From 3a0c844765bd0e37c9d0f0af3a2c90ba4f278a2f Mon Sep 17 00:00:00 2001
From: Shaopeng <81775155+shaopeng-gh@users.noreply.github.com>
Date: Thu, 16 Dec 2021 15:25:17 -0800
Subject: [PATCH 01/10] skip unknown compiler for BuildWithSecureTools check

---
 .../PERules/BA2006.BuildWithSecureTools.cs    |  23 +++++++++++++-----
 .../Pass/clangcl.pe.c.codeview.exe            | Bin 0 -> 696320 bytes
 .../Pass/clangcl.pe.c.codeview.pdb            | Bin 0 -> 5373952 bytes
 3 files changed, 17 insertions(+), 6 deletions(-)
 create mode 100644 src/Test.FunctionalTests.BinSkim.Rules/FunctionalTestsData/BA2006.BuildWithSecureTools/Pass/clangcl.pe.c.codeview.exe
 create mode 100644 src/Test.FunctionalTests.BinSkim.Rules/FunctionalTestsData/BA2006.BuildWithSecureTools/Pass/clangcl.pe.c.codeview.pdb

diff --git a/src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs b/src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs
index e4d7a3073..e3bce0d4f 100644
--- a/src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs
+++ b/src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs
@@ -116,6 +116,13 @@ public override void AnalyzePortableExecutableAndPdb(BinaryAnalyzerContext conte
                 Symbol om = omView.Value;
                 ObjectModuleDetails omDetails = om.GetObjectModuleDetails();
 
+                if (omDetails.WellKnownCompiler != WellKnownCompilers.MicrosoftC
+                    && omDetails.WellKnownCompiler != WellKnownCompilers.MicrosoftCxx)
+                {
+                    // TODO: https://github.com/Microsoft/binskim/issues/114
+                    continue;
+                }
+
                 switch (omDetails.Language)
                 {
                     case Language.LINK:
@@ -153,12 +160,16 @@ public override void AnalyzePortableExecutableAndPdb(BinaryAnalyzerContext conte
                     //    break;
                     //}
 
-                    case Language.Unknown:
-                    {
-                        minCompilerVersion =
-                            context.Policy.GetProperty(MinimumToolVersions)[nameof(Language.Unknown)];
-                        break;
-                    }
+                    // Language data is not always included if it is only compiled with SymTagCompiland without SymTagCompilandDetails
+                    // https://docs.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/compilanddetails?view=vs-2022
+                    // Compiland information is split between symbols with a SymTagCompiland tag (low detail)
+                    // and a SymTagCompilandDetails tag (high detail).
+                    //case Language.Unknown:
+                    //{
+                    //    minCompilerVersion =
+                    //        context.Policy.GetProperty(MinimumToolVersions)[nameof(Language.Unknown)];
+                    //    break;
+                    //}
 
                     default:
                     {
diff --git a/src/Test.FunctionalTests.BinSkim.Rules/FunctionalTestsData/BA2006.BuildWithSecureTools/Pass/clangcl.pe.c.codeview.exe b/src/Test.FunctionalTests.BinSkim.Rules/FunctionalTestsData/BA2006.BuildWithSecureTools/Pass/clangcl.pe.c.codeview.exe
new file mode 100644
index 0000000000000000000000000000000000000000..5ed9a672189860a5aafdab045a50eb1336ec1d34
GIT binary patch
literal 696320
zcmeEv3w%_?_5aNa76@$6M5CfcjTXy86jT(b31u}>R+C74KPzC2FDi+mB}!akv#hIF
zrM0bXRqXF)TeaF&h!!y*5^S-eqN2qb5q09mb}LZ>uH^syo|*gD%?3p9@%w)YpPRjR
zX6~6YXU?2CbIzH$!Lw&u8J1;b<MRG1@jmo&KO5<T4t!#e_2+)i9n_pL<++2VR$n@+
zXy(;dU2^qBR}@`*(Un(TRa^A^=|xx9U0HPLl|_?IJ+0`9tENpKS!`M50n3__(Z@Pv
z>f;yL;M=Usi~$*gEbDBaWtC(~@`8QwlV_JG(f7#eW0LG&E8gE}M3z<3AO+<;{4wu4
zVDRqB(fzHVHrRB(_w=_e3|iI$NA|adq{}yHg)@EDQcwQ)qx)OsBxo=HM%GTBU5mW#
zv(QE&#I~jozsRyK9C`J$i)ulcyWa*d)M0JH@A>%k{3`*KM(Sc#`Toeb5H!fe??n81
z{*_o(%g9lqE}n6TWeJ42$R~ME=~1p^<TY1aUi<yatq0kL1*Tkiayfz?dG++mueumj
zf<_i-Wu1cG%H(n-zyzuP{r3%~KvnpiP=_xP$c+Sit$_qFjpkT0%dBvAvAPOOaAZqp
zrSH6_*O-4Oe|o5+NWXAz_JxzJBUL!i6%FKt1D%n&&PY{mB<Ksbg=gl5%d^A2))L`3
zbtgcD1Mx^89u9Owf?Y?ps~5n6kw8aiWzqSm@be>qJY5BEg1M0@-;p1O^NU+26=!$j
zUwBHf5BKDCD?F(<Pc;I3Xl1?!kc;mb8es#_!MQUU$R|ei@km{sgZAv)@Jydzt_~t_
zARFii2UH~336u{Iloe6FK;sO05Izw0;+!7|3dlO&k=@}j#o?*N**#Ex5#Wik0p#Kf
zaK-2i2T>3=*AO@011jORRuS3ikr5zZl?pHKN$!H4<o-UAgxtkmD(U|06@4J@(0ppK
z4~@tbdKVbv-HvndKaB(#6$un3)1)vQ*n||)^1QrAeQu=Ar_KkMNN`hlMI<v)nH^f4
z0eYh`WrdNT3YUS39pN+c!k#{f9xrSZs*hX#=s>*PEbI_yYv)8D+|?Edw1rlVI{$)m
zh#cA%&B?2oY#B`PEcg{ABL}oPT(nvN6m>`P!d3AIxEL4#mv{;;gO6hef)k`7)BbS-
zIVS2do^C%Fyn^~89St2rvMj4+@9u)aV<uaTEwwoqA<rGYsPMAMR(N1O{}$x&@BX>`
zd$f;#CuHOAj9Usu$<M%I`Ptu+pPU5RGvk&+yX0p?Cw}g}EoUh5A^~gB5c$nsRD|DX
zz_(~PpBpzNy1VaX(xPG%Z_O#h-+tLvOKZ*$+<`TaHq_ib&iUxF7XZx{zG*lTtMecb
z)J0_ecT##>+E?`Tx36u7?F-fCTGtE=)#q7teOm(}I*>HzntqTkq4tb0rA%&UMMk)Q
zbZ8bDtj75Ag>NSfjBt$giv$v(7BFfe5=@K>=FTdJR3(tc5ue=<&R#eQg=4R4l8xk;
zOClNQRpV3de%9Ts2`Tg|PNrYq$3bc9tLBgmpkQlGHL%aX|DENPR$&z4?NF|OBOyF>
zV3(vUZ?hr;Ev8J#>C)7p`jbo@880<fcfo}iDPX_y?t<C4t0t#*7c4k>vW1jsNO8Cj
z^iw`iS?$R`q<2k*`UJutv@+YjxTUeBu5V3W^%IDSe{572_${k??qMaC`VA<K66%*g
z0V9%Su0|O(VgUa5z#K>%SlxCIik^LhE_xHQqWn|FKbxWJl&k&E%@R0=BFVpab>p+O
zIqFitRGomKx-}p|&j<9;E$2N=e9uH--cw}oS+VRL0x!5$;5p5c{4&Wp>c=TrB60Zs
zU5{ir1i>>1u<9AREc1uT`v<SF(~PLH->*=g^rKWws0&7-LxPF0&+QewAL__eRj7g`
zJ{W-#xa(3c@y-_xV#ZHYMgm>sm?10FL!WeahgRk$y<fAfx@A0t$k-BV+Pxr-RUTTo
z=Csq#&@)`1YxFba(Lj9KB4&lBE8zb>7=1|{_%cYgD)62?3RMmYGzH!bO&D_p__eMd
zDEvnhiCv^qth%YKIg$mC)%TA^?M?Wjezlx5@S$_}Y7MOJMka>!HcI=z>h{yXJk|49
zb`HxPtjlURWb9ZrFv##P4!&EVUN-zQ5Tp$U+9FkLq2sOE(U^M5)o~~+$det4kQK=c
z2UgZtHJLS_?#gg*eI&TPyTF<|+3K!ZuU;48Z-`WFAc%t^feq#AW1!-I7=)}yX1Q8k
zE*+>Y1;XLLI+cOCh3D$}MXJ_Ss<%$f!gJs~@O+M%io&QeL;YSb^+kf~!oe1&wJot~
zb051PQq_U!7hSm)cj(Hs<*JWv`_qx>P<+;ggKN~Cz|y~XZR3lmEU>0r-6@p?-)npp
zmGwnsk*YP}s-;c^OJfkSnzX_Av@p2evd+5T{BvB+&|FCVtj2IvFKLm;XN3;2M*yBH
zC<xRc005Gp>-qsO!AT9A{waNJA*=cI-V(3{bf!>!XLsFUm~Jc7=0!q15XVQEUX_s7
z2?wvo4v&3{wN&#xRVGEjB`6AAHrU0YUAkzOQ<H-~^yho0NPUS=eWDx6B<owG>x=CZ
z+gs}E;uxuBIi>CsE)+<>ciO#$fNdI#XN;G&9^++w@8gBjbYN|3U;~ze_5g_lH&m!R
zdla$T_B6wX+&(|>Ui<H)<!grpHiQFfBEdBk;Ic{;lve<6eW-rDRhPFa@UA^X<_F%5
z&5i`tN6LyD-ondsYmxhooBK}e>{WqH8K&3g2R6kfoBLR)!(yu&>R0DrIa-HKTn8qX
zPF#my^uju_+p56ZF37ic%tX@PKD7{%9sQMkR7>nA^#Ix!DaqDT^b=!2^3g4E|D*jO
zwnFt?R_!44__#n<UG^gxvFzACj%xArDd4Fx4J<RZCx#P+MP{tu=w}7ckNVq;X@n^2
zulGTvSd}v#6=kTuK@6#%?8DK**@qYnQGJT+p*pC>Qq9N(D<dcKk&K@3{EGz?>dl3)
z$%POhqC@<Pt9+Ge!+}OJa7<jK0eOK4Jy14h0<ZyyzK>+IF9vyuWG%EGUj`<-9M#An
zcOgtIC~}lEV7TV}j$fN$QcL`9)C~J-QesW)0(7hlJj@lrI3|E_RVQc)`cg|C$UzjT
z>I@f5;!U7yQ5k<(c9WD<QWmSgP2qtY5M09)luOx;MN{#+O0ds(B*W7&9(s59)NdeA
zK;5Cx;4<nCmSqL%&a0>aFdwHQ-TAhZg?2Us3|?5N5`S^W9zlX$=#f?67?HPjmpL6n
zei$p2)%I2Yh7gSHp{l#OyFoV+sIU4V9y}eu@;+VOuPJ)GCSGiiDw>={q;u2~+<3;j
zr4BnldQ~mk+YtnAdsQ=1U2fW26{55e{Awxkyo|*9nXeWh!-JOr$M%Lg@}$R!f0YOi
zs<QqigB!L6&$cXS*93GC60^$2%M9NcuA=;E7)!IA6c~avd}w*0bbs8xBy++5jAqFJ
z={(&g^<gClk<tkb0c?>~F+PkLhpTFIS(krF1y-M3(J6Tv7!oG-xoq{&EO1g#MXKTy
z)mrHusylUDP}LqHN_XzKiMdzr1w11auwNvy%6-RG<<82%Eynel(cW?GX@5n-1Zt+I
zyj${@+99HY9143}cWquo)^4A?fY}Q9vB~OG3>?(iP@iC7%B;kxxQPux?F}3GQr%!w
zHgNDsmbJVsZvck?$rctsDD=sT;R3>P2_p2!AKe0Sp#4$kOx*=-&}%tfWF0YDc(=RY
zZX}KtfZYXmI``3F2VNLU?YJs2x~ju|2UZnU97W<^!=Q&VBceWA)f5uoxtVg;7CY(k
zF^z05KNVi}nHaL&1wK*B0Z*P)7KA8<lwFU9{z+WP@|Kll;ZFt>7B%PR9G|(AT+r$M
z2~?9IpnOt7nrF<%Dkn}IN$B7UJzI=LJV+9zVMpyNol4e=3=aJ@Gg6w3+wkBpexXDF
zUUN0tV^@ObiqM2y^r0pFZ_inxfw*M0o5%6hT$}uU^X%m3)|@#=;6GG?@}Z8hnn^WS
zt2dXcEA}GQa-+d!bn{x_i%p@88MXcVOJMi`UsJ1s-e=7)b<6ucE}2?T8YQ5DSTgHO
zLka&9U&9t>P*=*JNn}kNuZLd4an5i)Hd4ibSLhDoLpi{&s~vPL#YEu~wBlX1Vh|JO
zWX#qzB#(4W0^pO%AL>j`FCxEs?V%-Ri6``K=ok(iwTFGACQCi9#d7r;Xw)E3<2uYb
z<?3V@pFpE<<2<O0;pklcT{wq-e>t0fAFJixCuidCj9V7oEkDr(^7G5f<)^V)ett7e
zejd6IKX>2Ocqe{Zr4BBDBf;!&^cEyVtFprj@8V4$J5rViN1Je8Qx1Hp?x|Eu^97mK
zz&*gKq&09q86*;b^6_AIK|Y2=s4Jtc&#FK-R1N&K<_Ei*g4^&aOiQ{!kOcOMHyVti
z+qvRJ2T@h2+XJ)yHfV4CL5=087bD7*C8T&7dW${RM}<B?Id%NSv#w~XI|tklnw^(b
zR|zrEa9w^;&K>*I7Bm0){DXK88J%dDoqsUzVZvn@tK?^xT-9sndlU@Afa;5sWkVlU
zuSil?I8U9sA`99Ta9WWKYuB1Jr!V_6bl1qL3H+J0{~3|*G<Mhak34T?;#WhfvKzKB
z@9K9hI3FwE)0ZvP<@wWFdFGk&Xm14@=F#`LKG3aoq#iNR|4<&;<!T-Dl{Dgr^sA`m
zQcS(5OH6p=uo6qw7-@$(%47b-AS^k8HlfaJ{6qqs!ziiaQ2d9{C=|aIQ$?5ke$vVT
z@7tn95VY~TU)K(~m$AlMz|NoN<oA8N6fE}K;kp#^_4?>yr@*1133Dl6YB5LqDk24Z
z;5-pbIO>qgMtC3Vdtl4<U>?rWwq`b@b6ha*8qRrkL(<7S!7mSs|6J%-&`%!}G$_9@
zGlK4G^bmI1m0Es|Q+{tLf45UUxt*T=^pZ#V4?Y4Hfng57qXppi9DqAT7f*eV&!Q!a
zeg@+8w9{L2<{9yQZyu%v7_Arax2C^s->vIAx~2U+h^*E?96d!Y(Lcfn(Ym(LEu)|H
z-xux^K0iBriZ6V6u48bWRL~X<td_^+Z&{J41KS!tJZbusb;hQa6`3@!?dVIdoPP3v
zwNmJXw<P7t+Ub`MSle?=H9xqnDflL8lqo-@(kHOggGjd`Q*zp1lYpRkv+>2+tFXd5
zG=4(2e?m*246F7um?|3H;&a263;SeRwG$&%>l-#o!q%BgIMR8cyib-@dvMYVNEn>-
zLY7rG@ZKiSk7VPoX?m7pHJl0(OdS}P=NH;sQUFOLhw4}Nom0UU^#%4REwb&5Hfg5n
zckE;~6f0MBOszjsAV~Z*Gb}f{Ps!(|Pcx-Y-P#Ansqf`k{&~45rHccQT|7H&am(kQ
z_XY}i5QxjtInO`u8I69%TCBdqRj|CQf#D^zu}`QCV-?!r%20hvAAjSoP%Kox((*Un
zi91~{CQF!7h4-HIh2=*2@`a6&Nd@sxTT$(0x?ql{U{Q~PP<pf0PT-%qaajLHs@68V
z)rL1h8?A7#8Md5;`er`Y?H{UNYSrznVPf5AH@ZX`J-P)(onT`0b1LIKEW2&F>={4M
zpKjrZ>0PMWh4Bmd0Q-kEA=O?O@7?|(OWUy+><wdOsv7~Z7rG8p9i}%QrZ<`D_GkWV
zJ=G0H0ZeZ))#bGR1T8|r(Dg&myJ0?Xni~?jF59Y|1nGwq=0_$D!Q@9F7nxXCuBMR<
zw1JCDa}j?XmFfy@ZKEZ_&OJ`UgR;3XuXeaR6h;Pzt2Tw|H(9m&Mc@^KMQT%Jq!eqU
zwn(temeRQIX*mOZlzPHhK9XLcjzao2V5P`WZ(w;#$0;X&YJ#=LyDGpDwh91)n4<y|
zdQ<?ep^OSpM_>yGjEk!wk%_sX7U(os!kI_b&=uPQYGdgA3|Sp^>Jn62ZWzy{9@-d(
zM-EgAEk|jr_kHR~5R)E2F*K@j^_*UgV^!Q&WE9qI4<@bKq<!>HQ=6v=0gAh?8>>-h
z96s$|t582(3PekasUO3e0}Qh<-%0bKvm_$EaY0{Q_GqluV{b_<9xf$4&&2DYmOPnP
z_*^E>`OfoLc`me{MgO1^$YUmVI2i9^K86D2%hC#1Zs_`KYYwc7xgZ3&C%Zo#+7&P@
zCbDw#L`fszvnGPRo`su%DDB4r+1E-wwA6#_lQO<0?K=zI7nwK&Jp)sxRXbVePDTU2
zCnE5pq7%4s4=F&GHBUzDTQRPlu?9EuQ#8;~UTs|p73dG5VT#c+!}NmGFPa}a9NkT0
zHdn-z-~Db|?O5CdPsPm<xZ&Uf6Mj$mgm1dSW$=Mxw4mm=>IBcyI8>Ie4sXt~)FwQK
zW*1sF6sp&F+XDA6tpkzFkjg+S!ayLFnZyc05#R%2ELs48V)qC1UD)ZUa!do+*<zB>
z2!jfcS%g8EW^@q-M%NX+*XX(w26e?MNHjs5a*wimoTPPy%k$NhON_Sb#zScRYkT^q
z*2m$v$`!?4ciaKwQ+7^GCXg*xo8VD^XM#)7U?R4`;ZWV)ae-W6VAwixL(6k0g+eQG
zD%GtZWm0&CmIu&JJD>UGkOp+{9azgi67dOi3$^5c4LC?(yn)M;9qM0}3DOlJ$-j8;
zXfj6P(m;amaXh_DKJo~4;fF~8Rjyuu2!tXDx4uX+4AM>Q3>%6DyVaqPgD@gTgWJ?r
z%#(0eR5RQP$^md+S6M?L3uLg0QrB-~8w$&#SXcZ?Uhh)J;2mw@+PgKdmW<EbdytD+
zvi&4eY7|P9tI1pVKG4uZU=&O4g&Z)Gf7ztG?od}z-F{5WU}CUy)g)gxGevH7#{LTJ
zUHrLi5WS)0Sl+CunNhtS4sY~K)tXARbsgd70l&C9A0YU97@DUoatFeXr16WZ3njNp
zQO~18>DPjHTonp2Apbf9z8d{vxN0Q~U~~rgh}k7*P&ph$FkC_=p8OFj%ms~tialMa
zs7!Lj8`u!4-yn0whH#*Th<sp3(I{26#ExJhS01Pg@8(u^7vzEK05=?1%DkoKg{ktw
zQg7FK##gy2){9LUV~%jc4f@~6Ka4dv3WYn&+K=Vz{9r;2W)&XR5ir6(B1#~Rd==!C
zli4p-U9I@(`GU86XlxoCVtx<)6#P*Ca;yZ>)o<f3$QgWVPP4n5oZa^&>2kd6X_=sJ
zw~wP11xLQff}98Jf`G@I(a);;P`%hUSYLDb(Is|$CjXB~`7_;o8^0aVw=@m8^!S&V
z2XxUQJ7Fjbf~WR|^cUn4C4ti)KO@|)u|GIHV%`Yk(Pxv&fOdar`airj4gE<!(?7SS
z%U2Jef$Ht0*-1wAm;OZWDO|R7{nWRf%uX_@>#n!?S9PJN%0ihWOQypgYCZDpEa0mO
z|15TY8qyrUf(;V+kb#RIV>{sHNo_9sGbs(vdOit_-Bt@59p*c#7Dkbvq69@k+l?{9
zs4M<~F@Qo)H%uvrd|fJ6EX~vj)JZI*c|+ijp{2?==)kQQr)tb0K4OTM!ytWbNI_ZU
zyW#`D#N8E{m^V5{B0ebCIw5?Z4xb{6arR}o+M^{~AP}4E(8d}5#u1cL^bD+l>qgwq
z2z6T%o=Agiq#_^cW2_HWmrx%N@3qZ8?^E>KWx+VOqa!-0KLQRFB%~;Nn;_uG?eJP|
zf)@Xra4?kBO=`$f*_eIWXn+gVw^{Xr(JbUz?GN+M{rJOV|E)jA9U5n>Wn)7V)?o&)
zYLBSqueuq`g4Sc6JfJ3n<2N#p>EYl8I9hFeeS@CAq3i;XdV5(mM^R*A{<uKAcJFGE
zM(9GCp+sE0WlErh6A@l!NVcEYD^LI)H5DoIsq0a!{UfBtptr*$o4>7ge+{jw6UID3
zdjh%L>UI=lJE0791JgVQ<Z7eV1=jTx01-s=`4>+r_C;Qe%qh-peAYj2Ji6u5mJIw0
zZ7K5K{3a;Vuw^d(`frNx?-Pe|?VK^I-{#*%CKYE#wmyv{E=M!`p+BO)4F8oaGyF4K
ztgPq#gZqYB^Fr^%hdr-BTr(wle=*8f=4ZhS|BZcdos`EvMf@|0e@ghLoPRFlpPA98
z=HjJ>cK-cjIUFzDb<e;(YwDf#9j8v9eD#pc0E+9RyijXVsJ#ejvpPOm4$rAo`~Bz~
zf18tU@c#ti4#*qS)b}Jrg6XHa4?kH>3rVdnj5cJ4+Ot1d4p(1yZIRuAUm({C_YI$v
z9cuN3+I>2|?gIl<kMKx0MpSjjOla4)-z0;)x{D9<^h1vkFXcU{X`hW-nr`8~>iDQD
zZPu(wTRs&YBnX7gV9_eFn*!aOg-^p1hcu!T)T<dedZ>0)sDEVZ`>L)=byZ(|&oZ;%
zg`hwPqRb^DjrdB#Uu-`rTe&s8{Z;U-7~P_=sCazd91!PN;9|Upl3$Z~?;}VrSIhn?
z^1d~PkNgKYKk(1EN4$ld#YdA>@CX>SQZ?CGeAHR@{u#IB>PkC@kNoGMl&Ak{x>f#D
z(nMNU{AkY0f0Re{1_XD~JA!X@`3zXL9t0w4X$nxCf6ouftm-2CQBx9>EN*~xYJNw$
zeD;62`oSwAl#;5~{jXLb3v22$GmgMli;=J2lV{5KVD3w+G1JI%#r%LhAIP(#A#g>&
z6}ITH@Gf+PR%9Pnm4JaC+6MKN*ha8`tqYNY8Xjk4OHq+0%XqaACtv27&|kab{^f%w
z!*oM)&ZvtfTebV3k2%d%s+QH#`^ajwn3YnMbeO=a>8`%#+%hNF4DmUXz7l5EIc*X9
zndS(3pyO;#T$+P8h7M^?oB<+nSd<Z;i~%3}Cj{v<6T#G@N~uqSfAR4mK>p-E&HNd*
zf&eO%wrBhF)M(T9vVd=FP7zQ#?`e4-7I-mYrSlq?bxqx2)$7SL<eVD(po;3etGP%~
zzulLkvXG9Zj5Ra^)QwV)jmfcEEjSaC3Rlm>8v;jlZYA^NH?v4AhzYAQ3Uz^#qS%u1
z_|(Fu77X#+FecAD#E&rbcSwy?<%Kgt_4!t<6#S_a1P|qN*`B6<(PdaaCDbW=ceT1i
z$`@ftJe4lap8Q~!M<4^sAM2DK%Ee62^58F<15;Kc9{x&1l3#WC1@Zf#33pKh)aAD3
z$PFY=Y)_q-Ro`DHa+0VyrTPJOL1s<%y)0O+=C34I=F9r<0BSU=)fxC%bT@Lj;`%lo
zLKFC8)m3@`o#p_F3?!rqRpLPEP*hR?X`l<KL$#3%29htdy1SjMY$DUZ#~h6`#lZrX
z<)6nDAsGd3_{#!aV{=NtZtyQdYrQPkHMU_n*$=PWOT@yt3n0grZ|OrA8&9}w#n?!0
zboTWqFg2qPu{{i<tK9>Cx7C7CVP~R4Q{o}JGaxFO0^48#-G)G=L6=o^jcvVY6kt;&
zX|KkgWQIuUk2EVBHy`YB0@{$&+eV&<Jdz&Y;R?r$ujCaD`4vq~x8l_GtH+MXvD7^r
zL?+hI4f}@OEvptb=0v1`w2NfVFITUWm<iKO47HHIr+~j>D>+NCY=!#lX%S(qIl>P;
zo9B_2dWEw_zW^#|sVew2Hv^bn7U<`tDbM$(JU@{9Y$AZt8swn^i0Ao`>IWz+w7jVq
zUA<NdoAG-k2^+YmN2#(=uCOsBtLM(b%Y>ljf9y({_9iqrG=b>JQoa-HEg^uN_(hi>
z28O!6Rd-1BT?AliA7j_PtRSg&6da-cdW5HTT~gOh2rAc8du$*lk^<Hq9&Fgs@P|Z1
z?F2o(ZDTY%86%;`ST9DpWc7H59@l@=gC6Xj9ns@V4?Tw2wLhHSlO9iu^w2|>)U^|W
zN_4ul8+x$zWO_6|h$Jt6QE~D<Q(f{rcNfeBpD!X;b{EX!Eg4c2456<_MbZ4)lKeg_
z=Fn$KDJW^kOFX_3`RWC-1Wf)(W_Ed>#dR63^fV$O&24={XD%QB2)#lL7;B;)-s}|X
zkt1JnH3XTj0O1ut(x}nuE~eN6i5dgi7;eZ|E=W*&CD`R^IfAbzB1WERp->wk8v!Gl
z-QX2*lE16^)^_xf+>fb;r|2We<q;<28!ekRD%BewNpY9N8o&D7?m2}G_zSw+=%;BR
z=<_ehE<GfWN29%4T+1^kHy6zrgumC{2wQ+Jq>5r$_+>Fo4`h|j>4U##-%uchd4K&4
z>@L(G5<;R7^yKas-);R;*yqQfC+O~}n=E1APgn<z+OhS}lt(}aI0sBdQ`BI_-scGL
zT%)hC!SFf2kkW7`(3_vFeMe4x+_b3kGeDK{Ljrh_nfNF8;QjI%Y)_$r_%|DJQob+J
zgqV73fSAI<^Lej9*zbR`79>BUff?wo@J)6J-Cpolcfljnt-z!(Shyy9C!dKvL>rx%
ztWin6rw8RZ)G-{}`JmyfQ)}P=W-x6OR(yorf<k#>XO=Gb!=4-_@Z=;|^hmhqy;ZyI
z_rRO8J$M&DJ9Xi`#iE|3q=h$pd+_`cFKy#@`}W}tk@jwY6Fm|vGVLuyd-KuWJhVL*
z_vpWI&{0Dx;enGjPe_I7(oe&?Wk>M-0`rIq?*kV1w%LVOB>0UNc*O?4A;75+_~ipX
zPfX0U!w9p;;P^8yOc$QUuLCxZ?Y1{E+KXS%3yU4%!qfb6x4`R#U%Dkm)b0-$9g^Fc
z4&IdQ!TZA=#Lb5HD2sY&mkwTn1E@ECzCa=kZFm=LAD*V)g92|m{4$`>OTU4sFkSj-
zc<1g2-rr!>a{1*+7WcN<g{S!?SK#e{Up^@&Oq*XW^}=-FY5bOAp|o9oIcJ0yzx}<i
zJpEzx^BsG5q<-5&lDar>`A^`%vW?2ELwU}^=a~A5j+rmadeRqKo?D?1^bcwnvxU?z
z!Y&gNcyIHKcRfmPbgme+AuR^_^g^L3(KHcLA?31!F-YA#>X&$v1m+)zasT29cmhA@
z$M-$^>r8*Zqs<j|m+C;^Gk-g={t|bFzwyVwpGnJ+RIbjsOfY~ffGX2ndl3F^LljC?
zV)<4W+Y_O-6E0glHY;}_mw(W27;xO#C2Pgbxz`_V)qN-FwLoHdS07*(dh3MCUKpE|
z-zcxaaF5sG@>(E1zih<Zw_ufi0pVqs(K~>S%;+6d{>2KTLiNgmg=2M{qw`n)8@bii
zwPN9Dl~y|z4wN0CUOL28bKSz#)p$eTs6E~nO;<Zz92HCGm8y>#e$pWpXw9lpA7<6W
zs)_mFZ5X=>)jPuGxGhpJ8S33M`-0{O-O-`tWjO92PhQQ>hz(VZ*axY%%MD>K5A<CE
zYL?|j3UYbF=z_$ml6*5W_pq129;7*F?(F=`x;z@d5G+usx@C7I>@0%Q4}g<6p&95Y
zDSn_PnrK2zBW)2(fEWzs6{*q46O2shB2_A-8PcPUk<y*q=I%AFB#j3YJ5@RikuNR-
zy5kY~Z!$j_fSb>VnZlIZ<ne~qT6Jul!Ypb48UDt2X84baLR%6mHJ;!jni4M0C4G5c
zrpc;<v=X5extIfCr#|N-J!0^FMK+Rv1!qQBts6`ZoHU|7h1xRf3P@|@)oC?ZGeM>Y
z>!kLKwXpvKSnUmTWn<6zKVg(hBI53VG5Ev1h0PubbspeG5$}OY)RA}#V>VHt&VZ)@
zO1VV9zyjY17aJmAf^oj_J-opvDnnLp{r<&eKKLuKKNM>a6or_x=rK!R^Bc+wTY1W3
ziFJT93l_Zuw>yx-eZqrj%Y#GV!V(!}Yp==uHD6wH^HSv(-bW}8%*4JhoRnTKxg+ju
zeL?yc`xO?K!39;jCs2!Ijtlr0(#mKCkrxs^J0A-z+ZK{qAE@e6ky8-6?^fn%fA97`
zGyZqAy}jBOv3bK6>KauqM!WtTh)WQnxaIizT**<R+CSo0UIPE));z4K{L#P3bHF#@
zLJS4{-iwli$i*!+OdG^kM=-m+*?Bqcl)m2vu+=Th-1dkAW(FoU4f<LKz)YrT(9CW>
z&j$0ZQ+ToiAnq1sc01#7bR%Z;w?PlF0nB8QfsEVsEC<ZHPGQP?4Iu88W_J6_k^_3o
z!1hXw^a@ELJ!Ue^fW~e60}hxO*jcYj^ZXf7Y{E<?nZmej|DglsU8gYPaSR@AX=b+v
zZ7?$i+K`WT0L)~X0gc=CA_q+QAiFffhXs$bnWPIdw|z6XoNUpsWvx?~@>JvTx?7sr
z?axRKno|T7TDOp{R}J9XOw*v5-F}w?rUW8Fm!4+>n9QUB!c5GKU8!NTL8jH`z{ngs
zPh;>t6LdM|#ZHt~<UyO&#g5VM?aKsRjCrvG31VLjVqdVforl|47V?~hu@MO}Uj55t
zyv*6dzl`JLxEuRPiW(I=&c6(yZ(A>77Ry|3XPpr{Ko>4$7R#J%XC3RUNXrA_Ual_0
zb|PqSwkjn11`lI1D%A9UOBPH<dl2_Zb*D}UDGkjQ$69_hgP3zY>vJATbED_ku~)aw
zwV?3xALL@g@@za{VyNLvt?qlBg5F)JYl67)3j+QrQ-tm?*^Xm07J18K9~OCLSD-HC
zTlTCh@PLn5zar$XQVo^1!C=u6>Y9$Nm7qC;0}+G3ITYz2$Rtx{3HOq};eGr4f00!B
z?b$dTfNy8Y+rIgkaO-Lt%1yNVGSJyKKck5bJ-Z4iv<(UKtGb&8&kt;qSA70uI&u|J
zf`~)(iAnlJrxiWs4=7YH$wY3KS~BPRnu6V^N{2S?1K<D$hUp%+wswG1ckB&agww8#
z54{`yc{&2hync{=J+yUt?OvqDGH_%7U>Jf4cZ-i9l9;;Vgu!EE7~3I1x4P)4Iw{H^
zX<zJp4FC+<J?^hONddMnHV^$je{fUPHfSu;UKkTS1OiPm!Q6DPWX4irI9&b!thO7$
zR?+NI&kU*a1w$(Q1Fk&-MY@Zl<>!{@eF?EL35kxCau%^-$IE7g*yv^-pN8w7Lv`W-
z`e$$blc#_B=^`dncR}Ku5-SU^`{Npns}R?LxDLZL0@um7#^4%<Ya%Ye5B^%~e2>3&
zOb>spxF4Ym#34RK8HnQ-^E^)z3)OefVK8;Jvv{aExOz68;2Vv8M$O7uIiTQpSV+_i
zm^Bd<RD*chHgz(zYVHlkaT)r(>h%Ogc<Qq@{XU#+kE23yc>)b(qoFh!$^^jzjV=!w
zhuCQJNk(InRd*cGc(apeY#<sN)Cwwk8V&uPMuYIwH4YlFqoV<?yz^o4q2-xYmOO+}
zwx~arQTbm_*KE}~giS#kT34YqAQhuC*@f*<*=+h3eL3_WDB%k|=>P6!5B;A-XY@w@
z`ZsqA{crv>i4AP}Um$20`cHJx=t2LF|7oMqJN-9anvVXtHJ^|EbI<#7_+Q-oJ?KB<
zLl6B=1{d~5|IgmA8@_A&pNxi0|2O~R<$rWWul(<z(L4P!f0T~?!;$)V`2U_ShyDY%
zBr%>Xf8Let=|=uMi_Ykc{`DJn3;l2IN<zb?{{@1E&HpYMJ^BA1HX6Ot|LR5Q=zlj-
zKM(y|z8v~TKS^r1P5&9tW?cCXF6@o|pS^B3eAoCt84a8MZ$fo)<v%*3SN?a<=$-x>
z*QBF=?sK1y{%v0l{RfKsy@&jH_X7|8pG9Z%M*sTPb_@M)7N5I=hE4wq1Pz=2T{L>~
z|9TsZ-sykeN9pLl2B|yb|AvkhtOShGBg>IOt2Vc_@s>}!yG7IJukS_KkkoKv6Y@e&
z@-Ho?9<8IA_Fh}@h>E-4Zn!BPfWt#w+<`7=oQ?OPenk1JO2Cehsv%H>To~0uu7fTl
zO2~g+wTaMv3~U&p3n3^7=P3f!c|-*NVnCJmL^~pP;l{am4n4`gM74wfO&Hr99#l7O
z*5Gv*n<*}+Hphr+E#4=p{8bCla|TrhhDMd()rl^uw0GdRmBs~lE!=pg{Jl&5-i^Nu
zJdZL9KC|#b=C(F6mrbE|-iD=0Zs;v5+&C4f;pmwxx{&t+7V^GM2*AFYgD1X40`Q&$
zm@jutjk=~HIOc|k$_ALYN64LERUVC&-~}}pK`^+#pZ7d&%-q)CHr#j*QiawBN20tB
zM`z-%De@`~Ka4aoq5W>u%caRi*!6NlZB}^U6qar*$KObl_XDE5_s<IfLH1$Yu+Wo)
zh`rmbjhEww{|w+81TYiZzYD+!6kJH^jH}9LjAUMx&}tPj#uylLhH3Q11@o^dYHh4e
z26u#jV`4i4e%fEeA3;{O6cE`-$O|`?;cq0$`vFnj*PbMZX2vF%YU&3+LHcs{dN6NQ
zc7}y5jW%X=un6a61@c#wAVdv;33*vj;=BrlrVE$@TN|e#!PCs2?m_x7F?K<$#D#RY
z3#qm7LS!?j&5-6|d54LyVae4*7D@*#JQsPU@G(-D30Qq$tMn_s#hon4MgRU1$A3I&
zP&EMqt4@!9oU)fX{@({y+Zq2aIphDNFJt`wI|<dfE~?GgSe`om+Z|NXj(-=`yZ_IO
z|0DA<oblh7pJ9*x-{E!#<NuN)obmtA=N|tze~$4#NC3<DpUUxH?u?CE2GGgC!h&-~
zID4{J1c<a67f2@pmg0!kh{%QZOh9aJqX>Yp<1K8q%;nJoGVH?(MFcd82oP~ld#Vuu
z0b2y@DW~M(m|`FjBnpFLhdb!i`I(w8xJ{b8Eyl+rY%l9Y6bupkL=;Sqofr`ThnCb0
zAN?$*2*`sO;VI?YdPswJMzC2T4Mw7}XEh>H9C0E>VtWL_V^ZD~2+#b+2n3M_p^mYk
zdZ++BydSU+x$)rMIe!pnY0vpTLkx$<=7D(d6FA{ty$Pczu$IP#wW{h}XZ$#?Rxfa-
z`aWx&p?(m?k62&)q!`bG>D2~vSaq{!Zufgo>XVET)Nn!R&9{lt8ltpDt$4>l$$3?y
zM5t=k^A1Y40&*l!1OtaY)UQVz(zU}gKmo?&z~p7sU-&p)&<9#$vdH7C*IoO)2K<GY
zwss;OGp-r0HX@Q!wv^?=jCWj6&4M9M;g|+QRtNIMOt%Re$||b2kz=d!VEn7ZeiYh1
z5fh!*=5L&jjL{Nf*v9(k0&l}F*t-oI#kg}9+E4cNuJ*I9heDggTWu?9EDJ-`5cMR2
z3~(Y$&B2l2YIP5KFaqlj^fTvGO(8;66@RxW6uT-`!<NsPCQUuxZfX@~AJ|<nInSD`
zK1A%O*o)vRg|d)8Y{hYb^=Nc(eK@!-2B)Hvj@{d|C7G5ZoFNaV^<`A3mS?5)Nk;44
zz`w7xr{&*2zUATHh2R`BRi)$K6Q8q5(f+O7!M`Uaqh#~%fr66Z-%J;!bo~3LH4aMj
zMQxXVmq0pr_;*?lNhjSJw7YeZaPW6j(Vm)vtMak8{kSS}F!z0vgM(yhIe&B03mYqS
zPX_WrEeLJgiqr0sdH7iho)jLgY766l;_dTrkxJ?~n}@f&>EYoGAQ{JPFFYLmn@y$I
z4`P=K56_UsUT8P=49%EOL1#@-BlpleOs_s%&H2Mt9~UGKSFMK)6g=#vgQs!ufZKM&
z4CF<pmS$pq|0*vR8~&{h)eqSj`8(M&l=pcri40o)7O4;aNiwXYuv@8KZX^E|ajE6J
zT0MrcL6%xK|J5c#JN6PoU=><*dy4vxBV3`f^Mt9NO9po3?5tou)r0F5?<V1@8M{cG
zD7dx|*A{iSi>vdh##IFK>(4s4_614^*`;QUm@s7tl%>(YT@ckvRR!QggLkR3j=)?Q
z%pVsl^xyn4<zrPbRz;3Dr(lJM!7JuSvELr%84ZxLzs5Vl6CSx1C<Fswo`zi8H_yoN
zLWnxd*~4D&4h5WG=%hoq<IIY3JsN_A5bD@goKddSO3e{y!h|>2Y0Z?s&8i%XEHPEJ
zIJMy}_2|e9wD!+zEgviK7zzBjJre>42PG#pDkUEC)kEzTp`m7}!a1a_6g}O|<Cu!n
z(;HaxBdqxm^$IBIsrgu`nMbWj&FiU51RiW}LdO!5)f68P|NiJ!kSb-RB$Vqh`MooU
zL~8@NM0B)KbhN=V<%*6CJRjN>93a#3r#*rrf|^E);8+hVWb#{&Uvw^qVyJ#y>g0EW
zhYR0(JBbTX7V1HfYWW9A@Bm5hfLer}V4xvJjPt7ILYe%gwmMwcfNJS=o|DQXGNVy&
zOjaKaWP8_o1jKQ{wG<p{!&Pfi1P6}BT4T3di;WCS{ZFs3TW{4vT&`wkNbn7&YaISz
zyDE2sJb89w5_N2OLVvL%Pa453+mR>7ta7NctT%ZgpG4p;zg>|h`zPaS%ae~^Bd$iC
zyoPQyxTcdQ^Ph2W-6L6^JR(pWd6I!Plim9bbLGja!gAY}CugO|lY7Z8R0%zEj3ZB`
zsJ{-_IeGFzTe3u%j5+ovEsjKqttTmrMA?Qu^o;8ZuvgF{Q7k-Cq70x!`QdgYN~0rD
zlGZ(`Lgh-S+z6Ehsk{X-4kFGr9?r@gp%TI)h03iMr=;>MJZqss1^9DnB)9heJYvP2
zm9<7v{ggelAnkWau-t0ghh}T6Em$sj)gxFYgR8b9SUyEu1y@t>0EdiVxgnKX9KkY0
z-HlMyoe?Z<+g**MdYRq+?TQu&f)M%A&{2rEr=IrXF>q<3`@|;6d)#7`%DZsmDEtjQ
z$-mpP9|w)&(->uSaj_pA@(Q68;eBWcQT{3m+_fG1(W4UOD3t7JKORm*463{*+L1=y
zg&T+BZ|F(>-JbpUKI0=asOsW^>g<;ZWeDCUs{B<|-~fYaI{Q%{7ggJSJQlBo8^_Dv
z68Sp`f1yQ&qs$WfF>_lRnaidm+m93U^+zohUC8?Z3wiI_kBiM)v>)@H1eh;(O^v#y
zboOIb4V$q7K=lI7n#BDSB&q3RXg`wM`M8Bi6{)uUnD^mmA^w^opFj>r8kvyBe%wjK
z8@uo~66O7XDDRW)$Al>M<9yukp8@<U0n9|leoX4P_G3O7`?0{F{g^k#ew>F}54ckW
z920x9A9o0{aY2^%1ERe5+K;80wDx0zSsMGXVCl6V=O*K|<P_46iQ0Z_LrStA`;fiO
zB~3`)VWML{Hq}HH636huZ2UEJJY5PiLEDdiatH3b_Tw*Y{2Rw(n(_Z4*`f$2x#NEw
zu<G4@{OFU8B<*QG9u7bpG-Q9?e}VCDT!m@I{|iJldHlcRpqh64yQtdsV~(_M_W1wL
z7I*yDo$ZYOpW}81<Nu60XZ$||!YBKWdK>><`>_lv`j1k^|F&8JmhnFofN4KAV?*1I
z`QWi13mAw1kygfjoFW1q6o?`Mda)mi2v{g0pix9Xqlf^H{aC80Pj5dq=%uwEd$D!w
z$0?#9SMU>2AogQ{m&ShVL(4tV;N@8)6cb~{ek_&I+)Vp1F%CyP0^v7O-W3Rqw;6#T
z`asftmevvpIfdXrzlM1bSfaHAvCQb_V4}4YF~98bL@PGC@Qxc(3U$^HC#%S0wU!ji
z9k<8~=Ub~Lj^Hb;C1afQv3xnSe7wqd88~@DQ(b+<;1_Bc<%v{GiFajCY(hN;foU(L
zQr_2<<gyYwxD_R&{fH+lapT!4dPEcQt0jn>!^tmlJ~{jkJVh-YUQh;7Ar-C&?pVm<
zCJ8>}hxvVxIP6y3Ps5v}17Ql~<ogu-X~K{lzHG)TV1B*%Mm9?`wv%=Ar)@d6)#4OK
zO5|Gheu!e8$QR64Pp(172k@!V4ZyZj4SF60akMN>WFcPi87qLG^$W&s)P%F=aSE#J
z|4cA$mx0A+c`L`pWT`w4l_Lf*U!5a0bkuwsCq}9(|IYOYmIMe|4d%6G5V07%DB6Be
za{|Hb%d|)o5sMe@52gj$d8zGp;+<tPlE&h+CxCh?H<<pyc@*4Aj|P4KW2D~Ggf+En
z`IawU80G>|BoO$p>S<59W^^9iR^0^K8R9*EX&irg65tmUU`+9;Yp}~2A-c3@#noA0
zD(Gf3qdTuw&s+|GgsS>4k!cG1#;~`iQ$>JLxmt+zz1{<;!>n~@+x%wsYoVj-9sKuT
zzu)jUUYnhb69aHm*Rf0)j{*{KoQnX?&Psfsvs|6&%fu2RH`LYL)8k|IyYQ%E`R9&r
z0P{Pw?N8Wwc5QxiUSx0<KE(?j&WjbIpOZE%v+x}_6fU*%?Dm-WadjI^dEUWg=R5t2
zUFsMy!cYn9Qs?LaGdA-kv$wW*f=_LDtj~MiSGs56avUT0>D9EI=`Bn}NuL@@p$|s|
z%Kyz%zIZ$3Q|mWh1#{@Vz5HedOMBw|n^)tg4bQVp&tF60r=utH8P*HiB)B3UT%k9Y
zv!90j0E0}A8_F5MC)6>N@*&WbLxDxR9XG&n6Ih%2J^D-!VcBhT18fJ#4PA!=!ZD;e
zAq&Jf$M_2faOc34!>Z4v_1VPb%<JP0smaC{XoeKdT*0EMD{`_=6=6^~;cHoNh2cz{
z$V3@f4uEPkA7BYvJ^Cj{|6}|#Wy!-}LcL3M-t$btnLHEqOcLnQ(-7K~%WVYMA;4R4
zRpBUR#C3GduiDmBF#=)z+ZtQ^^RCe#aXzBuzvWU5%)b~%wWB2V&W_+wiRzSnq~4}d
z42dpPgznIrG=)^B@ufi5+}VXb|4p}pJldWq+f*rqIyA}f%_V2Q>KvD3KlhMqZ{w>p
zB*T7Hn`9rr*#M^-1<`u77W8vT<^a$nTMgLihCezadknSn)Fs^<oXW&gm-}8j6Bg|5
z;>PM*N`#<1UmY7LVrQ{^ar8YOrtpFLKlvas{3l==J{-jySS;k>P(BPX4?>_D%>yQb
zF7<tE@xnWp)4KW5M_O2m+s`3KBlBqCI_?dTi~;QjFavw_N@PcAr2B7?5^FuKcW`}(
z3m@pSa)I<dxDLZ5gV&Y^G9Pd{Q&-sBEFZFyLpqWAQ?yc>&A`&h`vXBwePET?n{RXb
zXSJt)t~KsK(?77NmZCDUbnqF^L@^5D6*`V#X$L@c^HTtu4cO|RkJxjC{VgOjKDnP!
zYcS&kS5B!sjc+*WX;?0!7W}MXBPq0;0va>+#1Z6IwHR9xw7@a&iu8D2RYL7b2H(YS
zQt+eIJivS62ytBV#Aj8hj{6JeDjx?$8!C6j1pL=pOmLS8kM6Js#wHcu9td<-SuXdX
zm|KzSUE#@?M!NXjqOuXDHhq##iY$>Gt8#eLVbzzv?GnDtL-=jRz30l3QmNIa*1?$o
zLB@g6rk0==46c}@9RSt${0CqOTTTB%GU1(B*^$?fnXM&7Xg>&MYpbmjwMxsZV(K=?
zYAqcqg{aGp#hFFv<g+v1`InWAU{BzfwD*hjQEPeEeh*FXFK&9|HgI)u^e+6=aC%br
zLZOb0#Cfr}U&#A|Wh1u=^M0?IBBsNchb3=~Y<m6y?sfgqldUTN<~m##;i|&bi0d|7
zR!&Yvj{cXKla-T`Z4VstYxqU<NA@SqkA<TGx(^gKXoGR}H}DPS0k*lOKUEOj?Qjo+
zdqjMz>dQIB=0S17*)d3)>{CYzkPf<H@O=b;&`R21N+ha+Rfz1vNpP_-?6#`TaTU3<
zkhe|pj+4A?P(y$axTGw1Rp7G>zICAFd`2}ye?7{~Z!%wEH!!Fj+VX9FLI$x2MUdbL
zHH6yd$-LVLmems-2i7r6dP<UbhBNgoe&rx^eUVjPsQY8^o*WGLDnijGuOTZuIgR?D
z=T}p|S?wh8gqOdP@q^O=D9nM}i$Uj1sH>Ck8_J{ulknq*!$a2>TlG9W(=cRGUF=fR
zpQ9j8P)gT$VjVu$h7Ho8HeY0NHltH<gfNaGu3A5!YC|1@l(>ZJ%L*Tc&~N_^{@^R1
z$KnTR{$&*-LR(MqH*yOp$${7_9%3M$eS!B2TZh&T2&~heo<aFlrG>uHa&SY+c;}&4
z`mnacs+(?c$NMdPUEN{OYCV6s<9!k_2SaUoid?yg<9(BAT~6tPp7GJW=K!eoEdyA>
zR&~EO<Gp<*Cbgql+AqZq8ufjuHzeaw`8;3BT+I_c?YX+;Ru{!PJSbjf9Ea{)ZKGH!
zC>oJeoP?qSK%+?5>c!vLC_X3J2PjRs43_T-wV$k)E=T%*^sud(+%$C|1xDj={D96-
zZm?Z3)Ky)#pMDZm2VbIqszV`#*B~j-*4Bwb(P%b)Izf?acyn-Q>*%@>_ESYhXzNjR
z2k1v^$HZ$Q#=&O%7`UZBdgE4lOdXbg8ik1&p{_A54v5Tkae$M-ik;6MoQNv14{}=V
ziJqrRYsY$?uB!dE=cx|IPPp&QM)<J%bY`7tS3ljZD1Pjgpk0>(8)>CkXK+4ZL!iTu
zB0?STHYgH19Z*3Zs^fSn)8(MV@acG65?#-y;kqQ|CO(l;fJmzdo*?;1@qzlu%<PcK
zEq9by&)->M6`;p%#{C<(zYA9kS6`%U!S5mXwfgnT=%@c>nqTivR=@0iIVPb`zkYrD
z_4Bzx+>Ce3_i@qo0&zX(C`|34_e-_zd943O_X0UY_h8-`@-vxtI_@GH#Z?5PfST4m
zmjx*AjjA_`4-XrKZU!Hgqw!P%p)1DKJkXvG&=uqAf6W7Q#khLHJU~~(_a@8(bj7%`
zz)F0lkPmyB2k44%b&P(%5oz5}3HxHa{*VI|IZLt2NY5SoGVyes3jKUI4u@e1kD(sj
zG6PHGrohKW=dMAA#MQy*53Tgo)RZt`up~g|#CZ{cj#ZO#I&mr|KCyu~r;gZ(oOgjQ
zx>Orp>@vgLGBO{>)w50+*n9*|ky8eHc{z+jU9<U7MBGz&o>{jyXYaVWP2Qvj6$hej
zlP^4O!xtX6H3dI)Uc9Jw59h^FmitT&PW=oAr+(HH*a~&}Q_NS`K3%mHEx~Lo7>w$P
z!I`Om5&|f}^WGEXH5Eb+*=o|!G-)6XCd6sR*mT?>_NsWKyl7a(m|^^4?4}wvMZJj8
ztmjXhD<7BTBjma0g_|nSzN&b`3M#6ViXXee3AX^`t~Zlk=n!KDRkw4oi-zh<TwQI$
zuRVtIZ(Lm@37nk|1#oKBNY$F}rplU8Hu!QiTh~YZIj#nPl~@kzx;e*cKy-HKPCbl`
z!>j>#p%pYzZ7P?Z(JFR@8mS@aS#`lD7@N=GdLP%YpJ4prHygi|xDLP-z%>}xSX}4f
zvIb<JCToEEFO#=f1G04r@+n&e<nXaiU*CWMnFIO_7|`Dx&1U|lKA~3wlqpFXrWx-;
zX#c`K^s=F7OQ%@}bjpb}h_u<eQ4}(>QeFrcqhFkX@AT-CWIENW|H;rpLx$SlSqCgv
zk77HIUfyzG@r(kg0ZWtk3`jo!*otDb)P8amTm<sj20k4=lTQkyEyrO9TY*pqD67z0
zC_JV@9k(w})X6tno@@I8;Z+ldXCPWyLu&^#JK{Er$6$A=8G@j_2m*6=syzieTUXm3
zK(O@ZBxj&30u<baOGioX*$See7uQ$j<l`t#`GLSz-+#|b1TKV``XDw6xkUJ1q|$;|
z3!`b580HRF`wD~MK%7xBC5<XqT?^!Jcf1}h9fL$J3}RQv9K`OimudPyA#~5|klQ`A
zhY<=j@9gkoK*U#dGk-R0#S2gaTxc1w0|||*vFva;I3J}DdxSZ94AQyCbM!#dUUME4
zEauYI6JPMQ^(oWVmJV-Qf6G)D!DbhC%P~4ooNr_}7tk)2^9dMAE{{Xey=YX~2sSP<
zF}pm{ALr@cWEw>QdyD`YWz`K(pJH;Awvb$)3_^!HiBqIv6u$TIFX}*C&46;Tp(qi$
zUfz1lc?;t}zFT3w4<sd>)_TSZEwnb+y$x8b6C6XR8Dxe&lQ_ciP+kqg1kc|?gcxKw
zPCvhpi6)_biLGQZjOsWh8kuU8aP)#vuP=hAM<<KeFNHUl%0Mv(u2H{=sWilfY1&%&
z`n;`FUxF8HASW4}rdU{-w#f1NWG*dep|lk@EI$vKVxqtKGWI9UC(wt*c`^-auo2A1
zbGWqFq~3~D;1-@ZieC_4Dj$Jb3J3|c>F+iKHupik2o5X5IKfPSwE`l=uvQ2MSMzCN
zv7A>SYXQy>y2^?x^|;qho3G##Oa_9^%Ro@<jPleMXu$Btp64{X8ho=7JQPQVX&VFu
zF=hj#Z-6m#X}LOd8yRCbg>yok38|@Pa`F(DKy~;&9<f!?KXF;G9;Luf-g68lX`=?p
z>y9C<ZMvUSH&z4g#&o5pv~Ljt>^Tzz-dbt&DEZLLS|Ek5daX3@SnViLpGVZ~L%kxQ
z5bLdpH_BEx$s2aDOQF`fPbWjIb)T-}t~jUUDRqPO!k!0ZAbnNI2q<BCpe($_BVs)4
z@2)>JH=l=B^~|y7o8oLqww`;&i!SxSKT}G{_>lQWNdE@3L#=)dte#5&f%fA2X{L@7
z{*m&w7rxjr9(pyUgbQC_MSIN$0kFoUW{x_cT|??x+BR~Q_Z>5yVZTU~?>8;?$~-(s
zg=^mP%DmqrRsC$g91F&;#-E}Fy&ofG#|l0}2tARfh8$L{==U*J@0)>>?MRyXxUA;v
zk1C+-B<Wh8`u3w9OVvQ|m-MNRq1+CD>au?VEMcp^-~?2}k6};_0&@82Ymd#L73zFA
z#pDDc3{vw!I-Ee$_u6s{Ei4V^-B*G}(oQ&kVt!Lb`_n=_KF^3u%%2g?Xn)j6K?0ud
zmFGmHH2-IKF`N;u$Zn4!O|Rg4J+|bq>b#XM9Ts@#Fa^x(*-W&Frcy`{tl$rRgml=z
z75oO3^GELr-T|QLK-lU}zc6&b9K?xZc!p+stgG(5x5RoB*L%30Hov^*^%AZg`V`I&
zc7xr-nH$ISH5TXN0Cqfd{TS;;Or*B9x&i8Al6s4$F%(xA(vY1S)B~FkQ1mb<N3|4U
zViQhy!K20LQpth>%da?epm7t&_~*?-j<dCA(~QVqXj1=z#KUe15tvdLPMG>vc}<@v
zKI;_4hy7IcV52mx57n=?>Ttewn}w760`b<8e9X+S_Qs9`p0;gxouI-Q&}hhQkfWSu
z*Qu@8XVN}RUIFJ}GimrL(B3wonehX;PyZ0UV|z%@N5@aHFI69VPMyjbzrx)^2JrYI
z=pjRFfS!CG&zw#iQp$yVc%msG`8>bp0?+v+`Dr}vZR#zM8Cs@3xT|Q+LHfL|>u)TS
z^Sa)reXm0eU(($@za*n6usN2!DzF*CD!4fuRO(K=?EeE7yj8hbD@bRVVmj2Pi}3<R
zNs>q2)e;On@Qo|^LMYZ>-KB)weG#hfwr#n`!)JgYmnG*0CW%;izu9U_^5-?j-%NTI
zdm$vLA4n!?_eOp;bld_t?qONk5Ezkdl28;Y^p4?3CO?R%_qRXB4Z^aII5H6~`*8H`
zPu+y<uxv}z+X`Vf!t5>^+wBA&6Xx*+%=l66`Aw>TJ8RWcY{t-=;v)+QyHam;M63xn
z!2=_{hD3rv;sPd`&CDl*0nP1|xDCsJ1Sa7Fm_JPuj$#uePqXR9%kk`q)X<~a!(UK{
z`9(=c7js^20--@VU<D3ro}S9A!Y~MeNfr#BZ~H^Zf8O&edh#Fr>`_=6uV|;{(h<cO
zZ&9pP50FO;Zmw|Xb5%&*tS&)vGDkT);l;O=GQ#@u;%i2~h=$GxmyZMiTT92VGLV3)
z5hQS>_G?T<h8F4U=er}m=0R5B={0FT=sov*XS{!n@ijcF548B=@ipgxNj>p35C0ym
zl{5FF*^@;_=0a0utk8-~{b6B#&TpEIs7PRO2d3##r(;gn8m%8Z3(GurqveG&bcjvY
z10wizh|K_0p;i3>h|bWlKM1ig5gIzgW^YJ$9b)qtV*1GHPKb@r-|<Iz;%helqz5l>
zgqiYod`<Lz){a$C&p82f)JAHmMZLw>OwbNbTP?EVYxa^Bn)sS69Qdj6HBAiIk@%Y5
z-C-*NgE7X`Fkn=!rvK09i?7+=!5>z&ggO9?cH(O$FlECc=}>MSbK+~(Z{kuGXRWSo
z*up5&-Xc@DxOB%ifc*i$G_@qY=8=V_w*Q~wYkqMmi3NilmYqf3l}S%|E%7y%dCLD^
zjIa4&5VBs+CtoDK<|Z*L>`Hvi`wu2**q->B7BIV`VK2f6F%DX+G~D=_QDF=$iLa?x
zpaEg0N(a{%kV~HUnwOZAKE7r~BohXAZI42P4O~7Z!bY13D@H<@P3$nnW=X|JXmDNX
z=Y>+YiLn_1g+PnD-5g`{C+!imC6On_CM+Vr#MoTUgB6^xBsa!J$R;s1``+e|ZTm4c
zYyMCoMCCz{#&6Q4Hh`?gZ_=d>1T*mA1kwQ?_>_mE_<&D(%Y($&_@E3Lze$(6%sfbp
z%_&$PBPTh=<_w0?0LGE2F*f@$14_OfV{-%$9FOZ{T&Lr@7}rc(^|<EaN}dnU-(OaI
z&EDD-YWIyNzUG5_$<k(`Sc{ILPNzf0-1wTi{sNYk_?jD{_FS=h;%k;n94Yg4N_>s+
z_rvh27p1nb*`7a5{+AF>vZQRJy#`5*C$au0em(VQiHRr4D8P!;#FKoKk9!kO($0Gm
zPx1!u`)jk)3%GaI*iQn?v$!6`^&4C-<9ZX<&c~B{`yS~+JD%i+_w^D_k_khbjwkV*
zET&{{Jjpx1CJ+-((gmi_)2tIulJg(ze!@sf7f;fTvtMyeaGH3M=Ow52coI;%_jr;I
zy9^c*s3q|v&r6c+qezV>`N5tLbP$`nFP<a`ztnh=o09O8c#<QM@cSb1BvRw9#gjnp
ze`WC`%YKtOSK7fEcm9$LW#UP$1$Rl$q{Ne~eH?;C;z<q-8^N;M<4N{QMiKLpjpBdq
zCW<DWWZkd4D7x_^f}+He+|*>FXvdR4dTlSB<o+cRPcjET5bca7S&|%2k`&8<dCPWa
zq=_e4k`zy}q#`pZo+KMmyVrOUR_ex+ESZQ$PdrIB`o)Q9p?B4ZCs~pdPr@fRo`g?s
zJPDuNcoIIj@g#iOPCN<Q<%uUr3XH)-{ME*j<SoY8*yye4xL$b-=VRknA#EIf&%kvu
zu35NtLp({6y|jadH3S;?W%k(sCyhjw@OT#|vSb4yOYZ)Q%s`jpho-qlMTgnkJ{NT2
z^IM|1Y>vUH(V<pKWXa|jB1<~dx8Q@L1rL!W9qN4v8QILpk`6Txre)?pL+VgP<^dW~
zhdRwXKtt+KGt2`bOFGnb<^dW~hq_xozzn$AM3yWR4ZK6G*lf=tbnV@!Q$3L-S0II6
zvrg!`UB<vmCrgK#J<wjgUq=s6hq^=(==dyb9wDt&Gs2VTNmCM2p<?3q>QLX2f?Q4)
zK0b^Et59$XZHY>@<fz!U81vbo3Y;qTdZLI011LC^{#VDojP95?(gd2|o>J8WnslgF
zyn!a~NubGl2sC-GDYyx?EB&GbnwS?Q(Bxf-4|x}XChs-{-iA)O$po6bjfS1uJStto
z3|C+bA=<=-EYRK&Xzw7}B=}ARqD@Xii{R>=;a|2kU1I<!GP!72*_dHL6%MYifw!(h
z`Rz!XIs|TX=)es`sW5P3y##J_*nt~|PNd3^4-|9|ins!k-%v2<b;A0yPL<*0T&g@B
z>S0I}S#8uxs7QzUr6iz(P-Cz|djUFhkjwfC#GKghE7hOy`BBtJH(G}}9b5(sL--)k
z9En~5e+ne%0=0-<>7dSvf;xI-eI?wFfes0dDOWWb5Hv5b&d1JxpoaksevXRf66;&I
zCgEztbu6y)aXpA@Hm+aex(wHkaV^316~>=1-VDwNYQUqPodKIyv?_tsTwG0go?bT+
zkbdR2g=gYwF`|52H~Mo-rR!uUXc8yuYVQgR+j*7h`U=thG?3|tC`mND#jU<g!LC(-
zE&4@#KLK9oI6bxz7+E5Dh(eH%c6dL=tHM^}iq_6$9q_TKLRoUSd>-ahdQ<8Vh!U4T
zltX4<lEEndSiC3W)q0%$X&+bt`SdaNRASr<=qHhd*WgeWSBwOph|X*;0X+7$lz5Y?
zaj=e|0Vrd~o7|lgbdxUL<ZSX5tt)hX!`)P_ny&OXgN=nZDc(dcTQH?(S4I$TGPK-K
zl-&50#GCxjB5zymc#}txVrzCb-UO2mRtQeK$!TIo%G0CQ6K^sO(}zQ@)OeGBBDyhc
zyvav96>nnpA2R;Rr~2O^>l@SCFi}b*0*%1#$2q#j1%35L1AG025yTY6*%tp|ob~cV
zn5Il@zkoB6W_pAp!jZwl^k6@ZJ;4RLCyvGNmm9ybpNU_2Iw^kT9+}P(YJ#M4MZ!sL
zK2yE%E27Su_!XH=K5zVrOgAQeMS$#F{K~2_@`pEm<$kRBdd9E(9jQP#P5esdJvIc&
znMY}?;?in|@hc<U_?6qgM=_y<=;PIBd9veI3Q(~dzjBg1?M(d2bU6Uu#IKa~9>4P3
z0y0mU_?3Bg30IIwq+?9{iqPGOU->sQDlI4N_?3ErmnMEC`)3*+iIft*f^!fw@pd_W
zWiM?=cmM#KXNl;CSS=liMu^;6i!X!Prs6TiRP5N#Yan71Du`EgWXenEQ?DaQo0DC8
zyDs%mYAF|95#c=t9aNhN-1wDtr0KW2AL>zu`@Y1lT=Bb<5^g@Fj0*Oe4|eP&eq|r;
zI|47%ktTlS$9H&Ts2#s@x#CR9k;4Hk@hh)&Wm~%(zj7zG_<7<sJn<_vw|bVLLGTya
zO~oiFex(WDjnVNdpI&D#L({~s{OYIVLQK`^<5wm<Qv#}ft??_jEKH(<Cw}GoQPN?9
zj$aAf=3S1v@hd_HiC@`_ZQK&a(=&eMqLn4q4{-f2u8{fVJ+C`(8CI7c!yjfppN?9=
zhoG>b%tWo&dwL<qQa0=9s1?L?Flt4qN}QM5{y(C6$ri23Ti71NMX&_aIkU-&=yuBF
zgH=fvrn7NnV`{I~@xxLU9#ouzm??1xRdIxwB+AwQe8|Q^vyw2W8*yl2S8J&qr-IE#
zUA9)<=78v;9#2OBbig)MwUK-k&kA+`llJR%w2B?0l7=2%dAv%?j^kBs2Z2EWv<V-Y
zW4sEy&7m!fSHTzIu>TMGafh07XZm=RNq9MJyvq0Z0!GC*AztOFP3R?$a~~Ze{JHb-
zDmgy_q%SjGCHpOOhI}qzr{h(&yzRuR9DoM*7O!&C&1ixrUgfCCJ&0q|$M^$wC0?cI
z^Tn$?CrckEUgZXP>=CchisWRDN{&}C`>6v7>}|KWjU+Mmy28HV28aBR^8jQQH3qi3
zdHT#hVG1yjkr!baw<9BuH*UtBo2T=dIADx(XEW4bQ557n00%(zUCjVX*y`R{wnVj^
zJ2rirq4RssPiS6Un>OC+*UNfzku#t7cAmmHM}St)njnlmm%sO%zZkPp-EKNhVe73)
zGm^*OyA~Yi%t(I%F^vNy$=^HsN1&hhdoQ|L1A@QTK2PENrDk33|2oc7SSz(tm)Xs}
z-d61fwEc-5U+*s)NiyT>ol7B<#@8z(6JPJhA2=j?3@j!)>|_^w>Uj#y&xz)uzOM5W
zc!;uA3wt?FVLu=^6xY$XCgM63*SWYZ#dQrXdyX~w2I7Cj-@Cuf&AatHg>NCe(W7j7
z{Jo!rJR+eDo#l!I*WbH#F<4ssy|-Q^fIQ!9H~2FQOY8Vw=sblP2olu`6a%m4c?x?9
zrs>X8Xur-Z=y&2gg^wOXQ>lr4x#uZ7JU@x>kR|qc3iECv;f=HDl6k;JtCNr=?s*EU
z{|&;+c?tzrCKKK^f4S>3S^pGa&~Tk(PXGE+&r`5o(EjhWw*PyV&Qo|2V4lVGD6Ze&
zdKuT7xW0h@yFpmm@qdGFjH=z+c?yNY#9o)=|DH=Aw*MP_r5ClX|NF)5_`hH1)&DIy
zz5BnHZSOpVA7hMY<AZaa!c~&goB#VOK2PD`B>cqx{X9mQHo@||hcDv)7K-ee|NE;v
zPhr{3spH*tF5h_r8Orv5gS)i(Eag0f$1vWt|GUPF_ucRRPDat||E~9lq;)rXQFQ&^
zKBB1o-<R4b+WzkyoTqUAE872!A2DhC_dErv(Xc8-DYR)Q)aOKa{NFg<#dYLE$N!4`
z-!H@ejozA$>y>rzf8$pnZ5)2jz;!aNS-5tC|9dCSQ@H$fnRmwH2NsNP`gsbMBR*fx
z9kd_*_dEr-r@!&%Dcp64xSHW{-0^t|xexF9c?v^yebk?K@jQip9xRw^ReHfmua;Q*
z<2oMK4{?paH5J!=xUR&t5Z6Vxns7aY>nrqUZ~r`n*6+FwRR6q%kbBAJDg5XWuc_WX
zPvN46IMi%Y{r1jN_}`JT%LpbJy02f8r{2#~XkX8XuJ`j4euno`&QsV+5TsY0y4omI
zq@I4zs|)o!PvJB`LAlR=p28ltdx>ECx6hSoY$BxdZ}&V;;ek^<ej>~`J33Ecs04q&
z75tU?w?Dqk+g97ZJ=58$L)p5s{_Vxd=P8^fVIe*J+uJ=)VVmp?KxoVEJx`(4fc5yH
zQ|tw<KiWP|;icc1i6-ehg`lL`{^)Pac?!qi%PGnJ=zOffditZkgH)<OJ<n6PGipQl
z!sjVujPUxS7Y*l=?T>B*g04S$i9GF$Kl<gRlo>ldPhrB<)Vb66qdT=x1C8IQ^AtY#
z0pX?bN7ur~!$^!Y{^+mbJcYpbJR-)pqJ^a$d$9ILyXPr<w+UUJ?EBygZh0;u)c&cZ
z-25WuZ~r`ntLF8n!+l@;(QnL6DdFZz{ZICqFZP(U=P87}?+CoK{^+An%#B~N{n2x<
z&B&eP#2<a~>$|}povq!cwh7nckA5B7*BwjMli)8|yruY~SHF&Bp`531**W&Ia1eq-
zQqEHtBwXFAKYHEU)ak!ge{|v+LEol>#~=OTm88Q4?T>zJrgwSl`lE#o;*Y-gY(s~h
z{^<W~EU_}s)MIh&X?}Un>kwSFtatc*H=n0)=AtkEJcU0$&*npE+U4^UeuoV#N#`jX
zHxjhBebr|CeD(fmcYk%LqvwA1FnsKv>pX=Gb?N=ny`HD=d%l2C@=fqh@4oXCrdOj+
zzf}J;H#B`Q|McfPPhsOFXoAN-{o`T6rjDmqk7{TB;7q&==P9(E>+J7O$A9*D3KJ0f
z1Ut5Up2EL=t5u$q^AwInsbr3Fur}jM{8PKfKmBv#<Ll|4o_Q%Htnp8ub{WX$Y(8}T
z(=Bv+i+?(!%9gNS)IWW}(>=P#>7U;G(~&&TYA5{D`?c75xj0>SeLwQqGm~a0kAHd;
z29YyE?O8+m^*rzYfkx0z{L{-%(||ntkq=mI7ODPuU(<f%TLgnI!AE_Fc3s*NyT?bp
zWd_M+eAF8#h#a!H`;mog;-j8l>5%O)SSEV+QJ>o(+Kl?T_9K_3`lwU)BR>^`u7T?{
zT<_xAjLQPj199z(%cFnT{^>WKGTgjd{nJ0XB8jCv{^|3kdqhGBC9ES7T>td!N5RtK
zpZ-_50NQQ-X&u<#r4EBz-s7MCM(#&m@Gr58&&H2FPkop6BL@NIEL^3yj>a_|*HyT7
z-XHt(i=_)~e{2jrn${od?nj=TE9O71KekGM7=LUvK&1F%>;BxkKlUuiOSd2S1j*^$
zA1jgey`69WeTk;AZG5sH`2<Po%^&*}???X74kZyAr1)chElD<hU&J3P6xlU@tc28m
zMd#a()ILgE=wq(5{ju2>kt>Zq_Py^zu+TD+vLE@bKR~dEKX&01BUpC3KQ>aGB>O!6
z*o!VCiY7#4QWA=;KUPo_f9!|fvr)ADv5;Qd+mAe^Q~a^H_>m=j?tk|qV?Iyz$9|*s
zBj593iS>ugCDuo{X5juw{LaSpH(c-GdJR_=dUH4UW53XT<l$X110_BoLw)1-BOis6
z3|-IcfA=E?{x9!GUYH|}PiMdIcK0JU<51XL-j95Uu8~gLUE7cRdbXer^-}gDpR*t4
zBE28^EsW(QxYpq+_^8Bc#qYmxjmNzY*Acir#q+`VJqg!W=)diCKl0Ka(`uc%ANep)
z+}N@qU$?&>`Tcy+{xpys???XhOwcQNKXTK2<H||dk391!&X7Cak6ecLd)bdX0$E>h
zKk`x4UVFanug%55yskYzoxir{e&ntrJ<b#?h<f;I^|Hm;k9^mjhN54Yzjm)nylu7p
zwM7yOWBaCmi^&#B*XKU}9;&BzKl0Oim_`Af_x$_q?ngf5HgZ53f9)>pN51}aS>Jr&
z{m9=An(*aa+mAf@5i^~M|JUA+{Lmk~1MeHNANd%p@KXH01Jn9{kqQP+<NuvD&4%!W
z_akTcwJ}tm)w&4oDv$pc2zva#^0ZU_-(Qi@cDx^X!c;O(I{)uE+F!eq`;k95jquX>
zf6wjJ|NE8gM=lxRkz2+I?ATjV_apCl0lI#N{@)MIPbuZXE295*`}>hkI49+8uYXzm
zzYm>}Qo@DLMU#s5nh(*|%YNjuyzdCSwEo{r6zl2#-H;UXqW!;!HQ43-$l2OmX|I&M
z{@)7EGW1FCmn;@j{J-(_SSf4&?*w}pn$G_#T;03>H=`6({d)bsXA1f@9lZYEa?)Xg
z@&8tOEe5XtSLmSqzvB%Z()fR^QY!;ZJr>uV=9l-p4#Abi|GOLZBd>TMc|Y=sQ`w%~
zvmbe{#cb>@>_>j)H{`2t@P6dEyJ<gi2aX#`cYc1a`;q^`7ceTm3I5*Qw;#EVn|HrV
ze{U_%=KW&+-p{!o`NNaZ1dqS>zJYk|F=09L1?`Kw;P1Wg^X*4IFG{_|@%Ijr#~%BU
z&p>iAM<x4v?fuhD5Qfgz<9Sbgy_q*zVpOiiR1kWc&zW_3(9=RsoQwMm$(zCna4w(u
z4+UEr?#IbW-S~%+tv5YjKX9Hbvdfef%N?9NAXn3ccpK*!_J|jg@2ksx$tPEMwccwp
zq^8j0tTq#$h9XKtFGJi_XEHmG$eBj4au7}AcH*>rBTqey-jY|#3?A90@BuE!Z5}8D
zq1J^tX<TrVe_jCrz&S`$ab9>bzJ<`mFE`<oxK4bZ7oT#%$6>Ory$}aFbQdpt(1*#4
zAC|&L?%&<a!`QOhpVy=aEzhe^ADXnkFpcLA;ViCgCXMSr``!MX@-DQ*aMcF=u^4<u
zr8N)-GO{%shpG}n94GCVkLKjvf!Ww>4PT8m*;~U8G_FhIddDPR%E=t3dVK_Dc5Kb-
zzbAdfGt{sh(E(6>=EDF>*y`q^?a8fg`ztu*SohGfzNOZSxZcIJ6_>|<$o-*gkT6e1
zU4bx;FiX!}?(;!#XB-**2=U_jea&D4@xE%f5fj??K?T>H!~^H(Ampba<j@o~UMQLu
zQW@;WK&PDik7!*FZ}=M%ARs?GH)mgzkPoL8*ZGk!t$zD-wpO`xPI&0NM7tqvCBj4J
zXqim9R3bL1nG}MKKhptF9e)*I30oa7#-?*U8&uUbP8jwE#Bt*5a4N=cY-t|Gheyel
zILxn!EG=M%k_tFsaYQ9P<P_*y-o{hoqjzSI|8Y1*LY;t9xMGL!V|OMqa%aZn%v6mz
zTwSL*Wqv#TaS*n+?XW){{13VLOX`mcJs(Lr0Ea-?eE+Reg^X$X<FgYz{n3Wbar?so
zP#u2-{Xy93)}y}E{`f<m-umOCEVn<BPVqPWVd8T_%^V+@{ziQepb^d){>GO?L_iu+
z>{@dQWGwPtSX>U5i1l?$7+qSF@k0~ww_FxK)<e>DI5{eHOF6}&PyH@HlA0)<=t&@{
z9*Php4uI-M{spjvt;QW`lN6tX0)V0Vptgx4%EgNvxt&-#5}K@w({&PR9&m|y;(lzM
z**o9b(k2ft*mD9mq8@-w*7E|VElMR)&61CjXCBq!3LgMX=69UWk%6y5u|azG;-PXZ
z)F+%5>^dy{X>KEwgr86rC)13Y<Nc`eaW~*oB$x+TwMg>Iu|3)TRAVj<XcTv(n)5Fi
zFO4lXoPcRXzCc}Ehf}xhuC3drx&&MUGjvs=VTFurwHlFU_?`wp=m{97&{;8x%+?0G
zHlcv<ip-41h!pKYIev6rf3Ooxbg=mN1AEls#jwoXGC6XMoFq#H8o$jYWYx@8gy~bh
z;8zT}Pii}SmokNUzxy`yc9-vN^6=fc+RK?Vlr`TS^<B?UE&vk(H*;>51EAXX5Wo_)
zdU~YIcjHNGlwCl)jDVHz1U4}NAGd;-g_ORDa@D8}P!L2Ado>fyfrek4`A%qT<~z|u
z<XfN8;r4jzIo~xi|2)yj1l}$`lLNf)QlH8Go_yFNPRA$s@R1lCfR$aLPP##)k9_%{
z3Tn!+_VYG;wyPVvoKP;f4ToJ8^NZ3*+cs`3+nL<I^8@jA?vsKVj7cfGQWe=?KEo@}
zlJe|lYRbCE2s`OhU1WdznIC5U496@MqQ(SHG{MH5z^4Y2t-$1mNGI3?Fu}*gf_T4b
z>$tzx(ptz<MA0_vw}q@hMf{>FT5C@4oD7>IW~ipXC;aFSUdzKUz|pq)wAA5t?#BTB
z2>^dQZn*$`6C{LhV?BOspz7E4hHhI>5Gvno_H!4&ZUNT(>{%DT+%XTYp$y7lj@MY;
zN=P``YIbfv(vnBWh`Pto1#Kl?Qa9PDo0y8}A9`vn_ne&uB&Y|eUqG|tOde-zR8&8W
zixXs<{c;;$o*!t7VOttLPBt!(%WQr+Lu%Zhvp1X%$>@IRD2d<o{NoFawdxK;=S8Y=
z!}wUYZ+<YZsVtj71Nq^Jxq6S5OI50A`U6popBXnu&u{;Tszc41(~%D!db2g#!y)(V
z89s1Q&*=zb7N0@f?*z|uw5<eUK}%LlM-G7M1s?z`VXFtfZHomxxuk8ctdB4W`QbuN
znk_u`!`|XY|Mm{M_4A)^^h4|r(!Q|WbiUEPCnk}~6F(ZCKvEeC*Gr(A8wlxs&n6xM
zsU&{1;cyMebH35C{}^|}*K)p5xqNQnONbqPZ&DJ;Jh7usjwi`X?C3q;@siAq9Tk#E
z?C2>&9g=N7cJ!{j#1i_ooo}=-ZpLF>FXtP5T2N~FfMfx#gK-^!Ydo%#ah;AUNgp%k
zn_<M9_p#yT-5Ni7(sz^k#}hxg|2WU+x4_?=$y2{)GxqmjX^9_w_%H#q+u}zTLyd*@
zqi(*!ULza*z}R#7DRCOSu>v1`JTXmozEQs;#dX7Jq79N5^3ZHc$7aQpBPeCD$E9Tf
zDn!9A`+TFnmnIS3bH362$FVskc<o2%1%oTZu6w>wa}0!+^No%^G@0<<fb)&o_9?Zx
zi=(UYqvL6J>3pMK0?co5-Hxjf*JHSz!nO19w3EjQOWX0ZzX0F31`vL_UAi6iC@44j
z`#xhgiuR7VHjD#B<S^140b=553jsn$LOJIf9UAUEp0=OlrHiNicN5?0J)Txh^XV;~
zc8`A<EW~^$@w88Uz$80fHTC;GU-9`yng90UC-JlgCgJx*;%S8<yB1ITRi1D3Pwm{Z
zS6`lZ+CLvnt~BwqKRuSxM;5Rc@3-_ddRq0&-(tK=JZ<10Gv0T5Jngt-6g}~@g9Sw+
zk~)v^qUgrc3W^d>dtZ@_;&V`hF>i1q_V(gw=N(9a(ReO?Wa;_e^Nsppx=N0xU6%ZP
zpRf0Pqxk;lumei10D5dO?g!#`HJ<mw@3FWJ$8{R6-4IWU`93Z?g#vLu#ypG){8r8T
zr7+uu>Xq|VABC^_OgTj6ogw)7KXATLt}PWsq5JRoMl>~;&-iRbU>Z#at0v`ij)H+f
zJ~aUa4;(OYM5v2j@WIzuM10E^d=l~np9H?(gG0LU1)sqKIc+0Yt)pquKpfzXFY(|L
z6|l-+DIbrN7Y(ZzGpwp3T(zkNZh*LY(fcVK`Nlm;>QCuxs=x<us^a=k@JiMEIsxZ@
zuJetCPv7<PjmmU=43*u*^NqH>CYWop+k$Tum0F)+eC~_ib8rpBH3rvBxK6=UhpQA<
zHLfVGuP{D#`{x_Iw^bA}QEk$lZ?r^$+o<=@T=jP<{WwABQ5=r#hKg?Qe4|#_7`T?u
z=NoO2C%A{=<v1dJE7U@MO<iGOg5!_IRH%M(V07>28$FKqQ_eTKW;$b&?7dH5?oPF*
zU}x)UJ<m6qMZ3q&oNsjBC~y3e9WVRf+g>81i<j+rzR~JFp13ni<UQhL^)k(gmo3}k
zcF$My{hrft_>&v!Wyj05Z1lEuXX9lTC!cRL3)X#@HHCq^@v_@J-{=516w=1aJ_gUB
z*#1Y+^MFMM*7k#iPk9oO$1E=ET^&#01IK~Jqbk*V7i+LPbH34@@7U@$$HXsS!DgMm
ze2b|vQlMyjW6n1^{VnsIvpP6>@r|MJY7Ew3J<m5fAE{u-H1Vx}{x&&6Vx`gC2dROI
zLJiN{|6}iZ;H#Ye|J_=(YHVc~Mk}MGKcdiA`PQbZNn?x2pAc$hLfBM(P3kswyG9{}
z5c0n$)RIbnXdx6KzQZDVvWwBuWNp9q=X0L(Jm<OhKKI_OTk?9@>vi@#&w0){_dMsE
z&*yy3=kq?FLn;iQ4&Lz$iE(GGr>Bfm7~JqfG?|#^?R0`p*gS7%Elh$YzV%sD(8RZX
z!B3Sie)G9`>%k)40gI?XhY1M1$GHvnRfw;|0Tj!#wO#BRKD2+ME4tFMV2kK@-juNg
z1#QmJ5`|I&wQrJtqeHm70QlC2^zx{Ye9qfB5dMuuM=LBw8UBjDq68YRrhlVrPlyTw
z-+GpBDubRdqocgw{*CVM<o6q9e#W=%J=Q0M`JU<PYuoo2jyCw#7u7smUO;?n=VX=V
zN&iM0zE*i2<6Ezv5dnN_>dCyClPgyR-@4~SMN{>48fmJe-SBQ${Mf>f-|I81Tp8c$
z=^&Sd0r0Iod$F;_?!28hx|2-*x8hrqh1pZKgMx4U{RC=<N`Y_vtc$ulHu0_84vcSg
zwb$FhAK$vETe@Q_!jbsgo%)sTDYQV4x?#HN<HNGwkWM-jC+}cOL~e~dc}IHVtR(Rl
z2O=Sr5O49+hn~dAJC)k_%K$`qg=Ql<^spDWo_?Gts%oC+iC@wBW%LoYHyFc^9-Xr-
z&(l87o%;(oo@*7jEOe~=V>o5zm+XR8bfjfjZq+btGrLiagny&=FGX!f0Tu_g!8^b%
z{h{IS_it1c+P_iM92zj*_?7bfot5(Zot5VKJN4ZI<6Yl)40Qgg6ARwlxE5=uoq3A!
zY9CMrbi~1cceVF#v<;l$shE*N9KGLl<G|#y%w3?D68=wy;+cFG?TO7PD@(>Jt)wH~
zi`a|=PprFa5M|IKV%#MI=~0xD6NlNoq`wjYldQX>J4Il|FY9II6hDxL2rZR%A(iyy
zcU1N;50{zkDWj55Bg%$IDh8315Oo`hizfUV@$F5JuH7Yl5UaoY8Q?zs6Qb!8_?;N0
zuYJeE)Ig33sy5~i5?A&C?>aC%yle5b7QAaueuQp?Rybr`)^f_Sc534gZ5>fYtu6IE
z`0=hcE>Wf6g9`6Dr#B`y9q;<bdRlB)@vhPDi8vMSdZ-?!;$4pxago5gp4`QE(wBJG
zmKe;2c}h#c$TsbQ0K<q$KkWrf`iysdxUHP*RJ`jer=~mBAbgJS6M{0I8TcQ8`H2YL
z^|x_h;4AxA@G?)qyW)InD@Mx~?@C9q?;GB=LRjylP@&*mA3v7bSvL#ZMI6Lv=X#@^
zQ#PZW8SmP&jcn)U<6Y@^<0j)>XR?Z_X?WKew};Um^WWW%{b7f9JtNg_+#iyx^hXUk
z$LtRi@0#=}`h)SVPqf~z{b7%HZOMv0(H{o|-gR4NOOrChfEVQ2vZJX<b-e52XkT;v
zVB%e;|AZ!Gyz6<bWRt3RSK6_Cu;X3Jqg{33;$4ZSn0Qxu3K#FXhUrD(UFkPN;$633
zS4o8NuB#>0f<6?ys~<15#k-Q@m`LDV#|SH=g|&)tmyx89@(CD(=D0KQuIrz}xMRHQ
zr!C~T`xo!J6jP54-nE?YuGbAS@UG>AcO5RDn~irZC%o%GS<GInCV_YDC7&7Z%1N?h
z)L$aWS@Jo8c-L|(-t~@6Jk}-Nl|ER(yN-}=L*QMhQ0?s;1MgZ+c-L3u^8v)WzI>dD
zcYRzu?N7XGCk5}C=gCUQa|cAcigq;-udcniqN|yR*9(*VCnU&LK)iOvLBPg@6n6v|
z12YUdYRW{s=I;PwV8rXPMp9iS8JIUK;?-OqLEHE?P7`P<-u3cjLUj#Ye^}>vR>N<p
zf_L3_f2k)OV`(S_@9H>=8cNrAeUDZPgm+Duf`($e>x>3&D3{_dRl&RdP5x4c?k~*i
z&Z8{NreI#*YfsIlV_xT@4b5gVF|XWgjCs9muhDG5F|YTgvv%}v^Oriq7xU`tFZI`f
z>5h7YHmK+k2*)GzLO2Uy2!gWylm1fo58icnlBI7HylamHh4vFVP~Z6DU909{NHgAb
z<zH6XUn}*ow0<RfeZAJC^E{=$)IWe45LOVAe>m%bc8%g#1Kp|M<=LK)B9yR^JHHZ6
zgWRNWufuuZ*wc$WoeAU4140rwn^k8s&gKPN1io{h{G}G77&pQ#2%`~ZB0P!EbbM#Q
zq1=TM-}x4LG$6jy^p~1h&NH}*?>vDE(ea&qQG^e^(|MIWzOyU83xw~C=QsBF&Y=EM
zJ4>XHiSPWFA)gX6;EV4(!2VJ@F!@VN1LHeSw$!gV_|AWrzto1qER03LcW!P+qf%Go
zlpg}dVh9x`zSHpx7z^V&NAK1dOT_V=ms_i-;5$#@D(d*oL`xM-d?#0t@tte_kX4lU
z&Jg}mN1e;~&i=UYQtMxTscpcnt@zG^%3tcn!Rd}~Gt(U>pvNA@{m;060pTx%BN5jI
zp*KPV@SPU>rFWfkCsg6yc%FSK0h(Z>XQivS(m;AvVg?$K#WPTMTmZDt7PW9VN}W4*
z+=W)9=dD<!;<@@ZdU&U$c)$w7t91dQn%-PW4?m$7=wT>590I!(Jq)0S6#d~;dbm)3
zIDsDW^oJyRn4mwjqlY=-0cN?K*q=yHo0-v~ItG7aoyWiaQvcEZQb#W&ks%R=G64z=
z>MynQ$_V&N-T5m2A_<lI<}dXnQINEjcUvdSkY(pO+7C&0YzIBZ;Oa!!jr-$p9fQyp
z;VOh~2*VJ@Asj$FDB-_>P#_7o_j`E|uFG=k0h+7P#{7p+FeG&ltqHdcHQEveyGdAE
zaDS=G02gFn9~BbXU+M=fFn3%1rCxFx8Bu|B@bQ;AkPo2_?JqS6`EC5A?(GvrC=3AH
z@bwh~@kBEQ?IVs6Fc4lJxV*I9(A`hy?gzA|{~!z<w*gv4;y>qDK(K-EpZ@+**H=c9
zH4>9Hu!&d@`Qbl({H5lv)LRrket__w@bP1QD>{@U3~iwW>-r+a!oE5_wUKsbW8L34
zi2yACE2Uy-gGCK{BEn-D6nOPC`2eqn)gN}Zx6RQWL<<JOe+KoJdfb^L4+4TtEmxg}
z;#_z1aul`G_Q7B3kSJc?7|up&0SR^I*6Z$;*i8?)TZ%0{4L=8m7bU9-yMa>ZTjG~Q
zXKQ<QH_%Cjh^CKcP(3{3z<(0J@%7cqX#1OjE7ixBd0yr*m^-O)UuP1NgeU!_p2d(`
zNq7g1ztmP(;aUBqZbOVep7c<l!qFB1@T8;QCCbE;E&?420X`I-w5N$D-GqZ|Og!mr
z`~;@K@YY;Z$HbG~!%t1YlRkSc4YbhyQV(ftAl(ywl}F8Hk5k8!zSD{~$<iPJHM{Dr
zD<t1Y@qF0C;G(_)E%_@XD#2{KPzl&|yP|>03xFpb)LN8Bs~jIZ=>hYXny^LTTSA@U
zizkH_9`gNy@qAb{y3}x+CBQiNZ|Gk{s-J)INoBrIp;AKlOWp31TP>gQqzf>ES!!XH
z&$TSGeUIU2gD1UI&7;$Es{efP$ySwzuBH)=4;u50u4ZRPJuf3xJL<X!;7K>fSXRmk
zp7f=98dCZ)v<%~mh8p0CP`{ga(t(?>Qf549KTR$}4@KoL)3v6W)38g+(Y|TP#tb_=
zY0Plem}1aR%SbGZ+Od`=4#Jn_c`_37+)+Cg88L{!^HXAK@uVj{0wAh8%AFG<T*`ey
zW(W;GZTc7iJ`z%as~8y36Y~l4DIISZaL|HiZG$i?O8caOCw=-aY6o4rUa}YMU}y}C
z0`j>X7*E=JyHrI2^NA_CyHFLbg<RL^;&jI;2-hK;tzYS$!i5ONV3*_F<<<As3lwP)
zO01J8Qn`6v^V>WxP^8#1-wPh5H0=Sny4~>{wU^j3{lFgjp2+x1{SlrGF&P6rNgn$q
z!J|}NMLG-+q&2NR13xIG@+#iV4Ie4^fHjH3U=*w;Aig#;8&X`>LF_MeZfJk0S5GHF
z0IOt)A1#;o(Q*?%x;#2Cel!u81L8+LlmVoFFyKe+{iQY)KkD2C`q`iO(Lv-5xOw<d
z;V+f(qsKuyx5JOFsl_KK_|aRJ;@NM)GUf~77W;r7T@~K>m|169@S_b_jgg4sgC8A?
zRMrs{7(dGOMZL}CjkKr09#o6%HSmu_e70WlS#mr{(-dqJ<bM);w(tp)&yp`G>ELLT
zZhX{TcOq>+G>>-HAH<Y&@KH(~F<ExnX=KeWeHsN)soJKklEdn*jc5sGY42EYUQaaS
zqJEh%MJMwEIA|PJLGV=vSTZ}$jB`g3<Ug(ggeKI$vD4Dypm9=Dh=MX>A)fQCJCha>
zp7x&TX<4zQ`tO);W5t><&Y`qdy{kCRQPfhbiP5N*%AMp>xdcyi3nwJL1W~yJQMnzo
zKBR#p^Tu?`#7Yx8sA~J=#@z<5RJCZl>Q<htI9i{R3sqW2fx{BVrKX6@(e7XnDZ7Bf
za|_<S0YJ9?JsGhru;8Fib7!DD{1kk!#9`-eyvGTkcZ)1!OmMfYPC>cwt5pakTS5g^
zK#h&?$d}92Ms`%222Fzg{RNHrBTf8$jt(@>hI_zK&(MfrWkM3FS)<KAfhK}jw5+qn
zJv|fRAYyg*TM6!TEPC;j=mx0VS>wq{c4sE=jfFdsU0(i~;{n3c$=Dj>L!!F;rQ=&Y
zrSNoWcnGF@G=Xa=-9-E28Z3_P^dB^S&sV<neWrrRmF{D6XdNpS^C@~FS$SNI@?`oO
zl=K!Pp~z&U_x(NH4`f*Hmtr@hiYHpS{<ci@S^5imvLSGL(tBHfVY9^$#_$LWKjHby
zf}gmPwYPPy331GMY9;4^!U5&x*1EC3rWkgf6B*+mB|O937bLu&{$#cxB|HT`vFbNP
z!h2>Xm=DNDI9D<X$iM3@@E^uc<Y2QJxeQhOg}uTc7%aE{7Jp$W=nk<aX4h&LqHRE>
z@bMWNKV=4*r#Jgq_R1#niYCL3d-B;pO-A?z*<=Rv0Zmq3XK6A8J5g3cO{QZf#{RB0
znNfgfGR96ES7|g^aO}kTYj`E_xA_Y@tzI^zjlZyNs9;|NC&Dm<s}RN@OhC9BL6R`j
zo9Qp?MlKgxnuz)fJ5pFD<&akJ6F>i=%%>aCSu_p!`U~4Q7v0YIi95gI{xPsq`--2C
z{=)L0-4hH+Zx4MvqxcJJ!8Hx!FYL>0x`M0;{=#<crm1|t`wM$wmxVCEOVasQW3@u;
zG%{Ar!+%A?3*TlIe_=0dN5iwfu$Et18(ylDE&RV?U<#9LR^;#`E6I0DU_41e9$WM3
zMoT=&KKTp#5XF3nuo_`8!Vd_)A~YROa<rF+w8WF#fN>KLPh$EDi+z|?#Uy@9e_@|h
zQz1H@L_=Ts;7NA%x5txw$?pQ;N#5o+_IMJsw(Czje_`KY$O>g1`8yT<!Z?bwx8&y8
z7f*74{e|6Xsb3moM6IKxe$By?aEttN{Dr;pn=ie~^LMB2paG@hNv^}_BH7vZ{N0o%
zLGO$wIs7x7-Xo4DX=kmXf+yLkDJ<!opVTUvcoME6<4JDaEUPH-Bq98Ty>SEMN$$mk
z77)5e@%*A=#1jk}XcKof>9H%)(^v{=i|ME$BMmYg;Vwoaj++gh#<1O>cTo@dloRFJ
zb869X;?cD_8rg7;1|BO0roq7P*Z~SxfAsXClVlY#qFi--%sNCPlTinF7;;o!$y1_m
zX+Em(9Odcy!oJGW&4s*3%MdAx3X_$0;|o<+=$91f-{p@dIjH=Fr4+!=DSE32;m7NN
z`^2>lap&QB9m1suE`$i+NyuItroXU>H}kwR6c<_$dRh<yq)|ta)My`IErw@8k<@6f
zFp8wH8Yq$)Z8iKS(;J{jYP6}0B55QPNsacr{xE<Zmgx^bk<@5E>kmMY)MyUIiZoUy
z(ZgZ-0~WY7+Ueo}D3V4UMe={V4yn<W|E_cGfBl6y_m(<oTgO4~FYJXfk_W=`7uFw;
zNjh7%M!Qw|BP%?e@U=DC)f_>y^9k&jA(j*vuGNW9wQL(!KmY;uYn!e06~9Lot9|qr
z_RGCob0JDkA3i4C(F0)!f(PL&gi#2uA>4`ZEW#}avk_Jx96)?XaDQRtaAv`_dtNEe
z1Q+i837k|wXF%3~TCL&;)s>3jFO1Qv^0-x4hA~;xVvYrC$pbG&0eg^{oD<D@gsit-
z{pme^viBGEC3{=8_ZQ|yejk5f7jp&4*iN!qFRJrl7HqA*zp%4W3evgLdvWhc0bgGa
z1;UG9r>%*hka&^#?4ngRLLj_|zrV2A%M`mSTFMVE;^QwYX@S{22L>;4_dDvhO1#J_
zuUv$;hIH^EcX;@CktJ4tVQ0_RKMHLZw!g4nj<msx?3=%^a=lmu*WsftF!3GTbbQD0
z+!zwyVfYKHrY0gDL``(i_zOD`G;PIq#6Uvx$9MEZECyr%d`IdUSpwn6n&mI-w^=H_
z<3WCs_>Lk}(8PB<&reOkcf89=^w9podVEbX_ZAjLfeJG59ovLb10UZce_>x&Qh5RJ
z9i!l6hmcLQ>hQsL90-45r!7%fjIMg-A#LcJ3lh)>iodW=m!s?b%w?v&L*P3W_@*+;
zOQG_D`wMHtB;oTLW`4$Z+_=~$h4~)bx?an&eb0-JR8o{99o93n41t>l<T*;s!{r6^
z7q;dNmFG!($A;}H&trVYf1DA(chr7oS-C3sj`zP(mW2y2zVHox_>S2hW97>Dj?34{
zW#OS%uKD0Q8osAdXnP*+w(+dh#i0M&@Eu-ZG?c1R1>dpeOKOKo;V<mj|EbGk6W_t@
z!1#^}-__fJjE7cyM-)D@J;Gpw<Mk`uQ|OH#c|BeA@nON+6S8(+{DqYQXSu)qh0S9m
zWhDHCeFcc3#a~$0N6_}t<gB+3<Rh|VdNPxb&x-XoIZp%I6FCg}Wlosfj?V6Zt{_<!
zsJxHey%9tG_;gyxyEF6@{GRNUq46GD2^<j0U)YAKhJfeeK18_RK>orWqYNY|j&dIY
zmg2aSY94Eh8NEH|prtri5n5qUon9S-|5wMa%xaXn+%w&|WS(z<L!o?FEazY9z|la;
z`B+P9zO_6{`<|V@Fya4H$1@mBZ}NM#ckCNJV9+-fekJh%$KrHO10UenLPY9=5131U
z1I7m|S}iGbf8Ybs!^8(bH4&Q!>$)(%3*8l&+r=sX2m$M#-oLcpR>uoyG{vBirOltg
z3}NC0AoE)ChKCo}RF#cNn}~r-_L?IR12Bq~!6h6+1W22Pisi(%AfN$m-8rI~Cd@)b
zGNd3cfC>N&I1?)P=v+F+FTvBEvnRL{XsiP?p!`XCoEs*7U;{h6+)wy{3*fEQhoJQS
z`up$$mrta1P5AhMZc6%pB7UIXcrm0gQo_Oy++f8I?7RPkmxQTKN)QTu;I2)I1aa-B
zU`_$>1MBYue`5SV`xS!4DgGA}{J`Jje<68)VF+&9VqxeChTz<d)NDG2p!+9kvzZtI
zZZ^gceD#*mY!I{^tX0N=oJ(?&aC89By{*TMh3`!qToUJEY4dOMzi^5#hQQbV!p&3C
z9TO4U2oEDXgRl@`1;YCX#0Hi5fYuiK2S4z|=a#-v@B<4zQs&#~=qQ@UeDMP>%)yXm
z{J?*gaX}Ho4@mzD=UDLry8Ll)`Ck}V!gh-^Tq59qVeeGz=S5M!;rau@;kfUJ&~$tG
zPaC)krM<l0$2RtI)BnQyB36~D_VQ=B5ZzwB6obOYUjFW}_V)4@`CTA;`ThLH-d-Nm
z|HAL=DMspG*<SuJN7>oS53v7*DVF-Nz5HZL{hDJh|A+ZsxbqVWW5HZ0?d2D}Poq+|
zm!E;r#p|_La_VIIU#NN%jD_vxKP=W6OT_Kv|J!7#qGB&!^d41F-}v&-2Wk~fdpTE;
z?d2Ip6{WpAg#U$Y)7W0V92Zu({Of-K#@K_||3bDKI6w5(vj|7v{zhEW5dIHg7J?h$
zb%Y4m%Psn#aQ!b--p4c0d|YT#`a$l0Va-m`bV?}Xzy25g(f${lH<HK@rvHT`cupdl
zx>tLJP3UBiJA-5<ulBe!vKO6*M{z2GSDcElB?mTj>EB_P_URb@MKTlYoBxGrq9EvF
z__TtTr-IQ#X@-4zGd#e-AWTJg7hxR269`^}r3l|5yo~S(!fu2EXkRBh4Yb7m{uf5<
zCaZ!p6Jn<++6Vp@*jJS_6Mjgsbd*FI^gK1Rr&ydeAx?xp^G=rjL?NO5FPygq?Pc}9
zuw^G1*I;V%@xQQ&Pm2!ie_=NA+xTB7#;a!fU+DapYHyMD^f?w#K_Gj&zyF0ySYM^e
zB^>_?8mnAzR24elz}VAUJ*s}Iw5Kn$U<aCNPxtY^aG3lkAA5RG{|is>Mgow21pP0(
z|2D60n(cq#jwKQCzp&O~pEvw3aI7S}gU0{D-B{sS?en8<4`iRe53y_=>D7Cc+qvBB
zTve8}oOHk1MKGuDqyL2*X!1<|3p>Z@OoRO|e1-~|_W9PR2269XXoP#7*9o!V`Clko
zL4zlNeSXlp!k*ql{|jevc>(P6@95=0N$zW(KVbeBra!FkE!{}Z`X$n*2>ZP0f1$+#
z=z1UHk<>?VdRnw-Ut?d9C6!rT3cU~Rf8pf&d~)mhE-s&K>5otINnw`Hzh7+o9_vXP
z{|o1;d360+0RIcWyHy@4?ek+aKl}V6I4uH)*_VJK9KGSirNUVQ%Q*WTfRhr`KdZ)#
z(^9c99$T!)hAy{Q8SWFX#p<H9mSw17pFim>Wf^)1#uwVv&pyB9Lln#Q`L~{vE9C(8
z`77TEYM-Av`){|;4_#wv2gN?$c^S2XZl7<tTwRWv_IYjxw$H!*tlkd(_W7q~r8^cO
zY)4qDU+JF0rwEGqN$Owq{Yv}df1xuhzN-I)4sX);M8^L@UdMg(zwiT$@EE5pvb+#1
zcie&Pyuv=Id$lrKM5mVnZjVnHnduny6p>T5%bOTr2XU1)10Ik<`d{e3I<P%{5V=nZ
zWRGu089>7agFW8f|H3Mu;?48BT*XO_!nlf(dtv)xR@7G9GdJQ`cS$MUxmM7BVoP=7
zO|}Ha@5mpI2(YCUD^+sTlRL5TT6+*;le=U*@&hqbMptbtc|gcbCeJWN8TrW*P%;&-
zb$VKq1$)=&0QI|y6CH&eT*V2FB2;xMRRn+4s4Cr4wLN_2F1ZWOt`+p3sydJgoO=tZ
z=g5ChscHvnRYh{Hs<xP_T8R8qRk~{LmK#+y$`Dnh;<ekKGOFqU&>zB2$#i6MmpsJ(
zXY>C#_)lBi%jgwtN}ow@D@y1seF~rnt}2|c5$D?KaF<+!Sa;balyoNDx0^}#Mce??
zR}=9>xu^l?o*G~p-<6h#UrK>RJ{c=D+9)4~``BS+T&wJ|vVq8;rLV+MXk}&d=zdq7
z!=c|E{U?N{lDUZGw(jgHqkDJRSp3(M+>;oE#-@lJbMU(;+Vvea>%_UL9PXJzDRoIU
z{(H*kzFisJ$4_;kg4Bma-CQfEL`Pxgijpz7p+CLgo?I|R?l>C-S7&)<QtR}~O~i&7
zXF>~Zt95wMM=xVyH&MNQS&6r&RFvdfi~II4swYM6p#9!EKEXe(EN}>-vV-u>U6P6a
zo-(>`S4Q`RgSn#7)o1BHQ`~+TweJmUK-dZEVxk<_TqkQ*gndN`Eu4w#1~xjX$pu4;
zGOF`BBpS`dbgU>Dg$U&{2XnnBvihp(fo4fv&5|lgM&dP$tFmbh<2)2u-Oc(lo|)W1
zGe_W^-i|+Zpbw`AO#Zz;)LIo{__A=u{CKi=ztO)i=;_983;n<5PycTiL=}+!pD>7O
z@cy8GYgO+;V>yZh{V(#T|JRMG2BiPTjjGQ1$I$=PUzzm(SwfVg|2?=3LI3654EkRX
zHvQin2K`^j1vC9$MD(9+&_-eV-m5%JSnwK>=Z+bovH<2*{hWbVKpdCIEFc;s?x-Rb
z06$Axu_rLj^_>GJQKIABGnoaHFbiOIP<VmP0-TZs941vvs0f{M64SoAt5Ln8c#4HS
z6E6l0X{e@0OKoqkVFhDOqNZe4FuM924>LG?Nm2LS?_r7nKge?r&2I4H2B&d0<_10S
zWABNIaB>{6qH}D8A++T5CPUbDv(6BV^%2?Agufviw~2!`c^Mz$9zqcDbpzvQFD5vM
z+=gNZcxrwf#B~_k{9|ww3*B^ZN4rs)Tp6nAQLJ?_sIC{~&&rJYFLHj}KZ3I!zA7LS
zfXCf6A*nSxTtWBpN~(_dHSjb5HoA%dP&hIFlGjZ+;A)6J(z8(8C4zQ!&q4~Ap=ts6
zfOIaj_Eq8l63k!}kUw_=ilwr(TOQ$p6flGQo~2}{Qt^}P3j^XOKVAlgZT(=iy*vm1
z`J7iU97w8@532Jy`#+yf*hY4ub8#-|tgYvBUZcmU=X2hq$LW5QIPV=I4q700Zl!P@
z$bM3M7V+dvNiO2)3{5G5u2+WM{jXbw9v1QGv{;8<&e1Q^(9><nnHY!W&@&3ipZf@k
z<?}iJcvucS^?c6rpG$XKgK#^-Gz20coqlxup=)Ub&*#i3hn#f{=+1PnfYYM6;&kj2
zD<QP`7qPWKIiHjCHtuvni@KI^ZG6w?T)EHZb9Q;nuATS3NbRh{3aZfPW;>hbbI$z$
z?ab$M-ZxXWbMw#VT$0nH>F0Cq%HsjcO=a==r1vNGPuA1mUOEE9E2;=6*?R4_#bNYE
z@`d}cKkUxuoVC!dKW=<M>5uG})c!Ef=bZaK`h(BsY<O_L_J{rXoTEpZ{b51HTIVOx
zAJOq8!mw8FdQ%_apYrU45&r`11Dbd^_Z{7jDkk67G<j9GHcS+C@Y$x%VswV4WF^M&
znpk)bdezdTJd2U;I95CQd1V&ci}uw?5zAqtfc)t{qF6qk^W_I*llDQS$O|h-BA#}9
zGD^)egKD|@yBNGIyEkDJh8yemr($P)wZP3Az5xw>qvP)+w@E+^TyN4yjb=wB#~HLA
zU6f#qVh6vA*8PxCS@dTe@0kCiir_ue@E#HF`JBX4%=0<vDa`XZy%#XO$n!Z@hI2k=
z-!jsovipg<_^YXRi9{<VGr7vK!0*^E!0F6Iu_nhJv9`KHcsR%)zvkp5M9UMk02f8m
zDd%(g@lq~L-x1(iDh68$Tnn+oj7Xf%xnaI#-0>79#@*BN6jCmEP91mV`JCCaG4A+$
z&fe4Ixa&_}i7uT^)$KQ99{%5n)qlOGlp@?&8kWBh#HP>-VGr`;YHm)a8!5z4QOAoh
z--%Ht&Z8D{pC7$h-1PByTT1k(%5VGnj5VUAJl|)KhWZ}+0WXG0016_A*f^i_i?5mc
zz<C8cOyGRZ3i;gZ^EsE$`J4-7F?+FF2(AX_%4b>`05FXtD`eDPBFO^z9KrKBmsro|
zTy_&voIIbCK3F-QbB=r);(SgjR6AML_D{H-!1<gV<?{hNpR*l=3<3kxV7Zv1?Zp&_
zr~P?8XGe6N?hrF}T2?}7z|%QJtD2{Cmh9u{oQq$uumzruK(jcV(=%6@j&6DyY(ele
zOh@MFoMV3gTj0|<lkb&mLEn^R-R>ji1D;<X@w^J>Dt7B9JO7f8Ik8Se6~f&g((OeZ
zhE~K*6ZhS}<h184O{MG)83})xh6U^Fr$`v`_b-`HjHcrKA-_!%1u6a|mGe122G2tN
zii|$sE%@TPbpw;238}-hGA+8)*&uG&=~5j#JgS?P+fbU*BYvf`0oKZ?w^M$&>79`1
zh`;xGQ5eJmQZCbGiXJ%4rA|BlC{9$G4wpD}S~kO%$@fHr{YwrPHcPpsM%f$E;|Xdq
zeQ!tthML)A=H3u)GTs}q(rq-^Vzi3=-jKA#SUlpBRv?w`GpJ6h0o$er_zbGkdP7A?
z4+H4oVK8udfX|>htqnvYdVtTMIxSg$;0BtcKfq^DopueB1V{$X)Cl(s>_#$m$K_a0
z)61EBI3G2ojekkc8}QqL@GQb>2yY{7K==~jN4nSlRQVJXvwzO#ET3l?(uzu@Y>q<x
zW6@bOll$%ux$9vJY2F`lTqzf%s8sa&(|j&={5R=*PU&B=)pH^JOFr`$)ijWQ$q5e-
z&&B~PP4F){^I7!c{`W8W-)Afh4_+euOD6K?=n941=mm@_9TiXoKUk~`%b)!{8lL@2
zK6|&d;SIeXx4$mWA6WmAW0x{o`4U`sC8F(<f5{#w=06CX5DrIhB3yvb^!+l+u>Blb
zLb+e29op7ZfaKOfSRuEft{tX-$rsLMiH6jz(!XR87ozW%DMerT?3bDO6TJF^hxDOt
zgZJ*7xZB#Vb2d2etJ(y97ihoCRs6<&zs$;D{v|sw(vehorhiEW1lsMFIl%rUqb=vD
z@_w0)mijekzYMp?KgYl1`A_=NyWB66I*Uf7uGnf#9ul0qbcC2??w48m5a^xv%PgLv
z(|g4C%e<^x@pSdNvR`KM!&F6`C5@V`R?*xq!&T({G98R6%Kb7S{7WXT<oz<<6*P4l
z8iIfQOR~<IhlB8&IR@S?X>i1e!wL*XnY0M4ZcA#4^fU-J*lAOJF{W$y-y|<Kc*;aJ
zIMjp?Lr-UllyE;qPu)dIOfB?8o;Z;*PCSwR2W1{2o^+)V@bh;qPj}pp-uevT9Na&S
z>m>*;BUB)~iSRu_1oq1`!M|kXYOzZO7lOtg<o+e&Bv<^`zvMs0zhow4*l_(zRz9}x
z{w24Z$-hVP^FI2Qyib%Q)Na$u!EnnEUP7owcpTv!gbr_~JHElSC9a!rtwT5#_XlwQ
zOK|^^!$+_{#v3l;r_Kalvig@Cw_1hveuVer!Eq6}<XJ*%GV-OjlwxiCOP(>9G?mi7
z<n{by?_Y8Pdt|ovFWD9Oef&$FzJ@9&Wwl;ZyTiD4QdaZ#FZumB{1xH*mwfGVwGn6`
z3^uOKx17=WJYwk}9~@2TtaFWzaTImc{QXPz%~x>cm?uK{mt1<8**ynlKg^GpsNX90
z!>j`6)$H)5?uS`o^)LDTrTRzt?1%XalPek){UTZhz>8YwSRlXj8m8UHPQ(K2huJs(
zlEd|4p#w8LM+t?2zTWotFL@XNV2zDqhJVSe6f5_y95ntV*JV(D5~&`6rX-iI^RNc<
z_b>SoV$tjY{7Vjk)!*E|(k%ayGn~?1K^5rDPuTRv)j1qLZ0=tf%uh|(zcQNr!-w`S
z`QbE@xwnY%r23bfDwG=d_$K+6Eavh8>|cp_kd-7XSpE(EB|p1XVKJ&z$k1Q-`j^}Z
zlbVn2m?*$Z&+P6)-&E%N6f|lG|B@Yt`u&EPpZBknW%{Hr-}CR^X#1We?126y|D)#N
z@&fvod<_$VPP*{YDEF^y_*&(8FGu10&@X>);n?T>D-Q{CpH$&0`&SA|m1SWT#upD(
zpYubj)??+$`&a(DO|D!6>|c3e2Afyx&JP{*0c&+J=>InVlK0+kS-~s&SFX8-+M!bT
zmvp+-<*~Vch1-Gmuk5^4ZwLSVD_6e{zupMXBe?V{-BWlFL01j)MIRp)e**jJUove5
zfGDq!z(AXbdqFLMqgL_gKvlCeKEYa}S5B>8MxXepQ}L$4Sw#svS=;hF?cu5W7r1D0
zt%|1oFWAV8(`0dK<}cX=t;&EfD$A`JrVY~Q^CRJ3@(!G=Y4I=l-Z^M{34PSt=Ya2L
z85r8X<WpY&$QsJO<e2*c?`OFPnFH=;=|>sR5eLJ57CZlv5ygY<!3v*_Y4gW}Zgdev
z>W59fUV>3!7%xmb=<Et`CdPwaeY2!U1sB8PCtN&e<3f9TCe5t>;z5DPbVI+MRo5?T
zTm00+F+GvNkF;3{1YO2Gct$NoFZAyMMAc&4NGQ-7Q)dp{1m>^fLC@(%!nhR=I!upK
z@t{}gakS2nc?(2bB=De<baSLW^b|a3?qp?B?2B<|4m}eOI+kFjj0gR3j2wC@9`wqM
z>5f|w?nZbN!H{oUUIQN^Ffjrj!{8);RJA`o#^nu!Kb*WE4E*7}U3nR#;6bqiDmWgr
ze4p{4M+&o|Bypvkf1X6`tgFp8qS4KEu7^HUn8`}lp`95Idgl$YotuvbC3hNd1n#U`
zT?LmW^<@u55vUI4^m=VTEau4Lt2-JmJr6~Vp_keZ{dvH0Q>FOHw}Jbk)BG^{qrS_2
z><>FU=sm*P7@$9{xKrtmfp@9>Vd6pS=xlbzgZ^^;e(eu?JZLVf@TmXX=?4WKv`-1Q
zgltj;58Ad^nZ<ra`=ZjiCD_D+W`2hzWjyF(`Lan>JSaI@JlOG|<-lf!iw7m1V&XyR
zDNH=*hE%2(i3g?MOf7<yRziJ?j>;bhBM5Y@x%HFRFlB3L*V3val6cT_L@oUApnkm6
z77tpE1Jojc2VE|#baLD&c+dy#P)NCGqB`zOJm|t17<Y^ZJw8v4yMOVZOTqJP@Sx?4
z2Yroa140j#GaghvHyaOH&UjE+%wDXv2oEZs84t=yR>-KoM3M#aIf8i5aw{J6{oYJ*
z5)Vortl&ZC%eNu$pj4=KvaIc&@#TyMmCpwd5Be7-H4_i|vv}H{c+gG?9u&^zvB5AP
zB2=`ii3oM=BO>&fJN+jlfe4*&yD}k-7!Sr^Kov|x=z5$$AP}K#uaS%)5F(V<SNnno
zZFdZd_F>~e`#mZ3;0$uycYon`6k8ff!GmTOQA6n(q2A+281l!1*4=@IVm#>9k)j~Q
zU$}w?{Zy=#0^vdPJkfb>^Z|oIU2CveUPpwAW7Beag4XLpVnW$X9H5JjCXpVePRE1}
z-Cvl{vnN`bO~Hg7h0X5<CbS-HXf~UP3FT&EOz2Bj8O;_P6Wae<)*k+C{=#SYVnTiW
zg+KXCx??`Vn+WR=K1HZP_!(gjg0lXj^CKX%>?b_v^LJSKM!|y?->T65Nb*u(s8rTN
zY!d6Of%jubGamHNE4iSE;X$Rp@FV6}@Sr-r@!;|oK6b0XKjI?rk5PwXb=Xs!A+;+J
z_niw!-qUu_{SgHzbpJKow=E!xp|%P4VyOtMO%D|FAB0W_ha)%<E<k7o{&6gKp@DzA
z%?AHy`U{^8lsJxawBR4P5Q%@ppzy^%t`35K<aYt_kNn0S{}|L?cxQ>EG4YQdTh46s
zJzx6(`wQ>D<S%XhjDI}YQorWlAOB(g!q30m!dNg@8u-VXXjDr4BSx1gRG9e3s(Zm$
z1pe_-ov}n7|5#+HqKbdKk*X;1kK~ZSkb6x0BUe%2AB`$X{9_1z;fdP?{_#herWpT7
zt5XI4XgS*&;sBxjY|huF<)L}Lc6m;;<$P^+7BPeuwEpL7(~p|xYnNx>Q8{0m_K^lY
zUz--;=K0$6WS*~0Pv-gB^kkl|O;6_e+Vm9Ud~NzJ1^;L{D4Z5u2NwVM1MrXNt<Mn7
z!Tsa7UV`v4LIuK`2;U<_0RL#Q?}h6xJg%B&pvs?UKpph{!VUh&I*)(-h5w`dg&*FY
zM20Z^g=-H)z+d<?3H*x$lH50c;g^YmAbGJXuK!B|qlb?d$Y86%pl2bxfv^kVd4!J;
zlC^Y)hHE^o|HCyJ*DeSL5HD%#FMI<|;5A`i-;*7T{Dm_ZOv1i``wMT|nWaBbNN9iI
z$K;{Ctp37Zfag?30{Hj~pT2>n+R*;O^O0XVbAkrsk34rAgi##D-e1eYt7iHO|Gkrn
zpON^;ITny;Abh01zwo313U~=KvL8NDEL$+8#|-mCWot`Q^cF=293Xt;aq729eB?q4
z7PP7ONFRUU-*?nM$_F1A)L-~bb7%wvz(?+aB@OfkR3&NRu_+7dA+Qt?*GDm+>G%$;
zhv_^@@}Kc2wDqw18_qatfyBhw^T4hE;<_qInxA8fPeWJ5uZ+eio82&)gxiehY;DM8
zjD$lp&@KS`!46%Il-OxYr7S}!q-&D6Oa1pvyyY>ixt7}N7QCh5FPtH%lJE{1f8iHn
zg=fWE_BlEb-ttPsqAdd8EvMp*iMLz?=~PI^)GtsGz^eZaoRqn<*3(l)Dmn;_8^1EA
zC%i6kGxygzC98PLwb1J^(_p;iv#6knxBP;inu537^)d}K9dDV59WcUKKVf!VcceOs
zx`^6pS6oelCjj0u@p>K=NFNVscGX>12-lIg&*|yfGq|X)SiS!W5mfNWE_g|Pp$_5l
z0^ltl(#xYIgb&{GfcXm_d8Wd*beb~svA+Jo*B*v0wfZ_U^iiaLp^3L%d)zmbSzZdg
z5AHAg*Lc6*F!M9s@(OH8ved$S&%b|`?R#{vjlb|VY91~xAl`Bc+?V*{EysN0hqt``
zy$IkfQ?IiuLlwN`o-37Q=+`4L+tOmu2XEPT4OYsGxAY9*f&dW>fVb?K&&CWpyyY9U
ztTDx)|J(4E$-=BC?UM@L@^|>IGqmfUU8OF^O}r(y1LG}S=j!d?kGI^kGu^Qj;YfV$
zPW?*v6j~rK&{F@WkB<oW3;+Edz&oC!ISp0;INJDb1bt6r{Dq&+-sT}$u}8Z}@VHc0
zk)B8%ZLzuU4E*5aHJRX5?%XPx&fuX4QLZ(Kgwm|X=7lP4@!jOd;2`!F?id-;UwF<I
zfv+rwpXR!hiJf3GgmU4INl7re#=3q=fl%Sq;zkF?SH>W7Kz!x@Mjbr(N;`kyLLW}9
zJ`&NhWN$U?f**WFBd)$;3L(enj~FAnx#9<wbvzky?#UzZ9;~HeGWl(yp~Jbzr4v73
z;({2IXdw>Jh{2DAA8Y^L|GxwG`yLwCiTL^izKipaVY)5iVp*P?TtYq`@bTGZOZa`0
z`aL1a`)yPc%L~{)|D!JX8~exeH~&6>Su8s0gG+7yfbDg;efkjnHJRLWMzH@k3Cw>u
z<Eg?~k7^U1o&c>_laMj5Usgi#37*^}4A{i%y!e$_I52V(Mry3qWipMdL|5O&qUh@A
z>h~21NVE^(5fgE6Lab+ldo)%ng5-0w|9(P?GDxcML3itBx=&Q{8uA+)m3d-atDzQ-
zb+_dQPkO!LKTUrRe6IN(-bg43|Ng$_&#`TfPO?4VW(Pj;(H4JQMVu(nb*5;Gj{<#9
zj$M1a^10a_-)*sN5BvHA?w@jUL>jDrn(%$?u$?B<_qn{f{2~2^wx=G(B(EKNJbY&N
zpw$;9bkkX7o$w{d&MIs1mYr4B(hvmH8YhCdieZX5kpYC#S>@MYiqhrstPvJrl+89Q
zH)uCrL_&*~HobVY?2A!#!%dA*K>o;`5JnlC*f2l}qi*_bEXZ|-w!=AJnmZTUZ0qto
znLYE|Sq%ja?Z&UDlVV6Nf|N9cW*>&#*6FZYmSD7OOzjQe>)Sv&Rp1hJ+Tu$1-A}8=
zA%k^_2h2Lpy$OWJ&CyN}<<fxGQ7QUKC_J8B-o8?wkd~vhfuPBCsH$*oq&BN?f|PXc
zQ@K@c+6hy`fM{yR*75i3!Al5Fjj3g^(HRa}NY!ea|IpV7h3(6n8&StvZS|MrKnlLc
z%d$42^J=ve@P0&)AFtfT9fQzMBJXU@3(Fz$>PbgeQqsN1o4XM#qE>qYuJI5tjW*FY
z?ua$=j^MncXlgH${`n0htw&zHBAHbjF)gdUG^=sP2Gm~sZi;`Mi?>qJzsx#s_>Lo{
z<^Dx=o{qfYh$KypGTu0ZZA0!XI=r1m8HwX^l(j>L%29U8WtLHfw1ae&PU~TcsQ=T2
zG|HgW;U$kzK>l5|D3(S2*=Na7HWsyj<HJTc#c7Qd(A9XP#wy=PoguX_=OMPjxgJ%=
zg}z?@{7$=Mm-TQJZ+1-TGO?Abc%$RCjvnX6-B1y1c5QO({?hGS@6Os#Fp$dah#chX
za-%zUy~nxP?c9J^*Mw9@F(PX#GE%uwx{`UnR_lPo_&(RF{;Y7|5904l#bDT?eTs(l
z<gRa*yP>EpX%}j>t+kwiP!6u*s@S3<!4pZs*?>{Mo=4RE(C=2a*Q3|-xR|&N4SW~A
ziAuNtB?v?PC0wySj>2Oo{tS5gTo#Q)H@xrgB*d4;v~|_>Dg-LFR!hb!-U{#aw0Hdk
z3#8YL@r;M1y^uc74Fm&f-iQ6r)w;8VY7X9~Iy9y`&PRxLWH_ejSGuRL4$pE;6@cCz
zxwP5zHom2#w^4lhEa@T*ddmUxx6s?dFF3-F-qMVdYYlqag~`G~Z-c-<0@0fnE)9il
z$)GnkleI!`TbOw3{pf8W=e5-N5T;dy-bQ>&zx!7t=xz1IcJwyue1+cb$PPtsX=jF@
zx4|EVLvM?IYbw3HiX36n+tWxKgx;=2!&>R>7Lg$cy)|z2qc<<e)}Xg<CFG;fN^cc#
zqiI8L^YN-V^fm=E%}Rt@TVy!)=vTU@a5_Q|dh3d5yP5Nw7AxtkmeDtsvAY$*r-j}I
zV%iKezb%!>9dmvw!79;0Z=0ET{pYudoYykH9mTY&&|5xFwEpxq(7(=)Gg&M2=4IlI
z2)*T8Xh&~d&Qs{EZB{6HTY7p3di&zNaOf>v9*tWV?))|YIl`v5Q;|3bz3oK9TInrH
zWC%iUH&^-5+X#@LL2oy+KRFVVtn@Y<j#+K!tv~y0g$bgG^V{#3X?nKGaD0bQpkL{p
z!gB~d^p@m?2F{7IB^xJAE{>(k?a4UhOY3nilY0S{XkIM=!vIps0-CLzv74%RCuH5^
z)iDrRwcEN8$c|)|gvmG{1ySS3jm=$@7^1PWw%-(vjDd#lru<tVY2=UkgU)!v1f8Rm
zG(<s;PRK5U@z;G)LnB=~afu+=BDf}OglobY?LNFBw}m~*oHdXr<ZoA8AO!o|TK5e4
z5qL6;qU2X`@&;0xSnOdso?EZ^n@FXbpqFC)cT~fDYQ1MN6|_n7S-vUyqpW&8{{$m{
zODvbG$$h;3W)j}`6ky5|XcH_icu!=Ju|6tJ!TRW8G)_d<N8>KAP`0u@${H;Cm)A$V
z(Am7sVaYYn`skZeC1qo0gStK%-TOUv))seGCG~Yi8oN=)Iw=S1q}&FNvl5-PB}bct
zc^2l>Ca;$6`51J4c6GYlYH2&95S}3**lxCpx6lc!cenRAH@MR=@@OPjkCf#8$bmO>
z(s1bA_5vUkVnFb@7w=)GLJM^4(PoP0kb*pJ!(S1-Tz93>%c49T{d_-O8gB%}>HTlF
zKK>Af@W`)^$7R{}zf<jh42BT>-%Iv?xa(sq`<k;po{5nXbbTz!wOt?Mq$~JtsDtmQ
z=)z?DZ&4VF|8a$Fsyl!wQRQ)&f(xMEcj73mL-=rrLUx0NwP*?ocF~y>ajq&@A-rr3
z_O{EaDQpE+6jdEV3~5?!V`(mLWpdSBTNqDUeq4XvMkyK`l%gSuC3hTl;e-Qx=+9Oc
z;cNh_dSe<e0T!cWi1CpH(LD0wWB7S?<D<vf%J@jYU<p1xR`zV-_*j5hwmIXY=!4+n
zW3(vOW_)1wa;<{W2J75dLz5U5eU=@A_Qw%$k>$@{2-}}DA}aiOLAuiZ)6p4$+J7$Q
zQK7&3Zx7l2_gMLJF6YzrSJN_kK#>CN)m1{v6p|mqg}6m~wf)K9t$$qw_o{#E>-HC`
z{_5Nz&6e-qNtE*a8#wBW@g3%RdWNt5s)~hYfBn^X&TG+M9qy~Y8fBxu>d$#C^8F*e
z`YVms#QyTV!@thQLR_@yuf|}#7NPa@Ejaa3aYUl%uLcjGQC2Bj1D%8+$4V0){ngUl
zQh&AOBst1%03|5;s}V#PP|9q7P?hh`L2MxXRn(iZ%fglK8<%3-g{!~%9f^a;_bo`h
zWzk=)78xMl!{=Z?{nY?;hL8R#87eJ9zCRfy2>sQCXa?5=slPfB`vsPv6?Fa8N}<0x
znVPB|IDK<H4Ks<<U#*Moh1z>E`>+??TK5n`bv6By_8E>tJ7hT4APmv3bWh=K1S#9o
zRi95(eesv@Kh(_ibe|+iZ-a0+n-9Hp^3`9Bwb5V2a$XC)J?pE#s%7H!Ur%pXq7N-o
zU)&YE-l8uaZ==7O&Ur0506K5RLT~j#p%n@JRn#Cmdi$cELT}5?3Po@ET|&^?xaoSM
zu;)-adYiFWc3HUec0Y22O>a|>I0(HxNZKk3z2%4uLFn!NDnEJ~vsIzDx8I;IqJd<k
zx97*$(%Zdw)l_=RI6T8~C&H;mWH^@TSGuS02cARF+x3{Xn@Ml;j*;}X`E}WOhQ4@_
zul~wmqraNXc`fvIny>z9s*V0?1n0HPZ*MYLEBdQg8~s&^f1S_r)nDDq#2XR))r^65
z^mbieh2Dmo8H(QOjt@a^t;@opw@$CgE(@35IwD8d^wt51gV5XYq^+{h+tx*#Aqc&F
z3+CrDzb%LCV$5$BpoBp5b_T$rHuGCDUNx28Uc)T&3&PV!WjIbkpsNgdxDQNk0re?Y
z91VG$j((1)KBdclEh9~l*Y}>rpDXOmRcC~f*YE2jN7_QGynbyUeaf_)9x!4W+LTTY
zgr`mMmEOBPgi#hmoAL<uTQI+Bx;Dj-H|+Eq#~!sm)=#tg+x5qdeU$#lK0Q=_G<1~x
z5!U)?QkdEe-yV1#Jr_*7F?d6$^%M3+8v2bR6#Yi4>Nx0EFGRQinvL^>W&?NW>zsQX
zfb2j+L8^+Cxe2a4tg2{aRYhYIw5l+DKuysA4Q>!MMF{;wG3h5FzCJD&2D||4<FZqg
z{vC_X4!%A<?zkrP@3%sW(B$=T1>~_{{X0vPYr8(y{RQyx(Ea{LR1QyIINT?I0yBVo
z|0gE6X385$sZ!o}XuO=f40$7pr|K~9AeV4ni@b3H=T-0^gG7WM9weFbTI7v$IjJIV
z<ckPD`*hVfzdGN@Nfmop1m%rReJxx^Sx@ginMP%$SWka-N?>`T^iR2-E<Hw$N*g@L
zxDoVWWLqJV%6T^H>8-cR&ktAL_!c?BmNz~@;vn+I+Ep~ks(6s6M1~;tvXdbV`p6r}
z=rBXxi03b&fn>Fpb(v~wFN?z~Q{D(457N0)hT}?v4xKX`kLp*tr|>zRrOXk4-rShx
zn@Mk_T_nAw7Rk;t=xv5rKATu3J3NS1NO>*vwwUuO^tM?<_|e;Z&TFB!FMZ|vIuYSV
zZ(}*HWj(!@lPdI<%nSR7$oGr-*wNcP-4%K(=oyOMl9EEuTkA{1p|@LZlU)`rz1@r)
zVbj|+NF0RTE?nVDZ>NY1LFnyCbcPST-HWxGL2pmqDhHC4-pb)c%*H-F2d|n#Zx3Lm
z`3Pak2^o&I2y~U<9NY(?x1%u4H<RA#PLlNY#x1h*40`J%md_@=+2KLPb6yL*5#rK<
z2N@+I{OGMe=e5w=^_*0h-%3S<AH6yJ>s-c36?&U5A|j!`N<YPp-j3|5(Ayp|atFXW
zn)BNWi6Q81R&F@-7ByCOS-AApcyklz?RO*&LT}%{=}T{`MTQ{s77uRdLvQtnGU)AO
zlpq+lmEHyy+tOQiylM`;MW<yr{)_NC!X5gR?kOxm@S(RvvS91ZtiRmI5-89fZW#9o
zkL|^3nqkE-pn2UevDdh>16tSh^`I)xR-*wz$+K$u|1~jvJ5k#v$jk3RT5Bdh8FaGb
zC!4e6;57J2I%;mgmyHw=et6E=oY%rnMsreS{+=o#{P@WT&THW(ZceK3lNUsUA3sU)
zuk!*<s_>HyA|ev}<hSm2{G=jP;U_Ph7?_`2@|TpCFG-O6#K!*A`V^I)*y+PN4V7IM
zE<fpr9AVGj9gsK(KXHA9*A{ts>v^0Zh<@&7C~1B8$x!r<!A~wg34!!;vvO_qa})8(
z<R{_TpN4hMaNLKG(Idn0zJ8^93at<%FQIDydHGUEYt5v$H%^uGHfo6MJcHgged<GR
zH6p@~-qJX)h2C~?Qia|Uc^>t*KY7p9hn8u7I!a8}=6;2~BEpZ}7II#TynL3Ju1%R^
zgoua)y-n_FM{mPBDfD*c@uBEViwi+-vwG-_64d^*C{uP>xb*faa)eE9Pa|;<dOHjU
zl33~O7Lg$cy}gaj@S(RkFq|0l_U&N$A{t0m`%@R}2eHwI$MIGXiRTQD-qv82X+U_b
zSBB$E1iH#_JMKf!+YW%$nn`b|r%QUPJx6w)L2p-Mvyo+fyGum)(c4naYoWIiPO8w`
zJQ3kHzfI)4mig^PPO8jr>qUegy$$rQ^M{;Nncuu3A`<l0{zN-^+kUJ<Z|`>uMQ`KV
zgrK)BCxt_A=}y^Y;nLdx<OrMIPDSD%^!CiBzVsF)G6bQwcyM7Kdh;U6ptqX`1*W%h
z><6)-w>i93q-peaYVQokO$eR)WH?^ZuXIo0M?43hH&tGK@!d$u%WrLHn!NlN8Z4B2
zZNESB>yFUhM|^+g?#>p<Q0!$N!pAVg4`DA`m`s#`jk`Yh<Al8u-*#myNf}|{PZ#h8
z<EHP=9NiL>5M+O5$y^%?O#pf4dQ7m*<i9WUll*sTM@h^E|J}ODhyM;_A;urymdSao
z{FlWHh5v3AfB--K8^?Jq{P!raoG|5`e6gX$kN<8w&acjoGgLt3zXA{t3I01H#WKni
zef)Jv3jZB~As0wr(W^nOFX~#zQD&o$zwS@D*CCibe$%n?^TXx8A0tQD{C5o!2jRcH
zU-Z>i%n%uZ=quj#*T>IS_3@3#lK)!u6|)F$gPjur_GeDC;BCU!$G_GW7yyK){{svF
z0$pXu!@cCe0qE^dOt8(Qx1<4*-V*s!EwcJ8IH=ho?`-^-BmCr@Eyu`aGWKU4&a|q~
z+b9O__^&VKa9#_&y~t#($UAjRy#9F7k(}33=N=5}QRr=A<ks_@j<ut=-H8gleRV`A
zdMkB=pts$-!lAdTk8UcxU4<NB)7vm44nl8hpY^4;P9j4PdOI21&_~`$1_>JS&izNp
zfn=q(E`+xUOmA@(yiNG@*113IUkDw}g8fUs(mjRG@f?KS+?ckTNpGbYlHTSe$<8z8
zx2O+%=xroKArPP+z2$RW%l!5%Ff0~*d@U2NKfQJ5ycT-<kMH`Tl!@1$-fE8YtMdvb
zYlYt8BDbDjbd(*v-P2y7w}Qh$(Oc49@~fAGt$a4~+daRBLvOzwAwNId`R!Na2%Fx%
zL*gLxcHz^$^tMQ32tsd9g8BK-+r5xo40`LxUql1RN^j+G!ev8mbMVU4pM_6v4`8PG
z2w}=V*uN0yD#JOr_ougj__hVKUo7JL1qUB#8EJ~Ver!B{u8`Lq7<R$s^;h=Dk@gy-
z1I3?8c>4vP+)bRN>H7trhkO<c;Z_c}cFeJwj&RfE4Lf|>jmPef^;7xbcKuOyh|(Wp
z(K*5U<G4R%e}uVyx&rb8w^S4T+ni8`9tg628jaZ!<@zI_LbUJKSf)gNeL7qiC<EZj
zdc-O1n{a5T_FcKViS2t9zNb0u`|cmX+jkeHo#wRfA;+M7BaYwO-NA1Be%MxN--T%G
zK;t*bajw3<?aDu7`-X+jj2ErYWc=Q^_k*|YJ=1MkH=w=adQ8aN$5l=C&ou8mDIX2`
zfu>}OY@aTc`=;$+I?EdV@=+}3wa7>Bise4?>i(G$d0pTyA8pvCivp&-<6N=aH`o8O
zc~S2#A5G`HmO6hZmiuO%lX<UBMDRf~gjrBhvAX_`rBPNX@OVQo<N~h$qcF<YKU3XK
zIm&G8i{n<R@{yf=amM$u%fgk9?njQW<)bM`97H}kex<MeHAiF!qJRAri+vyYXaoAk
zkdNN}j=qQnlGWaE#(!+}ugQ32%17bZJ6_Ag+8^QRbFubEpsNgdxR<gKT?4KEF%348
z-V!g6^tO4c>^x&VvPmrW&9R#z6mWj)k=dNrLT|ZZxo^_jJSJX$dK<xcE$fjlnXHxd
ze;P09{pl^mzs^^P<-S?x`AobKp|?(lSh%`EZ@Xg@di$zXD0(Zc2|;hI-wKD`I#tOo
z3zyzHB1hQt)&Yrw(A(?FeCciLx11pey$$f!w^{J77odbd^j3jgCN}nt`FPb-dh0wC
zYk!0eSy=n)SGuS0Ii5q%n;X-1GwE&WFiCHtzLA}0(A(8wxo?i$g}kWupWo6ruZ7-z
z5X*g&-um#O-k;vQU+Y85oZqe&%YEe4{SPi>;`OJug`C$izx~W)t*rn1^F$jFdRrvS
zf&u2Yd!iJ2D`*jl-jaR}L2t9l^+pM9&##nS7B0QLiX36n+tWxKgx=1^CSo6ZzQ_=S
z-tGtU^O@hqKz1?aw{QPPU*tc(4aY7M8+z-HS52k22QbTggfJx=Ykvf~%5V<u1Jhf;
z_5asLL0*se{<gubEu39l|2OWX&(+ue7<R$s^;dq9BW<B|{U6T$wnfXsTmAd)u6h&F
zS+Ldrn-A-2uBNa44SB<E{r`B<{#ZYix3uezvb{=wj78@J?~mhl$o>dx{d6*<2j=V{
zR{y>|aK;MsK#<k{bu&Y)pX}Oq0Ysn3uTO`^*tKtudZm368bY=2%I!^R-}o@KE57af
z1>~V%?OP$V3jW#^ef(PRwey;~zw8l6cg>vd$6qGr`>8L>$-|iMPvNOj*<Y3|BK+j*
zOwMbW?{hh+VqYs15&rgU&TEmcCvZ|lzMd^2{O#E<`PKPxPO8lJ%SA*a?AfcMETdA9
zuV?*9qf%eb-tiZWN`HUDjuvt~oA!eol{WhRF91ply}xYJi}Lfso$o(Jj<DzZHAoy}
zzQ1;wufBhV$Ph%|e-&0vKJ)!h^p7#$H@-k$L<7mH@2`N1OB;Rve7rK}`|$PsQ-;I;
zDZ;In!2hX!rF#meBgi>Fz<RbTrrBoFn|6hyw?zI_i>$g@EMHCey2@rfyXAS=Ool!C
z2TrQcTZ~xX`qA4Q&TFB!HbR^><?A#X`FbShwbZ!>CspWesECLJz2!78nFNrpyZoWh
zTid!&^tN<s2ztBjf^g{VYPhx*D!*{)?JDF5o8E>YaS(djdABdUbrKnZ(A&r83?F)1
zjs=lHZ}&ed2a=WEh7Yl&xBht59D4g5GfmIS;qMfoK)=#Gh3620(A%4kshUY|ms~CB
zZQeZDdB*&f<BJ~|D<b^nw|vfPncs?h*Rv0a2tRu3&Ur2L_6R3c=C`FH!f$@7dB(5K
zD>$h_Z<Qh<67;rpj~%_0|E|#6qqU*vE%TcY^tSsv`Y<#~(EZcD!L@bM=<QeJ2%Fx%
zL*gLx=5qPc+ai%62)zve7xtmI?jS*f-a7IZ`Ok0L&#|Sq4S3ZYdb{Sz4961)!>-D3
ze5GIMp286bKJ=#IWhXouNxZD*DY3Q)<}X2&f2+}kp!T5q#nkjKKhjir`Fcoe&EzNZ
zMoWG&YKk13CO;9=wK;!}6%l^?B#rZ0`3Wag=I@6@gdacgPS#1s)Q>&FNmYI#BK-Kt
zLe6WMzgKWlm7j=+Nbr*x!Z;XU{=V)Pg`W(m3CvHbVx+uW_od_~Huj&vsVYCQv;Qo@
z*6613lUI==Y<}`I5(nWY$75aRqaPC)g6PL4K}qVvPe!1B41V(MB>Ey6NIv!-ATDk6
zW65}B@{=&_Ki9zigYfjVu>T;?Rfas=OI||P0P^ymyP8dJiPuYdtG!cpo<VP0h5Ff~
zHwVv!{`%;poYz8cEjg(|Z>b`}kKQJ7Ud#O5m6Iy;mMJ3q=xv~XowGQpLT_V4L?q~~
zlQ5G8pts#WDfIT0Hx#{<ejb9}zDNm&-qMR@mxU`Y4?vEv>Frb`4nl9Q&-JCZD3Kuu
zy?u<%@S(T)FftnScJsu*^j2|<ExpahtESRh=RDYd5IS53`;UI5dkUZ9IRw4AA+0rY
zew#W*(%aPklbvVK+b!?=;6JB}2*3F)lk-~WZ6+sG=<N*=;YV+AoYz8cZ*o$F-nNJc
zKYH7EhhLq)=A;U})r*Ko(A%P4?d0Wqwkz~jup<<`C4Cx#-mW{AK1|BXcJte&3G(y9
zrMHifBW!wGgTz7T?d->W>1~F{5QN@3f`j|eTRox-dTSg{U*tc(4afcwoB6FjZ!Kxs
z{;~%!%Y1||r2zIH1iH#_4(<ccn<_7#dw(S5<;#UNBz*Z74HimXw)*$J9@1Ac`NIoi
zC4YG55;@om{t)%H4}VAz5q|ukl=E8n!wH;J;SYmEgdcwx%6TpP;apCt@P~X6;m02m
z{Of!pCsp{vy&@tK{9#759e=p)dxbv?`5`cWc%hXc|9&L-gN?rU`Ti<@IM2o(S^MF#
z%fjUk@yHQ2e~3onApD_sq3?Qn6V8!Bh9K+dU%{+>_(LT&AsGB&07?j?FP?RV?Rt75
zUYYZ8`1<14ZiEbs@bpcPff48`LmuuWj|e3HLi%bZy(JY&db<dIA$;(LGv4x{w}m3Y
zkKU3vuZ7+gb5e!gHj4;9daJxhA6n*m^Gi;u&|95|@T0f6oY%76+{;N7dP`nT9}y8e
zMkmdV-gbYh(A!sAL(yC52O;Q<@O9>VY)5ZT;o!-ptv8=Uj<D(N0VEDWZ)?Z;(%aP{
zLlAnq>ODVt8wwIM=<Q>+OVL2G>WjO;1K2W~{ZDw+9D3_~3uIt~4!1%E)~|F=;d49(
zp*J_AuV&I)={QMm+j3;*8S`7Gr9SjFP(=9A+Y6l6LT^q^s?ggg5#dK~V>qv6e!HHN
zD)d$=BK+vBmw%nhIH^K!^F>4?=C?)L?C9;DN`>AEz6nKdN$W$<8{z9h)7vRHc(Q5q
zb~18=O>dp)Tub}&S1-KLm)?GZRVn!V_A$<7@tNP2<6K#T-mYT1ls~<d_p+t8Ie66^
zdV2sf%|{4RiXa0c&{c+WaBrbERsZ@ID%>>ra|fiKX3}Ts|4I6MsGIC;gFZL$+@jzW
zYD9z|eO|(OE%dpIlPdI?$n%mvJ~5f|TIlmAPO8vnUlHL)pH(OM)%h$j{h2zf5h5ZI
z^x1x^9er-!qR{92Uj?Sm@v&0=9RH4_PaFMf1vcWC^l7&~-P%=tez@}Ix5yDTeSU((
zLFn_D`+V1@Pl*gc)~5s3`O#-GNY<dwc>W?9NLKx8c^ljH=^VT==`%e2>#5`6{{*4)
z1o%JEuXIo0M?6c~q-y~Ab3#?K>FuFACB3D>X_1foc{NWZ3ccMWBK+u0>q2=g^j5-2
z6?&T|BK+pV`JC56Z!dCEh2GYS2tRro%XuyG=ZBnBnGd}pA`<lW)Yo?OHtsWp-Y)wh
z6urf+4nc3j+l51Kx11=uEL?iK89BnHw`-6%2)*_8_|n@cB0~^*yZ;?OdK>euLT^u=
zAP16_-Uhd_rMK>Q)l_<W8netd2oFrma2$<5R~atGeF%DM^L4Z7EoO?Ow>Q|NWf{A_
zz2PH&CM@O%KYAO_c`fvII44!;t&fQCqqqLjlxD8?{=-QXdb>nK_|cogzs^^1Qia|o
ziik+i+bLh!(Oc_J6ngvV(@^v_dqoI(+uk}HdW$-~sr1&^xe4_4I}!(>x3%~9(%Wj0
zAqc&FyT*^+makRl?PQb?NdNjpv@N|Y$E&8&TZc&*j`I<s@5*pY)30<-VI7|R=uMSB
zt5M<5@~0hs`K%b=mwQI~JepZwSVpFT*T3;&8kss?KYJ66On?7cBX>&wS`EwO$ed=y
z>ksFA`uUN0o=lwUo7I35B(H$yW|pl(AjHeF8Z0MBE*=g~5M8UgP_Z*!XzOsSrqfpI
zJohGyK?~(*&tjxdE9b`Mxuex%FIe8-{xFW~{d3`7F=~o@&tGoD8|(3^QeLs^pAVr`
z*wH=G{j>WsyZ-s`L#2NfqO$_^k9of5m2b-aDYf=b;PX9S?HXS1_~Of3cMsk>tykOh
zjv)`)weRC-+Q{SgXKl7?-y1h5?VJ5ksP=6rm+c$Y{)ho-&1>K1;lD8`eji2wG5Sj_
zgI~(qDnEKlPn!iw32;D+NiVuLZ%-4`|DTb*G(hp8=xJ|@{lV{^|HQ7pi{DrJdn7tP
z5Ivdx1P@&z`#Vg2x8gM&i`_(iclct=yg~TgVw~n+&+qL0HSQmNHF%R<`yPwK(2e=T
z@j>ABHT^Zb@`h~Ru=v%@cZb)yzWl19G<fR{hms>;>;6srYWv4_?Yp8vY2UeM>_Fq!
zY~S-=m+c!CziOP?y!O5B9<*<e{ai;vn-wm<YNw|SmtXyFnJ7El^dA`M?fF$sd^t`4
zuNzAToz-JTa#Xj*4X%!9&U&lBAo!<9e_LS(9P%FP`t!m<%1G%sBb6XCs_Czl>CX-?
z{iwnLqWtR%PmeFh3G{nzF6<$Gx~MQ!yc%D4jCgek6;5Aql6~REd=bC0iQmiV>3dg(
z_r08+zL(R7{$5T`-^=OgdsoWu<yZ8*{EEJpU(xsStFXTJ-~J6gp1CFevHk0DCS-fE
z;ymq#d7QEF<*_;1yL|9{+!bq?{;cm;;(hL^w3kl4*X1V<UJS(&fmqiMSFGh_pDHf_
z6XR*`PQW=Rc)ccu*M*k%$lt#?`3oBIwShz6ZKm%)$Ec@>k7T>vsk!jt;ZMbk9O5{|
zS=amB>@sJ~sAuSvI}3h;w$UBxqxElWY}9!VT0kpHq~-56#5CXq4ANjpZ9G{C+C_L=
z>v3-LWYvsvA40h=z3R%#={w?V*SFLj{a@X;_UPW6{AiEZ^oX=akJBUE9^GHrxAsVG
zPJXmUT4dT|1#IvU9UsXH_N_hQnv);xkr|oxczkSx+aqrNzO_gF%gxA-_Q;P+dlWw!
z;r6J1sTtp+@MCXt@}oUUBhwxW)<&v5%ACoVqmpvUaubJ@Ipc62o8!r<*N!;@j9knp
zN#MjhpSZkfZYaW>buBZY{c=02bgAEyRi(9iSJ#Oa#k$rv?zj^y9&cR};v6LR)k^8L
zmRP(e7e{o}xQd|wJTZU79nk8{y(QC8;K-la3R>1uL=;481#5j5A5QwYb7QrEZ_(nT
zQn*PwegzgEIPWVXHd`$q-w_8hEtRcpdQKFCT4|^T3ekF2=!)z3sUK5RZe2x2AFi3R
zZr#8nO5@3in-&c(zT(!k1}4cmcXk{e$*z#o143Ry$*TCNw~HcO6A~Tq_g*gwi(itF
zgodn(Uy{>f7_Qp+aDRepX?hYp&E;Q*4MQ~5g_Oxzch~r&*!U?kP>bI0QImNQ&2qb!
zE0*hZ=W4EEjhbxzM6<~rRhsOKHI^nrTG?cWETbmdLQS?st3msjO=c7znvBZUo_N-1
zGT0>?>zs{LeSA)mJ9nF_cw6gnV=-qprj}$rlEDoMwE*C1jn$XZ_tl{9>0u~6^oC}I
z9tP0E!x%R7a4J2tX(=8~poe7rfg5O&{?LxzT+@b=;mGGkY>aG)!Bw5Q<8p`*^zw(c
zx^G|cqTP<;=miwC0~1M9@-)6YJHxRQ;a!AJ5WYq5BK(Qa3YC{SbbWj$(0Otg{Xfgm
zTu7etAH~;E>?~Z_o=^Q#C;O)ku{4C-xwWq1TI!#e`_2AYuk_EXRhIri+H@34L;A+0
z)IT-UKQ&r5I?Iz=uMcUXfc$}nVMtTiTEjD35Dv^1dbhQbK4Ve;0<LR6t}BdPMKMU$
z9ltYqHB&8ywkR7>uGNW9ch_UQ_Mq{q{kXcJk+s-DJ~i|?WGlgYs;R4-SN{0k_>~zw
z+)fQg>!A#7n06_P5V1rQRn#H|n}Be~%6!DQRwXKgu}v$&4^nq!#!YL_XU5a5YjqSg
z=MWqoUN<ePu{5)X{%Zgf`12Av=uh&JG2fdFU!^qsac^519(*UAe>GOCT|%EzMGar2
zeSu!k>k3|C6p%kR2@OwWYb8%x8(x>Tb^fT&4;2Gb@cq;a>(aYpWYkw=By)tbzG7f1
z1YZ0|eMNd2$K}?q%joM6jV=eHTo1dv)SuwO@hdZX5a-RUbN!Tp(+zQwdcwH#@Cort
zN~h1sa5SctjmM<`+e7QMrxL+8dKN^{{Y<*=To6t7Zn{6BAcgLW>Ar0N&PA-(Zo$3y
z{jzf%St#aGgmi?{5Jn^1jNoY5GODHci*DJXWy=_)u5_!@PpX(7JejfDql<Y+mt|FA
zKB>{FF>Wvq&^H&fEz7ONl8F0yM-)a6vu~~RDpFG?FvOqYhQw;QT!^=zGe((~k0Nxu
z1aTyktQECtY{Zf9)qSYja%=nL#NF0@owI@8UCQqos*~uKFiJAxaJYOF<r=_m_L{3D
zYyVMeyZ$_>usyoYwI&4|yk5gG3ysz1(%m%}vRn%$tkWrK07n6gQH0YatB<E_cceIq
zlSF^CKa7Z>-jkWK`%AoX4@vRsZR_u2kWe#OQmN}XYyDEWe%OK4Sly2*^ZP2berXi-
zBuB~m9nSSjbriQnt@HtD`7NbCdzs_U_2)T7XCSL5+Eo?n84}~#3JG9~JFC)@yQN)j
zWl<tZ!`#`Le()7ir~eoKz&y{u1#$5!b9%V;oF88T-~u;CtZQqmCp*UV9afI);mWzO
zopW=1$rJRRNGB<__a_199mjh*CB2v4Yts9@txegX=Ucw?K8R|L0TuH)jmm9A@7uKP
zZ-CyZXJT_e??wUn<J*JYscdcL6FR-`7>h{_p6IW~1s`<{F5HZ14pPqf%+*dW_@X{n
zue#5y;)6;RJ<BXr#9S?_c=c-vOB!UUqEUdTB9*QE{<y5-ha^aVn=@a=kgs#?I2ZH?
zW^qdVJ+JUfFpMdEo+gG-5{C=g8FEhi%4k<ze$g@FiA9}y7Ilb8@hsOC#a3jb;iKu}
zM^jPMY{=Q(wWoJc5BZc6<=S&<(Q)F@wK^Kvn2lqYrNMaW*nv$v>W`jYbdsz>MwF|r
zk68!oKrrjj4!NqYL}8u`{3H~cqYBSao~|$Kt32IYc#`r|RG6$hjW0Y@dAg)X|1L-v
z^j&3CIrF>5pf>!(^O5->kYT_(QE#*k#x`<RUyM@GKC$8{6WQ>=5Mt=vnIa{+o}Rjk
zl$e|7iCPLN<HQp<AC*a35WLf8cJSo6b2A*TK9%9vg^-8)6}XN^_yA!$!j}jw(3_4n
zZKB$Uzi9ocURtz?Y12}VXw{}o>o#p-O(w4MZ`ea?SlV;eh&e~Y)b9EzUC5qi#NYE2
zD(7)(n0M-*<#}fVF2vtGXbOmSJMN+cc>X{a^=_kwS9F0cj~-Uz<4FjFtXQK>71ABa
ziZ$Bv`U7Oe8f}^W09mm{`&oa0tXQKtFqEi(BzibZe}Jr5qn$1u;+Nz$Lb`4Zdi_5l
zRJ`fGT<3}`(2W+c5NNxXe8MpoBBuAMJRBZe>ih!)jjwPNphIf3&gc&z^c55gq=@z$
zK@g<FJWlVrK`m>0V0OYF!GXio=g_>1`l3q(EKsKDW~Sl!xJG-=NYh>~C&fsEql$@)
zU3KFNvE;x#G0#hij-=VUM!TPL5|F7CCcCKW7@G2?Wi^y${bgjly0C+hF`d%wbx^v!
zQ4DR`19AE<%vZ5!sy+A;%*OmBz5Htcg|@YzdM>CwDt?KxKD!`?+XJT`AZO{ILux&_
zUT_e1uGizNK|W7*O1GRo-Dvf)t$;p7`vlZ1=Fb!9Jq}SrN+B0+%fa{M)=XYQg6c3W
z4d4scJD68$%=M-<gBQzIND>g;mX|j)k~mYN-73p3Je}s>8trP1pxN&P6i!k#Vuj?p
zZCF7sS$wv(^kV)!lAmj|b{I;O4(qy!XNZE5xFG8I6Y1kHYoI*WnnZlSwruVhA!6rf
zH;IzOtUCP*(B=Y!_YvAX1Ny~v8^Wo$Z@~2gTz|tg3D>g_9POg;OOAHtUo_peXcr@5
z@Sb=}yO#9Ws&#C;cG2zHv}@Paq-I5)5UT;=DYPImlIZlF?1o1+XRRkQ4c}6$uLIzt
zEoPV}DqA~aJPTwz`s1h0L>aw5$#dt{m!ab!QE7v#X!S)cOQeQP;%Kp2?UbcNYP7ti
zwG(ipU>NuXh_W?#;C?7z50bf7_t%cRwh@!DSARN}pENXWHf%_HP$4f`R-<2Xt?rYf
zUCMr(6ES;Z1?nhljS8>J=pI#lj-I~_^1n&b)eV~*E!J=aKmV30C>KG!kWhON14Y!C
zWVK^a2$ueoOD|>ZH6)(by3>1c?@0k)Z!eO^vGhZ7N13w@zX5scb)7$OBhW&aV!QLt
z$VPY`v6zOT3V|%@8Xw~*>Z%>h1FRlD#8XnQY%OVO6q_fr5ZMQjv@oc?k>?=l9=S}z
zlr6ev_U&f(U`S$mB#}DCJp?7z#g|7v(rwKqhyiA4QPmx(G+K?txU(_xkqW1xV`}Sz
zcv|Eca-jabaYFuct?I?!+6rKCv%`V7;BOtcMD6ewDHb4(@u`g@8r4B?o<zESR6CUp
zW``OD!+{>t(7pJm%pUY{o{X4mPum=AZIS*_L}#aSLA@MB?X<rzx$?JAbD?FRkEx|P
zd2)IU({9>IG7zn1&~nvjNa4DJb1gP<fex5e)NAcUwUN^JT7_O<sWFN@LoXKAh*(2Y
zAV^4WpFwD!f&~1o)(sOpU7rDhLJT>giN|=Nsn?F>Sf&)vL<z-G9U+9H7kGK+`txeA
zdLg~J>e7qAD<KS|65&GFAn_uVgof&FqHP^TSQ6<%^>xT73mL4-G^sqK2}{%8P0Js&
z6ERu{ZK;!2UxAlcl+|g^T`AQkkcXiS=&w!18mtGs$Fn;<RgZlIv8aPPqgU@$Zs&5h
zb5&W^a#j=01DshWc6{!9%1A!~I>AhUwSwFE4%Q0pto8JikqXfrMbdOeGlclbTdpQ9
zpy^MC@e@=AT%BF0AnO_VsSBzB#UJ%NO|$DUZr;I1)u6+K4uTjlW&^}mLYcWdTXX(K
z1EV`J=X&iDa7`Y)g*1k!^^3ZQ+G-1)Bbj>(Qeix~b2odOTTsyE9Bq_PY9PIskEyL?
zyALkvD++GJbS3&6Kta~$T*2jS<d5#<c5d)wZA7Iu4AZvh<xwN`V)400(NQE<)N4CX
z3RkC>6gX*Y$Yj?;tTms`g;;Ao-2}1Ld^*3Vy;#^U6$P#v*aJeCAe6<E6c(clf3bci
z{e>9KS0JmHIi7hLwNhseW&Cq`9`(h(shB?aJvaT=kPf+p3J=M@OVFS8C*s6!d<_2R
z^BZP<)?=JC&nJcXo`3&X+xKV~tZ_*)M;k!82G?~6-N=q-lrnXChW^5rzh~U3^1Ri8
zG_;|MRG#-TVzoC9ZQ+3OtAw<Ky;)OLgJ@Ra*5HcYuYrW<D)y3!P+M&-3-3mqq}ID|
zzGYd6w1c>7W3?gklx1NLj4$p}K7!ULAiwGetX!#V?SJ>nW#OTy1!%K1)tp92T8?(7
zux=3}hSKsUh-;*}Y&|X;q=lv7s8?C5i_tqRBe67U$6BsE=?(Kd8HvE}?O0^QAOg=%
z@pHW=J@FCn6?c?7Cx(|(Vg*lXcWws_S5!jN=Ww(G9b_W4|I?Lr81u5F9pF?porno5
z_>5<$9V%%BU#Xq&th$0X3J~qUhopRZpWY6bgJ|ODF3^E%v96l@N`_+wLIuJz`jze}
zypCW9OSsX;M|ZY-_kP!n)oE4@SP!PJz9rDtlO%XYAIBt2q*7X~M2B0%TRin4b_J3K
z@2u2f7c?~Pc!gSo#8R*c*vGkrXu8yRL4oBLensn-(I<ZDRHUqMR^dN}(zZNLdq`5h
zfaAGVfy;tn@{a*)^GkL?tFo+Gh{jdJwA2^^6hLU&;ws+aC~D;@u5uKCThvqxOvKC#
zZEy7{$SQTio4G2n;C;G;Tm?Q#^Xz8rviYd(D9(bB*ZV{5#cR;^5^$im5BNUK@Se=%
z<FjH(c@qe>L^72@zdR(9+X2Era!9f)P<bD_dn11E_;gyxyEF6@{Jx+uKjo@S1DfDX
z)O!b@gjxfXpiSOMwlc3k<)lpPBmg^iOiE(F&QGM@^J+t3&zm+ds?@oYR!KX-tg?2x
zvox&_GRMD43*Owg7Hg=Td5ZCB$4~}zMC~XYwm>yEr3Ae_;;=}H6YI3bbSk;=YW#eo
z)a9ND!UM^*aK`$uKhZu*9aWhQA+&ROOKZNhJhQ$TGsmmHLyK<Z(MJ2(+4tHVBiI3I
z9hQCXy!WJB!}h%?EZFReeQ(<H77B+>UK*=LKB-Xn*-v4V1+ee+Y70)s_PyVxiGpC?
zBRw3+HTQi$m4&z!KlM|J3T)rY^F(98FXZ7k*BYptbPJzYrsVVlG1Z5(@s;QF#0aX>
z9!=uk)@^+CTmzE-xw#@|<GWC|X4XX&MQvamqinXWPp}L_jB$$=H&<;o)5gcm#x}lX
zZll?P+xWUK7B;>&!FY7NO`TSWW~GOr^ywWj80Z0dn>uX@rgeHal^%BK4{YO$g-}6n
zlIYD1`UBhe&d2<WH&z?paHzB?WqUqdmYR}{f9-bQU~D!TNgLn&Z)7;;AiRjM1Ys@0
zMue{senKEVuG6Em?`6HOkLHNl_sZv4hO}beE1N@oquck!qN8Xs6DDiZzBfA_Lz?Y-
z$CYwH5wq`=XY>RQuhULkXR+@w|KNq6A7tL(A1ptmh)E}M_N?;Eo{|Up+OtNMvtBV1
z7hyk%Ivm1-ZqM39b}QYUwS(?;d)C)<-&Tmdn{Y2gTg>stqL{7-?GaicoQ5y}q3QOl
z_aEghl=iG+9=EY)MMKaR_N*7q=B2D^&nn?UbbHop3<@C>!)7JyS<hBC*xIw){4S6^
z>t=pqZ_h$&+uO4~!I%(>7cvx|j;U6Am7{328pxh?OT_J2miqbHv#zn!FOBLKZ>e8%
z>{<Ma`)1Dq-#=jXtSjeQ7z^e~X)Nk9n?|K>&pHyLORN^G_N=9cNPE`1E}gMN+@AH;
zla?wf_N*DRsEWFYz3>sWil#k_tH}1O&PElbJqz56br?4Gte6#S&#GK**t5#5_AHAn
ziI*a__N;P?J*zw?+G5X&VHuT_EdlIV^rNOdt2_gbiaiUv25szF<raGuJ(>0_dNS=<
z^kmwz=*hHa(Nhq67JZju&$1ZiFcBYEd)C;uG8~i8Tkj&Aj{7oPGZ7v`C`Wh^;ZuYN
z*t0C_H7^PFFm%N8>;t=XC0n*CUB#7#Wvh}bTdRa+3l~}%EMggE=Z?G3PV~H$C6}Gm
zP^x&fci6JEvl^Byuhs=RKw3e-vgOr&Vw2TQl90UGAz0ed8%RiAEk%ETgyhvO)E^)r
zd9^(K0TPl|o1i~HLh@>J!~>QgJ9W#}OqRgC+S3w`z@p3~5vy3XZbS@e?P?+G*69n(
zf&?maJR7pW<_jl~2Fj~l#}TA>O<LN6zgEk04<b#T#x@<Tn)Pm8?Z2Fm3{XjLcB6#3
zNH~<%GMZ~u6qI?@T?ljH)ebj);)rD_l+cNU7m@zgSl^;MGJ5KUF5DAW)eT)<?Q_-8
zwVe%J+hOS1UYfNH)&Y@`4PAOhHgx^S_NgCX==!nL`8{OHZMvcBdwkf4rM&`um_8~%
zL$G$qlDV`WxU?T&?aKNg2iC3&@kLNI=f$tw80ceAkY`9rx6D4>vNU(rmI7!Cy;{7q
z^cBHy<Q0Y^Sjot6w1o{vUTHWwp&yA1iKv1wg0U*nnnTN`#XYUa>tNF)k;kjO0(+4#
zH?pb9t3A#UWcYxQ%`3DJUSVY0k^`HUEPt5x`kDNTq=@rs7h{y6hOY52da?Bk<C9CG
zK?3WUmt<BX6xOpX!=V0jdf7OatrduZAbGKNz%vYt9&1v_V2i+@??IS{@B_jugp~+!
zD>EEhaBW2R0O5CpBN2B1?O$Z?hB5@EkEq`7VXt_7S#CX6bFde`OIkl_KvLs>&ts-W
zdw7Muu4L2JhZIYyn>4gZ4GmqP-HFNZBn;Dz9;zEMsF2aHXw^^N+K3#bS#|52e~OGa
zGTw`<gsbZ|9qp9>D+sH?p?&GEEnQ9OZfJIda$6Xjw&iGZ|DdTh0dp#8bBbXIt6@Xf
z@p+hJK;?h1_NKo!9{I5mn+;;%Pk-dO<3RUZ^c8r8Y*6U4Du@kWEHj6;cTKrZ*P>hO
zT@%^9PKz`$`USFgT}ESzj0&WDhq^0UO9Nb%_OvJ#DyzLqEL)(t7WS_7L-ZD<(Re`Y
zT|Zu@>VBoYYx-L>3govo)!v242P*`_-nH{w{iBHOD)z2^m_Cf=^0jx}xsFCa0DIRi
zETly)5Ohd;m&=RwFe#wGlC+n~czvT=H=)>KOGrI*kp$ZWQ?J7cvR_tg@oA_%AVXmO
zz%<m*x5O`r&ekrQN{D*EKcNgI;|<^t^?1h<M}74&(h4dXGJQR6+Ru)W_OoSjIYNX7
zxtG32JC<W<MMA?13Lku(Vn1VXUbmm|Y!a^hjHesje#V6~&3=}L6`mLgP`a>*YS5rS
z_OqK1iwXy@pY<6nOQ6qPM9L~>IQFxirv2=cb5#4;r%s(|aCH`=f~Ng!J3lqWe%A7H
z8fd!xEYse8cB6*|&lWU-kNqt5K^_$}NVsEk`x&>pVL$s75|v=K(tdU<mlwc(Hcu~)
z8p+3g_9aT;#@lE6*%3mK@B#{4dK<HTu+{XQ_z31(V@D}`OE;n!`jP^$*m^AsS%q!u
z`x4a3s+%?RQKtQDg>Ndeyc8<$L&%^)RbblBb|6mtM*I}N-!SvD{jB&-pA_bMrmrh(
z-=jrs>}OroJY1g38^C_{2~a#HX27tYSug`^Kbx>K+Of~}vpzFuz$VGV9u)goTeq?d
z{dpQ@TN<oB_OsZ-u~KIH*<*!V5Qs8>{p`OF@a`cy``Ntr|91OX_vw~)Q0!;XrPL0U
z!hZGx8s-1FdmH$uimQKo6E?EILKY1g1vNrcFn~c&!HDvbRYX=dktkL~v=-N(R%KUE
zi4d1mmUR`Y)R$s~M{V^H6<c3GK@+3|6l}1xVjJyZvCg`&O*NGj1NnW=nS1Zf-PaJn
zr~kix*xWmJ-p=csIdf)4Djf0{#MjRl54?W%@Ei>f$?IngTP9ex<6n1x`*-axJ=4E$
z@J@WL|EKW>>@8X!lB;GuteVC2RWp505#j(6HVepAGps4ms+kbEINBoeYc{<&MEvWY
z5j<Fzp&T&hv><cpZW|9i7~n8;wUtd8<-J|TFL7QQMy}n#Tm;PEp%u$q?QU_wR|G69
zD_*8u&<A~K9IvmFA^16_TjgP+iWu4Pv`_#WFf4w*8Y?lb)^4sA^dxeZTrJbr$aGxL
zUkx8W_<C75`+C{6xin^AMn!w^X}yfk5}@@m+Uu{amkoF@^?F$W3a4Bzi$3t*vtIUK
z4u)g1PB!#m&`DdjXj_Z})_i<FToh;FkfeZ^1>o$g`FoWl=hyaogN<zh(<+QsHa#Ry
zsSgWMwg4@MqWQoCtG@<Y=wRw0ILH=2q$qbGzR;*Km0F$x%)Gr>y^-4~XbbdAfY#tY
z#CMVX=O1lJUaUn0kX8y?!#aKWiBOE%F1^7p)jX|pd6(YCph?dl?=aDX-D8cGqX8gv
zijmnft_W37JtF@mDpa5>ZzRftO)hWmCo!{eAbBj%6VsdhIv@<MzeS5rL!Joxw0aWP
z!UR2*pzn(qIAY$i1_F+Q_UIf8-na!>j_=oc?u0mSqZHu2&{h_;wKlBh3=!X8jmH4a
z$n0q%{7^mOjM)qvF^b%Z&lFPW6HH+cn7$MJO|vnBUeiL@Og|3mU(#GUrqQ_-XvTII
zyV$#r7;bCC0<*x6{XO1(_|2V<75{?bduWdWWhD4{vjQfSSl-t5D9k%94*yrkr4#oH
zZHX|x)_4iAZhb9j+|4wCY!*-ZX$0ZTmqt;~W~z{C6;t7U!g$>1+(^w+Kj9ZZfsK)A
zFyb4X92rB&e+5toEu+U)<e-IFxLgV;wgSfru-6uS-%YhZZ-aKEbN#Vl7(@^sx+NEk
z4E@yZ-#g6PLw+jp*{Qbw(Q0Fy5H=jXIW!xu5R32QQ5@`&Pal1#zW|d|OY|}-S1rpS
zL=uD4-g#VW%paTP>u+RsXds=hH4#0|_=I_w1+By?sH#ix9s3qXez?bnNQ`>wXQk*V
zTMsxfmW0ck1-Iu$Z)Z?s>|AU9%T)z|Dj4g{-JIcovkAjWnXCQ|U}L9_jh$!&*k~%N
zYMz7i9eVl>PIvCaewv1GZZFy~1CLu1h9v6EL+uj15if=(?hB>9fK<{1VViGI5W#(v
zb_4p|NJq3w%02cyWmyy99Xc2?k=-o@1=t@Z<LcmLu!)rmh&^7VJzKAeMc@@0h(F7r
zV9-{y*bzOC+sX9~s0M#v^o9>0;9N}&p2aP!j-DSq4&Nr}-&WDL<M`XE=%6Sp>^A?d
zTqwn=);)j0PGa~l0?y|s(|`6-7oXF$gr*$z@%I0R`nUXN$@<rgS+k*{;`(<csVLUJ
z56;S}e~s;!(7wDIvnRIMDQHdBzsS`d=t)sFasB&tE(P0kS^wUEKv~6@XZ<_pDFwK=
z{@qC`ob~T-f5N~W9{oF&n9QVqn{?@r`nM_aJ@gu>fkgewnvV1@M+HKf<H3OG^zRLe
zOz>ke!}@pJd=jv&q<^=HLHA_TzdLT=DjJ=e^?pkIyE#HTUNl>ofRg$balKOi%4iHt
z{U*fkRSCp#gU}tC`i-&rMM_nNRKNVG#Mg@|L$qE8Dr1aD?Ry*adPjx$UuXtMezNvu
z)pHXU+mAZ;OXZ90_N08{8dg`n6J!I4y7zUQ<Vo#chR<=`yOFjARf^%VZJsvlmb&*g
z*!uo0Y>#7XVckoLxtnu$z`28_53Y@*dnxXPN6}`&XRvBVSyh;HZ-P#CHurMwWZjEs
zcg#L^V0fb5EQ6K>HX;ae#}JOLP~vJ<y)jMo)*J9QI@jq$dy<vkI!*Or%L_Iii0Ax?
zs`r$;h%?rZ>RlsxfK6zEB~@>mu6ogqRJ|WB)Ku@Q)QK`~;Z;rbZqvW9T0T)z%dC21
zn(A#M)l0@>z{&b~FRR{FnvP)oum+}x8ovfR!Cwzu4{O#I9N(_nzNDo!eWJ||{cEPf
zfs*6vi;S?AV`A7KY#t;pH39S{9mHyx-w#Oeuc7DbYe0cEoic5NG*Aq~op!`T>#lf^
z=_jaI54P=IYmzTsR;OvCO?)zs5UHI<TMw*ivr-teMg^Yud9=4&&lSO0u$0=SeobQl
z(w#^9$^OoraF=)<?a7$AL{E=m!&&O{X#Z17EMd)myB=}4HjcwhFeJ4hF$=!GI_YrW
z`_TpI@O|@K1>f#Fv*COHbq9#=oA-4M->-GxM8ORBes-b6_v;6V?-z@J?=!%`hm^lh
zy(b;M_xTijhk^Xe{QbbSI=->^(;5EW_I=mz?Sx!JhhdXT8vd?Y!1#VFiMzA#bIpl|
zgP$Acr^D})UIo7k@5qMV;WKsoc2a-T?ClzUKX1>>&;PkW^79)9$<Jd?0KP{YYJR=~
zyLlCRP|?@J<|z1ffVngC^V>6Ye1|&6&%?g!8oqsygXqvGcDbk4*ZoRq_0O8b&e_Jp
z-p3yfeX-}xbokwNn}XlfKz3&Q&bV5~ZzuJ|Cwsbv-+qvTO!~rkH}mtz4--ejEc)UT
zM8_X`ef;RWbojmbRt3NA+q2<!|5a)5dnMB)>HK?4ri0%Sh7oXp$eCF1UNV~+!dQEc
zg&xVd9=1xL3g)h$oww!_@P8KrhD)MD(s6LNyBNa<h~F2FI~@2udu}@X_Wr4Y-&P<y
zGyneTM+c1Gvj21qzn6jYGvW8$d71EA2oEh{x?tO%Ut43NKX(kE^EQvaMZ(MBM;5>f
z)AVIlb++x{?Qkc-9~7%?u!8X7S~rCu)7rYD7Ux$XX)Z0YFQn|WU$?F7UQVP~;9ESm
zL8*JL|CXG;u(2z|oI$i0>OfFZtC$N%7yZrW8Yw_R3v6x`^YMue>KTUfLg8Q6+kOq>
zB#{CK!aYQd&~XM-gNw71w^!R!qsgn|a#}#bOby{NkN*n3o>uK;-CX#n$}iZ@8%$&3
z#SH{MfJE$CD|yYa>$=#ofF>TjTz2n01lWXPzrf;X4BK3*>8yt;JEm1Ow-^xy@#{;;
z1Ig(wI~D_MmE!ro<ytUz2~^poe{sw`g_y}Ya7Z(`^Dgd7n%p+)F)D}XF!-M_JHiGN
zwAmKy>;Do_sBHm9<TemVcB`cC_Pyv>z&%RlpbaR<F@u0MAATC2ADQ5PQicBxGyDxH
z;l~8rX7PFm;}yl&_s7i_1L~0<uBG|(o`3r{0B|flRM{H7v<9khYAtzLC8%}{)R~S>
zff@~DhtpWcNI~DV%N6*VeJ1#})u)6n1AXBv)aYCBsY+iI(dfJ7lT7rTo!=>-4<UWm
z{!)eCYli=wl<;SwFL|WR^zD|0z6<+w3e<z8@5fIl@U<h(LXqFE-cAW$2KpkTTchu7
z%_@CyP>)96$X_$jH`u#VKp#T-e*Cx!|Ltb@ajIns{UzypYfAYgpGcg(EYdOwI*U}4
zfA5%kj-%~}G{$4~;|aS27=f%L@laV<DkN2fn{1$nv?aB+K+k9`y}DXUY}>zs-sHm~
z=rbMfgwL$63^~@^3(|gNe-BI!B3p1gbWYsm!}5Nh{vmC@lE2>J7QKKlSk7#Bq;PR`
zss6<N80Q}*`J;Ll9uE6u?k#L~=)o(>{Khql_(AhWm3mU!FY)_#KCR%2Fz6@P->L84
zIe$avtnbA8EbiL~+a-f{<c6OzjZ%4|G<~1W-}ebtj}N{5eT-a;Oo898u2=Be1Z1;_
zad1%F-xtU4J?;a-@859#9(XmY?VX6<Q*p{~Cj6dyi^OjV?^721zKA__k<vpwKYxRl
zzK!53g?~doR`7f4PqN|ngiCe&-cMF&+@G47e=mKfYxr%%)`?8B$1iST{3d&wwq~23
zWBuna@b4AX>GZ=e?8P_qg9FT*nSbAQ>G<uGe&|5hdsq1P2Jn3*{=KhC@^1=nQx^Vp
zVGm;D^h3?RdpzmzyKSa|-_<~NX8g{WqT@H%8UB3-!Sh|gZ+Gy0ChyW4$I}p>!n>4}
ze~&-%aOj6e<zi$C{d@B@3Vz+!X2b9P$vS>Jr5}F!R@d<R8}NNb{orB#P4+Hj#qU>`
zZ5?|3dp57@r_#T@XDIk>1+p{q@2@UOgJ08n){;rX7P~qyN49W$erLQ(i6fj7oS(`2
z@vQVmCwiB%;&*-i;lS@la+xm$|Gqd~!S7NaJ2QUIn{<Hq-G(#ux`N-&v2P+1et$BH
zIXEqTRe!_tM=A4_>39j1AAv!KJTT%D-aL}l-!eCozop>=Afvt%%i<<?%Q;Ba+$|hW
zFy@|q(%phEgGw>~&x{Zh;<?I_s*c6*^6;z$fhd@kL~wQ?f1`<uY1$&cC%9R(@kWJr
z?U4$+H{nHr_pAGf-bwJv`PsEh{IvcRI_KPQuPC6wy~3ca{8JXtqD%D&Svt6EmK5+r
z;Gr`7Wy|rRz;k?Rc=Y*p3i`$UDLLB|`o-NTcWuo?zjZsZ0D18A`wng@1Kw45QQ#fM
z`%4apeun=<rysjdQqXVLAG3hgMfwd<;c13DN`dEU>}N>9j~VC}_m_-+U!h;zUGnC8
zndsO4VHO|{o_=EhqCvkF_@oqgZ|2P$Y3O%DO8GPVBYe*Qc|7Cp5sqA91w-x;9MDuD
z`o{qzKQ7%v0G7uSJB`}{IngEb>TE569~?g9QSxIwJj(c(<P>3fO!P0P{*0@xjcejV
z<<C&-?=S05H5VtJ4fjvY-%HD%Vs4o-|MxSw|EcCmDf7R75$DfOVf&}d|4SJ$le|(&
zxl{B%DEl*V3x&<+1}0<mLJbK_g7+#}fAUC}rv8g%{TcIPf2Fcs5vf!7*?x`5-?#7i
zjPjdty`r{}<u_@);yY{-O}}0-dpQg654c_tS){^0!wmm(DdErL&+hzs#ll~93e<!3
zXZKLy8+x?~zT;EFr|ahw^o@_ND}S%jH$K1~i}dvL4L;E+pbw!xyN6$)@6hRH_<wW2
z^fks?V?8R}dc}&zI|b^&(s#(c3Vc(pGQl_Y*D2x4K;QWI+wiVR-}nGL2I=YP`@&<L
z0{RfrcSx-Y|BuY@;~dTu_Q#=IuXyuO3Gm@vub_1e9P>k4rm$=gk5c9Ff|D|QSI5s6
zu9V|jnn=u~@#mLX{?3lKL7BhP<Ly-w4s5(Fkr6qa9&h{0{&af0jdDDST))9-vF6b^
z#d!YLY25z<7;nF`D*U<%FN*y*jQ6M{*^j!srkL-<;{*EEEB3O(SYBN6jv=nfqyXUo
zJgK|M$J~23=c_$bc-M6^!8;ba1k%dqLC#kn@@4_8i}Rf^03mMwV_&I4zng1P!jpl1
z@$t0cZH0dE;q<-rndrA_P8J{!e!g=NKs4ZON1(R?Zw+txNaEK_{sv?G%r;-$etQ<s
zx=6n}X_u`YpEJ}9&x>~-DE;E&<wNTf`o)LKo=8sbFKW3h3y=p-zko%7_guUv^jpsx
zGt$uSkjz(m#Q{8I^VMwQUE+K;{d)Pnli-g%<oh=+l*@!E{ISPhNc^R(ms>7M?T>Zr
z!?qCG8zNph11z<%u=D#jZa$sZDf^0UVl?GzBjAtCuws6uJEPSg=c2}ZH$A@B7ab0K
ze<YU;Q{ekWr-JXLKt8)*64uY-_&#sM0pfe#u&&|TS(+K&pI;*JoyO|wG`@L%!6Dzj
zaf4h&Oo8vQ<qE!wF35)O4^G$dov_|(TF;pkoHQI~pzX(c&ecP^hVMTO2fl};-@mcU
z#rRIPTG<{>&(AK}PjJZfNB4^vEh+H(33e44`lBAm&dkrZ4A=3y)MAQPNQd9vC0)a>
z4|0%Ef1D-xIgMAX)BMc)3l91IjYs9OVhViUJYK=Kdtx?x?;on;yOaAj)(`0#zVjdl
znO4}V(s?Db@blr>UvRcuR!o84-s2SfwgTCi`T18RI(|E;FK!;(HT*t%T4sGwC%weU
zE9_bDdwBL2d~`uNeevRX3VxRY*_rWs-f3y@n|}XB|5FLW2flw}A~-+O3h=~9tT7Vj
z)miXcb1d}nAs_GNI@96THCDlI>G|34`|02V#_#(lcMZRP2VFAZx7&r8@T;y5Y`IyP
zKeSw6@~?gJ5W$}`f6(W<Dg4KAf5o*g0~smyGkpA#F=0}I{Pq0|?@wTS{DA8NTW(U}
zcbef}niBp)vpx_W-ziWJ)_)wCt-xnD!?*9jl<;MsZ`_|z`=UzUxI^Q+Rhj4;#VHm)
z?0%I<wF-Z^iN5=AI#>$+&O~3szmau)z|uKT50<_?RQQHYG{JX#YWOnHH}3CP`GQK{
zxWnUEq^DmW=ym=NP2V0jD)b!+ceApe<M`C^L5FgE;JEW7z=v^tAkp8U`ujEiI*+4?
z&TN?7Jf0?&=lu~G&cjH|pMHMy)iH--JpN)V52GpU$@OQFylVcH6=$a&j|(k0lZX8)
zmz=~Eb#_0(iQi}^lVsVenix%Z!+-W=oE?31o}3+}Sd+<O@2o#8`w{LtHywVj9;M)S
z+*#T1`_B^(2*2<AyKDIE-j*4^kB*i2P2o++g5S_#*^h8)SvvggJ43;57|2d#ugCfK
zffIE6b}HWZ^wzH7_cvbyzZtwISDefEP4=E>`X#-7xcac{M`#?A4!=*1Q1H8OWH$T`
zKVHXg!hAFJeviNXvupUh5PYA>d$Olk@^1?7Nf!Pcc3Ac!+%P&Fe#e$7_$>l6XXf7z
z`s?`Z)P97gzUmr&zxWsMo8h#JQ@^4ix-0t;_TkdzLmw~S{p@u3{baa;-+CZBGk$M5
zPRDPj^uwhsUBmBv;QNgFVKnn^vbQ9we%N+c_9Oh}%yjsz8K&TO=IPn++vnIc_%-=g
zmHi0&z9bB1_m(7D5GRB4GtK7voy{0d^p<4B?~{jRKf;Bh(&6{`p$dL2VCKyH`_eH7
zh~F0@UBmD1qnYvhr!zC-SM`@1`*)nRt*<X{{cOLw-s-xV;7{u>$r#@;;#WXM@_vN>
zebSh2rHJpC-koP3hcmuo2tYL8ZQf;q_iEmMk_2z2_y8k*QjZVd;~o^y^!*66M`Qu5
zi}3+h0t5pdyBVI)RR>DHxIg5!<qG}c?vO8knTdYO^RfVW@bLjRh81`R;6;fKc=AUn
z;mt%p!~dbvFWr8G25T13x=6pr|E9n*1uqIb+pbIrkM8eCA%Agy$16`L^ozSYPD66~
z_>SgoS%5rv`aS=t0`GLZDDZwVEhW5?eupH!<NI6#z(W?_k?3Dg{TVNeh->0Q<<C&-
z50-NMo!*adx0XM}+|r1LQ0t#9^QW3CrOaQ36%E*?o!*bo>jR=kN?SH%{okL?^>;cx
z^8IaGf3l@PwQKf<3h!I8{*3v}`w_0JQv7xEhnxI$H{%G-4C80U^@e}{g5@`9Kf;Yj
zPw%fR`4d|dKj3=9l~YythneB$^Iy}9rye$@((dmw{L$&oPa3zQQ=lHKKl;wg6!?}8
zHNh9+^H!7K)Ae%-`o_oCzPNcZzMd2xU;~e2qVL6j>=e+4Fkb!6N)`SRGyFJ`GX;N3
zeVv-V#&~PcH{E`OnICov)Ptq(;}r^g>rOMl_actKOaWg8`o_oK5f7{MjSs-j|2z|Y
zXK(Km(1(z|kGoa)hnV5_ri5S8_tup1YwQnX`er{r>8>UT@L^nU$QFO8>i;qzfX1&B
zzU`FbMTwTbv*T%hnZMKHX%rrt0~t@>!kyj+GM>IL_`t@~yJh_u$43>Pvt|7m^P9)h
z0Jbz6^O<w;qS%M)FG<Odx;&<^hvVz_D<4$s;rM=o<B*)*9&UM=x$|(&M<2&NX9M0T
zcv0Zp=1K`~ruj^#=c9eIf!4+O%ognUHQ<?#7X_YuQ&Pf{fqwDva#u*9A4+J)(ftU?
z>FGE0rNd6YkGCuE-j5dr-rlL<%|t(Ae9Sf<t#~mDXkDaV4;7wuO(uB8UVNbRi;ssV
z-LKFuJ{&#~%tXJNR%HS5;OC>q0z`vfxBkHduWNEjcqRP~$$T{Uf&t(mn~!E2@67u4
z@k#3Vj|~P&yuph%rG#IX*A(_`T;GmZqS`-kh5LNKAb5&+slVbxi61te=J5+v_!020
z!aqAD{F45jl=hFIe+~OK-Tb8$hfQ<>)PuEe*WzAVgTI?`fWHFYw(6AdWuR|dA6G0^
z=^IzbTkgw5-|unaL??hgg!b)P+~gaF9|7<x{5PhAKNEco{cO-T-TcMTIZzLlz8{w>
z@U`PWdj-C)aKvR-=P$SYOr>vJVMppR(YOENADX@&<2Gi4zU>3d@Z;*W6!1&>9-8^f
zY4=Hh{}1OcW_^Cq7G*qZ-)tJsYOp0B1wM3n&uBkiOSfnxujl;5Z?J>1=%Me|osI)5
zA?}CMe!dbQ8uYiD;SKTrlO+F)r2j$g*R93zg&9HXqWu+URNy%mFN!_6p7(bo!IOc0
zaeck=UWI;fb$uL?)7#I>afV<<AP?UDdK@!KgML%+qQJY2_gf^vn~8pge$Hk;H{dMF
zjG%Rqep`O8z%w5&3OxG|a(`g*7q_2xEmY_iSI0j>a(enT<BY<LKps5(KE~<A2L0~G
zivn-&)bL9B9TNNbdmIv|0r-R2&uYBsEb|3y9N*N5?+NE)7`5o-Gk*8CjF$He2PX}#
z5Z@IL1`z%lZge(b+Z=8q+(CafIXiIiL|ESIiPN@l#31f*>z;q#UVOwk<Q>JK!pRfq
z#s*iLcy$q7q=%~}ynRE?CO0MJyheBI?T_Y%Turz<u1yrlge6t`AzG309NbIHW#@6(
zdfY(RSI>GfXWfUgRZW#twp=DGaqh!V5V09$&*ieXGy`R|tQT?Cc9hjR;*kkUT<tg}
zGqM%Em+e}T`+PHJ{XX93`(?tCs_&`KOHp=YJ>7(xa22CV1YEoQHMrjW6c1h3u3ypI
z3*Joqmb;UVg#2wZP6b8YaymZ{x7_XNK~mi;uY&(eFNzXr3s&&1U84ezr9Yy0`6~Fu
z|DmfsXqWV@zypqw@2IQyb;s+qcqL@bJ!`*qlL%cPaxqf1dndJPiY53tI44MwY?!}h
zhh@R3bVqTMWzLB~XVadYxGT}W-LmInTreDPZLJ<h^>*Oooha_VZVFUw4mx+>?n|Wl
z?<}^|AhE4+LNQvhM2A#kaA*@>(=k1`$hQ96fD^SbKn!m&m|>@Qmu?-X+T5#ZtFLEu
z5fx~V1vZTvo#U?w+kD61m`S=Eek-m6*~}dE4x%TceYNDx%onQ=u<BWeW~qkLQ3GGd
z?45>J|DB^O-u{$+DrEdkT(fDJ{hlT0$bZAy(;qAKj-pR?d_n*<u3^^h25AX^C-JhT
z6#3~0e(L!sTwssB<BAY{33lLx6D>3F@5o6LEl+5F>6!lh8SlI}sIL#2<t@;+%ks9^
zrOR764gpG#w})Oykhj$`AxYkBT-GFSuW?pI-gd}@BzfDqklHoL+sB+$k++ykNRqdu
zT-Kx`_HkB4-Uj@ZfcXAU$lEJ@(#hL>M=0`EZObNag<ofpx9%f5BX18a&`H)=d3z8g
zIxTPaB69|LyX?_Kd8?2GGRWKMh^9@Dw*e4AL*CxGC$+r2fhd|Z^0u4<Yz|!BevXmm
z1N^)9;)#}?_(y;Be;436gS;Kvr_1sdbL;Z9qeds5F}|JjQi8mVlL<-k_86Bn$(xh2
zD)M%{Oh}Tq>0H(%Z#QyQMcx+6gd}+@O73%rvnukoN+ui%c^ls=oxB~>O_8^~)@<_j
z+&{C(+oL%3L*A5?X?#0rzD}~v%G-%3(P?=*5}7l|+ut8fl($`XbAb%<_7v9Y66EcE
z8~|^~+oh->)%bSd6=~&dC_Z&%e9OILqUAjN`x^i5(*Dvj{d*n%O!B6#*S(Jp!<yvv
zI(@LzGp8O8@9f!S`Fv!mE}zzGbYdIw`EMRu6#LV`W6S;|`P@81N2_6f_T#LIe2$U{
zN%DC=mo>@f7|yE5=QNp+B%f|BYZ?!)=B$c*&X);?LOxe^PbZ&qJKE#+=Z|ty%V&6i
zZhzXMx_r(y+n>`l`}2)ns(fCM#{R6hS|?d&<?~XM=(K!JK;{hcIr25kI!*RxUs(Y1
ziF@Ny+MoIG%_qob3z7`^Trgc{q{~e9=Y`m~@Fv;D(*Ar~+MlPB{W%n$;_?Y2Q@1}i
z<(8uN!AYb14SZ1gWW)4a`acyDEuZ4w&nqWdj>A9ttN*(k&x*L|_oJxuy&m1WEN|9n
zy1YGdl}<cE-fDR$QRHofOh}TqX<XJc9zM%i6?xkz6O!a@0GBn%+ZN8M$eWM}N%9u{
zQBt43;;f3i*<U_n_U8y|I(h5fuE^V$``S~^_u}&Q*cVyk?Lu2;<ZaiLI{2NHx4)r8
zr{(QKWX>RO@4k{KZ!2Yi4DxnOpCoxZ7aKSXdCO;rh>^_l_R-L^^0p424piQbteR-K
z1pjg`pJ-X4{iSF6w+ZiA<n3`-KV9^%c(2mst$3PFJVW04zK~#lmdb=Ac@tMqS(Ch-
z$ypV7n<^8M<ZTs~HObqRoK=yxc`_kM-frcxrtz(YvnukoTqYcf@vXs<PTn4kDe`vL
z-fZ$Vcy|_g`v{Tzar-mf_;%anI>|aKZ$CwePRrYM$ecmmE_*3a-bTm*8RYF{dy>4}
z-&>Klr>b;DGRxZyL(<CI6nr{RdAk>*%-i^P`;`+dd$qsxO#jZpza)86?a#N+;cWIN
z`B%eMFI}WN0fwr7SB`fy&KmZAmh0_@L)RujBcqBvJI6TfcTlF|xj?S(D10oFAN5bU
zXVhQ)uF@gh|LU*T&J$QNK7QFE@*VJZ!?P<JNh)u4A1n1|xbKnu%Nf2iK3(nFy~JBS
zYM1K6*L{rzR!p>a5SQxK(lx=`#dd+y{1pV~{Y&sa8@=q}cLR%Q%4hp-U@=Ykl>Nif
zSN!~G?bgf#DWCTIYV&&Ql_x`xTM-LFmnqNRPv?~y_b1<c5s6RI`jx(3moa|k-*gLA
zit~nUM7p-%lOlfRdz^lR^^hMj{=Zm-f1ertNh#r%>pz}@jGu9I4%CB<uefuN0^jm>
z6MUfyQ^J>lzVY?gzCTgviy~S;V*s~frKfLyobL3)()Z4RD*WG@;m47gDfl}ReU0_m
ztno9YvpWUq!P58flN9*Y?KQzC&tp9h`HipFj`*=k-}r*<^VemfZy8QM`eEt&c##VK
zcV_tceAFcPC4FyADZd9A|34YW9TC9)HSse&eyyx$uY1<Co;|iGCBN(Po-uyrq-&WU
zu>NVfpY4g620NsPpJ|`M*g2f>Gsgl%WBl6sj0s-Xi7DZg^gqb>nUk`C*2VaXivWTF
zPy5p*cxp~a2~P(4#r5^I*C_OhtLwka$V9($FFx$_yAmK8@Y>DrhK^4OZzlQ~`Z-(t
z%(auVfYwF&1^!2Y=Uluf@g(a9q=Y8}{o?v~<<$!P;_CP~B&Uy`nSW6hAP+u%=JAyZ
zyi@R^z`Lz~N_Zvx4oUpXFA@C>^-Buo2aBKaY`uB1MLhI5Pt(-dhc>^Wt57k=af@3p
zNAYj8D_Pin$M;<Reo2<^!_$6;rxx}1N%K92dLUZ6CAO~jFQ+;e-<#5XufWHL|H#k*
zuOU~5s6y5;d7A;YH&58^p|h>g{54#G^=V4ireXU0gwp^wzgJN1j(*-VCtKhvL-a~J
zIisW9@qoXUCC+wZ636*R#^<#BzJ_8aBog`E-(st_bo8r7eF0~?zoy;dvz}2Oy*}t{
z&ws;K`<)Ay5_u`5GFa7)#BLK10}{h%UpvN)^EUa@*|;+^|BVTSV|$@5oN_Wvf$sG7
znM)-L-y}UUdqW>eoS!pKwvfv!O3HLo!dKnlSvYf&<@%KbjT^J8mDZV)EhB&L4msPd
zf0_~n<`^CBkgHYD!Ataa5Sn#+!bKN>QXT!)F=~80=}Q1PqApJipXl`oyt;)I*}>*;
zW%z4aEHdLv%2-S;d*^Pr5fG}fJ5VKpF457?vT(Acqe@WubC3(3{_6v9Ojs;e8kkn*
z^P2yH*34``7qV=yYF-XWzW^rOu6BW~<vN{pmqYwJ$|Zi({S8#V7>JoADjAdG%Z(Ni
zU2@&xQ_QyD=@3WAZvncRPsOgruX_LRk=qO6c18lYqu*xW%~V46NBn0RbY(1u+2Zu;
zS5hoZaFVBX7x@poM<B8+Cu*hmGP*CeYCl4l_Jc8r?uiuU`oyn6J<WqD+g*xw!O_>B
z1;($kRSFz9NPtK_pRRO@%h%S}emv*qF#H#2-V)7C<ZprxB8R0Mb{(lW;PR54K3rRb
z414~)hW?anU<`=nKaiN(M&=R6>GB4CoT>6-VG=+3YaA9|p?C?iK?#?g;1W0>h``w7
z{KgWh`ld4Ebbx2=6(Lu%co$s<_lemk5^#!ORSUwRgj-<Iofs2AQQsg4&R(5Uog+R%
zy-4Fm5Sa!1V6ltwla>!n{8YW)GkU^gM4OEsX9(5C-IrZ{1;a7I8Dr6Em7*2+31Z*E
z`LE|SK?{M3d68UnbuD4~P14i%_0-f%&>4nTXpF^oIdJ{z2by~OBINo)+=1?C>g}{(
zKT>Cvf@%RS5Ijc8loa|-#K;9*&AN0ods=RtY!Q1e;e63!g03)PxX#J(_4dT*!!G#&
zt)upi=qV6XTqM>vP_+ZGYi{wG#Pz$up9t~#JPMKHd|E9Q-;tg*BY}hG@FUKuW+Z#+
zDP<j{6w4HXX_A$Ia%^G*V6843oM78z!TqDHy3AiQ<0@USq<oM(Lta_lNkiHL6R=|5
z9;|W%Ds&BCXAO{o|DaTDBl{7*Rf?;(F{R@o$oav4<5d1DNaDW`2857nw|Ej%0#}8=
zd?8m@0AqO7n2TgwAo&~dD3a5tFcUoB;3+G~cW%|e)y5wKUZCG$(r}68hjyhr_;p?q
zzqY00R~IR3flVJBI%B%*0zoPCN}M8Sw2Sr#x*TE#Uf)e3<OWF^78&k;qCWB0*v8NA
zgWn%505xs?`l4tz{3R-Jeo|B7L(~mS#Yq>h592EeTYTL|)<+hhGu2gG!chpNN@EZW
zxmCAYN7hGg^n~)@pf4YUVGN;)?V+hXax29R%ZOba7<2tKF^rtZIIh~_SxQ+~55zM5
zj?wtBjkyRy)$Xs)VO5490a1=nDlxbC^+VK>!!2+c2ObKMs8N*r&uVn-4ifI1l>Mj9
z=SGhWItQTYLJW)rsMmpKdxbb{bB;1(aDD!kLh;Rt95N<|ITpLguGy9AgQe2O#DJyJ
zMhXQcCXKL8;DF2tER6^7TNCRx_fnV>9mUJM-iZX0R>hWF02Nq5)kU77;>MR<`{G~f
z@FlVkKaF{h+<;*l|3$qr%D0soB|E7Ve<1>`0hb*A2YK9t#}&6tBHeT=W3@V0oc9l2
zInod6g`rR)CSzHu(Smbp<2gM8KrgOA+`oxR6!<rH5R0%geQC>_iIy+$?|1mO4gYlA
zOn)_e6^VDBB7DU>AE9E6{?#_<{{9aU#R?$Z?P39KR>R*5v1yNo8D9YqNuW?_Exuv_
zDSEe<`&6z)oblTnKnOSY6hwT}_Yo*XAY%p_3r?8CYNB2A=hT+KBx|Uuy^?gul}K?{
zTg7eo3-$~-+tGMfe9g&uqGypzMvbSVMW`35+{%q7EFS3a)wbAycui?ByW1@D?GTB)
z1(><mB}b3(_z94@Hpr~I8m5gMW^*;hgGY&X3lS1ce1BAE8D#+bLF6u#V<qHd<Ti2p
zlUN5-hk8ac;}`nmu|$2+VoRe>NK*3`{RMrg&J(WXtp0Sx0@<HuwRnd?;RGwJAaZMd
zL+&Ks@p!Mj(^`5h%=x~M+bUadg4Hc7OgfuM4fR5$g|bp8A{suu*8|s||59&9iiM4=
zImhD!IR+BWR!r6A`sV>%$5MM^+_TVJA5L|PHkmh}Evr~1D}I->3Do(`OPP2{D$p<z
zHGUkWiAbZf1&BcW3<#Fb1cMC6bSa9_H|P?0eEl_T6f3`w1VKuXrykjKLHf^UCP6~p
zVIpT=jv+|#%$}W81=S<Q!A1h>gX-6cXMi(sj<APvEaFj|M2DDn@T*w2od-;vNkfA)
zj)ai~J1OLBCBeaS3s`%r7=99c-c5#9(6zfl+=J|3aojepbB+doDMPHXDCusT25s^D
zh`^Exng#T(5Y<5f8WW!$N1_-LzwWOK=s<BCCTEQnti-}1VYNdU{)CKZHL{H=yE<N@
zXASZ}>Q6Q*Z5Pke7EXxRZ4fcJN`0F6{rB-onL?Cd1!s(jd0cr5?<VlfR4Ok*|55qo
z`}H2TiRq{`gt(<*NH@oy`_2#^rE)<erVN*H#&%JrHF6X;A|f>1^AIai5B`adZZQpe
zE*YzGRzV;B#2@~E_+w1pVN?#IDw|Lxs6pRf!}p-u7J#wk+zr}<E5yLnM131FUqCq?
z<{I|V8A%(hl<*;1af^036l<fk(b=qb^na0&zW*HG3Dwm&fGp^2j{bz2yc$h5(xip6
zJcul?M=4hUfm5|J;GkUhp^AWW2c@@DY1a-?k9a!|Zvkf$<(a58Q=&D~jhkuG`G}QI
zT>lZ~&H9gxfd?>x^JIMXW}5fNoeUFw)7B!prD2zz2Hoexc>g@S6LP$Nbp&LjiGB*t
zz@YDPU`V!CiUqZV47*!g5F=Xz!~B3oLJQ!xM+TxTarNUsYP~y9R|q8<4AHN@p)e2{
zK(EXAb;E$bGCN)y>voexO{F<^-aw!&P*=>K!rG_Cy1{s-CK~ICv?p0DdQ=E44Y>#j
zWEOuvl@JLPw3oy9tpP4syPnEZBXiCI0xE-CzgsxzY!4!S{-U0MnhFNFSC!(l_@{q$
zqjn3lc18W-9Bo*%H`XD9s)Ohp?J1wBkHHY720{q;fOiY(p$^yBb-2ZaKn=I%tMIR<
zj~4IAp%8sTtArXO=dkA(!vStIIw*Cfd8~`=GLwHj_s{Fp^71GbTt;ZD6emc3Q>YF{
zE}<WP>&?te7F;MqNfjFM{tV<ra84>QM5Pe-=3ru$zi1(WMC0Ivr%?ZaQX)bA8zK55
zJ09o>zWL0|H$}uUjD6iyH1+8&Y}aR7G3Q&!M5e4-hdxJ(5xdqQ9gVjRWHhpl%3t&W
zupe4RP*jSuv>sE?qy#ol=RhZ!&u4G9<iD|~Unz1jy(v$K-U1=q5~giD*Z|_uTmBmb
zIhEpPZPYcZKj!n@#PZV+HhrI^fA{*P@b~RuwfKel=UKjCn)r1KE|b+$Eazz7(V7J2
z#*?9l%C-J>3)acZc8CAFVZJfEH=^OQTs3*LZ=l>Vu^}(sblrzOuqKfwvJb3T)L3W1
zGsp;tSxSbT43ctU<aXd8+Aqj>a*OMWGm_W_4pvk{77{;-9s5k;6BrSNdL!3x#J`o<
zB1H7j`R`k_PQ7i1BrCmLfaD-2Mm7>Jk_O8Ko-S3ydLkIGpSgF>5d(%;@EdZVCv26H
z0qg8&(k;HDedRP+S@;bzV6+zwcVyw8MYo3!2uf{*nJ20~(Oh-uNaAf0E({`?R=jaO
z)d#IuD(jQq19dR~qoMtE*a1OKkhbJ059_w1W)Hv$E`a#~+lRoX$)q+}fh}ED<)|6Y
z6E8S7;CJ#2H~O>?-SIp|eS$Nfq8<8B4vC^}uGXjJUrQKY(oM_+3s%~%7SEkVo#SY(
zHxobl42*TcqPw*UFP0U?M-}XkThwzQdJV#y1f<k9&`X79E2<z{)s9|4ha3fggBhbs
zBr4B;<9-JXm2g9y1W!io270OVG|6&0B!302QBI#WYWT8y-a}?`@}TO)Ysf}}N6eo8
zMqh{knNnm!#`}m5BzMDow`y_+Ug9+L`D$Ra+<?B|Oh8|XpXz))Yd4xHz#6n^Jrrwb
zV>>a>`Tu6*YVG9X{C1~pR^SmE0fIhw@kg6K5k=d0`q}1*p>`fl$FU})xhYS(ZLs$v
z<4}fX&o29{V8M6_Szybz5;?}rnS!ofZtkk(EFx44+=xz&V^STfcW*^2cQ2o#c82@n
zU5LB_3ZdQ{-xRL*g8Vno&faUhW6{7h<_78$8>rnt^sN-XWn%zX7$cjBUV|EQeN$1R
zW6mYiD3IGD{|#5W|GS|+s`)x|%?r;aJj9r3fnQ8H8VGR}Vwzs_-~Pn_MDu96J4AMJ
zC>#X?WbJr5l4hV)_E7oc+yHElN5L#3>s1?x`K7kSf{{FKA6?#9cdn*s8tV{HuNfGl
zv?uZCQcMQwu+6z6$iI2>FcJmo5Ssw21p&bw00bI!FrF%^t3t~Vbkrerj5fU_-5{=&
z;~VX@1vAV*8T7Q_Gjciyr#Ol#w3((@%lZhmi0??qZ$p?SWWn;BqDTpf=$VR-Af6-D
z8K|RvdY(m>bUzNKgr-=m6=FGT9q?v=0ranDFuDCtt!RH4z56#<1Iq~NcxzL0iUP|D
zWfHaiNbL$h2s@3FY}j)g2-)xqBCe)(*(tQT7^1QhKl+rJyWtLosO}0;sjHx4|H)L0
z1J4-(K!G-ZVR*hjk7nKe?<V?A)do8rvndgHISSkj)^1$1gt|rlMF)iH2<vX~eGAnN
zoKcQ|%z-(7ZhqZ4=qcfv=@gh`!%$1$Fd2hWnqtAJP3?gY0xUWL%Zl;aST_#8Tzh_y
zpBdYf7!1*GS%@mg4{bsoG$!)|L&O%rN?Tb$1DJn3*Wta;^s%5JSl(b=%PUk{EWy{P
zM4+HgpuCSYxQy$UosylgHw8n~pTLwRYxL^q<)$q7IJL<d2w5n@GAlLBUDdj=tca^_
zfB{GkQyZ)p?dhqGJ_JKlAi%Xpj)g*&RhKbh^6UNuxT<NP67(kSMBd8k1s>Z;(1tni
zlq_XN9Y97Dd3YP^Mk9xgFM4Kt@xyxhT`;FO7@~*#Hy&|OZMC0~$sFWz(34I|i*EGn
zCw%ta3<tH|s&G;)BF*G{g=-jXn7=G5NA||@p0u=Pi5{Jt&Rt29Zq7|Gj<W@<Jta-H
zOFp6cgH!uj1Mb4;Dd3?TUmt~k9ML0@mggfrgL#X*fe8h(U3Po$p{2l3V3~u8V>}9m
z=m~Qkdgotl1!5VcfLEaxuT!L<ka9yBc(9}f?_atCpj3#W1#IskD|ds0F(AJoD~oca
zXun71AwDMw1)oFN{2S$K*Hgs~cqsE1t-^b}#VL-#{`bhW)OT`z9ehX_t9*kX+L~Xb
z4|JvOS9x-~;#c7g8VYQ1g;*dPH>Vd@h#Qo26`)JC&gyEgvD{IF=3%`gh_|M=y!IgL
zF*&0~u7+I{BP$aF<vj<-lgfJ*&5*X$djZ|HqB*i=FBEDgFlYvr=62EsXTulO`s*VA
zdI`a=dC1}45f^c<;T@MwC{pHEAqx-aR``>HRjvLnt=qp0RJCC2am8j~Srn%m<Pw|0
z>SAu~!S)-D#GrLq4GMJG?I}L_BFk)7JD6xOn5eQEPTdv^=CKO#*?)*x3gNoXtGOlr
zB>@7Rty9J`7{xqp`ia4lB^USLhkxK^%}RS#aA7nCqeE%W+`2gL9?FlQ#|xh|yJ8}+
z^I#eXOMczy==oY&<HQ6CRP@hx47PZGq@-XJGZ@J?-poYf^sd6oJ?#%BCVG?W#Doh2
z&D5O1m16XK=HWG*&W;NI{GP>VOGycq_bm2rA*Qumgtk6Z8P=(^)q-guVGV1^Ia{l9
z&AkO{ZoQk^Qu@$Xo>NRrXikFH#gqh!2GCixNAOF6gfPA$Q-G<+1pGh}Ty5b0q(%^u
zK*&?tAkYm5@A#2hRDfs!LYKh)W`NWVKmaiQ-NgVYfPzqjJS7E$D%K@Fkx&#VqPO)j
z+=UAA%)KqH6c5U_ls-TmGxE$yj68GFV8W+4smMse>{*&T(Yy%4SX4K=X1~$#DRKLa
zeEQxCXt~-uz%)zg!zLFzBQ$-E9+hC=P@<ed2iP$a`5R!D(`8hTr%}j2ouZoa7rl(H
zrs)dJ#;4@h-2e&EjTD~7Q2NCDI$AB@^zEM+$=Br9jV3b$3$@Eeqjpa#iEAA_!vD?_
zM_Zt79A05LQ0ra{ne<Q+qCDHb3xv+aU%26yQ7Wdt{#Y5?b3?fA<w&HyNAqC-;F+cv
z@?kx_<}GkTb6~8%Gkjm%>}>w7D;!ZGCw3TV2O;b1Ix1!lE+%bMAzp%~76aCpI;sHX
zc5d`B*%AMS+yM7T>K}%{Eq;0zs}mTX$POKjUyHAw1PD_z|K2h$Y0q0o#mN5UKll`S
z57jmaY0|80C;$9ln3YiTr~tz$L0-XAc+JujXZffh%stlsUFtc`x;?Bq{f+=$=Hy26
z#K(2*9W=uyhrq1B{r$+O)a`V}1-l5uhdg^H=P|55;sj}H;~~g2kbsA*lLL%LST^{?
z6HY2XFaG-6q;L6kJ?P7NW-V_4^r%~S5c3SIN?#}W4~vn7_zrd-o&xL{j0{KrL+moG
z#2lk;627=45<&z4I_;<w`yy0Tq2y=(dU7d(bH71djZ8_Z6}-XE3=ff4!~KE<^1<T0
zjhKW{p$ruv*^D?2lOH)olxgUf)nSx^w^jNV2y1<V%NT1LasvE7fE7`Hv@V!X8bJ^?
z`oZ6U6{@L{eagTJ0TCS;M;W;!&(uE-ppU4T{!-0Be$onIHi(LP=y|E4AXkTB4=Z@9
zYgNlYdeB+FRE(^badQ>bR?!o92fW%OQhuj+sC!>SX{?xAYm?@eSbv8dU{tbp)%?j8
zQAxc^@V1!ZqinUKX<Y+ibu=$<aOc~3@{T1`8;%lE;<{vSwepD9D7sdOU$bedF&@8$
zb!Uz<YbD1+tG@wuN-L}cO#Q}GwL+V~u0eC+7EmGjDaNep<I!eDC>b}&@T0x@&c%nk
zh|?UD_>dX=niL=M8zh?>HLnlq@nhNI+s;o$G5440!Jz>}7p&toLc5?zBPv11rePm)
zK76LImJV@4Uu3R|X{AgwjMpDSb^g(o%;AwrJPTOp9h!2Ps#CthG|bE|?LnK^Mm2!P
zovdl&VKW9m2ES75LOT3`p5e~X^Alh~q2~kqnncf!2wx^9N=;9j=uQ2fWNq!xBL_R%
zUyI7`>En}znfdS2)crj*3;$hy1zQ*+Xpz=i0-asvw0j4w9Zo!i`CpCgn`eRB#__c1
z3Pz!LIaZR^Yi8(vN}V7KpHv91U@H?yym&DR1$r;W#7w3?PU((d?$f14($6S~LI48&
z3XrH&+9`ao{D9vMmwcSs=f6`v(((J@#>XBo!he&#@V5+w-t&BhkxZM&>g)c)Zl=MF
zf(e9ph1>;vl%4noKemyA#L&|g=u1v#(ro5{rX|i+9w&uZh5`s7?SSw8Oh6u-K*3sw
z1tMpEjNC_@XywGd2#wew{OAlt{k&xwUd{S1eSD*<ATS9&0_gO@zyv)aumF)xEDwm_
z)*=QcS%ZCp6Q-cuc03@)WhkZ-G@8@;2xN>uRM@o#&hdn_`#3@jnGmcI3*?eRK7Y}#
zNxZqF{~U|=L=QPrNUu(E1p8KsoS*83QJ(1cF$5N05HAW0AP4&4-!P?83}y2gmCA2o
zIa{vq0n0qWdpUM3oa-wK_NHhu>@D||5}*k1gaSZpRh!fjbM_FmS`mN+7+NdDAEm7=
zehF0(Eus>+G%%d2)o;AtL7j{b6v_I7keU=vni=01KUQ>Z{CKjrY5cf^Uz5g<N0FRu
z{HSKC6Mn@c8LrGDX)-*(tYSCG?`)dES;Urp$Vrj?`^78Ns(Ccl_^ATx3s{z+u*qRw
z#AUV*_aaoM{TgpB)(Y#R_BCWqMDsYTF`)+8p0?Nq<BQ`ZrQ4^>WuJ30ENxFWhye34
zmNV_{3bEL&F%pNrTchtOyB4z4HxTtz!zTtBYL%5GRJKj241*Ha2ZH<OVQ8Z>Kwo1X
zxBKt3=HA`|K0^Op)^2yuhvoFaX$LC<Ya}rO`!-3IWQ-66-_OUy?G@dB;8{fOsMYwP
z?1)bzuU_9uEK1RwXAx%2JY(ziXR4$SC4Xx!x%3p2M3D+Btq6ga5yeVtZbiUWr6||S
zzyBvLzgi0<O@ikI10E~G_e*+LJ0z~ew1B~=$E26QxEr0>WOT-RD!^EQpXwaX^uhRp
zyUejPMct?n>uFCVO+3qGH&C+CTyiFgnA+oD+&n7o7We4I^UP4_)<O#UP-G*}LiF(s
zFjXv;LJ1py43(L>C1!d{%|vv43kX5CcN*O;9|C}H#g7^L;~4u3k-JiCqOIcuwrht@
zy^qc1%?NYaG=M|cY{~@-jDmkL7i4^;CA&*6zvGW4vKt6f=%33QLM8yV&y6M~od($E
z;l~V{x|;hXw!d>1Z%fq#*Y9t+KJI)XZRy<H=v*<i1a)i6&@}JNd4iXr8=cFs)CSM*
zM*QMWJ^hIe!r5W7g1NX{@y(!Xv%euX;M$A@%{ME>5-4!;1~}{eHT5~(dH$M>*4v3t
zzauwEO+C&S2|8Cmnl@L6J~vWdp_*RBq`qo%rRe=7J7|y)biNvJuAc3}I(XIQz|`Jb
zXFF+0e05+-UeoL<JUZ(G<^6Ub1>ebw;oKZ_ZR92Cjgf1}EU(%as9G0vuH&Pd*ZFJK
zb<4kR82S)&t;5mHj;AMD-Xw!}_6AF6O5RphrQ${Iye-ll`PT5)&6W@vhX_OHACzBN
zVR&!k(hZ;Cx`=*T0S+*Bz8suoT;Mn^-w;-6|Cj!qB(-QQ)sLXHc>NtZZ_{~0uvS(<
zRyh2675-wI+N#J;k&@i&J=k=w3yvJ+lk0w3?fZFL$M(<SU7xCV4aXJvW^mWHhvRtp
ziQY5n`T5DU_tT40&j%;feu`e44nqQ9&*^|YCjomd@(Vm9Bm4v%Fsjy*jPMWi?^N%k
zq+T!3VMedLL%7$ow|9#J{h;1!ty|CN-FilL>zOEyw}HU~UrYI|(%16Iiiwu*@$cc4
z6D>FW4}$GGs)8+;pKBvzbuLBLdaMph5p%>aM89hB5MG3CW20dAH5|%>brIfl$mLD`
zfmHU(rg3)Cac&5rbSlmySrzypZH^EX43ZWa)+C>Pp=+62{=iyBw#C~v)b{dUpJcDw
z;-iS8D~y^Q!%*{M_>o2%7#o%+Ja%m1Vcg)BM4jG(U28$NJB<2K=}e>2&BIY?>FKCc
z3xh#@fOCQ^kE(Nvv-IlLe;_-onKo!#(0K@C0omgFfe2ryf0j}I%u>`J!;fCSsq^9^
z+Iddueuh@PvmF?vDZ5syp?>4`JC;63<Zrr8_nt{VQXD?{eM*+^L(_dHd_rXmxS186
zVRaex(|0T)WZN&)ep469(|)0elN0v09oT-M9Z{@ZcXhvz&hG?&SNgA%Z^sdw8Ri42
z@kjd`4if%RUmYU&yV8FZ{_3v5zvdv}Z$p^MA)$X)`me%&W7pu{d64i=MUdFR!7nu?
z%RBfncA)+F9ZVc;(19%|b|5Gzxjzpepsy4A_gK^A!pMXqDZV+<irhc`{#!(ErT_l)
zGuRD>vU>ifpHtqkzYSZE(c$xNr}Z+L!eFU*<cE8FjxkO<r`<<d-f3$HBkql&1@m8a
z!3WZYRo)Vc7;T$No0)zBUq&}vL*Q)n9FL*eb1Qc6;UodtYKr|2S5g1u#;;TGmG(6J
z6Mv;OhK*k>G^kVRV5DL-A$l~ul;K6&ljY!a^PVh*M_fK%-?PW>3Xb@F<r)dBj<1#L
z%<pSfC%nIEe%D7WF&tO>!H`R=Kil_;{I_YWa=^j{g<$Kz#FB9uNk<%Tf0Z-)_+6K$
z|0{pvsR&c~Z}K<7A2d$&&reHQk0MVxFI(ddKTK+DxnA1sl|zVcCN`rzlg(f!@L4l<
z%=l||(r&Nkz^{5#(qw$~Oge`cSag4pl$dcd3i6H=M>Q(Dy^PGBH7LRLh{_NZDp*51
zD<e7R1|r&UyD!bXFju3XGHtFFs@hoT*$IvdIqTixuP~YriN^cW5eQSefxcj(6mqV^
zc?kT`ikc|g4mDxB5#8$I?XTy@cBA~a?GBjZaIE6EhaCjz4yuDML}@Z2k;3Q}q%F*Q
z$>jd^CbxK!8z>-=4Z~h-sT6-@8{G~MR;&0a8l}Hy!=oYhYYr5>HpO>tv4Kw+W+7wH
zxhB#RP}2J;D1h5o=&?U7lDb+#1&ae!uZEmqRNR7=UWH{$v$UoPajfhE(aSfM77@S9
z3G`b<_(5@sh{U`T7?{A50|a8O4#2wS85m`VA~}ee*n<GC8byS-s5^B+h#VVCS-P%8
zoGRxPn3DQyHq#v}xI@PI9OW6yd0WM^T+4IODM-W;-EvWk!okgA8@@j+`yxasUINZ%
z(3jU4N$`t36L4Urj;6WAe?e}jPgihlD^j@}S-!!~Gk-{aKKp-@`FY~TEc|@$l4O2<
zfaiCq_&I!w#?QTgB;scX00nl{ZlEtZKlkB}#Lw5un&SMd<tKiABZ;4>j!yCOHc$XU
zNO4jcKlkEb2+7Y+p;4mG4IrP+&t=%8sc&yI`1u#esPgmWD4_B4#dyrj&lkx)q~_=8
zs9Ey!y)sH8k)Qi>(<(nd-a~R%1!i87pXYK>xM`C3ImCHe#h;KP=v4UGi^AaN<MGGf
z=Y_~D`T1KJ(vZl{=WDgy$F-&BXBw}x`PtT~L;#9zQ08X{SHj#%n-0?~>y&3`WTbPD
zSRP<#Q0h1=K_pr<{N3L&01GpXBxaVNtDrH5H90~Us<5*Gp;~=0AY<B1JHzc1eO_hf
zyTY8Y{I_lX?*{tL$$!171AY{Y2B{XDu(GtI@8YU`ux2QR#Ti@T+PB!XKeCXTt185%
z<$CDH!T_#;LPXe62#i6_CAP&lipzl`3Ih5&X6EP+CB$%q5w04;3fBG#5s_fY+mTKO
zAaoWjLO2TpJ+%sf9_|9_b#M>pon2>uplUySDFfxLTKRRS!fMNZ+qK{SU6Hppef00`
zkzd!BQ|ZteUoR>ep>qhLy}A1C=;fvf9rF4#MhONBY=}YC2=*%SQi1%p5j@ocWpxZh
z|0Yv`w7kd`pgRqou|ZOUrXYZGRVa)O!yIqvM_r8m>AnI3Em&P*_}Zeo^i~J@u1D&~
z4_RUC`8OJzBB|v)k=H*O!XP<nD#-Eg9jNy3WG$jpE)x=MTc~v!|JbrzQq@8yzB${r
z3wfd^ZbZY{BaJTjr9rfq@skgvZ?a4W|1iekx>YD1ZIp<D4R?ap5Y8$}fx6u20*Y$&
z&dx;A{MWI%^cRl1waR05aOZ-t5ld-St3+okmC+RLF{l-}mzEreIr9Mq255ybmHd%?
zWJHj_90`HZ#mUamJMiijXpCN<9=r5kVUO;?R0mj38!w~V%gM`aasQF@xykdQ{4I9O
zWwcmra0milUWEi<8I3mlAfy@LOmSI8Ns7bCjbh)ue(Z?hpz0KU67^q4zcu=iP^$iO
z^VT=>j8D^l#cA{(Za~bS|623kVEuPqT>r6zl8gw*3S8KN4$5=2&I<O$Ua)Tww?#pQ
zPQ1Imodq2dS&UpJiC{MC$2t(XupLb@XD(|&nSvYY5VDR4&MLe++ps2qlhr8XJfD}s
z!TRLi9g(aFu@C{xheGI#)P?8^rSN(Nps9+fy0AZKJya}pAwIG$%;QvNOzOf`e*{Y*
ztx-$|ARawv3!P(Dz`dUb2p6ivhCXORr$iNL!zw&NF_Jda8-_OIR8*N4`6#XpX<LCK
zK%);IuZ}UOfR^R4#ifAk!m!katc_3?N2roE)R7D`f>llnw4v52Yr~e*+K?<H)`qCb
z(1selqR@t6e8=pXf+k2C?$)*8Zc1NLwVSnJ3u(g^v>b3XYqmBl?wV$ccL-ysV9j*o
zh8E#n1{mHXVHGVB-5{}rQ3NWH$5j~ADe#vU@uMnSU1Rb7RO1>Kv@6JqWhxA)(6=BB
zr2ye>@ilMr19Q;Y!U&{F4(dFY6l%CHq#F}8mWj|wUfg(Jjr90tG^}Xc$iL#cvC6J#
znv`@kT*IsbIwk+CpWxd#T=7zG5Xt^OtREHo@&3sv>__GMO{u<Py$52AW9#=ohl9ZO
zL0E&?6>e{B&tDW`9z-xgUp|dzK3kqJ6cPU_&r~uyW}yC|_9#5ZH^{S_CimKzN~d{>
z%Gf#Z<#N+x3K@rqZ(om3rmAI5&q8G98pP<D_)IE#I_3oy?=k4F8y&3>(WlwP#2t!~
z(v!(MWU_g)sqW7Lyi|*i_pLg~ddA9xqpZT_C9m8lOs_s)Kx@TT?X=E4zyZ1OC}WJQ
zWDY{2Bi`^F!x3-sX0-9f5yHZdJcX@Q#GrXFHj0I-XpE$IS4`fq8;I7Eq^)m+W6JRs
z<EuQ-txe3wWQfX^Yh`hm4VtVJuks{GkAgOaQ)52hmWS!#M0~)ZIN<d0(k;)_bEW*w
z@}~H6nSU%|q4cPl1XzQ23W!dlJD&&08>PR6`b1AD>WN~4ih%>^f8lHt1%?xna1@A4
zg+`50Kp2Il3ECUZdBf1KWmVz)x-+RVXSl?<yCH@lP1M3vMA18-rgzdq^oStc*t?TX
zaG~P>MK`+5w#|oex~&Mr({_--p-|=$x1Upet7kbgBZcO)ff&2p;xZPDLJ)1M_zjxF
zF)#402y%L1Jg3xGs9QCy7T-iP#x_n{_1xr&dKwjN6f?Lq7V<ZXhxLj!3Xfh9BWfG^
z2Yt)dwZK3SvM;6Ra2&p?J%_=MRW&L<%Kp^@JAtZZ3Sw&J@v|9+DVDjyURV^(6i$#E
z{hZKRVWr?8Y9C0YkqdJtiZsW5IEMUr`6b|7rxU@oj+h+ItOxW@YjmnP*93^~!xe(g
zr(i0*s*}0uRg);B(eK83FfSM<E?6=@N%y3FKBsy<;@J6wheUp6e&zK=^jlV&^1Ri<
zHGVt_!2l96+SefB(sc4;hIb8dtbQKpl)D*V^LeBh@()OrAO5n1s=q9Ke0B}GsKk>G
z=T||zAbs}a-1|n%C3rK$lcT+DYI~(g{$}EK=Waz^+zD=i16EfT+WD^#b<U=#i@%YL
zK~7v)T$n2&06}!H*P0eRw8bOfdGKADuzW+Ey^DRR2&{pEAcX>v!D5MDP&JSSQV1|Z
zTY|Y|&K=n6@pqXvM_OO}!7Yx~d3__k2CH_E&AL%)2>tX@Xp7yf!Jxp-*890t2MIxQ
z;v_wFGhDZ2&ae-o$>uUwvllbst$gxTnBaA7X4A46;u*ON>KSn17k;;Yi)-N9BAC5>
z$Xg`b;#U($261?^7<H!x^VcEQ*Wv>9lI_&H<l0H{ERhQh357toM{jWi>jWCSQqz(I
znB_5>e3|)CmDkX`RPqY`SfTPqdVa(aaVkH)#IH&GxChB;U@-cx$3Ki`jG6sw=Kh=H
zZ|mF?@~7hiq#injY?HL{yQ$afmGbtkl*jsNQ+Z;%Lu;Dz48ir7%s{08MK*D+<S6-S
z7h~bLgbz7+rFAOuy-RG8c<L=j-6Yr>3OoZYJ~(`|V`=Ds@d<pi9wL0OqxxX+A-;u8
zA{RZG|HMC_FxB_h;m23s|7?C=YrSo<MO1*RWu`c~r97^+(f5baeiwJZIyBX9e)r7W
zHqjy*nGYM(<M;rtT<7ud6s>ficDMMsTpthiw&NA??D93SLku6y3~*v6Ox|i@vI=oQ
zIT_`J$Q=KknCI&il&2`6LMgB00HE=lj9o{isp{xNu39%j)%?6Fm#WNtvMDMf^TRzQ
zDq&Kgh4lLcVe*hi3mf!Qj}|uQwZp>Ftc~brh9;3jir4=&OqIh_za-rVh-d=#G<_{;
zd0X1=Yly<KDED^_kyw2v{!`zHH<WjA^z@AJ1OApG3`rGeAEHdYKZ=t0D|8N0-;$}~
zDDV@E?U;DN(~iL{CeFA~zn1P8SnbHgsmt*dKCsA>C{4MBA{WME$&4u9E}r<3a<+>N
z;BguHJ^<#vEZ;7c^VgV|%JsBHr%~4K2=>D0kKTMm?hUAKm<0~J?w7C7h?H$1%CZF_
zFsIxtc47S1yhQYMf>!h18>ok2jUgGI68_s{WeM=VFH^-xbeG{j2M+{UE_8rgR8!$U
z7hhHQ+o_m18hO!ehW|}O$}s#`aZQGQ9e<69Hed`B3JL$IIJZf{&mQeK{C!ODuRvJ^
z{_$q`uhVLNf@?Ox4@^EHjUAdH_bqe4uHvIwpc=?jL)RrYY5WR%p!7Orzije-51IGN
z!vBcHJQ}N@FR+LYBPxDp0~(9IZ?+DUEwoH8^tTO07BNCne~E2V^w<4=+20EGUgSo{
zFx+Mp)lOTXjwEY`<1y!tW_u_42~uby<W2HjSD%`F*ZKN}Ce$||RekWU0HqZeO9`bg
z;Ap1~ZaP7qqGkAUh4zJZ^|Gso+%5w}J(96d)LR?_CdUJ%+L7I+S7h`$J|JrHM(yS3
z*^=68B)b_sNodavnsa;IAx=trYqabsmP0grp|#)1Of*dK`i8Hkprgj2@o9cdyS><f
z!u`WR*5cvh{NvK)7Z?08SJk(`CoQNDMaj?7iT%=p!5MDxvQ!h0;p#b_Cf(yf&WoH1
zv0)T(hKw(}{Bx;8?tyU1_%i4qwi!vYOv6{0f{}sv${ZJCeS=im@W!j3bsy$0`ifLE
z`L!OC&GJemId*t;bZq{jw~@h9OFvp);OK9``E*7{+C=C&8VuUR$v>vS0G@1LDYf<O
zZaR;H4$1-<4ISJj?&0k1;&pt74(1hSDt-it<8leaRMYy4r|?|35}%=;Cj5lpKMSE@
z+`>^I?A%uz4tdl{s=Sa&FNPL`{~R0qX{7=4#8yf@5^VvPZshupMe=xjY8TVdG9Mv~
z^VPW%JIze0^QZKW9isi{;ulYt_(Qk9|IgyxXb8yQ|6u<80r%tkTO|L}QHfxfH2gmz
z&i{9Ok%|B3;Vbd~$tM2)45=Fb(;`^@B0Aig`G1mZHqQTav`Q-e2ZIs+8y#sA!@zpP
zZ2!Suh5wI6TW;Z&Dn#M`6F7Uj`13y`|NE&6DE?=pcaHzpu@9Q~|5pb83&>eA|NoX!
z$@>xG-AS=Xt|kI^qH#?GF5!NtB5+vvANE44>OUBo<X?iq{Teo;HvDkRpO3w*-vdK1
z=3r02u#dYzTOgVFizw8QK*atK#LMwwE9?qE&L&xUJu-MKU;{;i!3{GP7dc5)+A7|^
znlxCe`0)%~gCSHm3{-LIHhhJmiq54hGm(X^z#-=o5D23M=1Vg?Z9Cm)e;~JyW6gH>
zYj#-ZriUiImixGtrs#-9=T`KHW9I&d7$XEU!BLF}#m$xCC`>uw8lrZlA$uerg)@43
zl=%zr>rm~Rl=!_}E=JSv-X;8Q_&3of3x1`W>lmEupyRg}MtK72kN7JkM8$7!q#F2b
z!b^Jm{+!!SiC?l8g3bi|B2C5bAHfA0ejmf91Hv!qYt0|k%%CO2dttx45nKTT(L@+y
zC>Gk!h7G_$L1Vq(UM*INc4&!WumQN8bq>a4EW#m(psgE5v8wjyJLJ7r)^jk3Q@ohv
zGA^T=;>-XnuUJKs@n%>!V2ij?JaZ}KRd3!?_$5_;IWS-}^_OBO()AaIqEdJPOd13g
zVV={?*$Q~0ZyO!f`osOLU(LRuPW9J2klX}m`U_75!^gL5yvJ7x=t~M(dzrsuJWFMH
zmsQ!lMVd9pYcJSohFCTj4Z4#!7X5?SJdpMz*89@cH#~EF+M$PJTDL{5(T4a!q-G*B
zJlcI}Y*1r~)J{aL5IB2<IM{?vy+5PGoH2aihTP+a={tpOpf3_{m4dGCVd;$@y7(IB
zXrseu5k5c*Wi;)_wKlYBmPb)+ZH*H!NyWxUq*)?$@=K0Xt#i3Fow^Wk!EFv}R~~xM
zhMm>6{5sm7&1SW~zL@5uWW?UYj&cD<Ijw=U`0KIpSGx3@aWZ99i`E)k`sg?HY6q>V
zLDj};YhthFTI%Nx(H`;_-G?55P_+$nu&YB(OOBYk05XP4hzdWMXhFu;P{Mn8v>LTF
zj<eBF8>J&H8^_yf>6z|EM2m~)`2v}zj-JnvdG4j>;WE$9=y{;bvxJ_HmU(EcJ&M&k
zs^<Yb!~W!PfsVbXtOn2F#x%@wckAr58x%lET9Bx)MTde1&@q$)Bv?;uB4~M^e-nJb
zShLfMg=ttM3~vogpi69sCFe9xv`oam1^9O<{#}KCLHxS`|1?&L>j&mnAe&gbwqYq6
zWOWlGT_cZFz(>+rWv(^^m(pyg%xUxS{LdQwRAo};&y@vc{}P1ZX)TGrOZmY42*fcP
zwGfxQ2zC@$1l^Y>1ER2;VRMTzydzHpA=~=tfXCKuC`1G39Z)`u9=FHV7GQiV+06Zh
z?ulWlKq2uSF&49go6f_}bM!O)eEd*W4;2$9oWNSeEk1vQttCEa;>OLiIf24s+Ghm{
zY#w?8?3nb)I5k8)A*8_bin;owRI_~??MtN<XsGap<F(2c%gTXVoQL@W>pbXnf9%{l
zE(b0v#TuE0@1d#Vm&neqG1op06<2rjtfBgyu@YzdcF?M=WHSs51P?rVGPQ*LqbJCg
z(7U(H<?B(<GikgD`0a&S|HQ)#JW8!ImvW;35kbM&a=p;+WFe0OlI+<@H8VzUdX_6S
zv?9~Hf-BJiN62rSBVN6W@K6Z0Vpjq}bK7$eQrKhb>YV5i_(vO?X@ryItGkJj9H;`@
zp9<jOO62Ls%B;74Eb*31(u)}^&gE-c27rq+qY^b#w{`T}frvwSXMlfw45l!G;p9UH
zV%k0h9^`!~q!&Yc`AC2-MhJ%5k-4^k(gPtnP&v4aQgAjjY;?dG;M*Q>@-w|Iv*340
z?&2KzPSI`J2l`ybM?QN`l@~-{Tn&U;xk4(%CqDASdP=nTRt4**xlQ9bEV8x|?h3^=
z^Ia2-buE++|6$w5GJ3`dlw|t5LwrpNu0A0+D?9ovqFXt6*La^ZV7^L2LLFbQ{<6Y3
zIbr{8bDH(2T0~rq!>ysi=wTrqis=DHwYNV%SmD0nhg?44XgBqc0xmfo57V%KGfXjY
z2rn8u0bHbU$#I@mykYNAa2_*?eq|dn4i}I9TnR6dIXzP+qA=AUKAuJ;=*qST4#LG?
zW!vvNO8l71Ab_8?_C*k%L?0~kF^bvB`pv@uf^!gjLeU{|Zxr=X*&8*;<DvSs&K<9J
z?w=Utz{Ps!urX@5*o$?XMhi6rMwdBd=cop8ZoG46pfR-Gu=fbCjX!+;?9HQt1<U5$
zg#)Bt$5FHXFmKn|p?7HqcL`S)xtjbnO@yz_N|#R1yL6SgOUO7}+@N+z=9FEc8pQKg
z82EaMp@!By`DGGgxMsG}97S7-hn3Or-4W=r|FiRFZx|i4hh%5zWZlnle4|9iQXO<U
zoEUpX<0v~-@84T@C@8~`vHF<+GM)w2@mAB~Wp6fZHoe5%!2;&iqy@})tQE1aHon*{
zhmFK+2`02LTY?EOmVzxo=XSy+F=0Dl7up(QpBCe`v^?JFpXi-FLhUqX943xrV6}S#
zWloRPiNaKan0h%Qm3O~I`v!fswas)$<u>S{`$|XF&(Nh#?=LZ9^0r7*&jwKC8VBC4
z_v|L0f=;bx^Bz>hL+131qry~!c(Y3B*>SR4XQ5m0N8p!D362GnJ=FR~_H088QCT+s
zuJdPaA04#TN!sH`>e^ikfkYm8Q!(?B@}5IDsM-!Q3}zS6U;%UlKjbeu6%?SCanKw$
z(E}>;7Dr}j$%qEaUqlBuaRDn{euc&&7a}Et?3}y+Tx(+24|R53T;6wZ#Fn{uZ}b5g
zQsH(}@zf1(0-Tn}OH?uguC{R1s?^u(QondgF1fi<pm|fdV@M7zCQy51mcQEfxL&pN
z7M)0or`iUmF1o2aX9$j7!|i?D*AU*LCoQbONYi5tQ6pLq?TyzQ`ew1x@moYWop1F4
zmidF`zv9Dd$e)^W{S{DQ{rMt}XfaPuq`a;jHy5%&29;Y}h2=Lep`J~bkIPv=j7_W=
z1bCVvCP#Y~;|-&T6VYvoqDGKviKw_=5fhoy(?W%*2JvtuiwOn`DZbprKIr0orNK>x
z_-ghE!w>II8u&4u*3)>p;*ksD_cf=D@4$V>KPv&I$HC~9yIapN6fhiJCd*&bl~D&z
z!RW4JEk!(xuBOnHIzGi9G(ko^S*m9vFL2Hi0L(sY0i4*Uc^Ejq`1Z6MkcQ5SS4hJw
zAn6YR(?yoFcM6B-*=gQD%5`-_-u9|k7&8CLt+;%G2DsiH+XX=OKcw$T^x@-Zq)FJb
z`e^Y1)}=`!_2&G$a=pdX$8_{7g#Ci$o$hPl>$hwhf^)<ASuEpVBQ9W?+41xm6acfT
z(jGzUvhUeGh-O%}K~?r%?*+JG;J{$(;M8Jka7wXl&jw5qEWUBUTwGXv#-e)fDd$|9
z;~TPQxA*u4;W%e}uJ3px_C4p?ZoUG<jw1YW(Qe;|LAd1JjdlZO`q%q6=O8*^&jzR(
zi??t|F7`p7sxM#zqTtRw8=!10-W3S`hoy%PA0TxDwefqju@+kaqKgQ@IK9WS;;V@k
zan%3v5cqTxVQwt_cJN_pCwj_Bc&z9yFeMk9dk7%JB5!Ng1&OJ}^=YNOg)6BR+|TvA
z9P9JAQYcRStT(Ow3ULf-lZH29ti>3zY;~0J=|aVNhsZ%N769}5KLFHP_(--Oof{oK
ztVNM;opTLEE=-Ff-BF4U!Nk<L4c=U;!NK2JB2nZ;%t$}#U!{1DE3;u1hI)iv4_T84
zp^LnO1kXbH84bq5;R}N?+4v3aa@3c`XnsjcP=CZ<iLGG>a_LQVSBP6=-O5@S83@#u
zMO^>x=yg=~4U~0rybhxryLWs;t94*c)9VPM7u*!dCe<;H>j+0rpgOS47C3FD$H%nq
zMf|<l;6)Apm@Vu0r4`h3JNm7rxr?(+!|t7Yhat_3fVzr~e$yZxm>G4@rWXvd(B!b$
zXilulw8jejN1hI)*Pk0bkMykXD6Q%fjH)Rj8y*)(j+|X<8OCx3I4v->CI6GD?|T2)
zw1M?Sj7pIMnyd5`rixA57^`&({h`rB!U%PW#aErx^#1CrV>S&|Q=2GHqm53`Cx1h{
zP0T_E59X?zEgRI@qefD!wz0f$dmz*Jbntb4HCM_XpI%PHu<_~FcT&BnSKG|_v8Iu1
zB4TH)iU1uR^tXX*AVu{i;*W`?<=04ZLLmuC+<P5|A3ie6Vn|eCg-UzdsXdy><RG5a
z4%$JUSZTr0MSbKb4c5nNc0$^uVv_I8=J%D48HX@y`kNA%!EJ%w^lUH%e_y#6oTb!P
z!3lbP`e@FN@i?3`zYV9E->#(20w`Zk9%CaI3bA+ii=1kU=s1aoCw+A8eG^*30PP=3
z53r+XHv|5Q_6qi+6m3;#C)}L83+#^k*RTE}SQW;3kG$YS+I!H>#Yl675l8GhnZ9`*
ztArlY{ujgeI3aDqiC$QuBaoTg(qZ1ThRB&_un9HI^F??cv9ApqF|h1J*WS9Cql-AK
zuAdk4O!xvUJeK;3Jz+HCS#_b(Rs;4m7&a5NrJEMeet-$^pD5vf7n|(9z$P^`+63hA
z#Hxt^$C^tD6GW4A`G@HTdRQ(<^f&BILl1qX6xN#x%cjE6ri25WWAe;p#!SiM!s4w*
z@K_+uS0UoO!^Oq-#;w43X3titg6a`VCb1zHd58e&$IO7qZeFAo@4&(LC#pQKl3BpH
zI|`ME@bN&EG~mvMpCdR4d$7ns<Nwa;8%kCd?Q9|6Jua@!>raA*GhE^Nt-{LTPTjY=
z6XF>CT@vP>m8~Y9on)R38}s4Oapzaaxf%EIf`({strb8t?8^1e@4eN6tKj(cGmC$I
zKfD%dobT|S&-u3R;%wd#p6Qn-^2##I*9=|(R_YM(gZf!wqS#mlZGb}xpE@zo-6ZX2
z(7z~&{^{&vxp5UsT8%_^jC2LiihK%!d@ZEcszSMWgGV#6O5VfAMrW9^pnDgbpc0Lz
zClB*zgi(|n@;JM?QamJ6q>+#t{V5#^BTqCIe?~P}jl!^!8@+;QTY%Gs;lG?rVfhmZ
z%kp+WY21?=J%@V>vl!bt=>wgafc_!@jwdA8C;>f20(K1`!5+v#H;J{AX#NV$lmbrS
z1i=)b^?L0FiECzDrRrpsC#+{N;AAe)l+rC;W5v!kLT{3M3SWWixf&uGb4x8CYmxd^
zmoavauqjW7GnA+z!Mgm8OQN61BEQYL{L(5t>Q>GnvP_N3?`}nY7hJD!8J}4+Tm%v0
z)M$}z7>|+JQ%qG*J>tD`DpU}`L54*7iwBrUUuBabo2xMgg$IXu7cvxTIB(7g(80i9
zWBF2&4a}&*kle=dCBP>X-5*oSd;TI)f2z#SpT*RrJ(=K~SY8b#^TcJip$`dYAUI{I
z70oKSNJC7ym$!E4ngdBeG>xL&#xws+)>I1R#Ruj^K4}`~D4=>eZWDUPMp2ZNo=L!l
zF_7%Oj?hpfJ(tlFk-fsRSk3S*XV6BP$O&?65B8o<L);`%Un{-zIH5F&PkZ!d45!vj
z8h;kc`8-Apa-{Q!(MA}>k{4odc(L&mCZFc;@*D?+qO0+FYS%b#saP~$VFM$xXO+PQ
z?@nMgfGXfsCpsnot+(i{w{YvUn@EO-oZ@MsqSD>w>94fD_gbpR@cAN?q*NTCwr*sW
zty4Y1X|#^g&{?$iUUPx7FPvMaFc#uE8p7I@)(0r9&o{S@yrp9C-3shRX4yK`BO1r+
zu>Tzm(N=$bW`NZ_?Ti=r4)bajz>w#o3}STe#*`(6B~yL|y@Z(qcyTEh&-B%buUL50
zz9QBZUvX_6WW$F;M6f`Gms%^C{ExF|GB^4V{^t4|`Y`IiFnTvQ3q8t-+|DfKfQ}8i
zhn7@e_0tw`4`t114~{P_nNUg=`uI|`A$7Yv0*3IIq)HO}GZ<fHChDgaTN?cY9dT+Q
zb1*oY=|T$BT0$Bh4)J!(emjI=0u7K^-}RIyjfu6_D2$R$V{7t&<L;&ZH>NXWOg4=z
z3vxx?EDoC#mbg)EhrM~jg%A7h46SHn_IRn2tQB89pIL(A@HIFofU2F3>mdhB-kkAt
zOBF14d)@sopP)nFEMh$se=Mx<tU#59R(Sv$WaC<8HRYc)w8B%b=Beg9n*4B%(hARR
zHOC}V4)Y9#@r6=uaU>u5gwq7&wr`yDf*6Qxn1q5%!Ep}F@4@*iR?-ARpAXQpF_iIl
z@W;YL{@9q#{)A;s{xbAID)aDW-w`w)h+4@;UgG*<vFjh8W{0;gPJ{S|JY^|N#3VuI
zksSkg+*Y+Hw(1aNtb6!sg?rdmEfr5;ZO5Rhk=e6|s-Swrr*OVttYgD1dXF~!07GBi
zkJ5>IsUuSSU}sV{A)OR<?hjkN_Qt%0(CN&9bhTH*ciQk0=uPR3d5iGN6=1kwOE^g!
zddr4jqriwwWur)X5Vu42e?gt0w%h%J;-adpo_&-A#Sy{X$}{0`gq0<u0Wh<{LiEyU
z2DjyiqUj2XqEk?sLYA3{u|0F3Ub-GEf&tD};c2}>DgD`1N@===SDtr_g*!O|mX@@}
zZv`;Z9f$xhmaAY?5T+BnYlgjDtSMN{s?Z!t+Tn|u+e#Pt3?tyQi{oQZ4ZNND2zZCu
zcOC(Ui+iyWWH5)3*>gQG=An8-Lm4v%d9?4;If2&l+WlW*F4AtGAcAEwpnxo47Wop2
zuo=0f1m}e8>J~ttPL17q2lk)B&D%me-9nZT#p?*16^3~~LUlx_yr->%_FKVJ-Cg2}
zmAJwb+=JjqvpDPPbwl~wo&wB=P|F~voqbnkRfv-saNa5{R-EFof{^;yyiZYuGvGf~
z#%AO#71dq^FGglhDOExBi098?yudQRAT7scgq}DM;c`31mR11AqT5Q{0aL>{>91*_
zUU-yV>{oiR^GZ`MkhfIqo}=`_$Siw7^@u@6FV>+Q4aao#fgl_U#xZbDCz;tteprH&
z);{aTTc3gP=Frp}kT47p=|;K*Qy5#BYxf=b;%06Z%kj8#I0_rI5Efy9n`SbYbcWGq
zgpEM(IFN#73ll-|ZdKuKbkdf6Pt%|#G(_`M*Nzf6Eh6v$?li<~C!F4u;_lJ3UW4@l
z2z)!XCBx64l9=Vk-!hsd9x^-tf>ekBqyQb!j`sKtQ3+(A@1Qv;>@r+GPCHvZM6@S#
z7Rd4zK4ef6V*s9^CPuKDcn%oV2BjSF9j|X|1CF=~D?w6BP&2Lvu^8}R>;pW}URrHw
z)W!>HZEVPaYaPtB4&qv76CxQij)`AXuB}w0`8jiy%rCFrrgyX2;xRINhLSWh*M4)h
z&b7;#YcZ<?*B0RBG~!zJi!<X$t`*pzPiMR(aP4JEF9w=>fxM++xY`RNv+M<P?af9n
zjz&X<3i&nIm9!}Ihs##dv!nsb`oI;d4e(Q#dKQ*yBg|^ULHebD^$UXfz<fJGQyj!?
zP&3`=5D@4NdzrKOjw8hrw-RO~OGj3)Ob!4;6;@K~&2G_?+Xh$1w<6WRH0|cv*^MUM
zjy)d^dJk>UdbP8y1ku<u^fc*QfZ&P-3_Z`DDY?3;35F~-j<~jBey=IL&G3aI)Q;}+
zp!h2rIJwO&<}4(7*h#eLLIPf2AQa#<wG{H;V10Me8VV$*bEW~CW6qJ{ZQP$>!1goN
z127AZ#hFhKn*wf3Ji&Gk6hmvA%bbWSguU&+snl3yhm*btol-@u9pzyj-NL)#5OpOL
zDM>soO2PTn?Q;q-077HCF~+&tx{*JB<tR<ERS2~4Q1*w$LkC*Y0#F^YcGH-s<(GY-
z{Bgl&DQ}@rr;P)QGMc_%|AqGi13z>l;GBH%t6SpuiH<|V`7hH>L4dC66!g6xR%+v_
z4d?qIOb)HnV&{7!HL%!k&h5eeTaje{W%FO`Cdnca?8aYIy;~1tI)#T@eRwLRU_&AO
zkMCS&8W=En8z$a|U&0u+jm)0;H1hMX-E)*C=+RrjH0z+$ALAmLQol+wDyl8w)?Sp;
zu<~et-bp~~%;Uf|shyG$e7y-jV1(u*6K?YVW9@z5tS+km|GUeg3oh=8OQMpZ;$KMd
zZz`Z*yNb%%F0uYaB}Ls<E&uGQB`9=vgX?mW`mlYlC^509s3=L%KvyF`!^EOOBVCPZ
zu6L{b=$fmMe4no~@45GVFQ}jI@Arkry*u~)K6B>GnKNh3%$zynv0%b&+l>hq_|>%w
zzus@X4#NI0I8GR~*x7o3SwE;wEcxL!4wbP$ik8x56@)9Ch*=K`TgzzB!WEKqr(LLB
z;!*E@v4M4}NdCP2mb2deWlCOigixREUF!4ysQvdt9p&1;p}75zcfYzm*8Vx*rtbP&
z`=4O#FR!&<AZU4`e(s<+SKV*mqOs~7PD3LGSiMIyZJP|5Xc6PE7$qmiDKXXXU#2!$
zA>5{DL)<UuzT%(wLm5mzr{qx`8AJ7YeXLRvn#t(at-CbToA}&7)%(v3iuMD}Dc%ow
zKlzF}pyb~d5o}u-Pu<eTdEJn<D9DIY>)=TKx9>vec{xHcqjs6Xn7nX4!t{4uKbiin
zbnme}6ZCiXE)#KLI7;|XzF#pr2Xz%w+&a&}`U#3#)G}K7q0Hw|v;=6)n2IETLR@Lr
z_K&NT(yrTqb!`(94u{|h+;eQ9(l&Y<=w^m}M@P5^HZ0*r{ljZ;X><4Zt7@ol(!$r5
z^{Uotsgg+3uV>f-Ci^L>xO3KF?Cr9OnYjA^Ly)qUoD-(jm5-K9#+=U{V{bm^-z4uS
zE4k|<!Tz&4Uc;iC5VBQ}8w!lXsC-62i~_qCRvv-l>Z)`^qCC5QN8>04ppkGm&pCJ9
zaUq<6@88jmv2H1{Ho?b0(Q+oSWVM6nIjKqInXf~?yLY_KcxgMIcyv2DhLmg9k*g(#
zRVYzkp1s}m;HaQn(V1Yz+WILLfQQ+m%$-S-Q)jXFqX-kU9**+$ZvV9E<{xS))*ja6
z9zsa&Qp)|<hxO*eDo8Q&VTauW1T}sG)wid{cuwNj{YWiUWb#Pwk21v!jyODLUkhvz
zG1&80=U?)pM6Q|d9>{)8J@*6R?Qqyc5i}y2EX>BnB-9L7Vd58{2!UGfQ?UVGIv4Rn
zgMQ3N=r9>Tn)`G8G@ND1(L>87yGEKI7(V@WvEP#CXeGU@<uDpEY^-s28x34ymmLhy
z%Al=xXpr8a(Yk1_JXfAS|1+RgMkCnZZfq?KMvtrQ*QMz&oHZTn(9L%9U0L>zg?ByX
z@M%9w`m4a-tLuH%8&lV~6T4EiE4foHMKreBHQY>>QZ%ZK7|mFw>AICTI&8z`gIfZa
zi%Ije>b^QTLQ0%l_gq=xcPG`$yKMsA%>>-e%2@=tTjec(OW=27Hy-J=e`QX`Z1U|F
z%*gIOOh$G$>iaMqN@3*J4zyx>GZ$n_k~iH%_^$g)_Aj8(5@>d$ZSKkCOsikf(|c<F
zmKECtp{vPuuRqm($?kV8W|tOyY}v;A1x(dd#H7^PAAU|O=I8sa-zFz$u}aHJ9Wdwt
z{a}i5nk`;2MH-?-EN$>uBHLW~$gl-G;V@ol_VV=ul~!fQnsCp*qJRPnqwBEW!Z6B$
zZ*D;U$GPg-(bO`kwqF}A_ox!Th^?CK%8jW1QNJ0*^;@^)edHxNBg%L;r$nU(d(XW9
z^B&N?qZSt@Xq9s($EFZ~AxgKFY)Vd$>jW;e_fWZxVdhiOxY3U_RVXGMRrLy<xiboG
zBlctAR`dwCQE!vp!$Y>F`nb<P+BVBaMB7Ruo96Sf(5v8jgNRs`IZadhx{7@N-N!FZ
z%AY*Gs#^OuBo<*`bK3}aAKO3CDOzp(ZrM;GQ#hl$bY$SU7yZJ4-?tsvw6chV66f$9
z&b1oDPx9$esm66gfYap1wnyo3J?3N8ZQC&;+~HQ{W;xz#cX{)MQY-TdlxZyIJkNt-
zJ)RJM#S`LO`b`u)u(o@{M64xMvzw!3mg41E6>A>f_MUC!mZv5&FXd4cQw7FYGT827
z=5c-|pV>Kjh<4h>)s^1{bCevQ<yR%LgEtJ+Upm{)2ky`t4qEAN#}Ivwv)#JeDmsSg
zS8AB{?jqlmmLaxt2~CV|Qg+>`VK*rw`op`iFq%P<r(8;<Dm7V;X!g`uNL4p{OEqA>
z^Qt1n1<j^BQfFb2bf*jh{n{3D@l1Jo#8mgGBg`-fPr3NSRr&Mp5MA$1@~_dp4NcF9
z4RVY5r(fbHK2G#jxnA-Qiw_FOALZWnWYx*W+_W3jBlR4{rwW(+tpy7~$adP&{Z2-Q
zo!n92=h?9V>r$K5hV=xQ9sSvpS=!e%1hPr$-BDw#AJR7tbUWCLi7Yh<XP*~N=Gmp$
zhosiLKHJ%}GJYO=)Gp`UO|KtZG$`XQ=Ej((Y*pryY!yJn2#5fzLOwtHX^Gmbsf#Rd
zI)MN)M*-#(|0Gfj_$K8PL-($VVWBu5DF#+Pf=SSgVz9+J7B*C4St*=BWR%zz{8YAK
z8^D06=H7tgl3!?S+8$R9H`z{nUO9}=<fOpm=mLX?lmp~{MpKa4RV6J=5Re=3FQcM)
zjZs%r<V3LM*8cwU2{lc=$X%7e9}OZZGFxK}dXX0~oB1g8cKOt%g>kIkjpuQL*sjX0
zC_YLbmJqvJU*7#JY&se*%m;rQ$73ZA@pofHCt^QeH9%VM4HM8eh*|!|{Khx2K;Fdr
zc>+gf=YHO_NGtu<CBJ|h$q`M%&&`iiSI3H~i5HbUlgwV1jBBXA^>`KCRB>L6Z@;wt
z>WC}uNcN&~HT<1aHus90zJ|rPA@;^EMMUeg9JNk9HOi)dJ&03~QjW)J?ZGv;7r$se
znVjvlb#!^>%mrt5B+-5mFGu`^<Sr20kcn24inX!Z>)OUQiPO>EMj^=wrU!4G$UX!r
z98ETwX{aT1MVo0$y2-ez+i-~Enr!SSS%q6na|)aQ!w>4O!bO<69NkczvIN<@Ivr4+
zGPUa8k27_8+hEhX4@$L?mHXiRZ5Fn9!lHOj$KY|3t8ZhG&HsR^px=5};TUjMHSt0Y
zDbS4CKiNKj6~sgQbKl;r2U@I-Y7PbqE4Qyq1`ZtErgM8#Kxt}HH3QHHqU@aFbps(u
zYkS7kIs{`P%^OUZ)iJ>sZN33fOM`J-qif;Hag#A}Z_oTiI)Ocp(=-KBXbTa-q^Z6v
zJMICE86N+(82(?z@c(LJ!C>3daaP%bHqwCd^PCOjUS&NKQtlGXo^IokM>#yU`}KSb
z<sHQ+OCOZmT^QQ-_9Ga0nV8{-SKAW`^lq36_S%yhlzaSWMNQGxGb5*}ya5{Y^}@Km
zp0<m=cGJ}EepmC~rnD+bTF<gBJviKNqB#D?nKD^S#d0d@Qrn3SU2P3}N4~3N9u^*N
zvb9{&VQ#PNzWIDIbeb8h(ZvJkR0^k7*AsMckJrVAH*FUK3l!|%&xo}~rhyWS#`Q1m
zURlkLEnb$!>9k>HhQFVK1r0p-S-op;SNJD>4qdopv>=A+(Kr<yL(Hf0)w0TVdE*2F
zLH8YCHcU5+>;bbKQ`!E!$zpHv^Q;HlOh}s!{N>bey&R~wNlI_Md)(rH*g}?`50?>Z
z<oO|^qdF~j26MjLjzZG<qL0ynDcR6e&nj20X`Zz0^rIqcmMexqe_24k*@^}Irro07
zi1RDxb#M2^sZITHv`vOK^1TZ6)fJID{gn??%oM{6E9wL5zAn_g%ZPizBe2llzV54c
zOWZ0MyB&315Vr=EyPEVW{J-jAb^pb9NlIbeuMFr{hPtoVE&AmhwJSln0`$wLHjTX?
zhV}+S8`T{wNsV#WQRBH^2xA%kUw7D8wwjDVWvz>e&mD#%r?QZO>SWib`ldg5>1c3&
zJJ2*LSf{$ZW@#)b%Uq-Bfyse9HBaVU@(Wd^t;C$JC_z0g|75<bO|h~n3d%yD3I~VC
zMYgoE{nwFbdNtWAHAxE;sL5W+xk2l?(Sqztv2vE#=6t+PK~2IUuO_KynUKcSq);x4
zq1+xr*-(tqt4X7)nmNx@&oBw~BL{efNeEy1f-x-naahEhglc)dv8ubwIC=?zBH?JN
zc4<fLvcUDF4esWEWH)NmZ10@?&3t#G=DSs=PRyT&d%ydgvFrc)4YTW`X}M{v>fZ&8
zRhpe<2G?)6@z}`1Z2?DG7O*$_C%ap~o`&WNR@l+D^B!0)b)pGP!E9cWixWH%@4M6B
zt7zjzvS+5I6_F1J^qO*<6v)wSKg0dgBAwJPqolu|1`TRKD`6w*U8Chi6)=cYwtrV`
z!o2khsKLt&5xahUJdr~&GA{e`VJ<*6c3>LtoUI<G<3VachCh0zBi%nWuJ97>*Qdri
zJys%!ngb&E>JfFzdq5L3rb661kymXAmo@}Z_m-n!sD~D^M|w<P#eKEj&9$H2y(g*@
zwY|gY6dfaE*B9RTeP9s0;&(Q5mO;;lTTGO^@@8J{Ns1}5gnQSvsDmOqlS)i=UkixP
z-5$|KU5wd*Ydl-U4RMu~aE}>+Se?j|yrU{n+5WKgc}_f5+xh`h!3hCzS4Z8t2H(LN
zyQaEMd+t?vD_)l6HiY3V4o4Zn*6_rJFw`|z-X;{SwcV<Yx;1cmHI%KYZ%Q=e6e<29
zajNk0R<)k=`RbdN#v$K1B{t@(P5hlmmF*AiPK;I>O^DG7qlucK&7tY)K-01g79=|w
zS3uKpxV6lS(NXbJD)X$wJj+!%5TP$XbU;9~q@!*rnV0xByD5&~Y(o&SoOyYXJ(lcg
z$)9Hs(sbPdH`FOm!3ye>kQ4U`%@gWYXr}Uo>Z)70%CEw9rk1OVEtguO4&xe^S0<k&
zZLW?)&6}Mu&XfI~>hk%G4-4^QAg*t^i17on_~Ck&At)Yu70kf~!O4eFi$b|<q(^yA
z?Xvkb!<>8blWY_qxl3Gz)COMKROsQUO-D7Jo4CGq#em0-=h5hm4c9lW7?7?RwyNGe
zNlENlw|C7x2Ct7PZ0MPeY8p$9rfGaNAIhQF`wVk~d)4R|=~DXLxFl7T*@Ni}cfX>U
zle3rZb8BgKpqtYB@15{@ea#R@pv+b50K5988-yzQ?_RR~<!Fkm`rfDTh<0A%pMNKF
zY%?LOpAb*(rno)4>;1#Jd3K4r8w&OJb_=c8(=<!<D6mH_x56XcEBl#H+}fML4O>h#
zHx{OZTGozESM_4iWBB2d)+@)i%C?_qW?0wDMJbhS4=F9PFf0}fz`b#^jd+o(J-@r+
zHcRrI($*ni%~5fUzs*}yLbKoyn};$jr@FuVI<)z49?FbBGgeu1F<FvAA7xJ~8k!cy
znLGQ$Sl`PY9l;ohOu3iEL8lsM)D8wQyuN8=9Aa!7SwS_iofWdi5AEhGBYQmWzbQW&
zY@z#2Vi>v6pWEoWTj_pVrZ%mP7xF9HZjQQMa)J)eabH=$%%TwH!bJhkCS6!;R|=QW
z#Ozo3Mc0WPLzFL7*JV_)*|QM@4esEOZ=H<d$OhHbA%!8Zxb`U;rQ8r(d@IkW|9}E(
zv81&wAVq6}^x40tWGb~f7_&`1@d~|ryqX}-SIQ+w=PFwyF3;X<HH(BJ`EF_J3~M8d
zomEy$)l>amme`@O;w}rtp;}gf%Nx2))o};rc~)e^Lvf7BS%aJ8i_A=5A6UJ@;>+%C
z&Y3foLVqjRDjf_fiuY%GYOL=N9-+c6Q7SstP}{@kZ&5D~YuYLgvM7qkCz>W+f+i?+
zM;O7mZfIv3PB=fzMCk|~vS~HohQYP$Bd$ibdt+j2nT`?hH)^NG^7WXIczLv(Pv9SP
z(%mg*$;`fOyqkdIs%C8F=XqM~_FLH&)u{(9L08ySq}?oO)Hkt^OMA1BL}26n@hhUj
zw(Y>)(l!*a`Q2>eFNJMmf@f!esGG=(>Q)o#cHY=n7c{`J?!xn8b@Px>-N4`$SH<eK
zRPzSy3HGv$X+aGcuh}K+yN4@s(YDbAuE@qcjXUS>!%g?>yGb%_{6R;pNwf^X(z43+
zv&pnhXCW%vb%czeYrQzPJ5KF;sqJ!LjIv92THO{nrH#1FaLSm+&Y(J<=alv^N?0%7
z+c>ql?9y`+3{OK&v@@BT0>d_WhHXkUZq&WsMCcg<U|?87VA%f06)+6IkGaFy=-QAt
z6a)x^hx7~+26tVhXPDk+Z?XC`hnD{|HNZsyZZPk<^;2#f3mj~3(%hph;3c&g{q$+I
z>m&*5&=}c$3SY4ss)=e;Pi2B@I0qsa318iK__<BQZYX>EDP}<gk-4XYQVFYYfq&5Y
zPZq;DiN9=A>`zC@<2&Db@2&xxlf64ne41VR?<Gn~=C-(wNju1S0<joIeJ_z9I@rGa
zVMDDn`&@d`PL(qHsb8cgy_ZY<Czsk0rK}rsK04VmT}#xh^0qraH;3_S>yNEQPr7q#
z*cxFgI=W_VnH%^MNu6KL*YDr`%px#&aIMP7KS3ii_$wd9)sMxXn4b$gM=djM;pQdf
zm-ndvp4nIV<l@=alK0td%u#-O-p@uiPor^nTa{VrE;;wZ3J$n0aHp=+Gi|AOOKmxJ
zGfKc$M$Wyv%(Z^6Zebfaj19Z&A;<M&IDa0oL;Prn2vbjC_JmV9qE+q#u3`r6utz(%
z=_BMR#uv*U0b>r~a&jwfgyjQpwWzHaP`g7HUT6PQWFDz}DJpC1bI{w~yS3%m90k}3
z&_ZXf;J)c`8wsOnYA%J<g9g-P*%e%}49p|6C=-T#Mn9czy~6YO664}Z#Q0(H42;^8
z77hq(=_m6Rjxx%-0hbtI!MUW|;zEjk-3F{)mh9Ry+1+pK<1#<fedP>geeyn0h=#-*
zwjMb$#Ce-=y}8xD2R}ZTl+S-Vrd+wUKFP+R$8nA2mB~f?R75Ulx=mXEnv4+1Mg5_v
zjEAliNkZ+1%{1J8`s_Xr3_qEMy}(m@IlfAvwoC$d^7EYP`-q%jv_)w*J3>c48<uvD
zF<RIn+dzFkyP1!x?9t4?2>(@Il~wmVB+D@(k(hgIKP$xL$yNAN#A@oLCh&`LcHq~P
zXgN<gL;+{jAi~qca+9ZNM@N;d;DfHrrtEs`dCHiQk1GpLvyVu&3_sqm92ndeme%`D
zb0J&(c;cWdnW6hfN&kp~3L<^P<e_|kwie2{pjfpj8|{CcR|eXm_J<`*03irL5CcVh
zG!4k(^HUmXxM32DDZ5Hyjz5w26{KqEN`-4asFg9LbCOdGUyPp}4P32>Yw=8FD2#{_
zA3%>5NXim-;ef{!U*1>>4=e=zkHrwgJ3ndT_XzLM6e#EqH53N=uD?&XHw>#LiT5=2
zVh%7t#9^eeUD0ef+G=d^)0v*^5YZuvCTatIc%5{yy&#S4Am5_N#;M9ja2<PZwdp~>
zf;Gtf_=gFN>)grQXPTlfdw^PJa@pKh<pYp>21l^|)Olr@Z%}gfUiqcV@<gy)nd+RQ
zzvY~eW=Em&iOAu$fIK&@c6-Y~WTmO*zGmp39iYxcv(@!)Q028{2kQG6j@bIehoPSp
z%EJwGBQvM|)TFZPZl8+iNaGm4v98pAqCFW*+0wiRmz{%*qR$|R{hXMlWG}+L+Iu}K
zp_d#JqeTBeP|_-m+u(*UZc0A^P|AC4lMh1#3hPAo-<>F$WEg#3pT+27_kjtzbX9Y?
zyTs-wvI<QRS)UYN=GrjVCuQX&fnLP%W_kE&GYwPLB*&DQ3>M}a?_aqrcS@_*`YIPy
zSg)dfWb_7q0#pRM^xR=!ZeiPeqhT@U{W=(D*#fasMcr6-gBgQtn0C_^V$yYu<>ma6
zf)~HKSN0pbEhxA0z3M7jpJXL4UAuks=Eth3#OP<~Xsis@ZF3Jis&?8&bqW2j>`%6o
z5REeVPG|HUm0!(a-#A_Sj(MPM4fJl!(Yp<L*Vq18CUfHMgJ-dLU!J&iKb|0N<!`^J
z5%f2Sw_jo~6@9ot=|~#ahETC!5#0&>R<UhG6?=orQ41@E#`!Zdd(JXPh^W>2l8?ba
zUta~;vih<FS+~{w<Pp_(tFP~>Z68oy<el+V9rvkMhd=es@Z>uscgt%oXcY54^Nm^@
z&m;5~<&Ofrd|)=<gZ`aZ_Eh)qr}~EnRUYI!yhpg6NkBqQxCB_3-{H1b=s_IlkwxIH
zL<yk@%z2i&Wd<c*Es>n}hl+(m&3O_6esUk;a}SLK{TV_(23n%QC+KI>7v%USV_v+x
z!T<a6=rQoa?X{cw6z~J9CE|ytA<!G;ulTV1m>3_Ff5?aBANj%g_x`Z_6F)eA<%i{;
zvul35WiRw5p!+OK84O4=o$x}6T%b?D$=oD7*fSl!-r3k69m)6d67nA#<tH}R$b$S@
z^UoVZF$9+1%o4RfnwR#!SZbj47)jve8U|(ZbI+9NXKeL)_vpX0MC9k~oFesyi$<a?
z7<rjW?zFj*vL8#2#^6LvqiC`$Ij|t9z-Q}OVU1f!Mf%Ie2eK0ZQ|vI$^b@Q;{w@T&
z1y^Aa!R#F@8Np?y<v3K=3yY+~y%k=7U-H;o-?W+0Ml`;Q(66>1lE^$iINPMFVmhd+
zl%3M|)9=y>N6tl|x9a(>b=W2U`LX<!3`-&ZiT}&|djZF?xF<j^$^pR}_(AMSz%J$g
zN?=j;yJPe}yxZ)%sedg0KV$iC{jmIMKOE&~zpF6B2pQLMso34&pH)&PocDRq3{$da
z=7;}F`+{)U@IN%NQ~TW^-#1~(kN;+l?Qr*LZXZT$t3UE1S#Yo5cSgA_ut{@?yRO&6
z!JdG<X+*Q+*q%*fIq~7mj|%sac?9O>Nuy5uO=O5-`^nDMc&=L>kcS^ra>4XT%d8af
z2cyX3FWj>oBrxATRQ*h&ud?mSG^_eXWm_95G36Rhxh@4X6T4MJHcRgA^lx-(!+nml
zoGB&->dW1TKz)(%R8!166XP9j%1=Qo6U!Y6GAoM{`vv?o{S8fD;eZ0%{DkQHrKMZd
zqf2$qboqeR9Ic-btshl=SpLU4#BBUMrDHZ4`esVZHJ6vSF#a6pOK4FESNrtGMA}6@
zy|2=Dk~Tc0Dn=T|e#s)tjuXH!9{3QYFCZP+k<g+!tcl!_Xf-Ze%uQe(T^T1SG?o3e
z_6qdvls94jfR+=5`-}WQSstnMUrB3%SKEKMS<^9#crTXtKfoXce>6UZ*->u(2YGfo
z1=BpF3jVVfmuFl=Wj;T2{J)tGK1MIkm6Mm(FdKlBX#S=qZn-2cdrQroC1$wW1he05
z{BCi_#k%R^Y&&Zmr)vU1=M9#4@|gjCd`EJ2_c%w`F7?lOpy~9AL|97%e)_c6QxMJU
z34%*n$I|XoUCnYok%^8TeE=P-dPVb~;<818=Z}UV4G{7dvV&oMrBSVxrCUj3L?)Mq
zXI|?wT)u0D#|ttP;y(!Qts?v#1>kx8?R73ve^I`HcABS2u7Oakkq%tHtf++wrdFDY
z=6IRhh=ZJ%snNA?y?|atRdY)l)<Q<V86UE*2kAurhuPQ39(Ie&{(TaJbTQL=pJG@b
zeMP=D#~0QHFGQ(=e)l5JF*@?&gayErZ)^)T3a7=)py{O+%n;?g=#xFEX>)g-wnD%9
zrzS|69#sswYae+Cmb?F=<tQ;bPT^jd2=CNRD;O)r?E?st(sFlG1TviaYuGL4EhU)o
za0(=Pp(r*`D39IXKjn9W=k{n!*u_CIUH7KzT53zZyyiaHCAO4t(E}?nYYyM}%Fdk+
zDy4nn)eY{Et0e8^9mDi&?z4%JG`FSG=Brlj9>O1nmVw`FrM>CC1ZL>Ve3h{|a~EG7
zLza`1HI?MMXI8c!!jlK|08T!rzfu{A>tFB>E1#&SO1^Vu>s62I=~J&2KAn<oTshSZ
zqaX$ZLt-mHoFp1%7+JBkME1{V+Y2mrg9>ST{eDlI?hsGQ|9KG9fQz(y!uki76FYY`
z@?xjGoZE`uAEI+uy3rZ;SK}xXtL%LdLTz^E394)>lO8l$SXoZ?PpoXiV~HZU74zDC
zq9V7spBr+&|HRp+Rd7R>9exSW^#k>bI}f*^9F}82I`=26CVn_qgB21--g03Y?+rJ^
zBL-xfI|PvC(x&Q}><InL{9RZ?+=zdq?ypPNE;gVkAhgQ`9oO0|q<UN3=R+CYsD|vM
zfZ~>bq6_DmbZr;e=R?yrH^@+I5qHwHbLc`_+$jOYH$kB|7cE?r=iL2rpwy8a`*jGW
zhMqo#n8V%*r9VakU?Utwnvu5L)lq1S)yHDMO0Mt_OJrVzML8CbX=qHyCRVm1(6Q!V
z)u2#5+*j{2iRXj_p*5zc@SCjg)`{u#9f+5E0LPg6bo))Dx&Ljf^?*Rv&v+N3>ucZi
zbbXsLv!hH-P$ur57DiTw<iTMb<3<mdos~Vv_wfaVvQ!tnpPoHGR~wc*Mta~Y3xP*Q
zz{i113oh==!uN^jePxV*9@xU*Idd1s>il@P+B)OL9B<18C;QKAooapbsaFdgk7^xe
zB{#TLhZ=vpMjKVcYZiReZ1wK5*41QmWrt<=<*~^2@ywYI@;JV=67>Jv9>&_B!5F<l
zA4_J&vYK|s$pqsXboX&ZMS6z{%<Lgc=|iqn-37t<J$*Fu0$-dwcU}04<OE1{Y>~QK
zh`;I~Rv9F`+x=1Vtk8?KQEHk@o5?;gd)>sAk4J^S9_gMyVHAUx;%tL_vluI<IN?oV
z@@0ndYJF`M_B4I<3cBgu-h)M_Pa9X^%YYj&&LOP9HSgOroPO-fnd*)(rw7G5J%#Kg
z&DBj~)XSguP9Le-<*CLMxP##~<+DfhJ-u(F8_#bZ(o{nZBedTAftz*VKj=;{bbB{V
z6S_G8-O^O!GMtt=8kcd$8{7MqE!j21bT>vo7AHur+!_~8bw{)Ah(2`<gcD=&z3oA2
zot&^xs;sh2A;y}k{Pn<#-4k4t-Z4b4*lA8T_HcjpH1l??@6e&!P55hvZLLk9M15(a
zyycJ+pP66xIupCsnM`ezB625jVBFekG^!_ie7bHi`fQ6SB)6C*wB?31%}4sajc!@v
zUO?|ymVQ)y_M|klr)#&=r_<{34eqLtYc;t#n|OwHT<yLQay_kF)3C(w593f$et?_E
zNRgfayt@+r8Y|&zz(!2-177yP=7~)juhQv@1vv~>8{`c@!qEyu=b%V--+>UCrZTN{
zTrbWaL3q;mWvJ61Lm`MZ<^jvP&uu935W^mr+rud?1iRlokJw1|Ht=^t?M9k{T@hRK
z4iYOjn?gN_rz0}N6{%NN&ilPq-|DthKJu0N#+n2-_npKaUoYqD<@L~`)JDDSAf|$8
zMwE*v&sWM{1eoru5j)+PBTZ83o5!cy$MdA#eU#RtsbIxccL?fOe=lMDu6$x+@|`nU
z2RDz@lRqFf&1Wd}94Xt3BT7lt`qGk654MD=(>lHcg9cH$s96a01&!d_ELFEs`YGLc
zlF`&*UO}RO`9BoU3r)=RyArKWOPmy$E51p+xpI8#LAv+4`L1;P7^{iwO<$9K{H1+O
zp2wS!{ET#489DpinT&_ZB`UAB+pWtpukVS5n#EV7hI7iNY;d~bmlxv?V_C~UnP~)!
zc9dE%Tj~0z=}nTV$|tHz(q+FJ3A9z@_Y{;l66o-n-QyL7yg*ghMOHNP%X^rbs(j>&
z+pU?~SMtZ_)Xs#J;2Zka5o=Ed^=>J+19udoV45gc1mazIm#%(JP{xEO{_LCTF92q)
z<!iT05O_m6Jqtd&1>}g5FVH&aPCYeTLnB=G36~<!HnVY(Zf~*H>0BVmt4OEy)BS;V
z@kui}wh{zb0&^vqc3Z27s+AgT@2HHEf!tli1c<ipca3Nbld|?vR{k|u1YSD2-RF6y
zUilMx4bs7F6y5G21_GHhe%!w<l8s;EFvDA09u?N-v5rLOBRtQ1Twf>fwOgKv5)+(X
z(PN@Y<)opygb*7ap-CB|h4<sw5yE=~*rI9$Qwq~u!*1^#OlEoq-VzbGKH|g2$iSos
z(VKI*HGH?b%v8J=N~CUik<=~MQ7P_;etj&_3z=h;RnEHvdB!Jj=cx9Y3v1Lf(^KGC
zgFF60wOKhTpmPKdruye@Fic3*F4N86>2$RqJ8;lhg)rcEYdX{BbxX~jQ?2H+J)R*h
zrm-@OH@K?YCgEwXu*PY^OUFi=CCy{f=`xRUNn{V!b-DQ{q;#iZDol0b1MFg8+xvKi
zU@Ug6po5iNZn|L8imHWwYJgn?Z0C06@2Fek&JD0*ft84E6Bc)sL1VHnY(6@j-XaVg
zbqn2r0lHMsM`|%b<&^PQmHPn}R(4!8HdupyAK})UujtJok#-N3itomIMglMMEb~un
zk`ERk)jzWlFprGcO{#W5q#uG^)X}(rnMQK<CX9W)$F>}jo#vaqV5CSBfnUV+flcOM
zI(>uK?cSOn^-ukDA7_Y5cPeQ;`_xx_rYDujX3A$rXnx3(%&~k~QA`X|b#1$hXKm4G
z-pnKmp6P~E&f6-HYjlig7b9}Jt$q1rin&XlKOic762<IRI|!1tU+sEdhR(cQaAxbt
z>Gn<5winXnkuZZgU7a`&HL-O_K^MsmPp8+Z@!h9wMDdvhl8K4gOqppf{z=HV=yE0u
zN|~jS?o=AVSnWnjw?(t`oj{7)U!uC1e=%z8PG^aH`qp$1xMQh7U?mpGsksJcI@@xL
zr&@lOZx@ivQ2%yAgkcPdEW0M2k66@J+nfoV?o?UUvR6a|{sr2y7l)Elb@PiFF*$qw
z39Kq<N^zM*mSf?iJo966d3iYH6<<*%K+%&?(G$fW$yR!(D*r6|h45gf8jQKgXUxhR
zEWOY}*T|ly)KF5W=QEnio4RDHU$re_`!uLeb;^tbtRda0-&51=YpkV5^aMrU?-tTW
z1tKYGAvZ;7S#RMR=hr0mnNpKDudXI>2cMhy+|TFHX*G$&9{+d$N=izje^I^xWdq*l
zp8y8FNICEFIpl(x#3%Xuy`d(tnZMuQ^DdveK3S7U@>$RGc~ff=-w{m}|9AgN{J+xD
z0hX_<V&K3%2FCvFSw3jsz`=ugZ14AKsIN(^;PWNQ44-wB9sm4;-}=O#DgC2Q<)2M~
z)|ma<=bnGbVw<D*``oSFYR<~`n;8v)plKTOX@1AWwX*G#JgIzSh^@>#({eD2G(W?{
zV#KUY+YVB>`!0ATfX@Oc+<!x`5S1&#(#gkpuO3>vEY-Li0H!9(kdRpjO1*oR4(d&T
zKKEIA3%zG2eeF=~(=}ff3>NA405usXog0d24HngIMtK)>!`$l>Conif;YRs08Xv2i
zHw;)DIWgqjWoF24=8vhpr@C`!t4osaUfFt!J$|7(VAInxTc;P4WR^{&xjVuJQnxCQ
zHl@Un*zFF*MnK{9xs+xHAE5B2dDYS2#-ik;C7WkNoyxsO&EbN4NRCXmPZ9s**|I07
zZ4nF3`l*Haf6!sAz~K~_(Pf&R=r91;a5Ekp4eo22MhGvfSR(o)k9mu`G2qz35R|C^
zN0_(OwYeEDqJ)Pv^<IrOn6_0IXyPTDtMW~}1Vm%3iTCql8!;W4uK8KqNLn5-sZ7_k
zg>{MvJjy(z(Wr11W@BSyJ7&VV_2%Zw)9Dea0G{Wr6jGTo`wCS13T$#K7#XeHeJNLm
zAnmG7t#&>AhtLc;O>CublFWU{7m==8;m$`TL*&)UQt8v@2D!cx6jtd)sm8_W+C>;(
z6(UFZ-lTsqU$<4kcG*z0)JFGFPmXhK%p9^zgjN9T+->?bxVcp6W(d{a-=HBWcxXXq
zY`+9ddb`TM{RHU-dP!uBy-Z$f$91qKSYzwl-=M{qu(#$bg`<xzw$HsO5{^xG%2b=`
zYVV9pz%KRibXvw5T*jUYsD7~>_!Ep{oif;_x(3W5D}0U56Pavl+)*LVz2wQ<%>>ie
zNnyXX&#~1}z9+Wan!Q#1<9mNp#ajqnt6w_b!X8Ytj{EoDMI6VvS}1c#_JlhJ;p4mw
zzTL>bj0FbM)$Zn3^mLUcMxzlGSmnOKQ{zRcDo_!s-^VYBj>e{~6cWa!Z(dxJc$Lr3
zFRDpQz6AZx=gCWJxOz0EzzdV51H-!k(TlQZagjgh<7CeawcuHlV(jBwz8jVsCY}2X
zy;%S+pfwSI=A5ozA@uT~s*~?bY$5KAU)}!0mWV6e1S-|)wj21ap0HrFL#8kWGIhtF
z;AL^7->+2bkbS>fz$4ysK9KH{D=GQz#Ma6J6_>p`_YyKHyr@12rP*th`z=&KXfx-&
ztLGO4>P`#P5z%d%8g-@n+V4e3pTfUtWnaDkzo2iSpFM3$p{>{T^2lhr2-+wGxN<iR
zY*FKgtH#fY3s3Ai@fi@}w_qlzb`ZXTrDIi4oH!Ox8h0{e*|z`UdFU6+oLkuAV?TOg
z>poIgLVhe}x87VV@Z`IbW*zH6>hC7LSRdY=KPhuBeX2Ckv9aR~d*deEH(=wwZ{Rwe
zYVF6R796KX*sF_FSmr9aZvG;WNF<E@^3bX*+w9|~BrRSBv(vIuV+!ER))R}mFY_gZ
z**uxbqKWF8KL+{r?)NZ^uBfW)o85=SXRR``H6j=uhRsyZzqvijc%uO|kdb_+p><y=
z%c3fT_mDZ%llh!)jf`E58CHpt{bMT^`~;jikx9OLTIIcL6Y0dN<mBA&rX=Z(yH9Zi
z32a@c@k6)@>C#7GMtxH^!FFUgxQ!@LQ#8HVlOmD`sV6+^I7(E+pm4HJC)_><9%KyJ
z;)s`b3oUoAzhDBDsnd*@W6kb+|FOQ4Mp?YqE|PV|z3p|?r;tQJ+yDfTHtXd*j|Y`D
zrm5c*krBi6l+`V1Q0BQ0<ZFSVa;2dbJ-T%~fVH_V7?C|VN-Lt3Vu2u3wGolap(1-#
z#6^5NFs3zN`?a8jG)BaxXqo3*XkO!#V+%D0d;@~$t_D~WK^<n@YDX_A=H<=C3&Ku?
zw$unDJv&o*UippkY|j$mGn(E!=bzZ2xh*=pDPk9UEGA`Ue=daTyi4t_QZx@Nh-K#U
zxq;ty49CtoC&&r=rl;L~T47@^)vA2qV8#kP?3VVxzvQ<b=_s{p-JAyZf~{<_&pF2(
z(WZ9gm~3U+Q=-jwPP_aPuHJtwnQPU>sm3MjTc6ch_ov#$f4Y1j-iCjwUHGRFqnhS3
z`P9tPoeH*SHrwDjejt`t%j@Y;+UZf6ezobALxEBy7pVy^0Oh3C$uHI}e(~}ZFV?OQ
z)_{`Z_3keaU?>fLgpx)7M_BZKgk^du?{fFN$fS?g<k*CYv*x-(%{3OGVJpQq*G+nI
zkblCOE_);$rg_U<=GVq3zkt4AW#Iz4>8De7ZL%%CjWZqMuFmpaJ=7>pqqmpCd6OGk
zoA`bN`Dq}V@6`L@3>H#1W?5^8<YT;wddy&!h5&hs5j`h^@(kj{UgiYUJ3eiDSI+wq
zJfzRCLc4gT?DzII{uIfAMiMuHTKlHywed7FXV>QLZg5%)2w>l5*v(Ea?&^$GZY5*}
zs5U{J!mbHt9^G}hUFTkRJujM1R~?S04mKE1-YcJP3a|CD4UvaO(M<eH&s!5@Ck93{
zytnSMqd&;(*Y#L3&9jALGv;U7PV<(#QP25C)O`BRt7{U=_-y3!4?ewo5+$W&`G2|*
z+W)im9T|$vEA~Dw6d8QxX<s;*tg=eb7Br$2+VAdV7*|8uG759H7NnC=wk2xBu|^*u
z63-c&XTbS1eokDmGg=}RBz=L|a|=3S9J1IV*+cBeCOt3KK?*#vo;G|_ju+lOsEXCE
z(hpqKQE_)QEzla$?~n_c*8KB#__nuWOFQcAy>zGh^!eJF(=Oq7pJ{0<Q*X$GOKsnP
z+Fsi;(TY3$w80(GD)crU5Aka+i}LLin!^5Cd+dhZnI1lSN%Ij}jJf7lk}bMj51Tq(
zCi`74{0=ph0FB&5i2F@#^grvREh1%5oRs$~f4k>tw#m$m+kC0b$BLG78L%*9(S;nv
zpW;U~v|hiP0X+o`cu+yxhNYm-6q56WSnEah-ER0XEu!bMM$cc_e}M~3gedkgMmD2m
zvwv!|Y(YMl6Y=`%GFjr&@7+`N+h+=xv>k>QT28V4Gb(UB-+xwl_>2Z@+t~d?Sp43h
z{-c9XJKQHVM8!yHIo0!VJNLW!ksI3k+;Gv3O6hYilffKl-eSYWH+!FZNBl=2^tmU6
zFO1wWY)5+Rxe0EV;rwf3LFM+$SML4v!FJzBnJ((%MesFnm}a=|??K1*yBncJOnwNN
zl4fVj^P?+k(Gtnqi$pTa5r%;*spW%SoYK{JLUI$;F@~_^<KASVLKm_Zds51W)YES&
z?p;{VgMB4p=5I8Ah_zn@XFp$o>dZ@g#R?fa>(p3Nop$#zAx|=MoZO`gO+!3cGx*me
zY_!Mygk+o##Lo-OggV)S;|iZ6zExflCe6x;RPvqryZ6KG?y1*u-d^cxgP-Jrtn5Ht
zopnk<pUQqchXqC!yyB{=i7l3eV{<ttL)v?8&nl>k7X5Qo_FgahnQAZgdI|e-&wKV}
zZem~zl2+>XM>~cskyk@w?*sBbA+~16kY!5LIUOJ0LnDLtGWxd^x9xDbUM2Cdu&n8J
z*)R_(w||{71QPS|_0jrY;Guk1#smVQ4cc_$PHy1Q?AP_b5=5uZRnYsh`=gkdhi+|f
z-((rZOI4ryAM0Fw?r3@gHvFF6{j9`~X|30?Nl)3+v1Zbmv15AWdf@F0=6d;Kq&~h=
z-{(FCxOVFM++n0ZRl)FhU=SUK%wo4J7AhYU=VbodDjC}{sbONBR~pPOe`$R;5@PGG
z6W7<iM}4~8Ki0vSfm)umpZ6l~TI0p1Bqx2E%hd2YCxGUecLGn=*ZxOV*n3dL(E46N
z7YP0*ngYrmcVjhWXR<$Er6AL~{A|`Kd=I*NY!UZuR-%A|)@bfubXa<>b7?r0sn3av
zj-%uoaa3jd58!H$;09J&d9;{EGBP5jO)gb$Q~ZiijL?{ar`&!6y{+<*`6E6jQ!ri5
zAE?XCT?a%yKW9h1VSo+Ip}QrY8sG)ijEO@7HD?V-_Fu@wU(xiUEDsZzI0G}^zzz!y
znS5td>v&svD0J5x)pCT#sN=C#QM>J$P+5`eICm!|d3KmqXxzx$c;(zoP53OwXd(l?
zTXGlPFp>h7MM`BjDsWQts9Xac%)N>3$g6W{#Q)HUW`%XT?<179s)Bs{8atCo$qvN(
zkmdnRi)8wI{pm>cYI(+cW^}u^$do-$NdLIOm*>rvKhgA>aU7Ug!YtW~8snP|SeCn`
zV2Z}bg-_nd9txlD^Z62=SNSCJ2I&7TRZ=>jtgN)yKAPLJ4Us6CPim3p^&(#1Q~Ub-
z+HB<$by@G)abe}W4Q0qz<7OrfTUu=5FrPnWqTTurvBB@72`Dd?6I&++If!&ib6L}3
zvF^&JJnL*HBh@%3=6%t}D|nH)8eG}a88Q6~`iDFw980==I?AoyT|i?}XcSXKd)ac#
zitMwDZnXhNy*tu_3E#dv(=2MMy9!kI)Me+_ZJ9HB%jA~5`98O$obU4p3UX-JG3cSg
zc|&2V+f1WsdbQPk4Hd`wRaT*IxQH!tHbIZ@11-B<*Fv)kJf^iK5$!LyOaGq7@Z}ta
zX<$gFYp6woJ2eJzLk{8uL3EA>VygQ{4B|XN%vQZb$&|>h7&m~y@)W)#NJn;g<{hDj
za+Z#qQ{1n6jF#pqnN*SU$`_D&`O~@MKW46TtOB{;f7X0kFOJ;qT0R+^?1;&<jzi6r
z3H)tzxy7cA-Fw&_BoDg`eLVx*MzflKbBnb`<||U3b?Z1J0T%9?MG!naZs9jXUDb(Q
z^J^V_P#(ol$#8dM3-eoJcekBxp6c&a#@C}8NoFAmmQRG`&HFbklU(ijq!5M86oOi^
zc*V;0Nyf`(nYl1zv9gW#16<Ui_8#6?&Af$T$>7=}OkKjX_K66S?NAULFWtCkYS@;U
z6ELj=lbvK(>DEL;`VYXAt!+M_X`9g87SL$f-8S!P7u2WIqpbN)3usn=#zc69YmLy%
z1dZ1m4@PY|RU~Sy%|BicJtj6N?ax=b{RXhsyM19Zg6kb3T;nfH3q|fW7e$%&0Ny(9
zU;WaKI*5GCGk@ocC0y1{)qU<T>C?hzW{dc(8QCb?@v`pTrDr<RviX0+EPKXLA>Z|G
zcq8{r1Ciz3nt#?7^7g$M;Ig+`p%3@v9$aO)PRK(vH1FBeFTNhMRzNg#TdHw>y0OjF
z=wmztMRv3wu)=m-30U0aPx^P2*=X`M#Xs<iH_v~|FW#ijO-w<rtzsnH$mhXZ*-Pj1
zD?YFAd6Q2W@9*L7F#guxRFjy=XA-}U;P)~7z3^s!^J(UHV(9<fKh*ZnvVnW-Sst<t
z8Z>z5UbeSAbm)-1hYqc*+NY|jYGDs$KFeos$_eQSx6~x|rF{LJ$LH64;sb!$J2Q)v
zzfCSKZk<r1|54M4YvA(gpGREQ@^IQB4VSx5t?@eMGzlJ2|8i!BKcc}kZdhEK@UL*z
zjxO2ky?IyC;yG{L2l+wgC#FTZZj<XpNIQm^H?NN5qmsULROHQDw{4fOa%lZ--R99U
zQfq}-hUF}M8Rs^d`C9as#8p20obBAVsa*BweLSkinp9&~n)smU+BK+#6`W5&i<(Z@
z8oJ<C_eL~SUzSJk<A7jQs&Tby#|pOX#k<ykU`tRcTij0~1P9=P!{Yf@$t*?K;M`bs
zP1{H?r`wB{<kt*sKCz8KN;dD6WHBKgJ#YoKOR9Y}MuR)|U>%m?fKr9KfR3DM-@?<m
zvv=&=$t^k6UM;jnt+OAn*|T{0o?ed7L0r~v)L9Sn6pKr590bru0s4<&h|V;-eJEY8
zf6Ht7$J|#FbI=NHm!Y<qPZ2|epDkmV3mu*qo=8kcu%^*kv7x;WYG{02W@2fQiH@|M
zGI_}!;<L^GmZMnj7uT+Z)3GWLKG5zQoV4;-L1TZ;j)T-#v2!5cXb*WH(TCnq03f05
zw(^P7(M{PJAF#}H97}c&R`<3<WqT)XKgBqx1vpd<aBK}Ywt5^`cbl^#Ez1lKu_ZuA
zDZ(NA?EQr@oa_{PM113>tU^>BF3K1!<<Ayf*Ao~@1q@mhcsId9s0ufiTv5EyQ0wZb
zb^5tZKa;c9QGqS2hvZtN5D6>ELedrJ>+(ptFr0*BjYqNuB=_c!OoWvey1lQlasOo3
z=@YmaZbPn!cYCBn7FUXq>Gmx=sdo=!*M^zj+f1qCXSRtq4em1$tR#4XCR;gSVZ4nC
z3pCoSSwyWi8tYc$O<g1-t3ow2%cjk6CtsPIy)scCBP$AIWJPlJ3i$jpa_+v3X=!n2
zc|fgICgg-;4?gy*ekNxx1INvPU@x|>Q>E4A{%Bp!A<pUa8msUAmm6<V?aO%B(W!4t
zgjJRyEkJi2dC(Po?#pO6yg4n~Z?3d#?mT04>t)O*Mo3GY_lVb0?Tg5o>Rik>UIk>C
zitX9HLTKG7%;2T3+PCX%T9DW`%LLSs)-$(?am|W6kRn+n8Y$HO{8@y00U)W)h05Hn
zv_Ve7AjVU{h-*E{6ZfC1OdvkvR$Xn08SWc1m1w;P2UMd8fmmWReVe8>nz})VoTL{C
zQ%71q-9wO*YTu>;%|T{?vUH^Nz?~aNT?wg~w^{2>r`z;m2IOL-D%ohs9wpDS<TNGE
zwB!;cPa?TXcTk6ZH*{zPezapWOVzsUa;0h)BWl(UXLxy75<oO=AP-A$OG(aNtbmUa
zTy^N$MLNbU-J~8}w<tM#5mNFQGJcSlFARtm8sfTzxFi;d`GNo<^AqwGq-y8mrkH5C
z&KJkr7UjgUW$T6M&Ni{$&AHSX2}9D@bu-gPoWiUzuF1VJ_Fbq~=@vDJJ1_Uj*g1|@
znJ-&)gHAtYmu}h?h->rox20^yG&{;ydWL7;oB%b)plau&Y+{#OJ8LInQ_GlmMFx`P
zKzwqoB9C4YDq<upmms#!w2Cary|NZh^U9;43`PAH&G}|#_|dAD(ZTSew2@+|lpV#(
zvg@nnn*jlUx5U7eHt<fRQk^&Pom{JLns^V8=9J0F9)}9{0|uC6c87wM_L!7PnKx~A
zjAf6?ZHhrFZP00@QZ~~~uAQl;E$mN+W;xOFBL@={Nk_!bh#^thBT*`4{<j)}r$;c!
zwMr#gC%OG0fd!0@;x}vDf5-gd@e58{PdWx=#nMIlG~@ra!k0HbNndkU7=laO{a0Gz
z6c!i(Zg6LgvUW_hZ>3B6j$R`y9cevqGq58~(`*2X#*6WmYmm=nZ-)3cohR{z_@{?O
za)Ii6lPQ$+@2^mg=$}bar%(Fy(QXf`63g`*YnSR7V~DE|mM}zBlU-v(1ry3XcQ(aD
zCzqgIwDql2TW=wmXgQy~nD$X3-2L!yQGj0vNJkjbpTnMj^vSj4yvH+v<3is1=_N3k
z?MXPP>^1r0;-xA<I{V_CDoWpq0qD<fwem96K8<H;GyS!;w3PR_K)+WTQx1qoiU_|`
ze35pVV;#a|yFf1MK^EjvX+zwpRH}0_--U8HB?hguLEG|jDlO>bT7BzodXvjCl%RP`
z63!x+IqfwDr*Hbra%A;`d+bC21A$8Wnk$uRKb7yI9y>k;uC%X@QmIaXC)etmlK;Y+
ze3wCU`f$e06-}cw7{2x+wFhqRvuN~G=N!JhB8Ag>#28)y!|UCBHhHJvHuID*I9<kL
z1~&b4n^ud=P0HLURZFfNOr{ZeJ##nO>y0Fpv5z-o)KB+c_GTSPMt8o+*yA(mnLEi|
zcac=a?LMP^x=VRuePz<m(cBeMOGPSz=FeH<C&7!rT%~<`DwRr);Tz^!?ipUAjE#XS
zZQ$)nrOX#KxmKAHEuZyG>IbEP<h{IkaMMX*YsU{Gw%!1-=up0M71Sft458Fe7H6#$
zAZ%U3Q!3fHg~ymL`srF9jVd{vNl5k>kWUoyV*~P;0C7}-Zw3m!jUjX3Ot7NL0_1dq
zoFT}x(zNa-6_ifffU*D;VwvB3400wc*3y4#b#lTY5{cHmI&8}Ipnj#(>x}N#d10pT
zQR&V#!sM2(iE6S6{2aDvS1@uUKtJ6NLIGc;fDi5nN5z=0v}e9jsrHe47j=YDF>s{~
zyi=)Er@)hI^-V{xMVk*&5hH*LLZY<Cq*SW2n(smtF+2vXv_YqpO4<3T<XYwVkfEz8
zhD2$PM5&bd080&4L@>#<N+npc?_2^)O@r6a*6zocGK^#gU>1wx?sIkd@!~K5G{!8m
zMr(|{`5te;WKFkrN<PQ`Aaiay_J&8f$WTs?0c-|9C>I#Yvtn;9G?Z<I^7|L$QJx_x
z_rKUs9+KpGgO&sRHdL?sg|gV#!`ermTgA`J=TK5%h`O4>f?ikfOW7>5%-(21Fh6Re
zjTYzrSg+!2aqbvq=9%xKl5=84M(f?m_-^7R%jnM>G`Me1&1L)_Cc~MVl`&`%AO66~
zC+`GVOO@>@8YxUAmVHk$kM^vgMHomV`FG++C)QYf9_DfT3Lc{ujW0uu(6UtfN*;FD
zH@e^kW#~u?&`q>F%Po)4PGuOS8|i`D{!_7|Jae{4T|eM`>j<?lC)DxfhFl$oC}Ua~
zLmdgDq)rjnmgSMeN&1xbQmIrbo#4AjTb9MZl{Rp5R!_AHJh@ii8Z52(G+3rtiP=e1
zVk4qTqo*Du*Xo<DIu{h7)iG}^TYhN+ldm7R&{dVTB0H5zb?Wq>DA!*-Pp-98%W=&k
zo2J<O@4Hc>jfbVF&WYl5yV9lsC&B*A^&dK1_kul8ptMoYu2ibs@m-{)<PRUfmG%TH
zmFg6Da;?7YI{0Xc)h=gw3)~#dvdnuvxmJ&1(Ht-ow;?Q=U~4CEs2i|Qpwd=gTB%fe
z8{guP{_1&ht)<}5*ruDrq36C6ap)xD(5d23r_!c$4n_zwM9$x(i3$v^tsoBsC~X9E
zDwXQo%y*$S-4cUV+LNnPDlO>bT74H9Tyolv8(jLGT&wRy%iX!oAErlsWl4)daAzYx
zfjFhDID49Em*>B@qrZBdTx+S8G0n#{EfaTs{7}T5F~*&-;!av=>+&T(A$z27=1|&U
zdG&DzKdVs-wmAD3Sk#s8WTs!-knzsg6(dz?BQ>p5D!rQTqRzM`2ClS$+bKHMP5GT%
ztM9_jxQZtQoly^xYxRw!tpmmGJENBAVCG8T0yCAiB0H5zb*|uB%+y~!Pp-98D@v`<
zSohsKYM$jl2aHO4j7p_Cm+>u(`s*=Ts%50qohB$VrAyrbtJFwx^yza~Ah6jHekL}Z
zxAkttxsbwyMsFudr<#hH^FEX5r4$v&QQF99S1Q%MnD3&#z9a^&w5MJv*0K0buGKf3
zt;KM3hcE!i$7zX_auHJsI@BUE1uB&GXq8HJF5tVcLoJL!D{aterBZ1@C)es5BJSl)
zvHZnn*Yg1j#VYL)DV0jM@vXMdU%@2TDwSwCgPo}@>MCvDRx2<*j<T+Dl)8$oeCapi
z-ZX2gGiZU(RzF=yYvjfzg2N*wMh^HZ+x*4qG6LqjPg~82ND)~|8@ZNBwco+-qPCh9
z16SI>JC#ax3Ou=1-vxTPg$D(CSr3wH^$mr;gU&qtyN<0l0T$S)v=x|EDwS^HyQn+g
z5Cd1*S4XK-yTFrc^_^%@_;0w9n~7Am?foHy%p_kRL}^cmQmmTrT|~%?7`W1&5T#P>
z0%u`GPYVgrY_qK$&=2Cs#pDZwDD4SRDwVG1yNHl!F>s|lAxfp%1)f~1?*yCmF^*t!
z*pcIHHvZoal!S7G3FXL~Q0g~AImLwXdp{PGS0Eo{lI(_K(W;}~`ytlT6p9b^QQFr>
zsZ_d#@1pulj)5!f>!TD_CEv-l`i75dc$3#tCm2h+c&1ZUXyJ)Kg<_TVc$8xOfbT5f
zG9@AfI%Rw;lhT%{Qz=#v_+}MBPg_3GJgCWucMpFn;$5}zZn$`d-X&xNDJGRQ@NTNR
z(H0dv?_OPjwQ!m2sSi?aCs9nGUTIH=QmM`{d>1OWu`y_+4LYq9(|Nv`pX+I5+gjcf
z$zB(aCd}bWOgjp&P^{8CW|vN>RC*-eFwJz4nD(yitC49`ER)if$(}Mn<u@}<J%wp|
zHT8*UcYQNrT7@yKN=(!7<xc%(#bdmUNvGOe-7{^)4`A96P?m4--L3MDh*6@nr$nh#
zdo|yPnzi{1U)$j^aHS2rQz<66d^2U$)5^9Lyva4!afYLdN8(r&5P@S#dmKuoI?MTv
z8VZI9x*`Uxv_YqpN~HyzT&r&l80AfgYhl%=mPD*7Ggg(0RW@MgH)3{@_01v3ROp*?
zzaJkkc2&4#6c7kj+LNFZvk;ILb;m>uTxkPuS1Q#maONm{7urw#LKC0N=s|L=z7s9y
zxX-av!dk8BSfM(8?i*1ZckB??5`g(Wq~A!z80$kvBLbn0-(;F;?U5)Eul8yhE<8sD
zJbi|zpKmW#`i)qP0#Chr75)S~jo=Z8oC8iHH}<D@0JZ)0In*_}+%@l!cxCJUxJeSM
zaw4;|#(wWi(&f)M1s6+v9VS&SIFvq~&v$9%z5A%s=N#bNBx0}>dBAlvF0|<3{X;aK
z+X0<E1-obKSVfMsBDHl)K;Kv3mF}YG8(x|Isr8Kh$P73@(68<M8{7ZSYMaZBTyQzW
z0$q;-&`$Kd_x4ORF5p~6vU@n5#4Y;}C#SsSOunmHZp!>Ol{aX!EcP*!XYPb`&rW2w
zoxA%)14Rt663pQZoY`9p(DDowh_Vc!E>xyF6feS_@f&5`whP}+h-6?b7hC+0sBE0m
z)6#rY6}#?m8#T@ncd%b_NS4g67~nbPntXK+qS<ll+a8tkjPS;-_<r@=j}xNE1bm3!
zrt8nl3-!`d$bfUA`_>}5eI6Q&V4c|sc}Bb+Z?}ZX-Jj>}mJWjK+5K%QVV?rRheCK}
zu&B=oME@vmK4&bIS8lOf1R(D$Ftu`CQiE>YCPFQYT`G^u&T{@(WoN3g3q^Q;<_3dO
zlV4|*U2K)jG}?$Q#sZ9te1*r2{h2fLSo|^+U-c-C&Y?&e3RY66O=hSbM^v3vlI*YF
zCH_j0*HGvQsX7JQYpR^LO%2hw5uec|R)h97)gbZ=jyytL3q3dUS5}hW2V3%;v9t20
zDwF-E-F-@~6IzMH{eQuG8M~vvr7mS%iFWthA~PTCay2lSilW1W0J5$Rm65p?hz$d6
z=~pxtk*M>JnNJ9$wqNcv63dhP&mg6T^E1<pqy-RToURJAMCO;glB4wdDU-3YeDEG~
z$U6D1!vo_>S(3zG!HUgQLFKP13v?<ru7Y5#<8fZ8e3+(~zZ+?uA03b7CNl|??>!i_
zl5K8GlQiksvk59|tX;>Y6Y|FBr<aZNa8Y-Dg@(`te?aWPVOeP&S1Qfp%05i<bnT*f
zx`>}38a_bttO?bLX`VG)BMK4O-D{rJ1)68IIkgsQo(4KVL64rO9#JS88S6Zu@7nq8
zWf}tv%AyvZT6ynRW5dMz#Fd)kS$=n<TIPhvE1VqA?YQNY^Uf4nZkNDM{{ecDS|hK6
zW4dhR|3;Us3havMGQx(+!-h+t;dLIr4FhNHWLVfZk-MZrM$cyrJ-V8C1$@qY4;hzo
zF|rC|NJ^H=mB;0=4i{i-aOtQ1sk-Gs%tV&NhapX;ZOP05W&b3OUS!REW)598Rkt+c
z6=l!b*rR)@mr6-iiZaP`L|ROgMOx$Hn2a3YTOw9JF@v+rTvi~OMVcL}<wj`lDAG~8
z*guKz+fe?RXiGINiiUE~;Xy*sHfdH7Y^)G6Xq_k;`m;KXarjPj@Q}m|o-ht_Z-qLd
zpmH7TY@buA`q>0K0?K(pJ||24$~n^K^a}kBp3!|OA`J*|_6~-_ywsl7I=o1(0hLc+
zwk`%Wj)lEK>5r3ggC}J~7zH>-A;l#HX^JaSoHD)^u3OAW6Fyf(e=mssp2pt|U$04Y
z-dB@2@f-Nm@^>7cyZB7y^BF#`@qY1=nnYsIhyN>yf%xE7u?GX>X&d`JsC?lva68H<
z;cqjaxqKexlPHW+^8fKy3E@o$aYCG}fg!$05vDTykB|K(yx}wBTQ!M)@)?GSGl0+0
zd?xVuBp><pnm_N@=7jt0nOfK@L(38fQHNV}!udxFF?E9y;^frbp;^?o{n!)^)*ucz
zl_qEJ7~8Tp-zT(;=KJK9@!4~O8}Lu=l|7BKb+@9V;AyK8Dln$AN2Cc#>^{v_tu{vW
z_@O157<gaQ%va3b&W<Nm49BW^-BG+`A8C|K`RM_vou09HCcW;_ughBZhmkt~$XV-F
zUw+lQK5f^UuX$m}XX8f=9>wlZGKT8v(AL@N{Xy8xe|Cq3qEwyttel6%L~q=IfwlTU
zntfo?Q6g{cm!mpw=LU0b38Qj7ZlfwUyLpeMu>$#e0NIw};xwYO3&iSwY4&1xcdCF|
z1JD-2A6sByfaVC#$rLqFAX5W~f_Zr7;vRRoKq9aG2h^CXo8Kc!L!%a-Qp85~dOP|0
z@#qB3ckOZec-odT{##YAK~0lY*k967z09Rs{@0D`%pKbO;G24*$#{=Dn9})cv!(%%
zN9kF4&YLU!P*09}GV(g_+xVOF`F`|yj=#_Ic_aE<N#S4Nv%9~$@lW^hKDn8(vTc35
z-IAJ2_3fg62pytktgf6l4`>C~>2bHv{%*qQe(CCRAwj&m-$O0J6d<`WTB8Am^@#77
zVcq)>{3&twjE_1}yvcuuL}rE?Zugl05O45R0(hI2X)be<13<j7|4RVB7r+2_WB`aa
z^(_MUnE(d5JpzDlo^>Wu4FXssfIZw_#zjP8+ThB*hV7{yHx_{GZOwbS4dJc#Q(t9`
zIaF^iZZ3D<3vU^&SNaHAJ+ALQ-k#n($aRFb%TmOeQ=B<4|6XrLG!J$+hPO);rmS{}
zVP4JKAST;7yqJs(y+4bj70As?{y`)+cQ30+EameQpV#;dpb^gEGlS14K6mk1!e=#~
z#Nd*_rGp0yE*m^}@W8=)4Bm5a`QSlu;qm$~bb6hajt(T|jt>Uk_O~Lch$1hac=L#7
zQzzO<kEs;XCwT7p)u|_x&AQ$_M6KL0XZ8-(efd7Kvh6-{le)O&;7o?3?a8R0G`PoL
zJUvQX_ch)W>0NEayp5=0;g1fQ_MCg7-r0izsDlt%ws?()!tpI|WRFE_OjAc55kO5^
zwYJu{eJWt}?loG)7n}WTQHR05ji`4eWUVKuRVLz=yI0Fp|7x1F&mF!vS})O2fm10F
z#jjQzrFw~)zLam)eQi}mQ0!nuP<~~_H;nObhP3`y$q|~yZZz3(R^`0wWlJ~iU~ahJ
z2X>zD4*tYWDa_7QBJ(MM;sE$8iiky}!%$_@#eoCBYr|4};5+=k5!geT%bS`6^7i})
zBtCML0^*%5R=XntZDBqr6|&m>n4(|@1Cc7&aI7kbAzYr>fW2t0>rZv(RIvgZj%umd
z^)WGJMwnxw7l-e|+DIJcfF@}7UqsD&1J8npl=^97o@-KFmsHL>LNFG-Wrye5W^t|9
zD2s0Xy!4RJE<VasAsD(mToL-}fdVu+{hM@S5g;<N+&wqXWXAYLoFJ!wxsn+Z^m<$@
zyqsjd1A+_}a9WEEr`N<=tO+F6Vm9UzWnJQNYiGR0Y6HmTRO1$%7Z*r9Ad(G5Kx+XY
zuqm2dHxJN@e=ks*`KT_OPah+atj+cnHH9{hw@=RXqU=w;y@V7Szk?)5<Sqgy6*#fE
zvZ+P#^xZE-71+oD52J{fan|W>{93MYA5=d*qIvJ8Hf3oES-N!liN%vEca^FHz3R^F
zwMCQ}vMM&zy^WK-q^LEl(ddRZf>s!~0|?JoFJR~9XviMwYj_><FDT+<MMCjVMQEx>
z50@=x?B?@XJ_qr+0*U(HoHs7{pp(d@0~VeNp3}cqllU~Bd-#m}KJj7sdj)^n_zdTL
zKYu@|^3d!5zy5J>t{}fmd&Y?PAb~!b+p`H#@TV``jy9def7`b?%Pz7wDw)sj8sePZ
z-Fj+A?Qleq=){dxD9r`+ZWFKw7@-s0@$_J%1V4ubW-+}0YPg>HA|SqbEh^WfSxktw
zOp<i47`5diBz)ttPB6L=lc86~#%GdQ=X<B~H#*R?zV=@%9=(Mf!zJnd+%Zwp?A$Ri
z_a)tS_ISq6n7z~<FT1DZ^X>+pxJft{BIpo!R`Xu&p%X<mvxPPePU1VzK7x5FHFNIY
zbXFE06;l+CW1e!Ra+AA;r}nzyt8~*t!EkkiA$NA$5(cvzgFiD3g4`2hjf`2U$xvT9
zSBJPGL*5qfv)#<M{1+<tOXuF|ZZ{e>;yI@B)A{h9FI(pZqMahLhl6U{3BDrce(zoO
zqZr^qbdV@{77n|Ua+DB%f$jhw&Tp=8-wfGj8YNAh5+4mz-1s{Ma`q|;LyHG5+aWaW
zIycQz0>3bWp`^l14XCCYsu_Gok*S4fk-$EYoIN~2fH8~f^_xgMu4ZYCrY*@H9)G(k
zdRuF6-zt%;bW;(IC3Uk;#j<aqnzA?}g*RZ0YMs>4I2<v3n^vi!HK#$+RHv&9B(Z7z
zbhA)F@M1sw{rPD_`~F|_a{DandpXHeFh}HebCBE3lG`vajjr2FBnqRf{R%d9a?*|n
z7Dwx58SCK6d7aoA+_=$E_PgZ-`tPXt-3tD&G?J=YY$vRVUh~FW7-&KHd&KmpzmCAZ
zq&odBiOnR&{u~WR1;!#kJ|w<go&pp>0c;v<PG7WHm+O|nqu1wH-mUKLSl%rZ!a%gu
zy$h5=3|P^de0#5P%R=70$jcQ4$=9kX+r}W{YP1l~WoN{>g|ehLH&prMufrv#x^{=w
z&2#*yVR463=7H}EnF8l&o^_(YjYd!yg^kYpu|EQjSx6a+!?D3!XMR}pUJjw^)`C@@
z%GK^Y`k3XshMZY{qeuzfvApMee++Z2-XET8U6uxhr_Hgb-VOH14b5G2#28Sk#gy%L
z*CG7b69Q$s-uaT8y=r3MNtR}m7Mz9o=6=L*j7(gjaMIlz!Ph~)3c@X%9p~a>QI7M-
z!I>1*%?<mf4TY>cDqdB(eUWO!^+c{B)c96N%^t?mX!6yH<U19u!_(#)G}XQI56f!x
z`4NO$*`;hIM)u=NcSX%oLo@gz5y%Mbq2CnMX3Sdz!$Px^iz_Oq1T1?r^<KyLz9?WB
zZ&)Vs?J3o7nrIeS8r%gjEKfrV0TTWN?@vcW`i13!faN5^a;mWSVA7o45(Y`{i*#A5
z%^Z*6EyFONX@@XW1Po&g!&t+hG&I~0F#LDGa0VE}dVhVKOr0B8D^$pvB?zv5Z?fO5
z6&-ceuHMour|Wqe`iYigky9sX`duGAE_;w!A!zcMD#<N`Pl0EP=s(%X9gWpfHQG$)
zeZ9NMzh`k*+JBnzu*&N`4|Rk(H_Yu*1gQ%-4huA&Crn%pUG2K)Zgl;FNH?ha*8q!t
zi<Np1u%hm-K(edxHWZiZ_q9;ZUy9@YquE|S|45C4F@DP3{@DheWuE5CGieSfRsI}b
zaEsDE@M&Yvah7gj-?)O<Nl1OYTO$tp$aS-`lZ?_5qIwvmOZ~f4?NagNBwy2|?(=A+
zRP7RwH)!6`!P)U6A~Wyw?5U!p^>9`HDf$W3-@l`_I+%VJ<V(w~(=^{@b&2e}vwv8V
zc#hA@KdMRW;Byh5_!QdaYhz_?zjkM&d~%j>!NhlxO?=O4X=Kv-34bk9M%N`IXICc(
zCRJOJJhiliTcs+Jrw!m7MPtQ=QpOYA^{ZDUt%G>Ap#())Y?NnKm{zUMY1QvV4Rk-x
zJ8G-eCrT6%s@MI5uJ4soE<T%&q!r34u;Vk0WZz|!M5_+lCGJo@3f-|$(TahpiUp<i
zk?6Tj-|WUxe0?m@#)>C`WhLn;rHqrgh1Y0y$CR$*w&OSeLzP}OL%sjRXBz0>&h4a_
zdPN7)yF-y#p7y#FKyV;hD?L9vzD0ShiEP7ZRB^b+{hF^(uuWmuFXTBxdBU0~onxOO
zeufp>+mJtH{H(@g!X~QUyzzOHD|R;c@iYG;KJ$;w|A~LV{2vg-)23eYEZI+RM=m+%
z+al{S!@jalokjO@<Pe#?J_9y~(MAS(e{MVd9zvkMRYdeXjc;+Ih^%Ff_@Vhs15{I_
zG=L(h)%7GZpWxmg93Vzi&U@BOksg*Hn!0QWVmyCXiP@xS+gfbXq}IH{v`yM$BizVr
zB^!${TLksr0cv%saZQ@|vx54zpnfW-0ZrQkb#s7P$>n^yTvSlA1hqg=Wli0JIzK>h
z7=4AmwzJ<|D5z_FiB3?52dJeSSx+}EwGzh)YNCg-CFPyBN7OH7<I3OI$^GL%Y19&$
zmjeLaD2sG;p-4InHJ^Eh!I#nL?c{3%n2}^&=cl!R;zacoO;+!z?VDfwFCzB*%g5zm
zh2o>Y<M9DgH+!be=MT++j@y|zhL=>gUldFa6wJp(#oq{uebEk7nV|M)N@!F&B|yzd
zHMXT2=U8<o3F>7QAn>^@7gSXQ<xl(CO<q0<o^g7pz<=z)s|5b)ZJs-JEI4Izjp*(^
zapBMOk&G5-z&>2yKMmkb)FEZJ2}RfX30(Gira|E4O(O-K4B(mw_!GcsJFsiSv<qB*
zLs%hW1U@Z*Uu@u-L-?!xtVu2u_?z?sh&ff@hX?R_1DEZdHjC0YbELr63B0^%qQL*v
z8dY_&flm>5yV6EXzZ$&LgHI9oh5#-z#-Hy@r<FEho)P%9o|uaTzBquNYT&YX(smTn
zi21s}6|s#bpCRzi1aKKADT~UKwj+i{%=H2<7x>;yO#(kXfFEVxV}w1ev=K92;4kJ!
zk>F~PZr`l&)Qw@#@tacpX1}Pd=6}I#7bfc70yv5iWTHNT#AVXpLhSBP(NDHSY#V7s
zkK)@~B^wR*3>-pG4p>%tZ-ceF0oMERK64%D{1B82L8Q{3g<?)L?%6a)MNAJx47Vai
z@SV1^bXL17FetJ&!#In>Gd93h8Emy+JC!y*pCH)Uf&$ZaTB5-niB1SiI3F;PkwhV)
z@j15aLwz0waxvj22qkm0ot5pMq!GNzbRBihRHnmo1C{xP_}xg1t}l*%%2ehU{vgS=
zwRF#|5!1?z$_i0w_OyOuPp>xK)xd>d8?I(lv1M(TGG9zNC!k0ein1IE{RYKKLs1e#
z(F%&JqQ;|wwzCeBe7)9(iYdQ+az`y8+1jVaNc`I^5s5g|Ab~sh_9W^z_?H|02jEm7
zaTxez?bV@oy~#-+9Zb%p%HX~mgZ#nWAY)dhQSo`o5l^-Il$per=9l;Ap{-(WbUzXy
zvwPob<r0XEuAV0GcPr~!2jXHsxu4ptg0$24MZw1~Q&^+hqeg`)NTvFtU+GSzk%i6f
zHVg-?nu>_?A|ke`(Wt^bXi0f<+lHr~#azKawor`!_017uoMG+ZJ8h@5z)Ji(sus<j
zj-j;|E60+MquX+9R}MRDh5T-H|CmLy;IPefxwPdNw2>{xH-$V~EzdUPX;+$BZ*|RL
zVBJQR*tSlEd7Qsyslj)t?0#9?{c|CVX3!}9h0KMHo%2@LB!0-}w|w5=bMRv|iEH`P
z@>#&AdMz;(`8$!n{L>cvfB}QGNXS1e9I{lXe}mZ1e11($qMgs)kJltl;&U~hukv|{
zj|0axK7af<W$@|c*#-O^4E${VuHbVTX~!qA&xijj`4AA1SyslSSA+x`G<dIyA$#vr
zSyk1s^FP$%aXu5Cpk90u14^R*yWZGUN}Vo`;6CWD*<17BPTt;XJsnlNOpX2H&w25v
zwN-h$h<LF(?<NGW*7^Akio%_SdX>~?B7wh;TrtD+qSnFgON5ld63ZUtW|2Y-4RxQe
zgrf5FlF!ygd(}#|+9^|wRj*pZ*yqlPW2B#ZrPmet=GJXzdx=e@<m=P?w(!8pdH*p?
z?C!U(`30(KkET_s&nuse>Z5ghlR37&UPop#&jF7%S|g~(0+iW+cHd*4TPLXR3Tlt0
zb%Oe@0A)5{?P_GX&wWc!a|Ko2v`J7m1}L)u>sHcB`rIArC08_8G;I~gc>%->z{cft
zy*}3{ka2WVCy*lph*^KN3+vs$S5y=EUM!{K%%AGEqXE3~>T?&9+5D{OT~mZ;bgnsY
zStwv0Yj_vwep#-2`02}rGHuJV#IN^1t&47;g*E?>ddc2st*st-&C~2c@%ag#kHY3Z
z@b_IlyUZ^~F=g$j_@yoVRsYhK{%EvDmzTN9w%62RVQP}>KV{b5Iik7C;;xvV<dv-i
zG2afGdfXEt1|9bubRODrR7YKv`?^mvL9cS}g|zMG_PF=Zs(OA~c&>F)@ch*@agWzO
z``d!4ov>aFQ8>g%k22g>^S%m(Y-?~2{Y}iOW{$|rmUz`cgm;jEp>hYSu-nA026rb9
zB5ihK_If$Q^tlbRr>{bv`#I`aRroVXk}9wr=eM3e6_NTY|NKzFJn7Se8HvDBVmVa-
z_HV5MJ|M}tH{@C<@)w#MXY}nh;8)ST<ed;>`NgfRMKddvdA^m|a&$0CzHz;3&J3wn
zk;kLC;VHhz%vf2t(N6U(0np)~<ZH!^M7F=oN`q%fMh6yb;(UGK{qa|}j^AA*?JHXk
zx5qEM8t7Ko?Mw46%29CQ-OSMy8u>d^xOkdw+qjkO9pP2s&2`gSTciHs!yt<zr=b8*
zVWY!VU#dCcNO$BXrEW5c+Dj=OL<O_QhmFK50_awGy=y7W_bTFR(#0a4WDA?+lGY=O
zn<eb(Jr5*pp>iHkCRrJncka<%qe#Rq@XdD;M=26bsFH1;iHJ3ouGM6%5uoJUw-F()
zLHgZCFnh9RD1U{|e*zc4S1A9Ikl$3O<=4>76)ac9^8X&u3`Wu8<bcAWv3!w-=0$Gm
zZ)(HFBbhF7k<|*3`{Dx{cjWeyn9b&h^)&rxJzLipEO%d|9Hf#S#`KuwTK51}C4&yP
z7}PGNFZQ@99{5h_@9#6leH4++$X86==;bEg8NbGWLlYkotgr9z+=RYMySdSjP=W=m
zOc|6Az?ZSOp$mfQa5F10hX<EvIXlRyJi1SlAI8E4x4P4?)kC*b_a!hJ#<RyKQs+S7
zc6SX5il*svQ<$q{?^8=WZN;?SqV&H|ARy%GXC1C0zjo~^+&^h7%XJ~sMOI(6M|@Pc
zpZ*Qn#ER)AWJ$Q6zT5qqJlv1y&*jVj6N{wV+(Q9V1(>|Y2p9JpY-0i|s;k{1sj%p#
zo~_q;S^o{qW+SO++1Hah3l@%$;9L!mu}~wSEtnpaw$MoR?&3h%RyOphPra|tR`-gT
z8e3>mKY1nQqLV)4>;<gyGgMt=_;FEds%7optrW@IIfUcAES)|TWbRrDXOmNi#_}5$
zZ*pHWL>q<ZC|~W3?jIEB5w+wH?M6Pe449YCR*sJ3*MDuIZcY^|n1#j0uv6l`{-@nF
zGA9|y{wu>e<BueN^k$3Akz3n){gmC?JV^i1tuu0X5Qx~F2(M2l9_tB~>iuxaW^oz!
zjy>;EFQVo<v+)Z2+os=Efh-f+?7r$_mSI3H1CMrwZOwm2jsFC|X*No~agB8$8<n0^
z8pG_hQg6!zp5dug+181)ARM+;b~b<}9NxW64oXp^)(TIKN%b81Z@jjr5i6SbcC7i!
z6k<?pTr$<|<ue44u3KdC{5!<eaEu2B(a!LJLKw86AHmzpgY~j_12bOY@v-*Y<;K5g
zpZE1^eH+SECVPN-sC;f%?R)@z5vh2^#CCIsnkl?ry0)#}%^W0EE`x5JTTJIy+!;(a
zc2&-cy?Gg#HHMb8T<scgV57~?3Rk|q`r8~MqPtahQXlK`xS+z*aJTAKx1P>vHU3ys
z)O0KA{s@B<&#e^Y{!wK`un{>8fT`|+-&+y7_teh9PEj`X%GQ8z8`+@UZ>G6}JiHZk
zsAxwqyo-!u=$s%7(oW;8=xKq}&C*UMsWkQM%LCpva_3{KednsEVm47ATqD~3(5uzQ
zoi@%LqQykQg-B|RtERf&{y|yFLoDxVy0A$N6lk5N!TknS7_&Bsf)SpAP417FHb(!`
zj0x^J&k&ZZcO<(@Td<tvtJ&us(#tB}pa(>L6mByLz_)3iYXbnjL^sAi5_>ZkofF*}
z?+%JRpDL7VeR-hNqQz9VmR=T69v`9X<4wJLF!ttA-muI-$W)1+#==?(!9#O^Op|kG
znt*02)9^(PhQrM;5ZivxP1aGh^xHpYcK^kdZCWHFb!p4M%;REhp<9*vo2T+<R=(|u
zgxf!Dyyl`jJKVRG5rw_$RGrq!u^O{S65nf)R)a4HfU-uo!B9bUxofR%Rl1R3qK_kt
ze*K<0l)D!ImU6t9rYoW#7^m+sfSDe#xm4|PjrQ)oDBnmM<hdH>DBt$F0OXr=R&9U2
zm8;b~>@egVJ<(G?u)6QKv}OOy6C~vbFRXv2C{ZJClOk%|9|+7u&y>x)RMosLkR_vu
z`1lMzYyxt;1yhC9cKESZ({cfx5dgdFU{@EOCqymf$Vs|!F@QEVcFei4xE3-2>UL`}
zdaRPuJUQ7jtm(oQULf|A=<P`FigJ!`@GK`6!(9~B9-?rt!y+?z7{iGUct+iO+|RGn
zz~AGpMrDh0ioQ^w*KO*ZpU7QW*(QUQU9W_l3?WUZXl;M>xHB<_a~f5b3$Em44q0X_
z!_^%pGT02d`(s5c)<%*hVjV+t`HNexaa$NaN^i|x?}0TxK{XAAU>pRwBWlL)Ogemt
zqd8pqj$IRC7}n8c&`R(FcUq71RUU;S0Kb$uZv*nUy1rJsdAP^*qMWkkBGKb&0LTu^
zyhdNtEe4X1r>-ywDP$@9%vJE6OWDgV>`KaaiO-iE;<wt)^FJdWWowVv{iiKgdJN`j
zc4aFJ@vig@C3p#ZA}VTfN%EcA){{e7(MBXodaERK&s-jLntql~g4I4VBEok2HUJSR
z2rEB!zadc~5P&!hmF=_jBu2;o;qHClqb#ny@lCRU6&82VL}HC?l%ObRQD_UIH6W`I
zS=|IzZMBLO=^AWHVHeQyFD%h4>soB#UfWWIsx7^*y~SHAV9^E)Bzj{Tlv>)RZP2Kb
zZd#+}EvrWM_x+xEo@bvYe*m$)pZosMJo`NJ=ggUzGiT16IdjIhW`2%Hh|3J$x4vNI
zvTU`jcIljE-E(6_3h7h$FYw(<@r&Dv6M&YwY8c0wZ%qeChwEacIw6tNoT&awOdj3#
z<10!9Dab>h@vZp}q{mcx=p_^}I^1h=8(Q4vMLl@tN5`Zu2S;mQ8$E^zQWy(48nl*R
z`bxO~3|BfAL>if7wV6a#R-!CZ>QBJMw2a?pH0hmSYlm7#bG6VbON?e_zs$@o3oGhF
zQNlyW-pNT8QxZOX_~g|zq>|f^9(|JjqzQhZlWb1b@lNV9#<QJ%mfQO-_H}!|MQ^py
z&n>apCjA)pw-RY`8Z#dbrA`AGIpc!8*ak<F7A!W72<_Dbr3w6w8!hTG@GHVX3DSZ3
zR=u=3FLcML6g5FK3Ro!hnqK>R)x{JsZHq|ICq6?edXQP&c()n%oBT}nr{DP^<ptTF
zep6mERB1Z)r++03qwoGSllj4Pjbj9#_!~>2$uUbp`P}BV#lPRxC!Y2jP(nc$Vi@Nh
zu%(dkH7O_Q?EC_Av(6-2N;<u2vPM_V*MW*r9FB7J;3N>Hg^p@9<u}aYp$1C*?J(al
z2)a2o_KPfV0_J~CtD=5r0V-YUDacNE=~1VHq*K8Tnc?zKjJ;{i^|{vks&}xjjAHt<
zuu*^Xz)MGo|F6N~<6Sptby1gEf!dR;-vip_ApgFNvy9|~v6ifWhZ)>vMSEG%7F3{D
zm5D@%>$|(Ko@hk<GU`Rld@@l?;!pzQ@do5e?U3PU#<%7qgg}=ymW$UP-5_<v65Vzz
zED!BS5S<`qB1eDq)-WJ)k08KeYFzSs8v#7LqyBBVbPEZaHz;3EuEb96sX3bmbl4NO
znV8Nbh3Do|EIV`|mJtkbxLt6Fe%hW;c*_K$|K{}u`fau&Ytzv>ofm_*F#i~x{|qZX
z=0Z8W*QIJuO<tGSrPfhwuvVpT#-o+8CJRUd_b&BE@EyoLxC^Tb3m+aRQd`j0sGhX@
zPSnOc;j#&6^(8PFzh3keRHxk^3fc||lkria=_8|V1_ZN@^36(i%f#Oe2AWY{0?Kmf
zV)-({;`%D1GN?Iglu^$@G_>^)n$|fTo3r6RuIrDf3<vvth?JML<ah~eq^7~laYi3-
z*gGg=e_Ri6GMn_^$R0Tz8TvcA3>>?nS-*M&B!`-t_tvb}pMBZ6F24-zk@D_20GnFW
zx?BC2piGhh>*zx;;3O5XTvziHv-GM(QDD`UO5!wKuw1Ruw>lVlDx^ABOKqs!f^hvu
z{bdyoS~%TKG*O>pZb-jkMe^K?j<fd9*%05;R03l|Cz7V_`HNwD-w1t7X5XHK@c1RX
zN5$n^GaG|>GvCG2!lkj>Eh8`;==JmT*fnMaO$o^z@$lNAA7k|^{UxNuI`6@{L6Z~c
z3<g_jE=Gx_@r*hEqU$`!!EY;Z;Q%F;$8O?ztOM2Rv6Pe`<oR9FEGj_$8;2NDtVUsN
zhXHw>Nvg17L-!H5c}X5FSiI0e3HCz(k^Zt}{g$iarLoTqfXAh=GbD81s|LopIlMd-
zl~E^PxZuV;9C=Z{#^^Oi(K{GB=J<GJw!IJZ$gsvo6}RWWj;EoCs2$xkUVWCY0nZ~u
zEIC3dBArX!#_sWnV%}njx!Abb(VrNxl>uRILT(Gv7fsqccQh5!k2C)v6NbocueApS
zdZ^mW-0)d3z)nr>Vow8UTl)Nulzxm0Uiy!o!v^1d^wc6xnD~1>VtW5aOg|@{nZqSo
zpUo_16Iu9=S%v04dI`DoaLn@2(nCjfOz@?9<;EQdU?|V{E_1mY-xcP!ZclM2@loId
ze+|#f?{Xg-epY(Vv89i9c~t;YA2=thA3RC-i;*wl%tX<Pcj6~qo<0-W#FYED45TQG
zF-jdzuiAGF232b^KUwY0O%rI3c-MFsKSHWgS)>rL@Rj#v9P?D@_sJ$R1+f!wkM9}i
zqV#Nr)=6l7^c2NwJHdM{u(9cAIj`)4d1VmFKVd`AMeJ9!h64lZPzNAPq`fSNUoYS*
zz8rNwmtV^`OE=^t0$4XkwsTZNj#jT+O?)5#b;EWf5ytY%1EwtwJF$m>M!>Yzp&B?7
zgguxuO^G)H(^sr>Z^5@P_OjRnoRj3Dk!gDNy2>C*aaw~7BhF9aQr1ivjFYh#VOS>p
zS2kvbDxbqvAg*Fv8#r8#Gdo7k^uHqrC18FZrp1-r9y@=Dca`y)Uf!I$;yu>GP0h?@
zm^09WL(!}kpjk~1^ZaHrYpz$NyjMyNPSVA6L^L(ryO3$9McM4f<byWBlwPG?t27eQ
zFA3z??vMsiFoM}|-}8%k&<ygnb!Mlg3hBTO;U`H~zXzZfG46+mV*|tbH_$UR;Fa>I
z;lt@gvrl^9uRmz?304X?mn?k}bK~me+c&dBqj<fe``OJ@OJdW2`-yUVwm@oAtxC<9
z-f`k+34QNG9386D7I5eCZ<`E2+!kar3;lXHg9LhMosVh-dz+>~Pij<RjOf<)n9ay#
zrfV@)V`7md<KlT*59@is<03x-w9T9_D7f-hM`H1Ye~x&_ArcQ;2V;6TR(w8l1bps*
zVxliT9KUa)hY`NF!ehh8z(>Y6WOX~Lc6^T-AHbRGN}P6tR9YEPcU<X;Jbnc(;&ess
z1TjYZHF(cg--@#JOX8WlSYC@67eZX5nUAvhkcFm(nWkuBLu~uR=VL$ai;#(Lpm%LW
zpRHXJU+_0t#dDSZHB(2^vv$M~5PN+P1H7l24yiEeA>T_=Wk?HdJ>&p?`!w{u*(3Ol
zcO9KR9=pOEJ^krp2kbrU{jr_r7HsfEej)WuhU`9AeaU}y|1`N~F<r2CZP-&^1r3Bq
zBnJ8>eTfwUxwP3{$PbN0HpjRPf-~dUo;J2_lA{R^t%;Gm2=13WkfGL2ch_?fAzY3t
zbYn0fR}Nlsu>LXSHK~t{^mF}(_9hFCF9j396qQL<p^!|n(!KWDk=goimN#K%U26mV
zt79*}(gWtvo1E@OR~x#NKg%YDKZh>U8~uwG`a0$!v}cnmiWU|Yh67+8b%3)61Z5~k
zJnFyY1M?Yl)?^atAqXYDC<=O#>3upR2Ok=irEdB^2Cuo&tzHgMOOmlGS#14<o8)y@
znfY~l==>QoKPJh(O(E$)|Kw*<9!@j$Cac_{f7DYQSO2$H>C%T-^PSNq%n#nZ44&0I
z?&ZVh2Rz=w?HJDK5!*3VT=N?W<kKWydwc&A`rDlsJK0!O6s%pn73KD=BJeZD3u>1a
zI~7|XOlI{kg-dA5(ghBxw8+`Q7rkBEYxMR;J)YPUdOQWaiAvIW({wM!jKLK3q^#Tb
zy6epr_PUnO(k;w^xWJtpmK;gpAehM(yH<hs|2m5=?5y-A1!VGWPcknFf}uXmNb;L(
zxTgS;NpE5yrnuf@h4+@5b?-aJlh+K)RY%jW|2jQjq=-y%A&aPVmH{+yr~;QvhqG7*
zkI}=4Gx$Qck+>WCcsZQAkr)Ha!ow_5>JNE@^o0Ql!9<U-q$gSBH4L#ZATaVUr`zfn
zR6u~5fIx<fWU{mwM6GtCWkx2aLp;MNbdFS5kV6v&Va>uQ*q+5cRw27pxV0r90UvO4
z&)QX6(TSi+(g(B^;{vcC!>X`oYOr?&h#dNNs98<DC^pL{O&93{R8j!j!5kNo`jw(N
zISPDhc!)2)+>4X9`|t+9z!4XQ=3$z{(pm(}8jo5s!w_Y9;8oQXC71L)H4<v{9(6G!
zVbp}fyc-Yz0<_Vc0Ci>J7rA1^x+7{2x<F^~=L-;=nCZ@4^W{~inXvU%^rvj1v7z6k
zg7yD`>>ZoaWJoGO-*WNEEQU<f4c~q&<^{H5BIKs=vpqOp2OFF~_xN$O$5$>Jv^~Z{
zg8f+SG2DcG#P)a{0^Gl@J;+~Wdbq`;0l!+L2}-+zaz#ghvM}%TCP@YvRfnS;P`{E4
zdNdh;ID1G2y#^U@G}*|Ymt+9y7$BJaV@~&We)hy6gP+YAn4bZbLv<k?Ed4uBeIA)+
z^r1++ee3fJA?trleMEli*S;qo5uY*t<M_lYj?_LIgv|dZ+vnX&kAzR*zZ9R3$}g`l
zaqZ79z5n-P@`v>2jdnO9f1u_6zluL#<XhsAH9nzcfIb8BA_R{TnFnMvTJxA~e%11g
zH>9?bS!0h8T*RNOa3@A4rtxF%G!HitHJi4^F9HATT^k25Sd-R&Tw*i|)D+wkV0L&$
zt#otp#-ui#8`7@mDW({Oi6Ep#PL)jQVF2AU4NhmQWlT=}spSumH&Onl2P^-&<0=1v
zi;k`QD#KVeeFCZ_x*zUk<}I3x7T5$!nfbxqlG<HmOR2^9aI>k!I6<9(3SHO$Cq~7S
z5hs=ad`a)vnuoSER^({ks?7|BIDrCk#<#t$#b=Rw|21#^?vg@64`qvIeFhTW2muEh
zU3p3Ww;deYYkt6EWw;g@%%V(wY>yxN+5Yk1k03D-Z+d;(M%KO`{35P!q2>fGiKz)M
zsJvJfB$?WaLIESHjFLb@iQdPRT*EO0Bv+xeSOf-|o&X;*jD};*SkP~6n-0+?le#vq
z1Y7WMj0+F&RJB3OgVud4g+fU*WJ;iC5mrw4^iHkvE<A;3ReI4{1v5QUg5E`i2uQor
zzna*PYiMHtp!}M{kx=DKC=Di8xaMvq*@fbbt+TJYezSYdOxFd0%)~u($TgSSpRUC1
zswn{5j0&6v)`uf#iSr5;au_*KR-FQuNKA)Vgh7<w-}ztoMD51$Tu*Bfh7=GsL#jXq
z8=AG9erIAQHw9W8`C8J;Vc?pqDu)mSV>Pb-+R%b>u&9kGlK~i^HCyF0r-Q~jw&{Xh
z$&tx?IR2?!-iXzI19KlRbJH3fxeq*-WL+BgWkG46#Go+`cF#?WVB{BWx%oz`-Owz_
zYs>w~8RbRES>+|+>QGfxWYwV=uDRLIFtN1R#Ky#oa?jiZ_7G6gjPeP|8$3uoe&VUg
z1>X4K!*FKGh-=Fy#os?1^-O)ocMmhCCM{0g^mBi5c%sr9|EAmJt7||bMe=}n@-mM)
z_{%))0D&Jp_~_h>=(*pbdV^{np!r-2ig6#B=7tJHpNzmIc|ZlLlZnl0>uDck!^ucV
zc7Zp$z@J@Eq|TR4@P0|spjwIi?O3t9EbSQRGaD`UsChtvoN*RFos<1WY4#f>*>8+h
zZ%Ma%ZQ@Z&_`2(7C;vLJVd5VrzBKV46SLWUH{NoyZNw%2ntVICt0qsKj0#Ay=aDd*
zeIrMYXyO`IbtIgb;i}3OS7Jn>W+sSm^3HNkbrrBGQVY!DZCqW(lSjqQ|A5-s3sl#c
zA3zWU)Ac0l8&Ne&b1-$fXCXAl970p8+>3|qU|+v@j@8jQe5k)4qv1_c8wDO1I;Bm6
z59?K27R-s38PrTu5v$>2S<rJ7_{6QkZ&VQYM<%?7b68ZTt(5Mu&2B9%N%UaXc1T}Y
zok70iT_rUx^#HE00R~t|rh-}ZGQKe5f}5-ZuLMF|3<i5@ckyr_?6JUHsac1jLa!0K
zsVT`|V*x8kn%d^4|KebzMtd0L`MC&01G~58rEfqP6)c0UYtf!P@!cU>LF(xNEkYhS
zHP{{HRkgY}tdX#bj78s+Y!rMdlgtM*kCK@OGff<)uJmqQx>24-oeY~)fD)@2EG=Pd
zm0R><$)9#`RRdZ482O9TyO^2G#lkEuytv#Qi^Xp__)!@;vlQ<ocsCcV+L(unN1N_I
z7S-5$$*PHshr!*t(wLM=k*fp{iU7fncbw87!>dxi!O%p-Dp)Zr1<IlFG}}+b1s`1>
zUf3>dJqLmL4cWm|ZLpRwF2{NGV7F>40_YmIYQrzKvI*W#jj93Ps~&;zve{nn>!aZh
z2y;lbID$b&5N?;1KYq;lxru^W-f6+ewZ09X*&h|&f+NElZG(5FSwF3IG>P3%39;R9
zyMc}anHg|3)3EA05za5o_WG;|uMB<Azjp`eo3oOEQcyt&^5~O=EEAN#vjTg-R?$YA
z3`!`q_M43IJ?drfAG7=c>04FdICo$6l<RMM{$r;nP)3g4fh)PrsT$WO4P1q+tS+_M
z>k%8iN2V`>KH3d<)>2wvTJRRx;9Y38|6pTMd}Q0l#gRtgmE6b77Izrsmso921g!E;
zwv~T$dO8JdWl@v@<d9m;X&Ph5HW}IBzYBG)*}q4JU#M>TtMqmsa5;RRv%v%9>G7R2
zLKJ4~<dEX)OOI8zF$TQ3@%|kfyd(E#QB9sfDQ|&Mqh-r%Bh_lp+idVYZ{l|>{PrXD
z?N>Dh<pu`jx%w2?%0Kq;fRSf2_52I2YvMMj$z1LI`P}f2(w{iJjQQXifyZqht6Q!1
z`i>3WvGr%6x)g362+X!VwBX%lgLmxpFI4F_HB4jJTks|xC%o?u0<XXZ@5uC)FUuA~
z1!v%c^BS-dH^<XSLSGJQN3)0&YvI4hR^G9Uzt`S4^7xC}$}czR8-0A^KWKWZSN(Pl
zRk(djzKiRxoG#J9e`XH?Z}@S-8$AfTUqaz?JovqfV{2x6+v_|3IN?2KgZEMUzlz(D
z>WtkGeXzBCidq6?353xR>VEyg?aI6Xw<|UOtWvK-GD8k53!T<cYay&!x(KU()W0FQ
zdV-G@K89j>rM}F^GkhH2V>YZ3)Yte(@bM@fq(Gs+D)kF|9(#F^=T#g98S<)FX<RKb
zYi@@}BvBC`CHm9qza#^%8FIyB!Cxw}EBA{alj7_g9jBQ~l`gZE#`qYk*R6Zd!|Epj
zNYr^T%J)mvC{$2y#JD769t2;kEpTwjga`0?9q)#Q=ZcBXV}Sv&Sr%I`u|81as)7Ab
zx41dPajP&-UEmOznY#^&17<vtN)y=i@jV~%f3SDri|T#v2R5-s<J)Yke$4ib@NPRj
zDP@btV=^!)RT|=|Z1Gl1(ecdnxXN&7<jw`$zr;|TP+%yhqGuy`8G|XSooWU9fw#y+
z8faQ`BHQZNk{@_nAmy#&GN?*%pIVlJT9sc6U0+tLcwR&Vs@S=QzhPK{ZCC&kjF9@A
ztn;{1;_@bTbq(w)J*lD;!Bwm01spUbT6;SldtTY-S&?<XH?rv)l|V5<e_N4u1i<Ly
zuhlHwF#3R!>P9ppnj9u(8wf9?5+*#MmFQ%U33lxO@!D_XAo4t=3GqQYM6fzc`Lb5)
zJ65dmB4Xr)=g4x@Sl2R+|D^x0L_!7c%|qOP->?t>2sDS*0Pe!JC)Sm{Q^VdUSw#|k
zw?=E6%oQE_IRg#XzJ3}mfsY+ZJ*%r9=oPiu(p2I>EP|6xsa3NU5$zqU>8;D?UoNGs
z^M)bCLk7B|)!YxW*(rgHbn`#hz|`;3ilS3VXXjP~3P=2~PRGus?(K-;<<cRQ|5<4-
z@Md-uOA09-#>46^q<$-XM(u*^cur8fDHCcx(t)klZn5>+t05;H+(t&AHh#t^Md(%6
zXNx9?kovk=il&V7VY~+;GnCO`E8`osGFI5jV9z*sr>(zHg)`3{lpZwmd1*%(%0KjW
zHCkX|F?EmC>ZcQ#$)*7rkX|DGg`iw7AAEx@Bp~DgrHZ7FjAc|AAAE!MX^b<zf>D$C
z;2Q=}p)>v_MqSGX-)aif>*z9=J(%#LjJlH#zF}Fu#~FVgqt@`jH(U_&m@|GWqqgwD
zx0)fU&Kcjrs75~cRx?!H?u_qXR2v_B!wz}C8Sh$zs9whN4Y$OMamJ5jd>J2ns~M&W
zo$(cnn#>2^YKE)VL4LOS&t=q2eDJNttM)kK>lw9*55ComP>(s|w=ilGAAG}MzdC1p
z3!@tO;9HGP-R_K6jB4kDZ#8}uaK^i$h{`aYZ#5&;7-xJb<BRy<Tg^$T&>26OQ4{#!
zTg}Ppb?h(O>VGYxX7Rzdnj*Ew86RQP96tC~Q>-3y#xG@5ln=huoFe<zHu(23s-6$N
z)r?ZNJM(X1)J8t|R#Tz^&iEEaHS@u@np4#nXMBcHJ$&%3<`b&W8DADdR4E^Pt2s@*
z4h^IYzZs0Wm=C_yl&U?>__>U_i4VTjoUR^o#;;=3Qa<=r^GQ|bj9<^F`}p8n&8O7u
z&iF?ewUH0L)s(4#Gk!axw(`NZnlscGN4%bILh2gL{~js1Yo=@B^Dth-fhVZ?nh}gS
z?*_~cm~X&c&i=HpGFTa>f``?6h?Xqi_Wc;3@E<3C+g^qY<90(;gn6t5ie)gkiG}2M
z=6onS@;#f0Mo85lwVq@|8WFu9PxfM3H{~bUo78$0gFkvg6Q7s;%s$HvLmtI^x_y-|
zKz)UMvNPvrC%$%me7Z(AmrKgy4l0_(uf-S#P%B>MZCGchwR+|@QaR#b*oP_8RvSZJ
zsL4iLw^dr3Q(Z-dw2E!19=$E4)uJ7W9;_khrqD_>+Q!BA_=E^dS75Zp!%6$#yGmb~
z++*(V*b#Q%gZ`nbBDB7h#1RkU%#jI*1~!Zx@yLJQ@#M#j+`4`{a@~XN$OYSFM-Cz-
z%q1^IA7D{~dQ(BAmZPyDxf^?03Yst%Wh%d-|BvUe5eMPVYzDo}WmhJc^f2&_?}>{p
zg6L`6@ddeJ{fpzX5a&+>J(Qs|w4L7bU2wOt=gXJ$Hgj)5x7TI{TJoOZZmG|XF9(CU
z<14_p<14`IJH7&MzU=tw41IQd`^ER!@s)Tr<Q<$SbgQ3fg3eL9Nsn&zWdA6NJ9>P@
zFNvZ)uGr{EBYBP%(reC*WXOE-Rpk{n$!s%|=1P$Av&AjoHIFdH1Z6CVatWn0qr9d<
zDG$xPl`^&cpTIMLIPtmA#Ao~EN5y9&@Da!ceh)gnBd+2A{NKEp%|6l%HWt5x&#Wxt
zPE~7xmO&8M@-PSjt2>RTfuCfE7H{TnNG$=Rra}orGn+}JT9Up>)#bDYu|oB^-$GZT
zrB5Ti80&3Qz%Epy`oyctk=<54{Qt=cR}19%X=ry1Oj5vv>nBwX)X4+{zUCzu-M_}N
z(;=Q3{SRBlSU%h^QJp>vpfL)>Q%9AW_0D1Pdy6d_@I3LQvs}@c7{SS^S=DOs`;uqJ
z<I85c)LqL^JBgU;kDd*fwM%D(=FN0PPt&3CyS*-)bj2=W<*X`o)d!LlGBmJEOoy?o
zCw>=T`xr8P7VyD*1$+!T(e1_cm9722Z#UWbt+yY)MQKeHCE#sjI!$?%m&n?=X>|yD
z2NKHo$_cm5bnPI|!NoS)FVl(VC1#Ag^Jxj(?b;!MVb8q8efbNKk6>5L0u27sOuSp&
zf%gz(=34xs=~8meox5O4)<@h0`z-Pz3QBL2nOO|mJ{a)ss4v)ea(ZPqZgIEfK}Y-%
z=A%{i_Bq0QBy^aYkL0uee1zaZaChJX`yrS$U>bv&BYxGdL`ruY%W$L@{0)mE(@x&G
zJ)zqJ{ato!^?A`*pA`ewr|D?*F=i-Zix?&?9C>-svoyg+P%YFkRa9SnN1%5u$f1A(
z=~i9a^nd4i%jCz|NP``J&p`BAJDF4(^~*q{AhPT4G8FO6p>uJS+G+)Gs7wf{hphk(
zze&~Vek*`kCReHDRsge%4XHb=0A?9qt!}gen56>#zpMaenGsS`tN>(rU=FHVt;Xmu
zbGP>%V+cHC3;_{uaK9_ap5#yO?1PZM(1V<~;5I+3#!2xeXUtEJMLWk|$aed7jhqP^
z>r-oSe=r6unAeGHm)?;2K3q-^wlPBb)0bWP$@Rw^dw&c*K9&pLwZ_N!^4V{EEJ5(m
z#s?L3&<wF-w}^1BQ9f3DD~=7{7oGU77#QECqv1OU{TJU6)a1^U!I?tt?sS{k^tSoW
znqi^8I?b4>zTHkyPfuagYr*K8a;Z}sFy^POQuTAptXg}Pm9wIqAgwfRjyBa+^vPe7
zHDKQZ*qFn4+He=bBebcG%vnrnCc^OvjmpcNq!Zpg+N*wyX#Rd3bm@Dl8TYZAiS8-p
zgkG&K0xZMEjcLA*wAipu-^q`gkpYGoQmQDddG@fYS`E?VpJC0*|MxEhLe-iSbe#ZE
z^jOiWP6d#V`i`t%adfj+-GEpK!F)YW5_aU;<(TNhJVAvkx@}WMu0M<uO{70<U&Q-G
zS*=0VgSPRA^+;Cn-eFk57`YsM<{ZDYn>q5HMXo-m?XS?sxvJ*yHBR&-`&P!9AJuO`
ze0E|Qc1OUg8F3$)GVx>MwvPJ%$C1G^hK`r@F=?Sn{RfZ$0|BiuO$*Z4+r`3H*f8#U
z5Hb>b7Fp0*@iMxrRA~>P9shc)7bdeGIX~88^;gd9V<Fiy=z0u`Dv!dk3Hw594Gs(R
zUxnR_M9&>@3D&Rv$AiDw-{2~}SlJv;{kMF~`cL|2)&F?#x7Yve<Ewx3$E<%e^H1vk
z<H6rv|L)_fzxtT<zxLzQALGw6^H|3pwBv`~l1lCkylGk~LmRRBYuxRFjWXn%6BSID
zUCIYGjYN5lfjJxiUeN%aTN`+@-{^EssCs<%pU)vktwIrtE~J2UacZgP17K5$O&DzZ
z@iU~>eN`|*iYB*CfgI_brfS5-uOXot+&GFU8j`XP&-|!AUA!IU0onA)+p!A|9}U~V
z9kVcn<d0_jf?vGr&QxGMv?r}tw)?gP_u||*Tn0B|qquVjX3J!_nby+SAa0IxvyC^f
z6!1Xdfm+<#Q08(i$6}H@zO;^341gw$KK<Y>UY%>yBG5gxa4FWSD^5s`;IG7E^S1}4
z)?of-6JgN`<8`<&(3Ya`?0^I?mB-!|3^>G2bg@{3>K)}QM9~+;QuHw1o`Ye9@2Pz5
z5$C6$f=GyCfALp6G3emhQN71eJ%}m!>F)#5uJ?EjG5+eM^LI}!(CrH+!q|1z(5IEi
zYY&`7OdCrVgSx?t_9`(X6s}MVqkC+;75LVSVRHq01b9y$;50yq-&K;uCM8U3?=Crv
z!_;tO@l@s5+UHlHYY|#Mb8Pyj2;5sSwiaM8pJ{C<klzpFA^Twe9yYP!?R5yv7>onQ
zVVuK045Qn_pkE(o5|+`dt<@(2Ug1C}Z`z1fa*D+kd}Rs5r`lJuh>gFWA3MoFC;ohe
zfy?RW*D(?emmz-O?|Z6hZ2SduccwlxHvJhZq(X<_yJ=bpaE2?UjbDY1D|!;TWHVor
z-gQmW{EX`4^-6}^VYa7SD@ghAZQ??275(HG%<#JYuGlBk45)6KT&Ezh`aMisxAU#@
z7n0ZSg3WNyJ2hD3i>DAm$9H<0UadHpf(Kd;X#hWi&XNNI+>uAO(Y%@M6C0&Ef)@O{
zO!(;=cz_~Yv=CW)%&Zi3DWIaIad{H6{zS5#iD314X60M@bipu<6FsI4FIKE?eTnNb
zuYFV6Xb;bhHB{}K4+eyRt<Hkdl=Khb30PLC&uYC=AK8rz!OZV_s_;HQpvTrVC_f^q
z7J>ObFpu0Y7wmEsi}*h5rXhYsLboAg8AE=rL)1RFDYOktIcy^XQ#j1I8pAHqJKTu6
z*M+RbNd}JKYCcq(1xbIpX|JG?=ipnyyi9zt{|@te>V`&-SpO9)FZ=bqWp^X>+aY)!
zWW(E3qXJULOU-r-8V~teWB+R;Vf*e)JK7i2LPL*ss41|C<!EK2eM=2?#U7!nn!sy^
zVO8IuF6n?SuF@U93j|!ofbk3nx#9HyP04^XQev#Yk7tp!%IQ$QmC&9veC>CrW`6Wt
zPpdOO3CS2*4|lB@#|jHR=KPI3*0*}+^g+{G>kHJ~VM0NJ|0&qfhe<B>k30!a`c)KW
zw@9<#Glf|mJPsKe6#%>rof%R+=uFI}iGcPab26=A)x&NH#3<)65*)cf^K-u;d_Y|I
z9EdMJQ0R+CK~nPr2PP!z=iCklIXJsrcN2n)O$;XQkmMb;IQWf-ML2%tEeLe%ttfG&
zUp21LX0_U79--Zl+ZX4WbAA|51MR8%b}s<rM6iv(+Ty$OVQwUcu6Qd+xXt&Jdl=a0
zBJq5%>!2-Yj^PXe10JcoeoTcnd<4X<b}$k|7UfL|cPu#<I8x!c=nRzWd$#@tlnW+O
z5bp3jHT~4#yU;8J!H)WAr>1vweuJ#>a!xd1IZy`I6}UnbhYNu@gWxzr{Yl0YBNDZx
zU=F$3hTEl4Slc0sN~QgR?aUTypO;*-U@i)VYIUYJ{afjZNzibkf6x`@0ZivzoMy;%
zOKO*U6r2%7eZFlN1KHwISW98f^uPl~XFif5p3aIiTS3D&Rk-<0R0Sh;Y5%Um8T}!S
zetKQkO{Z?>4;#{62Orp?)Ig*CDwXOAC>m%lMzhGBuh8?-d<m#7lj+^JhGsW86yP9$
zhvID1B5l5R8mYz6)E53=<oUk3Z9pm&{yRLC1GT{ZcmqVB{qR^0nF2nj0tmv?od;3r
zqGTAah$S%uJA~>WA|Y&g-jqPc5=av4WlWu?#$SM*mBd;fIyL=rdJE8G_uBG-U^w3{
z!pv-vNxT`FYm-i1F-hSiD3Q2QGf4sAP1A)~a6***f~K+)h;29wS>&7e5(pA`=OwP4
z=9PA+R%OEPs2eJcUs8{$fZkEq>Td#&5KFoMWN<UM5bW+&zy7|(rG)k7_;0+c+`%8)
z)R;dX#*U4^B&_A0!?82<H>;m5ZWLJs46;qVfTU!Qk#rd8K6IvAD(T?oyG{L2()FY(
z(&r&vZ|v+GJVyVV(NM9%r$slv7fJH&G+Z!1R)$8gP0f)Y%hWN4{{Z`$kk`p;meVk;
zfM<R+^>~`5gQtP~xt}2o&ixLHkW8T#qzy-hkY%ZU8?szT8}cpoH8>){vt&b-WM&+g
zHH*XfP8NskYgbo7@mfEvB>jh6a#K`Ba&npFqX4sj3jN--^;dow$=6cZmHu6B#t{CE
z_0m|bmo}}x+}bp6986zfj3nXeS7Vh1LeM(95hyHv_bjl2I9dQ3Fq>YLSgY%y&#sik
z0@zu{)coiSZ~<4eoI}J=DaS^E+$owwMV*XepR<0a)yYtGgLma8rd6T^l2w(s5d}c7
z6$9v$A@x@EaFjYzm--yXkdcz*VB4=^2PvuJh%2;Yc6PE2^I^OrgNlWd^WBL%%iTEi
z3X_7lmPx_v+OA6QKI6!%oOd-03zC=Ne9Tq;D)k6CDD>d7Avhco>mW>i9m&i5Xavky
zIO8Yk(OUFJ<a>OyY4vCs;Hn`~Yu+{1rDo2fDAA=(`pRLr+-m^u9R)6rDof}r#A4)j
zP63GIZ2yjW65qng)H7S4k$d+sW_%AxBs}#C1|~B)_*DcqkyfD*?Na;k6++{L)J4*#
z7!#CVv#~Q(=X9_Q5v_5g)+~4b?JT!V)Vsc?uJS@>i}MB35IEb99fSDu+#~Q@89N={
zwRg+TUUVdMc2fT;6~hiIT8AZnQSbozg2zU{#k~=Pf@R?JN@>eCv04=}YlUx|lf^iB
zKeJvVNbFBvn!2i}DmB{=H-ydVT!7;CUp0PFgzu@#;1n-9Jb6_Sj4z745GMsdD*>D+
z09tK(1>)H!`5I2f>VGmm;$20?j;G!ak%QV9Ep^Vvf?E6q>2tU6jiX=azntgoDKP5&
zH*|dME{;E}ba#kE`f29%V-XhNXoZXWkba@F^LIsY<;O@*V&X@+;IwGc{7PO1PmfW_
z{MyMfREp88MhGokKe1nr7-Y;xKAqp6oK~5TWY`D<BHdZz4822s`w07g?Z>wN5!ANf
zrhUy}Fh>wpU;COXkjmBvIqqc2v%;fk!BpG%C?rL62KeSlOJMs7w|1+yObWPg)8l&l
z>>&5W?s0PUMhvI)1>5;e5p0!wpCR$MJ+4+hPkLIC?=CQ+4SVft0O%I{eI0)*@OMA{
zTyD2J4}aFb{DR#4P}{|+GAHr^-P)xh2Km;^!+1`m6b2Qg67(gO?xtWe6LC#-9f$*#
zF5Enn;ydL9d8vIyqCgspijy1ozE%>~uPG+aOShWR=UyF9X3DIo^&|d{)QJu4cmix4
ze<`oXOESezEwzMnobM@*E)t2QAWly5V#ZhIO%a@yl-jWJ>%?a9>F3hxYdG~`#Z#5q
z(2G*4g`iV)#2425P^*0trpfWfQlukyc3TO+nKbpMQcPT>M*>=GHRW2IkX2PHss1YO
zmlMpjPflcDTU$9t>72*Z)V}!7&=<O5zHMv5tOfK(5b7}VN)u?g4gASdpt~b<sugE+
z6Z!-7sjrpU_Di~3ecRRt1sJZzy~xT8k@3{{^JSc;rM>HCo@&MEd~4T_=tULl*9ov(
zv3plBz}0ynSaN48-j1<)k0EJXC~MlnOZCeamweVjfa{QWGkBI!TdYM)k|?t<GmyDK
zXTQ~ib2s3a`E)DUvY?eTd3V}stL2gYmAV*}!f=OJIqr`RvC`nj5P&_(58bvyAz?~O
zqL6^7)Vu2-q$N7GfB>2Bu1o*P&RTNg7xO*gH9*%rI6Q8)Qsi?0bZ)i+qJy7;8*ltQ
zr-0+%e_D1t`DqV$%=&LiWc~M_+;B+b5Un6h`PI$nmSfm|ip%*2_>qeZ-I~|=U5+PA
zEkWuQDEC4Hr$~zU=sD=5_!Qa?yv|<2nu$tL(@quIMQ#S?r}NW$5smX4a-8TYEf_26
zxRD<kfhg#=H-0zvqD5q0ibFB^=|3VaSp^RQ-DFDLa$w$Y>4(Em=#=!13mf_pgh5|i
za1(!?XM)5@#|;|!zgoz9;GY1<-z8;Xd53wLhib{5`W{JTSx)~1W9cpbfI3{v9Z+7Z
z>pTUH(O9kWL}gOKbn{Lz&ol{sH0;&?smIYH*haUu?fb^xr{m4^V57s(9aeHpuQj8x
z#U-+?j}F~|xfp&eYVsnZ+^z<m4<f&4^vY+pcpVm8n8D^EwE!{N%d=x0RfY85nZ!=T
zV$7?kwDcwh!M~fIy*k-8CWCJWjQhSj-U3gjdcXj7j?S%dHp^3^4{)%G8Cv~KNNGCi
z@FZ6A(}XPPtJG(7YA^<zNW+4bWRhGZ2_4(#x;<*UCICckKF4~JekZ8M+WE%&9M3hF
zkW#63@Z~Bs<wFK}BQ2PA5V~OkSbwz|twU3FOq8f=#WR&+R3f!sLfYlMjn54S`24|s
zK7Y~5=QAyM&bx0zMt)LV^7Dgc`KfD^pT`>H=chaIv+-MX-S}y$V*z;(CX-=zVuQj*
zD&S7k_3$O==3v;+fp;w8AqoHsjA_jKd|~=7ykv`ucpR?o0N!h`5TApulwgluUn)^;
zh>AbMrz>_^{28Wn#ZEHXh?Xc1LKA>C!sr11p8wna{G0k+^c}bRBSJU-0AJ-|$=MfV
z&_;hlWm2lzL5ax5PK;iL4vcSS2fA?UB?kHfLIm_h;&iP6&I7><ds7a^f+3T>ll~Vp
zsa=lpDLX$acz|y8v8fB>T&@}zqyl5XQqtsA-2{obyMO8GL9~!rHBFCTC%{?V0_@EQ
znT_o82jXe}I%quV56_Ww{-s70eSlp&wt^wm8^ChyC!S|aAJDOKUh7aj47`V~JOSW3
z06?V~d?SKsUo(Uwq`%8y3xD;)p@Zs^MgNRB#Rqx<c&(z=T4O6e!RPeFp6fUV{RQa<
zpMW``b1x1VW8S3uo`idC`cHiwpbC6FatAsemXcA~_k5T$z2m&aO*%ur^A_qh8!?Us
zPBOg=<Szvy0c&<Loq=4=2)^VjJJyqdVsF&OoX!5je7^OV=W|0p15RJIPh<~6|Dp@%
zB1wTm&oC+7Y3n~6*-p^e2DJ9q`w76OwI4o%oj1tgv#zy2J~tWoJc(bKF(`~w<<2j*
zYqaU^3hLm5-yxF_+Z#2|fw8rXC-shdP<s8i`yWpFah!kofUNK%&|BC0lEF!DRbZ~J
z=;(-lN$zyO1(C`4!u)*hD7KvCv|T+d5KOmDrD(X2x*RJia^ykyE5|FEat?-H-&8sJ
ze310{p;#(<s&;JT*IWF8sIp@dzYg+?l>8{aUd9)uY(3t^DK0G6s&EwYZU`VbUN7<L
zI(A|Mn@N9PF5k2{mv7KpcRzaDKZrdQHPk{w`$T<BuTvvMp1M`O-JPGnJdFm;kCx(D
z96bfkQ=)!6heU_r>GRe71&yYSLAb8s`OV+HXeV8f1b(Q&0sO_jr$%f+ogu1T0J&-1
zET|)jXJM{H+zERN8I_lYh{Z$YxP@BPPhhjPB>c1`5m;|P=o0GZmX|9!HW@rX!_<fM
z?gp;AhL7WX-q!%-`yX^5k|g>Xq7<m0#`8JfQ{gwUDM96SNJY>UfUfVI2()%`-H3{M
zqNn5Oj*h}}IFfSQU1B8Vk!0oi4cRewkX$j{gr78`e}`yj9kq#cY<A=;fEd{%^q3sc
z2D9lZb=hvJp`gENhu#T5Fjwg!{-EpH`5nS2X5#9IoCm=E129N`p2%X&)-IOo2)RQt
zKw#J(U%uZJlk?YVy@rwwVcSJ~X*Ws}eSUuN0YHST)?NU`S~D+{wYK%(|GEu2%c+58
zdeUrz_F-z+gX=(O<w1|)>E9;<jYrfD8~g<H=)Vg3a)$@RM+c!tV@s|nun850y1I=&
zM$hXFq<Ck3BFM@W`R@HQB4w*+b#$g^wIcYDuGtM)M`)z2lgAg-m(kT`@5pXkArjb{
z?LrZo(QIg$Mlo+_K{hdOXdw!uz;Lrz^_&%H&2g5<E_SACsW6up;Wf)*E|T^F_51Or
zKDfq}OB|Vl90Es`h}yG=JA~h$Dkj(%--YF08;4YS`NWrKYSCcg(jd458WMq>@#Q;R
zv9ls~5|H7jpxK7YG$$@ddw~ktaj_C>TnI<qCu&r|<#oVn3Ovg4jNvg1Bm0Brjgc*z
z&wB%Ja7RI>3A~8`jGgK>j>VHT!Qmd`G^}0PsPf&O<aNdzvU0W5lV+7Tm*Mt<C+h=m
zz^CjR*byx3+>IcP?bxZdvLDuE1B*Rn7%d!<utmXOgt3*!9XlUXEI!;HMYkFoOH33i
zmh-YnFq2K{moQ#$a@{B35p~)85$!Sn!tDja62YzW3p@B(fLoOV8<WAUaH+|KY-@Zs
zMnh{d&^k4+k>)Y2h6ma7Yw1taxKyl1MELr^>#5-D>I#q&_Q4bRj@kEQm>02y*owbx
zmR1Dck@`~Fxl2$zTby@1sEU9l<c=CBT5zB7<H_LTrr`WICWG{+B-whht7LF}BDf_P
z++rr!0;(r0N86lAN)J4mm@ZMVVe02lSR{j+5*}_7_c@~osb$O+0oN4#y@NkjeqKKR
z_&;9w&t*FK((@JOL$$jX3l~#(HMaxI^$2>O=OeHhL2Gi?O}m^pR(lE5lWSLG<k07e
zrf5kJD`F_KmtG~qehz+i$drpal5xwdo^YvuNuQ;s+iJdlLch~WAbp~qcrW6+p~+5W
zO97_>f3xs67JrlQcLV-hg@uKA_>+J6@+@$h@+Q`2bT?sCjcW&ktrmp6GzWoQ82z3@
z@uEG)xYMtgHcPtwZ1tn%9_r^`a*D2BDQCy>x+465LBO(d?O2nY;F}W4x?bRyhj^@G
z^UQyElRnb$!Ry_$Y4jF|Ss2HgIAY}pG!_=d639%C=^p7Z-P4rlXz9V<Cy>88_Cwo`
z#@~g3U@ZJ(k6l(kp|053x+@>X+M70oWFJ*(7tj!f-VVzbP@pS4M)&ekBN=8Z9NPMx
zJy|h7Fds+D@XU*HsJ_r`4AnPN!8g@LBml=6Ks2~eqxGCj=NzEt3J8q6cHsonLbYNZ
z!jx%_y!}8=_7wV!D9Z#$+V=?ZuOQb~{x#%H*p;yX98&23@Eq&0mbV6yk3nO4AY8(w
zHUwVWQ`k?G6^an}JinIP%*F1Wt^nN@|Etf3-}jsoF-@PqpJa<2k)xdtzw>zVgPs@k
zlUD{?uO*IjK0Jkm1h%mq^MGiEuSJ6oxCZNUJ{;a?P3yE{*ljfYU6*Z#-K0y5u}TVN
z!paIJz$Nfl&1N%Q#3pD8Tk2Xi8_XsPlkGxP^<C^nlf{w+%@6k$L9LOT<p<mHFZY|@
zLI2cQe$NU_xV>3i!x1ip!|+77RP@Er81-VWHvMB1qOCPpY%nvm(z|3B!ls5ZOIVP4
zkbB`Y#q^37ffBR@6cyDJ*LmvHgKt_T@uE=lv1;aYid{0U#@HUSkucssjypGbIx6Z)
z7HBU8O!Osh@~gec+j_I@bSiE60W{c~_6P0(Ynq$n8rhYI(Q^80RRO3XSw5-&^%t$7
z=olFxv_?GmA&e;!Gu?BOmq>A6$|R=FO-Rwkp?>SsC-94R!Md@731Q6LaBV;<MpMC#
ziMwb64oFahaYE~XF{>CmW#(>Xau7-?&|y?XeC2X>hi$|X_`c-)XGP-OSei<C6|-Sg
zHX6)4R<ymln)0tVktd9(^L0U^f#910jsCEOO#`uMhD+W=xCPb3nh7dHva@g*WHdwU
zwq$XsPU7~q#8=x*TpLn>hFr6gKYI#<J>l9R2tFA-x1gGeT2mMgY-YEIxF4{YHwj7o
zd$F^isYdQ;NB?=Ma5D}>9OF7FF?ktf^>gw|4T%Dy>8X^qFvu7##L*t40yKa}O<;l8
z*Q_Xq*rU$m7sgN}yzAu{thAp;73#>TmE|!Qj&a)=dNuXdzcUN&6(~<nOJAhg`57ul
z1z0p^bUmQrcjF$b(=<bxTIuGB3w_01UC>N=X!>RKj}6EvJ*LY8{Xqc+9RmN;L%}p_
zHWuSi9M_IFmH`V=SWfMKtobK>%=|rYLp4bGs9H!p`Kad0+>|b@7PA52H=g8-VPm1}
zCvUDQsaAL1PB?zc1{U~Np>Z&*JQL|Z<JtG2HYX#Xxzcp{%Jt&nC9yXbmtx5(dVEHK
zx0whbw?+N>KB?I@fa3vB%67+JorlE;4f)DRiZUG1i_=kF7mYILiW*q3*-@}|DJ||@
zlhau+==tph(gcW)-(BvCjUXDtRBgx6$J_={3U0q59DHg4CR1$H6F+dF+e(x3%d+iK
zZqC0w>o2nxs#F2AIG=lH;0%qZ2X`1r0cRT#ekzo~Q(=TR4NG)ZyDvinJm3Y!XqVrh
zpHmZ`<;)|ERXGdNx2Udpc<}DaSSn8-;82LkM$GIEc^%sAA7tLojt+Q43S=va)QDd!
z*904<vtdAy`5FFo<OVO$0DX@OujWl1Fs11p{&u(Ti3?-@7z`>E)Rwf=2VTH)s5J?m
z)feXIV~1(U4-s5H48rSG!#MjG+|;K3j5Ki8K|K5f_l*aKzfR=T(UAji5NJ9exhS$=
zxo81+(A3fbkd}BdGr#kF%xZx5kN4q?ZVg%!eeZjUCR#%;Z0MYW07m~eqLbY?@Voj=
zkyEF3)0#iC6-u%6SSI)nogiP`>PYY;6A;iS0NT6>2S#AF`v`xTX$&eUo5N8i=|KlZ
zRs%^!&1C)b?OhXVZjS7iDnwimHr3C5CORoh%024mv@2*<<Ckid2**u5>Q@ZYS-(I~
zmnxv#Pz2F}Ul-sDf-r7n;n!$04yL2Ms+e)uW%BdGgAZ7LQl#hSd#D$jU+@#V$ybs2
zVfm;S^=Cx!9x#p<36(>~%@W$7f&Ef)dx$@CJg$N9b8BAT%@31ap%pID`;=1x9@)b_
zA03dF3&JrTjMvs%rO)6`@|)xgJnF{%?)(cI`iwuW2hnJ~>O_=|B|h#E#s2!27_tm&
z73uUS9FEdpu~+>bx&xf2E+cSHWR=k^1xU!)G_XKxpfRLAZSo1y)SoZ%lON{3moff4
zsX!@5zeqEEz3%e@N$|I6QVS$A&yLxqnST7>7~t)SvsI1-9-Bu{IA2DAjeTkUVa4B!
z#z3Rwn%CqnU|;=x!Hd@Vm)k%hu%}A;tJO+bO<@w{irTfD;|Sv*D|>aQ_L1w0yJe*P
zFg@A)%}W_e00iTEpq7*N-|k*+`W({Vo<83dE9G)Olm51QRyn_0`+R#V9PwC>t+KDj
zO8TwG$em;XpGVf+O#&h7?nZk<-hgd~KBoo#Rck2^Yi@~D;tPXeC|H8UzvMvI`RZhl
zptfqo)TdKMLaULP5LEcj%pq#S2T%kw4WdC+EKeV5WWgA@ID10l;?a>+%xidVnqwAx
zKZxE|FcOYa-@|^5Rj^K}3nm2B_9wI8^l4%>N$)kVO}`d<!7!jx%kazDZZOX^(m!a=
zP5;XF+$Ms7vE^j6=W{r5XH~0Tdlp*N>ijtE`FUr-(w;Nz1@~*u``QL>&mt(3*`61R
zQu!$DIq2ZT9T4b^lD^}4`?51I+Z?<v&tXGSirsp>h-m`9YpPSAG30lp<V{4e8r-e1
z6T3v%Fdmjm5Ge%N(XylmbPWH#f8a#wZK~S@0E|k>TPT%cd{t@#0avS+MiMt(2!0*3
zL{Vuu*n(_CWK-RPMpkI>IZ+F}MjjXP$0H@F0FcQ5P?x(|0}QF9CvzGtN!2ktq<$jd
z0NsJq8i_=z8}G0V#Is`YRWKmLOR|oExR1O+M?Z~%UGsOll9G6@JMVl6+4ZVRr`+rI
zpTC1?V6VG@S@*h!ogZIbf(txTFtboqX1VQ%OQXH`%LavkE8Y^RHawf^x{OfCSqj4y
zd{-<!Ik|x^SkMEZ=MpKV0+Y$dVyF1p6}WbN!+wMiDt}wzS89P<)&!-#XXQW`t^+Df
zq*{%1{M~}av#J$Dx}rSn!qGM+KZXu#L6TO0B3Ql;3>FES5m`A+C*(U5@<c4m*n>rh
zR3m~2gTE|NqL8ft-(3cLzUyo_+d3Q<%_KJLG_vtmXXDY>rn>F;?lrRUU9vqR?G`;T
zDGivYdy<*YmPP~;C5hAl1^@~E5?XQt-x3>`FmB`q@U8gV4tCF^eAhUk6A||~zP)R7
z9N!rS$t3Bm^RNq2>k$UpeGsaBh$o4<b@)z7$5bcl*xsRJitSjH+`v{sAX@~1tULl)
zQ3SG12qa<%BoYW@c?j&*fh-AuEFcugg2#%$2x4Zm+J<R1-Z&#sw*{Z-_n<pi?Qgh`
zA1(OM0!#cE#=4fDi!t?W=a{-SjA`ghxM_WeS)rbMV+%)6nYy3fDFRA(%>0v)|KFVX
z%g{!V20la#+(4|V)fq6X!~hQ|<&*IkIjJlU(-+7FBNHj$kLnCcFtGKi$7eFdXCn0|
zp7Ce+EQk)*FYf54)00#c4wWS8)<`s;F6``_qK3aFjbBsXu>I4kPwp~^k=H#xgODO?
z4w-*GGQV7PCivwO_YTG{UlD%UfjNZ3J5|TG0r;hvATkVM7WpM@;;PkmVSy(6awD>7
ze#tkmH^zg#F<-ShbA+8=UJL&tLURuyvZ-!8o|+2}%rBV=0GSK`b-8bQjsB@T(cqU1
z52^Pg9OT@N)EWu!AH2t(VMxW|FD5te1tX6MW`$PiXv+!S`Q&jM7&$ND&EJm7@`%HZ
z0fP6n_X)MJ&u^P(P~_m~<S*Mdnc^D;IG&h<j8Kz(GE~?nUxa;z?n$JW%E>-k5kjc^
z<+v6!4feUs#y(q&bo?!;1N&rkI4gjCZgaBFW+XA$C*KDK3%=5bNRxf?UGp4^eKsJ7
zsPUIYn(T8YzPk)Q$akI1VxQZMZ2Z;PH2ZuK-zNLyyJUMt+Kud!FNwOXcskhUeg*&u
z{t_Da8WV0{!nl!}EE1n4`{cXENwd!__%_)m-x+6TpX(3?_IZbPft0Ab58ufR>=3Xz
zwm0}+Gk(An*-8jxiy)AdM<6STK-LL?L=1sM0)Z?Kfn7R~B_WUnIM`=5qt#Ne2LStg
z6rbvQpgXe9dVZwvVX{xg9+`dK!mMDQKgQuYvd?SyogyHzPo4i5*e9{7R<FVUMcC(0
zhV^5gOc7FZN)7h82A|0kpNZ5aJmb&sDeRLknth)1NA~k7iRM$YPc}37$dTFS75`zf
zPrV*=?2tGWQ^H>*9&71KIa)1MkF0SeUhLUKRVMq?;ogtvUu+vpjGzbkU*lga-Zd5q
zcaZYeaN>hpnM-_G1R81+ZJaM!Zdn@BYJ*pLqU|cZQ-{e3f<Hq)gB0<}dA_>;Lc?(h
z9j(Fqg)_mj=>t1oERYopfn;Gv&nm9i6$p$kg+6?Qq@-RG+8gfv;9hVZhsGz><4~|q
zbEhF0WsI*pIh9wXk{d}~p7bRXUxICm!a~@zZMhdnm<z?*#etBqqEbt67+<fYXhSm-
z!a(PAJOtyYfiX`HcL>HEf-yYjU>Am4R#QE249nvXf;F4KO`P%*P!!V<sDwb1k3f?y
zQ11-39t|}VBIIUzBu{ucn~COTKDNkey2g)XQ}Op$D|+wiQCEJ5Sqi@+4;!kW7(7{Y
zQ!%0b6NJ>{!YFm6moW(@LQ}n?^<C`@rI9;#p{01btSe^ds|XbbJirV)=81d;zKB4m
z*3cN({?V&{>1Z4rIl%az5)>@sD!u%A3yU7mvCg`iAGpMEfbrrOZ`|vEBV6g}{`zTi
zeLcs%z8-x4_-}>W27`)_I@5ObkbJ7X=O5oh@E|Mt+;~T~$&M+0Z5riV{J)SN+)LH*
z|4M!UKREx7@q=$-XYT0yAPfgImf}c#1@!U1n;#VZ+cEKjhbYMZ|B@e693ww~bZh4a
z^4XssAoxi90Gf8}D`O*%TZuF!`qAqm%Rmn${J@GgO=uTyWA}J-@zDN%`)P)me!Wcv
zxshL>E*Kz%6TVS?ws<>~R-y%S##`mD?Smi6UkwH9k;|VmKnj6Rer@{y+#tirVu^j@
zy@SQe%nkpR4+{seW(6z1Osz+^$7wsB{IJI<n+5wahyCzz+2i~P9t1v?J&vQkpro#c
zK3;pY98Z3<N5wy>J)kQ3C$xtu+(bAcOU8z7FM-nt*<^_~IK6+F`>X1=AcI_b5qP|E
zpNh=crg5aXKLYt&HZ*99NKwYxg$B_<wxv^L$ckGQT3fM^b(FvA?~&b%DX-h+21z>x
zDkCdJqyxz$v-*~p{1s_eb0?~@EX5%Y?1l~VP!pdjRqVjOG*{muYh-8+q3K1vj&A-}
z*7rxY`d-;FP<^cwkzT954>vO9vDCMaO`#3YaMBh#GGs-lkm9+0k$a7L>-w5DqjI{K
z-lIqv=PkmO<n-Dzwdln%tl)7d4YHYgPdVPxpG(7_-*fUp8l9FeIbl1LORn^p=`t8L
z?ZoTClkoBaUJwNt85DriVf0zpr@77jK{_xL`wA4zy;~Hls+b(Xr()OIIDMvqsFxOq
zAg{sLtVgBWthFV3&_3Sd4P||cbHwkhaLbYb22hZ|b3T?eCD`Zz<9ANK@!NG|ds$pM
zw(5I=tkJlzF~b1{y1p_!bipyu)DaJ2$KSW+-&xmihd7RmU%ZaTyAL2bSuCC;-D|NB
zX;Yh+s9Ej6kG2gs)64>2lU1sAk?eBEGg+JxH(iUNu;d5<QdAq?T?RY3S(wT=x#YsD
z)!zH{EMo>Xxoc5~tFsEt4fL_9u^bS2)brn!YQY+^y`SA|&L5wiUk1Lv$T*J%dzHUI
zcR9vYhC{CXc!lKx(cT><y<lO=8!vj*O-<TLqX>ZXX?ic#(WjuLK_=<TnIwTI*dsya
zK#(@z5c6QV=H}J$=itx}xDt~d-fxgv2GU1QwW9xh?ndU;R6<`^AU>(V*>=Wk^aB5Y
zP|pVUtHZAVyTE>sGp3#@4Ga{{s71d6-O5_WvIQapfuC!i7l9BgZ>GY`VUPy0+1}Xl
z7l~IwR%z;9-9T|b3aRtJj-?gocYy9kH=~=GY!Z?syZLr5-%c49a`Q+r4UiH@f;{BJ
zE7@@0U@A9L(Vz~8YT-}vWdfg5AqinlqD8k1>fM8egj3wY<)lqNL_@6Mrv|#Bz8XI>
zE{9TyX7Z=kh|$SmP?{#~VKrC}_o|;Feqw{o4n&V{tT)x_J;0!XOpRYresMj|kFVgv
zbWfJ+I_V&tAJlV<R43_?Jl<Xq&*VpW?GTT7)gEj>tC$zF+Ni)xA5yzDtJ2k>-N{I>
z(%M&fGpo%EC0C#7mq@`4JWGp0Dp`-;Aczc+ZsX}cJx9Mtah7zB_J3e_C_@SGAqG1l
zu+2ms((uw)X9Gxiv=6`Ca`uJWb^F;P80x2{Ko_d%N(H(wQn18FSCSDOLKu#^s9R(Z
zzy(!+rx3Bp+zq=Q2ogMw4sDYfM8=nnFdl*r#tSUog!z$pgeQV*Qtq`R7(&$wu=s8e
zCG~!!pgTA@jRZbD>RuT5iKa}CT5LX{sel$6ldd(O{HfxdrWr9bp*b3=(*upge#QF1
z<dsnJ_OZ3$=|UkX9EFXPvEoVJV{by;Ut$qx=qoIJ3g=2cZ2$DAHtfQU`aw@A`brwQ
zP*=r8O`eG+P0I4qw=!QPu!gtAm{_M$xk)WsM!kUwYR;9Pp2Bn<HM^BVE`<n=P4N6;
zwg=s2N&oXTk)M_+yVBc~2kMa>tYgF<yRem#7pfTJ=5yU)k{|Tber)T(ASlGP9z2XD
zrGasu`{%AeszGSQEU)3%%KMYEy!+*|UwOYfN_nQf%%lGHYqs*)INXI+CLQ!|KjGmP
z7dG*A*~i!5`m^&eQQ6w(&jaIoHc}m_eX7ja@ahK5?1upD+-&I4wh?I@+@`S&{3%GS
z_Q|$0M{Xfm@Fcl3n$b%UA%h2wyE$>yUnG1zq;9cX#!HTzl${&Vj`l&`n|>u$k=77$
z#KYe7Xy-v@9Z!D9YyM#0_2*#z9tZXhGy`qskbLA6$jul<$KW5xqMs_YY@J0q(nue*
z{x=;@e$;=$$E^Qcko-TR{x?1IG5h~`@}vHte)T^t{lnkDU;hc~ZR&F>z@Js{CC!Gd
z0i)@Gt7X{O*^QG&MoR9L<?y+$kb;b@6OKm?(c5?Gf&NqMeVP-)97a$cFekoiv<&qH
zq~*k?+E<H|AE^KrX4(*t;qPQ5fLmjk>G63EKlvevPLoKk;biTm@!ed86|_hup2P^g
z>p2gSti(&S7K*OFE*UNNCufxxC6|?Zle?1p3ieJtyx21}<6FHR+%EoJnQ!$=D7*H(
zRVZT7$-bw@_~*c(fN%Bv2<?0gxFV?js|Z?j!n=<qXOw$yzU8@O)5N_$q5GKFiMb5z
zV3S5#moNSk<UG`bAeXQ12YlbF-yau<Z{{x=ksK25bf*@(6GKxg-M**aELb%1UEhim
z<DH(=V$VF^E56i9&!N3T0U>(3@98%Rd~u$9p6C1e)jg@jJ;^NIZuZAJC*b$;GCaOE
zA+>ly{5^iZJkNKL@Auw$zLlTCS3AFU^Xm#fK40W#7eBvVmRdPs(YDlLZ|Bbp(3#ZY
zOzKLOa%9**&<2}dHrV{MV0+Tn0ov8Qsl~m=fV0~HmtQux{IuY@<L~(wp8T%w>u525
zYB6fI5-sLWE8o)x`?v1Ffm%1|PR+d+=VjY<M@3IwJEVT-mGQlK@uoZ-6#H9ppU}vE
zf>?HS=D+(`{MCYN`3A{Wo{A#(IzE=+uO5FJ@n_J;Is&u5uf064{)#*!1Z~WC9k%xJ
z{Q4{M&9tdWC#Ej;NvTzu{0xd*k3KRmElU0lh>Uw-?d93}E3#K#gB{k`yOQOT$dcR#
zR1qKlyF31t`@?r1>jldGdf-}y$5{ML#@{UbnPslMyrBMy0vm4f?Ziu`(P56d9BSfF
zi2AO)`Wn_rf5zU{Luz59_V23@UHcZF=&m97yV{S(b!B+mJOPh+6?l9tgva7Jc&u3P
zu5aZ~{9S`&E3ZegmA4?-%C8{V%C95Y$|Xp)a^-^BPQpC2YZbUoY#pk<aCH3dW%0L=
z!z#uA6z?oMv<ntk+1Q^B?ZV^=ffY@I21*V|48=Iqfw45a3Hah~<;DM=$Ex6PW9)6C
zRni6En#sNKb{}tfcnt-EG!CxZ_1B@%d8tRs@$C}&9zts8IJ=I6@@5Rjl|%7&4GHvm
z1febnpI3p$*FtzKo`c7V1&H_x!cadvmLLrEOFgv;P*cC+b7t%j;C2hT_OFF7dORb=
zo7!CcE1Fu2L0vX8_Imu_r=k;*yFdxJq2!drsCbh*zSpg5)EqxppsD@xE3S+kGSCN2
zniOEx=V?C*8P_`Qg{tK4q~tnb?J4!6B-bvLk8OKE1`h)VtBk$-h0abaDy+$c?Ulue
zqZ+J^up`k<e(SK#H{vb({jc>)A^EL%%I{7HdOqOlMz1q-{-tp!(B@wnE)#v%H~7v8
zbo<82Cbi*%_(<uE#PfW=YXEeeVes@5eCGt)%>w56qPTzHoIoo|Yqc^<dzk*O`{LIp
ze{8V)#)+^!nI)`p4xjcu^)1`;-dhcO4zCQf?>YQ+sLFH=j+DN4q>*;dhgOXTPd{f*
z@5o>S9#*DkK+4<1@-`i{y#D!P1LjA4Z3kwgzvGvz!F*h}3@46_gCTHwOTtK>mp)BL
z<}JfTII@2iQuUgu(taM6lLHxNVQSZOGzh$~PB1XM60JzH!Q&)-M0kY|U<SpnS?-4L
z*x)T5o`Yx7OS_|gYr7gy<>X~@UN)d6z9g31hu#KfC{E5s#V^BvyA%=!O6|niPDn^h
zREA84-ZoEFK&97?09ShW(`EP>7lx5bJJhN)3%Lpx`m`;Ae{~!`KETbHHo6Um=|>Pp
zl5u@I;r~T9EOjQq?y12ps9*x!oo<#k8-DS-p}|u(Lg7y;Tt%wDV`beOFyG{5-f_Ia
zYCqfy+0bf*Yo2l8RyksvDG0Ri#Bs10eU_<KyN5|-v~YO?v=WJ6BVeWkT$r!<>S|qB
zT?L9jfc&Zx5Qs&l{r09nwmxtO2dxf)qvpe^2xroE;}~-${Q&A!a2ZZF(}g8&kK+A1
zusCX<@&@f`qCo8>TqwbRYCa(6r{UBgGwv$rOLnG$|4=uGCCpCyu(w!ZZanoJ{|lru
zp`Yv;xHH*_?95xFGnt62nVm^T@^Xhy2Ljlc!n5V@3=~Q5VI-Z|ZggfFJ5#zCZY+XO
zm3HgSJW0csosOQV!ESbDk6aHWo!P_Ad<d&DaJ8-AYFqKUNxBiIgATx%ybU273O_I|
zykFd2pc`A^lq(r*(cSog9tpY|uaa(T_Kgj0N`{+#{(QAjm#_{ctW&q(V}PE+y<5S<
zww{9{s!aMJv*#KeJ=dsvuFfoV(4K2Z1wT~(3C#lziQ9Tk^9T4ZhBs=SdWQiRb!jLg
z=d*x%W@t#yFw3Amjmj(EQy#$*MBY12_IGGMaIE7QV++0O7|*vD<GEHy;G>P_VB5aV
zDOY)|5sezP?Nj~7^alfuX&+030o-MtlsAMSq1K?K1{l_}z2m5SJ;JaCC1g@X)8HB_
z8E8hs;dU*h`Kew<-hhz?pIX+)mO+mF4qcveWPcigedvStvSDNg4#~Kry<mJ-84$+E
zp6xZ!=iug$$2~;YVrbA<eA$i#x-a9~W_DjVGj6tL-}{NM4DY*eS|J%2czE0T_lV<r
zfX;=_1{vSbae-NXwDBEmw|8zEJ!rMFbKB^u#x};eHUJOlGsfw!ho`Nr&fNy92gfjH
zw}P7=VVJj?-P)22wCDyM39Bj;rn{BLa>31Iqz5t5^VB=K5Ixdk_!yuk%^UW}quG;w
z_T)php5$Q9^<<+i_(45+>w*XANg3|H!o3&H;jZOX?0-SBz(^ND1&N@=IOO5%WEcHO
zp-8Y5Y)zeSmSnJ%Uf(uzLXaW9udn-M8-27NWj-H(ME*y{zupz-GpF|-|7f~@*7z?$
z=Uap_*!b7w^%?&N9Dr($Z~T87z$`2Vp&C8@q4WBGb^JpVI+pPdr+y!Q{7;i}5rdC^
zU5GLM@i9P89^d$Hmh%us!GrXq9{(_R|5)SyX0xP^F#frI14p6v`$4wU?HlqUf9!Z1
z&Kgu6?6|RlNsgTAk7@@4pT3{nsW)Gv!_<Pi$;Z8k{J#6a`trr9Z=tr1{BNZk`MaUK
z9WXyV4`>{|%BjKu<Nr8eblv5|LGYLSav5f@U;g>d{CD=jLGtVU3=jCP-PN_o)W;NW
zEfcR^LNkB?`~yr79uMIz0~g;_?k6UxcQ@y`#$>s!dli~yOnyDJxCs{DF}RTIamDP*
z3EO3`G2AXH_o8-gm8#OXewrKZG<+@y>av}zh6lT1K7CR-iA0_EFeP_|lhy7gE>(A-
zWZZ}%<-&Cw4#4Aj-3#Ry{CLcw;{FA9$Pyx!W4KR|ZZBc))aJt8e(VJCt&{#tdZIIJ
z{Gbb)|40E3l_H?E4iD^)o*>7@#5#)FX$Zb{;xqL(`o0MfevS6IRK2_@hb3DFr#bRs
zu*O2u9Eq%@zv5jtnJ50`jDffsK=F`!ELQ_(MY@t#T4y;v1?(cOdfAZp?lYuX`|0>;
z$>0RF@E6=ZZ?1vs*=7}{SBLNf_yvksStDil0U)8OA)5t+zQy(-O4Ycbb}{ho<A5N5
z9@7p8&Wg-nZo_SAnGKy`PIPc)UeI~%Nutw8bQ;y(rz~`=tQs9cRZBM6(D4a6I84XY
zIpj65UToK`!)03>9S!Tns12PnZ0LM*r=xX{R?xXt&}kq#4eE0_bgZlz9YR&=VH-O1
zFT%5lY@GupItMg52TY&AFs8JjbEXZQu3tLPfq!8^XV1^sIy;HZPPGL+XLOd8Rii_w
z>I-&s-lhb*ymVT$1kV7EewSWO$EBrLaDji=#p{_5=dBGKt`C6OmB$ZylHsu&O2H=+
z;qA%5lfwhsW0%RcavqlH;GW|Bxz!atAC6;j$PTQ|QWIr$3anKT)>@_B67jjH^G^IG
z!{zZ;VForf-j0#|cp|VBK39hax3b$>&;ZhHys`o*TjWyh@_2h$GB_3kF#*S_aKRdW
zba;463~n~Y>*k~@6pFc>(;();-03Xey+4-x&@-%V-z0uLTkr#F$69(kaP0|UDU4Ht
z;WB&-a5KU~vLqeb`AY#a0g1+=COuU~Rm<=(z{My^q}s8ab<7o*fJEa5FJd^94e`dZ
z^o?@<s@+BgvutGW`VJczd<6Uj_*k+f=%)8S9B>Uo{VVXd9)C6XlY7JR3#@Cy`o0+P
zHvJ3cUpbIEnq95B){2!rY*tWB`t$M^z<Y~&Y(6In81x(bssu|)_z-kY2^1~zBjMgW
z*LGSVcfN)PTGNYldN}~@b>Y$)zo?Din%loOAH-Tjd&odhT*0oj2$Uxd6MK-U1eriB
z8GsOK$q2P@oz#s^+I0{o$hwnj9$1Ba*pRwRBMJl-+ozsjwmx_mi?>~`x@&hcC1x4m
zifhTqhP%uGD`r$s(iKp9r;;$}G%v<hPv659@WM;WmxRMc=77yc9>gQ0{@(f_S#5v&
z>Ir0+E3is}NnLl2eFwYayH1!A^paWhDO+r^L{T+55=vOCv}T3L)^~5Sk%%PxJO;4(
zK90VF&D5L;zo}})6W|oV@+u&!^F>^10gCX{h2NL_a{YJbX=qBca2Z<o8l0AoPd<;$
z(P1`62b&ySfm>oR9ZFpg-G|%Kn`EFB4P_{ecZu*!%TL*PE{#t)FXn?9Xm9>`SPX)K
z5G<g0ZxO=RPS2~)lQkn9WU?;b`cI(mPp+<K>0nH~YxC;!F@npWCPMj`z%?PX5l=)H
zkQ&=ya)#M58{?W3`kM5KfH{t?(!AsLVND*Hff)_@Hy{cnRM#4#HzN-NhVD>lqX}rJ
zkUIT0(xHGY+7D1+ponre^6t$GNHESl!c?r3reM#GjK4p@x8_I0h9TTM0&BVp4hu7f
z{vgVeUZHrbi&;nTthvk1f!y)k9dnWA(0jgTTd4<o)>H5TVAtcGTq}yXO%)pQ4KwmV
z!#Y?#9c9nwdzK6n@JAM~oO(Yds{9z3Y>!4gR$Nm6CaDK^PnG%&{OE(!ZRBjO_aRtm
z_L&OruZG7zkc@Byxk4|Q7gCdOOSU+x!u=VgQrmX)H9G}1cj2z|WVn|X8gm{vz{KQQ
zfv(M%lqZ87!)6@y0~qPxMLM7Jf_pPxAMuE{6898Pp+oLJHU#_YYO(JXTI~u|smH%+
z;3-PsXpw9S@WRG`7ye%Gqta)SpTj;FHBAP}IfIme@0H?1PkpLHroA!|1`Yl<)+rxr
z@pE**J38$5{VG_b_Q0dYJkUQbvF?q(?^(fn$=*g+`nF+AWIW61MeZQKkys?(i7%-$
zh67cV7ykq1LpXZsqVR1A%cH|;G&TruY84id!S><7jwoUNKwyN6K$lUtZ?_A>;0gZf
zDs|N-ajSg}vGE3C=}T;~{U`+HWP8fcP*@KSw~<HC*PU=<>5zFKA6+lpjd>8AxazLL
zE91`}o)&*ke9}AnXDt|a9|_vgesEpdBkPNP?N_%!w;v^~*cnDEE(1FK3g~PAernHm
z=;2kLWcef-nT{~U8zp)X8#DSo5`QNR25Mn94Q?2#@NEnBg3*kps?S(zoQPuWOAV+E
zhX*?P&m3z5UFoX`2rV!mpgrqzfTTSG2ZjgQ$kdz?^;*y${NLqT$!MP_{3DjSmO~aQ
z1<E#GK%m-TWIpkR;Zp*B&MU$kIpqku6b0u2SpuCE3E5T*IE-Me7{2m^V`{;22}0<2
zRq+!}Ev=kdTGi<P1Kter2rC9FYh*tG5~|w2-Zs130nH|64;UMBGL^QRq;{iAazyob
zBD}SB`QuzL`sy~JO7Z1e@%C?c(?Zx-jJb00TRMnix-W}q?O5Xqis&dAHsavJXp{EN
zgAmkeZs+P&70Jnc%uKReiJoK3Dijq$l!>zoz$?~b-wXD<9r0ZSv^orTKt4g2cYYUe
za57&neJ@oRxYseM;?YESixyO2L;xN_`Nk{!&uh%D6uYO1*nKPb@!`0-2-9^_;K?k+
zzox);R5%BFlG+H^xmMbk2yaS;Hx3VPieZ`t^a&Pp-Lf;?wFhOT8^EOn4<^Iwhld}G
z;gTX6LYdIhCqb+SBS{9g$A6De@g#1Jz&)#B@80|i08}PsD0AV>x&?vaXc|hP7U8|{
z83wgN7sNT-Ee4YK+mD<xbQfo6HjTxY65;z2fpzia>s(84o6UVL-#t{^@0b95=3#DZ
z3hbmU3@+fnlk5)K<DJ+*R1=4A#O_Rl8+^YCXX;+^-FH6{km`N+ufZG5)#=#PU=6{Y
zqnR?6fyvsh)w~CUJ@kMv^u%{hn1}TQ27OOFGiAkz7}on4Ua*hBsPNigPd%jrv!*Qm
z3HUPx3=;ux4&?@4!|Yiqb9!m#JZzbon2G8F(+fcJAPRRscY?vdoc25+$|6y%`__mY
zL!qP_qNTvW%+&3BHb0)3M^{>Sg#>XqE~W`|OWzuaa1l(nduq5V3LOQ~c;fF(p&RA>
zz}WZfZk>-adUw5_(vE=HjY*l`qxu%b(+1u3dE5vvoQuoki83AZly1kiHBf_K3~8q;
z5wy|ohcZMyTp*42p}q0UK`}|a_N^S@jte|_8m=Y@G-4Nvm$ocBbtN2}H@X&%6sj9%
zQC%9W#k)7}JX>!x9y$O8MSP#@(C-N#*o-(%et|BukN^v=JfU`Zqr&i6I33)GFM1Qa
zv0D8tmFMz3+YoQyK!J2=_Oh8yw$vJN|M&guY~qI`XzAFA0(yqvId|d3m@MZe&BPB1
zP+VCu0f^W8tsy9h!p-RY#*iAFgBXNqfD_^{fe5c1M&io_Vsm`g1QbuP&lrV(hzs?&
zp^v)kLn4hM_(o&DDk0Nem&<YZCZ~@o#e&L|N6n?wOw83&1OC`_x=Dv@-f#AV=|=&^
z33sx(a@@2FGt30}+|`bT#wV|Lgxhh9+#)U<e2^TZ53yqi;aGy<v1H}VEaxsaoT$U$
zXL35kWf1a&0TqKKkg=hU=B{<@6o{9G^LiOlHNv_52-};F4uF?sEF>~GIS~ZhOaYEj
zV1o;*E#Lj{N9Lkz%Kc_zO>&-*8MilH_(QNRSF&CPC8$5Mb{HwyiS+UtfJF(gfGd9B
z>^^h=Ew&6S5Ibv%h7dYXoUkiBN1*#{1@4675gerA0hJoiAa-xRmk{?~hEQ$H=j9U{
zpsK>$CE}abF{A=*;^?~+-7gn)Cx=z3wg~1LI)TNyw6uU%Wk7HhxtdGMp7f`n?ixU@
z2EyZbc>vUoIywU;tQXPvMgMsV*iq$ZDG0Z6e5eh-3g10d)#{!v8>M#B2~D&p=Ti`K
zE4m+R+E41~nMi|40%iIY$3**0Sp}Au5{yybNvtoX6qq`|7R0P?OaJ<I$r1$h#qyzL
zKpG`=V%;g~0tk$d_`$450p?;ufz@#V(Pj1$q*r4(5NyX8sTLqgnF1B2-OTrHHR`G*
zgZ^?vN9Ut#GAVLOplA62>V;Nu;Dg5Q=>@THn3XOYC(DRDUEV;;h<)O7r!0MC`U;2&
zhp`kt1Ehpe0=2b8mz3OKK=TG-_EsFm_`}k~fXO;&nN|&v6^Yg8mNv(*AB=awD^&_=
z-xFb=VjOo(fxBV;g8TKK;M{MBW?wvTscr<J;0&`NJV)V52isJ%LvL1dkQ<f5K{=8Z
z4kI?Jpaj{ZdZWK5bFst(8-I{15sVEJF^{-3t4Ep9rO$gAB_Bj94^r|QfYPVrmnFzn
zvaYmI{&;=9^OH!#^&cwQ_dWo#Fq}@@ukI0Grj4Yn`5fzCrfh)$4t`mYBG8du5wh{r
znGT4P27zecS4sVTtdx9fF)sjwHX93*CV(JI@1$zb2n~Al;jmf|cs9Fo3Ana%DU9U`
zTrY{UsL_$JPy?D?fIkz7;0x}D>mPH7_wXtO%~6TE6(~}31Re8!HREBlFa{=OAe}GL
zLQsUKGWA-v=lSr?C$Lsx?$^)|)bsGPT<ua%=Z9GN+&J-h$d<73!ZjG6rtN0Cd#hD>
zJx3W>78dlVEd~kYO1Mp1-sN6-0;>E4z)gRGke?UGt-QvdRn0<h=OrwY1?_+!4tK2a
zot{m2!Fu6+KG7Am@6&bQipjEVQX<WI5_^Y0K;oyY5gttF^96cK&AG6+QdfftJO4t8
zM|b$vJOCJyx8J%9(za<7I6Bg8Yveg*BafB~9IRazY;#B>_kN$v)XX(hv-%5(LN~I`
zryH5@)OYT+EudxrCGhCAfuj0+8yz5&)Nww3JI}$xFi+&YE~uzMjARc*@=e!ZI9I72
z{5c0!nK`5(mbas_+@s)`VPD-gyy@E^<C(jCbz39?4yXIK<F8lixlHu3eHNNx0BI~V
z-FN3)N5lcnY^1|KbWkD|n$k$W`yLyqk&V=-o<;|eeju`0S#>)Rs+xaKuAQi=DN)~*
z+zsr}2DJ>i(|#L`W#mRSOY0!x&p7|(d#cin1^-YXtu!=Y1GpG)@{?absQHP>ctx3j
z9bHY@!b+xom#oTSC1!reO5lh4)qR8j{$b9SBI10`0pUF)u^>o(POK5vDv&yS-{XGk
zb<zv66=}dP6T*j(?T31VbFCIE+7lzTV{05M*+lV9ynuMBIF<rlOf!^nbVE&i2^E=_
z@FV&{MnhrcMm0o@i!;2nckAK(8CD`90PV_@Dfe(_n==M=6yg;gGgc=R%9t#YBjF4#
zj|wS}Bt*h|+$CFfe~wdCN4oI^PW5NK(HGC;#qwGt_0uxqUybh^xe1Nrit)-&I>QU#
zc+OK0-+;E^)Osn)!VHE1k2AWkhc%AxZo?^K-x_LW1QVk&*x9||TUWZU+8G^b#*4``
zZ!uAs?LdXh2X6TCR*sHrUzbaLo0)pdfT>qpBSm6lPMz*vHeHY8e*7B}7bg&@F80>(
zg4<JQOoc`DbSSG%m`(bEh#b4n25uqNkLblJICzeMZ5F9-|2uoEi^HHx#n62`Gz$G3
zxd2=P-jx2LS-w+ehNUKo^uQT8StSZ)U7_8sQtPVCf~9~9qyWVNlqxa`=zFKML61-%
zczA|e-Bd?<?@>kHF;2Wv=jGG^qd*biGdyBf@<6V2M@A;&3uMvskb`X?;W+j3b{v3o
zaZ19JrBg;8WM)E8#VeVE{`1rDIMAb@kkXs?f}eH%6Bct->KvekeNHX0n)u6!`*?HS
zl)?s#8?Kf5AZ<w3AVzrXcH=}``~@z4sCYAU*qKL|6=I7i3sbJp<sTKg#Xt;v40-12
z^(O!EQUU>Qzmt+eqZhi0!(=bdAOZUPuvMhwhd+!p!nxg;k*WXu5kv`X=OOW=IEYB-
zau}N!5rz;X@jBBJ68Hac_cicQ7T4aJkiZJTL`@VCA?2$Gq9~|fR6fdDYDwLVMA7<L
zm2QL9uMHxCBrYh+vKAGrwO+-Rw$@ThE0w4e6XcTMrM<yY8#UE{sm{7-O|P*mG?4fI
zKQr^}v&jarx9@x3_x0D3edhDbnKS2{IdkSrw}4&g@I4Py>UbI!z6*eO7ksB?gfG?q
z&olOq_yZ;a0$36vXYetQc38$qTJ7qXhb?Ih)?BsS45krl9(~6*;4cf-f^YiORkA^m
zEBTi)^*KqMX;Tk}rZ9Dlq@JNuqwRHv`!e-DNgZU$woIMhIJr;ZuNN-DWy|tbPJL?<
zlz`3O%2}taDE+u<$;a8DzW6r_OH?*U7PNB=XvZ1QMoGi3>hp9)3lPxqCH1E^)qr;3
zI~>NNI@JN~eM!YDa-`*OI%q8ftwn>@0;xBqdT$lxrShb7pw{WRN-Slv%y~sF77w;e
z&1LFK;{M0Ouzpy1(ABPl?HUy%V2+YaxdLOrrHCaZ`OhO@L%Z?=Bsx&z#C7Y;q7K>m
zal_ICezV7~c0<%)dN5jqxRNIOCN_b1y)YbfPW-L<<z<kAj^K9FBm7Te2s~5_tq-qu
zL$86XfnbSeW7`zz&#YW#E%bVpz!1WXNS=D_Az)1t`3jh7&@rF?$y4uCX+cM>HxJTy
z9zx;>x3A3x7?CUj<bp!4C%k7^dP%qVX{wiaLn4{MKf0ZsQbIS2ugZwvoQ00MRB==A
zS<Up`_#UUyQ7GZ4QUbL@{S4F&q*7~dQV(Ihak6NMl6pb!BVd7SPt8~&^)+Va$RBVC
z92P+zp0`w3p4kd&DzGeIrH~LgO8PU41EG+XsjGF(*MJr@)%~4YXTNFq)l;AV%MWCe
zbgQO&EMsyj(l-T^Ymzm7v(%m?0->LBMExYi6(pY=KolqV_ocHd&0nR`uQIVKXFq4+
z|9~jc;JZ*S0R!J{06!CaPXEtm?qB@D$fT0$>ifu~k}8D1LaXh-8uX!$Xs+c8OG$Ml
zvq-C_P_1OjNvlAsg0G)PHL0Gp(&vT84l~E1xOPyF9%l|LI?y2Pza5bRm<qc_aW7<$
zYUy=#4|;9**U;;P-~^Byg!J(5cBj`1NU#3@ig8^?J665R3D@+h>jhUk^!msmT^|vL
zVM@l{W;?kHQLQ#FP9s-Pa16ws1rp)kW1{5$xKxtA{1Mb((wi&EB5yY_^ySQ_EA$1p
z2p;CUf~|E)n7CWRd#BFd4gS4c^Y1-ml6y3h+*7siH0(`KAyuukweA2y=d_0RO`X4O
za-W=-RP!~mTBB4eZCn``U$rkQ|HW-!lUVY*I0EMH!hoQD?t(d69x;c`S(#e$=UEiK
zw>Axh4W7!&h{Bo}QD~gOzArS%oo$7#r%}lE)TQ@GeVi(RF1sqA5wr(_)J@c<XE6s_
zSxw>`yWC|3%@$dPBZ}={2GE#I95KDvZ@X9Uj!0tLGp%*9<jXF{jo3j0YH>cn7y>g#
z7EF9&|KFlbyeEslzfVlZ19Mj+XAYtaAZ>Si_dB~k+TAo@XJyC!PonMnZyGrWC1#E+
z-2XwJ-FF^af^v6z@9bBCvJ0}lhMmcdYrpOaadR1qn(m}Q>2BsoFFM;c@r{IEx+_3;
zc_``a)?EX-D|{IL6qvs9(ATl(%e%lk4zQmxXJjG%dhs`J|J(bUaQ5!*9OKpN$)na|
zLLq3oyMsFUJSOiwKTE9_M%Y{ZY!wpW*h@YX`K-#m2=&zuQTs?*DKHFw1k=pEpsUNq
z!vRACOS>sLkjHR%0uuX*QTSC=i7?f0im4Yi26w8?G6gRoY7mwuOMB9v%N5quWvah@
zB~E|ff5Gk0ebw(C6auoAhg`_%!~y}PBQr2?LV3;tgZOUu>ED1IZ1^QM`5=t{+9*9v
z&d55kmE1@kVxGR56fAgD*wLepxYkmNi68xVzL7qj29D?O1OLkLu*sty&ub6&J|0-^
zIlqVrnT1>XOFFYdu&Z_U2^A!Yggg=_XgB7(8tfK4pc!te^$e%xZ`=84^S6uRJ@&sj
z-fPq5k4+x+cz-W}b!=D_M@i80hxa&tc!@*+<;<qP$NABJ5>c=&Cb8|cWNfrYyZ_=&
zxU#?c1;7K|aIOO#kFHEQdYQYD>2Gdo|6v>};Oz?}LQL(^e;WBm=Hc0T-v)jdV<qHx
zcuW6vOvzt%Utd-cxqz~i`jzK^4~Of#VAKU3k1=-;o>c{`BaTSVmZ_Pm#K;1<k{fTu
zZnom8;4&ffiX80j`j*hEjTWX_wGu8B(FXMz{@}=kDUahPoEJ^`>|hnvuloJ@w#pW@
zUssvnWtHX_T#k7k8;@6-Dp|V9I;TpFTHk`p77gl8_ycV;R$8Neg`arHF1^aFPL)mS
z4qfFrsj??lx=Af%mFrVgvIyAuPL+-7B3<QfsnQrL-Kb{cCr*aMIN9u>e=}T@;opo?
z5?H_BKAju?cThJ@YhVMzevD}6%{2IQzyq(fdPyrSK}$|R0M3=ZR{AcqXm7Q|JNCt7
zm_E9S7VB5ga^rWSHF#U*F364Ff}hxR!xBs>o|XU5PtiE0%9_8&puegf{ZScPij%{}
zKJ+IkPQ0I}jQRcw=m-`%$A!6;)cG2=XY%MwKo+i?xZ0$PBuPA6kd)IO3c71#&f8^(
zi|}Gz!IaWgcc)E>M`<C(8_FOwQ4h<Ts<%}Gv@-pP(=9mk1&N##-A0!Q-9pz;bFkM7
zZyyOGRBrqxa1pcy7fV=|P4zvwYz&XD;9uD7fzyDz2%CwZRX<l_C+Ws`;^~D_-&|cs
z7*HAi0%>qIMDIJGm*W&vdj9~D(LCm}l!nXZd67b|apPMGKTo>xr9SsKpLKg-=tXXS
z?LAf3(huhzJk8W|SuFi|t*tYZnoAoF7PKRCIR`(sVVH|?r=;~${NO{F+dWlU)!U8)
zU;y4j&DbMtpBGt%$Vg0Sf-~*P^41j(qadbYPajwbN?TW~;Ai5A_&WTFmH!nUeLTKw
z3D@FDiI$XiqD(4`)r-5$Gm^g5je2N`KohO9CvTM|>h=PcLNrr+txG4qL|~!H3i4L@
zj{?4p@gR6*@GyYHz^b>=V-CCcX1{vn*JQVO6-zNfGk4tKs~<Y)zCF3@0h7BYpjPQ*
zGR2oyp*8Ttr`ae-a|OS{uXnZQ*By6B{_++0nh5hO&H>D=l6R33tkL3q(@K{(L=Z;M
z&;6^BKb|1^)!OsO-Moy>=#4(S25HqFRpH+<b+41dE+1!3oH+q?gOkI?2#jBq>NKeC
z^<+*MJWj55MI_fDRwUv@7GHC&pa*_$)r16CfX6w1Ksc`^2tYt}our_`N_Nd*mp0%<
zUyh)$Ouc)qfDJqR$H+w@?h31&I+0^(4yae0FJk%U&KE5zPdi_{jq$Ml60Q*^lH*UX
zO9%5IUk|Lq!VIZYBNKD?=wR_0N3oKrx5z&);zB+etQUNsaSo`yilgU$z<qsI@#FBm
zW)Wgw-4pUcRDBf(U;HFKP-HsRAg5YeeO{T4En><b;K=(IX7nQO4?=sTy!Rz@*P$I(
zT?&1t{$0J*f7#ThzTmd>XqCaKKe4y^i(K^!y7g}L4f?l3QIUY(qROPlqZE5IBD+oP
z9e&dSd;^kD)9t%CJ+4nX<7GJ-#jsQEQh#K-M|eNQ+Qa{+;5+Fk;NxPzu4c<bSs}o)
zMxo3P;WznDX3B^E!{t|)Sh;8g=dnfy6HzyRH;?|pTSVXTRGut}b$iKEQi@wPb*?~g
zE>=WEb_HK<edH{wKsBikv;s8@S`$n&_L3h@zhwL0iobZ_y;UqYO{xi{agx^s-fhmV
z=Ck!HZ0pqMCONI|Q8n13L)ZEn{=lWh1~X}~t+z<)<t;19<p|(86w^0cLW9UNu%&wN
zY(bjl1YJ2s&78lj4=6IcC2JiU$X~{Leih$v1M!Oqc8HB?q6Xp?0Ro5kZE`4*eg?d<
zym>|Wp%{+sM`<7qL0=thfXLQB;0pnKRfmkvt3je-C3}+j4Sj%hqjq4UXU|gL$5e;2
zDL7@dLm{B+iket03h@A55`dc~3KRq?;1T8&IKD@L!T_vLsRDni>fQp}A7B!9T4?N1
zU`U_>ewa>yU-T$Y9H@Zd&MELvj{>-x0}HrQ;MN`m#sn&GR)7MC>WpE|?or^hK*h<f
z0^@oV7#paV<0{a<M}cvHigH(h_|oopfREATt^y4`3XBg_T;VG4lO6@m2vi`Ntuu-T
zdK5S_P;r^7z|B1hOt#aVEqIvOqre4rx^;mOJqk>-)2$0+_b4#aPPZ<w_rC6Um}O^E
z7pUz~V78r2UEpbVfzUKrd*8=0g*}C24}->`Gh`*=3%+*hW9O^1Eui-5FTEtLL^WPS
zm@&k!yjYlMB9Z@6Ar|V^$&BZ@q~ntxVf98Irkcbv#{N9FfZihCxJH5a@CY_d9Y<2o
z)O2rT2Gk8#ol7P}W=%-1H7OF91la05<Stz0a7-#~)5=ex$na2e@`ICXfrT2yG8Fe1
zje@_e9%nQP$%aO;%B4{>qFAs&7^?bnRk}tIUbNT~g1-SaEQ_6{MiFghKmqlu@fMXB
z_Kd}T^^8v72yvP2VRp&ld{J*P2MP1IU}s|Ob*X^$TE5d9kQ>JZ1*w52`v%Sgl0(OF
z*3dXi&@)qw2MS7xX4z~)h%@9-CYz-TOLAx1Y`_x0b;-Uao23Vp4D{P<7RO7{AD%8l
zA>@G}B}H>=Hj57ls0NeG(#0jYb8R+@7niA@nrxOHSu*fyo6X`Q{c5GF@yR7cx7%zM
zpBzy0U5#H*k{hzwZ2W>UHQUwrw32}fZ8jU9hW83wjn6D8T5Pk~_{@Mh*46l|lH4kr
z&BkYysgK9$akKR7l7Y)?HXEPqSB*M5W!$v-9PM4=z!I8|`4NBm35!Pped13)W$DQ}
zAE957P4{ZA?1j9E^KF@u%F#%rT@jjDkE@8~xH3ma_<h`8!#D%Wfj1Eq-OkZB{wMXh
z&!I1^8mm#9rZ0utCQu*hzzTsis-1rX8;!=Al|cilJlQ3nQ)<z3*ayObbNX6GExLCM
zJG9<F_Qm<HfQ6w8VPMgX!jYCFKlxF`Ew*ZodPE@QVQsV8!4NVHstbR_V^Av_-SjDJ
zo=b56)U0Yy3?8&y@Svr}19xn-_B0u`=B2!4E=-IA6@x_GK5`PP^5rj!VC7dVOu^FE
zfu%{EuVJ}MV9|b-Jx+61mbT!UF;AXO*Rar=mx>QzIYz^RFLL>R2!4#>Bi>f!?OL4|
z1lP65mUT_mI=~8NZ?;f@J042hez8R?S!kpb&eL(51@7=U{tCF@I|T;!C;;D{0#|_p
z66B+B0QjM4VS?=<JH}mTQ;!0ZY!|w~W_N+mMKVfW3e$3qPVYr}l;odyU8JA$1y6Hz
z;EOUh@Xd*zO^%D53cVEf=>`(h9Ewav2U5OJuqB_lfWKzsuyoNh{^mmtC=ujuO0ncK
zw@8smj=U1zb@(#@zi8V-@g=nGNU@}dFYb7&kWcXi#w7L`00%Qf_AI(wdBZPBHpJKU
zpmS@D*oqp#bwc=Rv^l#perqu7iufX%TkJGN@g*r`>hGfk1tbthp6%0VBB|OV_p?hD
zhbRjyW-$bG6j7cgzRZ44%P-!4U`cO@;4M@@^n3A`hI+uX&F*tbiik@QZe+X&JpRp8
z*E75&xkRsIvp8mEmdR%62_=GYM>J0GtJ7SKPbw+mEI5r%3aI`%+i-EsKLO?cDE~(P
ze)TXmU7%QfaN>aviV(?Hg$AAkD$CTXXGsZ2f-lk%6`cH-GyN5zU=6--?mc#4y6OVK
z5V@cA-PfqKF~Q0&Iey5EpGoQ`B<Ep62uMh3b&&UC%qR4!ZIjE?6!S?b7WAvJPT}f0
zno$C3vQE*neg8V7`PG_{mclTJ53fgBnW}QqFq12umAbd+G|)-)woOv1ztdeVH8iYO
zoLOk-s_WXMQa@9Km4;vtW$IH?#^=qY@3LRzI54sQIa0`z*8g0j;XeKd3nwV`{;Q>K
zlat1}*Gt{)IxS5XAX2sd)>dq!Q!boTob4mFg}BscPXWLo%G8pFc)y>Rj#RT@;{jtB
z1H?T%>3NBXe7;})vh5fy{4}6FAbKZ8B;iDH69*Si5a@9=cXHuvXTcB(CY=?-?Gp9m
zorXPkQn}CtXRqe{7?d3AE_r8$lB-s84$_*%GfQaJm$5MCC#_{&c#ykr{4^MDjjZSR
za6b~`qm3dje;FLZF+SX)@y6y<PX=^|1uzqa+N4OEmNNC*JKV#uC4;);WOvCQW+=I)
zn)H&^ECdLeU68S`kdnY)TGoZX;w~J=DP@<LY}yrL%ldN>_$$V^pgzf6!-!Qf)7Y9U
z7A~te%{5~m-R>HqXb1DRnZhLHGPKO;)u{bVkHU5PxQ1h^3RpORmO*AH>}&C>)$YRR
zzPfH5dJj|#lQJ-4pv)~j%5bd)DvDiYX7wl|Yd6@Z0JF#LbW>mGQEUU73LayN!J>d3
z58mb)uRz7sX`#}PzuBXVtX2b+F7vA%Ww?3+DX4U@sJj^bXnS0EPqUet^<0oz&yEoe
zy5z=%U-86$j!{*V2Xln|25&;Au$ScwB_H7lXs6;F^Dh^;j-!iPOi3h4su;oHhwv?o
z9oErK#jUnqy&yMtO;Eg1OrI|4Up+|no?}*!lt)9LQo0XzD$;Cy)kY-YhqQkc{=#&{
z%rm8A+8w3;EA|f$0#*=?u_C98?J0gLc4jD-ld=Er?)see@Ly^?81JiCn`yJz&Hmlp
zIB)wi{tIAFj3AmrTQ}Iau-GZ3ouT6?+2Ee(S6fdNX_5G&(~I<9(NDzaMs$ypfHWDQ
z^Ti!q!K0v;eClEF7wa`&x9{&YU$;M@*L>Z6L2vmk`*rgW86n2!vTwuRRlNW{PLYED
zrTaS^gcG9icj*3@oW<`mlc1Anv<N=b2iMSL4i_Urg*?bLmt~7Vt~koW6>{TW87=b9
zy9Cm`ABrP`ElB-v+su?dgm$p4Rc{mn@+ID`#b@JbQ8_3*jm`(JeBp2xd@GIvhVwV)
z%@`pfnHhI71Hl!($Q9(<f(;^;Ppyg~875S3-9bFY$7ae@a+i!SpEo%WuBg;ocK{Fk
zG0&cSu9%(MZVx(FV#_~gV7q8@yIb`3vCm!EiCk568jhB5fqCY@cJ$baU7;s&wryf%
zsh6!7{sbett}~l;%GHjUMN)^0oY!j@^aL+b)~aTVnyw?b4-LnOTD1$`bkBu1W;2)(
zuXZp5O}kvLXu^BXLy2RaWP>N|L2EMTd2GeECo%M80tNY#zj=0Uhv2G_tzInojrxS_
zd!t<^WO_b`c3g@VwBI)(IP&R~o;ot<#~1X}`)?%{twW8ObDXU+Y>=5;OE2NJLU=7p
zlX*mQw<gEhCeKW7lI*liy$()nT@3mC@-V>=ZsgQnC1eCDX8N5>2Q{a$pIwYT)&_|S
zk3^_%U_%{fOY37f`44`RjLX;FHFEi+j~VBU(HCG<-Hc=`0i((Dav`*@*2G;XKt}|v
z^pvU9nTn~z#ZoL=7t1bF-^x_1jqxwgS|44kPnnuwi$NK5t{US=y*2&^pp0@ELc*_3
zvBl_~#fy);IMR$x<>tB8jSxSHwwSabuviN^WwC5s3=HtMwpa^%N6-$a41&z|^$VNp
z?yJc(lI8S8^NaM=1b2x9uJaf)-mcRVh-a24)Yl13&YLobJkAyFDi#6veenP7fAx9h
z;{RLz;`4xX<UdAl<@P2tg#R+MQzz=mDH#09As#q2m>_%7D)WtRXTE8U!?OVZD*wgf
z#%=RE{(zcJr2HT$uY^9RjU%cw>>K%;k1N?0LLhCYEzpjc1vu7{Nv0@-=xy(TnQz--
z?Y!ci>HR$EzgYUf6o5V%CI)OQ+P}n`zwAdCDnyqAK|p6vtPKK-Y{PbDhz8YzLjMX6
z+%zy*tgQ!y)@Lfl(WF!8I$MmRK|A1m49UX~L(bk*#)JEk1$gGG3^Rq1L9542pc8sR
z9KRI1JPa?qjhEE08_hv{K-))ZVDT|5#wa*mEEeoxVM6%#48^iojFB&-M;`F0r!o|K
z8{2g0lmQ0NDS{H-ouSwZEXGcG(Hot@>h8}_Y!!>K(?J|&xNZ>ce`P3kv+a~&ztAa8
zVX`w6yGS}kGsUnF3y{STYAyv~RUGjZ#Mh$^y6MC45zI%xI-RdQVu$5Fcrb@xC%Z<*
zmhA^e19CsoT`F|>9h{<eBZv5ZNQJy`e2|Ruqd{dVn4#Eu7Q;9dBVXZaOkqGx&roa$
zi?LIUTm|F~&QR=f+o@;@;g4_;<P*6j;#yI@&iI+OQ+jftQ;^ZF48^>*Q%yz+WP}H}
zdW>{0R04RyyiL<FCN_Sm9`LDU>h27sUl0p327I#a`{aP~XDGIc#W>(1nOIc>`&EWw
zH``8+)15+kWoIaMk?nM#?sQ;4y`%RLDNX~t(8o<WJw|tWj9+caP^?|-)EH^5?liZ|
zydRs6<((|Xsbxq`M#~H+#H%Ix;(UZnIvT1w8tPYH&Ct<<wxhwiqrteJpP|_Gwxbhu
zM<)i<A>C2h=%(0CkJp_Z?^kbTD0aN<^jO{Lv1RHP8Hyz|6AG*Tx>LkJS&^aGb{6A2
z_SK#C^{X2)6yw8!LOc}j-tb2d?=Ry~4C3m3+tD!H(XfCTmZ1g4!;p?n(H))QS4rJM
z8WJYij!x1YorL&38Hx?Got~gOJpumi8H#<N<w*FWeBEijUxhOidzHnwGzRES2jG5I
zhGN_g3&Hf$o%Rc;bJB~!F~2hrl417IJ@x@Ulik*&mYL98fOe`R-mrp7a(<>_9Tcr7
zMx_JApx~Tfi$N%M@Xd{sfPMNCpJ#K2&-4DLK2ILF;6i+_#`hL{tH1j^0epW8-)r$*
zhwriYo`LUg<NFDG_rdom`2I4!@4|QUfB8HeNGrzoY<&M3-@nE80hAeq?}zaHV|>4X
z@53l#br=2>eOl{2W>=I^Kb|8x4#IioN#N%;OsnWPw08m5)Ca{+2XBVXP3ht%2d7;r
zy7=F3AZneveacfgL1iy?U1-)NgEds-*@Bu0_cPcxbVTm8;3vH5pTGP~bZ2kxQ)Lg8
zR^wm92?@=_XV!v?)BpsGhcYZ=k_E3|Ja8k=SYfj*JOo~*P$hTo4H)N6h)yh$KTi`?
zot@AC&}_%otjE`kEslhG!1ypCd--Cp9p8!R<3pT>32OMguJP%TW_)Nt-89`bzF!MR
z!Ip~Q+O(+jEEo#9fr^KNHRz_WQ^G%%`jrm3nrPOcEdKPF`1l7LN986emJRT+hxp)2
zOeuUc!hg9tKK?LO@KMu*3Be|G;6w>XyUU_wm!O4ltmzr<;XU?sDYSgiqNVG)v}s4d
z32MM17g}^ljTW|`N~gKd@)Vf|Rf%?3ljq^ODlUEFUY59!BdG)a#)s!cvT@1vaHMpD
z?0WEm4@|uqBw_+$+A(q#q6yV%WW7yf?F3&$428_Z^E)_t;%b<tlqtULKvpSYveg1v
zvbqti5AQ?lZt-j4p+c1%P|sc@$a*>FDj@3(Agh)%w8bK8iy*6X3qr+&m(&nhr=y^y
zp|dTr-ncdmStvMOy^FJ!de3k)fa`C%q(&B7P{mU<vY4L;$%t;T%i%_hVVndH!^0AH
zm8%ZKv_U9DEQ@inNyK=@?VeJ;2_r;+MBhdRIdW$qTxHa^F*Q==0dujLmw*LszEB42
zDAg{8a+Lf8s}*~u&&yA~WO4Q5YtnEf{Nz`6y9i5{4AyY53P0(%&_!4)vEGiBpS<$m
zKf_PfUhvQGlbLpWJFZR}pYW467P!WzOPcYKpA@>s_Z$}vL)Jm+AOsQE2F`^reONJO
z5y5>B_b{+u#JX}VqAhZ4gGGe%pe_IGB8nhl4LOdm+bKSBoYFlAtDRazjkvCoA}zg$
zZY;^Ph`Mnc_l;8bA_`c<#lD_~IB=Zt>U)*0MWjn=#K|Ihr$iIR(JZ20EZ6KIZKX^p
zC!0WQMZ6K%V-cmZi?l^_=lPiyky$_8;`d_b2n$9543gUZ#rHA_J(VYL6;%$z%Exgo
zwhqr@qmjO_(hnc76^3ZUEnhMrx1j!(#b4=FY4}6I3F^v_i|};GV36!y7S{LA*Z7lQ
zS>pwOLO9p95aOd0*>jf>tq{vvM702&4E)!e5>d^#3ea6dojoOOi8Wbv+k~E>k~Dz?
z<$_eY$iBsn^u{aGMv9wM6Vz>Yxkjo>nvrse{c?(Hq+gOPPD*4WA`M=`q@01^W;9m#
zQ$cXkPggIrq=d{%rU~v^>}TdhvNFq}8DV0jQ45|a<&7jVT=LoltO%kceC@8?`^vN|
z;;tR6dB|kJ%1a`+cS06P=&A;boCb}Y1_(I@DD5V=7hB|9JU0zFC^$it-RVM(E~$|t
zf_u$m7ji~}zgjb9VHW~$`oLx|Qoc-pV`1_as5FQ^0r3qhdHG=m6}CD~c*(QmJXX`8
z_)c6y&&&m1ant~~v8Aa2omvfmjcdJ24Os69ortqcqXr;;P@5=EZHZrsJGYmLBn;cI
z1~DqwA)#1+dlGd7o^Z^I%=RCy@gqIXBf}%B4v$uIy0G54QJvzeCD*G(Xt)&D+k&XM
z-MQYa=Vs!1V$0_}`Wl%ohM3zFUb2bLytuetkPklF8C!FC+Ki#>1hozaJXU*171om`
zyzjkp^`spQ?|T6rtMaIcTT7TyzL8|PG2+|MllN_i`ZlD-o5uSVoRf+7x%MNU#sB7H
z<bTH;J^vf+=6^x@1z1d8Ql5rMu)vAx^4n6hpDG+&<#55Z=eWrKe%Y>oKY!!MTb1jV
z{xf{<{7D9P@xjivh}#riDC(V?blk_jnk+YI;<S-Prnt!-><hYcliy90zU;QB(Xx?7
zO_z<}LA;y_x^!)ef-k$U*?CzSHc@t>^1|$FLs_K?8*Gx(etD7$o0G^)=(`FvM(+i*
zy%{c-;J3nFO2J-^L$vF|U^KE(Y6s(;7cB>SISz4s4h!8HPRzLLU@tgk_=xeVguPtp
zFeq5#(-;&O3mFswc7dABCQSAhgHj9%jkQT*ZD{P*hP7Zaz*@lCyRjCq97OWPJk6Qz
zW-UlY8aPp=E$!qboVx}q9~&@t<qeT?zIAD~wA-;w=`J6SKU?OmMs_8&b_-W)r?6J0
zu)G$Jm{Qm4##*>lvI}BLS=tn$>;&bz#l>2j!g>mYwJbYZPhn=(Vil;8QtnOW!V(bi
z)o@E9heR0FxNTE>HDsY=ePAtVS+bAWlo~Iq0e`XCer(20IV+8|7=0<vI6k3R{$`*r
z4+45z0}kFRvCYPZ*=AFQ^0)>9mSQ_E@t-)I+5h%E*v=&_;>59nXIs1m+hJ3Ao&_>Z
zjsuyxPxws#SZy?Fa<w^chMLDgr=T}z=adu96SU^7*&#d|;#m*Aan@4_&u%^(yc^M=
z6T1_e?3cSk-5<ju=HOK8%VL_xF1P@}2;nX+;~eQmLP-O{Rm(osTJ#~E^Ahz^#-njF
zZd=O5;IqdwsrT{VvJpmt@nBROkC@^5Cf-cE<ZLAk{Ma1w1f5M`ws@uzfxnzD-Pgg9
z7xF$U=8h;v<0YjCZvxbH3r{C#lJ@n9-8E=0tWXEt;J_ZS5UQ7S{s|V9N;;C#L1Jnr
zz304%iOARmn@4Eu#GP0u8&kH9;8YMm(EE&7xe6|IEfg~;246GT9s><L>7m!a5IGnf
zf*n|*fT<5;;cS>uN`%Y7T&P5SY6&kX7JF1XUW6BWTRZ6uwg8YCMPv)?pp0gy{Ob3}
zfr-snk19_xVH?<b5`E&}G+vA%pd~CEb3T;=9d%-mL&jCVIWh>$5QKpGksSW;yz3uC
z0gg#-loSBiM#aS1{V=9oiW;}vyzEqe!B2VujY3yA^B-oSMlk8WBx{SR5NMj>j9sLA
zV{9s&?^jokm*q<rG$zu%g>mwXt3cl2!ARpslacD3%n-+~pi}V)1&+9{^sy&#7NgIK
zM*`Ynv|B%Ti@&R=3DFLqTeF9+n<~HWLVyRT+wR3{?W0F^UzDWh1+~f%e}?<6NXPlm
z;zOj7RGbb?kLI>(Z~j91{bAq%4V1{}h0^7X9-ixI^q^-c(p5C!Tn<kz#C98w-ai`u
zBT)4@+dZDUr<ot2JMiNyri?H@Lf3)OjSXFi&v8g!a5a9M!5?2v1n_ereugecT#TOz
z>hs;B&5zI+{CFI;+7KK1>AR>f96w&*kAaDk@RQ+_Lwyr?dWpeE^1>}%#-o)3cb75A
z!9Q1OZC-m9$QSWc;cE_Ni90ikP0CBlfE0wqVB-D!ZPTk<>HKZeSGm&p8|g+s7!Ivp
zuj<TQiVHWLcuNfcR4*<lE}*aX2(TD=jLjQf+<%NGbOOTv0rzz+bhC}l$r{t%1@>XS
z!;7=9*he_6gclc#G*xUX(V6{60)WH=tp4zm00;iXRP9`3;vgl(zi@$zqR66#Oe`HW
zl9B;6I=u>YEz0=2y-TO}M2+`fiW<r=jjE$YjW-Q7qV+nc(fA+|YUt(x%LAQ^fQ#yv
z_{|Fs`OE5<1Sx_`cKORT@dG>`7wx8C+xH`rXKwUOV%7@M5OOPdrNz>eUrqSChy$4>
zHeRNlZ_ulm-B%&S6N2=^B=UFod|jXI@jIZ}Kh^cwBJ1P5aEaZ+%aW)SSPcJTT}0%M
zzR4I+FFDmr2#L^b0wiaOK;B@0T#auN4&ni)8A7uL88#fmElv*MdYm~X97LIuL-^RZ
zUtMInP7x*za^fD^i2{r?lX~f{GdKS`qeaA+<x#!3zg{tO-E)o=Gm9(6uB+(mf-xM%
zL?m(~X1OsrpnlUKD3f#!de!Q6=r*8!q|=?!SXNkO1@4tO(o=b{yI(x*Q{XO-WjH#x
z8bZ%raG^I*aPkjDl>5Hy7UdQu-OIG}UP2SPt^bjn`BU_0EUkkrjKuxFPh>Q4`m@Ls
z`&F|}a>S0-7ib)(e;fUOC0J<JQhF$Pb2kD;as0z=9q;sLT}m-C9HRI7$J_ehoxJPg
z{fgAiP(B-C({$xmonob=qL9sK^$<W~e<w6AL|3MUX!spCq`iv6!HuQe<At{O5`WPI
zbywTE=t<ZLhcdsK2X7ouS^kTBM;pApHN0rHr}C>6Icm!x`isInS?EtcLY;(AjZ#fO
z(4*M_btP~lUL-9j1x%X|e*;kaDP8+DD%-8Na|x>>gTq(msx^Bk{#$wr``3g2B3wM;
zFTwgsHTxSRP54I9m#d^ak9uuhqLhhRe}((VBsqZ2;l2TKiVsg<d&ZGS3N|5~;d@}k
zErM*M4=QCDg3}EZF9k>+M=}b2v8Od&OFzGw&h0L>SkGr$fx7E35LN4kMr?uy$+;=^
zvunJ5?x;&U>!*8xDKbXD6T#Yn!+w<{bVe>gpK!d*(K`lM(eR!n?%kajZ1^$u=bO<0
zTqw~-6#HvhI&bIi0E+X24^jry*;<6*;Tn!)4m4PdmJKlo*hMT-F)dhw<)(tVIn?|j
z%0_3P83b!bGpv}9%p5dBqz%-~@HHHC@hZ-$*(lx^T!cnx0w2WUTs~v%ura>;%{l#{
zjh^%pGClJ6A(B=V(1jiSAV4Ix3OMmVEd*NkO7tEm;?#5Xwhmz>VOGTYmHwc6VYk**
zv{01DB)9mXL3j+0Do`jNbCZOIIRq*gx+F-;$ueQ0r!ORsk&GNChVf-Vq+1|qC@SFG
zP)A1uAo@)N{l5frYUDrOUomt{XLTK?E}%BU6id?Kla$!CY-4H}VjTDia#`Q6UTk9l
zXzdq%og8OS1$b6LAedFa=`N_=#!_YK`ad7;GBEB1Vo(STkOKU{Y?dr7sIFtlfI2r-
zax+U_C#|q(nW_+t)=T_WAmY7gL0x8(L!+d3O<MuDuBQNauT=ox61ouxls7d>F!~Yb
z)HV9+UjR?e4UXA_KLzZ;gM7qOPMAT?MTlz*GBLQKKk^AR3t-A{0qTM;ae)+wMU_m}
zt`D#Vl!4Z#XP8ge<So5P7UQ+B^z`xNeQ(^h-Hf#{zceX|Wey#53Zn3gdiE+=bjBa1
z^7#2al;D-3EYNpBq#!Yv?JR-8S)bPDnY}&lAtlx@FT-0@K7DP%zz1pvM+vCk!i3A2
zPWH(Vl3g#{8C<!Hqc8T}RN-`kg)pOJWLBZ*LE6iqgUbQN72VY~y|lOkWy2kj8F}1j
zR`dy04Zhf;-fzJsk{!WKo#+km(mBGbRqthNEWGZ9N;ACSmVU5OFvyYSE#0>tdjC<~
zM#UrLQm=L#(9CK%&bzy!@^5${o;=U1Uyj2kKAPxB^w+;hnHAGwG1!do(DhnoV*`xM
z`Xl><m`;ku*oXl@<~_bW2iwB6tWl;Lms_BF=gKtVwS?t|F`(#L)(bBJZqP08&Ib#n
zTmI(KLAT4<h(8)*5(o^Qo~PJu1?u`~GH%^%DZ90R%E)j)GvD@FIZs1MjJ}?OzBFhN
zzZWauj{r!ofJvbG;Pv<iScN_W)2Xxay<GFsZ7w;0U%jf#in#a+SrKtj#{?hfCA=>?
ze|aHCY7opPU>?L6EgX2M$c|5-1*!i9?qJ~bSll;Q%z48*vo)?Fmk`vw89?QH9Pa`Z
zpaWDvu;Etf1PkjEm+RHLB-O#*tjgO2xeOnP;X*Q8m&)Cl<?f!YNZm2T?jIFjea#~?
zbid|9gQ`<>_fGSmXUs+Q0sfo6Ok4uf2m^*shcNiN8(}a>6Gk=`44I;CIgK!A((XYR
zWtThT_z@?`PFwZsTwuBt5Qk0=-ve)`WmTL!feuS=AXlZ%jZF92ixoN{fAg9wk_g_;
zxCB#{ho6~nb{(L%)Rh5e*MDGe_Td~&Uc3^Z0ShlAF;O-cxIsI|>DF{Y$@IMZ<==JS
z6<ZEw=@6EP&{t@&smRqJBM~CSfE}SN36$G1lASV=lQWEjt8(r9)JQ-LAU;8-6`+s(
z*^J~=J(9$|{|p+3XXu=yH^|j_1~i^*J6{JG3AyEvUU+X#C0I|8R0T|t<MB6s0?Ygb
z6#(x9L_RsdTW8zy=*VZ}1sJx-i+`)o<NhppLHePSQW8U;2mtd2Z+aCpkNKzR2%H|8
zO2CSM>x&@*THdA|kxZYE;&n%F{fzExUf{tsSPa0$-#_@o@OLjqv7G;g7ivbEgWu>@
zM$6x_o)*SpdH4<f&Lqv>f7NXHJFBPhckbb1Ygq&QUAh3P%)ZR5r^@R<@++LVTJvkm
zP~|<5Z}lJ)Hed<m*7psebOiKVt(E2>=o)gOG5*F{i#mxdGJzf>+X>`vK!*wBFFk<`
ze@jiE!PiC<N#V;#)}1+AU-07rpDm9q_oD&7N&pRbFX+D67}SrQL2con+VM{;#$o}r
zCg_YSww6hvA9{_Tcx;~;)~RM#LRb?tT)6d?`cL4~_VQr>D_=D8qF~`>2qfa~N#P09
z{?6wu;7&io`W8dcwHW*dhz7Y-grCMBq5bq((!YkPUi>@wj#B`MYA4N=2F#>|ih@Jf
z2iMbNn^<{_R7_l%m=hesT&ylN*nwaIAi$O(IKTr4e0gT9i!=aKG7%9Uz4z0N6yi-_
z)_-}CA$qxM*j-^U>uXSIaw?9A!QNhRrBpsO)%Y+zCB&!wlwU0nm?$<)lm%Wu5ghOO
zSmxfrv9ymTUNB4qye9WWrPF1*Fxse_rx9(~<-lj6fI8tz^Q2r!yX-x6K=f<v2He1l
z^Da?roh@n*U1%SSgMd<eF!1d=2%kzE#$fk(VEW=?c+wd@c-4K!V-tgC+HY8Vrp{Wl
zbhNltP=R&Yp*x_{PLk~;UWD4{STZyX8F<E|@TcDT*z8Q(D!^WNS5VC>605)3imcq(
zU<cYuH-@KKp`NyIZw-SHm|R=hKDABuscm?u$`cv~_YP+Viv4sOF4hL3Ma@6?iid95
zdgD423x*q42K?fGECwUsG8$bOya2wW*m>qJqxFlYx{J^-9#Cj=cEZQXS<4mD4ELl6
zL!)*=J>~r1rBWDvz^vN*(Sh5sPv%txy~F)67Bc#kR~teTP(nb)`xhyYCFYGfBn8<r
zg9hHFTTUFQ#w*T_m^H2e?GqNbV^7u_;*-cj5EHDlNjA9HR3nH5*)tuiu)}Q@JouWh
zxoHlV`q<&h*$Q{FxXzijn<e6S+fz}8?kXxy?Q?lg-RyJeKGPb>#_pjUV>GM)L&Dx3
z@ipGU{L|5Tk<PcfOq>4}^3yh~Qmw0KlMYeMh3s>0DfMQRjeD{2c9j~|eLvV*rcTF8
zM9zLtR^<6@?iHC@KQyj`|0KCFgn=iS+7fooFYWBMC0sjO_!c%#5)AXi`973zZ3#DK
zC5pK%?2v6?r}!bswy;yeQzR3Qon0#{$Mj#IUcgN=ZNGuxgUf!~H#A4rqCJTjloLS>
zCd?)X49Tq^%`nh^(h7G!rN&8Bhu#X-&wv8PVZtn<HG+1~HZ=m;cFNSPnx1gKpHP&x
zM`q<!AUgV(i}8TsT+9a-W%ekNQwR@n;}jK}Lo^U#3^Ke>w6`CvcV5@Udl_GKTLEgg
zSi+8k9_(_8dsTz4XqB)5EzQZMFVnW3h?b+G7laq-Eh3G4SSg}H@V9Ic7si%TA;4aZ
zNzf!He?iKIK2Fq%0;w5R7$P&i4}2$0?+|Kz<q{*2@|VjEnixS8^$Dt45=~p>g};sR
zVpS0)0RZ-lrQ-A~>Vn3J?m5VwEx2r-sGngwuAE|(n(CdhPn7zIz^suY%|~WgEky7W
znUNFUgE46p1+V3B>-QQH1jE$ULzPh(N;JT2pFx%F`|qV3H09T&wr|<>iNe#fW2pxH
zaoF`jqPk&d{CFx`t40>6#EcX~S$GLR(*5eYn$KaIH{8j8JxlithA(=So<K&yG8$g`
zMvc}Stu5Lee1~gp_}k2l9V(NKhAMdAkxmsD=#OVPM3K#oHH636t(u?-a66=Oj=@8=
z*`!GUY-9PCLI#LRo6MZ}k2zU}$}w3Ldg90jUcOc%Su#sz<W+u6*X50SO={}9vTern
zLDuLAIO>ieYd&X<c(n^u_?=X`XzW`(Fn7zB4dyCKHP-OpgISxZC0C>*z&^{F<elU#
z8YD~cl$}6W8dc=j3T6-0&It!x+(Yp<euDP-ORHhN53~xNlXe*jDvRa+YT}38`0tEs
z1n<Ta*E|2UTPtf_(~&$zYD)&KYv8PS!Wdhttl-A+4kOk4GN%`Q>BV4N{PM9648J66
zQ7iD(gI|siWadO<!D|fLl|hDRxfXwSTN#F5l6a5EFGm6<XMPC?w~(uRc7Ctb)JSwx
z4$(8nUBAGC`~LtyZ~V`)GszB9>suBNBE?&BOl`Qb48^fa4v7>ezsc276lWniIMYJp
zrZ^d$`nC%Svj7E(6gQPmgyAzQJp8($G>0vLx5}nZ*uSAT{?-)7Uz*~6|9(b_GxX+F
zufZ0clJ|^Kw_AMit?f56!4-mtJQExuq68*9IF>b!Yj;z}t^KtdJzZ=%U(UH#lkwGq
zo_?=&UQ16bXyq?4ZRIb2cay(NvO9T~6cl{B<?l+M%%LZ?FY>oU4EWq&&eRMwpm=a1
z8zt}wBVY71!8k^as`)0v0UJ>f-f76lvJk2!M>T7w?&~&dGG77FZXk^T2-KTM|E?k>
zhe6Q7aLCh1Y0TY9C**Lq3DEUL70<Yzp8ZF184j1bS=W9V2HezYqz-(g93*)4IaK1S
ziHr4?m^;aSP9ww72u{lMmKa)jcNN)gf`2_<P>M|)^*q-m*wQEVif~Z%b(+9ZIMI-6
zWN=)>`B(qDPUhATDkwtU_$FXyUb0&@r~ML5qT!@kH0|YGjxDBl6xmSz=7#E>9;l)D
zn|H%wPrba?E(9W=!_V0+MsFz%ild(b1ecU|gzQ#X>&T2zskh3S>ppaa@a*)hatat1
zzjqFTj<`$4X<@nEB;T+YL*^!V-qHeYlB?_9!ji`oht5Q?E-`)aNxH<vOOMqh4ww>P
z|8OZ{W^8sge5gATE1Zq9#m~{f^RM5v+xb=#VZJuxkRE?&(al1kn2~7p3g9~potnSE
z_=4>ubd}%zLCRX=gvGa$|E{*t^_u^@NKM!AcDMGwEt}sS`COma3SKW8#v=#x(&KID
zvLMJeVzmcnf{N**fmqn;4ch*2k&YgIJS@fmF3#}!)#PFLuGk{9cu0NY+u@OVZs;8S
zVkCVYo7F>a9+HT@5B!lH3^1%>J=ud$#7pX+nT+MmWj;=%zpPem7js(Q9loxtL=OJ-
ztSs-sO9<u#1XOCrdXY+5QmH+0ym8lLLw`Ysv}ZUgT;O%);~|7ZNpmM~@QthQf+CF{
zh3gL3*#OH?KCgP7$Ohb8)<IFYKIu%R=uwmEis;ep8GlO6{J}5lr|VrP9{Ml_WiXm)
z#I8qjarQ<=+qq*#A-AgTCN;jhf}VM^JU2bVa{ho(l>FcxH~o-Fyg^*ruBMS)mv-C~
z8OX#d-OUJW-QkN)vr&7T>@@f>#K<f@f#P_3rjIW=&2igs8qoMN{+^fx`G$WdQ{avI
zZvc#cv2FyvxIcr>Fe1ySZ^(hVy&jI6O%6URs^FGzJWB7FUYLbU%npul#j!dgeCXv&
z_C{1|D?TSeBb^hWk?s(R8G(Tp9_y48cw4y;JQ23HPBk1L^W*?M8$V_f3n<>H8HTTO
z$281edW#w#6KnBQ2+W;<SUIizhI`ZkEUde<8d4r5($}lRQ~AG&9$Rky|B@aZYTP5<
zOaEPJbg!5HWAu2XfKK)7bJF8RF;g4`J%-!hNrKG?4%nK>ja_zDCz8bI;Inr+PvQnA
zqgb#?M2^}yl<UO_mVwLP6V)FkyRJ+*g@YZaA?>I_c+WZUGJN32xZ|QtOtI1@)wx(n
z<Og(I62%QMC$UnKFj(g=dkhfn@O6&e;X5>Shwm^f^7JD|Q1f-x-KmkU4pyEQD}RzN
zZ=)qXw4`=RHpJo{-m@h`LR^V0>~6Dkw<Z1?j4E+X%=aYPYotF8cZe^GNfDH@OWrla
zyWYDH8G+TRq*_h<0aS~ZgPkz(XGD4}uCU+@qgFr)(e|Wz5s8c^2IHbabS}h=XKF1{
zr}$K85UkViKX{T-8$Q{saLmEUMQh>>+O1mwOG7|Sx|O+nv${hye4A3ZL#@8;5TZol
zVP)Q1*o6Ki^>xX8Qtd<Qh?Njm0z-$oAEhI{jjVV#exlV_;R@W!lIxHy5;vlaP%*wV
z?5BhkSIYovJ5vh<*7nc>Ts_12$M*$R8D}jl=Hp7Y!$ENz^x+LS=Bu>Cq33%-4UYMI
zwHQY`_~iziI3dXV$YX_9BL2}iYzo)YT5y0Nrzh~-ljD@OKD?0H7N^S$p*{`+1C>Ow
z>wV8^#CE7Z0WAcN@vWo2XVX}(NC3nCZ%G*=ETuO9N}==yHWu|Y*gM9(Q~G<Sq*3~I
zQhEZag>yMD6Qz&E*3hB!%hM@+mzoXPE|gA$^O7(q9kD{%h0=cjz-q?gAM9j0UYaUD
zO8-9b4O|^ea;rg%s^{{FNvsupFAh|{%TRqgss0_w2G!Swm(&W?;|krgyarPzT|XP&
zW~hD_+S>xEZzt7nhd2ej;hGy`fMBukX4`sJTPfAn$MN#HC;k<gn_cSHki$X^o1A+*
zyHqU_F_WaE7NMjT)_)zTQ+zF?`WC<1^*uxN&6?_)LG{pLn*qzFfVv3IdYbCn)Eo0T
z)otntJaOev{W?wcZEBC??ow@NJ?dK*{|k`C(yLH9;(L-mtML=93e|6n`kv(V($bBH
z5J;#B1=jQxx=RfeSXJm=S)s)mRvG68tkZF&8+RYTbBm<=$9tpu4H$_6-9HYxho|uA
zCm6cF>}*5#O;|ak`zE1#fV2S#v7AeArWMCEUK#U=7#%d%NLIaX4F)D7+Xvhb@`K<{
zQQsP<H1M@J^$qvo5LSTJS48{Kca$r*hRSgE%Z>Nfb_qdKB`naEMYCQ8$w4d*ob%M8
zzjt-vFuWMkEqh~m;1tgTh>PmiSfb|BE*_bm0(OP3xA6tWEpDa|TFLka0GJs8WLW2z
zi96>-@(RG3k$xr8(ZQ=ICfpi_()zYofw~CeH(Gk-DP2Vyu|e{yD<=`?9CZh-Y)18g
zJexTi%}nuiE`Zl}XTbJn4!A<_aPCN4&(r||UK@YbcCd9E)V85Rg?VB;#KJP@b#mVf
zOfbBp-BUTpcHA;icbvpy?NM<=Y{%Vs)XP(A(Ufy1&{3Y<_}79cZ4S8b{pyJ?k|K)D
z9Q4Hh%Kd_#p~OG9hsWSwy9m!_=M9*l6#hTLR~r5)g;?wcWQZ?5Jc{}1s>c3&J-rV0
zWsiglT0p|IOxS-%F3RSpPbQ>ce<qsI*oQ|0d%ID<kmE%c_D_{m!TuXE5lW7qu|i-U
zai*R34SHbz8>Zt$(lJl`+Ie8jzJ4MUB+TDM@16A+IES8bzh*>*yF5xpr{#>xs!L{@
z+_d%6i5+kHX23na+~-Z}Zap*g)Avhua!xSY?#MQB0xp%r5P~4jf<<`i6hFZ?(Q?F(
zJt{hPZHx?&8G7MHT+|$_bn;sq)9S~vlW3-7R*ox1_h8*!;%#(~N;tXm8UQ#r(;nhw
zie(M|`g2MG-Vps^&HxDl7@pMMj$07i1LIM|4v2R=xtLRtqlVRTBn<N2re3%mEUQ7a
z@eeGFczvNwy~+>32DgL$VvLBt!wI6D0;jhaB!42j4)49di3nZ3g8cZ4sX~75xZ~;$
zGHO=!5-ho{r3*|$ay!%4!GO~372kA#qJ-oQ4-#$oc44>xE~!ogApCpLD#{XG+JGTK
zf!TwzCe<K<32kjUKgMa8F&~5trm$Gf!yFLaE@!*w00ISh@cgT{3SUzFff^Prhh(Og
zimu?g)PAeS_TOwMIW<fELY4#LL~m9AGhahuWF^;)6$T{&ssq<%#+Blo=?;scKNF2~
zh$)E8F2IGsWRPCX7FF1S!~Oi4t#$@G)i2>_K);6tGkEXx#=jiknuM66^NHyG!3i%x
zoxdIb#C&`gDi2~V2{8u+u@bn%Rv7Omj1#Pb(f|y!IW{#2P4!`*C)}+K(%|80t@vfM
zhPw+K4@d?r!b{`|+uBgw8XI|Z#UWT6N(<E!*seoXGHn=LBhs-h_yNABrSM(dwjF%b
zQ3%^pb{A~xmp=`&1$as%_Bem6<-aB6-q3l`<@}ldqBjtWv5fjJ$X%_6oTBqYfT*wQ
z8H-5q#8%ycJb`w8<rg7h5b%16v<-)J-Vv7l3FZ#(qGF~C;_p*KlmdvaTxR-uK>Di1
zNn@eT8z&7#V#@#t&kXq&h{VYwe?``Y@NX<O0spG=0T6qE1#kH}B;d7hO1juu=9Z~<
z+JwSje!Pj&H5S8?=u+kA(EMD9pW$RzWeEreb#-mUZfIj%z7Ri5$!StaIxRw{@DoK|
zT*nnHP>*068(EH7L-ASoSDp1Sey-hxpJlP-O!2FC|0=*lmaoRAl~qys%HNt-5I%55
z<!A{AU$+m(qb$T^EZ+jt=6JLjuLUA(*!XBnmnzH(A3URSifAx(Ex@oldAKC+Zb_wL
zPc_gq`8Hrm+|I#AV??W#RMNR$EfHH0&`^b(@Nf99Cp0-4<Bv$}cKmBvS%X##noh<(
z)XdFaaU~?WoW<e^0By<!S#~Yw3iB`1(HB)PLqW_C-Tz+!tx!Nu#U-uCa$eDn3Svv-
zcjcJ+<+mUW4ca;UG3?H!%X_6u<|po*xN}A9yZ9B8f0ZA-M3x8H92(C?<I%M;UpcEI
z%Wq<GjG2K7oKCURagtjWl{~~Foj_x3LH+XUk>~3Cv{dJZKO(5icXPDTc4)3Q)_2of
zwSbfL3w01%87vp@ajZ=+Mrcml+#HJy7rL~@wQlnG{}uWFGFjyRIr*=<bIX4Nz<*!<
z*I4P%rhbo|IplvHH|<vbzsI!yG5NnmB$3GfbH!```Tt-h`9GOpTKWG~4fE%e|DR%k
zb(2IcdWJlzP06Dp$^UD__x@<*|9h}$V`tQh{HGzPclnQ-%#{Bx+8OLrfiQkM@_!;Y
z{?W_-QF0JQ`9DIio+kel8pdLd<@kG70q`<MOuUoZFkvd7a%_XA=msh7+wV6jz;{zB
zz!s#r5pU)H?J0c!x8(n3NB;i+4l5bt|Gj#~y2<~|+2N#>|Jg^B|9?)&|ILp4KUeyq
z{6Eo=|GN+H;nSnh044*ZBWM6u%GDwsK)N-6%W%|fq|XZc?5P0&(LFQ(##=XX<^*)w
zO#@inT?2T!m4a>;8gev%tK)7BK=!-4t*GB@H2@~3Gyo*KG=T4;O|1b)<!x5fZ?+nM
zRCY7~lRR9u){X{%RF?)Y3r+T_0o;4E8bCG&tHt?AfWe@t4Hq_gY5;E{HC+S9L6r;|
zz=cPv0j$T~&2)K>beT~DxEAx5(f~Z4R|B|iOlA#$PY9XLJNNaf0o?Fv1`XiI^8db#
zLWAAqf3Nz&yJu$97kVxKeCG19pHJp*MHr3bnW0niw?Z2~aCPYT{H?fRaPWLN!KVVm
za}>F@tDofJ?p?-nRPlMh;Laq+PTxYN)$g9^)_>F+?@`O@oRU?Uofu^Hzz-pfrn47y
zUZm%PRIc{DjKrK9Zs?+|#f#8q3tX2&V2kiN_qpr|=)|3B3pVAh=}3*YW?lKky}{cn
z{-1jO^Ud$KGnY5>1rHuQUz_cGZT>v-^)JT9#>;!fM|Im|EO%#z+F8H66+AK*t0>5S
zV$0j{DcjAiq8jW8BFo#zjDN#_5oOofD<=$-*@kz+72IlamSV96lu-|Wu+$gcMI$-^
zyFoTtrv456((J#y1)rwy$>=h&T%{6dHi$|B=nJa*v#+EUuF#Kqa|jPbhND~!|8Wt7
z<ahs0TMzUE$fF|~Y(nr=<1@mr59Ps=A4F`A`OR4<ax5Wg^-9wl^sC~d@UOTY19R^~
z(pQ>GU$gLimVd>x^s`pB;95@@#s7By3lN3&z6gmq;s43=?zcc`vLE`q=iSplYS;~?
zaZCsQV!4nYbOix(1_H|?3@?M_q^p>OgfkE+A8vD<e;foRVTn9~{e3b@r0nlk;mewM
zxv7g=`};33E^E_B+27wms{8cgv+VC*movy5b=S#Y@2S&|O=u>~{{DL;^gR8DNvhc2
zhs#fO)b{s%gN2)@gM-*{n*IGGG-Xad1b-D-uo7V)c)e~hbw}3@UFU1e`?3Bo(JpRa
z)(gzZw*Cbf>-TZ;hh)sp3ijdJ)*u`Zo@R^$y8rBo0+ZS7&UDr*PQQ+k02U;vL=oVb
zX3B5S<&CFdPmW>6AMBUv{~mW2I=@fwid6oUneyctoQ8i&&wPVlutnS_b!R*DE6l!B
zspjWt=~imbFR%~ey~D};+JP_JhpWCPXFc#&IkJKXl>->K5AKv{fq53s04g<~MR8XW
zUU_nLi)mL#T9OOR;!}_<@T}C;&8(X7>iLrViVXRw`H~{Ib76_bwlDJ~nPXF#z0B81
zcD|(iLCqC<nK9jdmNQ>cg@z+Tv<7}>z9j!AJ@f5+N&bV~^K%?}y(N`J@nGZ?;!+s;
znw>G<)R)HT50F|>8a`8B@?pg5o*!--!scV8t!mc>T09_5OY`{oo1bHLdG3O{p0l%0
z9#L9Yd7j*LJcYSWGZ#iTw41-VaMlREj@BtkE&AZqXbB7>WWm%VW(MOx5Sk9wK8v-x
zU$7N;1DF44N#{HJ!WS;P^%76k;=yz+_N%jGDdXO-+6;@~fE|ha#K3&GDhCwb=YraL
zZ5n46^lAJ7{83$9`?X4>B0?aBtw?{+{}7yPnCBP-a)SFuSLNjIzqO<@|5ab-s0)XA
zJQrSwB~&@mf^%~I^Vi_mELpv`_An!BR1HOLcA_Maoj9+;6U0?BPq6qEoO~?fKhNSH
zoT%e1Q~*G`B)Q(@SJUc&wRG$8+Wg@#3Ik8x_kjUD?DJ*)GKhf%pa=lq+D%75U8^s}
z48YMK!cEG8)5CWDwc}IoBd$vn?iQWzysy4occ4oR2NF3&p);vT;ZQMql-HBx2^H(l
z@U|iFB0;0|(|C{vMJS0F1vK2IVOh_Y`2U}nf|(vqm=G#7d<_8iC)NA?P?O#{Y1J)1
zDg?seY>!Y=>TO*Yfmu-<PpG2O{x?RHw+(om4}37NQ5)iFar6vnf?nvx|JJRYGG*}E
zFH?`(7CJ1(W{};Xxq#XLFd$Q4se&WRh@wH99bd<YT>dC&4CUivfUg}cES@UR7vyvM
z0C)!E61{R2+~5<Dt#Q5d+7#5hJOo(St{dw16x8ho>Pz%|_JDdH`ji%U0*CQMyo?DS
zI?av&!G`mMeiXvNatt`!ie&LHx6pO>G99~Czr;3^a|i?@qS4gQx3O$+V<d}VM?1r>
zbJgms9Hc-&+)4Lcc>N>9ju$C7(rv)Vc&{F{3QR2=vYJ}OrWS*Y>RQ=|pXBQV7QLi6
zD(IHLEq$j!L_pXr4ggI91ccpUqD;30guwFHS_4Z!SPOxzO)Ub#TJWwjwX!Af9PTj^
z5?yhW2d9NtP4G)cqG#z~^CL7;TvATtCn!ENB5^){qHt(bf@=ibBpA>Qtzin$8s13b
zATjgk4_DlAYhov9(!hhO!~DRdj<Gn5mTSZ(@COnRd~i7GvKrk{Pz|lHeePihZFUM;
zsGk^wE|kMUsOX^6t{?bClb}F*oS*@6W8?KK_<^A`rrgUU;tGpJwoSNH#Uw$oQxUVK
zD<X26shDLe7MqF~6tHIN^7S2ds_(99XMYa#Zb2%3ghr>33Ot2ICuR_-M8UYkc?fBb
z0DeH^c!DyJ)4>K4LkX<DL?bs)aNk7Gg1In|jq;!k$dOPXF-o>|iu}m-goY=^nCj?7
zst+>N0gv>?KoRKILXO!E*&cvw7GVL6W6j?TwF)k$hJu1-_v(=h_u_%Fl)iS%%xD_s
z(vd3el_OPpUpR)NcUwPbWmFYbwpj{XKxhY(MBJyAke(t^b!ri@Dlu-Vauw;SB)HT%
z(p5QkmNsQ2N$u-N`Ld9v**V7#_d+Vhr&&lS{7)<-0cl#5tRsXQm=^j1=NaE21ZVDG
z2G-ISF<oTYT=&j`@^D1Xg7WkcoV!+zOFsy=x#H=ETMEp2L*ugE^jvC=2E1y*!G$}E
z5#ZHMDEW<$E)Z*18rG1&2fU_e4r|EZlk7vtVU(~7jZbuwT0<_z#Cb6I<QnS1n5Ic%
zhA|aOhn6v2k1spLSUuWB1|!TeYsiz$sE>@Y(kC=HF_It)-hontLICfW=E7%{0Xj22
z5s&=~;AdDv)Z1PX3%GH8GW6?(3d7uROD!lU|9NN{ROB9V7nKPz<)Pl^jT+X++b04|
z^!aNbWZ~J`u1m9@a_<Pn=*ZjOIKtOCppkK1N;^vM9D;=8ABSTt#P1T52Nfx3HGWkF
z5Fu}kG8a%k=+QR;aMphn6hRrzU|r9!U<2O}=#M&HCVuE(;B-Cbji$p{D}9IMI*56Y
zG6EEf3Zihy35EfQTZJ@FqHnZxq;_P7S9L0rb0V3=)PQi;8ZTz+ns{(-q%7c(^`HzY
zSd5<E232PWj>8Axw{|FG^cAdF91tv)Q0lGD5ttqy@_<FeYW<w?)90d!iJy*#D{cIA
zu=vl6pFR|2O#E~RMH@dIE?p8s9eP*ZsHHF!rv#l|u2$Yn?kZX@?kKQ=^F3W2_uYUM
zk^dqN!T4B!B08A*AIQaFZ5&4r^8JpiU`;@m;<u<=t@KVWZ{K|osMRN7+;H(|u~R*V
zLgLq=3WR`)jn#y`wAfy5Mj`ks$G0J&VqS327P)LkCG}o$g{S*dQZ0oK1OJ}XaKN}I
zBiO$LtYK=k<aVl)rLE?~Jxt6)Q8*$KkS`z|mlL$1iq73lm}9!8?$O}g0V@j}Mez=R
zTyH?ryEJ%7HQF@26-bEU$*rMm`i>iUV%xx<eNFyTlHcIMx}oneE_`2UFiChEe79Ll
z$a}lKw)o3PAk_0w8W<CW{XL`!zTs1=#+7#v-|dK+YtZFu$MrCE$rIcXX@vb1UL}O@
z#hdLpJVw=ON7XL5or-e}f=*n*{{DdvIF+;3I@F5znz1PG1O&awB_z=6ClXEA-6qw4
zq5(l}Qmr>_(RmHN)(!?_{Cer!4uad5m1d1H{9$6Plj>ei33$bWslBBwa?o{RGiTsA
z7AQ>6PWeJhcH&*~z*^UyNY^K$W;yQ>-e162|6AujGq}9Eo&Ow*G)#~ht@C<2|Iz0q
ziWlLrEt~>P2nrJBSs!TOuSXwfAu3pEJb?FAR<Jt(y`T+#&F*aLspQFSi(h*F@6hxS
z^YzZinGMtbOF4I3;!(S=Jd}3yBmhYJFL{}N+*L=;|6A|%rTsg4&95my`x+?euO=`3
zTgQ*RTzu+JP%rhdH%4%_7XK7me9|B3b?R#ex_0<JzA#q$v3NhIW1$giQNq`X5s=xZ
zN_^hR;i}SU0}r<X>#~Z9Q5|o##p#)VO9$hiw;$+Q>hUZd9lRP0%f^kTJ8f{Ca4<D6
z&dVw0?iSu}V{vq%uX4mnYXHWkGWAEg0B-kQ$lN<e2fe>ZHO3H{wy|2}Y77A6Zw>Gm
z9e02C%iZ7oAe;S=l<FsF4_1<CT42MUIDa|qp<+pxiHvVL8KHC3>nIGKKU`I3TfEi#
zaPF(eeEK$yd80ffsV+s)_&~G-3s)EJd4hv)0DRz6N!3RRZip|3HmB+3nJd7E;LAKC
zxR-+nVN~MBoTaXKlq`yV%<EO+OR!=!sF5?tN}km<zloaB@@FFjEbtKu=w!cX5Z#)4
zDM_^orkJR2UHn*fD`dFR={C`=+m=Ucw~wnev!vVK;t#H`=$dRlTKZ(f8!LTWJ&GKi
zJSElb8jF@9>2^*0yO5bc=$l6Ofh9oSX_!8-77qhG>zYWIx}1sJ&u}d%s#tAXeYKW@
zSskB_R)xdUWgkZ<=fUPEWZE2F((K7!)rhuU!hm(`^7ilr4E{=2ZvDtWDOq+jXQf{~
zB#8Fv>B?VrKZ@W!4e!2TgVHKg*ouobC?39Gr6*KGwT9QDTBDWi(K(OhL<*}DZw7fl
z=}aGrKn_5AJo_<Xa}XwRl^Q)muz4N+;2s}SCgG>t=gS9rHk+{Zcp$nUaU7}T92oE*
zP0(>9XJwp+u0|t+d|Cl0g`_spVZpZ|el`SUoHT?Q``?O`w#a>_?2_`9yFd!dEcU9U
z__BB(6o<5eShx^bQ}0BXDqH3nDN_}Hk3+g3ZCs@-e7qSD!5@098JYxZR<owd=&JDt
z`hyPCt1iQryeE2Uy#%7QJ^W)UfR>c_BDBxJ&O*?2xqr6@g9T)G{<eN*HRq4C^MqVK
zg}3`2dG8G~NejIAoBt<vK@cbM2w6iAQ7@foz)hfrfXZJ@IJu6R)Q#wuf7!own;NA9
zWV0J)d_xK()l~vu2=K<=GFcxY32G0FuXEW4c~`KVv^#4neb31}8^Ea=;lCyj!SLGA
z*~!@lFB``YCyn}c*>=2pyJK3H<qr^Rwd@{>dHHtzR(3=pX~%THY-#d*X_666#;e14
zkD=Z(7FFP4ON`<_!v5pmXvOa-{EbRZqL}Fq;X4%+m$+UmC4#7@t=S?k(&fYVq>~fT
z3FX5fmwb2?6O|?(wpweayk_r`59Ll9F8Q#I^9=d$oFgB0ANWiOk$_#<#S2mr0-DYy
zM?$RCfP9vOc*@-vCB)`Hc18(tGui{~U6d4krKg0r*~x%}Sb@SKA+Ez!OMMs9B_W=J
z*r$Zp1cFurQM5M+Q7r{G#G_=@BJr0p+H6J%aSjert%TTlp)9}bi(C@IhnkLrXg~qo
z;2EYtw}j{~-L8ulvRjc5L8sg95@PEr+wJ4(PR-MPCOpkZ2)6G?h&zy@8$2o1ts@~G
zg*Jn0gYkdU5@HW7W??Buk5WSX0nt`mRN+X73#HZ7@h>|PV)sEUBR&Dq{ZlfcLQws`
zM@Aeg3`)z0;hKwnUAU;ohzY_%cj1u?km3utV@3p}WW*hFiR{mi5vQ{dWW>2gCnF9~
z#QT=T`yD|>yd`C-;_s6e_9`PLeut!jp=lX0a~c|MP)qP9B_l4yS0)*8H+#@B;y&_v
z@U3M`qGZb`BOb$DEJ2PVBY0O#WCT}JW*LEFMaYOm#FBKAdhc>>2b<JS&{;+q@vam|
zsyFdBDo-uM{{%kCI*+2x(aDID1tQ3Z#=pB{#BNxqASI^5cDsFIEw01Qi%dt9n({8}
z<6Lq=-c9FA$s!?QYi|c9$7Q8PzxpqbJP2Im#GCsw%ZZ@|{u2d$N)Rn4`r<oXPIQ!W
zgef^;%p-cg#rsSt|E5g-<M~^8UqXVUFZwUeO>ZvbcK;Q1%3m^2%9}lw<OeRt0(eB)
z!SO79_x(iA_pv43$}i%3fypZ<Qv(DIJWfLTwI&^hD_)npQ+>Z`w_?&h_M0etmMM(w
zebO4_OOrH8ic#BKXyo<75G(;Swsp!iF{PwShL6ln`~h3uC~i~d;bKsB_`rps<55hX
zU~et-%AWjJ*m{riC2`9$F);BX=VQMZ1q?pqcFAfSV1smByG^s-<N+S>l_&R65W^1d
zB|XQoPM8-vU3$I%P71&M;VOXnaN`&AdHs>+a~>uX@y5tX(USV{V@H}(r*r(sFuwyb
z&+i-UdQLgN=l(5yeqS_snBSj)GXW`jexEYw-RJk*uVk3tJ51rvJ-_0A&giab^Se23
zM*951L*etyZ*hMa<x$P=o_ksLDCW1T$PW{&)25;CV%hui675-FjLv(cJf{YAr^kKZ
zaYCEyecBSO6=$V(HjELTg?Q@AEXV9nrHG!v*cg?N@S0=hs(XT99b)ih&VQf;7L-I<
zlIRkhjHANE1T#4oQ~ok;XvC8B9q>@$)i`KT6&Ki^aWxc|FlRX3wyMW|1wFSx<zGsn
zkmTjwR`mm>Nr)CaPxk3I5An*u46UoLftnty!9VB`y1K&B!CjNRz=SwS%=(+~;rLae
zO?Rl8Nd&ot(8utTI}*pJWazoa`dg0(&ArY~xb0tw|0&@V{{J#r<NwpL6#fs)bK`&h
zl%vQ0s}KVj@Q<rG!2h=UZMUuJMIydIeeA~nHhx(AR|1C5!av`a75q1RoR0sw7?i>P
zc>Fvn{1*;50{%1b%bXu^G`+5;9`ieA;SttfxQ*^%U`h0MS&R^io!R%nyP~sC=;XxE
z=)k7MaFM3jz#A#zZ#aD<mOR5>i3Jn&@eD{&jGN-iM3OGmfzd|<i(hq&T@}9ITzpkz
zt2h7PQhymGy>gt|hqnN1AQ)3J*uctcL5+NoH45oX&$ktN&@*fn=J<%a%M@lTy{GaA
z>t*AXAMjW0Dk_x7_91tqJzv)f#yl(Sge?q?Pdt<4r7HEIG?AmuoDQTWvuL3^EEc-M
zu+ZTw>mR7|58SEgUjtRi6JL*i)cc4A5l&{a>>(+82$B2_ttdYT!^lCf<~;Sw`woK#
z@iP6X(3?87-qgVs=p4oXy1;x#;!4%Dlm&T^GaeUB=^Rna`LSXDVBv_-Rh^fVasHur
z9)SacM6o&(6~UQOx6RG-72nh)h*iUHKOa8C_z1K3Fd5^~;p6vHKMNnvEICSiGzj93
z8Xv%y!N)LE%!H3W>Jkn<jMi{{epX5_870BcS1<Q#58rdRn@Ro1<$u>(d1@_PMU&i;
zQ3LQ#w$}^1Pi5{O`~lQ|xN@i({}(P&{-@5yg9Y_)2?R1>W)WXxtdPZpKvqfaLNJHB
zdYpPdNaFaG9xpJS7SuV6A;`eG!P{$vH@v(%jW?j|1$f`k>Gl;o7NEO@Im@XRyoIf?
zNp<j-mQzUd3xHFX#KAEff2PjgJvo}QeBmOz5&R-wp{0ixRu($fON`@^^J8t~9UWZd
zf>ExI7#L4XhY>+;rl{jnFrMUw(W$3lWRvQ02S#~hweA26XmE&`I)B^bXkLr}MrURX
za_A55s}@{(3C1^hnhkmx-rm;B`>H#9AA(QtiS1B-@SzXGJBwG8eh6h7UN6(&69G?E
z--iRMFw_;k55YC7_wqN(mVX$2y<kQ8hd>!l!Z+YJ52u5)NLQX@uf&|nS1Mq!#Ej1*
z(^%4+U5N(S%QW<o0G%}VsWfeQ(UvMfF$hCEyV?c%IfV0)de0zqsP=ti=ajAe9Z5TU
zAJ}KP2?Dmu0kuo-3N>(90$hvCXG_|At}Oj<1!fe6<GO==X&i2uI=^9Zv~VqPxnpMk
z(}0qU^=220uiAS!tzNCIw_<koc)*09QH)M)o|P>H`aS^boec0~-dfV;E&oM42p-;d
zIIX*#mh4u{@s5#U6~T@MJibQVptSua6QT6FYrme7Y_9c<`Jd2Z{+oN5|B8O<!3SiP
z>V1s>yUXka&B3tiWT1LUYZcI*ACq_8@S5%gLVBLc`Dzr<&bV4Rf<T@nTp;TPPv^$v
zNx^|!;o-Vz5&40lb^H28%A0UB>{nhnWrTNYlOU)m4M96*W{rVD+!QHqjKh%+^U@m4
zleQzJdte@^-sVAQyGZ#ioZEwLsNKVGKUtp&l$7tvU-liT)q+^0vVyY{f5P-3R`wha
zEbwX5;XcIFG2oerS8xbYx0i%5&bQ}#TPLH1{fGNBL}-0#7K&-^PB8$|*DRFQoJMK&
zGYfEmg9p3Kk<!LQ|M=DTh(8MgNh6a1n1<rzG7XsI#$G2`__w^bmA{HE0S@=f5C4px
zrQQt8!4O%NdCoB-hr`>|gStW$DhjohI?4q+Er**DJ(`cjzi?}!o(ET^;ZSt{-c@up
z5p^Pde`<dB$L|jP8{A2-MDN(tx~iYqUr+(3lv5HXt1sZxOLJz`7mq1uF@d$6M$$4~
z*ej?_<*#}seZ&%kDC3CncKo2O%1ZT{uj$du0zZ=-nAKX%m`;>24NYK`B?Hc=26MmU
zj0=8HNxw6)jNP&IIa!0uz-Hk!Tr;roGDbj6q37^t+z+TYE~rGet(aUfO<lgg?lo{8
zgQY|Z;BaVi-Q7Ww>S``DxPwqiu+$Kg5+~{Q>N;5nd<d%@4scwzaD|wx{Ub_X`<D|z
z2*GvvXo7y-x8DXAc82#g1d6y_#RRo}`bhpknH@96pf}tLJ59eTE^i}u?wDCHw!hr0
zs@p52X7(T3zXkw#aG@LVg=c1s#p8dSD`$)!c^Ka-rjIvYhtj_Op}$NdbHH2PA&(t#
zCy;v=u-@6n*Rf;T8J@(S;}fuGINT+$hDh+Cq$(4WZTFB*hF<by|DT=kVSUg+4Yvyn
zdf@Pt%z&N_aUaC`pAD{%c;AEyyH@7K9pzct2Y>bV;IFC|{t5>+Pq9a|n-=1T%6SX^
zlJ{77iER&*8RIZeG1ICx?=_GiIFVi<SSKi+4_ST2lnm}+WwxNk|CBWfYp7<$AHzTO
zz9#ks?(%~w!{o(vJ;mMec=|SmKXo|CVjsAl<?S#5{YiZpo=};&JJg{j_)PG6S~`bM
z{G<nao2~%>du!^Iy;=KNCLOHLHfR}S+K#a&WpC@XJlT1V^7ek|XZZt7#mLgQk+JWI
zzm9kmNgOy_lLakuLVMmAvHXi}h{(nktF%i!$in4GQ_I<#Qi7+Kr|q?eR_yo!Ipt+M
zNAL%-<Ly2e+aL1{#ouxlIT0zIx91H!FEvAWs~aw}Mn-mQ{u6j@`>Fk4p04sPmMxss
zj7DKt61|E=pbP^8z@m@ktkg>sPwnw}8{%aeNa_vuzTNg$9&JPPe(Qy4E^u7&Lqtw<
z0`Mb<-@bX3V?oc=lW)B1)|Sd)?5*--Rr~}jW}I_1n!j+nsz7bPpulOISw{QtURE~?
zTh-EUDDuVQjwWb0i;|mk6?v*I@pP3Z6MYdT3N&ULF!g;$U7s(Zfv#^cZJ7F_K5zZo
z)9dHD>g$^k@EFtv57-1Wx>IAo+k!f;t0?3e3vq7X`2)m`vG;^VTYMDIBrm6pyj}wW
zcjE;Q3F^GAq8wM7Y%leig0vq9(rvy1%ZG?K9ffUA;%q!g?<K;?D{%DDFL=xCFl+MW
z(b;#2g$kyS0w^9>PkjG`wbKkf0za))vApFipkmzLyhHdPa3EJHituljJU{wdy@ccc
zF00cU%~`t%doRR41rbB{Hb7N=4Y!%`a$jML&6TOd?Q9N0Mu*;nF|4C2G&;B%U|I*T
z`_W*~vrTrZd9Sg!Vd>BpzK%5jG<st>YuTP({mix}drHJMD{Y70HCmi=N2<k#TrIx5
z&DA2N1~?3fW-CN3<A)y`^&aZRxUG(e$5?iqCFOY`k~Ysb-qa3Y7AL@aGLe(monZl@
zJ*+>(W&_2jrv)=srIHt2_<kfvf>1ONiZteC>B-DTo6N@(&U~o%AZModk}?}_V2Cn7
z06rPtE^~rdv9@datH5e!C*^YWL)7(aM6zAH_b%-^6Ei_oOY0q+92Y9zcA@gNIu|N2
zIhYs(R~6dPuwG=_)RS`tRIQS7PEM<<#SdLAp6YIq$j*R|;Chfo@JaqtRS6>Ts6Wbd
z$PH@XJGg;aQfLkHv()DF{7uZ)g_xhMzMG!Eh51sbhWUNe-Rb$;nJ<N&y$ks{>WZ{{
zu1hr%FO6UkxJ9Y3WX=DLwl#%Cu@t#HCvyI_=YS5{K?m3X53x3ZDb2((*OMBG=W&5!
zJeFngBJDjB!Y*8Q<!T>qtKty(6{s($omfQg#mWNd>u$Y5F=LFY-?AWI{X5<Wt>;}c
z4-zl6tO%eDWYaK>B>|Kn9)`>9OpH}^vk&q1Kmkju^*<6I0e8My=x!`K@k<9-U_js_
z|6%NS<8_;qDB6WG0Lh2GPYm@G<>=U~xylj2xnIRJth-|t8@njjfJwnrHg9#2q*%hn
zE7ioo(P7Cc865K(DzgPO_G#8A#L*Wwgo2Ob)vu+B#z*{7q;r{8cm&ayqE5jEoSJ}A
z$HE087_Kdw3ljPkgg1bT{6$0|c&$dEUI{>9d*UJ#D)Fhi2QdP-I-9-YK8OU&N4_^P
z)Kb8Cn0BFnRy72GLEVhtrh=f=;EVT%sRZ0T9l8T%mxn7ke0ab$g&mr%a?Y+zoGRNm
zKrUCJ<!&^3hjBfb$ljP1bVu5ky^5wU%^#Hyr7bxeuV=+A&D2`ZhQNpNB=X?MCD4fI
zFP=JDmi55(DtRL$ug8Ls`nc2NeNcP8oA%W9N2$W}DDKb~HrKKaGsb5i<>4(`z3>J@
zR6`juE7j7ct=|bvHI-}VH?98LX(hVX&lvw9t^UCy*3TIKA+7$)N36dXTc{rJgE;K?
zuKtYtCqE-UWBY0F9h8Yp!*5zX1xgA+!CzXwK2PeseunlTaWTPk$pT}28L{ah`M{};
zyfYAT)btZT-Oc3U$Kt#V1bc+K0`J7ymobPcl8}5uV|y8Ea48b>ciRN&;IYz1wQJ*n
zF2<oR2w+nb-4nSP+Z@dX%ao2cf+H|Eiryr6FT@&St<k@P{+&S@+Wy)m>GpT2Te`Q8
zZI^AoT`-OIccFbKyx@9J!=RuuO#f@B$UEjx*R5<JM!LhF*S&og`~}*%Rp1{fzb*Xp
zr1758+-cu|f5R`j;l~BPelJGDKWRWW`1>3Ieyat6ji^`7>clv$dy5_4TsZ8gg0nl#
zxgY!==_3w{QJ#8TDm2E&kx%eOJT&0K?8SZY@5uW=QpBnlDcUh*U@7g0A{}1R#v_=8
zgB=MK{0lOJ?RP_3WvlaQ(u5Ss;++DoD!>rn{$0T*T+}Br<x~$+Rf7#|kgclq-<Kxp
zeGTlMa1IwZ8{%Q`17jm%^3O0RyuHDnwJ0GM0ln&Gpc(Ipz>O?GAF?vFT|DryWN^$E
z8pzU*=+cRIu#5)bfEGhl93iEJVy8Iu2kjur9PFRtu@S||6Ys(!rMxSAaD3<(oi(m<
z0Gs=gZcZ>r+!a*bfrh&R>XKgzCr7uqO<0I$;Oc#a@YnYwu=USVc~b2#+B_USxKP?W
z98S)y#M|GdYyrx$<h}_qI=%{SazKKx2$mj}hCV?y*5$-E_E&-`YxSsqw@Lbjg$!o$
z5?|q+*@-)39NJFNk^hVG!bo`wEKhxWt?)~fOP#d~fQn{|3b{T9yE?t;k=|s}#f$_K
z_W)m0T}$==MjgS1Zx0j%0(*`IHeLxfA)qkPk3=Z%I9aM3!KY5__;K$ABauN~cqWU~
z#Gk@9HrG(Lag%h`X8K29?r^ppnnz07@pDe^ri$TsPelC`bB$#k-j^l13bg~O9_S}K
zGz8l7Jr)TY+2K29u!oI_sfoeJyVd4xVBV{ew;?ei0X;Gq-kS}N?(&ZPZ}Yk<cgc9R
zB~Lveh3r!|!au6psto);N2WH?egQ7fNCc^F;vd$$UUwZW-xPnLm&Mk`vZTN^z1Z3!
zrQ%wCgvIvyrnJSTJe6~aq91OM6~M)|T|MwTnP0Dq?Yzg$Vtba|JC}Cy)brzstY@R;
z8{%1j*f0av>Kl*wGOKR}MrT&vhd*QAwQ$oktM6h&vXmKgR$rkm?OuJYmb6+41?`JR
zzxw_ifTD9QjZoU^+XXfQJ*t=0_mEUOn$>rc?x45TS1E`p{9c*AqN}1y^&Lt(*Sbjg
zdc6)W)==O)3QLXaFgN}Kj*%=ymZFbUHNhi#f4{#``)rJqV?nk|e4|fk;|cKlEp3of
zEd*#;f9DBz!=V(0fOVPH>aLRVJ$IjQCpO9rCBDWCtG2Xx0M6F-W)GmF4c_%a!|k}X
z3Smhyz2|hnWgN~apk=TyCayuEEHW>gMtoZ!>#?3O=z8DdoUM8vFLnx*FB(Uhc|2PF
zWLzvLxTMQVGqRGe1<Qi2qF3?~l4<8pNh&p5$u;Ud(2ZHi1)w#qWY8M_B)(=A^hoG-
z9yJedvVfi<zSWWPH3TJBI$a$tUz7N{97uUonJt4ywpOvs-mwI1MYMcX;=IHuW`Umo
z*!I7T)g5m1?Ehb^y$^hyMV0@5liWgRQ*KIA2ofRCqDc8uC@K(ep*B#END><U2trjT
zv4CQm6mVOba(gkim#bZutmvX!lvVsLYH?YpY>R2BO~9%tbhTpDfKldhBSeWdWlQsW
zf6hG5{gbA^`ZIm?x%133f6kmabIzHWGiTUT9I}-?WL$@>?X6PAhb$uztBO<yQ>bkG
z7s=lls%5PFy+-9!9v?CX<nOi+U(Z;EZ5eaFB>EjAfBy!S@c6p1EWzaOnumnzUa^E;
zx8(o5DNC4fZ@?0?(qjF3oWZ#zlQj8jT7eq%A2f;%RIr;Af!hx^@U1)xFsDIrv)>N{
z@S#fnPeJnR^LYt84i6YMH!5BNbEyUrm>4|Om;{!Gm64h46)Nxipu7Smutc6pn%ui#
zf8#QN%ardBpAYv)2oaOP_(_rsJ}M_^LmB*=>Ar<y*}&uM7OJRM_?{QS8w6*w`!>SL
zX1C$sFU>AS(AvmHA06^Sco(v?Oglh*Hn2BnV2=^DEq!$@yEL44gq(7RI*0v}N%cES
z2qU9d*X_fYOVG>;ptT#^3>L*+OsweLOJPo!5_b?NC=gWdKTb&=4WzKf?r@{q{JpVK
z_`GkbkJoAJu5;5NE{04Xg>CFg3R91l!mlBZ3=1Y{|L0iM@Ngi7UkbmOfc=4ed&o=S
z;Xn#ANR3G`KDh-Aeq@Or+;2bz@_1E1v|lAzP98rjYz1OjWi)yqQZ4H;KRkducFJNJ
zp_j*w>&oKG2i{EiJ^MRFgO9W(kEi~-4G0asZueI(_a^fATWf;B_n?Q^#Ihj%TCLFb
zASatLlgE|E@1*B~(Rezo3rFMS532GFQo1}%{>2Q;3rAyFki2j-j@h4V>6b*dAy=di
zk2@Ow6HrzC{-g2BaGnE?#((tr27z-h9F2qHkH*HJiv33;_tt=|1%|DhQ2q>#2{_A}
zY+37ZFvY_m4+izSyiooI_&$(OUYwCo-iF-?rW+E<+orZK(zYa9dLi?=`n5TseE)c3
zx3{jP&kN-(b@kiE8O04dCpGLS5XuycQ0@(c^7Y4fbY?J-95t?{7T!s0UMjCQseCrA
z4z8&SgtJm!f3zs)-c-wdndhvL1yZ?}h+?U{@av+NK)=2S;(1$AxsS_VOe)`#Y+0j9
zUwx-4y(iVOCi}5KDsKqWtV*_YD$S2A&8k#OXZGB;l*)FN$^>(V@_s>i6U)Fzs-?rT
zf?z(c9ff#*v@N=>L^B?Y_e$DsWQ{ZaVrko{rb0~jfb8BGe>MVdVg4c~L6vp&dlw%n
z<*K5tVPvVYpYF4@pJ3VcayN{%5t|Ao1*9L&r602NrKkIqOTXT7+2yHAW>lo+&!|jY
zGoxzvQ&MKy8fQMUdo$xV(so4bvFMbuOWWt6pq@P^o-J8=#$Pv=wP(`NDaVgumvQc1
z9=AQ8icYC3ZGSGFjV`T9uN&RBZyzTJ@Wr$B+a3J1u`zS))lX&1sPd?8+_UlGYu~o5
zW6ya@rgiM8U2;(D-#0(k|5U1Pc6Y}M$2|AqQ?t8gKl_yS^RQEBQQKPgJaR!~w7q<E
z+B|m6K01yu8HLiC=<f4%8-%}&Ft$qTx~aJ{s#5dz&hB+JAKNq9l4`9?HJ;F%YMjyR
zjxypZ|0qeyg@$D5dbK<RkjnW|+0rN*#qVDbxqkG$d<}eWZ)r@=oe}kSa+B(W)RpC_
zTPxz2^{%=|#V(t15<yL->)K|V6ubKjLg_P>rYin33DWUc9bfjJ(MT+D1o5pUaPZXJ
z|15W(<jn#d1TqhbdT3N&L&shm4G*E)wrzIz^(nc&imbdND)?fFDqd1e6{+Tmvzp3d
zi3z;g`mxV*S<`>7yYb>khHkS99fNlfLGnZ8$qz=8H&wJWHC}nuN3XhCJL;o-`MT6+
zM!#myW!q;bNlLig6lSv1HlUXsf<qt8krwOX^oiOukN#vH>-`!50sWi3OWR>uHIG7O
z<S5sss_mrxt4h<#J`<(N$O?Nd*U^}}_+a(PnQFei<*MeBs;25EmrxBtU{Q;y^DEdV
zw86k$XJzEhf3W3)%4JG_7W8x_nquqv-?5}~<^Ycl9`F&giD0`hGEZZPJ)E8=rCL-=
zTj(xYozJbG>7M%59Ty?JhXInGk>44x@ZFIWSCFx+e&owDH*aSZVlTh}E6g+cOd~_T
z$*te2=CC*D*RA9ijO~fk+`ecQQ-Hz9@=4kU&FD%twnR}aW&bjqeE>~veEkA@=5YZz
zzZeh$qkLwSbq?IzJIkWVAytWJbeKNa4a@ApQu}cB@%^d{`m;*?qAUFF;fPAA;RL2s
zGeBf54IJx<s-juxuIDIGqr-D5EuUeltb?wWxUs9OLHP^f%c~=ILT%NQScQMF7nP9-
z7S>~~uBBS=daoqa@}h+rR2>*`$U|29BzR=1G&PU8><s*6V#pa^euC|94ao9H3Y2N~
zVl%!D`BoaB1v47mMOTOns<B$L>pty}7Ayiac>4=Y?nCqSRTKExt-t25>7qrg{SXr7
zDdu*_&Gg?J-C`ZG)|Gde%K{eNuX_8bpE~=&-h=Mi%NgvlxfyXw2<rF85UJmjVp3-M
zv|`(puzpA8A-+N@WX69KabTw!$g7&Qy$9@R;((oPLG(I|)BBY0Ov~JtxrxkbvHu6W
z^vsAm+lmRt!2R=dguuo%MX>eRvQ3Hp(xUpeWlpgAE04EP{F(Uj+K3jw_SQAj-U+x8
z+|12J+*V88o7uy_4Qs0fyEVYerO%|;LJAfb{4E6TT}8DD@GVNT!iw3F`98&Dv@>D=
zvB5Pc$5ES_!=8Ab^@P7VFzAeiL3P&Ge3C}@ds&UDGp?~12x*r(BUnt_1tQkE?etuV
z8}B$~_6LIc{Q!0PBP_=Rt|1ib?CXf@SBCoT%v4e-eu#Hld>V1Tx8VA)?ef~S!P=f`
zSx-1%IHz8iNA}UyHasW{yUw8e4lAF<Ij|~Jw_lX&JM&dG?CvCmZD`MEavy(0=%@`l
z?<gy8oyt2iC~uaPw=TOd`ymySAFhM6f7qQC6ec>FHnuSJ2{WZ(mxY?uH^1XoGo~XI
z`E$L9SeP)4xL*6@S0sb+>=%_r-mblvYriEt62$a!FZi`FyI1s8%rS!fNlsa^+sghA
z??~?Mw{88HyupRtp)F^3^KS#*JmCH`3!3SM5A-u!bqy(I-u=mm0iW>;*s)b#w$2$C
zy>l{~Oz@Dprs(q0>;zYKs+e0PJc!6tbUPFmv_$E2i^V{E84|Z`7V0}gSR(<^TI1{Y
z{^}7Hd`Qhf{ToQl?~OLQTaJ{lF+AX<Q5UCAYPZ?TQ>hzV2$?Lo2QpWqNDzamL}2MZ
z!yTg*-40`|c2!~HxNdr9sub3bd3&<tDYc-b3is9%-1(=d1@fLFLn?67@f*VpL-@c3
z{=&c7O)hV;<rd|QHP9!lzbd#HH`xER_kz^tR9GFs*C72EbGm92pl}D%@{jr6iLz7h
zo!!au)V$i@bWAZZ71=6E-=Vx*dK|n4T_#>(NFOh~ijUxLeDoMke|kT!Cf~l$`p~R7
zCF<=q6Wd+%cjl<x@K5#2{)x}?qDFGud>hTve8G3lnG=80yl7Rbxw34#s-1}cxQnC7
zdC}Cx<w+>-V!I}#xiZ<P2?)xAH<}D9<CpTxT9j=?woA(GcHgLGgX7_e+(q@DU$LJ)
zQt+M9nyA@;SGWQ*8sF*)f48{6C`u3Xe^>la*qrF5{%Go=Xj!jRf)d=3pC8p_GUt~k
z8CDlnBrmQg!pyk%u&W=6n2@IfkB<<4I^i?o{u@H@BICeFEXKe3Tikdr`O6(gtr$PK
zzAC_vn1SxnE_b>QyC6+LafSFS-}D0RNrZy*-14EIr+oWFgLH)*Uo+OzP>!vr=%b)(
ztl06=hh}bJp5UtZFnvJ3J&~H<Ulf`BG$1fJOim2Qm{9<E=BPj4zVXw?yQ4x2R)I~f
z64M2gz#y}k{}!~@=ci4Uc88@6oX{2^$hXIjFuVUkx;EbMnM7!ikIVpO4TW$|K7<eJ
z<$t1Q!Fs&Er0vi}a{Jrl?);^xb_Eax=@*r>&Q(cd<5(EkxP1H^D|*bPd_noAsr<0s
z5ajSXvO$IYM1^sIc}c#o;vpTTC+!3K!~4^n<G`DvUyth%!`~UVO039x$(xfg_3dZw
zT+R%*fd3XrgKO+8RsNhe`H|OdKY87KfYS;luaU_+@na=zAaE-OhAUDPmC1%}8s>B4
z!Dn5Qd)3x0QTFiH_a1~<V<pa9+>r{Nr%h>hsDh%%N>`>JCfAKj?Tpp43#=g@aKgN@
z6nfdkzBKj)%{M6tXe>`ghlJ#$)jddFrU??u?x7R#=5k&wpCB#PB~XU?q_g{(2j%Sk
zxe_xZIlfhun!{BqJA#RVOkz1M#$>EtpV+LMQ?cayn;QD7*aFuw;oOPQJ5McoFJEy?
z_|8Z38?npW67?|wmEK#L{SU8lFlzuH&3FGQvS1Ero9Maro9+;7hC8h*WVB*ki1CJP
z$qJO7-e&ixp(5%wyjvLEB8)zwU`sa`Wz+<w?zd<x-%(lCem(uP^0QU76aM+gHYVET
zD{rqlR$-Z*t-Pb^IKu7c#g}i0w4WVczBAHxM$oVBzZZq8wa3PnuV;6a^PzVB{3Y2Q
zyyP{Ng{?-tZ+?^`$FIan=@S_puRPl<@;}6Yjo%KKa~N!Z6M)J0&xT;)KKXVJ=Fy~y
z-%%53pXQ!?m-V#h#)t<a<)YL5fxNBKat9|@Cb(bEkO#L>Eg+C5LU*&()2(SZ`V)&2
zbyJq#BJk$bAV0-MSw;w7Q+Qk(mLHE{TPx7kjZYy51b3dHB?VeFXo%Cq3&o~oWYdc<
z--@zEbjgpI35pE0ypMp=?4#L^)%C?ZNaJ&~wIlD1rYRhlvwxJoC_Q<@klTE`luOW{
zc1@sN0Uf!kSm1RJ^3_Hf77%QhCZPEB&;RIx$Wx?(PmP*}rGR_lIHk<pZ$D<)4|w2L
zLD51NXUISovP`-I=wdf`uSC8yj%aFbX%t+x)_n3}t)sg`aqQ?fd$p1p&2|^9jfx<w
zd<c@M;*`@hx}z>bTjIAf{klN3d6o#Itxn{7_Pa1bLw{$H!VUjLLnwN#2zT*2H7j>3
zeUwe++x+>nOf#fm9T<(jun^<<z-PDn{jf1+`T}zra99=2>ur2~%f40^No6>+ugM!V
z=<22WsYJimGlXH*ba8dFyD<PpBWf{97w}#0qeya!0XH{DB6wqWJqGPr&Nr+kjAAj2
zh^_iJMTc!}zlk=-KU-P0_~W!7ApWJ78=`BNqXZMrwz&)k?TJ42CM!Y|06~sDlVP)0
z=zA!O;ksWgU`WrfHti>5o?{)642F{esY(Aye>c&N8+#FfCAq0L5_@v~L_9v>#X{rL
z8$4*_2M5OCsQ7QvZ2&=nmA>_gK0jJFC)zecW0KQ5o6XIs>F2U{JQnhhq-@hVqinfV
zN@*Jlp=jv372-6_18vElV~4CuNrQkyD)m+A1cbH~_mi}cazWEVezhMeSV%3Dx5(4h
z#*4?CuI~?r?P>KRHgbpjGB)xww<c9-Sd$Nq{jtVH!}WYGH_`-h-3t=wu=QK-zmyho
zD~JXJ1Cg_=1K2DD)8C5p+=&Rcfnd~H%U8bGLE^R>BoJwQW!u&9bJuYDQ>3jqHBEtJ
zi=<X~251*D*5m*OZ3jH-{Q5EQ2@J`Ywo+r2@09_a7CGSt<Ni!#lcjd7Kfr%^+j&O9
z)p$<M6?1i145U)68A?^WTf{jaFJ8a7-j{>{cu7WvuM)!6e+%f{_#H(hO;JgFpQGuh
zN<+X8G`bV#m~dwqGk!-^wEZ~1ik}^6dq;6iZG|<h@ioOiTP;gPQFBp64;?KIS(R#H
zVG|`F0N84DC;4);ZI7RL_TCvi1I_N=&o>~lIssv&O)&(Z`~nq)i)S~fSl>RI`S!Ec
zXUi_O?MmmNdyZzO+2}F7rj`srv{p#QT^5l1*w@<mf1yX~t+!1}RW#7AB7*cLhnrWa
zGA!EQp`k?m%usxPc2SN(kfreE37@cz4K*$)lwK#=={xOz@I9A(uduU8(=JmfUEjxp
zOqfA|{c5&ewd`7e=AV*n97OG|$s=l9EZNWw$M?#?RUkgl3M3M}o~VX$@Z-nZtS6Cb
zIvBQ$MWA4b{Of)vkn>5l{uHN90QU+_EO8b*&-%WyES5M)FQ#XiVpF4Zfnvh|2zh%f
z5%uY$+{6;v^l`s_r(|KJ+$Jo70lS~@ZfbS8+pM6}>PkT87BJ3}d{C8`z-)h?jXX3e
z<g+RWG%5okQ2Y!CQ~VI?P-%@P%O{R{W7OSX^%B$OKB9W&)u7q9O9}RzR|8-SOs%o9
zfcCGZ%Lc}orP;Zrjc+yED=*gCPLe%1q;meX)}4Vv%n#Catv53dNq1=jx7odjwHTvf
z<~!s$OIViG_Q@bQ*Qi)xs`drERE#AK(o4Q^H6Fv(ICNxT*o1B3H;gNl^$2AlW$*r!
zb&a-8{8BzDpz6Ze(ZkK|q?KlR!AdJeEs!e{foyrYVV8UEj|hI8u`B$3N(w~wF%*V7
zaCC!Ru8$;au-CPWtYFeSQdfWfou%2Qq<{GoTil1qn3k(!d?<;Gox7QB=rm>-3U?4z
zWjoy6mTm);?Qj!`4J!K%h)*|kQrQj{Ckd@g&8bPT&#6OvL%G+~6zyLfru{T+F<}xk
z<WrcYdIO59bXizAJgmkBph|W9S&d~BR8-2R&?jn|<#Zb`r4rQQ6zV?01K_EXJbn}u
z@q#{Z5#KT^dr0=+Y&>%Yy_(@H;%N3<Q+4JHdX3GLq~le98?_1{6FIG-&rqdK@~M#S
zVv(mDDYtI*HM|}gP|^Qh?L|aOH5ckp#WClqz}Q`X6;VnJeAyRDD~`1izY<nrD%Q_P
zrnUW8!j5$+!yRFQK3rxU<rYDJU`8{l>lCy(s=N0Hf`U2aQ-cXe`fIP58tM0sZgZ#R
zv(Ct6wGA@vy_1k*?wQ4hR(3L71rAyG-^FX55Sbg!eAzm|nsQ7~m-~a&6LmiYA7o{D
z(LJSLLuGPaRrY*Q_j9C8bT56c`i*u>aDO(4XHaV`-8V9Rm;F)b*i!4-DJ?gdSg)MH
z!id-Z(TYvoWc#VwmnX8Z1+*rY$q3@g`0|q??J?gl+EM1)X-n!SHM?P4Wzk^N1$7ES
z6u4N>+4z#>WjB*$GiDaVYEZ&=<4o-##@2|9))V-kDOu18Es)zuOz>rP95tRlN7~pG
z&^kEo4d<xFvCBJtzH#2=;u~keKRRHnE2+V?RSN;|(5u`h37VJHN&_x>)&=DOXKlFj
zgZ-LBz~!4iND$r{;x}wl{tUF+4gm2jqTLA@?%l{uA_m<RU`(5|$I#dGnJ9hk;c{d+
z=qfBKcK4vj*_85dpw%z{bz{zsCil5zo=Hg?!Dbb!zY+0`VRwoZybA^~?7m3Y2-D9i
z()HbB9(FT{#ssadp#~<^Qd8HmCC8*J#en;^6*AzCg`)hbW&DmPrYfMEPBK3q`2C1I
zIk!^FRc3#HVtpR1yo2!wyR)rPkx9Cx+m<{;C?T&c*n3#Z0bKY+MmME|cZ(XmMK5Dc
zQ4#O9MbrB7mQk1kO7bmx-B*7zI(qpPqkY$1oBH)fiEBw^SMCvsv`_ef)F<u(A_cY;
zPX{Zj;eHtMabNpkZX<^wy|)bP9dyV*a`Wx_9Gl+S`a$d%f+LwzTCZe*k<%_0nVX)R
zR}LJGo#<L}^?(nbvUNSltpxX_8`OUs$;3P2xXyQCkIlusSpRwZ)33D$4ez0`8s1>}
z`db?z<VlAI)-yKofXg!xVc{T{e)J^zzo$D!S!YZ12BFpn=B>!6!~jF7(M>dsmVxJE
z(*wU9<rK@XDR9KrTH3AwGNZ4Dv0({6QwhC3)=-OeNqO0_a_ky1?%>>B8j+>3#5%w*
zavF+ln%s@m%=w9@W1s&Du^5lYOH^z1AB69hcy#kvG|_-ccL`AAA@1Z(aS0X=R^4wV
zB(0T>!$Z4&sE*|VQS|M~WO@s*W+(O}^m``XQ(X!*yFQY&&Qpf1gu?bep;)XEB5oa_
zZ60G#=xAmF4bW;qY}GS{z#WuAAmVQPDy*hFnZBP0_Yq#SEE$g9n#R^F8)P2z^uW)A
z&A(0+*j34diimHtf|j31tKVJR>iI3S`nW}hy9ufR@4pTBV->&t%l*7teOzN2<Uf=A
zx*DPYYgf{Y)*(IAn;?$bn_anCO2DHp{Z~VpdZV4&aZvXvdJ^4$v@LT{L>N=JpK!`T
zjbR&JRU0-p3X}>eomE_EEg2f!YhSUl`8>P$^9Y{<NPKw#-F=ZID$3(NJD<~_S|J^!
zD!m2bz_PeaO_XL`*u<AbB6?U8gTm^=!fwuiaZYi*hm=L#T-2z^VZJj$Aar$#mT7wu
zeIP^K>Tc(38jkwA?jyq8#Eb9lfPk2*Ab={HTZdGGjQB#x7)Z#g!_>^0q!kz6XoXtW
zf3O(7T-Q%jZRi@!r~9sd{VTj%-P{Kf<QHBpD9#_rQhUDZ6B@>iZnD{BfaLjKw(iNE
zP0kM$=e&=c>9oceo;W<&khj@wm+vffP_@t7lejm)NKay05Lz?}7F1J+RpOh{T}s&O
z)@=@`Ua6_qE-c9p@geFJv8SxGM)$GPtikb(R=D;3{9;Hu25IBGKj!;TwYhH}E3pEc
zx8CQ;``jppvm@=3<L8zu5L>m7VtNw0NUi?tN$d<lxKg<1{bJ2gCY7X#q^2orvP(&`
zv6N+D9V(etM0}%_&~|H2Vtr6R%2KB0R3sB?h)SpRf%Xd}Ff3HSwBnQL4Lno!3|3sa
z6a&;~3rBg@Z1s1kfMl1LcIHa}l(~I$bo2o=BWX|rR9eupfRyY~Aih!0NZTzviFFF7
z5tfo!LNa|1QRyyyXr`a|K`^6{btyjC^(fC&TF($Dg*{N!1wdKJNs}bm2^k!7=a!yr
z1!EFuyy1O@#;4*NP0FAf^wOUAxe;|h+qFH3hbY;Ao2;m0x|8>GmtqAO=n5cHe6s6d
zo~g8+A!G`B$fl&MFb_}WV^mYjGZuh%ybt!lLPpyz>q)F4r)q}8siw)DXhR~JOmwIc
zW>nEGrA;Q5@s3zbD+4&v=NxQleZ+0VDlBDv9%E6geN=?yF8+ZefQs{<qOnz5s5aD}
zl3fo{#LA6&YLqRJ7P#;Im|7<kwRP15jX>lLCxT>5`2Y<oV0(q~(2rGCT$<fGS89kM
z58Jwo_L;II6Sq^Im2;>c*2(l*V#MF|Yq;=|fjcLNfJhZ@Oiat+Hq*J+oOMxHKc9jn
z7iZm#GeE@0!9$}a!k<c6iZP2*4Fj`(;!562<HjoFp+3_$jy|)d17=%?@rm8Aa3FnV
zg>M4%8H7R|#S^$Y+a`=T%_Zpd8DT7_r;`K8cxV_~8)!sd03B}RBbsuWNv)1Whx*K!
zm^Ok5;ZG=tCH{-h{`$<n5ljEQlIy=-F)YU;ug`!}*h5vL+qf*~zeoSs`mgoOS1yWp
z$GwFL4J|c=hTl~rK%pUo3l2H>ZGAA8B^cvD{G+*eDK%u!U#5}OY_HS|0BBF*$`zxd
zXeWfOAtcQO$w!E&h`W<hVN!H%Cc=G&m%O5*HJdT24#;al{f)XCZxRA)k$L1pW~n%n
zd6S_aPt=B#oXk61^`P!tJJZX&gY<5-O5O4KCG#qa^RK6ct=-s$hjI%Dn%$R=GFH*(
z7JSjmgJN|DV9JLAb%*dQ!l*lhie#9(%$Gu?(~2v-@>QujQC~Knj~Mfr@*pok66yi;
zcBA{x!vm<E`KLTo<ET3|#l@|sxYp>O!X^eZzA!9oxi1VbjxNqut}LQ}Lc#1#3G>y5
zK;+e(ZR#a;dh(0vjAYlXM7U+V<kTHCB&Y7o4}l7s`CB!!29MCD?x;9KxeB$ee^)Vl
zxvoD-wW02O0{Z}Ix|8&7bxYmx`PKEZj4dFYTUC3$>jQP?Yexo1zG00a+0>nrigT9#
z+0-4{QmpQLJk0wZpO-pME6%xqoKjf!Q+j@8gzqAoHJBOIU&0{4=zoDBLC=WkGqZ~e
z9HPM1b+3h;6fmW$>XjRPX6+X|r5s3~QL+4?&jcX^@rF|h^_d4uok{HCyEF&=n&zMY
z>Ws3PI->x8C_G9b&7qY*x@$d8$v_$y$Y;eTyEZ6UTF+2EE9~X-QK^KoAvt(@E)6S;
zWOQ!W)S1*|(`V9x8mPMTo0@|_Rsem5r`Kl`5LA{@_HA9)6O~S^<JlO9T_kREDxvsf
z;!&RHGdx466!uV6r_#!nOcz6SAbqCm<eWZ3t_b=}HLFL3`i!Cl+%(f?y6)pWop^|+
zAQM4&$P}MUJj@e)hGz(w!XC0IskE|r$TE*WA%$85K6}3n`jE+Z<TRZow(34b<P;a&
zH<|10#JwtVqn@QKrrz9>SVK@Sh8oJ+2dz=b#65h-7m!SJ@-EFs8KfQZlh=Io5zVIq
zQDaM6@?R6W<U0t&Oys>Mv4d2qi&3*;43R_M!Km?iamX*o0j`vh^9N4`L+2V<IY@Lo
zNPK*wo{_c%KG4{91?rq))F@w=`|&rdQQP}b==g;4hkIyK=+eu0m#kM7h(w=rWYeXO
zNKh$s*^8M{^BP%-%CCS{(JjDLj*7Q-rPB(79;Fa^_-XX2r>YCe^7Wer$d2>m07@^B
z3%{Wqa!Ms4XGf8nHluysPjM?Z>KUmGw8Q?B_l#oS*QLmX$$O>^z_W7t;lCAQxlq3d
zHGR%?e6&q?ML(RMGG4-BY_hA3@&f(Pk|q;ti81|9)$<3%e8JkPq@YgUX=}k^=Y#(!
zv`ata(_83=q!>>>eBs0c>4$jWM8k?K!+}b9+4AwW?StiC++_4>mCY~FwQ9y>GJ;jQ
zZ<wpT!d1Fi?t3W-GZxH5rn$te%e3I6a@;FTYE>2PY{17Sup)ZB9V?-5ihw`BJay^9
zl8U|URdN%(1KW6#;r(2ckbO5_{+BN}!?rJME<|nY+CG5R)_p?uYsS})<AYc*y{-07
zFKqv!Tf)YF)0{{aHvSa%{nh!#2Ps=`*Ls_^e7MnCu5~-@I?;mBwka&k$6p+g-GrUO
zk`2)?qaDqUC1`(oXL{>eTeI_S>lTLq9A69o7aq)XrxgO=Q+fbYf?JXUAbYB64-v1S
zlznG@=mZv5hD3eCNWTz?Hotg4JlPwF+k2Bmcq=Ac=kqaV`C;F&c=Bgw##yxf@w=hY
zdC?}Rr$4j}>hK7N2y+BN8RdkO`SD{9un-j6Z?^Kak%Yb+EEMJDSRLeL4CQR`l_7*D
z%|uRCS9{T@HPd6$o&l(>4h{-j=rb}1g84|k=B6}f8)x<&)y-+q-qe=kBSWL3b-jxx
zrZ!!5Zz__E&Uor%%{~*6Y$gw1eDEarB%6%;SPS+$m1ty}=xRF?hRd!UZV5&oIjmXM
zaq>S|nEzPOk<OG^{@HJuUnY!fSL}7?%-7AXd)+YSO1&kSs82*^)W<LAz{gieebxVz
z8~%%?wcb9AtSNQh;&cm$l^gq#ZFb1)9B}740D(h+I+8!=K5--M0ijG-e7@G5WNuY?
z?g(Q8)fx=zs4(bef%Qi?NU+KBIf24-S<y>@w$aT>t6Cb21G2sD;}*B=UlbQrO^R%=
z$d@oPCbH3e4H;mzO?g_Htz?&9#so?m^v5qM)%yj!ry6UT-A}Y{w}ri*z3z14!p(WM
z=G>pnZ~^PXA|f<;V*g-d?0kERHVX0+?fjO3?}-8T{bu#VfLpYnpeM%h5U|T`{FrW-
z3-?OS41408Hy8E9E-pS%PyCe~1B`Ih6Fb~5MH#*)e7@H5zl1%JzSQUE8mG?+n3D|{
zZQM>t$@u4u9}9uHUnKjHz`Rz;{&1c8V@;E$p<3HBvav20aL?E`E>{yGy=k%7y<glo
zOt~Mj6nFXDZ(-vajMp0Y^}hD0u7SNFzuzR{(bBasa*_Ajxa6jI!|AZrS>OS3-npm<
ziEKEX;s#cQ6+ys0W$PNDO<Pv(T^~{o-F}tPA_cYot#{fWU<&rYriLKZ7lUN{y{Ql+
zpVEV*65Kyu9D<ZR-maPg(LV$>2Bbu1i_>W<tRkA+)5Ov>o|T6DFgUY=#h+a)f!E?x
zNzvsJY@tnL3$3K>beJY5cS>0g{*wAwE@*EySD|J=IM3^@3{tlSfU#P|ANap;#yr?2
zd=^ivBLz)9Hf(b9CkuNaJSuGPg(r#-^u?zq0)CE#@7lbDFVcO#D@6UJ+5_&Z9wQz>
z{qDo|>b&udR^}XB<TWSNrND%@Q0NrF0~3FEt>GY-r0Ba0D07E~{CSU}@8rM#Z^;k8
zIkV~FF&2_T2jDkY+;Cc$7SW_~cMd}_KVaP(3{!8}m>;8<>{sfD=qN)Io0c($<;I+_
zvG(NT+tHXLdHGhL${va7JvwqAr&1&-kaLzFla%t+9YbgvMY37~(7vx6><9dyQz=JF
zcV@cz?@=)TY|#;7_l833UTbUpy?C>VFJB|qGV6Bdgjnl6((Bjyf&bfug(Ro6^HCyP
zFVvc>UnPxVmHQPhiu?v}C+j=JQajw;ut{kRiz4~*T6d@xRps7qW6|VW84!-o9#&sc
z`JT>(Z*?sH7B;jzOJa%j>ZJP0+0WYE`|dws>`TM$2^)5gHLL}1Af55$ood)nLBsyJ
zpkW6UH;l9k)P`5@qG9IWgSPp5l=l*)Pg_1p^X!UbTA03F4Eq7tG@p>*t+}#&BUP<y
zzQ`jF9(c4Y$Hu*qCg2*inBS_TQkbbyHoLiSAvma%_4>85pT^n>n`?8PCS43WxVTY`
zw}XqVdVr>{ZuwSc%l#e8?~k+{rf2N)cN0sf^v(;icX|^Tk=<G=Af3L3Ml`ue2l<LP
zIy0cHChl)(gdK9~XTa`tan#HB*ZHZly%M;#Dc#jbUi49JK4K9;#}IaMvQQ?y=ONPi
zWwR^uuwCY}q#s_F(QYB*>p+(Sd2`{|su$Fb`fqjC-`BDHK3tRWWCbE+?YOVBtv<s%
zopK7BG1r<gmxW^nk?u3!X3glcW?-<g&6<Jd9GbC1%>WhBW!IW6n@*fb{zg|d#pkCf
z-PV*X)|6gd{j8>7LpPj~cbpNtOcm9ClGQ(K+pJdqqgMZVtA7J-t*rj_R{sXokC&>#
z`fIKJ`O|XsKV<bkZ1t~8H9TbXKWz15A&6P%a9~X)&9be9=Y;mNMWeOsCM4~a>_vy9
z(ruLM-nhnS)J<bMC7HODC>T~#$}Y2ZwM1gYZQA`%qk8}gD&(GYnOonatKyj6U|zPC
z8;aw5-eF!t&R6YUXV)T`xS1*z)v$K1+E)a%e~FTlcDc32RjWQdsLH5`smt(8orc-V
zj?JY<0d4V)jqx}5`IY<e^DPJ9=cWlEgu#cZt?v_`>T|PsQRM$#B|fzc3}M9f8|}X^
zK&QhS#!-~Uc!$GEoWokn`y+_xLd%@fLw@<aj}`Gt5@Kgr<?h2UOMdWxqu2e1%*2RX
zVsLB`99!Jwz@Y)k@b`taM*a%3G+k<9eU6VTd-Fjgiv{@ME>hWSWf#Bj%h0wSs0($e
z*&)<>78F6fGl2R<uCwF}ouKY^f8j+?Z@g02+aRbnxV7}S=kkkuVIFEzx8~2yL9KNr
zV_9qOGhG0;7f?W6${vs@$hX^Ns`Wyvb-ij`?@m;$M9wkz9u<6#x)xq$caKq>&JA05
zL}3eY`ZRVv`#95RlfWFyGb?znj88VG-{GM~*kcwxM%d^4QKNRjlSl2iD85754?exy
z)-m2>9C?;!DdWNr(~@JZplSX9-u4&b8_L%bkJ}vCTW6y(7+>8o+S$S__4WH$3O#oG
z!aJ6gyeHBwuk@#;%?xuq-8*$jWi^Ycou-#s;=oV6A8(_r-Fba+<>38*k<%`4PEtP{
z_(-a+FulH_=*Bsfoiq`NSxT9_vph69?H+3K+yT=(_rA+TMxFAG$!Wmy43|5onNL|W
zpQ4#hb+&At-7WWLxFr?hIr`blLBzV2hhp)A*g}LCuP*Ow*fjguWXp!0dL75)d|>@%
z9c!8`ouZ+_WDN^Q1-DeLo?miu_sgXnFP6j}BPkbW)M}gs%Xd<YLXsKyXu+UhmlA^2
z3CW)NEj)FOuVst5?b#AvzGcF4uA~_c6J?tj+#E|PKZOZnY4*pYMJmfp(Sg#3yY({2
zJEhU>^QX9CPxjgw(fi}e?=QI%Gs-P>E%z^bS8HPd@Y38v;NM*ce5&F8nH<;*T$w#I
zv!(Yevw)9%LB?Of@lTz!TW=@r)-%TH8n)1+mI|Bda5Jaw&?~F(S1Y!xC*|r(N>1s#
zWSYx99e8mRLLN1QJc`7tGaYJq6(h5(VGG?>*7E4;($2Y)U6zxy+K3Sb8}744;kgwP
z_ASe6$Ka%_%5GW2wd>ZorCh@HGqj-e_4EUqLp;-X%kGkl11C{Axqc9|f>-SLEfv!J
zK~~9?f+dm-P42GqC1I=L+_s|w5mF3F<-1be7j`6Z7EoWFd5S*viXT98s!41+^9_~T
z@X*YL-ekiXa9`H4CjR;a(0^Y6`kx|Ei2jGJE~K4$E#X*u*I9el;s3F&WzBLfh$^C)
zTzl7*$&q+(S;M;3hj69mDcK*TTKcF|o&Z_@<xDOV&?m<WxWC2;1aMCR?#%n?&e(UE
zto6noWA?e(+i-`pb5E*8eUCRnJml5YuU&D6@F^WInO?w?Y;3t2KJOWePtz1VK9$1b
z^YruH8lOvSBvN$_nO_7K@#SkLEJZmlK;Q3(4$=3?j})QrVLsV_d)VmfVU9`w{_=N^
z8R2D7e-Et?_b?8mg}cgAvM>#BxAskN_p>r^ccaE+F~J9yv96vw@#Jn-Is=Zuse#z4
zO0bOcKy>J$-V5&OE!#Y11aEs>jp6zO9XWVc>%4*q$)5|_+<sL-o5vI#5Jq^+(f@Ww
zR$nraF*u?B2>^<0dJ)nWN4#WO|AE^vgDVdU*y6L{<-MJAr<^P^c^3Q3aTTNG41>G!
zO-D-?NXwiYP#p(4Ldx6uSia4%RsREce4+DT-b?CjEt-MX+mvqE(CoHZ+Mu2TQ1{8!
zIVvI9f<JzhSB(5I7!oETopUF061JeVo5R*h2y{H7W72uyRe0kq2PFG!r1l+%P25kL
zv+tLUIkxAVj!)zK$(0tigq4k!ZAsP$`;zD5q+>@?4uQ%upAhlX_Zp)`ALQSJbi+>1
zswe|p#uVo!*M6fk5?1<G#h0&&9GGDpMuA#7@1TrTz_GK@Pfi0<F*K3m!}X?Z2Wrhv
zh0uoHnGKa?@~2O$JL+0iEvY#WvymA)_Xli>zdo`3j`f&JMew_NuZLn$NxJ1;HtcQ}
zoAA4vz;Ik1hVc=TZHO=LC|Ppk0jkt_;T_if%;)+HdwrQ#IP--DG#;J{*QOeVm{|Pv
zP!y};iG>zV_%nTn`;l_$&0eV;LmXmass;U&N%I(BNU=gFA&FBujxsq`!s;3ZV)1VZ
z7vi~YVX71~;6|2n`0ksV#T%os$NO+!J6P9;!#eisHp!QCHiwKM>yRNyp<$CkBVGz+
zZ&D%gJrmn6STxyPohvH-`sB8P%o;315(UF13P!vr5UPS}Oj(IHRE=cn#ovXhA(7;;
zk>rRcNk8%W`Q#8khL81URAGm6+8;3ej4rr1GW$o`3Mw2fxqHdIuD6Yo8-cFZwTmz)
zObqEXM`GBXBl<4Oc%Ar4b?I4W31ji=A>efV|6-~|WIDZ<XEN<9nVxlBijT#$w1cIe
zViKxh$(<=HZ1t4Ru9tZC-_%@7v^uTG&h)E1V^4PJN7VZ6R6?LwGK0x#+FCL>)uqZr
zVHQXw^t#%zcb1R&nEAM{X(>FsGdHnWPkKf`*G_&Rf4!oIs5NZZ3q8U1JcHqsU@#bl
zMDS@t71bEB5bJ5d7If#0KDx|GPFfP|Yx!Phl`J_<{n}+EV3=wpz;L>(1mii`<1?#S
zyL_vPJRSUWQb-4WbOhtW)5Ea?e|LHqpdqO)Jwtl9&FJCvVtN>~WO|15AfKYCgk>~(
zh{cnNNh@YyYRbZ7*Ne(yDKug&urQTY>_SgqvB!O<Ll-B7bU{L4?gwIOsV-HxFgY=m
zP{2wtK++cPsbV1ms`#_KL1Js8H0dr8z|3d1@7exBG98eJbsk(=uT4G$1hb8|Jija^
zk+<sL8-2f*S;>CLVX{Plbyf)^g0}0&V`(aFB!bRs4GkF1@tNC1B5zTVCz1a+q=-a3
zznCX}QS##3rH>5&7xD{@Z}AHutdMIMzbK>+&j_>?o5p#vVJw|)+%uM62$Qim$8>V^
zp^QsDTSyzv6SF^UC>GiflYut$BcAb2lW-~H6bq9jAu}i~<P;E=k}rfC2aF{6oLN}F
zD+KGzO}LCr^paT8zqJKIOWR<D1{4d^P%^D4Yf|iPxeh2~jwEuyN{DBq{j`vS2xr#0
zhCDjg_<%asdfCruUIY~!K2S~}C9ROBj96USIA;imNw1n_JR{MqGL3L%T2hWP5hLEV
zo?pP!EA*>$@HTbjIK0gu6K^xfLJlR~W{}yeCHo;?b(xjSp$Ce}XsY46W@de*r-#hz
zY{D3ET44-0Yo^$o6=rPC6X&4^7ZGP(zK1(rZ!X9h2DO|pq!W(#9EQ$@8(C>WwUPsZ
z!Tk6<B-Cey-c+h~95fc1ZQHK6Jk^G8?o04ry$nCyn^N1$w$|-iT3$C2yX#)`-1wf_
z*j>*uZCbgfgU(qpHTJ~umB`?d*j=9|HuF2^pQz4Th+1;UYY*b4y5idFo=Wx1-ui8p
zz$5L4<}>s&vkB5hVsV-A?d~Cp)#I-!yw!&vwh~_|T{1a!P&^Y&FO4P-POpf@o_MKj
z$&}Y(cODwgl&6=LFO2;>mR?c5d+WiJ&~`)Yi9eLZ;*Szu82j{xhto@kQ=^2gt&C@8
z@q0lnk5A1?FP#<Nqxa_)#?FrYvSMLu#WB3~>us~%F0ADBCwd*!>!)keD`qWuJiW9c
z^Sz+xk@V7$^hK)W&C3SBg0l5iP_|xkWtV3!r?e06O)uU1Heikxm8-Xca`l=kHyYnl
zxp?Ypu}_1s%JfoNwgQY*W?k%w7xu^Q3*%uog)6_<g^|&I-%)K-S0B`Q@I~>hCGnmT
zAJzWH)OMqh??Nn_GNrHmd;G<+(HUKqZAN-Nx!34%4gXvDzl{F@jjT~&h2hl~lyqKL
z62yRGefM#zFDUK2ury4YKI72zIWenMN2u}yrUkPA(yG)i0A%Jft1lSsym0ixm&RW%
zX@AYK98H$gc0lEO{FP|@)#w|q{rg@(9s;yAk;)4r<@~Sa|4IB0>s)<7S?7gi1+dwB
zF<d^4k1J}+?j8+=w%A1<zEo}UukC;GLuzsB%2zu0yz*5&>8^wL|KUm=m)G*Rb{3C?
z=kfSdBafvEc-(pGYq1pv^Z!zkt+;|@E3PBiiW^C`;?pEsaU022thjY$MrH2a)BzW3
zUqka3PmjM+8-JA?xoU!f;+fjroBEaR*Sk0E<(GSSUX6mF)IrIE8HYZyJ<AnjvG}Vc
z@mEUJ6g+{o|0%$V`QJ}%jrYe`^i2GYiXn{`R&09t;I@V72WRjeG5S78)UI)Mxd!F6
z4967*^Z!y2=oLiK7UCD4$Kz9tJeDrtap$dkxRE&8$Ky8QXkYrV4oXe`P|u6ozX5F5
z(X}s6V0rV{v~;q_{tZnpWl+~%-2VIc3&-G0YZH{f{?XydBjP>L_|~XzQE&W(GEeOn
zTzFCY?f`sfGNgd8Jx^df7Ma;M^O>g9=9J|+WcA^lM_8^+4vSZn3=e~Y&1-+{s!RsO
zCe&s1%X#lB;^(ds`;6U%gpH(@m)~|9P7Eqin>W2!KB;eE>{HMGId<!>BC*4N^#hU7
z^q;Xq^j!bUJ+q&saj}K5SD#%NYunEMA1{pk;+g5a?bZA~J-s)!aZ_0jOGM02dq?9v
zmD#?_`0&f=JGZ|uyL;xQ>Ae?C|MAsfqPd%|ds;p(DnQ*?v%3R|ofdm6R`*P7F2%If
zUKr4A7LYbm9$fMh7Y?15zT~W-*qlx6f24r*LlDmN9$@MQo=5<%?#di}?nNpenf`iv
zRq*w^%6K<r{9+_A+BO*5@Qbp|*^M-Qc6a>g(LaBe1&`gogw9siSG>VnPsy1Fo4HD9
zs%I}1<xm*Rm*;A?Oq)%1Nux~ThCmf-8_b*s?Y740g;oWN7Pr=pm@Uyg7ZfaXSwgl`
zYuybW@VjzsgKu;5&O>hEivShL=WFdGvo{^s`yR``UPiQ;pG#n3-k|$W#@wY??=ai2
zn{%eOb}M&qihfB5NLeu;1Ce$EWY@U@B)GHchyRcR#OL#Xs64l%5Re7{3D@UP$hJl&
z0v9(Fu;^3Cez@?{Z}>51k7qShjCYM1yXEEsi(M>N0P)fg;-+9DFt93QpUxmY(IDQU
zTamW7$$}V92%ygA^AM{%x9J3ry5oepe}yZX4K}FTLD)77cNmP?CGU$b@6$Ht&3p2w
zyDbEyH`v<?03o3P^1wMlUAHViy4@-|Gyufs^MI&4cV+;H^`Ta<Kp6@b8=&Spa|8Qx
z=5KBo<EX7Av+%BAYd`FKgVJ+Zz+mf{0m4;k!|W>H&`@hDcAtSZ$&?;1hn*~|;ObPD
zETF$3j*=~v5Pbaz+mR}0*_8!X8JL@pVU#@9@ty$*>=St7&)KS6d4Z0LIN9+&t9=S_
zTT5qYdBtC-fDsVirT`>yot5Z>dVBpeQmRQ&prA=C@nqR2Drfbf(H%ccc9ek!61g5n
z$;9g8H@4qXQE>0QA8)!nLmmy4-=LUfS0ET#%Cj%~SWu!g+y_%&B@~QT?76GyPZn`3
z`+Jws?ZsBDtLuj|8Jh0if#fhV1MK|%k%h0=lcn*I_uhH%x{?ewDcV@G*1dPR_BbC`
zj5$}qCs0X~Yk>1;xm%ZRw<*iNSb~bW`f}UpG^16O&@{U8MS8yDjtLjXpV>Eu)P>ue
z^`qGZE0>Q%7*_4tTk~z!g{GC<gF2S$tgau*o~Gm!Nb&&WSw6WegzR!l4Z=a7!M<cr
zNb>7}0e-4A7R+Rds}P|N&)n=xw(@xcP8nHyyWe-X0rq&jDZjhpxP7CZAIa8Hv?VX6
z+~-pji>HYJAoEJX2Jz9y$|97*1*8G4k#OLRkPOUnJECWvN4Qn_@{bJ5&t6GUcyC|4
zU+0-Yyo)dAGR`C1MV3{g-2LWQKvO9DPJ=LOW=4KK12|u}NgSb&+`{!xws_XLweQee
z8-pGeLPt_1oZNckA6#lWZR{_JzX*|RGe)tkq@5PQ1=NEl+eUS*?yS{WU<N}qUSC*i
z)O=SCW!#D1&`A(56cl-eJCh=hA7x%)g<@&b%P!lbmR|W18^O@BF}jkag;*rnfc;E2
zgLG1Tw_I%uniIJaQO-WwIo`+4@xIQMH`oY%gWX;3WvT8tpIMWgw~#SxYb1Jcr1g3|
zI`rt}5xSyuA3IcIl5=klU1?`k0+}LA{NYHExyxv;MYfTy9n%@cZ$J<Dcx<WenIm^<
zUIfCq0;jE5>y*VlCzlj(E0o>^H5Y2)Z_X3)!1M{284~~|xMIcam>d9eR0zy~+96=B
zGGGR5=Y^s!EN<5<N@-oCq5>D2E*TcpcSX=Hv!Yf}hgwnnnHN2Z<`oyUMnw&%D0AtA
z`S%CHq7q?IW^AIOo~l;ccbV4!pt`8Is38?K_n?9XzE%-5@a(Xton)~F;ti3acFNc0
z2)Ddk99{VWY-I&+$x>S=&s{@<KU|o$d^=T&{cw)r*Y)MUu9@L(pa>lUt=}Qo-fac$
z(1;&+$AytokGe4OS^ocs|2F<}9?gZ~)@=fP8zI&d;_^%0`c50Q1y-3kb;ysGy#1}W
zXT{$q7psY-3qUK7%yPf&?!iN??9^CLH*fug^=mP~>|x&||0Uz*mwzc(PO7qQN}DV{
z&JI|Xb}Ys?&~0O1hjSfl2JB67#%1oxXx-d@;o>rKMYG%2m4uFwf+l+SC>|W+O)Oo&
z-w)(DJg+QLhUH&5sJ_kbC8X0Qp_V(w5KN*Xa5x=Fu9`N>$H1T-sddL56F8&Z^a9@|
z>)R6=%<Of>H(1h0JN{!(CPqa$IzOf`GJ~Z*g^~$X<151utK4DCZwujOZ1&>t$T)jK
z0lXR^d3bvgwd7PK0pwe?BE^P?n~=1c2xF95OM=~hN_NdqHC=*W(~G6B{&YgHH@aHP
z+h8!ZVVg=T)pIWfklt%aQfXy^l9Ps@beG__8v(kkLi$){awil(p6eg3UU@qm;?oD@
z5!)#4zBksjDfZZQL@?^AsHM=Sb%2i%){64@2%Fx>ytTOLbBXCml=Bp}dJ+|c2(ZYg
zFUhWxc&@J{VrD`?u%`&6o&7AW=fypNAAUOk$?e^&MC!SFdoo?4Hx{x{>+sOCve}((
zq!=}<&+I)btqPVNvNdrvza`m&eIT;BOYfasa8c{}^0Ks`j_+Bbv>yr6DnMHObaq|E
zGxk_QKS+_If<Awik;fn?cNY<l>hlOt3zjKmT`G|bs-vtg*)@;f_(naKEG73f1l+x0
z?n%6ndx>(VEhQI$rRNi?v&j0DzG;C}!a#K;XC)LLTlE)V($dbfRwUEs5$|)&G$<_Z
znTpintG?EiFPWC=vUEgUvIb`|=Mb&YqF+j+a}<JZd0IXd;PZt=S-vxfRzCgud<rGI
zYI&v-$~`@y?n<TAx6kz_6V-aN@6)?#?2EeixtEh&ReH1UlM)Ii6P5OTzMk5z&}(w;
z>S*RA#z0Tv5?)oOj*%;DgG7N;m!5UjdZq-HkZ$RLu~~Yyvnfr8PRhj12GC1GxuI|L
zZRhV`y0f31-CfpDF_k+D+4r4_&9L3ls2M~#`#>loEqh^1o#;j3ZgQ9(4qUPO2GpJM
z*?%o7nfmkDPnXqKP32Y~D?!tT@?@oPI=ESC?&Ohx&j$JN%|9Y=$K%`FzE#ooe(`HM
zFuI0XRQQMr*HX2-YZ^ySR;^_IjhX?7zeliBcXqviF5LJI#`8l(<5_d)_K?nB#u(D*
zoTFl+Xz(imiv%S$0l5tr#A!6qxJeShhNP04q&&sOB;JUwR2Oa3GtzcGY2s%uS#qr4
zNAA!a`k>CW@niEQu#>G0#!71l!EXs5mva4f>Z`ea3ng&S9#_;J`XYX2$!*7ml7)9R
zsyRccIo9i9v0KVBr;^25Q*zr``GgFSN`}Zu04Tj30NqtUkur9rb~d>m1O>c;q#=!3
zHIdN*JGqQp#(ETho#?027!ce+d<b@OC|Cnme&}W^gd5!c`vIEJFiqM>ianOL3{R6G
zNMgg5>TpzuvjV-PY$$u)7<<erf{SCeDwF*5nWV`2oAQzgy`(HEX>7JAIo*;>Yb+}{
z?#+`n#8VcPOlx=tJn*MD-z^%8Huy9RwSXUeb;i_Vt2P>o^JCOlOLTS8_(Oc7xJ0CV
zmLJM>ChXd4{YdUv)g@`E!QhLt-FgYa>_7F`IJQs51U%pDNr?3;7WalGXAB@kri^h~
z3C37VNYq)2+Lp#QDsD;JEuMkanY0BA%hR*UB(kqd>2gvzW&E9uFss1JCFD`cn#RVM
z5~uG?s}ara*Ir#q8sM30H9Sl(MB0{x)i3cC)|s+G^;SU7Dl5RM_d-E978ZQ!^gRY%
zGF`1!=2KWJtuiwv($^+eZ9p(8#RbiOR#10)IO6^~9E|x}Sb$)}9iCy%Ia;89v=AS1
z&u?c7Mqx1iHjEvAs6!Kh9(Blff#DigXjKq}ul-$1QQjJX=w0f$3g3vN@o_KslAf1a
zPp7NW_m*NoY;rsx#`6K%vy#|j^U6~8DfZZ$(z0H!KBdxEQhMz1Dd}j}8rGeXL62GN
zV@;*S%2|AhSMq(P$C}FY*>^IX8s<rR>cpSHH8yqjpm@ge8ACH`A2|NaVfKEkFpZl|
z1zIqBRVcqTE<F8aeyeUZ4KhGkfd;`5Tu*TL^*X8S;)rKK?|a>NnD+xL)jh`|D`4M+
z3_p-B<zCer$*Fpi*B=AgXCj{J_u2|aEw7Rzg~B4#-vLgttru3uZ`t;->q{#KXB||i
zA9Ba87ZZo*(%;NK&@6Givm))YXFrP-<a`<u8eRViF50?=2o9Qlnn9C0H*Hy2NcBpV
zDK@v$Y-4V^5G8#QZ?Qxh`E6Qo(`HqYnqLApJxBQ2sAoz0`_@Yl;C={69&XIR&kKSr
zoxX>!?u|bM-P4A9a8ywHmihc4B2v}HUg_t_y`Oy8Yeif`AG#;PB2J@-R6<{7KfC+C
zRC%sug#Y~VXhA9QWtGv02EYi(84@;oQJA1LxJxfGE-5SzT)u|wdrzWTpz+s}sL6${
z%!RHALYUzZg6Hy--lSi{oCP-OiBkEXYD_41s!KW19^QX9FP1#jUOszt(%jESC;bAU
z&ex=+L36Y8s-5%)EB#RFbreY=W_LF>r_w44`vB!>b_>7E@r<X-hNkXG{+DtlH!9}=
zlYfikh1J<5<iV)_5L+HLpf(d21NW<J4jGcAW1+Iq+df4O^PG^KJ0%)UBSocQM+}2+
zO&z7+Dy&YCdeWsAbws|!nNP7+g+@RV>I}t8J)K{nXd_D#7OSj@xAUCYrL@Ve6BLus
z6RxOmT3>N*##7qAevQx-NG0?{nDShXlOAQTauvva#HXI=%S7N?A#_)2{+ejr{Le?*
zX8QtWS^*jvR=iRKbN(feL~)@L%s&$BnHrc)+6cUhk)7(YwopsO8f@_Snvc0;&E90X
z(W3OB*{wD<$S`Z=HJIxuh+e}pzER=G(vPRQtemu7H4U~R(n|82o5Uo_zIORop9a}r
z1+3y(y7bsoLIE4{D@T}4E9c9TER9dulc*$)Ze*BL1tFv-Av_N8Or`a-0ii&wvs%{w
zT?&_3gX_A~J-6Xd%Ho3h!0<{~OgW!KEBaL(DGMbN5#D{tWoZKtt`l92t$pGQzMz%y
z%+a5vX5B-d#%7wkdM^@?4*|+zcgL+7OWUPlI7-LUCGR5mUrHHZ;g#7>Pue<Zdr+fK
z+U371!*eg9ttoXuv*IIVi{HIJ1R-ACB!k4mlQIgJ{cLknDj_fskAkVmb#!UiE+d@m
z>QDvNiJl!OA?!d2n_UkHg^}}=G(DGRe4{c%ZaXBtQTa!gUK(cRIEKDwXrhwDe-pX9
zsj=D3Z;eFCtbnOqDj+D#!aW89rJ$=?vEVJfQK=%a&$0azSv)zuQFV{TK4%*kMl>Ey
zr3X&c+3a4uk$x3lvx?9yiG|%&uY}1x?NI`n|Eo_NV&e`y69am7Ii5Ib;#p_m#h2Z7
zXeyy}b(Ui32g7DzP-e|~9-pKIm`hwwRd7t-LPJp@x-usNe26m|qnwf0-S2^c^(1c9
z3x7R{wp?gI5E7SB*feAXQVBiljJ9KOZ2-!gIc=Yq3NS~bdpk&yL(0o`*G5H|)ibqA
zb#Ss&PYb7fI1werhf@|0-Wn${DJ@KD1F$Tp48F8FT4(u|9L)(;^26?Y=J>Oqr?8Gr
zzLpv2;?WGqnO(lZq7O+vWF~>CR9A!ym>G8MQvW3S)jw%H>(XjK>~lLs7Kf$mdtH~R
zip94W5-SK30G;!K5J<GJ%_|hiLJrS58}Cb&ge=6q_%#=47WUd+F?+P^lDnf*f58$%
zT1B(UkRB9JT|)+x!edHEvigFRseMo)P&om;D49_Hj85dd6*a9gAUk=c=a*2`?Rq!%
znChw`Oo<=7(-WLXiKPYm$TAIYndg++@)+6F@+uVQ*HEB<iAn|PrYvC<CWz_@S7Em2
z@*{J#D^!j)$R$}YM=j{Z&spj3a^UhM-BetjEXn?=5J3Fz+se(!ED02;sHWcr>+krp
z`3@sp-fr-~5r6TR`0K~CYXyAkdF7GpRAQT4#dm#*mc3i&l(SzuR^cryk7<SWnVF;S
zZFZjsiXKltUO70(N%;Kws4o1tZF=h^?01BA2UpwH6FP3{_yQf5y(H!UD3Hv4^ejy^
zM;|%Ey&EMjw;`4|i7&~nS^93_NePA9S#P+NUt4cbAhJ5GpU(6Wo=orc!)n0c(5=22
z1z!?`vQ_)XRwBZb5;@J2sky@G6L{teLt#CKh)_>b*z_ceMc(j^PNC-%?o>OTtdX)V
z6*o1Zf|6Y|dM0X>!l$!c#WUP{QJt*ChzLHWS5<C9jX;OsCBLh4>HmvFw7c^qep$kC
zKjdr}2i{4ua-*L7t!S(8VcOf#e#UGay6VXHLu&`|VOK<0g3nDi;FgrYSI{8%V0!|#
zDVPMi*>*Vx-j+@2|IzP(Yonlx#P0bwGA%kIow!7EJ@<qq#G8~YYjA%Y$0%}J;%BFP
zldu5@zkkKqclJk1(_J;pvyqRM1=mi#vYk|xJu}Q%n#;K$mou8~8f0mv*`<qfevO=&
zZvx&*gSC|TO4|tnb%U1JTx<-eu_918%VTR2jc&J3hrU6BF%x2|ja!rmbAHQb2|+#C
zK&2%?PJiDDOVMG@QgYq{n`m}lEYA5FrwiiNi;-p3DeH`&&?fh#R}DqkYNUZ6c)mF-
zf4TpHDF-Kx`Lt+a*k4nzCI;>4g!(IovIf!+%j80Vje1VRd4d&d%uVGpZ{oQ%avJ)%
zl4(Ci0Tr&&n%!e|X-;|eY+pnKOAmwC_AOLImUSEz9^W(z&PSk=V+2;1j;JW0jd80s
zIVEg%?aJkqBH`PPFl&UM%re<QpQkc8GRqkn1zFJNne3XYaD6S+)+H2P!s=qJX|!kZ
zrbQLSCcE^8hq<zZ0?EVzo?8>2;mLeOz|^G`rAxmU&LIXL5RG$)N$VN-*}Rlb%sffQ
z?3hrMvOn{cx>h|xV*V<3xd`hXPhl_p!uL`#aSeG^Zq!qm7Qd@?XTi`Mrr2<3-oS=i
z!O*;(9PmV~{&y*ClOzjl)N{1$(<v)Ex9Sw%Jgc*7F`vf7dl1lp_%zcxrp^kyZCdQf
zgwn@HX0@?*B;1r_zv!`3mR2RJt-Q`DcIymklS=SiI&z3DWf39Fa1WMYbEaXIxe@W6
z2G}SfjP&K1!EH{C&>|uFPSGIP675WUnk2AY{lLQyWBFJRv95HmZI;;%oe9L6oy7vt
z%P-dgAgt`HT)tN}G%MZ_1ln*7xtF^M^-6cP9h04*Ad7b#Pd}3TVXA%cQ`UPHzn(9V
zY#H{9q0qJR-M=738(n0b$<l(=AlbKHHhUDK&8kV=%d0L-&7V=Zd*|-w<2xfs;*z}b
zttR|do&Q$Dx9Ul(n_(JXt^BN^{3*4QP$j?5WzQ$9FY_^+CvJOo`!Bb@ynW}SU$qbO
zeQ5XfGiq3$nmeO<_aDl(FFv%6bhni+KDdswOG`eC{<Zbe_Jemnzk6r=`N-ARUbi{C
z)BLh44BW~Pq>4O9m4Ji>EU=bORmJ&F)qJ9b?MIm*KXn+ib7xcl%jVh7UV6uevzHmb
zRl)#eREz<*7l5n(iAPlcZ6(ki3bYkV%V*O1qre8g75r9SdPfNObyw%$4);Gg_MEq5
zTF0K+B?ra6)A!uVPpSHj7mj((J*C<EQ=vW2N$f)7>h5b($MZi$AIEe4rzTZlxR+Op
ztiL%QDU+!7TAhs?WZMZwB%eUow+(Ta&}b&J4uZ0cq<5jeZ7pF#7mq^bSFJLI=M*-6
z90wJB+Et`wAurzF(S8`ISGQDjPVryFfcSEJ1Oe5qT`}HuS7LW&H34S(D__9<?`ZoO
zE7`L`X<vLafzjVaBDYNo-FmpzADViQk>xohh?FUzpYtX@d;e(rOywG_j4aLPIz7nc
zNKP(MKDman)50Slt};lWDI}LOmMq3O|47-=>8-O4&MSJCw07`@qWATq3Rsxgb`8V9
zIh-kTLY%h_N0xFMle{ZT?w~->P}VTqiKSr0rk4*&wp3)F`vFQ(WM;#NVdlC1v+64r
zV;Wje*HvL%?<=fJR>fFAjZW(GXVEvQ?9M7m)-e{H32k%<^LHHhxC?1Xzd?Uv2@u``
zrcCB#vdR6>dr9`zfzjKLS4hK1WT`CV-XLIhbJ#+aFNA^?a<FyG=3~D6GbmGTqd0KW
z*@6p)a<&HMTGwNcFl3TWVhpn$Oyy#C>rP}jp-VT6y01(YYulLzP*-{mHgZXFlRG*D
za2HM?N83-d?YTjnu&s8bhsiv3$D$ME^YQl#1X(L}Qm{FAFej2n1{Q)iJ#HD|<ewQc
zWmeG(E0?2d(b87nDOq|gX1x;i+<)8PR%RmbQu)nlahqPAxbhj1<wCO<b;plFMw25r
z;^AyCMqxt>F=Eo0LF@>1j+lX@sNupW?r)#2$%;O>!Veg{l{Iid<Y4AEk{#N4RMYB*
zX4aQ)AIWS4%*=Wo<6SN9QFmR1P=^<Zuy6Yeb==qe`wbd0Ro-S=4l+R4_DXM)4Z^m$
zN5LL0!LlF8UT9X;(QHHZTtZPDZ4Pd*&z?lYJ{0aNC+5aO>op9&*2Z!h5?`n;91`_|
zW%4mLn3<0R*9EhhS_Skc`*Nl@>xJ~}r?a=Lt}n;Xmo+2#U~;pc6@D=TC8Lg};frVs
zC%knGAOD#g%1^i8A=|Fm9BOjEq>rUbEFX%<&FP?(d2sA;%*k2?q0~Y8=C3NFGPZ}q
zqxF9cWnIB|I0KFlR<_MuL1kvc$uPmb+i##$;MP~ydTO?)5yPOv3|lUE+!Y=Ih67Zf
z%M-t;^XTJvU(SucGZ|4~eZB4_j%SOtw!Pm>wyBk#8qv1RNR`#vORc(bG4G={Etjmn
zg&Jsi_VgfILzNDolWo|t;kf`H8W)wce(_q2^MRfT@_+a|w1SgxX&hF)uCw7#s-O4<
z{S(NO5A)6YGpqrEaqcAiD67Y2hi5)`zh^}iO}UH9+gA~m7oNHcu7jDz9*)tcm2+dh
z9LtY?%b~o#qWIvfU@D&XROHQ{TTg%v!x{OxAyw{~RzQ`8=5jHB3K)QOGF%?p;KPl%
zv6@ic1BS3y>dt(U!Hp!u92!T2<9xr!zSp>UfD4^7ez{lsv)<d$h2uGVc6Vw?MZ=JT
z0GJ?~u>?0R!oO<V94lqVBC6csezbVsXePtZvO-hbUSO8VC2jA4%uCy*x2`W}=~ZD%
zV}&h+pQcJ}W2C^>6xkuO$%u-DIFUhKa^y8=cuRRtDRiuc->Qo1t1$$Lt<nOj$r;;o
zsfGsey%7a-LnU|CS!s;9F^4l?)!-L*BjQBz>IGu3_-}OI?Xj*v&pl7JyQ<D~iZ)Dh
z7*h+mlEX~18CyLi8XrQ;dmtLQd4o^&xe7*BrjLxW$d%;xLWv=R@f_|Ffd2b@&3wm_
z=uY9v*kc%V%mAU9r9Y10dTf=+oBFD{`k^JKcp<u74W_ekD^n2yA&kI@Sy#+lt1^FR
zwbAZRh3y_7+D=vs2ohR=%`}BHx#NE?Q{3pe<X*94iX^i;%twXCMf3&UB!ig&pxoA&
zYUvlW!q-Ir9N!wE>O*9YJvpc3|Aw{KCJJl4!dkEUIVjBNBE$l+!!ZR7OAwjqurJ<?
z=os&E4ZD0-vXo|^<+}2BKMLVHW9*ocalMTr+Gss^qrtL8uxxP`151|c%Pp1qSvcfG
zM8oj)_)h2Vs{Qyg<G=F8d6DZM(C5bZVC^{L-$QSf&*FgnN{Z0o%4HM%?`o|%B*z<C
zXHsW4Xr7;94GEoj<3jo$Bpv^gbMTB)op#yj{zZNh<Ul8q&)RyX3RJ1?!oSGY+5DZJ
zO38ul;{t7?$9tbOE(2s$HS!Nn4O6U!9k@P8m9D(qvkiQ{jpHN!Tde)SHZsrBCLyl9
zS(h;nXmM5^YF$~wpy?-`LAM%d$(3)*5K<D8{Kt*$ARz}M%O}boVv>Tglk9lb1WEm6
z*>%|&Xz^MKX}}wbE0af1M<<#Z!_eZ~Z>X-Zxe<thTurEizNUtPnkLb3Q9yQTmV+IG
zX1*%rJAwxE&)U~x!hohk1IF!nN#~rryd<C(ac7k&l52-?bIxL#k)MTc)0qpaL84Q1
z<@ItY<ESkQ3MfEKBBX$wu_6i}?fERTxJNi_o~+*@3fSWAm0JXi_o0AX*47afs8U`1
zYeoV7n8<VRB?Ic}0y#6<)(|ZJw4wZ<WPZT)pCu2BSocZUJPTfAEUaNr(+Gc}X%G&v
zy}z+_pEU)$vQpL?Um1ZIIFZ3cZu_%daN6R}#T8Th;|1+?hZeP$qjA>WO&n*>o$q?E
zoc7v5v({Wz-(I8mmOmG?S7+9B2&82LJhZO9a;fMg+0c*kPp$)L>Gy{oxRcyCoUHk=
zG@p+C<0U>z7NhO|7$EG~Pz+R#gRt+NDTM9v)Oc3IE)XUkv^zmqps?>`v~GW)$s>&0
zB{r8fyW}4YVd~P~Oi&ZoOUABuALDdPMn3YG%-B%cD;Q#{bj*XjggPYu-B}Qy7fs{A
zbd<rgBZO&(VA27*JWPGat+6ouWzfS^Us+ebS7fV02_{K&FoEi~;SVvsyjNs9qd?pK
z8OcJjJ$7<YH<H$l>AfCR8y{VCocw0~S}qDa+2*qPZd9r6^FzKHk5lExWG9PW<q2qE
z@{-1VfvjNv4P9|caAwW)G403Lq}5y9#GZ^!L^vH{QQ32{@6GEAoMsEYNmgfTvq##u
z?JvMFf=>tgMW_j8OatrR>>Y*s;qT`Qs;{-%@Uqvvqa0VIxm_9$kA#z`O7|9g<j<^_
zX;Q26SfGosl20C#SD609g7i;n<nEsyiF5g)ayE0^R}a?x3|cVN;Wz2hioF7k6qEb7
zws-1v<WE3=Ze8wPQRwix#;CdAT%oA!&HGrHfA3kMezZDh4(gYQ*T=N@BF9urZ%l#G
zdBq``wHIe!^X+ydOLtb<hS6T!RXmh;?>XH(R`u)f;$U6NfQ||n1GGs5U~(!hG)WFH
z>wg0Myjt@nYfXjw<-QT$M$U&8UVrhAtq(yntb9B)v4HT>_%;0nIU3z(?6etea*Ga9
z>}L)N?y_iq52M3<yi{~KB6V=Y)kCC<DwQflDv6{zx+?oV#e6%gzYQONmF`5#H!OM{
zc9V1YE(`LNkxv+_a3xlsdf_^0pYD8gH!Zf-kLv3uunF&BpO8N-p3sBuR`ew@6_;CV
z`m4fyKyNq*sq`iO10`k;^Kkxdf`{{;DL|KIRJiTLh$<@F5v0@aDE7-i9eTah0Ft%f
zd-VFq8^Y3uAYY&|a%rEU_%B=hY`@qlRgnQmx0iD&in^NIA)Y9`F<{I?)8e7YO7A^h
z$wCq@>`&rV{vnj_jTR5kpF0ht;5rlKIM^V1;FAVvu0J1$hW$BH{qn^~L4UT>NglHQ
zCY4R=Gv}*E&s2H8*c(95W|VNH<qUeXE|+s<F6Y6yK0Vp$RG)s#`t%l)8eyM)0Z}+k
zpWaS%zE2nFE#Id%QDU~r!y3!g*p=(m|1Ar9^?bex`uF5((d$<Xq+GB5>VMU%?R0f<
zuRdk*9}Tyo3wxD*X>w(Sy*kCivx2()l8EnD5{CU64%(o9XI(B(uCqG!+!*u|*TPh|
zAESX;Z^u^M0vZ+7iU1Tps&LmTbm+`^(L1KMR!%~B2~N$=3y1bktQ`fUa8fSsabaH8
z7*y6_dT)$sSFNRA5haRf=ug^^7)HRQ8mnzFbeF#VP7y3`%_|SoVku>J9`EUWxKT;E
zl|)w|X-(yK-_Yn~^<^-76U(rpZO8K5*LD<(Eauj6#QP);Ttl*!Ax<|mf-4=kCOi8l
z#9ydwJ1z9MPl11K6>q1&z9brVec$x@9rAv8s7HO2nV!x(tY#^-!Mgo)iD)eGS&D4g
znJQh~Fp8@<G1p-+*WwxP>Ux)*g=;>|k>EvKfvhIf`X*>*L5||N;_CVVJ0VikpI_J`
zT6)jI!v3U-!~XnC(4Y6oK->EB^9sFLf4%{+YGz_b`Gw<aa(SD>yg`4?(YyMyH0aOM
z6cP644Esud^40ots(pRa{v496a@e0!zy5db&*L!OI&goU5wZUK^g<Zv!eqlfwS58b
z6!a*c_Q|E!+vrpHebA?uJYda;kCYy`Ps6dQU+dqMgEG9z+mE0o`$Z-cPOiO}2rFRT
zhn*;TL{H)*o*kq&TL$*wc||1HAz0{&6E3Z+J4tmmfB*4~G7v&-{Wr0&kG8I1SVQ$C
z*k%#m=&t^*RwAkzu{Ge`J-mxP>2=57v3Jz_B2AVAU%sy|T>>F~cBEa`1Y~{(V2dJ)
zKGxbNUNN_V$E`ek(ac#WRM25Mrn;IjNaaVDtzK}F^-ZHY_b5A(%tFJLD9gLmijRD@
z&5B>;i)ZdoMFXY5ku^o6HBOUDOfYx`(6lJ|t@#Fa>07h=?03Qj-p;%G@vlZkxk^#N
z4qAlpt@ZA`i3vaSkOsqHA~M=O#qxq6jj>!8lM7J71xmC?DN+WK7P7IP<;h+dhZ_j!
zFUa^AD^-!1|EH1ai~H}}@|fmm4PWV}@Z$$8iy|{}jF|bfYFb`V3QZ8w?5XP<KGFwp
zHBSNV#0TGCi~o9};~Vu1u=9R0v}!dcL{KSP>3nW>S3MjesEv1bF<qbbw?~}%*}VaR
z=J7>;!G{Y(9tlNeeoK*DfJzVqSpj?am_v~J*KY`%xqQb2lc!<kJOcU)a_qic#VIng
z#u{(slo$=FeaVuZ#F_l^4b0fbEtW-**#+6FH8E>%F?`G-swc4^NG(egg$2*br^#N+
z5Mi-xf<bi#U*a3}jI>XHpxNt7DF15nh~3Fzq2K$qo%ZjqhbVIMif{}E{P`SBC(^6~
zT=NLn<9Gh|X;OKr3CAY8eE0Ynh)aDPeCQSr+-n>Wh&p9>jf~9ZZPOCzu>Hkm*Zn<X
z^r)h<TYvp)i2LZE?~rlK`rTUpz0tj7J;*Ja*IEo)XnvJn_(CgY+Oxww_XyLXN_Nop
zI!92ywcp>T?mY%+rId>LqkY=qZZK$^bqBT4w7u?6d;^cVdj;+JsR!Or=9*yjN(t5l
znNP6H16j^Qa*1HS*4|ml*5-p3!eM1=NpHB(goSHK7LDrAQp>JpxAagtM(&Sys@yAs
za{JZ^MLUZ+!SLV2V#h=|p(u|mFLoo+S<h_=4f_B&WFf&7hHWe*GG>d)%JE~$t9+~S
zDw`JpOt3xi7>=S;8k?G9DCBR2ZwFg-e?RyRe{=Zq+(TV!GvoQb{vz9s9DbA@O=eV6
zYLhsRVgBgbKQ=?y{_2VC_@JqXtT@!Jw2v$~P(O{ci8Nx+R~u@>^62lkS00y8(NBKx
z8LSr{CRnvmp#rTuwI|#X%_-v8v-^6Bnv_e=Wi7Pd4+g{7pX~-Am0Osh0N(!-eO~Xy
z+*oo7)+he2^!ZJ{efD>x&n=Qff4A{-(3`_I4t>t`^%tVrSaPm^is<v3UL&IYV>5*P
z^Z$oFcN+A6FZz53Rv&MVJ{S0Ui<*>c|9<qj*|uWGrBCjs)7aE<@i;DzysR4Q&n+_f
zVy*RT81Y*hfiEzG+AP<5Sm+xG?!LHHDO(rlv5wmh+{9lhN0na+FBO@yN-uwC#r~+U
zipbxxTI|6ssQUcks)tl{Lt)iR3aU1rZC}_~Q1$1eK{ZrhsRRI{Z669(-{<gJvh*DH
zagM-h*VdNW&uSTD;a0X!@&X_1b~tt@n*CC;4rOCj^MPO3vMnN~nk5NM>S&+e0Hii#
zTP166YU=^_p{BQX2vfnlyWLs<np<`kp_xsnS?*&~gy!QY7c~2n9?dGjed8Ctt@@sk
zYer;b>0&los%B_Cd8gpflo(?b0k)G#Z+!U<`FtBH0AOhdz>dEb0YJi&U4LakKl_v(
z0F~g53jmOpx9mHGlKrJHVq**!G5Tdam7$831W_1xn8`OVX>X~<7?Mx;aO0AOoOidJ
zzx$!xJI$s>ezch7W0cokW!qFiP<!O=kfn#yZ}H8XQ8j06K{44Xi=9;*D|;<1U<}K8
zgnf(pVfHT;e*>jT%l~(2pUm93_`|1L*%}~6T}$N>^?iuq0c(S7UC@R4h2j~9=KJ`v
z5XGMfb_s)_M8cEZa<-mwee6@VHY&49a6kN?d>?1)(HggwBFO@`bRY=t_;SNF!Uj9R
zO6WIOrO5fT8?=oLnI_aVj4a+(;CL=jaD)DUKX{jA|5yHS|8NoA7=L(({iX04^!@q6
z%R79d%sb#g#viKwCjM}2an;5jPA;r^KmPFP!m3loA1aMMR2hG$VrsCW4gOFi{xIk0
zfIn2Rh&6^kRM~E5A%DR6Cj8;(=R*EaGd_Q)`WyMfd;R`m!6x-AcRu?+IojEeKg6HQ
z(@sWf1E}f7AFBT*{_v>Z@CyMj{?J`f(9iqvhtdE5;}6He9}Zwb#7QTUhhDJ`=y3*W
z))@Y<3*D8KDHiW*m@%;gjqgZqwF!JjGIEX7F~Zxm`<LuAa-?kc^GOyQwf~4+)(|T!
zcBYXVa7feSj^h$7<NwumGO(c^_QllXUpe^C9wXV<vlcJG-)Z+1)F#u-pfY%gVrLb{
z=0Fe=xQz|zUE(O>Bvp&=GPY6WIg0I*+16R5Jc%09sS-yiUQ}d9ht2rF$LY8n<(NMe
z4L&w<Pj)jW6;Q=~9Oahnd8&Y;n72$?VdRYWn~}iZCcz<sCCu7%B^|r;Ii@pYHUdK=
zsB0OAqvZL?-==R|;&&uNIx~K9CHqYW<|kk2+mE08ZTiOcSBtP|{N&e%6jZ$*KRKqb
zYVngd-|rtf(o<Zp-!F~B3^(%o{SGIDWB2=?`DwsYOgc*L6zd$?LLN`&VCA;K+rAt?
z=Xl|jqV}53@kh3T4$M<d{aK!R-dg9tu#F}5H_<s36a!#9<z@pwJOia?Kc4d4pXU2o
zI>&e>iJqT?Gyk{NH;!L_GPN-Xbo+xwI4j&Exv|U$*!@epp;gwTZ=!S@LDzXkQCJQu
zPKp+%D2&b(AE+IsZY+Ml>lU%QQUGKpG++{e^+A>AB;zR_vci8;#bac!sH08sh_aEL
z>*)R1#05XecXYNvR1NrYkQH}WHKT8g*d;8o6_D~_FH%2PQpYZwC3O@Kk4D%eIYI?w
z>wXGIo?rZJ`bSN1+l*hFz$Vs#`Ng7bc^b-S=^c6hH|ZY_WQ)*h{Ng+8%jT-yk6*m{
z<ASQc5b%pivqMD#!9K`qAlL_?fqcMqW6mku)mNE)P!Ye7Qevua0l&aUCiX#Jc_!o+
zHE7f0@C(cy|0aI%$je3THGZ*?{iPfk?Wco`KI7YKbCkE#LEe&I%qj-J_{BK}z=8P1
zodE!$4$@M?>eo0cLHe#a`IyB$bmX_IkIedkagp3O5!Ev^0>{;87Q3Iv8Zq7%VG4uI
z64vnY28<Xj);`kngD$V0{d7~KH<;Sh=nk^zoKkWGV=lhwiu|aw+H{hI=viZ;b3hcS
zC7Q)lE$;BThvztU>H1CE%@z})j85@7%Q%Wjq4V`|6_dMN5viDB@<n!7bEL8#$Jx=F
zClxr(voIE{fk9F{!>wvkP5cFHxHgq?VlPrpI79)*@d}DZISL9nLIq_k$GI%Ei}S|u
zfgyJ5TT(YglQ++ZrUv7K=LMGrEN@7C5G!Gw3qLY-8KKhH;~%Q{|A>1V_$Z5Oe|+--
zuF2vq7&Ibklwc9mqNoJ|5`k?INt*!iwZ7CUZc}Z&vg=zxlDp6n*0i?OzG+)}YpYh;
zVoMdRVgeBYr8OwGH>rtkFzuc72^uw(h=KgR-!n7MKDz{@{r`TSfA2Ny^E@+W&YU@O
z=FB-~&XhGFAMqk&a?7n><aauCk>E3n0%bdpZ)FaXY;vz{(@3Y7$T8K6Kdg-O{!PKN
z!mYS<Al&NXuO;p;07dR&*dgoo_u_Bx8~39U!Q)iSS>eXugm4n+{liH-B=tiKZ}kJN
z1c-%O)5RS33+nt2E;ALwPW1fX^E?TGFvH$FU^>U2xD4GI8GL3=02kNs$sQU&(^N)r
z4?MdXVpk_-bafb>oU!^9uDi^K|KvEAEGc?cFoP0rUgOCSYvxZ#y}8@OfCN_!gXGik
zoQK$>Dh3SN*hEJ>o9Hh^R^thVlC%Gj!C4~jr^46k3SC_?QX0f2nh?~zNajj=6gPLN
zN6<xU3d^!b@kT({4<N?JMe<qO*l22O(@*_9qiGa8N4+q3Al<YsshcJQHTY7xX~frB
z+xrAAI?aAW7STYZE$l@^EF<zvZ_o|>DlNT^a36!0Uguh*2f8zmMilO3<@X}3OGbJ~
zY@yeD57H@ykXU+U?M~8>rkV8mq;0w`vuOx{$*SR?hhDm*Zd&N|a&wwqsrSf@Fu*gx
z^FJP<*KNIe{d@2bg(OmNS2F&5?pl<=c)3*k3m$p=n|`JBs+Oh0ZK=oc7AAZV$N`CV
zSg#($H(oq#<;p>d8VU}In)>Qy+!<VnYZ?z$sfi?koE(6fMX*;%)mF@uB?-nB3_wnb
z*4T$v2%tr{XBAE#A*aMU8lB)Xi0s3;faD~Gb#}yXcp~Wwu8MKKFn+a#P+vtC6XBNZ
zCCH5bSiv8{5BLMa0mvoMs*u1MI0J*8h3eh?AA!*kumU{#A;Kgi+|_4QrE0YW7;-&{
zC#`xJL*3_#{TjkSw=C^pj|~wK2%queOMUUKoal*UUB0YTx9*~Lf%}%8Zghs>Z`hw<
zp4RInF2(fE#GyGK&eej!p{FBi0r4NK=|ENoNLu*%SK!PiUU?z7^5XZcuDm$*UzZol
zBU3Q}Auk5HGWcKQg&&6*U3sBPMmD<gV*X|i6F$ljG^X>Tlo$8ert31B7J1R|k*8^0
zQa7#nzbW0cbG8nRG9JjeA~OQc36L4-5JBWS5f&3ySK2=k?^$f+MdsBAP|;!GmU{#;
z<?96&>7B_8dMQrYHeAr=(o2_&taa%%#)EW<O0A_=mVMN_P4UXt3vJU?nN4GxGFe^g
zZCaPqO$)t#+L)$SN-|HviYd1|FoKXV91Rug)Dz#P@K~pQ_MM@G2V+bjf{j}gUU-UO
z$t%B3&0>x4?$on*i{KQQdayxZe!)0}0IYSY0woYp2H~MML<hM?GP)o1yGGnjy%4kE
zV5NF<K-eD_MMDIz>L{tY6T-vQY|It1cqOs)J2_2oWbbiX6_IN#IMq5S+yV&~!@-9R
zT!IB9NX$3A!BsUPQJ`Qpvw=GFJAtdlGn860ze;HDl?8lhreq08_aI-i_!tnuhHW0i
z$G1N)@}(Eug$99x2A<w_SE<`=fh07vN!3Ygm}5BT)9Zus1oIpZ)b_>x3q0sSN${!b
ziD10a@lj;n*eKy6WTfdu94`hyGWYQ}iXtL~zi_K0V|-uWUq;IBBva~TJF*U?BL0vF
zfqk7`rZ&aTRX#YFEMKR~M<S>spwz5Q!e6P0bgj{g1#FbTfVtuLo0#ENNc^gQs2hLd
zFYqt1i4u;%=GPu<zLbfLE`F}M11=yJ8@Ig1hM?3_FKBEYK^i;mS);%viMB`&V#D8p
zO#^?`H+0}{{006cHmg0@ASl(P&1)SQw9&=SRo(Chx!AbnH8upL#u;pm12)L0Xxhe@
z<t`nT`VgK=^3|#VyvGs%1`Ym}_fI1oQa@j<;@?T~nO+=P&ylwi@8U1;um7%bZbXMv
zK!_PZEmULK`Q}jS8nz%ccB$ZR!=XHZRlh2qQvjhT4I5BA@em&om&Ur433-Q$TKPr(
z4vzNK&i4&I#5Y)nRyE!?Mue+CL3viIQkSABs%E(2=b`niE6Cf=33*rlP^&=YUkjDL
zEmQ_5WOn3zaajj=)OXc7sY{Zep9W>V!!4-tg?}wn{<cslxgKIQbdl96)sGESLA}1g
zhnKnp5*qTi6f0ZB_je*yE&t^W*rp&K%LIX?2zUZwk4y6ejfVIY4e=eWIF&E_YZ2pb
zjo4#}239E(sCQkZYvxsl>IFnXS}zkK-ZewU>QMr-9cMEj7T@7+Qht%Ywi&*$%}Adn
z5wPwY|02U2{@$qpuk`}vR{-X_`i4dU%)b^ee+%Fhk0k_NnV`Eg*O>-+kBY2s$)GOK
z>#-#$zr~QGlgQUg?^6%31py>oX9;iVr651wO(OZ_qiNKjPx3z^NE-6949L%S^{bwj
zFZ^rK=Wjtj>XM%|?g06vnQSTzpuC~d4+zYXpM}v`zN>H8$S?BOHp4fz84Xw_rk&8j
zL9NTapyy7RbZqJQNU};mdWz0{XeDlm<+IeUf3P8dCUK=LAyW*<H=$&iOc|V?m652I
zmQsyK9Ohi_<svj-01EjRH>}jq^o*;&f0Z;KI7kktG%{tY*j+Rrh-%rCx*iQ^jA>(&
zYIjd!)<lijf>kT)WqO%jt$c{!aj`V;PmN<;2`BvG14D%qT6+>a&Hl1*AUX%yho}|i
z1~Y~YMiEEuU&AnT#4|xz#!u$l5I?m%S4bo}4!6Mq7{Hxp-UVLPQ=FHb={+xNZ^uoa
zmv?Oyyt(Vn+eNv7JJU~At>ytlCU0QyJxoftp5U%eQu@)8rYi9U`Vtm*>>|1iTj0o{
zh|l3#!E~?(vPu;c2hx}Vv?4%euLwA+(LCNkD|=rRmO)E7{0UI$kBxnG)ikWfTm`Uk
zF!~Ji-6CJ?cu^ciP;n3~@NG&%9yCT+#K+tsh*VWqUg|E_zvlv3ewEy4_?$T5O$fbs
z<EE&sa22_$qgyy~|5|_`95w7|S*vvr%q@Zj@VgEah6^9ah`*V9BmU+9{mrjnS5CVi
zLQQxYG)eCeT{!d(1@t)z=zjJrsN5;1ezQSry$G+)lQv*ATE&2mBehc_?X=l;+SpE8
zeZ}r{JG;60HD^wBJD=9=*dPI(zn9>WR{V>`pqK89FW*TuqYXr}O3!onXsH+#*Skwa
zl%1k#;s0@|=oU6q1RV9^1`icahr|^=?ZX-^_AEw_NZ4r)Mt=~eAH`|O`vP4jWuM#>
z7~E7bSYNST_USs<W4({pC>W<Ea$_|kpA&qYh^K%CkK8R#RiWkf@w%~*!A;?V_2G3M
zJL)=Lv>0Xr8I*nk>JjC(2Y{ZHlg`6YSON?BF(4m+41ypcP%yy)TW1gYHdf+g>a(CD
z=K5BCABrVjJV2Ic(F)YGiWUr2bqln6&QEd)PAB7RvOVoe2?780?}Q~b=3jlO4}NkS
z>7);!(T-Rn+Qo=9VuKN1{yazQY!tL3_BVXABewY!uVToulht3~ZLv1oh+9~X7~!Z9
zzt<yn1^_vCNUv%n6%!c!3nBm*jsuCZbdl=9HXMg>!QGR@v5r1X+B_}1kqo)9zG4F`
z1sR`ks1-+AZEsl#v};%p!nK6Ie9Fv&3|YtxG46xC9R7XtKLF%C$hifL(PKfa;FI~K
z&bv&RJ-B8#-UV<IbMWW+rAyy!_%tL|$#vV)@uOxRuJ_yNFhe7MF0lLU%tM!8G3<H7
z#4;}Ocv=ImnH*`w6YLY87l*t%FJOx~M@8URvh%`}jFgYWW`YpZubvVTW6qDmpi;1L
zfV1p^yyP6S0_MJPk;SZPjG5=zcDu!O?Y4`8=cr!zSKM}WN!>0XsPo-+dF&N45u<p=
zF+hVhRjSQQd^7Vux!2yQE{sE}m*>at#zt<e=3fYYkRLuPe*ZhlVKH&OXc-x%tpVA_
z!j|PPs~)&(B8$DvVgS>4k|a792tJKnCq!g-9?aoS`{P~tm~t-xET$sa2ghlXIg=oc
zu*2S|YNe5m44#njs_I-m@Y<f>i|I6I+SrP}W<325w=c)8*FO$-Q@%+1T43KR<8~A_
zA(c>n`)&Q{sv6$I0GNK~0!zb#p6>^0(Sp~`Sq5UhcJ08!pkTbq9}PYHMpD1*yteOQ
zJfQ#aJt3A{jgovRb@QXgw!hu3UVpc<O;;_64sUnl^C9bhm2qY)8y@`4wHcm?3|bIR
z!N2BUB(xAr5}I1>CfR82U3B>svL!z++&|?ds1Ch1{Tw6htG`*<3zqNac@x2|JbHV4
zX7ZN#NHlnh(Jg|%LH?95)yzQ$x3e(?3~ZL&b<4Z4g=>tC!jDt<1I(KwTslxBY!ZI5
zEs2}ewqXK~Es#<#*5le$4@l&&0i9l~$2oGmh48+~WDmLix@$bW)Z=665g<L{HxD$T
zj!sjQ`TclBH5%R=rUXdN%5v)vY-aglb$?cQm0*88z90`SF1_i2(sxuZo2uqp2xK-)
zm3_O$RSXn1ac!#}sN1umc5tweCTU2!{z|m~rD5bfYzrDcg-}D?4RGD8LSAgj309>L
zGREp@qzoQ+TpxUTZmB=f+LX+?BO3`0^X1-YoSzxD1NUU_!Y$banYUy+xGh_5%I2{y
zc#fQo;PXv+o0kOd``eW5(?h{<6S5Vq0emD)L<0cn-?teG3zB!NDS#ZF{-@|wE4N3h
z^vjr2*mgx?OVgX7%M05Q1uqUBJa}KCDY0+LpYnS1K8(LR81EgN^753e@y)n6(wCD{
z7dw4C|B1fJe{y2}x_<z4ZLIma>#v#8xTRtC;5Azkvj?VciC(m_G5Xf@H>00e*&W@}
zq(XQ#8n6BbuZH8*%g(p2yIzVn%sz<9sCq#EGr)g1d{#abtK*+@?bG!lhndd?{B9Ro
z?F;n!vmW%w;cFv}c%uB5kN{T>i+wr*N0Tdub;-yBqcA@SLH+7Uy~I*^OqF_;fFsza
z=d!k00<N=7cZqY{Z5sCJ$!afrHg40pq;8rJ)F-`7KLH}!gtq8-mZ4el#~4HNt)AAe
zx2=CMvvnAn&rx6XwysO+)(Js9^{aHpan{z|VZbYKrX&LnIK^Tg_kKByeSE6eKe>8M
z;YOZ&ghL09)5ZqJdk1g2?ZZ#E6C;;`GI&qE>7k%58JR!=$l&dLBHf1+;{fgYoi%vg
z;CS!gmD#3CGn<ydo9t~`m()$m;N9VEdM27a{NPDc+7N>`!?ylQ@z%Q?7car@_INt3
zOX}8T@cJJ2bo@mMb)08p`nf`!LFB)AU&B)Gw>M|RpC7pvg?upvf?~^QyrdUP`eEq(
zaKyE!wWx~4!hs3fmf`6he`O>m#N%!)>NhOm0!^$Gpq1(~{{g}`7wc?@zSwE%1Gs85
z+iweZaAL9YB?7(!!Jdf1WE29NiY;oAymb$$iM&<ApEkk(`E9-2_f2VND8AJG-i)I}
zUiq?ElV_dk!8u6bRh%VEk|MP1KgN@j;bba)c-}pn;Q3VKaWEqU&zs^FcZU$XJ5#*_
z4~#qeb;(HRc+0!zJtjlwQfQqzP4MVQeROz6_IlO5j6BuiaZM&3VC0$V7B3#Uq{c%S
z`H5c|Jlga~tyACUVNp1GdFkfix%zM-X_`f)RXpD=Nx;=JRmU41lIW5e72)brEh@V$
zDgi-dcZw%2IaFu!+2uf&ttaza2;VBxybB-cslqSJQNZtwJUSe16$P8mNk01$^I${S
z$>&x+Yj1c{(wDej+~M^Va3`-*8}N<W!|I)w5kt%lWQBtjr+K0J=nl>W9L3a;#;2*b
zUbj8Qw$XO$LP4dGfzRC%1Nb}}IZfU^pVlVa^>IN1k`FxqQ!DlG)%aJ%e~Qzk4dD%#
z%<%lK`Y#@R#YATQ8($QsOeJp@OaDr0ZBYM(f1&a?F*Q%BN>6Zm_k3Gb_EoIPKpPNy
zr~0a?dW%%;b*5W*Fk}&-pW;3IpW1?@77mWCL|Ps6oW-V?x|5`Cx9yY6?|6^3pb5g*
z)8z8-D;A!a@Y+M45`#fM-j)O7T}k!JJE<qbg3ya_18pe~!34({sNT0wva-D^u8bla
zvMqqQ07-r>05%Ob!{o+GfX6Kp`(b7_B-zjMyd#=E<90Tk;XF_4Cjl&J$vcDU6!@C9
z`M3xoR_A7}b4**Hl@u837`TMy1j#;RxBFT2UR*&pIJyUkh0NL)MS{3~XQIl(RerE1
zgovv8he-2$pdM7u!GYv9k?TBdDJSC0>PrYGKu7@nQ{r^2rvJb0LkSTWjaUi)&o02;
zA^1!_J)VJaP0j^~>q2Zrb^nw`Y`F$-N?5YK_Aji-QTN2iu^}|h0HgvyhP#rr*s_cl
zUfB?XW#C{hm5{3&SAdp=3S00u5IYvn`TM$%c6-sjE=fo3m!#cHOzz*;mG^3PMsC9o
zwBLe2W~+m2e2gAJf;{T%Vwc4ZqCdEaVPvq~4wO{~uu(+>U`B3KQV8}5>;_bLA*OOU
zVmI`B06Ydl0jf2y_NyB|ha%pso)Fm7ABOrIOJ;?ghS3I3as$DgtG~V~AIO-hD6iV8
zAa@jw$+DO?_(J1Tg}%k_&ZpNFxxcFN>#Ow^a;=(!RXeK(fCu?fcXxg*z^y>I2hYSK
zqzzBOO`9D*a=;-oXSvI!QXbp25E8+#X~7?%!?@7Z$5g|}Y+aR)xK$+G=E7ri)=`lM
z@Pt+C9P#)Y5sk)7X$}VgAXOiX47hU!q1-t7cS*ia5?sowO7#F7;_hVSR8;pZ6&gSh
z89+WG3K8TF!y=+{Efw&QN9&w9>;ydGNPIJ(u0jEt2QiO9SI9HuARhKjf)4OAVp?Dh
z2{3bWU~73k(!mU<%lS^mPWK=AY4X7uy!thfTdB5*49-V?h%#R4%%+Au>D%WKSuOPU
z2nE2C?`Y%_w-MnC{YU5v%*h(;0U1<7PxFMQxZy{Z1IzdkKQXB8kq-5nT3H-u;j=tO
z;7~1kO(w^9@NL4>JcOa`chnM!xzCVzYh`uh<~2<KX&*`=mlAA3N``&+Bw0}|Bk$vm
zpb)Mn)?<gB!(t0=)?L#wFEJZhAVgqaqN+r~sX3mC;iDD3cIqK05K9z{kpsBBDCv)4
zbKm1D{~<W62j+Q<mYAflSHL>bQB{+Ne9K>4dRuaE^bE*zBJ201DQx7&+04egTfO~z
zBrAcjeaNhzUl6}D@ng|NFu@-(``q=`!25{{&$?egHg41;QI5bV%!Fg{VY*^A^Law3
z*o{?ch=cks)5$=+Ss*o`=ph)T;ZeQctpYAQs^-RsdSV7f_jut*efY0#@cOT2n9vZf
z|4J5p*|@>qgIE^s<%+}!g1y{ve03-CdtgdQhGT6c74wqVnScQ18Jt-5giLW!TH4Hs
zOvMwV&5M7ers*n#h<Kj?e}nn~5JmuwP7V9DKY$8|G^+8{=z5X01Vwo2lRwq<kxJ(t
zsOqdcR_gNPU^?mRS<HJ5i}&-4d1wf41Un$?(S{`bYAsi=qSU91vL9UeA_Ne)G%+$e
z5c0F&TAW*5It}tC4?)tB;+X`{&%sT(STrF+dQ)!+2-i&_k<Hb9=S6<|3%;c&<h0_5
zEaz}UBAYXu4oXs<EL8uvP0~u4fLVt3^uisHdJvV;Iex~ozqi62;b!Ik9C*(i6A<Ml
zHbQ3(0*Nqz>33uVJJ!)2WJN|2P0=>t=74V6>Wkirudo1Pb-2+uBJs3PU0O_JpkXjA
z<D7KvNtBh`lZfytQr++nAPAEwh<B=O7z7?_0cj*1ZU?x5J{25RL1R6sJ1LnedL}X2
zvW2E?h!6}4HD=HOmS#(b*KhUGA%+x%Me1H@$s{|zmMvK>L;{)^DCOMld_~4TJ2`iV
z;MH4eWR-H}JM+L(K5BabNurGbPcVu0mogh2%SMMuqmArdqf&GMp)px}IWUlK);gLk
zaLs(Jgs#syL36}W<<(6)HqMN+q~}hAk?(f;)Nag}KJaZ^!hGIWt>;iY&*}5LngLvq
zI~KZUx@zR6(U?Jms`frCAhaKKpUePEWtjD_yvxKMDkbY`SR!PBrc-@dHS_8+v8J$>
z&SMPr>Olsc^x1wa!Z&_jd`Q|B1i7&d%t`hv#&K_+49BiaL7PFIF1ZQ<qN5IXP{3Be
z<Mvsxj_I@DXGZR4XS5y@VX{g~og1IYpbo+vg*s)wC3QBEIvdrg7*<0ax2mQNp{kdE
z<e^SGCljPN54Y;zDQuR0E%}&%I`ztQmR;~Z$j9{eLuA>#6vhyUH}n{+GcBCqAl6|D
zbP#7BQylj_As+|$?%%Kr8yMZbL49;Qvh32_<Z8y`vEa&+1l<7~w-0`u`v4qI#%0AR
zkeoB~@Yp>G+W;dj4R)>c7PewTO!u|MZYQ#-XJfbOA&nhX@el{B1x<>}p+!cS5tYsH
z<;`@6ZuAV;DJW(K?5RIw3>eBH-|kqo=GW})dgdoxuWrNWnE`XF>H#BEb?OiGfStj{
zCkanMYiXo2n7xLQHdN}}1Y*jq+GW>Qtv~$c$s_0wdVgtG>*Ln}vrJu#T1h6n>s)vq
z{XxR7-TQ<7gd!d|w!YOL#uCEe^oQ$Z$7?aF%Y>wLq%=IOKkWRKh3C;9?gG8i8qG8>
z98(|jHJ~@;n8^|#Z@u+6kjdy)Xy1jxkvOI};3OsP21hvcrx;xN1Cw~`3Sc;SfR#=E
zo6^Cm#{OWEY-MRAi>bpI7wvA#a=SIl?FJijU4x5OrCF}#rilLp(LOE_U%IP(prB|U
zW6)hUE%^bCDzpZy6S`jHc2pL4>Z$K(e#JujXDCKoCVm2HLJ(r5OZe;V(JAN8;zdr6
z)K{<7CdWr0JmAZ<s@naxkkmz~gi)=6D_@`{Gt}J@cgvaZ&{FzzLE*X&xe2`Q6t=rW
z+BM75rN9}>Q)()aVnjqQD(E05)Ps-kc?fqo*8nR9!VW}XDU`y!vbXMa9-^MYi=R>x
zi4D6Gzb7B56uF5L-S2q4Y(oUXsZI3&m-#TQvJIc-daijKZ&)AO)`jZzCa&i&hC$~?
z*z$O>fuDxeKMy%YH_aQwp(lu$UJ3jF*1aj-PR|amdV+-A$n|%lieQA;!7GR$okI->
zo1!#igMO1&jL-I3j9W6BMa(p8k5;J~2`KtSTD20Qj+8bxu+0ss4-{sbZ=yM^1qS28
z`I{pp$#8cfLTA{06n&V5KIUfMSzp~EeQ!XX8<L@=vH_b~Dmc(Md~yxN&PGEKF%L#@
zTtx9+S9JM1k88Py=GUv3X`UJ#W2Be_tb5p<Qt(Ssa2@enrxuukO!o{*=2dr_<+V38
z0k5ntcoYvyQW;C4GdANu63H``pQ%R!u~BOlkLY946FoSX(VA1b*t<q7AriVCNWBf0
zCx>b~-lv-JN4hMIhFyDHgY4&RrW`7wjJd+uc^<97{;mT|3C(f}ULoqeZojbg7?R*y
zkC6nAvuBU1J1`v7x^99cT2OCup2JUPv4hA6GM@Y&W-C-k56gY|#SE6y1QzJ$3G_z^
z{ZUn9pu?P^H9Fb|2XDdbw<|-2{PgN`9JCPbPxI(@-~zF?axWwiE7-l;K$SBiKcEOP
z8p~n~iWNxff0MBQT79nmm!yKx=WfMdn+4FV8ku||01~P?<vV%-<bm6i63&J`hg3ZQ
z34$6bPt$Wq>O^f$k}^%Jpf)GbEmYX4p-`S7Br%=xA3;#xYrt6Wjs*Jkz#-ev9Op$b
zc1O_VxaFWO$Ml7;24lZ}1YItDZY5KfyTL=5@BKQ1GFF%S>MyiZ5M6E|h7<Y%7$M?T
z)szukF7MkO%5V!tDl*^?j3)aI1%ZlAxw_n4vaTGFbSsdeiJF`t9W^;g1eGQo?k(7z
zNxEz97t&F)S^p@}H+tL@B;iP1M7*F&a%MuKq#ielugq-;^m%JN?(ZZwLfshbIMks2
z{jW!(#n~W4tOf}3YD#F#m}F~!Nw$ul!(B;^Gc0_!XQ1|q2isj!tq!;K=j^G`;hw;#
z85VY{>VYCub@jLOK%IduIukN<IILTF6$4u@8APwad7w7dt^ryCT?J0`6I8;m8lR@l
zS79T{jQ)anRse9rR<oSz-cwwju+^HAZ0z3f%x+>enXE>^yX89fbjirZpW1-c#R>Mx
zWNnMfV$WdGS7aOyAGCT3f@85g$NZJOLN~Q>oGVO%!z3t6Ok?f^COVk(!+JA0Lt-xM
z!0?DB&RsZ|1_vVB;>+8p7PTP=)Qn=y7~8jr5(eN7Aqq}b7vbQj+c#a(^bHWy-D^C3
zdkjKHbVB%L5RE4OeO}bqr>*sf(R9;|neb2tHX_Dxwi7+M`VyQ!L;&wdgt*F)Qbwaq
ztL9B0Vd{8XOn3sOzM_@K!OW%;H|ro_)ZW!Xi)Y&~5Ku`+Op%NYS(kx?cOnQ>E(1XV
ze})(vtN14@Nlp~kzDtr8l4RT#4@q=MO%g&-H`jYeLbHv?M5;6<@Z4xxpo^pw3vQ|&
ztgl|jV_cm3aJ{YbA@G&Q^Xc_q1g$30Uu6sr&oDiRDy3i2FibNUrWpt2(hSpx*<vTY
zW|)?52$7zXkk(f~q(+*VpSOJTyzouM^RS`Cmv1EBctToh&bLH*Pu$lokx=j)br5G4
zZ9J<fsfi@PtmUgUkz}SH63ohQL+%d{#*bjuBIy?bR0EU56$Iv*v};=R1~S10h!zC1
zW_+rzUY`iBxBX-#2#bcf1>lMHuS<7f<G|8x_d|NWx9P`rzXu;`6Z$QRtyp8H`~*_#
z<Mwy=dF!8^QU85>I$V8vgenySu*I)5fLTzbUTLS|k`J_-_S4COK(jBmOidI$bT@p6
zTjv%`fDnY;9Q!R=eGz+hIye&eQb)qgV@7W={hJDTcQAH7Xr$(&7}j*rkJYt!;LGvo
z9oA}I9-@?gEeHf%Hx3S<oLmO4w7+cF-OJ|tn5^OmAy|<)>DlwC$ZCjlSb5ujLA+eX
z==a4Ct{708aSj-wjd*mc|HcDf{uoq(Qc66Ms`jTO8CB&P4J@L#?647aflM&D5{z;U
z6l?krDmOwFXMK6|)I^|xR0=-5IA=n9PY&6+&$4r$u(LOAqQ!&tREzbvOso+%0qbu-
z1q5rPq=vStPBU2l?<2&zjaav-9b^<yLTfZIjWrul_X)=nYv(NXjA`!~^zwBeC!!6$
zj#i!y;2C$dmh^AVykyplr(e6rKl_UC2=7^-ef~$}xaIzw*cdT=BG*XbKQ$dz|A3#m
za$;xVdv5GRQO}ulakc(lbpyym*L9}aic4*9y$f>7VP_US6~5ulU79I-F|NDx@3LO;
z6Q2&^FH|q+cW`mfxNtt><LN>kt~XZR`xwM#fZ60vj1=zXubd1HN4#Xg1cvmUOixo)
zK6EuHzEEw)*%pw+nd{8vyLtKQmWN4ybM?)9u+Wt4kW&4gVVz@#b-~ZQ%$UBHTWj~m
zUX$Sw6suAF?0h|WGn`G<z5{<st=FGoqZ!ivlm<+2T&=2pjA6j!)8n30pOr_&^a6Ss
zE3m`+>ic+o7@M+;zr_zy;{Lzs0kON3jPGz3k3^Ceky^&3m+>9-m;F2S5zl=0Ld?XY
zi)XG#!hVY$agwSTu;?1EKBv=OiKFet8|)$nxnZHB0Jq;P#^V;bye=#7cyqwx?aLf5
zvkQ^#+7u~fz637ED*CLigbQ&$+>DLbg+f8;!`{8O@ZH|vQ|HG%7|+k?@C_Sd3<s-l
zu4n&8`qM;C59sE=H*!6D#58^3F+L4e(Mq*l)*BNOobi3|L4Mckk@q|3`vcN<?Sr5G
z_;_)$)d!$njbE*}lFXfN=-YryjB2dNkbJtP;XdtFpGTA0`=0B}=ZhzSoqMNJw|Yb#
z$6_4dK<!oyeB^^Xt&oo}x#`E-<uQbj;*h2Xun?#eX;d(TqOoF?#=luZ$uSaoU^=LA
zo|gP-w6`U{8ZM81-LPNnTSc6uVOCZ0$cR5+=~wOYSZp76$fN0zUzGt*PfUj4kK&&_
za@%~LutjfT#1HTro8X4IYx-pOizuT3Do_YLVYCJ&R9UzuxUvUL2ot~n(XZ~nfo=Y~
z|2rmDF*=)%U&CvCcUi9U0$=<MEYE*$#J_GFM8A3ykIo}PrhdjD_)`?wHD^Wq#au;e
zrb7C@b17X{G~6l`XX7o3${7%=#|<h<eTxs+I8J2%6&6|W=eF5GrW!C4@*hzYK<6u|
zQWwm@f=iD(fc2@TpC|5p>Mszj{P!XtgV~A+!qiWGCzKil**JgiM+qW%7<qF@1VskF
z&mw-dre{7OLg#2BD9m`FyeEQ!{%*|cp&}^U_IX(@l&l5wNkZbU1)_mx{QH}}YxO^m
zeV%!{($?@vm_S;hiik1wCsTiHRrg8#R%27}Sky<0WxfcD6!?cFyHOHGAr3(XK{D|<
zcPM<GIL3?5!ve^Kl8MjT;KhdU5cph(xdcv1<Foik_zaoT?L9%G$TOEXqSF2$=SlAr
zDde6f9U2}t#mz&)i}#e8C4_hQDP93ZADqIX*$rCz(--)iOk=%PH!4*~{G)Oe&LiLu
zlMI_6z&n8-Vg<ndl))zWA43EXazx8~4?yZLLUN3IHy|R9i_p+|=rxt<58_-DU3)G~
z*~`jS99y@%2a<5bo!|wihjNJ^txFa=8Z<XyJYd<O^Kn4^44gzw5dM#J#tt)n5CEL!
zL?g{bE-L6{vD?duE-LXIgEYEjFqOc=db075^`!YQ=a1}8p-7bgGWOThbz9XGJg^HN
zeVbj_NnLlRdL3NDox(UykwbS1SzcSQT$l{rp{Dds;Y*RJBIDF=wfoK{r-hjhLJaXB
zIP8lZI`L>xPvU_umkJ)u#G_eVF5HWh{k|FvEb;?DjIa?^uv}|=Kyw+`5CiftJB1FE
z@)%5ztC-h`w{hcpzX$6Yi}i;;@T!z7C|K`-I}_Qeh;^g-Cmx9P3plk-TQ0DEUabW;
z80V4(rm<!tYVk4`Ygld}xFNgNBIAWD?~H~{Yf(q)PYlOyi_~YN)s1X*qngN8@p87{
zXRMFac$m_dr8Gxv4^Q;=(2+ToVPZQ`rY<a}yEF6vc=>?!7>zYF0T@FM(Eu!ewjIKs
zjYs0o3t?+kwK%@a*cVWExB4y~`0|=>k;1L)Ypc2#OalJI#7Is5zr&(|?`I4)SadO4
z{U>~hoE1Q2r}7(ATE9tDT8K)E`aSa%@VfRPSoD^A?O+qr2mYUM>7wstAPz1S#AgWN
z%|yIeeGU)o&543|BN1;@`$1638z6oNm;UA+FXI1W8Fk;E4Wq8tjJn}p;@4vJeYh9g
zS#mGi2U6ep9Z78N7XAeu4$rT*Jml%Ca|W?LWJ#JLOA=PV_4U;ove=g9moMr*fNj?&
zs$q9JgmXRm%OSvrgAz~~ur?Zb9+0W<)6GH`8!du(lp^&c`~g^rNb5fJO%Pu8t{W)6
zj2ZGWI}IOr(9<oh9AC(67_rHJ?l(RR+Fb|rrCeo46nO`LnOyjYGoZ7+ynSjSe-%vv
zs~7txa4E@9PVD*~@4==LQ~PD{tD30l!Ps05(`)b|xO?$U7|6r-r}4X){o(qBvqstZ
zV`19*hja^r)ywo*)xG0jMBYCbljD%6ba6%>cG*4zpI#7}5brvWVM1%PCbZQHa?wMq
z`F-9_%6L`j?fQVa595f~F!end&$QO7$DV(6dG(9MK3F?q#~=$P){fH~5GSrLs#Jf(
z7r4sOAM=+0TenGF-)g_`e=bx{V7AckC#28#j!+9I2GsT30A2YG`@`C!vp>9mj(F@3
zUy;W{><`c2^^xokJZw;@ax|Wq3Sb7lm_|L9a*R!9TzZ-Q9)*2k=f6`Q`cCm8uK!1M
z-nt?whakE!P1H>E$!wo#p12OX9-NOjoP7c#iCS5bA=5yi$LC;V>LK`a9BF+!Rs9|=
zCcX1k8{v`J<~x==2qosOe{mr@Q`8{qtfLAP>DB61`2*hhw;XHP3^gO&>?Llq*gd-S
zA`4EknpN%XtY1W=_HfPe3X<$eC^pzE%_{ARg6B7_Sw)t6aC}621FcGkWow4|fglEQ
z_|%V|u%rQwZas~o=usVCb#c5HU_GbTcH>dhyxoKZ6$1Vv2^TsuawWTHyqouVkO^iY
z!-yeOm_{Zf$k6o;WZZfh8G=-wOC$3X+vF_z(^j)q?mYTMa<=*f4hU(MP-~=B_5lmx
znO>`BWVHwPMc?!cwu6kL>3xOz6e`PUv7K29Ax*khYXq?n?mUFo&H7f?vz8F(VmMXp
z7u4{K{Jd}pr5U#l96ZD(A&V(+qez8Tw=)^{C!W51qruY`QO#$lc)HouZnGE%w_aqm
z%edQabD5$C8{v;<+$>(H-VHOo;T13A{?voxoA+nnD7^B9ASR^g#>qxa8sO;G(>My_
zj!WY>4>)=lH_Lm;oVVJ0d1mBM5988%U}yT}naIF_IYTW>BXflyV;I-1r;#B@^}SnN
zg8h-(e#E;(OO8mk+$bFq-;~1oa6mKgk@?0LA?%Nv>#G~%%NrRH+LLfMgOOi)(Eh17
z&0WtC%Fa*^3$8-LwQ$i`uXMVeMw=kj8(((O&Icw#>p_XdImO~e_ozXx^jfnZbQThY
z(Yn*4T5swf<aI68&(|)0J|`N)-`wCz`fgI^LnvcQH02dZ^1kogRj<&H%me7s<&C<_
z8=-2(mv3N~lb(^<>gn>jH5qJ!vX`mHrJvH}Uq9;UvRhAgnIKh9jdXci_z{W|Vm%#L
zC&G`Ua-o#Mvc4-7|1h6!y!Eu>I<WDDcD<#&rBFj7WUff@nE5a{LIbE$J3mExSqQd>
zAE?$Z!dy*|pF)HIU%Y`Ae7*}!K<A@}8cyG11xKEVRBy{q+HJRmAG8QPfm(_1gQ@?3
zO{^vd+X^rP<jm~7T6LAXaO>sr;h{M!(Qp$$)h`H@BpM?6S80lh&7lLZ&JMsjd`2_t
z>Z>1*FMpf^Fb{pSGX8I#0hm;uF#srgnfiougCNw|@E^H6=ho8$K#=OoUor#mfbH+I
zH?qGEr0PI$41gSrVq}DaO#$}IeNZ%L&14RewI<kg=#CqGc3yC05(sB#wXS10Z<jC~
zE;b2nT3j$OzP}*2@^>iB97(~IkF#FpGHot+x3!@2uUSwqkyo+1H$SEGbxAY=6z~j}
zbY4JQ()J#=t#flG7St~1mD$tS+>rK`ycQ|mv<GO;9XT=H4>Sv1G;<EEmzOUd-DmN|
z*VKj1_ph1jpST)K>K+VDhg3+^8t9r~8OegM71fER32M#ilX0^fYVJw~H!aAW82_*!
z`Xv%F`o*l`UJ~ruBQzZOZ_{wso~<AWZi9h#uooE@p+3WridguJ?s#3?b$e<-mgvdu
zUCl`tDpzX<EbfVQa-4kp^{uIPR#(4;oZ@c*-ZkiZZmgP;Z8fZneY@Vm9+{`}ShxHl
zI&WiVT65<K|3#*TW9fd&)ZN#Usqas5h9#<3V<XiNsDueM^)xU6(CSA4uFqIflQ34!
z6_8Qz{G)OvVHL`0@X)Ur%o;may^Ql*MyuJdmZpgAdZaj7Y1_PA+FY5MiZ-2jsB>HF
zq-|k#UBq*he6CIL<b!h-4md4T*ZoZ6y=oa@;D3}>XR(~TNxhA#Ks_(~s6;@141tkp
z3mec?cN;ie*AWh%QojTo(ldIINLYy{L|M~)2shrXPJ8>RsHyy@ROXX&t8=3n6C_>f
z-IYS^wICiw|C8tm^)k6?o~VCCYTeFS7ddBVmHq-3Tb91nv{5dl`Q-RndorK1HuSPT
zIkHGt6ArANTQE`Y^Ys4ia>TF0iXpR+Q3hU-vVCe^Kuic)q%`^xv4J&3C#+taGg00&
zB{OBhD^v4|GUqnR=MQI-SuF3J!MnO-0((5OdQUF+iG3mjx!O>4i6@gG#4Kc2e_3^J
zFup-Xo@xB!AC8Gl&zjF>`s)~k76=&+XS`ygOIFVvIl=iV03v=l-ajHXO=MAS8A52!
zmAA9;x`2n)Afoai;-6zEB4&kLykc^Zr@oBgL1~?%+<Qv`(w2u0E<tc3FS$XabYH5R
zMZ<lQ!hu~#g5a?a#CwV}?6I;%WcCLMvzO42>qS8sO2w&N7COru0-%i)OoiwbL`rc*
z2kOC1Bei&m9S8X!(P{muyTO<yq=rR!O7Od5L{bGe;gn$P3`oiRyKr)@pGoYB&_4<3
zhug)(w>d4g-ZgGLcy=TX|9G_xr_#3hCW2brTRw`$5SD}()v}5{U{T$l$Mik@`UVRx
z>$z%MdZnc1g&MeQFRY2HlL#DX0b^21Fe|!{d&fnT<wz9^8<M*mW)RW4e1fyrR2+a^
ziFNa07n*hv&gHIAhi!M)9>f`dqrmh1lPdbaEl9P5g93f~+J3mO670E9o!%`9QrbY)
zKM7$*j2pogB6R@D$#17{FNvV*9!X7DWX1OtkBAtg$?$4{ADC9r6ZPC6J~aCyw`XZi
zYZCgvIkjB}3R*HsdF^QDz=LHN(#${bV+NUwRWY$3gyVg{4*Lh(w;I5SSx%AZ851lk
zd}{|HZ#=LvER@dFBh}pV(cx=CI507{FuSDW$7}(+<1$GIhkVY1YDBC8yD`C4b>tzh
z2*|>4PdR$v#W9Nyx91*~auZ;kMhGZ4>>wJH(>Hx&xr&1x4J;Mq43G%g_=h8+pFm0S
z^8t|z;AaZ8HQ@suWhiyNNEHHvv|CysmFML^fr%jlyL+1o?g1`vnUi*MfeU_huhjzF
z0WVxc3qe{LM6t~C;0?U7$lHw&CU=pSLl!Ya4Wa=FVwKb#sUJ(_j46;IXp{4zGnh)2
zXpTgmw&u!}cnpZ`cS?Zh)*NIdH1iNkCX)NmQa?@N_WjNR2GK&{jh%#s5j6@Jtb+U?
zriwEW+l@h!-sRP#%qG(wu6ba4@K{+9*UJ!ya6g1?#*%6HyJYC`*8B~1#_~5;hX0@V
zJ47*_KVME@VCBP+Tx>deF;mOJDi}XkM12no&hh<VacW~jcgcuSvUsN2pD}btTqDl}
zbLjPLKTeX!Vg_t*wODw+tZ(K<vDA;q=GDLnL>s{yX!XU1Oeleq<N87#UPy+U%Mg`<
zT?t<GrY4fr1#DS`T6(zv&@1n0@)|2|k6C$pW#u)^Icc;$$U^Ib479cj+xEzDrylZr
zva$x@HUr@K?hKxX0rjMfBScuBB_svFjs(XadsE*agd+%uu6fZ<^F|{w?+F`4OTf)*
z9th6(q2MwzkDdZcJ|Hvuoy#p01l;#>3Y_q)Km)OPy`&+T^GTTpSPwCK{?w`Gfo?up
zG*m;Wtuh&UGc*saZ^dU$T|OTPT~_8^jMcga$wEJ0n$M&^<7-#=d^2lL^Z8=I_8Fy1
z68WV|;>i_D;{7WcZYuQ$SM8b!yU8z5O9L{0U3ht)`4{26@@c63zW0Ooq46cb38U9y
zH;#W>@L&Iu;L_F$kS-Hfx-A~oC?EFYmbh1UJmG_JBD!GaV4=^qZ26Ml`#WZy56i`h
z!X?4KE-20K1gtGfg69r?t@ODbI=Op7^@~dbiQVzdMfl;zfBE%ArRwr>d}|I#af`wG
zJJ535lHlg1;WGzOciH%v=feW9Vm)zq064rCyb{Q{&2$cH#Y?od`IPneF&xECVKEc|
zNd+`$B=SdHPOBxnK{@Jv+O?1(Wi|qBsi7PB1UC^9>Qt#0P!Jn8lt|3ZuT-zg79pR(
zF8%PqG*tI5RKLRfK@n^Tj}iUc0q>wL?lZ>`NvT&B9<blif#qhrY<nhh*!WHwm`b%O
z8!(*qG%IlO4%A<g&y{EUX~0C#n3G-l80A}jkjWh~b}XrrF~2+<lfuAxpLM>~+-3fF
zPyTCx(kr(xflYHSE+lMkd~HT4IWzdo0`T8+?*>nPWeLuF&AQ{XRgL#tgrBFDFCDvN
zU;C1}ri;tl2RhqcRZ})k+Pr-We@|)LzU3~Y#<*t$*cQo8hx6t3Ep4YL4AFLKnY9uR
zX4}8G{p~kW_nv*%$?e0EDDg(>&XUB=cyoWeyT3C~iph}Z+S1<DuJGZQ*A|o_oYcUA
z2N994N5J}yGc?v`0P8dH^R)7%r)6TjeT$S>>bHnnECsZOc=&1Y9i4?87#kR7p#iM%
z-ld<$<025H8b2>CUwWYzkJ=AQ?#NGUp7KiY*R8L<wIsf*)bCq<%)U0cINTC-$}8Kq
zGz6+aKHpu)85Rqea`_(OK1bq$K7zQ#caG3^@?EF359`+SJ#WY!9G=EM{FvU|ajx#)
zx#-^o_&KY5={bk*pQU+$raAlNrTPyw_GW%!f)$4Ki8Pr%GT{m(wHC#+o6HM6w%?Jv
zST^ADTobC9g<_TJIFJTgevb>*lsAchHp!$y<ZbBHq-XzrRP{0SQSGgT>K+ZmTff+}
z|4sRHNc%PR`)`K+{;&4;-zfk8iN09JYL1KeAhd<bQ#F+txJSZs)f{hMG1v}!Fo?VV
zG_=kTS9bi&cxZYZG9Ld{d!s(4J$L+0(gi)^$M#N0_wPzQO6(s8j{OVUSLyyCEhKe}
zOmXb4H(q!&iHSQg4ew_ADh+Sp;o%|GyB}%c1BFc<&en2E_#58?Kr{H_$U>Z!L6#wg
zqj>sf>yJBp{r{)%k<U`S2}Kb3E0HJ{iz_xT>I}qRBmUUFU=%s>#~_?qzQbBgg%a!W
z82zeJnCj2C?*>G#RL%N_m?`^Euy>()%D(FH1dv*JQK@pF;RAG~V%~QAka6v_FPkAc
z@N#JS693<$7E(S{s(Ycd2#Wpc4OGGfdsXVM!_B(^vcG~S(e^?#Qe^(yV0*zX-69X@
z#dZ1zdm+YQWcItvzVh}$k2U|M`*Vg?Wu*Njrb{%7tbv9L`~=sp9MUVP4}O=4JWD9X
zcqJjmdP&}sudORzlm{lA<iJ2TsZy2tRR+gr!27N4q=m<ulYohax73bK8r}{1)sXNa
zNY$^UO^q&9sk$^cK*vX4qo7=2Kd!V*b3&C>_s5O_+RiX14@Mqu18Mr@n%*i2B(Xy;
z->Zz;247qWjZWk@p)mb^2*3J_CImi*;1(p&e_=n9i6^+9{WY4+zHUF0JC1cf=hx_Q
zxW#@Z@VE5#9l&#HuxADEdG<4b|H=KFTLT*aWYbypGl8$upV4{U>vVtbkT2l>qv~&w
z1xl2@;kIe}`%i2N#0^T6BJO9~-@n?=MCnrZv+eIQ_A`M`bU)kv{=j}F@Iv>q?e9JI
zGlBQ?i$KWiZ&idTXl2~a*44o@bvPZ0sT(cg56qqDSpGn{=osg;h_4oInsT*QkBt-B
zSPmX@j@`)jp5vo>{#DhKO9iz_7w23<N?44Asm~m;&#~%~Y1IQUKtVIk`Of4eIHFq4
zXSDB};gnc7cWO9GriG<6&~);>t!B-C*td1a*{NE5!N94T-vo<+$fiCfxm~C(w$I2j
zL@xd;I;CZoD_&pQCj|70pceZ|(Tc^?cj^!Nm3Jm-oU-RjPECn!>UeBKw4)qj{B>O&
zJe^w;(x|;JVhR(AgS^E34i?c}dDVXBD1X}h4i3}se{a8&ht71rhiY;({O{WDgg@N<
zUQ&Y#);Us3?RUcehqf2ET$Dv`%}=^r<l5m1B=@QcPhlumjIlgbB4?0Ku)J36lv*Y$
za!$h0&l5NLFl1maA4Z1k1)VBmpfx>37t!sNdD|1{rx7HeM1%YR05}al3a|kbiz$JY
zq=8y^_@d!CniLv;frpz>23Qkd3OD-7QFl0?nVqfF$2MPAK4_&Z_=`k5*TY}rw{z3{
z1+vSc@wI=t{3Qu&dm%6MD`BQX_$NYCbZa37NJ*>(hIo#yL>7v0`sh*Ki(jrBDshYC
zM>y3rjyr4-4)lRO!3I$L5z<gM^q4I|UizC`BowJde{@4DZ4t85Gj5TR2nSL(^aWdl
z4Lzuf9Kum{JZ`XU|53AEnxD!oKjBBz!%ro6H2j3h(SL=XY<%)h1u3ley|QqWfB=vN
z5LO?^I@72}6VLnUtX1XiGfZPpO)7o1Jj6-$L0&WrVqC4Mj#_a1RqW?g<WO<ux^KZM
z;SVSt5j}IRe(Mn<njSjqHb#ZZEg7p?3^U-mRvbV=Bct7+<qE_SQ?g3D?~aLGghpnS
z*yWbsIz$-nh}xEJ<+pALE=4Ty=d2P9ZV9^@J(*SF%en-Nxv~P=@wR)XN8U5jL1YI8
z;4YCJ_~9LE5Z;b8=eIl7;4n^et`BBW$u>aQ_9ol)&uvfUx-5R2>oV!dQXyxQmO>-6
zX!6W`N<j;++`#L2*W#a+9r&hY2LO9zhg(11gD?jyKW_*!;6KKqfS*LPk^lC?hq6#r
zdiV|MumW7epWwHOgXWU^`R@w`n%~0v$yv}%FVJs2oTX)WCVz==F)VgI!mS`WToxOp
zA;5P?@nX1aL{_1_nw%_zK``2#!cQ-xmUJPEtKqdRS%rS?7OF)z4ZHm$tI&OJA&MEJ
z@7<GC=qg>va-8nB{cFe1^558AJAP&r`Iq<)BSQWw(foG<{u!G8^nAu8Wi_)fJP@iE
zz9Y>ZGCX#_T$0Xj$n%Iv#K6E&1HA^a3hV;e(jH6lUX-rJ`igFB%DLJk-xi>SEZg0F
zGrluP+0`d|qdKJj@t&iC4-k=AFwg_#WR=>iDW!o9vq1k9c!(XU>uQ8w4GD@2V50pc
z4H!yeAv>CMF<(2zi@BG7wUsYtIkQKM0!?wN7~~7=U77+OvKssXwnnaV9!g`+g?ww+
z<qZe{F)TvBmnFmywl}%2i+}rYQP~jZKP)u1KRVKgGaW7pA7zg0q3xGtv|raX3n5&v
zwQDG%rEb(9gdl>6+z^qCiH9B{OeBiWZrd!od-lgS>eVf4M=$tQB_u}-M9{D0A}8F$
z?e+c#pROK6(r4@-L)<~)P*Iw|S@m!G_v&Lwv=>HPqla+GQKF#R_tgK|zf<4s|A-!$
zLPIw0heQcE!yO*baVe11|34q0|3|2w-d|(CAfvfbWWU*8?~`kn{Cc|}oO-kUOs;Qp
zKih@;)Aln}uV>xQ)C9Qhe8PUFDEg868G8i*?zf)_{A=!KY!zggN<lu0j!EF3*PmUz
zPSfMi{`A>OZ1NK>Ol*Io$^W*W*`(k7Z2QBYLAS}2k};yrYWnki`<cLZxSwr*?zW!^
z{7Lt-?ax*AGy8MD{+!hxmp_(k)Q04bqnaQ8R(<FTTm>lhF#^yH=pySE7g<29S<K+-
z0j8-OP`6z!2U@e{C+u5ts$E20!0Tf3oHX;ulX#EGckq{mHs1krAbL)Oj24>Vz@6m2
z`qUx_YL9*w@0pxlzd$=2!j=1>kus%d0^Grp33K$eaNs-FU5Yrd5cm!MK+C`=BQzpb
zz+27-Q{REa!V$>eGgZS8FOP7f9tl+K@vRB>tPa14v_o&M+8$h~bL0gW^0EhEJCdz5
zu%>#?>gv4+0@*vh7GPta<jIogv8b~b3|C*kFBnC{xo4d(33sH%pj{TM>q??(-G_|?
zfac%Hb>=`8?ycL?%lG?}_I;i+Nm}a1i<$f;rSqN9IPeI%6)jX3YGZbaR|l*Kzq300
zHUXj1JI_KZ_f2XM*XpZDL?(}GMLvF9Z&Xo)<UGvGU$kak{_2W%0B6nY;Zn2Wo%n~j
z%T5J|cjEi=SBwUnw{Ze$87^<BAmDe(b}U2QFMUu_JuB8%e`*fe#>cmj@O9}itb&xh
zpx2~|-Mq5^R!JdYmxqL1tE(LpbjCNbW3~8$bYiwk%uj-if2s$san7wNIUKD!I3&uu
zGrOH%u&HTi>H;=3DI8kOT(SuD>#iS(ixI-_;9&_^7{7U=EPhuG*Tc>mUvN38ug&MX
z14$FQ2jB4d?vx*cxKsjH^B9_TY0I$l6$Hf-H|B2u4~eHa2R&sI-DL|_simXr314GR
z_dC;t9k}ZegwVbugYK66K4=)497t60HqII`XCU&(R;s6Tds+d?AEk8@k$13%6CRGo
zxBbUFdupI&RHPT4M<l}Pms~gIm<mNGucVnW3jjv1y$!Pg_sGkSnv)}oPi76=V8UI$
zIxXMkbLmq{&qw(d)$^B+7<fqtBMAY1`g!?G$-?h^`_aXa0K7fu<eG9mKe?ExTL#pd
zc)zW@SWF^QMO)|F2J`hL)@lS1dinMlJi&!fUkS(q>Iq#FlLBGX1L{Zo$g7f&rD{Ok
z&nH~Of&k(HwL(hDJhl=@=u>0t3h;11jC<XeR^Khf3U2PFIu^^TKXoFQ6`TlCb*RX(
zyrQr}-B7^$)^M>h{26t3>+IRnpqwJrbuAz-pTt6CC{ziaf?~NoDjbTP(LsKB7hnMU
zVCs)3?A#zNavP!R<>`9dhu!VggLLaq&+2*usW|FMVl;;E_r#wMt;Gvmdb9*%x}?5h
zKMUWl3-5QXLfo4qbLLrLv5J`MCSXHMtSn$v_&eYyL_j7YVl5DiY=`=c2GZ{oA({!{
zz}4^Z?Rom`dzQ2!unqtDDPQk99()WdQ>aS);p>d(gtr2WIhG$JnQd_;@;8|eV_Ac#
ziO2e47ho<<su(Nz-8jq$@u)7ER6X_{h{pj?NX{q?V9SJw4uzE3voj9sFOTLRqpqD@
zY#CAnvjsZFxDST9F3XO0v060Oq(KU<`UaZN;@R6AS_5=m!zJg2#zi8>&3EV4J(1Ni
zQ`95X?2mf{3<r!RtH*JS(w@Po(Iq4Pv8YT4>a7b|qi7>mm=&orq-lKs?FbnF^MmQ8
z@3l>zp4l`q08Uotc$?NGb<>2PzUpoIG4#)KYOlxAnevojZb*?V;m+eC-uqj>W?TO`
zX0E5>iYKdn`xQ^ebxGa2T$cFm1?i4EI2_;^tc%8x4+DqX-U@da^)3&`8GgIcj#n1i
z-psh(@jB0<-Lohg?a8ViM;YDm(j_Ck7+yVI(>-XXcqxeFT?S`nWsgbci5?g6j@S9N
z>Ho-VI?3@`?rmC^)J@BHy*MRJvD5-I?HR8uwIO{hHFLbC*w)`)n9*?@RGzE`act7<
zxGt$%m+`v9+xlNP64Z@&Y_f?QA{XF6L`r-w?kz$J^jTOhutyOo{<u1C81JORq1^s8
zBUe}Bg9%;bn!&q{b}qykiTrXWT>{w;3;xqB^%c7brXOICmjt56gvGnzz6h(|m_V9(
zER6@NRI=PugvQd0^evOZ%~(ZaNOZm%#(0=W<v3VxaMf2Z*RYJ@KqtX}Nw73=TXy}V
z%-|W6WqIgAMJeP+3FOFFNHe|Kqg(jR^`J*x2>`f%QFyaNRL~w(BtYFXSDE|Yc+U-K
zeH00@efOocqbI*5i$s06*uh0s#e>U9V0~>w3CkHgRNR&;VYw1r?rfT#mY2%SdB~-R
z>w)USrEDOIyIo3r!Btf2(1o&!5-7D4t*H+oM)57@z5-GCQYm>Z<}(FssvUoMA3!2p
ziriAm<dBvOdZR8V*8`R0M4`|Y=kTha5+5$>E1`HZ`9N-sti==bj@rr$mMiuJzxgc^
zZMn)_YFhiUwDvYNPULCtmXO)*^s$}p;M0K+QhQd}(|9OjUR{hO0{2_FWh?NZXk^*u
zW#h021)uh3)F=v-?O0(5z-uF%@9NI>;I|OUix^1eOTB_G4OCHy80=g;;nFQInUz!;
z%YjXzN{HB$^t?i{kFmCWmaPV2`MG5+K&%2EMrPE=&nauQi17#v5R>K?;kRDiH2Wd_
z3dTcyCD$CFz<y@8o{MLpB$5N{>Z($=50c*b*j8K=>FmTg*`J^%k)l&L7>VlLxbR3-
z=pvQs!GVuZHUxjJyaC^|@-l!{)WFnk#awt))#l&^R%(k$^$>pY-#_DDXbZTExP>M8
z>PIXUZb_{rt5xrYAi({nc!vNHy#e5^zI37b9o}hO1GSrN?axc?=G2X-EgcS*V4fjM
zKGGSY(sEtNX1GGlMqBd?so5ykMnFHtjX&zE2eSykeY+(<MH^|fKo_Z0-~GrCpg`V$
z06R&5odi$W)KIZjt?;31KG32=J&2$DcPIV@0Zv2yX^lvS`k{PEs&BJ&`1usA0Z6nf
zs^gFG4m%qyOK9jWt-^hLW)L?@x@uft%fnuvWe5Dhn#`XTP#c`j@#R%`KpG&@mEY^b
z>qsb`N^Zj}T@P~cy1sSztwofYu$S`lan?P6(PhPd;@?F0alLnF83vu%gn?BxAlP(L
zOS~(X*L3ps!ltWIV_rWv=)OJ1zRky53N?|JR?V}@*5K$i$O*CRS$)u0V6?twEc~~B
zNRnqpXi0hLkB;jYkTU6eu?@Upy?=*jd>5p$i+@@-Bmt!@eWGlPDqUiiHudb;2L|;8
zVt<gjIQxL;tUwud_VEVRGdFTTX}oR{R}|bEfihU(`#Bfojtu;ZF~z#2PcEIPns0XD
zUuEGtR{~U7b<rKDI)pN()u|Izy;MB|5Y?%y%3sbYf}w-Nd)CqcbY6~;pJ98kqh;tH
z@0pNZPhj6*_EdD-k1%)H4f9G$1(%^rn^68zY>seZtHT+NoP@Zy%uY;fv2d0F{L@jT
zZW;r!@^T4wa4-g|7+gecyt<$#mCKo3(ShR&NZW~13AlfuXDQ-9+py5%bZ8OwUtquv
zFrcbbCu^K}!0XOZ9E;1toqe0CV84x>;2s|D!TW~AImjrlpa|Nqf2o2C){xB<o8HhQ
zs-Os*Q+cA)=_5moLG7jWNlil9&s&`ub74$Ym(brT_3e{Pmw0>^38=AlIMbce@!-1?
zIpVr;vU~LVn9I-<x{(f1A1O?-JIOpr1&F5f0SRX<uA|X&=l<OE+;QiFYp*&L8i~En
z6MokscTS3tu~r<QIQ}L^tN%n<W3+O$1$TS{;2<b1+%Muru<$_+Zf5#xIKnU}Av)m>
zq8XlyhN!07?n|hL4F)3E(rn|lAoHoNXEkc$s7S-zD61ma$m=NuEod9u0jPhp_W*KE
z^zqC&QWo4^;wk|VUd0|+FH4WQdtQbffU;MZmOl#`xOZ8dHygy0^U9SqzBGVH`RM>l
z*y@c*0tkx$bAcEb(`kkXH>Splej>NY;OgHT2#KLC9=Y`nW@+mMf5{~chq)WjUedrj
z#46RiPZ+6y4J)R$vQj|-35<b)W<aI_1xh>=xYt90J3o^_0hF~ASODzZ%X2;nO*l;f
z7l5V!VXMxGh5{lk3<ajr1`^&Vc0;V4^%WbiBTnC1n8dv2t%b>khdA6|mJMK*B&IC+
z6E|cPi_4tGRQQkwgR2tgmTYpafS5ciCC~T|QnJHRvV%7rbU@-rer(aaF^k(WDS2?b
zP}1OC3B0keaTC8@y^6#YSlY~|n`g31>r$T)(K8@6RdeCYNWPML{DNQqhy!qhyMyjS
z1}NsOHy7aWN)E}5LuFIn9n{K9_8E5vU9EA%)I=TtUKP00j<?ngy!mXdBx{;POyBa1
z_t(Q2<K2Q}hNfemN5^<&)ET@oY8D1RJ>D(=J>G<^_D(S4{U}!n17qF{66aCp91PEp
z_swhzuSIEF{3I#9Rtp2Oo}P`#kEE1eK{S(=S9aAgf#Ac$r%je%vHw9aBdSdO%Jlj}
zNb6N8ill95MaWu9F~ToDlFB{Ktq}iw$HP5sSdAL0*CUpsjqw7wVs;osR|BJ5t_J4N
z6YXj1aY$dA6FbG~`4rlH(8>w9Tp)Klqp%3r*3Oo9NiD437})13Iz|E-{IN-bq`>Y4
z7h{c!R6<VK-OF?<wKgLIwQJzOv{GLHXb=RTkyicQ{G8|v(u5b!<wnl~N4gjKVn0-T
zY8v7t7UJz*h_XwAl3Q$V;|3^uB_FPb9V_M+Y~(PjK#P9SLMFp^0dm2J&HY(_CGxli
zaK7|R%6lx`ki+h+Lw)tRJmbFNSg1_@1VtTODK=KUKAl}KcUpV_DJ)X@QXBLr`z~RQ
zOOd(5?<})A@M3ZjnxMWbppta^B-Nc@vD7!w3?}26ilWsp2h!VtRc{-W2W0+omYUU{
zW6T+^tv@hQ!eq#2pn&abrMd=j_i_cFXj&YiUSIS~1CO_|S_DQ30v$x4L;VwD<Agl@
z@2Ss@gwPCN#@`cv;92VAz9lZRBH2lDk@e6vKr|!buRP5i*~l-^H9NT9y~M*VQubn!
z>DFnac#;{Flj?J1PJP*}TQ$;8fP|`i;{}A)1aC8mpUtchEK99LLUaqv8ARnYFcR!c
z@r8g-dYn>gYUTJr#%rgUl=8WyJcQ~M9Z%1f-+nmsd_n%kMsNPcv)$R>o4!IqW)x_b
zm5WTSKr*?=yvrjMRZF`o$}?z(Tx7GbVyVefNxK%(u0<V>;ijRt#uss`M&@$8m4&f+
zoCbk>3=eaGK=r3S#p*km7tWnorw?f>eoSJ-ic()dO_Rvm>XlG9;RVADP|&|_bVflB
z%#+J~!F2Y1K%2akw*xNZpePJVH}p@5g~!gN+qXilndVerc4E;y|2I?fO#L17aMoh@
zhG+qIWa2h#NP^HLHV!_=-CSRP95w8%g%vw7eZrx#*`n-2BWa_uk8MC(S~CWIxs^4;
zWNXUgGw(`}v&IkOCL$DmKU}2~ZiAu^<vmnZ(Y-X^ne7w<X-H=Uy@B%<zKxqC$O-B>
zZeK)y<Z4V9s{&S<b%Wm<=H_5h>I2Z+PIQpfAez&cQCIXLKxo=N57+7WIkPu1-*+%J
zOjV$dad{e)TU>^TdBhV#V&-$80h`|j+UI~A-BFLCBF>YtI*yj4&pb(a*>C3IZ(ali
z$|DbAsYP-C>|uY-hCSeozd&OU9j#G07!CZ4<;*QI-r~AE@85t-!|E{44{{A8aJE$>
z+(KKg7TJabE5XO!mjZ8~xerCyt}>q>DnfW!iNTk=s+qTonEe9gXK#9bR+-tEo|@Pi
zs4qfpLh+?Ijg{!c8}a_(vC(P_KB&LLKg?1ybt&x0yu*|xpP@&O7VxK=IHYA@pCR_*
zdeH)fF&+EsNAMu_&-lkP92#Ct!Qkj(P~_+Qs?Q1A4U0K%9X%g01V?*zJ2ou!-yHa!
zKqt;V|85jE+BiJ{MhI+a!1+*hE#54A7>B;23vk{xu%vEA>5AOw@b+_xOXvHZ@cDXI
zM6bg?zS`I&?LF<=+ux1PTmZyiPF;qY4I|crU7q7P-_$*L)+JALc0YmpGJLU9<REG6
z1bEhbwb7S4+g>}Tb=-WP@U3%(Y8goxpo_kwi*90>dszmiJaD^dE0o!mI`(*<?`k;{
z3hH<Fc8)E@N$&ho<wqr)?hKBaTbj?Ks614zmIRA%mVD`d<52laf99JJjX)azj&9Ze
zo-+9ic^;qC&lmQ}zl)oe1TP1$E0d_$>>J;UEh}oRy?ug|-gpBjgoEF`OM;)@x+Hj2
zAO3w0=fn@<cQeYN)|Ff9x<CgXb^vuB9zgZrH#PyOy3|4J&+>M>7o7Mmko%yit01rG
zSvZ+}f^!@f?9JUpJZm*xIG8?R^aJwyDx5;U>NP;-f%VaA@$Nl&o^Xy&fBz@m|0*QE
z7yljQfX$TysMCUSfTQcJ*JW|4e!{*b!O<V!`=1bpjYo8uMMgKGBTe{kEB@QIBzQdN
z$y4o6tqgThc0{=}zqtiec&W(;wC|c1|8OvRUEPNV(bv0f)#JdDmf)JuLfFmk1vj^{
z=4RH69@9B20&rWNqYd8q9IB3H;rD{q0n1S%Zou#7IJyo-any)P`E*s&b2~9dQztT@
zqbUcpMzc`U@OSC-CBZAUqxSaajzz6_&scO~L8+S&fIs~4&HP7_0$hSZ=wK+`JeD2A
zTl__bk%s{7FMXv1KX#!3jAmgI@m;GC{bj?WrKsw2@-Rt_{JkMQa|WkKbmY&<@h>Ff
zJV;Zhq*S8%LZ2yz2!II+$MK4g8L4i0ze1N+oM(OnS1!eVgAO8vlo|c-x0VIJ@i)F=
z@}_Uk`@}roVCh2v{DTT4R&XUfB&lcc2YVe(n{DAoCtwO;J?ivzUJFBKpfjiQ+V#+X
zI&(X(-PjObO9{+;Iu*TxqkXjy_^|HKSRN}>`>JTn;|`1E!y7xtq&}}fW5qsd(6DOt
zSkO4ruR%W|pilRL&dI>~?4!Y2!OCDkD+~IPL$UrPXaj;6td9yb7V2&by4!;O2Rt|1
zd>L3@ra|K`339>FV2!0dX+b9~=!AgIpmi?>5LkmOM-93I`j-XW0nqNaJ*r_D3QQF=
zL+z@wIJHK9F&&UE6@D_w<4{}3B<rC-k$E=4^v_kB%2P#~ZKch2V8`cNW<hx{OL6Lx
z867w((6CADwxD;j0~Qu9@J{peQNe134a34}wP=nz6wTEdw3jv?M}eKVFT#RGdI-(a
zEuVF{!(x3-2Iv_i`^SN9fmUxpw^-1(9SZstVGGOCbB_jeGcJp;pqnk|QHOwb?iD0E
zMqEjtnE7LzhzJn#rXtjNl5=@_J}r=9e)7uW*yxg1)<Zob4{dCaoQMccX~dlrw(UmS
z_V+4WilIDs<|OJsRcFlet;2uEjGO1X5&yk_|B6fJ`R>Di?fCB|{5O95JYOyT``wxI
zd>7%r*YMj9LFmgl4*$!|<KO&Y{LB9hKgNG-f&Q8Kx6nQYjyrCI)vfrimfzgn1hx$m
z5e{-Y$WX<bg(|5LQ=aQjWSk6T*R9_Zitu8ApWOfoRjQ3Q(jWnk8jpz_SJ&0Mf=d+t
z#%_ih*9jRtwp9J6nCDT7^4@nJ?DGA2_vJb#2_#Ivh3a+<2jx?bp=oHqmH6E;jKf7Z
zV@q9VH38h|RxU>z$2!a1*Xk5GRp{@$wzo5k|M&kb^+xi8=DGJ4>sA=ATVPx1l^Yw8
z<!Dby)O=^a?pt4w-k`oy>cDI_P$l50fVu6U`H*Uow#It3TSMO}iH?G&!$e1Y{|nr#
zl0fJu97f9v(Kkt5SVUVbmZ>7yqJSxR2e@{lf<eVx3!X)M)n83?6EdJ&aXBv02^DUS
zRwQEn#PYy1m;C<fr%M_x^{qLxpnJ_R(N7dKM#sgs=ES$<O#k0IhEIR<uH4*zOy7oI
zTkvb^^kl3M%35sKl<m`#(PN*5b}@KI?!NX!(>2#!zuo2qu{>kedt*O57nX5tKNLrV
z3B4-DV2MFWjE6r$8NGQSEK^^$urcTcp}Al$2){}-8|;PoB6rcn?u3OSuuw5My1YZu
z#^{OGH>PfRRfZ%*)zP_Bg71~SFGW|6B8gmx$KhbyW;7>g4KvvNEREYbwN*sE3N1ez
zMQ9=CtIln@)d`+fV~F?E71X=0NUP3gh%PuArnj$X;26j$uON|@B<kb6SiM|7Fj}x@
zJ*=TKYEAaeIE$w=AkY4fmecWrpBNl$N)`;m+=k|ajURkn1Mqcuc3*~my7)M5*#dbv
z8B<c|TZNW!$sU~*ncFgC%gY3(#{*6zL_ad%b=hci4DpPEuR%RKis~8lJ3RFfGka9^
zw@U8Vg9UqI^SRS<#v0|){PTeMe*WI}w_e|_CShdS)$2_ktiq%m%!%gX;oT25m&bD3
z4;1W;=C&tOFJmoMJbzHw7%e(~Z@fP@n)|_j19q3QHs#=B>ItX-oo(E7-3~#b8_3<#
zz87V>AMSkN20(sTH*iVpmG*bHm=boEwxwWuY|)nX9w(Po@bDXyNqw8mz6^FCWV}4C
zoe|No;TkIoLpR9}d+{OFo^<}+*_N7(y7=dK;B{p-3OTW$#WVv{ekvff>_?4c9+CU4
zeYd5(vAyfHbH0gQzTTeQvxo3;Al=%Uhe*-(?QLD|JESJ+C5VBx_J`j{{v<Z0y|H7&
ze*qZZ0U+K*N65Z*%SLqE=k&`4)_M2xcuzFZhrd=tk1c(;^G?6=!D|P{Wakop=kR!Q
z^g7JxVJRm1^9Y&Rdyg9y8@VL$<Ie+~+Lv={|M%eUXW_`pA7>rEr2fa(5yxNi?;j5m
zk-yhJ#Pq?YZ<+?ahu1W)FRfjzAGS8FX(|o=50bvtb>&09O#CgcExsjGxv(lxs2Az0
zuD)_`-2a6}+qdgh+y8Em!HZuD8h>v+(E8Gvmw?8aqz9+g?$+*t=8wZn1<CQ-?WDLA
zd}4p=P1qKs;0Eax*{=QVEf45_SIS)2(%FXRcD2P;xvA9m+6!3j24DL%|9-HFuHy2j
z-w@7lsjp+$+aT^1+25tx*6j^d|5#JsImY~Wy~#HDz)<B&+P4q&IvY$5z({|z1*P_d
z+kvfbg=r+G0GYW+4|01q@YU0!V0+ZxIqU;GzrG!lfg-`fU3NYG8Eq^gWBv6b_}g8e
z$lD!V5CzHhUP_ww1D)+#m{qK9j}P-RzGKA_?4O6X-&#6+3oJkIats&d-_kKG1lx%I
z4SU~snvsx-4Ys7b&fG0{6YnX26>4xr{oK;wcuW)oA8jdY>MF!@etn?ywX;j(%>^_j
z`S5iM3{!p&j2wA^ylG;p%4<Kn^y)2=vT!CWSEnLzVM%l}CZzlbY^2dZ(X(^)7AeV@
zSR}dSuo4PXr|8gk(U}_G>s`PT2`_fK1zaqE<NHsE9;3b{(ABl+MmmSh00BTbPz+S;
z>Nw?WJX1=DYia4Wju8v+!g;ZC*acYyOKm}J&hGq4$B4Ns_&w?zlHn~04~n?Kdf@<}
zQQ=tkb?3DRK<LJbjAfc9R4aNA?~aJ4%BqEGGAw2=`gMl;m((rygHU<xxB0U)8l#U;
zDMe<qYx_|+V}-Q(3PM#wuoWDK$kU=#+j+ibP!0nPB5OTv+&GBu2O-anIlnQ*C?mDO
zPjf3R9ZYM$gcR~4dMTCNC=yciW0m(suW+v8PxL!l<tzelMmwH_;{!zqm_bNv7#DMK
z8P5zSS_2Xwc(%e1Oz^Q6kR(j07ysgTPp@;~8brrTKEKg9d&(;aOQ=0N?X!9W=tO$&
zn#TamH{dsNU7Y7jlu=@EQKAF90ShA(uj<5?^XqRd%}?~y^*jLBuHR=MF{h-m;W7j#
zE`l@QF~9_&K_A>2-xyCG#5RZ@8x}!jodcKhWq$lFfd`?sQcag=gJQl@Hb07FyI1RR
zrbTWXj$RypVHqcT^g^~nR-IF<_3iezjov*cgdd5^0#%8JSahKpC2&if@lH@@&qw?e
z2!mc|UH>xNDtzkYT9=<w3@sb3hfS}G>ml*xHC9L*eg7w*|0SmX(hmDy#{Rb;AuzXr
z@vg4;cEpV~68me{3kBvNMvq8?Yz=b&qN27+O@PXWVGvTT1C@bty{5=dM%ufYXIY9|
zl(=ky>_Fy}SV|bubZU|;f)*~dE7c&Dym+%FNdu`=CHFDABv~|Jp(?C4Bq`A(d9pKu
zB%b-vfzAFQ6C|x~LIhD^L|=T)Wl*f+UH-HJ%H+K9J^Ati%)<K*prR&o<OOFvTuiKz
zD=%mXqTz4=|E5K=Y(d=iAiWW-k`q0SfA1^7-@N;RPO+MFvE6Drh3Zs!ID=4(7H#@d
zDb1e-Sz<6P!HyxmCns85lcVM>CP`qD>5C`#p-3tK45eH?ZWUs=e3Z*qC7yC0v0OL0
zCgpO1D@(u=Qq~__S%lx%pY|>?a6{vnfC%1NT*-?i#CO*z=124j2Ej#3_y{6I?@av(
zxbq3+gDby-ht#v|O+}#n?T(YUmmPL*Vdt<b&z%orM2lm7wkPpGt5&!Lrp(o>5N3tq
ztO|{+5J6p5Xr#?F+z6A$)u@WnW8Bg#0vm@HJi_o%8pbc@>}+Io>GfXNu*0JC`pz*z
zQ;3JY6ctB3<iVBeEUiMpl{EC2PyrdEP!x<H5{~%gw7+e(@WI68DA^z}umMU4AEtxq
zgyowe|616@+Uin1$b|X|RkvK>*xKOo;?8hu$B0VlO{;;L8U`@v?X|7!?j@9`LmlkE
z4(YG)WDv1<f5i^zukr06oVfby*6=|eRsv-IKuCsUM`v3&LNK@-d$3kAID+-zaZC51
zHQtpIEkMPb^b&%z3B2Q|6=xV&B>;O~-FA#xEv|fH;5NSPc7Dv8iJ{ztTRB=NOYo~X
z3-B82(E(YH4)EkCQgh(QJdall@TkNA<a>~`TQ~#x5x#tcz;$@CTVZj46*9gHoY;z^
z7cxezFoIcRCG?^ImW@v#Rj!>72ke{)Md8ZETqubiUsIxR^|V{$9TZ_mAm=jngnBN^
zc@_A8?L?H>Z1ge22M=-7Lj25UV|3u4aQC<}e`~<chaSz4@)Q||lt;b^uxq8<KTqKr
zmSB$Pb>KgQ#i17xE(`quCVT|SAvzG@H^_5eBD?ldW=EiTD^U%3`P%2$Q9rY6t62et
zv(YGuA;WTZz0QaS9l}8}v2>lsbRF<>r7E*!N`w+xo*7ZcurzH4qHH^5`6&>|iK0KZ
zVEHbq_M;JO-}7JEiASU(+wBbtHq<oqL_8`WLfdRaliSKEPC3`MT|&hW-SBUl4S9lJ
z2qj2{q6o|#z`+a%0Dqz?KfZ&J*f@I$dj$nDzkZir5r6<KRx+vc=(m=a{Q7O(P-0$w
zd^_Iz>*v#)9Z%*<U4#X>km1F4A^YVkv<eq8bU4324kU8T+MtMLIuHl9Y;@%`b+Hiy
z3&oS~6gEj6g!M@sSzx+t9ht{Gyumtow$8q+I<iV7ZJi|e4YW#19p)00c0S6g6B>fG
z5fIXqv#ZNiIgnLFR!3M^ba&cxGi|71D;%^H)Z-PRJK~%?SEL|lmY5fS#6ijW`Cx*6
zk`__R7_C5jho&hQu%9a~?g;?Ofp`ms55(kQ`}m$v8VI{&fs~|y=phFXgu7s;!_}#}
zuMTsVs}q!0`4OEYv-(m#a&<b_xr{$i80m(}iKaikopi1*aL&_@T?5d7^qbStZ`fy)
z!EFYt(giCh9x+1^r_)7U7*jBMVIAZq*3&3j?-d0ZsZ&sptnnuMmIGs~c{IJvaY!O5
z5O48I8TcFP_Rt;Ov}c&KR@ZeJ&QKKYkS68u(qg`!R}$YYSj~r|kjE~LWW9c@C~nVb
zzfyqDz5(i;koE?)g~w!9`Y}AV-Pe9~B@O~`a7ye{Dlw0Hy5c)>0l&Ud-c%REm2g!^
z8oa@_e}j1x-BD1GHx*;yX1KCa&A1Fvm56cS#dHt{Fw)OpC<&YMH@%flh5=bY$#~a6
zObSWYj3|_*R32CjpY%NW2m{UZ{p9W@C6f*JU|{Uyd-kC=^3@8!U2l2eAp?L5&kO7g
z7Z?ELNv?(6d3Rky2UlrBOZhwq98AvfgUIJJg3KbtoiguRaG8EP-uo6jrr(08ErfJi
zg7-0y*;E00a+t2GCpUUN7*R7Z+pF6_&XFED6EfdZRbx-VGwJg3Mz{jx7z_He&#r7g
z$$@!(EGW`>No8j-r8evi7olGz_^$x}_05{+rg%5{CA1wl9k7IihB58|$||%5xI%)p
zXtsKwX-|IP4j$R=%ns5w^~FhYEfTnej~g#_Dnbx@g-tvQkg-LT@=}ccm8Smu;ET}w
zLJccN=0XdRt&?`QF#ZRck-Lz3*WWq>!@^P#gRTNckV&(DrG7i;z6Hg6&TMI`A8pO#
z9~4ISe8@i`-Qz3c>A?-Ifu=npm^eeC4UZ8k0P|C2prF@3ZwJuD0VG!*&=Dgb5}wj#
zYeSzR?$@m<c<)H;3a{<KN(5AVDF=UCfWcM2!6SyasVjipGLA*^l+2It4#lacQT6k?
zs$W0lGS{1a{ELyoorlbqcN~_<*e3yHS64l_rP>b}3H1ySu3?B;Z1=eS^BWeT0l7+Q
zz-bX2-WfyyO+5fWP)3gvDsA`G@?FJoHR8q6!_zFWnNVDNoO8YJ*SYWEn>Y@cKS1H8
z{TSuV=NQJqGA(|BPG~O~u7dP_iTinI$hxKdvQPGp=YBrQ1X9<fzrC%K7wK&t%3F8Y
zH2m(kuoj9l%R<k7$rQA&ZNX!;3AoTPOms*Pt{J}xhQc1|7jQ_S*(zr^F}+rGh86sF
zbx0FH-YjR(V{Cf6>bSO7Z%iQPip|!i*ct17fC>*S4jgfka}1(A;rkzx8iQfgfCh&E
zgi&PqVyDCd1OmW9_W;@jqS@I3j4)fKvkRdiF|r?q!f3S%XfU=y0No?QK&yuO41;^b
zKj;CD80dkV*a+QY5-RB&Yj=K0k|LZ$7pAy1E{SndoD;(q?{3-gv^m2#PukeAaGQrb
z&?sEaIlTR2Eim@le?q}${Pl9dX@gvbTK^F3voQDIG@6_%O2}~&&IbMC1)e@R=B`Wi
zorHs>t8V|yJl{4kRY3mxoay>E0_1$ox%xLk;E<PB|Hf+Ib578|L;PK!f8(dm7)OFD
zdEzzEAc%~l=_%d_=czG$<ly*$wo-i!rk47LqLhd)@NXzuq<@?cE!00wfksm@q%9}0
zD9||@hLH7C){U(T7M*w#ZDE1<W<Q$s+cpzI6K(gJjr9mt9=$8DD60E$uLy>En_P;>
zuKXYNt_41-;@lq|O2Am7qD71KfCPdNjEWX{CL}?E0V0Hl8k%g9O|mB0U3WJ;6f72O
z@zr8$t!?F&R@zG|Ds64WUTv}3iWV(eZ;KTzDs4mIw$!FATCDf~pYKf0IlE_*%_b0O
zJ^MTRpEEOO9^ZWP&CEBC!$eQWh<&v6>+k&o+OQqa2cCw2=V8+DAMgpy5NABrJkEau
zUz;PnuWbFDs*mXNQLEMZ^L7=^`m7l<jq$jL;?BX%=Ths=2U_(J!W5OBT@%hzW^&cn
zd!K*=|Hq3W=}vkUa@f`IINJ|!uJ`-sd?8D#lfK<PUV*;h<t2xqx`pt+L+vSpOk<~k
z$>83A_JsU|3(5MttXbAde-__AqTa^|COnhi4ldw1MAk;9QgYLV09A6(LLRzh(93qK
z(ms5W`Ajt1j+XNoG<@wXrxhRN#gbN4mJQROW^R3|K$W9v=+S0VOi$roOVpOG>knIg
zWW@t^&>!x5BUaKL?ic&WfnmZJT#>L`!h#gse;?9I<SaHQG7o0&^$*!x|L{kKKlH$L
z@MSlSquEW=QbWXddy=lrh8k<2_1Z-4nrwG!{Tx#JDpozAxocBR+M!plgu==+!))D^
zukr&q-7Y@#{5~2RN-{gNwWz+BWOudwq`IPKduuHuW22-OdfV=*&!I@l9@`VIpN!@l
zi`OB7Pm`umbw1v)dL^nIkMC^g_;6lQT$GOD{-YcKjFP1IRQkofvD0Ag7d!L7N7bRM
z`!}IDRDWhadlIV6+t2n?&4%v(6im_|VoQ$$WbCH9Wej=@Pwb_tSh__YQS$*%l(Z?C
zhMq?o-a*&2?Z9+bF}8a=WWrtPX!4cELkG^%Ven(|%IP2{7qE5LE*H(=7XL1Gu<pQV
znl0T#Ipt=m8to!{LC*ZO7Lngr1ND$%-$P{I1s40_=+{T5T5OTA{{~c@SEx4LjTVO?
zIa%Us`{@skyX0LSQ@l#QyKDb6yo>4^zvM>+w*#8ZxZtim3pHSBD}x-dzaQRpQO{ac
z#FJ^y)=^~ar%sCd&g?vHP<cc*44bvHj8(%ppSOBUan@zUZL6r=<|73E>^Ajr#v=#L
z{UJrmm<3svEoi%u9{9+Xp{*a!K~aYaV_DFRvoSoEy47mYKy<cf?0+a{&BIz{Z98<Z
ziCH_fwdN0!H7-u!QL(5`H<m*r-1J8S9XiPZ!*0D^wKK@VUQ$nGZLbb|8&tMlfuCpv
zF52cJ{ZIu~O=gl&w?$zpZ>bb+g(f#KkkeY9_`Rf%?2i;$T2Q3$Cvhp<{T4lXr*QMD
z#hbkXua&?Lj74i;6SDP=_MmJYx@<CohXmT2$o@&?6FQm6<r9`ttEQ#(4r=)V81bMX
zmT?L{iq{t#4&DOCaSuvsqY`u+hT)97*eT#bh(g^xK8a#+Nyh%C;QN#x^W8oz4N818
z?ttQ?^^`~Y56Y&{IQh?LJ068Eqw$4)So~XeOaD`U$j2An*rrsG4yz~LFcR!=@CX)i
zvCY7%nSJ;3JP{6~Aa_cT2Ir7xA3{|^V;>`KkF&TH$BOO4%ULR321uEz1LW6RoB?Ga
zqkGPwYF&+`V#D|>{o;aCZvGeEw7dGJ-25jzTiI42-qwFm9kkIP={r^eQ1zJre1I_%
z9nA&rK#POyoO1I+`pqZyVpIn&gZtD$@s2afWc7)*=0_L@<I@AhhtY>XGkm=Ym+CpZ
z(;nO3owmjJtYZH`5Zr%fhXL=*uyU>nz>cWRQDE4gkMq&gTWxsj6HqzGLdQXnMm$#%
zjI#e%NV6tldz$~qG{5B{Lh)NxP;W^BunbG(`ELC_N?MU6Gpi0O_ArDzq=MDf{3fHK
z)*+$RO^__e#?>kkeE(LHOGW)Br|p72S=9QIq84@m;l1H5UXVE3DI$F3poC&w)jV^?
z;0z=gSqBru)j`$%TzT!e>J<53VAld_DyuZc)bm<@0ZGPZ$1v7vub}m0*U(N8^eLHH
zuBD~*?P-I?;E}<7*1T~_OF?@kl@*i`7bqLWCE9AJl?!&Tm<!YqNOD^fz-otbKD_@X
z7!G_QAq_0`mI*3$9?XX@cxF+{NV{yb)#+9e!MRrCv2ivDRphGY$oShZ27Hgrd>fGG
zK(u*&f<(~=#3^fi5ifw`aXl;#`aSWw&Z+ec%uk@Or>Sh&PWTjN%TOz;U^<-xPr@8n
za^RY{%t~Eo@yKv|0pR1^j6c;JTlpEH_@T`%3utLHKRod^WHYr!XnNk^#+a6Ro5=9j
ze-I|}S_;&=6bQ-+g?@oe0&V4>fQmrYTO6byWYO^WD6+=E{rn>HfrVD_LSDf4;6A8@
zWQ}PmcGf>-3nt7}Hi`+g)!9}OQ8chpOvr=4I5SFR*bgs8vohudepqbGE(i{#A-nmR
zPvC5r{an_+e~t3U7Uhza)p6NXElNA7W>aA4#sqUnj%NrGw*{pB#m^u`Y(w~|^K%&0
z5ET`=$CwViEwlJ`$b8TnUx;6Dqz<YnNgc*knKy5NljLU>#OmSmcF-TB`C+Bev)pmU
z`6HP#FMgKgbzA>0SnnXl>GUPN%|5Xz_BLaA`0t0I`AT=;G4PXA;Hm^(c*C6wB_A0J
zTav>kz2Iyt+Oro&|F|HXgkYm0t8&oWlsei9J|H7F20~VcTk$L2u+CMOqSSeg6G$z7
z#%V2(Z^F;25-KK8_4A3t1KL%hZ$mB{Ez|AFrgF9Bb<|ah_aIteHyCG=u}ax1gDg%x
zwEt?9-hm6_7|`O>BuvQTx)l?$Axgr8{m2<?=A~ORWaadPDA>JlShB^@iEb|iG8y~a
z`@g4xYG<;?k~7(!PMA!&$1$1pj%Ko(x8HcaRX-r>yf~$ChjH<Xs;wW)?;#zARtDrf
zsLTH#QmX`kv*}VCV3ltc8WbwZ(TuFw+xL{UUxL}vS3`5W=Jg@!u!J?wnrfRjW;QWh
zh(-dFLXc!=8##xEQN<BVzoHpbuVCI1HEzwb{UHs&J)9GiS1_k7uV8hJdW8cKwy~|B
zy;C(2>iipgY#Y-PZ71=Rs7$oST+YtU7298#c+63uV$!Jf*Jrn{sX1N6Jv4Sw>ra&B
zaAqpLy~f&y%r$$@ZGjFI2R6V54}cigx*A6qGARo(*SvA=yw*OF8u{Xs^uIZ2hfLja
zYWv)_q8}1+TgG`x@$UKkQG9>Pijgu??G?c}+^?T|W$T9ZR*nx}JFRuSemDe*-e!HT
z8$FMM^I9*tO^q3_g0S^BpOI8z@MNv;?~i3#px$*TZJ`cU_P3U`_K|nQ@ugcWN9<b}
zf_$PSChhmi5+j^Ob+Mvt|4GGdNxxN0hSB-`$1Z8e)wBNo9q1sj-L2Ys%=|J2C;8QS
z$%Ezk`w*NP-hUQK0P7zg?rUt1oeIPEX;3bdCg@<Wgdi&@BEZvVXaH(kF_ywmD}l2C
zOa*(UDcHSQ!An#!@W?>C$b<9nB98@x4ua?V;YFO&bd&P=7*9TUx_BE~Nt||<p?q%5
zQa-ns@M(RLV$Gpx!m2mD&KEJcv>wX?4qOA4xakeP3>z*dI8cI|XERXkWdiv7rq>xT
zY`7kQ=ak_k#sM3yU%<g$c!{yWg3BHFB?(twlk{J|9*cc5?wFo=+pM;WceHN!!9U*H
zHgw7?V}Id4j_?3HhkGmBSJD08G`OGV>Ar;SgX!MS(|rovtER&JO`KPp82&kQ-%0l;
zJ>B2Mhv2qtV)*xYy1z>I3c9aJaNmLSKTh{`%wLVC`v$siQTg|DUq$y_bU)A2eF@#$
z=-$uMeG1+4>Hg;5;`7h+okRCpx<8rVei-iWJ`DFEq|bex?yu54D<AG_Jl!9s`&zzV
z<LSPE?u+?;VS>9Vf4U#y`{#MOFQNNtRsNptQ|LaK@4wj=pMQpb4&65u!2L;2_jkVs
z_l->7eV*>G(tW(jzo+}-bf3WV)p)vZp!*KG7kav{qWfl*e^2)%>V2lapQrm2x<AGA
zz4=$q{L_6U-JkSyfA_m^FP{$g`x4yufqt*jJ&W#Z65J2M{c*Y<Wcq3n+)4ipbT2D}
zd!eWMD!T7u_~&`LFQIz|-|y$?K85aM>Hg+h@%g9xIfw4s8UB+A?wjEL?swomxCrj|
zdAh$!_X%`gli<$$Jx=!uy4QHRZ=m}Yx)+N39kc(kfANxks<S|y!f+=73)AyDdOlM;
zyXDy~c$rNv<;C#w*T2N)m+rZAUrzU5Cb+Y_PNsV%-M{DQ{(oEHo=5l3C%BVd&(VF~
z<#3NCxNnC019aa=_xTC#yWxHZ-B;56VsXD?_FwmJyGdom**M&~9GwODUqb(5XTpEK
zgz!lJDRgh5`<sX2=|T5%=-x*6Cq3QYeF*MVC2+sb)BRPtPp11CPxr^^zKh}4B)A_!
z{2S=Lh3<t3?&Qx^bRWX-&r5J;`j^nXVHVu`#k=3S8Dk-MnMf~1^s@KQN8XETU(caq
z=@oE%5{_<uV)*Yq2=~Kuzt7YCRl2`K_caObln;;7{dT(7c)D+(`&POaCb%>HRdj!<
z6z=DFx-X&oM!NU&be}@^R=U6Wr}+Faedo}9CEcHlcfWOl(C?iGFxxxp2s|HxY1@Q3
z@O-y;cF{}wf41HKcKTmU|8*YzRgfF#WiY)I#>cPRSJAzK?&l@AvwdDd_d~Pc-p|v0
z3f*_o{Y@NN>`Lz}zJCtgH!=Jt6Wp2QcelWO2i@=UbbpoZ2kE{h!ClFJx)+tfy(Yn(
z<-39IgRg{pVZ8gT+$ah!*Taj@KTOXtdOlM;yYoX4Ih$VYp_jiNjL+{LxaZRSF}nX!
z+$mpL7bVJDCeEPeR(k%Xcy`CP9bR6&A6~}JgO@c4@iB<U>0U<n8c+8PbZ?`3VS+p5
z^(wea=A-mkJ|8~MYEO(iJuJ`J^tGJ6{(1m&W!dX-!oYjkcd7q-)&F+&zf1k^RsR`S
z;P_tlVD-;aqTb7%p#H1Wf35mouKu&sf2R5`SMTO1bEz_~R{v|&|5o+CSh-dxb4>j|
zrv7)R|8463CH22n`8=r1hBEI_=9$XeU;Q_z|FHUxssASRKUV#3RQ~s=|9tg7LfJp8
z%%(E8D)VCXzf=9+qyD$3|Dnpya%Fx>{jXI2rOJM{GUq9Cl`_|={|5EHQrT}(=CJxN
zQ#Rw(e}(!#r0fr?|0C+ZO?;|<o>=x?c9SySuKw4l|IO;ZT)A>7>U-Ifl}(W{=d1rB
zWiu21J7@ZvnnLEHP^76A^P+|^<XUV^!~GZ^(!Bat%`*C4G|Tun-(Ni|%}~;NZFTc3
zWBu5CqjqA2FYm&N%4MNQW5p#E(TZrKrebMLEEH;rR@6jdFh^Q~u|Tt5x%e9@qOsb_
z*ov^fG7zi_jjIWVRRYSU<SRThNih6&k+B!|E<EqWz3bFsBk#0gBmeYbBaE9@)#QBR
z5X^ali;c43#l|7r`7`p3D&C{S5B-@|*c;)W*J|KKgt--W74G%8vyCPr3b*D!u+bk0
z`kR>eXhjRNz%2Q~VP%Zf20|5;b%7?oBt2}j7}a<;VAL3u2q9)f48P$snhg`@2u;C%
z5I&ml3oAF30LFtif<`0!Mu2{}S0IE4{6t}DvCI{Ciojff5X1P158B3zT7(dSOQlf<
zQxn1%2Y347RcX}2CKi{bN~E;~{_9k{mGB!<>4>Rk=AWsLsuagM%t80l?^C&LK^mC5
z2-3S0sjY=MhTA(Y%iy~nw6kehX}Il@QQfA8I|S0e4l&u=hA}N`8kInXfvGy{A8HsL
zS%IscvOUqDW~P7t6ZkXQfBjCN0+ibW<?5T!*XWl4=L};2l}7yr^g{qA41f>J*%;6&
zLE%F;xiU^PPUNkAv>K2xfVcW7f8v+^Gt`fstgt19_OR&E-RndZ3IF>b@wkxZei?i|
zF{5vWfkVEKHK9Sq3H(Xcna2zm;g7H31|0?{It)<ZApI64=*!AKXaQpeZxt8Guc(2@
zBq7ECP+|Zm!doanpGPhKIfiNEfKTUxOLa{jhdLB(uW78;^?0fV7uTp7UW+$I<7XNx
z@#Fh-@M9|JVAtLt>SAKZ$>ocLIaY<o_gIIQ<G&f<)WS?@<Wn_W;$!?%tT-zzNm2>9
z5kd{3B(X!NY!73iF%e+|5mG><f21)Ip$t=goAKWQH%h)_F*4VqRmr6)FGxMgJBCU6
zio~l#EJ2k+N=qM7EwWZ*;5d8*TVIuMA>AoSoqm|(2Dn6E%aZdUM9SL9?e<fV*NKop
z3_W1UA)%sO(o6?STGNEjb$Dh<uLCs#%2bQQ9G(0!S0R+L<T#bqCe?Iw-p+)OzZj$?
z|842aa%xum5(FKVf*N7aKuW6)bf{D1*bIs#Z%^XGh{lD%vURsxe1p8lFomb{V3OM9
z^qE|qcN`}<N3PC8Gf^j4E1W*bZFUN$!Zi=U<>08r=}5P3e@&!6grAAnNFnwTh8wKW
zd8*bVrZMQEj7}wG2y2T_nLL@C)~WJCI`yzp<=N&D)=Jh#uiEJ3Ce}OWGuz|{Y-&)e
zqWCdylOd&?HFzwZnm{wUn<>X4HHLYkgm%a2Q+1v_3--z4<C}_dNhe13uqZuaxI^u-
zD~yy=1~nrtiBH;#D4yeEPA}f><kU3Cu_6!MB_TXqf_#uSBluB5liQpeNPZ407fQzf
zOc57fvu5=iUudp4`gGDU9ZO!&aURRubyWU6S8m5=eP+F4>(6mY1pmiNz3sVj>kW=f
zpZk-QRd3|tc&k^U$M{cZC)3O6u_@1<;MCOer(-(a+PALe?%0%D&$Vx<<<A{ox@G9>
z$8kL891Tkk_UN>D>E*Gbl4LLQ{npP+EtlP`hg~Z}9b5Wstk#2d)>7!0WOTu@<H#?5
zgwfOG=B^h<KbP+K(yfQbrk|M_KgQ>%qgwa=>Sv~wKbtSp=Z>S<&+KY0Iw~LPpypt_
z&iNv0L1NH~no561U8)|fbJi-P#`VcY@^z|ZpuR%%yFFL#Zf;AzL_`bufu1M1M$5@3
zB5$aRqP~uLHPL+sjO$@yJL={b(YiYA^sIr+MU?L3BhGK~@{WT(M0ZK8zEkJP84i7Y
zz+cC=9<lSXmy+h}%nGGFlsO;HWGz?PNY15G%P-pY^I=adO#B?So(~vhj4(#E`%V_>
zWca8w3XFNi<;HB_V$E)_O-*loyy|zo=end7<Gfy2X}CllILnUnI2-}^(RNUe&iOyB
zP3KIQyYH!6R?f(Yo?8=`?a*wzOZ~lsU?NU8kDJPcvm_0OFHy(Lc{zF4IcuW%=!5cO
zS?L)}ZI<%Wbti=KiZ3&kwx;X*ZTw{OnmrfE*;s00?RHLcUAlemcs`W*=8orVbeu=O
zzoKJukD{D))Vuvotv<Nt#N1;unTONyAIqGk7uUZ}IXe4DM_<16MhR<efLr54>2++{
zq@&s1AD{G0y^SD8rb@rg<;(Fo{uBB8{+|~-cJ0Im<;XR4PJU;f+u6HvyC(Ky+!Rcu
zy?3`0GMbikb6gpid^J?+^|w3e_Zo9ZYnFQaPI`K;6Y33Vn_mB<Bbm_~x#*fc=s&MN
zdHj`^TOM?!o$g9K*SzYzf>vty`>}tJnqEC#3a3}s(;17nV@@w#DaZ73+B@=~w{x8y
zo&P<{H+}hWywby~k8-TWpk0yA|C#hneN5VO?Tv2T(vu5ak-s{o<4tdwTI*uxu6NoM
z9sdXA=pJ|4qtc!)$79=m^hODPptqDgcs<Ee-D`tWZzH<W-gd5cI6nKW?)h4`_Wk|6
z-cv^7$ycm=Fz#eM`gbee_!dR>_{!|IUi)El1}WftL+=so{4Ko-MYt$+{p9gS?_()#
zQ>SC+^0qfx`}F#bUE_(~$X8c-<UK7{dn3R9x#j4ThF$6Z93MP<>||Nb=@*XAextOp
zM|-|IwGpYCf~m}ta?PP$*W6R{SngD$Ct<pxEpo?~uFmNAE=RXClU|+PjWo`&d(B=+
zo@%}APDyx4p|18L|DF0j9r0LiwEkV`?WD>tACy-rr@VBfR%y;iMV`CmKv()T>7^)n
z4d=S{Q5bV_?}4+=<aH*BiFM0d0q?_ldhVpDO*kc`C&x?f_M$uOQ);WQ-SMT{KK1TA
zS9&>h$``FiU@t@OstSTZ$tNY?6I<gZyB(;{;>nE>@Q-tMRpK5!_nrr?)aF?{<R`7S
zW9oZm|4e70|7Y)`aqpH%q!r~6&)BO~J6U>iUsJMBKPV45N0jTwWlw7psL!)Pbt$k+
zc%|CDJ7xK?JQpE-3FOsArM{A(YqKb+)A88!lTxFa-NQ()HB6^%(s8C2qx4p~n!8lm
zqg3m`@swxQfK+62SLDF)o&V&rFxB$!njGvcZa;RiFIBpAF8AF1<)bej-0`K`KksO4
z?~dWv=cp&;Ugzc48@!%AO^@bzCB4}`bzV+A$Cc@6r_(F5blRQX&S_89zvDIksrErq
zZAbon=#acG(v|*L=k>iO<Z@~?UB{GeTbfSU>NwMrD(PuId%IruR-RL>%U$8$<EhLO
z^Pjv9rz+1nufM(BiltYxx;9Sg?L4MZqsi6pH$Bg>k;`2x%ifYsEJN1NWHSyuU4FgI
zv+32#V>4b&jW694bkB1pE5)9ZtG&UeJzr+Mk&9HMWe(=v<hyTjhG9;yrKt%<`F>F9
zt-h>g;aA<rQ~YKKzrDeE4W5)JUuGgtQ(qs$tRhcQi~qI=zbGRou(ber%A)2jy11pA
z)5Sgi*tK&$Q_ms4llA`j?g=HRJtu3QnkHurlF~c{i}X*Vv;Fltwv(EY9nbeA^OtM}
zFV*`0??r!++OpR}_|-`_duH8d^-<hBt!0Eh|6~-tFP4WD8oW}aXXpJ?9ZUK$PM^Bx
z-b<BuE{u-pcpGPSM=$8)0K2@M>wd@)nlh=EYdZBr$8s!7TKDdHLN;}U?~i}_I5{U3
z+0j$$fqR2X(&xzc>wJK-^m@DAyZh_u(^{`k?o7_R<CF10&-G7I<MVXtzdPOUCptN~
zsdHJ-6*+lq`Uk0vE4Ab~-uee!&7E@`<}BIXmJ^!(N1yX`Og$?by2AJA$OoP3_XmBP
zoYT2Xcz=x-x>{q>qquuC<?ey%wZ`@+zPCzO_mG|CnTjMJx2HZ{_;-@?LMiV(e8*cU
zrdlu4kyky}pGj>5?2gZt?ecwh>HzsQ1?mMN*elSYz9LNRAJ;nbyUF}AJ8LPw*+P9|
ztVj9Vox1cS3e%LTw!<CYvFy{hV?Opdb@p#;ZK5sH$W8Ws5qxt#5Nz~Eg8rt8nn)~K
z(SrYqK(MBwCKU0*Tp0+);OuLvjK*pMp~_H8EZh<s$FFp!F8|W0KRqE!QmZ*Srk<%Y
zU7^ddX&1Umh4gs#cq(Jv>ZejadbT`!TRNmywjH(ky`7`3%DbK|Pc1vrr)#P$nvN;m
zwydKv)L|dXTpZ1EOGg&<93Q7PzH-OcGi^_*{n^gj9e3)w!x!mMBfS`p*K$8v?NK`P
z=m}YnTAAyZdWQGke{#L6R5*4#uPL8ij4}@EYVMAvy#IHVXI;~w^|s9JdI|Sjd(|5p
zonGzfTAB7nzIwA9dz**TE7Okp*1eshu9s%&dY#VYZg22!&zE6u<f3=Wt>?HlHSLo-
zzI4a9U6ZZuIMe5vR7ddc_@vj%Qs(Lm_cv47m*w^TY9CW8NnKZtO&RLgj(+Lsn2v3^
zxq0U3=h7YDu_;4$oX0+oPDv{*xvUws=S=LAKYO}f_IBRWqxSJDXT8hUxgz)jxyw1>
zW3gVNtL;f|)>AG0)2lC{G3jc4(~GNXb+b3})p<D{z54ipyiIKdZ&x_hO;dOO$ZLj`
zCt1q%LI3vsE@wX|Kc|j^Bej1w`Rd*QCG}FT%hcb-$-|D%mH3(1D|!+BCmU1nZ~Gc)
zjC4JV`^CnkhWGx@2v#74jOEtImn+h^ms9pUI@c!koP2Q0sPtOa?#RUSV(c2P^>!Ye
z?YfuTVE@Nix*zB_-v9mV)XK32wSS6|33`{TmKW!vR)^bNYm&74PI*v+H{3N%_fcg9
zD^Izm56b0;+SNX}eFvxL(ptc0JPn&GSjl6If0#<0-d!JtTSU3JdqX{&4tLw`KML`=
zYkXqv<K<^}^XC;`VlEA%uhHMwZkAxjv;otJ#!h9v08iq!2hV(JMmh3C0`6_|8{=@=
zaua@rQ5cF8FAv1ZBB2_8G-?=q`u6L8!ifVi1`awY^W+bml6C57rw=~k%nuJa>+FvV
zJ?Eq6n!|>lHzIrFsGQN~j~Sag?t;7vFS>aAC6|6|!etXDO`bA!T7JRw!lL3Cm(MJj
zbw%myIdjXdoHxIG!NNt0ue$o0iX|VftnyXY)cWh{8v@rhHZ=!B;p-yNSj*C7%U4`~
z!^%}Re!|!_tb|E7%t)cJ7v`+`S;~A^o1ZN<GKY)(-d`3QBP{cwJ;lakZGOGjC^ZVf
zj|IR|6`nj78grFRfl+Q0yX?!2tBf+2-E8=s1DkS$G7qkX73LgcfiWBQ^Kd?Vp(BiP
zJkwq-uk+&*PbAQ%JD5nToEO0po9a<#8dOR7R5^v<#&aS3>iYwEs-<s+zo5|wy9m$^
z*9!O|*F|A!vCI{CV$H3<`#hsUd{n@<9cBei-DaO4=CU0JzkGvNYH9Oc-yDt9RQSSS
zE_H4S)%cqH70aUjm>9>^ge3yRA>}h0G@Jt&BE1^MD<?eEE6!a37wP|axyU;@oC0I9
zm3FV(8IVzvlso@<?sy^vDnZwfMUzJ5mw&96QMiygEAVC%{j?@Lv9)c69Z&4YfvtSM
zD1<(2jzP&RG^D&_f2<DA4XV_5Zb&39jL|4z(-?!BWz7(y>R-<L(EU8`G)q1-eRO)A
zsU;UQsPvGw+=F2A0^_Pt?ld{`#aO4{PDU$f1-R!y<ciQq%1@{y@w#Iu1xHW9EqRjq
zA^p>8q#|sLH$J9P$lcG}N#RqiO|o(b!o3;vj2gL^>xtqEQl+qQzRB3rDV@$k_9`=e
z?;!?G;5jhkkQ=syOaXJ~ba9^JB9zeO=H@f6RM=%V$I5+A<}oq!p3G;m@@7lLnLbiX
zUv|9{u4TP@f6{|IovS3ZX<Vo{I~SQae$pS$ovHI}vhrk~qu#0qiREd_(ZupBMBNdY
z8G*FzInH*6dn|aGtvkQ<BIgoOTFPbfMQ3#2+hvvn>{&`UL+(jh<RZ7@tbA4?^~+JC
z<s1uVo8xYQ*y@TDmo|)Tm0xKux)(x6eCJG!mZEdPcQK@w|D?8;pZQiRUxG9jBAudL
zq3^Jg@w!K4pF72N$(gTGN877oPPc5k6Q{e>*#>ow+SK0N*v&AK*ALbq>E}qP92@#}
zFIG2&S;lU@*QFoNciz6dIj?8RjgqPvzW_Mj9lKpOo$Z+|x4K86bost}u_l%aM^np^
z=A5bQ*avCG)Ba=>r~7l=uTQCzi&M5pUtG?zsa0bY=eJgBErICO{<urMCpfcns&(!o
zk*>*Us`=A7?qN^DDbe*9Em3;22Ulo~N@Rqu!*ln?Il7VdNy26x;_XTmFVIEWKN$h=
zEw&c6o-K-zZxGr8wvjBeD1I_>kddJDBs)t7bpq~G(59!;K-LkyNsqqqG!nU`LuCIR
ziYV)H+R8XmXf1k6;TrC+uLjK`(Ad<0hOB=a2Xd?}BWI4mb5xpz?wpA+VRt_I=Q(Ob
z*n$uwOwyZkE@JN-$1^SN_w_hk^OB7BN%I&&HZcy6F#z=zCR)V!v1g)Bkw<*5_u^+7
zcu{LX9RSDt)Ot{J!Dn7#<E{@u@UwgT&3?ACcggaKr$H*(k<LR-l;b0jMrW_>8jQx4
zsM>KMX3KJ|u^D@)V^hvgZ|W1=xgjN`osqIiy*zqjJk@d9j}Lz8I1hGR5v^Issv*o9
zFDW0Vymazrs&Xu`9>jB`$WlX%yO<`nFw_dOXAnZ$LY<{EW@n$yPN%zGJN@h40Bbfw
zW6DKiI0iLJxH3^|<o3lhdYy&g&=p5xzDTSkT;Yq<FRcvwBGEvwUa5<lEs3IM!I&?}
zAKTM<tfq7K3i#FD#FJQ}NVUwerxG4(jC1swEKJg`dwO}wSmq;!zDihW?RB2CZiOvI
zJxZ6HMCG~e6;j72WgJ8s$T<Yg*-_u1>0&_gdVkYaM!BZ760rquxxZc8{d`gL$&o+j
zD40?{HzA#2l@o@q(@qz*GIV2muj2MNH^qZjLP0-fvaCskWc*d@k2c0aYCggrTv~xU
z5D5jF{XrhT5{LzSO@Zruu|O!O!vQV3GS9-+E{b^>ww3mL3;QBVk$b^_%44v-k0Prv
zINl0?N<0(jdZ4X2w#!<2^Ri~zJ1j*o{0YSwW>jfUc=j&!s`hA&vx(HQ>aSam1J7_4
zC<m=S>nr2B4qU|43dghTr1hY?b6%J^V2{TzPB4t^Cs~O&2j>2k`EG~#4wy46`_DMc
zpLLkmJIr@F%%5|ZKkqO<+}95C`wnv^;z3wOKimUxcdvd*e@*7xSW*>=Hr)FyGALrv
zC!orfk|=^7UF{kx{VH27le(#dfW+fUY)7O&%=z7VRc`6@ubg2d_M|u-n&--yiC(tO
z*)ULnH9H9HB=cI2fA#|>f=6U#r=xcV8G}6D^U9~}+o?x9(#s?d#@kV1NROSaO!wq=
zKawhr-sOE$<){(QY^#IN%;|ZkuDm0qqSNbcH|-g(<mr?#LJm^Nv4uRv`<D91+>BE{
zk<J&Z`X)9ye&>9fvrI{iqr(@v>^1FJo=!fsXKRjrdSvVoMfp;aQ5qSTkq>~f<V(t{
zI!GzgSO~i)N}n~@#7KXPnrn^c(o*=UR=mu)2Yn^>7v`d!;%b7$_)p%eps(p_c3V~x
zbnJ6ciXkpACZz0>qaK~k?#e;-2>Gq<5bC{XVl`dda?b5W8s?x3$mdhl7@MmdWkx?o
z)kfA{)^N5rqb;BO(t?*Od#)Uf^L#{(grvN4KxdXU`#`jn_&65l2z&-K1YG4Y$MWsn
zC(`elYV7KqjTA}Fa3pj}AjZaYS0g^IP^baYj(On9P1^Zz*TPR7eryv&H(`Ps?R6fk
z)v~sObkg*+`?*J#&lo4ACwl-qr%=aF`!H&ejN_B7?&7<81%Ufq9gfb2y}mWx<w8b<
zc)Ql$a<6OQToG+3l|+lHWAWlka**4Xfw!xXSGMNt2bqe)I9i~7iKQkQKCW?K`5H#;
z#0p>Dg%y>{LXpObODduj?3gaCiG@N<Q6BRLbEG903pD$ci$3D7BJ7V;#u_4iUu|Wr
zFXmId&5R3X8LR(XXl$HOVr<5}75BrqAHzK(;#X6Kb3&139~N#E&ck}6`XEjYgt;kz
z{wvF%P^G*OspblUMwA;hVa(48m7kuYFZ;RGsI&EmRa4zbV@Z?Q5DGP#z9z2sVW--x
z^97n(B7V~sGwT9PelxovYBmLeFw~Ay4M)fCiJxo?3yLF=P-LRn>~9W5RybmqXjc1b
zwRJV(Z8T#m!hZFlGwg^zH|1n?`W`~>a(V{Mb|u|kOPYWjIoY+N5ng$N-<+<J59_?;
z*<o{;FRJqi&(+Lypgss=1P4Wegwe5POVn>xTGo}|Ez&(_bUR;^pnfj|hjWBcYs^Fm
zvaXbYKkR;O4oX$V`;AIQaxBIXw3KnJT3JI40^i{1lIuLR_Epz$Z&ykcaw5kHl<_n(
z1Uo*~GieRHW2JwNNI1fxl=6zZBR{F6fHKG`%Wx<f4OD|k8~nboi9<RgEn&sPD3MUa
z4ElW$RWf`<<%N{hx)MElV{W5Jt9Dz4)U#dCYy5|G`AwmamR!1AH0|Rl$5zp;2WmoE
zgnl;Vlf51PE?Y+KARzTqdE0RL@?IItIGoxQ&gNEwL*(jyJ*b1^L?yuGtjDy~(ul%A
zO3BWX^ZP~iy4#%gdcam(X7iozw176!6Pa0DP-Yg+oi}emS$WCaIc8CDd2wNRaS`N`
zzYbDcNj{NJIp?9uv-Y!^j~fKZZr1u^{+bx-cB}#RF~|a}p==6RLUdUq6!V+0P`j9u
z5S7l%4Alw0R=3pE`6J^7bs}fpH|ey>J9&D1bvPZjC&?xO`h&Gyr5Tg@zDOt1q3gfR
zkKWQ(*KlvwR3xL8&51E~By)AV9r;Nmc8fhc@|#%ybevu;B6kz>;N@5LS+G|%4<jdz
z-%2rlC^W8UZ>KtXYYzO*Ll2B=(4Ftb%hZnKu``|V?{zGT-EZ<;YKTNP;*_vO1+xn-
zFD~kUpV4cB!jyG{eNa<mRyxwk=M+pL+1RI{Bu3{iZ8>#}(q}QC>aemmD;+k~GYdq`
z?2;CA$zp!=W<!{%=qxvekzzPT;ffmcKmtLF?oEMc%x)c)HLwpImc1L8A<>@P=~I2*
zne4+XMc)vk4c!qZ*>%0r{fTPu2zAD~4r%T$0{34IE}DnYbD837)`%J4?E={A{!Dx*
z>^J(L`DQ<ldVh|Pojb8u^U449h><)h<CppHA2W(nFJOk{&U8|{#U2)SLvnPJY&5FF
zDMFkxR6nyoy;q3;0K(?{!(4=NEzDep&A4Ueg_`wbq1x$_QI$Q)q7FcM(1tNRe)Lfn
zYC#LrUSB$4^G@F<9d!OA9Yu)SsaN3FM-8M%`t7OYOP5+IezV72wAe)W)KN;FojpN&
zB_6zB#L2mRwoKfk5>g{jcErpgjCd!Sle42!&FttPqo}1hOzsU;UyEK()Xbea$T)8X
zSzGnQ&*PBDoM^JnXrpmMc2n&t6Fi~DzHX^B){M4PbJS;MFCUvwH4Ou!W{jcZ--)ln
z2s;vs_tas)b5;7yT4V>qh30S*dU32_MY=a<jaHldzQ*XVK?&u^kyO~24~~@CAC?ET
zm*mgv5{~&OU?2<lKmno#h*4FEOEFXGhinM8G*_dWgppwFMCDJtB=x*J6hpS{VQ)0f
zM+xGt#IEB?Rl^qn=b+43=VZi2{i>{NArIR29MQ0TlMA&5sad(pXvo>#IDKguW9x+6
zuGIYLHVY(B7smsxCP<BogQ1wtmyC_|C^&9#Y>$bHe9gXk1SMT(8DKXAY8pBnW}`ei
z%RBozBB?kNZs$JnJ?}P|8SP#^?J*Bm5y_k+d5Lo$dSoi|JTfNZo;L23(|tVW+9R2r
zWId+NOY=Y!+5zgvcm_ot(wnN@j%nb2G|nZGPI~rUWC>*j)5vcillw)+P{*YASFyFA
zIf|JOei_3({~bTeNf{)0;p~I#VP(3Ra(B*2^Xc%TC8-H&u@&SzZU`7f4y8;PCg);O
z^F18z%7|TbyRAz~49<PF0S5q&SkD<BFH!T8gMn<6O$)~YIfpsfa-Ru25zl4TbA^Qs
zK!z6v^8J-S&cm*=+&>58br+CxviAb%e-p3|a5JzkaEpaoE&GS9=WP}~X5n@q^Rd%<
z-UVbhFImsKE!<<-@3nBBg{?r&$sV+x4_Vk|;b9=tbHsW!D&@I9knv<#&zaV9mW6{Y
z9Adc-wa~P1goQa4j<qn)!tp?+Yl4N7E&F^6i!7W890-5q7FGdC&jujr5(5qf-flhL
z13V4STYy7>JAs%VHx63QnN{*U7D)F};Ca9>@ND4iKohtXcrI`ka3t`s<v!R~Vw{5K
z5kRIt2Z*_NBhRwW2Qs``Ao-^W$n-A<eh9b@$appZ8UItjY~VrQ2;ksqd7ca$gXaby
z{jUX@z|Fwnz@5Mx;9=nTz!5bi#z%npK=N@J@Kj(eko>9nGHlte1=9aUAnElmkm-2|
zc$UMz<~Pkxy1X?XXnxZ4KZN(s!26Yz)jqV1Od`zKi(CU)gB3<m>`fIre0&FHK2$<O
zAD{ysDl6-J(U>+bML#7JvAi*yCjC%Z>GxF!=s&tFP#3G@tcEsUq|D)1<kIo5i=erV
z1Zt?auWZ3rf0Q!U(6&q<RE*0220HxgN~rypQ>Q`}Og13B3}Xs5WDdi9%@XwYFrnZ>
zn&>|len|T<D5zX)KI8r~mKpgack20SKRC-4!5EYAKD--Kfn$Nxl-&sYIPR6WN8+WG
zFq{wfF}QPaUw}Is_f)(z83Bxhc_r?T<E~m-7xO`BItuSrEv<H#Nv%;v75inOIyxIw
zoEB&@p|^?!YRvi;U!+#-Ntj^0n3uA=Kmpjbkm#_j67maK*l~2Z!W}!zeJxEfbi#uA
zHM6EE6vfN~1Fd42LV2sm>h-=AzVr0}lux9udcQsX_RyWq?dg-Gdxuhmbw{xl<i0i#
z4LA8}{9J-$Hv7WNpTEKEBneJGcJ56(8ICYIN`_HY6AG_LLa3^i+L#&f$66vmRUB2t
zGmWZw<>e)I*|nFpRhHJXcYx$)@~RNtPoq&4Y7PcW@<uek60fp}Azbe$xCFOrmN;DT
zZnH0lPF-zh#EbXmNkFE}Sq^bjvMKHIr)izkcUA3*psyM1-oDxly>%#rP3B#@LA!vJ
zY!0^8KH#UFF_K2n?x)klFpmi|>mXcLeU;fuU2V1eF^3N~5p26W0w+}ZmiYqQ$*cX~
zpa{b(=lHD1AFYW5!dAU9r?aXTHu<7ahYQEfIfm1%AQJJd0KF`)GXtoak(!1Tj+fv{
zcWV%4S|hVkDn_h2><fm1E1E+sQ4{6ikA_hN`BLFR3^Z|#7|~!%oQQVZk8vEzBNvNM
z;SW+E7c$Jl67SUegMLW#T#7i#+^RT>Q7mIbD;^R9VZ7N*b;h)5m4!5q8#m6Fv!Jw8
z*<-TVj#tItNRcD18j{bMT8A6b-w>*GIR;yrn$RK{OG5!pXFK9(58hZc%ES$~r63;V
zm4EpS%CCOLQ<bmw+LkEXX?F36qjoj;o6t<DvT4tY7XO?D=Y$4FuTGJf>N_6MSPhGz
zMJ>}Djs%vXI8`A-aVFC&cnY^vV}3<h8`s1dT7r#BQ2K`9U(RpxnZpag)}u{~HyY4z
zz&_d#f_4D&Mv&TgG^qBYp(O}8##vdINmD^^5Y-vVPRuYG=xI!xXca&uf^k2iZT2@c
z1;Wul6b<xPG6Sx$4ofo_@-MIPhgr93!dTDLjPoZ<NhAHLGy;)El|I_lHHCciUmHS(
z{g|J_LIv7a^6P^WEWGeidA=CB0NShm3h=^<-~;Ibb%LQ~LG~L+j|r6+cL6WF6b8%g
z;)}$*j1DmRT4Eu(vBO2~&7lSQ8kLpHE*)<g#)3Il%$d7rj-jciSOEUbrJ;6$Rax<x
z{+ehDxTqyaO(yBcu7L?%5G4oF6w)S|k#2va4%HhjC{HLzXi(w9Fp@X^phucG(MQ2D
zS<KK#Ria|Bk2Lxk!?>Xi$yh~%tcD%qDZ_e=L-)>b-S^P$_eF;Bha$toosWAT?83nH
zxVPdyggY+}Ydu==jC(uoL%3JMu4;dgu^RVA+`Dk^fL+-i;Rp9#++_z4c8V9rN$P^3
zPx}Qkeh!Ov7t6p`;3erLK_+!RCJu%<ZJNo1tZQIzL@t_{=l-~9=J=5p&Hcn^6#9Zn
zSyaR0j;IiC@pEbe0zJ0E45|5jH4x}@T~B=gQlh#d8f#MD@N~SYVyeaZSDw0)hg}gB
z&|fT5`i@4JFTu?-di2RWOQFLMEkl#C7mY{-bmG*+H$W#*t$cGgc?Il5f5O$}T9ZS)
zgubXXVcZiDpWDY|gcL*!_6j=_=@RWu3~K|&V;rF0qaKEO7V2oYPtL&Dt`Igs{6etj
ziZ<^0kbR2IodYJ^>)=jJ5##6TxA>HBoVdLa<<?YUOu)Sw_g>s%n@fxa+?#Ok!)*pj
z&|YF46z+^riBX1oBkqTB@4&qqw;3)m@^Et{O8_GsYSePo+QcAGYngIE6VV%yX4GNj
zf@T-uUv94Z>iB)VCQ!e35#Hr^uCw>_dJyVRovZqt;c$$YemEiU2iLYzJ4el!Gh}M!
z<mxPZS#zvQ)VVH^^t5S}N}ipXJLkJhO=szdf@8?x4eha#(vpu<-X(u?2TaKIzN{_m
z?0v3i4T9ri?eCI1Qj2>z%0Tq?QUXl1{dTf^GcKD)sauy7BoVwVsi{RymZh8?YTs)R
z2KA<_d$~x}3Y9X}$2uheC~ahCvAbj?pInK<{JZOsJ7rwSN}0p8{#-4&+#`LdgyYPi
zrk<oMo@+?ITD3okwe(_D^9<MNXWEV_)o0t0^S#TQwqfK^R<$-E{qCI`&iKjk=xczA
zl!`hY?{Mw1q`Z(l$%#~Uzl%PJi{>gilp-Z8XYpnAoxRRk&zkV0w1sMQK?&wcE3uxh
z05(O?O&8-yTo%AASE~AX-6{!%bXyd!o#&Zxw3D1rJI{8C`=qFsxA!Y`mIpoa=v>F`
zm4EIA)A?q+_KGadATws0t7R24`G7t-Yr&PgyxcT(hN;s*J45MF3nG5bKo*1p(SkYi
zMVCtbDu<N5h=0D)P!%s%eGJ+cqhC3HMHGWN4l<kkQMgeLe;V$~{jq|YSYWAtQ6N|w
zQYt+a2kbEu>Yu^s$Qb+&gkOdQ`{E##Xtj&yLpSE1;rBrY<L5M>(xF;mmO>#Z;g*HM
zEl4=~JJ$P>h>~Dk2;rU#d+QzRoJUCr14j>9>8%l`B)=R>mCNuw@<7yI5G4s{!I;~_
zrbT<29dRy*`Xfc6d6VepV8G1x9P!hS491x@<{JrE1V4_vyE8r87j1<5iMW}!61_>!
zUl_r5J&<}nbg>A;Q5Gf9g<R<1N`y{lY2j>NxV`jbUl_wJEi5T254m1xr>AWTAMgk7
z?dhdk%<oEadl}6}7ZduZ>7nHX9(Ie=Ji)w>og;>ufqPzP0Tgc5W<*es`tpKsxGaPb
z>IxK;Rfy&O2zEIt3eHvod%hp<w_L3;Z;wOyrs~DZ@BD_)vLgRde-jloMFAg{mq$V3
zgfNABpc0%Nf{sr5+oa)qe@vnSW7RZX4t=f<V=uqb^K*_t7;HvMP!(9-#h1eFbliM*
zMpLwa%avht+HuK|^BK8E*|xas5Utp`*SX3HD9Vjw>rNS0_vE6Eqe4k)N<&%kqW7fO
zvM||xRO@U^HAuxIfakt|ElW#`ZMdJpy$koXkh{4C#)U}#^{S^-2+7a(kiDKOutrDQ
zmm92Goy6T-jR7=Dv!c1WhC_3;7ePxzr)1_>K-R=bUjae)82!BCOPPMnn5U_r?!eb1
z8+Yw~H)q}L)*%@;bdL}CHuni}R43yr_K)n;bA7l^`C-NL+K26Yk0U11T2{``JY4PU
zw08$#KJNMwV+ih{xJ}$6aOdD2i#reZ1l;+!XW}l$U4^>=cMSJ(+$(Xf#=REzI^4J8
zUXS}O-1p$V7xzZon{aQzy$$zv-1NT#_b%MKaqq=_5O*7H;|9#};m*Q67`KUgJnlYZ
z6kPc*&%|AZdok`R+zq(HxR>Kzhx;Dfn{hvedl&A#xZ7|a!QFo)!pA)r_fXs;aF4}3
z9`|J2MYv0Gm*cL*y&U&i-1NU5_r16`<KBjQC+<DC58>{=3gO}&j5`N+8SYx#^IL+(
zY_yN%kT;9`wOEtUf_*pvV?H!!aI5uUTOiyO!cUY2_`_BVWkvrH%gFbXCEjg`h_f-v
z7c^%0tBu*d2;_SNxWbr)IA^sq83ir%kf&i|E+z=)gqC6rQ4Re=rmo;S5oG{P@or56
z5bp=51;G1Cwj&I+X%XQ-Elb%PM&AU=Rro=eA({}bwqp40=7QPKZQ-6h`-0lq3s$Ib
zYH^J<XX7$ySb@u!Idfuj^F*E+jqp`3jQcIQ&JXkAcxFNtsU9q!*+Yb!2R8?le~!oX
zdmNpsXsq|`X9*{&#_#kY;Za)Hb`m!CCD`vtJofW^#K6&2#NlTa?3mUW2(2188_%Rq
z0pvK5&x~`Hl{X@3TmY;Ga-Aaki*uEHF(89O=$T@@7wp-PN%-7nDmzFe9*#7$jgFH&
zeH|}%7V0=vQL6a4a*~(C&C!TbwOVPA)iE;O(CMLGfD%Nfiz7g7qtocND?pBUm036&
zcme2Di~ki?{Cwh%JBsPfpV@9hU*dBn#v>CEBlm%Ge<Uxi9?Qi_qxmp*Pu?>39EEcK
zDf|1}*UQ~#buO9PNxKJidmvO%8Lf+9uY`5ngE9C<$Q9gqxEHB%3L+k!xq&`Ds42Vo
zSq{t<>8nT6+!ab0uXhF-#$trQ{m`-ol`D!wGZ8`V$&E7BrL^b1!Uo_n;0hr56mt?P
zHoc!7I%>S7cOc4m)U<54qsN_^L7;`ChGF?tdC>>gw{o;b^xg+ejRSQEdZkxlN}aKB
zyvK_?FZ%(pP7^eUqSxiUw?7-PM=d|%({1B)b($Hb(<ejE0k1N5%)N<z4>e${YqD;O
zd}*gj=UPU#)W?yYx)equw65kuQq<l5qmz%xnB1zzjHR00H0=o+_B|*sS^ng>kXlC_
zKZe$;-?X-uoNMz9X~!Bk%%fk@y?Sl;qiVrT<b3Loo&Bgz>a^+y)>hX?!q!1BTF0Y%
zu6jK?SF)FZ5;Gya=c3PCX;7asA2#yM05j?NKzcVw{QF!P&u<1SR5}-Gf++o1x9xq^
z<W>8u4^4mao!$S{Ws-c<;trejl>9HJ9&o0Cr6qbp%wL0slmp4nfpJS2?y9uU*GT8g
zh-Bf(s!Qjo_Ik&7vNtLrg{V^^7xIJ-Sp`b{WDaH{I5J`0*te$~rk004xr#kbQsjvw
zyaqu>MjG*4VcJkai`>@F?8Vd~cFJ<GOFVZap6=5A$o_t|j^m*@z6|p!G;_VEUbQd#
z8YrtYCoqQjs-&2zdOYb>ryRwIjf@CNz+a}L9nz<6U>?=lJJFM&lUDlb1H+lPsYl_>
z`7|Qu+J@jh0XOwL)YDLxGXQrcZt63Lv?Ef=(v55Xv>U_ayF}^&7;YAB+EJfznsw8D
z7;f5Mf}76;)^nlt%rP<FnP=IvuR;GD2Q&Pua5HZ9v1s3n+r-U&+)&)?FEOpFaWkzq
zS@=mH?bqODIBRk9{X21w#{FN`^Vfh(*CyPI=f82&-y^u0uIF*n{nxnZeiaCKK5z(#
zLi+TS{A7)gT^F|Ww9ja;T@fXCN7qD34e3Y7yWLHXyPsBv6tM@A*i*xN;HNRZ#Ql_Y
z?*Q`NY2CZ5=RMYQtM%MwJ(tWu9S+tRa|-4dL5!<_IrH(yvcYps6n`|+zGO}jjmjPx
zS!M1X-6@f&m6rY>SGO-k9kwZtbr;|;z0Xm4e<Eoq)mXP>9+tBP>~C`JMlMp2>(=da
zyX0gpo?p`hH}1Z%SFKalkjCDwa>g2Es+?&qVT;U(8rR@W%Go6_F+WWRw;6tU9xAma
zS{B8x%x8PUU0KW>Q@%vihtyIb`v;f~>4|Z-1bbz)nT&tEUonQc=^V_xNLqMW62q^7
zJN-!iS#~0r#x(fya;KD~21UZS#6o?pu2=bR*BYrK?ThS7u!=>cFuq*m>o2M1Tr_EH
zVN=V!oLI{AGl!|h!d$27S5BR!#+0VyZ^?O7!%+fbKvDjr9rBOK%geI}l>BWc7j~`u
zFGQ-yi{mZyDrLIsZy|b>sSoK(p0;G#LCQ$cBXYb)PLHq6%y#l{6Z1?u$;m?Ge2)L!
zH91*II(o-D7N$&ejtjuclnk8vq|6~-^DGL^mg_O82_O6>5$hJ~GbNf+`{=!w$Q`qM
ziHZGb?h)k<X!#Zs)6uhXmc26em8jXUrLCM-tnIz)a4PxGdz+YUTc6DN{i)V7rGu<B
z;CCH(jwW}6b7VOV&(3$a|GFA>GCR*FA9|>IR6@>{o$1bZdOn_um=$&PY&kG*q&LgM
zE(b=m06Z`Q6q|q?Qd$R%QSeDFOXNdRQ%0He$<;~Da7j<{s(ZGV`Vx-%hpAsrl#`rz
z%@&Y6!gE*IJJR*B5TnLQD_6{u?CoOz{@CVpxD=y{$9j@q$om%}4(TIsKVvgW)}D9Q
zbL!pWBZjW^c$79AZ*jC|^N{o^w0(EwhdVww_twp`BHQ_;0NQ)Y4wAkn^DXIc*Bm<?
z-l=e}Wzc;H@~QMIv<+nurH<}X>0TWBQ)~r9TCITAf-_ds*{kkwH}e<YYtrjQC?j>8
zY+IbGML^Sz&-umdFuxzjnQ?obvU}y=l(w?Al08_qDJzgtekW6}WeHm~jcW|2I(%FR
z>ayLhgB|s@>@7;KMtVZ2=c&2<%wcz2lt(hUpgg3hqZp3{JtS6}7OCe6i()Lrdh$HU
zDPA4rsr&WKyPPHFbn?aX{3K)4r%H=KO)_;tx{ap>pZvhpUDBhH{+65)N$nNeI7&O|
zYqLkddc&JKAmJ+ZzbF%BWu~(yMyhmI4tdi>=ftLr#Py&2Z=yupKiOH%f49B&(@bcz
zI{K}JMk)U1_J0#}QToRf{Hgq$A$-!Xe|@2YO68~DH~*81UgdrDO`lw|_U2E0dfhFz
z-gf&PpZV<iJ3sgNyS{Mu7w`Gfm%noFhX4BN#;<+-zD?iw=6`Sg*0=B9^1y=+ZT-%7
zzxVL>fAGk*M}PP~k3IgQA8&u+Cr>{0)1N)P<C$lFzVo@~f3fR@7k~NE|NiRNyI=mz
zD|=pj?YDbhf8))4zx(|kTKE6)z`_6f)1MFh<*mQA{q67nIQ;fI|2*>UzuxQihnbUq
zcsZpHGxv7>dprJa)4#J1V<&f4AI9$W{Ch~bV=e*v+|>R{b(fKrV8l=Mv44I0r1sPA
zJEeMR65sg-%^4o@|Fk{~Kd;?oFwTs~GQ>6uW^JOcRC6r;;{B(VTiaKbVVlL&r%w%X
zA?J2e7pcd-v=xodMVOW0ybQ1I^+R=!SL@TM5Af=hb4|B%o|S!f`lL>cdTOrGu}_hS
zpVemnkD6=h92k?NneS3BCYPM`l71+|+vy~$_q@`}-kqId?>y0uo&#XY*zYVv-Z{%d
zO^Vj#aeQTuzNiV;t2L<UqmG7p6+IK<bLsXN?m~nrGu#yz?Q{LVjA^8AYwtg^<FL=`
zkr`RiPR`~@ZJbc=kIDK|u0555uvPw;C+VNcm`m$rq<r)j;W<~~wpoJMo&8#^xzVM~
zaM?E(%}sY=NgVfi&Dm39uTT5!PHgTx$teF=<jE^0(Gieex>wJgd8%-gTH<(6#zpaC
zlD+?3g86WsUxhQ39OfaLZTrcVxd493VV;Be_~|g$TK1efUJmosSPe20=GB(D1m<-x
z7s8hF$oDw>Jm#?9=kTBLE%9Ft|9LR$xJqHx=?q(Dre~dHE`@osWoCM|TV|$npJirx
zj#%bdFc1B<gn2d0<1I7OS!J1-hPy2D<uGrt%%s&*4)Y$EXJE#haUHSDOvBLo#hz))
zx6BN`0_Gy*hUs5vndyI%Wv2ffmYM$d!OXlf{l=COV7a2_P?+VERM5&{F1O5c;C(sF
zT&KgdZGyQNZ!*jsmYMdgmYMPPe?a`qg*nGEGi_y-xd`TUmU#xun=NxO%)2ZzY1L+#
z$qz#wlrU$*Ji#(EZHp~4^R?14lP33CW|qr#%gpr%dn_~Q-~S;Alj{*iSmuQ=&xCnC
zq%hOg05j>#{Kk}@IXG(*aam@Dv({l|+_&SID=bwyV7?rbW87O{CLc51+m!iggbY4#
z_<6};J_Iv)m-I5WV%;{@NHOlgFwa3vA+5(c%;RC!;m>rKD_|}|3P__E%*@*rFt3IA
zYNV3++z9g(SlPmKZgbeb<gh;ob2)x2SJFb~E9*P9IS*!?chX3kKa6)|O%vB1v%Lty
zCee;7?x}l`^=%EFesVqi$a-9^M&i3Ve6F@_LU`InV&+apZNs*{0YAY&JIeZIuKuMv
zB_DOAoO$A!F{Y7wJ&3&G{cuj4yRVrRnZuLbjF&%#!4;A0NqEI4>&KX4y;72SgzQAW
zK;|uTG56!nr<;no2%mZ}H|-PskcP5G*e(GbwyXnSUgO`>rRinQ7^_w4q(tKV$d}C$
z!{q)N(Z(_KME4+e-FT%%zKF(krd*fHK9+EsmtWm0<(C-95uC@8{uxiVW$z|2-WHU)
zS6D(hFaKN>$h9Y0hsa&k@ud~-p2(%{_c=?j9Ob~dIa#SpE_C~eV)lf6c9tm4#ZjeC
zigNw85ASn!g4B_6al6ZmL<4-Vyy(*ppRBR*{=CxR_Tx?m%bTep72LdFz@DoxbnWH7
zX*&nh(MIs>M+$VB6YWS@uBK%^Swpy{Gyc6?*l~Y5?fI2Jt~;ZdI}`ZDMqSJ0yHnRA
zHk~4d$C-IjOy_~?ADLgh*Og@*?}uq(7)w>k6Wv87aDL6pjql3rI`hpdK75X6SVlf@
zuan>7{c&ZP^cA%P77e#^&fF_}+0V`zLOLbJPsw8<1*AD=CzJUjb!D6&<>N&wk*$<$
zl;py@@%f-6TMk-kxs&KF^Tu31=anCp9^YjQlBUEwNhymA@(P3Q_WQC@EIu8aap2g^
z`+ag6xlZODm?FxX_%KKZ;Y-;E6YtLTZfu#ZhcA|c&{V!~qIs0<56}H3-?9~Q)+;T~
zwEQA640n6MZ-|hy$YUZ0bUQ}BHHe)&!ZuXbX&o2Wk8|dlGjj1^u&g=u*M4=on(Js;
znKz!jz!=D1+OL-XTz_P$xS1}dhV_|eH#k#BJDc7-X~3p8YZtjz<a$T#htrL1zvPVc
zqzq=8L&@rHbDVC@cM{tkejAP4V7EOS^^@it&66g~VZEwdTrtb@5S;EJ0q9$5P0x-C
zDdVWm;kSQ8M(bXUdyS2AZ0KIEm1+q3JBm(iOAbmN`|uQ%=OY~~->Jyw_2>h8f9W`#
zRr6hmBXK1?=hfLi)EX1}9CoHv=Ksl){-kN<YKJIt$~wev=yfMNy~a|ntt7ul_^HvA
zdM&QKDMM+q<hZJ}CutfVej+`&o`<!n4(pa=&h-*&U4*t}o=TBE)(VCvS~BiEDux|b
z&X$2w$RFH^;GO^OQ8`_zbT8IKT9I>|H9_i#$P1>?%~>7!j^`UqU)Fl^fj4DwUIyG^
zt~AWS8*Hg(s4{3)yVJNIPS#Ab?7aA~dz5+ql!v!eiZ6#mU-9%W0B4thR>JdK!^gd)
zVwahDcIJSrOZ#VL<o55^KQk*U<D3jHeQzLGQ-M#X`SC3Uo+OB~6n#yV%K|~14`_X%
zO2*mU(<4gzBmHRichhBcdM)Z9`%JZvads=gUXQ&;OV(*f8_%`A`pfHyA&`IA4kYfY
za?3aA8%SSG?^5E5GFg33c^vP?6p18}HP|_-ClT+9A&9$I7;GEm8*Q>q`+P@?I`q-Z
zLTBr(aC|0?C=OTP%MwdbWKB30J5n39*7Go>G9O`6jQfH$<?Q{V+_e>gy>p*JYV?yb
zaE9azW1Nx+seiAWIt=!jWW_KgHEV35E&CMGlVq<-D3w}zIqE0Zq>^G;$=+G)Od->p
z>^tnj1*wEWu3*00`}-1Y*;jCK$+`V9gjeuB_u_Hfz<x2$B9zmic$Q&{WwuW>lwG#^
z{3xj{{7N`a@0x%W`ZRGbkRMMUQ+1MS?4=JQY2c`qEoc*3;jl^r|GeDzp3Frrg@0;P
zcxK^f%&STbkbXSNJ%Z3kQ;q>S{^l%@iSy3$&_>Hnh6xtxvo^eB8b9%h<7ON2SuB3x
z)gN41fk~`NU?36-@*wZZx=5(GGGtX2DL?jHnNm3)L`u$iG9qVDIX5Tk<tx$J@q90R
zbyYsf`u0Xu_xNpb%Ek&%o4b@)N^CLZ$(DzVE16u=JwxxjaM#6!in8(PXPc5NUn$Zy
zic^<^OD(x0^Pc=3n+baI1UinUOyouH&F3sH*O5E(n7D4vE&Da!aV*C18NUK7wS{5v
z+b5(O<p;H{>{*aIS(ijZ!mm-u<xM|(?luSSNZ*8fXxBA9Ik|yy$Ck0)@iWHG<2xTQ
z%2$qc%hQoWVLHxNxuPuR8zKQo_Y#Ce3Q?cLI%d;cR;H5Y;wjx#zIDqDzRmf3&9VAx
zQXK!<aXLBJmLXoL>$J^l3N6E#5TR%t_7a9HmQw|*N4VrR8BftB@k~{&tL7KZZN8s_
zxfAEfd@4BbP<P}hIiLL!o_|688|Ap{L~+x?xo63KNBEgLFvtm94Zz(;qSs=sIEFu3
zUukFV?fs^bcJ_nxiCN;V^Tax6)6@M0cg(FlA?L;NJXrEgN9VtiLezY-XXHHHk$W6?
zb^p9xuhkOzG)0yU<t^Jz)*rndUQ*4`y6kXgeyLS+pB=^Y_2nNfFYM#6?;c;-=b1Ts
z!)~5(y0BNrmXz9KxtNxQXXWhWFt8t<mjn9)R|8J~t_O0T_&vY@z>PrmGByJT0=ELW
z_j()fB;a;nCU6Ikd#QH;KLp$jJO#KHm<4PFa*y>P;Az0az|(=o&vCXBAOm;?Fbl{%
z+(UreyKVx{0_FhE2Ic`j0-ONkp74C&Il!5~j{?hp{07frpb4x34g)p-hXXl3c^)u~
z=Mli=z--`Z;7H&);3(jFAf@X)K<)wG2pj|43>*vG3d{v=16}~!4!jh&1NbrEE+EHb
zyMdPh_X2q)dn<4n@DMN`co<j!G<I^17IXj>0keRde;oq69B2YdfH^>}FUSL40h|Dw
z1I!1`1<nL=Tv!HV4`nfM5wHr#IqwD_IU)@F1aRjXoB;*~SdQnuz_q}B!1ciXK%QxL
z0`Oiup9tIx8~}V6m;u}l90=r@Tqgl{;yDwz8+bBsAMiuKL%>sjM}S$tjOV})K%Sp>
z8j$Dboemrf`@ujHcm{AR@J!$Y;1FOD@GM{%@N8fO@FTzm;80);cn)wi@T0)nf#(A6
z0h+)~z+u3xz~R8hfad{s07n2{0%imE0!IQ50!IN414je<KM#HYW&y_lhXTg}bAY+P
zeBcGZQs70v#lZ2vTHqzXFz`~~O5n$U>wpu0cL6U0ZUjyQZUIgLZUasQJ_Vcx+y%@B
z?g176TY-hZHeeAj^A}jV02~6G0UQCm9GC|z0Zs<a0?q_p0W1fW0;_;?fK9-;z~#U)
z;9B53;CkRf;Jv^_z|Fv`f!lz7;0|CTa5u0C*b2M}*aqxF0kRAH1mszX1Av)$9ta!)
z90VKz%mn5Evw)L<rvqmK2LsE2X9BB$X9Jsn=K$9N#{$;_CjmDDrve`a76P{e8-crl
zeITe>f&GDPzyTCoFCZPjOyD5k5MU;71n_KN9&i$HCa@7$4(tPgRtxM83<C!MR{{qD
z*8v9s?*e85Hv-QFZUIgLZUgp#z}o@r4}1wY0Js-85O@$c2zVHn3GDwO-Uns@CjoPS
zeIOVo00#n#fP;W#z)WBT@N8fMa1wAeunz>~df-6dy}&`h&A_vP4+AFwcLMvE;49!j
zU@LGCu#N6O<CkzBfph=|0*3+z0ds(pfaB?&gY?iHSVnhX1?|ToJ+ueLXb)UX`#jW7
z+5_*QJ#Z84$D@AI9{3pTfjekF0rcWCa4(-HgI;_F9_DjC==Bnwfmy^Nq?0%k=_HmS
zoy0QKQ(*s<sHecQffYcGFL>!M+*2>bOP}K@E6v#Vmzfl<4&cSUH81uJ1Z93v&$zIE
z!;3ROyx5Wp${Zm3(Y)BB=fyP+yf`n!i*s~>^32sEytrbK7e_vV5?+H9kIZ6o9_l*f
z9!39!7j-9sk{<Rod2!^xi+wR(oO9sC@hC6O;tI+$wYI!C`r_39y$vrPD8|c=UM#O>
zYXrtQFkX$;d)%GPi>qjO@mzCWjh6pLD?H9i@@lcdjalj8Tq`eXb$D?WQc%**(}{RB
zx6?!1d2$9Xu4UmxIyVA&9y=*PoegtJe#o`fYmp~%v0jU9G5I1FI)M4g%sy+OYFo(<
zxoExFE|Vu{E{2(Wk&8Fy!AxGrMa#~%ocusD?a33luq{>Q7MN$Mb(7=`+A}Wl2hHU$
zlP7Z3DlnR>m3c1g$s4)o0Wci$2h+^($s@Ti(GO>iX<h&`d4+M&5BY`pW%|i8x#*cN
z9P$nAnHQPO<k?&_^WAdwE_sOY@?G)~(~0Vbm>A{))yE-UF+Eqop1j2{NeA*5>B;cP
zW4VZxeHWggLNoJAUSpU{C;2TGKG^Re&oP}`|3|)~`D*-gej;X-Gx<=L7kM!kzL`$C
z=c<)%Xzvh`HgnEgo5{1<Oul6~GM#d=zzjuC@-NfI^faq9&sJ$>-<xGbn#-B}vsK>7
z-#iPL{W0=5&EzZcIn4~8yiU5s=Y_nl%dT3bU*ct5&}m?O&}P;N+blfBbh2(}`({-Z
zI{hq1F>}UWn^|W_H@;h=(#%zUQin8cr5@=wm><?BmNH9R*DHp?(lwOkl)0R)C`3Lc
zuXE)g=|!4yHKVSFCB~I7OTFT1M)D2QB<Y~6Wyp(RFZF7=qNCIq@h^2o?D@46T{cor
zxRRA=mK2x4)yYFr2c+IQ`K(aoQRIk}x6~6U@9BzO&a!m+r{<XXFIGK&ozG&$3)1Fr
zWv9+_fl8m`xj@xj$+O5I$#bEioih*4_#}Oj2OW2rqLPlgRF#y(Jzu3m=v`{XN190-
z68Gg+-6YL~#v)IqTj^*<Tc)Y3<0w*PDsk{kKApc(OBP7Eu-qjM?s(8;D(T=iRme33
z_;;6)#3v=7<D<@2^9tAX>Tt`Hz0hs8DgmLJcetzxQj>MK<*IC@JcMT@y+tZd&am8N
zK>fCsraG*-;9Q-?S(cf3l=BMtePcdJ$?12lvhpHj!n&yGMVj&*y13twnkZ?WuF65)
z5iXGSZk9^F_~EKv9d3at2k|3o^mX1jzLao;lf};!YTPM)%B=dzToj_rbRG&E<*`8V
zp1eEV;lIpbf2CEHQvS@R#LJb-+AQm+#a`C6>pYT=?7kdxCiPtz@W-(*>BuqsSm3%>
zN>tB@Iul-Z;dwW3Bk(uCEx_*pw*fZ-p8|dsxC{6T;2z-r0$YJE0^5M!0vdZtj7I^P
zz^8yifO~)=fYbrx0e1o?1Ah#h3ETms&S5mL9M4|?HUS%fVb~7?uElc=pOM}^!1Z`$
z8+<PipGPw`10Mk{hkIY(c098_tjBYI;7&ZV9oh~2H1HnSp8(v4XUbdZf~Xrhgy*jV
zj{xrkX1pr8iNV0{;n@V<52TKPb#E-5Zv#??Gypgm&(vXT#d8L5CZ6vDmII#yRspvF
zn}E*%mjgcsTnqdma6Ry+z<YrY12+SI1$-E|3%DIfxw#X#9k?6#OW-!dHxRfF&o2NE
z0bd0k0sb18@mh)TEO0RJ`#=-;1aK_yCEx_$CSVcp0bm*Mx4;VE=Yb8ty}%goe}Joj
z&jW7<z7D(x_zG|n@HOC8;LE_rfIkCL2X!8B2cG>v>XxW`dI`@>z<cmK61W%74M6JN
z1_2M^xfDoU(>UN^JV$}l$(;o3|680L56l9712`1;ATS3=xicR417JSzF(7qD)K!(@
zc^#0tr;pJd&(s<1Lb#d0T0FBqK;6~_z%ZU;z&tz;0j|XJL%?-F%JbcL?_}Uzc%BQS
zE-eSR5zp5G8}NKCa0{M&K<W-Z1l)#a4B3<p@f6@wc>V%#7m$5|L-3ac+=FM<@m&Zf
z7ubsD2;K2~A+Qb4%YhS+pNT+YZwdC@gI;+5R3LR^(}0<<zXdoHIG^r#{~}-xo>u_Z
z<2f5R9?$i_b$A{D%*S&buoU<iAa#OcfQ#|m46FsN0hS@2DZntEKLyOk^CaL(Jg)_|
z;=MfJIy`Rx-UVC++z4y|ZUHU;8t``-U>lzA20jHW2kruX5tsq@(}8>Nd<Sp{;<*&q
zisu`FS#Tc=Y{T<Hy5so_pz*rs3^RfE&>na@FbDWm-~`}ipb7tH0%ziRG2QX}VPH9)
z+2f-wax$<A&o={`fd36#4qOUc3%nON0q>m!T#x5#=#J;%z<cpr3)~F+5pWyuN#G9P
zR^V>nHef68=fK0jr-Au+|7>8!8zs=@%h>)+;9xxe1UMG>IIsx#O}YcW1e}TYJ_3y4
z`OCo7z$HKf`M4NxJD#rxQiqxkya&&>0(0;@0k|2@tATlVz6|&<o^Jw{A>5(B?Rfq;
za3?SbTnzhjfV=Tr3CzNKmjL(Sc_om#Y7=+}&(**x`2Q&I2%f8e8Sp=z_-2VZ<J1J+
zfai_yHwrib&jDZ&Fa#_E_5)S{-vEYz>wznQUjwcKeiwKb@Y}$Rz!|_Tz%Wq8Li|#m
zZohp>PDz_xtz?pzYZaZu%$51te?YaTVt=hllb9P7e~Y<E<yD(kw7<)KlMaV#gS7cN
zhrM2-%>F1xAKH(M1SL$KNk)72yyd^f(T8{1H^E(xA!Y1Zt-=&tfM|(i48}Pm>P^@$
z;j9a1vFvw6U%+07=#IDsnS8`}b3q-Jt>_MFReLUdZoaSk##~FJ&2-gf&i2}7$_CM0
z@EdWgVeAueoXyqNG_yy@m3G=(t<oX(qV3XVrb*0_J~4A$h_=60m4VpHs%tTaRa(U?
zni?_7N^&s^4{0-HoAl9GLfXvT5!zg%+CTBbnRnaX_Ro1bZO@fNwwZL7ck2~R#oVCE
zOw7%yT@W+ZPHX?7VG?_;+PCfPc)8L_+lz)x{I@vlId4cm9J_N}4b2>*)2G&La0LU+
z9QTUGP;?BUC6jTAXy(K$<)zK!4>9v!o4FrIo0}C)sPoeCik?7tSM*O@heVwU)1d8H
zm&nt!r&+X%{9*{r3}19GTsfh2KcYz#-IZuJWgISiEN1?Tt}_>{Kjn+)SGby#X6i^9
z6@QAZLeisk4Dv*O)N3`WJc}-+QOO(89r2%fB<hqzdntMa;aAZG@t^tz(nUg*k&|c%
zsXMgorGB%n%ZRL5m9gl2_^)+wTzjH*bW&!bdk{^o=pM8mhAH(ybU2a*(c_7xSM(Fy
zB>|bOc!>YD{zPhu{Vd#XKMUt-9iV87MF%LmP(;ro@rsT>_)pA|PBHVJV<wi3XqQEg
z$CXnu=A`VCH|%G5OP;9@aJuu^=}rkHv5S9F$9|?xl5_NQ(|k#3N<9;8-S$oyEdIGm
z#>>ChyZw`AG#zNxd8dw!YwZ}9=(nV$p+1qh7dmo9fo-O4QMB%&bCmKH{VD(XE@gw1
zhv-bXvYL88<}<8#RJ29%@65B)-kAr{lP*<qPV}1+uZ)3N7b$)8n3&JxD*KsyE`A$S
z{9@*bbJ{+t>YCW|R7ToUE=WAhiWcdvOXQju$~dmO;Q0eQ^|lr%<SH*&rPbNm4EH{h
zBD~2j71--IN-^5z2)P_CrH<J23Uy>hU9vjcxlW9$Fuhl`%gQm*(kn!|I@igLR^caG
zYiE6b&N^GMsixT%meV+_lQ;%nh;Nr~pJC+VULc=+H|3-A{Bk7vwQx6|5cg_dt;>xO
zcfWk}Iw#6__E&f|qrD=f5+!EaQy$J!@~a%aD3kPwHF+?}i64nRWPPIku17IKn1@p1
z>BZemKXWhZ*PP!oah?pXzuPb$X^kOX`>PQ04GPKtUUe8n%dQxG!l(X{NfGo(m!ogb
z?~jyW%*(ZrT!lGT%?z3CXOB2TkX5hT=Oek+Vd%Fi(I@A4zZg_oi95MJ&OS}YNb&Mc
zeJ%n;i=eNQ9VBw9NS?}DavID4{aBZ{W{fA(a20Ff7cL5vJKOpYI7C(h2a$S8N&V#`
z?$(m$*|4*}m%`fO{8Gn-7!|X|;H#qevYT1h;0xCH&4MVtTgtDDnlpU(Bx>zMlV3(P
z;cs#s4fgkS#+s#pAY7<3;l=fI?sMX~b8G?Zxf-nFv>eTEhEx_tVnx;U^ZemZBsS5M
zFQS^UP{?cw1?$aF#4MR>7Dpl>HXKRwks3{z;~6L$`;2j(U_TssJC+0KpwAXC!ROpn
z!7}HHJo+*%?94a6MkKP%F0DGNwD6sf_7W7kVUn%(@}XoA&XJvcsqjkjl9Y5f>6T9T
z!_g-3^mT@Iau1}J;RUVmvZFcKwWH06X127?-h4V&wL!hdrOE0~D(OmIj-;oYlx(7X
z;)t4(Lt0?rfsvp)<uRoL!|{smBIW9o9m#w$6z)%850-n0xg%yYdNAA{sW~OF{ZAHJ
zV!S=~bs_iqZuT%ZTDHHj#1m^-Gu+=R()Erks%3eil<vw`j?znq#GkyKSftV??ZmR4
zY9~;h)E034vWXT-)-v<7Uei;)&4`n4x`i{5w#jNNK-p)a-Z{T~HI-RY{H7(YiD$Mk
z-h7i<`_glKlkBTh$<n8D(XnJ<4M=P^nCi~j0%yySihoDjfm+&Gn*_3Vnu1~UgiDuC
zI`W_S_by2-HM$o*DPy-V(#CWry%L^oVGQdVk2%0v$T?}pv(dJ*#nJKTGYu&nz2$6t
z4~?<(jFj=>+Vs=K^n3F)OH0CKJ0mTQ?xo5Jl+?9Ej$v!lm3B3;z3D0Xrzhp5wMn7>
z8eHmY3e=i44fqay4R#(!%|OuV=q4+V_;%mt+49G8WJjFaS-ao8@iBWY)W&lk5Whe`
zeFmkMbA0Tyckfu^*x9`=h3&W7f1(dcweF6KnNB^fXY0vb*ld@b>2})pWPHm|(-@bN
zO3b%y??snk@WC-W*X2$}>s*H)M=m0tYtg%tU0*^SL!FOHy#i~y-chVI5Mn1f8h+!F
zCC1)EynmrH-%s?*9haObVm_kqLCM11UfhH23`xJK`<^;|KIp4uq-F1Qw8LWvQxJ}R
zD}>xpTfme%bFXu4w@0FnVIPKR(IJwnxKD^<tay%MxL%aiVY9Z8U$mZ1;*xwx8F-)Y
z8egW=2unEB#XH}pES8=*zg=u%9$xEML_Z<rz;vgpXOteI{e3{vgEF7Bm6G4d_s%_g
z@|`j9Q-{=(ep1q6$24)~Gd@3zPoE>;{EAg){unBID)GA<HGLR6cR1#t#JG={^@w8v
z=ePIVF6@a>qayp=<wTe;a?iXZD>s#)eJ7RoRfepZ+>bxqc!Dw;`G5Ss*o<BGj{RyT
zpM8IO^!^`js(A7*qiZ<FjhV^szdQbfr(XPY-RIsuV^UL*vNN(?Uhlta?DXni_bDF!
z<qwY>HJ9rP^80>az!SGD95M92-}z~M^N#4A<_8W$`tXG(p06GC^_pjgZ2EKd4KF+w
z{_}4e&z<_m4V9eK#<Y3xUr#=FZRTTj7oB_AxPE<$ug*UF;&lsW{p88t48Yv_XUA>M
zDE#iXSDroWGx^Wo`qz`5e`@WhlMbwW@~-R$N>0Pu`DefSoAR&j{ITz<J@?;V@pNX<
z34g0U^RXA^J@m*wN8j<;s=LltaSY46^?yFR=`#;4{MJ`5Kk?G<Ua@3v<(}1pzWuL5
z`7eKF^RCrrH=c)y$Jz;{7v25zqBZ|JebzqT@Nd05C2R8Ik-z@#&e$1OZ9n;&=NxQ$
z`TVS3{vP3F-TcvOd~<_=^KTe3^o_FqW5&OF!JkHz)qLr?XTEvn{#l>N8JF?lP_X3e
z;8~=0{zW76ALw5e`RLpK`@&tL|L3`D>h2yl>FckoddI(I{%gy=@^y3T{I`Gnv-`8}
zx?=X5{f(P)pZsUruHo~_a!z^VuWy~c==8zU_pDlS*{{BI)>VgxPWYVhtHIy<)T7J3
zalP+fkDPX`?<7#~)N}5re{!LD?p+gayL8}JG6Lbpf8<|k9(ZcxS2ncPpAj5*#)dI(
zU3A^)SI+#=^I!j6@w`uPg+<o?EWhg?eYeLxa=WqQ(AJipz4EQWkG}lIZzHGpORvaT
zcIMu{H~-|$!YhCA%oj#2xc`k`jr#rOd%yXeDI{e6tX&7&4y`-y6F+Spv^doN$AwQW
z$vr$X<J3P5y=vn-IfvSwoA!-yXKlRhSC4(VD6pze@a?P(3(sEBvgxx}oATX9C%3Ho
z<mb<v_FUt{hi`f9)Blw*qj+{h<~Lt?_s-9c`0eQj8}ddKJ^ZCV72NcLC!g)R_%ByB
zy!`d-rK|3^ZVou8_Mg9BbM;%NJh14lQ@_93sQdnC^A|7v^w+DJr+s7S>_?t^Exh43
zQwq*}WX`j@uDj>-eZO8mF@NqG)9!yev~2ds-#;{nT$Xj=g8K))xH$8hKOgB^_~|u6
zuYIEJ(=AI|i^l%q@{I-mbwb87Q&0Ti#?~Fb_``zj@4WuqqCS7#dZRfanjLxJrnk54
zd+>xa2IN;yx_<7GP0wFk@W$Nc=2M2fb@9UAEj;~+>@WWMK+f6&cmHzPq>_(5n0xN!
z=7b0Ce&P9dZhhss*XDd`d&7dSEeU-0mdU4$xUP6r7DhNjN6q?haM6R+2fuyG@ISx$
z&#(Vr-=AOq@LP}9UA%hT!ylVEcH58dd~M5F8MSRM&AIlyOFne%!ur9FzLNj!r1O_I
zeC49Xmw)=u-yRFpjzoU;wN<YE=R+?n_`l8Otgjqi^u_xJ{p-O#H+*yKtiTt3{L#@v
zpL+V+FaGcDrB7e_Lgs?se183gr@y@U=T~G8S$gQ?f$KK^BbIgU#3QH9{M`eesktia
z4?q86Yv9)-r$+WY{HbrRzh?Ml7vI}5;QA}>+<$rQvbTd@{zLvrXFhfKbD3F(D&IP_
z>B;Qrx4r$$hC5G+KD6?^6K>8e+!|;ZlRI|pqHkvX`P^Mb{`F7)u6kSRwd;0g{qCOU
zcKmd~Em;eGaMiAte)P}97k+YEzq5)<`(5_T?6bBQKRx%2?WHTew)&Y#FXVn_|KZ`y
zAOG?#6K>dj){5sNOMkZftB?L}#hiY3?Ng$|Fuu0`rHZD|s(oMi!^@N2{#vMd*_GpO
z`&sK%V_sYQ+T>p>es9L`GgdCzd{xUIM$WHa_TidGet)2H(7SI2E^EE`l8q;9{`8|4
z{=M*&bBDcBc=hhP|Mrplzkb%VhW;R6?Y~z2=z{*wT(R~4{`UHB=6vn5(N_lUyZ29X
z>rejb8Q=QV_rL%558XW>dgo6{4($Bmn946qn{dkCzjvoO_+!go`0ex;o_KBe)H4?S
z_MuxVfA_a#w>|rZ`>vUHLBA<;|1e$Yr?Xydn>Vm{$?MY}esJ9Q@7))=@40Eg>vJCd
z$Fe7`*tO%u`n`uYKUhEMnFqeNa7WWg8#a8wcw*)?Q*QmythP&Eo;SPomFs>wZ0Oqq
zZz`U3?e1^?dS&VB8TWqUD=o&l$@{oI3)Sy)FJ=9u|BoWILo%PZ^wa;mfBE3i4_$fW
zvM(OUJ|k~T=}8~z_q9or|CRH@BkPteF8r@;oAynK{^YG0EAOd}efE@LXT9>^5AGZH
z-N9wwzT^JO{y2U7-Cz9HZ-3k8U%&k8i>v#t*!VGo-sda#mi^^{Jx`B)V9Niq_a5L`
z6ye(NriV}xLhqqSFWY+w5FjAES4kiNB7wvZdJBkvG=p@cgd(8QR7&Wf7b&4gSE3X_
zIs$?s{P*nUC2t}q=hJik^L^*+bxkI-vpYNWDfjctyt33}U%&L8eSY>`@kxs(54`p)
z{-I@xT0ZE^XZ=11+k7tgm{-wp@t>#{TV8MZ)zzlI7xAmLtjYEt&U_Kj>~^<FLvL+5
zS~j%DDeC<~i>~#*eE30?T4P3$>R%}`FzWY5C*Ly$q}-@gaCnc#54oE6Q-7I~H?Tm=
z^v3;G1Xhd)E#RRCjDPQN*&3fpcMqPQu#VYMr*`9~r(=C49!T}@`El6oSuOWO?(X*a
z+4JMR|CvjT>~(MYwz-E3y!-9W$u;Z=6I9^3IAq^~Duo{gSPg$Uw(Qe^OUiFwI=a*1
z!?hBEgppzMx2G1^wW2B8_~0sT!Pd>sR}NsyHm=DYDPXRf`aE7d*LlkavkKPvqxj+a
zPrj3{ofzjAQ{=d3@#pu~o2$Rrv^(yOf646*6Ak@*SLmp71D{kk&iwG+>{>s4o2z?^
zgzt*2SW~}a)ze2WdRBe@UHzkzD-@`->O}dC#kP3wsdm_R<Dr{hHn{k9uK9;NFYcYv
z;u@3GcK4JO?Q8LMN_$T%cy-6~0?%If1P<=r^AGXc9s`>Hu&J9b`Ym#8&*A|dC(?fK
zN!R)XU$AN}T=L`muOffE*uCmj?~2nu`8Gas=3AF{ZR(%9VA<-W%0#?dAa${J;=_K!
z??+rZb7)_+OEJFExYP=_eW&%f*|%Y_xC@h~^&g%1jySjPUS?ymxVKK_15*aCuJC<6
zGDuOicg`LE?VRd$&lUeEX>m>Cac^UA!_jp=`)P2aYk!oR8-F_E?y*BYXO>Rh7E484
z{`z9mPy70>ShS$tM~MeoPkGjEU*h3YyHo4*?S8J^;ZEy?8_x^GMz+{f{KDoL>*qJU
zzo_|7PcObVvb$fkg|)t)Uygi_3i@!{J9=Ab;AMHqH%7AsCq`9Y@axjV{ZDt#`l;l*
z@|CVD=S}>@@3&jyzg@Yrqj~i3nh)ZwGV@RNsc}6|(cwknrpLVVL-i?9;mV>J`7;9f
z_Ii<Z(;tUd+Sab(u$t#5_D@Mp(h6+2P$N0~Sf3HzS1QbDZhzAgL+Azh$2%A0;hmTA
z@Cl|oe2Y?^zNINozqcq){~DB+zd(8AGAS=?L-Y=4NqOh)f*q(aluw@iluzE#luy27
z$|rCk<r}z~@(tQf`Q|@H`Q^``{DL1)eg%9y{0kKI@Gn%u!@qD{k6eX2c;qS)?~$wM
zc#nXhDINjEHhBaTKj{%r;*Lk|61hBcmwd}JcPT<Yq7bfwV+FwxFlDR<6<Q~dN}368
z&L1B6P>1Gf<jjyT$cV&8fJl%8C3Uox5MU)ldy2yoM7}550l|e_zdrcp`W}&h$@w5e
z;w6~9bJES9wG5&|5s5V`hxh;y$(wjJz4`Zuj|cf)_H#;d%J<#TA|ipiYqUfk$u8Ry
z8Q6L1Rd@_(jq7*3NguhV-A`#EdF3EuJGh8TV{!BYcYgx+_y4{;243RC^SVCD4au}p
zFy+awtUK4gQGN@QPfkX0*$<fVEy&Ne+t<HQeycx~Pks^p-z%T=PgsurAvy=~A|<#A
znf1gs!KJ@D+N%55xilyE_o5u4u{oz}ka<ird!oye8SeZ-Xo#(|JHOJYA%|$QJ%Kb3
z-v)QPsrwl`WDi!HT^HgBNpvoPGPvt#<kUm563EIR-z4@Pmpztf{LYz)F?cE#Pmp|a
zk>CGuFan~#I!FR(rwfsAVI8l_b>8LdvdEu*hJ*ci{c+IZiCx*jTeI}*?(niE`aS7|
z%4kJ@`+p}T;eYbW=dZ4_W2=j|F%U94|5AJXm)k>d7pFA@N6u;u@jJ{yMjU*G%rD~6
zMN)tN8`FRN4r`AOIScl6t##ffRFU+xgK~ETO(j0T&b)Glm>>pDuf6K`WL&ewg)=n7
zTy2N)oD&<f&=`UvxPD8=Ro<(9bLa2MbMOj+B$1xYS$l$~kyYoc2Is^c(u&vB&Y8=E
zz7jMf>$eKXJI-C_)GSvY5<cMKQ_lCvj3Zy{310`*rn_~4JU6lTSl5F;Pd!qUef_g_
zLPmhBeS#Mg42tkv2MKeZQ{+R09+4V3D~q&>yz8PNWN%F!j0N#sBqL46!l63kDbi-*
zJ?ES~?ASJ(mG$Rb*ZDzNep(K`_h$ZTICjtRTqDPIz5MMcQvZL}PwuO#Ge(7stouFE
zGlauOW?PHd`TL(wrEQq`R&CVJ=?T)mSr)LWNI4dF=hu(ixqsHzU1&1#Gw)?fPwsi{
zxF+H9?s){2C3B3t=Zr_z3C;hkzjD&wLHI`Y-XTw9owe%Z55gRDyifiuT$0REV&fqD
zK^!hdFxL?5xN=Zkf<`)Rc6b26xC!?nYhn=ocRU2$@3{Dsh%w9Fe}rea_qID<C;Kj5
z)m~Bt@rZR%g6zNF_0Q+6Gpig*Le3Z?)(V2<l3#<#TH(aj;hsZg6uA=qrfxak`_HMb
z^9u>tYwTe8q|RBnPOV*a%DPYH60tRqaep;$a5#u_N_Q4-vAf_O(hbu8QRq!_)?8=o
zLn0^e6V8~`_gVLd4bt&8Cackf(mV4e{xx-X(G6#WU){d{vv!ajKg8RftlO;fLUVGb
z&gdV)FUix{<q($~;N&=C<H#X|8#t2Zt471At^GGC2*R_6b0Y~ttxX-WI3tlbUthvM
zqhGIDH_nVAHlwW3%Q+88E;-fJSwDoDW!0BZm{-@AjIql)<IoqPNjP4+we4Mwul^3{
znt!vMPHkV;&YZbf?IiUe^Tgrr?LajMt#z%W>@>|qQ?s5YKJxW#8G)=&M;gr1|4G^8
z`p-R&F&cFyXNr>5>YRK@Jhq6W;-C~+BmP&kn$+{3jR%<t#0!FGRpfkL*LrhF(pmLz
ztuNA#E-9OgNKQ$+GFsu}yZZLk<KdE1iA?f$l6F>!ubR)U5q@2XS+e%4+CV5-PC471
ztG2?35Uj|hZRT7l*`;pRQ?ITI8Lz)?%fCII&Pb3kb4J#EJags|D)OrF{EzB6b=-7t
zSKt3xYkE^H%)K<1&pwgRU3@pIZGW#bxtB$1mVNBV=={_EC(>?~UkOQN_l6<$&hnCZ
zRgM2f@938ph4X>2Lnb=1k9|DwKU@Fq^>y&iXz<{yS&~zZ%zB3O)vL~ACK{RJLF#aH
zqGuB9hKv*OC9iH<<NwWmcC<b6o4-VtiATL0?S)9yIpuoSx^%76oU7UW-R!<fq`l-z
zE}bYRruKIwzuCKQVOA2p?V9Q6r<lII@uL;dv7K?$d%w>8$${_W{P&mprpS5Gm<>@c
z&nN$ne2L&0S>GaU%zoV?M@8VeXK~)nf3Da`W&M2t|ASXtNm=)jn&JPhFL052|7_km
zoYRFPIQsFQafH9=J7+C*g$|Ej0&$(S{m<*=LQ)+5PEK6@vj#-wnY(;Lv<;U&k@LRO
zgWWN^d%?fkCAl&7xMl4s%bCyG`9x-Qw2hqk&in4aqMp5c=Y1EN|4+v&3k4wi99=pF
z@$DxoDobX~j%WPM_+{=H>>k%AJ~AOX+pa+(zd0on{+@*=zgi-8Nf57o$6c?^(v$w#
zJjp3{5nk*dn1oMfQL^m#Dv@`co+Paz_>T+W>W{aG)<<+AGLQZlCj0MyhtM=<9=g}<
z|Li-i-(h!lBa;2(Wc|D782NReuJDR%4H=)DS3+>#SI>mMl0aVlPWGALqMO+<;a7j_
zRdTC?GiD!oLKR*m6%f6ftbAhoBW-<Ed4#4oGF{e8dR=M%o%`iKz8XnSzN+N}+anYv
z3l(?q{l6byLUjoSPR_$4v#A2P;daHw^<=WBBSjIu_Tok0%h-N2?SjKU5eGdX`5)DB
z#mG;>jgc?oK?|D~2s>%D|2nt~bGMA`Kt{?SZ@FLOUe=YxpR?|{|3}w#Qm*)(&3nPm
zM|#*9S@F}Ov-TDIPzW_fRf)<q%|ETp7~$QdgKwps5N2NVeD|64>ztw^7JgAURQPh>
z#Ro$k?C`H$b4Touj!yete)1k^4=&etGBVR4_FcC>NoYRul3w7%AjD~i?JMcfgNE-R
z+>fZUI4{EF4!=CvRi^K!9+~kd^gHG1`{+TC_u>Xpk^N%GR&Xk^dz=mD_IoeE+2rq(
ziNE(OiyV6N=PSt`0dgOsadG*XO&|1l@5{WQ&Vw&r<PH5*tea<cvBxw1u$+4tmKXV~
z>%uYDboFp5zE(Jugb-09+?C_RX)j&~yLy#fd_M5t3(NK2^UShbqvs#$@9pnT0-PqC
zkXgz-Yow>^Ei=@a2Y1n5<O*^kYId6Q&+Jeqc8!6Pdi~!k0V}+QStWjLQA74IG2g!5
zFu&bI%ZL8`d9L2F0Y{4OSI1AcO8qc3&!A@t^35qV&(F1r$M;=uyo6v-X&rt&yDG(6
zL{Yg~R4sx0?)!fIZHZ+)8g;*$=#Tun9ZDBjZe3`7%qqUEF!J|%CYzsIV^5|ZXm_Hl
zL51$F!Lh5XGGXVQTo{7)Q%=X{ue{b8(0onhiN7EnasO7Cd0$$m+O#TdWuSg((SMXE
z^tCmk=Opi>A0_1PO{z3)o%PG7-Hxo>Qw#OI@lHRV4c5Zpi^?C{T?FMdnmn-gMr%ml
zl;G=LCGq~1rnyh2TB92`J$#iydqOLeTgPp-gmyjo`1>N>U*3Adj4jswrUNRxldp<F
zW!&(r`14lln{R54u5$dQPNl@|Tvunib)(7TUjnbbh3~)nrO)IY*7AWH7k@gXDu8@_
z?<alIta`uwaA)!;mh|UJGw)7o^}YAMsW+jtL8T`avQl?ir(R6EUo5u=(#?FHx7cN+
z4XhlRYvpsD%6M3k{&kmCyL<7x`ybH;)qHSZ{Pf*cR6_B=)(y~uly$8VtL(A(x3})i
zb(HkS^WQ2Q+GDlob*)a_keUWX=L+uMZLd|M$md_*x`g+s$Hj|3*lQJtG;5T&YayLn
zc=6<YR{ETo&#F(qt%C!^wh!5F9cdlfZAFNI@0ENpW8HphFE_PUbq};J<!Fz^)&Xl_
z`Eg@+?h7%fdu{XNJAA;plyYp*y36RV^q=lt>TuAyn(<<YXGjIq=R|`tHx61M6&}Rq
z<1jx$y(TX0d&nBusoJKMH#xlDa_>g!8>`>vQH^6B;(PH=hg}>0jg^oxs9gCM=&#V4
zn=ktwwuWtMbEMEWr2k@1&7XSMN?3Vqdi@Rg3@W)m<nQ^9Sh;7eo_c{VZcssge9>Xy
z5vyP9nXToAqJ9x0S{j9qT34pkd=N9ALH#{1R-b#+8h3wG@}rx`Po6%YeVJnxm0aZK
zn``{={R?H1<{Yzn&3y3d@P6gco?P`h1*BUe-)dF9Q*ZS5_1~qW@N{cm@TN`E-o<=e
zQMN5JF5O!F%Z}maBT>K9cT2suFWq8y(vutAKzmo5ICAbqx|KBl{^NWC=KG*s+iQg$
zw<c~bS0_YAeUf8}%^Gstn$x*P*})Gm|J$#mhpaztjTrNyn|TcVk*XHDaPPQvDPNxQ
zHQQG*sPH<?@>M)xJuS1ea?prEC@=rAZrx5;!Nu~_EWS3_pw8A!dvEp$Yp}FnWsFh{
z^EdZ^o!_3YcK8Qw|Ndtc^I^;Kuk)O=*s~jo&G{JX`BnVIjX&9RqD3aZ%8c(_KW|ei
zSDcaLq+M}Z87J+EQ?{S8pLfMcU7WNlZtmrzU2(`~XYJ=*aYh>_?TRbEIAiC#;)pd)
z+7-|4>ZDz9dZ3eb#YwwQ+wZ&L6+@h~D^6#ev@4Fk^{xH9D-K%jq+N04XeaH8L(4m9
zSDb$3l>NRdj#%cTU2(78PTCbesqUm*@t{X1?e|@A(q<>^imCUVv@3qn)JePIK}9m(
z&y3?QpK#if8E1Uuq+RjZ5l-3_hc|W7t~j-nlXk@^n4e^xxZ?4<owO^CpXsDsar+o2
z?TS+^C+&(;f}ON0rf#I$<-6juyPUKumghKWR~*#ONxS0shECcQr&V;)u6Q=(q+M~w
zI?w}Lt~e>qNxR~Zs!rM!r(HQ}Kkteo7CLEHOm%e9t~j}blXk`Q=_B_0t~hO$lXk_;
zJ2+`qoKf6KyW)t;hwb-W@x7%^+7-w5ani1ss^z3zani5f*zdby9NuZCN&I^MFXAOh
ztVP5|O|17Jz-}Df>s7v!1<{{;`9}7ck1}GigQ7BGB7RjzTn6#l8jb8TJ5v#tMLG>J
zai`UhPtKVLLmY_s0PYhhCmk`_f72NE$=Q%+ktW+&E+P&=oPjtG;wy-;%Y(XwxDeup
zh{>6h&kz?w>|L{weFkbC#6^)Vh`2D~l8A}Vcm>47&9*w?@`!1~MDFJizlB&vOg0pR
zB8JFmJ8nYcwBy7`Cmo4@@CZd>;=M#fQzDj<+ufsMY(rg-*f{%GlOB=XY<aa$TvQM8
zPHdDTT6XR3WOVH{I6e-NY!5s@@_Qs?<`1T+u7eo_{5Bwj;cm$5+BbSoVq_0&GbK;v
zyzY&3?$}BQ#K^muX_pL1C1t)5>ck#6L(>mqPzIh0BdHhE3y&9GFZ^Bvz9{p;awKLC
zJP5yFJV&lKd)|KZKk%o0492fkqnB@xZ&pW|&%8(ST^Es!$^W4U?(dL$@pvvOM>&Z|
z56iqq@?DpEIqvU}{PB2hrCT|q{acYf;8qrShSZZ>?q#{ZNAgne+>;z-`O}T4f(Wj9
zk!N02miv38tW-P~hWA_-saI>HBiza&&%CNE_xH&Ar|?{Ij<QmaUg=gAdFEARxxYus
zdWh#P<|ykH(ofvVBG0_4Ecf?FSvsDpjI+L67kNiUIyCbh$#-4u{qFt_$uEiL;@!$2
zeU*gtB)782Gq0+X>%FF}H${@N$h+iZj6F;MwWmw~)v{GstFc2?e*D|a;jJ4t4hv}>
zR;MN@r>@$$Zs+jm*x0zbox8_I_U+j{wq|^E&F(e3$3;aCh>0FpGd`*t6$H2{=~r(m
zt+fvo)W(NOneIykedSA~boQsx5Hb*`F8)*qLMTE6LJ~p>LK;E_0`(5^5ke6n5Rwp5
z5YiAb5U8%mM+ilTKuAJJK}bW$K%gR!j}VFwfslldf{=!gfj~tfA0ZSW0wD<@1>p$7
zJ%pfc{uGVS93dVd8DTBLcL-E>yo(Tu5P^_{kb;ngkbyu&As-<WAp#)@Aq61~Ap?Pm
zMm|C)LOenWLK;E_0@VX~2%!iO2uTPj2x$oS5Q2L8QwBl=LJ~p>LK?z71m{XB5}NrR
z_)+0dDxRckhf*1vaJJm^`czQq@R#{(r`Dy`mJFwY>Snz|GH-DKFP~Yg2T;0@m42Cl
ze<q0m)Lev>2%8ZOA^eE&03kpMph6I8BB%&W5#B*aK$wIu7hx&FT7+E)rx30oJVOYQ
z1E`7!DnfIFZV1B=CLzp4_#9y?!U=@y2+t7wl>n+ZLUjZap(#QHLOj9*gn0;GA#6uD
zgzzK6J%ncndDH-kM`(o54PgYr#|Wzt(h$-SG7z311ZZd%f{4%@p&LR1!U%*32#XQ6
zBBUc^AlyU9hdwNaP!mB$sE^PZAs%5Y!b}8m{cnH%yZ!kgRW~-SUvzk6->BGVoVs1t
zv9LI2wBZn=qf}j39229-8FcNaJRV^<t1c?Kd0b3iB7PJ=Iu<{fTsI*mF{XQDEKaf`
zC)ZJoN4>u8&k0E5`J9hY?Qy?<pH_qWB}VsY9ESp;`{A42Jn9XKNo<}F*FCx)&LZ`w
zAJaF=t|c|n{=a@qLcc^(p?ZVxbh3S~DMTWtj!Qi1$M)~nizMpw@6iKiaZuE1kNOGG
z(e<)^G}~z(KDNfrX&lonAu?ewwZWr7bYktg%_(Xx`LAyChVb>J&fEXT_3497A}8+E
zrY_{TgKBt^=i~bJi;InJf*yhd>UO7D|HSzID2}2^*mwIUB;c33T`es6=X(vKs4{MM
zTlXSnUy2I((>**$y+!VZkwJ<}=o6WU%4p=ytC~wSCpn~VTEz@O|4}Vn>DGheagsAh
zHID3;n0XpsjGeXzhV%qV9z^b-f&F9cDbX~t52gh*H0!Q2lkAZhmh&#2oJa08tJj3|
z#d`8T>4e%*Q84OZoVL2|AQc`R84vlN+-a2<nUL5&-l@WQ=T21Sl%*~?>4ccRJxLqz
zjhprzds5lscRwrLI;Kx_?S7>F<UgvY7fL7pz3jQt<W3u$z!(<YBeH*NV&l3E!zikS
z7pYBcaP{s~8~cAUpD3!G{eO%8(Fudemq_p1N0qj>@3)M0-sotjNQZ-|+yA#Er^R5v
zaNe_5!@gKMNDs-mifZ?bY84;Tw{BejzVN7Ud#+XEn0|?<P!u%?cd@Qet=`d5_O!S2
zsG;unn`1R#`6Uc?@+NvU>=zc@t$)v+(Fx7b?U;zv$GDd{8{-n{W4-rJh<4@8MxI^Y
zx@6%;_Kc?Hy6!kjmfG&sxNeik_?I-}kXPgA$N@Q<1KrN6aa<%;kiFLI8S>1l3Hmsu
z&fvu8)^Y7(qM~sIW&(b<)LAcfEnk+}-rMfy=FtguN8_kWyJtX!`g*sFjOmBj+&wzp
z>HlHgEzv!h%MmkTq@5<iPEnV<TPDV~={pcag?i-O>gB4fo0t&m%&7z_#0U4?)=%5W
zgqX-~gaXzgIi#RW5{M;4ndF|^s_8(|trB0((BUNArf)Bs#zwuYCQ2bRbe>P^=meO*
zF&$h4fm-d;I<}uPd8jqye|x&ECI4Z1Vl?_kQ(ux43U*T4d|vwjDxa^bYg@;?>~E^9
zZ#z(JbfQhO+EL}4wB1Q>*K66dUSp1}85Qfeo7%kB_2+q}{<ShQCTXwYp;T!Ea=G$T
z-ST^s45cO`xaX(4<=3kbO0`2M=QE9{@2|alkn_LKytaF6?Bsv@=YRX>RXy-uy>?u5
zz<r&QdR<AbV^{BW`46Z5b-wqszs@f>{jc*Y%=qhkerBEjb~J``n5)0`xY5mT;_6aA
zBD~3(cfEhg?R`@2Z|^y-1FrnDIr2vhsQdEUxAFg*eCxm4Gw%JDv;9?<WpDqV@|XWj
z{))fJ|Lm{xHzWVQvcE9AFVZ5z?QasyDk&@rPb2;0x=7xe)XOz*a<20V`?I$@XFh-6
zzqZ|P(iYNoS9`YRSO-5`etmoVZ`7soA-KN}hY%a5c9l2ee)fF#bxhuS_#k_J&i=ao
zFnj)i9OWnfnms?~Iv)O8_WYdRpY%ue{G8=C^Mfjc%hjHo_4^}7e$Mxo<@)RQn+0Ug
zPjPGC(7-Ti6oUKrbGB~|+0=#0Rljv^@00rh1#yDHza(F}e<vrs=o#{6-*MG*SdMz0
ztPy706Vkh7t<ehMuV16Ca@M+)^TFdVY9+#(wAb~1&hcEDzup_Y|0dt~@Ak}JjbGI=
z^+@*1d6aW}tA_kde%ZgtFZb8^yZ<J?8U62#%U`wgbLFq=nOr-2e$M%0*2$iqb3Hb$
zmpy-s+x#W<+S)LCeolJYv&ozF!|Uevo@Q_M{(t4%bsvwM{n@%-_WsD3AC;Ir|8S1}
zOds^$yS+Kr*`ZO{+w-UV(b@BJ_Q$FBv*+jJN7Z&_&tH+Fzl!e7o}aV)-wWczqJN2>
z{7){&wLWvs*On8V6QErAIpwjzle6dN9N+dIJNfBpPCTqxBioKU9`RBHauNG4xiIv$
ztVVoG?qxpjvNOBqrSGW!k}u@^p1#HTP9DU?5M1?kmt)AcM(=i>Te7P@wH6_i+|0Z-
z?ydi_F0Svo@`yZ6LQr$~u3+AI;{Oo*Pwvr(-7j*_^?i4`Ir^LW_<djJ`>)FX;&6TH
zO9XOV$?TI}YqHC+<-d3G$us=L`Y)dgADR8Ry4SOw^S+wZA35bt>h7DZBUgQMuEV7d
zvbSexX1!g{PyX%A%Kx|4AQ?BhXO`@i(IWfUkbWZ<86$GJ>gnFDUne%8DotweuhEy+
zeTUrNliGkpudD~T|H0<$`G4x)UD@+<&iAmrZ`O`i^#l2S)WPiK=cEHo4!>FXZ!*5*
zd;i(jm&JC3HN6(Ph0GH&2VC>uRp0dpdDY#&zvqef{;J&9l|bGjbmdL13iBJ<-*9gS
z`M+0`^ZU@QGRQsG|F4R3<|k1B0RgXi@L#_d^xDh$RLE<uf4wUIzZ4kRt$S2-kDk3^
z-t8URr*B;RdoZl`A24vxVDfX$xN6s_8&<D=gYbrp-frBaX|v`nTDEH4rfs|S9XdMs
z|F8Ug?KB8-TKL*&5c2;@57_PazkE7)czW9|UQ4~;+%|gf=(3rEv+R=d&!SJAc+|p-
zXXL-o5lMEu0?+SUa(+pOll`Z^qn<mrLNnv_Z}@!e%;z`Y`D2T(EG|x6U3`6Ur`MN1
zVv+qu3m<qKoPXzh2-WrcyXT#A5#3)Jb@J@@8BcL8<_M=|A+sGiOrCM4`R@O_zaP{y
zyFBtw)2^~*w{lbFHl#x4HKf)KYUs-TQ{22qBZ`h}guRzey@~8i1~4Z-Anhv$UNZ^h
zrw{x4Ff#K>#`CA}{Oba#Z%urU1R{H6%yZ<({<Cqz?Fz}E<B|Fi9_gJKNZNIg*Iw7}
zB=7&m%j0h@&m5Om=H+UuORjUJ$Jck}L`|!9Tl|i1*GS@56N)1mLPM#Xc`twe_Z9hn
zm6r%tpsq3S$;nY>81YzY3Qv|C_sK6eW!}zKhj_OP_qxTq7lekn=h<2CSxW5R&sAi$
z{P@V2m)~;r$^XXxb9!KH#ZZcb|GoZa_CPM@!oH?^UN~Rh+ZE@+E}Xm`xp3dxBUi3K
zc=2Wa?|vWu|LuLei*jC;;C#g?+j-mVf7B&7DwtY}lm2fZ)c3Y4hp(_+_^+^&3Z{yB
z1djXk0x7enN3Otm_HB}Sh^K<7PH4y5_+l>XvAXA7n0n!qg8WAwfmCn5Kx(*0FlC_p
z(jLKM0~-ax4>Xt>g_iHe{VH}{Z+PaSLZ~HP_$J~{5eKg(CDx+W``4m;0!Ux%_YR@b
z{c{z@jxmqI)Dwi<o`tFLo`C~`rw1<xrjB_AZw#jTpf(dwZcIQhHN=<HZz=Aa^er6N
z4>cNxx&<~4tR2`kkowUxkecG{9~ejt@d#WVNEPuYMRoDaRUp?}*Wdab`@pvU=dg03
zRiNZTv`IgpKVh!2ExA72P;L}Aj+@L)<K}QF+;VO;x1QU|?dA?~C%E(6kKAqU0r!OS
z<n!=l`HFlKz7rqG_vHKV{rJIr5<iZg!q4F6@k{v6`LFoR{4V|oe}X^D|Hu~<-V$00
z9fZlkd|`?3nXpD!FKiKZ2?vFA;f(OTa8<Y^JQSV@-eQngOe`%{5NnFE*huUw_7w+;
zv&2Q>O7Uy)fmllFA@`Pt%W3in`GR~!z99!Gg_QEj5ao;-s5Q{yw3*r`+A8g^_M=|S
zc-xq1oHKHpA!ci{iy3VunID={%~@uK*@YaCOU*+UJf=OEd`w}c9n*~&!^~kmW!5uc
zY$LWcTac^BwdSI@{@gsYKan58Pv*M_9}3fimSP9-U9rD7TKrI)D}E~aNWqdKg-WNT
z%hFvbmwZS5UG`HdDZFAR^^_(`qB=}{s(NbvT7IpVCTXEsxVA>yr0vqqYCmc>wd%T{
z8+s3Yrv8b(N}qwf)D+bVb@Qh;(y>et^m~BNOBgRSm5V856$NF+C>s?)4Oi3D9$G&w
zSzn=V)OYJA^zZfC`V-yHXlryb1{g!p{!fhgW~zDC{K>3u#aKhEFRZoJR_lg!$NI&h
zLMdt~zB7_uLkBPgm@-UdhGTT5Bh!m{j~T{{WtK8uF*lf}j0ansZNnN|ORg&y!wup#
zaQnE^+%>KQAHrARTk-ArE_{D}4!?k3&L8Jb^B4GE_-X<zC_;DCypQk!#(cG~QTRc)
zCfpRf#KK}lQ4|}9jm4H?J8^(GQ`{_`5sOL9(1%YYU%8lkUA~}rsHj|X3MctcR5AK3
zx;fpMo=ksCFQC7n)9G*No=iORL~E|M*4yiy^$0ym@1@7;@p_^@NFSz;*JtU6^ke#2
zJ;*3z6gOI+SGpRrjCsZ)!{01oHZq%;?agF!hB?<fZk{$TnMJIUR#|JjHOo3=9kZ}E
zJOX<{@$DeG5M7*ZLARy5(zED!^dj1yDZ(^jnlbH}WM&34mpRUyW-c*B*ph5nc04<a
zJ;WYk&$2;WA+9*rf@_Ojn}u1li1X)*@QwIp=&xj~l(}|aUE+%fC55uWBw@dBSU4+`
z6w9J_5-{)I7x#;Y#pB{6WxsM*IjfXZ%c>RC1a+YLzPevMtR7dl7-_~~!_UlP<~N&~
zt<0`y%R+Oh8E^HsMq!+HTKg<CARapu5Dlf1=t=Z``Y?T*&S#HzN2V(i#qg}c)?<^{
z57-H;#)Wc?K?5dnQ@NkGTUhNJFY^Z92Q?ZYZW6bPyTyr8vNTURBVCk!kR(}`!{zto
z@$zJOpZbk@Mh(`AXeF@%{q#I~QH)C@X7*S1{PZ*O82JtC5l*70F{qCporf-pF^!~q
z&|hJ$@235jJWPJ(EPs{XC~g%Gh+dMvlvir21gL>(3AM8tsrFC}t&Y}I`$(Iv&C&L2
z?jxS0kI}!=f7I{jwG7@+jJ9Scv!}VjTxEV`HnLh+v#ohninY{QVXefu4A`@XI@D+1
zX4|o|+4<~Z_6B>0{mt%ydZ2`(x$2m~ydVp@5GsTT;X-4fxlOZf$@k=k@)P-)Oex-q
zzmi7@QVJ?X6)FXOOem9Le9(%Ppedc1`HVlCmo3J2WV^Ca>=?|BNo+DZ9bcTsrm&mX
zaK0U1Q4ob#;Q&^EEZ38Zs3q0PYIn7l+DF}>ziY%{9d9*u8vBez<}$S87xRhvhgr=!
zY^7VLFiS658P*l+IvMA+<eXZHGUz&VQ~D!%Iz5M;%PeB9Gq;#~%tPi0^Ng9ve}Xl7
zoxjaL;1$6X8VM7HWMPKzjc`I3CM8K@r18=ujPG=5HpVzbx*?U6%geD^yq2g9(uQeC
z+8AxTHc3lH|IgO&u{39HrEz<?<6JQ2cS+EK1EBop_~Jqtp~B0aYb~@FItvlP6VVT=
z{2Iy~q>NLFt7X(`YOMO6IzU~fcGS9Ry|tCvm)Ztxvi`BYK)<A4(QoKQj8ybNnz6??
zfcc(ooHA;dtZAAf%`u?q%RtpOT2Czd%$#(Gc6!otu}-hkx9EHHL;4B*jGoDT0*-dw
z=3xqNVjWJjSK&9{QNzR}af~=#oFpcT)5Y21JTXNKmWoNb8mfkY&Nfz?tF6`cn1K;$
z6h;Q^&Y&owqBjR!jKtho&aPx{v+cPqppTz(Yq)jXDef$Hk;~w&;G4I&dt5Glwy<0n
zAdbb%E-F`&H_JQZZ{$2mex<NdU-?aWq2$JQTBvPRMiVi|-$y@B*0yLlDccd7&X+MN
z7*&j_CSwjVhk>(=F~^&eOjPI|WuK^Ak*UT=%phhsGnzTb9A(ZkCD;)5Ew&Tejm^Uc
z@df#!7^x7x0$-W0&eP!EEBUYaXA&iQ%l>j6IY=%j7nMuOA#w$|vW#*eEQ}}ZrQ2Y=
zE~b~$E9u*Gd!`E$!+g%HVb(FHn6u19CWE<>Ip4;E=JntQpj>~kh`3o2WL2&&kCP|K
zQ{|QNT6vwED$iFIE31{e%0uO;QbS`kQyYo-^`Vxef1poAJJ0ABbu!y?S&gh_R%<fH
zgFI}$9mo~rLbyn-2iKcZc^p&2PvWQYGx<J3f-pkZA?$%{@vGpB<Wg}3<cGE5Ix#Oe
zb!n-q6eYz-W95nREcvYbo&2LbL>Z+V0F6yoPJzx|R0iln^>O+Eo%D4vqqI@g=xxLs
z{f#e-uZ+%CgcW7=vSO`xE72Nc4YQK02i8+kw-67z?@OX)6}ZY=b&lqEPUdvb)G#ib
zqcuURt&P^kVf`G@Wbpik`UL$WeY(C*Pt~{TY5E>~^RS+d89&GzXSTI^fMTIs+5>0o
zQP{`q$9&Gd#Z~1*ZXh=dvf4aIX-l~k++_Y^@ZL-O75)ZaN-PKIDNalj2aEAie`%Do
zOWH3TmaZ$e(aWl8VMcqHzGg7^MSI9aRjpc<hE|NS#*%M^df2>z(BuUAYdV$QM&G0-
zfzM56W;64c6vzZCm_Ha#HXqvzQc?%DBSv8bw~||nIiCt?v8~ui?1>&<C4MD76`zX%
z(%VvVsf{#I`dHGHP$f(WR~jqLmDWmorLz*De1`tMtW-B>&}`YzjZh=Z2sauV&5hPZ
zdz=&GVbkd($PiOOqs|Byg;H3llf^mWdGV5XMf3)b$Rh<w1*M`=Nhw51mG{dtm1QVZ
zhD3Nzd!%{jx?WqauRk$-%nhWC5gybEMDNmZ^iX;$y_4QY&u11htC_o?l24gR>;d*L
zo6epB55LG}uvZ}Y)Zv<PA92$m7jNLV@cVgxA+HcDd@g(`Jb~OwiQb~Wm`7YDe<5!K
zXZS<*R2nKxm5$0MN{aHSazXh~ana0qT8g$*TLCJ!Rx77h(HmRMF|*rSIp-BB81F&E
zA1XqMmfn-Tk~T_Pr9Y%zavyoHO+EHN0=_Qaa^ptDlojembu6UdAia=YHk13xW<B#U
zX?K#dc0Px^w*?f@gYjj4V6HI_7><=$gYC`c;exQPigK<QJRDqb3U>^&>>PKV|ADV8
zWbwq)(go=!sj^%{W>KFJ@&r(`bopC3w-T&ug=D%%JpdUcT|K3qRWGU;Y89=s)?Hg^
zt~J*|BHe1HnS0Cw=3z74JO%j_TPW@Gb1BJ3$}hE)+DV<I`I5h!7qVbSxvLx{kAaLa
zNluoh%d_Qqa*8ag4b;L~MU*;An}`0qrQO#aYjyMndMikN^Yle}XGn7M!0m5Y_bt2q
zDIT_5U59Q!x5|{{h&0v-I?Ez{8RXVR;$HEPcv>uinN(KNA=8IR;Sy<~DUU=AK9sj9
zyOg6!pjuEZrUq$+w6a<^t)~{NjW;G6bBy!GCF6=gt#$f&A=b)T=05Y7`JEvW;RUuN
zR~A~uAJCxk;k&K*4$zt0`;^ET^M%EbmG43ydMXr_N=TKYUQ!<k`?2Nxa(lV69D%;*
zCCAFXT5d>M?X@nb!DrfPZL{{fM(IAfrq|JL8TX8b#uMY2L7CpBKjgz8b2K<5=0KX$
z&nr>0bxbO=l}TgvFb9~!Ou9|M)0Dl+aV1zKQb-q!;1TtlT3jomRnWqqwKUe6YpwCk
z&RT>vSo1fE7}t!)Mn}k<z0H;8m*xiZ8u>=L2Q>*%N66^s>1%W)raHqgjhW_5Ye>un
zTZe7Regqk44toT8<@a0}aG@%E2y{dS)O(;XOqh+a|4jNB+SEgd$O5}GFWq0ytDlEF
za8s{tFotO4Hw&BP%<g6{vyb_Ssav5|m=$ihR?{l$D{H&;!lE)9+UZT_f{v3P-|x&s
zK<4em#4^5oZpbS{cj?A|#;=CP`a4evK7uCH5pIe1#E0S&@tH_TE(+5DlF>AY%;hWU
zb@i5dPkpF9QJ<-l<_+Br4Zi0=g(IRlfvb&`L!{^<9Fd+I@)P)v`04yQK9%3fr}29r
zAsyz^`CgFn>q~8=ZN@I+s1axuG>e(}uu?s3UR$27O!IVqdI&v|_Gk03L2N;`D0GYv
zwgNkXoyN@u?Z3+X%-!V%q0f?pG0+hwL7JN`+!2W6To6>ZBe-358sV)>Qod7vRPU&@
zG+t9QcZvBA)6>dlbJ`AsUIckk(-94)N7Ga2WArKd9DS6z%wA_7vI3`a7UycmDQNi@
z`3&9^T8Zt&DCoqWi)%z)mZ2Sl%3;tD8q3Y))$(p|*;7g(l}LRq8n{kN)wXJBS`D4m
zO?@O}_z!jW{+MqqwpLqrt%sRB*3;G<O4~Fm%+^^xVzbLKJaC95!U|!X@JRSgcp+q$
zXqQUQr2>%FD=5**yGoprHG+AxAg!R*RPS!|G7^pT#%5!O;XbDbh2Bp3h4!@P_euIJ
zeT9CDsmj!1*0HJVRyK{@lgT@3a&`G|tZ<^`E#xbRmBs2JE%HD$bTL%yB6XAcN^7Kb
z(k3Z;uQ+_c)hBzj(mDsO7-oE6OfWt&ib6vTu_{=Vt?CwS@zxaR@Xi=5p;yrB=tuN#
z^b0z>j<J-@%LQ|#p@T+2Hl5Ee#!SD<KjfeCe+ZspKCzkD8hFO*Ym{@Gve&4fmAy`=
z5ro7)*D0sw^Coo~Ax#6VUn*aff0pmcgMgwWsbkdf>LfK;osRiSXhK1~jowl3s$Vy<
z)4X@gevr+^SbJ?<9(9WFv~@H0^&ih9GOO9$+yU^nLVR()48Ih!W~HzeGbdHpDx?Xe
zMNX2z13r)@NFPZBF>6XHA(%OpmFfzuOi`AoE7W!BBlS1+g*pa^!z4W!(%futpA>zy
zu^asDlv&6sZk4g9c&ATRKyF@(kxGT!kw)*K|H(YADc6N8)moXM%vBaD6|~A)b&bZF
zmNgw1(*o^lJrxqAj}c%58q>|$<~%b6*uV-<>a{kNp^`jpxze4^c(d6l%{F!ydz2;8
zb}^37$-ev=P_a$?HfX{}g+Q?&@VZryO}0xfByTyFoEO}`w9-|H0!GybSj7l+2PA=m
zDwXVM%a!AS;4GwPLoZ&#tYBBMJJ?ii8zc;(F<#=&3g3bA{Vd)Ue;0MBwp3p#C6|+H
z%5iccWQ^r<cF8eHap%UOra|5#I@8BmRh_Xhpd?TeGAb3VYL<lgFx(n#9kh;GI7cwW
z(>}Yu1RVlosT19e&Q4z|v(;G|dfjL2VPKS}fXiGIGK4F_bs&}Zz?+{48OBxPzQLN3
zshh*i>*j6qsi|5PxKK{*U=CRmYaN<V8CsbyTi8a3T=IYi@5={gqG%KOED6g&9o*%C
z-$W0{BaI<Xx0c#NLVB$HuJ}PeZKAeR=co(R&()jYN{`fP(4{Ww8PJ`t>$miK`a__C
z&+yYb4UJ*O`#3w(8TZ3L(N2MeU8FNW$Fg+g5alg}Q4*Aa$}seBWwnN?s6*6|SbIw`
z-&d+@G3QfNBIC8!d+MT5-ykU3BJ-$u5|UgWE5RCJ<BaP`yVE^wOrj68i4pWBdOJ{_
zAifar<ED0tZv%&TZexXla9emFJQozv6zhsjl$OdnnAJ<6A8b>1sYikD76f|g&Lt)r
z9~%p7iR*@ujdNvq+B!oQjA~!Vy6f=WZOkrc!GYkQ#n@6@Ij$xb$0c%uxdr@pz+mra
zwRB!rbi=4)GzFcV4q0x#x!7E7-ZdX$T!Ady^Q6Mi98WqQ-HdKccc8lfG45+?zMB~L
zRZ@yC$JgZJ_(bT`!-dhp6yX@=&p81vQ(pEN;d!-Stu&C1C@n@Cu8-EI0Hr*opVMy}
z4~*xAWrmpz%_de$>m6$$(5lZYD##0`*i+OtdKZ0^4rB^4#h6lTIkqMn$0o9aS$8S@
zJD}}%_*%fN6rqovppVdZfCe1Yj~FM6?~O8M1+$7-!(uJd8VTz7A#iXnyIl^hdI|I3
z27MbE!E?r9!`Oyw6JWmYa0?-6e8#Qfzv8#^FL-YumylNs22S4<ygo+6*{gPcmzFqi
z{4n_g=mH<fMIk|ks1<-^Raa@1SEr~;Af>N^KK7gT0`l@CBN_cX8+dGru@vnt08UcD
ziniXh;%pw`WzU-@&{HVJoAC!S7=)HDV7>;Y-NX8D0bC$Aou3WaJ%wM&uK>=lmd_`Y
z2dCwM%?}YrirzVpj1lrQWj1EiRpn=34v9JNEOc;$mo2}|R3@vRs+*v_lthg;YL~R1
zP-jUm1N3--vCi;CAIfF}8;1)7Wif#TBw919`PK&O8L4}`mo1}sV6GIPtJ7nF!=(au
zUBRqkb}-A><LqhZ0wsVF-QkMyrTI#H3%)J1kVJkEKMZ!1W&AMEmp?#VJB#0l1g(gN
zJiJ(1E;W$n$dBc=$}n}OO3>DH^{M_`_cAV;KS1&xVvp&!pl+9dv3lVb{wOL2E1(~A
z_+9vZ08@wA0(pNgQ=aVsZ7-hP4?XudOLUTIz!LiM*Z7<KJ^rMqN{^%>(6zS82jl|^
zt*UA_wWp2Jd1!gHK9K!Qy^;R8zCrJ7gqUA|&)qi-tB%zGxT=>;SA8%$CAJqk5IXcv
z><WG(-(Kh`6c(!ho6yDDVheGq{GFl$RlBbKsy^0#2X&$i!B7n%`|XD`{42B<53Ini
zp)KCAQO_4<CCELDHNpDGnr@x5Zj!!EapuW6+NHUEY-8=Wxcl5=t~OsE$Pm%(zR2V)
zXT|TpUCv71LAM~-&t18f(nlGoQ~`~fuT})|R$ptY5gSSqqowhVF%h$L22jTzjf$Z0
zi8!GcXTGlWA|@KD6kU$43EmMwN7J)`U_Yi)VLRF{^)V8F*?ww#ZmcnWHUlgw&CAwp
z{b55`#%y9{0{7hqwD}3^$Mph|(~55^#6WhRh5k{1dLIF<;nZ-MyifL3a>K?|98w3T
z>{G9)z8cYbMQygR+_-6ko9&?epfc%Rww>fRdMxvZ`HgwO{Kk#tAMw9oy&eE+5-wJj
zBx!{-2s$0F@5ihuYLqlWfFf2l2=+45_zXSn30v7)W>vG6shDw@=;{>nJM%}_kM5YI
zta26^0nus&yrPTM8;H?FP<krEi@>3j59Yc;^U$%nFmcc*j{|k|W^(~4s?Wx-eK8jn
zvCG&mFyo%F9$3FTr*I}W!nTZj&XG0HmH!a3`!v`O$vk|@mlrAvHH6y25Mco*P7T<L
zVu7D7gI(kYAWLOnb=xNe%SC`vHj<mkt>qYbg}e&5>JuP~8<m~PPe2wc0mHqb-p4HS
z0{&(|haImi1X@sB4~JxMU4Nwip%(z+)ZQ3utc1Prg;C6m#Y*01owj}=Rx;>yUeql_
zzH||~JT21(I6!yEF*6}^|41uLDASN>3LW|gY(RxzDXYk~V%xJ_u)dPn^K2Dh!u`1+
zkTQ>Om$=zHC)CGSPZkym-wNkp4=W%R6-$BRC5hF*+2f_5wq516R9r3t?3G|2y&(n9
zmlxYu<qf&8QUWsQMw>5N>W84Kgy%m4zEV@;v}kRV_9^Tlm2?j6YXZr5r@jv;<_q21
z$Ym6U-rUUSY4kCM7<Yl8e{Ws}ha*<6ia<zyCvAmC8Nqq|pm{2=4G*J7p{1MY9gtNE
z!-BDr{gU0r{><Km4#;v6SC@;oTNf@i0XLWdd+0Lpq)1lTAZa*c=5V<QS};SND=(8z
z+AS!9nM~W7*HB=s-+>Z$frV(cIp17^6?WaaO|*9Cp56rZ#QBtE>8dnKYjhawe?92l
z^g#L(dI^1iK0;rjgTM*jVrnuP6Ahf3;4LSaa%?5GC2-02*@^5`_8$Axo@>ECwMv7|
zRp(e}u5ZJ#JCjQVj#ousVFhU*v<9bM2$_GU5G>XL2kB+&up7i6sgR8XHInW~zrwa#
zNG=WRJ`DP78~Gi%CnVGU@=$p+aP2BeO+^JI`4D=+TxGp-0tn;}z+C;*ylP?C?P>vc
z?FHN2di4kOXEmQzN-L+e)Y<_Po3AYfezQm8_2&9CeYs8p{rt#SVq7$SFm7XoH!(Yy
z3Fc6s{L3J@uQzv^7a@~)S^ic*tEQD|ZG*Lv3h}miPBogQb@a|Dx;A>G5Zji$#TMqq
za|gMn+}F_1ukt_hf-p!JC#({_f-Saz__4SR^d?M-fW_yKR0t>=qlk(H`Ms~wPsytW
z!}3;7ZKO6+3jv?6i}f==8wxv6ntm6up9VTP5w@9Outrg|H&q!!mrmcOy_sRKYwj0P
z&<7<Uzx|B$HxyKU6HZ#ELcOW8hy?mHvy>eR9AhW<4c5j@aKoxR3pBqC<fmc$2S8);
z!}iux=qr4T)$$%JkRQP|^QqWaIwD;GI+!2pBMSXLM*dj-N<JfB1{(TA_E3CbCGQAq
zc@X&hBIR>s4J@eFlsif>$RVwut(DNqLsx35MFM-+11$b0NPxcpKTCq%wnAU6e+wI8
zYgmg%1Jzpus<00H=v(6gusv@x5cE;Nh(wv^&8rxNeAZ-G7S|A+qPaK4W6t`6PL#u}
zZ9*?*z5uRv0l4z-poFDhe;E(lYd&y-qwG1*e=lg}GFOjl!u91ga=W;buovBd&6R?6
zrXpVp9u^&-b6w@LTOqUb(>=lg*o?FElQ1zHG_pA~`u30=A|Rdh0>zAnEntv1?4^xs
z1L)^@@hawaUumQ?PMR#O1-85wc<v49zEnjPfp#vydc7k5B3HtkZlttQ)+(En>q={A
z0ISr>T1PEiI|c8Bi&}<uMQZ~aZ#?A8!;oSx>iIBt^8%Zb%r-#hV$JP9c+Y{-{9y)K
zRV>}AXLYjPgX}pOQVOh=5#E%JJ}V21=^$O4sle1_S}^ax|6mBSf!WU7WK4Dtdj@i7
zJUHcWZY=jHw+j9kC%I5)5bgLe{CHS?l7X#l<SPkvg|~$k!aG6_@Y1h@eXtk&B>XPq
zf~UbK%$(V1cd%3jh-y1<!u8TNtY{9l>#3kl`{ja4Ii;GyD!rA#%4pEnbme>HChT%v
zkYlT=239~9wVyf^w)ZLOOm(+<Uj1G5)&d~Qm(c0~7wxR|g?;n`%%+N<y}BL->f09j
z=Un{@{iOaIq_q67BXLGO_+|{n%$fwbVjd*ll|Y(y!lro+6xrJ>V3vd>zcaY+Do|#B
zD~}a~RbCWQaU!I<@z4g=0?{~Y{XqII-rJV(_R-1kTv-pKSz$wA!#~be!OUs%vS+f(
z$T=~{ocd;CSh;%&?+GKpr9J{h{0S&gS$Jv8M&A{c{!rU%RFb!SPW4GTn%#;uTbCb+
zZ_VVFNbQv&>TGQ{kw=ofZTo0@W;%P2dkE<(1Y<B)Tnx+5CP=mC#mk}~Uz8ufSH=Sz
zt(-CoHk&n|o7<J$;0jkDqyK`w&!grCR#-z7V7Kax{(oPcjNVTND*cms7n-goFgro}
zO#e#X1}!QB+U_I0s?iVDtO?c}YdL!BAn^ZtKo6fdvU!R(C1bvUR?+_OKM0}=!Uv%w
zP=E?RTdUJ!=<)E8NQUivHoQC>ouepIk_o}gtPK1*0=RL1W+vukGd2P|W&$vb6YL{!
zc^-DYPFy$J2A0O{0lz=YrT@ta?1z<I3HH`RekkwY2wB#nAfPEl#W489bP|`svUMBS
zb2aGsk<ul2#Za)cGzYDFAC}W^;9o>MpK5_p>+lEauEYY>ouOP(Jk^@21S@rn`T=?>
zMLh{>=cN?~y&Lq>dhfn=uR{{Lr#;l3XoF#IKd1ky*D<OCS*&eM1?svV9tPjRdh!G^
zuQ!#7ZaYl}L$;gFtc2}gC)0=h8vIq`B7`XT`NRtGm@%_p!FU8co)J~Z1Z`jo90rT`
zDbSlcVyM&vm~<j+k`o}`R0E~4<Y8#h1lWU5!=IuY@T?eRp0XVD<~XE-n@WDPriVHM
z7}76lIjsfw&Km7|EibGbVL*1$;oWl+-T}3NY^*UhKzE=(nIp{d)?mn`(1Kv^@V5Qj
zbUG9gL^$0TQbcRIJ-kjL=qR_bo=2z9OCir?N9PW}SEf2cGdv@^*$v`>8xDeh)C5>W
z&oR|lku~81(2JeIu7kYy2O9#Zz8^eDwsKkX;1>4__nZslOM%1ngshP)%mLE)Eu`8C
z=%<Dl^9XS$<fkR#7x1yU0bi&}5-s(XzCb@Mf`$5uvKey29mshlwW>gO!q698VR^a(
z>n5wufTzS#{Y!m2WW8GEEO<ktfgjs8>2z<Lm`YI!d_o#RlG_i=Cxgxf@05<rK3MF%
z*aB=-mSbzf3#LEj^GwX=hpZ=;8?s%P?eEnWbaw=}(*bw@-b5Sx;Qdzu7MsQVULXMj
zVRiTzk`wXn+6t@tAs}TLLNSS#r=Z@)<sanAwlvWK+<2<;m9hhzxE@yVRCO+Vm@?EG
zkX;*VozRka%+K-KRE%$`b{-u0q4rGk)`Q?fR6`fx-4&~k0=hZ}9Qu3x7riDVkJ?5w
zC}}dV18*|`9H+Ed$)ruuG@zSD1CiQmJ~H33+E^c0>#eI~E@U_|QX$NQ))@W%81eP=
zRUr7)85Nv*7wp<U!viP}SBf(r*-o{+AJ4;k<1zP)^M!Vv1iT@I?+<-sEUa|PF@gc`
zEI1{Kau|5zR@kvC0Ht1t6-UE=W0!VAdq>}__caa~-GC#p)-K>kP90i8bC|;X%sj??
z834YPi+>BKQ9XE5_62Pij_)jlt!M|o0e+H4pd~y4^4Cai0qs9bnWp@zXz-Z1pcaJu
z_yz1^H-S%R(8xd17o%@V!`E#&zM0!B4n8s$o^20J%bI2_vo3%Rq8}(9Djaj-ZF&H_
zt^%3v%tpo!eo&);#^#4L|4YsTT646pNZ2IY7iz%|Z5HO`W=QqV#adXw?@DpdQs%=N
zy%TcSPtrE|dmys}FMJ=~9H(LJ{z(zlhVbYa3dDY<`U&XJ26YSY!qcd8hWZ$slY$mo
zLJNT&s{yNSiy07+DOb*f2WJY}v;{Vy)7k|{7>{ksW?{XA9)g*m>7n4OoiHPamqwE9
zHJJh=Vhj8yPU{!I0~|D=uu%f~Es;<|ZGXrJ+aof`_K8dZtsuU0ry<j2z=HWZ=tg0)
z1hik#)XY$`Ej-5}%mKE{JrnwM3g*%U;5~&c1s29Q>vL#_=YY%kI6RK-Nry8{;7j*A
zQw+GA1nnaN2umEe!&LTjXiR><stRIOv0MXq*R{lonq^~Zt0428fuG%DNPND$Wc#rk
z<eP&35}o}qsKa&fS1}d-8<so>I>tPCm*NlGY%11HFL-37W8_Q1vmsJH3oZSwc^1_A
zE_4AOTP`?De@EY?&obXZ{v`Tn99sk$kisp%D)z-3o5MfmRiQVufX6}=&>Et#jf0JI
zj<i7fMtUrjg}+V@*u2jvHPmsia14T9R%iV);}6JpMIZxP@E*}1nT&@lw~)*$+K0GI
zQU&NQVA}{_eq!Qb6MMp%;EDUWFwChAd<<66ct~q5ndC4qiuOtu*x`!6TJXL4A-p0s
zY6roS3d4%>F|ff^K!M`TQ6{8{P#@|r%5O`@08{&nzJPC3W@<1N(;M7q8*>c(Uk=F1
zIrcGIjKj};aT<KFQsJw5imS}mK<^&lPr@(lGJlKT0gtzn@Z0bO<xPbKbWAJ`J&&}0
zHYDLg(lMz3{GTdd#kG|?$*q)b$}^=D^tV_wUd^u+h4xm(_U37Vc^jqmf(Jl6#^W>i
zAUx3uf@aOu=j&^LE(8KI+y~jNFc6hS@YNb;_OkjwlB1eCW7L*;7nb<-Oj+=dx~O}y
zGy}c=L@EX?vz8nwFT+aMhjnlbtH56`0u8Z^{th@F@s2yFABBgMhv94F271vGef6oa
z+Bj=`2ehh~O$}SvGdaTyw#HeLz|qlp5k9v6)O30ou;lynACS2#GPNOdcL7fu56-@i
zxe7_r173?ofKp~ahb{qsCgOF}0$x5}b3uF^$l6=^o%~7oZRdqmQ-}R98rnrNbhC|+
zu}{Jyx&pXYDDaH7Za791@R?-!CS<<5u$)uyfJp@s^}_UqjJuW8E#Ak*$qvwG=>5zS
zP{u%b%;tq%?o+;m5CY$mra~)t5zY{D!%w`VZ6^q~zjpw1=o02@Em)ho0e}7&c*$4t
zZ0OR}fhiL2=WweXkzyz+$;bB5@}r4w+(*nHb~t<y27v;9#MOZAsqtqpKORHlY9K@l
z{e-fRzX$@`ONs?Hvro$X(lhQ1tSXgYnH>le8|5bZ*f{z=#TS~w1eH*u!$1*<$7>^C
zE}b&z&N-m)KN}9lMm!e=!y9H3bfkkse@=1Ah@%tXshee;+0EQ$YJx}0><o4;yCic|
zE^{w9Z$1})8~yoQRuogItDqiheQcZFG5!?)9bZT&4j)V&sA3%(5g!9@thQ1osi%!5
zuatg(WtD}#GXkENzboEqE@=BKB(6|3S(^b1;sIzgC$wUEInbCc`an?I&x|m$IXKEq
z+n2=0#^@bH>;rlNJuTBS`#O9fU)VkZbs+~OaUY<jLFn5CSpCEKv9KcS##;Q5?;x#|
z_DBb%6VN(`!Lw%$P_AN-Wyb(T`52h&7GPVYA?b|Kit3+QUy|`l_pyDVN-^bt`$WP5
zGnA<X&-`HFYuN%7NmP=QqG&-|wLfgcU#lm8`~_*XpzHU6*Ij*M6lm8%Xi@9o8-3Wq
zFC%975I1<LCe6_n=G`N@Abj9kGBsG1)!5b2X6c$*23`{1!uRB|UfHMtj*@EdmJCgn
zc$`r8d~6^332aW!*`?4iS3<L1C#8Z@rlFk&;Dwhios!N1;mZJiab3D4-GhhA6N&g;
zMuOJHp$8VoOXS+{2yJGM%lk?#_?>ov44e!pc&^$R8s-FTnzjwn#eVHe@Vy=I7Q6$l
zKNT}<p>YsM#YuPyA2N@@7UyaCL4yQxX=CyMbRcvc;{DVZKCw?}Punj?guiBfSR~89
z+S3%s<t#|8#FzIu=f(T;0Yacq0=~~puz#by*ag;}nc^q#j(s4N0P0#@?f?|5yBwx9
z)Y<@1^@UB;1Yh*E*Kr4MpLpAL9D<!Bcev7gFYFZ=$sdDvMkw_0x3Q{LN?%GFq|fCw
z&}z2GJZ$@p_isDfcg^AF0l-`e!jeu<gcep?;0GA65MO&9NOUY{m?z^0-^3Hl8F-*J
zfDHQudyrMQ!8V563%aZbOk@i%<9hPj@FDY1hAKt0DOk5#4aPi4I5~KiuWkFu1H7|6
zGYfW_lPJrZ?GCi_7Er>o&|i8f{gsLEe4YpXbW}U3Z8EkSyN!lse{+aA*0xh@1CR2h
z8l$)`=?(C)%gc^sCt~g|79>bdSHy1MF2s^^O}dGZ4+nbHTgj^}HYAMI6|);~B;xIo
zxjO@X6u!2e9Zq+o`!IprA>lmyk;+P<MEt~aV^w?){KVJB-1=ntv)!RXSc?sZ&ms+(
za3=i6_Zq#)T8;O$WrB)yeW0jgLH#$-4d9an{oLO5(w2P}X!UaT2>S!1mD0ehy8)A`
z!h66Qg4p;=i!nfphG49=KpGi@Ui?Zv2<wTLQUyMpBe7zWl_u(2K!u23YaLh@Dj3%x
zcT!2d_WJmm_5!^nwx>hP`=IQhK)o74CTPxg<VS%bd<35YLKUhCs(3^i2t;Nfd?_!(
zzwx$Qz@}}@K%*u>hgb(6q9f3BRY;hZ!9_~I-ys%jg3zi<u;bR&-_|?m-M}H2LpSs=
zSRj<^jpN26cuR|B9r(O1C$a=^yOOYj_9kPW>`U!I<dG>&5Y8~x=E|F4N6C$qQ3bRh
z4Es7#U@=Q)3&WqQ3M{NKz)?Sgr^s!{5w(H2je`ERNZcV_gr9LW*y)={9Uv#ql@>ya
z+bg{dpS?Y{FUw=Os3Jjc4+pg(w0F8PM_GV&Z36ajN;wDIiTFc5S6X4+kA>EET^$O&
z_e1S#Xhz$#yO0Db=+%JiF9os`2>VSK;Xf(9wr$z53lnQgKXwAN@lS-)!Ubq#j;Hkv
zV4%M!#f>sXHKT{^(@d@PrFgu43s$38AZ>X#4w}yjXsV9wY$9Jzm@bx;ivhu|1{7>1
z_8U-X&bLZJhyEP1+#kDNE`Uc3fL3%EYwcU9B9Jr#`1e)izCtAVBicK*jmp>FPjeG?
z+5*_~QXgntb9nsC24b*5hyl9$K0JHZis@LXzlw>{U}=QyA+=rF4QbR<t^!XG4!&ef
z<d*VS_-@aGhPg~WCZCeeK?Bij>OUA5lGBq;Tgi@*-s&`UHmrM#)xGc|pn$l~fRxq@
zbL3-aX9s~8m4PpPm@&ne277dM+oN!-saQ>IJ695{T#JB(d~I!l)c+0nO~DLb?2g0_
z4AH&lKCnfspjW~AcNNl9QHJm(345q&10@>EOtkk0ZD)4d)}gBGJD?}M*ahI>#P{Va
z`yKlu8_X4fzioG527R~$ZU&_DV;svzgFlvmZK9hn0ll*t`{nKm#bDbec9xdnK6obz
z@K3D|>7<*qTKXD1rm_5`yg}ZDHTh6}iWycx5rE=1Q#vTUlrNPH(7c@<arpbYYMhz~
zEqp%k+<n-!b6H)huLpkM=uSk2ylbeC@WWws_`sZCcD8NHlYuOdT}3~E@A*<IF>iu_
zb%)T6Y@dkr^lA7H_%LKIS$n1@6V5ilu9p(P#fbfDEOv}t0KV;Odwz6<7j+sCgq!>w
zVUAQ(E(O``1KWDH0W`&5$qQ@eJ2tLGR>f{0fuXQMG{tH#F@Al46wK9j0D<lZ<hehP
zfrI)}y$0602~0Jw?Tfk%i1SS#f5am1XUi!%@Q*F98ePGjkitwGV9YY=H;iorYtT{b
z)))+=y&RC4FN6!A_9>ur&t-ol4f<>)=p;L}4%k_?0QP}`MkS!Qtqc!H0mR?O@j6`w
zd$b$Q8037j2m1|Bz;j%FzA#Xe);69`JOY>UzCv!HAodis5ZYp$PRA${d*CIZD|VQ~
zsC}U)--7J&7`n0qf3DiFOFKIUrrI*u8DQ_O9d8$nN#;D8C;HjHKN!pD{8q@_?c|cc
zB#5`eV}+vqY(B9Sey7Lz^E~nSix$bw3rbyYZU#jpHo#i&C-k#@qzRoq&1`0At|vDD
zKCBJ+clhpnEKekXwt_4-kcYq{dLr!8#OvD&9top>Hy(h$@Ch|mdruo~)2dyX<Gnc2
z7-M{BNLCZrN!Gz$g^APL&!#&gvFma&GXc`~Y_1jTza53HKoZNt2KP*iw7E?hJj?3H
z-IX#L72#*wnLoiUgwMdAiDp}vEdg&>BDb^$YUKz2b>f#A#=Q@l*HmtcEz1zEhKGD<
zfmoBbz^m_|@QdwVA&MH%*1lptSVzj)cw0wX)?Wh2?MqlgGNh}L3_4a{i3jH&g8ex`
z@cOQ6`&*4wCqlm54m-dBmDt0^z=B8U^RGaye00Z~sH+hLORKZvke~_;&3@1Thr>&H
z3w+-lp9ZpbX`S`Gb=k)A{it>5no7W-1?)A9f}ZQ_EF?Dc0_-PjH6X_d#(~ID#HV2$
z|2?#o>wG8dtBS$SR6<D!y}u&l6Nz1UmDCCT;xRJuqnr<fmF$_#rx5SgiQw0Bu&xL%
z^;L7jpWU=uRuXc4H@z?B`4Y_ZoA4cbmg#Rj*cbsHRN@o6$M^`AFAdl*Dx2hI`}Ju+
z%v&*=8RE}yoFg+F9v9F+e&jQtCEkZ8WqDAq80-O=B`tvz{H=6e`W^e{a$%j5KJEuw
z-6-V?;J)h>Px!T0hfX~kmeDnkaxY?s>>y~=2lN1VeEkmIoy+2|_6%!)H58U4LYq@v
z{=vz9wjI<HeaO(Fy?<pN);sZx<$&VW238Oc+WaM~OFOW)^$zn3L;S!-L%01B`&yp?
z`wHNB^s))x{7LZN-2rdygZva&ElPruF9WS&l`TqD*mGrd73>X_Vd)~)>t(hz{knM>
zdYqrFgPj68e3c=)uBx&R*k57oGr?QKxh3#cT9@gAdr%}k{uSWM7b*3SOl2uBg!T5W
zmEW}O*wcFqZ4NXF8a-i28<Z(y5*fHFe7B|m)1%fp?X6+k$fIepr=<uy66(PtfygnV
z8J&%WY}e1;;kcZ=%yr^N@b9B#=j^$Y%k~tjV^g3xLVl6Kp5|HD1(6#&YKj378fWh}
z83`{SB6BIQbe+(in7-hQk=9Ji+goG~r1?=#5EZ3M(Y5FgY<{=_@}57F7rN9tz!ziT
z^+LFy7wl8@uv$|gRUcz3!w%n^>%cAJzQFFGbG9}c3>pvxl;~^7?vLOZNcO~jD^$cf
zon>2o{iTY~m;6AN^D1Rv-JK79e_tWHG2Vi-M7)$H10CB2k5dng?2xFZH3GUg1sc<A
za0?IJR}Y5Y(h++Por4h8H{Js>I68A?KR3LfZ8R_&n=P<X31!@8KDTY{HLbU?mt+;B
z0J59pchc^3Kij9c9(YO>Xrn5Vzzl?4;4Jo8^6UUxQ!fQ6cQCgZ7;*r7k(vW@Tf;Yj
z)qNb0l1pMkXyP@oS4hJAUxQsG;h_6-K~b*3t`(xa3#oR6HUhS-A;t=zNIwFlYy!++
zqM1OvZYV0l&-Oz~fOl5_Q=VCl-5h)2<><-1hxt4Weziq_XdJ~F{Dm(Ij}z*i!yi6_
zA43OtcKrs_c8C%KY;6jpGyKXSiX{7i`v4c24Q~p<p%3ESC;T70h+Pq3u*3I*%)1V_
z@Gkhl-Un{j8`kB)K!?eGuWRB>?3pMnm6s~pJM0p$gLDyA%u{)da>kYh6SRK%ng6f3
z^9yaO48!=j$S^5&%izc&R>(AH)D6@2G|5SGYK8?nD3WQAC=nx6iL6M}2pL3(7+eM&
z<|0Ce6#_=qiwcotE=XJ>1}!)=jDW?Jd9;NEDOfOrUTo;^`_k2R^U@1<6Bumdob#UN
zd*A2J8{??>?sk3^k&hJ;NVnLHt3#{!N<?}hF#H2d-7hi|@+f#Md?lZFuX)$K*S&`C
zl>ckaoy*c|d_b?EDBMK%+RHrfH0u7tr0G8-NnZ+HfP-1$4N{D|;KyDu@~EtW>Ae?j
zY=}4Z0w~-ab3E}NUiuR#hNoc2&d}j3itp#-mn8W(=sD~;f|CEd=LDSQ@9aw0M^64R
zp7qazzkwgudD5e#D&HUag2`z=z0Ne;?sx1-cmNIdb-2!RAoSjm$46eElRFO<+VTG%
zXHqzeDt67gGr8vCz8!)$)9{=JW%lS}pYT@Kd{=$r{{4Z|^k<6UBNvx2-h#b8O5*e4
z*hBF8d{K{8@=sn;>aTiE!o*zhtdRS?Ik;!&9vn%%4s3CFQF{)gISCG*hm%;v)$*QS
z!`1N&y^9j!7cKd(gzDA8K~hI$KSsT-YEROqzfG#LpG08_RLE>6g~yp-d|*`7U=|JY
zOPu`s%S=RfqZ#|?)8C|1PmES^26XA0G`@R^xw}e&w`-_l8k-qXV?{WyHcvuDcZ{HO
z7da8zLaB&b6*qmhiWeyYCsxGC+lIMN(c>a$a77YKzcQn{n9W4Cx{NQhJEWq-M)39)
zWd^s)JD|~brDXc1O&_3wcrTMBtm4Y;GTUlQZYff~Ri+LLNPLVdEHZao#m~MEzt4UC
zgK)8jnLKpVO2Hr;qqBMu*5kD;_s_d9^QSpu&oHxo%GCNf8Njdn-!LElNFMGA8rU_a
z*gxsY|MKs_&9`4apx@8dibv3INAywsi2f8?BA%sFe~C=Was3UHly}flPU#<@>3)QR
z<*fdhevbKYk#yGgD5F22kgw9u|Dj)pw^Nc<$z2F7TWFhc`ShGjvpwZ9$aye6IKi|p
z@>j9#{8JLF$_>tJXFC<AP2x!%|Io50zy0^U%;&-#i7_Q)lfP@7+m)QA0Kzt<!$$(H
zJdFaBhr60Z1DeM<UPA?1Lcd?8zwMy?Z8DEp(eNGMog3B6FSlca$(Y6I0FtQIS$h2f
z=v@K}D|A>5CjAyzZjN?1CpXEwS*1$o47!7!pdWQ;0+u|AK9pcKNW)p?(G6#%v!_BL
zLSTZ>jZN734Sey6VKwZA1Fgu757LiXG(q+>YQ%ZVl1AFdf*S?q!V(x<f%|LV25rHz
zn}!m%$+_b8oKs|1PA^GzAq~5ky(7U`X5OjkO`Ikxx=;`PQRx3IE85EhDM_20q37V>
zM6S6abJTS<qBKGDOZ4JxTy`sd^Nwt&Wyhw1ohcTL{wsJ}E_aHVahk3-MOT)AQO)Uj
zxR(M<#VqQ42@mzWzCf>51%2yGNX=d8X%qKGM_<=Bm@YQaO_YEoV8zK{4_IXqF(SBt
ztWC}%**i84?B-3Cl1=&!YB(xd<mo%ZU9_@(Tof*P;h@Y|#hFXeIDray!9{1)V8&V2
z*61K^kkeJAa^UCm3bTJ8F_I!FH$$gfhS{p4v$bJI)|m&y?wJAU9uMK6isGG0;#|ms
z3?($)8ou1N*W?7+1SRa`L*3xCP&lH}pPgZELXmw53!rtA{#I$&lx481Dl?XoAX1F{
z)ik)28P1UlEaG}C({omF2{dtvw7Ir5x`ZwrsD<lON$0yr=4)KzxHbub#psKs!LbZi
zIs=-`F+(nJwRQT_OR)VbT=6>ib^}$upQ|2V_rf8tF36Qn;%|)M(U|7yGbr{m%$sxE
zfdx=dsP>n*3oA?wx3=)~<3t(2nQ#bn4AOf|f{`)q$TUcqVN=2kcV&+HTL3ld-X>d0
z+OS@0+?_6Sn}s~K${liXnrWP5<J_eP9qtqwN{X{1hssu@Hz;$rs&L~?c=0xz_!@k8
z7cShw{sEQU11|VwjRc`^TSiE}PQjq1c$0Flk44y@GJ6E7c+{KJeVdwJ!~NIAMPgwi
zhe}e*MM_Jfw#UhvN64B_QPU~vIY%uQspB#=T%~@SB>&sIgKN}mmwL5Ot17N97s&-J
z5X84RiBCPoTu$A#Y$D#OB($XT1LUbX;R%>0eNdzFmPmCj<Fo8geVh0ftt0jk2NmdM
zmxv!P;{;V0Wm-$%l}S^HdH9CekrKJH3QS^ydTdDtMTeBpCcL7Rs&sgr)TM{)U<m#v
zOl`*T^(C2Fv(#q+XI4od0X5p7N?S0^Cc5zkm8y^ewd2}yQmr1kiV&=1n2L?VyeB!w
zvs7&XPP)XzTcL6rXcR5<2@`E%gFag!L19M+b+QA(L$)IX`xXY>;v|rhpjsBUXo1<X
z1d>(Q=g<IyTHucfZ@YmLQvq}AOq)&;a~^Oe1m_th_a6sel3+^~Tq%GlCGeyImNdYT
z7QP=7{MZ0H6mY{HaF8Q$lOgfL0Zp)pBZ|N2zdBnK)266ARtN8kb8FX&;_Q>S{^jsR
z^!aaxd%ngsX1y-cumw#|#XIl9H?Og;U>vt@#E3ELPt)6EU^-^#aC*)@;oNiMnAdO(
z#7K`O>25OgH)SS?8cbS)Jb@`$BgNAv`T3qJO=Wr&j-~L{d7hR|rJhG=0VlRdZT0e6
zn|PpwH%&N{LY(diX06O%R-WtS!7NBq0BdGJo6^>fhBjxP$b+ezd0cp?Pwqlc_+LVF
z23fe3$)PY>Kn3l-z+Bd1cZpr1YX>x~ffUPBrh{sXQh~En-7=NtkX>t(nlgQ&S~Qtb
zpZAw|rY6tP$+Mg1<nIKmobwZ$>3+`WG>X~;=WL#{b;)qUq$RjVX*O!)(5p+_r8-_m
zll?YIxKH+`igfJ_aBn8LHyLzNaaS62tQ|T-I~nsN8%Q<=T|;hp4J{nt9;Qqs-nXSK
zo1U=Ls!O~v4XMg>z%477wX^fynX>C?zdQThS)T&F1gYdC6<nfn+k#2U@*CycQsFHW
JAOGh+e*<5i>p1`b

literal 0
HcmV?d00001

diff --git a/src/Test.FunctionalTests.BinSkim.Rules/FunctionalTestsData/BA2006.BuildWithSecureTools/Pass/clangcl.pe.c.codeview.pdb b/src/Test.FunctionalTests.BinSkim.Rules/FunctionalTestsData/BA2006.BuildWithSecureTools/Pass/clangcl.pe.c.codeview.pdb
new file mode 100644
index 0000000000000000000000000000000000000000..0f2a2fe5ebe3a6b4a47071d6c124344d6b8c65c4
GIT binary patch
literal 5373952
zcmeFa|9|6C`v2b|R*>Bdx+_+fSXomP*;NEVm+q=nWGNFSOqtp#%7h71re<mtv9iQY
zm@;L;1VNZGMVKPHYNt%r6lIDqL6|Nzx+X@<L_g=f_ecMP&kyhSt!}T!>$;tDu5(@2
zxt{0Cb*_`nHnm-J<rP<5aq;|pPdxO*gAUra>CE5nd*mU99cJ5kuanNKF#r9uqGCHk
z_O(=0EZy_}R8&-K51Ib|(;k@iz_bUZJuvNoX%9?$VA=!I9+>vPv<Id=Fztb95By)^
zfywFrradt2foTs+dtllF(;k@iz_bUZJuvNoX%9?$VA=!I9{7LW1OGRqDgK}T2-5?c
z_Q13Uradt2foTs+dtllF(;k@iz_bUZJuvNoX%GDW?15jJ-}UcfF#X@O2c|tR?SW|z
zOnYG31JfRu_Q13Uradt2foTs+dtllF|L=O>|D+f8vK~6|NMA+8+CwWUTHo2RqS6d^
zxOeCOQQt|{|Iw<+UH(UFMRQ-%p6#T*_n*+#H=&_*$njhRU+gN%RYQ~~=E0YE0@}50
zr~k>fOhQBJsdrt!>;LLIW<sq=<m69<uki$Epr87{v(TDbusbN~{RDX<vuW>GNqPJx
z%BfwE-}M-DWSsiSN$gGBsro+jb^bto{W8kV68Zwahc7>$_NGIrk5vBXf8(f`i(FR>
z8h;Xg$A{QstD`)A5Hz*~zVPp9@B9ztSRZ9e1Jsd`J)&)IpttRO<Wv>l%e@W_t%Y{x
zkQc3_?Ai}Hu`l-aM`?G;{)R^6*{*^wxPbP?JE*tF?!*%O68i&k64y~~I|{pePtiaA
zIQ{)AvA?#P@_>tW-wNa=&!O!8f_B>>ln4JtIlqPeHDSubZ$j-=@KrTKUH#C|f!O2N
z3T>7@!&TU8`=#t%CHX`28`t+L{Ruv&9s4>@q#Rg6*`syQpnfI!J+67(umO1koyafW
zf<Es*sBgZM@pL`|?cEKz#bcrQ8R*L$2Y=-ZX!vs42j8Jz-)hxwqg*@>I`#;3_yF2V
zds1$^i2jxDQ9pVRdde@#&U>-bqwm*yD*S=>=->Z1{d_M<&kgh&xC5F9(>_$9JUj-?
zR8T*1E&ZZbp*PWie9ObMTRWh!QTRMsA5C{q-}O^y^`o@A??is{Ytp|na@{|M2A9E?
zh|;hBEy{)K;h)etwOxQ6!9Hl~lkhuz(B6ZouhsYmpJkpmO+ek7p{YxdYxl$7eLi;h
z|47*xr+xehsP!M%Q@M?D=}pQVT9@uU>1W>_Igb6YC-WZs%}3MjPV?RB-h$70CGB0O
z!C(0^X!JAWcWHh)BJ{7_gMO7g@QoZn{X`pb`a)3qF0?l^(O#)_JD#P#rHl6biL?hk
zp<m%7>Jweq>3oRxL@VtRqHe91cqeuaw?gX<Mt<8G=unNyvyj&pM}A5AQlBB$GEBSo
zZsb_cfjSq{KK32ukr>qT4fXM5*k^r|{?<$RzLiViYtr`%><nLVJM{Mt(LW+RrSm8U
z=0Usffq(3HXw53dk@+Vy@G)|#AAmn}A=G}8^p8@u{Y&*fr(f|o@t=#m`4!k{NkB8*
z$SugerqAJb={)Lw9{K5ysrPFCnD~r-&OgxZ()X=A3Hu#yBj0fpw62Bzwy&`(doSg<
z_WkBn$O}9Tb!eX{X`e|y34iE9<T;;UJaxOl-|vPF{}`H2L&K+`FFq66dZp~MQ7&8$
zU)SHMA3un4<9hV@_GNt4ve%JB|JZG`mw!vYo~x-Jx|sUR8OV>eQ=k2oddDbsH)`I;
zPeh;P0OYjj{2OVb-^4=NTa&cs?btIKqCKYl-kpRmlSR+iU*I2D3xBufdHitd9hbuA
z(z(<o|9Z6_1~qS6-oxJV2T-flQBdcP_jT+@YCcq5!MKAjAwOA%T{YT2<8|=+R$*8F
zkC0oG-F-J`93Rl%^BVl|2JEgmmG-e&v|H!U-l_Pne>dcLSHS1E7QVrH`Um$xZ&>?Y
zR_9FpHSmoo4y>Dn+_L;)OVQsNhepnpKW;_O=wGRy5VhV$*(qAPD|}swvpb%mJ+%+C
zU2%0v=Uu(xiLN#D>(_j?4q|7G{9CL2bo_DTbjiMy;_v)x^bcrVk0`FHejNL|H4lbI
z@k{a$>igZ$qWtfA8ol{l&{IE2xvP)w-L3gQru{p9G<w_Lg0E8Nb>;!;dwP%`I9GPB
zgj$x;K5!ZSAHALWvS^?D<{6~DHbi^Phm@U)Ycq-$Mqj1AH-#OwT8}Q>TiTyy+&xDy
zj$VBSe-HhV-O%<&uq(3`IgR?xEutNwQPHGmMl|p;{o?<GrmWbVRa_SM3-#k0(N{H}
za>xsxV-xnZ{at*Dn>vn$KcB+B+*7nSYyTM3xe{ARy>&7C*0Yi4EK=Y2J@qZ39ipRJ
zUx8cU>pCC4%<kwLlHckyKIg^Q8~FkLajm1;XXrQ4OMStO{@AYYr_ZL{FFQ-$!B?$$
z)xVK)<X!Y;b-vf{$2@9uLE{UMSF?`ti0&^At-C}&ax8y>FZ>g}zwejG9n*Q<*ef~m
zWA0<@>v)j*yw>SJ7<s)K-@tCPmmSav?Hk$mrC0HA{4w<TMbo<9c(gAyIcN_lUWw_P
zcHMv-mYWz~^fLU|`V(la;<LEogxKfQmwrRP<WBUP(0Szk5$(OdrrqJAy+`}`h}KER
z_t@{&`QEF0LQL^y@e}%2E3UMj%J`F7m#Hh|U&TEQS0FDp7e1TTbwT&c$a>_BD=w~F
z2Y>4r_2s#;cRltu>Aa{t6g@%N862Qrr|$LM4$A3S=xx$D?*FIcZ5Gu%CjTgWZq0`_
z#T!HK;-{d#e@XGEdq3=PzK9*o4N%8-%rl4j2Q|O_i?ApA2DDA{C8oGKx(EHehtWUx
zDtwj0=&>xtj?e<^&fI{#p*PfTFZdD{(J!X>X#5iRd-jB{uNvB^du{)2^vnGXKFcqW
z8(T|xOz~~s7UbF=puIK$jp!aeEP06tc2@os{^DwAG$A`Lq~EZ<Yw>N>YrQ*OpnqJn
zW;NwLQO^M7jA-MFl!rxoHeq-7f1uei`ZJ0X+{z32^60JBJgU(?*7Jnyd!BwBx+kV~
z#7|XIac2{HTWX+=YtdJ&{7w7-%B8(&AF-jYUvYnv)=P02dJ?xolgfkDD$X6#zR~8!
zuA=fABY#A0^e529dui|2zT!Qe`h@%(()WyAfS&m4(3JLv#C`Plo(E0Nkv)A-&l%XC
zdKW+Vc8B(AKZ;yL`>4*}e$B&@=11OvKl-1-E{E=q$=j*#nn`_D_mAK&k>5N|e)~Io
zqZQN_{)=5%#m#wrZ_5hm^Yh?~DPDHH%eo5c{$8UvvwIzU9r9D;TE_3b27AhD(eHdn
zRPlVvF_h~x-oZS2dlh$e9*Mrzd$D^+@mkA`$PXz_>s5T+{TThnzDIB4E%d8W+}-G+
zUrhUIwdQB%F4#YD9<=`^<dn{(|40lw16M<bRqy)??XeN~L-$k8o(G@*Bg&~ww8vYi
zAGD&US@%s}7wv=EKWo0BU!U@0T{>49-=u$s;;rJJ;p^E-f4lTHKLKAz^SGq%)ijRY
zQJu>*7f=o<&WQEmx0WsRcifEsyBg5byc9i+;tyBj&&n5QPx_(5bCBDmd`P|GlnLdX
zy2RHw1NljvN49(DU(|V7*7s`pqsE=3-LHM7Qs<xdUFw^4{*5c|)Vn?Xth=J8UguAv
z&Wq-A7;l&6Lvd>UD1LYAJQ-Jhdr1E78<RcTprcRXm%bes_t1Q3rQ+7&mFOQo7XI+n
z@aOlX+^6$8`zZDGTAwYe>F1vb-?+{L`(4=GJ<hmW@1Z<8O4;GzyL21}O)DQ6*8FOH
z2t5M<_%q*NZ`-%fX3fuZlg8IUy+`-2UiqPOgX~qjUv)M5I{ozP{4?zh%8x{6&_4bM
zG`5fQx4~DdxVi8-{oSuan`OuNgYd`SV!WmK(1h-N$s*;x>yYoQq<>O*M6b?ihm(4r
z;>$tJul9M^QR$(*t`<6=ds(0M8}CN!=uuo0ls_5<_+HtUph?{~lW!r%^)Pmg=p1xj
zhn%v`ooeOL$CbB9eL=q}`8Te4R{tpdhLxZ7Ppuo}gIvn@yPkqCGRgNF`I2%}d9Ac)
z#~9-d??-#p5PBn;k6qfgn{{99(s!x620pv;p@n@Y51j*zeu&)MMaZ@3TnuRcN&bLc
zzDmBEtp)ypJ1D!v@6kH4>)zL<bJO_@{CVx)WyLAY2hcw!yT<pTTz@0_Mn9!rpYF*G
z`hF9;@!c8^$KKE?`sH=+4&F+ALHD9g#T)I~e+RCieN1s|xAyNE?Z?(p{E|Cg{?T|#
z+V2aqvCDN8^CWRF_IN%;ZbbK_#KH6*%R-$O(_W=>rdRP`R(aOO?-+;e7sz#s+BJU5
zuc*)83iT<j9=ja*b&4PAlou)~U)tuxpIMzpt*>H-OL+;;GxTrU3BFF<v+@U`XISqo
z(LYjd)BZFl{{D6J4=G+uoC06{{ZNO#TSW1;<qGP@_JFz`z@GXfbR<Z<UvX8n&h1o8
ze%E{r?2O-s6^Aw{9*!xWP}KWm_<H0`=v<7?LQdo9*qynX_Qn~M?VmtBx{uh-;JZ{F
zuW_EJ`KIwW6(7WPPUMvLjQ$e)Tu$hi?(Kf%<zmWr#q>@ysCa9lh#v}Tpc#GFwC;)H
znny*&U!i|7p7HOnuTFj#dY^Ky^4N{?W9@sA`#WfD8a~&z*x90UEfv5oV~c6;z8rpw
z>YLlqn~?s}74U`EQ(u1<wC!i~tJ1#a(){z=nQw`A;S29a|2plTO}bBIG~SV~kkdN{
zzQR?MhccAglurrh{xf(T_Lp@J9{U<S{TIXEcNJx;@&&`2DaXI3-LHAn*NL3LpJ8wG
zGRgz`p1tZHQXCo4xfxO%QKNN~z7zR<8b?BLd_wQ9T{iSKO7DQ~k%P+Pj4D5vRa{Yb
z4Bu-=a^pIG2Jb<SSNE^sX8h#Q`R&!baUIM!GFL)tl^6Fa|KEK9_E;5PITj(OT5)$_
zHs!d+XWtJ0)TQX>U7+#)6gw>k(B9I|`e{<0rC#~p(Ib#&k3(yU^c&QA=}b`X?M42;
zJIHT&g|hok(7-9u|2t@_&dJO>=udA!&X~@D)(!C4HtPF6NqfW3#dj%sQrh2pw4Zlq
zKPhWpj@Kh+NZ&8>Ys!H)kn6sma#816RB>qKBgpU8{uX+ea^+oom&B3uD=RKb>0EEW
znfl;~Q0r8_J%xX3w0}77rM<9|zH=V=onKQw@V3Tx8tqxl$EFKuFDecg(>a;eJ*P|e
zoQUqtma`aV+fID9n$w~EpW(-p;@L{Q>$k^|U$6BRmtQK^Q$MkRejPsSs*F&!YX2Vn
z7(R>M+gf`VN6QTCD4vEN{J()O@H@&Q+V9=U_YOQyefzWUMHPQ`?n1do?`ZjNDUUx7
zZTdC+3Jz$!)^oeg?dFZ}CAIFV6gT%QqCTwmF01mv;cv0ORqu@XcNy<QkowxY(bFbs
ze~I?&f05^L;-}m^XevT||J~3I3pB3xf|eKMFP-nriU-5Be7B(ZMs?q8TaJF8$|3nN
zs`rZKsd=P)*|6dz&!^}eIS;$6TF(XLwLMxV?eD-hbUAiahoJH0vj0cWPVHNL+Fx8{
z>`hHVJq7$y`5M%gqhDM!s&mDq-=&N{4PTGmYn(e{XG!~eSbP(DCuvsP*Bzr@b*H}n
zFlF}~`q!TiEk7i_hoRZewNBoloKoJ!do=c!AE#e~?g#C<e^lNDe_#%@*TJ~@uY-;s
zKz;Ej<X39`wQrL@Ux2Sm^WLF-%GM&e2htwi8~r2NpR&5Ywv8Y+^EcY<@<;JT`gxo2
zL-z;h^UsIY=^PxZp<nn5^cA!ZHOcQO`7P6eo|4AZxDxr9OX%mAMY%!wo{XJxPWz=}
zoN~MFvmWKYyO&{K)y2q9>E6^{3xD7M{NJc}BX}qEJ)$=GC9QjVUirIG#jR!CQ(F|T
zrz4CvqkCfHRphn&7(Lym(q1|fTKpb=bqzr~zk&L?X>b0Ba$IrFsP_HXGU@|AMgEY+
zo%w)rv*vwSag6&)#@}%z?ZE}m{8iW$x)*sJx8d*ZS(HcafUj-`><Lxi&)^I6tJimJ
zRer;tp`RrNe_Hv`CdJXEv#Gah-*->huX$5^75&~UG@-bve<gBjG!I+!yNTjT?5R{<
zq(*tE)~(cc{S1ALM>Br^HPEKH$RAjU+>HF}(R|8OG44@~XGn2KK>K6ej<kDqPxt=_
zJqgip1o^FBO7G+7X}Scy?jxzs{|Y*)c|M`vMOCNiAJe-?Yc=JN?hW4C(I3!#EBz+p
z%^gO4<t^wdXg+jkK8%fM+>P*+^uE*n66I>e<?X8|C!T{^buKp^f&HDjPox&oKKeTP
zobqc%=h?(x(O0W`defcQIkX*eLdt)obM&ulqdud3t6letA<dVh=J~kt>OFebvGvl=
zukSgccihDO=r1i|z83u0n?8m5_9p0r&gI<Ql-(D@H|C?CPw`IY3)tDXjd8U6h4#uM
z{Nr<Iw<y0FkpH@NqCHboyX*`oe)29r&amcJznAfNcBY?o4zxx0+VL~7b5Q4Ewem2D
zKdavZ@Vjn6UqF5x-9~+v?%U~F<aBkRzr6`MuKC@h__C<`u}^u7ZhiO6lgKOS+;HB3
z{#wPe{lAsn4>Hel`p$LoXZ%a-8|a7Tve;90(XaUn>cfiTJw@8>_hM&op~kxnzRCsY
z=~AAg=`reqyTD&}m*nbwA*%anaBu1pzee7e_8HHI)HfZE-h3zW8ubo4rhGyFQ`E<l
z_iPR^Kb#k6T~5&;^7_=jP4_b2RmhLX-(j66<y{%igyQQu2j!NlrO$@^Yyi6hQ}Nj+
zwCA<&H!6<mz6||EeJ57{zL7fQ6!klcj{A_;t@#%mfiJB6p{Vn$^KJS$G;eE^H;8E+
z^l85tn!1PRe%@S*{Hh7Y-Fgpp)xJ)-ZmquKxzu+k4r+OfezrB#yMIEtUH9?!rQ+|A
zJmsCL9>o5j_Qk>9)2~+bLl*S<v|c=q(ch_k$8{C`L;Ag)?<~gcStGfd#9v^ZWi_tw
zCd#${MSdU$4L=NjI8FbIes2<u!teemd|Ab%v7f=;s(s42jD97pgWNNe69?nBu|ecG
zo~6D~_nO3J+N(~cz2zb3&`N0L-{>u9e%4=1|IuskSA2;6<Bjm8-=m*z9n?M-z5yrp
zx^*t3PN05F`*i*`%B3XogEt|s?sV$?x;HfF+-Q`(p0)VBQ}>Q&5By=}zsie|=lUx&
zs=U^SekVJ;1U*$7p_Sd(U3DA$eYYUb{V25KCyXP}3SYJMJ-g;fTO0mpRQ%Lf4gawA
zk-$32w%<UjG@ij<qrV`3_E(@Usd;NxyjS}X{nGkfY(s>8ZOT75v>r-N&_DPj)S~#>
z-bXolFSP$SXhh?$QT*1v9pmd%ex_1!S$fKkhhj&s_S=m1>3A5wRklK_^Vrv;bsKt>
z`uNM#=S1Clp9-uIzrJrm`JL3R=nFrOe?3$C#YNcf9H*b-M&viu!q>5waYUM-L!Tq3
zqYVGx-qeq*gg+IdzWi(WI`#c*+Ls;LM_aYtCUpK6j=~PxTj(ED-ru(ya{4Z(y|RyT
z!$0BcdYJj!avt?nm!jXM{DN2as<BJN_c!>Ob-p(#-<G%zd7awFhKthk3H@AphY4N^
zpZ#I%N&kg%{zv#Bq4T0s=X<;Ie3?zii7AdxDbHD_^$|T5dHtG4qxYh}=NI@jx0(L6
z^BG^Ge(#(8fU^4zX!}0&b1J^^--CVQ%5SzQui((R>rtFuRVn>fqtB)FRutcu;>6aa
zjMLeH9``Er_N_)wR`=gNt^Y3V&%ve0cWb`)$c|CnV+Qs22!r~5UAmtK&Y@pYzl&&T
z!4EdQ`_w3(Y}0;Mt^Ac=_u}|0#xpn*dn=ET9ipu}P~UMR<0wmSQt@u|GkxzdXq|q4
zmV1kSfhh7Cm4C7*4(iRR-)Hbu9}VrUf#0GyularWT%SX&+E;wDDEBE|7}kE(^bm5|
zRIVO?uVYu_4*i?)wx7*-CQhQ>cP?eO?#qe&s1GlvzFzMS18XVA^d8hR8-GVH=DS<8
zZ{<FRFaK-wjmz&NozfSiy-#_9ewE|;eQ{*!U3fnHty-@Z&GVf0(XigfT*^nac^H54
z=TNWy9%<-G^yRcq4?jYCQF-X>IOA~Z-q5J^>(Tz|xg9%d6h|~~&v;vuH+1cVyw<66
zs7-#?cMV-k|Ag{Q5uMB3+P`d{;itw1_#DbtRqjpw*zVMqlox22P1&RPu}AT9Up01x
zpQfM3&$!2wfAw65T|Eb2Z@vpT<=NEN>fV|WO>1Ay${&pv!IxKlF?<MeQjbv|dk8<~
zwZHoxpuTMw8u}CbA>|Ju%GdVk_raZ0`7-5Ylbf->?o;FrDlV?w8@mUNL*B6R(|If7
zZ%Wax<0JfFRi0w-E94{;FLqsuoYd*a@%|g?(tZ`*g5BP?k(bgt#(02oR_8_M?&wXN
zhrF=`$gygER!#Zix7g!QyzA0CUT>cIKE)Re+W)+|cjWZDjcUEyd9|L~&p=;7>ptIt
zz0pUoZ$PwOzguxVf}N>Hp@q+&?PJjLYxKA4-MFAQzhCptekl5i9q=_Dt8pGkz4tu)
zTi!-{Li5wA^Lykc@Ok!vhIAio*7-8##}7&Ed+9%l?`-UIWoR!e&P(V#@G5^&^ECDp
z4`=)}??ZFie+$aL_xu<;>*vw#SNsz_4EeQT^bWSs?p6M<R`Ecq_K`+?uNviRs+BKy
zXgyh#A1IuKoV5Jv*Shpi<&*V}mQ|eHHv|2J8ph+$??ya-rrfH1Wb8oXHeZ3iI~A{`
zl^;xMU-!4d=jnlF72mmZ&xtF(tkZi%;g9$sJ9VF&8h-&jmRZ;_xQz19;n>@(IC?<m
zVN~aDx)S~Y<vWL#BfmlMYF6>DP46B}dXEYmgxmrB&bM$G_J^*e|A<ZVSnDCD_&EF>
z`l>YEfiCQHPSSt$0_3`N&e%fmM~cV|Dt^qI48LFbXus|e-SR_B^UJSu*pftUoei2(
z{;};F<PYiIFuEgl+jJf_$R6J-=<E9dd+pk1e9ur{vkW=yA?%E6y$>%(pI7pn9mua7
zgWon6c>|9?M-(TI9l<)7_%roM{XTHCoqnN<prc1YON-zu$=->7P%bE59#;G48}JA8
z`xxJ8*kjecF{Jxrd@=ne($FsDWqtQi?ofNzRJ^G14=WDJy(53^2pu1STD7l51B@^D
zHTuW?L%DKC?6d0r5t04QI_f*_gx_IDUccsd^a}bnD-W7q24A)QUS;@I%5lA0k11d2
zS6u7bBE5~`)9==5?$J1uUv4{&a^u7Bbts?O*GIWs^TIPsc|h;SX~moI_o;V`;>YM*
z^hR%@zDxBj&CDae?!#>r@Wt+DoTaJ1r}zc)t6gzG>)r5q_5F)Y$mu%<zQiujq|R%X
z_MblOr-g-#uTAl$S8+nUes}Cr{62B2?0JH5)G2?MPNC2795nn0)OrIny$G7r{Um<^
za{83d4MvdHuXl%b-K#7Y;h%=j8Gqz%_?p*YZ<FrbgTG^Zxk>mM6tDGNgP!((!9S$G
zuNb<X`tBw4bLsa3ZQAck8_*Nng1n^Sf}-*|F}*`4@4&vspCI3^zlW>(HRE+CpI+2G
zb3pgWxb9;uhtR)204?kR^{hjGx8`Z&$NGLDs9X0B?|Y1+PWyXqCFNoV_6+Z@e#+-G
zYy3%_r}oFulb2mi*%?vZWB57bm9!5!1||1d>brFRuTdNp(fzhl`S;-V=&#oPV$*&!
zvOWEy8}U=@apXodFUIz#eoXsb{<rugc7$jdyC?Mbn-S%StCerJ>-Q&4<v)tL|0PxK
z)IBz#yr6Xr@`|F?+f`P+d{psVR`G~^KK53f&p7JeXP(5})LV5vTXpYhQT$~44gPRu
zk)O~ztml2k+oW;%HE%mVV7!)(puN5Hvp<2}z|?yF1?BL~w3n2pjZ9K+*S)J&{Nu~8
zqfYsTD#ZhqFX$h5n0~g8pxtfIyzZGLoqzE^GG6aI`t>M35uVCFSQuB!k?4zk3cr6b
zwEGy^+hWMC)4tNJ`(fK6_@c_c*q^67sIvDa`W3FlKV{8xpXNc;8Pqq)z7fsSwD$RW
z?ek@QAD`lf9>ss%iXRKQ&*o0oIKE=M?rX5es&(7*GxS-nrM*|{zf1dVi@tyTLhSCa
zLUaAd$!a|(ZlQmN-d74C%ES6SOPBWZfcDFX&Z+T>;cIypnw*dP!7b2$`o(k~=+VD_
zFn$m7H+?qWBdWY<o#N`a-myK(kEOJZo3xJI=cCX5B>wS>hDDPnp}+Mt#@Tr#{C?%_
zyA+36o~C|8^PpMtv{U!(p{abq3FwJv9}G_2XB0oXl_$!~=X(UMfez?9S1I3=)qYym
zeW&3O<fdikz;E!&*l(%NYrk{JuJkbDs(T8*H7G8rR9qZBpZ@(iuLf7hPd`Uq<5K#^
ze+pmEW6=C()ORS}4>eHkRQx?GYCRY^ImP3RTj48fzJ^v%?t2cs?b-*cln?2bpVCLb
zH_{IcYP?mtZ~GMY1+GP3Mt@h8*1pqtA@U~_PxP*$+@gJd{BGnHbp90ed(f2bM`iu)
zU_kT5cLRF*v@cZayW8GGj_*6<r-JZVls_5@^PSsvVxGB|sI0iZ@(0Qt8h<%Lxp!Ci
z{W;2+&!Np1P+w5Kp<4H}w)?Qdt$lVt`(ar5fc(|8PrQko@EWL3_mqgn<<mYgG!^f<
z;miGs{v#H~*ZC#oI^~z0FTxjU#}9!&U}tt4^Duur?LGHFE0a*4)^AqvfkW$M@VCsn
zff9NK^#0jbpj^~G)2=wkq2HAhr@r58_!5c}My^9&)t=ZD7@@sh>u;={a<%rA@kbd)
z=XumyeDp6XE-WfOZr1M#T7Q6VK>LS9d8)v#sc$|7zeTTuI;1ynI^~G|J~OR+PLtxz
z#Cg~;tb1I?&hQr(Avd6VZF(wB(LOuWLVHH<+mU}Gr$PA>+rMaUc?3WAX+C!=4ouw2
zcpI$vD=s;sWy-@RVTUaSUqth=`wiN2n%7>fb8iLux^<op-%7bw_mR2}k(1Sami-WW
zow`qZ9ztL5M)>-qzjcUmUgul(Ey~TGVMqIV#@D3z+Vd20M;<_4sTaPo=5KGDcK2o2
z7kdXfbOLe*XF=N)-z61K)%DXabU*Et?@+dAUip=u$!Xp<zrwnRoQnRIdh8iqMSV_r
zF-HyUL;B94Hu&ndB0sA0en9(iz3vfq?W?)<8i)MfrhUF6DZd1e(`Tn#r+f2+&f9A3
zlYumH90x!H%c0$8LPr%hcYT5VzGJbocs{gKa?1K$Z`*FvXS6Q|rt*LbsSoNrb1JTi
z{#<&MmmU5O<srpyHtiqPXXCF}C*w*fUKy=oeEB`0R^<`eXTdkojl41GY1FzM=;eDh
zEQdxffVwV(wrSp#r~IBmo>%9AMfZ<@=27GKw2vv?3o71oEkJ+IIgG!oJh(;g(Ur=B
zhTQnKU-Peg2K+9c{8^^G{rC96qIo%?xVt$^d*~Estp&X;|AmGX$9NUrjQgnXItjmd
zFQpuR41JcF$Z<VIx&K^fO!>x|OYqacWzf+Z=%07duU_A=YL4VhomT<c!;&|kI6tRx
zIu++R9)qu=A3BtP20Ee5x)%*JQXXzbkMkAma4P>athlIiCiR&tG^sebCc}5DY1KG&
zZZ_(7rM1ehb@$=-<{zLry%)t^M4syd{Fv3cbLjq5oR9qC5@?&^&sLR(=2G9S_ql4F
zUzr23r&Iamat^(X+ULAC(_X84bx85#&|TOwI3-{Ch@94C&4IK>zQx`V#f8l=?C|LR
zUptlW&^uPG_QT%o<iGQ^Udr?v*SS|EJEB*@S3h-b>HP4{q299_<EfXwNB_ll^lQDe
z-G$tk&W$GJRf9$9>-0M~_Xo&p*ZtA^JmtoE#uu55pWOO)(Y)Gs`tPGXtvq`~aboE(
z_`7wF3{TDL=djm0j{dyfznYc54C?n0i6QjY&47PQzw;T`i*o7|+Q)QGjQt6Hp-Yh4
zFttyfM}0<lwo;CEi}nex_VKaH;j2C#T7Lxcn~uYug=3+EM^ay117BYEiQWP1s=fpH
z<%Q75$I#Zr^h>`)c}VN3O6OFo&Z(%*soX{I`#YgEl2=fEt@$(j9?(2-ZiH`Kae>{3
zz3B?=!y5nK1L*J7eXddQT1N9_{3XWGqJ6kh|DHrx`>-WJ|NLF>`G11ml76=o*pYHp
z?{wXY-<m##->JOx=xNv&eH(d^BK-!duy;)N-Ks9y{d?o@QV2e$=3B`Re^mQ?dOdo=
z=fF3h^Tw$>Tch%&Vg0V8Me8o8{lNVo{aUU@pGEPi>pkoUTt~Y{{p$3+M-|WH^xi$L
zcawhQC)y=9q50ptJ>#!`0ecgA2M=gIjjuzWQ}_IU{{Eq?_|kR&{aO{LMg}Q|lt&+b
zmj1QculxPjZNDGBfyWu2ReyKr79H4&`hsY5HvMX!q@P3g-J<r9<g>I-XuS=-hTirk
z;P>kH3^sk|Ch3hmNPALw(0+}tCPDp#?xD3uA-`%4a$BCEToZ-Qxs~r<e<$Te#S@;*
z@Hgo1WBQj<F8>C8%TzvWCjG3R(O#{0tLpFJi|Kop&O&dG@(x{!+v4{~?oG5iKcMVW
z+|Z=^U}YoiVVx`0+83;!pg*TPw0j5iX5NM0U&TDBRbC-~uJp7*+Z9(e_E7G93YvZz
z8tjK!^_{$mdn@0e-u5xnza8JbVJB$sA<$9n--QOsF5T05&ZO);3tCoO=9@*iH2@uy
zp9(rZI$Ef=DgTk0OL;(XyYo`YsjHyYze7u+Bg+4`D*xT7JVaUfw6SmSe{z&@CA5##
zucAJ4E%NfB(W$&bn0Bw`S-<v~sJ^>(XXG`1$@l6Wfj^j{KD?Rwq}J!q;e5xGpMBc?
zD&Mi;I{Fp%qM!32%2w?^8J*|lKH8)Ir9E>pa#Hu9r{-A7E!Wc?)Bc|N7kcYngIe@{
z+_!*!{cj>SaxneJ>nOYRcMYz6sdp_FeV2ZNidQPXlHK|{mY$E`>(%-RY2Kv{rC&hj
zL`nN__95yEq7C|ck)-aM)}@SRRQ}CtpKMcJ)UEf(xXz>QYvFHK{F|7{qaTjH!+XpA
zUHI;WjqsO_!#|07X!rY!tEhb7#MO+;@f`K_%4g(%hn)0T$RAW*!lwN!T!}oJ-o@=&
z@3AV$IS87$6}uWFKcsc%R=n4>0r`Ht>+~vqF3SJj)wElmL7(pl%6)pzt4UJ!{1rNO
z3)HSSA^tResM7h}btdg~$`hyBX?H4*kkR?oraWa_^D4UlKG(h)pYnlC%7?q&pgo;o
zyl&-XQd8%{BeXjT_`6<oME!$1;_nXaA3br(fh$yhD>SF~z(JkAv3=F9eWAsRec@xU
z!+IflW7j}yv@Ql!@BbKk++p|ws_)l17k5#gbRjqNOUjo0_#U0Q4>?yNKj*}rh~nb3
z@+S?tXV;I?zxP+jYfwCz{4e#1_n=ieZ!%g}Ef*s{v_1XC^_~+QgTH5u+Rv3g)==Mh
z1pIxoDUT>GnAZJoK=ItTzEjO*$Vuw&P_1{;zw>g&JJd;gX(Kdv0dkXyD{>b6SyDWe
zJsW$vwBKbT@DIw~{!!**Sm%6P_N0G9zr1K%<7)a1{rmKLtMXx#^NN3Zzr|krtJpW7
z`8}`_KEHlvR8%|`Qrza#y>VRc4wl!kt1tl#%|%{$HS#;;|D=BJ9n-xkrFB=(IpR?s
z&7=J*k;Oj=<(KM8$ZOSii9Cg$Yx<#8TcD*A;p@H$JE|0yc|we<SHHI!Igj?3=5b!*
zYnr-O>HgGq4&$28e(ZTv<GO(UrGxRmU;a$UKedn1UQk?JeK&G?+p)7l?`1_hc6Cg`
zAJ96;Xx|@DzM}dW`S&4c<R)nHSbf(gu%mD!_IY(5>(V~kq&!KN=8^w)^o{6#Y14h7
ztUPe3oA$8oH=PIZJsgV5{aa<XXpd-GbX2rk_kl63*QoqDcm{SR<xhvszr;n<+mxqs
z=p8M6H}>=?FWaHNw{jf@e^(NF26X<{dnnuQr(a5Ouv_K8TH4*(Z+xnc4^v;K-vI_y
z-@6JuQQg=2M0<Y)|FFu1ci@{)IjT6j>)-fqME8({)?rL>>{t`u&v_a&vM+LdFC)*d
zcr5xo^?jnlq7$Na`MpZNzbfi?cu|d`QTdQQmGiG7FZ~DX%bo%){usRtdqS(^_xL}U
zcTt_sW$nA2t@zoedu->R_^il_?h5VGJ#kR^rBTJ34Y$(2NAcCrdivKZU+mL9-0*wq
zb0<MNv~N^j$vDP!{*Ub-eOeb|Y1#|Qi}osRiJZ##S{3JpuE36lZtBA~(634Ju~z#-
zLV2^={rO%w#YsWMKk0waKdE@Q_;>6XQ#@GzApP8$A3o8bXjJ*qVST58=do)-<?g>A
z->31|)o)nmYwQgCQ>FL2-nZFzCXU1o+wbT<`d|2lKY@li(9?Ju?Xf$svrq2|HB)h?
z;%BekySko$zeV?q+B{{;2B=kWUe)iBSNa+Cy-T14#R+-ksbk9fS@n(=Q(o4y1^asI
zu(z{Bd06LM@&~?`Pw}T;-^H$ZSF3XS4d`|0-j*AppF{b<(W_{;e}w#`@($fM;y>3^
ze(na^Ck}zXQtxfyi>UX>zTOn$PS2*^rF+q^;?~5GjHmSo=;)2`*D4<FkUu75U+eAI
z8<<31!-vqQ&hf#g)UNyFgyNrOJ9f4#WE}l<%!^vZlNtRzUXv5PZqek_IjMcvskkTG
zh@6<_XGcGFjO(4SRp<VM+UvaVXV*x+?$MdUsW0n1vuOYAdxvpUYQ5GepU|uG+^c=3
zQNN!UPr=`#_ms-1@1yt3`X|vdd^h^7A7gL5;#S`b{O+%(y=EK!8B@HRp9lYl-f?Zp
zpQN?lj))d??%8^=r=Z_C2Cc|%(S68uH0AaV=z#Ktqvv90t-gC&^CzkKRJjxO^}K-m
zVZF21G%sy;VrQ4~#T|+>>lKgIDvqtX4!({V$m`HL$^Q|1%D<$(J3`s>t;VnOFr)lJ
z&B5@s-wN&5c~;c-k1Bo&=w8~S`;u=4;~Y|a@6);r2N;+0P1b{>54}xyVn@7|em&2i
zuSN4ewVHl?w@_bq0sTBq_??<hby4aYbbqR>rQf*nE)y~OH|yRz(gA<sdT5p2ahi70
zdi^*2W4iyP_Mq(E2WruMyBx*--~sfD{{p?CN$8NiPfYP^r{dqF&Wmh<{<*F6_sE`<
z;<)zxs4s2LczxPGYl51``o7MeW0y_$*Zl632UITVybE+-SGCqt|FQ73=^ZKc3+%DV
zU)A@*@0pK&>w5e(5|Q8JcUysSP<gvS<-xjjegtpC-Ui)UZ7Igp{w#FlVQ6;`G_G^m
z_X%?CugR~k(OxZo^gV}MzwX5Y+809CX&jfpZ(C3Q9{ICD@1bp?o%;JhOAdWQPWW3i
zu89kgQ?K*BW*9z)_RrzZC^udXO*`PP)ZcxNYn``hAGGTo-1Qaw;Vd+z^<=w@@8Wm?
zIf?xlr$zHU>7#vcEB!LcZ+H%bzpVJ7U-6e~1^yUOTojKpzOw#4w|EWTcR>HHReCOR
zA`7T*>VT%MhuZ!EZNC{>bsIFi9eSEIo`TlXgyxOghTSE_WeM%8&Rywe(K~Hk`?pJR
zea%YjN&gBzcxEx~LFKnwbzkUK+|b}hPxn%2v<KRtyh`vY`o|PUrmN6DJ`cZymr?Fh
z+#G+E`f8mUgSyu^b^mF&8~%3P`}_3oFcozkb!r}my~uH$01ZvW$>&qHYd`L}h4SFf
zkXxno<X0ZgwwdvGl!vGkwLHhT+H{{E)$eWEb#5heo+N&te@3*R{72Ob^dA_*-$A`+
zB=sHB4^Th6mHrdTLt3w(+&Do0p|7!jWES=ItLazxi24?-m(FKZeocJypqV}4_ukID
zvc3mja3k#r`PriRRQV(P<hlm^ju!abdf&5XAFIq$pWF>vuiqJrUW=ZV5opb&$O-G7
zmeBi7_$~T1Y5ue*&Z^QoX7Ja{&+516?^`eaudu&I@t#A!SM+NAI}V4>se47g=1X4-
za;*A3fkTi}(mv3B5Pm9O316%3e{Fh48QllJL{EgK6t740&e3)$_15{&qT-h7i;<Vn
zebI6y?G5wLXV>}IqjNN?^*W(*G8Ce}_owuW?+Nwjd$+#9IK~wp7xnMmG%9bA*86<v
zLG(@NccbnT@KZ_a-L(`s6YbE^o$-HoSMl9RedRp#XLSFr&(J>p9(J}VZjB}3bKOV3
z);-iu`M`0}K$iBFzw5g#7T+G!JDy`6*|eWqbx&}6;BT{HXU{)1-(G>HMH>exkBYXv
zO1UH&{ukwj|7yH%qc?Ux@@<;W?orJP-Ln$<u08sFQ&hjJb6rC}e+qtk3BTu#p?+{j
z^hNX?2KJ+VC<uSx1jcXGy(G~^y;u9qn9k!${qHOUb#EJ4O24lCk>@*ra!&7pmD<OP
zTIT`fcdERMyGHr35&gY%b_06*zQ*3#Z=l7u@K0I4Pf6<@+@-iWnW0}+d9=Z`8vhT}
z#}{Lt>k#U*jo8_K7PR44=xKbL_RQ|oTdqNG?q{?|_5C|F&m1M>H|Sj_uehvJad1}a
zDX#lKzuv=}|H1g(IuC09g#1?V#TqDQW5^F_+|etrr=)pO^B(p#=b#qdPe(OREXoV?
z>K(Rj6hCC%MegV_%9d)z+pF*6*1c&$>%AO+fBZn~j=V;>S@C9E`)Hf?tF}JcTaG|(
zTK56__tY2k{@SH^7SnwwrN6W3Ka_sm+MlYg!_Kw@G^IGWM*CebM19Xe_$T~Z`WLs!
zU!(Zbs`?h~%Z^dC>%KJFjvpJ8_sA&kQ&Rq5Li<%l@p}D~JqhHyl^1KAjoij=#@nlX
zETj2TxB)-LdT1}{Uex?9{SqZ;oAN?U%4?S{WL#nWzQnI{s!Hp(X@BhK)4Y!7k>4I?
zT!o+0o;nJD4Sh~~kK*A*{k?5|2lV^Sg0J^v^j2zJw<_*y)Avigh@623p$@&P7w@Iq
zse9C@_7lrZ)OYASpHQ4`nT36$ihq-e0|NT@RcfE5J*d1u@+HQV*So$==UBDct(vbb
znor@U>EEcoBMRNYID<=|Ufpw}EtJQfV%)tt2h)3@uVoJPRq~%tdCmS~skiC<);A`<
z=p8fmFmj#8;a9uXhehklqPVm<hMg7%e2Jp^^+B_nRlW<F(K+DIeqU^+U-75do4Eu#
z`p<&~TIGMe|MY(Ze@6RPR{KO*`KiqL@Vm9&m0zaZ_IJkHa3=Pqeh(eddg<E-xiz{k
z_szlHQQe=)?Z~l;`ktoTsJPFid}?8L`gt|JwnyR1+Zo@m)^$MnsM1#XN9(X=06XHM
z&NFBq(S5vQh;nlfzWQ%ipFIa@e9D)26u0Jo17C~c>*x-YUHbkG#a$D}(7$fVkBZ~+
zFJb@4A82pUe(Rlw-mvCHlkz8F`Mb%Ao@&kCZvBqPc^Gms`n{lE`PhyU{9fGyBU*<M
z-FNJlXnalhu~vEPU@i5v@{d*ed$dktxAL8P70(YZgg^Wwa>mlo;G?4VK`WO*JMUrq
z?y2_~#sBd%;~#qoyF*j!|IhSG>vwWvivQcSA10O0?9e-`>n`kRS%@5m@})`T34^nd
zm-r9V`aI+D9Swi}M&?6QaiL3jsN5iSH}}9lrhPl4drP~{h1RLx&wP&j<}<OUPx<J2
zo#V-$qR*!LbkxQ8gZf?A#3=nktFWi*VdU8U0<|l?snq(nU#)qi{nhe5Wp9rDr9VMq
z%9o`yp3)$8Of;fDaw@b%>%Qqy>}b+GcU*efwZ7Wcpr`3X<kTI4ea)TF^gqy>7i~Bh
zKG%-4k3EHae-b%<z2l7QKI&1vwRH<}(l+`HYJccdek^?pcBl2ek<vRrQtQI0JpI6V
z^!MxCV^r~VK<m8p0N=N6J81RI*j3bdYg2wMaXjP5ZqWGlrkvM$Z;~G}W$K3>f(DM4
z{r{m~I8FV)t>|goj`Eo1N%<7Y%{BPR`!?m;dQs(9YxVp2&gYTa|0(j)+9#WKp}$>m
zN-<7<+kc^T+tF`Ad9Li6)VnXj-jaS_R{e&?`vvXE1<37=;;-fn=xtU0B=3^HbJP!A
zK);;k=YaMz>mAgml!wdf-rkl$Ur#l9ipnbuY9E+T{<=ovN&W~q?fTtK?Put1S^=&9
zJ?)7Lq1i`~U$>5OdJ$#2@++}((Oc+be9;5p^D0l$F?DXeLwo%*&`RBRJ;yQrX62)X
zufmSh1L%n<Zgzf5*?TJbD!b^H)_ItjMf>nS=|5J59j<e!k1O7auAqO1?umZo$?Vrr
zACvs?Pbmj<KMQst&-W(svTGTK?+s|UK)dyQ+C%5bo@Lk>*1amMymdlxNcsZWJ-5jZ
zqCwG!Xi{`gbnF52IrhcQy6>QsI>%}?zj_~pZ$fcwN%wcxU$L(v53N#O&8B^@vlBli
zl}D)5?@1^AjGZy<f4w>%9lEdCX3^fD_0_Wr{;}wu)$#@UTD7mo6#w{j{&)Wky-vjw
z&5Fkxb-(CSoNZBDQPOv*z8Aek-8(#rzv>i+7d6h(O8DZJVMk8$IIZ`x8pW$kAK=fB
zAO3>k+!n<xVNtK*U{4=@j>ygqmD8f`ZM279WPEnLqh@bsUvB>~_Ed|%PWF}LXa8x~
zQFjmg?!O?%uXwlgFZ$bdhtHyWO4G@V!_fi_d_w=hacJP*$QhVVzcJCsziChEouRm1
zWsT3Rcr~N<%)Ihou2<mmorJtTo&TQSQy+a?_SIu=?+WS%KE^)Flaxo4_Z?cs{Bax&
zt=I41Qh&$pam6KLij%!p%g?%p^yr){o=1I$&UOFUl)FR&%dx9n=SB11u_LFy1C1_3
zU-#A2r)JRKcM9Ve(z@vXBke`a^MVJty?OW>G+zU2r2iZG*FFMYz)!tR_e;kT^p5Fw
zqK%3lhx9wq!6o>u`A%r?JLE-9LQY)!P_N=yzvin$`{wvP@V6_!K7KD{>ki1P*Slz)
z@?V{Qz|OLTaV9M2>D)`>6zvXb9JR<9n_wK-3n&LR(;lASySlYscytc*Z^DjhopW8M
z({J=~_#5WZfA~7&#&n;|?hRk%B=v*JZ`I79-am(a0~1j9R`itjVm!f%DSH$r*mSR`
z6%D<MoTeX3p5oZlK9tk?`<>dE_`|OKzeRbxx)Jmibbl#ozV++8bUaGG_;28Abs^WY
zSpL(!yzW}~#`HVOi1J5`y8qQG&tMZ@o7Qzfa$5BcIa-UJq~>9#&ZC-*_+el@dfiK*
z37ubFjcZKz%EFtpM-}&$w0>(}q2Afbce7s(^-aAWDc&2)$uFlt{fgsTpTmyKO^ml)
z`%hyV->XOafxQ(y<GRl{^d4US3H1ZdLSx$Jy?0ZtTmZG`{bp42EP6EhIuFO5zGt9a
zde`>J5B*Qjzc7<=d3NV})qH^6{fbAOT0cE{Z-}%Y&;BR)t^Yty^+NPk>+hq6mEX1R
zi@c%tpf$=P1Qg#j%%r~Qdip0c?*6|}AAJm3rF>-VZ1neQ9R}CaUakCX&F_%Y)kb~(
zLB<!qigNN*><ue!^ef+7lKz_SkUw%AG^x0^sQazw9gR1Jo<7~{Bd;O9Za3;n&(Yt1
zIka*=+9$N$2lYPG8$n*X@;YtGBc=k>4{LsOUrf1kJ~W^>r>uKUeyiHGKjw9>ODECW
zq5Orf6?+=mp`m%u_yTDEDwQw7ZylFG3%bYHzZT#2jMJlgdPv`~S@XuNylW^={}$aB
z>a-74evX{_ld&)V1$^DgZ&qoa_A1V|{!09x$<Mz>zhA!taGt?@Y`u^A><##%R`X|Y
z5&gp&w^jbGIvoDiyOCScdqVy!>L()5p(Oo_`g@R$R`m7j9vOU;_V(?lubas_w`+eM
zybF8E|AbnPg1@B(`D2xo9l9rWDc;Ebigs6w_V73~qdc=;>#({CzOe4eLH*u0sC!qJ
z;_coP<7|Bznv<U4OR&rSH|q0>XI$4Hw_5u|{42)Qt#hRDW%%vNJ2riUebv8&mb5=M
zTnb;M-WS8NtL1OV&&z-QD0Wn;+^`?*{a4dJr0?%6B0r>c(y9CSu<{~#<qr~?2YJQQ
zU5_I_Fqd%*D$a5*Lw?g9$nDU*txfw?z4A7-+Gib#+xkz%K9`g4UO0|&yViNbZ1lx0
zqQ2$7%=4kC^L!KfM!$kD@+{@@FGTfwY469B>psEGR-M=5)szR6r*W)7ep1vkBz>a(
z*C>yPcDzp6s(WEt^6Pb<?^}f3jo+cit9(uS&WyKrDRw31!RMR0ABLo76XWU_gs<&u
z%E_CN*Yj8Ei<i;gqj!mBt#{9#sISreFt2kgpnLd$;?>;#$VnXlfBPNK><aAY&^b1w
zI3lQh%c1vTuV`BV{+f+Ym*U#I;^zLX)EAG?cwT2b`3IogE6_Wxd{@B%U(NoEx6x1k
z0o~sVy6280=pWYpk!VGZP5ZK2_lA0XkK`5jzk37n>J%r3wV%2FgS=MxFJlwG-q&(p
z(r^3**`@q-_Z<3-D!*2*_lR@{_4U6)j{O1Xkm9%2Z)s0>8E;PeZol@~Cgo$j3mBJO
z_df3g`U^eOk1Ag?_BZ5>=w9sA@B7A;=W{9EYgazfaS#2oPeG$MVTU`0{H`{}o4yj-
zd>8GNyTae2_&KcmR^&zcIrY1y$T;@2|B7*s=^p6Qdv~MaNK3uO@h|v?6-N%}oh+?$
za9sJCDj#}6?_p1;)_L=Oln2kk-lTqS6#5vsHTR<@a6SFgI=_Y#{|zc0s@3m=yxJez
zwXeh#r^Z9<gCjb}TJ@cK?nZyL_OY5Dqi^^W_$PF~=~Nt7P~6s`{NaeoUD{6^irZ7C
zBd7Cq>~7OLZMDw%@I2}RyW!`$bFm}d5A|q&99O>6)_}aU;`)Xg@sIN~`nTy^wNAx5
zice~k7jDw|K7IoHmaXV%{SD>9-*n#DuxsF1XzTv8H}%jSl>gjUV^8(=@MX`X9QY8q
zft{c!(TwhEk&BQws(7}~N59a=$j^NVZPqy()j3;Myk?zCf1C0hgUVk<^*h2umi`f~
zABXY>m2;V2&LGsK-&<5GE=?VSz21M)Kcsk|X$$&V>u9gjKHks(UrFQce~@ynz;~&B
zg7V-H{_#p*<Ij;Zs(8Fr-^=2`t`6Np?bjp6t@Ti^_0an{_3iH>H}WL%2J4|Y?SHYI
zkyp4E|JJ3jXJj?~b05+_u6$|n3))+K$VuznCZ+Y2I~X|wZL|j^r~LrRF71Cd{k@uH
zIr3W`$A6h;pw5S(qqjrjx;M1xT_maR<<U8ry9W84=W4u)GipnW&!_w0u=KjM9{vA-
zKP)=D8aa^{pk<wJ&SM#O&2#Vv^}C6%)?Ka&{-H|7U+BYsUAI&3(R!$HASd2SeeOKU
zjRzw)ejwu=)_k_kgfBD#4Rpa*(D$_}4s-qyy_MQeyn2V9*pB)>y_XIsU+dh4oXi=t
zdp^Yu*Idf=qP;qo%DbSy=0f}#z8IRxQ}0yXqw+fXkH1fS=0o_>ny=Ar^bBmnKXonG
zVL2B5wBmn%J90`L@HhV*zSt=JGH=1(cpS8#cp$AjLY3Y>V!F?jwV#gacXvtcKdGaT
zTd(()#xiC5!F-1{#q|!wHzPB!D|a}0>waK-IsN`2pnPv!<Bco-(ysehLiffY-ADWN
z{+`l%u3dTMatZnVi=eImbofy0YF1v#b_(^qFW{F3?ITX*?V9(*e-mrqi{}|%M)R|6
zH`+TDe>eOYIl-^s@6q`^)JuK&HtJ(~=S@oAxZWirKSF-!ugI<1nX*IsT|*pyMfCS}
zW!-<=IzNZCu1223&%qDS+jTkPt`DO>qV>>mK4pjgKBrE<6Y{U5zE^(pwaA_^^hcYJ
zUw8#R*ALj~Jp!7L{Jv|^->UoWgh%@H{?>FL{G*!pBf76;tnjr~(%$?d?C;Py-lX&1
zr}KQEAO2>Y=b3%5uj52$O!xcHDU_{xSMgm+dEzQ)PVsC+ap1rP#_iI+-5@`^HD9X(
z^b6^p*Qj+;8=+rz7wqp*d>Ol&`fA;;BG=Mh--ev-4DAhm%H#TXB#PP}LMPJh`-XlE
z8}UmyPJNB;v(_(Yk7&PdeVlejKlPUT^c|G{?S78$G&o6nPWij>*VRvPbG__seuw(%
zsd(XO<n?I2HQr6RZ34MtdcUpKeY#WknL6EvigCtU+dx0J-r2H;P;Wn%c~@3^-D{yf
zc0G0sK108ON2qVodD^FYc=9dma9s~ybS*Tq9_qM}ai<SM&$zy0NO^U))>Vzxm8%7L
z&AQiwbdH6Vpg*^s_B!n=-EQ=Z>pjLbfWDrG;jgLDI1Ym5WPi&d`c0_ZpnI5aF7jhK
zmj};OzYD2%=>9XN{KT-<XW$Lm`*ePF=$!XxpUio%t5@^H-HiT$S@av$d$CLFqhW8_
z3yN<u55t$!d}>-txku&jBFc>(?5)$din^x+E~7oB{DA*3?6D{CllL9UE(hh}_ssv)
ziPR^x|90toDl9}^%NTaro$z(0sE<5Py-)ti>UWj7Utpj8SMcY~gD-R^ddDB4zfW<F
zSNE1djk9%M_*44*O0V{_^e5C?E`i2HYv(hL+CM@^_Fx`1bfbT$8@=g2(J%QB<?PR)
z7QL5by5LXWOnp@M*N$%Ntv{XiCcV3cbkFqm&^~$@^7Ae5xs=C?<nc$V@?bskbMx--
zcOL^CJr%tU<#lS$p<L2=nm&hd`G(LpuKn1p_1UCxcoau=JqVxmW{qnhcDRm5Ur6_^
z@;mr#I1FFySI`liGcMgDJM8pp_R^k8BER=_`uh|g^(s%%p#8AvbNEYsXuIOUIxpk%
zU4dPp`;gc47JOqmk5c-*R*m*g-#@V<seN!l=T%}a>RUg=o)&$d&{pbg527!n^-}yA
zzLM;4>idjb3xDiF_#5^98GHi!1{GKLe~F#mXQ+2+-Nm&In|0r|=p3!uhwo>xAm8;a
z<@QhM@7-D7`vc_GYky62;-4Y?9<KWm__}YPpI`e>-TBCCK8^mR6nZ)m^bh_S+NXW9
zYNqrk-{pUa{&~^1mnlz(c4R15{sS5owd?ORIv>$E{tNBUItym8qu&O#Z=ikTPuSz!
zh4CbG?pCdUuPH=*OmR)4<k%FqShU}`L>oj~MY~1q+P?-A*E^5F{<`BdjtczXI2Kyg
zyVCeSup_VkJqM@eLF0e)J(Q=cKLoy{zC$#M-K~oAIxb?o0exrRZS<c|eA=z`n$^9*
zI>oPhar;@wPv1qq%JY$5uXCvH3d%JLu|N4Te7z@8uGBt1?57<09qmrVJprAw5yctd
z$7r|g1Ak`_`};4YYzgc8j=&e!`CZUH?R3FsSNzj^JnPJ*{okW^)ST`o;UMjUyX(8$
zM*s3n=xP2P<IC@WAKJA)4NS$!y7z{jqrLXu^vhmBIivA)97#F1OyfF=a^IooZCFOX
zo&~h`>i2nFv(O(?yjr6;rAPZ=p&B`9t;^9>$f?);)&4mB-J*r%@YkG;-u5*7$+PgM
z?;L2u0{D{pJ6D_DTkW^XAKFKwcfe==9(n2C(ms-c+GS_<Dfp~9-=p(skBh(cKa4y4
z2lxU9)84Cnyjtypqv*-K4WI8y?Dv<cAJDlH{G9fZ&UxGJ$d6V*Yo4NC>?rgk_0CgV
zNxfHpw_E)!{2tL}(V%EVG$}eLninmLb}PT_`3$@2bLbhqkh1N2^fc()9Q=g#@&nN5
zj_?)Ug}U_nkhB~7^ZNU(!Qatdc_{M6&gFZCeh$s*J{moVe&Y|r=Y5fNklKm*TK!Hf
z-a~uk2((}OUs3nw>K^n3^?f6{Pc-OWms5OS(0m@zy2&elQo9}c9MT)qy&<K0L|S>>
zQX_orXF}~~L5CHmxU^0@S|>f)r_%bpKvN6+dC{)9l%s9XqSjB>)O}L>MfUHsC$;W8
zG0HyWErykUPbi)myazu8yWk6HK6UDz(sHxDyYd~8zrvqWUc;ljK!f6{nBx9`{9khr
za$OHF-|O`LIHLR0gyO#5`RM7<yF=<#zHeFQul+&3Tc`4(CEb(yU&kJYzMH!WzKN@l
z*Q(#0w4S8zKAU-E`49GV>3(I={Wq_7EZ_d{I}gDAhMS<atI#)eGwn9{b5Q3{hxXrA
zjl-dHB%}G?R)w5kgz;4#gFNpw$g8S=c3(t&gZ3TkmDp{2g8oqtba0q)retrY?6vED
zTzdfWTJJ+%tMaNfU!gy)@0(P-<hliUosYs_wFEl)8no{MX#N2D+tj~Bd556Z>(D9K
z7rz<13!+s^srTr6_v&6Zth{CNQuIgkdx)`L@SP%x2fCEEOY7d)t$SZl{;h9gyv^&e
zb4>fUUF&o}al+7<@Kyg5`(nDU^?pjdOZSHEt0`w6fG<4<n$x<g`j+;Q#pv_bP<HEm
zv81@sq4^QleY!UZ|AhXYA?%W#`=Igj7<VoQZPz<q_b+L0Q5@uW4S)42PZZI6WjaoM
zQoqZpRvxo%3H{qXK!5TT%Dsv+T9hBFQa&~HKJ8igG5%ZGt?%P)r|g@9zSB3oblT<F
znNM_X`DRhWdyCo^O>Wxy<PZ1tZJGS$_G=#eQ+C~~+`B()oqYbdchBB7@kaL1;V&jX
z|9(+y+v>^5r*FRCnkT;<`0%NxCl{?d`plQ^+Poz<RNgfC#`|AfeE;P4zX)CN_2fra
zT(o6!>q}1!Om6w`^wo=wKlH`PMU$7FUtThK&gA8jAKm!T=Vx|pSv$Gy^uONRvUSln
zAB`Wqb<@9|>HpVNFHKJNOg=n$dinG0r9UiM(|!HYt-JjB{rRQItxa3rsC(&|7yocp
z=be*J{;*Hz(A;r9x_t8e^V`dZCI9;1M+dxf@22-(dw%O5Upn-~&nG|n_=j?F@`v0@
zmw$24L9e_t=ZCE)Zuw!+p&v|sFtF*Xt#=KaTG+BBy6VI7qp3jlrDu=abo-V?%dYsM
ze0=fWi~iP|zUIv@w`N1vUs;}fA%5TFv!8$S`|Gcm9C&u%hmT5S|M~yf(L3<b7ne@H
z|Jaf5e|7(&MF)(=wp_opx%}+Jw;x~eLfSj|((&8(ZT<A!;}@+jPwsJ5&(_nv`25gZ
z-R2Lsq!zvR!=c$<e)PlEA0|_)4?1V^?D5I_H*MP5zv$8@pG;0J+O}!^<Y&hncS-z$
z7neM<>EZW}zu=2+zZhP$Hn+8NpMOto*&5t5xwV}8@S{yfy?f<FcVCq|xct(gk6!T2
z*5mJg`tJX3TD0h+@83V~s#5NYMVEcE=!e%gJ$LiRUwrZH<fh`k9`Igp!ADy*9l7X>
zP0OyHynE4>>nil$u7>V!aI(PygBuOj8hmZA&0wd>ii$l9_BA-z;3R`H4CWdvHn`1T
zg~3XL)dp(}HW=)%T}8zVgA)wq7|b(RV(^^7I)gp8H#!Yw8(e0v%;05%wFaLW?6iZ?
zX>hQ?Nd~hF<{Hd5SZc7+V1vPz1~V*1kHM)1^9*h=SZ?sR!8(J@1{FJ+aT*+JaF&6&
z&Q_RIS;dV8CPc0<*Src7;#Qb#s$#u?`58&YHUsm#U19zNtit@fslq&ARGefm%V4p=
zQiBx+s}0^Z*kJIbf%%`(sxbc?R>cVhry9&Lm}g-A$*zhe2Fnc|H&|!zfr0rcNX2G@
z3ahcv;4lO8JXUd;!2*Lj3|1MeH8B62RmDy_8(R#HGBDSniZcx68q7B^*Nlp#1}h9!
z8>}(dVDP2EcLwHXCKWRc<`|f#oQj18w-}i4y~12ID$F)h@qxjvW@4CBM8#nSCmWcs
zsKSIi6$=c^PhTobSWxk@!Fq$Q4YnEVVKaU*IM`s8!CZr-1}h9!8mu;0WAL`Ymj*lh
z*!ap|Z-W^IGY#e#%rjVMaErkbgXIS63_dW}Xt3u`jDHNyGFV`6hr!DRYYo;Ld~LAJ
zV5grNn+*0fILhE8gINZ14dxr%X0XCwjll+kz3s*hgToC@FqmmD$6%qsEe6XC9yeHL
zu-TwuH{&OR{SA&am~F7Y;6{U01}__|H~7?Go54=I8+#0nGC0X#mce3!+YDA3tTtF<
zFk=rhZwwY1EH`-0;1z?72Ad5ks?2vWSYWWqV6DNY245TO^fRNw;9!H349+l^WiZ!Z
zvB6S<6$Yyf-ZuEoV27WZ?_jXE!3={F4CWXtF<5S}&S0a#W`jNVG`bDWGMH_!z~DxM
zWd<)BtT)(Zu&=}DHkf5F*I=>1Z3Zh0RvN4}c-vryy^LOiQw`=BEHt>qV7b9MgN+7z
z{=)dz;ADf@1`7;sG+1WvvcY<TPYur4+vqcxYp~d0sliHvw+%KJd}pvjwHd3y;RdG~
z++wiAV7b9_2Co=wG}vrV@k{f44fZtH-{53}*#?&x+-R`O;AMlg2A>*yZLrfmX6yz>
z8JuKrhQVBe#Rj(-EHzkRu*TqRgAE2>8tkyIvCCkF!Qlp{8q749W3bTR7K3#L8x3}K
z8k-FEH#p4TGJ|CXFB_~k*k-Wre#Qoa`36f3Rv4@{SYz;|!FL8b{L1*=;BbSP21^W{
zGkC?|1A~nQn+<l|-{>>g-{4q-lMT)?xY6JagGUTj8LTx}Z}6$XHiJD}#twsn4bCu_
zYcStnvB7NyD-2c}ylt?-;5&mEzc%(5oM3RO!AygB2Dcb2F?ihI6@!fin++-sFm@Rn
zYp}rJ5rb6*FB_~i_}XBP8O9ESqYTb4m}M~EV6nk%21^ZA7_2mS+hBvi4mHL%1~Uv!
zHJD>C&tRd!a)ZYW)){<Yu+gC6K;tKa%M5Nbc*J0p!OI3;8|-nA(QPoxV7|dpgOvuW
z4b~WJFxcT>GY1T27#wbJg27CKIR^6#ZZTM5u-xErgI5ebFxa)$_`u*;gOd%;GMH_!
zz~DxMI}DZ?tT*`DV4J~7hZuVdW*N*kSZc7^;BA914R$!x*kUll-~@x226GJN87wro
z#bAlSa)aj#HX3X;s5s30pTTT{%M5NbxWizX!779G245TO<TgGrIKyC;!CZsI21^ZA
z7_2r}WALTHcLqEB#(WQh6AWe=%rjVG@VLP%2I~wyFxY6Y*`VULX3iSyZ*Z8wSq8HW
zE;CqQ@QA@GgO?3HHP~jb)8S^G7#wUc%V4g-VuRZZmKv-uSZ(mO!3Kjb4QAAt`C)L2
z!4iX44AvQJG}!eBV}rr|1}7VwWiZ>|GJ_ipmKi)^u*%?NgS7@<8{BrJ(PyyIV70*p
zgD(wsILdqzgS`z-FqmmD$6%qsa)ZYWo-=sGV4cBcg9?w)Z*Z8wu?8m_+-Puz!6OE%
z3|=-^Yw)$fPDh*XVsMnfEQ7@cD-2c|tTuStV1vO9$Cx>4aH_#VgXIQ~8@yt$&fo)s
z%?1_68r=pb8=Pe@+hBpgjRtoZEHik-V6DN|277poZiAByW*N*im~XJyV5Py^245Qd
z^f=>tgA)u+HCSk{#9+C>a|W9YDvmebz+g{<!wil!IN4yf!HouY7_2f_Yw)ST*9QL|
zJMSM?`I!IzcbKR(t;tTzvD2E?wB|5TOtzRPilXRHbeLAHX-yPGF|9JSirVckhl!#n
zYE2Z=DvDyVomCXICMMgVC^}{iMNxFj=h6G|nE$^2e*e?$cE3Gu*RSXGysp>lb^Ul=
z*J&B7jl??u62UgG0~CWwP!0Bh39txOMZp%Z9&7@UARcT7g`gbl0rj90^nr0O1Lnc%
zOYnR^Fh~MfpcK@CcCa5D1j}IUrFcI<7>EWtKqaUKji4JG02AOaSOlx0VINozwt(#*
z2NZ&GP!IaR3|JilTR<?#0z1KOPz&~gb}$RPE`u##1K140z&4Nvia{gj2NPh`<)|NQ
z0r6lvC<OJO6AXiSur(IX1|)$rkOg*vTCf)kf+;Wyyy8$d2m{+d9w-LYpd0jq17HFy
zf;Cs5eh>*#z;=)W3PC++0i9qNjDs044_04^cLxN6tsoX8fh@2S>;|=<9ZZ2)ur?mH
zfz2QcM1vim5p;tIuqFZafOwDs3PCxj2Yp}$cwB}0!8))N#DXM{2C~3j&<^&4K`;xJ
zf!Ecj8-#&qumj|QVo(XXK|h!Pi(pkE-VLw`YypuV1>}G|papb-J}?Ysz&!9U<6Qy4
zU@J%hX&?*i1be}LFa>78GVr<vwt+;j0~CWw&<MIgKUi}u>;YRqJlGBjK{==gonRcy
zgVjmsACLyJz)nyK_JVdW2o8cNFblkr@q9oShz5zE7&L-@Z~#nzMX=^N*a5bH?H~t~
zgBCChX29y}(Fb5Fhy`h2C)f-2gDJ2K)~2A{AR24~)!+b_0E=Lg1@(Y>&<TdYJn*;y
z`oUI^1kykjC<X0cKNtkF!0Sf5cVII}1lvF!C<fJ_8}x$%;4oMOYqp_{U=!E^B0)Sz
z0p*|`^nqb81Lnc%R6KK#2C~3TPzrW~{a_Hx0<S-z-C#3_2HU_6kO!(kBiIM}!30=!
z6Y2*kAP1C#J)j=6fKJc{hQT~oorXRKNgxemfxVy|90aq#D;+j~%^(a!gKZ!WRDx>I
z2)e-pSo3G}2iO84K|II-g`gbl0rj8-bb?_p4rajWoAInbEJy=cpcK@Cy<iqBgSFf7
zoWN!f1`@#zkOwM3HP{Cxz^V*98xRRnKn^Gb^`HfGf?+TY=E1tZpni}9vOp=Q1?}J<
zm;!5WLH%Ge2m{ez8^{Bdpc*uS!(jam)D7Z63fK;EKp`jx^`Hd|gK^-IiGBbZK`@8~
zX<#SV4fcX|FbJl=ELa9!x56&40YrmspcpiQZm<Ye-G;sZ@t_dYgFY}0=0R{4+6}V6
zUa%hwf@R>94gFvP*bKrzBG?9YfJ(3rbc22{0T#ik+wo3-NRR@ygB(x}>Ol+W1Ri&w
z-C!L^0%;%%)Pi;}2&RBn4(tFMKp2PyJ3t<&292N_^n(d-7%YNSxoA6x1lvIl*aKQX
zC+Gv?U<Rzd6Lx@&AQ;4gG>`>K!EUe@w1Yt~1!lq8yI>ax1JNK6>;QS75;THtZ~#nz
zHF<bHz$Oq0;=y)M2wFfN7zgvfBOmsFU=RzEKo%$kyFo2z2ZP`sm;zpR!zK_0qQN$h
z2O2>)H~<cVRrlc8fE-W`>Om*y1M^_TsTmAnK^oW%_JVdW1!jR)0qO!9KqA-%c7Qxk
z3@Sl4=m&?vs=uQBAQEf`IiMVLf<7<~X23k~xEId@Yy`nzD~JV2APwvX2f-}xDuf*%
z8svdS&<zfN32+!Jf>lN6d$0vWf_RVu3PB4P2IF7`%ma`6@Lqs*AQ;4gB#;G4K`qz|
z2Ej5|y9?h52m^^=2Pg)Opc@<jhrz01*a0?yNDvQFKso3HePA5S0FM&19i)MsU^l1*
zdqF#x0$zVZ-CzUQ48lMn*a7lDF{lQO-~c!b7QvePVF!o=@nAd10fk@>s0W>(4-A7D
zu(}k_1Z)MdAPejSrC={;2eV)qtSy60U^55<+dv*D292N}90rSE)dR2xtOr{_B!~w&
zpb(UUPB0E;z&zOaAf5|YRe`c#6Nm&UU^~bGg<ub;2Q8oz^nqb816KbXdO$2l16g1v
z*bQpIelQEx{sV0Rn?W>41Uo=6s07uZ5gY)A!TL(r1L8pn*bZ{Q9#9YZz&Mx(9#*_#
zAQ)@~NgxaC1?^xz7z78w6!3Zowtz5@2zG#CPzm;dZZH83gGI3BVe~182Pq&26oPV4
z4_ZJU7zXoT-EP<dwt^&(2C~3TPzrW~TCg7sf`ecgY__3qKqA-yia|B#1`}Wrta$`|
z12%yzARcT7IiL`fgL=>jX23jH{U~e#8$mGG3erFpC<VJgE!YnR!9g$umcfQSunUBN
zM6eCyfnrbz`oRG(0T#jfD%b>aKq2S^eP9O61CPgG57-J~K@!LUJ3%R^1%qG;EQ7U=
zqkfPGDnT`91naBOeh?3GKp`jxEua$&gK;neHrAjnuoLVC?O+Pbg0)YejbJl~28m!B
z*a7lDF{lKMpdU<tHBX{`un9zh6p#Z7K_?gn9<^vE*a(8bRuBu4KpNNyO2KYW3-*FR
za1hLbWw5pmc7bS+2Z}*8=m!VD1Xu*Co`Owa3)l{FKp`jxdq5``2Q$FqY1jqUfnX2|
zvcOJI3TnY1m;%dSZ9V!2YzEOF4-|uH&<_rP39txOHNXzA32Xt8ARcT7IiL{i0rj8-
z^nqb84(5T!Gq4S;0~<jw*a~7n8rTim!G16Zrob#%242s?P7ns7K_bWl#h?;YgMP3G
z)-=LKum!|}6tEra0rj9041;kn57sr|xq&p01xi6J*bCahAeaJP|AY-73?zbWpc3o@
z{a^wtf;G?K{Q;Z677!0oz;;jwX23k~*o*!E!C)&$0%@QW)PlWW8F)40Ie}<U3@X7s
zFaZvORnMbNunBAdkst+Z2jyT7s0V#u9L#`uu=)kG9c%=_AQmKnG>`>KK`qz|_Jb+l
z)dE|<2Cx}~fkdzk>;QS780-W6-~d?Fiv9qbKt1RK!(bfDgVis>4zLjfgIJIRvOp==
z4Qjz&&<+lQS+ES&z64vqW)KbXKrvXe4|Re~AQHrb?H~u#gBH*UhQSQ*XhZ#AD@X!q
zAPejSrC>Lx1?^xE90be2>tCoJgn?*~2=YKNs0NLo9~=N{UWPqj3y1{epdR#rVK4*c
z!Nzv<14sgCAPba&cCa5D1XExZECa6&^aF?nd7v0ngGSH~4uD0l<`wh_*aG4~4%h?g
zK_3_f9<SnAfQ=v+B!M)L1$Kj4&<^&4gJ25Gf@R><iM{}vK{QANJ3t<&1l6Ds>;wJa
z0GI%W!KyCU2R4C7kOK-qIcNc$U>JD32KzuThy_U?3+x1?pcd=}?cgAo1<N4ub-bgX
z7*v9NpdTCti(q{>`US*;a?lBe!3^-|L7gBNl!98&4)%jVa1bnmwQr#PAPgjeZD0qe
z1p7cgm;i^tnm5r_umz-m?H~v20rj8{c<e{LU?bQHVnGr}1G_;j*bCahAeaKPU>SJz
z;yHjY5Dj*KJWvcOK{eP1y1@ak2-d#^o4|Ik2h@W;Fb_QbjrM~ikOp>xcCa5zfmyH&
z*7l)ZkO+2wMz9a`g9)$**4t4JhzBVk2b6<7pdR#rVK5HX{Riy_TR|*H0%;%%>;zL_
z^V?`ANCbJH8tenzpdTCn6JSk0>IGXsJV*iCK_Msydq5}X1H)h(%!AbfXgk;nl0Yfg
z4fcaUa1bm5uXoUXumNlaVIUD~19_krRDwpZ4|IbA;4oMOtKNl;U_ICZQowdl4)%b0
z&<AF~%4M2$U?T_yu^<g(ft{cf)PgB63%rJ47YGB1U>hg~m7p5z0~25ota%UhgLsev
za=;$Y0{Xx(7zZBjqi?`Eun`1<tzajp1$#j|*bfeZS>QE{J_4IT7>EXmAP*FSYS0L}
z!30<YYevu~U<-%`DWDLvfKD(B#=#7j2Oj^0Jzy({1!-U>C<VJgEocW*U>10N0GmJ<
zhz5C}7*vC9&<_rP!yxhiYygE|>nPp_uoLVC?O;C`1hc^FL-aY=45C3I$ODz28Z?4#
zun5+Cgm)8c0r8*^>;WyH6AXhHFb_NqqTj(fun`1<Sda#?Kq;sNd%+->1#8D(3kU;=
zU>nE-#h@BAf_<PLOn}2+&By3>5D&J498eDSfELgR`atmi&=(*HOo3(KHI6z#7}y5#
zKqaUK`#?W901ksy4%7v<fJhJzQa}zU1m&O}w17S^4(5T!C+GvP5d?!+kOs2APEZPV
zgIcf`41$AT7A%8ppJI#xm7p4QgMP3GR!yMoU<-%@+rb`C4_ZJU7zZAccotwC*a(6_
z637BOK`E#OdqF!G1XExZEQ9FJ@I1gaumco>O3(=QfeEk(R(+251LS~0P!9Hhde8~_
zz&P-jf-N8zYz1jxC#VJOU=YlLwbOVnK^TYz+rSQx2P#1$=mrPC1UL*9!KyFttiUF)
z1r&mE&;mL^9~cKSU><mU341^=*a~7n5=aACpcK@CcCa4|f`ecR%z|aGb_RBWZD0q;
z1Jz&x90seLcvfH&*a9L!Jjelspd9Q0Eua&OgBdUnJify70~<jw$O1b-DX0Z|!9g$!
zmVwtH*aJ3z%^(aUf^8rV6oX1o4fcU<Z~#nz!(jbk*a#v)Jjem%U=L^kePAAVxL_Ap
z2R4FOkOgW%^w+2l>;T1}8}x$%;4oPA4W1F$0wO^QC<NtT4`>17VC6FAI<OVQf;6xb
z>;>&$5X^#Quz3#kf^8rVRDx>I2=;+~FacJ5i#CFIkOFeR9#9WjKqu$}<6s7Oe1~>|
zbzmdd3X(t?s09bXEby8~zk>}R5o`lHKryHU`#?8Xvw-&iYypuV9^`;MpdQSCd9eC>
z)Cqz?5=aACU@vF~`@tYM2&RD752zb#24P?u*a51+KF|#&z#>?)2pd2=NC7#Z9Mppr
z&<Xm$Fc=5(z+(wEfps7l#DXNS8?=M{U=SPxVL#$ofJCqZRDykA0&MyT^@0?z9Tb9c
zP!C!_Cm06fVD&Qk93+7(up8_J`@tYM2xh@D@N%R5U^CbTc7Qxk3>v{cFacKmjP`>~
zAO&m(Eua$&gK;ne=E3SCXfFr`u^<hUf?CiH2Ei1V1uM7UH-Ko62#P@?*ax~nq`}}3
z4|2dB&;mL^9~cJXU<S;CjmH=~7LPS}tY2mD*aWtKNRR@ygB(x}T0ke50rOy;r@<o_
z#DX-C1xmpnm;$rF>o|kQTCf3Z2GJl9Yy)|q66^#0-~c!bRvix;KqN>3+d&~{0i9qN
z%z$~Ya&dYqhy_`o6zm3jK|9zF4uV;*47|Ky3kU;=U>hg~)nFeu04Bg9So16N2}l7s
z;FrH&df=BH_@xJa>49H*;Fliwr3ZfLfnR#ymmc_~2Y%^+UwYvG?;hCj8hlEZ{eRbT
z1b?S`pEI}H3jf1q507l?vG4$RcvRFM^M5k@9mD_0rV7T7N{(!1`amz!{gRnJXQ!OL
zguh`QT3|Q;KMr2e8<9zwevHTeg<AueFW@WYTk4{|xKBO*FMZ%%h6g5?9&$a)H=IXl
zeVysa7gJBcw+!c>!m#1543}KP^8T+eJobB*uQ`tKx%V*MaD(i4gtF~*=5x#bxYg9_
z-l_b@vmfF<r*vK*`|e_T!y@%`)UiFL?<q$gW_;a4l&)gN2lP^p<r4N!?k3jfS;p|>
zht%uyZ{|1O#q!B>EI0aF=3i=Hyw6E2mx&)$uk^pc&hqJxFuvnXh8I4jEINbvB3_|>
zzwOjBGNN)htS8_C<||OS=0~Z|bv5%(_OblPlZ;==X1}C9%&>Dc^-P|^a7GvN8((HU
zJ$F-2ej>{S-N<m!GRqBAQrh;jd_W(i-!AIu{gHaCN0=}44aVDErJm#tO3Nnd@3@lT
zpg29h`<Q?7Y=%R=XS%^med$VHI$8S8V14-;nLqz(miN{BovrU-;X?MCBZ2l>nwWpo
z!uY0m>a*%S$^JX@)ft%25XpRgS2Nyt8N;463}@*3akkN(E+5LWCd#FB%82(_PeL)<
zlQB-28$*3He^Pn9XQAsDUv)C`<>xcqfU#xey|OqNPL5-Gl#%)iG8s;uW4iO740~oU
zz4iAD`y6C?voFKhZ!?_gU_VZ8V?AU4V?V@wLOJ;$^G9?rfA1RVt*D|5e23|#O$?{s
z$b5mPvOVTO>Nl%@I*wtuX+6_he`fi~2N>TgyX=osk1dMnAtzF1>}7mY8N(wVvfjBE
z+TY|uJ>d(K-lwsi{L7>t{~%$dKhr;B`8xRZSHh`Y%;)Z6d=<{IR^rWiuUpS%dXb&|
zlKT<$L|nmmgNf4k8tuujQTog=U+OBR=dPjsp4TxwsD$;k{+aQ9>VIbf^GE!L<ww+C
z*(b1E!W!D)7tVZT|7Co>C-uc_VK`gmk|jfP8Q)dP@+F^Bf0K#jMiQ9b^giP&G8jL%
zmGN~(+Sz*z>&>`{da_#?Z}<oEk1D+?l>In*0m~=XP`dude4b}AJ>wpRU7u1<ekx_u
z3rz3nkRET=8*rHR*-m7>gr}+3V3a)?=Uf`keDavj(MV~ymU?_OE_VG$eWTw|Ps2s5
zFYpP*Prgn2Y|m5n{76~TD*Nwcxzv-GzjrP5SCq28peq@lAE0t`%-?}Cn3eY|@I>a%
zcF}(S`zV+8F~83p4A;z3k9QIEF6cc^^<ey57~}n~V}9o}<2~21p0=&5r!9&3+?pTl
zT9*{fGT!-?<gv1M7wt8f7{729Wz~z6LmyEt<uKovH|w`N!}0_5OwT`+_QZwJj-_8Q
z-SipbgEXFx6fl3Xo3ddK^~U@t{d(VgG|u*3Lp>FzGJl=s0h8thXC=#JEHT|Ll=b^-
z9Jl|0=|+u@z9%p}@C53$4l}*glko+a3_G-5G9)oy)32%Dc|P-%TuIrh`hynP&g@mp
zA9oe?^laku3Hgh{`hF9xU^pX~dfLWVKI2@*$KfB&th_&?feafGnXl<qh9@=OG(|An
z@D%GE`wOLA>!=DR^-h0BeKk0bS<!1cfzt11rjNET?EM;_Z__u@tM4g9^Q<XR@o{XI
z&*`+wQ}3_MU+p=c=^a{!`D;8KJ)Y@BKT}W4$E?qwexKI*Xv9ss+-I^qmJ6sas*ZMA
zf5q}qHl}xNp&q-F@zyei+b*OuT|~K{@!9(U>Y3E|Z`J$|rFFnU9ra9qLK*%H^P3)J
z*td=LMQxE?V@#j^GwbPcFkiv>42Oo&PM;{Yzjrm$t175xE`sqx8t0rr3^$!j>G=Z7
zFC1ORjIw;7z9U-@>nV7Qb`0Fi{B6;+FG1t0UF-X~1A6Y7Co=V(2i{3N;rNF_EAL6v
z7V7i)BW2Gu)aRq|#`-1W6J&3QzK8UyS$^SK<`4Or^@UE+F3VetpR-fihp5M`_3wb@
zDaS76_dLw@j$|-jnckD7A;x!H%zWwkjwZDaa;Gxgv4QrO?q>PS-%_@z{jIMtY<Puo
zQu~hZf6=}Mt<!A3W_aj4>RnK|^s^WqP`i`AWqU1KSZ}_Y>17wH-)~{KP5Yp+B<a)o
z&hS0MR@}o_c@9O7Gn{#l<vnp9U?twE?=&u!&n+aB_D6h78RTYsy2iPf_ZXl2B;!MU
zsn_*C#+TrqPOaz-(7v$fdfMNsb<vW>FNem7!0VW9O{SihC#ff+m|=_d8%2%OyP)^k
z?#<_wtM?}N73Md7%y_%@14c9B6FS-6g;BOY`>(9W_Ym`Yf6Vx%8iwoQ7#><fY1Vij
zeirrAX<a)RLH$t`EEhUOz0D`m-lZPKo3$P*2xj?_zcJs^pO`+khw)u&8MfR;y;aAs
ze|)r#^M9J@ZR=RxaXa(%XkM#RKby6F@@}Kv7|rtmk1-tnt?b**_C=k|_yHSby51-6
zTbVCi>umd0*6(*7?V8rO5?V+*EdOG<N&EW|&BLwd(B5o~QzeVkYkY#`hO{1v*~ENq
z?XOJguRyK$JC<p0=9`r1{VX54K-r=7dXdI+=P8W$d!O~$dl+tdgK|mVwV(V4HjNV|
z?MsZBN7{N>pHc7gSS9<(=LYJ{e~|j-G_MzQGd|-C_D6^I3zG(hL+@e!viI5E{Al*4
zTk}$=)=92!nBMjU>tB+d{0|uKKTUmInm@uDsW;n$GD_=-j%DU|9->|T7ct$T@5!nC
zUhWR259qnO`dM%OM%L4?o#}0VV)-6DpMk4r|L76s574;fxP$eEYuquO%yO;DpDepd
zs+q4!^Rs6(>#5RubIHuG-(@V{rFtAGw9EHw#%JHfaO&?U+vHEF2-fp!pq_?jDZ@`v
z`G2$i{AKEikY6I9p80wVj1LH6{vxgS+!mJ0yn!<4MZOm$R+e);Oj)LRq)zj1%!jlm
z=4<LpKE(1-$?V67HyQT-LG86LpY;LC9<3WjFxIY&w^ipe-XK3ghvv8NW2rB{jP(@+
zFl?8<$#^Nl;gY%M(q3N+>-9D=-Swl|_dCXy6i`NJ-PNFR+=hFZEA~w5dl=O|E$Z*A
z-`>k|`TwN8v6~srzMj%YdeUPU&Pbp=)A$FAD|(mG8DF!X@vWD!-7f8;ZM_VSUd;4>
zA6U+%{)xMV>G}SY6-U?2`mVi?W4T`W2kHu#ZzzuaP;eI0<1V3e{+af)>ig||i{Ux#
zL*wQd4*W0MUlqju2_2)}^g_maAJ2SN`Tfi{vOZ7we?re?I5d>`TpRVCwX?iS<72uP
z^_sUazU@z{_m6sxF7}7}PUf?QFup?1JL7D|7d=TiawqE<(0(aG`{00|s5kX%+7pU<
zyDQJfpnXNM{3Ol@>Pi2A`Et!_*G~-lTuixi8vAo-17*d3Sk4vAdMv+XIm^4W-+wjZ
zz5N)Tliw^nMfx?qgzEX!^wYi}AEtL{e_V1V!x36PHf!Ax63F@^R<WKa)gPpBa^wZp
zo2vQ2{71IKq<o|L&Le!Ozb=8YHJo~lK5S?9OO*MmDLqeOzOr{%uP6SY=SshhX*>+w
z&3dx^7#|wRd;#j$A?@?>@27p4@;e3TJzl^)*cE-*vd5|SDd92d?Mh~P=3~^qu#3{?
zZOWQeOz)BXf$Q0xz{e;ZA26TqX{<l+OWIeZ_a?4_@l`q0lYceqZPWLap>=CrGV{e;
zM_D83l8n*wF8C|!8<oE_PX3_uBG%jG&-7Mr)gynx^f~P3%paI9_aC&sOY4|{D`?-y
zcGh2a1M^p0NIgdU<J6UY^pPLQcbs8^{9(TGSJ|{~2#903X?_0-Ud*2<y*2WK+4LM1
z?xNib-&1yEGXJ#p`_oa3H$6(}t9fuv`>tN?t6eYad49z9<^O|rIId&3S>Nl>ddB<d
z{c=3S@Z6`=->ZH6LI}f6o7o?JJ+y1|d-jv{E|%*kq0G-`da~9pj(1t!PvcC!iRt!g
z+SB@Xmh;y>-!x9W8AUADHL3dVVZ2lRf~x;A+;ut2_kPBFaqFnpTF-jo_EUzYFn#)d
zhK*}kzWF%julOC)ZCdvxtY$y<9%Ool_D8;2Pxj=n-nc87UMBxxvihmvea2gG*MH@`
z$=CRlul<x;<7-(l?J@0O{$}Y}_yfZMXE5Dg=V3+vpxs3yOb?o1x>L_N^;M=<l(0Ry
z@qBI>@^jhreU9}oU(giGPq)*~A&o;$y-y4B7ntOy^L~uwdP~{<f(Vvt)BKRD_rI-+
z>8X0p+tSp(@+0;X(ti64^;u74x@$e9zuv>S1ogun=Bv~BM#opow~)nj&&MhK7Aafr
zVY{qaH{n>||DJ>AqfAfNIGub6?KEtlew)^<-dZP?DPND)DRBj?*GK-cxO-Vo@<kdi
z@LPtJ=bftWCpC|H2lT#X|BK<6FR5qbHHI6`p<Ure*KxNo9HV~C-$%VYS}%r2(r!}}
zrMI3(#Tu5ImOs#{=a=cp`bN)VdWrnW#$?7P8)*NK_Rnov&u52Izgh2B*Jg$TwT?@c
zpD*yJKSKV}1{eFKb(qqeLi;PUelR`CcDKpD<&@vudO!2oi)mN-?^(WgBc)U0XVBXW
z=ND5?MlIVFw1qONoar6kshs?c-p4TA^$_DTGt~b5)Khj3!_7Lkh<S%$&->YK-vO4h
zXnoP!t^T-_`FeIzzx_Lg%l^XrbKR8g)0p3_@5HKgM8Tg~ZY+p))K#+|+)psvQN{Ec
zg?%EZFJJF{@0+a8uJJtpcMMkE!wUKB=Jeg>Kh1o;x3T=Fk@<oeXji`c@YARAeF(Ua
zGOnF=<l;9FD|!tEhEpB1D@yqcvCN-wJoQ)T{q~(<xZnoX6Vl9Z>$R$PRQ-j2p1z{L
ztB}(6G-b_a%;$F>>#LHV*i-BJf;X6N={@T89Avo4%JB3!%Lo33_L<d>rk5FS(R#T{
z>nHEm89(<H>udOl_Jyl|{nk@&>UpfkqVcU+<9fhTOpkb*dc5`g$No!wezi>ZzmfJN
zlrnx)ew=BIQ@J{CcE7;-JBnCev(|&=)zojy;&Umvlrq&#ea3HCZY-Vk88t37eZ+Dx
zA5-@Ji!z~)`AqFBZ;xU);C0Go?c1!`)Z6?l^SR|O57E9XHH7VQzs7PEJE%WZ>kfnV
zH&L3ugZh|m+C{z2H`tEAH!0I4>m<h{{q{569nA8cleDK~v+VbwtXN`th5T}@yV#FS
z!>n&k{%N!Ph#`NK-SaG8bvn!UTuN#Fp7Dm`*v`;chJCe8G59gwaW3^V=>AUJ`HXM+
zko9}EFug|m6F=>P5;V>QsGoEF*v^Enm_Ok^EFU2M;ez&W`Px4YJ<fc&1uPe%{Yl3s
zD(^`<209o{#&2g<zPr|Fwl8!a<L&>VjM8@;{v6X=bq~O?f$cVGTr1E%IAE0e^0m$%
zx`XAWb?)U>demN)?@@o-bY2?rCG*?Q<nxKqxoF@l<BQ~%HJ{7&h4?T&V>R^!%Fk~$
zslOW;Un74<(6_WN=oywP8)7?`u4nv!{3da^>L2;-QX3d9lAp|~{dfBR7@r%d=kz*d
z(RH+cTJvl6c??_hTtnoCXj1**nm;S#*EZ@r#-e%BPyLboSK4iRl(Izk3z}mYuF!q5
zX0^Y;kMS9rk1Hgd^3(Ku!t~Z2+P$RtKfR9a@;R32z4D*dJjDK72w?tE)!%wA!?|Xr
zw`zaU^a1tsmQv=cJ&t>suS@60QL-!JCFTq1<MT*0QLiP0GF5(!2Av0F+)n$f$MShk
zCQ)yuFY`C0QBSXfvO@Fwq~Z-)56#`p=QHYJd0QIwhFr_==)Wl!^xX$)T{Nk4*1$WN
z-|ay?nZKhwt&;ZZ*e+j<N6lr-pRMza>339K`-t4N)MIO)-9^_i-SP+OUAmI(^VT_w
z{}S`{d`mkGv8*rs3d$xur;rmFw)s*<yg<DTH&MFe*C;Du*!l$ZIR+_PA7MSs`d<As
zUPn|i-fxh0Rmg8r@+!kIcT-=4h4n`1{Hj;;L7S239T%{k>`=CUNasve-G>M{dY&l%
zusf9cCSzECy4Ks~Yp5qz>kPxKv}5EJ$|(5-QdOT-_YXsRsHb9@_V_+bJ>Inprz<_+
zKIY4p|8U?|h7H5aX9}XsoTYtZT5rc~qQ1$OXh*_Y<_p#OXJCo>P4ZV69%TO1>zF_N
z3-(KZ-tVsWm>%*b^;GEmeELD!<9eF$0d<tUy62escj_t1VSSD}Rj>RF*}9kKsr!Rf
zan#p#p88MYWyfyDTeNQK(D%`LH{(5JPwrWKZ~bqh9d#Oi2eva@P)ogIjSTx}-DVD<
zUD;Ps-;(;NLiaBGw=sXk&&)R&&+x$Cm0$jd%t5A`lbP;+gy}U~DNX-mf7s7qKF7O^
zcb`PN-5Ot<^1F>`KNhF)+k7_jdH+oPhP$c9Xr~O+ydBZSdc3tx>ewoKPh)(Q?xQr|
z_sJ{sa)s6tO|wkTxS9IwKeAk$h0lNVEQY=1=jck)d+|8SHN&B|qHipm?dqLjdedIU
zoBJ6a8l)cIV&<#ZOFMeBe^1u9Xt|x`GS%Nj+6S049ye$|5#^x1R?TlkUsJEA_8Db=
zW4-pT7+-S(!`WIVwe3>>y+xU?`;|TNOSIn3{C?VBFa4VJjpS1XX#HmXn)do?JskBi
z%XP?)>??m-gZ##J-9xbMWxWdvw69G5fD)DKsiU46oxiz`?kluk^gNmGMW){CnlSdK
zZxZ8e9xQK7r2e6knC{F~znwwZbvfhF{QrB7K|5(zY75Jk$#0add13BKmW#QDvPkzo
z6Gm8WMBkB9excBO>Zy`{*VRvZ7Bmj#U(R%s&RZjHW`9n~FH+{#^BJWKnrHc<qke}e
z+EI1%``0;O&*#)zqI)(`x)%|rdyEb8&o_IpzeeQ8&HpFMc|Xs3qBM_&)-c|#^?rCZ
z>-Fhke7gK9nc9CjPG)?E)_E@ZH72#r8n}z)GXg17HNV#dvi+&@D=f)RJfwYhKr{7P
zA7;6>oy?#75W_uMuNM7{;eef#w(}^LwEvjX{??)SIYNHexL;F$ll&=TiF_|II$2Md
z-b1JSFUdysU!B%73ohm#>*e!mdXn|#YM(fHBf}>3%ZU7`4d*i6T}T<w%>HkPWW5dY
z8xLsx5G8+0jEU(%8dt-$F1E>^U-KaC=(v#j%$nbGqghYFX|hx6lM<Z^haX@+WGGx?
zVLesy6Ls9c^10P4A8`WP-SsKMHu-0(HZweZBGX6TU^t<a<$Eq;|4kM$e&9If^9x{n
z*;UMEjiEhuji(g{8K2$4{2^M0H6$`V@D%0`{ed!dn)%{%53%fcrOTh?t$kIX)`w;s
z46lsqqsg?(u5rky`8?zq#uqiSU!2<Krr*qdUdo{U3hnEv^d4rWGk?DBeKa4Uo(j!-
zz27rj_A~X=-OTokjZ<Id^9<)|zVy-lcR_xgxKyV1Y8*7a#B$C1DO)|6?)VL5na;6-
z_Om`e-LFVc`Dytpt(w;(a;e982JLic|7-Y`Vas9a^(mnA);O1{=jo7twIhytjPe^*
zXkQe*hW%b}1?`DTpq$ouL&C54UWAxf-dp=8Yd!0$JD)Nroc2t2GF&6SMVI_|j*nQr
zLw>CcjXO>HU4UEPWojkMcl|^==JXz9AHAOy#&qW-(@k2p7U>>Sh}O+^wbNVv4j<|7
zdW?2v%TMGpO+8&&*IBfG3DUYIq=xBHA5i9M-xZ?!W6sBEPt5gf-`G3M=jqLU?Hyp)
z_%7?MQvVn`_+Hvxr7TEcdH)+&Zmxj&jk_40)c!JA{=u@t%x{00`Wxb@$4}??Wm;GH
z-OYT-@?X>)Lwf@?KP{*~E&4ul-(db$J$FC-j$u;mw_nKesi*M0nA5#QtNeZ;x+mdo
zqMl}rtH!;wGp>~F$=CYCSj=`VoJW1FTHlUb#CrU74r0EM?Q<QV9{U{i^l09!%c35K
znR-ICZb{cZBz%DObg6vIKbgOGnEK`pQRcp_{*qtGN8fj*&Qn6PpEK$EpVND8e1-PT
z{f2sjw4aXq6Yb9bC({F3S&vix1GD@v9X~L>;!@h*^jC#{&2WkQVb%}zKKzf;q~A^X
zIjP@Me&Bq~OBRiDt?x0t`Cdxz@2Edp_f41Zf5TSB-|3eaKXeK6Ra7zFQo?pM>3bN`
zdpIC})R_Dnfoj*7#^Hv3w%<qRs7t3(pHuT;%nbF0KgW7K@&CbA?C}4JvO%&!@kJl%
zz0$pxip%x9%V_V|I;LCiq&~C8+vX2hPpH;Ync5#3<*!NYVtpNNvRs1RPyeIkQ>oV-
zMmgX~eI_r;Hr)$|@TVOyfwZe)4P}Sc<^H;l6Qt+lUe9_x|ITtDl0DiN$9=(g<2B3|
zbc*WprQRB?BMtf;icR%;>mKIZGV}ZD9-~p~vWQB?_w45LDZ}qRSNc8RRMuCMLOHE*
zqWMhLm!bAp%GnQf8b9qfP+y7O14|?IWq-l`tkJyby_4a(E2+=#8`d*A&hjBT?@c(u
z@<xS2$C%zLKSV?n^<+k{y!{Hw0L@G8)0y9<_tBtnA?_2FYYU<NF`dJdnONT3&i=^O
zd4Wai;PkJU9`O@pl=f-a8Yd%uq~0o>N6l#++4g(pPu;`*a-2@t`aJ6o)O;HLEaTgZ
zl(}1I|H8X0AFz+INPen-5r$h&WIsm9f6}0Jc0n)g$<_X6T7HZet$$qqU_0AdSzqso
zlndGyW!}WF^*7Ad8%}#`s%Te?{H#SC%va^d_@bLA1FvQMRy*y?R67>5&heIia76E?
z>u5i^Sbpv|)SH^fu#djas2^!Zvesi6THm;ij(d8KBGm5=-IMIqz9!)^>J9IvbZGr*
zk$=P0PP<37z8c75*sO6ePWy@;+1D(+LmDS+TF<%V7x4L!{b&E4^^N2+Z2be<5u<tC
zPxGlWkNwp!rF>dP*F4OAsOzTe(!AXk!u+0kuRS+1yr6yT&|%u|8>x2xmwKBHP<BmG
zUzyeoh70&Ujq16F>iKo3ed(H?;vSV9KTuEEv#e)MenZdI3@7KYUgI#OOa7x6`5Thu
zS5NPv-4)-nT+9oUL$^_mWK!m8KC_i6pQqAyvwYnBl&!kAV!M$2T%>u+U-M|(>1=1d
z_SK=2Y)|;b%<s&kz4@<Dzwvp7ty-Tp`Ldo6?fYz6Urp<N$Jin2iO{)Zo$d!!X#Lxh
z&hnn}|3zqiwrTz{<HE<vcx;%UU6X+fr^+AXqkUR}{9i%xD=f$l)tt-c((9)Esq&Kq
zM6%tU@)x^~W4f>IB{k{2b)TgEG_(G6`Nev#VEG`eTdK4Uu+LIY!=0?xQOokldY=Z=
zkN!Hhi`%UC&q4h~FEbpX{ZF|3MHzMK=VrFQ<|5`_ili)9pq$jbm6(h8oZK#!E7Q8$
z^fkkQy07D>eMOPJ-*EXcMs?mat^H|u0_z>nddlTwef9v>lP>+PKT-cu3;Q8o@42_;
ztpNGirX~FzVEHAz|E2@f+uEt;AwO7=#>xEE?Dt&x)4~I2SBS==GWmxS4pUE){9vOS
z7%tO%mb`~{PU?KitaV^n1nbQ_hxHh~pnVIvuQ2u;pN~cB@?1ZrH@`wVI?iEwkj4S`
z?-=j=nDzT>{pCt!I791{hBoFiYCSWe_M6hFzv>an3VqjgI*%}GJ+dS}exT+L(?iT}
z)jpy?{)e$t+LwI>rSl`&5$<5Sr#1dIHL-tu<p=N4eSYt=m_I@H0Gh9--BI6A_5`!v
z%<nL4lN^!seV6fONt<N$YqYmb{v@~j5%yBX*Oaha;2G5KeIw(W|3W)^)>67JrksA9
z>8(1q4L`ar)%tG;j@OlO#ZUKkazACcO!-qiA7y=$x_6p-GTWUgKUy;WH}FdNo@1z|
zsE6re8ed~RVg1%X^_TWLqo*=H?hmZb?^2dG$S>ES^9if+1?qPQ`6JAit@Nq{wNv2`
z?UO^UX1*%b*Q)U+V1oH0lt1Qm=JT(keL?bbWo9!Ru63gSa||b|obxKaHwE)7Kd0ZV
zmnpqYGW=nt_i7yN(*4RIr8nvO%+@*gXglpI(7G&0^|b0fo=xi<pK01-*~a`O+TTvL
zv0sfzthY$-vwtJwUGk$WG|+yF?k)Jd%k;?<mdmzK2FVXFb_Uby^nCs0{}0qTXm~W=
z$Cz`O&ndrbs_qS!_0dlMUs2X|^S!bBz_8_JmJ4`B@gK2%Z~1kauV;IwbuYpGI`bQ~
zFExHbJq<52pH1I?*?QXL`w`n4^?QZ~v@ULVk$PM|vEDY#FRiCB-dE?eKAJ}zA=0Ps
zKJY>69lMkD_iSRhUN^%DJxtGdjqPy_QO0S0Zjyg=`U>Xjxt{v-HGkMO&lz<-)m+GY
zLt6I@e8cwEss6Z=s6Tl<Wv~22bMjMU%kMb)7p50z9XonE!zC8>LzVWY;To@_w9m7>
z#CA2G&irnDkG<uxOV8c@Ci|gP<pQ*SH2#V4K0Pe&)cZ7`^;WCa9ii%XPwfl+bEv;e
z<6`zXv|~>D|E>x3-%XU(yV);G|71PsS&Z-ffb}nZ!T2Eg*G)Qy@Xn#$x+KcDKIV7n
zcX|Had_F!}cgEFHkKZ?xp_;EU{>^e_fs9W*+D?7%G1}*N&N81-`%kC#_pQ2j*rD%f
zOn%uStw+iZP;al+eFIOhy*)LQ0Z&qfgi_l6NNLgf$Y|noj*`FB|1S1V$YI70X+Cy#
zv0TCu`y)foBmFtrZFMl+c^&)3pz}FPEcLV|GhgN(Xm8i)tY=^w<CoN*?h~mePWs)8
zOpo%T-l168{~BfZkCa81)2>N<-=@bHpKv?tANZN+qxVpszs{GswEi2>c}km=_RVR$
zw&{25+4ASPUS+zc)`gSbQ*VKO2OGG+`ik~5-lct4Q5f4hrgewg&2X;T6?i`N#=J?p
zGZ$#*r1tSP{Vpk8_jue#*ZDeEFZzn*^Y3H*QP;8l!1Ji5%}u=vuQT1P{i~nOvnq5x
zk*)bL=q~EBYCmf#WjJ|`dcEc6GQ36o9sg$fwALRHzv1($)A}@d1KVr)y`H<`%d)7i
zPUm$#%M6G7jrIm4Qh(F|##`k-4*Z7krr)q$mmj5%)^Fw$SiWXA+iUxW^hHxTkEcF=
zPwL5VQ98749?-e9{~e6?m47>2{(!CwmT$g^^@i&lVodvnRP|fW+0y$q+uf^vF^n)i
ze~j_QS=w1}1>+4)#`~y$0)J*bT~?+Cby9{OOF5u@zV9aL@z?zBsHUFge=t7xMcUna
z4#UQ887?@5`7$&gSr%BIRr@_3?H7D?ZdkIG^^PtwpG*4!AK6nSzgL;o5p6c+AJe$A
zB)@sgzgd5T_GwWz^{btFGqhgvmp?gX1NAh^Ut6O6y+iAV0j*!#blzgp_&K2U&B%jn
z_o(V^2;+NdQGL1Xtam{7Xw16bwlKwVCaoJvlt1n<=5K1G3=dKN&NFP(Ib+*F_HXh!
z))(+QrcZC6EE!_CE`PqCOJ_6eDgR1_=HCdNkCkj;dfn@kCHkGq=yB{Hf89^<)4d+I
z&cBA9W&R@V_haNIFVlHY(FE;D522oL)$i8&xlH46#xu-k(fDOk{|3qLI`l5v(eViD
z8<T$^;9iD}i7X$X^XqAyUzbd?pW5UX_Se3o`2*&+>7GpT(RBqj9V`2eINh5I)q1oo
zfc@<E5Ys2uGMur%`m40A%+R<Mq4}X%{y*n2dS2?k0PTa4(`d)^qikQ7=7*SY<`2=j
z$LB)!Uzzq-fs3rSK>qliZtAHxneiFb4A<$qHpx$K-p=$Wou|b;&TzB*Atk}A$5ZRu
zQLVGuBAIVmzh7<sBkgl(o#J~5`y*HP-|F;Uw(VoNQLWPgE7*U@X2zQzXL#-cO7lV1
zUy?u>r+#Zane`QPvY!kk%-<k?L!jozP(S9IypQc4IE(pBXH#0dSa0}lhC{tr&&Yes
zKenIJU-NI5(ld2_m+H&(0<DuPG){*8jrLT1O}$b6%vbjh*5`bKc4hQZR>iZwntsQ0
zAFWfT^*e;7KU0tW5cB&+QNKa{fD-wQ{qLmxH99|S`<(d={mk#zp?1Zvp2@RV@7Vdw
z*DQaXYd!1BK9~6iE|cBz1B}YQoT+_e)om=_s(V$Ia+WK(l;!HQp32vEmp{V%b&X69
z(RyrJ`%~X*XqW$gXop$rg#eu&)XDw=oBHJh>a$y@FI(%xO!@V@US_{6X&=?`HNydV
z4sM-)m1$n9(tg*a^^#HJK=|Keug(+f8qXv0X@|GYp$f*>e*2XAJA&zT@=LaAp0E24
z(`~x9=KUK!rx?i+NsG>RoccXO*E;5lIGNJDmeQd0oY5*f-=Z9OhW(Sd#C#U{8Jje|
zy7YU$t~Qm^c|mUv?T*+<J3TeN+5SmAb4`qIE1`6&-Tp_|zved>A0)qU-B*mST4ed@
z29^6GWu4YJ)+4mnq<x4@elmx~xhTCKMU%8Q{|VaZzLGM)hwo4F8rB!|8^-(3F@L(&
zU&dD%4%hc=);*VI?N{vOOkesv^+b3wT%+^j41K3n8)?5;>wM>(3>&o1uF-r^VPpB}
z8<;-Q&v1<VPeV_zUxrpO-hYPDZK3@GSF&GxHJ)cb%=FNQC>`fgCd=-SM_A90{5oy&
z>qK46_Bb_u4xPe$P1<KqKFRRd3Cy=t%X+hQkE=-Uf4KH51zTBf>($I>|C;4f)ec7=
z(_=Iq*n_Cop?Pme=kTriolf1ke0~O<$Jlf}+;I!_TeV&(dV+d=^t<P2z4!j=7h5Rx
zEF5OOIr%fg^*-fK(hi?0_HUWqzpfkj95Uqp3Xs2YPV4HLc&2;*S>?}Cf4#zb>}N6E
zrFk;>Z?xNdfcb1%XGXlm_@EM&8}g!zN@RJrey?EHIN_;%Xy%v9*Ab)gKhcgj`D1%D
zZbWo5pP`EN4%AWako;CnF2*}_{~-4PrU!n`{#f`c^^OKG-=yx-<X*$D?{!Qc(>ga!
z@4HFwVL}q^oAYMAblq<^YCSf2AM0^^NExE_u+O66bq^&%{(&Oxi;|D9{!IC~vLmTK
z@Gq>-dK%l^bA&QCn&~lmKL$pW-pTf6YrPcV&G-?mPdzohInQLgS@XQV&Sl2VXM930
z?JbaBVnOroh|cvU<&Uu4OZ%eUU^%<|z9rwWeAhwB@a?p>?kVQaOyPSR@F~-6hgd#W
z=Suz>w}zJ3FSgTJzQKq2=Hz$H)Ox%`^XbTL=8OA~^*A+NMm)uG**d=%&1Sxkt?aKF
zos;;##rk^WFO3RgxekBIs^e&Ho9;mc=>5yyN_|G%Q>)Xw()%XMjg7HfsP+p3&$6D@
zaoRbjb-qRaCn8z%r$PQRAFX3zI;qd1eO!-=<;QgY+N}Ld_F1&Y?>N>o`3A#P^UR-o
z3+)-x{1LR7>2*fNn>5dLWU{^}?W4obV1HSsnLl@c`dYPKGp%PhK<nyo?H5M=$miYk
zG|QE(VmMp=kH8?7OV|F>?=IHs(z$|J?{|=XUlE}3J9UWqGLN3?*0a5Hqb%Q{{f|}S
zLB+AGC+c#xGxyh&2H9Jq_ib8!`OM3i-&1~OZ{0JpA7niR8ZQdum(0+5rTI46)h7RO
z(-gz4KeN6``C+}~hb?f?UO)M3oCfA=9%H!#`BPFgkNa!h%QP_EeDr)><4y0kv~TEB
z>NThHxdq%rY3^lug7$wUAq*RIE*o|9-t;B3BjX)PV;A$4sobd6rH*{Y2Wb5ja=qG<
zMf*}C*pH4D%8_j5kCUImQ~PY2&LtdM_<odV9v#)apQ2-_x3!OYGH+#gLH?OGtpj{@
z4=MdyraSJZ9k~y(-qe@a4+ix^!FLQ7>Acc(1M^Q-vApN!lq0&g5wn5z#mRrwdp7k3
zYW!@to%zRRDFbzG6;r@`B^tld_1^SqUJlVZ&Tt~@cm2%#OIl|vJ;3nD2Yenrx<@hB
z#&Ctk3yaq6z1kNqX<YWvy4&+f>UV0~v|q#iOekc$e?RLnX?^RXaXj=q=Ihn@$JkeF
zpY09SANn23m;HhHth(p#vp{_Y%`<f>*QRw%l)lpfGoOQ1`;-E$1DmvNDA733Rl|Bq
zZs2pUYh2BhKVedSxj60H1CpsXPVLIjeUm7?*B#Q6KTG?k<uA*4h2bHMOX0e2)~tHQ
zv~HZMq5h>q><8!lY=80tl(u8p{spzSNA2qQlKH(gA5Lmrvn0Rj<a5*;qjGgWu-!gK
z%WEIgq<PSPl=eFJFkkBl42Q3y9p2jSFV!>N`d>Xat#1Rb(s$=jeyy8I_A{T4?loj;
zz6q5dz2OksXV?1FmPq{zf2951x~G$1(EFnK)kpgjf30gm^#0oAR|pDMzdpnIbDJp3
zw$i?a>sfF1HcFe$dtx4E*hjx_u<QO*mA<$1o7F!$NAc5o&T%5+?Lq7Z^DgPvy1@Au
z(+hs29VKd)Wf$Yq@1!(dPP=<I)6Q(^T`FLD(~Xpt-!k1_>$MuK=Uf_RjPhT#y-qu(
zwU0>ExmnZmw4<tudV=&_M%~W-FUe)Og}WIJ{gB~-D7MdWGQ)nl=TUSl?XGEO{<aFr
zA?@$;?_>UvI@TAXePF^8!*#(-kJI-Or*jH_?StALp}le1?<Z?~tI+x8wESDXPU^|H
znE9<QQvay@Dw%6(zw=u5V}Z^;L*$pqo>PBpXL&z8AD7nCt-2=^YG?aeb19oXWxd&&
zr#-J`J?UC6+B>Pw)69IP0M-*Vu6F&G_LOKJIihp3p);w+aD@5hk{KS-y0=E_;ISO)
zjd_oHn`B?rWegWRL0NM;%MU!G=cE7g;UA-VE@gbk`;_kgP__-Sy#4pAXGr6oPb0(T
z{d#ZTrVRZn<8w8SM72^+ug-TJy64~%OuYlQQ%>s~)cq*KZF^a6VVU|8!Wizlfc;_o
zHTx~*kBkqhW_VP7iEJO*ldgMV9lvG1icaeD*E%@xd)2>#dSmpSm^L!MOY4*HVd^()
z+>IJ#{u1pwMp~HP?#=im?ay4AFB<gx%tz-{t=sc;kI#Da_q!Ldo}hbaXY2LU+i?u#
zLM&yV#_tOCgYit}AGt^U<)og3YW72*<`=(zv%SWhl)b^s*C2nd>vNX3?_hjrG-X8(
z>-GMC<^0tC{0XK{zRG$=&tiJI)-}mrFuqLwbyqg?&n2-QziZiFb<$^&A2wU(8IIRj
z?|{CKhWDw@^f9H6?jd+;91GAsG*`d#^VItq_bT;t>Hb`d#^KQx+GEuEq2yG44-0xf
zI&}V&dphg0KTUg$+i8D#2W8yRbHqc;7q0bojPy;fqu!<omQR&GZ7!I01!(<Vl1F`^
zpQ_#3SByBRw`32?+i#_8YNkxz&HVZAu|0J<7cuJIinEyUzM9W++nC=ezkA0&S#Out
z^EJBHP^Nj&Q}=oo^!-?eW%nbL+2btVrt^X-`6XgB&YDi=d(rxg^0m_L-nERM)O#7S
znf>H@w12ce36Y=F@gKG$W02B3Ksh3rp!6lpf7z$VPK7i6%=(7ZZu>mTw<+AL@3rYC
z#!nW}PVdhc9vk9wupFd}@}Yi<<^fOnH>~RS+#sgsYMoZ3_rv}f`ypx*+uQa9!*TLI
zrryH(Y+66{Y8~3Db#aFFC!;ziP2WX3-4{@w<zm*`q4&-^jruFJzZ%v1(VEM8lC>{O
z(D_l%(ed;)>TQxAs#ouMkmi#R-K!3LgnF8fj_a$~&rRC*G|2DRrF)8gT940l&`y`u
z1#Y!xLHilY%k1ZYCF)PVlkKSbhUIFS8Skm@IK<3)%dVv~>wauhGRxUtq(1*brcd9<
z_=xW*YqYNldXf5jG>-VIA9F)lpO5a@+FzlbN$q#ii>RlrgypM(`8*op8TOOEF;Meb
zv&NmdBkbpd`>4M_=S<1E&rqiIkWueTPbKT^)pIdx-R!CJBEL(Ro^ccPSr=)SS?lw$
z_n982dV`8+-^k<aABX%ww$+UH|A^&1Z)AIlv`=XLGxaA=GrdalQ-r>=>@lV{oyYch
zYJ3>dxX`3=eOmhf)9uXHd>-p**8J_GezDv|yPNM~zApKN!oQ`Rqn}YW%YWEoWBmcY
zV!I;rp8F@r?w@G)q~7Dqzp#8p5cRiezV_F>#hQOHfB0caV<DxvjM7p=*<+#oBl?|N
z)e`kpy+i#4x*s#Wfp!=)&ROOE8W>`Hjn*3>n*VKw*nZoM)HkH`hO^ne<Z9~A{U7b9
z@?!o5tt;!~pLSkD`+Bs#2`yu}p;xIl>SeV@{S;Bd_=+UfGo<e!_4m{>y`T2F{HZ53
zjQK}&KfY@X<1=q&d9%(@8hmMA%t@31lhl*>U*<27AH^+c)p?0k`}8`^`v&bxT_G&r
z=4APV4^;0B)SsdA=osZ6%3*r0o|nzc@-aIZZ`QcwxQk)aZzwCSV7>~q!zuf#w4bht
zWBS-l%pbFr{gH7Y!%KHiCTsmYxxnzq33@Kqu)O6dK8Koa$^y-!xz94aO8$iWLWY-4
zqaNb~<$%rwisb*P*h2jo@{9J!o?NX<Ds*2oS?hpFeb=6O)L*ClaZC=wp%s*tTUno5
ze$fs+rvmMlEt9lA<Q(S9J(K0;!r3oA=kmR%&^;5U{Niz^GQJ>>`CJ2(-aoRu;{el(
zKBb&IkIy-CBim`5XMF{-e@=d*T=}1R|3*EgYpB<mL>Z&~ji=rhlji5i7N&=59CZGf
z`j>W7PmS&q49Tw(cpmL?R<hiH{NW`UKm5*Q`Q-1I9`z;r$xrJFqxK_1@@GZmGrg{s
za$5cupPSik#}?|dYhH0*#BliMOn3f+;hr{@_f24UA&+)O==~YhIbid#?8g$lmsZ`c
zXxPj0UD{upwU5ZSoAEvx7e;knlBszrIh^%5f6M*~RlD+a?i-iP^xU^7O<G3;T)_Ml
zFS4I1^!@l;M7#Yyplo$ewvDTO+Rw~AOnn7I?1!OSn4UaGeKBt{oT_=i;L!7cg9BF|
zJVMWBKZI&O(WCR%pjTMV;lX^PSq$fE9GYIuuzwfR2lSmx%deKcOnZ8NrkvBbJEr@I
z`H#|Wqx>K-+6P2@#{5eq)SIdK(kwrORqK`-`6Hs_H*EbA%N1>4Kh4RXJ*xHbWGd|)
z)jWai#s9T`N%L3lG{d7V_Rri?>L;BmxL&6{Asd-5Ti=mI=lBt4GJl}vgI*W&=Rd@H
zLp7eJe#P>WlG#5ny-oYWDBTwfxL@Voquv_T(^0^1TpIf?<6g>X-FGm`pBXpLdd9w|
zbZ8u0c$#59&Fe$wQ{TvCtS`t-yL)v1uwat;<4TzBl0V8_$#B8Fl)mye<!b%x@a22u
z(mF5hGuAWoJKAeKIzGtnW4wd)S~YJJ>HMzlC*~i}I&sNU;eSy^T*dlrdngSWZ-(Bc
zK2ME%=~|anXg;(A==oeE`!(-11kg@n3*$%cW!S9#n|z<~o@11LZ&DWMyARNKu%LS?
zsk$#|)Og^hb)n;0mTTTm{WkfpdxvS4J%sOb^VRJC=2pdPoz`}#=79|MgROz-O}ane
znq+*?3)DZ*MH%-i#xI=Buv_c6Z26Z0b^j{rKdiq&em<l2Z@F66dH<dEhwDAheUN(7
z)ehSv^~Y2(-g*)3_0#+j<VSl=|D*KnmHqOE*|a{b(D_A1BGX5;u5-xWIHY}Hk^HP9
zTL0vK!Fn^auOIn4%Nw3!yZoY=KBD`4{t*nv{FbsQmhBtTyq$k6+tV??=i%z0o{VFe
zKmT}*quT#2Xq;X+%=DnADCgd#9=|J8&o`_mU-f6MVmLs*+xM2AsZ0CX+y<8O*866Z
zJ$8+g))YOr_u1Z|G)hm+d!Bn0zk~IZ-A8?H)o0TBc~ale^eod2x|i*z@6~cC+hNjo
z)u#1TTL<-5{EF$5`aO7;{M&A=>svLCHlM<N^XX^)Hl2@Kb-wD-xk!cf+o>tkAFAJp
zmR!Z>QFL@();v+C{og=2?H^Nr+x0$$yJergm$q!`_0#wt@iWVXr&1=@Grjj>%IP-t
zvn`J@^Bcww+)wE|hV5FAAGb;K^@!%%qK(X#@2%(mHtiWHXV}!o@LZ<!)iK_t{i3(t
zs|>A^JG4Jemo(kOesODl3Cd-8pZ`&>kM{3I-CJtX@1vaGvc4`e^BXl@y0$Sqa6Dz^
zBJ(vhQeS}lz!7@Co3wuLf1LTdZec%qw$iS2&D%DegI4J|TSJ+zMC+Q4%UQl7ishO=
zWqMUD>uu7!>aYE9)g62uQTiTgb})a0{2wc8o)xT;u1gqh{TIu1X&xJKu$=YicV*=B
ztm&scWnm1v^xQI!u7`C#<g5Gk$@>2&MbaCm_rjoZ&G)b$O<J#nR#U%0{_QfS(sd3u
zr}L8`&0nS|+HHJ?{Za7~WtYx9j0+6seoC1+$aalrJz?L&@^$U1SMyZ1{;#rC@1c+G
z6^v@15hTBsQ{(!W?jbK}f9HQL>r0QP-k94Mwn{cU#dbC5{pu;ET^$;y3T!ObqxrK(
zcKGRDdZzqwmL%p|c$E75Q&~^clMIjQd$G?^e@VHXe+Ane+QxkLWyVj+A2D}3^>oQk
z*>Uv$MR`!qkmir5ebnRB@7}t!UYyi8ZPD-4($}$`IQe7UT3_X=|JpR(d8SccW+B_<
zc_PCjMYL}~`)1FlsV^5V^2+->s(rbmSmmZ@|ET=Vrf(T;Yhrqre%}zPbHl0(>dEM#
z-h@32yR=?zDq_2vv`=j_F}+51xOJbmP3!Wit5{#Y-W&5;make*S#cu2pWal~w{SV7
z=>e9@O`#mpdL>u;=7w43Yr2GbMlYxI(RqTm-aqq0>^Fz}Bcork-9gV&I&{uEP{DRM
z42*BkJmekCaGCs}rWxu>{R8dl_&v+H|IP4%iFSp{KU1J}uj2&9cj=sFLF*!y)+@FN
z+CQoDjleIc&*aDWn9VF7pnLFLMYN+%`WIHSAB%L)(nt3X+P+u0TPW>1SBud;-gPYF
zLp2|ye$RT-uVTGLiwZx(e1ZC%i06Y0H)tImq4zga>-+2%*>9}}s3%wJkOHlX92&1%
z<;P2ZNB#Z<^)_oh3+iV5qqWpib%?SlitP{7{=iwzd;>aX3yGzk3Vp{Tw=q1b{gmM)
zh65ht^NZ8E(^tQ9vpvA{BHb_O_>%cz^!}A--5C<cez$17)U0`LPV;QG)+_1Pvizhc
z^C#&1B;+`T=k#4POtK&Rwz8cgdJg{2vwd?n&@S^D%7oXM&!FEaW@`O5DSuP`CfR*D
z^X1Cl5n@xjPiB1AV+<GRKCtsS*0-edtAUf4&ohkm`fGjXGe>)^dhQP0*B*I}`BRV1
zKRparT+8-0Cs4ml<5Tt$(=A8+89L9%k7Rud$MboI&a%Eqox?kH-e#8H(7S_rrnP=>
zY5mcl-%%tVT|djOA63bAJG5?e$1-erMD_hZJ1rNp-oQ&J19aY7a4XY$?w}04Li%>8
zpX5)m>N&@}#qt#zf1IzgT#fqIt$lBT_7Ri1-#DrHyle~G=Pmzcjo!x?{cg2J-+69{
z-VY09llBi8n`vKWF=fm_+T(jZ!^!IBks;PIb{+e{elnk%OZ}0meN>sG&(ZN$>!Aeg
zf0w>x`K}E0;{wCR9Sqx#wqJgs-euYwbPQ$qpC|+VPJ8Aw9(!jpT&8u_kj9}=&7Tzo
zY*(-DIT+S4f5w+;m*kxG(M{vD$0$E?s=oV$uNhyYd-ffh7|w2^{&dYl{wK+9%)%@4
zaE8`Lqm%5{CatG~PG|Y3DE4Q*_Bol_S4Esp`}{TjjB1}27fHQC&$7I)#>)|{Cv2Mc
zjJoIGAIf^ewZ8ArI<w>Gd9lXlxv!|tp>?Ux(fjt{v~NMb8~4|`u<UHM(`Msyj9H{z
z4Hwbwe4WDt6f2*eTljvaM`->S(KzH=%kqXdC{1?C<`ZTAB<pF?eTl9R+Ldq>Wkxge
zXUe~q{%htB)HzStGSidwz16)$y@qvcxA`WfyLI2X#+!B;H9wZ@XL{FlY|of}N0_1a
zd}JHrGxdGA^<DZsK|QYHSznai7lZuw+45JkYJTl%l^r^N9{3l_*`==}hxJ(Gr#9=m
z40wU<ZEK~R*8J{1!up$<DVMaL2-G}1eLeLx$giI8BlDGL-EVx4{ZprXt3%^+^LNbW
zEj=Z_W4?5ahrYo~w`-qlzkuxuiD&$z+7td9+h>yB%W)x}XMxs@q1wNj0$9#R^OA2T
z^##T2dFVcEoA!@EI@igNKQ1AS_Vuo%^wqw9K<n2r-DgdHp8eOWbzgHI>nYPdf8<@-
z8>;U)T<5u6YZ*VO_t3288L^f2O@B=pr*-O*-kW62dx1y&&PP~Z(XVKS;a!FY^qxlj
zmiD*me7@o6{C*1chie_Xr0=WeG}_e=#q|7YN~`9R))?xGn5A^ArmXvp_4>-M@#c5i
z#@;^i?GFn#T{KjXy_|pX>sQ_tHF4y7=hzYV#qSq(Jp1$2PyOY{i$AS@{f_gmPCeuN
z-mXvG?l-<URCxYO(UAx5IOUGJUV8DIlOF7G6y1EI>%5Me?tJyE@BLrD>EH{CM|K_j
z!SQBC_D}B{kKB3vGr6}vJH7rpSLM4^pMKN*b<k^_hYo%9YghL@SM7T9fv3JX^1-f%
zr`ykZe`(j}_q^A8(ThKS+V;)aH$L^_OQ#(<a_dWlUp{v6=0m63Km7EbLkm9-{1AHC
z59LoDI_rnCepmSP*RLIUv!k_S=<3<&ewX#yo4$YJW9KK?U+g+>*Jm$&dFYL6Z@lrF
z{tK`Eqs7nvXUivJ^Q|f0ym7~^pWYQczsr5(`QK&#aL=oLCp`WA^<V6IKjF)Yw?8^`
zdy(tK(3m6bPwl$JX1({@g_h5Mc-P1B)K|IxyZGl5zI*+)H}C)A;pdK=|H9Dp`#<09
zzWbY#&p7^*<(^MJHh%P2^2Ps;z59WV?4BFPf0LbEK~z*!5ClOGWZSe&37u`HZQ4eg
zw$pZ6@np6;TUn;N^XyLBlwc49K@bE%c!D6+AZkkJAP7<hK^{UwgJ7yb5S6yS*X(Y#
zTTfeC$JcRwr#)Wh&fK~8bKjr;pL=Jr{;+oQ=YD_7_7@#}>s4=kZ^th`^ZPIS<lW~T
zR=DN(D_?T!&1XOBwwtd1?X6os^oyUq^(nu)`nFrXx$AFNo$}$E|ML8gU;pQ8KY!CX
zfBDOme_Q?4wYz?DWA#s(zx}4i9Xa#6mz{a#508J$8+YGw=@%Y(bK$Tb?|IpM-uv_)
z{^dv4zWdhS-15PP{qoPJUO#vF{9hXWxNzf5f82Ha)1$|K?{|kC@q?Fr{a4rh^@pGQ
z)~#Q==9;%%^_l3<(|&Z@FTU{9wOekw?WE6Kcg@wejsO0|*WPf;+J}7WxbMGm8$VGE
zeC-ifA_Z}hbTLW}KN$-AGZcYa=%CCbSV=u?cx)7;@pVC9C<;ax$77UWmI9`dAXFLz
zzB&oq9tL$-?gWO8AV!LAJjx4($udQrd6oz^h!c<10$nh08xTZ^V`vS!=wXNnW>~~D
z9{49l0zXd<BDCX?UXa00QGyXBSzwir?~N*Gq?H&6Qgq{XBp6_rEK^uw1S=SVf+~E4
z8<?I0w>m)=Jq$5Hjv3}yrp!E2Nj>d!(#Ig<%u-;LP?_?hj#d(M)5|bpOp#}v^7|?)
zy69(=33AM_%o>$`V^U9qcG6@RWSm(R2;JZHsiToFt#s4N7+I#sGtUx%MpjNOagub=
z&k#B0SY(Z+2WVTg(@B~PeT*>9BnuQ+rTQ@O&`N?7-3*Xro+Se7k1A?upqUn;#Ob1+
zQD&H9k!33V=DvvtZKTQ2#|Yz0vp|802Z@VD!gSNi0Aoy%XPy;;!<7@YG!v(b9{L$#
zf*do<vCJAx4_01ulA(`5##x|1g*mN`Mp}uHAjJTA=2>Eea(}blKnqdgbTPyPGt9Bf
z8fEUqDygA~cG3(o$pQsd2|ZNVP)8$ST1k+imjQ+uV~RX0lpC;WX(39Seufw&#|(2U
zQ|51hYN#hd8||dYFvtj#ED-YBjcOVR(@Km4-3&0y7*pg~A$Ww?sHK5sqQptk!w{oP
zkYk2L%BqzeHPq8Y8=a)dFv2*KOjBT$#z%^iR$`>+rk64D%oBLlRZauVv=Ajuk}ifA
zWr7(NS*FsuqlP9Tw9`qN41EkT&Lq>!vOuUtjD(4iqMHGR$&zQD;4xyPidq_olcb*s
zW>{pIvd4;xdfFLeoCOM0JWgFwN0<aD1{fntp5g>pP8AI_(?XOuNxJBvpHU{5W0A7Q
zD<f)%&`u|5GW4-PfmK3J5F6Fh(MT&XQuH#wFk?)yLirQLNG;8@5G78Meufxjf*do<
zvB)xOl+}rsdYWjXlQbFn7-WQLW?3NgBr#J*D=`vu)5`$EWSM7);K|~pnHHkNNz%g*
zITk5<ig<|7PMSU@nP!#()%EI=7zt8z)5|bpWXZEa@Kj|-6}2=IB~Fqa`k7#cIhHAV
znmVPP2<>!|rjJ2Jm}HjF)72~0)Db2|if(!tV2ml2SRrWeKbnb>q=z9!$uYwmi!8H7
z{buDwgmyaVV}u1(sW?(R)X_+c6uk_PWr}&0C_hRW(L$6sJ@hj{jyV=trmRsJ(L{uH
zG7K_K#nG-$9gW23W`HrWOp#}vC03|9Mw!q;lsG+%GQkXslpX8()DxkNPBQc{!Zfq2
z5^53;jkFRYL5f}m7$(m=O9aO$7pkbGg(O|{GsGwp<d|cTW!9*ChVr3}cG6@RWQ0i;
zD6mTCnaYi7>If4fL5gmM$udvSEH-LspoJ)Ly69(!33AM_$TDTm5+60x(?o=J()2ON
z2;)q$z$z8b79Xv|NRXnNUIrK@%M^L$St2-I%+%6MlsHLx=x2ygCde_zGG$>gQ$sxw
z+GwYfJ_ea&ngt516566%siToFtt3d%O)mosGe(v?^DMDK`3d5umIhjglB9=zhR89)
zBFmJWD0Z5N&`z2@1{q<TNoHA~Kqw+^8fhg)f)w2hFw7WJ%(F!KNn)gdI7zzbp`Rf}
z$+5^9H76@qBDB#?hH)mDW|jpCtP(m!e1vHwL5gmA86(RSd6p>NbT-gT3vrSRF~JOT
zEVD-0smhLeBD9evLmz`oGR-UtgiaF|t;9&t%>ct>nIg{$!Rcb6g(z{7^w7@`qvV)l
zku@q?l^ad8(@BOt2AO1<Syl->NB^OkIvNQRBSDG*hRKp=o+VbOJwu$d5T%PAh8QKs
z409|}cBc5Kr-?S&Ni)JE)2vd_CNAn|q?H7{3@}WVDe?qoX=hYXOEXd8B<Z4uAx4>C
zhDFw>JX>5e(M~6Qj5Esu1w!YDi#l3~ksw7ky=0kUg&-;>YKfDiha5A^vB)xOl$|RU
zYN#hdJDsG-FvtkwEKp#Tiu1%q9gT!(CBZORrpPnT62bY(jVfwsriCbRy69nuQ6`vS
zku}O<;-rZPZM2i2j}gY1WR?XAtP;9FywuT1m;?h1Ge(wqmRKRUP`otIOq4iDdKhJb
z9CNHu_FOU2M1(dvNt2<EK}Hy7ngXj-w~LQPT8WV$MK`^Sk!6ZJ^DGfOPpni?O9RbB
ziIb#<eny#Kj<Ww!|J2h&gf`mgBu$1s1{r6XSqiLD-63uo3DZi96y5YPz%W_zEU`im
z7dN#u&`gv#NxJA^h#BTsWSKQ;wu+kwZM4%#A0tdMO@YuwVkJx~F%tAL#uRy$SRvS^
zJgKFbC~=Z>(Zdj<<d|cTWhxV5qlq@!Ni#@+RjRiuH^Rh7(M>N|@+?t)v9h6=7UCr7
zVu(>D$T7nrWzScqG!dbVb~;JZ#~>q&GtDdoR;lO|8;yjCk)WFavP_X@o+VZYb|^EV
zbkWZc6U?#98f7m~M${9boleqZ7-WQTrkQ1d0-+a*k2)G@B}Rf21B{U+&kE&9^+*d*
z;w0%|hzVv`WR0>*#77NHL};Uv41J6<%>o5h3GEac)pRq!Fk@tyXNeVpUCN4DnrR_Q
zoFqLAG0FrvW>{pIH7Zl$qm6d@7-yOV3anD`-(sSXR$?Sb(aiwEjFD%F6@uN$j%Hfu
zqMuQ6%(2WGWqXttO+;v;lQiQjuu3Sc?r0@Of)w2hFw7WP@&uQPfhrnkriCbRx)>tI
z40Ehec9~d+&_;%FW+|{r=yGL4HFY!+CPsp8hRHI;JWCY6G$^N*7NW#S(nCK(j50xv
z8Rl4InX)UC7fnQHr;`kWj4;V81wt<pD|IxIqMHH6m|}?)s$MKM8fYO-7d`YdN{&U!
zy2U|+b~21G&Lp!euuAA9VxW;2DZ1%pfMK#sk!POZrOJvbYH6UEBt7&q$^<!PSf=b{
z+BY>s7-yOSt5j!{1&y>4BSDH@hRKp=i51FUE)HsGCQ6(nJq$6*1T)OBOxY{MLOl`M
z=p;iQgN!iAG_w>~rQ((1BupzQx*1@YEP0kF?-3uhG|)_xI7zzbXOtP{Sf=b%%84c-
zbdsizK}Hy7l4%NrUabtNBTS40DFzs3j4V^+nP-U=%3mW^YH21)oF4iaCC3bltWnvk
z3~3@l8|`$GCc_{j%(6g%ir0#jM#8ibBgFt?WSJt*JWH%l{yK5eKr<~w>0*dcaxAh&
z+3UqgJxxStC(R&}OtV0NRVw<FBVk%eFu)jD@+?vQ2650#3sI7E(a!`q=2)ZbjbfpO
zCemaWWQ0i;D6mS!o0Jh@VkAh>%P?7{$TQChLBE)2CQ6(nUGy--C^=@BW07UnD0{OQ
zsiB?-ZFG`hgh{4ZV3mruC@&fb(@KJF1{h|HEK@A8Lit;@H=2o(q>Fxr7$wIHb1YLo
zpzLU;lQew{GQuPatP*;gxM(Cyf^LS%l4phTw~K=YnrR_QoGyA8Wr7(NS!RuzcZi1w
z?WD;t!X(oyP@sBHEQDz#MuKj78D@+uQ{<Uvh4Oc5_terr3sK^9(ZeVc<XC2nvUiD*
zdYXvPPA3`q7-WQTCYffI1uEXH3<(n>K{ve&Fie&uRwy45Ck-?cCrKAQ3^B?KbF5MJ
z9&L^Y?R1i6kP*h2WSRvEgx)JQ>S!fKH(Bz`vqbPdF;Pnc&BRI4ML$D~l4FiVmMI$+
z7xgp|p^Z+`OfpM>RYLC<4~@j=W|%RuOp#}a6@m{aD;j7aPLdw_8DfGNmRY0hf7B=S
zG!Y?9hCT)vXPQ|GtP&bgUewV@f?fs~W{fOL1RoR^wKUL73vs&WXNXa9%rM6?YgB$n
zjMURaJDm(N&Lj)068f-yK^={RiIE^hHv^0@MV=*!Kk_K2ie_4f5+_Ly{R}b61T)OB
zOxZ`oM}#&q^fAaZ3#=0QsB)u@FfmeeGr%xerpU8G@G-GbMFTBFNzy|<L*$rak!32!
zlpFOl5uuGvG7K`#B-6~YK<G+kNSIa<q!?z5EK}r}XNeW6KCX^wriD03dgy0}QF6>M
z$1-b_T_s*>XrhfYeM~aV0;`0^)h#i)8DN+(@+=X2LYYxTEe$l&LX<9g=x2ygCYWK7
zvQLVK8tQ2y!wBO{Gs^-6Dn6x7X{41H-3%~HmOS&UP(C3hT8NXRiyr#PF~>5MpB4x8
zG!dbVG#UCBVUlSUC{S^=cu3IA0Au7?A^42)p@C+i#7WY_C^=?WWR1$KSZJf2PSRu;
zWSj+7sklZvqLDDIBuFv9FjM52XNBOi%7!XxX&_FLE_&!^h#3}HW{t|viH#=OXs44j
z83q|)l37BNVx*c@VkGEgm^@3Y5PV)-G|)_xI9>EJ#0-lpQ}zY*MH6jg7-WQT76@Id
z%@C%Q7zw)RWsE#4l;@NQwY1Ph4?|3lV}>~vS)=BQVxWl#?WD;t$T*WsGs^<2RD4OD
z5vG*{DY_YEj4V^+Sz?9Y%i^S#2I3^?p`Rfpm|>AM%BIvC^)%5=CmAN0W`P2$guWs^
z8VS=%j1=AUGQb#FrkH1i@~^5pT8I*-iykJJVU9(XDf^n(sG*)FBDB#-nm$GtXO;yD
zR7|T|8VS=%j07pV86e9Pd6rlq_`15Lfo7t_Nzz3R{Y)^&8a3Y#BTYo;B*P$+tWy0=
zG0{kvR$?R=W{f4uXI!6JnrR_Uk{(9MF~b~dR9+_r>S?EwaVD8&mQ_OE5(ka6k|0Gd
z0}PXAo)v1p?fOLNVu(?4%&<mfUY=>ElQe^jvp|8+chm`WglQ#3Hv^0@MV=*ADF3c<
zpn)iHlJqmg1Ucqdqw;&opElC;G0rrztP+|P2X%xgKX+3w>u(QJ7i<cW{sy4m@BSyx
z+Z5FLo%op7v$t*x(zX@XYz%UxoBRfJQ!qe^7MdqF1aprK1)YB99=jwI4BOU7bM)*@
zzBAqw^xD>bX=5<t?``t_CZV@%Q_#0b+V|ZQRNL3OaZ`{DZ3=qm_Iiwh*VVSQ_uCXK
zKWkGk__$3$jwLE;Hw8_szJEhd|A7rbvzVuj+T?c+n}QYF326uZCOvSShT>~-58o8T
zZPUf;vEucF&lif<vaJ?N7g4{-Ptz=~%VI9~H;0MGZwlJ|&ECqNHU@RJeXP;w?{qpD
zB!A0BzYmqa{KlZk-w&jZ5$oGG1Y<KBgZkBtK^u#HKOZ_j6!iEVe~o|JXw9($u2p#7
zh9Kjd7-Qt=YEZxaKC8>W`O)B<$|r|{mZ6eh=K2l311SmeukhLrYs>xHl@m`71^w?Y
z308iwAy|B>{`4^I<8bY{LY^O_T&beD_}XvRlj?T-hK)hSzgsg)IStedZwLm(GXI!R
z5Osb`TI0WzM`a!Nw*yPh5#MDcLE-}?LGBkDgVpm(f{B-u1g&3n-UXpx_759_NTvQ4
zs2_Q)CQW^@&Xi$Roy=0<^I6v)am^O5$JBAH>n!|yW6)z;f6Im-HMlW|)=2Zo+G?G)
z|7+!{{OA0*x63xN<ob?XK7CWLrfx(2#wYB@za!L%vFq((T-y+&{mteyL(Dut8#xTy
zl_KTbVt+NQ-VYb|d7ZXhc&Tfh8w%$9?L*nE8}|M#D1B*3P$u2%+cyT)@7Ng3d*9;y
zw9oq<913#cp149xEPiG~kp0O9Ynu&0*mfjd62zrBxmB81ZwPYwOyq^~Z2z$ReZ|-B
zao!eneL^T$X$%G3Om>w7LxUym#Y=+4`3*tE=biWNk|23wD5&0A5;PV<L59j#l?1Ea
zFZr9o+RunRRpNQ1I6tZ!KfN(Xy~g`-_4Fp?``@8p?DCC4yjvUa1M2*xp<wVe%JoI^
z;NJwQ^Y^zk10})i#U(-g8KGe9t)U?A-(H^c?|CeKA{4a0E)<0PfO~u{6ij7oKPT3&
zh~e8}D%YkTvN34=YbYp0ygp-NFj4CLqxGo^#B-!P-V_Q(E>hRe^jV#JkGb|kjUU^&
zWTP=jy?tmy(A^~c_iYTOUsn>O<*iztXXLd_UgO(Jg1*s>)`i9Vlmt~7buX{e@*3+^
zN1rez^(%|r^4cY@FVRomrfx0^1xvjfJ!2O44f6EsP!POLUXvxk)Y&1=Cgk-4wqve+
zbttHPQ^@Zdl<`kOo>eNRT*%z!^Y4kJ!dUTe{rHwpFm&q1AQUxL+{gRJ>C?{>+cEOL
zqAxw)SP}NwQ(gZP+Gn*k^@31PwR>Zb^luwBe{6%__b8JQZTw9oLHKnWgY1HFbWy*S
z*L*@7X*IUKMZFBEpAUtCu)l@R^%@hjm5LwQ_cCdIHWVy;ITUnV7Ycgs=UNYz&R?8&
z;>IA?s(+Vw|HzHLyWSY|HW-tB=iIH1JI-fMRE{50HxE%J#_w6}vFE$WaD-!A_r3b+
zYfFOu*GuDPp&<TCW%6om{{_aUvqC|`JLKp6j`O!tRiF0R8`R|~()zLTekEU!pXpH0
z^j*h3P(4+tlQm`EqCC#_exvt~6;r#h=xBZW4<X+%s<UVN>?z7`TpxLOC`ff`Ybka8
zLv8sZ8-np?hJw`(Yz)TVP!gm*zQHq0<JqoIkiJwpFWMMXy+wQ2qpW(o?$SPQ+Yn6B
zyFoh+v~5~S#m7(yk5^tVckWx1`*vg9bCj+2zpC5=?Y~0%?|ZFwaiX$T?kmcDUb&A=
zX&2wpHt(;jD>nw2Rb>%T*3a1(EGhTQqx8X;{B0J8_CKfGv(NCEat~?$V@D{TgzG1j
z!}p9AAKVa(9vcdlm3x`?-|ug!!*A4oQm%iQx_B{f)sEBRd$reBgo4KVN|(t8D5Lwi
zzQ1Enm#Yu&r@T%+Q5$)s@_wti<Aufx^%m0JSJc~@dMl{6wl^w|7WtW1{yoa=T4nxq
z=V|Y2>TT#@#qn9&S8tW)Xy2Q>*WRnO_cir4^+)sD#oGGuKC3s@Ywxi~go5TB(*1Ak
zZf--+`OytQPqQ@sNB?<aNs!Thd-UIij~FAaRu&f->x@^8`fyXfGW>6SP#<0}UX|;^
zaeX+f4~O*OrW@4Duk{n-RepzYqD{Mddnjlf*6%(lKNHHMFBA-%Y<$udYqiB1ZE^l<
z%H})rc9?a7wmAGZX`Z4S&r;sn;_zdX?Q_*xqduuEt|pAB&+?hJn7B&cewcap`O@BH
z{QSX&VAkJ|E<Hor))v?N0nV~K6^dh$JdMj!RYH8mrRGm=2)f=Z{oRf=Pb|DdeY{;?
zyIhQ~RgT^2b5YvA5u0&oewVTBTzPr7cKJbdc$KoeMt<KM3Z_rjKCTzrYvk?A#<Lk^
z`~zjB-xsPkYTsfxU7eiAeZ7BzaX7BN^!JrNyT%T6bb`;Gu6<6Zn@8!_N#jRaIh$)n
zuavLj^_dSFpWj>(teJ~?%tM*$HUydP$ggp#>1UxJ^9$|6SP*EV18<O~{uf+kuG9a<
z^}iMUFa0X7^}o81xEUx@PaB=LN#5?G4KnI=&l8l(E3^UqZ>F;(7(3IkZ*%_pwCRuV
zDed(2Vn0cL`;l{Bp{_q43d+A`{LJ$J`Fp5!#?8(-S)SXpsgU<I@_C{9ILes&du60P
z%hhM|ljZy4+JO2jT&z5I8V|p}Aqc6@O7+?Pe#fZKX5&ip&t3CZ%3EG*%%uhWaYTQt
zHkZ!okBj<a!==WBSF2b3F@Bi-^+03G;qqqNTA`0WNE+TRdmXDYpX!ez`s3_Q>!_&w
zy^9fj{Nte@k=4HX9dnv%sOQ?(sQWKzyWf<z?~CnleNa93-6lWkdG=goUFQAcH~L+R
zyf>Nu)bnDeyl?T@)3m!!73TnD`a&`7(e{3<j>k3xYtI(fhs?+Q))o(NA9X)#$iv)w
z-QT@~C3N=&_dJRzUg}=vKJIN)aqT(Q6r0^^xL=$7nfocaNS$30#O%+WRT6~Az05sF
zxwYb7+*6g9$B%Z8bd-A$La%bK`*Zg{6n|5-IN`qJa`!WyH>6+cTAQqY{@}i7&ArSk
z-Cvy-XseFj?s~6qymSXv-Q$(&U$1drccJ^J7rTFbxw!9R9r(u}7`{bJuXaxrv;PIU
zyLi&~EeUG><R0ucQ&5lnuHCxRz1K^`7SiXI-5cHPy=!F8b)9y3mgZoYHQ$Q#ZdFFE
zm$^WCN#|sg*9LR<O<w=iJ(+wJfB%&gPxOAu;m^f&u^4x|Puys&F8%7iIcBTt4!BmM
zvUscaCpqWs*6wd}pL?=0u`m7>>+p!{*}v@AWycJELfL%Ez2KO#`MCUy%kL+p^D!}A
z>DI^R#pi#s-q-uQ_}sF|=VKpr9iJEP+l%-2GtakXJj47jVD5RZ{xfRq|D-WeADfG4
zXa8$0@p5Crr19~q_I+FXE7!J;(0}x?v6GD9XR^V2eQfOl>*6D|>1FMAn{|4#&z_|3
zUumqU(uVc1I(@8CA8Y!swd`@)`mpx;dS!Eo@#P%t@}2t0{}|7%G|qiSzkHK^qz|<G
zRDXZ9bib&->jNXRK7Ww);v>wtx9V@FnNOqIv_6olb<O`Wh97JG`I9+NA6O0hOdpu~
zWN~~n4!uBLc8l>x`nx_*rw^n)sQ+7owU#TV`zrsd)nD9L)ML&0GU@+vLooFM_e5Lu
z-?%>Q8D8<3XPIMq9aHI;VaIeirphrP#}uC@_Ks>3p2@5nt4^Ag{}%V_E&9WAoPV}@
ze4V!aChhuYeeMkNU%m16SmXZ@(mc`l@R$-6tPQ+J8_8*ZSE%0+ZQ(2G^~2i7G1}iV
z?GI}|r)UGM`r=vo=xaR_c%$b-EhYXoMc+QMBxrw-a(<Tg)yn+c+W7Ou^*-r+iDyXf
zcx^*_EB@9t+~%6v|6HHTzu9w$GfVtEhWV{YnLO0}P{g|VvC=UHbYHKn9p`z%v$f3=
z^v}~=`%Gz{qa0r^rhfT5)xAue7>?494mV#vTc3HPe9mg4@=^SIf#PrGE0j-6`7|k?
zD&;dRA6fZGo~~~`*_!ic+e&GKOM;3=>*qt#PKoscOeu>GNkf?|%TK<TA7!#CKXdX^
z{0=|$2G={u*imbad3s4Oa+rMhJNluAmF)d)u%^Q`m36<eF8&Qc@pto?6YZ0yQF-c(
zDjQ|epiH_>bIz0GqtW)k#=hgt507$x@&kEp^7*smMR^RLDvdLgtMaH&9>wpqmzCe>
z<BX9{bI<YsWqX`4wMw1OIIguMD1VA^>KNtx5OdHLZJ@?Aek4yPtHZ~Ox53)*fyUNn
zYJU$e35LHdkJ`!5wc72^T}Qpt-Cw$Yc0FV7N?M&5Q>T8fj*LH@+qAo@jE!H=R-6;3
zQl5*?2?rTJ%9!yJ`@W}cz9D4t#jSKJr5~Gfz3Ysj&yluR%eC2pSZhzvhQ+$@V{QGE
zlA!YmB|&DhHF`x!Fxc$<BT9m{?>NtMl6L=I&8p`TO*7VCo<mI?u_<VzDdL&KFRY3D
zySLr$v1{IA4ScS9QqM$Eo`Vcz-8=ow_Nn^NgS3x&@jgji|EbvLtv`Nj&c4ySeDtPZ
zvC4CR$9PWQSwXJGGp@5dWAS`zkj7iB38?$S#-Qfi)|b!KE;HKn*WK5*TlYTI`s983
z;|-p#T&TVItj%XNKI`{czt1v0OSWr|FPHCcc>O%<fTtN_hSl9K+_zt@jyx-f%gZ<m
z57i!yFvi%HJ<M||3N4<?oa))wkBmv@Y2V%Ic*^sb^Nr6>HVzJnYhgoB_F(lps9)V6
zjq|1H8O-uml+6XM=kpO|5_+fhxo8fFX^St_zdWNUzc3Wk{LFUEvx!RArq6YIJvS>?
z)_HX>qI@z;y+d6d?wBV_$2H1aqt7)KW71I8#lH*N`!`(5dr~|#%04EYak?MtnGU0Y
z=V>L%e$_hUug1=st=T<aY9%_XY)QXMxj#nSwi(;1HrFALzu7Nu2&$iA-g%Gl*!w}x
zy=q>mZCQUNI?MqL);8}~=Ed>WaRZJUc$k=fEtVzotnHX>zj9b%UTmvOp1diTr|yJJ
z?oqXag19_Gj4S`JxU0R+yu%#wbmNU<X6&Ewek~?%+UG#6XP=&FMx5JZ->m0s^Pa8M
z*oH|Eu<$_7lAdS1^9p_An;U|b|8hU_bn9C&_i7W_Du)dk3t#7ch+gHDV0hX+#y8AS
zwpHJ>p8lHqMz6bR{JOSHh7qPIQ04eAJ<Je&uzWE@jsjJcVy3f5|B5_Ped`NZ&sRg9
z)8<cf9P<nM%tO_szFE#%T0ef9`C>pD(_ae8VAM6*<h_#y&y7bsSIZH;RD0a5t-obM
z5cdcFwXAyGD4#tal<zmYci3ai;h1vU3EMu}ysl@8VVWQB{_}DA)^DwOw^^Ii>H{oZ
zWIb(L=d)(7+q~|#P1|OR@9j_6Rye=hdBdCa-y2>3Px=IlIsIcqe;_2DI@&1vsB!os
zVz7;};PvR3dt`ApywjLYHzSlgH$sx8yk|GX@^RhX;(6~jCjUme{fq1Ahtc1=k62On
zO#f9q+s^sCNlaxoJ8sEX@aGLd!>`;=-Q=}xtK$ZpSIv-gV$4&!>h<TmwjFfd%x}Ff
zNb}d$@PAa^(vAPY`o#Nw`)j<<JFeexOZJZt^S;ZqM_i|qVQCGkqXFkvI<8X;Q)2A2
zf6n!*oYU;H73oEN-YV^!^QXifp@&}aCgfpci+-#u+P>rY?YG6EY?^JyzNMd&E55f~
zwjH)VPmN>y9&N0&-<JbHxqW@Mt#3DGO1IMWivLv^5~`x=?Huclt>)|xD0_<kHbCDm
za7?@HQnBrH>2K=2?L7BLzf*?lJ$0nDtM`lEH;6TVg??#Yw|%|#%{XTGC~eGn)%Mld
zm#{B*k@3ZGWA<h33!FPnU!!r4;UkSRu3h{a&2q07Xrth>{5#w?h_CqX6yzNfmxnRq
z!nm<w%{FwnG3VRv*UWqKggs+lGcI*yjg<^D#rWSmM_F@EX*)EjZ~t;*5d6{hd&U4_
zv+iLTV}@lazb`$8i2T6V!6@^T|Ij{iq$r=WHm8$*;{Pi>#)*8_^9}l_a;-9RQ{#^v
zLwervw&g!_jF=`Hlz}mG_-X2DvvM$Zq`fcxO>nz;qSL(5zbJ0=?AULlBM;s39P-^#
zyK%SPXMxY^e(w6ll1`e<|6}&G*w;xPZN{f@+mSE0Z@oZ!dzmq3dV{}Z@w}>D8+@-d
z#?Q6+hgcIxGgCZ&MfrK%X+02_lNOA#Gv?a*$NTQV+!L18;JcOOV~x+(8Yg@<^$~UV
zQElrd?wP5yj!4kY6y4^9d2y#5J7G>JR~Av%X!2Rw96S49>xLVRPoMG3@txKpOnH9a
zAl=D2_ig6TR^xEFJhqr;#-vv@=srb%n0}(`D!--?{a5=*IA&ToPiO~qrRFeWaDqk0
z&(s+Iq&MfdZfW*v+e-uT{|?t3biTgS?RDBb(phY0dF4xjG1}~3{g&6-XPY*=e4Dy?
zNXXw77-KIjKD+nKqtd<3P1>aL>$5F5r`&whV}2SXWL_9CZ)UZhg`$|Xigicx*Ni3B
z9kb@=CG&H)^+!^jE%<E4XY)R5QD-rAR;JEU)-9{Qlm~P7@NdN8ee_rQkM|4Sr_|}1
zbxX6g%A)zVT=_@-rd+))Sl<QeX;!<ew@u%oeQfod(L9&9%(Gl`LTl6<^=Na}qs&+G
z)V%Duh;`+t{C0X>Ft6q0tNA?Z!VArxOqk<Fi~}jh7mUBz&l<aJllIlxH{^AdeVs(L
z=?O9{P&s7&rlR24-H@@6h3l31bBzOS+PLkEZ9moTQKqgt^K9+%Sna{KO`OxlpE7N%
z<#F1a_><=BK;2hS>vjJYWni1|S()vuG?vK8XWC~AwuOi2XGh4BHk8tTMp*HB{yX}^
zceRIKi`(l?`Y2d`X01OPzhbPj<{R|B)BAbr(MInh)_lc(+a&9}*(G_k&grtwNzBNj
zbxyf;Sixrj)%tq9ZKt*Kn7*3VS10t<T5IPzYv<4n<^^lve*Lmc+s+>&enuavpHV9>
zlhzm^b<s+Og7?+7olH=Fow12k`Cl>SjhicCG^(S;pQ<loS;E-WYOPl<?-gQh71y9`
zm9e4L7!+6j31!mHoU-ioe#!b{Nn5J^sWnknobE#kpE93+QQK9QqaD@|J=(Q(MfN40
zA6#u-{IYq`F|nP+XWZ)h@!Ii!=?~VfIb+Lcw`UulHV%BrocKxQtDl7&*Y^bD=BPEt
z!#$Vzu=|Z_{or@zmfvdow%xXKG!&#KZwvBPbG_?{tIxhArschJ!u%}0HnGhX*UMr{
zh^?F|@#S2%PJFAbn{wSIV@<~O%3QCd$#=x8GReTP>ftzbVjCmrb-DcshN<*^&UV~q
zQ(hNr)AV{>XMdyZB5efEP={64&JWX{^w$>O-HvLT3EQZBg}<0bjBicqX>8RT^H=>^
z`8VC{`7^m+SjXRJPI;GSXU2jF<3i&N?w@{XJWxI}_P5&~Dz5qMZ*lApQJ;@cXMCMC
zeuaK#uF5Lc&nQ>QuaSS-R{P5Jv5Di0V}r3>TblW;K1_rzMp<RiJ>tCkz}Pp8G42DC
z?)BQ;>tz;=VGlL72l8dC519`}j8(Pn1tKKqWsHoqWv^?DpXmE>V^kgW#-5ly+n~Rv
z#1b}_)|pqw+^?=u;l87eFfpd=n<wY>EK8*H^${kSrI*N)JZGcfXzQ3p{rB_k-`(?%
z*>>Bud|KHlhn3GM)2o%&XO-O~S1FsAYZcQlSJo8QD2E$U^tCB^7@>tKb4Z=F$Lja2
zJFF`z+^+`m+5cAUjbU@r!rP1=Z!s^u**eskx!k&a<R;~0eVIx7KJkC7!D-SS=a#Jp
z?TeVtdhDCG-fMf8e!;9ZK5gw->D(%FTMPZxeQ~PYyH4o44X=|fBbU2Be!KD8cI36@
zWd@}&V(ryxtZUKVW{p?V-q)Mg*5qZ-_*3J3nC5SqW2yMMHfg(PteB?Pe7B&T^gmRY
zpQBFI--Pzvq&`}Gp0aHtYW!MMhJI`k3>y2(#F!V$+&kUli(`rfYtK6M(&?VI+So8{
z?C3Q257Bju@j|^Nsq?yf(i+<9)$6R=^_QG$_lqN}j;fE)cDx^cuiwVJUzreiA3ImP
zOfpRJA=Vf-=?mt(v@v5y-|Q)Rmd}`Yj=7JjCy1LiubW6ZCR*f}W_pVISkyLVsP;O<
z>;>BOnaYX5KPlr@<-wx&fw?YgU&Hx6Q!X<!o9m(sDZj;s%Y!i?rVmuzqK@uoO)Q@?
zws~Vjxv?SXb&d0u?XQ+zQ!!2F%ra-JZ!C`Y`qz*cM~&r8VjfjSt%tde*oItt*_v%d
zyX@5_3(~8&zkQxBO?$pnZ=UP*+$HI`%aC?lv)~@#aO1A}Usir|^och`wK+UQN(@oT
z#8oXHQPMQBX#FvHqx(|h@}T*=;)UX~?ii=g?wQ}q&9C2d&*iyMi{}Cj&B~8XmZ^}B
z7TXzm88=2uv&5pc;~FdS*`lsTw1HmRRp#k>jP*733=(0S1#?a0WBP{s-|lyrvmRwE
zHK%o&ud?rSumA21LA-bm{2}etacSFO=LBAlJEzJy<<1##T%p!D>zsM}67HR=oHyb4
z8n1gD-%xz5?WdS9m$ul>+qRLR!TA%9wJv_N^_?_Rk24lM#`>4;8qf9Oz6<lrC#Bq{
zhV^-Ew@N(@Xj6IPO-8*B(d~8ckWE1i)$Vl$lu6h*Lmx2yIKG#q3zZ{H>TJ~<Q)B&@
zHNVuFlLoD`LtoXV7&6v1+fLf{-fB*wN7*hJ+g7a^s+4WBeinbEx<1ME=<>SBHef8G
z{XR-ri*bg=lf5V9vjzG{df!GbQ{InK<=CV-sKK_zc2PRhtobZ$+h3%;F8O@1*sdR@
z&6!76#MbZnv)W3fF{z1Au|J&Vz51@+<NK3pX*2eCbCPXfPVD!3TKnl^M&BK^ZLz;s
zc{D$GQ;>6h-D9Qu2(c61;@V&F9gy^ATsv*MWIG}c^UA78%**m!Bet}-a_XSxJmU_1
z-WQ}X<FmjqF|Q}QUK01P@|^SxrNZ$E?X1DJ(=lVzPiia7Q1Jz8G^(yu?>XZ&HDA=9
zzGUq>rM`%XFK_=S4WG3h^!d^??q5D<-lF^S#udkP`>fUbCGXp$nX{d+opFAj^y{3z
z>V5Xh+N{?L&Z+WQ6Kh`2Nq1RH5y$pOzu)^IX{2mB?Tbl2<@_$kv=^^wf710D?d!3f
zmF}$9YsK>%n`NFJ=~p_w#xZM-3Cmm3^+u&xpj<3dwiS*YE5>45<{C?mZ+2dtWBZ+x
z5Yw#f1fyP0(|3zGRGH7Jr`$?Okb7Wh(D)nUz^6-t^m3`PEDgeMC=L4VXYM(z)Za#x
z`hK|7_uHjGoBPMUms&?!Q&&E@G#L6@sec2`Gq77qgXuo${G~J)xzy|4(xA2Y4~hP`
zG>F;X`=ioe!T(=$bg(q2`l$DZ>BHMgJqL2kSw3UVwMG-A=FQTeC0-iD&nR_Y<n`&|
z`lain#Puz)TvO`rz)ORPN4k$VvNUM=b!kx1P#Sc0lm=xNId5}mkbFw1fBV5_(hG?{
zUuAvq9Os`|8q7b~I^OwxyGw(J^E1w!b8g+%Qva5h^yRB-hqzx*8uYA|1`SUy4VIoO
zZt3;;tk<^7brLU@-orenl5S0#Yf5+d2c^MaXK7H7@9tV_^GB2h&BZuvho#eUfimc|
z2C@bjd6Hu<lzyvgJ7@OcrTV1T_AS1~8s2fM%BbyZ*L$w>9XI-7<^DD6g{PY<o>&@8
z-eCXZ#r#2OKVKO=sx)XP>pCk>5I<S_n;$KvM~Yo~WzuSJPPP1(|K9zV{jqK8jJz_>
z)k@E217aCeCQHg<^m(@OJg)q*>SkG<%j|D@p>x}9eLi=wbH&<eJ2&r~Nogv>X`k18
zMETs`{1B6$3U#mkCo8Q_wC(;9Wog@ee{tCs0`>B2^=MmptG519&qAN2Tpr_nL|n&c
z7gf^vvpi^{EAQ6smVNK^OZ&H|?{Z~Os(rjoY}#h({XYL+Y1`L3EN<<5WJEkK@|>~9
zbJe#ir>D7p6GzVbi1W&?@Qm=o+K_FuLb+C(*OYhPqs3jPKJH`9X`6VwI&$vV`O08c
z-ldVM@$BUh()p=)9;fY!J$;H8E_d#OU02;zIH#?_TGak|<q~$@Lh;;Bh`G$VPrWQX
z*)xU*dT#SEed%-ZwOkt1pCp~%dA|84-*r4rJ9?*fd4&G=6LX#WnkgDc&?Sbd&nvg5
z%G+ne@K9^Qk4xhr*5l$>6z5`@x|XLgv5$&xO?zK`ti1d|U0<oqXu~59QpU$B`&T=+
zQGXrRw%3$_x}5%`cKc`J$(6pdyw;j_%G%&_?m55e8Ju=n_eO1RqxHc}#`POKGyjBj
z_l=&h%iq+Z_kXc2pz$lp>ebd0zqQtXk~;Z@e)&yp_@(-GSiQMM(@#9_y<VOF)w*TX
zJpgOY9etJjU#gz272B88-7_8k4c{yHe8T53WtCd;?7_C-$JTa_vbIaA%XjHB%BB7#
zuJtBcV_{5;<8PMN4{GlpQa4`~<ID8REz0S;o>~3ST4~N2=w{=l{7tEg*<Y0e!{T21
zU)TGQwbGb2_A{UTTpiku6x;r1)vef?<)iJ7@{&^@#?x{!jVYgAbvTulH|?_iz1q0^
z_k7d&Uw7YQTga<#*KDTN_?`1U^A*pgzaxEej?4M1XN_+w(~s-dIpt)3`?!0eiIO1v
zDevvC{G>dw?0wa@q~Wth$4si5ylvN2o|zD0<+Ik%wpr(u`z-9dQQIZQ*4v+QZjbkE
zUMC$BTrEGJR`=3Q7Sm_hIfFE2ts#9r<#pKkamQ7OJ^F21aYn>4rEG_7M}ENd>O=W8
zF4$+=Z5#cCxPIz0_0*+&Yt?Iav0Z%6v!`pcG4-|Jb-Cl}l+T*<bGOOIytJgZ`b(et
zEL^O!U#n~T8@0o3rlb|KuflOrW!(RL<^DHiX*=zj3u2lQ!<aVIrLL!o&uPD)E<a<9
zD=!1uM#%o`t<DXMf%X-oRgmYXx~LN0vf~Hjz0P%$<itL%t+v@8bAI)t@>Zrf*B|_=
z_C`ToGX-gAV}Z7iRz7+8s$J8bXQX$X^Tavjysj@gM!x&5l|Qe`^ZKM~57-99a-Q|s
zZOTfzjh`2*^A_xHaouTg7Njw5f8g9+_0=V=gfflk*X8zSY*XqgF6Iix#nUA1mTAX}
zWr0Djhn=_TIx(>{Ij&$|oisZg8@0b+e8|~1WLpsbiu_KvPTKoQ<(3prkJx%{l`m~*
z)O9Dnr2YGBcFgy|#+x|?SoJ<@n~~4qu;(1=w*C*&H_y!d%AEES^TBn-*Dt7(?-~z(
zqhJ5f`1W=4SaG~C&dh$<d@^l3H*fX*!kC&jzWvxdR8tyEJ;peZ^o-5E1#?Dj%6@b8
zoH-~rXKXf)O&NRAKePWm#>DT+hc+0|mczCK-mm;fp0uAf<=^FXqqZBjKcy`d2>-A0
z`>EGHFUWI`ZI*Ir6!hz;vZ%GcLAy$7!*vX4$1TojmfrODmD6>~L|I3*ixqmWvQE0M
zx#W+IZ!`BE>E1JDEN?Pi-lPnBjB)0%so%K%r<B2s#-3+c!zhn7^KRcY>QX(_d`?=Q
z)ef|WX>Gldh_P=?-LBY9Xg}@heb)PCG2|VWaZIQ4R;4kbU5$7@>vh4loi_Vc9G91F
zN;?QSKdFAFwUJ5JoX~z-wS_uq4{C1{K96Z@)%worxcV)={-JBQUZ1(F^KkWim^uD|
zr9n-lx_OW~Bla@$^ULM^2%p!ROU!N4ue9z^uPcsicW&Hv)%k7C8?<erj8W$=Rajq1
zx7Rk1M#Owx8#P{^W=?f{hF<Aqq+R<^<^5=FOWMf?lm_9D^j&Y{ecHxj9NTFAzghYP
z{Y%@4OJ~H~(`f#RT;?;f+QIm*jsG{9W7W&Bxw`5q?e6{38?^?oE}Yf|Do?Y%alP?}
zsk36f%$e2NZBN1a@;GsvYc9D>TUH0Ngq3qO4aK%;>?kkRlX0Zhb>^<NjxVke>ZSbw
zu|86a`eM5^Pbwk~>!tZuTK8!qLs|W2LcjS=am{93bc^<%5r^1ny3F&|1@qP{)#mcX
zKZ;|gvR(0+I4f6``74y+@08CTYu7)>yS2rLwph1GJG91Wzft@8s<_2o@OsVbv0I(%
zm?i6%`M^5tHuqv=Sn|B3TKRTwF#o5O^;h)W1#!OIIo1v%i|SP$UHrZNbh<KkAF%8@
zfXW*^x3ryRUY*uEzNZ-5vD%HgN!QAwwo#=GtciX8W%j*8K3=CyDWm!Gw1?NoM_8Vc
z>f(6sU+;P+Nb3sm93>AQ<QnDEB%epi+lj895}VH}-sH2Br1N6sV9W@=RvM?;FWt!b
zuJcs!h(FfroDVDeH^|RrK99M^tF(i+I@g+F#lEUx=fAnwj-=J4A73JN>4%m5q`H|=
zhqFV*xfe;R-#NBR|7~5VUC-agI46(UhiG$0D5n-}yHmY;zYrDU!>wDy(js5+GIjZA
z_3>EeKg&Mte(YrVmakUZm@=q&i*~omKIe|RH%b|E^P90gTdow-mHOzD<l&wA+JyW(
zLBG+r+D`VI@`3WW!E=yh^?tZM`bDv&eRpI0%3miBPZ6{Bzjm8ATx0kF?oU^Y0W<1B
zyI6BC(EU60{4Hgn-m88jc6BsaqRm|Gx{jZ{TzTk!oj+6_+UmmB#PC~v{e{wdud#kw
z`>u1prj4$&h;5U6-p@H3wRiVkGhPSEZ0`Q@YddCJrd+}gQ0I=V_Ib5(ZQ5YpeYFM0
zwAr61$G)kMy0O2<{!#nKZ3pe^Ew#0O(lPx-j<1wvR@%eTobtNQ>q+|;9J^$@YJbu>
zt70oJrtNjwzGcS_Qt5rI_^N%r>>3l!Yw^0xzD8-yx_*;%TEv^Sf0!ldR64d_U1ZhE
zv~h6!68SzseH^8}&+)z0aqdAA`r=M)<(ca3bo;cM?(Ob-F52L4vy5eDdp7-S<+#H+
zM?3yp{qrp6bXeP;B(1o)=v4PN7aMb=)#Mt(J_|{s$6TA<EUk#|3!dxR&WoIAe7L}~
z$yVp<TSKl9agBs|EhVOebJJ(~&doK;jI(v#r<_0V9P{<@<^bo{zrcN$aXaDuVBUFS
zVl983^me<~YnQfbwH<4I6vJf7xa9ar=k<wwOn+I*IF||YN$wS%-Ts&N%3#j<qsk<*
z)ioWrU=Ce7!+2_*U6S_}uP2_N9>g-=s4gyaJ+G6^#c@aad&D8eoa0*MvHkhV!0R>R
zMoNq+$Fz!jR2etP<CHQ_Nq2aQxm{WIyu`K6+Yr>m)WIq8uUwj4qf!1R<#q67-Zv`)
z<&yPzT3J`Rc8$E$Nn`j(vHPq?Z2d1)FVB!C>5j-pSlUC!cu&G{^U`W}opEs#q%*4i
z#>47%mwAe?^k;n@7SE#3>YUSRJn5CM%vO|ZUL7^~tlf12?W5s*^{%WcrJdCFDjYkj
zZA^-(LSDz@BQBn0?X1=NHDxuZjHcDgitDUtFERDEERS_N<x~F0j?+et)wUhms7|8V
zZl5uDL>(`xtK$E0&0JJ0FH}d`&x*MF64LR$RT-q^smt{iw1IBd$VjtMnU~2!e7CxK
zo-+0Mu<K3Qx8{9VyJ>P>y*8TGHmb$c<NB*U?{d8<bvP4O*Xp+a1fMI1HrGsSk&gD5
z(bgKpGJUcbl}Vd+QKKAIm03s(joQMf{pIr8rG9IaLBwbC&W}p3(s_aXO`Fx37~{vt
zlYLon<r>tFG8mA*c4=1ICZ$#8{Qk3)w>(dXaY5`Y@-i-sg1l57s~y-kqi)N@*Q~z!
zy`C1^glp9+&mPBD$ydQSRnm%S+fnbQ)O)sDoG*6#OO&HJ?vq~OOzDZGOIowqK&7+_
z%B#__O|NjB9(C!QwD+M`>Ywt_uK$ea4<XxG{eQW5uKZWH#%RWQ&QGe>33U>7osjyR
zcCCSSF)5qEG48!d>O(cIxhCyy*Q(v7Y?No`v$O}VhqQ?`WmWTV?eg2k)ZZJ|%}2>A
ztv{`?Yiy&|;iG@F=6skj@~4jZvoZ3u)^}HEORqQ1n`0WUx6c~A+PzM-_3gmN-3L8U
zyzVdKPmx#m0&CJ6_^tH6<38dlbJBN>(bny=kJkp5<h53MY31<<Wqg_S!%xf^|7)%=
z_q7~h-Z7pJ)oBCu^7(diths&YH|Fv08^cSa`vWmX#rFhl>{sG>ta6dwqWN^>QOae-
z9QH|{_bA)HD4U0h{YG<4xB1{h<~ecA{#+bCE6y+a+#Aiu=ZWEe%!g&leA1lsYV+))
zwZT31`|h%``1?7}hgUyuo+(!+e-+a?)(77+Zz+R<w3e;$TW)Z?`-OgMwWNE9xa%~y
z$E(jO3waNIDSzTGyN|SIT>lmFAJX3b<~Zr~zs}sNJe$Na{BdKeJkPsUzk2KXgEBu{
zUO#4xdz`UHK3mQ;PadZ4TqB(^^>$)u5Whs5xYe4+xKNoi@7Id6L|fUSOr9#foS6S4
zAI6!))2z#^trlJ*KKZKjzJ0)X?@|`xDx4&J>#)Qtooj3@D6hsA@fTb}xtE_}dtYV$
z4(p01sW0oKMe$|E)zgcN(VO&_L2;_9S?TtF)aT3E(WT1kx7wU`7(LZ|{dMO{v(vb=
z>f8a>NPSJ4P~HV?tM{w&aI?6qo$E`DE6-LgPZ8S@`kpe$DVt7t8uHnsJfxnioWzuR
zz1WAO*QMWt#WAHk9%7$+hRByn{M$L6d$?bl^9*3zeRi*H{6yas9p$^5XZ!BS_dbo^
za?j}fO4x5iw)oD;cLlRvFZ-R%G&yZx(Y;->d%NHZo@?3meOa9D1;?ddA^kf0%Zly5
zHR7((rmZZw{*-&cgyXBd9xKLFytib)`_7y7EwO}smsCd|BTUk3e^rs+xh?xHKk;UD
z*RM^zQG0%aI`VqW>nX1r`pg^NC*NeheL3&Lj$iS9()*-iR((G1eV6xD-p9PJ_I}ap
zcE?vce%AXTpGWM=`@GNlsP{`g&v+m4zTEph??*TIj?M2Wq9hsgeSD33lI-<<OZa==
z1KBr3kMisGy?4&%6W-6TNaGWHhen1GW>};4iN05)n_;F{rm9Xkkz#-e<_Mmo>}aE#
zQD#}A?#cF(VU!t`sd|d<l1VX0mIcb{eRoNeZbq18jk>4$4xSXlOtD18(_DjY##o^I
z>0+gmezGi5-rze%5)3fOB4wL>Pe?m`WSJ*8QaRC1H$&uDq*8kg(@B%Mh?1g@8SOdn
zdyx27l{u^Tl@A)qq!rT6Z}C0eG0NKS=MoQB7R>owL*@qGCDTT??}_W(r$+RHiW6Mx
zS3YBsI8D-M_gS6qMH7B^QY(%8*IbWs-}A4%&K&i6b0Ov0%b53VUN133-uo%rHSxBK
zEB*mv<e=l}{hMphAlBTUeFy4V@ipH;%0uNli)$0#O_wMm-y2Vgq2?_0E8ZNnhs)Q4
zrFW)sDE^k=)7rn^$}Rm!?1YNn9Xo#dufBJn+xd-t!xE5W*>kwgEq<@U<WKb(zgwBU
zP9DB%eL<PBnRe}{7;23lWmL@jZOxBeLmOZ5{l${<>8D-U3`svI#>kNJoIlKY#+Zow
zw98iy_x^Wp3EW!(_m;rDC2(&E+*<<omcYFwaBm6RTLSl%z`Z4KZwdVWy#!7O4ttQN
zra{eYC@2YzKfd<(hT4XPaO8}wmuwG*&)RZQxb1|<xyRR@lis~!=kr^4T)h39?aA%i
z(z|wti^qk-7Y4z}`_owX=^fHYZR^~+`;1+Q+tX>e`-IkG3IE`rbT%JiESvu>mY?4t
zje8KwzJ%8EG=6ZoYzZG?Fb>>XGC^?K{<4YRa8Nuxz6SvvNbHmQ)5@K+alNj#Y&ma7
zdi(CJ#rlZuzT$-Bu5B-T&el}8qvPb=YOrPN&O~zi?xVtC2R3XzQk_Zd_}bLg9lOJa
zc;<PVk97W?bYfp~IOHof6q`oy@REJ)tIcmx_P4JsC!BYD?Vj}R?OQMD*mY?-b!oa|
zYhr6kHo_5sZ`+;jaJ3z~_J1h$6FN@ca>7|BL|l8{=i9b!>)f8`NTm}UoxAp=i-(-G
zB_d-N@7jII)^x{ZTa!ByThlvs?d-T{>z?i5$UVH`orZC$&TzM}Z$9)$i$!ywY>K}p
z{5O<MYS*3}#Uk07>_}}bwhkr!A6q<!?Qb{ve^0yFlh#wV?oRy2mdB&^mq*PZl}E?<
zciMv2J5tB_|8!64IR7rY(p_BiP9ymTeMwTcccy<Ft={z5_3}BSzH}F%-jnjV>)!OA
zT13GS`^zZv?`lJL>{b7<<+46U4f`(i@5W(ko`3Tkb;wuzhyChKQ@Xud{lnSx4s(=$
zjQHPCHh0~t_D|t=nyEWmH2fQi=fE8G?<t!*_NM>9@>rjvQis%!{sm+3U99%j2bw!+
zD|d0xf2Ohg^K(?j-x>Vlapo>U{nyS>|7k^Z`y6#hed=FOMtAI0|EWzUc*g#Fzvb^A
zxR2~OegECuuGGF|eYoTF+waqAYtP!^eQ^*!d;hta+wX~ea(r#anfp)d*tTn@8?sBc
zrT49W4^HRY9XmTx$*tSAcciV!4y1bC{xrw$GR?&HJ0@9tTyWqn@-9-n{aHfhsP%i?
z6KZR>9J8h6)bNG-d+Ehn_oO?v@7(6eLZV~mrO9L}y<2eMvragvZQp^h3lBV#Sbo+W
z(}}elVmieG4@xKX$qoDa?7nznu|o^TaZ<Ux4wi3QufM(NoYK;^rQ`h5Pdl`rZa;c&
znrG~<g9X2%+&7-=OEcECC3d>o??WlCQ`QeYD6b7y9Y{}s9$HSf>^pLAT<dK$?%$x<
zA6M)UVkutfKs(PrVg1~**B=V(*y)C~c=vko?(N$<QoE8nwq3Ee)?*$G6dU^bbsPHb
zv;VpW&P`o<k;Cuu%-hfH_dA$<F`s?X{+RFXx+fic-Qh2<x3#lRIfQdhIr!Y%?dP6$
z2<K`rxA&E0zp>dL^BwBz?gBq+U&R)iX7KFwv1RP`bUaPjx2n3^L>wiB-TTk)_iq`l
z$Fb$ygBNA{pZ0hpv(<yKLrM5<PTw2z`m@6P!7(404(>i^hwV*cJ?^%P4%C|ml>4IF
zy*;(dgQ(73yI$C_v-k`%a!7&S{rRqX+5WO>IFxG&^iWFct}nVbfxUTMp92~WyFITR
z9b1bJ+dM@(w9DM#c&T2rKQ9@->)K!M`>QRvts}kTlI<ObT;X?q-a*%>c-w)txqj@f
zZCjK7#3k-<+TOBx!FrwC)iqMP_BN<JhgwX<QuQRZ7~Vmr?!DH|{nuK4<)*(cvt5^a
z=GnRTiS0cvxH~y{@AWQTzuv&#m)|9qCeu4Ex*~ngi}3%P=}PPQs<`sN*n2l!_#ck|
zcXRUIe66?V@bw4h>#}>;o)0=+s_W0{^L~H4-ky_|MwcC0y{{j-H@@|`X#DnhY<&*A
zyTK_|9GTX~<IMDdydBcW_V?pjO?H19i(Zl1{+zApZJjOKlPQncJw^Y!uLr{63%0bh
zop5f)o{s(B85GY6`|_u_>%`)@TQ5p(KX_-fbN8;xPu+R(E~Rr}@bUfaEPnO=Yj$*;
zx_`btv8(IgtKG%bkKb~BW5-Fc6HjW3o_gjP9g$PdX*=_rQ;V-fvE|&8T2AWPwteq<
z_3Z82cI`G~?cIC!_UG>~yX<||zwf&yyE{%i^Ni?8v1sv_*uE^BeCf_@`+{xRT%5Gm
z@7+_I55&87Ff3O0cHQ^#ZF@Q{xoA(vwp2Lcrl2{w^^%JcTRV<9^5SETJGL=#+_A@Q
z-rjgz<JP0MZ#`=BvD>yCb>#Nrj@`WN+2Qd1mV5b*oktznanYq0U+gLSfhtd2v2*Js
z79zX1@7eJpH($!GSn~V6+gP7_4n8&9asE9{(3ceVAYKb=Yk)uOufNo3|FAqd&W{{O
zzv1HT+cs}K_M)RMZai}9(ML5Lb<8mhjoUXjZ96h?^!A2hx8Fs1?A-N#OJMI~-a9RV
z$eoqI-z9NSo)00WeR*DQ1IvETy|=&bpWyDK4IG^3Bb&5@W4B)1bmZ2Cqb@q;m~ET4
zU364a!%<t0J^JX2k2^YX7kU22ZQvf3z}+TzP<b3ey!*;yeQnbJ!~J9U{_?nZ`_9Wc
z_H^#J*zMtt^q#Pex^LyM_k*n$75krCN5z)jy(_t|N$>5>cYD<NjSb<3y%%1;Zt#PD
z>bmaW)0Y<KW<BXHFS~xw?N{}uB>UTZ{x^4WU3uEMC%M)1D9`^e%Xci2OME@KW9Rmc
zJ$ts_^HMpuZ0|IohGHHz>$U6g_y50&zpLrke@*;%Na#TPpIskwZv1D<|MptFt5RD(
z;t(6hKT78R#NP1#DE4BB{R?70IGF>nueY1F-`>M=ztiS;$EJU1qrpFw(1G~Z+fCa&
zZTAOXcD-=#BK-A_@2uVY6UiKieZA}}{@Jp>Lsz<s;O}-MUXT7BC3GPE^|G({XUqQJ
z7I_!pA4=KZgJcfG{-XWkO)z&S?f%l8{|{%l+wc3scQ(fz%C+yVP!4pu^@DDo<vzMU
z&;9;Z@8C5~ac!I4wRf3oiF;=Yth-%a{L9y@#f89ntTp}?@ZeaBYjLseUylECvHmO9
zR>fG~xW8O0{%*bek7ND2h3npuyob^KT@uB3)_<>-J97WM>%Lp;z0b-MZkQ4W9z}%r
zKO`@XZ2Mn&7`XTOx*LJ@XF5UC{%3i2pHA^+Yy0|*nHAWD>#6>q4~o|)K9hEh1F^0@
zo4?y@?0sUtFV^DA;)BcLGkob>xW5kC8vZ}_-Um#w>#7edg9+Lov&}{c3TUA*gCmS$
zs%NI>k5Sz3Rn@Eif1Wfmnvqtxx~98krmdc?qW_F$gu@Qt1%1KE*GWuPfH&K5{ISa7
zK%013eFWHE+w7-+!q>?fBS0Y?)_^uKP6vb$d?vfUbM8Iw-TV4g)vKD<(-L1C(wdpR
z@BBaKo_p@O_a@;P3&HlqY_<YvX(Ek(A*fmXOIi+Pq`v4&ZFM+}*bUGmUSbOI_a}mV
zmmR734}%fb_7$Y??~j}+m9xA>0LrB9aU1s}Xdj`PN4%bc;=TqcwSGXnl;s@)=2hw*
zTOS_{Q`h+!p#JkC@^1v}-C8HvKh^sjLwI&CDKM8F!JqK4*u{Q~4XgbgDW@f~;oZ{*
zZ8!$b0aI1dLOmpE+=dN{eQe6UkilmRj=(<3Y#;auhK1j$_Z+m}gD^(>!R;77h=DVa
zA58tsLEDId9q@_09P%m452j-L-~f!!?zPbdJ7lqbkiq>OQ9n2cQw(2&l)nz}1A1Fy
z6il&s^7>(Z;NTsjk+33u(3H7F_Vtu)UG1V)zuH?sx9lS7M{96`(xo7p@gE;?FO)0I
zbLZV=-fOpMbBs1<Bu;KhEmFbb37#5;v5mUWyN;gFF2!<Gps$9L#j#`gT)}q>$Bv<z
z243-(!ns@l-L~{EPh{S!X`TPu!JJL;$b=mO6C1iP4ZT?v1WrKae-8`?@#K9HPhPj;
z$x!&V4B*Ao(oK4b{GxEqy^uwZJAQzZOy-KlHGK!Tv?>Q+;xHG~ndj{oIg}?dS;fR9
zh{=_ZnK`a$-ugAmW=&XVv|e<|^l{lQVCoFM$<A4}dElEWeN*)dwAm;&*&nQD!V?5&
z-n1w8KcHO}buhn9;r@QZKcX}k@L-1wOj{tph+Ss}>&v3aRtf`)HwnOgkCyAyU>#Yo
zE#=^Q>5riMR~3Kj3v27W<)9Soz^llws3D)kJh&qlPK+tmWz_{d_i?vNJlyt00^Gis
z2y*)(fo@+Uvj}vu{cp9eb^878%A)fap9WFYbvXdxx*pOe>o?>=ft~E`#lbkorMkh8
ztlu*{(St8%ON6HIa7lzD;}-@`PL!VhV5Y2J88D`!axo5ZM2Ikd!+gkGPxn8w-WGZr
zE9*|dQ9W$y)QF`v3-tE5eFOr%Efwyq5IFmF?e7W>wtmI~Byb#|hqr1IljC|YNFqpb
z$DK9ZJIipAlS6>o7n!xpyCl}XqHSlf=aV-1q>(<6r0h=lf{b_m&4Ka3siC;>^Z)L^
zcsSuf1X7ot`V+0Q?#kK*CP~@USwm^~DmsyR8&|I-*QD#Uo0Y-d4o7@O=AqAMnGVA{
zj;Kc=hX4LUiF@~I`|93Q)&0)u)s5@j6)ZJYd)INmroD`PHz(h&(s80gKUvalx-L*X
z5zu%0H$^sS&==DNDg7_DAI3T-4l@MweMHM|`%hD$Px=vK&PqY?DvukJ!c0bJ+<!4u
z8e@bwIgNi$d;oXZalA}ohbVs?!YQ6Ww?fnQAC4inSejx)HKD!z11+cB2PT%&q1c$v
z<>1b_3H2v*#RzM1yOQ|Ue_JAXc}ErB_FhROw}kY?h;TxClh`r+rBvt>9Un@3oByR$
zX^au#<aQ{r#7`FAl%8W_NsQ<w)UD98mn^;wp(#dG6VfDcB=g^n;jgxw4#mcVu70xk
z7AGsAD@It8+m*z(-LFn0ui{a~HwX9MCYToz(ibDb3GGed+vcC8LZ9e3#z`mFvCz2t
z%c;^BBgDyRlvr{*S$tD^w*5A(L;DBvx2f00kXtNGF`}B#-XxA>lf}0<IUS0P30+&s
z;@dE~VuUrhT}gbKdM1$$OLQs3-C3UUQHWrDI*<F86U4V<^u<VUd~;LuiC^x1cXIk-
zT_7f+-6>7ePv0R;DauLgEIXBG9xWZ!Ji3MZ;*;1}GWt>xAW%IK));V4dJ6O%N{o|v
zH2W`8r7=c`lgB&p*X?BUsItSub6D1`(BveWM~Bc9BdYO(2-76<)qJvfG>)c2u`!`*
zH`zQojIJ1AO>S2b-!{J{QG6>Wiyx^>3an3|FN1d<62y;$^u>s9LVJ_gF`r3AeurXv
zLgUu2q#{G1F-C}!+o8mgy=3uC>G>|jw|=ttHiV`aQB7!X5=S<Z#kV+`M1L_(I=TLY
zuFUU`VPm%bgsvE2O-`4@kNy89k$+Z>D!$SCH3{NdLi%DvIHA2s?AXD(HYw02I!@L0
zgvQKnDl!xrV}v-l9ZGzg`j#=|X#2;Z)j_tB#W!Vpu{6bqYC?OHII@#0zQxfb`b*Wu
zgsyC|_%@8L7-3CrS7Q54A(8E)TLb@h*J>ezD_jH4zb$1NV<b7g*(n--T<@PcC)1)a
zT{BcvW->zOZM^fAARgm0`f^z9OX!Rd<^*Obbc(-ZzH>Zz#)g*|Po7lILf6(iQlKkF
zWRueMqq2Yh$eqw7x{MLn9q3YM>wkS3w8aSR4rqJlm#KS&vq|mj0*>=8;YcN2W9`h%
z%+0Oif`j$~ZU=5Z0YA|f5mSFPTB~uJ^0>1uu0<Vi9o@K)oa1uoi{06SR<?E%9ktZZ
zObi@9aT3=$tA7Irhv`9YF5%&hOA!nAUcOt~$`;;QOcXos0=p^hNla!gDH0IZhNgSs
zV5^7kcPX+0S=!d~E^RygWc^idLVn}4C;s#2Gt?ZWz5ErKmsa06vE~kEhRNc~9U_gh
z%DWj;?vVTgaYXW!ty-cwz{GJRCd-OXO-JS{i6Nz#uOvr$7zUCUd%D82XB?cN)iK2R
zuMandjKl88n3)*ZgyxbW0Y_~*DY9}P&Pcwp_aFX??F?TUB{$eV&-Nnu%5KuS$b|WP
zVrld9A~DA}5(AhpzQj)W$&ntljocym2ja+aJqKkTJ)}4?e#vU^q&q&WRE%T-w5giO
z`1sQnp`E!DwaskJzL9KZ@N7H2{3bM;R7p5`6H1kx1Cb}pf49Eskk(4$D;|!MHrH`_
z9INg!J{PeEMkiiXkB|Qlq-aMVyaT3V(Dv0gQVg<Z=kWzMVcfZ6v~f0ickShlS%`@*
zlG{wXha6vG(#HW?UZW@G<gijTmNC#Cim@cepSB3?$P(l>|2g6Q`?%{Q2?}E|JbF$_
z4sJrTNtJ}7H=$J7iHSW@+nY*uf5rH9;5Vxs#RvK^%=gc~?MQC3m9!t@uEd}_Rvf$}
zPInXK!fz^jNkek>EEV4Ek~y6)|K*G2hOKVKZeNL0W{@<}4S3SKIGstE#u)9#Z+^uZ
zoJFJb+hzV*S~N;vPOC>t-6be=&i{VGykw-lh0YjZ4oF@{OEZ&^{=00_dZMP&_L1~$
zQRv!D8dHbS6(h1q?N55|GNtkC&z6_yGF_V!+P0?Bpe;sdcVK5ftNSUpbBSofQ$dfO
zZx>n@a&-?+_u!(?yA=v;%!rDajL^RORfk7=jI_r$(IK>NA3p@z(>3D*)QjA2%Uy`W
z?;5keA7wK_dyL>GFmoF>tmY@h-k+RU?smvXGsGUCHWSe6C);ndAt+hL(i<b*RP0*h
zdplWw_Go&=9?}WPHa^21rjyNQ_V;n}6?$U?oQC~MF6iHvs210*-tB{Wh|5Cb&i|9h
z$CA<*Bhm3qmJdrCG){kcI&u`Xr(>pyN|EFIze-1rLSu{|CooM#qvV55vh#Xc*Rdff
zMs$<wSLoVJc4luFT`}UibGr7Eo!g70OY|5cushb{e6n+UL+OeU*u->+4{ZPCWPVyZ
z!gx3RJIVYsA&oI&oZRk2j<?^MjvNoe28G6*f1QpTg~k{`PHc}7SNaL#oznH)i+7nn
z8b@}qbj65ka=R0GO@G5Uc4yNidOVDHx0x{B#pzM#iV@hv_9Z^BeKVOJF9OruT7m-=
zpAQonGwZ3+7$e3B>@Gs1pX`pb_9!`uu2Zr>rc&fMznYF5g~k{`PGXNtqxkREcaKA(
z?Z0U*k;MjuuKgQ#OjnG!Cbv7GtA7Xb5<RAAYeLt~9mq@QiV@hv_Vqow9y3+cZ+hWS
z@Y5YUSB@7Sme#v?s2pdD&#&If(ZfrPP9L>%^KtYOcnk)oe(6P+#2;Yb%yE3ku}t2?
z=>N8U<3jMaYXbP#u}9o?4eu$`@QJ+Nv9+V;GkRqT?>#TA_Ey5@9(rrev15-RFsr>C
zdX%G$XCde@=z`;%qt|Khghx~JzVpcmVL|E)Og{*6MQU3gG2mVAEp9A#+gFzG18=E!
zLD+fMeLS0Uiw>Rz8AxJ{*fz(~-}%{_;Ek#6|0N+FdM_sqk)l6}2~Y6^s4`+7*^agk
zlJ^0gTu9V@tteoz7K@p+0G$r}j7T7Tf1k*7Lj3KE@dRkr2UDP=KqLfjBkf+-Z-$W!
zdaLaPyr_itwoU6>>5-p|GCpN~nJ0v|-krh~Lk!=h3HI6K95BDe)>(xG!mHbKnE+hj
z&@-1jzi^JH+DyFJ8Qck=u6GUY3E7qNKa<iK6BNgoMH17wDLuYp(<#yW4ri4Sl#1T>
zenZd86Vn+ZP?%ZVW_j#Cj-WF*UpmA-$8850H_sW`-a9U^QSE3)>1%H~LE2p+Vk=W}
zCuxjLPsn17k;g}kB({<mSQ@sH99f*p4))GBogi&nIi>sQcZbC3aakNcau2nZ@xk4Z
zy-a}aa4lwhf(}8Pw$)@ZVmHoj4xTqBwVN1M9Waw7Vl+9pRP1I9ba%&Yk`r_Y;*8pj
z<Xahee=uflx^$FtziPV+^6dT)`%Xk>jP&DY%rUdV2%TH<9^u&X96!8FLaFF|N8Tiy
zn9dl14u}qu&?)!1X5_8)rIn@irOxuwGpI?>%b1<j)y^#}SaXkOv-FU)@!I;_vBizf
zGVY+GRqoa0-sR3RJ!EeV5s#-4*E=hnt6eI>;303<y+kE|C`hjPtm<`d_CZ}!7);X)
z>Ljk?!GU5(alJqy1Mth|Ph<q=?PNG}cZQQbe<CBY&;Iv%PFY%OQz@#mKuhqoes^K%
z%2F3s_uY;7&~EaITWIqCW(qXLnC@7yK+`0(QRjPx(*(B|R<KCT@!L&cf~5*w^Y2fE
zt{7>J=jcM0=y2Y!D|(3h>MD8bk(gCr>$eTNnv|v(K}}*-f&Ti2UB%FJx6LY`Ytyi+
z$?1xb)?{WCydl3UcYYyW^=@=muPpbTZZGs!7BO@5R-9T8bywGWH>vcGcbchCnv;6w
zmab>Ue~&u8OdAFOuI^_7JK8mL*6)#Yjw)h?H0>MunvkX#Wldz-feq~${&tY2yKdS6
zU74Y>N=R3Xv?es|%-_+rnK5Ffx?J~YBBszYZRl?@dSZk$fl0}nGG+MP0eTXu?T#zl
zdZH7WvW6{9N>hxKCNibV+KzU<I?M^4URuP>%(01`1iHngURzz+tm0+6R=9X_xw~?8
z{Tl72sXQ>N_e2H9-k<3+Qi!7iaSY&sf^xgozBmZWs^(+s@9J26z4H{9&=*dd-1Ih9
z7qC}^t;hpmd(OoQd&oCV)_EkyUvl1mL*w*6rDZn?r%xNT6JmXYzqQsI(?61oSK9g;
zn_1|AxK-aik$Fb*y8H9Vcx_)KW({S^)Hp)M0b1f0e<6ltUvd6v;TKngV`<jDjOm)T
zlylGu|A^lk<;~f$>_5}s8QG4_yjSzJHw1S3A^{)1^J;=`Uku^DPs87ggHOA~7n_B4
z+i^l3+*}3A0_A82Hu@P&^s^cI1cF-8xTbE#$SLxX@H7Y;M2}X0ICS7n<CA^^M|jhh
zxG#1uZ(NnD-kGt%3|&&cXS)`7JEP!%xHt(Zni(Qn&PTL7b|fZX-xk-+b83oZYHftG
zORQ6tdn}th;JMiFe@rW?vv94u*zT_{wy*WpP%sz)JL{C&P12drxcQ6PukMUSH$2NN
z4tM87N^QuIcry--(8S>h62JpVhHrFC?Mxuc7&=oFrbVd8bNYw1pW5<l-??E@d(oX*
zW+>0?4^Kj8j6e^1(8PqA0==UBe0npEPE{6Ed6rX+o%gG1Rxdx|UQo7*rk4)-oAd%?
z4NYMbpajoe0zC0^E)elAhGP;uw@2e?$1~JU#F5NRPHcR%<c9MZu}K6WO285Bl+!xO
z)^(3pzuSGPeWQbV?Nuiqga|vY%&WE<`PPs7HmsT2-+K19{kU(71Mn6j-=2!0xisM0
zlKpK)?pQGSEf4s%Y=65MM{{Msw-xp6d$gSQrC-LxOG6|W+tR{s)c60_ThzNQ+tSBk
ze?RV);kaEVLwC5w1vYZKaF8tCbX;bG7gv-PGa1q2wDg#yqQ{t3XS_uv(PLs@cUzB%
z2}_;JgL?cG?T>rX|8Zw}9Dh$?D39ZVyKA}}pR_~Zbg({s*|$zdpD`wD<X>j2PsC+%
zaCcpw$w@l|P7mr+=G$G_H@Ee9Y2bW|du(U}^D$YY#?9CE?EnKn%^_(uFHuo&g|6+m
z90F%r<EOrMRpt-*emC~}aL2<mE!600(eM4Z+-ZPm;(Jt$R3r6|YPsx5eY?N0zP`{_
z{ph@eUtPiWy_-Yca-qG{yS#A)MU;Vyp4fVUstW-GRfCd&;W~xTwlj)0VrNp~AR`oD
zN-n3@$;lJF^&2{8MNj|Y$UK{l4Jf(G_nUFw56ra>e!m^}{lI)X=6kUllm3A@cg*+y
zLD!ni?+51H2fyEqqkmxT9e$tFcH93$U4t<3laS*b55Eavd{WQ(`|pg=AuQ_fUv#@m
zFDVWb#+!@9a8?L)DEW7`c~m+ae3R;bSx3b=A!RZLHTjd;7qfBk=&tzU9iDw1al7YH
zy5OC2c2HjuJNu8P>31<nXM7|_&N)1GCWds^5^Eg|5)+m#iw89r)-L?GIe2298;8M>
zu`@BSH?kVj<?^5=C3fDH-e)@(nsAa&EP5DfY=lV+;Ek-iJLl}6zJ5v1b(v$S#LkH-
zFax6J_^|Gp^2R4^a0DG67O{CylbMXv4X4t{KgTBwOb(7O<AZx+t21p*4{G#hv~TWY
zkIpyknDggNhiPzkP;Ws@J)f%HV&<>`MYYkvCONFT?u5xnOPkGunhaxVHl4gw9B3>i
zM@O3E;NIBkOq<h#8kLy38DFa#H$R<7pYc)W&x;Pz;O?N_q{g}*SL5~FA$u-ieeMZe
zr=9wIOr6-?P#I7niSE0Eu%(8+8%N)ey%&KX-|xr88RN7`bnhkl{bpRvYQQu>doS|6
z^kL3_Ny}z!0rzGtT*H}}4IG9nI4VhBCo9Fi%N6ue#ud~a$$1srN|g!jrJ9PuTkNcN
zl7n-prH25D?sismzt>vi&a4}q)uqnm<t}yAx&{2-(Cr`m9veV368mwNwOwrWlfZ6Y
z#8qCyno-L{0X0Ywe2nD%Bf0ZySMJp!`unRroOipf?$n}<g18P>-m$u*wyV^Bjp%Au
z?#_yVHIzaPO=uJTGry$s6@n-7#J*eH?NFdL{ywg-@ft&jYIWb2^tVlqg=6@oU%FG7
zMXk|f-lcW9`B{Az+Zs*@qw_y|Qm$gF(3#$o$ByN5B+cV`d^S4X%LTW>@fY~Jd{dM-
zB6n%6FRU$GTUC}fM2Qdx8z)JHaEndsiA@`D+85&iL1)+^q&E4$${3c|#Lk+wVS?4a
z)n3B}DdPnb`0ro~E6cbn8|<T+$NgA%gq;BnH8TduLlsQ%VPEb+GicP8$yI!4WuO-T
zpdLpetguh87BfLl|L#E8?TY|Die3d?S(JvayhP-?Y3fSJm!b%XgQLk1+VwbFzI}-~
zp)5FRXn-T=m7zAw>3^a9IDnbV0$84kmtb#LdKGqKU?#Kz1=bvlh$!=2#(;~nM9NwR
zTY$D=<D6#9_d|syW(yj`kNbwrC>pet4W&cIgnqm~0M00S#OTQJL@s^9&X}g*)}^g4
zl#6fJm3%*f4mKu}hRrBHbc|-0O!)U94O5r(-3YKlO~Y^pBra$K<REsJc{q$`D@H(5
zhCqi>hIkxVF-M9l4FuFMkH{2a;UY*-9AsmSg$(NGjEou-fh{y=55m?CNCFy8v*Cj@
zc!sE!xH%sSmxY!LD$`3c=HZq+_Phh~&|*+J8AP>~hay|~IO~uIf3M7w#aP%{+X*2D
zv@6{Z@iIqEts3x`7JAFnBScJ+{s)1VMj&$>fQk+`jd^b+gbCz{%!6eR4t*ksHS<Q!
zutH7&5{D#GY7R0IDajcexo;D`rQr-umNX<YSrT4%PlfX9UtWDmrwo{DkE@htpo@`w
zS;*m7$WZjY`<@uMBtZ>$Xgp%;Q?fS3v(0{1+tuy`-ETuTfwmVq#yPKJ+0$@eeKrkg
z_5w~1;u7F-yC4Qvn8t-PwC<vgg=Kz2`1+2!z}MhX%VDsV`4!EZ|I}UJ%`QP43O{0l
zI|a$L#<anha?g>r7es7u|E&}1X&k;r+F)W}N!%;2!TvYi1>Rz9FkOBmUTjsz<wwev
z$!|Fr90|vVl|)&;C9&|^?h0>%E%9*J%lvEMZ~m_EXItYT@g(->ynEc3C<Mj$2a<%i
zLgQ$AOb%-td(8fUu8$_pIVR$5v^}QFUSN;TeUsW_a)O|{cza9^B8kc}GDka)58>(T
zn>SB%=I#PtgDvq;@+!#_cUJBKZ?+X43O{0l+47K>ILroPeBzCiC(hq9p`OO!YorY(
z29_vphz;(&{VwnpYlG?XBlGf9b6kF8?t0_riO#p*72XD0;`pLUWQ&p~I*WIOKie7)
zi6^ng?Y}W@Oca7*{NoLlCvN@GkUTLq-cQ8aXnRa9s<G^G`)en)$K(Xv?L2Y*(IGtL
za5K=GtfDA>Hh<=>@HN;L4<WM(=IE<;g*Q7c9s)m-C;IM?m^j=9V;t+~Gexn%+i#gz
zPvh`4(gqU)OArmk1~U)b72aZPFin0$SJ~3|{K)L}M$HtZo;d&DUE*!9C5|tu1hy!7
z;{12sCH`z{JQSY99(SduF|Ot|ASMbyG5+y}$P~pMcfK$rPfU}y(e{{JRAboV?$qS=
zn4F-ylPUgt*~5Hr&>Y<kZguQQmu%(Dv=x1+qPGDv!t2goJsMsIn`?^6mu6Rdar4B{
z@M?$B^!XEA?mm_te=)v!gvsVXyUqT;gW}HkJ~|GsBkeXZupvP<Vz+yLd^Ehq+HH#b
zeL=_D>^G%gw~`RN;S$u)c7@-adyb0V!PYyz_(t3BZ)^ST|MjEd*S6rp;8Ap%eI!L5
zV|?srliGtey#H${#3WJ3Sp1H*;pE_w+wj)@QSlpZ!)fv;`NNdlO?F@%7C)!Pmbu4G
zZw5Ddj0<VBGSO2kyx#u$@%%L{UI$xm`s_;H>(3qyueRl;&!6aW^HO^J#rV}5D(~I@
z_v6K(VRkzXuOsa?F|g5YDt5c|Cr86;tlg%_pX3Zv-<*Qo${hM8$a}Z`;!*KC*m}no
z-)Q@lym$B8kBVR0f)9hoz=qGI$YYF;z0vaC-Cs{3CW%7E;&-$SCkL0@hHwADQSlpZ
z!)fvu<PYx{&xQw-?Z-`U?rP>M{+hY}sCXT0zvBvSwDo2(K@6TbDt>MIJq#Yjey1*^
z$zzO%y#X>{vETmhjTeuG`|3Enj<nyzz{auP=`S7?zp?h4DvzR5{~J@WUzt_ku$k~5
z=z8ehUpP8`2V3#@;!9%3zpHtkdg$nQwk`Q^_zY~hl`5Yx{`SVmh{cwtKATE>5~YmA
z?`T_24sIM<-uc4O@f>f<>GCOg#r$6z!<O5%H&r79-ks*RTE%a7$H|M+<aMwSr<pPe
zyFp&Ob^M5QYa8&P@F@1XH%?wWN~bX{c9dzcC{*m%d3B7KlqRnu?KiRDhJ|2ZH?ZIR
zaq{9c`Hi*Tba@n=W~bBeQJGrbcxkaHRdR`)uRJn-2V3#@;!9-5k{9oflNS%P<MD|c
z*io6>OcL=K*s`CdZe#rIh|}VzE$@$$7mw8ISp1H*<>cTJ=~!%e>p!M32Z=2wCvu=I
zCkK&;PsuB$zjaJo9<~V^<8Kq@6^S7wVOIQh^Xra?*TGhNC^@6li|0=s5x=o{MXD+d
zdSA9KrpRNAk4<R5i6M<+znO9RB`6LL^VP%@A|j2n-^9R@up8vX+pmuqgVW+S)_&9F
zQDV~6+taXLnP*~rY~oxZIjkf~mArWCzdAC02V3#@;!DDEMskVWcO4newk01DpMfnu
znkJty{x-2KCx?|pv0}@+FQ*ZoL@CK>92$|w2bYB9z?N_Srz7Jz-j<V#EfJq$%Uj<v
zrY#TOoQ(;l6J{2PAthorBm7Q%?UC_2I4&PTb}YH^p1f0*q(7W;sr2+~+wmdrC_0^%
zH@(u~F~-v-wBf{%#<StuzdL4Z8m`mCR1S^DTEB^bC16=>IQvIO#&4_*r^%ztvHmxt
z6PILKj0v9;XBEj|B~U8Pa|q9SUvY#y501v;i!cG(k|R%j+Y$0?Tl1mtDZ2ILz0*64
z$wFj|&rNL4$zdf>tYObnznV^*nuzDo_M9r)V$VCje}p{8+jFXXuIgT>&7aqPyRovg
zvb4U`S*ACv+*9r)dTar2E;wxucabe_be7v7YrWgPy4<_mS;kuu{LA*j>bm~L_0CG?
zYWI2<Pq;acxZb4*kS8)XG*0IihT|j$7>v|#4<ctURs{yHIQ+Eqef_?^|K#b_CHit>
zd3~wBjMp5lbyhnI>)q8ghs*bPM*MnPzvs|d?DX*)ydoEOGj#mFJ`UmKhCs?Xg)-hM
zbKS=j%!SUvweDiOzrNVM)?0)0@Se%fXqtEA{lE!mHY8;}<u?h@0F{L5P}bR`bjMhA
zJc055YREbkQWB~~*3<Hy;wV|iV476c@t~4Woyojg+sO2<s`uxzcsr%lUtj92z*!f1
zD{Jek8w>00%XqBB!LyEQ>x=A|4!v>s9{p`5?%Tz#{pqo6*8VztyT<=B_3jekR<U5A
z*M~79RxCUPlg87Hc*O|ez_~DJM0>q+l}FM0Lqb<}6x`q|f*rnn*wlRO>i3HRx)9&K
zYopt~)>&DE%da~Z6uDQHRu-=;(Z8&Ame$wcdra&jc;%Dde|bW~n}1TptWof;UGFV!
z#DKd{t~Ae`cbj>y-DU?j-W19n%Vge?nVUNRyW8or2n(9nr4@uCQtp-2Znxd<EiWzH
z3Mu9X8z0s5W`F1_lfmq7Tn3mS5W}~R_I_-D41`WE5uF}MR_M%pDq=sPCxKZ?1hZtq
zod4tqnAJous|54CVox6*!Ml$s^U@QE0IQ+Oz8=%?`#(MkzMISnXjTT@e@oyVA7NX*
zt7%4fSn9!VdG_O%Q^iMyo82$~ibwIG&7T;_WBXz<2?lSS3ZGMtkI;D#epb8v9&(mz
zz1~ypmEIyA>~xYbIurtN`ggR<r@wPzS}0g1lE7eM2!xXR`!qe<_l}~c-R@8xhYTbs
zdh-jy_Keuu%cF4-s^x|D`qK4odkjO<a<RWOanJw22>TKUy@d`!^aQBQ50#9+PxI}3
z|5&*DJ$5S0H_5cECaYzIKm1tH@B^BLz3)?RpbeZy0{)+dr|X$;5-A+`T+#78Vgo;z
zOctDgU%rJ@e0(CJ-x38PhyKS#%zau8lSaJ3pDQ_t-#NcES`IhH_Pg*4!gg89Jp0lp
zzgtE|cq6I3>A{L0nX5OyWyD-^DUmUAW+n69?k7jcDB+BNs0V3;^YzrXMttGvrIi!M
z<)TEHO3i=7<I_63TD-N=xsIG@wTlOxk)TV8MR~K(y;m9={z~rvM7-v!-wKsH<Mum-
z!3~5lHsMwA%}=Si24chlP4=|@2-d&twcf_+0?mjzmtS99@7>fHaSjii(~HSZ1n;fy
z|9k>iP)r;!dfA+xNQO*h9Wzx3>`N_)owEM+zzUg?et!F1zRh^iZ)+pJ6<zMGh2QqB
zU+=A`coa&(Ts>ESdFaYLw2|!p7z@{s$asL?sdeatYqp+V?j2a)NzG$-J)ps^XlNdX
zlqp1QCXs<I&3|N(3@dodfINQtbWp)Vy-_YS?>AJP1~xi`=9rapyv9b-91AHS%|9dY
z_qm~RmeOZTWodvpjHEgqlp>oRJ{>OWfbNx{vKG2yL^LVg@t~5@{hzhGcYii2?>F+x
zs}!z=mIM=8TPE{mZ~5x4`7+FN+g~2l+a2*gxXP~gKVz(IfVUlYVof(a5oEroZQ%B;
zRBgbny1xPW7TcfyfneSp^y+Yolf|nG@&8J1^?GN$eFLR`<l(3us*0f&Kw?OP_LNM;
z#{wJM_MMN6wEb8_aT6N&A8GrEfgQdG0^8qfr7DA1+kYeREpe~^>w|q>CaaiOHDIzD
zZ2jZIN}~LD%974~e?iCot#=L9{rGeb^?>og9ljVcf2!mE-iK4R1=|bWki3f@I3F22
z2MFOY{yVWBB!`v60OFyI>j(Zzqx~Qr)7Ue?_#!=gF$8`v-A`E#@qUn8ly`x5sY&@a
zf*7E;F6<?vQOhuwtdx{If}M}0-sO!eQZE;n+dnb_<^V5>1G=JP)mAOgk*>OoLnl3A
z%%vLpBiiI$@7`PolQX*JFZgzz8i8*(52Fy`YlTs268qnv_n>nqQa|Oi%h<nba6`yy
zu<85`EerqcdTgQDx!zU3Mz=|>z&lr&%yB&~6E`k*;T(&ijuwtp^r2|J-!5|grWn|{
z$Fel+8}yjnm@$M}V9Xyo2*Y<3jCW}mJKub8%*B(;&^ffpY|u_J6(j{`KL#fiumtDM
zw;Y7m<{ijz%v9W%8lwr|Y<<>*)1>_^hw3wgt0^-2r@F>i=FRZcMyHP@TX7Z2(EoBm
zDaFrSXs@-;uij#%VwktGzKR{^iYi(P?b+iR=cC;|_L4j6y-?>xjdS~B8m9qm7}Da#
z%0gx3N)O1GL9vOwf2na@SSfTDdaEHa*bg>VvHc0DDWT*v?&&Y-8gskO8z>k0Sm$WF
zqaeV23j_961aC&{yWND(tuEa_r&N1!<NEbmZR!NH+9R%Ly#AbyBYLw;?KiA<uVVwU
zvwBMxqbaOj-RP|9<_se$4X)uRol8wO;|6$WHzBrII*L!Jqwb!yV6CZcj;mel*mc&{
z+uhaG-YS)`yQ;~H?MigKe@*W}nA59@%DRRu!j9Q_0ZXT}+;*}y4aUZF2*-%rK@56c
z@B0kG4<~r9#xei*#U{Ep`{V{{Yfb+L^?$U5QCpTEY+tMdBK$5i!!2D|LYIpkuC}i%
zJKf*b_I|mu*zVq3=yIVpG!s;VvJ$g}{;d(;kPnNDw(r%vUS7J&I~P~cq$YfaReLvg
zL7@>l?kD?>Pz5n%M`8+X6sV9wQyoWZiHEyCrTI<D>yYs%6_-hv?-5;9v^}Uw#X5Nm
zrtK>R$I-c+=@+}4|ND9_RBncy4{o>{zPsSM7iLh(A~{GL*_F7-Qx8SCQ2`Vl3?LN2
zgqHm|?IQt<kpVFT0$N1g(=Y2d*ylMX)CwjlJ*`^yIQ1JczO!WL(9fyS>iaBz64+Q@
z_h8Ko>f8!?yI9=8ce~%McnrT=y1v+6SnhUKHu^f&QA-(jTH#ZPJ$uh2`3`U6%7>7L
z#K3*s?-k&bKB8p(Ud({Nx~+S?M!|~j^-{8sxz^XcT?b%Ef0JxQ2D^_jy<Gqqz|(zQ
zBjFA1>tX^0UgpCp4i1Euq^HZEZ(8?r4TP7ZpUZ%ETlaDegqNh33-BJ(v1DKOaSeo*
zxQ~m)81%7i>i(_4a1-@!G0^vES~qp?))1J3TM-g$#S^keHLh*ln>7Siu=zZ~R5L<<
zR`+BLggLm0DOpbz7+BHtJG$p;0$f<jB<aFY`hG&=+toc)gYlUiQpuEYS@f=ZsD{Cw
zsD}zH2#(vjS85~<v*jrn8yU%e=XFn1LL6aRQ$jpqXPNI;xyNWc2O5_WV#)+OZR*~p
zQMjW0Nl6h2Pn)`jX%wEAOgbs5jM(zL?o%3uE9^Q-243Q=ulte)!%p6pL>?&f*0%0N
z8VEN@FA@Ms{M*-kNCV*|j(%Ye(!B0L3SgRDJC02J=07IuK@ys?<%r#zpyJ`j^dPCY
zChMYI-G3BMb07p0QzD`zhu+rxM}R+G{}ITP96I|8s`fn;hEd-NmqUtI$v3xkZw$d1
z+4n;$9(*oqk}2Kq5&71@8oMM3&OmMdtXk9H`{DbqF<VCQJGsH?FBb6)J-6(ANUeoN
z;*F{H-U(h`@7oQ=D<$?Ah6hM>7{|iz{x6K;SMbI#JOSQSE$6A5fqo-3TP_xi-CZC{
z`#9wa&VDoCbqLNFJ||GD$hZGvL-`cprlVA>_XO{@?puOA#qlb5W0;*lslfXSlAC=t
z%I_WZ-K6FFLz-?>%oF<i-x#%#JEDJN??jB^2Uy#17JgdG-}&KG<!|qFjqR1gX%?AJ
ze<YZ%w5=YHd5oRLi)nDjf+jvOq+y$Mw#{V17@7wCBW)%v7Q|+@^j=sPEAB}Cu{M(y
z&7ahEe*3k-b}qp!#<vCpx4~93KCIDpBRp(Z2FIH5@!rKg6`23eXg%!z?<woSwx03D
zFhcwydtdkF$Jx9fjj`E@?I$^`5e#6i6&~h)Z?yd+$D7E0l7kz;hS*Q`hf?Mt-hNV}
z`x(h|bbm4IXJovNi9_*|*RX^gdKcW&y1z3C?ij}J2={H>TQ?N9I8Y4Z0~}~5=fZbZ
z_cJBJ9mDt}xTStNe=CS{wuOzI6AfFbWP*C_j_zLtud(=I*qcbN!rzYW6+D11WnBus
zjPA)Ah%bi0N%Z#)nWuD*!%R$%17&kkx7gG@2{YsLBmls>BrfP)1AITQ*MRUzjb&f=
z6X@}Y`U&LQUA;#?gAMf2d-Q}glX<76b64-B&&2G%U(o$9BD*OW8`-;-aU#22y$?Mz
z=03E1zoqw~XU5rw23u9l)AUd2y*iO1-^8PD-%&jo;(ReT<EZm;Z`ZKq|E-3__gF1)
zr;YF{y55^sd&b9|$I(}FsY3lIR$mwI(q}SXr(rrjsCp7kVEiR~K)cEEyQ#mWYL)Uk
z+7o|5f48OOdQ$e8W$$*3JyOt?b&ef-M7L=Ld(r)GS3IcJEZ#Zhp=gYV?IRPL*dF+u
z>H`xw?hP16%@G1?DjQFO^pqXfa@Za)F0QXkY-(TkbDSL72ZCk>w1EW8An=n@8fW%x
zN@r)pa#XSOakt&Xa1&@2Hvok-*!iDS`aBc#F%0d6$aw@0EibyIBJflH;~I`(hmXi;
z-P<R$ZfaW3j!EmLruFQEwEn1;)lN;#kuK(}es=*kWwfv3%B-t!HfjaxJ%#Ru_0Hwx
zu5$r%8jiK&PMMW8jKGnaKH4r~lYnE{3OX8uBdffZ^PqxwNHe-EE{MxhCzOr3Ru5jz
zn+w`Ol(UK~xBrQfdro{##}uG5@9iN?aA18@%V1acGX&p_?W+OEU@s^0L1lv@VGihN
z5QswKw(e;d2ybLhgFp=T$G7zU&_I}IJRG$%CQyaWtzT3zcnHj3!)4%}y9O$G$DZDE
z9|-e~_S}VoFpt~U`|cCqL%K6^-#tM1UTuH3-==zm2ICuN-#q{y?C(0iJ{tb`d+#Bh
z%My3>KJqX=7|%HS?;6b&jbrKqBkW5X?19$TgoZ48)!TaieKap)@4p9v6P}!Blkqg}
z{<|O&JDbw^(J-Ep?}-caFrLi6L(L@v;g8(EJ_vK`QzK-PIGPxFw7zQqbRN8GK$B3^
z_O_?{cJt<J7WDt-ykR#*(Ig{z=e)*Qh{IWOJ=bm5Xna%So!0YvA=&)ydUM>@t`nB?
z)V|Hh@nafZM)!G!@J97$DuBi)-6+pfXV5>I(R6xA>7+~*852RtiHvn0eF($AiZtS2
z7k>yu=Kk!A$`#7U)5HAWU`9*{8>L{9$Ii!oSCC;rPPrL7E|SFtUxm47=G!z~axR3^
zmn`M2LvwX!;CFVeetW<;GgsdkFeaL-XC8{DHNqvN7y8n)J_AyYaD#kz4hcH?k;DFi
z?60YusKPqBcv8=5SGp@V+MUaADqL8~$A4CPI0JL>q{`02b^h+JCitFmOFF3%ejeD_
z{I3uG{yN&HmsYy%wKX)!(`g8sgrL^2|Jh_PqGX7zXA;nG^UUd?H0&gxfnY>wkeKG{
zSkMT3cDTP$NHiBZvUYc>D&Kze;pNWt%Zr_M_DXkQrgQr8i7O|McV<syPn<fHJ=vW(
zvv7QIwwpcOeGk^EIj>xKBu7`}@HIgKYv*_b*6}ldc)D}t%<)e4#N|_`7G@SMpE#2}
z(K$Ukd*$rx;t*KQOa#`c<5y0dJ$-WV?CH}p-IHfec4oVs6Emk57ET=Ro;^LY5W>QJ
zKsXfvn|-&$;o3cX=j6FzHfsvnu=k9%_Y1?mjWIS^2XAS6ANswCTlcz)txaoNi~D|*
zy$g(;mzBK_gE7cnB{uKqxbnEfK$`9l#zw`!{<~B>I{2L(1Dyfz%@{cU*W+PDW8l;P
zoN+NwY8<!qS+U2hb!xz*b#_7Inyo6kYM+F0xbA>pD9WV)Sq^Cwd<Djowy*Z=Fc^V>
zSwIBFwzje1FyiTuc;aX~i-i$uXcj3!58SSfYa`*rlM}$%(>6O4j%Bp*^lT-e#|*SK
zn4lgsrR!<!*#i!s3>ow3+YxW@pUj!paUTxu&269NvFZ%VshmT<qnw5Q`>Z|Y9M5>h
z$am^-4{y9h!-^>wYnb1l$JPUw;ejX`A~+uiU_}bb8jjGv9>6gV@u)$9>%-xg;NT98
z5E%2}?`>khyNr1jJxfYXMv*N-%isHg9+P+4*=)Y)H*;<|?>GPx@U?A@nJMJ!Rlm|I
z;CA?Y&Kh^$e>7mt6q>b0v+mb0uH4{pLYIG2%bak|cwVFG7AqKc3Zq1p`xee(saY&E
zTV=vov|zo6zDDMeVU=<v7dQ(jS!P05pR-_<n|`I#%F{*j`H}_etrq>2a;{t{)mqLR
z0Ta5WtTEMEu2pR|iN|8gg7u1pv)XbS^>WL1=FVc2$l>$Wm|CMyYl2Z{ZpIk1^^D11
zy;7+bJPbMJHl2W`Jqu2wQY_`%QkD3tGfhJKYxcNivsm?f&~&Vz^dsYTt#Qqq*Uabg
z6@pi@;C<8{=QUcjVjc22RseDMpYVCFB{RQTt5?eet_+b0&M#T8e7{xjOJ!oTpyVp!
zUN*-a&$(`{R;}kCSC(vubLy)MxgF0}VL#Pe(ea7XfG%rH!7Jo^x0rWa8YA(+F=;<u
zDA$`l2qWSf0iQzK$9~PQ|Ko*PzE-I;*-wgV02%PQ^_n%#uT|ZKR|L#_agoLe?$21f
zdiiFloUib>dZ1ewo3ZHhyjr1FYLE>SS^=Fh_7gVTQmdG&R9za|JTUfkdu%yhF6V2+
ze<9>w;J#pug~L|8e1-iCRRnDlGB#_`TlAVPjE8Nkcwp?q_SjOjR78cG<W&mBiVhyK
z$5y>^3Bd|JrANxR2kmiizIwd{8JyMQgwBuIJhci9uh1$9{|!=Cps!;#%$C<`lwnV#
ztAI{{J8h5kD~(#S#Ja5=82f<4dWvz!ORZ9~>F3Bd@>Rs0x<$j!S@f2CFW>NL1h)tp
zipnpAhUX(=D=ok1QY>SevHk8PYiv2!YPBkP*fz<FMheV(EWThXh@c3KptVBuGOeP6
z=|3|4pi(O4p{qK^mYZ{DFjB@H`=U7xZdEG#d9qjVKWmJ8(H`fOn)PM_@UlEAg!lR%
zTkxuWtx!?&Eb&N*4_Qm@jY6f_^t_U@MuUX5g2iv645Te`yP|eGfpwqd^Nm)$T4};G
zPRyNf0@*!a!D_ZJQRPU+9BcF(DtH$yc&&1|+VEPii8Cy@P#^bOFnzz~R{bi;n0zNP
z|GoV4M$9~st9#XIHCJ}lmR6h~W<K{9tuYO_ZO$z?t%Y@m>v$Rb?~IA_M844U3xztz
z7m68S+z{D(z=D}?Vj`?Njm|BoHo*I7Q@1Ay`CP7w;O}&<_d{JgYs%zAp<ZZKa+Fsf
zt}b5zFv0hbg|Fxpt4*)woa=yvV9b;St5m4ebLCtWJI&WZS$xQXQ!3@LTVBmO=enRt
zaNV@Vl&iTyzT9d!#qQ;B%(K>*N}*UPBXBy^4MXk^M#fZHUL6KhTwMy`Y}#Xr)uLA^
zxsJPWH5{{N>9~Rk%6D@mXT1YlRELGgGbb(mRcgh2-Y-%NQE>tPRdGakJZ9r<A(`_r
z<ovab5brCN{;Ii(-^kbV4z{<#F=zgnX<OA2qD-M!aQeNc!!hd?u4<)RE&G^bszkrg
z^I?08Uu_ke*lca~ZiKe-AxpotawT7_QI2zx{-0q7CoP(4<!Y-`ZZsS;ri8GL{U;-y
zoT$}HjbgJwa|CMEWdqiI7G1R#=B5VZbk5ZCE0%uhZavp*!A%!>$RLEj4_a{Q$a!<6
zS`GHH9FDndkMUZds_Hv#e>EKQ($|{uu9x$eEfGUjOj*8YkEu2Dm0C6DG%5cSdLFc7
z)PR6;Rix?5J;Uy%EqWU8fx3&F<6;*XkHC2d{pLX~f1**X7mBq)-D%%K0xn~=Y&bPn
z$p?4BgmLs$bFMnkXqJ)u!PeAVg=j!otiXG~g4c9QUZv^z&iRdQh%;-^)pTo>QoW38
zrf(rp7dY>?;IxqY<ZAG}M#qr%jwQ>MS8>ZUk5`&l(g>XG&ziQ>D*44a<<$8{&xd0^
zZNsUS>-Bso2VX*v6F4U=np@3EJzs0(Kr{SA=IRH``S(Q2FIDml&OvDY)pMr6+xenN
zmyhUM#RTOn^x@+I?@Q*qdcwy%-Dvrer(wRqv>DKMza=lf;FfB*{G-tWdBNQJqB-Vd
zzFBWzeb=D42<6~^G8b-}K65hPYBjKq&C$GtU~P<h-Q?k9p-`)q3i*a}xraJ7jT1h$
ztZ|;#ES6o2LmnZ~A;kS93%6JH3Vxwla_|}u%{bw>y6Gb)q54{}*r+&b-?h4KjeE()
z-E6?Seb=EizBTS)3tq8OZnpeZ-RbaTZQ$Lp=qqC3)vUTLiubl`K4*<975!?ngh_Fs
zyQE|zvd)+`bFx&cHfvtfb8hsOc<B=8WY6NG)T;TVRy~K9fNS+ZUNCOnw3(A-*Dus_
zm}@#4>pg4SJ!ZT<S@x=Kp#^)+KZX>_w5#Xrag`icDLc&z^|}+_-1@9x%O{aJwTcKe
zm`l61UA<t*r0iF*imWs!7TdCW!1T3~HP6SiRPvoGFanE*GnP#1ZW+@_!=*V;Ih)9M
z*RuOY#q(R0qEGRiQ=)*67cKf4b>x%~wA10q+>r5yzF_j(tdzYRne*&Q7Za;7?llWu
ztAH%T&*hyf*mvS_;vXNhWZWvcb!3&49{BYC+j$x+xy1ILn7CWD7F3tRdSF(D>o_C4
z7c9H>3zcH6g8E8_CqRSN^QJ6ka~>8hK5~7sLxw2uK4Xt7)@ptY^Xb|(yahyb%D7F_
z4rg=Cd_G@AZ3Km3Jj`c|d#kDI*}Mk@qM+m~FLFi@!h6udn<tsWMcI!n`W$;)wbF1a
z%@X^GHEzeWiP=J<T4*9ar}<ntsOaX{4;ynRYN=ihvrNmu@;8t53nm(amtz($NFlI#
z!P)>9(NK01^74?Wli6~qT*f1Y;JJ5o1~YRw?gfiRtkJOaLyn3$aDg30WPQfMiy({&
z6KZ>CrMr5W;0Z4en(MFGY9)u2B<5YLhwA9WRfZ!l@3mmoa<zun@LLWp^HRnu;~q3~
zwb@#^j)Df29ZK$_=g(KdxvcQ@rW|W^TryWI<()3%SkK}PBaj)`&a0LVQN)A!fS)VN
zJzi1-<91E|n#FqGYn6~ok-r`%fI{P|mMzw+rAEGpnnQPG<2o}P$me$q-<oaIYF@!b
zDUa4Wb0?2qvh3&c7H-Vn#Uip8q7m0w8Mq7oz~tL6ms@$%%(VFwoPfrCljl>pW;O3t
zP;*@D;aNF~qQXnY<mHryM74$V2@MN~dbGxuI5BPN`V^MgZbj81pzGz%I@JV-%mD85
zpEY<t1@|vi5L=Mr<4$v$u>^nCqSK>*TSq;F{htIR_!mvPI8`j?ka<y^kAkFGJQ27z
zExt<m3PL63w|4vKQzr?oj4PY5_Y@T_YMx8{cRQD{bPH_#1E$}eLNy3^pI=gfe}uE`
zkf(Xm&rYGp)<CJfLTkZAUNj5tGxoT;hY}}vLXu^V`-CM+cuqB+N1j!=y3$)Ub@{Rd
zub#`5i-kgo)|VR`Bn9ujC7XJsT5nasGsjX>HlMb~VL_im5O)@E<DgYzxzF_NQw^`u
z$d|CbXkWY4@2wlU{)7du(L%D5!#WI|s=XCc*O|U)I~Z1~7ksXXR8}^Ym*GElohobb
z-D>$T%_=S1lo$gYe$LXNUn;?Ckqff(oQvr2=Pa2cV<<H$hz0rOC3;6!-G!RL|F%sZ
zKjmX_nJYp!6a&f6mlw%1h&lXE<nNgDo<^Aj(!zv~HO(4REb*gk?!%nUm9dUQhRyY|
zI{G{qs=z#B%Jy`=ST42vJo10!rDyP}W`O&n7Vdnh3OB+!59@PWb&2#v;9aue)k~#{
z+bB9u6F`C|H2$154s|+|lMuJi2!kh1HQzG!S!=9UC^y||IgfR~)s?Qw3POLIH)|ZH
zi=J0OipulA4LlOJ%vCgj`(e|EPZ#}s0Sk9ZpccE!U0f(?%KjdUh6)7LD!H&#igz=o
zLjFH*$%!({yobF4)X{pEalc_8r)w7OYOB%6<*+B!ruRWloeaml_WOoSpRTp)#Tq7j
zj9XajE-Z)R?ziZx7xOJdZq${DJ`>(;Yh1JFHc|Y{I~SU@X6qtCvFLHi8iz#M_bK;f
zcqcHc$+*||O!_d5dqwPfI0d(XCATrJyl&=}r(0!Al7(u`A-|+YWdnF0`U+#7I_)D5
zYvqvM6qnaj8ZWy0jJaMpjYSA{dCETQ2QOYMMC|82b3f=z4r_CWFy}NHb2E#Jb2GOn
z`xdwvYb<Q7;pLDAq7Ko$&I*K4$k<m+-JHQ3R45jk^u!gt&<h7f-6<G5ZOZdZ3AtOn
z?2*37evZ?OnF(a@B?~UfE<VpJ{mvRp7$XJ$$4py0Q)*UAo{y~n)F4-tQv#-p&3w_&
z)0q+~xA{h`;;0UMz1EVk=PkHcBcnEiIveVKt18eKa2<=UGU|V=BH|sn`^+hFcw_8q
zHrzbYQV)AGsNWrwZQX)f!6sQAg%^g4XWtZDnd4tI>n3L^wQ{qJIF7(fD!@*i1b*S~
znng#YNt+(X;ZZ2wSk<9FklRVi9x#D6AdR|HF3+8~etqu58m*v&j(aT`WB;<)^09`d
zG-LhR#>!K)QA7Iz;ybrZTR&54mXTmq$<*Ctv~Y*E^O7YCB;RhcRm2*;7tE-ko_EZ+
za;9Fc7Tsd0;NT5sb+t0-L+HI`#>zAGda+n8<F;i=nyIm%cO|mt@QUekXPOnSRcV${
zBUoBp#|^s5=>+x%E!Zuj0L4~aCFF?lI4r4Q%lOwU9kz=3LZebgeCVu@67i_BR-(x6
znk8%0y0IHp#xfB(C0>6HWw&SQ`fRRT_K+tQsFsg=o3%p=4d+do&m!%^&VZgfF7r8{
z2+hx$vOZfV7wWBgJ?G%$9yr7-#sR>v|FT6(p^lv~x5l;76+MH8di;dR-`N6e!)sL`
zzuA?ZYC?hCi9MICv0e_cs8!0ykBk{ocznpTrL)*iMyU*i6s+1Cu+Wv>(~vi9{0Z#m
z?D0kH`4myJn41kn9gKa_q63+}*UHuXKq+h>0{3A{cI8UdE75`k^V;$%P1Im7fP0TM
zwu1PA+8ND(xGYb`3V&rwhbXVq%RbjWOYV&;h7yGi--eAGuu!d29>4bV(v|f#wQL0b
z@``DrXDfaYt5MXkwT-T+|02Z{*iTxpYejT{)XJ1IDA<@qLmpo>ed}!9^~)_R4N(QS
zfrDo{K2y&fKFKVbYnrol%#SGNU>{EBE#|T&pncb(9Wfde2|q7ElCoIkV1na8+!qkk
z>~pS@uT-&-Qms0r?)rH=^jqXdro5ZPgM738W%f6opRZOb=-R<I1+WqK%~a%@V!7D#
zTx1UJYPSeacKb_fZu1;wQq}v1|74cU+!?fC_pO%qU}<x+K+_><kv)T<;u={q{gwWR
zG%cX@$p~Jmvo`bP9MS47tS{Z@UPREL9jfq~2P5C08rUqj9<ux1^?qlydyWH}k_q*H
z;?vB1rmjG14T)~6!MoBWcViK$?rIm)&Wc1t`7Rs%u2wHpQA6eE%m;knf`&oMck8AP
z0$;s`Wm*jtFZc=sb3!LvZOO4kcP~YF!-QBX<r_Z9qt0iR==OeF-<h|X`i2+~0?}^a
zJN0~}aK5KL<0m0P89osCrkpEyULB!39E~sWJp>=nX4zuifv$74I(D8bYmd<*XW^#~
zpIIQe_y5qycTnssxJ9p8qArM8Iv@f|>8>rTF7<KiH%E1m-!bX+qn-?W=e1e|x9-)Q
z3pzT^hCP6UN51nT_(~<zL|o7)Gw<B&La*I<y0f(I(09VyqL~8#UlqoW#<Q|>?$#P+
zD0()5&YPm0JmhWfmMQnVQ+F%aea@F17ajboG<<IMN(atElV&db?j`HHf|Ca-RNk<A
zc;GuOz6)>LmTeS}{FJbNi(PZF4ZI?t{KfC}H@LjW{o};rb7m~YOS7=wS^-lv+wcua
zk||`VC7)J9@a>i*&w^9OCRVA)tFs(`m{-*VcXhRMOV7*Hw@!Gc&73XgIoPnO7W0U9
zi})XPjWqB-pyof{!v7p~zX5%Fj~R#Yt%uH_YMr~YkQL#n2P7EXxwCM0JSl(|OYmu6
z1NWP29DG}Ky;i>Ldrr)E)YeA5?u7IGRy^|@Y*?e1jf}gnalKE0VYYYqeK?<t;)&kt
zq(~OxJ!AP4zDGk#tyqBb!*SQUm#9g$TkKML%Zpmkt7GZabLv$W-(iOGP?1#jr(A1I
z`F&B-yBVRkRq-&laiOI^F?(*-qh}>xe3W`qe^8OrH;~VEC48@2_EB_T9KMUSh8g2z
zLC04tMD+ZSCGVnBZ=#BlYZ4)`x+0ki@6TE>rQ}o)UmLl4gKXLo*jl5r_Ee~=eakLO
zPPJLByA5P6gtN2KTe)?;w*f`bixX@8&O%qyoYS(~oics5>=dvyU9J`B`$7ZPm|cZk
zsjuf|t%MBv7P%FE*Nkmtr-ZzsTFAGY7Mlqy8+JqS2G$B2#qOrE7x9mR6>};Mf@!hn
zqN;ulbNjW`Zf6k|v+z_2i^vY%BVwD8Z$D?*OvS-gey&)rdL%c0wYSh+TT>G!866@K
z8LH6zq(wIxVRA*kg&jYvuGeASRLi;Ez1~~BH8+d51)jp(ozD^Jg8PFOZWI~N282c?
zmvDP4bWnfMRvnNF?!DhOWma{(I$E6aSSHd17??_f$1;P^siY>j9m`&-4l=Gh7P}R~
zeF0Io(7n>xSk_aep7R9vXDpkkIjGv9pn}GmSxOvOMYEzhc3B+^1^1$byXF+I*753C
zO=;ZfTbiHg;ZF$tqQmDTAo|QlEgz{lm2y6h3@hp*wB9qKnrgZgo85`P!0HTDBkG`r
z&0p=Vbg|l*JF6C>VPv#nT>Ar4{&go`ulOanE5pzaw9m~ht>AVAsN$I}wt;vrh}=i$
zc-G2^0HcX@dzDrrpaX#!B^nf2gEV+{VY#=4kjEY<Fh2L2HXSvu;@68Vk_xWS&dpxy
z^_~K5>=`RdAOPBd1jg(8HjFwFtX7#;XP^TQ?7)7xCQhYHs4|w0S1g&<ohEjS>P7C7
zG-Qe?=2~wtsu-c8AE5)yAXvd;o+CPfRr%u5njxF(uy(38iEU0>v7qj>3I%k{VeWAI
zeZPm-pKig(lt*JGYT*5;Wqcie|GZ_J4X2DPEmXmrN}$R7Ds+lv+Bvv5Y*S4od|rj%
ze8BRJhEp%pT4)ob9U5z%H`29PY#UKV&uapila58;_>EGjflfh|#WE$ZbF(s+taFT;
zn>FW@s*cYewQQ`3+yMa|jZXt?Ot;_KIu@EfX3cL+_-)CrH&MA^{XiUK99(PWNj{ni
z1v0v3*$QNfd8&bc&2TW~%$-&48<S=@Bx9lH^AUO~4Wx~gnwq<)w%AEV&qJ2oH683|
z712JeV#<wxuOP9Tm9v(Sx$qN~&YDic%hxcCp#n9lv%B&V%2wEAhDR9&K=#|z`r5MQ
zlos;*JbD6iq_2Fjf*IxVt@SSE<0a(8@=x^NYxp;Q1#L}vx5(%vOGcPdbB!A9;;^h2
zyBy?)xOX7ydo3BY9Bh|h#}(^mQ}<Ssu!SV{_&JL|6rxd*E@4x}Ip13+n?|XGk~}!p
znp*doTu0(o#`0C)Df-PSD(rchM^w5;D|>&nyRfv@b=N4Bqkn+3)w?|O-))mG6dg)=
zujLo8b3=S}uVE$~t$*Qd$K(wQm0Z1yWg04`_0H;5tP79_ZBUI4nGn^}kvob8l~PYS
zp>03=Yeq~4tb88DIO>qF<9aAABf0|&-^qplWS;$;4F{(+D<uz|dby5~o?M2|X_n|=
zuMj!_rP-TATc3MO#g;y3$tvemTg`l<sQurRRjeI2fi2a|H3@h_vWJRwfhx--Hxk>7
zAToQcyNt4L2<HRl91J*qAy+A)DU!ehQ!thaH<x%44gHsA;t<aB796Z2OD-xf=vuLD
z`@lS?EIfqsz{{qr@c>z?*eIac%~l!a-?InQMk)*B<CrlU2f!*wauEKNO=|f_t>oa$
z9MV&_^aVJzT+>5(X|ko4tp_y*iez4X-CU1>9-OE^Phicn=G1f7dQTU+H@eGIASf(#
zuqjVWiS2ye;;HCV8l_qTt(i>Bb$*BwmN&@R!kp<Pi<Y9(Y+~u2Z{akQF~6&%KbW#9
zoDeO-&sGFR3ys(4KyO(vbn<_`yLx?Tg#%K<<Y&s<lSZRf4!gZLtVe4O$P%pNuXR?i
zTADR#5k*zQIAOy1v?Z4ka_K_3R>BSkDd~V*qH1yiKflki;gVCXBk{qWCBw0OGtQ2Q
zq(E1%n!Rw~tzPqTbP&YJcUD$<@TJZIt&4b-u>lsbu`-KF!a8QPULTNTF8jQ>u0}Zr
z%`fP~@S6_$HPHQnxlDx}Gv1(@!9j6D&vZnX#MfQRp36?FRrTwt+Hc3|c%vpz{GJN^
zw{NbWka|@c^&F-m@_99xlArMs&ZKU330#}>IRs1Sd&$xP%1KqPUUI3%16_(~2echf
z1H%%3*|+Sg?s#q<{S-}f?&Me33zx6rcse=*X%10U+PT^FUJvU`^sVx~gur>-qN(l_
zOBM8C^QqEU`?9GD?dxF+4i1LobGbrAuXjxQis#Sb?f(DOs2O0HUq!Wrh;ra*Pjy#U
zy32FNaktdk-0=<kXYTmg>cZUdPQTB80VLt=`L~$y7Ny++I%x`t!Gv(W#-zu0uxZ%z
zy<%=$dbYmOhJ($57Rn(>!36Z&`x^#dSh`>z70t^{M^&Mqa@=^lwuJHkR(HJG$2+sD
z8|nd1m}6j%A2sJ$f>Xj#8|<dBJqF2ju#BLGKe%GSDGDCuC0OFi_nEm3U}2*uhht0V
zf`WzyIP%)YWlrSTV{WSBZKAt-puAu|2Jl*?8ahEh+n6@+nYWp6a*pR$%8erS6%xV`
z-|btn$~l#~S8QRED3PodczOx+_bToV4tdMLzR@Cwa$HiHL`LU-!iH0?Rec<esgDci
z(lHYb(qm*LWm<0~l#$T0ZRVu#v#Li;G3a6l3{%QoMt%cx#f=59t1vHl=v!=haH^@^
zC^Ql~uF&)0UpD;&n}4}-qk_WcxO}ZQY<im2S_Ad!;c$?cKDEx%UEm`xnDZST3&+85
z*RAEyJ)&zd@$;SKCggO&-&@~d(p7L8ei3I`aXIjqdVA$Bm~cGA0i58^;l$dQa6a(O
zHXIc7A@EjlTsXdEM@0uAsf5HGg+!}nWf&1}|4`*>)|5}-pPBkEI*nSRjGm$Dxb*C;
zn|zg#C;NHY=uaq~KwpKD2?w=gY>*eJ{yzZF(hBA^#O^L)sL9vj514#au>VnnWg}M}
z6VB%>IRg&j2d*n<MC3ehK_Yh8{}&N@nwa?uSZEEPXV83oe#Vp!O4TSJpguQHK2bOl
ztEc|dq^F9tL^+ppaeAKC)VN}5X6|_V>E7y7bH`_qJm~!42Fg>tW&CXcE6C8tHh;{f
zshUIg6g@~kCU5usQyUKUUZ}-oY&fr#O*l2wG_cg7j@yLvh>Z4s&y-Q!!DSE)9NovF
zv~#_46^?Ydi&ZfGD+~SEr>`w7px*Ix2Ptlci=v|cc`JT2oB|B8*~G#&Ax#2j`}<Aa
zkgp-j^3i3OG^Z8b%4SWYfbDs&*eK!*?j$vh`|AcxXw!h-qw&$L4CT#;{X!F#{^6YO
zVV||`7h9f}8^<OE*5<1wEL;YHf(`Z&Q6sxXiaWSyQc6=xGu3JrtaBbT*EzTppirtd
zP$!`dsj=5NqQ~bVFmVK->^7-3bqkMZtJ<Wda(Ri$UW>tg*wb{tM&Rt4^EYU#dpK!^
z)5hb<{&~~Zy^7Pssn&*zZrm~CC9;3c+)u$&QuffwUBL|{3@bNC_Ij?OQ^H~Xede>K
z9&sQPzzT)2Od`nTH_h6Thkb=o5j%c3$ub6AB6r7xRdgMXsvp(y^SG^lXYg0aV;-+o
zuqH1<Xs(Y6NbAu@FZk!N212#lJMZPsdj(psQacBqniP7nzh%N9J80ng0qAcyoX!>9
zuOM(<f5n7TbNp()RL`|?Bj9i(B)tiojL8=o8gXb9&0@&AhtqR_uV?>_K@ZAhjU3K+
zmvKO7IGh7~`6gdza>l(ftup$!N5BdAlHQyTebJx?C4~}>O?frGyr|J#US8_2p}e84
zNeTLSPMYhYI#OD{SU`6ZS2VESLz{7Q#)HHceB;>Ppf^5`!v$*D*;#xa4&hKUh5AVL
zgg<KL&UKVyydti12+A>WZ5Kgb;`A3RzN!sG5!@z&#>6Y==20D$@6`J%j(J9>jus7U
z*yn3#j#}y7T-TD9vG>_<n|>La9(<@_{n`@kFJYFHv3+|i?uWsSFq(<mZE2qk&v2bL
z>yOCB%1F!#m~t8@s$p)<^=`T>PwDNr-_#qX-!eM95yf%20~|o@1LgCG=XsSL2R)M4
zY&^JV1m~sD{2$`EXz4BUx*^8~N>25PSEnZR<t6y-i4M0Wp{;{H5}SJ7rp>EYTUhSG
zK(f>TVq2B)vuN&<p+f~*5{(89#RaWp-0aAgJhcedyR`0JGwq7LLpyA-;-jmyr~54s
zUGRa7|EReajPbact%cN;I?}O2gjPGcJi&nfep81SUqs?n#KEj~dt(Kg_;fml$ID*x
zzIo>v&Y?l+a1Orkh#EBybPCawy9NkC-wQT<RkU=We}oT*pmXIQeGi%RHJw}@hlE|U
zt+m^#xTq{L?4xo_Ib(bQH`d@rpHR+Jm@y1TbV@P_>KFLVL(^CZhuzCiCu)ord#gCk
zbqaU8!A#|wW2SDf&5X|UvZq^@Zs<VK#hwy*z3~6?A6t0PK<*W5O<W?-!y%IH>J{oX
zGWB`WwCARS%hwt>yjF7_?FFTNR;a))n7xnKO7(G-3E3vsBaF63;o)A>{##B7mv;C#
zLnro+)-^iKM0OqWT`>2uTTZQvSl2)cV$epSwzAo7gsxZ3eM@|UZJC<uqu(pv==4=N
zm%9qYU(T4dU~HM<9-x9xm-K;>E8L%EcUH-FA2sERbQ_nl6{;Ll(W)D?e=e+T=zVOF
z!v{>Crtez$W(`b7TW*Od!FAKz$3O|SiarA@5_qEMU0+$k9y8)48u&FX`R<xcBQAF-
z;oNP_q0?Y2I=B&CvH(j(Cwk~RA2e+NO8|6=pn0kQTeyJUW9hmHZSD1K!`2W2aj3Xf
z!M0Jpx9VYkQ1AAH{dDI|z53Kff@5!Jr=y84PPcE@G3uqi6s{*`X0RnxLJ1fTsDSj~
zoXjf*Ei)%D0_$?_lyP0YQ&HxWw|=hy>jX~E=FrVgJ7yTi7b_YtUwSd*Z{`H5#l?cp
zSw1eKC*<$Y^xgkSa~y<*V>&3m63o0gZpWe#^-J7><I{8u+{ZCc;63?*39r(?O-N<%
z%j3|V7>wJs=);B^U3aH>Icbdh#P^sy*Kt84E*hYG19(qioXF<b|7PNCHgI7WZVXf7
z<lZM4`?^slnmK`{1@!4*smCynq0J+M|H)YAzccX9;!J9#RccU&i|Zn!yY6=xG~Dx~
zH8xjtE4cfR$8ONrXN<AW*>DSPEuZImBVG3jjqMm?ckHpHvRi-yGTiGl7VVn>y?aks
zG*nQM_1R2acZtT*d?UQwW5dPuqRnz%$pNQiT$ifYGWJqrERvaOmCWCDaS+ILSB<g0
zH8zjaxeeSt6^^AfpTPAknc)l^F2QM0r<v<AZ`5EZV=vib5rXo#ftANzr4N>kvG*GL
z05h}sdZURGnY3f>Vkv?jl(Y!kCl^hb<?BtPfRvqT6%%X0*fTb7ehrldEa8H|rY@$e
zu>~}e<Z$5;k42Jf)0?q)!&Pd9I*tK_aGy5lecgszD^ziXp3)o6;JNNCW9*a-x7IA=
zOP=ya*4w%<*0IN;dof=_T1g;T7p9KO)>vF?iQ{B^*P0fZX}>ouoAe3|Y(_VfuP+dA
zbL<NiZypW<R^6P^8}6`h-3^1@Yc|{llJ{C&DXv3fO?qFq$NF9!cZMiAu*^(bf6*F?
z&9)NeV`b~?n<m@`EqaT%sDRHeGx{jK4_Y!S;(}US4MJ0*_90Ua&)GD<D=KJ=;<4y8
zw`I0(jV*bo!RL9W-*w*?9s9gJ7Tx=m3hq^+VJu(Mho&vwO7&_!hXxiNi>$|v5824r
z8m{%h)sHmn8vQV3_Wn83-*D?(rP1ULaj2KZnlb7Hn_f&3Xhv7Dgy}WMPFwOV=bHtT
zftdsj4`e!lA3x-nG?Xj2=7uW9gq~xc8LOYQc*BYp$FaHd5-v<1+%Rmi9~oQq%gB^y
z)Mff%<)h_)Wz1Q#=<2KEIK7?&Ii1#h?GmS6wP05YIN9FB{dokJ{nM1itCrkwrm$Wp
z>sZP2fa&+!He9rv<Kh<ObL>Z^EXwv++~|rcaFk8(d}zwzMQbc>{;A*!UL_2Md&Q93
z{npr8&O?|g8nM!(ch}+#-7)zl778o}wlxy6$gFRV#jTOJGDF!9E99y%cGsrCuj0%-
z&eD>6IYyZNdD9w;+j#0FZ13|}mV@a>n-&dFGTOKF{LS&t)Z6nmT$Jb$E>(<R-pts(
zZ;frZxGg%TeS_&W=c4;9-)LZet)cD?ab2E^h&Ne}ytHlFWuu9U7H~v}d7C><(%`H#
zl<~I3UjruLVJXhz*+<Pee9Ic!%wbLC<<<PjagB5*>yCXhPn$)yTPV=-o+;ovpDFK+
z<ZD@rPn>wf)q6N+P2cc*XWB-_l3%k>C?gQ@P!0j4!oZH^?XlR&sbSvb!5p*9__k?}
zE#mkJjsoylju)maZ$-x9I*|%rN`|mPL@$8|vE^%#u{beCRc#(dKd2fZV|Q#hqZ!Su
zp%a#d@f>EteXEr#q45&;WZ{$)jfH^iTxrju0k>g#)aS-y**;CUx2>^$zKCFmT>%2g
zc45llWqT~PN{iSo3+XlI=a((su#;7<6mSO%!DSlE9N~;*4}RG%=W|$E(^&Qq(>B+w
zdCA8WFm>FAz++j*<WJ%wg?o+p<1~7o8aULcbc~b6m>cN_f}xD}jWc^Qr_pp>@=AQ+
zvg@9wp^N~=DdQhB_Ks&xW79ZSDeJg}8=A2=qaS`a{*nbBH=-8u9!}=bsEhQ21r7rd
z_;0o7$0-21Wl8C=LE||<!>DEayeY@ic`W90xaNsQs`QEf1o?>XZoS2bAsFw&xA+`B
znH28%!iVe&6#E3nYZedGlRymxj06{kYnq@i8GoN8qe2r8JQQ`@VY?L>2~Fq!xk(eQ
zPsZ(uvVO*W;8+>c4{mV|aMUe1d8h&5c6?<&IQ*yOx)9QI&5~2Gh%Jyj-_fM=;#>5Q
zA=ig3_{C<urdL0#Wu6|$O#*supE2zYjiD~)9+l+qU~xi`QQwj&8tZW(oL)blBT`t;
zz#!v4VEVx6GERS^OH<_nDmUYg!tp09`f*4%->UH)!mi8k+3xz`_-htDWn7x!`*gA$
zq_9zNVu>Ik^gLw2hb(b68uvHRc-Ao!g-Kk-AG60-ac>!4y@zT5eZ#{ku*>+eMGv0E
zXyCjbgJ(BjH>MaN;~%i#<Hi6w_Mqmk5P@N%eajwdKGt7&tbq~me8<U{5hw1o;N#>;
ztAa!4A-_CX!+yl3U)VKmx{hn=8g*TkIY|uT^auYmZRkrD&uF!(dbkgjaj*_pXO}~n
zI@WmH?3!;>G|#MK7AklanqL1!lO|lMjGJO~60ALpY08>3-L&kw*`g(ZRzzsmC>)3$
z<}I4g#)2x7mJ`QQnFwV3eU@B(9Pev*y5<wcJ0w?9hy1WP{w&TBH0roNi)9q*nIjlw
zWMSQN)A|ng71dEHQ}!Kx$LR%SBH?!r77V{Wi!J$PxrRIH0-If@Kk>{>r-Q=1$q#+p
z_ztU`oJ*(uupvz2IRJ7X;W>%_bb)@sB05HZWRLUHrr#4BY$c#vp&|<#1QV_5EChlB
z2mc$T9RZvVM&RK3Nj%nqdnbZ#c&Wk=m9Nt;SjCir25`=sas)kS>F}^fQ}nPTLju_T
z_^%9+6;jpp&5xS(LxO{&Wd$5iWqN2+3NA8BKkM{^y-{gL{f0;iX!>x3HyoS6U3n@2
z<HbbC5UYzxQXnlj&zZJMG?A%OzZ>CX)i6gaBVJ6X6+iu!c@v$z6qS+hq9&~?j>h~!
zA95g5OHleNB1p*B=Ko;ZP!Z2h<Z=~dL+r7v9|pnN;~&8?GU!S8yjkl8U!{5-m)_vo
za>A%Kh+?IDf`312$>_eXwrMKWaXB^`0T>o%G@-&-VWH}1Nf+qsyct)BrUqUGg1{M0
zC=d2zHg1NaY|Di6@J|~t4R8={T4=;l9?D#?v$3>Tg%x6oLyKp^d4I;{3+X<#6!{e$
zolIa;Os`ewG6Y%Lvxv?*0bkF3lMM&24pgutF?7bkg1KSlLLa77I)L+nu_rbIzUp4C
zP(sTz%ZIsP5Nw7l6}D{tVfopYBD$~R<}4i5Q*e~-d2WdigneYP4O{omMs$V+WwnMw
zp-dB-qRMjU)6iL&L=LLrAIlM0<1q-d7V|4OI)3qN$|Mbw^?t<feIK`8&<(gm0F%P5
z!D8kg%6#az92-|;uVulqAv9m%o?(=SlrgffLvQ0)!gA(+WA6B`VcNi0`M3Nh4jPm!
z3clCRNARIGiTzPD=n`q^<9qfo3m^J-@q7w;URBUeAK&z11Rs)N+}NfkoAmMBziHyb
z*@Pl45HFwu`;g?h^#c)nm7I^ab<DubOtMSdfxX<&_L==UGp2w)oL5ET3_APCUP23G
zRE(7UhnF-=2oJ&Xu0rG0w8|sQd6qv`xsTZC_V-wP;?j|N9SsHz<?!k2aq~t5A8wP&
zmnB%GkFURB;X{WH>e9uA-abtq-{#+p;6o`M*K+A)M|$`q$9l!eL(unE!i7S*$kHTJ
z;PAxdES`lpeF*1X&P4>)NwY4W!+ty{N5NfHAK94LfRu5?%>~FJ1=iO8XUYM0WHr%^
z(a@DRj?o-TnK1rqI31iIvX3K{3amXVXT!Z&P3$P**(7$2b2K`f9XSv)nRenPu=XSJ
zDtfr8l$+?Vh9OWaC1!4<yk7sf&112MTflt1GaJcE@&x-l{dk;y`1FI4lcx56->d^d
z_N788hwJE7{#K^Z{6o#zVIrvh&c098oKR+;h{(T$N9ghmeyL5DjhH=_R5*|G40=HR
zKNpdI83!P^p^nI6o_Hb-MbGru@)thui|~ncMZSTWJnNEEHvU0x?_mZHeyG25wByt#
zu#IxWX7Nx-1@Awo)uLguoX(A~+4KLmtxs$MmvHxyk&iKBEI3XFSP$%AOesZHv9ra9
zo#Dj-TyCj%GL4l!amY$w>9HO2Ux`bBb^B8`U3Cxd9$Fz9*UjsN98<`AhCV@-A+YvN
zoAV6rcdKLH7JY~WfWKg#Lfha3Erdtqm;lzX|JjDs#NFwbwA7Tvp)NvK2#m4x4Z0Ss
zyfcq}VPyC&UW^JjW9ryc`A;ly2B>}kSTd(g{cTHLE)K|+nz@RCm0k!A@XddJ1RoC5
z<g165dzDu$d<Yh}h7q@|s0C4a46f?fwC`DZrbCNWw6E#ygout=Lu@eYeFG8{CXxpj
zE=9H_I^29F!Xv6OxWh=-6Vu~S@LjuQ;j7@#DXb5#J+T3%hfies>OYU*!!tqHEYmF%
z6Umf=H%Ft;UwI!*czm%R!HElK8d%<`NhW<Bv;T*M54jiRCRLmYA*Y^*$ANYua((XS
zO`KRB<Z6{VjtnS09uCfVvwn!v61cP^@8MXUimK`26kTpTY4KTdaD6{E;&tYio-Sp5
z^5R!S@S#?ZH&xLoPP(+$9r8D(;vD^+XG@;fcxK^<%~OCXk#iX5K)|2Sd?kE7SB~KI
zv8=7)luXKgDflkE$HIrp6>w_|f@|77BKWqxHG+>`v_*QAGJ8RudC$kpSnfGF^|FAm
zjAlKA3gdWwaN>Sc&kgt9XTyW(<Ma|gk0f=+23bIuC2^v|v5IZMs6sV0%onWO3CASS
zPl}xkB@?zM{*tE;CY1lm_GGPW1m5#j{)+Q}IrNd@*gebmB2mWxIHL%2VU`2`8=ET<
zGJ*HN!#2<8Ji{dw6;+dB0L(4hJ9|HaKUm=u8D^{;7I(Ym8oq}G0Mi%NxEL}+Q3bPb
z^H=?brq6)J7p&Y2F!6>G-Rv0JRa{&;sAu8X`A0U-NE-94y55yxuMOoNN{$)l*@%Z=
zHhN6!czw%;hqo_rxqL&pHIv4)u>4uaEC;ppMB_<|qs}b-<gKiX#Q*z$(t_*az;?ZW
z9R{^njGZC_15jcW=#jBZ4hx!#yHv<s(Y);BO&`WiKAw(6!l|8rIp-fN2(}95i2p70
zwlJY(>*3$>pV(o{+TwE;Blw!Qv#W*|jzZ<8im(687Cz)gWxQV?d!39bReTSgiQvOU
zxNZ?IMw6z}Ll@}pp1)z?!zDOg8Cz8~<<RLN6npU>jNrqO9vpyh4d+Znp5hbt<V>Hy
z{#yaZ$>>Qe7HC`?7@5Dbb8rA=PYg^nkm-x3OdhdOS83tA?cvqkw!bNY53de4yn0y$
z`Sf%s@$13&nli<mW2mm+mM>$k^%)LPTz5cz<hoCUf3MRYc~;>-K#OXD`@p*+aLZN1
z#gdu}IGl#l04ssx5=RjgAsHc$q1Mp=?vtxF+&uPTYIsVRO@Ke=z@$PT|DCm~{?3Tv
z>2-e9lsoQB!vnr}rpFLF&sa=(81*=W@`S+=jzgcSON$&naXCV71M$@7`;v4y+@Lo{
z@?;?^dh_&mUU~8$S_BE)&3PMc0r?8HlZ?*wA$l7E_hS*g;o(fQVJonS)y8h5>Ucu$
z^UF59o?C06+f>Cu&URQ?if{fq>uIFkKK~CRaB)2vjyxJMHWC-2sR4<Y-HMl(fqbXe
zB5<+kRmGJ;Y-h}$A>ZiVhuGP%pSJDH!xKTc`$Eyn{=~{*ikd{*1^U6Mr$>K!lzvp`
zN1ogwp!c2#y=V=@EAwV|=@5E3Ovc;U!&W`3L<bllU+u@NBBgAii2Z^sm46YsHUE`M
zZUMc^5qrRm2(<zZPP2S@yg_gD??dGK)`%ZhJj{WuyfG!QosI3sABy-zwUkGrgwFHE
za|~($4dn1pB%W1qWgr^(l^mk+Yz)81c5M5tBAEG2H$G0DBklS0V`SX<++VTb*6{ub
zI#-QlWn7$O0kLK94-V_xLJ-K|e8e7b$uYLaOY!qi)E<V|Zy_RI+??&xgIvUHRJ{Cm
zW4ed|8_;`S1TIcm;i`L0ZxnD;Z!v%+PA*5{dcBFJYqVv=5**bV#}5|Hf%$lE&yG6{
zoRY)&Fe6U#G{%&3h-CL;y>Tq!sg3#I)|fyJuSN2QW`T;TxZ8vT9F2<{%bp1BYzVzm
zk$DqWg4Y^&rj6k;9ZagS*BpU#6T!U}f!oUEaZzNvTO<G*$YCd<H$R6<aioWClpOLz
zdVKud{D|#unA_YYI>uNIteMFC#=aF!a-5fNytL=Hy^q`WKnLF|^t2w4!g^t%7z6)_
z^JD%6|6pmKr@^%QmkHLb&wa{-i*i%0)X3$le6svNt(5&Bv{y!^)T;OYnR=EU8#Mn;
z%`$}a3B7K8(lKR(w>rEsUgE?B97G=bGlK|&5QAXY%6>Q~88QQKfxWkF@&nkV7EU&3
z*rCfXCk&BcF)IF{3WMxDfffYz{!c{cuGT#t)z4732E)WlM7NBd`D4kkf(7>NFSqH=
zw-DiRf<A;D7pEB*|00BaP~M-3$Qy?zyee)&VAxD@L~lk$9~OH;L3IpyKY!Mi2_9Ro
z;a(Es#0Lw3X=H)2+8C*UB{VF`Iz%S#|4myafZZ&WaoHEimPN=a<K{V*1e+$~V+Hb%
zNFWs0{RrI^yh7{gRzrrGglxvgw#vz~z;>+uT-?=zr-btQpnJsoS*W3Tvlhc>sT>Rv
z$z<NAedqk|*fOcPb-YxgyW^z*j{nwd88III!F(xSlBOM8t3adiRh4lGA1|9{v2wUO
z5Y<K(=~*a$=7yEYGGj(q%Zwn@D*qcVv;_8+RVM`OdZUQ5n?@-qA}OXj^!d=<5Bk!5
z5qrm#A9w&<x85)urj`+?fD%rgtWqY|FeXSv=>A;9Zg9l1TE=s-ER)2B!+a=*GGK2-
z=x*YzEj%1zOm?w;I!nqM<)@#v@?qSM*1&6LSmTdJx3YD@XT|{ETGLe=obSMs&N?R!
zBQ2|pe=r-Y2v%O${mQ?%Nk%C0zSmlRRUEVy7wI4p(_JS@^7Mn@H0Vz)`q88x9{o5^
zKVaH=CHA-p`!io}$1cB_Lo0Po!RAsy7_3$CmEf@2m<_fNws}TRBFVg0YP0V#VN+YA
zSHbg_Dt58QL?TvfT;wrqRg4vf+ywsZUpC_a!ABiWAM$5vLb<b`nM?-4GG+^pu*fk?
z;5*+Dp&#!WyRx3<50&|nL>K|%GeSD^$SxLg1`GoKK`T$H;Z3?`z0txOfdr5l81DZe
z7t9KOK@+OLf5Gx4+@XmUXB>c4b2Zb(5ZItuHU{ae*O13B=s?2){{vC@=%3EZjRAw<
zv#$<=e?{BR{U5dEU-aDujy$S-n&Hcy1l|*a$gq3BMz8*rHNw2Hbod9`k}?BBPWSzy
zZAT>>pT%BUv}c7Ou!`e!!%#zw;AmVRC+9^Qe%Z@4O1?h#z_66+h=&k<h%N+e*n<Io
z>L1&3s<cqIl+$GlnuVqK4vaNaX-GBWRKytYpZzB`d|Vt;ZWizwd|;=cAFy7-%!8E>
z!skCRi&Rh$J9_Y31b!o5s<!gRJjm`pJjdaTfw42QG|>wD=ZrhnXL2>X*Mf&yrR|le
zVY&v!W|oSAN*psWCjBo);zYgDz)Ow#NOhR9vXH`{$)ZtHFT*|<CoXG0*tO0W;66vR
zCRhB1+BfD1ABrZ_1Ow$CtZ8OZ;XFZH=(7hRqldrTwo$)Hx8#|5X2=K|5?cw=%uY2Z
z0hfK3+fx>NybaiN3oe$Mp%F1eRtGZ?VqqruuWVQ$JNyMRreYX$F8E&kx(Gh%Xls>n
zDk<j=Q^9vb>uA%s(-}5Km#{bSbeul^CrN1-f7qr%cVM2BF<5(`VL0GFv3=8aWWeWh
zZHrI5O@baDoQ_p}KI!o(axJe!@F5VO$6EK>q>t~Oril;d@=Dbvt`*?NMD-+@iXMf(
z>2HtV!#RKk4$l~qa;o?;AGYx29qe7;37!L!Pg;I)^J^pcP;tjj9p6fN81lUILl!<f
zzJ#OUe)G_Jh<39PeD!?I&*6oxLy9vupNrtbB~Kpupp7DBs`m0iD}v8Q_TQ?R#q3n^
zW&f&$ui|)kInBofgTdUN3c4VkO}#CO57&=k+d?hU7*{F?#ozb;QUo7fJ862T-=xf-
z;Cu0_Bls%NT?03;92UO!S@@{7iPyI2QQ&kHDE#gHcmyAAI-nyzX~$2g1wHU1X6}ef
zfnl8<JrYFh@pQ}C!yPRYBoABskd3Q|jKZz)d%0%l<ViX%Uh{H_Cw@+5ti(muJXtq_
zqgY1p!sWKa4`(@?!*RaAP&gaqyvWEU`8O(ApznALFKsiDubls08xJnX@Edq&oADrB
zDbjag;wuS^{6-;^q8YE~q?wRDlwk@0<txJ9XRI@&cvlwLL#^VgG?0_XFoO*lQ0n6p
zpMM>)&tv$nYOhvwHUB@^{FTwx2mVy;ftADJADHt;>oLR?2Ofw~aD2(ySH#7~%?d91
z(YG=1;JBQbMaRh5GFdmw6#q~QCMS^B=d85_-FM$8<UHLgz<h@SVR*(Go<TD}rh}Ei
zpQwSPmVlSf{Gcr_Tz-Y?y7aA6%nRrGA+pf;__vDgz-YqE77HcOeb%ZQHXOWbjCM<X
zvmT2@rSSxXRb=qOx@U%%4Q7aWVFOUQ7d#oOM-+IP`C`t+V-y6KKMMUL6p8{wLkvec
zxF|DZ_KE+~jCBpX2Z_Vla(f#~g$WK9XCVsamT`xY;@|SWVeu-wyc*%9g*%UnO|5^{
zBL}$<vZ3IRmr$DgYe8c0@_DNVp@BC<eO#QS?+ajFLThE|g<5AOSy23M>{84XGYMWK
zRu_KCmKW|z%V8hhn2MN}JBro8Jaoyz<>KtApGUY>g-s@uf5gRU=9HOa4p?N&5P!jc
zI<Ve+{^<z5B3dnQqnNRIl`6h$H-fL^=1aH|?6C6Om%lTDuYv<-E!?5QPL;kqx4t)m
z5AQtS;u>A7Paog2%MpCI>$2*W`4M_^a!<=%?(r;q=nHjmw6@?LmOO9%qX<4+Z-p%c
zeZ67&^4$BFg%3@dIYh?Xp{<LYe;mOFZz$lP++q3O-iIRis(6qPeOrf>$L|&+_^`J`
zxAPuWJlm~U_~;QgJenYfLJz@S-WkDH!)9fxipO?o7E2%B3&$e(>S*P|wRpzHE+b9L
z-}`4H`1~4*ku|fqAys_O|78mwHpl#2tz6Jo;H59m?2kt9Rk5OIR*bVvsjwH+3C?_n
zg|C4J%W~C1A$5e3Ph|gY1mFKp-P=dmnVj{37Z|XTHALa~Y=-Q_w25#gUa#rVXvTu|
zTKDU{-yiSjV<b-oZnwHyQroTWc6Vz=V<t|=%o;)Fu-Y&olg)$(b^rw?&?IIN#38~M
zq7W|#)**uU5S_&#6OPZGK4*RQ%-J=|{_6Ksz4cV}z1{DX`Yww8xa#-bx9a(R>Zzxy
zo~m?F)DAb~PDnpD-yOljg^sv>8kc%b#vWd6$MA4VZW}Sogy3EOp$MLVm7vb#gy7xy
z-WVR{yX{(eQtJ;_zAu7@ORun}%$CsHfBU=s-UuFIL6nNn<p=l00G&NdeWQkl%W4|+
z4)*ty)yAZKh4<E<jo@LjRjOl!WkULL>u&_`P~4@|?V-NBDoC-f^le{=;8puQ9HFs`
z_4}_c*RDtKT4}qJ_HA8({fBqp$0B(B2Bw(l#Kyl@*8_OSTjK%<B(5hFFWva=7#>Qn
zqHd#XR@i@j7H1=PxN@daEl(^@e)M<*50`pii$s57{QL(2yf$u>>f!uCWm5j-)ngI7
zK1w%N5?eH8|K(Ts!2n(#H7^<{eTrKsCo{fZE=BNg$P#zd*;3pSpzo(5c)e1;ihXO7
zqVLsz7{SBM?zQgz)8}$oOHb*1X}^f8I{W21F1O6YH!Szd+!51DTnk`+)2HryQqb&P
z@%z&s3igTii?s$W=f!3Q!eU029kJj0N}d6xqwl3Z(EP+DaIG3<fI1&oF_aQIQ)MU2
zBU6EVteQtAZOI3}oIrBVlRgLQN{|=s7a=*6Jhl7!+2!aYwgDsg+9*TJtexy>HNf0?
z+zY`zO&m9_*OBJ7bTKcw|GYdJ?1StVJGk7Uk4+ksAElNjha2ZrGxjt2?RfcO469Qq
zC+<vAZdegMl$q>YGQ4y#;KT0<Z2<TE;r4=-Oo<4Ksz4o~7=1r-#K2deBj+hH8i87F
zYWe)}!C-ByU&JMAxboblT=J}qaf2|Sc!eT7+T}$}+e;r0Y3rjRf5+V}ge^K<!+shu
z`;&}1m63~K9vi~+t0T;l^U>_{@p=B2+7UdMTcx9Bd*r9LFM4byCx|<H^xWom#EB@b
zdLDiu*aO|inneRi2z!GIU-sf+r-U)yLX6XoyN?7u1oeQrD6P@8S8PmR%y~S5S1IEj
zIHZleQ}%50o{Qgkb)`a3sN^Dl<zG8;{>5(&;9+k|+QxnG6N9(;QUtGq^`<J)5EG*B
z?vV%{Di5NzaZfGS>?=Q~e;|U_?^aQ_++LwaQ2Pq+>bEGHt3W+#P26T=4_XqESdTGl
z5x)702EkvwC!yuhIH^`N96Gxt<5S$4`_lJ?@Nn}8b^@0rgr>_SJlZXLywAbh+2M_E
zi{K)!+O?6GcOmreevlyzB$KG{JsJuBB60kIugKnl4BmfIas*#%4NTSLwrtBj+S6D7
z$sQgz^Z*^aH-93euU>97a4bzt)rm9tO32=qjwMG2@6LgcK3uTa#6q^Dl5#MV!=6_y
zs!XIy=k!=~ORoWgpSUZj-$CuD@!|)@M<kz&AV6Zmzh(i@(Rb^whx}}$B~uYur2?Ne
zhEOpd-i<~P-*NLRO@g8$VE^)IP2ZLOE`-;@Ave?lkkk%k6~!aOm_Mk2iLl6h+A1~F
z5AJJ<zH85i@Y*=Ogo@VQi{3YRB}1O)XFr68TR|En6qxk@y+V4M^6rFe^9-cUdP60R
zoG>^)bLCnDuUW0(q^t}Rk$#f1`{ZXH*0Cq_w1Z328)aMOJ+~Z58Hwk{3CfyCQ=%r=
zb$a?0J#PTKUaN}>{Oqk<?14^f=;jxroicCuu=$gH6Ego&Ks7uaI~jQG67G3#i=O6*
zofH`vP#<pWpzk5QSBmgjWrUz(o}Z#MP=)vxx#2D31<>d8=FJ}q^`_Tv<GyQK+LVgI
z=#^AZocp9Vjfl>ExrY-V_C`noB3w$;vx`3{`=<aXI7*#PPFQMqJ+J7T?}q*xnO2nj
zv-NIecri_AiewxidleaL@>1~n`mEl|1$p8^q;}%Yx%hMeL3&*zHKM9SfwCj<9zl}5
zLw_FmGa;R66R}jqo;!;CfcGbU;OFQ-NEANt@(d>QV4Ny^GSnZekD(xj4i_m$-w(SW
zbH^HooxT>nsOdwBzTEEid-mD|&mr=~gSt1Rh5BTEXIkIUQZXe*vC`sd29}KK5I8?b
z9VsRTWFK9*i1i8ccFlYcOa4sFH4feRxtFIkUrlXzTrPq8)i{3SkRu^`t0iPUQmhhG
z1@r~+2H-WZIF4J02#>A(VB{^63ak{-5T!CRY{JQ~s5SsPIiC4<p&Tpiq}0HjiG;_n
z#fNUho89b#9REWIx7sv2erl4x7^(79)sa~7S2`(CJI&WubzLIp4eC^3Rms*JAz^f9
z-o&UpUX6sCe8;O0*-nPYcS>(Q_m@JwK^12dj<vUf5>fBZsUz%x;vs!`j8fD0S}^{j
z6k|KZc~iTjL^8-!GKOkIO8JBG<Nh6*4c}ISmZI;=x}G}t*}%ys97U46DBF=1Z-RtJ
zMtdAYjrb06A}Ajro0*NX!wZoeHZVEGHU~LR%WgdbhxyZyc1Uda>%j2S*~O!;hVpCl
zYi$%ORQl;<MJ}?7`?rgSBR$0}A-ybq%+1$tHx3{dUk?QHa2$a`)v|ug-bzg+^phoy
zex%duZeBfgd|lG#uAw)r4l1uWf8*syP}GTluaf!;&l)!ktv&N`(tHr1uK9}-0jEDx
zkA(6>anwc&2MGK;fDOrEqT$DlhztIa8prpj3uYRZ>CeHpMesVfi57KjydS4{$Vm1`
zEA*y8HzuQzp@mSKcG;8G*@<fd*U@=E->U}xVzr`EZ=m*N#v96$Bzn*8{Ty-eUXa}P
zMofv2P6zMH!Tix2y~M&Ra>Im|+wVkvmBdp8#0`N!2k)T>ULVzXF-4YSZEkp8(L4{l
zJud>D)7MAz-fZv_B}<cX%N}K=yQHpB6^J&O<s>!U*?1#Iw^nlVN~k~mo=J1G#NTm*
zAb%)Ket02Kgr34trqnkY!IQ|2x1C^42U`2BwAD+*=du5xUfT4d#*jUnl#=Buy^ux|
zBjaLFi9I|4<g!mcc|?2$g=#_>5JQSm-ZMOPvb-M5%~1m!rE6*(d%V;;adzfSfP>Q5
z0yS_QUrz=x9qM{Fy4?mUH+f&+JxQLJjx>@X{7V`GpriAxAV-F}-z97>DO+DhW%2OD
za~Tl^jyAXAYC2yJ=2*C@EU8v;TtZ?3ve7H4hf5kHyrMBuUzvX3+kBA<Poz<TB;)Jl
z=d}I+9`?nf6p`pFt)OBEqdZC73G>Ka`FK2gq>6c_@Yk;Sbw$(n#b9hsins|KSL?Qg
zKI$vYz^e{HQL*@!5Xoo%4*5cx5hN6SNB>?(pD~W4u4_|z=CD^!DQWSeG=KHO46z}z
zu{!1Xc{8y8q}b?S4;u<vP*2&0vWlZL!zX3`WCRKFhD7=C!_2Lmo=$Cr^fkKGCW<2Z
zp+h8Y`e#?{SvdKG`4TIYW%+;4+9QU{OmAKca*$X$YPYdN$=2q)Z@sA*l*|y4!Mhsd
z0#K7aX?9TOhjfxA(n(qJgO6l2k;$71$oP6Pvi}xR<ekKxm82?A!O2sy)4S|@@^em}
z*S}iN=|CqII<n)#9vU&Al~V<Y%RRw${`K|9zqWA}0Q<4L9?`N$B)LlCBNj?+y~cV^
z#kYxHAkWYKPDm$4kt9vKYI{^A(^<CWBVm!<lsTu3^fCO-3!aQJsliO1Tl#!pB`J0*
zxC^vXmK-*%irgF)3)~l9ABp^V7k7E~I(5lq6Pgz)Sw+GWPsjA<hk~3^f}C=zope-r
z!-%aB_eOHrdv}U4v&%EVoEh+N$^t9MV=9hUDU$E?h<};gHcn3u1-aG)v1Akbc6%a6
z>SG>7r8}U`5HkPbUK=Wb&RtD!hW@qRLR}P)NW&-@6(vx9up5d~^xgdG{g9{;MNX<{
zL6okBcRPs96P#njF$=7IjAw{6Khi=_M8}(mnS3~Yz7gpQ4jm=ElHMk~yTVlIsm;eQ
z(-9UMJ9IJmmx>`j(+)~SyO^AKl7W6~=U<!^kQDxvS!CS+mM69)w`t9q#`$1f07toS
zZa1r)$>D*XgY76t-`B9=-{a=_YL@3Ro<17L5b#h38aG0WX%n;r66A3r3xr-kbTXWO
zQ~OfX(Z_N?qiO3mkv_Jgt`T{vhu3`a)boMh_?|DR802+c{hA0~yM@~TY>di&XoG}8
z&hpU<Hxplu$iwi}jg2RNMC%UdL>00+CdxhtpvqH$BCkr|<HB|PoetLLas6|n*6-JC
zo|W`QYU1@LQY^l_r~XubA>=R0Q+B#IY)m@6dn1Y7@vv{|Fg1to9WnOte)GX!JyW=W
z(b4yne;UDSw<@T$sm5Z`=RuJ^suT6o`)qM%89b^OU*SFy2XEu&LwE_2NZoo(=5qH#
zA2B30fju4we0aTxO@8%yzba#J$zaQdo<8!4L{e6yfV7AP?d8MY`k7Eqam6C8!)?nT
z>{Z1>Apox`lohebr!Sul=2UfDmx2;SsH)@bg7JjcJGy00Zak;*HtSu6StxVzyQb?J
zR&ece(!iG9p3LEhvZsYmyghj8J$(eiW<I<N^yP>?I|Fz)R?=$JtUvW`l0f<41;%cD
z@J}I9!^nKkk)S5o>W_!=Ly7}O@AbC7hzw6(L^#3kN#E<A3+(|n6r=i@y>D04*(fQc
zMo&(7d?WxFWz8$2vpL3(I{Ce#@8kqO(|QLR<Lo*|$Mi!eWL6YO@R9Hm^B!NJ(<R}l
z`Hr0BoZtEFR|3C{5^uP6qSNfict{GomPB$PJl^M<(|H>@9o*OdK=T!F6BLOl*&~*b
z)1r_haxg^j*KwBVG~A8%g>b8=kkqSaf9jQ%9Q5+^Wn1on-ZR0tj3YxRf>KS(D)^_~
zQvdIFa5nTheR?DqKbpl_z1i>e?OoQCZ$vL0D2<P3kbK%crBC&u1~M?AWP%)0HOP4Y
z9xipnjxu$WF0xN{yStGpS779CLh_8hF9dU(CURB{ta^;QkA-ZP`9)?X9w(DTc6$58
zuhRYp@NhR&sos(C*y}C-@-EXyabz#SIVFl$I}8HUynxOZgSl$6*r?PR^?ps_D{uMa
zChgt336*;!Cp~Unw+Ya!N4mMdLw^+733gkc`jEZ&h_NBrHEd!bgb@^dhdg_Bas-es
zWpC%lY@N%O^|_adxvIC1;nLnQL|tW5cIwrXI!L{AJNx+?nU8Oz^!gKqt9YvOe?HZW
z8WlciVIK<iv6`ClD434gX?~o}<kgqHbWToK9Qr~56@Vn?vwpg+AA^YF`=k0Eb?~5#
zv8Io^)QJbxDEc@y?MY&f(T9NZjokYH>U_lYU{2I5c1l=rYFVF1Zc|~sMtRu^m;G`q
zg<)lD@M0T&`CKuB_vp`sy47j-ak!(b_JGny5HbZz-4S17I`wAeWl#0+cEFgy*=#jf
zlSOTIlyR%o?7B~mG48PE@SZ7IBTL8Etxtt?_N#pq3e)-fd!$ow#=vuQZhm9vo3Qt+
zQA0+Ax+5;dP(q+2o6@6A@nhUE)zNt%$g87<e5sW-QCZ*H4gq;LPN8}t#Cj-X`Y$RC
zHI_~IgUM_;c!j^H=|tH<>{#x1?VdjGU`Zk$NnPX`*(+ZmHvG$D7{r`!1?v<jcY#e=
z<}?QBqqAjjLV^f|eG_Oj*bxff8wSt$fbAe3YRYRQrFzpY91zq<-|GR87M~<=UPp@W
z$<tx*)cL<V!M=Lbi*NQZirTw*onwvvCncnl2$6Ogr*p^Iy%)5g*co#eF`FHfY+nj|
z1Mui|N@dhNC9l03A}FsxB%7Qec)oYUz<j^?;IDKQ;=%wfvzgmLjtzC}Yi)A}s^~6B
zV?%1AXD$WI&iI#*>&BRjEE3IcX?$jBFVo>8!G2%Bt@o2w%gzhgAKTEQ5d+GT6f2(_
z34qAR&jgD^oAV7z>)IE!QR}Z-Nh)@HBVjo#h0JCDq@6;@6e}a!keQ8VQ^CH?cCp({
zYL$j9CFZ;-;giK)h9r%BQn!d5Kgb+{K4lmzN<f&7)~`e|?O`lKH5G}`hWSDEasM*C
z9IVr{i~Y2Rb#Qy9BX!a{B0?i&6fyrIWkL^Chr=p4LUPG-bNQ$9gN<L*GDVr1TC3DU
zshaz?70Q{onyt+lyf=dJrCUrIT~s}{XEJ>odPIJ(3o@J%=69Y*Qc9xyxXoOqqi_2!
zX+IBmDD8~80FrB?y7<n>Pw&6IZSuPa5sxcv@)I@&y#CW6KkKce*N0j9am*?Eu$cYW
zQ3~y_`JCpT^2HPU`%t4B{BOUt_Xrg;dwJ+ThB&lL0bh4sxoNsMVLr%Dg5qDP`L1t1
zPG`UN%wNu9lONuX$Qfy8FV6-!oG$J#Fne+I8Il~nfqbSE9FvAFUK@RK<J_4bciSyu
z!+O13vvWmi2RrqH80n`z(J^p~2tj&1aKQCV;wItfbgKGVs8gM~xfrRRd!Jn0aFyT)
zxMLovUDPRIv!T(!yYcIxJQ1m2YLS0`wO3WrO+k<=-fb|S>SXzHu%3dNuAQV(>)LyJ
z=}YKphPhKJR>bj)omPAGq^D`<bh143!x3Mxp{s*EU9=r49+^fWh&tJ)#wvI2Ss;$a
z6hIwsH~ui>E%NZqGIp^NChekP#6#yva3q3w&=pn9uVe=w>7mI4zAP@p(CFYDsfIN6
z>q)nUJIo1>n!q-mMuMky5DI@_-$aS(n;0DUgCJtyx%u#||1G2s5m^@{ZDmgCESq!^
z1}(-bh-bQcmA?tg<4}xhZSovWo^QXcVWS2`2`d4ms?0;3tjICaLIfyRK9Ub)s)&;W
z`Y$O0`NcS3r@M##C(U2LOv~84R+htayZZyWJt9H)930qUlmZ(*JGrL8xP}@SwO+g5
zvNbTg0g@hm5D;l1_X&tJQMmk$Xz)8SDag5g_G?2rky}aIJ8pp>y9k|q`K~EJcFkAV
zzaumDxrWTb$L;ubCfMtV`V{RNRt9VtOHY^|SzWKghP!E_xbB5vgPU|{5ODIn5%?y+
z@1;rFDoJeb8AeKniQ7RNwo5vGU&B44?-)XejahhF?bwYMqdkow(91WcV>ED`UVZ+S
zvY{%@fR`~VZrimj_RNowg7&IM8Pi{|1x=euIH&1+NRQ)yhlSr-8?|lepPUoG|8z?n
zK}U`S!fHx_aQGo#lG8ywi#snVeFj`?Q*5UVdnS|!)ANuVkGi)SzCv>%82<`eFe?$P
zaUan8lK`*N>2!NtdsdR%q)^$Jw;ja*l@s){8R8=(vN<h`IasH^x8D}h*~4Z9)LW6Y
zya;Qe!S5m&lc!WB;zzQbVteZ~V$JlZ`bY#9)s=9EmB96OLjovK!u1X#hl*2=oZem!
z;NgrGPWIrwVHtM_g@Peu(n(PKj_f4GdjK^AI(VPfYhD;)Dk*9?^=uBGBa?To9b=W`
z9N~F3^Oc_YmEY0(@VlD%jxmxO+ftol06bJ*X`$YW%nzfCjfdj-DVkz$_oQih+Fg3p
z05wc?Fu(L)X&F|E*lSj*r8a+m-!k+HWccb}-uWu+f3V-ZZi;FrDwjfSp`@rXR7=uA
z5t2@l?Gg0M9S(C!pGU7^4|)X)UG_#LWq}pLpQibs0dQ^9%aV9-7!n|qBXQt|7<Mt!
zpP7d>Z?PY|QE%3pc3h+Dp^!)uAH8Rwnh>xTFEQeG{EN+kHLlO;wM)=gZ&lhjSE$aQ
zkUZkbZW(A2D3#HJFBuMy_55Hnk%X4xv%jh3h<&HMdasOx5&imc(*@;7YzdG2^A;dX
zOw5Zh6U}!JOPT*a382m<J3kciwB2ZzaME93dagw<sWJQ@|MqYMhDHZ(Bk(!c1KL9o
zKwLgV8rdWDlK8W463XxL`W&7Gak0?$KM3i=*`<0F7X}dCVY1^1Va~8<!=phhCBL~m
zoEe1#)WPZxeUPJfM(6*aLunQJLU2E@fk|~IXBkm@(<C2AZk#eF25jPO2iZT*--mQP
zA#4Y$B#8dpUP<;#hI-Z#2?~%*<_~<&|3G+NnS+>MTIVqU4<$z{t+LHcv0L`&X(OrZ
zkpRe7F+IZ)nk_#(4ndAS)oWOQhkMS-rL;WezCJ=FMO5*KtHz(ZSm29#UJrOUDbZ~v
zJM-l<>82rpwC&;OJV1IZnl;JHeEQTOt+#dT=`GjGwh}MfkfS7la$}F8Ets|S4I=!W
z(q=@-R^&O?FUfPNYG#{P^jR&?+UwTK?X;`b^u0jYIn9F*_ygtUU9i_SzQ<pKJw>;E
zQu{mHF<<K8nr6EPjXm;X7^tXk;y`AIbv|zBm&=53GQ`>9(r-lYaF(&rZmT_ZyVFN9
z$UzcGco7Q%+rO*lBREQkbH)8`YVRuXoskx*0A=d=xkqSaXyn4W)76tdsC5Q=7I5iV
z7pvQJHu0d$v5H#bH!Kkoen;A<$>QmV3e`xSO?o=x>+Mnq7xUaouhGcOSGol9)zkh_
zLminS{=>j?@lN3@p&Xm7O48_8#0T(o%14<5t(??}i7@!%??U6ZXZGTS$|*rc<I>#-
zW(NaTlIFGziq<<<PpFT|7<)JxPwM?A(4B6nkyJbOFbFMzo$)V@6p=UOcYK8u(%}&Y
zzUPK7F3DvyzE|&I2FxBVqiSQJjQZnEgWZsM_vp)=zJ5;EBn3R=;2}plc91WgVFB8H
z{zN<H08TQ!6%k3Q0a+c`<*Gj41Gs6c-mO$SDy|!*kyIb)%s?eV#E;5F_9%lj`s)17
zm+RU-+QnwMR_nWZnv@{5j{We%TOYe6C^|M06iHPCqv5?C=qkz{V|zdyg(<uoy)cJ4
zS9)p+m`=(Q?un!ycQMw5AO^siW3AJ!rI@fAK9Lso$Pac#g2+m*h?Hb@6x=*b^D7GX
z*p6itL$9-y3xBL_6Y$d%7ZlokE#%hz`-4aIniZxX*eu#F)!X8OXl*3Y^Uix4Vnpis
zT_kL;4_vcyG=4Fnu~%*MO1M*&Jl<y-oqeA9*-&p&v!M{{D1_<9FOot+NsnK~$%Nb8
zDcqPvTAtGd4HxU3*q_j7<G`5dW}j(wHu{A-T8D54B)o0C*OfUm^}b@D`{BN69!d4n
z8Cu>mlDvlb!TX8ejOrb|4-Ii0Hg6-Yl<nImOgrysyynm?30L_g!OJt<A5}@&6$+g>
z{dqZvC%Z+YCDKyY#v(KiBF`SEf&>r-lzhYMCqXiJAb-SjX*o82GL&Nj$EZqeYnLt_
z@p?pRyay*8-sA8G??=d1wq?pNqjTn4LzqomK!S_Z)wzxPrBenPL#NZ7*Mm3@>#8U{
zRCamF`=^hJrr~`)4Qa$eBWkO3WS<f_#t&Kw#pSh@KX?xKIEaGhujDK=$NSf*|2MP^
zROG{nID0;ApY74<>rK5!6!y_>;P?ja`kRCgaQ^O7*F(N`x}83Xxe}yPSNu;$K=bz&
zKrWE4v>Teg7^WXg`7^o8429?KdjsE&wcK8%Uai`ay!*^wr?X%9y-=nmoQ0+2juA)<
zaiiHr#wr?Sbjb1cy?+$K>z1nRdbK0tmt$_nsJi2D**uK2`r%%XXasTe>j7`E=9l6E
zkHqf#nh<Xv*0spsVjCsg+Ed<fEefFzvrn%wG~A&K*1TOhp!F6t%{#pW+!b4Kymf5N
zt+)hBZT4Y4Q%#w#eYO+AO-s0U9*cc67%F-^i!&mnlNr{zh|~@_4EyMmIBaHXn{WPI
z1v4oXap778>rezqUOsMM9Ht_%54VPGd$-wqra-7%?)xnLC&7wsTOqsN@5j-b|BupR
zz{izZwMIJ;1SX_U)6J0PHtIc=JNBAK5-p4}MEk`<B0~>FZ{&vrK1Sbhe&lTR<~ucw
z7396sUaMMB<BNA?1V9C$?Mc$oF}_DJ1VMe=QtR>cuBMYUywX~^IXr(sFMQkpIO&Bg
ze#bl$C2B7jBvST4Logpax)H+d;tsz`qp4y)&ph@Pji*%ukRsrCN|ty!86h#5;P`v%
z?V7)+qth)lk?EJ<Z?wI7NfSOlND+S^`-M#U58^{IGkZPoCmJqtwOFTaB{+O$@Mlk)
zWJ*s=i7=+4t?rUHA-!xwgOalzZXCZ8!$dJpRG^c&_PyJSZ^_t|Dd}uKO{({zBBsVR
ztX3UMsic#Z9~nLMm9%mOPicDrl0MhMo-7Fx{sy|E_sqw%E+OYvLS_LqS_zw+B&R4m
z%8iupJMS2s4)A@>r#ePNRA*u%xhbblclDYIToEczmizS)c5}+~#7@{dMMfU-L$t=c
zLX@Z!bQM;!jJalU@AZh*4h~5tc1p3Iq&nUn)p<YA*-cTz9Em^j)@uaWB>I|5e<QmR
z-a43@uY~gKm&}SvB4gYzBFRSYh53q;r#D&8d+M3w{+&EGKOMm=m#|0Q-U;ve!v7T`
zCkjxM!aVvkQREt8Q4$x1N}2B7{$=eSkdMQqHaImcet+0{`EImQlZYHOiLc6IphI_l
zOT)yz@p3h-;+8ealtZz1;)1fFlI$Y{`Z_`o4drB<O+1TD)Z%!1M(;gC8RKpxsg+Z^
zaP8&89_hKMR}@m_0vMShuIL$5<XhS<Kd4RYh(dLGbVHwi2VB%>siEX=d>)-h->+YA
zFsFl93H#K|W((o$FfSMoL<W!yGJqT<7f2-CB$b@+!DJlF1AkNNZo7yJ(8>r#B^Di~
zL;K+W-h3+5p|n@8RZ&2VIuzTBY~QBA*qz)@7%{3b(>&5~c+^D56b`~sN9&ZHhhrNx
zYK&mkX7`cvWpc-N<5k(K3V-!4yKvQ;bvT~h4SXQ-R4BcJGeZ-}1G>55fycB=kvl>@
zu2e-`Qo|`496b>~j+^gJnvY|L%_nWh+k_{JtRX|lYvXktU$5%?ANblSH*0lN|0Fzb
z9Q^Bk*FGG~JNgVCV0JOC;Ob$aahTrj=KJ`YM^6bm@O?)=9`Y3>csfb7E4FgNaL@a2
zIy-8u8jdUGooJ<pVA)QTwp7f<>xQmV2^w)1X$u9_ght9EGI)MR-ITRd`Q*0*!=Lz<
z;zlv^wKsIVIKb<dY7KMi2<1o@LUo|&@q=g+huwTFxxkimNc`X=(fRmd02lj<>q$~e
z>^kV~aJ{Jf_(gam+F|AQ$x@z9hteR{MXsUQ=(Z|$|0!wPzxdkGdhn$7eYj%}_dnv&
zWtqFgzOQNYh2%s-8|_dj7N0%c#9hvkI9g|PPB6jMlPI^G)a>SF`ZTHpI~pSvqwu|g
zNqpkY?OfLT1ppJ<`6}(SDfU9SdS|LEARDQJ0dCsx!U=TPzGla~!-0(7{OihQasLqt
z$)R?ZO+Zk4NHR&F3ek7)2Qeg@fFN@_1_#e;!Pz3F{Na?&IRIugZB|p12Xf;Z-2gvG
zKfC4!5m1`TpJ}iBAUt9vsNq;Z=7XnyMd=k_Hv0XNDQr)e<N8ByOGJj6K?9b!H#-M$
zDdcSvMS}Vrdp$Y{I&K)o=IrRCd1M&E??RdPDd5pE$Go@T>Ak6IX@Xvq@<z%IPRsN%
zOs?eRy~)*$tA#IwJjRys1Y3=T$5ac-g+Qp@baiAV<tIC)4T9uG#0WNf&d}(5#lzDf
zf4eO}#DRRLM@`ceb<#~PPGp_aFukhoxe}#$d-d;VxVW<*X`wWl&Ha)@;!hAHjMBWf
zIh5n=w$1_6OkMw0KW%hmtfTC_3nW?OEr0N=rb2o4tAN+=g@Kvl?Nz;B1Mr$<B=LLJ
z50fZwe8XZEj(?=v`6NHc7+~_P2tf1pww|8?ZX1<@&Ehv@y3f3IzJEKCXS<66g0)oU
z;S+-SY9!Ad?%8uUaWjCV)V!>GWWn$FNYp4(HPk`XMdhC`Y(A@bI~~#4t6}M&Y4?uq
zGo4P4wm+(U0&4n}YOSQLQm-RT-5V#VBb|&lGKGpfq9HYl4YzgfwU%JLt&4->`b;eS
z4q43)KGG?Z!JfB7kl%R=6YpUFIy$!kUj%r)v{LCuXWpC}su<A_AUom*CF+NQSgibo
zO-w}zPv^~dXkUc7kSHoqZPZnLCITY}Qc|T_m=F5A<K`~{^AP;YHcVFM>$Y^9RI3*o
zje63?>22C4T>|@|@WzOfJiF;zxK$(@yYJ{d-GB-6L{`P-m;I6qxkDNWokUTf{4Ud)
zuAx|-s91bi((B-?ljoI3wBFW>*v18zCGiO^lydUy`7Y^pJ!tkz_-ZA=>zg281nS^!
z>bh5;wGU5}w7UYAhD~`=A4y5mz*Y#j33nDH(hu-`vX(L;MobJkA9&ysT92B@rDO3F
z?tyY0H$I{?ndj{r?5NrV*)^nQa=rC`YaXNK79h5J6?I;RjmRWDVWXhEsZfCYj?yN9
z6oX@h(I!XdtKS{ciNfZ%?$>Tq8P^ByL1!k@Kz~uE2=kf#C|x46NC>qkcm9)H;5LU$
zmk$1A&0o};sbEF3Y419Vb(qS;PDm9$q)#J46(4y&;ok}Ky>A}WJO<nz?)JuQazR|?
zZ0Dru-bWB(n0%&4`JoE@Fs|@CGF#g-*>37w5|$`xNY=G$_KvQ5_f0e#;z7q4=F`vU
zJSbq|UeId8oyQnvH{SmIIOAmD^@*15*)K5Nyz!vkO9Gg<!LEi3miS;YNI4rALEo@A
z^as=Yimm~`>+*uGGUib7tPb;bZ@m!8xR=&VNn**{kq+7}ITrbyvFUd6sp<bYgo(8a
zRElb-d=I50!;Yhy&`xJc=GmVO2;w}0i52aSgOH2Aul$!9Hu7mLvr^uc`4k<xmloBP
z)=ToeF^g9^Y>**O_%r!Ljvd3)+`-${dv}oP!EH?SM#ttwCjjr-f3NB5W1X*?c2Ts1
zHah`$1--`uYJ=KT)ii0#cryWb)87)(huRq>>@kyh#RTBpIv&D9l$2tYDCe{$0I#6W
z5`v%D4~ZR-wkF90;5GhyL|?asbzyt|@&w>b{cAmzVGj~+C$2Q@I?M#%9n^d3!B6aE
zZDZfl#Psuut|?>Sp-6wJ)1Mf;qk(_vW1ih?w0gCDw|5tJZR$NKps#}~NGe@>r_``<
zl3~V(oC)1LM<zN?4wn3m;XuKSlNWRy5(6`>VBd9Jc<KhYiHw)UEC$<({7$c1LUAo!
zV~`^fhXWr4G352*B&qZx7l)Re!<Pw#vRLTGl(J7OKUc8Xy;hRYn!}Lr%M3;AnBPgq
z-!9RBgbmTVevl*IB%kfZtTQ^_37FL+?Y7f>cX`<udHJP~#wuzWV3sd&&;)!!L7%+^
zeT{Nb!>tIi7iI$Rj=n3TuU#pj0-dcdu#fQEJSF|dF}yZr42k4ZsghI>AKiIv@XE>W
zs9cPDoSMc*oQ$$My*Y3#f}5rl)I#2O-{*W$`cKqY0y%c7398A6o;tUH|0~80n&yL)
z`0NjDf^^E%lwmae71_Y3j(=ezm80?D=Rz9c|N8BIe`4{+WqsEaXzZF}#i*e@sd#Q$
z$BzbH+Q-VMt@W{wy6X6OJ+h5{3!6`HG2(vH=WOFlMe7Xi)rJ@E)ouJguBWDhrPg>`
z@)pF&o}+X7w?nuUY)G!RJNxcb9lV0hzhhftwOVT9ESTh<CLu??f62hBHS1+u<h|c=
zbo6cOGdu=fr;2R~_DuK$=v)1IZTHxFT<%s8MovtAH(rh4wX03ssV#ON4dzriKk!qF
z$pXLjz_^5w7QLFhqJ4MaZJ~a4%=XZ--Gea+e(F6+kYA^YLy9H47h(eNuISohfS0y#
z>r%t!&?W$H`<+^TNfDc&uySG7EhYgkkRSGLr??rQZO=qb0Nw?C&J;s@tx`!+9Os>s
zy<gGw9Syu*uT=+ACk5}?w}$eo_i<vcjbcs4=TCs25C4S-UfM?u^XA0(dFxOJuZa-2
z((cN{VgmF{wL^F~h}}-wc8y>H@UH1IK+u<N7nK|ndj@C%@NT?Y(}(pt1Tm#vW8dQ#
zH~t;fH45ser_*WS!ZUlGbQ1LGJ$itbR8jK2S(Q1OPZ4t{Vo0shp^r08;wQi5V8n=t
zf2j<CkF&4*RLIX-6YI@gdq2+v=-UeBOy-^}oMZ1!ZhUBbZ%7}?eKt^fA>P+RF8QII
z?B!&ILwmIGgQGg<^L&qqey1;~KGzNTwXyD6txZlpum5OBU#C>5RhrnqG$H?)2JsTs
zmMaxpR@s`^Jn80-g!JLaI&Q`*?fYEU$?whI(eWA9laT^TvCO*P{B&zHcXZ7a4725O
zDQWK9zR79zy`~gg5n%jpLeXrFed8}{-eL_qMJ3U0X=3@H13w<Z!}gMDQkvYF!lpj|
z0N&P2nbe*=M>7H6cI%h4?ihH@M#Cla=rouQ@=MfoA54}|v^l05LH(?wZwvW}1bDTS
zcK3aa&E<g({Hu^Y9LVqD+IX3pMLB6w6%RYcC(+ZotkF=4109{Z64Kc0qDD~D-pe-u
z86JH-gx5B=lJwGv#cOYUZ3wSl!cG!wSl@4d<NVuJkjrbs=G(YR!mjyGfS<SZx)4gX
z<6fj@r(2%beByxK#|C(q?3PQY*++ifbNobY_Td4xjW~YZ`Dtwv*jv!UqGieMwW7`Q
zgO=czulXG<!K1{#m<X0#dyo5Q4$Cyo24`+*c&HnLYmITGjEql_4c?pi8L&*LWi(#Z
zb>&cw6g5e!sPnk*YhRA1w}bq4A2~JL`h+uGld_33x|S{IOUgBPQCkaRA8o?rMz05R
zG}I|?w@?_+?&tUF;ui(HlJGk!BI8en^j?{qTh;%=n`V6d8Kpbe27)`=J0)zSC12T#
z2Yx@g>fl}Zvmrd3b1$Jl#J=b7oo#ID^(N5Qsx|v4@h{^O19@iV$T@y+IQEG;+6y_%
z_h|HFy<3!VmyIZ%Hhw*%vDNKVO1)&?{kNm>%r~p?0yHAoTyLSm5oLJF*zQU5QKR$V
z%H&c0`Goo8gpqECw8{BLMInD8?L1HA<Tw-QO}E`{Hp)BdJMNp0OZ7g-26E25dZ&WR
z3Q40ZA&GN5Y=~kIHEsTqL#_OhicEJ%c~Zu*D~>;t8)o}ZW*Y}}EDV^~Jk)EKTl*gO
zJ0EcM^IC5JuUD-gv#w%qBJM-}Ob2_EXR!T>)b`Ey{EHfpn8!2b<D?0woGfqueXTz@
zFHpka(Q<oY`IBpJgz$PDB-q=N%ja+ET8j<jgOhF}?KdVCzpXx{<%oPKw!L8eN90Ip
z@MCw|pp<Ex6gpe*FWMqEi#qvTIUK@k;*Rld(o*}^_ZQyXf|g%W?3?HfYon7Ii;G*D
zKHL*usp4`NyWco3KWXmtYvkf?@l^4)hKD&Dcf8nrOHn*Ur@3cP#W9(0$*xkmCRY4%
zwtq+O1;f$7ehroEv4-z?O0>tY{fe>k<1}{jK|b*@4Q&5&A+1<W#}PX$KASdV7a2!~
zx*xg4;(rR^rKa?`yW@5r<0_X+nF@Rj<{DV5EOo_&Qy^X{WSBQGKh(<@;=HT<--^(%
z387WC``7T+jmuYmQ`3sQ)U8&pR4PkeEYc&QK{Xk%UyHv{7DSPo$%*2u0h#TUI;wNw
z*jCdhRZ8V{TL@M$Ac<wrNXXO<ikm{FAQ%aG&q2RK1o&a=)j1z@^l|MI0JqZXCVhLh
zZXf09;9YxP$Xi^ITE{$De0pA=FpiJyhVZ($p#W(|n#n$b%f{rir1^=xy*PYTuk8Qc
zLdVY=>mj^$0~b72tgh~({G7i#7{nar+;$grNbFs8v7S;Vy{DxC@R7kOf8}3PV5+S*
z-bhay`m8p}@1?DN4F#<wHm4wI8B}q0S2Y&Si2_aTxOpT98YEHiFZ;7zj<0Y2uS#!l
z^&d*6CGGv+0-O1q>z@hXVQsitu6HE%h<uLc=x&aO{(=6Vf5`?*`W#1Ns_(Y}jW~vh
zC61Epc_VYkFh7%^-ywI&@jTNo1JJ>n`DY=Gbqto3t{p4cBjIs~CuPK*)Y9S!o|5yl
z@jEtS2h6EDT`fEv!b5r!`7yhnhdiYUvTssF9<d*<x%}1Rm4)to89`j(AVa5v`{=tu
zxV=t-lz?6LWA}u{0fTgU{O=2H;SV%i+~b2<E7f`;@+2Dxh?Elz3XmX)5CxqP*b50X
zPi#axJ8tN8<K_1EC?ACMV<oM(n<cwfGtylGq73PrhymfUZ^6KpRdB<z*F;3m4(6LW
zmkgK*wiGs-HJMlDQA|S*@!<GK?hv<(ei1N^e`fl7@SlhL?RA<p6jN051Ft9dqrZ;E
z^tUuT)cC8Fak{D``GJV9-XciFPHuWy`2x95c89e<rUE~NH9<`A65Kk&0W*S0rV;SH
z`5{N=O&zym`$o5i={geG!(i?gosa4oL4b)n6>-xAF7+{baZhympo|QrDqs^V{yG15
zLGL$eVvVlZ>{ePkf)Vet{Q%|V$<FDNXt)$Be<f!w7=VtiSM`}Oz(by=(Lq5r(#S6C
zxOdnPO|aAEulvcp%;>YUD8<%E%3bWf9mZBtLj3o11=KVeD!B|V?`T|oP5Yj1v4MNT
zt5ur=p?(t#Ihjvi;da`F3&PKgGi$|6jt}d(7fLfWyZu@%?d<!$BR8IG>vOw+hYKmO
zvC7uxp`K+<t7q_)r--SZ+mUvA)iU9m(I2O;GrAs83;X}N6&yV3%iNYG?_D#wMU5oW
zy>61}gu(ClsK!(S&(ZmoKC^=3*9n4W>|qh*iDS#Ap_IMtu{oXDVZ!#Yf&`Ztoi~-A
z1>7EPrtG!s#a={xfBkwv%d>@jNGXnU;l30aNu;yn>u&Cq?~guj?&j04>h*eTF|Hz+
zUaMH0b-blqJOWOu;`0j`=aog8?}(<Dn-QzG(Z8u|6tI&LA_R9HFw(~RrPuj|GnYe{
zbyUN_F<n_Z^dwS&$AEdt(8=ah2{;A(b3C5;dm&8RHQnk~`ZA8~!Q){SVyN9Yd0fzE
zE|KcSwPtM;j#cMZ_RrTl9^cS4?*J3liUnE}^D<1jcexJbv4c6KYksugd&{`^KCyQk
zjti46l7gg2`N3gOVj|}sin_i&V0J5A+<|QC#(EdXmNGsW25@AfYVil!#YnfveP>RO
zZs~ms1|DXfrHb9x>hy@l77^?Wc06UG4m%%w=4Z4HW1gLqa8l9ELmh1Izr7`S?>>^;
zo#^?qg4gwa6l_6*tu|ZblG^`5etO6|J2Om|Z+$#O>5%pOj;PUSGkwx$`H^nJEu<yX
zZ4@2$)Q#&WItCffl5h=vRo8&WF&gYT2h_UEBgB82=0ui#@H---OM&oPDj0vFw@|Lk
z$4F=XhLUL;Yw&ekK;~+VL@J~@FgTEF0@=>W_%OPTwX>P@n?jhKR-<1->W#j^+YEd2
zF3w9T&lJumu9M^S-%w+C2YZ(rX}wjqXX?kLk*Y?lh|s9H(yRL1IgXpB6;v@y?YS>f
z#^(8SM>KaRXEdERe@)ZbF1Gqj+$wF))<<;48Zlg;e2coK+#!8}<L$Md*Dz5Vx7)9y
z2In4gCGQ4yD$(9B-?|yXtd&ry8>gd&jV<};Bo=hf$}<Oa76RU)jzAqrxL!xrQ}>y-
z&Q1=jYC3VYKdDq3*swx6Y5Y_qB2Sl3<oTU<4g8Bgc*c@aX=aFY@HYQt2(RC2R%&)A
z+fNd|qwo!X9$*V^tSCPK)hQt<RY_zDLA2@7rEG~j7YkWio!ds+a=n4m0Wuw+2cn5e
zTRvk+#kF0H;FeKD1SQ|dR;Kv~Ou@xIFxU3;-x=auf$}BxiVkv~yp^^mj8S3M<k}Wj
z!?x9=jibv1%T}DMNK<)+a9rCj#BJ-1M%iAWO2HENaC&deMR0q~H0g=E^%0J=tr(m;
z9_L4+wz$=ygWDv{TSJ@n70$1n4dFJb9Yle$gw4i8T;M)qdMtUkH@+@xi*kI`#IEsC
zp0eo5oiD_>r`ksHZMMxVr2?0tRlJgC-}beo5N@m7#m(FjDs$XXIJ2$NjjPW_ZF|@N
zA?nPblU`5AO$@mw6t9*(8n$hlyF%=-U7|~dNn@F{dYoVRuCQ$f=Z;!7MaFk&{?e8k
zh9D%TSJxvMbrIwsbvabPRfDu@JFm}h8rR>zCbO=%{#d>Y+(EE|d+j43&R8o-+V=Pv
z`NYvqa3<f8y>e}<5zf6b3IyA-;W6B%!8!45FJBDd0%Kf$EJH`!mWxAYecM-NqqhA7
zJ9&olii^kCk>hYa8u^WW1%Rz@^>bsPw`_1e?%ST63E}pun7vuJR7a(gy+}p})}ppG
z9E?dtpQ%@@6DV-WcjV6;&Q~HkLiGXc&=C33{FIF3*|$9y`i%<8TXx%h;Z-c(4@EM1
zBx+l(HJUA3vL}`iZNKc{o(cUVRy(m^Z7)M$3?sY4=r`oqw>>!scvV5k43rR);g-!5
zpQ%^M=bQ}f7bP{T{i?MEvPq3c^6cS$F_cjy>2xc-vaCZhO5}&gC~jMv4{=6K*mh#K
z36odK*QJqOeJ+CAz&VD#J>o-<ir#n(ZAA2T>K$CLAyXsbsC<q*dwLt8K36&&>}`})
zenM13C`|$8o9X23a9pT#dZ_G~%2Y5O7fu>_PkXr6L;qaqq)ESQeGWqn<)G>7+P>|l
zB3|JrRL!1FAgjo05s@1fGMwKY(c5dI=!{M25w2=XeQtQTp9{yMO25=ftNI=^C0`CQ
zxUt*WZ#9gOP_v|)ppF22I~P*b7#hp>kw~x7b~`EC@(QtDoiKcU+Qa=q=%1^ldZkpg
z*A&IJ-#2Z$zU@n)USUP6-L|LdNU36#JS*LJBOFt3Mg~iqHq8~oCEpdVz7Vx#^#gk+
zWZag%;CYYp=R&=zR(q{l-A=oFhFO$@<FASduY_X?w!ov}n?3eTT9pk_H&l#tC)5qp
zS8UY!JuxKe0#}g*ZakJ9jbwzaA?03G;^&y&u91;~``+ci=TxzcrQK^uARFrjpK-3i
z>Et7!f39{LND88UfB`|iD!;*JWMo|1>4;vGR%;{HVcQsID#r`H?aYA?=PoKdw;PgH
zp?_irG~FF~btSZ;YOmU9H7%cGpTjX_#l!t_#AjSJjC%}a{Ed0_v|)mZRi;C~QSJ3g
zy|N7`saHf?<m()z<JE;oMk#VgxJ!CyTt^jK^f+G$<H@Qi57x0qhbR;BO5ifiQ8-V9
zaZXa|m2mwh!4eE(IceH6<RYBR<oi(QbCPPk*-Pya^H{!5MLPNAkXH$uv$@)tfMXdo
zOk3sKUkddqsl#tnY<(``OF;?Jd{%n(j*!nuv(#|AkYn-EBu#?R$>_5opHXtWl_WY=
zp(YAk+Te%0jNT0WRnjWq7Td;fTi|$l*0=p)7y~CT1)O}7wlUJeci;8{aa-(PK~~i3
zl^VS1bCmsVgmE1zKh`mql<|mgm9OL2t>WiS=r@v1rCq7mtNv(nG+p5pyHURVYG{K9
zuj;iv?s7M35bG7;s<>`5k}o!zBGaVkRWf26zu<XwE%fbR6effMHa1_nb`1NOZWP1V
zJLxy7Eu6+8&T(VXuYBxR!dL|=)oPXO)^UcR%5M<ok9eFrA>0~jWuhjt#O;))lCS8B
zZ~JV>t6I6*NKrP$>xSYLalY)^z7&q3xDlj@nW!*}Hb>wh-?9;0-M4)))QuV@bZu-M
zC0xQ$^t#~8+2BK=4c6+o(;GQ{&u8W9ng*_#m%SR%Tklq}-ZY$E@>%(fm%_OQW;nP&
zO_w24w$L?jl}_G{aBd)e?%M0t>7V%_ylR`a&v;%v6xu=!MRZV^K@vK#UUf{{Q@-sR
z5!@y&<!RVdFZs+!Soteuzc)gERcrOy*a#*vifxd3g=ID;qr2glQft?034$!IR|;-o
za8~2dg}7}KoACAgSMlnEX{*MC&qg?R>d4pG>r7&tsaGHMIKL6vey!82wrV!si097K
zXBA()8Of+$?R1;^`c|bIErYX)pU*`0+fR`tv`e5gAvF(;ZQ&7prUpk&(*(Qb>@pjh
zk<Zi;5%N(_?<*nPdZ~hRkX>RSy$Y^8`?g!59o0+ya?=ij;$jSq0+GGIj56K06Z$%2
z<-1MXTSwg>y2|$D*~5J`9FOX_@w3shM^Fe@@%b5pgPKd;4drWY9>XRA85iO?9qmZP
z{Anm(q=8VV%f>1(!JM-z-8c}AzjfT4gna};ZwyzSJ-uHHeJoN1m4-!`A|Y(yGhH3h
zz!{&9hA}V(P+WK>!vfRR)Fo-lXQV~5wyP1ZQ1Tu%b%)1hv_a+D-#8Y;?ezvG?DeY5
zH5gD4bJ1iYqFDv^^O0U*hZ~Nhsdz)_r10JI>UN~hsE-S$BLowg@;UPC+ir$Fr;aiP
z*mWjj8HYfX=qJ6(U%e9goI0-g>6gmFtJvr8S;ZS~hW;6Cd%bc^=2nEuMH~?l#{~s<
zK9Uh8IGwWHei*~0KC4*trMHJNf^54DyDhY2gu=m(hDcT+#hB^F(MU#MbBY4p-nSER
z!8w-Eok*WM%{1+ngx+{8s~J4h*nK^+qiz+kXkX3Cl<gCJm49x;ZPR|QrG_Kbl&mua
z^W9i>GxArxQev)-_Wp|cEc8;v6x`d9ZuF{fleQ#XETaz_deuC1JHi<`D8$dh=j@EP
zRNF@)y-F+PHj3d9XQHd}43xJTkLJVJte)c3WXs-j#F#<FlVZi*jvfu$Hp;l~8k->q
zm&3M#%V!lcycEs{8yJnsb(^q@ZIHU5{PUM1xK%6=AZt#z)CGmJJbRpPguKEHDs_y&
zf-~VNC)+bJ!UWjq#-}2j&4jRJ*A~euWebcMR7{wLcGSSoU9a1+^I|s!nCKN{1_$ln
z&O~r)D2Uy*a7mx?b*bq_#dU{5ztL!+)@-dS^u{*GNsb!J3Q=1`?X8B+$0}Y?uN2%5
zL^yX4d?T2pjAH-nCRdK$7bCd+X1kB14%^0KD1DuZfnSW|+i#b!%Ysd5f}~m4%#Z=(
zW_(V=c%zZFar&!1+;LF8DsG<%^P*_mZo8PDYC-4%IJToV!kl>{HML7@DOvgn)t2!j
zPLn!boeAk}VpS41A4}X$wNTE^5$xK&9O`7V+^v-Qc6~qAN$Q!(6}&y1A2q9}Kh`LV
zZzo)(lgEutDjB^Q+HbR(H2QW(As9ujV^v0P8jjsfB;Bx4Q}l`>n2H%<xP=IA(lKSw
zmA_KFa)2GL-iqL265F&(G4wWyT&g5YA;bAgp*~|>5!<PTFKN={K&`U2ok+fQT;_mj
z9Tl2BN6nAAhR<q#v=ojh%{p$uMU`8&rF<2=jMdJ1y?RGPZv(ClW%LXLwo)#ZIO|xn
z5$5Yq2)2PagV+&eOF@Y(aEMSb((92<LOJ>!yM-~<Nf{?R&hrtknym_)ozNSvr^L4K
zS{SP|TP@s8WOakQQNEr2O4<HbB6{0ZRNA#ymd5^yeW{q?au}N-{!Mx=j-@<3!(7u$
zHx7M65Z5(3jXq*C$|x~{BAfZaq&=+H>(#YzzJP53X(zFhjgOheah#*pQ@$9{+r?hJ
zjve<&uQFghtNc|p(yMM-!xUH)%cCl~aopgc#@`FqLV9^2h0RfLnVd2bT20dpWk**-
ze}z&lE$p$8IF^i6u}a-EE_=Nyg!HybrWm2k)qC*>&a_EPa-84zQmD^JAUD!(Q|1dC
zi|A;itvvg-Tj6-rN@~~`S(g|%hRgYan*Yv(w%<w`-6jgnkG6e<^R3WdVa)Hex+B)w
zs)kp}7TzB53e>h+c5NcYnUcaWE61xN;rc=gcUhMkcFilceL5W#6TTVF2V1zlw^z1n
znskv$Cz)qaKIfsRZ5!F#j?F*EF%n~M)%Meoe3AQVR_uakj5DW|s_o|^KDTjJuVQsF
zwn6#=Wee3vH&8$d1B2u@Vm_ZRGE(!w&xY|v3;8GP8<F_}d8O9)s8?!U_Id=j*T>}^
zHdcx0r4y=n`CbX<M{Q(sG2Iv2C(bH3BmGJz-yZU+U9OdrhRvB1t{TfqhF%qK+zoL?
zIiXUgV#m-J=Ti}{4u)e&8+AFGWm^&;POLm_+Nzj;KGZ9;tzaQXVimeq0vFq-8&G?D
z-iqkOmLl94H+<gB@kq(&kq9pKBVZMG_`KT<D$WMq2xBD7BdhJMUDqIsX#j#VpVd6{
zdKmM!QC1Xpm8-o>ieBnu;&tOj1h-bHb-H%HDB-ApBeuat=-W|Qpn;T~ibWONW+bDV
zp}%U^OVyHFdm?X?-w<8#IDaV|%aAZ{mvGjDK9=aJJQ9OKwFl!s=r`K+6gR`#{FT5l
zhzg&HhvM_02<H}x046=rtJwBABq}@F4)YtRn2+sDcI;;8Oa~xv`K;Q0AmVek-Njwr
zLNDWA#jBXlhoZKaAN8=5Lte!}f86#+q#I@ct=KsZ`K*F(dG<2;Y}~ewBc`Y=Xt*2e
zl|1{luZ3f1J4Ffi)b638jMzZg!pD5u&xLI}rFN}{TTF+Jzp<~o9?A&EelhY(To<#M
zZbRpCzY@Vs5~PA{E_bM2DWCIZC?mv!$Q0T<AxWh&3BAu429`X%uZ8p9POaOo_OVgf
zyvAk}jI`ym+Rtz;^syZzMoOt&1EQZKmC`oWjn%j<ZY%8B&1&SUnh(Y}Z-w^TX*5$5
z(Ux(LAQ`+WxK&T@vr*e-C&Bu$^6d;}rESA7LHXy~p-y&M?KJ6jL^sIiSg(}r7a~5l
zIvt#7Q+A|mfqoKEzw_-I5zZ|vmiO#h3}vGBnsN-qq|UXihW@J4M#8;nagOzh@fCt^
z*Y>4ICvgJ0ibbHIwm`nC80q0~Ou=@ddbfjfP==+k4aRZ%m%?!$oI<YN`nuRpmQ9BZ
zkMqq4=T0BnY;2w(hD#O0DL_Z>RKzPBUPYx{W&6sGsA5XKZ$)i!FI*3mh)FNQBNdy;
zvxnOVV}?!-i$J(P%iACk7oDsbdR6@VaAf=aW+m;~{q58vrIWD@ekGhcci>@r*ce2(
zl&7MXZPh;W)o>o#Nt@WY*_E-I_N(Th90yfi^gyW3U2I}Zktp<Vl`Rmi%1;(UztJuA
zYp7-~d?uTe-$)Fv6wa@NICsl6WG8KYGRB#ttGxH8LSErGYN=YUh>WNUN=BSpsTgS^
z)D0|&^s#+om;DTC?0!e6&t062YL{&+8pEZlR{r_bh|e_`5^8ag&t$Rkbtet4l&|}A
z+!hLHQ^@473O7!frWjH(JGv9$T<hTskv*bJHYuGX-&KxcJK}Q#M%c4^5vfv2zVy#(
zzHlv!pAl`C9Xg_uY^!nw^do8xI}_Sbw~5UG)wZllGB=>c!Pt%thVx&PZz(r12PU6M
zud*ZhtG>7Wmm@x7J+q0;5MD;gjwmDL>n?<T5@luUxaocPT$1@`1^3fY+fEycBGzxj
zGUD2Vg8OL1=WZDlt?e2ReVfuNdG_=^9QrzpW4M{n#*;CxlE{9)9L__bk*2n#$TuDr
zC@!@xXfuq>x;RUYy<5_j;!!a_pVe6Qa@-ahK0CMv-Jr*J)%q{(Lbd&T#OD;H{@P`+
z{TSzx=}`HN8^?mY8BPx;t$r$FD19o8hg{?11!aS8595s<1{Bm&6un~Hu6(RKdl@|%
z>NCc%de@cKjb%g|RCDJmVT^>f7*#A>+L5va8J|4d%Ms31l-KOoef1&}!yp+4=|a@_
z``*xwdPy_sV#6tAMEaEdQlC|fv=Pb|mC{=sx86;-N;jy_%Ex{o9FKbSR;%N#`=Tx=
zpVKzzt34Q<e-z3Wi+mlF+$7FCMM^s&$EhmwO1_svf7L_29o4@io+Qp}p<-Yqqm!Y3
zMq5)6QhXhuDgR6vsrk_tLfh{(6BKQ+>)r917oS(Xe5WF~tuk&fv2&cEW7#F&_OlUO
zl(1{1s84KI%2-9|voi)4*KLRM?q08oqI5d%O`?TYWSfeC4@PkNjZzi!Si+5c9pS36
z`_`YRbH6AdRBCo{HI3*bSxlTsIkgj0x@-)+73wnvU+j%f#eOLhg)_$#l_z{LjC1-G
z_`1H0H{v*l!;8xEKOFL^pP*_C#&6O~-YDPBX@{cs^$2III%9v1#C06DRa@GiTJw4~
z+`EP2Qn+-&?%j&{%$%yqPhJjV1}q&nkXRXt@(H6aI#zi$^v`{qc<f@$n~lk08k6V-
zaaR8M0}-#fHJtyo=Llk6QPe61{&Hx){cZ<43tAGJ(N9vT1#ZtEt#b9B3hk)ht7Gi$
zsTf$<FX1YEz8UeVUuh?pPI`KkpX9tu#e^?Myuu<~9V=!-8Qn2Bm%aUN#%+7hE88~a
zbIG(-a9;_>6jWVqn9|FH8;>b`R^$F^*fuSdvBY3=*L+v;N}fH=Uk+^_smT<DSH%|S
z+xa0f;-AV-9*Nu5km~D+kB#-2ELXnnt&msP=h8!!JhA<lSJX*m`%9r-rMQ{~XiLmM
z`jidEaqQi2o|2Y({a)Xe=OfNkYN40vsd5xoLtDU{yWXwX^GEboOfE=UdG>rh6y^$0
z$+CsA+QaGX8r?YK+rAdj+o)rK!Omd`Qt5MI+N$~Bg=4|^n>G=uq*kwJ_KfRDDIbw4
z$o%tk1Q)j&BE=|cB802vDKVd~hW4Ab+PKrwmN21wl}>UDRr8b=BfaA3vWCQy^yNyv
z<g@b6g^15x6dG#Ua%8c;BF;~FK3@%EvlM5;`#}y$*#eoR#*|x;Ug4}(zom2LYV0Qc
zDt>-5!Wri~v63VD9OF#+s`%<!Wcz8gT<Phndlg*T2K=O}zq0)atsA(r9d(g<J)M+c
zV{)70{;E+f273(MWZ2kIzo&2BqH3@?HuT}2s}nNa&@fROxRc^&x7~o@!I5lgCBG9$
zkDHFAQW3u;PW*|=q)_xUZoU}8!v+`B2Cm8=6cr{>9T-Ss)9Cnm{om`DC@I#ly&E}H
z8N8^#)Bw`xV?w3W#}3IYGQ@xyP77yxjYv`v2Zpf@=1fJ?SudifLA%tkK}|$w%&p<X
z5+o(A1ZqHLbrp+$E`-^^L3?cM7DKI?UP&hjpgxFye1c*;RH>Q&3B@T=nZG>gKk50&
z7)*mQxCah~aQpo#4hdUlIsv$j$J4*6<=QObfPcHvwKdA`iN}-#^?<fXb{P-sX?^s!
zLztLb<8BR`uw^4^g;%3J>z7fQ)U1<+(R3(h%wNbrdVQLDr{*#0_oMg<0zVnBB5foA
z{Eh_30O)i$dY3j$vN_rsv1W2z-BK`NE<I#iOO2{H!U@!fb8=n%1;t~WDa2g`xG)8g
zo#D!a<a+HnO)Kiz_RTRayWyU!VH7Z~a4QDo<CLcPpfQvUj~%U-e^JxgEhg9*ZMNM`
zf>sA}>*qq44diHXW?X{Xedg~6ZGEVzg5oc(qpMUp<)klhJbe*;4)vA(g=5R%Vxer?
zKdNH^v_}yjoE?#Q9_NJYgfmUicXow?l=$cR*nB3$0ig)CWQ%)@=cp7M6HN%-@ULd^
z*j`b*!?h2Xdton~;NeVy=0tpGZ2Z7)yvWtzawnvxf(29@otGhrte`JpBqsC-e~63Y
z>GiOWDryCH?NLeJ1)YI(LA+q$4u?0R_8n76&(>w~9k7*jKs!Jp3jbUm4~KmuB@{bq
z?IstFK6Eo#AF0kAn5+D-=!dPzG=W$y9Bw&gi(htl6!iQBee_Ks1AR`1{3KOE3r9OF
zYAIT7=sa=1h$B@Aq69gQ<@upx(la*Q5BfM7@}rKL*h#x9eGJu8j_3$J@z2Ti_Rj`7
zR!2s%VYlIT3`FWCM~sqr<abCdX8e4wj`dOA4%?m)N=goh0~4LTN-&Z)&k+a5&(G=H
zh$&Zxv^VZlrA$08lyaRgs31{+e~yl~>sYvt60YS|!`^DofQimj#qcr~dHw9@oG{u~
zS`F0xmmGMk7v5euY-TuI{x1TXZ(>ylCz)j^A<DE<>Nr_LiZGXVe0VhEL$li}C)k=5
z@j>Z?;)CnsNT{2wE)M9Ix@sMO{8x51L^n4>Jdi-aZVfxf9x9I^x_Lv-AN#n5u+i#N
zZ61|<a4MnVUebbzzLM#yI&Y0W`ew7YVn^JC^y~R~J;K3EfO{3utD#EKG<t<ZGX6P!
z-qG{3ezAiyrkFy=kU7-G7*ip6r}{V<+B&wZmiwiy=*7@J82XBSJ3MZMw4hiMt~0Rf
zN<;0eYiPm7F8p&gawXKyF7ylMi)9?(>ok(l`gtStH@zxucInw^#!$WBm*Q_69W$Z-
z#a8LGj{7k8@V}V2;-Bl|PRI+CIH<I%yUB!ei_mwz71DzFdaE9+m(fm0z>e|A@pGdX
z*n5hKG&Njp;q8^9F_}sSNP9=#z_q{r_NaXWJ4i}mtMs<?7e3oUY`_ZF{&pzOv}(K-
z7GR9zY1T9^db*+h=2pl9RBULMag4*`PaY_LL)DP+)WvsK{}(-e;GUK;)T-H@NPOpD
z&fExL;y&II&QS~FM#hxnK63{<C-)?bFOX!$b28>Tm}kC0%c_oh3(^#u-^39dQ`1&5
zo-!Bb_Jom!j5g-4bLPYUOmH4EiFX{#8^5pVL>=iGqS%&&Id(3A%IFaxjpPKf_I{3V
z>zg&5ILwc&!KJ<}65;ikp%L-sckE2;WQ@6=qx0e4Rdl8m)Ivvw)b8OTs|bTCOoWG#
z9s=iUF~Nq+EEjd>8x@^6Uy@XMrH%`VsU;L2NhH(wo%n;tjSPq8qR19TS&}I$X7Hw3
z8XoSEtk*iIZzei>&+w?X3aE#-eNOY#+;iSau!&GDzLH05OG+cl;G-W{C<eCRUvx}#
z$}YEe?U^0$I;9RSh%vlk!~KP~eO|-Ez>H`O<A_YKCIIi+Ukl-3Ll;cZ7WCOic<;m9
z@2jDwQ$PE4n8hADHmIMSogXY*o?BSmSX@~yu5Zj2i>FH1M}DSR1kcBP|2?+<)h*Zm
z=)T8!_uaPN&42$j7VnK0Ru=|~%jZ@CeDl8dEp`sP`ezD-uQ7Z$K7Fk8bhS5oaiO;|
zzfdd|j}{Dm#-=~N^PLkLvm2Mzvo{L`1J}G;2;Mckon2a5nG?RMJ|EffUc@K7>u|gh
zygPSccFhBJa6b^dv$HSv-i_eB)sSGI?_hp8d~bG9!F2Cj3*QM4bMKr9-cd4Bym;|n
zSl@O0F$9a#C0w?GJGV1Q95rk;dT9QC<K~EWwM5Y3uzmmKU*7rt5RE4c$D><A@bSbQ
z&2T9W={w>)`*nIWGX!@n0rRrM;jLlsW>WCF`Ho@lX=Kr-gMVZQT}mRv^_`Y)8`-;u
z15r5qu4QoL_lW%&9h(`C4i9C!gZF6<FTmdE(NW*e4i>w2PI{bTwiX<mFR6DFJG0*p
zsNXdruKjyGo&oFJ@AKL3j}PVB)vSN{eH7nTGkPE2m2Yo&cpBZzjvw{?jO1I@<1~_Q
zUr_H1<J(&vk5!F`<I5xd_keFsc4_we5yiJB%SB}qFJ?H%JDPXqO{eG2W;7oe!aM2H
z!F|=k^=Qj0nGV0h_ZRUn>}%TNr}@a29K2iVos5qbo_ptu9w)`i5Y_?zj^d}hV|<?(
z<I{INRNxptXb+Z(#SfK^l}?@5SX*2^-&x#PSewOnID5rmp6ev0&A~S~ZkI1DF3neF
zH|8$%&whAeZlgFD)YjmU8?(#vOABj{7mFuKXVTIsoH%o#!|{c=l{Ewph#b=Lslocd
zzIzhmv;kzkVvn<Dmlotp1Q;K;xNiT{P`HhSrPYPCVbB}<0bS<&r2Cu6tIEpq`o`L&
zxs4S7Z7j^Lc4wDo&jW+vQ>Elg`Xowro45#nfci7VXH1Bc#Yme|?4!D{OBZL*;GCuT
zn$S$fo?3o>ae4maN^)^^;{~JG3&V&OmLFd@zX%YsCSa3DAme%M((+uBF%d93YvD}&
zBzYUa*$)s6!1yi;<M#Kx&FETvVWV<sZEazBV<Z3(TwWSlj)p&G+=u=<D|53@pyELO
zIJG)&m}TSxjTj8();0zRxbVtgb!BlGdcIyP8m`N_hmrM7;XC^3&R*UPPpilQQ_=p1
z9ZtoswKN}}T|U3iKX-ENh4qswl?w}V9~mY+nBTEOtFZdw)3iUMWN1<bx*zGzuI_B|
z^kau%X$;AcYtyejRs<V&pl1Yve@|Qd3g1teoLCqwjFAdObM=I?=MOts3;&D_ca4kK
ziTH^U^3wTyfV_9|!rIF7nc{+mvW0c<w`fzRPQbY=6i+QzjhC4<oP!72>Ca9dIl1zY
zg=L5wtZ;m|R-&BXeU_H!fynX0#v>Xg8ZS0P9U~6lO<ZwL{<=BQwRaYb{Mm1J;o{ka
zHN!AtmDA|Ee&(stnQ7C)y<hwp+ToD*AIsi14V?d89r?b&UHYH4GIz2$SoXA@NKUTJ
zF0U^MyFLV&jBwb)8BjWNScIe0;4wpwlTE?$wRP#@D%5^ud1G<;61@`98_ipEQiFVr
zuFiZt=U;<9r=RO5AX)g^;<3jtB@;UyK>rt42CEpiHqH%J<h^3?+lxmA?NZjyg}nW&
z&&@9H>?YHdqNPdvaSyJ1VV;f?Dg~C0QkJ2NHN5(urSq!AZ*Y2X`S{8HrH%eMsLaaR
z3)%Q-wDasNJV){I^hw-Lf9A|HrGoe2cWBFl!K`s`=N6Wq8?0YgJhw5JJ!^)7xsAd4
z`odriGFV%&WButP`t9t!?48p`pms)~oe!V+ojfqsIrRlMV16S&xK}I$Hx3p5?Oy#~
zKKlOqq~Y$r$pgb7I6e)lJLPa`d7mWV__VoG4ntv#PleZ~t(~&i0pnh!;pmvkL5G2H
zFLW5YGGqDF-x7ak?P7H>w=}!HzIg71SV8SC#bT-4gVtw0`Q@nn;`(5D;XJ(9a|kLv
zR2rbXh<V@nyv=VFA1?6DFKi4hZJaxbC-lE^aTV>(E-o!@ynv_qg;nFq&`DF`57$TG
zuQ8Uf*15j0ga8{UxJ3pou>U|SO>i(+L|iR>xOnL1Khk<GE|Qrh1Vdox+QRHb>F8+*
ziR2CULx|7TPwwpN+}eWf=giP<z!&4kjU3XCXg&(GwS{%?=j^3(=S%?oq0-1s(BA1x
z;V&NGm^zqy?8&u_m5XP|Uql$j?Oim!4$~L%G%ZyJCrrrK#kZh(1EMWiH0NgLE-cIs
zRyXDc7gpBs3;mpfarM8k^v*qgcyAb|#)6UY;}@)q4c<mGE<rA93m?6-xCX@Fv6t7+
zt*l+N+`$`{mVqWzrTG+2w>?vEa$dcUeg>yWcHy{{(ZTmgyh2`{n_Y*}EgLm;fwCx!
zjiJ@=^MmC}OG~R8YXhKo=+H^itBX;J?^1m-+%^ge5}|?fgU1<UHE=VGZUf`9G6rwf
zR*di*3WMinmoACTG}-1!i~BXr2hTpG4~B71l?JC}KI_`u&eLvi`YD{DCbQh!Z07&4
zI&$$WR0N8$iyjV6nQ8P`YLe;u=C^4$&(G}!=Jc3g94&V}jCBz6{M`EPP)cLM$#mfx
ztz6fQ(l0JAZY<6&Eq-iapfVKj0(3sEO&YYhw7gp@cOLDGi>0!Dp+zejgJmY}ABO__
zALP4IHs>z>iRCxAK-=Gq7u6K3fJTiWS{H}kevgb3^9#-^W2H*G7$*8qC+ilg*4*@$
zU>&Bd%d<;^`4^UFFD}l(nAR6RM#pEITp}ziJY#L+X7fH^Ew2pi-O*8eG+*C?)Avq@
z8;hqNmodbQ8p{jM4=zZu$+#sXTu^Z58JX-j-C6xc%5rvoelRz?w)TP@CEyb_RxZ<-
zqSOPH2u+M@bjOTSTfWW3OG_Jzt4kQFcWG=||GI5E{X5j}+4&D&g73UwMr;Um<<bV6
zJLV@Va|`S1n3z_dK6Xe3+JXITc7Aph5-nCU49$#2ek>O8x)};)H;nUJL^cBx$idm!
z^@Xu}D#G3B;od>O4)(^tL@|ZJZ&+Fme)CruA3OnCR#(<x_$x+zS7%Mm5R^}hoWf@;
zJ$GN3lxz@OEYHub%}<U7r(ZXJ<g3S!3EaUx=~wQa#?Y^8|9l+%%8dbRWl#Oe-B}KD
zGW{x|c0zu8$&CVC#Ss0<-9a82oXt;tIhTzLPLFh8h$x5om(d<<{JwG!^xM|vQ`||P
zLnh<nu&b7h-(3!p3cqG)y882zlTql&CPRnQwe3&m@?{Q*A^LvLx|YAM9D;GWR``!&
z=~{jqa_L(B?sAZn>Duk@pBzoYb!~s?_yKD(tN)j^ndfGg=P=t?LG*YT5g8Ieh|l&M
zFOVw9H;@kXea%ub=t(}s;ZyiKmaq4Q&k!aJ4;=I2GxM%{!^aut5C)Af&fPI`{5goV
zYx?am`Qz{z!k~M?=Mz?crZ4ZNKcOa%8{F^CkwU@YaJ9D^Pln<!gbnwmCm9ZZKR+Lw
zEcQz`91gc})_t^YgnV!~3}M7Q>4VFcOv&7RzbEckp*C~aLcz`356Zm#9^gci_N-^W
zx8Uku;k<qKzVBhu?m&Ia+Rl{Z!!tNLQyjZxGq6tl6t`5A$~JQw<Utn9W{AQ3!r4pb
z?M_e5VO?%ws~*xg1a`ovdx2K7bl(1H!a9qs7t2Mvvt{U-Js5<Iq}lrZV}~Vi@A8o|
ze~vkevq<)vl}O}Xp2H3Wv)RMs%v9<^(iYSeOxp{$CFeCK>jWmDyo8B0*GZ2Z|G?7h
z#k2FXgC`e`oSpvmxg$rX4<9~z`0*#EpE&y1^pVHrpE&pA+3C3>b05SuiE;vjuy)$>
zIkD}(O4{aTS7+z2bg^HFDu9xO54R3~w{fp<0x^;Z)3dYJ8PWCK@xK>cw*<Jgrp+q-
zBbFAhN_*^(EHV@uR(3nq96<j7r<b0|_Ev3GeEY%r3(IrZ^ssF5qvw}a&LUj`?}kh`
zwgD|%9@Qt3f6dHR*5_7Mk!d%JP+0UrHh*nxWzA&s%vuQG9=EzX^KHzl5%2qe%OJ<C
z6;F?%1>3a-8yA@UM=EP}7eY){RhH4PPUF_MdTvZkL|2wpU>q)UiuCYDFD=--AQmHR
z%JCdnc5V?Hey}dExPgUw*{wx<U4J*9<$BCqp8hUeT$#T#yt{(4<GY6xeqy{k&^UqB
zL#*S|XO%5oH=j{>NV^!EG&|L3_D-BE^(x6=VAro4Ez_?^A1fCx%9^3s?1V%yyvV}k
zRg*N8{ZIBk^9ypE5Wn!{DU;GRNICntI;uZug&pihoG%P6ajVt*m{1A@hj;Ns(L=LN
zy0$RDV%Y4GiO{X@TfE4HF(bi4)6<D;@HsgcTs-{5lZ(aT$-_nNrt$r4j?-U#@BY&7
z&W|59srwEeJA70l=;*yVR(}e?s6VGWh4b7CWt=~(0z09WkY6>a)^J}`1sgNuB!gM(
zei}Jp$lBp_(DTf!NS=KG9~WoWjXzUjz(DX3XHAfWp|s&8q5GTiH0JKF1bwz03Z>}K
z`Pgf36Cb&<d~WglC1}a)+WF_;M7X51j70s)^ZW`6hD(ccSmj4Y#?T#)(r@DU%JtO2
zI#di>5wQw2xUhKs!r)^IYby)u)+Oy6YaNenT0al12Y1e2Lh?6{yXU|!Z_B9f{O`?{
z(6qL)8l#}s0kAZNHSMQHZelcS&-Us}zeN8tZ#EvTtz25?C?Ep}m^5n!@p+h+9aCh0
z$%ZO<?;^LhUIc^a7g93P#dX^<W{lTAx5dJ{Oi!CtmyFMbi#vdY@6uPFwLUWaCfebc
zuyJ7DYA}b<odB_J_DtdXEsU+Ny(buU#Ic^01Ds!S8BS*;PiaGXf543i_eQV9h09p9
z<FU|*n*k%o|1F6J*`0F>Ixa7czi5f57`hD@E*9LBSa3`jaUAG+^<&wT#Db&yy_Y!9
zfEk>o%-&;VcK1E>#q(#ei}-|WO5wQ$2B$)57AwriULCa*>=f0QzbqB1kfq>ka7N}<
zJKAYk>^{3PTTrubF=#eoYE^J^tJ^ZS+8uTv4jc#=6PnZigEHS%^Su4ix^j}2dL!IV
zSlJe2UVcyb1T3L4jDta;;CQlW_1MpShw|iJw0SJ1ID6f?$(VC~VFQ6=7A&}c90w(^
z*$NBX)+c2f7`Tnh4b^s-F>WC91FL_F<8{t{S1+B#s6QCltM7N}wLJJHdGIyEMuu<k
zS7hASoe%Xq{nmBA*FKY{-&US}Tc%&<%MbpOJbW;N@tJ4xbS`fi2tJRs_2ao<lyYf@
z^_|WRwhl9P+Cx7$m6QaEcc}vz4|7rF25G%b(zX{`-MshqPvxUEGt6C0AsbdQyH7uq
zM-On0M23*Hh1C`0jV`RLd_=ZCRdE_xe%clAt{oVP|F-poGv9fC_#hE`p9q;AL<Y+i
zr|q}r!bv9=a`8krFc3d(;ceZ?3D0QY(%fKU5fkqG%4cy48*2F1KAA`7TsJcJA0NDK
zC;a}TrGN8##)t3EUgcyxc{lvrmW$b^zDMRfyZhdZ56>gGk}YKSAdHnAt%WBpM%en^
zF?bTk+GDUJZfdY_{MdRU&)8{!4e@MapfRMi@Wa{U=I`g^$8$!|O!(yl?;9A1E@!p+
zxm-56gwrn1<@7-IU7^dxJ-5F#&-imD4=voanXUc&N*;dY8%6BYB-@LB`v<v(Hov%T
zj@lN-NMOju()Ypc&G^3c7kD<y_ETG$J-;4inx=683;)W_PfG4(e(||QRM2p99Jd)0
zr?pC_&MumjoQ(x@r1mjnr%oNVXOLW8b?Y}}UbRx1GutUotS-zgo?A4BIHR+F%=#3v
zIaZprGvzjz73&~3a><;)7}oNz#d&IHyDqj7FAZzt=6<WUEsn|D`lVqnf+vQD+;5t_
zyR@{py1qDy4u{Y7Z`i)wQNrU38<*B_pm7Kh4#rj2rhB5j@WS&rg+28345xz*Cpole
z&T$TH;QBAR_f1WX{_@fb!;k^ZPKMXA_g9+pNH0}Tv82L9lOaT)-McNXZa!vdPt8$$
zDFGt;oy~~|sbgVydehOHZmd0dWH>U8pLZQD$IYqiMV`(yN;RyNqj%Hk#K{Yb>m#}2
zWqjAakM!i|2Co0q;bdOjg`e*I8AtCaEDfy<Jqb%|s98R4i~TPw-<$bo_Pi}?o(s$K
z<F9yr2XKL?3ZD`maxS^NikaKu#z`a|a3FOdMe6!uq;=C~Q4;@L+n=*-kz#SpN^9pY
znT%xz2jD{y+Qz?Ud2sdL&~KYH8QBfQoF^u({~2u8E|sx_eENuBe7IOWeZ-ujd8Y9D
zmbO*Y&&D2!$<Vfs+oeYAMju69;kPY)McK<e8T!E032f&cNt4sZDcRedpQa(3T88iL
z8NK<|?p4a&)2O|Jqlk0*SdhKmlc8--eViD1nLb|o@R;_N8zsnYs6OWIU|f+E{&#C*
zoBwBC|LAsE<=^QwS|i8rD<^@2)6Pj^{BSgG;XaUjesX-ga&6nq&$6+}{2eRDZPZ7d
zAdR7Rj?bpC>2k75W&d~%pW=`jVlyLl0q(7z`TH81K&78Ee>kpw=Ep0Se&+9PY%-mG
zPRkziNy%}zeom0CXPn(N#qL(tu;Y9llhljmyqhUFludlcUfX}p_I+3OR^d<}`u_i6
zpP0*S&y0e5pL@D~6m*%m{?<dRak}%c;}X)>msSTGX1+35$LtLC3x=}saj3QZeSp1B
zi>T9p4RE@7@f1`7`we(RoaYd64geLGTsA@r<<K;WlOqjL25x2!YH++RbB^<7svAu(
za4Nc-og=;a$IL%r?_IVSX1C)3J~q#o)i9H}#wNfl$=|c`Jt%wIbX&KOW;SmDd6zOb
zW)tshGaX8v#_8fU+1r+*zj&*e#V_1z#st`Li|h6w>iMv~b1(WCjLo8->vQU5<}LH|
zIby-j^;pRIye;c}yY;!}VxQ^NEcQL^<n$BF(e2hJ2-_?5XL=R-oxG;s$kFfKsXyu1
zCjVScxbVyly>z<e<hASCPabM^?Ew7y0mr}Zx({6PEF2jQj7BC~IQp=~=i1lrjgMXf
z%Eb%a0JMM1!kYQrJg~-JFe1s~%yujoIoPSJP3)$(mb73WQ%-W#LX9jkfoi{ZV)~^$
zbvuNef1yZ|K6Ihzla}|lWt}J&{X3R<#^S<`*5rj-H=MbWmlyFW&lpI=O@V>a_i3q>
zy$2us`btiyz5!r4pT7C-J;#YX7fFnO&B*5b?@d`F*$w}EUefwVmmgjIEYGG&zjI~-
zmI)Y5&KY&ouzh`f<q{$<RjommFtCS>TUWAmmhE54)sLEmWE~NsC#}8~pJv`0_>|`7
zv3-BNe=ZC?^p0Ne=R2G~`{k_N$h2tGG;4eHU&L*P<gKH|4sLqdx5ZXdS*h6-V^x3S
zWYE@DmkrhhBB)YB&*c3N-U!+nghxZoc0T)ciRu5*wJ)Q(#{BN>!RNB&^TF$?-Qrvo
z#~OBTI|TO4-*$ae8fmgKx|9u)h!dp5Nw$`9`(I}5aK@_1vmv{2>w^~O!YjHR^c&?F
zpEG-*ciSxvnxC=lXI^vd4Y`1ex>a)<ImkYJ#JvnqZN#s|qN`EqaJ&5z<M$2Jyzc&x
zZofNDX-PJ~JKf!UJZmeJL>K0F3M0}$*LJIywZ#sP<@H^8Y3r>xnpc0-w_Qh>xVZ}_
zv9leshuwq;ozGxrdQe?l#|p~a0yl2&+S;|<{8<M(shl{qxB41hJKr?*w{_b+S(S|k
z*QAa#C`?Wm37K8@J1R&^c~N<RD>}AJv@bZybw7to(c`jw>EiBkH#D5Jy1e;g84Z^=
zu$r|nKZZ_YA!dg{<Hivl?1FqUACbu?0Sr^TX>UF|H{o>T;8PCI+R_S^u$RxLOel;L
zvh@{iT-*A^ti7#6>oDJ)R}K%SFWVU{b#wNicgd8t-9u5`+W6LAbvSfzB+ab+x^-O4
zgk|{5YR6ss-Qn+^zzp79u5rq?a{W*J+Z}Dpz%6C4?aOZ6^yZx%@9Mhju4~qfH{;9Q
z-`n|qR---Ydut~is#bf}b!HD!Qp*?iVEB@tOzR7KEvgQwplr0-`-FqPmf?$9R492(
z1KV9tPG7HP_Sv01zc>dO4>QnaTmYE%==9`f7PrVof;@qMYkO7dt%Dy@2KV&h#)Yy}
ziri6m9Z@0At2sMKhqT4A?q1C^pEms~j&HpcDd?Y%XPf_+`_F(g*yXBmukT*M8{;|;
z!8#wd^`Q(l&8mN{>c*02HN3*}IGMcuTi33SY@Dg+yt^+pClBoql%1`*dB*iYzp}7)
zazzBUJNa4rtxVrs`@JJDb7ar?r`yBYmv~xfq>H0(vgiIBFK++cjE*(rUDsa7?`kuD
zJ@a!}9~*1O7tZDEf*#k+dG7wxu#X&Gc6!KYLYsQpj#b+kkATzy3hB?uT?u<IXjHde
zcA3uax)COde0=O(%wjItkhD9kF6#1iLa){wudsh*x40cH&iRO`PS9rWKn=dp`H1N(
zRy(nHei<Xav$CAJo@R2eCCPKf&u;A5l=DIG6~j&kA<nlt?cU$c#?2A$$Mb@0?9}f^
zBPYN(NDfXh8@Ft`VD$724m*9!#!&lyG=lmTem_+D?=rc`$taV7&qiq9B7+g*6pp06
z0p#1VcoqM32qQ6-Y!NYy7VqgJ>Dt1%#mh1$G3<0a*^cnFmyVdSlVl(g|BspXonBr&
z6~fLliFIvnzCUaG!o{;IOS^k<8SkCnTYc8G-FrJ!Y{<?oww{Um*c}5mhBzNSGuY97
zW!X3bw=-+B07#6ZWo9AnCx0hyEM3iP)NRz;9k`Rh_GdEK=GqAZc*of5k5G#YoUX2Z
zGHZ)wqqI&or#g5uzvbGP4Sc-6V%V%RNCCLE+oye7%s2C>TIK_9{<>@Xw7Fd1<b_Mi
zAKBe+3$0F9R=ZhyR%PBf24OoL?_<DKLW8zkRDv!X?zfKz?Z?9XpvV2}$?V3Uofz0d
zmu?D^(LU|lWB)R)@mbxSa@T>Q{U8=Av9ALD`{{Gzz<0Wt9(C=X*~`E<5}dPst?->L
zXFNb%TayeNtenf17~N7%v`jc;S<f6<#o|a%M8Zhd!I{q1wswQ#mW<#B_eu^6K)fhA
z<lv;)T30?edna@qAW7=F@nHLXZoOqNCl?TnQB}nT=^wT-IQShdm!0(`i^|AmWu;l<
z8-2<g#oM7pcA<HX(kxj_JoEm0g(ZA;^sk=J=$}V%h_$ul6}#rWvo1|3!A|_FeoY%I
z;L=y-<FOzvx^GI#<nE~9I&!}9;IXWqb38nt7vb0K9R)}Wm;;NM-N~6}*d5LZupY84
z2`_DTEQp^l<)hHv@nKu)tBh(NTZ(DE!$^)>J(%)*kcF~cIGUY6v`cD!Sxb2P!?w@u
zKgoFFt0QlidDO%!6`GLX^pOZEDpl0X1jONIu(Ps{-uzR;udeZ%dhqaLWbXJk{ovup
z+{sT`{hN94@H;iA96vdz_D_{NsHp>CJ6;waJX{AYg<tvr;%BZXbNoB_0ODt^Bysp{
z{_uVH8na|;&vNWuUf()xIl<^F;^**%S06n50$;fG;Nche!kZ5set|FCe(>-c=?iZ^
zc(?|>@a_YMpZ0~<9zgtzFZ@wEF5i96z4$`6_kE0m208}M<qZoNj@u6+j`WBg$Aka%
z1IR~uMUUgugNP$NW1;ZVRv*&`5yu_g(erfrLBy9H(&JcsAaRsSZJi$~JdilbMRpFy
ztGDjQ#)kxsYKNXaA25F8=w*HFLBuigl{X(m93x+O`$5Dp@|A^u^#JPQF23^agUHj!
zS8hL$IEKD*>w&~ke5K3f7JUwLZT5K<-jN7!SX!7#OkOaZRpjp3c;KMagEe_o+YjoE
z@dmuHy36vkccpHy>CaT<#UU-$RJYNoDFr>G2Jx|yFG7s8s>5yjV_EJyS6?{vg|flY
znG_(F9Iacsnf@^QyD+<s($`C7{Y3}ODsesNnRHOL-ZfMA?Ur9~H$0APOP~(sOf6`e
z8|L%}d6vrHYHI7)TP1gg>DK288yQS<s3TX~U$go!CG|B7T$9`X&!(`(peN4z*DW1|
zchYz7GaY*tEf_Lk8(!UEmxH&Cl)^7rT5kWK$=)B^XIik(HJO4L8U9YEwyyC!MGpLj
z#BjseH~OgeJ{HGtggBkL`sutnH4Ytn>QwH|#?h&1seQ4}G8w8<`-;Dl#X+fau^ay5
zCs9Ug)%bno5XNs<`z|*2)T{B~=PDF1#9fV=GmS3#<IJS+8B5Qm)UMcf*@W6PK1*_l
zB)b#%?myepXE_9h==TUF?yX<>`^rI#)35FSkXyg<!_TE(`Mb+OPNrWszi%@14A-yy
zrQw6l=6y`LfzoL!YuN6bCsK1U-i*|myD<CQg4;C6(re~c=4jKKy-7p%ahh`mUx)i*
zzq)X2ae2T4N3y@`@l);@WeTKr!ZXgE4>O+hSGXf8+<6HFDoC4a(6X3%$gK%yp0e-w
zyOXZUKA9YSn@No9>Nn@Ju%5gpq@6ANIk>Iw$Vt-~Brf)X#CQDp)~R3QUa!4qGP_WB
z@0o9SoHuj#tNhPUF`#3-f+<dRu6^o#j4}7b*=`pL4w&yj#Ly-N_Q#!m$vqi)VaF$<
z^MT*d%Fi=z%H1>`{$OGGxkcRJ#iMxP9X0Bg_^O($-sSY8+#|TSE@vR@Rz_@yvb9a$
zZRy^2?^RYV4tv%4ifK91v$&o#h90-WnUM0S!TKONUYFss{cej-V(#5j=e8_9@3Hu#
zhwXc{OG`_|;|r#;qdAenY9jXCvVC{P;nZ76F3&Bjn({b1&H;`<>|1OftB(HO%E=@`
z%kgN-y^}63qbz9jmaj27^H(hHcnK#gcD(0cZo2nQRV(pJ4(7Ih=Oj1RMlU*kP0QZ?
z#dW_8H+s|Kx8-E;^z72&{EpYMGfW2;#V@U6o7~`%x<Js^zo$6d-L!w`cqw~A7T2Mb
z>#UDs>K2(|oMuG8<#DsCs|$EE7wMvQG78q>#H6WlGxYVdI7eNyGpQjlqIX++rqyw=
z9jbqpPkB`4&Fyj6o;GaD8cJd=Ei9kkxG=y~ZLAM$;sWC<9G!)K$gzI{bPgHk{}kx_
zBWGW-UbCNcx_EVnK-GA$&k{8S{6>hh;AlN4dG<-rIz*^{I<(fTT(ABQJZlJAaatV3
zC|pJ_tES!C{id*%?dSHM{R~cz-n&YZ%JQ4HKPY2AaFUW4XOXmBn9pz<=6asCcwCb@
zQlN*Mdf`xnBDbU6?KIzWpSihI6PZ)j?`^q1CU?Ih3rbl>>H6K2dQyA#o1>@{dv-DM
z>SrY8+lvo5cHCP|_<LAZe>HF4d+)M$ov&H>ZOOePd-7v+Ii~8~W%w=7=Pb;da`(u6
zz=RFEQfecwLvfV)dI71_iP{^kuKl#v`3MW<!<M##QXeW0jC&~(MV)i73Q`X$H!OV<
zNKUc}%a*RYa#zThu>5ZMyzrb}Zc44E{P1>^Y|0C<kkNQh>N@3x8P6zk13c?^DtBw-
zf#+*8<%Ht=-L%wi+7m{OB2J;dlNwHY_M6`$sWZNEmp1w~%YNA~<cCPali`IEGM*W`
zK&V)_iu@4r8@NUF`~t$^=Mn!h=sfn=v11h4>JoA-FW8?}&J7R>|9{lI3!G$ERW4qT
zKmro!0P+%{3<wwmYbIj|b1_s;ch5{GJw27~o(J*Xd%C*2db*hEszX)vJOV<=1q=|q
zb-gH0uMHxif|d{@V1(i!fBzW04I=WUR8UmZR=HPD(fh5v_u7wB=kz(Jb7~&*gI}l4
zUVH7e*8cX|Yrn%vai6u=Tcp{IeYYK$#?q^JtA)yX{m%@Qh0{b;ym2Ak@XnyPV;gm`
zWGW9Skq!u+pN~rb3M3E7!ebj>jz?s;6&PYXOJQzNo-ej(=G|*K<Umi4g+3$3Rf^s@
zR4fRuSA0A2Jh7q+941y{N9I|Q_i-?-eTZ04GMz8a4>R3R;jB|fzQc$)iPO3o12K!Z
zSo20D>-MjSF;>lb3n(g|kcZAaQC+`Q-XXf~@l{VpS6AsxZs+u(dOL;6qC8#B;~%QD
z^$cAg3#QHx7huhKT->2T`CiZYa6QvTlddG1!He>N=Sx&sdY(Ym?Rxn%25)pa(XLsX
zh&ph54@O;93eBRSERIdLt`Td_lwT}5^MfwI81;E>!`MS-M2Qcduj+hvC?Bi6ogHq~
zLrmp*F3)$C<h{J><#W~bjdiaj4*xqx$Pl}>8|R8>8n;MsbbLG36)|_ByxuKR87{Y|
z%EjbR>T+|c+$4Fq+ye@ug-1ynZq(XUxGRlM))9m1U@hoZcNh<gk4()&7@gZmSHAnB
zeb|lrJUmztM1yy$cdM+cStWb#F;2PZUF{xnwdSs>?MJx$aMF5s;52>P_%yvv3>=dG
zz@OYZWgDtTT=|>(LnW{O88QA*uTa-9`K1Ozm&fjh3348^>Eu&NpVE`W9LdP^$#BXj
zVpUPAl>4~SDgU#hts{5sC-u}<tR9TD+*`%EVye0cnZyX6nTlRt%xYJJt{BGJK)w+&
zGJRsPme@E^D~wttjkV6{^zA3H7^tIAtR-d;uLsx7BG&n^Zzx&aq@Nv(Mq7Gbu}XbL
z`GM|qin>WJN1|2j6cebie&G{JudVlux~^Q*r8iA%73uz`@H;7d919YH|A?8|c-$rD
z6{{5EuK1U`z+G}V65%d6yI8gKK9{lAj9Ra7+-0c?#hn!I-Scg+uc3~29@XeOdL%^a
zPl1sTjqP!%>;bVBNBrI_<3}G?Acee3hr7`1B~rX_M{zghdz;F~8#9vTr!fcR-&Fa<
z4Ks;KHghMX`^0!1%WbX7Wb~ax!E2=Somt((!Vii3-b(dU)x3McLyu{CwQ;ZVTiXff
z(T*uB&wXCy$$!`?1A|Pw``%dh)bk;73F7jIyv5??ZR2#b<;zO9+(SislJ*;^Zn2S3
zNH-N8Hb!|1OFiw|w_bXo>dy5WSw-ZwPK?LiU829*Wu1k1vT!p;_gh&-=azDe$L>4s
z4<6I#7K_Kk%+lboaQs5)7mCMBb>cefeR)@Hj3cR#cE9ULDmkwNmG)=KM-Fb-Rh{ih
zzi3pZXO}?59LJ0Kw_dn9bdfn4y%?LFU*46kWT8UZ%dWARoL7R1V{CRmdB3okT&4>Y
z@mpPj#^&P2h0`${o5{_Tpz8F#@Z4|9HrH&>6Z4lx2#G5S#TpaOa}KVMb(5(M(M~X{
zu!_~leL(s6-uV&Kg$t(4W&enhz57b(<6`R|1jZLD^y3O(9Qkieh@&(*#NsG1v#4gx
zYG@pdl}4aPD2}p|o$Fxpb8&5eyT#;TR`ehuJ+HV*&~uZ|imQY4Whd(XlA9$?6@8X=
z?B_>PCoZDWn<G|!#*{DDkNjxg#D$08`67l|+^`u_o%@nvDwQ759xA<AV(a9Cs=p}t
zBhe)sQ_0N{D?jfw=*j)RY74Ep2Z5LQ0~={*PjR(@D+P-3a$%ka?8v<*bccl6uVc-w
z>Nf)9Mj+lZl#}~=tUN<oeDu6zPwp?WXv6myG4H<IV`S40?K5K9?vNbrLj@!?(-xj2
z{0H$B`wHlaUmVp~ZOA8g570vVafJ(C?u~9%Y85(9vFokTc)XUD_x1joO}RHZDc^{#
z(UL36T9W&s<9Nnyi)LAwum4f8*D8+hp}1|0LB3lbNyPV-q<n8zbyj@0*lQgpFLrF9
zP7*R_TMXWwjCYbt*$EL%CG%jf#AFQ4^l<=rWvXoFa%W`hW@<Knj_s6__rJ&53FizG
zS}CXX>Bv3lalG%>mULE#ZP=B2(sy4b`qrdYTvGLxm;2FU%S^K!o%MPFW8<@l+KH+o
z_vzuJ6~|?5y)qHLxvVtX(OE6MSGy<oqbIPP^{#R9?dU`0mE?Z(#O0;lj;=~%TMp#j
z{)FYF-HI*?t20L4DfZVTENl1PgK^)J``#0jmwekhSJ;15I&I#U4EHr0hCGwF<>qwX
zj!lNNw<b=9*lqPJH}?@mxvxHsZ(^@{P}yVqZ&e**!?K5qe{dqSz0u@t@9Rry*%iBI
zr>Ci-ID#)YI^I@WgmvuU|E`!D!2>2Z7+k?VNf05jN%h*YH+$OwT0>@?w?CAUr!|g|
zi_#cf5L0}oIB8Ys++&?dQ?FX9RZihhY^(CZ4SIe}ZDe&+cQqd$SFe5y-Ki#u(f5><
zq)l45i(xkg!SmQ6Y}7X1lJ-c*Z`c^bP(6*U-`^-r3cS*Gb^SufVP%3L^=PoB?rXeR
z*|IC&A#w8Gx<me3)gJ7ps{AE+jvM)>1IOZJ3*h*AOrBv7bVJADRbyeEU5lr4gj~@v
z&n=5CaEzRrpFS(!muJ64`SuZUCVUp_W62qE{F}-3xS^=|1`epxqb=B%PXYdoiuabh
zj{q`wIJNDGS47k;1nXtGrK5p^`RD1bJ2@`ke7UQ+j&a0$9Ve&><1Om{R;x8S3FBtd
z`yEU2&NnLWGP?5(CYIa1wH^g|=Uc{lL{BMXH35w^8lei$o#$Sw>oLRnaHkWpmi^-j
zy90UGTY@?WnaH?UljmFk=sQ@CzP#%#V?AQAl-MXylRK;mV`)*|^Omt5p;*dH_D?7*
z73CdoJIT(oddX*sFT?~oR|4?Fy7=;rx6E~kMpSy!#9@l(JA3kex6E~MQI);?To+^a
zig+`L{2`dO;w}5GjCfon=M`5G7OwJtA?BVl*CifT*{Q?0+LrgaWv)v&uCkM#<F8G5
z*DuRYcQsM)We=Fu-96%ZVZDcTVB)>ixTx&~$~She7iSu&taihrGiyF>N8%~wv(@?y
zd-*!KNj2eOf5enEt_7-NIJ9ye^Vrp8j0aoQJ75zG_=<@CDYE3TbZ7ehl~r$qaX07g
zb5BpqUyplJD}y$}>m6NrzPz<oU2S8vVs&_nbI9pR6>Gjy*}wlS8KbQ=Hfk$s?=s9E
z-E2|^TsC<4L6>P7=ZduemZS7K+5XeY5rY2k=*t0dv>d%Br<7wC?tLeVuss$(yh}Mk
z3=-k#ceKbI+&<5R;=^@C8DoOW-kuG$L1@__YVQgMy6iV4&^zP0=dufp1bTDXA&T#&
zzW1y8?p=2^%?Gw*J8U*KFvYgvYpC$q32zqnHWbtw@o!Xl3*WJA);eAFaR+~Mo#v`&
zdd*Xd{gC*=c^H<h|0dg}_gA(MqwfN3|4Z2||MW~`V?-n$L+EO?13=@OS-!2`%~ZY+
z<Lw5qx!g}H`;EyxdJ3~KbsOqELQJ-c`eb?hqbckaDo==sb|KHtDEs(tPSGx1c{0Zo
z%hYpxT&g-_nL>=TI~@I-vQtmKeQe`MY>SZIOT`SMkB#(&Uo2Nqz72T4<q9!a8dMF*
zwJG1*+r3;|lOfG7RZS|%*j}aI8)|>)>XGFNG1zY8dbPq=Vc1WF$>p}dY+@^2cPvYH
z*heLnCB!Vd!jYC`*gwU~!gZ7pc376JVZW4ImJq}21~0t6y!C@}JXyWNY`U_?i^biI
zh{Xu-xWZ)r@NUWo840U#<(%TXnF-$mQ_~nFvOS7Vi;;DgqiPbJ_7Grboh$rLaSvJx
zQ7i5praRYKcwkA~td`}qYdMNbsl4C2LY(#1ZNAoMoZi4%S$PR7T`j+|+_vrrvct3+
zFj1${y>(oad<qfvif3mp9+Mqc8@DCPtCVq(a<v&6^gX38jaR4Sb@_U(ckv@KZV<uy
zGPeGCD-Bw9l|3Pc^SD<#t&fVHV@%6whZ#mW!SII)kHznjeZnYo$#AkH;+_pm#H;y|
zk0^b{eqwZWqrtel>$78Z_=M77`={jmb<#Qsaj)V1PAt9>b4rY_tzSupuf!5Smsory
zW)`cCK7;0;7@a<$_{vZRZu8q;N!Uix#}d&9OV2B|Qa+{HOa4a^)=7F9c0^fvcCjky
z_36c59AzE3NE?M7jJ5td68bV0A_VUdv0^;dlJknK7{=Pxr&3}qxeST0mYiLzN*ZgM
zXGW=0IM%Y%gZoXtA8a!jZm&_-*N9v2%Wd4(>Ww4{;C54bNU%;a)Frm#3>iFzM-;Ij
z<G3s@@09@<FySp?<_z_5A(nZp%=pU5dt{R95CZaWGe)~IrA%T@aTUV&8vJrfd?l7(
zM>m$WIyx@v92=oNq4-K{khm(*_tfH&DY3>B-$uBz3~8sk?ktn@ic^UD%7VNHCP91I
zl|Ip4EIqq8m2_X}zh$I#<RWbZdT{&SdV4S~i}J@TL<rt@jkV;w;wpx*HrPtq{&%HM
zJl3*PNn@?o9;r^@Sj$ik#@gU_f^9}Fe_v)(X8Ml2{)2<{lBqt?Sj#-JG5evrFCJ+f
zxmX*49*i~rRYAWNTQ?zyzt~Zlb=UhZrN&wsePXeem|2{o#+*Lyz2BZ2sZOC-%Tf>S
zb2?v4-e$PhNgicIj|tNAim#l{sJXP>p5%3tUXC5d2I<+wtEJa$wtr#7b>*UNB)Tx}
zO23rc$FU$G_`d|Ax171N?tiDpT`HZTJzaVerNCXGHDbNOahKdQ33OrKu=&C8HY86Y
z)-ShkPGhfgRd^j`t5-Atvkr%NzN+-&7oxsg0A{TVW3TY)aGw`nM<Gq&;)iz{dt-0k
zE%wsr6^p&Z%;MYyW3M-VA@mBxUS_&{Ud2SkFQslr+^1Zs;hw&$-`|_Mo_3{MGy>DJ
zi^Cv~1$&zprrul>X0H$9aBOJKP8}l<w*iFqzbs5ho46#xKaIou(EQzKbc@Gfa#JP6
z;dVp}xI^Eyt9lE^VRrg(U%VX^2e#>czso2Lq)Te>kM-J$iUYIMD;j{AhEAj!_r;r0
zabT8ux!}uO7p|jDR2&$mOGq=gs9|6Ldy7$VV3vBtVlT0gc65C<_Hqjm@kN$;g<>x|
zUAX`4M#X`Vy09C+1j9gd|K$9>tYX}LR2-PCZqW!#Z>k+JsMOPIHo2j7TNPhqtDlR+
z5$VKuT#SkbV|5B?8y7nq4B*j^iU+gREgp}_O_d6d#i6y`q<Bm&5N6xM@tB-NBAs}=
zmG1|~TYjavT&Z7fXCru?JvX!mFI#=0!Ix?HB<_>owYRO8jJA$kz-6xoW3Bg^;Cx_w
z-GspYqK1G}F^skD(0;sZ^@+t=V&m-S5*(}*hW6xTt5Yb}GSq|XrZ*J#?Vv~cKL3I)
z^zt}rFcj})ty47O(witAb3E3~55;*|>*b<u6uL0(Iz#bY0$oDzf3ZV5ate&Q?oeEp
zwNCN4OKzg%xLX{G=d#u-9CumjqH#BLzSVD5ma8osdbo@x_e58u``5*xbFNwI6pg#A
zqacpu3PWdIv)0MQT-JIp-o}1<D3(irw-DrC^k~k+bK67bUX#>K8l7VCmY7+bmt(wj
zht9rcty3u8GSh?mps~Tw7-%QFrSIY|XhdiF*5c4P*d6O<S9(RGE<L+A+;L3T89ED_
zy<RTzve$*NHyAn(n@E?CHgG9Kbq0Iep9;?NXRlX0_L7?^Dfaq9XJfP1D;#^->#{u*
z*WpT7x<cnNy10brf3}9=xeRrQ23po3P>#>XZVttA8S3K#EOQ;SpB{?iVsr?B_{9$4
z7+;IO8uVuw>Jp2u#D<A;V;Wz%lOxn86kpltz;)6Yirb><Bz^yVAwxDE_w<J1wM_Mi
zMp=6E#Nv#{2-`!kTBbU=NE?A3jJ49Q1jnRtdW7Kp5(v>4Ym0xBwEeSDQ|S|rwdCv)
zW36y@q&kITEkixH-yD2AI3A^|6)(@YtpD&}on)v>G|DoMX*e$HzG8%R<033`9T;E!
z&jfv0Or3;a{8EX_O23{GUukrS#aCixu|ACPwf$ow)F%{Q+3CQ2rT^8WZG`)lOK?9N
zmJ7JA+<Z>bI@y&z(I`vLE*57TmkoY-q;=#XZ3KES){5^+>dRP&5WHVPaark4(qb)@
zKJi#f&Mq<5@-G^xPT^R~P!Go1;KRW-bGEwDUc0;kGwktYefkd#)=QT9L_;m>z=r$I
zZfBJB<H9U!9k@>Xp}T(L>Ldi{7dtq!Fjg8`_smkCSd1k$PMkAijBOuJ+h!7rFtj~a
zVJtC&I2|~i@rUmFjjR*yG%w8n4LD<+Huoj2mtE-;jkNUa;_6AqXm3sI&(aGqgtqi7
z;`HFUDGsf1#^Nmm^Or!7X5p<gw7!|GPVsn4Zlbt)V!Y*t);6=%$?ZWIZ`tYb5_NW|
z`vJS%;Au8GaFEq~y<v|M-a1atZ{)cA{%dVtl&Jg=BZPP2p|4V?@?WO(FMKY!{#*;m
z9sEub<Z>*-)(4Z@fMp0VLPVqAS%x!wPlI|#NZy~S>cItJ>M(AH>d$exo9fM=_;N!u
zPG9Y&T=hQC4&}0`GpTOYcc9(^N>FZy!s)A+&nRx%?c933MLY^K@+LoifVxom@=Rtg
z%j_+}k+6PSwjW8YUx=wwVQX~y{Ta7U+fOCeFEb2}PQzS|bsX4!Fujf;m6)!*j8aG5
z!&b8WY>18{ak(Q@jP>f-emtpOAvJc1G&_B_O3&^mV)eQ#nw!>b+wO}J>lRXJmrgU&
z@5bk!b|v2jztJjA&X(6J;(ht&ji1;je$Ar?Mhf*I*C`*{_vBk}?dI}Yvsirocxim{
zw(-fsblCr?il*}vrtz1Wrw!3<2jry`%q#br2g&lA!_00`y!^I^J;kYPJZId5WziGM
z3yHjya=Tm%Zw+`&cbsIS5}8-`e)6K2d{)V|{kk~0A}U-7=A9sJhTqox=7;hu`3AR2
z`5Ioe-maXgG(EAuBrM!~{`mBXeYHycRC~=^Z>&^TtCc36q!ZUS<Ze{@j{VA2R9Efh
zc@Ho2HJ0(rh7&ZSY7hegKI+A^+f}~84~sgce690!V5U*Wo=^{mm%R2GvaHBTlyWVX
zm)G!^p5I>a)*7vLv55EAO5?{oue{uB(`Nxieb2A|NvR_?Gsq`DPF`M9=e&Midb}9h
zi1#kV(<NEy5k2TnJx+;xT<(LazVqD?)ye(r^yB2`Ig8xSi}k-`brIs`!@W`T?!T<(
zWEoR~ds1L3jUKU>O3W;78Y#z^>a31PmrzV)CqLJP|MyASMEbZW8dd3e#Z?BcCv8q9
zsf+aGLzie|rDqqXj^4LCc=yQa#zof%bYOfH?@8jbSbz|GM}#Wz_)5+zu0j}Jr9Vr9
zujJ(?!dG&3aq4J%<zG26eZujTp$@uFyf4s3ZofR^tihuKb&-`G(VlB$aaQluBdQY@
zRhi4rnCiYR;InqBix5m-Dsh(oo)nl$qem>J5;KeSRUBuHl}DsYD5kQLpZmeyUnOZ1
z+z%#SvWV{olk<wJ4DJU9Hz%o!UFi~ytn}>S)G__wyGB+wF1kjb1LLdn?j$~o1qi|S
zB@}0MznBJJsdS0QS8{fV@wM0)nLgq8%1{UH6UY8A&_>FaXPmYD=s;a$rAIWfGLKWZ
zPwd|{qB?O=mAU+ksm(V8eAZ5N5rXMUCC=)+HwC8B=n;#l#LQxS6=N#DJR)5}F_oSC
z+z*a@BT1X!elU4#bTQ(r;&_s}*p)8P$V$&H7F!=t^Y5MC7+Kx8=o*0zjIY7nNqiOy
z5Q6VZD9+mcavFT4(j^{W$=M~wSN~-r(<dBX8S21&V($}yHnMzq##!A*2I?X!J))77
zd7Q$1;^M1DR3|Q~GMAq*Rs6Yt&)TUjLNI-)#98@wr@&MiJz_DHm|3i^VodeD5$O_&
zsqEzEe$fAVk~YEp;H4dBZT@JIy4aO2(a1{AE*4uHXAORBWOd`BYXmwlzKXw@#AmSp
zA^5(8;;hma(%>tVF7fzE&Mq;&@-H2kKH>PvPzRpF-WrOtyvWy8(ss<zW5u+bcB~Sy
zVUf?B^@ifDO!bMzS@tUFJ#?L+xGPhgT&#^i560T!Q2Z6EM+o9CY82*RtvD2iWvWjs
z))E^hzWHdZ4Tj>eOmzyyT9$gSALtInWzl+Y?|BJEXXw3e*Y76uhvKu0b&5t@dK2x4
zIiZ$*n=<##V4Rk*UM}iJq6_10aVTDk*Cho17dvWmaOV%jZ5itnkGte1N`brLQ2ds$
zUg5aQR2QDx7;FXF(8}dGU)FzIAg0brk7$f#8u8GH5uV%V{`V2piHobu<!4O!Zw`z-
zcdCmJRA1Cc4Hdy-=u&W>eO7wJVk)swcJx{{rnW07+DGEzF;WY~RAL6P@^f7b{w_(I
zNZ&<Ak2TZtic^NiGh@Mh_Mx~+Up{n+Mpk-uaq8&(U!~wa`|R{_(KP}c7+<~jCGlA-
zKnT7scI1V|&iLy8X_B_SD_!F8mE1Im@zs6B$n*)vSB5%ppEwAfXS~dwL*sVR51wbt
zN{?t{Wge&KI4gLbF)LkMRAnwdW6BSnXWU8t5KLb(an}0-?K>+yVlkE2D6zhZF|{2$
z&zO}ip_s}}es14`;CaSS`MK}71ZTdiesF9m39fdfOEj|5vx~(RuS=HR6NrJcs~Z<x
zBhZ2I)eD|y+);-Rd|yg&R`5JycDlslE4gVB<EtAy&zPM);rPl>2ksLK!8ogNdCq5z
z1>>x&^oT}Q=5Y%5iG$#LR#v*WsLEV^##BEzpS6?xA(*~Y;;hZ!d{$O^#9}J3QDS`+
zW2zX8v$E196jRyB&;4K_7-xmbpS~l$81q?+!TGH0bcse*deg*Wi{q@#;Cxng`nc#C
zfewtXTrkesQHKzGUqW%#STN4YPM3ImB{xlCd<}y0S=s3mj;{=L;6AYzjI;d9GtTM;
z<E*Uoh(=cCaSHc|i^2J<taNcvmAU+ksbX+GYbW_bFny`SS^406R#tk%Vk)swVto~3
zsvnHAveG3KQ`yPS{a`N`XNAh2z9YUEan>LhXJw~LG_um0CKg*9XXS(QS=s61qH6>?
zFupp$IBQ28LhyYF#aZ28oRys}@%Tz^n#A~849;g|r%yP(GSq?l#O>hyT&>G9&f5B(
zz+8M*dPE~D^Eie3#Ld?P=Hau_#YI)-@-wD7uMg~X*h&5nOkXN-*5chMFqKA+SWG2m
z7VE1RQ@N!P=@N>m?BwTuaPzN|w2AZ`@x_R<ww{-yE_S6$G_umOi^UelS!2IGvbu56
zH3A(NU;cZN_$(G61mBlXoYnbK8hoYFB_3bN*(JtT=_f{}PdL6Z)Zs7G-714W2(}Rq
z4-xnq?TS|~H=B*K>VX1JUZ#K91Yw5{%Xb<6TItyj-rv=_5PC+#GQ%K;Rn>1Ib%XbN
zT@YPe$c{ok#;hN_|7+L!g*2#(802w9GG<G``@t@Vp0SusY_uI5DXXe6yFC;K?zVj<
z77rm-C}tBgNTMItW%qCHx1Z%s{*v2#cK9%Y44mWnJNC83V858UE_bDCG;-6k+p%t?
zy88XH+;3c*x^>Yz8XXzGi^2QL()%J7Fr<B5+#ofGUq5)i*#*)y9>2*=mj=JZmu1#o
zlM6WHebd7uiH<z?GZtL8-MDN*S#Q=lo3|Z2@0pbz(csH4loP7x^Pc_S{<y4kaUEmk
z@-wD3gZtxll0T$nT*Oe*!Bi)>KQ1dhVlkE2C_6ND7gPD*x@}gvgkmZ?`9Gmzr?KF=
zZK(Y0D=)cFP*et=$14WcZL`xQ8d>R06N@dLPwWKu$7QFFi>?vq!1x*j&wK8uLkPYv
zZm8zqYdd(}Gdo@4@s->(iSgAB?vKk(pKyF-r~~(j-C&$`?(&SY{NVn$tn`RRR_1XE
zudx+_`{T0G#YI)-@-wFL!ToVN$sdC0OC`?A1^35grAI8L5*sDfS23nGgK<_?x`bjX
zJNdaE>;~hkQ2En$#1~`TwjYeMveP9RS?Ns^i!F|`a>4y^+3Dk=YXmwlz7~V~<95^`
z1mBlXoaG1i$7QEWJid~fCNaK>!ToXB=@X8x40X6gjT1LNCiVqv)K68~h_IG<nRa=t
z+$=A*>237JMsvAhJtg04H_nO2%umXtQT>K|{zD0QS(r4;@DX$Wds!~|rus%5@2Q^-
ze@*?s)JeLbDVIB_@(d=${P{+`RbH)lXUesW3aKO>PA?u-OorZ3$E)mzT|ULB9r)b3
z1D{(ZAC5QtKW09awzpa<pSo;9*pt&#7wm&dPZaaIuxqw@L^s+DLqMsDo-541b~JV3
zHrVXtXH4bZqS{!3x(IO>7cqo&F*Ue1Ii}L+5sRtB%y#Go0+{N&U^KdfVk$%VxqUDG
zQ-U^;KE}B~A*`$no-6DgPEZ%S(j^*M>Dk3&i(}ZW-x^ijxab;%4veqDy$O643lM^D
zD_mHqHoV408~e(N#dv%r=M`HajIZKfq`+75@}WySzLK+xRY%`FIQHsM=@X8xEOoe1
z#eLfcAC!AQ?s+CYX+;H$-s~+1Y+kMM<-RT3mcLTQHpSIyrMBXot**4!5T`}gM(V!Z
z^Ol=!#ML%-r^lz{dK1gieVwd_UC9z+)bNhpu?x2&Ez3`{J)gWAS-1fwUrX9qnp}?M
z+5GVRktf7B5e_9zo|h>5Y@Un8jf?thvBKr&jz-%fwEPeg>;@k%<974rr21!%36`PQ
zNNNL?A;bu~#KC@Lht2`p4j8DGYZZl|p;6}exE!tC%oqyE>$Pf)voQ>`zxWrsY`<Aq
zuC}TTx^U`3d9IxHqxm=3b&*PzkV@GNGL0;qA4o3?BP1)&#dTEp=<a0+G0d*e%06Su
z@mY2qg?fw-Q|zu@xcq|Svtr8+QU89H@A$0f^0USQ>+d`MD!%*>1MI5)+20i8+!!Xs
zs&u<_?4;NM6`yeayqpsY<d2>V<NQ3I*ST5vE1BPph+6F?z=rum&XLpeiGz=daf8T%
z2#v%}K0T?}%_@Jp_`&47EJLg5Nh8}T`~EXVA1RwuM2$|o@=Dpq?5Q<vYKMP9+41q?
z(hx(P1!B|}sB#8xNLG#|bGm{sf66-bZx#N^vNv=J0b+PdOrg{1WaZo+oj$|;>;s*$
zymEa77-}>to{tIc^$N{!BmAeA-$&eWA_DMc$H$Ka%H6ZKcw(RV);{l7iug8pVxK%I
z<*heXsu-IzX-sF{Br3cmJG~NDacF>?jb5Ku_0@f526|=W#M5c!ortKi9P3v6{S0*r
zskDgpl0mIS>-KK;hu?AhlxSxgaxjYk1H<cb+gqxfs@Cg5@KtZM(Okzjz0NfH2B^om
zEc4i#hwCGAnM3L++<%5vla~3nl%4&jk5cB08jhAamt(o}AHNWChZs9eqp;+DyRvuw
z{QbxEC?jl^vm@hc?z?x@{zBypG3jpb`>X6HWE`HMoY`ZRW$nwDeFU<G81;VQbnyOo
zoK_I~G_>cHu^rs5^2AC_Od@zo<rWtFF(;iSrrp_pF;2%`8}A2pC1;39?-x!#o3%Yh
zhtvEAv$iSA8e-I4;*{Ie*gx;ut|N}mjq_(&H-C25c8!%a#In1AYmQ~jT{i+*83rM<
zLA!wg%i8<U2xSd1>~3WJU)*2Gd9xk+fCzsT+MR}&GEKefi3pZ&FuQA8hRPRWzWXQN
zn|9saUHP)YqOu^{FQ1@~PgK7wUx)!y;ZMo;a~yyEn`=K9h1Mz?O^;>@yk+#%-UXPv
z(9V(N>b=p$-LB;du~!<v@jB`omA%HEc7NsKiVSI~sVb5s%jH<M{>QSCEyQTMl<n2Z
zZn?lXC#pW(Mwv~F$WD!ASqzM2QpplxnlyM~S$OSvF)&_9CQDWrVri_k@PNNcCr^lR
zQsKtPv!rm-e_qf((R997ZD9o3s(RH`uUUEFMzvX?RR_;2o2?Ku^W(Lf<!ZZyS@Poi
zxHo&-_%W~ASlU=E(o|=T%h)bvQ3ezZDdZNVN9Rwjpgkn$=f$Ssm5p)@^Tgz9Pt_Vr
z<(l3<EI+Q7>*Z6G^-3N4kg$Pxe4MrrYhIs?;dP51D^USMylw%n<4Uf@y<%@mv|Obd
z#}8w-?#>()5%@M0U;o)`(+GVjO9}N+Ik#N#+qATdI*Bi3D2t^_cYnMtCl4nmg^0lS
zB}$jAA5Orxbig}NC`>0Y)k#CU;~EXGoAgFkKD5l`cnz!YxHvt>r($XdyAW>A%_+O(
zJ`jV`(s*gyIL}b53KFZ17nAU`d`=`&?}X6(4A=2b#L9Y1uBOR-7;;gk7-x>KJfhq?
zRJn`sHdj2>H)`$b(s?v!v7VH)=wLRK&baQs+SE7Np<k;mSLu+(uydkTCw7_LZ{=y@
z|0|X5gY@MGwMl6IU^a35Aa_8?vHi=I9U4toAi?tWVfYBNou?`u{Rcgm{QKGE*791j
zSbRQ^?VX_i1B*m=J=gbBn9g5np0)|eDF{+cTkJ{NwQ{>?+$1*o6^q9XOqC8yqAqV{
zzH<E>+Y1r2>$5fOhPP5Zg-YcWak<|7{Bd;?R!+Z3-1&^~*CKy?qeh(*EzQCfavPuL
zHyg{9Rtx4y8<a)wqfN^xYTN0Au(oJdpJIDFNyNe<(kFKMB_y~vj?P{{PoPrn<4UK(
z&yKQ=5O~yA%FUHs&dy@>m_cUiXH|{H+SpsgUWpWS6B1X3n==+`i8&>x7{=Q6@1(_A
zVkvgqx2>8_VrB_c(pc-tJrpCVqfo46st4DN|INg0CjFo)8g1!$C8(UwC_k_{ofvQF
z<=7E%>DeVvOP>QAyl=F1<)Ushx-jmFzmwR<u^=J%w*pz)sm9|jIj;m2#JDT{Woq0d
zmm?AGlCw*omd0KFHKWxl9Cz93@>b;=N*l5bHLDmX=s?hfacbWnU39vRF?Z?+EUb^m
z&b*V8w~Zg(aWIP*m}Ts}K9!8zK0;!ui1ra0iI9}ui8wKv96!!TObppE^_InW%kUVq
zQ%hB5gz{paWW1uN4<3gV&xX|pjw-d+5c~rw8}+s)H!cB4Y1Zt8ER%7#U^zD5c>m?t
z*(f_p!hSCIX-f{VnUnT(ik+%$YEq^(UCM(ZvAa;*puqbB2T!o@H9EaUKR7a~=`ls`
zXD&#cxvo65_ly`MS^6*ryT2gg2jPFx)m2Exa<K+WMlr^q|J%F9U>dz*F_@THR3Kqg
z(-<79UJ%_vF_@)3Tvxe&Oy8!`ch>R2Y>JM5rv`?u;dXtGf8kL2y4sa)(MU|sZbvK%
z^>RG^@ZWoZ>dr;uNOWR6ZhauVPh^2Y+DAmF5Rb>?yy7eD%PQU+e0BGDOfJs_8e|FI
z=;E<==LOO)9FNIO6kla}jk9OR&3e8(Wqf?{wgZ!g<3=SpUFMkF?{rqh1!|5yyvzuI
z(?IApEH=cJ%44Bzdn{z@8DiD&NJAExM$i1ZgBPP`NSXIn&$p{K*tN&bQcthC?$=Db
zKZ?=ww5X0Gw)s^h=e9k5P9i5e!4w^7*f?KGngBS~x>)Y(S7KeP=uI8o=S`GrwS(0f
zj>H|@s4o|90$J`lrBl(OJ0x~Q9IKzL)>rm|jA<4vni)C`FG-4fZZzv~d5dPDi9I5#
zmF7a@FqSrIIO2AbURx_&LH#2p3R;!r4K$|nm@KI*pT=Ofak^S5?jzZrs$}auTGF1{
zpyd%sS4HtPuio%M`b0(dr_a9{JiUopqg9b5N<J+A6)GL?mX({8c`>3qQQRxaVjlmb
zXt2wrU4gMGARt3=`nP5JWM#RrQYkg6bvgtJ4lHZyq>y2<Qp3^12`EN_&R3Sj4hzsR
zpWl>xrs@%VPDwsf#6N_Mu9NR)J{#-v=UeT{x~P~+>jZ4gW&IDu>s+;6lB<Z)E{|7s
zTb4WyqPm6cD3xtiHE9Q{%~qRCGIdT`jrlhW&1~hIAfe(lkKa-0wT;#q<v*~o3RJX&
z5WFt?6N;u;sZ7<+RGW=DZN8Cp1ZA8$dY#ngAZTZ*OU-igyi9+z(&u@S*P%*#e4<n=
z<XF#J_4kR=bbYm9%XnV$M4k!E%mJ=5)p}(dnemTp@zOAw6Ox8)@&B7L8ueDARyhKk
zpdjY)(O~*faodrQlWDFo<!m&YFay^bq+y&rGJ<A$#g+M)raZ}OVGYohM9)(8TKp^W
z5gzGo(@de3fZH>bg~sVh-Lk{uf@MpdqG;CPpEb=SH6(EuklPyT@FFc+Sd|wve*d?o
zBlOHy?*Ia+?%3uxIOz*?!q&mdE3_;#<yLzNuN5|hkyzG;>-@6u5H?N-uV(E1E1Cx?
zbfYF*!z|7hgKjTjgmwD)0G;$h)M6wZm-(bnItg^f>y(!3=+qH`5To-i>ih(b@s*V(
zHV42cY?G(yyb3&rD`g*AbNN4@^Ut@-&Gv>bm3Hj*8y3xq<xrW&30;P4r(}7y8_V(k
z86LttiFSulxZOV^kiJk|uZ*{-p6S12J#u;9(X^E2Vv1?LSIcy)RcTIER?FD7Gcz$g
z3EkPQzb*NYMaFB`QA1V3X>XAEDUJM#s5P$JUo&a9ZB&})Nf$cgN}K2QqHVIyzhLO*
zDyjr@k-CguGU)_nQ3mJzu#xRJ-Q|GBBhqhFZS{|2`g9#V3)1fh_A%r2m3hBfpP)Ho
zY9lQBo?yQDnQE&IHCLpKnXb%q=yzb6)0LHj<hBJhQF6Wg*brR_WazG%=OwM>|DUaB
zTa%TgjZ>#8%@V*0w?>VS`TZ!<D7ZG72hjs>G%HMtvbm0*Bkecc5*C`Eju@LY-8TO{
z4vlQrw$FHoOrM!JQugggfbFm@<(a9J&jd{@3SwFQLD4nJ=rKfJWZF9O`Y*DqBea3+
z05*^<G)`cf&;-q7i{OK?*ZD4rbG%vYhAT^2=bw^1WN#tt$WrgqHk^>M2yB)rO##mO
zaz$W4Mk&UIUy%If%GDOUDQ^L#NY3E+ZxszdG9f!NcyQDi%lnrmof@o@))z6GH;25l
zje`}4VagtuG!;Q<5^+B;$?)l3F89EkH`lI>Q@~nBJD6;=O6B(2e8sOc%edk}8UVC}
zA<FYHohL}z(zH}3M0<~>oo$D4WgY)O+7xn_V3+IlHmUzS#SEgapJ+F0Ce+pS@{^j*
z>gSG^o7M6X#g}L)#x{SfY00F@Jm~Ih|MD6s6UsIH898qDA^%hJm~XS+rb4*CpVs-0
z)z?I1zM>(3QdLB2WI8J87b?y5DpdrBBgB*K^f^USYe|O(nCP^>(P_e^lBinNujn*{
zA860mt?Z<KO{YU$nJ(<be&d)--%$~+uMKGzZhQ+3-6D%OP$$mzd!M4CF}@9a*7d!z
z%oCK(z~{8h9})4tchj@wjzQ9u<I=)+%e0B<TI19n6W^S6zk4gP*V1jj_;4qm=fiha
zH`axn<`kaq{K^BUy?7G~&wHLXS9sp|@ul*LwYgjDS}fl5yyq1{zGH`bas0sX!X9h^
zM_+i0;`z2Ao`GGEf?wcUfETyT7i(VQd&7k@c=JC-`!1mihIpv;Hl`d7(p@gp5whRy
zPtu-IqQR2jAsQH}hG*4denQd6!5p!mE?d`gVL*G1!K2xppuy*n%6g-Tb23zyRBu~X
z<#JcZ^vR`DRMRHyV@?_c`367vTe#dd^37HJMzc-)7+-!!`U#}7ZiBm&{>`=uU__fb
zjG?jiDg8gyvQIV;3V~vxRs}GQF1-LzdyC3re)&H)v>WTbR1-bhX;86DTVK&MG;X4>
z$SH5Tt#v}W=zw658b$uCwMK2lE-z>7O0+0aie}UFKd*HJjkJ*{(2~1v<eqLxsSi+0
zLVUPQk9|$ct>OU+-IU+7c$J3ehG{y62Bir|_%y<&^4ONWztrV{X0l2nS=qapSSJ71
z4h{5&JypHTS4CH-<?j#CA|7ueG^;K<b-4XEnx{0DumnZirVa<D4$*8(9kT5CZ)hG!
zKY&(oS`az<JzR_hsZD?e@C_-a=<uPYfxGX)gnjas!3y!9pf3_DV+Jck8;X_AXEjzp
zBh{C!(bUV9!IP#L!joxt4h{K!w$UJh<^+hCrt`UBd87w0G^M+)lD_5KIkb_+S>3^+
zyC*(m^T*yTefH$k!SQ1=3*N*DuUhxkE9*$(K4bg&vd*S3c|&>VJN@lr{*3%RLaQ@-
z@S9~TDW6A^IT#BZtJkXa)53cioD{w$>zHUtQ)+SwJUBk+KT*V?-gHY#Ez!HsI8d3a
zwA#(a`3hP**LP3xn{LfE>NGP>am{pHO(smQBRJRcZT*Y%BS*^QV#=6o!ClW{OmE_a
zO-<9304>k!SYq)PrR`^D4vGGOY(YMZ{`QnlrZf_hf)$L-bovP^?_{;*Q`ceV4@)O(
zaNl0E^3OKf)m7D3JP<U6p|m}^A9<bX&q%Jh3I;WpOyNFe$;v0w_G)>5^*s_FM@!z+
z$<hnfeHfPIr7}x0j`rpjCOk7BH1*uE(sl5Ld_0!y<z+piF`TH@=N2%yIJzqRtgd+K
zgO|$E=W<_OQ+@fubYxeq{oB}-tZy+FT%)kv?X0=~>He;)*W++Jy3-stx-9--NIE)A
z#{Je;C8l}MEKqj<r>CJWmr;6>)YltddBH}jtvdkb(fv(XhIe42T3Zp3g~UC0aDS6~
ze+13pN)6)@K?m~Ol^>FI2avYfLgnMDqFuD6>eN{hKcdS;(usK)tzTcYYj5J*InkU=
zxT9%`Dkcij*#0dSL30B{VLNmznwduZ6p*I|KW41ieS)&3@CO^qZH*XhGR-faSF}QK
z$qN1(;|$|NHo0yP4U~Wr8oX+jB5E`3u*da8-QN+}idpu-hb7)TueOZEgq4a9@8hjv
zy~EUD{v!@e4aH%vrmv_B-KNcpyj88@)e%H8A(z>EKl58(^01nL6QAdTG}~b`HA%((
z>ps*0#hYGv2@xZ%Q(G&asWzIqgTM;4_rX6(jLTED<37S192q-L7L(KZ+{oedj#RLD
zaAlg759&DGD#i*26ravNMe&(mYn+{|oT=0r!183Ze5&4{NW@~pvJ@hDsL5cSpb{>a
zD#~I4UG^(kwj%k!C9O2D1a*qK)|#E0+hXaj9X*<2FgEU2TjR6y)0kXhy6(4RUo7oL
zU5;M<frl{|>^l4$I*h<?xRGd?=hi<(@}y8+_oY4M-(}g8jkEO{*_UP{7aB7HQ#6gN
z>HP?LO^IB{tLgK9W7}Y=9#{r~+;UEbvD$Iy5Atwb;Dh~SKS-m7?aX8B8+MuC0R-~U
zooN<>H0We__^#syhXzc{QUT3)h;ja2g_FYH+GT=vs!mbH%1H{BD{8K=MKg+~j<yfl
zb%Z?9-sDZ3diR684V|_h%e;M1`G0ZJ9X#FT0Ku0r;{U7i3rs6#p{Ox9bp7uH<TP{w
zOWa=%f^y0gKbj23EGaGs56qmi%!R)T*v?F!lbuD~vz>cET6-E@gHX;{alAP8_W}NH
zr5q`@PKykz$D%`TBA38AC)u95E)!?E`Q-GkX+y%vvCf@sTc%)hlZ}G0+W95BPOT|n
z)DqWaF2GMu8$(L+49si$v2w0Pws(scYLaCexV*GgWz%+TTlfb@574$Nj(L@hSk8_^
ze*}v{=>HBh&W#7wv$i7Wc>RX?ZO+;lR{W%Eb}+m(A4w-L%)0l!<IoLHiQD!4O1oVQ
zO?{73g|nP_r*E8V7*xr=kLeZzbjNUCDKDjv_h7oNOV_R)s?_H&SK3&2>u2x^TShp!
zkSSg=6t|W9H|_caz3eXG#g<P~m{>-SO;ez3ug>i@HbbT^!JB37{kv`3^2&-=6WGEP
z9jhSIG8Eq^$CMJIav+8X2={VeGDF-wRBoO+Bk@Z4zBR^i3El32OI>l{2exWdFeLRv
zObZ&qKhb_8Kx-4RoZTO?<wRIjgM>6mCKl^VJ6UvWwOp=ym})wU0kQzKx70XiblM!E
z-N4OBXE2dcW-F8t8ECtX{U5s?h&R!n134@qD2-kHCEH%h4gWl|q-fCC>79s)W&B2V
zLLf+M_e@Hc2Eaaq1G3Z0LuuV}@<hjex%(UyLyNv-rP`w2Pu*R@MYPUSlxu9V<=CVG
zN6@U1=$IH*z>tbEHhWGP716<l6~WltT(#@5(rnfn-fFY4?loE-ej#!-b?JxDu9tnA
zRO2&$YM8H0>-lXl-^jK+{0DL_MB=%^t6BI-!+#A?UH4l*=<q*>9Z0Bj;|H3Ud1IS&
zuMeZ$u)GFQn|j(5_X|)APZ+?Z4)7TmG{72XJ!(}r)l*wp#&k7uaozUA@`#ha!5l`e
z#V^=?XBD$RTv!uJzt|<!z*20ZrpxFJ)1Sg?kIUj1n&;->c3S-WP#H3hWUcRS7z^jU
z>Wdq8Hd@}<2KH?UWSGiXM^pg2aao<ug_cF_af1xZbX&tRwS*o@CZ@}U(`kMj>vkUE
zlv`^zHriC5#E1UA8E<^hJe#b~)pd+TY^3P9h3;K8PN2Hn8lW+^d4*FBnWni~ga2%(
zqfID_V~DMs?ekZ$4MDY6(6HRSE1mK{BO3){s`OiSI#rvvo!e`R?LR^V&lkf-Gauv+
z<yqmeATmgWs6lZ)ZX@}Bwf!TNrQ8eoJX~B+S*^lTn>s8yzL)4}Kn7Qd(H@3;y6qK)
z<niS=*P|QzSPJ7~2I3A7t}EjELR|Aim+P~`vvhrwZR0Rn52DDy8p+N+Z*W7<uC3~+
z@)Fv*TuCLL$92#hl3yxFTWASLHA@Gs*X|Vo{%csy08dU|bm|>)D__Xi>4c<v;6V<P
zX*R=X>J93uwe1JdG~{T+RW)E~+9hIOT1%7dWUbty{*-1y+H2?v%zS72@pd06l_T2{
zuhN6<H06(NEP;l7{?%%(SC$u`6{|MbVQA489uUTRxW8o^`OmcVF?|Ec$+#~%IvX0{
zRmtyT?w#fz*(ViWZez}(7jDI(b1-1hDJ<~Z$@VjCtXOo_`Wf0gWIchQ!O600Js=`4
znl7yiGF|Brk#uLP4bv_b9}_{RO>FFz+Y>=subj1-k(OaQ${q^)+}<{wwrSY|O%#)0
z%$i`Kd5@{JcLzt<R^_!?6&if99ddiZ@c{3Qn*q#xR_}J(7g{nX$16Oe44o<P6;tbs
zr(P7E+@_@Q=gWPYs?Awt!ObADgRkGHQ(dy}8hf^@!x`-B3^Y^iXZ#;_Xd6pvLX+*$
zb9^|i1FX_iBSl<i2=b;(C#I~nYH&s35-r-iEzdOTwU9fVHeEvqb4JKR{B9af^C;M5
zf6xs{r_R2*j4Pm4Fgdbbt`Q&hHJ^6kZ&8+rRs=m=z+};4DbI@Q9a_zq>_YsvqWKE0
z8mm{>zJSAV8nP{WZA|FUn2lGK+2#Yxh#4QN^58%;-gX!9u-5GwM_xGwRCMC<GRVn3
zWbDciIb_J81i=-L8+9!W6~uVTeZp?XN*<9HR~uBYtrY8HOxxdzqQ#VDrCFuAWIg>)
zMbVOFO#fO4vj=tM%WX`tA>3}3&&y}xjqk~SAcVKobVOFj!u2%x=+5*;Q&YzFeLLr2
zjk(=#e{yGfskMn+24UD~;=}=6794>esFZuB6U(alLaP<Kx-eR!HAz}$=sYkW4+3?@
zw||cv4~u<Fa)9M6i?vDWKdG!mwYDw&s!eBNjK!C_*h7bcOYZ34g>u!h3UyudJHzxV
zayi<~fb!Y4`JWihQ>nMGvD8~#BR|}7_sVo$HcSsood&hWa`z>}G&Bgouvhl8D4((1
z3*om>XO6}nz22!C-Dx^w4c(Uh!>%7)@y=Wi)As(r?vLa&i`T^FVDd3)kj{1XdpFv3
z+dPFh287g#P5poI+2J&j*31Llb3=fx1~;{VDF}<#$AaZCjbg?+j4j(bkfjxNE#Jp;
z%VUqVZG-uu4Ltfw6C>g}4R<z!^x}42nhwcFQ$jdWgQ+R_GBrPjJdCYD+s1*In^Gfv
zXNpSWCbuy}FGl$`HOWJA4V*a*6~L$oja52`<E_HQVZ2m1r~AOK?v#fv6Q}A_@>3a~
z-GN@r>!}>v$9^%EzJ<uiVBl`2FGQdOys;Iv-T%QJ7mHxZ3(iQ^8`NHM`mV*!A*Zgy
z!^>)P8>lQAX>o4T=WV)mE%MWdGFa7iZtgEjHxJ9ZN;~Ami#+mJr~-j5n6cSOkXHag
z<z)Q(FBsNWmZ^)-n9QraSJLlFdx|bu&F*pz_UEs4{EnnI-J#jfaCZou)ph9k-(IlJ
zF`vS9&SR^sXWDU$3XIEbOo6ZIG3s_0%?g4F(2!jSznhLsxM~^`#E9A*pUGu*9e(!w
zooUaDPW)}tpdpAuVRA&r_0o&viEd1u{L}q_?~Gv_-eOdzd5U{*c^vJ~Nv8+BnYQ5c
z(?ME_{0;54GmZ<;ijkb@vkK1G-=P&FE-ruU2D=^|IsqgqpWFGs8LK$7fzgVY>(~tF
zC%u5tssAdwU8tAcRM$ZBRd)HsSMN+~PinA!xv)HT*Nh@`+m5HTi_q<L(TTs64)$14
zUN@}mn0Ln6F1-;=E;f)JWP>qh{31NeGIybvhJ>3l`wHKA4UZj~rzj?WwBpgTzMsK&
zo{#G27`(My#eMLtv*nt<R@UjI$MJfoNJnw?>hij;(+hfSMWnak>d(@?Am+d5^2hY7
zPur|?dMTLytYpCX`@#HYB?C?`oML}2%E$e|LOjjCb2^wV<)>JgZ2K+zU#$6HTYVLq
zg$Z?x`Oafh`@kz6Z3I91@bYT8TB8Vbg|@~n(LP+AXEQF(DtJ+Tl*@65AD0Kmq)Aqm
zs~<<N1KAZZPNcjYuKy@qOddogZPbt%uM{6UWCwZ)9n(|oHFccZvV@V-kI$#A!M5nd
z=MmQ6cH57qH=02w9wYT%tZ=bhYtljo%@#4H{5cipsYRHZp6$_8l1|V4IOoNAA<m3+
z?yGXV7mk+@^{R>SePfX{=&LXla}I$X$8A0CCs)L}q&%y{4;fpXINN0V$CUhno(9w^
zqQNQ?pUmckKGN%Ev<0z0?H(1U>wI{|Mh)mfIB+PU=OVUu$S=H>UB1fAm|pxZL79hg
zsHI7XFOqu<Em*W&A+L&hLUbisw&lY@^90K>HpxFs`9DzxP>(UL8h@gm=zus^go(On
zjz!zlv-P5}&lz=a3}H@)tQ_ug{@mhD`GazEZsS{ej{FQ38cW#1o3@^Nzl{N>pSNnS
zr3+%rmz;8B9IeXGZLU*MefSD4c%ap0*oouVbL^j1&SS;5*78=c)fmqw@$O}&YX|Ab
z>=qsSk&d{>0&$pZdo+zC4&!p`!u;GaRyDN`E^>Smq<;a9G;jb6c^R);QT#1>5p`n!
zI`=g*->2{@yq-LB!Ts}{tk-J!3@yB~pYqvHt&*d1{Z#Q8$`8>{k`^PyGH^@h&Fxe6
zMmlY!h4|WsE%LsURjlt3EUo!+qWgFDaiZ0s+sFUZVka)>xA?qB$v|#q)o(QwBf<so
zc`e5-@|hMH-KkYvu2Z7BlGdK=K2}~3BDx}ugRXSx&aGmGLtHvy(UK1*elKTxVyA^y
zK7$UIHe47VoqwF_)0}iM^bj^89@q*a{R`2^?G$33mdm*FH`Trc+Nz9MuT$dmnW?*;
zui6sQYs>8hf)kB}-qmV;h3ESatZ|($zR=`D9>i43x^LOKR{5h^b!lBr0C_EhM07-r
z>`8vS`xu)Bl}qandL_^FK?4wr`DjrqawP=Iy;uoY^%~+$8Ee1IBSUCg*mq+{wQi5%
zIyc*?bz1&<r8m}!mTTA*0(rT8<ncC`SgWTrngX`cHlJaoZMgZK!tKg0Au1!EVQe|Z
zV?v+CWHKgZJLdywc3hl4sM-$Y3+O>MF4%d`%KcW%x5wiu<Sj3+uhi6e5z6OV`NZZ8
zG)wlOeRclJLq7EM&H*pN9Odu1H2Uxsm%Yh-FnB13t#LKR>z7DVOP0nT@Vpz+)|cqn
zI%8uhx9Fye+Tk*{EPee`IObycufCObR@s7e>07d%Wnobk^BvfE6=Tl3`FXA%xmX}i
z2$=ECo4Nh_c(6+G#Gl+bUcbh79%Hio^Bj|@Z3;AhgrOXEG#Gz3(B(>q@;L#PYm9xa
ze{LB~2;&Kuqh-eCU96FdHiw6`FgwY&C#eyI@lTxxF`d|1=bdV45<P$52WT*Xa;hRc
zqM>D<uy}>bFIX^-nTv3;Qa)L3fNts>Y{9;r?tm2SwRwtWeyg}CfDgRtHr>0AY1+$P
zwM<*+blTlc+8uY;Y4_M^Z8zV&PMXZeeaQnqqRMNPSINA*Xw19FSkL~$l%6e$smsga
z4K!Loq`OpTaE<v&>g!3SeT*eR%RxOIPCJ7lR2J&f;IO!_da;v743DsV&s)P8V06{u
zxTTJLAd2i~1b=mU+-$wjF-QL4w#+LvxKG58<yAy=)|{DGR@HfOp?Q`n*bQWFgwkuV
z)Ydmc^N^j~xjv4yw&Lj3ydTr|zB^10JxKCa)!8DZFNN}VVpE#x&^mV#(DVErx7*I6
zY?<`1RL6&lkF?V%*a;6*wak(9ZotZT><rP1^$5A)NbEK;KBNe2i8d<mV#XcRX^<Um
zR(-|RBO>S+Vs^jJ9X|4FpW)cVDra46h1Is%ijoJb$a;^l<pWDme4#CAz~%QHn_!QE
ze2H%b`+LQF2#<HW-{t5@gA;v>l}1_IVzGxntY5Ls7ctju*%4cw2;*p1lnF5t*^=us
zAC$%3(?NUW=t3OObNjy<|1HL*qK=fW;3kV1qZY;mOnZ~#D*}E+x+3lK#~fSp+95k3
zNz8Wf9XnHyzrpu~s9_Q92ISUebnSnSZI@Pi1Di)M7#jir+a@VJ>wA}@uQ57pLSeh>
zah4-XwEXs2g05pD*G~|>xc{Q@gsdZdhoQK=5TAA3(0_-~(Adtei5Dg{Ubit|ka%K#
zvaK^y_BCA|Gf|ZU#!TdY7kTU@#%1VNtT`r*jXHT1<AY{Zbtufg!!ah(?9iXnyF8|(
zKFi|GanRVS)tC;e02WYa<Gj{2_nJ@|wVZF_r5<8)X%q0$(+{SNZ+^d>PTM{xW)jxL
zo>DVbSq!J+?E^LJ1JH5wRyZv-HJbIQ!gZnLiUR@ce@f3aG_<ur?zKLH5i<>ujBMLG
z(s{yHvCrAunHFBs*e1U}y!^9D0Or}>nNA46w0;aN3Ba_29}O+PRaav~o3{6#B50Mc
z9*Ehl#R$GZyB2N^=c$T!?AqOtCzWo>AB&JRXxChLUA0&x5`b;BxHC^70Jq&fHp;0s
z(X21a`$@QM4tSkWhFW?*3g_K&)2lQg!D+egQ)gl}>XYJ7s+Cp<q){Nxe()x=QQ_m@
zEX4GUh&@-A>#&;k3BRi5A<s}B>0EoN$B?;K*fe}L)%b#9F#RC5y+cMWqZ3R&q|TgL
zH2omWyrJPfW9*f-9Mk%I*wFbz@MXJieo4)_2>ocqeYHk6oN{_`C|zz|<@Cib*!dA3
z2KRM`q$5rdd$w8s!54>lfQC8|ZKLg{sx~3yG+i=O(d}#S=L!b_8ZoS~+Tq~yc6o*u
zpU+`jb=BPrp5P~A43>HEX|_D>_<(6TVKiz?z%&Ji#_qFC8!JW9nDu&Yk3~mjn;%=j
z*sI{wjYBJHk?Xh@;Hg40y~cVs$2Dp`i05`+%<DJjmOUB(^Y@oq-)Zp6-|y7ls}B9!
ztnW7cJM?$op})uaZqwhZzhmTUmD{(z6FvLuoI2B9UaHf5nKj*yBYXszmir#1KhJrQ
zJ`~TC_Q+U;PBh}|fyQ$0ZzcXPHGis(Gah1}%gWLz;>oyJ{5zKh#l!5LpkkVCkcPG~
zNfPa!`+x89X{@eNbY-*Cw447BN{gu7l+8HneKUfVrXiJ}ET{i}Tw0qU+j?_|#$u#w
zO*ZYTxqp<hQpLn2+q$Fr7JSEc0^{HMFOoh{O4Vqsu8C_*w14Y=!Ahq?KaC|Z{$cEQ
z)fsn@U!{Avnt;-&zTO^|ev^^Q{~_7uA%BxDNMd>WZ_(wp)*vr`-~MU!z1^tZxX<))
z{(rZ>d&pt(j9F=v!n_LRd(Hk{vc6LS(-+?>=N57GtS~Nr?^)kT3I1MqrqT`cEi8`k
z_mVnGung4G?N97adj-j#Y8F%7;tnHD+fwy!*E-k1mYUaJu2gIKl0oRt>A6ozIYhd3
z$so&9V0olCLQb;ZrfRp#VpE#o_w?_V?N&@FE*zZ~TQCnE&~0<WPWKvTaAhfN3vl|h
zS2;9dhEiF>)KB->T+S)lD5>o<c9ZiR5x2?1cwJsQ-D+d5j_ud~qO$FpTJghT8rx^=
zOG9Y_K%8Dw=iruQUa%I)x<0p#O6)CTr#3bX=<kJJRCcF}>meia8+)7e9pf4de{hV&
zr2BS0y`pOTZZ9O=Vx!CN+`;9LRK`YyuPAvja3TB=4#<Xmu5TL9SnCgqYM(CFZC9(O
zWM2*+hHG<-OoKN_A0}yN6O7s!AeTTiHgaza(uuWdL8a^JHkMBu{=Dhgkd4#wI7~({
zGRmQIutG0R8+(`LEz=NPvyZ(`jf;^Fcx(f;?Z$1h<yq33^KUWUFrXEHv(ie8Ih97B
z<NEX~s$4j3>~Uw)h;-uLze>i@h>*vzoQf5kjTUXbru>xtMf{)QY@|DDJ0usSf7Yby
zbsg3#_ZwVx-~>PNuwH{-w`pV}=luR7Wt=8vxYRYyVm2E2**|PDj>NVWEAD!Z$}5g#
z(A+4myJ|>lY%P9J&cCk!s5CZV%$>BplTEqI;-qZjL=T8+UHluY?`kcOd97()xTwi0
z!#Cfn6qqpmIrIIFO0!|g-mA*M>NvKv>F<RD>U$f96TpY-?@H7X)t_3b;w1&0Z|etS
zKJ0A}%k8XVcSZUg-t)lUH=nHN#fkSln$PA_?C)k@(%92wJ*X`T>P(=yYhqKa?*-Du
zFoSN0hAKLy+f-PosMGWIR4vi5j9cpdLe*vH?}gXM_9;)un|dob-^E+#x=xG#SK?Eh
zsuwXFms5Cx)OqzFuF6y8lN@i*-)EdQe6#9T1R9la+)fK$l(J#V1RSz)tlUoer(}J|
zbacX&zGH`!914&upFhFhB`D}S$+!M}>ia6RTHm96#dcMd5!mR>{7S#3(s3&-ZG<@h
zeq!$LR>e=Ofq3U`x>1hE(X(Q`2@8_qY%ID^b>+7m2V}v6<r~}2a$xic|IfDln)0tC
z&k6?w%6?>zP2~fz9R;%qE4uEt*dDakUYcBBiSm5$39?=Bnl#JMVHy18TDfKIYf<eJ
z+gh49BZhTUgV((3Q`EK=E%)|sDtqI)%4Guy-5yHs9!|IWTE<S-=7SsHNq)9X@m+?;
zS*s8o+lQrFg>V^zciMbpA)HotwZb;tDzGH)N8~jBpJn^9$5EWNt@<vJrg|<;+x&5h
zry3e?T29@8Mfu8Vfr;y<d!52aQ;sG0d+v{9JhF<|eJ||8-wU7C-)r=p%h>*u^_}2u
z*>n(0Bk04GG0%=EYl8~o?*miT1{KErV0T5@h*t1;U5Gn!uE&AerzTeU%vLocukz=V
z9`xyBs!tJV80)f*{ZE^68RuMHPR;329y(0Gr_gwPrK9#qP`a9>;i${nlV{d%x*_zz
zoq{m2UfUW|_xVWvkw?!B&d*7_5Iw;KN98F*)VglpAp0pw=lvku27HBWktVkqiDOM_
z7o~2G#h)@|_-a=VujP~M%x@cBnBqj@$E#ozWU3`oO_zJbFda?kWAmVhftlY}2pv|)
zDnWkv5IQ>kE|^)iErigiSuzPbm4oLKIzMd7i9mB*Z9bHaUtEg7xLN$1!IZVMqW9x2
zTJ>s|2@pkAGV|`dO14R|>jsu_v4gNpr<57bxgRldo>i61ZLhEP3L!7H5}C6CgSV(U
z74MUQEv;_vHF0K6?Q56Y0Oh7WG4{lDL|7DRE?fOc=c&^7Nbr$UFn+kF;xLu=!g{%m
zQjBltm!xi(SZFse0meG{&Ud+Hz&hn;tvuKe#Cf)k*xzLy@-<Z6bAMOH!gvD@m(;tj
zni1ZJrs&YvS6j;0mYCP1Lnj6xxPn!_ZpOS0+cZNjoXPf1WzM*C5igy|Hb(R%o8FoF
zmv^%fc8PAmr2`}bGw$kMG@?D}(gv=*l#gn#?*G}L#Z-#AE|p4Wnnjz&c?nJ8i^^OH
z(hR+bW^`T)(mF4r8M>N7H~c~x`EV-Rcj(ZWPMN*<^WqGTd?k(bX$R@8m(r+>63=rs
z%^`j*&Di9{fpqg~nvuT~q=8R_Ki99PF}7YFO($MZW4b$s=<HY2OkLa+PA4x3oS;|V
z3~e_^JM^lWp?&R+wDNT|mi6`Fv<v*g8sqxSJJCs&qMxBU*$mK{D^X>8W<0ztKo<rF
zvH{EbjsQJ1e)E!=sq=S+&@EtD-EJ$r0F8NtM&7wgdfXkP5%WOPaKrM3Nw&>B0lFh0
zud6Zby`i*+Mfkw4F0sD-9cby5HEshR3()aPYs}~O0_o&B%xi1LzW0UD;hw_72*(5#
zncr4`Za(n(8n@q157F^UKKpc?es+k4&hk-hNgH#SUkuVYFR>ZFJ_w~-z)b<}i)_sI
zs{wkVJZQc2$MyF00NpXnZK;P%)XQuJf8Vfa$$I0o3?eT%W!r2AX%504s(VnmeS9-W
z6Z&GCDfe4Jdh6vjF8AMpH2U>6gM-}1tv;LNKdugrDEV$yzV}L-ZaQj-c|7o%oAFau
zhv#=*bz@sR%%w%Y3X=}K>}K|>jz!Q9zwl<{d6bhU?4>uu|FJHu>W#x*d^2`^f}2NJ
z)qeSnF_{mcn-RXJh}9&+?<qE&eNC^r51Fz1bcZhdH8?K&haB4B7vY#^!KOPhd<8Cv
zz_j~p+Mz3O<$IA_&o|k$JG=tN@;=w54|xfW>52|r@HIHoh9-k_)X9jK%M8t7hsJ(Y
z&G?}in+E$cCPH6VGxVhZz10^wudK067XtJorg{v5?!%^TQ^$oT1GJ{E+ox&%bAV>v
zdUcKWfG-AUc6zXk?Y?5?Sr~qOjr*`QhmNmwm+y;_F10|qaF<r>>j%;i3Zi|<m)O|%
zwF5M~ZH8JE<L{hJvx9<M4==XqPpBsm1Fy2NEjkV@y}YJSA)h4Fb@B2cIs-x)bCEr^
z)VnHld&(+Jh+y)8(|nyKQpDXiq#w<#cGOth+UdeOp|OD%_pht{45Xh}V-KTOTOicB
zl)gWpH%z<3C|lZG%=fCf8cU|(qqdNp>`3%EHE(axJ5%>8yFbi#XbOnOu*FZvc?9A~
z^9WQ7r*#8q9&AmRB3ZVtm-CcEiXx5W$UiHB#+vtJ+QKuUXlWCadmlt8h89!2P4!fd
zp110lJalv3*>an9VH?{P)cPm%G3g%ePs1c1oyp`n7^rpPAv)AV1B+XafPKI=m&gBU
zy@*aAv5sA}o`T)%xSvh=1looz_Y)J8wSD{8mq&A3pf&UTv=)X!cwVCaF*&D#BZ}=d
z&`v%@;EH8z;gY2$WpdZDx79hOYD=E9<N7XqLDhl$E;6y+zFG&YwpOaAFmWc<Ud*z#
z)^YP4%tPN67$nvB>dmnH>q|@J8m?BebeIjMNgcGTZeF^!LhC;`;^ak|o7cDVF5&nR
z_7Je`@^-l*&CR=Q=RMUd``E$3c{lC6BF)X)yVa8Gv{ab$j@dHHG?AJ0-E#BRY3~-N
z72LdaQkT=lY<W+M-LqQWzLQU+Ic07;W%_uBr>*mDx_K$h$=kPWK~S*d&8fW<)fVcV
z(kywmY<Z=)y3CHv(}=5eEjf9GxH@mn$*aZHc?Whnt|OvLI=F7~w!9)usH)pxL9JC)
zTbOOM^juW?v2d}9Jg8{xOUfTrbBAIU(#%h8@mwRm(~Kgw_0Ei@rz45_d%^l{({CS?
zbELRIO)Rc6pORY3tgV=}O!67;Rcm`<X>a0$?vo#jG&<)ezN6#A<`6ojLDi}4v-nnt
zYcZ*9rgnAu;4kE!R689ZjJEwEqBin%G_s*1DdY#)_I-7akVq2@DzJ)7r@t>%cfiV9
z3RRbGrJq#qugY|@F^cWcS9?B?zC`@!JN<pRiY4$Jr(w@&du*#U&KeGOY~Xk&fI?TI
z3YnN^;a#$>YOP8Iu0`w8`E~2N)dy-_?R+8Yl>U3|{PGeFi;cFYZ}Sm5=uE$|Y0H2#
zJ3q^j3(~0jI=CMzg{RxBG(P(Z=eV4mT$cXsTi<Qm=GB}!=pCGIDV)=HqG$iM_><Bm
zYBQ%;73H-2w`6Q%Z}jA}Th$%{IvS52mbOS~*#<xW;gOHcQy!ANqt>eJGt!Kg7n?Nd
za5b;qIVImx3-`?$xwo9}(x0$wgP+oQ#Ki%W%5~EXrnO{VPVcM!cYTSnnkr%5i*7n?
ze-O5$zjr9i<4#c>Ky$t#+tS)!%Xr^@lJqsa*1~xP&r#oTqm4MJiZa+<=ajwFp)_MJ
z=G7o)x>wV`UhP|}<1Pv;jA{C<hswH=fv~Yt|Ge}`cnqy>FH{nSN!L%~|K!*F9p1nr
zn-cAn>WqXhpD(4SNoV-X5v5-po_>PTSl@#38@{^SfO)^3zpvKCY#G0M%ISALM#ho;
zYTbEYmD6)v_G;ZoXO;UlWj9`n<$RA<cf8`N>811DUb^1n#ywWP&nqnW)ur=$t?ys8
zzOxTUa<0g7aHCOqsBg*blQ{4jXV+@JX#?AL$vWaSULs}e6x5y!d&>sNPW(D*F9p)<
ztri*+#rMhfBhsz-%y+&U2g@<;;yrdgm2R4luFHK~XX>U3maD7oYklEH1y_#ZpsFWa
zfsX0(dt_`Z(`m(6u2N!nq1$)=Po&Q>G;&p$?NYp6+EQ$NkxQRC@8UB8X-KziIu^`}
z@d~%$?)#<gXk4Oi=kok}&3CpKW9Uw`w+?w~#e({W0?D3KZYeB1gzluml;Cs2>ME0n
zzZSoa&2OJWRiKF<T@PxX4DmzAz*}WBwzj@4ZOrMk8IAM$|H5hZE^ITVT~uT6X5|!I
z01n@)5jfpJAs(!S9QzeceYNLW(>e?B*nNlhn5gTqt}xOvmQ*~}#4%0yL3m{2r`L7b
z@>;99TCbck?PgK!NyCFo7zCg5DI?V-#LDf}`7nF3TKDN@Ij-k|lO~dMzLMq%ZZexr
zdzIRw*QEO{C=EM!xV%|ApJb`ie$vh-vxzin-$m62G~0N>GLY}KKpNd_#5(vo4V4m*
zbKOp}cv5*Koz_OLBNJJN32hgZh5|WlpPkR*Nw)ssKpM+QX}9Y%+L9^@WS%FTG$RYi
zx#*-x%W(VMRB<e><*6-!mhrr;=5Sh-HFesX4!N83{O?P=Tj>C%neW*8OBuUUdQHA3
zt0Me;w5+Jh>0cv#4;`$TpP$;R?o2Yi@AF&^_At9oq-q|U%6}3M<2_CN=G9puN?!uD
zQM}GuRC~rLP0i1VedBD0p4!(%>DCow8asWpuZz-oUl;caMYZ2Vr^yTSbWg`+<kg+h
ziVnx-rSIlC8WfC;NPNcanA#sk`FMXA&s+A@ycMMl&9#N}A3fE_5WU^Qu#5xMzi>M5
zSz=l8YVSU!bIibY7*qSVMA{DfxAH$F`*lGVvVV)q+E#nciB29zH@>r=_AgPI<2H9N
z0`o0cIt2G8b=3YO@OAblZ9Pu*&FVXMb-I5neNy9Bn2hbY_{Yw7osa9!S98PaHgjw0
z*4e(Nu`mFpY3#uVtqJ3-S4W-G;xuO*bgPoT&L@;xTJ|ot8(+pFJdQi0_Hc^5b4Tly
z@#d*1n(Y*;^5SM$)9)2*+J&=?Fj~g>7T2q|V!+71#cdSdH(H{38r{_1UBUsSQOv3J
z{-%sU5c<mtT&=X?|8>)7G{pI~US_8?#9nVs%m24P8Zt7@3u>-YU1&Qr*U5Tzls~4P
zp<Fk6`1{WHy_)Z)x~~=^GjY*vkTK7#4}x^oJS)rJ{YNRk=4I)ff1>m=bgMRA8}uoz
z=X^gKNVDy{srtJ1*~UTxr)Q8&W2ktWEN???oMV1t?stNu&a*jd=Q*oo@ZIlDo}$`^
zhm}<^VZgQ?v%ez;f8SK|1w>C12K?Q(zk{CT^;HavYvk1HR>n461d-JC_>BjeiQ;xX
zQ1ehKP0vIzW{MAzK2P52+(tU$p~loXb_h&2_UDSOy?PVUyvC~MOd_$I+vxB~7QS)9
z#&z)lDvcch^yYje&c|uUsMD1HIHS{ATEFejOS!BxDpIHClz&0Gb}+U~7)(ofTVi5%
zmD1RD#qUTTd4|)}oCVbtipbro#;CzN;__=U-&u7Jtu(r+<AS<l5%(nG3Pyv8?PZBO
zz7U%AFI1fGLO)K+uj#ZQAG26>(`>!_FR{~HAJgds(vVS?_j5X}-B@1|7GZmB{cIpD
zFvsJ+P5OEaKatf8P?>k>7oBvfMpLevS8(Qf$Ujr=e^J9)QGb;8YSa>~W$`_IeE5m;
zy@Ts7uormi&m^YAjj-Uu`i*_v`fkM6=>^qB)Qb%21qn-sQwkU8tb>^7s@UT!&L5EM
z><>ymt;!6ZDR#aKNa#F0ix;IZuPyUk*p|O<Ti<Q^F;j+f-l$-IM+WB8lY6^Gm`pmb
z-HP(AE9VhkTgOc~7bXXlNT9VyG|OC9mQyB^@VB1+X3E_%-yFSidj%fFjG|p$U)~SD
zyywOy0a43edZwUXzG1KY&Smzu<aZolHgd={Q85F{`fp1=C68#KK>j|EXPj3n*j$e2
zN!w*GE&4n8T^x>*mm+a{*p%nxMY^~q7d$!5muE~?D{GA!-eVC*<+!{YrvYbnd8J!a
zdGtM`yn;N(wTe_s5x6`{@+=gtZNgb7OSh6dTeM2^UAB!kWz0?A&r$;0av;y#)6pDl
zpKUo8&dW{ud*?q1c}YJpW@6p*PZ4cGHX#g}aFu}0<IB1d%O)fbmrMVReu-`$)b{U6
z+|jp*xdpW=5_D|Gv40o!E~nwG?_G(j^`$1x!CBw)e<$hjGG_xI(tL6^nD1l^)?=H$
zw~&D@+QmOk+YF>pu)%Vb<Xk$uugu1Ia_)C0KFQ1Zb2+_k$=sFa%hxOG^g@CuBex-Z
zF@47kTIT!U--PY)eI1AA&37!M3;R~q0WM3A&ds6@aT-HUrE48~CJl<<sRFB<u8b9A
zr;P7hk3ESu0XMeCmiZ<Qp7HmboNr|aYWwA_@05Y*$7-UUUf80Gi7g$*<b0TUf!va_
zccZYAnAW5`?DGoJ7s42N#{?}8>hzL4t3v7aQ57vqUf#(nA7Mg1mJy*I*;z#-1}|M1
ztLR9D%Hlk^Ul4j>7=m!aib1>b&Nli^*JEq?lAQCP?+zvgj}>z&^c~NUo494{3H;q{
z55>0#tbo2Q7%@%@ZI-7l8Chlb?-2H+Jc1eP;LCL<eD{}{Se)eViw|U8QVA|&^RuF_
z<=ra6_MFH6N0A4Z6T=xj*Rv`0P&ZK>s?_ngB=&qAE=?IbkI8xqt+OulK;3Y-sAbGQ
zK(qmbgQC09_}|Le-$irPdB(mj>>xu#%hsJGAv=9{>TLU4n%=3i#c$~EPM!JR*56w`
zoEY1tBkd3VvM#kf|DNgV5=2&=4Ky#eo;SZ~@`%E%Je#^4x1Njt!g*vpbNQVIDO-`R
zgy#b*ZO0DVSEZ39S)Z<qNuiI-#{7!zcVT?a)913<;u>bnYw%Vjo2*9teM`ozDy(h6
zSN(t(AJ9DG19GCv$$dAXQUA(Z?hH1$&>9^5-axuomV~!?B7VR8DLF)|blZXK+N|Sq
z;Cc16FQRmnL=K90yawM6PR{_L<~MEL+7N3bQjYtO_JEvr8IW6k?+G8P;i|v;a!kad
zE!bJocdk(QR+s5fnaryO-5!wB?po);beP>HM4-z2@Eo>G<IDLFy<M-$I*hd{8b=Cs
zG0TRBZi3gm>oUF}Y3(5=?0MC--x;H|(ut#U-tnoq`RSvx-jVTJ=ocmro{IDjBmDun
zg_1WhJ~MM*eBxHGG&g;8ZhGPQ-t5u2BjYpBkLj)mr<<NVK0Y%&NpDeHb?vuBd6U!g
zrJ3>PPaK^+IDN>QpBSH=nVy~Uj?PU^%}vi9@}_4OrsihGC#H~#>irsl1DH>YRru~|
zOa?bjS1Z`(deyc6A>_Q}=mGEOfm@~~7QET11#fPAVah`x3v)+jys6po0}=y!75xKq
zJJBB*Kj|G9pPf80J-KjLmvQBec_!y4O5VcwA=*<fWx8rddSMvv;LP};dFXaM^89m9
zkLjbKYLG37*3ltIJHG(=$7hbhw8xLm96N#*uwUhK^a$oVcyw-J$~!hYz2J>cOiazs
zd#HT6%RrWSwXIWpUSMke=)nabs6_tgs%!rha$k`v(SuTS<m5>CTy>rH2U7c`_P&8R
zF>Jr_sQpr#Ck%RF5LD??@Fb<F<5RN>-sJegxHma9KQT95S~xl<+xwG|jvXI+_F_*o
z`;?|~D)jq>09NVPiTMT4Uyt8}rJaz$^+obN0y4nBhrANymhv8=@*?D+JlBEln3d`A
z_|`+2CDL(bYJB!s$vZT6^jHaWBp><2(!}9$Du8HjwfI}A3fk`n%~{$S3hO-@w5Py#
zeC`M~105{Q&v|oGz$Wn|x)W$`_#@~}SacH>-HjyIgftG>hA?N@W~lZRltsN!J$uLI
zr{;j7h3VtuGfHz)^HZ}EQ$mJEkX~d5$UrjX@%O;<7qp*d+v2m}_fg_!<6vs``1Bm$
zb^HdApX@q6efyNRKtAbe;oGorqE=q6v?eh1z0#bOZyMu}6JCH9{Ueo2`6iVy2ygF0
zIifDu<xS60OM=u=&TC2T`NK!&P!888#8M8_*wbUfD}yqYZ57y?g0<lFFw)WLzo@>a
zEqvSc&GoCxQ58%&J(+dFC2Pdv14^g)=_92XI7OwJw)-)KFI^8uj}j7v-QO9shq61#
zO!S1MW6B=%`wFtp@uTGOMLM-(vF-*;Qu+(=`$PcGs=3(e30lIyVSwh?%!2s+Nc<+q
z(A{ywOSdI_zYf12NA|Ph1A21L^EZ}i;wfukiz8&uiQy6nGt@uD^iJAO9YZ(8?VfP(
z>&i|g*bd@o%-Z#BK~~65wmJ+iO+6Fwpn4O&LA48NbMImM+r9x+2t>}9nv}R(2krQg
zNwoJPCnpphh%ehsu@z-MhWv=PPNo!gp}bx&Gt$V;AkC>N7QY`!b*w6a(tV_>DiwM^
zf_T~WAnvyj*Bqd2%2??g$V2<IOn)w3{ZYL-`C{4cgDkAyS6l1X#RctgF+v(%*X15|
z?fancV=?z}MefkNHznqIu$zBQJ}w1$o(P(IL9@m*6Y_O8rXU_~Lpsa=9c>=!L=(JE
zoXmvhH-ZOxvXVCgydsD>IWbjQpfC*qEn*~57u07G7V$@5=&h88!k(#<;v3<b_{{9Y
z2zkj*d<b+1NREy#P#iWtetZhvWolgTC4EIWrT8*^2)W=z`Wt~uM@3XOFUukOnzXqo
zM4;p@gg$NjJ)qhUVT;OTb*RkO;djYo){H5Q%CxNHq*0kxnl6;`ZMr;l8e{cQ7zfZ>
zR&s9^Bi6jfa-G8TXPIvJc^4hG*B+>NNt&?dU344yv`afwFpmY=7<UNyqMvsWnB9OQ
zxJ%pzi=$CEs$v$coA93xyOz?sGQENO;QUh!heXgk6QJ%G9@q<KbD{dZ>e^R4N{mft
zpoZB;@t&S|-Qm$H4eg%NPHo^STzd84(P-<xg*<#m?m2lyuKvz<<l;MBVJp6W2=sgh
zueyR)f9E@R@m<jG1^-RZ^P4Z?`3AlyDDX4`ty5P}#w>90D%b-nbtEgUs>0oWcyUf%
zNJGbW>J2>3R#~kyEA{2db3^@I{`x!_pp84vZv?-8F#Oaom-rYS6uQX_CL{UpMdTZw
z^ALxa_=xJtD@`9f4p}L-_*=nSK1|V|N3qUebc}wF<|fGp{FRe#?NKmfqW%3S(H%M_
z`tO6tcbCYQ%mym<45}df$ET?M$vJazB9HtV)d_k4vTtZD+zgtpneszz7GZZ-T-xPN
zjo$jQN>-Wdb_=CPbkci~el$9L|NiH0)ah}7m1olai)U_7p$Cv>E=`^wm)6aK$D4%Q
zyRy5`o$UK1!9&>>8$iwma6$g{si2_?acRIszVKyKPxMwJ_M6p~$~d?o_m+^Y-fij&
zxBQ5QiZsS3{i7zm-k|dyY-repc;9W(om5Kuph<HWlZ@nZywY)jb&82TH>6iMo~i9T
zgJ{K-zhX$4y9M9gCh{k<?N0cjc6D0tA_&V{3+r@C<ce3vwZS}$g<rZ__(b9LtPOBf
zM;|bH!;jR;XK*S7FQ#a_l5JjRXs}0V19p{lLRfoO3SGkd3;Cr#HatSxSfE`Cd{Mpp
zH{`SD)+nBxQNcf@lP^)OMEEFbYY|ON_^3CLo^n>8y(V@n9aOt-Rony|?FZjarju9u
zV6xXA#N>^rZ_R`BB1|!)=r^??Pc<U83(qkUMt)C}DcWK1ysob3>vB&+%gg1SfEeOI
z>=o7PByxt7{J5lfaRd#5X<B+jUn67en-CXhUe=Yqs?h!W(K+GV7hU*E9Y*e;%GV3Y
zH{8PZ?>9X^U!N-D@y9DU_W=(N%Bd5zN(t8CE|KOB#TmE|Q=H#rdu&TOH(pUh%&YVu
zDo4aLc09tYFn=fQakrpTJ&x7P_V1@<CetvPK9BiVZ9mInNqSK^wEb7db~yI11HIe<
z`a~tmw*)N-;ViA9j;|48XsSnw=^~y_MIB#rE!|zqZ-6I#0-X5gkdNQgi+EB`$dM-@
z@b4<ZW8mpMals$bu2cM&PRhGlU1{-d5=ld2^$;3ngZ|+fF`f_5;8i`^%OquX)2djj
zYl{b9DSenfrAzkVGV-ox$%ANyc`%LSL*<Z<V>y(=rXUy1Na|^)pJ~*9LAqzK(k|0n
z1Tw~r`>20=2<m5U{zts&BjbmrJdDRCY2-z-<&)DGoM3MA`B*)d^OfHP+7QBtqmxr&
zCjAgi*MpY)Py)VU4wUG;1Okw(RQ|A>L&XcdiLW|$I&|!m>i;Ct=^x>3n%;FgAn!um
zP5e${eyR(8hb=71#8ev{<J5BvSL45FKa@=yc-~EnfeN5|uGkxe@ZC5;ykUnYuCWv7
zsTfP${yn)Iz3F#FPIcLGp++4Hk(hgyqMHe$^UQKOx1_zGr?P)Ej9wf#5qxctMBH^d
z>{^nQgh{KzQ{z}^nFoR>wm4?eCh;18Ohg%!wger_P#crdm=~Br8pSiDAD@wtrM5+$
z7Wm1cC^9hoC_dcKX>zKb!3>tsaw3i5xYr;yIBd<ul6-_0S(YQZh&2`+*=bhq==?NI
zo~W|^*u+#^#UiL;IaQk)5|m{5AGR!>C(2vVvK$q2G~+W$ci5ToP`#<K<Wi$i6JxF0
z$cCtqh3NxA|7HBP<~Fp!Syz@RSWo{IWvet(zbKD%8K*L&k>=q#X!c0g@m{1)MWqMF
zB}Z_p1R_83BNfVH0b}aWG}ccrYXs&zc|vgz>8I2a`sUFdOKOszY$C?6>YP<u$xC)r
z@&*hkF+%uK=?=h1*Hxq`oDb=0>VRT(Q3XP#BapGAgnXikTNV*tU6sQ!!HS0~HZbj?
zVv=X6^w(ov=BgapzTd$9v33<BrStMJdQUt@$p_PT9rsSeQ&;6?+Y|DR!-dL{i5UhW
zP5GSgCu?>5@_N`$^u?qCqc-HJ*u5&oxEk@!5PkSFvAT?NVR@)Lbyx#8l9ZPbWpa%4
z)fjs9B$TGdQGsEZ^t^z1xRU3#7Ox7Scb;=v#(Jxa@9vAI<tJj{$7P=9!s%-p8DCCA
zH7)Z!5i|^43PM`IFUQ@rhuA!0pDxw$<JU2ttYry*1{Cd2%Dsj?qng&WhuECO`wnss
z6LeBk$fz+XzPnpaIZp}w%T+nO-BkCF$S(UwehO30)~A|_r@n*U)bwV?=Mdb`wD2KJ
zWeXqqHTq7idSRNDtHrmk;M+{ee0(VK{}a9)T#)?`@d~igyi6|ATaKOH3BFgu6Jx6>
z1}%7MM7)0~ZTfPwdrISpR?(3{JF(FK`6zZKKLyj7IDv1Qvd$f_9ebdA2<@p<ClY9l
z|D*6x*tbC~N=(v;jZ!$yfjI;G#u8;68{YAc>_oJNQl9AI`o9}A56wkhk*#q;bl>ID
z*;iycbPsds#E3_hO0li95%IgmrPEhrvro7OG~eyg*hjtez1t$@eiZHv7V(THW;I}Q
zJQdn(G%zP9-?6#++RtDi&}(_#+yZ(^goG3HasbZvFE^`x8<#jypY)HQd5X7yc{r2s
z6ihhc5XJ$z$HT+@eMEN^#^O8E-6U-PP#Uwl?8NscL*CN-3_3j1j}qT2;`r`)jwt^-
zv2yMabblU8R}eA7vmlQ*kM$Y^TS6-AgqTCXPx$#kk><)u-`@n@*fF$!{}Qg~p@Adn
zi~7&s=kFeDU-z2rcGYVvy#W26?0bKZ(<z_!*|Mzv09FOh!1tT&JmT0kVd?5?=bi6(
z@!`BU)`(4Yc%%sOkeu(aX(&3w%b1i`;2{zXQkQQd?+|9jsT{e^^dFR7Ix>l(guhtB
zZz@9I58r5P^L2}dz}(>~c06Jq<#~fK%1^d?DbdnCEDObI$S3$yJxSQe3ZgthMpq9d
zp^URc`64~KbczkHqk6W=6%7Y+5iUP(>mZ&tZdZ<qI-S7{oYZ=x{14Xh>k9N(e(sC!
z2JOR1OY&Y;U+LOS`iUQcFV(b8|757yUl89h)Ye*KLtJZArI3oA`?DsUK%)D}d-31b
z=4=Vr37aebI41ZQXdmIwMjtd~J&FG#ojfae&qchFh@n0`Pi15w{*Qu9<nT`J!^5ei
z`l@FhU*E5M=L~E@v_bo^^fnL9O?}P-(Z|L0IkqjoN0));&#`XBJ&^UJIk0ifwJ$}R
zZ7bi)FW*zO>bZaDM);yN0Tov-%*>lz2V5rgbC2dSsbh^`#$}!hl(_;J+GW~&9}~tm
zkb(Q<7c0KPzAN^FSe`gILb1d5qODM~C;#$z{P%*>V@Q1;i|_Cq6XiB$%n{oW4OA3)
zC@q*kHhN_6yK2c)&Yxk7fyKMIg=3}Z*@H*L{V_B?5@XsUM<<VA0|@y8;t?#D9Rj7(
z+V_k#K-3G|N;WEoRtfEbs2m!1&8UGF{ic0gGo=Z!>5YD4b`3T;NJC>$-~WQXZ0hjT
z(8dSyCl7{<Luvc>PaQ6mn^+3Ne)5(WSJA$@nUdUBM>e=d>b9_kWvFR&?<0NxGGv}9
zxkA%ejp%J+o;Rh~;<1bgT5_Rfczolw`)_DtI-RfxuW}Y|8r4_uM+Gw+%XBf0)3la9
zTgOZt$64QupaDk_XEU#p7{?i2Ei}10Ca@6HVS$@{(ZAU=@??X&D8}kdc?865paVN<
zzODAgl85_0Y}ZG^;vdt0!=~R*w=jk9XSrXC@f-M)M|WBb@uc<okDz`q2R^qj;Z4uX
zOdX<4zqDTeSNPt$Po67m;`OC!xvan6ZGXSx4*mTe>wDXxzt{c_dTLKpt|(Qk17Yvp
zQiZxIv=bADK2FJ{Z|b(vp9>tQ^aZ}9m-3VBUjnwm_8QRlu)PLf#`mzj2J}6+*MRub
zcYeS3oP54lluO_F{a$?6dl~3Ezu$Wf;{ukGzVrLN_%7%fm*jK57cuq*js@|{eanci
z5V`r3pT~JmhaJ8*H;3DQW*Y}-rvlQr?%$!))cTqs(U^S#@Q-ptm}nQKcE3o_EaAo-
z%%n2T-w~6?YPP!F?nB$ysT@*^`QIBu+i0l^G*&1ElH<OUXcqzg^e_whI@)(;#_rEW
zdvNJm^!_O**OZw>Gf^5Fov+5c#?JYS*4$RNV)Mw#<aveHVt!-iGHlIBHmSRh`HRSW
zjung_ZDS4td1RG`KieZ>2p@e3{o84+iss^p4pm^$om)NS0CyGZ<x~&XT)PMT(QekY
zt|wVOBz@8Zx`sp4IF7H1>FJg@z9`4=M0aHr-4wr}eATrtf*kNd-t_#qH-3D4dWH@W
zcqebV5nt*21f|m%3^$!_$ua4)$8jiqAHDx5^V52Rn?8R0q{W}sABWPx|2mcb!C~n?
zvIi6-gPgB;xr&Q$pRiXxgZ@&invsu?>0~x>r!mqibxK?j{;G}dcdERr<uhWeK)#vu
zwq%-~kxNY4ue=lao&dR=@<g8{?N9OSU3RRtA-W$pFR`9NF{|!>d*Jnb;3Z>b#Iu^T
zF6ihi1Z}i@pd5YDjT*S2w?=Dn*veIJV~Y-*5v;7_k@Q1*Z{EKj&tz@T+1jhFEk6;=
zbF*@(Or2BV?+=jQr)H*(V8BMUlJpOh-^Ujg=B5uEll!qAq0+99X=3Xo)i3eCQhu8d
z3khmgno8yL2dQ#q7if$8+|<FTIk88c<#@22j(l|9hWKJWndC0b9i=lG^4tt2;g5+a
ze$a9Lt5x|&k4QcE`$OdS$)giE8Uh7bo`<^Mz5mDF*9XW|opnzjK-xl^P-;_(?Y2#6
zpt0TWucm1>*$r9PB<p4aDbfzJ^O0=X>}+ReAt0r(#flXxR;*aDVnwBWQKO=wVns!b
zl~=K%M#YL1E3H^j(;91R-`{i2dCt9e=A1kC-Z^vc_Er7>cJ6bY^ZcIkd!F-o&z*fc
zz1=7IM)kg^;rXtau`8rziK!}ldT`Gad5#L_wF`w0>G_(R|G7M=O7+vTvjWd{vf08u
zdVY4`xi(+xUK@NqI}Y2a?WpWIfoIc`jEnfQHn(ec|LEvWq{AA%5i>f9%VB4(9$O|E
z@;S-8(jc>ArGg`X^wAMd?wm$Bthg;rF4m<K<v6KNt(dgnY`5m@i&5^|g^#YD%}@4X
zoGt%8J4b)_W1cJjUPpiL5U;cd9#EMV&~LO2Ha5F+H!!j63+eZXnHhRthPXkp=hJUj
zkIhVu$#cd0`vvs-fxTDl-FJ<cD{%em>G#PVZO=vG?_piXCi+`#46&}Wj^&PtU-62_
z)p*s5et#NuW7Pll{nHaW@iNSQI)q4VN5A7eH2FI%>gqGd^4VGZY!B9r6=As?-b?e!
z?Hv>A%3Rl4eugNz0+kU5sjhSM?|A18TkxtF#wzD+7`m8j6f0f%NpYuqEidi}tky<H
z^ZT*fhy;W+CVDT8Wbs}ht+Z*`r6X7w5bG}iaV@X%SU?^pL~p{4<beXL|7?SPb==-4
zzqU!f6l%{o2Kg|1&NaxJ?4g*-i+0^Hxp$n7wjS7zwg0{2NM(5CW8VS1g+`vHHX*sQ
zay~hnhS*D+nRt7M`aybrw*UFegghug0{DmPTI-kDfnCeJ<6ttKub}Mg$(`euV-e_*
zQl8woez}Rg<1ET@)JA06d49P-y~uCVctdaR?0&M7_(k&T{PJSYdkU{eUJ(#x*%$a_
zeKz=o8UG9YvInTs*g3Xy_r&<lebaPAMEmkZemT6dCEMg%4@~Tz)xJF6FSB!M41LhJ
z9wR{)*Li_oj^ooO$T(i?mlI}Dpi|^|!mRTpep%tq{cqn35EF6_TGzeaF9#SwDbL0Y
zemSA<0A6olR(O87&@U%NG%J{gFZIiyPQNC$|02H(a?k9(o%^Pg52+oP^DpzuVN|e>
z8UoLmSKs7+jyKRIcTG-=hxqvAetB6Rz1%i6HMMW2*uD4Fz0of_j#o5P-HhQC{^#T@
zm_}90_nBt2jTign#ETqzXMLwJFpdHRQ7`l0m410p0PnfXOibf-JI3Xcy~Hmo`U|`l
zCC`Y=PO7u=Z0|SwWhYf9=21)g{8fHAnMEk^=-7C*|M|?=H9oVnOqX8<?R)U;;}f$D
z`RX-(8G6wc?~sn|y<&nA0dwiKewm&7_FXkOkw-XUH0p8SbwQau(|Fx7KfP~iawm-@
zcTP-F=Zb&W51WGWQs;qbdN*@FNpd^9-XupaAovCVEPJU{Rsy5?S@sQ9*_jD?ciS(!
z*(wXC?wJ;{jO#M1EMA=3zgyRTxmAv`_Z2fZ8>RjKM!&4`Dc(oiMK*GbZVAZrP4liG
z$LP2CpYNxkIu6OGw)D3T%fHDlkBqh-JB?`arXno=X1{z;zj$+d-!-!RnN!_<d68!+
zDDjRwFtN^_fDFA$7Km9+%-W~Det8iP7@*-D|H-|3Cim}=15R$IKELerfgRYL+>N}=
zvumxh-!G?L$_(}f9;XNVvitW>9XOcZJ9hOBWVNdVc*ZptkfU+uOrGP{v%vGiP(Xg~
z<gQ&4IEmTZ*RgMh{qlqTJMaoUjVvj&#5k7v_J9mj5s8^gBmVLzB}T@1`ev9M7mOO8
z_vq(uF+P`T4OI75<MTdU{;kI6^j%I_Ki*97#%kKW0sZ`K#^;0j`F7*;A^m*J_<UGD
z-(h?{qMz?HJ|EN1$BoZ-=;ss0=R5WDUB>5f-a!7n!uXu_cBKDy8=vpe`DW7iyr-M;
z4Rh>DvrLa)<|?y{SQBDBQ)Zby(nIs3_W%!ex+bS-(s)&V*8yAtL31kleU12C-3~E6
zu@|EbVIMuieIh8ccj6kv7T+o|aS%xi9UIk6GG_~!eN#Aw+9bnutd)8&{u5`P(Vxv?
zJyVuHM?Aw~2M%G#VUHZXKvE5-5!PZ+M8-1Jd9Elkagch@sa@zA>CB=UFya8_o(Y_8
zCB)QLB!8ZeKd^WI*e={DurEKhL%i~@eXvg2H-U^WGl3UYsW9Pt5M}X3Zf%}IANd=L
zI%7Nb;{p!qIcFxd%!`9E;-&<iXR@A`1Z8&b172Q_AwN-F7Y1dn#cV>@_(g4pD5hua
z)VB0&jVLFcjqgR<@b71NzfVqI-LHQ?JMjCUxJ!iA@iwaY-Y%Tz##Ql$<S_)g`n0~h
zwL(8)`69muD{=G7SYDjN&${foNM$FEF5&drA`Wd**<G-o>V0pdvg&#f6vgW=H{;BT
zRD~8|J-K7=lN0n70I)rXdrF!WjmEOaho#{8;nk6_?8h=Db~EQIbz;~yRqx9qmDTm?
z@?<xyX?;Cj`6Gqp8-(w~n%S|he?40Hz4G(~Hbo^3gc`hyCv8{@J<-~8oX=r2Xu`cD
zT30T&Jrbt<OZYq_R*G@OGws&;4BO$;l{*%N9{Z_Tu-i*Z%}^Hb5%x0P8%GC|RO;b&
z9tgu!s^X4|a&w^hc=DoX<uy@6u=(QT>t}~x@YgTy^J$I~Y9ET*HOJ066HSvX;ymt0
zw8@7FL5F`hX5SXgCxO7@_UMmRR@cpeN9CunfAaP7B6&fVmk}d*PUT-nv4?+N9nB77
z0Pa<`u&$Rx(`6098Lf}JOzT*YFxmqVI*2!f_XWpDBmOxSO=nX;qNs;gXv#ew7MC8U
zIk?N*5pi3*3bwsn^rdoKEUqt8uh&ow)Q{71Ub_^}<&;>=JJ9Wl@dnB8`lXP;^l4@c
z!v##rxDH;s6wjxyQg8qZ)4uY&W+|T2XhIDpxIC{_is#c<uG4oONgH{MQkEaX)dB}6
zreGkK=QT-wjuk7~G7#efvY*!>#dBOS&*gZ{QI-?;L195%t|L-8UTYN3m2Y^di~Per
z<n=}&hj)2+Mhp=x!)uM6jM#OfDV`V;QGLA5DD5E+%RL5q#_NjW*`&AvLCi<#8LuUZ
zXLJczp4yy7hVsri(nE7xlI8V8X~*o06cvkK;!+m&4X-B(xr5^~xC3tzi_#houO*7-
zyts@F99l19zwlb3keR_a6kB4FIi5Ydjwoa%akJYb-cHi9cuyCvCki>SZY6H;5=`Ry
zcn#4fquInVymlyL(AX0*xan#?4*O$$iLvwgp^)*}OwY^k;hNm^*bK^GMQ`8UNnBZl
zyS>QAH14J6XQ}7AW+t)9IwjVxxh(FN6J@d8iXk^f;3AS_-Bfn1dam3hH$Z*5&r#34
z-9^cBDtoSah6|W*37GU9{eGVMU2qpr_hX$57g~+c?kV|&WY)1>T22)*EaBPq0wqJu
zoZp3IE@eDpd!c#`Nb<4b1C8IQju)xtg7m<|zn`yu7mEsNuaD#};NP(kum^h}EdOHu
zeNygm^Y1TFzmM<RgY_M+J=Uw=eM`xrt*MR;tc%-26=t0ms^{zt`u(m~3l8i*fE)dG
zjnNHY(nl-Mw<d?Zh?%$J6}0I|_1YN%U9Q{F^Rv`*n%3p_?ZT@jlrFF`jf_ccK{976
z8MP#h8zS`*x3HUJ);7rS+>7j^=jW*BSQ5l)$Zo++`u$w}J0_$^6P%~%*?FvUY%eWR
zO<tkasi}SG`8xF+DSSWOV~I3<6`*U~FHp}xFu8eyXN>8E-ZQmpG=bT<cpX5?yvUQ0
z<&ku7?dS9~=I|6-WW)J>8-$cs{{>!o5nhCi{qbVoGfbOxoiFk0+l_fQUSQrOrvFm!
z=TRq4$d+q2mTO~6OSrX0zPe9(U)n{_CQA$D{fAfTIK;Uq@h*!pyC$%2ID<x(_kNPC
za*IUNO)_h8EJIUcI*f2NZ*_=vCYiIe3`I>|Y+;ZZY7=^XcJTRrS_!1*l<(;|&JHL$
zt`S>`SP{VHJ60^P)=PaD%i&xA%VEi2Czk1_4@~bF+l!uD9HAiplfHAc+z#xgT#YMN
z_iG*J>1SA%5$BQi(6y{`56M^8IxR;LIkiW4hF&J$c@^~}8ruuB9A`_q_f)RelPxdQ
z&l!}w&=G4oa_`7j=ZmzgI7~yE1x#^~#n=z$YdNixdL!=PblY8^<**lrWpkgaw9JdO
z3_HQYNb5y};U!vT_bl!o;n7i^J1$z{;`?DKmZ;2nT}G?`QD;B9Pj&T-V}q7Cuy?1p
zFKwJ~Ad~JCG0XK|sO7G}#k7>UkpM*pEV4X03Q9iSIz83@Qe9?tY{w3)GVPezcMWaX
z!rv4ZBy*9L5sThptU|xPO#jXtQO!Vm57=7APN-PxC)samlBGkw*gT@OG&B$GSD;GG
zzn5!yc~LA{23LGyBqX=+MGhgo8?_wH`jFe9<8o#9EA%tAZ+2pe?(F3z^kKYM%kIKj
zn->Q-i=$#mtn=eV!s!D-0rrJ>T>bB`18Z?JQzG<59DqZVBIJ0Go?{(MJ;$qv*nyis
zM?-N)&#)Gzo{6<a(LnqR>tS9wjJBy9<%<uY-_mtrmC@II3BB}O*GbQJUp2J{C5TgB
z67~?)<Sr`pH~XPr8Y3J~M2~UaA#hDkj_=t&sr;@lWG4IQImS=H=M&cm`{)_QPJw4=
z=c!2;LH5&gjGqF}$7jaqbxRR*^c>@-z;pPXw>h*9jG+QDIFUgr^mB}(0?%hAuAYR6
z`Z>l^f#;}UA8ou5_rDAqa8Bqd8h}siJwWc$zvG;c_+1@0(!b-3koaA_ZXw!&^x%Au
z_+8vjxC^&VLl^mwp5c6ucm|dtP{lU2)`v4f;@Qr9Vnay(ey;i*1J*I(A=`VN`W+W5
zi-5Wib$kcvz*;)aI$?tyGZB)d->`<hGrtGdNsnOwiQidP{H}gvS*)c)c1+9i?^r)a
zN}3&~%U;<(q#JAJJ8>QGE)0ppBbLYdION|>6$a$74i5d(*C-RUjadH{zq5^`=iShc
zl~qcHxSMzO0NGByq~FmG)9=&ht(%^q|D|Ub=<7$K9x8{vS0q<#Jx}h0cG7o)s0Rns
z@>pP(`~9Nb$Od}0CP&XGA&DZwfAsrV;&+Vru<J&$MWKgoj22Ca`ek0A-`C{y?_>b|
zA?l`QXL-+1k$9w^o$WoN@TDv&;)cqt^`6m9ypua8XEE?XrvhBm#>a&{XoNh*5j}(Y
zw>3HSo489t%AF;CL&Kvi#qAMMRt|Cn8YJdD6MJ^hyVcaE(Q|N341y)8F%+7`xI>C)
z9pIQJvwvciCVxDJAsygb;5pBccu>W*fPbDGX8hP{5xnB(;Gy?i-4f4Zc&Z0{^q$NA
z-Gvj_A_voc?#C_yaJjzJe14Lyci7^co22_=K7lo)yDlL6^Z9G$7iVVot<?8b_LPrQ
zYd7mRop!1_@1U99Df@ZY@g)8qXSl7O6DQx^1Ub5;l&01@#xQB!gZawjERG7`G=ZA)
z9>#aHmA&$1LVPWC8M_+vEBS<;tFwaYIh{k50#wHhUU~7UBYfDKz6g`2FU_(Jl2JNX
z1~1hXpr<bS7oQDzyip^rsTdtSOt;pEb#>B1eYDTFMmfCfxV#Km>a*;!c#)glslr*v
za5>y_gV(h77WTHNo7UFxS}3-dNY<_sXUONOEA&P^;UV9dZG>F;Xo22s4wacN7Y7DL
zgl#vYo!1_tIL2Y4owEn!NSKDXcqah+igcg=RfgLp*ec&;3awXM8&nOqja&kl_BI2?
zWx36P1Iof5c3JG+-HeOT;k`0_Vj4JzmuBB#e{X47;Pmm*#}!Gx<@(JFq=#_Q+P~tz
zPp&k7h&J^i$j~l0wYgaj4r}M7uGVtAj4Qcr*T-^l|2?E`T-V65p*nqXQYZP>Tz{=l
znm?-BmCq1U%z{2DZi77Mc(BSUu5<fa<$V0)JZqJ0;1;(tpJ5K#>tXWcI>808O>D?U
zrurLYy(}a5`iZZ8dmH7wY$LzZ(Mmp;b-es&tHa+aCSUvQfvn0dk@Tu)Z;i7t>d6jY
z-_Yc9f3z~s{cY&CS+=6bbLEFc`Edn&yXOdP{8I;v?MM~g4ei(<OSh6jmW-C^Ow3Jv
zdB-ZRQly9zilg)7c)%?0vxQ_8zA#x4q=WFCk0TB8(&DaW2;!`Y-KJnU&Vp2z-8NGh
znMcBH)Gt7JRw~DFeQKYs0b64^wo<;oVz<*=jx4415W6qQyx}|@7XcNxX$2RkF0+kZ
z8Mcn<u-n!sFa6iruAae0!-&&V&w4B8R2gL$+oj&WXz(@J6_6K(wYICT*Jf9j)h<=0
z!LAoXlaFARx-Hn!j%I&(Wg6Sj?5{?7*^c3P1{VR;6uVTS;WkwJ-VJTS@@$dJyVT}p
zn}YIWQMf(mXoG1_=P|XX-(ZiFXKUDYbG!LvqxgpIISm>^eFkAQ+oI%^G2ylZWFzng
z?~N|j2m6EO=scj#Y&7`BE5rWbc)QTZ>qdF$qtVd(r1Kg#v_DOWclzx4ps6gIsmqx;
zWhn=9Bj$WfGES)M7ju5l_4x^;Z8USuSVlNBqKzK;8v3OcHU@}Aa|rIwTG$yVM}|gh
zcaJo_mghRR8+oRE<CRq{PjwPsUK+2Q@GHlgI(yj=3u3f}=+P9@v7_G23zeq|m?LIC
zvi{(li_07{;_;X9=1T0lOCy&N@U?xpWA7J-fh>TI_$FMM8@XeD9kq=1wQtOVxM+C4
zT&y+qz~Az{a&8-SUa!G4eW*w`4$GVSpaywZ#D3mj^qH0qG!B=^tu;Xpl+lgDZPULd
zav9+-F1O~`+47v9%>#kf@nUz)vH$zE@EU!s>hp)$-xTUy8X!BJZ8ZDbR7OD4=LXHb
z50(ow0CE$@ySWXT%j$;kl{L48y)0SH_1fB_p|sDr-Z@KKo7l@re-XFei#0Q>JMY_b
z#ncYpox#}7-G>_##mCR`yYTicEe_L|<F~vu%sjn}U#QJ5<1Rv+2q+)IQY~FfNJ~mu
zmglJ^Srn$5<g~2nV~u)m5;xd*dUG<qjI#L1GI&M%HMk?Yi|((&c_Vx~4SNI=baw~c
zUqyQtv~fUd?PM>>Rv=q190~}NYze>XAC)Zq=9k6KLdW&;_pzCoF}ziXO$q!%I%sc)
z_HMAdL7xN?ztNrp$*>J1_v$X(--W9gxGdfO^-laoyN>i3OOm-3f1_@_??JyE!oDSz
z>GxeVA+^zOFN56d)Z`Aj3?qks=r_`ZvaC-0_BQz&ZOH7O#RfLXT`GU0JrZFG{YLfb
zN^?@~wfHZ+bH`_I$X?nf!H$S9gvxyywxLeF7el|%{vDNJ?BxFg&_6kWgrqHzcR`YU
z{1cUZE6LHNZ$v88Prs49+F1NXc3eVo<9Lk)%|J4*#^10*yO(|=8T`g#LT(tg!C1Op
z0hi!P{TD+{T&Ybr#N}jL({H5jAl?pDKZ|-V#B<t{r1NxC2mLKKa^#ssvh8isCp&R;
zO2|-KL6>eW^2bZ%Z+x&uTysZd-wl2E0wi`_X0We?`{NLkxR-9WcJmHgQFz0i!qNn8
zLA+V$eF|8hcPCzQ5hNgch>PMkMMwIL+JoxnCZT$Keh|9OT!Qw;7hm{(II8<|#Jm0F
zcduY81hI?@7RrSqu#a?3!Y-V&K|@W^C!@u0_d%Xa!Kr{95EH-Mjo+wZ<|$#vb`ZBg
zp1(IockKQ1D`5lO1hN~K@-CEXq<uGT&!QE3x)b#C*5~4LDs|yR=qB5*B|N0d=ed47
zqdQC&P0z6OfeZA+t(;`z*SIcr3JR0n_i<TeBN~L%3cWvQc;-`!HT`uPHnPltMY<S|
z+f(bf$nqRO#7&5#;|Z48UtXG=u2*rrQoXDUp?d=V(e~VD3}N|?MvThY^z3I?M?(dq
z|F@0Le9GYuvh$TDIYD3fZPdTx`hD%qZS)IVwgICmF8qBy%TTV6H^<=Gm};eh`~7HR
zgK*UGU%`WXzI<4GU`~FEitKw8m-lgm^%KW?`1yfrgm<aT&fsqW&{XE^E){>{JH(zV
z#TxB@Bj<>8NZg{>K}`F@NAxdr?h@adI5fTg0DZVuoK>Lm=SZD6s33FSdH5Us4Q_6n
z5#{LIGm25(r?YSBoYJ}tk3*lx1v{rEr`5$6WFwug!SCu2jpXio@LL`y<Hx7+lRI(w
z^CVs2gj=DyySsbfLQ&5b$nN|ux@%IkSf6NzZ)yHr$1og+IncTdJHllGeiV0In&f@$
zL^hG$jV<K-iplr%uBi4EU3>yP<P$m@M90JExDtJ=nPh*Be9~~iIpv`jbT$6o_`wG8
zIXa=Em+V{4`xq|k`y6!pnnl>~OZ3|q9b=Q1u#;WX)}jq%a|^j)*h=j$Z}_Bhg6lSX
zn<zUa>ii*YcV9B5SolxKKo=dV6JwYibR13L-z)qmzRR{$FG(BE;<|T<Bfz5n`xU8U
z=NJycGdDp@eC1+F{QV3+KQJl&{+O`!03Dkbw$Jl(acWrVpqSY?CIf~rt2<KB4a$Cv
z+Ts^c4kx<tUZ?84p^xe(8{soyAeDU`ey8u4<3qd@`l8PNLRspw#W)WQPIA;P{zf5P
zIp~^Hy&ToK2pKUS(z~X#4~p-Y@$U`uD_-HIddc6v_X<@W+x&;s3z__EiFF9wFj#%K
zf^rP)(TRHH=8rm)Aa``hE-YOHM#%Uko$P<OT!UR|5+-u;_p?mHP88eq2l}}j)tB>&
zMH+}vzggpF4f@57lfwM_ETcy6<$SdUI*I=K4t~~9Ua!>1)jeS+?V0&};NK<_zWqb=
z9pX7n9;l9T4aXB?PWTX)wbjEbLa>Y4^A?M|-Wh-#aprefuDn>9FDwc>p9-|Ge^w@a
zMsq63A;T<5)qfkyG}y~4?GO`~KNF~nTUFNc0~Q@}^+)!{f6hLWlPI6pq#tgz=pa9c
zoeS7O`R}MjPPZc!*e30|-6Bh#f{5@T-PI+1#J76EKy{ZF@$Q&KhoXyU!w*<wd`&HE
z|DZ)q+fJ*mu#4*b`+&cNh5Fl)BtyRVA&b5s6J-1S4$JD;DARCX<m|K8C?Dt=r2ad(
zOanKxy~>ef%Z(OU|L!H#N4ZJYm!A^j-UW4<iE!5~dQ`KDHv4VnlA7rI$wWHdXVIbD
zE8>a9CwOf@4^Ait(|nRAlN58mkH5uyaB6;zY$utw;y2MJ;#e-p(7c2Cbe?*U4D~xg
z23-&3%(vk0{DEL+PComQ=HHE-x#%-qMe7Y-|3klh3cu+N7533@G?zl3&oc+{+dXWL
zn(&Z~L-IE<T_PKQ6Fv)03nX4Di%FjNGB=f@{0~23!&dhFqxfO}Ub;(Toj99LV@PqP
z7AK?CNp1QNg|LIh26DnEXK7?F&CyUqPt&Ll>O4^gg}v}OUQf!YE?fLfcZ{oPr}+Cn
z;0H{2^}O#+=oIayCX|G)8#1UT(1}xBG+!2zWz<1`Q~QD!Z^xg)=8u4D`8{)D^iFnh
zdp0zuC`)%JqJ<{tXfpYO&K^$V=s!+%&dlcb;q1Tuc$U!pFVd!+IPQzr0AziK_&0SA
zBKe5MT!K$(*hO|y`|(^?#1w2BpI^p(#kknGwo`tXUfKH^{8s_TyAR`HO#MRWAUtR*
zVaovYVf<086%L7YHc_v%MU#%|{a3aRw`kJeqHXr!J|Eamf4>$wr*_Kq2+~1y;DX=M
ze5E1=MfBU#Qir^t5zoo~_4p0^ri+g-3Z}Wl#26j$CV$fy3i$oQC{b4zp3``X$Vhr=
zt^+yPD_4K0ER8#LjHp2;$?nJRlLr=WSQKv-N!y>5<<b1|Z{n5kJE%qeqVL+$>!GA~
z1<#1<;*B)<#WG=oy#HPg9|bnLcZ26QbVCT{HN7xh=p=vc9FyZ!;scX`@)*4rz~!ze
z*LPsfE{Bb3W<-9YxJA4-hOY3>&!RlpPh=*W>AWiatq-i?cWN`@2b@MRC~P7>kP}Eh
zy`zOPzSpzlS^$;Xj&i$j2iz?FOZppl)`y?P?**v?FTd=??9MAs<8{QIxQ~_Egytn=
zA17tfNjVO`=_VwdWY=#1_r&g*@*%7Mp})q*V@bDs_E}lxYJ8Ibzn4pDSS_&9x)m>4
zk^WyN{{`liboa?Rac-Jy(T9;yFWE?IkYtZqh7`ZO6FP7o?w$#?SVwYy1-VHMNR%ai
z5r0%zi*l4(j>y!aV}tUPKS`0U3-KGKU_5ma_-Sp<HzgHI2jm-)f48(zFGCX^nokCM
zAjv<PQ_+NqWM~dZn0?bgQ5U`Y5qv8H?|B`dGxKt8B+B@Wh8+|y#6Kb*$<duP%w-h=
zA`g+hlq390B=p-SAwM}&E@E^ovN-)F{7fqVDz8(HrF{m}e+8EP#-<R5`H9`Q!WP!;
zm-W&&#KpI^@HHb`)Nxp@?#cF`^;4C4h2Q9$FJTdfe3dU(@L$R?qBFw(lb`5LVaU;C
z##nxpSMyN&()<#0N%3YU{Y|-?#u#*=EtPAC50L}tcY0S=ti90N%WCz7$}gdxQ&VqY
zAFb=7UcIzWGBo!ln`tA3@At=N7100SJ0=SYIOvWKD9~ttLZq9<b#Fkggzp-hC1iHZ
zFJR?yf0@5gsE@>x4C|XZn`G-)1H=)HN_BL!R=5e*ryQY<g736{RLJBfm$e4@wV~PS
z4*D_|c1~^<2a)+M{}QmlM%3K;R6c+EfxZciGWoI6yH=L#-nYT|+X%OxBcF@<R*Llo
zQ#76@&y{jwHA!Yp=?CE9?}=P@o|Hk}oyOOEaWeXdR;TEv_1&{h$`<8!9{r!l()v!@
zWa!57I=)xt^Y`_*gP(9N)v84t%oevR(f3mzg5TwLFdkJhm>J~Jg4k8Xq{XM>5`0q-
zI&fm4%-?enS2R^Cw7<7*!>u%~5ug9SN1Cw8o<CeJEalNtZ@sZPU)mxcf%oMa4&Uc1
zwQ^Z~J$##-pS*?2@5BoM^c8WsrFaS78ye~F9_T5RhVpbrwfw%!E-DFd^!IfrGq!-O
z1pFYz`WLYcrix@emxb0tcTdYWS)vI7^b)pft=LE?92>>s7TBe}^~SGJi})KuE?Fw7
zis0)VDwZC>|GzrK8$B4+FBFc<l?sTT8>=_KQ^iubxBypb9n*-}Fde-iI`}(N&qy7j
zRZSip9j&63Xq#d4Wn0yRipw5DK0y7^$`VCj{I!aUmmu~7Wofqv$+jr=aq&5?qo{20
z5HU!YCF<@HH}!XIAv?M*-_kh4WxMFxIVRoM4#HPjoAr@TZ&P;NfqcPb8(B`(hA{z`
zml>m@RXJ3z>pzTqWUIebl-cTURnA}kZsa*z{jG3}j^38o0qp;c$f36STj8+Q->M)S
zFr(W4*^v5M<L6lEq9sPH^DgA^<d_<D%D#9Qxg0vJ*%bLh7bN&ymv?PO<4_8@{Ibn@
zH3qSD8SIogpKhTO`6Q^*r%}}*0`xNYlk?o|=u=*uyT0*rhcps+!|3Ssz4#aBIXW1{
z`ZxP^48JI{4*F<EKnM5pPYE5qT&41j$O(8?a<6Lth4b5KEB=Bp-9;t)+%CLFXlwh{
ze8NY`;7iu^NQkah6dxUxx)|rd7q?><h6p&qhEHs2znu=z*V?vbefPYi9sAS=k>NYW
zJB)tV)()-h^Yk&FPAYw3EXAW-?!8d29us2ZO!WrkN^*3IS77KY0*{%uVsg<eOPevC
z%x267n`Pv{T95Nke;4W$yJOzB>U2F_==1e+^|f98RyW&n%pk+;W|^n`GXC#&`tTpb
z7(v(NmqAa7Z+8}P<O+7l{PU=gC4=)v%14SzH_NYOU=l*_4_>h0DAwJdgzm6+Z0Vh(
z>+wA}%=CE-OAA}`i!0@cqxcrJ`aC=8lyYmD<@Vz>*dknxvG4^OXfB5#fp`~Kf9qL&
z=9%V_G*|R}W>KC}n~@)WqWR|v3Qr%vidmjcOp#8k699*=3^q`4?Unjg6z%WqgZ;ke
z^8Q(Mc@f`LKyqcs>D57XO>KjisPA2(zTN$KOkAfYa7PHfOvQR=?D`Ho#~j%IT$EeJ
z@4=sSF)=rNd$V3$u0fwJNNd=0Twe?0N%nfKqlGN_mD=4~E)`#}*|#4zn9;!mnmbfU
z7hJt(a<6y=U7aap*J~agM?1YHcQqwAOpvDV?c0T&;=|s{-dw5<?!P9dCQ7_S&`)!H
znfLF+^VjA;W1Q`PI{bdYhA+at<H+IkUO9cxn}4VE@Q2jzcu`wCxDfn&>FY^?zG6LF
z!{ik@<ZrmIL!MTYKMO9uOvujc!{sKpN?d;A*?X&;^3i$X4%bU_blP<J=H+_%NWNUF
z;RBIJFki$9E|S-Z_l`N;+4=$Oa@C~FocMH+5}|Lj-Lol|>jp-FrC8J7_{|?#S*Xv?
z;WOIulfWeVBxI*Cu56M;A6!^af<Q{LUx4g`*pJY%JV7?do(s&kn`9eoxER=94q5uX
zT7hgWA4Q6x0YK{*r}MwB5WbaT2YDn1cfi79^a1wKQOvmU6|p18@E{8&Yo+p0V4-u=
zRF1y+MpZVK^T{i}Qto;s%22+fGH5Ark+7Pw=nH*GPJEY6-0O+Li_2BGkv~=}*Q<m-
zS?+7N{Zq^NvoNo2VXk`KhHsYk;tnZXMu77C8~ir8?;6~WH{tz;Z}?5_J3yy&CbZl-
z`fWm7y`q1^x0>;r{ALvE1HQ?9J7;lth2lciyPba9aRArm&*XQ`%wqjd{(j8&J6*;E
zv-Gpv8m|nlpST*uy=Q0np3Tw|U%9p3GjWlJ4{L56p5X}c9$Z1g_U6{(H+52p?ag)J
zH=LoRuc6Sr4SY5~ckJtmWa#ndtN3amEiuR|uIc|VJ}uLFN-yx8hZs8xZD=jP8|tde
zYY`vUB8NPOaymXhI%2c<a3OF|43W&~piCa`G8b=<#Ai|DjSDuMy%ssiA44#^x`NXk
zBH$^9NtuTlWRMoL46W5(3hrRf3QL~!VWvEIF*XKs&>rhHyadk_MsGAylh1ma%ZYCu
z??O4s1-9rZtzd~shR~sf>Re%AtCaMmiLT2rvG0W*ibI<oSvVNHSE3B%7F!ux-NCdY
zsu%s??`Ry#I(!t1lP&eXuSH!rQ_P=Y7JlR3>1rDP16sR!4g8A3m}qp*hja~$-}&T3
zZkNVqQ~~vun>EHJmWne9Tf}pbF)d`4{c68a50jTTiM_`#U7o10nZ{IleUkfDW%K!-
z9*;};C2`R?`KAs&<NMWO@0ol^d0%ml5`LcMEHo~ozEyOeQ{@}W7=u#T71TjPHB1MQ
zmvCksGTftzjV|TWKla)a%aZd)xCbMjUf|W|&$GfpdQSbO<W-O@P%W@iU)jWDJR_TF
zAc1Dbf-AK=&9UWJV|-06_c~RIz8s4Wa~83&Rm$tL8Q!E=EY)u7lGAnQ;I;UZW*vID
zOcvOd`=A=DZ^0TH*V){+MUIfsQNNeA@=`#d(mPZs50*>ifzoi_++1m{G}zlaG%{H1
z8R;*N6t{H+)<M^jEs@K5&cG@I&*#>j<Kgl7knw}V($}<Kz_@Ew(dBdZEMMw^PkD{=
zB8+)hHoA|384Tw^{hzEx+)6vvVx5X~i|F);@Z7BAe{PxMJ!X(;oa1f6+Lf-y-&VlM
zKDpN><D27Mtax(?)|g%g7Gv&*@%1ejb<$ZbIsc>Y2nU{(7jK-$>oYXYLUrJ(lsnld
z7fj+949Pn|dEaU`)}R7<mHdr(VTit9i(x(bIjQ@2qpWIOzswe_CA}_JD=*<Cahj>p
zyG9E*)<-gI<NZR$@31_!)-c|s9Yu@_WdFJhAIf^SVBP6;*md-I#*>$IpzWpXI?NRs
zWZ^~6kGD2I4|tNl^?bTn&f-Z=_c5&VG}Mh{2231~2FZrk=FZ=+0XeV>`9zPmJy13B
z5zU2;L5Ak@XM@8_^H`IwRK@Sq(D%r>5KeT<7dS|M9`g6f-${Os>Y|+3jj;|L7Q*Fz
z;__O`v1jAAnb|3fBQg2IE+?*A;^XPMOx{<B=7wufX4+H;cPj2UK;MqUTpu#{&U~|C
zB|~-J0y{Z>--LFiZ92N4q6~YfKfYQ&mt87jq_Y2gk;Mj-rRTTlviQt6bjyLhoM(}4
zDnB*djGBF7v|ZUnK5H&X>*DBlbiLqbVBe2NNHo%wNQ5=mn~_h%)=kr9Alb7+>-76U
zV$o}M;Ls-JO_L^nB3Hw|CS^1V`ze((pY!Q+g2cArlFTi5?^x#cQ&<OM+<rh@o&Ps9
zpT>6=`eZKW2%lv`CmBE<Yut(cn(g#s@!IoSsC&=NDSw=QjwkO37k6{IjwjvMp%;yL
zjBy9X1BAPw&qm}Ret?(z_QU9xJ-O<fSO&#&*7KzQIUM43rcx94%SX{KLk|}IIXKla
zj;~L<So!!?^r?^)W8})bxQY$=O7iive73UadrCQ(a`k;OCl@OVE3{0F{CdHL??7yK
z;s24_MW*I<-;Vfuy#YV=e6gTX!fLpDUzg?SOp2Bd;0%^vJEsvhB)^o0k86iSpUBT1
z2tE^QZ~P2~>T<mP#?KCV&kDsOrG-V{;%CRbXG@2UU|8;ZwhkOuw%pWM?t0%dF336`
zmd~io_>r#fPH+@D>Df*EklKOH{M;|wfqxc#DV-~PK>i+(r*?Z#^`-15(i3NWlIwj~
z>e0TT->F{Ot3vxXVc&{2y;QalHKOPksSMfls4Sy@Z?*n@F~%DAgKLk8ax2R?BXOiq
z$5B=^#9s6<^o%nVt<CvY?V4vO=wbX@q-tpwn-5)=U$#y3-9Li<mES|hrz&^zx6pT~
zI5`MxZ%{RgIRtiF0g&eqTf=L>c|fIy`l)~(IiHKHXPeS<44h{@&GQeU5ihRFr@VH_
zdG}0c`IsJTn8>_S*?0;uWVbPP9eNJNx$=H+k@Sn4OV^hMX`<)9>kwO7&X-Xe#Pyu#
zuAn@f&}mey^Z9n<ebSAs08*zpdNFuUW4hDeK8=ItaFe4P3ERiWv~P9U7XP|(tzJDk
zI=Ty^+{r6&3L3gthQ{A=?ODt0#f9y&_|C7ES=%hL4=1W|ME4rRsjLg@x{Z2hg%}$w
zSBQ(cX`S?qunDVJQ{(x4SJD5`Iw}2zyNB@`-rG|;`S-J>ELWAQL7w&;-mB}PF(p<a
zmsYUGPM1ewGLXlGf%AvN6lwt*GAm1R*)uTq(?!JG94oJj%P53vA(jgBwJklp!&re;
zA7vtZ-xBbpzfR>*U|~7Wp9Z=8(^}5+X@lGp?k0df+KZujJ-;@|jg4PBF+=b6bKO`+
zS8dQBt6H6PcG={{Xp<59UK3vZ+ikL%C7$dto2<CnAFKH|OiF9d7sBQzWgeF?r<OCY
z!idvcB{{%{%$rCS?Y$0T8REWwOhls)+86Q-Q-mLgAN2h{S}_;<BRB_5Z_$m8s!O4v
zm-o5W9us>WO>%U}HeF^7QRu|G;fOz}ttbwwqVvJ~5c6~M3%HJ0Sxa-j-_vsM#>(@2
zWgb|Rnb;&Oh<PRPo!CzIL(q%5w5CW0XOZ{m!ani$OXc6<bx)cH{jtz1(5qD%yr6``
zF<Ac;I#0X-_F+Q=pMelBOpwmkAgAHAj(sx-cCziB%NfIR`EdTw3hsJ_b#UPVbvfJM
z6Rd$>s%45eAX5^fhy}4&C^iA<0%_`l$)<-jR(cZ)>+Eu(DOMe+{-4J41?)P}AZiqU
zf5Fo&_B^~0r1`rF;(Vc0SOTi8-eT{&Q1-pHvMwVYcD@O9ja%xXgSt5XKxbxo+avdT
zkUvPiH$<Jp$470eHE}jk&3NT}CfoyJAIK;#Es<wy#2S`(%QlhzF1bcp1CHL!W*kdZ
znHtf;nsl;4)ka1e)jVH0p|MqIVfKBf^O98S#4apHjfz>a;T4(LK&d2`y9G9EOxXst
z)FkSDdCGM!6~tBVm{YIY@E%Lu7-=q+=rZ~_9BT+AHicsY$wc6YrT<(7b==&+I*3t(
z=F_O>8B0A)d7wqu7!YwXv_zWUSIL#DR3NZ?bJU#HqPmd8-aeKP<&1^eAA@RRehzXh
zIS^vnBI-F~={MZf!)%lF{i~(EU^IwC$Gxe==VAS?j3eUrz-4AXHu0O{&sLLx-1dIX
z-t#1>f;mCsi7#7XH9^m6LnItW{5xT(D;6&dwQy2k{yo<5dOZI10@qCz{s9+OQ5vRH
z7+dW?nV+=UNF(%yL{3MMXk&!gi#Vh4)-B#RHZYFt91oqcLhypd!#^L#7d{_cj<PEj
z-&0)R10-1Dl4Fa{K=%7B`LD@e$y1;)+AUs7UW;$6TCwCJd&X!{Z8Q6{$Em?+oH(6o
zo#wIXp3H3U#;Q{(+u$FoUX^m)JXWQA_b0ZPqXp{4KtBt{$T8uWsIeE;p&7<GuKP?|
z72IdO7WlVV@QZv8ywtB=ZINjhlZdtZ#n5rR-6HZWjklh*_|~2Sk~mqUYrJ=ddy-PB
zuQ~GRy+5o$Wl+D2`W)6>*KK$-wfbemQ=Okmtxg%~#H+uJ#o-qHih;(egjjf?@!{cU
z_0jra;)o$!J1n^~Sw9`#VbU1oO%_}W<;6qw!*tq()<<h%&26_uRwfFWTSd-Od1kAH
z7Zxmu1Ah=WDzV0C(n`vgw03V=7u+>9b_M6Km3TPXA{%jS(SoHRKeyzXq4foD%9h(u
z&$X6%<Vw74oG*R%=P3U^3s>WgSq*k__!-Bn_P(Qq>q9EyK9t7dABj45NnV{1mnANe
z*P=jCTkW;9b=<ZJNtH%SiQ6iqB5tcs0oM;l#TAxa47?C5HzEqI2qaO<_S5{*wr8@0
zsdl}h-evGj)A@xD%6ZpY^09eUU&bx<F~1t_Gqnv67%N*mVOS3c%*f;z@D-LkVdq9N
zuTs9IG1%ED)n^+6<}#??KL-4|rF~ud8=LRq%nywLzm{5^atuhZ{|O8Kn{rwhoeX(K
zM2dy+{#E=WYB~1jVE=bn?2n#dY{tv^5RE0?-@!U~rSU@4^BHgNTioINCj9mrq8}Ce
z;c_b#@2TRPeE~=8<=!miU9rV2&wsxL@k@7Yi4AuAKk4`by?<@otIwBkf8T<9?MLi)
zzgpuh7H|_H?ufw!Nr$WSYCg{7;{I&gb6n#u3T)N)Y4A0%V$c06+KvXjx}4aa7w@S3
zTO?WB;y}Cm3g;*6Wz^9Gn!&Hok$Z7Y;Bk`Yw?w@SQ?<J<&nvtEW7`Ve7N9qbsEx?K
zH_4+B<PNdlzw?dW_*b4RD$)T{Y8j%pT&7&EuGETUo!O}@`SO)9%8HmmxmTgwuW796
zOaf}5Q$1wV-Zk=^>a938x7j!{w~UgK1>@+bQ+1ZpOQx+G;ShBR(xqE8>C~OU`T>cl
zKQ7llszWY8f_Gi2?owhgvA#8<{P_UR=9&GOtXHsS9%KdUS%hSbwA#Ens(gC#9Gg#F
zWN@66i@d*XZ;jRFyLT$zJ%66fcb0%`F$*$yK$XA}jy1~LQ5wUu+7f!bzm7n)hP#qX
z9`P0B-z_h+`PUwu?RX<B>f6z~I=$@mQ%mRD{2Ywlc6`v73EI)M+WmPi-bpm~Q<l6C
z)}`3y^&uG{nL3+Stp>DA1g`r16F6sU_NP4$B=bR721urHwRx5M{nI!YZT4v}=98gr
zjP_(&R-5m*-(Qb+Q_a4!#CMBiXNWLWqK$q(RA~&)YD-#%yOM0b-=BK9&A;||Z_mY@
z(Yrdm?DhM1;rlFR9tU$kd%kt2Yqk3Gm(@K8kKoQ`?N8I258eyKxV)I}2f=02eS<@T
zy@La|SY)7B9PaBWl#1QG#esp5p@D(owk<3<Qkm->D)kNz^_7PPhx@zxOXbR7d8l0M
ztMtv4dWN@QRL-(}J-wyAzW%<sLb<<KoEsV*>FF6P6oz~I%LA3c-fr3yX1nPdIq~i8
z9UQI<j`Wn~hUN;x!-Ks8LxaU)e^0qkEDe|XDkaZu*fKXVJU3V#>8lLE(C(2zTsTys
zVk5vY<hQ%KIMiD#4|I<VjP#9^`n&tOOSolaV7N3~tW<_e{eHWz!}mTC*gZ5nIMUx!
z9Pa7s?ddNJ7mEXh?qa!rq%hbs(p~QN?CvQI_Vo=64fIro2KxId-M!_JN*@|#q&zY_
zR2V4u?Jf?Nhr0*5`@73SJw1hyzM;P1!J)q1?z!$_WnicqZR7cS3l_2B+dbIZKhjg^
z?dit93UdW=c3}t&&_7Zf?yvMzJiCW`2aC9`rdS>t>Kz>E9v<i!n42pOjT8oY2M0$6
zd;E6ymk0ZCpUpu3+(36>2>j|U_mvC7rJ<35zM+A+LBHK+UYo@3q2c1(NPnqs2>-5B
zhDOT$y@kQPxng&rzX&hQd3IOuTVJWC*gH2^>?@7*mU_GU21-P!p29$-*z32u*j=3K
z?dd5)wr6mlGB-3dSnlqd>n{xS6w8B^0KXsKl*I0lQh|urH&8^2_Yd}tz_wvT+CZtd
zI9I`Ydpg#N!==((aimo4?j0Ve4D^@gdIu_{Qg;bg28~pL{zgcbdxwUGiin-QJ_P+x
z&+tfTU~Zt&JJ?^DtB}91R{3Ncd-lW=vHFY^)EoG<d3rfryiUc@-kPbjkj8pT*xQMw
zw{_(D_1=!P)M$EJGt{s5{%?t@w{?c}>wWCaQT4WNVZYvI@Kum#erU~j(#!WJT-PV{
z(z}LOsV~=v6WAWW(rjs~TIuJz3QkJddU3g4U69gvb50)Xq0u<*-@bfH_cndU$6ftG
zccVOa{XDi)rRaTjdH2uB0V=0X&)is%TfWAQ+B`NE>%9QUcYbdfZd0GKl>EjzZy$}S
z(>e}hGj$9-y|sOvK2!0oz4T}I+oI|XjH|SLS1LXAv1EGuHt{`J{X6}-mKS+nU$6;|
z<~ySvpRmaJlrnD)?+(be&6}-PwyDo&BlG5>si-=m^X9od?d$ZJs(Et)FK2skxE$io
zaNgYgt;zKGZDQV(_8WBNmzg%2Hwy>Ma(<nBx8PA+BuTkd-Xq|D_gv-|-&?cvQFB}b
zrmNHU6P|xCwhnCy-(_)s93A?U+cs^(Fuo}j8HXsZO+XHk`-_jq(NSI$pSe*t?%;y^
zx%or5n6bKY=rDWeTBY|H+=Cn0wlKY($@)&H+;ukH))*4zS&lN;cO~g!+oL#iRIJn8
zJ1cZ&A3gz8J%X2+#WnX^eP8v2a`dNz{m5lMrF^jc9d7M3EXPncjNx7~JAYQ$dF-9>
z?NrSY!=>DiNv+N0*xnO)=k^+0+rGUYRsLOHu-O~Pqp5OK+cwv}Z3gGH#mkSg--^*}
z%Yut+<3=1@G3U8p+qSUL;KKI#_etf)uCmR>wDYCj?^TQWoH27bwzX7oYpcPr5xHr%
zmGjU8hvM7Xf(I?O@56f|o5gJJ^M{?=YjAIL-rDT_nBwj5yKMFbV@r{#c{mqx0JwE8
zWV0@pWBaz=(7t^J2e!>m&Q04FqS==PC)vi`N1WJbaAW&CWE-b(L83Xwr=35S594}f
z-$*l;V;k?pWt%Q-G&nROFPm-T@$iYI_%?Qun~j#To$GMdVq9Ogu+!kq==^N7^CK!h
z?#3xtvz=+=$40AiIksyY2Uy#+%iyrY{Nu6i_LXRMwP?$>`shZlY1?q|SQMYNu+8AM
z<UHee*nX4EwzTt~?vte(1tYxq_OYXG?KC(uA_vWOa$7%ov(3&l;<kltx3q7YYrpZ_
z;L&fl*_JU6y`>*Lk6HU3x3)U-sn1rP7wo<*zO60tP+K{&fuY)Bw)gJ$I=9#0-spML
zW-reZo<3%?H-mWB-t^`%&wNMw_8A<QELZyM<FW0t?~7(%7Mx@oPrcuXjRrTm<6-VQ
zZ8oNzKe6uPo5gUP41d6_eFkSn<Ydr39tSObSA6?A$;qIV-Z<#^9nS4ExH38~8}0nC
zn!h~%-8MVZ$csU%*rsPc*uG5$XC>ktj~Ac*o@h3u$u(`;ola~sxGXupI9{LrUYl)c
z=Q}+@2#}8L-1L2J?KC(uBLB>G^0@2pUGeSgBqz<*di#XOzu&pN2G>UCsm)%FrPCj_
z*_%c_G+W2Eo%w<GZ8JEpEnf22EBAxZY|Da+Y~#9*II+>-!uI*cHm?66n~iDbOQHqN
z7RvwNM1{A`J#~*;8x0PP$jN3KIiKJ0!|`qGBsUu^WjjxN)VZAocSh%Dqn*5-yzX9`
zooVF7MytGa?zKPKzFh`~QH2rC^fcSWxf&akF4mIUTEl6yPTTflPHZ!{EjiDwJWHO1
z%iR~vHo_L;;8Vo*yxw#mv2$1Wn2%B?JcC5L>2&iF-Y8fu=dXRk=;-ym_!oVrNZq1>
zZ2tc{K+#WKtGIOh<2Ej(-Iu29cGvJ$Bek-?2zKpN+`9iKZQM$uKm1=lRg2~2WtX2w
z%7{;cicbe0_#eb47a_75b5dHkkcW7@bn27s^TsfcOKrSltJ^rXOE6xt>8HC7QyDMW
z3|Jii1LLLpf5yh8WXaJ6ojf0Yinjg!%~rS3?XKaiMrvh&(KlYY=eUhq(UYdFP5+lq
zhn!69Z2ny}F#|sFcxmbv{|E8OMTo4%oRk(W@TQ{1+0Xt`G~RS_EjU{5mfQkkyjsRi
z$!l>sf=X`2Y61(M-J*E*(8D&K**oIoPH@!&Cbz)Y44r}MFq8d%gBQ%h_YD;HPW-x!
zd%=X89R2_DE!o0)a*waF_!4}(TJi1PPyG+&o4asYy*VvijDlA@Ry+7xPIzUQ)~Gm)
zu*2(QtQKN{F|L!1)k11XbF3C(#%cl!rtw&9(_=QCB_6<pI3cCJGsFU8Gjs-OdU@>|
z2d~I+JXRb2eH-^;CEgJ9|I4?IjMYLszRKcD@Quf6=YRTtDBs+L)9TG>>0%VT;&ZDf
z9=Gwz-m!G%4A+g-`4X1H<$nS;uKgpoHX2eu#C_9d8~Hrw_CJnqWAa&L>%O7UQnvHh
z6VB~4xHI}Vz0poSxBBRx*z61jOIloHyB_&W`*s-|mY9EhHuT{?jb>MxoYS^F>BKgJ
z+miE)-;00v&uq4(o&WMXXJ+%``wr}wn%Ls|e`G?o^~|5UwbkIzh&=S!*I?@}sP_}M
zpNwy7C%I|2IG1Ca@BB;WHXB?VowH#!^LxK1|H@`_8hO%gA=~%VU$<|c!HI42l>5V{
zpNeK*R@`JepZgmpb{bsihL1d+JpEalovG(jd8aHUb$D@9+%3yC_CM{`MuStM^0UcC
z&h<-w7vIK?a<s`(uU~rTbIxrwxHJY&4Yu<5?eyQ<Y)vI!Hd)4YoqDEyy9`cC%tOxK
z&;LU-yVB+!+jr{oPV6(du06hS9H0J2n|*2LL;a4jN{C)!WLvj?!L6+Zr$*$X-Buo}
z-SNfvwsw-Ec8k67<&*#9+-8G|qw_Y*W{$6}f4142M!vLL$o6giQv3E9oY*!`dED0h
zFVXDFikocb*5{qrX>g?*KJwUY_rKcgOgo=)i!na$J^S1L&8>|Fr$*#wvyGhVAN}|E
zHnKL;%eLn0qS-gC*DF~!m!NY|Z0p)DJGa%~Qm#3ftvrs~{S}+7Y2?dhFS1?Z|Ixl(
z2B#(FA?NSyr=!`$$kO5-+c*B7PV6(du06hei0?7}s?9$4`S4J=o?j}|3P;NL_F10Z
zS?4d;<Z^7!mj7~VkHK-8b7A)Ion-6J#J8tCuGy_(n@+p8$>1hGzw9=>YmL0W;pzX5
z?<Z;q<DR*>GYD(9XvejZRA@BNb!@cWTBZ$6_Vs;Vck63I<9F8AwhA5k+EzuB6LIA0
zTNJOaU$e$?pNpLX&f`BCyOUQN)9=YEispUxegE0ceQ%&ei#+GV_aW7~^?gW1(R|PS
z@Vay2`#wo}rOapOU1(dM!cdP3o^x!E!BJs3Pus(N@Du08_fI=<6Xqqh>EZL7+hlN4
zi+E9<Vw>(;7vH9&Ji<p2sVF`fh~ee(Qn@%^nJ?G8F(%t|#|zxrWN?z^QY)MIjKk6k
z<J;68pDdPf^CI@xw(DQy+%|*DxMIo(t!?8xHGO`3+uGn4wgStCYK4U+da*sj7r3>@
z;3z-0toCr*b-g&gJ#F*KU=_D6<#e`f{Y#wNW^fnRta#PJwjF9-oLld=tyZrd6|Ah@
zSgutTsyF3})y2|$eZIQ5Rj)CtFL-->)&l_@{%_sd$Bu1qbE!($44IF)dFKW{ruOYI
zINQ%nt3AA?v~*#7d)nq^vsFwG{SBq-U+Ua0gR8h&#mf-8xc#Otif>mNe8Mc8%x>;T
z*`EHFxwXgOBtM_5_As9|ep7sV+U8S}Rot$=yGmc~+%AKwxL(Dl5W6_XJ#V!O{qIfl
zC0r?K9Zv01dGgdo8@4bVY%A`wQhH9m!mmf>+arY=V1l~D(r-(3rB;+{hw7T*uFGk%
zuvh82|KixXm<H;<U6+%_cPV`bU)ih=>zKH0Q*<U6Vg~vEJ)@H-!U1gC(k<pWT-PJt
z+?l%A<5b<K!nLW(Uss?%D3@=b4{hVi+y3ut!_sZ4?D0rtwO>RWQ{O+R%5Q&7q`K*w
zi^4x#?}<p|biLwRWu%~&+w!$h>P5Sv5c}z=NM&@LqA=rJcwLnG$UTz77pirqQ<2I=
zTbv;6nw0)#MvgFCG%VW6DDQgMLaD0N)wO5`_Q}E5NAYF*J~1R$*FLdT5oM7^5am^h
zCy!j}&L^A%<L{BhWJ~gjV*6*y=G6RSXj7eaO)j-ZQw#ruR211ioS*K!EQ){RTQ-zO
zIVWzqJW4s=`EC^EI*&&yE6+Nj9OwSwH%6&b=V5(tm+O5zQh9DO?6;^sV|I&IFC~I}
zy;hj7FUy6c(b1)qdcBxmtS(fGH;55IZLzQ*9(G}txLohLbW47|I=526+i8*q#X|9L
zxs+e3m-2_JB(N=4Q+4hB7IR%}m90AUJVuRPTW)`oSLbrw-$9^zD20y$9*<O3w~5H3
z{&B!{Z;n)V(>UOnNab|BP2+%ica(aA<ABqV%IG=+<A6JQqSQz3k>h|DtNgycH%hto
z`@C4=0LwiUWWBK`2pMNYO;|hzsQ0Zxf7mm5CtZ>|S8?QI|0?u}i{nZW$A=s%-Gk})
z!O;JTyk_Knf>^QXj~gp@53NFfB#V`HU7};<^zbV5N%UB0+YcA3oH0G>&JQhytA?(H
zM>BCECV4GU<A&!{kG^Hq`o<nTop+C(hj+hq)%qtGNh$b*<LT~gsrkf^13C~-A+^Mf
zr?uNxt#1;?lLPnYc&d-BTK~j~Cl@~9x%$Z+QGC+8E^+<NDCNxS63;~|+q5oGACFR}
zo)<Q)ORSrSQl4Yn+cUY#T22l+>(n4vcc_$Wqod2kTA^M%jE(D+#kzMUhWBx{?6TPq
zqN`M>7nG{csr8E!Rz2U4pHssezI+H9Jj1m1^?8MH-K5P|ox^BPR4%5N0hqbJQaGos
zN*`x1;kd`fJiUF76KsZ*m&sHx(16U-$M&U<F&R&7ZfqQB1Yl~OuA508XLOz>!}cW=
zgWG2#V@p2T&1M=FXv}|8c<;PAE4+5*CU<N&e>qN{I+zvaAd5SNleygWZLV+{Vv2`H
z4!ImsOK8I~mlxiV72d>LP6}C%jULHog*g_N6XWFZLvAiI&Lo4FI4n-0-^Sk_I*r76
zX?rPsjCSTahpER8w^!1~8Dy(_Y|PU~4m-hSh!?VXn=78$^he_9nRlg+F&R%2!PGq6
zek6UI(RrE-8;=c+RwH9eK1_+j*5tK>a+b#ikG(r9ymsbx2(s=^E~;mRImqHp;bbl!
zywMd-Lrf{-V`bhJfJ17D#O3>sW`#E~my<%)Tt0P6R+wXPIWbNiKMcPoGR`D}m^c|Z
ziGC}82Yut*qwh^0qn)|VVe0Y2Bj1re&LCUeV`HA4dcPBFhIk>HV`bYgkT(61c-sGg
z^f4ymX(E`Kr$_HdA7^x)Cd0;KgX15JjIBklz3PtD@Oo|!<yIc&p1CtCymsa$cWh{w
z>aoGp_hp4S$l^}nWG>(J{jP8tVoDhwEAzGh98ybY!!nnj`hl$QCgyTd$ePPrK9UvY
zSX@qw^DK29a_OGPIK%pPLsE7+ez57c@RzRJldq{()j<&NRaK<xE#g>1j(u?Oqv`v=
z&g>*^PVR=UsQt(Bd(-zpkm>2-=C<GTF(<eUap;u)HvP#P9_M=42j}0Hz7LY|-@O}{
z|EGUEeIG>UzkA&L?#RiXh>W|%D8rDVJ1~|Bsim!0V1GRRlUe!09udhMpWG#!8y@@V
zto#v-jx2n@oH+goS3WSraR*`~q?Y7_K!3shxc~oT<&VTM(h-+%jNJP(S@|PYjC9lo
zcl=yrA0!#*Wwc)2Y91kujp%pmmVQ2cAJ`)ziJKFq2kC~~SJhnNx?fD+55Y)CA3NuQ
zt-s_1yCGIr^L!#02b+E+eIF!?1Dl)O#KHPsP2UgE<DfIxd5rM<uSLe5d}tS^S4dt<
zTV&w-8=iS2D}UG{BO{mS{_?3$W#yA#lw{=xj+GOSy7Ge|rWLqs_Y<Oxqc~O``R%Oy
zkvLXD9N$*@(6RE+V_EqmR;+Z)4?MoQ@Ao46A;};xPLGmAe^N5g*0Scp9VgQFfju%(
zcY~g1)IXiRAA-@4K6Z|S*~gt=H^eJpiq%_$Il-piNgQnbqx5}{EDk#21|0{RpGe;i
z(c_>q*m>-<?lY0GCm-g;=@pXK(pF6H*y+rlX5|liWMt$L-Cv&iv#fj)jFPPUz_If5
zU%2vvA*L0$SUpDzhlJGPBvzjM%dGs7I95945*;g#|8-VAi4`jy_rt?~6WI@8;~&Fz
zwbSvHO@D&;;LqF3vr&A<=KX)0z8~z-k;K*Qxq|mJ?*6;<{Sb_Z^szGsj{dz9?1q?i
z8Vff4?GeB??=JmA`hG|j3!QNV$HMGCrtgR7vCtXpJiZ?OLS*bMMmL7k-GMPwNG)y0
z1^cA?pR)3aJvx#*zdg5b&fN0PS@|RwDOve}xpB$AxblM`t~(GfA+@we4D=)HlZ*Z}
zE1x8emyWrG<7NH7XXTSv@zQZW<h~r)4@m}uaaOXD=x-xN<Qb9|s`pZ!`%3zLut!HG
zuE>2&ou_*0bo#ysMnyLGIX67|RVVlju}ipOtyqOQ!lvI@OgwldeLp0NiH^BK$Hcu~
zOWzmKW1@5Tc?@wZcUEq5&h&Y$rn`8P4*}!!7RhUAJ3hWi^%+Oc%E~A9D9O+*IqpmA
zYqRo8Fk-Uw1;<V4Tvxs@#JB<&t4C?!l#p7S#m#l=vhqpdxap)@ble<#VOD;L6*nFA
z1&_gYpC8#5VPho2a+K3Cm`#5>u_Df1aW3tDar%C+M@bS_x9ti&2HUhgeP0A4BOCl2
z6YDN?g5MCoPGiERzilFLOq_aY`hG|j6CHDfj)`YpmcB2d$3*Aw^Z4q-%Om4&G4e5_
z@(zrzLTYI{K6qa8=qs}Fi9Je^JHKtW=<(GfuguCX!HCJy7aTVaezPlI7-GBwaT8KY
z+XUgbx&PH!`6O}NbkZ$4Zti<cR(^>UHy!mwO|6aJ^*Wm`ZmP}K%lRWK3-$S>g>s&T
zRE1)_TwC61S~Uy#RPz=w8pHnGjjGNkHg&R29jsif{zm#mmpZH0&^B_+$(1tJ**A2u
z&StE0xi@Tpt8@2krh2z76pqZ53i<BhP;aq3&^<CR(l=7-@9yg^jSLnChD*c6N@cjz
zzio6hvS=>Hb(Aji*U?iN?CTpC8tADE4fOX_x_iqbmA>xY;z)U9c&IQ?@YT^$)T`sp
z%Y${4`UZyvdj|*l=H>>9#o@l5LaB&K1_nlk1_p|OI$DT&bsT)7zmDF);mY7hPibyw
zt}r}2*gG&ZSS<GUlnceuaH+3S^3~B&)T?9DmOvdt!-FIJJ;mXkzTTex!f>%TQ0Oj}
z`$r0cJtN&^e|z+{67}kMK2S$rPw(8w@Z4Z|q^~kGSL*2=87x<dB?2`vINU$v!_iXI
zt7GGv{5Vjs)YsSFH&-b47mIU4!y`RCgN4FyZ-059GT7T4tRr01tK*qK9sT9O{<*o*
zK>yr8cVTF*d#JnIS1t^fhDHYZh6d&aeRZ@H_3AkOW<QR>-u{uELT^tu{#BSOP=gnS
zK!W~};&6YZr{b%lrKnfOt=;}QhK7rCBmJemA^f{i85$|~_Z9~G=8D~g{^C&I@SLxX
zmZDxAyL<d~4EGKedxt8;^3YK4;7IrIK+nM3TybcmFwi?VI5ODdtD~i;SI1JXzYYXi
zxp!!2sE8=(>q96G^$d@c2IdATy@UOgIlr%3ih6Zy?F-aVDp0!W8z>@w^bhuq6#7cT
zeU-j}Qg3mt(mU+KG15xZt7Bb%ppFW-RO%fb>MIW+9=iKW<;q}rs9Z!n2$w(|twg;#
zx(EDq6uXOay*)kU-nqe^!GX%$(9mGHyKk<)Fwj#h4_5r~(Nff_<4mxQ;ZkX?I8rKi
z_YMzK2Kq~Ly#tj}sk>Au4~|p<ZC-38>eaDnD1c+QJls9d-QQgv>gg$r^ntH~Lw&v7
zbKS+tz)-i}SH)JMULDT|>Zl+R`bs@T_^Q}f8tE<dqWw#hczX&1m13{2&0C7*a_>}Q
zjg2FOgGVg2diCh&Xfcn`3iaUBS&K1Ee!03*E0*OqNm~j~|2n7iKNm|s_t#-nuuLwu
zP1W((sE46gC>}1C@=Ntn{&01<4n^XJt+<sF4)Xm08)sDc*|)SVufH<8P+dIaX$t-f
zox7CI(>|Tc_0oJbFZWGhL-oj!>SEse#;f6{TyC$@bKh3aHoG47Nl+F4O6~D$O5gfz
zHhpSew@@l9VHE4xXWXO>8P0aWJMMJ(ZJ*xm%68lEG>PqYU1a<3DZk&nBaZE=<zl#=
z+uDYp9gTh*&x||7VQ^iWI6^fNjvM)2;$1CpEY+&T^73-ECX!x^mXPxt&Zz##mtTC&
z-&k0fNA%Al3CtCiWm1i+U#@{P9mSx!<Ek>sJ2o|!yG{B1zTN5j-M-qA#9y6uy?bkk
z_Z8*;lUJti|KO_5YV^4q3;p@!^pq1n8}gac{9@CefaEq+uJVgbKbh*~m(Baq_j|I4
z4a1{HP|<oJn<}I0-COI=FV}x-`u>j|y*5X6n(l5aBtL&h<?&<tBl|h|(9g&p%g`Ws
zEf(h|SD2pJx!gxodz?6sReRXuIk^YZX_8J^PI1EH&5Z}MYL{TlulBZZX{|p`O<(KE
z|AySHoSN!+*rqvGi<Vs#W_x++p6jw|kHpa);=yEjDny~N>*$o_{yg>UJF{w+Sdky%
zx^&vYrM2Y$Yt{N(SHb50kfqMi(U6DU8u+s@b#q#?spsc@`yZYQvER^YViqYXus!tb
zKU$2Zo9(ly=jUWU??Y@a$vO(fS{>UDv}{%{A6cr_3bmWnC$`AYLo0<^X>>H7k0M9<
zM^*b?RQ515?Gebux`v;<{eg#kWtWT9CG0O8D%bN1h2?s_T&q=U`C56ojJ*c6=w}!4
z_6H7EJbQxc`f_|-C$w`bl}fobI@<J;xA&1d<mqVu5ZLY*9aXLq|MC2Ozpp&V9Bu#S
zwiY`?@H_AS%pUgaYptJ|F*+Jj1q<oDmh<QRb@*3Y4SOxOHT|adS{{g`hpQ(WeOo#F
zGq8V3ac=j!Y<5}ZP|23YV2D$F+WzZqaA?0R&CrHL68r7?a-UZIUs{N1ziLC{Ai$jI
zxz)o^w4+sHx$B5qEC%;Ez!Iue??E14v|(|#ZwOMkQ-+x4{nJOPu535>N_5JCN^xzs
zD}(L42YF&Cj_vKx*5dtkRQhl{{ceXi44w-Ff~h51;0RR-9J~j4y4C_mwAEk3D+W&Y
z2yFW0fS<!`_1mh~gdVG>?|1tgGFhkZ&k`MQy?b-Pd)|Y*`^NPBADlO?N}szi(U)JQ
zjymzPA)PtRFE;&2@{3KEaY&b7)NIpFw(9({@s{-co-AO);COv_wESYzWpurJbA9>c
z*>6wZ|Ivfj=BJL+-HnOxGw(s(_nydpZZTpq3^8~RW~7fLa+B9$bAED->DjIKAa8$f
zR_$RA=j0AdsYyCzI^u-)AQ!$Pt9A*7{HkvYm*)EN)YkXA^1mT>E2pNq2iZL5YSFZ-
z!fu_Xy1p~3_DCG;Ar4HKr$RIuyN*to?#ol_zALMCi52)Eo=d4MT$&62^ZMM$J8b^9
zH-562EXMY(Rr+u||J`nJ7#dtmK*btJG8}f5!0{Qif3WU*;^SzMh(iXtEzq>1*oSG$
zoz5{Ce94_+dzeBM1Jlo{cAEZP8>V2OCXN*sYW((osC|14zVTury1jNau$T8droS(m
zz3osG87XLWJIZ{vUw4-i+YNpSa6Fdnp~_%8pNTm9{nGX*XC2_b$cG~MOvJ_yd%kHp
zI{<Zb6r<sH{m$eAzOtcbB9xvG8NH8x{SSEdv^*1`_Kbb!B=q~BXMB1Z>^Gl@xJ@34
z;CC+Xy4$m3WpV!9E9Ly*a$yNCl?Gl0!z-ob+G1fLU#XSL`K9W@eDP*__i?FQE7YsC
zx8`o)a{xc+=?mgoUMd&sHQXXHU!OlzsN-PCLbZCs%2K{wm|G}YE)s!UzFsRVE~60M
zAzLcU*S7SCcfPsmZ+k~>hq~ut%SWj0$d^}m=5M}C>v$}nqvhokMjiM3kl&7;Qj5zc
zj5@mS@#|=Lxr9;2iJ*>Fmq!?NT>ry<J6c{2Vbsz8(FPsimp>SFJRZ=|@^S~Gj?$0#
z?Pz&<gHgwsfR2`zGZ=N;eXrk+mX|LWbsYXtzmArdD;Ra;J{Hi?>hc7mj(dVST3wD{
z)Uohmemh!TeqhwG_P&6QR+k$Xb)0O_(ej=H&OyHXvGn79J6c{&5U}H~R1O{gIO#CG
zRjW4Wqis?c#@}MtWSnwaR+*CxBWWmHD7|Y1X9f?KkIvW8&wo~7JN^^tV@oz|vbj&r
zyBpx?c~sX=rjIW;AamAaIp*W-Kjj3IVJPU7k2d|r24g-x|I_JXOUB1o@H8K<|3v!u
zqVq8xrq8P!^4KRMV@f`=ijyUi*J9-67ZuK}4`zka&QQltb-(cN&t!!)$X3_*n6sOI
z&J{jG%qXK%-Ir<T0GYG*9nT79V$Oy*)EJ(cvzPorR#;<kHa5Nws{C{3FWT_geVuId
zLBqux3yVce_N)2D^3ghG`pe50Hs;ut!w<Q&#o!b%7?DF)vn?M|ei{Fz__nl@S8U#4
zdp7;Db9)T#;Ur`C&~3^;Yk$RNPms5+xx)27>7agt16uOqeG32m4@bk_2~MyLM}O6c
z4F)%~=E0!y!_=>NHiWND;vT!=4Y?~-x#vR5k!XJT=EdUST6J;$mU8~kLUj%+li(H>
z3+ES0<)g?OyOgd6em%^FCS6$1%-0Xs%7v1+6wZ71Z2Kc&dII<Ep)?Fp@1DI$+3|$0
zd~jW~SgS7OZz<QRWlDHEl>G7Eh+3bhXmqqRzf9|>lry&}9pj&hsiV9oRPfyB(ckpS
z2W|caT8F5B5wc4W1R?)0zUzKFeSEHaPRhoO5P47c`Nz`7=OV+KFmapR{`*ca8S<J)
z?{Q{*VcnNazZ_6DHkgl-U7t=LUouX{gUFnG=<)RNMdxHZOg!hA`s2u$l6U!Wn3=p5
zD?b_QnLo)2tDU8;;c~9I|H-Vd1{v!bAGhW1zi@@m5I4%`RM#X7d6luA{>!YeCgyF3
zQ_W$@yuI(Ktgy!7ZESozuQ>Qw8$Rq}VGW^FF3umpj9{sXV+-h8uT<mV?SJc)YnqS9
zqLJqnXX5E<npf~R|DmTnn_Ax)A;u`U-l9yf^ju;0-^J0vfhpB&Q@(jRpo1nbM+%FD
zL**moMO^klSAY~(YBl`PFwf%oP5pD84NbnK;<!9yv6{<WuIfAGlb3S~dFg<xtFlly
zw4Bqr|GtIpg=(>Ysm}+L?$bW`;Jn2ii(!K~`%a*=b_qAfA1TvC;`N)CFau*do_xl$
zJ4-u`|HJCA<Ic~o4m%G2<La<u{MprEN7olthaG2Di5(}u=++;Gj!q<Un&(n#wB?V7
z{%LjCao2OJ!;Xc2ULAJq{?h8OW7EH^4m)zsuMRt&%GeIxk9qiC<NKqXIi5L-;N4|4
z9=iA6R+l};{(W`XQ#!S}?AiV0)n(6?udFV6*8j)qvggz)v*+Y#=l(GaVR#;C8^w6}
z=aK(hUH07f)zxLs?f<p9>^Xd9b=foZ->b`>?ys#bdoKF=>aeGm*I#`07}tVog`4QB
zb+m@{=c>%DxwF6V&%7TlEaz$I3b^>}^h0aX$K`sJi!!_qTJDcjn>~M4`q+Xi%*j^m
z8u2g(yVg3vW9TczbU)4xUKlW&ez_^&YbfU6!E@5bm5hUtp=l1@eQx^LqH{1hp3kY6
zdhEQ&c#=;U<1jIKElqsnv(W2akQGKdD;>hrxqteFS>X&a)Fn3N>76ffh0PEn%HUM@
zj(vHPdHTfpSz%1f(-3Dig`?)_#usOWGZs%{Vf(nsr?W4yVYB-<tn&@q3!GoZma}|Q
zopzt~t{@JCE-jVuCmnDvR`D|XaveLVIkxes4Q_2TI7$paXxtOm#!o6gmM)5KV>@{#
zzNNVw+xq-BIk(l|QchAyyqe4LT<O+VG}_Ah;AkoQFI7BODBe)UY>CU{F7}s^-?2DS
zI68l1<w$;c{?H<>R={_6SHxLhE^~*e%>1IU44)%e|4M&7{%=iu1D*d}Ea0mpH{};s
z7U+mL`7_6TSobCA<1;3RHb0GQfT-uy)8Cvv#$Z-YmQ5+DOt_evrB^w@Wr%B$D&vfh
z!vNa!%g)#UkhyvLtJBAqjGM6`YHr@&l|IJk+>DRwi>j}D_%)GnCGR5RFf@5BR-S%I
zVSVPcSz)!awF7W<pRs;ZR(ONV?F2^VZ};n6VKl^$GCb9}ogvRMf3LeVE3Aq68{$-J
zxN831@rJDM#^P@xjF+mM^uT66MmavlY-|}PgXa(7HX4@ex-49d<Ke-8+&AbrSULa)
zqH%>=^+;ab_oGI{xg5vCrZ@V1k`7jTB!msE>@#s1JGOwU<Kez7>EjJXLgz3tf7ids
z2}VOqrZ`q^(V)!VJKmf=)@1y(xl`uw7H~Cx*Y>23H#&dY!}t}I&+EOBF(w}tr8%B%
z(YRk#xKH<Gh1<^P<PMI;YmVb%16g4Yvb)oGnd4^$UEwvvToz;Qh#WsQoE7fG91n4D
zJdUp$%?f)gj<=1M&sW_3mdJRM42t4p@Fe<G<JPLhvb>v!ah-Z=`nc@uZ6DgFRsVB%
zd-}M7%xoVEx6u<joM17;0@)aAH6sj^O}~|U+b7b;m5h7QpfUFzx*~mC(YY553$Nv0
za%E&J$%h+pvS0FAns~?<@0rR9qn(YeU~&%GxGyV=L1wzb#cg-zx4Ob*hzn(GtPI%#
zU`Q=iey*F%3S(k^Muy4!yyNPuFvj9%WL$4j<B&548*%X&iKUe}e2Ieg^|2bL?|C@(
zcE7w_{}n=1GxffOBE77?TwTF!5nDz7Jvv$|FXKZNWqG|pF1J_J-F<BwT}<{Sb^1QK
zXJYA7wk;QKWW%mhb{+e+WOn&f<p!0mORn>DHJ#U&KWxRqF;-QV#l;iMw?};Cg7+JI
z1Dy{6q{cJ*r{3ZDBQ0F^ED<(b3||BHLDT1@yYuN|3uXs5c$kCNU+)BuAt#C0i!-VU
z17_1N`zv2V@tOU53hCoY#=*$YGzXuYOCMWw4o1hr<EOQy$aq?eYz*<tT}m7#Ca<N5
zk9-z-cR4GJc2+ussn0^+RmloxkfAQIF;5>q<O-W1MmoULkXo!fT|b`{#>70015@+#
z;JdQI8H=Z}u)R->NAJGDhRyEdu+G<zRYm7c=LD7yS63EF>No`6+hiLKFSxbA;0UV?
zA5ebSdL+IL?c|L{Z?GL37oFQ-a0e%l=2p2;`Qwz;jvyypae?c7q-w(-y<P)gYy01#
z@ZP=@tzMUH&UMee+ezI9*!Fh*h{C<8W~;kn@xOe-{8E0gTBB<t(WtooP<>+!0CH^C
z`enCv8JyF|iBP*fru=m#fn82G6KY*9$M!u}kMFk@_8DAf;8hFzKB)Zn)QZi%=<yw)
zj|sJgZF%Iz_H8jZCl;?hto(BCP0?&=(N+f6#BVFM>DW;xHW^%$+@{jaHk&$|ujsZ>
zm96B08^$l}r`@->waMTxBd1I@asJ%$?eT4L$E{||*shJYI=9Q<E*rm^?c#CQ+V|M(
za-Wx)t?=%#eae9y28TrE59h{*Zj0uRPI88Ax%<6NY%#bcI!}15uzt*D%Qw<Gycl&A
z3v^1qTG!ubx&J%T$L2a~iy2K2p8h`PlkZC(pNs5a!o++${eCBy46z|nMx2#UDqxhC
zFFxc|fD}rFC2R@Gy+F0L6l^el?{xEbrjIQdA8qb4!qa>__<{8CMdxEYOuTk|>vu)Q
zl)UROvdr>T?c}u>8}Ey1y#DYVS>d!Z)G<`uFP!@Btgr^z>KY$&cGLH`!e@vXWpt`%
za^N<ss_6cmIeYz`S>a5~*${^s!&7ti-tWx{Yb?$t#`pM#BI66|mksL$PWyeE{-(xL
zS2^nTTevHIe0G*5aiJOFXH@^O{=@0x3o_FkCLXUn@B>aT8DhdICvE!84Tg0d#<%+i
z)5n*Llkp%jC!hOB`uL)AG9D)G^KQQ<GN$Cii;TvjoHH3~_eZnBYG-M3r<%i&WAW)9
z$qH+bv99rPTi*VouJ9S+CgU+_6K{VkE3Aom8{*U!yuB|gtg(2T7~kz5kBl$L03=SP
zO`^Z4@#H>rPTv9W>`$bR&(2b(5cOSQ(?6L$#vnW0;^IEz!Jl%1%Mcr6Z>$-97(ko;
zmfT$bK>GNSaWghV&CR2qNFQT#ZpO#O{r!`ljEpP!kRwj^OkRtXr+nYU_=8ztwX?MY
zaCM*Y@Xut0H^|&hU}XMw{hTX|h8R+Y$I7rRz=qV)lD~Hy&kAc|{w9H|`MdTPvcemS
zzlkvN9>BscM#dP{ciYxG<7D0>`YoKr4d_RXR2Q*^#c_K7L+RtRv$i8p^?KdYzmz`K
zAY(g&k2$;kSDfH8#0}XUE8B(vwds${+1(GPk24u(6GPRUz5Q3y#~Pip$?^T0+V^<q
z*COL<(SsXOZ3o5)A+@yR?^hJ&)4!e-W;=_MJGUil-PdgYjjV778Qn>&%<Ee}<qE4I
z#yY_3kXl+cF!TD+-^>bgVqUicTl0F|Z)Jr$7O&gF%43Z2-;RtmYz$yXqfW;dHvKj(
z*Qs_4i*t<g#P6h!)6U`~t_+9D=S8P~H+`Hz*1E^WZTR@_Il*R#8>d{g=?`x}A6KVO
zq>nQhSCc_yuAcmZ^l?V#YBFp*UYPyE$k>t(U*fDfB(J3<ZyEFP$Fst0XK$xqb52_S
zM_FMGGPzSYxot~-><XtLu9WeyRwP;g4yh$FpC5f9E6j=coESFqx$84oVUES;#5j4c
zxc;Y+aV8ni#L3J_^fz&Msf_#g@EuIPpXPxl)5m9Lty744ulT7yOCMv9rEYOCH`o4!
z6I_NEA$wzG*)V`M{VlmUd@_A}$+#ICqUPqpU#5>SIyd9v;{Bz&|0*)B7Cp3KO5cHT
zKu9fCp7J?{C;vJttai30cd8Yx?lUg>o2>8#ncE4B%-`Lgb%oIoLml96NG;X|W&Ymr
zw^?CL%-<w%HGfY$ofY0#{A~;4nZJvSF|6-4q(!G=1DpP4&eqDs`Q>?WhJoiG-G84x
zMmuAZxG@x_zIX8OGwI_DGSxjco`2l^4^FTdV#O&>ZTdqSka>FI^XX$u#?wSFHBWQT
zrjIi^Pm^KeK61+!B4bNFEQzxkki3>q&hk3m!WXl`YiDkUAnU!q<NuTu<{*nZg_F7b
z>~pSg8e&QrA8YlX1>lfcB5`^1m$Jf}n9E5aYc4PROIDa;aXB$gUIV-T`N%kv3}WJB
z<Rto=_`5uROPS6iFuwKwo<2T1Yu!Qoj5-r{?91un3o_IlCT_E5{=*3-Lu`<(u`+8I
zIGg^KoSgn@`uLJ@G9E<c<fCWO#}}QG@i6gv)~2sV#?+!WHcZ(&(C3HLV&x}ey?4#p
z+~!<9U#!(}RcmR!s;-<H9c{Xs(J@v#OOsb*hReBT<JzpS1{v!bAGhTl=eojYh?@@Z
zHl!AFL!z%|thpCtg*7p6W5Z?M-uj}fu*TwTVtmhC5E)-sA8km3PR9T?{Y_k@yNdne
z(tFpZkI&B1BrY^V<T1eXOVh^}WTrbz9CN2%<^+==CY*B8rr+FPzPZu^8`H;^jFa&o
zGAFNlW%~G{b21(#?(^2ZDl(?zLyS1H_~f-%`N>!x@5&0Rou#hfa;~}Oby;BzGS)Rd
zZp(w0y259O8)bB?nSKkPA+@yRZP#U4VNJ~2*l?M*&%H4#tg(2T7~g|$ii|JG03=SP
zO`^Yvt2fP;>W47~;Qi#M-kd%@J4>BH)Mp0Q_oR<8$WFJoIQE8no!~OW2H6`cn}z|j
z>2Jx+!+q)FOUBLE5H&aN?N1+LbZ*AS#r^$b1CepH=!p$e?hf?#A+=a}%KO8)p{%gl
z*_zy`R=B#)*gl*U-XL>3fsy%JA901z5JMf{Z%8fH24(&pAI%DDV*Vz9tNHu<Te89%
zi@%95-lq16H@(${(ek~QupZoy9K{I1_kpGA3SN@JKV1LQF6%dV!d5?j8~NUCG4Z#P
zOz=@+`Q;Gl1-9Y3x4E^!;0DelO)XJVJh)`L&4wTsT{J(}`GkWy4Oop$ev86+`&cxb
z4x2g0b#L9_q;3ObYxCwlpm3kE*4>dfuh$BT%ky=dE6>*pa|>l{$0Iv!K1g7P!4nOQ
z-(<&!m<QuA?QlVeCTnszwr6_6tvv?UG?T<&59j4ecG>K4nGc!`;QCKGsNdj&R`k$3
zz59x2_&Y=kZO6ggPV6waA`%^PJGg(CwAmrAz|5Bl^@9B7;OMBh{Rc-xYN!@{J?l8p
zhK^mzj_a<BVh3YuG9|})PPM70SJ`v_RW^I-)%^Toy?m%#%d5kOeDBJcDO;JQb2Lf1
z+jQ0n#Yc9<C(sVkc#g4c-kUx)`|Kcz`{Xpp5ATmuTOZt)J~kKGmIi%(Jls~dPCLP4
z$Soqxy5gZte{)0mc=*7#rjIQd52M3l9-f>@A6s-DM#sbNah=&88Bg-=HVzw;*J9)(
z<Lp0>6;3-dT|(u&vUGJ;ID;&8iH+OvzH3}zGsKB9IM$9z3y>kTgmU%d!K`p5=4vdc
z%+-so%?f8Mt|r1Z{%w)5B^fBi$*4*6H}dmZ|2T8u9qD7UGt&(`?%(gtr;jbjMmKmk
z#vUp-!DEO4vNKk;3<GA<AIih0is@rZ#>43Fn1|<A(#IB^htctH-@WN@WIQc;Rl`O{
z2m0=iT8x}zoTYbVh11T=<PL3y%6a9%g{*J}S?UrSx8YNZuCN*6qyt<HsinCA(UCLG
zOWvIo&cs}e1(ms4TFwe*EUqTPcK1qTY+?PcA>BFc-);IE`C0IfGoQFIeQb7SCUIXg
zJnrAuA59-ykd1EeaEy)L>;#V?2AuNHroXwNeCwIVZb=_oG9E^U$2@%W+tbGuorlr!
zaG!SS*2s904;|vnzLVEt<Rs(VdRtaF?aXuumGjCS@68HlkfkoMaT}gE<_eo3PL#p1
zX6P+IhSU<u)%EYo3TI-j#)8URz3%;4;f%%AMA+`VJu<c=1B*BrHHrR4eir@X%oE?4
zJ~lfu-N57i{qzUY#};Ix8$29im)zk5k0A!g&RE$p446%SC=Yjkcly|p@i00(=Hbx~
zrjIQ;52NGZzWd(qiHxU3uWFbYccAYMsl~`i#`)x(S>d!ZGr2>Xp>keX|DmjK23hJ7
z8@J*1?{kIC5GNhrYDg{34d`3XJbG7FI1_U<7F6cyL*Jhj&RATHh3&KIoZmAaj*Km=
z|23pLr~SK4e-l6R>T8^zQ}~YFojyK0JCnH33Q@l=yZ$5TV+=CWEiUHfy+7mxmmw~k
za?_^Y+HlOx?jKGcUovjShN!uD;-l$fjLyyYxcFVz*?S}7N<PGhGfPiii<PHeQaSXZ
zk7b3`&ejgV)$hWd{IRU?2ASIljLhG=e%uvCLkuayW6kbcfDNgoC4Z-XA}g$k`I`i;
z=I=#6nHAnx{7r<B$K;RyRAh`v1}AYcZxa2DoGtm+M^FEB`q=DDbpwyrr8a*eeQZHi
zy1~Odocg2_Jcd{xJ7Z<gFkm+Qp*%eLf6~X6jEB+TF%KVjFnw&%c^DlJuQ@&bGm-JM
z=xGg8?GE(kA+;De$vD^kTvj;k%uMdkW~iK3wja+5XON{Xv2hzN{k$t|hB)Z}S3_!P
zZb0Aq=mWoy70$$5jRlpt`phq8g)<gc6JfjPmm*^e>wgXD&T0Q{)8EL?MgKT+{ja2t
z&Cbju?rVm}{rmb~O&?p3jc)L8jII53CwL4o;FO0p{ml&pA~LqzZ={bc84shwV;<&y
zGkt8)c^DlJ_uZ!+jf^Mx&>_z3J9#ZePBP9jznv9MJ2PEE<=9*IyIJ83veYFuZo_rI
z?+TkCPL#p1X6P+IhSU<u)%Aan70$$5jRlptddVMVg)<gclVSV6k+CHiSj5SwN%S}J
zv+5sb?*60nvDumF1|IkCNB=l|Y(X}<!NW0j?-Ne&7-E3zjFm0JfZ6ni^6<o;q>n8b
z52M3l9-jV8`q-lLFghOYyDxb%GM*N_s$pu}fxbJW79%Ga=j@+lh11T=<PL3y%6a9k
zKhFwhkfkoMaT`AR7p|}w;-mvy4XLHM0e$P4r%z^uGci|VL1nJ?|5a8vV{tVRw$fim
z#unE98q%H9{@td(k)KQcapql5rH{?d%p~q>hR6N;qkoe=wjdkb;Ncj1=Ce-l7-GOF
z4{iFJ8_Ktyx&G<&u_fbSba>3e?SGd(w&*;Jj)(j1(&r-MNj`LlGy6_ni;<Iz^WMMD
z3a6c!E}?Q>Ir&UhID;&8iH+NE-RE6lGsKB9IMxik1;~(ELb<yAAG5-ln5(g%GFNYX
zHY=R5xS9ytgI|b@Ey=(lPDV|lzmcEI{&D81FQ$*p&P+G(bpQTb`q+YObc2Uu?ASj$
z!DEO4vNKk;3<GA<AIifMUrHZaG9E^U$2`2~`Sh_x=V5d_+;`9ZYh*kvdR4>JxC4E6
zNG(QAGR_D7Ei0UMW+r!NGgQtixl>u;46@WEHg3bIFT28Kh?5R*HKdm22K23G-uIQP
za3<zzEU3)Y)Blkb&RATHh3zZq-Nf<#jEpU;|23pLr~SK4e-l6R_{7xGO1+$4EYxb%
zo79J;@(bm~L*g6dUsbpt{c8HS?W|4W+St%@UsBk&pGhBkkjd%bWsX1e-%juv;>#(=
zZTe$3G;_TB>*?c8#&KuRHOG(V&dF`g<@3c_9XX&hU(L(!rHzip`fi%dFys6=I>&8l
zV>fl~tTnISKy&L&XGO-Fe8^)&ZTS{w@>*g$;auf|b!)Toft~d!x*^AL|NJ>w`5_nq
zX=3L%c>Fw9*bOnN0L5ChXyJsAS`x>>@fT#}gT!&*(hWKe?s-vGeuxzZPO<ZxrG7zV
z>`4Y=ae9Iz`Wv~w;$J_$@5Sk3voqTbJYKhZ;w9;03$oP>9_Hbx^-k~@Vub9Bm5IZE
z+4P6<u<OF~u_fbSba>3e>6fODEjkaQ<KZ>A`bClPwCJ%7OA#Fy7lhPe<Rs&K@MT%y
zv@<igLz|&;UU~MLvcef;sY`6!h8s7!!e)q*4sbQ3mgWZZtshUnA}gGUxf%;9bM?-P
zv%(pRtBJ5Z^2*5A!unrBx^vpU+w?c`^QeEE`Rpa>W3w|eiTj%2asR&YRq103ve6A5
zj<Kz;c7n$c15SBp)8E`sAR=Qs+?77IWIT)xk9l~{YtqLSorlr!aNqsNYa`=HK6HpP
z`%Yeqk&}$`)a$asX=kQOs2qFUug?l+kfkoMaT{KLsVi)TI8g@2nxVG<8B$9qSMPa4
zRyY%LH5OFn>XVzZ!WoOJv9Rq>d)8|&_hYNot4Bvii@du}U38&XFW2(R)s<SYyjAqs
zqoXT}hsyO_ZkN*WR4g4#V67&%P3d{~jh-#VLh*39lwYcs@`tO-br>an*gC&h-$o^u
z3zc&I#=^o%IhVUqmEXOkb$OJWKeSjbbuCmE4>f7Z>HEQ-@#$(~pVKxzj?>d5AJ748
zxt^~q6b|VzPuH6~AEkxM9<5HG<#^0<-J8?L7K~6gc>Y}R`Oa=9cno<##IY+5+Vso5
z!@$84J?Z00#=*$YGzZuArH?H-2czTRZ$b3;N5<1)lwnAP+!e%OV)9y=_{ih6TL-ej
zXlJEEm^$}AHkcL8AVXbZW1i-QU12lCNC$WtQj3+RyGOFZn3$(=U}~P;HJTO9SUin|
z?E|V$fBY>rY<3?f8&zPGyi_XS#BOE2yim&DG+&~Fx@^a~x4N~%;0!Uy=%O*U!Hy3p
ze~fR7Z$~@%!)#41$M)RuHs|&jT*C>)=AB&b7Us)#n>|6Uy5tDgea~3?bsNBk^5T68
zcWFnox;w!Iwqbau6B`UJXx;w3$`9v{dp0!9iB(`NREvcL%!3D2nY$vF$uBQdZ_+uT
zd%~+LI5+HAZd$69i}TC#RdN3_=cc7yZtXBMKqChOc6?Cz@%R<-?Qp_JpEYdDsol<P
zF}TIROP?*A7lyC2+2S-O`D*s^;o7U(uiF4Tln=KlK0FbzZr2>(`tO^HhP_4o2KeFa
z&Us~Nk5_+FE()yAVPS5*l-r^Fb|yl(#&tQVA(y+9bJ||7Zkd~w>orU%M@OaPE+u#V
zKEGVV^-Q4xLnZ7D@>=4_SbErh${MLkua7=3?YGJQ&V<CEUZKbrN`)mXw(=^gwu)`K
z<6GnDF<HfaIy@7i%fJv3AU=3()9(H8^q6e=h-$mdvo>As`yY00zOY!ra(A^>&M#rH
z`$(BqyD@AofD3HbeFxmyWpgi$2BX;ZQRT0V*TlC=`QNzWVrC<^STyU{wtEgbx6R<T
zc((m4`|aBJwh{khI8FB_f%a76HT060mKEyxx$>d;#YKUul2`BhP)V`plFPBZ_k5dM
zdkv0sV(%}rf8P<`UWdGl>E&FG?Y{4w&h0k1+REA3c7L4n=Jhta-HgZD;V|2HNuhlk
z4bF7J+fOP#uAhr$W0qWHThA{#vDM&G_xxN}ve{~R$B|mqd9p2|qp#{Ti@pxnbN`RJ
zw*ivtIL-u{Bq)v~P{vRY1yeLVq96(YL8||MMi7L-{9uM0&WvUTBuM={yzciJ(?U;o
ztGfq3TAmEcv<-V<FW1ZU!n;_TvB9;mXRZ&nVVjoeGkxMY7!Eqj+u%8PaX1Ih%kc6X
zw2$ZD-tl(n^L<%WSyiw5y?#9aNbL@T<jkwA%&e@etgNi8ss!t2(!Y*8hDdcdMGfbX
z`}|0ClRUnUiW<&oBEh_#J$8M04H4<kiW<f1FRO9?+*%Z`@3Y_8Yw;r(Wj@b;<NER$
zBGYS8Q{DHc>YL~DgH~16)1!^+&TEKRuT53ir=D#^@%jPG^AWnqyk)<6?YxBu?wa)R
z7uEP4YY)fU2d#t5-}cUR;V(pd*QR$rr{p)%jpFZpw2yL;1P8(Co^JV0#qD6plt?g7
zV;k3(rx4-w>s|y;JO+v<HqX;_(zyuE5((z*$jR%@TZqU)^(~UOpHTXB>QoeOsM_${
zw&#@5{UR=QO>SWXC(Osv>1*dBL?}b+5${3n`qprKyx+RR{EYmA>%vcnXf~%W%SvC~
zRQ$N+5*m`R(`~!8Zl^bVO3AF0dsOQn*4L>ywW`zhzqwIs`}DZ|!wP5OzmaW>z{!kS
z0lI-`6TE+SQQ?)W%6K%k;$hG@&f|2Oj#oQY>n8qO@v`^ZQS#o@9XlZjS3(s-htPFh
ziBYIfG_tW#ud8HY$oel-`(}USgKyvUo~a_5sPl){&V2A~ydKsvs$Hy`kN@a(X;+9X
zxURYxg<s}Y4baW=-}&I%cXhhC=_YF3eD23S_%;r&o11UfUn#rt@)JY1>*}Y@%~;Q?
zrxK~Bf1}#^&X0e;+8V8`??ZF-oH6#3->>!tHTV5!BkS*hv)8MQA!A4}{(+tw3$e4T
zziU7B{c7t~>+b-eMh;i4zfb-2_p7~|(%-9U<F}Pfy8I7g+Ncs7=q}myX5*^Yb0^z1
z?4N1}TIa95cy4p_uVpO5!R_H9kyuc2c<pDR_>j8}5&0f{2zkBp{LgL<9}o2~9?Ocy
zXa3OuoKY)>K7`0B?yg}`f*##ybR8MbPE-|*$DiCBjYz)3$t3<#(OLb+QFQ)mS}zH8
z5}7EJkV3mtPM35%k>L5E{!c#mc1BxE;w{t}QVU}x`#@5YvXjwG)ob9h|MY`zYtT}@
zKkZ|kJ^#<HOZ!6XHSxWvS$<GMqwvReB<t*@U-;nLd38E_)lJnp`|`i|;M+R9&R%`{
z{#M!9EB|un_Fetd8fsD^qElB-C02j`Z`I~^f9d<x=4dT`ADgY`njQb@`_=BCM!%nJ
zWxd|}%=Kz($QV-%*px+%Y4iXpL+kbIFMq$<eARk=EzQ<?y>{{Y)$UE{^)<Ei0rtQD
z+o-k<aM9SumoBJY)3kndbGTUTd(i3pdhgi*_(EDQyqX?lyxw~1-);_96mQ>Aa(nUD
zqVNTM+Uv89Rla_0y;a8^3GYSDUfLWFF(xBqMaNPQ5r5^8i&cl<<bEZKSASjdA@;?*
zTE{Kdedk!cS$6A=Ja^`FPB$tEhOhsI1@AYaz!Q5E{={!u@U>3ecfImytnTYhqp6mY
ziMti-IU80HhhE?^8c*-Hy&VFB%W9m8$RfboHSTG?HYRbG!h7km;-OQiVSli5(yh1F
zkZZu@cm9@L-UVMRAImabezvFlqyo4{;eSV!%X2F-_~D$Wwjk|p6?ho#<=>WcLgAd2
zhP(JXgWx(E?uq9@;Z8DP?t`!X?jSf2#t*|5zdI0Cyhq8f+kY<%w$qUGodE34=fhzY
zvjUjql>PlsSZ<bX|E~Xj0GuVyu|F6DXXLr#g;2OYd2ao~L2yBNZuuVu!UkmYo`jXE
zTy;Cp>NUS|+<_YT?S@O{L%03H_XOTrM{F%S0y+$C=ZgZa+r&XooP6nnyFGF1=;!t(
z5-;48NZgokX8gv96w%p_?>}-+BJq;^9`YWHp6}|-=JAb|(-pR$)AB3WkH<Wq>TeNv
zL+bbY{Go`z%bvt7qyHK_-jHaun-#y)aVS}>)vVVlryc)Pt?Q`ofV~@ZANxci@z%CP
z;wHRfBkUTEV-S?!P~ej=?*?HUBn?2?0Z`bzt)t(;OEE9qO8B~KNHy@JVU&P4nOiTr
zs8-#8l}se=0I&ZByxx*n>OAD0dc-~MFZ*t%*+5UHQTD4SOC(mNokv!jiKV3@&dS`O
zg^AU}%hS%{^4y`h1!rM#)p>Yger{@Fb$SZ)Wt|%a);YZJ;KJe~3&70qHx7gc<(1XN
z<!J+d(?Iw~<`$+FA6Wr@Zo`&=@Y4&c)5}ZCb1R^bNRW>G!S+Pr;`eSK9dk~#DAUV)
zf6jdWmi_&C{@xA3zhJ%#_`86g9y)-ki9YZ6l?_aIr!jvwkJo&ho4#fA-$L$a<LOS<
zU!U>a?nc|6Y&NR3V;gO^i}T4VP+R<O6}f1W6ze2Ds4xFJ(O(ZvE-tLjEgYV94lj@_
zOxc!%DVv{IS><}aj(X^W)19UIL;gCUg*Kq@Zs7b)lx<1i^OWz^Do{>uqKklF8PBf?
zAcFZVz-&v*H!H`#yy0*7hZ`Fm-&?^EHb0do8U*t@jHlT?jmC7*7_@qYP9F(8_W&jb
zm_$MhKdIP$d%f16^GRmRFx(9mT-%3;8kD<28ZM?oK{MThuSyvp6-?`m4Ka@pUj$?0
zlH<w%-KAil3zRk^_-cR<V<8>;UEuhEL|9KPwQEi4-MMx5n7??!Z?}<d1G{+3=<f--
z4=>L+tIKl}ho&9swdo_P&eZhG#Nm0-Hw5?lfcy7K7nYjM`eS~(372%PAx)Avtxj-%
z0Jz%{4>Ze*<!?YeX4=00Ek6Jy#{<EA+`vtr>cT#uQ!65B-iulG9o5-x>X4lXU?!VK
zFrP3m2VrK8wV|9|0MhVqyMbMy+x0f;puOxijvuVKorpT0G<8;M>wf#;TD!Y})4ksk
zqas*|dD>y>OrA!sQN@L3w^k)(R%iXGkBR>uv|!P{?dcP~7+j3&4pTly(_GbW`;AJt
zEIwsmCkfY*?;c0*U?5=t9LD&7rZe6<4J?;KU4rdl9)HNdt{}MTdz09|LcSK4-(|{a
zn7Orv-<|_8ruD<7e6G2Su|-hrX5FU7`t(@?yHcw+mz&M*6jIeHIH7u)Mk?8FlG{BN
zoZp6)6ZAp1Q>)lm4G*6SgNIDovPDyL;+1*W6$U%ksC8@9@xE@??l8FJ4RNATSQ+q3
z<DK~3V_@f+Y|fM}aGUNmFtSgU+;$gKn~h+bn9sciUdw&eulqQ}+dhpBVA}T?IFgby
z@+4XC$GGk{Fw^M1W2aYf3iCL|hiVAf9BRks4cw}j?B~|87{L4;G9DPWWh0h-i2Q`_
zrR)|loMj^zE*%DE*#(Bnguz+1f#I@YaF$(QxLg>VWeXTC9|mWQe}*fB!C7OU;fi5!
zmJMLIk`2e>%o_g;mrB}z=x>I##=nLQbczLQjeiXr=okyuvIQD8&^Z>YWfwGTpo1(}
z%PwfxKqpzSmTl0mfsV3ZExVv$1D$2TT6RIh20F}wwQPfi4Ro3XYuN^dO-J>cWg|3f
zRKHpFLBmG%n`I+3Y*fElwnD>3^_yicG;D9bk^TEa*p{2w=a8$I$-3L==t&bETWx(~
z9b$veF*5oYII~NK=NA_a<+JqdWBAs^dSz+p;l(-Oe~t)y<vg%>aPi;+)01#dXBH>n
zg08^d9vS@=(1Wu&H@P@9?X18bS~vt-I3j#c=b`C`;1f;FP0|v>nOH^f!NaT5&g!E}
z<ggR{yET1hX?2-=^%1eIah6t`M<yPec9y3nRu&gvgGYov<*YoqvI?}s#qvWFt8<GB
zj^u`X<q@%d>tDUm{4pZdL<3etx;;J35qypjp9dEg=cgxV`6FP-XLpQSE?PzM`wYri
zr26l<g;kO;{ryeC^~mHb;i11LNZykWp7r;<`atC$#yWFm0_&W`Nzo4S*_{VhmavGM
zUz~i<`SRgutQZy!KXh=KPzX7YkLvWhsDj>xkU1F2q{ZLlP)|<IPEh4NphrHjv%EU*
z%uLG_BmCQ$xkHDSrMR))!V+@zQBn79)R|vAgf5=Pnr%d^f4GmrtFMp_q1U7mkgog^
z(UU88f6Y0zfrA>jvYFNc`%W}#-hPk}?WVO3<6c5nIP-H4&8-S86UgoYu4RpDZM_N4
z)K}U3goE@$^dppjmc!6hXMXzO>3Nh9A2fC}eh7PdWku@N+zhEOm?j^1WVE4aY&2@$
z-0&U54n3l@PqrdRdB4z~kCV)4n9;wWXX^n8o_MD<lv$~$l@VG&_sP&$xefncSY25~
zr_d5v)amC%Hk-<ch8bVv^NonL97$|(`B7(S_R$sUII(^~|DsQ6D6e81W57!Mw8k<#
zsil)6nff^um#p8ANbFWUC;~t5tiiSCP}+X0ivtyS)fe843+Gex=$M1d6puQ17j^L1
zp1px<d-lqYyZ4WYUv_EeJ-Y|OQ=7k=_?&oecj-pMQzulb3{Sgu@7q^**UO&kBs1ld
zSIW75wOA<SOUZPxQZ2iMT&3cc)7e~Z|6Yd7``L1`RLK^T>2x`r$t82eR5F|La@Bk}
zS;<!RkKLnT0pV2(xm2N;O;@tzjGxOC(iyj!bKOk3T=Msi2_0WhykCZ{kUT|93GwOU
z;&K@=9)_n5jC>|#`-hAyME`g`^$#LjB9bS&WN0bx*La`r#Vh;$s`1V!ee!NG{8G%F
z>^Uwq^4bW=g)pmi2d&vnf-EaJ?ie9FEV9_H9UmVW)X;b%KqI!J4UJe(L*vqi?RLZ}
zo}m#7n$S6RFMY(wd?>3nJ}!;jP{4-HlONqQoo{c3&_UJr^IL714bk^(pmy!XePhyw
zyb-_=+hMjr(KsGQJlE)8Y=;DJ@IJ-mk4c%yGi6wqR#Y&HYy<TD9@h6CAUMPYC<yJJ
zs`xEh^WxstIszVmJE+Fjc>%Wxsp8dydb2~*5c~uAp7~z*ENt_G^PK^{gZY9*-knhU
zRm7ad^FB;!yAy(AI-=VbHQcZ0y(Qo_#j|)@;sI6v@sAsRhf>+`aWXy1>fpi;@SIn;
zc5FAedfQHwY7KGIjkP~0_350bhx3E$ZUaFg&v9GidO@bLd>8z@-H8qoVR6qcnfnlV
z+^t~W6|jg;Ao$#tp-mlVy-o4?%I$*BX_EN3`nK<rl6Rp?H64p_qIVp~*Oh(#imY1^
z<iIz7-?>BJtf;PquOi`3$?xJb>&+YT8-!5Nts^CccC_laG>zoJyw3liz}v>{RtTp<
zJA%6+boG@`91<1njZj^teMQuj9NnS#nYx4UncWwHzX$s+<X62c_FbZRx(Bg;TI)P_
ziQ?_c-TFdz$?dMK_{y(YQTM>?QE)FZ+*Gp@0PHX%`H~Xns|-6q1C@g2y_HNI!he2e
zB9Vm8rT3jwKRW9h^=?gUdyAXr2=-OLE@7VTgH`+9>WVt(;H{(o2VkGQ(}KnJ2BM^0
z-k@jLI{^DffIW+OTH~!(nvD~r%eRjH`u*5bu*>8@RYoHd6(DokLnB-8l!BG%0Fp86
z`gJ$3mqoGBPkxs6F^oTiOKJ(1=x>V6QTfeWZe&ntDJa?(`VH_jcAwZ6Iw>|jL6^RN
zavNkR>9_bhwU7APuJ~FnJCFoMEjCtYo$x!rwGZJ*-16t$NBIEvIZnNT5!>~TA-t-5
zxslNa?t||voM*N;zT3i6G;Os`FszbfRl*`~t~yn01E|eMU|ay*|C4<20r*sxDz~mP
z5FxEM{(<IC)s#I0smpfe(N2u@7Oif?)xg|?)N(Wzv462HYZ6?!(#jSbY>A0E$Mfqo
zgtp~=j#!5P=lrBx^U)grn|*cY&dia~q~<AHW{Qzmfw3=n0OMqjl3JK(?Fm<Pi$!9;
z&NF)Js_}4l7+e>yHrXUkK~;f1@H%G}`{s;m6YHFG*3FgjzF#b30aGa!JvW_87R%*g
z)-8HoHEGs4seIN;WwOOgzL-sx@<}&cEmzX{bQ*u<{6fxN=Ooi!IhQUJ{UR-($~iw<
zD&%v8l2^!7bD3lourxTB_boSH74P{x&=s)6N|xN5m(7>FWF=j2{Y*ZaPp2xr;oUF0
z<x(-7%~lH;w~(!7OI{i4x^gv@sk$hzc`y6vWT99p7u-}fpU-7{w_JowN`57iD`!(B
zwMJv!Uw}=$3b_}`ST*L|qFXL!(FN6v>z92u?N_VmY@t#~8Q#;$Y&PqcvzbgK<yA_h
zQZ8ReCH)H6D-^3$tQpPv(#@9(g_4`e`EIq4_bb(EvXBLhqKod#6be1OKaMraRq$R+
zqgS(;bh1<=sa8wA=V#I+oTBUI3$Ee4m{0p)r<%-`(kZW;2h$ZFB6ri}YR31fHt*G{
zTdt&XX+M|DmU9`efI2{ro=7Dt$#k-Z_afFQSHZiVOQo~bVlnMii=`6yt!7iXOv+C}
z8{BLmYk1FK<J+%7+G)4oRVscdl_{kw>9kwMcQ=!_dH2(~ikmDJlRi}`mi>GIt*d&)
zO0HDOr!Y3uTp<0s3s_GO?*rEL@x3nQ0*UXLkHzAPZ;gfTS<Hno{KfaIh3_&Ps~CLo
zBNX_)rF`D)@SnNwg?mhQ?y8WKj^M=FD;<@Iw^pG26HFVvG}9*E#8*!II{c&YaSvPB
z2x-x0>BRI;C1ZQUD{;o<)*Kg$6+fA&mN2rCg=!k+saP&1bNLFamz%9-gcfm3BMTpV
zkBMo-8C(+!h;6NjH@p|15i3wbBNo)q*a`pKv?EsS4UJe(Lt`HPzM&C2Z5SG{poYed
zPuVnL&AXuy3u<V*5ug!kh7FBaP($Mq{C*>=*kNwbh_m&E#+e_oX~a%ihDI!?p)r4#
zO(S+vH#A~F4UHW?Y}1IH1PqN>P($O5AdR@`%c2nnYG_;<3$!E7S+Z!vff^cTK5f&8
zo$L*bSWt7X`aCwF*fw9&s-ZWg8C<Se>w<wxtHdvIya5}5L-EB+gh6PB;%yj23Bw=O
z@PqjaE<3KCz2Wg-d7#gVOkrIQ{syl=A(z1bMo*^hiEHnWT|7SC6O+C=MPWTjer`y<
zhUwnncpC<j){~vP;`kfBe`DAi9+9Od+jkG8C*O`!6u#5oIf*Ym(h?ViFu{efGV(u3
zx2wuF)c3^6RO#X{JrzQS+p_cCI6A|Nyq65`lUxxr^yXQ-Pa3k<(nV~`_#d&3q+!L{
zuXzTsBZDK>Q4Gbg4{<3AM_iaB6vwLp9I;EVP#o`m-sU6LAq~axWYWeF>u`qR*p;$z
z#5$CrI9>?ih;tZ2aU4kp_=sCFh2q$fv2nyYm7zE;1aQPUjiETQS(}eor!W-9%RwA*
zPG2YvFBjk=&Z!H<@m>H&tkc$mL+%qjg_8zD%=5H?h>cBU7byk}d&)TuYlW-CA>-JN
zTc;B@r`6RnUg9xjr&o&t@Aa4qJim*OIe7lM!o9sTB<|tnfIj@M#p2(L?bqnF%rA@&
z$$$JjDfVhv=2Kr767O(w3E+M^7WZakB2a5xxv+0YzT@SA{ZX-ptaWAni$mfbP9}Z$
zaS)Hj-~c_}j9fH&Et^ZR_=onr+sJ^xHO^)nef3Lmyl={v>chYFKpg(f$VQ`2EGs+k
zyoLYjV~fz24LYABZK^jRc^0weO0#vk$8Iv*)`J#Y2gwUcRD2$q_wBnj92VIob3j&r
zS;Jnfq@A2pIK??=btKd(ztB^DQk)s3{7hMYWJ=b@o@yNjR!&y1BgthKO&PuecZK$m
zWxXTQq8>J)ao$cQ3uxvzZ=yA$U|OfUD6HWu7EXxcH|!=e|L-ao%m@hRY82o>#oZ4H
z9QLwP^H+aBl!?t-uF3qp_Mj-E6p`T0I%LEBk$6bJAcdrP+;>j8T^tFatEO@Mtl73?
zh($7u*OQeVCOIeL6)x{!TiTM}xkXtIUCr!4ezINLzT8vh5UWV809}T8uMdW$XJB4h
z>BU2e1wJf1TOKADwPlXOK#sLz%(S`!hIsJ&s*BtPWQkDPB64TYSCZ%KBZLR1`kF1|
z-RPr5y00#Za-3(xwf|y^+Tx-6DAl#fEd0y^3|J3L9Tx>`5DQu+XZv6%WktS4%XqeZ
zr58`9(yp~gB)To<1&rK;7uSr->jQN8fv*w{Q!a1&Cf$*;cvF_+8U?5BA9HbN`Gni9
z(Q)aHQ-^+2ZU*JLyn3shw;^}-)p+M83qf=1=x<^jGxF==Ty?e9#xe0!x<L15NS?Qf
z+=-X)2Xa8<S#oF;c0o?l8^V-B@w=#hR@S%kBShXsYfB>WjO3$rY#lifz(e^MlpB9h
zem}_t^qmCtEc4wyhEXr!{|b3fm(2GQ{CymIS(nxKlWzMM6;Q6o_eKdqOmp-VW8cC5
zH)tCNql9EBVbqyX0V4-G<!c#8;)&YuoTTAa*1dWI^|=kt%kL-o`wVg${tWU6pJ8<h
zD~Wedm<>66Bcu0XZ5WP6-Nk`~YFQqZ@vvXu_`676h=mvgXy-wmXOI_hui_?*n(go-
zXQop-*6_VCqOl(?hqT*Ukq<F64#^(83A#H#)_-<0^|grhV?4-lbKxeUuksV+?15w3
z)Y~WIBLJXvKif#``$xg@O(?|M*A;L3u-DFQBi4H!7a-%N&M6>G(|2f9vk$rP<KsGa
zey?cpu6uTWC7n-wZ7+mOjpz8z7;=Nd@G~zmjWLb{3nfT}?aH0lbH7*FNs<z6yW+^N
zd`Lt1byAMrM<d{v8Su@0b_sjoVSEeC7$2tz1Nn@{@RF*O33vO9lItwSS6F=}6@r2r
zxkt)R^8ALt!?7#u?;|y!l1-(GIm*i@WnKJailuy|fJ~4Iws40AHG3eGzk9FVv-PT}
z98wR`sdClLl#<m{Dwi#L#cU~)ucix`q(vhZG?DmOC66bN)64Sc-2({>yFr#AYL8)P
z1c}6V6hCx^EQ%l5msi6`d`%jAKcRRy0$U%&gI0#CVPmMurf&{l(v9L{XwgOn&WFaJ
z`)23Iqxp%Ka3mw~Rjs~xcK{DVi8qpsp=xXU{Oa~-Sqv>%Gs)>V|3NihJOTg2jQt_(
zOGs?|$n7?cSfgOLL2R7kV|$U)aUFC}2Z8v`v^NLfjaLX{&ZwXmuZ1rlKRk-hp?cP!
z)PC_Qa!u|{cuij0>UDy;MS|zKS7PAUm#4gvdvRug5@UszfP1CuIL_AgI(kj;`T!Vi
zYxh&pZQX?K!G|#K&F?@SN0j`A=?_B2ef!)1TtoJS;Ei?g2=YI!k+;Bs42~CKu@Z@Q
zcs>KD;m1q=;8}s2+%$3r$-kH1DF@`<g!#_v(I@nG+fy=YymuqYSw{7-=(cP^Cv*Ug
z@$Nt#MwIL~fma8wSVvwMfOi;uV}v{=yt||M9I`JNrS|VfK0`S9Tn)v-+(xszh7%>k
zp?oBr*8)!r0eiplFGhAsUPX)zVG^vQ5icrlAUhW~py61KR2d!HDSlSKn-xX__Xsvm
zG8k-!T+dwUg%jr|Br=YJ?L;mE`cwGHyng1gCrz1NLvz_Pn1lCX{VQ*dskZ1sytsR<
z=nTfq*h?HsD9fqtU=!C40UxcaseDTUS3c3@0;;^$Ky->$))q|SMjWGvfEmZy_J7xF
z+x|#s2XRcS!qu&jvK(hZ$^41)5&v1&?e&299B~CFU+d}=@$NyMpY{*-VSRg_THg+P
zwpmaSCzY)u%mLD7{YK{sHisVvbpyD}DQWqcn`h>Pr?Ea}8nJ8iP*Ls2+xF7#En%(9
zxcbf;(Aw1YK6Hv}s$6!F;EL_zLaCa|rptb^l=TY9Y(AAQRx4KOcshx#-AvN0cwPbd
zur3`_z_JMc$$B}gl<f5DY^IoW{dCdwkUyUE%gLmNRPGE?y3^HaiH;^1zQ=C98orT@
zUhy)yO2(_Ei`5iXftd`FymL7a%jE3i;2suqUKxq~S=U1reg?-2QYAlI%%`xv%LP;3
z0fF-fe%|%{QmIhMQwDm)&y|v?aweOsilYX67W_QUAd$QW=8VUQ3=3Yy_cY=KG5F$}
z0(`uVPhic@`Y`Bhc~E6d{d1eD&$?}5M|UEQ5TM_41|2Fn);D5cFPQ&}G4&&cgRY-N
z{9q9MV12`XS&gR`MSTt`#Eugae~1M&@rNf7f4EP_A7V$Cp%DveXtWT2Ff?LErlAoF
zYG~|3Ou^8I9YuylEU2L|f|!A!5jzwNjaX1a<CP$dI2&Wphyyjbofi;uV7<KN*)S?D
z6jW|`Imh5>Rp%65!216>@)wbhxp@Y8P4Oh+0?gkgJP|}CqP-N32^>I7!01@)K(=R8
z#NFjQ{8|7<>_830QODZd@DV!@Lvd`udfniN9cZCA_F>&^aKsLzP#km)!@?0aPy#qO
zR)0z02;W)Rv?f_`2*%&VdYX0WI*duZ&f#^#POPtipYA$!yVfnknC|rc^aUG69oXmk
zTd~$feg72hwZ%fF*$}7e<!#2iKmDqN(IJ!`Fum4U!#WqZ^x1udjBYO$S9f0T`;%!6
z^C?<`z_wyP64y)D+SobgtC+<aCxvpd?<han3qWfRsxN!Lf5i8n@RF-r9P5HFFfvNG
zhp($wvQ%B{$Ia{dy_%t52d-9(KeL4O#QlnsSYKbE1`D{0K-!hJMSZmwM&S)!@+pDQ
za*j8}@~X}mtS|28{j;b#7OinrZ#&i!fqGant9%BFno7@5ME9$@Z*8isA<nd4#NMr@
zZE15PVaSN<cCnTivaTk~b$4O^km}MicV>6K)?ke#`8s8U5{|Q!4c#|}udC^DZ1Wkc
zBS2SXi&%|hDjffK7yFf=a2lh@H(0{H;Qa}a>Joy{z`Yv|r!gK>agS%P7GT|_(G{{+
zYSF<33C(q<+1W?xtM{XK!k-Vr!NlZ#XgC_yt#<^D2&E|F#+7;#2~fv^iU}UL{(1P@
z_j9a-a$9V2{q>nO9jkvEzI0d{NG4ccQ_P1|2g5UfT_)p*PQ@NRt;fL^`!tugh2v!g
zhC;1?89T=p&%mw@;JI7rR1kOTFlRdCNb55MqdHw2XIB<g+!4TY=2zjzhT%0lYt)9b
zQ0%%`TtbjnI(GnmXc&GaYap-t@`cf{Jyem`jju%13-Co%gJcsY6x}!AUozcI%{JrX
zm>_hblfDj3tgr9cy-UduyzU-rH032wqyyhlbf3Up(q`xy_WRB+2V5eMwm^f_d7gL{
z{^tD&oBe?9@^r-}N!!~Ze9U3$vFy=Yz1R7Ys2lFnDfmG%Yt+hTh^mH%XW`$n%&%g0
zkK5@S#J{#FPhdYPiU+APgU}dvnKwAurtF2!9EDda#O6?Io?nZ{y(!G&Y7Cr#AI?0(
z(`k{j+xBrU6s}~aIj7N~3;H>bFQeRCcNhHU&DLe#`4y|KA)~KD(!TS>y9|vmINp0X
z10S1t>D4Rh)4{^womX?-GCLNHZwQ6gD<0<Wt!u>xUy{Z$=U$!rH2qEvrsa*>bE`^4
zW%%vbOBx2AeWVK-J_ITFV7MLFBa(Or!#$<pLY!y|-!|+cNqpgOEYEWSZunIO&js)q
z%!~oLyw}#kJ`?NDFmsR|&*CnN07{MX2=<;BXP8b7&MX9@eDJ~I^SuE$HBW<;U8Ci;
zKZ7&3QG5=i>l&lk+nwD-I9o^^49bT0hM$ipXP%NccX~}c>4<>Y`+3#EIZPj0IwKDh
zpda`S#nv9f-!Qmz-w1t?=-7YScCW<cQM7`Fv|0P9UD5Ed#di2ybbYZ~8djTqzAbw#
z+EMOEM;{B&v6EA(Udv&>#l%%!F=ZTEKwrxJ+`ab+diKh=zm1SHpS3vO58vA+je867
zc%d^!;gBvVHkB;_0JX;5>Vxk?4SctbQvUQ-87px_A1Mk*bwLV#5IMn99`?2{_z-q(
zS8}1d**-6Mr;9(eoZkz6cYN@Fhg$bfp)8p=RcYb)0zC&tZM#e18$%o-NqgdJ>dsTg
z6K5B=obrT&<p^~N+1xt%V~D@Z{)v1;OzgFp`%{r1KsQv%P!hEj4<;pEvtcQ#85aQA
zfY@OduRAgPl{okgy@(?3ge3g0N5jip{A!ELjOU-C{+B$xF`y2hdAlC6yk+#qvHn2B
zibmf?<9MTavLSCHrMvll2C|r6T6}nVc^(gV;c+nh@Ll5bOH+?5E>DU3$j<@JvA_ss
z7kJ0r_2TgWo-e<OK1(HPoer)__x$n(t(@&wd^q;-s(@2@8Yjh5lH%BlcpVCB#3l|F
zFwP_B%Tz)FsS^?OhLnOb`u-;3L@C}sZTqbz8r(+D;3=WLGc|7^CIndA=#FbuaW|_&
zcRQl(cPRauy;+pg`dgRMISG>GcBT6=7sS-1^8mjBIbDIziMV4`-keVI#QSadenVnr
zacO!%|9vJgLr+PGa|CBTn@F63-;R1ttA@+Et4;BpoT5__UqfC!Pj}PeEe7fj(WS#!
zXBiw|n?rdHX*+I6At<=RbSieAiX(8G<~a*?SW4sL(*Cn7>3(+5Bb%sY!ewvEGLo|{
zW1I0L`V;j~CMC&ZdmsA7d^fh6?st6wayfvtC&^LtkIEov_$Sp(_ELTXH@y511Uj}q
z!TIPOWRlrzZ59gpliNYI4|t>wS`4ymNbgZjveBhHCa4dy!apW+Dqmm2w5kqI85)-a
zoRGZ+1PfZv={!a@K_pBu%m1P%Gv9gdfN19=Uv8NOS=nE6Pv8YL;Jr<apDO}J6ziO$
zmr*YIrKb|p!vKM9V}w`MTg2ly#?78>i1VNMd;A<lB3I+|dUK;QMkgmaEw|!-ZhRa!
zr{ZBOw}BH-9sGu)3U#VWWA$$Q{}ud8G*6KAtJXWpjKa2T9bLd0ZA$5iD2IaMr83w8
zdHHawOK-%EjQ;UhBJrh(<f&ve>z0#V1+g=godmJr!4+J<O(*s+ejrECqw_z1gF4}n
z2*nGK4{~FH25lG_{eQvZ(#$*_r<j<ZKRAIGKxPgvh(|R{9Q01et)QrJV8y;t)~x99
z`hg)YVyQo^`s)P?N3Sn$stn>dDtt0rZEEk=)x1x0cOenc-vdM+*Du`GI_wI|>uTE?
zu?anNW4W!fn1`;et$Oo0R0$tb{W=0$d97{bG<A*#@frqCAYU_Xj!f{nw~l>}YvmUc
zjgBkP-PG5L&szTJweNG+0WUA%*rp%FeoO)OuSo~ekZx`{`ecgqyz#1lQ>sQ=GO%mX
zUdT1b0pxvAo2AV|xu|Vy{!4Z_ghj<{+q2le(RF1RCRn+7%rNhS!VtHVA1Zlx8v8pM
zPftTQMz&?E1ru1CNroBM3us(1K@J*3Qf(qes(;t_^cP{j0x(B$7`l$rjW}!UV^%nZ
zUof+5(4&Y52Y^r9fsXx#vwueG0F7^a{OF0Q@cscr=UQKbpFnwem_u6C#snq)&SEiw
zHP-OwYsqK74fEKD#3TI@USm-vF%ARrRSwjT<g?Q~=QM)|A7+j293v-9@^lkyMpyZY
zx?I&;fN%PDbVeE{_iz%J)Ch+S>jEd0{dEHGF&=AJC6XSM{cj1RGvc_Pu4Li-lZ3c@
zHBd-=()wjfke*oGm@-N47+Ro~J&@fkqhr`pNhBx|i*CW=LF;9eM-Apk|HZZ_w3=XV
z1dW@{JpbJ*{~w)1j0UDRpZ*>C%b9F<@fhSmlGrR-L^qSun@Z#lh!u@|ehmIK&ex`B
z4P!ktCfYnQx&_~z2@;jY<VpW#WOO&m>>7lJzVUlf^j;aYj=uk`;b(>JjOFj7SI*?}
zs)K2LanhMxTzpW#-%WVtg-#r9;qDNsK<{+DuJBAXXPRxO;bgrAZ$~~N+nGc{x_T6W
zWbjvvd+P8*OL*044o@c&UEBXJ1*u^24iaV9mocvTV80y%=J7m_dAkqxkl&S<S7E<o
z-oZ-(PV}(c*oA&mC-J&}ALi#$LcUWjpujtqU9rnfcYQK^yr#s%0I26}tm7?cJgCtW
zFYH3=@b;@-Brp$Cm}g3IKiezw_AYR7`Fo;VGA5anoN##yW4V+N0~54x79LnoU9VX$
z!$$X(!+OD)mXEIU`J%nBlO?Q|oiauqEx_0k02jx$Uxb~MFd#$^M4@?5Ogf}44<hv3
zKd^Rd0A3h3tjKDZLUj9H7ci|hSdwE+-3CDK3euR~mN?p52xt3f8vj93KhEo-BDI&>
zaSHp`C5&e+3@vffj=iG<BRHYM6GC{n?m}<J@a+=3KH35M41L0Ao}@SH<@>In$@;bi
z8zRd?M}?k?-r26<pc@j+Jl^>w-C<f?#Iz(XDC~qb^Sb;MyL<|0<N(y=N$j=C`g0vg
zL6{%S>&sYYaQVa37qhVGOY%`JDMvYPu3`@}0B6B4ukUIYP!ggMvxny84CV%j1LadS
zI-)}FAM5c?=f+Gq+Jg2fOR_?P#pY)O>yH2|Sus4(Qo}_pJU_p#VU|VEMYMcX##5N*
zRqS&~JS(B{ecdiU2t7J3IziJoh5avGf2w>ejK;HLL717kE5;=Aki`UGaF{-1Tlb<Y
zS8)S!tL5BGS2#iA{c7!$=BM=;fy+UB7%NMQVN0i83BZ79#Srtecc;L?gIOfkkQrgQ
zUJjP8>#+qI3`6@mXcOaDr#Y5w5x47A?5S8V&1#j_`vG)XH=f46ML(=Hu0fmeUdA3l
z7%UtbZ4sHz?Rx{T0fY?mMlXzoh+`rz-zV@`B{Vn4vGX$G-QcIPCQM9a?YKjJk1RX-
zc~Pbga!O;(afdACT-4L@XZzx%#rMAZd63^I-iTt{bWb4a*E+PJBCM^Uo6L%`fUvpV
z8>-CiGcNP;qFz8wT=q^um042YvTR9|o#+S)U3K6C!mp4r*gj5Wx&-!O>nOb~bx!!e
zVt#WraCeRfuLvF6I{K&ZB`9}T$J1m)S^xt?;2@Zm4I^SA5`^L`8-VND<=tkNLg;$(
zf+60c;7-|ad~;F&lI*|4`M3>Bvr+`y85>Tz73gbto(LLI8}3&4p6G`Yadh$@i9bw7
ziC6KjmId<{bYr1&@(!EVBrNQMJ@)0g;fgNnwH?@BfjrMjUa;n{CL7eDwxc+4PLzu&
zR86R~Z_)A_9@aW2=Xsf8b>p0`sne%OQTJ=TI18U@T*TcdZHxR?sV@|d`vQGOZWB;K
z2Dgs>1#IM#g7)FY6rPq84}HQXa9Wr*@%B0*bMSE_EI<=ag~3kFA`A}5MPZ2qUV=Rz
z28(y>H`*OEZr(qE&>s0Gzlixf0lsi^iZkQZp|Rr9Gn~l8hh=g>P9wFWb^=e&BYqbH
zzbXMyg^<t%O5jKOK#6UV#=+V#OSMFF5E~bDa;G%xnBu1gR@h~AED~cy;{BY0T|kdv
zytR2@#B{fu`A_%>rL9ApdDX5P6s|c)o!(r9AKCGfki+4|$u`zpC)a!sX`Jxecoo|B
zL`>C|U!Yzp9bFM^y<N*?U9GNG#75R_(8+&^4t!4Qq=fxT>eR&Q;)8-IZ@z`UZUYYb
zeuMZfGT8)P`gWuE)^cg(PBn=heZNV3hdjvMS>Lya@7*;RUQxjCH;eCdLQQ_BwJ72F
zkobNA&sH_t3YDgDizutmgfD0_pCjTs9tf%#em*R|bxzi*xF*Zu=Ofm4OdYzd9~Iwm
z?-d?}W*)bSZ-^K}Q7c`8`&RLN1B(RV;R~H1-ai(AUupRjAx_wut)t8E6W0Dp#4&J@
zTw_%zvEXa#sE4vQMHyLjSw#0<{TcGD)EEK_*xtaVJl0?^9^>OMjiLi?2kr^fKl9gw
zyWQ>9WPOs&hv3^_HNBv&t`zN}Z#U34#9112J{lv0+DqSWr0?pnM5@U+Zldq%!aJIe
z4uRf9L2nMG41=HcW64&a4z;y{^4CQ9l5ogW5$xTqqt8Q57y4~TYodK@9xf|vr-XSr
z1m-b9B%q}2B3#dez^(dtyAVxdoJ4nG8+h)AJ;uDzc?E)bwjZWJEhD}_E^(>9+^cn{
zH_37Az?R)AZ2#qcxa#z&R=rlKb(ue5iebyS&Toa(fyHKUG)LTvCL}<1>Pw%dUQ#i{
zjfO{zst^?VbY%4Zfem&h-7aPl@F$&pin07T8X|k<L2R|ixXZss|F_&)djU845mwqe
z{uO*%U7B;C`q1%_(P{j>BHmS;uT}jO@$e~LkWSGi1(km-ygW(eME8$SPO}=*pl|;P
z-&#}D3-T+y=l5mk&rXN<o$}?ae9iVw9D~6Y(m@I*IGLp2?+d6assca7R786_PH&Ti
zEPfenX5PsRlK~<6Z{fQ&OJeRC8U2rt+fI08K|~YnwtG6jMhXUmaFoF><E}z_BGv@F
za(0+UJU~3L3LP35JqMn}_ojFZ)~%aM*c^&I<g@$5-f@%RoJ9pFHq%9PRG8|JdK82D
zhNgSa?bPrHA}$ti5s_=t^<Ae<(`$#sHpb$}=%X5T#>M598o;Sx{3w{OXc(-<PcYC%
zql|P4sE+9OFKU>cnM#%a2k5Dk#iZs&Oo6KWO<gYdfOUt7hy6#f=-0nPzOJZmazMld
zg(T0TkiEn`2lc3RI~<$A#fO+|{bTSRNjLvi(+KcLZkp(?Kjm`lE!KT`hJotcrrQ?e
zorFmAzpm*|sXH+h`_@DEq?<<=4%0H;q?DFi(QY#hx?>J{K?9Cxcl*9$>R*-XWzw-c
z<HVr@7(7JKx}qLBw@==pb3u>rjv@9SWY)mch6t4wt17RuESxErWNh2|oRdO6=*Z~t
ze%<82eYk4w6(&OH9NkYM`wO0xasZJ&y1ou~kfIU9pQB+8H{g3A+-7`M(%YZn_E9{J
z#}Og|6}(4|CWwCdF5|$q^D(~z!Og(d(ao*Mb#bb~S0-A&77ix>h}J60nDKNr%Hmh&
zxUijsgYsZSn;6DffU%N92*>5Va^^+yK`<BlU>>S<*2#8DJfv%<`d}8&7UW6O;Xn~c
zm3b52iiLwXpw1W}*lR%|6&54ZjthPDCh2k(!6cRcd~dl2*&^IeYZ)s4x!!UIv&;!2
zho9&x*ZQU9{Ud!a6W$4-f>KsQ=U?@~%wYS(!OPkW(f7B0JZAn#<;9q%b&|azqH#y#
z>VM{Wh2m%%9WgPHohKhj%s2A8pfwHs7&up@a$>Hc_4Nh?azTUa!T*IhCS-mQ^U3cq
z9W_x>-{&x92hvFw1n+-IcrkUYuHhz|Im%FyZ6e>_p?Ky);;n0KTc7IrK0Yp@c7kVQ
zu_c_Phh`R3|Ne9EW#&0O|EGEW7i|iiHl;s7KJqGgzheD5GWw_Z+wvfVGeUCS3YoSn
zM}fZmJzx>Jg#RRG2I?pBf0Xxw8RNJ^!E=t=P2Geyfn{%vkBd%|ehSBpMz&D7rZPUR
ze`SA0uCJdHZ~_725$$C>kKY`LN6AIvS;JmM4?n^$Vmy0qiNqt|zOL5$JFsW5Pg)zc
zeEpsPC6ka(9_C&2LGKm#zoqbBG5Ck~JYY^1hxJnW=<iQ_n`vXuTeZ#Li=A0);<3OX
z)M>tueRKtT=DLrNQHVgzKGE|u4x!|nKm0iMgF@kqy`UkX@zNQ{UU*h-0%ZEMhtvya
zeB=EZj`oiF;4FkZ21Y(+!FkOk0wL|@^5?_Kp|xC2cZg^@Tp!xPa@dLWlIkxU(7~<F
zUZ{9AzGn<Pg;T}3vc0+e@C&5;?}WWk_)K{o0QmWaf_cio7#)F=tL8FtEBl$SRU{79
zqP29J=Eu;ARWX}bEU?by--bEsn#MKw=9vGp0+(&=l~rfs4p@#w@4|ec`&cNuDcga#
zb5z+=1Io5xpDn81xdCN6u>OszM={E%vIO?pqRL(fDPw)BV_l)@(Fj-eT~4|@CSMmY
zX66|mH@`!S$TgDt<wr0-?@JuDmXhLRvkJfZ9<6YBb9NPX+#O%$nCbX<@NZ)e-V-<j
zD6KzCZsBu?6S3V4^{Szgq2Iwj%VHk;jr;WKe0-eE3AK@B@rr;k773H4Hjf0yxW0<L
zM$D}$ngA#(uE6qoSHN7IyuRHdFxKU#?;^T76At;f#vho+-lWzM2Kk~Xe>tXnek`Vb
zO!-&gtAx>K*<KOlMz>5p=vTf*vfZ!jAKk||l%0^FW=;phx=q^HcQ#iayNBdI%DQLZ
z{~7t-tG~Y+@x28<&W7iC<xTNjsE%poy{0c7|7?h?tnzKxEA5k|RsKv&dGT}M^|>!z
z7Uk^eifB<NpGU9{+t0@r^?dhMO!<Y~gX<?D{XzI&j40=J%t9vnEU(#W1T^2sd)wX+
zI**%nJSEC`(2U)E_ZT)T@xyes-ADC<^Nn6!B8<aumqXyDbjBa?BW)?Y`L{1I*AY1w
za~^W2CgHgl`|^S)w@l&q_~8|7b5Y=ueUl{ilK0t>J(x5cEpB!YQ>-B8P+c{wZ5Hh>
zYgv0`EDL4-Q#%>w^8zM7*K1CQumc7AY4fIyrHzK)g&0u}4}jM@s`LDC3FALM82%y5
zQ9|x)XX*XCKK#>_4y`p==3XdFy<Tf|YBsMgg~83J+kuw-?nawdZ3ZvBnb$}Ap_K>y
z(<iY>(b2xhg-|$u9jSyA;0@s1k_*8}6X#;1jxe5<>slyWQ)`Myw*frcn^y(AvNy_)
zrM9pfX&=9@ElXl6NYi{V3}#tv4PmK83P3nn?#V(3&Q)xKsa7-GQ{iw}yh}iadoL6Y
z5>&EbxTD1ox`%Nttu03g!@blGcMM5Co`>zO&SF*f-)yN5AHmsM5gK-Bd=RW`5BsQZ
zN5CS+E=Lq($*`?2gyRLQOo_7OKC&+omKf0eGXe|P)8}XxV&=Xl;F$K=D7ac>3Moec
zoI4JN;pB~UqZ_l6p>PNsBN~DOglrEkMZzKG1_OJ7&eGsnBZhx`It(wd$x#-;u7;nT
z9S)v#=5i#w#LF_fG8c+hW+F&eSog!z4~D|xI3V7pvD$WNJ{%55j1VJTb=&AY8h^~g
z{6kUj6eyRw{S13K6n1)Y<*@Ez&2M5c3@^cwp)!5!g~K6<TFNS~e5&qJD85r&1Rs1a
zy6?_>IjSBduNuC&jZ@2E@H6!$Cc?%sk-&(3Na^Q2w-O4gCWD|ZG5!};!|EK`Ku};o
zB#xtR*xv3sOt8uxqu=J;j+)_3|2=D9OjJcIsSLEn_b}n(6-y9^b@yojW7aD{D8t*1
zM+g_MSb|WD>jeoDPSDc9;*l_!%;TU2G8kqk4ac<i=}=hYhGL>*gUI82>`}rS^tT{J
z0ApwAky>}{pt$l}_vgED@Xd{`s-pG$!ee2)FQ^-gXwO>eO5!V_aH7i>t5ZCV#XQft
zav`+NVoNSr<T&ECUOpOzUnShGHl=`UnY)AFX$CNU#7l9oV$0XSf3+NnyIos%+o#Qt
z)AsdMFBHDpUiPaNxVBm6!Ce2G1V;q$(rOred9xY@3qYAiEWlZYPhx|nA8)_&!u@l8
zEgYVlK<0zT-VWs4^y7xF0ZB8yH@^`H<H_DOGG03#3M&$Av^H6N_-Z&jc8~ESpfyLb
zFE|Ac+O|FH<#YKP5#`*L=hk)o9=pVtj4fGh5NyCqXdsr~n*yfCE-5I6InyLO0h`o^
zhcb-<`x!6@48(fyx_}9+Uo_No18+IXtvu~FpZg}^)F88d9YfR_YX|U0NZ*SL5q8X2
zZWqI0Pp_Aob=Cp4DcfKz`tgRQ!Dt=ZwlS!Vq`-6Txf26nn?lLi#YKCWFYjA}>e0wB
zm3Xc=^AAGnsD*$T&u>J)>4ktL_xZ;|ae}_-Meg%`XTo4<K_K!%l{aSiX#Hq7JbW?k
zQf=Sf4uySq5{~TZ8g8-ZwH06eP8e>i^6^eC>q+9rB4IRrhTZW*C~R3|z$xMkdp;Z%
zxm(x~ZAoB;&Hi{O-l~n4$L7nSup(1U>&>N~?8Aq%_&zJN&d8-nlI_sgS*oLaq*_PK
zM5g@7VEJToU4n4^Ek6~gKaD3nX$h@;u&yY#<Bhe>4AM^shU2Mk25~GjSEn_9M}9hh
zf2r2MJcYVU|D~RCF^O5Yi~lfC|L_#nI$Zae-m+DpPMY@}=K^(&!ddjs^}rxk6SJ{t
z+k197a;Nb=vG#o){~3+nw($ze@cE8_GxnVUSU0?%B|NrmX9$DiH3_3*<qW~HSo=o;
zM;{TUaYd91J+XORM?#k#r)y6Vj)2`qMvaJsQEqsj4R}+)_u*{2C-IK0kd)CQ?;jIx
z!=4SqHt;n8W6QyYGPst0PPA3a!iM7Zz9?Zr39`)g{S(5Y#tx3r%&FnSI4<>->*1qy
zaOYFKIE4CZ9ek><Tn_<_W8|Oq;t*=C_3Tt%c|eslp0|78q(^9U`RLEvbVSYy#;}Z~
zz9PzytLGr`3|GF&F(AvH_-9m)$~yY|0M~oZE^ElkK6oGC$@5gtK~k8Iv9=edej)IE
z`V@$<%n$qvNlVl?<Rc*wibtUlF(z*nxojVLhjNfbCKYG2q5iF-Gdpo^{9T!!j75{&
ztFz94Gt9hzF{)vKXgo&+j866loF!*GT?r#t?IlL%D~O-7h97&}*(5d13lg8!Ya592
z-YJjehCn8Zyc&vftq-DXY==D0BJK(hnJ!(CKF()s=ss3D@1n~)$Ry>bw_){o9KHux
zf05w~gh&~txrgokxf?7vqK7iZF><3-7Pt?906Q87-4CK^Z8QWHI&(vBfYQ$`;A3tb
zK01Zm@HgdkeFJ6A+(Q$Grk#~(aes<4J3TQqy^M0ok#kVKB+D0<R_7KMCgv4DCQUdA
zM>LGFxfcPuKOqtVm!?-_`a0F;`M-<yqkImTUpSyq6T+TrOm4JsM6)ZHHhN9>?*LY8
zRY0TdCW&0GLJDnq07twJ9-bi@#A6BHrcYIH<paDb>;ofU4p$wicqsn}%D+H$mKPvP
z`TH_nFUJTKTNZM6TEa=(2Spvi=^R-WzfaQdE6XAu?2Gsv$4qJsPsU;>y_;x!Nx-ZM
z9_e?nViOLI<Z*(^r;kid3qd=}(}(6(R+lG8>Vhw#Vd}_6Q2QuXYntjV%pY>pA$y`n
zd^m>>X`6NdGX7FRp5BBZAqKNlpZ9?19WIp15=Y*u)dmFHlU<NI%IR)7y7=iEI8Uyz
zu&zEXU=BFbvst9t)$7O-#AY6CY8)sMErxr+g2UD_uA9Z?L~|BbEY$rrK$+&qO+-`T
zJ5+C$-MW-)+Jf;cn0Y#>B0&xy<xup;Pu~GKJV0mup%61dwaxdQ0={$P5_mm;@gnnd
z#XV8qz{yxVZ0B^aq|@{KUdYUXQ)kZT<Q2}eBOw(hHK1xn&tH##C*<n3UG2kqkWm<J
z3l?<N*AcQsAKog?6K(--WS2UW>QL*_>8<AR8pYsm8T~d!><tO(_9p&wOx*ibNA5Nf
z{7yS-Cq-`gLBRb7=uIN(o*}nYbJjb!0<i(qxRAob2oyKT)l&}sp_(%a$Bo0{fTe=3
z_$@Km9N<YyJPQiXO;?4dS*FYKkftjTCM~|U42us5+?3xeuf4*FQEDM%xL@&g^RRee
zNJ!qIJ{aNp9~!#;=>~F=bvwBJEyLHxWe-)n{VGMv^+$%SkIu#|Va&ef|HH%9Kh>ct
zKAbxG)j|7NKRz-<{dQMqSpzx2I8PyUmpOSr^}|Ppz@x`Q=QQ%~*ZB<=)u~Cmognpo
zYZNXT%u4SSGak-SHjkB?r<fmZ*R8|jkPRa7U|M24bl#E1;K!oyxJb`#)x-qMus;w5
zdmJ}w_;mrxZ5)k)wZ=A5G3j!_y1pn<^nO~{5#sH(C>+#JpvF4(@hCWpmgwPX4N-U9
z9k78?2HT_RgS!pf4^;DDhQuwS6f?SI^pNmMBJN0=X#1Ft{D~G8_X{g?l)TJ!Ziu3T
zWeOH<KAZ&%;ptOUC$H#4+P7(JIjsmi6Vs93k@c8Xq&+)?U0xjQJK;YfY_!c^q|HJd
z#I=3geuI+>k`Bq9<Pd3}P-nV9?yPr&9BF^XN6tMqp@|@VxP6iK3H515Nb<VWY~gA^
zs>$t(v`bWvOubJ@@{-qa#cQN3LY*aPhNV!5VHztSNcv3ejI=|jE4yJ8dm=a&QK@zO
zi4Lg%eF*RzX^Vh^fWzb)X?IZPFouCTog|w~;ZP-C?w?3oqw34x8_A0L7L9&HB4C+C
z+8NXjcI-oLN2cnFaY-_Zv@LUb6*CF{fp*Q5w;t5}NPDAFh<Y2%x`F$1!tbk`pF~X1
z9%V)kBkk4v<lNM1vzL_C-$)x}YM?f7sD5F+kF;4-uj>ayOI7LYJ;^lERy_nKf|gy)
zQxi7)C!%Cw;6;zK>~4>OUv8RSQ*GfopNy_^*m^@n)S~&6+OZ?5&O{4W^N_a)1yh4^
zRo$`*?R?1Zt~GJoOV|*`^@GFU!oeBb@TA)ybe+P(3Kz|*#Md3e;96O0o}8j95h!<V
zs^;R_G`f|CQ1Q6?)G&CYwSmnSDPV#V9(Q*})yEY+vMDf9mE*MdbFm5#&0yX7p~$*o
zzToVyWF{{g&$@M2RK1ycN2IqYS&=_Lvijix@H4pjkiZ%D*Z^4cwAd`L;Xge99wN~2
ztb=z)!Lt_z<UEU0{ACvY#Q_mtQIot}ic+`){>RqQ8I(UM%5hT(oD^K;r}8BDAZiEe
zp<70O6mqyR0n3e)vDNlQr#sbL$GKc_LW|bSZQzmj)veAwgrFFmzy1q+n|)+%VP$nf
ztg8t|-CrkwC_b==Z}UqF^DDR=d<Bbh`(C^M6=jE4rk58FK7eq_%>2Zm6%j{ylJG3A
z&f{*oxz#ybTC2k?Q_}~rMkm_0p?&j96U!6GjUoO%gT<V@Y8)3N;D=}*A=-<mKkZB}
zU`e~YI5~X;WfbF}^__GmdslZPw-F(a`IQN0W^s9XWz|_-K8*h^Pfy}5b7%EY5f&7D
z<hKzYlaEZ!N}2p?(42i_VTyUEfKCq&$j*@bQTuVYu~!75J+BKqLbi?r`2FDNzE4N4
zG_^hO`)8t76@eQ%d;Qty`g&v#a2~MtgYSshN4g32=o1uZoj)?VXCMu&@uJ2I;EU08
zYzrD?sRSOPyK5j_Ju(G+8t@<fL}dGVJzrht<I%i=K)|yUb*Rs#2G$|ZC&Y6RwdGma
zvFQ5!-h-+~@<>M43(SC2Mf6)VyqRGqaDS=NrBkDk@`El3t0`a)f|tL*7>Up&$Ze3<
zDH}xnb$2v>L2pP_fqy+RdgJ|(beEff8C_NyN1c7qbfRV~QJLx<jIN7zhI;0rE{!+J
z#g33sm?tIb(fFaoYD7JI{6u;ngoyfoZ!{j$|BuN2C)w_dhVSz<i3Z8%&geRjPxvZ;
z>e4tGkFIOCv&Rz=ViL4J5nUg&!&i7zo8}5y!_(dEnNq4!EoO0dyIxQWJ^SQ9+|q$o
zt2n_B$>Oeobpmd4N32L>Q-p2)Yw#1%=V7a9QImA+z(AV4t5ivl`udK6^#UtCQHkpO
zRWy&iQ373O|3Er{)xM}h`k#-kW9vnv*G!0L?}q%qU>|EgNjT}$rhB4k^{tW!@5hKg
z*uJI7g~!N2xD9{bk9lWl9(xsVNmiF16|waN$jWKdJGfwra*AtoDxT`zt$iBlTRa0e
z@-4_A;B#uPAf7*w*jIPg%bx3`OJ1guE+)&RWI3Cvq+LH*NLH&Aw^%5ZN_iJAdoifI
zkr4NW$t$tw5bMvWoXN*QcLH&7Tsr5_4On=-N4k!5|3|BfcUH|w9eV3y3?X!h#k}db
zSHG!A+aG)BKfCvj5%4Yzy~lb3G7O&lq~BKi#7A#7Jkh4gG0NP9H(SBJiFj|su!IK+
zxRLpCwp=LYa@lOARLEA-^k*TNO!{s*RVkG!`}Z<rv0Csl<y1cHmNTVnx=_tlU5G4K
z$rs#0shHo7_eL4EQYpE)vRia>UNM_4mP`3e7Pos9)A@YP&v}*oWBU^eitpEMk$j6g
zw(E2Y0Nso&xMp<mq|rGKtG+3I*vLWj4JAt9g(Y!&tKSygF}#G$S?Skf@QTMf@%S|J
zar7fSd`KO+YCaxN?Hl>1!3%Bi+axo22Mks=$4o<Kg>SqtIqf)mt>5W^>=}jY`K!Uj
z4HZ7O%pqReIwVh2cdtRfXBxNO8eX3k@>*b48)z(YPT%=q>Jmv*Dl474^J7Gh)hl)k
z7@H6aYG}L}pb@LWhDI!?p>g>K>~_SCIzuBC)VvdN2KL#=Y6$zOj~PbWvfb#vgQ_o*
zqgRQ4*KUpDodAy5PO>eb#&Pa8n~&H|2*t7U<2H_1AqQ~q{p!yP96o~nPDey><Q6;P
z>HaCc?wj|OuWToJ>cT%0x6t=jjw=~YVNRV$ba89dG2BUPPy11BFWnO*bBwM;){R(l
zqHnow_x32dQSJtfYe{$OC!^{HU09GqJVMr?dkL*}1~+IdILgN{a6Rr8;J7cI3BZN8
zj)3KShrK^&<K%FGDZkiTPD?=4=R0I~BCo*kg!=HhMexgld8QYJ!v%n08SMO&jR#0<
zx6p#S*b8Sb&jH8x;_t<s0fw)rrGSyybG`6AZZlA8UJv|G4{m!YVDa!`FI?DC5%Byj
z_R?KFcn2(@ZGPV9t!KOL7C&paYak$#(50D?;X7gQ{b3EQcTbG<;O}4V=y9?QaUH|U
zfG`*MXB~MuSVx}IHXgc$+jX~%yLZ`YbobdFIBWAo<4S%efJ^M$(KeRcG%@;fxeu;q
zlLYPHF|%){jngc{CoGufBVZ`VsPTN(#$$(njLe?zfw99QK&8ja0o+|+`XeGF0(kC=
zmxJ)VfqRX26?YmKyz+u@_k>%k)7C3x-(Ulq_+Wc9wJQLxV%nzsSxmwPpQ*oJ+0r-n
z*ySzknmVpLTr6Meh~j|9;FWv1K8`5jy_*_t-NOV_Z8!DACa<2wkvHO-&pTY)OZ8x9
zRJxv=DW>thg4oO!*N+kWLFL14zmMS68$QEKZFA;*5XP|$aj;Mv5mTInLi4fp^AR|r
zraB7=pKIBgjKC3`@^nqke|tAjuW#Ceu1P=rBG$*co&D3E&Y!GjEV%G#4|*nXzJlEZ
zjnhnfy8L`DSgxi$j6GTZDDvv;`qs3kVdyNr4P#Avx@|j(77UQ|OlMlZx}_joXk-ie
z#WKr|2jP3BD7_Au|3VOM(3HctXZHo`^h`IJ=W{s2uG^2cMNBuk|ITBrW5b6`ADZtc
zzGT4;o<6ipE*`M!^i3Zc?g<!T%}4+Aq5Jpj!2p~+eP~>FPT4Sh(}!;RJH2rI(}$+}
z*0hB)IDKfCH<0zK+hAa5`p_^}4p}h4=|jU@!2XxU6O68FnAtfSrdvmv{W78<&2`XX
z`#AQ11rt5JXn7<awBRdv)~JI$ZJZ?#NdyiO&Me&LdSN$k?f(h7LRKw8@JugVI>LF@
z?}ovv{5%P1_&z#s@!=zZp^eu7<kTQKQ=!)V{jv>z49gZuoWk{+a!=CWz4VZUx2E$=
z2#&JCx^#{WENdCRv|z(iqCMRYB<2<^<ChmLm_Uwv5G&o4{v(Kaw*E8i4Xc=U15OPH
z(zyV7U+!Z(H&L8MZA{a?^b@EzhBbkH=R%YR&jqyL?+3~w&ILSi1I>qO4zy%ID5>py
zE@1nO7916#jBU}Ac3Gg!5)0#)M?6*2(&qxCEq_^-iI(6$$jzd?b6K`)i>N1S@R}C%
zx%>dyFv)E|f77cQDAxQ@zPT>9+Sm)X4eiiyfp$nprgu)lk!DeW%1|d+-8vfe_8*-c
zIS+p_30`!+C|;cPje56M#`Wg%kuQRM6|hSm3W1fvQLll~c)~l0fPEHgCyf^=*Fxb#
zV1G6<+}r9D|Gx-5i+Uqh#9Z+V<e(R4sSnssnnk;(6gDw#a8reR(MRTe+W`%{fy?MI
z8zmCoRemL%3t$|5acU8#3t-_OT`Gsy>k6rIGMy@>llgMl&)~;RR!ZeUDVfciK(*&)
zvwpH#EGMg}QrXR=tGL&@TFzv0rBbSpN!x+ybh1!Qd&zXRT1h1l0Z-*~nH>FF@bVQe
zo1#Fq#rs9*_f_zocdONMDqF}^O2u+ES;j92N|y=+uUty|87s(ME_&H=sgh0?-Mn9^
zWU9qvI$89}2+L>PR5EMxo=+AF*>ojSDW%<1Hd9PjQu!hplFwF4`AV_a!@GC$Rq^f?
z{9-N%jv&oS(M$Px+)&_yf6v2SK*f@KHeX05OUXhC%}W)_`AW%4<BxJB>7~6)J|K7W
zSh18$d-=Ry^hzakO&PK&70TsuDU)=2c^|_b!BxoJFDLzUIpslc<y1Nkb~2@$Tgdue
z+09pz8B1q!DZiY_R!Z39$Ys28B~z;Ap;)PM-p%;g0Pod8E}!+wo>xv)u}@MhriyMk
zU(L|-ip5MmqvX!}8&6>0fOsFUzY#AvXd&Y}_t98<@mgfzdkXRM82-Fi=~(zKASNA$
zFLs0iUs>6U_Yi-c(y{tjGhkxev7m;=ONbvE8nH&f(1-;!G@e3y+0cmXazi5))X+Hf
zahpc0fiN^;K@E*5#GFk#VojSxBhCsM8ru+aHZ)?5g`p7(YG_bg+t7$LbB0DNsG)HY
z@oz&Tc32u3v7m+qy$NS%#12(MBNo)qp!2B~jkw`!(TD>zG!pQI4UJgSZD_=T8X7ML
zXv7+FLn9V6k@#ul=bnep&T|#qPdtDp{Y#_;ST4~Zj|-Rmip+wmt4;n2^YR2@{MX9M
zx37_z$2iUd-}YL0(OZk<X0wiV9#nJ0R_qTL-HA2)wu7m0JQKhXYuH0^?7Pe6Bi3+-
z;&?THBi1m7;;3W4!N_9>8_j~X_Efiw**IbiYbYNV0yts~XDE*Br)@rB4Pz*dmjgIr
z4PPjZGk4p3#4a*IaqPg}hUu4B!xf6-QUFJ+VG7{5LyeaUSZhw<y-L1xA4@>QN8}zV
z?Q`^$IWE1Nh4EHZWBCa7EO;y<ID{qdx_Fd?Ze<)F_wcYC@}21OF>%Nmc8@Zptc5I+
zPyk2iD(&V*N9;<=3X&4@xgC2RQwebge-m2=bs5W$d_ET_qZXLGjpwoVVd|kwwP2a~
z$KD6?e|1(C-1|6|u||HmjBjkie#y1sL@+}41HJn@g}r@5r)ZTeB4B6;Viof2$sYK{
zTh9DFevXC$@m=-UWyUj2cz_45j^a1GBvwaEMappX-d-9cs|M}}<oC`b9NjM+<Ru8l
zIZt%Y^tH+Wue6JE@90kC@JZS3!yeDI;%(!#JG!ZY^9$Y(INNxUhTh%cU`tmV9%5BB
zZ>38)oWVZPl+L3d8Hn!CF|2n)xmxR0A$fpMJ2-Z>hCL!`hgb`uN2!?iL0;`IQ`k-H
zavu9UJ@s{OaZL8vNEjrL$ma_+O*;Rf@mVo7;)~;gbZ54P3B=Q6<2as1=M)G|N>CoM
zvD^Mkpj@8oqBtnbYT|ADtK(i6<~Xp5TXd=2GKNZbji~kW$yyU3TNG0tQT*~_fcZCQ
z^GIT5X%5Fu`0oRWnW^cA>CT2*M{BTY7qHGH8m(HhjB4mJ*{Ae&?=;<!M=6>r3P|UZ
zcpvjwQEmyR)>y+6p7iWm6=y$HjSi>gAcidQt|3-5jq%IZxDa~qu1+6ma4qNaTL@mY
z)2dd-^$Jb!%l+{L;y4;E&>s?#;+Nk>d*4MJYA>Ext2IT&tdzwWl$}y>WynI5kc@C_
zA#qB^9~<0z^!+kojgQOk>*Y#UT);^*==&M{9V2U9#%n2-iKTAhRV8nZdmtE$N5jeF
zdphoUKf!K8-yy!E`(L%4$DqpFB-1bAq#pwRPe{5_CwS=g#9!$yAZpW73b&k!<QznE
z%?2=1{GMRW3Vc<$WrsZ#qD6O}w9qF@$V;X(8q{7nj}0^9>EvFz%!pDhMZWSc5ROVq
z$$Vt=mMq@W6v?UB4}n_KV_%flOmLG+@+27LMAO^nI76krm{{r==;jP_)tmDh9ZN0e
zs^wfMRmzr<`5c0bSfn9Pitt#;FIGyKl8KAu5f*hbCAWx3YB8U!_{Ah%=}YI!nN-%R
zc!+hGq+dUmFXRhJx8%Eiwp2_aT{xdZSgce@r3!@<VrY<piDSKi@j<+^euU)x##0Bz
z6Kal_!nn|~7{Vv%?V<5;YtV@-1>uXBw}?bfekJv_ucUMNukF`#TZr#}P;?8R%W<&_
z(CZl;7mF2@S<A+Pn)ULz5t~M=+87$KpoYc~#79j#VwK3yhy^w4!<`?oX~YU3;4||Y
z^Z5Xd*an8;SVio1Q*E`@WjtTKC2&kGb*-c7G_J~O9K5iVXk5Le8swLML(w<|+rAkZ
zlAEA`j#&c0Hp_W5`!S-0`B_@$$tARvV+!wxvf<kr$%h&G@E0WAH-CWWc0l*w<O*mq
zKSwcNsqcqd^Uaead+wVnh$D+K%#^srLMIxr&)NDom2b2>S{o@>Gbj~PiPsgEwo{$q
z+t_c{;7;RyR`$_X5%=5-zDSu#v^p2yJ%v};b0bf)Eebht&i?C&ixLk47WoJpb=+Wx
zYl*OF-^Ixlv1nBDzpmpU&Z+AR5~1i1xo&t>)oD2ndc^oB?2jiA*Cd>>T>3V*D;+;8
z%b<AFndS|pt%xC_4irOvXaDz9;JfkfSf4J#=bA~#I~<*k^ks(KOQtvC{|r9B66Q?!
zNgzzT(p`O9NB<qZAAz4DzsoiPy(qg0{>2f@i{x9ikBLfEJaP`ddh6&2%IM6HD(mq=
zNT;`sei$$pK6C?e8$gpCGL_%J>y3H%Acwdw{ZqIp47zRlU%aQouv@X`-Un;@uz-F)
z{l~a_&F)8=Q)u&(wtva#^~gU#W(Stz%7<?!5<d&yjNpeKo#N~ZjvvtmaNRoIC1NpS
zd-k3rFT?4MMg6TuH;jup5r#i@lXLYQrMq<h;jH2+><rZV$p!N;i@px<&~yIj{p8^z
zH^}jSC&ml&FpSs!KJpahUIt0Ry);MuqI95FM+WP}14<`egN<NWR1mqsG7JlNXAKvc
z&|`r<l9R{;<JI8?p7vxTETzWl@n2K8F2QavuJ5~Cqr-?gZ{-qvbmq6O?X>jgHKdw)
z>{jPhn`hx~55z&29g{>=_-sbidv#DfI+9~c9k<M|UjQG$#gI<?bA_i4U!3WG-({}m
ze&%frKKy@aym7o_6@EMMCVUM#R*G9RTg`U2>LOnY@*P+5eG`7QhBNaQrZN$ZG*8$Y
z^RM#-&%x(LUDBjM;F{LE2Hp-h4y?>^!ZYx_L934r=?c%Yb@;_$FsLQN$$(|~T!Nn)
z3fqveA@<pJ!0#OZ2eogDN9KqR_KD8wI(RhPIq7ygbi1g@-Fy=MGH}9|>Ti!FW-Yh9
z2rMc1q2(4g=aVnAiaGo#d(Owpqc;5o%<}{@{5%gq(>ZRQ=4}&=nVMoebPJEOv@lEZ
zXeb@@FmKP<^LG5XazSBN5dYX9>O_xi(@xCM0eazQr6XEl@I2Rxr)RDo#1Hu`tS^*X
z3Vui*0zIJDwz6F8CJkc)2hz1?Wbp8H)d%!mJj>)d&`_4rjLkL7orJ%4on$wd*C208
zSh89uUej^=$1$G)2XYHAf7lf*S$ddv!emKzSy5gx`TcVJg{OJ2!KA|J=!?O3|B`<`
zZ2l?5cN4Gyul)(-M+fOq$~A6Y6ba9KUl+q)iG!!t#nINZ!vA_Syga5<rR(41rUKJ=
zV?Z51>w7?HjrAnP>Um)wD!6AK2cZP-a*ae~7j#(}N7fO^ROMXvX;JQ$G41q~JtN9s
zme+NWxWnWRjJ*kq?Aq1^YA)P=jO!7>>+p6e=zi|rB~jfDJkLQ#<Uo`9(S^M4z<0XW
zXlZt0VQPMQ*;!sZygIiqjUqjMXusrvVQrWougs*RJr>3h;s0Y5m-#Ae4dV~ZAMTTk
z9g5QzUsTF&x#U;!)hu#~Q@9W$ovBn(1zZV|Mi{%CG%@gOwvb7=1uyC6y<)18@$;@*
zOnZfFDp^bwf)`(8%jr_Of+PhmRZJlbIhD`m3TfPy;et-mE%(I0--NB9wuo^^1F-+@
zi+JiVp!=2WnuT3p*$lJpW5wb6ulCmOvEyNVL-w0v(nn!)9?&uASYeo0ZY-#wu@`=@
zp%L4ShDI!?i5I^cpb^^zwu0$=q9@@K8$M$j7>Z*Td{=`bwgCYg9Fu%O;2^t&dn|E&
zrsB5fdS3W{D!vL|^Z~K|sTM!VF!SE`V@kK~yp`at(X#Z+xy<8M_^S^ju=7t#Ufi?p
zbcD^pd?$H4!{zXEHd^GpWA&<FIKH+Ge(VDYe5~V+`i+*3*S^T##aRWMm-Rgz3-vHJ
zU57UH&GB1dBlWnZRRP#?%P{_OV-=Aj;{#Lfv4*wQ9kO{`ql37#jA^XG2PSw-X|#2y
zeWz#D_tvQjo~6K6A`%WM4tSfYH}Y|+*LHDhvBtFxaabWU$VT$Cbu@`zF3R~#bq47U
z^MP3uPEnnNh@UuL;U3J-be4vGwt#1GClPjmDcC@l0psupxFkFyqmM%lhYn9HPfgA^
zle5#44_cE8%|{P>8hfJjRIGRg1CMLqr;P7EKbDX$&d~FE$TSkqa?Z-9A2Q?PtL@VV
z$+F^1A(Ri(tc#Zgk$pJ~7@0OP=PiJ?cvqrMwG9Kr_pg9HJXVKtY&xP`U&N8PO~s*J
z#+>-z`^M$?`1{cGAtj0Z-{E8lz@(5TuRV^ymsc{umDDG3S=G=a1s<NW-WGU<W5Q?v
z-4!9n)3eae2ceri3USEq;^^fuf3XS;>Z~^TNpd~jwqdSBy-8@XP)ng@X|tBuhPhCc
zuS^@|(LVgMm}5}>0G{dqc0BM=Yix+SilKA7)}O^30vP!M$pS8(^*zBRjcbP43;QnU
z@X%1Y4-n1kI|>HQDeh;dF!r3tHDDZP5&Hm+8Mw$34exNHUTYi|V8Fp~f+FS#z?hbZ
zVPJ^erR2F2^910W$y29nk!pU))`yfsa;8nRuNMN7v0<*jt}B>%`F@NP6Ty&O`X6`V
z%_;POUgy*?xtwq+R8DJ{VfS7LcG$Cdlo#_G_v2jW=fs`~EzMNM4B3%eN52Q3er%5^
ztE-$DE_?c3Q?{YXSgw?(G!MCAuZlKf5V1tkC6c75?w_Kqmquh=EKj<0A3Zgccpvr*
z;??BhyomOYo@*JOtl_4$3hxwk#4`urgLtI%!*&I0^Ut|QPeX5jr&6tNbk+dNaVKi`
zLufZ;kjfM)p!MDL@$ogc1AqB6KXijS_bVNIA+}Dl3UF-$R<Wjtrhyke;BwIA6?m`*
zFAJHq{FTUh6vCjbwvOhh1v?c^15S;GHtpU5yF~DEjV|{{={R;jHztO8Hc&_8o0akO
z6js?iO`t2Cm4nCe&)J)8dZI2~FdtNt#;cs)FA0BvdF^_5j#|r#VJ`Q;`0cia;j_{=
zaC<$!yn!cfD8rA&^4~zuwje(r`q9FRm+=2);pENZV7eUZx8#sR7FzxY#=tEi261}=
zcbFW5?Q>`Y6K_o&Z!}MmWbhOVKZ?k(pBw<ofq};`_x~E`O3m!gA|`#6k!I|%G>=2v
zp1)6R-RvK9`~!OVFmOM)S=_X97=xJB?{r@W?hU8Ax|bI5zuCpb2Oj}VD*NM*G8!lM
zpzLib6Qi)NRf00ZeOU9|2gj|~dA&z4P8SqbtVLy}Gv&?V(m#3`z+TX(B=SC_f;dvk
z9#&(Y&VOGkPG*!c)_z;9L0+=(_Qf5*JQCVXwvG-nq)TP5nok$<B^;Q|yM<~hlPjju
zB^*%3DdU`H!VF%ugwTVR$>CV6pLB7K78h_<+)NG?vq`UHr`lz6#ggm#$k)rKa@A7R
zL)0Q$EtGJ~xtK}&BGr!hro2*?$MAgP)NZ<vu2zuimh}B%!K?Tc#6j||U(J@%Dc|s2
zPI|>m#>?Y4Gma=%DwRSypDt#-9Ig<}XFVL{H7SB<ceUu{in&TThf79NzL!o{3*}5X
zgB)x(Bf=wm&XwjB;(I`BB%U<-kMZq*FBO9?z6*el?}j@CpK1ZwoAhFuzD`44PO*;%
z1m^-zVQ!0pWnH83^MKN|I@YBco+bxN>jm<?P`I8r*Ipuu3<4_IgK!|<e@pAdNL-3|
z7&=vCVN4{xp~l#oSWB`_5m{RN)Vdwn?(uP2@v6%(M2a*S+<n&donw2T6N24c_w4>k
zI-mNQNoAmWaD{)*dm^uG52wX)8<HG1Cz2w^Ip|#IfVOoj9X!J7$hMC4V}tl*)70+0
zXbbOOJdgEu7;e)RjXs)RqQIpV5nc~HgPf-@8bT+>$3XzIo#-jez2Nbn>RUSN8CE~Q
zBcWg(SO&ntI9`ds5yFFNfl7F}XFtY(T$k06PqisN`Y@T8;a22cE$FyptW7pC!&p#5
z<Fy_dF_zAz5d&&yJcIL`rX8`ffT0l!YG}0Jrx_ZtCf3l11vNC5;Hz0Q;^rEQMjWW2
zapzq&jabueXvBgh5}XI~o}jTQ4^Rw&LGEAl>EBR~G8P}rE5D(})YdVQ$)@<_VSgQ2
z9tNe6@z|#~&2y|w#>XR1HD9%mS;k{`Z<^m>1hQF{hry}m^If0WG|xlGnBCzqaax<_
z^EWq7YnZke?^}}7`!E*~8!@&f)}R|a)>-HS*bB9B#2D;Q9Ipj%#2VyK9Ibn7K4J}S
zD30#u0yyFfYABAayKEe>1~Y)8s%+7=-GpOPwrB{Q<5Rijtn!u3(-}_R6e;%Yp560)
zv<I#<>^IBo=)Ie!F<e_D8NDaCV=vJmHy)9k7J@l^U7&nCQp25(f#bE(j{6v2WDG{H
zt1b)y%lm?3h_y;StpyUUnx(i9!<-)g!*bpB`Ay4p2wgNMnR(sx(&p(5*MEkT)|Dr)
zk$3&a7oVawYr%b~P16~!O@<U=Q*ur4uB0{D?oO4DEsH>)-s5;1I|yj6T}ELoz3=cQ
zb`NCv3buB15HYat&_#?Z1m+O}x?Ay(KzxhjD&i9AKF~+7and|Fp<&*Ogn7iYB`@%F
z8Yf$L47iJz;LU!`YXwnu!YXuVgO+j?_rV_;`549emCn;q5FVfc$JWvPh##y9n00zp
zopyr}JEu2?O?;WoZ7eGL8=4dCHSzXZyU_$)UR%C0sE$Np&P$4w{P;M+7Z}^J{~kvS
zjc5wl3FPuV=q4UFXt$efkkb22I}tDMfyIu9qd^(x(}UqCC0olpiC7rnw3?>(!YNLM
zGH$Z2^Pc=p#!y#deS8`*bJU@-zIq3+KZr7l-t^Ub!IbHGbjIfop*LfnpuWXtc@-%1
zTb@zgA@)uLIAY1@aC9x*$w4{+mossvC}&au5WvWszY&(b+(;1_ah&+a`!MvL3gYZ^
zH3)WDqR-Fs{weLxEGaz-?$5}%-Tp@X%l-CRWIY%&Y*}EhL-)ZE=nZI8D|P53He4m1
z_wStfW@YhR6}KZ<e3@ktmbDiVBrfLjxX%)2q}_6*m~x9rT!Dy)E?!bAW)NOA!PX2S
z!b#u5V@=sq4uRxyuAIu@Ja#Tsz~StQ9|*RV)7eTP>lISTQr5+FmPsV0rTuI+l`r5U
z=b|z1??T2`!+WKY%T#muVkPIM%eV(IRZ3Us4##ZHLjs&@c*iA)Xj(SsRz1I(D;Fvm
z++SIu8x%A7RNfEpUP<FkE?ks}ShDLvHtCd?t0t2O6&4GAA<Oqea*X>j#%Lt(Fs|WZ
z$Ayqd4|iE2H?Nq>r;<6p>>|esY^QN$WWhQHUve|JMbyict9jfAiP&|ij4Lgx`D8Ma
zEaLV}TkLsU1es1}5bw_yD)|gj0n0cKkHhwbs#h%*a+CtdG3mV+v&8p+7<atX5O;f6
z>0cHx?jSxniu=<F;}r>LHC{TmJRIJ5NfBPo7kqgu;pHn{({aPV#Asqc4Gpqq7LB+;
zVbO>KH8ecrD_At*hJ-~U4%E;{BHzK#i0wZ^BNo)qn1|nBXvAu=p%DveXzW0qmqjCP
z3|cheKn;yI0yJWE($I(nH8d{WX161Dm>L?fpoYd}?6VkI#TrFJBNo);x}L%QilGrZ
zumWrOgUasgz@CYPBW~b?;<yyV5jQYGam-?W#qbfU_@OxHY`Vb_tJtA9PGJwm!V#yq
zp*Xf-55?e!Rm@Nv7XvtA6)zOWJoYsVAF+xRz`?m=ZwMS}o|6tCo>7NqtP*NC7x^gm
zH!#msMGlZkP=PO~&#ZC2a1nbHU*^462`s$Aaixz%>@W0})5`~R(*Pa1>^6~}gG3`*
z76~_3=jm)gOrPdD3IyA}tI9V*&Z^8E((wfW51*B%+B(u!kY?v$o@1EpxR3G6l;5mi
z1ZjG=2Qa)x{A3i2(`+LzdVRgdZv)7+)SY9JPvJXAMs2a_b@6)=E+A8o)$5)oJ}vM_
zmf%`*p79m&T~;G_J0EK~Qa&U#&XNk|V^JNOSIY8`kgB6WgYt#xeu}5QCv({>c#|28
zRU*M5u{m+MAC3;v;N=IT=?Z*OR&;Ous)!97!ox6>TQpOv*H>}Z8&slh?mD}q;SeJT
zf!l+%)&}s>edIdlP39_Lqq{DS?n;bCzUP4Ru)6mFRYg7%#q^$#>nx|%aUK1R6TVXp
z(*K0mKqBe|<8pHYCz(jSH0%vgup12xP4Dx*47^ISYwMna8}aDIM&7+onq7D_qTSsO
z{T&g!(7V6+RH=}`_4`=SciRnY0Miyf6qsOsDTue_BEMUu1f<B{6L(s{1|V}Wl`hu6
z_sHm<2J0yBa2|dp2wTBTevOTmOefz53e>jm1z~#Hmg;L8@$g5%I?Qq(EVc1BgRpiR
zMPf7Y@Vh~n9v-Z=iRht}-OmT>1ltD8B)gv!FzZOhk+S>MV4Z%x6@F^t?}x(n^FsXp
zN)Wb(e@li6KijS)==j5IkCl4tv%r-)X<PSJ7<@lV8vZQSrhWJ=c*f87>`?5e7v8Ca
zab)c8o8fgVDzec`gYw2hXjt&fm3f!2g?Le4oeqW~SPK!CzJu@`*qf+&VFdGP9;6(l
z@Onv`p6X4*=X+R}4N*@wkm;Sl8YQZp#b+PAEwJT7)YJ6X4>$|o_2ERFUf{+oPIp?6
zH6R-+&kc=WF6k*3V|7NwBhQL*%OVCxUkY&pwNXr+<n)%BbJVvJok%>%fq1|X=gqv(
zizi}a<HC;SI=zSF_}|23yNLRl+?%8DJp;V-<B)O;LBf0_;5UZh=<UN06uK=>$K#0P
zgL9G(AO|SGhi!GKcSsC$-;j8AXWi`_H@VO+4XR5$5>l6AnoF3g2GXU7@3(MwF>ZyR
zOGvrii-YPB&7OMfYZc-5K8*80VqQgG^7rS(_md)Ji~5+q?}Y#Ra01_H9>(|0oKYay
z>v@Of*VR~>f=z#f$G{NxFUrwEzB11H(Pby%LO5}h&RkTBwlV%YF$ZiOfADs-FcQ2*
zq4+1^7e1%DUrcc)F6Lza_bld#0dN7{Io3UkxuUm@;Y^^{{`HkuSVMw*gAZe`Xk~SI
zW`33QV`TKt#T+hLQEkCwxt)&iA^szMhl*8k>j|A(`(F$k?%-~CbR<A}bhO_yGWv!o
zui}|D98Wsth^;1NPmtt~1&kU;%?A9)jwmNR<-IcUyN|F;nVVXbwk<Ray-8-nV3pMH
zkAdC^ivLSH{=9&x;_yQgg|K_r;N`OC&>u$<KrZ*D9T&K{jPCuh%V@pDYqBFae-$XR
z7Mff?iTTrpsao})MoctN7E*r}KE4fe4E1@fdk%A@UDm+Ud|2s08EC0<TDReK#N>`7
zI%~BmR#tdjjEp_cZ|4!`qB60p6}{--<g2k0bS4z#-F6%II*EF6Jw)%6+cH<%`ofN&
z%KLJ6FWYqT6(3c0qHo_(?IFsLy|e|ikh@FSn0I7d9I9&K2$2a4uwC4Nu>;(yybc-4
z_P!PP-VuALT;~<|WRJp@5=t~(+t_o^9sbVu^}S!Rp}U4ZfpOf$ejD4PqiE}6xaSAy
zx~?bYH*un0H=1QazBJ(0%iZS5N{CF}!q_q8W_^DF<L0r1tVZqTvs1K(^%ZT$>B?&8
zk2r57?w3{vfsLG=m++M6E%u7z&jgz_`B&xMsoDS+Cu>y3iIKyzzz;Zz7KOsm{wS@<
zUl8Yu{DycA8TV*aXl0AZk><PitKaBc+h*_D=CMoT;A@C=!G8(#8{4N#=(n%Iu8HC@
zLK<|{OH&+)(&OPM`q1FuQX{)}L&_}`(c@zbV?g6UK0oOLkDar!O!A>f@Yor_7-1f%
z&TVSEJt@A6DtbK89p7I|h;M?zf2sXaM8AAp_KQ87v^=&!rn+3ogU2kr57<*?i(AX0
z3wy+HBn*}{&HeZeAysr=vrOq8&#w!8sAxIAF1``C8IP-w{nts(w8}!Ca9=%+b~y<L
zx1QC#+KJ%zqw;&(hyA(#|7Y)gz~elwdf`{Hlc<f8%BkDBsT<VPP1DpZvLws0af8>=
z%2Fyzs<gI~5V~INA8Qj?Qg>Ij9MaSjQ_>PjfD}T>ZB0qrP|}hXQvyv(C;>vha2sfV
z0J)HUHxFOnmXeg*67KB>_xC$9XWn_=eRo%KY`*7vo)}W?J9FmDnKNh3oS8Xu2K!H+
z+```Eo8NdQHp^>(<~|l~%bDFZT+lL^W)G?lx(lZk=BlB2L4lK)ma=#4D3=$kCv00|
z*m;-|u!Rg<dt*4*-r<%YYbV{igpL9NUChz>6cA=+W1u110!It?*$Cf;_eGk(3q1<k
z-W+zR3_1vVYY!<hmx0u-nyaHAgl%sGn}_?3K_l%W-ZhP2=U_GEk1x)Wf%r#W6Mk(Y
zcxjn|dlY_Ec=2{|aZ;|`8FwZSz7IQmbJ=mh$aWE~ts&h0dDv`~Dnd!H{|MXO5O$Du
zX*oYstlm^xpvfZbW0^Ir%1oLTvJSpY;nB?v-CSW*pIngJ^ci|bnHF$uXv%nPXjsOf
zDS{nS8EMnQ(e_W{CFLO%o}qH?@H~QPmh)Mr?;iza{iyGBl*UOjZZdWtK{EH@t=ok{
zHjOt|Y$oh)Q_iEaVL8QA)WWEj_cbZo%_N(g<Gv=xW22Ev815mG&rUiTaSX6rSFjHq
zY*dm27kTLN8*otTCGQ+;BMt!gs9h&8?rl!|R;^`;v15nbu0wWd$0c~9_UfBCjq<7W
zpjT?;VwKxW!L7F5XE0Z<q~2!zp>;QdiPvAT^%pR2tfYRh1AdBejifav=f>-tv2{L<
zxyRJmfXU!hZ2HiO>T_b1XuIyiT$T&Ya?kDDnOj`sO4mNBBq}cmZno`OhMf|vvssU5
zlbXSJjcZVM$<{rFHEFc&dRA$T^*OEUnYZ<<gP%~ep5(sQx{`BS*Qev-@w)mNjWDgT
zQGRlrYMo#|PI^-}B0gZ-dmq;E(e^g$FQuUw%<AY+dFI=_Q99~-QERWySzVnf&(~rv
zKU!yUZ)&~CxvQ&N_sX_l|09RBr0hmDQ@qfn{kq1Fmuc1wD5raDkH7~jQdd0#VPlxJ
zC(kJ&u*r>vU4HiCxm<%e@`IRj&HiURZiEZuicOtLt=XkJ&Oh9zJJJvr9k82Y&~uR8
zm^WuEMY_Sz@Ll&Pi82rB-p(_t!DDZF|E%qklbA!5hBN0%quY~FqMLJt^SY6fWvu5K
z(bS5&jVNhVj{T}Uxfb(!qxx6gB6o;&=4=H`%9CA~_Z!jFs%;G^X;l#QAFzG04mLrf
z`d7mfy(u<s@jlW7Z!7Y`*C0bWZ-E_gHt5uAFiPi@un`*JZB3_Q3-{k2vG}qG9L0cw
zi+qZ#v^0+`1-C~(hWVRy8kjjmxkHpE?6?z3_dYnsD~vrikw7~ZmBV!d=3;>hgFtC@
z4(6!@7{m$`qEv^|Cz*I;ZgB@S?zKG^cZ>UxpMF#0SYXtlpKYu|5mn%5Q+1)bkNc+i
zmFiH5MRv6tQ%`zj<AYQ{n^DkE(X=Gp)z9-4rTq-*Z*ZBqCFSsgH+uFC=-C%hzYb-G
zZwPwxMc{LTL~V<wEk0k?Buo)vzu*~Ixrd{2c?0w#>-J&8ohlr$*%ErjGz-0x4@%|b
z>|vbX;B7!0619?9rHe9Gh}9)@%`Y9n8<iZw&gMCt0PE4^N+?~Fi9(F7X0hhRF^;~`
za2(mwUK^W^$Gy!&nsi@dWrJ-ju5?`0S0na`p1ILJDF(tJIx6P)tg(rw(-VO^gtjNc
zZI8e`(GU*L9ik0d?<C~A4xhaRxdo64_h>UXRIT@Ed7j)5pQ+lt8}hKgCR>~J>}u94
zjTFu5u&{4GYWwyfj1}$MxZYVE)`phF>d=6;8A}`Y9?lkR(MSk9cQbmA@v_fW9jXLX
zmbx&n$7RGnj8J>(Nr5wLda-?gB_8H*b7p@V?17@WLk|CCY|O%Du(2r}%tp-fMgNUl
z1wcQ%+wy1;^ZeQ35qt}9sBGRI);{RM`uJ?&*NH=IqQ@+5e=ZR1!w8*dqv~<`36KUK
z&eP2TeW~RK^<fFHi(=szqe#z!AJRM%cGTHb)Z70I-P|ZH>9fph5SNsBNpVSeNAfwA
zdz<)bn;Ow3roRS03*C_IH8{&sLrl~AY`PX$%{d@p&s98ApTCC@hjdmX#W<2He;)vU
zqj};=;Lg})F&`kmT(yl>oKHp4wTu}j_k(A%LH@|%p6fDc;h#w#LtT<SbZ}y7h<r8a
zyMRm5r;1g+V5I5yXu1J+G~J0gWmf#pkH|TTo<HA@d0{qKLga76T1Pl_zD!66)gP3z
zvikHgELjfsAvEY0CO17-<Qa3BzGwmvEq|k5UZSSy)&H<O{i$x0@&pLW??(MMdFAJ0
z1Ze$R(2kqL7tRo%^t1e2q<oYBEl>LAOnD(d)1N|L91*$<-~9A>Nv|%__s&mWFnFYZ
zpT5ZS#hJ=YfM1QguRbO(-jp8Dy`^d%^A6(V*XWLqIO}+8<#5=6^c_oKoK6nnfouHZ
znbC%ZWy5l6v(w-2J=QLZ*W{qpWM~Kwu9xZC(+FRL@<uo#K#ZSY=Ggl%E*jzW=u|)7
z7|$Gp^UtF#w*q{e3f+44aZ_d=E-As^anLxePMbGuR7V_w90TvZT;-;efK7+xpE7x7
ze%OmAX(g5ek2X`zci<%K6_n@nlH=ti_Nn$U-VT>e*14H}c@^09b2!hpo<mg|uGq~<
zPYR5kllDQ=l=r~<EVFPBA)W`Vk4UR^O0)ICYIHeaR~mzxu%CbX%HmS5<c)aWm$9mI
zbgod)AlH>*$@Md3*uls|Z#E{_7rG~YH{{X5*nJB@XV*r+SFGUO71{?otqgZTe&S^e
zdRwSmLO^3zvcUTKRsIvoT02GUF*whMb*k;s2bptqx&p>smu=SdF4x8mF8VI7ZJl|^
zQ1Lzwn;-B7vIY=3X{48(zYEW#uW)+EqJRq;Pc3ao45xD`$2HN#;@;@yu7@NY17%F;
z9Y_4p;mX31p`v~CPuEce^hGVGgBwHO|3Ub~;-X+UAMuR00qhdC%rFkk{5%JK3*2O-
zd<0tqWAM<{aR+A%<ay}RSawh1oHV`cV8~AcL$n?M`c&uchrz>Iz=H748N{aDBq^Z2
zFf=Se7u13b++=N&U28%Z#@CI&kSu9Q=s)|Afw3=J6v;=YA8yCGp{C;j+77Rg!IUVK
zG2@s{6M8OM-;ch0px3+4S3zL!uqyP~MG~L;;r?V8eTj>@W;<{_5`z=3L3EVjd2)Lc
zkIh#!;L%0vcb`R?i0j4DL_OUvbMZmAavQz<9>~F@`4m0=2Jmw%HNJOrD3k-r|59K(
zS4G8>gCWT5lE`<yjF%%8jwHyz^KlqAN<!JEjTXV<i7={ja<>aK*TKbPioUo4lQ2F`
zK(3dP#s}(9**^u@HZcD92=niT%p%`5c%-;&CQDa-0CKz3WbAChx^=0=*f|}CNf<j1
zV{HpOk+Gw5z<pTLE;SoF2pMz?cRS#hCi0qsjCJoda$Pyh(NivrFX-S7eKl$G9u3U!
z<L)o}W+ij<A8rnU+swMmu0c&{&ZUE>`}Vp#T9tHl!h?~}a&xGM<L?gKe|b#&aCI$9
zJPJDx*F$6f^4*9#8sa?Yu(JLWxX1H&L!1Y*1}kOIyfJa7#cN)(GQ1$MOR~0ruDK)#
z?)!aDM;H+2+DLzM#!GtDo5;O`qvME?KRP~|$xe@s?;T5LMyArKq4bc0Y4c(B?H|jG
zIuP*Q;Asn{CJd4&0NV$0&WXQ0>wa<v+rVdC(#xZmW~Xa-7YQ%zFqQd#>*Y`5UPXSE
zDt;edS;G9@vHtDI=iT3JrEU3vfgM}nzEU}itz~#tGss?O90MQy#4c?CuNVLL)&ObC
z4v&rxrLP5Rh9|OP=>zGpY0RUz!-71UHJwgP4US|dCSeXs9iN3f?kndj3)O`ZUamek
zHHQDGz@-PShdXyp7ZD^3N9RR38~@R!u;%R=j8KFw_ez=s*j^p$|7aEE_u(GevR5{@
zin3|G%x25(LA}{klr>K=j$>?D1mM#QaC~4TICeGWWK-^7{eKj7e6(pDLpT~K&ylrw
zS9}a_c^oX)W+8$YikUO7xPp4WdG71=x|93!9qZd6la0A0J%~L^_&+wK&2n|c&5w{F
zbUfb_zrYI}rKWJJrNfg@^gZpB^^mjC@yu3S6T@1gWBtcCo+WCA?jp+@Y}uN9xC7Uk
z3cMs@0|W4Q#Mw3bEh6IWLOQ=eK6F&a`jZZC3<L7Vk^k2&A5J{IJvOF<In^=r_~~v3
zJX<)9<7v!bxJ*{Q8H)=N#CH7DPHo4^%AuIh8MfciIV&7MzUnm9cfL|%-Z#;Pu}RD|
zpr3j#JCw?#4jTS&ArE%+_TVr112d7|WDnMq@bkr-n;nG48?4me=R94+%TPt5%%|Z(
z#LWg=m>b5~Ip5ngv{3gZs9w>p*C+BbiwA^i$1ySUT^_F3gceI%b`nPG6li&0Vp*Lg
z?Ag-F*y`lt64;AllVcO(d)eP+eZxCJ$6eg8f!=}qc096@-`<<wG0@vLu(jB;J>R{f
zIM6rKJ%cw^!njCyH61UJ<2(X(%Ul?T?FQJuA-+QIzyMxUnaR%-`w<2Xk?1h>Ax>Q1
zj=~PSRnpTK--qp*dmZfM<7(g01cJ{nZlzVR*Mc`L7maZ0`JaYA>+dPy5tY6I9#Yv_
z>_f;tyr9y%b$dRK7hQJXVOo9LXBGTYdg!y$j2<P0^Ya#^r)OZMki)~Z2yoZkJJa8v
z-<qH49q8`OZQq7BXZUo@YKIqO#O%q<!A5iRkSDm;N%nv>XN>b<*!2!4kpZV=_o{Jf
zjE7CI;g9Pca&dVP;~9s>hmU5DmFEh17*h7h6EhZ#Z0^QcPKz>b6I|=5VNkOSHlU>n
z>@GP&3(YWLaztvbhK@4zoPq*wUB*=fd(M>WekIF=jWOn2eS?&?<ySX{4{HeHRNwGg
zmN9InOldF}vH#=^l6mhD6}|@JJh$L}XkW64rFLN)Rcl>%AtVUqtsEVK?n|miY4WSG
zY4Y|=q_##GUWG?hZgC$!slEp7inL16MP7$-i9SV|c(rTiNvwa)wBFU!_kP>XI}txC
zslKLsO>V7n*Yw_1+O|Ys(fK!98ctvKVrhuKlGD0w^*Pznm0Wk&&pgbL0U5q!WLn7A
zaC(0jEm2)}EjDgi@>0+#t2iF?cNFQ3mN!>k9^zb?wWWt9D}$y!`>3t!d9N;i>Nx`o
zONn@qXoBDqmbRzf81f;4)Ut1NGgKmZXM~CTQ(J}S)yEsf=W<$JmeW?e5)y%L%IfbL
z_9a$`&(aQiC5lqh-TNP#t_b<KG6|{kw`pnYt32&~b68iT&)E9ac9=c2dy#mYJl%U`
z1KQ3=3LK9j<ed>JPoD05%ZmHo%G0gU-j`IKyBd3-cGZgUsobDpQIwiNxxdlk9eFG9
zsxi3&8{Iic!36N%wmZ5|E?Cul)fWHbEv~MPEq+}qu;0(1u02-gJQAs^rI8$ohq=e{
z=CQZ=^lsbHhq%&xxdFt8-qG7PGceG<qpvrY8|csV_w5+q`bFuLH))Iwy^J%?kiRV#
z4>263?@xTck7E^m<h_kE(Cy<`1@Ao^&qi@<@9oQN@5K|DXnt{~z-3oA!gP1f4CKj_
zC_nU!^e)^L<vc4sR6LJbs+9)tg%~(o0@unj<vGMvaX#*p)fwBTb68yK932^~XQGp^
zNH*vEwW41~S8szl&PX9(uJWo;U%4k5)o~{6@EW0fI*on%L_VEi8@wu9EVVngCD+k-
z=LXZ8jk!vG>lmBG#?%VuNvkKhhdeKP<BDSo{M%NDLsg*M@Fbe6?O1<)<v1)Ia`(}-
z<2LN{teOUc!ue2c!oEymznzI(<Z}pm#t22>_<6Ju{xg&duL>7W?gaMbv<)k@QRKY{
z(5Zfw8-5_f;dbe2_5i>FUvG87DG&BV>jdKh;re52S4c+$_ZjlbqIYBHdkye68$+Ht
zadh7Mjs|p|iQIU5hpJC*z&c6$^sMk9+@5sfuk#04$Dtg;T^v8MuvG2Bwr{Zt5ia7!
zYt)Rf<IgAo)d8ngUOv<TR*&c!pl|o8X)v2j@avh!vmVu|xnrVhfW_2`@p&{Qq6D9e
zJ#qh@urF3RzA()?zn7swmgmGPyZq#`%X=arPyLe)4TbgAjY*=zo-KX0>AAgx8CCsV
zAD40jI0lcjFr7}ch7OZ{xz)o@OZsA^c(e>DfPZhUlFP&Y4e9}BxyBxv8)n&L7?s%<
z1g3sV@r>5PjB3T0b~wF*gQk1C>wfHYpUrU*tH#|wm>p?Q&zX#G9HXEcobK2%+5q<%
z>NtzujqB$H|7ymy!Jy;%<Ta#kMdiaWWQkDU-i_}h4mhV--(F3>OVUH1U-kRgIA(Yv
zHmco%MPRSW!m-%4GWe+eb@wNfp=8HPoJ(H<-jV!#;<;EusmBvl;mI1$PajJx54S%D
z7v3?ZU(?NM%VP^Hetx1NBx0&d%<fV#zcq)~<V$@$xoy4Oz5V^&eZ{Q<`5wGQ-@P4A
z*4GbOzk19?d#o;;#rch^zvWqi*973WRrTpwgM$~%B6C}#vE`#l+=^OB!LWYblV%&v
zu>RHTtoW2W9)3&eUvcL|)~C96%DC4rq7D8M$@zodg>#}8fzvHDbpD!!FIW;jU$p!c
z%D9z}%{W_1Dz~B$h3Lg<h3lU6BQFl0n2@@bo`ru}5^d2o`4(fi-`%+`x$Fwt<ynd0
z-GI|C4rhG&b9YN`z*${VJ6A}n%m&K;4Hv(7T<Rlz+TxOVVsEjAIBZLE#bJ0)&_64M
z^~|~R8&f~#YoUXGBv{5}rXw>m68JZar@9H}<v+rEPRPp5!G{_1)umRh8OI}%hwDz7
z*8#m6<}J?VymE{2Jg?mIUfvAcA8+!?-2gqSI3>?3$9of+cNjimvtGH8^I~~kxktUc
zn`{I14p<-bn&LEhDCpsRAd)}NCc5_X-H@>Ce2yiRHxKxE66utFCB`=AT~1d{@}hO#
z6UnEmM_87zp2D)si<Z5^%V(%rpWYW@c|N^-TR`zza$Q>(zaf%`g4)gkbc@R~q`JIE
z<9S}WN$3DA$0a+Nt~eiv=b;?^Ug@9G=$#d{`5yqxEwnXeV8>xakj)><R;xw2+qiWB
z@4`i3sv(T}CG*Y!VfaWu1>vX_htfELaUuB&xL2?+H?Te10~*b`V+isc%`>I7{~6bq
z`6Vn(sLVp#ru=O-fA&~Nz2aUAS!P+|0~->i<Gg0_z2=jz2Jf@6yy~&=zS|t+9C&SW
z!@hXjrfW0FN9Dm2ka3nVd8I|>sm;uI+{m*{4A*ndn{;U!;gu(IkWIjo9f|npyTN?%
zH$+uR!{gEPNI%o=e6QY%g54)!rb~0V!_{yPiT9%3OL?JTrI(>H3+{##X{7Jyzr)^b
zu(~MDA1zlF=EaZJ+-#}3u*%}o^)$-T?{@1<2}c6m13Pyn6)_uEtdD+Sye|MBGP&nP
zUo6&dtiSkbeic-iDqz*}%+<)mA+-P2vxZp>-Lp$0@AaHb8e;)Y^sMuY7+JD>ycT2r
zY|^MlL|ror3)GG8w)J#EF3x5>x~Dp9@joQ^SIr7ouzbvyW5vi-0lMZ^j6JwmVfPG=
ztl<s>Ul@?h5$B!H`>c5L#NLm)-j-bpopUzZh+QRj-hNtepF#T)_O50uy+hE0XOmt(
zu7U0~ykP4nP*0H-yV2llk`k^2;YDqCH<9nhk}g+9HX4#jP!C_U{&hIFTMIul-1E0U
z?uwq|Z$*BG$v+kc;N9k(odKe^OL<eL4SFD3dWw>267o#=f5dw|ok{TZZFBoXoV(u_
z;0zFvcVxCWnyZv0NIYW0`b{&jyv6jV!qa^s#(-N*dEG1m3ixXq*?s`BO&sv=^J;We
zIk*=fYYA`;rSAXk!kqZNpg3QJt8W(mzPK-n7s$O?g^y?~aO+g!VMVfH&2)19=!?hc
z=u}_BLy)KUnK9jz+3IV^IlC#mt09aJ^rVzAGaYwGV!noyd_JIP0+9GTvW#F~>zbUl
z>HF;5=Ht?8%>zCy(YZa)XB*%nZk%G%cJV1v$rQnWW0`UOx<dUS<x}S3l3f=(2)nmA
zy$!3dP4a4qrI;~b)*sJfot#vUZ3m-6%vO@91`=H#cOd3w5{{6!7EO!}IKxRb98U*q
zyB}?U%cDnvJ@C8E;WN%wc$Dhi{(aC#t!Wh0A(c_*RfpXJkUrBo?u7nIs-pqzDg#Ll
zq7lKMXRP|gp135rjwr8V?Pyw4*cuBaZMxd_M-4v3&D(^>L1OaZ%U8#S<nj@Ei6Vgv
z9Sip~z!CCwzMNl}n=@pXR@4o#<i3=)DsS(=9F)}72(7j%B{yE1rpG;>Rd`t8PRrYq
z@V`!~&udr6+%52(LSfy<-twB{vQb(ijI|gzzni)1Nx?xi>ZvNwr}>i`Sx0@o&V3KN
z{Dj#EcodFry%{{oaJpW9(7`R#W^t9nr%GW4E>&FhFuLA6EihPqnWvH5Ip`Mnc$42^
z15tgdR>o|aWJB2}KwSAJo0YG#r?hmquH_xx6J}jo#K{oibKriz@Oz!?XFTEGh4mmb
zrUBoT`O!e_9lS(<$UZnfMo`b0g=G=`tKD6I8rDgTVO2`FuW9CiyI>3bXu|wxWznw)
zFB0$EY0ovY)}=o_3|P#Hd^i%FqGK>q$nyJb-Hcb1RJT&Ob7zz4b-=|bXp|l!Lfg-n
z_enG)w14Cvu5o3%u1a>lZ{Bh`KpIM+(?4L_|1507q`H&a@2YRq!ba(?<q;wve|jdf
z0d`^%9hL_ROEtVbV=s!C&5cBjD>_x@^9LK?4BM83wm}ns`R$fx%dkI5tL)VvqV_Qz
zz@Dg}Y0f{W3$|nwUIuIg`qj8M{i|5lbOyuY6QkoJ>8a5Saa>~4yMp1=<Yan$2x*LY
zcH&Jzunb*;HBxr5ydZbyn9eoLvKh<sdQp)3HrK=ND7tS`%q=o}lf4?{zrrQ&CfZ|7
z^jEQhXkLEYZZcVITdsrNZ!ssq`Uh~0sv^EmSl;s8F~z65H!p(H_(sr+Ko!#XEcDx1
zr7^Y<^kRrqyX6_^)U!%sY$NF1w!cn6f1cHPY`{syKMUP>R`J86fVer^d?WPVS;g;d
zny795=-IAA145!5s*_G&Uxw`von!{HU7Q*%0KX1IrS;&U8)NVV1oo*c9JhPMwt)IL
z@;o{QZ#N1`vv@faVH>JA*D&)r*Um9mM8mi#Tbd1Z;tg2C#$ad_EqGhju;C0op3%f$
zm*ySD@EqWA11D$cz*L%rzpU=hKZ&zX;E?cEHVd|<!C%9=4|%etM=9BdrHp9)2-a`N
z#|Xe%njQf4?Wdu$pEUZmWKAl!o}_O4F{>MSU{K5+$<4!L;?@&lyCblXoFf#oCaB0R
z=ua%)3y8ylH-O<xMuJQ^(|O8|XDnXnYiriRODd}bXqz8_o?`urIO0*-6vq>2-%0GR
zE$54iHQVKtK5Xxp6xf{?tUvz^<U)fz%G_c(d!$Mq6daUbzo=B6L8y%E+}14qk8enr
z@@*?EUqv*BSr+fff~A-{P5Jgl<#FG7zBniM*ZF1_X<gF@7LCV2cNX4$61Iu0x)eKv
zyHMuzyBM>@0*DVM$H)ciU)!wh!*kUXeZzr~xJWDE8@3hj!w8^9aK+uQU4Y$NtR0|N
zq7UD&ZGfNl;K_H=vbGT~M)e&t-0a6TUOqR6yZyYwk6>w_kGy30^BR?BxO{>GSh>l!
zGJgPNo|183d1;0bPPjOZ)~$aB^1mhd4#6U<78n;*<abE_@oZ{fdvV7AE~von)=q<7
z=@6Qt`3{eCg0A;Yv<1PBBlfRx?sPC!47oDo1$CMAC&$o_2MEO`qf9$ATz?iYb|U%g
zK(s~If{eWy$=6QvU=Cppj=*R~0Y>*GpNhaV=^T{N{m(_rxgp+Cxq^r4b4PJ@E&I=g
zZvb~~J%l;bgSQ<R=JSn;Fh4ARwdK`X%oSliAHc~Xv>?um5#5nn{f#KlJLNC9@_6wX
zaoox?6*wN7veo0&TJcD>P_94<7bN68=r(%!Vaz!{4*hkMXANN&x%}HP&-nSai`+cK
zw;cR@uZtYaX3QBrjMqi({9+yUDIHAnE^@Rz2>yQ{a7GiJ1uM$M9mcL)gZ`^o+g)_{
zEG$02>-jk6jh_grC<4C$muGl#ujH9|Y$nH(E|zPC)0E@-|F!^5k!E(3qRq<joyQW^
z3_&mg;w0RM-gRQgr^*p|2GN`mUyk-nPLE!n&Sud54k?!%Nv9?y0@KvKRAzKyJUcj+
znx1y~4YJ+7%>d~AU;twZD^_u!pvqZX!0V1UyaQFb-|~XM@$GU<+rkSwr(=A6kn@{F
zS1_DX`(y}ZK7{Bd6%BPJ%6w#D;U>e&Colos1$zo>tHsiMm`Q%UtuqKV;~u-LyC!i^
z0tGrJ^>#=eURgD1I;SG<dMnTL3HeED4~Xic4TGacOu5jO*h;Y)ahF_2#A=P<M6Tq=
zTg(l`D{b0UZ!xJ@IPI~xm(ivq+<dyS30^L}+*nu#o&g8Vj=EMTzZVUR=DV_d=N@Hg
z!)c!5z`67*)An<J>UL*qRcZ^%J9k2Q7U1KHcjn>1vVgbfIdAQ9TM=2_Tj}p(ycQ!f
z-%G%8BzF_e!eE9;q)_fgh<kswy0C<|pk)tYOLSA}YPYAsx0d5HwZLaLAL>xLJJkiu
z7jc}3#8ZW_fXNhwW7t0L*&dKD9BJN=tG8?wdAQN?gE3XlMP0i8!s@iH+b~D0urAwg
zc7tLSO`Esv+Jt%G9M$DF&B@jMm_M4<XQx7uv0c(_6tp@a(7m#|v6fjSzJ_w8IB&xm
zXyrJy3lhn6>mSCSSv}5%q`LKB0cTxtycp|p`-=KZ*Erv50jE9<%Q)AH<2#aDE+1Js
zlC7FB_V$)g7;ibi*;HK_ti_VbsP4SYltJ+Sa(^G_)bwZlbodx*`r-zugYZZV;lJh5
z=OXE|I70$WfS;3$ORT&<ZPJeckHbBN^B=%6Ekes_Ki#9H59c)&Ug}ib_q+6v?u|H`
zF|bkk?hMn}97oIdymTU0+{-wVxjkU>!?Y(g&4b$wTT0+C6D#kq7z=)icWCD2`2m;C
zdGf>H(cD~h*6`HqnVvH9eQ6G11dA{vXvh2{_e|5*4yGr?fSF1U;>m>UAYN^zj3K65
zJb&*f;_O;$XJX&JiE-K!9qWIZaMObmlj%%q&saK}9?wi&2OMhW-VK`Wz}#iF0T6N<
zi|PVA2z9OUgv~b@Zd!Haw_u)Od6*N}QgFrHIC#kB=Vs<<xXn4YCrpRz2i-5&h`9xL
z#>e*JY3o|KbR6q=&10<INFK^5ub&O`25AkEHy=TpWxa;5X?^+bZ98|4xuDsj^M&Fv
z$`kIR^>B!>n^_2<!!_3p;KR=_?r??+9l^rr!wkxcHMm*V?M7RZU|i*>SNF`uK=;pp
zZ(@TFX=vQB!O@{;{R+Puc5VW^Lyb}>OM2I>zZ>lundaUC$@B3E@o4+H^&bPwY(Zc=
z9MUcW1X|Cf?R2%(4_q7ktlCbEUMdJT^3@d(Z7@84%$65Ejt%b1El$f+mXh78(7t>G
z{AN9MaJHQp=&8H>7`jLJKEMp#2T+$I>~d8?d7#brbN)L&4xW1YqV>ND{eK7MUfSvh
z`P%x#Qf;ENuXqIO%(QHLVE|BKXYiB-XwdcUBfxuSuxAO;*ajK2c4Fp6ti(o&a|i}I
zYR^M(mN8txt%(uYEv)p?aMJZ|4ehKi-?*gmk#B0<8Az3*jBgpQKxMpu_4=I>f7jNY
z0IO|z5NqfN?C?Sb|6jzk=2(zW+>MckU@P4j@J$Gb-)oqVP++H(rMY#4&t|o?gUic)
zGZIRMZwm0P3(NWidUx)$jf7bFzlGn%ZhtztT&8k-4_8=H(ED(0I|ZBPPRtQFQl7yo
z$?SYWBx0WqegO8&O5oN0crb+baJ!!vKZgD>$f?EaGU1!866$;aUJ$sZ{3&BY4HISs
ziy!+7d{R5-0oXao^xqn3KZ-!_7}|EhHmRrW){r>BsvdbjU{^?=ZjHR-9c~SI2zJe#
zfm{mWd1k0_0Hbx#_Guv_+VZgc8^ZE;LdUGS{8eEaH^V+kDDR0^$oi0gs~r6gB$xMP
zyq^BIzSXVs$6#-*zJ4I^`st}N!m-P>;WpT7$#QfE&o#}#`$D$65d9WEV1g}iXYb9S
z@6krsaP>0PysXZ__ej|~8H+1x=wc(khhQ5f@GA~)^cr}iHdoi{SdNo}=wneN<e}y-
zU#9u{=dsCz`GHnrm_PD;%ug@lb{z)dRIxUT>)6Owx*nDMx^{@_+b;%SW+BbsxYIm1
z3ditrS7Li2<!li*hUYF%ECWMoUk>jW2!3tX+BXt*v^pA257TI!o9nOKZ1S@ajX`^Q
z;TSofdgC#Ht81T|NXRSQk6V6|&_`xta>g;zu-&4D{i!g!u4n)QJ6ZMH2FO@KU;AUr
zMz9HOz`I(Pk*FKmu8mhF)`2~<^fVh+_4@d(WLTdblpD)cYiW5DM(f!8mPU2#%N;J~
z$9XYQ=i7UdVI%qom7t6!Ro%SP2fdcSuW~g#!e+R>yuT6LI9}M{`JvaB-Ox1kWBb@_
z4nW$M_Xtcj8y|$MQ|H9VErzx@j1E*?mjrJ!aK2z^J$KnWIX_6x^BL+%bLPZ)E?WO>
z%!iwnXn%_h;O4ZQI}aT#$)iAT1`iC}t`IIF`97?!=k9_1_z~<cL!NP*fODtAGCZ+f
zTAkmHuCI6=@bkPEo2yBDB;JwuS|6BY_Mx#yJyl#pP;Rq>O&tW9k-ygFhq+@or#JZ*
zY{MOj#QcMD?~7*?*^%MVu{7bWEdV-xLH5m|Izpr_pX*qYk7k>EUM_a|cVKN6%NLRr
ze;4fLSpGhGDQf<epb7a0xN$#o*i?`L8#KQQwr)KCAo5jK9)!Jz{OY`1EG_X_K$mwn
zY&GN^^)nUkEbOjmo@{}jUUOgiA+vXYQ>qlMP*!Stma4~r8o03rfxYpt$v0$6i%i}Z
zu>O0@&l7Hi>uT;*+{HH|Z>rXA0={#(7F7LDS^Gu!Nys%S*;A(X7srcP>+#*YFyHu@
zdSI?E=+ha8BTrPOyU>@v7?^5I`s&8U7cD)c_oG-dfcZFln9bs?sY(H7DzHQ5tV4xb
znpeJMm&T1KZY`8@rES}br4mArZ|mzD=*#DN3f<k^Gdp%5B>UAaTzPM?Z);zF&(^+y
zo}OZN5rG2pecMZ=9o^e=#ZphHbTuv#IIO+J!nXdto>JdTPY%J=`?qb|*4x)#*w($H
zyRfx8cXij*E<Wac;1B7RwXpHm;aUYgG7_s>$XC3rY2aN0(?6TBXa7+bAG2l2Fou0g
zQ2I=nI=&UDqa`oHI$DB;b?|;%*p6Z=&U$sU0uAqA-GZ?f*3psyp*ioxnC!#3MTnzi
z0~2xZj+BR^RRbb8bUYQH`yfwr&@My8i{B`mNrPa+p8dmkWaxV6@pG#`E?VEVD+r!7
z`fLt|sY~!Kg;N6eZ>p=F`{?uWEcBz?SKi*!KhWFXy>sU=xU3Wz*#{d#;XcqI=zw1e
zOx{cxm-ddskBOrR%~wB*$Dy|r#@+x0b@SCZSicC1KVL0}Wpp2>8~xI_47^imQG~_Z
z{?7^Yg_f(}S}A-Rs(S5IE5$a0E2+A568;QY4zK>esUt#`)4}wIi@+f!>DGSUX*I1@
zd;{1QiNg&j5O|}u*7J~)U&7mojBJXaJGdk3bsXSS#yAfGP8f}3r|Z|kj?#30F3@@R
zUhE6Fd`qL^yaRoAH{TIHf}>imE~ft%?%&&s6qJX5?WYg3Xw2ChUSgnh@%_d^`7qvE
zB0WYwaX<58L4LLfeX2l)UX#!L%8vzb++Lb1WZ`Ltd%;VK08sn;VaUqIv?hi&sNoD*
zBC6pRDm1t{)~|!STY3;dAz!YtQ>(S(bWq^CRj)@r<rlAP<hJKaGq{>(c2@-_{Q)KJ
z0_@_B_1%I?W-)tKJ5%P9C~~HY3RRA=T^xKI_b^QGDg=2e(PgrHcsA=u*k$CKZ#o#e
z4bEIBW9P_v?AY##ROQOuy~=V^ItM{_f4q_ZSRxA=aVCsUP9LS!;=DDnu5i7`_d=TT
zMJ<PSgky!iQ1LPj%!51K1P<F#ZtM*}SH$u0-PSx@K50bizQ<Dy;AG2taSj29O#y|!
zAG#!tccu&*DW98%*ugEr_zvkha_GW(cyX4r7vpPXoEwRpVGDjimbq>{_f$gJLiwn~
zPt>&-??A@s!I>?Qxi)Tweu=|~zeG$vmF9<501w}nW4O*mopx*i{8XKHA9Pk-T|908
zFFC#y?!gVs;Z$eTVCOf&m+kM%(ot2%V<+|i8^X>U_ejPgulT2RbYS1DVL3YCdUW@_
zwjQ=RTP`6?PqBo#Q+4yuCIcs06<Q8AVxaGhp4^B%u8+$b@4VAVIxbj04n1|TYP}L}
z$%PSa;JcZvz{7;KIM`Pw!(yFO58IgxOT5M97~YM^u*B<Nb^Z1f_;L#HrA4?YLy?Qh
zM|+e9Ttl1+O7Nb6|2t*_fV(-5Yp`FI^I}MJEd3LbUMXTb#=+kL_+LRfLT^_2dhofl
zxpb^&Q0F~pA7>A|O(b)aTzu*6f!oiK8JXEV8u>2OJpmqolH7Ak;~pzZCqUyT-MXZ>
zqkn5pZx8<K?$7V&>D#sgPd{xd4ix)}x%@VHTT7KHY;A4lm7x2R3GF;GgN7W-Ycm}@
z<ANo_SEWGJmQcH41LhdOD>_cTviQ~f)0i(LUyIMmks$P-8825tM}IOv4_NF~&lpml
zhDGSgPX;rj*U8Kn>^YXJ;L0qz$)(fpRMG`HOn=g*+j^WFpM<>^sUNtw2XX70g5U-G
z<~b-fuk39x;%l_#?pXg1(ASe=sj0nbIB{mud(%^)4Z`vADZL9?np>)xHLEeejeTct
zgobCLW9Yk9Wz>0!JWw0<5c=>_YTGZB@SwOgU~LV0CVB|_3CVCFR^2D2KlG=p9AW3L
zyg&=Dm^-p_C(TMuHs)z8(xE=rPfHmChn+Y$+2D$>#FHuU^+C7Z(7EXe$P()iy=p3{
z;}m9W-W}AXiklx!Le5&0l?#Mg@?7c|?FahIemc-oUF`oE2MziHr^qLr=a<pXpVoHA
zz?7Ffx4&2AXBm!(F`q?xmGL}XZQf0gfoAYw4~J#=9(02;zVjNZarHciK5J3NRi$mY
z19o1dOtzZX8g0uhu*;gmyDA)Av(OI>%fwovYu5~PLCZ2>RZiy&Vcg$~z2^SD+CmPz
z(RJFl{B#%tntmEKn8NdXOVe+FedW>tuljE@)`CnYc7=U3Op`rXg}no|mw`RzU<Y7l
z*|Z4k_e?qrm=Nzhu(JTmv<U1h&Oc3hh_@5Al}!^^rR{N(zN8FMo1p;v3h*{viZ~iK
z;LOqGfhk(%o=AGMOa|wTEF%r@`1rJ!&Js%39kAOhJlXEjyRfIP>4fJVHO#$+@d_2+
z{ebz^0Kw^O+=6qdQ#kK@;q5`t^){Zp;E6^a`J;Zd*Eqj?hB~C0FPHg(W7+udsZG8a
zItKZe6?y1b$(C?}=1sLu7jduJhjSCU$FFYa7Qnblw6E4de}w5~zyJShp8T566YM@6
zSq%Gq5^Y63+F>%Z9YbiJmo5!a`~Eced>{8gDzz&9!x%Mo%u~RH^kck~;>IHI+!wq@
z;B-#lKFeoSk0Z>E_xhsfRh2EqS^cc>#gv7FrUxkhIi}k<=jWEcW-o-c@~_jztKxEn
zCkNaUa_Qhwt8t_JeE>M_N5ACf!swiuw;4DkuU47U2$`D4`k03kkP1$sBr>RzfAF7q
zSdU=MQmtrUPR*xWGoP0&67#`t&FB5mc-`HQZOQlYv`<c%JZTP^=JZMj>>rfLOH+`p
z?YPgRlN3{xS7re7DayF?OW^bP@6b=T{4&QquVzrbOxkUdhQ${Wm6qGVqt8=5{u6YP
zwuids3p$SAM@=4R9^;z$c^pjVQf9SY()1hTW5omj@@b-Pu%CCXY0|YAZMf5rL9uUf
z+?x)=#2v7a@KU5xb@mA0e^cS%hlyw&Lwr_c+IWfr?xOYd|GeAx|CC$H(CiX!&iH=n
z7~r`3tySNzGdh5J>jCHhI<4ffBH~V1v%6iKuU-TDrw?{H)=-N&VQK#m-|z5z-eg!E
zYwCJj@-!<PPuy4dlI$N~2M=vgnSTnuALQ7k=Q<)3s;+$y>0g$3NK4M&h!N-t#S-=!
zYHsfA1Kuy2J6s_k$|~RPkbDl;NVb#lEs*gq2hlw3^G8wkE1)grp9w2}&;$##zC_yR
zTni+?Ls|?V_r2G`zA-x&iwMh!hto^ED80CVpRy0fHzNK6c9VgLM+A}kCyk2B9JJH!
zfs=o~+ps48NX;!>U3{Wz(QYlfItm(vA8AeZ&6e&y@bFCQZV*<aW#v<PZh(2@OzYO|
z8+8`H#^Su^Mc}ldLEL*(8O&8@N+0G{cR%ad7l8*`0dmzG;^krz-hnysOzG0l9=e|H
z#vDpq*g^;$lyS_vh|!_r?D<3(8_q+<e#iQM!@N5=JU%&<o=i=pv%?cp+04k)#6i-1
z3C7spW383V&`FU?dg{ZD_5T}X4vvmbW!xQ@(edF4FONR;#sdr|U#6VWO&|J);48Ge
zEJz&`>pPcortZbj&ig&F^SF8D@5F`Y#v9P@J`4^x%!VFlRNa0WeHnrA@@BzzKM&C_
zoF30$uJ}Ff1xocHzHdd+%^L7OiyvPVyM{Z$$^3W_W7CK6`Jrour@)V|a-Ar%Q`oL$
z@FG&y<I@(j+0XO&#JFFAPsj@K-4{tWeA2$9J@otDx+9OxxT;m#I*-19w*0=>j?6r_
zGS_$?H8~#F7wtN00PT3#&PglxUFzO8Ftc^0e_Ls5u{&4Twk@|~W?;v*+(2O<U+6Aw
z?+$&Ja;2Uf13i5+eLHgf+Y7zDa7V&U`#_;TpDXmt6#ISOrJkPNzV80g)*Xeu?c4HO
zO9M0Ag`Qk@-}Yi*M{oZ&z=pm{_ky>iTWr4;zDuoX2z{5jAX^W+GlG`w41IoDf`)!Y
z&qV5I+3K*4mY`uB_hT%C?P$q?u#T3Xq3_b|7*k;#Eg9e&I4%bDW{j~AN6Q8#;$V!u
z5J$@fL~y8Wo58us!-4TQbOE5eeQ_Pro!C2t+-azIXVaea(*1oPr^9jPqU98=&Yj)Z
zTaD%UD4@^H7`_W<F0lRQVVC2ifcE-D>&tJ#dc~wO2Hy-+9`62ktUvUQM)s;PRsA!E
z)yCTU1FJ7|FUz-=edgk#m2oBsk2j<$8pWTmw%E6ze-vNbu5D1fSyaGA#_k!Q3eU=)
zh5f5E`h3&M{50}k+qMiHrRB~_+Zq_tXVN%5&u1JT(&(KL$&!?wK`Lh|r#!QY!OBWW
z;dG7mgoTTDKH`c+-j9B_m4R!atIjH)tdXwg9bM2<e_&#@W3}p<w=~ad*0z=LF`0o*
zQJVbz-MP~^_03q?={KoxXQhwT_=X%QKk3V-bwp{Y!Oc+HL;J$4_XFsnWOx&@jxu^K
z?LCbb+8zw2Cx*vTdr{wN?Gv@LXrKI{+F5heV(}&kP9f`Rh2dUt491>FUG4TRZik#l
zVQi0Ebb5xn2-!`Bb11<(vqznQ+{R!FIL8HzDoy0Gf#n-mtzdPIxd$@!hd47LCia!?
zo9u=hXu3Z^=p6I3pKlLlb?n{-nQ&!Io{z$<8Tv3!DIB9R=vwOWXnLfq(sv8yF|Vv+
zg3{21d8$4?M0F{AdtQV2>}9Ht;9`h_aT#!L$DH;#H>cHEsxF|8oFqUxzH0f-eX&2X
z^Hr--k-1A9-%A5M1HFA)OR!aU%xuqh7y9zsdbZDWZ!Puo3~b+C3QgS|#qOE@+{|`7
z(K*wbEB0>B6?W{{Ug#c}*|v2@X<N5%>Xy2<LKo({VKVn`EA$t;`?hW^7E0S;PUA|z
z_H8tEu{U63=ON4^Y=gCR;ZceU-{y9KQrWt0;G41dXyg8ovvFG%4Q<1gpkW>KRS4^7
z+1#*>mY`uBv~j&UT6L6HM=Q|K#-)FLSVv0+_#)(NT&^!e94#A|h=XfU4@av8L~y8H
z8G?R*9AVoVhwh$U`IevVMs2vaQ-khs<!pX9YUzt-;zq9xh6ks{hF7iY8H3}C9NU8v
z<I@uePBN8F4e4+E%}h;<Q4bRCw*WV(c@5yyFM@N&BZ#kPUF;EZ1pe#@EvT+Cy349|
z!kw5$n!<a&3hIx=bHzun#%K6ZUO31hR$f7PYsN0^tE7CL7kH-S*D3Dyuu`leyy!lq
zkG>&3thn5pxJ}TM)dk-NNY6~~gZw@sG55kaw2SC(o923(XN}G7PH=zjkHGt(a&>Wx
zkwUPap>@1~_Wp4&w{RGbBJsVpKL#A4UgGv*ICpiRFTRF#Q?WdkMGV_odFe<W`;=#I
zbRKx<Gja|;?WdhGX?y0SE(3SJNxPmtyIS@RlQuD5q@7{l9y4j<#lr&XXzfHFe=Q&x
z(esY~%lKZxnKYXIDAI9KA?Z5L-U}lC1nIL2a|j}1E}!ZgxQurGSKM7g{G%S8nR3IF
zms7Ru=~zD7tK*YvAyc;8<EI}2%_e<GG8BFTWKZkz;kh?r;pd2`)j2ZHKpyA#Gc!!o
zqn0P9ON^`BvHp3$@Ge1LA-65p)4g@)P66c+F<4~A=ikTh9LeQp5%g48VNuCA{`V$u
z5N5t3DR6%kg9{&Xv_NPdW%F|UEt$^9f)pwH%~)Bbh0eS_EiW{IQ(A_tZT&oOe?7t}
z<IxPi_Uf)8-iz%@<f27$wL3R>5Pf|HcnsN?%jYdUCm<V9JfXe=O|41VQb)A1iPG!n
z*7|s7@Eq00ZmFy93Fyx=tIx2idGj1Q9X|u;*mF}~D0S#QSKpP;&#S60p?B)r7#}6!
z`$=5ao^gGRSn8^)=jSb$YtE=XPa0O!zI$P-oN;}tXrG=XK8AHsv_33F<c`BiH9~l1
zcNf-AXM`(cJM@dOI}Ty3_4NREvtoTyuMm8J3K1zDOz5k`6P5F$mY!1vkF&+>K=;lQ
zkL0R1)l=ulw*~5D!KdG;k3j3a9rx|QhjUo3C#V?MTJJJ^HO{2ogx1tIInETX-U57K
zUrfDTYgSb6&9;9h;cJ^zFM=r1cLsOE%zXV~df20lDippEM%L-iduDYjw>``&YIRum
z3k~XaHzChK!?oRyZb)wT3hF-NhHKrY;3t*DbGf|43$bURzas{S*WWexRG;g*J&B0O
z+Q@6pv~Fd&*Q!;@+9vpcpIN)LZm(4<th;2#*t4;^%}mi`G&h<{l@zieoNfZG=TZ2y
z`)z#D^{~ka_1p`8u9ehNPi_;&CDd~gzGbVaCnR@e_2^pg5Pb2!?tBriaBE7wsh5;K
z`TFGaM;fH>zAPF3fd=W_h%FY@dyAvz-UjJiUCHow#nN>h-T8(HJXUbw8vC{;d05E$
zbVbT7H_3apN#5)m>v8tm_1ROB=dTHkb?ByWPaUugJ+|EJX5ws7&d8g)v-NDNGT!j_
z>tgJ)rgeov>FUA)J61;R-sF}kKW<xDIoq=E47T&lE$fT4PU~ZAwP@Sw==560eFI}t
zbY01E+}iLpfSuI9JcT=%2<OOmaL?4iMaXq<i*Je78zIlZJtJ`Rp>0mz@>RqahpVTr
z<E?SHWcnC4Es8HnpPtF>-a<Hk{Sop`VIFJ(qx>Cso5hpdObln!Ur#5&*=8!P0`B_=
zO^PepM2D;M`xD?SuAR2NI}A+Sx}s3D@vUuhZCHH?bkJ|h-q0=hTbBj<pdQ>g@Uv3R
z*9rD%5feYeF<5oT@>bU4!&9E^`>C-qdPX;d4a1}|W=Af3>tkbY5}XYxf_KA?EmR7o
z?PgPsVM(~cqu$ZFPAB5<Wz(Ez-_jSai}LK6>+l8JlHfvodY(?d%*Vi&=v{S*gCZwu
zm11qFG9T)mryIZ%DqEhLD<0-6Y6!AZoX=wm`kbDvYa1AY<xlI{kTn;_ajjl2qN{yS
z!@k|0@_u)10lD0BwlU|iPXM2yyj%<h?J7I;Z~QZr9piMMjt2H-vO79Br|l)3N%!>B
z4&eFjH@tgz*w%Np##-!+egitlT+uV{1odNGJ~?=Ba0GCAw#|FRk84}ynW0K?TJD4#
zJjZP_@=ad<x!$e8g*t5;-~aN`<xa=B^xIH9Nq+o=yJsC?ND6FoeA@+?`in%qrJT>g
z3E=umxnqJuBg6+<m?>tr_J=rF*At3kFK=Zqx)CF39&~3mJjeU1fUZVi-!kp519N?b
zG@VPn=$Jc%I{yZ=M)gLP7alRJ=+VqmJD#_gIcXC70sJw*GXjRX%ei@`?>w8Y#T`WG
zAN~;bqyGlJ&IU!)XZqE)o{<j1AbwTe#7NOGe+qlAt}J+@>5TE^(&3n_>Gb_zx+TZS
z;kTmc;s~v0e?!>UW0@LU5BXljM(hiWO-`o=_v7*4>$0g#W@>cL{!Drr^)r7H^0Ud=
zc%#bj?Md+YN%;JjBTf50a;1pt9P_H5E5}_N#s01Ntuq6;-hq6vkk9oMO4~|>{I<TH
zVt+oLEA|(}mBRTxoW_`X()m8LEF1a^v;+-(1|CJfuc{8csDd~nY9rKe?(rmKP2OrZ
z{>|YXG|qi;+-rD4`M=t(8(yd{XWvMTmVq?tjkW^ItBltmldfLG9yx+oc5nrZ76!cP
z&S!mi6Me(NaxPgX@60_5`DEM=uPsr0_Bj#K(fX{?%v%FkrxGVz_~dFTjEmZADbJ%~
zXAj(q-~SCT;x`kvSKv)uM*nVtyaA3z#q@N#2SGLXwg+jk{&dLyTX-jo$`QA_?uK!*
zZhaRJ-T!%>U5`!d#T(p5P)^4a^><h<JnP>51;XpOv^lR{l(g~OIPmEicBiB*&gJsO
z>=@GZy!$b!Z*UMvF71%O;{FR5pmZ;S?!OD^cE|3Dr(4R%vAM(Zl;D;a&yJ2~C2baO
ztr`PP%TG%A%&~=SJ+Ax-Ny{%Fs;Mg<NE-OFwL8o6Xf6Mc;4KPP`V8KTowj!R5txu%
zC~wl%NZLHitXi1?`ZT@6_#9YhuKx}E%WQgBA}n)p0Gru8$rh%+Lek~#FW+i&b!-d}
zyek3zwUQpfYu%ShIzx&fHh`t<GE3L%B6%Tom)rbJl8<y2orl59`2f$Uv7fcgTZ8I*
z5Ms#{*7Ti0E)T!;!+5@!ZV(Rs9YL;&=W$)S^7)xH<nw$EW-j`}@a-R%hCX5{?XF+K
z{_<`!&K5bmij@j@yiQ^{?24v~0|3wA*@u9G2MYr#n0Hl)Cp$K}XJ2+CH9iFYo_(nd
z9+#iW4uyK;5zz4z#ws4>Jd!mCs!NNEC>_Gw554MOFj_J8`39uWMVWdp>V8OM4R^$(
zT_)`@N!v5J*Gqd!(ymWW;Vv1+TN~`cXSJ+EN(<9pko57?cq~2m4H?J4VKT^@TR}sI
zq)SWi5W(SM3H54TXP8%|^`d$2L%EHyJQS0D{88ks3$nv_0<%yY6xS8t>sZh9?C@k3
zk2<**pN7)mKG;1d|4r+2qjz-4C&pwwBz4UfkL8a!T~1s2|5knJy`jSkda6?b!2EZ@
zNL&nfe%lxj{~7ideQTaZ-EsRXzqQ|(N5=fZTxjeF`g1+qC<Y{!!HCm}$)kw52wvd0
zJ-h$~!?C0OR*cKhusp*wd4+V|ri?Z$gNvHxo!YRV?k5aj-fmVdflS2TH|>0=Sy|(n
z7Oxg^W#+co^H{HPkaoaD>!A>W`|TZgnX_ZFwVDMB&`j)i-kCq;-<juetC^L<Sr@Rp
z-@XU@y;)>03)8}!4I)YO4f7UFp37pHHz55pCVgTOkD*Q8h({^lT*h(BG9Na1P+mQF
zGB3n+(xqdLLAtK1I>4|02R?B%ydjI(0CkzMPF#1HGBP$XcHLa{36nmX!-!ShJ!<fj
zhCvdFI{Yu-_cK_Nf(r$>%k}tqH$aAwS3yMnLTPbf(a*b6^Ps}#Z65V7>3Z7Kzlf)(
zup1KA#ryDrFIUUW_efJfhp|ikUCLaW+E-i1<PPIGFRvWOhLqz}RW+5VO;5iv<Y5{J
z=k;$3E@LZbKR#w?LQ9I$ksLe9<GT%xO0BklaQ3F1$~VUT0Dk7==CMbm=_gHkr8aLU
z()7noI#Pus*C*eV`f;}x3qyt71bKG2!Fi?UE}L%q1hs~8^4F#v<ZYy{o(9Z6K;K}h
zDV64OhgpVg$CMO|S^JZ5e>9J_EBoqFIQg~1&$gUJAk7|5=KWHi(n9(8NB9UbWKeNg
zLS;KTxi^J8PHQet?ZF{~*Nu(K?bz68(udN+sr_S_?BGEd4p}S*QH_id`d97}n9*Xf
zm@3@3KTO{u=|eMf`^q#09B;=APD+Q<{hJ^&pbgppVN+_EiRs$HyJ)ehJ=ZB^jEv}f
z!8kE2BY}{?e7rC$P1gL|At#y-jM-!5+UzixsQvkr$(KjF2Qd*T4|#7I<zTDf)ht^`
z*CcZ$&(!H&-!+_8y!ROx1Z2%DpkBwP&5j?`7$KkfB;E24HiPbAZbpCo4~Z`WjvQM^
zRSu_V{mA<&4AZP|T+=EXI8+Bm+vyI@=We@{cF#rYKZ3MFrZ3e0pC+2T3_?dog;{(+
zWUd}2KZE`;y8a%t=byl{3c`!hZhQi`X+bRFF*XR?@FF$_HNDMG$2}0*x3o9TQ#)k(
zJ$U7yIJL0ASgj`SLd_e7Cp7fEreCD#DVV6jQv-joONWW-rN6?ZL#KJ^oqjq-s^VX-
z>4P|X^58FV=~AtOf2Ef`>%ni(^z^dmWySw0O&^ZpM_gHBlMTbE+{5!4m(J-Wq!aOC
z4gARQMX=4$^IA<GgFCSYf2m7f5Z$Bnyv|F9%eBL^Nz?JZ2klCQf4!zp%JWYy{W49T
zHe+Amzt2ne`O~H88R-^>=M7#u;kllmtX!_?*LAzJH@dW~E^V_*<GRC?eUqk*EgYT!
zPL;naG<_V-{J9cL5tH}VD$7%ho;zNIZ1R~I=&lRaGf(7M@}TIJ@U)aQJv1NsdU#Rt
zClO54WlOy*kG%$)KRCOvxL9O=lcp!N-bszVK8&!tVV>0M^0xJ&m@6lBy1bq~=5fCN
zJK((bD>9x7Q044Omp-fMV$m?YWBo&b$2wp%o#xdEJ`ij6x``)SnBkVV_~obY7jW{{
zF8%cHHRT2%LXy9p`J>#OHQ!%g{(b?M{5LRvf0)0U-@}tUP7pf2;?Z#+HMT#Ebk=j9
zN#EKtVBn~ClwJe@!D^8G)FJ((=~EN?$A?D8_h$D^a7hE6bqKFDA3;P0N2f>mye;Gi
z_eX@*-k#LdRO&ig@BK_04e3A4?>&P<Y%uBiZ9~Vq2*FtSUozjqN1-3Pe@pY+(<!`-
ztJ$|5$jvPkuNGQA;laAlBw1c|oEF@az3iy4M!uK$y+8bZCBLO+)@}4N_m{tI*Ed*M
z$!qEH7Xozt%3xjvELO^V0D^oqI3Bg>axKBLt)9d@N_a^}hh1vd4p8V!=fPmf>|Qa?
z;Ck5P&C2tlEDD-6uXcfyvw80k!%XuSpB^~zG=jPRfMTxPW3fD-b$Mghm-fq1@OA#&
zh&^cJagPpd#tRW8yt*r95<UT^?Z4B&E$P01rk?`LKjRz%VePGsHErAgo+BNB_!bz-
z(BXN)q?0cZ_%ZMo@T6mg8H)eOFg*f)3;0fWyrL)ZC0mW}Lpr`;Rf8PhH~OG{+?(`8
zg~w{jhhKK-V!}B*jr2+!Ui<PCkUk6ka4*U>!L^zDrpUtv+3cL*9b))+<3e?S^5|aR
zdM?NgY&TNageKEB_W}Mpv>gxg1@y3QXmf?>;d<;Ln~uOlQb60lJ|nzMxBAr7!T8+B
zbL$tSb<U<Q=I3%%7!{iSv`H^>DFX7KdkmhDwSot0&>1JsPn$HvO4FGt#B&427V70&
zl{3Vn{T%Nf#eWJg{}S-NQ7CiwAno}eM6c~-`u~)4oPFXcDttm`nY{w`*>?j(p|4cT
z_@wQOeAhn7H~r0Wn*IcM_+7{W-qE3IbLnH?2hvL-AYS@zv|Z9|0j2G<O?L!%Wq2Nj
zGI$UL!sewjzN4haa6JQ<e+_-!-hofF)AR>*>A%`LU83{sB2C-FvM;!@x4LqSDfoiD
z^W~RQ`YFTzhJ2D@#TaGHn((AKOXnkb+1yb)3}cQF+}X@SDEq%CYkZC~yFAcu_DHyf
z;RAgbNN6|pES@u@zl84Dq1a3RUgE$@9C(QXFLB@{4!p#HmpJee2VUa9OB{HK1OLC}
zz=dDi+J^1GfW8Rd#h$_DKYtnGKK;jkV0noD#iA1bp7@gaZv<;k{^q}z2W_3)OKS_h
z^W4S3npd&><@oNv)&ldmZe$*QUxKBa{KH<Kr1N79;Lk@Me>2_GgmVp~v-}&7ZpycJ
zUcj`ICY^9=1aEui%WV2^a2`&+Pk=iApYcyX;FcWXvB;7R?;Hki|H0J$#GKu`QEz+a
zg~WM+eta!)7I4&CkB_Mq*F_drGy3GsMm~!x5g9#n(F|ZDFWWm`VR2p+thwZ(SFH&y
z#&-Zet339n7XZVwPNc1ckGZC?elVwfy}%kCb=dvQGvbf*MSCafCa=a<#w!FoVpMmp
zjka>K%x1cFzRKceo2CCz&%14#8Gj$Uwo1BrGUi`Q+bMTzT^_uB^Gg+MPc8>GpE8TK
z+p=?c>_!!ei@C!^@Q&?(e6?@%_ym6+@pGvswRJl#fqYY5*8v~t;(y^7SQA{zHlls6
z<KGk9!!q#g_~w7F#D6~g>j{UP%lH@YI<{VJ;a-iu95r1Q?hOvEy^}oi>ri?~n_tIf
zTlP(^Y@3Wt9gA;v>Fu5Ty$<z}CbpAfRB%yw;GY@G?VWG+%AD{07F;N!?Oua&q>Ft-
zJpATp|9+N19o@F94}T@n;_y8dzSqK2pS%Z{v<=&A`o-Wk#znxp2#SM$>HWCf;uvr^
z+B@F^dVC)8n`L+6Khn!@()$Cp>@KgY)OpghgS4nVTf}drYqy10x>ER#)3t{%;KiVY
z?Fr6*RjB*2si}Q<V03tLa0(|-dnuxsSQ<vy%Y*YSxg7O&h)yxT+d8OU?C+O(zhCbC
zzR>%<F8tkoQTV&<72)qSo#F4cSBAgaH+a8a9sX|H=>2}J_xsZD_j#}T&U2Ty8QsS=
z1c4j|1=M@P;7JhRz_B~KRmb~YNgJI=TirM!-$Qr;-RO%^`JNco?`!0Hzx#ftDSxfz
zkIA>x(W7<jGcY(GGdRcPd#pHbzbE8-_<Ee!iGH4xZ{D!LiILSy?~=4BoER6SEmO9P
z=1<G_(71kQ<U2JoY3tZ8-$GX}VJH_kM?C)k(xDGmBo_^2X*xlcOqwT4Mux5Yw1xfE
z*6#gY<NaP6{%$`n{M~jz`1_T<OrqbNd~Wi7zux<OnfLqqzVqB)+xa3cC)WwDMkfX>
z@2;2cq3iYghva)=Sif(O@BQxkhfVowHUHi69hJMRff-VmLm`Zlo1CP*Yf$@iM!pY7
z|L5iRp!_b#@9X7vQGSoZH}d>fU5x%M;oIxqrhU~P(-r%Mpey!WI~XYxO+*iSJoWqO
z{4l)}<NT5aW76_Et!=ctcHf5A7>;%v7+zzz+Hb>a9AVq<vb2BFecveGL#gX+Us}HJ
zQ+PA}hupUr|JS>3JO16b9slmzjQ>gZZN~qU>oYU<hp*TAZW4MR3!sPm<`|r_eH3M_
zRnE~w%kQ>M8piFy`}WRxlsEIeooC-~=72?)-qy);Y=y75bims=i*w*2VAfciOAf}Q
zYuRI7I%s$B$7AUV|07;HX;%F2_0mb3roS&tmvzBWd~@zx1Po`wA7wt~xA%u|on6S$
z@+WP&&XJ7ovxt1L7x0%{_yA#m<0mXE+ukKPl-c&q4~FSN!_D|+dA64{{G=^^dk81%
z5vAe7HeG4B1>Y>|({P8y@iQ?T%D0~j(}jjx@y+tGAOZ~^vE_e0gzKapQyT8F=}N-_
zzFF3%;iDGEFU4>u4gV!f7aC6Bo8{SG<ip2p`BNcW=NpluG<?FQD-BhAv#d|UJr>6&
zV>pzCPrGz0+aEA}_p3Jjn&h=bW->dN8XMb_8hmFqJ$_(xYGOQlpx2n>$$1!A?E7D{
zc;DU-@8krcoXRp0i1=a0WP9glZP^BEL)JT%PL1!M%<hHT%%npSNwswRy2Yiu<2dDi
z%DW37$Dbz*X#RqQ-IGjnYA`c;AeDg+4g<I1fu4-1xjx<2ecIw{urBraH#$C@NsSMt
z!?q~bHOJ!oVyr#Ch3|NK9v}?b^V=3y=kv>8BMjTQ+RPVY3-gDEm*(?4el<3enKve}
zgfHX37st|eKKK%F1;J#ce3W+vsB_I4?m<as9_Po<eJFSMYH3R(1#P%2Vk->8%eX4@
z?Uw})_6?xR+o8+9g6{-;nK-`B0be^;lY!69$*Iu^xsN$Ax_2aCep_<>INh<v&>q6H
zC&P^4#U{yLlbk;~4#$ttp{6i{aPP{HmwSQ>UWMcRcCNo3LL0M5WRr6T`x3Lj!sosn
z;o$-H6}r#Z#GezsO)emusMx^w<GUjmoGa$$mlpRT2*RRC{|%(Ci=+?caGQT_5O;KD
za`~II-zi(2!4$6K4Z+RN)bX1ryCFzHY9I`#dJv(`;PWB<_&dnk7!2bU<y`q@ldBko
zp5I0OCaku&j`%(N?h3R<$ksvyk<$!)mxDi>gK0cK7(7Sa1Xro{uL55GT^Z%vs&o^1
zr1L!aqrb@${mnM&Z?;K)lV<+DB3Vad(tGR>PVYfinR)PQuDsc!yAR*0f2jW-Wj@C1
zpIA86RfHq0A#8i_bqo8Lh1E4WVc8b8A%tHO{2AeZ`y2cVx_#Wf-r#)x=N9%a5@6Zx
z5N~_%goXX97_6?<32WBr?ZMwz*e5M)gE?V%bS#}2-Dh>6eu0am|8H$s-HZ7<d@DT{
zfQL`nI=<=P+B*ruHup!yOX1kq!m%M}u}m44S1E^-wY5Rv*hu;CtjoYyC7tbH%+tW5
z|FEZ}l$nm!FVIPPhzqWQZcpa#Ee)|X-&ksDZ#p}QS!8c|iik4VND{Ca*?Gpb$H>k<
z;G6YOf3V&E$b9hUe^@x(uOuBofR;|?aHY_UTiPva1GZ8UMTfVeegA~A`mbXJI{cal
zKbzM<{(f8Vn=x-}o_8(f3Wf&q1uEwJe+CSA8(~5tzFZnvUk%GNoEgpt&$RutpAaD#
zk(#kDovTPcQ-(}ht+JG_!EepXHQ$lCqj<<;vqu&7<@11}Je`j<n3+?qnb?z^*mF&K
zFq0jf$l_9BT1*4PZ-=#%+B24xxu-p70>^oOC^a@Qp3WYa7~2o=m$_zbvodfZ9!zKV
zkB?&0X>c$-J)MQMV9Ir@t{iNc>4{<7p-D}e@~>!CUgkOL^o#Lvy*HPA7rbfGO5-Rj
z(^@MibR%(F9wP$#==9`R>N=QQ!=rn%(}St;u~9G!Uf<~{I!x~$pPqzo^zdkU2y$-v
zrB#{9sfoQ);M?c{?j@PIzf~Cy)~T`7AgTd<t1Xk=KZ#qbAaZPIcywx7Yysj})3SYG
zy;)cyNjQQN|IvzgD>1+Ym+S-RxAQUXsY6~szqKgLVR*2w1rU1exm%qrhKm=)%6?o|
zhPQu}R;2A0mp;Bw(=6qs%Nw1~(X=Sa*jW>}^nJPI@{y$@2A7vUI&WSBg>4(!R{sm_
z%I=>|Pho_>Y-el^xX@3ht&I)qDmjzwxN41#@4<<Eqx(|O)FQvxQ4G_u>+G10<@NUL
z8O=<k-?e{q3KAmiT^qz;M#p$9d@40%aKJ8$;-ALL5952sQ~T1>qkG4lJa@+7#<2=H
zkcNuMOkFoQfljscK{vI<VKY-$yA7rH?B6?-%A|z$wSa4n!wLOh(J(Hmqh=%DxLc7u
zke=eb16*RihF?9VE|!nwNtyGa>7y{PC7o@>1^6_k`1DYgP0Ws^$M<GN?D#YJ2QpNe
zdsCAU2-4CP*hXiro8*Q1YqNuUbR7PN;2s^@m(Gk#3^CeDCOZwYeoWxl?CDYLd|4SZ
z9ZG8UjgDkZnW+OQrw5|>>5(w6BZ%hh0p7tqV-th#RNTT7X#;M^Lmnc$GU@$&E}ilL
z9-8#wsfm5iW&2X&kT=7BpC{R9K29AnsnPLlYI1UDVjq4fFDNSxCztNHP%@nX<EJ1o
zRxZ1|cBE68Yw#-V{_%Hag-PUfuvYjxmcqoso>JT<eG>A-At5=>O<~L-gsJF~?_tbM
z6(xR0br5#~3zhMuBgINNKg9d8*s2pn(hS1r{@<~Bq|KjE#?zU^3D)UiZ(gZ`WqbBu
zo;^4^1c_rCBlBw={Lu8^WHy6`yhLU$XiA4aDVjME_Kfi3-=lM4T`kFzVlo)@63_o>
zvtJIqjepo<GiQcokH^@DYSXvLCL8Wl;V<pOHT-*mZwV!yw@*!P%NpSxn@A1Oh~Z>A
z1YI_mnV7l`lLq>3f3_tU$fVuc)_ET4<5|VKlk2OmYY_LIj6uwWyQ!`f6lxnk-#?==
z>&4Kfr-@ICe!7-BvM4qn{T(`jeYqPKD!Oo%bt%(d9^kHAES<bw7wnx|n90q_ZUvXp
zm2i#P>E})3RS?Ld*1sVb#DcaA19ZA5TPzp{d^ny|A(D|>du$AbiikRPq+A=u)$Tnw
z0>6ouym1w3uHfU_<lr(3HIM_~M7S>4{rQ_Pzn03&xCM{UJ|Rt;(RP_eQ*%6O=ki^c
zrZis}94J?6OS!py#Ul%q<B9mUU>|59U#wO~in&Fzh2z@Xt$C@ExpBCUF?3A*<Z)jx
zI6b7Cx4dF{KiY<XJqRaR8^aZ6gVp2ZK#(q!Yh&1y3VFXP0AH85XE2DDh{{EuSG$Ah
zv|LIqRtyU~Tti{rAZ|}a`fMcFi+jF>!QnyP;MTpdN#0bz)yt5NV+zLyf^xO|Y#h|9
zZ&G0u#!%#VmWk&Zs$BlHCO^WH3oyQJ2pAw`ltFW3<3#&#*1)F<1qe|!le?)nKboth
z5z_K_9WUk@!`AU;(ZF)k@S3F~iy6d=DAr<asU^Y0+Or%C9mn0fa$b&<r-~57I=XHN
z21h2-`--(3y;kb^f5Ox=H9U-aCriATy@Wd@;d=gLa=!L}B6K{ytpQCFr4sJG8JVM;
z-rfMtj&P@AK8%?V_V3YRp~sE$JCr8Kf4OuVN(rOXNLE9-?hHm?DpSCOMV6dU4)1dH
z^tyWP4$||u#&r}*1=oHLFI8liYm>vWr-B0ubI6-3Hs<p^hUWALH~DarSWw0K{N5y(
zSfAf#V6GkBn>essKiu!&8V#(F{?iUt2x?To;eG&njn$fr?}_RVt~4>)Td`mzNL&J*
z<NVl-`MU$-OaDC>w4V4@Ge1t*{S(Sl5SU@jvCD7R)sS~wtMhaX>_n4hdtb+ShwJ-5
z=2_YuFZbw%PgScKbj9<m?zM4NSDONnmBgmF%<RWlvjj0&alshoLPmaJj;7tR8*L*1
z{TBJX82cvKem>Wx{&!dGo4oS#xmTm#U$p!+dqAKjy9A1i+`K~g!?Y5N8k1%YB$-wo
z&^ctigDb<G#K2t=rn$0aKTFEGI$r7EmK?qfVVc9oL+c<A`UD^Oh!B=nyc+4)3#;Sf
z<#9gqhPh=le(t92<?|Zmr+kwS<c)qS@AaEx`1#6v&1W0^{I1xy_JzW0U+`P|;<cu&
zAX6AGWAf54jU6OuuM5-A8HVqhyfiRR;9l>gfq9a4nU|*czAsEeXBd24UYg>2gO^5p
z<Td-^a-<^;NA^epuXQi_V!&{GY!n=A!DjrW&CQ#cw7C_I`Gg}p#}RL+67I?vTo(qi
zj<>adyGr1Ueg7FSRq_Bs99t}ow^<y_WB>W%^!pwD_D&hI?~nQdvTylcSawa&WAXO7
zvZj9atxwxF<cH<VUa98u1e<vL@eWyh?lSlTV*g2e5c|;{(#ya6kN-k^=Lb729Y0{{
zATE`+Yps0iH}F8-jjtisLBt!<(jNSv#kD&DS0;uFERu7lpx)m(eE=ITS#B#}Sv@^C
zH9CnUl2N3IS-W*Ff5_H5AJI>fHQ%o6uxDPX<JWmQo@rfZ)4CwT%k?7j{JzM+Y<2d>
z#V)NU;Q1N%`-V}!{)0>>65FaB4bJ2(u4Hz&RB(dwK4SUs{>VHy>ef14AhJEsMS>l(
zNLv#OBL2dBQO_X>w>B6n9z}}s=Dc8HQ6fZmYm4)P3>P87FY3aM;GM<e4A>5R!1mz0
zru~{k-Z;u5Y;md5o;GQZ`j(E_ws8$i`ZRsqOD7GQK55fMP9d{A)6w~L%H}oTxtZIC
z5JYMO@5h>Br2Tfr4^u7AGp?R+{A_@X&s%>ojv+*{gbVj!xQ-j1Gp!wI`I)&zofnz5
zmTC4JncwI0yE2#eVLAjRSD7uCvlqg>9BHt)a2~u6fnCS++;UwyVwd8^xal{R@8q{v
z?<M%oSFt1P_4Nj%l|7hO3rvV(BfjTKIZ`X~K)jbCZQ<zrg5u#^y$NYpJ-P9;nJ~p8
zWy%a?jpeSeX}l4@v;!!2r77op4|(Rc3u&km!6yTeH_WH)2LY@9cB`Eh_L`Bmcn_m5
zo5}*zk`aYzzkHZ#W#Kw23l02SOszcEOb{$D8Q8wlNJknR6O;6oNsT4oiDg+_(Y>6*
z2*r%0o$&UDKr`N3###lN4h1a5ZJ*zO^o<zv+{nnyg?Z%D8u0mtJwCsnd=5F%luyKM
z=I{2-to_}<m&f*$%n7<_=HoWAh325OoX2v&c{zmO1jb<rXAUY?0rqG(3RS1IoBgV>
z^88Ijw`*nF--YsP%)V7(KJl-WIc1{6-2&ws)6HBnQ5p?HV`H-{C-pLaoh`S2J`8JF
z5C}5{2-6wZZH9@GY%s_w(~c45ZwU6}s>S-cH`;VTXWK&fO~EKsP?3ck9bMe#VF#z?
z5Etc$oF|btgx@SO5oRb4uQWWHK->*1S?3Q=ABQ{Bk?5SlF?^NbT}!wv2A>e8ShTLU
z8ytyw-KO01(o8i%ftKwtWfSw+zP{jKdA_&DRvG%>GjG85k5ugO9Q$JMo0%w?(O`5K
z;df*H#HQ9X&(O4f?1d?5!f*0qIDoGYrrHY5;jmLt#TI7OmzxobUp6r8Hiw@-=I5J@
zP1l!`A#ICVl(dk(jF)GN37yQl7JHf;_hz*m%HItE&KPEjm5I{S(Ohc2z?Rb|m^f!J
zz77SHu%R-dmEq0u<6;ZpNv`%h^7P+RsuyBP$sfS6tliXoO?3fJp?GXoKQ~8nfQdFy
z(dw6|ugc^sBKu(f*p4x;k8vNv?9<BbEqzstFT-KrS&84=#dh8|Yt?baaTlJ=qCED;
z%T+r+lK1PhE+xYoubsBfrgHSD33bN?oZHHtX=XvQTwiYV^0@gYdrEemXMLN(eCRa3
z*NhJK?0~MY&%NT|ynMOK_lt)zvzc~eM7T{~(#Ndq$pw7Oj9!oSm@gL59Q0+lcF}cP
zd*@BIZ*^_b1v`)JBy36QYY&bP268ZOVRg;OdsjZrMdW`qVmI$IFOFN;;P`EK?YDZ<
z<L%m@{!E0lbc8&gK7M3oVJ^1Ew=Tpf**eBppUOaN7MA{I{v`?grtLwyyCUre5dI+^
z<*ICtw_84tem5QxWYo-mfsEI7)LHZD#6HWa=WgvA?L)3JX}2F`-=PnW@$U)t+nQJD
zUdTGk@mD#YmTY!(I+aZwNR5v1z&m^G0QZ>8Id?pdPc-N`azb8TkDO=nZHOq&)PZX)
zPTX6G<)z1m;cKwh<|D>wEFWcUo#!XzZQCmLt(+Ct=TGf}Lqc*}#?uI3DD6Zn$XK1s
zGxw)Bm+Zv3GRGr%do%dywQY3F9uOYvi>K}u-y!xvzwHC{kJNKhJs*W_h(22ryw~>G
zt^9k^^xykzS&q9C_|1Q7Fb;`V;7;(j*$+t}k8u3URo#zSd?y_avme3yC@k(zSlFLP
zfaQBAA>Q`jgBJEfG1%R}%l`<=za0IyTiBn9!Lokx)5rVM7WR$=*i?*$pS7?*=V0|d
zxsm+_>xnR2r1+}9oy2I+`gC+3dHnMhzw-DO@J*Vzmf|?O%hK_SF}ROfIQ}KvFIl*|
z9h}9Der~Xi3Td)|MdjE#o@(j*xW(JRpEYtxz<!{l@$39$TUO`$Q}_;ow8lc4LVQNq
zpP(J{3FP4nz<62P9P+vyo&76Pj%BIC5iEW%EsHMPs1V1oX1vz<h+{(c^^7iS4?aoy
z&=;TL-xG%ag!6q{@3nb^yBv9TuT%UceV>Gn0gnC0F~>1-pT+%IhkMPdeht4bN3Na^
z@XidsH?5(cLwn~(9IWCoV^YUAVfkOp&X=aHHNkJ79QCl~?}8rwOl010JeTE>+M;X2
zzKEQ=vY$G_yhuNhKkLFgor#>?(`n~Wc)r5kf@y8%<=+I(4PiM1<CXZ-Sn!zr0`A>?
z5it61((mV%a@r>2iTh0r#^*3xJ~H&AoKC^1EH#x*nekblzI(UuvI~TepHMZ=ea_mE
z@~tvzIOf{DHW;dOqkiRW2fnv@-|O(LXEDUniSJ%7e*?bt42Jpem#A#F`M(XmY{D5D
zLJCgf#M7-aZpWJO@ZNCka|geN!|yx!oesb6;`dPajWg6j*`wi9kgodQ_XO#gWiS6;
z!293#1?jy1eSeTfaD<Qtr%`^<`+guuW7{gse~|PHhV(oXq$6@jK0FMX{4$TQ%(N-<
zJK)QskSW~ZDHID+#lyVL!?+yK8}!%uk|$4(wnr~C`MQc@rwetlzDbOoKZ}eV>ZHoT
z+`&*+5f1iN4LdhgN%qzX9oUCG9D~JpVf^^IbL~!(K3$xXg`4YF$O4ub7Tm)PnLxS&
z7g_tV$cDB(RVn7o8izE_1=EYUO0k=^2FC@?dfLC@@njKx{;L}oW}YW*{uk=I_TVAl
zod@5ny~O8S;5u;>Pag3vT;%3!vc9%9lgnR1sMAFRBQ6%|;b1>GxCE%@`e8po2a5gl
zRn#9sBX&EUSd|M#4g=G6i|s_Zf8X+faV7ZOjrQ=Li8EpBp54%O%rl^E!5`v>&ev);
zXx<}U-frMwInFbj3%-Ut|C{zx_-$+%|C=^b5Be*pKbLWVM2-4#pJ<qwbH7eHPGF^A
zW!TUlQGP{U7SX1)fkcItZ`w;80lH|bksE$@^4p#_@_QrVAk^T0OgSQ5yxaAss7L>G
zX$)#=b1^33bQyj=7HM}|@D2OTdF(<cTD_zA=e7;xiOCDk3;xpPy&ASDnj-fCIj{4-
zCp>%?pp}1xZ#{?Oyrnh(VgCYoQTX$Nzi9wZ9wx#6H^5&CI>3(zZsLvNJ}>yY1X$ut
zg8e37b<S712^;cbP4M3VL!04g{ypL6g=c_&Z}WBrYZGJ%55Vr+={k!2cEEk@My44n
ztm7HtImt5+d<FZ(R{2MZ8{<Lp^{nSxNWTj7=s5W&d|w*8O!|>{{sI48`0}>k+xW|W
z#J?M3(8PN&`sG>VvAy->Fd4gYMy3c`57!p_i-oJtGh>`}<NRA<>ijccDQDlYf1kI1
z|0n)x``ISq`d6g6c65a8sH+D?9(4)-5eNCgHWDs{bmI75_z$7Y9bALGwk$fsk08t~
zC>do58KMV-7Rb9#=Qh;Ee_w!Jc-aQLTY~Rb;8xOi@z-@bbjW&W)EAJZ&sV-f(q0+-
zn=OB92n^U)2LBuBs46%%o3lQKZNc{>Eh~Fvz}LpIcm<Bpv$97^HF|4ixl@_V&n@89
zEZMIIuD1Wz){)H~EyACAZU``DoxJu{7Y0|f|GUkn?5zt{F2Cnn`C>otVmrqRe=}m3
z{wB@(dyP%M!s<}=7g}(TO{9I-jW6ss3@y+*75rhpwL>SK$HkldN8gq+>Nk}4`%UGT
z^pXxkV_PTb)iL)nORuhVUXE|JLG=Yl3oaxKa1b|f)XQr)w(9djIVTR0W#Hg%)@5mu
zd;igT+k#7My&R{6qpij9emUBSEci0mwN8gwkL_u!t7h;jP$+%WSCN#c&Uy{&#dsr)
z{QV)J*XWGb;#=Fuyp8yeI_XmU<v;2)rYnCp;rCT1BwgD0dVD99zs#1e&kM&m?&Dpu
zrY#6w2U!07KK@0WT}e1&I)pTl4&r|!emmNshm`iDJf-UrTlZ$xiMrpUbz%VfxKvmC
zJf#Q^hf!vr9iMvzWd98)6JfjPhYQ*+NBXVN48XSsS0FvAOV$YNO7y{-QI`MW`hYU>
zGU$UVZN8@uq7*cd5nm23h8#ATBZ<?T+bcf#iptwtL5s>8fBW+GHhim0FmDU~qrANx
zfBBE{#&ngpZv6J;Z7aT$%J<mvNqMR_>hnTbl=%;G@cqC;dFaJo{0aK_jlbLQx2}9l
zCP}x-<N$uV_CY4KeZ&#ZQ`%J~cd$-WzEkUjO!~M~CO=#!lWT*1lnFbDbJzuK+mR;n
zXnIa$@duC=mqo&@L>6}ej{oAaNV$1AWbqv~KPHP!<;Iu6S3m~qc^%p@<IVMA4lh3(
z#|yH@vUA1x!+8C{iE1pvO0C#%DbTDk%iq4t4&qzsVcs76N0}YMU;d-aGF@eM7{7g)
z-HY#}@*}o<eO@S+sw2~YrA&<SFY3G|31>_mNt4RsKKypHLmriO)*a7Nx>O#=StshA
z&^jTHJ}#BVPg!}Stg4QDCw_}O#&}O#hO#+^d?TB20P5KGU=sOpIc1rZ$mzQP$A57-
zrTkE5PTBmpoW?0xiTtq5FFz5T)3MONIc?H<gKJQ}e6=95>AqmGQkD(?m&(#X;>Fy}
z^+sDTDYAN<t&8(H^L<(SA?6{SI9N_)i{C$t|1NBA3vR$){!=)Wku1_39BNZI;@~=w
zdDjw$Cuhu~4H)J{%h65?^L)8B>mXO3hqIaO?|9|Mb)|6`&4}3kVI6IO$}0D@X!~D}
z_R!9MH~u;lGLNqb4k0ZjdqECqcp7(B;+tBy86WN)Se5}F(`Jf%fYp5G@hv+IBKK<o
zephnG%!}%h_R64uH2%9aBn0~sZ9x&~w6VF^;o6{N;o@>lS>xK^u+68Otn*q$Id-V6
ztP!`$S{c77!;mzw?QX<3ZBq6<p>ATnl{o_kKL%F@XW90*ugjq}L}m&1ArJR^EG{YU
z$tl09_>Xd0!C(GkourL&s<bWPTV>lXbJUip&+}!^taWREr7k^Y|1RS%>mokZMI1Nd
zx5Ez}C{0OuTDRy;;QbMc_ZIw}hrDsUWY<sovCD@OA6!)|guWPyfMY*Lav&SDHIF0D
ztfE{Gnh_xR?ZJDI@5?I3&;^i%Tam8+bR8DM0I@*m<_2R(*HM%Ol?U!ea2<65X${WR
zyx}-+_a9M5STPf2jFR8)2Oi3k)<rq`G5kl_GyG}~P7(&N<Pl-}6ZNXBgE`&gaq-8^
z`~2|d`kx>U$Q<$U_lJN_<?4g@R@q_RZTOFK{fF?E{{Satbj;k2bjpgB|0#SYmH)6U
zU!PaM)(q<nWmfIep9CJx#XpU|_!Hd0Z~Xlk{3ULd<$v<;WueVfSFfjUl@DwO;XYz<
zNZVm6Xxo$Wv|VZ|{5;B%zF)v!sdKHNM{%kC{i3xM!u8bJ;Ac_Bb)M+N3xl6S8X`q6
z%vU9bi+L6gzxkfjTp33k*ovhcaVOx!j*y-=w!>XW^T!1DUkJAn+u;`h$A57hOSz+t
z{iw~4*$xfm&ew@Jdk~$-exfYb_f04hE!JWjQSeb#3&ni;vi@<_VP&1aeOdoyd~4mz
zJB9x!>z}}1{-dljU1j|q{Pt!2llV?5|0!F(J}+!neO|q+{|fL>mOhQYl=XZ0jlaK&
zzbsGM_@DeskagFln5;8hW&N`jhqN8Cu5Bm&c%HUPW&Lv~OZt8tf2BQ;^{~#+)<}}|
z&!7xt-F6^sh6{sVL)uDY{XW2ntlPr0lkZ1bT-FJ<5?TK|;P@{t>y$mp`WI||OxByq
zo-gm%*A;muZ+v+Vc@@gVHI4Op76)kacv-$y&MwT{h+{$#`?}QVUc_&Cb@Dg=lYgGP
zQ2#OA9~-~JayH$!qY3vQ{^L0L68`cZ#|hJQoO}hp{c-ZU_*QxM%Rgkx*XM=&(DmP!
z0ZUo?J^bZZ_-Yc)n4GgNmGeKqZ&x?uTxn<B@jRtV<@^s(mUaJ;)(JWHaj8!KnAPd*
zSFZmk)4z@1tz??^&F>3byo1de@nPiMTG!8ktPdYSUR3U1+4jds<G;8(Q?|J7`<l)7
z<hdR@Rcc*oC|h-XhCN$7kC{q7udHUXQ<=;tUEK%y=;lzdny-`>xv?)MSmS(atN#h;
zri|@O#-G7l5XTu!6FlvmUk4tJ!z+^UOzs;p1mTC+Xzxyjv-C<^M#`9pEBV>uaROQZ
zSsSpe^UrMCIOe`#>0^8;+RTsP8_|fPZ2=$DzXWHvOGoIMkmL1k^4Iu8{3*(H;54Ra
z@045)EE|Gc4c5cV5+1nZ9t3eb4!DiMV!TtHV?XkI_s^w%(m>ynY~y}fK|da7&PzPf
zI|omp3DIw3bd`=t2mIvgA*5g1I{y-MQa+AazOlVnP2mnjc&~<OYl8(7<-oR|X&phn
zV7)AaC*=9M20SOfIurQCwvk_d<?#zXzA6Gqlt(z$sBJeU@@%srb^|KKjhoFl7pYZp
zd+_v2HM`Zsu~``?xM=(a{wwI``1n8Ey$O7sM|C#->PnX7C5huWi9;3~Cxl><;4QWj
zLSpGkvM<q=t1H`CK**MCE0HBdi=Bi`K%g{G3Y4wv`&Qc0vM+6c(v}Y>rG?UdEjtt_
zP#}S_mBRNtXPI~AF1DP&*YE$oKg;*dGiT16IdkUByfgF8un+q@ep5fPpV##I1u36Q
zGxi@0x#yP8z0#B!F0=5(NEfGMixWhYvN%$a`KAW?NgGU}n9Un4ljG8WJ9RLP@>2(x
zF2Oz%ZIj%mjyAccJK8tS_4$?z$D>$#`wGh5X8S8BBgSrpuSWVf5BfN6{)?26@4IHT
z`$MYRshCG%aG~xbN_5G-{Ogd>`|^LoZ`#7a6Sk>Zze1g%{PRabKDp2N2Kb_Vg%}l1
z&rgCH3*U_Ngm-tn4YA*NK)#msnSr;;hWF6w>TWT{Cr1$sEs7GFjoT82Dfjxho!^mi
z9=|P7Mz*EzMmkxxsJ3+SGP-Wq-tSMll9Mo?mE+m<R?~;KtF<TDu6_VLRJW^pBi*b!
zLAzS4jQ8I*JcqhXFmXh#3-`0I{a_nEItknO&#3%M7G)dvUq&?RAmdLKAtU`0?f0jV
zj7_0USGj<?L&4lX-5;CWv<N@Csmdm~c5yPk{=ZPRYMcB;RNnJXV3UiLakKehor63w
ziqp7c9}2@Q*>n<a%Z^Hz<6QPVzl`L;SvfW1-20*1O;?>*x0|l2(k<QxKPlZdAwjin
z3p}L7KIa}^w~LnXew1Giq&b1V<4HB~IO4pMEdP=^<!_D3fAR6lf4^jeYEP<;+9DaR
zHhWtZ$%wi4v`f%|NQyyE_oEIrZCiv5ZUgU=Y0u|kpG&pPt&GaE_V_wqv`qJ-yjvFG
zE4EboGrR+QQuTRSRG*ZQ{=+VCkyiK6<ClNYGG3dVf9B!HFI@)i*IhTfea=^ickbNQ
zv6E0&1P!%!4Ycno?Ys%&((}*!mF!6pv9hwI51Yeu%EEb6!8xDnxM^``b#zD9Ku703
z-T^g<d>#fl&oCRf$@1YGW>qTBt4`G7^JBTLjq>wyk!iH$D9$T_7oX2v$Y&7wVEd+g
z4oBsZQE9Z1BvqwIQngh;DHfaie&qeKsEh+q-uaqUT*Mq*Y#!9(JEA-)Q64m?@zL5+
z#rR_LIf{Hffqd4Q9`{>54W`h%Pz|CNo2#9FhG)_B$nPSwarQG;TG-Ev@-Uw};`lj)
zeccYCqmRn(iMjyg;IklceHPR;aTbqsTFj>GLZf4tbQ|C+>O6~1jE)~2o>QN%zu}M9
z+gOHqWZCWWQ+Dno!!3Bv;E3@n!1p{vGZaenC3X4v`YF@%k8)lt=?d9H@!jCP#fgMj
zkPi1jntYmdE+4~fCZFG#u|bJMK0L2B<mob!oPU(@VUo6xU50Pp>(BWG)K7R%QRf?)
zvnxR3Ja~TC?Z!jT5-VgItKx|>50Bp*#dB?$c`)ABnYSXIbCA=(Iq&azF`j=h?RL;|
zY+0wicMai!AQ{T@7wVd}bQS1*Ug2uyvw*#1$-Dx$c;sh#;XOKp^*qrFAy2D>x5#++
z4C$X4zg1-5oWV8V=^xZV9T^I%nD2&#RL|7yJQA{O)CX7Dt^=Ky{aXCyUmjn`+AX|M
z=rv5e{R+HTF8|HE`1>aj&fmlj%K3)Rgn9FmTz{0`?{oFl`4v#`SC`MrJyX%WPzvsB
zkQ}PNcX{&8qMzoXbHBWArv+yr{J(gA(kfWiZs@s20XA>TxchUr(u!<Vp@g*lxwMh)
zZH!v?PB^h?ob3iaUf<W-@8?UK@Ot%J8dOki{Z=Eh)i;Z=#%HhHS*@1im;l#Ibl!5k
zh@-DoQop^BIc0?GOuvl7{JGd^bGEj%4`J-jiEr@w_1Y=g3G;M)4%lz%vpH)kq<60^
zT8`g{KG~-E4!6pxed8?J5`BcI4W6!oA9=Wt@y^0B>OtR&>@0Q`aiC&%`%q6s&xmNs
z6vHVGJS3wVm+s*j6&$5ycR3W&_;MGniRmAz;QsRb-N(Jiv$KTzb#{fDc{&G5!^Pe0
zeYnG*qic8j9$XbCZ^`qHlM@n(|3F#ySzWN){7wHgnU^Ihil6JzNz97E>w5g&lNiSh
zCA_Hu_C}q+-$!ZqRxU3V3dO`d>PvZdlDy-2b6(C9maiUxm+O|OT>Q;)y*revy=?ay
zg*$MXGGJD$&QK;`gShYp#Tm4_ELuoc?&|HY;1U*GyyNG9v=Q$`m6v(}X}NKxSb4aw
zAD6WZ_LmJ?rx-5w0N?&HE)h{1*-5+;S8!N93k>(P<48{23km)3y<YZV!zjz#$RR}H
z!X+3G`r^G?Bf!i5xTyU6&GLUPlpmK0;_Oeo15)ow;e|4gwXe(MY|0wY^x*mlTwa75
zb?y9<26QZ3xgA%BxD7O*3;gh&atU_}nLgSY<?nn0Ip597@5?!WvewT@RaHL@T7#{!
z4U9&5<8SIM9$Qzc#@bIsxWU?|ysCT<d-R6KCV7<S=<wwH#KiR6j1QQPLjZxGH`JH%
z&I-3e7XM(5^*Bkjb2|=!@Mc-ZLs^?-eB}4E9x=RN;|slGvn1`A>&kk!Cay2H{^Vx(
zKkPUT;aep9|BpMFIY+VzebiK>fAp2@={3x8S5*JT(CQSZgnK`Z`lUWizyF`UUz~b6
z1$w%@N>Alp97o<gpjU=3MomcqXbCpvcZGM0UEws-jl-MV_Vm8)5{ym9y}N~`6UL}v
zyRW<3!;hBup%A`a!liv4-;?JN&OYr`8W_Ct?2~ZMnBP^}FX8T+FgYlD3<e}Ti0v5p
zIh8jER+hv0S?6U-<K-BXaHrgV#Q2JY+jkFGo<kCrvTtD;x69f3`Yy7Q+I158)&#0=
z`iAW`2I?~#T`$hZPC6Xba;_7sf?;bOZVKl$=g)hEfNjQ@hW8}4wH}4sXh(I=ZmuJC
z^jw7YwX=RYwkaPE-yhkI+IaMiRHuuPv5v??`S6<}Z)_|x$C8+b#pHvZfuQ3~o?nqa
zn>J;Shg=QjVaBKS&mUCJFF&CQ?a!WwG|LybPfyP<z+6)HBw(C3ScyNL6_Mw$BzrRH
zQU8(-^8^pF`sW@9j6Mb?Mh=YeKA*7}t`+L~-&2vsKd95XvM`T}goo~j^|KwGg0$B{
zjx%axX~~|BIHse#oMGU8yf-4xtaeYt@KHGfWENMI%nctM!LEN?7dkvXi>;M&IRE${
zwo2hv;A^zsl(*E!hNtyl$Juoo*2z9>eH^>)Vr;Kl46~g#@bv;xR`J`3kI7lvZ!e1V
z|3x`j*UyB0X(RVMAl)82fWs(<=Tw*XTc;hvd&PEDmiw!}U#~3G(X&iPe%1)v5$^@&
z{8Ih4)S5j9Y1X6N@vO0!zHyqR*>jP`^SBOe0vpoguYMb8&7Kc>Z`)2^pLR+10?_(A
zWPO_E>_wpQwn={V=~}XvfbOZkPJ21o);FM*qB8uN?BssRK>K(p^uab1>yC9t{iQy(
zC3^*Ey^d)Yw4cT{(VD#~suS{SR41<i-D@9Eoz(Sb>o%OUUXJG(@4HuJyuWq!e@8~v
z>Fcacy?s&dUZ=JF)spOupm$pDXF0cCub+K$RHy6%d3HuE&z9`1h<nBZs#Ch<2kMk{
zzqHD6f9vhnCkN~1ZO{wbTilM=&e)FX>%2AlW2Eu=*@oY&%ldj>lKlzdW8dw(8}nb9
zy#r}n9_QaUkJjv6pm%><UykPNJ)m))LZ0>MTC(?5(RserzUKp=^Yst%O5+RJpCR7M
zKpUnm8<)8?`->=F@@pjDhd~#YwKi|OD*+ll*VG%|;gy29;bVB9!eq+P@tG+(J|9E4
ziSYw>+Kk8XNMuaGcN;i|_E*S9KGAz6TodGb9e<6u{FZ<?Gu=1I{ceBb>A{3^F~`ez
zv9dj<LAhnThym>c&OPLK_Wq4!>oGX~`1LI4L+7*cdh6jajHxH)$M8(?5zMtU;W>XJ
z%KmZa!3N9qGC08~HhN^@(dd^)`AC1WcWZcns)^qjM(Oo3K7PsWyO(D^agF2?kiT&r
z*}bfjCafuavZ}uSr|M+pq-|s|<KX%l^l|uWPolo-=k}YdXO+_H^Y2bjpVS}g^V5s2
z&-x{jHhlsMbp74>K<lh(>{Yk6Y%KiB`(Ibr{swEwq|4jgXHHO0)EVpPv-h{2PC{o5
z-T_meK8c-DQ^(>?piYm|kSOVMKIdhr)93sX;u`fil#hMRKYRMP&uN%--0L(X68ZWX
z*r)VqmQ)UTt?g=SW5Ln;*ne?(qw;btiGA$9A`UYya;58-93h)w4N%MZc~4iToF^m4
zqmNfE8AmkWRvj0W>5DE~oicr?PMIhJ>+Z{*E-q7bK5>;*$3cdB8kFax`=Uj)jpIMR
zz5gWqOrxi@-=x1ep7h>Vd<}JSyuP3MrVsjhRo(qh=)2MSqPEeg6Zxll1k(1st$xGH
z7}>RthrfxqM!t!1(Z0Xs>0|rGq0q-4sn;bCxw;$Jx|g>>%hhA3kD7~)+U>VpzNmce
zi@t-nYG1_sS+4JTx~g(5Hvh>6<!Ed}CwxY(+x_3rq0i?h)Bo4W={MLURYGrj--lk0
z*Y>D4w!I%z>HjySH_j)>nbUXc+Q&cQIo8h>k+YW#=bZ_hbEtndP}lCRs#`C(PqGGu
zT{6EPqip1*&%4!o%4$+weRbFF=(+{voC7;+5+Iv!XYqR2Z*(We|H%CieBSyg%A6F#
z_74zWli~H+kt6c%I`z90_5ZV|{?{SpV)ZNQS(vxrN6&i4K26g%b<cZ9sC&{ilgRvn
zq+=LQ^)CU9&%1E#i*q2HJ4ny`M#LJ--_~#Ev%{6c7(VhE4DH+_0M*0wxu#VGr1!nE
z&G=2Z(luAP$+S=I4zsmjeII!`s6*eX*EQG{@My#P?ICAdE9O4CC5ZD6?klL)=l!y=
zSZ98>&{8W$13x}HjBDWGe{e)J*N){KKvz(0jI@`gRXo$q^|ajhbDtX5%2_vAo%0V)
zK^@}Vxg!TBhbE7WPlkJW+mIeQ>Ykc8HZn8HxAXm6>*j0);_&`*tsKxj>lrm(SP2^c
z$UDrrwq<K{bv@Vj7kKwM$)&Cef}Na-JiYv<;kVjv^O>vgTiZA9SW$h<iExt%cfaTC
zbkMip?0=jnfXgi7dYHw1iF(HMYS8!x>$z2Op18iQuG=11*ZEljQrZ-<vKCgYLH;b?
z`nr7l^+r9#<7i?7(=$9XWo~>doPlwslvmE!kp1OnA>5YD9Uh<U#4DCu&Cc)PoI|14
z;9LpZIq4U9$bJsm(OQfWrtj>YpOgzc^*$S(32`>~`A5#sNOan`PW^pPtvjB)sO?wV
zc7E1C8~m2PuSUJXUlq=Y^2A*vi_$A~$+YRaqNy%<*9OW`V0+?zGdXo`gm;y4`cHSQ
z?cEvy`ic$wXnt4ud5|sltA*@*gz4vq(|&osV?Mt-JlInj^viy!EbNPn5Lg7~A=$>)
zNtuW3VqCrNnq#yJ1=kwjIe>G}hMYi(m4Ce-r1AND<Vib&d~z=2MF_j>ym#wj#-qO=
zPP&e|_BcF<JBP5XSLDX7%JPj`>ou_0cej;?bL*I04;R6*j1NUV@cuaGLv7(ggs^vZ
zY#L|%GM?eqtT;W7E5@lu_@dTJkp|_CwN_V;UPeEEQ2ITTaf6kSd9#eGO}@(_Sy*oB
z`f|Y_1U~Q!H3d9gx!vARri^^PV88W<DBr5GMq^fNg4Ji+FtjAHGf@qyfcwc%-z>lP
z>#5B)XPb~;eIF(*0$WPhyJ~wF3L$F@;7@zs0v_(Kx8nDP1?O44ezrKCaT~i5{M=5V
zo@_h9ahX`2l%_em3RpaznM3)xw!`n7S4;Lt(7CN}j-PS-W@#RUxCZkodiP|dXApa+
zag$f2zkK5sJ)_31rL2mQwm>~y2cD{@C9BsXmo+jj(%&s>s7w9bw)Vbz?=#yZU6$c)
zrkOdrn+&(+R^8i*d(S3EYhrc(9@AsL_UI_K)6MeQ=+Ut|d><a;R_1X<ynNX)a^SYm
zpD^C<3B74-W(qfX%bhuFpNv~m=Z;XuwWFMC!alf-(w;j6OMO5wq1z<-=HBm4;Qm?b
zcYRhVRoh?Ps@Tc#=1qzIiZyq~x}12MVGJ9oj*gAya#s5)%9+z`3j6xHfx|b{6{1dK
zt=`vHHywlzV;kx*&v)_i9W`IFJJRDK<*Xxi&ECF-a&NBNXH+I;dGSe~cTrIog=L@f
zXvj%_%)RHAqn*;W?#Qxx-H*;u4H%QmPwIUo*MlDCg@wMO2jRBtAjT`R8D(JK-wVt?
z3t5z>7)}(146m$vUZKwB%}<WsK0h{mcx+^P7~9#eiBevs6mnxS?y<+QreoY_$5mQ!
z&U?6Q!lm3Q9y^C3COdc9#=3fJWOtqJZR|&R?petF)d0fO9r5^VLx#)v<JpEc;F}-%
z9^&q!EBH+x?Y?gaVLuBmq{rFKdqR4vqr3Ao`|71Zo;O+=Ir9*C4<gL|XRm$Vgm0Id
zGBDp;fQ5XqFVy9(i9-ooCO@C~F~;|?_^v5KG6%M7740U^CqJvSHeFs0%1V8?j@dtu
z#{v9RpP}yjtK-OnakO#fbr8Q7B?t2IJC{U841)4>`Prn;!Mh7QfAMDUt!r_Mwpu-N
zcNl!q^B8fCIxw8ySjU_f&0Nk@9|51yu{qp-ZD*__j8nHlnEA}$0zn)AC}+BlB8;s7
z7?b0OT#Pq(E;})oZ{2>r_Nn+7@IzyBlJ1cH9v;!2Z+PmU=11K4596A?VbCWuJgc2`
z1x-#{eocoF9v&V&I5C%A^Te}=$0aVk---U@^z2~aR^dZl(oZ}f<>7hZ*X~bfk3LS~
zbI=_Al5rC3jglWhIp~{rns2@izL_>nUriqTJq;TD-L#7So4%%8w?Am?HMLI{HP!cq
zfoJu&@`3TB{Iik#?2p`69wi?6y<-f+pOW5b?lc<rBaFKXe=Fe2?!Y%c?rW(tjx*;3
zZOWd2_;@@!gD}VHK2GI**G~fGV`A15$Gj3R^@B6qBOV?f#>Av)YtEhu8a|KNJ{N7r
zw@pqRn;agQp7wV)MfcnwK7}jI0&e$K9-1FlY%`vn*~iX-_1)krsX#3cq^!ifTN4Of
zET0qPx%26u_p(ug&p_DY$S>B-GZ9yROtHJvhgSmm8sD%OO%z6Etj~MMcOkd$XCcf#
z?g5*N^5MOT&j!wX`OL`=eJ;bK^{_viGc9IFC+BC!#2-;UJ}*8OJp9v=Me@{<ufbfQ
z@2#3Vf-_L-EWTq}FN#4q-QJ!b<?a1NgXee6<KQ@|w|0>`g2Da1aDUGW>hR~9lG@TJ
z9t!lmN8EC82lq`~3;QUTeY^;1ZPyqsES*QboV73`QE4I^+3GW;*vgBMmi4ev6pMLk
z3v)a{+u=JBtn1J6dx5{z#$HxM_i}_0Cw$muId`bCV`MftJ~xie<t|hwv8H?l5XaN|
zd!I4Yeew>k+yAS;+scO%TE~x$>FXHt)BK)G3tEo=B^F;gZ*%tE&R+w*{L9-zA$zTa
zb^eL|mVb;_ec;{fB&^S{j9-9$_@Ql3Ur(mK?oM?(ExJ_wJr%!mzD?O%tN5~Ax}2;V
z{*hkmsgV6)6u%yEFE)O2_zknj{uuGTCi#2#J<C4W-3RL5*ChW0asG++9>%ReT36VW
z7{@@dJfD(#FkWbR9ORX`sQ(x{Fm*&wwwD5gdq=%IqlOV@7{SPm=h(DK-$&alNST|@
zWW7=c_{hGGtj_y9vet`tb|!EccGSY-tZHMCqqqO}L^6B(cm2NC${y?2_n*8kN*DB7
zo6`y9IIgd0P@o7F-FaC)5Xn?smJik`i_h2nS(Gl6CCVf&L<C#C<<Fh0r{ntP$*HK?
zW3EX=Ql<|@vU!=@Ha~1-ifz*|w@qKG_(;SjlrhQn`0{w0<rsl~(#EBaD`X!9Z-(c9
zyKl|o)z`-9)A2<i`xw&Gw{ZT?$Ar=ci=R=S^$EmnfDg*^DP*6Nbn16riQjo#Q}!u@
zeQd<E92>>yIX3!qM8p1lJ*4;X(;R-2<{yAlw$Jbz@`T?D`Tp-X?LQiy)Ni$Bp97xD
zr+NGMnd$k*_oU{KuhYrB&6bXF{Lls%PrtnsW3wk#`3jK98CO0R!f?ZN*V={G9Dx<G
z-}@5s_p$1i@tgJ2U~UtKy(Wt~$pToND6w<q@zp4guUQ_yi8afwgZGKnEdLEO{?T)n
zYZfgN9l7s$I1b#p41XNAZ|31!_|R51;<wv$yZ!bw40qs<X?Ek=({vkM!}ZWqnc8rx
zwQu$J-AK3pVY=n>*!S?8_Kr`OGn|uP{q@lAgTB#vDD9zu{_h8%@sF&BrgARI9&WAs
z+$X0@*BV!HlJKVJtoIX=itWXE;CauBSr`7{ar8jhsfQm$dRT>XBCD%L6!8FMKhb*b
zr(r`_)90e6%%SUD2*1Ad+#g3})H@Lpoj0_}gZI0BqqDq|tZKFC=gqo}V=8Y^b^Ej9
z)Gg&^-Tpi(_sT`p?a9gAVEj<7^b8lvrAn#T-ZMOig(DuQBbzAd#lX7hdwu~~>3h8I
z{cnWVqk-oAOCkFuum*E2^*H0erjDUqjdRv`%Rf6)^S=jUX|9<xA&k?R#`e!2lFdHE
z==NGN+;nkUG0f2uYs1>gf%%!)@u^9Tz}TMj?4MU={m1a|bqJn$Y{br3AihfY3}PHS
zeV7+7lAh&VlMPOf8yo7k74=vUSrCa2)`{wswQ(t>d^+ynJE_zs`){s=^R`d=6+d&b
z1GX23A0%NNEAf42_UEjtHq({Y75Q;Kjl7p3ZYiF9mK$%MOFIX=8uZ0dp8md0SWJK4
z@SgT^iAQQhC8~+DIy=SW@UhdW2-n(8b9Nf(AUF4`dH*KA?<TIgVcIZOfo{&QG;5+X
z@*8Oy*gZ^r2xfodaC@avE_DpyG$}1aod}db*E`NO{yx51i|`zD%|EX%+6%{5=OC_Z
z_PHMMIMoXWmhjf#+}>KUiRnRF<M>>Bzm3=<dA4QyOOv=|W_)fpriCZQI1j<{@Hzin
z@b?eS9IqqxiOQq8WF5r1JRf`+X8yE0J~OVia<FV!HZV7XGSEIa$Fwez1AX)TvX9t~
zUjo~68)1Ib9c7_R{LQiRMaYvjLOh-a<yhRy!qMd=QCXl&YZF@TIq(j&7$-dpwDsrp
zYBrYS8%<yt-!R?iJe_olQhy8=vLYM_))~2iU6~m<Fs4i0^dHoF3*s@;b6{iwRxk&T
zWVZ2e$kLV#%uF4?`Z!(KY!BW()IBNG!78k+&&}MK_%GsE`^IHOW0Pd1k@<T2+Dy+T
zWZsnRy!x{39zT@tb-4ikZDeL_Z-2Q{d^y*_FN19USy$h`os=(US=r9H-<`5uA^f{1
z#wTwRKg)1S)*)fmPXRJKB9a07QS$mwlh4DbpDU0itDWEI9oUES|JpTy1wgIsd=pYo
zrmIb+IrvM=Y>C}dM%pFX?$q%9d`}~>w(Rh@W6YQBbW0>F+UargWj^lncy=m(yWidn
zKJ$>mZMFs0wViUJ9aPXp{TXr{X#Dq$5q?Yb`)2+IZ>D_|dEoc0>6xjzo^Atz;oV*B
zon7U49UjBK%X`OX56Gf&w22_#J8cU>$^t5e58Ghpn(?ez?6(>@g7b^$<FCVCzIiCH
z5<6gATgEK&cCa$rGd?pnKQdukNywY^vmRW1k4W{tlr=b$RTgq8Qyvx4tc~Kvc&H2;
z(rljJd3k&fZUn<iv-`(pES_y@U8dWFu^T2zt}-!xeTa{f=Q3YhXYUIAJ<nC$iSqmB
zQs3W^Dp!rUUd=)6tn0DJ2B=TBfujAU4HR%T)FIG?y%}j9zcw47JbghP^~pYuvXKRa
zPu>N&-2Sg-`Ozk5{|9L|*mqTu__kG_0L~A`JR9n_cbxc%8}d{``rCBUV`bO(02T_$
z$^Rej+E?rvkg*Pq^TJlivYy$9Emm}jGEhD)335@N(r5X++k8qt%aesI<l^9S--5kW
z2X5m9E@J!YTLkMFKQcb&c20a{HaNe3@Xpz}u_Kl7{c5YkS7qJfuui$#J8u)|8O5Yq
zleN$6AIHUJGj|SQ&yh6_<<kop*Jgub6IiFFUeSdX21IVv51!8&=(TAT*GYVSN7iKT
zR(~Vsn&Ef-{e8nz*g-QsH$2D9>BDxed5T%R4VgaOKK3BYd2QMU#|02I+Y4-)>6_~k
zSQR-qK7*dr`~)%BIqtsFJv<DfKN*8pm%9+@zi*7n3;&(Uq6Uy+BA?o`%foMK<7Uci
zV_3?Y%i5GZ2H|HwR$T)McEJvPd~$xQ>kf<)WrzUTbxo*-W^jx*CBohqU&w8%Zw%Hk
z8pw71s5y@>PEBAV!`P^8(%17mVHySMaTsz%tpF#q4)hPo=%0nhqH1pbQ5=*2IenbW
z_jYJ&eD8zbEcfHUm*eCSeA5@~=l257J=bx7wvT)-?g7MO4O7O!9DlOC79is&aQ~q0
za%mnwd*wX1w?#Zb)U=~4%iB?h`OJeNpS6eBOWLm3sE?FgvB3#JPaOa5gzs99f_%ZA
z>pXmZlRoE#a8>-asxa>PNcdfVF!jr^G4<<p!o2)%60);SWbPMQo<jJsb^R!I^yV7g
zQyLs<?<o!p=zwpy)YsiFE#ib!J9n}jthycfxR02@Z_4*p$+!A_tP^sq(s&%?IAU;Y
zj>C-V{mF6E&V1y-3OZqqD8svdBeKdo#v!=knW_DCB~A(cpOL$at&rnK#=7vz{!BeZ
zC-L_~>gxToqsQcF%Y6A9?572NmDDr*1KaPsV2Qe<KRqgVEKhbX?VUdF7~=f1mM1;`
z+Uy-|5WF|Q#@QYz8||IH@3P<iyuo&vWuwP>#*U6nl*ewLAD_Wa04>ux2#NXE{duXd
zRd{kvY!PF(!V@C-@t)0z<c}K)%svjXapbxDrfiYrXPHzN+Hc;8GPpnDIPl5T59nBL
zuCu4uZ}yo!zM;;nR+IPj*pIbj`^#e^6CLx|KjFR|@1PwmkIl``O!@;vu4Am{)aaP$
zIM0JSYCWG`JfV*q!t)D#!4l~IX^_i5YaX!vV;lX=v?=P9WujjF+$rkI_uTQDfBfX*
zmDcPTRwut@^}x7mI4*}r=e`YwpDDV~u=Ab=1?}7U*RD;rX3s*pcur_S`ZU|i0ed(K
z{&7D>c{#4|Ik=4oXKgLn?}Cr#OB-We%$svR{yQ$y^Q!XQS=E;!Tby0gv>M}Jc@`%x
z=E?kh50{h+{GIPoj3{4de7z4}Q^j|kg>MHRY5OhOhkF>0I?|_4Tm16oER3yKZsyNF
z=FNQBkJI8`j(mN*>2dQC*Oa}oN~TL7gU`FMETr=^<P8mHudy^P2eJrq_<3tQSBxJo
zKjnCRRbH4U$GS<~d6{yhIE+gT`it#23?BzR+fqaV?(}D>H-RthmbO9}sXMN>-DN&O
z<vuizmrTQX)o(_cc%MFL+OpC4BS-F>_BsD~;Um|6jSONJmOn3$c2%I&`*Yp`erqzx
zL(Z#axwsDSR^a}Td9tJkjms5}1xqN4+d1omf2<SA7uWM2BCj}I0qNo}>>&wns0wo(
zE2clCD!jWYtZNPV{mnnJc()6-6Y}%$rmFN?C7i#r=ys-dTgcvz^0+P1zFB9~eO~6~
z?1NHfxAokf3(ybkfOp?g2Bu?p4Z<&lUFh=_=BbOgyW{%7%JufVguN?*?I~A=d-?|l
zbu{bGQX1D^E)Nah4arJ-@p{?>c{OXgp}taIi7B~`HZ<5J`}Sl$9QkOvu1>RTiCd!S
zN<BSYyV`sByt!2DhVp(GWs@9bEM;ApK5bFP2;C{qS^whYT9pr0WIb(H7w*4k@9i3{
z>@H&p&t-0^M>kOJ@946<h4tdgLw&egqpP^P3x&6`*Q4t$b##@LPfNXcT$s|?V{A-^
zb?JKB_fcNnEy4Cgz5FHgQm2GneM7zaFxnszS`u5JZ*trCQ|OFyjvP1UBmek;K*tG;
z#~UMIT*)*XyQOKW#z{6NC7rEH`glHLdX8h#^l3lOaRzCyf)tIZvwM%?S+f=Q1^qSR
zPJV1b6;(Zjo^W`m_SIqjl<gEdBkz(KTPq{=*@AJGu9@O;vIvJ?J*KM;_ub3qI=)N#
zF)0`M&{v;OfOtS!XMFmbd9I6nA@7up!w*N;`&5p1=#zZh^GTG=&o`BR8Tz8#`d?1F
zB>NO-8P+k9hTZ3p{%WM<A88n7|NHlrhB!aI#>=qwgKeumYx>nV9Zy3{;WLfz7L3n6
zXM8-YduOq?+~O~^c{HXYy~lgl<0%*88E&u_48F2l85-c!z+Ub2Vg%;J@#hyHkB;kA
z-Y=SbIv>%LeF@>GCU>nJ*zb16aU9oC{f)^OZv&1K4{n>A(z~2VyAoJsd=87L`Mf*&
z^ke&?@EU|~jKXUfF9U%*&3UA$!q$;a7T)-7=d3(yvVB}k+B*29z`ODOYWp0ns@Ok|
zo!L46%NRE?a>&n(;QGPF?AYMpsbhO_l*ZICqb0sMJAj89ePeX9;p<S=t&v_Fr(N#I
z4iC<amL{j?b>5TMHG=ie&k?jXOnj%{(&b1UV-H2)E2t0ubYks!F?Bow<Iy@UtomB0
zZ##$QZp6V3cn*!ze8XsH|J=91wdl8j2iqbycc|adxh;;1m@aNV-$r`=#qH-i7ADS*
zw;zU?p0wYK;^KDi;|U+b^WI<g10ONI>K`$qC1D-kFpljcm!pvV2$-j3`)8c`fu`)o
z5^g@z`>Hj_$ICU3a?XPn|8joK+0T%s!F)Q$3kPwo&)Db~R?fm`IzVWFx<2t=;6WWU
zXvgGp6yxZGivfYhe;W^<KUKd4DqW10=k8yErX>S5&ME#`k-Gq!`W0~hU><kTa+4qB
zPT$Mr8+O)zgK3MLDWYN8il67fvcks{3TJuF^beBv3CsFs%a?Y`=Sj7nd`$Zb#Iug*
z!?;%4iafj?nRcEyu$%_HV?@KYM;@e&X_kY=ZD*bNX|@kOcdtZT{q=6FH{KS`LGpmr
zThppjk<RB~Pb2@kRiC=faCBn4e^Q=-bX@`A%CRZ>h!8H$&oIn;(x^|?`|03=S#r-y
z$7d0M%;jC4)u3bktMIo1>DVUu;a*mjt5F>5v0fbOgE-6J`(YVAi~M0|&i{Khrdcn!
z<^2i6uuojClKbMeZ0g{_*}ICzY)=?zRvLy^HLxb3wncnZHh$nR+$cBXyB{UKM(KOT
z_s`0^pl3iHs6&3Q!S5p0?)V<*nfN^@S?T+u7Pf3+44I(w(050gv$K&dC>wQ=^O7u4
zH@qLJP*@8(|E$eZ&@*`Qo$eFF78dI05e!_9LEoS|zU^uM@0sjHF0kWO=R+R1y$kT$
z>y3Ri;~tE^*e;kKai?SZV)#PR6>_<5Mg3-Ln#D#k)Ft(?4m6_My{c;qt8Np_bemw*
z<6hQR(|Yg;<p6J%yA`^<2)KW8-PS92VU?71f&Ey$d60olU8}~o=&7*k67Xi3&w|!2
z&W36})XSx$0Z;BbW7}+5Xn)@3ChT@NYR_W}?|Q=~3GXTH*yvc_Cdal1>_u1P7|y>z
z8TlNBd!wXnZ$LhfEE=230pZL@CMl~=4ws0XRb_#kl=(7~+2`pvpT>T4HR_)>KtFjo
zXxNtNSEvX5v}RY>Z@(uXqy@o=(=W|7TKWx`)5G2-nag9|kAz=ck1+pE%x77)+4#H>
zV^r!LGc{935A;pVjUU9mKI}^E92ft{ILwBIxc=#}$<B^lG9OT=!f64dZx-A~cUEVH
zjbKri%fjqQ+p#~4^h@f-mG`ux4jJF-{4nG^FjpQsgq>wGcWT<DN!;L_M`mY^x}V2f
zIpl^Ml1?`ql&7X-tVq7gBwowRT{;6J*y?C~#BxhJGRhd$2rihG@~sGQJQi`!_}H;D
z9`o=~zWp=fhsJTPg>aYhoRY+s{iZ1)pj@XW@zgf&A76UrY1U6|Mcobb?<r~r#b0P}
zklXhauphn>H0*<Q9lwxmLzuR^o!<*wv(`Cb+8_UzW(VR<Y&&h)RiNW1wn4Y!#q(K~
zJ<|AG0a=!VpUXmfX1iHDujSdJf=u;%QwbOAjg1_U!KD2*A9WqlQ6JuxcOtylw%l%c
zdRmwN#5%-@T$Z-hN9bAsiZA|y?K$@!d0$b#-zuRA>T?e}#}Klz?y|D_Sd4y*HnLk}
zY065BhmAbCitc)Z>&e+8>6k{JfiE(dQ=iwA^%-3)kGwpL^Rhk^^lAU8{5gIi9miPI
ziPGWrz=%I->c!RXvpPFUViWi_9SwmO?SXpOW52y!(JuA^i_4)h6taCLgO8U<+n65r
zp&EUCxhexH7rsrdTTB+p^%(md%k@}b_2e41d}`xz-PhlL7Bw0D2}$(1YkwrmfjY8`
zHjrh^WVxj7_@N7X6QwfvBjj}`%Ik3Wt@bcpH=m~LR?Elr!+ohTE{CntHsMCI3G#w2
zk5uuTY`}BMcy`p49h<)n4R*Dci@RkGJM1c{gIj&xUX||*!fcC_kMjnzjE8)4M(1lP
zv0cq0uC`wBBmkVB*cR6#%)eUt=IjomuWyTkGx`vYZ<GBllZo;@KK#}?c>=<<c{F8D
zv^=~{e4Iquv^^KHCmSu}NSC+gJdSx^73N+v@257%`)S6{^+7*<JbgUf=;7C74C`b4
z-vaJqc=vJ71Qz=$FCX)0)DG@3{ukt9uLB40Tr`IbH1qp$?iKduavXqhm*ee|I5W`q
z_A(A*FOSpK$q8;thw+!k73XK?rjGPZjdEn<V;k(n@OZ><N6M_N@5FfV@YsRd28wnc
zJ;q?3W?*!GFJ6PkOGlO;#$X39%$lB>nZsad77-i?>evlqFptCLphGj*dmwpX?BzHg
zOU7n)jZKct;G~C9h=k)UDC-3n^I%*c<M(GnX9Gna@)SAZNya<BgZOy7^Bja}Bfrb<
zg?#PZ>;AdGIlid1)t2meh~vlY#oJu{`fSdA&**D;6|&8+QGV*h9pU6OKAsP4k~Yon
zTKeYf#g-4t#Wr!z0?Vkj|N96t4M*~!z2F?Nmqux5zZ;@7FK>|M6_%!!U*2cPxnxaQ
z_A<~m<NKBN{VIIBe9VhHUIQ%1guM_hQ@uFPTh1i|-`5)7*WtUhwRttqbbc6qb4}{u
z_zr7Q(c>J?rFaD5_^h&7o`+Xtn=IUQ2N0QSSdncpY!A*Y8HMR>h0QYU)m8YFhF?>K
zZ!`SbDtx=)9fp@CtuM8FI}PtUG&YIGgy-`WSr@RbJJ^I=ni5`%nK?LefaiDBjXyFy
zAqNqQTktY<gU=1~V>5S_l4wlZ@by9L$Hu!mwX~j9O2&M9!4E4|GN`njtnC<_h@Sd2
z4voDyF*Q3@!A`m<%*0FF0OJnN&voKtB#Y=BnZ&ju%yE)0<0V!5#DvAuX@t1)KvBvq
ze8%Pmd9>tAH+DUDkBm>iMd%#Tx!Dci!;hA^svJ@eN`t0;9KA5#bF)G4;yxMS)q}ir
zC@pan#9^O?#z9hFPh>jE0C%r(gE;zl1pBkFzsloavKrTpT~}fQ=Vmt|4d&<djixb<
zLuq^GW;X-J`kmM=QDTn+w$8B1^mxE7HmqdW2<R>ahSSNp<6ig?!~R;;wdHXT*hWih
zmMOHi0pALI7wQ{hu)JS^yLY*#L9;_?@GeTnopb0ryqwnn7u~_A>zbeCe+)c!f>!4e
zN?mstekbrw;6<F8U71q(p9BnhIfRxY5$3f3tOr<HPhEHHH9k*4{D8+>T``tv??zn3
z<3e3+mbhmiZXe<_f2IFzV7CA}SehNYi56=0_blL#1I{w2qLlvmz(;c)vcHD&c&vxo
zmaTRE0>m9octItW&kGSZfjFJ@zyP7M!#dx*ey0)NHOU#30bccobMkrQlJaK0bBOQm
z8M*7u2)lz=FV15+G9qWuQa3LG?Gq%g*|E7@Ls%Hkc`T3~uL$u#!Cezm`|<wYok#Xh
zVRPa^T$HV{yaeg*2Hns!y=hRc=$3LkQ+eRP^<4I66B~fr6Y*8QJcIGopr^V|!;bma
z<M$NKXy<E*kAh4br(T<FE4%?XKb%8s5o$j5A{7P)K9=T8E%)BBPkIyRI2Ne?yi>Vx
z0RMFRmi-1FrhAK}<J#If<j4LQpL>1%=0XWhjQP8e4C4u7Yy|J1a9_k9h<wn=h`y78
zkzL_!!2Hva)z7=WoP#&^2087w$@xbnr|-#Cxn{-=P&C*RWl`CH&D|+&ni$WE$9{-J
zzPBgx)z6dqSPI8SeY8OzeD5o(d2i9@$heks_0{lA`=?-8tSS4wGp0aMWbgkwSQZ$Q
zk3krIC;nF8JXM}o#*dG+Stic8*3uTTcUw99oYQw9%rVk?@J)KA3%v2$*9aI#zV+f>
ziMi@ip*K2xc{{dad~WafsJtf~@FP>B0fz2r$L~d+UVi$7_aW?dy>5PT7Cpz<=sL_i
zOS@~%-j8_rV)S<U4z8yGrhwFGlaxKnjtn0#-Lf9qvR#D_AiaO^-mcA6F1{XW^a-nW
zeX?Ch9WB(+JKCJrQT_82s$`j&nw=fQT?u16q@IQm0oB%lGBfWFp=_~zF#KWs#p@|9
ze;$|1PkU&Baz27Iw1>aMx7$OY2OitQMuZuspS+ArM?Aze<#8Q&#&es%YtbVUrQ9qW
zFO5p!gSj}4(b~*htP9wM#~H8Qk=ffa$4rF@);n^Ck>YvDY!;YnTkP_qkUhx;I;O4t
z74YNPC*xs@fxoAreQJ?VpTY}w<bt*|o8*E#R%CwzymRaT2XydHZp#NE1IXn3)6-zj
z9|Ns_YV0{qu?QQgv5hL*W?izcsHMwoV$UM{9m^(<wI#gmXy#poRa>~&_un%A$p10?
zDg4p@u|MO-{U7a;KG<c=X$#q>k%k}le}9KC?fviZO?vvjK#$+m_TDIt`PGYi5_}_l
z-9LbTRXH&ZXwE(Z{CGC?S;UuSd1s2-PILB;z-UvdLH1*AC!<x`z3*PuNh@sSb4cT#
zYFnw6i{?^=)znFiZecI3TlypFBDR-YH+g;id6@6%Xdmt$7%olfam+f`qZmD7KUVH>
z{Ibje6*9vQk4zpK%VXt5TeK~vZEirrw#Rs!MIiZMhnMlNV?8W>NfIv$^pdVM!7)wa
zl3BW?HSxGVp>u44;~eJOmc*Bt`SsWbX7fL(OcV1*_;fnMzK>~_Cu#AzC*lKl%YQ``
zjccxbax@ZF`K_#>RULpfSE}WGN)@f;jrR+eo_VUxNBt}6n+du4r#)&17WroG%qQyl
zrw`Dp!MOHrtshryWVEAoEj~w6Sal(OHy*D}94z83;92P~?KcKb<nbl5#rkVR#XZ9q
zf#Z;2?P@)Qv~0URM#NJ`7{BV6@jy6}=quolIYhlT3G1*-Lx0ek9ULE<7!7*}m*a%;
z864&6?}3r#)a>Z&;Sn6fg*s$9j*VAGV^7R|7rqM2KdZCG<)j?c56k@Z@O#N>%Byp>
z_PdE=2K!xzem6(ITcY1fqTj92@1@c2w&?e===bvccVR{TyXlntci~jrCj(!=@_$3h
zI*nK7^&Dhk-xTZso_18X-;(gu(TS<)aHq(>3pPGGDKAPZ-M2NJL8{;HXxeF53Wk?T
z_g%vd@FjAqhyM`l;4$29a?r8w2{y}tne^k7?fZh^?kT;DVUh=75dVSF;&rv0_Fknu
zID&RXn)@V-@$Jkw2D=9&-46vjGKI0L?8QN!R``)%Y5_Qp#x1nQUhAKIWAs}#rxwnz
zv=6m|0%Yogy>q_}?TGtrDC1A?yO2%oztzs{pzaGeIe&8Ms63*&Zm567sYQ90M$Y2F
z-r~Yfg`digzDMP6AW!`^YBsN@_;~=*(}oJGeh&V$`$p~c$0FOWr+u<5t&Z*tVSB}1
zV|iAj>};>Uh|0Uh+iL^aDVw+1U)pb<|K{90=j7E-=s99CS~;73BR@wB^Fg8qo&`o;
zjPpIND-l=!xq0{XT{rqM=khb?a|!snOs)3Y_rx>oYX+2SsmS8{d-3)p=}{-kEFJU4
zb4B5~Yd~xtoB_}vZ=Jj6`DQ*}!L`4Y;N^P?LjKeX{@6e8oAg{aTMDmxs>yJg$q?%b
zDu%8!AM(o6HD#+U-5Hi{1L%BDk+07+`gVCU?4mgn>Aen}o;u5Eu-6YXUZ$9abpDsq
zw`S*np5?e5Wu)HG*yNoCKT8f}m$1j<eH(<`W^^2zhxIHvm(kCcbvqOO7)7m%%0Zc2
z&Rj0^bD-&~JMJIu?dru9R>K|bgQcRpidF8FlUKxVHH_W4Q|#wr@TCp9j9jyR2(Va2
zo+EY%FwQ^FSFx>R8ApQYyTHU-a8KNX9S7uNMW!J?++!8u24<$_Fc}p3?3FUph?Roq
z9YUtT*+g;<yYs-AM3z$hCTZ5ny@Gl^H_r1bTnbtJgL79NfPR|fyeMCX-C(+6yW@Uh
zZM#i!R*=(N9%yi182p6ej|e!<qqX08{p#K(^4)B4_5Cxa$2r8*(N_rV)VkbiX<JdV
z&DqcZ`E85xJw(5EcmBM_@D9Ys>&SfG;Jj_UIPxQY&jR>Z+kPa{`!h;NgY~~_fb#=7
zN#lCB7WjsRJpFYI((knNwY=kJ#n#na1AG){`Q2{c9r$)xnHPC<0t@nCEzsqw7w38V
zT40y)?Z!9v%5p7mJAQNS`YL?$lizux7@G(do$)xObJ<se4s(@y>lMa6oNF!uV;!<@
z=d<fBg#8(n^Ud6^vMjr#u-o!rUGlED>isJ9Z3X>5O(h?VXvl2k(cne<b>B$e&OeU*
z{rB~xL7j_T-K~1uh%zwTi@z1<1A6eyPs1^hK0@VEc-Z9VXC4dmH%+T~7N_T3Eyn=p
zSXXKOOS2m+f695K@p9W7ted7Ot3+v7mV1!Dr`cm^I9CzM347if(lm)a+@5a)P8;*|
zH#JCqv!!=?&Ux3`^FGkho^P@5$Kc!Rfq9X~FtES__U!W2i}SqQo*!p?NAS(D9LJ(;
z8@l)V+^i2c#xuN&Nu3SsleS(4j_x7gT9vvEH-tD2Jq}FZh$q-C?fbF7f{zlcknIN+
z+xT*ntd)DTkq7OV_I>~~{EXsT?Y)uD)B6_Jf;XSD*cU9t-HVS!nY_P1ZaS+0{=^On
z&j~$}P9OXQKP31lClQz#9{Kf|Wef#w$qq^<B)9LHoM<M6!zL$XZR2>GDRWEL5bS&d
z%Gh0JA9~Hkbns?9-wM8L6RS}UnMaBCrgLw3lkF{^03Ft9PjYX0)t*CZ*VNq*Y+w>R
z<Nl!j-YhH)$mjy!){du5X3BqikYDdE^?fWez-gcCU-G<~vsvK$)W+$%>WuR_NAj-E
zr;r^rKJ{hZHK=<V@oh5S0eb40GT#|~>zMT}gzL%kc+120#a#&5_{T9Z|7z2;WKXm-
z?rWW%<)EMAzFq#+rftohY-zpx>l)G)vZoj=`OtsmI*xrzwf^(C`g$AGgQ^Dmp*6M7
zrz0Qg&3!gy=X@^9{|v<Ox0kWDOiQ!hGC6(BN&9F_-<<t+RIb!^YWG~OL*9>t9oObt
z$ewL{T$i+Y>a!m0bE;^`w-N1gk0T%72j<7~q^^8Faaxu__It+XtT10Yy8jT?OUJqg
z`Z-3RFKEgPt2(2u;CT1=9rJb{7;f6r^!+%EyE4UX48j9zt~uU4Gj)V9#(#;&*)hAj
z@p2&ZZFRgdb=%lvd3@CNW-xB4$L-VSb7FX(UGo^ov1N|+jU8i=NQb#PrOWf<iwhFB
z!sD=TMENd(??b;N`|@50UEvJ{Uy<Is)dDb5S*Oox)`L6u9}=I1Z)^WA1`lulFR|ZV
zPcK6F_wiTHHeL#xANmc_k%y;yIl}eZav^(#r3-$*+Opd|?U8@AdA4S+vb5gj+;3E;
zt)G5r_8Lp?<CM$mwvndnbyaldHK2Qg(RsN^*QnfY%6YD$Px7(TTY&rX2<2wnTY<&>
z4|T!k%6f60H~mMWw)uyaxBD7@=C9v}G-rQo^tE-M&+-s6bKg&1vHok*v}Av3{9IP1
zX(a1Ajh1$GK6IhBsr}Kr5m(E<DSMBlahYOYTHh90viDgU@}vCqbnAA)c+#c)NmKU0
zh({V%$UbE2guzz9gMCAFf5)+YZJCy4e_^~`hWd8ZlzrIfT({(3zYi{Ce`&PUGO-<b
zTVg(qWcsVByr`G@HdM&|#%SH<C==_vemR=6|5ZirHd?>_nzK(Bz1KP02h*@W;UDJ}
zSSK90{w-)}PoLuVLhh%S=I?;j>L2Ti#{Zy=KQR*5_wdHB!44<ia$SYK8-0=C+{=wE
z*hfaN2h7(G8CN+X+q`v;x%hPSNx(bjk4#s3i?}tG&kB6U4C07i{|DsV8QwADubnmT
zn0*E`ETg|;_F05k#((5@RT)1AtX>)a2{=DqN3KKaG1p&n_P>qyztrLVuMK#A-gvuR
zI`4eGr;vTo_<pGl-!C`d`<1}g>o@1~wK{yh-hj`)86STakG4!(^Y-b_;Qn2!zqag~
z4S0Ba^0fY4kH^0o53d9FU5)JiJ4Rp2D_`q&UgW_x$NX#Qo3rm3FWL?L-#rVoA@#LC
zKpfK~ehqT~_eN>hcWsE${IEfqA6c4Oe)+iD_q5*!T0Zyxr+xnz-!32XB9ET}qrCE*
zhUb2lsa~At?a%!`Grm8^_x?7W$GQ!_xu^XIzU%L4KR25~96!3(x!(S6-B(FEsN3l3
z?}?rR4d=o7v453Mk(^hU2gdmZEa8vMjS<!PhGW3d9F-rBH)a&ZflTuR#Bpd%KDsYd
z=OKu5e=~7^sfF}U0?z%-n6bu4Q{`O%whow-3%ofL=8U%I@l?cL?D0s&Auo9mztnMV
zTae=-RIaBX?lQ#D!-1u&n=%dYjfR62&#J~bHYzjYw&ronM#^|MaPE1Q{pzNZX9DAX
zXUJJOJU@Ax%XAO$or-I*js97{JAq>^hf^_@uk!yL#9>WK%TE`syWORXzl*pYk1Ng1
z9_gN%sf=s7=OJ#u<5(|@xBMt`#pAg5mwfTQ4t4N+#BrZ9_Vwp6R-Z3G9QQkSW1~hc
zO0J*BAx?UYAg0E>4CzJ@$NJ_7pZUBJ*kNE&uK-m9t)EvTZo=bO*(etcg6Uq1xar!s
zuuq(2WB)3A2j{2x*2HWV-xoMHdp+W~w^`!&a)p)ajlj9L8ChXINDmev{hNU=IDLpw
z8UFxrcY9oWzIXp^z@O>(Zd|)0XJV*rJsWuU#Qf~xSa~MHA0gdyJzXB(ac3mw+d=aJ
z&{(^)cU8{K{sj0-fQPmz@3owpy#x5mfume%Z-&1M_^W}79;)*4ee&-G&FeL-mptV6
ze#E^w=DS&K=L5js=6riGaKKa>*}I<q4DoMAJZvkD6}$U$#Jv-7<*_4EN5?v`hKx!t
zA06?utk?G<z8f3r$EUgJK<nW{z&{xB%>4t;hhiOm1o0p8_`a$BgVNwN?xTqNsK-V4
zUjzS`<E0}xQ{(wD#D5a;Ru6PZq!JtZIO0C-X|?`spZ~epClU8q#C4-W2B+p{4vfJw
z@Lf6XUITCXc#ii5y8HV2D_z*Ej*}NVRkwc+{GXW?${RR1iGvBkKri^A&ojPAjcdE3
z5BxGPsb}|rR#*RwxUc8@grtZgLic0033X0cICe5w_zd4$8pNVyakrH73yAwxo}ThB
z<1oNvdXABhzS7&t<lUv73Qkfqd;copzMH2{2cee#*EN0TQ11W+qU|`UQFZYR;6KRI
z#sgK+1^cQWAzp3CT&?9xU;9(UrM_0*@%R?vet|eq2JFH68aNl>`)$NyK&|nyU4VeL
z_FcrcAYR{b&>oMLOc&<m{twV#NFe8}_$!_IwuBxkMLx9km7pnNn-v`2A<k)gAHuj*
zh>Hu&G~Wll2Dr!$e`>Br=J<btIKD5$^{fBF@2RTyC2qj`62Ab>&#m}w5o+1_*ui<&
zOEALeIPu)L%!~gL={dfyo&$$EPjU_%DUdhER@3AOXUp*u$BYa&txe}3d>qg5Wc+-Y
z(-yL3q~V8r=J1`z<@1+5-u7`WdHLUk_}!R)Th?m){h5#So|bag=8F?(8p>4r?94gI
z`1v%KzmTnH$S0k1PRp(Lp+U4TuI8OhwQ@FPr&X8DWT}20&t+=KPPa5ZX6JK9J>F+j
z(e1_9xgOn_4a=C1(><?vemR$^DO+ni!u(!U9kHJ3*HvrwpeX;1po{rdV3YiK{{Bo;
zO?Q4({>+PeN&Fd%_EkS^YxdwM|Fj<SIV`tdJ|oBWM>}L*$Ftw{#^2i#<!WSa7avEK
zc<w5dGoMGPt>654&-0hMsB1HY>|qV_FJ%7ibj*ix)aF^pE~_eYtp8N@LUx7Gdi$n)
zq-mU{CEI9e;%8o_c@p}^T6vnY%~kaDL!@_`NM&lywi><fNn@Rh-lFf?e3oR}EL}X;
zR-Mknwdt2;JF4Uq9ax^V^v&7TRrKV|b1EB^>zYt5Jp&?dYk6C*%_l!k#`}$U&R{2a
zG7aYp0zb?dv|C<iyVBSA+;<UpJb%#HAbppmujL)fs{3F%K+E}qZu{PaZ<p2Q4@$s-
zd>AaaeB@sp=Xv}5!K01u_4xjyr8<A`EBGdk$N13QX#SvpIDTaO5MD30cfM`hOByss
zAOFO!m^-12lUhL620Dy;bTDdTFXAf|*CCHRb1nf6GtZw>EWf3|*C@_)`tY2-3^@Lg
zK7UNNG|Lfj9^!OBtFK~ne6$kyI>+S&ZG8qf1^C5|yHqAG<1Y0$l|agOD)7sIb0~ha
zI5E!qN|?tg;Pm%+A0@$81K;X=x_M(4-wudGxBS+CZimy!6NSon7Vv8v=RnTr&j!8|
zcs%#O@^?CIu|r<i@bd3=Tu|kG4(NLv=L_V<`&{4yz!M$YIG1u(JWVvOKppRM9P5>m
zO(g3rAufF`XS&CE9G-XMbhMdK#Nh~$iID?ii5;AWxWkBpzVj_Cmfr=4n{b{?rH2no
z{jEdXw8t?s+CwxybRpvDXHoX#x%ndCcPK7$__OjufIq?ck(WJZ6JKzg`9%2Lj+>rh
zUeEM6(}l-f0)Ed%T#(D2<*1|Q0xwPC%w*dR#5#W{@E15QkyxK|E(QJ)$Me_j^oR*-
zlcafhEe&4X=Y)zr50U28PE(qkfR?R-)V4Mt{`H8*Rk4$^6L{^LI>4)2l#OZM>}mN*
z7akJ1YVFTCjDMTQ%adho{M$XgcWma+*l7Fg?AVe06L;!C&}IkZ^G>J3?F6wOq5ZrU
zab`arD>g#=`Cyt(Ey(yj9PuAQykxCjPSRZt{G-52vjk<bF3g8M0&yR6o>3a&pLD#`
z8T{NP;GcH9xCa+~PtA-*b9`G6|5=Y8*q>6EoL7S8pPi;Mj?_b)74wzM_wycC#2zg8
zKb))>^52g5FC#wj0cLYoA@1unac~fp?;{caEsK}K0A|(p=(D~HT%XPL85yS>hCCmI
z_#Yr%{5RSLE6juz{WATJ5Z^a8Hp*K`NAQZ)k!jdfen=3H1`t}-(N96!HCeRN2^!PV
zPJZF}nk`2rDg3SlO@_Xk_QG4i=*7Lf*CCG2{?HXQsg*C6Aj?@vv)B(R&*Hm5hbLQk
z7Vp9D>Sys1p2d5a4?cXBZV_rei|g~Stb4U^Z$HM0Si|-8Du$nk@X^zCKUz~Zh>JRU
z2THijoa=xEg!KwR+@Y~)TR7*kS?Kz3<~eTgi*VdMHVjJ<i0PLgJgCQ*3BOi^yZSoi
z_fp1PUmBn;NZW=mjInF5tGuTRwnl6ju>Oum%k3S5c5c*i<<VZ=rR$L^n6AI0zsEB+
zez+5KxVOFUM#vxJIR#j`t1?vX)3m1wuS)sG%I?yj<(V}N4tETcyLvWl6FHj@?%_4b
z7A_#XD+)IwJTTOOSe3bj^teZ)X!J`+AB9^HuIwJ_yWZlLBHV#1Q#{;;@ZM5oH=<Ps
z2=}yi1bLPtT<qG{i;ICMqR^}Wwx_$oTj&9)94mpL>{<}hNmj73;oTut8+F_SOv)Ew
z1z=Lf2x|t0avEY~Wm=XkqFchWRah%9DKqH29+v`>az|JjFqT~*vjJdI{)lclFxSBr
z_!gF91u)YAC|Nqw18~)Y!KRB-$XBm~N$5`nzN-#?8t}oMQs4E+kojfJR`%Y~z+jYL
z6L2Yi6`r*~e^6Dqt2^kR2^dW&#tOjNdrG_dO#WtsMaM?Oyjy_vclD|qtDxJ`rfo2G
zxhqEM6j*4tP&lyyuwuWpS;LxvvDtW?v<Qv0C8Jpa%-fOEwE~ki64l94U~WfF*9Oe(
z$gyR>)Q*5yT`Xr>vl*vb!L(J_N?@UmO+Tjq3-yb{EbFP{7wRz2=QQ%HgRdez^O8Et
z=}#wp9eg$L?lSHaVw}lw1~BuTV&s%#4KUMPz|I6Fd6n9?ZKdW-2WJ77ysGfCNzWUV
z27CIYri^|q@PT#+QH7rayq!w{`l^t$jR%o81fjUhlCqskzE#+Hz{~@8ZnAQnA7NY{
zVcH8KY>QzJj<BtUtpmn9Xycymg}^9FjI9R-NK^`k73}dM#bZ;J{4ZAAOD@<$6ayP^
z`6#8zdP(46oK1fZP3UvKbgAN4d_aRU9uEUH#9nA{puN~d@sxLVI($M!TAs+zgs}Bj
z+U5{8zbD~lgw5wkxCLSLck08IAZ)%);#(2+!n>U;1?KJ8u{K~Fp|Nh3NxZgUk6#YV
z6eBb%5VrO!;gtwm+m-Ms2wS_A@Tmw(o3(PEMtT~P`NCDCkHV)T>}}FzSj{xv_KeRN
zOjm`iAsu<KEgIdKq^rWt0_N?_^Eexrl~dNwsE@VIkL}9%o#Xr>>_MdSc4l<MXk^a+
zT!cfLGn(_54w=%Po$h>KZsU$!01RYq<D%CGD;BDl@~%@%vSs)}4SV&8ovjb)VACeY
zMG2kuQ5OTt?N)8<A;73gS~vM$g0S^L5`HMcqJI)tTe%ci?o*<60ld<GeOF&Zy8)Q{
z8c+Xl@<a)kuVa@nE!@{YKRQ*rbM10qAPeSA`K|!gUa6GT;pXLigyTVb+9o$fIH}2F
zlVh$$E7xY=gIxnfUb0BKEePxFb(=SCyi)bG6<B8%s;zHV*Ra5v&y^9rStF!wwh7N-
zrPSXiJhvlU?C<X0Rqh`eu)5j-tZUyuf7!;gSCIxcKH^UCE;;Jg<hvTU7)-Ih|N4^3
z_()*5WW3m3?!+>$%5n|U>$rW3>-SN>y88BryK(GVU{XFycO7|I*_>u)gbfc4b##}y
zdOV-@IIc?X9dVopJ<wn3!{RMGf!k;?rg7f6hZFsE#x&J@hP#J)&^;9Uajcr@s4J#-
znW8+q5pTX~7{`Q39=m{<zY5rHr;{;&-r+`@C^>Bv{%EI{{yL|>-s!9G9^f5ArJhcy
zV6C@aV5L6VKWkoP>q{_sToRf4fwTQU;P4DJ0L<%ecsE7}R<Abz7yqrGq%Q*#A0J_Z
zz_7yJg$KDxsi^r^NGCTqb`BJW#cBt4V}$B9FvNHYg0UYc#K!leSkUQS;6XmJ8$dg*
zwD0n|+sAmoI1P?4+Wvs>yAgPMxpxqKV{x}U)~IYZ0cShu>KYWfn>}3C@GS@r^zZ7A
zeeq*}<vLcs_*h`OyV?ijl2uW?*2ge#JXj5L=Yjjj#{t9d;a=Qr$w>m*#0W6_rnsWp
z{Rrp!MyF`Dc>s8>^Bf<oqK7jOzGGGNjvoXrO#$}pybl43<O+En2Cn6Wl1z?qV7vP(
z1KfzwJ=7O`@HB8A$Cvs#OJ%d4+l4ou9Z|^|A?2I_ZtVsVtIlSDnLPw-E~cY3m>lyl
zZG;~Mt~RLNi8?+8EZ9!mu1z4)+yNSwzpJlU>9zW}6F8En{1!p_yCQli7Fv>|GWi}K
zr%MR5tWQ9E``}=Iv801*@_eGCDbi$Mzgmx^D|ac@)1Hs<pSU{52ikFFA@)cAlkJbb
z0rNL(2fWC0*iQM$!#icK^!u0i-70t|vDn=+ykjG-uu<8X_@1I+J_jIYohY_>hs_n>
z?PRCh;+UK%qI6pwTjF#BUAXfUmy4Q?aMOgQH@t+id#Q(N94<m^dT9-PN$^#UN8`K%
zD{tMnaij7+J*KsJlhrY1<Ipo=45K~DwI;?))-w}K<vA<GWW9vx&ra|?!gFnm?NJ%m
z1#H_63eL0_#@Hss*2map#V(4mEs9+nV_Oy5=vaHt!0vX<H^qiGZ`z20TU~8R=n=Om
zkK0@)uH9^DOLg4lJl)pnxGj0yPLCTHC~n)hNp#SjU|R(1NHDFZVvLzyIwP#x+IClj
zby%M{;Mm~qF#fqA!hAll9ATY<10u^{js?9{a;&$jvlPblk8>QIlRx*4M3_Hc?2j=U
z;~j`Fp8rkz7>zNb8;dY+#|I;9cwcY3&p8~5@x8sh?voEk_;$-{+OhuLKAsKD{1+UH
zo`Vu>SnKd9G2O8Cq0e=!*cHZNuXe1xcZ=)i?T+<s+3fwxha9VvOSl+1r2n+z`*NEK
zSbJ|LP?7t~PS@2D`m!H5h6nCm%;mFuKXMH9)o1$safCU)pE$Pr#*Q+^SNnEs<M;#7
zs;8fNynxskZ0+l339i0BYcl`XxutW{reTboI<bNAKAi2l^vq84^@H&Bq#78Kp@zHr
z1cJxEck`(}FW-X!NPlMugK?dRSGfuqa35wz^YG2Y+sozl8)afrbkRbrh~7viD+OCZ
zY_L)uDq>E&E2qWj58Zfh#3M|OEhQ$MQ$DxaMvP;@uFfR=GUB})Y49;9=dqmlo(go5
zkKb1ilL`EdLdbes88EfKQyA{Z3q+bziOFP%*7a!&_u=ut>TH#S`|;%1-skmoI<d}D
zZ_Y{exSBX77BN8DEkaoRo<SV*Kzz1}@ioM;kYQ2cN6sXMN!gh0EMgoP$f8D>6Gx)=
ztN@&gA404$G!et9Mo$SdN>N=Fh+`mxD1lk_W@03?vbHcR4{9N`)~}{5m-gV^^@wLH
z@s3hOl0-5rCEnXr+1=k67%{&#;Zy3xgZWU*XIYN-XoQw!x#4@-%L)C898c(1631W`
z;~mju)<XGmW2FpD#P&p>)lq?XDUMJXnu*h1yUOjAXwI&Mcz3yk>gz5>wz)+3^mTUa
zlM;&lT8ZJ5p$=<xlw&Ee!AgW`er-xi-3bHIE+dAAyNZks^LDeG_#SB=?H!T+R}fd(
ziak*~T}iyZuS=^Ym+zFo2NMhtpKKNA!=ixM7cuuCW;X?5=0CiRG!xSXlG_(Ct&V^#
zA(s1&fVUD?-x08-#Kd<1vU+PH7JP@ci)F-u-%xBhG4&5(8!H%AUm)R?42L$I^FM{S
zwQ0}uRASzqLCQKhjTjeGOs-W7V*#d}k0hq2(~V}cg|pS5k;O~XEyLD!olk+7wOcR}
zduk>Y+NokKN+)g9(=H+A?bGsXC6>2Mk$tJ8)pqG=+j6XD$kHw|jP23smgiWY%hoVo
zsc7Nf#IQ9jPgfx3?alZ%6U*CF&|8bpvQ24OmoRKC$92+5EVL(}Ru4;+R@#%(wh;^M
zDW_dV+}o4Mw47LIOPc=*VtG3P1FgT6AwAlWVW$xDyx<gEhEs`a8KgDc$QYCPG>L2P
zYu^Qb3z+tmoe6qdBw)CS;k-`}ngX%ltISr2Njo$<VOXn1eLKUU{V7c=F==}mUdk}}
zTAA7y_O@c!GGgA5Svi&ylQy7yR!BPOgGAny42Swwnp23WUWDdUhP_@buhW!<bt*Kg
z7<L^S&FREK9VzeCF`dnooT0qvo3$P+{Tjiw4!mB@B$n$u%$1x)96BsvDmB*i*~Fvy
zw6((1$6pY@^mGn!ndI!ox{%8HAYvUk$T~ll*d9y>^p~aF=Lx@dWUOPx^Ceyv@SV3{
z=%o6)d%D`YIR+_*d6WxCFMW#4E{Ht{y<nV$Fu!yb=-ACfb1em8;$sOaT{E$Ka#HxU
z5W^fT)T2WUEAtY;A$s2~G7#EUVzQ82E`k`-`O0^x<EWwG!8ERoabnN<Jh9C9>R42<
z<&vJ`Pz|qOIH*>!m4bC*D44fHrRxmyF@=R}0V!oL;Pae@6*0Fdby8SpBF*4#&dOU^
z3kwBeLken{3JcA|diwk9&f0|*p%EaYTSBbd)s6`?(?wyS)v@qgQCL{&SeVBtEVMbc
zY4Z-%Z((5>u^WckJNMEIXj6rS<-~>p81i1>>9_6(d9NhKVQf#=zI-0Cuy9I*L#)8#
z)Ch-Y0Y5FmDW2<O6>)SgY)nv0pg)^<f3YHBi>(wE))E_XP|I=-vCgg{#^ya<<_8Ie
z!JC!$TuE2y-eH+|-scgguEXA!A7nr<!RB*g_gdK3wC}U9*Ub+t?9Z$}vamn@{ilWf
zx&6l$_UH4TSlFMne`;aZ&(AD;mFer}7RHp2=;XgVyh+2q@UZP|`EL(z(fD6_*q(=f
z<zcK@aZV9?7v;=_Av|Z&d+6B9CKV%q&zL+DbsGD|*5eO*(GYH0UBGX?L%@CZ`Cc*H
zNeX`4cYY(k7qaZ*I7cEskL`fG8_Vz<d1VKCN5&`RB4gj1%Q(J|)RxWO#r<p^UWqVn
z77yW72>0*5Rl?lwzb2bGG<#QNW_%3qM&s;7+85LAg&b=^>-QjyN=6!Y6XMQmnm#z`
zks=8<><W>jr!4E5X79oc(s);mXVhhdn~}~x7dO?pZ&OcSt-YTU%6z}=qkCZikMc5K
zF??fh?^R(h#fz$Nx4#!x;cka7N$^b@VbEePzh8};-Mq9KH~V>6HEwqF@)Y0X{9jRx
z8~;~U<HrA0)wuD0b&79x{;#RVjsI(_apV8GYTWq0KE<~<|2I_Q#{Z4gxbc5eHE#Uh
zoZ?%Z|68hY<Nwxb-1z@NHE#Uhmf}}B|39q8jsG82<HrAwt8wH1_8jl%19SS?KS?m1
zU-{Dn(|+|G38wS5?@X{__pTwe$9E+-S8|5J+S9x9xP867aM9K`yeGxCJO17j-{JWC
zQv52%-=E-^I5z$tNbyaMe=x<vSn$tMJj^5id5VWV@-I^SO6UKf6c6S7aEgcWek8?1
zdH*uSLwP@%;8-lM^8Qtdhw}b)j>8w_`v0305Au90#e+QmE5(C6A5ZXH|DQ<lAkQaL
zJm~*#Q#|PZQz;(w|92@K^#AD;5BmT66c6S7hZGOx{Y;97@_shKbN&Bgiih%kF2`@`
z?bSB;PYI@N@ShV*+u;9BFl~eXl3==a@~;VYrL^<UCz$SK{z8In7rHMd*bc$Ilwem0
z_T>b_$i?jLD=8kz{nZo?_58II5B2=@6c6?MZz&$?`5P%7>iL@~9_sm9DIV(i-%~u)
z^S2W`x9jhucqs38Q#_RSKT<rD_j@TG%KQBk59R$qiih&vo8qCo_oa9!?+;Tvl=nvo
zp4;_*rg$jtk8}KbA7}q0!hEd#(+KnN&d(yu$2vccFdujSSA_Z4`xg=B<M02DFdu{e
zGRN5NcDud)D#14eJZlbPHqdVlcvFIJ33wsFw+6g9!LJN>OM-6;_>u(Q9`M!#-x2Vo
z34T?;+Y)>e3armZ%TgQ#R(yGiqri%<NO2Tc@s%l#0xNz>ile}apPJ*+@B6yUX(_(l
z@l`3l!|~Ho{3^#+C-~-#j-Qd@n;c)0;+q{mGsU+!epZTab^PoUztZuwDZb6|b5cB%
z_dzKh%6o2#hw`46;9Ej@&rk7C-U|{O?+4hk!-G?NyW{Ipe23!~rubEkuTSvJ8y&wW
z#Wy*Aaf)wt{2?j6#qmp0e5>ORP4O!ozcj@|c^{VIp}ZSXJe2q0DIUsuS%Pl~<-I(`
zLwT=A@J(p&+AbcE;%M-SZ%lDCc*QrRI2yd-n-hF<XzyE6Jhb<%DIVJUl_?(D`?eGh
z?R|TShxWcB#Y1_oO7T$Mt5ZCb_mL?c%6m<MZwcjnREmf4UYp}x9QV53u1oPC&(0JN
z^0cRTkf$TTbNv@nJjm0T;z9piDIWCSo#H|NyHY&pe|L(9@|IFOl=smo9?E-tiih&{
zBzUg>-V_hz?aT2&Y_*Yji~by|_*i%#!E`KqLxSm8xSU`*79LD69Sc_yOvl1Q38rJ=
zJqflw`|;0puf@iBjstpnuzzs4tE_Xwn<A{zrF%d($5;ug%+@ZqL^xJV!raf+D%{6H
zS61OZ9@-Y+dt~#c>Tr96@5XBfcvVw$yCcH&9R<a&ig4LoIjH#65njPWKIaA=8DZEv
zF4#2@R_yKU@%PeX2Md+dhs7EzdlPrH5W^&{%<Fo%sA1WA$oNhT%f3T~J2WhN4ki6=
zNiTZ}8OHfx<R^OxCB25_ZU#xO;boqm?ZaH|;i9gytnhHBhF5yHL&K+d*!G5<>fsLE
zD|VWPapM5xS>@qQ4a+`7%F~s<izoXO1%nXw%q0611%n`l$v#EFAdF$MPf;)kWSHzz
zRJwr49z~@K`xa%7qF@lt(w^h;+WzSWdAK+z<vG{GgBm{1!<`yF-^1M+zQDt~H2h!>
z<F#JuXPt+;d)h%Fc6y;>UHQAevL{kxRYIn{)afc+*w(9k-os*SxANQI*bPHC{!X!n
zJ2p`4EZbbzWie*+=9kBqz3*{FjM<*qN5t56&11l^VmUku%br7)qgW2lNwViqvG7bN
zdkz%~&x5k(P_ghVc$4SRndfnHj)gpK$+3{fV{$Cy@z@*-c?{=Rc-DMej)mt;+2=_4
zI?Lf1bJFQ{bynQ}O+}cGfu|iS<#e}4nA6QT)|1oCI))r*7jqsS80;GA><>DaPw}9K
zqbVMAaV*7yKJG~Ipp!dOJm}@F6c4(2e2RzX?<b^qc>Z2+e6SMiN%mb*=Yy3{&Zp*d
zp^Q(<u~5Fdb1anY={Xk4^^6<~W%{ig3*~vHW5r6@>+822<CL$p(R&<=-t%~tW8DL2
z^xBr6on!Dmiv3QGb@m(foCtHe-*v1sh>bg%_PLIA574uSuX$dCfuUf}cZ>rN^NYWi
zV?oa^$g!a37v@;d^NVsU==sGt7WDj*91D8>{TvH=eyL-4YW8`RmqnP*tGqnId@S*b
z2=j5oD<jP3RbCZgKCklX2=jTB*F>1ltGqVCHrg}g>tf8-DqbIBwodVe7&E{8#t8HE
z&^N`H@q2TO8Nav0nDKjSgkjcB>iiF4%=o=6#*E(|#+dQ@qX@&SnDG1K7&Crvk1^x-
zCoyLH{xrg{tzY=PBgTy1J7diFy(`9y-@7C1O5^vQ7&CtFjWOf*z8Eup?~kx;#_t0$
zX8b-FW5(~#V$Ascd4z2@et!{T#_vNhX8b-JW5(|z5r#<+(cfQ27$!gj`)Gt=vPZDL
ziZD#{2=><zhDjd5{wBgO!6VqmA`Fu|g8i=u!^DnYACE9Rqzd+l2*U%CV4sXIJPZo<
zw-JU1LBT#1VR#4>?C&BB4}gMwI>PYqC)nRd7#{ot`;23~`-+2Q#Xjp;SLZ$sUD?lm
zK49=eR<<uhnCtnA5$1aSQiQplzZ_w%=dVPV>-nn@=6e2Ggt?x-9$~KMe~U2J^EV>Q
z_595Ub3K16!d%b)9$~KMZ%3Hx`8yHjdj76sP@ntp|A;X6<KN3MxIgX7z8_&u_k$dR
zTT{AwBh2aU%Q3hsrTbxoIo*$P3~os2{xiay?#DR>_o8$^i7==8X^z2dDBaH@%;|of
zV{ivb_g@j_biZ&6tCmjp-x20?zl<>N2Y(e|-Ve%q85~Q2pZ9}Jd{@IT?*|JJ=KWxE
zgn2*M5@BwCOCrqeuQkHl{+33V+h1FRx&1ARFt@+u5$5){BEsDMRz}#ylCC?Rl3+U5
za%zI<T+3+*wnhBGstDU;{7z3W<+nP)l;0T%ru^1K*k<E*W`Zfdvl2}Cot<FHZ*7Ea
zF@EPHnDTp2f+@dq6HNJ?7hzkC-}woq{4Pi^<@ewOQ-13r>`LQzVS*{Y^$Di@E=n-v
zcX5PmGky<AFy(hif+@d;CYbWOG{UwUzlSB5^4pML%J1O`ru;68u#Menf0rki^1C9z
zl;0x~O!;k0FrDk$lwdm7w>iOdu5U|%>ALsU2-{@xU727i-?ju(`L-vR%C{rIRKBYc
zOy#>e!BoCSCYZ{1O@wVW`5u*ED&MsUrt)2vU@G6v1XKCi6HMjnNHCSJm|!YjXM}Ar
z`MMHJ<?Bu`m2X#qseHQ=Oyw&jn9BF)1XKC0PcW6QC&IRxe7y;#^7SQ{%GaM@D&IhY
zseCsin95g9FqLmG!BoCVgk5R!4JDY$w<p0=zP$;i^6g77mG8y`Q~7R6FqQA-1XKBL
ziLh-Z-(wO?<$G*`seHo;rt&>5!BoDH1XKC;Cz#52Ai-3=(Foga@{J{!%6BlqRK7zA
zrt%$5FqLmS!BoCm6HMj1Ex}a2i3sDyO^&ILB$&!KnP4j4RD!8|(-Fpvn&fwTf+@e5
z1XF&q38wt!B8(d|$!|Wvl;6<=Q+~%1O!?grVcdvGes?CA^1Ca+l;7hMO!++_!npC0
z{GOO#%I`@Dru?3qV9IYH!no0r{GO6v%I~QOru?3kV9M|A2-{}-o}OUJ?->cE{C+FJ
zl;1NWY`gLM?F3VP_avC|dsc!ezh^rpJ3n=t{W}rn<LBo@n2(=-H^O}U{M-nWou4*$
z_PhwUouBfY`FzJ^*PG`5dlBaOzaYXq{})D>=l`Mz^YQzOBh1I|FNrW8zyE%O`S|^%
z5$5CfmqnP5-(MbKK7M~ig!%aWl@aFS_g6)jkKbP%VLpC;O@#UQ{k4u^cNJ~*bs?;F
z@cIx|8+bzqYyH15gw>b5DTLLJy*Y%{hrK0))qlO!!(6?!y3XXeYTJ%sv(KgwR+$PR
ztTHu+u*%dD!Yb2}5LTI5Ls(^68p0}5n}^#~C(A-u^Ismqn*WLr*8Eq7u;zbC2y6bQ
zhOp*;S_o_Yt2|sRmR%>OJBG;=*3)Va59NA0!?E5RTjSVZcQ{YrOvmtQvhzR7v0^(i
z)pm5YV|zM+9BUmbw&RT^r8~#5Ql9UF9J8~V&hv2hK;VCVj-gb_>w+9BAp>dS>vAm2
zrC*q1VJ>}rj)l4Oi*hW?rC*$5VJ`h4ITq&9FUhemm;TTk3v=lYbF8;_Xt2C7%!h19
za4pNj9UCeKd%w)F&I%S~R1cR&nES9R94qB?kBBg*+v3;&)M{;NYrr@ir+HlI*d8pT
z8{Ia?in)B-9UIKC9gcP8*j0{I^t`UCJ&cn?XtR&>@L)06-8GKkz%7^IQI4^gCfBt&
z7V3MaV;%WBSnUz!`sj$T%~tkegt_nUj4=28T@mKKzdOR*_wR}@_x-zbtmySxiZGY&
z(GlkIT_0gCUr&U&e7zCo^7TcS%hw-aE}!_>-mTbLfypV;i}*HRxMt&~E<0OE{F`E7
z{Y`wFVtc%7;^z$WvWc&=v`#1f&M>DFpJ$lsKzyEIt^@IViiNf!e$O!HCw|W`=O=#8
zFy|+J&oI}i_&vj1r{ebvbDfIcGt6}=eowJMFYme3y<sk&_(Q{7KJkZ!xqRXe4RiS(
z9PxAc#77#P%O^h4Fqcn!q+%6+Z%}-sVgBx*_(;XBhoZ#~i;r~7)>FhsDz<CDY)E{h
zV(1Xm*IXLO?D>k{RJyXC2_-&Lu^wNW6`!ftZa-6Kv+=`~CE{De=YeKmR>R^~5bmCs
z!&95eAb!O#uLtofhIu_)=e&{D>p^^t(Rn?HuQAN)L41v2UJv4H4D)&rUt^f-Lwt>4
zUJv4H4BKS&Ail;is|WElj@i1F_!`G-T}yn8W41p<e2rtaKSg|vW41p<e2rtaKSg|v
zWA+}g_!`HqQrj7bbn5G+H^i8gqa0&aj=>nSa#Ui>$}tpUR*pR}X64u$V^)rRF=pks
zF~+PMH$|AQ)7~6oR*qXD3??b<NBpgvsb((M`Zn>oimSOAE`B%1L%%1!H^;+RNBnP&
zhw+a1;2aNQ9`VCD9>zW5i*r1TeZ(K<co_ePPtNhM2SxmHj)y%c;+u0EX07d0{BwkR
z8x<cN;oeTgPe-`7Rq@pk?(J3lb%cAH6`vj9-fqQjN4U3L@!b*b?N|JFgnJtnAD-i3
zT}}LWgnN0#mq)mlSNwT|dwIpDN4S?){Cb3YdBwL!xR+P_dxU#=#m7gumsk9JgnN0#
z*XMW`4~xH#a4)a;e8n;Bz;MFsU;KW+^ReJ%Y+E@V+QsE59@@nfDIVIzBT_uHi;XEB
z+Qp_65A8zwqFkQPE~HNiIEDjOE*XpGc#vPl<2fGWmoa&c2l-`Op5sA&8Jp*LkYC2<
z0mn&)CXbBM1CEDY!)3gl<3Ud8TXQ_fDgA4X2RWsW&G8_o^s_l0<dnWP;25TuJksCh
zc<?9E=jM3uC(`dmxZ9iby#dG2!}v@88}P~|Z+FrM2OL9SqnCa-;28cGE`4#p^Jik|
zj{|-ahu6|CNS~~D_w)fBzet~K7=}1PCw;PF9OeineX`MExB^&xsr1W=4^ADN3w)bs
z!#FpS2kg4vEku~>s5!!14=oYqzGq2<x!-AxF!wo2Bh39xTZFl<Sr%dLXQY2Lncc@o
z-)NYRi=<z4%=%&J6CJbhg!G4w*?2<wLdR@8A^o6ZHlC0^&@mfNNdM=UjVGk<bIisQ
z((gHD;|b~W4D)f3^mmR~Ii#<1%*rACoMToF>Ej%;a!CK?n3Y5NHpi?S(yuvY<&Zwj
zF)N4kXO3Apq%Skf$3@bQIcDXMK8zS<fjB21eV2xV-;sVxvEXy0&r&S-8|kkU3%*AB
zD#e1Ik$y_C;A5nZQY`p!>7Nt}K3w`HV%>Rrk$%ZAZ!gj(8RqRp`Xj@<y+~hVn70?{
zhYa)fB7Kly-d?2tG0fYG^gV`ody#&}FmEr?=NRVgMfw}ZtbU}gam?&Y`WeT}&ZLiV
z%<N417st%bq;GM|>`eL<$IQ;8PjSrbO!^bY%+91QG0fYG^dpX0IiwG9%*rAChhtU_
z={p>=a!9}7n3Y5N49Bb-(qA}c<&eI@F)N4k6OLIqq>nJn+l%xMj#)XRZ%}LyO-6ja
z^bN#%^Z7mL8;D^7()%Il8x#xeNcsiELOberpF4=R7_1K)$g$9lZpg9Fj><U}+R<Q+
zg?3cQvCy9n<yh#;_vBdU$M;5<x3_%}=I!mq2=n%KQ-pbYyE($Vy&Z7O=Br0N+<Sxg
zsWA`l!z);(qr;AsE5#w}cgG{l_peVl)}ub}h=;Mq-FZz045w$|9t6jya(u|o7C!1&
z=U@pIAU1I<V3;*G`R)o>ewOeP9UJV#%Og5gcv8U1VNCGk2y;4F%N5%hDDSel2wBT@
z%xqTHavig_Cu_NmS=(F7wI5>bxgE<oE3vM;91nK7fjyyYb9}#^bRF%LjYFz~`53dk
zq(>uclhGZEF{8U9!ZsV-oiS!~cSYD1qkDXe8Ql{c>r?^R*F7=8^j)+k#TW!6-IEhc
z=@w!P0+Q}238r*UjWGyFx~C<W(yeJR{SEYnIzKbQyw1;xFmGpPN0_&>wGrm+?3@Vm
zcJ`nM^M38z2=jjJya@At?feMye(iz?^M38YF=jToF2>9zFN`s>$@MX2{lP^scBR_d
zR>wMfOL&b<+TfJ|D~5N;w*4RG-UB|b;@JN_dL(RP3>ah64W@(^AeP)60_v7*tDs^V
zLU@p^$F@M0go?o=AqqE@B&7G=+s*&p+}!kDZhG%Gz4r#`^}fHEotd3oJ+hsfyzl>g
zK9-;7e0R_8&g|~&?4CX6DC=nI?~t-=@J!0GQCVk9Z<Dc@-ezTey*6(dP}b3jE2g1O
z4?3oGxx+E7%bkvCUG8#B>+)L1v@Wl6OzZN2j%i(9@0ix*gB;VkyumT8%d%&pzZ*Rh
z{SA30b-CL!smnc{NnP@sXlv7srZSAb*v^9NAD;6sD|KAIJP#p;RSI+(W;_p3CgtOK
zh%zZ3&qI_+`FI|pOv=ae5M@$6o`)zC--G8N%Eb5Jd5ALcJ$N3XOneWXhbV)h$wu%z
z#8|k_&GQgr4IGc>A;!Y>Zk~q-Yo7>u;dzL#eqrpJ6Wg+TQuWNfIkDa_?`6N7j=P5T
z?3cF8ez~wwVeI$vd3(5A?DNube@KV@Njh#Gn$&9x>`w+Z1<3Ws{$yYWl(9d_Y`2}u
z{-mVWEM;JSQqz-n0kA)*=?P<hQqt3N*`H)KJgJQR$-oW(a{1VwWHyPFfzY?v|LgB4
zw@*wNWB-rY%&6*?eK=;(CuAQkF!Kr7hYPGh&t)GjF!Kr7hYQSnLiXVTGoO%sxWLRO
zWFIat^9k993(R~%_Td6EpOAgHz|dNQ4%mkiruOan&}X5SK3ltakYj4!Zg5QPTiG$S
zZ#N3tg#<O<A;&b|-HxeUWq%UoqjNQ1_9=yFzU)^D(|q^3^wh5Ib4=|j`=4^I+Ew;H
zg{fV=$(^fq^=8k+Zn2*#=R$$p{@7PlCU%Q`Rb^tg*iTg^c8hH&-eobzh7yBD$?mZI
z<l|s-*mm-9us3Ws`8e1bwwZh!_SUey<m0fnhHWJuhrKmyC;2$+tzjF<#~V3+wvT)q
zo<GL6k&mG%84K7p24;PRZDU~8XV^9p!;&A##&(g8#qVdENXIhAID_hdj$3G>MrhZ(
zE<>!T#r6!aO(fRdYjZ%hiGj84l6R`HO=K3=n%OP}W@TTi`L_34+1Ev8{e698*55Zo
zX8nC*WY*s|MP~hdb7a=vc`YE6&-y#tZYi_&JGR}zwBNDq7N-4<ZMQJ(cWk?bX}@FJ
zElm3z+iqdn@7Q(=(|*UcTbTAcw%x+C-?8lutU=}AwE$r%M@Q64gUZqAn99Lx0dlU&
z!DE3im4n9uVJb(LOHbwKc1-2yaZKglaU`UNrHar_c^na@a<H9d*4wrVFGSI}Y^xpD
z_-wBoSJ~NSJFfDx-F94cz_#0Q)dSma$5j_>!yQ+B%&P1=<9PY-$gKa|8JYE;e~HZc
z&m$tU{`1Jltp7YJGV4E&j?DVcV<NNu^VrC&|J)UsjhByeO!fbG$5i)Ea7^`nw_~dF
zCpxD3ev+{kd*=I-Bg30YL)&>uWc~f^VVrqtWKGJR7Mbbq>5-ZKo)MYp@0pRA{+<=t
z7Su40Z_oBj#=+-!Cgb39J(F?pd6AjF@qEWre=l%M_4h)@RDT~<*4}T=bN`5An%+kp
z)AT;(n5Oq}$F%K#!ZB_4pL9&^z^5EjJMihq)@tAWjAPoaKI@patIs*6a(vz~mE#MJ
zsT^N)Oy&5JV=Bj&9aA~}+cA~nE0Ni~reAeT<@lOoD#zCyQ#rojn9A`@$5f7QIi_-a
z+cA~nJC3Ow-*rso_+DgoFYNanQ#pR%n9A`($5al!myYZrJ;YgjAHJ6^FtdMrFI`|}
z|M*_Iz|8*fy>x+D|K)q>0<-?h_tFJs{g>~h3(WfOT3QDT%<SK~$jtt&kId}f2FFw{
z8y!=<@V#^)k9yS$-%BS<>zD7P6Q=dc_tFW|`h9@QL+ke{$FzR0c1-J+@1+arng7rf
z<29%pd@r5EQ#trvI$<gY-%BS<<=}higsB{SFP$)zgYTsirgHGTbiz~)zL!pz%E9;2
z1!n#O-%BS<<=}fim|bJ-kMH{k%-SE{^AVV}KfdQ9Fl&E&&qrX^{`j7cz^wi8Js*Kt
z`{R2)0<-qV_k09q?T_#I2+Z0a-}4cewLiY+Lzv3T_k0M`dgFUOglWC;Js-lf-uRvm
zVOnp6^y&4wrC0j!;>dTZ-PU;*;_lS)=-i8#mPhAb#I!s*2P3BC(Rmm#EsxH{h-o|0
z`4};6M>;1XrtL`QWyG`{>D-JM6wBkc&dr#~_^op@W-@;3+>Duw-#R~ICi7UGqcM|t
z>={mfc(OU?d!}cy{&tpUvi`QxGg*H-+c9)(PVXGgM2=OSi5%y8CUTtTnaFXzXClW1
zo{1dy@l52n&@++aBF{t)otKiX^ctqlONm|A7i80UDcCM;e>yKErtMGXrNp%T>AaMf
zwm+Sh64Uml^HO5k{&ZeSOxvH%ONnXw+Z<)vrS0$jj%oY5(lKp+5AaOt?JCct-mdmc
z>aEc;skbK2q~3I1iZXZhN_)|HDKp7e=cOcDz0{k|OPNW%>AaMfwm+ShGL!UlUdl}5
z(0M5{kwfRD%tQ{ImogJMbY99#+Mmu#nMwQ8c_}lIL+7Pn*tizv5jrmg!wO3}F9ox`
z=Y3J9Xp$jbe`HvV3GBMay02^5!D~1VjEq-lXkBMGGAy)&b1RN%d*17qw&#70X?x!9
zn6~E;$Fx1)<e0YSn;p~kJnERX=L3#udmeL4+w-_*(hep(lXh^6XVMNPJ(G4Y<(agD
zY0sn`%y=g4;Gk#H4sP{K+VgFWX?s58naFXwXClXgJrg+|;+e?tP|rk;J3JFP9_E?I
zG3%Mgq3a6NP8&oHT~{Ec_Egsun28*ZkLlU<z9%@Q?eA{KwEaENF>QZOa!lKw&fAf1
ztG2(VxOm$Bp6Zykzo$8-?eFQ1Y5RMIW7__n>6ys;EYGCgp6!{`+jBgVdV8*CQg6@m
zOzQ3Vo=LsEz%!}07kVc3_9Dl${k_;Tk>e$vi5xHWOyqc(XClYTJrg-z;hD(sO3y@&
zS9vCKyxKF7<28<H`+KctBFBG5c8%J<H#(;6?@f+r`+Kuv+Wy|+n6|&SI;QRKZH{UC
zd%I)W{@&r3w!e2ertR-tj%oXQw`U^ndpwhRd#`6wZ}0O=>h1lWNxgl*GpV=#@=WUO
zgPuvfeaJJZw+}m}?e8O=i5wsGOyu~OXClYPJrg-T;hD(sNzX)%PkAPCeA+XSL)VR9
zU#?O6_gNQD+u!Fr6FI&X8Lo)*@i_f;&tz}u4<c*UcKSodw4MIQF>R+mc1+vpPaM;B
z`cucWo&L-*ZKpqXOxx)%9Mg9COUJaG{>m|Jr}ua!db!s#so!6FCiVLp&!m2T>zUN=
z?>v+G{k>;Wzkl#d>i3VHNjv?MW7<yt?3u{%7tchFzj`Ke{LM3w<9|F8ISN@bL0fBX
z5IJf*6FEwri5#__i5zu~X*)f}Gm+zj$U3zBo#>dhzom|8`#Z@oZGX!g)Ao0=W7__f
zJErY#g=5<OPH{}z->Hsi`{R9jSZjd(I<)<r?&8&pyk~eO^>(IbQg3H@CiS+`GpV<;
zJ(GIly?|O4skc==p48j9o=Lr(=a{y?^F0$eF7Qm`xQ}Nd$AzAW92a>ea$M}0$Z?5h
zBFCkki5&O!OytmYTB;9if4WY~OytmYP%yhkTh~E}Y5UW4P-5EtbRCqKwm)45C8q69
z*FlMC`_pw$V%q+69h8{1KV1hUrtMGHL5XSm({)f{+WvGMl$pq@>!8e}-gF(5nbe!E
zgEEtP({)g0Qg6Br%1r7_*Fl*{z3DnAGpRRS2W2Mprt6@@wEgKiC^L~`d#v*vxFF2y
zLtUPU9NnIY96g?i9KD{29M^aza`bs7a`by9att`8?QhUCk>iHQuF+@TlpWJ&-`wb!
zKKo|KF@5&UZpZZ5H+vk@XWtAvrq8~qIHu3O+3OfyOu~BJ=NMi}!fd}|^u{Y%0~qlP
zf)KmOGYCTLX3ro9u~E+;2(bg6K@ehNo<R^|<DNkfViTT05MsA@20@5TI!14jAvWci
z$T97i$T8!Y$Z^m!k>gg+M2_1$6FClfCUV^FnaJ^A&qR)gI7V-XAvqrEnaEL)FVNY9
zt`(keLGcRO3(c%~Qpe;P$J8d498;TE>zLZaI>*!|9^;tW#08G2O<d@h+C+Y@CzlT^
zeX@Sf@AM4Ju7U9TJOi_9Ap9=R!0Z|bzsEB$y9UDV@C?kZf$;k~1G8%&{O-=c>>3Ea
zw=*!i2Ey;`49u>9@cTLggUJqSWc;p9VX9|-Pp2@|Gryx#nCh9|&nZmx%<twDrh4Z0
zatc#D^E)|(sh;_LoWgYM;dgNg)3Jx&!x<P%c94VL!6{7T;P-C|Q#ttko5EBMe*dO0
zm4n~EDNN<y_iqYQIr#mX!c-1^|E4gNgWta?Oy%JBZw3aF9pvEmZwga6`2Cy0R1SXk
zrZAO*-@7SH<=}U23R5}weVf8m4u03BFqMPfvnfpF;CE~aQ#ttknt|CK1b(-sFqMPf
zt0_$7;CE^YQ#ts3n!;2LewU^&m4n}-DNN<ycW4SzIr#mV!c-1^ccw6vgWsDOnC(H}
zcV-GxIrx2<!c-1^SEewPgWr=WOy%JBWC~L`_&u4zR1SVmrZAO*-;*g!<>2>Z3R5}w
zJ(+>o9t3_*rZAO*-;*g!<=}T@3R5}w{g{DGR)(k8w(~pFm|^2RW>RFw`F&}|!roDS
zSDLY~f0W;oW-RO><#(hR3;Rg<{b<I*UQ&KHnz68-l;4YHEbJ-eccK{!`%3wJXvV_c
zQhpbjF_=ZM@BA*b$j!#{yU-#xJJ0Vzi`;BIzY8sLv-kWyw8+io|AF337Wjmg<&VY&
z4-8G+%)0)Qv6j6D#CH7I7~P5<?8#q@bq`HX1>fnf2@7@dw}gc{Dd@foEn{D(<C=tp
zIxZzFq*t4;kX~KF<T-!|3w698VWEx}CQP0Qn6OaC$0jV)@#2KVIzBGtR>w<HZgqTo
z%B_x1NV(PVi7B@_UYc?n+fPcljql4+Ze#q(DYtQ+?<2E%!w@NLn(rlx+~no^$s#v-
z`JS@KO<umQEOL{V?=6em<mLOzA~$*Y9<#_zUcS#Pa+8<uHH+Nj<@?QyV<;7Q`JS`L
zO<un5EOL{V?>&p$<mLO%A~$*Y9<<0!-V2g?S!43vC*>yZg()|AFG{(|dvU@s<chqP
zq}=4aH037meN%4oUY2r`_wtmRyjP^$<h@_YP2SZhH+kz*Zt^xH97D6nyC&r(FW(1f
z^|H?7<$D1mH+lJfz{pKrz9%qplb7!cjNIhqdjlgkdHMdp$W7k+r{y<!uS__GaFO=`
zDK~kqO1a5<b;?cN#*~}9O({2dn^SJ`wxrzTZB4n!+m>>Zw>{x_HHgT&CFLe>N6Jm!
z&Xk+HTT^cGZcDkzyFKM5Z&%7q-tLr}ygey5d3zJS(d4}*<tA@m%1z$>l$*SK@2R!7
zjV3SOe;T>T%lDv0Zu0VdsF9nzd@pL`CNJNQ8o9~K_oN!%Wb*QTsgaw!d~a&xCNJNg
z8o9~K_ozm0^74JEk(<1HuWIBbFW;{kxyj4-tVV9~@_nn3o4mtGz0|MPxm_jW>WA;m
zxccJzGOqsk{*3F~VkF}_zql#mI>)#<<2uh6&A84r4rE;C8)GTAwT1DFtGp8#S9x#A
zxXL@3ag}!}<0|iT##P>#jH|o{Gp_R9nsJr)wv^i%#G#C<ytiju<$Z9*Ro;hWT;+Xe
z##P=sGOqGIEaNI~u}J;;@MuGtyVWF2{Q886U!O4X>k}q^eZs`APnh`i2@}6QVdB>(
zO#J$UIln&TW>=P^-0aHnDL1=vLdwmqoS1U6D@#*ucIBj$n_XF!a<eNZr`+ty@`O9T
zKIJCwDJeI3PffYWds@m(-qTZV@}7}$llRP&o4jYG+~i%Ea+CM$ggd`J<tFc{l$*Tg
zrrhK`FXblh`6)MfFG#t`d!Lk>ycee2<h>~6Chx@wcYb}!P2NjWZt~tY<tFcCDK~j9
zPr1o^MaoUy`=#9EU7d21w?5@2Z$rYJU!QW5cWuf|-gPNAdDo}h<lT^RlXqjvP2No@
zH+eUw+~mD~%1z!Y6Yl)_l$*R)rQGDbI^`yBW6Dk5rj(n!%_%o|TT*WFwx-<VZA-by
z+n#Xe*Qea%?MS)F+nI8ccWcT`-fby2dAFzB<n2ni$=jWBleZ`3CU0-TonN1FleaJB
zCU1YrP2Pc&o4kW5H+grY+~nPva+7yg%1z#DQ*QEJmvHCTr`+VdKIJCwgHmqt-jH&W
zx14g5_r{c)yhABBd3UGW<lU2UlXp1b&acn7`h9ydu72OXjH}<bKjZ56jbvQ?zMC?x
ze&5X*SHEvG<Lc)g$hi8sV=0e*ea2PZiHxhfw`5%9oy@q(JC$*jcRJ%L?@Y#3-h&xe
zd2h|Q%6nVNqhFtKmG}0HtGo}+xXSyGjH|p4&A7^YN5)m&hh<#lEtaTX-!!qUPuA-b
zCVqXw#IH}7`1J`Bzdm8&*C$N;`h<yJA6cK)#j%cQJuG$%jgI$w9Os$rWm)2x?8!Oa
zGue}Kf@iWP=S0tBPtH<feN%n?;r%ElIo6E3S7@%ZEM@%zcvpw6S)J^{`nuzDiI*F1
z>O;d~nN}F<pKh1^v8NbAJdx>C&qSuvjJ36IZ`#7;I^9@Hf2&;oIm1}Lu``Xev~S-M
z%5s)5ltuRMuJo+4kMlU&v(~`QG1k<#M(So&WD_lN-_E&_^{o*(&ht#_=6uhjZZ3#y
zV$kXJK9TpWkv&rvdM10OF7izFOkHdYGQ0QkTw=VbZ>`94sb^9z_w`KVxh%4YPI>3f
z<&pKR6?v}kO!j}>&ohx_wPzwry=NjzgJbZdxqYqiOypSWnaHuuGm&GxXHqX4JQF!K
zdM0vg@=WB|?3u`Mf6qjYD;<M}%yK-yGm+ye&qR)^Jrg+^jrC3Sw)b-zZZg(1v0a|i
z)9e_Y%*pw-MAo-n<Y@Iw<Y@Cu<Y;#co-e1j#WRtk!!wbi(=(A{t7lRl+dPx{*zTFs
zN0(<JN4IApM~`PBN3Ub>XjzVHJQF$kJQF$kJrg+wJQFzvJrg;0cqVe}^i1T~<(bHF
zt!E;~b&kPPWjP+`naFXyXClXgJQF!?@J!?=dnR(+=$Xhd<eA8^+cS}4k7pvsuw&$b
z(s)!!SQz8?CM=Bc`w|w$`27hBWBf?M!We&3!onDTbHc(HKbo+xc6T6QVeM|rGYs-1
z$9Tem91{r(a@>-zAjf3Ff*ex`3vx^+EXXmFupr05gatWnO<0iQHqS7ylN^T<7UZ}+
zVL^@uCoIVEkc0&}9-6Qq#~ld^ay%?yL5|{h^$A;g2kB9ya&4_9<u*qvrQGIdwJEnb
zT3yO*j#ezye48d(#kZ+(taG4?byf0gM-#JJV=eZazB<R$Z$8E`^_dqqrvCCm$JAF|
zWUOhTcOc|@tYcdUimnzLZ|O6C)HAUiOFR?XalB_@J5KOSY{!Y7iS1Zwtbe-G`6nlN
zF233_V<@B8kCTnz{LbLJF88cG$i2d|0XTXh_bHxt#%J4}>bZ=mr+L;H>h^TcIznD&
z7;EX%`+m;!Ozh!Vo{2mwJrjF)wqv^Q{T$DvZdQ3Fb#ty~Qa9&$CUtYZXHqv8cqVrJ
zKAwpj7kVagT;!R^aj|1q`Q`EH63;}AOFa`g?(3PzahYc#$K{@h99MWIa@@}|kz=)I
zB1gSvB1eN`=7)MFa;)`C<XGpK$g$otkz<2rBF9G0M2=0Ki5#0f6FKhhnaFXaW9El?
zCURWmnaFXqXCg<VvHqd$coG|p6HShF;xX#PnjIVH4Xnknww_Lo*Xmd&JtAKEY+K6B
zuD7S$?E03Jn_chld|(IX+38qsS72KmYw5y7Ps*{)cuU^~siW<lNgZ{0CUw;9nbc8_
zXHrMK#-LNDgKJW5I_NXr(zj9Ss^2rIs{zlX%?)}c^6c<T<k{(&$g|5ck>^^^M4sy$
zGauD6X>-?mCUQK;Gm+y4&qR*0XClXqo{1boo{1d0Jrg<hcqVcTJ7zv=!o){SSn!GV
zB}{zOgo%%uF!50n7JQ<c6DB@t!o){SnE0rksgIg4@lg{N<hUha;-e-^eAI-AkD9O`
z$4tV+M@^Xcs0kAv)id=`6DB@t!h#$RPMG+p2@@YRVdA4EEXeV&go%&3Tz$pfn<r)L
ztMN?QeaSOv_qCo$yRY+1+Wj$}NxNU*nY8<bo=Ll3<e9YlV?C30zt}TrFUKV;=y^%P
zf}W30SkUtc2@85YF=0W^#c8U)KBzD3`>t_J*Q-m8=~{KIW4caV=a~80j+w9RnEBd{
zsjpp}rRD2w#|(shn;Orwem&Fr^-Sy6Gp%3Gw0=F)`t?lf*E6kO&$NC$)A~)A)NjJ1
zeiJ73n=q;0goXNDny}E1PD+^cqm@z5cu;lFvuCPj&s5Kzsh&MkJ$t5l_DuEcnd;dy
z)w5@+XU|m62@^dhO!S;E(R0E?&k2)$v`Y0iFxjd4^Gx;Und;9o)t_goKhIQuo~iyk
z6aCFPrv2#Qo=N%c^i0b4FP=&H9^sjk?~$HK`5xt&l<(1=N%@L%Re!C!O@E%L{ybCt
zd8YdFO!eoP>d!OPpJ%E+$4q~oss21u{duPP^Gx;Und;9o)t_gozXJLj=<A&GY<^-W
zFwGB+(>Sft2kcndza2~4w_|Ddb}Y8Vj>WFnaj+@N>^S%rC);uGEtcCcI;!~oD<U)B
z`;^FR?r~~lHt#qsGFwYJJu<u2e}*zV(VX;hrX2^poMp#BFDvah=;drX4thDqj)PuS
z*>TXzxpo}%a-JOry_|2yK`$5Ban#FwA~U^Q7@6tiqR31y7e{7#xg;{v%caWNf?n=x
z$3YL5*>RBjayt%kUSY>UuKU?>lw);dR_6N1tb7f|;`?jYL}ur%jm*wn7n$wjSRa|~
z)z}aj3K)E!jgG0Gv&k{_X*MhC?cb?w_x{FOcIkWVuZ)b_+5_~sy=9l4ca^g3kzK8<
z6Bmx9Z!{XiqNuPYWzC&7e{MF0$+yI7QPzKLe+!=6PVK%`S!-|KZRJqsZ3zqgp*>-t
zEo@0x=ogk=OO^DPW$7`?(qopT*V@}vrF>vndK@oHk6D&pOO^DPW$7`?(qk6V>o6TO
zZ|Rq{)J|n>yV`aP1V3u4vi_aMwkd1rGqzpXK;IZas-rGtU0s7(Z{5n8`a89Ldz1}e
zAzbRb*H~PCy(Thie|^TVs4M64vlg1V*60hfs4R;q9y1sSiN|9~U}l$=#CX<EkB`jk
z(g~4S-#sxhvr9`Ov;KTiWVR=Z#}h6~v>7~}1ZL&q@gy)SACD)2S^3z`Gs6HX^0KWD
z%+h0fADE@bHa{>+kL@tC_I|ZDY=?#ET#N0nFttH!i-qZ2i|w&6wM%T1h3Q<2?XobP
zYq4z>rgJT}&BAn#4clg6y2plXvoIJ=o-43zRwlj>+h%3r3$blhCcY5cW@X|Fv29i+
zz7X4HW#S95ZB{0}5Zh*DGFM>RtW4$#Y@3B)X@lip`>aglVEe30<Y4=(OypqutW4x!
z`>aglVEe30<Y4=(OyppDs!Zfy`>aglVEZgguVb)%Rwi<=Jzy5c6t)M<;=A(L9x&^|
zE}bwg_FI1gyC&#rAhMP|dA81=XY%gM9ggjg_k-*-)<z>J>wcH9_Fjx|%&s-I9T%5E
zS+0u=FBJ`p?N!&BhCcUf7`9i;`mF!5y$a0wFWalYtpBpT3e5U1+pEA*dlgt}uL4W$
zRbXbXmXRERnNPw#a$vT1l<itz=BKb-6Q*{9?V2#P8*JBvsoh{dS(w@l_LGIF-C#eN
z8C6lxGyBTSTAEe&>@PFx?^VBteP&^UaxU9bVLigwo-%8;=QguFW!BWv(HYtS+f!lN
zdjexWnpteS+z$FXy4qSho94`gl%qM&c*bqPSQz`cEf@=9Keq*AVeIF&V9d>rjJY|I
zF*i>#=H^Pq+<eKHn==`Uel@p;$gOR2n~2=nH@Az(t&MZrh}_yaw~xrJt#ccR+}b<0
zlgO>jb6bhr+C8_I$gS;jn=uY6?Z@HBO<rz0k(<2Sej+z{xeY~b^75Q4a+8<mW|5n`
zJU@%v<mEY9<R&lA(;_!{*+(!Q?^|L&A##(KeTB$PUiKFvH+k7-h}`65zaesymwkuG
zO<wjNA~$*2hlt$dWj`Wvlb3x7<MF;F_9r4YdD*9k+~j4yB65?LeT&FVUiL2{H+k8|
zh}`65KO=IJmwk=MO<wjlA~$*2=P(}cTVlT>a+8;RkH}44_CF#wc^hd=iQMF6KO}OK
zmwl1QO<wj#A~$*2CyCtTWxphHlb3xH<MF;F_D>==d3jD1xyj4(s>n^=tzO=NIL>cN
zxuw57<(7U|$}Rowl$$<zzNO_E=ret?j}^J;ll`p7O`q&*MQ-|Je=Bm+C;MEHn?JyQ
zm*eUau<zx#`UUKNIj+6|`(Tc%f53j2<LV>Kdi}IV{XabArvE!rZu<Y1l$-t^k#f`j
zBU5hre^km%|Bp_&>Hje)H~l|0<);6;Qf~TxT*g)ZkI%U3{|Oma{okE&)&CPSuKIsc
z#&v%8<c#Ya?<pDAdEQequ5-Por5por@B^Qoah3NO8CQ9qnQ@i(Ss7P(pPg})_c<9?
zd7qncmG^lWS9zbGah3N4DaQaD<b7erRo)k6T;+Xn##P>zWL)KaX~tFFmt|b#eR;-J
z-dAK?<$YzwRo+*n90PEW_thC!d0&%pmG`w7S9$+6<0|j#GOqIepNy-#|CVu;_un(F
z^1eRfD(`=!90PEW_YE0WdH*xxD(@RJuJXPq<0|i)Gp_Q!CF3gZTQjcmzAfV_@7pu3
z^1dVG7=VMk@65Q$`>u?uyzkDq%FEAU*KwgW+JAobdgNy3`C03cn>}Ap<NTJ^KC|14
zQf~HnamvjOFUh!;pP$_x^R3r<;b*lwuKMR^vpcSO=4Y`-ZuXF$z3#Z?%g<VOT=V5;
zt2?gw^0U+(*L?Ze>5-dV;%B8huKDt_(H+-(`B~_WYrg#KbH_Dbe%5*9W*_+3=8kK=
z{48_FHQy`JdReRauFkmT+mLeWr)x8=`SP>TW4`M&Uw#(4<C-r&``mHOm!EYWx%C%*
zwz=b)FF$`+dHW8VpYn5rBe!<Gh@KG~xwYpdDYy5}F3q@>e|gHS9iEnP)x%jCS9w>Z
z+}=}rLB=)Ti&Jjx;j)ZtzN<5?`L0bl9<&zh(#DKyzE`H)>V=;(sru|1=)()?c-@en
zlju2K^hawx{QN%8Au(}&uAJv<!y3$|7rOdtiT3R?DL4Q2vne;b_qmjtfBX5ATRZte
z%FVz1V#>`<ektYV-+npe*53X*<>udhCFN#UznXC!FTR#>t;ertT*r%VWL(?HH#4r|
z<F_)d?cv)Q*YWW?8Q1pq-Hhw__`Q@{Kl*;gRo)+DT;=^?##P=QWnAU`amH2NpJZI+
z{b|Nk-k)V$<^6faRo-8u+{Te#W?bd{RmN4`dor%_-kWii_tzO$d4H2}mG`$9S9yPz
zah3P?8CQA#kaDwEf6Tbb`=^YnynoKP%KMj$tGs{BxXSytjH|r=lW~=opSPuUsihBA
zDcDJV=9c3sZ;9^jkKD%1+Kj8bbs1NAkIA^oyCCB#@4}3$yo)lf@*bOUm3MK*Ro>$=
zuJZD8xuU!_F7R`?99Mbyxm=E`y!>1)$5mc_E|+rL=&jeKl6CJbxD+Dm(${%ExvQyV
zyVTbMGu|OQSr3<cHm>(^We-6*&+Hx4bRXp7;xY)0WyzQ&`x0s>UQ<^qUY^jT=awR~
za@I!Hs`2U~YgTqlWKAl|g2-BwEsU&H*`mmrl^q*d(=O4?;>fTuCbawGB5PH)B(i2@
z$47>Xo#EUQB5PK5Vr1A%5#lY4tX0`bk+q?K>|-o*3<YF%vSTP9v*nJVfXr4nh5|A>
z#W56+*{P19fXq&F3<YF%x?}w!2e;8s=Pk<4jPd%FaT^TrT9vJg@o<-3&<kIS3Gucl
zTjk>6SrYx)56+Fe54R6;8PAK1A3ULH@S3TV6CM`F<@Hi!a{ZduN|niVcwQ$}CfDJ4
zjZ~Rjhv#)oWg9~t+*bpmnJeeZ{ZyIc%l%QA<jeg|ndEyzl&`f<@-2HN*Z*(yOs@YA
zc_!EYcY7vf-s72E{~z`Y9vj(!O2Wdm&AkZ=e(%17g=?Gp6Be#*jwCEx+Z>B*OY1-%
z=R2OT?aU@3>(qF+BrL?6jBLBcn~DrMgmyR^S^t34+rvGRdb`szsW)C{4)xYQAoa#;
z%*v$Rczs!!?#1=#>0VsVq~3T<Ih@-v&=+Lm^<+&Ck9MIt;<e<!2JjdbZhyRv99Vm=
z+;_`s$jZ=@>0DkvR@U0XjMt8hg?PMf99U<6Te!FONwLiBy=}-u#;zwP9El2lO5|N#
zqVK1ACi>>J;*eKYm*|_<iIs`Id5u_^=$qGvm5IK2ZCIJ;o7aVviN2o`%d(3KNcwqh
z!b1ChUcy5Ae}2M3`{y;_kO$HW?Vs0wjfM8lW3sU@zkG3$UbwdZl7y|sPRr1adCk|(
zUya?2f%BTL<LaaEny=$)BtEbC8n3tXdCk{xO`q3%9oO`E&DU{FpVxeiH(2_-=Igko
z&uhMpYx=zA>$s-RYre+USo*x?>$s->?}<Lwlr{a=XI#_&kA$za^xu$iO`q3%E#I}4
zKCk&YuIcldukm%3KCk&YuIclduj5*NUh{Qa(|=o1&h?i5+cU1|za!(C{yQ_S>GPVe
z<-5Vs=QUr)HU0M_>1;6lyf@>T{`(TXdb`?{_b0sG_y-c+VEn%lzQ*_m6Ta5?hZ4Td
z_=gj|-uOonzQOoM6OI>@iCz3y!ts(a;U7;pUbrUw6A8yl*MxsE;dt?y@J}TiFJBY>
z>4f72Y{Ea2aJ+;~_~#<;+SP&yf$*<I-UhpA@_s$xv0lEB@K`V3On9u9ZzVj|%eNCA
z>*YHMkM;81gvWaMUczI&d_Uo_UVf19ST8?Jc&wKnB|O&4j}sp2<tGV`_43n%$9nl$
z<WPSYw|<_mFmC<AGx6_!nXnM=SDs-di^jow5*Fg!>ls#nDBiCV7UKQJGpw9Yyx%4)
z#QU9RSaG0uzfV|*_Xp1~Q>S=;OjwBbC(rNzEQ<H%goSv2i45a(Sg-wS!or@pza<O`
zl=lBWDYrFTzNTe%4@>b9zlN?oL~d)ie61^TTf+_S8s<4S%2#h|xO@%F;%_v28{Rpr
z@i&@3z}LoHe6{Bblk#jVtG(rGW)^>wrGIP^f0L!p*V0^kP5-zozNXLD*erfMIW+9M
z9-qVq7r&6Nz4`d!8-{l$tGtLW{vltJi}A^!;q=2hlr4U}rq9>ve0)hiyi3`|m-P7>
zUW`u;4W}R8sci8ZG=09d=i^KI;oZtEzNF9B{9=4^XgK}wj%AC#M$_kOfj+*ZAKta>
z;!FB`jWEV1hlbM+?_9R{Yc+kocIe|v`r+NnF21DC*A!!Xa%edHbJO}=r|I*xMjv0&
z5AR~O^w(+q@-;|{ztP5>@J?opzsWdXo3!}#7^s4u9Nx{W@#`^A1<uzjV|)x$frocA
zTYL;uf%CP@7#{;w;Ne}(79Rsu;CzkK;^W1pVjsdgn>9XOZYrFweOi2a<7`OheyKh&
zPzBD{L}PpmRDsv0@i9;Z&euv~d<;~9uSw%$pbDI?p@#Sv_oM#T#rWV+|9oxL;z#|5
zcTcmth#&RO*IZ+K(|>pewZ%96^R?I*-}E2eMQ!m-|9p+s;z#|5cT#KosDHk8Yw@H0
z!@H?9e!c0xG0{W4>AxxErvK)YoBqSQsx5ufe`}22-zoP<g!ff*+*W1nF<x`8#0&4M
z=6L<eI%2#&U7HN=tLAupy5_jm#nbi5@V@F0PuDBAyLh_h7~WSc@np@h+r`uM${xpb
zU9;D*jnW3g`>I2Fx|ZMP;$f6#n-ktw9pdSG=?8o~u{Gg+)e=wa*bX00)){tsChH8l
z9NX9&^1arvO~S5otbTPf`y~(btUj>oJ!=T;L7uG%>;}))1{U6@Epn_2>_!)FqueVq
z<k%)*yB(`vy_3rq-lwhl3vAfOYX~g7Ph0gD*j^uRZD8Sj+FHKA_Pcl+TZ8_>`?N#6
zO~P(+@#<HH=U9dJX>0ic8};!T0t@fc*75~5=HsmmY}~VTflWkqt*#G+_i1x_V8Nf9
zOyY(0q3}L!jThF3rjvMKeJH$7TjPcGp@T`hus#&tr>*fea2?&2#0!3Gc%Qb$3x4eF
zNxbOChIeXfT=WtdcOH_)H$OJKTifEBAA3g{-~8BzrQH13*@VaW*TWMY=U;awJkG!V
zCE;=Y^@xPW`PU;89_L?=N_d=qJv!lW{`HuI$8qGb36JB*T?vol$m3FO<H+MvZsW)k
zQf}kO-6^+m<cTS_apXyn)4C^yjWE7HIpOujpOWwf<4;Za8skq(_*&ynPxw0H&q(-s
z<Iha^2IJ34_(tQ;PWUF{&q;Va3Cv@}b5l+NGk;#nNnqyBPdN$9`~@i|ftkNB<s>lk
z7bSdkr}|efPI$fXmn6Kw_)8PM#`wz;zSj856TZ&)D-yom_$w2>!T75ZzR~!r6TZp#
zYZ4Cq%RQg3O*sk7`uW$ClfcYhmvR!A`Tt2d3C#T8QceOh|M$qruH&&Wq5Z!;<GOD7
z9~swq?i(_$^W6VTc)g|n#*AzFZ_2o)|K^Nq`fo{igQfr0jBEOD%ebch_Ka)#?@0I>
zOaGl2*Yw|&aZUf-8Q1jRlkl~c{(Cd7>Ax@In*RGUuIYau;p;5@|H`<g|G|uF`X9=;
zrvKrDuebC+l5tJ{qZ!xqKbCP#|KkbYVCjD%<C^{_Gp^}>D&v~|rxU)>(*I1xHT}<K
zT+{zt#x?!VCw!Bo|AmZe`d`errvIgkYx-YKIP8h|{QsSESx5Rx&c*ltYR<*~|60na
z1GC-udd?;NZ{%Fk|7Ol5{cok5IxwgI?VL;c-^sb8|J|HR`rk`Abzn~a`#G2Ne~@!Y
z|A#r3^na9c>cE`-k8>{R|0L&<{!eo*>HjR{)PXtupXXfC|3%Iv{a@x>(*IS$SGTME
zzbE6`KJU%Aw$EQ@T-)bwGOl~wew%UK>-M{h>t46tXI%HX{UPD?R{lR`T+9EbjBEM-
zoN+DxUox)c|7*sz{C~^1mj8b;uI1;w?_pg9<8OnNzlQc|JFev~Wn9Z&n{h2a@1b|;
zX!(!H;%oUAWL(R?FymT&-ivSPud(tUo5Ww!uH|2xaV`IG8Q1djo_?3UmjC!HzLx)l
zjBEK%%(#}H?+vi@*IM~cO5(4z@-NG{mjC38Yx(&e1DC#*e?=Bw%YRD7wfv`MT+7e*
zDp>mKto)}Z@z+`T&&arz|ICbQ`T3p)m%f&NWfot{e|E;T{O4p`%g^^tSo-U&{O2a|
z*IW6|%ea>R{ETb)`5p|HzLx(!S$r-3g&EiKUzBkzKi|t?>2I*|Uy{V%VCBCw<68dv
zW?ak9_k_6gwfvW7@wNO{WL(RCzl>}7`Q8#sf1{PZK8e54%HNQ2E&rN~Yx(&e6_>u2
ze_a+|%fCM3TK)|g*YfkdE|&f#EB~e>{w6E`=8S9k@1JokKi@Os(%14oAd9c%zbfNe
z{;M;t<!?-QJq^G-zBlDu#`or&%lO`sa~a=Tb1rMRZ8?{9-1eNyp0O=CmwjU$DW?IL
z%io!EDgV}-OZm6uT*|*a=TiQzoJ;w;b1voY$+?ujH{~<{bNR2yxs<;z=TiRuoJ;u!
zaxUc`%(;|*N6w}EJ994O-<5J2fVuqF=3L5uUCyQa56rog|N5Lu`5%;XDgO;Qm-3f$
zF6F;5<um|u`G;~Y<=>riDgU0FOZkU$F6FP}T*|*U=TiQCIhXS9PdN?1T>g=qOZjig
zxs?CroJ;vfb1vmSkaH>jSk9&V<2je|Pb7Rb9?}=qe{RXR`frmNSNl1YakZb*39q;G
zXELtoAI!L>e{04y{o4}WVCf&qxTb%5#x?y1XI#^NNW#}x`VY;xrhiAqHT{QWT+^RT
z_*zT<;ThNT@65QS|1TNW^dFJ%b(a1kGp^}BD&v~|qcg7QKPKVpE&a!4T+_cR<C^~C
zGOp=AKH(cI{U>Bx)4x08n*I|ruIWE1;TtXeCudyKe@ezR{ikMJ(|=mRH*xxP%ZuVc
zrxnGe#ljU&SyGgyi=wyz$C&YT^tEj%SBfjHZrZul4jUVbdrl~7SFBrF6z3uC1x0bs
z+e)>|XiryBw6&Cbw(&Kv8u~rh-?XJI*q{=J4Gxrh+RI&ST|Ir*23||Ny>ok884t1@
zz=n3Y)>TKmyJw)>-ZR)O*Bg%^*4e$I2`|kl_jhj5xC=a|93_o~#C!YNT6(&A%YALv
z40iUl>AO%DQCLqX&wyP2K9(5e+1b^*y{)UQdjQcTt;H0!qrTkR8m{5;@nHA1?w+09
zC}Urj+yihN#dF6?=y-c)SLZ;G_jo#P>FMhm>>bdwParnXi94Euy*rVPn_61h`uoeR
zZQY$H1>5nZ#5=cdZ`;zey*zMjZ(A8p#glYT;xN$-o>kj2IMCF*y^ZT)8HKerZ^`v}
zGV$&n<k3911&VE#=kP7h(n8s~+WH5Yx_U!7R#3Rez~$)e>CtOdr*K}DU{Gf_tBqwi
zmBRbt^ZibvW6`7P<8)%pO|9h?JTI`V+}kwJ!E&5IJh1k`?cqL*Gl>oK^pv}ry00yF
z^|Y3oT3bmsqRX==ysNXjlZz1ayOJ4pR-kUF-Jes0c0Yu6kNRz!oE)E=3hmwwsogKG
z3GKXY_9q>yYY^0VVB+A87P}5xH+#;g<95BZZuT1q*Zx~K`|BsW_;zn+-Rxy=b9|HT
zv8bDU+7<ONU+km|^3=_4UzG6H%7p5&ZuX5YcVT#Kr=HXF<c645z3$JboBi4~YaGWm
zQLeYTSr;E^TnN1#Cwkix^oCxu!?Z>RtTQ}i_}F3)pWb^G7p0{Y#9cg#Km6W(3cepv
z6lWC2E?oxeLC5<Lj&zG-U|;C7tf*N=mW9G=>+p>~icfYb#;+|#a2|c;#0RSu|7MAQ
z0@5!b4yRo;ZmBpRap$HJ%Q-i!ra1d#B#4j7de<!du31(Cb_>#^b4WImV{uI}DS06t
z>!${~rt_!4FLme7%ya%hIe%{2zN`zD)uIqnh)dtM%J*&f*0NGwl*a8~R=!2CeAU7<
z?`1_u|G|>(L-75BqITJ_7;E<8_em?xEcWA@KG)1tCJ(jjW_A-8s<-H?3=LEJrFf%Y
zi@<hHj!aje3u0qnOE})d=+K@DpG%CIOw+_fWo)?Mc;jHmvS_W0R&cU0VB|4c8JY^`
zQXXe98ycoDl=7GWTLm^SIWx9r2xp@_Ct{2{1l~VASs6M|;J8#g6vyKemC2#$@yQ3^
z+)ImNR-9N|Sh@q8KGfdp^b8E8gW+U!jeGBDfKI}=IX2QgGRiitj`|*q*{)#rxbGEp
zdv?Ppbq(ECu)RW?;c<EvX(M*a_}J8Rv{&Jf`rc+qzos}iyt`+NWuW}{c-QdI^ia#p
zB+6l|H?k|xzcrsbk<X6GWGhZ+9v$Bu`nUs>*H0v`XeY*|50X`p@iW>Xa9APAvu?J#
zKG-HO*%w|n`wX#h%*c|7{rTlWi@QGTpQ)Rj{7$fwh`T=Q`Kg<2eT%VmtA}F#j>}&4
zy4g29#l@8}U4Q%uq}5KOi5Gr{a;ohEgTB1&dqk*%&Tc%KpFJfy6$hk~Pg?!LeQKT=
z86EB%+dE!{(kClp)2$<ul|5)Rhd7TK^0;Cg{xvW@KC0y}rQ!YKGn0EN?IWYqC#a0I
zX?XAC_`b=Z15{<Z(abqw&|?~}W&FT_p|Rnn$$c{iP^Kv^%P|~huycDW`2=P5ai|>Y
z(Iys1+j|t`PD&gd#VADuTEKaWVO19M7%<4T>@hf3$AH`27_b`sg^uq+xE}+qK%Xj#
z*%I}q`01bA(*Z+KnIydr+7YrO+xd8;p|<l0lAqf8yK#Imj0M@SG|y7;M1;|2Zdgt6
z0+fP2>knU^o|);iNB}5Ru;Wk3%F={#Je3&AOtNd4pH581MlItrz>X_Q#nbRjA3BH9
z({r9h=gby`%K2;@)41kk(KMbTX^_2|tJ}7*nFG)$iy^;Rucf8WlRRjgc)tA(W7-RF
zJU6eJ;)Rme=BjyF&B3<pxjEGwBh%fBk&Yh&UouaAFO~eDpD@;DItcBnrg*u;Q+?fn
zcvKg2WhfP|l(-FtmtkjG{+&|xnx(JC`C3n}!Eawruf_3v?eSkFU(z@C4b-p7^?wjX
zWhEcN`VD-De{<(hJMubv{XFOVhnzDvy}5qFzauXB4R4U||HQYJkMg24-UMc4g5RKJ
zsurestKaZuN%t-IF2Uy}zu~d?P2=+8@J*kV(Q%C4VXS@<7^<#l8Xo32PsTC%41JXY
z;|FEje<m3D4D4?-AL<@D5XS!Jf};x-TPo9JEcyHwfsx+;Mvb4@%fRrDSg<;wwX(19
z3IqiIf%4nQ@m~eD3h`ZjJINN346j4j1qefVnUP=dMlkAe<WsyAzr9a!9@^Ye_!Msg
zrw`dr_!QDV@y&hnm}RRF7TQ?&y|CuqdrpA<jz{|E(TT;L-BboWt}710ddA~L#ni|?
zcf17g!$4EmIZKPN5gtukI?KU&cHdNJx~JiI$H?Tg=CukrpH)mv?%6YbU}CZ|H6?iv
zUs>#%Y#$xkr|cb&ZDp~SPM;YX4f(#4*#w-zP}Y-h-r2=eF94T|Y}~41;$UB8sxo=7
zGEDO;Dhs*a#MiIYkOsEhC!krqOLU1S#l@t{P^<IWZt|rl%~f<ll`_M#om1wb2xZ<{
zEWnwI7Q6>})+Bjt-hAcE*cjU4@a5A(`>rD6F_4f(UouoPe2-8L($nGc+>JI<Di)RA
z=j1$W-c^b+m=<MqUKa9SNhhR#$XZqZ#J&DW7bw?)51?F&{y|-=m;BGA?2GZedt1gw
zXAX?@PY=bmM`5KH)<$y!vf(A*4?5k{kv9|0FNfjV9YgWUVBt;+J`7D}@d@Mkhmi)^
z@^<(}HPH7o@*6!B^M>9|r_l<`$mJvO9=VElt~JHRfJU5we8`So?|h>3kRBa>4EcDU
zNXM*I(EYjiBfCm@$GD~96C$6^iAfg}-_N0A{MzDE5?|A%_;<iNsFwC;Brb(fyqJz3
zFT%WjzOb~s@jNXr`9>6{x_q_87hM_Bv}%jB^M;j*D<n+wAsru1FJF=PsuzkspI*Lp
zn0((uh6|s$`oxS(!n925MfUTm)@^O^Ey?E;_&A7COfC<4qWIO%sVlx?Wvf|s49+2$
zNf!I7n%6PK_vAcnn|IAdALIuJBYDUNv3iCN@<ThPhTF6HK0gL0A3=SXpUiXqPv!i%
zX~%YQhO9IE2yw|D`I&tG9N$`2%8SzYC76{D{)m>ZTA1do{>ZN+-FxtTUTyG4K7!v%
z(KkMd?<&2SeSnW6j6UoGU_M!y+>7N3Oq{1i#>X&5kuN}TsQyBn0~4banuiTdBZfxg
zc%MW(@@Y8Uz)1c2_VLM<9etHO<CC^l@@d2|A4dZbkD{yZ@ma(ne}~iQ-JQqcygr9G
zXihP&u8}c4pTh9Zg$?b|u+Jla{2)%dC9LUu0c;hR_t%JBKn#=5k?F85^Chs0^<0r}
zuyug-NbxU2SpUq##Q5a2r~rad1o5dT&T7Qj+c{Oge)q`qz@dpsugsrG&tFFP+L*qa
z9O~e|5w<Z2Q?-P$eHGzXYPbfmUPJiT5#FfbnNGEQRL`v%XJCXhYW3gYIJC+98;HLh
zylJvRqD-~jLheu~?>7<Fi?Gfq3hHN{NAvkM!Uke`LC&2a&F>;?mxgtX4`V#vJ~CDb
zaat>TwM~8>@vhf+1D#Wdpi)m!KIE_dg7U%JfyiII7r%3V^_*gT>DS=&p)s<KW7AAM
zjB{Va*iGveMbX{V)z;C}-%)O+6^AmeGxW(djhZ~H7xR3(o|K)}*VaGS6|Q&G=I7A`
zpzUn~dQG4%4{z)1>*<qqraY{t$F4~olZUl8b>c!yPr0YJt(&erpnh(EAFvR<#WW=Q
zE#yvZLsn*%wW>={HDV+DKf3m|3TczghRM6<HR1!&@jvR{uR;n-=ke1|s^asWRK@2#
zNqk=N3x5y!mladD(`1YMds@di7P|R^v<oWn^5_GmQ)dX<UfpkYe$|njW+a04dc)y;
z;VixEkV|E?NEtRpM>wSKuZN-@P)Cc46V+Gj4SwQZAv5`j>O+vvjJP;n#C{ujssBT9
z;Qtk;hq$><xuyT_^(k=%ib!eR2A@>dlPF(0u0=lHr=+ove1aHOQ(WqNmNcwXybfv5
zM|~FZ1L-=A`j=_^+F~K{qYvdn{UhcR$MouJeKZXp*grECmWS*}WLqryA~}zf-+7sq
zfX~ghwm9CEDb>s2WRL#ZT%DDQ{}jE<FH8TS1H52ANTSdIBnj<gnUm#Y`yJM?mRFUb
zrdS~|__kFeamm6)J(r48v$*7AQ@xQKsr;qlbcw6F)VS)8r}6RLWr?poDWyy2kgx20
z(pa9lVx^p;ZPfdg=OB#AmB;|!a+RG^!|hsq%k#j!Z+ZSa=U*V_&rLhFL-j4sMO^YN
z?<3zA;#<qAzU9SWCKG&1Egz+yhiTsGTV5jRUW)Ja*hfKYU4MfeAm5Veu(!RNu3qD+
zLU#ubkQg%t2K!r@wr_84YT3r|N{D9`D$Xd`cdA1eeb{N5#|Nc2==Kt4ejoH0#3LWH
zyK>t!8ZD>40E~Rjj-jdj$`*m4+7WLEt34c*eVSvzAztDOo&ZL}!M?E87CO23bSEN=
z{K=lZd*Omm>cRh63cd;)1RSBlPXfOHT*_kWZKr^fZz*{+AHu>Lt$UGQcpAdUx16d>
z_wF5oTQ(9@O;>BMkT5+n)iN|Xx_byK(;WW{#9xj0tWSxKLJW+M|K$A9vk-6XVdCj^
z#<LM`BjPoWj15g5>W9Ym?BCK)BWC9qT(lWn;9-C3BE*9=XMgLy_?`P(r=s;-22LLu
zYw9>Q`CDNOxYYcuTc<~$xT)^u)%u)<n!*?^*xh?iH+-0q_%K%>&9rS<+|`?^x-LE(
zW({?D2G$^huZK02{+-xg(><VjAo#i$u|bA>jf$^zNj%b%UEk7pvQLrMY$TrUh30El
z8gFgz=@!u14zb=IWYT8OOIxU%^X~81F8d-EdEOBDvC65aj6>NLJ07A3Zs`v+H<KPn
z4oiEWnV%=K8M;1RbiEq7MoEVz4@})UGQDU2G`xFqKY069LW5q(4sCI3MKt!(aRbt!
z>qHO3Z~ExCK;g8mpmxv4T`O&8ZdkO5nxD7P8*tv7b6}%4N_upSit<q#y&2rw==;xe
z{*`k6+_YnP)JAVYT(Z#*kngMTtz}gk-3Vs#!bWTPDE&N4^Hv+(B<VKe`wsLYve6qb
z#*_V614bXV2iu3Hrg`^JuodeNMs~HoG95$2wyj4P+0s@R$jR|T=-0Ky)nH`lLlQL4
zLQeqmeLeWl7nWMV>9Zc?sB>pgkGC|?OmvNw>Ymp~(VxgSr?I)N7@5K)XkNFc;|1co
z)Aa_7xutf=gU-ZSZBKB}dys1Isc|KuL}Bq`E5v+t#Cy_c%9rn*W`p6Dm4(JtZoS}_
z%yVF$@0pZ&&NOEhuUpV@om|(TF|z|@HhV=Kh;t1xQ`n+nuU(g*bC(uF`{+6n>7*0k
z%Ztf<yXndT>WQvbE-03kwmLmD#`#LP0z?W=#WwxW`uq22Ae4_=@BWANLs!&~3v-NK
zYU^Dn<Ko%S?w^S^p}s!JNXI=0&wYJr6Z3_U&oy6Inr8Hc)y|xUbM?A&8n;voh%Tw$
zrC~KiN#+_p9lb7^#w`^)B^_Nyd^TjPmgcn<ue6lp@wV%M2vhrFvch&<Z|BtTIcmFZ
z0Qa`5JkR+z%K3BCo@=`vgt%n8hU9xUzNtQ`JZig!!K{3+U0Oa$KM&Kq)pk`R-M#oe
zTdt*c<2Tu^UVPKXugzTpX1-wm$nAQKwGW)^6<tZ2Mt`C6`@zWf>%Vz~_Zt!$1fwR;
z_K+M!iMs=QIe7aBuE2;5r2NVEYr$45^~ZLBk<aJ%aS>Yu)>q;EUYsiBbsaeQdni9P
zH-$1$`N`Mg{M*86DvN<U$;R$Mc<b(c>__dxZ*N=4?wy3|toy;~Lw%}_V^b%`S?Jl?
z-e^uk^~CeFN5pnS$2a5eIE;8VNjlmtW0-FTp&!JsIG>w)Ua7dq?J1;le0!e2v9>u&
z5AFFDDF=<k#I-$7;kR$k)AO7^Bj?Xe+shI5{7oV*wdaHKeJj3IPuiXjfm!*`p0#|G
zejcWIYkR(3(tR+#@5Go;EUzv0v7Zy_e-xbBBz%2t;|Fj|?Ge|V4{Ey`1EaRM$F-Yr
zFlvj~gF?IgxUJj<rW15Jm&W6VfcZ8<c6cG#VXX7e*t{6+=b?y0pF8l4ee5#D=h0IS
zc#NQRqgxP<>}Bcy=WBVhkj1a%(KS?B%X_%UO7gn3ysG<P=2_3%>HUNwTm|0=#T{uq
zFHf&Z^3DZG7xXxNYOl0+YVj<!-LUrZNXSW?_dmJ*PREZ%81?r@i7qsr@0*WBnD!q#
z2YvG{JEw-z*1q|8aNjqdFwgmS%lUKDp4&Gchq%-?pD5o?!nc-H`{q-?tbFL3T0TlY
z57WH0Z$4GheHy--tMtvsfNS3*Tl{1kbBB<9FHgs@?^_E{x;peN+M~7*{puMAr_VF-
zE&XcF9yML7qBSa7honD}aWT$OpNM=LI(`oRj>FE$XXBeb8qe3;^AM)GwR2E!&$n}G
zIBl)B7lQkGd(k}SzgW(noA%s#djaB7y}d-fUy5%ntJd4giQ$iBLcMAEDE&N4^VWKM
zg{1pRe79Grx95WUdV3j;souh3O|Xlv0`ql8wvg)V)!_7rbyj^H_ltEaSG+>zs}%nO
zsJE-HE^okesIhT<b7OHekLdXdRwIWGHnnZrb)813wt!V7o=wRtZ0j{mt&N%tEdyZ{
z#sYhrT77W;$i6YG4o$`gu>?)~GTMUu;?osu47SuddYfB&n{YjgU?XMPgMI6HjMa0a
z3`~s7O@uG0X(FA6jS;T7#w18>?Ej^RN+UbfRl`<f-N8;7Vmlo7VBQf=`sx~*h$(UL
zDLjaX$bCb%HXoX<Ou0Dgn~?IZt&P`3)erB+oi%f>gxg81YEf9*ZHB3YPG!C8w{$?m
zWn8oAZ)@sn>EQdEXiGB{hjMEfpExuyo}9mJo9YphIu}B9MTF}ro$R;Ww$mbR?QJUW
z?2M9xM&x5qgfx;hr3Ooe%e`f=vo+)w${BNkpyi#Rq`2PQe;rj(sHWz&4yw^uec4G|
zBfbJ9X`eNv-MhXC|BzO1)2^Lsds|wlAoZpiuI{Ru_i6W4_Ki$o*8_@%W-&1`w$BNO
zTvk(hZDT{bM=QOPmAw@#c_nd3lJ@OGw;zh9F`{MH14E-J<%tQaEH+q}1<ImbZuZ!M
zn-_*gvG}=re6)FH@7~H}n#AA)?tiFQb;Q7JgXK^en%u;sYc*V^UTjQYL98m8xGFw)
z?8+5?#avE5Z-CQ8c8&YJvujn`J4Z^5Tegd&F^NLejzwdGu|p8$rW@{s$s<{VrMXoa
z*fhxJa>HrhBq*1l$|;u<br4=^)<)7hvwL)8&%9Bv2H#)V6BF37Wh-oe*l=XoJ~@7X
z*6CdgbS`8f#o5x^w6(!bKvHCRR2%3&Z3wqu+ObOaUQ~<FI&)wGX~u%?q6#I7L~%3C
z^yJ9y>VZB-J}DSdD+Hwj5qQA!aZ$Rhoe*ZQAC{<d3l|gdg2G%8n_EMeT(^+2xCo?<
zXkOVW*^UsWIH&><ZIB29>GTv`JQ)~?$!&wuOk>m#IuR!ZBb69Ty^^wuiebCME1h#f
zIw)0|_{YMz^PmhFSV`yAqOfk+++zxE+TFRfwRsEO>Dk!G^6~uK%8#S0e7#slcW1=L
zL9L9gFZtHk+eGba%hq6ISz|F844;)EMr7N-F=e09R9j1oM{R)vdxv*N$^~b8MFmF=
z*pG8_-cSb(y20o0@qF7SZzL4A*?CD}yR!wr%(EFAotfG{ZxwL)V`%fCR2K4RxP^!r
z+UevZYae?r32TNZizbQ)ogoWDeOLu&<;Y@6Nt{M~geFrd=6gwo4Zh6ielfqUAsU@{
zGnQ#>3+W7Per{M(+paB?aJU75?kqqH>pM7P$?pm+s~zLz2yR()HrrZ?GlH&ITjpB9
z-lka0?(v?zi8Ui*V@k_I)SSi`od@PKy<1R$Tk9n+sbVtHbcTu5fo`LTTCSn3IT;{=
zn&);@QMktd7Lr_q&gqIXI^^iAX6f3YXI!D}9-pqD*$qy4m7(>*TiLamVt2sWP|ocw
zS^qb^>R{js<jNDW;ij%vexr0Dqu?2>hB@ik!HyB<7t2Q(ca2OP7=lBSpBoAZPs*J$
zaDXi%$^~aBKcR!AO5(Gf>}o-S)SeAr!|Nc#4sEZ>s6tt%V@jfmxq}LtjSk1&_HDt4
zp_R>ca9cw|9Fl!Y%Fm*<w5`6L9m?Q!1&4w<3fWnw1Pp>)|6~N=O0rWCT)39;nX%~@
zlVkBxa(`tXZK6$vT&n%5db4JM5hF2*&?$|Gp~2ttjYTV0bkhQ%d_IQ7aPs4zn#0ad
zIXrdYs=9hfJg6WvUZv#EsGAUkpK7cYCY2q7)P)F!5W{sEv~?@`YfRbvofr*XSu`#!
zVM-j+aHfSP%NBwW-P@gNW%l8;4b_*;%ma0*gDs;YsLog>G<9mim`+v;lThx#?IV*@
z(=Fq}*d(j2oKJ?vc(rI8pKX~5fi_L~a0rc{E&$D*$5aXrUY`Y8gKB9eOXJUqW;PAU
zv_*4#OOCsk`EFz_O%(Jhi$?Y2oE3K6EYJ&rN$g=Wcg~BQZz93+&Udn0oS9pbEHvth
z9Mv?m+|9zpfW*J4@NHoxAw`ZYkxCIZ$-t@Ca+bT%VQF@~4VBu)#s&IPPeNny<XJ{`
z?G`&N4GD!dwPSGgQ(i98HJnXaoreh)ogXHKD7JbG6QaQvQ@xYUG2Hbwood$X1s9&f
z+_`S}<?xot@u{i)J>wIVw%cffz3Yk50)}o7qhf{T@KHO*M$xM)S;1U_1Cv8zQ=^!1
zQ)PAzN7)d^)ij>J(A7FHelw=FnBiG1x`bE=9(0c)URPyuUuC#yYN~Qz_voR{u?gIq
zJ#V6T*iLGhT&~ij^C*XD)FJ9T&6>+K*Xpw({6>FQSe{pz@UGU-biE2YTjvkcjs0OR
z7!^S+$fuFr*5FG)ojA@62S$(-Hp0aiSd~L+u|`{Pryd4`z8y_fi<Ou-*J`)GzHuUH
zgv1C^lo*K@dZt_wC}#)_u2Jwg`YL-}In30d&r;pz!k__QC0NAiu2hDxwlqF8jAhjc
zwBpGvl`(o2NM)ENb*4>9v~8?KmZ1(Gm&$0Pj`X1;w0~-e^vog}=q%H%lqpn2+NNfO
zVS{ceYS~}ebMq8dWUX*z%I==^wJTTr#`!lF;35h6H$3vVb*g;*iNlY=znL2^yNM~>
z|A>@A%Znp#(n9Ok$9UwrcqbxjqFL0mjn=QnBBCY5^SIEFaH|w%b5%lGb{k~XhEZR|
z;?)mXTThs!Dh<g3L$6>ltKHXRnQ_YbT}^4I<WW6`*qFFysy1T^ti>2hBOo;_4q0)7
z;fo_)rtBnQs%o$3c#Q<NKshxtPi}Q`33AyI6BtWnJw?sV&Uhlv2EE}ylTUgzZP|^{
zAt74SHg+3=M$<c=Vob;fD-%*~FRfg0xm@F-sX;w1<Ws-lrO?Cl8xB8;ev`zbMLAf`
zMul8;Y<gwOa}r|fF>xQZ52u9$uFuetHBD}B``m79JEudI9>`zgHO;VgV!N{~BDEE&
z7!(z)2;mk&nxhciq3r{xy5vO3K5W#sI4}${HATX>V}cTzI^wo%JAGG}A$QPnf;F2e
zJGkwHZRn!W3{{EQkVX|Rd;Xo=79Fc3;qsphvDjO3Le0t*4|DeSPiRZjj`Vs;Y)UXh
z3ekSp7SRK<JnTT#LR_w0esI>DKn@a@Jqg5#92WLpRSgO&cS#V9H8Q$Y;drW6LaB6|
zi9TE_4MpY9{?e5zI^A`XZK98`+|AmU43F??3<$d5B~09LP?^ry82U{_)WYvM5BeT)
z{q}fVUnhO@Dl#W8i}|$ci$*09k<9|_CTrwqQT>#qA}$4Oi8Im>tt<6l$Ds&ninKN!
zsX$)Jh?IwOez;j=XrX+*+ZZ=D5OR#g0*6jiA7@%_kDQ%LjS6k@F6ij(u1(%5I)V|E
zHIJYpK87;N-CW3Fv_*=+q_;Wlj>ST~mX{uslEjJ^-owLLB(NEYa$kw5@Y9q?YjAsL
zy(o#9MH5w$gG5)ML$NqbGbMUW7jeS!PuPMSqc+Xm-%Gg%7jmZ;0+T`t;Z_o)(BP0I
z*|)5K6dz8S#v>hijbV8@sO+A*&>x<K_WF8hvj<&&;IjV1U4oVbxszz+!Gid*sNQiO
z1KLFeeN)TwD_52<UkW=m{*ew!r3q<K%}J`EMKx{1>fx5v_-_z*OHfc5&(|VN>N(*#
z9#bsMQJfkQ(uaS9r1o&HnVUD_a_6}d_3;{4A7f4jGC2P8YD5x*_^1<Jw1Twv;`wqI
zGh7+o?#d8`$bViDLVBSDGD_2y%FtkVI7S#7$*4Iy#~Yon!7@9KFa6$gH{@xP_6<>r
z+eIFCKLZQI9V~9&alt491{c|ZfwjZ=BJJ8r-Uc-px&NXuO@wTCcs4AGP+EomZo<CX
zsp;X(n|EXTO1LS9el>z&OCsI7S+n%5D7)?hqu;bQOZT$B4af9H_xn;9ZVf2jA;*n4
zq%%K?{qNPEk;Xai$1QeO?!|0VZlk#R0wRrFNg3XaG_?%x!Ef60MrETs0uTEc--j^T
z8#V(@=e!qx$6?>t`|(YmKI{Xd`zadnyFAFxD5C8RxH&02DUiko3a9gZIELSuQGTXF
zZSeu5g+(QPHs-~b(DNwizLMpo|B^g#D#~=UvXz!nnf>0n58;^fNo6Qd_7CHj_Qg@W
z#j{7&<?uMJCRD;bDWc47Q6|^t$B>Td^5c}I=(35+&2`Stm-{5bRF`zlC-6tQ{1m?F
zqq?N?ysrKpU49yARnz5XBoE5R>+<ljm6lSOy)Hk8W3S84<Ct_w@kp0fq3((~&tQyo
z2Xnb^Rh3M8M4{9Mzl5|@pI@eQp-<Hth5a}F{@Hr_3exm?BRQxIeid9lUT;T|qx}ea
zV2zB;jE+uBPnOe;dcg$)q73vM(#O|P2Gz$m@LSp!w<+51sk)(f-^3s3=3DrtkG3g_
z_rGmZ-$q(qHzXVB<~x!H<>Pg8^s<$fUW!fkzI}ZUY5Ml{eL23IHs|9*&wFkz>gH=>
zmD~1ICTRVt484;1-H{Nl*V57-A#Lre^jmfO6a4mN`YDb{$Fv`q;{6zZ$6;^p&+tv3
zYGJDXxnbG9U7Y`Oq(f={LcV{A?>Xn;I-)-7n)(}+gUU$p?!|8_m#h0~VOnP1(~CTR
zEqVS1-;^%NuKjH_!YSR~;qN$?Kc!2Y{`iBvYFaiO$LPK;y(cS)TT?3jDCe<^h)3b9
zQ<Qz3+}rh8j4QPF`&S4{st{x7N#OT@-;oCJeHXt4*S1Q}S*EzZcWl*ede{%~<BC6k
z>r-~imKNQUd0g=)4#U1r7jQhD+!mf;SEdOCzi(SvUBQf>@s2!e{!HhW4_5YI7Tk)b
z_tH2>?RH7AxAYf;=?BkJByYiTKk9ZnTdj@6e$To^CSJE%_td|ry^(K0bz$|6G%1Yg
zoyN%t)P?So*ZQP7jpyUp%xC!HQt^5Y56?=cxEepCSt=HC{18t4ivD7rrQ%o@PBtqK
zKhA|y7{&4DAMeY99!)Z|&u=eqIT?%au8zrM<WQ^zKa+SV(pQ^7ztv_e!*6dhPR6m;
z0mVBBe`GV3<C{Kn!(t!OzPSQ%sh&>3H`NiPqkaA~{I+yaSM#Rp`YokF<<$O7X;T_!
z;xE7FliH1ix&Ezv*5|E#_ABVKbkFm3xM7s;fjSlG=DMVQKz;Ibgr)uT<l+o4`rI++
zq;Sqz2%oG>@1GpMwH%^QU#%@x#(c=?;~w1_ZujVuZMX4rvTAE6?Q)qW6{F>YdwC0P
znVza$#x!IK+w()YPOdpy%8>V6YD09-);SV>Eo590`tF?49<B{hTP5A%We03CsZRce
z<HfU~j=6s1cL{j~9(-{+&-xx(-hB|R&ro?0+IbH~#h2il`YOe{5yx}~%teT&cA0K+
zOa0+eaY+`Q`go<{zFBxWMwg1q5l(W@SWe|tn=ymj+o=rTR317m7S$H35&ycX{?P?x
zx&(!})*kG3L+xCEo;f`^#J2*J8#eH*aYu-QSr*+dH-W6q!{3>>UrwL@Nwx@g`0Z#P
zpeagxCTv|XHGwCP@cr#;P_{+I7%t-%_fQ$pM@nnK^mBf3g#3@PjCY~0glAop+i~TZ
zMhJfHLrqccJ+QYtzWXM+<32nKq7)dmzTY}IB+t384Qyf@PYcDvdHGzl_ud1;>AA-Q
zmYlmFFgv%|J&SBTWaSa5+&Oj-7t<%pQ>cLH%DzKkGCK#0aU?%=1I{ITxC8U^RZeHk
zP#&$B<{c%R%2V~L%Wc&|F;mCl9Nj4qo_q9I*cWPJ)SjlfQo@)*?eG4`)3?7K>J#{*
zb{FH<77w6!h<}yD@2lDt%WWNN%5A$^+Ij~%d%E#npe>#K1AR?&z;%3>aI`^6zfsb!
zJ|`;ox8Qkj{PvwPULn+XZAdkzl2)^%bsgFbJ%gYL$KeS(z8%Bd1^2fD59`Ne<`C9`
zxOk=jZQKYgA2yiMp#HH0Z>~7By>hUEXDE{%U^+^zoHnITUH33@9;F^Af2x;mDLds$
zcZQMa#ZJzUyOe1a3Q&i;ziEpjbquo0R951P@WdV#iv#YxC(O}`(iT_VCB@O}b)I?&
z?~TF&T3dLDP>?dGs26%xj+PB}rI(%%p~rQ_MCSp3W_o!DWT3oC(Ct=N)<s1*Pj%kB
z)TWXiNS~xb-=?>dj?w12=zBK&z6fit;ddB6sLjN4YKmSyu3gcIZ%PlR;dvUNUoAvW
zUWqk*ZpY|D!RIM0y@h@wqK+pt?odCZ^Vp}v9m+e9UiI}Uw57GKezg5~2E9_AyO0Lu
zvvt0{>CZvu#A~Knt0gBvNEO%4FfLptvf@5Ptd)oQBiZSxNiE~!H;+_s9TJymwB1n{
zJtHZE?ds{1VC_G6KUl|n=i!}R5|*C#K$Kx==#TPX*6<7wJZrafJ;L;J7WF+ZXEgyu
zU*}-mk@Q8+^F~dUG>!1h=~TC6b98suXvi(t;j+}vLD6BD7xfR}vFdI8c>fpa=b305
zxc^pdQg0ZmrnrxEqm-~oGrL6t6rb!g-d#4f2m4coow-t7FL$<z<RpC!IencL^mSMP
zq6!Zijpfufel7BtK)>^Cd=JTwb~-G2!1%}OG30;6cs0ddiMP+<;h7!Mhv<B2kD-s2
zmfj@4>3n+T3Vmo^P4Pxu81=I{^v}o8SctGO2~$5Otd)qZ#8o4#wes^=Nsr@*%TL$9
z)5;Es9le5|wO%ZkKv<o7Do*u#>>IKE;`>c?JAQ!Enrp{z0bhigrhZMn)g+gP%0y#P
z*52o|O*c4(E^qCT^7D3yj<wE6mvyj9GZY8<Iw*1J_fGo#h-lBqhbEh*bx7wOlJjnN
z=TSV$PyKH?J`ed&o-?kk)FJ1G%K3N5`P#0ip0tdiPD{nC#C^ESYn$Z7WkTBIWnDrH
z<$r|4tNyN;a(U|@-f7r8*xruEnbFfp5(4c}8jrGa)vh2J=ntm<9$JIZzK8L8_XPUB
z9;09HzRexO4i1mFW7xhae~f-T<<G~v1Mx7JnBHl4Y75;33SW~RdTsff<@&tly$Vl+
zCQI#Y^aaJ>*sZuc?tO;GK(330(}E4fCp}@VTY4<Q^wWr$;gR&Dbv6zCKN9C^`#@5~
z<4Awd<KyXj)`x|9^7E0e@faKDCs@AVaY^SZjX0*X?zXhTS_$Q=<E;9<PnCS1W^v;f
zOkwAtUl+wJRVO~>@`3t>jU&_w2IM#D|0Pn#XQIs)1;;3lYz+E8%QHM0ob<oavo#IO
z&h~8mT4v`sHY4e+@=Ve@*E31)49}1r$$@2z3!ep<;Ez_7gLL*x(F4sz=(n!TJXbi?
z8NIuQ>TET}OMl!z<0sBr4x6gyy^zj(MDS(ERvn8t`dL(@Gga<fDS~#%=ZN!^4V-7~
zibnK%sT8j3mrD6|R3E#i%6$U^owOU2UQdS?s9<KeogP1fIU{%J!$jaRkX$c!`gn!p
zM>>0@`~52UU43p|mTX3crlvYZaJ3Fkpga_(>Pb=NiG$KmSzhDH@><DL{fM9!yk90f
zHG$g_u{wG;N9LC;D)tPEJI3~61?p}|!MBFGas?anugGU<G0{RLbAgzv20!9;2-nZ@
zLS_Bm>zwTax3%!RGO__$@8_bA>-ygdF*v;le{{{}6*A~ky}S&+$(CrmH{<vn67M}O
z-n%58PyZseDT}ynsWsE{(kM-?ceH2vP3>HL`nO0O5a;@kIByeP{aTjjh$c9!)uzeG
zAzmaHtQsP9{|=<7{p+2Q{@!GqsaE$x({y+B3?2yKZ9dj%W)4{XG3;GP7wy18Ldovs
z^&C`5>D>s|5A4Z5rCranh7i)WlDL-VdTy0qXe(U%d#}^i`$S*#Y)P`k)ZXDiq*lj`
zsdc0ux*L25dtZhrm*9J!g7X#?x9+dVniuu2<;7ebQ=d7lN}nNF$@l(%(<A08|B$RY
zza@J_a?v04q4#qhwZ#YVeFl7NdLIeRH8kEdj?=iu6dy)hvNI&7wzZFfT{=r?#`m~>
z49wf-kMnt@r4*O?9`%P$%5Uw5k4ArcjP%31T|a!h^g}v_+qLwe&&v7KKS>tSH9mMh
zXQ;!^gB8UP^_`x*RT=_451;xU{DjgMI4;E}xpI9UP5;B52P%)0?Mw7~Hpuy9_j?hI
zh2W~I7a@%PNLQ;Vb6hw2D#eGacnUqo^>ssPp*o^Js-I{Jk14((=lz9j63Rh((RYMj
z$95|oKL*E?$FZbaDf0_Zr&P8_RlTNDF7KI~F3*gO+%i)s@2?C^(B-r%_v{~<yetGw
z@O`1>y_1znd14&TojAnXI(A%rLDf?mTj4NMl5@|)_Ai|af1hNM^3m_RP(HLjo)7*I
z$J%x%><9Rx>p(xkH+`s`64!S66a2n(HlF`e9M3twglo_7e9mV*>TFIt<ns%O$Irk;
zem}-B%{6{5-@n8+>6pqu`BEAfoC+%|#w9K5oG_GH%c0k-?v-?Zjqf?-ao3_KjOIQu
zpLqRi?s-uTDl6%T^iA=oJyIHfz+ZliTGOu<_7ix<N0m3y*K6BcuB6QIdi5Q6W+q>+
zMmefBr6aXM%uVQ;*>7-udR?rx_$}BS|Eom9b+g~${Nc(p?gJ0k%YKhzSbICB^kokw
zo`qOj{1L|^Q{{t0qa*SR&cL)>@fvz<@h8N^c1k|)&*67@C@eXY$M=T(h)eoqEZ~+A
zKZ!%v>!_}vIe9*4ZOvbBPPsh1cXT?vOh?z&|H@(MwRN%wc+W`bZwS*5u7~{Jvj?-G
zUvXQN-_%FRc6C?x^XD-%!LgnvkZn*%uPD*pL;YZUnCFxur$>FP78lN_tYn|)x7w!#
z#HH_%9igy=_#^-I*F0~db4p7`#Ad%D*lCLDK4n~08ZJ-cT3>mDUUf{@+cs~;_1OkI
zgmHA}!0zFpa(%GO@v!mgdR#@Sa%N-Wwb+4-o9$q%({zVv-!~rnf&iBp-TsDsz>PO<
zTDy8({qXPx9%t};J}2jKBB$DMOdf(gLp!B-OGsvD<#>G4=M;?R)OSw6vGx<%%SiIq
z6m_*HN<4~7b(5C!|GxZw{?H12{O{|nA+5KDtNvfFw`I_+w$GFC+qX{&TaG`ft1Ynk
z^wGM)qk*f|)hXcmIl8*~|5|3ezXoNb{@GXE4{8a!8p?FR7&~jr+S1GQ)cx@W%X!0L
zQK-+Kj`UThXHZ_+=h6NtEPP`7k3L>tWCK=88EM=+8^7tiGx3*?)8r>=nsnVs`;?}s
zjM6;UrFq^_rb%n%d78>7&HK1CFPtaMyD`4gGlZ${7x2kX!c%R}!f!QCBXYHT&v0eW
z=v4*pc_x`PoXpQ~Wp7!-$yS_$aJ3by4vvouue$VNSZzvS)uoqQyk~rDYI@bo7)^*P
z!>e$iANGXuUFFi%d|^+pwFNoDkD&e5q?<f%ABXZkziR#xYrYa7eJaBRE`2S--l3`K
zP>4_l(q&!-ABW0tQPnbNtoaIYFRoS7ew=~Q#W-I-=&SR$>!WJ-rKM~?X8-<v)o_IL
z@kl)GSNBDEwO?I^-`1}n1cil9v{l>(7zRe|^?r2TtoXn9P3K*Xzd8L1=V_YMht&RQ
zn#w56H7?DyN0}z|p*&4xl;#GP=Eix_JShE&?6mf)EAU&}jkYcAH`KOQyYOoLsvhBK
zzw+HGbhOa9E`i^AY|-G-)BJp2p*%?^S|-iY$Dy{ou3EmXJEb{?eze}Dt9fhdzY2DS
z@+RHodHXn&_oixjYb5GMY39~{Hsd_~9IpQyUHitK7g`T^6#h{ES0ZikA$gAa031`>
zqj!DL{?e-`9Pt*(+R0tj$Fd{&@Vo<R4Ey^2?pb}cGu^ztiOPp@kIG2D@0z9GVP4;Y
zW1Xi`STp`;Uf+su`p_6kT>E-EeqTBp&)<UMIp<?u-y!GE39B-fZ$n&itUKj<E55a?
zlozG39n8uHooo5#grTIGx6b9eB;9U&&nZupxqQqgn=_+~F)W?SlU~#Y(p;Y6_2VzM
zWi&sWFO25$G5y2jjr8-md^~UNTz(tMal{#9wKjzDpXTyCIA86M?nUnfJMvt<dZN_N
zufh3#F5ib^KbNQU{ak(k$N5~In3l`W<p;raF25uEPUh*9Kk>hJF257!%r}?c#bN1O
zp6me4<*!AUevV=;UtMYB?jC7%uiBZp9heP$>qD~scsA_70u+whCF~ikb6$_~9*;RN
zuJ5p&3u_t+iU)yHzofA^*hB2YcE8E@RZjjT{r-DwA(?hr->fFd;a50!$qHw+Go23h
zP`Shw((k)aMzw_%9IJhxuwnd>E!>N5`j9OouC{PLeqTBp&mY0@obzD|Z<6!pgduJ9
zJ9J%hAL5cNyji|S@l86Xd?_zVV+_Boe6WRDzByqisphS=a9q-z!1tW;WVVpzGcljc
z=Aeu*EXqM;CB1lCNbzRym)k;3zgpNd+G0%qFnOaKxh;(6&9#LGP>$-h@QAICZQ(6A
zUu}-s!bz}sY~c|TC0jIw^Sv#c#<91Bl)krx2XUO+LSkAjZwqe)S6g^n_&vuK5<ikH
zq`HFUY+dsZ&Y8~^-p*mwZQ+9vrl0w2;SrT~I9vGl*n!#5w=N=E$Tk6Mgt$OO{adf&
zk*`PVoe#rz^!aLwSw0Te;LgYSm*J1X>3bpeW!#By>I-+u`e6*KDK4P=5JqvyMp~bd
z-|S29@8F|dfxe)9bqeR)jz3zbd@S;yPqnbPh8fZrgA7!LX*vPtJ|5@lp0D$P=sk%`
z@JF`Z;$gSK-H4}S1jV8A?GJJ3cZ|QFcoO2%yD+d{r-UH)DR=Fj!V5;R#?F_F^+@KE
zPr-R=SD%XCq?gTw-?vrXN!P#hx;c$aXg_pE1@En(W84owuQ28PR8$7o(bChAmVU5L
zS#zCJ2CZ+B@fMsggFljsj>#fF6X|qU_3JS)+PoPTs4J5rd&;9D2S%o+uB4mubht``
z8q0diHQo~{*L|L?WpwuU=<_12%#&BE+|+=z4$5l+l03IcUe(v$s>vlwIETryMY5#)
zNOjMzlHZP_)}t*N9VW*%$uY>d3VFV;N}fkABV|>;UhZXv%azw(f0Ezr$nVAfaDHnV
z=Fe|1$?w6)@1_4xez%f<^JlkHvXeGLec|O*@;mzWIkg|p&77x!wkNXDWtUf0$!qIT
zw--2n^W@YaIZ?YLoAv4{`5e7Wbl3bm8EsAV2lHRNwn|<{-yX}jv^2eb?L66)v;64N
z+3Tw0_rK_KhpV_PA|=}uvc3QI&&hNC3hYevO7{8n|C~GzQ<>W&(_mZ9L!NJ_lIL|t
z-9F8p9idXwd}(}sW0ic5zP-k$sLVBJ@p&rLHyV-GoByG_+(R+uW~PH5x0@#9_0}qR
z9ev-(pI$LHLwz0x$wv9Ty-I#GucNU_{f~Dd4*4I|_Y3m4i2E$3N3c{kJ~@nWe{3K7
z6FJmALg~L7X;S((z^6F@p2>S~JSz7y=yBzinGtMOz_Y)xms;ZN<5y`-7J580##vT|
zkrwTpWA_C2Uk#1Uu-`*vraf)%RXJI%zrW17XNt<1-<$q^F!EVRCel-LRez83ytOiP
zbE>3-#6C?r`XJKNI`|N!4WFFqjq;(e599ARcMtdNqDzYFbxFs$E{UlwY0mW#9NT;e
z+x2JmOs}f0rRsVnnU5)2OCLo#`jKacBocDNNQjrYw3Ow94prZDoa_4&V5D!-!4cXe
zB*D;>YCK~;|C*(rMw+Vg&rteK=M?r?{CS;IeNZ{7g}q7YgVOQ!LC2_%A$nc~wPQI>
z+Bz{`KcB<#(bf;u=jZ2(pXff^4^XYoEJR&?0cq$*>N3+E*Jj4NK1)kU4yq%qPdd))
z^UD+m^+`IUxYh69Z0}gRd9&R7G=QtFYdLcd8W9E4C*E85RZ0tWSN%T2JgxBLzdS*C
z9Yjb~{6AWYqO`w;zx>$>Nf>5(x(@R;nYVo%=M)9DFTzIZyp6`~x?*UUHvf+tjC-BQ
zCtFkuk4*74;80H#cL}o=dbJ4d7zmu=E@j@cSM<SiKrFUm|1YkHO^=Mt@clP>(^%L)
z_6?MWAD4-CNNwhuIQIIaGE!YEDoUkqaoLd(K4%rV{*Iz9W<wp54ycZ)zP~HK*F!(y
zp84*c?l!$&o_^|m@&h}2<ace+*Vf<Gx1+7Kz#jjFxUYFpiRAx2(#lH}>TmOA(g3v>
zs^6V!^{CN_n$$Gf&oRqZA<dc^+N&+UOYV1V{9USZzZcw#{WamaX+J=DG$*a=ckr_`
z=hpQP5f>|7NnQWQSX$RVW=<)0PT>jaT+cr-M)e!o#7~*cjLqOhIhsGogf}zu&`AAa
z5#DY8v;T*^ZvnIGs_H-Y&Lo*8X**5R(l^sIloHyKq-khFY3I(&o#Zz2>fD(;P`ONI
zZj#$hW`;X6NrPBNtO`Xz@r{bSQA7k(L`6hY<e~UR0RaKQCqgT4h5moPwb$BbpU1s3
zh5k{#kCSh5&t7Zoz1LoQ?X}l_9-$Ki>|VYES8ErnOX?cyHNWqZba{k}-?nnXmPC`F
zu>F1pe7QL&m46`T!n#=I1<2gj(FW(2vK=!1XYscwXov67cIfJ%u_%&-UeRxGb<kL>
z*5S2a&cyr)R}X!C6H4dg@6M#*djul?2StWBZ!cGe66(@?NZ{oI-0RIe{!79m^X}xV
ztEbNijIFSVBeo9KBh}&RiS6?9ph-$9!kt6>)^xG>1&J>ato~A@oLx$SOwR1P60$-v
zX0uqQQU@!o&U`28)ENNFW{>6o`@wX+0v@d&Wqu6*H~zx9vGZ!oGv7uYJGLaBPKa%u
zvyaKTpe=AVGFu<9ove&4&CApnD@*Ezwsott!NDdk38CEo2fX+qp$>WW9dnt*uL_Uk
zljkVbCI^$XFFWFfvi>sCG`lGBT5<Dj<cl83-Fin1%Mgd%d@E@P=lom`<{;tjMx9q6
zJ(c~A75a_tj0N%QfwMR}HJ(d%U9<tX{C%uaPM%idvEzOFV0_%ktwm|caj@5DR0*68
zoI`%V$F<r9UAd<D2`4vS3H#CMY?GV?A`fV~#Z8E3&sHaEOaBq`!1KE%W9Cn}m|sG<
z5Jnj~-ip!r$lLH6`7Yu3Ean9W^LxqKcg;^8w!VuugB@-xNf&K>n8C)DniKQVcQYRP
zGg$G59=tQ?%PwTP^me>zm+=+KvjD`s7~gtRcon#`xvfZpWz8S6<)tpwn4cor@iFb!
zn67XE7;T!96))J<6MG6LU1zk!URUU-UtQ6Ze1pRJBgWkv>6JK$=f-N?#m6A7J>9vI
zXwNJAwkR{-E@ciIz7wh>l?9tDx2e9m_EC}b9+sQo&d5!#Ge7F;WdYw^j_+*3tK`>)
z_rRb9tY@IgIpk?~$~fMkK|}LrO!kg{zz#G{oYek_Fr2-lZz)hKr?aQ(F1h1K&{ub-
z%#}fzwXQN8Ns%+qn9tq0^F>Za55q!B=W=LLUaeke+a8O&osUqEKE}pvR};Pxx7}?B
zQ`gJ}GhPq=HWiD}HTdN-C_FqD)fhej5Bv5taCMCx&OKy--UM6D|9BkI^m!DLcAhxe
z9b0Rn%=!0t!1<Tq5n6T~;CwhI!1z|q9e8J2X4{{LFwbp;zf6zmlOOl2i>}vq;wTr-
zE8eY7%JSj*Af~Yed;8cwZbv$<_-<b;c{90C&q#AEV8?I+z#MeU!u7cs>0h4!9M)pd
zh?@9sUe{7LMK^djz754MOse4NM=^~X9e!l_6x%@qgC^Rdg2)l8uvnl-!h2xbu{L&0
zKKU%U(Iyq5i;)i2z$On%bK)M{Li8lS_&Eg!Vtx*Gcxv{ZzNzVZT)AQxK5%hnsyP!;
zhtG|+6n7%NJ?a~%h`30bP!^f<qdyeOKh{U;H~FI;^Zlmao%9B$%v~FB?ScAWeb$qK
zW7(}PNxK(+)cafT%O`^aEYtz&q>q=vkw1@1=($^Cr5-Z<WEzF&shT&-MIAQZkiH1h
zy90mR*Kc%8gF2jt`#9_~b>ddUN$cJ|z>@XW5j_Pkn@4%#6Wuwc+XC1Q)v?<HnC)xm
z4PaM4)x`~A+}BB75-_DJ1#xdseP#VXUqvaLT`ov{L06}jn@y*J(l2)6Zi^d>eL~MT
z)Z4GmHc{Vvoxx8uJz!lBZhA%D?EOCUrtTeQZvi*^b0DCp1n*L(D~N+M_XTmOw-$F;
z>2Ggs`-2|C^#CCt><31f*8Q<AGdzaB(7wAl^j!NMCfmx&hcueCv-RW1$LANc0qQJm
ztH<Hp+7;}$?3-m=Ykx6aA({l7&jY!BjLyn7nzxAtgq+3PU*85ND`%5;Y+smaG<)NY
zEKJB1@zAc_H}&dtUY5_eJYUl`co+B%Q=v|CpEJvuZktuW!hV5a>lY^Qj(!35-BMeW
z{^AhexGJJg>^RyG(>@HC^$%kxkhLSq-t`4>8npR|zCha{Vdw`k{lgVV8+R8i>A)U5
z6rv-54b-PG46<}1%#rc_-z~+Xz}cg7WJct@m=It(oRw{|A0Qvr7QZuir_LChGPZtz
z@Et30Kky8MDG$qsv^D&(eN5q(58Eo?j7Pd@yn8y}O?QbSKOPt8JpB{Gt&Jbo^i1DR
zAk2ISxAsb#&o~YI(dM7TFP|(ANgVB%=K=4=-#b+ok1<Vi*wh!90W59%>jBJc|J?!1
z?0g8jP3`<W0iE>`vw$_`rkizsfp}uRivMv*!z{+Qg^2Y4$(ugu+(SX?Ms2>#AW?^D
zug-zZKP7P(&)fV^h2j=ZC%au^2G5!Lhy732zv&Zsb?*hKZ>!U$hZnmSgLkRZ6<5Dp
zgk#(`wp|AkzF7oeZ55CKb>$56fNi(^NX(PEOn<=2Lz;W>x2f0>oy9L7w-%gh?}NNr
zi7y~gc9_?9BW<5op!XR*pvO0J^9G(QF4k4zSQeiq-c65*`#9!=@^F3Xe?JTS1e`{+
zhvYG>_s<3_w6zSIt^FRnhc=b|%YA^!x`0|*!oC+UXOlI@Md$ylIJkUhg_9In`y10g
zQv1tw7TDjD@tvoxty~w?8sQzBOqcp_eN;QnJ9lx>nDg?b-4~=h&SonwXbaTM^I@~U
z5B%G+Gm>6YiQ4OCwq9f1qu#RatSzw)?Va^wcAD@VE3uvaA%sIaP1+yCAMNyW@ymz#
z67F#YcV8fJ%$IPcNxJ8UbikW#+1}>|fTtb(Vf>Pw@{ZGu>1o#qHyiLmyfY88>pzMx
z^CmpB>x}av{L!xe7=HQul-lR#Asp%{&sF>gU}^jOf&gar`Nsp;Q`Nr?VYJ!Q3Ca`p
zR`rMG){PS><Fvh{z37V0EB=JUVLWed1ATa8_JXqY@`SCmI<$H+ogkm~E;3vZ*-Cww
z%wHVP{G7h$e=kFHIGlHK&T|5yMon$(FEBmW*!;VWBt0yPgbB#d#LfBVV#4$b-M@(R
ztsE~^-ffKfGK52&CoeC-A9eoa_~m1^-{x`h={urVdiwQSDEn6+%->hxw~hZF77TN&
zUMmwFYJy0M$2RjCr0sc5^$FzD<M3|n&&tkmm6hevL^{RjwFvY1AleJt#;Xxd@Bm$=
zy=VTOW3hJ~(JuiO+Ixo0-v2V*ogHT##&aj+!}-fec*0)}=1xctpE+ZP35U(59ZuNb
zUqQY&01dynGPWBS>`IpJW^95DejRZ3=p16QsH}+uB-St10qZ!HbF2q!XN0qDW$9x5
z+6@`oTqjN%U=3AR=fu39yYAHW^~#vDBWx?2^L=B$yN=0oTZGJk=3?TqkYCoP^$+Bo
zcGmR&HxQ<LStnK=(*HXC===O8e)*VQdR(fHAe`xv?k#xtbcky@YJJ3S0Z;k<HhxJ@
zJ@xc~zO#=Y+}inD@y<M~kN7==Sw6zUK7w(6AAjs4-iBX3@6$fw%?O9O&35oRfTjD0
z-wj~aN4!0NSsxL?%&!k&^y}GgP|j!zp~i{-PT8a1fJ-0yIjjq`1HHsB?qARb_<cMq
z7&u>k6Z)1vkaU?g_iJSB^dq%BtQTJws3og^uSY9R<}44}0O71ZdzZQZ+|7Nj<jsAj
zG}d(`X`pJb`0MXt`hmZ0Haqm!N%L;}QD@(SUp{WnXs*AW&aRc1(sas}8~6Mv^6~iw
zdP|*V{}kimdG3#>9=;d&bmBI*!E{3%rLX*FfQ9y#VcK8n7Io;+u(RYD-zmXX%h|g0
z#;Us<PjAI(sH$Mxoc8-b>ufJev7qLc>utPiVN3DPfwxEJtTV->2~Gp8-YG-sqL(3b
z(dv~tN4V)6`L_4J_U{GRYhbqHZ#}%&{r=#cvNqeuG<U4Tw($c9r)?wY{~mwTvk&5z
z4|yfr<5ISfaHdPT4~KM!o3@Sr06fe65&W7S#p%ZMw2g#Y`96ks=3%z+;|Nnugon0~
zasCN^w2hy@FQ2!mPJRgCQ156PKMGjdHvVG(Gu!yd0A{u^gqdv&VP+dCXXtNA6`a4l
z7W>F{z7e+YQ<4tTq8{h@m@QqgRNl7PB%a^!b%5HjdZ&B|H{D}7>|Nx(;_BdK3g4YO
z_lmn2Z9|B3=s~!*m-X5GX~egB{!gFBx-FE=m1v_Iv7e0Z9ap-&bx~%W8fhk1;Vq{m
zRP%c%$nU>2zx+K|NH>@{ayA34nzy>9;hOg6gS5Y(X}7qKe6d!pa$CR<uKG59V~D2r
zr69d8YkHqj-|Mpo<DTlN6OC!i`yRsvN%p1q9-P3ldw)7Xd$0PDr28D`x}pUyBR3D>
z_9twP=B$MNp4l&g9`^<toKBtO$GX`X&54_5o-otrc~9J#n(_&7Pae{_B3g*cs(iD*
z>%n&-+?J(>9;7~PgunRTQXZByinjBv&o=tB4{aq!KWef=Nk^qOQQC)UNf_kq&bOrd
z(-a*xlmwgBm{1VzO%Wqe9WQ<jWuTq1am;5BrrfL_ApT+eaSR8gm*=>Y<&p5ys+(`m
zB6%P$o(H^}-F|&;n~v90QUy*(C*}qx@)H%%f^79wmaKro1sBMg-!Y*-QGg7CQp-GF
z5wOtyldc1>^tuVhh@F5}bS^wxBVoP4mM?e}M4slOz|T#L?Wj-dqsxlxkd{60d)tUY
z6f<BuTU_c>MrSZjVmd>cExNYiY%}>ao6Yi@FF+dhr>2jafD83eXaS=>ZdU%8HsOp%
z9?rwNr$YfvXNaTi^SHowq`fEH?EM9rp7rZn5N1Avhy6O^Y{eh@^$YRKC(A>Od$sDp
zxu8wg`T2mQ`~2<zW_|ue0nGaM5N2x{7YB4))1W?3p3sw}z*Z#mWNxN@FYA(RybEg<
zj}dytk+D%59f@0&Xp0rDx4qh!&iFck&ZO(r^n|?gy~THn7HeupWlx)ShXDvik9{`Q
zK#-2r^Oc(B-P(82)?-ED8`xhp*UwE?*vKM%&{aqueUq}`He9*$HBs@gz}X}B*$1Lp
zy-zQ8vrjkKNS_WnP95E*W%ByE(rV5u)8>^=cA@M-;$TjTmoehwm{%}HWM9no8n#)|
zT#G;Y?vKYWpEdR&F$1mCE2hX{(b=RYAWzRj(B`RotRIg9UuG-JUS9`%oQ2yP#q><Q
z*;Z(;cK{ZS6B)L7x+mftwtUU&D&z?^`=qUvaK3W`?Dh44+mmCj12$K$J8O4w+2gvQ
z-VkoOMSl3s^L_N6Sht*8OP_P$9q;(2nlwMsu`RiM-O?od85jCrn`LeeyN}~zF0v;Z
zsN$}moO1WSmaKid#$A@=Q`^8z0spKogR@*aR^t9;FT$a&lJ;i&v443oe)&)ygfkxH
zb}QaJ9q^_z#E}P&3v`Wkhj6nyw`qFTzdRLT=0kYczc9`n_+$TaJAV1ty2~vHr}c0j
zVCg>ODFMv-klp}h<Hiuieue!7<%9l0b+P@r3)}Ptj0Z~+hw*azj95><fi}&tx|cKh
zjC5U@?vj6dr`@-Ak@E`g^9bjQ=lW$6yZBBWk!y#d&(3fI&M_0bn&N?E8P_moDt33G
zeK7wP<I&n_xy62IhNc%cK3P!vtz!2<<^K!H^ESu;bu%)wzczEGA2%lJc!l4rg8f*=
zPVNO9Mf2xh*zRCA@cpK_#aY??>c(ZRJ>vfSW}R1q${v2g(Dtx*t#03j^KkT4fb-lE
zwu%R1Bz)U#tT{i8MvV!p34Q|D^?^(a-=1)3ErO*WP7mPs-aB4*<S{=OPc4XR&QnJH
zC-HTR$d9{*1KD2(ztselCpVq}7*cw+Q?@bMDbs_Ed{>)sm&%tk=PR6dE>{6}vUcYY
zCjvU+n3m1!Q)jvnmvzm&m!yt5qQijOKH)FoA_L0AXh}zXX006s9q)IEGII%D8d6Lj
zf_9MK?@&HWpP4>xyzw9QgYo6ZYQ-n{PSC<mkFfTbR}uRBU4YqxwGW<~q2x1pnP1K{
zm<M_1JCcZM_%(Y*SX{0`G$mno#)akYL5vt*jHZFlpX-n@T@4cnyep!13|~lb^&CRt
zbE^5iVVp)XK0|TbJJGJ>{Kv|}Gj*IrXO6hLs@^=+z?Y8dkvkirsHtO%b)0u0tbiF=
zA?I-#0%0cxaRvl+D(4wbplrf{Tvbq0;>D%2_`orm`r$oUxH9GZ)su+NeuF-V^4El&
znn|%I-xrP|hgzEFR_5BX>dkrO(ct(j_Z0YqE-<ZPk{&m`H|82kXC+QY5;s>rfgBaj
z?-BDXKK1+VWcgf1nc@XtEgk#Bd$ep1VIK_7Pd5-gIkl)la(4yrdm=Fm9|*^%5=m=t
z&lKby!g1vQzG5&kH3Hd%aQS-CENoN?hkM74QLa3@XY_#8@5NCU)@cB1)TeL0`PLv^
z&_O-xC-^<zfbP`%%<}AflFnT;l!C!3;?9M}v%<Ww+w3g9xD2l9$LH}KAWIhpe1ZGq
z8J>l_0?7&u&kf8pPT;a8$4eaEwbRN$7-rpSjxGyF*D*h*y3Blx-r$HK`3t-;2O;Iq
z2k?--IW^PZcL~{6@%h{0DU`t;J)17=y<J;vqAl>Q@8c3TQ8#O@!<_nJ@06$qme2U5
zeZqZ`#rYQeuEjoa&YyhOmG29%8~nxCs{<2*J*oOWb+3P)oj)UO)o}HN#RhH$@pxDF
z^=1<vnll<TFia9-6PIS#Mhq6V4};~k4a&guiF<4KZN_J2Wia>k+!OYd9C`eFAP;$0
zdGI}y2g9K}7*5NBu(Uh~OUr|>v^)sQlLze%+IwC*PPF$>Zq|mv_C{Hr2U#wzD$6!k
zga!AYasEB6TQ5NwOt<7+Wy$wYmJEloWH>EL!qT!NEG<jI(y}CMt+HHAZX6Gv3%M<?
zDmPa}J#EBice>@t?xo<_WGC+`JHCgqV>px@!)e(OmX;l1Y1t8$mK|YjWcP@4j&r}1
z-I-No=kIfBBfa>3x;**49DJMn<Xz>*_fUQehw@`MEkDB2@*^xQKf==TBka+VpXuJ&
zRpm#qt?jP8JlVYxJe%y~U1i7jP<9N5vST<cJHpbkBP=aD!qT!M?9rCpcdtoyYr8iv
zPj;^c&n7#0SK0ABlpVvN>=;hVj<B@s2usV3u(a$5d$eWuJ*&!Y?ROyN$?liHv&l~0
zRd#$2Wyf$RJBHJ;BP=aD!qT!MEG;|2+Q^P5nb%16tFcd-?q_N9zIRpGwYwHDzRxjF
zZm$KuCO3Ikx$!-e8^fX87*5NLu(aF=OUsS0wA=`LwB*LSDJi$_TUBnYuQs&1Df49Z
zI`C>TlXsOF-$R)(9LkL0w9E)g%Z#wJ%m_=%jIc*bX7uSOv+rM3W^Jx!4DP+mliTaT
zugOi`Rc?F_<;HL*H-^)4BP=a9!qRdhEG;*}9xb_9zxo5K%59bFC0CK%8^E*4PTo~^
zd=F*Ea40*5)3PHhEjz-}vLh@lJHpz??(6dDerQ$Md7rMGq4W2j=IP#>z_-ay-c^2l
z59P;jC_jeN@*^xQKf==TBP=aH!X9n;J#X#uYi;m?yIk|+_Z#5b<R|YcKfZ_ZV>px_
z!)f^umX;r3Y55VBmLFk{w)~#IcKNk2e)0XVdGdQR_%`{;yULI6q5K#Q<;QSZeuSmv
zM_5{Zgr((2*rO#s?xSR%@gr-O-zr8hmSO&#LGgUJn|e;pw8gM^Zrti3oNsG4R~yQZ
zKAO$dhH?zyZDg4@pO-iP$|Sr`Xmd2_`Mg&1r8dV$d2xR0N3(SybCR)a;#G(k7R&2S
z{bt$=B^~Y&*c815I%B#k@2b0e4|SK}P<I(l>n>qw-6brPyX6_m++ca~UTxmReC==c
zyfJ+$9KkKVC|f6~IY+697PpDVcR}aX&F?^VRyXplb;I|tZWs>hhT(MG5SFeR!qRm^
zSh{Wq`&O)*pIEhS)^>MxUfsMEGO@amcdZ+~hjqhnST_u(>xQs&-4K?p8^Y3cL)f=c
z-O#6IyZNbA>t^kDjoTVF*M9lO^*>t&<~vuGe+Kz+ZP$g1(HpUTu$KML?nF{@PZ}=)
zwl!zwQ^5W*?z7p6oPN%is~G*fz8fv+NKabw5z@XyX>HBkXl)-*lD;E)snX}KPnQpj
z<4!DGoGiEUj&K_W_itpuD2clV;pIq=dj?FFuRz$!#=OZh_XET{cSf&F@f^m<(sx9!
zR{CuDW1N-$<Iro{vyeys%bJ$)Yx@^0UN%l=^eaLB>9QDZH}1~iy~`{M(|kFUH7plp
z!9V6h`SjpDTh>j{>r?!NY4DwK_#4Xe4I0PxE9C1{A$pV2F%9ZRoJJDIvjcfJOaG-P
zoA8cugmiEA>AO2UpMi8(=CnQ>4%08Ji{7H~_7>e8#b1Gp!oA<zE6zIr!mV?JU4e8m
z+f1>xP26LFa~D{-@Mw}&_Nt!&EZ)H7))#*Pyp->)PcQSfhKk$&>h?u$ihdC|IoiR?
z-}<p-s5w77HtpiQEX3h-C4G}u0Vcao-02V8y5i0k6Ze`lu6$}?>8v9l{+EE?Utd!8
zs@Uc*ebQl_|MgnnxrcC=8+6eY8RvC?^({AMXKaficF7#5&*FRBj>lik!CTpW4LHZ<
z2-axpGs3srrLie`BXHoQytp)VY__p@vfdP|l=0VrYb?6Egvo;o$9D-6_8XwVp3z}F
zL?iKj)4|;N6wT+i0PDZ^-hS-ck`lN}XI$BS8#wSVJ~eluK6)IrzBqxcRQ2h5WbM5Z
zYwz8~-vNz1{EoVCsS<2ukM~7x&m7wn_87@NB0E>p86D@|Ax**UH=;gwMUVvc(9ni*
zU(8#Bd^h84%_Fg)J2Zc$i`Jql;`WZYy>Ic|q`dQ-`<vbt<cB?QYd)7{dv5sMT^x9y
zYBm<<=W5d^%8B{r+1ea7NyuIq?0(9_>t{3EUK{Mm%cJ2f{*ngv^5x;(o&2aXcdu+z
z>_MsDj`FxsTuv0Xt0*rq9iTk)An!tT`<dL=3;er%xd1j{FZTFQcIdvNcck*G*Xqwq
zWJ7?a&OK-@z1han5;i#@ErtuxvBn9M!{M-{3YX*)cVn<u>W?fRY@TjR&ABYxyXXBX
zOMm5I`4odo+rF^CeI+s9@3iz(8g+g@BE>i$KJANr+AHzrNWdf0#CBeh#k(?T&P|_^
z4fBWh_-qK$ROyFh_wz~ZrN%E@GrXns_p9#G1i=scl4qk{-UD9b3BIppWA$*4$$LR(
zKD4~656$<`hh{kRp&3s5(1fLZXu{GyG+}8Uny@?{TF2{;Xx`K2jQ<pA+N1l2zHYgi
z|H$)6v@eu1&oq1$f9@$p@6-H@mVGtpNlU*pr2UH&E$K*4TBaY;{*}_2UuLw+pv%(Z
zyC6z$ewq0_A@B6P;ygN|_owm*<1mjTeMj{7N}rd1Yg{q1a_7b4URXX^oZJ6uxFjzz
z&U~tTnHQpu2I*6Faru)t`fPbPlRstCT9zHrCxU!fr(s%Yzity~S>L8BrdvGE=i|Yz
z`;?}6pZaw?cbxX?t^|#CuyQ1Vz8lZ~<oR{<CH@@r;v5)(`aXXNcq_l{uYnWaDaUX7
z+YqOI+us2uzC(`R_JK4m<+pth_;!BVha7&`4hgeN{{UFpm-{ea?R>e9<lxPh`$ynH
zpUj1mKH0}WllI9z?qCU@Ov}@cdtb4G(s`id`JX^rl{=E%cRUHB+yGOl+3l3hf75hw
zai2uIJim{+z%!Iq)jYAmeEu2qt$aboc^vSnQ*wTq<MqqnAN~vA_N4v8R_B%9gg%u1
z;J4DZISxhZaYtj<`hP=t_1h`d?CjGsw=K`j!L^;aVQI>JAaNoA=}pq>g&Hsa7Ldgp
zeB>^Cd*?qAbuITeB+ImKU!ugRAib)|1VQi4WPFtg&s6X`blad<@GT#FQ9?%9b7lV<
z-_&_J^kD<^;WM#51SWT_Dv^nz5_ssr=lmZi^J&!kder-a*?P|~o~r9qFt6$}N%*p}
z{zot$V)dUtuXeaGH$LIduT<<XN*3H}^J<?%IqY1|=Y#hz=)0Xa*?<;aME*QC^CiW7
zMC*h7Grilz>1Jbr^BL$X<FPHzP2f|=80(k0<GP9fzK>}5F5a{m;>YX9>*xZe^}88N
zdo#YturPJ3fsxVKYJ>L(b>Qp}+rdfy9Wl~v4bqab!{;Y0&lOz~E%9)bfC;0Ia|OKW
zXK6lPMwxn|u_ix%qz9|y8$<ZKVDT%!*|R;$3R7w_3r@=TekVKTLwU14o8XJ}xf$&_
z^ou_Rcr5o~^f2P&pV5I;9UC7VJ5(C4ltw0mk0i+RP`JwFyBlpZ9#_>Shf3r7%eBhL
zM0tOCoC!>%U`XMrL>y$$e^e;t4fy=CdBhG?#s*3gC1cFOh(kSE=XuIIyM_3D)rs-G
zq0v5zZ(+pWfp!>|!)k|dLVCP|Hveo`WpeJGx%o3PT%NQ5sNH<?Im%m$xC8iDnaqgM
zepf7{<=WIfE<W|poI2rVyek^;`JStB^V>Jdcc|W6L=&sepdr<#PMK&@V4vRknqL0B
zHAt^o8Z4K_$4gSBlOe#Tae=1MQs(`oe&YkL60Z&Iq_5BZ(j@Dr4Q(Y(x3X%w0r4cM
z+oU@br#rN2x&iSdsoSJ`AWrwds_6#AlcdhqHB?D|X>iE5ZV5=*ZRiL30;UmIjlOSm
zG>E_uVzh48rE34^Kshd}1SO9)vT;^}Dh4Gv3hH+JmnMSbVMEHGZ>hr&NoA-!Q5g>6
z7^HnU`iH8Ofw&wJlybDm%dA)!&Dpv3Wuo<p<1o~|OlIwpacJM#muYA$k&y(YOl|6O
zXzXw*62pj<|1DCf!<?R{zZ3u^&zAZyQ1&(huR_Z{;R$MM_}&@3Zw%fy2k%?-{r&6Q
z_~~lt3Qo(}L-z9w7o#)d`hme+9J?C4GluUD;p=1gO$J{;I`}pezN_r!=X)f4%!lC`
z0pIXp=Gzr53xN62U+IcwJ${?R3xIgeZ6N;K5-F5N`Y24p0Uh7}0_VRgI_cBtK>0x<
z0H)I`agNW1>68REb4)VRv>m_4=H~_I(sr;~ZM3gCisn?V)zq=5iFpvYxpFK{bIF$Z
zv5p{@vt)>2%}egLW%wh)@A1ZLeW`)Z3Q8K!xtMVlmY3C+TQ6xWOwTqJW~P>=B%No%
zpX-W_!8K&cj=v2;N7%91c@e#XcR4s<F8u|GyRi7IK$b4Og)<K5;!&r_$J{+}9@H(s
z_%Tufh2LJsuXeaD?s<;R`f{P`cCb`e?9!l~BHgKGb4u@s?}#oG*z}a0?cb{5Wi7`=
z8g6L$FE)I`rTG{Qn|v-Yyz+gihVA=iml^(~i+{O>p)DfwD>MvEk?@rork0paUZpUn
z0ZtZ=RoL`dmu`=xLoKlOrZBGw3g4!1Q3i!wW9gYfD15uZsR5Sm;{q79!r<2`e0G7v
zj?c$?*ck$)&aP9~LUVrM^i)&It@<O4ojTm(^hq?1;R{^Yx9zK4*fn<Lb&G@f_PtGM
z!Zx_1>4fc@-)N*xYNL1h=V02XU0F&Frj6RclrL-45_gA`Zvoez#yYONxhhnCpXlgZ
zLsppO!D?i=_eon`utq8AU+>~sBNEsR3bRJUxHl@yH2}wN(ZL}0m^a#gjwOX%@WFA<
z2u%2s1Wp{sedvFJj>bC303`iM%l<AkUeciNgLWaWaIeX3g!xCC%|DLKuyhn{h&rR2
zh|3*|RK{`LcXP%M!h<k!V*hrt=JS<~|G#|~wuwNeX1y+^`=TDfx9-b&1^<7iPs!^W
z)@sZ1?C@&sJKdHqbZyTGRNG4LH_%31yUpu&$E4$B`}x1pX4wv4pAv1Bb1&$t&o=AF
zo&6MjiG8KCFT^$kpT+CrH5yLXMuDyF59QgnwEfPr&w2Lv8drzQu40{yTC0tAGFUk6
z8oldV_Ci*hqXmG(2#9S=+c(;dJ+N<22CY3}-`dzHn=ASbG~}O#(-!U<yp=Wuwq-Nm
zc1O=s2wNeYyGv#V>^T3zIi{zA#_&wD2h0%9x}pbtM}WT_24xBHnUBnq-0#*UX%iXl
z!ympA9hLCQhijHhC&tD1e_0w2tS~+IUAQvhF%H)<EzYKmSYgogKqvXyy<i6b-x0*G
zw1|JF#?Pi5^K)5*Z)X&+?gLu>9@O6<{2H&!i)oAi=K1T2`OCvu-tt`mq&uqVj^Xz-
z=26eVoZpjivBw1$T^{uV#^<i(dh=`rH*PeKPjNn!xB=jxrV+k$kD1aKM%j<oXY06}
zCpsVYVi<HbsYRcN_ha7$nB8;6yDd5XJ}0`iIIj8aMgE;}EScKUNiy_UZeEOc6ggeO
z{Yzv7_57!o#dY_~s*kKYt_mGO+Lxh!bNfyDDkB3JS5`*$*AA3R1Lg55c_XeE1-Mdw
ze|c=8HjDv%75Nh15#q~7CdNy($?+lEBNW6PDvj))EbT9Aymeu`$!d9gq=Z=lm*)Bq
zH&&`v508!yC~iZDn=IAFDo4sgRhM5^3fDh6G&-*F&Ixg&RoSDoF@%wa8u-I>Ez7kj
z#A&(9BbZ%*jI8XNLz=PC>O`%7bo5}QY_dBygXg5Hh)?o3FT_)7D)aM0cm?wy3hxf#
zgF~hLHOjX(F^ZAlo#p-sqq`ua8=Dw+Wc{O<Og=K9^4Jp692pp|jgD9LS4M=d3q#z%
z=;4u}(bB+JY2tv!-5TP@M@J_HM*F4KmCuVpd}X9EQ7H}8IPVkG@x>tx9K<6>YhDW|
z|HowUUK5DFB*dfA%Hw0>l`3Y;2b?Zk8sby@T^8c1(7S2{gKAfIwW0E%GW2&h_DG@m
z$emC}&{p8t#>z~`_VAtr2o3Q;+so%{^K^N(e#+nLO+NwmlzABEUy4ZoY1+owD!Z6V
ze<_&obMu3j;rtED97SW5f#GVUR-GtKOjc_nqvOM%*8ONHT=}rnWib_JY`i>F8Fq0x
zQn-Qf(xB-_X9`ytK_%@UFITm#txMs{0~N1->r=S#@}UaY5k5Dha7cA@Q1z-Sg&VAl
zpm@$EJp8@M@{LX$z`6+Us^1{@mvf%xJ0Z&?)uGbRq|7}Y-jjo1ojtHIX#+*D$e8UM
zr5&9d@AvK5Y@yJgIgOyrflTCVc2IERkjA(owM}%Y&I!J+jHYG{OBP~8Hf9rr#?Z(>
zC^Q|jjY3l%88EVt#%yFZul~{DvC$DU7jNIqW(sX(1e!H8ge(I>Cx5e_>3jo1DTCQm
zp_{BSsZ#%e@<9LS*io}jW?O}(ib8;DynNRrHlBzq&8`Z*e+V5wWuSDZR2eGu4Ot&y
zwpD1@Ax#_|E5}5_i`iF~4%sjx6ce&tnY|S{shjFinEJ8ucxj?C>TIIfUZDZYNeU+;
zv%7IRlVdcUVcnSB6&i=O8Wx_-_F6tc3W7J=D|j@XiBa@&DkGDx*<Ve=bz0hv%<c;A
zP<gyESSb&*ke}ILp>=sU1sNLccam}CHd`!om^7A7Qu8xAEI0}SrDb*pN+Sb9Xu*`f
z*<+UvyQz_hfl3uUD!Pu*k<!Ej>Q2+UJZwj(P8k02^4RG3gq1<*t_bO5`JlfvBKkdo
z?g)z*+Mccq=_->W2S?D~#p)q4zbd40Et`FT@c!5kH(omI+0gWRLcH{I1DL^$?Z(w1
z-uW5h@RYoNwJpSJ7lkI{ZS6Hl{P0+*f1)-vI#lUDT7wBHR}PiE|FAttOIM{<og71#
zP_2SW%KErG8gw`1n#xAydu>ZPR|u2u<6F{=mqVZBx|Vbh+VGe!?-N?m4V6pP15zhD
zTGG&3?jMJPD|Al`=~QM1#><1o`}GO@O=IdCOWYemTonR@qM8elmivt%Ev!nlQl*M#
z$k`U26w)Tst=3?hM-RvKxih2{GfN+D94m&dUG7TYGwsTZp_FHLNGnPVUvX@xR2dnr
zREJ9wXn>+0H-&U#lYK*#Dmvo0!LST_LK-&Yq0&*heleBf@8*!MS{<4^QbW_jLR$Yp
z6w=Y`P0*CbVY0-5PMUj1`{V@eNM&%aJWy-Vf7}w%?%mT@L8~zbhh<3M(FK`bbZZz7
z4Tl^J)OLyt_vPYt3GOMmxZQ%gEf;r_;GUX`+atK!b8$Bd?v7mCUcvR|;+`zHQZDWm
z!S&_hZWUaAF0LfFfm~dl;L5qUe!&gq;+);xpNn(t`amvjP|~dA;@q8~toJ+f@v=Ti
z{K0&@tWy#{l#iG7$_$=*1+}XjVu!?U@obPeb^5YT562wr7*k^og6O~Q^J9Y%to&oc
z5L{jx0~I2Hm50j1>@lSM799+I>UgDZGVTXE99%|-<g?R-`{}#Xs_d}f2x*_TPSZtC
zI>BCMusn{Tv6KD!5T|W;gM*=c_0v#dl7SuZ_@qnJwcRewZ*(~3^&AJo=xtJf<ZELR
zR-+v-zBZ+BgX5+B5>ffy?C>L_=+9Ujo(bYz6_ocgoV*7{hk5GNZs(UlUI2r{krwxO
zl9wnNC|COratuBKuUho05W@y1NBT)1@L~+d45EOgK00DJi$Zr==sRP0Wq1tTd1azB
zHimJ&%5+_fA1)n<<lGVOb7fhMX<3vxuQ|po_2&JmH-%`dG>&mIyra>P3I?B*r+Il|
z>?pXw@d`ZNA@9Fq+$eCU#pF0uAeg(rxKVIAE#NB7>y5+t3RO79ixQ_a(tiLGHX;{{
z69p!7F3{^L{123;gxVH7#)^U$cT@0+)ilphJf|&cgK!~)NvCTY6$iE*Dwx~Yq&Rkg
zrdOL4CdOX*JJ(<sRSe^Mtkj3|42J0hi+jGpphW0P9bLD=yc?}NUtsY~t{RDHZ&6$*
zg9{brC4+RR)0hSpJ(z(W)VL%^Nx?6q&dbb23P^ouH+R8(0pZ*Q=f;c3<2cf{N9QhD
z?%QdXKG!qD^f~{@^iO8fhdB!N5-|kk$9;Q5)2hM2a(+H6lB;jbb^^{xlS;qUOHp9(
zmvqe8Az?Zz&e!2NKCmTnyxX-WB*M1to0EpY0ObCko`-%6ZT6SNDq!e0TpsSjFh}&G
z5CymanB@r=W<fhXiy^*Ro}kZUbB!G-oVB5F9M&1qU?vlOnV(Z!7vi*+pe(6d>qDGl
zaS)?z?}Kd!@w7H5FZ(LYZHs(noqXcLc@f1RNa?{hdl?-W9%8RVi&wMm$?7V^Np~c&
zD@Gw4W>O5hi_?+7nPi;IJCnEx^DEaS;A0iji}eY(n`L5~+Ms2fb7dtns5{sF*lb`3
zWO?U&dD#`z4pqh{Cgb@!fsIXaax8!sBZ0#h8`#Pya8+Ul>vXhUX{obzkNtw<laUfi
zYXI{1S33WX(@tgh6XRu_M@DDRe*oRI$pkAXihmlqIaU}PmcSnX&x)tjtjW-x(WzS<
zNnDj)x#7US#yc$2VQ?k52qA{b^nP7TQ|`kw^VsOv<k)a&1T*#CCs^-k`Y^9>s4|M>
z3+BDS!yzKh9o2>p(#w}Q6SWQaK7{f>Ydkb8B`?=F2H{{)(mBV|SdZ6-*$by%8$HgL
zuhG&TDj(6wG|gv|rxOPaO^;)p%6`7E`y{{k-l+28)8ZJ-ruc;BTu%ezf+1%h3hjd|
z4J&A}Ea&_92PP)Q{G5BuCf92!Dyw^Z4_bNRhGbbum>AXN2J(D?$5X|tC5(p1GkV4T
zgO<h?PqV*_ZS3fE(Xq*bfb`DjzPPXwk83aV^b@7NJ`At=#zzm+Z&X=s^>`UHid-)8
zFso}7FZ8sAX<W?M3EjmRx}oxZY<tCEd{`zz0=<5WryU%{G;j?P#}W~|JvaX@>EXM?
zDj&3did1>L)WeORiSp10if`4TbeDO$!E#x7yxhZNEDUdXY*Hd(9>m(k6`lsJ{W#g5
zgp2RK)q$lzvCB=^0Cx2}MKF%Ml~WAaWz#Yac;_Q&8{X;tL(Iz}{qm8qikl9tNgvF*
z$I7MPxWTtJI#`q8j5GNnn-0ax$`j^0Z2ipiqBDgLeff2Y!{`Ey!OiQe_b^lzX5g%U
z-(cyKMtq~PJh~Kz#U(75lqay1==Jg(#lg9Blhj%#8)LXO;_`q<S@D}<yo-m$Gc?4p
zF{rR>$4)Mir%*Usac&$>42ki7UI0fUlQhm(n51z4H8whabZ~SCOS3Mm?l_L}K*gMN
zW^QzF5R>@ggR<|!mH^R*CDjMvZgec^4+cQie|)Dx|0tL6`broi3{MVW$cHI1%%H*k
z(FeeixukvC^*1qb>;w4tOn1<)Im1=#pEyG0#<&neOit~%vcV5Z;KI3L_&5$H=GvmU
z{;<n%i8OcZHC^a7{CIhI6m~bvv&V26SMx+<mv*n=p^Y-<v&-?il7{bg@Tj1C8vRWQ
zFQ(vo6yB-ukx{f|jO4x5clk$MsdzVQyzU_0B-CUWnmArPV17o_qj)U7vIopfyEjgQ
zjvqaNp;6a=7gwSc#hM{2m2|w*xx$?U$@Gb28z9ctql~`>%7Z274>$<dp-JcKRC-SK
zh(~VOYqg_eqkKBttInA_tw_t)>w!;i@18t5uMZ|0tWUsM@_rBV^!1MBP0lfhgPN-U
z1-!3+pBE%hD^+WiNiT<tF6?!6$Mhr9hdBQDFp3rGW(Vo47RIWzfuSLsb=iPjC$8<?
zt8GsjM%?Zs$Ts&P@8=zY5k@C+)a8$H(L`-z5~;cJU`#YotGGEyjEC^<<{3NrKJMPv
z$-A2mT+er$9--Vf@LhTamsS_Ua<amO&k?*0uN-V6VOYPhG5;os!xJwKznNi-vg8b%
z>cP2$*;0hU&La#H0Tr%>E3BKaiko}AK;j^vxGgU1=j<+Y;XQ`mDsf#IFLJnB40o~M
z;`NuuIK1?|l*1(q9~#9JoGZhn48vkpq577_WrSg0hJ`O@I6m(se%uv=^}7RLO!rEL
zxkCcY2rB5;bgm-Yoh*@fk9A==HNtq?8ODMHchE5WIELX6g!x}f*rWj+-}qAZgt%yO
zddI;^gvmKR7w%&i9(%boENS<<@F=F;{QSp2Oan(Qxlg5R^f5-tFi1G_Nzv~oyx+~^
z9*}oAB_wew45J6(It-Fit{k5apU?CFa?A^T)GhS==vRgJs0U#uZinw>oTFR~k}&Nc
zAZE=aPI2YohXJb$(S_7~7?PJlhD%j0WJr90)4?GSx^XSq?;dTx&qDi!nwLi=hh6K{
z0NZXnzuR9KqjP?+Hpmvsx`gcojO%Sx7=`i(R&pI*0v{<K##)Jr1pXU*2;IAZxdg-$
zXCfC5dkj2hA84%MO7y#RdCVaIj)_~$S|eR79lK><Q0cY;EX~LSuPZa=6+mA;!k%_$
z5VG6Pg)j9YsaK<uzD;0`0ko4NGRnY?rcxi)bhQn^o|7N=$4CP^Zw-D<8V)7q^p7xs
zxh~!@#c$hlPW0LIeZbzpP_4qxOIGG^hu7?EZRgINyPVKlVNnaP8!z@_c@%d4P#=oL
zy>J{|I9EY=MV+Ma7^aQF2FQYUZ4mS6X5Ut!wYqGZUTNfL#P9RjT-AN9FW8UPQyPMg
zS1TWY3B@j$cmW{?=gRn3aT)u;XmtVu;(*uw8m6=RRnO74_t%E2{TMfL$C7I!geidf
z2|WW%DM16>g0nX<AW5q|hF&4RF`pyjLU%xSl!<$r4jn;yV}~6Zu5Cj%1QzlEy<omF
zPsKSA-hoUVSkZnGNkXp=#XY40*xtC8RQCVh@Ai^%|0cuF!JnPA2T1mrCUNd=(0p7W
z`hLuz^0B?NJhQ?5sL3=6(GMaYK6$t+FLAj1^O+ScTEwRsEQCU_OwU8Q+#kyK2mHI+
z*ZX{g^YZ&)<;Ct0;=a<o;G28Rv-BO&3zXjOa0=<UFF6~hGy2g~oNXv#7%wl*i!_ey
zi{_s3e0dh5pHNzpJNJGwP3l8fuRo=9#4-OE7w<u~{D{vlPciygpP$pC2Snyh&OfJl
zbLGg==l<!R_i+lMd$xc2C4h5Jv+@3mE#kja;|uSJv}4|F|MV|_miwn)roS)8ujxGV
zVj8am%=3r+)5c#O&hobX)34HWUya}QU=D%baN}O=2=<Ztq`x2UxK{ytqTL~!2EN^C
zaHxpF`>|n~-vGQkx*zmgWBB|6&ax5y1AwzR;2xm;Jg-RD4*`bjf(RSI<u(F)E?_+l
zR^_D<r27%TwmX=$5`n)E@ar6Wuu-3#q1`9_j{$yt03Vs}_k8>~a65q;TV6`UA$(5&
z599nKaJPi%f!Rfs&rbt)8*r6Hx!IE+A4aowW&Ro9dVzDY>&G<%cK6cd(Tjl_Na2J_
zEd%9#z~cvax5xZh<jFnhuK+GM1%-X;#ppGFg?rM^gO*$vP1-ZYHK2>JNBx&T$LE*v
zi#_UAt@^dyAPhV7dfWp>+a5)e%?2mJ&{t#iu*74nSc=BXU`6`86rOX!STn|?8$1H%
z_ax&_PGH#(>yYM87nAA3Y2pqPNnZM?juhT4&AI-hGl|0{nDPjHN=tiP67QFoU7wZU
z>i~9y3%?tZacrtpa9wE}c3Cs6bFy%mdX#Az^))soX&g%X)J;hocBaMU-<-r%xrE8-
zXsmdOe9lecIqJZWVQ|!Ba9$2xVr$+hyw;y=qLK8^PsXR566^RW`~bKAYxPU~?qq!K
z{u7y9kc7K(sjRjnaa_odI4QWxOZWTmo=kqzm3_spK)=mHWG!d?MuS4pA&1@YrFcG!
z{aF+Z%@Zc)#SrR@4m2#xGl0Bpa%u0Li1)dmb*%qY<mJ{=llQswdH)QKQ4MP*n4NO%
zLBlt>v3oIM7><{gy+gvFM;_t2=C2_i%m9Npu|%X{R}S_KGdx>zKl-9XnUee4i_-q%
z{q1&F?VA9%N7sni@NHDjvn*gC?|y<%e#yK(ijE>&FXo*PMby)8Wb@)$M9cdp+Lh;D
zQ+e2a{WoXx2(AlpcZ)n7{6x`n!BY5OdOWz&C%kkD2L6U+`O-sh<(LEZCS$oeIi9G8
zq4_goQ_UsRb*Nt_P6|-&!hQ>Qj_)$l+*BWli*V}_<2qfuYk6wM#pRtu>!R-UzYQAP
zGo0X`&NC(+!Xkk=?#FL&|Bs*F=;LAxqbDx45hzmN{Y$@#{I-EB_{I-DOUrt-h;n+M
zfg=^<mEmG^d=P!$GH$987~^zC)5mzo0+$u~vllL{>7n`QdpwLj9L@lq9^l0WDvP%w
z-|nb+VsT17(<1kpa8J$eiHw8+-dDATyLp_y$1~$>KbsJr?T7vo{e6btjz5kkeqYlz
zADeeekl)ZJkLf$2cPRa3IFpC9-iT-Z==)kco-@hjvo880jo0%26!wzXC{h}hfg<ZB
zhV=GIIo^phIEHAMhKz}&r_k#40Hol~sl7|nxEB0V7CiIJGO*07(?0>8<BNCWkMhfw
zr7L<5aC}U*p^yEiz%dTJ43isu>_78y3Q`~DWB)nep^yC+E#m*B#?Pjm^|9XvTKd?3
zrN4iTU*pw$?7s!f^9LW>_+$EMoaJpk_WL#6zr*iK&_2>W_8$OF9~*wK`M3S}7W@+R
zoc`<|0uPl5@#6pfG2ryI5w9|^IC`8;wE3m)1&;o9W$yI+J@7~AH~tM^{*EowFa5^9
z2Q2g(Iab{WKk);A^SSR*@e}Q4F0lhX4QNR_n@l|q?Y`|3`jDp0^tF$XnP=a*Fod*k
zR9kYZ7`hV}Ht3ZgYCCzKNO!bQU6KpD9+G?JifI2I4$|Ms_Mg5<L^Dc(k>f)Tz8ZP5
zkH#&gN2}Q1hyBRB*+~4Dg2C8J@n|0EhqOh5`@;kd-eGXki^F9;tEP>fbw3hk8taS}
z2LcZASR=hVO@F=N+;ptWRdYST_PBf$<wYr7qJEad1yLy2_(b1)Oa@kJL)o4?afZAf
zcZ3X{a`%_?pdI6EIzeJ?Id*_ViXRK)x|um<ZgA3j>X2zWz2G_WP%o^n{zQ<z>cwRG
zF0#G8eya86>3XxYurS-0md~H4Z#C37)|_gd4G}0S&z(^>=o^00$t$3cF&nf(_K&9E
zC=BAaD-X}f=auK5v*q!3HDM7L2|x7U-M&2ZN5!?a)e_Y?4<8uO`CvC*657hxp*>P=
zH%2m;^E2Jp$iW7%my!Ol?Kk>Y@RstAcRSTdLtXi~zRZ4n8|2r@Kj!z#in!DB-!tVt
z8oEz<gKgkD0n$r#;$>!#^)W9K9@}vfv7Cy>feI|@@m!d-$25MRJcgaG*tZajEz>k^
z=fwzQL7k>Pd^(T?Y-wL(ZpK|8nloz1;vLVn$1>-9Xq!9ULYXFgX5M9yr&FKJ$hH(T
z5qG!Wdff{Wtvrm)JF*8XvClk;42&H#x;}-ec0Xp0@ov#xH(6=>vbb1(!pWzy-=}VH
zS#Q9~hS@-a+pZQ@chF5`4f|lYLZNFR|J-5lkT*9sOgs569xuaOaxLwo`|%df!EKMV
zttUJLxk1I0$QwxwyE^<GuXhu&9aI*0ppVQKwqIbnG-q~SV8f#WlQ`%oFxY&7Nofa5
zeot$s!s(>Rj#W(;c3<fGN9Ev)$QbrsVA$MUvi(CF6gD}+$qmO-m%=!8&T%5|SfxIH
z&Xtu-hUxgi8UUqjYtLx^^K|bES>4OIgEFJj;@Zb!o!KGht-G;D5j=k>o$eaP9#2!7
zME^6wH~^QaoS^-Xyrc}x6TCaAF+<O2ri77#j62+YaMOt}?#7LYkOqBbBvJfIz?<AB
z5_{Q{YsT*$#29Q3?r!EiBtowv=Nto=y22aUskE%0Phk&$jhk?@h4_LNel+gkqf7Pe
zyNulZGFwnr={x1v1^{b$SJ}7kGU5e%uC1~CefusWkwN0VInG&7E^d-N|1KlWJ>3MK
z>8oiwlW#Y2%t*?Q+L^Q?FHk!oL#Wi<W%&Azznig#CNxUkU50s1kM9+H_U<y=F_*ay
z6X|5`!=$&l+I^V#I#1$0%qVpqCi3$4Ve;-W<b!3A_|ChHB15}E&*|o72eT{mT;Jee
zi900O-tj%LM0-cr-%ZH&j<COLi+7hX9Nx9n>tLDt1wog&Ul1@8lJG=-FJDH<yUP$S
zbKf9fnfnHrXL#Qr^HX6-e%Cu0n6LzPgThQ$>~C&VSa{!{>u<Anm!UoqcbB35y#BcP
z!1x~5Z7go;?lOi$dD54Wxpt<a{W|+@(CLL{u8wy&9us#na!f|KFsk&ME}XbqlIzf*
zaTlm*`qvmt7;)+I?lRCN^5k3><0??($Mz0broF?Lf(dYUmmP<H@Fe&L4})hJ<F2Wl
z=QR72_pme7?rprf7M||Yaa-ZB<ljACH*YztrY%&OSI)I@E{AiKHc!fZ3)B(&>i}=0
zI~Q^b=VlpR2iykCpmZw#VHzxdn1;<yhVeFNJf?ph({IDaIiSr;W22^V73N7X2QB+9
zm=^QqJQ#oT<F1c3Yh2rhLE5LlU^5=m$mZ7>otKJ3d6CxSmKUd6<79D#=rryd<CDe3
z^QHOo$dxiac*YYJ)rtM$5{H0Zn@8S?yeU`8_#%A|%WL&?F>qNPI-|$5;hkT&<CBe7
zjCQ+@5BV0ld55yiBVV54fpWV7F#F4<)fru>JlOsY&Vy&^3ejU*@>-1Eu5#vlK@_bN
z9q0Bx`tDGYanQ?goAPaYTdqNv`jX|N7;X3bx_0xx3gz$CI<5tdaX8ayZGrRdkN0s3
z($-8~PXK&J5PwID_)paM*|cLlvb`<WftK^`*X!>M__a39yqLz50Q3A|-re}i!&%-o
z@4i#h-G$%R=j?4+4>;%D-Odc1Mn*rtIrlE$pc2vOLVZp#0^bDq)*z1i1ci%pE^wT4
zcX1qsX`K%^_qlL?$Hctb8*%|)J%A0*pRVir7f>#pEx>IT`ctQDzs-e!T?g2B9h08A
z2j>#NxX*<RFkC}po|gi*6FA*DqG*@*Wx(x`wB|4_Hk8ZzD&V-+1>XfTws7D0qO3Rc
z0LQ&9!1d2gEy~&)^ST=FUI&*Cj`cO%S{`wa18#sge1VmHIM*R=1k66z;b3T|fQ9Q2
z+`odgetYDO#fz{maTDnH?7=Vguh_le9Ew{&+KTmmY#Z=H5_8`4_0T8dbG650e%t1s
z_iEaVA^o51oz_u4-;uJ-^X05zw7mPj#rkscn=xU(*>-_B84WBw*lvB9<>&r|aDDk!
zl(W_PGI8*)#AmvOued!ky}rB;G+19wGD6djUFqo+=2SgUr~I1k6VYGg%`@GWt_RHd
z`p>HH9ffX}F8#W^bZ^h5I~iQwC*LF)fqymv|LjTNP3CWc-49_E<$s0^20Nf<-Mr)5
z-%}7>>V+nCMcMIVSI+nmcOYlRkI=VO$B+2Vb7K7X?e8hLIfriOGUg#t%bl&~zAhB{
z>2H5e0pCme_V*Or7?|T-=ul$3+v{MN`3}%!<~snhMlEAyj@e1~t?)gC<M7poF-KPl
z`j1umhMcY<JqphD6?bc2vA}LOm^<l_aO=6b^xO*9^uxJ5`T*fv%Ub7E_>G(>^^F{)
zllVqXlw;HXx8?*nz5_p*Z{%>ECj3SY!kKU6q~{VhKtCNU`;8pH6W_=|dYNzJ0G9bi
z4*5ubBL^^>Zj*Mwc@V&K$l=-^$MphpLkgjzO$V%{O$RP9ze$@8ol4krhQn{<FdTj(
zNASTnau}Y~IsZ#Ez2#Zgk6fzZ@EbW2Klnxt!!Q=&4_u-2FccELQo}S7HrK~*<S>rw
z)txLJtFZ7JIi!)vPMyQMT4}r{D14j3(>9&)y+SDMcBM^!BZstvi3TX`wMv`*Mh<Cb
zp$6eMatKR*BL{Wm=P7$&QxR@C56!(Zz$fN0({s~#^O|d&!=z0|`Wc%JSjMK4Pj%G1
zO($L2rUUlBK4;DS&fvp;Z(|OAeg%Ghzl>#)wm4<H+XrRb6OX32l||+^Q{#Y^^F3UY
zFX47STTQkw1`nJIDT6<oHyiZtZVqQZ!=QN{$`;OvGF$<U`&AF%mrt8BX#Ml27Tm-g
zw?Q$ac^~xo6}yN0yUTkRVa~yDPiUCmi00R_yu8pzuG7<TwS_g$F`rMd`!0RAxh~HA
zkLTu#9rUZ^i+T1iTMZ&tx6gGl$oEiAzK2`ndqnfKxlH!Gw!b&r4;#y<GkTiF3CqPc
zo0VrV`pz6$w&gt9rz@@PO*THlJ;pH~9nmwCejDZlv6oQJ@sWS}6Rr03#_=~q$27jp
zw_Dj|z8gI9H_PX`Xh!4Rt@~{X5w<6d9xUUe^oX5-C>o6Ih{uj_6%qRd?#02pkE1sn
zuG=wOR}PMc!g==zSd#rQ$B{o;yh|jpLna16F&+%dbpml%9{$k==auWEmdomO8|3(W
zw8boKF}ho6t*$6L<`JG#jAh*s&8FzN)@k35$)?{C&82v;y2;WOqXngHV<WJsGByzi
z_;%AoT(eJ$`flZ4LO8z-6r*L$)8?aT+sGT|qvLWHqBAKv+Jrp1vne{Z;XJzU_H@o}
zKCnU?>TKHg<iz2e_<cT3L2RwfiLU_8d1{OQeJ$cYN8_jY*@Vq$>%?azukL#}-wRsK
ziGRQT-j83i@yv^9{2*W^qfM9-H~#W)mbcA`|B$BpT>S3C`M&gC^g96$_M(@T;Jk1i
zcNB24s(aL>&mepPaL$JVKDazLjp^oTp+5>Z=fVL$G}RQa%%6V;;K7+sKZpEXfcH3h
ze2<46(dhBYsfAhDnTvMMylSA??r01(I6H++U5cLqo^#~LGqWFl8aU3C+kSYaR|jmT
zqaT=`UgjATw~<)WYXHxAa-=sfJ6oPxYMzy{-2*u1$N^Vg-P$hGJOv!*$njkv9CN{@
z{NehkV|6FPdEk11bL$Ni-e@4-XJ@=;0yp5&9G+ir^X;brJK$jb^Wd#9r^id#8kNU;
zK{Esz{bmux<?HNOz>USYMEyJ)xQQ6&>xlF7KLA{OI^CTUcphNk{QMSZ<;C&*{NyC~
zq5ZfNbMy~@me2F?3tLT|a?iPs`2Ci;4HGv`;9d;5cF62`!S;y~ci`aAF#2ou0oViW
z_K!Mv|0Lkt18IADe*}5s1f}eL1qqE8?oW#WwC_Cg=k|7vRVRJMmOf#2e;^~)Mn`a^
zF8h(9_9HK39&{b6le`Tmaa*f_Ts|$<`snM0PKkvPsipsf8!^Ht8bl1-d4V-9?sbUI
zOSrMwHq=FTG&_xB*W#x$yfvEfAM>TG8IOI$CDEz+sm2WS4a1h@X?$W`=Lvzk!r^2|
z$)Q|4?#1beWb{*=K3P9C1zwmQ^VzOzFJ9X<ug|0Zx-MFRYTSeE)-DhF9oI+G)KkAk
zK-i6(3u(sZ$aY54*8UT8yEU&v$K4o{arXdLnr)nzW9wGF2;Uo>p<a6XA$vpsza=^|
zJazYc69em!<x??V`v7muCE-7Y`oAq&nt{zj7E_*=7XdyHHD+dsVJ^s*^$GbFe;hb_
zhUkTuzu&_D=R5@a*LLe2KZ!KM^$xDn7m?Rb1$oJORzHqzPmG7FS}~;8eMg+}a`u?Z
z_Y>7)M;!NE^CVBnbB(O~aNX%?!c$lAXA?Z7){9ajEfGm_XqAcprlC(<U*oxhHK&a#
zX?=h*vxFsgjC8D_9)3Pm54NuO3yCtL&ihM~!68)nX8pCWMb>68N07H(DQlI~Bi7L`
zrqfK<tc4*W`VZo#-S7Mdj-wcU8UE<^n-5}s8}Xsv8q*e|S7^RWlWmx~8OD1R@bp7C
zE)3(nTH_fleb-ib{F2hPw1E>tmA=H7S;Jb^*CIaoB9Fh~-<^;5I)t<Q6{26&Jo9ii
zrnT_^=TB`cz;RnR&WX#sE_#EeX+A#f<Tk_&$8RxxNAxDogF7o~^pq3FaN)Qkj<+uQ
z4UK1hD9g-p(3g(s3elTAozsU0L`F_7Z^?;6-}kqDoPy|(`M$pk_>Lg{TU*5cJ&m8{
zC(rl&9njMEeVhLNK7LJinHSUe1Hi0I^nH!LJe=iizVACU-9N-{U(SAzmjfR7zVulV
z=P+LheBc9%Peb4BHGr!RY`%_Ied2x@IQ4@KH+o!dKyg0p>w#B)7+#&YZsP0y8sI&V
z_?V36{p~jbzTLrdeb!$Go<4A8k;fU_evjV-jK1$6dRl?PW|Ftx0-XM@`Hsc_eZaQ^
zC!U-7nmjA|M}UPsAopnC?g@FukS6`VZuozH3_3pV#IO2)OoiQtC5e{m`ot)24-~H$
z51kwfBi4%|XD8{aM9v?P`D3<~&K5pMS2R!eL+IRI^;w+=T&|n%^DgkZIjUoO0y}NE
z8-cHIMRW!L=PJ-f--Gtp6P=!FitFOa!Lyj})^d}x?d;pz%sD0d&g9vz^+-RjKYwqK
zzV_#t6PP7~KvuV-KC<$yRO`=NhBMTdn$=YXshBhr@y%}8-aOhmw#PpMAK`o>!+(yy
z4Y)z<eafT7y$%g#8|1;bY@_TKLi)c{dP_I7Nq-HT*$s<BoAft6PC<AvoAiFbL!0z>
zE#m*Z#?Pi5_k}hd|69<~CVfDEKZsxB)oju~0Ot9FO)~zNei~<an@#$#ruz~6avx86
zJpLDe(<Y7Ar~Lg!e+3xr(BWnS7YeyORUZN@TeEKL_EF%%cDoTJz`Zz=Y_rsnF0|Qy
z1Pz~$;g|cW9;uFSt&sIhABgg~gZp{!kL#S_e*%s=@(In$`YZZYrW-L`A^Mck+1x7E
z#z@ON_?L~-8U2gK$>OqmT;sgrdN;jgKKx^uvT1ch|Isp^aNnitTRU=jEkvKuG)!Kh
z?mwt;*oPaR)cuEioPx;MbpLaJhr0jy7V*EJ@mZ#1+OZ5w_x}sD)cr5&@0ajvyqfNR
z1u)Mabl>=6`e~fyZMy&8n(qJL_aW7Nwj+e3fBGce*{@dX^?PWi*=PMTVC+w^2hraT
z_OF1k4-NNM{u^LD0*m)h{ySjX0Sos~ei|_Lm%MCbyndoFKj->P!r5m|&dtUc<>5bp
zW4~#88p+pZ0owyu|LpvnwaG67hE0ibI|2L8uOb|_L-wDzd&xaWo8yJ^(H6f3IzA8M
zmu=Cd;H<Q~!#20;KYC$n!~TQ)auNMgp@*ruNBfUK+;Z!ObqFA3*N>Av?|UwN!G^hk
zKKH%b2eePVT9S^Z71&qy09M4ltf|?$^uG*uM2i@Z$75^Y5sqoLfrev8T#w}E5xP)A
zVR&;i+?WA?d0Yc};&EM)$Pj%@v6C6;<IZiC{n>lmiYeu6C&Pb3&l$?l#$D@sELG+y
zV>x%5ua}|(CH+Gp_painX{_~0-^;UxA#Zw1r62FEHQlzu-E`{EL*B7qb;mPVVciu{
zbqBn!yW6p*+JQCIjXkV$$OeMWDPQX3ilc+T<PQ7Q@->-mMjrOG$SWu7oIN;B88Y{O
zg}T<6(luHO>YA1JJn$mA@O74#`pz`-^0e}HBM*C8<n@Tk%ez%L_X!I%Gh45oTwa=)
zKZ7>u=0gYPo743f4;7t==RLRd$oiR~Wvm1Bm&-FkAnVlbgIaA)@(t)~w?>O+7uBbx
z9?+g#(qcaDvYh!i(!*EBSi|}1Y_q%%YAg7)r$^@8+RY!hKKtF^=e(#({8g@_UyL-^
z_dSNcD^c{mq|M_M#bS%dLvTJ@U~X)}T_e@`WeC>B9E4-9E8v(?oo+T3me~EobE=yK
zcc4DIFo-=(u`TSz+%2J86sX_p#x?ZOx60YGMc#`dz9MCK3HZGP`#I(Y>c{KNW_<=p
z%~s}wFOH$E&^@!9GvxgNmxA6Nk(Iv^%K8Zp5F2NA^f(>P&M8wKozWRgQ^$2uL_U}I
zST5RjbRyew(V*l(-lDv5qTGKK4ir5=;_cHq;yf)hmIFH}_lpqjviVt+_m$uW`w^#_
zQ!)UQ`FFIA;#Gj#BmIbtMU7DlBS-5`m_E)ey7}KAee6H+>E8)ki8;&lJv~}}ODCrl
zXAPziBU7|Z>Ltray=*Bfxhp-Cl?RBdn8r2Wg=uhIhPty2VeBJZaFTO+xm{sXBF%W7
zANvHG_2WyN?3O;;)w{d5fb9_KS$v$tWtv)MTkkMgS{NLWpJ}u~^0Nc7it8W!1+R4B
zef%&w6LHX&<GLOf&(7l6JQ{i8T-xJ-e*$Tc$3e>N{@BN7_=&)6z>U^B@XN=>AC?Z&
z7zUk<3*tDP(G5Kk#i#wi3iEL`<w?Mq-)(W|)9>_g3c`>1^t%Dy5yZc#Mf^P)Kbv;e
zr{4uy`t&#J?_T_x9GDl=xCJoJAAEY_FAryVn@@kMrn?WnyvHX!p1mG$j%Rtvj`{RA
z0!9~!FzHO7)0~5PGT<^{B(q;`Ec+C|LLZvGEyu670nSIquYS&qZkbO58uEVCZPq2)
z<C$rlClh@Kq*K<UoDOsRhcg6;xp?j|?T$_@;ZT&=5{55{rW4_w2+PQd--a}=i%v9;
z53`4e+spNY$qk3q<%Na$<`PUcd0;<@^{v@OEY=xMy`+s#R(YRzAi@%}v-YyS#Cy|k
z??Hz89AID9<~*T|b;;v3&}W<9*^2kDO)y;Qabx#h{PLkLa4sjtWyjYsF4jY93l}5J
zyfn%^Ox@`u<A?2Me^1<gEN!-*1Ay~E+TDa(`?<3x*?tZp%slD!gz<*}=aa?7eA}3~
z(&O6Cu>OwVm+gn?S^F6S%%_j`WBf7wG|uw2_H&n}JC0wDtJ3YK4{)}h5qA7&CmehB
z1IG4Ky{EBYumQk0b{>a@aNU!1gMe}D9F9>(0Sgc8GCs$uRlvh`#(stO0!{$VNACq(
z_3W?piPSNqn3#uU--20G9MO04u)I5med3`WX@`FPbWL4iyrEC}L(b=JT#2HuX?su4
z7jr#@^ToIm$e$THf_!l&4q!G9jC)n5PDwj_CTzjx=s1?9<MnFp*XqVyz^4PB_4`1#
zmHU2Yr|0KRJ3Dd#N)8(#iSd3$wrj#JGuY^Y)TP0%h~~M3?dh(HrmJMq;<9W#ey*C!
z<#C_8Gde?nU)N^e3w<dbMcM4xL%U%6F0Jpia4+YLzp?(Gz75BL-+??~Pu&_fU5_<Y
zWZ(oq7kP&=<#HFwOnqSui0c6y;fE9sJ@Wn?_o|BDGR>W>oL6!8G=Eo*^3%qD$nhC@
zW>Iv2{sa00f2S?)pWTdmr{q4X#YpaqqR&`EKK97{lit-bVS50i{SfZuTg|^M<AN`D
z*_8Ki%SR+GZO>GX({;PU`WV9K+q|<`zc<zo_~N36PC?u~S4HqVEpZr6eKVg?CTGdl
z^4cabru)t=K|Qrjc0n#(Tpz)hV`_O88^GAWT{)Roy+<O+e{w&s&#QGgABe8JsETy$
zS;os9chsI-nVh?44kOpz-o1Uj(H(a!*PCZ67#1~;Pfgc*W9(#U|DC12$=d$O%0O@L
zSZS<ur1xpj9oVLYEnG>ugGYeSHL)xPW&AjJ`8ag!M33X<&y1J!tob*MDX=>=)0>&K
z@9kx=QPhKDrGqT4tQfSU>oYo(@y_Cv7s1FxC$)@wQE?(~Hyin_TCzJhmka^uG%CfD
zxfL72${u8<^mNWS9X-8agrsgNI!QTJn%vc!O&PiE?%nMoajrTUNvh3FSSJxw(s<H3
ziOXiPQ_=}1v)2}bUT2aLrHH-C-d;&p9EvoV6c@#M=)sE%S6(y;J+k&vET}F8-orOf
zq3AjFhAxk5C8+g8!L-HDr^=&deTi?CgJjjHND?J<jWL$X`i?6vx;d~T55;XvPI`Uw
zWD?$h!Ftr}h2g&1;e!Vu9q{ej4NE`jZ^p=pL7S5k$MSLMx6Wu+Z=6FbT9KpV0S1LV
z7b|XhK`9Q7C2W7~u+_pHi3>P#OM+JGnh%Dd+CIaSohI;Bj#O-_L3lMs3JsoVZz<M<
zmN2~m_q`W-9$2YQMI1woxJ-lVJ921tk_a|SQ<>mB9yw%`jD2>Yw|CbrjU_jHq{!nA
zREhkcG(~t&%z_z@Kw2nm+Il?nU=#M?gXr7MK0L$h!vHStoLZVb`ORwx*wW3Z1HbjB
zH@NHEHQx%09+0IeDq5$OOs}XiBE(zL(@|ovQXTN25F~LYvvHf%)8v64b8x>CXnZLt
zeH)4x!y$f#(}KaI?O2ILI1e&^YG9N9CsLbiGbi6XnRD8wH<+Vwaz>*@;n+H2Nsg6d
zje$c69@}Bz67zqQnN1?)rkG6-8Hm{!?7Z@#9}aBsZj2Ab--&boCOMd<T-*!h3PEi&
zSI*V0Z5sB<<!ddFmhWx?*{bq#hzJ`qold_Z0)qO)qd|>v$Q|Nn8Nm;~m7e>|U~OXQ
zksG+8qTfyhS<uW`k8~7pB({VNNRNZa&?SfNfMy*wv}FE1`$X$X(;T_;>uyynQes<P
znoX6!PLxW_GwJncNrqH(Jv@=-*xxl)+OH)IPM@S>J1gXR#MD`oH0hnW8OiV{c~T`E
zk&V+2zmi5wVxw?8%aV?!GSD()PPU}UMI}X%u&~D_FBaJLEW%jlG?XKG%|xTL(0z@P
zRD6w+ulyP#)O_4sk8#tV1a@S^d^&2G6yTd|MuM))vw*f(p?87`^2#4em@U;Af}r_o
zZ5cU#T}4TmG>Rw^ZIiRksW@)mYbsV!Z9-$Ov5|gU!9Ful3fL*z3EsjGCh4U(TuboO
zIc?QPIpCU`Z>nxbZHj%GGc+|ZJ+{3zpM;IYq(?1AE0AVvikw?c(__EC9YVpJ7{(2+
z4g94WG3g|IRs1!-Z(i?hd2--t?{Rk}cEEw<8<DHg;D)?h5;K<EIh{vf6FaIj?0xdc
zSY1lO-D7zq*4y~H$|+T{E;T{<oMc{#N9eFSgXF!kFpm4w<XU4=D@CgI1<PziC}gWV
zEmEsI+eC%2kRoc&o~>)?a-4jVU&G9Bh^FPdE)1dhSy9)`WXMnqTB(qRgS!kJni3j{
zip5du04kRhvUh9dU%mqKruVz`n`goo=6V6=Q~xV~FDl&D%DB(s75Kj1Hu%fjAHp#A
zv@V0r&W8~H8Kgnn66iu&tSCiiK+CwqaYp(mzt@L+zruW1-1{LcSlIi9t$0^HpWWl&
z_C2mIV!e?0y&MY)%#ZnkMDitEctn^pviJ4y`(1@CFc;AdEEw6J(XbpVpt1FC!}GU@
zznHEwdJgF9EDw1g@5BR)rx@Lj7hCH~;_%I6!C@~=P{vNmV1;pt-F$yQ-rc(S14=J6
zkb|w$G5o{8aSibK_~m2qcdSVMl2(V-_X~TH>w!OtFw=SgetlY4J^V3*`56DiXYvHy
zj|0w!dx5$yLaD*e@kVoTskVgfF_Lfj5w-{=pPO;O3$SMKBR$*+(rDgRs|{j(sqQ{D
z)4XZlzKP~p+)6op&+yd3zJ1u--JHTy%=K#{yB%kfJE9jM?Qq?Wu%7^I@ywL04RXzd
zJSnHLuE8+w&J!*<hyQx4M{J1p7Jm})?CFjcmuB|u`~Sf<S2ph0&Xju(S($qSN%W@5
z-`jg=*Y2Bod%;kz-~X~5WuX4-g?@8=G_PG;1)6TOr7uEP+4k5zdhp9X(`~Nk{0so5
z+oWMyhTj0)ezD-u_7RV(&D7_1?U8v|ewGd;{tJj_dd0SI3I2Gd=_>s4p)Oy6cb3cU
z=m^Wz+Qw{%Ue*(rfp#IZ1uVlW0zB7Jej4^8=B*gL3V7!KYW}Xc_t)sV&>>BheLwU*
z%^UMGTNIX?@3fY$?O9!3RyWM+8OVe3dL81Cr-Q8P`}vOjGI+Q3{$C^B!M79;;|&Ni
z{td8Q5#;*DMA)tEhxli2l{6(T%Ss%7nZs|U!p{w8hrk1AO&{K(v=-iskJ1v)et<T%
zN5juY8VpAWpN@Eo^-2*W!Sjr%x%s)Xr{<RzZ{S=XX2YiIkKeZsOV$hZnc9i^QVsX;
zF4eHHZ@yXMW{@SW)*Wht@4ch6^WL4u_e>qzIWvvsLwWvQkC&Ugn>>FX@Et3$Ox}*L
z=_}*B4S$<3ng0j)<&(i}jQ3B-{sz#zqX)Wy-#^4}h8`PA>@2GB#r#S4PSE>2Q6GPR
zFds<+`sQ({=bNF+e0~acS<bEXa2IoHk<mu}F=*~<M+Cb_x<3J3XkX90s3842ZUUH}
zoe8P~eGcdg?*e_TcDjz~me~QGrbjxg>-E@6@owPk>5RUKb-fbnEBChY?sw|vk}!j>
z8D1LK`Il9<sk>|k@9T+iug5#%?Ia4gztAw-KEq7+#kqQ2t4%kTYRhvCoJ6agtWPb}
z7M9o@o+cRk4bkQC4IfviH|M5iYsZ`QdTn7IU-~;M-`zcQ$M)PLdMD#FFk{v_6^sCT
zMfd+2Jkw^FE;9T#_@f<WdH7Hlg>EH&e?Z=yfAV)dIq~6>{5{}&Xr~z8+SLc~9=59w
zA)Lt{?dl%@=aa!9ZR1V$C4uGxJ+57SSbsl)U*p@_&_4neme2TO`UxC3wY;s}eoWK-
zIDRwy1nrhM+QT@XWSeH$P2SWS(tQeln_8ri#<5IHf8&bd<6jXsFRu)bQOt+nprdiT
z*k-%{=YqNS@S{jKSH;$<rD*50J)b~2p}n9D`6s~c`-T#Cw&;^cXQsY1HH|wKneN{r
zJhc>unNJg2nWh%&;v4=m!i~k+>8V+4E>wF)nDN&mmoK`s{{?XLFB0$H+<R@x-Dy*s
zKko7)T+^>j!NFyJ6w=T(vaTRW-Ivx;_;<vq)n;(NV2ziH)TU?W7x6)8=2Q3&!6j`a
z?Z*Yt@#3d}v#0YLs~Pr?kBa@U@!m2R;~(v33BCq@#UBtmxGwrk55pZ7^#VsbIuu2+
zM@`zoifgB|rKZ#D9~ZYq(X;SJJM>22_)z!PBaMwe=-xly<KmdF`UQk}i3{^~K2I_F
zB58F0G4V035Pdleqs`O*A)hxZpSOX}FuV_88$a@U8T@0pndTCHX@S1hlS~67Qq~8M
zw((uK+VO3C6%l3{^oQuDbs*eC-|fz)Of58Orxt5x8gn(w71V3T8@Nwtu{OJ_hJW(C
z#6py&Sv)&8eUc=*YdhVUmSS`dx{~@V&)6{Cj_B0<%<^o#)|f%E{MhnC5AvI!sInr<
zv<^J9=#hOy`dWwg_@KB}w>-Ii>n&4z_n>=0xeMLvk&d(buCKTq0tw67C1o#cDI!nG
zfn)6$UyL>iKCTn$PFN=|mT(;Zy;6rJ%VKn1D*i269~%I7zH+f!-dAEhVL0ZY5M3x?
zm&XNo=U<F3Mi*&V`hC>j_0sQK{SD48mS!=ig`^>4Jzq4tILI#D*&)J;5$G_*BzwgI
zcn9HF#7@I;E^@BHGwhhg>&H3h2DV&Q>)3}qKUcmth`&zuY!VEh*7P{)dA-*2CE&e9
zJ#(v}MszhD0CMa4Ql!PYrfi%nT%TiY=ChDXC_hKj5nUnjbMk#H>fdz0;fv8#f{%4z
zJf#EIA#8Itmw`4vpU!BTq+{a{^W}=&+X1KTp<c1>X`|2``*N6%Nc;16PwUz|$CA!p
zEOtLZaaP{1LKm49|0t6s{BpeWMA9Lx>w~l&hj(U5|DQPF>3;YACHD7tXBziHh9TV<
zgbjCHDh=UP<LyY{gjdDgkirRHn)m;p43<9mr;Q{3lojn2%ZB*|X_IW*VVL#DFv#Rg
zrL$-1p)SwOa7b6<bdPTriX%*Qb#HLr*zL$Sq(JKt3zUTQ>YRwPH+KlH@z}Iid1txE
z+a-bSkYE126f)(n=rL$EV2-jM@yuTT&}A`>8ebM%v72Ld>QVj~q<-$?*uRW@y5l3{
zdol!o>4zS?4>q6kQ%nalWU|GbVe*2rxZzxx%v;e;cSYlHJ?2mK&(Gh}(6dLJ7ugJY
zv|qWS#nQyL;*qu6H_W=+8VL&n^@XLA^oPhd?Lr0RvF8#;)0S`Q>jBDO1$T1h?&Y0m
zPR%XOaxyPWC<BEQ-ub^Q1Ctfb3=ZRhlX?>pvpTpUDp$u;eyo$8sN82^%5!@((3qK=
zLr*;;a=`GvI2_3Gx+qg(QG^T>a-d9yRHo+NoCm$&pZWHF&bF%<jcGm^+{PHkG%r&f
zHC>i8VORJ|-(v#lm@T!rHkQ@egPV)$j1GY=ZXd1<gz*jnpBL|FD*e$Gbl(B^ow>Rs
z^RTtax#dMn0m&ZkI!4JN$P6?&NBUhzleWyI8x`-yyrw-k*UkCeObV-|Yw~8=Psd+4
zj%&w1wsy(wmzV^Q{o5{|G&JPD&^?9pZ47-(%fkE#=ifB`Hk}iX^DahP;<#uAa2w;?
z0R1Ijg{ZSw2izVjf0~2U`NIBtq{Fs<D0i+y<cjuxqP__Ej?6FBp1F)^?%MpZyWy`e
z{X-dOucO!EQ*Tc)57gah(TV34jc@ncJ`ZGzT^2ZIj7uANU!^Nk0@S+-3*yU?2b2Fj
zc;A6CTRWOX*mQw(4g7I#@DzUe7~S1@bQ=rNywYXUi0jklI_5yjG17wmJ`=wtBl5&F
z76J2ofa{o#VmEoGEW^B(0o#N$ZT|7;&>gPnkl&Q_<ZNP-@Jwa8vGWperf*M$zEKBH
z2e4}aqpqyS8p|2L?NJ^4hIAz?lhgrhn#tDbPFG&LZ<*(#p*wf3p<R?_PV+L{+VMHp
zBI0niEqpg*7S<ob&&D6u0j;dtP=C?Zg6M#|Po|^rJ)o(@3BwL{Vuq$zybo}D(sdA!
zOG}NzNxn?(o|i!Grkk`8BWsX_w?QV10Fcbptz$n2{D<;j`1|n}%7gbyrsZ)zXlg;)
z^nu79W%2{S*^`z@7)68<0Mh)KTs%*KTn5)53p#;bDKwDIgYtbY_zh*i@bmB&${<fC
z9so_vGC}#t6U+a6!0kzw-^iWmb_}L@vT}Pq9$~r1n)TDZ+!{#d!E(O<e1_#__=Wge
zt=vBfnwn)2l>5g3w<le0BbRcw;K|DE`AC#I@0?qr@0vkBIg4AarHisaUb%k)e6rkw
z(jVsfGG@~(nYL*f-%R%>@fZ3rYtd6~O!4)lfjqu{M)|h<82(x2w~Fn0F=)^axlDrk
z`Z>VuN!OQ=OMSKADZ@ulUu&`3yiTMx=S%K`d1ZeIcnx)x;a|kxYGr>ZXlg#?2>zRE
zqb~#8o^;t`aw)wJrunk+dtQR_uf<jmHx^HEVCy9i0MdD}y}lAWhcaOJRrm{KkY}r3
z4Vqezc4(_#1Dri+IfPL}5&<C1pUJ}W6v$#NZGamfy&N=<&Vw>|E%*&(!0@l&FO)%^
zt$rP7pa(9Kpbh*g;P#};Z{(^45;x70mD}?XlzVM$0LeCvCyOrOWKJym8^CK=c81@G
zztzhACeXODyNs+2{5s(F<d%I6d|CNDFG2ao*U(3cjFHbA#x~}%Bw<-Oycv9la$xwk
z@E6J<uN}MvG+qvxA$eq<{oBCV(@GX=<<Vr~`AW#7Wj}@?0X`GaIE{(v+RXB)Q)k_-
zFKFLnK1zppvPSY&@E^*A;orkwcvmvp1;-O_13W*)=)rLr-xiC%4;p(^9xbA*&Y#J{
z^Q3dNOn+Z%9a&mln62MtYxWZA-M;-$IIb^tzXN=-+!!OuyNxmb2=H)>`Ns$wAB^*d
z_@lnO6Tf`ez6cNFybIw>9Mt8zgE-8`<h~Q>Fpc-(k85w1Hq-cv%LCjwF>XZb<WCUC
z3d}ls55l(Zj^RH=xK@7V^3*K9@6i$c8N(B}H>qAbGj$ddzNavqgE>sfvlIIKKH%-q
z`m^L|&hFTrBhS3DS{W!G&Ph4>U`HqC+97w&W!u^$*N1Ff)7JQGozK?#IQGU!Ir<y$
z$GEm$xS;dk7QQnTz7}EUuch}nxw$7j3Q}*@j$z4qr=O<amro2BwwDhef2%k0#PA34
z7y522GvT35`~$)!r#Ma_`Y_;p+VMCzbx*y9+dbx|Ih*TPOu|ClE_8nsX_`L&V~UTD
zwcz99%7@K+k}jXN82yvd-mN<LA%ttA&4rUwb7WKW>?4F#u>rJ(FAv^(R@Ulmqb2VY
zp)P)cG;W<vh-`nrCke+Hh50E=HZnHoDIcg&@l(LrWA^2d)L|Rny_S?|dpWnOuZnJ>
z4OJ=$3+t=c{jVrfs8bC88~$hu7P$6=hjxm3WA*wUjI-k4q&N6~5{~voUHdfNiTe!x
zLj4@ndi!_4F*h;4fO}t9AD?9y>!H)=Pgob{0rnEC*<gb9OcOPE=45>ibEi0V+&JFA
z-BFYQ+CcF^#IwihBw1c3%Oot8K|5K-b?Y=idW{q?Y@h!HUReHi^T2U*w)tJV^BVoG
z-7$Y`&!1<yPTpGzDC`#yw)V_CKZif|3tz-9pDZq(=d=AyUji*{$d~cU`ehzgkN-{B
zN_)GIkf#+R1q@~LRZa6w)IawLeFb68GpeogZIEj({{tMb!)K?d3~v4EYk*-N%<x&+
zaNghwfVRtG@nNB79IlV0ZR_fFmys8A-(*SoOTDg8PQ`BW=IWx@O`iCkjUUU~*B|tP
z@09HhNz1KQZrB#bXC16ZnDfY8_~m11dtA;Q({n(}y4;9g%a3_5?q<MzT-0#ObOZm!
z=B^nxlRsp0KHz*Vmc3)eXcNLgU8-U`J9{p0>AB(aNT0IV+$`MAW>YVUpb@=rRSLUN
zh*D|6L~t<~D@CVoLSImb+NSHNX@jz9#VN5YtEJ_rX}j3|d3V?a!Y_HI?xyu}ZS8+=
zYhSZAgpxLNMa8`*?Z$=3pZ19DoA1`XFT#7MgBK%g^-Q|0_@fR!2ETkVIM^EQ2hYdF
zx^L?jmmnSL=cW348GbWqCiJf;{IYGCPjDsTaLqN0$Ncdbr06Q(_?X_3HcMBCdXz2?
z7nf)K7A&bnj|DA%uf{LeNw(pawlfW5d!x*(y*&=^UWSl(LWZ3I4(%wpZ@VM99C58u
z*(Y9s@O=h=UU8r1H8G8BD5Sp8o^B7|GrI4ZX<Q3<*#5Xjk#f|W<lqkI3Xf;})V^)%
z-e&0Wb->wUdfZO;Livg=p{yof%8Tuob<20@7gR_2ZaR7cXhI#m5n)T0bk`%yKJQ8R
z<&(w5dT4##PS8>hcj4FawtBk>FrO~?ZJBODPn`{CpODEPY3x<rm>0`qz7gq}*DZjB
zzENHp2|l1dA&;g%&r&<Q8|l?jeX#kpdw>h|fVy!rVE1JrIJ^C1rWN>Sw=(<){IfiJ
zO_=Y;=dg|--MF)@`y{_bUalTnW#~5TZirJWEAW`dI11?lxRSecSYGRQuoEflDkQxW
z-o<4{B7Afdp2GO4HbVcA-vGJ|ID5<oNmqsVk11g2BZ-czxP2BJmxuelJ_miVHq(i`
z_#Tc$zcV%V+>0>vj`F6CkATl8bKb`FNiz13K9$E3Y7N{w5ez_*h>+hh`H;3-?B<w&
z`Ix=_7{dF3H=QQ!ApSOCf64*;@@dD@P<`q&jzGxxZFx>^9CSS8AdIIl?>k%MeNgje
zpGcm}-VEcN{97L~k{2I+;;6>AzO8~VZOV}Tj^USbXWC4U<sZkpFF$g$G)TvB)ke^T
zyib5WBRBMOlYsNd;$mC(H1V%-e<Wz#pfXv1W)G^sr|rQZ#^HT3Iz~Rsu%6dvJk}S_
z@f-o%9vgFgJvx*vM=`Scak>%Zt=-phRA5!z$ji(0kl#~m)i(O378}!;s!9x0*i3B9
z(}uwGlJ)#ukeS(k>I=h9$6sjwjqZV!SP!288spu^fgVl)&WCzTxasjU-a|c}X%WA!
z@iS=$;|uC|5qTT~Eq{;e?+N^J4luCsWB6<`Y-mSR11{7V`Yb02Ya=J>7VBUg<^UU@
zwa0voc2UKqwjs#W!3yVZTh{m7GN!r~uxm&Z%7-)+@X0!w1&^%DK1t`fMdR1~icR$~
zv7cnZb|B%U*CRAZvo~`{)9QlhpTgh&<L*nq<SMGRZ}&`+$pQ=*6csT*M0RFLCd-GR
zLlPtql9+`6B27<sPckqYvt&Vy5fKp;6&Dm06_pQn+)#1f6%`c~6&3dl{m|f!+yA~*
zb#B$ITerJsNreAC({pc~Q*~-PRdwo|S}21L;?0M)0j|%XKSfcGNzoA8F-^2v<}Du`
zlE2J^V_4Hhtv420?6P@F#gC8@zs_rLElo_RUS4b17rUWuL%CzwIt&S=av4`ivj)x$
zz-@ZT`(wzb@cwpuOB>_96ykQ^=eIG!-8Qz1;ZU!HOL(?Xx}T08<;=_R=0kss$8BTJ
zgj>qa4YS*XN#ksPt;UfY*7Lw`6W-4<?>!-!3E5Mpm+2t==fHm)H)KyqZwM#pQgSik
zywb$^T!|BMrb|oY%=dx^c|P~Am0plC)r@E-!tB^qQaU@f^=HE!s5H#QXXLH`Zg&U?
zUgjL;D&V~_NrfqL(Kz^Gd(UX88(UZs8>v(~ctq}b2+PNp&&YF}i(hT<_aW_bBGpDi
zDQSS`44>=?)H%vs%2xPf7W{?h@WnH+5A>YUKxwO9&3dj2C~$pvxPNiIEnTXPPf(qe
z`YO0s5K;Zrwa7d9nrTwsNE2m8*e}$Yc-Tc?1JUQi6aQlTX6G%B%Kb<$0UW&z1b2PD
z@=M`v=AD!}5vu>c4lwQ1>2Hc=<zJ@4F)aMIx+$!m{#3d^L)I)ZKTH$LnBOnrH}Wa6
z)P=BL9f0~48pL0Z-)xL#ufm&;!hzo{&d$rz;cVP@sqrrtF%GQET!+>BJ2;MUe$6<s
zet+E%_CRB;a>Ra{<tpVuKTLN^gss5pE^zIhgR{eX`&hO)wa=_I>gF6|4el9Hc8ymf
z3{<9iVJnO=9B*#`4EqqzsrC;J@7mHkx@~Z5^z^YF+<l|R;}qT?8TK^@s}7Da_nwna
zXGN{~*8(oj+{mpj)hD}v0{Jv9`#riISSC^@EDPNRLSrt@CC1{XHJk^Q^qeCB0d@BA
zZ$x^ekG~1u(nk}{-<$B8owGUy;a83Uut-8Qv3nqJ27Z-y4l)04MmXtjP5_MiA)2sG
z`YnLV(}G*?>ZdWU(kOXWY22gRnAjO1R;fKR;-2BTr+IF$WWqm|t|#2{JvWLxfk)O8
z?k9Ne<2*NxWJvgbB-|ZA-Q#9lt%Qw<Vh%jlaTi!$`PL7h{B(blQ{Pf|9|Zh(l#9qb
zAA(!j7{lC#-)z+Mhw<hUj(<aS2>asW=&iFLy!a7>XI&f<O#ezA=%g4~eIXRn@G*p8
z8q|X^QTmuPE+4(q=su;NX+xkkR9MLGCk@RSvX96;xcQyxk7{LJktYFkEs$jd;-OGH
z+Xz1osQ&uX4W~I5J;~A6Ci80B4bxBEU|bIPmU3V_WH_nIFW}p)%P+#6&Og>20M3Ve
z!SK3`Xua8&Gs1kugc(2|tM`y$l?m1f@H-c+A5_OApuN(akJey+_gEE2Lso~YSW#`@
zP0@xR9QQ0@{}gT)LtoAC)1viNTv4X%Ox%0M{ZK4}JCTOf1C`!ky~pxw&Wa%%Y+2v|
z3kACuk!A2T{P-q~ba^yKUk8ql=#oDUH+9P2z?)^n@VZ>{>YNFF%l^V|0{1Qa!nCm;
z9ymVYpXrb^rPI<BeaHA0KF&^eKKfq3Fa4+K=A-W$zq~U+*I%*^)%Cbsj(SlCtns85
z*2&4v{=XlB4wl{a^zO99Z`}p8?@!WxFZ_nfB_I9Bq=);LhR{yQ#Ydn+WqJPuIP#>F
z8OMyD0>&WB8|MLW-;~F?0YhsUbgnvYo7SDJjO~>*yn93EjWAr>QSMXwwXtIq?x7NI
zmK45gQZUG&fc2Sh%?dWUt(P7l2awh@1?$17Hx@Qs!EkN>^!y5HczK3`mnkd9@w6yd
zwbb3K>CIH`ksZA~qu5QZ(>u$7br{%e1%sXg7e6u`bCerL?qD>;E*_P(0~BlwQ#RFY
zDSrnh{B0bnmQgGweFrI=Ix_}+^9<-sbzA!d%5>A<rPTp7=i9PCe-{$_I)4d2tPhU&
zwtvb+zk-{O@B!;r_<-MW-Jz%Wjq&^WnOswri*AQo#((Zxq1?r>1E(4cLny%w>RgAA
zi#`h2kbsaE@poc$0eM&XjQv@V4ZEodm1=3U>d>Hn^4eB48tHiG9^l}FIEZIbD!n6|
z^ThYt5Z(rO&#Ijq275<^wz}nHB#QCS)e8#Ij`3V|l~B+=7&jlX-+|m{hVp7fB_oO3
zxU0W=u+OBAVLqY5s2nnlgndfG)(z>i+mvsI{>Cy2Sp1qe6--B{X?#Z0P+Q)8zlyVP
z0}Ysimqn^LKWow+Lrq#fr{QN{@y;m3N;Ob;^i&+{^iDLl9F`9cmv#l<y5lkkCtvXq
z!ybLe;W({fd08niT>qqRz;3*o2au~kyk?NwG^h#ce1Bf&Z|xZ4Sl1JmieA$+Gcx5O
z)$Z4Yz!U7?q*3q~Y<U={c++v4x)VPM52SGi(#8dSgCkY&R3Gk<qB19uZiZPkfQy~D
z-@%C&+Pi9e51s>GwPNFDKM%Y)fOOpOE70A6BxXk2!Q_n9@WWSid2OhUjt#3Up*@qn
zfv+r$mSS2=Kib3k;oknz@U9r8^b&Vz9Dy?W$KmeQxK%qxs{@s4CFsY{R$9uKa<Z*4
zuQ7^g{H{sQ=&(8T+NAv+7aoVu`7-e+URDV-aTqxFhqHK6c`$V=70#gQZX>5I1gE+X
z2aeU8gFAEpod!c|?O=6h8T-uLdcyS~YVbf3I4&gk3OlOQ%?F!GxQtBS-xl{#YpOdT
z@As+g@Gd=bZAZG^g;z0<#`W|AQ*K&#RA9vmX}Bsr6_2TdShQ53l4Z(z=ZRf$O*mz<
zvAUJLu3}-g%`>lk5O;`l^FuyH-Qf1BByXrK^t#dOGBfpgZqFtT4K^<V@6Lc@EP=vl
zC@vFIPUkY>P1~?BSz&ZN{#cin?*HOeYwH**cU4R0M9_>LYRsbS)L$IJ=%WTCwN+cj
zvi{<VGuN+Td93T{;n{u2r^P|i9vfySzoxpqs^k~W(SHtl&I}XfH9KNISQ*@mq8i3n
zf)&K7yaayE#<Q!tcHop<!@~lHi2|~W4KK|>cMrM`6~D{%f>$Jl*H}_Mv*9dm4K{C$
zL4B8uf0JQ5u6d5>sR4mp&(({=xI4|_oF<gahZ;&)CCRku^lo0cNhd84rnBSp-qE$y
z5_Llow<_;}zFmnpL3LdMwhiW1>D=R*OQdsEd1TC`v378E1suF$TWNU3wrcrO7q<#M
z^3X_cBD~-Hb(#K}^{Z<UWzrPg2RC{ER<2Sq2yZz!VIrj;s6w~<TZED4yacyUo$GK<
zp^%p8VZ9ZZKGt3Aq5Pja1Uj0CG9=|P%9Nr{l=*?3Pt1sZk2EkmWkoZ`ZKW(J^W_Kd
zt><-m?)yjMU+F5Yv~vx*|BN5?Ab-M}4|TPiE7N%_^fEFpiT&o?d3wH;afyzM>88KG
z<LB=8W?Bhnnn>>-_>SozZke|e$9a29!_l+xzD~-~e*xZ?qZu!D#jEa&^73Edr#Vtm
zpV2_F{+pt|0d7?|<e{eMLBM)P&VVUSyZ`CXKjBFl_Adwa)Te1()eP{$zX6x$M3*vI
z!A4Y|t|(QG2x#>kMqlC74a*^SG|CZnxg*V45<<hpt%dT8PY5Tv4X%UL^T(BI%?Wj8
z?g%$dE*OA@3(K4pEFS@eYd7T_JBDi_Or3)osW~&)ROv0IA$>}(#mk7s%!JATAmh;2
zY95>pzo9hF0GtnbguG84k@?k3;D&%phr`)jPPm&;RxZEK$%yNKIE+qHm^Rj&8h`0{
zlf2r5wAs3_^@%$=)j8mK(4n6u^KLfp7W1BM-Upg@t9c)6-iP4La-sgqZDWjcE^uxe
zV_I3pS-2)Qt@!qNPuk{ThKAxj#~<mlyh8M)zSw{9r~Kk={pO>`f-avBPUgz8cJ6Ta
zWqKcnciO*AJ8_I7jtBjP@KXpU?IDD7>)fa5_fKwo!c({hRn_@CllCLc`zZ51+PvrE
z&G?h$oa8GX=jO@Bxq0$&lD1HMl3z*pF(!RaH1A{0`#AGH9&hpM`ys9g^(8bI=HzUB
z_*&l9%`Q@P6?7E};PYJTNeCxn*va^wwTJva?GW;H3;Ixgk0G91i}O9x`JUx`&vw4&
zINt|2-v>J12iZQF^{e^c_60{YaWBEl=n+VZO1F~JnxaGD?j6BY9|wkUJkjn|{X?U>
zl>3pu<1`+2k7~Sm6x?MT8#-+IOon+h{XmFS^REP515$FA(B8aqh4DjL2)BBKAkWVx
zC1l$;jXwj{<DpKg%t4x>n4Siy^lCqA2RE(qXep3OXMOJgk}K(mX&JCB8(b3O(2xDa
zV3($yE~Mx>D4`8&+g6-5rqcZwlnrFNHBe?!YK&;}KSIOwJj0aX;{mI5V+vuQ2VrH<
z695w#gSI-tPH<sHE+D^)zh?kOe<wOH(es@G7_@C<``F&vj5~aJb1&tUHsHDb2rC;D
zzFoO{N7UpQ@zYO-fh{+6O<1Re#q~<~0)bNzWae3fFH~?{mvnb2_fTAKge_7qXje=f
z5w=*twqstbr*66~a?ujND}(FHEMMBcmO&<33Ya`CrlrJfUA1#Fp6#*YJjZM5_bKDD
z?M1nK^d!LOrVf@X!cK>5z<#U=F1LM3-yGftr7Lw!Z%=h2%;VHypW3c0UAPn>jVsJ=
zYeN!Yo7Cq;QXW~3bfn`&dI0B>!sRVarz!H*6{h2DBuz>_LY%r!)aws8W{WL>{o<2>
zr!35J<6czu%4Y&5epG&tC;FuyEjKqsXTguVMq@qX{u?4?LvJD#`#AHPrAyJg5-MFR
z$tw1B@S=@U`BGdJqi5Lc={F}qh11$kJIxPWaA+3_E0)XnP$-;tLE+*>oo!tUyE>~8
zd5>jr4$>?#5fe%GTKs0`lk!0V=d5W`^@cKv!(ly*tUaQ<%syou=p|FG`<C^9@AeSz
zpL+`6{+b|`BP@qa8-SB1=gu4di{&W18<znR=*oqvjQ0e19HaCMlOOUC`H8%y`KYB8
z$0Xy)MK>OrwLdY?2HI-2%jE?$Ot)R0kN741wm-;67npRVaA=o;Yq(uDkS6jX)53O{
ziWB|Tthk(XpE87!@%y@qgL%Q)o~*o}Y-QfZ_&<$4lJO7dHj5VEK6>5#I$7|D<;5fV
zw7PES!o%wT&^s100=Vk}h8u~mLQO0W#|uVxV%#0u2ooU?AA4nF0t{f<eh<t0N?YD^
zZ^h3&%R%ZQ#yM^ODztB|C;sS>ET`g1o+Uxrgy|wLD%*{~+Tg1NYm-Xqe0L1mM%LN}
z&l$;1l`AvKKBX67^kpKrn-}HBb;y_KNL8hoyMV?+mL05HVRg%|iul~}qq`43xBN~=
z8FBq3%P-QhQm!B0Heq!cX)pPaXNL?Z8Y+8O{<rV=QFIM`Y!A{d96n(?xlH8~`^`<7
zgikEa_JJ}V9fsc~B!2{Nq06yX;u`}zMF(wkJK%hXI~rq690y>wpT)TxNSDleb}<f<
z=BHpi8*!Hd=FascT{{790<EVr4D!1k{;%1izcrnCD(+_jPddBtcIhw-KyeuQnRTTO
zv&V#ac19STf7AC|*{b4sjtO&RAPmzcVRYJbn5#^f=Xqg{GV|$Y0p5f(USZzPHSeqO
zX1TI$#%1KR@jDd%<|6Vo`IqY=`HfxO?1<DlNurb#ZtfK09AOkdSp$`7#LM*fzXN{c
z>=A}}h6<yN(kH>sK{&zT`3~%O-F~8L9GH6_1mWA_&V}<09bV56^tpkDMCayT0DtnB
zc2py&l)6uwFCN@}TX@xun`s>*%T%=$r%Z+4$s0l=_6H7ru}NPF2OXy1C}+yL#O07P
z$%EG+oZFsW26rr1KrVYZ+zre39W~{M_JSwhzY?@1y|z5^(e;4yN#P(z2(Do{qJcEA
z9GI3_dy=xal+oK!A8r}F4u0J-x)JUpqUqrBJ$aSzXw&-DdTYrh^@WVjGWwG_;79px
zadacI=302}2<Q9p5A40xjG0>2Q@Zw|jE`?rWd&<FmI@R>o8#zB8iv6i=JKLm!~G@&
zE06V$VS!37x7^`Ko`KP#gk-okD?hkNWos4Z(qKE3q4ySn_iryDlD*6;*3V798E~v+
zO665##p%HN^42YYxqR3TK6KsaQ(}F+<%wJ*x;EC;Nua@gn%~#+PAAkGzp1x!>*?Ka
z3lA~OJMp7V|5m*Dq;SrjDE9NL%=f@A-|xj+;$|ES`+mS;x@dz!SJEP53FmtBcN>20
z7(g17Ni%U6w=B-;amf!e=SI=HK#zUk`|ytSd8)t5M;`!8^dtJL-p58C1dNZ>)o2)^
ziH1u%iZ1*^@Qdyzp~pG+(8op}1|0VS5UwW@h>!Zl7U&;tH}qL2%}$D99fZ+0rpn#v
z=fb*6sySlSr8v;4^nCPVh*!$G32CGI<M^?z55k)db)1CDSpP|UOBmJ<ai793R6m(G
z6r9D``r&#1l;2o)9RH}tVLfvXg~+d;08TQZVKbsn17_<$yOZ@YBl-;dpzLGa8u#XW
zR>KnYf%_|_e-3aytdABO8>>U2R%Iyl!Mvz)Ln+yEGwp4U=70KOdkde9<`|&j>hfTS
zk?rFS(m@-Rxas~feylT@-?GjKmpc0@!ys;kxf9>S>BkL|Z&m&bZPqRQeI370-DcuY
zw-#sX_NGAHvY(T>WnDAQmZ*Q%8tg!z-SjKKd!+#Q?C5KN_v73xssC@l?bbite*NDC
zm|y?j)UdezSvNCL|K9?f59@zUDg|+?)Y@>bZ8GnwK2Z9$K1{vsK|P=jnQzudxXtq7
z)0hdw5x3dzF)Zpx#)?zm=1=&6_<Qi1jWPfGc=I7Y5H9@iLwpMlvCN6P7r#(FXW~%L
z7H8}E#y~wYecV@qZ91w=)7=sc_io)bs&vUr!<@L@o1z~8FBz9Q{t;kq9n<aC@s9!X
z>-Z-c7S}P$oOS$D!1=I_aSuplnWxGXqna&O>`w<B)+Ote`I7H8ln=kJ(fWoa#$_Mg
zRfOq!ZzWzLB8o`J?*mu>R5@uBOHfY2tb43)R7;0Jj8aRcsTB(6FHh?rDKBvDaTF7h
z<K10ar|=t97Fu#=da=Eu={^NBDbA&1*dOU-nf@Gi%jh!Awf-7uA`gphSk|6UzN1{J
z3%Mz}AO0AYas$JL_sI;|p`T6KI^(vsm*LUYga_z;06+G%R<6pm5-x4)Pfi%}HF1At
z7<|k8ne;fWW#Yg)7H8X5Xnf?l7wJQ(tNA11vRUEWZ$|VNz}&V&x8HXD3Ygz^{-$AZ
z+hI9!eEd7$eDwI}#8#^u_XNrjr6%PlWo%{Fe6+x<Az|H;Z&}I*A#U<9%a44_eOT<@
z*r!Sz;Nls>Gx=5}uk0Z|==BqM;L>s7jyb^jWc0~0?kgMckhs7pjC&fwO5D>K_mw&h
z)<1DG@C(&{Ca&2HXY2p+K;KIHh}3_244o0RAa1wr>Gtb>CSZQu&(g5C?pZEa?=^ik
z;C%Gh7?(t#TrkeTuW7sLT)qR~4we0Zh9=uA%S4AU-&ZDWK`hhdsB57^{|DnYJ8Fs!
z!JAJCm$x|K1NPP8&+=R@I@Hi$T2x!!gY+2Qc@%J=Fo(rqG>=in3i*3X?9Z%0Q?&D~
zY{Qc0$H9+$=RilkA8+7tr;zl0tbdjX+X!Lgh9lvZZG`e1+X&i@(pji+e-HDMZ{1~R
z)1T-zmcSp~a$f7O=U#8<P%p@INgk=AQo2}YKEgP9ob=O=<b^tH`98_ytHzlVxad)>
z2R4UJSf|mj$F|Q?K+Dzh#OcDA-3A<=RGJ|t2~O&nIzg5vY4HxIPNos<ob=hwby_3O
zMyhngHgU>^Xq}Q)8M~z3UWqs)O)f7l^3ogQz{`U3X`P=zYiSKyK8|&!>=J=8i*Zhw
z9f7t1oknmSD0$EF<@D$@q=Wo*6A;853x2vl%SU-Qoo9ZLO8~I<x;)%F1Pl25A~w|z
zmrma`S{*62FH~h)$4{Z4;u-=~#&r<ll6}v|qRk-1=boX~fonYvZO>TGK<$pY-)sfa
z+M;(GsWdi0ow3rCBSSwbsuTY>(g<U>O5<G9-lTlkZYNMa9s1DJn(6E4K>3WPJpKc|
z@XKShQyxduE{}%OG=coKFKVEy7mYK&AB0xY&+i&1zmKk+--gpPf&6yrldx;nZzmUp
zu&oLIA2Ck;Ul-v2^-lhesh$6ErBV2O57Kx9WE{Qjm%F_$#}Z%JGpb!@nf<S58_`Cj
zNA<dLv&+a>xB4tz3S}>uV#|UAsGvPcUwk~`YSgBB6?C`xsAc+QRW6=AFk!t+SzusB
zUAolH-b!25d~Q<$QfSN=3cX#tuNF6Lmv%bkL)#{{F`DwqN2N0El|yf)%dbgp<~HtT
z;)|eR+|#fs@3LZ9?djCzk8?|KWJVDiMW7*<$jln-1WqD0Yq1kJNrb}Tj%AOgx{6%k
zD8oAON#Yc4S`sG-#W*|z=WptD-CKkgTr!#kT!^W9-nSMyZ$sDX%4$yu({4G|y^8hb
zrQT7sR(x|Y11UVE#`5MUIv?rL57tDeGf+78>Gc#)I8f=J$NhxgeDqWkj(fwY>$(7L
zeGWU;yQ8iMyU>Lpm3nuv&Ql)c@iaq&@yq#h8Oc^XXT3ZvjoV~#^GLP0eGuzL$s;+O
zJ`Oj^7e*ArM|lmy?vy@iFe2Wq%(0U)Y7yzuCA?afXmLnyH!F_7JzCwmOIH|<+*Adg
zLYqS7xTSe?v$-r%`Usp=fL%4%YN+;3(GT{PV{<WfVGV=0la><Fq9-?8X{Y10Zgiel
zFX756sIG+jRrzQy?X~Pbw0%kIPv~yLSjn8~wUJFxyK=j0Bb(IPNUp-QYa^S~+DHR)
z)<!m|wUG**SR0A+NfljL8`-4RMnbM})<!~BRDRsGkxgoCB&^7ZwUNuvzs*AbRz<lO
z8$|t1OKDJaS>0~R;^CNg_60L>Q1Vu%-Gs{^P$Zj^{dk*GCY-O6AKs|yKrDv)$JWSm
zSEnIQy@@<2n`8Y<i18I|;EL#Rhd%!(oXc!<F+<?&(@rZc3LFlmTW8nl1$tPO>0$Ho
zRqL0Zx4LjabQ%vvD`a~-ebxHYSDtr4bQ99>5mkn4S2&9bKc*p8;1vogR;}kKIN;5v
zuR0S1PO}=15Z2LscxcAXRiC<N@Q~}5uf$&)GJ<lt0crd^(%5Ip`)ZR$t15DnXrX}=
zrjc#}6Id^O37kzH%Wn?SC25oLi?uh&@^ip})CI6^@{(vTeMzKEAj<D%r13$g{H`<Q
zXSIu7B5T*O8%#2hNM<s)pUx!KCiH>5A4fXB?WFVVE-$(kA-B2}ITtBO^7%64$4z#K
zkeBw57n=dar$2MjFMKK%5U-StU8GP5q}T=#q?^<P)=OgoXA>v-j4t#wf56%+KGYwK
zsxL^e;9=hnbzZKYQTP!#i{b9WJkH|t(RK%)jw2uK1pas}8>(3CzhbdGJgQGx#3~Ri
zxQr-W+T{qN^;x;rr{kMCBGJ=HUY-GXGOf+gGXXoMeq0rttDxd}mWiiU`mj!Aw6`02
zlA;Qx^nTBd!|Cy858UVt2FtwzJ%dOq$EYg+gACp+FvbB{GJ1~kt4jgvNrPn&-w(wx
z0)i6DHJ#sS(Q`rTh;V*;2fN35*pE_g_&oTd4qeLdYPiERvF6Osgv~0t!i-T&E$%{z
zX-)?Ra6Q2xpgj*?Sgv9oYfE|&=*$BYL!IK6Cgr0kx)yNqPn&Y*qC4kC(T&iBN6{Yb
zMZx)RY@iobJzVsLS!+CXs8Bk_G%7Zi^_BX&E2Uzor(;o1wX0gGF03r>?C!2~SGqbn
z7A@&2w=Y>xT~bz4#B)z=)OVq9@q$W6dq*308z_6oOObA|NnD3-mM7&|s9sebF>g}x
z>^$SfHpGM*fzelJe$i{=anMwGa14^Q;up3p#V^<)G-USplaB~*fm{nt5{&Zya-;z^
z-tI9RMFOT%uvY+f7<o?36f_^c60k?-0K<aE{?d@r#qqwe!}I+-?6HI~o+kjQyKP{P
z$X^ft^32O?{`A@a^Z=Vf2nep4-&#Tc_&wwct-pUYXo^mj<@hrExZnH+6PJtAaa$aD
z<#GkoF!J;35RUx=ahho??)3&ons2~&9G|00_v4%4q($Nr7~^}B7oUrJixc0?4aV0T
zh)-aQ@2y^ZF7EA4eDBDJk2IKX@~C`Y<J8Byfpg2?U2yZv;al<Mlft3n5?iaRJAM!R
zvh3fBx5T0A9BVlNbL;;DaFgcy@n*VId?<t4@XhDn(818w`Wm=pt=O^0(bhUMdM#km
zY_TOBr*;kNlg_Zlmg{+Mbns;RO0_4(lja*8n)5i*o_8#Gm(%Ha#~*hr=E>NWfb$PI
z6eZbw-tosA2YzN6ZgS#~G+^G%`Q9@2u}sIC9Y2x|*ALV3zoE1kPmQF8X}QITN75pv
zwJk$>nU=RXek3ifAExD<p|psnMiPU3t2KX4T=hF)y|43wPTX7*$o~I;XnWI#0G9_R
z(mrJRe=|OD_;w!6G}KB!WuuN&<^elPmsW89Bor_NZ|xiGF7=(Ned^v;i4pUT*W=M?
z^HZJ+>!ovb{1*y^aBS#u%@}_>%1*cUTr0n2tokUv-M08KxTSs5-$(G{`iqa_%_oHe
zCBcR7u1n-D9@Ok0Ve%muBzc1w2Zx#&qsB8I9PcgztU20YfEsoPU|8Rj7%vH%6YYqB
zOdCM?PtPY!{j?_KtJrU?v~f)T6lfd;5*K4kH}a%c_kGaOZdbZK^@TjK5Bwa$&Dw)=
zm$gjhg)!w+E{@_HIW0{(330%nrgdd3pQDhD!;NeqZpcnbwh%XlHsxm7x&Fm1{>4rI
zZ$qEU^8O;yj1$!>xF5CD-94=21HukhFfCVn3GT&FKklU1rahUuB7B>Mt8jO~{i>+c
zKh&?oF@0}{cI+sQKz6S7^vm6Pguj{azBK$6!dXJ}ZsMT~^bW$&<0{d{z$r)F>hZ;w
zk%sq2#VtjfCB;{Se_h}xU*`QQfc=gzCu;&fJST9Sm#@O_8p2feEU#`N%*~?1$LASb
zoJ|LJp}|R3h4(L(FiJKnD&dU$1W`PHC(<BKB{x2PqP_hK2rvD@*YQnWCBF+_90tDF
zZTNzRWkSO|G}et%A5D3&yytl3JqB27)W<7J`gr7Iv8-iG!simMxE(;JE)P@w`+BkB
zRMo?0k(R?13<S19x|jHxG4BB!ZH)&M_rYpnL}uGB>@j#~11(zk1L3bUcvNu;|9QlF
zwZ<#{WuNlGNJ-D_*0YZ5NZ?*#aFUmGn3ugg8Y=fuur_fL_A0=}9N0Gy&ubBnDT}dT
zoR!Y{z6<a-nEp@K^aFdBp{`N%`ELRz&xexzn3{+>U5DlrLeX=uA36X8ME3hO=;;0*
zXGP(g@bF#pnxD$0@;2ONI5b)*ZX1O43h|s9#F)6g8`Iaa{`cVK7;-n>9ACbJAMbX(
z2X8)1-+@RU(?owiF#gmy<oHX|urg>moW;qWvG0Q}<<lRU_r2!*BfQhJtxYLS+u}s_
z{fVLVQ@mx4!*XU=#u<;R$j{FK=R@3F<lEwGn%M?fChWVL(FUper;PRqgiQ$uVQB(#
zYE$${_!s$^auxTG{TMLWLq>V+XX3^R5PhJl-p}?6!0min!+r@^1!vAxhX=>F8E4dp
zH6_|jR2#*4xbTC1LPvo%Kv`)v_F(*4!HHA410`TT6l5jN?|P}%K;8TpYn9nA(k=bs
zZ;@`c5mlGXC==j*2bg=O%S~Eekyn|E|LIoJcpm-fMgt;YGDt0{Q0aZ{H+f+m`7L?;
z1HN^ipxf+TxP^D=@AvpoCVT*IJ}De2864a5K~8`3XTYVuVLVcnf5A6t{}n&CKOk-D
z2jY0WJ|G#+wwZJ|i<3U!Z=lQe_;>Su(7gYFH^V1s+jgF&ZE?~E{L9e#H{Q|*Fz*b@
zINkh2Phct1U%r*Pky(4RzdYd9pG`me1NxKx;Nzx0_#^0N^#@7T-~>a@wf=-KexLA9
zz}!CJKjQZKgdEc6_X$ma)$0?QReo)s!1lsEVVZ)gqCh|Q&}uKCdb<_n!bj<un(+bN
zd@|<Oq7SETHjf|ily`VH>`de_Oa3oW%U}!C+-{HSr;=cdtXhxuImi;^74pq8=t=p_
zbqtgp=IAoE)Kq`m6deFK%GRActMs6=${*;IKXuQ3#A-s52AlNcT4y6X`w+#S_$GfM
zNopOSUO#{%hpU^0#~?S*jk^;{!_?qvkXg^da~3tgT|aOL=qac^jTK@C&SfVh<wg=P
zwk$*5bvzr^6<4oay{Wiy_1Y(|S+(iR4Xc)~T(y#Zbi9H;XY-m(t7CMBS?k34#9YKD
zzBZk|ewALa;6ikqH^l3MOu^s^ogrE+aQ>){%fKtu?y;>JK{(cJ=<>y3!ph2F{Nu(t
z4d>MxP!uRiCf#fks!sImH-VcbINQ+6ZaSt5Udh`weKQ2!H@KsB5Zs6Jel=lTRxuwy
z4;8}Cl<<(kfmei?zgYqwLhmwQ;j;x^9oXJGJUBp|h#TJ=!H;4Y31&Ag?f}6Jj-V%!
zV$<n7P;g8ECL2_o^ZpF1Lse^G9*O$2rFUtu*Q{4d!gQV5^)9%pa_cY>p+{|1IN)zx
zuMW(_cZuO2w)MkQd~CVt5nro)5=0e0r{RTgCx~S7{ynB+9&)9Wlck-#{g~s#D}1)$
zMg^pG0BM4)MwP*1kfwO`L=`illWK%j;>MN*jr-SSC+p>~R%!J*Hak;Z;P=(*wrp6<
zGvb(T@bc<)o7b;g4glTYv(@WXtvf^7D0DM$Z`iPIgZ7Vnu3ood(}pz{Xm^3`(>I@S
z#;Og)6&p4w8haer=8da12(2h*{cc>f>0AU;{-eAD-$bac+o;*X*RET;DyGu{_=<Js
zoU>ZT7q!B@anlBLGMe5zxR<Y4vu*`)wURcI8HXN-vgf?`@O0Vh@(Gu-!Ray$ubq>A
zLbXe-L@>+dPUW|v$`fBqXX1M*tOV(^YUrV|36k3!tfHjvszPs{M^>GuxN+0+4VyNv
zU%mE>b<6ee;X;sxD~vwjC>5&Q&9dhBMI8|KFb?6A=IZeFYQ=@O0FJflmyQl<T>|~i
z0c=z6C@#{`;YqJGs_Zz=anFVOe8+tl@f%@2bYO?mj|ZDae=FFftU%F@C|v;Q&!^u2
z{8+%x=<VxUK8o|@yT{ZzLgtBKP9(0cw3TOQ6Gr=BTeM^2w!s}+(7z1saNr$Lxm)tj
zdr;_q9`d@tDHnk^0lqlewsEwwdSGab`#f<bFJPxC*t)S%0!`TxUQqB=!^60@jrWX!
zNApL5N99==)vr71A_8^3W%b(5j^Y`s*RCw0c`rBh?n4U&$VGO&G}_7D=?Pv?Wmt{N
z5NBgDPxnHeYL0qFR}5FxjSicj3Y2^iHwQRwI$vJql@|&dhns6~TZVDLn?hM$IXoIb
zl~q~uXJVslT*vb)d<`l`(UQ8Cx@mLxhjlM--e<!!Z-L_M#HdXAYiUd+Y(C1mEmvON
zr_Spit;R^y5z7@e^ZXN>`Y1r}*J!!Yj!Zkx5Gqr*RIUuwwx4-`$-Q2t8561OLYDzI
zIJ%7%G}WCDK{}L&pkLD`;2?d3%|qHSvJH=p4MAw=8PrIPI~uqhy#ru^9<a1hWyfLJ
z=S;_)eou7rhOt78VNS2&bz<Q@N9I+}#vGjTc^lGsgwTa7ew_I}1LeVU4j!-EJmVko
z7kH&Q*rWEh9}hU@JH6C4V^jub^%rrvNC^w#i@iP2^r?m2m5BW?=5F~DBo4&Kv@4lR
z%SYK+2zye!XLwISCfyx6lDb`daSPg*zPCEnFQ>{oMbs~HMNRW&{WiZv_w^pfGCgeb
z<TJJ*+AaQnZSyyvjreW84Scg8U%Sn>JG`|%@3;Bva+NmEvbC*Ow@1RV+C2M+P@Ctt
z<hS`BB2QUu{uHD;tId-K+2%W)yoK6)qdX{W{Uo6mXzM2{oNntgoVLCY@J8A?+a%k1
zm&AecsL|F_NzZ8RsufAUwHy7G(j9;{sV_!cvIdK|`%&KfO~a;Z`eQ%L(QhgIan8@R
zcGREodlX|jzfZ5Jd*l>OcW`W=MscruE)7Nt)w+dcj05y)$%t-1-(Z=-fim^h9Q&S$
zyhUO=!WaReO^uV3;|S;7?ewQ*Ky@gj8Z()H%oED8CQ93ziako4GO`U}m^&z<q@m{W
z2!jEQE8Y}c!VZgyaAS{?8KW83;Zbq4f2c><)EM@kb1}|EdIrjJ;F!GJ;fKX$+)CwD
z_kKpFZOdGh5z2w}RWRi%ys!dp(J`^?Ps5LEZdT&WCxnynEse9fLUo@v!mk1y>K)H8
z?<eDpxLX;Q=zUichB}w_Mci5Vxw>uQ$eUR>j=^#I18b`4;X?5VO^wS%bDaAuSeK!+
z#AUok=Vt@*5%S0UkY_@;lk+^!9p@t>tW3mhZE73H*}$p(1bjpr%Nn?~QB)e5hSMKp
z3T#jw!^wggb`D^p*z$#SLa@<cngAXqjkSPRsxef-)&ZuJE5;AqV*?7J@ay5``GBPX
zY#{@mlTHll>r23J&bw(eIzIZt_z*)Gmg&{<k@;3L1)G=h=x|^0a$5$Bn<4`mReaYo
zX%LPa4+}zQ6HXP6+9@PRlQ#*66m17R!Kyq7uDf?@5YGI&X?P0KpjBJj;(Jyl4X6+F
zdOUls8>dn0IVN!%5k_?4JgbqgO@PtDr8^tS^|^>V1<o)XD(@F>KJ@TtdVaHl6Q^{o
zseYhV-+OzF{u@f$%f_ljrC~%TX)JxI-e=zNCu(k0_tH{{*fU(^5^7lLcPXh6XFh5l
z9!0yjC`A-2(zA)e(j?=?7UW&VBz|ABNA)x6Jc{$-mcEL(^YCLIcLCmf*dGxt{n3T^
zK7Nl4|1`K$;bDimC=Q=*Wu55wwe9NSP#DBnGGU~Dd@9`RAB*PQjW_!criW=@ycK-M
z>4wZ9=}zI014)zEgQ|vZ58kOfIQ=B!RCzFQ_9o(V`*m$ca?>MuA`O<E+n3W{AAWvc
zF7$mIX%IKdq+<}@Hm(}!KpDzfP?b-Nt2UfHKb`A~*teEJH^_?<<Zjxqw}Pg$Uwx)v
zQ?w1R-BTHn>8maQ-AZ*7t0HtiaVgxTQR`;B*vzXo-m)L*ha3Hl9x@CK!X&-!nXdzY
zqt8)iLJ#ThVyRLYhGHY`&j~m5(f3!B72fs3ev0*oQdVnFkcQl4a2Jb}9&EYgbqB?A
z-{8pDFz>Kz$_*<V?($t(?OO>X$0YVi2S+{m5k-fzY`^C9AQP-L3Zwh3Poiw)_6cKf
zOB)=4jCVPHv^j4#`Ku-Kx?_ni^QLg<6}jh~`fYFp)Cpn}8XN6dtiSUSzT3MX0(1P(
zdv`e}+l91fcGXlzaUciQq3K(3wk!yu5S?E4hww+?hgcKtX>i|bWN^y1Mxt<J;=z%g
zZ3D5cm16olJ>$bYs#<oQ2iUO@{84HLZ%|IY9BDl+VhU9P73}GN9S@%C9jZcr9=x=K
zQHy5_(EmrF4?77GM=!T57}&3{XB#k-3-%%pjPUSR?622x{#xNG-Q|(fm2`nk&~X}{
zfp|{Fo(7GH_KKYTOu*$4IXzWBj+~ytp)lD8?gSn7fz(?(3*Ri)2z!y~rVLN_EvlSl
zewK@_!r>1L%XM=u-zE1(<)SM|8~!-=pg+#>_|1F%*oV?h8setkZyhW&^Q~Wtzx7!6
ze9&W<*RXEE&o40a>E;-Aa}C)dZKX=DB!D~-ua3v!c-Y{0r7G$P>%m2?NQEk_?^=E)
z7cIxWAuL=_&<yOyib4lZF`w5m?I;t<1pF46;3fEGUS!_%Qn;lp)8C8n<Jy$#@aB`k
zfs)`D56eu`%eRs?<7Aju;G6VbiJ!k7<wXXk;zBvg+O>4J<XD&tXK}I~<$BO%Pw^`A
zezkeufOnd<U2{TQlD5T({P9{t>ve_}<B7}5@CwU|WkP--&y(&O;NSYQX(s>EANe0F
zy7$xQS2(`C4E|F*aB6MNVYrtgoQ#38HtjWlVW1piAHi|`Msa)VP+kwXv(Q1w>u&_C
z-a3?<;0L{|jskqg_Q7>1Z&GmL>^SFhYG@sQ?Of_HE>$)YXdi6jV@#Zp8*j%vmHjIF
z4oV|s+!@`cEx}4}LU?mDx(%!JAR=JWQ?+)pmS`(h@8JxCtybqUM``|WH_vc!MBTY=
z`e@Q=jR>y}ly{|ZbGg>L7>*zN&VUQ2;c$gZr(<4(VFz3Ma0)nAL&SNR9}QHu>eIn3
z963K$rMm}L3l%H9TX}+r9&b3F9v6k-$45grg{3%z+kUY(NZa=4{{+BMPQ`BIbEs5~
z$2#Ipj0S>XP69kD%*mvOOrTmu2Ap)A!Z043eSRC)ohOS@jh)0TATC*yF%Dzh7HAnD
z**Vo`#%YE<m3Y4j9ejcKbT!8GVHec+jQGzaK3Q#X*fqo@t4{5oz>%Z*o1Hed-mJMs
zi`gvuC)UPt6y%0@->005GB!lpO{EAH<LNk~+_i;q3FS=L3o@3$Z|^N}=`!FKDOsx}
zKM(bJ3*y$}k+-^e=~60Y`e+ogmzO3$W*qavVHjgS%C*ljhVfg*u(u;VcMN+6-0W-F
zC)3~C;N}?iPQ3ZZSoa9X1Sx-*%f8$AlfM34aFf=pc&Ge3b4}v79y^W`DU>*gn}hgb
zoEMJ$PYBlmJ!!x`q-|s@dRD42ZNZ6>dO+<h4TYgTiERU&SxMEWIg!xF4oQqD^LLoB
zi~Pbqk>e9;Hx@q3MFO!t8S79?6#Bdnk!e4KvV*Q!$7|AvGR=S3lr^bxt<pr&_(9O%
z_<B^ZtVa7)8IAU<vLPRR)cD^J^sm!!8FrQNF7FD})nr+&_jlymARaMr9H)JV<uo08
zkh5%&${fheHE3Y{L+E_Fd;5Avclpt%%@F}FDlc5KWa|VguuQ)*inyCOD=zCjA523Y
zW&J6qtWg)Ltg|9;vYO>ZrGfeVB<M1~$C~+(<o|7O=gk@f?tz9Tx4bRBR9%lHgf|ne
z)_q_rijxQI!(KC3-pH+eF@Iq!T|bQRcvzjXu4yp8tx@-K?5C=3_vjNhS8!e&Y;%Xf
zmccC;<sm&@e*$@d-9o{72Q2KUoQ4gWwIH8?zhm=7q_0?(G=CN_*ceq<Aiy<hdBR@u
z8P3nme-3zg{%Q7l2l>b;{2(4B-!op`En+RqKwot`PE6BX201WD-TFj4XBi%2IYKI2
zQ|_(k3NiJ>ddIpVfa8K!;}hXnR|L2e`U88JX14h+I^`g3zD`QUm1ef_FCY%~3FOat
zNDI?54g5&lw_%JWE=w<=Y>lJaux<exb4pmRSjD0elY$@)<#dfHC$0rT|A>W-kbkHI
zGUY@#`bLbVoY!l<A`I=&#ANm9Y|}58tNKGI0LIYyBynws0X8{j*e;fk&QY%YWPHpQ
z@|wTXDd)Lp@4>X!$rsD(tEMdPFmmxn6y4&`&hiixb5PE8>-=1g`7`o3st{bn0;Rgh
zjN~8YwP&cRv=q$aNof11e-v(i?|`w_5Kh0yAK=3Sa=r)a4|y1^48r(9uqjv5hN0uA
zD5*m9AC#@pjv=~?4qjTs4|g(<_B_DnMaBN^ktCe5-2AAx11AV3{FBbHh*vM39l%zc
z!5v}{Aw7mWF~;xctyBeTWM$wXdzMBp;9?u9F{Nmnkv(^KNY#EmhBAiixwYR7X7bE5
zLGCPX9|bv#rA!B51#LT_Wl186WyO^$Z|Xw%1djV2&O~{{$F4YMs&J3g8fCBL0BFy>
z_&CzG9&uGiF*fQEOT}{s;A@&<xb!#Lhe<o@c70P3I5V)C^nV#)H#K4Z<7j!CB#`++
zQ;jZ2!fF4C$GWc|+=WfjhL9czH@!o8z1i1+ySS;?UEK-+UN`5s{ZX!h8Z7?}_>rg5
zWCba=S%_T4ws0H#v+tlh_f33<WVVY`-+Xmm=<2r_Z<G7|mM+zzE@$+z07*j%XV#R3
zzs+=9i67F$?`x1Ik!!yLx5%l)-HjjZLf^%kPa0?S5R`dy@bf+RrObN|-qab9j>y|T
zAPjMn4*MeFeu$rM3t?Ty@k1wa^;`h(NIJP@j5Nfbrh$E8pv5Om-{J<8?rr>KjH_SA
zO2bNQK39F=<kGqY4&G%s|IFl@<-u<$k6+;X_&qjXzl2-LnErl_ALk#x!kdrOnH%Oe
zp)jbk`%D;_i~JgH*2`~0{+&66q?d6pE%(EJoED^9(xTFdz9Yt=p5#v6n=z(QPxL#4
z)upEG)&B?gZVgbnq2I&p>YAv3qMu6dNU6I|*+G;WN8iwiz9JVfzZ@skZDgts$SGb?
zW8}~-^wqed8$K{T=wKCP56b-k;r#o4$qTchlk<BOP1054hn8<^w6}@!0?Ul$74!B?
z+kS`>epc<ysT1xiV|jibVcllW^12r=ciqE};6?|lY*jzeIGC!n{fPd5N*WMbFGbmL
z{V3Dp*3ln{=bB!eilG=DJj`%^0vu}-N<BCSRjC41zpU>rLdhmzEPvF8P8R&JUz;60
zCjV#9kOyOW-EvlaX#>rSWk<dU^{JOkpih-Gdh_}Q2lS!ESix@^``MYjt8VLmLpr2?
z<+t0vJ_xsJHz)++{*E8}*MH#6CylfGA^qz=;g{|BUwE@WAsy*Y{zI74zY>QHDyjaJ
zGEp2q+U<78Uwjz9;B>fLbPRYzaI9BL)8e*IpifPfag7$0UEu28ziG%{oENV>NnTVr
zJMD?**RnnR8|7o#Q!+Vd8|3*MXuEAI54W_fCXGw9t!BX7w#Br$ZEHI5fwnaR@KD=g
z`s=kV@;BR73uwqwuWfmm<+N^G{4Ha{EW{aVa~COo2(NV>DWk{N=J7sk4=8HM5~g(Y
zSxAU1h0OL<D5!C84&v7BEZ53!X#)r1+Z`Vdf?L`Z{T+ZG$JAE5`J`}ITqx@%q|F@+
zzie}d;GOdC@D;~S#v$c%D8A!3k-|ir7&~K}Gj{U6IP&Hr5LWk)wMtC$>0J0VYbt7a
z22barN5Zc==5o9=d^XqzrBz%fx((zWrP7gHhrs%s4*Seuz{!LDUhCkpYp&t?Wf^mR
zW_in&oz%%=5I5z`51<W8oy7hDmpW89ly!`A%KEG(y+7lvprK{}v4UCKx!wbKaFjCr
z!+U`@<*vICdmM-AKi&ttTh{DT-VYepuj%;oS{3GjFl`PPHOEouX(^^p*a@orearac
z>8VuVlAZ@E4h(WfruP3=<6q{(^gkQr#<<-1F!_Rc(b{=Q8hI-KFOI-OPx?6(x9aa;
zf*L4q!!A-D0Xc+4hGy2Jbf20I)5$fKwR{TAp26WVs-h-MwvopoFX{NxyEi%KCvEaf
zns(Sf+Xd%o-~bl2l0C_jlrxp#Em%#QQ)~GXeQ>rvBO1}~Y|LdKs~Yx;k5^T6$d}Mv
zBv})Aq1;9pGVZj`)afIPdP$SMSl>ba93x}@XKVk2&9nYvmH?mR4o6vKtxbBI!X^6z
zo>g;1)RjL1IC+lEXg#){_nHm*b~#gZJ!BH@C*t|1w2kmQS=w7EBS$UMqIrntj#}f4
z+Gz=`D>MU3m%?r|P{H&~tzlPtn#|Hny}r_V!|2>!)J`n%Dh)xGq_;rLlZ6!tQiYXR
zE~VF<dZDnP$aIKKLa^c@1SEgn-Edx#sZ&al$>k_OaO(2a({R3E&rtSG*h}oLGZe1_
z&nQ%uAIIML;0ckv`R&Ty$G|P)1aVKmkFxg@@#d4lK}L}EBx(+g!RA=_&BO0;c<;tI
zt=E$c3=YH0&ot1Dn|rJ1y`WGPn<rN)>osOg*qKuq-KO>^H%FC0@iQ%=*}HdymQvD~
z9$`NO=DYl!5vh~Z)Hm!J10s*|J{X9*`FTjs2}n<xuN2qA0)p0t>tJXM2{Rwh0<w7-
zF!AQ1ZQCSId7K`{v@}J1ChdK3ey2s3m^5Fm-bk-{w?G5PFf*go>OCu3-N`+&gw2jt
zcP%jAI2%ym4~X<$?gJxkh_B*W3@(V&=kC%*EawNDl#y3`20mBj(fX#e?pqdkz^wd}
zcc=#yx$P9h5%Y*A-%<DK%9ocJ-f2&S$weJ-^C4d)>DjxIx#pSt)CRwNcbfMCyc=&f
z7}5H%(p4>=*Ngtyzoww!%-eg1n)P)iMu!SxEI1H6eKX2FhXYgC?=C{RLVT8r%eiSm
z9dD2(t$I`cRD*!GLW*`qK3IocNT0NSe!J~|DcsV=iCcmn+yDRI%_ohsGNiQsQ{k8M
zfG6Rd^6&8p;}Cu-;5&{J@@FDW@RN%Z9ol_plN`4fBW&{Qhd?QzEm0m?2EVED0*-RV
zn?MV-mk7-IC2owU=3-?Rc3kzA6C9xM%c1aY_VJ)gIpH+KxjP-H!Yv2RlYeuk1Lo`D
z$m=s9JFEaso|fi@I8DtdQqgDdh}2oAZ7Uq=!s4txljk0@e2+)^oYBaPQY^!KbhJu%
z5vD6yFPm3#3*<l}Kjx$5TGrFaEka6H<)2qJ7}%}YwPQwX;cRn||F~xk<}zIIQ`~_a
z^SI?l)oDID5$S=vr}}oG#kz$3%GryTS9Y;^+>2Mm3{MY1D$S%npEgGsd`x;y23^Q*
zy7x43QTGFT)yUWoymQ^VKFL7Q83OJk&{rLiN-pI~oiEt1jPVO%5?8mGIM|N@rwm^P
z10KfRK8PEp9Gs$&^v|>|P<ASIbS7zr7Sjfsmkz)k<D_cR&9()bS8P8c&#nS&ce)}K
z&z=EXh(8aD^7$tNC(oHd{!9~PUpyWe=4iwreHg#pKI|;Gg@=h-jUW54v+?G0dBd_6
ziYiOcRV`|KLM`j`o`&Q0#7$jfQ!2q~l2a$cQqQ^;Wh^?Tb@*l-$(<YpwCg9Jf8{(y
z>WBW<<2SpdDS8Utd}L2C=QOloWrt~wHkvRz1BvtY4REvdW8IH*2bllkmaiBt?B74c
zyX{yXkSX$;4IRcWd%csBo`++7<Xg`{zE}rR-gIxlkL}?&%xn3u-Uyd^JKqVzK7+Um
z7zSgq$og_-9P3o-GwC-UU5GGz+_*IzTW`0a-gwpp`5;1la4bIp=~7*rzUEEoZ_We0
zR%>M4KNWtI+;7%85cV{{Jbpm8$Hkz~BT;NFYHbeNCjDO&``3J;`{A70Z;KvJCjseX
zA2K64BwvJod1Bq3GnM7+VygQP%5bbBEjQ&3nT7<E;HECX)dNVm+dgnw)NRr$vf3KB
zDN~p6PWg9aHHE`i6w`9_gOtIdxp^fMuns8$R6x&bG1PKRwEt4$B>52INs=t$L%rpy
z!0k?ACN<?J%^uM7$2jUAreloT3Y<LagJawjCPojA0fJN6cjsG=LY`zy<+nSgUIMr9
z2XVdlu@AWvZ$8Aa{l_?mci6uWF8#{@zNJr+FoUG$gdsi3Xbh(w2lvy4$Iub1hC=fz
z_G48(R^Y4Erh}K_2q3Jf>Z>L;|LM{-$^afshV5^ZQDH*w9X_$WV{xq5s!6l3S&5lG
zfuN*4zisvM3{4l#!3(cTR_k}Y{)I+pFTs>f#*va}?=adhbq;8?JW)yM8qzu%tBYw;
z`|Pytr8&ABM=I;@X;_tjtqdys^vLRTW;nW<7Ne`Vz|qZ&qMk!DnRpb}Co&;hTNWf?
z!J>`N6{YMSVgChoBRcXw?&JhKXZD6*B!E3<Bx0FU7T7L4hmbt?a$l7>+r@}Vht|vO
z#5enN!iOFB<@lENvJ2nDJsm&ZIb`pSZ90^+j$(GPE_x~IljlZZp<mQr8o5-)w`ahQ
z%r&3-G|oS8z6oIPRg`nE*}ib%VScxQ6Nkr~&!3cu9=`31V<^j2kD)VL_uxC!*VwZ)
z2L=@j4Wk#qn8UV`Gb0?!mhOCn^TT>aaNc~h_fGJ36ZAps!>$1B3@)0qwteZ+A+oM&
z7yQC<EAY7`J4GXeT0_9zfn}uney2Yc*}&qgPT*RsX{BsHxq-3)$JIW3ClWbPsX)nW
z`KTZCN|o)U0a(LE2eD%Zja`+B!4Cm1a-rIEZVY(3r!K*`j>WBmJu)#jf*;eWX^%i!
zghoKm+f^Pk+>lA=3nYxeC3FVFCDNi30J^Gk!@_plmRzFEFcI&_rM*M2S5kYf`!K!w
zd1QoY0`Xfje`<v$wjphGav67`IzFb$<Wt3`wod5u>5)<8dscLrt~<`Jl+yWNtPFd0
z40A>yHNxt1`kn*4)CcuwbVFtm`<p_MFRlc9_mnV(=CkL5o-e=A7IrY?_N#!C=e(f&
zHYEwsl3Rk*6tzh3_9Z!W&mhHj=Lz*RMs!rG=0`>bwXJTvro9aRPG>X0b{yLb{bY{2
zsFan_Nzk|n6gn~lGL9ElgJ(oO=C>;!Ujw(u$HYA!Kg!21z?)ARm!6Bg5PsRmz6fvn
zr!Ft1<@L9en;XL=Z7j)f*2W_1MP7=yxnATtydj6EwaV1LFg<?Qm%|Sq(FIUfBX*u-
z+VjyX1Ad1PHl5FW^eW?5(sVuCOw+6JrfkG~%Ut3$gc<#Yr0=zWQCA_dQL5}69O+R;
zBt6LobsDb+jNyo5e41uHdIP@sh+pRU#<|)r^FzPt!P)sYnQzje-OS>w&4f7Wc(ZWi
z2jUbzc|5@VEf#0T+`F4O=3>2)ia)GV;T-*1;Qb~yp(ea9dj>UzH$^W-T21$bF)tUr
z1a3V%sZrAym)Y-U;4og%ZcbT^d4E|bd{JrCL-fU19ip!$IgIxeOd}3l=3Wk*yfr-7
z?}-#DFRAotOG6mP30EjiPp(MORA$LQStuj9!1eY>3LWK0%EW=0(y(P}aTmm8WMLzU
z#tkR~2gXvz%93i*xZ&6((rGCLXmbsh&ZDJ07Jv-~VCMy3I|Hzx0Bj&G7p+6Y=A~gM
z5wwJuD4*9M-#jBuF@veg8_8ql3^qOg%0+}>U8z7--M$epb@H$?P37H~ZvwnjxdfL+
z;0!gcR#S9mMsEh(7>fpQ`GiRh`DAAF7T}bz$i=8|O}U$a6CK$@R}|2)+y5f1zU)SM
z=LE=Zw*V(kSay5J_i9=$^piPmab@4hJJ)F)8;2j~(S2xfd(RMTl%qZVt<{S=y2`k>
zx?EkfsH1C1+v0`o3%k3^i<XoYc64<u>1x+1G`aq^u5a90joYs~Iy<^55qY0u_1jSQ
zGWNe6-!k@7-XQKB_+c+_ysnjU8{s0i@!OT#-VL|N2gJP#Kgw;l;>{<8gS0JcW=WfC
z@3hV)-%8!Pd~+Qhzh#}?`#_I&lB<r!eUAA40DfuO)1uqrc&8u2!ha9ke81PcKZv*F
zN#bHT=x;5r-3~Wte;DsLPbjsIz|DvIWH8@~-U+wpf_OhM?aChltl<iR%*6Q|^TyGb
zb`I7PVazM`ovX7e=w`lK5SuppYd<UpoPV#(;S!GJ(i)Y9x6;P1=A1Zx3ouD1&)Okx
z&Wes{`k0EBant_)-{noIXWC%M6U!hMvJCw7n4dtJ@6v6nfq7eE;&`e#v^hiC3R#)t
znCEzgl^|FsZc!abAS6(Q^hC18y3BhU&Xei%%&Jjsq?v-81;|ci{w`@ae})g0wM)w1
zEEaH3Sp}^7xqRzqz$emY@%x%RZ1=i-e-3WxJBa%%e(bY8k2jwbF0e-P3-C(@{371;
z-;Q@o%bRB;amo4QDT#1)J}GPV?lAFu*}T7kcPf2ee4N+VwAgvgbalRQKKc@9I7KP#
zLfu{7=o%xQi-GmzW-X3gOT>BF!+DJn=ievC`J$3<;%kh)igMo9YmDwh9EmkXag)(<
z;Magp$$@B#Txaxk;N+>l&L}3VWiN+;>b1pBBOYms{C3;oH{lk3Chji$*cQKqH=o@N
z_Z#7L0$!?vo@%APaa*a^f$H*+wl$eCCrEfI`)108-$8kcT=-plv%X~A(L%I!e+?1+
ze-A&dJGuvNKC<qJV|QrXkqy%v{lJ8gbw}Ta+goRX`D8x&VGK8u#$LVdi1mX0H-E38
z!}!Ou?#S@PL%d${t#>1TtP5!)bpIGXwh?#z5#dsQKXt;ip<Iaj8N&qDAF*!T^+(ok
zKKcd1@NwhTbZq_cjt8zkV%^I6qmu&bkA4Dtu<=O?G3T!T9R9=>!?B!l_AdeRc%$YT
zq+iAUHP47_yiBdv;&h*a_5*v_w{Q*8ui;;w@vK3bY~R9p2<wV-50QWGgPSt2EB{LQ
z+x~G{^jni=S%>s(xG9hP4)2uzfP4_sa@HX|sOmDWWCvM?^nak|bwI9UHnH}j<~Vu9
zms#tP?nk_$YneJxSC5Im2W@{$r2NfwNq+!Np2pWDO?_{|LY~?_KHvH&<W0t5e!JuF
zAK@0hA?^YE*vI?{Z$8AaFNtvuPjUPpT>78C;#>MG3G+A7bHb1wZTk$T9uLR$1R>nr
z<6ajqnYyXFI$)}1fbsf(Q2DBQfn05IR;GWYSs%dmEb9aQjPJxmRr=V8wN~`O`RFg8
zS!<2J-+`BYd%SA|NISGffbgs}0uIj8<>#YBTC|ZPxJJN<x9%DN`mLG22G$5LU5%^}
zc#!_Mk<M8o@Q)Z4UL){N;N3L>bcfam{0nezjlg6Y2xPRT+`mE7?@y_t;W~l;04Gma
z*F1%s8d@zdRV@@_*5wmlFEH^k&S<lak$zIGJJxKOK|Z!?OknUyY11cA_O;dz<eq59
zFMhk@R}<Vaei4_)kK<P}-h9%yv<x*3eyJ;-jyL^NCmz%C#wU(zjp35|o@6+y?-5)5
zEW}M){cMv4-~Y=^drGIzt`P{~{51gwns^Svo8ve0BIEbLgqb;q#D552p)~=v4D5OV
zvF&qi;jROqUri?;9g1&0OzRNd#HlA>_qRA}J7754{j+eaN8%J8cy&kpn8n$#^nPRa
z*K&up`}=bl+IeSyuHRfH(Fpf_3pewq7Npx<127YAGtSV6omc}9#CdA~=7hpKYXCeN
zi8TNoE?xt00MppO8UQbRVhw<Yi`M{na8GW?MIJt01K`1FLRYqK!mT}BuK{40IIx6`
zJLzAq0Z7918i3XW4IGo)z#4!g9lZu13Dau;k}$mnAPLiJ0Fp4h1|SL3YXFiky#^o&
z(`x`&F7?&`JOY0FH2`w~i>>{Nk8=@W{u+Qs0v1{W@F>7TYXA-dJZlZWqk+p>1MnE&
zWL_GNl@IC0ujjmvMY??%jq(iF0~`*VJYgB_Vb$AZtPL2yFtRV@nF*~ASklwowy4sv
zcu{9{QP<)HZ3`;Zp04VmYPqwgv%Au6w%CaIxvuZf`hX+A3nB+R9^WDdP!=L?9)AA%
z0K!GDz;9PBI~s0|)f|tBI|@I_W%KdolfprX<*pB)9?aE`x$6L)2paA>fS7)MT6Ano
zU#|mr0^Cf)G3I?7-qgP_4C(Wm`PJXrPIw~ROy3E3$Fxy8C&A4})&U#|x7gQZ9l-H`
zHCz#sTnE5%Xk;D0$xb@mbpWRTE>GQc0Cl-a*=ifky3d1+@9#FIM>8qsPP1-EF%w#U
z8Bc=3G{?QHs1P#!>$Bb4QP$E{`0cipPPnB#5Z8ep+sXpG`4C5WJjQu)E%j-{smH@n
zpO%GVyU3zRS=r*Otb7K}s^Gqqqttvvk1-1ocen&6S}UZRkGep&rtT$k|H-Uq5yJYq
zl*KVDtxKUkV+ru)tPy>Jn!22BQtU-LMs6wS`eQKpeFpT-{{x&n;W2n>OI8n(VVYCL
z@4F|iFQMT*V_p<kZKK$0S<rtthZE$-xS#Olp>dZOM2m3B#!V@6$A#V#`6Td_^f&x=
z`<v6?mi~sgW%#kbDd5c~jZ5#jSPsAJKTgM+{wXKKw7foueOF_+w9dqaOY2O|K-|=s
zJlUin8BZ?qbtaZpT4&<oe4WWzCZ4nLrp|<ZMOHe8Fh^%X+*<rXIujd*)tRvDxL3l4
zvwJ0o8!}~w7Zw7h_eL<Bdb~2HjwB1mdb4S<a+j)i6Hf7jV<Y^f(UIt}Bztef3Z%zx
zB@=3O`=wQ@@he)1G`sqdRd8qNM}jy{KXPU$yrUoSXe9I_9xm38tY#V;(2scG6Z#Pk
z7wbnncuGIw;bZ-X2aok5ggd$rwHJV8;=mI6k)(gEA4$Treq>F8Mq~PsBpt0ENy4;#
zBni{{kt9s(N0KnDA4$Trek2Lg`jI3|>ql5F_4Fg_;K$dGtOv~3j}YeTN1g&$NI$Xx
z@Q{9FBj8#3kxjs5=|?sLm)4IwWQTJlmz|3=`*Im&7wSf~04GmaE_?X&av6$|@t!Ta
zUu2gF=|?)-JGz%F?(V8C>Fikqg-F|yu4+%Y(p_4-cnS0+i<0{%>iYKQrX2In2S3P|
ze*wN_%%|K#+*9%M^&^Cf490I)2D=DuHQt)=Ph)t<U`4$7q;QUYB#le&f4CTQIL?>M
zyBlxnI+zZv>&Uk<ANpJCJ*se%b_H+xQ)xo3d+^Oi^d1+&?dv_tfXU>)ZUIkH@9}=f
zOO5C~wmRu_^&Z<yewe4adXM^<Ve@J@>ppKazRol}Z<vG%I-b>pDNn!<TtokH3CdjB
z0>9n1&<D5hG;x>W$F|UqHy`3C+s8Oh)}{V~IQ4iq>OZn@Y#&)PssFGztN++w^dDj?
z<otdBafi!ra<xMp$RKD>R0lGIu)YrDvKSWDfeZtmr30DxVg|69wngSfK;Iv8*#@W!
z83j(B@R++VO1Y*+Wc<d1j5cuX#C0MQFZS`wp(Y;7yk&7u;>$!6=tHulj0x05)~XV%
zBiRmqlRk;xZlAOhZt0VV+kqeZq+NLPN#oM%N-l?A_AyV#oBk;)#I(GAiv3$-xU`PM
zhD+;6o`txnBiUopkc=m-BeAs7IuaM>>qwqs;<*xU%1iVs^3qj=IXV*Jo`+vZM`Ghh
z>qu<4^g0sa)DzH=SX@%qK^;jJj`c>Is&}uhI5t?E9UJ~_bR>Gb$zDhD4AAvk$|OdL
z{n*O2zT}xmzpF3V4R@BlB#86$CC?6pcl0G5jfB3$!^QfNE11Rx^d(;SgucYX#rhHt
zp3;|i_*h@!!DD?1;f`)Z=}TB94lJQBN&46Nk|a#)OP-sc(U`s@Nk{8Tk}$0=Ny4<g
zBni{{k|a#)OOi0HFG<3*z9b3L`Vy8)J$=d5@Z;-Co)4I>FCom=ms|r_NMG^-z(e|y
z7XqH8FL@DgS^AP|flKR4CO!!7$4)@$PF{@k`*Iv*9O_P90-QWyIqu=v`(@}+#xIxb
zCmCl#x|E)BTdA|sUhe4bDtA_vbW}RpIu}+Jv{y^*rG-7^j-)Q7u5W+7OWEK$@Q26-
zFT=OU29%G8dpUl-E`@NB)%fkoYS+Up@)&Wi#E-JttMKNN!Uc3Gak#)5l2?Nc<$)W_
z`!#q|m%=bwf0A!yKJ>TNrQ8TN<9!|8F>U1f^>FhMUCJxq_H`+*1xyqQbqjcsx|BxO
zki5Z3r>jeOqsb5RR9BZ$KQpc_rLJ$Ew<g5z<;9gscX>&r+SajnVb8(^mF|v(J(WsZ
zrKj4pq{lydrLJ#3P2~4Cp^Svz-;8gU--&w*em=hwF8t1Km)~!JTX>qd|HY5|{#LyC
zq;LU#kHdlAZ&PbI7*4O5dK>7F-`{TD@4%b<&M?C7%!kYG?}nT4z6<Y|HgbI{+<b)J
zZ-(3F_jdv&{9d<!C&}-P>JH!Iq|@d1_nQ1LPj&gder8;Luj||At;ThSLxcKIZk&V)
zp}5pv#ceN>TGyh7!c4N`U(FC)IR%{&`R@HFb7>3wcH6>ja0|Z^_W}Ia7CwkKAL2OY
zjd9Lgj%|~0X`8p>TiT|C`3UJbVa~!{S$*Dj=v-qdkm5+Wr0-gT22bB)gS;?Y6QxUY
z*6}Z~r?J_bb^I~JlP&}7L!9E83+!ynjADvvQJtx+%WQ1m(t*JpykCg!Tr@B^U}INj
zpW~$8ILFi(vW(<B=uhmoGQu@)=3+a3;cRG|D6aucRT){n8XFiJ!AaPLUvjvUZxlD%
zvApv9#?5w`kIY@3rYxHytdHsg65$?1nN2f%^{M?<X0~Hd6I=8UTNWf?`=cEHjkD-+
zx+g|F_t{@9OS)F>;#OA)*aA=+yZ1dKU4;ILXVZTg^^P6|_j-+?(^oa3&a58-6lWb6
zMY;orP78O5(bVAF5!Mu)tZZ#^@Z<w~S-$MEKC9^KGRC<-fwTTIo6Llk1I=5;p6kC~
zz8#9c_W1m@V#B85%5|GhU$aV8d(pZJ1)O=S>twkquAR7JVH!?$iw^mMQ-&ye8zw*l
zW0g8n`11(EF^%=hu}eKzr}ZWC9m1`Br1loV9f>p7_=IqBS6~Qt_1x@m9kD!_PUlA-
zl^yPGv|K)?Lk`8=qtPA66W?Dp@2{BmSIzrQ^ZuH7f8D&lfj7tY&)_X%`#14z<W*I6
z8lGz<fAd?;u=y7JeH%ZXWqdc@%)7_}O15Zej=lppAIc_-gLEbQ_u#G<{vHz^d~qnl
z9|c;4=}~+ZKuA_$I;eNHIIDO5CGHvLn(TH(SL>bWZ=~ASqno~l5zn>qF6{B?Gh1>W
zg1@P5z1selk3J0AwaybDeq#1cO*?d+0BL5OC*a^bJ+7t~r$sBc(Ql^j93TyMe}Anz
z2kPdpf%61D>cyw@#5#RO*wpp?arl$70eC;yC*f9-4P*qm*@xIZRgVRPlP4`)jb%9F
zvL(6;aNg~1aXJjo82&DBxEV3XHjqq)hN|eidC^395ElfE;F8HvwU_ey2p5+zHn-!H
z9vl_yM4_VB=Uy^D&?hGDKj0ae%-4m@GN!2<s<SkCALhjZH}l3Hz;C75(jPH!>Ym;_
ztJq)K+1o$XkAtWy)t%&7(kJegS-RdeLhpO{A!zLm=6EtYQZ(&*LEG1_a=teo`qdu+
zC(o_3_Q%+(_V(<1;RWS=#l-F8Q?}S}s;e~HJU)RXc$tYC|4byyI?i$JC*U!ebMxDs
zbN>u(H6DQpiTf#joOAyiZ$4>UdjG&L;Fmh4U*b*wY-2GkXTD7w$KS?qY1_CBm$r@H
zhq!4Q|E)<wGM=<;+|o+h#$B9m8^7Pg^LxB0m(Z`sC3^|G(#jdcJ%C@xHg4lc+s19U
z^!@?j)Dy6cTU^>Uo`qw*5vS_it1HSV7H4G?Ib(rx3C}AE-B-yo7JdbM$~yE=ZrSLw
zum&vpHPY?c#D4>KmQ6f}^K9b33x#)V;vS8JP29u9Hu3*s8XK^Qd*Kr{aSs>U#67qt
zOXVUDAKSz|xDqHRPY|x;8g)&DK4XDp;=mF%@uYuk6HmglP5ciD8jab+lXSFAJPFe_
z@gz*!#FH>>6HmglO*{$HHt{4(+r*PFZ4+m?)U%2I5q^A|_@4mtZQ_LaHt|0L7P5)|
z1@Mqf{I7s#*~I?_T$WAz@4%&P;t%D<uVu9dk#1jBqZ~t9_&<P?CoHQyta>}G_xF=L
zZqWk<@ckgiOvoPCUg_%WT)1dqd(WbU3p#t+I;u;0I@>zROR7s2FDfl8CGFpJefu^W
zj{pAxPssTHZ+y%6PZ@}~|KR7_0|^&-jNh(2mOs|YT#7c_l*gLz<|Fc0jDz+{&RR(0
z(q||%gAT|1Y34m0Z_0?Ir*$g%R^~&0YdzIW_#y2UyyJM0>sfH~5qn?+w{H)e0hrhW
z>lUz?zfJTmg+}e)vz>Ih_P{wNKg?5Idtm*{xc0!hzJ1=h5A#E;^z?O;<I>Ged<9ZG
z%gJup<6kLLNY8GeP=(Az{yPw5FKvR~ZkuR@TX>tegYaXUI2dm}#8KXlaV@q@u#FNf
zZFDZarHx9MLjiN`g7;6#mN%JFAD2aMs%l^_^E+|7+~o2*4(r^M<u{+3j7@EF`StW|
z<F%|!Ss6^vP2RRPRV6VI3)@r`gxJ^~jXoe`W8+;Cld-X}oM~fwtfJ32)ZH5UtskGP
zrERLpnSC_Nn0>K&JUf?<bM0I{&b4#-IM>eQ<6JwJk8|x@KF+ms`8eOs^*H2@cCI7L
z`|;*I&%BQ`@1xB7X!D+rH^-{S;4Nd-G59uem?}HM#WwXs;Eu(Q=X1KYEjtD_N5=ur
zhvO^hl9q%&p@Hxxn((x3F}!cvvT@n*R*lop8(EyAH!`-ZOCVp0-iZEu+ZOS@ZR_NK
zZR-$(%@j~3u?Yjx5A;C!=n<e_%f3Z?!royFQ(9M4`%Z0!4cWH{&$4ehI8P^|(;BCx
zhJDM4x9)k_^c&NpJ;%>q1NN;)+I(i-sZIUiqu|fAZyg4=Yu{qK^Ttl4cO+k0xV3LR
z0q`vQ*73ki#J+VB!X?V1hJB0q3E8)puaJF<cQN_)t&`z*s_a{*fL0Cr)?|iqb$)mo
z==*vT&S7ZdY6ni9u-;@JwPLN|$Rs|29gUfDnCm8P>za7k2RDjjW_MCOVmu>E>5IlM
zA=K0ujh|fR=~*22I>CD~ujIEouUrVX%qxjofFI|TU3l|J<I?*=7r`&}DU0!@f9ic=
zS}n<Ok@L;QaB16@4VSikor<_=`+AZ|Lo%MU?aR_i+rC_!Z~H2kc$VW$S%rQ@R#`!q
zWBVd*C4M2>myIKB`?BHE`$CCRPr&wNamh00zR)Zj>y0>7?=8u2w0&8em0_k&)Ax!~
zZV?$KbiVi!;QgjDi3YfTTe`7>Ekzz&JJ|ogon;3L;ygRpvQT)(4(8EF*ugwpYzI4y
zX>7m_=7mq#!8}}S2lL>b%$18gd~65v;ISQyaL4AQ_J*=d99Y5*mh`XfU`d#^gPoqB
z(U=`9Nk`kkk}z!tOTx4rED6(gup~^|!ICg-2TQ`V9V`jcb}*JpJv-Pc`0?#vX8`8g
z!3gv1U{3}tWCuGF@Q@vBHQ-rxu(N>6vV)xsT-pxya2fKoO>7PF;LCQDcW4tk2RM1c
zvfabB7tFAajbA|7U-HfoSXVq9mBG8`c;_-MagBH%clr+I>CrmW+Z_$t7|`nvR7%5@
z`umJ}2euYXjhidq^ueyN{Fopm#>RB0!pfki9R$*baCgIbNv2NUy<E#KolcvVqX5CF
z%NJ$X4X7)TVfpRKu$$l(IhDAL_)&)4j5nXl8!i`fH)k?8I;&>MV9-ZKMX^q<39qjY
z=sts#xx93=x^vW~Ve@J8Yx=B_mTt3dpLZLhH|rkj>8TDYdt*~H1_*S#8irWMu%4Cs
zE(ph3egjuKdDOlO%GbCznaS%N7?T^mbbdiTf4(Vuc;h|F|CRibZ?+&E!Z+u|-`b{o
zA>6_@^!HT!$Tv^Jn-ArC!bQF>;@g$)iMtp-%J=uo*I`JHWn*zo(NmoL1C+Ndt~uIh
za7?R8-<~LX8|o>vo{TX1F+8D{y&F08BEW-uVK|3tx=QdPx*PH)Vcmdf8H4Q~+iSoP
zgqLHurb_=@J6r)Aykn9O?Pc5I-J?|nCr<HEqxEh18UsWy{WbWRWyU(8PFL<7-3mAR
zez(t;I<|eov}l`2uiQI&F5EOU_u`%M-;$me#k8C=h3`YXao@sxRi_VNjd?!01oV>K
z$)tK))InbHPu6{-mm)rqwG#J@POy6iFXZ|_)0cfX*6^Oue&FP3{GQPXCMF?`xVf9!
zvF0hrlk^$<cE_3_xP?E68^n)&#$|Z(k@g?sS}gCdKOtQDlTm!T{Rwen__=m?(qkV?
zoO)U;J>qyCU<h}oW6!<<e!@NQ<RzMbwSHenH}PH~=2exsR}R!wSe(^WTx;$XWqYNr
zg8V#;??fV1FBDWS1iK{NX+fG(eP})!0liu_lI_4tzdPPLMM*nkBOyG?M&jVS`FcJ|
zqy>e5%Q=I4fSh>i+DPcPX8szmkuY8Eo+G6X(CO3Nr>eVI(GL3a?iAe_!_sF!a?IQX
zyx3JZhS43mQ}lAcy*ouG*imUddphX({U+xdyifEQz{wLnQ)o&!RQH$(Qd8GgUNUig
z|3u0)qk&Go4~yqzW}r6uzQN&f7nKrXoCJ-VKutaVZt#qZOZ;}nr9E)VxJ2Bu@Z-4j
zY`poTacLRo3izdb`W(FJpL+b5R!ef+p^V!YF0IG6;nI5i=OJ$D@vk;%NXC=a<6By3
zJ-&<c_4qF^@w^akj?45b<MOqHU1`U1;$DnjNRMyhNbB)!xbz+t;?xt+<6B&^%&EuE
z!m-|nQ}y1G49Bt2;_TRXw>jTY%MaOmSgr(JziCWp$lRAL*vx01i?q7>`m5kJ<3;Lj
z&>#*|oBsa60gmmI-=7}}@96728VP;9hl};~*D#F@=<B`k34OhXi}m#$+#COMk%y1<
z^&ULd*AwpO=9RvlW#YgR`ue1Qt*=kQw7&jD2^x**>yvb}zCH=l`uZeH>+6#+t*=kQ
zw7xzG)B5@(OzZ2DFs-j=xzy9wzXX1Kef>)T^Y!(F`TF|n01N5sUj}$cU;lEzv-I_^
z04_^k|4QIw4jGSy54i@fWvuIwR$s=VTtdD4tALXyEMq<7d$q)jH?E6uixvA$E^+nk
zr?sNA@#9^WA$|J|sE@nGp^J3{sd{GPfP&iCm+WEQNhw%N80nB$5>rS|mkWg;kmJO?
z4d==5o2$B*ikt<=#_M{fAb-@ey$*FJvM0Y?+4J>qi+oAkjrdXad;{Kmb~ju;;pw*2
zWK9)(My0WSuAL$syqk`?YWN!I5j{NRIrLupL=VqAgM9wYrVbd>MD*}em1pwMO-PII
z(3|3Kt&9I(xP^!4?`HhSL$~0~hcY_hBBQ?z->!^K+}rUB>EbP}DZ0n#+ugWyxaQ~w
z2FJ9j^zDhFcNty0zrKZf1^Nl;;@=8*9Zpud_jkab=uNaPsVRCVU?F|{yJEPeO#jqn
zyc=-vP^^z<TcbYyRs|<+eEN8|zB5(wHF%q4$GUNK^6!P4I(c_okn*?v#kA;sCe5Og
ze<R$~$-f`(l>e6W94Dsb=;R+XI{DA2y45oM2S6{-WlpXqR`r4V3_&|fH-8&&B3Dh_
z5TNCt4}!KY2XS1Yj{ZZy$<w%w-f%+3oNYKgu1NXW5jRlCQ#~%d7I~9Ch2QSD^bxp)
zZ-~1cKlUjf#hVXt)Gx%i7RyuYZwQzE<`ejK`y1juiC;)pPn>#MEIr0WU4005_qcWS
zlc}4!8vCh|jAETV^Q_9=D-Y@=EY9jBUTJjpY|o;z{}{d#0-SK$#Q0O~ZTL87*3#R5
z3V7+C$E&v|?U3G{@GQN(gY)L?`6!VVt<VVS?VWh*>h0;bX8sz`+cRB_=<PpEf1cj{
zGchczxBo2guHK&Rkly}tfO~rT$utnPmjCmh>G!9cyHI!k1>ocf&nu^pQ$rg3scNAZ
zvo4>w4u9fhoY7{dYQC4P&mVumrDo3KCs9+U|0VE}j9>hA$FDELE#nt)ci_kI>nnKk
zN#oKo)K}q`y5T$Vrhn@6V_GfA@rh$$W4N?V--b);^zTC4)aifIq#+qkTBmPmrFHr)
z&e!SRZQ}V3-W<Q_SH|z}5q6~=^NG6$zmQJf#*x<P+i>Z%`NXLwpwqXwWSMggn1y4#
z5vS_CB^i!mr^VT^Q_iK*a)#FF`*RoSwZ8_sMm&qvN|P8;_kD{-U&VDvUq`xK{r)%L
zHseZ4zaPYT`u%T(!aMqXk48ej@8M$o{<oRN2K4)0_=JAn!^Qf25AMkcxyZxE`h5=`
z>-PzFboolZ&oXgf3H^T3zt-<3VOqcc-2{!s^!rIVTECx!Y5jf@ruF+tnAYznVOqbR
zglYYL5~lV0Nto8}vs~)w_rDK6zJC7)fcg4;!hHSy4*?75_wNNfq~HG$;92_p9|M=A
z-~S14G7o)tG=4qD{VCGz%Vd;asO$e3aPov@vWHb~m!bC`zwogy<(H$d)_w*Gow^-a
zYoEQ|en#{Q)R7xT>;>62gBj7U5N2QB3ldOeaD9r^V`Oe89k(GS(}r+Q!#Z+v)V-Ow
z^$re9!G?q|%_+*AI@{<z)T79`{C4Hs-@z@iEOEcZk8<w+;mwCQ%8W6tB`FJWeI#+}
z@o?0+WZ@`ZWznR3WpP%%I>X$T{1g?R?w9Vzcen&6WHiO}g>>`L??Jcb{Je_u2nKuP
zplG8QX4qNL9}w1`Z|{v^>G?L-MLqz0)?LXHS+IqSP-e^h5p?~2oBYl@lK%vpJmG$O
zYD-pktYMl{$?v~GzJ%ZT?ehCy;TC=;?l1U}-~Wa;AK~{H*JAmd^BTfsUh@xpyYm|2
z{)yl078_>Y-OH2Ra|X1G`??q1hj;7L%I7#v?=r_@r>SLZatMzW`|v)TbjoC{vwMb;
znmnK(P2@hDbPVIm`@X&pC!M}f2~6a)uBoYfIjbu=jy=V`yALO?=rfKiyK!c7p5UP8
za@c>beA)N1Y}t>h$2+6T$GK;8`8fBCE+6Nf(dFaZGrD}7dq$U!bI<7VasC-y&B)_S
zWN?~!PdD!w=G|i6GtGOJdC$h1V^9un8G{bM_wjo)obeJaXKWn^_d)m-T9apV*|DuT
zY6YGTZO5cbS`z+{2EsqWgy$Ju4DX-OW#h7Aq8fi8<5`@Q@#Ov)EjMZ%8vXfabP?~L
z(G|LX=I`(~)vZOZ7sy8sf_5z%7V#64AvNug4U06hY*-G?(@kl5aay!+3PCJ={|srk
zHl<qk&(zId12(LGdGRUTmrkEn8i1d<-s9i!C-x}1{{y#sJ{Ni4p2MX^NfnMfY2o&K
zt~r2bozHbJa1%M7Yc9gYWekH#t@~$~AIRLP`)8Q1(D_`U`)3YCd{cEk*CRoz#`#<m
zoPy{%+M__*pM%K#Glu~uPx$<XDQ~@c8j?wNie@6vneU_fXR^ekpdBDHn-i22vh920
zm9d~5%S_z(>!8;CGmim}$$XIC?tJiYxMe;_++*?MeDHC2^GV~<dv}h2U+Oa+k2n3(
z&KJ{aNsfEer8I_1+xcv`w4Lv0#7#Tje3OP`JZU?hrIohxxj5g>_e2xVv3OG!p<j_j
zjwkF&T?P{W34n#{d^V1>osT#jF1>e$IQ0bVd={51bK3c`aI81tRK0t3MLm?oSs6v_
ze3VP%46Y-*^Fe9nn+Lin&G$rl(*4!4jh*jEq}#Rg9R+umoiB*<?0ioMg?H?H9*u;Z
z&%?!bzGIli2JC!Z_=KI$!^L(!5AMlQxyZxEc0LcTgb?08L%5P_ocm{3CJroN=S%w6
zcD^J`+xd=5&}hugm!zZZd`XzL^Ce;0&X<H~J6{r}?R-g?w(})n+Rm4RX*(awrJkMd
zMELRTd?x|s+xZCd?R+N#7P9l50(i*I*9Lf&ov$6ZEIVHZaA`Z=L%H#5S*;W4_GLA>
ze`W!2@`PozhgENvVdr~j$}#)lK8}D~X_lEaVvQTWc{HqH#TeAM%`t3Cn8aF|SiB8W
zp0X9x$}YDE?MdWPe!Ft%61YY7ByKT&luMW5&4)P3STW9%U1*mhPCXuucDXDZ<)JK^
zl!q+N%0nBBT~5|L(eCs=h&x<{ldB!t=1v9e#5~(S7rcgT?nwyi+vb+Vu&{0JG~lyr
za}!^P30BkcR;~d0exJ)WKpWk1;N%&Xjc!s2t7)m5s+O+WKo{~SZGhiy8(0aqv;pE)
z;Kw$w3U5Br24bAU=bW1mE_0JJ@$Jq{h+B=HYpdI*_wLl}UB_jyo3irXr}ysE$?rHU
zcT<+%eR}Uso%~uIq?#6t*Mc`?Ww0Oa-D$WaCSqxts)7((-Z|(4Lbkli0G*0^ch)KT
zjAQ(^yvcOoleOqgRXMYdW*M`;RgY)W^Kq_C&&RnoJs;=V^n9Fa)AMnzP0z=<Ha#Eb
z+w`7-{LMrLH<<TE^WJ3Mo6Y-N^WI|K=i$w<YAxO}R$YK^+TjRiysk~}sc>J2pMUQT
z%U6w$EzQx>@Xd!dJ<=sDvFR1zt{47d6P`9bhWBlHHm;<ejq;(zS^4mObMKCpIki29
z{(PGr@xDzjbnng?@RzANo}758)_y%1^lRDmh@Y7JnU5GYWY;4+%dY3(JYAHg7pJ9$
zUC)WP?%p)|jcL-3<;&L%*!9k``K)>G&e`zi+V$4J?b`Lo|K8ZC?0V!&3%7Q?^8wGY
z>s<ugMC^JcgiDl1jeB>PpO9UT`3l+fLig@;!|znt^~#`C!>%`(Ax7=htAM^gcaeK{
zs=&z;))(!gR$R}*H&ufh=5PD%-klm^)Hv+{ld0rbA>ym{CZGzbY4Mvtoz$}VZ3XYi
zyprGUys{T=nO73G4L{B+FTtBn8kgSNcPac*SJH<!{nO?b({kpa#8FSv7%pw|v*FS<
zzahj;o8M(74as=YHa|-%ZS!++zRhpc#50CBWfJ-oS!D-dSK7HaaXaw~+5BuAX`7!7
zm)_e)oO%K_KZ{GsBDDEs;aG3Pse1S7iZYDFSs6y|-J#qfHowr`zJB2SrZNeUWdF8w
zWB(gK9$fq1AlzB@zaY-D{|$%2JN7@1M#BE*;bQyW2-Dbr{m%=Zu>X0u*#76iJ((*P
zdHC4==fPw9AK{LzPwn$#nK-b7{V(ZX+y9a<ZU5VzpwXE9FG)w+|B^6m|4YKO{VxgA
z_P-=d+y9a<ZU0NcwEZs$)Am1>OFjGFF8J~7f0qO1+y4mj?SD@PEM)(C2H+w4-!lQv
zvj6P{F3bM+Ea1}izlo2;`?n*|w!l5egD>03y*tkaPM)xA_pt2+Gwg!n7f|+>ymKJ-
z0`jb;XXDPDcf+=GVAP`I5nTHmJqPu4qu$@fVb6JrSin9!TI?GvUy6l_!_`v1I%lO^
z>g!v&v{>xxSi1DozEXd8rBqx{?OM>?U0JxGdtqB?QFq&-wrXd!w79Zp$->S>3%k3P
zsng*a_FX7kys)ykqqC!{643@inc}%fr^pmn;ag-1CYreC;Wr!K(^_>FsM{c1WITSm
zGTt?CiyTMX^YNpM_X526q;M!eOIx3d_CAzl+FvfZHl{KC5T@^iaP$2l^L{bjl0L1+
z$+t33`dib!4sOzZDc*7VPy#Q5o6j)L&f=c?tKlBRh*%mO96t8A2<PH9MK1xY;ljrH
zS)Nr!-ry+CdNy{a=;aRWC&3^2WO{T=(<@9G7y>%bhYX)gnvc6W7A$Emb+otPU#Yv)
zRW2_mE$Uj*zF<jt@q(WAo+KaF^&R5l>rr;X$FIV-%g4mM8b6<p2^T)*x68+`g<E)#
zxYyuEK7JkEd{Q`vkJGp`@7@SH<lWbs_Z#pg?=mjoUFO5(-8aEa+Be}HrwO@!Gu(WH
zcW;2(=iN5~CcIm>fNSvXTO8Uh@7`?Ez;uj@ck3sH<3htpPxD5;^){>#WIaoNeGAf>
zM}NltnsvYv_udMa;Mr!6#$DuYfBtshC*2M@+dC?qoeMg<OVtJCa`&ReOWNDJN~Oge
z3#toyx;omD?VzsjbY63<??gJK9lQ(QZaX0E-T3+KfN*IC{C3;Hd*K#-Chk4>u^qe*
zZ$2qppdG~F^67T)e$ZhZe89YK!<+4ZVWb@}A8tGNFx-syLwLuuk?Y&x<|FOkR=E9k
z@Ik<Ynd%mBjdt)6hql`eK5Ejybd0MV)K84t4(j^$d1KPN+g_=3b}j1a=vvs>-Mz3}
zUfkJUs+8M0$_p1RS+sCrImx?qef#O7Eb?)bo$&4_@a^(0ai7G`=Uu{uclqt|?q}c@
z{v__x_>p%%i#MMXF2K8SxB%~d4s^)7pEvI>;7#6T7~x&!!{yyO;AXsE!aJsoTz?sE
zKEk`7g4^faF9IgKTepB~@a|U}+Ai;Y)ue&x7#Hu>PmIgEb$$E1;r7cHdHwR&kmgDA
zc1PFZ9*85A?nT|D#f!T-7A~TQ(q1i<D~l_gJ(VPH*Y)kEpS=AIq*HkNE_}PZP24x}
z^Ld+a;cb4qynQ#^!oS3Q8$a^)ckt$u!UcFc4j16<?}83_`+Men58mW$h7sOoK3v}Z
zA>54j2YAP{k?VWm<|DlQEx3K&{yt#B+jR@L25<k!q3!bak4+kwj&bpJ{lvJuUDvnI
z8<XbUw(_Ema&=+bl7&k;msA$Cb+%QObd?t_t}HJ1^enC{Nb+u7-+ubYyFW$Q3Ge<4
z-!AVG_jCMw-X&akm)|b${t9m4PvU-wA9?rJc=Ji&0=yfC3-Io5K!?10pLzclZ}Kj~
z2=6i<F7MtCH{<<3ykpwP_3z>4BfR?yxP9LJ9bm${bqlx#@BYD|?egwklLn?^T)bO9
zF)r`c_3iV9+b>`5^~--mnkUWM<+gHnM|*qq|FQQS@R1x<`mNdQUE8v~HpUpUtc|hP
zNjWUWmR4a`wpNlAc5M@e(M*qaywZ$38f`FOL^7~slam1xjx#xDj+~F2b2{KS;8?=}
zcX06kzN&iN)zv*3N$bVj|3~XL>aKdPUcGwt>eZ{z)lHLajcu*@$@ca(zoB`uCDYoN
z_1p4}zg!dB<)6C!U*J=8`}cUZb(^q1;OFW#<3+dmZ0q*_AT0Vz*ni_k-To8qykf8f
z-44<v==PsMhr0d0=KdGlsoP8=y3KOfx?Q(T=j-7f&_=0K2=fx%{v*=4y8TzgiEh^v
z@FKds3V8`_Tenvm9>~YCbh|b)wr<zNc6H;Jb+^4EJK5QiYi`H?e7?QYZ)wW3HBV+6
zGA-Hm=8nmzU9O4k@<-iW3)zY8uEVpfyM(RB&(&SVi|+E-*4>Q=i+(CRribos!kt$P
zmY};qx&+-l5p<}#Cz<=nxKnqTMs%0uuyyxTgqiOtxCgXR>eCSBCAzx-VbL#{ud7F#
z=x$8`FQU7fE!wv3o^E&`AIs9++RWIxTNB&W4cjii#<9!y0MEy)+nu=#U5@6~Y*V(g
zrLCzm)12#Q&NsK_nzEDmrjDp?*Ti=Dr*7X9e2Q+Lg=bs03A-15u5L44beqq%Zl8m&
z=r3XS#*eyvAKZDxU<tY%q)X84Eucf)zOT7&#htp%G@{!qhppT9LzwxVhkHO9r9K~F
zUZUG)Bkbz-xrh_pt|{O}bo>4mZCkf5Fg%ctW$AWpW^CQAiS6pfvFmPotKZb#-k!yX
zuNg}rt?i8+ow?S@)_hZ2OMcRsi^kN(;@B>K)ZJ~6o#^gGc(!$yu#53?b(is?yL`5F
z_cDY<KMA`OKk9A+?!02K1l<kNCFpJ==umf?%)J?R>MqlW?y?-V?zSP!d|MfhpW+Fn
zZpSk((cMcBc6GM}ae?mE67V9r+hNhRb+^;-Kt7hIyEU1K=x!}+S2t|CoVp-7zx)93
ze9XF??eIGqS{qs#{PxDiOlLFvjJEdXriRIeY`(R<!LiFVv0eVD+YbbvqT5&C+172s
zuEfvPZN`gk^V!zz9SDp564s3$b-M?5UNKmLZU^ZSbh{UHsM~$!-j6$Vn`uP1Sq@vb
z2M}hyyKoO^qtsU+%u95;3t?BccOp)7yQY8_(e0}(+O}>F8Xm~UvUIyPGq!Hm#CCP#
zn02?Qy`!zOr7_#l*xc0ElIh51TQdz=zoj$N*4WwLJM$Pdv0eVCyF-wj=<YC{ZQUho
z1V2}I885oaXIpp25ElI;Y!pB0?l|teVz30=4bmm(?gZ#iclVh4Ufij>Oe4C>a@e|i
zJ;KcQI@|-=DD{I7<|Vp&4Z^POUW+)<-I@YkM0X!-(YAH>A%+L?u`J!K&5W(PHL+dY
zxOwH@1G&o%7O3*h?n>xy311s`_W~{Zd>?G3N#<<Xl&XFag!@oZ^=asav@<^2?JR?^
zv?anGh9BG6B<{T8u=rU)S>UoQ<!~oH_YDWMoV}>r&$~2OeBW@GF1~MgAM)nD;ez2I
znooS+a7Zh@Z`g*p`-Z1YJ~Oz}?h#k)UWsv73#SYu|5?N(?HdmBi0>OFOs9*V6-1c2
z67~&;uyEfGdEvg{YB1ItVXEGpy5hd!5Ekwm{;B!Sw|$;r(pf=1=(??BMMrccZWK&z
zJ1e5ETD96A=;bN<aw+T2&EZ{;I&TW$YWsu}Va`6`8<Nsn`-B}Dk$u7rEZ8T!pFA#M
zpRkiYvQOB71^a}Z_}D&S2OjJbcH)D5!i=}}1gm|*l!+A=*(V&u*ZYK{aeAL{F+yW$
z`-G!(^giKeoZcrKjnn&tqj7qla5PTu6OP8|eZtW=y-zqAr}qg{F17Xv-v}IcpKuv*
z?ml70x%-6Y5SO%1xPthkeZupIueMM40ASVj2_FP3zE5~1-R<9`;j1&{4}oWQUod?a
zehcI<U~(m&SMh(x%F&s-@;sN{WqTZd6W`@&EB77m;!WvQ`kIyJvX~#aqD|S!9IoJn
zwi>?V!_gMRm*lhUOFj}|@fQhu1b*}-Z^oTh92S2E?NPv`PqKhJ@##wjv>gA0KGxD;
zabGe_7xyI}hrH=aKHl&U%_r_lhP2|oqz!X@$tRk8o`gGnN#cqx`DDgfz9eB!!7s^|
z4D*Qll3}{|J7|QdE5VlxVR2uw8jSTun5uWDuINjKu+W$Mi}5Afu@<`6J7|vvUDs;e
z)$gDsx1nRm#quj31O9El^05e4^D7f!j$e68QhLj;bZA8UN(UDBl}{j#OYke5^bx<(
zfdzi06Cd*{9eChZI`M&D$#~0$RDLC8V#P)L$|%0}E2DARuRIc=u{6IjN=N&Z(Kzi_
zM&q<!8I99^Wi(FvmC-ouS4QKsUm1<lekJ8n%ddPYa9qFgX^3<EO2)Z<<<k+D<X1ie
z@kxH=GZA0Sue=qoYJTOj0E_#TEANDt<6W*i7i9#LkNIry@A{bZap+?{2Qayo=wq&&
zrN3dptN5FLw?59Ow+1KiFJLy=zS3#FRyODFOHa*b$~ixm<|}2F7m5|N96xd8dC3@E
zySlo(qnf6dx<S3Kr0Lc{6OM%@=k=ZkouQ9#D&Cc2-^=%E-i`OW<UKL^PQ-ZuejDLc
zz0l~G;Byc6McBh2?;*JOFLv;`FE$5!*<<M9-{#<NMEE7Zmwj6<{>vQva}a(5@Grw%
zd_SB2+Z}wa5v;$!^JJaNrT<EUe-`Ak2C|p}?k(qf-rFFfZ=Q$uBCL1e`2DpKej86%
z<GtER_ZE}x{@~3`$MYfIW754QNVh?~`x1N$#G=W1tAiZHhgQ!Ep>Ny<SPy>WL+Gh>
z2`kMIpONMU{SIVISJgX^bCq17l&<(Qv!!yTd^kNhpU?Yc9>AegSiRk7UW2QF3KiD#
z$ZtaVG~adgd=_8zEqJ!qN#2UE`1-_qGkzQgybX6=_F66F8OKd|?=ZNhdis6Dw<Am)
ze<$uSe4M`}wBxX-|4KhJ;0fvEjI9rQt4`(l=I;XirHMs-i_UvD@MW!s>oI)4@jZyU
zd5J{$9^=i*E|?cq&Dsy;f_0qPO3qX7I&uuM-b))_ZB^ZS6`u$EY_C7vi}xt`{v-8a
zy?1`<eSpceX{n{5p<Wu#N+0?muM<($`>Kr6(|&QPvQP1@<5FIFCUdATGd~lB%|iYt
zm)1t$zo%{usCcVBVDXG{YTKw(SbP23x5vEyyKF)Uet0nlvwkcezT9%f_U)nXdA+=C
zoGH!~Sg~k#Y;hA-xa-QsE3dSYblo-6GLgb8dtRs7=)b$WFFkba_4Z57y6(_dvRPW!
zKk5!^2c`0|MUN@9zhT|6Px&C)9QzTwf8=+y`2Obo;04hJ1@CdLU*mlk_&h&v7PY+<
zzqOus^wTSEzjv|!8WG+x4%&}LTV9dN8!6OXIGdN)o>`YGY|sCw%S<jaTk*@Nqpr9G
z?COfO?&Yh)vTQTk_s5;~O+R+A_WeoVi~q#6UH#o;+aK0`E$8Yw93NHA;-t;^4Zh!f
z3*HNt_rOnO?|?HrKMVR_TDiTr%liB3C-ki(3y$xPhrRf_{ANR<-C&)r&~B_m;EA&r
z|ESaXN?L4CZ=wlWw*C0Lu^(8QIF;)mmtnjdp4(98eGzbm)$j#lDG76o<yqm6W85rZ
z+fG~oKjX0pcH(QG`=gcHiMzNjs;*fp&**sBjOBMK=$EP%@Ob+htm75hjg^ajnbu?F
z8U3S<xt>Qq<ePyVN!5P{&-Pr=w-Kh#(Et+>%)!BSd<XHoWUg`qK81Yqmo|s^-uhME
z_o}3)E#f6}O&)BG%r!A>8*Eu8ejBm&`9p)tHCV>Wyw;BqFKe*#Ce2R}XMbOVymL+?
zq!-RNDIW~B&o1xJkUpurKQ}xGzodB@cn-&3Deo6n+MD5@J&N;=kk#ilv!vkF*y%4~
zQYI;nUzt1v?`z<V^jS9A=l=wpJbwaro9ClezQKGa@b5JA>^hP&-0eF0U6u4wN5ZR3
zTjU|IPob=zcFHR-JDrsA7{;Y{nNLz>J$WVckC!o7fs>hBs%1}iEW;Z)hH>diWS!VU
zB$s-{yG{R21`NriI-Ye&`|>B)1I{~r>+i<LOP0g`FOx{gr8~af9qab*!?#N={Xgm!
z%Mx56)XOSeUCXe?Y{P#sZTLWyHAuC#T`5;ehqiCeniY^Vt#KxcS+ew8X}+BGmHE^!
zv|o8%RjjUXI7@n1ep2VFVs_~w?Vr(a<Foi}DLmW$%PNHFE2xDE;^DUu?}V+!ofpf)
z^hXx>tjD@*5ssz78s<7HO*i~A`iJ7Pao%e~V!D)ff=PE4)-ySlUV||CS#RzeaTh+w
zJM%t~Y4B70qIAM<3<h6J_~Lpg>7Qiio{W2}9P6V#D&-}9E`4L>c`AM}Ki9w%KM@*Q
zX7tbFdDVH?;G!<VD6?wxC2vi?&igIo$xG4XoC4?wOxA5r#djL(VQFRorh28hqK0t?
z&y?K+{Hj`IbdPJk^}uu2a8E(p&9xGnv*k|%u6#>H&Y|6mIDE5(-xKl9!1H{OA-z6)
z4}|A32YfV(OvTsh$Y&z1?CX!P=xBY$t&$hkfk~HZ#p^MdiuF@`4N|46yC>4Qdy3d5
zPxjhUX8|TxxTbpi+N9kMIRDEr0PD=#kn+yP-JbhlJojtdhOrCrxSqs0;&TwsFku{%
zjGm#}#TQ_2>^6O0;88EAGr>L!;BQ4duOyf|-mufT<BhX0zkM&xaf7CeuaaoWc;lvH
zvV&%pp|&ZsRu`hS@B)-u_Ga)|Y~eOM+j6@IVbz`>BjR0%A8p~qxbvb7V!Uk&FGV<(
z2Db1rD-FN-W7|T`?KLK*OL<Kuo!G)l5T-3`F!yHMg%7cXt%wWwMd^fJ@)d!hzJxEa
zg>8mzJMOV^MC=&OWnkX0>BOUMG0*Mzxwh~|15@&g(9pJ!<KTE+b>0I(ix**(SvC5S
zx2BJFk1@TZ<NRtM3zS!E;Tgsjk~h~Dwjkf?<}A=Z*v*vJ0bJJ}b|P*Odl(R)y?X#~
zU3+*r;=~?afoIzuUWu@454#YTWDhAbSiHa<J|4E;wujwF=h{QIP1?g9fXTIVdl(c=
zZ)L11M0@2gY@1>eWv-jHjde$x*o(Vu6B(am6Z;X*_V6vo2JS+<=xMNT4EivDcwR{`
z*9O|@TpKtA`?s%(4YbpV4U~NZ8O)(o+h?~Gumb1Zu)l3M;8X9<`-MrDw9oECfZb`*
zT@$3!K3yZ`v6}FU($ugU5WnBR+;ne4{M(&$l=DXrr){ZuUI^RrNf&tD$@noZp~p05
zAx_e$XQYw3=Q^m&<*9xRXJS7HWnenCRogy41o2XD_I&6=O_`Zy)=BfQDrqt%4R!8A
z&>dNWVVLuaVOW1_VF><~@VNzGp55((2JyA|(P8qyH6NSreN}iU1U%?G&P6)*`79%C
zemIYr^7cEpoR_SIJ7aJ~R`wjA$ciw&`<yg4%QA7EQ)G}tM|c-r!#T*1*Cd$mMmhc2
zX|wZH<aEF(kNw`Y_#dSASBKtVi=Himn;d%fyEj6QGN6np1N!Kqube9{qmBq~Q1Fy@
zvx2X$*K7H8-T~-}$jtVmY}qrd4HJEobhdtr-zMWP`g_FlV1GzMUEuR^rd;HWIOLr^
zViGRnc@bCiopB7ynxv$4d3EbP^ata0Z^NYSllVzNX2OrGkqSRj5A+X2KDLc@<!aZp
z*n5#3`w7z64cU=~x*(@pE!h#rmYs_$vP<H{l}*@B#ARc{Y}vT^iENJ3eo%f1#%v%p
zi{yIzmpIoO*>tt&6mK=M$9cLwo~<=UVo&PCb{(1d{v{LWs`5R;#C;&FyA{s)EjCXd
zXZ9a;H(!~(>-T%S2=?KG1=<enkI|3goDTh$`=Mst{h%)aK5ePku6p1f!@8Ssw5v2p
z^)V->35#o9C5gSOd*#HBS6i078gccuM-q#+=H-)ER(n2%b+?s^`yX}b_Ego>VOe!a
z-|^*6`{sCSvG)B6;2%SKzRPTSl@*+o&_7;{dAa>6I_Bh3$=YjzRS1_sY@@IYEjWhu
zyb@U_w&dhe|6g~ql1p_w>yqvH)uufkzjgGu7RtKm70apJmG=h6tGzD2=d9jhmrrXM
zZT9%BqyM9BgSGFwsczYZ|Jk(R<MducLM79bC%4|J8-f3?o9C(pJDwK$&ZEcay@-F*
zDc`2Lo9dKp_I0Ms9=~@K5~_I7v2ImiNOzssTbnN=R~c0QU3I-x3mEKTi;L_o88;oj
zcNF3bOJyzBI{$y-UfpeV%r^Z-)23xFJ9e%hHhhOsuiLHi-V8j>d2!uN){Yof>tmQ>
z=lZJ9;Ch<9_NUj-R(WqXG(bK=V~Z13%LRs}J<rBG80K1<%>&n(B+PkxuCImbNb$LO
z8zyt}q{}rXmrl5T6sKdugpRBm*lRajW8%d;M1HdVA@Y;3tnElyMOFgeLPBQkhx9~N
z0+%^S3ClZb5*FD>Sk*7+as7q#bbZ%(KfpdFDT}?9LOfo?m9-S|N?m#}VD{SR7Z4U2
z!TLAr)zC<Uu?}!0!Q6HFCt@DwN%$r0RkHJwb$ar6yTjwxEgpllcJTNOhesR6^4dJw
zFqg+Vtf{BC)()Do{wQU$)7d=!lf&cpEFSH0ec$2nfyn0yCoh)y4u{^4EP6H%KX&LH
z0Ih=w^j`1K`>91Q*js?|{>-6g!(18KFjs~@1P?!Q_z)S|>1-Lk$>H%=7LUPR2JrZ6
zhesRc@@T_c9-FaN+rs@33H5BJ6CQ<syFT5uP8%j`$ZU6PXSSVcK+wi@*D1qx61QPC
z%(Y>*ZU}G8pKZv^-^O+G58FUIe;X$GGY_@_I}h6QP`~4JY?w`ly6@5n^*T<+h6x?1
zD_hq@9!W5%D}mW{BW*&~tX~iQi1%UWH|eVjI<)>`{YY65hh?D6PQqn8FUim5)2)lJ
zEyc@j!|bxVyvdri<Y()*D;HZYq^(KW*+xm@o@h6up)Qp3RIBX7vCHn_x@EU{amyaI
z(RkTym|b=^KPfxwMfQX|2c0zSEY}ot|Cg%g*;YpuLZ9efDAU>a$-9{BXYYePR$X|X
z^WLV+q{BUwq$B>+eVnxP87{TbZZT=4K5RX*eGkzi+BLzo<!<-wB6s3$GiP3@y~<v?
z-%n>N)7aC^bFdhPeTazT?rrbrHk>1vLYH^G;fdv2@8$jCfpkTk1f?Ilc(&RQ=%zrU
z&g&mcj}7b`>g)9wPBA>xx3hbEU{4?L7`K{n!+ZKh`v-^jnz;3h8|~}vP4^D$92oZ|
zy>+K!+f#}@&;`g}&Lhz~zb~IJ7Be$`?h?N^KXXZtquP7Cx1}01I8nfCZ4{n8Z)~tP
zJ$yCyr|U8>JT$C08S_+JO5scl^%|~;w@Rmzf*ifn@JxN!2A)Y}Y`lAXVvN$-+Y*K$
zGURouD>EYtB{Rx!Y(&XW$!oB$f83VUAY^rY-{`Q3t9RtSh2ieO@xIZa?(sfdhAzfA
zb+N#>{^8M{zTuwn?m@2~Wms?Iez7I@aJgpt_Wr@{ow`JP3ZxpMpm@~D$H1X2pzZwf
zJocsb`x<(G@uL7|+an(B!ez+sp++XCalU@zA1YMR`T6PTbavX$6zA2RSzSjV{Kol0
zc7K4N>kwzR1?h{W0C<$;L;sUv9W}Ci0hY-iJyXj0x^&4fU3aj1^-W06J?d8_@QfFP
zW(q~T8j+S0lSQ{es%5`2UoNIAU=Js8`s)0<9pEoz_-l#qXRwplvq0ePD0yo&youf6
z7_J#{ZTL~<?1TC4c{{>S)BFBa6r=T(EzQi7imC?WBslr_Q=8v1+0dD7>1b$bnrv!r
zZD{RiY-nlBwdULKDY=%ceg|O5*!bR3u6;6}YiP}RY!~Fe)9_Clx*gB5pPft+_5l1g
z;&~0q#fx~1m;I}Jrp=cA=?a9Ylal^{OppElSK`hq216y-v?)934=6+1rtd(w2fwdu
zO`@~P>jg~bq0fQrLYRDXn|mMb!oTFfGV5pER(2sw9(Ur-vMK(deFJ#r^$zGD_pM)!
zu<U!6@7(qyZpoDaedaqlEE9Iy>qe*Bgo<Z5S7TSZ(p;sB8lPof@3Aq>7YoHgrI48}
z+?1&lph0CH4Ycg@{ODEQRTh6dYm&N$^Bz}St@2}@p0~-n`*bgC8~Pmj{zcBx-G}ne
zPy6XgIa8?2sUA^xQ&9k#<ef)ZcMT}pkdzblZqq$faaFxOd9w`*b?*w)E8h(xT)h^C
z_HoMT8@*xB$xfH%_?{TUBM9T&gmj^(-dafG|2$#jf0b9Cx<>LvmU3=yl+DHYU+f)8
z)cB3_etIAFDp4AjCka7b3(_zrMb|`961>mZrP{?9c-QT^uAa~GUeE-d?KZLpVQI(2
z8^@1rd@t_2*v1%tWP#7RU0sK8Qkv_7G#c+Skbe^1gAJa%2XrmMY}*eq_lMvfOBd-2
zHBT%D@g4^JfOqJK@SX${9_1aOjLCB{G0(WZh53Z~Mj27AVsEK;#LMGn_u=G+`kVwK
z4W>K6l&OHUNqNQO0(xR|6$}nwm@a%r=(*+{A+{ym_VgQ*(oRGX`4%PLp?oOt67{Z%
zrqWKOkp}1A8iTe3^+vnodq-KM6Z<P?>E;lZsZ=uAefm8~AK{!IhNlpg_llTr*sfQ3
z`w%Y7u{jrV>>J4&<0OwQlcf^<cgEkK>EH;h99}z`OPBIGKgO4RnDRM4jW(L5ov?9e
z?^$1vk`|q&SGOPO(&=1&x`IJMsSGEoG&f)NX~*lP6)bvoFKxtW-htE%U~*wRu?!*V
z*OL-cEMg<XX0L-~;Cp1$zY=($4vYVT?#bhOSJXw~R}fx@mU^QJ--BZ?(=O?MFiblm
z?-NvjM;}7+@^I$PJi^aS^qtHh#M34CrIa}RJJ*SV>y*p4w>GwSv@~T~CY$}%=JuxM
zOujXfX>OYA^rKExP3(vhrG2P_;7@GjAv{Z)rhOvpFn+EN#dvLNQ}ukdZRH~nmNrY+
z!||hieI)L@Vz5-$o>?c9A?=*l-UWo?Y3jU32lTYRbTh)_`BCQn7~DyZJZO5UdX~?o
z{dj~)`*FAjyh0kcAk0g?b9xiP(w4+udMx6^U#cm0=m^^n%jS8i!qHH5dwhaLo3?<u
zvKGG16BRD;)p$Ft&N{yvb!Fu`+|WGPnCooK`1y|Z&bH2mrjBfWGSl9g&1NQ>T3TD9
zI$RSwL5Gh(R-(gC#<Q)%ggpg6SBDudI?QKVho6qH=p12B!;d=r4BUCeV3rQYVR2o3
zCg@OCZ#DO4;Z9v;UZSfkhpns6MVPdogL}XeO8q>9d5Nw*6=7FbpN%-t)td5ML|310
z(YAH<1%?OmL0ev1S8H=YE5Br(V>)4M`vPsTejks%8PBbtZGI8?g>8N@?#ucP#(`2H
zr_{CjhcK>%Kf0{%U@Va)_2V}1OP!Veih9bio^5l9^D_MS9gLUb&P)0-&Yzr*al#&q
z7dSr>e5r}YETm^k(}nC|d`ZEblrZyMW{$$fRWmQ)+{G2vyu>S!cRYojGl|DTXz*Kh
zfUoeZ{Xu=yKH?=V<?Yr-?Hdr|`QGDdZ-@Hm18HnmV;L{?YEyQWAMZd<3=Q-Q_x53`
zZFFErO-xNVabV#ufm}xB_Gb3`qwt1G#fdr0x)>SQ@qLH<>^ujrqcV1-OjDkXbG2VC
z`qSh~&js4Bfg<*$%+L5m%%g$|+8uFLN79eLNAt@E{1Nk|R*kbJg43O?6b=+Bhev&U
z_rfn`eKjArHiEOaRNg;a+~M!bOvB$}KI;I7G{a)fc}LsKydM3Y*Fb*hk+JmN?yLJa
z=Q=h#WG1|#kr3O_p9XRp>r3w)OLvcqT&w1HF|9e;mmVI)Z0!){O2^ZCx(5e(G1sW)
zee1l%@F#|@9va>|WaNUm)kSC{$FcF@Q8R~$IoCyS_YMs84(}Zc<h>Yf-w-B8M@9$6
z`dEiUkk1-3?{){|vq(xUt3?nfx37hAJ3NOknDqM@OquvSrDDD?HD6Y0G3KLsOT}@F
zQ+AX}6;-#8+fwjH=ZlrX49;EAdby-D6LXm<f4p3nn)1tYq24YjZBGdqGEEV3LbFu!
zr>~<Pja@f3-nTp5-=`I#XLzW8VCTdr=KF_-(qnx+>OOwmNS{%$CF5(mA#>!OcQr_l
z4-8H8p>eaGrQL?{qkUr&yN#ZtEd0UYp`BMv>>dfr9HtrT8#i<8VccN%*tp=Xw&)BD
zDINFNmev{>yn!+ZlUfChMp7sEy%E+IwCnKP$n<W1W&|~o3+r9Q4V8*II;>k2Pc=cS
zhHg_=K}FTUo2)t*86F-?4-V`e7*Fp;l~}wOp(h}auTKYjfu&wQSIA=CI@evnCqE|V
zD>Rk49T>#~-^gPb>b$DBgGgP>9v0n9#M@ggRQ!;r*wE^@LX>&0PR^Uc!FQ^{cKjB~
zhLY&*>mBH!X-apGqm$S%G2UlOXE7AY=cJU>+aLyX*UbC#{zP$p&d-hEOM`xcslOyx
zqk^TpBv_MztxAM7E7<A~wkMOFBoP(ACXC;mfpIA-h?e2n5GIN=f*FD!?Ya;?Q0mE`
zO9^4?Lzq>*4wdJI5H?WSGpm^~ecuT-tT$81Ok$?N;%TD|?<vj9PW!Zb0Z*Gk_)sN3
zH-@e=Td~rg7{a^rIrev|4ubS2h439lOsegi9L8JaX>66YU7rkZ6Zk11T$~eD0oHrg
zosRWl)&Ab5+W*)HI>Eu=o~zT>O!UD*4NdIc(Kl)=-qp!aZQpLU+g_=Bc&JoCA5lRc
zQJSAK{g`TNfOSt7riy5o#his=>Hz+eKcmx+`g4UGTo0pPL3|&Q7bd6u@zQQMKo*Ih
zO(DIBhR-p^gS}Ln%3E#f9i~kUk6xD^*>&9*+SOoMS>~M+1LN1x@fuf)o?`FOxN75S
zS+rqZPus_&-g2Z|D8XtR9+-jA?Dg}R`Dv_CYu*>bAA^%sfaj#!2iBPrdSam+`hzFb
z#2ZmQwdl&GMe)aRDw^i?<VEpR*@h4J<uYne)!*Xyx<7a*>SvwN$9J)QM#r(Ho7f@4
z-+{|Eew|Ux+K9A&Hw5*vXS6>J1KPc_Pt|$fwc~L8hGbp8&P#yz_Vss93<mva6`VbN
zgTo`c;gX3wQ%SUX`bNhG`f1AHTxfZ&s)?t@1wFEMzB&oNe{f*uuJQDE_vp?(I<Tfq
ztyu)O7eW{s9vdI%8B_JNb`jj&!)O!`I|e68U)OoC59zq9=(lp5wZYWodsvroG*fqR
z0PE_GbEOSwzivlnu8<ul>X-XC6ftEJKhumpO63F`_~ptM9r4R5Jvs{;OO*xwxWXBS
zH#(f}%^bEdOkS&nPNuTY2D9z15ttqY*<eL~t%3Jo230wsHin_U&fxU=Z0I(Ew0Tnw
zokyu$r9k9ogQ3+wotc`mNtwJ(u=rt_Z4{>8XyCim(x461ylgUXc3w&JPc(2?-|YTz
zoHQEALDM+N;3zkdy}O-_;qzpJV><yh8hNcZIJ@B7O(*1Yih&PL-hh#com%s8s>Mft
zAxeStPc!g6xfu?K{h9d)r>cH8hd4V*v++DmH*nJL!3s)*O;gr0gb#>fJTqkzQF+|M
zzz2%(mCEz8k)jwHXBwQ|*(`_B2hi8V=-g9y!G09otJ)}9CTAI(!BQr-Ggs&>7huh8
zG?U-G4BkX>x*De9{cM9rUF*)>Fh5t}tb$EY=X-C1H#R>rgHL6~*)#c`WAJtt%H>iy
zj>dYskHN8;NlX)ox5eNMPtKL#(!mqfyxiBs_Z`amv-I?Ab`2j}4NgxvGq<mIer8s=
z8#bb*b*{nFvn{>;<UEJ3alG?{9-JrtP-X03p^}Xl8<X$-4Bn_eRlpq0;cMngm5fc!
z;GJ*q`VL_*lQTZVcn0p1jjVaRzrhtRV$8><%JsyLs>2Hmd=I`|nlJd}?p&^_UR>zl
zj>4-u;K$J^|7}6OrL6j1-+<GMO<687c!T~_CVM!U*2M;=XTFSyrV7>V`cg4cSXGuw
zgjT7vA6-i>f?@Kz)ZmcF*mPkQJ}t_PL8aCITxM{_z&N6Na5M^zk=62Sh{AgHQmKYD
zMqzekDE^uZd^Cf@YN1o*gtpRbaHKwLB9v>310UZvU)--1LG|^mQ65YeYE#j?wi!If
z7U<3hV@EipisyENH#9$!3HsyRnP9J5hk;|pFz-XHlk~sS;Al4eTmn-nuk8kJ)aM=>
zs5VBic$wDEaonZ`7_={%uLl@h4B1Ae=jTSyBf<67u*(gMJa-?+6sFlUv^h~SdZ2*^
z<ryg*Oyc_rgV%@7K`BVgVbQX@(!~o1$K~E7xT@{?xoZ7ex4|1M%~kLT+RR};r{*PW
ziqwZ425(1U%I$5HOnVI6=rVDfZb+A*H;RWEp7nEk3jRSmL(_)(4DPN{Wj5oOGV;`K
z;JR<dOyWGpM({dJ{p>XGy-b`dO|dPOwII|!L(<rlgp<I_fWaFqO`#P}CrY05t`d5s
zgKaHZt1N2LOKAPM+TdzC?3eos<(Y%fL)XL#%cMVO(p1A0-*&gbi}_%Ehm>v(8Mw56
z%!xv;Emn;k8a8-i^RVZt<;8JEBri4k9z>rK$GOJfB>6C4N$Jq2!5QBNONiF1$GSb!
z1@`v2IL$GGA65ozf6rlT*ket{@y89mlvz*x=q6`lQ_d4EZMW?jIqordSe;1p5B3`P
z*sPz$e!#@Gb8R%QXi-gDxX$48(PbGaMNPWFx!&M#BE7G8pinLqT}MgD`9TJ67iLp2
zFMyBS+NIa+^uY#4WMyHX<QnH81}CYbqzoTw;A%wAiVv2QhLuZ{<ol;hnjZA{Wk(}P
z^I--q{lJK87>q1322c3!=Tu1~LtTbRgJ(uZ=qs^rGwQ7=nPnq*y@k2`mPCv^ash9~
z7qOg2q|j5zR{!rCeADOQE88$%Loi=9X;YrO!R<YaP5*^#lE@XGQwFa`k*WAoYPu*s
z_TA_5y1S6Y&=9F6W^-^uY!)c@f{VYSj1d#2DfvZg!{ZGGXHTJAna@na#p4z%o069K
zeuL-QQcUXYESKgZBOvBI?dH8m8=o<_W7w<}DTLv%XyD@ecBB7s%TY2o-G$0n1~auN
z;vTh?)X<nU@ICu-Y-)A^RUO=D;61bRG1r>qDI53@I{O1y0dQs~6pcB96SQ~MINtD=
z`Ou1i50(y!p&TgLoETo`4W70Mm2zn|GCQI2I$&_5t*AK$tdH5`$oD~mmo(-U8-B>(
znD$ihZ7RlQ9yT~sb+!x6z`J?fWN^B(vxV;YTp=Q5Q?`d293?@kt+})wVel|xUOsH$
znR43bN*<3i_{Nt>aCx*I-z@n<33iq<v-=8JyR@pGeU#A3mggr&_8mrDXA%a^D&Ga6
zhtAJ2eG2|)0}uK;Jmfhifbm|rG~JC}Q|0*>g9o2=vQYG^=W68mScBh3GSm+<MF5q9
z>f7Sc<$hd1zsNzajiC5^yzq&xm6K*W@DfNlqIR0jErO?Jk!>;>{saRL`>CMhv1u^s
z=MxRSo&%#ZAE)`G7)~EvpE5&L8{Np}h{4xx{dftxNJ>))WqEQ0uV-JTh>Z~m^qyky
z*dAg3B2AWMc&dR1CAIX`A{X?*Pc!&Eu=AE<s>}xHTS>H!^>l-;yk)iIuIKP=MDp<r
z;RA}uuG@kKc|S8o%fd2!;;jZJS+_<rNq+ycByYGm98z($YmP(3zI<UYGhcK^f8_Vs
zCQU!)rHt%sW|Uq&$KX_*M=|#4xdxAQv>O9&^oJ2mVt&svIAf)JWz?T^x&f`f&o?-I
z)0vqbAD)Gp0I)@=>*NInZ#bVvU*mHo2u&J$B<vCxeSD$84fMk-<wOjR!F`dzmA;PS
z-D0*dT~LEeo4Drp#lml{5b?HI-j^8IZoGh&$G4v_)QXx0ljm(hqv)5X4)@Jf3NtFV
zc!6}DFE#jK8|PF<A<}f1|H}+sP;TV|aKbE7a#hbSH@JIdcKTq$<d4l8c99Lgw;SB?
zGNu(VWnfHJY}h0|&MORlREN||xw5^lH1LT36>nmS&sQ1T0a#JETsf}1arA1l$+ExN
z;O)wka~vPaNS7;W%2=a9utQ<a^>CT?pG?{@R2L>EVl(o@d5yv8o}R`8MGkJum>(6Z
zuB(4Gczfn%Pz@EmbH`@Z$n*|_7jz^E6q)a9g*T4eEnCDkY?CGK>kMv!TwQb}+t(ZX
z?tEUoigl9@l{WoaphI>hhW9s^bfaj|V}<FMeSV|xp@d`;&@y^c1nx|Mm^|KWaP}68
z%}sm#vYMjf;tu>f(X+Q09Brqywt;VU_jabLtZ$V(ZJ$5T<V>-USBer_|9YEA7YJso
z;$wO?v0cAi_?e%bg;@?J*GlE?a&{j!vd|>>bE*xz!{F*ZQ*F75@%+vto~sy1*8jT<
zesyO?%m3X0UF8$?L!&V+FV3k^o#~U_V{q&?j8Yr**EadR21j-uvR!IRf<Y|Jj+tY6
zUsXJ|X0)RUC}Zy-%kchyH@0yzHdD5t;Lo{QY;@%VNolxXl8p>N75#rPxB>0h=tIls
zg9fi36Piiu10OQ*u$^FDWp^ez<Td<#*x+hCW!KeL%$5(wmONPgj~HAv!H5n4BjQXU
zYL!(vK5FoE{p`tL8ZB3fI10KPA2WDi-=QbmT<4j2f85~8yczrUWY<d9)h7&o#NOxu
zlAgr3HQLDHlTIEZNwWzC_frO!^Fn6U7ZRZxZxhz#{ItRCoyqK+M;{RHPBh+U3?6D=
z8lR=pu2KS3%Hy*Jm%bHO-)h<Ze>M0Kd1yU!yDU|QpELM_er6WBQ7T3}3eE554UXzP
zo8smEf`Lna$BZK4F|zz(5^rONi<N!YW0j4qm@59hBzY(7gt0lHtiHSmE_h3vFZxO}
zjWU8`^OJMgav`y8eAVFVcC@%wkf*N+KK<f3YO~F?mhabvhl8V;nVd6aWn}jagR^&^
zpBb2)DTt3@Q)7PLG<dy*JdD~XUis~r&O|47lw7|R;`QKdyK*9?$@|+OE~a6o4`YF4
zs!+5W*>F*>)af?)oe*Cy2`-X=Jb%~VYx@DConSM+XK;4R7p8N_nhSAm*}rdaIC(qB
zNje+Bl;sBoC(=H+$f@V+)O3{e?LSPyRnoGtbzk};gA2K<H5KfJ*zfevO71_lc)Z>(
zmy&RPBD7|+vLs@cMA7-TMRD|g&7T?^?NbK5#3+`J*cRsY6(Uo3itf+&ZiAi_VxCHQ
zC=c!<{JGid^FHqNG23(phHxOqZoPxL2b+=2@gY^g-1l?pM!oN+&bz8KsTYNIaB{6X
zo8{JRM<lw9q#WF8^^29A2u)M!fgG1Rj9;<Z!I>C<Q;r!@Wg(0YuqMP2vlh#ey1O>S
z>nrAl^T?eufU){o7vgo#&6TjmP{DkVY%g^e3Ury*hiSBYV4O?ILQ-|NA;g!Z)kL08
z2=Tx!%!JLYX(t;)oW!}_O(EP~GEdC!#1L1(_Y^peavHG7_oNWl%{Q3OI61_@h-Fks
zGS(#<di54=AZ|>QV2Gi7;8T*|X2MbIz^Nflf7$nMiqx*j=d=(<WS?A927hyi&v#$!
z8c=n4dI;YEQ!<75_Gs5^=$sMajbXk8XFQ<!U_-(F9feF}#BK2J5#m!%%VrJ0oPS}n
zp>^=g5I>mBw<}y^bWaP9{Yl>eF3oEiXN52|gfZ_2*_o*_-z&sZR(8bC?1zHN@C0uk
zXnJRdcmi{#VKv^pLp<$pqQRk8Q1yOJ2&3l({}wC$_{J~W^nF6uK&gs)5$}E>9*3YD
ziuU605WatYSmbiPg~K<f%EVNy*)G23_x?$^YIqXtdQiMykc2lN2bt)-xEChj;7uGH
zcrvAjMLN%IAs%dtd5ywa`?@HEYgs2c%bM23A#NbkalFev<74v@giD!S65>!2x~HM!
zOx<1@!u!<J6jy86lUifB%R(Hz1U)b_3y+|LBa9rQqWQAgFAP0vA=hY2pL|*ES8yVp
zE^(|jD>%(A9jo06PK%3UwOPSwb#bhADmZN}j@32=r`^S|+NI!hxHwk(6r4^M$7-8`
z)7W4m8T(?j%>XYVY=dXD%>XYVaD!*H(*Q3bbc1KL*#Ivhc!Rek)SV&t$BXtI_qA}X
zZDDR7*CcIyYlvU9pKCIDer|}X_mi<T7}$9sEYVsxwkIfWM2Sp!E&CJTMHI>4S+*y@
zizt)9vusa*7f~pKXW5?sFQQZi&$2&)*Oa7JmK_T4lJv^5K>=QpURic1z)R9A%N_-I
zNqS}3qyR6eJ{ss>2QDfbkan@Tmwv$b*B_vNebw-e;T>1;okV!pwr3p&(5F5jc<;fi
z=<5CBig>W0aR`finQ3K*>tq~~gr`X;ywsw2YC_mxYg@Z&F?{qO^m)tJZNM&udc1lu
zd|41N?PAShxDab$W`2fkaSvoE?>v6c8mo+q4)^qpjir?|!*?^(d51D!NydSMLHC7=
zou6VICFZ9w?U$MM-BVPW{l+#w-`U#Mlxfdpvwmk|b7xbwsVOsw_)K$K^aP5U*f?z<
zo5|uVi<VBF+fY~kVU$(QpZEx#?eixH`zU_y`4fzn^C$RhpFi;lgykFw!aj~4&!6}t
z?!02KRCtC8&w1k8qn`pU@1Mq<X9tjuoGn2f?XxBR6=Bl+Ebc*mDADH-=Ed_Cd3Mmp
z5RRTLk@7x+I60@GrsSYcr1N=;4$qNb{jSEDCtoo6F;AX9rp}SL`|J1AI`Fdz=K=-i
z`hdGHfmenZ&x>bLy+!LOYQw&wClz73FFji+n^UE<zT)TwO!LB%GGDJyfnsJloyVxh
zoXenf^vd%RsmZxV4!JIgPa>#JPU9Issrs*?ETW5iwsrCA2#dZE_BH&di{HSV7xka<
zqW|B*v#nd-MmUx}Rp))jq>sTs`;9zj2^Y^xqYi%)xV(SY+`osr@XfqP;|GWf_`^9D
z!e0yqP9<+?D?c=Je}sFCAL|@8!dTy7K4H6yrwhwLUMUx`3k@g>Y5WX7_q;Tr@4`rf
zuoFyqe}S}1;sbfP=cR?|!t>H@M?c1M(7q44i8{6djpbQqKL$Oq8FJRyPY~yvo3`?1
zf&PIu<=;TlJ}>R32;1kWF;8>8nL1<g=LoxJrZG-<wa-lZcf`xtYyY92BWI&Af5z83
zKTX?;wA!<eG<Cm3nrdgK{Yt^2XQ$D=oZ{tEzXnV$_w2Nl3o_|kHA7A8$O`OBm2;zb
zyc`y_`5H-;PTQZ%Om=oOwY22hn=|b#`IgSyBo2_8%r`dYGXO+8?V8w;P8&KyyY(B$
zQS8=HJWKnets(4A{M>$<@nS3aY}?BJLRjnoVZXzVw(|G5^NPW&ejEI#euj1|j#uaX
zcR)ki#6KWRKL2R$|ARYi1oPGQH&xFv>1R#*e-S3_KjR+o2MPQIVO|GJKmS{Vr5(t5
zXMaMR^z$`^jXs^{ov|$HyfgS@=`426ng0K;7Jd61DNIrX7xemW*O3+LZbw^_-<fI7
zH?(v%HRdMUvYE!L54FuSP3D{ZTt2G1HL;U)Hw9UV?ykbKt-FM+#?RGV#*6Oq+1A~4
z2#ekkwiZ9??t0vL#bB21#$j=N-2gh&*AvWrBkt5!<|X>da@hKM62hc?BJKfCDD}w*
z^AdesgRrZwn-C}ZT2sI^^tIliZ|mzRh7a<xBz>*Th<)r?P3#1{P&VWw_zA(8Uy#>n
z;8V^)<JnF;<1+MJQ{L%--?38Pm7D+WBEOZSmg=+K13Zf^^V!zrdm=14N!XeAQJ2rc
zofmCC<E8zajb~f$?u~FPJ$%-4O!^oMw10A*rY%0}y?{%7zmK_Z!JYcfe3=(%Y{hfH
zAADBfF9rjrlDGJ*=Nh`_;U441@mZ-4VLpyO2p&UNSPt?^xrkk9FnAXt&h=S^eiCf+
zQu79V*H5+i;+d_yUTFN(`+|=p_^CCulRoPGKuhe0_^9V2ZYe%$%?ylxdVkQf{nHB&
zw*6D)XZxqy5O)1j#tEOce|iz(#Xr4RKgax2#@F&sS&xuv;GbTCG}ZjmOBF2YpVEfV
zKfMevxt8Rg))eB>ebc4dkT)#b-r?obN@4OazSeM8up6aT+v>4BHbSmq^Z0Dryk>;O
z4iMIaA8lR>?!0L87%w)j4bQgCYezVi9yYJTq>sTs8w+vj5}VfwT-v-&bKj1;@GUm)
za>NDv!R85nq#uESQ^{Lw-UAKYD{znT<Ji1<=yI5kV_U#u2n)+WUMUyb<`J(4KiB37
z{UlflatY}#k~jEpZC;oz9Gl-}Y~BOF$6_`ws#A-0%IX~QD?v}}iP*g^#4T#~mXQg^
z#oeH1+r1qK+jfun*><lNVb|_4PWZI#ULWGc?)B^EnB8N1ExX6MwC&zbq^V~2b}3lY
z?$MUe?hODY*Wz|>8A4ow>5EdUZA)xlup4E!eZi|y28MaAD!gvx8zz7IC4F$tuOv^n
zH@3Cp8k<`>n%g>B8amq=GEMo(Y*SlP6GE+iyL04oP3#0ew|)qGiY*()v$R>-AHqiP
zbH_i77yHR)+kTEAEH;I(QT%8>$8qNsgIVJr+Kty-DE1U*m;+ziR@f8BSKGe2Q`aE=
zJMa_tf@UMWV|gv^*WnkZy~evf$XAc|ClF@Y_L%#FaA&^cRq~=7^s^rCKNMloehBVC
znIN?^!n{7<>3RKY5SI2O<NXICPR36)E69wWST>ycOQk4q-G*}jEbD5-aSsW@Ecbe}
z$O^tzAUKr6CVXWHi^5af!a+RBrQS;))C#7*QSdOt37@oA)XNjFZjeE|T$_>R?$XO;
zx08mZ++=H0dxzh_)6pke{g%%5w$}E}TzhlAwYi}sI!{m&JE@&yAscBYIXv6#gfJgJ
zx1BIv+6kYJEKt|9PVGZj^p&tF{Mb$kxbup^BJD)epiac`>b&WIhSvET5T?%WH}@Ib
zsq@TNbe?6hb$%9M(k|g1@COOph%m3B(fK^WqD!LlMZ}5D*A%wVXO@LJFX#D}ExMwk
zJkNhl;SpEO6;#*J+8Nt(1U0c;oj3#aNYhUH&hO^YR`H_Er>x1{Ja}E~n?`0Dm|Hjb
z?gscV-{y$|y7*0_le|@@-w3K(@muh4PO25&f-u(>d5-rXC7-#Q25~0OJa(07+o0nY
zyt$jy)<9(&R(XesTgSMZ&vzLF_oMK;wjh2`tpX3><9|F)ca1uW_$EvKpRUthRFvJt
z%R#+62pT7#5Ym4>0%4g;(Q-_Ak0cI!ZQ@G1dz48h=eCRN7Z4xHeU<lU6V`oiof@G?
zUi@|h*M$RooL~Pq;8&TWT*4Xrersb>OTMF{DVOi)?Ci*7@-2<6&5eEoCfPGB?T+!O
zi5*ciJ->bn_!AjC0nfJWA?%6xxweP#Vte>(+ny&QEOtY|m>#z0DY)~B!7SSohsD3k
z@Kn%Y8+e+zKOJ}0JM$8I!*ba6=2nDB`<b{0JfYOjLYS9)m*GhWyY}W8h!cBLQ@+OD
zP!HU1h&<b(O`AiVpv`%X;ejdWkJkP!Lv1c><5Lsc(TQWw)uz^LrlF&w!RJPfj!D0*
z9n<LfTt~LGv$L(yaVY&-*bZN8ug`<5L|31WXIobZdjWo~t}<S9mCv@Wz8GQAIl^9q
zA9eL5xbup^5_C04hjF<3y_?%Whr0SwbAK7`)K#VtU1d3JU3~?@%=dQO1KKF{D-q@;
zy81$dU0r=S;sRZ*CErDK^;H&aTUTFgcpx83)YY0?M0B+lwxbia-CYOXY`gm!gjcT1
z9ZhidTAG_0pvPFp%y;@ZzqzS(vZWC=xUD@Cb^2;zJA6}@?*M<I%df?=t;>YH4nJ3y
z885obXIq!wh_L7@VQ;{Xy8I^GdBtD}x*ViS(B(IS4t4o0=KfaPsmn|wy3BIey8I4=
zneW?i4``#*??jlF=<@3kc6Iq}h!b6|Dc?nO`CS%mTbJK$cpx83)8*P+*t%R3+tG=Y
z>uNrqnann}Hu<d$Et9RyxppjQLTNiXCmS2G4NVPEU9E}j@I_sHFJvXU`aV3{x=Psl
z@pE;R@uI7IwsrM`2#Y=v_AmHRS3iV1uNW*rSA%p3y82<zp{{<!+&_vtb(LvES6L2Q
zS3iL;^ZhvP0d17}lL+$?UHt&UuC9IzaiXg=<-3Tke#)Y4>*}Ws59DKMx>}nHTUTph
zJ33+8UGAr_?e1s6>&kU`(r;>Lhvv3t8e7`hTATgMWJgnLL#Ll@rt$5J>T*qNhi~fg
z=fI!n^5^kv>oQ?qz|YlX#)~fV+1BMRBP{w#*q895E`J4gUNKmLE(hrnbor~GLtXxw
zxqlsZ>N3-aF0&lAE`JMQ=KD?D1KKF{w-M$gy8K0iU0wbL;zXBg%6Ac6{*Fc4*5&US
z9>~Yibh$Pcwl3Gic64Ipy4u!;8K8E2CA*<B)0%5(>&!J|o7yveb6ZPW6ZVosb+sn8
z!xwe+`;e9B>JRX2>ndSC#Lv}L#*41<+1AycAT0Vw*pKm}uKpYDykf8fT@BJD=;}{F
zhr0SRbN@N+)K#VtU1d3JUHuP)neQ)f4``#*zeJdq=<1IUc6IgN5huD@Q@)Gn>aQ%?
zwyyr#@IXG6rmMBNuywU2wxbhbch%kzvnD`!a}D4(;8o@>2)Fl;=(&nj-krb^8e@3g
zr@}I)l=6OuaJBZp59ngw{<QuKD&Ar&&d<7g_?ucXt(|SY-!X|V%4a(|av9j}j>*Z6
zmP|)3mv=mon%I%jvpxJC{7HNG1D@^nK-eGgv)hB{GhuScS|0nXn@l9*sHcA-%>}KG
zmmn^n>8x8)=0X$S>j>5dg{H)j=3fm>=_74e-KAlEDLgMFKh6ufWso@Lx5m(v{A}1d
zE5G$s@*@rMAvT21M<5f(U+r7kh;+7GPe7P9WE1YZVlc~w$Qtp9z@-dN!d>#)wxFL`
zuliZ%cM5PwvmSTF7w#LO1*hW9>kU|U<r?OHBb{v@PQlkV{s(blAMic((taP`KF;~s
z=_|aW{KoX3EjYi)p7ZkooHYN}qPd0NfZTEcCM8K=%eD(IV8n&kr@X=Yi$zEBnXBa3
zT(01}C-d^auka#y**MH^6>y{sL4F1)%#nMkH+ZWpdXi@zACc0T>O9w4IFhH0!#p=6
z<ta#ErfMzvWQ$(S)(d+}`lng+#kQX49ayy)@p8#`?C(zdat`zx??nZ6lXJ%WasHh@
zX;0X7>74=I#ny7Zlkeob7<bWq`}>|}nsN$0$LS~HXODqw{IeW<_SxJEZ2Oru{@Dhf
zbN2TIpIh<!3+C+Eu0Dvl_7fI#yV?voY||`<%w3;`I4L*FDs$d)Kj~~6f33F_d0nq&
zycf`_?JMmcn&rnw)TF-IES|<8zt~dDZ+&pueoqaYt}bN@&O;vB_SDt$S?vA!c;2SU
zqV2-{5f*t9?|%4ggimq-?z~w353u|wv&jBRlo1P--nPWFtGtU$TCr0XB1}7VaT31O
zConJaux&x}bQzulo=^heN&4O^3?DK6(T_JGEw6z81yfEK@_;7x<j7vT9ctf6%DV*V
zYDieUQ*kNqZmxxB_QN#*SL_knF57bx;<D<f0K1y?+HW#Ut3Wz4%>&U7r{~qt%sE+C
z*1BkDaXDyszA}p=<hZ`fb_c&pYZYN*1)eW~gGu#wFNxC(e(>$sS-qaDwtcCz4M@xN
zYQ-v!dSiazzpe%N>2!2&2z7d+cYdlBFuAa<eV6Gp%VFyw`_PA=?UnEo9kAPUhvDN(
zx~*v!PZ*Omg1h3KyY1UAxX^XtIy$m`Lvy|plb;Rk`6j%~(J|T4(At*8yB?XAd~<YI
zQxiMl#Gwx8$8AUXq+LG%&!)XA|APAyL?*<$96$E=55%394bw3pjJ8etbUKc0sEhO$
zZ2KL;b{H6G_TV|l&uZIle(Nk=BtMB`e*I2<Hf)!b-@p>{Tb+=f#4*1?CqElDWaT$p
zB|p+&xpf`r=Od7p_<N&(*)q5WVfuSxxbup^68yb!;8KYvaF_hHE$C;~zkb$s{aS=c
zb1&}XOXUX{T!&{~zc>Eg6$p!M;@$xIL{}nCd@S*aY=5uYf{Q;SaN4$Bi)P?|1^ynE
z((yUVEs<qu?lRr7?R=AepG9Btw|zYNfjcc6;laisA6F&uVflfJa-!_q2JdPsAK^vZ
zx+`GI$;)mFM|iPu$je9)FM>q>a8YLNRDR<gE1#MM!}K%PTluo@p)I7}_#ni~b(g+>
zd^g#`jqnA;7Cr=Jvu)u+5tjBfx7qV<!fzw`{<M(+ZRv?t`izr)vP$}_mHuQaz3-&Y
zS4lr*($oIwJr#Hd3C<_m_QAl<tUHxX;tjy1zeC&xRdFeAKjQcec+ZRZk(1fkmiF|V
zK9ErF_J~BmOS}``K$mYL7WJVG(0QJhQ0L(@2<cKjt#`ecGa9nkfs&r(78IV-20Ns_
z_gVxG=?LjG4rb)RcsTqD?&{u_YEZC%{I-J!?unt_%)Lcr@Wn9u`qkdFU!1D!(>~5B
zuY|nTV~4GfXW7ZeEaK&YuM**=TG{F6&mi4aB!oPVemL1jsJ?fp=0?GwA+&DaF4nZE
zp{1q8pKNJv&Nk+<ot-$Rp}n!e$2)T^?H&2NGuK%YJK_{*pI{DUl6FwRGuuI+`v}kD
zXV2|W*O*57Ej}MvpbqMO<PgGk`hy6w-#UytuNVx<D)TCFSbVSNO`yX*?cwJB2;7CI
zZ43ID<<QTXr$-@7+Bf4)eictB^#Y!G$zIO`2-|%d-}!zd;+9?;dLQTU-s|~ji%;5U
z>LT}gKE{-XWjeOKo_~8?l)8Tp{LuH}M|(SF%0nB*woFZZ;6+N;>e&`WZ*Rf#wguX{
z(Dpq6aklMyq6%v`_X$x?38yZ3*e`Yj;c9cRwf6>P+9uoE@m6cApUJnk`PqEFp}nO8
zi)a~4!8W(IN1gYY*a_|QDd11a`&2yJ?Ub;m;petf#!EZp^AX5M+UYY97MT<F4E)$m
zZ^fNg43^MNgLDaN63+r1%J$jj{v6!dPMK!gf_`Q>^s{cK&qtW~J`eYRHcI^hgn7xD
z#M2RW+v#%=C+)PRd{v)O=OyhId!a>J=FPZY>_vtL^0BlviP~J)YZ5iF9i3RYuC`CM
zOg6M-pq-N~SUAWxXZ%S&)8yy#O)c%&Y-3bcYhpWm(KmVtWF@+K8=h@lCG4g6xw^`D
z(N#VlS)h(+y|^7=(MQ5wjvsaP6}a<?!4h;eNSC0iuLK?H>Z{EC)wokvnP%I9er7rJ
zv*zia5oW%x!9AdjQs03vFVWSPA?)hvKOs(ZwWfR*(bd;lv~68|o#BCeEKOHyb7AXh
zO>9ReY&*<(HklV>y|PcXZIL}6^F~t+dtWq)bd=$B@c-zGNw~{|9|icHL?8EZ95ji!
ztlT9Wa$S;6PiKR-DwN7kEQZiU|Cc(U=5rV5N85fVUe6$HRadLjd@g)ZH7P5;=-W}2
z^&USbq4|TprQTu6$3krK7Rz3FrHdgL{_5)A2AXVpl+nBJOd0KhOho4NljX;H*|M6s
zukzjl+*`Fzn_^6OCBIcSkIy1Z75&_nEM^54eVvY)Q|)Y~KC?N#>LE-@=I;Y<VjK8;
zWFfQ-A3#{zKVk33kGA1oaOXvP#CWksAHwstg)sex5ssyYjra)Sd5I0$j!{z#5BYq|
z;K_TQA4Hh8<fG>Paonjl<YC)_rtwKU2fV`15nf3@0t45=hs=$C3Ta9I)40d@apuoh
zw_!eUKRbkl<sh$=k=SgEbrg-yBhG!#Q|KqbZic)<`itZZ`Vs#>!gDy^eye%U^Aq6X
zST&OGwSNY5#4giza?a(mh^z8`=hD?(%>%9S{uQ+BcRN3au>Ec)^RnOV`~t%6yPb>^
z9_@EKzleBwxARN-IreTR<7>U!soQ?|PWzXUrrNumUs15={5|aj-|hS=U~;j);hqId
zlixV+r}1R~eWu&e1$eCXqOSfUI1fR$cimTi9sJSOsW}t0w{IYv>_2hYqEy7{1;3z$
zZ_=bQ<*5ViOnolj*ov1yni?nbndZ)hd}Cv4%Ve&jrL(y$-_+jhY`3V1jm|QYYwl=k
zZpp(=(_VcG{E5B#HlC#|l7GU!gP-d^F<xvWpN}li?&$J=A7QZ-gnbV`+Q=W^&MO8(
z4<K#QytlWcK7n1qmTfEU3`V+pYjp>@5B@Ruma_8s$U<1we?wTxL)cI7V_AQSJ1@$Y
z@gm=!<9XXcnEu}pj-^L`@C(HA5}DqDHO?3w^7*B~lm6gm2-9Bwhq?a>ciLF;ux&xp
z_)k0syh1;PSJIEbz_sup{lRaLmh_L}9^=R94}Jlg9Oe_&aXejE4)RJFi4L+qAdTPS
z=k^CeKMD5hrREL#qI-%j^aml&VSjLo=?{JlK9ViY60{Mvntj2Ypdofv`hwpgu1a69
z1j4#M`5kE3eZYSqZ1(}o!|ntAfUw&KFiv>0`+z?pUiyIl*3Yp%fbq5Z0M;2K7@TYJ
zKS)!p5BQUUMf(8S2lfGf228GMeZUd~x0vx?qJ7XdkL^bEI<R?Y$A2+=O8fjF!fZc3
zGWWmYPMv3(Z43IDHdsGv+NsMl?K<28+Gv}r5auOkZ+#c(r0(QBS`Rof_N&=7sPROd
z$FksUWVO}9&#691?I~CdT0-9*|E)26Fx6_cYvAtf(>NBH1uq<ntf}+VJ9wVAK(Slb
zlKNhpNQ{>;vn`E{9j%<T=xoX0YVPQ4!=b}|HXEJ1sEHl#d)GsD(l>0tv)DcMy@Z{B
zpWFAU_{V8o;q#FNK5Jb$5n<6o!ZtBI`iYZp=M{rleeZI{V+Yx|(v@TCe$#uG*8iRY
z-lhNLvt8cP5SB6#b}D`>?`GV2vHxYf$oLFAZ(9iEbq|DN>CtY_4AZOq3Xiq=Upt?(
z44$;_(-Eek-P7Ffg*)3f(=cD=b#FWeG|>MFuQ3?77Cxl^J;%_!5AHF(o&I+_<|x8^
zoPG{GhA^CW270{6D`g~l$o`jj=i%q}zd}C=_7&Lqkp3chgTCAUhUvoo_lW6#&jugK
z{qNE=lKt-%(6H?o$71(IT$TQJX@t!<Y%A#4eek&m+kG(evHRfrA?)_Sj1&IsKKOjZ
zOCNlH{T%Cq8DFapX1&>c@C8Uytq;CX!J>VzjKj78CRepScxl30yc=GcozV7=ZA;ok
zVE@pbFE+eNJ3Sd;w$plZzXW&cKGSIXkgBIWwrxcN!lZo}?g4GI(ME)MNk6<1VW~gq
zhc88(^usl~3DXa=EJ^)vlSSX|hnp2X(=53kuFVRoX3304`!{<Y^@J4XQDyxL=Z2oE
z<-H0=ejQoR&+EXy$e#Tl<7FPP9k34kI`Ly2uy4N)Y_hu6ukyAdo)_zI7CyYDsdeIV
zlZN#jroq~tNkhJv#)B;;UuU5&U4tOw=&$lVZ+>AJ)_7e=&-{o(z6skwnud<74|42w
zIevueIf0bd3%rn4o!5l3cu1=i@uX#!dne-Ta$jnddl&P=#kAaGX_xydz@#mNY3jVI
zO&aE}_GN-!<}c-D9Bl;eN#!0wdgezQDfb9z8ae`FA0jef|2YaATLxo_j;^DA$WVB-
z_rOe$F0MdUXm6uu=rH>x=6U)>QTVIQjKW2>ZKr{6@Fc#{gFrhe&j*`4Sq|<cw$nVc
zN}9BlW&&klnkwJQDEm|R4j<l8C>8xfg-SY)uf+4CP42u;Qv<eWHaBFlxm-IoX=eD+
z4JLf>uO-)tIiRTTSrZ#=GuPOT*L5<JX5MEKJd0nH#WQ)PJgB3D<?wTTPsVF`r0V%>
z>)RB<B2U8d_|X^JhdZwr%<?@c>kROyPkbH^+LT^H-w)U{esLNpZziCx&nhY)%(i}m
zxfgLKP4Xo4Szi6D_3uW6NqZLefOklzj4-dqc>4VlA7R(Fmk=i=vSu|H+s^XfEriVE
zw6FFtvuvw9Q3buvdd|v=cAomQ4r{{|m6qwD{$Bd;LZ6c7H?g-GpU1&5okrDFd0jov
zVQMosi3Q@8Ob+`QnsK6hW2fKJ(bkBW&Q|w??wZ(fJwE_>iJl+Cv#sZZ9m3DmbH<CF
z^V!z(ha)U{NZ3vIQO_TNJFgflqUT!QSpRXnI`2^d4Xw+MM3}mKv$-$ePF-fcqRT9k
zt;>%^n6w{*d%zzg@Hm8d6^$+*M%dNmM<Y&jxu&QSbeX>N<1M<je{ze-pFF@{yxVny
zGMe2C{~P_nFV90ATH`0_x4376cFpd$o`i4}eP6=4J}u214H>_wBa_2n4h{ZfLqiTH
zJT>E_r>1<q(>;)}CU!*K^&Yz?gFn&tr{G!ioq9yrQ}J{4o$;dYe75!d83>E6683cb
zsPE6jomUKI>3bX&KR@SI&>?TnGWTcWP90}nqT?)wt>e!_n6#gZd%zP){d|OZ$$p5Z
zA?)h-a}XywUQ@nC$CLK%yuhMu>-h@}59EX6qT2hpYI9+`;We=xomjc9Hcn1v@QMfy
zIce|Ax3)A*`VE~ex%P&Zw#K%OeAYQ1rzW<;7w2YP3|Wb;z68&<t`c?|ey*-EUUZeu
zwywS$VbM9lUWOla^>*BO#b61#8l=Ox(LL+w6`(_1eWkg-3U}%%(}=FJ9Ja2$24Uv=
zPq+uPQR;t2n3w44OA&T;_0@<IU9BnKMRfHJi?*$+uQfc7kEQ8qZ7ytGt%>dEgl%`(
z&)RnP^$4$AmvLZDHrL#mZO-MJI`WN}z-?~E*=4P*Fu~2Ot<Je+HL)GOsmpH!f1=B8
z!n3W*guNL*SC<(ty3A)=m*0l4=qq7w#gDrDcHDWzU<tY$q)X7{cYqFc`JLweF5Ich
zOe4C?a@e~3UWA$NdvFhEqtx$1n3w4CTM%}2`Q3;UU9KtLMRfW77HwOXKVWzuA4}8a
z+FaPWToc>TiIwXr9ASKE$#2W}erIQUwvC5CX8qRAhQ`U}mWI4@K2A++hcD{t2O%rb
z)eqs>)>XnjjGwEkj2B(yv#qNiLs;~Yu#e(LUHv%jykf8fT@BJD=;|jxhr0SnbN>|X
z)K#VtU1d3JUHvS=%=a_62eeV@e?^#==;}uhc6IgBh!b6{Dc?nO^>Y?&TUS4Ccpx83
z)79Es*t%L1JFXLIons8+ZrWV>#hhFDBKVZKDE6%!AB#W8d4lI{!+DJOZA9&S*_27}
zX}>rI5#4a{ziRMr#<<ptzaymf^~_ap5_NheQ^bosGx$Q;_U&`{dKFeBr>0Aj_$;G_
z<7=vZg_{=lRE2iwRRfn^SC@W={_EgH>vml|pQUYl6VJ9zeG6gHW#WAUKfaItZQOaq
zVAhx-21729bgMltpb6Q_yWe_V8Q)4o9#zW+9pu>SyTG}*IudZ|yzc==^qo41bamfH
zocq2s>jmEeP5l5cx#SE7SB}S{UT#}NFWmiJkz+gL)Q**J4QlJY_S)-ftxnSZ{0OoU
zo5*L|CjJCrsdK`9j2~^{zv0e{c9`*^Yd^!Yt!qC=IF=r|_U|Tr3<lb4ue@ZP<EIGI
zZvMjD{{wg7n|YDOuMijT2fY*iVlZ$jdCPj_uMOS*#68B3qx-ZeVLr~fA9xI5VL8Yv
z<s$tP=X{CxJN)eNI`bC#Nw6E2nm6dX>yb8J(kA5_oxcPh$?K8J*GR5S{s#1%w&@*3
zT$Q!S<!55nDenYLd!6#P2;1wF%+p?{{4a#vbxOtwul73S?-4KSlz-6Av2{wu*IK7k
zeUP<R=#NNKZJqMJ6)d_=N&CUQLjMDpT<mL;_KPlGknC-$?K2-)lKr60^8Bf!`6t*0
z)gN;noc-}U=BU^o|1ZiSFm%icMjC|uRl!pAj5mFmqEUxNBW=@OTS>7o;o`aPe6Mzk
zdS9S`URBN0Vq5Bbv4Z|Vf1`W`FB9P7;s#bIX3MHWHgGRBqdz{L0Dq`?A9o&ktwx@~
ziv@mhe&!Osqu}JJRyOvw)W$>a4SjyhBK<_XpUTY#ZiDtAF4z0SwrtZ2Dp#Ht!{{36
z#%8dtsvZP*pq*NavWXADXR+(+@od}m4G2qp5N{oR^dU~bomUJ7N&;g(Tu;>WuwIQc
zVjEAyGwGd#AKz#E7UndC-VW$Ske36Cri<FYXu1%#)qD^7WaP#Eg)e>ceu}xDiaW~@
zrCsNpcrV40f<<YEFzH)18(OCuTBL86A>8}Ap`QCaLs-Zs*PyvRyA^5SULAb{be(?E
zM$nAav!w~d*#sQ1Z}gK+hBtH?;_$hYdA@r?dwqt4d5p|-A<Oq|nD!osH=2#ZY;@e2
zh|A%d3VyjXKc_yas<ksyE@${XR-SWnPvF4H=`4(H^URvFR6JpNyg(cFx6<ufj<J0O
zdq8S6vGm@WZR~8wLE0FfrH!3~XS<Ev2VrSP#Je|sY-3w+=M{s2lEB!;xLz%7jI^bV
zor`DEI}bm%jg6p<1$jAbESfIVPx28>7s8~C-4A(D_s=)?`<wd(xHEl}cG!;Mv_qJ*
zv2BLdMTQphvCD84%EXJbxTh<Gg?zG&aW8<hvA38uc3;qpx3P#esJ5~dcy2qp5OH=p
zyI8_bJG%t&ZacdaakbjnWx%o98FifPtU<*Sw!C&0DV25&VntWoNDUod&ifB0&lQhy
zmbR}dRo?`e=r*UHk1QZ;{F4^Is2kK9;x*&PF-|M)yg0^TytLDHJlpNG1L0VDwA0Qo
zz4BqW4<m+$d>&x%WW3XcFnQT-?w8}v_Dmj_FKJwX=YUtVQ{goR1J}Zbw3jOl-7ef?
z{5azs?w<+s3EN9NU04qCN*Rg0!K0$lhX;4OBlMGCY>!LI8}!}rPM9v7gOK+h9tb{?
zJ?N!qqwX`iLBnqE>@Rm9uF4o^DTI|B=>ZLUOw)_7J*HtE_L!z0VRuZ!IN{A6)9ggN
zjA?f1=h&Er@wLV@tTRY3c>iGlX{wEBu2Qh*m`2`zxEe6Is*P!uBDlpyF-x-#dYr;O
zjN=rxJ&r|ogFmqm^z&@ku!5!PM{u`o!8Hg=+X#I*?Ds-EFSd;#C(XE(ChVK)ya|)W
z&X@k89cJIguzDxOv|WbTcCfKVwF~mY{eR)U!LYp$m%cd5`|Gnbf8?8GBJ3gL0WiI%
zaD&=w7w*H0(xJaWT-r01lVuS)8AFHr*htr_5A!5{99M<>VeSO;vAjr!xTGU<vX`UG
zKImPh_WS9*USZl*UY>d3vh&eA>3Zfj10~O}EcoV}NhkSSW%3bx&i#h?tGxX|K6-x_
z`IPgcSRS5rJp&y1Mw-C6hmX(XPvfojO2CtKLzb@-Kk~>t!?LBk8-d45a7pJkcy}|T
zmGb6*W9LaY`yMyXdEf~hmetNPEN99)2s~cohi$_ifAcIYUaTjM@1>7@Cv-ucUx#@s
zK1*IK6My7cwKd4;k;sEIZsvU<#4RK3!xf+F>))&NE9EUH+`4+^!9JP3+hY(%-|ZO~
zACd0kk&YMpg)kra23q(HxeL~6d?Z)8%kl*H&}AJC-^KYI-o<H3JS!nRyr*w;uzO^r
zuU8+46^1dy=iWP>xkVm5Z=i_1lSO>7Qk}!4eNKtnRhZfr#;^B=^LZ`|U>qgsH<>tv
zY2sI*eXsXMO6pVqH4eiW&4{b__VpdWngi35@3m0MC#%9LMtJ5?$Y%oItdk?aXPwC2
zTGG7$awXqe@%&W4DKpmTI&Y2lG%L(Dz`7MUYwSY!;0KOzJce>spX%6EeF(<#+zNiQ
zZq})1@#~(Ac-k4U`OiUEbe?IRg&)UX&&8cr42H4^jQPNF8G5OD(q^7a^8!4R-V5<_
z$6wdtOu8U1=$}3R5lt7`Ueb)F3t=+;dJ*zsTYIs&zr@^c!##;7dyXSYJ3jt;nW6P^
zLyP&?W%vQxEiUF$fxd*WkWaQ@>W^*<-qAbE`0II~85@LLu4-TTOV0;fd>xtJcq!uS
zao6n<cE(+=K)gHddL`m&jk{h29DCeFUFNv!)heE_<&C>ms>@va)n^Iz50CT>nKK0Y
z`-b}myLZ9{=sC~+p3%X61zYd+j|`0TspopHe`t7MXjk9pz&LG#o;&TQ`5NjqX}i4s
z-o8Daf-QLc<9*kTdpj@>3b!J)1!a5<${U^ERD2}Pd}>ISn(JiS!1S(a8#f)J9hfc^
zr>Yx*tEw9Ul$m_I7G)4yz-O@qug9}(3*LY*^_RL$yw~AJTkuBQdBtF$BrxW)1%0EY
zm#Qaiu?26zGwHn*Ki3xAVPGmR#}-7>h3$xZMAL;Zu?24fU6$kR=Kc<Ie<$utAEh0(
z_c-kkCS%KY8(Qx%v?B6C88+d)2VSJb561?ww8ovZ1=J7M7Q6{G<F-I+0LNc%2Hdp;
z??Rky3*IYX#}>Q~@vbd+KjLcHf)4=4wguE@+Jb*k@q{hU795*C*VVtn_(asX4}k}x
z+iL#d!w9n<zN8*Zp)NjR!s4rb6h4#qXiq&4{W^YuFNA*l;|5=S@E0WLTiHGV>ClFE
zBc6Aa7Ih3v?^8%C=l9cpAZ~U1wcck;Uc%dz@L_i(`&~Wd%5HyV2hNV#zYE8<>oZX&
z(y?e5AKm6Z2io*!sApTihv?bojF0wtz)`1@q{!1)Kr)TjTmm1AaEw<Y@Y%9|KzuZo
zAMZ5e3)8;(uz<u<COA8Fx==*?{LCacRX!c#afZ95H$NAAf0$*5f5wBG({r4GH@+U*
z#+iI)0;k2yRfLrG55EB3&i2w%nOW~B<waZlMO7Xo!nMVV3r4$rHRScUP&c-reDrN>
z-S`Uf*y`1t%5TQ7JW|JeCcnd|KRz=J@AMSEhBVaEuk*g3Vc)<rFY1=~VT@xs4TDca
zd`SnsWW2^aS(o%pC7*S$bl)}UX^ZHOz8P?)|32v~5Lb`iet<A(*yZ{maRk@Oi+PCt
zN?x?8KLNh93Bh4|;rN`sPl&t5`>CN#`LLbZ`MwJBV!r=Q9K|EX_;}`J%Z71Gr(rmQ
z#L!gfK(lSJHZ#VJNp|h42-Qy5HdsE&b2G+N+`q%|hi)6Qc572Q{2Szp^V`&Cwdc(E
zgK=ki)BF;`oaioTUhGYC=&~1?msJ9TPgsLDJzlD0G$F*3|23$zqo5^Mi|Fto{8M)S
zNm(pVj(XhxTZBUy*LlAqT<{<(;Hfm?1N_0H7yV-TKbl`ykNBRCp`-9M9c6EcYv=c8
zgk@aLvho+Vm8-qK08eyC@RD&MnMTYxB-e5GG)|ifEMra`6+Mx5V^P~%P2E!WVfSe9
z@IKcnkG2GMPT3OXkwQJJLVj|=#<|qAGP$wHgK|zGt@eBLyQyL$s+Dam@RRzCWc;<>
zdeWDC7NT}R<jDHqGu!G$;ET<&c@f-r-K_IYL>j3>7;WUH=U)PQNExnQ?VW7#PJ7vY
zX%zQ1G%BSV3V*G43h)_L?F)VLld#4d=nl@>rF~@>H`RA@OeK2#We0YKp|wTPuJafc
z+&>vyWebtdJppS=_Q40$VT=>%8z`*TJ!w0})akuQ`*GTzBTa_S#*gbKZv>CL=<7vb
zmaj+Hrg|%#17p1eG{LXzUAhfAOP}xF$ScAZYzE`cLHx~8fQr8l;&=KLU6OJ3zjfZ1
z6`$$ZN=}D2f*<HTy8jG%@L4^lGN)k>ANz3mG7M?fZ6OcNcUmaZbzUlUU%=!-A8$)A
zQKn*R_%89#DM$%k!g^ojoeO$lSoB2qUzY+mil6e%2YwmnPRQI5Jlcc9{>(tm*jzn*
zcW|U!%KCG2rE+&UyAS8eXDc|#O>8!CFbg<}4XWh>_&kl!S`Atw*wab_FSx9)_1^UC
zZaCA}Y12K+4Fws#8r+@BVT-Hu4aD0-JiX(lD&AIAq};)7yk30357^wDncE-mu^D^}
zDSv7>A7H5Z((`R+l20k%I8HJ(Whd>k0qdS-Rg=e^Wqd1eI#VuG^j-#>sR5iVUYLB)
zKj2SWvfFCGM*RbYIZ&Z2*l%ru*e<Z@|2!`}cHP)`-|qClQ2($tl~x2=luqZx_YqrY
z$?0hKwjnROzq`oj3fmsP?Q*dSYh5`Fx*~RiaGvLVDd6X$uS646z8d{B{@Q>mKe3I}
zLBd$u4M-<?D|6d2C#`UBwm}nc#0Evj6?I+<U~3~fI+uZ-rTxj-ppI925_c$wTQ70B
zLJ+q};^xA*`XDZ(x7oy%eQ0`7`{C4wGfn&<{YG+GsYOIzG#{1n;c2A`#wTamE#3jY
zOa;KMv(o-T&?X2w&zmnEEZ~z5d_CHtcY(yy%SZe<&>Mb3s0}iatIJDYwR<GJW1`>t
z?d_(oCQZ-lJCyZjsklA(a6}-3)nR=9bY?2>y_jZw2pjdYrE)GEmVHwQlg1j%IoEr-
zg^gs&IJ6gzo7KKHhv^22`I5H{Wmt<cbXa8=32}73W9kz%-e{yeLmXuVd9L<$@k4DG
zCWUj~;D1-k7`M-loA=Ij8{g!Omk;a4dGvhb&u<HDxAL#|M%9r8x<ZF2uHU|4*?EuQ
zO>i2Ao>={2PQF~28pqj}=v*utL7CSpSRb}JO->i)_C?CGS-~_tnY|bLdZyP;VN0|s
z7u)gWR=LjhCX`<7oX?bVs#td(JrXI`&M{3rzK*ck6WF!GqXsN_Q_j`WK~D@Up03_g
zm80tz^|lptu?9R}Ve!0K<LC-Jx(YVO?w{01+R}l2feu^>S}D-#vS`5v?Yp+8Z)AL6
zcql#Ew{u`@e6*VZ<b6YgZeKAwU79Ntr*!pL?RK@-UzmnU_p@nQ@#{tZq%}lf{RJ%G
zOdnQ>?hJHphsE0_tDHt4zvVtvkum$?vBH$qZs$w+d@siIAk9`C(fiy%)yOR#HhIL4
z>Im%zb-&l*1AfQQ;7;A?a9qc}mwNd`jO*BM^aFR>0{x0rr$2eKhK(55E(0STVZ`I}
zdiW>w`>K2!r#L-lY+->G0p8<8IvUs2<wf-refZ$m9&JErMwC}!>46OoZ3MnmbFkOX
zV@f4w(uS~2fc4>vFUoa*$3wYyVji~Mo0>1=dgkXUr5Q=Ya$q!-+HJ{gi|6oMr5u#U
zAkwk#-G=^i17yqok}~F<eW2Wjfk*js%rAZDI&XtF!t_E1a^>?ijKi~xfk-cjW=LnP
zH;y#Y7jvHm@uPXI^7fd#_VT_Ej%Th#Sn$bXNO!e&ot*|eRXG<%zbD>@*{!j|I3H$4
z`@3^}hui}*I`Zwg=E=skrp#n>XG>Fiz9paGw|cT|?RZbSqfO80%iC);vGFEYb7x~V
z-_eq#?CR<t41Q%C{}A#Ho;lWFT@dzA{M>f~8BaXQp3g@h8}V5(2+KHzu!rHtG0r6J
zykfAFo~I#<^d1B}-FEa`gpY7MO`Vqy=;^aFvIx^Z%bEKW?!up@m#Sy^Y}z*<Oxgw9
z170DG{Rs1tcLvi4%Y3<<@wE?eOP0E_Pxz9RqRWl&=~=kh>YUAKi#FHgs4x5`$c)0(
zd|-_AccL$;`s=|L>%Pj`zV^Sz2X^<_?l;3-T^`4xv@IMf;7du@`I)k^H4J0iw7XOc
zzpur()!xD0%;DkuUf<s@{SD*Ss(5X`7+&uk+*O(nX`KLCg(8lkG5rE@HhBl(l$470
zc<v<PO~chtfH_qr`1Gk8E!m?_ShP%RL$kn_HZ({1EYLpaIbN}E6~yzIwnpq+XgAh*
z^GpZ*SLsdLI>0zQyLQc`71CMj9Yz|4&qbN-?~*^<(2_YB;Y;`lX{`1hX?VHWNkf~*
zUs9R{ljeIUqu7QYnrGo(@?4Dn#~C`0H+jpPb3D(K_XLCcL<jfwQ#|in$T=(%zQJU0
zUk;e?M;XcUlMRhuM08XQf>qy29ZGpU_}*=$RNj%v?jJ8_viNXq&e!9t|3#m_8gRVd
zg4qzLn&p>V1Rnr<PV~qcmVW=-APxl!``>!6uZVGyp5nFqmd#!dnglkbsDX=qKSz8b
z_`GV!BJJtyWZu-)7r{Bl8=K9P{fV(%!=vM98>8sU(FdoVj<U;zzI=3iFx`XY?tz}}
z!Sq;Pk8&A%`*uw1)NQ&t9Bn+5x!yxWoqnc~Z3s(wA4ENDtKtJlU03q~o=tk7`y4}8
z^h@-Udd4;;bi#bsde1`|X#=({^Et#@?Y+R{@j{b_=%MH^ahV2lSKf;a?n?}=_!ZPc
z#goxR`U+fUd8xrCO!V(%CN0N=@p+A1dxv_{X(fLB*u^;z;?|-5o&nvH3uD1VT*~Ve
z%wr)e|Emz@+%12cudvJiYQv*S0~^Hj|73U+`7u4^!JnJ{4wL@1CJkwCK^~OXUvXw1
z>Al{-#CJFy^NYmeyb8x}Z!|RC6yT-m>n_zYlRX{aes*@GgvqnRrh$$7WxT$o#s$0m
z%Dz%A-G`I+3{dUqs9QoBp(0ah?0>Guo{kjcP2GAcc&eE*D{OB|O*B-d8ehDP<y@d_
zwD0qFgeedDrIg1zR9MeTQJ13dl=m*Chg{#yJL-(%I__7oI33@|FLn>;*YFBADJjv&
zrH6288_P(1OFmWc0}}q;LJ`))md$&Se^BUZ6dc)9LlfD&k7crC^L~VF*?d5SL)k>(
zus2K(*?fq1$VT3Sv^X8xSHchp)0Xu0dJCDUVhJP6tQL(Umuk3-pBO;fwB_*;<Qd4L
zN=io@Rj?op)Dg?^QI^A!$Hx%1<?(S94&@Prr@T)xJ?MOjcgW+8xUQgLb0y5hP3^`k
z(6knVs~--|L=ltE<vDEFq`XpLsU5tY>CD_*A&VjW{z^&hk0<`BTKFUTsHI2y(GH>h
zsvUj?{0Fj)=HiGn3KYHiEX!}n@m~?P<@h-j4&@kyr@SvPJ>>XB-XTXmk8yuEo=Jx`
zk{8#aC2ad;Uk%dfHc$Kzug?2A;h^~qgLj4TPiTX1>gGTZ(`0-Pk$pVlaIR!*{efeD
z?JeA?_By~Kq`n1ua&5xdlv5L9eWSxWu0nUuU2$U+-b6eaV!QLGthv$#F;CvN;?6y;
z<ehQc-})WH`*#iRoR>=K+XjZl#=C>=&4iE>@ss+uYWS4X_f1~G^MdB-M~JuO{$qnj
zem8(CIB2SlexDMXnVBu5XXere3!J9L=Xx;l>{kjietNnwjX%gi+XNR+ZD#>aQ@Y9E
zq&ydg>nPL4{E}W%KyTIJxTVRt(ln-(b)p8n=Wul_4TqOlL#iliKc_ivQf+cg3|D_x
zS>rS)oV9VB!^P~rNS^Bwa4>0@FKMhs=}Xqf@E}mU&#HuI_}>u2IfOZ277}tvYo1Q9
zamp1{BgG0f0hL)puv0?O^kExqd<^i^baZ-7O}5C%t41&l!s{k{2csf&Ziwgbx_W79
zvUJFye_{fzW`wMBZNrq%@N<%v$sK?iG&kuwJK5Who$da#gzLRxB{!|@<|#Jsnc3MH
zWq->U00ipSBs`z$Q3jx5@;S{;tE7}KU;|Z9RO;+z4;1IIWLwAu@BI(KrlJ|7=*RsO
zZR25?VySp|1}`sP!mkg`&0@53|Lxm@gxa_U!LBR28~z`6ZvtmWQMC{E+zBKk0R{*z
zh!_I0M3y^u?%bJ)d0_%15DZC7!mf;WO$H`2!z_WI;)r|PUN;mKTtP&|72I(J5d}B&
zbpsU@#RUy2Zm8e$RMqJ|UEO#3&IDfG|JT3Yy|tWEr%qKrb!zGA>WgJ%$=cSoj$c6z
z=fzwv{Wbiw5ik*^|1xWKu5JDXG--dD7fsUenl%T<`}-KLwaYxOk?T%kd-#m*4+vjw
zpVxB$q^?%ZXe{A7raisg-Nj;8Ur(`7V6Z2j&*Q5go%mF?_bHG}?%1ju`|q}nozPF#
z3?6`={e`S^k@hG2{B<|ROCLl3jw$vHw%>RVVV(XjOpkT9zry8}pyi@<w<Ilj7UJI^
zhZXsE=l%mOZ7lUzI%WMVhxJ>X{)I4QKLnS2Mkkc|-|+L2^|e1E?60r=6LGS>mRY~R
z822Zno!j{zC7bJO#01yZu-Fq`;rbfP@&yBUjDnAM4h{J$vDsR1??=lzdzhF#R;$&%
zayO4u?#6fG3cZy+eC@4{&qEhVrS5un&BJOYx2G4ennPU)R@>p%SS4)^em+(iFIc5t
zV|6aVf;rN5$B$T@2bWiZmV(tV9rl(#AMM|!vunY7Kn}4w-?<Cm601xjSY<ghR`)`f
z`R)lfl#NpFjW934>TU@8SY3!Xx$l|vI}KJllx&UFeVh)|qcyB%YoW24$(_Ii&ZI`W
znm=W2?tawIjh|T0X06fD_V;LJP0`UFt7x>{_h5{y<-ADcae(4w9%jwY$vM!YnYBDe
zJIJHGM#)_4(cYkFOFWuc2XZnG^=MbBbccB~v##UP9pTZ;dWxeh^=M|@#L<rOXlC8S
z(T?$GX0620@`}d#%^efO>es9jI9`k(LK=BFrsrk%(7Ji^l)c|2#mjqP=8%ro>(RcY
z>SmcoGxH>uZn;M@^CCw(&ZC*RkfZf`G&8Puv=cm<nTI&qNs3mQBV+y*V|6^@uCEv!
z9AB|^<7y0$WL(vTwb-p(J;i<uOo>-stY|r`-zFa9DSA71(%Fq!XWFr9Bo})N>Jukn
zu)AtxY-@QUCU-Z|Rt|IjM(r%Khj$g0pRwU=oWkw=V|VhbDUUn(>qkZ>M@i*4Z?2)4
z-FbXa9FskdG`A>bm0|`Qw??|{K_2^jauY_L>&NO<JS$l-&MIPr<TIaqj7TZN0@6;$
z5ET!f%acQHL*ZHsDWfth6rOdJ^RaMFU0D}U=1ek~dDfofiB|&mwuSV)@UEyiTMB#Z
zyjA#Ex%UoMkDr0LSIs_g6-7)Q9l@FtPb-h=J8a_jLHz2IHjTuS*!tf$h+@G3zNlRL
z8QMfWrZ&lLtiC8X4U@F;=K2XE7q3w9`>S|U1CIYO!G@8jlu<s9MLbqs!t#^C`~SFT
zWdxPiba@oqwk(g2@i$wMi}F1n#@}SgN|oygF@B4>aCyn;d|<E<STgfg0J3@k_v@7L
z5X8X6)x#453rcP&AxiRHCFWx8)j@bJGHy01MtVMpajV8+G8QuqwE`^QQ^H8?WFO3U
zsNlyh3BT6?W;bivfH~74ZqBp{_N2+2Nv503#ViP`h}3!0$&e-EEzX-bj*>O^Q$YLU
zK6o=4E`On|#$M`E5te5UoDcB1wv4s7CZo@9T?1ZT!k;d)Jy>h<u=6aPC-=B;p0yry
z_5nuEDf;c$|6Jrv-Iy=mq1p&OcgCkTA2ZLx?Zn(|B_78+X9L3{9F6;f@Iqg$t6J#I
zSNigmVrR8buIGF54V+Hj+k;&ZrE+{bL?(A^U}NTGr$bMv`!iTJH!ov3NIMfh?mOgn
zhj?+!C^Q=r(OCXVOr(utJ)J|DQ>t#9EYhCgXq5R(_{03%*ovb3{P<izbdmfdjxwL+
z<)>*Cm0z{R{J3Yz&rjl*U&G5!)3&Jm2AkwZ87#NV9q8YI`Vw3XA<Q};h)BBtKh7Pt
z!sV5qskwu^dpQhVrXPVT`7NEYe%^EIw>Ta{m@+Sf8|H^P7)O}br?4NF`{>U?SkDXg
z!IRaq5hwG4!QpKqSn(OC*6P)v<AR+XSZq00(I@Z_rdDr+bjmzW$y|(=pBEp2(|DME
zF%G?T2fo0IeI$DXSZqw>H9k?}MD{q^Hs)7WJd&U0VV<>=JROghE8id3Bd9BxQpN^`
zBQ|53?`Fj#`Dz~Kdwxp3!sBIZ&f*(YGBcYw`Zwk=q4MDTiuP#FU|ahn;^o3F9q!Nh
zKVgsLnKRoa*UrSA@)_zyh?6!!+e@0Y$!)=Q&=@`o@nU<4VTRMrAH4<76gXbMo*a4P
zGho*oN6mxPfyv<uhDR<k`}N7!){Jk<MP`2ud7xpsEUrmfQb4};W_&~S&E@L$QS-#d
z_08B1lr9rXmE7yY=R(|@NPGNT)ImD8?Ss>4{pR@^*C3C>T$FXb9!po3hV_F1E_R)6
z8pD>zO(UabgDgjoZv501G@-A&*pxM==_ieBEe{TJted3SO|X0}%aMJ+aR#Pird(4f
z*P4wh23D=xuyW(3flV7u$Nz?vC$8IY(!i#(acF@VVNAzi%P81+tb68eJLR_EGJ~D=
z{U2K7%8zqg1c!U$JRq(Q6I=FOpj_}Ghcz3Ho^!G8c*%1w%AbpIKyDwVx8n)QllO2;
zdW<J_XnC&Rb9*Rrlows;CzH9=UA&_->!b2;6u9|{4`lTBw{kA{E1|RWSM=-t>eUEK
zpG4ZL@MC}V-*9>1K6Ef%#vHGOU-v(+LpYHhYhJI9(wlcEuRSt_5BXf~_~gvI*C5P$
z@doF<5ia{c>cD)N*A?)Gy5gRRt_d2n7CoeIeY2DM7Ptw$y>Sfhd6Z9bJvyRA<)E&t
zBN><FQ5N#O9Y6ofJdy9yD1)^5uDtI;+9<DS^gv$3GcQv%G|DJl^v>O@Feca=w(U)j
zyGtmA-Q&5lZ-pEgTd?0^Uv?$pnw+5*!FSpwVC7r|Ir<#Ew;`<0(PKXP9KClS?4P5@
zIMGj^qxVk4Z^n^K)c4)ipEyU4@mc5S8QY-F(YqRHnw_I}jiJTQ(WCv~+2HR1O)jpZ
z@?2g2+X5|C9+yv>9SA-n`$1c3Y%kgw+p0Sg)S6>a7Iz3wX-Bs6)k}XyROzi1D}B`h
zJ~CIrN9wy8y?K0>vR1((t75q`?|nHmlbbW5a&LF7R<Gb8lzmop9rP0W^gj5d?NLe6
z-jAQZ{?B-^iS%om_(6olHjs8bezb`ng3BvGgXNF4JMe_*U<-$E78EbBaUX^p>h=-m
zeiSa-Jkwa)it}tjza8h_h%ocL0d6Q8rT#d=yoNCbAdWwPuwY&Gf`1HgGS1JeV6<O8
zt2)!@%vWh`JN$%_%Qj9N@Hy2dUH;So?~y)gIG8am@!8rsK44Vs!wU@EUA0QJtFKY2
z^z?OBO69J4u@IlBXL6_E^3$jr!R2S**SI9@v-tVAWW3;#evQk|BP`e>?Q{4MmtTO(
zD?v-aWtc7nmtTY&;_^$*{W4tQl4%5&EQj@5Tz&;%=6eg=P&P_^E5f`4mp38o<ML+2
z2`)1$xCt)5s^n^1-sbYB4%6Z?J7fJQDw8{jgIvd6=#zO*Wn9Uz(AS|~WLtB=?Fgr1
z7%v6DxK36l(yVK-gwHYe<$F4Nx~rYNl~T2@RzRRq&DRRGu9Ao1OzxQWX1(bf&`U7<
zP53p2N&6OlK86`D7^Yui_)dfcr=)!cKVta1aCs$Y3d6)A>y7x6x}=@@KH`$;a={Nm
znfAHs_Yfw&|HrvMgiD#!L-5TqYJA^?FlGN3Zm2J6<Zgs{z1Z2^ZzJsE`$vcqd}mgD
z3chKFSvH)<VvjIz?-tX}|3u{{xaaqne~Ngy<^_))c4mR)TDe%P=NrA1e513kQtmD^
z@JOan>FVn4>+9_4^01uAoy77zs2joZ&*9ftChZsa`B-MWV3~f6<zFEzxFhXe{D|dW
z!{wErDJ&;x$#KGckVCxw#<{<ROT02K!7Iz5@p?bPl>K|Sp-w3E9}wmx_V||w`*{5w
z;smdm)tiD>;_{D5uHcg6gq<#b>M&<|TxMq-v&dPfiQ_=*2KVByKh-w)PYBO`pG%{s
zyHu=KYPCvd0~@g#y`A{FeW}sKbH{qSN?q{*MJ9JlZ9C5W3-lBGJ_x_YFKK_p&&Mz0
z1;6xb{Qd)B!69jX$B+2^CtO|$S_*!{bSe8>9)cX=_g~KaH(cVEX#~G4hsJMPm(4eT
z8_Gtha|rX2eJ+1PIv>CPL7d<>vwj_Z)AnSwBQKFn49lLZIZg-a(b_(jY%MgDGr2uX
z%pR-w%xt|->8xS?Rp~60FlOlL>n`^c>$OU`)W~~S&E)p<;+oO!s4KzhT=+FsNt=hC
zk5$GCR_WJRU4XFQ(eN=nu(}W~uLLaxt6{nntnLXp#Ohwo-5V~k$~1yimP2E8Uxb<O
zK5#?XDD{2_^AfD?fw167=42g+6Rc*|?=)Clq-1NX?(cM<9<5<DTMLcVOl}Vo+U|Z3
z?Nr;{$3oZHW4TmrG%B4%41oK3E5&>T9z28U>*=Xg`U>?fZ+~GXx2HF;{CMamSUv!L
zjb+lFfS-?L#tW9|*H}IXVZkeDPsEQ{eiB?>30ex4!*nTFUJN<J^1;qs0+(238o@Hl
zp|SjAgqiQ5a6{QB^<fC}5-cBxu#e?K5GPp9tlw#{e7KUWv3!KnfqJxt<!mi9mNU6M
zOzZ+y^SwRALba>fS15ND@h$r*zFl8zR7=H1U#Z&L8y_Q-vba6Hh}EU2E5Yhh;MZ6s
z?I`?wtTJA(O25YHu?PzuNjnBVVl@w!SAv#;)i7NORy!ewSS>iW3ofzBG=f!@Lu0js
zF!SwZJbp$el)49gUV_!55%#fKL|ll~tooe>tG!CL#%iC_fqJxv)l4m7Sk2=0Fd_G6
z9M8)x!H;KCe~AwzaA}*&xs0~S%TbQm<Giz*-+b<@<O`j>g?y<}sdwQj=c|2KVapf2
zQ$aGhy)qH!$3Z{A`SI{;oRij%pO16K3(o1+I6o0#sVmY>z>hdT2`;Y$Ed}Rcx)hwR
zgdF00m2*#qOPn)};GE^qI6oC(=DQkhC>y1I8p6B;=PMBQaefNo1m~IcI}Og)DA^k4
zr#T&{M{79G)<WYvliS0@?6F$N_cRK%d;w;-GmqD4I!oPM-Td{`O4VAiGj5YJxjnsz
z)pe*V!RmVWHC9P`I(|M@8829+Ut@I>!h%QAHsVLDo(`8+f|i2SFkK2(&ww0a^-SlU
z1(#T58o?^dp|N@{!p!#^xS?#6`WXoG60B}O*vIPGh!d=4*6%b}eWsGFv3j1<fqJxt
z)od*^Rx`OhOlZ5y^-yhhp9NiKk7d}_-oAXHRw~tdYkhrKIjdk)+}Bg7RQkH|Wp8|u
z$?fS)ELWhPV7Usv#xiL&{Cq4kUa(BR#`0!_1+Szv@FSMDz~z;orC>QsmxAR%$RU=`
zckTsniDjk{EVCRM%fkpW->q;%*(mi0!n_2_b%cE^4<SyloLRrqV0l!@)>yvK=|DYN
z!*aG38q1m79wugw)pAe0w>ysq!&vUE_SQP<rFx@Y$K0(}>ns(j-WVa1+tZ6!9Y<XW
zRwv-sSS4)|KOd`%7p&5+v3fDWf=ALW!jD+p4wqMgmV(tVT?$q&fgED>+0K0qTw;}J
z1gk8E#_IDBX1<rg4P~R$QwZ}CtZqZt$LeztCs@s_-)XS=d?j0B^)jae^=J*N*;;6<
zW^#L&kiFy!pckK4>h;g7upaz&{1)I2ywK?_{0AX?1Ne`HEB9FQzu4pFSd#1Sx}Vnk
zFZK9|D?VS+wovo$aQxD5@cH3)4~_R5uK*AC1<Lo+Q03;`<cqnF$UJ+L^MGWJn+<dS
zCC?ydAG8?zg?P!HxDL0M$cEj!%%C%#{M^TgZGXY*UEYfkT4G|jC$D{f2`_{$s{(tr
z8u#Y~0ZxlPaZ7p391UsDguNUx<^=8~9MTNl+JiSDe)nJv7ST`Gjsw%onL=nIxi=wR
zE__>~I?8wZxw-Ik=kM<ib>yD%ZtUwzKf5SBE!*8&kjMNfmerP>y1x~1Qg-fhy%OPF
z{U-I~@HkHRuh$makH6aiXZok#SN7X&L41k7KCrbsjJI>P;sh>~)}FiaHtLM~P5Vc`
z*uQtcukFS=5f&_y@9p^UJ4o+>%PT>HB%!fxmSMlP*d)pp+j<TBl=mL|{O=&$g>MFh
zc>#C&n`rTL@%=RMbP-LygLEzOqTPJ2bFXvm`{1%1aoN$gj!28kj%c!9@B>cP^-dP^
z(Pg;#7}l1}=Tg*3M2qw^Z2@hIZ3E8E8_^cbo-@cyeg`Rm2D6{;YVeBvrj6zI-`|h8
zZR-2)AC$27O{5PYK6?Age*gW$h|BsW(nr99ooqG>?6s2bQh(IMlV<HY_o?}ST(+!*
zlF^vY66dr*)~?yMNt<{B^kUmIb_;uTZ$wz$OX7DO_^k%bXY3c=OZo)(UW@%qK`_PJ
zt1f)7aciZD7Z%-j9{tU2B}^I1U47+VJh1L96|42$e7RaJlqy}F#agxIJx9spMt{{)
z>MGYdxw2)S`F#pLX~Um}U)mWJCG9i#`C}NyTN{w;pnt~{!tTAN&mk;ro3xwo;~3`i
zaCs$Yxd_K>_pD>Kd$Eb!fAJ;6CDY}CFNZSi{);alOufJ8+?(N2CiM_o!ZKRF-CuMo
z!j%0LxS_tNk*^}m>$R>eeHLM9AM%Xl7R1T;CbRBMe-q#L#{Cy88=hBBj*Y>}4s696
zqJtH5MCM~o+<(Y+e4EOfZIf8yUW~6HUM`$*|EOY#?SlPRbjFaaU+K#&@Y{krpfh=S
zW*(9EQnVS`FP<++`-RFdef#Byx-j<N^B#U1>GXa34#I*7v56dO-0A9sGT-22v^g2y
z^JM%_6B*wRWw`ICK+nrDeiBUbnJ#h8a+q?#7W@d|+0Rw#-KCyVPrlq&FV~BGy?LB@
zT<XT7{l02vXHQS3w>2e`JEfi91^uL*-wnTR=cN4vKfj$bUfMbRJEo#`eh<P@|D^p4
zKeqFq!{wErsdk>ECC{+<1>~@9f9c$N;SvYTOWHEap)qkE!j%1MxS>uc^=}a7C3BUZ
zBJ8*2Um;G~a%TOyww(5C|F=rEo~!)M=|DYNo2z7Nq30@@+#V)okJU<dqte~i*;nk#
zm%6dv8vA3gn+lKk`|7>bzOKIbdS)iKrx(YS_oJ=^tABuBW0kZ&;^$+P@q$(QHCF$G
zuwag~2k;|S{|uK`f|i2SFkQ;L`Y(_}tUl=6zrrO}nMSb6a%imn17YU-cetT!l=`0t
z^AfD?MA*mb-w-EQ&8**Pu=<dat+Dzqrvvq94XfE&Xsl*(dzg@UGVde%X>EJ-JoZ0M
zZyA&Eds=+IN`LRjjLA@{wxaEKM!~{<hvVk-ZxmE<`q;oI=0O;xxhY^gs-JTs_BZ=s
z4oF#xAuE1PVVJ<2_x*bGOLKy)l}UWz5faVWg}XtYj$mvvUiRP2_vxq$FqPXK@p9#{
zudP*G<{%w)`6G0pZt^}Ks>AfB9q#=f>C@(epFj3#d6Qu-Sim^o*zms4`fo-VrJWtO
zDDr<79XR8eR|nEboyyt7a!#(CmCLch4^R(bABtJ{zDOtcdIEIH;4k9A*=^vFvF6v^
zx&mEVjK_dRUK_UK${*Tsca9v<l|IQ$n^SBX8LWlx9jn)l&Cb`wOOKM*keh|W*%pTQ
zN9n+k(@eulE6!Sf!oZpN{OZ;H=QN*@^WHq3^<nM}_L0CZcJm4FYkPAb!eZyhcL08z
zk3SJEuLKQ}gk~@RKCxw#%{-ZAG5nNwFn)SI&NRFaOhdjy9G}V8o14dFMDu}Ux`-xo
z^Cgf=+k2>UpX}Vj;HK%PzgO<-Bs7_uAK_#j30E*jY*Q}t4C@i)c?#lrNxA1wS-ztY
zAMr){vz@Shq@Cp4d-Ml^KRL5~BvEMR7*9gJ($C2J|8T_V`TtT0d-MOJ5bw|bk3n44
z{Qp?+==nd}D!+-GH}Ry|{-@RX|07vTO_vg8&{p?BxpbQ>Anap_bC@ny{?L{=d=Xo>
zECR-+B0QGBOFp`6{XJe-)?O{$;xCkgHtfcMv$l`=SO%EK)-BvA)0#HZM=eKL#J15d
zw(U6hbv+)Bu+$^@{tG|awtl$05;RB>8tdYz;Is0uUjlxyZ70G{c_-oL+cwrG(@^#*
z$7k~OY+GDL)c%v{BAVE?m5@t2bFy<!aqeokOdppWtt}>HM>Mf*Pjj-?z!lrZdSF`S
z8P+4pvlj8ZSXV4J@khS(@JD=+{<Ll66WjJhw}!F;aY@@YJ%YIYaRSo$w&_&FY1?#~
zggx7|4)MNidOG5=Y|{qtXxqegLff>_#FI8N+cbSCr?D;>?Idjb?mqFpu<i%<3xeNa
ze5KzBm$BXibpM1KJJIDcmNSut_m^SfUwALZc#r(dhc2H<oTGWCEX~TX7;xtm5Ju{9
zZx-W)Xndr6bGd>=UH8d0f7P>C?CI((_tf(BQmwbM+Ep)=%e{qKPq8!K+u7rP^C^=X
zvx$6PZ*RSpFR_em9p^!Ru_Xg6iyO<Z45U2^KRv%>oeE6~B=6(0&YnpbQ?^Z1;SXha
z@B3>RvQ9>MtXt9~jxrlc=H?b<&Vek^OJqtMWuC8OUeH7)`KZ6OyVk!0WfL1Q44T*o
z@@>VBbLkPdyb?6@ETWUxo>A};92dfs{Af$*=l!sLyM8!<FlCOz4fDg@n?#t`-EQ1e
zMp$eF*JpV)PX%!@PnNTJ%=tm?{Go@iwk&ixmq+NdJ2fS9acpq0c&R>$h@>NrJOWMJ
zo<&qo$yc8<#IuNkW0HAm9_GJg`ux?gL|Oxm=k^E&Q*@B?gpR}fk~-|3qJ!q44nx!H
zAnZJ%NGoB^Z5UHJWVTZ1#Qe6Y{5TG!E#VnO7a?A*Hk@5xPAGYlZHapaan@s}7^F~v
z1km)e!c(T34w^C3cGQz?yKNoxi=BHm{JLE|2VrTe<hukvj+vedmsf%YNkU^geGV20
ztUR1|i!@?Gr{Jf&=i}#(nP}sfhO%Ga_)Naum?<tJvLDHG5lzNSmq9LV%L|?RBImvs
zF4M<lN8_TT?1(0I>!nWC%ixMVWIZq~^9<_|<#{=Hc#-xD_#;}RGsj7+6B#Fc%8ipQ
z1%Gm!l#Uj*ndgCDY@f{CUV=D1KH4E+Z+!F$#QWo;S0XNJeDo^t=<yNT0>?+MHu0p*
zY<!enx@pEmXHDN0!to03#bK~@GM?dcTHZ6EbL{h4=q&xE-mk*@ro+5f4D;S<dCzw8
zK5gi^;Eka3zLS62aTuN>u|JLS&INBqc=l`a#Y&;CP{kP>wa(s7yzSgsDt7l2@Y&3A
z1B0h>CB8PF$sHRx+2_S?g??gFu7qFOJ@HT4Rru+#6Kw_KWjsOuj;W~qyaQorKcu}K
zKaMBf371!brp6OVTJky4yC8?Uz1z80!xf#xez6?ZZ^s<hB23xufg9?CQok2rUa~g-
zHiV_!$ur?=5GP}b%=$(D*6iH=>y&K0Hvc}S1NCTaZ9ZEIy*8i8?O|f}SglsdmA-nl
z1Y}n7ojB68&{eH=_TW&{0v?7|@^P$Ya(jAloc{sTm0<OH_%&8Z`yhTkRv9l?rC($9
zBM1xTNc%8;#Og=k@=DNBuo|XId5-ik$RSp5aPEz8iB+Z%tg;*$tDi)e`F;X!C>y2z
z6vDg&s~<wx$LhxsCs@s_-)XS=X(d}@^)pTf>d_ijv$fDz&E)nlaXy}@1i@7Lc&)x=
zU^BmsUbkPrSl+ZlI$h4a8uya)ug6*-dnG;(vUvr$^Dz&Xi{n<amgyzj)x3z2n^4!p
ztvo*=Ryk)9`^vtEJfFvpdr-dsmlww%Yu$4z1kJOe3*lLUALfn-%k!YNpcgVkKDxZ%
zQj{(J45vM~1#*RF0z9J-GJ#*z-?j(0f`>YPmF`s3my-WB#6`Th;A@&!m5;pU`<9;U
zI~@Nv=z6lhi8w9$TbdWL<yjTS2z++PGoke_O1pb-C(`=-e8#4Kn*VzyZ@ZU_@^9C=
zVE@SX5l*+I)sd}RaV$Ny_Y92HM@P79GBT1l7`oQzgWarkb>r=fdcKSkd+?#2YPqW$
z+ue)#n)g&blN&7uuk6<v#qLhttG13GLO-#kKZ0Lu=>+ZrX+Or#x2231TT1^9+z%Ny
z{{&&Nm!#c|A8qMR;qpq*lr1H8SbwyGG7kGW!dK+e(&d6*gfi_uv7aGKJA03Fe+ic|
zsRw1!&oWxS9TWT-Ve0fNxS_tNk^2zlb(tHx--WPmXYWOv*xAgQcXpQL!RWAlk-6J^
zM%-q~hv&w425k3O{zl~`c9;9YerwV)J%+1zX8dU5hu_(4W_J~&apZZezMOlMP1hgV
zS)Zl<Bv@G9qu-;P^QQuQd$WCCu4mA8ux$)*F~`(ndvL$0i_x+AHv62N;W?<+i`_Q^
zCrurV)f?3jeqh)<i>I80MpCeoy6+Zr<o;mfutxcu-r8|ru~u~#%+d~g2XaF@0Xwi0
z;a#x<m3*zYtE*PR`2;xruv)G56iS8OVyzpW?kW{)-Wyt(+zC7IC+H`3;Lq@DJ3!iB
z@bm2e<HZipzheqvw_o&c2uoWh?XURJ4*VT1uLRAr1K$B3+o{y)LkMd-5X#Kuf`5fF
ztsVFW!n6bbbnd_55?4%P+kUQtWwd^42im%=P66CdHfkh?FfXwK4<em!2mXUNu>+Yk
z@9Y4}lVu0mk+<Zf?Z6zT6D7222eS3jBd|>F7=F%}i5+koD>6*Mz?se#?2fX|pNeb&
z`+DCN%r*59*#d^MYystnEuj9i1@lzBHnjya&_8Pbc3i<RnT)}(naGU6Cd^ITJ+R}5
z_WiqIJC-00%>i`x?hMuw*sn(Na=~8EHQk=LHB^3OqUkr^iru|^<#HWc`%0bNjlM<=
zle1!@rw_-b^>!8N-oDgK?id>EdO`>E6MM1`{9;eoE=k)LKi{4(UhE0|J8<8{p6rjX
z*bLGZ;YWM&7`VI=G-XecwB&liV<CsSJ<hq0hfABmyu@a(9NK0ah%jY80dA-hO8rEH
zdC44YKZK<n%X-2Ah!dNUS-;L^r0q*RNXZr(!E@7|<aD4Ot<BN0wa^wKliS0@?6F$t
ztJE5$LQkm=L*7!kr_tHf-P>8{!;yb@*}l6LUr)&7_VnTy_+ZqPV08)n8mpuof}f97
z#tT;I*H}FaVZj_}PsWc}Jsd8t1T6)tVY-y{gd-q_SUu9YOW_i$Oe0ujIW$&}Mws~?
z1viw9QXhjbFTv`e2>V!l3gQH-ne{sjR*zM(HCFRZ2kOxpR<pIxSk2`2Frn=($1&RO
z7NG0wv5fOo3q6HKwa{J4*XzAKwQ9YJhvKDjy;1Bdbk^fo&gAy=CYFoPPq5q#zs53Y
zCH#CWGhVPvzs7PO!h%=QdhsKcm%-(gprv3rOqYV?r$P>~yxh6}1(#T68o@Hlp|RYL
zF!MbgZYUe2UV$(#!Ez76K9-L|oM1V#ey73m2}-uc@`+9d>d_jOv$fDz&gAwmF?+1S
z!Zvzq-M!t_N;f_c+*z*`3XPshSEUP|OfGkM&m1zjJ-vw4m8dJh>MHm(R!KV<KOd`%
z7p&5+v3e@Pf=AL;<43GM4KA+)Ed{G#x)iLgfgED>H0Q2`ORO@DV3p<2SbaLe%y&K9
zP&P`v0byQ()l(4mvAPa%g4N9Wod&BLm28dGO-={u(Hd5>wa{42<W68B*Rce;@Se(A
z<EdDu>OD3H&Va70N7A3f=W)E|wFhUqGSEh^z}T73@%BE%-j_)PEk1IFrsY!RIY@i1
zlgn|qmir7RSH_>@Xa1BK@wEl#d3+zkw_noup5^$cr+G)t>3IOg_`5;o@zmY@xYo!k
z?016Qf-2JMIyu>^lVen!)Kl^*KrdpIdFy(h9M;1Y{HQnULCYF+vZNl!FXfB)+JXx_
zzQYes=iBP|q%0gOaqUgU_sm~^&u_%zXMe;wy0mql|3b&lvT{vm=@iz-@eDg?@_Zoq
zoeZwzr>_7_``Hl!U!EX%Li?v(^2+)Wk9|LX0_76BN593jUAx$ZFz*R%6KRw9(e7OY
zmltg<<Hgo)hoAK#_w*8k6X{|9o*kxlYjRjimo(2!OM^Twb!p_A6&E8+y`JOT=fUN@
zp+3}s`92^1P;ayg(K|sy2}CE^yK$M5`vSO$GI;y+h=(YjXun1>T~rS0%KDPNDUY&H
z#!K<jdoU?O<oh(i;(S-$mm_UUdLS>^V`p^4Gm$7=^j)6o-FJDWAlI&7dH`HL-MZ$q
zs5bk(UI@9;H?jZV-jo+1uIYDrX4!-&_r;K_zuWT?g!OlOn6LhB&&v?@zuUt&(N}-B
zX9wctyFIV4{=|2C7@zgs9^Plv^r(A}yX}=o)9kxFuQIgwcYA1$_}!jYgC-aIUsl`0
zcIO^pd&D(1w%;%Ax^0yewP}GkyW$LB8L>6{`dXAn>?{2{P&To3uSZyH1Zl6skM{Kq
zaCy<bGG6TK8{uc&NcuM+oJbG*dPSHX=S9PB^S3trEoo_x=UZJGv9FgSO#Av~=Uxey
z_J;aU2j=@W_(Q#6Uq$Z(4J8nr#J;}W$$bahL>WB$N=!ugc(w~VMzp9L)Rpz6?JN1N
z!Oyp^BHyP`25IwMdEX0vl-D$RKque6M(HB^dZV+iS3&NKT4_tjw%<Z~CuEDw5*zz2
z#Ldjcwv?f<-|vQOZD+4WSle0Vt?lf45ccgX<3wj|XRk%P*xBo>KVfGXpJiuxPqm$W
zAHvP-?E4KZZf9wmXlFlQ<WQEK=gh#)wp5{yq;29HV4V89`2xeQabY{AZ!^zJ#rAv{
zG;K#dg0QsP@kP;Dz8|FwT(n)ZJ(B(gFa3>8(tq5gm$fp^%i?=Ra=|CT6U||;E{<<Y
zGrR=j7+!39>Ccdxd~v*PPE#4%ZqDnHfc?~XX9LH!*Q@>9qq8)yXNFNHAatB>SF^9)
z6XS~s#LNkhc6h`@GyfbOx7_5)!xZzHeeqnf%*da0`dP?ho${H_=i#R=Tg*2{<@__d
z@5Y@0MiZ{CMq_Ale2f47OkcSR-?piBR~jXJZ49e2eHDDHsZq-3yYjs_7(Bjun8}UV
zH=Z4r3k|*xL7l(kbf!K1GW=qbS!bl(jGw<A!+49goJp_y&09ee?2+#)OpiY7t8jTG
zXt)t#kEz3I%xQH$`t>w<=tpl4<=N-Iw;{|5{hD*{fJ=GQ!OFAc)3Uz>8uj@m+)!8C
z!EYnXOV(*_L0D{_Jj?k8;$)pBv)0`@4a<U^ToYsU@>V$y=sQX_`v78t&vNcGyyPc#
z|M#&WZCvjQBPRHi@_W!NY~!#|cPv8RYsZ8hrrmxOgX{r(zS~DPK6=wx?k#qg8~9#$
zccrJ=g){H__(hzqQfH~|t&L}L$Ixw`N&W!3ik<r*{DN;PO4^U`^YP7i!8iRH-*+P{
z7$)s5{D|+Lz~z;odHB8xbwv!yTF6;=Z|NSSrJGFK9{fC%YjOTlgsJ<_ocjy7#5r{l
zoU@!7=f6UjvhRf(>Wo_XHNw2!3ERne*pCtRasErh3C=U?-{G8P39wg*n{c?-iRA-^
zY2L8PQm&Z~a^n;@wu5n%W*%+y$e8)Y>U~NVwhQ8G9@@ok5HHt4*$?$7;frm6YXj`3
z7vj7^X*18qUP{`*sEy=;-y_U#v|~-mYa{yEy{(g`kMK+QKvbd7g@>Z0o@%KJuLe|b
z#uSe4>1os&y*=IW&LERJ)?D28QU3rvrM>(Se%)S3+limwUKlU!g?`;${*18TnzTRR
z$M*6UxV#cH)n1acw%}DbyU(Vx?cqVlVTJzHxqpMp_Q1TPJ+K_QJ^T}4%Kiu3P$!i7
zA%uB}-G2aKzdigNanc?#E7)P1c<}B1zm#m^o7kY;|F_eDDdOw%k1jTL9lNzczJ@cK
z@%Bn@cd0YqU9Xg}>AO}e7Vv4Q9&b}CJ~K5vcN%sByb~<gZR7jFSi2Mqk(R^H$1dXq
zyYy@9?uM{VKZogo-QD5xO3+fUOPMAe#w<Q|=YmG;&U5Y_aEV=}5$v)Y8oLV-X1)vH
zhO$xWJsHL&*lkDH$L@T@h1kui;AybCmy)fqySLMUddv*FnaXgw)w1e7HbOg$vCEB1
zS;uz0g=0<9j6sGC-xvCe4d=ca_Vp1x7c2sO_Rm(Ug+`-_PflSIXSrOe)C--p?nXXe
zD0TMs)O(8FZq7{ZSRw6L=P}Sv@c&r&HU3F^9DY9j887&!U*rD?2n)tZI{-i8|3J9B
z60{Wjhv|U-=c7(-I%~V12sy0#gPi*$xWqrx2>w|PjsGPGGv9;ZhO$xWLlEXA_<uaY
zKK>UYPC%4dzYhOt`>zgFvWb6Ug0}m~P6z4{$A5X)zKP<Gf3vmFz|Z9NFfn_q7OK_m
zu10sMx7uAURPbfW&b~r}Uxg@k!(i9T@qtDrx2G59orj~Y1gl5Dudzznk@)#oWxQaO
zevQ?m5EeX=_7wbx)uZ9^O3+fU8m3FZ>M@W*tRCxJd;UbultZw}a%ik}A<TRWa6{QB
zbrE4+g4Lx6`&jKnoM1Jxey71|x00=~T5>v2kJhl7t%b&FCbx$PnGdng<$PSmjhu7p
zXT!ZtZ{g>C=e$PSDt(UNGRJ>Q>ezdi=cmh-9dV>-)Wv1X<aTx8U7dWrR_y94c6MXi
zVx_y%*^PsqyE}Vu>T}hb)Mj$WDhlTUv~?^;nWXLf7yP>Ikaiq?e%oQZv>p0&+gX9I
zv=7qy@nhRL0WPluO|>04pOI@DX>-|7UT#jXGL&cS|A`2*O`YW2Rd8wlnMT?a%ctAa
zYJ{oJDR4vCsEtz*<|XH)ACIu#rcP#>q4L&Btvrxf?XFGvYc`zEvYh-bv7X<~Yhix7
zP|a_jru1XGBtG{*AF{@kgJtR1_4)1pIzDCm#Ie<r_qXFGJ4en1Yf(0#b52Cu>G9Qi
zgm-zKQRppUaMgu_mdllDFIJcG_?8iNy7v~Vy<K>r#_PJWxMQu)&5<`iPicP};n(et
zv`zT=?T_)&{^-~3?@WZHjgfW+er$hd!R3{psrHwoCFdDuLk`>7InF&7F54ONl6J;&
z=yrA<!j%0?xS>uc^#H=Wr0+T%VZWU{198&MvTuidZ$52~{46C~&ojzS2kH^;yE5j;
z*~-Mau$f|G*RfkE6stYOT2E)buUN(x<?=ZHp-?XtJ4-!?^tWGTai?Loin<f**5KFJ
zC9RI1k6p$KcInsH-GZ=SkhIPC5xawMc_nBm*bURA%#qKB9AftZ=MKRoc9}-7%W`P!
zjv&l@hv9~@QR-2Ic?otK2>aOGintKFSrzR1h&1e8sAOyGjyWBu$IP&ssZ0#JS=>H0
zWIRP%#J*MES3RDZaQf43PqGlGSAH)?(!cW1AmDEaD4}h~9lQwXbQ-RNN?))Fe(r+|
z>3DbY62oubg_;MNPk)Y~x9>j+67yPY-koa4v)_1_<3~;BQk)JWT`Y{Fk7Hq$QS%?7
z!dy4!^TkU|oovMh|G|O5Ui;qZ^K={r^W>Y-aa{!y_k0~!Dw?><RNSPK_W~W~<h@YG
zIe9PAagc|zl(23d9QI<wFUFH}qa~kZZgT$q{$RRy`NjvgV(L0nFAq<S+CvqV+h>m9
z{>CIn|DpLj#F{g#UW$CRjbZp@`1$)h+VOliqDA{KPCy;=*~AW{ar+{Y8B!(teT}x4
zgKuCUz9)d?%LTdID?pPgJilQV%E!75f+@lSS9;xYy#6ZWD>nDl@UuQ<Sm*WxmFeqz
zML#N?w(&JC53#)rzZSo=I*(|{I)5F~G_P~0<m&wO;A>XrZvaiMY3h7N<$KEkwhq(x
z5!l^21|*|pybn1sRvw%fPerYw3ugBP-g3a(;=mBc2QR7PJ>a<*_0P-E7F=P<%H1R>
zIbaSrIXqn6TCW{lAD-NLbST0MI?pUNqxQ=tVqd1y3iZr;NgTaN>Qn8*lJ!hti+r?s
z5g+zlxirHlTL%zJIkxEb-Fn8o8F9_jv-f#H@D}j!n7&KuV<R|4zj^`szkP60*p-OK
zOnP(@-?}j$yxCeFCyn=K4&Jf73Us+*7_dsr=>ABb!S4X@$37!Z;pj8oj(jrPmB1l7
zz&&|Nfw>Kqk#}Gv+EoK(L0ivBIjpO&Rv$7SR}0~mDL<Y-@;S!guPqR|f#6PyNf$Rh
zFj^n8ci_#yX3k;r-6((S8u?(=`K97D#t?_Bkm7ZAD#{WpYIj()=Tt66#f992AFxgQ
zT@Bsi_!BOc|2R|s?ZDDC&9EfwE#KdG0;zw&7u%AwC$^V&O1{9^wa$N-E8n|J*tUiD
z!q2u)9;*-3FPtn7jR!kz{}be{6B($3SUYH0=Xm|j$o{2SSk?Yee$#)5{p)CA|2}{+
zD2yoy%k#(ikTO(z|1jd1o&7UfS^M`!*!}lQ9j4en_6uVFBEGiZLoSWjKgzL+NA~Y}
z@Wk<_lsEm{g5ZPTNwa?+M*MX4?;|dM+KkwJkJp~rVKz-qU~1x=EIZ_|l+Uz3A(mG3
z)4-vO)1IltaZ<d=EYHp(p1@$t<u#q1>ktc}?A%q#&fSRmR2YnBlF-TrrLZ@}WsD)i
z&V_X+w$9>idRzB#=pV;gEX#oRfwt}w&2S^^E#K>S0(~FE-m&dS`(gX|nB)z6_bKNW
zdv}8gTYL9u_<egvjH08=eMV&XxNlkSBt~1se`kdM@hv!L%k*gR@pC9VfAZ|`-$EXV
zikG|u|2e@r#*-LontnbD|DQ*_HphQLt4Fi}NO=VRcHC+4&$)D10jjV60`zYM|6go|
zpHQe9I%ePNcnUNC(ObsVH%VS8{rl$(&Eoyb@HfNz%_5@--V=8wY4H=7Y!&ay7H8sp
zMLz+*OZL859*KIEyr#oD_Wjwxa}#_2Rn%*9yeCTjh~iz!BY4;Lz8T(cgZ{1H{cFwe
z6R%a>!_D|U5bw0_Uy;00?E9^TX7PSI{LS!whsbDx_r#r<2Jcd@OWgb?2r78Kh7&x2
zQ_g+xm4IQ1Im3(vf*j|$--HfL-W<TgfZ?I~u-R?OoX;%k81o82sk5)AtCBBR`yZ`W
z=7QVJH$vUsAnqILiq<%<#U8}3gDz{5T%YDD^_|c~)<Ma`@89}7-vdun#-aM=a&<e$
zUbc+*GV*W@2bTsrPf%t2KGL{dqGPO-!QsuSP-zrfo@21jX+Bi=-sA1ros;nM3{SeO
zJN~$y`2)z8_c$1b)s^6fh~rw)9Z1XdDxS+n9fP33BgW0V&FYNr-Z5so?YnZpg_DC=
zBN#3Z2c)+L{9bt(U&q@V#?8Sg<#-RNKDKpm7@sB&N+|1Y7%xz-yP~o-MzQc%9v`>&
z&J|N4Q9^T;*4^Oe{@XjLXRzD8EKd=b5&wc><ZnBk-{P}twm)UMfL}$Q7#trjn|0Tp
z*|_?}qa(xkg0G3Y$HuV`SO?;`Y+ml?CXVTmwcMG;&`5cLrR0HyvI<ZenXC-eF)v~h
zGD64gfrfzN>0X=}X_`+Vq>1WZYwsy_z)ES(<}UwIIsZF4a82`<r~_Hkycd2xe~H#&
z<bJeu@cxib&OEpeVeWw!9MaEp26yvz3w{IoUU+|oXSFUt@vy{W-lzE;;u-EonE4a4
zlq(qjF~XF|1SKx=!=+5hr~iJ?eT@GBal|<FC&slbks&V6cWf$a-u&PJ$S65%nX(w%
z+h+j`&%v8_)lrKn>Nzh6p@(;u?Drx63>k7Q47fqQF*IRprt|mr2ONXjcF3Uuo0V;M
zZNcz}L7j<uVCPz8KOTf!hmb900MI2Is10t$%4n>4rO=Tn?9*YeC75yttY@hcaalKs
z`kgl~_#1d-enDRH@m`zz1e^K~(0MQU%!c<;_L4A<^@w~3F6D-}LM{FaVb)j5T3l*<
z@&5h?X?TC73|eowr$LXszcGxU3~h*)vw?NGbpG9gcJNCdpvw`Jp*`3QJW^JXsq4q|
zC-~O<T=0eZPjPL-o*Tk5n5F$(h`NjEjB`WgBV9Azh3+0$jP4dJRJ!<b!*+>!-wS+F
zF6PaA<FYVg1&`cs;fZAAf_*{f{v3HH4=r>n&O)vdUlKQmap)Ix+&so@8JQddMucyn
z;j5LmtGEsmHxf&`h;iHNWu5kMjJqhF_CUiIk6X;R!SUKS&XQdM%<TaPFG3mQIuvx%
zJSVoIkwp0AS=Kz4hW%Om-pmOegY<ImHDA0g=LC-fpVYVJi|VsII6(6tFa53-$D$mQ
z90(q{C%k9mp$tpU1qT_rgxdnXUn=?XTuScakusPxIDhA0l`nbt{5!^jd=F7P#G2O4
zVy``TveHd>qVnZ}!<7u$4xNw4IMT?N*KxJmTg-O}Z?X2lG$Yo6y_^N)0^aD@NVPsb
zK2XQD+|iMt!RmI|n46@K8LRCRgLPvmPoI{f|M<@1kDoT9{{FL9a44D-)8BvAIsMP-
z&R2T-ipAalc%p6mSf})}cF+3JC@;tGEbme9n+xNgW1OF~eGwVbU|Da33|^O@?U}W9
zq_xGigAv9tpYrG^52PM)bz+HVn|#J|EaWHXcnV}{&vF{Ryyi1?Z8*$5!Ly+DPSF|q
za4j_a_EWM#{!iYMOT+%RQr|o{JTS4vywS!HuvEt6@CCyo7Y$3l+>~z^141)K&IL_*
z@Ssh7(Fgb9RP^frwwe2Mp)Q-Hw7q&Ws_oO+){5?au-)8~)oz-JlRMRn?zf>9`23dC
zEQz$I=Ja^0V*6m3OM*l9?jGBRw4IO!gx=(}9j4WwXWRKqM%(E@npWCQujW&2hxdhT
zr%!bD+fK8>|37qJqIOlQZ>tZ{<eG1^k8Q=Q3ZG1Hb?&vTX?a!qnwD>J5Vm%MYFAH1
zJx`aywyo(nqV~1i-7~hY2eaDObRy+mPRHZ7vle;%wl-ZdX>Zf>B-<S8;W)u>N}CI5
zXmhuCZH{UEHuvR>Hg`PIw9@AKHJ@s8yjN^<D@13%%}rMU{}10Q_6e7AZ3`DM`@<~E
zUWB!r5&YRDDH%IR4Wv_joMv+Q2u)8Q*lb3PqtZT8W?4^?dz^yHkOo}d;o*{LeO!J$
z1D7i`-Xw9#IBJ#VQ@G^)ATCc9opGOH<EZq)|37g*Fy7s_4dvljlsL3w`nF&-$|^MW
zwb8f*=e#N!Z31c5=C%c=DH`ufgzdIq9cT>Oc?8b<z?gW4eMcxq>_?Y<^5CD*HZ(H4
zdDe%Qo!Z*@WE-eI)-AXOK)>F1y$NBCS2)QbZ6ki%cYQisUYt8HUe@T&gkSHGJ`3SQ
zdhEYGJ4$cv#jo=ze8}fq$0ui!oq;fQImfxrfGc`4U*>fl;zC`~)<o9?4O)vHawge;
zllv^V3BA=`5YqO={5#4gI$tK4E-D9gWgW4;$%kSa8Fj?@`zA%cPooUd=DYH4LE4t|
zKwh-9yo`=9{iA)Em%1~_o(Z|LMCH!C@npV?^s?`rd(*kUwt~1O=Z<AUo$0Gcug?~%
zA*|09qkMg~SOa1IY%#`(UixgY&4`ByH0Od0T7TkfF~(<|EyjC;nhVcxJRfPAoh^2O
zp~d$R(?0NQu_4gp;vW9Av&Awi4Nm}?o*mnQeQ@XPv}CI$hxz!TUR!LQ7S7sgot$O0
zi2q^Kjo2*uwapquSlS?IBlyu~T?m&KZ5HFjW{tzIZPo<BiS)2plVN&%4}o&fhNZu_
zC@l^0yx64?`!$9z?bkNvZig%75&QLQ#D#jpeu>`HDMmvHL?^Ld&v9~}3pY^)&wd>Y
zoJRS0wgEauw5S}^mG!0V7x^y3&$nM9KaF<xW3>Ef@`fJ1&C+^x?*j&0mphwv3G_&B
zDKkJP)<0;!E`=<y6Jo!fhqxy8YX%uuTQ~(-+Lk>ZVQtHpm$qduK-jlsj1wKTEqfv2
z#g@Iu`V+Q{@maQv_fXri7b8tGTlNw|i`z2V58ASqf+klpTQ-9VoX)DXWIq;TEm^nU
z9neqO%lM+`EW?*Oy``P=9icS7S9*N69BRjXZ0oc%uLgZ4wsfdEGQ4fpCiHZZyw&q*
zUjyC5meQ|n>FW@d@{;yi{Af#G50@8hDdWYKUJk#urEf$yksh}6O=0?6$IYlKeJ|de
zmIisg#ibEj`UZqqzgIZ-t#E0dsE^pvtKbjyhAkDnsZ)%G5{OP>OW)??z8!9&44y6J
z{f_eSY!-BkXi+(+E9*<!Qu1AmpKnV=zE7hJ(&kTD9j`^&D6eVsfKI+$jnYM9!ONUo
zy%KWM?P@ksX-nUM^kS#PmcA2lO>AklQ1iT?J$M&nXdC)&gtZN29@>UpgRpNy87I1F
z8~Pr^iw%9R^(Sm7<Fjli?~k^j*C9<a8~Q#&OShr#2TiVKHZ;59rZb&0u^Vls-AcQ^
z9=ho^{6U1J&1if2Ay)?C_M2h5&vksoVOZ?!N5RK=v)Ip%Q9jZbz86~Bw^*-e)4zaw
z-3;c`7RN)?fr-Jb^?_P>qC9&;o0OGpby<#2uskS-__fXb6lhX+<ohIkw7H*#%ZoOb
z@lyAng<sp;n-ET<ht2(5l-|s_Z%pGuK3{NrVrM^tFz>_Xo%=<&qPN)DFC#A0757AR
zr5-UFv=%+Y&fe_g-U2tFw`XUGizpw@hC#=O7L|j#vW~Q!CEwTZ^X;t2_i2<tn%LPp
z;E(c}Mi1!Z+u0~xWM{8(cJ@n<n{H>5NShY5ZVdYs$P?QpcK24qHL<%h%*2jkzY2NU
z2H%FTw!zF#+u*Mw?Au_*iJsa9-;Q{(!QZg{gbikVmJQ~;(>C~<2sg9A-!ing4W@nJ
zIQH8{4rST*>eJ@rGpxjE4RTUeYxd<<*hFm;?u6c<Jw^NcF2cn0S3SP}@%X;)_-^y~
ze(3T2$nky6<Gah_yW8=7-Q)YI$M-YGce}^;bC2&ACT!o|r#<^F_*qV_tMOgUd!3vk
zFm7l2mpv-KMm+cHMRk%3?sL3+-;?cJ`l62@UhI<Y%YH{0xG3YXNW+V5o%;&s!d=3M
zcDt`|E#|2VPnmPNBl;YCzM1@7Pau7F>^qcwG4kCeezS>rm^EbVi}@4s)q8um|A*gR
zq8svIFV$ZZpOz)%w({l#e+6HZE*BKs-W|%r7621of;IEG2yy=q_2j-Irsw>SE`O1X
zxxqgn^NeZwWE`A6TCZWhAzz&yofum#r{VLVXSiVHbM^D18wR)kf_yjL=%8Qv!vDap
zaUWoZi`+Z%{Tsgp=nLBr&+9z<+$m>6@^4$6pZmZ>d2>w9=sh2=G~|qQZAV_x_pl#j
zcn*H-)1R8Rc^((o^9OcAd@H$ge;W5|iA`fUc=o{VNH3R+5g(p%v~^H#ThI3S$vlJ;
zb&E3X;dGGxJ%=#MJs&P@4(|i+5z{V2TzFp~UG7Ult{MkW2Jf@fDeHkU_J%CKKWFte
zqwy?=FmKpISxe&HLC#qgKwkR2h)}>a={><GeV6pHdm+yCv3~VOiQOEg1H975?W1H#
zKghGdO#4-9%KL&Zc@_fCu5RS^15K`G7>Ja}Zf|01*zRd(q}@w<p9@>FKk{UlbxNCY
zHSC?xY1Lki{VNPp2I-eR#qpbPTd*I_IuqNx2zl(qANc8#{|QdM4O=@a_L=hl@^U{K
z5qgm5qQYWRr;yJibbOA<PoB$RuOZT`oyHd6lh@^;I`>DLz4v8ow>MidUH_b<!cNhy
zUkDvoX23W6c7$!W<Cm<(2@bOV^ibrFv);C>s8q)4+XC#Xw(mAR8S!#queNyxFdJPs
zXE+41#7-U#Kl?bTmm?77eSML;PxQ0Z9!Wm;ytL~WThB5ldkScB&xi}5+qAjhXhmn4
zSr@!dw*0x^SVNb4&}MoIU1xuEd-A0Yaeu?UQE(W~vpwLBM#^CMSnms6|104|?mHQI
z7SAi+ZTg&E)Ks6+pZN)0%J)>Kzs0oGU+R-_<cp_i503Nn1B>bZWxTM+gy)$x9niw@
z#3=lfnFHOOF$u4}P8+O_jf{^pCYCKbbHf_^jbUF(eQbQ$vQzM~&rp5S@=Ol%n&Yx%
zE4SgTluagJPq91xP$#1QbVciTk%qBfvg=3Y{b5cxDyA91p4)R0>O=Z*`URh>;Me{5
z$p}lIK)#juu^&GLE-&^8jNdU8;q_F66KT*tJ<X*_qvc??c*)#%HF$~lHO@T^uH;4i
zC}SPsLY>f$X!$W3N+<eC-?-k%eLCEPKB~`4(%OPZS3I9b`-*gk=A6`(bt!$N@STCU
zw7!xu(r6RFf13PDQ*CB=|C?bki8NzPXN)fFrAT{6qt*ORS+Vw{H7nOn4h>nj8zub6
z)^LvJ+q_4#E9asP%>^v@_b8%8_lWO`aepW8%_jH$GWSA119DCr8X2#fXXguoXCi!Z
zePZ?SHoWInJEJ@_SvTe9JN)NKp2!$GQnGA;tAD?!yH<YKU2_hLE#m__i4E+t$vtaU
zx+yHo5*u<q(r}w-PpCJ4ohC{bjSa8CI?Wz1(&wNv+8blPwJ6&z*;lttvjKAaG2}+X
zUAjxc?fT3n$XPLgnbwxT?7=u4;gjl7_)LU>E3@x`c}AFP56(h(^*FFLSTppqE$@n2
zZ47TVtZQ)m!Z9%8H{ku@@_2p4a1GKT4s-6#IiR~X2L6463c|cr599qzytgTN?ul_X
z+rgY*i|Mrn?7oq<D)^hN*VGIxzFxyVa=)OItGj&8#{HU?-7fym^^uj-Idt>(y|KQv
zJc@%T%;@xtFx0#k#{IivhIz~slA#t&#uOgCHGA8<MCLreEx7M8uApDW73agR#}yYK
zEVh7rI9Jh(D~90mV*kl_J+2r=IFSb9iV>G4jTZF-_Dt%n;N`et)VUYJmAqtJF^;%U
zC-fy+evF3FiM}$fm~e7&u47WylyQa5C(_l9D<WECBdIIvQjaUhcL{!J<BDc9jw{mS
zzj&AWbq`Ud|M22kLs?jNm!e$eQhoYCUVq0v`+49yeHb&e3j%y&&CcPbBrOEA-Zy*t
z?qV4@E=jBB1XjW4_k&Tos2}8ap>;nvhBEH5U2uKjHpue(!ix|$<G#?V!sFZ?#ET(I
z_lMgN*8SnL5tjat`AXl!e(pI4>;CY$mN)9{Tz|;;>H0(BN%x1BA<V1Q{_q9hZ`L2a
z(9q)jA#FVS!xy=H9`61yQPp-?$w8w3bdTOz>zl^LKRClai}!bM2$SKB+lQ-b&^*r^
zoY=B)qC7D<-ulGYD}+prQ$)_Tz)sEP1*hG83GQKNcYzs(Uy9#?`MKafk25erU(#my
zq~F^Cy6*R0j<B@-Fg@neuRuI6$w&8luS!dUe(%*T4d={Ulz17!?Au=H-2a9v@}zHj
zE#ks_VHG9cgifljq70Tp%1)a`8E?SP?{m0T(u~IOWtcbYxvcwcaL-_019>U;wB@m3
z0w&HTybf}GyY_m-UHY(QX2;`{EBz4d*5wGV9w+c|)Q!{UjfjJtv#kKOkz;Sx8^0mP
zhQYCSG#(#E!x_LF0DGt?%Z=Mr9&K+zyuT*RcDgV)EO!NHa!of5|Nm1v-HbBZF=(!X
ze%+Sdim+gvw71~L=RsG(<&{R0ahZ(qt^zOH+1uc<ZBUN1uXn&7$_2)?+?P0-$!L$r
zW-w2o8GZI>3%0rSFy_hg`rn1L%=6uF6FMT^A3KCP_%wtgT6~>^W5S5$$<*nTZ7{l^
zU5DvZyT0Fz(>RXd`|ez8c?tZ|?ARXoyyxwV3+GR^9laBAy3LaBYQ(W6*>=<xT!U~l
zMraG(gK#vSXbY}II2v!X1@A>THbXY;(Z)9$GoTH(U59j+MhbG?-S$4j`E8DK#=X$j
zzaKPSS$%yZlAU%KYTgM!-$!~4`ZOH!d~uWcqN45cID+lwdeoC`r)|bBeddP{&-NtG
zKR%4GV4i6{h#%LWKLVGR$kOfnV`*v7&TnvO67oQkb}nns9|bSl+>OrtI9$m~+WRLF
z7wQD;Yxyx6`dZOf?8v8_+)u+z=;OCB=%Mq8bhUHEh!(Y5>dLy5ew+O-`96=I-*2-|
zZ$_hCNRz*7YtRZ!W{#!8t)VNdvoE7O=0g2Ty`;?%Zw8<Ao75d+rra%(76MwIBPv~Y
zL3gQhgXih)H+1vudvrgdag@JC`U#Y6rgKA8GIRbv?e1qFN84hKYd(v(8P5x2!mXXZ
z334JE-5z`n;mC%!2VX!~=7h{MviI%57ZKKT!Y^6g#GH`v&Fnk-B;rTU32#N1myER}
z&uC1xCALQTRq!{P6W(TM@j0Qak$%nPlhse`(mnL%gX$Kv*2<dqMmx`$;at$<&GvGJ
z@imu>e(wGm%6?eJuc~sUontD#7Aw)I*SyHI)pr07p{)k~82$!+{``{h(pP>9e%)7o
z8)4~7!u04Xzk_&Ql8^2yznhi@{o(gq8kt{y6Jhp;cRKff;EFuy4}XBTFkfgX`6hHy
z_Kq@G4k<hBB4zv-Kfj;iJgFIt{acu~8i$_h=9k}xJQ;h=W*I`=cKJ3+@I%P-ZR3v+
zw@Y)&SVq=PQl|7>w7+*D?9VIjM%--Xm6R>EPUX?|6U6&tT((QjD}M@_T#xv?GFBhf
zprzc${?irT!`UuxM_KJSHP=DEZaY6mSg=jnJ@|1x`3tzb(r7Y9k#XQJ!OM1aFI=_-
z%8~Z;YxqOCz_gZ2tdnLgZ$2qBqfg3w@;6AwJbw!}p(En`@kXeFPeVAOMdL5Z<hU`S
zc`|i6WebchXvbkX)sF9V^U3Q?neBX%<rFN)eDYU_Gf;5r&i5g#+bG90zeAj!Oa2~V
z>F2rDazDb+IHWE31H#cbr7id)!fA6!#y1;laNf8R^h>RBW*+$f!hRcLzsh;!pFrc4
zH9oN7TI*M5+Gm^H0H)72zUCbm`fOtNFVI=q3jMmR{1sur8fg#W$F}k}xV+M6(pHi*
zjVJqT@9&U9O#j2V|AZ?#NqhPi;=;Uvt)_XWU{a@(wM(9x%x~bF1i4(};NFCX;J5W=
zZTG(s*7ze1{)4znEtA1P(3g&bxv;fupz+GW!A$Oz>>vCM#=rOD$Nhn_zpfqm34Iyb
z@SPrgH_#iY<Fh6wb(hCBPj1EDwt=C+@rmW(_n5HVJVxn1$sF3<-RQ3N_V#u5^UO`&
zzq!cIVyeyfW$d#D;(1?XonSt~f)l2hhad5^04}d2Ey56OG0&!12wq}nPq@sRdC0hA
z67iI~H-7%Og!R~r#(E9)0p{+<`Ru%?kEAoY`j`VxlrGX$>O?TTKlF+C;^mF!9mz0t
z0XwVH38r^9<E31%7v#onkh^spe{_ImzGz|A(AtB25H`ouIh)Hcj^8wUSN5eG?1@B>
zSP%9?xTf~OEJFCww2X}Gw%{?K$J<X^@L0s*AaBgW1_m1g!*!nbSsvStGrija)+t(3
zV{i;7yF!M<VNW*B8|N9#mIr5hi%xBigFN336XScK{XHHuxfV7%jXq6(J5-5L(lCDh
z?Awy}_C`D_ytHxriu}ci_VfglN7@tp(w?3Oziv+lAuMf%d<Wvk_VgsUyppsCU(%iy
zgO}~;V7SCB^U&>yau31JZ%?#4&1l4Qs1Mqcyvsp-B%RSUr9DOIB3-E$<E1?v34g>F
zFK;~WNQSg0ole@*eAk|qKyK^~MK1%Gc5x`^x=lS9Vcn(}mNs=5WvMoGIKsM39f7dd
zrb4W6e6tjEzfC;_an0Hk>(y^ljMHt3Vcn*Vf;_)X5$kMIM}sC;i)|{@Kdo7%VV(QY
zd44hHjC{X~_xVGx4ZP3Nza5M7kn_-m_m5{<KM8x$&4qW^I-QR49tO{>=a27k(dLGI
zCeHHiLRj{o^Q>?F;ymp^H+bG`+d7+sx?HV?;J9dTs8+>yBJkXNU|^_#FP^y1+IROA
z8>P--8D|Lh^mP?0y}hNrVpqA`TPl}|eZ4iiY|%0|z7j0f!PHM%M-Oxqd(aENwADPc
zC9My?1>o2p?~(9gy$Q|6L^RgVB_`6wvHq7+=9H~FrekiDMcQ$WMw!RMALi$^W1Zhz
zrHkYzag=$2m!GDcr1D$YVt#W{@{>5`cZ!#vrk$$tds>tHD1+s;_SyP(puS{`vlcXC
zYfy9KI}JbD<aKa)C1_aWmbskFH`jxg0DL-J$&YP<e%^EIx9^&5LYOi)!VU979h{CZ
zuP?&3u}@!yu-KC$j$}W-NAOg{2^0s1w~btYGheItOv2D{fq54AUy9DJYSikDkWQKX
zN~U=yYw;0y5r+a6FFo=I9Mm#Cv6zF&Bh8p&k6?w8C;5#}pdk$*M~nlw)_bDjkvugI
z^IeseuVeCaW;st*G9}*z1{yYFo9}AHBl&6`=DQ{>Ut#hyMtL}o-Js-V8wWcdIYZ^c
z_vUDm_6)YQpNV+6@O@G{x_XptQu;nz`#u(q!t5#xR3;k@0IR-rbYlBJtzMbjYz`JS
zbJiC4Fw3xc1iABJv*nWSI6ho?Om|L(&O?R-?u-FVLb2?g?Sa~Me1v$gI)JU<gO}jF
zI9aSt78ftWx>Ma+lZ5w%`i&hp7g!J*M8CE{&qP@43~A56kI!SzgUgG1pcpUx$g|+r
zHl>VkTKbAgf3`|rbLpjjm3OM^sdCzbhLa<GyznRU%mrH<uh`dgnQg)OjxQ-Avabcq
zA!%0!z)QF4+|AA%bnXSt9fF&Xr}{eDW7Z?<j(j8VhxLuxmHJMjNnMJ~A9Z<N2$yns
zPo!_>J9d;ijvx1$NPj`Od}lDqGop#y38Z0JC*dZ_0v%-xOxh&)(((~m7dcrMr^<@*
zrYzp4G+Cr^j2`J6*MZLnLYi7zJSWF>9GpuExw2Q~LipIf*v}tWJ5G9JWGrRx{dW(x
zB0kytX4#s}yth3VhD`S^vu?e!6l(j6G02pDnzo;P$TpS<r}4=8>2`$mJcRe7TE@q0
z`4upy+a-vD`N7*Owol>x*Yl5On{a51&HUy$h(lkDcXsXf#n|Uj4x|iBj0_CpbugSr
zz_CM{iKl(zr^ZHL)=fH-m!r8TisF3Uy{GLyrr_Qe20v-U9p))Q3yVS;@r^l)eZN@o
z<DK6aA7ylak00@5I*vgXLFTv^V_Oex&qaCsIS+0Bldzt9DQI#%?%_j=oem|zH!It}
zDs}(A6^`$~)f$6%8+*dM#%6Xtq*Bm_upP3FrlibhYq7Ol)O$pW+BVN);5d!#l;b3e
zw*|rTA*ZU|$-4~U%>W0+TYN`q0RMO^?}44vpYP?pK=OqS(wEOf|4ZyV4Wnm$+0x2c
z(RLHS#PZZSi1*1}l781Idm5SE*RFZK2>RRpx2=PI=}TV%zwS$4iZJV%Hkf=b#*g!X
zm%-&lThDmif4>~zv^1}9Y0_vX<DT&1vtX{1?f@_Ie5G?=l_t~c%czI+Wv_uh)EC$g
zeVMmU6TR3^Fz?s8JYScZXA);oJ`v7XFRV-H1Bo~Cy%9fuEs8j9M&mQCH2H}-gbdxU
zN`B^kseb6qm`@S^Y#X+j**-?vgxh&yng*XWyc&EnLZ!3c|BZCsSyUNtwtdCxkxus?
zwBc_+Tv@&6csatlFL)EeXsc!|nE6KSxIMT6VgF1j#z`J>76<crvz3!Lhl=rI_8rIp
zE(p^ul<kX>10xN7qp!`_6V#NgK4+`nf^^OH?Yz~{;`?@J6ZQ+X<*o!xE;;AJYv2#N
zP1wbCqu#FGYEPq7sP=SK`+B>Iy`A+!Pc`3H?=4pHm2Pj{D3d$6ZuB<PiP)&O!!PZM
zV=>a+f!_k0qA*uI`w*I~%Q$U0_`-C`j<8+nbaRzVS&x%Aw()DI%apZu?}5J+nR8NP
zN*rZgr)0jbiA?e_FKffCU)$j8K@%H6z7OC>yZu49yb?6@L}EW=y!;{X(guGRuH;Ai
zN<Z&`^}BB_AWWGbg&XFFJ9Y!Yynf@>ao&lrv^`nJc^BfQTgTzO61uEy$T|<(?YouC
z#hApVEaPk&8LTZ{dX!z$v4JCDFZKwoPRU!Z*U&EVzWVuV9_nyyiVle-om4G2zTG2u
zugas@8V|AH>mkcG@($elQ}hs?Xo)9P5i?f*h{_|gnOZv++^F)@>pdSwyj(L_@5#=V
zBT}h|OzyZXxn`PiS8Ni*iP^)oNOIEb)<`~y`jhrezi!{3Mp)V~X`jN6Yb2k6%ZqCy
zj2D}E6a2cpeh%TZ^q+U>Wi3R$FIrFK#~xY7FKZ#fpOl>ozU+9DwB-6nRHn!-72NvA
zXCa4n=?l*Nl5=l%?k&#!3fx3q%GT44F(1|o`EG+h%ojB$b(uzs>dCIje9h(gb-0wv
z`j$S5XX;Vz9r*d{AABYh<r$S#Z16XbhGqRG+(cQRqrd)<mXFB#wv+XpR9R8p%!l_o
zO%`eFA0wUPI&j<>($u(fL(2NcDCD%d{&6exvE$HPZKZZS;j56Bw)QcLW^e4~?T{z^
znyh<#3vqhg<4%P2x(Dw=)m!)YF5>jM2k*Nc>weFK<Le&(gE)WPgL2Z=Js96?-NVql
zbq~{?qqU91I!3c~590daT=)1s^&W_imubtn?(qZA<Vs!ln8i(Py67<rTYd)C9PBr@
zS7C)?<;AOq8zXo*bGU{luv~v2tu2UXCzQtrtLR%9pHuOtl}*w$b$sBE>5fz19Q+aM
zXVvPpC#^hdVD;Kn>ju`WJY(gWja)-HvzS7_63WgUo?aXAnd9mfo?drad7`={(0W<g
zn!&Au6Prd(8XT)vCq~BjO<SkG=o#m$ZyUtM8R5Z`FH?TYgVI>fx>1ysWdUT&cS-M3
zW!boL#fB448CbX8D@qiPl0b*>8{4q8KSp}mp}U>C1mNJ<opE#Vr2Z#}r;R=q&*JA#
zMbGL<{~2g{oPQ6(@_e4p^3UlG0=o6Qwa2uD(KG!y!7sqi%gBeHeT(#sok({t;%Gy;
zE_jUE3-BwKPV(Z}u>5f^z>%PdP674;+=sCA&s>+}FV52*{1!aBIH#-ibQQ}zUG;ne
zkN)eGT3@ZNlCM|G_`-0N8v^2c0W!Jc<1mg-eh(dGd~!eh(qHCLY|{RKANK<Mm$w&y
zG<!uf){pE3AV2H>0m_`Rbw`=ZO=y31G~SE9z#rzP#s{Q{E=<j5`=X2FCvnX0Z(e?y
z_79ccKU>U?&-VTNB#!z0+sjYWf@QYsEJGXoY2~8~#>*I!{vA`SJ3FVFgLF*K@ds(`
z2y+g(8(dxqTFM-9cknX(T)2`S+XVf*=hkoYn-3n!+yicyAL?KM!n|&CbI3m;o%FRb
zhun!cnG(qSN#=;0!~IFo)8>#5Dw)mp0=NxAN7CMK&h}R&Q}WdFLgxE-#UuG@9?l&f
zO3OPjc?@$mdH+kvmAqx1$GIT${*U63yfqK=&Y^ClF2iyQQ#4@=Gw1W1c}OF5o!RW&
z9C4w_N6!)WboZ9`cLsCB>}>TMF_SxPn|9T1cJ=nws)b6mQZMCu`WlTYHXGOL)gldO
zSEb<D%`EP?ZnT?wqt3)`cEB%olYJ3s`{0+h7Dk%Al51gMI?w)zOs11{FZ$U|xh~R5
zI$7J2bX><sOGlf)c(F(HYkPD6!eVnsdpv%$M^At&vT18VT8ce75WM7hB3#K&>=Ely
z+oQz@GruRn4P~O{4@Q`mtZD6wu(TnuNBbd8+K9AIZI80nv=%9uGhNf#KP7K%b6Q=~
zdQ6HA3A2>Clw|GWV^j1H(;_yil{Kx$rRX7YA`_LWh?$!mr1Yp|H8*FkmZ&_ny*dQ(
za?QkEWo8?*S6SR~n;>IGjxRYrrK`uM(KvHX@MNdIj7d4a<DOHFXE<l$NyLYPM`SKP
z*2?;rCsU7kk90D18tO4!nx~}bL0v*Uus`-_@Q9wzfXxs($IjIASViah7stV2deA#T
z7oARZ<v9HC=5^EMbkb>9j_J~LyELLFbrU^|o+w8TcxY?Rg^u&5qB8X%KE?~3mmyBZ
z_Pj46NE7?61FY9_@LX=!F=@)wH84=-hfB6r#<}6)qU!iSb=2SDTPie4eLclmUr$eG
zz1UYQch}2ZojuiRSE1h5(^-voPnp~?DDv5ITgP$GPx`0h;n)2WY5n*uz>bMYJ193c
zmi-KA_KIjS&gKpa^0OXKq|7OMubEEMRyrE(_A2<p{8IWg$&csUi!PF%#4*3sUVfVP
zG?m|)7W12vlApvezja=In)Y;+--agnQ3lH<{V4rAP+u~xKOJG|M@id+AN$cW;POh)
zQu@&|!AtO+1y}O3eP^zN_uTsJxc*#(Df1k-VSYf!GZ5x=3DyQV7F~g`-;bVvxas=Q
zlN4RXxYEy3=E+KClYTV(JS83-xhF(iFj~CSJ}o-RjeWzgjn=8$e&kb>F4E`w{qCuX
zNA%S^)cLd&ofG}8&VROAyLrr7rIY9_{j2oT>lKgat$C>T#uUAUC+epk4#n+WfwPrP
znRd$c>(5j=vR|hi<=*7;5HA<^^E}#iRQdp}0r9zn-v>Mk`cB&i(D<VdU{{dr0}8#B
zTDhm(=q;4<U6oR)+F7l1_2#?EJ>A`nKL2rjCU;67P=S8Z2UOwLeE?}S{MZMKczpnA
z_KIj?lWFJ4PkXbOGN<BwfY1gVjW*|e_{02C`T)s~HeGa){3MR~ZT0fgv=NoxXp8yL
zru+Fx9P=CZ^3$|QmEX1|`B4VTCVc??x)0cnu-JLhF2;|2z$I{bC1@#qz_Y>2KHxcU
zB|qr{c+Yho@H~Vm^HR8Ben7|+!n~vps3Yw60S&}W*9UA-bg@mk54b?dY`qUin0?(R
zH0=Y1lrCaRwSDK@YgqA!zM6-&^uiRKTj>L4thMU{#*|K?x7cp!111!Y=&gCE_eCjs
z3(vHDz>F2QeZX^-PMLPf^#RXUI_f^)GQ`Uj_5qKg9hG^A%mX-%iuVI^f)^rg+cbM>
z_0!VkFL<b}wyh=Tmv`s+%!D>Z`m2{X9c8}&$LB8&>$N?2sq@QxX({?Q;iWB!cyqxH
z$9n>vQ?cEgjegMI8_%=3Uk1MT^Unpr%Mqs@W$t7hao_GMoJ`(l*|*zTk!M#&au1~+
zryca~;j0iQ_4o2cI6EG7x&&<Ohv?GE{x^7b?CRbX>~wG8m7dfmoGNMf4$o_$lk_k2
z>;C2S2umMA+UxM+{**Vs<;8g-<7JHSM)-Aq@g{`R(qG}yCuz}Mlq4;=_eAS-KF3$M
zlIfy75wiE>a^z2(zS+5Naqe54d!=))f}4=1#vkl2sRPSQzIVVM>V#U6dP<{79mu|p
zce*^^1($MJmonbs-V@5b8o#u?CsCeJSw-$ONW-$e2X3M)(9z#}l9rFidasjpU8<}o
zZ{|aLkS2>X+LK7<xDK>MAx-T)DedCklea<V8SFh#P31VVC;9D2Ka;&CF#+hG`OM|r
zkRjtD_F0U(7IAui$@>u2`%75YRd0XE`w^%2m+;=|{UskT;rRZN>k${Xuk8Wlr0p+Z
ze6#%}hNg@%_f7v_*<bQO>h0|>p}pn)k`I9<*Npa;#BSuwc9f{3#@<T*z<z|bBHo9z
z2OmM)?B|2|M!niu?x}P&iiL7_SH7!M$`|XMz12dkyPof<$JYcixiKH?DOI|=^Icth
z*NwLRW6)1*{SEMoePVki?MD34=7Xf!E1ECS4sc!<rc-uRY=oqfc^YMq#`#$*>14ho
z={V0yOGkUlc<Be}*Ztt<5N5u#qom!0ALm)0hbyvUw3K<)7r;xNFT$1lY+sq{U|s5d
z^JavZ-<RQr`Jv`-L711!vp$Zn*b{kX^$Eo7$~^0nO6DUy&-zq~u6hpD>OAYyDLOxr
z^Q_OL=q>Z3nas03o1(YKc_ijpUs8H!wtqLz`ijy~&$Dhtyj-o#v$Av4kIyo>J^Q4`
z=<k4TY(sJTIw!adap$x;&r-&_*{ngan7NeLt*?i56U~*xenhm^=SH_fUcB#K5Zr+{
z)eY}txi~laMwoY#xsg)3)pE%^ZxU6?Z;W$JLz~a%ci%#OQum~hhcx~|KJ0h<4){Vj
z7~}CfzogS9QqFe`eV%#$n=$Q>C2}d#{8T!d|D53aE}h8v@*-<rKZ)mV^QUYcOv~E%
z%wui%U>D}tH`Eb3UEi?34cljac08LtFK=>&U43}l;MmBpImXWJvc>vs^d4+;vN?mR
zv(mtUJ^9`cOL^$|Q<TqK7z<zhIO`>rsAEKn#@_O7Ea_a|vHP4B1V4kE=$*O+!9574
zy&EfY?4L`%$g-{3d1lQEWT4fYoGkBj?{xU@%|*4p7-wA6$MM#A{qSYWnrCN+KF1%L
z`VwUS>CF>*dg9Ko@BSs~#*P)*j9<n?ze2q3$A68mw0owx7e9_0?t{xqWbK%u-#%yi
zZId*=b7|7#J(WPgCGXw-2E1$!zjyBaX)@J#OZ1@bl)n@Fp}xSK=$l3py*NkYd$$j`
zJpYuMXA;9vJ`skg59?CKm&7vp{)%7Pd$-MKJZmgXexeScx4buJXf8i<ztkM`+wQ$v
zwmbj5Tk7b)cl!tMr9y7`ED&tgc-w<NLS~b9a%Umb&O!eSnKF)KAI~-5zaUP(ulpdv
zdXD)wgynr*>J-_Q_TcXb`|s;APV&(2>;A*aiM@-<{28D1zAoz=H5_|i_n%1D?0wyb
z3@!Qo0pHjC7ie-ddtY}J6|5(Wo*A2&-C;jv_V&1T%P`Mm34qUe=+L5mEEn9jBp!ZA
zrwU^)%RfpCx0&yOaqmhFzc4-MbDnB#(<sE#HVN+y*gv#8Xlx_YCE7oPy@-hCMH>5C
zO}j8}NG6Z<*uz7e_ddk(@*K{HH)@BHr<|py^;>B4v-XlYCG%_x_Hz2joSS^yPbK^u
zKScRr<mC8id$^wAmwR8(nNK`jF4#|{V_njQithV^CiO+EMtit&!DC!H(OuInQuTF$
ztFMA9Cv959tLw{+$#DNVkBRyd>X6K%EjZBSFZDw{){pSBoKZgQ!9k9n^}}-N`eB;I
z_(}al>2krrE}h&z?msQKJ!0kzR$$?G&{y=}ezWH9X0!)SR`OUE#L@w%BT3JFUd{K;
zwFgJI^ujNB(G~qQE|z-yBAc%8N9An~j`H}4-z0|HgJZxaI&eLRzu0_bUVD%S5A$GO
z9_fV9ST`bY$@sVj<!8O|cLr#pSCj^4PddGL|E`8T;Qf>I-JnT&z2{J;FS+!hPgLf%
zV5`%I_n5l!oryVU*CL<#@xJh<^^0W836?qel7>1-8m*H~v)rX&zRz>-;jkaSahhi=
zVub7E(E%JJ<j!Ci8o6k2#C0SCT#j{b4Tq<xHOA`ofzgqn!Rq$(!K9NXhqfdH_6sFV
zq&m~(c$7)jq3Gv*lCj|mgr)vT>&K7d$rIr6;u;;}WjuNk{7a{z^eYigq{s7|RZ)5~
zhI=(u{1SY~=M={$-@ZB#VczePox2*Yu@7*WFJ(Lp{!mx6Rnav;gVv&lJa1Uz<emmM
zp^qBBlE(WV<rCS(WV)yv)RlE4<IFtDLKz$I^T(MY-=|RqY4crqPe<C8^gv$zm@`Tj
zJrm*gns|oGsgN5VOYRDS?YM6(WXhOK#(nD$=Z!CSB_lJITo0Lg?D%wq_1Kbmy0M;l
z*0K>{fBeWe(N&KhHz8iep=VfsVl2t{tg)oE9|NOyzTDn+Cekz;N1kP9@o^+=&OSjS
zcQ$Bp`Qyl4smQc}<ilfg>^O?$7yC^MaxTh2dvY=2#hyHqaW6FS#!j4vu(Ypnth-!-
z-vYGp0apiN%lS+XL()K8lMmv!u3rW(!=%rJHMt9okYTn(_U(H<AqdV7<lWm-P~;Ow
zwvLu31}lR@IBJfs;f`%ZaAY`e@8FVW<#4$&RNqt|+d4RGi0g(=92py%95sx5C$>Ex
z-#SEW#c^#L>f<AmV|>kZm3kky4&4S$S-E1pc^h}bX)89ZUblAO#5F56%8RV&L@X2R
zJOJbC-CUU)kRxSZf^xHb9AC{1b_+IxwgkL$5#~6Ydnq^$pnoyONvqJ0#>VGJHHb7K
zgLmgD@W_~x&x-vux*^BEFGNFHAYq8dCF$pN*s##;{D5-|U*3f=dA6^oJ|bV}BA;Uc
z(nUV$f(?$1p7#V>#{H02C<kkX7rA^)Iv19794|FXcZrwIhHZHyKjstgom6}i=edp_
zQxafqPH+(7r9LGe@*m;&r#${uioYLvNjdUHUM_fn;kWto-mXWPDNpDxis{=HtbI(B
zKhGwY`WOC}g8zE7i9La1wi}GxFRs=NwsAn>)=C}cBMNPfqBVxfo5wM~7uq~U!^_|!
zWBB%h&=xA1J0}Zg8ru9i0-MXgXn73lZ#ZyvJftmB=>}EfT#EJS-GQ|o&|R+e!NAJ1
zPF%U(G^-6OPh7X*q=6GRYzmH1Wt$g_S7G-j*q&*dMTdo0f!RJ}-lE@Gg6te*ze35z
zIgDEN$*VVR+Thyny3<Zuw>H>W-n>@jgE}1M8U{|v9k61fyygTr(GaE7`9rVKdUddY
z6L#(T1M2)Rvj*Q5yh`bTGa@&hxNiN*O)E}VvvOeN+D#kI4#)kxcbpf}77!0~IimV+
zqz}WefownLL3R*K<qS*s7p+Jftye<v(W3HDoreId9<J3dHjA-doLSlI#Sve{YQ7r=
zYl*81yQV^677NsAPJmbbA%;3Yf!ym=`Q|lS8}{;RMF)<hUI*D6OX>3SJI9q7mA^Vz
z+cXksU^Dk3{Tg^+=h7G+hQM#@fORq_7z!(uIG{ePiz`~H3oq*y^<n?}Cdg<1%kLDt
z1^y+tAB*SmI|Xf~u7q}_qAf*#vIqERH)y|^hW!HXCD(1}$}g<vV2|K!kRfwYrjZ|c
z?7Xf$cn5gIHc|%rHA9EXzU5t@LpL)%xUFbubXkh4P1<=KHf+bg()Woh(UUHJ)Hl*`
zZg4GR_-R;1rl-rFpXNHG(f#oe;4x)`Y|)?T*&n}O@tS=t;HAxGzY&+aTX6j}yhx?=
z-YxhLczF+H9Iz1IQgC|#S+(jKsE%yK2_60`UtRTLXR%c1EcO-(^?V(NH&lx~jYeO-
zr(ACo8jbk&j!bSmKJD!7?Wxtet9Y^A?(g_0bd<5)$KaQF5$lGu8}M5Izsy_MUKua*
zRr+^KMfd*`2+R18w2$M*`RXU(@=DNhTDHZ|75OwiJj)AZ*t45Hg)l4f)6V@YT+xqn
zQTkaX>$kE$k1%!k9NbVp)W8=I<~0m^z_sWb5tg|J_gQd0b`#=cpG9V6n?AQKU|H~0
ztSzi>%Kf5}%lQ}auzPS=`<Gn)<i;H0QNe?>agIHCAHz0?^~IYJzRIq#_}I1Y+}PC*
z7|aU>8e7b9oBYgykLY@5tx;}t_tYB=yuQ+1EcO<w<w7l=&sX~T@Tz?r(V5&aL>v3~
z73e8=z7>AKGnFRotN8hNX1w5;evRj^BP^ID?Q8fE&$q+nm7pm+CuvCx-vK$)?HkVh
zCS2l{c?pJD4vpdOAWYfch8yaHQs0R%FTwC_2>TfR7UBfMnbqqsOgv}|e^<#RhKUPe
z_<JsYa&sPR-o^SqfQyF%w_WvGcd1xt6f1=?UbiiEcXxLcOSSHNU%u9v_s-O*XK^QS
z`+d}%;PwabYuu9dL;QT)GG1^?zsBud2n+s5`!RmR?cH#BC1@$Q4b$;_!Z4k+y+1*i
zxc#Yfe+HMhWg5XP%b{`m3xt{P&*6r$QR-hJ%u8_lBZPh2-h;Rhw^`NO1h@Apxf-{>
za`{t-nc_B66}`b}hPaS%8Ep{zE4ioao8P!J2(G|y0q(+mPJfvvlg{zZB-|eys_ZyQ
z_gnCaT+J8SddT}dcvi*6#r3hV5qzU(q!ycx&9SEdR!1g>-S_nDTyb77gb((ZShq(h
z$o;|T2$h1S-}Sm^Y;dB^UC5I|6K1@uBkaD6o<ga&tCa8Odn~%Yl5(2v7X8&u<R^49
z{!(K~K9Bkn=;`~yn#`}XDlO<H_ky;Q<4BGtMaRFeF0khCpwV$&hYja~g$T>N(dl?^
zEDxTun>6kFk3z%}{P3{>Gf%kC3k&`9J>&H2b~p0~Gge;<y(pW!v_AjwWw$Y{UBh@K
zaI_d)<hKKWT##EHjmtSsCf<mtJ$kTj1J9d(z+Vi1Sp7p9&SOZYy^}FI>xe&=dw1~M
z4?6S8Lmozm!Cb`sf9#!id==HV=-12y1f)rCQbnXEp`$`*L8Lb+q9K(YLIOw;L_{f4
z1Vs@M5Kurss)ASmK?Je)UI76?1sekD`>vVU=S)t5c;CIBci$hs<a0jf%$hyBtiIMR
zWBQ^of|d#2w<SN<8qaE;4_h^4TxyDc4qjIB5MD8=QM>wJn(IT=x#!hg&NIH1${-gq
zB#Vq9Z+sxdpakalJ<ozg+=KO~$DCWYpZP5vcR}jXaT`2n-*k-hR0?r#sOLM;bnx#Y
zyym7qQWDZK=nXHj@YdyPpKi+ajw>0Q0Fl@vIW39qsU9vuo1Sgp+#!A&+j0fJgF3kw
z*TxoTxuSe@zfW<#^)JW00%3pMtp6!NS;cxuzH^ih%-NWJY5Q8P4CO;@(nHgx=8Ysr
z-Xo1ATM3?8@P0B<<sars;k{5j<W9`~mKE@W?zbpKJGml`=hY`K&Hc%_7vR1nWw~$c
zk=hO2|4<GX+!I(vrg;PJ{U4m4nVC9j42Lad`J{8(vC8vI<X#2k3w@Vw1-Cw}^B?qM
z?tT0(@x>8%(x-n><yqwm!^>}!rEz4d67cF!z{J8KUe1?SDs!((uJrL{s#pR!dgQp~
z&69@c>$XOx4kCp{2YUyu<ANn2B7VDFv?}!)e%0TGU$5eKkYB5FZFo$}RpX<6&DDJC
zU(S2k`BnL}24(g88oo{2h9_$Q3)KrRnR<1NrRtV}g-0Zg8!}?dh=imeqqDsEhswfB
z2HXXpVOUlO<{84N?i@otTXjVp+6dwx8@70-<Ct{K#ii6uCFNQ-*qj?3^=bGI1>*h*
z&zg(S_N(%F4c)H(mdZy>`V)B0osX*xEXeb^F263Ye`wpy2W$O|ZcG;XSM#>@cm|)!
z-R`7(lb3xt^?{kcx2%g|;$QHM7t?q1?U>R{c&B{~-^#P*x={JB?NI*FPsn!QD>QVk
zJv*oLR~ZQ2Z|vT8N-A7&moL9(Q_VFdj^&eHZr)pG%<Co6*k$GF3dgmZwj@kQ%^b;W
zlb2(zOg)bO-k>eu1%7mzYuo;x`k{IxkddbmxI{xThL2B38qb=9+jz0v$h3sfsp%%b
z9+S?B*kOpA$^8ZaaV=w7w!Byk5#rddRYI3m+2u7hu0vdZwg&kY#?2jRpV84OMuETo
zzx%9y$93RXb&JZv_54<PE`oll2lQI?fblbw7Ywgd(^0}Jalpd7;pqpxcKP0)yA0p=
z${U}qNj>U-hYWvt&p6V~t<&Q_<z;i<wAr5f#-A))AzX(k=hYJ>9Vlno3YH7^&ykLl
zQM;(RtS~(0#^|m+O-zE<5|c+KjBDB?Au~B4Yw(b?(XJ0wD)(|(S$HPFa?HP6tiIH7
zf%<eWUM}rweW7v_{BwnsKAq`vcD<A9^TB@Sswpr1RGjPEDK9KQXB3zc#;5vq6X{D=
z`Vzt?65NezLz`e3<M+C>K?C;ipY!yCB{NEd>sEhO%SG1RJ5aaIN90~EO8P{U%g3Z_
z&ibOHALWd#*S#28r<RK>uRgr`tv6HN_~()BXCGf4xh0}(u+GS`36x!NkzAsG4BF^S
zCgoJOaSjd+g&yWGW^`IpqwPYOfM$(jVjINriEf<SEVf~zW}Jf4D79&7!_>s&Mv>>?
zq+Y7Dre%^+8>R3b9JBv1k-i#VB#GZ9FQa(Vd&zwCtYe*z*FW_?%smehzNdV(jB?6X
zS}u)eLv;lF<j6X7ZJnv#@ScHbokO%=ew{=AWu1EFaAchZrge@8)R}&fI<=hk-{he5
z_bmEh=7L6XZTvC4m%&GUwM@SCFULJQr>~YpSv4}F`8Ms<n&SOddU(G*Kj1d5wa&48
zhuUMD<G9wpFZ^?eQ@A$1joCw)3e0eoIY-5uMWeot(#qU7XQ-I_8bb^U)LA)rR8}r8
zwee0V^WI}KI8d)?H*!Cu(loN|U>R+H*gv(OV`HT0fyO2IWq6=|(+9IB(d=zh9*FEi
zu#EO$<UjSn6b^54G@Wqw#E%Koe@QvTertQ<1MO*CraDE>1e*Zd{F$>t&?Eof=#&X`
zE*N)>_H}VkzZ;$D>SE%qNsP(JzU0dzszc43=*4t-wmO*UoWe84KhQi&2iAFIE5rKZ
zseU`ria`9CV#JHazG<9&jOUK?QM;`D(f;Y0uDjjmJRe5OX_@eSTc!uvj^kdi?P#|x
zM`mVg+mR~dQ;hx5d2MY==X$kmZNt>B`JvhFv*Enh6nr}Ktgg+`H9eUnyqH$U9(;Bl
z&zdo68zzUNzr*FCWPYHWu6w#zx%&g<w67N{w~%s%9;RK>raq&Z@1Z~$(`ICuhXZ9y
zdy!=x3G_+VR$Z)5j|R%A|9P=;%K~kh`XbwWEKtVO6<KCwpgp~3d=gVmzcqq<JWx*Y
zaItc$1LYJK7b~|m&^ObrX;Yt3+^-9iF>OYc*+3cP5%Y|$<1xIXc)3{nn*#k*++3{O
zmOvj&eUW|G7ARxtiY)UCWsE!+Inek)KTAsl_#EA`BT!c35t9eXt?bS~S*=(1iCnDS
z=L2Q6-hV3lB4v$im^B_|O`MKR>9d<MCRV$QcFh_*&&RgqCGHzqm^#!q%U(~E><g4r
zy`p9Gb6q(PFAl$z2lrD>eUNK`tIwk`q{@f#**Nr#X-i@HQ9MM}@hWwgahY=3mhzC-
zjw7!H`lDs^zOfBKee_14oT1TAf%wtI6Y~sj1={S&ef=05RMvii%XcVaaB0eDTi$(J
z-V3y)eKGwp^>{Rik`E~NkLQ{EKR)BQX>?-aCaH-HjX(bp{WJdj$NV<_y!K!3eZnWV
zGmiD1_ZL2MSbfcS_7H}ii}2x1o%)>GNOM-PKG*4AKBwoI1fT11k>`{zwI9Y8*WW>3
z{9CS#zpeMa;iJCzVZQY*$2~izFMfow%A-g5HtiW-TyYun#gB8Xbspn8)E<~W!L|OG
z^GrVFI?@;a44CmXjX!F9ZS}?5f&+6uH(&hoK%M{oJd^*svxC3LrLRHXT>E=tF8vLb
zQD64UT>6~DZ4bs3|IM?5zsjZG#zi+if45xv9W0~${yLX_n=)Zn|9_(6-u{*E0{#BC
zX9s^D=%dC7s-HAYI0@YRh0ZhiU(`>=ey9%D^W#;9)P@9g{tv*6tuQ$NV^7rX=_k8R
zcI34CjOUx1GT}Oz3-{|(JEL~441TxX_pTi&$8~ObqugykUiqE+jIR-lO-%W4+j-=V
zVB6TLQkQ5eTf9P!>H^Ojys52JJFopVI51=Si*g1}!E(WI%JtdDX>4y~ot~}BD>mhW
z<BTjH9A^||bL*!WkLhRLOZ35%H+{%Qd1JQ~mi@jh1-QQ;_gtI1eLr-zXk=<FF)g-P
z)7XYd4Vz&=QyMg2!4v7VrYVh+6H{V&Lr(UUdY3FsYK`|5G>cA-A+_eOJuOJzj4dw2
z@1QN#dxiN#u6a_pv2pr4XydNn+SoC@SCo(1xMF<kUygeL8)tB+>opaJIm_BoGE|SZ
z2C6vMY7a~J-=+9gyQpm&yQt#|+QqV5Yu#n|4)qZ%l;c|eCX<_2y;_9ppk37Ur=@`z
zyLU;1qvv!!I=KE+uXSuuk}*2P&!LnLw4=IFd4>6Cr-I)f?Gy9a|Es)WXrpnv(l{hn
z%*RyZ`hQ@3Uv#6UNij){8>PjhMkl5;YLwV4scExDiA__QCZ|NFHi^#8?UyW_joaOI
zsg>!c;q@x~HoUI<qxY)viR5*K8(!DnL0+%Uwc$~{cNHIZ9-MFe%W*Hj>pAb`T;ErN
zdbDrX_}?}8R^HaO3~%c=g1lXaYpuIB-=RJ+>bhL(pUyWcZ&%|wlDBICGrWCC^!mK5
z{19B1S}#zq^0HZ%THkM9OaB+w_g%Uxy87Z@cRV{^{15PLY;1#u(T&q$nx!;s(kMA5
zt!Ywp3hxGJ*d#TjS%b!nBDC}+OK0z&&X>l3JHxlJ{0{Q1-fO@ol5Z7m_*Q=h`L;3F
zhX3?lBR<NvP59Qo9QShJ+t72ltV?Z5J<7Mu{O{&`E8prfhHrHoLB747Yi;*BzC(30
z>K0t<pW)kvTu1WlwZIJdFNxlZ@NLULy+OW>^V`=x{1^H5(p?Gi?IlZR=L_RUsSZ**
zW@xJZM{r$gYrp@huUn97X1kHQkHpLmDNOGvy)@U{j`IKYa~z10ILCqPern=~|B-VX
za#Z+l&v9r^{|(>k?;ziI;M(xE-n)U1^8Jl`>z~S+!i}tT;&+foJ9C}mdHBDJ|9p;n
z)ZJEb&YwBEp(AA#*IoVZZhWh3XuH~$*3pCCq5eS=)4v?|=&5PjoZZmVueTT9Ir<Zk
z8|gvc!tI1}4LP3+k3;*acriK%SIw=XAF#-?8%+JV-5c_6+opcA@5${K@kO}L;dO@Q
zyoT=d!&?E9`-vkt80#NT9P#4a-qdMyj_L-rpEm*f$MYKgYYn+|_My(;c@2HJ4xZPb
zZ3fS4=+AZJc?}9PeGQ)1a5HdoUc&(IcaHNK6n?4m8kDABICNgaEj)9v^BQh-@8y18
zLjw2ApIK-1KS427sgVZ`Mx57>gEIe4w^&8v7`xF8iS*yoGv2&+64yp<f@d-$`{Oim
zr|M^&#|XxWdac$am9oKdI@b^^r`K9;P@tUpUwU4Few(<{)Hj53#!dv=RekT3Va__D
zjA>KLc<nhdf-<3J$PZ|}rk~nwwTSlJ=O~vED5vKu<l0ZlWk!^{Sbd`@cagoD8DmEC
z5|qgJxmjv-Qscy=CY;Ni)F3gnL6gLkX3d(UL^n-p6w@rNQA9*>$<kQhCe0c&YZRRv
zj-SWUC&LrB@!RM{&GG2HaeN|uGld%)rN4tVY9iN$kM!OIK5C<G=Ue}B+za?-#->-Q
zlUq4U?g-W4#m<wsR$DaL|DM9P>UV9|vwL<?9aGQ--o>@{VJhFD{(*sMT<f2n8KU}e
zJl94KnZ28L0yBQvC6Vp>X*w2G__*s~?+(<ddf4pSyvJ`_OQK8uS9n3?Lusyiv5#;b
zn2DE1(|@ID=sxlCOs@ZNe#YIwnV6oEklXf6UOd*cLBp6d@;}Xznj}Z3G)!(3+axJE
zCM`C$X_F=q8<H<sIvZ1a`;qUZe}<=L^V{&W@`~P@!zYrb6>fN1e+PN`KCTVl>b-e<
zl&9zOt$#W01$a8=JxlI%c|xD__;>;JXy5MlzaQXR`B>XBe5~UL^6^7lYuyj>9qJRK
zUc|NjW%_(Pm+MGAUI@(a@g?!=^Re=Q=vfA=4>oz9hXZvhKPyk@9?r#nAM}Yp%)z7o
zJ3R5<;MM3D4$DrCCW+IyQA*>~=!P*dsVQkqNbs-$xk;n!DV?-SmCl7%mw+q7tB>+K
z$g6s9DW6DQRk-0*{T<}h$GA2;r}vigQC?laxBlh0mkY0ko+CDh<kgkbqrAGx|9+fr
z<yC#g@T!g@$g69()^=C(9jcpAujN|*46iQZI+9nP02boaOX2q)c=gFZ-9cVm=l4PT
z@h^GxlD!Cq#s5{F$o;$)e@%Sq;DkYA5;Id$J<ZB`=By!u(o<6^XAK^iIof5$-o|;%
ziYOe{K2G;KdG(7u)N_t>*ihnsu72f(4d7Jy)A(+xKh@qE-c&oIWj6BBy{DV_)<08T
zeLb^=LhX)TE7xtI+)cUf8*0<FOV6$xl+&YKtG4Dh-@STt?c{C&Nie`%3b=SlLtmOR
zg2>i%N=+X$da%n+-hR|5N$-$8Wb}~4;ca*qVEEjke3Eioo6(uW`y>ua9h1>HF>6@x
zEF|uYOdp*&a(Kto@jZ1Lp4)#yK>KNb%sMjGy#GV@{$2kS@7t)ez!a6W@EKx?$EviU
z=Z9_QzQL!SS+axci<O-doxSYNKw0&f%~}z&{>Id+>k6Nztf8fr%~^(XFe1vB`oi_F
zHit6C57Bz`Oe?*w`bYOsycBUiF5><^?pI{JuF}=>ZEowGm6{o&b4Lbdiwlbl!lEQA
zacmptHr%77KATtHcoYH4CrZ;XS$*^bEWggylr13fiOB)pDIxJ=(v!Wj=Cs|)lqn<a
zbU$=2J!;>;%1V;<uYsvc=~hlp;}6tTQP|hzU*E?4s*;#FD8}ojUf0s=*zk2M5%K7;
ziNj5ul_}F)$CsKkCXITkB2Puo0Q<p}`Fldz4#~>sq~{i~JMFgKNxp1Ub_=A@f#Ip?
zejgNOiNd@#_4+bNWABzW8s4W=h%#eF(6<1runW^;$8`T-o|1W}=|G?#MX4v96TIZK
zXJg7S|Em0L;)GXS`WyXV$sw*)4%~9+AI*p9Z)0EI(EEYs-;8+vE&qA99M9`Kn(lG2
zIL9h=9NSvxr(WAKhAmQ=X&g)8?rq`iL}UF+_kKRnZCVK_L&gqav%B|9QR)CAuJ5FE
zR3=lBu165UV|v|E-_+r5)g6=NZ3{eex(oYPIN#4!K6sbD<+}GoclVCTQY8`EY@B^7
zj#nTqPWPMTEBYSw=%41K3?3C0k}F300oUgoGxpRG%<p=`hsV9~0}G?Tg%SOaNC=_9
zE5|u;BitQp1{MDEMHOz);ltSfNaod`#CyJ_!bYe{^{(+0k`vNX6O~`IA7XKxGV(U%
zMfcj~dQ65(6LI*RJb0waj(bn9v(=TtK5fLn+>hcqZTOh1!5%#%pSezOU6S;aEVsCS
zvOt!~lUr{=zn*Y0x0YPXWothpIiYbwudhY<-Kc^0yE4CHeRwp#gU`fqYFuJk8szZG
z3fCE#BZsD<To{SlA1xDjCTfcEziw-Cah{Eide1iZBI(J!D044@uKHX)b1%s1K2G$0
zQFA|n&U&x1xfelivJKw0u>g&=e4K#?Xsz%m2JX{bVY>}1K>KX)2;7L}ZW+tL<NA!)
z{=HmqBT@dnTyP`#{CgL{jT8;F>8XSO-lVdBF9&WE4i87*M&f*U1a4%C4-eo*cKfgh
z+=SphZhD}1>iK%-ql@Vs-h!--%|9p}zXY0x@u`0KI2YZcu%Pbw)W7!hl&6cr&st*c
zdp@Ce9n{l79cxGE*r;6ea=r-NT{J?sSB}vAx#{Vf0($zZ2z-r5OdgE9x*H-drmAz6
z3FGW*#hE|vq4rF#J$vTmZNClTi@BD=T>qQ?C?{O1KjAXr{v3_yk6s7+b1b4i$GO&i
zD?NkdzK<w((!KW9muXpJlUzQ)*ZaXQ@8N^9|NU#v7xc!hYpJV(F8!2XEw%2qSKmsn
zv7Yg%3CW|4Pogm5Jz$Cj&v!XPovc#<mXWAA4)5JqV*d=>{8hNvxs|Tb)i)#Qo^7mg
z?;yZEU87-2Vxz>^=$JT-!<45zT;?2$;;cV@tLk$r7h7rPVk=$yn~T12ZE%E+a_w(~
zPIK*Vgq_c6e*?D34%jS*-^P~d?|_b#f)RE&AJ@i4NAWwLw{qBbeKuHE(SKq8v`pZc
zmX*}6@>P+4-h#>p{9&tK|2w!2`c*+$yr_!Hr4U4QX?j+9B_OYQ9pw9ST!-`-@_L@@
zQa-KY1YaU0af0zJrsP6<v2yxJVgt*C_7Vj=g7%URSOo2*D6k0HOC?|dJj%cbI>rU)
zSosok)Mo>A*;8bSdRL<-c)pfBW%u7XsD#Z>Iu-Hh^e1@AjZUhgE=i|AAw#FXs4qw-
zy$;ezT4bk_#kJ}&wO7G%PDHsV_uA8ATGrS%{nnT@uV3Ed6VB-MuZ<p4eo+4K`j_**
z_QS-)stfg_<vqQ~`A>oSs$cXI)-|>i=Dvx|RR`<GtPl2dE$_4m)S>;<kJjP!*_L8~
z``S<ag!^nui9j2QAN`m%JUlp33YeLLQyZoq(;uzN>kI3MDW@@=Ue}tU?RdB?2V7xV
zR(~sQ%LnRIJEWi7>bx>g&fGVB(E2=FMoA^gY1?`oY`Y3@gLnO{ZCA~uPSXdi)6?})
za+P1FUI**E8n~gA{?<Bc1nN}1p&x@!t<%G0l+^U=)aziKwSg;4%j$2fvreE+<#GMw
zR%g9HIdk9iLF@B)AxfBobaABD!M0<88@|!s+IE9n>NI`OIz66`64L5!oq8Rtvk7p+
zYx-O3Y|6Lc2|fG3%prSgp>1g%xUaD6=Ofs19rq0%P9#TW)|Y257bPtyXL4nc<+8V#
zN8%`}x<b!-P+g&ZNo!#0a}>lcG5uBhW7e4KZ&aPMrJUlzyJk&g>F|2;#>DJehkmR7
zYreI-=MU$V_B?+zGJ*+m>o(8mxU`J<*5Bdh@<|83UALZm5!ZN1C7CkTG3kAqF&SLw
z+I+KSeH8Z$-rRb~F?OL|l_B>m400+)_vkah@*ce$=}vh=4=r<dNpCH_sn;tPB|Rw@
z+)rTo5Lw>qM_%b293NCsyqYmYwi8LuzJa#%{1ua{)O=(&?wRtYt^UA*b;s29#t<y)
zj)Pq3fI!{B^Rg~h_pOu<)6J2$D_wjpHboD@@Xj2>L}rZ~o*KEppm9ucOj6Ut22GPw
zQ<4)Krld7WOG$3jFgCSua&ls7<CN_4TbC@&{8r;eO=8oUHi$NR<r3+yXD{udN&GhR
zTZ${am&_+}eoNtIeoKGPn&R@Fd)^?^!{F9?x0T-G_2lmS)*!z1FULJQy#7l0upTs1
zoua>Wuc`U{Sd91E@aItK8^&iipPY5FrX<v!H-|fzYqjA+{O@$WwGHi~X+y{F{q|zF
zQCw@?8GMJv0=6=_*1u<nUvw=3WXLfuHWHYb7rP`~kXK!|ujhF(qKwvK($Yw}x-iuz
z%x!dWU;ofG&7IunHL{N$qDfxba_0>=i!&oz0lm$+QR=5^|FQ!8GjnVCm<MJ?D)h(u
z3=;mg`O%zpV05C6y$t$Azx89z1JLiw_#aFEL$Zdiu5@{$h!>aXT=<~juGj76-7N1q
zJ#`T8jq!7Fyb)#OAg_p<D|FoJP!SiV?*|x^7Op3ccO5FEF<@SW#YFq9d3ndn3@lXA
zgF`DV>s9FIl{lTlg@uax@B$v(Z{2(Tasvw$_Tc(nkBs5rXhQo{$b*HW3BTUL3J(``
z$63UMg^TL*#G&Id(!vE5c7+EE7xe2aCY)Fn(SC6cmZNM55AH@pqeq5uTQWO5G(v5+
zly?tU0*|C~h^IMu&>Meg|9)b+-q)(V*rklZ!$WY#TGoYyyQTG)b79%K<d!X;4Ib)}
zd#{3fFPAR)IJwfhALx?T*NO^{z-uKB7VeZ^M`aJ5tz+8XD%s(oj_JLs-o0Ep=CxnV
zzaQwBJD#gp4Vsu9n~jgFd$4T$dbJ13#+NmeFGj=!IKXS`8UqiH%x$Zt2M<%mA8#!m
z9xm?HQ`>_Fu;#(*7<l*rxBj{^cznjl(K-54&x7Y^x4s9@QGc{#jmo5&5Q6=F#<=h>
zSn(d~!qUP(zib0eCQTfkl%p>V4LqXnjXZdcJ~sB@;o=?+nt1RWeQ#>u;RjsYG?T>S
zky*nN28~V_$y9|4Ywp4f$gB5S7nWv#Zn^6uk$352fA)G8W{P>wws2wDpKU2LJ2-#_
zA3t#}JUm>*Wh)mJ7?NMMwTw54*6mLl_c}x!7uME=F*@G+qh~Q{eeHmGOzd69>viZc
z57u5`<}ts$8-V$Y?$*=6y$(I-!fte7=0UHnjxru$2<xFv?sfL(I=is!&vgM7>}OZK
z4n5}8-A!TUF~6VPfd%{7!@UkY==QUx3o{RTb@h_*P&3@m-tKkw=WcRg*`MnJEZEP!
zdL4SqtGl1V%wv8(`vVL1^Je!t^q||%0WQou=+$+L42AC5VYdPcf&BUtfVo^3p#4A@
z3N5lfn+Plf@}Ert7Wr(l4E4A@P+tnL$Y)c5MLwG*!v`gfU<x_R+V1!Uh2Yu8JvapC
zRN>Uj(A?(`A0Dp8!^uzs4^`vAhZ(r3#vk8sA0Ch@w?897@K8lAJUs+A6?yfKl*nOu
z@C*YFRpY@&8Mvv&?@y)&4-d<SXZi3@H9mZ_4>#4QT#xZ!fgyQqjy3R5B_8}X12>iU
zb&r#@5hGKE>(Q&OFlgQ5U04X@;$(sgOA7(D+(g!Jj7ZdDSu?{G`1Rf%zL)KpNnv=n
zGXI&$f{M*WPu}6e!|2ksr?{}d@claObZs=1!1k)-wd_;_OC1%0-Q~edF?Wp9e3)O%
zh28DJLJD2$yT`x+^-Xte2JH?Hw>!gw8IW7wOb?c3fLh-y*SE!sbt&M{>s|wkpyO;0
z?iKaNJjaKHiu&-m9z2`BGS9$5g}wIfli{4M8}y_-_<RG8u%!z;c$g@DoA>+haB;7m
z2RwLyU><y-frlS(@${hf6W75-iC_0aE-cKai`;8}cz&6Og*73g6VrITT|oVKZ7mMp
z%hB&g!uN9Yafu8GbjGXeQ4f}_e@i`BHheErKMmJ1G~MC%bGZ)>58JEvF&7>#uKcmW
zgN2Lwb*yyZf$sY7RX#lYfLHh93fFio)EN){ga;3U{d!h=@IV7z`8A4n<1YJU*ZQy!
zTlw%OU3i#g>%8kwF&*D}7nYrl8+=%(pkLoHhqe>a6V2M1<9bb8sSvH}gu@sE_rG`4
zw|4<9U!8Q4Q-|QzQrx{h<*;0e_kWn@e{eKz3fKRmgL=fZHRXSD)Q1dTpLWzQ3}2sd
z{7YUIY39p*cKk;IuwNX%TLIXwj{4kQUG<n_dY+V~=A(E;w|H+U(G!9EHB|vX9CLgo
zH>o)S^O@l13EVjxvMCeYYbSKpH)$6)2mBIe<7=LQ+^l=8XXWd)-anVm<P{R)c~xyn
zYVUOaMUfnW?$d;Iy57B3DIpkVf_t!@W0KsXmwkVfbHP1$XaCS|AFgxWZvAb&)oDsg
zPJ;C77{%)1)E*;8dS^E0HSiwB{CKpy%)s4O>Sns{bJ2Qq?%b`r&B$~X#JTTtQFwj>
z@4@?AcsHWL3K&?gOx8x~%2<!*FE{XbWf!k3xg)<`SjsO~$iP}bb05Z8)Lyw(@P-d7
z5`w`8K8*FYemM<Cy*92eur{1w?UySSg3*LegW>_0t`F9+lrXS%<J^6P3M*+~@!|S7
z1KVpi9$xpKEggboB2ZpmINRDQcY}tQ9;~c^byD-;!ODeTBL|uOl@GvTqP=nz46HLE
z=C^yLfpudMqd&Ha2G$ew`LId>m>F+n1M3A!{c=?TFjKCof%S`abw;(&b&Pv`Rp{E&
zDb>w&Crpyx&#Miri!nFem}-RKWZXRe;~E2t=k?A0^EJb;#Bn~XmVx<v>aw7JueK!g
z?cBKo5|$C7d7Ti9aL*raT@QxTh0E0o!NTS0doZLhTrN5U3zv)WU`S=STx<vyF4w?=
z^+bVD(Br>`VHgEHSR)VCIdNRLzQ!R~xV|PnY)E>zT+<LNT&|f1YcnDvT&{Tt7A|+K
z4;wjRNT@H@d9dE73kA9|bG=_~?C6Xku~ext(;@`R8WKxEg|!U9GO}VbhPbe}5G*Sz
zHp_#x3c<jO7WC=VIt=#;`|vg%96D#YB-FOrdaxUKZ!tac@Yv3Wd8Is9ya#i&83o<(
zv=6|{7;o@kZ53r&e+Tb6R+-Dl|BYc-mVtHjVai+v)+r1NmFw)ol(|f~E@4=xTvs2a
z%w@`T3&TR?y8AGfxqLm{BLJhIJJy~)Oqt8n*DDMQ)z{m=U@lYcrZ6m2u8$8><}&5_
zhGC&{{R~X`$nQ&kALcQa_r9i^O*xn=CBO><!tksVWgMRuZVAKv2Ru688i0Ebc<_WU
zTzM^IiwB0`%4;EbVi>Od3F(leFkGt-!IQ)Alu?25DPg!WdCDlCM^nRa5A2UCEezLj
zg~|^K!#%KHey|Vsg(B4dAwJv{3?J`94NL{YhYj;#o?v*i7#@Uy5|x7yJ`BNd+h~Cg
zmhSstQ}CS<;=3jA>g&*Zx7)V!SDEI3<B`#KGY@R$b<DiDo`<V`U1$!6nUty2Z|3+i
zxIcmW+2@uWnMN7o=LO4{d0sOIeGlcB6L;q&O&!tHr!$^20{65H?Sr{Di+g4bK(Kw!
zf3#(`dq1DMen4m2_4=l4YZ<fe31R*&+n$ho5qm<4M(hbG6W9}?`#*Hw#XQ<Df7tiX
zi{a(;nUK$`zN&t7pNW2SOvdM(&+`Va!E)g;j@<8#E8rJLh0oVkI_amC|4|(4vwF=8
zt~|)I1td=~h3onQ^V_k*zYFF$bNa^I_lL!I>(H(p?@<rEHa@;ntM)zJb((NnZuej<
z(}p*H?X_)L;r6UR+m;i6N1ZvXdm44^=@J*O9YXs@6!xeK>mAxdqOhedtZQf=iNcn-
zu>Q<7`OZ4LuJGl4o$gxat{JJBOgWAu&eE~x0X>ho_g%yhja+1Wml%8Ff5hWWtvdB~
zg|fG)-GzX&{*sp&)fu+edbYcPw^C_*RrjXE;bWM-XRU0n(3@ETH{!BAOx35azF41{
zMw`(z)weq8dK+CoQ<V>|n$uXzrNt92Uiz>;CJ!^)Vy_P1N#l`j5%tu%SbH(CO-+OR
zq(yIykG7{DKi+fOe9~`I>(VyY1=`d&q+2d^U1XdcSYoRSixc>fqfI}iblZF?Vw@WT
zZ4#s9sOKW>^)~JC!)?#tEuy|0<t~D^)@|Av1iL@oIt^YTXpw8#db!i1cZ1kgJ$kh2
z=OM>jQM;DU1?Q$jj`A1jcYL?*1{3a2gL@a(6|aEc(uaL_URyf?xOVBA%d@(+Tje-T
zAC>rw2C=RvxcdNG`LM<f!?4HQI^#2%Mu%Z*eHiTH0e#)zc1JqIH1?pbzEHi&+Y(GO
zE^LGQJgg8XSH&&YJKM9KtpjC&a+}>}A$tI})rGZAPBESI`=j<#*e9v);_-@mI?U^n
zpFjxI^R!ntB+blB9PiywTzT7-L1v)rcDHPN#wY`&P1Qd|C12j1+;j2o>ULK<{kQc`
z0pI>aVFPYOr|7xNt7s=T?WKN+_FL~`y;aq@^i_LMR9vN<o&uN+fo{3yU3k3i2z2u%
zs(+)TsQrTbyw)LtUG{C&#r3bQ8PawaxzD+t7?>yUXC7AJ54-Sg=2fL`pBB5Yup!ZM
zj{u93Hi>NHbj#><K53Vpn8ce+{jn*mpuY#!z*YhajnChgs<3D?W`A$0!n#Qh?=`*D
z*PQWkw41#PxcSQnjkia;HeGwPH9FTNsRwdp(fEInK7`7W@^9FW$SZrOU)z!#?*=uv
z{pYrHP1j!PC@@8Jy;Y3;nX->-T?c8}H+ez54*Nfs$;*^8eT{sk70>G@Tt2V7@(<<X
zD65}f`Gb@<KA4VM>oeo`<js*ofjSlDmeaES$CTG=-SzxB<&7__?|2A)v~Aa?<qV`Z
zDW}(-ynE-GUG4Lt)~PGlg71FTa<1PBUrvA?HtE!NsKfkWr*t!oZY&P3S~M@UbiD-f
zw<A(ndZs2Zy9D}o+&316Yl(~N*Q#5qw(e^PlQ~8yCZ<V}`u{F3cy6p|{Qptgx}Nqu
z#%$IIzt8Wg^x+sji`f&R(NKn`7SvF<@spbeHZXtRjhhEHFwCsRS#A#4z|_w`&J?ab
zp<gG4!i(wM9I#gwL*c>P{I3tA8TVN?_v^th6dnv(nffpk9?Z@8`sK{C>SOusx`x8^
z$IbbAWlcueZOhI3dT`Hx;Ab@^RxE^`P~QCzd>N^Y@7kktt6s_sY=ic-qz6MqFm659
zNyqNu(^ZRI*hrk3W%hKtICbHjhoq0m>X6PZ+aaUJyLfbQ>)z|e2I0^xw~sE4-Ft1=
zY@9)|{><st^bz)U`}lF7k3G8f?$WkHm-Y#ry9Pp9Pn!jA(PMo1Kz~E(I)2P>f4{if
z-w>S5!#-`@zJ}mzBzAS{Wjb=VKc5Er(+ySEp=XD#U9zJs1lE42FRf>-DPO9Osqe>D
z`|vsSum&>S?C1CNMM{$9=PP1^ZIs6slz}%Cs7}8Apvp6+jgB%p$LKwyqrT!fQ$}HL
z;nZj>AJ%n_d_$RfuB{i})`xXKB8!2w!E6v(Hv0h&yM6z^v&o9bBkuD${(onaO{}lu
zRb1*gJbc;m9d(87Ge-5_^uFiE*>c>y@08Sc(<lupLjzM@^?zjflY#maclt~SZ|s-&
zA#h*M1ko~j-^0BvKLzfmm&|$p4EN32X<ehO&w6`xyuG?q_n*K2VBkL(_zwpDgMt5G
z;6E7n4+j2&f&XCO|0@i1nrumlgCZ9;um|aaCGYZ{_Gwo+@@-*9x^A~*@KKQ?w>q-z
zQ(LxvZOd0JY{`0)_s*5zjIp<Exq-7#+df6!Z<-~a9C73%_n*4QmdkI{ci&pFaf>5=
z_M`s%oPEE9ed#?d8QX(>d>>h|J>8O9ci8e;TSrE%7P(`9ExQWZ@?kB`-M!706Blf`
zbG9QdTxCnMIQCF~!uxj8*mqXnk$Jz_vj0o==1e6H=x<45%aXl~nL8R~OWaaNp6_SL
z;~hn2PIIK*LiW_tpMFg^dpX&bspEOi4dws%#*$;RELp-V+OzA3B0Jbpj&Z)ZkN5d?
zVvQ^ld-XfpQhFUZJIj$7g>0G7+m;sxIdb43@Irg{9I)i?2P}D;IPj*8BFk^EWz7}j
z6%L5J`M4#|5;r_i)sfocEcx~~M+UrZ$+qWhnXC9}L;!U{q--)7p%IRB>SM{(D;&8D
z91JL7%j-{b7Tv41%>PE@k9oGpE>4A_u7lq@^5hn9dB~DgNtX1T%Rc9OL}DL>CU4sE
z`JW;uA0!h`-G9xnWKCa7-guN9ck?Y7u-caN2DZfSwxnVk@^$Zvbb8K_3D6?;4c<#R
z&X#D}?J?An1v4oN>~MX?{DR2lN|xLUji){<(ib`m-cOkyELlnW)1PB*Hc@2VCf0zx
z@5renM=EW0<iWdn_Yyc-RA1z)t(FuyX-kjRj+EbLiCvp=><51PoF(t{u;k^!@XHM9
zs$$8A%WU}uUYYqDIm&|M(2m<Ob_aO)llOUoldqZ0I69bf5G&g9^jY}!Am=E4=1Bi&
zN8WRo!&O?Iwq(k2k=c2fSvYP<(QTGo#XFgg9%i3#1Nf;9xL#vR?T<yCyH#X;Cb&Dr
z+P&{N8zMhvH@s`hlw!~_N#x57<mmd?(gZ%(_Zoc0_^wHH<o4ONjCc_Io`VM9@c0<s
z&HS4s8Rt2fW)k)AeCKPx9lZZeqAhQ~VM(DEY<cwtOZu&L<hxUxxem`cwEZ^qyj9+k
zCt5PDbn?#16LV}?2aRpw%ZE}eS=Y*zgK?Hz!L#RTThj8p$m1J$riCTF`*PL~xOnec
zOD61O|M(Y-ks0}!#Vx7)wIv&BI<jZ4C3%m)8-MYR(k&uw-nOLYU`L+KV@u-?MXrtI
zop*aIsjx((ZU;-Q><?e<6?qgq=Hp(u3CzWo<IIOYZJAaMdH7o7$15pQ$dPet9Qg{p
zkxAWm&atG!0!M~^V9T7H#LnrQ75%d%zrugV55RAYI8V2-Bj=ytoy?!WW2M3K3`ahg
zX3Hat>8Z7r9Gu5H`#AUDy7A-z>3iEx9hvi%B~vdzqe+~b3O=3~#dyKtz}e^zWaQ;G
zj2$_d1FsK$M`Q>3?DxZtbnGf}=Xpo|fLHUp$NH*s&=I{*@@o3`xh)xYa5CH?Tb}z6
z-m)#$8K8R}hTaD_TazSPzrV@%E<$&GD)Rp4oV9fiIHUegS8;awc?%|W<i2AfTj}S@
zs^n6KBOCj<2W~FV?`T#B%t+TWM{KFqi}97>9aFz>Rz?|HuKyMtSk{ss7DM-DmJ}$#
ze&^2_JNRw$J2L$U{Q5h2rdQB6@ctLn2ioOEaN7Z$`1>u694iISe`d)en~}5Kj(oV(
zmg-kpQsY@$4z=aoJJl>1#@LQ0(AOI1MELgLP?42e9r+=FbssNTvh*iQTJPqpjrTk~
zFdDtRdZQ(akJ-|q4|IYLJ_8qbY!dk!+c5h+N3MHD<iwMXwEhZyWddORTjb*JwdLNT
zwwy)I&Xhv8L+8T>L|$*r`P?&@>v)g63AUlzPUPlCN3NW1%K~J)+RNxAXfg$!{TjTU
zrH&7QZJ^!{us!d7BJw2TX;uaL|AHRqWXsUymOQgxabronnU)Ot(30}VQDz1@Y9QYZ
z@5)%nzU&7bdAE@x_YUE;IfrZ+4UbQUchb?(clUMV3v_o8bj)SYC#pL-8h#nZ!>gc4
zjSlQpKLT!kA<I|Qk~g<t8z$N^q$7GCncv6f7Ib69XDqq=3R_km6nW_m@=J3qX*kr8
z?*}rD6WA*byqNwhc>2PY(?vL^>u+1mFU9^Gb0n!I`e6#ZT>u$qiLAmmw|9aM(2uPj
zV$KhFKH3-?HpG&@kfG)u@a~jrZFyo5dMVzPB=A&p7(88{{9p$A+xv*Dfd6V92Op=%
zN4;#xmPC=-@R~en$&P~XVMSYx!9xSfW6#h>^;<b|D`#8msBFtspTW0JGpF^lBhNg@
zc`TK{2ed!+jV0?_qFejg{I=zn0ld@fI!995*s}L1^lgbOzU;`^yTLPdy*|8Bbv<&i
z3f{*S6vRG{#J-dPzprBN3YD?swJXW}(Z9XejUjiU`=Q5MuUWDa`i(8inYrNX$(7iu
z-;oI$Jp(U{#0I_xt{0Gl+xZ(4Ci&6fO~C<n<!Sij6ufrF7-o9Ex8#c!j@*I#eQ`Z9
zSI&~j6`A{ipKCFZI`}H=*Bu=F0v+bvjShVby1}E5egkjQ-+JiIUeg_^j9xo_mn{cw
zvgHG4+qe;S<yuE3(bqAh9qH50k%h>9@*?&Fz~3))<Gi9B*sa?vsq+`IN52=&vgP?}
z9C;r-SLHY4{ua)GroN_UdB4_rY$bGgydnKT{<>}Eq*eGJZIUgmPcT;rzbDT`UoocV
z;GHV3k?%wYAHc3h*Wj6nB9$88i!4XC*R|xnw`}QykMQYMbT59v<wY1*5;h*0RsEC<
zuUyDP$7AbWUFFD)jqw#8w&X#4s<P|g%{`7Z6H9jEcb&$r>_RvG@iX;d*Oud3z2;bQ
z3LQ19ruSaenJKnpR=~b*!3HJr{@qyQza)AqN~B?3&TRb)pYCt`fZH5tz8GDDUp5$-
zyR0#G79Bh<pCuj9L**{Fq&mLei&Nnze5vkF+hU`eYNR=G19)g$2R{l~yYVeY=7O(k
zw_9@mAxpBVao)rS&=7rH=yOMI`vct#{0-`Biasok-1KSAd!pdIE63SVmb%jJu%th7
z^Dw&emuuhwbkfZE*f4bCTku%l`%&xPA{V7ZK1Z(<!$)1STVyfxEjgNf^5~rz@N0qT
z;B5ywm~nnbpUNyp=Rv#jLoG=G2koKr@5k{C$KZcp*RMy9oE&Y*+`{n2RGw=|J?NUz
zU(;X4TCS}vHSsNq<+G*VUe10_64^E%9X<mep{pZzT@ZPBvn>^Ni4?;2pTm#I;MuwK
zyA3pmg-+8c(|V*WGk%0$Yhv3@J5pyn`(AEmo|Cd?ensZDSW*cc+oik65Af3nWP2TS
z9o+<9_6#RBP%dwNOOoH@eIuQbw|&TLJocS(I~iBaw{6*%Y{{6f@T>3Sd?{pW-9+k!
z?>>%ZZ~S&>n`VoJj{o~Qk-hj<Rgd5&e#>6E73keh(a$#e1{o_wzskN3?x07RAHmOk
z_)=}~6BBL8ztffn;PX-FidPaXX-{7-Jn6{Zy|%2NjsBVNM;3k-beUMkmK*U)$G-!A
z(RQDPBJ<Bf+s4@JVeoZrTRLBhKX%5EU!d13%h0jk@Sbwyq%qH411)OphSp`kFa6lL
z&6XX%qVwqJ&*+(LCE#c1^H2#(N|)i>c63c^Wct`RVxroX96|0!H@Boax~bU|Thg$F
z`F=+yjO6?f?DQSI9jSboE%gRC5)WS;&x?LVzwKy^zx2E%wU?vI@h>u};?Lr*?tBOO
zypK)Ei)}=|b$c7Vifp(2j`PzPbKCLY9Qp762R>IdhxchYl8E29zPc^FuD4}rEOdtt
zroi8gu~V)3B5U7^^xlY#frh`(mtDO@o<{$)EsKu1-IkRH9QnDrBfWRw8-EEd!P6Z2
zRiOZK2M>4Oi|xb)T#KAl?1&GB?RfnFb`iYZ%ox|hD+SPd@$I0&v&h?2OY$IdPoKr7
z-@#lZG^p@6aRGW|_|>e1tc;$yg1*0tPjJwY2hgYS)KzgXelB`&^v%SaQ#C%sc4Bv<
zC?8$Kks1?`>+;yxjkY{K93I0SHll39D9!@He!Q{UmPN&}3GwjiKI}$AaPc5^yS*iw
zPr+k+R$wPTt3n&#px%q<!aqcsU<-bl&3huQLk~g24yCd0@8SQTt8T<ESvtd#KQF^~
zNONSt0%WeK$e-BycG2(+e0Fvl@h$zYy405YJ7W88!_O{@4-Y?W=nswWLSE48OGjDq
z{R{ByJai8FXz>*E@p^3GNmg~@TTWQYy<W)r^Tb@kD37h^ew_XFYtUJb;7>Ov*8EGP
z{4`<@WTDfCjtqPl9g004j{a)bMr6x&N9KP)oe#pp=;%3&VPSpzx~=&54e&?ifP*uZ
z#QngzJIL~YEPUPjE%^q!+XY^l)(*adrilX?Yd`EdvT$?_`<Rf|Kj>3Dw2nn4$DhV7
zq>wYfSKAd$Ucf>>K0{nL3EpT!eAa~67Co~F+j%qk-}w`rIU7GI)|Mp?(WgO{d_E0b
zhR@psd;Br7dyqahstQfumHk`r-{85sCn0n9ifo$6SukgLhsJG=OfQTKx3Z+uW5nw4
zec#I+Inx9?wwE=hKOk!bMfPK}@`2-z=>MQN<Ow^y0e!L(nJu~zUlX3W@;Pi&AxA1h
zk8aOl*EiF*FGbcy5vvb?epRp;XDwOX%8_-&$&+B4>Sj1{IXYn*_Vn?qh$pvme=Ifw
znfR%Uu>2Fdj+|7vK)lEpy4^@y=ZWcB;#a~K?*M<lD)u4Sk)HEx>DeFoC}_!(XYkc-
zpbYwJ<YSJkJ^+oe#Vtyrx1j4fX!Jl0k%LRn)knyOJb<29fPJ~zmXF@RuLt)-OYvC+
z%|F9#-ek#T_%J8%g{pOfZzf~g(urU2O)_gCGti?wviChYqy;vt%`3#G_yVsY^Ci$X
z-J>}J{uPl&ron&MvdMF?XV{RU$XMyF$i+%aCW7aTWB4EU!IQN80{r=0ALxqy$-fIe
zS-_dp3-H15nU=%fQ?a4jmf&A(#}E4my}QJc>yeic2Ssj8<xIm_j?}ybTY^n!3U4mj
z@5p0^@q5s3yKCZ4{e%t%zwH_CjmX6Se36$LsEu)?ZZl$YY*)uA#7EfCJ6|Oia16N_
ziysY-uApBZK55I*heX=Vfz|_T*(u0w3UM|xZFo63A@t$+M(F2r_}lRN1NDi;UdOkB
zhIidY{PP{<3yVBYuAwh7yQKnS$1c1+*^=hZ5?7HgYTU+=-yg)5-Gq!IqYZoV{7cB$
zX=MAjB_F}}t9zpV3z5TGiyZ^c&w<NB#2ZJ3LSy3p&)~l*S2JIJ0YB~&Y~G{jqVnX0
zN>c83k!P>ut-bF%GMUePapWeTkB$6v&rfa+*?e;Zes(wb^Hcn-*~CuZpjHy`ajGNN
z;!~W@00+I$7s$%4LW~E0rPX3bc8<sQ`j9+b17g`2^fLCdQW;xb$s)fOhre+Wzp)rR
zUfq$xui5fzZG4?G@E>F8v0CJ}wygH6$2@vzTUr$nnLC;oFbUagMC|b{e!~dPE8B<7
z0Kbh>ZMmZ-aS}LA{SkaUC9?2u+9^uzZ8?74^TfRa$W>J#KZX2WNG7j_j(shkNS(p-
z9U4A3kDMI#J8q>dz3;|fX=2Oxr;v#WI2nBz1Nyq~&ESdH|JM!hGJKLBe^O)Xrj3Z@
z;J?n;mEXGC((-on3F8@e4juV3vRIRR#1rs$HTW?vbqpb%KnJvE?4v($<O%f3cfTUP
zdB}g!$2$4Qg+9YRYUF7ndU6xCpf)(Uxu3`(?k!zMAJ^hnCfl;@O>|yf-v7A?-()hm
zh!^k&A0+-uwIu&)OCF+)1&4SR9)A}3t$hnI$!El{O^Fv0D1VJ5FM+e-$n8A%@=s{8
z0$$IvTiiVB^~l1ZZP+z<?l|{nZNWEZ%&W)K_qT}I-Xtb?n|B8PPMnwtuj6~aN4YJ?
z_VlB+YzJ2pz~egf#6$4Xpl|TaKelD^ox}rQVF&P4EC+nS1GmthtH(Lgqcgc(`1Zx`
z;dk(K=R9=z8Sw6~h6SC{2R-oC9`dvW@N>}X$KJ(H!jEgv-jaf|Ecp!{Tv*DHr_P8x
zj2(Oh-EuiP`Ng*A{l{$?MLhf=ba;Ii{J4NvEYp!jd2IO&pQyq{{QrB2{l1~E$YC$+
zOM~8yw81_XuZ+F8o7m<}V%vVU48&LK$Fohoflg!bIsRh5D*Si@{PkLGev`B5i9A<@
z4<_LwOj|)b^$B{1daHDRX4Ba#-I}u*u`jyDX9m7by~&R3vMo1Plky6FAoW##j{I_7
zd?xt&sZ+MhBKPttHe=a3OG;wnx}C=d--)g2?8tWf;?u~;1b&ZVEYH14yi5I0pl7P1
z_qu$7zu68MXMAPn+wv$r#eMjNuQ!Aj#*+^|g}rSE-+XDyIb^%qUiH1uiFcwmx>NTA
zbWeYBj^OX~JLu?U_+OpKoucDj{ec(;9&`BJ_j$&3g8t%9^aEe3;oFgmc=ynL<SGW<
ze+d1@=gu1~nS@>3+tre-$1J%Sdh|Nz$X|nOd4HrMWsu8r;N~Ts>oE#Bm`4l&tyjMe
zUtrH`JjFGBxSV3oIc4XgZ?@k>EM9}y1OG1>J5cUw_^>$Ry3>;9#_?_xbXlpQ<n^MU
z3o=qBhJLQWhlbA{pGbZk9rro<?7C^lEcR}_g$x!V?f}QLx7+dweqj;fguImRd=Q@m
z9kUzX@HX22sSfeiaA0L^*<F$L(2Wnh1Kx|-@&a+xEtE;ThCKWV>^!>mQFK@5?~!$M
z^%8u59go`bBYZs){a%7NaQ|}hlHje!Rn)%>IioM{zKOlcuw>vvj+EXn@^c$Y<~(7`
zl~0p1d%}@5pWAX0UhZ&@EhWL*+57QRr=qLC(TlVd^CJ18kFY5d=>G}u`Yry~UC<9b
zGWkbj@Gy3D2Yv~<U?St{)|?#5H@wqv8}U*+ei}aA8~6*ip(josLXNTFgFDmjh2ZWP
z?93dId-~x2qW3G`gUlY)yr?5DU57sHN(>awT+B=Km2teEgxqY!r_PV;;xFBVPR;s@
zTxM(HKkz-{0ygCZa#gFaVfaLU&W9#X;s+zUf5kE$o3~8i%N@g>Pltc2-j9!h?=z<~
zeh&I&-{0hke<nx#wIgr#B)<KL{8Iw{(s`80L`(LZa%3~|-l8*l?>2IfZOC(eD^j|O
zEt`?w!h4_}xzirYnFl~_P9c*!u0&SeCO&|tE2EUYpN0Kdi+mvq4;&}f+k&5uPcVlu
z)r%)S5_Iq*&=HyW1o|z2KI3`ru}#Dz$m{pd5$Aqv$&dTs9r$e*Ix2mpBQIYMzR)*Y
zq3PG~TC<JB2=H*<SIPIn+Y@_WM=gA$$FS#&YfpXV6R=xrIxzN?wtR~}@eO<&OB^;A
zdp>5pC7+?oUV8xkBA)wjH}+r_a`X}U;B|bTQTTIzlNbGpF@H_2q&|KRdcN9g_((Tm
z?~da0uE!6}6#1etcJ%;b0gb)T1I6({x9-9BdyyO>{&S;V_>sgiUtnLaK=<{YLT;G8
zoVdo8DrFgWJ@gNB=vsxjH1z83qsZ}fI=4rj1RYcZ8`Ez-a~La_S9yor)IG!w3()iD
z!QE7Nv^VdKT#XE)U+c|>7tzNpo+bY81)nv+4}?z-cE=8(yGkFV&Rel3*vBONw|ad<
zGMf`e4npr>OBWA-Hy&f01#J1A7$_M&e}#BrT|N8&{G_+R+w$A+`Qw<kcm-bsUVHcm
zIoUJ3UmzOa2pT=U%$D{yqxXr+doCmn`U2jX%(_0>?ts4Q(*Qm>jJ)t{^S_XXENn8m
zaS3C;<7sT=YFj2%vgFzd=o0kc2iIad7UM(LCypW?y7?#ON;cyzMRP*t1xu_v<PG83
zZ(F1DHxTndt0%rAXNsN~Q=ORYd1CbP%x{c?4kz)W)?sVgG4F#9_Wox46vne)0z8B5
z%8$&}1iz=C=WpP(;}Y!6yX3^$+wv!MZ$OSdjj`pi+tF*-!=8K5$>^h3;GMVg(RXy?
zAnf&&Gb-2U^q0w-gS%$n`9No4Dfp)BAm(1P&|%2o#ESThZ`sln9x9Cw_6$03(M)KE
z?01}jkIwkdk#Fv@nY<vM605Lb(Zpf9k?Rl1v%p_(mcW*vTRQW5)hcXAEBGG%FLfH4
zUxoc7R?YZ<oc2lL{f*>!ldw0??-BIhf&KVM_=HivF-MF2%z{>H!ShCBwjH!w2#ziv
z3@v)#Zz5a$@}f7eNokFl_d=J}TTCq8mwf+J@_7Zx4Xwn7ZowGa+44KQd+2ZSn6#Cr
zJo*A%I&TGf2%G!}Ix}fG{_6e2u;70=`u<kRNd<JxMB<>X=zHwNFUioe8u=CU?$&4U
z@3x}Tr*mFBK3f#N^X^y4aWud#fzJ#5pyd?C53YYB?w$t^KeZIQxdA(j{P(?rIXdiq
z)@gF>HSif|_r~t{n3to|N0EcRgZb>Mg$Fq!pfqO$!@phLCBK4?@#jPE+;n^&^u^Sf
z<ft<6fxDoak?CLKZMn4|{MHG%?k3V;AnWf76Ca?E``<v^v4gl{F6HKs8@d;~!RIf4
zvqjaIuVUQYpR{Gr+xS!Tw;TS$$))&B+tC~7lOD^_Nw1M>84ljwKwh4PSHbzc3CsaP
z?@5h`@9rdKJ%c}g8F`x{_@KX#2SmRweGHyENh~vg`C;PU(btRIHwQnhB=YwcyfTJ-
zCbY;q)7yL7CdTt)df!4n@SRifA(w-jyP;)G?AgJ4Ex8LH;t$#_R~)&;eiebo&R0bD
z7sU@JE*VeXi-G6HiRioUumi~bLgek_{mh>=LMA%kYnH>F-{;6@=;Hi6$*nBHHw9<C
zv6aWD_x54X3wzdKqa&{%7cFWMGZwO?(r)r@==N{XGf$xhek6WNVy>b5X>`e7=yv#R
z{~6AEg-0I+&$ka`oPRR57LGKy3qN5mdSMj$yDqqdPwv4lnnK+llS61nUDF2P7lW59
z?EI5a#G+j9>V$p8e>(yl-=Uu51m>_xk&~kz&z;70VvmP{qoYsYx94Z>09pQFH93m)
z_%QI%9q94_bFtgx4z79Ek~n<43+T0ePoQhw#^3%BU5<Pf>_EM-(4rW91)q<uMkoG)
zj|5L1M&BLXjz0+9Uc8c6>KM5)<ie?KN!LG##phBtc$kMx_>MaM{)4&Jq2yDZBBuWV
zJBA&qx|&?c4*Z6<!4-Y{kb89>v1C+P@-bV<l@MRNj9sWc3SVz6JerAKXUwZA;j7(-
ze-8dWtz}DcUu?sz<o`?IFC&vJ-p8hQ0PhWm1C~%H;~qO3zQIoYQ4`;^BJ-#ZJMuI>
z(7+0msbR}n?8?e!;1vD0u{*iM_RLpdCnn#7J()->g>ATNF}(3Ta}X7&FA3eTjXAxM
ztRH~J1(EX|W8gXXvd0wUt2z1{Jvr@4=2q~#leqr}dhVM|ysZhnw7xzY2R=ZS;K#Dm
zc@SB79y*u&guE&8Q1*65e!>Tu^)oRr^!_!)mdXQ&1K`sGSMn}VXqcaNj=hY{ev>sN
z$o{=g;hQZ(pQ6V;#dh^YuT38;a=s>Xxs1NuCsMo$ssuTVqOLXN(P^La{Oio=Fpgoj
z*fQ}h=5uDl^E;VCI>#E66icrAmG~Q9t3R@P4jg{A8(Q3qjY!51D}nyUe#CtbKcV}d
zUV;umM=!k<`*I`xA2x0W{8R^<rSZ_>->~cJ@iFrvE6CHK2FP!3aupY72O1WFmmheO
zT+-*n;rM;K$0Hl}5Ce_i9Ojp4`z(CInC|a`P27deLl&QXp1Fii$(7YZX7GbvM2Fr1
zPn=00CM%BL2p^Sjpw%_l)@_cgML#F^#NT>IeI(+;60}nn9r`8vEf~|EThI;Yga+W@
z(Wd0V;OU<j+bjp4J;Rb4@Rur|!WMPJuPn{H{0q<xTQs)-zU+E(Qt;uH&cue`D;4|w
zH+GywNfL*?tVzE{GM+KW%kzc79s2qa_^cuQxcLV19+fQFRL_?Cuyq&c`}NqqyJy35
z_&JZ=hn<7RswAQ}iBVE{?!Dv88H}~${S^E$Y-k>6`6NEaQt&q(TfGn2Is?vDqSxC$
zhfH0Kp6E*s=6+(x-sqDX@S~vhl3DQWL3{yhLb(`pFuYUxEaL^A`Jw%{jPp=Sa(WY)
zM{CGD(2Lj-Xge1Byod3w>_WV6<Co%NrJW+b1peL_Mt(gVd$@&u&tqQg9J>4m&lehu
zE<VP13c&N#ux0ttubQ_zK1}Bv`Hek#^&R}3uZS65LeJb!dHDV&bV*nIgOC5hH-t~(
z8Ix3phTZ7rdz763U9nNCKBJHDZ)xyap+7l}amXFG{vP~J?#R3|{&SP}@B^W7OgU)Z
zA0K=qb_yN0sWx=2z??rce7g-f=}E+?U*hLZB_==*b*PH$7GgaUc;568_}oOU7QT9x
z{*Hy_-`&ahu{poBCf|at*oloe^a*@&gy+_Pw=3vJ9o9X-KYgKJ%`)U$uor{h0O#AW
zql>VO#1c=Ut5$-)pDu8ASw-|Oc&>)LJjgh=g1_$Puw}c@iLar5*Wydy!<}vb|KABe
zbfymM@PWO=iSXSX^lEYR?#yoZD}N)4)8TD&UUlT)R{V>aXGI1!BQFYHe=r)G-kLd*
zXy^{_2>0*8XVQ0){4$(*x((P_WVihl_@3CQDi%C_0v~}`cKqMS?Lc&8HGElYNh6-$
z4zJBYSB-}6ey&BX9^LR{0(S6ce5o$jjpxa)JWHF<X>TU-Rg`&+2Uw3-6n`uo*#s9|
znqzyh@mbKVBX+w7{FwM8ZOn(ih<R!tFRj}^_`>)b_YnWoLQb^YEMok&@CbBiSqwjn
zII!1d?BQJUS+_%*>dYa5-?Dd+Tj<Ag<5<tKkNiUh>j{dG7u0bc!;ig>F{0NRtVCaZ
zg-%VzpIOZO&ujQ1&7gN4^f>zT9_ly>4N5)$jrTG~NX&EdBINQN@(Ls1ZDeF3_Gcxy
zs#^uS@-+1LidY<;7&Mc38{7Bv-{g0Z*H7+%7w3|j1&8_4@I~^Wr|IjOlGwnXnQOip
zAHObfwGGWb<^B<P5!^kp9Nzg6Uza$k`sd6Ap#P>80k<Dv&!GK&cz)9_#OV)^i)n(6
z7{xlmRO047_}=d`C&5@QLndCt_u2FcJc}Lsq#g3a*e22EHn*bZ(K(0qpr2--=kXDT
zF1IDI0I|+?ay6^4E$Fym*j$|(T8)i=s|;%f;hVn10{f!yrCz4*^r!e|eD-3S!NL8%
zBU=lI@sNkKw)h>NLa$}``X}f+x^8Vg_<SDz=`{2{x}f_9=!E(BR^4r>wU~GTJvO8?
zb11-Gf_LBOF0yPkxgzLxvIz4-$gAu}pANxyg>TdDhR1hMZVCE=agHs3-`JnHu?N0u
zePr===5XM#{@0Q_X@@OsKrRJ&8Wv|uf$g?*Y{7g2bh*18`H>CC5q<ce7x`Q2OMMI3
zQXPLe`GQBWr3df{;qeoR<VVj~^6GKc!t7*C9{OQlCvXE!7F328EOdJo^ELRTvHQp&
zpm$bO!KSpZr1ECw=-y;L4!N<Q$)S(2_ruA%R$yG;5dS`izuT2H6VEZ$=iwpvv+iBw
z_K<`2U74RiAC~MZau{2;6+TSH&zXqae6)bIe2tjLY>wZ7e>!j#_Nxtk&9(S2=-+S9
zg*UeWzwngZnR#65{DOPWF0f=EZEQroW_^xrzaHQ7IsCjS_$Z$d`$Nxrx8R3h8w>r!
zd^bM$y&ofsb?{#q^RMNw^}7(+2l3-*=lDSKlKh?zem?GsKX)@e^GS3LbefNk`W-wt
zkNB(7v&c!JE%o7n;g6Ej`HE+#=Qwh!d5f4O#E<dNx2MKn_<#5aQEAwQ>CAmU!#b8i
z$nzl9-C!eL8jnsy?m8AB|C4~ffDSzOJ8N&iWApFuOI~Nr^DTVE=IGE4_^#Km9_~X+
zM%IEq24kb}Kih(<)k}HD26$Q1obmH~w`;M%kK@}jo_@*1!Vl4>srUr6F&Cce4nG#(
z$=n$Do_G~<c@=zp62D-Z$bdfR$y>;&A|JQEgl~f#-rkqkXg&TUF~;G=$oS>hffRDm
zwEY8Zv>A_#{RThOL4K>_bHYm%(0!G_<*F&<E~>IVD+YT9k50nY&$^O%5ahqXB3ml2
zMAqI#?uaLg)1T+p!G!4g{BPh7;kS4C5j_E~<^2<XqXRKK@>moZxrH%|{RX`WZ=4;1
zjsac@*?h1Eb42JEU6=LR31V89dO5bPXlZQdE96ztX(gY4w)hiyV)2U)GVg*7SqvXe
zUd}x0Oy(2TqE|BbZi6g*fZv91sIqwG4O^CNqu(EpYn$ZAF#Mekldzo|XtNnU2Dsn4
zmplY`eCi7Fg4LNDdX#nH;9)&7_|SH2(KO_JDD5A`_gTprg*@nEa8n6+{^$=>goAt(
zWM1-je2F`;O`FIu!56>5$GgsekKb5tfE+dZ34X<I*fxwc3e{MvNd2?wF!wST`OM4Q
zA~xq#50N<dx^)wL3~a)C@buZ$_y{9em-#jM6Z{toeK+-cc;YxQExNjYQ*cK=N|itd
zKLw7!{R<Omld-%$0Gs+GYXIlNf7r(|$a?+N*oCs_s2i9AhQC`OXU)C^ukg&IEOvsU
zpUbXC?0RAIcQap-j~J;KF&R7{hw-7{{|oui18dP~*n&Lo;z#dceji<UW&}B3{Gw$W
z@ePLK=Z!!P??g7U(3|{T4efq>MAz%02clWu2yKR4&fFyWZ%=*fGk$3vcyctn*s30V
ze}lPd?8m#b@iH=7<N~^52f5WZSu0eM^^W)kkIf=KjU69IeNn_0=fTk+`2LgY@%@nD
zCh$}he4#$*tSPkBmptK!4#?aVbok@=AlHyjTEV<n8n_vY-u;=FCokn_<6-!=6gs>9
z9&`h8`3C)Hfi3zI9F3qKpJ4Y-d`O?VfqVR?nQO>*p~o`bMUJB^`SLFEcJ0W)yiJT$
z8vAw!Iujk5(3-J;gNNb6wv4gojo75p$Pe~r(X-$znRRtj!PC#oRh)(9Yw(+q|I-W6
zq4f3gtI5k@JFcq52Yh$Bh1eJPTlD)q_^t)|de$%aOyKLY_V^|bv+idCbGi63-QPin
zfxESgFTFBr3lmg+dH2^`;#KIg5uI}$om}7^^1)T{@5iH)Z^mcZ!F)_AyuFz<yYzi1
zG0MmH;csGF_8_Nc2I6boi(K7l%a_=hU*MND=-*d%!GBeeMfhk>S$JhE^Wep?5yY}T
zBNro{A<h^A?|h9-!gt^KE%$yPr*<9s=M(bLw7(0Ty$wEJjUBP!<AXDhr*f=CLyxZP
zgbqXgHlsh+5FfN<{H2LQC!s@cc@i8#-yO)w_t^dZAEAHmwdI+m_&V71g7Dmq?u_9k
ze1_HJ5zs?L(VuV8W*&6;?ib00CF0ZkL{9o6aJd!y%|VY=LcXCz*GbsikI0Sv;lNz@
zD$|(jyoL2>=z_;vlCQWy=Ptl&L)NV=WBz(6w!AF9J-B@28v6SZYxvL)QRpU(xkiHf
z$G~gZHssH#@@wovtyTDs@L6~C_blxEh9;CFo<6bw9{Y|pjSa|4O~wZU#}8hEts6(a
z3fo+9IP;{b?74yenol8408fRk#pgr*8bGgM(8cDn^Dt|-&cVmUnM-|!JnLZW7Gr()
zW^@30ZXtT<&_H6$1?({(Ch87<zlg2d-H{wB^0oF0)Iuit$WNIA>d5-ZGWg-}q#nA~
z8lPk;eeOekX)(Ah_A&d39%W7VJ<KZ|CNINtv*GnM#19<)AlI#Or1FRGII>g<{m~hp
zH5&O^fi1l`j`j9c;1TrM-gxG?su738*b)PNcGd^4Gng}&k8Of4($5oP^@SIA;17e}
zEf0{3EQEc9rql43${cm%$Dzza>?OyC-Kn-1UP!{X#UH6y34Al=V?|kGbOZ4R{$br#
z%+VAR>G%o0Vmk5EB53rEpqSBz@zDEm=3c6xw{|fn!5B7SBj29I-1Q7{LvzqQ*r%ig
z#6*807sm*Z((noQ!Kdf2N!Z)P>%gtXw9By}#jtB{v91W7IJpnqwuzi9w)_h0YTd8M
ztL{f8@MqTUWzQ0NVf*LE!N<%OSH<>BL|?aHZNwM!_bmQtSMn<>kR|kdiF)`t^Uyul
zBKLW)$MAnIe43i@;iTR8>ZteH8Q>XOoP~$G!}qrqW*rXts19<nd=GN)H#xoe#8T+9
zy|0lMd5kr@@Po6Qxi#$4J;Yyc!Al!wvlh?6pM9D9*n8l2A!E%XrW-*FgHGD@89Edk
zwr4y?p=ZM1_>I(8q&B*JCGrRk_e1ljP1xj4*lu{`D)?yxda5b%+&&6kE=XSdBryp3
zy*IR70-kP+XD$U>pzDesoK9}OCVD!~mYL|wTYezs=mAciB6qX}`GBv^9RM%*Et$w^
zpDoO@?Ir*C3qHYCay`VRb59`K#M~KIz`M_(v!B9$-vocQBL=TStcERbaX)hyHOP@3
zVor*&biR#TCieUx#=L$DV{eM@jV|7bOzt_yToAZxUxD0BS=PnDx5eYZGxljQx^h7~
z=1RV$pGS!UULcNx|KbaY{Q4CBbXRiv^!wYL=$I>6zlt6^0gX@fBS$e!ByK8t_B8oC
z_~&RMx$`&B!wZ;WzlYfJQPw_;BHs%iwSO3$_Xu<97nrY`tm}aBC-8F)qnm$C!ao^}
zu4G)53K0_ywWTuSSa3J~6ytjH3~Le4*O#N;W<#ezrC9GmKZ=0A8Sv}$y7(MC^E$ZQ
z{2T43!y9AJ+3->vGBT(=c7_<UZWrv)4&sbQSYMr=F^yrZ3_A2=e%AhuL|;D7y0P8Z
zWcZ{bxc{jmx&r=q`wY{(=!C&DpdtN=Uy9AWlXXJ)zY}(nhsj6o7db8hkF5KYb@ffL
zhd1DxjmOUIC5KEK@l#nJ`x5K1V~G{85BDMShrsRE(0v5De_Ua7U}<dZ8Fbt0_-ObH
zC$L@jb|b$IEq_=>e(^G5@ZQ8{#HhWX*Qg@M`;W|}4Il@8iuGW7h<jec)-)sEcpp0H
zRmQN4*pj-p5Q{Iw-|r5uA1X@wjQ3UOvl1P?upaxs)(}G?+xZw*qY>D*tH^OAAcF_U
z+eYCRoJU{2fc~QHvx6)t4DO0Qgk4xjUifEhC-$KMbUxmnena~`=!l00kZ&sN$ZYz!
z<OzJ4GWbR4<uVn~r-$($@v$b(WxrGx>@@w{UXT!RC~F4y<Hups)+3*HVYg2X70J4q
zd^GabH-lIKAH8mU<|FX~HC~=x9{UN7Ru&_!&m^9}&h`F=y=?W-m9shHma_9^q3h6n
zuNQ%j?!}%kw)5DLbNjHZ=<{n%qti~{ckILlp*ts`r|KY!YoOiazVL1_^6^ihD}Eq<
zpAUV`v+>xAZj5Oa@xZ}bnUCnr8jVThg6Z>C@VKxgxz;zC6M^2kPwsc*=)_EXQpVnz
zHd0EWV}RSxV+Z(6-NPF4RQ#>;#3As+JJ{jsRnYBSkrC=jdy*XMm-ww+vBlVc%UYvr
zKE;RsliU;f?ayW8(6iu?58(g5!8v@qleYI4AWsX<uWL%*g<SE?_$M3i%N}EXF%}ub
zPHcLGShqR6-;1@Jv>A^dKAFBgfStLwJ9|>$tLXbc=K%CRy5Krw;3#_PgHiBR9C;pe
z^qi~6xdAJVfBn`x=Dn#aKQYi(FClO6@>zIy*;Hbkn!2AC9fK~o;#K0C&GhpaK5sSR
zJ>sG0U$F;cnD3dx905F18Qph7IpW_G*5EScD#&DMe8~-&<mm9Nrmn`HhUb=m)0$UM
z*F^ln;k5S){sFY<{W&?pruYJ_zy);IJblJP#G2GU96jC$U7h$DzBjy-G>`sHz<)W0
zAKQR6l#Hc#E#`t=A}2Zs8}}eF2)r<+4sl~aYz8`WR(|}aDa_$*z;-O6-ND3K9m&;}
zWnT3o)@7r=k3rihoya}kLYxFnAI3ht0e+U9W=<1Xjw3ehkr!E9#9DB4#2t*e<-6Df
zbnNZu$~uRL{Wh_u7a1(Q7e8<@_oImAe`L;ZIe9qz>dWa<*?HtD(LqyzwZ%4U!X}>{
zj}M&(o5Hw;96|PoFSbC#{7Jlf4f%f<-TC23*1CQJzFuQ}{k4o~E4i-i#1+V5O=P|+
zwrAM&tmnI*eMt8~m%GSC+#xcsI(wA*K^yGm=QYS1Ad7FHV{G(8qc+4tJ;?)(BKHRF
zR}eE#sY5?f@x`9Nc2{8S6+XZ`WOl_D@Mt_^I6#}o#6a*gxdi>^ck0LZE-iTu->4OQ
z(_<Rz1EKM<^TY_<i2W9D#xwkJExb6}LI<ov_x*s6+z>um2tA+0MxvWC;rCejJmENN
zy1{)z?EKyo@>bBUT@t+fI(gbR(L3{)JHDLU1hh~83!1N{o@2-uG<j(^YklD7=+@*O
zQoVe7yC={~_yN^Vv7RU&{E7Ts`7$|OaJVmpoYic6$8F?cu&u9GN4C%_<!R@o71VJM
zJqrE~JcqA?k25?<=c4hCDxf#|BKz0VHop9C4J?V9j{W|HH8=0$zwo^W+UR=R!<Dd~
zmC&z`;-@ttzsLO*w}bE3&^!Clo8aP`5Ao4oWgP-Kdo_IiNKMv1w<1o0XKSNR-gj8@
z@Hsqw6d&tq@;%7IvO?sC9O!xleoJd`18t9FqQ~l@*PwL^{PtIV!)F0U!@%>FN%(r?
zAihOs_Nzf(@zbt{SLS!q^_AGRnfN8c$g?1Wi#}mJNIh~{wZU64Y_fw4<HHrjE`Rhb
z^FrgXkLZgPbIIK!Ul;HZPgEz5v=Ti%*pkZi_}t1qH^y=PG<q))UDX#l^L_3d^G@{N
z!PY<fD8Ac!&|^G%2(W`OZ)4M;Pp6K=q7(5)W5^d?#+rou#0Z_C1-f@iJMLr8+o2og
zp2H^rkC{WzmyEgGT=dJ!_~Qrgof@+q1G+qpU0L)g<3%@Kb|pCt@LfL(n~Fd3bqn<C
zSaK07SOZ>y{6GEr@Hu=Y`20F#X8+gdt!n5?Y(~q+S@ZQgF;5Y6<RSX{8!-@aIpuO>
zy&t~lTdZ>--a8zNp6Ww?ZYI}E>^Xk}I)*+hxe~nx?Y1q#4?)+*<imcZd%k~B;+CWE
z@kyJUEoN~&JXJmgoK0nXb@3l7!<#$F(H+I!*KlO!i>v|S`Hh>&6Cm?3jo{5{tflLV
zZGo4D_Q8KZ2G+wP`>_9A;E&nwKwE6$4)ny4Rro*1(BEI;@BPYiQ~0jR{^1Se?k2Dg
z1NgM9_**w4XU$o2fcy+aF4lZY?rIWsW|1o?fL+D6{_$??=1KCr^r8DHbl_(2Uxv5_
zA1!4TGBA}qZyDkMX!HID%xez=hOO$~f;GC^@n;HwcX&IBahxiL?9=DUqlvlBYrcnk
z@C@i*93N{qYu*K2f{)!ES*eCz+IR=JfM?r&%N#NCwfbINi^2ZmrtDwAMoe~~@dfxB
zx~_)iai{RX(3^#^Vev&-7l2+F{uJ{c;Hx;gJbyvv1<@OsM~SVjCr*TZwb~G?4u^iw
zd447Q!$ahFim;aMCVcje<Z%=5?TNYHLl&L@kCSdEhqRWyq93RIL426b{MilUq@LzO
z8|Cp+?mtOC9>!)Q;`7Bae)Q|Fv+&KJXVuq{kI~p4a5x^F`Q9I_GsGtShK@T---g2z
zy_d13`Yw?LU04^04eLg3AO=1BEc&lwJ>uMPv;|IQ&LWp^4L&|O%^LVV#lIx?$@5QQ
zk3K$(?#GYa4$hb2AGF?%US3BmR)9EwwtIl5<3Hh3Ipl(0$7a&T(Hqenajb!ZW*_}T
zei>e?4oyoX6SKx(qpFb4u#ru8ZNMz%8Tt`hTt{2r^D1;t_j_o24R&n2#iDK2pABYC
zVF$E>CmTSIQ!SAXe4Deyna_wNchZ|RBoE*(-argQ9V4z}Z9_@)Z9#JD_yt3MKyM;*
z6R<n)BEzvuh<C|jYy^kt8=)^WsC<Driyp+>$MCnOk$-GJT$TkL&$4H9B>o*^+d&&c
z-$8dFpKH-0ookC+IUGMZ8J#?oc()?DcNaM>cx!b>TL%8fo&fM3eJk>NBRQBySR)6Y
zH(_jJiET80RSDPv@*xY4pyx*sXP^(xevaRYt}0*OTN9#j-L_TuYdo{<Gv)@Nar>L#
z=Q7~oGv*l4U)Ss<C-D$+h%Gu%h1eav`4jYtLZ;UsuhR~&cjiz0^9QhpFM&7YtlKlt
z<um5{k&zdO6>Ck$r&<dh-+^Yx^`F>=2ku5^!ABjz&#D=$^BIHfg8l_p5F7rAFNSVw
zh+i@l{#=U<8@Zpj{$prJx%<#53wkieaf*0w4r9bGA2kQL+sFJCy6j8rL2+zb)d{Q{
zZA7jTKW1!s^wJCDqgFa{^-<QS!Kc5^B!)$Qr&K4ej(_oSK6Ev7>k2OwKJ3WA!sysT
z>?xW<-sL{*-4^29lFVb{zut2e-->azfd_v@eoy3O&f^>G9X7CNXMA;hkj?mn2eA|D
z=*PUSj>N&+N2=q8v?XT=|6a2X`eQ#|Db1Q!Y~qb4$iJfVum2AEu0fWOue-qAI{30C
za`O@X&>#2XpFyVwFJs*+I;kuCG#CH7EPV1rJhUl-tuM>^FZAG0Z2jZK$bo&uT7fro
zeG#-Mj^B72F&VObv;z5MWbOa3ch_N7)ouImHw?_sB_h(&CDMWtBi-E~9a4%2C?FvU
z(jZb2f)WadlqeuADBUR{t)PSm0+PSa0_OhB_&)D*|Np+uap-2x+Iz+Iy{_{-uUKpL
z%yzBq=+(E>H)+XuE7X_TsAsZgdl<a=H#Uze=iWpsOqP@K<(gCBr?@F~fKL^nC;QTZ
z);z;ZzlX!!i-(2Ix#psY>5pQbjgibuOG!PpJ#t+bl#=ERYiS#w3T85I95EZTM(kX4
zywkM9RrwPhUIUX}KPaa8^gCPCm-^wYa5z%RY-4}-Ta1%i^yV)#(jxx)Ol!4yem-41
z^@9_?EyWppq$|C#vnD@E%Dyz~YdvugUM^8XF2jd2{mwUiuIWm7rgO>37K?Jx(6i~(
z7wvx!T}lrWvHwfrCx3i1JO#}R1^&2GKL!UpS4~YLnVkQ9{X>3qi`FUa9P2;nyZrD}
zQ|o^L{!TMD{{fxl+}@^7GJPzc8*Mg#-aOq{Z7`ks%UE;b)@|(qIh*|PotE~|z<hUV
znw1VJ+)7S6SKSjIox}O3H`32Z<*kM3%s=UbhH4Y`SpnCTJ4xT*mLC(#C)V;;TH-E0
zjvOfu#fQakN+bKbabA4GqNn7CD-x<(<N9ec=+r#orJVTqmL97P17YPzd^h_D++S-=
z%Ic4{S3~!^QS|hm8^lR=_cGwnQsVf4_&6|2&(wMxqA%j(oeW3RAU~nQKBpo0L+aJ)
zzGXc>V!4?dy6AEyxkCjusz}4(^7T8-_FBUha+CFrIej9ZodmmT%PZ>8KH@YPpUxuI
z{)BNO`Ei;z_)~Y>L(eA^OMPEZSNzCab2Z#0z9Q%8|Lrzok&_nfpf=MP7w?lB*MjXo
z>L=o^2NlI)V>&&ghQX)z*>9G*Fl7W=zM|HX6kpq4XWV{az8OT<_ucb2S=@JM1UFz&
zpR9B*?5JH-ZyoRKfwi5pyXTbV`=z3LDXdR>nAoIq&@;pLux$35a;(GV6qd3*Um3<v
z6ZWUYCgG2l)CS?zeEgP!p8VznTZp?C*y_XI>6r5J6*i67tUudAJX!OZV&vCv^wvMJ
zUd8k)+p8nFwl?>0VNX8yw_NFcHSE=5U@<*JBc#DkYt?h!{Ek04k8F<n6&x9#*euHs
z=ku$cDj)gEnpCbK?}IldrmN-BPg^$PfnL_6n>pv?xZ`>C(YwxbFPyP1jlWWheV*+z
zzyUbcgHHOAO~*M_t;M*T?M|Mw4!7k2UGUo$vCZEW6hPhLt$rIAxJ4g-0egjqLdDwa
z<E0M^WnE)bZKirIzbHJMfA5#CyY~F--+w5ddk+@Gfe|_6;9|CKQ9S!Vd|A`Kp7R|V
zqvO+Z-;ebpZkj`IofYxUMZ9!om+$Ttzt%6wEwdAFW3E`pltXQzE8Ml_yT{-kzE~uI
z`)1%p&4sT0FdGljSItA)JY|LiA7}X8{WR7mQ6=$G)qR!Q)NwQ6)y$698b8-o*M8r*
z%#@=f6vxfgciAXcO+GOZzQV-Lxz!4sfA6d`{Vjf;Ky8Sv@7z~Y5p#F=RuUZ7=_&f5
z6rG(&O-J06si{7Kd*7*scPs1TiSes!Rxy#9<g3<%F6yzF&EI$L$1FTjT77gFJ)BZ+
zfsKyf-@9<BY(8ARk}uq&<6K{vJv9DDw&$0_{b^ka;UQ~Ra(b-L#q#D!*eXe7wuX~k
z#QJFeuK2aNqEG2%`k^lDn=?=?4JIsZW%j>=^WsZQ=*|>%^vp-92f*Y;Lka8e%_YKv
z1J)qjT9_o}_I!d9FPcf@gBz_?iV84gmR$NpIh#DRlh{f1i(|Lb?_Z#9=sU$fRkO&e
zrqMvmg~We8b}Hr`3+J7SZ&$&8AMwQtE9f&kl`5lp;5hyfn=f944ZYOc_(m=oqTv9!
z%7-{m?4)wdH?05F56lc~aSs42pDe}~d@n~_tT#9bhh~u@=7HC)>0nWD&{j@Ldv+FA
zlViL0n`U{?636m|Ll@-xFuEvil>UU)&kJf5L9JOmXe9kIOs@xLW#+4ioy+ID&54Yr
z-{A4qxMDVsobbN2Oe^jR$xE$c-}5*gzn1H6)?~R^o^xW|xg{F!zUk3?<XQQueN|uU
zv;28NZ~XKlELXR?;P-!|!n4k4nl<X__p#XQnWXrtEG_fA7#^Zm{EYk)mY3=184vV9
ztE{ld+Ps%9Rw$C6?!PZ*f=O-IX802NmA+ZYFa8qCN1Sg~wSe@rR)Pq%X&AE&zO8@C
zT2-MrV9BNe>O8UZFH<-tIZn9s>?qutiivm|*~6RF)~*E{h+B!q-K)P4sjef3n=KYz
zaP43FT&-sIwMp$PgFIlhKJY2$uQm{`h<Sp$wEI391(%(vWF|ta&Y!Et2X_Mfb5UF-
zz^6OJVp2AWlU(2GTeWI9(2#xZ;n#cCIV`W5E)BKD^_OTY_w)Odlht<rq-DZrUHcsC
z951l-BpB0`Z<Wf%hA?i8SZfwrUH`P6c0BXpc)Hn7&eL&wIoEhNXvi_XVS9KI*yUQ%
zZ;(&%yLS)p-@Nh%IwVU3Es&ZnwoXTr@I$^?tQF2YOF#bQyy%NfQ(^8KdbD!ya=q1s
z8>>yi(}>Y@ue|KN`0~M_`Z>64WDPy&v1*VV%#f#1OT5k}CaN#}X2u|uzE?td(^St2
zf<H4SyFXzf?Xs2Dv;Qw$>q2;&F(=I6Gan8%_lXaFhfme<@LjmGDvkaLf6YJ1>w7fM
zO}ZL4zgJhS;I#ALTg`USI50bSwovDIIEZd2$Zt0FGAEIa_J@TdzJwjkaL@+!<4@%>
z>raT)_@BtH_;cla`Ye~#H=a{d<Y$w9Ry%n?U1W@SdWU_on8jV9uOtq$^yO1x>h5>u
zo-5INud9J?(}V5c-io^XbTA!g{XWI<X>(hvC)6dH)7oFrlw-sKzs-JvFVo_q+3sDq
z^Mm#2S4*y#oo-nHBWdocZ{aL{vU9vVonLOSuHV>a+i<g-w8r^<^7dKgwf+!;P5sVw
zPh{_{Vz>ccxp2ySCmog%p6(n%bFu%)h4RDNZ1;ryb#u%C_HkETZ3IaD43^Mri{q;W
zz^x(G)nNJEJ8#7fwG@*HUZLaPbj>jJ+w0ctE?;_At`!H4U!%>eL2B_>0N&OWzuEca
z3$@KF4&ztwDUMv=5dR<23U_Cv@jHq6#r%ekz6_T>W7FmIUytf=^F5zupV=?swbn5E
zCjRAjzZDa|E3Ii9^#M3_X%OC?BTsNXD_>K;`a<k&Cuv?&R~MJpOXA~IxcRo3jM?~j
zpd9_Gddq8a_bTqMa!x;&)r-I#dDhV58{v2vT;lT|il-A7#K9f)zzNRtbG@6d=y`G4
zx1GGfn!cS)?Z7e0w_qFRc!{mHWU#M{W)P~WkFaSQpWoTjz0x14L(^&#+2X-KSlpEE
z&S*A|k4$bv2mA~lC+j6%HfJt>c(#B(c`O>On|avuG$+6R8;4D!SEf{fGtJ>VOiC{w
z-@R5H`BVOR+dVZjMk0FohfFlLeU(KRNgC-xh|9gp;Si2ET9_`_V*e?9r#TL*k2~>A
z!L<B~z8X)<96AQ$7m5>c*P@%+*d_Xi@0}~I_I4EieWCZ)gI)8=`S|NL$9nIOd_1?~
z*K<G7L|W%Fe2|A`r_UPsemffY5M6TP8(Or2Ty~!O5c=pz_7yip)uIa1W8!#lF84g)
z*)HO}yzd@drWV^)K1Y-E+o11HKlRz6CV1YtrJ{9QZ`LIANGmn?Uudr{tRa86_#Iw?
zmwWm9o9sU3Al{h|H+RB2Ytgb9yYy5;ku$}&c1OyqlYA`>J{7Mx{6reJ&vi8CCPwQd
zglThqW(GY0dk@`F)BV=<wuYJ0tP9LddER;D5a-{}?9b^DHIOq6aewirX4)?BHGY<x
zf0c$a6RzXoEA%>TJ+(7Gei>d3mD_$2^xxDDrpQa;^N0EFSBFnIo7v}wo@e<y%|{c2
z9acX`qi=fJELu;s$#8g%Lr>qp1I5*SuG0M0y$Q~G9)`#7W&Ww6wXII$<GvN@Dv4%1
z>Yt1fw_W*oCw221+hA-Lc(Kts6>~4_V*5Iap9<@%SmSE2Gnge9EpBGRkRns{Oyx({
z*l4$SY42F;_}=Xb@&&e@Q9upwx;X|hRgyoff7%*XQqOcQZ@~I4^0$Pr^wtu2!4O&i
z7qm}qrnbKR)CImq-#syjy~N@9k7+9ymyZ4{fjesbs89B)`N4M_4_+oJ8O)!XXQvsn
z?#BD{{^lNZ#y$Bn|GsOzQ^MSCZ+nJVcQuJtX3OAY@XVgEVrbiGe)f^NyWC_4EGYLg
zt#wb$2Oo8g)MKpaKGO00lr9_mYnY*G+}u>%$9Hbxq4#N;YN>o4R$OuJmyY5Xu@#=f
zzWO@WI{g#2I#Wk3auDAPWxok#6XMDV&eHF>XcyZWEik_TFNT&^L+t{y$Lkr?HS_Q_
z4k&~t@9U@Vsf6X^pVQ?yBb-mTx&vRW#r8KF;G(qr-I~7|@DV(mHc#)TGrWMw7irs4
zFYz6|zfN9tJb~+tr$-1|f_sp+?3Axuam|<fn;la(6a#cn=~whNe0Mlo)#n>Oyb0sG
zSoa;C`72L(@<p0vtNppogVU||G0)|aOZ=Kq4(@nuZ7T)O<CTWpuCLk=dI81^UndU{
zr{7nlm1wB!o6Q_tmLvS-S~}qJ@$j^Sd>kg%eA@9_t8LQ?pZ^7?KbJ3AtEXxA12A%m
zykY4@IdvLqss6E-zkT<rJTyKnhcEk|3FaWp$scguwlAqj>#<G!aWqt6Gx^8W1!>hY
zFk^pJx$q%eDmLp>$F-H{g1h!Hm7U>f|AKl28}zqw)1Wwa1>a110~TE3lX9T=iRicL
z^7Mx4>f&i$GIi1Xu|h53NZS%>olnU*eib|Y%{kKX#rM%TFy!sQ_S;J@Bd%-Q?zs7I
z#c<fmW<R^emp*-z2Up&NSNg)h>$J^0m_0*(qrdvmGc-jTHG46ApdSrJ1DrdkM^F-H
ziShlz<!XFvhS<oaCby#$9}1I;lruIs$Q;c@*MWn>n$mXowg`M^Q9&Nemy5W*CQqC1
z#KnKs)t3(8FY&R<xo6z3UQ=F-4ucWlIGP>DO=Q0j&Wr7jzXdm5giA2G8=H=H{&Sq?
z__8#joO%Ku`Hgm(7@_vSmKUAtImd3$Nv-=i{I?p{W~cX3^NUaLI6F7&2@9NO6Mj<Z
zfL_87`Eg&qn}*iB!XMfBTrS!Q-nH2!k1eNX@q*k2zczeR4h~o5)%VOOK5~8{emW_y
z#xDc2n<dF(z5w2Slhygqw83+?`*u{<;#-^XXIlQ!x06~$60-?>{}x*=ZU;*yd(O*t
zIOTX*W~yyCpT_h|%HC=Rfu=jepI7K-<F%qUU=uy^aa;N7445=ieeGTIHN*6N)47-J
zC$VyzUHEivdDeWGIcusOLJxKKtaMKq_c7svdUBj8&i&4l=C|qNEhp6XbIXx0*k>&M
zz1BU8-^%aP#}2i`6Su{B($ngWu<n(O=2O`77x>-t5A_nbmA9(CpZH79zQO%3FYMqu
zS8%U$*|Wf!?N)c-TL~ufrKRe)uzeRDc+=W!D+9Mn%28j}Zz!TSdrfUQj{8Hb?Zy^t
zueQ^JUj_Gkm0rcqmf>UmU6STJI8_hijJlcpsowYchgBSly<f@$8@IR@b*7px{V+8N
zJ{qG3$WO+zZJc6qMfR-Fp6<Co3-aY)KK=kMKGj<;vRo~55F6P?1gA~hORclETw=Xm
z$wJrFNPQfZp58$lzo51hNjr<xEqvguxMu5$h`}%#Q0%VbpS2Ib82cJ2hir9LJ*BJP
z$pJF|s4grPj%=|uaAv9e;KiHrlq%|zY4wRC@U(T9Ish)g%v-J0!^KLHChE~Xzqlyw
zhv(D&religLocT99IGaby21w4>HBnEWA$=BX>ypx#+&%qTe<0s1TYL=%oNveu8~7q
zt1|p14c#%9c6e2M4A}+;{&M|%bN?th-a4e8Bai*txw*~&D^9cR6h5Cik$ixTsY-u5
z`yM+?!LMCly7i9eW8KQbcE_2QB@~L}F9*JWg<qPt{Z4Mcu9dH;DT$fJt;~3LaPL;6
zzWp6J#~yXmL$MTE_}6IjeRM*CLipzmx;Wf57gEEaU7l`?Gs>$msx4GqDu+EH*3};B
zMBqPMxv-9VVwSju8s;+ViF<xNeVuuZ`h4j<d51M`wAy*k(JOhMUbF5Uvb#rNvc5$V
z_dMjZc6F^+f#5k#VWG(9=+axT_-*@`sHfnVe~F=8SMesj@aG@=-MSp5{YUPTNBP{&
z@8vt{SJiM^V{w##f4{#UzSnVV_S&}<ZqNne@m57XurQl@qxoaIWMQG$)~)H6W;5BP
zs?Vjn>K=~RFsC)mz61yGuLsVl{156u>-GCT(T{qT79T}ZRHZX3i|dhiv<9ErZcf5F
zoP1tCDg!;}yi+)@;Xkpx^$PCQzS;v$yb3o*>SHHXQ=>mqeZf|1&1ao<-J@tW+|f*4
z)%!ARvnD$m`_4dIj|=Ov!`x2#yX*9o%82U&dT=zs40>Rb@3rxr(FOS^{HV7{F4vZh
zaqa0>sO!VCUTky`-n7Lbi%#p2^Oe&t+c%rnJx3d^cYh0B1udZsu%erFZ<P`UeW2FA
zM81~PeJJnffzu-2@}Z5JaS3g*fp+<e?fTb}^S-42a86v-($8?6)9s`7)>xrT+w2dY
z4tSFWhq(`u@`YaV_Z@W7Yx+#~^}0Bjm5C0<37^2N%`^2s*>Dga%^Htx6W@t%SP%YP
zBq9HMVBT_p`v^W)KZ~u#gs&Q9lk<u5<>KrweDDk{HGz%V7lHp`XLuVN%GNo2=I0jb
zfKR{-IPiTtHN1;-9POXibp+3{oHI*(tO%XkgfFkwo1i1QrB=)2ziqdwABf$7Pstmq
z(4M<sFFbpyyP5_r`F;#-{}O)Lp^ms$4LMS-T3LPTFnr^uJ(rnnW%J&p`7A#Fi9Zaz
zj9XU0d$!JcQ%xfW{5{X!U*f77w9B7rJMg$=XPo0ZM<>bIozpkn=terOesMj=Yih!U
z@P~TJce!xkK{+h0YK0T$S(i6Q$oogjH-A%O_?aE;^NWKt|J%5Ig!tbTE7TyD9?vwr
zwd(xuj5#E6y{o1Cm@QuZjz;0j({azcuybZH*s$l32DmHUcXy{ptYr<p71ZjNjdgxa
z<q+TCha>psx}4!dvvRTJav}2ra@s#8$rDG)A0~<?F+LD~<e)7o;Epd7>eIl82sWM(
zPoGz;{6%L~9wu+#mkIfFyiRJDVm+^Y&7wtrXzQMi3NXE#7(3;jGVxQPqrAQ!ji$~u
zOMG5PMOVuwer>^Kuq;b|{?p9dd|oqqBjmFD=QzF7m+pE7mo>`>E_<>E9W*I5y>pu$
z!bKH3nmMBp8f3zC{(UVme!wxu=*|UVfA+$#P^OBwhTpZ08#@$vlotI;ueh$fzZNY7
z*XrGdakbS-7C0Vki9Z;2@z3669b<-iuIqYMY?P{Ou86O$DHY72=&vMD&v{X;CnqkJ
zf1hKgj#uT>>_4okZQscKVOC!_JGm$=O&gB6C<giIjAOJ%;2YQE+QZc3KN9<^=**I?
z4R_uY)9u+cqN`boO=iB}+(9<T#9zz)NE5@Hclkw<BVx*HD{=5ka`hi^zfz3EmA5oJ
zYkrX}+8vSC;)(Zj^20*3=W4Sh6`jkI;^qV$?lrdaPjAg5bHiZQIp!60n+<v%*VQ5O
zdoFGsGr@G@#a^)Hb$$;EU$-8Amryfdzp3nA=P%bT?%u|O!QbC3;~d89P!B3kOF5_K
zaOJIYv{3{0`xMTK;V#qc1J^E_Cr{3xZf&2<-cn0if$xs#AzI@qYiK#S)SQlRudljT
zBUtGg=IqD+bLg^V^!PmMT*7yo^06Ochg#Ag`!B)7cw)9O?ZscFz2KTV>cfoV_m$LA
z*y9y^)HVT4%|8Z3@&`7)G*(?&{M6=md*Dg%{Nq$JU<dziB1WGP%Zu*dZuU5WhvL4E
zBbv*L;6&~LeEKWT@LUWtFVS_hSs}-Wb5oxL<<B1M{;BTnC1?X%8_^4N#ku#z^Gdnk
zv*I%^JAbF22s4}3rOCy`4}5#@U+!(U?hW^=@vzyz*VRSE=9U&}Uvi+XhjB<@`lhjG
z3Jk;nY<B*2H4oQN;*eZ=xY`)bSr%W;M`JZwNyjF_<LBXiPcz4SZn^lM!uKol?@%iI
z<b6Z&IrpAAm19)K*KHQ*Q&v_(Sf{_5m{y0Ut@-4!f^z7k@}4$+UyPrAgByB@L%Q+L
z!jI-b7SJmXn#(s=copm2Cdx;|NQORa?A*dX#K9Nng)}tmGjbDnx&a=1vWxa>Wp1qy
zpZ~*p;;vgM^@Cu+={90BkG|DhwR1RD=~wqwz0Hox)U@GuJ{tNRYnS9JeJh%y`~bP^
z$M9-6ZSoo1IK;>A(x5cNXS?Y_vAgnb8rOR4IR)eX#)mM!|F5p?m>Iqe_$WE-f^T<9
z%fI{6f;;6LALG0s^urbB)ZUC?PQ5ZQa41Y&;1Vr!-F(1FwWxFQ?lb&;2wa`4Zu3C=
zX7s!#=dp;Ee_<poSXu7&JG(nppG2_aG_FZy-{a^sw%PK8nb|V(Rodj9*j<xdjmMJB
z+6NoiDhI5&*p8nK;TK|gEbhz#SLSBtpMz;<e*P98?f!&b&dYe|DeGq+A6$f)o$V9<
zx1GWNPN?JjBFEe-em3Y)u7Y{^=K|lX`K#QwC0|>s*G~I?#LvsFF{97#BO1vquEKwu
zv!DY%#2I_7OZgsreuRE{8v5jG7?hcR9fm!$f1Ks`^+nnzE}hgx9&j9X^Q}}9^n>_v
zx07sv%Le>__ZN$?^Z2TsT9b2ZSOEt<VBh0v_ub46E|rHaqgBV!U-Q_Mjl$km`{gS?
z)HkPJ1>fd_MdEnLN_z1{^*B5_R*YmFWIsdbEIzuLU%%zG^w;iLvQ}dU!i&_8o)h&$
zOT78BxfkbG%bFab88bC7WBH3d3@)#{lmBE1W-gs)X8n>h`VT41)-0t-evlhF_wM{@
zay~T(9NOp)dSJ79G)~^ZSN=F+ohs;sP864TvkKohRzu%t0<Bh*J$`35=X;CIc8S?F
zcy4cJHMFVv`h7Tq{30^UJ=OL2RSR>YeC31ka<bNXE_=n-7PSE}bG@r=@4I*XeO#1D
z4V&*D{nETN9r0l)efCe)eDGEs_&D@Ev6)W)r<+)W@vADy5pTo$*W^l_<STX5^XlX4
z&uO$j%_rwEs{qf-(yWK~i?x^4sbJc`xby+64rimW4cNFnuCHQ!_)2H`bmx7#X_PtW
zgzCNWfxY6oZiLzAPw6H;ko9|W;uYmp#o_B#F+_v4<?HA8bT_Z%ao`0$l7U?cS<g^u
zJU&XjV!L@^YqJJ7Y`sMn;hY!5K)fm9dZF2z?;QJc+O8yxf5jTY#AWZ}{n={q_0&V~
zLXn-G!^rlh#eUuOIF(Ng8RI_f<TMpdE6Zowy#x=Ai$%65jjQtPQ5!n1FVGX`JdLLv
zuSY8V(1z-YIPmsD*s)cQr=fiF4Yi_hT((c1&kxG+o!6(Sed4!0IKOQHzR*Y?NPG`_
z0WRJ(tHW-G$H*lvoBOg}AD&|K1M<eEYF+Qp-UU2!|304jNgju*2gzyQ%875R*}}T?
z=sh*|mg-w@;5qU4ZWn#5=iw#HS(;6p6vR{GXlr)s#*XLHKl0UjVj?A6nU&hLv+>NA
z`Gd8%@Rk~8QJDXcn1SExQ_0!h<ddJm2e#YP3ii_Y2ZqubVzI3A4!fcrgF~}ezf|L3
zEIjE{5|1Y1$9S;@Y|ZK%D;0p>nP>+-k&@0|MvrZ9t;yLcM?!0KnqH%!`_PCtlhQ>I
za^*B?tKX^}JuuJq8Na2I>;9?!oI+1Lz3;=c=aZN@oCO!GMcOrb`l-wauBZ3lOL@6d
zYPcQiBlX9F?8Kj2z03ES=_l~lABw1dP2y|I;2nNSEuVT)u9OGXv=N^J8q-7HnsE@H
zHJ&n;RaVcfhkSGd>{$ty*>g)Nao>+`^rE?8#B+tzO%lOxKHC7ew~Yt;#LH2bvTP$C
zSxT4jgL-^#YEQLATD0XHaf*k+KBLXV{(KzvY!1Hi8%#f}{x1iwvy)C18*6`)qgHm!
z>CA)m#_9Yin7>FkoX=-c&%X=9N7G$!H1#KX5&WvJ*q9FQf?3-qm#8KA+yg$b{yBIq
z-e0*xkM83`^WjzlTudLGD1~3-b!XxHB)nYUCjN(~6|8wOF(04r<n1h1AFIz?$?Pti
z+IP+MS(AxtV19WyH=iGM6lcMcqZRp157z(--^c$;e18|*uLNhV!PUO5VY>YVGsoqo
z@PjTes0nNs?|!hV)@6nom;F?VBmdc<zRU(+yVetUWlgvmY#O%54fj@<f5nq8R@38e
zY~8!7>)kS&v6d#lP2Ug4HD8%&d5d0itnnB0jP{#@hPQiH$*b?EA@!g|3eu|so$GEj
zP&j*z{m*uSt1qdsXOu7WHiL0T-p7_BaLTYO*3|XP{tF&EpDp}%uxrl@FYe#Ny~Xf0
zY#h>EFJV*AKgHebd`_&EzT~>j>W@4x7PHD-e>2C-r~aHO=DONvVsRw~YCglq;a+jE
zFj)+Y`cRz`$9JWZBEoRB-_OEnSF@?(ZPTAFs77?sY>BvQbV^<0YtKZ8R40aCdp@S!
zTtlKm`V~uI9~_IDRDYtp_&OE}z06<wJ*QroK+au3&a+rQht?ZjlLoAVyNbX>xYVaA
zc;JV>i1*yT!Dcv<v<mEj$#Zj%qm``5A2fDv=ay4FWwv>fe*9UkS&c4jUeC3*!p*Ls
zZ9;tVy_knXZSUzrETBDTzPc~!&A_vKMa}TXqnTRiOIfFR)+`QPKiAq`TqGBr>wak0
z@abFP;1}9U{LL=q9+X>j#S83aAJ_hLZj)etMZ5%?zrk5GUGL@T`n1dFqa4nER+xUP
zT#j#E@8|i2;xpbEJ|Z5D^S3EwU}S#JawuZm`2Xwy@`!10;HVf{r*EI$nx<n%c=YZP
zb)<LX<$URdX|AoLnmIlwm{NV{O|_v}>RRLEkMfEBd?Tn?B*m>$F5}70bjQ=y(wct%
zG%W|0TGmj@nW(n;Lab1xl6rHvEpn9F5ZiCHK3m(HpW$np`dWKDb21ye#{Gw2S03y1
z#zh+Q6<X>R&R?PDBMz(j_jkB5!~1GLTW|}T?0i;j`c;2V4}UbDX0{bhEEH4e@%oZQ
zFk&D-{Tr`VQa2bVU)fG)@Tny=#rj~F1;@+7*8+Lu31id&U*iW)!3Oa+j7~nAMPA7c
zXPoD+zB31|zdC~7S^pl^=gAf9cTrAF*Js6ro2+Y%jq*hpdi}OK7rgi&5iE5r*{t>8
zW$LLoyQuv(f~oIVkJYu+%F^lk{7ygbww7Y7E58b!h4tP|wd|_;lQ=Fdoaxgsb|@1K
zHN>@7o@qT2%A4k?C*FaP@M2Coxm<95_-}P?obaP~fI-FK%j`-tcXGKlpB~i`4o)$H
zX#bm2;1(LL==W;*C)Bs?W2|#7Cx0tjTz>_Y=ggp%yNfRlHxn&Kz5?40C&O>g&|dl3
z=_9?E#GXUWKX%A%uVkbl<Cr_(A3J^$v#@0uy>w?IUxH8J{45LX$Q4&D9<~LuX{+&3
zy%cI;@4ALHa;53C2LHT=w<|1Cd)g#cKM^w<Xh$}ixkb;P26{nkc5f)hbWWFD)9O+*
zEG%v6dM^HAPIjMK#{#~>zFEJ4*Er&pxz6z*E&HVVfn3|pocsa)EZjve`(9mqJpk@b
zyP$`WQvV^feZtWD)#O!w>*w?RQRn$ecK496?MlZi^r`&43*GsVS+;;1YpO52h#OzW
zVKBYrVKoR?n&F~*81B=kFeoRk`ce*E8diULO+OKbO~@c0$Zd9PkY3%>>W9{=nb-Bs
z>rHET=Z2gce+`L`i`g*QL>i!)TE&NS*E_+St{9?YYvk9rXsv!USWPmPo>1Iih84ez
zq0RnK*A7#^_#IDe^Iu7^!$$27m=`!@4(+788a}O~LsHB%<AozT<NA-6(=e0GILxOB
z;d0kQVfw9ddAeW_E`OgrUZ=@kg`>gqi7MA}%#Xyk{bd$k%@?U{9J6jc**1lq8%|vc
zqpFvqbNFVxy>db}>Ym;GBDB%d&%lu^YTAYHow#h$i_XqU`@+euAJDZ0&Dp#K&#tPc
z<i!It`ofL0#!&hugU_A{o>OhUgWVcL;FJY&<1KQEvpB+fcMz|eQo@t>t>G*)jmL4@
z^Zc7%d|_QC9l>cQU?)zx#iw5@>Yl3StVOt-pfH?i$EWy2-%aKhO30DmWUZIgWAZtl
z@6?^~@#z=k^BwuR7^x~oe@!Asp(%^MM#ujwcKPF>OJcr{YrPd);JNoeeAlS0mYRmI
z^8bB!a_F~wG^_i<2hj?-@GToZ*+4#(7Os?4Psh1g_(b!xxIF<q6-iG_aj#EHYj_&=
zPO#s6a?spr1nj-5kvcH{DR++j>46?^*{|b;-^MTO(F+a~-lWg(7`2*-o0`@pv-@Nc
z(ELf|*0>>`wRssHA6u(-FbN03#nIO9K5YA~Dx7PBpH||R_Hxd3_!ypiByQ4(p(n%C
z8V<>iVCxW=GFjcDn)5G`k}q5Pm+tA+!OYk9;LYdNRN9Kg8geUsUT?nl--_Wj)@~u4
zS%#KLWZmw&?<L&vhUo`7?wH%=7~j>i=jY>&^Lyvl=O^~THH&7@+9ha=oqY5&$N0{3
ztp}O^hX=iOm~(+$ufv<TPpU~al;6fyPud$Y#OQUS{__CWBsWS3D^DJgUu_G8T6TA=
z)@m+=t?3#$RtL2Xx~Q+%yYT>a6_7vVRxjnNy_)J7mZ7K8^Vt^S^F8@|V>Q3+YTA5p
zPG7aa4c4%S9t*#o`K^17*XrMnhWUeGsN?n8NdK&oQ^ivUfg6b%&@%h+MPYU5)$XZ~
zQwMdTUAxsE#?$i2X&_ub(ORU<<e3Ao`))n8#_D>BL(Dq-s;)ef)@Hw)?E4YF|LLyT
ziTCtT#Qmx|avplCX%q7U{Qgz=Qo1*70>8q()1z1|Z<?wmA_v;|8sEi{%f7)=arCa>
z&fmYQg|(tB@90&)gQbbAU3#3?$^1OLuLGa<7jZA)81=m>=5c=3f4-{j{INbBeA(g}
zPE8j}wl^>MXcng3?=;reeCW$iDAKuJDQTZW)OQz{Pe1S8hFt9Cnm&X<KfZ}`ubDgY
z`DVB)cvfR(_;qWuxWc6$WN^MMaTHqw&s?dr7~a1j?`|uH=?OE&o6Y@#pWv-H_h4R5
z_;T5O1nbn1x9dS{wr<_j6X4N-*YyNkXPIZY46Ho(J&tAXwsUCpIW!jj4xZn6$-0%G
zE51xm1D#O!^POwWtpj}gy(ztSR9!}$Az@iMVYRv+&6o90^I`0rtcjTie3(fbW~WV)
zoiaCXO)@7@`@xCB>^oJM`wc?s*!|Ut@KR_ke?Et|a|X{cp;b%Z?kCJ6j*$C^@vrI2
zgv;z_wpy*+VatnRx+5RWr-!nT?-q0K)<t;`46b`g4TV3?Z5sTY0lu74pCO_8Bt2cq
z^-S&VeyrMJ-da>IMQ`nMKTIhapT>C+?%i1F_`AgHQ+iEx*caZ6->a7=R`NV)zq?_;
zaJ*;V8~f05x8U(a&oUe)N8rPmx6sJT=@M(WzO%gNE1IF2I$SY5z47>kmVLr8|Ew;L
zf_;NWn7yh_uRSexo)#y?tpBTKL@KMZ$rqYf*9LUUyJ@|`j#1t(%4_ZeR*u@H$BYx3
z!n!$svsV?E*hNnDu{u);{w(jAUx+rCXC1`zGWfQdZ}(Y4dmg2?JIkBjg!z}mCa$Qq
zPu{>Mo3VM)5BYKhzFQ0SiSJ}EE9W#eyk!l0xzA$}UDZi$jJH$OHCyI5GxDl|rq?(9
z5e{{t#h-&8{InonUnU-_Z50o7VdCesQ&$`U2d+5ZCd>G{{hYSWOFyAgKUR1B1OJG(
zr$cHai_|0d@QDe0vLf4jP4hLDi|*8)<8$+9iDUg-{|EA=1Nfu^UxM#*9?)rt>6&c%
zj`n+EoZ6}Fy~okqbVJKk^5-Eq!S90St*q!JS3Rb-^F4l&+r>SurpM1`(pHDWPr3Q#
zkoeq*{qjcpJ7$fG`0jRgP4ySP!2R16@X=Um^>l9Q4t$^;-GpzKpM`DL)E$4O4Nr@+
zCT#HxJU^-L*iudXl)91Fo-k23d@3h`r7tH}3!zH}_Ef`ppawoAEELK26MM}L^MiZJ
z`uC$dhFcTsc6u70u%?Ht^}>%rp?pDp`>ozOe{8$n-;r=$;|Hs^@Yy}N-M@re1~pda
zf$=TE`TXy+-7!7slIFk%o5_Wl*I;5&JYLxOyw;4q+el{(w*4hJV0%~`TMUYWI`-EC
zCq3(WI`Wa^H^j;Yv)`la=Qo-+(3V-@NDbH?#Q#WjhH`Sk&mHe)`+&tCvsM3>^|V^!
zyq)TH$Kjt?n4DC7K~B~H4hKD^4SYYpeI))>52KhmF+KU*SzNu<eRxgzZ&`Iu_Uev9
zCN+@%!=pLr)GU55TlR|n;9?xQ1V_Px;F<c3f7e4zfD22>L9W=(9X^~(%(|YsFraJ$
zwmrh<Ps@j%Ring}yTn3~(~gBpO3D=)!rpuQ`j0#G+c-55Jk!KA-nu96q2+fs(d)s<
zb7Gmfy3Ed#^+fq@ob|Ait%JV_oun$xvqpF6o49W}-^n!ULf1H3{kJ|p>Q6tHp;Kwp
z73_IYOcY9|$JayeoA3R7gg$yrE$=7VJ+t~HtX#Q_?z^ED$cMJo(}&w&R;U7vo|GoA
zh6k#sU968C%JiCC34a#H)A>^4?$W_MF?<<5?4O}#+RR);Gx<y-y$3iq|BU)^DSG89
z42lo$KY+=wI~<q(lv#dyT@R`_JBj%`z17N_%UQzZny-8Ai1^LS)}te7+B!5JJD<5J
z&TiO0{3z(y^RCD(#X+TxxPuR$g$GY<&<BL$t#`nNpV?-G8jR~(vW-#at7mj{KLuY&
zKU2PB%|EFuuP*@CaK)e5XooM<Hekzp;$_AeetAwFJc@>eO&t>1&rf>E^x>a<@#7zK
z8O;0cC`}Lsx9h4sjAp;&bo|@=puYG?=KcU{SRAh<u18lsr&hcmER<<DynBz{Sf{>!
z!KwWsf1)vefv2zg+=REqcOQ0ft@mb$<rI8|j|G2Icfd<@6--}oU+m{*liqw%3>0M3
z{sVA)HCn?t@8!dv=CGCnJkuZtyc}S?OUgaHUoryDy`x6;G@O$cwHrh~-xCXen)w@x
zzh+r~e*L5Tb8lO57|#qkAO2%F94yH1$BMU#@&VV8&v`DrLifRkPx^Zv%?Em@1N8?!
z!l5(FKk)J3Z^3_PZR;n3Gn>@@tW_6ydDHs-R$cwNDxK}WL)Xl6Orcd8#tyZ7ivO|q
z8*k8~S<J8$#z(8wG-8>f#-Z;VRd3`cC(G(r*5?nd;c{;LRTWoGmoxJDwSDFExO`b{
z_2@`7;lye(CHd4`JXlGd`z{^PUhRPG);5RJ+xW$?SfO<_a4~);Gh5BKtl0;j`SmaJ
zWUq)#YqPSvdo6y1bMg2bJUk-SuFjx02FYiw`?6hT6Nb|Fhs;1Ml{?S`d8|`jYuJN*
zI>Dlw6Yy+Wd4ctRbtaBsm#V8>b9J+g1?4D{t?@m+3FGs1lnc>{&EkiJB9G%zv2!%B
z+`cESdQZ%x64N+26Rb@Vho-Y`&(<^}MXQ8a>sEXvBDH6B@ulLf<Ab{Hzw6>YAzHs(
zX3sVnuOE{@JreGuj0gLz{nhqr3^1=1O|c8ce8diyF5n?t{z)zCdYJtq&A8R#tBKXQ
z--AbGXrycGZ@q7x(r*=GYtGSyRjdzt<u5Il<eRsb^4&4kYL9;Qc-PuST_X)_Z-o<w
znd`6OTIQ*5ZI`<)q9Oclx#I--q%MC-hVv?~)K}POhWZD2%2YL>bol(Zdz7A(+v0(N
z{G#%wu|lT~=!NXplTWSJB2K=Chb>R3cWswz*mwRqboq9(JU&x~1`F<Kobsg{%enWa
zSq@#GU*@aPiHYEEBNP|2Tls1Ax$Zmag^$JaVVraLG`xRFUBq=x{zSfZnkMVQm(zHT
z#Y%II_w}oHsXdFKF6VGyH!-){bID-)2k<P}boNRuf51;QM$!Vm%cGLJkE;)!s4dT_
zBz7C<H;Dh`{O!B8?A*od3Z3!rxg~qxJnhhJk#&CE8aeI{FUJaH!bAP8xVPf09O+Lp
zB1P546S%h`jhaSz>-h_fI}pDl3~H%rubE-Wd3E^mW=oQ?VF7*H9nLKk{WP7QJJ-|f
zu{#Scn5%z%9akOFXKH3nX`7mTezU>yscdj&&!pI)Nb&M_PjUAutnb6FW7QP!PbbH%
z0Y_&Kl0W8h|Ilq%ln+<J-c70aIzDS6c7uB?r;3}g8{qT1v|fHXD<gZRRJ(Z~{`k>4
z_7Col44zlHt+gHs99Xs(pRN(F);qki9B;Y&s<WA_@7?P{6Ew&5zaHS9r`0;%33QTL
zeE~6lPyMvD{Hd;U^}W`GT!%Pq<b0;BwyrzWQTbZ4E;u)py6;dqT48?j7A^Ocx|4M-
z^sBzG*gDIvvrkbU7-TkqZpgJ;J}Gwh(lfQ#_jX^;Ng1wZ5xoC6cBthxGjigvxoi7v
zftm;W$}(9V`6k`@DsC&OH(k%OK53WC+0^Fnz%qH`@BE=uezh+=k@$>x%S3$o5KgjA
z9p9p><e;N7Sf`xoUhCEBe^yhCOK0MRD%%~0ue^UA2X4~;A4Ny;lZpxPQ7rc-yO#R9
z)jDae`TX)L95lE)z2`b}^34M~=<TEOp9N|xO>oFXwJqy{T0$j`)02F>T3pX8NkY>d
zmZRR`SKph}j2$}^39~YEkY9X-kM_||FfSP#Yz?~(HP*}j7-oJ3=jzKvVcFhK#5_M8
z&X0z{%GhE03s1|_=*t_+X&Cs>%QaLKe`DIZhv2+9tO@RAhZj%6$%%8^S3{?*hkwZr
z(JODLhxTB%@%WK$3HT>-5BcBkVwzTKywx@0nPpquJCuY@a=kmP!}1b(x+n3_M)jGz
zxP24+{8rwEBj+68FS+!;v#Yt_t7|vJR&JVy{(2G)r)(_u!g*U3!sMsahg`$EWofo}
zcxIV77Z~_cIJ~WexA{j}8X)lhO>n6_KFJjiF720(;o6q{*rX1e_Wi<Ft;K~<s3mRs
zOaXP>gY>nW=`V3GSL}bdkiX-!rnsikYcQmf+9kg&cv&nu#~apo<r?Q%hK3*E*?4qu
zyjgm>@bTDQ_aD|%o8}Y8i^wNR(qx6zPkx~XTEUAK=#RyY>Dmgzlx{T8dN_B_H56&Z
z=UQ5$^ZNcc;spH89oYSZYt4zXt;x^n<ay=PuRH7I^Ysm-*cCPuSS~*+$u{`*+o#p*
z+QAi{tveqtj8H$M4O7>oGjUaBzPcRNT&K@!x1%FYsC7K6pLs@}yH3pW(G_iJm9^p$
z4{gaMCs~B&2EdCK#mFc8_ieLHaPELuojOxZ`dNP63C~~DS9NX4vf$dO;&!lmaxSSi
ziTMGrJZym2;s-tO)R+zI9V--ytRBoTn#~c1lc&qGv&u)N`2PDad!BW|3At9<Pj2=-
zW_|5<&~5s#DPQvMvE!`kBKp5IY#n6HZs>j7Rud@fvwS-}9ISE8eA4S`;qN<kU-!1b
zjHg!Nq>-+T?&xz>9VR2crh{J=zk`~?lArXZ65+yCVsx}Moh?Vc17AC;ea|(w%-4c>
z&%KT_vnkFKYt8uRAF$$B&RC(yztm~iZ#8cH_<>sMZL{ZaK17eK%SV^6%duPPB97Ph
z4vk&Stj_`%G7Hw@yx`us%iHvZs>o~E?L)qoG?Tszja`17e(*jRYyFm{4CVr?6MugS
zrtJNeessRM`Di~pP-3e*(09Z5$F&PEcnV%AuBWop{X4K|+LL<q__SeMIwv-)gC#kt
zsyV=$9W=>^X)xFRPS!9NJwYD%H5;xlW5HJ%;(~N+nxvyyWal#U3O`z+uC$b%zA3+i
zL$}hYSM*aivX4Z|^na$9Q(It;;ZHs3Sp07!T%_~HJdn$awYo4h6FX#G>s)85H(s))
zdH9C-Y+Nw7p9ZJ#*A_mvh*rtC*z@1u=x~^y?<w){Hl4Q9YjQZ82A=&6Z*bVtDcnb#
z7LJtj`$c9>>B_Fp(Cd6JJ>2{B3T>NRzif<iu1{-<uXgXin)hi`+%_ODOy^fcoKvg_
zag6(4NkV78#{Zt6pFYF8)+MJ{?h98AgvIu(2EP-VZ}5k~;<5yt_HJ@Lf*-|h8T@tC
zwZMy()^{rHTmg?)nMI?)){eic&397M>rab)O~1ZOgYB0?7LeOno3wcY+!7OT=g>|$
z?GpKJ7ktb=o-fUh)hRBp*Osr$3BlD%sqp^Gcv5XFc)o3Em{1~z8I@BwkdAATL4HiD
zc66=5ENSs<g0q|Z`m(cmX|=Hf>d|}o-(U2J>mEj%_QjtI#no%~%sQn|k7Czt`1&2|
z@<A+l^s{RClgxT-aIP@4DF2=E98GC`e#obek_=bC-b-TtX>lIs6&%JlHoi+UG{R46
zJK@_srzW#lyy-go;=JZ?AD$0k@4^LPR1eqvCVu|G+*@z=4!k4pe2!1p?|?jx{R)nw
zZBElph3Jv=@}yS_!T67Y`y|u}#PHGlVg}}?mKPpt1xNYGg42GVz<M2%zru@oVz}Rr
zW;^&-4*dLTQrK)w>xuK41;o)t*H7n^d&1}CdTElX!_b7s@y|Dz`N9k}1wMBDr26Vb
z{4~JK7_52+u8ny?O}vh0vgFebQ16JOm9DnH!vob|=i$H0p6lShF@K4T&*AADvktq|
zLu%oHMCvoWtes;YK19>+5a&PeH<}_5j$a)|On0-NHndVHH3#+|4qub`PB4#_A&%UI
zy<*|TG)?84blr_U>YCQ~#zwuCxoV2bVNF*xrj+_j);rAvdi`TscQ?H}17DTpLwvq1
zUQcF?!sw|wY~A&O8SRhhIsD%?t+{IJvtbcU+||5LZ*e8gK7tt&ob$LXzE6iNEvlaV
zEBiN~HR0qHdN^A_bwKC-gm@m1K<+NigL~%|u2b{r$+mQPi7w6|BP>d0efGokE!=mr
z8c8L6O)-!QE~dokhxy02cVVD7?lPUPw!=Tw^w7JSk9pdEbLG!;V$Oxu5GTIQfBKc6
zC7k=Vspjeju^}vJe$-6dICVYoI7iH8s75cgRr4%|F9r$QA++{-a|2?!j%)w%0Y9H-
z9^o484tqAH<crqw>x1flFX0L6nYe@Ajs2W#Mz4wM$s5(v>fzBc{GtWUe!)zdxM*=-
zOcZl2^UW8XwXfB13!awmj7wl)_Rj1U2G0u8igERQi>SGzSBpNUmVr-hz?>i1b4qdR
zO{1)!g_`4qL$KifQ*3%bU8%9YNe=bc61ML)>(Gpb_**Zuf_ps@s&TS$J?pg%M+bi!
zbX8T_&zcp5KZjx5xCgWiZa=P0G7C;UmqiSY!}mBeH*DUPkq;y`7rw{2v*E{o$o;3Q
z_3+~s^v^23AJ4khq|2|2cOIXqrCf8(bLji~{DU^#9AG!D{tWhyI7z4Cqge8vO7Zx#
zHNIO)4$+AgNH3l;nUQ4kZ{r8~H7zA)dBggKi`R-UI{150M_}AgShhdHde_j4TS^;b
zGN+h8U1qrR-lP9nOkE*^+}mfC|4FaSlef{zzl5w~UfSxQ7^E=@v{onRt&bL0Z;hWn
zbBQ1C*6&^qcL&hmv(=BLImSqsxJW<Xj9!*lNYGtg@jJeQyEnh2s~6A|9r)wxF!OTI
zr<dE{^!?w<iMQzqzG`N*3!c~}{(V1XBI^Xx;$KoTxUQbPQtY2L`!k8=*rKjm7XG!Q
zYv5@s>v!RZ{J?+3I?~@Q;XciD{2TZ>!*R-*Ro+csl#>6Q5DU)jw0Q0er-v_w?aTB~
zj=49F->!mbzodpaIBxzZ*YT}b%x^{$CY@)$33&cRTE8N@R@hGWIL;F=vhse~YM^=o
z3_11(+;PrpVbuNK%*y(2hIOhr)bSU>i&}h~o(i7d9KWOb<4*N_KDo9NJsBZab$w@G
z`{!5qC_TOXNjcUaeN6T&Va@MWho!0X{Im0;5%Bw**m2FRT>EF^{ksCr;8$yJ(6c!7
zwGr~g_smZ?*0{QQQRCF*=)PZ$x$loYiF4MR=2vu4FXw6>(_H^O_US?&gu~d9*{scP
zu|qBM(g)SqsE9h~vuYm)?R$k<9zKb`p4R3AnZ@-M@$v?rPV<wxweR)rE;oY5oA_-v
zcyw*Km`jS|@$4jg(cQ7?@qs<R(Ze<67yRkHp60jW%Sp33=Xd!<3mTZ-xV}*Q(B*^a
zx9Sz0>l@}sufx6xj=#q95m(W0cVRJ3SvXj&p?ttg@&y>VW=)U}s713?T{zT+UaJf<
zM>$URB(S5MSuU73<fNSU8JeuLb@+~Lvbgpa)CBNR@HYz54HP$yU#X88W^;b<0XxCA
zb_?jiJl5XnHg%1os+bw!Yu`V>r9B??#_z(l;yzHOmFJd-pPjJ12>xl6&@<9L;6r`Q
zdx@be6=>sxv?1&qn!-MCT>UfRB@Di-buBgcMMLYKNc`fC4k^@mSL2-Y?r#Z`%g7zq
z)W;XjA@gL{8DAdfJZFue*}kMvoqvNgYLju~(7D9qDm|0jaQ|&{U;Jtpz5Cz<O}#~~
z2(QzNqnEboZBNz5-7cRVE4P714G!qV7NmV0bFuxs>AN5D|I=mpKF)n=1iSvCH+ar0
z1`JC10Zny-#!0WY2NzO3uf8@D-dx}p{a~8-deBY$!iEL;tkKUns3z{P?+Wl`vGw_^
z8ePoSW@Uu4pSV}W+P3)I{3_pDBF0wn;rKiC`6A82Uo@*MW~wa5pS58+KWZhW>b#<U
z-QH(ukcC@3%PTPsKLnGH!^#W#8=2w0nCKVJ^>@Re?f8he3G(D-KJ#rm^*8=d+4VQM
zL#O4{XQll%_f?C!C~v0c^5-)Ty^S_fYZ&mVywp0K;gfR{i^plSAiO{E5$%!R>_=C*
zG@nc$R{xSG7p_PP=Ayr+!1ArmRm`{BWsPsh`^8GGl5)oTFcE(zn#;do;J4*r`Vo9m
zmFA*h7SqK~z`*ai>l?pj?qf8}>u08WzI?X>`?{7iyYSk3u!wF<o(RrVRNJDrK7swe
zS7t+87W_@6Sg~Qs5L_nSQ?N~D+`laczhb|=AvMcF_T${L7GnFS%{<ZqX}_hZ2AONd
zPm%1?h5cWlw|c;==jN%Gen5LKlD`%6e4fcc4NXklQa5U2F6FY=aJ?t#@HhG2+Z*JW
zFku|qciE&qRNE{rAB_BkJ%_;HR$}0NKFMz5*2^19sgrG1Yl3CT%Bj~5wr+31r*nD<
zW#Gs`IsQ)lKe3Rs3LR2{mb`>pit8oEXFKPVV*s2PWgVW>^XGf>vgm&}Uhv$()92u4
zvH(xyR&Z<Dd_3IQY#!e~TwOjU|0qxYJ_9TAUDtO@>3d_;B;<{0_<Ol!eED<!^@hI0
zDt&+0H3G*B9H!4%*?gOP`gTUW6me9$IK1rbzDu!k=vOmhpV1*J)IJ}`r|F$9zM!`X
zTBCvbSn=gcJ>-G?_1a<l3|N?IFI-q;){zgNX2(Qtn`hh&3#PM`yyge-6x7*Xcu#%}
z!#?R|7RR;c7%tzx?E1#2^JQ{P#q?oe_91KfJ6>MNzQZP|2@RlU_nX80)H4uZaRfY_
zaGPDr@#m#x3&lZ8+on&(1K*ophAH)6O#)cbq&R&r6|bGv%RR4ue8w|%R?!k`^!0i=
zC*R*Y97o@i6K#Z%;w88@v_W}xoFUJ)e!Gv#N5uOlFes=A7NmbRC02I`5AKEL2iL48
ze;(Bb?|rAgF;EQx*5ALY57|#mG6%dCk6Xm!XDL0q7B1hvqZSE&t4GKi#8!e$dW+Vl
zQ+^sute(tG7qer{r0NoP&EuRkp9ecTeMj@AhBF=HiPmED1wER!^f+BG3=h5=SMAI9
z{vK_Xu|I!=7Zq=*VeNuBa*yHk#_b)rn|?j@g>(BD4m(z|IC>KN>VRuG>KsQm^gJK7
zTAB*}C*UJx=$$Xsv-^vkOpkne%CodfHuVp&F)J4hCx$EYrHrH1xy5Y5Z{Sc<{TRMH
zzP9tk$zS85UTjp8&HLqmAMewm)}>>(T4)({IR4gxEwk{~%VOgRzE$iq{f%0V(U*>$
zh{O5PWt>yKy|t&!e}n@$_E}rUo9c5l=-|$`Y43vKW{^74F<2|c597+r@bs(iXt?Lu
zcsGvw*&2<a@#^b6oRSB`($_psql^C**8KLEuuxgr_{Jc$Q}(|o=3az(L*Yr@QhIYe
z@Iog4U1oQF`W0-=XB|F$&il>$@o9Ym_ISs&%*rVy<@oEYS1P<U_f2c&`=#DeAA3m+
z`#Z;khiCZB=S9Q?T;Aq-pNADeUw1T{Zo->m#q?GCKbTf7jsx4sIZoupi!^;u&+R@;
zF3?_$5)N%HqBh~0uCj52wg2)7oYxd~6orMqnpMXmNt$~e@K?0p4E@=iYO`W9!xHf=
z4hyC;Lvo+i|C0~AOxHJYpRQw`jf-m?cjiWUNC$f6zW&-e7@A+*1>ZE`-#fpC8@}@g
zU03TEo*kto5rONwhz<C-d^-KVCKSpv2R|McXL;Pi)fe{uV#ZOt{F>7>H=sGU$rayG
zZ~R2vKel@i#CF1O^<oy%60oI(*go@zdCCvf7LwDq+stRt0pV{srzHGvsApmD%d|ez
zoc$8xwBP!f;l-H+CYkktt5tD!uhg{DVpwuh&ENrhy(GsxFSp=7r(kiaeDaTdW>gd7
z2^ezW7@u>!X<Dndys8exmy+X_hVWzX75AoXrZ4CFH_g01je2lveXG>suqxcHf{)<v
zie75iS7|rLh<#eUnC8eJuFKFs&pqHDzp*=waiXf{1l4i=V)VS@X2G|?vjz&Mr}gnn
z3!J+OuKroi96Zds<ljME_;eO)1h=z1@7$ehj>WLCnAz8N;UW%P4cCWn*Yo;{Pj6C7
z_)G4~UVYhd-zxRI!_IN9I>JQt$)(P9iTk%R=v%_Sp?^D8OErP*@-W{?xDu9#l~=#U
z{d>gZ7<lpn`@bPChKF}c()Bmgj>OxaX=n-CpE*gN!v6Fr<VbKNXHNR*HySCics&BY
zs;ar*y0IJ8DEiW3nfX95cIcy)D+k%tk#BaFJHoc3wmo2n1s!20J1p8D$H?Z|-*-P2
zo=ky%>WSx}Vm}^x?z8@rmxO6<t0UvT8<(vszxYfXo-HRwQ!jXW1Yc~fN0W};9~VpT
zse7_%A?NaHBhOT!Gg6E5ANX!;I{KTVYK*VzEyI8<Fm{!-dSx{~OyxdaJ~Wo*82O{#
zCM?ZXo;DPl>z{ysQ|XI_u%W)1I{VdsRUP$dnuvdFhu2?~giqFd&jR{tBpVOM_l`5}
z1z0&QcwV?VeI7YQ6SDx#)PT2`Gr^_tQpzuC>80e-qh;&Y`AT=#QU48^pdt*ib_LGB
zMY!>yeg1Yyy$WC6Ic47GMY<)o+70~5lS^NhhAWdsEog=NY{Xw?T5BXt)+QSba#sx(
z&phj#K08hq9am3Q=gCx_Z?w}}s4myp%_b*kK03VYLb^SS_H|7|o}<IYyEn}1-XHm#
z^={7h$Gf)Fe13$uxqR634*KEYu5f}a3pw7{6MCbc!id3qtSDc^WhJ`6jl6X6RJAZT
zHKqiP_&`hz!n1Tk9$1^wx+iVnK7s{mTN%~a3R}Ai{J62+%R+H&4chRbJjrQP*WVmo
zwM$Op&T$SWX`N1Diw3=9JzKrSmtgChpXE~Q^fyi`v0mS+v$)+VFH6Udam)Rd^4!7J
zco@AaZZ}<|GaArN>*eP6%sqUiW;FtKe9tFg-=}eD-aD~Ek+WdWHQZ@Uf@hX4r~^C8
zsBd^b3brl#4JX}+9g2j7$FISSPib@Um62Y^0n1OzcRnu_Qpkb7v{4@R$VvBnv(n7r
zyJnJL+UM8smstCrj~`^y$@EUoDr|CF&F+N0296)L&&+fsS~w2OI7MrHV}6Vl-uE#+
z5Z5n$4r5oF@BA39JNLfX)j1sJ1nj6fTaNw=U;jic?JC{nyTj6p;Z&||Bz?M19Lqy~
zWcQl4@zQu&?I?}SH&brnzqI7%{5T1Jo96rLol7bl`3pM~P}i#^MxM`(n`q-amuS*T
za>(H{<VSRjYrN|?mAdFVZIS0L()WaYd23h~ygl$+J_5hjEQZO6%#*>SBCv8oLAB8|
z;&!LHW&!r^VXfFWUc#WyEq|Qgxl-}O3Y({Z5y9URT=E1S93#dK>QTa{{S|QC5_1ik
z-8=FJTYoM#U#4fXh+V!spC7f%Ag0)&P7U{5eWw5RQtVJBnD7j{ZNkX~_}s-?wC7U1
z9ilVk2!CgWYcIHmX*2GtCYFb&sg>8Wxhx;Dt-~nCFAc+nz~HMi>@Tn_Oe{_|1DGGi
z6|sKS@XBlE2pwk`9C#7d9Ik2xbtXMhDlF8pn!3AlnLbv1?2I~jB6Vf)dJiYJnywF=
zR&6u~-AEgj+652zY@EbqefYxMm97)k7I-`0DRm2W?E~9RA5l9jFDDi|i|L|0aALnT
zPjxVuk?|h?6~04Xx|Z05tfw_jz0BXG$)uL^ik`t|?(cXRXJ27Ucz=-Q311Fl`Cg`~
zau%3>DcrrT;^Z8Sea~7BgQcHkHTNRs-@$D|<R`zu(9&z&Z*U4u^@X2<)RXeTcGtCW
zD@|Bgjylpz44m#4;6rXU7Ec4MYvRGQ8=k*k57w2GE5f{&?6)r5+m5$ih>*9Qfzb)@
z&kyds6i30|y-ZR;Ty;~YfX{c6!HcVO8XODf;|JjP_48^~{C)sjJUYPo?~ps+lq<ll
zV?&)sC-)W}^1H-pJ_XdO7vZvA#87kVH%HACt~C&6OPi_{y{#UM`+u^wogDuPT#Q@9
zvxJ;~t32wzY0WkB#a3%z+ePbm#Q8U&Q(?h#?DmXxUE+I#V)0+NkY+Ot;havvf+TNx
zF2Z3wn`YM8F}|+I#xUz*BbtLB-?PRwKg3~;<#Vwg^@e6$f#FB#m3Qg$PH=Cbys))e
zG4B3>9iI=$>-kUoFX^TC^;KNc#<ltc{HN<Oxx;?-s!M7SCFs0sc(9{BupB+2Kfjyn
z9@`A+gQN8jXxX~O)JfR6!6NuUWBkJJgJ%gJrJI81XQuewG4IezyXAn(%-3bow-ZOf
z-{#D>i_iW}Bk_fbxNaMbd;ljM$p_1D+`@b6k>dMh_I(SEP8g>ieoVayK7UbDU4`vC
z{{;^_>NiF56FR!+VSaTMuX}&%G@jk5pSMEqxVJi_^BS{EjL~Ja`Od`e`B^_$@sfLz
z_;9tP@QfZR`?7rEOY>6q+#|3Cj`ExOyVM?=h`mAn)|2Dj*=8-o-zfOlGBq74epBI;
ze0-&8O?uq59pTH9hT<N+kS4F5Mhf4{i1QAxqw|>Y4t|k$yuA~KwD#P_uU$86yAGQ>
z{$PzAquN_II-S{r7aR}wWm;!{GxT^8()o938ZjDsAYX((L#N@H{c20_Gwo@0&+pW&
z7O6vsy$I`)@Kv=MoU;xeRQ-*9E$csVl;U;yUKxJHwwtZ{Xu3c1`~2#J+Dd9Q82A#*
zlhxs)9kb}=FBP{*^jn2PMRD;m|2Wo6ooK!M1rDc3W8T*9E85TU{N}LI=rvi7@~-*P
zB^nDhr~OgBL=${DRUI$0+PAezJc6$*SA&%UTuNx2$D2KhaL-&#+W84}o9eLg9=m>^
zZqSNu{#|a~oi5E|jdRnwd@|KQwXgYVE&TZ9Dds#EtB<^9-Ak#n!sW)|{wKPtWF!2x
zP=4^M8H<LvzZ8C0t%nEya=jsbu39fRbQC^p9Ub&7X&;!{{6}jbcOSYG-^1B$t}_GO
zbmFpnXNJD}EV`}^PHts=`on{!>NnzSd@p@Vc}4d!bk-92$)7Zz^&QQxyR~%B>K)IT
zUZd^+qcgvOZ~9uZ7O>`l95RobI6Hp4r54f)C)YFUc!=F|)3GJ!fTHq8m{+-+YhI|9
z3!mPYE`Jl}6L0G+;`Cu1=-~);-7n}v{#k&pbbL_{XEM9F_SNatDpvD{WVrkry|35A
z_ar?Q+%+1OrV{IeyYj6T{HTgLLVvaT73#H>@gS_sGETksE3-j#@DN&SabWu^`YinG
z?+Nn8SIxi<(QA5-mfr|p;>qQTiunxkfgB-oDR`dVU$qC%;*t6zan=xAVc&5_srg)$
zpO<n^NpZ8}d~kCD_atwkmHF|5w6wK+GetSL4I|RA*HCe}Ma(Z;;+`YtxOgni$L*bP
zM7e2fH&HzS$5m;d&a=<F0ZdAZ>$BY#BZ<`M*n5!mKEbEXO_E1+_WLW2*GWuN!<Foj
ztP9`j1Q$P+N8{5p4b>fJn<v@e^UQFKum9SEzHojwVam@iZ}vO*?G^RUv$Q~jKGGm_
z*>a_mM`3~ZD$^4-UX;ta-ppd54}YrLls`-tbM5t25975kdR;AJ)m$3FKGxFFw?0v;
zYe;vk!ao<({P=J2xAFCxaCEzP<EyD)W4zDRU-|hKv7eW}L>%CYW8_pD%^iG*FJbR7
zKAp>dXOqJjyw!M`9>n+ZDsi#y58U2F?83fd_+<fn842G?mc&`#z~9Vr`(a{(Pu<;3
zXX3!ctK`sUtj`5CE;d+x-1_l>UCz0Un2dje<`~Hrtyl6|w9YT`s9fw&)93leIO~=V
z-aL~^9m-m@fJaGT*|xc6AL*LYTj?6UTr{ctYzi$l3ufkI(~9C<Yz@FIk^T975A`y3
z>>3K5!R7vg31&;-NjBgAwxBtslza-t)SiKRzrcx0`J(GSyc(DEqA}pjg)y|qZ;l~;
zi|rLV);eE1dTxu_CjE9F_x|YoW?mPQ*6IpAe=;_n91ol22U+Nb)(zAVX1Pwhcr3ni
zeOnDPpB#vfEo1Ks`S372naFq6W~LJyr}cfk`0aY=W!0jt>A~lf7s+)S^Sd|V%Dozh
z+s0~|>Ih@L!b>prOZZz(3|4;2y0kMVU*3F8eRIe^!xU>dn*Q5b-93r7#OxaLjZf)W
z!2G4wWgAUaswWH>PQPc;Cv1uj@aUb|@P?-S<-ECw&hVrUT-mR`E(X5OWv#?+Vr$vT
zafd$;FJd$ipE}W)o-U;B#Ao-tq2~349Amorxz8Od&i<M3UrPDRH5`1xoYq#l)tY?)
zld|&l-m}HfS89;r_@i`Qt<#m4<R%}}9%AHMc>cV&o!Ln5uq2&`zkZzHxj6W!aZ-LO
zPXDlmsl$B_CLPQH6PwGAC(*d?(yTS*#23_GUpH^=yt5p`%X?w&XX@f?eXyM8EYLl@
z^Vs&Wdqz9pBiHucV0{CA5_$s94%I(e1nUnv&TjXw?AJfS6<@5UArisQE@srWs(HOA
z4;RA~r_wMj%<#a*Qy2BC_}63_^BI^`9L{9;8AoK5Q|5*RJ=AY+!L<EqfdkE6SC=b3
zL%Y#BE8xXwewJOVq>8j2y>SPeT#K_e#^N{Q-H*3hy#lwd6PMkx1#?Dn*H7rqFX3uI
z=i|DvKcSwoIxLiFnEMglfM;-O<Ogc=e6$kG&%aXr0ngOSAQ${mPAuo#JDW~tw<;II
zLXoa}SwXWSBjpz*)oogtKcqbm`poWTOe98=%KMhWt3+SmGRJBGi}LlAr{)%`cg%#J
zQP26=jP{G-2u38Ug)?3AvR7P_SkIgu7Jg{|!#%fiftcotSq_<@t8Wh1x;37r{)Z2j
zJf-HdnO;kekF)cu5p-_?Yunr0$ZgNw8L0M`4Zq!o2e71|c#a3ZgTJ-e@oU_6PR#-L
z^gC&O-MY1CA{UECSI9T!;G_2G=x?=w_Ghd$JV{&Z(L7GcH846%Z1q$Jh8<~s@R>_;
z)UGtg-+EkLV=Z;AZ20?!>Md`^3PsYyqs86O+xU7PeUjMy7~kT6`1;zpap-Juz(=c!
zm0@`GUF-caJJzgB^OnIyZD9}I`RWwCkq-BEkPEy*%heC=9ai5JLn}^-Dc4nUW+;@2
z4YnS&-fdtt+jsa}4lgf@_o6z{U3w-i4#SNR^g{~qe}!L!zadt{*6}BT*)f=-KD0fR
zS^^BN_N&<v=Qgv5eCKnz%{5+h4i9LF*4AXlUytUR?gm&3KMyT|i%;>ZMsQu+xBN>k
z`>T6ttnC)|t1VWS+IC7l)a+?Fb);FIjIf%H%0Ev&_aR(_H?jJt1?<2Rqu9_|{hi!w
zmwhyngZB;Tea!b+nDgDsG(da#&p9&}ZT0=uv1J;5HH99{kN>Pof#$e$YS6FegR%Ha
zSNHK8hB@Ns1l}2aUJnj7j5^@jSK|3));BF1)rSpP;PoiEO=Wnq*<4Q(*xp6{n?~&c
z4o&RpJ|aH*(pEhev3IzlS`|%Oc_p63RrQ|qcQfdx^WD@3Gy2R<^~NgBKOGIV309`?
zO#jNkJ>+Js_}<Y%xJNvNS-)9@>4xm`)*AF4zYgw0cv9XK4pU;aVV9q*`wZ7O48PR$
zS+QE4?<94-+2k6*`L(~y7umLcXFbOs_-7V*C7#+SMjznoL->39P3Jg=PTFgY;qltS
z>ZSd|3{{67{ygxySiUnWIo>U8{Zgn!)2~hW%NGOirq=^ATtiC#t&`8X=36J|AwG2X
zfj%<sS#OQ2r#53-+I{_A7sKb5y|#Rn-tn4F%y#km#{hE$u%O!v`p#?Nwd!wa%%Psp
zOG;}ypF8gLB3mvN57$e(&jSvuZ=vSq_4)v@2+MEHpy|AhT&v#cb@d54JEQxu@5;L~
z(c~H9gkJNSvQ!-RTFdWS#0fRR$Fm2-2_?wlyl2D-UH5u@U7XO$tk&;DoX|_zocDt`
zp&z}T&lorK3XI%TI&SD^uLoMh4K>W67d#+tXua3FGvbEQ=X4(H;)eQr-STtX&{?n5
z9>fj3ME}&w7#{lC>-Ey%q26$yTk~+W5%&xC4-ZYr<NQ7j59Q1o*fTt|%ImZf;i1)D
zE1e1tJ@u^qc*cm(1+UjjM?BPZ*IPt{zIe{(2SkKEgqzoAM1%$u2+ltu)UzP_o`?uV
zikG_&B0>cUTa%3OLQfZQ9i`)i?s~o3B3|g5qWES&yinWcgY%CUYE~@xe!S2%uRooz
zUAz=~5HB?71)4u&{7`L}f3bA@P>B-k+9H0aB3}4>K>SebQr2lk{LnzJ%~r*K<V64e
z|NpZV2os+|GU_K@dvPfQqJH9)=cgbe>L*@^|1^p9=q;29UH?FRA!@6#a2y;E{e9ty
zG2fpZ8}ofi8Yuebv(kpq-`|Gq(cf=>&8$<j<E@$(b9-(z(CDAf{m<>6{bM`b8~yX|
z^pZzM+yAA1yw3`Uqkq2emYDBPolzT&_WgJl)Hb8Nuk{<P_V_(@8cL8dPK@LAO&TZ0
z=RY!#5HH&I`&^BAe%I-v=;wQ0eiQxu*qbrm_oHQ^Z||UJ68-(idoj1yjEK4Y-ap>Y
zjURJ+%>*&uC(9crG~)632X3?f*_hi0--r{#-%ffz<MHQJ<iZBtj1#Kx_&v#<Jaj8g
zwDpgZGL!eH=086zqix5u$!8~z8)Ln4XZ*+e%>Q_w=^yW(iTVCJpO0>@`Nd;yubDsQ
z_OUO;d|#?e%=epW#{7PV>M^&kt{gXnqN9G|RVyEJd%ZVee!p#xnD6(z74!4k-if(=
z+n|{554;=meeA(;L*41l;75iTJI{u=G5kCA=9upzy?@1L1K+k@p~c?!^ct*v@cxcJ
z!V=wnjmE`%-+NTd_jN{uhpPMD<DYnCmV}3-iw}Q-^I7jbY4D$)mP^A!lODe_WhFrg
z59RsKR+`280Joxk25k?I5pN52#C$*KyYSE#Q6GkHvo?muxc(B~hKERusGoR=ypJCL
z-429@sy*IH$*0Wnb9g98)TiyQ@J}(Xx9s_t+vA*zxjl3xJO&=m{xdv=e~-Ey^Z2I|
zMZ{RYmMJ1a&p*cRV2#$l7!jK9HLyvrKHW-0gqC`ZTEF}yBVyS1=7@+8i4ye_Z|tZD
ze>dXM+u%C`Cr5-(%EO;ve^Va6k6QmtD<Wc?@8DGtG5lfF#)ug9E4Ml3`?gzSe!u#T
znA;y8`rns-E%2`e{<Xlr7Wmf!|61T*3;b(={}&77>(TBlEsW5E#<I+yX4u4QAl#z;
zWFnjMb#L3MM=Q0gGn8C6pE>Kbxz}hvk)cpzzDFMm)l$z3wM<|bz-t+=(S9Py&V2dv
zw`s2y{csNhZ4bm_jsM5zBJ=fntxJ#AT|!Epn!S%dS1ab{f?en9-mc4QZ5%R47G~P6
z?i#8S^K+5T#Bcxo`PTyfTHs#`{A+=KE%2`e{<Xlr7Wmf!|61T*3;b(=e=YF;KMTnD
zb3VT6sBAt+#e<%8PzH!)d(=EY)OMpPp}3EW1Yx!tsd@MlwY{r%CdVHBF2C)K9&P?l
zA3NB8g#Ut16tKPFKeh+^4}bjqLblic$M#_VaUO3kY<s<bY@hGFUfaXpj<x-z$J>Ka
zMDP>+_#fCF`S7=oN)^FBqaXi6+l|6J{E7O0^y81W-RMk=?a_~a(sm<ZF}4TC56&*Q
z{@{M<rVqEqJbuLE>pNq6<9}=qjvr<Jv$jXsH|qRu*&a1DaL)E9`$lcApq66N^Wk12
z&4rbJyni2k_!Is7Ub4O1Keh+<i8{ZswwL+G_UPwV&h{w#N9{lQ`IWal@*m%ietu(Z
zS0;M+^T?zAv3|C<|Ht+i>t}o0e{7Gjezq$cJ^YE<fAsYWnyvpl|G+*`{u|5o$VXp~
z8o7(%KVh~<`A^jKM?ZcX+oSv^YJ2qK*Rp-|<NX`ad-xL^KbS!Y&bPMhqaOa&Jlx~g
z;QHe|_Mf`8N6lYEZ4Ztg6<@*MSsVV3?;9QEUytIazU{;QvHiO3aUT0m1KWrGV|zU(
z=qWD`e|ysQX#M_&zYESks^5Id_5_c=AN3NPzbD%~e0#?BM`seX)!!O>_|He%|FAvE
zzoYCI-9A@sZ}9l5QQM>2=bG(N_z|@|x_z$OUiTm0k8Yp8Y_Ic=?a}RX!}i+$*dE<J
zwG4Men+JIK$>98hpWq5x+P>ebvF67XalZrSi(3Cki<;efWU@UfzN2sN_T>NleX!5q
zC)gfk|ADs0@qM?3{^uw9_s5z8&GmT8Ba6rU{(9RN|L2>J{t<ou-Jbd{$G1K8|MLBr
zwlhJDpXmEvZ~H&}C;Ik1wkM78?U?6(^1tjqIJsb+A?n(LT?P9O-Ut6>vfW7Be{Aoc
z54T70XG_~tTF`RAhQ~iwe7}(R2*zrn=I^3!e^gda_Hbrqpo9N!=O6ry^Qh|&&L{YZ
ze*H6T59VKjZPB+!z29SdJKF-^iM~DR{38tqmbNX5ulzH{^$oQBpYa|2_+xF)#lMP0
z+kf=ykD51(zCHT&uQ!ia`SJ0CV+TLM{-e$>nLb07N5777{!#uNX?xlKW&2p$gJTCj
zQ8*L*{P)<t&o-wKWB*adU!1``n~%S1sUQACKfhpjCirgjpXmF~WP4P6MSUjv_FA?F
z>lghe`u2ggN8x(ZXQFSPX?xzN4Ub==Z{K4(3XJg+efuA_ceFLY#{bDbT4pj&Z(DHf
z(d`#ypFeExV_VdB{qy1aMfqR1XCC2s^lJ!?ANBo{wtM^VCu$!t&d>HJ|9||k82%s1
z{C~gyKW$HD`~UX+O#kKk`TxuINZX@$<$pSUE!$B<jGyS&*X_UTf1vGIV|+Vi{4cgW
zz?tYj(f7apzii)Qd!#Q%t!=QM=<AbA@cpm$vpqP!sI`mwe(*l{uhxJ0e#`%|y_@Y(
z_!xDJ|HIy!M_W!+dHkt2gA8GCR!qSI3M?@|F$jnOsuU3=ASz->1*rl`fr?ZCDh^Rf
z8|OIS2zqgDwcE7wY{Yr!Hcsu_9cNV3sMy-#@cVv~?ECh6ox9IkzxDg)w-#sBt$SZS
z+57Ch&ptzjo2&iHz$4UiDqd2w{U!J{0F(TS7w!B>z%Bn%aI5_@@S|6uk4`Vei1zIQ
zn`ZDT547vAz@OUN&;41nfAK-MHrj0-|38IKsIt|6Ciu$n;g#)x&}mD+SB_ubY<U;4
z%%T684*j`9e*w<<MSP<Z^p9gg8y|445BOR3A(y{va2ek;N4UHF5AKflgkf{5U*tpZ
z2VmQz@h=6J{v|qCzv$1vu|#Ui5Fdd{e1~`met$@dJyfLq<H0-UFV5e5v5?Q<oiY))
zw7=$JUkbjCLMTJL02lv;cnQwqbJnG~*c)JS!`Gsg^}n}az}p)=j{78Q?eQT8-w(+e
zVBZD2SoHcqzMl|ayKudJDDGqT&l3DQkexJtjSxIc@vUyruj9*SF5;^-liLRe8@q$+
zqVvOd@W8=CaOO8-DTVs+uiX}dKd}F-?U(i$fj<MB^RMX8{skev7X>yc{|j*OPs>Yw
zmEcc;JnPo=kMr|zyZ<KO$M>>YzsQfk(M8&#^-KK~_&K1H><^E?@fGrGJ@(P^qTfg7
z*sD{&EIy(?1ZVEhHf`TH{@^k`^=g)lUn%$^fYi->7=Ic6N8oD=UODtP;M#Z5FZOvy
z;k&!oILZDH9836#JO-zJ7VW>pC+WE`?x*uJb;xH9`5fGee*tdAzXD$kn<mBIJKAoa
z5Zr2?1l+1W1Gm~I2bcAs9$zKC1-R8dm4i3n=pxGs+eh?=$JqHFgNt3FM9U}O`wHma
zHP4iO*-i5ixXeF8ya0bJ0NYR6kn-dHdn}$qf&PtdFwRrW6AUf~h~oa8oOLp1b8z-W
z7Rh1FM~ZiQb@?sw1vn0|+cG3yIpk}_hvXaZ$3eUJ&WdOs|K|S53B&Ct_GREW#B2A}
z`XzoN@a^C%nu~mZ#mT`P9^^4N`=>5Cekr*A{ucMsJXd_E{sR0?z49SmDK0i>{SEjY
z0{VB&dGdD8e!Ik2b03`ZAM4ijOZ)<Gr0BRksEYEkrcJ=_tYn4D_@9BF+;gp8cm@7=
zaP~3H55-@!A;RJnQ+!)Am-b7+hsJN=8Thv#%|0&s(f)CMMP2(-x7IKI=MG+ivwy6V
z7yoK-j(?&XAKUl|=gE0I4rAFEqwPx(JWGELen&%p0nYJ3+Ft6H_N&1UGPr*Vo|!SA
ze;gn1d-hy>r2XPw0X{UoO8b-!UO9N};0^emh_9ZbbbNX7$m0G3ZTkZU4;?%L=lG=y
z?UVQ<;EW}Uj<4|4p+5s()5~i4xqe##&irA~T=ZAqm}19_`_Vp;_aB7cmBco-v6dhA
zFL1G+vMk!a6kOIn9bMi(a&T+>slcuAfd_8%pGDgz{)ONNcX*tq+P(yQzn%}tXW&?Z
zwYoKz_>|yWKe1>o_1EABDaQSl#rMJ8u_L!H@IMr7UkEPq&k&Clmwu?_Q*fEzhvai`
zIldp_1-Qg#h*#iuht1-<*uP7^tpTU~lemA{QvS$3+Wr6>DcYU`l6jh(ws8N{!Al4C
zAA;Wm>Gew-wEo1w3-E{a@&Vpiv^>9DYw3@{E&oOi-Z*%K&TG}r-z2qo4Q}}t0$TDJ
z_@Ri2<c`Eg=BEPOnm;RWuKy>=`)73dDY+y1CI3QjtAEDe(!Zq+wx7u7;Iw~|{t}$u
zFV<t6ZvQ5>^P3l6|Ebq6bu6nNd?)yBbgVDr62IUqyZ=St*7_j<A3FXM|1)s*f3b}w
zX!}Os&&4*0op7-)eE8D!Ju((8pMWEU$7?s?B42<XhK;OWY|!$xgZpRO>(>x`AEjIB
z7yo1M)kggpIM1)qe{G-GUxG{gG#C9f_})quAD6|4Coiq_cK~kLAAwu?6Y%|~S?hB9
zW&X;~S-Ss6+b_HUe@HK@xy+BzqnC15bCHi7JOMun`X}Yr2>d<+^-Fv!aC3eF|75RU
z>R^6JdzR<oS$W`GUk>ueEa}(&N&PkW2(o0FOMJ48_>Du19}&2o-wwv!+=tJNws^M5
z=HB@>&mL!U-kfCCzXi{^NB)#>PS2lrgz5A*+luu!K1|~IrFdTBRCkR)%S-&@6tV{Q
zw`2T({)<spfESByzvL?1e`E0S>dyYVpu_6=#s2aco&A$|bq$`qh&t&jUo3ijN_Q@e
zze79+xB7Ph&b$!WmHI1ixX|XO&Yv}qVE)9<?ye6}Ugi*OUk?6$u*F^n-dg)*{EDBm
zbo?kbP+oWj{@z}8h)0;*kOFPpy8noL0gfTO^^bjwMce0JyA;2UF6SXQ4gtq~Q{+W|
z2EHdYifzKBf94K80%vR{$yW}}$<eCccksZ$LkEw*rQPW}3*$SBcls1NcmghcfwC;R
zeKK&FpLPE2g8it!0RJ}n?-~mBMdwfc0z6w3+okQfi{|kQVI#IJ5cEa!5%{4PKLapn
zBh9N9b@z`7qY84dFL*JYQIBnt^jF{?24BQWbZGr~-kpCGhTWFw_g`Wk|AgQeLdUvS
z%8$VDsADfA=*zPDufuZ!!2^MK*F1T(J-%e%T)%Sc6CbpE@fti+9c)s3Mz6&)w!w9d
zY5Dy6rRz7MgIwZYf`1YDu^u|4ER%oz()vsDu{^jne%9beK~Q|74qbmRvgIQOPr&aD
zos;zE;Jm+X5&KBd{uOV)`8C9UEuiQimp)g$u{;04*l8}~oA)MreHnlUy{wj(_(kA1
zfO8++K5~Ax244rp_SIbM3EsTC?Xg=M-&wq~zR<xVaPgJ0EV_LX@VybA7l`pazdPQ!
zDSJzI|1v-Cix-QQFTt_I_&@&1`YL=Yo&g0;d8tCnSKwmb5O2V({PW*t&)*@qHGlKB
zAs^7&CVfoX*MNTrd=W1hL&+sSihs7}?;6~izejKPylv3Evi(KB{|<ZpPQfL9P}3G|
ze-3WV-!-^3e>M)zhodnz(sndJ*B?4~0&dlxI(X*bxr2|ucWa}z^dIe){#7`532w!|
z2Dj#K|6lNYR%8Bd-eu3<MPbk1-oGvN4{0OaJ^}a!xGs!Q&^!gd5!)6B`a*sOe5OqB
zZhQW&!Ep#NQGfCtd;ZSAw;1vbxHW&*AHXw8F@LXx4k@%>+N}PFJ-&D!#qlS`#{j|-
zqh<bo%$~pfkK6M%7iUj_ZjLPyW34{}$0On=&foD(_WYfJTjS>l{3zucJ}ztj+9B_K
z%GMu%-`mh1gIn`=`Wf7-Xv9DJtUZ4h;MVz}3OwlT)9owscLQ$C-}&e4`MUz&4f=Iq
z`^xxIJ9q;wxhgs+FZTJLx99Kh3-<h-f?M-<4UQpfJonKCouBy^ZU06NUVvNvRp8e6
z>3zvQ{;B`n9zRF_VUM2;xOMy!RF3fz{6@q~`u58B1z&ZHpWx>B`8CJ*32u&`;O6-G
zpZ4)j@m;(BSK!w1kN16h{A|E~g`nv^r1P)-fqner|CfFIQ`h$R>HpC7F9f&7&(tBG
zJ9q(Zjh{8RHGc9p*R128;HUQZ8G~EnX9^ymeK>Xwjh{KVHGYOav&YXAT(>={X~&=0
zzP`-Cb8u^XDZs7cpX%rK`03wlkDnR1HGYP_u>Ff1JO;P?OTn%2a|CX!KeJox@iY3h
zJ$~lka(;CvKML>-DtDxPcad$svB%E>{KMFHQTE5X9v{-*+T&*fepe-nkIU9Seq)cH
z8MrlmrnlPb&-Bms_>zNL>(AnU?eTN;7km87Z?o5*{$K6&XZ?4_`1udpzYyFUKOOS9
zgBRfD_z7-~pHr*M^`}3*s=a@P^SjRPJM@1?;MVw=fCv4)T3+%$1GmP{0AJp<&L1V<
z*7%t^cm{5bFC%bk{48hjTTi`zL+6jYIs8TsIAb7dB=%o9f0Tm1rkBTCTgW9o{`{);
z*^p}l;$8Ruasj`=gl(dmyJ_z2g5OtMwRCN2CC_)Yd9d3m4<VSiJ`Q)s?}<UFw5{kD
z`!n#xsmb*hxVg@<zX6x_l{)C3%#WULbKk)O2M--QQe4_V+ZQ`{;@~Ox0f^rs0_!ul
zC|`X5=hW^AAtNN`kFkwRxNiS^A3MJbaBKdo!L92rC4Qso6RK`}T$X>?o$=dH*e0=A
z$t!T{_`|y^em4q2()J=R`4xlTXz2Iwds`m{XZ%Emj!y}09e+faoUHjX0pFr@<KwdV
zwF0;1PyY6lb^RqjV3m1(qX4&#Kk7yNPBCnn82<zD`{v-%$Haaa-%C7vVSj97>_i9S
zC-HB<t?Mr(z8t^0m#1!)W%A(G`5Pa}Va=a0xFw%Dcn)sOpC!08f7Wa9+u0Z&*TOHI
zU*kCizo~g&Fvd=EiEjvQ&7U!N(93FhiGK=i&7b~#?fEkX*KLog+V+w0HF5A1eC#WQ
zQFQy};G92yvTMhL%k`HcwCB$T+?qd=!|nOgJHnnniz6NL5BT$7|2>w>Z~c?@%kUet
z7Wa>_=g;6+d;Uzpt@(3woNa#%F72!HN7}b>aPN3q-gof8!9&IM_#*a24jwyr0&dNp
z`TbXUKSkS4nm;rAZmE^uBXDc}tiY|~&*CI|{!CA{=g$({I{vJ|H^4t>d+C2NeuSsk
z^Jfii&7Y(7_WT)au;<SRe2ZaU0dCEoqX*-6>!&AQ{}?^go*zo^yQ6;x$_BkYs2}E-
zKhJQ?pD}*#8M>KYI=^N7h|a`s)M9<N9$bp9-#^=)KO=B!{!75E`E%ruFCDxFx8_eD
zzXfZ}pW&nI<If1cuWZeqDY!L%=HLMW%lwx<py#Io+?qe*N89sf4ld)XZa*2nMh;$p
zTjNUwZq1*~x%T`SKE|FuN8ooe;!}dZ4xIU`<0tu>Y{c(=_e|oT<J*Aa6vV{wwRtRm
zGq>X$$5<#Y_aCO`+40H2Pl1f|Es+=dYVbX=QEV43<6q<8-X_eyhJ5JY3Aj~%>fo7!
z=MFvsmv*7=ER3(@XW`%_xRswZxHbRziGBRoJkFl~iVN)d&)aMtKZaZE`7Z;%5iyyR
zKjDS;{MUe6$B*en_WYNFTk{{k{Ata9%@ge7$8wuJKh)sX@uUAld;aq-x97hG+&X>?
zw%f;#%@y|i7hGxk7lB*zU*?b>Id}<f&3_HJHUIffwvQjfr`Ypf0&dNJ8F+yF=J+RL
zpdOz`;MV*XU2V^Q8MrmR<PJUpx5k$e+?t<iaBF_bp1R6=N$<PZsr?V0wsd^PIgW)~
z=8y2{_WV?UTlQDr*8CJa!=4{P2amw5`6+eqkwbss;H86C4qk&xyL8cCK0h@M?qzoT
z18{48iovbpv+x>wermvD7(QwKh<4h?X9@TQ$V=a340L`L;MV+<Jlme1g6G)t(+J!;
zzgdD?^Hcaw_WTq)-#$JIUhEjZ!SBAx8;@ZUAL*Y-ZqHBgOYHe6dZ~SUR)Sl{XZdyZ
z{8WNl$7eOTH9rNfu;n8MPr$ADDF?Uar{Y!i@mcw5dwy!bt@+7+jXghw;MV+9fm_!H
z{ny&#OW@!kxHZ1V;MVuo;@4w*N9Qi_l5>dc-=Z^l<0|inzW>V@p!@#_+-koHoYx&i
zR{F>I_{PEgH{tv!gk<g$dFfvzxHUdk4qk(cuhh+={qx>zpT8Y}^SANVbfRN<u`hnB
zef~2Cx6aQ7|7`Q(?Mv$eF@g3={pCCC^S3^Xx6a>2|7zQxflK_Qjak1OzvT`-a`3{z
zO9!tMmpM?|S37v);NH9J^S9x@+1EdVciZ_Ffm`c?6x_Q08Nbh7ANcRL*9Qssp~n1{
zf52WJ)ZjNFF(vlQQJtUp2krGi{2_aNP=Q<Pg9hAMA0!{P*9Y;(?c>+rCdd2-ZXLg-
zpR(5n$*1l0LHrr}_%#E!u7Ad#x7P<5xV1hQfm`c?+9B_K!PXyuTk}f{Zmkc}FWJYh
z`IqhWK?!cH4{GoLInA+8kAE`1dH-&&4@ThD`k)4v@fB6HMUP*NgM0sBk1qkZHNRHi
zR{gbuH;(%Kuh{cz0gfqZ;{2L?)t;Y5;MV*ae%<EfH|+Vf`lda<2LEZ#ukp8S`*U!K
zzs@h2Uq=pJIC$ycm4nxc%NV~bKONlr&XRva@;<nAeKh)>eSI|izMcOuxHZ3K;MVbX
z^56FS8r1gunu1%`M|1EE==IX}8~_+!8DDB}bAJ7yV}AXSV}1oU=T~rZe*Ljye*L+9
z{2l+wo*z>1yJLI^RE(CbFK)5t*X-B!{F?s8KK^dNt>f?VclP|+fLrsc|9g9WjlnJX
z)WLIbYkn=kt@*XS)js}i{%Fsy!T;FvYXmNBD}6xce*$hDe|vwj=hp~a##f|JTlDx9
zJ9q+a9Y1E^PlQ(5K6wA_pKYFjOaC8|uN*x1Ut9mk!GpgnjgLe1#}1x>oAx_+aNDZ(
z_h(kdZ?2DN3NGtUIY+?u6JCJJc@3REv%P!;elL7x8RCsY-v6sDAA%40FZN~Nmi;C8
zgL~U_{6*gXo2@?qe~d9cmVaO6U5xuvj$PruoIePsrc6GXwYk5`l=n;M<{YQzchT?d
zI@PX!CHB~D+58rPOMJ*!bpOx5cf!9(_WQd{ji2AuNqgQ2xIcMUv^MKZz|H;(ZpE+O
zeX4!F5ZgxQAAP0%(H^$E=TDi>PY%EzZM0vu*Oa%}Xuk%7x5bmY*u1*?l=mznzR5jp
z`^x>Myr&@!9Ak&#6Wz;}9|cqG?^`mKk|VnPD{w1+Bb?l_cyX}JgL_Z4&wpn7>iQ*r
zQ}6?Orn#)oMh;#%xVP4BpY*;quaB^Ke6;P~2;B0oa&Ye$JO7ho?f6&6+dO)J&5M)m
z@gZ7o+c(-^bMHZR{wAl|@vk0Y^XLql7iZc1GdkP0Z}bS8dylf)KLoe>*XUfE`{&s_
zJKxUF3f#(1?{PK{9XtWI#?NYt&7-Y0FD|kD^DcGR@8Aiz)jm~f^Js_7i>qw=YH%xl
z@zpjjpKkN;S$6#i_(o&?EU&TG7v9b(?_5JZdA8ku%I8dtpN~B>KQs;={FCip3~u>X
zTx;9!KhL&5eZFn~$iXXcvwyx|Sih`qLvY?-%h>7o2~Qk62j6JOH;(#)7uxm54xWKq
z_1EAB8TR=vvg?l=JO#JvufVPPy%*c{hYp^ATlJUV0sLo?<8XcaT|2m!PnplZ4Z!aK
z-7E7))@PAJK5@ur;5(r|Q1<ip(T>7ucNW`z0?xWL*T0YEzr?mb1h?#u9rCF|J_on#
zzZKlFKX|Eae*|vXpE%?*hx`cKvVZ1fw*4WveAf%j)E0ew5rbRyrw;ktAzy%7_V4?0
z+x`gLvOfX0?9UwXBZqtmZrQ(hoo#;%ZrPuLTlVJ;`NAPzfm`;kdxdR(0&ZPD$ic1a
z^XaRn%<m_MubDFM-^;+Q>+{8Hr^e@>hVt9He#*RlP=H(CuS##2GVd>Mz^&^C{_Cd9
z>jxRQb$@yKhAH#=$<bS;%=6<3xOII#f9sU_{p9RzQ|9-R(|?{a?=K&Lf6@4URr<~;
zZ#5cjMj8+AdVCszTj&2vaO?b;_b;}5;NTIsb^Ra(-xvNZuCQOupXBeFGQXc(6y5qm
z&Zkig{TKNf+`2yR{ad%bVEiP8I(`ATb^V|OUk6#PP4xN8u|4me8n0WhOIxU)b3g0z
z9XtTH&Ob)r*7%ZwTh}M!_u1o%|9*RXNx-e^lNtDi-q+T7{HNnvf!~O25<Bjr+b{co
zJ-$RAw8xhc+!|kM@GYoQ+Ft6H^<VrUdwhvLHf4T)Gy0_6e-iM!ubO;)GP}thU(!$6
z<4f}CDf9cAHTYMI@um2jJ-*c7*7)Lm-X32fa7#XM@C@7<UkY$*e5o+Ft}^0Zf5{$S
z{4d+%O9&qH`6W4~^FIc+#+L@%8ehVHx5t;r!DDc1d`ZD&eBn867H$8?!7Ffn|Al4f
z_^kmy9E`D%F+l4N|6{8CeLsmE^=O`ezX;nzw{RK%8}PN*D7shj0LlN>US8^;evz-h
z_XZax@-jX&;4;3*KH5INn(~go^_O!XsN*N|L;Q6+J}I~rp91^<!@e5aick8DDen--
zPm0e7+=@^9O*=j*xD}rq{62`!*%RVZVsR{OtK%#4X9a#I$g&La2K;eG|4zPZ^Xhw3
zUSi0HKd|LT|25@pGUUD5)}Q>)=H-uU9{gm=y9KeCbbZzT>6G_7a9(?pI6nv1KjryM
z{?De`-(M$}9MQZ1x8$3j+w#@TwtV%ADes59eM9w^zwGi0y9~B}4K98S<_EZyKmM=m
z^OF&{r9TF@^rsH_4BX1U`WBl<znSvRGxBfrTU*}y-IRx~xO>5h_{#X0{NC1I{=w$K
zA8nrf&y;sF>YkLJ>7S;&s^>%b5&hYg5C7Me_x@tbH{f^#Z)@LB{nc%De$?Ox_OaFZ
zDf5f}S6e;+xAH3jUu)=39ef0Ss3BiD<h{Rj^9y|&@-GCp^e5nJjQVp2FTt(xsr<V=
zK8^li%a8C&?B9WXlg7tv)wEfEHZ^UIZ|U@OdwvU5EQ_Daf4PGf;8y$B4(`uPo9z>U
zTl!OQt}iCF|Hz@g0=L@Vo3(ieeskYGGEVFHE0~)$$BzcwlCS4&`C`GAAMG-2jvv{s
zcKeUO#V_5zBtHspYyA`KX7haaX><N*_ORs>f7)FClzZ9wgMDnC?Q8S;j&}d6?_~Gi
z^3Jw=c^6xLbXQw`bT_;I=XbZ;cLZ+DAC*JC2Dj!9?;dvjKDf0$N$+X%YQJf7eG&$?
ze7<_xT%R=i+xp{0n->S#+&|dv-`*N~e5k;!@ufV(md_8h<+FR+<4dyEZr>E#%CC__
zz5uuKs{*&?4;~y^JOnq_4-WYp+?t<ChyDiKnxBHhY#xJK>y!At_V^NpwtRTFE$`#x
zgjK(Pq&+@)>+Ja{0JqvNcJK_`YTv>kUxQoi>mOz7kHD?=O&xp$ZuRf{XuE$W$Jp}m
zv9^40KU>~E&K@5ca9&?!8CqZX$2;=p1Uvs4a4Y|s``hx>iMD+806Txn$o8)Wx7x2d
z$&UZ%WLrKz#g<Rj+w$=SyZyok+Wy7hJpaxz)V`^M=ivA3#0TXI2d}`b`wyejY+gLn
z=E0fv{1t<5Htvrv&$fAZj?G7pvFoqEAJNBep?~N3V_Cn48}0cscJLJ3YTw);Ux4%c
zEz3}TR1V&NAFX7mN1q=LAM40Z2TvV5cklw-%HPT%-+)`+5Ax5m{R<sD2Diq?c#}Oo
zhKVg7o^Q+hkF(|d3+(Zgoy(d(0&r`5^|#pLV-0S}R~Opyql;|$9D~z;B4;O^-$}RH
z{^j6u-G{l)qWgCNZuQT~!5atnA8+dq!Fl~p7j0kc;3@e1A<VHsj}LPHZ2`{bhq7oc
z<68+X*Kai!`39WlLUqyhc~4k6evy4N_raeHAY&`{A?M$$Zv@W!m*gHYd~CV=zDaV)
zwE6tL4BWbYIs&(@AC}-pqE7K$>Zi}`wo9km+?&LGaA`mBQTrc)KS*>@ISRSNHv>Pe
z+dQ^G%a`ER_+Nut*YCZ{rrZ0oS%vtZ^@rf^23y2S&SQ~F{2OrIzs_R_DZGF7SVV<6
z^rdZG{hI6hXXA9~_(SWL_-5d1dc{Nb72wwM`-3M=oA)P1;F4Qfzto>N<THo-2>dG8
z&pO0EeSh&^z*(2(IzGYWOZ`jRC;c-7=lxSGLp%oGr^ACh1?T+@(%-l%+gJYfw=c=}
zYFa+7A6(jp*DzUh{v_aw$Pc*(Nx10GcT9U<$Hsu5FS`EpifQk1Y~Kw!D8oW7eYyc(
zvqJwav4>}#b@}(qE2rCg1$6y7zQ1<x;Hqiwuc&h!Ub=p<KX}r#w;uQBgcErBlxgqd
z2o}EP*v0_6Ewew&roA1#tmKFGzW{$bg-|q?_$SYV|Ike~WM6*GwD%Y8j5YLF9`U&o
zvVr-MKX=;u5SWgSu0MX^w0Aakycsbb%d7YoFX`52l6z3u`X}R81+H}qm;Tj&?~jdQ
zyKuRF8N77be12U5{&)y+4i_6}zx+OY1#XQG(aY@lBLSCOqirnIFZO5P2VmPI`wQ@c
z3|@ot{K+JF|K)c5A-FYv#o&yu#0DRi+YiqBf5>GY?cWI8il2YoaQjPqLU2oe3~uQ!
z!B3{qC=#Q8J;U?n@fYp&U(wB<?GF8aw13<`z^(c-aI1Ys;8y!q;8y#3ue94Y1h?vs
z!L9a9!7cxChyDWG@~;NB{PSOB`xk**{w3g+e;N2Y(XMM%1G9Z)d<b7XZT>!93eNk(
zd3+#6%a2}T%h%vme#WoujxVL}unygSQgE|<z!`taOMX*c#?KP`sGdt5ntRtzkDre)
zBp-vHYUm$<e;J%b%S-=BZ<zLO>hK_sUI+UTUzS1n*H3$o?C>D3z~gDp+q^<vaw2%+
zv={YE`_H=gcLIJ{|5?vZGX7NHkLfwy+M?Shd=u8M*h*d6ev!|?&oX!e&hrzL*Y=6L
z|7M$q4jzM>->(7Z+Hq3-xkJ8i$XDRj`t{Ja*z4CA+_WFuwBI3LIOHpE)Bd+Q><2gP
z2RH3^$QKUz3f#2+Z4UdvP5Z%3`yKLyL%sqx?f++o{ouQ+zJ-s=#@7Vg(*I$H{u<mm
zKJwmf^8nmBe-b))1pWc|#5J-Wzhr##-m!H4M2{~rKKtO9F4{801BZO*;E{vJ4xWJD
zxwlV`uVR1Z;3IIkzg_z$^J4|hv6e-1(O-jG^RM?#dwmjsTkE43+*%)H;MV%SaMWLc
z%Usxbxjg?HaNNS)&Y#+UIX_dr%jWsJ?fIzym-FX3KPA2uIM;V9x_;peI1Yi^F-Fd_
za{iV4PTz00PY!Oa9}94+eQI#4ef$sD@eRSbb`;;}r(Qoq;OntXVk2DEr#ZNle+9T)
z-w++tFY&9u&G>@90`Xl$#Y6GUKjNq#+=_1nZpGL8s2$%B+{)h=+=_1kZpF6%x8hrY
zTkEsN!Tpa-x4+-WeAVqE`RjeWTR)Ef#(p}#6YyiOjXrW87R^WCJikocl4F|J;G7#+
zG?)DFK4J3!+?qc_aE{NSoAt1MS--~Q7++2&=nJ{zclyaLKPa#L6ZsMNnqE%opuE^$
zfm`j@fLr<L-(=@!1a9^J6x{MZ2j}xkScdE`9lQazjvtdxO?!AmxOYNVMf*SFBj>Ne
z&)D&a!L9ga;8y(&xYa-W&)WV+;MV#w0k_tdnL~c$kT1b^B5DC%(m(b2^~KM1>jTa8
z`QI4avOfj4?9UzYg+smqx9nf{dE5R3T>M4|+M@ec>fo7!=MFvs-%BbUsK0dZ+M&O3
zaPJFC=Lf|M?SBj|>lZyf$@r6kbADqP;v?|2VC?&H4vG55>re2|;NBPQ^WOnD=LgoU
z#}^r26Nh}}kT1cdeYAe@zjko%OH27RB=0+T;NYQyM-Co?qdD3#WM2aQH_)KlrTw4n
zC-F|c?BM_2t=}m)q(29L8kmd`+>iQY{PzFDmXE+K`4apgecif#$v^)qHc!CMhrHyr
z*eCv14jxrY$6u6X(fOY`_z2t@p9*kmeOZI!C&Jn}PWvzRr(d&=uSVe3`k@53?5n`d
z^@&5j|8?8H2;5wsfLq6pBXH9{aBKZtgFn}b?>8OwgPZk(KOFjx?NVo)KXQB;e9Pw9
zx9#=G2>h|os*fRb|MtGq*~f}?{>b<jfUj<?T3SC)UU&?Co}s^R=&v05z3+DG51Jr-
zRM#Ikcm%$om(}vpKXUL#fHTL3cmuu&#-h3SAAAq@M`8WHZUq<p(GRA*)4(R_&%v$!
zH3GNJpB3QviGWszZa=Ai^xxASz7E~Ct>!X5*5E_;Hwq7G^grmo2Yl4>lGE`Ir@i;A
z@Sp2Txxe6tKkkmNbbR#s(*H?!{YvbGsos~)=J8c`{k;T#9kyw%^Edfv7yn7|&3<mL
zFGk?j`OOlX<C`uz|7!5p0&4rT{n^cq`oUie`9M{m*XIkrm~Pinn(O$5;5`1)^)HJL
zINM4WZGQ&729Ry5+gIAZ0N<t<^-x}T@XMw9-)IAi<~8^!-RANC<kR?z^@YD$IzE#f
zG*7_g`A3?Iy&3qUke`bJ@xHA7TQGiNo9<(pN5Ag)%J_+YBk+TI-8w#Ee+4ejhY%B}
zAOBka8t|dxXW{;Dy890(JET7Xm-|CB7x@I7`74Zibp09lYHX9X5iaK+3h+gP*Wk>L
zN%H=0?fOG-J@-icVt)iK$Cu)Rwm$*qc{^b%<umZ1^WUPs0M~6V@-lvx4qiEU4KDd9
zHtPKH8oPcU+>#H$pN0J9F_aWNzCPu5-Thmd>+zukKNIq6AuMgE<!}9cC$G7d5B@Oi
zT?g5f>l0ZsmEfmBe}H}1PAppg&9`>?18f(r_4|M9?k}KiI)3tZ49@j0nY5#hZw7uJ
z%s*?Cyskh0Q&+#{y8Z(E36Nh@`oD?^Q|6!GFVo&@z@!i2qo?nmdm1>8MK#y@OYj2`
zAKE_TUvpbGep0XIlApm}?fi(qFX`J?<hB1V_}fzZ3fJ}(;P2?`7Ovx){C#Qt$9~L0
zF81Z%ynk^K+jaX$`<4Hg_P*8IC+$yp;iFYE-aH0V<`-kgqIoeh<9!I*ST~O$Su{^)
zXWH*~a=X?q_Km;~Aw<#og;(Gy812#WVqY{j<J}kbuTfmb_l)_Ow*58N@lC<s4%q-N
z>SWRKf9vG~Y!|NOgN2##`I({kN8ob&C-PeVTXtEpPq@}!fxjMgvwrbk%b&4pC$G7d
zPr?5cvb0Udmvu3pf;-HNkAH^pD+1^E&!Y23+9v_u(cwW}gCF1Xpnuo-8SFOWeFfWD
zx2|92zXp7bVpKtS;lb`RgY&EK2>cAl&|it4&d(hDem&RzNqj1BUVmWG_KE+sgE!#o
zds!_n>z8Pcj<dd@`g8DmA-`jA?!&_Nm*+cQjUP{@F3olO7vSt)tb3^b8vF-fk{kHA
zZ2Ww+KhxH$xz=BTKOW=536PWg*ZH~YzFmH5uH{4U46^iH<aPTL;O|1PLvXQyT#mn!
zyUlnH1W&*vKAIQzn(@8?#<5Abw(p{#vrltvUk-jQ{M!t99Y5;g-^~Ft-W6yc_5sn)
z`epu251jEX7?2nH>os=&@(!8tc7gnQ=pV|D(b^er6WB()bbKVgy!&+h2Y4BW%GUl6
z{8RW$`xyfk#wSE;Fvq_R&iPYw9Ut$o8E+48i48us{SzwMZ9e!B{b$*S@!@B_V(@kS
zXYHTx99-_d(_HLtz|HmheP`O-q(0p~Vqe^I>gGNyv`@y59Q<e4#@rm@Svcb*U}76S
zE|agp?~iS)TlS%TX`kTmneqAgLHocZH#Hae6nr&wi*5M0EdC?#gL*FeuzvBs0%zYM
z8{*y(Gu}xCkHIfP{)>&+b(#O=ku%;)u#L8B{Sx0~-O~It#QmdYyf;90vDbmOR=*rm
zmEb?Zwlx!Yar8|4d_#$y$V>eVxRzbXgJbOciogR1iR~gU@l71^8TfG!nq*%IF5@?K
zv*`9~9P;6@w*4{qJ)v`w{i#DfcgPnG`N|>RIOP5N+4hIv*7y)R<Wuky5g*+?Jbxs=
z-&TP0{M{tpfIkbIeP8y`<4bnjOnZMW$Cn{qgWn5mQu}zv&$Q<UC+UwIJOk(TyGin;
zL*6^VQ9pRr>lYui|0VcK!6%Kc$^B=%!jSh*?B+k}*7~LYrQp=h*lI5Q-+w?C|4BRr
zKem_E@}j>0x5n2R+!|l~XvTXr^fUfizt~rRUt!cAp481Bl;?|u@s;@@0lyEnP2#yj
zz64Ku`62tllO6pFd=2C!xAAe={E&fPi*5VjHKgA^1?#7ti4HyfW#E`%ynKcH8faq-
z$_LGO&%`^6)-UUa_*CRS{&*X>j-Sjg`9mOu1<-oTahgl}<d4Mh9TrODTEFmM<BWGY
zShAviX`l45Gv0gqx<&rO=Wu@R&aa2(&3I1+r|-gb`xfAvaDL=X{XTeG7GMAT8SjIr
zpYhT06aT8m&9uk=lH(#T_7$6Fy#L0=0I#9?^DQ&p8^QbuJi2hkd%D3(@E009zG%jK
znZX<I3Vac-A^XaUXWH-Y2NQU)b*BA(q_iz|Th@Py$Io~lL;ToAI)2i==_NDXj}iX}
ze5n3p+l+TB^5gp}xWqrXV#d23`ZurO<9J?$^%W+7??d@u{jZquKDw*tWssMm$Jg-2
znfCd-A>fdG!5e1A$HkgU|A@ff3;WhjkoVq%^%eZzJb_1VnQ6ZtPTREoqCW>e7W&t&
z;F5pUThYH@STcbp?}Ytmj4wk6#}F3nfA+o^?_}6V{~1#j-G8bNbmu2{?4<pd`uz`L
z{Db}k`nCPi{@EvIytASI+7<G`>rWy7A-f1ZRDbfB84o`J(tgKDa!}jne}2Y$1^Bli
zKU9D5Mf6V?zViFUQh)xH8E+c$=?eSAztLB5{M^TX$p7YROXqJim-Y+4-p%i{O>@y-
zfHQw4jW6jpX9lkyioE}yUHvQP2jMZew7aff>`Qz3N$p#J^ZY)Gj=#uP4&HzVt@QHt
z6?y+#Xg~0Ec<J^N`wQ?p_3}gZR}S7dxc}`L{seh@eqgA6|GP8e^8%WS{UP`>VISkC
zx!7NVZwF)SwEe=P@8SFz>JR#T@V2b~#TeM02|g)5>L1K_Pl60}>-LfLSMp!o`DLkF
z^z(1NatANL5AOG+EDQUe$Ttr80G;nZ$V{p~cJK^*jUiuvTlUos?$@?_1imMoR)zjc
z`^OHRIC$!)f8>xa9P+h;`#+o+-`^o^q{r6;{2b)pTKKQ?TgK1wM_6C=`8&jepUjNU
zy$<mdT&|x=h*>}Wd2N1z>#>RZXkIw<dq1_0e*<uiFXH=3{gHzw;1?P46*%wDoTR@2
z=lTDY<AcOE{MihSrMn_JbpA!)F)(906yMw-KLWRo|4Z;gp__H<`lWpuaL(Jp@NrrD
zct0P${vh%JxD}rWoViE++CPy`9rC%O{sNrmUqv@Qw)RW>8}NH$+obw~n`heZA5&gp
z!1fXO3_Jvzq`v^S&JUO1JU*Qy-+=S{3iC(y(e;PFSh{|w?UV5<0k`6xfy-JPRkTI-
zzY)0QUj;7bx3zuJe*Q1J^S_hg8-rhhTIrvZ*+=t`vwJ>732xb6gKvf)b5shSKQ8B|
z;$O{p&jkqZ()LOF)!;Jz55=zm=k+l%se|$1-+YC);Q9o{$4TdZqhH%R{!M2e{nz!6
z?E^ouXA&dbKEZEo`NF}Y#+I)fJo%mNU;6v*`WakU=AYze2EMvyx_u;n3UKBhV>85S
z@T<TW8yz2sU-Ac=*Wl;&`tjBl-M-PSGv0%-RoaF-Xr6=1{cExhx%gK&cm>Y;Ustxj
ztRKTaF0C)M|H2D!J|8234ym8luZ~2v^7_@Y|EF93Xs)kcWq)3}{wngcU-VbtXG0I|
z8>&D2-|qSt@VI{Me*|u=?-OuoH|k)aJZ+~vDfr{?&NYG*a@s;(gQs|B-_-UCkN?v3
zAF&;~wfcqU;4i{99z!h>qG<iWZC(3NKVK}GXW$XGt!zKhUxKeUxc^t1C*Y^|^5TQ8
zzX0d)0qf@&#G-llH{1Udd^2PyKjdExZrLCHy}SQ`^3q1S{sMd`e<VKsKW5tdFDXCd
zUjiQY_HiGUW%|J%hHYdsgeaOblQL{0U&M<=^9-E*pM21N@Y8xeWM8;ywmrW?dA?Yd
z=?8xZwoTGsIe0KN+g`t={E&YM_*yWr4Ih`)pM#%*ZIqXNw0$-BhMo`U52tOOIe6vZ
z!HmN{@WWxB*oKd-e=<Iezz;Hb1<vbNy3l_aU;J5HJ_5f4!jjw6qvKbAza87w5cGw7
zZ+xcB$=vLCeXqIHpMvk`_Z1&0Fa9;)QyAZwo0_vN+rJlP&HKXxa9Q8z_LurY2amv+
zAC%SdQhyG9RBsD&j78gDfgjP^Kh(ecU2XeA@HL&<W&Vr(3Ap873Lf<G@<#haK6miK
z!7B%E9NfQyZC~i%v4f`$o;!Hq;FW_n4({*f@ZZ5>2TvV5cksf&D+g~J+~3{dzk|mP
zo;rB$;Dv)%4&FGpzlXzr2ag>*b@1H53-E_y;E?f-V+h9&`P<)f)_lG|1bzZ!I5z6>
zoA;FQ?+l!4PZrH(d>VnvT+;2;)i1|4CAc*{HsC|&e?;E*X9w?p5gvlyt+!3vCp-qf
z6g<F-F=1hR4u&_J!%Fa>^M4{=gLB<V-9!4ly=?ga+>(#LcS3i7m&{K*K9c)K-vmxu
zG}p&R75I7JVjDg#o8Q8{yY<~l`(^&lz!`rQ(V^#`k%O1ua{Sb3>FSsKsKI%DL>H~!
z+h?}DwlIlD;Hx#nXDy$C^ZXFYko~zse+9mKCqDjP>#rTW0cZcwMazf#&bHSF$cOAp
zzyrm&ALYmG<KQE3$s5YD==uxr5Zk0~;iA6=m-g5FL)y=~<7|8Wk#eF#>kq-NCPW#M
zFTnNMko!?y`d115Rczz>Rm)5N9NlTDe^ZuanY`lKKG9!;Tm3)2b2mPT>`MI^_yO2R
zuI&^31-PX@xXbML`Iu4%?U(qc;K8c@dw-4ipWk)1J-(K@#XcFIYjA7)^X_KbmxAN=
zg>l=8e(^5{xAYed{lVR5+xyq(`;h+$xSXG5-7GpjBk)}jAC93?$QcjnEAC<2SAp~V
zm()!iI)55)w(q3)2KVfazb5e*oYyBN@eJIme*|vMpMCwbU+U2DX~22?Mi@S}{_$_h
zg!?VcpArM@e++KTe<`>%f8`GO!XaOQ^ZY35ka0}Ue}~?yoBuS|^Ir^Z+7E8p?~pGX
z@)fvgf8ekm+_WFuwBI3LIOHpE)Be>C`@v27!A<)e@`Xdb0ypj7-(f%a%liDoTU(fa
z^8Ncyfpe^-4^njgHQ=}$)b=&qzhr!m59rSCkPY!1oZpYTM3m!Qk8kDTtoKmxN#}R`
zgSzpNeCYf|aBz2iYSQ?SfZqt&N!(vEJNW%z@h<|G^_RFn`(^!*ICutrOkcl_kBna>
zIAf#Zuj3OQGTX*RWNE{)@eSNse<Tk141CBwnSV=%{tA2w#;xsrq<yczf_)!k18uJF
zGuu9&brGM%2kqbJuvzcBJ=0v`pWS!Xo9*XEX+xdAXM{`nD_rMq4!#HOKRX96$)EjT
zUxd+^b&QUf_5KU*atw%%ZG6T5>`2G@2;5vBt($G1|3Ke{{42q?;$l^RoYGw8)bQBu
z{4sqK|8)E^@bx_#;uW|xel_6M_~qZvmJh)#`54?9zupecwHS5C{HWWn0)H<U+iu9e
z{J2>!>1Bs_1AZd-8oZ>9b^OBPXUD()gI(G}F8w<Or>riTXW;yP6^qs{@+J5NFxsZu
zSN`@-=;B9tDO!IBeqR9DpZjS06YvAEO>_&F{*!}08vQ3kj!AqeFZtEnzdQb<yyzeo
z`QXIa_WAZ4e`So;^*7+6i*>V*%lg`XfXzejMaW3qE9DdL_1Gx33zz;`fYYu?@)fvz
zzex7c_BG(v_~}JU?Z-A?(a&#*!Pj(~$2L&Ew0{Q9_G8iY3opPQ2uA-jAGh~OUHm4=
z2jDrNo<H>Xn1fsMdjbBhkPq;Z`nCLtCwKCi>;9R5Tk+4p&G`k~ieCe6#V<Hz);qJe
zUF>K4C4V#UJ1gJtaan$jz<GZUi<X!6slg?Gy1hDi(eJHay8fZL$omc+fM0{T=>!N%
ze(Ct1zM+f1<~shx184b&u67L}_G|f%KDb-IT%!Eb^7(0Y`xW3;`!(P<^tz>f9sm3x
zOY1}NPxA`=v4(tj`t11ohePs-;)C^rAIkAh`LE-1(L=lVYOdo`f}8mXZsnK%Fgt%E
z@cor-__!=TQ*dj2QG;9ayLW~?KL_BJeB_W%z<0vt052J%8DBZS`)P2_1)A&lHsGtl
z*><{pp`zUu#Ixh?|LFN=-2cv8I=>?FS0@~QyY*)T&f^y{;hzED1=h085jgt>$4@<f
zi+=wstRIm-QNIt~yf9h%epK-AE<d?l^fSNFC0qS5_+>pC%Fhy<eVc{z5DSKbwzT`7
zZS%;%Gw|cJK77{pmEgR;f^|v#<ovtc_K4Z>^IwGP_?F<O^!sZ6rTzRz&W_{K`h$IS
z{Q>xq*e0_0*mC~O{S$EBe;|M3W6Nd!AAz5WZF>IX_t)6ElyAUKH+b}@rSogptu3@q
z)-Q>JXW%y>KbSw_-*3*Rd{=+`=*~VW7Eb*#Ka9Yi)-&lp<dT2Exl8MRou3kq)WJ(|
zj!!I<VbS&14(>f>>H3@Qe^P$}et+oX-;y8HFMI?pehv9wIC$ycm4nv~-Z;3o5!aW{
zzKgw&cx&S)=da_(+I)20()AG?KWYC89JgqBPhGuyeSKHd!+2E}*z(?HT;GAR43mh~
zFY^A@rTo_Mm;4UFt@V2hegN!{+`-3X{VxMQ$lwLIb^f?^)bBmsK7Sm5KLP{h8XDFY
z=AVoY*(HwScW`Td4KB6g7lB*xOTex8<=|HQN^mQFjiY}5GCO`DxD~%Vwc}TUTk#8@
z*j;~N)5tiW$Di22Q*b%|rt??&PY%xbvkdV9{GJ^itiN*9-#F^`FSqLt!C60T)AmXK
ziyb@#x7KGlxXe96`U{7A<&bZ{cf$4nFKIu$zB_xny}rx9E&E5{mi?tezIMoaJ8b(m
zgInv<9Q;7lcKFzie=<Lp;P>vij=%5*{Dt5$ABw#Eon2w;FTgGRHMpfey>hnwehY0I
zvTp>w!>~WNYPP-qo^3C4fS%t|aQ08pjgM`7B)@ZTOl=eMzXT8a`IWLP`uMDRQg?i|
z*rE3SWycTT*7aNe$xG`;QK9FD82rfqT)T)5+P@0iy1%0VUkBN>6Xe6EbX?jSyDghP
zQ*fUD=Gso;d&mW9{djdJPusM8l3zLa!95$|WzVt8GI<$48*uad%2Q{(ExoMR$M}rv
z2Y)8`;tKt;J_?>T+dkWZ@sXnAUx7>Pm}4yDl0V+lyYpL8w{V%?bMT|Ek-qEor^r{}
z*8CJb!{!Be(Cf!rTeN)@xRrm6Lw}Ot{13F!e(_Pqw*j}tPyd<r_!)v*^07lc1-}Zm
zag3Js(c}LY!5M4Km-SCa{r<BY_Jf=DJLFSv(|&N%en<WOH4gj1P5T}4DfmvrH<%Fr
zZ-CQ&&2{{}o%Z>u0K9-a^N%kUoqrYhe%LmNH{g;Nt#B_d<4g8Ddwnzlw~kLs2d}|*
z@9op|OaE`c?*kxX1NZsTW^ddk!SlQ8zbm=iGZcd#51EjHeW5(p^o&XF;1xJ^b6+WX
z{HVdHI}nI>ZJ+;wVb1-jGXjtBp5P^g^0H>h9J~Z)tXTB;Bkfm#pV8q#9=y=zse_l`
zJbzNE`f0!9T>j!&@15Z33NC#rdP!G5ZP)hmGvkwkf7Q^RzHHX}h@n5cZnpjY)I|N@
zrv6tt^uOAnA6(i}`zP~n34RRxWYJvO&wGu{BXH(7i}YjWr^sgxUV`(y17pn>%d-4-
zaPPHt{|~_TM*FajX#LW@(e>T=J>ADxzwjLVDhO_b{8}1^qPc%#*T1-(I#{&-5%?WY
zKYbiJ{}#Vt*83vPKhVAaFBYvocr%WFA<w$kv~)R--h%ZVIGL_r?9bkc^+nHz>L0xg
z>pvvJ4yAvO3zyc9)xXYquZKM6XMKK1^ryva`+TNF@Bl9sZGZA_v)&USzYg1n?62QF
z>pdRqSiGo{Ma#$U>5ebRb$&_x75GVDjL(q&!F#*&pX5XSr{GVS?w(&X#G4N+U0>Gu
zBlAP>!S4Jz^$*#Xfb;%=N%oDv<@|#7U;0l8{ygMI03AdA#UDZY^mS|dBt8wejD^^(
zEsU?&?|*dGI|o~7`;dGJ&iPLm6;NKrj}bWgKmF78OZ_!C=Ry|IL3#1d`&ifi$+f)j
z09@K-NIn9$>dzedN8o(E6zyjWSoHlz#V5MsJK82(=Vw?VzR2%2itFRgdw;T9Uudq^
zS1~wqds6&zaJC=IkpBg^wf?EVt@B@vqyF$FTYn7xLfFRK9Ewj3elFsBs^U66clk^g
zAI)`q!q3{r&#{B24xT%B0e%<Q&N3AL3S9c-5U;^c=w&sR{u6wzTi;L8AAwu?WAGaw
z%zd=}h5qlxq2K?!tv>*_^q1fq-&nV<U;OjFVC(n6E&T<!b$zb^XWyDsfAB^0UyL^#
z<FtKpPx<Jp-SI!;B}Mn|8r-Ts_?pcVaO?O!1GmoqkHC4Xu+ly`e^G%SWN`26cKrdk
zReuC-)t`b}^^d?gzpZQ^nSV+Lufgw*Wa1bp?e{P&7<NTO+P}X$>%AG{FN<(JzZBn_
z^`6l)%_Tp>@7wW-!L9hD;8uJ_;8uJpa4S9y_!qH036+1pQ2v*7cYS@5|LG5H{~Pcp
z8u3Ygg!PpX-}1+^-sfOn03DK}y8q-qpKYK0IB9%JZ?@x~gIn=0z^(Y#;8y(oU)a~j
zB5<qz1YE`vwgC(Mm;BDaxjtd;>G(+gmA!t->HL)SPwn8|FFX4t$p;P|Ie6mW8Mu|d
zBXE9yNqncBIzMV~SvQce=>FS)bADkF9h!%~n)RNK{9F$%ddQ_s%3HeccTSS`e?8ki
zpPFk-Ezi2x9yvIlKfGoIm-dT)yR<&m?Z?l2Wj&`pZNJDD;M>8t#u(yZGwc03STKQm
zzr&qM@R$8d+b{b4KQFB>G?)Ae!S{!uXRnZ_Ewn%Rt1X{_-x>XX{RH{ZKbF@2w2?)(
zUkQ#!thUG3noIqonYr=tgXUs?367u8XzkZr<eP=L_WUh<*YOpe?lR|H+_NEGgLCb`
zG8DgP*SYroL&^@xkHA;A(#yHnUxD-b31t~?7RG1%_Z{Zi>knj_OZ%qa@_b_+qqAuF
zaQ8WL{SiBO3VwI!l)6Q~jBh!(^ffXT)-SvOKLy+94|AMF+vn{u*Zw{R_3QYFe+4+7
zpEAk+a?iQ;`K*(8<<EIv!tuu>KH6uly+4e0aUT}iC+$;%Ti3VzedpTio0J=pPr$zl
z7I25Y=;NQ;z`2$S1mayE|3r73^PY-r)IAiR5?tb{`PhE&0R5AFL+3B|ZSB45Tzmdt
z5+8wot(VpQiF|gqIq#vU>{ToD%bZ!=Yp#8MpX`s_mbHHpp#P$MJ-oDiBA>6G^Ii^I
z;HB#q9_~Nq{h?>tf61TlfUf^CMp|BSHU~cqj791{V;j$J^xr=Me|FEby!ewY&UtS~
zeyvgR%pcJo;N%+DpVTe-b^edQ{~L_)AJU(#ne$!(;3Gboi~qrW=GxzPrEbl|z5@K~
zkX@J{pWk<`eSVni4>il$#|!7Y`x)}l;dA5br@DTLe+K@x-Zs|3LjQ$_M|AO@RDTBk
zPms~^<NcX(f24opT>JdDN&b((ukPiweNtbrZm#|P5wT6|6P|!u=T|ZZA31pG;5E2)
z|Av3mocVmJ0Q`P%ioWaollUj#%q13yfgb-d@aKUowtIB{>HPJNw&N3m@7~J}>5ssV
z0;heNi+vgRsXg!2wD}|RO9j3jfc-}b?UUcn2#%RE?=OkKWo)1gER+}hi9<dE*L`=T
zd=7pwHqtk(Uyk3sW9QoQ3&K{)N8lT<QQA(p$mie(_qt^t+Ar}d!FQz)ijJ?$4;8o-
zfB$}V{1b31{ss6xsC$xs6}T1u#v$(?XU9JPzp(dRY+!uG@dM}i9bx#mto<u+EB?Xp
zcKl;-EB*=i*D!x<?roI%C10Ww=e$3GU$TPB{1TnCG(Jcl(D|E!^Z1=H)?D<LCwJ=`
z`med<e*^viLq1$TH+X$O<P&gf{g{D^FZ7*7+dl%g@}~qp6EfnD$V>YM8|KEppGn4|
z+dl<A3;qQy>HgEadSEv{v2W@Avxtmg9}6CY{DnN%-a39_Pju>>_kOIuDzu^QpZDqI
zz0<q=Va-}z`ez6}bp2%<UvM+N;AVWm&G>?w@qMTxzTjqjALfYf8Su}FZ#?IH(2DQb
zj`%uw;@~;>1JHKT-fYKZ`2%j9|82l!Ek{`vo&WwL?Dh-6t??@bm;BNBEBP}5m*-Py
zF8NnF>aW2$|F8_@um4D!N8nccGH}cO0^G8{0=M$N0skm$KXyg`lr||IwY0v`{a4~s
zfnz#p%TWAk@CSl&eAQgyAD&~+pBcE-KSvH;f?M-z?U45#ZO^YhxHZ3K;8uQ?;MV-=
zpWEdR<EP`#v6tH-a2}sen!i$TYyK)8GdKSJK6S9L|Bc%hoVma<#2bgaztPqog3EcE
zA^ovKJ_SF#w@u4Sd<uvD%E224_aEEMKa7vgZ;4+Bo`Nw4HRosAJ95aE4qk)H^>M9V
z>i5pG?F+yqKefEXF9EmoXAVAc@DiNgwPMljC-&D4?rn1T=im|eb5QrB^-BeQlCq6<
zo`3;+9@f&{AX&;^9Y3)@0_X7~ndbaV`3ju+rElY7+y8_I=g)bM!Zwjz$usbyv5~rD
zANF5qzY@Fv<N1BfMSuFZIqywioV)b=B|Nxb&U-!>_4CD|^%vl$VSPgTH5Ykr%ba(f
z!IKN;+WT`S>2JXK+l-U+M;F^X-`eG`*!F+y2R{TGB{ssv{u=xWY-DU?ANnsmdHme?
z`VVDUbbK=Kk7FD2E5M6I%STU`Ykz-{_G$gnehv6m_<w9G+5M;GlS}8k+pu}fBz{>p
ze-cX!C@=Y$fpad_Me`i|IKWBmQ-Pc7J8)S`NFCHK^S{5%UY~^EGCmE-r{ISHNbI-|
z^~>?k2;8c_1h>v_)ei2ZwtN7-S8w=G{38cX96WRI5x9&kL-iL9UV`5X$@nT2<L_^0
zf9%f>Uy1dJ!TqP<{5WK3gR~LbM~)v8a2~(0Xg<zQ@H4=~cJ8Og-wIs(BV*C|TZ8A=
zM%`LJKT~J=bbEc1gRjPZEK-lwUxHiq*Wf&UoaBG>3|l?{xBM@_#je&!{I|?LaLfNV
zv;9xOE&oU0GJos%O8b@IoF4+%C2dIiB>w)hZ2b|qC7)ko%a;z`IC!vg&igQI=lDNl
ze+@3}FYTb??>*b*0XVO1aDAxdB|hPEY##knH-18VnSB!f1bmSYg+8!o`*H^_!T0IJ
z2KCntdH-6w{s=sS|C8cdK6lQ$6`Vdue(CFnXFb0gUo_X(4@>axKz?2C1K+g#lV8|f
zf7D#dkHCKp8MZxNER3Jb&-shy+TSmxZDOC!@8rdE-Xl=I9OH<*v~QWuwa-^!+iU&8
zgO}j?9pu+2uI)ePrJennYx^_sgIFnw)-U-{ICu?i&F|jJ?D;hSKLB;pA1REF%+E16
z?VH3i@Iwt=IO?y!&GR4N*8MyF%a`VFZNJ1X1lPICedwR8ZzAxsuub~5aQe&k7=b^g
z|E&8bS=(OM&9(Q>uFMa~zX&|SzLR+7;3fE}y}Y!6&Tsz}bK~c~h!2`4;35Y#Z6U`g
z$=3c9T>R7dC;nC79`akqQ0uQ=xpe=8)T4Rus-^XzwomjY;M2W+9bbuG`s$_Q+ur=P
z{lxy<!3zhk9K3OG|20ebr~McELhy(5vDWbw|1xlii{_HQIXKsLWLm$-hp+AW2V<kT
z$j9J(J}t*L&H0%+v+KM259DubYU3+^*WhBGjFD_#(cggc{Fdkzd9g3JVd?y*_D|vy
zfwTYXqVqEW-@S)Yhvq5x(E45U=isvb(e;b{1-Psaw0_~0L%wmy`>(U>55cYaV~2d|
zkk1|Rg@acP-Z;4bdfUIy!D9zc9Xto;+F?@vslY>nd!xDb_f?sKL;2x@?@5R<!~<|1
zU$726zH#5S|AF)T5p5jewL?C-(Uu>9bA7-f{aE+k68y2~Ea!ml+wQfz{|9fL^L`JW
zt>Cgg2>#jDAAw&0`Hd^&#sA`+bKc*<cdp=~zbLx<vlts~zsRTW>E>6)k}nqeC*w~6
z{#k6J?2vr+-nsVq1oU0Yi+=xo-Sq?3Kg2U|wjbpe@nT{9B42}l1^y-2KE#U;+3Tko
zoaeu!ZhTzkpa0>d{F8n3_!xj+(XUS>zqme?-|yV*Bi;DA26~0-_2~)Vw0jaCfy?-%
z;|rHtn@e!EB@1K1qV21|WqclzZ@{_!V-fqby#G;~hu{Z6ma)<Ck-rlM&%vdCYkBc+
z1TOv!@dA8xU$^!jP0-p?gUk9Bo7zJEgnJ*G^G?QAv6nk&9)pM2M%}u8S>I;hJU$eL
zkIUpo;0O0y$6xBNz%Bc|kK6VK;3xF@#RhGE0&dx#gC7O?N&Z#fy#6sMJ`MQ(1`j@A
z+aG~bp7rba$oP_iGr!1nehMFfbA3enxDSi=zXG@7<Cop>nZ$0Td<1@PY!uzXrTtTI
zo`0PbpAoq956ZGEvk%<Lp9cIu$V}27eA2Ez2B-hDUwmZ!Vt)>9_5T9g8b2!V?NeU+
z8?X039V~kMd*e;r_!ncla6SG#>r->yJHaOL_|x6}b1VIqzf179LZ0)3v=RN2{764D
zH~xOA_)q%|K{jz8@3S~R(aQ?g@(K8dFuwErRDc(Y=E3LZyl-F|Wp)0Fecl)B_y*uF
zK>XN8CBJq2p7o`<)=tfJ{0i{>VV~w&{vBVo<!kVJU@^WE^#^#d==|`$Hs{@hZHz7J
zVA1|p;5VTD2-^d^Snl(brR#&`H<sjed?g?AZ_at2!XMYhOZl<xY7h5>biaSS?)%;N
zuetXBfdA^&kCS);z7KA|dt0`o|D8(z%uhT0nrr>1+}!D(#53?ez-P9-&Oh-l`^B7h
zEaI~=KZTdSTsr=PincJm<KrXnq48Jpy8(YVq^OTM%0hY3AOETwKe(MXuxR}m`2Des
z`}>3_TD}2ahiz-|8fw4r7MrKwJbyRI|LWIR-+@y<ZD3*k%J0i~zwM4+HP`JEg7f++
z$Ce@c@@CF^9hm5*e)=ct-|%<#`MntYQpf~&i4Mxk^T|qZuFs@yd~Eg0_*#RDZL$yL
zg?qoZ<pXd_J_6r~Is?3zgDi}nJU{zQ;H)daOSq0-1%3h;<11XZzyF8f<A2G|5d52P
ztcJYKAGzk}{~6ye!T5H%;<|lb_?K>e&|KSBfLD-Z>~;M4neohSoAZ8*Ki-DVI=|)q
z$`oIY<MX!}L+ziO6U}Dly*b#o4#L`g&Uw_I&(C{zHF&Yhy!Q(5QzyvByUmY}y|jL*
zf3(lM_XI3<*P|}l$g(W{cb+$&&l7|5`4jYA`!DfH?=s*1J{-peUBB?`uJc|4`(yB-
z`qO*N5B~m~<Zl5UL6))Ni$&*m<KW>v=e<WlhO)GYMPJ{{!PjA%=F~6aUj_aK@NXjq
zx_u@8vi;`U^+gRX`YA6wyx08T`bzXC;A{K(wSU5M@E;(4e?}V)=}-5cAFsc(eG>ly
z{6y&I-_kz%_dy!)i+VOBpBymneFpq(6Y38a=e?`JZl1u4gXg_hAvPbKz~e)@_=~-$
zYFU2f;Bx<fwok@~0{kk>zaau9@p=E#J;-$5-w)T#xA*@^Y(>B1R|dX_jgxo*j!S6X
zEqg4_Uuoay`1$tS$Vz!>zY#e1)rI*X_Q&_{+K)M){gZg);6FnA*mtD;C@(yF!2J06
zUqk(~2EP~bhdDmPy_4Y|*m}Ig2dzH`KOc<pL-u*6%(u_iI2L@!z7hDTVDxWj{m_6%
zJs*+}*Ux)@L++fgLSE*_@YH$lPlyloYyZalw0ZBvkUt%KX#6Q3I`3@(qwm^($&c`1
z^W*Dt*rhFukMJ1$5NxHaj*ql|=HLbRS0NkpI`HPb>Y3Ev-T#rFG4FjD{xNo1zqEgH
z=Dha}gGUda_bTvE$v;%-_aD*8PvXrZ=e>6$e&2w+j<4i@aW48F^s{|57yH7E^W)!N
z(Cs^p5BPe>PKsaUkPjYf%ctP0p`S(9Fa2)>zJG_8#aDO*eg-)0)BcJ5!FluT+(xeT
z3s1oh?DcDT(LVw|sOMT<cm;k6_$2+oCWrsvmVD`u_Y*sQ5x5n<6x@nm2_75%`RCj5
zi@>e;rQpxS__uO=ko@#EWBr8u4Pb+AAL03ydGCe2{LuInTs-f+AM%TkAL8}aCHW!!
z=_T{tbw>UEW%J%kjQWdo-us+Ue|Gu2cOiHL`{)x3pI<5K&u06)cO*D-Pq-fc!z<?7
z`$O19L*q|))qMN=F&tZm<VWD^z*sbw{I0=ye=W-p4`9sky?sOVCwTbMoe-b1A+P%n
zb+ON6SEK#$9^f@3?>}|k`yo2(#eE&vtzCb}_~u<RKfXVBNIn7oG-Lw2bp7M`XD8-g
zFc!_l{}_B97&^)R;#wRZbmD{YsleX~+Zp2_`?BXjKNw>nh3zZj(+FJd@6_>^_*LL?
zEHNbCfL{c_x}^@CKgsjw+xt_5QHQQS2mcPX1$fCm`uOrs;Nc3ckKfW4bnz8g?7Cb(
zIOQkt68tEGdoNsS|DpIK;Jkl^`lSx-U-_c>_W7-o=I<<@_fALt9t(M$ALIDHbiTcR
z9e7#$O8x{doA*9w<bQn~)(?<99j_t#i&xAKUO$sIk6zj359`<dVM);boq#_FpC`3{
z1D=Aj?xFgVS1si?b+9mg;$I2A9@{3#`>*bfA4RvwOMb`T{C*d?wqJM#&i<hb>lgn<
z;0FOxR?ExZ6*$|UMcXg(-fM7vpu>aQ2mcK?+g^NN{bHZ@+OB_6g|1)phv3XDv4{In
z9{<{HG5Apb7oLKz#=cUw$jkb61ionS3Ve;hz3c7z1918-zDfOJUkEO9mF%<3Kk&Ce
zNZYt9em8Xavljd8OXVo!k`FOB*RJHc{e<V>5A6Bi{0`3JYswGx-{5ug?eFKFx`NC6
zkl#4(y#tLIgAeJC-fY{SgIo4j;FkTtTWtFi@W;S5#)B^w9lsL%IyB5?Y}fwF_>sJ0
z-n-uL&wJPW;Pq$e{{grU{hS|%+9!NZx4vNfv0GcTeW`;N;E(NPwSUt8{P%Y2D~`{a
z^E2zK-#71-J(K$N`IXW8=iBGYh%9z(<0t2bqYo_2kFpQ#m;RT6Tjz&saO?cA_rdx0
zxR<txeOiA2ZplXu`2>6?bO(4z`{?=m)8O<)b3K1I;L^XbTU(x_{P#aJ-#$M_baMy&
z`*{htC7*%s2O065@>>7M!AtO8LngpWbkIM!e(>xM&$s9LHP`+X;8#JGMdVq(<ahXy
zZhb3bIQJu${7OH%bpAohOMc|w<FzV<QM7*r_yO1^xg}ikuLeKJ;Qq(v$M-i3)gOXe
z<4+3C@h8Mfj}PKs>5%t6Zp+8u^p8c4?-Jh(+**H+9P$<Tub_JouR;4iG2h-FN`G|y
z;-6p6+t(*<ns4uqJYDHumOtPh!ul>&`gQ)T|4b*Zxt34CE&p@yPeC{P*N}h7XXnSy
z*BtUM`dqhuU~cIAknuAGKfY%}ya2cQX9aHEAK!pm<74vq`Ek2QAJF|T1GmP%5jc-+
zSNbRYuXM=Q4tehj^X>D$0@NX6oE|?ngInWg4*uWBk98~LWqf+*m%IGXd|7^gzZVsZ
zlsw}j<3sqL-Sr9J@ff1xmw>+<jPa59>gy}sx0cqo;veOue>C7PhW#A>hVm=>?!5P{
zo)5_<KbZFxu)YW&Kg8=FcKHRoEI(y@@P35zBVb|=_tW;J4nF#67hlSW|2jSexLm&&
z;*~?bR`R<4jP3tfm!GU(`!75Im->g~BZqwAkk1@^r1+5kCHU?%9%YDE4*A9*@BQ4?
z?}JNxhUyO;@)7uk-gX^d>f+xyIL8l`q4p^p^4`t1d;o6MpE`I6F8ALL`CqI0hq(6(
zTRw2`2wdVbq(5=UXW&moY-Q|VoOS>8emQSGe=`DqmLXq(A48=mx_za8`M;X?9t0-s
z&HZ%!iGvs5=NR(-Elcqksy_t(56F{gF7vPVYg;}5x8xh}jfVdCH}l@*2Cu*w-%0D+
z1e4u24Ed<R{R;*!z`6FB=>PAA?;nu(MBtks&$W+^pS0%){AY&#{P(tf-XG?@S6lkQ
zYeRo_Yj=Kil79{O>4tpt$8LQ-Nj?ML4tb7EL;idJGw=Q0(C_`pwl4+WU+Kojwtq<c
zN8smTTY#6YU(O$Rf9|dykxOC!5*~wZ1_<yPk}tszQ4AlK)!%@hifxnpkN$V*{tU{p
zuzs;W1wRYhCdpUea(+?UC*w!s;Qn9c$Ipk*>vO3;cJLgW_usMZA^FO|{o9uEXGlJF
z@EqJ4Uy{GtJp7yOf9l{x&)GhDev$s&fFIbiAs+nQzCR%W=lx9~bjTdU{21rwss-;J
zt2(CJU+Pb%7RJvP(_Hc+2R{b#ixcdxrWd>$d&V)Ah4qX6Y-VA6e=%dgqIop8;5`iX
za}Lt&EAsimLVN!weGBkn(ee%W^)Nia_5d#y?SHxZ!r=Yi;$IDZFl3}Yk(a;yJr>5-
zzlP!yg71p>(DxzxqdgbAYr)rm54BI_FSP5YwJW&PAMCX-e!j#|{4#KU|LI!D>-fv@
zQ+CG%F9M_fA^S@3_kqQDY5ydDvO6t!zk~g3f308a%kHw^9S9z*;38k#b-_!~zQ=-V
z{|`lN97BS8bn(Z>abf#O`^4ZJKk56R|KJCWCA$w=z5r+c(na$cT)tl+`;haPm+|oL
zxiG#zP}eU!2IuiVW2@tLVDDcEekz#63m=!|ufN|?|0843_EoDFJp6=Po8Lq2mml2O
zM>$=;#IFLs6WWKew1I{C#hzx(Lc9K;tZrW!-^)W5+VPwDqx~0o@6ZKr&tCtKeg3_>
z_Mv`Vzvz#^dH#?^bFn`GXZulJ`zP`__&S4E4xWVz<MTg*`j1#>kI!hEwvV5=e*xa$
zoxTtGKRR;3`(LmeFFDTO{SRyKH|0m`7QEdMKk`MqSTrw=T4>va^$qE-z_)@?7hf!F
zUx`n2^g?@nbP~_NpN;V&hTKs5`p0$sk9u`}Nc%(%o`Sy~vH@P=pUyx3_=WcR@+A8b
z@F$@%=AXn*%h%CDd;bP)AF@9<X<__)i6I_?9|2hw&BebQ{E7}QYk%SX$qTJ*v|s1P
zIR4<P(Y_q}w0_B-^pu76`ZfR7^1{9K3*KuXzXn{7pTb8QkbmGKrC;Yy{-A~S`C8nc
zFBToY3jA<vBOA&u|I~%{`XX(ok1Sd~20t0wC_AKo1TO8S{g?Qa;Qakg=GKsW{b0lo
zj78fg^8RTHUeMCz^1?%K+Q*{x3(vrR560MP&d>BWdkE$~%wOl=v$lWCA7<NEfNwzm
zVhptXBJZ8G(6;TQ{13tJi1<v5|HBu|^?eHdx!(4n_KVJ5@ZJdjCdI#bWH<gm#j^NF
z{QO5Pw7<VFDSpj43*ODW@AR2P=TH6Uh4%Sjv`usAKjFFE_)9s>rT!TFCa_8N2amz{
zN?{c3zsQH+2lq^KsXqbd@6VpSLS8ua-d=8x!0i#ZJp#8!;PwdI9)a5<aC-!9kHG&|
z5#XBiFz<x+66w;F<j?nqtQTBz{$&>hS8lm{`_^rj1&1GbSa?|I;ds|?_b+=R)+l4H
zTI~M7lJ?T`w_b*GAA9?<K32Q&V}`>5+&g^YUOVu<$~*t^i!R{bC*zEx*B*1M!kHWL
zU*ZH#%dhM>_3@em`4rAX;0c3!?SlpSVZB}NMCB|zrjoK9cENPWc-zy<w_dj6La(*0
zH@Dr5vFOV)Y1`hY`)E|O%G-4E6&GH(<#KEj`%c5>RXB3xJ`JLQeIB^&@=MRBFWiSV
z>V3G~^EREeW&0JE$Ue<K{_zjJPud!=>7>gqI(_SQ>_k1cs(t9I_;?8oL^-K@YyZCj
z&gA$6AFmWA8GjzTNKrnv@wa>&L1-0@-Yp;XKC~ZkSY|(uNo60}kNbAo+<7XFSy?uA
zZ|(nYMmyK|1p7B_zf4-`|F)AHr(suTJN>=YcOtGqoVXVckjHI#%C;*m>toEelKm$6
zN<Z{IL+yDB+Dh*;)Shf}*+<9Y;=W-vpdKk7Meaoi2IFz13dqVfRq=4P>DjHm!=3Sv
z{j7NCeTLe8UpONB=-geygJYD7y0`ZKCo^|DU&jqkKlRw6a(CSBLw%3&;CF^r;jAO=
zA8ISMgWhMTt=RWuAKg|y56)3e>fYM_pAP#m81-${xv=SyE_eUm_P>2veTSL-Pw(?o
z*ns>#ecJ`+U$O<}aQtB2>U}1)lkB7Y#8;Es@}lmo{r@?rBOd$NcTzaYwpyq5W1s4a
zGbb-@^<C-AN!icJNxjcdJeZSupP_iLz4Sg)4C27pE&DKLC->tTZYOFBua8ODiGE!7
zG23(rTW8bu9h<jq+tjDYwsZ%k*X?Z#RgQ}|-`f}-=k2!F0r<n;mEYglWT-msxJ_qt
zN*}&s+vVq9v<0cTH1<~gfbl3*!}HLtyv~bmv+2qUm*+3gxD2)Hwb%i9_wXH;Z#kdW
zs$`Cw#TdT|k(tz9)TQ?sYA=Rf?=#e1Y*X2Xe)4>4h!+d|Y0rPMO*!R=FZ|3k#0*}m
z@#2s~xnuF7EalF@i-r5FZ9jP)9_Q2EulpOk^SNJmJWl)jTX>91E6?#N$BXhO;l+Zm
zj?Ynl5*5*>oA566)%ctH%Ur1IdoA*5Kd{%~eKp=+kN1=Dj<3~>>x&>v`3-on==!cf
zJ&eyzRbM~Oj>lhJAD?5v`vpINcixv=;{9QGzX|WOw;hkWJQ?)w-Kd9geNSH>W7&@v
z?eEOu&t>hf4g0ZeQoLV?_Z__)>#6&C*q5kB`^9@|U{V`1v8&JD_WP_r%l6+1VO|G(
zHr{W=`>A++7N7l9pS<z5PoMa-4b3l4`|16D@Ri%}Ws5zb*kARQ*+*Z${#Vx>bIlFY
z-v7MjBp7)>yZyUg$*=xyeA;by*!;)i7VrJtpFz>><@N~N9)a5<@c+XIaO^+NTh$(u
zZ9Z<}`QhOkH(j;u@+WLOYUB2e558>2mdh{QvU%(IJGN}R@`4@Pwq3G)<0V@kcfqAQ
z4!i999b2#5l3u>;@tY1m{C>wCb@bs!9eMc1ZI65W=8aD}_UMh<w_I?+#ZNd4e|xyU
z59b#GerI<d%$a9hF*SaF=++A^-?n|*g*$>ZXB`r7$#Ut|r)<S3hf}s)nr^)WN8CKN
zuQ6es*srhFaiT-nqkC)LkB0Rz#^zPts!f|v@fDYE-SOm27hJsMf+uXcVB5AQY~9kW
z!+VhxZ`Wo=V9Va#>|T#<b$Az^zx9$UE{DvWyuJ4ND~<tpeg00KXyUxmtuZ2O@9ORB
z;cvua`WinEVjb3P_>=cnXILI^ZILbD{eF1I5{};+$~YHgkmEC^{8d{Iy1u^Pgqt7p
zr=NV|2`{+Yt8l*KeeL!KKJ0?K{rH?)*Y1+uqkhIwfBppKuy*_2_r3FmM}26`9y=~O
z?90d9d?+3?aU>elU$x&WH-GAxx1PE4ZznwH?f>$YJKzS9E8FeA`{E5ZeEOCPuQ=t7
z`#j*IKRy3y%+u}m?>*(mbC>?@T`vz0_{HT1KK*Ck^1Q#c+v{(=`I<8?d+8C!?79Ds
zF1zlWf8e=zaL`}%w6nH9|0(y}@zA|DoO#wBpZT}Vo_9sN{ra6-*4^;4XWeD<wZ-$!
z_+4`*?Ein*`x5w=uKxWSvDTKTqKXbuI}KtBCH9?&*i(~9W|9oa%$S)(sAa6xmX=am
zEuoaE)>0IuXjNNPOKB~o^|tn^qSm7R&vVYb$s{sDTkre-z3)9A$CG>KEZ_5-<(}nx
z&Jpjo{QO-&pmB4v>t(tuezE<&W{PrEy#M6lpm_nWo$1nfU6IXaPwjXg+<+*A-@N6g
zNgu5o5ZR*B&1YYI8y(dl;(eDX<tLWglIKq2p1Ch1ycbptdnLvDZ(i8{<=v~VT^aJq
z(<MKc*bnb;>>a|HpIT&6ozSjz*Y7CR{nIboVv!ujUEzK1sEVJ?UsN%CR^w{#^nC03
zAY_7WbOv+=bOv+=bOv+=bOv+=bOv+=bO!#*8Ne`4iFpL$|9F==^p;Zqe|rwVjyV91
zl`q0R?AXrNSlQQ@*w+}^*O=JX7~0p^*VmZd*I4$yya?*a(;3hi&>7Gf&>7Gf&>7Gf
z&>7Gf&>7Gf_%|@{2*>|Ui^J}8{{!Ry3ebD}5NrIUgx+J@?#9-su@<4;7-5OEJF)uA
z_5DJDo8TrvbJNle<%LwY=7M1?!ta<y!1}#+7~yv82EYyno@vl2@R*mb!2wm*fail?
zxn1nzeGg$w#@e!<Qov|*nyfBMy2e4e-T-xB;XFGdbPdWW1;rkRc?ip*CB^7Sm!pW%
zDDVvthoa1d8$QohpJ%Jj%hcz0)aO;|^AbE$KOt1rm!OU+O>U%xXNpi!a5da`u>LO7
zAacnV?@AY6=%EHN!S|T_LjEF<|0onARw5kpVCqg347>q7i4}O(v?M6=D<Tf;$5v(1
zbY%CcGEx7N(NGtHGEoQ6TP7zqpIC$%M`qdX5lg-hvN7$Nu82cT!+!kEwC{m^1Mx)T
zy`Rz^`6tt^sf=i`F#pQjC;g?>{HuWQR6m&PGF$M7yeb%Y!iyX7!29V~l(O>RX61va
zq~=Wp;2OvmhWFk)WRb6RD*RAJ!(Wt<@{@bY?=U${NfwlUq<|YDO5isZUN`<r{|$A6
z={oL}t`drWpd0Z=Lsp(|Q&r7tx}(kv!{)gm%nx$VQKTt@1L|ys!OFVC`(&~I9_dFg
z>H0GhQB0Y{*MZaloeHE5XBx0FZ~;*0e!`zD&$65|9LCRcsb~)4XXgJAApIW&LKQ^0
z3M>!224r~Gfi;0QfOUaToAE$bNBIK?l@;X{unq7wuru%uFcOIU9G-qasK<C>fXF-#
z)9wcx0L%q+0P_MtrIHWGJcOJcsNg6CfF2;udGd?_76eWJ;@(9Mb?*a#Gl9i`3xT+=
z(6b!)G;kfz0Ne^J5Bvs*^O8I#fGAfUq)n*?giK0xAo&W0m32*?`#`?Pa}X>|^<0wo
z8bH>~nn3ysfV*fo1StDq>F;SE+ZLML2%kLf0g~r^K<W^m2h!cIz-NFLfYpJ&0c!(s
zzKEv*5a&R7c$V8`U@PG7z>dHxzzE<~U?1Q$U^Ec-qIu$hH-HJin?M`z4sa0gPhbl0
zE^r7Ch0!wt;0GMVN8os19w5q^k{>u7h`kV=G+=SyG9d2X@vH%s1bzlA2V`4<d*=i%
z?U4Sk+>#g8W%5!9zc&HWL?C|h(j7=%dH~6b14v#50m+LKNM2k(^5O=Pmt-J$Ndb}<
z+(#yONd=OZAwcpn6c`PB0Z3kk0m;j7AbA-DBrl_Z<Yf$yyx@K)!OJ+{C_Ik`l9!i&
z<Ygj|yvzWm0de1<;AJ*&9iHa^Hv{JbKLsuT?gB0X9s(`~o&{nrjmICHyaVK!QOkg(
zfbRp@_N@Tw`f!=`;a25iy*uB$@+-F+{17~0_2@IE$GRi4b$vJ#DBb7`=nUu#=nVX2
z2GDJJB<uf{REv=Z0I0)%vHtI8_^W#Wf&#H&QjGDFA4h-WQ$KX&98QZd)@Zd^-Bweg
zbtv`<aE#C2C(GaMF1OJUZ_ngJxT%S;jVB`vha<BSF%K{j;e;wh14%6US;7>>|LFdT
z^ZXm&7j};2o`YDY8{?;>B)d%{8g6{g0T{f-sWSW!1`31zrZ`Iv{ZfVDM`N>qpVAzA
z8nT3sDF^oJ7zg`<nnALZt-Hugn26&sB{Xn3#$qM#p8Ffh33-*EPF-p@q#wR3oBpm&
z?R($VZlt~Q&u~}g-gmXxO%-Fu(}<7biv$xCK(J%PDc<`BqA#kPN4i=8*NJpV_Xpsf
z`)gTNFdi4DBXEA?INmQUjy`arOXQ9byJiz(OtAyicuwK>dHCJxGTJOIx5bS2^mo+D
zpBd46`{P)Y<5tRI0Oz6bQ(mS^$i6EZS+w!%2z20C3`Qbf_%1@7Us<l^9g2%68~9oI
z9uH~gw`G(Ko5|_44>sb6ixkZBBwAyKgoei2ZE@CkY%~$C;qAU<W;K3iy#3X9gIRH5
zAijtflqv@i@7C<%wb)XuPP;A1VndBkqtB=~Mz5bANQOFUy_lfNKpykL)`w-eHHiH6
zv)WSZ17#~9(^d$-XJhWE59ifz>7Mj5jSLr8!ID$QJrx^Uk?a`Y_^xwGdK_Av?vzJL
zvQmxXeKn4)NC@M|+_=aHe1|XR#h5=$Rc=<Q;g?dwXC2Ioa_&*n!0^2r9yJLMl!i8H
z87M>2VZ7U=O{f!lGnD~Rv$R}yS=>ew;&l&kSnd;7MjNHY#XI6@IBsS3Fg<S|E*_eg
zQO@JAXDhvgF)q<4a%PO&so4ro-sax8uBdT&*D1zzJX5;vi7PHiorCk8PZ@F5*XBnN
zCXIJJT8p?Qi*~_}<h6{5?Cv%>-N_EP^BuM<W1K%@UGzs{jm9`036se1SvD>M+3?Em
zhRnCgcqT73U}?}kdRXQ$ry%x<bpRH|b4MWkW6nVRF39f%{d3O1%*F}kJc6$a{1w;=
zcmc>cl#9Twz)QfMz~6!Wft&-22XgL<a|AblOy^A?=LR_EH3rDJu313Nb*%s*(>>b&
zoZI>eh;hB=YhYgBJ|O3`egJX~>l6@YID0T3Cg!p@=2wbd^k5!KJY(L9XGnXh0!sq<
zjd&7>c@xC|><h%aiYE?O8E6N>tq1cUVs4A=c}+Y|0M-IxUP5^m_!cl2xDALqpgo@h
z>jC!z>jRGh8v;)N8v)M(aTl}a7Lfk=9exf--VLy6qWsDI?Mv|tXX$6=F7$G@RdvTQ
zmDSycs=HwPCfiB*9b!H*--BRjFu&+wHRu9lyNbLMa<Kf!c2LgU(VutuK^}<m^9_*Y
z@Bol<d<$ecj>B$6z?6L@Ed4(T3wOdyRsBy>{Z9uL#xFB~#egUSo{GTPz-qwxK$hLN
zfVF{(fK7o*fNg<DzXxehmI1p15vL~#xEg2$t^=~%eF$^`Hv&_Em`@UOP+Nen<9RC(
zGVm-`&m7=(;9}qo;Bw%X!1sYWflQ~UXKFr_!gE%h4#6GyJ_;mHD65_lz#mor2K+7C
z(TsZPo!>}vdbv;#0DoiK$auWnHSuyM+b>yuvbt-mx(j9)$S{ThP{@UMxj<Vl<PHE*
zZhRKSoY@4FRbP6gzV=%B(l_;`7wb#^brl2&@Ed)0)trsN)7$6v#JayWt~rOcMZ6!h
z`a+NA7f=5tzRvMpFAm)?4s{HDsQ|y<ZXBGx_S)L1miW~(Ber)hh`yD0f3w%dW!G;y
zPp;oPu}Y6MZ@i=^8^rsa!}G@HT`==ppIIx%E?c>~x9`2B$@umL_}#k~^@a%N-t!)6
zgXjRiE#VCsw|xGwJGtr|Yno^K!oiq_74Ppo@4=UTu&+6}k3=}b=N;Z0(A@p_t6#<x
ze*TYvDD1xUhJEQP`_g;<Lxf*&M(J~3B#$_AK4hqW?qQ8P_}=T<1Y8IBr7akA>CP{P
zLk(*FHY}#iJE%my_8`|2eBQg~_XQEotzWyn*S*ipr(SMyD7vquF&Zx2{NG`K-;PJI
z|3A@gGRMZni{by@-T$A2#_kH_ya?;74*1&F?W->NYU6y>ZC`DluR5&j{{P>p1G=O-
z13Cjb13Cjb13Cjb13Cjb13Cjb1OE#QJgV`3vfG-7Q~1)y|9*zQxAxDqea?+G!DO^Q
zSA8?qFU>}*HJcL?p>tU%urCxW!-N~G1|?%PN}jij0}NBGZll{2gOjmqsqQ*u=gv4N
z*@|-my__p`)VQC^&V7bMZ;=%4B?x((Yoc<Ee;VdzX-2_vUVk`j2gn+YxectJ#aV4;
zqeJW^$XLtdymdClgSm6DUd{R6P=sMk!U@mD7?aB)^|TAo6T)?-n1nl?W8Mhv%yySC
z!D2G=A_MAx^9=MBcpqnVLRA7<<}zyW+Zpw@L{p}pM0nKoZw!A}P1b_Lx>&(Lo_|ky
z(%&0RW;53GIj_%k_h?LNPX-T|6IbSobW3@uFCK@9Y^z(YlX0!Ajmq0tPJY8!VaXek
zsI)^I7cmhI-cS%6b~o0wp#zdQ#Fzq25VO&n53biCs_aZA9;?BTw?D4qQLe1K@qKpb
z*Z6D#+2ncNIOSVqhukm^d~w6{YWE@>Rnv>9RWa|6DQl%8!lVK`(%Z$|GTG@wdLu0{
z_gRa~Sm)ICTufs{hiMN>9$UkH2F|ylupnGj$HWwi(vPKSmt5~;<ryf~JXzMVF=Aa^
z<BA-*6Obiw))<yC=J|1?XENe`2A+Qqamlhr4(Z-L*oN~yH6I!I-$7lU&7DWaS`|QQ
zD#KE4gUo+bZq$CU%x#L}PKJ!8!5B;5Ijz}}e=R<qKTT5xmho{-hw*WdJ%cALz8DKu
zcr95Ye31CGb@k(Fd^Obgs;Tj%Wg8#$fZPc<W*u#w+ii+Xc%Zatadl$G!!S8a8=??t
z+nZBdX3Imz6@|4onvSrHmTQ3ri(~z-NOnAC?1I9oKC<w^${fq&R|wN;LwU8uTJR|L
zBC-8*;yrkBQ7?q$lWhRY8=51FGexKiiT7}(9Ke5MR?St>{;}<47#WgrhmTSG#<G!l
z@0QgTXE%y{E+<6#WSFuYllPr`q4H53e#t${Gxb5jv*kV+l|s{Nd-yWkP_3*?8{;ab
z#^rf{xNvl?6{=PbRIaprR%_JwTB`9i2hKv|{0?W-8SfN1-Efj)9LzTcJp*B>Uvr_i
z;>~LU8%UUMU|G&~!!qu@zT&pqGQQaOFtM&OKeI9EZCiFSux(q9AIyl~2+#G^eCJ*`
zemA<K&4vOLzehs%gEDtf+q4r{ucM*9LtP+r9+Y<=^JLk^t8E%J+w8W%$Pji~(8d^X
zurZr{`F(>w%HEIxsfK0zcozM?^^k?@+SK)%B->x=|J9}!zMGiwE+m_Gb+mVJ8Sd(3
z^DbDvllfH(g5U!ZZ*j}EelKKb13u)tj7|abm->2H`!M7-5xgD;Pva5rLBWfx$JEhN
z`!?v!WyEm^@7b48dokLlH=TR!J7`8&G!<c4H_F4l4ekRnl^3Ta5p73y-$6Lf&SWYp
zS@jZ`_gY=Kt;WxMWBm1D-)G)uia&GxXKl&po1*PWRO3b)nq=h>-L`ni8{0(w7U#4l
ziOwyaDVKJi)L1%zVI#_VWP*(XpL>x9ti!U}NI6ueaFNMm;vf=!<C1M!mr}Hw>;ti0
zs8vvOI~fAy(Dbp`C#Pu!OF5typ$v!IVX|(R++O{2{3Li$n;$-Un@sYs5zH!&R!_6a
z!}2!)iEIa1N+Lv-8B|e`2KHN+HqDQgM5e);&-H3Ls>2_<UX@{)jx@=q9FO1~^HuGd
z;VF~3ul$VbGMuNv$}xl-TSViT`I87s^BlU4<PkbK9=->!9)8=xfaQR#fzJZl0LeMN
z)1KbI_CORne!qntSZ5&jDs}~O>=F)S{F7m2UtIRlqw$Q-j4~FM25qZ|zbugPKMh3l
z!2OvXwo9moo*>{ez$!pkPYAFoFceq~2pOp#=YdSzYby4<1p|$EMg!%E1=a(y?4mxU
z>*dHkGxk&BJ=}{tL>5TXU%E@clk5Y_zHv03kwxiuvAlxt$lpXD)Abq<!#c4imHbV^
zGvZdJ1HrX26WAO$8`u&!2T1wn0?Ai2tN{VBJRyzZxd1Q{mIk`!9)BSB^pP*_<zs&h
zI&LD~kwAX0Mga}Lu|ROAya;3&gASaCCk%fxBNz|eN5kfUCATy-xMMufrSp&z?m=X^
z;GRSFdAaA1^0F+Xso@|GL^!N(onUEJ!yUs}1B5eW9gzHN03xrIkATeIO+e=F79jFe
z*$QO%VX(6QDf^|-c=nbPYWgDl&wz|~2ar_@x_lzOFMtdu99H%%WuG$|&-q|m!P4}H
zJLaPii0Z4v18eaI=pm95J~sdk0HO{k1A$t&vX3V9ETi$8cet;>9n;S}lFYAHfz+pa
z4fquBbs*C}4aoeS0c5xhVVMBt5BZOV%?(SAX}GtN;l2lCdfx{Y1Flg0JMg#cUnxpU
z{2dL;a&CsD*?{2be<P6PYZEX4xCO}ce*!EI+zw><`5eej!Iwa`xjTW)fL{Zf1JSP%
za;M>M*|(B?u4p{7d`^R<sRH@PGxan1o_mg2uBewu9;lC59Y}pl)^F-zb_7xnvn!DL
zm(f7#T{11rfN{Xqz$9Q>AaoFge(YyJ>c#E?b^@~R*BMBDm%_^al<a3k<C*-SJ_>_!
zE%apj02|>=Utkz83dsDA1>zmQha%pAz!W?u0$&0`7SC%yJ8(YG4SWv>H)1dB5Fofy
zh629>qV4oBvqu60fPBw>-zXsEW%-qT5ZO10#<O=hOM^S+=K>(h*&-mioI=mC1n?a^
zljr5Y@<7Ov9<J<L$TAm=-@L=!2X_n?GK%*25U@0!j{++Lj{#XfegxJB9tUdj%D#c@
zGeqMz?{JY;Q4aiol#}|wEa!QE4T1TAp}>Mb6R;?d;UZtuZ@ugTMB~}Jy`f$(%U5Y2
z!z}}3xZD$uZ;IFx&vI4)&unKZ0$HA)0W$nxSosaksLxD4{m>MHyWGIXflNR3lCJ=7
z`1#ha{HOFNKSBi#@as2cRE3=ZKfn9a={z5veB%?4^r-bEed#>u`i#0hBZ|ImbOv+=
zbOv+=bOv+={>vC(U-uE6|L;n6WE=qaclQ8TF?iM1(mm*l(_jpya4cYjy@KBz7;uX9
z2FyHTQ?uJ?cVHMM=h!$#$i|2{HqO~|Zt{18;Tqz?C4?4?73F&NMTTo}#>Kjw;vMG<
zlM#^jId`K)yo&M@-14lm8S3+C_4%zV&mXAI=kYt|@wB;NjxlI3HdL4|DX?54q6~5!
zMZ4ROYbn@UE3Y=paSl;ilkk>Xn?Lj*4#}J3^CF%L!@6N<`eM9CjyW#oc*_XnIFsXJ
z&VQMK94EyCxt5UtYz7<zY!5`7V!jS(5oe?g19Ck7B9Qqu0myNg2Uez2ra!A3^WcP>
zybCM?Tmj_xZY8h=a6K>txCO|0xNX2zK+bct0d5C&1MUFE06D*bF}?B?kUV3oF2;En
zm;TS~G5J%BI|F8Km{v2aw&CMhXMc!n{@Wptq8pt7odKNzodKNzodKNzodKNzoq_)<
z1~{gA6#M^^Ozs4W)A^6-|5Km-DU6#neWg<BSUDf$=lUIW1`go&<FFhntMQAmF@DO<
zWYVwM3xC<2*Axt&GEBL?$$-4q3$d0i)=x_SDFgI{#5j`vp2I?IfZvS|jvSm{{6vX4
zU%ee@Xz~&Un)<mJWKlOd13Cjb13Cjb13Cjb13Cjb13Cjb13Cl$P6jyse-!Kg;;3^T
z$gExf!1aGW1IN&hD`l04<Xq|4*&6G#yX<jpLzRfChOW5RFUdL-`<4tX?MV)tC+)-v
zxjg@$a{#vjxR)gWqjl)bt8)O4;ct$~sVBT0zg&dn901h-w4Kc9^1w|_d#SXwagO0-
zSaMGY9y5*ou^ukQ{zZX|8={G^Ki9`ciLrld=jVED{^|8mBM0C3{`a__zF`Qu(HYPg
z&>7Gf&>7Gf&>7Gf&>7Gf&>7Gf&>8smGw`U!|GfAKI_l{&0RPnZ|Icj3|K2(PyeEts
zy|a%0z2teQ@xKf!`?Y`X@juu8y~qEbi}C-Senn$i7AxJXzrmJoXX`;#{{8u@$EY))
zGoUk|GoUk|GoUk|GoUk|GoUk|GoUj-1|HS;U);`|KKkb!xBtxge;$nQ@3;QX@qa)z
z<NtJdkmiS3|CeE9zy8m4f9f4@+|TuYM4i6=Ulg0@1N_|6{kQgCeJea@)a=^%j?5ko
zN4n7&&>7Gf&>7Gf&>7Gf&>7Gf&>7Gf&>7Gf_zy7fsK);`%ixT~f28Z58vmEeX8fOZ
z{ojzy_+OKU6hF-PUxt<a`aj3}9RDLavG*VM9;A=|dx-IW-?TTX+`NA0tG1U%-k6tm
zl?RdQMrS~0KxaT_KxaT_KxaT_KxaT_KxaT_Kxg1TzyQbpaf%;?vN+2<G|CiQJIXlN
z?i?6ZFUl3w-o|@GEoLjOtBgvCb=&QUuBb$7Ol*?77B3e~u{fOe0mj<38#Sy~zjnR4
zwWI7Y1I$sW4eLj#w^ZW-aZ}<yeFi`^NUPmxZOG;vK<WSlXEO(oNhUEn@o;kiGR*Af
z0&s-7m<xc~znBZa@IQSnV78bG7+W%C(*Sp+6<71M{&My%N00wNX6sSv4CoB#4CoB#
z4CoB#4CoB#4CoB#4CoB}&oc0+*8knM*hGuTmhAY4&;P50aeWK*{6E|^FAVhW6|Tec
zemdTl7p9K=jjmXy+sM1}tfoZkP>az$#9_g694>9oNe6)U__Y(^;O=l-9>_BRwK<1r
zYP|Sa#LM^@Z+ND7lWp0@oO9gX=MT!Xh&={MJ2k!_APu4va}Lx)VA>IV`W@#|7V+*L
ze>k5|_<Isa*-Hbj0ITFulzKSGAi!^UgzJ@|W!;^NweA*C<g-;~Me%jVxvx9IPl!2>
znH@@{I>WDD+Z%2hxb4o6DT;Dcg#XFKLGuD$JJY4}x+0s;p4#!g@4MC43in%n{w^TU
zxVhQ&GF=wG*nS@_81!{#`3ES_0e;^P{W)*aofXr9E1q>eGvd@i+z*KY65v<t*^;e$
zZKzVjZL75_^h~w-xMNYczqE7i-0kP%l3PCUc(Y9>O)n_QZSns2!Np^`*<P>HplF4k
zY;W|wt0+yxU3qB>23@-Ii{Vg%n!gQ;Y4gr<MHyLu;ot1FaoP2o&Xeo+POQ>n%^NQ%
z%11by5`4}(yg8t``|(%5j4Ay59|K*AvO&1tIXrKC-UTzy^_jJD?6Q@+d*i-Dk={9D
zEg^GHjV@)Lu=3@umo9emeJ9}`BK(3gN}u~8dBmCXAw&Ih4{O{(Q9_^;6X2ISs^X{f
z7gY?O)wtR_J>R-M2>0Bhpal3$DqQ2;9z&~z)XBAP+=6Pucj4Yf@qSs%hS?J?Ea}s+
z=1Y+gNe!Fht_s1MwbGp9u}#kOyME%pz=@@2^1?*j=nUu#=nUu#=nUu#=nUu#=nUu#
z{GVe0!<<KQ{=dbR@<{amb7Qcpjl;`iv-bZPes`$ja94soInnGr0RXA2PP;A1V&nbx
zIn4ohkHck{*{}U$=p@F|JP!cFw@l{%z9+_2r)#%ry6B5y;|pFs_0`C0)=B^8iis|;
z&VbH<&VbH<&VbH<&VbH<&VbH<&VbIq|8WL5{vYrN^#9G4I8$<>+vspwVy!N#-S!Xb
z0ZhPVdu<*dNSy}=LRzQ?Pyv?f@g8*^z-t};9<ku`f#(4l!mSJw>!|oU8kYRkfTiL7
zf5s1W0nbywCxDct1d!|NHz234by;8Q%D&cLeXY}97V{0$%YS%!$AX4yOZ5u8IdNCd
zR~4nPSa1IA#=+@pudSVGiC;Z4VtaS2WxpWSvv2*{?Y-`OZa(#LlS9#cEsZ<-UXS;s
z2k@}#=)Ts=eXWZ>tR8?by#!zD@eivv@JC**qt8z*GO12z*ShO>l<NNJmu<^no!-ZK
zJhERmIs-ZbIs-ZbIs-ZbIs-ZbIs-ZbIs^Yv1~`6oK7#ST)s_OCd$ZADa+;DXI7Yyj
zV6vGLEzW;<9-uVV`@5+70YcPy0ItDv98Sx5fR*>o1NamVULJTpfY<rSuoZ=I(m;h?
z!7xx5?S24=n0^*O7+wbW6>4Zaxa0dN$2SghZhJSO;3?IE4mtxm13Cjb13Cjb13Cjb
z13Cjb13Cjb13CkbhyjlOAI<u|&F)MxB^qPxHn-EBs1E!8v3mdtU{I}{1E8G&n04I0
z_1<y6*^*hThZ^h4@UkE4YkL5wcEGiM?6Fs-i?M#5$Ca|1)_?WdIMdO<k%wDud_)<k
z2dgunGoUk|GoUk|GoUk|GoUk|GoUk|GoUkY9|j)P`oE@VFD?Kuy4+@~-Dr2Xu@S%}
zrUL${`vCnh#@FTn+NtaRP{9^!|M`Jqp_Cs0>!&m~8oh;a#hPq!nn?Fs^EY_vAe?ea
zp}>m31e|N<uNb?^q;z-Nou+sT-t(-0o~j<gc2$lryoZ{&(u9bKfxYT{#69N{-iIuB
z6>}6!OEyNx=6z0qOsk@hgRJKTnlU#)orpLf!;1%A26A76lnrMm;_s!fEEn3o2JUBI
zI=G*qJdpbtn5L3I&UJ)A>0vDb4)AN!CARd>y|2_L;3#u^WW5_(u;)SSJJ`11*7l~u
zTVFia;bfy@dv4+2!P-JkeoJ_R#x0+J>`tzF$C~EZzHqRjxWxM-dnUhdB)r3|g66BC
zLDi2yKjNR-ckr{Alll4R*rH23RSe%d>-8(wa%NTE`y>9>_9;B-{VBfoo1hr!MrS~0
zKxaT_KxaT_KxaT_KxaT_;1M(MsMi0JOzs4W(`htA_dk}yelNX$#lUm)uq>`bB<D)U
z&em9`-DQt+8>&Q9HE@8PWF2a?#T#1MlN?s;9Kcw*Q{a;rM{E23we$aiz!B4dV3pkX
z-5|#Menxei?J_32u>U}l2qzM_GS2^_ziiAs<7yeE-1krS97i)=8jgn<4#&d=AlClV
zbpRSeo&dj^mnXfl^uuM#;=gSB<m%!pqv1$5Is-ZbIs-ZbIs-ZbIs-ZbIs-ZbIs-Zb
zIs^Yk1~_hwdj$Lc%|mQPccM!izVEI3|98gzOT5PZrTipG-fR7%uqPlq)7U@W;x>9q
zVvIE<CdQaz2R^Xge=wqvVahf2i+J`P`y)EBrp`5TuBmg4oNMCwA)l`^;(V>KKI|QJ
zzV5*Db$6YwGwytyt><e^-`86Fcrn*8x9~ITDwRH0d{^&E+lF3Tt?ze0Y0!<%fX;x<
zfX;x<fX;x<fX;x<fX;x<z<-{BM?L;GLqq<b8vk#9fboB{&+$Jc`D^2U8D{q5e~$Y(
zAHZ=x$N$<{|2&i6e{KA~ON{^9-<UmfY_6-tC#Su-Cpuu>pT6%H_|KPqT>_l}odKNz
zodKNzodKNzodKNzodKPJ{~ZP%)%ZWzZB4Yghd}?|HPCH${G)sR2V;z1U)^iZJN0Pl
z1F_XysRNwNK{>3SQb64U5NC3^<4o2>xtG2M2kiHl{6goym{Ks1<9G#Q*;u=oTl;aJ
zV8OsY@7}#T4`B{Axsaxq<oI}ODahDL0DXdjffwOs5p)nNsj(JuK7i3-x7u*`fs64L
z3{1oCA7=U;mm}JpX2!vIZ{T<CGr$G~T%D*WrSa~-?Ynn3!4Hp7w4}O?nvWt%qrg{0
z8X*&Y=W{<yLXeL9Kt8{yKF?8qpQ1j`!ZXhd(9TVm$V&@g!eF)Y3SLFno_pp}TnYBU
z#=%yb8IUB{DW?<*Xh+ZY8o?*iupa69330pJCZ{{u0iBRIJDpR;*&+@_IgZ~cQ&Tlx
zFRC(m>vuGO+|eS<>3chDR<{-ROboRcliVhTNqLCbnDjjzS{#vTImidc{FCQLGLCRx
zaUkVR_rt|;Lycn$!X~#PVLwA0TQhNMbzyso4JS#MjV6Z!PDDCHIpjlTBhpa<yrO8_
zZ3N!Tc9${1Vlrck4CbF?Ickje4omuL!Sxp^*LhT~wR<y$u@QhFaTFJ4S&H*29GQ4<
zL6;`kCU5aD8#BsyoHY?e9A0wdp81_B!c-KNN#?h<m*<QsL)N_53R(RWEx%pv<QQWd
z=JC9)^pqL@Ao<=wEnAbB(J;ecnI|c*XAsZcOmXF$)|~Q(zt2NDGg<+1B=hYg;>zGq
ztJRW|P*u+S6b=SQR)~DT(Id)o@aGWu*xVTFgm#nG7A4s21Mz!KJg|IFu3X4$ZiI5C
zSVa4yogq>M4Tx+zWt%z~ZY#iQd#&EU&unLB0+9q|7O*rh4HyJm2n+=-1%?6N0k#1y
z19k$w3yc6R2lfWO2kZ}gAIQdb1rW`&vJ&V5t^y7Pt_F?*egK>RTmyUwxEA;ta6J&R
zC>wx~L4n$l2XQGM0Y3yD0e%kr9=IEL6!<Oh7!dE2AA#3^KLPWAgA>5Qz>~nzz_UPd
za}LOF%rC&pa32OM+e!I1`C{=3fu-SmFtd?+!|=D*8)g8O#xu`QDGOvc!LYJzlk?0B
zhjo#h(ttA$pSuH@f017PWP8Oub&8VJUvt%8OCaTHrTR<5-?9x-lrgG56jfy!ER6x~
zD0g`v-&X)44N65I@3wsgSQS_aSQA(U*a%o1h&Xt5jHey27O*GqSzupaJzy-bJ}@2_
z3LFA#3>*%84#+mLDNy4@wnMUg%9=hi-1)=31;}<Q&dZ-{JF@4cgX#}uQt;AQ^~W+P
z+X2}=Fh24Pcf$07JMsc|BECLA<c-n~7zKp&*n!Uj-N0yI3eW^hPmid-vR-FRj|c9U
zo^e3d_wm3hz_47t&)6x33<~i3^6OEHhFo}c?2eGv`i{K$Nee}}iVP3%`{d%Fc>%AT
z>C$;!k<DjM?LbBIrN8&EcldS^@h%uMs(PF9TLO=_^$)xB?Pu+MpQV#5<e4+p5;FJH
z=u+khD_`z<>0&p06AMtzo4qzJyMEJoa{b<kReG#><0aH(@qXv<yzzM#%skg;*2=NV
zR_+GzzVsD+=|leib{DWO{m*~u4ru+19aI?I=nUu#<j6p7xQKZK`v2^pyRh@$d+p!P
z@K^W!2L<8;L52JOhv3_(jr|+?$>gDrA;!Jzhwz-eaCEf%6pt|?vZb+o`UsKzs-}T{
z#povvW1QxJ?9cQRZY$r@Z{{~&HDbKQv5QT(#ao2I{<0>=Rv&V(!>7p+X>lf5Z6-JR
zDcQ;~{vqU;mqiZtE7)(5=@xx1arU2gzlHrYidhv1ibOvR!6@L&QwpdQz33^YJ{y2^
zM?QmrTKF<O*@qtjcMQJ)kl~{*DEhnX*LjD}XM^gF;j^E|{tf4G>WTir@Cer{L(955
z7i--uqR3~f(82T7U-9)_4?_L~__e*A?|A4-8-|wZ-Sm&vH;T>o-5>I`&*5SF8NT*c
zJnX&>U;8(F^$&dYpFYCmNr2z*d51R#G<QG#>X$KvpZ{Z^%Xh!ZSO3hH9?Ksh{DLz|
zpZg+t#F_IUL;Z6PYmAPyul~&o=-3AMSu4#s9^2$hzw0Ls44hbcW(qQ2H#!4413Cjb
z13Cjb13Cjb13Cjb1OFBVIR1YW`~Nc*=$!Jvf5h`oo%#Pg#&;Yu2Ha;({OTi~`)(}e
zrhmI}aQfP7Yo}V`SI>;t-o4;IH<#^eET+$K%Q*pkj{D!zJm`_=4CoB#4CoB#4CoB#
z4CoB#4CoB}7cuat#{cojCa2lxN_IHxPE84b<A25QS9Jh71-^uZWleWGh>OiI7;+1}
zN9sP-hd$a$u{Q2!l<~(VSYihntvvP5XtO)uhWfEg^Swsi^G7{=>QyJhL8Qrv0|ez-
ze;rjPcaa(|)DRSgQxtYO<k~9Zjer_<7ke9vEfx#?4-yyG=tsbRcYCsvezf>8#i8^x
zB_`vQ&^6F>f=gk}g9b@es3*wyYvSQ}M*QJ&(?Plz_vkjji)u2`OgWZ$$wB=FO<#JE
z8YiL<aTW&_LY!0x6}s86*k0jHIJa6PJ1tT<ImT%*-S50bDFgQjPzHaH>P&F;jB}e}
z5-s6wC*FC>63j%yl!4`+(4!Tyq~#<_#uktq`N&BYO=o?*DhsBXge-g{FOHmKkwx)u
z%c12@q*|b%J1fd0^>8W2)|}+vz5$cXoCp>0oXYC`IH7LL?;<YT>xg)nUrm*w_zQPS
zk{p<3u+*D{{)h4`ehJP-Hr(@JavMdR74o1sW@B<LFWO$53h<pG3sQv17H{c}eIg8y
z`*~Q$`8x_{qFUIb8}3oTdxmkvhnv<mvq+=1e<C*%217k0mI3HKD-DsxFetucsUNOH
z?3_U=6J#>IYsmd{_j67&(^LrYGEK20(rHnX)io{-TQ~4pq3%C9rJE#EYI~d6lFIkq
z^=p@!mJqyWTI#?uEsmVil3v4n??HI<>Co!tWPT7}yz3^@u`=g$h}!v|OoLXg64@Za
z^nhg*?*_{>Y|S|hUNt-C@6i3~_TMR2Y!?bX$vTkHE_6`a1qbHOX&S<^$g#ZDMcS16
zrp>#Bkm+KXzt=q4az;+LSMPr92kV;FeyH`ag~??RbxqrMcSz*`dm}{tV(*05f2OEy
zqx_`G-iv4zT}BJG&Y_=>b9>D?eHr0Zft7tC*;g_kGjib_zn?VNd*fkMi2>3*^F#J!
z6oq}9Xjqm#wrMo8D#*Kz<^sw6JRtiZ^MUjq3@iI0vX2stXSO3jurx=4<o<@EK>9ld
z)Z&%>39)BJp`70FJ_bcfhEotoxv)2f+mw{zK+V7G1IV;x_5Y;mAA5O(f9z)x`<5!I
z{>hX4Zp$_!D^GX9597z)AQ4|X{4Kw)V$X_@m*uz#EDiPwc_@EXU|C>wAoU%oXIWQ$
z=64!<iPFQ9-$ePXWc=RYT|xYOz6vZ1yar_YuLBwWO(4Ime*iT;<o8E@m$LHF0`W3E
zErBd|t$@tqj;cH?2eQqVbu+8~aMgb|)qe!A4*c{{{flxZ>T>pc_E-JKsqO`zs(ZF~
zS<^od?#O2nupVUtwg!^Vj_Nbp$H8iNVfb6NC9+I2Jbnw<&d@-2Sn$~hNIpY>?B6y4
z(#>-~^2qWm>!aAiB;@ig&u@Wm%C#6s9^VEcuNc1KOW)C#KBX_c$%oY+^|eOmORv<I
z-l{MCS6}+FzVvkKfq3Yl-lNxRF2?r_7Js}qVc3#I%IeOa{ty!XC&<&yzl{Nw-AAGS
zAL~dqnyoIm@gH&g-Ld}ybX>JD@OjiNn!2cnC_+j_pt$!>^fj<o*y=JFO(__JattZ<
z3XAas+ZfH{*ZxqHQEay!Q$od<pai~-?E8O#@4FlC6D_6`i%Xlxkb7md@x>7ISK3%i
zZVYwX^Sg{22654$>}MZ`|FZbKWq6PFt<(+g^mj-N*O6#)(@S@2Jaz>j1jNOD*pK+#
zfWO;XY{^y|!gX5`@rb^=f8cW9A*B5?;IOA;zl!~gUGTFI{G`S@gN@i^&rJsW{<Htp
zQSE=FLKdx0&<<f3)c52tKb|WgOtgK%p#AfZSG2Pp_7my@u^)ha1JU;48z=Uzwgj@x
zZ3CqI;8*N<<lf3p@!S=71Q-E43+xW;jyU=Oqk-&uqymk=*MKJA8^BoLa-bRbDG>Wa
zJqLkS;3=RTcoFCT-T}IRPoPti415}x0;~ZX0*nHV1jYkB_%{hS8aM+u2KY8`Ja8Rw
z0&pwvCEy<5B;aHIVo$B7IB*J{%L8WsS>|Q|+17g?gRi#US6k_;P50Gy``Vl7tL^sH
z*86IUed(L{`UYIh!?ye0y`_23IScSxR&MElb$1Uuap|o;e?R$jlPbuIynNqfO8JT9
zw&c0fxM%JQ3Ganf^S!s@VZV{c2Hofk=nUu#=nUu#=nUu#=nUu#=nUk*0LTB2LjONm
z9!}-P5daty%ToaU?i@e~jB&NObIkh+6NLYn1_KelM`OV1mwsLt&Q+6wVEx}}GbUpK
z9>(`tr<}vo#>v5OE5pl}zs9gnVVpFWFZ3{OOxJr1KulkX@gPuXFUCQxA-Q(cboY*#
zTliSSzbb64iyw5OGoUk|GoUk|GoUk|GoUk|GoUk|GoUk|Gw>f^faBMP9{;DrI+JZ~
zYm%iF)~>B77KhV5z-VkxuTi7AAr0%+j<UxLFh`{}tRH1bNU$V2Z~*>4a{hmtb|F~P
z4hn1uH9(wQjb&fzNXfGS9|Ia&I_!K|nt!*$LH*5JbuzjJn;cNHb&J#gsV{)vy1Sir
zTf7lR?~8-W#k+9m{o*Kj?Ipu=TJY#_L0^_(OQl+@uV?r*#$jVYj45^?b!xrbK>Ic$
ztPDq)+zf_Ryo@Zv0c2<TjJ?u-gI)sUpz<;j=AB0IcXy;saL_3*5|a^{encwPu4&4_
zV%e4R5=v7%q`~?r&5bP~b!SUbjK$d|*(T;^g2kMOmrewHXvQFP0knG&s$q`B;ZCrU
zXTGBjpm>)Q2h9hm`#|05%a3FI-)3p<jBg{}Qx{>ah+k3o8|PSBsJfu-IH>}Y3QKvZ
zcM%4+TMcq9r;RvazPrWUGTG_0*xaqP`xW4hb2-_|E$4Ey^Uh~L{~_x+?35i*C~=Vq
zPW#|4c6akcsAo$Z59(VC1COmBn;C9)!=WEg+n*uMZ;z1IH!v-<8vmQr^dL&HH--9T
zu~4W8ep;l*Jp>2yQzaxc)M*-Qw3(7HE9HAm%HUb;6>o2ZqtY+p)byRBS&?BH!SYY)
z$WhOJtKi(v*xr@STGyBXn3apPx3ILburv>0ihai~d8F<NdFK8MN0y-Q8gpS%r#=eG
zh>kW+q=_mqGM_bl=JTqI<bxCygzW|SRvKhJBZqrgZ4r@Oligk8P(ba@A?Y!(%*vW3
zWrf%5jL<>U^86j<xtB-gk#=UM2l@*%ZD1)@3)mizC0yo_(b(KPAlc<s_tNCdk5)ef
zKasM26jAHPSJ<TDNHV9F9S1p#kUIIY9t5zcD0^A>ValPP)ddy;n!)E}ZBA3<S8{Ad
z1&~=O{Gc8f_=jpxO%>&9Ka`O$!3p)7_M%>*nSdO50(&7`1RvC?OKqt8$ag(6-ZjYP
z9gCFk+d9Kt!))GBbdgq;m+PqOYI#8!lkJ58?|s#|vB;NA;GqWGIAlDcY@LAYEs#Hs
z9=3rt`(V+gkUO?3vs8Dj@Vj?C?5*wr7>lq-tq1ll<S`gzc{7S~+QY^RO=KG*^I32Q
zw^@wfQOjr1p0rNI1|^qBEA_#>)9RhC)6@nEdPqW!7l30?CepOB*4E+<SM|Zt3%sm8
zqFxryB8d8!sjRzMrrNt&n9OX%Vueg>hrMNDn-&F5CPSV+2xO~>pWhs*tDYMXIU?H&
zU9<CW7Y=t&GgA($?$Y(%5tl`4gDGcvEs^{)9{QgM{}ti?n(CkVe;zVrx+6#R>w-IS
zrdh2my`pmG-DccE9x57lvGSXcaUn_0?SpsTL=`|-Fj>P7@EN{Qy^80-;?dHvDVunz
zqo5hIc+iK6MW4oseu<l(Bgn)ySqOLUe<JUh4y`>ag|k>`2y9zP8_z;sDe4CAL2{do
zxTi%sg!n<i)?~k-hJBb}!hQ=Iin_K{gzX1)%MA97{JPoWgzW5hWMeYbqkjCJ!3*7K
z?Ir7$#UZ~b+(W^3$$^I49h*RfPSGCluB8B$*NoTVJ?o(xVZ~~$QLwacws&11cbDOg
z4Okk|g0>Jc3td0)Jz)Dovjois)4UYO{=z#zrfV6H{-a^H8l?YJ{7qd-W_2Vi&3@JY
z0bmh4gF6q~;O~H4fY6Whur7WNOadMSI)TT5Ovk@~j3<~@tw;P=@R|7>1WS_$cc^j-
z!VvoGXds2ZaJ<{9rjLCC%13vtU};J~&mGlS;l2n1@F`$5AooYq0^(cbVO&oG`2jEh
zHF;JVWV%^*7_PTGs}Vn+KLGMOzs5@*`Hhv|-mLOG3wM+Uaf<yRb%5l%E)W)dEXC6d
z_#BYm?504<GZR*RCxy&Ho&da?2upKP^?wdH2+!w%DZt->V}MtHuK}+Crvq;Tmjh8S
zJo^a1{lHwn<G|d&Ux3^XatW9h=noFKAE5w{&-{LK-wNe(z#0saud(=>=_W5`Selm*
zAIsUxK$a88Ez<ic5NT8(o499WGO!n(-vY(}7Xya^mjFiqSuQ<5$ezxN{LTnH*n4>C
z2zQLP6R;?-GZ3F9r3=si3<p*Pb^{`BgbpvuQ4c(~0`>&Lj{=!Ik-*+Syc74JL;;`2
zb1cvZ90EjoJ^cQm!l#!b*_O*TIBPj_!X3+z3rN0DC(`}NHadHMXg`HN)JfqFai{x}
zZEp7dhN=FBtNy@gx<A>L$~HEuoLf|XTY+qQx2gU-_*=G<_>SUl`eS`TI)tf=@<INq
z03Qcd1M-_&6BrG|y>{Y0nFc_}B=)7u0CL~Xd|)f!PGCDA%V`H7%V{Sd+v(0glx^h@
zNc5%q>ucXe5DH>|-=xAd-t958T1cH-`^GJ(HhdS(YDWVX;J0nTt?f;Rx4w9;!^uX+
z_S||Bd;A{b`z_%O8n=A@u{*iy9c!9r`$A-dOT0g_XYvb2!aLk5XucX6RQ<>)w9A2X
z|KRu5OaVawe$KKT^R_DU#)tiH+^KW0@5L&<b&GwS5%;AC=hMBltb@z7yium^Pp3D!
z*ADc3zm6{*XkWV81&UM7?a_B81pe_>+sdux<+}6Jvfq(M;(hq68ZUlP>HVr{y?U)^
zRQ&icY(Nn2`(6Ge|I$H+*A43VM$hN_9Q{C1J{9kqTgn!ArOr21k8JPP`ndtCQMr8S
zeEZTV&-Dc5sUCEG!`O<G7G61F`}l)a?NPCO>6H7@9e>#K=Y8qK`?}Ysxsda~tzP@8
zAOFMek~t_}ukV(kAsQmypB`epb!=zX#XFjB9Qwphi_nOy6z`W5Y`<tmzoS!1H(VLw
z-*YG`&sp()!KzPM4Q;=m->+3)yu5oBx+F?+9`bPS{X<nt@O_W*x$DRFOS;r&Mxh!>
z?;d#{cZZ2`d++)AzI4+c_B{LqQNNbOY?wXa!je86YrYg2k<_p`+D0Ky@gcuY&X@3$
zZ9@G!PX^2jMCG3=-Uk=&bn@_q$c>F>y?3tI?!EI+xpkv6pfjK|pfjK|pfjK|pfjK|
zpfjK|@Bj?thMNHod;i}9um6ilXKlIjAJGBO?g2cFv2kB@{TOo{!f?Kib43_dDP=GY
z41b36ZGOg<iFOx{qZ{nR<?0rvu~A5Hz1n7T17q#b&?bqdq!_aa>#-^Jf%q-fY>7?8
zgq!dAaYLs0YhIdeG&*Wi0M03EG9AxGrdp86k&{ey{=Q6HkN1`-LOr{X>)A9AL(BnV
zn5?{lhrN{~PvSyxD^476+Moy#=d@Ui4tt_Cc1UQb9lV*`c4w8UO)v@XY%2I+*}2zb
zUauaCeA3pdIls@jv5T1ZaRAAeCR-_H9E`VYFXLh5L&=t6x0?T+Y_-6hCR>Wi+YME=
zVvvu2!ih2pvQ556Hmtl2w3x9%Bo1KXstC^4izkhOR>7SC>qjoPp$2(0RI7mk9U5v&
zPE2&TokllG-u=p+lCBFt9-o5@IId2dQOPy$LU>mnb6Z-p42$n6??||nV&T9)JbQCL
zR?SFci%1{mft$g7Kv33lp{5Uq=9#lg(|zlWZ`mo!bd_r}=4fa*=g)Nta^3;51bfSp
zY_kqZwipvEQ0)P2g4P;FpT)OnXsG=0Vf`U)-+B?5%Xtgtg<SR*>sZVm=7m<4wDh&g
ziyvUT)0YUplht-XBqFPvEY^P|eL4Aq91og4b2jM{dOrxmJO7F^(_oNvk$)^p;qV*&
z_wsMVU(LV=O`muEd8g+@HtBI9JuClSe)&jG&KdTg>G94lrpKn%FRsbcc;`<f(zEyP
z<&XA#FvQsHi46Zi<?QZNuDs<8;UX%Gx11?(8|~fZK72j-%W@{)Bd0vy^r$K)+gKJA
zw!u$R&YZsU=zF9K!)!NHGgLt#XZNF8)hfw07Y+upm<{-DaQW?l`FtvioCDN8k_U6y
zG~RO7hFecga-u(ySxzr0Rk_6n4N^X6p4ZGGqt<5%;Q}8_1z2)f2DS*?DpJO1Rf$3C
zPYTVs%Aujrb?~3okE@NwUX!;<4l>n2(3);QAupM<ehSI5Q3j=dU~wTs9`Su-In`u7
zq{>V&DKq<2Pv9Z=A!M%e7iBJ<jm+L{vbI+?frS!=btyM2+vG{`8&>{)-}kzt=YjH+
zO^OYHYkd)o(_G*Wdb-JpZuyOfQ`?|2TmXeZ^g>snEYJmc_Nry^FMb25<QtoSuviY&
zW)4r@Ci6GjyN#sG)Eyyz=;fgQ>k!|y7**!=s?6T?rw3%d`1jgP(RX{$dXu%S)MSg~
zfCt7~w!x6i^Y_}yhmtL8`>5sh6;-w>kdI9z=u-H-N&9=eLFFjLlxUUbpyrg<%-5{k
zY4S~DWq|RPkKdW#zsKD}%jb)~5N0Y2c_V)YSoWtJe~&+?wp(}{?E}>n@|U%Lr15tk
z8~NBj;(>BvA3o0kc=+%1L(At~m)SmR_XPCjpa!NgEXQtWVw6!BRHSKbU#2MvZR93-
zfz#}a82@YEhyqA!VuDNb`Pt0!8RyrFwnJ-w8*&f>(-<}{Yy;Tp7#BxpFN0ZXWg8Q%
zF86)%N9tv3y3S)6uifs(H3w#7t2j%L`kyrrkESB2{)90h^gzK&5ai-Fc8HKejun~L
zBM_F&lA0bC`J|rh0M*?%{LXipeqazkEHKdh5$THrCL-*;*{3hT<Vq0fQi~3~dYer1
zE9BE`a+~OY`lHkbWJ4EcOEKET$>zowlS^zz5My2H1!})LoY<lQf7<sb8GobI5O*q&
zgC>yC0NLx~{V!_Tn6KoZIpVOY-!1R7M)3m=v)@mqbq{bH!U;yFMV>oBJ<Cj86p_|e
z(p%R5Go{sqaI~~)<N2)l%J)3)QS?oa)kc>*)SmB|cAg8#d^W~#tS&iYdivshG7fx?
zwPPL!QxtO70sC471CQc&&dJ2$^NFACamKKzw=2p8!^XgyJ7@U*4Bm5`E8@g%0_d;e
z9Q^!&B@thC{WT876TRlR>R`@*GB976KUpI;CR%Lq?gSBLzypR^TMd(EaFVBc!i=?J
z`x48$e_$2J-Vk}pK1h9$hf*Huo8ONUStt4jmaoWsm;FN4k>lbSXG=m>y19&S4Y1*8
zcu-U*4$sLHf1_#&(?iu2GvLYb0Pcd}PR`lM`7%DUZR0nBri-7{1?>uCaphUfl!NZ%
zeA>hNlXG2iJ|=5?Epka+yEec8#L*6@#TOvHQ}QhEto|?`>7m>nAV0&Sz5E5M{y0yP
z)nBZdz8E0=nZ43CS>^9x{e`RXu_?<MAJ3X*-+qu9pVKS8m1=ws>u>LU;=>uJBEIQr
zd^5b_ljC36m(MDvFMkHeF2|!emp?fk%-NkBlgY7K*7Drlt2_s*{GdAAQ||Gd5apyH
zev@O7jCAG3yBe@G-BB+1+ylsOY%jIE7}fF;hIf0_c*^5%@{$KO1eRtv_+#H`1d!c<
zkwEIWdVs9=qkvj@y{P6(0N!WicQ)Ly9J~pn9CN(<$-cJa?P2_-sqwM@nbqH9gipDr
z0O3q|9jM7E`=_$s`k?;EvqO!K;n81iSdHhG)%ackmc;vsKm%}+8ZZ6Jew}P<9@c*t
zyvu%<?2obBc;^$;+eCYSxP{IxR7yqtMjwU6l5Mm|e{cLP`%bb?#c=Y&c7mmO1@73-
znh0dQoCHKzLWi2=V=|tf1x^9h1HKMqpKL0S{3gK4zKiVBFnms*M8VSFGa<sS4&<;9
z{E4&p5vI`H1uvdPcwYzD8dw+D6^QaE&P#p{h_auqyIu+(2HAg*{R+lsfTjL8O)I!(
zdhlMf=k0;4PaT2y+=z3Q(cKoh=a5M}*H)j|w?W)OSG*T+5T5%0CjgNi&m7?Mzz>1c
z(f%A54crSf0lxvp0>1~EfhT}*K<L4XbD0ByRy+p-6M>C^NkHf&i*uU00UdZA0CWOT
z_Y~->d&U8W0n>n^fJ=d+f$M-{fb3U|1ztgXRdPMN?y|4*h7SoH%E=o#Th9M(@6mDc
zi1xYav_)fZ6$LT7^Nf9+-~6yT!4Ipm`=8Ry^`-ObOJ~=YPVGOXBkM~C-Iwkxii>U@
zf`Qy{YkOqt|5lro8{w@(#mV^c6hQ9bX%gsX;C$)hXwxH-bERWvYpm1mvd6g%RU)by
zx;k*ifORN_6bA0Tw<coDq3!q2t8@yqqAqJ=Q0!L{hV7m|EZg_b0x>^_hEa^mptIl>
zR{;olEOg9yH)1wMjLW>oeZ$o7i^DO)F9yr-qcO3N5k7YAacR`#7Bi6#6aG;(d;}@N
zFRF&`$u4|#rt@LKk3<_v;~joeBqlgh_?W2CatsXR6h6m)`4Q$kgrjXO<oJ)gX>%W&
z)OZWQ9eLw-l)Q!ej2E-NC^VRX%`tw)qun!SVBj!l#zj1Q<o?Gr84r_XOtK`!I))hI
z)I$$kbe~fiwJ}^Y+{&_qeJ=Q$-)Q#DB4KIpo%Jxz#z1nyZ#>INGhiuT3t$ki6|gF>
zHLxZS;fTHnzv-9p90n`P6z(>Xzh~+rnc<G{Bml`Nzr8HP1A#1){01`|_SIzBk$Fye
zS=Vd8(%A7c!x;o*AI1q}nFA^5a>%lg;h)@wz|wS5{d4Tf^!5ZY9QG|3PG6uVhs<la
zHkMTm_B|*^e;~t&2C|HpRR2}*x6DJCxAe~<RR)#@918!>0<Ylt2I^5g2%6n}GrsmY
z`RXf_K}R&e?^MX9SKcrD*p{X(+CKC4&xhXC`w9mJPAok$#rOW0|5RT=6bSu4odKNz
zodKNzodKNzodKPJ`!c{W!J|9>kLu63UfdayuKTYT{_42DQ{W&Bh(fjdgVpge#t#?;
z%JYoOn8#Zw#(T|sQaJ<*ot>!4)6#AqXvG0~9P4q6k&O{!Cv8022jO&&g%(+)IBrI)
zrE{#sbGyWmQC{aA(GS<zlkt1o?lLBZ&-Yw+<@?s{GTw7Msh!y)1}^yhC!~dG_yJf2
zaR*?~!#M?c#*%tPyE8<{uZ_Rp+}nux3hf@}G>orXYv(hmXVhtDZ*_eFzu}I+7-$zH
z-~d3L)W(45m*dEV@Y~XkJpie0)u&uT2K5ThHfx1D9eK2l#i_c&d!`jhy=%bV5f-7B
zBkmyNd#*`W!23w&kWQ8q?Jh&Po}86ux<3H-(U6hx*j<<iz=evGo$Jg4GUZFUctUor
z^>X|x&+&>-wa%pMTrcODQ|X*|ojJugxz?M6u%%y~i75Rs|Dy3e!V(Wv46K_&m@ZPi
zLd3~6>+H$|xjcm5nC{lLSnNK*tcaR=t`WD#1OSU~D#G@jUyx;2%*Ts!LJE*KSeg?U
z-?EIH0aB&v9FSw+Ux1wRzX-%SgK`Df0(ceJ4fqETV{&nx4aegX5V0&@vfSmzb1l5r
z=C_()t%vcn0dgGP76|H;-oPMWG?4QaNkGhb(4Sc27z^xyXRaBUfLyC`0J&C%p`utT
z!+gIo7tiB>i-41XZv&?T7X#CPSO@UD4}1s6HHl?FoUNiP2Yv}$13U;^3*?%_$H0F9
zw*tY9vJLnv@Dm`@`zi1?5bFt^@<{79z`8)5(}TNz#d9+t=HEOxD@FMi5NTC@2HJsF
zfvG^;GwC6Bg|Oy`by=kt5NT5$2O>>M86eW4lml)7V$DL_U0DbC6`n(Y-ve6$S<hPm
zkyqmGNMCCVzRvUTb?%6-H3MI355CU%@HKzpYp#E-m~Ywg^LGJ(#?8&Hm+7+j#rFF!
z@pV<azxR$vU+03vi}{xEW1@;bUH;a)1HS$w<lTrV7kr=Z;%h#~*V==x`<0Omy3rZX
z8PFNf8PFNf8PFN{pJ4z)x<@$v$BL`V;`Uzm=UN}f7t$0_*Z(uG`*$`$3&7Ca<-!^D
zT=S>-NqH_%i5+ZK%%M@H;M!5f!FK1ssCrSZD3>!fDkav9eTS|ntnuS-^>Tu!m}G0B
zIST6GmZ;PucT}P^CjB=f_WIi_iP+<0Nws7jrVLRFxs@fQc1To=)fSanw~n~mAStmH
z{UZA8{cAom%S36Vnsk)4E^bIr88W$&I1ZENfCrEyn7$Y%X!sfjU)998QF_6nwg+Jn
zelugQ0QKBCPho)7^xXN5<9d!oRkdfh%M;jIhSj@s=gxMH&r0JR4}L|Iow%hug8SB6
z3~^)H1mpWWftywLNl9?uJqf3=%lCWJ-;0->>~@C;>s$H0v(@Y!l8on)>Zfz(NGGmk
zz~ER$M7i={Fbf$(V3dsS3d?tNB*LdWPsw+!Pz=nG*f4=42sx|E_uaC-5A%920)cym
z-Ce$S+bv>SeEN8NYc4pDa;E14$G2<v9)|1t#5O?Ip|(Jd*V_RL0^0+*4&DLC@pDHY
zhBso}yezOYo(;e*z)HZbz#71CU>zXF?w(L!1h5IPClG4w;+$2E@1X<fX$9nZdut%q
z(GjLtNAC`#E?+NTG%yMn1H>A;(B(4$&3J|t=di{D<M3<+CIIa~{O$1oQ7k=Ufi~bv
zK>X%;6^OCDXDV<Ia3&D7)H4@|;^J8dM22{l0F#050a3<09{>jfHvm(C9|4B|Hv>li
zKLd^geh&2D-&ep<z`eln!2Q4%f!_ili{~)#W#A9MiNJpWCjn0YA*1Is@HOCB;1u9*
zz}JD7fS7aeTm{Ym-UK2Io<D)JfYfcA4a^OE6Noc@l{8>M-~wP_;38mA;9_6^@NMAZ
zK&098BycJ4Dd4+6&O0mzRs@0z&ojXHfmMJjfYpJkfVF|EfnmV4z!t!Dz}CPIf$f0n
zfgOPxfYhzr2<#37hn`-*kAZ!Fm@^Uc3&BX!vXaze==<!&UurD<^_%Xax{ur$GHEjA
zjKupk70UJ*5i(-!7XP>rdEaxB4BhAq=nUu#=nUu#=nUu#=nVYVGLRc7i^<Ucx4U?G
zAIG;i{w)fZ#mI3o2iC5rWDaFHfW<L-{8KwBPK>VMjb6l{HeHE4L+xMa{71{R|I*3{
zM}Fx1OUyj>&rauG+|OrBiKSk>(;Ab^L1_uxizn|E^nS~^g`hx_I}u^y9zAi82o}5D
z7GsjhW{S5Y;r2M`hUW<K4n15rX0{LJ{{5i9HrN&nr2#HEi*TB^XrF_dPJyFJQP)|H
z+Yg}MO@nT=&<%ea_-hcxV6`}=^^@YnnOtt8#TJWoWbDG$&V9=`w5ACU)oE&wN9%AM
zx>x}7=w6fgER*wyM>~IvYswu|nKZrsXAwXi*qX5UpHY-ByvR<b^kdzm08JV1{dD9p
zUP+&a@IHIy8;q^fI_2kB-e|-%kWvpMs9Cch?>z=#J+*UtOmTG@#98WF%$9oQhIM0N
z%rWNrb?P)|R6n+MqYz7@*rs7&Va<Zf$vBurW@vn(J;sz67T&yv<TVM$%vfVEMPTF>
zdbrL$_rt=vHE-QJD5zWWhl;u{d042OH>qaG0KCH#fmox@2Tu2T=X2I#7aDqx@J+Il
z+)xdt0eN%O<bf$NAh(!T#VM?6D5}hdU~zUJ?}4K(MG3s;+z|Km|K?S8v^k{}c!xOw
z)HDCU8kmo2hk%&YKSUa3o>R9Y7t-y0PC|c`BT?Ako^uriU^$2JCc^YcjvhEo85M)4
zIo-cL)WPrCSr1da(xmCd%)-0O#YE~~XnR#WtROIjVe`UL?sM=H;GM5t^;fGaaF$~|
zrJhNCxbqhkBF^r_6dL`pu4?fIFjAPJuoQ)IJO+NLppjlzop#ZlsV7SE6dZA$h3`6=
z(M~Xa9zdY^(dG+zPLnIa8plaA%Hveq4s6g8rUCxvoK|hvli<VPEzg6Ob8)Pate&Ef
zr++0Z2$%8;`S5pUlOaF#aX#|OSB=we@y=!$oX!QyY;kaT8@3Vxt1je~WtO^H#gSg`
zGOO(&i&oS7B>a$nw&UEZ<Upe-_{Y5T-`PX9RSlnYkKwbPGW@-n!vE`g$P6lhMbz*M
zso`JDF8sf+his-AzBfPILpC{6_}*=o%vXq!oe}e#S{~kS4_PTzL>O=081G7-@jmz-
zvirqfN7FS_<F5!Am~Z7_nQzh6MY+f*$Hv(Eek<8Nv3_ZL)()uQ5*RLv2g6OfCtQmy
z#foc(W%uQQ;^?5t-s&*~3X?UCz4yc+Kd9>0)#|e2LQ2sS$~g~Z8z#>~T&~84Zjne6
z^NeW<mwDyIl^S1)$!VpUB_@u2w_$QlobhP-pH<i(!C+onVX^EF%Xlu{lP<NTRKw4{
zjgjH=JHa-F{TS~a8iE%2rp2A6#$6fjnQza)PG-9()9AD~>}V&jOoIz-aej?y-~*)1
zyBr#gnZFNOURGg+hCy&5-a$adn^r@VL+^@b!~zXeUwP7x)ozSQj*G)3-1M6h$M=(?
zjasI17iLJ}3QpvRJWGahZ~+7Dqz^eHAM{5Va`TUS%{^^`Hy1r|uFwX=bKeNE9x#++
z$5Q5PeKl>VYTCT(i)iCyxylrEEaZPsK7--bJ1ySrz!f#l(s0A_#JWR1S7sBZcT4b~
zac9@IYGrB|KNc|F>1Eu<vx(bR3-K^=_~PJ(DhH~t;DCJ~$`PGSnMz;9g`2+<cLk+T
zU?3{50e!Mu$ek>ocTr(3BM#=B9K*>z!OGlnk1@m(<_YL>lD`tb$AKk*nm;+tlKauK
z`pX4(%x`}nnhvFa>Msm`%drH{=2w(3R5H2?fu-4ms>Z%J*L>Olxz-Z_+zN~YZUZv@
zFj(2&mi_Q(2<aWpGW<-r-v#p9_CByKa0QV4^;JME9kLHB`=nXZ@f74{J3t*+hF4Zi
z2YHiySJ|h{>hCOcYAMe-AgjPHKuvDh$CPK~WljGQ$W;*Tmjc-aGaVStigeTlF87k#
z0b-H83i~WfKZY`jmT$cCl<_|eWM2>KbLsK#RsHe%m6bQF!wG+#fGoDq8}<|fb_Jqa
zl78M+L;QVF4TtU+4vLO~A}tKo?L;^|fREu#PhcS+*74GLpL`$rE2;kL11W!~>W}fR
z%p$*cyw9orngS_zD<I{@I%9hJW#2~L-<&o5-N7$;Ls=94djOxtb59`qM!kSqxsiPt
z*}i1u-voCI2j6fH`#xw-)BVZ*N%sC;R{g!A`kScwW4goDbh8c3%6A#nUs)j2TMo$l
zh3q2UX#6ev53*lD|18f)r!X_&j{S#OKm(9##LP>s5i{;Nz*fMyz;NI^U=(mZko}W1
zAbDvAEBgxa93;lW`olU$vlH&f%Pt`0+zo`R${rx=>3-ldzym;r=YUOvAS~xDScb>?
zVTPsI0Cx<JYsF6hvF<MNi|q&N=*PfN;8tKq;5H!gRQVKW0d5D{fjfZgb9@eDyi79*
zV7$zK#_L_qSU;JrcYv&a9{`^Mt^sQ0V{&!rA6|uj@A}yn?kIOZAj=21Oy^I28>vqs
z{dw~@K=o$>7RK-3N9bU<fz0n@Aj?MzP?JM`@3Jp%ufZMVm<*&GQ@s2|tLYEKd#2x8
z{<l<ri-1M(`(oe~x<di10|5;F@5O&my783VTV5;r_R4L;Bb!Y)dv)mcC0`f*wBxLe
zdrtm}h+~Aiv7WKTk6a#=Vk~ET@rC`%2j@CaYRshh3*C9jefD<ho8yp?lZCs%?Rv~=
zysGfDnR_P9p7Vaq;?7%D#y9YMSA5)=BcJ!JF#rYPW8v<Cy>6+mzMH#pVZmF!MqkWV
z*!JeC)<s%>{I4M!mrOoYwjMJ1l5qFRozkhhg4gYDGU4ZIrGHv(PS|}s+7)qOQh|Ys
z8}#cORtD)n#v1%z-f?i*#y|Uo_V4}sTMlQ~;dMtQEy|a=X-co16VvwO--bdlK)4$|
z=)>dPzWl7#?&;f3zjk`oN4Nb?uQq)3(wPY_3|mm-(jvH9BHUeU(s+4oYro>%KMTr#
zw#;w8M64Tk;OpGE*4@3;eD~bx)ltWf2zRf(fBmB;$6XzJCO9&-ean#BJ(hi&H1p&<
zSDVUB&M&`F8U?5j3W&i!rcADgrAup%s`vW#clwtKtu^#y|67}1c=^!y6~iYCy4^V(
zdOX72)8!iO8T#&p79U;q|M)_|IX^V2&{8qC+WgJ0ZF?rwi)?WN`YFO)gFL26acke%
zHm!NLkq7%P8fm>bzvQ`ul5=V&l?j^Yw4xGi67FsUM1M1)?3>YXyDqlBS)<_1T!%*<
z>Kya&?P2~E=Ek1fj0*O<a91dQn`WE(R$My1Rxj(kXM>Lw|N6N#iwgLkxcyF}YQ3h_
zd>>;BR2+kU&hDaxyW*A)8cwVb(P8kMCyyR1aN%yCb?P^zm4s7`ssxTYwt7i7v{Ay{
zD-B-%BIb$f^;`ZK*m>!Jkqh=EpFj9bt6Jrh>aR>4d$3V6v_ZmMjHi3I_B);$&~w$L
z0w33ZI_N;ilDBtld#POD-f9D%^PGr4`-QS#@ZYoa=a{68feEu_9J>8ozvpjV+4S3_
z<8u$5I5R3`Zo7S!g*XpIxQpFUacSjCxwdrko4w%LhppZ_Fy`yHUxQL}oo)R5rU65L
zEQUHN+zm39oPK0OK(qKY!}nD_{N}L+^^2Nf{+JlMXX=YhH@-U(AC5)B-PE;*k5pcg
zcjm(1T>JMg{AS#swXH@J+P3KX3XP9ETll6u1pO)DZr%IE%)NeWcen1ulow5x>YR4o
zs5kxelYT1?R7>1Y{LLPnFlQv(Io=Dbq%@9nH(9@LZt$r|>yF;;_~Vv}{>AInUln(1
z<I_{opF<rs`2TsVUBT^Dm-hXrSk;(qy}$Zw^`(-ZZrvF(Y4y}jZ@*USUuZ~s3wOm2
zSe9PPb-7We$R5{57Ms!Yc0|8Q@68FGwg1}TmOF2SqfvQLxGS=tp5a$R>WAMy_v`Xq
z6RMpm`)$eZ_pcc9)T=3foZR)+7ig^43wL{(TW)V{IjKjj#F}Gr&s$rtwCBoKBVPEz
z@%_tH&(1ji&M)Xw33vHVFZrclp%I%8p8R9}Y|FJuSC>4qZbEpqZK*rs>$a@2ekQ(w
z_^=rKPo=$l;Pd`B?ce@!`)=K^cH4KEiq0z9Xj}h$TSG5(jvh1v-&NtR@$X+nj%nHU
z<;{&xSAPEZnNI8eWoo@BxW}|6y=(vU!LkA4afX|4*E-+g<J+&4eR65xCt8kaR(kH_
z$}fDH((0+osbfFN-T0@DXb86pcN^lD5A86fTYSGAPcInX@5xs`4((;GSEG?-@T^@I
zA}^IVi|+|OEC&Ay>+-H#R3PS!%GGzCx?QhH*C*x|`ti$x#?rF~Re$zw_*#_HP~omt
zt;*f{{n;j{-qi|*3MW?_9lN+_fo3nh_tWt8D|VhU)c6qJ0^x2{{y&=)m=*2Uwf?@<
zM_Tk9Gy3eIMn8lM{w43FQB`K=9rp#k-NM~*<&)DFs!o0Kx2F?Y?=bDY*>zO$BWJ!%
z`?yB6`H7~pE%z$Q*TUVzZN<;e>i5gb&vz}_C9Z0n@o$ZbbKICeZo-^rN6ot7zk3eS
zVPHCbt+MnT%a#7ON`_QDw*IX#jgNmc@yVq_Kj<-fN$sYiR!v2CHHEud?je&4l$mJj
za%jz-HAVJyd2fGm+b8PhYdvr757*0>f4z%xCEQ*3c7yBIs^%B>9c{Mh^4Z-<UtAwi
zWmk#va}F1{v9b5<cfUj5L%8exdY{4{zmqh%<iPJX#ZT+>#?2A0#=l+i=Xr;3rS7^@
z?*u-QM}@oc#mav8Wy8EzU)bNGi1PN-DzVQtE^?<{(rX2)RSp{W{mV;G&&x9%Bc_Db
z4ZAS4Zl5Ld_I$R~^+o+#Z;qSW<C*Kj+Z~$s&B9x;iqc59J9#75<tmF#tT?hd|Fq6$
zn{*64xi{jMr<c@xE&52lil6;@2zrCU-48#FtXyov=^9I34r>?U>h8a9;P>UfSQdJ0
z`I7H<R)}j|72i(bZuyN*d)VBeXWReU^TLW2y;qOkv$W3s4fTWLSM_<T*Q$N9(N_}g
zPS;;F==O*ke}1z2=<5}CUFf^!dfz`EZ)5#nMTcAcPmWG%j(RTKbvaRD^*3Ew@A+(h
z)X5Lp)m_&y<j(9yZw!k&*rUL;{p)W!(Lbxe^qxC?Ht?rDxh|BxHg;*B+RrR*S0phs
z_`<FEHQN`c8n|l0VCZ2AcjI<F{;Q+P^nwR(4x4iGmFc7VwYjo>Q^NtjK3i?To4Y;^
z8-qTgaF_41z<Ni{Y>t^6sjRuauVun7``13Tx5vhM9k&mTyuEC1A4T~>xO;ie@z381
z?cDdLXPOO)zgfMAbJDr-H|o5!`|P)4w)ZR94;`GV!risKuaEVNt}r*=aH~!4&^P+^
zdBuIDLWi!4>h`?j9#`pG^s%Z{WI9@Herj#0)4>}H9&df6L)&`e=jFftZHM(yRYyAp
z=P!2qt_O1z!riydDNpn`WiENny)NJ3B?Esu6*hmwz!xulGVJSL+N^Frr?{d_6Yf4A
zuzqoD={ikUu9|zH<B@%zU4MR6lbTm%SC}$5?$1O0nt|tC!d<uFhc-1R_T7xxJ9quE
ze)ozsjcfEP`Pd)N9eZxlGv!{`9v_B2U=Zco)~C-evDH>y9$x*c#tE*ktGG6Q8#mb+
zHg~G+=G3FBwxRRgSh!m<-|<$B7w3Q8YiweR_R82%5g&B#QMTQ0`FfUYSbpN<6^BvJ
zg}W~Xlx+P(zIS`vm>Yff_rrsleKjC={Hf}FClwgIr9kH|N~1&ip>Q{P^RCp*?>^DA
zTJt5<8b%wQs=I96i6q0IX*(}Yt#svus_2Iu74DMF7p^^jH~(*s8-u$SKRr9`s|ha;
zc}E!@nOw2Om&5y~A-zSPVLECb9dvie+~lUi>b?8y+n)@W5i_#emm}IA+xMkXFnr_N
ztB{VS!rhR86)JgVOwRYx*bPrc)*LnQbo0sI1QraOKlPI(pH8U${7IbaCET5PrE-bl
zKd#y7+2cqadbdTt<}Xwo_rzT1<&JN3{OP6DMszCEgu6DK+O=-c^LT0VtAl^ue|7Me
zi#IFXw+$`vk#m2Av2S*8*%jrmaF>7coT^c0?;hD%sz<SfACy|-sJya#uQjg+v<Uv~
zi}JS?HpbdSC8k69!o6YCf}mO_e)*)_fU^Uv2bVeGYK|`S+pTx^oE!J1{|V?R3wNb<
zM&vHhYs#2S_2)eHYL7m}zmG~DoUh;1J|&y&*wngDk7(%c3U?o^Xuqr9n9$1O!n<rc
zX7c1(_|wLJeKF*>(#N`u-d=m&s*xC*2zT>0eRp9}-0t5zsh3Ku+rA(<W$`CV{1?4&
z?acf<@iY2*FaSIw++99CWo((Ie?D7k<Z1u3t1-JyMeZDZYGO$JnJaBOM!uQW2;-8<
zOvmbi+bRwUEbwv>$MC5iB`Gfjj(_2BgE>zQp8RvgLk)&F@Lh-$?nc-8VeY8`FEnhj
zclqwzyG#0=Z+BvD)rbvaD$K22cvMAybmGSdcfpZGK6rlFkk1!?H8an&;2+x+8Nasu
zhck1vtukrpLQm;q`1Y<6?w&t>Wb#f=RMqvB>hIlFxY~$-xg+;2snloGSL@yjT)+D)
z((sFLw=yF4wNahRzA$V_)iq_CzrOdx;0l*wwyxS=;pVh0)5BN9;yYc1>6jC}>A;I)
ze>=PTm%Y6#+j~^`Vd1x>JEtCVytnuLlS=L<zJ$KGaM!M4%+dV0{0Chq^z?jd!?fGy
zom(TSwEdt#-WKOJ+_C@Zz}c$8UGMQBFK%5Dxbv~!i|x5};_i;O-;U2)F>1qt{!<Ts
zH~q4s3Gzd@o0Rgn@rqyAj_*1Y*ys9JW&3X%2Grb;uW{ei_Gb#Ut$TA8_MHoNpPZZ$
zf6_KQ?bMNLQ61kHpZa5)=JVb?yr9U7%@)7)+Nh_|o|Z>jZt#D4?V|DK?N3gbHfY$C
zh2x4$ckc`>J?6P1_Ig*|xf>T;X9P9?2zSTU+*tJg*t-(=CW`hQpxlTBFF??M<rJm&
zWr2c#s0E53q5^H&rnFMp(xy<5qnuVmtcZdNQWZW9K@d<;fv@<X@+n|JR1lP^$R%LG
zawymTd1rQ$O?EfgCTSD@U-n1XZZf+&^E}VI^Uk|7vm2LhxM9HA$D?|jpEo`+W9$b9
zhW;KGc<PHo#jTdq#rSZRZbeL&B~6d5Y`F5k_LSdrm!EDF(R}lT4{oggOn70=?H}(3
z&TCk@uUgDDzTM-MqQHQ!H?0f0=k$fGVgAGXr$%16ke$;v?1A&>TeEa`tbFU&PFd#`
zt{LxVX!M1Dhc8#YmlO5cV~bWcXnMo#El$Bd_3K3CNEniRsa|&2A9*F?>radQy-Ue&
zol6o8-%YzdZe^G7;EC|Bf?2v%nJx6Ue7e1R`RMCEyl~UowU^bK|H6M)&zt&j+fi+&
zcD#QH`nW7zov+@Bj=!nS)dROZrCZVM$&c<``u(h!tEtJ4n!?(D{p#t@;U}_m9s9gE
zwCRMrwa@HroOU&4$MMTeb9<MaSUGOq3Pan^J|6Tb{6v=S&4&N(GjhYKA0iu!DmXl|
z`;sk(Vm^QI%f}*Lzi;H@XPf_qV8CgXZu!r;r2F+N%9=(NeWrWvt2R@&wU1f8`^oqA
zF8J%2t6RqxV?I0D5PdD<&eHU2p<&IJpQ^KP=h`Q-Y89Sc+pOWsuTL9OboauTb<n|M
zEZvr6b@vRoH@0Ti(72E8|LVZ(bEA(hopRre39Hll>D!KJaTaTGvve<*ei{61;{3M@
z`={q!4cPEtWS@bt#)?VpQV$Q>b+Y%Sljsk!bPfBgHO@I%w)5KygXX5LzGcciTa%;e
z=6^MR<?3cp#<am3b-IHr-Ec$c2f6*rr*{sl(^q%A^!Dye_bv|D@!poY8&3WDVW*ei
zKl`D-uCLYV#I8I4eDBEal@pB#lU66*mcHlsq?Rvj7<hJc_kpKwNk5KwDNE;9JM6vJ
z65I7pIJ)4@iSNbyJ7DW=@0?jRdspit1BOq!_B`6&T$XO-*Y&o}sQczC{yhS|UGq!e
zTz&rszG-{+u1<SzxUqG_jIK$Dt+I3{9_jJr$fTLqKHc-qm`f-BJ%8=toq5j<*!Nk7
zpVFV4HuUiiu+9TZH}8{y^A3g0X*scUajm{lhV6X=w_aVas$}xEe~sV&*5#GUFrNo~
zV12Fpt51$uTD)^n%O)d6otySS^c@?P^^Iuu<^!*OIy!o7mvivz;#j%|-|Mh&<K15m
z`t8!?yrTzO4DWt<!jh=|@rOeOmQCyT&~rU8pMs@(Bz9c#@{5DMyVa=gelhRs=1cC0
zfA8Zvdi}LKE;?e=50l@Azsu5nxYJboxya|{HmSRzsLxLWex0^z{kZaW*JdBdT(E4+
z%r{rzncTgUzu!jX{;_)fstu1P-LYUr%V{4T9&`S&cel@3vo`8l+3UH`nl6^5d+Ot{
zCqFrrH2H^v%iif2*zb)l6~8Zj(|C32%KF1*-Wf~tpeC|(`!Bws`|LoMx5CnP{Wqm>
z`PsVfPrIe_2g3tbr?#unyj6#zm@mQ7ExLH(=l{MxY+~3Q&s=|E;jc*_Tt7IlWk~&Z
z7FCQ&TKB_ll=l=%*K%X&gw}Jn$BYl#81$Z@&y^dycHDR0o_S|GK3=<3()Q;cL;KN%
z%JJ&esekq95q~~C`9GhmUG?%`_f4PJre)8FqrbkoVubGG60|dqvvk{<4J~b_oAukj
zT9%jG6BhFOsnPvEzbU5KE0dm^b8T8sMG@*ROLrvSFt*df1K&zpH2c-@vs+9~3wboR
zEN159!2@&Fz5Lk@*r07J-LYZA4hO_$|G4|(9rJG3xAT?%bZy-F>g62)eM%x8j6X5s
z8LW57(!HL!Wy*&ex*R(>D&|<$#CE6Wr%r1bV7NRcd%~x`%+IJh40Z_G*Viih>y3o_
zoA*p^`{TbK8r}b{j&o1HUa!s{51!6=dClTe$8MO0@i8o2_*K7;BUXJK8@K7+>mR*6
zEA;)EuV&SKtw!s2PY!(Xd_}-z^t)NQ6El9PGxciMV=+HJv~F?U;wJ~Jt#$Fcr}7i;
zd298&(DnV`mmFg07Jks_v&%hSe5GacQ|Gs>KiXqs#9w~;!Dp9cZn=8H?_*BAiE%qY
zl)q0dMMv%3AJX&A>z6N;tuJV^%-?X*aPh$_@s}o~9-p(kE8+(%-JGz+_gsIr-{7on
zyZ2t3pL}@fw1=;MzT=BKcD-<>{NBm$w#GaqmhNJm_Ycq7v*ldpYtPR*H2%4^!+ze<
zzWKL%6JB`mmY3^3ardW)-LiClWxd(`%Gl*AHjaL@b*(iGHuYS4`kPu^H!aNVc5e9m
zz)KP6ud;LtS~aiRC+e&4n;za+ckEYPrcNC6Rq1fkbC2|S;j!kypX_{4r@P3~_4#N>
z*u}G^tD~cWM&&H&)A+-h>$Ws{=V4v*t2^q)2W@*A&y<3xyc11L565@;;AB*zSHA!6
zrP^=3)g<xtmp5JAXsR81@!130cOzEF(jEA{G`T#W>z+2JLW*uR?0NULL65Kbq{fmP
zrY3w;^XP@!;D<fW(p`>z_mAL*hwFAXc<SfdY99K}wx5iDH}L;*)y9xf3%*%Xfw;wH
zmM-%8b02M;`1j)RhR*9BxN<#W;>o4=K9*WK^XY=T6)p1?9zr=-y8oPir2O1i-I`Zh
z?Ax?qaT~u6o_y#^dDAez@^1OJ^eHd*M}IYh$`So#Owf`VYi?e)t^eug|6JSX-MqQ|
zE3Pd0dhB<%-P@w^-;*#ujiq~LTXKVcPuhNZeEzxZ2Uk}#yRiAMxR3h$GVZIK_;C&Q
zp<3$RV(Ci9_#eBt@U=4+&wM{AVd#KvM{hj0d+6pC5&g1nY0+%szfyF%{Vd(|W_44?
zU4Coqk@=_p^V+IycW!z8^OkRYGwOrq4(;5Vc<KcDWsO5AfAjBYSn&I#W|=3#t{kru
zw`<qQ=m$5vzO&Z(N9uj}pUE8-j7NW!rMn|Hu2s9X$C@u4JRx&H%7nt_3;K1wcK%HC
z%pF0^d$wA17Go?~x=U?L?cS<={&4V!Q*Cm46~7b`IAqDcCnV;+zx=d*-G`5^#XK>V
zF6NnobALbd%k546wYh$;Zx8?0c-M1Z*1NC!lg7dA@0il?3$(w7Si0lAzR1bwnLGMo
zuihJy2Og^N%j-MOOnU63{)KTDS}gtay%$kG!l)bze~r-pb?Swm_Sbu7{@Es*LWVbd
z>uQ@m%htRT{Z8kyM{6B`J!R<}$3>rJ>GW@mzxv6B`eRIuA7B5&JsGopnb>%7>D^}*
zZEl^LwI!h48njz1-BbQ2%HyAWc68Y2g`-EdeChQm>k{=%k0b{TxcKkVW}Rjs2J!<-
zx8u-j0Sh+2+n{L1?@jdQh9oY_`{L#C3j$jXs4-=GT+s`IQI2pbN7~*Q&+Fa|>Ck1p
zvGB&JspsB5l(=g`yMxAn_+=aW^*Yl8&!SkmiQSD$7H&9enjQ4;cRlJ1?OG${rI4~7
zuczL1_kffQm!52dc7df^QFcMsGXLS|1J^dj84ipZ`dM!3_T1^6SFArdylm*WjoFw_
z$I{h$bi(yo-`)An=A}E9y&JId4?|q*zcOb&G%|YDH}{W@p8f&W{bA`I_;W$0rcHib
zwmSH|7v60#t>3z54o&(jY0o1kcE0m^$0_fY<5@3kg1*+W8ycVg`o!quhkBfOZGmag
z&0~z0j2VYd4?ln3r*X3n((2-US-N>=n_VqPIe7iahqm0<JL~f~3v&LQykKCrX~~b5
zeDlh(4p$KGWa-+pTAZ_G_09b=UhBAPMZ*`?FT40%$+p>B&pz?e@Gn|-Y;+3#5KH%M
z_~ovTZ#&ca#YQ*REqStd(CV0@VaH|{{Ss6E+i^qBUoM5NSh~v%cg20aR=@jD*F!b8
z{P_KeVLy%dY1pub{#dTh?$jyo(Fqt17)j-5yJyjoSLeMLcI@niIpc0yc(9_zyOVYC
z&o7C7EcAy3VgCXyy;(ZP@$6id?#lF)lYV@2<*(BxH2C<YJKN^@PdIhD^N+tYUH#Fe
zzm_eFg8f^<(tXfoecYB6J>Setf9B6Qi+_(F`&*0hX36z>zS(~3mKXi%X5twaOZR)}
z`BzixK7Vp`__r^gd1y}H7pb4z+q&@Qjc+Hd&N?)CC+tRjw87{fZT)I)ouf~U@AUb5
zgM)hfcr@{&&+Zx#5ZCDQ248-&T6YlrsQX#EdOu#Dd8**--M6Gge6oAMEAtDk7600)
z-VZ-b-1gM&uj<X)gZZf}-RF&Onmpyw%xM?zjlX6p8t_<d{5@@!<lohQMf4}_3NIXg
z7xO+@y7oo=i|R+37ByYE=U9)m-=;L5{n%R%1Z?~9n~ZM)+XNg&|Kl)Acm4G<bAS7A
z)zp(0U%TU-#xHFN99!e~r27h%cMn+Df6>b=4S08GG?nA!d%n7(@Iw2315U2`q;FJ{
z(Kk$<J!Vkcz)6ee9_ZA^ZwmasUMyYkV{2xgj~QBjYro;Qoxbtva}V}z)xG_;tEMSe
ze=S?S;+E-n;Kb5>-v9Z(vT9HHX|tbc%h+LOqJN(B>qB?n`QJSY9?xxkZqJbi@XVa0
zi<(<;sr`gI4h}uia>TTd<A;u!dbjy_?!v`I{a<>uMccSB=y$VpIp6!o&6v^0FL%%}
z<FXz<7u?<3|BK}h&OCNtL7-nnVwcq@17ZmJTDOe7y0P*4wujG$K6|jsxA*q=;*)^0
zM_V6RIjr-PhjMP6zX;FHS-KOgCY|Zm=F1s#gZ!6%mJs~&i_h;cKJe20&pvhPwGRfJ
z8Hjo`how6kH+oUwQPY(;gMUo$XW4^4Y`T8+@)yr^N;*EGM?%zc#FV$OblvZqeCF@H
z+4G)xaK~$%^z(QA=g-29@9p2V;KFXx^pkr##OZWrSh}p|R~}4zbHD?Wr!}lyfA8&Q
zdw)EsZDd)$=j-0_&@(*~g8qemcMO#y`{#TA_$+qHhOOgU?>|&}==|en_nw^pRF8G*
zI`ld-@xGi}P|sPq-gW=|V6k6Bqq5sZ?p*TCm6^ML?J|B>VbQvbZ{K;o_D8+yA%4Kp
zm9KbY_13}uPrUWo?W5{XuQ_r1sU0t$i*DBXWkc-MGtVwXoA3@xckJ(q+x{#)eE90X
zsrT)AGT_v22WNJTE&TbbTU)N5(s}#Mvvs;-ES=-$GtJ;T>1&O6v7qId+uqB2d%?~j
z*Xxb1JAL1kgFC+Ma_ke6VdvlBugydpgr%#PpZa#Qyl)=L99Hws8vAdbkbiF2M-Tk@
z-O-a{I&B!TvGZKS`B}P07VjRj{gv;Z_J4ThGa1JH-yLl=;q*OkJe;zv#?3EY9g+p!
z-eKu3=TG`(^u@LV<KOp-NX;*t(&MwzgKPY+w5{8_+tVj|)-OQ&!O~5f8o9As&1VA2
zuHJm#FN<P-dU8no+hvz>hop8IcW_O!kxfz0yHPnFzTv)Yktg4I{=YxQ{`<Z9=dUgO
zYVVh8=Y1C)ccH=DLzf#vqrT0DfDZv50zL$M2>1~2A>c#6hky?O9|ArEtP$|T;SeY1
z|6>k)dX{YRe?lr=)MsArzeeK!&pH2333FtR<JlB#t?;Rj&u#dOYm4!?h)<j6?1~E|
zBw&REBW4X}q$iJ;PHYw?f-^iZ0T1sG9L;92W11{3$L6>YPx8$&H<sqLPPo~!27ow^
zI}dru#)&lFXseLt@|yfgEwH0J<1}3or9;f$oM+5*8k5If^`4!OZOT#4VrM>!U8#(i
z$<BXt%f&R~Fcf7G*Fq3+NR;5vU%+8bEjbQ-kgg<9f`gP4u{hH2a0!}&q=ldEl6=wJ
zYlMSzQ*XjEWX3q>=u;tYg~A09T4Ed_B(6)t`9)R0(PVd$R0%w!Jdr;82xYHV8yCTb
za1SecW9$c^>}Be_;AI_nKSNf|Jyc<|^6`*_54!&Z;r^w<{qMrH8sdY;8@i{Ec3l-<
zFHFN`c_ux`H|shs#f&t>-cf<PvB~ub*{q(6<(N^2Uk%}BR*p8<lZMKwpd2|yOmxjP
zYAOfiSy~RlzMFu33dZ!%mIk{@c%)z-LE;Y*>ZHviJ(x>0LY#B5V+xxvr?gg+Lg0~z
z>%WOa+t~H^ngEm^6TVBwht>`_j&#G2t^mhB3h8KGEWPi8)=J3A72e5$-)YY9HGEHV
zEYl3R37J_5$yu40J#FOmnaV~V@trTFLiunRU2S|w+t0uTWaBwLv%S20SxM|QrMz57
zqO`GciS~`wbx2R)_Y~KYFbRU9vXK<BX^(XNV%x;-Wi_Q$K+|3w;&Y`5r+p|(BJR-}
z*VVIYTGm()@uafTJ5T8OFEy2Sz@X80VjlCU0mAk@K9t>W@VO5fr3rn6$4H||Y!Ue^
zW^vJtT%N~9NUyLlY{Ydx$i`;p;f*)R!liJ6xb{U1?nNsE(=`Z7;)T9LlgHA4R$W&d
zTh`9y@B0~o??k&zSmYz~CX{6|(igJ4la{z<2#bW?`Pn(NLIwU7H4!XmzCysDJ$@se
z$nHep`iX%Y1JvzN%&Wrp>b8yZqSUSs{*&0XEclD}&TfE<Vza$>k#O(4Ov~M!z4scM
zd!NJo@Ri^rao>sBJ8F&t@S%<7RuU{Uw~~CS{@9D>aX*F6{jxpJAe@(oJ(-Op$$7k8
z=jUyLVVB<TYe<gnw;OvpuM~Une!R`avpIZkd%sNKep$l(vW5HUk(Retyd9(ak^V_f
zv^5pd#o}+?u5jMz`nB<0C_c13jdauo(R+3vW8Ea|TVg*Mduo@aU{CqPV^YDc^EFTC
zI{2sSj1O&vNJrOs7W?Md&&HnGgXe_vci?YsW4Y};4n5zBuQt>7*zlN%&3)`4;B!Cr
zx8wU>*pu(u8~b+HKY%@P+aLQ>><3_<h5bP6$74ST`*qk4#{MJhhhV=A`(fDsi2Vrc
z|HM84`+5K@1$$aA*NFWC*gu8+0PInZ3Wj5!i9I-GbNr~S7=vSxH*Qnek~cakkCbm{
zs(^5AhCSI}V8YHz!{6LKqCVqqI*+Od^2aump@8b>1nddVr?L0PeiHT_u%Ci`SL_S$
z4`tO&#r{$3r(;ie%)mYy`<d8NKIw06>$nZ1`_Xk#ZniDK&-hALjQuR^-@<+#_HSdq
z5c_4=ufQH3_THpb*nfg!4BcS3uEl;2j@M)V4fY$b7x769<eH?qZ;Q`!NJr(IgZ*9D
zKQB3t+XikkY|nd1IB&ji-pklm;QU00#5d>hpE>7I>zqPQ&3Sb9TtRQ28>w~fp}Xfi
zYMrB~b<U&KIf`26Jo@G``sOnF<}&)`GJ1M0V;=;e^tH-MmToKD+UV_|*Y3M#MB=*-
zubTO7=hJyLj()uANc7cKd2lXk1W-En&3W|AW%RDOj9TXudTP$2*13XO*Szrdxskp(
zkFL#m)H+Ae-E$+g&Slg(H_|ufv3lk_YMsldb#A2AIg0L{8|j<#=$rHCoAc<K^XQxN
z=$rHCoAc<K^Ju$<pKs2iZ_cA{&ZBS6qi@b59`yP)9|ArE{xJynA*Ump9{+F1G38~;
zW&q&*@nhNebv6qCYqRQNn$$@A|2Ypp9J9OwV~=Q~F<CUO2*X|2`)FdZo`_^zXJ)!7
z-H?$!!H7|!qw!9{l!T1*Oe50L*gEW#HesA+R1;bgg>LgqTN<kv)g)dxF2pg7DHQV(
zSCe0c#<Njg>f%H1FiEt^i`BSKtK2xsi@kTmh~o;E3VCQG<blRe-Hj6Zi+RXSzza8W
zMkeEXNB5($iPycNaNR#JFi&rD-LaLt?%-ND0h=_x-{QJ~((8^RWmhi0s}-($8rNMH
zBIp7*7?MY)WMCj$WpMDLiffZ!x^AiDy4fQ~(=gUbU3Zwmb-%%NOC;AF=R|%ts$92B
zdR-yImBFEq1di=SR16v?*AV-es1N1Bb!q&t6bF?`#_E_jc6Jud&oSoWg_3+c_$K5%
z9{0gmKiwsET|Tx~95-$|wwJ~O(>XJQb8<s@y`_3X?@YvH?T!Z?Mg#A#Ny{`1dD4Y(
z%}|-fNwCsVrs+0inuELr;67BQdhEK6%S7i470#J1Imcd^Xslr@eONu>_E8U_a4GW`
zS3E8+pyTe?Q(0oMza9G?*pnUYiM@HuqHrCuZFC)~UIF;f)*I>QI(@Jwn@3|&={!9?
z-0txDP3J)-=CQc=-JFiw5#@BPCF!_bP)^rIl8)DN<#cT&>3F?WPIs3i9j}MV>Do!s
z@p`444tTNh_5}vKo^Y)ZE}+-^9+F_B!&f>;zF<1`ka58^>_L4&eE<k53aGwCU{5&H
z^|(fruh$Xj=z5*7r|aE~Jzeh}?CE;<Vo%rWf_(+PuLlwM#*F?m$BcSvEU34S-E{Yu
zOs!)rwT_|mz30LAo(JE19(?b4_@}(*VJaJI`Q41Rekblacz)`?=D%^r%iq6r*KI|U
zi@)vh_wai@9e>;0nQ$n4V<Ww5Y^0~gJZc@2>Fr|~wT|8Njd^r!%%i)<GHM;8=zHHn
z^}KJvH&)R1euV$U_ape;XW)CEf$x0=zV{jU-e+L{{k*=heZH}MzOjA2v3<U=eRv?}
z+k6Q45bz=3L%@fC4*?$nJ_LLS_z?I<BY<J5x+k0-|F5+Ee<qD3&r0F10Qi4B_Fo*6
zUW74=v`NQ~(^&UxHdeJpLITEk3!rEki!F|I<>&M3+OD(N6k{Z5tm{qK)7bi(g)x)9
zbvAduvhCPEbIhb~oy`^dro6c)@6`8ud)<47?(XMan(=)U28Hj$IADD($M3kT(~{DC
zz2euT(H}QSdv(G7E8jgi{Bp(SKb|jJ{QZ&RQ^zjuyT|wz#+kEp$)De~qW#&L{~lQ5
zwKp$(*lW$c>AO--2jtg0ao_OGPfa+C3g%m9)9;P<8@4E@_-gXgJF*YX?s#Issg=KD
zKFJ+~^U>nj`@R_QSJt<GU%4I<+jsj;!;P=r7`1Ig-ID0D{SwD4z?=z|?!G_28a(~}
z2WD@%?^yfcWyj+__}S2VY2c&tV}=I(vSHOzv+yoamacc*Wo6qdS~XvB!!7qu@7`i@
zQTwO=Gq%_5?ek}R;&<OK4==+z*jc)dMy{Ul(DZ>LpZxsJH)lQBeD2oh$5O&NM;XVx
zy7SE7v$vkWy4RS5rLWcIgF5S$)=zr5{oP+4y%H8P;Fcwg4*$1dLW|eN+}-7R{QJ;V
zG)s5yz3m4+d96=C*!ed4HovVsG-KI~^}9c_=9fvE)_!?X-}yt>ah7gsy=&d;znWNM
zK=_{ZzI8Tz>umbg+4S@}o1b>0dOrGXzb6K7k83`seSU+t5A4ba9<Zz9>V=DwPQTV@
zQLS%(!eo;gnDF9TXS2uC9cSLMIOp8MFF*Xtv+ENu!KN4!ko2|s#P#jnb4Xc>l)2-6
z{pS3*|1R628?<f0t)Jw4(`Lr&59MO<{sSysy)BD64m)xEhcBBw+SI$ol4>2(>8UZN
zTE}Yo*4fPcxqa3jA3b%?M|JOeVtrQIMh}Gi^{P%+(SdaO>2EKN{4H}*@zEbH414(H
zS^0<i^myZ)18+8dru(wDUzmDlj!xGa6U_9r?tFjgtd#A|Uz|T?;)`$1Z2XGp%jg!<
zyZ(?BR<ZJWYGCkWyn}+J`*Gu?r5l%TxM9HA$D?|jpEo`+W9$b9hW;KGc<PHo#jTcL
z0^wAaZbeL&B~6d5Y`F5k_LSdrm!EDF(R}lT4{oggOn70=?H}*Pq`NgN-B&GU8{h8n
zN>O0I*PC1$bLv}XbLZM8vT7BcUE8eT%dbxxQ*`&jn03&>W0)|gueD`a-8}>Djjh==
zH14DOzdA7c-00&=r`&gA!s_&X`nF?QoW;91Sh^QXzYKmhasJzd{nPWV25fjRvd_R+
zW5uL)sfP#cI@x>ENu6#vOV_Z^TH~CPWjnvUFlcV->RYDVvo$%YZvI#ESFUarWlS5q
zQKvh|(hWD1evsS0e0t}=I(>D=OK<PqbnoJT9q(<ayW!NYA9i{v5PoN8%3rG!yYBq+
zy(7C<PBbR?*4aFF1K#C>37+~|55Cu7;l{ha9`xI#%Xvo+wiw?1@`NQ({o@aZ3@n@0
z@1f@~$=A2erf;21-#VMVbvAwLZ2H#O^sTe$TW8a^&L;Uy?Th*s)sHkSYPxjKG2d8R
z-&kDVSX|#&TzcB<p3Rl#|E3&6rfl)Q(FRkRF(*e@`tSec^ZypQMopF?Cb}Jc+giH3
zTw_jxP-<E~DXz&>yi|0A@NVDZ!q@<WuynQYLAXda2j|iYTiLpR$vLKkR70*QA;p-C
zQ4`|pjbqX?P5KTPH-N7*I(6)jV9ZZ8W}DKpGWDH0BJOQ(jkNW+y!c+|XK}A=9Mc+l
zVxA_}#247GECS0Dy5}rUrC7+xI!{In=BU~{4H0m<B;={SkSAKdYZ>yMD9ux@$zU=9
z>rBH)<7i{1DLR^#LQBre$-x2M?M%O>XQmkQ?cu}Ur%rf??@2GGMZ~b-R_xuYLD(<B
zy^HMMJ0;JMA>4FiMplv`!#-!x(dp*ZA9?<0EiCzFdEYy&FZTlSVM<HSrF7!Di^OTB
zaU8u(I?u?yuhoRsMLdOakiK4L`L?`^o8tWGCd+%L#|oGiQ{~47x#|daj3LpzhP2sk
zF1MIZ(yVYx+)27w%6!G9%*2!UZg{`i{2UCc!M9i&44==MV9i5uoDF-QIlYD5x=yO!
zm%lTc?jf$7No(BEb_+iAC&t&Hwqw0Ut9w|Ow7HetdP(^e-$~vH<AZqZN=eAf%gDe_
ztd5HBMUSBZV(W(w>EuCt_8}ksA~*a!@tI?@Mj4gzKx2^<Hnz^8n1|Wmnhcl4w($HB
z2c$8)`5Ov1n>M!Q=paE`^gH1uzSn+*kYBQM^d}y<=@vs!1tM;_Mia3jUd<6FR`x5E
z-|HN%i7=~RJ9Rp`S2i?H)tBx^+eN(3ns~c}eLL*0VK1J??Hjjyw&&HX$<M2WJ=w$h
z*o)_J8^r4fi9&k61Qe0(mx4XnEM%3P7mL5S{or<m&ZBgp_|Uc-=^A3c0{iyZufm?}
z@jKX){aKB@cz<3Wc|Eng|MN&kb$2fIRDWNPoX6`0Tc=O9R$^<UBc9q|AB_E7lJmIM
zc^#lN0j1@|&>2=<tjoyWM~)#GET2Ph4X#bDSvn8@baD951}+NdxFhy@?D1HZ@q^HM
z0sdxd0CvS*cVl_M{lYP6p4J2uao}3wyxZpMHl(BSz?Kz|7U+H671;aM5d7zkhx4r=
zs5~ysw}zl^+}BH`u$g*_4_!8mFRI^iPG<l88^7Mzcu)T|-{d`TOL*PhZ!G@lV#}1%
z*Rf_VOLykmk8&@+*Q0#Tq3)Z{o!C8k$HmDVcHY{0(SiDxJ|24Io$uiDvUEe|J$}R1
zm7|Mp8};4hk@MqT{%i8wk^j2w*EbGa&fj@8%s1}KH}1>R<GyO3fp_P4E?Rh6U+ds1
zzjnLgdw-o?KeJEmWs}B~{$26T=4EkRr@Yi=#G0f}C;8S8^tN$do*K`kb-bBx4ME>{
zu2W4hE(jeQeXWEc*_Y~Nhy9UPGQR$_*x$R9{MNZ7(eT~0>*H2-2@jsQ5b+F_ZdGOr
z{Vktv?_NIo`VTMM^mgrK_2$3u-_`S`e%y9c+o>JzUxN34uyh^!yg0P!guJ!S>}{NO
zHD<^0%T058mz`KSZr%z*+s{58^eOsDY}}G@XKDJi(6HvqPt{rI8&~x_I=s1^iI0_E
z*V{Uy?whap_XzlQ%`bs-_5C0CrtRIkI_<sT#?}!tx+dv#THj0TTSL&dhM;c^LEpF~
z-?$~;xFz4XCEvIu-?%06uYBW{{J&WK;LKwO76kfLB>KiJ`Nl2z#x3E2oNx0X;6uQN
zfDZv50zL$M2>1~2A>c#6V+i=+&hB0RFDuWKooDjq@&8SA0ZlNn9s}=3C*_)Q(lbZW
z*lO{+ToYC`OyH%^=^Ehs$1tWmYg{hIzXmkvla-g5VxV#OG|n}kNspcn+D&7*7w%-r
z$|s`5IRdFQ{4t_er&~$`EU{s%BO8a^0sBFCb{BsVqw#fEKajF2%~o`DY8H*8r4iui
zJU0nRhFoJza+)Ehvr>B8+-Mjrlq$iHV#qcbb6E0j`fhH%Tufy%kerp7YtpytoR^uK
zJ~GpoqEEmmep7g;Ui^WIB^-1zf64EXY)DQsrX*yWQWDa#*i~3!b23boU}LgL=km>Z
z+<7nt;)-MK#WB(b3|x&d<c!Rt`3AWOfpk6ktr7OKFlbitTafr0hIZ>VTAvpz{zhYT
z4`BR?<h&5^H;i4?y>ES9DE&s`te+CJvX2H4V;h4Hjr$#i&!f;v@d;I}WM}23lVCBH
zJKK<B7;OaguF1vSSM)N)sE<vz*30`|td~awy_~8Gfne*659tL%opkZgOR2hT!8{t6
zxSSN%G~$k{{6lq-jymkEc4Vxeiw+GS1Z>haXE1c3SJ#C~n=_6KZi1;2&5m$}y_Uz7
zi&jE4=A4KvjcOAlq;$F!(rQyiDcF>g)@_33HmE(WC240|Zi6NZ+R32C51X_N8cN!6
zrVVn1>F8+nmdKUsdZmK2`!P4dfwZ+h-l8GV=Uv#CYe?EIJpv6CsM{aw7R42Qqodt-
zt$(;y&MCB2-lmo9<WOUiwpCwZ3}o?^nr`eLp&RJV{*n6S)D)w7hQr3Gn)*k-E7+Bh
z_)gNsXl|RTs()00@wT){+on~}iVhR;Rr=EEZ3yA2=GUmQh3>Swujplp(dx@w@M67)
z{i8-S(Honz9a;{(l&b5+y6tdQBks7$KU5c4UaSkTf7BNfifNO!IbT5+*_Cc{95^Zp
zc0@SCh5nJ<i&jE4=A1Zef`pV+-am@O1ae#7cD<8rP*wGh=3w$UZPGSq4YX5m%!xM0
zHTkHwM6O)dD;1=@e{{bWYe?)LZNfWGXp^=}D@j9I+a*`{tz`e`pJ#2fYvp5ww#r-V
z&0gJ&O-Lh!Sd4?V8Tf?Zla0?}Xr*YXw0~qwOBk7lur8jKU|AQoSP@*+tZZYB!IYKL
zp<_%;hGBG4iXkB=B_$+0B0M-eEF>u@EIBzcB*>7G92lG&78Vr|7M9$tvzRg}H7PJ6
zB{(u7#267C85$UxVoVJ;Mi`SrQbUqbf+D-&p^lg~Bq%r~BqTH>$zTjkPELx5j0y@0
zHy9#=Lycjn;lY7u?T~HutVU0N2pe_%>g}n4XCR4eostH+=q9CDpXOG4-&j|>$yHWH
zT|iv_NL^DLUojsC1=1xbjpe&=c3fdj6T!~090vu7=UBcALz;$7%5cwDfvMQ`(0BEa
z_&=~Ew6qOjPTx^z>~6%}49WZ%A$><>SdVnc8Ad}UQqp%va6J>g&oSoaW#A8b#v}4M
z^iKSMP0HsI+`D+1Q+x)8N2Z2H1*IfKBpD(j!-K;j!jqFjgN%mcl*p8j)D#P!;3z37
zGAY~`6_OeO0t2JMjj72gbXpYnjgaygm>dzDYzzyG3X2MfN(l`N2~3F!PY#PriA+vS
zjZ6u(!)FIOeBLmf%4p%Uk@?udr{z1&r=K|u=hJd*;nVV+eLlZa;4?*m&tsL~vjY~}
zvE_3a_$;029G?-9;ZdPM$&o=J!9k&h$mHZOLtwHoG|CVj6cuO;weT5~5*`u~77-Sd
z8W9#6f|nl{qf$dqk)w=Jkr9S4gOtzYNMmGRSYT+NF(N3)5ET*;5*Z#55*(Nmn4B6G
z5s131T0aZz@Y!{iHJ>r&V+)^_?>L{K<}{p7%dv$|%Xjwq90Z(g>t{XKbldvb6X~?p
z&r6s?YRl*AIKQC4DL%u4L!*KW!9jue&yZxG%4vu|g$<2Ljtor=O11DA862J*9FdxA
zjED#hj|z+o3kpk0N{)y!gawC(M}-GT`3yCNhbASZgoP%B1sWn?rvr^4MnhyuL{wNv
zL|9U|9X^kjs@vPstc;fWdCGij;nVUR=ktg;4d>HxY~j=LoqawRDb&x85W}?Pb9N=_
z=MFrNx8?Iq@VSoJ6><E9=JqopGC3(KG$kYg|EH!#L>WVa4dEe4$$^H@WYnr83!ka@
zE+i!=IXEdiIV2@2I3+kRBrJtYbC4k{H91(yXL4Y2QgBd^5ov?M!%~wXBEpS<AxWWz
zu%KjPc&fejv#*`{*=mM${cLGIw(x2Bj`Ml5ISuF2a%|z#@|}G?8!FV##R~TJ?@I8w
z5PGoX^KIOxgyp-^d`6`hsG$o9ONQkP4G)e2XOZx5!cu~hlTw2tEqo?Nrlce#N2M48
zgCoOI!$MP%g2Pf%QUX&_jp0$L*7XyvlrcCWA|e@Wb4UoBt%#t=sFbjzu+-r2(A1<<
zJM}Zo4xjh1HpNmuJDZO!d|JNad<K})a6T=^7CtTC+2`{P1wP+Z;Ij+TIkLC^g6~!m
zSC9OGgal(+8iplg7;^%;cMnKNV9Ot3fx=N37{!J*;Ya4z#tsoZPKT{uEVjpc^c~pa
z(S-D@q`cJF*noh6Jt}qn6Qr|D!4Kbrc7?Xl_@KzT$MK0lIRhUS`u(bzmiXR|T5Pn!
z6o1v@+T!MiKR8bQ1?%xQ`N)R^A6fKMr(z*Xj+Dhuttn{-hv@1x>4&`9K{h%%At56;
zI$Ffnp~pb^qw9{S+;xK;`8RZ3@|Q^;WzOrvp||TmA6m}0(#L+_K$}z_rLb%M`-OFP
z9qYs4J;_T`(g(+>a{3q{skg-A&&X>f^x?4IL0Hgr&sFZa4tpMST~QypeoosDhu)S0
zeP}t~N*|Z7E(vW?earwhC9i1Khr@fS>4W1`Ien~^_+7-~E0yEXp@&LX&~=wr?z#^B
zX}Yec554pHa2Wk?pbstQTj`@2Ef9-Ms*lycCi^4J`fzwpHGOcLDyNUTZ0yID%JB$W
zXFp;@Sdcz;SMItF<6CrHQ6I6+>%*Zp=s+J@&bQJ>B#T~I>!TUkoN~Qp|HI)u)%3w}
zs+>Mn*yy8U<@^MPez~ZR=t^GKk!LQ|N22rkaM=5EpbstQTj^tH2<6;b9~G!Ox(k}^
zhr@fS>4W1`Iejd!(MRpd@#wI}OjwZpxV3WEb=beB>yrHt*K*${;7)7F*T#o}_ASuX
z2VyX`c}xmsJQ#DRLxcD{Iy5OU8CjVlyD?u5$(1(d>x=&VWCWQ_n5SSAV#yB)Yy8g%
z<)_kffjan*iP(km7M$WX!IYe9%F3Ym7RDUR5a2UN*m$B&`c9qMa2}Qi>SM?^J|13N
ztDWXGU?PS&4qlFeqR)ZHL;PI?6bGNxme#%JX>P`GO?*jHSLoV=S$`qleJR7(r1}0H
z`Of}bIp5;rE@7`1bMI)Zidx>gAz!w6pY9;<v(X<ZP_zfhS))g1WhRVG%?28#)Yu`)
zW2s~1GiPFBd$CSx!o!ko>cF18dh{5gH~}U$c3_WQu}@$fdj4!^A=c}s?P+wPQJr)n
zv2P8(tzZDto=wISAM7gUwKIu?>ob;aAZ(-)j)A4FZ?@@+#zPlb>|G|gOe>@d+x{tO
zgY?61&h<m{W273xTJ*YbR4T|mBR$uIIb8Lc3`HTcbFz|+xw%;wl|DWj%6bUjr{jB@
z!rJy{9rmqoJKUpIll>4Sy%XRW94}`$@^^Eb5}xTK^v=)Dp}AT3oir_;Gau*7z<2k?
z6ZZTZ@i~y~IdtA!=&9K4dP;aqNl*!oIZ~8P_mrTi@+f2;n^aRJ6muKss-}e6EA(Mw
z=_bNPy5d;4t}CkBmDSaYD!O{hv927pnN&p5NaskMZWFL2UA1ReI@T4Pa|-8>uHKcL
z<49K}+H|Ele#DKY%B-utF@%J*u9&TQM6<3`^DCGu)|SPxyYT-=R~!r1byZn=MRsX}
zWBoYv$*Ck{`>rTxlyo&C8ZjndOS)Rluym{|I;R)TVfJc}HhVRX;&D}>E9Xs?IX1h3
zJ-xKn7PDD{-JmUt*;3RO$HaAgRn~5izHUH_*Fn4IFitM&t3R$~+qROv%Ak{M;LGe5
z!_%?8=$xfEhuJO3Iri+<H0Vp$Un!nvQ^MFGR-<d(X{$yEZQ$`(Ld9B7%vQx|){|8p
z?b#<@X4myoS^GpbWhL5mTh2*WTk*XO>bCxr!&oHYNBW_D(7IT`J~8|p>xa%cf^(RC
z>Zi><&4PaP?$VD7HYrKaP$0eN2%F50>hGk69M~aVcGq=OSvy2JYNgONk&XiKy#pON
zj9C(fq$5)gy!Wf8V22onj&(%mbOsO14oS|jXNS58{O#yXcg8!e{P?@B`eJ_+Hqt-Y
zioe`U-s?-q<qIybHX@CmYWu%cpI)h-MExB+s!TQJ@O22NpQM97%fCxV#_|*<`ikBa
zNc|=HZL}fZ`~$@cTH<S4TcF2x(!Nyyj-`DoI`4|jm^H#Y6xe0-(&?T@`ev-${N5FI
z`a*P0G0u4j=WLanW3T^2=QIP}1?V^pP2u(Z4&-Se?sJa%<vBT-SqPjUnvo;CM3ZS^
zDeiMK&U*;=+9NsdIL^z%cZ7{CcGUM0`)zdJ!8jkym99>z<-Rl?(BAnXHibC%Ih-3O
zoJ+jybAZiuA-@+S_oFe7_U=dd?J4Lor7v!X?J+;D%R$&5hb|LGs_D{VI4EA?tTwxw
zb?BNlZS9L5WpPHEJAq@p2e>xVSlJzGlg^33Ii$_T07C4i+tVhUvk~XaMB){~Ia;(C
zi*wfDgC<YcI^Cizt=gpfmg9VKZHGT)IbVx5>D++6T${^;a~)}u&Pl{Ml-~iPEcer*
zO)(x7Nfi;>wOaiBg7ogy_zw6y$KrZoQ;^F|rgQPA66jrFo4Ouf(%1;HW4EG)i?LHz
z>?~b_?5wRlB^xW%tRBZwdrEEMgidnbimq35`TF%IfC(nun2h-p*J{{gDZaBxkLyv|
zVth|ARB;?J*_||SL<Vmec1DIP*L@+<QsZD7YZA{1#X0Zb_Xcx_3w}<4$~k0j#CVWD
z2?E=V!2K5NYheF6ar%O*oLbu@ckrs!Mv1)I+9EByzG8>hWeU7nr3Zd$yvBf^{SOPg
zGHf05O6N2JKaAI+%JF&}el=~jb+v@m{Tf>8s-}2MvxfXWHvfBFeGS92GTXioaTR%9
zUSH$zomF}ij?(tU_qO%*X7IBPSW|udmSM|z4MbYC`by^<!8ye1gbZ$r$xd`oIfv@2
zI8JRlV%D_T*4L6Ox{iyyTB<DbbKSvhb=28ucDS{zv&5}cdSI!>?J00H2Y54X8NQCW
zrE^Mf4&ydk8@FOyq6jfy+HC7=!K0eFRgFuy!~SaRzYw0zwyUqg#wyiQwRY7iJ+PyD
zE48aTz{ybHOI*Ip@N{f{>6|$@hq#O$V&T$WyDG*95)pT$&9<HvJnkfyHg(e-d{#%@
zJYt7W+qy}9l2v-(r^e@e@X`SoGd>xnj`^f>hT$B>Cq`Fj@sq@OK^ine+s8F|zw86-
z$@eW9uEeJ~T)^xo9`h(|Zi^Q<Ti@tB@~3Uvv=m@8V=(V~Eo9~6*xHK=&^eoM&Pyn1
z+YuIQ?e)FroC=&n{qy<>{2c0gIqE}^&r9ca04IewcYts%wV{XX^v~&>6r2OMO81xK
ze)}uYKQ}#wld+WuI@pXo^OqA<bYN3&oz+5B*HtwwWB{)s*uLjc=Ao>Nj<rDNY{xmI
zh2JFS*wX@?qXV|oAO6ZvIW5q+p*WYca8r^+d-k+I=Vap?xMI33!a1ZpEn0X&80S)N
zC{D%}icfuf0`d6`{RiFOtnVZr5F#$tYNA=!JaQEs&BA^{bW!`<<|DX|IG>gL!x2KB
ziiJFd3wa6_@>CvIi~Pe%<w+u4X2+Df=GN<K+U85dDik)FwlI7Ms~~)iq71Q>!V2r<
z8q82>&Qnx7YpldP?NG>5_T8x4xzf3Sk|l)|`D1x9L*;19l334d^OPy@SH?#D>2xQ7
zPeXi;;PVS`^8c$cnlfhQ<{^|S1V__z6Oz(LCKxlb@<ygf;@Hh_ZTV*5^AhZ$G@q3B
zdUOI}7GkiP#$YwVS7N+`Y%tkx+t@X&yG!i{eV=0-lb4=@v2wZT6O1^Q&MC)lPhj1I
zOyf8q+kE^@j)2RRC+Wr*FM$u?augrJMZd2yT-n3LOd;?4;QI2-yRg|RU=xEjnzlqZ
zG=$9)*f;77ni{FrdDXr>lZV>6S@xEpMzAXf6FC#a^_CM-bFxNbAXNel?}`x?hZYuG
zVk<=R@n?F<xNNh=S-MuQsKGSUQ)%2xH%zCC1P)7atw>gGi>^%g&NgmFHdDlJBK#HF
zr1;Io^$QNFYRftN6c*cHBk^b%?<&Mkx|Ww3ezCwVA2<+xD_FT5<M+9szwPj)XiF0G
zHw^n*p}%#1JAt224J#o*vEn+3qI}L3FAe=~twZVBoN7200K*dCK{)Pb<=2j5BLly)
z6vtPf!}1;O$5BCw)rO;V4IececL2kBz=LpX_FpQ$V;t8DdTa!Ljy6b;`5I{cbr*r7
zK0wtTTE$JO+XnhkW@Vd2d(=mhu1l?i8QC*)`IGs@q~(7K<zM%ws*bdmUqLvo+AuBU
zm##afR{oC#{%=l^m;VaNU)oY5{~oeIT5yoA`RWLVmgHPvlj<M`IK-aPr~?N$C`iFA
zHbe^!(zTt`aQIZvLt-k&LE65Pf0TWLsvewc-<|i5%xjlhdq~>bCM`aa9(ouCES3U}
zg{<t3ZK{aj(vflu$ww+Xq^c$7FjNqgM*HG2hFbij6yR43EC|DTKWb~2L_g_N8plxD
zzLTG%zv2Xj4(g_Y6t&k)6(nuvrt{L!|CY9j`ixrqq!qyMIPf4G`?B&o)}n}G=u`a8
zQXI)oO8nCOI4a1o+Hln3CzS)kK;S_*7P9g?#_<EeE=G>xI7-_G@{{5{>nEwGPkU@k
zi?1YN5R)OtfPAGg&-zL(V^A4?sn=*Z2IMd4TB){=*8ZZ0Y>^+&w$1+*TSR_yW&EYM
zOgRqZFJ*g!zoeoFt?@=J{*vfF7vfnrZ6na>YKZ+%?8#p$ZLF#X=h}LOMoME_pPQDI
zL$9q7B1!J`lj5O+8Nh&S>LpfY$2L{OZabd&(<a4^{G`~QoM@W_XHfnMIX=5p^_2$>
zVoA<or^P>-1Kdi00b!TM%Ip|BF%IX4anZC%{dDq=imp0=T~*p78}+%<FWN!+0S<)U
zCRT3k`1Q&q^sMnCzo_&p_v7c1U*sfyTKu7Uz%CXzu)532?HIpz1%D`(0>#+ySb@cj
z0<b54sKB%SkPTYy^@GH+$K+ATt;<e+kbi}$cC3AXYP3~;JgYYUTetgK{2wu17BiM#
zO3FL=KY`xh|JbmvwY}Hk_n6B+PF{ZUdy2im?{TvHTKpZc-I<ur%m29G?+n7e4%!|6
z398z!Zhyz@{c$*$m&Be^>Uq{}{<qWx>W?eMh7!TA^!ZsVG>{J*$Zkfmayz!0B7U34
z^V>`Dn}+Kr=D8U^g+@oCzvvQvN`8+meg(j86L28>3R$@w<0sa?%@a6&ZLy=V5qIKq
z9{80$t%{#^+v~iKt%{iz`>WIkmtrP;Ua|RUdHIu2e*HK%l)nlzqow>x?T>Bw#n`HD
z5--2h@1_1$pugAjw`{av>3C`NeU)sG?KAum=-|pkUWbOVvOBIrB8I&t%Q2*WSMgz0
z4LN7S-KM9?W2j_@Y%%nMmSTYg*`Xb*?2a+~Qt*F^rf>|UaaHPnm0xoL!>a6msj5+X
z96(Eqx-W2?1560ZX4eS=?N}ZvkYh=GvA|vK$5KI(PQ<8f94%yDYu(n;FPje>_X88c
zawx;VF_vPCwrncL5>m8!p1;ns{W4V*YW2~T+DK`ArZ!T<;K(#N2Gl=`^=$vlWek+s
zNm~p=KeK$g90Tg7C3-_YO%)04{dFyUHW7;}GvruMpRLpz`fP5%LQDTmtQ(=TI2OZ&
z{@Y{NlmArI#B2N~#HlUOYOQuvi_fH+i8cl0C%d|dl~=o6&3HzR8~IGSpPgu<swV#9
z6mDAlq)1?vhVm0`9awoC<0jU<)rB0l1VL}q?<GGeQRjr-s?txgLQi{puEjUX26iie
z1L0T5%B>y0Q_srrBj2caw-dT^fS*ggk(2mo@rTv{yW_xt@Y})4?HIpRf}eh5Hpj0c
zb`&qT3m=M8mwDD7vO>$9K9E@ML(j>}O+HYzXMG^2%B{uk5#vLL=E%!Ueov7%_&rvo
zcdxHwE<a5^!zR@``8vAOs`kP<K32^(!jI+F_CHHZmc}J$@o&V~hW-V9E$K65@^8wU
zI?>+PYp2~1E3}b==02nrU#AQ@XbCLHW;VNt%I?@^iWsI8$uT5fC-E0m4S6g+<Sd3-
z{GI^dmk2CayUoh(7(;Q~-Rc)PhSE4C`8_2yoY0|zI;kK<;S9W7%h7BZbN|B{Nv(dj
z7XK#=7_I;wgyV5me(g9`%#-6t{*SKI2`xIn(Ix-KMI1HxLBOyaco2>qSos~}DE9j<
z(F9{`(&x712l=;E)uVO0-~n6c$FpqnzjfPCnYhrE`TSB+49F)c_N-5&q8#o1ffoNr
z9CPLOiW~#-k4n73KT<(LtADH|CM4p}Xn`CD@{<C+!B27#2QB`Rh(q6n90%$1=o7#p
zwwDw3wQ6hxT@~->;Ja?fuGY3m$xrIi&iYxtKXlLw7?4d(V`X-1Q$_4%yeh{o0N5qo
z;AZR;8YV(RL+kD|c1r${Ep~ChtpFGhc7?3Wj<FNtLfc>C*gYx4g&xJeoOBoJ1a=PE
zb(j1j8w9m#PsuN`#jg<9l>i5(Jyve*`1vi8<M%M|E4ZS%_JO*O?f^dp`Dynroy1Sc
zAF{=72Wbd65PmCIxgFytj^WcS=J-j+k$eOEbi-BkR~`P44O-fL03|<2iWfZ}6U%-@
zq3mUFii+F0q3jA`p+Y%ptNb`kHve1ufJ*+4ZP~^6$dxzby#D~+O9yH!yMwyoZd;?J
z{7Qb0YWbJQ%YOmfXW#Cg@+;8qlC98EekFg$w){yo{hLt9SHC4Me;N1>^lZIPR9b8(
zE6<djXG$<H@#oZBd&R{elwWn_)b;hOX44C(@LK9zW5N^dqoWgp@t+|xH=SNu4Mo6v
z`~O}*(J$4aS0!8h6ErA}F(q4_Bj~kw8P}`SKR=GN#l2PQt9m<6hFDP#ph>}SX|&tb
zOs%_%M<FtAldmVr=-L`XM<x2DH3!$h&Mty>mqNZfm{uM8W~qYa2d|LZ=(>oVW@}xO
z!l!d;Hw-C;Y`pD~S#=m`pU!zx#C7hhotEmH>~w!Yv*oMgn%zr&MUJYSu8#ghHQQ!)
z6v-QPT3zLGO`D|>8%)|1ecs|Va&3+yAL3y*#Qqf={%Z3Z)b6e5<2d2-s$IX@jHy}%
zyrY1X@p+Z{=y^7J6@A|M>$qN}KJQ&f8+)UwEp^UeQiIp=Q&ZRNs@lC3sdabps>#NB
zeHpd;yh`!#))M`a&$|?Mwg}oKpEr$ZRlCpIcZ1wUPsjDkepl7J_C`sK2cOQ}6Pi%N
z*K6vscE3W&PD^zz^?8rHFW2mkh$WVKHjZ4)w%Hxk&>QV>b(PCCZ61W)q;a#!LVs-C
zCb>3`z@F+J(P&SrGS06}q0Z+((e9}Dzs}#qtzNM6+3=>qYS*&TGn-!|{sh_Cd4iU=
zf5NpaeOCSl(iVrQYFXW3bRKATc?-_xK#}UIDXJSS^8cIiiv2x3m!r-9mS?hR>sp?c
z=$riIjj+)r&^C(^Gc7yzmuCreV&PVPd+GE0CWsLiH`Ex@aGn)kJ#g;fp7V%%S-ltQ
zftDDulAV{<1G4j(f~E&=lWY0_>dd;4s&?MmNpl`yFV(dBis!xdyn4&%s&>DZ*l^OW
z=x^({%eDJ7(&~G-#~v$mu?4kj7+K^Nf7?zD6z!99{<fXFRHwgfCmY^WSnd9{(ioxf
zHd+?_?a(i{mZkpoLr7bE&CAACdPLVw``dOj<;~LeTzN%Xt><#I`QO^#RvItcSE6t7
zw*z3K1EFo^Z!;}x_qXeP$!{<9w_n8d{ng+5RH=r|t~eacVe{1kQ*^X!w4eiT&<^5?
zCf@V)K#RYvWap*zK<aOA-znGhpNJ<Gd&5{*k7(L`Rkr&4?aJ!7ddn!<aA&o9)+W9!
z&OOrY=Gv7$BR>Uutcy_XE2>xEsu?dgHY+^^BY*i$#6i!qZS%i%Tc$K`Yfo!SoS)jV
z9jLokcJa2X11q!RwoJq>=4*a?DR%9FonGf=>=dM_acqp!*eN}yw#Cj5+KB`P<OlR+
zWp<36IB#oWDaTIg8~;hVYwrYh4q7OMA<5eNd^QNWGH=TkzgS?G4;%=;4y@eT@!Pyd
zj$eP^mw4LC`W8;&r{ss);#UCdHUS61uaK47F@ECQrA>P|eo{a5JKz_n^|@X(+Bz*Z
zUuiCY6fg2u#IkSvMqc(aXdg<o`YZOz?q*x1rR+*$4Q$IU&fD6!PhR#P$?iO$YIiEt
z(7W5#Xeqx^Y*@AY-^$DX7x}9G?kT?l{Vv&BE#+78)osf!u1Rz0J6`^2m?zv2e@?{y
zB=}#~Q?>ln?e8Sq|H$BkUIQNO8P~hB<Zm9Misae1`QNeMb4=p@k>9fkI;a2^OL3+B
ztn7|$r-)(9etvr?hHZgiX+t+-s30bdevbq<=P*?Ae{3<l0{kL@1z~uJmEAFh;=0d;
z2RMc^1RYMs{w(P**a-})(*IFKlFupDqQ@IM=yayEbi5%(rxV{BYKvtoaGU{5m>wAh
z+OgdCgB;5^U|I0Dm-#|&z*5OCvc+-^a4ZETgyjl`fnzMi^?mjq<XHB^t|2}#`0OKH
z4pY^ob^B<~H&AFC-BF)!=2^D+-(nNh-sLRCjr=1KgF}b-rKA{~fc=d3?07^~^-!Ng
z3kFJlk}U>e|LpjWatsbqo$`kH?W#y{o1_H`C7($Ri;AD*SX_i2^jiI82liQ^nbYnw
zxd96$|H&2$G3F6i#<8$n7cu^3)#tO-?mzK26e9SHrRc&#x!<Jc*|z!LVk6Yv*&|&S
zo&2Ut&_d@jZd>zNnH}3!5xb0^`R%3H(Rzp_zpC0+=de={lvX?IEOtu%k}Y<jz%30J
zP`h-TmDw?NqR+YR7ml6nI*9sOPUy}-eN<?sDp4P85!AlUl#-uhi(xkKTMaA-!@jKS
z+A*y7RgNL8fta|*3H>?1P(gy#f}xUsWQ*ZO;8zYT2*W~FcE=csv6J#697DLYY#rz}
z*wgxlv7TN3P_T8@HqVb|)#iVT%~SJ>q<Bf=MyGz`my(v9);%os?7D|emtDypvMsyl
z6P6#9mz~x-Ecb@>4rK^vU++oD4^qRR;+Px*TI(>;8`e5>0Rtuf#})%|J>HlT90O?^
zPU}LiyTyrisA~F3=2agRAaQBULn$WA7lIxlfd|>q{jB_s?Wl<3jFWO4$rsZ9=0sa$
z4@ZTDNTV<0796$sMX|uJ0C*6NeOdV(<0!_FN`L1#+WJKWeopAoL7VQ9Ut|YOSDvZa
zYO)YG?gS=;<qC#@b}U<-mSai&QORB>H0c0K1zBqMkKBNz7C&hpaBK!l2+QLP1IJj3
zeVu?a980OMKz>rTXZ<8Q$Z2mgm7cXpbx1ywh(qT;<T#Meq&u&wDedtz1rfQ+w)ydF
z+x&0sJ8JQt#CTF<xf}=bpY(UA+9_)s9Mq?(v`t#D(BemlSoAt8$AbK*B5&}c?9>pl
z(^|05;!lb7qu?CJ;t4$eXox=tV_%#6seIM?;ap5aK_D9Iil{u%KD*>Y4F}KSJY({q
z`a%m6fdSdr{jAK|ZS3Yh<=9Qd^>rpUW9Ph`aT+@%zsVN68Nh85Fd*zYurfQwPK+n%
z&U5UB3A!7Cy+3ppum1jHb=`@jR9bvfc}YZ3OOEGDiPsj-K(<}+muxXC0e)91IEMMG
z?AkHxbwQ3{5%ias<Anaia;jjcAVCq4D#cLAPqM|(4_b-^7No;MR(8i2it(h_iyT8N
zC(q(Zdh9EJVe!+d7+SZB_WC|<ws~4?zmjhx#Y-Abin$~&djiT{KGqFoR}hRV_FhZb
zmHZ*wvWxMg*uUgu{~Kk`*2=qs`l3L+%k@PI21<UA8V0@omSd0w3`(@}?*Ib@2~-OP
zO8$>62LBS?E7;*O$Dk2*wee|yPeZgriRx>Vs<%VV+JccrtPX9+F^o21ozDbX#Fj7i
ziM&u-gPp?0`vSM>8aAniU$Y^OgakHMF@q9QJr~Q^=n6kwTE=I<bE*28RL+%AfpBx3
zuc9)F?@6psDB~^Qu}FO#0rfIE(6xiQty)r7xD?BI=&GE{m%(M(52`lX>2fO2DXqU%
zQqE~L`1<aPuFK0=AAA;jxL#_T&f|<BsN`fVXKtZodL|}#Xw~T&=+4&Wi2Mz!0f!!&
z)aJ}YdVlqIb*t;tURf1HYR~4l&Y#*1-N>KXE!@msX(u^<uL$)ou$G*^n^6Bsy~3Vq
zW6^mtUP&&UzmY~pwb#jY3UyNC)UURj)0dDw_MkVk9d6-Nq2`E9mU}t1b0fEN`h!9}
z6@9zo3Y^}Eda7%r8rOBs&MG)P_UtT8I}+y#vW7tRpSAy5%Z~rLvyNQ1&qKG_&gj;S
zZHYU|DEf69>&na6ocx`?-Cs8qs1z#+#c~w<I$lz(et{B~VmTMplb7>Va9Og${pGY<
zN2|D;GwSnlc7g8e;DaLS+JMi%DNdBro@N!uG}p`Y+ywgDkWAgm+-zfVdTP4(A_?S&
z__P;O5c`&~=z*Hg#(C7Y6#2|(ATQ^qC~W*BH<wd^%<3qoIB#uOLwPv^z-R1aC(7xH
zzYra*!m3z>weuRLz^ho^xJL5w?gp=k6Ww241!~2@kUgr>@`^eRy@8i^81zl`btpbm
zUlXgjzGBF<ab%7mL!r95rM|XoEH5Y3*Me%UuT@n}QNN9Dl$Vq0Yqm$~t3qi-g+pgr
z?XbQ2dPSkUR9}lcQeUgCyiW*m+ok@T-$#KT#cc=SGX>=>wSE^$jwvgjS&*!;#+=lQ
ztZ@m+S(z#6ru3}L81s|%jI7L&_I*`d!FpU@oI9t3-Av6ejLa3jYlM9cCcR|ljZQM=
zSjS!qoA7+n^Chw?G+vqPN~tqCbiohE&LU3aUVv8ZDfs|mA0(rxyo_X1%AL`ky)r5^
z6jC3cD#|F@lVLZ>%SiU5%o)4sa{DhYsl=SP#h%37EH5wF6P+`hIw-FKtzvP6_P^@N
zD{46K7G7Rke_dD2?LU9fro8ocM?JmyR(Tnzp6Z>^unYCHD#|E6&)3~1FC*1ce`oBi
z1Klcgy=-(VE2;RqOLbH%>nVk@QXLKSNFA-3vW^hi`|@U-*GVuz^t^LCK8Fz(D`~9S
zA3?uiTzU##XKSYm%y^*oTVb<m^W&T7bXnQtH{|N5UrY~WsZA7Choxt>%s-&HulJ&{
z&oE|=G^LSm*RaXe>({Tpfgg~eOoJ&8-hIY+mNlfM->=Djr(fx8?n{UmR5a%pe1Pu>
z1M*4E1B0@ws`KpaVPK_2%D2Mi5Cif_-GKqkg|f!T8iOQ32gNNo1}%_T^81?M(+Zl8
z|BsapxZgM0FbebwFE5trAS*8?nLlIiOzO~g(s#1^+{@zskygr~1+I3TuCbtnS#5PX
zV`d7AjXWjfb@1)-y!J+3OSe=$uc9du_Ck(%-vL=t+RWThp1Xl3+dNN~<awHq=S{76
zp6{u}HP#XPJCWz2&lK{EF$;K8G;{V5R<iP^&Czzwgnbgabq*B$@4-qXLHCrjPFR!f
z4+NkeXG&r9jmmaA@|Vjf<vu!T*@RCL-eZj&t7D`SL0^3MXF_iJ$V_7j{Z4*8%|Fh=
z-=bgN0^gP3JK{P$6CDQXlA8=Bx*+8PKV8qp-^s%H6*wl}UhD(3L7MIOj`{_o4f%Na
zw=rRKUWO?>8+CuIAtMhLYO1T(gk1v?WTQTCK8;Bo3f=gFhZQ*9%5dl7*-qhlRIY^H
z`Pn&i5&TWDIPsiVoHG#LUHP22;^iXSLUt<Cm~TozW~J#jBK<6+8~O!LPkAmA^32PT
zU`VA-gP3vQnn#d^`amh^Bhx8AWW)9;oo7g4_|iS;GfU8zUe7faENJXr>>mJ!{v}nU
zG11a-nIXST{VBequ-Vnw{cg}1>BLrNoADjhPbHm^T^xgqiaIODv8~QXr;c>Su3@9I
z&EP-(POh_V412D#<G7xh&gh&KIEVV%lebxPM)il<0$ZI?`j+7P8KgfXq$iyn67p<M
zXQV}2os}w`XQQ)61f8uGbapH5T^k=%McwD%FfdO2*_hEd3N<UikTWud8wfq?VKU9&
zbfwK~XUR6vI4qo;k)CT}nja$MC8jmkyfiOgATROS@?y5FJU80xzEXbr3;EeD<mWcz
znXtJ9pB>0gwzmA_re)=rM4OFMl{QVd3~s}5k>+DN<s)1ZM`m2a3{l-y$_&1<o1cdS
zT=on3k@BQRe#mmd%TgL0oh{J}+CskGg)?~&wUTz1Tr2-Y9*VSaW5$GK1{rY{6HzPW
z3i&BSe#-5PIg?<*JuHp>m6B#V31d<Qx0U14pfl#G*clTh$%nQ929#T~^OBODmB82I
zj*f=+q|o7G^-(dsyC1VtD1^Eh3CVD45}s%u9i14A{|uSA>4Jw#POP(Bix_WeC&zde
zxYpYlx8+uh6@o$T##rqZS_W>of^oQ@;|?9<7~c#Xm)RLxRcVaH4ug`#QkJsWOHw*T
zUCqwlsJif8*inx6d}un}&iD~`<E@~%s=?dNjj9@NvAxiDlH)xWc$eB4;~~MDuUPCt
zdtvtfgnTqd8%RD5`54b4A0^t_Ey>DW&f8THlhC_4CeploiM*`S)}{+fNjRSm@wwR!
zg?xNP+-S>(*|#uf$PNBQd}of0)Cc?z@)WPl2Ndg((`}#FFYR>?&xammBE8%}AF|8R
zX8_a~C75yy>84yhNh3NsJI`cFPRPv4$Vwi?q9Hk%h79(j9#0!{P5O476VkJi@=~#i
zKDVvOhU7G3N&<oy329lBfLv)i`PVbwRUD6VJMt8RPDXA53!AWbWFws4()@i8yPg=Q
zq<9HWAI!d|zW8jhUvjU!%&l>q616gmXsZ=l_`NbESNB=0%YCQ0e9o6!v<*9ia<>F-
z#5KheKZNG8`>FOj;Qpn!)Hm#cxUf>+aA+6Kfiy3hke4EDc`?^X<|m;X>UdiBfo$_5
z+Nv@kKdl68ZpZ#3<Y%3>{D@sKr}H89gR%oTF4BB#q<pB`1t~{nT*M4Hi;LJdtPt`e
z<!LYC@9Tb7jlWCtQ>nh8EjJ=2GlJw=`52g#YU9R?NoD(nw)qjY(kNJ-pA_UL`%l&W
zvJ?}NtmfD|^$l(FA@*CcL*)6mj(n7N(o~<Txo@cQPC-ILu`j9Yu(SHE)v0sAE{GWK
z3zcJh7i@B1e{aNCy~k3OFgt5w?hyKhox|lAUx1DSwb{IC*0DRL!n-%Fp=KY7BILMk
zCOh?bHECC&U&iXMVtseQKB!&48tp?xq#WbVfN{LGw#jwvs$rmrv2*r8?G{>LcGW(_
zMawZx2F3;I^F*ZWZ8c-8-9C5<S1~5H`93+WHPN=|0^DdHguaoY9F?1RvA3moii(wR
z{w`WY?1C>L;@!Ec9PhTk+uxnOg!4!!;;n8moWGG)$epztqVHDJO^)|v*o~4v@71@p
z_3&PdMNR8s<rx1P80!XCAI1uHQ~<7<qNbg*A$IPfRnTs*A=y3Tcz+GN1KsIwIFOwk
zBoy&>+J@M<kyglEwITa@%JCipyo<E;^|kpPZpOP(HpGJ%i}93U_scQfhZs}2wir{T
zpPktDm&Ew!aUmafqMlNGlwxq-A|L*zG{w4{dUj%)7ZH=}UK|r?UcNzIO0{8PepKPC
z{>5h}e!b=S_yqbd*Jf|bu{U#uT(E&6HgkkLNn@lNs7`8&7l>_x)3I7{TyBRx92*)(
zR39G<o7DXVjuNk^>V-EwCaQFJHj--0!5E9=9D^x24U@F;GEG)%U}0F5!p5Hu(D+Rn
zCwBz*6W?=2&p5=qZ5Q(PFs{%5pFa2;MOuHS@|I#S8O&K@xJmP7`P({gQHcFZ^Y*v!
z{KfA<j#~=GKsH3aX#X?#D}7WoekyxGyfg7E#l}g+8F1$MwrvvP&Bl=!Bpit+P*e{i
zQC9iJF>9=AMDo$y{5WAi<85m<`ECgNJ0Pxq1Ur7sd>qb>N0^Vp*l`>4aVQ(#OXDuP
zwYP9U<9jKdOk;wR4cX}?jPFe|=HsazJqv2sgvJ@(gx|ArFvt~;^Ad!Cz4V(nE>S2G
zMiNgjA}Pwn#{~!CZw$AkdH0wvkRUEM%kr@U*S!nBi{pf8?CuWICv;GR@0&ix%S_Mi
zXq>ImI84&^H9<dpAC~Lqchb*&9?*}vbK`CaY1dG9iH2fqG-N&&G-N&&G-N)uXy_L&
z)lfa?rx&!qG}Kj_hRz8ZD(ENI(6`V~{3s7-$l77^m~Q50T68lc!&)~j%*R|eKQWwi
zuuWVyZ<&uRx_MS&|Gmlf#6dF?!9VF{9xoRgPhijXh;3KN0J(1Rp_`Iks{P$cwOtDC
zIO(BM9a(z<QoFu8+AhDogaL26KJU%`Hn&}~&Bt6n{msW*KTXZY7X2hjd>e1l&kSg1
zGju@uso95@S!>(n_lR6S?Vz7>Klj)jHGUO+ALrUGwOiPekmj~4w4TKVU8rqsgFZGN
za}7;4A9D@$G#^_ubbCkd^nbRK9f1}|L&0@;nH_0JY`bFUg$3B8{_`o+mFzn`pdsyT
zSC#5!V;hTZ#_Fwg6Ky``y1B-1vb0^FnvX5InbN^KbyE+Ti3I<ooAtb04%@Ce!gKaQ
zdf@=JG@;)```=)DiXYOh8wa5(h1mjPcU#c{sr0^_zl%L1q_q!ryq`r&|9aS3OHY}P
zxt8uVA9EXYj$ujKvS?|Xm-^4K(9sNNg0%DtFNZ@dH4wD4f2dqb=b)w1yFI2Q_13Iv
z<fOSxYu3f0r|&vj>*+P~G1t=w^D);`8}qS6PoZ9Fo8~}E`=ATbQ`38RnH{xhVxPX{
zlX5*BB0VK~Oi$J=o2NCDBGHh+MnmRfK||(aK||(ai-u}?sZBZr{WOCXn1+(HX-I6}
z(uT`5G!Yt#jn>{bb3n6#4<npWsUDj1cX3DiR@l|jPwR7^bw90v`Iu{IH^a{2E6p<>
zTeLLMOZ#bh=qLr6AT3Sf<<i`~ZAy@9sUNfycuqC8FYD(!&$6Pg<aGOHN3{0jq`7^|
zKTnwOet-C%>~C|w|8IsD>4)oStNEDQrfKG5i=NWFw9l3SEp3D@NKZMuoDTIQwr^Jq
zay?x_y@|cqZS9*Knicg_srJpz#oeNz!rLtETc2C3+qVYhW5Fgd%p^9+d~DIsmtN{4
zZH9g>K?}?#@p3uTkQjT6N#Poj_WS9%SuA^Iq&QDsW|Qp21{FGQZjC*vU0+Q=L74KS
zwa+$Vm_$EM*yzW6Ea-<nV}niNHfWyt*rFeAeQu^pLjNB+VEW<Za;P8C1{I{r^+V6i
zV%hVeYSxc>YvznZ?MX<xhI&dg6l<d)^Rb{IhMB|$nU5_R^48~OvCz*%Xn|>nm&>7s
z#MtAeG`WW8xmgK&c2vz8vTngVrW-%u{fqR>{_`wr-OM&0bKUeeA9LH&)O>8wjki8G
zn*q&i1plO)n%TUrIO^YvZP%rz<hr5fW`XRPk?Xoq@K4;@cBx(8p5f8jcA41v&4T~@
zpml%jZ~jcp;y;^@1^?N6Y|)RmJ~!J8?NmSqq@NsKPKS0!Y`bDc%k@Lg%@W!3qH5NU
zb8VM164KmuEp2FNyHe|0+n`S7V{U`a@Mmmh|7X4V*rFkCeQtII`iX=VNJDS&ayitH
z*mjw+<Qk&qW@YTzQ8jBwd)rl|x(R4!(aq7jtaY=>e9U!|X+Gw*C)j*!(T%r0H;aX4
zvcW&;rcD4Zv!k|4j4PIm;krq)d2Z(4pRS`#Hx6P!3SFZrh%4H;i#yt}p#v>ix^;lH
zmVRJZS>ix%n2))ZlFY{zEqUv6vwY}iGc-Y3dW4tLp$!tBoB5mMTB7G>v0Xf-CH2<K
zdC}UFljb(9FxaA}K7rPHYG6JV`eO_~Nq@|IY|)dqJ~!JAEj5BJNKeyvxg6?A^os_M
zmFtO~o5ix{MINzD)-9W-H8fJ9A)}3k%*TR;_%k-MUo_8rY|)UnJ~z7=`iX}Yn1*<{
z9BN2x--`3)8lvZB>)3N5w`fSghpB@0&CXry86>U!v`ev;=Vl*tv+k!&FduU*bu%CH
z_N}J**rFwGeQq`sI$8uxke1Hzd^^;V*uIrdkZXyan-#NXL>|$S)9ss+a?;$s9lvCG
zZuYMW*3ZqJG9Pn2-D^JPdOF9SxxrRh^yID2&6Yw-r=Sbc(=WUn4)r9qZ=sXqdZOoM
z>)7)mkLamV?ORoA=u!(y`}RRI>-KGe`B<<?=3~JonU5_R^48~O70^#0w7_f<&$mMj
ziLpo16s{rL=VpnI5MJ6e<V<i`@u{oIh(~9xuiB=CYkzLGl+C&0vB%Uw*81sWKIZy4
z!|<~B*z3*57X5hZbF)ZjCmT8-{k+A?<xoGO4catSt{-}CmKf;){iwHQ?v{||c5Eq|
zcPD5l%0@%xV?jd<Gl_=G#}*BF>vOYw=w~Cez%<0m<xoRn?6G{hTtoEStc>+fs@Vov
zw_qOAO~5Fo6*hPEXqvTdR+*2vZZgfsyzL4$A6s<et<TLiLo=tqKk24TIxn-M*rV8X
z1<sP|hMt?n_n`iV>$*|!Pe>1y8qH`=Kx)@_N82@@&AH=tXGl-${#Xn1G1t#e3@?k_
zdCPok(T}%2H>-elIztDfpLx7o4(*QEc9{z0`l07$1vN;A)vO=q+Ae1#q`B?d?q{(<
zvuaw~poh%ITtkh`$J_?(Wf+pCEE@9G=VqbMPd2nb8v2x%!=Z-6wrlllxrXSunXaV=
zG^D-ls#4wb;&aAW+f}EPwQjy-xR5TmZswYgxo#dYA6s<et<TN!p_vunpLElcm(!tc
z#JJ+6Ib1ik&&>iK(5@Tj!^f5BeK~&@ceG>qe9jotQg~l$E&a`~vS?|m`Iu{In)%qG
zC2xIhwhlU~fF?*wIlP<>wIs$B`@SI85<NFd?BFpiskdfTBPY#m+6p!YPw0<zwANE6
z^D(zgXBd7Kzi7Sr*rF$IeQtIITIvN|ke=S+<#MPe(Jz|wqFhh(+$?dp$Mj^~vUyrV
ziA*=lCZ&$B(UAFA&=A8+q9OCKMMK{D+$;|IDTEf7hIqLgYDjF~_P-?85Ir|5RbPip
zHXh#r%?dt@a7LwiXwKio9qn5)K4*++>AMK)e%fp1W3HtU=40NzwJ{%CwB)VN&5EF-
zeb5AHsc9rDr$a4??OTUe<XWQVW+i9nxsbMgn)56x`bti>Z+1j$PfnWKw|ace7}L||
ze-J)od-xh@v(3j`PyNluTu)8S#}++#>vOY1&{6<&L3*lL&dTXfPh$I)u~4ojdTv(g
z@3!{M4$X>ss#N=C=i+YBP%}PfjN7Cp*6rJC=3~JonU4jVWIncN$XlPAb%uV@pao`=
zn({W?QS7mWu*SpS*SLmCp}$7>{1=}ZSg$<3gL`6+3d0fI8hcc`zKVbn%&&IO5*FvQ
zyxtwl9(JZ>9GQ*s$6nl&*1n|oLQ9{6(OR9f?jpSdTU-N?*0Ul^)z)I9wHs+|SS*oG
zRUtcz7GBKZ@2aNvVTWU(#tcKQDM5H4IjyOf4W8q{Spu%Rm~q74hmPdzz3t+=%V{k|
z`iSpeiCrY;xiNSyY3>1@)mt5VVdko!S~J(u=T+6k^-%B}1Kx=18(MH*gYK=ybyJ~E
z>)()b{TKX<q7V;oZQUYxEx*#|O4Y@0FL2uuToJ!NGH&eGWzlBWE0*)SmHH$@+{3Rz
zyX;n*t#<wDu-Ve*Kh?!^066voXT)=>#~jyV(Pme?Dd%|(cn&<F-M_O};na9g^z59o
z*=o0Ng=)<<Tl$=)y0~rxp3A`-aXpFgWWP>}HhbUOa;`JMb=gG^aIM{Ddz4@4^OWl1
z_Y$}*1y{uHJ(swzP4`x7liLYx@{VPk-vc<0e8Ro>_`&}QY^~j9JLvl>_(xR`N3wGl
zS1L7)&(`8|OP_l<%XyF;pSwFUVe5162jAPlUn)48#Q5TMn%3qYgYRs8?oI;dCClZU
zHzS|Bp2s*>x8lx=%N5!++j8miiR$8gCpg~>4vF_0>RZ}vHQvQ`d-X~=@7G|<%kS|R
z@75OG%ej_5N2o5Yw}a;u;ElNMdaq-yMY~@7j-2al<f9FA8`lbLY!%pbJ9lxVf@`(w
z(s+M$alQ_GF9Ltet~0*0+4Y5M<eV?0`u)9jU(G=kw8KUvy>sVp<O=PY?YcBBUtPQ}
z1?Tg@A*<{AEk2whyFO#BoOcs=FD~~O@0GIac0^SzTubBU)y4H9@LT}ii0jjgC;N3=
zjIm_A$GQFv=aIkuH9iy<_g8=Ky6m~Hy}q}C8|~H@i`w;_B$}3K(_E)L5f?86$7$e<
zURX4oab&;WE&6IhH^_OWxOl<s+S_lp@vQEhJ97(HsMgH2C*tDS;CV23Bd&Kbp6qii
z##kcXmvc>V@%S(gaBXe5y_R23#Knh!+fZ;t{4QqP*ymTY+4>LV{8C)JXsCPmRcJrm
zYO~d@?@C41>VJD8E*=ApTY@v<`A5c)eV#>|-RL7Z&lDFgKdIdhvsdBNc&Mc3?aVD)
zp<1)e_C#Df06f<NZ^U)i-z`43THI8$*{431b4_va;=eq=wRW4WCZTHK*AsDZe{g#o
zToJ#g88`OpvKT)p+syg>8RwCo{R2J}7x%wQyUljc#Z_>Hs~~=2=Ps_0uGM~fA}(GI
zz7K)FOmH@w@x?h;>qm=m@%>xnoKsx9xPiwwSNFV~7nduvYqsT{h>ITq=lj4R@qU_d
zW}kPl-QHdz=bhr>rCmJ6yR}94a;`lQ7e54^OTZg(-71iHvd^_>*EfAC=bGZ;{)61c
zwL%+P1$N!eU0kW)TJ5?g;^I5N_eSu?>^kGiKIfucU$<S(ImN|G4`}z*98^I&Y*f-a
zcm77M(5~68dm=8r8Jw>MhpevuVDZt_+H=vaFZx{0JH^Ed&UuXYO4)TgqN*0IJrNh*
z2%Z;$H{yC1<H>#<7h^0lc5tq3$BP%W({9)8b&M6<Xt%~#)UNL=(O8B_bDj1?T)Y?@
z7l1Q1#*}fyc~<Lpi*-8tOF7RJ7uPlO0MF{)xieC7g=)=Qdm=7g2%a;*8*$x_@noNC
zF~$<VQ_eNT#Y=-cz_qpI_F8^D5f?Xs+c<DV{I&`vZtU|b+U&^Pa(*c;?*FKJ_*G~>
z-D<PduJ1}k*6M$IA}&4{9EXB4;(0jZ$Ue`a%?>D)^GtE^>|@&fFnbkFjfYBl-p<^@
z6{<DcY){0+W5BZ>yb;%17*F=O7HziQUOCqk7uR3#0N2`Wwwi>hg<ns^#XC@)1XslG
zXvU3we#Q97rEfUDw&TU)@6>Ly9dvOOT;VE+pV+yJE2L|+-=2tz*8|@b;E%=}EoOXi
z&ei(SV*I51TRG<x7cZ;hG0xRJZ|BA33hkP0xhLY{SHSrxa7eu0Q`h33sqrqh+lRiF
z^G<Pb|IQxc-P)piIoF<ui&uc>{oswb9?p2OU&lqeUV1>zHO0l_2e^%Eg*LVd?7E%1
zxKhEj+I3IF#mm6=PVmR<I^)Ye=b~NTaZt`V#l`)<)9$M|sDgIbsHAu9{Eb|pU9(;H
zL|l9yINuHqSzTwG+2>uf>l=TR^G<Q`k~1FTy;64Fj;N}IYfr?*cY^12;ElMx;Sb_T
z8`s5$IoHRLz7ak@<D-M`me^jqUANaUR&b-;8e>trz7s?zBw!tr@KD#+Qn?EdO4m}M
z`JwJyOJx&yUIgB-<ce-B<B4;v78`FP%<C-rS<dwh;JWmGGB$2Sw`M!86d$i@zL$dQ
zIpB`?zLTwcW1sI^1-?zc%K5$oJ6_CUu-evbb6efEw&2cO*3~MlnPa6Gc~x^fAN*#6
zFXH$Q4KZ@Dtxo(+&hZv-T=u^gBe$y1TK#dQIC)iboe!Refj8p13tRifetj10cl<Fq
z*Uy3L*yGy$GJ6$I!EaJ;tJNbc&fKEf>b6p>ysG(50oQThj`)6oab=%x(SC=Xkn^1Z
zzRUk-V&zs<TC@FDikDY4$AiIdAowDVyR)@#>~k#ku{;0HIX;W?$p1cxPc8UlfqL!!
zw}Y;)f{R=QaTPmvakX-5wdG1N^UCsG*)>)o!FdO8I3B!BVVrT^)ncdj3cgu~({kQ#
z1Mej){;JJ4b2IPi7Tx(9xk|m}I<FKruWIfC!FvFBB<^oyYvb7GUTnvkVVz&vq;>u(
z+4cX)xVdvSUMY57)qHmb*EfSZ;=4Or6URQ^qK)@IE9bied<Vw6&BiOZZdG98?cBxH
zimuhhE5*;Nn)jCAyb(BLHlA^2pLfy5H~Le~`vR)x|MT&4=jyyt485wkzZtyO1COlE
zvvqRpb1&NXD;09?bHRNvi_N;FeYaB^6`!40M_?SZ>2@yeYE{?VrYptKtD0|raD55f
z5#N7QB949>?~bO;Hjb|EsNKff>o_a8*Xn)qs(+8Kz4ge&%I)&nE0yKCvTKs-&ezZ#
z0dLf2%VIq7y6q^AzW<V(Yl@>6v9+$X)or(Nt?soua|;*hHltf}-S$Kr{S>&~2kwaP
z!y48l7vnIS|CaMjarDGc57cdIEAG`Cdm@g02>fmWU&QfR#*h6vEymGTT#<83ar9!g
z?zQW6TA@94tNm8HzN-~lt6%PkIC=?qUJBlb>pwKCPcHgq3$Mw!rZ~Fpe{vlbtL9p>
z{q{s0eKokA5AKNX0gNmAbz8LG6Y)k7+N8c2#nIQXb+D_sZfm#SRaK=mbL@#Y`Xca~
z559=w>l)T67h^0Yyf>IOX-tjc=>BcAx6ux|L<%l=6~tKV+@-o~xhLZ21>igz98$k4
zfpKQPpDo5%vhj{=Tiz*-Ud-0L)>gOO%)7cr?);5hrCxKL_e2~$AG~LPN7m=ouwJ>?
zjwjZUb5C*fQnn7ZN4U4P?*9P3JrPGYf$L%5j`+Tlt)XMTu8TH)XgxXK6i4@e#BDZS
zq0OxV8*k?>u2yud{<<gP=qccQFgRp3o^fWMchSZVZXoBK;^?Jp4Q#j6b32SE#!{WO
z@pf+HD)pLeyeH!5!@zqycw}{+t*c|7d(p=CY9!~L;^+luwU2pnV215bqR4%vY`mR|
zR~z4+h@%e$*RkM^`2L!4WuI>`4ingz^DXVG(RlRYw%TpHGeI#$roAMN?&?}CRUJp~
z3!XcJHx`FsJaMia#nJV6-|zpi_cicw6y^U1wAez01PT_Y7@%m80(pP4LckyeDh8}j
zksp`K-KCAB$&p;3K!qR$3seYLuwsP>1qxIRSfn6ez^YX$1}yxF7KmD)Le&Tr3s(6*
z&&<y3?9R;Y?B-t5`~8p4k=yCM%=3M|&oj^S%<L|HL|tPYz33x((6!#9hoRGGY#Y^W
z?91~}N3R53PX*nfzN17}-uh;Bm~rrqU;K#r#ya{ic|M=nI37kBO51jN@i3>&nU3>O
zN1uka3Hm}EA4i_2<E>-nzeo0$b&PfNk~x{NX~lSox;tK};}HH^cmB~T+cYlEM;(0v
z=y@CH4Rzf~^yIB;7Ml$pAnO|I=)JF-$7WuJr_+T}*WvuP?h>O_x3T}uM;(1T=z25g
z4)y(8qAPEGGylErBeK4+j$ZoDJm}lpf9GAt`KY6B0sRhwzEH<k5dC=TnAKPwKZxqs
zT}N*^)ZBmj<XavUZlz^wym<JljMlhKeR)3W=<7k}Ye9#YcilmBM)mHu9)0a0vfi<d
zK0H2ede?jO{Hfm9ujiwVJ_veW1A0W=A4i_O<E?u(j<5Qttb44Z7ag59-8;SeE}-vx
z)X^UYU9SY)p}wO;SKj(&KED5Bvc9p7-gHLB^sN|kEhPqu)O{51ag|*8_<YpSSA))1
zfDVa|Cpz=iJFBCwI84?%*3pYzFpuBDYeYG=hxYMVRK2l}&qp17CFp%Q=#khw(VMsK
znU7z3gsgk4qYwTyZ@LfU<Hv%&^HE3d2VE}#-J!nsCC}gS*7tRhqGH%JvSAw4_sQ^k
zPxzh)-`mmF;T|UVFB*+^rK8>HL|bQ+zW=kn{^G8-bTYc2r#;=4YEMQnGmpj7$*%61
zs=d3@U5Y@S)?&#2X$^B6Tvz^-^gaZQ>|Ls{k4GZ0L@Wi@itH2FyLb}(TLU~aC2sA5
z&rjJMw>x_}((wCW*k>~QJ@NpnEs9-FC-Ir^c>EOj`_eRcer!4sIWV$EaUbBf9`N`S
zv>!<1r~6?{jOS~E@9uySes8ewEBZLa?^O6V#1C;?iT1KBtN8Ij(t?oqA`=YX%rb^U
zfZrs*<OIOs7X$-6hKz$vpO88Dvrj_3AcGhx{6Z)W&YPZH4o(K_W&<9`!D=7;7zdY4
zmpS+=z^?@EJI$00EAR`=!H2Sp;T*uP4=_Ovew<*S=isH0eTg4zK8j*E6^@w*-vi<M
z)=^NS{2CeeX12!`v?OBD(s)gIJXuv*S5;S0m#8eQC{5H=$E#`+wei;0+C=5?_4UTP
zdfIF`Tp#@&`kvRJAL;pR-OvR6+PioH{QVKw@l5JlaT<vDBqqy}Pf}U%A5fNB`0fdq
zkDNyMz&co#sII7}s;Me#t*NT4Xe}*I*0olYmdERob+t9Is+b^)@2<wO><0btlLh5Q
z-;Ta{COBu51La2leho}g&g@L3+d4bCSv&gpPkaK}X$6Sjf%~I>e;9F!b<JyU>rUf8
zpzmfl%{f}u`7Z(M(kmT0FH0mUs%xsttE(znTB_pl+KRGRA`U=RRn^s0RmB}R`Rr<p
z)6)TUUNS?L<@a!o1}A^Zt7}`U>&g->H7&8)+UoMEn(BDGvMd>kCu$QFtqDOE-(8Jm
zc_E-I+Z3{#1O6;^wL>rEHMP}sm1XhTvWoJu%2;hYUKJ~iCoAh>)n#?1NzoR4cQuyf
zEa-<He?^W>K32BH7U1g8|HAv$BfBwMtSBpQsjF?NPS#bl*0dzbO6#hVt?>jZsjj-V
zvPRI0@2<wO{15cQPnIyYxCU)5pe+ttIEnuE$H1GE(-uMaL`6kqMN2GM8IQNr)Yg@i
zRmWnr<(0{**6Q+7Cr;kG8sqd}K>n^iPPWAx;T+Aq4*pgqt1DYt5>=HgRi&|-meQKi
zWJNMoo2aR)s;H@IsTO4M-PKr@YXi!%uvC_%AI?$Yl%=}7vaT#vURDbKi?zhisl;l)
z(NxyOYb#sJS_N5rcQuyfI{{^BER$u~7woy|Du-TbYU3?+m5GWP_<w6_O<l6GJXT%N
z5-*Ka#%n5STLf8rcQuw}uYi7~y<GMykAU6v-s<oxwdK|E@|xCovZkiIx~{ags;sJ|
zC0<h(t17RquB$E+WbxhASe73^KgNn*sjZN8UIAG5FLvl02J&QiO-)T4M#qW@80u@v
zYU>hJEmf`M)s?L+B7c2%HOA@KfI1&nDa&#=oTJ$#OCp9LYDHBXV!6ud^14_>qPC*7
zqAF1yZ)q*B6?9(bx2v%%9}OtWj4GMGN5Obh`ly4yb*<nR6Xmrv70DVH2TLmx$=2#*
zO)?Jhz%c2M#cx+*Sq{(AxELlz-C^M*j*I^Vzt`vVS@F_%OL<vYvb?3bth%bTrKYAj
zSz6Ij8LKLbC#ze<anW~IW1QX#=zmLUWSy@DtOrUQc}cuBk!Xq6C6cA(wN<TEm5G+}
zs@6oJG|`%@u4{GpEZ<#?Ww|#?Iu8>IZL@F^b^ckfuK{QL8?Q~)mR6NkmL_Y;%3^gD
zFg8`!RFs#tl*U`DYDz`h@ZHrIrxOF(`Q$oT=idRW2mk4?^HvyLD-vaK;BUMlQCFTQ
z2mh78#H1`%)fz7se3tL7#<JX+C7lPc^NXxH;#Lc%GRRRU!WT-2k-g!6sh^Q?id9y-
z(wz(I>*G+7?ZS!-mas_eHQL?T(-lw7BsDGH9pK!!Ho>o6h_#2^pbu;;XLZ;SsF=_W
z(7Fod>JwqVWJkivuW4<0u%7B(l&J#t8+js-Osvl2B^KMqSgxZKavcu^2De;gf?Q`?
zx@!6qmFpuYH+=Vp@9&R<nt3DPG}To+7N4I?M4@~Uo!{A=hR&0QnegmzAhWPxu8SAp
z8cY|MV}8Zz&vr$B{sa4BF`C!^bp7e+=x&?WkxZ1dcXrIPd**C5@8f%}KAvy&am7rE
z*>VfBo8j+K5GM{nRg3r0InNO9T(F?CBbtb%W1QFSCQp5fHMApzm=tUOSVLpAf5fuY
z>gViF(|+D&^>Z2gT@S~We#@wzjEA6Mp{uMF&gEryVt?29^!Lfg_~M2$CIEJkXf!#0
zeyk(Wp6r@-!U?4(OrsMuQERG%0NBuY_6gHyxzL)&VgKCF*ub2NJ;~G1plm$##FHCN
zJjvrsWew5O&pfH|#1qd}8bL$DnI|?joC`2Sp11H`dIH7!GH8R+U?d6OIPwA}Tr|8;
zh)4LLoH$m>OzBhtY|q@epx>(XUQ|b=WFBj;NPY1(@Tpi^MqfGtzfTqPjPq5<%NVpd
zJ4W|MKidSp*D8OKb71Wg{V^@KP=74WYvFY;j;IDFWtBmRk4FA92j`DG4G@+;$}<J$
z&xR9a{<Hy+Mm|SkN}1ZhbuRZbJb(1(0v)ONLv^I*&lf;eHYPCs;2c%9`SUdJr#Aq9
zqUUJcM)Vw|vr#tscpx|xrBL)710VE?<%6a+${gATHdqRSRRAAkdHDcth>Z(6Pc)h{
zYWPHTrsvc13V(!i#zFXmaa2%$gna4`!6(_E8p85PeX0<AYX7Xvr!`=cr5%BMl8^S~
z?#>(~pFGc~;S<%Fo=>+c{1eXqW}8npSkKR1F^lTrSm-~->Tv1ENs#vqJ?3ZIsjkj=
zvb(#pD^zfy^a9i<q8G*5+aRiiDa>d~teYln%Kbfq7r|+a{jPe(y$^v-FiydI^LQaA
zXX9Be;-OnDzHB^A=F98Qr-42EY&Q!^(64&LJb$cFCiA@oUU=n8B5(ebC*E9c@n-vM
znK$2nakCc|<ax&sS>TOx#pGDzN@jW(fFI($vAOgsY#f^Qd6^#xoV&TkQ46zEaGs}_
z@k23olUktCNrV`Obmyn*=dICv?041JpNRL@GQQ*@uVUlSd1uOe`54T%G~Ah)aY(06
zC11jMcHJeiO_|L1Hh`ZI@6*jCZ`e4r=nFD$u7aR<`15(-jk%Z47gsXV!vOpc@A1tg
zKkl*OlyzT}`EeP<PN|p7;}oC7RI%KjC8kR6q8W|CUq$0!!k;jA-8LSd#CwJrk8)9`
z`GLiw$#Z2M)q<btKi1sOWLP13zaRcWxuH_FdLF<piT5Grl20t&nSHLzr#-<h4X?<X
zUviEOW1T~p>}>$v?5@bWbK!^Bc(&|3nK!+VS2f&eo>%#(RuP+6N96P#Whuwn6}oLa
zo{9HIGyju|Ix!p1wwy2Xs2%dHrVSYz&w}zO^r+x*p>X4w#|f38QMP&>z%PmST<4Nc
zY&@G9llk;4#78Bmyzwc}2;rgf+;Aw9y$!${@!suR@}|q0i{4`K21>_~z2RE|-?^~S
zbdfd=@|Y#6ulM*z;+rSH`Q?v&-!;z3oCDW)uQ9k1){~@qTH4#lT0}_s;3V|EC%X1;
zO$+6}D90aRW8m8X<zPdtP89a<aDALBFp+0CfILhu={S|=V7Ly>BjUQ7^D*B!U2D$(
zy~2vD6`CIZXgp?q8LrRt!q#S<2W|1rj&yQi+M$n`3Az9G!M=kR1nfV<o9II!ANzMp
zA0}%|?@`EcuS*WLPPQmX<*2gsa2))71me9WxY-vZiAH1g0}Im01*y)iSl1=dmY&wu
zB+<sao>*6+zTRxV05Uu%tczy4KpUa<XRnhL*BqW@+5CVd)7LGTu7tk>xPB8J#z163
zk)-vT$`y9T+__&^r^))eKdjqm?~KRVVG*9VzBJKFF+arWAFg}d4{T_tPUv5EyfX#s
zUFRj!(e_w(I-2b2>g<YkCA*Wb_SIU3rQgN4-yaricb`aI@k^u+k;v=NckDA;Z@Sa!
zGx7xeD6T>NG#uM}s@P}8b1i5cDvg|`e5tROnv8u+ozPG07h5~rKaXOGYdz7A%z*D(
zpo`{j3U(;zT39YzUvE*E{4vIDi$dRjfwokvD~S)wz&<h?Yno5{h|hz@K7I_o#jp-~
zAk<p)%Y9a>o6qrzYtga4ms|ETp-t{@9rU;KNk<Oow|1U+uKIe9F0-8g5@YPewdUCG
z7OUSYt$yQrO*W>S47?f8uYDC)6<Z_8<x*RazKQFiv2Sc0bmLbjrefcog}xQ(*Tjka
zU@#$;%7xIT^ZMdCXzbtbE$rrAK>G)eb|Kio64*!`)FKA->v}YG=5W*FAXrAv7er^}
zLd`|Qq`h6n<ZT#7hnESy#ks~lgba!?pD+>EBZa|4f4(4?yd}gCh{@{~PnIr_G3f&Q
zn)LG>8cZxoD-&LIl+BF53z^ZJH3&WzxH!Y`S=}MybHY)ue)`Fvobi!Fq2>(W<9XH~
z_|$^TES5(8u=^9%cFOo9(GM=v#u3h?jrRR30hnVOROU`*K3<9UB#2n7OUYPV0Ctx;
zL(7$*-B;){JQn(snPVZYuSYD{n(@sS%2@mjc#--}AYS+wjmK0faVjc!M{`PZT*P(a
zA}-szWL$m>92v;v+ULtd;G!Ul?VrqX5!X8-E;n2ArGsf1moI`(?t9UXFJ_CX6igw8
zqjWl&5e^Sf?ynx+EW;FuIQIJ*WK0m(BBL%@ZMW|tS(opDE>j=#^MhHyM_+3nlj_WT
zcg<~6TqBJ7WNW5oEtK_n5BTziTk>F=&bs%Q)L~}2Xs$PL?XKukCtoV-?P93Il?0gk
z^#WKiBoLpc^pPQas_y)Bf`tuYW<EoAu3Yprh))&Q)rvlK%Vn}I%ONI@=<^V3kk0}>
z;hdCC1zA^T=DTZdo8o#`(WkEXs;tjjAr9=<&o^XGpXLrLZ#v9O7tQr1u0ut=-EYOI
zy;sP3y8&XG-tFdNVfYLrh_?!V6`etbKV$Ct9mLm)YeZ4UY^}?Dc%~wL#M<fUn4_I)
z9=~Q7E4>Q~f1w<yIa^&fw`FndrZ}e7UM1`KV6f$pNAhONPB%B^b(_iVn(I?sQz`o9
zsqp+Sx7~gd=f0iKQ}Vor%m;GC_-7rF)3uIr?7J)U8+BtkuO+T`6n*o!ugf~V0^;E2
zH!|j%gX%c6gY&phNZ;&nM&%Hkt*)EvSzL!G`sR&GWIg{8#^BQH^QPxO&dx&<Inr$=
zyKAmbaeW}_lg$TgyH?ic%UIvlKQ};6POqYbuFy-$u$exkIW7-_tm6C`!)4s{GA;*#
zKP%DS#~Mxu1tCeXW)!&SPic<JyI|8IE^k`%($km9xEu%j_UiAS(&OSYI4UT^26Z2F
zMss3wjP})FH2WJeMseUyseVm<Xp9uP&J0GLCpO3EGa$FfqhDA&ntg+e(PF4wH(#QS
z@tuw{w6Dp;Y0Tws1DTZa-zdv}De!4ff4{SN#}&G>eM%-yV=jNE%SPDxgt>jP{Qm*0
z2KD#NIXgZY6Nd#qnLC*|7H_+_z_3W%BxCV&z%8P`=OR$|6?Aa;h|HbL9E-<XykKiM
zC*Mr5fb@{8j|0dekHJP?uyxXxn=X_#&3nXk(ilInb+Ie0{w{`o;(Fa)_&x;dQ~NyE
zKtuNwYop;%l852*GUbo+-Ue|UH1?;%@~h{4lj3&}oM0k+u~s%2KpY|KjoEwg^b4B7
zH2fDm!#PcHbFX{;fb;|2-&aD{?y@zdJFI?-Yqd{+eh;0h9S`Wtm1EtrwT@3{gRUC)
z)xGxlT(%Z(8O0Qq<`PUHWQ_b3ble|!?epby@pFJaiR+(H&+OUBjknM~9V7JVa{yky
zh*wWX+l4*J==@|X1rKy~JP-~Z=bY^7h_y#syOPOhsuOOAxdfjpn@V=Y(w$wOhSM73
zb`o5djd5&E{%4@AGd&;Pcu4hpD~lg*rTu1lMt&{=JrAC))pK_$8HblKMi;cD+vdg6
zuvovnv-5(UR5TrHX-{fi-U$0e(_JxmNHlp~T`JbrHKUBYLxPF;<^S=M5!bq-Ja{kB
zWza{rj1gG7-`0^x!jd{`4L^M++n`HEyzk&Oh=ZEHM%Hz+cPAOVla2LtIvnk-53#RX
zU~kq}<jncjyW*C8i(<duZjlJ$KMwxlg9V3Z{ham7_oZnzP3(Sc*$aE<{*+va{le!5
zBZdb8N{HvIf5L{4ci}tFrb62j;OF@rFK`^T&xZChppSgE6xv0ZW-NE|39)_(<S&A`
z0;ovXGWopVOeK@<9v~6xK@HaH6#d!=`<6I4;QO+&u>Ja-reEiMTgK~5z`e=&jt1Ws
zkA>}56I@Hh&C=UsZk`7m8KCRTm>zv!BBtusQl%o*-0c7N2OoUd#mzLdskpfk+ULT)
zI&QAFWMaM!xj6uOX>xMY;N4*1{J;-29BBTI%z-7aZ$q!cW_(}XrNUYXHN168w3)AK
z`n5yRuiIeXh_he5FX9T@uWxJm)we>%Ya;Nt6y~V}ALIK{t+4%?ps|_6cV(OTK8#b%
zbp02z8Q&LVsrnVvW>yR1Bl>MGo4F76)!EEWOD54~jsf|5UGIwWfA3W|o0*}(dfDwV
z2d2Wl4X%Fqy_iacwTaCfqUqQCJ7f+V20p21Es3WX2MpdvCF2#810@0c=0`pJW~5)n
zdI#8M%4u)DFN6w<^}jTJV58M9F@CxS<mjX8XBpPMFLzS)D`@<5w+m~p_-UsH*6rVu
zv2Fma^*Q4K-xo2dWHRCP2^wDGb8zq@Vtot9(NEX&FsyxFs-)^yP+l){VeRGHZc<?V
zww3#=zKhCK335$<Zz+7wg8fSiVl90v@s%F9e|mm$VH?~BiuD1%ItF5Z@4biTiuWYp
zH;x;4%<YrmSpczATN<7>ekuF|<_tR^Wx##$!Q-$CY1?kKb+)#`-P$xSc-O*u>fJKd
z?*i6Eg|gP&33uM`X7fV5_sDqP1>^kiGHqTTXx*e@E{K%0mDA_Wf@Zjx0-RwQBN#LP
zvF%<N<23lsLGa-ahgx+z$Fl(fVXUYV>oLywx^XAi`Su^@-6vyx9K;3vPnfTB@FHFy
zto5^lVJ<<}IXL0YyZ;!xU&i~JQ1@xrmDgR55sd$9jfu6ZWsI+fF|lO3xsMJ%?WXk9
z8ZQ$5Dk^g4%a`nKtxaF^eHr&z!0o0&T(>+%IM3q1X+M;){|IotuTa(!j}g3?k6AGw
z<J|`_%E;s9F^Z4%D~3)sot;4+<8hU-=wqflB;&pa;+04tuD=~4oM%2}$&Y00UjhF<
zbe(yum|@O4GobJ%S5ZB0vErRp9Ftf>@xBe{JrTaQ!uL_|>8W?MaZI=fT9<Uv-0-4U
zM;s=ZJEI-&(86dc)(x)&CfMleUJt>)v-xEAx>F`w!^5&{?*o@2w`jQ(PBw*qBgtL{
zWOJ__y~om9$&Y2(_6OOT4+|li52qEXV}pcNLen)Z?scC`zQ`l8e5Zg9F8XQa<x{9H
zWAeGzY_hc*LzaA>0XpJZCs>jdSpYSjQvEZ9oPNkFTU98`gpU)T5Aw&kR?58wlgZP+
zmg-BCryKa#r++SxxjYI5WlA3Rn#$WO`$|75%kwVir|&yjzvz@FOEzVqBlp@!Cey6P
zWSO1>9S!N9%M(Z@g_?})$V4Xh8ppFNJ#DpQf~9c8jw;~qpI|*%Z=;|m?`LVo=O^PA
zAn(y<ne^plI6qr=fnyLJBi7z=O$}R%xAG?xbMf7y2Lq1=z)--GDc3H-i{r6N(e6t+
z;`6&YJD_kMo!8#k0xQfwAFvq9S}0}eW5xB2hg$vJ7y96SMk``K*8|b#H_wDT13%(g
zy^SDyX~4e2I=E<hepfP<AP+(_9@oWwW53R}biTpr*P+lij9I3@_Z{fhU;v#%Zve<(
z&rf|(&^z|$vsQmr!@ZaIfsl#JMZFDw-@;n*X@ZWO&s>amb*7@1Cc8S55a^&DVLC?f
zv3)OcECs<3UDHKlADrJ2pVy1eDu-#D4;tWPiDbNO0T3qD39A!fzXKzC6b}JztDvvn
zhV6sM8bNzL2+!S}?o7cy5e}eyY|Ul^JVO;fli`baV_$L2=1|}@n~An=TxST!n{wB^
zW|Q@4qoz+If%}x~u(}kwPp`v!s|U}R0QMY-Mw9dB$2t=2$*yT9w1S<|fR>nT!wJ*e
zQwR->+Bc#%D&Kt$yQ|B5fzQ-X-k`j~i6@<W!incp(jJ#LG@esg0ehYcDg%B~zmR&0
z^5MJC1~iX+9lmE`9q0uu-`#?b;rA)Kv<9*vS4-e8`+%uLsJ`uYUT+4wI}qA&JQ#-G
zX8;~-jM&HWxoDSh*az(tZFdIv;8a)gqPEVSZtB_Tzior#d(l4&OLJj&a_%kgZ{k{6
zJl9sME#A|G4|0yi!Leihgf@)a9L^axwdqsV>G{6J&7yTOH~)$G?4jDcA$#1^!V!x8
zw0<DdQ^`-Nb3H%b9wYqxJ@7N~`CR!<M>v~xPX5i}<nmw0octcxcf+ncpKr)Rs#`q|
zR{#!U#ZQ)uiidLc(-3kDH$KxS#_-Bt$(-zl!Mvm()<4MPRE^<O-+FGQ0FSZ4&4!$D
zQ#)uef0;FUvN3$)Gcq@ih1y@FP}Ymc^i+=FROfnr9u1g`1%Bcf-kdXjD#!4wagvSU
z=RGTP^5*HVhUqJri7RCRNQ|g{;*tXb&sb7-+CZ@+)vca~Hv$f0froDb4|~J$FnW$Q
z5s#ju%#-z*c<^%>j^ojD>|~s+hneu4%**Q_w(ot%JQojNs?OjV0mYn!T|CBVCfRAK
z#&oKGJy*Z3$a|{tkeB}rxZ0mXuIfkioX|D0r?r0T@!!dOJq7&7z$|k=nqj_bp_v)}
zLV^4%<$<2FjSByo56=DxI6Ig_&N_y<hTQO!#h`OvlzDm}_>Peu=gqG=;K&s>slN5x
z+;5EdQylw;N5@S$Rszn29Q)1BHHxu++)FY?Z-kt+so>TJnvMNb|9Y-2Rpj&e@S`~P
zN18&_Jed<T=NH7O+5wLHRP)n?perBy*Zx7~>t&F`Hou;+v0oO1IZAaVrG<tari^ga
zFYfgVSCu(F<$<2F3l%wjJ~)eGe@PBG>lo~E#8Wo*&v`}W>B|s<l@`hxRN0*>xk>e{
z=jQLnNL+e`HP15hRjRkApj0>k%Z2d8br>V3YGXE-Oow%+uEi3VSK{&VC)j!nyayMi
zW<S7174tjW6S!s#&xva><^soRp}#n1e8p+lKYGvZe_?-|C&qQKY=4}`#V=b^w8N6q
zy{2f`b6pM<HQ#HB28OAQW`n%A?r|1;aZOQkz`m>26aj3CkF7Jj?^#?^glnPjSxN`t
zT)XRi)p#Ot4NT)7X}`f8lYT>&Ba>laR0`&sVf146i~7A^m@Hd_*Ei!W*2L!gc!qu6
z4X(rLYuKmrExvEI`ZUAp({%Vd6ZRc}wJ`zu#KtYwE#rQ<-)YR&XQlo`v6=||84uqN
z!S@d6S5dvg4sik2f>=jvUUC7fS|C@CvLy`Q{+;XG;1r4v)h*f?;)rY7qEWIwrX6=i
ztk@c@5vx!8Lp%0sU-<qDd3Tb~CuyA^zR4V3V&2h7Fu`>n^2g>Ea!KTuc>UC$DJE>q
z+QD$5IdJ_V_AEyGmG$&ZdlZk>_SigJ%3*x{)8L#US5C9IvfaAA_$-(;uy2X4{OoP;
z=6!HuaJ$uqp)C{xT>CN}zI(y<In1d)5Om;NC#R3k(2{h)nWC0R3=hkQs8V?0d2B%v
z9@-a8Uy@1^Y@sWPkCR{cerY$qm~5+GlVuwM*@$Gee-PixFs5WX%tN*%ugkJM3$m4<
zm)QkmLtm@YTjC8_w%>qkrMrl1Jsz?(Y?WpEHOSVyi^#Sf`l{30)W68GZGin7b`jZd
z9MZ|QLm}HUAY0QeBHIxjvTb}**4uAEwxV4`whKLE8+c2WZEpw|dvDLMpHx&ivOT^n
z-6qSn7s%GPi^%3RzRmxuEZYQ-ZD1FX&1-yX{F^M>hd{Q$T|_po@vY?VvTWl(wvk;#
zHm~t*r$V+pLAIe?L^iMSZPSRXxA7p`@Gc^o*Z8*PAF^x{LAL%~L^jp<#_q{o{<bXJ
zG$=X@e=@}QHk!G0Wfn*CQy88VAOAd#$++kpS;iwk#*tl2M%8%7WNh9p%Xk>bSakHR
zrAO7c$7F2$rz~R$$XK$A$*3Ctn2gikm1X=W$k?=t$*39!nT(VECCm6Rkg;?ZlTkGu
zG8sn{G9C&tHtb?Ds>Veo<HjAb9uEf@BfFT4UgP81_hcF8!r0%pKJ$K6kpi+hzNX5V
znelPO`?8GZV0^QS$>=pc_WoOz@rxki;4UVk*Z7#&Da$wqWE|SXWb_&zXZ=T(@l230
z@~d6T9=*oL8UK}K`~t{0yo>44YkVyFK$h_=ka1)elhJE@+^&%EY>;ta7n4ynKC(H;
zg^@i-Zgv3te<FN~;fr(s4JVOVGR?D4aKf%Db}_tkD*^lC+Ke#su<Smbf!$~yj)QaU
z4PSsb@_DE~m%JeK!8r$+z5Bz}k8<$5p+`TpiNpT<Sa%esj44hNKsNbf&sXEx0@ZU0
z@c9C*a3IcK^XFynF5~tN;1)Sl>r1nTTc&4DozM}EnP8{7hhD_)b!*;x>Npv@@4{Mz
zp>O7abB={|8KIgnUaEV&MZB1e&KWP`bs?<d8t8YdYZ2$t1943eJCo@X<#K`$HmW;6
zy(uKPjjHZL7I9-X+P9~S+YE4UeUE3xMs;#2aSLaox=XmBGv=J?9$67PW}|~2lCkT9
z{IqmezQ5C^nlWCgdpSkC*c#b!6J@-X;5_a-<~}Wa30TQEjirXaikoyM>q2o%Ro!DK
zV#uEFJbN!0!;^t?4YSPcHN1364E0tU{z7gTjk&10?@h#!`Mo83%Q)^2T<k5Bd$mH?
zvFg4o5j$qb8z#xveFMhYVR&vKu#l~5^&D$`sG;!b))DG^GQ!!h$5q?}G__;Z{X!y!
z%#J7TBV%|8jJqSRWz3E}q|2-wdtAs3qp=;U?qLyeWOm%NuZ-g#z#k4?n>QSt(Q<gA
zhsI8IkA;ZclU9zgshDDS1e8i}eeG2Ey9s<?Dwpf3+PdL+lk_do_~=Q#$`&5BnMx&L
z6Cd&&?}Qggcc)>=H|C~ji_`Fj^|5n%J5R;u;fc@qX6wB-qI~Qka6EhG+0)P-i>G^_
z4`h8Ww&T444Vc$<b}fjdX*)ivZ!)wWi|hZB9rM!ju|Ink!>edN!1t!XEgMk~33CHD
z9eMpWd3GQCv-t1i5u5n0_$)qL1CGabBrnEe>78P54g9zFoX6p7!{>Fy+R4BD$N6vk
zIPA~+&T~rr!Fxu8YdZRa@rdwm{F-<V${et_jli4Bpnr9{p^Z@t|K;q<#chcs!S-F}
zxkx+K2=L2z*gRS0VKEk2?$Fw>k}~*iI?wD>;i&i;xGeHed>%XF;XWXriicQS`u{wn
z-1p+)X5ip?z#HV@uLw`V^YCfQA8tEP=HVw{ENRaDd}ClXn)<|jK^}Im2jk)=piRZa
zgP>i-MZA~v|NBJhhtVe{fQMUwJIKYOW{l1!GA=GWNao`C;2Vl^KM$2PE{g9tU|jsN
z#xH(O;}`!w7vah7R!o3g904Atfjh{>mk3wF`$aYfv(w^Y8JrX6KaPR#=`aT~bi7oz
zVfUf&Fecg(i(imT7{~p(d(jpjOzlCu53CpN4{SQs(Fb}j<$~D4wgo*4qTOxtI+BSf
zd%rFENa(ua<6P@^IPBrR&w^nw=@4~48kGHL>&SFJSPnj8s@#t+U~K!M0}sy}9Ah74
zCP=jywF>01L@Wi7EQzcFW#3`WPm`XGSXWo)#nFzQc6@z77sPF-G(Y`eOv&(>{ZSd8
ze*r#Ch4TJk1w<zJu=$eaLuGtcLQYe1OCI>+%$PGu8xu?zXL>&-W6}e4t;n6`buF*X
z>(URU4QeV{Va}f^o9Zu-@hOFIdALxXu{uhdT636;&oYRidoR%DvDur0G`A@oEw!{U
zu_^ZKzTv}VOqPNlZr*P0XM9R%iscPis1<u$MGKVSn8mP~G)>0pRNznFspkC2Fjo3H
zOZW?E;WFVB^VKtsl(Cuuyc#N$_sWL!MT|>xKQ7~Q6O3i0@Gc)<QvuD<D1ZuRcZ)wE
zWA#-S*BT1(-K`3^g4o^4=`vQYf{!Y?K4U&gF&=sPbLU9s<Ci>6J}SR-5?i-*6vgMu
zz(IUo$(P{!RmfBOW;w<?nx{h1ts9;s)i$p!4ZHc~H|}==VZOtzyUM!m>2RJs;d=^v
zZ-ncP7+%+&LxBVNhvvoXy6hQp>>aA^_t&xKOP3r?F?bBlvp0O#!1q+}%_UDcFxW+N
zQ>rv5x<p&MIv3DK2c>zIinb)qO>rnA_S_WKwT}lpSRIzV5AaA><l2?&?r8@$U_A`q
z5A`<GS)h$SQwVjj9oq5TYsroTnMYwhf5i+L_rJn*B72$JrdNKU2!U{SbxlAYIfS_c
zwM}p6iT#*h|ECOM&*G6u$I95>g6lP}$OGq{9x?BDUkf;7itEhBEIv-g`vP3=xzs$q
z@d8FMPUyLw@m$@T=%zlV8Suyy?##zT%4FO>4zW_-s?7M9K)8qVF}h1+)W;kGm}Clj
z=3`RjGWOR&>{WVp9<Vp}F*(8e3cw*#c<*DqcVK&kjQ7`I>=<~(+^745qlzKbGuG93
zn($XKA-$=;xp<W0>V-l~v!A7dMOCs6P5@mGSD14?JUYtCtlsN{zmSO<jN_ZiQQCs2
z2j=&8RLgq!FzCDF&b--z(*unW?03(g4KP2ns8+`Q>oB(W-fJG~_`sv^(bf^_=suhu
z^0<nL0hs!sMWc*+ME)~BG_GFOK{v)d&t=RHd7zV7Kjd*C6Ezt7q4}eXfkZtpKh*mv
zSr0FOziaNvn;ruBp<H4A>kN(oY|eP((-iwnuud53I{3E{{9WWH=3{_Y&ZP*3GMaPg
z&To;vt23S?@4!Ys1Mn$6tR6NAZ$pl(g@?uC`q%y7JqH)j-_vHFQC^DwhHY)Ut*nl<
zooBbzvbN9LZ8fazB)hGewN=?|Rjh5g-B!uk4zb%RXxrY!?wS*>6<Q3ov;=f|E9_KB
zbV%z?BT!$$f@JjMg{dxFJp;e7*2s?82FD~o@J~L@<fqT9N5Sp-)gHx5VZW{Ly$Rae
zt$nesh3_6$ogc4(U$(YC(IE3}EAVZ24|7}37~k|!Uzkg{DMx&&3FnsYiLz6EolSo`
zICm;<vpF}@ZsVLg&TiwJJKS#LoIAj7<D8pdw{gz>dpzkE^rg(fIkDD;{MinC*m(lw
z+~jdo7UYB%=kS<j-~w`PFM1vFUVEU?2X4+qV88R=i=3Nn?Q6n0c2DPqlVr}_2=%Lh
zOY-33oFhw4c{YC$v+eQ4AE&<^JUfWD**u$Mw{f0*01FX8ZO9AGv$yRw&a>C-HqNt6
zb{pr}Gj^MUXJU;Jc{U&U0=h)swuR`<-?!m0>){yW+3zo9@~eH@eAsUte355UX`e{V
z-p{wOv2^CiGS6BeZtc6qJf`;|gd)zs-2+AQVb1S%Y^G!BtZPwj>eu$9za4ygZwdK#
z<PjfBx7lr+Z?D>IoNv$DZJcjEx7#@1*4k~HZx7gQ4!()CRpi?caA9L3<=Z-<Lw~;E
zF}1)0<lAFkXY#B0wh7K%3Hu`7c3S(I_%$|`4xA$M?J$VXQ+H-&EDglBaAT?N5^l;F
zkEPS^w#U-fSF-WTj^AG5Z8qmN*lnD1KegL9=N_`#IOp!R+c@Wz+ije4*V}Cl&WSZ;
z<Xi*rVHW5WecVc-M}N-YF{|O21aR)QyO{iH&drAXR>2oJx7pg)gmY{xopPGYxvL?_
zDQe0C=gh~_jPq>$Sq$g##n;f^4&QbOZ?k#UZntrsMeR1uv$O0r&a;#4HqNtJyN&bg
zXuHk9GqIMAJX-@C7&w*ktdZ!>pJ#Z?WY9nIto}?UznW)j;M_&9FY;`WwXX@!*u2QH
z*_3CSt-KWfeiibB{+G;SHlO;KB6Z9{eaz!3ZYO6tuAaA<#WCZH52n8z-1{(Zv$+?s
z+c@{$`GXwCy>7R0?!9EUaqexf+c@`rYPUJKC(a=t_of0bW`KUt$899~^yeNP(+9^O
z_n!SdlV8ofQrK@Pe35%av`<EH9KVnM^D_79!N(09YwqJR%su_+8va6V`WcV0OUsz;
zk1sxr{&w*1)4a{*U#Z>3`FDif#(m#`b{ps4M7xdiZ)Yj#1ICV=e}A{z9Q+gKPLO}g
zfg7vOp!^$m9F+xqlUKfq#}olCkbnQRj=?oPs(f_-&OHhCMgBF=J{j?k#dS;0l=(LS
zd|%Ob^XB`UBW)fyx8V+E^W%%JqrV-T`zmj<IhV5AIOpPa8|U2Fb{ps1sdgLZ+)TTT
zbM831&A~Zw&Ima-1^7?`dPSetNc8CM^YEC(a13(p_}iKMYR*lA{d(bxoa?pr4Km)2
zn<I1XYmmF90^BF#LkmR=W*reIgAIQbx5G0XZ)e=i^0@KEZ?0rHtDRH4%-d}44cTp+
zdq1<=IQM>Rw{h;>XSZ?gt+3lT_inV?9NZJ<%8+|Yffp;jK)JV)=+mEjcuWL1f!w?O
zE+)U4d;M_ko$y8O4O{z~aF30*i_ez1*8zEK?}m(xw?VlVdc5_xkehzS<L%7f+T-o}
z&$4mP=HFj=o6WyryN&bjcXk`+-!JSo&c8?PHqO7*b{ps49d?_8f8rb=@^1q0Xe#I!
zecu|QQ-A*9F}-jM^6v+~Ve+f_R|5Mjf-mxK#M;+{e{8(nF<0i_5X5^;sl4$o(0H2-
z&Q0oOn2#_1b(hS!CwQC9xdFS4bM7v?jdSi+yNz@1TDy&NZjs%_IoD~oIXEZIjUwlk
z03Z55ugJN@M34TQ!(+C?G03^gFJ$toIkyb<8-Xu!ZqVA-gmdhk^F?2xoZAnMp9tT5
z;5!@Eg%9ZOzfbkFw711^RXXI9usiV|u)Ip~vDc;JbBNsc-?v!zHOx4d_TeBn1NLEm
z_)dZQ3sOHvf6wnHGJKaY%o3(MyOPj9cxA6~-*$uRx!3rO6h|WTEOd^t)#~rCqQ4Dr
z{K!uO^_K-5_4Up!8~0g!-!WU~e>^;eK<qQac+r<-J%0rH+!PAq?$|{PV9*uDFDClm
zPrw-GVp-p&oG16~1lV^dES^I5O#4>v>f0HXuGd<9JIvzdA@KKAu#cujAqSG)(@Yy?
z!i^m85Nx=?!W^R);oOXeXvY)adT=;-eiwVz1Y*bLdPe?-Vt1(3zbWvy339Zi7li)p
zvd<64dsFP^hnsLry!VCOTO>Z8j*Yc5qB3sV0k_gZd49MJow0q2^XV$=Snd71W*NKN
zVIDiOEDxM>Mkrp>ii!#-nYN_ya0tA_d0`b^%tn{RWW2f{rycHhj2EHrSyRMaIh>ER
zfiv~B;{2uxH)f+lEi!J$Kt48DD9;bKp)<Boah^_v9kbC$LdNbU$R(P0<>!Zoz)PHO
zQsKqsc^Z>4Uf05S(D07APxGk=Df|x$0hMcT!>xn%xQg4+ncAy3Z=%AG)lZhT${2nY
zIF~BK=ZA;jqFDb|;mG{n`gt;rlYxr^Kh7H$ouh1cqPr<*?DxbvwhB9D$CKJ*>~4Uu
zw&-#5vDQaC#c-PiJNCGW8$?q(7VEJp44ECz`HGC;r7-T6ypFX9o{xLRD;dTxdv(wd
zb}ZHvRX8#`?z=$7aWnYCkwSTXcnIvo`j`s4+pN4h(N3|ehqPjE_+o+XQSgC-JG4Gf
z&yjFh0c7s;JA2@n+jJnNIXvd$^2b@{5}yr@xjK`nc7ZI@`@n~$Z)xo+oJ<PeVP!g@
zWfGq=jWXS7>1lF@EYtoV)4&lSWb$zuo}rB-nYq5i=N5~yjVNS01^i(1Q<;}dp)xk8
z;M>4lOf;8Gd=4(kb_1(xbyB_U3uMNcE85rs$l?1IYVFGz17y&qOzJvq!gC%(IeJsF
z9Np++&(P|~Tn>d&yzIzCj!x(stM8#4w_5sWx=@zmU66U?JBIqmg6){d^R`PbOrDZ1
zS)M0B_R>y6z4*wZP>rv>n8@>(OFs`;`kB;C<vGQ&m(Rdo9FI!>qt#D1->q<RZq9XI
z(3XmJ;EN;h3AQlH5lzwi%K#MUmT^q&9;cYBI~20wI5qekt?t6fs!(FKWOa{UKeqI`
zH7)BE$FGv<A!PO8tU|R4&U$OtG}d>IX-wWtJ+izwrVaf(^YSXxn>Bge<J>)LoV$q1
z>mKKdF45Yp`S_qvXtwz49{-qp%P*GY!|^Zmd96Op<x?myTk^Tb#rrM&Em|nchvQ;u
zg`xh&kWISBN+x6TC9;e-Ru1HJtjvtxagU!&#>PvjjAB0bIE<eIA87R$ZcH(?NqiHN
zHG0wqC7Z|8KY@OWF&vX|`em|={{cNV+^)67a59?O<tSv_3H=sjWU;~IMY4<s!oK~V
z3?XCYY*Qhrxjqlj$Qt>oEbD17RyM8AysQe9>c+}Z$$BdEU)1aEmY>~Z$tsSMDe$wU
zxf~}Il9|Rkovu8D$u)2})uAZYMWFA#T#k>UkgLbVO*ZcLT_MZ$9$?Uy`*Berop}zj
z!=*PSU#eG@?<v4yDEDLHsN@@T>F-_3-ukbk^075<2SDC-GK?$DPix1+K+p5n4TC{u
z8Zp*W?(gvq7i(^UWTkO<XI?bXiOZLab5e2r4%SB)UPE7#@%jtk)v&kL7iSNzaHF<P
zB}&Ll{hqjH2l0B-;@9@8WW4&o){3so1Ha5Oj;vrLuG0}YHSKB{qj@k_IPwkixk4`+
zQH<#%eNx(#X0|`f`IUqUV1wfN91*WM*T{Gsj<tjPGGl{*@Cs*xx=Sb_Gqpi+O^#@T
z3%@Sobq$OMsdMsxm$?mQ1tW1C4r0WfwY+ADjM3%b*GFD8_fz51h#;02{whjx1+YhP
z{f&s-$h9(dp8|fBRGITDyi`i;^i~=ELQ42dZBtxxBl@zE>t*aFV*GVi-gxJ<&^+NK
zuCo!jcHUAMud86J99(5SR{Dsf@H^HKIlV6v)BrOoVPaQteT|6S@^8r4b>g`Be8%iF
zD0ZRk)Z;><vQu$QjcBLqZ;-Kj4t!kyMR~(6key}=FL51>h}Zl+ir4pGe8D+={EK;I
zYS7%TdBvQ%09`p6gotT%=a<MuZwn!L<phvX{y3kf8F>oj$NSsp^EI~)vhDH3FVNp`
zAAc?U`}pEt@$DM2{RH2xCfg74?JBZ;H{Y%#&kn?U-Q0OBU!QohtRKu{n<kp`Ib-_K
zdx0>Q(5c8+N5cdITSx2p_W0t5>2I#1`}j81(RcYa)zM9So9gIlzHRHsojbGpHCBF8
z))D5;C0FFZhMe9eFM1gua@%@Y&bP-GUrm2=y<Eb#sa_WFZK{_T-==!`BHy<4qRZDC
zZ;|za`Ff-v-peAy9RYn?ACceI&qBUEzBoyLbNzgYZ&Uqzj&D=_oXEGSeyaGktsi%N
zfcdtqx61m#`oQqLnelCku@vn=9UX@AZMsX0+P9_1J8Wzn&E?zUi%+J%xsK}iHr3HF
ze4Fa%FuqN7bO7JBb>yx|FyGd@T-FiRBznJ?2OXLFwyf!;h`is%*2@lp18$EmevSU-
zdU=U&Q@#9#Z&STI#kZ+m9_HJ&UUYSk8Mn!L!8%Cf74tF2C%;mJR$0ieJg%ZMBFyDY
zVz@qng{`ZFd>i~6{mpgtCBAL>IlgWAIlgWAIlgV{%3XJ1?+Mua9a&dccPTBz_r}P>
zl5spYNbs=rwTf?#FTRET=K8vpZ&Q7Jm2XphUC6hozLI>~)|b21!^WlF@5=hZT2Bg+
zBk+2ecwemt>y??2)ANNlT%Ac7>j)O|JM$uf3H5(3(BE7~zvA0eM^Er=s-p+_Hr3JH
zeB0KMuD&$m4p~Q7UmCinfa^;E<Gg0_P9EEyX7TOu#Z~k-*VR#co9gPLe4Fa3m~T^E
zjpy68uH5x3?*IB_U12?Ic*s14@S(h7y!RZd^wD1U3ys>gQqLhCw!Y@_ZHW2kZ?3O8
zzD@OY4Bw{uI*e~qeI3BJZGE|GXx#tZDeDVsXaniI=_`=`^B}{hb=1(~)X{XlJ-+w=
z`kU)$BHyMu`VYYm-#<Wg^bfvGb@UqFwsoYd+ikgv>gcDy7p&X;1io0e8z%2tF&m@8
z6bF=}Q#R{%^u7f$KEb1k6d&ikbYdM1pQp7LxI7G4Er%m_dy<Y__?#SkZ!s=3alcmv
zYop8#X5TGijJ3Bx^3IVQW32aBVbmzufd#WM&SEVLao!3T&jP#<=ReYSvXE!Tdg07+
z%vJZuIAi^+Z;^St6$S()mz|y_%xOoBtys@OY?}brm4Fdq`yj!DJ`>IhTec2r(kdBS
ztbwJ-do4!KVTG?n%+xiO5Pm{;ejUh|8=CkDu_lEWuLgW409J_cP1gHAO#MXqJ{e=I
zV>OX?I^-DRaDE~v%*K8~tSceTMSyV%@Iss~wBC8)hcojNL-)%#V=ZdrEc3X;%b;~2
zjM7i&POGD^F}7lD2(euVxNZQ95ZmG}&^W~pTehyIVYQ4c){}ZSoBLp&&^c(%tML}$
zuc8Co)MtqG9mIPhU_BFXL%hF7aPs%dEGJs?eHm}82@RB)b2&T`N=EBFNB9frAUEc?
zSffGA8v*YDzz#8gj$q}FIg96}{!qpo>pCNM<c;IbXd{m}i***nc`aZ(1@I!iq~9!V
zX1-+UfQ&QNW}5CU;Mz>UJVmUPAl@Z_^%B4h@xGAY<j-s7OCk@+cw>E~`L`MKC5kc3
zBC9&m3++ohE;MRiBGx+)^FF|P=YtgUD+yNqm@{88|3@<BSR*Oz&Ku@|d`UKO7HbxW
z^ElvV0`Nj^pGolX$C*7_s(%f|xe1QNI>&7IVx6O(<np7BtrbB@M)Mcl`88yY#yb}*
z=<G1R7g4Nth-(NpKP=;hwTs>lne)>tR@TWCFtP}92|wsaY%u|NB7dB<BC&=cu8EuU
zh>RW9BbvTy9w&qmOo^S-s>7T%V|a;m3B-%pXyaNLFRU??US~eudkLoSRk*u)<k4ge
zVb1RdoZmb&K4Tr%_KCFy(MEe8m2tzmLD4;#vC%-d=|}8rKxb^DV*Nn0(SgTg?64Lv
zK=R(vj|+jYGq+LQY5k~XjF(swK)m+atq9&q5Q%L6iHsNK_YE(b`?T=siPE!aEH(U9
z{6I9dS252=4EM1xocV-|A?EC<a&vnPFP#!Yz14=lkROc3ToiM6(eEvMQpOSU@PYok
zanWhPV*oob9~bTT@t?}rVQyVi$m<@gXO{(yjl~>WwBvD4$rxh3TvFic5nM1D+p(B8
zi+0@bw2UL>z#|2l1M~FE7&|c+M(kM3yzXZdJ9rEZ$!n*<-&4Q`judEKo5m;-;t(8z
zOW?2kv2(K>uKQtd4g>SK6nvxf>ALNBJk}N(frEp9CA>-`aycx9!1Xh@zwVu=B7bN9
zT-L!`po5{p&5@ZJjP)Sq$X<F_4?36yc%mN8pMdd@zaH2e_4;4Pdbk<#?f$~bw*zA@
z=G$J_Hv#VJ07Jz7*vrjqfcc@>>t*cQAfD(g(A=FV!PF0lxx1GRHUR#!087-tKG$R2
z!=L|bzGUOCWF1Vy`hDTn0hk(${g7A(@X|vQ=wJx&L_PeC;ODOg=7*Y|k@c_y;+e=C
z^ZYJMu|%2KIWv+lr`6?gfw32B3SQW60^DZ<hKT(Q1T%l^S$$&l28#U@ICdg@@%@rl
zz*yY(f1p0W6oNj<<eAfAeS+!ZLcmLmjl_Is(z7zQGlAEG|2OIu3|``EOz;)!7GC%=
z|K0ps8Q;BtyLdA_c#eX)U&P8G17j-IGrTZm{^0Q;8PmlOmo)z$sB<uIP5psb=kUUo
z)iI|&FJqg6cq8?HqyE9*HTDN${lg1i<_}W8lkt5X{A~kS-=7hGpqNLnik9kGF=sU4
zQ{VJBxlv4E;$y|Sh!>`8y~WCn6w{Nztzvv|B7AWjK*^xFkM#<o0?lV@W-h{<Ujj6h
z?20El(jcBOKiz8p7-pMZkTJtG01@(R3o{;ukx3cP>Srp#TtW+*sm~Pa8W=0FHO7(u
zl`+G){~?lB=NL1m)#e2!u?B%SF>Y0El5xU0{{fQwjvgn44?_9X-YtYZ>dvnvRseex
zYX%}_^IwuN!}<Qc0({;Db7Q9VDCYN~J@)-x#ti5AOTSncIeAc=#9SP4VrxK${vhLo
z^ZNsZoIf-00@$XQJB#=gy)5I0bNj;uo+C2|P3=_7jYZ$q_==1l&gqvFU=AD<GcorS
zIk)&#88e*A?=9pUmw^|+X2twg#BbfOj33V9_Z4^^%OEthSuuYVZFa{WW&CjdzPSMN
z)S#G&`KgH6j6YM%l9)!pHwItKLwgJDJq)R?WW24rjjcsD$?4sBD4SzUY>_d;JhZt0
z-^C!nW}Lsfb5Z_2=+|W2Fc&SoG7mM6Y~-Rg#f-7i<)iCfm$AZpwCIKcTZ1kT%+&w8
z^HFA(JKvBo!+dn)zC7es;p#)?X?zH-xpPuxm(%|u<AynDUxB=*L7<qiUF!1E`ESZt
zVP0A^Z0^H+%GHX}t!FJ<Q!NUA6}e_)lg-pd-FYdS2V4D?j34Hu4OQkg8eX!1mE7<b
z@`BKqgYMjv`ME9IWDGGk?Y%2+9CVJRdB#nbpHBOmj2q^s!-f0~2f_K7+O9i4Wwty2
z?=pUvpN>4AG22y)e-@e4m2&+k>%&2h3uVN1-8m|=-To07L(EYJ3-Emo0`-i2o;y!v
zYuP5fLvh2f81I|LznG_v6k49z-F7MF;%KX-@K^pg-|MjQ7wGftXDlwVw)cbQHz(<D
zcs^fwEuIJ4&avBSSlg*~TQzI@l-*Xv+K#c?Dp}jd?6wNlw)N+vPk3D-0$#U>x0Uhz
zUR=laE3@{a_m_%!H?E0a2{yCw?L8uWaDkqmQF(EWUAHEl9Wwzqa|;}^KfMlFN59qJ
zIeClzDRT|;`=J8N?=89+^KJ3I=<991oo8*Mj!&k)9ek^?+c@8jvfDV{4zb%f-#%=&
zalU=954k>GgY#&;-NyMg@?o~0&9@)hZ4SPP^$O%p5%8uFIDmZn;v_1sAK&npg>Ve=
z?H%D5FTSxk`r&`ce8aj(e}U9Rf^uxm)lQ!_!`eoU9YB9OIQAjCjdSe1#mu*qbB?`b
zw{ecWY`1Za{nl>d99wR;agGgM#jas<>>9hx!7;JUgB<GxuB-yRBgc;Xnwd|-V>ZJv
z$g!UZ$9Qp!ji0mMmpO*@q~1cSCj}foD{rRvHn8_1O|rI;YyZ57{F{SoZ`f^|YcJVt
zoNLe6ZJcXQ*lnC^KeXF8*B07soNN7ktS>g#TJ1Im*Tni5a%~H6W-{m>xi<brDzBeE
z!((Q_G03&Mgk!w8#@5n2zEkEJ*5R7(M_-!bwKVz+!E61IB0V6>b)?)NsBfG613I2C
zzHR$H-A2B>Kz}><_Dj2s^X*Z)jq~jRyN&bhyLKDr+l_V`=i6Mnjq|N{HR%`h#pc^*
z?KTJB#JVE#tqFLu7&w4@dyVMa`@RWw%vv}G`F7O<6cgmA7vI?US@MC*H>_Vq=HhvB
z%r|ExBrhCW^JR)3<JeMb8#&fPe>*rf&u-%!`;y(pId;0;#yR$ByNz?~IJ=E=Y{$8z
zPk3F<u@c^9bL{mmvHhGmfmn}4z6=6aw*HrL>}sNCe~#fXQ-LeUu_Nepd~*V}2738!
z<KQToce4Bw>%P6iICh(H%%>zV_UgVt$I>k{j$yo;WNnkN^v^6-vUAZl>^9E3m+Usq
zyJze+&bue<HqN^r+HIV73+*<}yZ%41zSz8Lwc8xNO{`-h@1_BNnt==G+s6Nq%Ii0l
z;xWtM806hu!ZBXHjje;5JWl2vd9G@K*UN*BtBE?N&zos&BlnJ^za2jBBX%3--bA~N
zbMN1^%pa9=?)}wn<J^1IZsXirWw&we4b`yo+1$I;ZgX%?tp6kTRse@K??Jg&RZZpf
z;~pMU1RO%{{Z2T>i+e1NTfC>tJ)CD4xeIxp7oX=GUBf%nQO9vB@1?fSeBB~z8~K)`
zza4x#$8O_%JJoLEeEXE$#`$)P-NyO$F}scPZR<VEui0a45pT2k_Tt@aKj#=L&YK|L
zrT}kd0|(I8^{k}w`tc2q>4jsEZ~N2h7>}_#C&+vw&)K~XbC!(oO%d07&M$<UTlKh#
zj(Dc^-f`cj`5WWi=GAl?dG~Yr+rhg>>^9E3`|LK(yYJX-oOj=_+c@v8u-iEAX4!4r
z&!rw9{er&OysNg`9DYumZ$jQJ0sgE5E+Fq-AiDRD?eLf#a18RU`+kavU;e<x*oAw`
zyd%#W{vG<*yzow+wfgwH5Y#iS{Z9U0#KW%rZhMh#BlljQza8BBrQOE4_o&^*x%YtG
z#<}-hyNz@2M!Su3Z?4_Ox!3yw>6e3hpS9Z@+!N>Nkb9Ad<01{f2jt#sMF0NW!(-BL
z407+PjT93<?y)g;>xX6Tk>@U7jOWP<_X3Tv+2q@nODUGj*FA1+Bj4_(za4!0mfgnr
zcCFpU`F5Gz#`(6uZsUB5+HIU~)9p6Sx28)-KOKBK&~9_^O`P9EzAXaY3;+j^Zx0il
z`|}Nt*#gHP-@dSrV&um+RtH{gJ&|GE9&{cR|KdFAFqy|Q<C|AeLy^Ri!kKdAjb?NW
zbAD-DO<$5q0zNpdmcU>6<D5rr|Ftuon`vz$*Y5l!kC!+%Zn4`qH<s9K<#;_j_A<Mz
zjJ0*xZG;>6uH6`Kt0V8;ox`_l$@VFHo4$Lko^R84uN}j;>ATlH%D3se*Kn>>oL4;*
zYHR<7w%aGeeezvx9qA~1lk<{Y(b9$3&x7ILx52;nz;BqxZ*5x`ZBKU0OV5XGd=Bsy
z__y7Q;NN121o(i+;n4QJ<9w~{ov}2!hg2t?9!`tL;X9r#JCdD~o(q~jKp?u3-97E;
zNJLzpK6`)aA4R_6T<jp38_Y3Z^`mkoDQnEx+50>F<5X)KdH1y<?vprYd+avO+4*)G
z=j@m5HqO~I>^9EX6L}luY$e~Ooc#pfrkp*PZ&S{Gm~T_g{)f-^+ME^VX2&{bSv`9D
z0WxQCKDX~`^dmXutaCKa3s0wB>-4SLme6hF=~>svzV&3gjq|kDZsR;X+HT`KJ=AXF
zJT2yJl&9nPHs$HRh+gnLmXxP&@@>k~m-#m3>2LV9%~NrHcdYZ2#R4m*$UMb4;S`wz
z9X(GKv0+AI0p0mW8w>2b#hGJou(pw}<=^CaE%&QO+HIV#Q|va**S+mF&e#9a`DTnA
zIbZ+5+bCbR@NLT1|K;11ufOKol&??lZOYg0^KF~2;vDf<=PS#V<{l#R73Y<k$ee19
z`5G=32ufMwSYY#m&RAfzwT+zJ?}u_MFy3zCoZUg^rjd)Bvv1jLoU^akZJe{u@ixlY
zb$pw0_7T2KIeS0frkwpQ-=>`X2H&<hE6y{Ib<VO_Aabb8S)7|5A#<cT=B#-vkTsqz
ziaL2Z+uBB+K6IYU)4T09&eP>~8|Ufub{psE<#rqA>4m(F@-)G>DNoPg+mxrL@omb}
zPxEcc(_{Fy%~Nr%daU!5&2O(Sp*-CV^?(B)7sJ0ezn$7*9<%zCCKaWDEY#jTuHqFJ
z%mA6?Psx=JLE~PLdh*_z10geIwWt|eoiXjsH|&^p=4*0Hdz{_Id3?Ct#(8{z-Nt!5
z!EWO`{x{JJ#;labf8*Pf$A9G8l*b$SHs$dz`8MV8BYd0k7;}Gd?i+cGIlouE0Ou5S
z^@2_CZ|-`*pB?AZ*9$)S5of*N9XJkw5bFi3mcQ(XaYT(Gk8!@dpUmx=`P&ThSRW~b
zzmSf~Bwh&0<?}x6^vN@<ZS=|Q^|DWn+HIW6XW4C>%O~4yoXfR#8|U)Typ3}CP`*vM
zT+FvAm&fsK%H@CYd3(y`H~6;AWpOTjtaF*gyK_D+a~bE~hwsgsPj*HSV}!pe9&q~N
zc555?yLy%Ei|?@8IDc=p+c<x(w%a&=7us!{zZdW}%HQ+(Hs$Y`e4FyOk#AG}*6?l0
z-%s#uo4?}R{8;BNiz%iaCG!{O^Bc$<c1C=$B2LXhOyO}Aog>D1hoF9V=YXs3U~MCh
zC;dRKJA6Rb0${$zdHlBB#(Dgj-Nt#m$!_C3eulSE9zV&qDUToI+my#E`8MV8xA->Y
z@z?pb&0}${f2{ME#S~kQmU)cp1DeQucwTrMI;IFg<xnxjq(3-gip{^L+sNgqo8*{c
zU%QQSd3U>wbNQci4FYnWb9t-X#<~0l-bT6nEZ?SFeu{5XF0bL+l*{+>ZOY|u@ok&S
z;@W|+&Se%;tU6ZaGOjl$xeRrZ7cK{iDRRZ%&6iWYvV3o~wT=AUMzF%%tBluxU$xsf
zf1kJ8IDda`w{iZiwc9v<AK-12zqj*k%HNy#Hs$YPzD@aiG2f>AoyWIr{)%f6#yWr5
zoW-W&D1W;l%bN(_PWY1b3s0HH#9=1Ea=w1y;<f}%wqqPYB_?UD@IU+gV)#y8ac*Cn
zKc7@4<3;Ar_cFKljNzppwZdFN3cW1Ij4>1EmJu^nv#l(bF(dQ0y?Nl6(>vw`Cvk2Q
zabmWZsE~0Y^M~KSSk-JS@e)Yk>v4DWlR!eOCDNT=M=VoY6zA4NTU=f#<3;AL3h?=4
zL2Xf-+YxPXuu8^^%%7Z{8ULl@fYRTa+oJBYI%*mFEOBlDabmgl&T1JaQon!I+-HR^
z=P1$ASY-IC=)g0zOR=7f*s=U>X041JsTo(Ab1b}6O6>F_W%vu};4|i)SVI;4TB=UQ
zkJKse%p3QdmYPS*#JZhmudC~2%t&plke@{sFs2o2MWVfK`;?3wsmB!fbI5{@sbYOX
zwAYeP%lMHRz(pDJcZ%`PGD3Cq7RX*bPCjZMC+5V6*{zYHVobU=TbNCP-{axC7kq1A
zE~f7>t&h`;e_j!<V)B|qyd}ri*8@c9B)qV@hrCP)$2{nQ;zRR7vG2=|r}`HAJ_0qL
z!DU)~hv>UPE2HT9Z5HlxPmueb0^Cbq3X1z^1_3AfCfKw7Pic_*|7oZl4?P(ad!PO*
z;Aa-+W{*k#Z?N#+py>aFABQ=dOSJeqZ8<Y^CozhG?9gQMo%Ol*L>cpof$#mF*J5to
zX9dn0nj7``W(()qljJ_X4><R)FvQu19tzK*qeq~Ak0|>6G+;g4X^6E?zZGzgs^527
zc(478jCU>gmHr(2^K@6Nqq{8)?<I()V=e7T<hY4_GC6u1WjX!<_z&gSw}+ME9!npy
zPnPAl5cJWI7e6mcW1<r#%aqT`vK$XSe>g8bKb$Nq?%Al2<x22NO}X*^Qs+(d!1~^I
zimZo)U>gIu83#i3{dUV9=FF1&{%^p2AeZBTB!QW4VlqrQRhHprfd5D?$A*wHoNMV}
zoh1XViN*P*ec@XPdPu>2iZH^d-i00ST(AJ#c_NmM%_N~geLZ<aZ?roNH(Jg!pVK)K
zu9KeMhErYS85$GdZwkKd_oB1D&OMFd4a+4-U-yT<rEreE9QPG-kMk}3MihPeHS}rZ
zTSoY?vEB_K86&B*Af)5toEKXsU?}#h|8#n^sMlv;-=RG83-8@V-ChV^w{B0faNIGQ
z_O~DQ*%Q9_cLdf_4WF*XG2O}U>7`FoLf`3y8Jp{FnvLhA_b;DBe>>*7KV`S^x$a84
zjn8!-W4H0S?vLATe6IUryp7IvPvP5iuDh6T)4A@w_%@yE-h*$`x$d0=6P%x?bKQvT
zv7lRa12gh~z58U^859xGW^g_^^_&*h&YpCtCml_7b;gt3-JM;;$dy%GFnC4WO?-lK
z{}5TX?)<b6f;YiO<FW2!bS_}vr+>UZTQ!%==KJP+Ud9UNlA8|J#`@XAN?#!lmvLf}
z?1al0FZVq1o0iQkY?AT9dE}D5JaEfA!wo_yV~pH$$jts$o+)F5bI6hJ7Q!5|lTfDi
z=bk@i_P6mY87rJW9$uRn`%~oFdS4aJ{&bg6xhrFCx#y0V{q6XIj2F%w_qOH%FLV3L
z3P$dEWA;9h(l5#wk$L04oBJrA5{|;3u&^%3C>Z`KDsq|HqI=Gm&9}FoE#pS!j2q3l
z6<#7GZhDIhe<2lg#&+qRFJ^vh#W^x|WWM;Jym8KHoq58`Jy*<ZbmLqZFEUrW)_jcg
z5lP{5tRvL(b(%;u{8dy$Gqq9oJTbG;qH|^3$UO0%GG?PeaSLsu9v4zUXKbVHIbvp`
z4PTbABXh*p<PEz(HkvKG-1EaMj-CHM6tBNR=(;z2{{mmkBO@EkeOj2rML7~^tTW8{
z-Q+qKL_)j7oLc@kYcJxO<kuq;itj!e>l^W|G*rS8ZJkk?9M;!oFG<WM5cT!ZXnT2m
zJ<i|o(jIxn*$!BbeJ{w$>U~&mV0N`UD)R($=;6ucb`?gCN}lMwQJ71psA9|&F^7H=
zxbi^Gxsqit)O6u|`M!%UEQcA0$$Y^Y!oYQT@GDLaoO6zdHH24yBe&(8BUu2zhZiec
zykO(arnt-ttef<G%RDCZQlMh|#N7i$gJI6Eaw4YVjaWCq@#cNNW7Ol#m;pjf6s+0e
zc(W5^RgE_jT4kPK%_#Mw%#1gI;0fnqb(c_4#dy3CYeqQUJezZ_WEl)KUHEu2<l+k(
zZ%XFNe8HMoQ7jL9F?Y9F;fPo>!|~>)Ip;_g0Px|(Q!ZYx8btF~WL{vMZ~zh=V1|*K
z^{EbwxjJExTt}=Ez71SiWg468a-gUQ#KxifUGWO5#jI+V`GfV+;p5HyN`|4*JK*pa
z8r7I2)=S?74*eic9LfnWY8vtJX~4xJmOpRmka>i)<C5>^%?~-9be^~)){Zfr>CY2)
zvId3^U+#4Ag^gQNE|mF#we#MG%=084l`3Kn>xe+vQuwQ=oQ`SEB-YMx-1?7cj1#`Q
z%2Jf3QWyRz5-4f{v2p7ISKPzKt>$i-KRAcbw>e|uR#5(gcF!IclF-81t|^DaIRqTH
zHsy&!IRQpZBR+2Z-o+y}ZuRxZJi_^u=H9&VD3Ghp7I(z?6dbpHo+s{P4GbT?{L;l2
zR^Quj5#`ITcc=47zkt6upH%d$d7R@_e^Vq|8LjW>&hK_KG0V?1%9BaZqMuLN2kKsr
zL)~jVV3J;tf+zFZb1ah<%Glu?%gBM|ww5vM^iC<vB~<VcKW&1aILD&GkJW%0E|KxW
zIfucedElPYFmsNXIOm|kjM?j=OJ&Tk9^e0M^ElH>IEDYk-2+9KVa~529L5DEd=u;O
zD(u+U`1oZqc37kCeK<4r8VI{^_Nu#t3O-|d6>HQg{FuFtERylVnr%ru5BQneYgRB5
zYql!PSYB9rImPU^*7*7i{Ka}^(Kd4*=aZZ$hCu6xKvo<6Dk}1s+OAm7RN=_-qs3Rq
zIAUF|;Y4%pg_ls7O6n~*{Do9d8r!j0*HdB1{NTD?8B45f_5Lt#oOD`qp70ZETPpmR
zO;7roj33r|hS!*n!9F4?e3o@YCT-f|Dk>tH+O$~fQQ^pJdhS&+j#%>;c_m{u?IB@i
zZQA2PDkzO@TC91fuw*v9e6frr=KX_T%Nv$~Y&u)`iFv;YKNeT7yPD$XzCUl^*XBOa
zEACYc(ix4bb?0}JFK*?*R9bg3tj~kRym$LGGFF)P_L293n$6K>3@iO89Oe=#xQMNq
z;3ek0h!=~Sr!0~2!aTS6+B|T}X_Yz0NX&B)BW8b%*UA`SUfXc1`Izb@jKaU*?tw<r
zFy~hh3dd0sK8bm)Xn*PJWUMfcEqTb?*N2fM;D{OK5-PZi?N7{OMf+QRy^I&;t%Ky9
zaHIEEfw*OEf4b9-3L`OZMT}TXJG4~Bh}@sI)!aw<#I%YbDhn~K$5m9oncAY5ry_1F
zhMjbSj2pQ>kG$K;j9VGTO+O-rzmN(#W4jddQqhmiyivvu^U&c3^2Rx*b>;~#F%K1O
zG~FlTMefgg(0q*a5lP{5tRn)Al;N+UBATg<ig~AKqXRd|xRLww{$M^{hL<Sds2To3
zD(H-DRLnC)8y&t`#*W;dcSYW?3uL1ngdP=MVqPiYm0m{iIvO5qvp1wyN5bDzz^4rr
zS{@lC&zd6qn(9s?$+n$KZg;&mgguAI{fwytBYPBY0luXG!*9YlKJ*NZ1ChwV*7IWU
zxkd17VtCRFMDDS8I@yKK4x;Z1#dm%JG15Ko6f0u;Fh;*`Js)M#t+Gzu0-X#LV7_Xp
z#aJ(5&g!L?g`krOfFtVV4T4*Ey|DM6EdQ3QmzyCk?k$kKIH)ef+}KMOMWBaefF0`M
z5rS2CU9kG$jBm@jXoLK_xzO_OfPPEN!M${{0`xH*Fhrevi(nRBC(LiHyG_=~G|2NC
z3NX(PYAa%{@1>Vg(8(a+h<dr0;1*sl%x^WVkoB?z>IuUIQcnn~3$do)rHl2ThuMG~
z>f$5K7(a&B1<SvSZl}69#EQ2LfWKE@ExM5F7J?5e0Sx7j9ea&H>?PJNn10;Pfb@#7
zFfN+|dYc4T<NN_Wbb{#)?+N`OJlwLqGahS?w)C{NVpK+-BRUNKhH=?~mUvWrCL+dX
z?439p?~wI36Kit?UOy3StONm*K29BqHI%SAoDBLK0=!X&rR07nYJXvM$i}Iq-;;H?
z7uaBAb>Y=<g6d7I<%HGSCeYauz!>$GBAAX&Z_IbjzDw5IVvP9;xt<izcZxNou=?u*
z-OU25QGY`O+tKNd`Oc!dW&NcfK1>yOT`Q;!inXn<I&1>{O#-}8hr<Nl(dm%+&h_`m
zI(#0+zlH*=uLaecSYr#Tx5=Qhb$~JIZGd1pI=!*^>h1SZy&VSUoe1BL!k4@sc*uOr
z^O_)4Ok?5hfvWIf&hIXYCO|IJ`n&iXF0m#$?LHYRTrV<ska-O`j4S~w?_n;Xg3A~$
zvG#^|vGpRe?w9ex^&)*Y=7C$zYJ1Kx5^G|J5wpMa12RUqUL>``d@jsO7{$B+?w&FG
z)16;MC{z0rYgMBCtz0c*h3iF{3h#N&32;}&_9xbmMEhI+eHkxYFEWzMjK9+9Ug@vQ
z?N4`F6{U<Z5^Fn%5nC@3`Js#vt``~po4Jqjnd(#wfz}a$tT6mlRKS_qqF8f5+*r;v
zb3n!o*NYSt_Vb(r*`-+P5dB#DgEDrwUZkn;p6470FR{iT+UUxMWV~>_$iO4!W2BGu
zD11&9Y}Df_qp?vjw-;@6_(w8sxL#!NkLLbA!?=ZB(-jap<8eXEsYM$tdRWE|*NgOB
zoj2^9BWQTVsHkR)mzc{UUM!BC^a#akvUPtT{v~;2fxQ=~!-~tMVSpxmXsw&Q7i#10
zFovM-g*t-%#`i*%;bHql#ux8zx0PbsKG3!sZ=>&a`p5I+9B^DMStGL3wFU+61;M)a
z9sqv|&Vh3rlYzS%e>^VI2iwQd<H`Hbw!wbzYO_f6<b|oO=tZ%1_>DSb$4menegoQS
ztbSvyVvFV&(N-osD(jx)#fA5tBUC@J6%+lhnTo!G>Ut0Q+oAt=V6qSX9oxA6|H#{@
z{-5L9w*JL@Tc!UZ(BsCnRR8<Z<9+py$4me{qW(W(_1jPXEYFYpMAkpa^MQaMq0zGr
zy>eJZ0IknqonA7`Y2E%Ykj@w1Y}@?rZeq4;+x*Y$Hm>src^lRF_xQH0bFqG))H&#G
z{bN+;uM*tp+@+Vz7r`+*;TY8U8}yolCtfzs{Qb_yWu23{MS;DCDu};N+=1~Zwf7(0
zPJTP={VuzW>;5L*Ms<HB-?nux)<aaf9|!ig4)g(PkNlM2@2`72W(ORDy8k7;rmybV
z8mpa8%DN|Ym`BZHBQL{L#Cm#r*GH6LE-@<GZ~Tev@4xvN_w8i>F&Xc#vfH@+FXU}h
z|1rL8>tC$zsPrFs0`w0$LH*xBbl|UlJZ1+RgZjUhUej0q%-@d;%K9gDrNVemSRjAD
zWxlQR3i{h&^GDciT<68Sjp}?izHRGVtXC;@{?l=hwV(&o`3duAA8@?(^7j!qW*Z!X
zIzNS8(^u!LPPXG|S?8oqR>1E)3*!4X{=**kkD$LDJlNlE<2=}nw^1JaV}!*EHV?%5
zn~De9L7#)58|1-p^mw9EFCO4A+u<1GL5<aKzgUme{l@)V<^ieuos1kbi}id`S4Ftz
zS&Pw+0O2n*s&Qc4DYj4e!e_~E2NynLw{b3%@ixkZ!}zw%1+ku};=)eQ>4tTb3sIsE
z|8W41iGWU#3-jnTeSHFp1IGPQ<^ri>{s?)T7cMxX|2*lx@nPE+d~*%6X*&nF%5LNO
zzmT_CaRA@8^)J>(Rr;R*dfe~}D-Iw!@Yg>c69GMvIDlT$SO08GnDi@I|D-Nk!0*`$
zGA68i%+3eic~s5^{%p5#9z4g}C=Z_E+cpoxdasfPpwEr#DGxp%x-j4Y95Vs*i9Gm_
z)o;@=VahWy4@jN4u-_XPC{A3n#U2y(puZhs!aINF;{@lzA9)+)!gGAv=7LziR&k*S
zbUOTN%7uOD@xJi^9y1wqid^`J)o(v8urXoEZ)7fzy7@IIUq;3RMSAEN9|Rf`JWf8U
zm|*b|TmQfNI@fg>KumJOpV@6({}1vus{iltZCn3hJzk~%si4Q<4OIWH5*_&a0z76i
z=n?h*2EC^5n84~njn7j3SHZEko(u)Vd4SUA%wqzt#9a{_>T3g<hopx&zgzj8AeZSJ
zx^6vL`nNJxST`>^*xXja$f8`Ip^u`&TtWqxF<xSQ8|N8V-C_BVj2G6KhYMpp8B)p^
zBe5PV&cm&HPR0o9vV#S-o-By{iS<))-fH{vGFDi}>@U3aWP!LP)*D6po3c^H3+sLj
zt(oyxim_Mk+nuAjmygn&c2qt}tj{4vEGKGuLB<H{WTk&MAOFIqtxC_X83n^%MFpJc
zSSZ%B5I0s=TKb}l8`hPY3wu3TAiEUnKcXLd{C{QaunyB-c<adm;U(5fL>t|{NyZE7
z7Lfw3TOe?zHY(N^L>n#ry^I^?`9+1D=Lh1Pn2(D#+WZF@JIsrR3vWGHAiTu<74c$u
z<kHO)FL+HE$s@s?kvwvs!1Bmc0K3%Xk&nMDV}*HSU*YAE2$!)R)8&!FugG|j=h*g{
z$7o&wXP_E|c^s=dtvehGgpn?foHQ(BM4n??VC#E=*q<(socTu?EAkxM!dnj$h+Dcm
zviVOkUgSBpg^@=F!bq1#F8{NP5$2Hte>eA0;WNDa<dH#aQI|(<+#=(KdE{_m=aGRp
zr^_S9y)I*id1Oi9&F2TgOP5E^d_%?y^T^%;&Le}^s4kCOxK+jt^T@u!&LabHPM1fn
z`iqPm=8?^XH@_MPFI^rv@+QUWEyx@2Iks=W7w02KHkgm28H@EbmDn)ncL)95R$ep-
z{>mTw8C>rBhwyo6_*`4^e6!fXwgo*49M3po^ZGNl$v9$;IRp=?ga2}Sk4JXrDiKPO
zW13(o=9qq1vU$u!f0ePs{Imc1Ja97e`DY;f#Qf6_KUN!B_cs|o%uRcj;~J~cb5S>8
z6eKG4vT5D<M`P1sZt904v+1G{8Ar@po7ZH<rgd^EaSUhEx=W~_G`49mZ}r2H*>uxC
zWGpeKjkM$eOLLpf3Vvcv>xUnkH(mL*j34H^{coE4#9b}l4Kikn`K}+PY)*COJ2Ix2
z3lE)O&dCg8s<-m+7aEnVi@C5LuFP-F`lpO5=E+4r$QxIk7M~|9#XQ*$OJ?^g-j%V$
z96I$Q^Re7VT!oLbj>zQmcRa45A}G$qn#7l44(*32v-|D;k}<{ny7%Rb*}aFf0Y~@n
z%2UB=JjRRpwI8m`?i=2damC!b>B_v}8p!TFlr}0X#oXHu%YAk$D#rZk@%Jf~hr{oQ
z@WpqpoDM#8_&4T0)GNl;O_nLyna#XB8t+_?>PaV~9kH&i&Woen=`Pd*dycs2nhbI7
z7crgyc&T!BT&ItI1&b%qC=sk3ev;>W>}O#=bEk~`-vRr<1I>AyG3@mbL6}QOJobS<
z)Le2{{Mqx42mT}D|80CO=F&WH-|0cd6z1;QKp4(5e>39)8S@1gXMEc{&hP?9;ahR{
zKoLfm^9LooslRd86T)E6{LSjfcyvJ#(brFhc%<p!%=nu?*oX5sx=RFw-`L-{YY<`Z
zXa1&ScNzbs)1d}lAhn51`FMBTA`IpSTVw3FaTN1Qf%iD?kcRJ7Fvj-5L<F$js9x?9
z8Y@DaEaWvFR|!gf^gTs@gZ#1QCvYypUF-1E!-a4{G1kF%>EZigCc(wX`&^Rtv(ixy
zt`H3FZQG-G8rlfx>`eIg0iq*(9^2l<IA3xioCo76vKAKBC?0C*c-wec#|>atgAL|>
zEyFt2d$;fx3aVz}<4pAIuD#?!&l5n$TS0HA=V78Jy`I_lwf;l0p7#M;j{Gohw(N}B
z#-MK9wV+(+b_Ddg4s?aOEg`zm>z4WH)e~jiE`hkPd5w8o=mWnZcCd~J6di`YN>Bqf
z_0#U!R4#P90ra~HbcQ<aB|6gUnEB~td&@dbL;RU~C1ZX%sE$MXX^#s9RkN|5cGt>s
zq2~e6aUbXn_1s7Fq}Ma^)2R>3dVX;_+@JWhyy-cRpU#JF-L<=1=yo~iwH<VYx@{)9
z(d(AY`LEcA>h>dW4Au+xhcB+<DSFO)4ED;e6=7~h^LO3(-A3C3a+&7nVogxI*J#7O
zGFG@&XQc4nQ-g3B<0Y=uLA==9{Ya6F7p}({yfF{la(av~lvPp67$dRfCf<)Vbw3#+
zTyxW3V9yl@Vt-<dOtin*`^#A2x|-g?d#*qr`x9$gqWz^N%Xs11nUcb|A0!Y)Vhsv0
zV)Nvy4v;az^)W>Sd_PDKTNG<Xh#Q*=-*TXg8?J$ADD3+|0&z~P!-#%t@)Q|6T<6kT
zc+V9GgqK*`5N&k!K{8&rmSwnr-%}IBM#Xx8XroIGmT|-NDkFvco|-_M6LWCUM%Nx9
zV~1-}1`F@G0)g-n^IF7<<&j&a%6MTO*;inB<iY@XkuHy%e5i~S=8>twd#(V&Wt=1F
z^2pkc$#`KN+0a)Id1N4rba`Z=M8*j7$dUqku0Rm`)8&!N4wJFMJTg*v&lL#7EnObD
z_HY?5%p>~?BaaM(kuHxMIYPz=^T@se&Le}^qArh|aiokJ=8=Pioks@ZoGy<%@8dFd
zm`6r_WIitX%zi4$>z;G0&MIs8le=rJf$-Ahk;^_I<Ar%-a{)hBAc&3X^2nj-GH#eh
zrv8+-`M+Gu^9JIaE{}|SQpOJR$cDmuu0SBX+<D}=5qkf^CJV27!HwbizVE^Jz@s77
zSm#(b(v|L9SYID!tNw91Cl*g9yQ1BlJzeqSOftt<U*FR)FPSF!hsixbyTNtR^V`UM
z*0@G(0$jTR7F@-#53rVP9Q17?e6NM=wWL4vneVu^4%ffA-~WmE@%ffqYmTNo5al`^
zu2=HYKyoqX%S1Dl?I?w8Rf24rL9PMlBg$4w`s6R$*_LdLGpKC)!LbwJyAOP~ABoQf
z62_r;EIvP(h^Eqs=={#^G$@ZW%xvpOACJ;>$6Ay4?$n;7alZH>T!ZNgv2L;YGpy*(
zhcI6}*`PnrleT#s$wWzeXU9Bu&&+e#_gsBrb&{#ajt6u=@9;&e4u)?NjM=FdguZpB
z6K$Q*&Ym>f;8I^t|3*_?o$+LMcV`zNxAJ})Sb(V*uyZ)y4&Wuz(bo3ZJP^xRk7AvK
z*<A#<*$U?nYfN*Gld;<l*fkw$J`RPM_*G)9AA!PLg2p=ne5Pv^#F~i;yVot7SW+ru
zcRScb$+A4~&KV`<6fd!UqQZ;W>AEr*uP%rcBj0oQ>(F+pSd)}dJJp?EB3b}D73(Qp
z*hMO2?2b7K#)HQ*W2ZXVGH9o|OGxmU+NoGuQDMjIw6s#j?k0#Ad%uzg?9A;n<9La6
z78PD>{(fPVjMud=CN#fe?$^SnsY=Fa?s^S>6^V2KY*wthc;Pr$E#vrE;9cJ=bKZrQ
zP>G{{gbjZo2})D@6>Bgm9ND<Bvqr{oGVpQe$9dzU(~9$eomh`iVaIH_u};SB1{iZo
zA2%O!eZ*7vDeH)w-ZLNsdI4-%tj~DixU^oz@lqIn8(z<tEeFLhv@LsFD6}n$wHg(U
z%$C=GO2%<B_{5^?@`hs|Th0b{V%<iC-R)MsG49h8JAjJRaiH84c@+F$<UOq))N>?U
zh5%KCR3ZjXh-hs~wkM(&w<Xf^NluE-#E?Jsy^?ru;=|BaR$IVlKVXd~1-H5<JD`Tq
z2}O%!7kPKz4rs^cMUb;c+d2}-g``%r0l5Ph^uvYPh|IK}qI-Wd=D7^JhT~=I-p8@{
zTUy?Q!%jgEl7y6C-6K49??PWkgWUwcZ6;uV*u6(&_Q&oXi+77pkg?kz`ZIDw2<&_Y
z6Gg3s4JH}{X-&k0fBPyhyf6U&8UepvzydM+(lnIa9K-buGKQzX_|gAV<}p-IFk={g
z2KwygVGs<L0DkKL3&e2Z(`FdnZ1Hf}i4?<Wcr1KN;JX0oE&Wg>hcl_}Q+N9I4EsEw
zj^g9=d2P@?h8OxHCQI{4vMk-e&&cPsd@z?qK>$A=WFkwaU_U6!ZI)gtKO@WXF325O
zVW^iZ`2-W0-gfDS$uyx+mgz~5zoFAmKRz-kRAgkMCNe$d($i^{o|alN9SW*J`@uT-
zLq|d#<Rn2)(wu@dXju;@FwO1mhx3ZOKg;UFjFTy@*TS{;hVRu@ANtMv5bbX7yciB6
zamNJwA$^=SDE0-Pw}A1*D)3`CZ<0!Pk$O0b6WTvZ`{$0a`ra2Xa?T}$ixU(Bo!drJ
zUCDS`cUvcWkGshjXA)!KGoe_F#jhd6S*4((`G7+|;QAhs+kc#6_^m!g#t-AHl5cD6
zCLDeW1Ih$`CUKS@eks6i72tsQT}$Nl$L~(dK1OEA_+hNodt?awe0-3Cf(jqR8Dbpg
zo5Wdu7!Ck_+W-s1@GnGma||m_lQG0ttMq4?$527Tj9_RIXZc~c9q=m!ED*zQ6WRSS
zWbsMlbc*3LI2Ol>68K`QHI$=R%VwSVoTo0<+MtjHW3AF0#adxxamQM>TK-|hY*{ZD
zYnA3S*0LosjR)Lu7L%v_bFw@bXQgr)X9btX9b>WhW``vY-t&)kvoCyKITG~KD8vs^
zjOAFj0Sh+T5^$LDT>r~(elgZ!>wcD=L9rG4vKw%v<Ya@sxYul0y)xBz#1&VcWbt>x
z=V_mC+85(L*e!B8^uPCbp-(ivqAM@z>m7JZfc@o<9q(aWa~hma#N&MH+8eEF-vB4T
zYhMT7{b3Ey@Xs8zaKm*_q+3u5qk8gN3x&0={oq=xU%2*Z67**XzF&oYyhZvz{WHp-
zTl>V;<E(6=IEu1-3eMmBWFT4CSY@G1#38&hk*D4z&nA$iANqyzTtNC^F3;jKsXS}o
z*uCNV1NeR!$kBU|#0$2D$75xVLmVOxloJ&nn>VPRa|O<_I_yg@079NX>W`~HwqEGx
z&2XmcNx#hHOPnRkw*{^@{Oy49DKv&QX(HdBedJpLvNc0LQNFiGzs%)p`~sElb~qOG
zw;aAP@Z*E0Yhy0!(RS8StXLwJf&wsGWoTO$wJ#I-n&EoPzEt{~53)5tKd*<rJwy6s
zF5k2{vV5!Idczk4ly4OJd%#D&Ss+^p^b_TKi}cH1z8|o-;)_(iKf|%8zn9_r2dLNg
z@2-_ET;8TgI(Xj3lpc-2j6ip~vnv@*!6MWJNnC{r(+)8+E~w@jCV)IIfjs<tu+5%7
z{WP@0O4puPdo+DXDoNUrZ@5m?T6jR(v34*S+K&Z0V$Z}zKRz8WUk>=)2mkgw!Hb^T
zYYi*IeeyXn?vpWB`Cf)`S0pOgz}=lcBkucwJSyBH&^{X6`vLPJzz=b6A$a-Y{$q>p
z%jQztUxQ<j@2|r57_hItV?y9=*|c)Sg?f}?UI6Db3|Mc@dw1@Q_#X{&sqjAt+Ew`D
z8fFvTPXX-v07t}s9l^~U|H<dd_{V?`4bNmAe+BikhQB*+NBpB8mkR&SLHlU%Uk=z8
z0gi}&n&9S-|1TK-zfAF;wmap23H-&m<lg^i<B=@;d#lb2vm7wJ97{)AlJnX+I*9IC
z>B|AqQS?}V7|au6%oC;_im|mk=e$Sp6u|L3zy#x$M+pWtmhSy=?gRZk9@7WMtcGLO
z{ugnh$9T<0GyEt2kBmRoNsCs5;6K8mb3O|4tNng<@OO^~I{cRdj+@V;_@7EJ@W&sI
zDFPf3|5@Kf-2Cx>mc={g%lKoRH8nj1{u%WD!L&ff1rs}Pj|->=dEOQ{4R|I18?=M_
z2o|;;-1~DofMb@!F{p=CM+MWvv}RckSgS4hMdtOOFa_;6kS#s9#|NDr`T@^vQL2Y8
z5iI=mfX9>oo~VbpzckasW0pNkiBUaZy=o$SF($%#Z^<Rv@xXjO+BoJ9hPr7j%3T*`
zGEZueWyZR2Z?@~gj)*TiGP~=?Pg{DP5SL}f`f+b=>c^vyocg+Pz)SgK*KsiSbJv=g
z?Bf!$>{x3a%uTI1C$hWi(v0gfl2mr|4QSh|;9Cvx-tePZ`_`<v_X;*b8#*ol?Brn{
ztqd8}?NHz4AP1}aU|co<^gJEp{SL_Z7Lm{Pow~Xz!)Z>djMLwNBSp)!<538l6eE#Y
zP&O)@-U2y9oJs+sCXg3#I)upQj}x<{#q(sGIx&CP6qHX{44#x|ndj0MxOg=eu<8Z5
z5wGisoaT6~nJ?ot6XTpGgYwD;F9o%XgPc*~RSWWn{8|E74S?K;*U>~yf4rV#`RP|I
zydbDYf3+I^Vt!imFD<`voS&+}!k7fiO!1*()IO0(#rTh_cc2_l8;guDexJw`nKt{3
zvI_h+Y<t~qD`#!b+ihj6?Mb_>l(y0Lz=-RBux_~p{N&k3L)|jgjV=(bv3K!StF5)I
zi!`F|TnqZ@1MJJ8b7^{R@@^T7Q_q3p+u&&2uM+lI3g2(Qxh7k(U_I3<_r-jH={Maj
z>lgFi{#&&65Kg}edl-eQC1a9_erH;1tWlTO-AZC{hkh@z+qiyP>^837Gwe2pe#N|+
z>GuJcRCVhY+eG~?2c4w=d(`hZdTy@Y)vzzq?_}7g9logFmDYYH`epTv^EzbxVtySt
zJcNFIT%IE87_G}Q*7FLo2A<mNn?yFJ9lvO|aXmk6w{boHz;1KsS<Ks+p1-89V{8-k
zybyFZ7j%GnPSA66J)bMs@y-R~BXeLs)blt?mLPg=Ov!r2{C(i3nb)(zlyj!%*<_tQ
z)$?tGvOQm8w{bmp*==0U=i6-#J&Sb#rsp3h>>1lcJvW2y8bAlA=gIWkT+crg?0HKk
z-2Valp`O=R`<dwZA!|G?y^!iztPi9xZ(OJyk8@BT(2v0;d15E@pT#RUHZfVJcFD3{
z1iowd3@xY4WmS-PwBwP9tUb_wQC61k6m`q8z6ZDrL(m4&`rlKLC*N!$^A4AOnatzT
zvdm8bJ|$zI4xnbVdF^A+rRV!C`<>cDWgZ89VsG#Ppj;A9m+aK)Ib6J@7>s3p(@7pk
zoXLcHG#=}QDIeo}UyN-@z7P7G0`h$i#5$eG<DX|RTq-Y;altrr;5MzThr`9l?nj4<
z7!x8cC4fmO$cMQ6fym>J3-f_<E|zh@_^s#@A#ll%k5Hpyp3jT16yj40*ffEhh|i~p
zT;}+s7s~ix+%vc?^Y|#Jql|k-i;ozCAU<;en-s{2_`F5r^2dkW2QvE-ijO;9h~#WO
zL5+s#oPj$wU~)~nRF(^4gXWyg8H`RYcO1a(@f~-WEEmQB%{iVIP)lb%{<+6|Cf^o?
zd^qO!=XlH?t$gnB{VUe^zH<@P-_g58A``$~!JS1uc_jFw6Rhz)7Vk>KnmT;A7LLc!
zbXTk`-R)j(i4T9o5xlJ%*5GxwMcZ1VUC9f3+Pabns)H$TZuw)+zu>j6gazmHJm@d>
zDBcR#?|}Y&6#BHD^oQ1;u%>i2^fCGca#51EU_BoTRIPB+8y>p^j@u63VmNlAbu8vB
zSi92I@-de0uy9%VRf@|*I4A!45PYlPnj;O~xG)DREYI?ShQuy#YQ;y74fgX4tDn;^
zr~N#958BTX_`3n}^yZTt@fls44i831+G}B=>CR}PZ5~!`sE!n!fF@Rdq|e}F&#A;d
zyleHL@e109Nw7Em+6%sOu%`c_qYt5<&!!6vl}lGb%&O?lPakSRK<nsfZ?_(B>W>v-
z^S*^mqF2Ud2Vm3uG3|Jty=P2@i$H_I<I8Ep=WiB13$K*%xf{lh(p&Pt9dNQ8iC9-6
z+5(A1s7HJ1C}V^Pv!`WWlQFpnYBEK4I_}X3ZBL50kfd6fvM1g7b>LuZ1ujGJp}t47
zr!`l}*pxy1Jn}?l>`B*mB{t#gNp}eyJVxAM_OyPnjL$6)uk?|1{mQybAb+Flyb>RC
zd(xeDRG6^$<BeP`WAY8~!Kv-$J|=uBszgRJN`=3Q4k#1b+H*Jhyzi-BmvK4`W8G8D
zZ7aM4N}Ti-7XCsysEq84jq5X)$XFc&oEm;4Z=7;kTb}S?HkY_o#^+`j!y2A2AH#e^
zQ1}e%h@3t@FkF1dY_9J*8K=u(JZpL*V>TBQr_eU%aiNUZ+`#oRR>S{~z4L&NqWB*8
zB3;^nAVtd2I~={sfk-b$6A+N2gS4Y}IFKfw97RBi1O(|2ib&Ofs7MVUNK>OCy#%C6
z`+wi=oWCQ4OL8d$|Jjf0cezY^Z{EzjnVsFGe=<*cVY-S?n~N^}%u&8{z+^)|On3FY
zxaD9Yd}$kB6+}a!-IICxA<8!Gd-dqitEZ2iZ~5{A`*h_Q4Dlt6hb_oIyz6E*k9#ie
zXE5F0dyw~4$lNk_I==tVtAEdaZ6u?99hvIubANFj-Ot;KujpQL`{|=+^>Lbf{AWi{
zA7OMvp-hn69g#ez^^8`+tCN$V=)^t$j;KyLDI3}Rv7wVG=uFl&KICji8?x7ZZX06#
zA{5KjXAI8@7hc&yd*(Jg^(|{S?)q+HJl@kC5j3fH_nMa96hp?T{4O$1;#`f4&h8PE
z(OrwriWzRZ4(-|7@YJC<IY+qX&MrgFuE;0%=H%Nbt+5&Fz~|bxT8nzR*}E6>LKrG<
z>Fn2qkn{@D=8XO3WTDG0?eW>;e`{8<9v9kk@$Nd7HZEy+wp+JcwyB0(z4*JxCGwp^
zF26Yul<T?m7rJO-yWx>5wCCa7bsCynk5zqjnQq7>>zQ<AS_)VLpHchixpGBlZWc;E
z6s7a}=cTU(cfIr1pT3rdu=PHppX9IGOCiL3_ArlH&yTNa<x`8jyiO~YJuJaodwz#R
z+Cmb-IXFGrysYy!!B#q;S9$M4Yh91Vm>~NW<+&q?BjHv};~fQrTf)CPd4zMX2aAnK
zxSt5uif|+O_jnaf`dWD=dpG{8{yMuh?fQ4>#KVLfQr;8%P2M|;GtjSpUr8rf>L7mW
z$KQLjYv0EG%(wJWPn~MsHRh9N?c%b`B{Dy^zluJ)c)s^1bs6d;%}b{emTCB88=l`;
z@n##{sYfTe72BvpqocX${z6FG*fS%cHjHp$8`V9+g|v-e!VMyv*hXg+F1l>v-?hM5
z&)UW`@nNRDfIj1CZ#UN1gXec-yxGG9>du8e#U4^j7yX594<}}_N11S953hTK3uzA;
zVJ2{jJ(N-5qRSrKW5}vcpS6ds^h>S<;h$G~tGMTRdZ9M_=d5D+l73hng^bM+9YZ|7
zk>kxSW>bgD(5u+RRb7vv+ePr~gxX@liCx_B2p7^WG7!d(Q|uzWpVW)IGc|h0kUevs
zwToQ&8UMCL%@`6PyYOucd0rM_nTAhei03zeyxE37^|%||iftUwbs4&CBqvM&r`X1E
zk8mMvqa<OrbBb-;RpFw`Hr!*#iTTgk#sua=rmio*Ho`xK#Hc-Ze&fiSJ?y9MenOvO
z4?T4Kg>Da-2@}XE_AtOBTu6JUMwtDaVh^)axahKnSCzkcYk^@8@#vUje)WKJq|8HZ
zhTo^~eMuxDBZ=?1gw<)tcw$E6XOI8QVP&6*=Qo?&cF~(iA?G1ysKa3N`UQV$tn1OR
z3z^Hvdq9kNi19pCa^?!gYq9m$NbB>ClEl5jDeE%td&GCY3(7q|=|`9goIMCPUWF5T
zk@=I9>**~X#$3exY?ZgUNJ?cJX%{_f8x`p*EH%R4SNL9Qq1wjtM-$&O3d=n7F~y8N
zpFN(o56^E=d9#mu)R_t0ihX>b>oQ{Y(PUvlEjjVUKIVAD4{0AW2$zI#Vjo|ra8Y3&
z?)y6V7C&nruhMrozI<VQ$I~N9EU*dBZ)|z9i44?JF7zoj@vW}Eh}lG!&l759;)_k3
z@`xYOCYBK{GvUN0?y7K6VH580q}mtH+Qb;<B!OGQKPL&J+CuRKRE(It*XMPO%Zz@X
zJ)Z6_Jii;}%{B^AUsm)gwvlt2F^7<~#qf?NW0vsT7V*V4%6r5QX&bu<SC(*M8_iU>
zsIU$9c+z3nv$o-2UJ`UR%Ept3+J?{LiI<F`Y&`M&9-24%s7amK(XH4=iN8db5$ih^
zFJ+yR_+lTmJ>rM7kF$hpPB^iT&MI6~*oS*O8MNYA`#6HX;XmPp*++!NlbEmx&+oi>
zvxzR$Q$O@6HWB~Bh}*>G<vh1Re6fj49`Qrk#67}wC!E+s85J%nY{GqyvinNICK{7|
zQqFpu@8!WJB6VNOxFtbSx^EYr=KwwLU&%VZ+=B>Ct?yB%+Ksh;xnCq}|L!$@(F6Z{
z?!D@?{LS;8ms@80s%K?BkIW`-&r^o>g?aa|=)PyE#18L$S<ic0ZkgXiAh-79x2TfY
zwc3#R2|AH^=zY%iwEf^n-HUdY)Tn2vi)WAjjma`^^1K)AmN_cxS!_bukS2O`v~ABb
ziv!wr?cTOs_m0@2@l751TgUDldvxsCudi&(Z{N$o6Hmr{ZMTgCtTFWEeioBgM`~-(
zm$}Dt`$|I@Z9?4d^<pF8(U<2vZMVLn(ncbyFZX_!YW{}4_}s5<U;eNOZOYX@thtJM
zsd&`vhf#IVwTGj-VUxKi$Fs-(Y*N-8Jom%6bsUv8DdWf)^0}E?)B1Gm+p%Apj(z&{
z?4{qk6d&_{d9~4B4I=kOcVmB6bSm%Z-=^!(@HwOnRl#uNNfP({%|+^-ci=js4z>_S
z+V}>}U#NrN7qJKDshS9XU3l)pao0su+Iv`a@xQ$OR~I#@hyCbQ>LTl>|GSqZbx}G*
zUDS5(KUi<nMP}m2m3+r-1-`heoN5pHvtAv#_LZKgP3P{t+VN&{wNTY}a8KD@qK}=z
zXAiTpI6u1gZmI92>GtFvFWPnO*M^tb_3ubHv6JemTn|;bvhur>OUftZ@_(va9eX~n
zSTeQ|C6puLWvZ&mG+~3GD>JFem6WYjLB`{!%G9-Q_l|8lv>VK>x9)9v_EKA9!do8k
z8$_vMQ=+5S__z98p01xaRavg6ve0bM8n43P{0=`PsH|tbsfyy}ThGq&)SXdR&+~Jn
zuA~m!wy|oXA+Ib0%T;d9^~h@pEsxH07wzTM_HEks>C<+wyHdlFI|p)#50wNt+tlsV
zzAaYf@JNS0J!LO#-jW9n4T}*SNhOQU+SF^?x0_s3{?bZE8NM{iUy9#FN5wb~P=4pX
z<?q|RE6*kN9oV+Jql@v*0B^c++p(VCTTkaTM&;#cuacMj>Ad=34-VNS5|&=P<rS>*
zdJTC*LaJStD<EWE1C7jl$;)kLdo~$5tWF+MPkdTYTTaHdiptK^W1#vb(KZ7*IoRXV
zuahBPA;N}o=zW5_&$LnaUXFfzn6R&I^HQIl&wNTa@sDNfF>WmzZ6gD}dA1D+Cw)X|
z%GS0|=k8s33z_KfC;Gl@d030&yDMTF?zX)6tI*{N_9|B!2U+NK7n@~sZVp{GKku^j
zjm@&T?XmfmXJvCz=jQUE+v7lGkkSUCvd(1ujY@kgxixgT0=&zm8)R&k&9p6a*&JcW
zCI%VXWixL#WUEhErGKo=xe<E|suZd{_U&odW1GmzCjFdy$Dz!Pq>q&OqVb!tJy(7b
zKT`Ti`CE^+gZ}-4yT1(CubK%OvR{?CNqGBJ%Z_LDF_p6VS9p#-R09=-M5eAQ|0}z(
zuf|t>glyNo>cib%<@(ythuDSKhm52C=)?LP`-qD1GrYDTHXybU(gtK44QT^rehaS+
zWd0^}nJsUIZUd@GILIPWHt?e5P8$%q+%B(mt#<`4rQB{CPqOn_xu;;`rsuTzs2G#O
z+uq$a9<p6W*2cA6q06j=?ql_JcXMLoG11ROm)!TBBe&gqT}OJnd(rhh`&*;FGg5zY
zm7a4G^E;cG`x{f%PP`GBXWcrs@5U$4`Ls~aw%t{IgHVpA*COgO$MKx|d(La6J{jVk
z>X&6c<8FiI-A4Ij{YI{&U++x$9IAX>`|7WCX``1g3d-g=K6sX6nJR~;o;pzuiz-LI
zUfp{Q<O_V!RSvd4Y56#9myCN|MYtaHs?61mH6)-lOTZ`4VGAhXZJd4=jqts>mhg#T
zHBLDusPG>`StFSUE5k`p{JxK1OE?*Jfm5NRYvBx3<#?NGNjE+ee@c$v_?ojQyaDMp
zw7;Rd{N@Oj-yBWlclua<KmD0*zHf+J;nBZ#A)55B(v7J89T6<Q^L+G_-|0j7?daS!
z%Ge(=hU;KXxo6shQ;yv%fytWKcTnu^2Pn3_2iAdm;X802>;Ml!xvzT|I^Yo~c53JJ
z8yz$G1dffFe4Ngh$;bbLn8_z#O!Vg?{hXzaVgF($HYQ)5{an6ynp4)0^TQU9&pZCx
zKblU+oPfD$1mgwF^evuai*NCQ&A!RU3(<U%&%yvBdclp>+pniS`@Et#6Y_gMh|8e$
zhwkyldBrHFwC_P7>fvT$&6$Yb|AxijedvzoxE%3#R?=`bFv>ZU!rJL%q+BIA<#>ZX
zOTBY%!np?Kgz|3j+^{n&4kdppr`9lP(s4G5nslVI6#Yk5E@$1SNr#vFMY=p05XjWt
zNT+TBqrS|@m|O(qs71S!HHzBs6Udee=TcY?O8xO#QfC#yHiR`{W7q~Zfl{CEz`n3K
zoDbiHOJQr63<vBzm>1e%QP>_<haF)}*ah~2UEyHZ9n$S<J>f#=fXg9yI0N7SxCah`
zN8k|nJEYE>#c43ZU`03r{s2e8{csGlApba66OM;shoT>QXG1^uh`K$S`8_7|lY(-K
ze)2=nPcbO^5xt0hYD3XaZz%d10YyI(q3GueDEe6gML*v`(a!-W`uQ1(el9@KPX(o)
zx0QYZm41#X{Zvr;Y3!jN(${SIdsQ^;G2x`W<JxN-_+5?<Y0v54G`JN`hm>8zmYgFY
zUAA)qoCT-C*>Emg058JN;Tx211uO(t!Qv3xb2fqNp~$@vegrqc)$l907H)=YFV@K0
z`90hQ#Xh#fGw^Hp5C*__lz%783%`Yh;rFm8`~jAQKf)SN{GnP<{GlfB0DKP~gmx%?
zQFnM0_Jqe_KgiJLoC;6E>F^Z%44#3@;4kny_$w6q{2d;J=OA+f?K~8_)b&2a=$}(5
zyNs=R|553EpVIqpO7BmU-V-2~=)C~^7FwX_UD~VYUF=fyUKfhq>qF6d3n+T;1V!&%
zpy+)d6ul3IqW6(d^ga)Y-bLS{_vKLZz6pxnMbDylv3Jq?StxpshkiZv9?;F`58~`S
zX6-$om!bDKdyiRrcQ%c)_ZQK>%fu)ieSMt0$DF-SK;N#`hTg?*5Pv2mzYXJ*gLm=h
z{%}et{%|Uok4obG;qqBuEe&i6(?aoq(!nnwex#F6R%w}F4bpuB)`Gmc#n}L6g&SaY
zxC!z}Eq$Dq^4RP~dBnesOnEw~@@!G%`Bs&u4(UpH>Om<_V<_d>0;N3Lp}Ra*%A@^b
z_#HB*lXX1L`5i8a6P0N$m=)sF>FcV~p{xn;8PI>{cfkzk6oI{25lg3dh;*!~Jf%WO
zXE^yudBoqB^5Anib3*a^WxhKaia%xL4CrgDi$o?J7wMSp8~VA#wdf}m9K$I`JMv2g
z#g9(|u@Pq(NZsh`$KuChe%kx617yp#vkw%1egNzZ@s+hc@Czt@J-)8)*W)8;1Nrwc
zDE|FfI2ek2QZDmPhJ07#?-3|h6~aro+CV8+Cn)9W2c=wtpp@%VDCJrPrCeK}%s24W
z^m6?SrCj(_|CXx@*QVr#9Wcky%SF+&R-AJD%(}Vg>jX>>Pr-cf7q}n(2J!8*-(f-G
zpNECvCD<HZhVR0wQ1l@AIZqpUh^hSi|1t8T?jt3i$R+X>g(9EGCGxd`p7I4V!Qm&d
zwP??;Ecuvo8TD6)Yq2ZbWlgT-NJ9Cf{UwFDU^18oCWlfV65s!CqrASx56m37{H<4f
z&tL4xks@a8H;9R=)Nf4LubByQOxcs@)4n(6@)P^BMbdtQB5A)`mdM$!Ba-$Tn9|6f
zwWdh*7a{v!*8cSVN%~>W{>l2QQNJ;jpX*W7w3m?m@AJl&Ko&Zry+pQsh9^I<U#GI)
z0$h9Re{=A6>3^jk_UwO6w~X@o8sDPq*Vp)d%6@%`Fa3pSh*AC)QEa~rmHjpjVZU~6
zu1NjHM1E4gfkTb_xJTl(ezWj*so!kSvwqD3eUC5twU~_lA+q)yvVVA9`|)FeQ1ly9
z`2{~V@{0+7N!KR}@FHJK<fr>rksRNws(<j+KeI=2d<%@^_~uG&*e~~-qI7(ddA|7H
z&7kM_rg6hb>NlqHvulQYa^Fq*fBy4n{uFY&5xGP@>E}G<^E+tB7Zdr3{RS!f&Cj*B
z@hv-lm;O)Y_n!TqL)ovd@m<P(eT}bOHT306eCaQO(-`#|Q~r|u52L&>m0tii-Y_vO
zvi*HX`+eT{q6HfA#YBE$zoy)Ve7^WM65lV9{#igI{WFWQUth{E_G_(X=sPC-CCSg8
zB4+cmmNfEfi4jL-|0{l{^uIFBc=o@}hsOG1Oyno_r?ocZ^VR?K%M-cyfej-U-@yg~
z>0f*;za<j#i#__iZR8&l_AmA2Q0rkn%gbi6$mq+jj?v%wlE2<xq>5R61znDuyn&Il
zZ>^E<`Rn#o%7`CR{efRH-|JWG)4#Lt@=APj72osM_4PPr`%ja)-{4Do5PAI~(SM1&
zS{Xy%G131>er7FZ^V8TsDE(DT*uThUzZ$dlV~IrnAodd&3Hy=w8aJ#XH6ECJk1zW6
zuWG~}O(7!VUzH=i+&`-T<^I_aDE`$j=;>btCX3np{Mpb*5o8Z)q~sI1M7~N;<P*6>
zz7fz<KBu~09uxVA{rI;s<g3bcX!Ccuzbp3#%R`yJSA?GPcbghteU0x_{-dw)&8q$Q
z5?}1smev@rB0HZBIlq10{gr?}4SmN{e&+awe0J<CGVN3DYm5CBgWm4n+YcM^#YBE$
zzg9JW&&PFW_M4R7#eU6D>^BGWwBJBAfA=+hu$sU78sDzw@4m$Ef-L^&V%C1mf5oi*
zIupdK{RSL~S^ITF(tfquMtOa)A89}4tcHGljqi%A{SGq9FZ*R8(?5m0f7OWeWPIgW
zm#4;8c?gT2<XM*($<L<l@5w%($jBFRd=a@sJ{e~`{Rev=L%x{EPwdBUsF9!S8}iow
z%Kkp-f6dUd{|z1xx%iGq<{uD={6!YKTF*(&wa8C(XlXg+*vF^qWFM88Gf=H#gcZ)E
z=I>#J3p!=!Ev#^U;Vhp?-Ny?ny})pm&w4t1<<r#u!m#pngfl%qwVyAn^a9jAJa6Ij
z=VV73a>#T4QolTQqRAc&IVvSGp3i&}7UbWRq13m;vkmtxo|Olt#D*f8pM98*@sxbB
zr!%B{Zz=hz!RGwEhKGDkC0|72Ih1@6jptJGMI@g1M}ca+v#H2O!=wuTz5goDB_-tF
zhhPc`3sb`*FeCg47KiNFb;>?y_Q*Qx!4t3{JPjMeGtgb{fl5Aif9Pp1#gsmaL-9jP
zc<3`&$rsUhL8=}i8c*{vKg~;fD5K;n3#C1j^N`Q%r9F6yXY$e>yv4J4X%Ekf=b+31
zDUEhCoNH+hGXL$sDMv}(_mKqhtf5|i<)P@EXW*O#U`1F2R)!@ZOQG`WQtfS65!Qz9
zL7tIw4u%b&*p1{H^vGDZ+QfBu@|FA5lCShNlCR_^`N}+9@_iFZzP+L3I~_{C>!CYe
ziEI1TkT(<8A)i0DB{teeLzscTH-i7#`HqOk3#4On@t~{pZ}R-6<X494-SPv+U$i69
z?<FYv$uC3E=T&$dUW32DV0Z!k4LP;PFg0n!i>Em=!T2yIOax28B+v?ZF4$QY%JU(z
z|HA~?>#si-!rpoPxe%Vw)zb4jd-e6_LOz6~>Ezi7{rQWTFf0FF2(!V@VGg()=7Rn(
z58MIqNu7Hjb7$uXXn{enB>V%GftMj`U(VaGJbVmUBXU-Hh5CeV!78vmtP17%k802k
zYrrnB7R0U9p97x+>+$bJumSuEvRBUe4dkAs{+unoqyC&N_b#2>Zr9jL;=Ba8C-1}!
zkhNN8BI*YnIg>!vDx7RH)9f$<L}$+Yumco(ka{%*81*X8g+@ia-ct3-Gdp^{z5(Nt
zA3E0SwKSA^MJIZ_)`wEBvhPLeRi0xeu6!<DuUDRh(Cc*w%)sxHq15X%m>GTwrCygn
zsn?}Y>UA}gdff=6UUx#N*ZolH^$e7HJqx8?&q1lz>rm?TK9qWW1-(kWR)JEl@|=;>
ztJJ5|Yjao)c7#%|J)qR9JXbHz_q(9f>ryE7x*bZr?uJsY`=He80Vwr)3`)IThf=RM
zpwuhwn_jPMi`VOw<paH5S;o-owFvA$ICnd@sONxQr#?dZ2lPSu_(|XAq$$g@<^RUB
z`54ck;z|4WmS4IM`8i4(^Vo>SlQ&IKMZ9;@dwwD1bNMJ=u=3j@nxDV&<0Bf+to-_j
z#tTw@enjKhl%F2ac!A0vk7&FArBCtKyxEJ`g{OV`tNM#*yg(o0*?h21Gi44^{+3+l
z;}lyJTa=@lYHwz)1H6PA;?XW0^^A6snK&W!m6LGd4>P}Uia)?T(SO^s%g1>BDxU0r
z_Ld*-o_Q)if2FSo$74Vh9Ys{WKp*9EsOL)}nqM$4RPd#o7MwVr;wgPbw44rJ<lsww
zHXrrrRP*<UmQz#vP$L@8<fA?VcoBv#deL|xi7)XiKI+rut9|;|j!ajK_9xFdcx&&{
zu08vgK$Txa;{_|dL^Phu$Nt6s(2!63kC5`s#&44QP56@fI>H>~M_KvJq~g_4@uZ(E
z$tlM;!ZFp<-)kgtOyJ*z;6zv*PEzUEF`U4rhQHDQKTYzNc_4nDeq2jxJdb-FihgfG
z#ystBDC<eLU?X@JehB}8AH#?6JNN|dh4EhHy(*-c049QoAik@X6pFu{3?6~0;3;T=
zzr(aJ7^Z`FVJ4UmzcVw;1+zl7yJ*><_`zl<^P8Mdp0m#n#SbnB+rdJx11t)ALJRx|
zmV%$aGH?Mb55IsF;VSqh+zBf~rng#E_!F!FlcTp<un?>b<^47FU?o@|ir=g2xk8+t
zV?xiiZgF~!2|Wi?Gsc~`ej|GOjo<`v_8b%T?8p|U=a|s5A1^XwDA(luZE^mF@BT(H
z<!@M(zfm=$zfmww&rxB|Vd|NM^Ei8sy#E}Qo~_&*i_>%T>)CSCn2*Nw&yn-%!nEhK
zas5V2^v~87hMwc*DUq}1u+}%MmE-gr74{sKo&#98l5sH3o}<^EEj8oTH)6t`?MdS7
zIVSWRlp{{hF`;J@8>`~xDbYVqu@;Tfb5z)KnDZ2Fn8n$1^xLyPHw@$S9Q}IsV`FTb
zo}*vS{^{fTjhN`4?dp9Iar43Goe$c}8ulEg=jhdQQ0F*3M@7F8);f|+y;mvDo}<^E
zo$=!AIVS8`%N(cYn9#FDy&o#>{$S+#jj-n3_I!pt$LTqm_1rp6&r#8Dgk{fxYJYs3
zJx8xS2V9F=--r==R_{5Cv*+luXBYRmZTXCK(Lk<czi28rhEt9fJYOO2TX_%4b18OM
z8n%P-zJm5p-mlRSwt}5uPuK+xgx#SN_Jp6n-f$J{1J}TQa69Y|e}n^|JkKHJ3dk5c
z%jGH&JIfXLPV6j~<)ShE$2R*4x*I#oWyx;T<4M{;RJ6xlq$BNd5R~>f3QBwY6iR#C
z0Hr;C38g*Cb7j&VkHDweW0KfeuHeG4vs{*jv9nykKO1%*+w99PIChrHq@MdePJ4)o
z_UIlThm)SP$8k{F<6J21aXpmwxDiTw+y$jQ^3JQL+N1Lg!@go$xoo9kXSrO>V`sU7
zd6AFYFO6;W=yyMMmdljWsK?*YSyZ$~_xL!1^rStGhteJwLTQiNptQ#wP}<`GDDCkS
z^c)}kUX7jQ3M?8s%VlaDJIfV#(y;s3W?#;mv9nyRJVrgnHveAZ#b?s5#<p?=vXB=W
z%VlaBJIm!bZ`gfot4H&l*jX-HHlrS6n|~j~3kt>VV_UgQ+{llO<+Ab8&)8Tl({aP@
zV_Q82T#KFMvgbAGQQm**i@(}{c(T6w9+dUf{!rF)CPVR8WnESL)fG_u)tylM)$gJB
zt3N^USAU0|{%W8aA7fj&{CFX$*nMm(SCASXV_Uhb7Yw_PZRHA9<6~?qm&I(@*9~ke
zD%#@!(vkM~5tQ~g6H0rO`y0|8_dscnGH;aj_zRTwcnNy8$AHAKvs}Sye2i`Sve;s&
zzSQ^_+w|qfi-o0Mjcw&J^J41Q*x$P{#m;isd8vJD)R$kg*jX-3t*^$mamfE(>>RgE
zIgEOYZT*B_(%4z9KwiKe8~asLqu5!lz!R}^9FiCA$Hsc}Q{S75ZT*)iy<uOmtz1Fs
zJ<qYNTxRti>DX2-=egK94q4Q95@VabZ0h@qv2A<|N*Fu)dsD&KSuUG;k9=&aM-v}{
ziH+k>fckD|Y|@vF`K;-xu^;<wu4O$ZF|5WZM@8Plo(Rf!e9Tb3<5LP+VI?Tv^QjEw
zdp=d*TTu3&O1c5+z4*1b4o|w}2q)=EI+E^NP|}rhd8TVo=|**V&FX#pQCVIyWp|D?
z>`}hcVB<q3Vw*re3MqY=`ByL>J(9o4zF>ROr^6Lf-zAZ7mQl}7uYgB-RxkN_hI5P!
zUwVN*8)XWsd=4+=^OV=_e15*3;mlsbdCFn?;Q8r!hLZ)x@aWlZ%=6RpET7#=IL~}7
zTf&#G%ZnVI`TCo~XD|L<>en;9fZJi0&x-vy_`rbZ51Z7#dzKKE<dh>3-^;^vwS-W<
zr;`|(VN#e6CWF#HSUH2$_w*u@j)ingbXHOx`QDLygo4)$Yq>b(n9Wa8o>|bO{w?`S
zJdF+{qVY&i3+!velWXbMBwe|eB*!?uHz@fHh8f`ym;(-lh2St)8V-k6I0DvyBVj}6
zge~DH*b$C~-Qfq2Y_%~^_C1b;W1!?W1&)Uzmz2qZup-wS&X_Ep+*gzGjf7G@*_SEh
zn+o0KvvD2R&nVweu0xIs#|STWaukY9{RFGR6Hwxwge~AH*bbhC?(rs=kHv}HQJt;@
zrAAA-e4sC?(-pf8+-j7!2-l)t&-O5o?~{ss4uHAk?;hVP_2*-QQl5y$lMj3P63;%)
z=tm-&pLLOM<qYB@g1(f~and*W{EGONU(h_?^0O}TO`o>?zLnGL@GYK=8-7v`dBpxg
z*eCbmoyqup2FwB(s`d6QcJ2SEZ}I%<80D1lC}e&|NnhH-5y;S?fB)D$J_K}&c)YTt
zVZ$L7`NU5ae=h-)zF!Vht>?E7N_h@I`P)G#`8qhYDn@+SM=OOAeRPoDIq3WJ_|2hN
z{aeP9clmck*b2(?WUXNn$esu1JFpFu{<19`2)TBSfTa7cegn%H`M$yLdpJG&jei)o
zMNbbQB59A*I4<(qYyD4N(XXex@;y~4e=C>)%D<((%lB2?dbUqD^jw_ZLyq5D_(}5J
z4D&;}Ha(u?>#zKfoLtNIS3UF1rpjxEY502%m<{IgD7WQnqrLbNU+mGP>bU^dQqP|H
z`U&}@+{d8U`Eez0bBU+wcMR7eZxUFSQ;yF3B>L(CMbC`=&Rmc^*1F%&8#dzK{a^=3
zQ*t`tAn4X-u&T$5{2sC%$xJU-JeZEZzXBzm=+jTtLqV>kTnV7tZg=pL$n!Onas|M=
za2J&LH97ri8Fo;Z>tN1AoMMx5^i}%k2T5A%55>*~K#^}Cl=KEcw;Ta={%4ON+by4t
z(92T@iX4TZ#4~f+)x1a2f8Kn{%HIO{*lawQhX2_S&eM;j&h+w8CT9i0<cB{)>fM=u
z@Wr4zKa-m8gqEMD|8MqEF3)f_<*$27&q`VRj~n`lZ24_o%I`Tpu&Q}jXyx(@$CrO~
zy@nRfQ%=hVVTThr?F<T0QBO`aPYbPFp5?cC3Fj`ql*_a^YRcvCq6c@mBtI7)X^sj#
zxV+exXMTRSA}^nm+oJ5WB-hf8J=@u3_VGyncLipLSE2N$*P-;W!BE<nmD8l;k8C<Y
zGYq*Rn@+$&!+s;1j^7TWUL%{1RrxECO~-sIYV>1M{cB{)<N7LU$`i~7#HIa2wmjPT
zsHv~OiIGod0`fTS82XvRwY0C4a2Tf?GZGl%<R>sI|DFk@ea(X6hs}l6;XGIyE`-hC
z=TQ8M#SouE`vMMyOW|0!49<Wn;7qs@N;{SEXrCBz#g_8ev&XLTn7)ZU<q^Nng7YZt
z;w{dQ{`;NyhCg~2n)&-Zh})~(hf?1X-&Nm`$LIKSBbR@mT1W9Ee;H$()r|aco1d9~
z`16za<Lh7vxE{L4BY!d!y-7O~r`B^^tBxNl{&EeN7Sa{!>wtA(KK{*8m7Y#bt}QAZ
zx8LpQH)kT8r1J(O3oQ$jc`-wwo?Z?pesfMJ<q~-UlswYjB~pASKDHbu_({?`2{XV`
zP~u6u4WI)MdFW1_=|@hGeiD8^2{XadusA#eE5To33m60k!{6Z;_$T}n{skAqb8s!Z
z0GU&07vcBtGL&*~E9zf40@Zv(^cPZ&JxY!rp^3lmRdR^@!CvCAhgg^Ypo(`$#glq)
z9W&&g&$YAz&w4ne{F2j9<o*SAhQC9R_YXK8{s~16NzakhXctkHo|O()>L;qwGb{fk
zs?yVx9}`vS`Mn>t`g8srwfgg~8MWmL-W0XvvnhWks_Mf|<BdxDvnc;3D$3`iT?E%M
z^tY31X}>98KTbJT(yvJWwF>5h{!rF7)<f}sHo>-VD|{bf%FaHJp<2Jc@-3Xjzjwn0
z@H@B!{s4EtJy6=cl{3i8xL_lk^uG<E%tIT&9FXss>*GRGDCx+!YFFvV+K}{r37~sD
z#zHt5mx{yJU`Z%_PFWRS`a#ET!{5!%wXBbMjst~R2b1_kU~X7ct&8dXr&<@2yu8KB
z7b2diyrF-Qk0pSo^6SA*GCuZ(iD6$Ta!P*oszyAKBV<2+jh`gF>o64z_K0Uv>u)m7
zg<OA2haM!}>rlq4^hz(HSF_4b^dC~MBUFAPjX!Bln4WN>pp@6l8T`a3Z*s21&f-BC
zqvY71@PFatFY>q0!X5AkXZ8~AkViO+mvDg|;p|?*9rXxj^%Cx|M>w08a7R4CnY@HM
z=n>BO+4J?{sXv#OaGv_}_Y%%ie*s>?dFn6NOE^#c1$qhRslOmE;XL){=Ovt{{(@M9
zdY)Z*>Mz(!I8XhV3O+wQPyLy_g!9y&%}Y2>{aL((^VFZ!OE^#cX<ov4>d!@I9UlGp
zc?svKzW^`cJoOjoC7h@Jv>%^eK2QAxc}dSxf5BeDdFs#KOE|awq`$VR{!`Z7L-yAn
z@{{zt6OBJ<lRWxOv+}Qt^7oMa<}u|roB5lT)sR1|aDmgMhh^;I^p>8#pD_-G70$Ii
zeEC|GUm8|=roY2iK5NbJ<?B@bVOaSFZ3~~g!A#1+qrZR;!w$!|%)Lt^Tu#P*sSg=n
z&vMFfmi}MH!3!`Oya+{(OORn)y8_$8n{WX98;*mwq0Arez~%5R{1M)Vzr%mv1^5sq
zN0>*DZclp*OT#Cy5{$<_hiWhhYzC9U&hS+@6efq`VG8&$Oa<}rG!vvbYH8pTm=5w9
zckOj3{(#7>E%^T_w_WwO|KIA{r26OoPjZ_v^T0Qa{;U|+A@8f2lz%PZY_*JVy5Eaq
zOtbmdKmNvJJg|BR_q9hj$8nGJLipQ%dyE@47R4m5(EM%BaAtKsF|2UfBBLJ-D_oFT
z_XsPTvs?JeXTKFbd0n-_mtLT{e-c*tENVYySmCVa!<VmVQrO|_)R&8itJGUdPML2e
zg-tl+7=<0kym2&?dDs|ehOD*e>u?{!3jBLAtOq}a@4%_B1)K(@pKi_>tn#VDwd9io
z*5#A~lW@v<-%R*AWUlYb3}?gaa1JaE=fY}`H4A;;=4VjScW|0_8ggvqTE;(_Uw7b?
z<25zkPOIkIufsz8o*vp@X4ng6g-)0q;yY<M;XIfJ%6dayxDn=q?tHaZ4L!$nzJViO
zjJ*DnjdmH+^17D27(H9wc`^C=|N3I;H>kvmk=MNF#mMVi`hx8F@Qcy2oy}kI=)+>N
z{o<c!+BTzpd3;*$pJg7BKz`>Kfj=+(^++iF@+epmj)8mOIQR>k2+zYwkhMu|3Y7WA
zRLC?=n+|1u@d<1LXT$Dr4txaX!+7Ms0KNeiLO!FTErO-s=ddbV3>&~Duoe6Qc7;pf
z0Jsc}f@|T2&>wyb*TLy<1H^sNHbTrx`x35#U%~ZoGnDZ|^b!=`sE;_kJgpahZtS5R
zElw{_>&2z^?Z@fmX}vhqa|v;Jd0H<fTU`GVTEFXe(&%5#&>zcuA*#lsB6M0Z9<kR%
zACFo>8IRgS8IK%L#v>VrWIRd;Wjx9TWjta}wLTt|gEAgfhcX^DhB6-6p^Qg8po~XD
zpo~XsE7ixNkD!c4)1Zt;v!IMeUqBg;Rzew%{GsS&6Z9O90ug{BYH@mbS}!IhopE}3
z)?OTHohHs+p0*d~{<wA&TK{6B1B`1&Pq!m8{jI-R-%Z1H$o1V5YMo2=PdL6a=BpXG
zmUXlQQ07c>RAOC9*6-egY+2DNL)q71RqIs}KlmHp<6DStQ~66dL+(#0tMV@gQ}Xxn
zDqo2gsPc_SJS*{REcl7NWakv2WIa;mhI07vlgPUen&2Xs0e%kOfQzBbv&@_}b^kLf
z*CFp$9`{(swy67`VTF^2B&A$og$q*mKf?+apzeQ$70#~ie})y#s_uV=70#jVe})y#
ze^dD6HElQSE3EX)YCl_8;eyruPjBJGz5?zU<twl1*K@zsVfM$%`oa-d8XkpW7rH&q
zGWw&4#`DkVTRi(t-{QFj8S<qHMZQ;%N7_MrC1(N;`GV^k`9(M$i|u0H5shc*74iIR
zQWuYm{AwuqWS<&MUq7mGA6evk8)k>qVQyFxR)V!)6=;KR!G=)kSJDlbYm_Id(>3Rd
zo^%7b@hy6f%JPbxo78$rX!U7U_LE)NPYw_Jaj56^BOH$#C(pAVZ~6Iqu^+GTo*4Os
z){ZA*57PcWg3|s!R`wx!v8sJv5sl}^!lTF+(Rj8!zQwb6slNiM{tBx4E96msE-&@x
zHJ+FH^A<1AOZ`1Bp7<s9T}J)sehu?+Prs(N@+%rZ@n;&sbg+@~FC@M-nW0x-<C{iB
zF8^RA-eM2F<{!8`a^-ih@Ew`_gMW*h{N_@T%ioUE7Mbz~EQ_T6k3_Egegk}uZ^v#N
z0fzhwxfcIa#=9n*ay((3M*6RK*n24$A69`0pxk$t_dT_M^8TleP~Q903%&|_L-%{1
z>|EQD8s&`ce9R+bMjlPwkB)A6f|kaN-kdyy5RZC_Zh5p{W2SyA>V9%`%i|z}n9y4w
z3#l=YPf%dY*nvMU1&MBX*!rUd?J(-+8?L2)^L)N<x9Z=%gPHjI_b@x$1Gm7vklV-F
zJ}7>@q!*CLD0ft)=NcBZ<#TXjSo9iI<+Ck`T6u$c_$eyO=R6a&`tvUqwdD(55VhsA
zEs5ItwI7OFc`bdTHa)+u4gJZSI%NAjNV^pO<PgjZ1EConfwkdLD0}^Wg6{U~Ol*`d
zs?xI!kJ|ECCK~k{Rpm2%5w-IAH;&r$tiMF9{v13UDg8@S>CfLUYRhL*<9Jk+&#cDl
zs7fzbwcn^nuQ~M)tlF>amy-7Dx&QWO+NHGL6EF=t1*^g{up9gZvbR?Yg1qxU`xEAZ
zXQ8xbNk34v=jck`PqpvpO5ds4dvv95SM5K#(wB#rrM*Q*`m(;_QvE{)uEl;l*JsXS
z2Qpv108Q{B6g#@4>_g%QsQ$p$_%b09`FxFUSMA-`_zu;+eT{Ebezq_1?Z|BoFyw!m
zYtg^w`arPK{|zYXV>hAr(SO5S@D?lrZ^N?i4y+9C!7A`Rly+?A)YSSwbmtQ|B4*_A
zpJa^V(JhZltq(+ZJ{Gk;5Z(FstM(q<`2?wcA-eN1tNtUp^O22K(oaQqJ}%WCMRz`S
z)o(>-J`VKdRO|m8xt9J-{E-fvax`ZhQ~J9WP}coh!aT4ol=aYdupI0FWo@7%l=((y
z*c5hwZQ%Q`E$jxRzmt6J>b^lt=W7{d^nWp(uZfN7VxKXcZ?L+*5!3m))P0ed&es(5
zV(Qnb?!&~iyiRrhCZ_WZQulpgI^W<UhQA%t`39)_Ofi|SKOIJ}>YvZWH~Qxi^dXC-
zBjIq+pGtq-8_IK{gQ5I=D3tr-!=UVE7zyjc(eOPu0pbQ~6X94m8Kxu6k6>o#f^4(V
zro+u}CS==?HV58<^I-f}*hdXhz|UYRxDaN9i=i2=gq7fGSQoB=@4&UNCG>}b;CeV7
zZh%waMkvqoY=P(D*O1RFYCGXQ_&rR7KK8(L@JE;p?uFUm0m$dWm>cuH1$YdWgU4Yd
zcpBD#XJ8%pJLEI%+8?k5JP+H$3$Qc13VXwAus{48^6e7s7UUZx+C9j(KeYQ$#y6?A
zKsCO_)!WNeZ+@eU@guI@UaoqR2LWkzT3o%oT=iyOVT|W-_4abro7Oz8-d;w(#2FMf
zzP*g~=C9_LasA}W)lUY09@pMp#`b1g9_LTKjP+(e8t0e1jP+(27*}sETfMoMa0h*F
zjBmSH|C0MhMVW(-k%_n*d}mMACzC*Vjwvau1XDoSKW~EX!Zffm%nbWMGh`V?%MNA#
zOAg3maavBe4CaDg!rX8d%m)v^BJdb23fUH^m4ugJDJbi572qRS5hkFFm0=2Kg=t|`
zm>X7u@*dUdum-FFYr&fEU054-gLPmJSQn0f_2CrQ2=cg*)))rErch(uvKdSbo5M!%
zJ=g)-VSm^j&V`*Jud&y<!gH`YOoo0PP}V#9Kv~!94`tnQ5NrkqLy=SJB_Ng2p5p2y
zcGZiE1$U}Pi>sH|RWA-++!9wWv9BMqt%>W$V&nJ{%nO#{+Dq(fFOIXu_;O49f>8Xi
zbc{XXkID10;*ZJwVe!YBLGj0A?~nLn^8BLsV{)HZ{IN+;{IS_k{IMla{IT^={4sgn
zM*Ok;Q2eo<q4;CJLGj1VLGj0KL-EHRLh;AgzO4IWDWUjd>7n>zybeV7$BIJn$E;BN
zF<uL+`(rFW>;70*DE`<;DE`<eDD7n$6n|_P6o2e@DE?Sd{3-Fr<UY0dV@09(W8!~_
zKPLB~#UGmu#UJCdK)OG60g6BNDtZ-v%mT$9D-XpVYXZd|8w|xC8wx%BF~4#~dx@);
z*i|n<OXJ#0Y-}&q)rLP7*Ir^*d$Ii-*N?@<_G0FPE(~#6TziQ<?PU=45wz17U;1(_
z{#bI@ol_3^{-Erywm|XAibL67E$?$H1<OI%UtIyp{_2WQ_E*0Nn?fs;{nb@q4_FP#
z`zPLpvJNEq2fS+7#f!?{<$SU7JJkDOUX=Vcwg37><sXd0Ed9cZ%HP2R;6>)|SMtTm
zAGGMj%5PQsv|m*H+thyT7nQ$R?c074`CDjruB}G>OTRDuKhr`j7pEMZd0$vU*ah+@
zt*giT!vba)b{o-nmXp5a7x=Yr`B?`)Kfj_%K8upCn1_6R4W6H$*Ld@M%P**xkNJ72
zzwS!D9!kER9`XfxsXuS=tX}HRTf87I_2(^~%}f22RPvQl@|E_G&)-Y^d5!0#{=CHt
z_ELY(i)W@yIk=%H<B#}P(*EQ+EvFn`#W(yUGuJK^PM)I(8E&gbxZqhv8exSCRN+F)
zce6^*MP5O5jP(3ezH*;*45u8K36}_FftexCIOyN;Hp2q^n`a%I#b6F7&ll%}m0>Pe
z9p;8|pEVC`0`tO_Fdu9O^TV#N0PF?}LGc@<-*Oy&T29Y?>tIsDZ#@KGBWxga$FpTJ
z+L>EF;f-fT8B#Y9ji=2w)(IjSFNg<Qe96z*$+vip>%Ph7SIxKlf>@aKMLz3h-}Gtw
z!?$vp$3;9|0CuA7H{`p@rL<RRXB*{rj^9~-O$IN+H1G<{4X?sN@H(sjgJD&86E=jm
zU@LeV%KG;mD08U0a0t8yap$yu;2QV<eghxE@8Ki32lA2t=T9IW41%w~^DrU22ophR
zF9DoEY&?*9dfDahpZMRX4;LTq_%GClW5a*Lu1szJ8*=#5@c#>T74+tRqdv^5{~Pro
zAGZ51*p=(df5Wcq&X->fUa_y44jS!a?<<CXl>;9|o(-3y4*rYySM{LyT@9eDY1m*v
z*a((~jbRno9M*;%U_00ec88r|Pxw9*KdU<wKdT3n{hqy`>@(;CnT}`!p!iXP;XODE
zit!JJufdU!>4)|KWZRH770N!$>F_$74KpCm99S9p!Fq5JYz9Avo#1l#8C(fjKGRmg
zwQwzzeVOav_i#NFKTh-&{JK%^arz3Mz5*u4*;hpD%kNX8pO3Sz@Y$F1%eeL!5&JUp
zp+vedEzZ8eXJ4i(M*nq)aX{7|a-h5a&*S4p^dRHok5I<Peb94!v{o_fD^6dAeTAhj
z=h`^?^6bCD(pL}xr2mSuukhJd@UL<0F(URAFgi|O;nkPiKl0ye^k1RfmvORAF8iKF
zLAif48p=FM;<=c}Njr{cJo|^f<!7B~^cxY)&%EBZat5^VEuQ0oZ}Rz7@-4rhmA>U?
zUFVxVZKr)Jr<sla5w#b8>?=^&XF(#1|0Z_0m{X3i*rTj(On_zJL@3X#PJ%Z05o`us
zuoIjHd%#(62b>MRg>xX;X!GEHxDeiepTpbm3n<T_E`v$nN|*+&f%5*nwNRc%^@q|v
zq}=|heY|YtcB=OIvX$Ge`iGaT+*Z{;y=>(UQvKu0RBm}D-KF~HH)yZYpQPb8wz}xY
z2HLOmC!3)Bz8PkKTcE6$ZiU6+c31`OfHmPa&;h@Lqu}>Y?lbR)(w`iJM`0j529H8n
z7d;M>QjVXYtc#w2@_x^gQ2G%mZ-5#XUY7D|tBmpJWht*+je{>sc^#*Xar9*=uT_ov
zFGG3D(%yms4g1Z`we$}OU?EO9wy<6z{_s{Pe#my11@3^-UL}4&Mx%awjqjQgx%?gT
z48P9T{B3H#m9O!GJ4R0aplgwn-=y|o`C5M4`pD()|5fDlAHV~!@vtLb%kLWNdwdyh
zg1CVv`KM)FFy#0+>{VlY91hbEW(1V|S|g#fkx@|gYmJ6g;TYHej)Od2ppA#;;6#|3
zOeVwZ@FQ3PehlA&Qy{OU*Ie){oB=PxPvBKJ6aG6ss(p+vOL<+cmrK76wQuuf(XVZb
zVgD~nd4ttH)t9BbL27^O%Tiv`+b@?r*fzXe{e!>Shy1eGLx9@<{IZnSrS@IF4CS>l
zwp*0{P>O5uALO~IlALmUr~Kz1U?%>(2j+!)VKKN5%D8UjG^uetvgrgVe>$@11Sr2c
zvg!CK|2neiSk<@@*>o(bKaXrWcI9_RHXT3Ze@8YQP4!EWO~<7Ai^!%Er2O*8rsJ>L
zm#jyHY+t8nKQcf470Ued4=D4~b5PpZdFXCmF4evwn~q)ivyn~5s{G8zrejwAUu4q>
zQ0*(S>G-Sm71?xxRQrl-I%efxL^d6#YG08}$EDg=WYe*$aWXRL_|Zm!S+He_sa@uj
z_LUmW;FKdN?I#&b1+zmF%m>pzx&QPUd=sXFZD4vh9%h6z6D<>z{j!<iBA5kkgIS^6
zkID{Z-8cuNnQOV=UobC}{j~X@v|m5YKo*K$hI0B%dO7qdFA{qh^l9Jta@4!l?&T<_
z-=&wsJ_9Si9Qrizz~#%(jvO0aj`r^S<>jb%+o;%IP7C8^&;i3fb8s!=yXSN77RFcc
zpNm0xj=#7XZzW!UdTu15@m!OA%g>>nBZz2zHnpEVqVa-Ne;tu{UC@gQM@ibdJP#!L
z<UdWG&6cAS`V)VtG|ULgKr<`{tHTPgHLL_XK`ZP9tH9pyE!YoMgW~r{egRg)&SEM*
zZEeiTXWwY_OED#%L+vk(sr;;?W3K+B-I~;VIkbI)0oawa_nlDY%e$1FNxWcnA2*`$
z0;U-D647{mYJDl9@#Mp=(*7bE&#dOR5shb3^Vx{Tv#R-PMB~Yei+zzVNZp5xXnw)J
z`=-wTwZ0S4{9In_^Qf}VpOk$b^RQ2cTE7V`KX37@uIKC1TRgLu_qTY9r>XUrh?djO
zi+y^_&*jBFy~PXgVxQjPX=*(sqVn0*`bk9NIn;VdMB`c2`bb3L$$l0;9;B7_x0G{G
z+Nbx!$a^qld@lhrz>;twECpq}miXpxe2*{va8NbFUej>xO#QUK_6t8r|IOY4XG#eR
zC0~hWeLLdu%*1mXGvdj$_%k9qV(Z7xYTtpGf7!Ac{e)b53uk8WNYV%^oVL)=Q&{1G
zwudiY=lkIcXa75V<#W{xUwVO?!k3<9d-&wFo(o^Trio#Pn?OBi_l@!qT(38=n_==h
zM=<YA6MMb^rJei@bHO{XAiN9f!F#X;{0DZ0525Vid<@ILR}%7Fa+m~mgvsC-m=e+q
zwNy~-RLbL;Wt2O%lqZ-C?G#aqE#>js8GFj3_lJWF`w_d4cJH}AFqPN=znfrIm>Qa4
z8tCp1HT6C|pX0MxS?b5v_*V6PK40U@#xBWU<dgo`Q+}G3F8@DJ`s;@<6MPIsewn}d
zsrVmqE%80)i}B(a?e7)%I)6_9Wj>k^7J)o_q3^d&4%_i>6Ldgc&82_;f+cb1SpJ<J
z{@cDN%=7Fy4ee0c`)g3zdpan3$pEFjXN1z;GeK$ZnW41ztWes!8A^N41*N?gfYROz
zLuv08DDAx%beG5c>GSRRMU+P#T%m}ew)YoN9?Q3}r##Z$1HH8ObgI3-uG)Kg)!s9B
zw0Db__8zYIUfO$j;yb*w_psuNA7!a#v>%xthxEU=m!-FNil~1#a6S|}mw0C7e?=so
zS@Pfpn%H9jP8*JwT>tBTsr02@g1$BUhmW}q>6hkJerY}^V{Cpn5f<?9OYM9xM$+~*
zzH@+4wvCd1h;iUk$|?QI9EeWj`4as-gl_%l<tLEj?`!;kIz~JBER_6zR{5WRGx_^T
zI2)dVQa^hB-F%O4Ck;P3X(|7ooFc!Bdrdgy$ePHIKO2<#&ko;!IiU2fIbmU#3l@iY
z;b~Y1;?rw|p_J3kX;~OE`M3%j`TRwm5s@bk;YFUJP~<5IMIMnu<dJ>Pp7L1tMSng)
z<S8G}l={i_iXl%%u7Bc`qY2}Y*k>~+<7;!6AGU_&U>j(K?O-d|0m``75q5)}px9Lx
zxCp)v<vw-~xCi!xdtq;gEo%Lt*vUY62@Zib;84gin>GwG3~3`^F*p*Ig`?qFI0j}#
zjtS5VKZIf*L7b*}hCcu6ayoc<6{`5p*QfdW|Gu31_&C^TpQ)%*>2EymL*-U}MII>a
zG_Ud}B%V|G6A_N5{D_Fg3sC+;MB?e=%N9evRZ2e3c|t2CS6lc6e{T<$!4A+pKAF^e
z*?o=gWbl*r;%j{K*M=SX5?^F7-BtNh2&vyR{6-b%#~S36dR+@;e&i3c!}U=5-wn_T
zx4=4ZE9?Nb!BKDr{0M#n*T9`{7u*Gp!*8MVv%6se^4|le!hLWiJOF3IgHZG><@NhS
z$;<CALwU6vFIRc}zj=AetM@a5p5H$`<o)yF?>&ZM$4{Wxk;DtCZ^#*1f8jMAlL<^u
zi)cKvm;UK_`PC#J^Ft#)X&++miTJG|ryM2mFGQ|Vuplf0_rtP~wG7P)rLa|?$Svvl
z&oShVs`N~Gqc**O-BFjG)U)Pg{Cb0aMeHLp6g_59{fxx3dl|pH#`7|Md5h=g#Xg=F
zPsXo+%7%Ruq@HCS>N$R0i^qFF2y-2Z-^#b+om7{01G?Kmu+@k!dXV^@<NH5^OUUn!
zU}E@K#be0Q>}uZ3w<7d;Z3cc5+moXO!@tC93&k$m!3vPE!Py0Ngr7k6Qt0nB=?sJU
zH-B?xp?vu8PNt38`*0BK2A9C@@F?s7HT>(IurTZeTS5n%0DD7TW32Uor(j<gk8<{h
ziQo{J1`dUM3qu<Y&2R)1y_h*=fFdjX`)bne<Qnzp$1RWhEB0)Ly(Z@`-ojZBI6Uc@
z78&#Xu+j_O5x#s~YW^HndX8J+E1zGj@Z}ryRru1g?g*c}w)5f3*E}igaMBOjFb1g)
zn$I)+DoZ<hzrf#gf2Rs8Lb$3>`UXs2_kU_Yu@_0te|FTRH;DA?bqzVDa4mKv_1B$K
z4(9B7`F@3O@b4g)5B>p5!9QUccn(_OMOYhNfz9AmNZZn`!SV1q{1DOxb$KLzXLlq2
zsa!{A{*tfcKglD1E7#V6hCb;F^!%kiDak2^AK|6HUI<0*&tV~mkM3*_mqMu*E2kfe
zTT;*T5fMs9@^z=<;#w9ZBpvCWL?5ZR9wWbV%%wj_2j{{3@H5yPE`Y7!B1m7SeGWz6
zOX0_G8QcYz!-H@oJONk1GjJ_TM1KA-8QcI<z>QGklX3;|l2Cq%b>;G(7CZIjT43}y
zv8^5*+hS)un!3ima`|EJ8Vx|~o_le6d*l|~zt6vXCGCZOZ-&|6R#+cygN@<Wur2%s
zN<SC?rCsiVGGF}``or(wCinvkfP3I>xDQ^2`ys=ob^zXof$#x545fYgaaw8^`it%5
zbbR@8=reGu(SBpQK7-D_9QE!$A@-M3_pg*cAnjMi-$c+o4_?c7pOk;oX7%qKuZJc0
z_Xa5b5N%k$KmHYzb}8wZ<{I`M73u9Ey<p|9J>go)_d49pDaSqXmHvo1x!jtRjP-p3
z@uB!H389oTF{}z@|3Ed!n6H;RC2YjMc^8edBjlZq&QVbI4}1!70h}u!W19Ya9#azi
zzD9QVGrzM0<va;<!rvitL4DmV55y<b@<Zvr3PRD3$Ybtd*hK=>zs8h2REsVTb*jrF
z{*lOY2#P%77l}OhzPdc;pvZF_iaa-<$b+u`mB-1otG`j-(w|HHq=5Z6<*=#xX$W)h
zZ)`%Jw>E)N5AVSDAU>UbU#SIT4yxJVhp+>j2B{n84A=#J0pEwqU^ggwb#eyJHp;Pu
z>+qDL2;rn0HK3G3#w{sFPblSZKs%far5v9?DaR}*<ya1-94n!_92Tx!<&1J<=344I
zK4&gYIXZIxIU(!>W!<;4x*sj^{8hZHT!)O;L&fU}CEZ>g@k}b7Ih1(vok+>AFqCwQ
zK+%`v7gW|LXCAIY=6CTG<9n7@q14+oDDkYE78Nfq*QVE=e!s)J=tJ_e!?ds+%n3zr
zxnU>h&flrhk@hL+c<KqAIur5xDp(AzR`IM{+f_V~CuIJM2q*b}4y8X>0yDy;Q1rG8
zy7LcE>5%m^`EMnhq_Yi5I@?t|qG+~?hTf`kZKrcg0A-FOM+L$qfdtXzuLP^|?>C|3
zEAfN9#1}h~_}x`}+JYV*oBTJvpO^U3z9hcbwdlX8iZAx<&fi@A`Q@iA=<#c+__b90
z+8*%(yu@cH(c=$N@dvB;Lp<U;yu@##;@eex+N3VO*pa*ZK`523Qxm^4r2ePTKZ*R)
zp~%lIBz=C)t&M-<`%_8Ji|?o6FI4dtsra9J#J8&a(aAIU-%#bJta|=`L$Q-v9_6=S
z43d9n@mH(-`6iMce=U^w{vP?eyyRa<#b+yn9>0i+U(_SMNy#5t{*P7p8Ef_U6jaY2
zpYUJ(iE%%#{96ep`e(|e$7idu9-k$(f8*P|<X=w3FR$WPQ1L6O_|k9LRDUP!dJm^(
zzmbal7Se7_Fg;8S#cm{?L&eL)b;x+>RlE!^1Aoux5zpc!zaLrum;ClZ$!{N|uC*>q
zj+$rDG;{p4KXqJo=ark~>NaV5XJndL?>ubOGSBLHmQRn~Ir-M!2e!nTc9zb=9Dmxj
zhSScJnw)u9;QaVC%eCEI)AIGBSt|lY?EGTziA4{V(~)JiO1M^cgUZw@o__9Uv#R{M
z{<HYwe>%3IfoW^O{FRID=yHC^?k3F5^n4Fh>G&|<t&f@(>0bDQ1fPAGER*xrz7a$B
zI8IN@e{t58<(Jt*QCQMzWF6Rk>D|W1U+-wHe7FChj0+0e)@{vN?f${K<;!$CHR4Ow
zV)9A2=Hp6^4_KOd@2h{OIrQM{lkdOyqI060t+p(DZ~DpOGjBSu30qbPSK;q{O+I+5
z#>5>J&gX3%bfNC1-`l>u*wS=H#pcES*s$XLaqQ{P!@Zq&Nzm?FSu!q5k?ySzDrcJS
z$~*Mi0oC5fJ7~<d1Qq_MgS@--a9cXB8dCd%hMik}pKal|mKi_(x_q+^r3#hnIPlZ`
z*P7gT{UZG@x;Dqpu_=-N;-u|9$y;#mxre1HHb}Q1`ENfaYm;eC?}A02*uJc+Y322B
zMT+EY*z$4pT%~U3Fz5Jd?U^x4QYEcCe)S*2H?Q4$$z13w>_iVYD#_!@Nk6s6Yf$>|
z`cqZk{b2OP6Xkv_Iq-6#8>8~gNi-G%`b-ZOr0qI?E&ue4*Ryqb`}?*B?>88g_SA)A
zeqR?Vu%LU}i*E%oht<PP-kJ8wr!6l}Y~3JL{Z9FdkNbRVC&#@7V<*fjI_lGV@ej^J
z4ztK{HQ%!39dEt&AbrXFzij^eg9<_0CTCnWWJA-@ON+fZYTb0wE3Aim&~LCSY39j2
z>z~+oXk*I5^;aM5Un5=V#BYB#|JS>jJ6wH&{psPZ9oy3P!MZBJhtE{re)HnN9((SN
z$hZIX?DI}0y|=ab!<ENbOVh(OpVlJ9*UNjj(sw()z4MH^pWGkuapy16|M}U;2ZQ!M
zDs?u6rk&BlWlxjks~^iIx;^x0)s)&7)AO}2S|R15Qaz?5E08zW*wYgkXcJ`@IYvw^
zU&4BAdWjZGKRfi@vc7vtKbSjqe$(7{hu1vu*^xyL+Vc#k9`3JuuiVVH`0UzK>yyl=
zcd=rf@_z+3x}0rk;VJf0iF1B;^#u1C^l-oaF*0wOE$0g@ooKCDvTx(~hr6B5zGp@G
zUsf$Wy*EdvxAQaB>)}@2`?hJ%e&sLLy86zwwN;z1AAM+9@uOQxTRN|6@p-d#hv#t5
zTMu`>^y1zRN8Ee7>)@GbIrm?CcjMi6AHP<;>xQ+pAH4V1=pI$ryR3(+fA;nDN9w<Q
z=)0q>{@PHp#HKnWAI&NE$*@j8H%)ry=;r%<*qf0<<h^wMV(LFyymBqmoiWQ=6wAG&
zX3Fm6E!Q3_C|oOP{?zLxFfg{z!;Rhl+EqusnaO^>KWys#Ni#>ctbS|r_OkC^En49H
zx%<Die!yC%9xm~BsY{)@u%n%;iMH|X;kUY6KKkVwflarTs<V4wlZPt;ThNE;;U*pm
z`r-5P_1^s>cjexl?-xwj=c7yG?iK&=;KgGf>~5L9C62>wJ=~qZX=9wDbIk8-eo(!6
z`A=H5nAGo9j@k_tmw4w<zp;6a6=ZK@PLZS9jyJx{aNe>tS<u_JYS$<=?z1F!kJaAX
zD*tH5z$9rNK5_DFuT{cze{|^N?^o>c>ee4Ieroal2P>{RrG2!$+>rE^t^@MCzho18
z$n^A%^_iNk>A4Q+FZJ7$_~g=V*UwoOjOaH0#;#!pE>~Y)YaWC2)dG^<(%-dqZ<&_`
zr77$BPMfqZ$EcloD=t0Qa@~<x_s2i_daxg3xt`t+?{8kxK2z~G{nyRER_D~=@9wr<
zSF!M|IXR{d?DY6V%gWT-emz{n;U~72NppPGoW1)mZ$7woV}(L3)4%#prC%z2lsoIt
z-JOvk9!|MA{>~OHF1Ih>e{*=jeHFU&J&>>Oj$@r%U9Iz{_q;#-%(|UP@agn$OBXmk
zFEoC^56#AOuUbnRGpf;s#!a)-yq@@-^kuV8cC9_hH|q6pqj&5dv}0wuHw#o*TA-}m
z{6>ito6hzy_nxsgczT{&L-S9e9qHlvcer+^^^+vmUu$D&oc8=2zkL%X4qmPeZ_+<!
z)gOny=Z74ra!dJ&o$38#>HPk04lA{?=oh=*pVe+;!yiY~`sMJCS~A<#FV<1MH}!CX
zyXDB^oaIXV;g~HMn-m^3`Fs`Ek<`gjFPOe->9-RKw*HGbiXQI5q`a@E{cYo3=OIV`
zAy2BdtTHtJ*mU#z+^q9Soj*QY--f}<PY+kUZq2u=z7v$G!^Z>vJbHWJk4tuFjdu=t
zeOsTSImXPb-M1HeO7(C_cFfD)>f)1AdowgmvuHzxjgGwj*_&;gW~yqrz9;*GMU3@n
z^N1YUo_<?KEzDKq?B!iq-@o{N*PmB7Iu#zB{Q85Hhc1ns8~?1PHPpjp*xM+<>&>Qq
zu)XxWS3hprBJJr`{Rbv)IlV>t%HMB)yG2tw?~>KSZChJwf6EWb=N)USzw?*2&Q})w
zvGw;ogRf`$rQzt^#Xeg%5+6hlw_yA6Yaewwc-=YZ#_OAQFYG^H$*!gG7Z1I2VL`&q
zv)+|W!58#!H-n~*$^7Qyq8Ub>kMDQ8-Tre;_KrR`xn$|t{yo1RIoA&#AX{FMV|}un
zIeVv0Ix(eV`1EZ(v=38{8+x+Lyo>`~f95<<X0U_t;{!dMrAf*Styc{GVadMP31?V-
ztC@1#m$kl{{Ys5|A1zzt%=8Om^g2CU>!4Gvz0OwoH|HrGxHCn85vKVg4=>HrV${A(
zt5a`2c#*PQ*2DQXN^oaXy(~kAEzQ3%OO<JXX9woE(Jo-!(H!?@d^6Lwwmo}p^>KQh
zefv-2$6UX7@N!_Yj=P)Y`*qQ=O!Wr+;#eKH<}WQlx*ySt9`2(7ueG@q&-(rG+DQ-h
z{XK85>s#J0yd`mkch~pIoxDbg`=8>o>fv_%HMR3!J%{_9J9Vd3olnLM`mK7E&sLsX
zm~wpOC7(|jm5u%{JAJP?ezq?ckL$2I<J1|whfQ5HHs#EId&_6~pwg*crEV>M(#cYM
z1mm0D&fC1>xR=CH>U#fx!AVD3FBc8?t5ATw?eWo11}-mJy7;i!ydzi-m%sYd=4poX
zUpxLt$}W#8?z!+FP2abJE-oK9ZCTsg-)(KYi*JVN{ZQ-eZ<U|!H`dzkY_I#r$NxV4
zo9my}`)Av^`;7*_mt$wYU(fN*B>FaU{EqtryFM;iD&x{CiDvI#`);rJ6K<@{knEGW
zqkFpw&aUW>yv_7*JC-Cq+@Of{l}aV+Zh33p$%!|6Tv$A^LaH{ay4Ex2?wtt-f4ClQ
zO20pvd}yEX`Gopi`#;LHp;p=I4Xqt-4bRi*x5fu9y}kJob1=Q$Mi=>Y{<-&umaQ1L
z>R^I{>Em6gd3JvOMq56}F~3-fQ90wMVs5IZm#q5Qj*~A1?LT&>@yDH3r5joJ>-Oam
z585|l`Kk=%I(BKYk#Du?^-(ityE92%iQoHL@@xybmi2phrB6Vkd^I+dNmTXHmPfrF
zJMcGjy$oEJsaxM+YZ_Iqzf@b8<tN*n=KV$we0Sja_YOCom7`XN6`FQh&$o5kz)gMY
z2Y*n=lBlM3A@GgLX^za#wP)Rq#2c>s`Bj1GIL--l|1`_R1KIvwclO}&VIA8HUu93<
z_3(w^nWt}Pc%w(<hF8*cy}&(OJzRo>rPj@{=c(W3+^lTF)>Zr_*VpM+URyEoK=!i@
zS`UBx5o1wm`Zja?cQ0jb=|AJoB)jYH+qN#zlLo~mmwYtIc0P5+-a{KTZdPFudkggR
zmLE#;^_av9XPT<yI=1=`%g5&WHIC*kc%Z<M6sfY88B?hpYf8HP{j%}i;*Co;q-b!X
zMY$@srwz7uAF%0U^UHNDSAIC-mt{d>zSW|qcd=2Gy`9^QeZ1@N%HH=beKTY2Z~OaC
zYVgx{`F`!%a&+?+j9a7h^p;gDx**N@<;j+x+}+_X?ZMFGWioERvnf^5@ues9d1LEA
z+GP&ie;)LxW$(p)`{!j&{a&}5qc@e$x?xGpG8q=u_;go~@@tFU#BZvrhpV+N-|USA
z4>kVl-h=+<PG@Re`N5C{<?7phE734$biLY>s<OtR=esY{#Ezd=nd!3RI<(opSmCR8
zzAj~IWg1oX;T=bxnx$&orhfJGzS`d};iR&YK2Du@gRA<l4gMUxV*SA2JdY=y?Kx{n
z@39N1-y}su&wq96dwtdV6&qT#%Q|aW=FwmM*86s|HM=LTUR&;Q(A>U^wVG8A_x{!a
zm$qGLH{#UkB`fn=>U~!9*5&yNJ3bn<JZY=3*{tuz<C_(F`LZrw^k;!yH)pRNoS<#;
zA58i7E??KD+?;0fmcN=N#T%Kfq+u_&p5BSOpK0HnEV`&vmjgd`n6UIl;x9+1E3~P#
zWmTs<@iJz~N4wmlhnsiz;_p9x*=ks+tmB`&JNwUeo1UC*n7KsKmGf?OYv+IJAbKgT
z_XjI_W-_PSwYzd~k0+<5y!Ls*B}ryX`Ek{>QCo9&%RMUpTMM`cucw!JW8jeNAMdU>
zxYWjC>)KX-n5t6#pDG-lb|Zg_gjw3{{-_!Kcu~>Ir;kS6uU^G=yKDPzx2;|A$^8l+
z49k(ZYMFC?e!A>E?a~7J`(DK)+}%W9{x<ILj+=!Ze>CpQ;7Pe#{k|h_#$!j?OsSRb
zlf>^9+=XAKr?)dh^T0gXxWB&092`)%REf)1der~^wTc;L4xcpn@#tc=T=Z*txU+-W
z4k%Ek;i4|{CVo12Vx|#YN;K^oRB`NxCJp=efAZZPbi7j!cfM7t-*Q<UzZ~4UXIhG%
z_RsvbQp)U)9_-0gJ)lf2+r=^CS^L(*&F#5k<X0Ptp1;(s;`v^~@?4$KX>{gXZ6EY@
z4B7R^jP8kBaSvUW<9@G&l^+gRx@=>QrrG1Kesy!zwO5bEue5n~-#2fzo?*FH20hc(
z&GCcof7a%$j8)s`{^gt6J?iJo|MAtiNfKSJb+!8^tLI-ipJFt7g!FKwA0^mYX2l_E
z-OWXwZ25d#$uD2|v{&Le@v^VE)NtzUTe%+ajV3+Z#W8;*8uh5s`HH{S_MhK>e#-`H
z<KI30{vdndMXRQjTwf1=<BT3|_ND^gJ*YZ$X6B4nZtq-wuFA$T_Y;_#+*s0c$D<UN
zdtX_|+Pp5uwtMBv9XU~=YPKg2?gg!P=2&8Cd#UZ+S`TgahIG0xd1)o~o#^2vmzrPr
z$%plt^m_B)k;gOI|F(E^ohRS#`626pDc6FFj98PM`K2CiR+fy3tC!nX`n5V66A#!|
zbkwlM`vP0{o7AZKlx7)=Z`)ssXMXi?)wjG;>h6txk9w3V)~(Ni>M6f^#eYZgm36d?
zkM<<B727$KHHPA%zhV8-{AMe<=~B7mGk^Z^UcyC-QrqW#viZ@*ehIC2KRmhnAZtc?
zxRaLy+Xv^WbU4SA60X<V9$u5aaf{X4;w?xqs?C;H&fQ6mKU7KYC&v$2{8_dfqv{=N
zUw=?*OC!_KA6C7Zrr(98h0fj?zdY0KeY`tgPwzqbHP?&RX{{Z6_5I(|zjEf=oxgVc
z=T+0*6&p)*n{{;ct?8^`>fy>hnY88WVgJk@+_upA8V{e88Fp!Lk!GC&#}0M&UzWN5
z>@&!#hx_(+qu`qZwAG(x`f2lq`8g77YFYbXaGFvHg5MmJu6l5=iFs%Vk+=Nbip3Vh
zTb*{v&iYqB`g?8iHT^%Xf9v6bLj#VdFOn(cKf~D@mRZ8}?vQ@wsV%0;oi`3YocHA1
zU&@qD)wbO~liMGfKK{+ED@V5D*%Ljz@jKhU`pxj&R|gNex%>30TN&<bzh8Gt^*;vg
z>th?3>?gVdZIK=>u(#>_-Pv=l-M#kn@HWjGym>Cw&4bOiXDU<AkuFn)jbC(NZC=;k
zg$}L%+VyRj&QmKj>pUpumandKwv2m_ZFBj4_t#xmzOy8HIiaWbL59Sg20mCc;Ova6
z-_BXFGuw{2-)CNQwA-dhXZ9blU%ANqEoDiOV@Ba*&db9y^t@Q=;e|wX4;;8uzSf4h
z`{Unkl;o>#N93C|n0c)pE^FVqS@PsQpK)=MAw3&(7&74_XT3s?Z(l1vc2BX4RkO^y
z!95Z^+`SzA@+?Yt`?uonUCGh6n&0#imUk9>GsNEa%cWP%{$Dj+%U&EkT*dLHKfZkC
zk2g|(u{~+EW54~C^1!6MNh(xs*|AC9tRs{CkdAhwhr3Yihd$k__U&=E+S?o2H#`&X
zkGcD=4R3bIJZ0dWOpAA|n@T$>C34LEvyA!vl_|fTNV0Oqjntb<v`)6@QI6_MR<A6-
zvQSXd_$L_`^l%@qxw|dn*xO?+Semr2^;XG;O;;T2G5fF2`c}_d@ye=unciiupB~Qq
z+2BXpHYDxcFJ+7MrwVr;_s6i5^8*WBo3}lC-(EX%<yp=6tA~5vbTQc0^1~jbdd%+8
zIrH?nBmM2>G-ulvYjF3QzzhY(u~u?Q54Y#coLsZEuX)uq=5lKD&3Eie`v36B;8~W;
z4dRX5UDq|G338McIl3Gf^O3fuM82ZyJ5ES7s?*Ic&)5$P$#c46F58lg^{QP<&7Lwn
z+_1_W7tG#pqu<10b&gj_)Vxx>4%15nRhio<XTb&?Hr#8OoN-GJw=C$6mU&Q}@+Ti}
ztlRcvx8~pV?X<h^2ZffcztlRY`M`}1P5V+07r*I{C-IMGTe*Glo+WE?Ex+EjZua{<
z$JXv#e%#TwdX)cQ6MMz<a5es(RUl33KbNd3zHZ8zOrz`hk3Tc~yLN{gUEIHNZvK&L
zg1Mhb-)oM)Bt^>Ghc5PLU%Se+IkWoBOWV8Sy^h^~yW0A8g<W+go=!u18_B|@IewXh
zZS!>ca{0~~RT_@``Mt#>yWU@r{!*9p^NRJzoNIEQu63AK=yty%$<~?<YodEY&a6sR
z;rpanT1`tiv}&~hEw^1L9Jpfac>E#z8<JkyjvLBO&e5p$z<C+Z{G9aKlhj?OAIYS3
zIae-U>QTR}U)qp+x_bGh-N^9B+2Qn)mbG`Jdb`*6lV|n$rv0pjZ;o!?BH-xECHWrG
z&h>CPvdr(ZV^!Mv-RI;#uq@e>^-Jy^57;^J>l^P*Z~a5|{K>E2@9N=>m3~mE#m;Nl
zrzTIEIH09p<5d;Ul{!Ds^+&~|#|AdP{U8u~{y+BK0<4NHY#ZK+frX&hg^GoWn+{P>
z#12eU)XioGpv0C?Y_MDG?f?}PyFIoZ#qLIrAQrab5%s^HH8U_EvPWOv@B6O*I&)pa
z&8)p<t*6$rV%9vv@_i|GuKmd^X6NrVxtsssy&F&a-0ye4PoK80V$F0G77^WtVvif+
zw?pG~3l9|8IoEvB_o810A022~SZ#HFc-Og84iwy>7--Q2{Sos+vv=OQT_?8Cf>p1=
zu3TAldECIAEk+hUvgS^W#<v@l_#A>ZWb8<CsdZ_|@`bZz+C6!*ed^$H3+}wnw|S(@
zbJ}ueFWcMm?bboRjWCBZGx&C|b+P01;(G5dRnPZG&$B1Cy(xF>@EPA}+h(_4H^cJb
z5!fFqFWuPZ^2jQSeYA<M+k9?N>~sEGqi%NaJ(MxrpvF>F^1)*m@3MRuW7dzjw{rbI
zV}=&pSGroQ2;-qIUN*S*s8syk^v`S8I-#Fg&hqW5v90~VxaKRv0w%nhy7al{pyZ0L
z%c~5VudH+E;LHMrgE8J<^ck(RGka+kx%*C&m+^@cEmEpnD|hG0mNAv45BfJbarJ3A
zw%@Vxo?ra1P+NG~vv~V!bJN;Rm7mh?x2!(#;f~e5@ga9dCc^JNW91n>iG5zI_{f7d
zlK)-4Nb|AwhuB)XCVE;Ni9F+H<6d{q0?b3%x^2pe$yZPH`y6uZ-;D1zZmo|eDoZXb
z>2#!D;ls{vI`|BnkM~6}#xgTla_H>zLMi=+Se)G2&8peG6ra5(YW6d4U;JdzGgsne
zcQCJYXZZ~8eINHC>P`JJ{to-kcbYdR>f4HcEDUeoAAY3&`Ll+zF5#Ik%XiYK^vF@^
z<3@k7^!yec)5$B$vtf<pku^KUIq$DM@nh;{>}6#6>cn)6DdHHuq|};APnvDHrmisA
zYgH@rBloTZUXj-@e}M7*1D5am;<V|>yEjBX`?RR)Mx)sW<%9C2j%XYe>uSEB<C3|R
zm53SOOnl63c(&@qk99h9dbVMIYbTSS5+f%M?ApHbh^5nSS+p!LYAs^ev3%BEn<js7
z=~?7ZhrZ=rmi#)UjYk#NI!C^SkNWygQfyqAF?jI8@}2BB?Q=-MQTGoN2tPQePnz??
z5&yKUU+wQp^LvF=e|zb1D?A%z`JAS|Pp>ny>YbjCEB701lX~|_xJQkB(-$m_={S2~
z#aitLVts?<3%z07e(czm1;V;M(X4IuFsi<X@u}E0<DT4_FE8-kr%^n3XiR*R8T56B
z(Y9I-KG;sW)99LIvs3%c-=tK3yuMF^QEfxZ&RHUpbzu3PRvD4jp~ji9)2)oxoKRRl
zoH^~ZrqyisN&R0e+SN6!GyK(5mhVmbpd}Mi!ZX?{ja{ry=(_DLwJkn&W}1a>YQJU*
zr&!p^5th%j+Q_tjFY9JaXmfgzh1s0MWA7%`+j{fJ{Ez3u$2_}Sw>_RgvwR`b*5C18
z*{RjY(ZvcDxm@Xu$G#D@9FsasD_phhgyssXb+A7d;zRe)^3@5qQQHp<sebeB#k(JR
zy}A5sPXA^J33Xef4R0J;2IE}}Cd>>L&5dn-!)cDz<YPW-$D(J_liv+L(X_lx-@RKS
z+nn==*be{4%JV4vSDO_D9EvBE^GjTQC1c$Ae;N%rH!&t5@Y=>{1^2cv#JUg5_d2di
z{Go2fy;m)&G@!_s{KJpGI6e2RbNT9Xm2O|tCar;g*~s!e`S*RfcNZT#_}V$T@i}kv
z7s+?VHF2Bx@NC)2+eS4wZaP^e>&NJG>=J%q$DBGRk92N+Vpf}cu1;T;`dxXga=GE9
z^qO$|#SFxBXXW`ub?w~dWTpN+w!SHH$iABSRomEgiAN??HMwXpph?tY_`mW^h~IuQ
zqbjGB+ZwTYeqxXBhC>RExtek3^tDD$_J=DI|FvH<4(k>y-}^b*)#W3uv<>c)|6RVD
zm4-&X?X$PlyXz^>23l<Iv7^CsJjY@Ax-30E@c6tN!;IUFn-HkEc|E1d(3cIDwNoF-
zXFBt1j}X|wGRDWPwn^&7_pHn+Hu_r5Ho9!{`QHbmRheEj_23BG=IR3e7a$i_-j~P`
zSAss(>g>6*fP*%2;;3dPF5cN>oKdT=N7G@?niq+}_<-db9__fJY5oc3NncGHKU(5;
z-@AwB>ZJ6r9$JgRcQ%#xD+T}3l=y8|qVW;OXB(&eeb4Q$twlb3TXXjEnJu%fJGcK>
zbo$*dMra$><tg7LzwH$p&piLvjFRgTj*RH$I`Qd;p~qv-l{nUJ;l2yWFCk}NmTzp-
zSkv2YqX#LfDkcoO5<fWq)$(JeEngL0u<D6*k&DM2#QqPKZ*c4G3mb1OF=xSrX^WO@
zZfF|%rS5o#sOzTVQg5H?-Jn0lr-xX+v=E!}XRj|!SXJ!HOP|+;O9U_8>S5$@=;4rk
zu`wxC?9hJSuzXX#R*X!P@4DhL@t=<sAH}Qv&nNkWbxE66WWZVn?+$L2WioFzPcC$J
zqqAq}LSJu{>o1FI>b=);&5iLcU$v_4;dXT{EPQzq&j(q)mBs#Q>9>8uZO5Vmq8^NM
zU4HPc%gLE%yc`!d_UrYgLNc|F3M7}wCvR-n_s!e6U(a`|b)jyzcHN$~rf}qenO<k6
zuDD=$qyWa*EZ>NMyOTQqeZunmydzI$JXyFu!{Es_v$K;@Ck`9F(&)_^<cnqbUb{4o
zw+iq!?Rvu8@M+~&&%5jzclBI>{JXw?X?A|;y!u$%xXtqEA9oh7Nc8zu&fg_2&MMk&
z*75cI$~#*QP44&Q;IPRz$8Q-iabQLVPnoPG%U7+c<AtFc)0*#pYj7y7*pmBBHQZ(D
z76&iCY}F&ku3PhTJU3u=dMNdK+})D{gKNH1H19ufVw=d*)l&-ny|%b~LjSq9hUY7W
z`4P)k@~;V98x(A;4RBl6)#q*N8Quf7rQ}mtTCaE$w<7Z9*K?R}v3m9Q`|nu3;)X3<
z5A?1XH{Q}KU|A#iJ=1edcC0C4@Hk_=lZDruhUm9yRU&@%=UdA1O>vlY+PBOnd-rc9
z9pbKzT6rnr#f{4?EUU`uPnkXThLbD!W%=~`jY6<3GlL6p|M&*&Gx1+I|7ON@@4jE&
zA9yt_Y3Yr}snLU$w!WlUg?Ts2r#e|PuFjkMe|65cXywP<EjC>pb58rxJTm{&#(fX;
zANm08@*>N(YjY{J*MrvIZKe*IpnPNfBsAS_-jfRX60TYV?loQ99sWLp<<o64sV!^V
zE!<_#rKR$eX}j)bw0rPZO#@Rq`>ooPebq33`|tQq0{=<iKMDLNf&V1%p9KDs!2gR9
z!0=brTb9p+Xj41)2?^^H;@iJZq@%qyRMRIYAb5Z#G*}bZM->_#)+Yjg`-Fw6`Y3fe
z_HVc{G(1ArCo(9U?xH&aY#i<TXd(l`Es;QFI?G&4^7-IB2U%%ZMcHGWVJ3D6P=$ts
zg=oXg>UODT)=3v05EL*pAlT2$JtRmM5U2@7ToQ8=g<_COp$rcX4e*T!*M#963v&~H
zO`uK_Do&+$L(EN-;en`w?g4d*uyAF#MiHb8R{CjzG{NCqp0IE=;yRj}cm)KjLk5S*
zjPQTUkceQlGCUvzYg1HCGwh?uE03kDxXEZp>~sm*;~DNBs!^&Hfgvhopn_Oe;GaNW
zrD}je8xf3UB9z(QBpP$24KiaU=l1zYGF)8rBEZr(EgN9pdtU<?-oW6<*DAxp6`EjG
zh+3mo1V;o0>cT@6;m*z>U|ks=66!K2BtUJZ0Gn#6uP(c^Xb=$`7T_1GQJV#Z1p77M
z66-ZJWB=66%xzIG&-|dLs;m@3h30mcQP^|nrkF{__wV0dnB#eYe?S=J%nwd4%StjH
z4f&e~BOS};GLpk8@VG)L;xSC)ukeddh7ya!1mme`7LRr7xwr%>gM8IWh1|y1O6_E)
z)My<Yoa~+C){ZKzuhPLzrBeD@+uGSRZ6M^d*Vy{Xom94ta%*c}Ya2Vcouif9)=F)s
zwfB{)Y*kIoYG>v}4z<?7&dR~j)>>ujYooEVaj>>gYVDLt8*5)DO;a;W)tM|X<j*{?
zbRdhooDcl^uo!VgWzHs7A&as|H<A@JG4LfGW#;WWIzmnbP4Z`6Tgj;q%9E95&#wPv
za-n-1*gaX-R#w72S!s4m{*O`T3dmHDKj{R^J+c`{3)7%w;(tmj4s3-qrHZq0N+TYI
zBTW^kQ3fL?>24k9a`QAK+7$|ozrQkAjb>=>>T0e~D5*)o#s?^n%9Q2SL$bu(aP(@{
z)5}&|PJr6Y&D^|mvtKHvH^|1j8k~(`FEu-Y@V5@mUN{GVrvx9~#(pF^)1LHONmHhG
zGn6SDWYU~`j9D8Xz2D{aF37$d_MR~@1*kJ+-&7>~jxs}&Nw^kELXfDlvqBMQ?d&Yb
zRj+k|9x88<#PamEA(TgU5X$?hJ-mFey+>9MXKkEv)D<Pjmu!OhDYb_DltLF05FD=I
zU6W*QLrsjynlP7x$=Zmw?NRV9WY=OkeelePjz&0%PAt_hI%WMtzDDFv|4-A|kC&$@
zHBKB@!eVri-(L!O8jJnDpC(+P3k^Z1r&fn*!ooN|pG}yVJ|5Dp2kDWorgC#RvdQkO
zDT|{5f5Z8N*N~+aHyO#COsX&%@cto)BiRn++gK7$Gx<O2tH{UA2F-4q9~VqjuW4mj
zwcf0ZpP%(T)~KJ_8udNXL5JY`%JTL>K_OiD21te_<|UpOz#-;kH1bDf=S6R`%i=|E
zR>`~!`$b-k7v*@tZA>rJHa&3R$+b;EFM8cv7B70UO6H}Bh?k1IUT6=V3*Xr&g5WHm
z9Qv&|=ys>yLeXJ`1`9tS#xB=KU9Ca)!Ouhl2LuO%2PgvrhO(iWB2+UlA|O<wZpw5#
zl5b;Eu?|WHmM)oGVDhrQDBq`#$QPijfe{)7*TE^mUAPgKKgfy*)F{G3l>y;l7>01k
zk}~Hh8}WFl8)y-1R`6-mF8x6#+3IMXkJcm@9ONs=Y-v!Xz`aqw!N<s7VFdL^9s7xS
zA=>*1K7*$n%eaj8a=>Yz-7I@M)9VPt13?s#CtYH{FcozPG8WSniSareV!DPRuTOTm
z^fv0>rEADf=t?l+=<0)kmm~gd3v@x=*IfVg3vF4L9Mr8xC6XRdOy)tIgkz3z>+#I-
zOF@%I3Sr!8WkWa7*!5vnno}-mwnEz3%zU(4kGnT3&5G2+{B{!RYb=sORm`R6hKp=2
zrQ#=0m;nZA!Zk>zzG)#>wv6Unq|c^8e_E1C<>Dk!zfUfa_U6jG#pAy)O`t}FsT9r3
zsAI^hzvSjNTpipPa}Hkz9{sRBn{0VC>Nw2x*_dKdxtd6o1{2tjV1+gy5F?<x>Oh<_
zlp*-VP_%u~?KF&HJoe^!tjqW8q!980G{zx6aQHX;fGRK~jAZ(|?YlWo(+-}d`Y4Nr
zh&1-@L^Sml`Pl5<)Y+M@TuR+E<d{M}kxf828#u$t#yk8_0N17qn)u{0S5buo1wjp@
z6*lK+jY$V}AKb*8o9wVo#?4Lqi>UX(Tm`cXYu=YRmI5(2NN2?7GMtX!RnE0dQFWYL
zF&)l4Xbi*Am^ELx$+tIQypkWX<SS>o7y3kN)FJLJsZhFyL~n=RL<F<G@*T>R<F`D!
zO8nju^M&?Qc9xuSPCN7u1W*p?pgAw2R9;5TNT+s4KCA=kh~nA^6MYC4FEpW8P@+W{
z8sB1Qi)_pm33EAEI}zk0%ONN73v>A~YaILnT`%FU*YVfe`0EhRLiG0F?KhGJ-Z+SC
zYE$HX{g7wHZ?q{4*Cn?nE$R^WOTL01gRRp+x+Qvw<Lr;TGERQK(0e;O)AWI#IVeIf
zxR=u2Xe^zxFYn0HHj$@|=px<HRLc{zz0Rwx6A=NygD_T8EATf0PKW5gt+^aoKG&YN
zCvzI~;24LKd_go$SBwLVIlmqd#;@wB6<CPGZ&WrvO~F;RBh!Y6M<<l44hd8EW4(@i
zG}%@<(i<aPhv6Wf%xtM5s|!5iH?p0UJZ%Sf+FGF+@_p_&i8eW>t1$nNh(K<A<mdLD
z``m`>7iir34Kyu-+`(O7fQlRK4$_1MXalh7sR>s425QvACDCP%J~}EFKNuc5M4>{X
zV~vk*Z_FXKA@4@(vRwa`NE137`*4zfTZfa{?g~!UxfR3YEnW{JemEMk{2cZ3RP@i<
zFU{dzBTq2u3JL?I8V$-VX7U1QI;7>K9Yry{B=dR+MILJNjai$8{%}q5u;lI5kveJ|
z1Z20Qws^?&bua3piYPqLK_Dp)yX3zAAkd%FPg7l8__`ALx@f3Cb<r@hIDAlo&_>ug
zROa*rGmM`u8SAA-7&jO|=;GC3RGE!`Gpsk$L3|TU<njuk1$y!{aU(7L{EKB8{*yB0
zLYZW2sORTxos+4!%p|_doO-&*>xnN?Z<%@NNf@`Zra>GIm;sXs`F{uKDTdXRPXWiG
z%51eXm_sKij6<dHB-q1Ez8-7`V?Kfg&Kpswj+axY#xEcYy<tu}(BP2<Yp=os1l&jU
z{>)!k<9C5?S{GBe^A8@7PBOOO?bEFy5^&^{aRMh}CSra33H9XG4y^fl5`I#TG2^=k
zrt4TfmS`h+)mIy>i*%RB&l!Y)MGlq8-Xf12XA(aSApZT)APj)!IO!;Z_(9aSl?758
zDaXeX^2Glu*t`(m2EqSyAN74LaME!bF3%2l2S|Fp3#8xf1KR^10DA);0qNPtW1v6}
zw?56S#W_~VPR}{SK_WkV9@q<b87SPxt-IpAQKaYO;}hbLP&-ct)&>f3n~8sJ9h93p
z<h(CG_@(;{fDM5~fI@xTx+LdAa^6>yzYpIwVREa*-)Dw0+<3WBA3^+KI?LJ|Kz4!W
z#|-~R<&p1_C?B_`#l<p8MMp0#4;PvAa%()?+D}foc0inO(sO$tnu@F=P~ekWQ{ni`
zd7l@5Ur+wNUi^JTzZp+IttaHgr%xXF1U{2c1~=bF90M>&e3Bcvij$5r5EqTB6M;15
zI1g+Myaen9yaMzFUIS`?_kg2;WQVJPvXZY^Trj$h$0gb2Uf@5#{XnwM6TlSUWnd~0
zw$0)Qe*iwm^}l>NV(!S^;hN&p;<qTopkwjw5X(pQ1=om?Bl`+$2K)x3^$f9|xcNCZ
z&b^36Wq_Z}anf;|x8u`5n$Mr%_3MWJ5A*Gq<U;ZxyS2qh$2`<S*Yklio?i$o16%^6
zcE1!z`X-rib7y=T7XOppXdLH)la3+0zJ~(o{$W76e*~}=a3qlC;G=+o{c!VM#GXTX
zPW!2gd{lltAhl}?{yu;F&&?sZxh3&K{Pw{~$3D<Y`HujdfX9Fyz*E3Bz`uc!K#C_A
z1*G_ZQ-NiHvw-D+G*_(%6!?zf<>!oas!z=KIFv{78xN%RF%gJit!xU=5;y}$_7?*b
z_~zzI+&n5L-{Ihs+FJyW^f8F%oB1Q24r8R}yl*Oh-!x!x{61ZD-)q*7aC4-b_ccU5
zqTdn-lae*!?^}WYxp@OOpCG=8zd1PRZ~#9@qB$$`V~{nA%LW-m!8BOBG}3DmT$A3h
zJ(b0^Zw_pUYj<E<AaujxKO>EOm#RHbgY*u-0AOd}FklzpC?MKwR5Y+VkmT7DCpU+{
zvs(O5bP`=ChaDlvNBYtMNp7J)Qy^@B^+Q8|ppnJ5Zw4HRYtSY`U95cE$B*f`u|Abw
z3~6edbfA7_Z@qwaxb6+?1oQ?XP1YBPI<dyf*_{GN{zVC#3nc%tn7<~w^F=!GCCAB)
zxw-KN)hllA6bFp-2H(Njo1C{-x-Ws(cS-!8^S)ImpYB@?r1AC|QGK5Lebjz)-q(b$
zuPKoFdsk6?@;vTy<nN<6V00hF0TcM+#;UpVM{y~MP75H>BgESz{<v``*Ei;*6F!yQ
zR~1+ac_|(y)#rv&$J0srru(RT!4Iy79LP>K0&4;{0qX)2fUs@ZR-iyPH~!0=ZgakV
zinB>{Q=CoVK4ZRq@{2j?w&Cxy<?pitzDGWPIQW_{NHc?OC*8)EsA~Q4ZTB(fbnk~R
zSTw2Fo(BU`-j_3-dD~lOQ5&|%@@?FFZrC>SvEw_=EVHBd+E*iWUyp`3jGoqQyOl-U
z>j#$Q;iFi-Z#wUm={ruIGz|>=*JaeSG0o;RNg932AaKOYcAHk-?-B$5WKZ?#e;-ro
z`!u^*y^G~Ng6__KSvE3xUnP_A{g+ibo19#vtgcK`(=$!yG^mRXTWb6psqtl`zMmuY
zy)>!uWu(6U@_*}nAF1!9Nqs*jh3R)px$cwhbUq$Y<KFqfXR60mo}g`B<3ZvhAH&dy
zev5XmL}QZrevZ`l>ngV(J9X1(OV55k&0%7ZUNbb!`WHU6q;UPq>k^*Sbnnv5sl&*#
z(%<80$I8=;>(pW3z$)u1|1&A*uZlfeUI}e|`^A!*wV#ANKQw3M4mb;`?+^Xy_xgr2
z`q~ufbWw47>jJyxJFb>3tet-S+q0D=D^L93RkA|y8%LI-bCLR9-(FUp`>G4ccURr(
z(7#Q_y2zAMuj{%FEWEd=({t<Tmu1y1HVT5zV)>jl+1`!r5L2bz$kOt?4qgWiRCs34
zrnJ}M12+HkZt(a~OX=?gRq!Ca4XabCVuMmXyIZxt^Q3&As()D?oPXa%u~G3@zG>0s
z&}sRkzjq_`J)=MUK8@7(eVQ_U%gt|gqnopFO7|i*=Q{U3Vp^?I|AwIs_CpSoQ;qz*
zf8{ml@6$xE^3*jRR!_S6<l&_$n`Rm|x_NZN&fUkhG%|Q)>ArV+Sxu{((&J6_tU~(G
zAK!8#tM}&EYDt$0mZ*4WZtH3`-8UE2O)k`J=j9J=FKq}lX*RU&C+Tr3rM?$*pVhm3
z=YeH+YIZ4Ov#8N<&u#NVK3sKQH9f81kWwuyKD-%o9D_5d?_HOLt(qBp8T7{fq~GMT
z>&6c7YFhj6KHeV=8Lx<*^}1HA?`=A3!qD+ceeY1}d)Gb9s9ybX9Hqvs{L}9pc4Bhz
z8s4nv;5(fzxL(wCH|jgGVM?s^uIdN+bb9$Yens4FyAya{l;zuCJH*zzRpAG!;u}<t
zpKDT2R_wmgt3l^{594+^yxp<y3C2(?U(d#7cb9&Xe{;EH-6U~+;HPcNPb~djar3EV
zd$;eZ)AHm|%(+=U%NF0CYRB!q<Myqp`)B7OHm{=Fyxcve!G!nQn^@>lreLC62?KpI
zgMZ?uY?yv#_LW9OU4lD2wD=VBZdTwqn+2;aM;18hwXVwt%mG+F#nm;gJuYn;`nU01
z&yOW9nZG^Qv`PFm|JTpjKU_HYj5h{(!&tr&bJVhPHSZc%>r;J9$|2XI-J2Y^vvNoH
z-oKl;Y$#D?{c7oPCO5G1-s&1Yy5(N~=E1iuKld}8kXC;5f-0TnULI$#`P+*|`{Qe4
z4UFX*9r7huHh$;v;M2)w!!LfjS$20XMgLo?L#$f$IXfe50c>9Cdz-~ulU$A+&Dc;l
zv}xh@`70O~nSDQ~h1J{JJ$6`JNj;EOa&ooLL!`goDK-9*)VOGk8GZX2zpF9N<LZpL
zV><WQJ@w+Y83AXemsd{r+}vVKWFzJC<<jH$NR6MCQJv(XKknzBe*ZL_@jK(5YFdAX
zHq$Gu^K6;?Y0|Y@b2^5XiJ3IJie0ZB^A#Sj=PfMX;)WOYn}41h<#8fNZau_wZkLNS
zFLydqZpJS2hn+o|MX$hfrW(YD{<x&cth}<{s*U<`?4V6Y&lSawU(xt33hp5DX>%n1
z!6{c=3RRefwpODJmA7rKXKK$PzSAFR+jlP7vCcAIn}hRI@y4I4ml<)Q-Tc|Tq{pX_
z`o6r>_fMt9FNm&3eCUtwCN+M6)VOU@;~YqhvnDkzT0V2)SAU#Ssc{oLnH>~JxwGQc
z<#|=!4O?0M$+Op$m%lSz6I`QA-)FH6%-cSG6pOWbR<Hgzr=zP9egEg<K}(HOCpCVv
z)Oe#(<GM<XFD*4*(w~m&Dm8xdpN=CcHNL9UxJpvvSS(<6-_hNwOa2PY`**A0Z$0{G
zvXfEj$2-H{ymvorn>uSx^hv`%ALmqR93-jnrKQH7lNtw3YMd*n@!~EsIagn~de_!s
zDaBe1pO?|%s8O2X)qU0>J>0Jzw~MagZ0&&sU#an+rN$pFiUnrGg<Mo?_|}>wL+q5J
zOrFRC7WSJx>}a`@D~EcU1<o7&rgaxQ+hF-Zf<KS{@c#2*d9{4rokH8ChX*b_J1SwZ
zecd?MLo*gdm%<ug9V$<MeBWWLyq+iHW0TT~S($uOxesZy-2Pv~iov5=tgO>R)uOp!
zWLJz&ce8x=Rs~&9UaL8(v1Om_)?<tomezc#xMOwts$Ofy1s-j7&p>)yQmJu(Q&_#q
z!NKnww>K($My}fDaIN8>Iva|nm#uw1<+ickyPJJ|;KQr5BYt<T*mpj8Th~QJ*1WT<
z-}Cg?mNoV*3%dI7?Tu@?V`ul|!-Dd;hLlf#{L+rBycVZ}7u_GYdF(f*<Nql4Dkil0
z^m%{lIFBteb~N;w`Y{p<=p$G@$5U0-oH%o!%LCUH(^7l7_x0Yn@$vK7hHDMe-<h1L
zOk<oaEZ;5fsSRuS*#0|v-<$g(*3X-+sB`M@K+A!C8(IZdx;W~6J<KauK2y8NLk?N`
zuJ1Y8YpH9Zy4zjf^4G>Z*)`Y2ymJeyInM`5|K33fJX|m{aCu+6a)+3eT}$7+^*J<R
z#i7Uni*K%2d%R%L^jkAayDU?|Z?Jiu{`miQSw8)7_?xhLtCacnA#q9<t2nz2^9@df
zPO9Zpx_DEYr2Wd?6HmQexEK!;2C#hYr=~SJvS<3T@#e2CI*)RzoqnSD`LaE3B#w(L
z`q{OA`NA^UB9>2a_+*uD#ndkk-u1uSX7Q6NT|7f(75kw4aK6&**!c0zZ~otphq{)H
z@AZEtKx*7$sqvftbX<R_@lgMC{C}x&g{8*-mm05CYFz(69k2f^v-|H$J}yljva56b
z4--nCA6CQb*wmCRBaIT5?|qxvdjIXCuF~V{8=~(rGuYMi@5=p4ZVazDv-U{Ges`LG
zOKV%Hg7vdTT?&^siZDDpQhJ<w2UcFI0<#Nw^g6BGd}xVtp_$L-_V#{q<<O)9@qdkq
zvQ4*~*#plAt*Ku9@oA;Tx!1CK$D~i_yl%mQQ6`^<%^KIP|Kn9-8;<emcw)Naga?fb
z4DaBf;wqM}Z-<mo+b^s$zObyRXGVQ{k0dXnNd@ZOlI1`At+m}{Cr|0|$fd@+l^PFU
zYMkOLjE@_iD%tkhe<dt*Nt$PJ%DxfBhNXQ9P98ZrCg7N+ME>XKk4knVIoC*zGkSVr
zZMzTS?t4|J(C=VZ+qN@1Z7A|;{MkKbZ`5OVV2?P<_ieb!U{w6s%V&>13;H{HP4wlM
zc1I@P_Z+pn`ofk0bw>7+{(Tmy@l{8#dV?)i_vvPIJfg$&(%J#V%B8z(4L|<iO8d`+
zHJVQ~l^_0*9#{QO$Bo{>=sVD&w#ys0darxCCRN&`3`;Fuc<9`*3m5*?Y_`!V*D5-!
zC;sVpyi&h&v=R@2(Vy#$$1C-FLvI+re&4FBJ6zMb|J%+3d)hYg-IcLwV(a&1ytey3
ze{(6pqVNPfU$vup^~ddP$i@fyzYioeZm-nu`ACh6EA@K}QsZt*{ceNQ?-NM<zJt_w
z+ETw`u(<*0SO513s$;_l#?J<=jE*;2Q?7K-gp2;o8?N1T_S5=?1DE-ZIQhKS;*q^D
zUX%LW0jY6&Jz2f^7hJx3E^*_O!v9)_9`)+H`q7wnsqeeBx!zqDmo~Z4^P$)~VM+Aq
z|DJ%<xWZE7-bwwQfYkWDQsWd$jawed#+~}VV<q+b1XAM)OO2N<HGa6%c<FA;U+ItI
z7|rbJ*v7Np{2HI$@}O|Y>#A-o4I0imJ$l=&@aqeUtu6mdK4KT1t6?vIlz72X<MICA
ziWmH+<B?1KeuC8aj8fz5%Kkh4lfZux_)h}=N#H*T{3n4tB~Spr_WRBFe~6}_4AlG(
z{%<g1k8wZoK>+{%7z0p<=_kCyor?W^bYSb5tO!op8?DBC!+5SJCIX9&6^t-}2$e|D
zvha5A5OFXOJ`fEjJOx4$Dx0F1Jl+B1-klcWAq_RndcRzVE#nIsbSQ(~2h{TK=`F}l
zrDmtq2l?c`Pb(k!E9`$vZ$A;ef^1vh*-=h<{gLnWoL`r1P()yOfbS3lA>hRO^Y<(D
z%T_C*Rfv1YHsgcX!8kF^U~vzfkk4nKh}K_-duVN|v~#l8XdHbJ&`{;*s8(9r$sK)t
z9c`74YPD9L75C7}-d1g8W9w*R?`SJ`vX?8ZwZ1BAduwZ4*=Zc?#BmSh)@olnYX?V-
zBL!6SwbR%-IoR7dIH?_Mw01UfTjYf%NjCHjpKuuCpY$s~k9&BG@t76&@Mz|BR@}p^
zG%oJpzRWya+{3Kvthk3+X?e#zECxB}jC<I(;g4|-Ly#tpdnoAcKp~D(vF@s%%!~7X
zPj~kA5T^q|PRgB>c4}LDC$(H<?V!}y*xTA$Td6czy3_b7eVrVwZEdv<HcAIut*w*V
z7jZ6qwN^G-C4La=&R1hCcW`v_bx>N_+S}XNXq3K=un8xP%Er#u*2?MUF)R1vp*x!e
z#ABB3tTV5(beEOJ>CPfE52w4V>nz=6rRA-=$IwYm-DP0iDQC>eD?ia)B=$GZA=X_2
z>5kFJ$5j1=cIV)WD5CaCN2RZ?Et;U#Myc`DD6KVGt+lO#N@bO$J8QYEt*yq_*2YF<
zrB*pPIoa7eSjjaisK>!kt3?datazhJdtV0!C#8*@MyYkM*Qm5wxq~h0a8#l>+c-G<
zTz5C~(p_d7;^K{3XI_hRmzl=vF7uk#UFNk&cbRE<>uyyp?QSH}a_Vj-(sFBewncx`
zT_w`pyx(hgj@IyMwl>ysCr4^kS|^QKV`EK?!%?ZUcTi^O&e7gl19fQSwocYoYF~RO
zO{GDTQ(F6KZ8U1FSa({j(pP0=XRWc5+xptss2y+*ibqSdlB?v_@}KK&L0-CJzD3mT
zGOtCt%S_{SmwC<WF7sNXyUet_b+;v#c2@#vIdymVC++Tau^)9;fpjMxOZ-B+)7V*A
z+iD#ht<_pbCnxAjYing^W2KS98!BxbY_oJ{qp`BrXwllNl@4l^O5<c@<7BO}wpRKg
zU1?)4)}6-MPNkGPI?6S4i=(f`-T~UxsvT8!PEPh#=o@L^l3RZlnV0UEeTsCKc`edi
zW*V=%%xhkEnb#uSWv1n=yD7QoE-@FMxg>|~D9-PSTw=!Pi}S13(;;-0ggC!aiow&$
ztT?~vB{&-k0$}SBi}O1LHkLG*_YZl*`PEw)G*5ar<EmhPX->q+Co7)KT|S;oUU7aS
zL6gvKC@$|3TuX`btG8DGJyhN%iRJ0-yHFm@2gnW%|ArmtZF$n{KuR&$?0^Nx0_|cu
z7zf+FI9k6Q=&kH0cEHK!*X-bws11_d=7B~jcA(ey@pcd^wLE=ZPh<y4zhMV@drxV0
zAf=dWc3_A-jC6?YU_E5AVyu2U&|BG0?0}Qcuh~Ii&?NQ;`y}d3@Aw70lU<#aSf1XI
z3(6Dxfvoed$A8y5dy!@bQi{oD2gX?Mpd$#U&@a#)PS0`r?Lcp3Kd}Q&KEGxMA9DDE
z`x5o0ccurv$qrsgEKl!z6y=c}%;ICixs^czj+!`WYFrKH2h<fag_kb{o5T`eAoooG
zF1Ti9gnhm15t(0M(7zhN_0iNX=W?)bFbMr}SI{T4IZ7*z8~l+b%sWV4WmrF&8}T_q
zVd`CdVe&eUe$*`2b|VT}t;zacf}^8KBe&5yVTK}i&{|`f@966&x3gDa6+mgLwP}j>
z;%csrz(OJS5fi__5MO1Wn`g7`Tr5b@0wJ<;X*oZ4;^x-5nMcoTA6Sr5FEy}by#D31
zh>4>=P79pfaE^uSe1!g%M3}Q)XXhUX|8ZH<%mU%H#lp$78oe~~?UHZ$pa}buadPsP
zvv`m6U4~TAc#UET?l=E&ZL|w`(c<2+G6NISvWPDQeu>Y?j6aGm$i*l$#ljZ_wxhN|
zrw|)IotIBV+(T==L{kuKO~<tlA#Sr?^UjLFt~YC*Yr)t?$zm*1tV=)8A;cOL+J+a>
zTy)`xn9lJc@L^T~2{<U7_;AGOjlA+ntep#d=xxwheCW+8nU5|aK7^QX^!^t3Kr09!
zk{Qp`&c*yuURtlTs*St|mWwc?EH9;#o_dlj;Jm^$ej%YlnzA^02q_}##nK0JEev;v
z_1&5jjYBLadRJ=&HxCiyq<6}ZB`3XECCh0r=n(Y%e_Kwbl{h)k+A-M^nwBgTa@Dal
ziF|^b^ma#Ca?+bsvYh_O#h&u|W<*jhysU$)b=<n5z>D4~R~9dNvr6V=WiC3;i<fwQ
zF<-2g?W7mB-jJymy~EEeUi4;_%**Cq)XQ*s(1t_odyAorC~giQ=tb{vU&M>PwLr<d
z6cX_w#A{8$7?8e8f(NDuE2@LX$>Ce7GIp|kn`AEZn~>ek^ez=-@uN4ZWPW0P(aub1
zpol|kXEz{|gzW8K@9;K@7rj{}^Kx0F8^KTJ)n<}%;bjH!!mV!#cBXfMF^d<yStawb
z_!oJJH)Cqark5EgLzjaWeM_(+Ui4*^%**6o<YhSatkNNF|No+m$+@{-re5?tSQGK0
zFRNr;-h&RIFP7Z?5fgz9aho{~nIvTQ&3dQuS^VhDDw&_ZB<g0f5O0_!j5x%)F+&+X
z<3;mE;j=m#rA~oQ8~!*)Xu!>Da@#ZU!?$^UtB^eT-v;_=+)QKX@*@6)eHGU*1{L;I
z>=O7!8XaQ3@52_{#z^H`*hcX`=3PoblKH<bvS)$+(imL-z<;eD`FDowbQARQpM6`#
z@3Swx9FQt??}v3R`u`x(zp$^y4RZ}Tf^pKg*B@sC^qoGlIsP?~I{KmsHwfS%SQ&%?
zfl}qK!P-OK8S<o8Jol?5>aQuLK0O+Dg}%5dJEF!;5#hQB%xLjWHhwQo|782UYrs%V
zn_zc;WoQ_FA|HmIWfmw`$8GLnyJzS&njdZB?Y{vn!r`E0BjVo#XKlzX>JPU29N)6~
zy@n6Er0QPW_KDYhJg;VTQ3wt(uaD7AeEx7-m%^{4#tvGg@+@xe#IxYvjO#I$v+?W(
z{l@&+_MIooztX^^@+)rN#BYCI$2)j_y}>rwvlmWFw1JBf+w(|$4I1T1rBU3biN>Kk
zjsCP?g+pwI7SM@YzfO1$MEl_KcDTY<#msy|LIP2jRGRCF{3g*Xe522-J|j6B&8cWR
z#=`R({v$^08-2O9a48m_wXyP7>3#xQgz=l0?wh&L-2yziP5h(%TTXFHmbZHjc?;j;
zqi>_oK~ovBV_MSCBCqE!uTu)7Wqn_+0LuFDFw0z%r}2~KCv?#~ijH`kw2dSVXJ@2E
zaq<+#@Ol>$voxJW7tb<E6dzf1(RY75MRd^`a5!$Fy%Kh~<sG9zhIVFXG6rp4k+rKC
z9d)+P^h%(wZasFBUDoJa|H>cNx03w{dUOOGbRdQ_lUE(!AnKE|uhZ%+IyZSy|Ni5V
zB`?xr1nLsE3xTeSJY6MF0NEFvpCLz2wtp;hT}ki5l-%f&VqfVZJ&NV^z7fX}O|8hj
zXo=+nbo@G+wO7Hu^llBvjV>Bf{di=_i|p$->JsEN8FthMa^m*^h@X9MpN^;TUpBLn
zKo)OSqEANaeSAVRi)A!b&T&CLf%Ha?G#-)evai+XU4YF^MpAV5@F%)6xB8K;6_B52
z_VqBmi>bd$*Ycm(`hi^N+C=ioK2O)XF#5Z6#s5TJ-Dm=UgKVAjNVZ;(==$aL(BJd%
z1%5&o`^W}pA@YbW^2<#jTQlw%qR<BQ+U@Vk%SEI|;W-#RKjH>I+1tVb`XC4naa)*y
z`(v`(oZf}i-=%fBh*ohMmD~PE*Coh1CVLyzyGZ)GbY1+3Zcpbz*CL`T$9kf^ZAiaM
z*TSFB<wG4f4zV65A+Ki+y7Vnx{w`e;e?nI}PnYnH5IuH%hX!H%%WIau*GAup`XjM@
z#n>}(Ws}z-(qnd?rguT{cja|3hrEPu->Mxry7~afcl5w%jW#0Z-}}jXxdfk_#Wzm5
zkN(nA7g}k_d+zeHH56eDw<!im!J5H*f6WyrUO&n4n<7vX>=*9O`Iu0CzUD~}*Ku^g
zNj$a3Nj$~;Hc#B@kwO_5itkqrQAFr4q2s;}nb$n+{{*kbh>Ji6EeF&1i{>A7pz9TX
za6L$^3CH3Yr`Mm2$+n^1+}3g_jmBxTmdpABg^rDl2JyPOnhX8OXhTtdc#Y>*c@VG9
z2t3ewY;HU(a0c@@#5!mO9VF;qACSJ(f;~UH8rWP_iXOykE&>m<rYhzknAd|_V~&SX
z0BSQvIO~H4PyIY_-8@^Z%zKUFSH9z$b6rDd+b?pV^C|2_{)g8!eudVYYZ(Hq3tWDb
zsRv~0^JmvGh}7R+zYyAC>n0qnwA4j@gqGQ9jZ5|i^^b3VvhNk6R7o~Wej}$H2y1c~
zxzJ1NTS<S|Z~P9;IqgA^aXf8Ez#*0~t!)|qS$oJNnffMueu8A2b4^RI-=3}<y<`hy
z6EyFkXAKwsVBZp|!IsuA`Yy3FT5~=t5M*oU2I6ptX{Bcc34hogewAKvKSJX{f!;lC
zjNEMW(mH>V{`U4OeTG1;WciBw45C-)AAFi|^wR!4>K{yTK0se`kz41<eSfU<eX9Hy
z%%%G=@m^D+vnk(?88+wWTnZrDUx;%I<f`-K*N@qIOtd>F+YmDk`N-HhtFVv7UKj&t
z=oufkf0eD<p&k_mNi>e7HZ`z-F#n}|?x>F&qYB?i*70=GckT+}r000_?Pz0_m`*$h
z6v$NhD}(*A#+=BW+relhc?k71aObkoe5er43WTU9LC_nMM=ncc$oKQHEhm#MSZ}+8
zHueYC+t}F9p4a69o_4m*0(xlQ#<}|F>oav3rV0p9gogx%45n|*6TQfi%fYP~3eVN)
z`^pNGO>z?ID$s(vO{@>9%QI(P*tSZQ{Z3uhJYQ@0x;CIn(tRAx(Xi139k2U9l_F3T
z9x_-JmPb9D4rp9QcAjN#BnR$!a|F_ZBZ7Q2p`ElIftnyqa5z0`X5(}cR21r@85<>%
zECl+xc~CBV135p}hVcDi*+}H|8JI;MXoK8UjK1Pr_MCs2EeiAv7u7{+bPu&9eity?
z2mT)I216NH08Y{swX1>ne=yn=T~oUvo-pTQ^g8qM3~Y%+9Qd9hYx9JY;Glf?wxkLP
z)&^jfNRu~iu*%sA`LbLNMz<0Bx;)mF)x<N=Q_$oEE05kqbzs*|GOxM!PS0gt+p*ub
zXI|Sf`bkd$e<TCiKTp@(*6A#s<Lbd*g{#?~`JT{)Klr13>0EhiA2sc_r!<8}q%M?(
zRrsHDNT)OZZozwAF63$u5|Ztyegi!m=HJ~RFUWRy2WvwV!DvOQ0YBIq(aay&^l1d$
zaofYynR~;t(!v-WLfcx=iYoz4ls%7B11UbGPQ%%g3W`Cn5J5GZO_9)lJff|UM(-Yw
zZIneVf?sB`5Vo2lk6>fXsIBuQQ{MOAzJLF#7SaU6Ltf4glq44{^KVOkWwJwPm}P(o
zz?xV)(DmnN6|aX-KJo)*Xdk&8KhP?)1zO`kIV6ruI%)4n2)|>5=)@&D1H@|(?GmAO
zZHnZ)_L(r7#(f;i)c0iHXF_F=A2q@su0Cv)RU=T2(oaKGGPyxUR0rEK6A;W~{P^ql
z??exu)*ej|yu*f(ZV&lz^|AFDg<pg+lyppdn4v7vO@KRU@#HF@baQbXAcX3szOy{i
zX%CDd$0iuMr!szXAYCvbR64qc)`sdLo%{m2$WXkOqzMgc6HLuQ6BdTg)pK+tiRnju
z!~i{yTm#!wL+7sy@SX1gq+?D7a+Ent<g<u2Q=}20m~agQzY0`<NH<}O&jR?3`jvpN
z79oR!12uy*fvkM`Zio-c--Cij2XW;S&Bn;j*1AGMgOq_#vRdfq$s=>`%cSGpKDgHq
z_pambB|q4Jzn3H+w0QvqAAYqR2*pts_fng|H>+h=&{x0a+Z>CI#J3BwVX-d+8?ptL
zDF%%jYxC6JZnE}9vMFeiu4R0{4_dL+LrVLUnMM(zxqMk^R(3+#%glUMY(<pr%}TQ-
zQdu2YX;!vE+SIIjZG^NbS!rw~iOLhDu_sBC7M+zZvyQAZ>)i4&KFIFK2Ns7=bdXm7
zd?nS*`B`J;Gcwv!3j01h>whlb|ErL74C_1cDPS)ORYYhg`d`5naejl{^}`<~bE=no
z+$)sBw=Htl>|Mlsu*+Nub<Xi{Q}64SRI|{p3VjZ}yH`qD`Fi*LQ~4w(VQik!fl^?T
zIN?^=+@~Dcvz+y7`4j=cgF*&q6oZxFVIjea0Ifn38X5vGsc)=Ben{wB$**$lUbvfU
z|HV-sjW@D>&)RcG>Dq{3RXDr_zl6=&v?+g&HXw6po264*VdId1U@UpF0TxRqze?#K
zKodHM8><ulLO+<;5kKN+!H=ulfMp?TGk<DN`4oe5bcDn=GeYh*@!w1v5%|u0%?i1M
zzAtO8!pVT_Nsjt>d!kKAEH90#$j&%_#>s`oVr`K(`(%^TrzJn`nuyrFbdXOZI&?S(
z;T}0Zj>Q-eJu)|jrQdTo7#~8vNMl&I=CE+4^SsBfWVcWos~avp(~gN28b4B*#IFuz
zhDG?YGD#PLe=Ob^nQ&y_B-+w(b|78&@w(vlVB(<$XMfBIAy1AYPd!i@7VJ(u-XPju
zgErz<82eEgjp?$+P(O|bTcU0Hg2w;JJ{h8)$_dZA9Q`jzq8#c!r@{sdA<Jl7+cVj5
zwkC|_^BSL~^E%jzzL#{c6IdPoAZAET9WZZ)m!LUai2EwsCLGypiOG@tHGUO*9LZa!
z;^q=$8-lIS?<9LRhQROC*OPv@wyaf!L<EP^D2gf~JqhFXFxFFN@mq@Nlgm$exjup$
zS03+5DR{pZdCCA=0^dOgo+EzXl^=<7yb3W7+09vhqNx)TkAsOWlA)My!TyL(v45a+
zYCGf~a@r-0d&G80I?jNe4uk#&(9c#zFDKI$$ScT@%CzOLwe8vV>#npeO>_xkKtW!V
zCXB-|&(#FMaZo)6y1+M~9vkwDBS|h?J#HwMXbt199r<hA#&qj~Ytof4FBHl;fU+!6
zNXICyETWOdmrT#1K`-gMHPVmQ5_}_#o4YZ(NQc5H%&XW#Qq=b^Ix%|h@;Q)n858z{
zE@=S=K9KLjAV1-N`i0|{bt#(WF!@3>Kg^|FFy0mHo%n8mYi0-SJGm>|-J7|$_F#Qh
zc|KoAVCK}A*}pvNequm0Zh@@uTXtD>4G#?n_9KR<ExGY^34U0H>!XmZZ-kc2mX%+e
zFF&(hZrIECsf*v3j&y=;z_$4`<fr)xo32n@wnARMUBAb5RrnB^Qqb?FxE97XWOpra
zT@Al0V515ZZ=Xox>9ZpGerBJiVNWl*%Vcwr=lP&4`*g(pB-{Qt$ySVHP9~Kix!=uD
zm)H;J=m9$pJDjv0M-`4kp2OTeQC_uhHVU;SFaVF%`L!mIz2J__gZVt-liI!=3}G;M
zqWYQ&@dao@H4ZnNl*a{U0O~X2_E*!;RISk}F^|bU52UdN<<I3{b=KzVq&W<GsG}Gh
z5UdUv9F~0=!)#3Owc?2;wK*Dh(42|pxQfA{0pZ~^tK{gn=jmU=(_aMXXl863!xU}J
zj9Zrr4pD^YFmMbA4`8#XJjROLdKt9^!A~j_S~mL<>a^zT)b*ki_-3@%QalDiW*29$
z_N~Jk8ybbLN@t7N56MZ*a{urrI;W2o)|8By?5XU6CV{h<ozPs0x4nWUvu9?e$*ELY
zd-@V1q&czcdzsf1kC5Z3KWL<8M1GReXzU?gYarfNK<1Q|X<f)n_H!EP<YRTXhjg<9
z*EHV`QbsDmG;C;0#j@Xy<2P!b82V=Wjml5NZ=s+=d=L5KIOs7Da@~OYj5*p_S%;B7
z1o;D%VPuJd$+P}|f{^*+q>7u1?n&Tj<Lk(_2So7Ig8gUkx};`D_R|gLB-E$-L6<+;
zKeFa_WE*GXCi4kd{AX+XV|#POB?5?+GdPKs6;pHCl_C&}{SmZU^7FY*_VwRip`*Ar
zM@LQcjYLOvAkpDA{RcWiHGXUf<$r~aIXoRlK?Bio7$?)sv>)gQQ-ucT$jAOkc?dqn
zr4I_mK}#m&lWDnfGvp!T^n$qqIyVI#t11I^{z{GpDgKz+8BIK>eNkJa_C#Y8Y7Yy*
zyCdqQN34ZdJzP5^UrB9?`cA=?1v($|bhf5@aJIlnbb98bQyt((u~bM_|5G~MP-hZO
z7u3~551m4rYuy)_agZEIuO2wrv#s$=uVF)i@q9z$r&JBW!gXkX(l=0pZsW(bXWYgg
zW~|MTJgQ<{emi(J+)DCMXahpwH>|83Xzh<O)9>XV=hOJ#0HfaUAv(6Qj2JpYXfF2_
z>2jRLY@Z?*pBr0Gkr&SoaMIB}pDc>{n-0Koz>YxSKKXCn$Hme9wfa0!Hy6{Ii@8g5
z7DgKBosQdhghS(qJ3!hFaTiFx-3PV@J^+%-c?47e9|MUGD)%DW*ZRLuF5AcZzfdmQ
zC;7inF0aqQkjbBtFWDCtH<OE-=3gwkeVsFqMb$x`^FZpJE&~Po;^Hj+`h8qnzF)tO
zi{tj|_i^#bxIJ$<+s`xD8TqH@K-!P^g10+2{LjU;;>OB#;T*_6*y5z)0P<M?4+2{P
z{{nUa9tKjseFR8yGQ-Kmf1>dSzR8RM9l9{KCjlTc$)A;vi?75z`^uTmSd@>8FO+*e
zBT+sb-)<_S9@4A0-V3}Q&F~u+yM}vaoo7DYuJx72#azjq-&B!YxL78+*Lz7sUqT*y
zWXs35kKE`J=hNkpPb?QMc0}%cycF}1hg^hushx504!H7i+M$y7<32zW<n<N#aknwl
z7ybHuI<`OO*Y0C}oFDTCqfW9zu^;bLfa`DC0g2A`K(gx&z?#60Kx!ABKy+cU&OpIm
zaPNI{Yf3r!59av~;rZ8z`1j%YFN5-a<-Qo6|6jS!5p{6y^CIRM{wMwm02|<>18ZWe
zzwHh*#kCg@(*;>C5ufrr>YdH=Ifv(Su82?Web?OOlh=LR`=-BkpBZT8-uLA8VdwNW
zf?pzeaPMDo?`7tc$3xH$*CKlaq`A*yU>s2JS26gXdmoW|Pm%5~iL|je=}6}9PXSUt
zgEhn`B`^&b2z(734}1%p0{jAu1!e$u1M|b*T>};bQX?q@EC@6N76ujrmID?C()*EO
z|H!?MD3g`I{bX18Inyswe<0W`_kJL^r;zAJR+%|YI))-2@jnbmdw;-Jrr-DE{Z=KU
z=jB(qci6c1Q}WEm`<cATBR|8v<CQzTDWH$Wi%)oZQ+aybkjA}(#XW;1KE?graQ?m#
zK(hN$Kw3{64Wza)1}OA*-1||v^CS2}Gu#uChkUZ-<NbARe2epO@AKqdui)27KHU2?
z-1s)9K1uH+9~uW#0E+!Q_x?-n<qLFBd*R+k!SitZPvsW?3jRX@KSAaD0BPKy1k!xp
z7fAA>`?+^NxOYNw-ml^B*8)9|*ALhp=+EEphX1+uDYC{pVm%H+yCHiW4lE5E0i^zN
zB#_2Gqku$*8_p=+?~-4q_VK&rB=G+5e^L&!YrdRPJUt*uCbYu^pqu2n5NHHk#PdP-
zar^DL^|74&M_%`Fd*6TkK5id6w|6>cebYe~$$tj0HZVp+XA&=O>OX(wK5kF;uhqx;
zIX1`To^4ZoVmqD4(>V!9?O-yn25<^bFWt}WSN{F`x&6bxcR%Ts+s`YLmB;@yJ{Q}=
zG?*{h!*n3|s~JGDYaN|zJys@LivOv7kv`No=@?y57KJ3)cp%x)1R#wcCILxblY!Kh
zrvQnDX~6El=|Gwv#Q^64X95=jX91~R%FFGSmC2~x<@7rappV)Y<jTfXPCUJIAGiNC
zcYhU$e1(u_2(SWh9Dko1{^$0d(mI1o76~DU+b?Ki^(_L@IBp4l|1u!?gXKVhZf;*G
zM>mxtmh(>JqjGlvsT}ml>^@KY&+QTA)=`OH@i;OPa-sW%0Lhky0_hR`FrW@N95?|u
z0vHDz2_$-q(MfZAJGnidR4)0g0@Qiqa6mrNp9_%si>AO@Kvy8?tvRqOumx}quqALk
zuoW-?*baCU*b#Ug*a>(S=m~rb>;fb@x&glddjM@vw-?X_*c<2p>;r5I><3f;6~HAx
zC2%j$7x)pV0b)!e^8*&hk2N<S#xSxFAjT>(9S~zF*+5_wU?{K#Fbqh0UBiJy&qSQu
z9#U>^DanQGcQ{TuT0<`+m!3dlU@xF8&>KkdPyqdbKENO#+C$W6paw{Kz;97gfq_7>
zZ{&$u0EDihii7@eU`b#Ekmx~u{N7E-oUTzh*{KUoIx4`AkUdlclAbC7>jEnSt$|g5
zO@Y;bRGueJZVx78fd6ya6ZL1*PNRTzfYHGEz%jrMz;VFNK=NzU*2%9?x%AAM+b_xO
zqoi`3k$xBHbPPeiO69Hq5}m7nHGr|eHo)~jjEQ6$fa8H1f$%x9&A=tVEx?Vy1mHg4
zR^V~qHsCejcHjfx4&YPZPT)J>9$*R3upbB+$PNH8N0c1~4gekjqOX%32PObd0?DpU
z1Bv#(f%k!lz<jWiOTePQtH4^o8^E@}o4`)MTR<P+U0^8i0Wcc)2zV5j47>wO0VV;T
z087CUJOfq*z5v<-(}2x^AL#c2GTA3!Wnen6Dlh}s6!;D32FwTh#av2O5U2(k0@nhI
z0nY%71Hpr=BoKATN(1x5ag+hN1Iq$EfE9pfqp~W%zQAh0*+4U30<b!e^c{zj+gHf#
zHza+RLK^9c4)TZAz{NnaRrC>ToJM|;>}Vx06u1UB2DlD569^x|^c@exZ?c`h%|P;t
z_+PdMcnk;|h<XS-0DJ{J2>c2>3^atkjst1`<4GXV8-<hGo5$_hBYI094egB`SLr_d
z2U}w8`UcPn*EfM~z+1p>z&k*+dA9D_5BLwRsf@?KDZpglDj=<g?FE9is0+Z?K%&D9
zC%5;F+Y?9g6o@r*J*;sd&Y!yg@sq46kmzg%tPN}qq;e8)a(l?Qy=BA?^@k)gI(nd8
z5<gzRiol-0>cHN>=0I;?7_cvJKCmC~BG3o;9*8y)We54GfbD=9Am-RIf8aV`0B|?3
zKkyDP2>298>kiaTbij(hfj~E4D3ItT|HJJS<77{ClmBXglaAW3FQVH5NPf2gurAON
z=m%^B3;@c3I-nJh%BBCgeO%oBE-IJgr^ZRge$-Fp9srgE9t4&J9tINsM}g?8W!M56
zMKZh!ge}U@_SyV63HSlmrSr?8(t)NxsuzBc-@7D}(Vix%*AnUQqwJ_|z|~t5NcEZn
zsoq+^D!|%6b6_1{eV_%<8dx7l{Ye90Z=fYm1#AQi2FihhfL6d!Kx-hiA6wuNpdIiO
z&;dyOt0S-;XmSF|fzCkEZxf&^uqhC_l(_+C0-FIh0^NbvfgZrGz?Q&r&}VC)1+WdU
z39v1Y{9ij@0I)qU7}x<g9M};U3-kn@2X+Rg0=oiBLvG!Hph?yP*bUed=m+ct9183W
z#3MqPH*f{84=@3!0PY0(07)O1hw%HW*cublhaBlskxoY?=&cN}8j$*->cBogbD$Df
z2RHzT_h6zTfZ&nIw*e5oL?#DPd$t8qKVuIhKjQ#IUn_G4HUmN?QPY5~K+I8O&446V
zci<&p3*b#)OJFjvHLy11(FW)RY!8e8b^wkALbg%sfS$mez%Ia(z;3|Lz#hPFKyM&y
zM%D)iUCa6b`;vTsTA(kG<fsO21Zsi%fPTOO!2ZCKz(C+>AaodY1E>Su1r7uz1H*uy
zfS@tzGjK4lK>>_EftJ8wKsR6%uq6<EAlFVoBe!RY+e=05r5)r5de|`u`KW!&1eyV7
z0cjpL8)yrh2XqC_2a+$rH+Nb4SPUGG>m|Txz~w;dH&y}<1J?lI%VleUg&=Rpl8p=E
zfR%B*5!eVA4{Q$H1jI8ySppDqHrZC-Qs55YNg#9(bqlx~_yKqb_#Jo{h_y1=5nz2F
zbQIMScp4Z2JO_*fUI4BDUIhLHybQ!WvMa!2!0W(Az#G7Pknc@k1>kKUjT7zw;R9s%
zfM^r4WZ)=Z3UD<r6?hc*40sdx9C#a;27C>C4SWlH3p9j&-T|utKL8zoAAwH5Pe4~-
zIuL8qGT2&FSKz-utii}Kfa8F&lCPtt@Yf4~-;s_n98Gefjsd|#)OBEfAjUj01K>Mg
zLEyi@qQF|{2#tX4fhB=zpfM107?}xh4iICdsI@@&jHq3}GQhup<$z~_kWtiqU?t#l
zU}Yfrh1NK^{Z`yQEV8>oNTaa{9q=(xbUh4M9SB*n`A#&D<~w77G#(far1Hr2xcyWz
znH&D6^2GfZ+5qcs8Ue}gTLEhW9f9QEoq<lkCP1PAV>wnX`6_Oo6Zg(7l?ye=%yH83
z2~7%Y(cWb??*9xVdXjK*dzF}vW%N`)+Etu%JOkaOfX{*DfiHm7fN4OY2R6azflWlY
z;rczW4e%ona~0VKU?>o6Jt`8I0i=HCJ8%myKj_DpOlAN)0W1K#2rLA=3oHyw2Ex{&
zFgB7E1=6_O2v{Fz3OokH7&i)SSXKi__FV^vzD-sSNPLnWxqUqFd32paj}Jf($tMX&
z<A+B;;u}7TJy%QtcEj}(AeE=X$?e6#7$5&rdE#-yO5~&RRspHJH9+b=Vu5vl>w%WQ
zcwk%LW?)C)R^UY7HsERCcHkM{4j|R*kCWSbgY`x5P4yN<8udkVBqATxOV5p|URrmh
zdanQ#z-vG)5N$hZ9q<<L0T6AR&2#PmtD{`_>`Xp&aQsM;9mScG&)vvJ_3Z&tedrTd
zeFuS6aeW9_3wQ+B40sIa0YqQH?BEpe5U$Z@L>&hH4J1CPop5_<I6qJIirWc7EV6bt
z8ED33W&V9SuHA7R1EhLp0$TxR0fln8Juu(}={d`ti+qKUj-`H9?gAjSvqeBR;1XbS
z;8I`<;4&bU>xR=9jhy5}^-;Mb7wUWHz!-|j$pT2@H`p#)ziI#^IvWDt1LYW8Sfint
z8Eo>~Ua|4a^MB1Kxh~<zh;FVEpMDs6Joa3PW9=61yO8{H2Kr={Z*0_9)7x*O2Pvv5
zCJeh0KREx@@?)kgUlm@k>WOuci^pMt6T|WiZry!h<E<s;EVwXj(UQ##O+&xb9q$lz
z-E>^)?NhxQ^jAYyEMHoPP5HCemnN(#_T{C|>%t|17jN}2@;LNx$iCQ^lqz-uWwJLc
z-;}QvBNOGjuDDG6=VQf3@oN9`Nj_m+(xw#|u-3u5gIi_r0Y_qHF!|(-4g0=%JNN7P
zZnZAd?bfc_)7BJ@JTTMi%+wVZ43EHv_h<P=4BVa6`R@~!=jR=HGULg@{TT*Nwwaxs
zlsa+P@Rdey)*xRj%lF!)alBQ4w`tcC=7vuzzk1$f*SM?a3gqAQ{Y$g+OXpD>n%gYj
z^v$34R~YwUY^uDQs*SsCM)wWZf)*q%3u{@&<wbmYMGTIMV}fI5;9EI=m$*2qXuDa*
z*Y_*$Y&kT!-<N~KCf^*tWyHjR869AVEm^*5RUI!3-I&&V|67AYX~mY@cdFqoQ@1#H
z`DLpfL3Z7mr^6@1z|9OM3|+IVT8-!q*Hj%N`^vi*UpW<Dv{ZO%_XdwYPFP>@_*u*)
zSb6EjK9@&US?r@teBI`AgJPfa-x_tZgYTh?;RZF9s*(>LL*L5s6*p|@dZ2gBxbc==
z0m~Z6@0p%!vSUpVgU1=`oh-cOG~A3i0c^(1K!3iaEZ-D|S*Lx=e6n}{X3`<<>Zp~M
zB3|6M+`_V|tp1eQV{bUQ!iTVYzENE}w>ep<e~+ziiX5`9W`5N+c3t9;NmWfQS`26s
z^|%XsG<0lca3Ss=-=KXa{tM^d%((8|_sjbOucjp}z416TdeG9=mo%#|mSy==Cu_#l
zd6WOI&iNLt{J6WtrmJJlX<wR0=6~9_?}7e9ACy8r#PaRhTuSZrp!Ii~se>jc-&j8h
zO}Cr(q(Z)gs}_NKO&51>k3NLu(`_=TEo<B@+-1+DrSg<%yY6PRd+=9H15-Qut=g1*
z)n;QZfQDvfV0u*(_c8xlr}o{te;ie6evgbU-nBO^kuSXR@s|6UFP?BJdsw~;%`_Q@
z-KTZ83~V^2z_OjiDn`9OJ95}*-JQwxp3Z-<{yBUS9GaOy<9BDfjd5=^`C#KGb^0cy
zw%_$o>9I!MeU3{{t4G^6^dFBkY?jZX@Y<x~@2gaZD^bRMjBCZEF?EI=8`Ppwoyf8K
z3p9SzZY|atSiZe}@k85=>Fnoyvf9e=-W8@Fa`sZ&HE_}lUYMBH?M+!s77A3OdTZ<|
zl(43V@7y}|&!lA7xpXSCy!eB^izzBD8d$&4ch8;Bn={L2X<4VU_qUejb{}e()kxlQ
zckJ4dMO-IrdNg9smNU=H8tg{j#qvcPese9d&?jFf`%BwyH}5@W^wXP8_iYD1FZ3q5
z?xI5DPQ$mcd`YsSPtxkmuJEdwzsE`C`OlrAO>d`OTXCp?#qvPqQ+IUM=UBd}M@(NV
z^nO0MZ>N$Swe_sWuO6q>r7s^haY>`-h3N+8mw*p5;^SrAxb>R%{l1j5t#@zF>M@Oz
z_D`)4H*|aV(Xm!dqqojRc@0^<FX2OCid3E&-0|j)3p<Q1b=-6%qE#9D!XC?(-v3lt
z{qj5X%krgN+Z*;}YqQsv?z$d$`}BO!=}#l;CYG(f<W`aNeLXWaUdNc8<?A`CSBXRG
zgJQ}JxPHKIPW!o^M^5)!SMHx>x4uLsezkjy#ge-$U-eQ|cK_{I=)<rp&5dO1X4h3U
zYHak?E@(zEi#q1x?o5t_-B%|*M$UA$aZ8(R(<^q_g%fdMr|rKi9=Ei6txqFb-&}Ti
z)fW}!%q(AWdj7X{*F4^Gdz;~$4o_X$IVWH2^1NDX!x=ue3)ejH@+Q_eSibv@M%5{`
z_eq1;$!@J}!@3$=8gQrj=?%{J;$!cesiF0#hdBt#7oUEtdvLh((>5=Aq-|;5bKB?(
zan@J%+ROd6_FC<=_0l5j6=V6H*smFwF*5zz(erm_)l5w5z2j5wZ>3uXY~RxMOTXmN
zLCw&PSiX*r%Wk{e(c{92D}9o;x3<~U&i3mfr@6zmH@X-3cxBJ$P>iK&5Wml!JT-aL
zD}P$Wk7MI{S=CzG+9=Rjp7v#V!!||gnQWan7;|oxZ(L&Om%6(1irx4;eCFpV^G18O
ze81;_WB-?pEc!1_JmfY8eJIOU_=Jhw?bL(5G2LW4K3#J6e|}|WrHkG7*|j@9xLd}C
zi@h)=VEHCrNIJFJxkK+qwOj}KeXeg5I_=r`bn8jypI#et+`F82FvgfH-^Yuy#zu{<
zvDDA(OUs_lbG>^_34dRsZKpLhJ-&vIt9`9L=HxYrj}`|j?JWO9zOPu4$NRRe?8YxM
z{B*7Do<8+P>joQ^%J?3IwE>pzTIkF&-BZ-%o`vr!d@FXqs}#58BL_@)b9DH*=PkFj
zSz;=a&0+aY_208rRnfX>!q%l}?QUN>@u}}tmxk{b)tEV0`|YN;E99KW@^v0@^MFIC
z>+=_#NqoNN{FWV!8+ey1`frnaO{UeVI_$Wg8|FIZMBkBKy`HNq65fuef3~rI*txo4
z2d`;k0^F9)4*op*?$#q1S2Sk%VwdYyH<+;el-Jn6=51tSqq}VH+PzBaSA~0&bF4l!
zX3H)37xZ0b2L2f)*WQ+^yR_N%E`Ae77M~k(SM7Z_c~biW1q~z0zF&wz_-<C-=!1!o
z2RD{!YSAp#!qLa9lFf!)kAutx&N=gXcJ24W>S4S=aazp`BGhRg`+hfkRaznMYWif+
zin9|Z4_Pl8(Ji88^S?**TLFGc)}nk?cL#otT^iAJxZTD^>yGxH?>nmV-y_@HyY#oL
znCHHATfs+DmT$;_8nvV5#}uA4c5j7l4Wp+%X%=(Yq?pO_*+*lKO|0KHStc96@}*9x
zQ`Ypsjx$jgbP+?pH}`HftlqdXOGDqbo7?Wuq-_ceo>s7YE!(&DXx<~KqI&w^f3AEO
z{P)^}vaUylmfatErN-FBZNow^=4JT|4=$<K=jr#`XUcakwQ76$9lAOR)xCDiGHxz^
zb-MbORgE#Xs7-vxPKWP}UTJRm`1#SQ{h#&^xUoT}Z8*C4t1lZbJR7&z;4#*uSibUS
zx)dnuHFL}X`z1xEckg9-r%%M-!rrrcm2*9Lz@t}pAIt$+zWrO;Bzli=t~1WF<B@yH
zsQjxQ?R$87$g7I?I*&eXwQTDstU0oL%MV;no2EVgDk}0#*<Ht1MhseeG}d6vu#c(B
z3;NCP9W@zqb(ZgK(#)}yn|^Cle$*3#6(4*PQ@WiQoif$denCR;$x(|}IAP7I4)L+A
z*pZq8O^Qr5(v6tCKS(yoWc;vO4ofNwj`^qNO@|>m^b6fszR{NVm!|X|=IC-U{(OP+
z<?_8~{dj4;E_=t+SZY-wx~4%%Jkw$M<lT(6_uVk$)Y`KP3eJ%~Xl*opXPey%^0%rx
zEpAm*#e3*ex3YYFlWxbHiRx2tPi^~)M@m?XG+sLDQf%#B(PwvUGTC$fDR_9!@+EXB
z@G-hWm0`nU>+Pu0Y}UocgKNC;J-qcwjn8xbn&-Jih3BYsiH{{d2d+*S`|9cW=NG*+
z$Gg|Pzv^1W4w3hCn=WonmK7-TH`cgVzScE;?;7Se7?@VP+VTL$6&Wu=4|l2CYP&<B
z=Fj$i4f&?S+??g>Io@`{;aHP1Mc<XW@a6IMlk3*`6{^{1@5+9&Z(X1FR_6kJuzb@7
zl~%mZ=XUaX+aj039@YtYwYPu6y@eb1-WF1;cq^OF3o-X)`Hm*f^h*vNu_ER6$3E@m
zj*ooMve~kYw^kZWa9z84Mszj!)9Uc$W(L)Et{JaBUSZ~(fx~C68fP>w{ETzOF->lV
z*u7u>T`RX9i8W4^@7|8|H9KOrm+17Sms7J3vxfKt4%&6A=kxaR7pLy7sIt5;*2q}C
zIG0AtOFda%Z2hg{>SWoMVZ|LP9Qe4aWRVH>6GJQQI}bT;V)@QioUB>hY+j7q{KB3D
ztA;N>9<np;V;t?6@lhAr+OE|H%oSO_s_R$%V-fOp!KNVvl*LaO*FCd-YpByAuO;h?
zmMT%H;tPz|3Rn;yiXOUjL!I5Lh{HpQjCOn8=x}m_!#>LEqrVSc-^kv2_yWuWSiTLx
z70t>VJ?{EC==<#%rB@eRYdB}d-|@4e_thFuE4rThay;v2`RcWt*|XHph%FN?8~J~A
zIi32YRG3H7)AfUA#VKo@*w^(a)>z@o%?vb&7X!Z8+Es{sQD{Npmfj%-6W?qpUu^E;
z(F0@ZFK|hKKD=1IgKG<4>SXDbzlm-8z3yjkO@14cx@J`4l8X3%4ra9mR(ykJ+$`UW
z@JHPy`OH~8v135QSM%*{99wpF)4U&1Tl=8vxn~}Go?-sM@)c{jMKkqTQsT9bU8if~
z%ZzGxNaa*G^6Z@T@#UQ~{@r$9jg95&tGu`?tmEr34djJd%Tg~^axHavsrl)x2Mce1
z@y~9H*>cFQ0r64g>A7m}wmv?;ez-<4BHpK5z@^j?m1l47{3gh?^NTV8sd#q7@)am(
zw{?+E?T(6+`PGJRb@|KuP`Qo&AA9cs5Jk4M4Ub}u;F=e8R19DO$w37JCR8vhC=4(l
zN*Iy>MF$1bieiqKRupqwbHcoeig6977%`%_#zpjh>U1|W;|T5Q{qFm|Kj+@w$7xQe
zs#7PQuF6<9^=#b-JqAU7j>Q-l%Hpj(U+Q3V$rbZ-9Sp8)yk|UJ-o4|c22IWyT`XU*
zu4Qy9PwX|Ycu#sdoc8sM`F!NU`rr>w56#(pCprAL9+!_dzU}8azW;!o*h|4$O0F|9
z+ckLA^5iA@dV`0(9>3G3_V$EMmep5uTzDkFW^;?zm^YDq9=T5Et&JD#XmY;S!w*^E
zk8ai+)FvxpnRR#PJEksa<GXeFtu5w>EZ(l<u;Ra2{We{%<n}nn+db}&U$<?<tA?Ma
zJ_wwj5FE2&9rk*fQ+^MJg}&UdZQb?(p0(#E>W|-bC-`l@O~<Bf+-&_hZE<Maajdyn
zyrFxCKi&7-bL@?q3F{4wyDe?;=2`p-Wp>os(rz(z>~U@-BcHHxoonxx%8p-evC@3V
z*+0D}ugNU=$M`BucMdY%;M1^3jarQ#;jECwTk`(N-9P_u8)II3(wBh??tAY1a??fM
zwDkHVZ-#kpxp5ABJZJIrccetroqo)2l=%*mtqR9a6<Zlzw!JVb({MoXTAs&Z`=Q@$
zLFF#Yj{4~6;QZFl>*&7C>*jv6oiL`Jep|~&_ZKD(mOWjD{&@h4msGufN<-PihpY8p
z9d2fB`s{f?_Y=R^Ri796+qBQ)P2R+zeXw{BMk<CIb#+-eWXaTpqo&pzJH)h4XqsKj
z*xoK7Tjm}=g|?f-;-$N}-7&CN-8#4T)U5KCljj|6RiSQn)+qzW!<L<$pF~f>ULcFN
zIPk!@UE5ovKOJV59yF%mi#a~y^$iqR!K#QO_vZMQbVK`vuF7@NJ}z}{SEH?0gIkBX
z1az-&IQ_-qQYBt?e&IiNWBl{<^5b!q$KqLJ7u##O?!3Lz?&e?i{65j_kD?2MN-io=
zchggsnQz}1WMMCi#d{KcuS8UKt8}}&UADxB$Gi5}tn>cr(2*X^R&JPOwyhh+^HdgZ
z!A_&&S#4*|)35RTZPK<!4m&JA7L)hROb9%XUH)0{^A*_J#RjWfXWs`K>x<V++t&G#
z^&xGWx?X~=;;G_&=TFWbB77cCThj{bP!?~Rd3>`kQ@ZsIYJKkF=Q&<?R*moa<;1Cz
zwa?DTc-4IDrn;Cnv3T=q)hOv`ea7OKt~*K&Khq*=Os_L3gTj96={Tcbjh6e8J7Z6k
z#dF-#*Zh5ESayK5$*_=Rjumzl-EyGZ`mVAX*{4c7n<S0Ko=!`mZ%kOFJI*b3KD914
z@2@{U6koYg&tvi2-Pt?Birc@Ra{bsjnaqR5yZ$W2>y<&P3-z9x##L2Z*i^08fQ|c#
zEGr-7zNhG;chxZ8h-LAzY&N}Y*>#ZYT$!PFs})T>nsi(FPZ{0Q>vot9n}2EJ8?1l#
zvv^ite%o_!%s=s?6iv5v{Pe|g%+poP`}w5Aj8=yy>W42#1s^Ql(YHNcy&f*xxUlBs
z-P_~q72E0B<<qN5=EYvM9$Cfl)hk`B%S?$6o6~kC%ZhBQoRHN0MeN_3%WVpu-u=y|
zW#@-qt=7C|g?}P(Hq7EpO7bdmDDv2gQ6pa;ySd>_^>_O}I_+`1H{wi)^N6yS(Trp(
zS-g~B-Sqbh7G=E8_$$)Ae~;FWD!x9~e}7HOZmKFZtM6FtjlD`1Z$kBwJ|nVL4u3G`
z#nDCUlIk2-d_sTarC~dNOHID$@%#za9~I1qzB$dxs-Hzx4}4<&>2V3CvuB^$bl$!=
zS?6ufQoD|hZ9IPz)@3YS?NFy$4I8A_Sk*fsu!ncV<XCmLrk~$t*u<PNsnNF9l1!X4
zvv?osg*9AR{Oz5VgP+$6ZNGfBsd3+Bhax;e|5)=vzGYXR%{VJ!@$4quoc=8J-miMA
z_m^&e<<7$jXMa0g%C?QGvUj7}<I0}ICTuE;_qhGZ5dXHJ0q@&)*zV<$TIAm1<c!FE
zPvtX4ysNqD$kv(AXLI6X!F@~l$LBL{Un{kKPNv>&(?MldX4i8}*tp(iebcl)I@i(v
zv3LdVbB$*4<V#0o@7rEFIIO~eZ8w_vPrNs#LVQY-j3xW)h6WulXt)vM0*g0P_sJ_~
z*C_$!0Sf|r^=B_0x5YzV>4BF?kN1aCsvAwjTK@)%cPe#}!TkN3%EU!K)04mM>yZ$C
za_*@4#`-;qj63EOH={TBupmB$T#SyDZ8B}#Vw-Yu#VDWGf24Yxjc9mNY2ci&qg(q7
zJ)9A<cw^cqmo3<y88+3V>s5ym{aY3Bo^6`uu-K=5lOEpNKe(1dKhEMMroEHtkL+r5
z{qqhd#r0wRkB9mk3!Tt3aof{DY5hm+P~nV?#nb5%@kQrqo%Q=yol4kbu=b_GsqV+X
zm@d9H6EC$3u$izEcQ9DIj(^WLs-$;6VMEKUGd9&6-)+mJ)X3wW7kWNPUccCI+@@E!
z<6=pCB$Ti4_WY9ouPzQ5i{^(dsT{2Qp!C1<V$fULBTiFqk~PUrEZ(fl>e*`Vn_pbJ
z9H`hK=)|=7A&0!?yR;tfHQ?~2c?pd_;p~&et5+*N<iLi?-TfCCo=q$}V_U-etA~@O
z9?Tp#d(g?chUK1PzQN*MvB+vQASt8n%yN}W9(G;cYlGb*^Yp24_v}hv8PWf3Rtofr
z#mg#t*6GA%`MK0qsYMUm`s<0??ZLO*+`7D6BUc$2h4+cT{<IbG(cr?8WeaD`G*8dm
zK5ay`1vlRm*)&$>9J|b>pV^K1=Bpu>4lG{5`;(z8-lqv`BX6x(dw)VinZ3W%X%Ma(
z@%%;8TlXq$*z@6ILV`8=zhx}m&U)LN4kWf+5$ZST?`iSRoQFTG`Kr2CskSQ`9Xv3z
zSjj+~Ik9-pQr<4~DH;28gT<A(8C|9spY+++yzb<?JAU`v5R^JL8U03SjG0&m96U3<
z#G|33j81IrZQ^k2k;k6n^#>a`l{-=9^ra25n^-TjWARGe`V#Y8o!O+y5X*h%dd!=n
z{=EFYQK=iZ$0Q9scc#>=3%Hxf;+?4Q%h+)rV#dF3?)*6{u1CL6=VtYmjjZ22(Pm%6
z$?qO-!r3p2*C?)gTxqMYC6!iPNO#zL#k<DTek(f~B;C5?f62I>!5z%A@344Z7H3R<
zxNBY1)Ax&NudgusfbsAmk0Wi>YuXqr=)PpGz5-{EHpIu=W@l<oe%Gj5kEiSQb+XnA
zC_i>;a4#p9$oT2kjU0=OOTd{wi`TN>#;I@Z`j<Y~ZBVrr6|;Zq+@V&RMoHOW<FfCk
ztx2ph0S9_4-ihw9AA^dIyS=|y*n#1088&w#?{{fZ=g$lC2ZYvrec?ezoH?<0*3;j7
zXcSTVX8#BJgU6dbPE8N%P;c+_1@Up+XD_VTz$qB(OBOHWFI}hTXvboqz0#El4tLc}
zI_REU(>W&n`h4SJZ#-IT01sFz%XO*@&)!jCTZ21q&8FOJaizJ#$$bWykLo^H>(+E!
zmyoJ+mf%hTi}$2fWJb4or=zEv=&m~M-tz9u*i*`mv)fG>`h3yOUKuWEN7GomOs9Y)
zlOKhBa#HBpwLGrsy{po;4Qpm*7<oP(?BH&_279MTEMA*BV>AA_sG2pY^QlEf@;S*z
z|DJ5P^;**Wcjv+;JiXZ131^ioUQq1Xn?qLg=s0$K+2W-y{+iigZ)5|jv~IB_Yj>H{
z*4<<^)|Ym~hw5(gm&fhLZ9h1w?zPmE)VBjNFFu_!)M3k(#_co4*oIU=J7@7alswdV
zc`?g!Y1Mp_mtFc4bMAhNQD-N|ZSlXdKDPLt_NA~+X7OGn_S|r=x9-4|i+&wedP31L
z$DW^>``V^@-MI?;?2IX^Fea>L@zVc!Q|<4RJ9n~OqHNE)8a#h^Gp3dO<hy68>Tes@
z^jPJoID2IA3f`Bmj=7FpXYfq5enz#e;lIyM?)#<GsFD*df4X_<N{jS;VT$B`EEdIJ
zz0cyknd9?&_3%qw0^N%KUF6!Y5hGu_?dkaU)kjZ*jkfpQ(R4cYvst{J@#lh%&HHP#
zZr7Me{>p1tAJvL@(QIi~@1!D?XJ+>eLcOhL@v=rnUJ7{Mz{UBGVwOH5Cy#SDo^o@e
z?xzMNJG37Cv~6iM#t#;6OqA7*)<q{7q-9sOy|={vwrgMK-_t&X_VqCuadTsJ-%4ob
zt%;AW<!zI!p01Dm^OpUgt)<_7UUlZ;>CLmQ+Bm%{Gd(q{0(7)66iT2_0)-OzzaW8P
zV8T;Y1hZn?ZL@I;3Uv$e9O^dG$^u4M-2(gqhbcn>mHuw<$QtSvj{mxahIqLtR4Vq*
zFhxjMxXNv0Kp3T>6n>^w7H*0V-{COY8xjiBB+c;$%G*X}r&q*-?o|AO@8Tb*O66cT
zKd+FW&>){MdE=gj@*b)%SeA-FN_o4W02QoThTy)ofu6hja4&a77|fk`hKIq5P*uDe
zqV!iOL&R_Cu9ShEBFrCUP#RDP;~HeZIY1EzlQm>!oQo40=8bzS273KC%TTfk__rgB
z>A~<MGb%&*IN+Qkzc>}x4H4pw3!1-6$ei?|s^e}WZ<DfAQ7&FBKxsVH@btx=NE|Nh
zkc~}7t~P)7V#iu`;enxkzJW?_Ihhr~h(+J~e9M-KT)ho{Cwog|yCtGB)|f;5LMe@4
zm&+0J3l)Bo{gS>sow#erf|$-hpz{?j4@sw!$delpfj>f@E6Nq<6a0cX>3mI}2jZoC
z7k#kYt_X1t<4F7=8V8GL>>?|!XYW!9a)Rpt<q$YV@P-N-v}t2N-pF9Xl{5Gr9-?%o
zW@6vo-hO~Xr+#Lv?pebLfC)K!d;5X(9Svun@o;gDU);fz;pjrPA9%ev>I0X9P#;<|
zw&S&fWRES4oIvfJqfeLV2H9y`0NtpH_kyjiqv#EY3Q9!p$ll~tlm{DmK4^|;TV?fj
z;GM-UxR=X}+;C=yC_ep7uvZCo!l}i9XIQDk-D=qOECE?*CD=y8La?`wiMhF{NlOz?
zABCy4v5$#~xtXW8m6^4vg-=UMQ)4I=m6gKNL3u*f?*6cQE6_o<Ftb57?CRoAuwqT}
z#UIJWHQ5v^ia8_`Ig3E{xLIcrP7S0cZ1t1`t=G!ay+&0?kZ*`0fH%NP<)$HhIO36*
znO$$5NwW9*fTt-$F#>PDri<*5O>7{@PLLAWYt+$0mCE*`zOh{@Gr*-U=n>wRWj3xM
zLajFSN#{JiL+9N4eOu`qd7ZPudV+$c&K+KskIwN;N@(+%ddJcD<9bK--!=7)bjwVt
zZYfMH6bc_NGZPalb5EtBrL~y?!PLsy!pqWH>E*@i*0=On&^u;_UQ7Lw-ZcR&|5oqJ
zkv6TuztcOSDL=iN@D07wErGj(sB_Z0H>{2e*1O^Sc%e^&83MNIWKdlhjT^S$VT*WN
z<9gc=g<n`G*EiYNkby_^GvTmconyw@4g<4|O<=gczbXv9b5lwtZ`{z(wWWp0pr#lc
zQ8(15p$IL38}9@=ik6_k4$Ujnoq7w7pK?H}ocAU<?<qs;ocAr+dm0l3pY_$tP!1e#
z#N)4cIunn$V4E{0ig^^;f;2XT!AOJCALq4W4o~^>N_IhyGhT51Ea&C}g3UCKvS1bg
zch6<iEer=bAm3M9{c<)Z#T^|#_)tCRvy@-`hmAc#J*hA#c?Ec5q837392;|}o}OZE
z!gty19n}%Vr7ER()DAJFk%e>b@{Bd~H%z_Q-!%JZDi=-ki!uK07w8@w9z-)rPCv*t
zH1+GS9~la}k3;ZJHdlfP-Y+Wr+l&8A_CbjjdPikZn<wJQ5Wag(ft(zLaeM<Yg@C)h
zOpdrCEbBpX<a9`j90euf^uT~iuKC|QvJ3`I+GJ@1;c3c};{GRPDfFM3vLxAIyDvwU
zG`}EP1X<G9`Yl-sbHMf(mnlF+Sf7Kbh^#eanNmQXLq?Cqqd8Mm(HxNS{5s_ASL|}y
z6xXj%KOxNV)3ng#M06G0Pkcq1&?(R)T56xyMGI{a{FuH4V+w_uc&N*!w$lvpw{Y`j
z!54Rdqoa+D<f!@1t8om-+BL0B%7G4HZ9?sd`k7k9OP)crHCv|${ICyJ5Kqj{7tHtK
zI9Urs7C4j4<)^@?lKHs}IyCutiFexgS<R25Dzs4wVt!5_P1<777z1}`!Qo2xAxeeH
z9YbW^<zW6kPPql<zs?|E-o@+810vpqb*2p(Dz$HFD~ou3d$V1Ky!^gETGi@&_+=9U
zqkqF_!6`u>wKH@@T0-8n^aCwC(wtu4aVgKET_r9nah?7Oy^h02jXCoM%__-h`2U7Y
zNr@%%SxM9`g}S6Uq`>Doo=-V-zzEbIQ{O^Wn+zGz2Q1&@GtX8={=AO;QRM|GQtMW%
zzhZrTqlL%6!DHNy>gzX{lcKOvc@pa@@wAe!w-g!#5XALX7j?enC+O!l*pjB8ph+rk
zVjU&kgmsCUm_iWqmV)})@{@Ej2)mDpu%HmRXHbwo%8^R%c~Rd%^bY37=iamlgU}ui
zO}Xs}Q5PQHJw6MRH8w;Rj4poaNk2tF&c3OnJsz6(meFYIG*1gh>_9xUHxUg%I)g@B
zH<X1inz*?!jo&oCB)iVUkC>;%w8@De=IIvrxBu=j`rq-CDv~wzUz$Ai2R{a&k$CFK
zXv*b@)*oV?1b?#+c%JGb4b>B^d(WaA`A^a-!I?Vg6U~FZ4td8Saeqa1Nj%bc%X}&E
zKJ9(@_P&4?MF?Wr-+=ZlKiY@!L`$Vv+#d-v)A%W-c_>e_bB(WQt_NLB`3Zg0_sUw_
z*9dgecqpb@ST`s0bW__aj)%4oEI_x6o6mU%3H~T@d_-`E4<tjx(iZZp^=J&%^b;YJ
z-H9d~2qp1Q+4MM~Y~7z!Hm%>jRdy<0HZ>C}7pf@hfU-Tfvbh;O+l+-{4){!gM@CwH
zvwn(DOJIDHys15qo(OAMS}Txz?eH$oQUUL%9}?uDq754aF-^TellmvoL^_~JQ%~ft
zjV3{_EAyKpG)1I2Qw2O1&=ymEQa^(IwSPS(3H`+mEi`@rjk@CXtmgc+;E4;{6$87H
z>3fGVh4mEGt3Y3G+H6D+%djEjZY(|v(xgw)41^<5>X>eTGR5=>W5p+)K5EcZ$E2$t
z!He-vke|E4+nXE;x(E44mZP}eB{_!heQaWF5QZS8vk`c5{yB0KlPZ~3abHWcHs|L_
zm1)355cjL?K&w61mT6m=HN_w4M}@MO@d=HxTu3hevMg==rr<;4jTXMzpe%WAS>jz*
zCPyZSum4lvI3bidM9w7^%d#8FH2%RdweczFT4mgMr(lGK=1;i7D5H6~`X}{!@P@+N
zJ|SBsqk`s8G+)x3lMC&4KTj*sNVL|&L+e`SpG0ej(qE|v<$UQ#p;J89qc$OoB_2c=
zf|yQPo2LEfyiOnxc}tnwkt{X)7=gxOH0eYT(@1MgGD`BzJpze+wLqp+8a4YC;oMWr
z(+JT)x}1*o2aU_Q_7FNGDBRy0r@GkXR|E!y4Z-~r8tvE-Frw$vx5-$W6!uW;(b0M#
zKGmU6b}<9Wfg2}i-b8b^fharWJIbc?T0)-wKwH~%<i`Os%ws6*!bAGF9nU@p!yX1n
zSRE<oP7T~$!i^%X)o@n=$X6MExK8rtml#NyC$P1qu(wMC4La$s&TOb3qQB(`l|NUf
zbTl^Q{Tq2_%iTj3-%+459y(W`_+dd|3V(MlE}hSlj^-&}5fY*p#YLdI0kjs*TaG9K
zNT51v&C6>8FE82}qB_&VGX_7>7IN~+z3vf+OoB!TcM$R$n_40dVXiB_i$Ueu@a4*>
z5g}-nONL{po^s0_;RhG$1&)XLl_~h8oyM105#<uEbkxxg`YGqjWCs|&0oax1+5!Ho
zCFJfokbcn_8anH6R3nqCP}T=6WzlzQ#-g%DsJOzuEz7)R(HWDttk)>h7!P;<iaXn-
z&0ih7<C|i>{+3?xdmuE$`<`?u{~{eKmA~(U{s8xX9z%Fk?i)N5>|xKR5wIPw8L$J;
z4A=>{4@iEajsu;6kAW`0;>eTiZdL-4-A&{na|3n+4g!*0IkLCu10=heQ9!bzxee$K
zJOCtnn&*H)z^6d6pZN+H2K)pJ2UZ2W!-36!5kO1eXdu~Pg#Af%A7CU<1sn&Q44epD
z37iC^`%bW5$?P7H9Jo6u|NoYQ9CgUuui*Bd=x!lI!_M>ovSFA`k$%hZY~lB{NMAJL
zMey-R_S|_scg|1x)fMr*@t%SY;!%6`1yUb31W3#LAfOzm0#cL3*rK)sQoi^MLKX>h
z1daoG1J(HdXkZi&|CU7qV}UWi*}#dw)xgQX1Hh@k3&3f>+d#xsKLAb#z6Z_#663Rg
zuyrMy18fPL2ebvw2etw(0-|j&JHK6kOYxiZ`*$F8UzPw21fp#9DBxP)1mHR#*-qUE
zoDSRsTn5|%+yMLoxE+W#rrrw#&FbU8!$4{mNx;8=M}TC9@fh#{@D%V3@H9{tGEN58
z0G<W@3Ixy0?)OEYJ$_#Wb^_i24g#hEy@0oXAwbARJq~yW7zMlsTnoGpgw06VBOq);
z${qt@3sUw3cpCT&m<D_Sd;-h>!loj#0}PvqvP}GjjYH~Z)cQckT-^Zp0cZrw0+Ri^
zPrx?7&p;>O7oZEUDB5j5pbpRvh(1S6_eV<b?V0Hvub*@;;y<Z(&_Skm&^e}eGl8Uc
z&=ID08-S#DCxN7QH-V&gkQviE$cE`1cwu^14oG@u0VKU^4J5sz{*&~sGm!MI2XHZv
z^o;ZleJs;E>Q_nc&<8TTLtn@Aj_j|J-pvD&-Yo%=-faYu-jSY>-X#G^?@j?p?=Ark
z15<%Xz=yyiz;qz#-D@D}T~X94>0NCg=^bpzGQBedlHM5uN$<J?N$>gsN$-XMN$-Mz
zq<1ku(mU8bWqLOUcn`m+zrGJl0+QaH1d`strYO_9dqC1V*y?0@R|NG=dIy`DOz$cK
zN$(7Sq<0oT(mT>G(!2IR(z`A|(mPim>D>?@>0JPj^ez-gdKUvEy`%d!g5Jqdm)u<u
zZhum<UljMBDZGBtKBi{82$c64?<v16{J35d|0X?#xO4jBXkOnbUL2oae(`8tlE&u!
z-1)fX{6c~JXg|pVs0Z}q^QUy&`T6&!<IbeNKOJ|*%gIrbPV}jaPMRMOohlKX+_~xZ
zr{m5h|3x~sX4jr>Hc#gqp3b>Eo%W!aJAdQOu&7>(<DD5E3TnhF3&h+=T?sfI*b0cT
zLv0Tf>Ye`0oq7FuKHNDIcZNgq7SluXDxwE{ikj92G_TSJjs?~M()^0_)gBLb=JVtE
zaOW^TmX93t$asA(hkt6eAGE!kcE+7yaO-2ucvbm$)DArO{HpQ!q4~=U@KC6WcqF%a
zKx)_ZMd{S}q-)HlGvw15iPCZV_S{~yW;<8_xl?;x2&@2H#McASsmu2Vq(9%2&Y16S
zzB?UXp01Yi;(0ok0;wJ_*I{xeI-U9Qz9*d=>Fo2V*I#-0Q9N!>mD|_VtXJr8PW{XC
z$q#!EIq|qXOzrvMXfB5@Zr_pH>(P`y=6tL@%>Xt8jd8p@tcYH|KcV-O4*!=m#Y2JC
zE7T6B0O=TTDiFGs$Db0nH^=RV{hRdMzS+M^PxZN+mt%AMo8&ESAH5)-5_sPS2puOI
z#yRrh_M^CcD$R5Q5RclGE0FfD-1u~H_&2wQ#O*Cnx{7!gjfX--$Oo^;-wzun^nj>K
z*)PBbz{)_9Eo|5`zrxjkZScDWunVvzuscv6*bi6>h_P8#8#o162N(~m3)~K@2c&+G
z<iPFKaC<45{KO(2@k4q*;}_|HkdE7H(VlJ=pN_^AN=M@grIXXc_Aog9OQDg8=LzY&
zyeJ;G*P%V$W5mPUNcI5@Xg4ZIuCt=-AxGcs>uy+;8K%Ay(`MO$RJ#*1PxrH0Z0kE9
zv&KVoazES7?+aG$n!7U3cJjouN>;Fu^xK(wQAv&L)|_+QdU5{8N!bTSEk~O{Map#w
z?E(L%?EybP1Ci^@+UGJW)qI-%n3Q;(PS%QJos17=&tG?VY|`pc*H&h&P5AHG1D?{1
z=<8`e!fVa@URSFs<!#=FpRcj3ne*1YwcCF@=VW6!?8ewXVCxz>E!Qcu8(e5NnDn5~
zZg8R9VA6v^yTO`vgTpZ?mg@w2SDSZZk8T^^9g!CrU0;05(xRfm^Pg#6=Vwo9y?6aM
zPu$bO;zq9Xzu&%aaTnsF)$9>QkG6!Cu_#g}s6_oqvY65zm6!i)Sl?2<Fj#GCh%=%>
z`@)6xg$wNq7upvtv@cv}U%1e|aG`zSLi@rrZz{AeTxegI^q|nbaG`x+(t|?#!kYfi
z3hfIQ+7~XgFI;F}_`hvm*p;2Dl{mBB#`%{L+1INLl_j=z-P3&4UlZ-JeZ2aFnKwGW
z@Wlxn{uPEo2^318Py&S#D3m~<1PUckD1kx=6iT2_0^cD4y0bd)U)ui<3sD4qW&9r>
zo`!|^`>1%s|77=H=8<dnzxa39{U`hR7i;0(BLB@Rz8zrUA^uBuMepMI2lpCvH|Biv
z8Ws|SvfV@T`Boj@hasKt9WvRDb#E6Q5&}Ery~tAl{zl*4;##IG98aKfgctZ>@95q$
zy$eu;;`0#BCe|t-zJ-L%F??gm=-}+g(l^Foc<0_>q$-5W5#ZnS{VqLp4|F6Rj&7NZ
z_@UoaCdH#b_tJ?+x|dG(_zi#!fVgX{ZUSr!v;$(P$iD5y)jIWV{KoYM^;sb9wW`kp
zO@ViS7C@4hC6Mlora^8}{k)gMhbnR%PyM1j6BA9M%x4{2JGi<{^N5Fovkr`&dTrw7
z$jQN<x;abtzuTGJ<EZa_z-Q#a%16314|w@tbcR{=FAp>KT#DS^w!t%1bdTF9Ak>D+
zE!e-5RKIyr{ozUV(<ap)o>V_iQvI_^_0uNRZ?aT>pi=!cCqW72ItBX!mFlnRXZu&~
zFDLpkuIvfT+UoG?LTa1+ub-R?IQ4#P<K(J!ms~IXVQ>FW>#yQlXI$Ku>qG|cN^|-1
zc=L1flG10SFWmP@Cw-gz%#_EIM~_)iA#)Y_52^m}r21EW-<Ha)cxY0urp0Z2{Oniv
z@_5~8hU>6xkBWFTZ@D}(arww=*=XcZ_y|R=^Yi>LOZAf~)nD@@rUwQ4kCp1LS*rh7
zss8Jv`qh={e^RR7GO7LvrTPt(>PJ(mf8~(6q*u4^jcZhCPkPfeQ|&vMh4#|9FzjaC
zQ|oMQZCG>jbUmLA&^@XCm8JR@mFhQnv^mjNuzykK+7!?B?=!t8wCgzafNgrCL1~Yj
zcHUKVSY_O2j$MC~d)wCyohaRpa52_zyl9-bR{3UdRy8xjTf2XsV4JpYT8+er?S00t
zF=-vObvDMWR2HvprCPiGv?}p-^rf~HWUFU4_G)2UA=^A)Mp>gq1~E6MuE95(?7N6)
zb#&z$ucL;$*LI&Y`qG9GMK4#M5W8$;Sn=A&SC3pAa{%9tu=|@Qhwe`Bs@byjmaXv_
zU2j}C{(jI_yJl||)tfoO=kqn!HV)GLPfGQdE7hN>R6m+h{hEGa`d9FMU#b3(mtZm_
z*C}~i&-}*Y1D<icWjo$qXgB29r9Xa6>9g0o>#-5NKdno_hf8l+ymu+HqSfQ;#rw*$
z9Q)hMbsg|q*qeG?daN?-n;jO@@CqhhnXKM^%dR;x*?8wAyUF+8)x5XCd&s#okI<eO
zv89J4Sh{wz$K711_im;7$4q8=;1YRlzh$MX^B0{?ezyDE<{h?8U8|M(r`4@iu?=dE
zKIUr=-y4`L%5~N(Q~lm_(z28NqW#-;mPJSP+}^8CtxhjX_N``BcUs)$>(cMZHelal
zlq==fX8*wYi4&Xm^IO`&_*Uh!t#+&`t@Gg1T5F?zbDC{}%?V6U<vNdlYgD!JogJsu
z=T+emU)s7lj5ds^5+Cxq>)fvQrfhS^<Z~h>vGAY0xpT7X1e-=N&fSx4Dbz(*-rIZk
z)Toy=Z@G*=X0mkaIP@?0U{$U&EvfSJg|5%04(d^{yN_YZiNDAAs6H%<nY^S$)WQ!s
z=a%5xu0|AZTiK-g!Fr{qR!~LG-WMR7qBn8$b;~6+M#SB(f6a0f-3P6WNi+PodhEYE
zDf;D;bI(%xDUbDOe0$}Un%zd;Qf*Ax^iWo;%AeBxSYK!SmO8M+(Cx{W8>g%Hsighh
ztp^qya-D+xY)ke7&hq<t{<D9!U+hopUb<?dUPGB}?=ZXF7vhZ{#qLb~)b-Ax`Z|@(
zEw=hR+FNHf{53H7jT%<3p?ZE?$tlr$YV>XvH7(sC?xJ2<y=AkHtT{Tl$)Ja@Rm1e9
z`stp<s`i^XVZX(aGSmAEsC?5cd_+mt*#oMzIkCUPfIc2rC$jn4)DwTL+xywoW^n(%
ze^-UrU*CBnc2&ud`)Bq$J#G2<Qc0MvJ!bj6PMaC6-}-Zl>f_RNmcR8(e$@N)_(#*s
zEEa4DJTY$Za%<QqV0yKsXR&ut-D-^<v&L{oEr(et4@T6>^gO)vQoWCJ4$X7k?1gW>
z**MdoWJ21pH??Xcmao!oLYtcLag9bF9p3)eMkAy56|=q9H38pCwkAC&*uSV$ztd9v
z13R+yTb<fg=Ofl<wB7ew=U_(JCAY2XwUc?bKXCCy$G!pPz1x1kxB0BS75u$TMOJSn
zsli{?#D}*YW4^w{>LWwvdyaGYb8P2Z7ygu$b>6#rD;BRdEWhT>8@afCb~G@5TTfo^
z;pWungo>rxOxk!aa`)!bPvuR~E~WZIZpOydtgumWrS+!;cE7gc{EiA2x^KJ`-m!{B
z$qq~7Z@<^~e(?osU)DaxgjKrZ++ycb>vHq{`tw8al`Hi;7SG+Cy(6r+{rf4`kDZh5
zH@O5GkH*flF}2T_Z8~7h((}g?Lr+;`Eslxr)8Kt%r)x_uuFQfS#Ika;Y&N}Y*>#ZY
zT$!PFs})T>nsi(FPZ{0Q>vot9n}2EJ8|eK~CYLnXk@O71*)?9)8Pef|;@rm`QI&5z
zzOwvaQ=?`6iYM(bk7$gsMy{hwPVxI}W?o~>^AZb^HxCTbnVh+~dfB;)#|OtXSzxzi
zA->UOa_K*7K>34f1LCR;ySm?Zj?>(aV>Q1UYQx&4*NOUxjWUZKaw)QC#k*bYH(s7_
z*5`%6$f8ed2kjpkai<deATfR)ekl67@u~-#Z)__yr`r>|t~L)-dOoYOrr8XS8zt)>
ze{l`AqZoY$5=vg^(cHdhD>J7(?ao}E`a0n8s&Tdz-8cAklQ#&inF$*NEZ&T;d%g3&
zk6a2LBFl9i4hwy`VcWXx13YWbPt+g3>rU|7ew&U>+ql{KbK2rid}AtG!}2TZxLG;v
zX<G7?cfF?jY^XA>*+DPsk|WQ|S-YXSwQ@-B9WvQX7H^OuWoKyjR}-2Vm*^yWobqd%
zN*Ch|PHjC<a{Kf9yNqTV!|tvbl{=?dS@pBX>VZ$pKRqttboT61o6g%8C+ocJS!&nO
zv5n`Cf<L~d6t7ru^R0_K8g_SoG{4T6t#*eD4pv*Av2N<wx(|8`iu@dlIYa`J--ZuI
z`vivBJn8(RZ^q`f{kM%jpV;!!9t&gNtpk4VxAnpznJkp$xAuIggV7~d%+qx+xU%t{
z@pO6jj+YuVIcs#We8sw!(XBjT`-R1O($nFzuV>8XBNx^Oe|UOm&gMJG;lK3|-*1j)
z`zn`Rk6Id)*>KwH;q~NN^AE&Ddsp);IlEPCW|w>GE?bqwhR{AX4#p1u#r;hY`x95Y
zl)eypw^7i`Jwu!ADQP=!TTp{?9Zf$%uR37UNUk%cjdIz7?U`XyO}bunDAB)F5%1Zi
zX%35h>Nn}(z5Ro0IqZ9}?>akgZM<Mdlk>eEe#i=cbhGB5HdztNth+nkF?C5B->u7U
zZDDVM(Kn}J(H_dU{S!`fYtYAcS+%yZ&uX6_t2JY;84g&sL$%aRCL6%!VKK?Syihfs
zSN5-uV`hH*ZQgiS$2Yt8TMd2D!f5E?<b(DTWHNiEFGKeZf4c9v=hz!J6V@9VcU#)x
z&9nFw%Iv7MrQKrc*bgislkH^j3cd$jhpkr^W=DN=bZ~y_=XG@7=5=#F+D;f#Prt3@
zqx%aJ2g{x=!?+;TAGcKh<Hy+evB!5qM3)IJzOE<gteEIpWBNgxe%|Iyt(7AdCTH}{
ztoj7s>$85>(Wz61wtdrTdQTs5|I*tLe<mD|^-7AUx-aBXz39bVLW59ewp4Eg`$w1R
z_xu#AkE!R=PX2DwZQ#8IZGwG2HmML2`*h-mmQ&6>xiaCHYc<zE*c@Wz7VID0h|Oc$
zANci;>gmRN%cgaB)1{;N#HFP)zi(@awkg+1`?%D-U5&P04Q?Ik641TA;q(`aOO<%p
z`Gx=7jq%UZ%a51I+L%zhY3A|GzD()XJE--!i=XFs-B~rh>z5O!PS!p<BjZ)`v768)
zE3<K5b}DR7)Cz;<51t*VJ@m;?zrWV0e433f_cCk!`KK|9bsoS*5bGz;C*JoA*sC{W
z;rwf#uDTA&db9s!Y+C$Z4<1JikMDFrxf1gTwm(_0zxso0y^s-PTK&w`_$@2TX1(xu
zRkD2G;;kJjbU1i-)ZR65k7}6*W8KL3U9i*Wcvjn)^Ym*xf19-Jk;4wlkHzG@GZO+2
zWS4&y{Coxa4J+dJ(}cB=w^ppZKOv&b-e2l82-l5x{-WuvdzCiq`S39z!Fsf;FceCl
zPy&S#D3m~<1PUckC;_b!z;?*LKL2M9Tf<dfT>%IRRF3ou<1PTu`F|0Q-1GlZ-*Nt5
zNoJtu?mpbhT@e-*;^!GoURtZ--4LZeJa38LlC5?FJw=#5&h;q`*(e8fFi;Ms;0j+Q
zc_HWGz`Zd1@EGXz^9%G28W9SgD+YRwa8K^dx!z&<IAFgt|2R&1QJB*Se#RbSjX|Lr
zp3-=J!Se}g3Dq|4UIHV>M-dw4t_<{oUv+Qy9RJ2PHiBC#yWv58-g1!ct@QG5Og{`;
z%h|ie{7WN4?sYyk=JWc6dX9Zyu}_i+{vO4Wq971KOz&jSYrOfp>D8o7ljI+!S@84X
zq{GpS>mW?VM7s{=%dh?r(G2&{%8)?VdiM!YD&18<{(fGgawXi@kdyIOG*ixGL!8>e
z*CDS=BP!?0RIue=1azp7knVO|<b9Or7w2+{2H?1g{rxgze0Zmb-caQbci(WhKY~hl
z!KS_)`M1tPu;9bg#M4vZV{K~HQekQBV{X>cQ)z5%=51+gW?^Ds<>RGj-BgI#(%8yN
zX=<$S^7giDX>6=em|I);w6w&3%)HG_%*|TM8|K6{Gqo~SC|g=7yiLqo8Y?}GjlIn*
z%}gz=JzM(tSX-L6mSe|~lZ~AI!3SMn%H<;9*Mr@qDI>GdOTm4Ys(4=kzUZ6nA|7Q1
zPTj3=Z>G3j)12QXkQ5gu_niexV~`WalBLQ0ZGzPumnQd}IlGTTeu5X`0*s*Jg3bID
zkTY!2hf|#hcX?EJ2PX}FL0G5KJK`Y@@4VoCBM>p^-2?v44t(l_`=h@Q*XQ#RL<MKB
zPN>hTNT0&!F2Z*?lIzpk(#*@-)ZEL|+oz?Kj|u$Fo0=*uEX~bP38v=e=DGFhZPL=j
z+f!ksFjIId6+Wg4Ybz6LrJ0q5iHV81xwntFJ`uyxRH3v`D3#XMmR=T~3NuSDrMb1S
ziKnTVv5$2=_4z8F`fRm3Z++V3{LZb<+;?1kn&rgd>NEFuZhhvy%fCK%XsOTfTI%z-
zg!)_!eN?-YBK>rCR}LAX2=w+>h8VPIW8m)2TwB1g#W1+`;2NZTU&+nN9$|n(r+#MQ
zeEhua?F|fE9KI`?fuv_Xd_VFA`{)z`@ZdN?HUQ65@cBv@TfQdRPBP7C-qi2Ok*5%-
z59H*d%kGs?+fL=%w$Q$+VIPW#$<I5deff&&qr0q>-eUX~OG1#Sjg7mzf6H8t%LR5p
zpoj9?AThrJJ4)n7?V9vp`M=PE0-K{WJ&=-39zFO}hN~g59&Cb4)WZ0ej~*0Q*f;cm
zlh60*!DtOVI3%&&3hWShJxGz5Ux8gAuLphkInm^@oP4o0E~B9vTZQZrrL!Pkno_bk
z9Oh@3!(n#8W*gs{QheJd33p#pm^+{W<;)!f-}cq9r%pjk%SG_Le5+{gP%tgR+$(1c
z=W_k(zj^!;^}@YS8aJtp2(nql(*qKiY_Q!g`-~rPLLZbP8*YA^BO6Fau4T3*RW`k~
z&|+MkqhCx5U3S$K&#Odp?HpRPPNlj2kIV6^|K^d4wt70Og%+x(!v)DDFD*Y@PZ9iB
zF|7i}1GcZ(9GT{0382S=lZ`Me6xc=P_Ra-H&3E36<4`s}kbmIiphK9ak#8m%*2ti*
z9Y2tel9J8|y!cnd3j`b$FkWchABa3uTpJL0DR8!%%S(Y#CG+AV;zbw}hvA)Fn8MRv
z*&1t9?*6zxz4HkVWYbPCDCW<KCZGu7x|)Od%k$P%fx}}ie+5RB%-;+Ve^TnInBLdC
z{E0laaC2j!t_tjub9pH+s$^b{eJ3x;JTEoD60PO2+>@!1hcPz}2)q<Hq~`KcU{uMx
zM2L9NrgvifT7Yqdf>^(HBfTnbofJ6iiufpK$s(DL?IJ$%)32TU*t~!?R1m~<@(g*T
zh{r=sAFp})SbpoIDYs73woia{H}}UM&M03wYy%%ucho1|7s)}G4~WO#y*&TZNC^=z
z95S6G70pE2S3jBmu|G=ypik<4idY7uzrvoH9WjeQLoBsJdTxPdxp<FCbBoW$CKR3-
zv6<rQALL0c|JW8Fmh;Lm8=JA;{2Q{COz$;Ooe{l*`LXvhPcN=YGFoYWY8m3%=k3o6
z98kr(KLybx9$%M!gRUV&2tqaN`Oy^j7oZYxojExQ{aJy7qc*ynSk9XN$@RHM-#~eb
z=pwy;j&~~Pvp=>&DJ8w5eHVJ?;}^nSQd^+C9eSq>^u~CqqjwGR^#(8ISh(+Hv~%BC
zk&j1;hwrr9h4j>?kPpXj<WKLtu)j-%(fiAIPre=f0=+``ZDIB;*kO8)K2u|dmZf>j
zrwL-7KZU$>^j2Yl<pG*#j*`5E?U7(Ft1MeD6HR_7lypRR1YMC~@0fyESEfTw>b$yA
z;DD~JPQJB=Db|%(QJsi&c!3tWjv{Vc-Z7)V!TI0Pbwq=%E?A?V)wV|ODX49MW2?Qr
zOWO{e`VW-#L|%u5yut%VVEdnDX8y`B?EQRyeg;@_<h1?DRFMeBpqto^l>Gr51ztS1
zv-O%}VztT5j^)h#hw7G-hjGrnE9ouG^M!UaQY6D~wKvjd(odni(6^A+@Q%iwuk~L?
z&#ndv0FUW_8;mEeEv54Lger!k&*fS)wXsaRzY99J_pB3U?MP_T+<UHcDx0-Qt!+<7
zPmV$V6P`qrU3>@E#;A-_JiXMug}#K|CyU+-{L%Ykcu(zHn2sa6oOW43X06wc&zs_i
z+r$RGZpCeN8+dch+a@H;qlAN=#)edOe&eIKt!@?7C($L0k1CqjAyD5#{W`9c%3dR`
zu6XVF!&4a>8*gQp!fOaeFRj_W4tdW<#N#>XAB_Q|SL83)-(AIIEASwvMI8d|wGa>W
z@X)-*{wMSBy}qHvJdn%<pSufqda0YFJtAs%k!VLUeon$XBZs*Mhx=g*nT|m5r~LLh
zsGdnTnOwE#rtsZ!soIE$pjmF(CT>57E0-(qN6Hg?8mI8(;i@S6&KgxB8;m+!&X=bg
zsr15OtUGtk>&{laL?4ySZxzu`abW!w=>zeqAf2YAGX70_yY!tP<n?u?G$j{r78lsv
zb8T1P!<!lff*T$xw?7`@L&o#r7w8w}r|^dl>Ab8EAKG=D`*vI#AJmTtx~|!Wk`A@y
z=kiW+l#gJEhsq!s_XkZLJWU}=U%ybCVhR+A`zxZ0-!?$1JmH)2CH<m0p}jP5UOgfA
zaFYAC3e=Q+fipx-_ODSEjg8#dH+ROY!r3kUPv5Y!P^Bp63k`mO*|+VOo96gb;?AJI
zKOJ`t%=tvtEYAtPmuUUa4M@}B?m(i`1J7YL=i<)wC>_P?jfcW9Ov%iF$AL5sp9HoC
zo&t6So(A>>o&kCT&jAB~7l10@MW9el3L7u}v*nQ7xpN`zyvQD%s#xx4bvPf<=YVvM
zbP*`j7k7^E{pq;<ac-|#Q||8}XX+<E0I84v%*&nV<o2?^KOMK{%<LS<G|MXrJ)-h-
zfX#rVMS8{U4}X6;ZZG%y(#cV_2d`H&OjA8zN|@sd^gJ(jipT9|a^tuh9fCOC9A1AY
z-tv6%yCBMM3$JI|$`!}s_OrM>70q%ViON;wlb^r`)hD+X!{w)0FZuZ@<@PYRy$#KD
z-|`(w^5FIXxcvbcDqSo$8(z;So;@!&n!kOs9*~$@4|D5el1E*{htD|{`amA2LY#+i
zz9KP>sA($T3Tz3)_@eFv90VK;^Z*V8dIE<7(Ko13m&|u|Ja7npF9RYD^L33rL%k8d
zaWz5x2M~RS`Xvza2lZPZ@=$*UjsRMLrU+nb;25AIa2ybQoJ@`X_XkD+y@3;f@B=EF
z1cX0R*%ToBJ2KzK<ik1^zYhXu0LeFX9Pll0CQuLi1hav(Um(^)bw2VG>sK7FH`?Sb
z#4|=&+!~2nJCWS$gHHpzr?3L$(|T$p&<wZ=Xa`&abO9y;eSvF%p}_S($VRpU7zNx3
zTnO9^Bzf-vCIAlr4+HV2j{xzg(U-G+{ygwc{7wVn9rOL149vuDS;be(=Q#cT2S2I5
zhu=aO(x@8%slTWFiOWC-;1wXo9NAyMp1^BBv<2o%*%z3K-{HVJK=>IXdp2tL2W38#
zR|D_k_jcez;2%J7yL8S+zCydS2aVi%fRih=FX|sjmK3D=inT&qZcfh4)hVB1c-NFN
zK`6-ACG`*79GRQLQavLJnE|~=XaW9+F2qw;1)2bbafzGbYEK8<VCkCh=|E3TI&QAY
z&95}egD$8+f^0buWz)Krr9->p=Z4&zk<wAS_onv<7JNF)-PCl{W)1uW*aj#EIsl2M
z_CV58M<D(!>j>-y>;&u!>;gm|BI^ni_~hn)+`Lee-d>1D^!5gt0_OtX08629{cN9(
zg}xd)w=?_HXWf6=SL1%{X}}i0uE)i(wHAB$B){tXv1!?lMXzhxB>$VmEBM=cso&@q
z`c@oQX@1{NJqvv+lKvI^t+&)~m8IHhC?=<J3$~%sjKwSXTkrlXUct7Uma%vRe<PjB
z;uUPWMd~-<Qop5^YI7%{F3GRpZ;Q{dc<C0af<KM@@cGEO)LHeDGY0N>Kk)M}j(*!W
zcgY(3aC`s;EUC6u8r7q6pQb<2yEmX{M$LE8i33a;By_6aZ)2R1wX9j^(uR6lCu4#t
z_1j&kHd&;8dn(m-i_~vVrP^+pQ=jBgux%cxwp)r|0wLE)8Zh9Qm(iBjkxkCn4hcQm
zIP}03pEy7J_}PIUXQysW!el_Ijh9=PD9d%Kelgrx?)AdOtKMxii}<I}vh%-=x}PyR
z`{kg|MSMoCEBivaEtphBU$}S1yFp({z5K=9xL4)$Ma$1jo;qr+EV6fa{kDHb4qgtu
zl4>JDstpjSwq>M#BQ4c-i_~w1rP?TwYWrqiL#nrB`>$ri`kZ^I9+_En=dl&x!xN6I
z(OEV6-Q#7&ediBUPnB-VM5>J(sW$$k+7{f}i1-+kb|dbz+RboxLyMH8@<wBI<HucC
z({Mo4nVlQ;cAt9!UZvVvk!r)|XWI;vYBS+YW8(M7!<oJh10$C|y7A7f>)eSW?>IUv
zU4MN=g-LA^exDIlCj|Qoh7_;PAFC#MAFDBQPVktSD`P6m3p;I7b3&^dLFRAPe(^DG
zIaVf<YBMm3<@fV!0ZO&;R}70VxsH2Z)rV3l^Oxa=N0lCL|E$H~hfNQAD6WqGGGc8D
zi<V;+V4cF^tqZIvuX5yAn^yr}Zp`@Q_u>hq=FIqW!>p*i4Td#{GHi#1*(4Uv&~aw}
zN)h3kCta*CB-`%P<E%=d9nzkx9Wg6W(ct*rURbb8wT<$#ZIt|M+apqKeoD1H^0RG<
zNVOR#)dq-En}Jeo!AP|MBGtB_R9hiZZAVJADI(Pdt5lnsQf;t)zy^q1XK~<xal5v+
zNPjxaE<I>W!xwXW3VkM$Tnc?A7WzyiJt*{<Sm-m6^q|mZqUQdjR9i$+Z5~UtC0iPs
z@37^0@XYiQkA{viI<d94iNmc&9(#`0A8g=M?nIf>mo~_5dP%p5E7b;}RGW);7=2$B
zXH0*%YhBdS_ls(;uQ2<7@$e##BW=}d+88Y8zGSYx0_UDK#K+ubXKGJ=*Qi^Mr|b50
zvepYIKXz(xFDIAC`03Y;9E*)hz?lMz*RtQnsc-H2mp<5SP_-8ovw!Q{p;ntlN!elJ
zvhSy@Nvtvf2Lmi#!8Y@y+MJbY<4UT{F{w7uq}nEvYI7{ZmgF21yY}Xg6+JqR9bdM1
z>5IQ+cGw%)z$&d<Y{}YPCbe}pS&chPIJlAPsO~m@dE9>7_JgD9UQ10$eLEoY;?p@p
z9ky&~+&*KBZAcaAHsGY%xL?o8P5<XjwZBvD+{t!{vOVi+@ciM;m{#_a@1CiuzinL8
zW0kSqPiOHw)xBIgpZIlX->sRY4_eeQxNNp&b#l^_+IlHQ!&<2y^u&2tE8=7DOtpSS
zwXNa5&rk0ArPQdB6E1(cdFo1w^nGE9<bNy{#o$bd#d|Zy=lAO2m%0SH75%%&wO=Df
zzINNw@$ajTo(3Cj@4KVvbl5m$@p{Ie3qCgQuhF_)V<!14uU&mqE8<17rCq&~iu|{I
zCdvv!p#%ygP$+>y2^318Py&S#D3m~<1PUckpahB`M&S4Q|MOOc4hsuX;ky$zW#I6y
z?Em4NUr10O8QpWw`No3T*ZaS36R<D;oyYScoak!-O5>@9XB1s<JjH#p!)yX-`wm_F
z5un`&uOW&M_psL7w>4B(Ux&QkUum;X*IJj|DVEW9C|&sPmB$q2a%v7Jfd|KKvH_sa
z{xGA@D<~i!DA3(knNx$XU6@m=c0?9uJ4HK9oQ<2>`1XXpb8m|?23`-uxiEUV^YrM_
zg-`@BJp)0HN)kO%<dl~t=X_}D%hU9jrwQ9MGP-{`2oK4~<B+C|f<jQAO0qX8l9GF1
z5E(b&g@v^FeOI&%f3J#fa)N<DVMFi%5Lfl1R7#}dzAc*2K=_-e6vVH`%XuRHj<3K%
z!~6n$#e^UVleNItVZPGDe37hEzK^dQp-bUQl@DJ;H^;MfzKHMq`0B~mm#R2%DwAd7
zq5ArWr!n?wJobs}E2l@wx3Y*QInrwh%r21dz1Kk8!3_${D{cB4>3ueonZC^vb46`X
zs0RaTcnDw7yI(rJIhBBXq|)q!y8af;P0%j1(JaU~ji;H~0?Bv)9xvp#oa@)vr}l7n
z8sbOa_l2VS7jy6KnWsSzy}C%RB`_J2-cuPCxMVGoA(so@)3^2{XBG6BKDHFTHx0+%
zgm3=E@?Kt&D`_x*@*Rk02xxcylb1I>?JtOSO?gY9zYQYgM}Keu^ta~qTd)N<5n~I{
zKOX1?`qTJ6@~a+5)K51?d@Vteoaq}vL7zo@uy0q%{=!qVG0tYDJNxF9^k1-<AgF?1
zgn{y+?<A?tLW9CXyp&uTvhlDA_45jhJqDrfNmM7CpI)*VK{gvgl=!qZglwg91|2BP
zWW;}t=OE&$`7~4p*?*w6DU?sVlP(BPTVAG4W#}*XHinmJ4A6sQdX&?NuVtF60i?f;
zx#XJv%_G-u)xRKDYIEA;YQuOYTcpzEO1h*e*AI|SC-C_URJtFNCf77fTG}HGlPjM_
zkSp~c-;!&NuJUrlHx6umfo~vW{gCePK_*vbpjX6m&LBxL1q<2&lPS>vc4Ta<%bk%x
z7j^WUQRXW=P4M?~teo6Ff^<}Dk3*>c<z=~|#B}xtox0pu_!XVGwV&UdjGJo+w6gI_
zgVqnAa|y~OT5Geia%rV{7t<=(1(cWLXeFSbjzsJVT9<R}pR?Y>O&dZKeqo`UP;G2z
z7AKN5tRn{nxCe#WVOq(?41kuv%`2(B4Cd#wf*n9{`R-JwM_8SHUA`c!{7H~R1K9$3
z<)Y1Q>o>-8&r$AP{y~8>72@V$_U)O0R@ed&#^3f8IJSGC&EuM)tPPOn3x|(0exzoc
zM|bI4DIt&^b2R7L&?Gw)^o>(~b3L+$^R2la>G>N}fIVoZ`AxACTzjUmkorkMcPQSL
z@~}ULc=-NIR+o=QV<h$2)HiyD`}inv7m@mF!7dJLB!|OLgD`xuzX^T0X8$YnrG(v4
zKe|1CsD9l02^9o-2lD;%^NRR^pjk)qliycIf+|v8)W>Mn6GyxDdQu^cwmCV~)3@fX
zB>x4F{bSHi_2kXy<=Qyalh7Ygy#9#u01wqu6dzBhC+cf|W<3S+ZF!3>3PXSzu)d@Q
zFa%}EPJg2<vn3x4Y@sg^`hLyXooKxyH)@K-Ejk#IHFDJwxc)`xBkfv1R}~??q3*`i
zEwQ-;^)uEv?@icy(lx<;$QV5?TQLtK!Gru;JP1l4i48t-4kyxi>5@Zp!Mq6d(Z3SM
zOI-l<?RD_@5-;4`^y|Krua7XVP%qUecdoAot>J;8e!hW9Z#mgs^$H3M4THURiYqsg
zH~b0pp#)7_J#qCx^+y%lqM`7<<yZA&M;}Qdh<WozJ}KYgEw`R>*vqXAtsLh3nV6KS
zbKk0`Z}DiNg~y(JdrIbc#PGrDkA8ZCN7=V{%&k9vWgr_u_!^R~XSp)x^o-huu>a&y
z8D%4g=@|-owtS18JTfPe@`zNjOmk(FOVe144aQo>1{f&HvB6^RVByf;!ND2-Yj5w~
z!M=@wH;qJ`4L{DHpFRIat^Pe=>dT=+e~nCNi6@)R*AY4u79#OqBRsx%dO;>}2Sk0|
z*ER*eB15PxBiM`-bCA~-bVI|&e7i%-Gn5AgDMxxKRYISr&nV&kL-PbqKE`a0OE%ZZ
zRu+*<;{c5pB|)cPKbOXOnghGwoez-4kO!#m=cw#f_`R3$!;LjG)@R_oFrOq_S1<X$
zQ+m=Fsvqa?sUM8g`BV`7RZ<Oc*$kA;<Lf7pHc1i0_0tzL+H-3L?U}+vm8P1ARJXt?
z%GGksTH@NFW<7Co`gT3l(o#>oMfDVoN}U5fsh)<4)+kg@WJ6M1Ps{kfQ+jTWRgsN&
zX4RRPm=4oeL2FQF#PQ(tSgewH=KaEUvoK-(c0ZYS{X+Y<qV)r#Mc5BIriGU7phcIf
zvw~?6`W^5fl^)u=)ud;UphGl~L8ys`_T8x)v;#dU;x!7W3JzDg4^b*q?y9g5L0|rj
zby%MK{E{-hw6AHoIS{pR+FvmRotkZ&_6}6wf$D!L&!d`{L!iE$cqFB0i?pwPn8$Be
zfR(}|XrTK0UOtI0VGh)oCUOX3zTP*-`ZhnlxIQ*N`RAUf$UTFC{H4?R4rL4VL3D=j
z^1rNw&IZuQ<=ncF>!-e<W0<0Ge-|2~*jJIr_YY61WSJVEd@-$pOvmsYm{_Kc(3R!f
z{#L%Ueh;Nm>%IfZ7Sk!rR}5-#bx-qN>eJ|F7~(qb5sl3_l~R%6xtxV)ScoDp)F&t;
zz@1wo<*r-5-Is9oX@zwM?JIKr9N;DlWl~$Db;m0-s!(_x3&bRW>RzBTnWwWp;t-uQ
zrws(1s{az5bham^Q?Pxvsx}BiXo`on>}iY`4my{M>C6?MkVU@w))IMqkK9O>AWuep
zn0O7#rlvXXa_fxprhc#}{)Xm}^9Pc@z}Fa35Cmg9#24|W!jF{yFkfOh3w+VJ#E<eN
z_%}0_gAoMME83DIHeJxqY!UD6Y4$19_vPP61@oP(UTMzwb;vsgwMCgi`y@VTub%i6
z+wUC8_k)k+TyA2T+o3LWf4FbSAzL!t;;~bpoAgdhw;=1u)MycC$xY)YwrOM?LHFSw
zrW-r0$m`$sg~HjqE^IAOpniz@7~1C@4Ep5UIVNrAisrncnGnCziRg?5LM<WBKDr7K
z+})`QRrpg}YHI==3$)PT2|A4b19Svyp+h)Js7wlmK=T}uM@2mCFy0;B%f<%H?QL!w
z3UR(Y2IQUJYLkIbcAS>7T~Kz~Pbxb<zRMYa2?Vho5Z|&~`SZ(X@ihPE@I6^e*~GW*
zPbym*-$MKJZ@}1QHd3iCG{IAi^q-Tt^mU-H{>Hp2cb|ciPeFYl^?Twqw=nL}elOXa
z9<J~YSAs5DdryO`hTuK6hh$9{jk#wz;<Y!mEuru1O_32S@d!LN1CQ$O<x#YN)nHRn
z-${Im*Q^4cbpD{prwZ?!K{t{9n+BiawX2xV4?Lf=-$H!SPny%KesoUn7fN*i4|LM&
zQ*%Bq%#oMV;SYkCMw-v7e!_fSM5g5W(45N)I@6veaT;{eTwe9V<5n(})MrX*8=CWY
z3;w)jH&3Iu&$56l?YVwK6@v5roGm}_@*{n;P-as@CKg#qKym(YM48S%Sf;i<N~ntz
zzD&|*(rX$jX$@}w!*wB8E0?a<;<*pCJx_jq=1&TZKwC64&!KsDCD17Q-abauj|%;s
z)H#m04<*`!KE7NN(19SPtubix_+Hxb_J0C-Os|S@MQHpt?|fI>_Yr-<I&U&hpIDDy
zU=f|h{F=hwt2f<}qNzvj-M>IZNJ!8K@mQQYA<IwCX<bES3ug&}VNG$_mr(Yre99i-
z2cLvmrh-z+?au2<SW`|^Z2{Dd?D3S)#eamg7329^TY8~6%t|R!ux+2rm#K$hsLYCZ
zUV_)<0<S8#Y31%t<l9#WGPK}%Y1|AMA&B$6f_x8)@*N>$jCfLLcI5M(!{;roAJPpq
zpEqfRFfsdDC%&&Nb|Dt@iOV8gh|^M*rVbGQ-@}(b#$^iPvMeD$55BD2j@w-uTawBW
z?BHMiMp>$_%le8fDLlOfAJo-x_pQ18B)LvryR+Z23*QOpxO>ptedH7jEG6&`pWd<n
z+skVDjr$_Z{;NHZwglS(F-4Mf08-Zr+sw?qE9IwR>-e9O-$>-g-9d&g1^k=nqdN1)
zL!mm#r7^q~kd9Pp18Li;4v@yF`alyP>@2Hk{t4T~YFl6<V0)k;up6)m&;{56I0y)P
z&5R!^pSvsk-zk4G%IEI%a(8Eme_F$j!9yVt)lU3x0uuk5fwUdA71$WK9cTgE0qg+$
z1Ly|a1so3C4U7Tq0j>b<1LBeG2i^f50Mea~gFw<VMi0BQ`#*!8A)tx7kIUUzC;61Y
zJK~XoHRvY!;GkYj{jEI^T?(^bO#4pl@SF4(y1?uWcLesv?@qwJz%IZ6z^*{zpUUIz
z(2`FiP9J}?ygtZ>%IgQD^5`H}DDN=-&E0v$J-{Mdc|<?zlZ8OUC;ozgRR5ts8(<i)
zGcX+J0UQDJ0YabEh|BD%j{`!F)H8wjw|Y4+3V0Ma9(WNL4ZIJ8j;M>G{K-J{0nEO7
zU*J^y9t?~HlAZ7AKz|_eRMVZ^SwNE8VLaSDQ||sL)zkk}K8Esq1o3>(Jz0SdXX1rF
zt3(~K{s^p){;=Q*eyP8N{;8>-LSLe$_UaC71oQwxCz-u`=$gz6zezrnFLw`<)%{P)
zSB`wSJCj_$c?!x3c5?hP4CBkEc--Aa?eQY`c!?B`trfX@YE+Mv@NNkn3gCtD`3^|^
z&U>I8@B@%!^bb%0`~-xK()R$&j{RpKbdHE)cI%4(Nynjc>QlgCz&F6+K;$7S0jvN<
zN(0HZei>jZU^yV&Z7dHYxe~qH{ki`g^vXdmcQ1{*ua;kZad*G8#}n#{^5gDRapyPr
z<;UGo(jHHoA9v4(YrpyB$KAit9#6=R^q#wu!rg^<Rb0l_wnBT_54|u#92$olfro(9
zACrFqv?=ym2|SGVzQ81)(4M%v6hAj#dz8W5J>d3GNdG}{j-P?^D4%|(0ILHp0&4=V
z02>3Z0*O9*Jlws3AIrxW`Ecj`+&uufPTqMRd@!hKJ?sJ01A6l9g3@tk=v@71ru&vZ
z5=zINQEN{(n=fw;U*23%dEA-tzevaS8NNRqcb>|fFOi-?G%^D`6keeosGc%`wScG-
zRxiXKcfQG;Pidy3evHz61l9%q!>6;tzq#{9?wpR&6~nuxcqr&V4m2)MKStvM^<$(D
z)Q^!qP<rlMkDJSDrmx7S*X7ge0V(fFe0qEQn>#<_=%)G<>!nox7nBcoruAd_kQ}))
zCT@Jt)UO4goAeSsK-l=Wi04C&cih<zHx5zzLU*1sULjv5FN(*V&1jEjB8qpI-@hgO
z*UYbhC|+7V@laPe<#J~d+RJSsipQNFXph&Nk7o~><b1i7_&4=`;(A+ycxCY(;}{!P
z*8yAL_j(|Blx+YC{fYV~<iqrz?N@XCl4iY4M?DceGk^_&aeTe8bo{)4`s?pX$G7kA
zNhe1c+&-&z`Ns2dp?KWhC^xQX*8fsI9<@JiKa<<HC;G+hSCZcsUjEgQ7uBP<zoGdt
z={wDjD+6cn<&xYy{$;u}wttYzzqmY8)C<!iAi5&*CCv1M%H#Idw5PM;(^>QB1piW<
zkdE6M!`dJJBso%lMsqs~*TD~!cZ28eCa^w!-vW}J-UiwO?*K_(<#?9!^lNLEwMFp`
z=M%3EACLG_=Od5KJYQXSzPbX54ob)EFKL%YcRpPYKAp2Doku?9(L99YaRf;6KPsY=
z+xO94-U&Y4Nj}{vAkBM?f5q4h#ggkptD`I5cpWv|y|(+L(U&%iD0;d2gxF;(!;05F
zzIx>17)+E7vUnLmrq$0}jo-4eY}N~pS0&2_F5cRqLWhHQN9|n`_o$Y6FvdO>@3-ul
zBa@AHUb35f|6R>{8@z{{OY;crnGsuhSc0W%H+y}2cZG&2*C}yky^ZrPC9<zq8!Ag|
z?YgJ=s=p@MW&3#b2{UhWe&GuczP=U3%NiMZDd2qr7w12US^A8eJkH^G%FT_spBj|x
z(0cUKwx!kBb71+cD0|4!cl){<R%M2%@5HoOb|BU6#LUzEtQOn)4#=$W5R1c>H7LKS
zC;nQu_p__b;QoLAt_rcgzVk-xs*)r3&+K=4+Vb<IlF&$Bu>98Cm3g+4C#F@hiaRd*
z?M%I>q(*jY&be;AIRE3M?1Q70!<QDz@0FeH1`|Km%Ds*olzO87@>$QFF_+I4E4uSb
zmczODc}<$(t}2Tc8N4ga<<H~I&&^9ppOL<B-zS~)ZSpfy9#0-UW<`a}RVX(FvXSfT
z+*HZC-<?ihOs5T>q{wWU9`eC_UV4opTP_><@2R}Fj}v@e)}nZoFDnz@6@6{()Vt3+
z?S5IxVWKG4@zgKcGcnO5%6!(bwS%kMG>>>VIP1XZsn;fMj+`9)shczQ+E~0gwXM!a
ztj}n>@3qdsjIv8^Ti0tR^KO6O;){-b1I&B3{Qx<$a?d*`KOJrt+o!pIvkAqP{!zB3
z`pucKqfe=BPBnZo|M}WyGMQArJ0%#u=M(RH2JF=vvT**jPgh+BWxd(|GBz##uLqB#
zhR1ihpj?T)LKe^KME%4@nMDt|6j`+5-LCc<FHbn@^TJ?c(I>Wp_79D?QweK87EiTN
zuc6GgcbMJo3-QK}Vt1x~>U!r;eVxkY7F&HD?X5E#`vs^IxlT{}5ngNF_qtkDDR1*W
z{CtgN&78OHt=<0PIVT&-VK>J9fqovHhFr(??=!t8wCgzafNgrCL1~YjcHUKVSY_O2
zj$MC~d)wCyort{+7Oz9egtTLCYSl<AU!~oIHZ|kp8jU_Wy#23@Mn>-|W_zz|0{pbG
zczb*|M0A<p;_G^%&WeeyHKrf5>E~_U)LJ=WVRA<A%&Jc?PM{N#>(tv>V#})1o^u;D
zIsNF9xm}Mc%gWvPv#fi~MZry4d~yDxjZ9|4;x%vH$i?-uqk;L`dh&V?H>XA?R4m<Q
z(#Cs{yEmVHDsQ?=CX?#7NX7E|-|yFEnVjVJ|K4BCIZWW?ItBZU`EU8P>Cfa+u)iOv
z{%WN9zxlu7*G8)U7I#ck<T_VEW>)F*$h+Fpu$?8ZuNn68k^Qo<!zN`O8FTiT<F?LA
zFlqbQ{%?NmN#(xjmuRX#Dk|}Lk%-u%-kwuizW%4_<Bj7#7I|4L^H%%phuD*ENbw5x
zj}pN0`+5F!b{SB);}0Z{Jg~k>Ya@p>Mphp3UrpETd=MZHo^$%u?1pbf8)72+-|~O+
zv;B|!U-73S)vwKCrdO}iW=89`{@kMaxOAQ6Z#|PA^*%lR(KIuQ1zQ47j9a|i8v7@W
zNDsD^O{yQPS9)p%Rpjh_0kSE26GvaSTvB61-2M93EJvv@Zb|h+^8gzca-CWGTxO-3
zPtzZh60g(AT5+tC@xko*>kf}iT0QF8%B-~*fB&cZ-HFDg0LHC}W|I!D(K}t{?@H&h
z9(*~mdbMwf`fhtx44!@c>b%z~JG5UGFLwAZ?r)0NpSaqk^o7v7je=h88QN@5N!x+j
zf*O?TX!>y><`HZjTd;o_seW>#`j?3^BtHJ%`_qx?C#TT=&6urrhYSu@Tc5FR>e;#v
zdJKyE99s`(eXJd=JzwfzbjcO-bR7(?Y`kYYUEaOpr3OvT8eJ@3v94uwD^Hvavv^N>
zI-K_PjQM=z!usG3PY=!6d?z{lw;q>|H@@xXI==saow(P<=Gh~&U4vIGPhO(0H+b0V
z@jGp5Z%^oCS$##vg+~HxHn(_PUM4H_f3sEL_^Dzm!^^f8W@Q=<C|=9+SZqJ^lh~M(
z>nzNU`snE3{MOIw=)TSC=6<xDFs7b<TgylH7bXstJza+WRI2}*rEENZFj6txsH@A$
zAxow%95uD(*deBULeuPG#`bmz*)sR|DYV`H>HcpjVFO66v+skA^~GzZZR>o=`jECw
zT`xgb@l^4?^C#yI5k8Nnt-;>GDs0Bcb)H1uD-o65D&6jGmo4$(@vc2K>%6}@bfibK
zl^bT6ZR>{3kW?0L!A_&&S#4*|)35RTZPK<!4m&JA7L)hROb9%XUH)0{^A%W!vT~=H
z$2a>jrCaZy*5@vMp5t|A)%dPoPMkVf`|OO2SIx(6!W!Thi&yCXrqKTl>0iPAZ<1NN
zyra|nuenX4^{o0e?lv*q!nMk@<KyNIbStiYICkENJFeIVNj0PV9=AUk;@>tj;C=fJ
z+r3;;i`-kBoDtdYseHzWcQscX**X*FBjyxu!F@~l$LBL{Un{kKPNv>&(?MldX4i8}
z*tp(iebcl)I@htcT7%+E-}HW8jhMI5kBxhKY4_j!2M*rlIy!wKzUW-7vwr`oQwf_4
z*1l9Y)%_S4)5X_j;-z*0HWSd_k7nh{myXKbx4m?5ScL)GZZz|scyCOF_>?9YOZL|d
z4LV@Za3jVK7H_ETlUL5JQv%Eb76ka}&t5!k%l|e%Iro`dI{rQ1sFL3OgbgjX&e&9Q
ze77x=QX`LhUg-HGdHrI;ahqP@I|m%Z{7nBhYgm3)EV5b+NXn=?vs~qphh3NV+F<v{
zJbh~1J-gCZM)ZH1l>&WX@v_REbvm(GelE3DYS9C?{(9ned+=>Hw=OT&$W=y0;e8@-
zK4(SrHMp>3*}_>f&C@ftPa9Ef!Ob^CHjR}z$1bz!XLe)0`D)Z}2NthjzuW&Uzc!y)
zJ1W?(O*oTFy;|`h2R2mh?!U<JY+~6N+Y;ViJ)AW4VCKNtgHF~pEcg6>zW<w_?bk-C
zpO+TBNMEd{zxmK8qV~=H5A+9*H+`I%9@e4W-subC<GRmYShImsFzh$kP`r@8be*E3
z9gBtbN>?U0+*LQ}pnGyn=a}^C^NowW@o2FDacn7GmEqYtDr{?T=dIb4n=P(1cR0Dv
zAoEe(2W#D$j_VRqb<Pr*?7!vzMyj8o|Caxomh9YRqwn^bwlmKino)7}mZZquZ6-f?
z8*yyS+44ubF5G+m;S21m_^^5_*iTLz%Wp)dJ_~KPmY=iWeC(nno0?S)$!a{&Qhl{@
z%;Os;2R0q*E#05aLRRkodw)7N*!j_zD61W<i%v2~%dTvDZ;AbF*S^lbr+o<R>ti(H
z=Emy2m2l^)HR)g1^0rA<PuIu(dCUIL*3xf3uR3$_^yXPtZJgefnVy<e0lHim3MEh|
zfkFug62Ory?ray)qu<^(Zb6}LL7qe1Mp{|G@~K;ZU*IrhNTAZ+4Iev&x`pGvZlNJw
zZVDB%{SQ-FAz|UFuk8QRcOqfRkO0owKhF4Mc6voT=&s2xu*>s6RVoL&`FVu|g$DVA
z$s6}Hl=o1D`33kzz~+X$9V~tL`NKG6C7FSqyZdl2cSRViad^V|M<~9zHP9QP^jE=1
zy67$4y)e*Ig!!WkN<-ggX&Uq5;)I5I<37BBUO&G;@1PN(_;$cR&k-hty_t^!E{;Rn
z&IQDA(u=|vBYem7p$JJ3^GiIX@HpT}!1;(hZ;Mcn30|}BWGIf7pl*qmWWRv^-m416
zJHL?7F#cUR{++*qy<*=U+oRkEc(8>c>%_{+{q|Ue^2PR~#_)e{rptYACeZ$%C=w&|
z!9(S`;Q1YC<1}b@S8}uy9a=&j+9R+Zp-DTv6Vv_)bf=)~j>v3*2JI_&+Ufi1k%*Iw
zrzzrX<>Qfz$i_3-3gK)|b3D;^bY$Z!nU5F#3-|st(t6<G>VvB%IhdvUN4@_)_Ra&o
ziei1(3!yg?1nF?VAVo?DJs^bMdv6|6P9Ts*P6DAHIx1B_dX-+JigZB%5s)f~G^6w?
zAXVD;yt8MMlMpobUjMiF?fzJv?3~#t@AR2>X1V2h1HBT7KTaw=Mw(RzQ%U4j&G9ZI
zIh6jk=-D!bt)5xJCLJ_~q<0P|{={(WveRWM{)o&%xaBH@J@JPnHsw!YDE_eYp!_Kc
z8I~!1UhzksYeMWe>O-c)_5C@p8P7~ns(m`5KX;$!bm+w-w?CC!{h8$Ur~Ya^o8;=d
zBv(Hrx%w{2omcp)^;5PfJ(fQopC(s7r7(HH;+830-Rj#qzP)s0sdmA0N_(Bl_T76M
z7N&Q*_-t9_;_W7v{4DwU6$h1jfByZ+zgjOQxq3y()t^bO{!w!Eh5jyjHh&lWnf4aR
z_kXS@@}JVP`A_N3Bv-#Dxq30l)wB7#=+FG8^kPydy_3IAkL946&)B~3T8}B~uNPR~
zDC>fObAQ?~)%%C$MYjy8n`8Wr-ye?4`G`HS$<%jAu3pi9N-yT`qQ{b4y{Ergk0rVK
zGym=SDaqBx`K$F<{%XCf<m$Wpr}S8otGAO}eV63w?U;Hord|wt9W-AC!xpz5TY6vL
zdeeW<=`)K~6!U5_r}X_Bv*+8M4_TJJ^N0ez9hrX^pzNJ`G)LR>W9bFuyMOm>;OHfH
z(|$fQdx?!*yjBLilOk8XqL(#oqp~;a(Y2qy{k-#l^7%)->^SX$|HhYRTI4O8e#NZ&
zJ^k05KExpXrm~lJ!;yXk$L+4#xBP}O{~o=VQA*F|e_t==uhw@-uAYsl7gO)q%ZdZ8
zFD%tA=*Wovj_9R%qo<watO6z^EpA^wXnE&eZ*A4|+~03nKf6$>jh#%r7?I1L>&473
zC-$n2Iy3IZ*<bQ_EZ&yB_KBY^W%=%-{pqSy?__ITB>&)y-!QTGSL?<2mKT5jTrcMT
zH+`4n>H+<y^kR~$*J0|<+-^9=>zkmhr3#MzdBdmvE5pwYI>_92dKN+~Zhx*nQ%l)P
zckbngn~uBhX765c>!D_!Om@7OccFN?)8_~5>T&2mx{r@Cm#^&Y&GP1;!H-7_eN?LX
zi>L|B+S!|zEHpRf?WRk8w!Sm^;nmMHZLzXfWJ1#k=_^Ie%DV9Al^Uy01m^m%-GX|a
zyUraCIqp@+^Cu?we^T~d&b&SD(ih8zTz@np|B5V=wtMwXadlu7$CB!v)0)njlGl&5
z1*LZ~rR0J9qaPM&((L;3t@SH=gk~P}VXsz=TMV2%?#JSFQw?6k89U0Jce_;|KB(G0
z{f;JGa@>03`9}@v<f~p}*Yl{s&o9I-S(<$q3j@mD-lk)pgr^>Sep{-j?Y%qS_W60>
zg@*4I`1a`34)%igj$ULTW~H+C|Bqfwa`lD&Q+hEgSO8)_-tYHw{C4E0pPsiEQsui&
zo;NR@8S$R)=${X~m3Q6X61%f~n0!5!oJybM->=7#+<nldz6+JuzwwgwfB%1S{XaC=
z9`MTIzy6i0U_Krn6dZyUfKv(J@2vx%f0rpQYt(Wz<d*f_y4*up^Y;Btol_qZ5D^s;
z9^NxL0&_XTQr3i%xYYUlh7Ld^>)`TYSac|Q4f?l9`r{_w=@c19$!E634P!lAelynC
z#Z1ok7BgclUe?oVGw#hvSXoEbI;yb6>kMpVG1|}>khOH<Jk_PnxG^29rRFZgy@s&e
zaq0-zZQY#-ZVe1!q5IFy==`Jj%|RO_LLwa;78K6+ne6!G8kSR%X}PiyCXusH!eTj~
ze=Ei%EVdY=BVnN%p46pu7P4rWl>SRjr!2DaJ+zMwid&jz<EGw7Pvo20V{n{V8Cr4O
z%pPx6$uR2{Z-$nxZm(0knOfQx_nO6<(OcK;)rvP$LH<YOB<Ht_UWBB%k|7yI+?H>t
zAH-Z_8y*s9O)OvITk1<uGKfGwM%<Bak_`}dy8DF%iZTwD<e!zudjn~}xuV)OC37*?
zzacC77~+0VgiSuHqw?ihXLwxmrF>I1alZ7z%{AO)LG6gsUE{m9iSwoCcpT7Wr41&G
z@|@C{eiCNMFQSXlo?9<}dbzAmhLJqem|HH?c9kv$&8#|eiRMwAP38;B@_P-4nVj#U
z&g!cJrCf6>T@UOz%Yc54mbfqF!^m&wXQ(qzn!_xZw}4q8%P;CI*49wM=|Glx{?+rd
zxPxAY7KOQ71F$0D9t;t&=HMTCC)yC04@wu$8xDt(5l2ALO&JC2L%Il#rtl-!29ATB
z;6!MHAH#6?35<qQ;XpVKj)e2!c(?@4g3BR)t239@K(<6UzJ+v!9Vg&=cph$noHwh^
zPAv_$^IQe)fc4;)P`>TE6I$Ue*b{yQ`@pZ^Ft{6zh2OzNP;_usIG@+TBbaZ2N8vVj
z67GdRz_U>7|KfbU3eRAE7oLOnAz@XzGwsoDFm-2=KHKHLU3caYh1BBq#+Rd7l}KGB
zDA;##tFHIzkMGoT-Q^SkrM&0eT{<u3)N?YBsbiD$*)yh&&A;a?8&k)o+vLVmo(vk-
zZE=nZbAEgpbMSfji<y}NwMh9bm^I%Q-&RWVp#SljS+vEIiUyRflI3~%(D50I7x5f%
z=0h5tGzG=ppou<ZeQ!@H+hNI^!+Vz6_f>d0bHwa6g&z&9e`?OL1y2LeiB<M4Jx+PA
z=)#MuPp?ZixyiMvjeIU0X?df-l9J=Qo=*Gro?EBTA653w|1!8p*3DN+Ecwv4emQ$9
zx1&AJ6x_Gm=iJIAXZ9BgszbkMk+Qe)@z-s_qI|A3xYhRd>YDA>4L!Wn`}pPxUftGq
z__W>Hqcb$k)Uj#rGo@39kD~4uYS?UH*|yK4M!a(Z1=`|oOS;wGp6BzNSG=}ljIDFO
zVZHJr=cIddqT!~_#fC=oNtgB6O9$sdD|`R`vu9FxO8EXd9h*#a?wGsTbfAV$=hjCT
zPRjDF^^VuLyJ<4KH$FqZn$Iq-Y@Me`g<+<SO`EI>*5}+1QDjZQb{jr+uj%#czJgB|
zRG}aIj>u2j7qxlFe9uxBZ+w-%$F&~8KP-<3DmgUMuTNJTzCL26+eP}+%3jX>EmOVK
zZsM?Q6=r1^*QP_ZGo7RRr0q1RLyqcux7F#;rYmQ~D|=g4H#pd7m`{-r&71Bz=jTYd
z;Fm2w@9X<(?sF}M?k+QDEgfuA$0lEmkB?mJQ|PY$&b7x2J(>LFC(Tz=pXM(r=`pM8
zw(my`|Ml9T8%NsNcDE^de!+>{O=8YPtUB`9B`sBU1_7py%_Z$=|4bEgZF{)!jr5}`
zjE>B+<q&yq6>W&c?Lh7iZJ*ZoWP+FH;Z1AGl)UwDM|t<o?n5d)dl(T}zkIz1ns!{-
z%fD>Fh2r7&rmgCm$}iJ5?nU=6TN_z<M!Q+dGGxu1C-+STk*1DK(8}zCOYR7$oHpjb
z<Yg;!R<?C-y@9bEZH>jPi{Fur_NI4+mGDYaU%PrFPxY+FW_#{iyFKmtn-{()KFJID
zl@NRRu6<YFx3w1!EgN974qVwaNAS_B1M^N=-{Nj)^%gg?2VZ6Euk58tU4HG1uJ1Ip
zUY=UO)Uh#jZ2o;`&$Lkeh$@SBUzn5rle3%O$}|1KmK&A#_m0@Hx$3xpGNo_jXnnZ>
z6E-qaX>p5vGRImgSIvOJ=e}$h+Vt&W<8IANm*&?7w?d|@ntk(1=AoJvs_a#Go@z_Q
z<%fM6Zz}b2^QR-reV%f9c-k2$3VwFI#l#2qJ)i#dXU~|rI5|?D{d(7V+wU3N_b=a2
zw&&F2tL{%?K7xrmi(93aA8p<-;P=^m{YtDeb#bQlW&Bo7<dWasINv*kujE?Tx?fnc
zz<#60I+~Pt@!+=4h<#;p)yy~RE_0;Ho~euTzjpSFsf+XXKFh|`#W8hpmgHwmhq1iH
zt$Kk$w|_qt@$skz`(_lkOg{MaZ=;K?J+*7<!$VQSt{*GPf}E*~^D<rEw8OrCc4ps+
z(pR=d`5pYd!VDJjTE8dqyFWST)11-A8-{gG`CE!pdHTiN>%6(%ZznHb?^S$#+YKdH
z&>O1kwVZvZ*X~b#=<nWW#HbM4sgsxU^}AJaPNTqGDY8v`-ZtDl`QIckb#YiXG%r&E
zrUXn0m=Z80U`oK0fGGh}0;U8^3H(hYkcxQp_$T%MgTv785AzFoWe-54Eh3!L_adXi
zIMB~#wM9mT|DE>%WKmydj?WNjH2rMAYMQ<;;7AJnH_^vU!_9PvHi|Wvd54w0da&Id
zZL<d2{G+>B!@{G2gMtI}g9t@$UD79sE5ROtYK-YaZFaj~H=ELXuIu!-bxQrs3PAi7
z{ov|__~yLsuf2PCG@9CdB7>uxX=IHGw+4iV*~9fc1%Kwh=zKpzk6U!URT^7EMde$C
z!HD}sH$4pRAcO4unG=pC?v^7e?z-o8j&=;|mcV!M+t^Q`yAb#Pkahf-LGw|5zlCoS
z4$+MkIrIq*v~ldCxTkc_wHGg6Rxr%j*dTiF7oWd;DTn-p`H?aESpB1ef;dVtfD<62
zlv}BICj!Acf0ykLYVXBO-a~wve_u|aRC0^5h4C!@-{-dqZ^pf&RNZC2MmpU3fcPfx
zi+9xC4BjbDICS-T-H&Gp-7&UpDF3hWo9qYC{U@!I^mN_#ib|fERs<b2(S`Rus`f8v
z<MCT`;cIH{9(b!=b!Mm=q=U%p3LJr*HToVEtJP1=%}lBQ%N~N)?^%(&W$aaO&5yEQ
z;3|3Gd;DFFU$<QLo5<djUYJJ&bVr7nJVp|ZoP^R%3y+QpwRe;78hK3Fiwy4;<`*jJ
z>PjB6&p~w6Bb??|dvHJbQQ|8y2tB0BV5>zpGxoC7PK_n5Ox*Hk2JYebJ;5o1UeUJ5
zzE%!7wMO-gz(I*OR+74u&b{m2lx<G8-@vx~iCUvJiZq+&blYx=a&h_3-Bx)BH%8z_
zn5|EOcg5fQ$W4CBrsU>KzWAW4JrK=#U$1K@|NLzs;nTv}+;Z`{L+XcI5HV<ZVHubY
zmWLK78(uu2)Ln()Jt%uC^twc2pOEgZ<SC|d)zt-i;_my9qM>z#_`!ZNea`}-Rp09-
zp_RWqpyZ>TP~4x!t=AKrjY-~-a7#jr;g%}`ds3(Lf^Wk}DB+EQY-82>Ly6-cC^A5`
z%Yol&uY{D_;XL<&qae5T0XzW5!V{4F4vy<^0=y3=LaDz#h7!I_+<LjuG$~IKK4dB1
zpH`Rbp%8hX66(kU**D>^z`3vloDVC(1(2y*^*!sRa2d}MPT6D89pav24*U$RgR9{;
za4mcaKZkGN{}-?@BwP*~+zMyHZBW{vT~NyVUMS)B;@0!LUKS+$QeBhI>S~KU$;0iS
zl#%u>@9FtjotdiQ?fPB|=X))o<o{Ms<Y%5s`ugwY{<rU~F!xNDdnW#q-~ToDOqhEn
zLTm7S?1HqjZcQ(~weDEcI*0ch?|f-}{jwVym3uy;@{|EVKeS2z@c5=Dk@SNLiM{Jr
zu6g{@A?5Ad4~H-9P^R#r`dLDJyly|8Te3m=VjgQp)A*a`k~TVhbkCzMYpa&LKcmpZ
zK0z-|b*he>57MEsxV0E~YFovuC#TNXfAGepL#sDbDbXoMhTq>i_ukmT`TOtg=BsHb
z=q&t|dnN|87Wa1gk8ay%N88KZZ@qPX*t6Xaj{P<=P1J<P69!Mb=~?zG-znyv33Jbc
z{(W8ZT+)B-`?}`2q(gmgl-_x%#LljMCx^c5v#fLl?*Y@8D=RMb(DJa{mh4~cu6`%<
z<>~Qnewunwy2<0eUHS2lEroj)9#X6p13B|tQghG5d<N?2N=bgX)YJa!%5}@vcks_Y
zb!pzAU;NbTLA%d(k6E?4@{8D+c5~0fzi-ckxfi1Mfzm?;v^sF4OVmd#>yB@i%X{m=
z2At<vM)GOh&27s+x*PR8v~roAk#p;2`6A_-?U`0I(sDiDm%e$KT}+&Ld5gUPQCWX#
zUV7v8%9%d-;oHZl7cB7TI&;dV=NqC@`#$>M$K8jR(^K|-ym2Jpj^}$v3*9U`;Vr+T
zpXF%PVb#_Yb2AUIZccgmVUCN;sVRF;eLnluyHOYIP=+2qn|mRyG5*L>PUJkfWJbr0
zfjPsjm49|MP2=yryYACq{mg@I4_c=C;_E?0&AkwR|L^dcdm+rd5N87Z`@h#~o=dvN
z>izS?vHNWGCe`|&$ITfVTitHq&YDyesmJd&4xKgna@4cNe(qJh_e8Y*BI~-9OD5hf
z?tk_D8rI6@UWm49@21~Tp@8T2<(4cyxa))b9!HAze9v*QCF{Ow?}B+QDa&N$WlF%5
zfGGh}0;U8^378TvC16Uxlz=IL{}TzM!qtxdr2c<Mc%R_#SCs$Ja1}N1{}0anH*~5u
zpi?QA=(vi$qzCudJm}p1pmf}=R#B-|n<YZR1A5v5QLpw3tcpRkKi2<UhdYK&br_CE
z`9*fKMd`ZC?>qIm8>hq)S5EHq+}XJ2pxEhf_1hlhhl+owUl=<CLTwyg>Ju347lN9+
z7<UT^_xB4?!SV6w?H3Y_TCN^0$s4a;mbkqKqWdrBs6}-Twu?Q{NA`Ax>!veYqPObQ
zfz>8rcjx!IOo)gzNZ&4?^sB{A5|`2kHe^sZJ37Bj)D{Eu!reTY<HuF*7+&0`+|~8P
zMXww&Y1TS15s_A+#NQG&*YJ%Ig;g%m)fKrd;r;;OxjVxrdfKlGpNm`)girQCIHRP(
zcZaZz#vk;FwOq*zUn!^jDoIA-T8|qnooMsn1mxFT>Gh|uI!l?7T{&e_|BoPO^G>87
zuD&X4vQJ_g@^}k#`R2gw<4Px9zH3lc-Vn1}ab{)lA+eb^D@MB6&vEv=B}nSsc(bxe
z*;DSx8UB*KBA=k{@}B-33s-rGnS7r>(k;?vj}GAvN#hB~?;rx7hxt(Fo(9<y5c`@m
zHr|nfIGlH?9Mksz$UCS0<ehT7Gl_S;bb05<Yu=H(Wb7xn=}ar*dlc@@wCZ|7&+E>#
zVsnp_f4yvF!k;8Am1fD2m+T85XfOK}*1xw9Ws6bOuDGf8qwt%^SH8ty<VgwhJ${!&
z(d#C?&RUZtq2707N?q?e3QAoT4UPBodPT2qd~sijkterYqBk#PX&j^|DgAkQ&zD;-
z_tZ`N9m}Qw5t)&1dtqPlM<jH>Xow1ilxqjN^BPBiDgS->TQ8q_xlQa&Aoj$68~g;4
z)f|hU>?e@&O+BF8naAIHInv9QxFhkL%q<sTSLr}?<2c5%?1#7kWj{nXb$x!Ak~Fr!
zEU+NV4huoqvxGbxRpC3Z9xMXGU{M$W--W|q2{;j!hI1eV$RXw28;abHaO-)9Fkvp?
z%z@c%Zn-LAPvlk!;+Do94MzjWRJ3Czq<K;M7})dSIL&iSn2qq)f~8??SPs^M60iF3
zLx>xWF|Y~z1~!HA?Sz(4zMaqt{tDZ`2e2J{2HV3Iumem*css$2@O>y{!V2#b4tE53
zirUBGHY{h_pgvC*^u9Rx*4HzZ?<%l;=H9#uj`!U7(b<E?y52O`N3VLd4roxT+_N^z
zPlQgpG{;`INY$GwALs7K-j?zrKg*oH&$q5m-^*MdJzgu+XV^wfGr!x|C&#oi_fvc}
zNNYZJu1~vir>B-*j9ltaN$|Z=_pZkV<(t_x=-{0OPfBEblJdvFr<(Zhcs9VT(CmOq
z+rQQ{yR!Fe*s_7=<}bT2tY3yLZx$#V?cVR^trF*c$+~j$<0p$2RqoFoCS`A9p>>V7
zFReM>9z5!|F|%(p?|muvoty#bYR)gRWBbHZX~U@7DC-ut7w76{++A#G$E{h5`R{6f
zV9&a{IlkVx-+%17NsSkeFZJ^-_6I8WZX9_qJt*zi>nkgqn3DAO9Y-nmvdk}Uxn+s@
z;>>%uRvsK({Bph%InEqkJuJ_--oIZu_~||xxa-PZx+_a=WXv>Z`wy3XpF6|$@SO)s
z3U3_Uy!ft|{oTseD!OS}^1m0EpGx22c6r{1-+%M|lkgM2KYLl$xBl*fes4^Fqw=oz
z)9&=S+oWr+spk5v`CUo<EW5X894&60ep(W^WI`TGcAwAA*J~4WvSp<w?mq_1i_Vlj
z>)|{lzB~TcpLv&Dedy$#(cU$W#3P$+eWfvlS~l!6E7#c{(%*jR5j^QwZms*}%0)ef
zoLje~1$~FAVy{lxFB{BDRWVa+j&29%9)C9C(1p@{zZ*SaO~{EAV^eRgO=o2xohggk
zq|bjmU1Uj`X$yX}A3wg}*oa=A*B+E<*TOS}s+=yJ`AIk(!(qz3J4;)x+|k;-<AND^
zdZr(ia=`AJ`=;FU$ysoUpYQYAA1uUPt778bxebpOZdkHDbF;f0D%W`Mao?^Xy*K{Y
z{zhZ3o8O$Bmv3%b&b(9Z{rPt^hbZ@!RxLd@>y>30m;JaqFzK`0uPFEY9j#h4*qf)v
zf8V-xa?hIYr1YHA99ZGg{LM7af6UQCTUxEt=28oP7+LjsP(Yig@<k3$zqR*2cV=L6
z&%)oN;xRwtmvy_XUw*n$hMta}MpU1>{cP2}6Zf~PG_y*#4tH~1qC=ltz3yAey(K?u
z{<SPiW3yI5clV<Mg@)`ZQgz9pPHT@%eKP9#j=uA7FQ??cRo&L-t}^k^m*d}9yk^(H
z*40N}d(dz9lJ7Eq-Dvuj!<TNck=S3^8}1mM?ex7Ny{-AJqxv6T*(c@qIfsp%yC5oc
z{ymFhW{%j-7+=}zQ@_phDr+-Oo_2Wbj9H(R%oh2y=*WtWli5aGJ^f9`5<M8`>`?Y@
zhnLNH;N<Kz3o<^v)%8x=%waRv*2z+5$IpGYESYdQUwH;rca^=5p68A^=(X{9)zKFo
z=Kf`6VE03@UF|Jzk4@imQN>P8eDe|yHfCGgKHU4m@+~hq`Mlr$w@)J?eSh3|dhEiq
zG214#+dpRB;dHxFaaM@3H?Y?iu`RycQ|f<rKkEl2CB7|v`vfd`)avA0HcRzK(T8)*
zE!lkSmi)D!9BS-SvFGVQpPSzbn=${tYv1cd2D%ovkGHn?_-y$xc?TSs?N-0C-|qTe
zJDyKnzH`v7#eGjLc)E;1|0dP{J6yx|Y-g>pZAyid9F}U%=NWT5?jIP`e_zCz4~t!!
zdUF|r`r!=9EpF{cmK(KmiO2p7zhym~^nRM=s{dEzw*#$*)vEX5_9|D3bcwy%c;nB0
zbryQHnOwDfnP1i~?=g}&DrK)u+C{Ou@8`?4G;{V^!>Z?=J)ubduY1?dQzT~i)>Kt~
zG568tC|B&<rcZ}eiQPIT*V2CL+YDV&rrMCTlbG-*X_54J8r63~`n+Spnx5Klcte(>
zO;;U{u9v+++B$P)pMR7$@YYM_8kD`;CpO!kuB~zB=-KMq?p-?+y6@4Tq6gn9IP1ss
zkGHgcw&En?6lJgd#~m{7SQa`VN6(Yn%zd<>HU2*PXv3K_v$#D<^Z8FBk8ZzL;>FmJ
zXZwCsxbx53i{v_S%sRe7_9<yQzWbG?Jt!ph9v=C4xMOIc+1)Hp>;7xsD4VJLeG)#u
z`m^3kmTm}bQ_yWyhD|kBGnf9}rfK$S_qt5>ddvjf-{o6oUwDfAhHgI?vwcPOYQ<|T
zDPF0oB~RJq8!v`hdQIMcXVN?O`xm31b5_}l4!r%a%gc1XzG?MpmF>!mc?U*+*ms#W
zuyyp?HNPGB{yg&E8->NaGG}|eTrxYl+JN#aN-zGZ$5j8pExsMp;M~z~wT#WTEMCia
zp_;PSw`ZYu98)Kx{b2a!T&+tE8FQt^gkv5VJ?2jOYRT85-|cdVIbLP&>PJQ1%J$QS
z{f@&C(fwZ5>{O$Fu@Tv4N8W2RrO_`Rtg|xtI8WKD+qiz6nr&lq2afA=;rN3--!9s&
zwc6G1t*w#A3k{#y&>pU7KPr3aw$Cco`P$3V`*WK6ZT0=O!<fvrxOuhCvcAjmzTYf5
zFfH|Dub=8?8TomGFQ%oeS9I*s1&-Y3XnWTxdtG8rPuTD1Tx`=j6^`u6TzruG?7>Hu
zywhRGfsLy?HXXXg1o;hRZ%xZo4~I0#*MGp0VjKRoZ;x$N?fKZ=Z(8rC@ZEc|Vfv%?
zpNoY5y17Tm&1tK2To+zAQ@yfJrfb??z3(---{La&i<<jI&HbW_^WNE6vV7SaH$$85
zeY0xLPX>N8=Ecx5_b0HQn#C}S+r=2a-o+cWSYYlKeV+M7ubcB(GgtkMt&e>wA3IgH
zW`UPaAIGk96k6o&cirz%gJ;bj_Y1l@X32Y;@22dHDL=d9%MY5g4zG6T*o(;lKP?>E
z=;hvh-{k*p{OvoX27OkLHAH1^YQ9`)>sCHc;mt-H(wh54@3=GmQ0tOD`>U3jn_^YA
zMZ22b8vEPoOrJ%MYkL3L+{3+3<|vgr%kKj<t&6fZYF9vpF9+_v)i>te?lUXz=X|*B
zN#o6Rf9Z1|vU#73-`CVQ+fCU!(#!qIqiHj4Kf3+HKx_ME)h@qr?@;?~xhpn_$eugr
zhQ-Y1n3pL5Qv#+0ObM70FePA0z?6U~fq#btSkn8a_5Zuu{32da|Cd9mMd9>stpEQG
zXKwFA$H+H_=)XG8+}73Ttw!`E?TqgL7`pn8Q|KwmlC07>&j!E19mgqMPgv~}NRF<4
zNO)McYVpeYuRo_hp|1W){BqURH}scVqnjyLZtm3F626Kanzqxqhd@6MJw9gt$a(0G
zoo<UhYI^QZxJA!C*6FtB*~h!A>qax}8+S?mbY4m)*Vqf-syi+^-|g||KKB4DUsG=X
z`Cb6gu|*_K`Rnm6iU5+M(=6}l^3mm1pFq35#}ueTWXW=%L*!Wiihq^3^|))A$VA?g
zIEwzRT!=>LFuw&y@XWhPmziaEr910|K8~q#F#gK)t<T)9tg{^W;Ogl91LkMByAUD%
zx1XWiO6i1oI$GAsQ)5)_CG-7%s5<*(=&EXuhEM(8<EJ8nst0t-QN6sWbMW7$bC6tJ
z0#ip|uiv33&4y$<ef7k=9VLp-4e`5H>xia(N9AX68?!6h&FP(PeAuPg8%=|Xd5`>b
zL{P-zxg$o;Dm`TSW4A-Is0S@#?^e;J%WU`Ge`@LooKE}po?EBb7sGt5#qInrgNtO{
ze5J&a4}I&Gv$t|P+Vf1oean5$tz2?uf1#i{=q)Z%_EtXrx(!?Wt~I#T_V((U?bi)G
zywv;n<_ccj)^_-`-P)sUs5zwUU8%6J*Rw&7Uwn1w?8k2(yxnobqmD1$tQ)+3b;GCc
zUmE&%(h>Np*Z%)5Yx)CKd*q*G(A_+#@1%J0+s%Osnq4f{yl=mn4O*UhkpJV|skhb1
zdd56!+g$rM&)WVY-N65p&Ovf@-;=A;o?M;r<mzN6S0^I5I@zY~gsD4W>Q0!t6DvP1
zx2_4gd}o=2vA9j!SbWdZniD_Co9pI-UF$B_*ii9FDog9Ti^8^>x)bJE+vZ;Kai2Zf
znrp;^;pSfQF0t+VY>41{i4~;YaBI`=rQ68@E4D4%x9Bs^Wxx70F8CyDM8j@ABh9_!
z(?6bA{>t6;WB$ALk|%eMc>2nczO!~57?<X9kG{qCu5DeW#<|N~H}84-eb2_3_GZ|B
ze5GcdwY@EsxmR1?t9`qQ<d^WV%g%J4->lxCp&3)BKbGfioh<_kSBh;iHf{cfqiR~q
zEM_gIs@RM8xzw+Fd<U=J(YN5Kvq#Q8=y3Pg^~pVItXWgE_U!>xBC{udFLZMEI45`S
z@_+lD<Q3?rvbQT{;PKE$g<CZLJXOV@n9+l4>^X8~mHV^8Y3o$$f4ydUho+rY_67{8
zw4qwcQJ%5SvsL+JmhbsaZJU1@``F$#sCb_<t8#YB%6eioaj#M4D!VFOUorOEbG~1$
zP5<D<!UM<lum1R?PveIf#+`kd#fL>S^LniW{+0Fr&|rJOE9?JJw#d-nFb<Z}6##s+
zsvar2%J-(<WPSN!M7lUO2@Z%1w}%HsS&FtSW@#1?6&xDekI%MSYK4bJ1c%rnIVa51
z!)omvVD*dQgYN#(e080(tvo%t+d?AvV7rT{thIZ3_(g@_hrA;P?j>GG*X`J&0{Pyz
zr$@Wsu)y#>cD@tt=~0(2zX$q71&4E9iMUgvW`jSm)7WDO3$w;I?pHe3_1SvD`}%oU
zyBV7}epKuFa@1X%RIK5V)<9d3pB!-Z`gME#JI}^BU|-=@1mSi)b1a>6U7hMit=Yc`
zudqnmRrk}Hz*BzvN7n2YI^9MUU!C2@c~#m53v1=N+p=UI7ax97Zo978i<$FMX9dc6
zWa@XytgQ9x-@A`Q_8C3o48f(WT}b@Io}ArB!mD%3412EU_6?Usb}qJ>Y2~?5#nxUB
z`FTo*BK<4jvhcfcx%0<P=h=Ac_*>4#lk?qJYbPwJJ+i3yX`GE$QJrm<IqtcPx40p8
z;>{{4JL%%>py{pKi8rf&os1qAopCbaBj2Wfrozh$#MSj&Ha*X%v%+5at~TL!Nd7`K
z!{MpFs&op-9?o>vG|3MZgzc(}fSJ-o5S;?aC#bEc_v-Vvo~G&yGWDLgPcx^kyx5a;
z6I}+8o#-%dtMkr^!nb*ryg^u$dold2r-Pn85{^umg>cKoRxkB^cHVXP@=UTj>cUcx
zv&KXh!_gLMZ`^Toc0OAnTNTuI&`AVGFXyxPMb++*^r!hYzc2njejbDQeewUUa~4dU
zhtoAX4jX#yROR#K`rJr!cSzA0X-4eh{7R+E5UYK4<#w@2xqdCsy^g8#@Zl2rJxZrw
z&_tiIzPBfp?XYCd;XO<3`zk!0IbwF3!jA^lKQ-srf~NtTQK{@*dYtlJ(S;XRpI(=4
za+7OS8~I#1((*=uB_+pqHFX|NU)}CMp|!T*(a~DnZyf(T&yhA;$~W5Gr}eYtM>=rM
zaUmJ=e0Vtan@@e3bo`}o^<LecyqhI*?Ddh4y+1f~?ZmL%opN-dA8YD7G|+|*X}P{t
zn|$?uP1`m{rGjH7to~8cwzLuXb^5-Mch}Wx@;)r{UH9wLL(2ZXI(7QuzaCwduJh6N
z)8}d0&(wJ^bskKe2UF+a*~5s)`sM3A&@@x$;koDf29@fz@U`6^_)gGIt-iZnXVZ0b
zt{DJY+%nc(Z5wkv_TY(!t;Pkd%s#l}j)2N(V-8GSwlZgBTldx*H0_MC*TwJ1Mtjpc
z!%BFisjpo<lBassW3xT?t=*n>{mlzs6qj!aq(Twi;+F5)cLjc1d-2e+0XD0t^I+;c
zm^u%p&V%`Vao6)A%=7c_dTc7&CF6qUh3YO^wZdmbiP$!7^zVJkOZ#E!JOu5w4=b^B
z-E~vvVee|op|kIuO=*5#+|+q6bsnOInK}<^qd%Q`u<grqebWy6{@Iy*CrV%08s&HJ
z_X;!EaNAnx9^9WC^l8rM;|;?)r~EC&sXYB+?seW=@3)heulFjxzU_t*<2dJ6*=srb
zP_Nye{LtUM(TGtYwo@lB=j(T?<eWx<yHaGE_`Gd6i)R1rIuHNK`adh|kx|jF9s%Iz
zA08R?H{Snm?CbY&eyi=2bNye|LS_Awbxv&$V_D1TxbJ^il}xPuw(fqtgTo{BHFJ@D
z5?6wK?$KBX3i0b^hsJl)#4Oa$-c#O{HFH@*7c;)~Wmr{f%Eq_kWN*A&9BZn=CoiTU
zZ>~{m*XdQz<o7?)N00?@`R17THGsI;gS+|pqh;Y2pzBS@n)W??EnMrv0=2QG?aO<*
z9MpHO)P8r_7hjHBE~cv0nl@o`WZ^ji%Gx&Tybh5gqKaEv*2AmEL-x(Pt}UahpxlwQ
zVxp$881G=+TBDdc3PV(d)LOMKq>HG&dBxvaW1hLyx2{^jW;_Q%rrI4Mr;ZR+bIsg$
z|G#_Ie~Z>KCaAJ__k}s>KRLVktvu5&Y`IZ+fA5GLo2!lsC{y}Yj@FkO@a-OR4cc6T
zHqYia_uZRo(B>NSd*|L8TR4CJ-Q9dOEd?DCi`%Xa9c}~^UvqEZy9cUtw|`gEzWqed
zgkay<lfs@%I=glk{gEol-jcZypOzRk_nUUZL(n5lY7P2v8*y*X<Ge2`h7LTD?Sl^@
z*4l4WiORIU_|)@F@=VXwa-Vj)*&F5>w7CXtu0fk?(B>NSFRef5I{DMlO@pJ&HRui-
z`OdWZc3I5xPQ4b+J2)$^$NN3+4c+LIfBmBR6?4w7H~p(npVg)BWoB%v>@`?hblQe@
z54XDX_-XXzGr7A|f7)+u<)+PlD%&D<Xp@E?)#Q98W$%lFQK>(w^wBtvwCg9-J>TrY
z(B<p;+<E84hZn=9F6uSHT!S{(pv^UCa}C;DgPwMwqUFiW@#jyaTQS*OgYLv6?0^a~
zo>?0EP|F+B$mhow8yfrl*t7i}ySWA}a(SBZyT;}kw7KtoZ_}|)!cz}EZ>~X`YtXlI
zm}}51s+re+Tmq>GK|?JCE4HjD2Z!~vMTXfzI<tS?-Z`58JKG}zI{QULs6W|+AJ*-a
z4gdD2$birY=W;)La;tjC-eXw@*RL#U-+yW?;eP)ne(e6Y)Uexaq5iVhU#>{)Jr6CQ
zPhj!`qS<0>TA)woaC_&d@bD0O=iULG>xbK;+E=R3Ifgqlq*R^ubu=QOl`7RaxGYA_
z;QHA^m7m5M`A+8={upJdX~J(<=Wedn@HPD{%#8Er$1>N8A<ND2>+()BSt`d~YLBk^
zyMf_>eZnIH?aFL|VHReyvBs^;rp23u*)V&Hcjp;q5$IS1`-K>8?ljEBNeqp3b_u^T
ztSancU)H%dIOA1=b!;(f2qn!ML8h$Ly0@&mH|1H@&0E5(kR?+`Hpo=9gMH%~`?A$J
z_U&M9p4&rNUzc@q*%L17<ON|T$i8r`3w#H%f7`)6Z>=kQ7y3b_8#I5&n!U!BK&9_M
zTpZ<iCjO3!FbMj<Zcz54cZa?ZK{%MQ&`3Q;eHaCalNJq|z}~Pq><0<6)*lj9IVZqD
z7_~u=uxW!KVH2S^2$MDh5(aH3#BXgF#7}JmL`Ojz2_xV~P;@cK9}fJ|#zNVPJ`Uoi
zoJ-&s04G5F(k4RO);@-~sZD~osZEBX;1u{F`~=>I687>0ob`bmFSg`=ayEUH;xk*P
z8B=4;yn5eWoY!jWfs@*mMGdbuCYSY5_BQ07l``h}v|b(a=RQ@oU(VFuP2JtFUE#&)
zc1=G2AcOt#7dU8MrUXn0m=Z80U`oK0fGGh}0;U8^378T<0x}j1bB_NRNc(w}>1<_a
z*|T%`&i2j?!sI+PTVOE9`7yNChu9&({=EYtqr*6_&sK_q{(^hkA|k_kSgjSySFT*P
zT&1#QI*0rB2vp;5Ii@eFd!)@T(8>XOey)20Ec%&%`LveNDLE5RXTmvx*PRJiy@pqe
zS5P@Wf3HA>k22Tb=^^L(<>$M6g?K)~E#KuMm{HcC5IaZx*<_3+-|cJ4ptW`mm*1V6
z7>r=bIdr1mKjtkN)4Hp9k!>k>nJW)>TJG%J_bu!-{K@6JeZeBDFuxFMP^8UfjR+43
z4(RLS6OIJ@qQWDK7OUzE4<4Y4{s+4D3BTFbFI)UK`;7Ad*WkB|MP=;2z!}D+DKX&6
z$t_`&G5mQ8VLa~=#^|tMzU60??>1T^q9R>_R6;*9F{w!Kp+Wt}f9`F<@%nuQ3FG=b
z;WfTbXvFn1%#679*4|L*(cKM4xpHwE>G8FNbU&x!+SM;CJgjeMc(mOT<`-(SNB9NU
zium~014xWObueOxpFPTIi;Uzf#z-5-8UEpq$q)Yy!Vn++${s(c@Mzj)_k?LxTM8Z5
zo7@t9RQ<Gz7UoF)inJQ^uO-$$lU9-sjkHOXn#gcb#8liQj(aSccITf@n?Zk&a>>qH
ziPPq}Gi?qMHVJ>EvmC8)hTk=9u3*RAwXFYhB_X~xu=q1snf!cp8UKxZC1LI13~To^
znz{<|e|m1JHtmvyiKM?G9|hW?`~tcw`N}-utJmwxuFR3jIi6B>L&5{76C;$2jc{j@
zOwUEJP<bR1ylP>O&0is74nD=XWao>-vJG>}c7rpFMR7}H>&Y$oAoj12ZLr<i+b<+I
z5I3c~{h544mahwEXXncjJ_#p5RCURkzapHGwh)`2-G-CN4yS7!E_u~BBln0ioYFo^
z^=;uk%75;9IPJ8NHmhG)pfxxwSmwKf`_YK1Ha)9klcX*+Z=9f=z`poteAl+B2!!h$
zZt+w6eoP^mr`JVB2Z8pQP6EG4T7aak1b!9ARzy%jzjizQYQ@`9ESqs}w$T2*;+Mqg
zkL0P(hbNAg?7cI}ls|>4r!^{Ebv1CyHO^icFyPA1or*g*cQfML^^CJ0pgKhq5<M6y
z&SEc#D=yBm=TEi6PWc-99`88)YDfP_;@k>~UydaFvWA7*VuJNEk0q}raVh`uJL9?E
zLfw(5nU;4%4)>km!9jZzOHwMM@SD^-64u+iE9VSL6tigWdw8CexTn?{5jK&P5&l^j
z#YMu+ZKRomKUUdK;mjYptO&p4OeHU=uadY__>J&I(r;rwrZqkeayGCYK0}tWXYx1Y
zm)=K^XOBefQZ;9Nq&7R^X)SKa%Qd+7&>M<X>p@0X6BQop{8^sX%c$PZ4Rl6K>OAp7
z%8mHpl^{K7{1O(?WchIqx4gLZKC|AJmS^$D$PZ0ZXb!1%n?dPgH-~ZWsd_^1-zI)9
z!1<m(e1rD_UEb6CgnD1GKEJv8M;BlDhhJ*Vi#|)7e|ld`@1rI5FT&|xFQ<QzF8=BL
z9KHXO*gwjm@{e(ZI)_=#S2p6O_b-z6Z;I2uPn`Zub^7N^eDt<noyn}^E8UlJ+;R=X
zo>WVNpmdxEL#YoOkZi6EfrkHj+pD+9iQ_v1dy+0Qp=6O+F7N5>p?+R<;`b(CPyC+<
zC5=CJzE_FA_4Y|mdwEalpc342edv7eBPjjIG0+0XI^Xx@Z@t~n>vWN`YrM-6MM-Dm
zpyFE|N`2@9EwBodc>8keZGoQG6T5Q(d*aSTm=#`v6l?7Yl(yt56nC0)>-D@|mxwze
zuiD&l9l@T|FUO$d&*M<i;}om_&%(O!9Bc;9LvdH!(d%u!K9^^4N7h5-T7W%~+ow>{
zWg(PsE`}nvWl++4ITZIcaqD%nrb(SG?n!)Ba?913pT+%dP{J7uDI;plRpb}Wb7>d>
zk*V67-55sm+!FSI-C;jC5DtKop@V;)!y#}t90pIo;qWdT1=ACr4`43HdZ?p3l(ki9
zQ)F#b!rz`-ubboLoDMSygIphDPr{F%D*RL6n><g2dEs<e63&Db;cO`Ko&&}GuH1Tk
zs@Jn3AIZP1x#jZ3p5%ubFgvUXMJ~0W<cE4t(z5|1kEylx>aYpVyrb6G#UF83uT%AM
zBhRks+5-FHPfIB2ivKDd+dxmAk%L-Wm$mo%JU>Q8<tYH}DF(K*f7CBuRFkZATC~iv
zXKf(oo#L>2ievqcfBW*m`1^f7Dv)FSm`<4WRpw16795lR%hb=Sv`uxp`zqh!nzpK~
z*!TaUUX{}CPUuvw`oNue2YQk)50v{~-RU*Qef-s?O*UrPe(mz!&-j)S0d-GNw`oA`
z3+?ZhNFR|mc5wN}Ut+H8e|h1gyN7jq^+$P|E*jO~D8eY4O6=#K8u;~)`z?k)uUc>U
zs>K<fXxe&Zex~1rG@;K|PxgBIT4dotmw#ZMMY*4~bdEahHW$qj6;|q?&(-1xxwo=^
zcmM3!yKe?X*UJ88^=+5@`fJ)VWgh#(qG2t<KK8EoMxkHArnG-anW3$BPcd(Pue;B0
zSWZ<e`Rf4xy35G;gGpfb6i?c1S^nrr<fTnV#uRO{VG8l>ulx;uXI5-L)vKKzUHrc1
znB3EPYuZ-&Jji*@kK5gAM7=rgTmQ^me(!0guczGEKQK+VH1nrj?=XGM@a1a`kx<b}
z4zq^a%FVt!G-u%GH6J#+dxr%6UCDoLOqQ|UKF!K*+MBc0*WcD7lm4#U&p0*r^?lKU
zuHG!y&n?w}Dh;X2s8HNfr0V?k*K-%X-F$kL;>+58`luI)Z(gPZObM70FePA0z?6U~
z0aF5|1WXB-5=f>57%u(e>;D0vQLZchWy(~pRK7x)@~$iYtjAlU`bOB8&kqV$-{K1n
zaNQ%2!Xk4d#=5`3KVSbh*7{|QKH5Xhb<^iA%P|I)D;qaMCAGE`n3XZTzNQox6d#{K
zaes^b*ROZ#-{3Rml)K=T>l$2Br@w}7Kq;rcMPU$j9k2M?)y_(oU!*0FMHQK~<_|Uy
zM59#^S>%txk#L<YaX9YbpZKZAQ;$E7T1sx2^N<TMDcybvmdqE(e8Uqp&QCM3X0P`e
z1@H21xA)VOLvJ%)^~@sU%(0nEtZ37(cscKsM@P&rKJXy=_sV>^|K=H^Z!hW4sN@H&
zTZUGWNe%NdC16Uxlz=G#Qv#+0ObM70FePA0z?6U~f&U2!$oRiwy#7BM=~3Pn-F?*9
zJO9an0HR0!%5eaJHvi~uO2u3a_vJi*6kYYPes1kzL^{U&I{$pEpB24+QNptNMRD|i
ze{_`1&fa)WkM6b**;wFWD(mN-9)3|FxGnF9;y;T0Q8sI+UzlGvTc|B8O1C5X1TtW!
z9h(Be``FRR^7N=19v#N^gy8Tn-A;{~4gSPVV~-&@W&K~Dd)VikdpL|NSq9d=<<3_I
z9mi+7&Rt{Cfwi@Xzz-YB^sbM8F#nKn+@BZsjQI!S41zb^o%*#lU9YXKGd%TW@Xsal
z0umli?)<!eC&};(N*Exqiyoxpi&wALhe`Cv40-H!`Y*Z{;{O}m1w<atlafb0Ta+%5
z*5cnk>$i_{Z$KqcoZ!mL&C<IjDt<Zf`-twht~wbM86GNGG*CZy;*WIX*73d}@8e#~
zgE-%k_<B42JmvJWBTR?=wlD{NPC$w&v=jl|ZK!K1pY`|!Vke2q@jAcc8xNxUS%dV}
zBM_~Waz)n=<Cg?W<qh2rYj{t;zRdr`hi|1bF>7N_!spBFN%(wUsPu4#udfs@C4aG#
z#FZd?by0u`3XZf>tdx92Po=2`dKrEp(PT$uMsU?coE>Fe`BUU5@sM{#FH+3j(%d{y
zfz*}~M$ye_p~4ieE7=S;QM**}kvKKwY>bGO>5wZMd~DsjqcY6#A)eI(qeCOCejy=N
zsxMmrr9U_<z=qPMsLJ~KcBs+5Ma?$WT9HvrY@w~BV(|6#?I`}&bf#e@^fBZLAS_JB
zY0Y46WE7EIrQshruVm($rXp@VjP6Qi88jb{X~g?2%#FPCltfcC6lRi+v-rIb{t;g4
z3Tw2gES&al@>?c^ssE;b^CK2B$&V;bM;LiaWGR{cG4~<L;58L?-OoGNKa73X{44sV
zhjK{#H0?US>3Jr#$Al#0t9CU7`gcnp(i-jSixew3W%$@B!@Bq{GW3Soh*Q@LN`{G?
z(DPbX>=~EHP4_!qZXy>~xry$zvnY{wGI~h9OKF%{^>QIHmiW4sSBY!ZjCx#8Ipb>7
z86h%Z%;j2Vyh*rY^*Tcr8OqjF8iv;@&Goll`9DE9DP@EWYa(AmR%@Jv%z?T5iLRXH
zj-Otsl&tVmW#{k!D?;ZtsiP#WNn8p1lZkJmyuD67VvaTKj)#<Ca+_?E;#thIL6K)j
za2V#%q5f2ng)o1CJm>JEy?b~xYRzQQ5Uc1|I}4yH#}UYJC6PfdO>3dz5ntvLrkk6G
ze7|KWcOLAHciJ^{rwda*bPEahXX6N)w8Fx%5?B63hQ^+PqE7wo9+XvY?6ij>!<||Z
zGGrk_-=L?<vZ^@hyhIjVe@KBJzH#MsLtMT~?U7v%pJ(Hy-j(GQIol^&oLSj&ubO#_
zdZDtHA<mw6rB}_$mVedEyMk_((L?gZ|3!LA`8Y`Y+$eBHhL*Zx10LQ-|Lh)hM}`!7
zS&=k3i(Lzid8CcqgY2AhW(!qsU3TV+;BH~EgTru6<)z*HCgE3x)X35bh~GxtWz<FD
zcRKvt#4T$U_gwt`9yeZ>AB^{8AA-CWlrlcdNB-bF$wN{f1Uvna`aquBIp1$a-%j=o
z=+9}iL;No981=<YXF)7L#VHAx85SYmP0-s@cK7(R;Z^N=jbPUR*-p=M&9Q4-h()s`
z%5(DwvtHMw_89U~+GdSBR|c2$yyS>Ci_3>DW>N%Hp6efH&zq1ZHY=mdjQu52KSd}z
zdR>}0zlr>1FGB>qXlD|tv|WRFF+yhVYmc&ps#QLfA0%z1pQ5(aTKxh8*<eYxLcJsT
zNPe@i&Bypf(y#>OcqKCR#h$kwc9l;~VPEo{@vSQ(-7Y)(2qp1f%<4MZpFpX=xr%X1
zQ&d=P?5t64rjT@z?f~12=qZq4*$qlHMuV$&{Z$<+ZBP<df;!f<PM5mz8R3*ZO+>ie
z9?WTGy6ZCLuy*r9xUPBUtTT+Y@kGMt%blGt-qG8dxG<_kO6MlA*Y}Av6)vf_rLIWa
z4vN1<d*daYaIR=FRaV#ymKJ~CRCQ$pN4rHi#Unell`Nvv8?XE~WF1D*r;&KSMeK||
zjq7+s%%qsOw!u=DjNzT6`Z<yxSMpml?*wy;-K#u*A#&9N7abI&_t)h&sh>CTo9b^`
z{o{U<{1l6fOAy~ZxKl5iUMGnA>v>1|r~#OZy(6q?7R8>#bDGnh$Z{6;#LU{tueYs^
z-U5j%jk_lG|C%KFNR)WVPSRq#bd#FX_mqDP>bIy_yS}xl-tRQ(lA?r1uGOjaKGRH?
zm2_F7+Km*iI*DD$4_@jm{XfaGdU)ddO;W%AS-+`bDSe-mYkz^_`AR-A`UOe#7pN+e
z>@P@tEd2#%1XK~TlDkDheQbd$eSag2Vh7^{&4>6WX)k$4_E1SXfpe-3xrn(B=`MW_
zqp^`aV^UX0-6iHmOYd4=-Q;)a|EfNV(>=*YQeP$2wn=+1GPRy}jQ*lg&t#JV#KnFM
z)$cd}Ur<lQ>h+8&wKDghI&r~4v;@7PgCnVJ^x=p~KarbpiOhWywFMF%qb-=P`ZKC6
zh^yo0#hb<THC)Vysb23-kGDszdc{ojNwSci<Ly;e`P|q;8A!b38cKa3p0oE!t4N;p
ziq*&R45@0#_?B^1cx2yK^QOct_JrQIlJ}+F*y$3t5kDL4oOfK@hR2)5#m&VmE^hte
z?Zw5-#Z1Lb`fBlJWmLN<`RfW{5Qn56s|L*cEp<Z9teV!GIRDJ^M=FjYGrbQa`G*a$
z>`{$Uc~SC?m_<eU1&4?sm(&rGcdF@O)6Vm|m>F{;cgXK@wQ$O_I{XDYJC*$uGDNK%
zUN=0lMo37lkYJjSW@<cZmv^Mxmykc4m%H#}LfJ~6%g8q`e=%fRCQgno;>^6`WEO8$
zro1>QGP@sVuS|tk&EnI_#a=nFC$g2c=mK$)L4v<uKu`UBy*-d|KtMQsq8O2(n@4wK
zy%L!Wz|uXZ%)|}pD~Ld?bz&kSWw$hciyV!2&hkz>%*N~CRB0r2gQSPiuQbx)ywi?^
zNz9D>pApm}a!uhT*<~M+%G;I;ae2Eo(+YalZfx_DeIAkqDq~?c(KW=#->&WAKEiYl
ze~q!e_-~Z0gHHdYout~QY-rk#*gf)7oc~OYkrToL>W7E-RDLJ&(|B}<->z{hA(?>7
z)$JR&t;LsH+?MF+*-Y$8+=NM7ueiT2hi<FBGapxgS8#u4yzCm-b;;F~PM6pg_bvKs
z>VNUfk|_U5zum~czg>*Wzj6KDdvRvQI4QM9yjgrczZz$+Ok6z>Zx%m3i#Id!xt@PZ
z5jdlLG5RvDePd}mB>Y#2bK-H4<X^I<HnQ-m<LjK5%Xr3hd@b%vT_X9N?s9Ype@H&}
zLJ+%=^Cy_s*5ebG&t3aflJ0UFx^T_K6Rv99QWkx<dr@b*Uy93D4eV{@0D}5VGc-4b
zC@Ou#eiD~Te+j4j?kXFp>uM`^*|&%+T=U?4XE@&G9qH>9;J$>N=C6b!VHjT52bVma
zc-$iCAbH$K8ybJBzdn_z>LN)a=@+ZfSf9w?C|klX4#+JpGxx}tSKQA79}q@Id>F~a
zs)<u$Ik7AGxTyT$yu=URMEO|Cy^)V+UNQ2qcR6`Q>em_ZW^r}1i<tyP*_#k=uWS-#
zae3Rtp0i%p)9N8{G3p-4Q;$iLyu?}R+jY)#ll&_E4at8=)wl9aecq|S?+q@ixTtiH
zJR6Of%(_Xs8}7$o_a^3popvSPBvm)N=9O&HVdUzG{AJA`2>wpk*Qofbc9C?b9V}x2
z8&kVtSJJ^#{%~F{`6fYrO(+9BzsUTn^ey9MqnBqfmp-ClUYxKKP1RT6o5x|nLBRoj
z43z@oLShY)<s%7##NQ#ZWm0Pp&ztqMQ~6NlBVQ+9d1sCDor+g=`AV8dANY^nx#)c7
zbC-9FdL*fI6o1^2^HjoC@mhR3K6d(Jq@$#Z(O*fGPhzHNGq@#Fj^=)jj4apX{kU|Y
z9ig3a_ElQR+&lIpeVkPQPpXJ&T@#fPqn|5%(9z0G>E~8fd4E*gvpxqRcH+${k_S_J
z42-i=Nxc*QTt=0lgmx-mM=uwy^Y0R0qwYNGjBjDuGpXweLW%FrSK`}>Wdu2YA|S4B
zrs^RT(**w|$cwK2N`6U)e=E7AJnqxuqVmiAKS+Cd=M;Ab-l=^fJ{_gs;aVPD%U5&R
zsLb^)cWQ2#Bat@Yj(T6EV@q2E-)&c|b!#-Y_4LD9QdfdFxwZ%5r_sMT>-19~^*`B9
zJA*7^<NG(Q68CRh%CM`y%0DR+k|t-JWwg6=inzpF;x6WDyy!G{jenFhK3uM0DL~)T
zax*R;6PB7Z6FpUjOSk*Fbx{3`7HNAVJTiV%<578ApHd>OdYI%l36sCeZ?555Y7w6_
z?R##?uwQYXARcSpQ1db}9w1z`{ktVf7iV>eZM|IWbB-Uy4H;v}yq(ehM5=X2HGafp
zy<O=QZ&p^!q@2W?RZ`F0;_T?<G5)zsIpdvpvx;$LE8$$fUf(93o07aALz*nKP}k$w
zZz{eLHodJ#s()kTE3ZQ0JAEi;-?Jn9ARBFPg0w_tbwm7&wUZM1E9!rD{&ys*hg`=^
zQ*Ws<C3CNFZSyB_X7S^uc(eF%)0jAWMt?H3N4#15xGCODm!*-nMNTR&1xMK>uwrhs
z%_<)`&81y3=H3naEXMS<S;NCZ`s&9^arU8KH(U`nBtMATYI4H)gQUSq3v*@2b0mI!
zqU5LBf8F@YHSg|prh{vlx<w9ij~`=5-hE|^k(@Gq8+RmL0csE&U&h5;<Y1UfcnrOV
z5b0=g$*@Z58>%<0AaS-l)yue*Z%!~JYm2hVq%ZTdGSg{|h_nR-$6!^pS4oG>qUs-`
zyl22or_zM8<7!uHWKsvo9H>>Q&%nmYk2njs?<%{4&ag_GA@#A0{q_;JozA+^8lkjU
z5>!aio?<PjONCF|H_Av+Pu-fU`|tAhnuPAh6_Vt*ZH$}OINe@>7b52++?f#e8kP4`
z=+oa!cNq)55)yGgY1!&^snIUG)*WIdGEGg7)^$v8gd?P|xU8RjBQlgKUOH-BZ|mu8
zO!9{^4`D2%{#iVYa2VqWabL=hYTJ>Ya#L3)Qs$B%NzIE=9lbIy>YDyX-Vv8s;Bodd
zEHD%CoRB!|GCAwA2J95Q{&M{PD*cVHyUNfAyYvfO!!C9u>=MuLpdh=PnkROpFDQ0(
zdFwN%GQTS6kRdJ|5-x_zd(yv`_oBk1Shm$?l*QZ_BLszqvks>JAm&oPh<*B;PE&ns
zCw*QqmxU9lpCU-(gUCwyM_ZL_^l-keKP@sg`mVEz@)8$Kqw32Yhbf4|&R-Me4?X^<
zip6IWm0w-k4BaL5e*#%2l}{x6$&t0>k)-mD^qHlucAX<I=D6d_Lc%nV^prYY!V@Wn
zyW)n7l_lN8OiaX%$X%YJoOYy6lQa@Dj!kt<4wWAyUFA157ZR7QZXVy0CV|NJ1N_;i
z<f*62AN5=1ooT!?l6P9%QEja9L+0kmey@x@UDI++aV&79b<@+*4W=h8=iN;*E$MB=
zC#ID7O8V=G|4)#XuIu3<D=G7mmWkI#l1g7mOEGsXOOlSV-kDg(Li%nJ-^A%Fb6>A3
zW3FY;?$lj#%>fc#k-db$HT{k9Y^1;B5wT;Wzq}`FMPe2j-rH*Lr?0(9pF_-&$`eM}
zO`Ip@k+w0UljMm(_x?P6rF_dfD|tuqMB3lt-;sRxXL-Vy4ByPV>9{}V&O)A8!=XVk
zHZ|&hXZen_$%M4CA&@*l(j;{y$P=!0sgWn7JOnW4m+(pXQSR^`8#~pauWNphd?EG|
z*9Vd}#N0K%NWMs_KCob(xIU0NRMK0*r}}?HOa?<nJ`uOYT*X*leN(}b-z85dzv)LM
z{@t~Wigi|i(#%TxDqWVe$T#9aLixHDw&b?2uam2*?1;iEvXgj=Op}sRQuU_9#~9o1
zD=7}@V_%6+5pGq7yb>RmjDnqiHBLrek^E!C$u*uy<q?Ue#3!kEN<K-PA0(dMhCVXu
zx^hKuOSuT)zGGosLB+F%Qr>dy4~d;5t_0;k@{17<$@5Y-idj;5Ug9X>)9VMBRnpsr
ze<a;RR?>F4<`ePP$h%49TchvWxwHgM*DaHD&c&Ud@c25%0Ri3BC@7$NPpgRL57Jlf
z_ZxH05+`ddeT*vcSI<rS>{9NGv{n6oz3Z>~`$n30QEucaO&>(Y==tD&FT(Ut%2Exh
zEha)vzeROG4-eI1+=aK=yhP(w*ZJj+k5s)W<5e}5m-*!m@n&&jSQj%D8nM?b-kt=D
zcqA~Zl!O_f*5fPrCUN>0`NFv-!YDw`>5`u%9{*~-5O<{gk+#~k-jlYZE9w52(Dlck
zNF`T2-~G{?sJv4GX-Hj=TbG6Elf<=uG8gRBUzRfFTF$yEiK+7yRhmx24POt+opPtf
zE8`yvzZ;jxVrQZ>bzS>P_c$(1o$^lYkv85;`7Cob@n-s*&GWeQ)aPvCpY^;U@5Gz^
z<8wCUkX2`VuS)pWyU0sqENSZ(5Eab;KoxpJUPk>pP32B?{-$bAWKpjS?!`LGWpG&U
z@SZknAHOJjc$gK%iSRI6c+j7hPifO6FGg`wjzr^(y&U=h{}`z@TJoj(U7h+*`H!~Y
zbA0=q=r<)_qphhxyyD%}-;ugm%!8uC0z`exRfksUXZ2em-C7Ig(x-Cm_lX}erW14d
z7C~fhlw-I=c1C?xqMVrM;g|X>l3VJtu7=#~0p0mZq@1?#Z>!H@onewOw}gr5Xe}%o
zb1f>5)<`gzN^bip?TJy=L@q`ho46gpT9WM|-v42{*i{y=xJEkb;3)W=7iHE6vv}?@
z)=pdp$0jPTu66L*CvoLfNk;0?HSuO~b+C(>%41@0alE~_`rE}Ut`2rFQ+Zd~oWynT
z>*OYOjXEt}#%>-L32h1FG8nl;>h+7N|Nf}Xly^Gw&UoHQuZKNuY?;)&t<eVFQBu&f
zxx6QlAImLm;1T6U4bhlQ&_B2EyKzaH%RpXqwB=oy<2LF`sna_CZpdF>2kH>_Z0Nhv
zCdQdnQ1jc(;+~}*q}_{qmRd=l6OT75ui}_k-mZP2|I0Q{#zRT9d4Z(EP2{TDFFpKm
z>8HkTNwi-^z2YSmFxO|?60hal2T6|z<&LDstNmb=4%ka{sWeF{KZ=>rCvfdQDtGuV
zss5u;juV%AsdJOtAC_|Pe>FZb<mc|AOQ9JM`8DER_a^m;uFGrfZC9GBK~{Twy)5=#
zz4U&jA-@W^VXdjFw7TXmr&%rM&{O3{k)z1Oiq2T5Uz9Qv`MLH(MHV8v2>MLc8j;-^
zvur705dWl)t@^Pob;T3c{>>?8{3M%5xXW`d%FZ069>2KQVXXSl|JQMocu07YiieB~
zBvMwFc*ysl9uwX%C#5}&%T21Owqv&tzl*+DNDes{-l{JTs7-Bgs-?tBw-e!NM;+>~
z+*99_l5!U1`nx^}8b3tAv*NfT_F`P^1w==p%n;==2$x{RxjDeqZm3_(>+H#4-*MsB
zck?mz&R&hMfWG3M#8dnp{;EAyBt@%Q!j~00-*d;i<qTgU1t<BA7Gl%JDEF8tj?mYe
z^l63&)cZN!ir?>X&*Rqj!D`xJ{!T|_Kz5Zgy4BS;t$s#)43xaw555HlK&jIP!V+*0
zl!nj&o4_GZ%H43-0giy;=SV1V9SuK(A3$kuK7y;^c=#op0QbU4P{Jv0>-%H%eX|ly
zic8#?^q*iaJ<n5NHaHzhzip=TeUXR0zg0iOU*2bmQWHCJ&2hdz7rw#sJeT+My{Y>C
zv#S&$*Y_3^W$9lnff?aaDB;aX-$mbF%KmL$koPQ@XTn^rs8ss*y`v#Pk@K=0R4ZBx
zEC&0*>aaho0SCeQa3~Ch!(k*G2@k+=@H;pWiXWdqcQ_rs2WP^%a5kI^7s2_EeVvY2
zxC&l`YhmG(>b!49Dfl_hz2R0E19!lA@N2jb?uBdMw{SB&0J9R`<1iaM30uK4Q1;!P
zg(9E!-1`1j{TzOg5C7uMir;}8<(a(Tko>q4G7Tx~?<${t4P}h88&-ql6^AeU2CDo*
zT=c!6%!}Z!xG!m40&}_Aq|x(lTPU50c2L~w06Rm@V0TF2>;e}+D_jS=!VS<L5*950
z5(do%V_^{d1@i4D#|_v6=ElzuSQUoCY7#amdpx4x2e3Ds4P)SKI1s**l71g-54AV$
zINo<Y2SNwtL2ww9^ceyB!;x?}91XvOW8h&p79NG;;4g3j^hPdIU`;p`)`Qca$Zri{
z(D#LEn(P-9`IW_dA?9*5b<^d?K3rA)TR?BjTf&O4H*603!f@CRGIcHIwmSyH!Ehy%
zc!^x)c^e!8&%&YbXE++>z|W81J8%s2hZ7**_s~9ue78cI4Eg?r_6f{D{N}(+a6a^d
z%iuV;0#1diU>f4f`S^}>a1-nTzk)$<H{@My58MX#!hP@?_#He5GpAx7FDw9$!jkZN
zSRS5)wcro14m=Gh>)ILUfal={Fcwl)wV&ZMh#IM5A4K)faSWn5=C}n>2Xj1us319>
zLY8tJsYw@>X&kbT_a2mVlX_0y7n^i_wSuf8^%b&L_0=jU@5RWwsr3C64*r((mU=0K
zTdo}`oaGS~<oPQo<>hNw6Yhrf;9h8joVlRt`)^?=&--C-co0fHI06U2qfmvLG|~5k
zQf82^_+N|PJu#Qd8++ccER_BZ-=A>E?-gJ}SP4pd;{)44>O4nJi2lAq;!qQQ3MIcS
zb3U(!jWFK~8^iNZzH##cHivHHr`AyFjCPPPXdNJaXy~*!d|@Zp0Cs`At96BbkUZ)b
z0&S4*rO19R$2`~_E`~keXRs&S07Kw*7zUB876}hS#=s6)AMFjLp6&y$!x(rU_JuEC
zKbRI-^@kpC02E!>fzSd8i>l9u!S{F`4y(gaumL2Dj<#?Nl=?-!<q`qM!@f|y5hL{q
zWz8`XPJ!d$G&loJhYR5hxC+X*Xf{Im7LC+Hv*A8C2TDDJEF7mH^@-ySTm;`B-Iv0W
za5=0BSHOl4SvlIkwXi*02PNO!;nw$cqF;a<B;TNRsa@oji#Abx3*``O$@5{@86JWD
zkp7hVCdvsY_0%aS{gWS|<j*s3C_D?t!*g&dB(FGT!dSQf{sLuuhQE%_;bpi3UV-1h
zs}R4n>kvOQ+6G4~ya{<%y9K4axDD?^;^jz1e8fB>{0+)JR(@0Qu7n+Z-=w}?BJrkL
zi0cnM!d@DlpTMl}DJ%@1L6Mu(6Z)RU`1TjEYM$J3t#Q7;7W(o`oYZ>}{H^avWKPT}
z?~IrQa?4eX_Cx%u4)ephQ2eb2rCc_EBIibMDQpb$;!YD-5H^F-PBw>D*aAv;ucjnS
z&iYCA;z@ivVty8LxpJq}+oQa&B+vO_V^|1EdV4~t2k6^4?64@5I`3WRfF<B$NT0_s
z1(tzFpwt%(Pt<cP^ue68)v7>A7s`_3T}W9{^+PQv-^8f{sVlU4kg}*Xgo9ucNEy(Y
zL8%X#!}YKgJO*3CbC9yA`eU6Tanoq~9mQZ*SQFBwIdD@8fFoca90hG~3hV|q!0u4W
zUohMYL!q2K5e|QZlyOHa<Rib18?X<Q{pIxa9KXYUFf$p0zJ=pWH~{8`17Tk1fTiIO
zSRM|AQf@znjo>8M4iY9uS4i9Ih=kMNJUAP!gLB~5a2}*B)#gLmN^K#e&C`}Zrn9wW
zFgF>UI>zA*S3@7T7S@96U}Lx*wt>_^j;?SMoCCMQ&)_z=5h5E0eOhf7JP5ynhu|Lg
z0wOa<dh*-1Fe^L&3&4Z0AUq6Pz$35|JPrfl2^axS!bpg$9sS^0I0Bx7<KcNY4Uz^9
z*<1QEl>9z{Ti>s!?_-qw{sv~lx#gm6Q0-xAScT`b&=+Qa&0!`e?J#wQ!w)hRQ29SA
z4C6UFlzQ$hDD@oU6~_vg3rc%PnRM)e)TwHGVSy5^SZ;l9p}yx(!j%g%>QQz5lu8d*
zEUb#jFR(7W1f`w60$anYuoJuk1L0jb3f_Zb;eEIWK7^~_V|WnK_fh4N?+7`L@%$2=
zhAC6)^=T@Yg7T9NO8cD=5;rX~tOT<_sb4%`LzoS=fjM9V%n1$o>wEt6y?}}3-xzz|
z_}c`^{9H3Aa%&Ey-fs!_!B$Y}{WkClYzH61_E5ql^-F#z&z`UYlzwhUSPpi9^kFnB
zlyJ4@*7v{Z`{E>A{EHhmt)afm%JVuX_3!6U<h=<-LB2QT7zDS%5pV|-xqk`8eJ^f(
zf1BR_6Za{0nkTnh0mz$dss+Lf&<2h7^u23IzjvJQ%X{BLdGCZXJ|Y8sPa1nz_*?w5
z@H_ceU6c_e=Lt~Syos;|oCNE^$x!n9C$KG?3MJo9hc-9^O1(b|O1(b^4uo@|l%@G_
z5?lbKU-&7Ma<B;Qf{WqTa4Dn@p)G?);0kyiu7t6WHc7P$Yv5g;*FoA~Z9Pm$T=?FW
zBOTlb--MfBZnzm1h1(!~TkT6opH|xmMXtWw`o1uIznI8J<XDbdF6tCDPVNu0@H_xY
z`VWFWa4<B|N8i__>xm>z*B;oD{z4cm0K=W{o#JnOua&+BOWw<gnUqDjE@00aUW8H(
zF2ham3j7jYgWtj%@Mm}n{t9oy=kQnf65fS*i1%->GJF92;6q4XRC@&Ji^|zaj%o0B
zxCg#~-@p{)-^<Vq-hip$BbWxJq#a8O-C+hO{o+he<g$}n-@~NuZIbw9$7}<)T)D89
z9_EHpPVzwNTrDr8FRkSlb65b*g$1GX;|swv&=Wp@g`tF}2z(BU!k4f(lyJQZv%``w
z7c2$o!)RX63zmV>?t8;VupE@}e|aeJXwR+h`O)_RNj&%$S1-)Mo}|-kDE0CjSPRaB
z&ES041ulf$;Sx9+E`^5s`W_qNLbwyVzXyBb-(D!?Y9E{h_ro*r5Tx&{9f6YGN1^oh
zjzMwXms{WKqVItb_g(Y(H>9&X?}L&)-@@GR04xR%Lc<+>|BB3c>)~{Dr#tnP<nv%C
z<)sJA0eeDmF9aIy=zC9+cBdNl#GUF;-0_9tP7NsT)P&+r1h>9dL~kP{UatM+M%eSl
z4t*AtE={1MOEcICHivCsODOGRYd8<Kg;HO&gI~ao@GICEioa{P_5BuVY^l=gP0SW@
z%Vj}c;%{MC85V_7e-?vh;k)nxED0HdXr<tN=mn+RdP8Yn%R(s+<)MsEDnR-WS|up`
zVjox@R)N)ERoEC-hwWfZ$XHsd1tr|R-1`26q~(4Jdm{HAp~(F-6uF;)BKNaU+^NK^
z?<>&Db51f%D$Gi7%XO4$P24#KGr{A~1AY(XeJ^fZ*FWj@YzFouU(JNlo{`t%-qUsX
zlYVcC^Sw`;?@e{Sr}7DtI*3A(_9t;ZS;Ty_gm*EN@GgN8-W4z(Tm^mL8rT7@h0?#`
zJLzhi^995&Z3|oiw?ZSHx<0<Hr!W4x@w+FtTz4s-63=^3+J)bo<#ir^>$>pRCD8Jo
zgl96hT#>ksk!FX|Z;gU)!DuMq?G43`KJZ;A>j)CA!BE-}2iyW>9pO7T6rO^^pybOD
zQ2KeYp5OsT!F*8G6)aHJ6(oN1xOIJUUC%smIG+(83FmV-5x#&qcwggv$+sz?FH8lS
zz|^oUOant<Iye%hhs>R58Q=t%2`+}2A#)X47Pt?-0gpg;cpQ2_2`Bw?r>-<!lK>J<
zkvIK(b$Me?!dVeYzOM{R!z!>md=J)u)nI*C1Ga{>U@uq~PJs0wc~+|r7r;jFOV|`j
zf2JkuhM%qAE!YOid}=$$m|5!p%fe337j}jXU>C?(RI@_HfLd2L68ghgFaR!vfp7=3
zLB>{EH+Tnjhm!GnK+zrV2}LfdTqu2E`bs>DTwLqV$=DOQOo1YgsZjF$G-!h};Akl8
zK;z&n_%W3A9?GyL>pkn>eE2zB0L5P^|GFM6btHd_zXU6;T;#@{l#4v@ZJ5{Py?IKH
zGk#vi^}TnT?-hYXc(17QJ!!vn{ZBp4;-AE;F}GYVQt0ud&!FbpQ!q}ffO#6&;{UPt
z9bi!&UE8Z@>;??R63dF%8!A{373>8S6*~$Di=vd3T@;N4yD@68#BMZ3V^=J(Ycx?~
ztXN{~5_@m4#`fR$Je6fp-sH{oecyjE*EM@~XV1(zbLPyMGv%2FFdJYe!0dqGfM_$}
z_vQjr>LZ=6l-9>+5A}RqlI_wTfQ69%wrrOuJLwFhbT*QFQU3-bGGOj6#t}C_&eN&^
zt_O4n+zE&^0WmJs0{j)fJpo~B4Rrv|0@ejg2CN6j{#+mMW55Q0^p6_@vR^j=WIZS+
z>HMB_9>P{me*v!=a9#m=0lo%o2$&h;Vl?1KfWrW@0Zs(O)tB)z0doVgd~d{LWClsT
zhg$51vYp)#8MrRR-&~ja46r?*5s>>x97nm2#Bzcd<#Md}PI>15WS?YsBFp<JAock<
zAp84YfRzDX12zME2iO%5vWaJ3fISfVei(Drc9qU_N%q24PwxYd{5}Ar-F+zM6YVOW
zC!+nbZC6~kCFF?fN8{HbUm?KFfS&>W1Xu)+?O6=)2w+J-+Nx53oZplIYy(&hurpwJ
zz%W4Uk%)a8H$bdy8>#|QUcC{eb4JqnBl5#>H2{&}0rZ&d3R@xMj5R9Ju73iyK>AZa
zKfq^zw0F+|+0IzQ68p?=0NLJe0ZEUtl+Mve=W9q$Z&$G9CG1LGK>7@hfNVP_z#f2D
z3lsB5XTXv8ogZ*4U_rpI0I^0U#xo<}a{Mj<NV>HUrSm87@%SBsy52824*vzL7)}6I
z2mBqdB_RDC=5K~5o$tUHfbYytzks^VP#pGz`CS0nPfG$;0CWYU{7M0O0MZUY2MtM3
z;%WsA2BX8OUh50jnSA8OuRi`harY4a`r~dr9kgf3;XFULoVE4nwR@;kPk}coew6ds
z$HV&v77HBv`H7VSGM_9sa^n1j)~v<$ejhhy^bYVR@CG#NFsshmJkw?#oj7~$>PpTr
zugZ?88Gp)o^v$!sbgkGY6l)Ix?|yXkf(K8{OI(=i)xDsH+44lqS=%^o<DGvD+`1&;
zdQlHF<|Bdk<(tBBhuk)v@EUjJS>ekoLwg@d4zjenKQTw&#WlON@-BjUz;GEI#_#)m
z`PR4HJbQHh^E-2l_nD1nCoaksw|#P_0}~b;&AuDL?j!Jq^xKr&_Se0Yk4)cv<EtC9
zw!L<^vCeq#i<{#<AN+0JM~i^BMBqL2s<X0ccsJ+vdtI~ND)Qh?yN#ny9?p_^<GWWr
zN9IkhPzgS$z?-!C`L;r%pN_ie<{#3$q5JC&%YTcUdF>lZlQLd+SH38WPMo_i`RiFE
zbGxNWs}A>=vS(S3f}WKJUF-2`$LHfuk6ANhT))??pu|lCUh!hJjt*LJzrnW04m<DX
zntQRfOG86wqaDZZHSHMb;osl|*6m^NjSgRI+BNp&-YwNO<UR4tzHH|Txpli<{Kr*$
zKfCjGVXep>-JlrTMR_kAgN_d^IwvUX(8K00E9QEc`OL7>t$OZ!J=nozUdXi_Kf|{Z
zc)7DTslUBz$)#f|cMAWeirWR}!*w?-%HeSJ^|IRKJ58&!8af1>F*<x0uYCvNxyH9^
z_?gex!b`sG`McM=Q<1CcJs&mWq|>D`L+gk1Do`KFI8T)KWz8x3d***$qv2bpR!dI~
z`}SDu-QSNls$9%a;mfI`ey?30b3B39GroP>=KDVD({b&i96M_icRlI8<oiRrzbNLE
zRK9QB_^a*EAD|0Hhoeic^o-o<)O*&9)2~l;>;CG=_6HM_=ly>5=J5XWnjJGO#8@Nn
zLiUwhTINyaAKPY{{q3_&jaHo;c{uEzYh31Ab-HiwGw4!2^bvu#adp1XPM4a!t3ILs
z*x*OiZp6Isn0}*Bro@xwBepot>41UywZJp4aw=`8<8Srad~BZE^@$tLzixTy$C3`t
z9yQj6UEf-KD#kDvVxxoeNz>A2nIG5o_3!X(SiTt@U$^U4devOFStp*IX?Wn3UpA}}
z3B02|rq{a~PV7)QqSDAL-~5oPaQu^lLqFedJ~zJHtr>Th-NBfIiLTM1&YuVUM>cFa
zen*`fWx6Nd^xgPJaN|X89j1A8u6lX>@;+nWLkqmd*%l}7c~Z2{(meSaj;vpJUP77A
zf9~Jtvodj`wq>bvx#eQ)<qEtly;crtF|uv1Zu^RVJEmKqNjp6|g?d!1Z5lA^(0%_$
zpWcGq!hmITaM}1#;-VZqzb;eZ!1dQ2UTyNv&wc6FT!DpW_p4Clo!<{=H&20AxpJAd
z-QG5F^?2%Hbh)<X{HVnr=cqq+)#V|Z*BrQQthfpGSl|uM{<eOOSwWfF)Ht^8Y=f>N
zN8CDH`=a}RJ0Cq7UUv3JqxZvi6L`snpKjbQH?`1%;=LR13qJC)&2Z<lH-B5Ovts%A
z5y7__CSmVS;7!==e0Ns2JL9{z`M7mhxoTs+8y#kTF@N;9xmAYGdf{+nF6v=qJ?@oV
zy3F*X$EyPF<t}XgZe*S0Z4(MD9kjl~h$U6)4PQGI<y8`RudD+Tauk^m)%x^?qZ{%b
zYrX13Y}5QTvNir@-o@udLhrpp`wG1KziqL+TI=)h*!lX~AKy9>x&QglvWGq`G51W4
z7h5~OUU3TJoWScmrAwZj%OVpB^gXq`*EHX+Uk;tr>-z#%zB%(M?$8^Lt9dY|6?i4`
z72Wh}t&g65exgBM!}n9mhE%DO_l-y7SGmfUaUFeb{1WJW3D#riWY6l}_or6xvgDhi
zdzV`F*LXE&^t=wGo)2ku`kUhmUxi@Y5O~*KWPV(B(bY9)*JYp9>Xuha&udBT?i62A
z>8qf#*-GxccN%jzfp_upurm3!+^D!@ymvEqOM8c7eb1HHzufb}$|dIxxP&z>hq*v`
z(*5Y*3QxaJK6-PeKp(@>dfm2EUiAAIuQy>K9jqQ@j?TKb4{NHTyp=D0?hs}5yw&_(
z$NOs<bY3^&=+bH@w$yOzwYJN5oz@<k4ZRoTeVgmYCcV}#KU*tj-}p<T>(AeD-fQ3F
z1D$Hksne^=qe9p6V@*kvccaFley@kVc>B|l^HWM5y5Duf^R90{X%fDEO^a7Ou8oNF
z!J4BeZ^<8qo(+vllk?R|*lYOmpv&;xWxSRg>9+RxjF)5I>>RiN{a2LN`s%0aj<;@n
zbnl6PYwMd;-`LXq&FtD=4-WgiLyl)BHouI4Z{x!H-oA0m>2jCM_X|H8wX{psQj44A
zjqr54|7w1v<~hnatsOT2b0vW{`p_r$%w?zN`u*kL$uGa0KB8NbC!4p|>T|D3`95<F
z?evE8FjwGZ+w0_U_U4YB3I2u+&yO|iedojvpCxtJ>d|t~0RPv^le%E-OW=(^n*7Um
zo~^oGE>*u@ua_0_#!S3D=0&wHj@<ff<eqK?x<$bk5_r#&ri_Xo;WDq6@l}(~o?mzC
z@}>2OON%y(s&{;29bNi2I0fZPvL20geD*`Z8*W>3B{zQ3qN&H2Z?ZrCt;ObmawE(G
zvgdpKE*^6_f%jX?<oq43hZeYP-I(pnlD-eFd(R)*ckH8|1|PoDWL@*Q&Y1fPykGik
zUK~=mTD`=z^X|7idu;FX?rXg&J(=w?c|h3P)7|Q$Jq`)HwnI*DubJ=EjM)bc-PwF(
z&4xM^yA{a!SKSMBCzdMq`JP_h@OfRy-|jA5?u3+2d_1JW!8*Myhs#=a{1%oF?mcg6
z)XS;o*Y1Y1Q%B$}nQ#8C;@J7WbQ%@Wpt)hx@OJClcPQHILAH(sYL%Ffu;z@x&`*q)
z%iKS!@a@vyZ`BN%nyY!wCWALcE<4id)Z{;0-i2ID=$Pfc!LUh`H)6-3xE(9<*DLR{
zq<pO)<7d^EZ@e05>^JSe!>Og8d|nRz(0PFu8+!j)_jlPJd=lu^-ucGt1qa8CAGpjg
z#6PxVgI|aASb+L|T#EImdcNPgCG%qI4fa@3<@=xd%;-6+?XN?dUpV%wA(!9Q@7JOp
z^#tC)zAmNXXC!3%V$_yG{*{JLxZ#s<+$opS{HZ@J`FUK0?$<Ck7I-(mEc2=Jr40w-
zkD6l#y=&0T=ks!-^UsTU-16&|m%msS2<L8rz-!{$tZ{>m$%R8F4Y+dR>40As?=ZCA
zJ?PVIF(+I`&1qqY##)-d%f4f7xqw^m&K@Y(A>YFF1vi+>B$nv3VTxk|w+H)6yjoZX
zdu63r55s=zmf_#JR=#@Yr(%6>^$GudxjC%Th};ietvGsn^c;t)m>UVaf(P1V`LxsI
zk=tv`%{i$<7w2;Uu>-Poo7$y7{e9aTcj*v>wHtxAZB6q--9~zr8SU44_l4m2%nL7X
z{bT>Y2Zb-R9kHkCH*1GstxDj{-+t=;#IPd|;^Q8Dx^d69vHchSw8UZ2=g)4=&)RE7
zS33DO1>WQ2$)k$Ydt0U8up15wp7uO+-T%Od>l55-%uI~hH*C&=+VGLfupaAj?Jn8R
zDaZJ{<{?wJMH;?v8uR&?nsW;cNVrn+bj^Wgj7R<gZ$#yb^RD;#yp~te$|G5h6v%Y9
z+0}XF+HD!>GOuc$;UyhD#+sDCbMw!;zWeflzbrmDGwU?BOU?3*`JwrynVFlGow#&i
zeBlci%hw9L?#X8p4#WqP+g!Rv((XLvhdRz1c5F%MF2fIQT;;U+$Su_2j=)Q7m*v^;
zRz*J_yrkTQqCQiSt`2Z{)N|L`6D}{O{W#rkO$g>*Wm%88LEBG`9rfVWkvmD9OnW+%
zy}0nV!mZ*im{%pOzGldhACt6p0<T%gp69b?cIbCMck%h*wHCa-8?&oj*{17je$?Rh
zmN(IFF(Dcy@H&riAG>Rb(}A3S<~#c8>brg4f8Xn)k^x)3?J@Ptsp*f+UT6=2H?jXG
zflo4d?>p5Z$1%$vWuhN!=~HP-wmMzcMVHFmwED|gnBxk(pRP^rbuDVhg6n6W1+@Hn
zOx&d=KHsc3^KIU-^%sBl)$ro5rzJ3k7#)iLuxL!^o<ftS^&32S;pn{6tp_{{kF0w(
z+T+QxcVTYThGMQQ@Gfk4v1r4R^?BMn>QdY1>6C#%5&buw>3ql6?d~t<7Zk;Mj$ydK
zTk2J1e!d&aaxFWvC-j=()#tfu7TW%7<HtG1))*J_+14YF^D2RNu<&@(cRte-++2@t
zPOMt#-m{$^jscFtYrTGEj%nu6^eN_I0<YMzg;&Z)Kc2a2V3y$Azc`jXuxxEi?b)5?
zF3XuO&u4}2!cWX1#+ks5<`>z`9uH!74a_mZ`%aZz*DCG`3O+UB-GF6PYE&CM6Y~^-
zw>+w_G5=3{>OYKpclN7KzRS8e`?RlqT{&g=)>3^-4KLSlKGrk^Ub!ZdJLek|yJqb1
zyuIIe?Z5ddpQUl~tz`qIEDbKTcWe8fu!aO%ZgemmN(z7L?onvT-H&D-TGKV!VcerN
z1#^8pXGFh*3NyVD(H@-y-j2oDj<u=mow=^N@0NxK&y0T@d2`XQIv)qF3~yyD)vxd)
zti=kvudJ8-zX+Q4-MH4_v2R@0H?P&Ct+(mPkkVn7+8@5%c=K({j|5(>CTmO+ZYLl5
z?OFRtVJq_wtF$wucDA^K)0V9)SliUwe*@O$1zz{yq>Yx=4@XvX`>2`WX3}T%^Bte(
zx_|ACZ0qk{*;Ib28{~(Hw$Y*Jt;5CtTzmD%vcaanAuEFlgde*(q{!6uZ68I}Z+ka?
z_)V-03A`*>J=V?+D&0Ep`i$a(*LwZvy0gHF`^(24E^)O@_aSd5Vhpqhyk$qT?;Mrw
z+v$!zuD`9i>^8~Ry6K5h6%Lm_p6BBdHAmI$iTS_4yVcI;K(C&o-~M!LMZXuff1I}F
z(xKQd+nn56_F{Oq5uLki#GD#)J)=Y1n{NFUEjTo{h*OWgk4J3uEVh1evzi6JZ940x
zNY6D@9>ZVr6?o0pmYunw!qN8EUc8FEey(u$`mYAfuie`3QuVgUBU-iivH|>4fw$?9
zHS3qPzMSNgZGA$Mi*2rqSiWw+!_sfZUyYivxZmh+mtzg8GU;CHYk9D8-SYKadKR0p
zw8)4}m-;>Jw0h5kRcmU$O`c<cPh;>Fczw3^zrF2l&!K0}EnZR1t<^VGp4^%Dt?AA1
zWjO*y7x(5~%V2?b`uR78y=ST{^yq!~*U)iG9%cJsME;5!ySuFnE1juO(X!XES1s`7
zKEL(HuRjC~_9!;?UDugcdTxAou5FR(IabVl(zj>g*(0dOU4d6*L(-rUllFKG^w>~!
zZE%y<AJ;8+vd*z7kIHq)TD0e$i5Po}S7AM7y&3+piI3mY@Q|Okty%u{%Q_<myA)|q
z^ZJ!pOM4h@&xd{PBJg$>?3`5EFy`9#MIP>|<Wc?3-N@GaKJh9zeaM#+-j1mHBmw<H
z;9ZRi?q9xT+l9U7j-NGfeBq(Jt9P&@dyO9I-!>-k>%IHYcXtcC8vy~AT)oW~j%?jO
zCC|x2(|@j;x5S%Q`(2yts@dG{)~K=ATNZe8qIL}1w7$xX+kL%mL=P@~Z(7)hBCf%&
z`k4p)ba`4twgB{B=&I2n`Q<l(4GT30DRtq;7Llz>mYZ~MPWF!;G`|<|^{RPyZ{!()
zvsMDH#+xi#Yc4<P?Yp`1yDi_1asMIntmtgBGnH6<yY1wsPh4MNPfp<78g==j;cx2R
z@cN@g;=I^--P){icz&u+Tu`NjE2p@xYlZQg_vaZMW^OFM_f><*(~A_k`*ioZ>pmN5
zzRY6uf3!Gi$D2HN`rZ8&&ka>2-nJK>wU3{!-k|uqS1*#+#k(wa489%wy!mUt7lXoX
zPFPYG^Iw5C!DC*fcVD#fkFIy*_}ghAmllm^`EK9-Uy2?6>i)yZLsyr;d{E%cC|W36
zliCMseA045w*CjJ3?JP7U{ZJMm+hK-)u~XmZHJm;%}wAn+0xPD`6KI_$l6u=#>{V$
zcT?uX9l2MuG!%NXKZjq{-JfG^y&Cx&Y|VGcugb>TwR2DZ{nr;+7cO)Pn)CJMHyf;3
zy`O(^X3r6<p9;J)calOLy4F4Ba<_WIr@_Zo7iiyQ)wWFY^9&E%lKJ|x0`NB`3cOdI
zs~=Qr+1+p?XP-X`WIq4%?u(|saylMZzM*>G87Edf!MuCBz^nD{%Pl(x|21!5aK&{^
zU%#t4`1Yd8ox+kve;yyZv`FmC^Qecw`}t|RhmZRkR?RAWa`XCmE?G8qYw`MFK94L9
z>&4}7^6;S}=7U(EGdg%4@TxjL(<<l1yIbFz_~)A3t79j%e)4+$(f+3jR4$zNuOZkQ
z5qM*FhvfWm$ew!x;~wuhxAIBBXWL);ZfSCPz`+>50l7}18yOY~yrh1PH=fU&egFCW
z--iTtZd332$B&P6-d?z7D|7zB1vh*jinTz2H?m;1umP_Y_P;vq-p{j_?=HS$&b}fG
zPxRgR<@rO$gYMqK{3EYB`I}ZLSNxqJ1*2|xyuSI7@8QF@J)5tebI9RoyX>2O9$I$B
zK+FdPUNMVr(bA=E6k6mzD5_29pm7u9TUC7f^uFil{Z$J!C_48M_V5JW3m0qYg;}3o
zs@CJKi>1+msny*&&i`>xkmZLZ_l${~I;_E7ioo+4dv4O5^Orw!`hI(kM!#LUmiO?N
z2eQ|x-_7J-rr5AtzhM4$Uf|tq^h-=c154!dMvd2pv^}5c@|;8WhjhAa{A$3n!i#=d
zI~n?nH6rN!m72zvcfY!LI{S)gkDNAF@1ASn8<!@FSFP||Q8BrL!x`8=f%oBcxX%Ti
z@tc8fwyn?6&ziT(y0euc##|npcV1G3`*XLKute{0Exiikg23zJc<Z5Gw=W_+B4<YS
zDl&D>u*4u^zN;Zs+dTg<sbKjrSYtRV@b;gd?K)%o>YNFq?l>7AcMMt_`^(n@XSfw<
zlWEu<--NIHQI8s|NAKgKCK^^(FI#1uY23%d!yf-|KIrhE(&tRBev3D>YINTTdmaLB
zaDCJKnd=`}$5(B6%IBlbbu)!dt)A>NC#+<JHlgcZbjuApF7TEnKQk1GYw3CB?FQfA
zGkrVnwS?`ljI6kH-R<tlod;|%<Lr^ZbLcSWox`c(E4DA%zj(FlvIoJwC0<62Zqdtg
z%!!7Po+CHnERVoz`sa-D`JApSURiDJSE~z;Xq7nj{E)ppkF~pXXvLgz!&X1UnZcT@
z$KpJBpB}vx8PdY%{_Gjnxz7DeFH8}a?sb1!=O^Fs=XeudGl4hdQNcIyq37OpYq8_w
z#?kvG%!v6hWJcS1BSO0DIx&55+1J<;7I-d2=f&(;>D)SEcDch#bA7dL@$*x=c8}lr
zsO!}3zmzDK`!4(qf%jXDS9QDWzF%T;Zs%;fx-DqG((Ag%jqwSWy>k3Ep!3sLNzf~S
z_bS(6-+gP0N6yzhpLxfH-){w6>~S$5pv8kFMsxY{u^k3sO}`fFQR>*-`Lm`>_PFtA
z{e%GpW}bVJY4uQp-^BTzo!rmP@c15bX)N$QynbpCc&|q;8*<^>WmiTH%DMHE;-z98
z2i?6_@xtYNE4RFOxp;AH*uVJ#Z==gP-yKUEd}|3G`{#stcl`QaEBvrvNcINbmf5*u
za+YjSIEx_g?j${(6_#z{?Uglt`}%&132wiHZL3^j+#egh>$x)e{Ln+N8#yp$Vji&b
z;G~bP_Ze7z-&+5wJ{PVBZP{D0hpTVyeK`-DSZO$i`9ed1m;J)K(Rbq?Rmk7F=C&hk
zrcaB1yWmRs>}M|y-reWO!R%9x;q0%#+n4u~p~GH`9`U@g-&<=!n@$$LN-p!`O156=
zxvliLXE#^lEP}u*lh8ULM=k5ze2b3V@LBU)Xrb|)7B+R=ec?pJ2{#wlOYpNV3A}f6
z?oYb5Y5DNm&u14~k$372xBi)K4yhBrq`vFS)^oou5{x|*PuAn>N(YOLdse1Zo7>B`
zHLL9unP=$ue(inR4w*OUO!+2RhAqarx4^5`Y1R0rUY&F7Y}LKMy^r5~*}QSl`ek;%
zu?~B4C3(rx{3Ee(Ch+#Pp7=64>#&R4vsicZ54i97$B-*6Dir_q*o-cg5|58vZHhB|
z0<ZR@CojqjDt4~()gnDcRKI!thPAQF)=4wxCA6M8t8gjbewbehyqMn|eMgOIlEu>g
zhH0_SAMq6$JN~ky`RE&GX1HZ}5>#a+>VUbj(IJ2THyiS<D|P9q`xob`{8riLmu;?(
zu9vvFETH1B7BQbrn~Srf0`FGQA@^Ik92hmJs^g-)fz|$)JaNCN>C}c_^tn5GWBdDU
z(T^qwyhpx~bH`n`zV;1v^s2Vk?7u1Bx|K^N-!I?uW)Gjh+DouzyIbJZFFy4CU&qZ;
z#x~zSyS#DQp`ZU8S8na;-7}sYv5vfbysR(I-U+<uiObIQ{<clip(Ao-&2jv*M~$}*
zDOD@E)x>PYT8wQFSoM3%FTGd~^B<KT?DZbDe&@gvr_U#yf7<2I@!Qk-_#`HlZFGNd
zotXUS=K`;BwjY}>$Wk+Ra)Dll=AU>y`pA_k0}qc&NR0Sx#l);z8fC{kS>Qcf+HU1e
zf5)y1XMff=$H>fs_uSq8^<&S1CB6>!eslkeMHmxS2)rAAJt^>K(xppp+77RCxSQ+U
zYv)GS^&a=f!B2~<8&+|T^LU&w6nG!r4=4y<$LP>wa(t2d1=hxXH{(#pci9JK8+r2e
zx&6OYxv|X}eCV$lvqxjTFYumB3;V8M?1>gp0h#~Ibo#SFagPJGH2w3`_1pc*ukW~_
z;v}r23%qvoj`Z6z{rAruTaF$ZVLE;4deK4mDt*&3bay7_$!|JFquo{ryjO8UPDDO0
z)z<HaEH%U8#trk?n{;lK<Lgq{8rS>$c7q)87(WEw;Ni74)XO~9HTjKmoy&8*FLvwb
z_g(S}OUJPC1J11~*ef6Uc|F#nWu7{_Yu#Qk@z)F9Kd#O3^zEX9#}BNTa>~>9S<Xr4
zU*(04W`qn0WJn-G0vQs>kU)k6{%=bl3)t^!$b?xT&Q5v;L|X#z0_}jfS~YNkNI+zG
zR9{m}lqn(r7pGeSV(}SZi3te^Hk-v)D_+dlD<Ce?%1q1<UcFY00E;yy#5^$2QW=SO
z_mG!UrXU`7{lrk%aMhe$g{{IvVxle4VOC?=cIAw1%+~P8@Iffg*f2WMjGNPVU$LuG
zU||1{z+fvV^^D~U%0ER~Z&QRBw?^wyc}B_ADcBkT8q5Rkq&K+W9<nIBxm3Ean>ZG0
zD9(MkI&}(<3XL9M!C6CBrzU)Xi@3Z*D#r)=d+*2bbsAm}`)TrfM@KnOdhnkB;f5Nr
z0#>hzFF4f3_rFI+M&g1vYluaN#fz7<!PA2Oi#uo=@k{EE;=P`{4=5Bb-VKkEnB;wT
zxtRw(pt!OO?>v(4QL-?Z_xj*3aW9Z1IyNT6B;A9^J91)?9^4=As|&`9O7Wfd3q6$Y
z)X~upZ?jYGQ1T%iQI7PIJKnX(XWT+FV=n|{WEb_6XuR*8HO#XBdEizXR?B%<7v60}
zzIerr^d`?h<*FzH?;}#^okZTxfp=R+k9V3`k!J6GH>8Jib%NgM!fXr5T)HPaJ@gtO
zFSZ8_&N!6Fyp#v;e0v|gc;smh+(bDK>FxPI{aDA!^4+bj?2rhbA!bD^gt!oMpyYx=
zmz2IGbO(Rg3*sCed8ID?H*|;mJw{pMNKKYKb$vn3lxKAtU`kAy4FSIZgl@;1Ah;%g
zeE~5Q7H2cDlp8+)zgqy}d3&Bg7SAZR2Hb()et^zs>$ZSX0U=LuW*bXf@$6e20LhOV
zq9hkdUN5jWhrbQ3hzyw0#8ZaoKH|)=GvE{a?hN7nPtBb&&O-j*JPY|hb;dE{>|(~*
z#f-Cy|98(WruR%@de0hWoFV*YX9yEJagDP?`vxn{ulP2rpJS#UX1l~}ZPVmg%MtUF
z@~^vAxKp&tcVGYSKWq5^%NfG-o`L)S<*Z?P&&oXzdb*|dx(c_FHqDy-V9@+4zdWzE
z+x<ZPsmG3<4O<d$dQH(KoBrp{F4pYKel*ZA(=YMnU-wNN+2HKGz=TTg8vRmY)0P_N
z1|5kQd!@EF<_G`V&n{-1Nz6Etm~kdC<4j`4nZ%4Ui5X`SGtMMtoJpi#mvJUB<4hv;
zAmdD8#+gLwLB^THj5CSUgAboc<i1-*$dEvW1TrL$A%P4DWJn-G0vQs>kU)k6G9-{8
zfeZ;`NZ@~$1bE!Ig?#@1Zy)!MFhz;O{wRy*{dorWBej}&#kv2ihLq?1TLt6vztP8H
zF-77adW^u1G1PT3gbWBZq?-}Emfa*jwqT8pj<5vu4+&@%ZLxO7V+eSLAs{lMa^ud8
z4R~h3P`R@DbOPB8wnPe=%DL-3ICsqOr33`@z!`o=Ttth%aPAtp@Lyi}T=hg8GR9eT
z)Ge!15fvveGTagz5#B4x6bjr=@t?Q!Ut}=O=to3Hn^`>HHEog7dk(ak0;|huLv(4?
z<g~H6G(J+mypwflJOizq&yEM9GQVm)a0LwC@g@QuzmMma`haYAZ$KQ;F!%uSd4k4(
zc>#G|+X;~8wQ+WucfyKyBJkWc&!zL+c2Pi{+a`UU(<Z;|0P$$NIIoRIvUwM=xFeb8
zwfVq9M?lar;Ao3@XAh2$h&zb80=7hYH^5ea0f21)y91(ZLk~cl0XGB!B99>m5P1y2
zfJig+1jKhk2q2=N7ho7*Z@@l);eZi<_%7ZRi0|UAV`zYQXARm_ygM)&Z~*Z70S*F$
zR*HAoSODYk+X^@wus`4^K;VkIzvBSM<M%*7o-g-9j1%W$MxQ;i>}Zj=aWxx%+-dyG
zKNnuk@<;xI!D~MDJAeBJj~4z9PzHozbl6aAZsxc*Gy8QdR`_)FK?SoOp0TGzr&8Z%
z-#zW()0~#;n^0gz$dEvW1TrL$A%P4DWJn-G0vQs>kU)k6G9>U1CBS)LnD+dCuv^uD
zzyZ-QeFHoKECJ1<tfrVqQ)qaw)r6_FG{uex@7X^jCN>Js>zgX`iS+&^b4+xfz`&Xw
zwQE;*uT{M&ZvzMw^KU#?9~BHV-UJ}64P-J(cL5YNw2RG*Cvzp3a&5rgT>#3n`!0OG
zze7}vDHxB@W91;wVge_)q98ETWW{6cAS0gL4{T_T#=K3s51?7FCD5mlZ=hvBuvv#E
z?iXlpjfsxx6&M{8DpnyxnqP2?H9R;%N#tDsF`y7_wipC`-cS%61KPU0fnmWB5j}%L
z`r;l}@~GedQ7cPBN`W)L6x>%LrXhfL-c1nLN&QdMD<(Lq7p_5&{%elr35<;Hj|ch5
zqf%$_y@9D$I3~8@d*ev66_Zo(y?yu~pzHEeC|s)$at-Ni3h8SK4eTl9R`N%MB8!|~
zpko~(1-^+GqWpGJR_VJ)meLyqTRBJ1XUOd|&jokz7vQtny-lQD7-{WXF<-yUwG3-?
zUsII7d_4j9%Iy@2|89!^s7%sdO!q-LUmlp*5M#B5OX<as-W2IeMSAn7(C`>jh&4Pq
zsx`8LK52#E|I^}szZg?kc%1wfWP%6Cb>Tz5KQj0_Whsbf?B!?ovt*GnbN-(Lu?1qI
zl9=D06wmHAA{|dp0lcbWL4@}|@OgPVL9D0n9*5VsJ0KIvu=Wn8I)g{)xqfjc1Ag;4
z|J;C$ffE=Q79A5AEcyWNOyK<m2Jlo0pn>2)%CFo5!4)m89WmCE>##wtLv`e#G%6uF
zLte=jMIFq%yrOk<DC(hpRqG;WMUE69MO~awmfgBoV?^Cp7p$`w$Q$eCi0`&_BfpBw
z<FZP$^fI3XS$LmHE%R#sWtq>mBlFD=f)zYb<~;=uAC`HjyjaS$C+ZE>pA5Ar^UG<=
zT&WA?WheY&ncJ%y-u=t>lZkhX{UvzQ>Sjj0xgN^4$!qB0l=TXE&nn)7rEf31k4^-A
zdj&v_iFW#k+kd&ey4z{5-lz}WT_xJ<csl!tv)pO*?d65`3KDhBq;?E_A5rS^Z?%`b
zx>cmC!7J8b4TA)4X}8yCoA&B2+k?|`UF)C>>ZS+cWXSR1Z$dY5osOqxH16(+jtY+O
zijA^}wQpl!V0e_ZhI_sD{g(>6;`?P}RCSv6s~>n!><H~7+2o571KWl7>J0-zotv)I
zfs7-RK%_{xhFuNq6)*KKQHMY}9jpYdo{7S^9vfl}>=|q^rQ#BGN<VJu+#oINKDvvY
zpw*FfKSEbW^*$Hy9T*6wBAB;-YxZB%T}rRY^c3~a$rS0n6xP2yVm*|TXt(~n1t{(6
zSFD;s03SrQCjpLo>8XFOH0!S)=cMtE_4f+&iRontq#B9(D`Q$*E+im)fk;&tiTEk&
ze@Q<^;8H8ND_&xF<_K3$v{QQetA2b|+Nlcoi82k4wUPa<htqyRFRS4U{$u+zk@eFk
z6Vdbc8Td;|PK&?x)?jO_MdDJ@r@zbR5j%X|6m&H{6*=y*!)F%o=_mOHvVSAXQE?Px
z8~%6s%Z&1E<=9)$)A(y3%P}+$8Wuq>$3n>OZBLG7T|*-eb@K1>SilaCozswE7H+U1
z=z07Y`Hl8;Q5{MCnJ(tB!(S~MUG$V?xLM{eM<%JS@EzQ5pd)VQ^|}}u?Z@^No}VPU
zB2u+%KU3IjeLqRz$J+7z*k3{g&8&tUpwHjC<lk9QANC)G=ZKFbvbH>XU$DnBJ*R(<
zXRDy8@th?8w&mGK#}>hs=b%6A@hnW5(9wTG&eH@<jpv8*Z-r;YPA!mm=2+{1NVnA;
zZDH1pBe2W^f@4DMnSH@Ove*emao?RXj*mop)07iY-_8Y{q^umyNS}Pn2X2Do>x*%m
z_u+{f_9}X)?JVW8{gh}b_Ie&^>gG>+x(RmZehqv#yL4*^!n7y06s6xO=}xsncZA#*
zee+2<J_X>o&7YCLH|l(^^!p<JiQgjik1P^-n@_E+Y<(2UY>do%?oXs_JSRZjd5>Lh
z@NTfn`v=_!J@X$#1{I-e>EU1RW03!zGXG0u{`IoAfPZft|9{W#O+RmXAD6r-<D9EA
zYiKZF2}Q`3tWLq2%0s*?8TU;FHp8k)D{=2-jHhRVi0F{MG5}tBeXp-jp5kAVb~RZp
z&iPRYLX<o{^ajiYx%j#0?Uoo@|CYT{Y(Nf_$<-dxVjtz$Y)0gQB=5nD#^DU!T?se&
zog31_ErIY_qe8G!8H%6C<KR>la&iQ}c$c+dw%|{i|J+3$W&MQX&=dT|ltHXHu&(<0
zCdl>m!T;1_&V%w&kJG5HeVvoe$GmSnCpXHppjbWa+*Ce<(ukyOM05h)f)e&+ZJ&0^
zIfcD3nD2dzfz<T0$H}xQThiv7!4b5R{v+BSt~c8>1W`}hnTn0D8j=3`Qp7Bv9pq}i
z-j4X+PEdUh+9`YWK8SjoQE&PdBShI*4Ua%a&r5>L%VZEBFFYTX9XPv6+UJF1lAZ8D
zUOqyZ7J1&P^tIPA?Gh-EZ9rR^4|wMPs14F?e|<f-V;z&>G9vBCam385XDR#jEQ|l`
zgyGeYnA6}X)-6AUB&qYfqt%}LNhc~cQs7(x4s|W8y>xnx{gU^>z5@?jS7JHm@ssOJ
z<_1VW(DUD$0}R4KL}3pB9gx>C4gOt;oI2R$pLFf<kKzUY3a_s)Kr6f^+u>F5SI^75
z>h1SB6t+O}C)A0FyjIL<-h1u#I`E;`mQ^T6Z?~1Xn}1=cvU-{?p#N^wMEkZgnIpns
zJfksUXy1_~z2gPn39F~uN4^{Rg-n-gF4SStZv!69(t2M|hp0xTkmwkRaxarr{$&c~
zVtE-)&!B4f@Q=a1N;^|XY>WkKG`7Ff&135{WV3<HA>bUJ;4ud9D(aJbSjZ*?i@G1_
zrn^xm8@3Z|1jipyM||fv#_{bk@XSq3R%}0^@)+rmMts^g{ACEm;Zok(Oug?akH^jA
z2?3{VlrMeboirGdFCeXLwT_O$1={_&r4<?*896Y}I?#+2{6M?u?{9OxuI&IFeVZ%#
zeMshsV+MI*U;7cV-zDj{vNGW5seB{5>0A@qscS=J4rxaIklvC#Q1qSeKxgQNNW0wu
z@lWJ6o)&GY&Hk}St9CfxkdO4(@W(nnlr|OPiM*M_Hd5sAMCPR~%BMVPBA!Qn$FmYI
z!Qsl5iu_IH1E$VSNNLZ{+Tnw1PZ6dtE6>J~H|iGCVz@MlMDi9T_s_Y-BoZ|L<c+SS
zA8-@?N&g(0vcr<X``TBpQ?`9n84H^gXDJ2)WypDFZN%o_GubF)7>x_zX+w-yEBas?
zDtZ%(GAuagtN52qQJ#Jd$aMBS`i4=_7<9s<gX)wi*PtEHKrtpuY=k^+D|=G=WnOC`
zA7xq%u^h@aR}s7lb>qso#B$yD$mYZTliqJs=r=QhAcEd+EDidJ{{nrz@2Jq<ZxrMW
zZUC%5?Ev2ep8OxvPpRwn#$bKlSLk=9{X>|A$i6=nu`K92x}`1u|8(t7(ILGLSx1zw
z`H%`fr)7SqZ<GhlnH$QmJ>J8Q{l5QUebD=niY*M{;DHc=Nc!Co-yqGgx{!x9-fK$P
zjW}ud*_3>|L|Mu>K)Fzs>@yrsX=^&lW7R{M4=$&W4=&e^ha8g9J*SpCc~3m+fxKz+
zmvW6_5NIg;k)L)lKZB9Z&<m0LP(GuP7W5zTL;ZdqFYN!c8JvgM&gm8V_C)5TB5-Nn
z=wH`Enp@Qr_N@Yv1ugsfD)kqo4HVnJ-?U@;zN*lT;NXnFeSXp{hZsy5`~$k8PokXn
z(Y-3u)z^0!=qCIFx{B`GqpS4AIBv`%)Ig+dpp9~+>?_!_4He!a>y&-K8D%IsW-EWT
zJ=YlO00*lv;(!MAP~j;z4K;$Er;@<+{ug*sbl^igEs%MluR=LhMRWmA@&5u(iVgn|
zPwr*F1cF{pCBW0Je}N~(u78N9{dRaVf+s`8|Gqvc`kfX}ioN%z@gNI`v}<h2MX<d_
zY25%P-td|o-*8MYf+IAOFX_7daYwQ%q)Qw2ozC7fjkbvPJ~}MSVv>C!#rM4_^D+hh
zQ;#Mf(ihrgUp{p2M4zL*vJ=#G6#8G8P>#OO(QnsmUJs{CmDmPZ4az=-!qZF|IRrgV
z^pDJy?Y5c96U(;~RGugsdps$9j%$*4A&+UGPZ#lkpeNZ$)<<by+6G32--;Yy5aJOj
zLq3~Ef6Ds<GGx2h2_NKF>5p6&8!l)_dqaAjcF8;?f&h71jz}LXNXR^sjgMPFmEqsz
zN$HQ|=|{O;m9;uWPL0Iq2p=B2Q181S($8}IK)c%4`IPqEUc2hsOX+*LD}pG(I7G^2
z1mbJ-m-y7{EXo8x2#5ZIGjQ#M6z!#7XW=+Qoz&}BGsxftVh^N$D`-l-2iLr%`6(ty
z2y9Era=E}k`+`S(`zFZsXa`)@!xxc##L=z~KUi(wf7(aLgE}tKDM8?J0(}$CQR{;T
zKgo_M@-w=)7y~2lA7yBtzGS}?d5N`u-JUc3a^)<fvd5Ar)AquD)FqBNvmhhK;=)Fx
z++%5|92w%SMEZTf87NP&U$mp-JpgM_W}gVS3EJE}4;*H5lNb{>Lnt3b*J@QJHS{?|
zwow4$9O|0U4v&rGV?AJza>@<d)FGvv*YlUxP}}LGC>MS^_>tP_W4iK&?J^(ShIc@u
zU;h^ElzdL`(cIDz&qRkd55-CChB!4K=mW)G5W23kldwa;;#uE2C@=8^=_)hsl=@n+
zid0++0P0E;#G7odV}b|WvYn@AhxS-;gfP>VgVgsGKCZK!qWg+ED|_K?bchh5V8|)^
zK7a>+XXurh9$o;4!{{a~ZAM^akH^d;+BnW&CunWJHe%nl42<l_2@lsJ6hAUlR~XYz
zzLEB@fZN>Cp;1E?%=FDjCtD%C&89Z;_{?;URn&W~1UBRXv%q(7a)TTL+|VB~VVvs2
zx=7{RMF#q>*50vEef^OM>EhjOayq=)2zV9f3H^B>pH&p{;+V%Wi$Gq_b7C(pLRThu
zW10Q2aMLK<!sZq{`^)LUp?zX4R_Wb+>>pMIzb9VaXNnWJqtrCBRVjq^n=7ZYf643$
ze7@^W*g>T=&>x8JE91wQtg$gsQV!}kZR8njI?#`>wUL`;9pG3_8^LAd;;2t@d7%UH
z7#P|UOS+QJh5xB@cAK3;1pZfiEd6|fXXbrTZW0#H9mEcUBwIxnU6~P~3?j=0s$m}*
zJ@KgEBZcmVM*D<>m@Jm|W>ZLbShy+1@;;s<U8EdZ$aCgtGObcFEiP@4mY;oEG-N{K
zeev8vEZ)Qj^!La>qo>r(P@OrX^SP{>LeKaCdaa<-%9vnZ-Wn~%e+ZIk*~-zJWKWKb
zLoDb(X}70VzGAQUq)~pN{qoVF%od*dPY(@6UT*F}T;e>lUS1E6*sDVm?3lB&wi8+p
zQt6_ljFB_bpp{^kR;%_cO#|_0Q7Fm$M|8xYW8|@I7e~8tYlRy{Ofl@i>8+2_KA|4u
z%wW)uW7KVLyL7nF-zF+zpi~zrr|qYv14{cOr9oqXeHzi~sM(ND=A@67;y(q^X+fZ2
z6=M`&Z5W4L(i)3mpQN*V`0qpGp<<it`NGOrO?!D>ly7IwAoF9}j=SvYi=Q>7hI_j7
zM3HSpE><AemY-}_w(aN;g$wnkF+{%f^fN_Q5@cFsk&pe%6_L6UZ`UsQ%cGDbT{M*b
z^&+kMq(LJldVr$#>7t|5C4d_h2)26fXIE|{k$$~b>as_sVLNUF*=_p{7~f-LFD-rT
zqR?r?jUj}gi1Y(FSKi4!+%dKN!*;VzXej(iOPesD37I+aOX?uTX8H-7r_*OKMTJC%
z!r>t*$47;}ucwr`2^=TVZvaU83wGP5AJZ$A4vud)4u4SpDoWXHKULp=^ElEE7C9t;
zfjnW^#Sj)A!y_c{XB?cGK@QEp%WC}2_Y-MLz7_pG;snR^!ozWJqC~ob(@Eer0zOQP
zp@WQ1|CeVl1U($bWc}%Xa{d$@5!zJV>J;^-3>cNZcvqH#LuN@1?_@b7{P<ouq|jg5
z6gxp~3kN4Z(71_cMA^~1v^w(ah0L=MF2@0dKc$@_>PRI|1z<aUg~)dD>y!q6F~I{R
z&*{ITCs{bLM7V@V`sWZyKhZyJ`fYml!Ly7KeIxMg1XWMz=i2Hi+Yia&oK2JoPkHjq
z)WIqBH;b6b8w}IYZX7eF0CHaAhzHwnwlIY+$^H`qxv<g53-$N39j4GiDqrfHCKlVD
zaz^TFcFF^^m!K`n30l&*2t{9`q8s6PV?1AksWwS4&nV=1jmW+>Ue2TFsMP)%a~!)i
z%QC?pv7oHz1filAqvZPE1r4^#O+>bf+hn`-Z-7UHLiP1`1HPT0)?aBCK3f#ZIS7#T
z{l>Y0l-ms9Q~rcP{!7!MA0EO-YxO(?K^}I3;2|&O68tY<Ez9HDqx9R$=66M#-${un
z@yFTx?rrniOa9IK%DS%>d0l;5*AUj3X?3+Uck;uuH>*^<>Pp&HEltcki07@Qc?fTc
zY0g@jTHei-N_ie?c}KN0wY<?<nwZhCyxMA-yUKG;ElrHf#5=b_q2VsP8>X$)(p3J2
zXlW{ct+h0jzv5b&%HPA~Dh-vt-CCMZInte?rd1cCEz?4@G?hPhEluSmua>6Ly}3-G
zTV17bUQMf}%4Lq0rqZ3DrKz$C)6&%XHrCQqy2Z6LwZ1Qf{u`h})l^<isA*MIx~sG_
zwZ3DuG*REYkjorR|HQbKmR%YLd*FyZ`79gkl2i`tTrQ_)uq8$)sVUBir^fiie5h4f
zN1?4@Keyt4bHn~3nP<Ed-vNC;MW-eHbGbaF7}~cYKG@FyZ69>hixR(rSH6Ru_RT^Y
zDi6Xe<FuR}(qFO$EMq3h$c{3?z{?A{4B{rqxWTd!*4sjUSA0WhB?)Wl;DPq23*c=R
zgJIWk>PD*ZpkXt=#)2b`1xDbf4$@da9&UmM{n<Fmh-;u`IMmUxR&%VjY@(i#qf8@%
z<K#UoQ&cZ&Z}A^xYjBj-xmpFs^o9E<E;>-ggIMGX!@=<gUvZ72SZ7iE1Z72${tm|*
z;wsOdvmIBWzFa?(%9YLw&pN^SYtJ_;<HyQ|$c*qQq64BcBFB%UU+l{Z%Vw${MwtQK
zPSEC&$~sJ3V+pNlW@(%vBpt)FH0jtb&x!Fm)DATyr5G!UOlO(eSn=>{={N1mT<JUd
zrPc?BYH4cU57N@qe%U}vQ|+XymL~ctX*g(Us@=FO>PdT0Rka(twKUakEYQ+~-C*Az
zrl!@#_?Ojbvs!*F;a4Q04Xuzb?*#o+!WI2a(G9M3Dt(=O%n`U|#L>WSq{CNyb>b`I
zv%a4xzH*~xQX@FaV?N<Av}Mp-yKTwgUb)yp6idB1#0E+oQnX{xVy)d?e<Qxro~mth
zQA<<Xqm!1V%JlF&C2v(VZxby|v=RHAJ)6pYPbEK!`t`*!E?H(8`w7>&HQSZTsUXtW
z-?@g{BqCVMwOoMfiasgq-ymGF;ujHX5z<gsG(}s{p0dGvHn;eNM`0}i-`Q4!(N5lw
zcTO0ZaYDY5pQ+f+NK0c{bo!aN97N)cHh?xEG+Z+Av{O&z^206daED0SSnP0cHC522
zT_N9LSPjSBG_fc~*eH$}<SE?Zn<@`&A?u{0FZjLN1afI=FmQmIFY`-zO_1>w+eN)%
z{fPep_&&gIJzr_>Tu%P)!S{kZro!gl(cw=6{`Y7PvphbKrZRp(4nptj>2jj1%bZ@(
zf2M*6`?rL=q#7^m>N49sb<k{}IyN<zuxdf~Ny{DZFnCT7_R20TwZBwMO@Jw?pHAJi
zw@;w#zlgC{?$ne+6WEap?XuHO1_qjX_YRH<#kIz+^)W|+m(K(4(vfy=-3-dxyP;2g
zpN?W3&fB|lS2EB7<s>QP#6}H37YV~6ZG_4CpOxhbMN{m{+?FiaV8C%dajp!Hx`;N3
zm(Ks`IP&zg<(K(rUlRC54#;kh>gp)u#pgXDpf4Qr*f;*f_x8|bYl>t0y#Fb?6Vu;I
z(9<(8Frr$jGyc@=^Jwpr*x+jiI=ck#QvckXhHevoChA_?0lu5N)E8)%l)fhIt4R(N
z`KC|Ae%oIdY;JV5H_=<5?sFZ4|HX!eh(z*p8oY#}d|#yZl*=b>VjBDqe;V)~1HXia
z);G_~_?8fCY2!bAzf%1Q5<v*eEcs#G0QW%G6I<KwSIT6WdDwo7_$75nq3@Dy3Y6~f
z04`+()`ZRKjVrXw;<hBF=XRoPNCu7rEClaRV$qbz0@QCQc;$1=JKJb=+<<Z>pzRfV
zMO<ItEkeAFyccx1>|;PR^bd{@wo@+;MW>s!B1MDY8$|Z~*@(0==Dlgi!(tA$hV=Hw
zx)+Zq37KFBuoq;RI5;JOw??4T9#|_yxsoo>4stxeYMXEa6#kU9N|brC^#K#@`+(f~
zj0g@fiH*+m_<#zX*R3V?{h<qR84QG!LA;o|r?P*I8@BJDE)|f@I4QgBr>MWOF0g&Q
z(uP@`ib~(<bGb7UeY3yTiT|0V`ewgtX{v9wR!dX;h%dD?s-E!0Oln$fVM~;8*@WFT
zm3cusmlORfwq=-fjhE2B4Uqi{$fY6luY^>V=)a2HmQmF{ri>*)ZODP-uftp*k0eXu
z6ubIFS*r6K=1Uz?k5^_t32Os*qs|hty}Z+)foJ2?@v2d30!Wc)C~b9ms?=7>@6GaW
zwo{<=o&KJXHPapoy26K6{k@}Fn%bU+wKTOomuqRFJ?Te}Rnuw<+oAZsY&&_HD&*c;
zIe*<&s#F8$E#*-U@D%k|_^GM&SDtFy^%+E^Qp-r_GHr5h{C5InD?TS}n<LUrA}uV1
zk0|+~)GJ%RlYZd){Z0obE7~{?^?Ho9-L3lDlJ7*D5!Eg@sxP2oGZcH~-42Ne(-A3)
zDTrd-&%Vu|lNy8BtlA~mpGBuczLY`Ik+l4ArYmdwwr5J%XKZ~S?(Y>BJZa}4lsasn
zp+wk>x_<(=9B?n>>)6(AA8Ha2jiUikz5JqaSrqfJ4hj5{It-`c>7Og*c+EBy?S%E`
zKtB21D>`N%(m1v>f;<z!PcnW_7xX3D9gjNMjzcGbyArs+0C$ZJmwv@u3`BUQQ#|=Y
zJ(`I${n$iW93ZTSbbZgr`N>}baD9*#8Xe1<DwW|(w7rsVshqE3JE`xoJys&0H}Zv1
zKyo%kUlgdU18nyPBEls&WgG)=<VxsG;#T`ImpA-V%^!24t?Yyp{((4)q+7SAJQTYc
zCeI1T{~qwqexg5nLtM_E*<QdE<0f(0r)+hM=^NxS^yhJ?dmcMkFHQH9vCy@H#J%m9
z`_O*>X&Q@5N?OPAq=2M%cIu8K&4w#yM3%~Q>f_&>h}eEI6h>VW%L#eQd+P8pe1qW~
z@U&ZMUjt1f2dR8THu^I^Ja2bHl!^X?^4accT{}wIY4h0T6%mgEXTceb2knL^;nS<!
zu#egIdo*6?-z3THM@povjFWR^+D=H%hL{KOXW$xt7qpcpI#Ut_4(V$3MuHkNy3~)|
zY0!1<BxR@sz&e*hd=A`Qsh{UeA^h~#_h}k*x65=xL67Ynh?orAWZP#qQ&5%a%kf1C
zTHUq!QqC83bh-YBq<3ay;`6N3fgIutrKAJ=T|@U<-!AT*B}&x*D4)uNuFy-VUDTVT
zY#S!M^2vs>*q=#7uZweKy0-Iu$9+N{Y^Qp@rZ_xi9?^skI18O{W`U`KBqKeYB3&e;
zi2xiQzd)q#w9Ed!zH|sk-mqmI^=%=QBtBL9#<rl%vfbBL?CcYn{&i%de3KDpgMLDB
zQO}g;fuRdv0E1DdaBFYvxzP{tq1b_x=WeAnarzF@v#JhGM(~o1I0b1t1bu0)#yTW`
zCv$7l0CDXL{-+GZ8AgGZ)i4SFGfk=2OtI>KyYqm{deuN=z5G5{FRakZRb#z47TXD`
z|3%*3S1;;zyj&NafhLcN&3P^J7!Lw$`@x88d$*tM>R9V&Q(TD2ES;yYZ|e+#uM~3V
zhC&fuBa+4oM4snK>|&pW7&_X7rP!4IkQ~IA4?5ErQND9mmd$>yjg6t<k)rP8O|kch
zK|o^2CAAUZZt#{+$1ZPe<Ohq@`AH+YW4qMHl(|CZCJHaoesCk3-&Y%_{6Ep=x1Y^#
zclkHx8Jil3yqqJ7O+%)AuS=_isxi%1m*yd-t!}90tuCkCZ=j}Ctu3eR(WP<Ck>!om
z(%h7^dp>GjH>JFNx-{BP<{hJ^)g}p%w$fY4TbtcPq_x%3$g)TqSzpByb0d~FR7>Nq
zE%5%Tr{LA12t-<vmPVFE+8i}a+dprkrKx#KXlZKRzv?P9YN-63QPVusyz{j*HE*1j
zrq;KgnpRz{TMI2st(%jVLbs}#_p#7dG2e7&-RS4hZZH$(VE(2^tb<rhxa&fio4H}o
zG>5e_1&1ns;ZivHL=SBxeMkC}SR)k&ndoyXc3gQlM45LIU)k@oMw&%3)3}$)GW6?u
zbJ0HoFwk>7S*{1hDs6w&Dl@8a!*-I^{dhJ?DqXT+?DH&d0?KO&I&!-S{K25jF-KVw
zW1m;>w*#LICbzx7x4sAeF7P`7U)D!~@B1G7B0;zV9r&_N3;bR0!S@9|`KcrIDS;pH
z9{j<;-v)fSuL}Il@4;UQ{JFrF`@6sou!Bz-Df3PDU}QkJiAbA$6;b#EovC}N)(^xy
z6NiqXCFel$(TvDrCw$N^P;B!anTKL1!~wAg;(3l6_Wd7)2XSJG<AojCNK$OGwuctd
zU+OQ+U^@@f%cOHpsYF|Tl0L|fILak_vi~+uNug4SW6+=3PJ~?BNSa~4onpcxgJTA&
zOB;fxAp1;-c2dT$*K>r;!FVc-VM#W>C)oUslYi4b_mIA0jMC1!v{BQvvo5u?G}U$%
z)Y4Sj`C_(W|Ej6>Z<LnCp$9q+x>_2C9+76$(o`FpG)pN@+h-rIrKxm-wKSEkr<SIU
z0n2Bq<*78Hv^1Jz$T6!^F*U8G_?<=lT|>3sw)&{pX4*DwKi9!20J=F7y5NPfWm=*P
z#V+X2vnaNZc@7~@J>-$)BJw24w!t=!zAsGUW(vahnI*kj2zb^7`|3Zi?y2pAHKv^@
zOjA3dcg>_CY(G`|!12po{n<~&*ksZ6o=>743E&AYJ~8wcJV?HuGG^iIPb%N<YM4ZN
zD8?f8ok4)7QHSL9@2P{lFG>62DrL9*6#TQD6#lh#((a1T?{N~>8Kv0n+jH$u>=RpK
z#A*k}ubHUhVDKFQ{2CjCo(X%dtOqM=MM@hJKN0xNfxk$`r*CjxZsYK%DD|wUK2I|8
za4q$Lj)t-x#mgY=t+P((g$xKrMA~cGNy_t~eftQ7FvVa_Xp%+xU$c+)<e5TuG5=>!
z_6icw?i||^?az7I**?s`wigCUDn|b)>#l=S0%VZ@I-OAVYf-M`$8a4c7CDstEw<?k
z;7$N;PT<zsBeg00EoCniK8*4-1s=V!ppQB@xdMM2;$oCFM9#x@WgD^lC>)+^XS0V!
z889m2t8=)-I(;X$S7Su(@q63f<Ch*}(&@jHJJn~3{%gDbNczg$^J*U{@0hI8+>4Oy
zkkG_#|HCs2+F5A(^Db%bsf<xKTS~H2ekaMlIX3**Lj1=uNgXe~Z?2?OQ*C)OEzO<W
zGVdSFR6KQDnWv=*`%b)VO%*)JPiLE=dBmP?SZf>-Z@^7_v1Kayu+qPjy=t~|L9~$-
za_R}%GF`EEHwxu&42Z&F54K-JOtLdh`6~I6k*@%BO0Jj4r|6U^j+YXKTNR-)PaN>i
zBYpu|JEVGx@qlaQq$T*$(XrL1P#OgUU(lpIZ3f8pH2P8wsm26BI#e!?eJY5VQwLR_
z6y9z5P<+-Tnf^eOLHg_mr0-^bA78o+Q(a|{eAeu#=`%&}!1^j{JKi+F2(;VmJNXbv
z%g?^8Ymdip@q}iIM|eMI??_L1-Yi+B*A8@YAo?N}L7T*v7qZpX#^tABDNl}*se|PI
z(niu2rCb-+&WK`PMy#FWMgcrC%C}8%9qCs=&tTXB+Is#rL`sxK0Fb}Ih(&?(P^_~n
zcUEBWPRAe1P96Sp{^$$f+^W#~tB}(I@M1(-9hq0fF0vjmCcZ9Qdbo)EbN$X$;H5rq
z>WA|w4D96D5Gx{{K%J7#Xfn6i3y^Ck=@Q7<2`THR-wWVc74?sN+LJ%|RrX4*%Dj;$
z@>Uvg4|wyovsa)nMV&|wPrFf$vL2lto)mjNI2ueK)JLQaaB=4ab>Os+mv$GVSSVMx
zl4O-0UC{3%q=zp>R?W;{1c7#qe2ql>1AO_NllW5ah}6_m^i3o1Qiqi7XS>JnzV@RY
z(jT?eL-wojf)}Y@iGHU0t#9}9a$PEbF}8at#GI~>vAw+rU0+L2yJtf=|4F+mc6VGq
zNlJNSyU+7U$*_gq2ZelX_bDW<8fy>vQ7?^B5w@Sg?kc|YMU-iK#(;faf3GBQxprl{
z_M_NQuNa90b(1pTK<`5NNxGnFKr>SWmU=(jkJHjau2o4kQ}X%w+alkK!ZCw<E9c;8
zhxt1s7z24Y-zF&8R>e<SB=h_o(mAfpN90(O(BVDul^<wJdmJ#RW12!Iw*>_w3`cZ8
z9EM0byK35}Bd*TSjo(1G6Quq^9ahH9+#Hw@u4I<#Lr6O20K0T-7bw-|IlV<GsXj!#
z6rZn1Aj{-jP+GUhF8>xjV0ZB!*UnXcZ@HG{&XS2YM@!>SAkxNYX=0Ag`TQShn!E7l
zlr>TP^Q3Rl)@~?6|2(N9<enWesRTJ}6EcwIu8O~db9KTG!!;TrFP|^O>1;k;DAMUS
zQh$Jlvj@_1r(9E|UXfPs;Ql5*c$$sl%)#RHwaAA#1Ttj-T|Wq@ti-!0kNt=Gs(%iZ
z{^48_0sc&YjxxU9r?vDAH!JJ5KoR}{+g*u@o{htL8^aFJr9IvPD9&4UeQ)~<O`|?<
z5V=!*h;}DG97}|ZrR8n)r3U;j4t3+DE#j`gt}Ie|*q8sY-rK2%?IAE!M1BldteLYd
z)c<rEsmI}(uv)eq9MVvHd}W<m?mmJBv+MYlR_qmlLPwZ?k)DQ*NB+k(0F_5w-6((M
zTv*T`Np4Rt*ZKrs3EB68M88Poqbs$*ZPuLlDa=TA@qDT#5DCNCN%ZH5l)mR}O4%1H
z+WbBln)3f~@^ALRKGJveRqc60UoB1Tm!-8db?q&`mPYZ4{+mTj)1E>6Geofm?&|vE
zB`r-|2Rx{ysq287v^3S0e5a+kD|E+eY1Nf9A1zJgue_R8okNx2`AAQNKkXUBv09qS
zUtKLt<*#F~npc&TkD69Zt#4i}O)c+kkdjwhZ#|%;sdWog)5O-H;Mq@0Q}OmoHkfu-
zZKDlZnvenY`405ijJjLxoI#ra8xoI^@-+UJ>5BQvY2@M9Z?;N%y|i1zEdsqi3Oggq
zLE!Q%)e_)Z&Eeox>OY@3X=l>tuUX~tuy-syxgy#^>W8GG?2nPoDDYDdba>o#h9pN(
z?tYX(d#c~NVxLra^F^LU$Rq24$P*#cW!>?Yu%Yw|x5(vQMxSLF%9uL%b7Eni2XzD~
z!z4h_uSFkAvtOs^)U>UkqLfr0!)^OCc@G8Oy+JoSXdROKGG%tij?9RE9{8ca{}#nR
zmhtV&-N7k0@PZJhl9e!_f1=GerYgRaGOiF(Hl<`dMK;R3BpKx})Ip^GM8y{VhW)v^
zzjCb=<xvp0se|UzC}UbPPIwVWgT50xEonUbiM*$le{bD|BBTR!dm)vNRx4gY+n!Sz
zI|+G~!aT-49jK4$X_Jne-G-J_AH_~*pRCAR@|or)r2IX~=C_;8@9Z|e?|voaryXx2
zeMjG~rP`soTAFGP%4unCWR`jJt7$b=o9LjWsW$AvBtZ`}YN|FYNJ~>~;=YM0o@%oz
zYiX*znmIwmQ~9g@rIJ=dt;gl@N}7k7_KTLL=3TF)sdZbVrfK8Ra4k)(TOTb=ty?B7
zP38IK7YZ-#D&4QuwCbu1hH7c548pZEwY+v(nmTUP(bClVme$f#x_ibcylBru_SDi;
zURrBuDlfIQG{K89hmM6#&^GFy74=0QoQX+G?#u?mucALtZzP|~3j7fHE<VNf5<g2k
z_Dj)W?@Dwq@7LC7!z~@<+w=VSz*6HlltDW-mlGr83xVB}^+3?!cw$ROPs<&762RLf
zNuNZX_%!k;bL)uVpoP#GwCF3h1LQN}LB}Z5RCa}z`{<sCll(NU5v2}NpI7Yff8$wk
zmUUIO{jpJENmA7Dyqu<-#h?tm;!!8m?JF>5JTCM@;414QX8P{<Pia4M7TCB>F}PS+
z84K|qY>_YZy4_t_W=Y6Tdw&Q~*y2uU$P5pp>hFJX1-_jiY%%pu@!@UHGb(M?d4!bP
z0zmp)79;&#2kg@C*pSaKr?~qutuuexxTB11uVq>rK!fW+YY=}1EpsdTwB*OW#QK(g
z%?;vJf~cn=ceps}vtn$w0ML7ZI05OC1Py7fiYAuM)*@XQmzA;6d6ZQ2@6cV!gOKt_
z66f+$=`e0IjWy}pLl{4)2>qwvQyH^n`b#>b{2nF$=D6{&z4(v*rfR$HYiX+O+OMUl
zwri1=CTun5`Jbz4(z7_qdXruss3(*OGo^JO&@@>t1%X4K;ZsEMTuK^x($k->D5A?I
z^=qKp36hSGKHJxJ|D0{3w2RwlDLcCh+hqtM>AR&tAMZ%QyARERfe-mcY0;-&&puAy
zxxZYXG6&Z4wqNG$xvVpP0t(sex3AY>HnItjs%G=~e%X*`&Y=ZwaiT!M8u?QC+sd(0
zku}j^pWtgbz#kzqzgl+r60>mTpuCn!S#3XuQvvn!WsX5?JL*nY2XiRS?KKPz=`B6v
z45LCBIx7GB;2O{YjU&z0fr3}of%cZ;&>*JBD?;qMhal6L;Qv@=JVz?{mF%msP9^Y>
zkGK=Y;2bS*^8vS7ZK-c5b29Q3ZfR=5$${_?Nga^~_vC^u&nxuO{ll_0qpSp!^$_{q
z%4HFMrYvjy+=}>FfI9(k8t`2`CECh3m2!UO;N%Xxafl#cs3zlbO;(w6am`h+M|#Nl
zLMIttnJ*}FsUqW07{bSh?3Z~E>0<{arEX)cttpEn>bu3zMrr%>nhjUhq$kMq3V=>F
zMCw(3^bfbPf}Xs$7jBVGkx6Ci>@~2JAeBv7aqUmPx5v6G`ypZ@1X*n9J+z^RHAaP`
zsL$V_snpTT%@>5Si1cGz5n0EFrBl{XXfpnz{IUb44q6>)N7Aa}RXg<lLL2&36ZG`&
z<-r9Qu@Mm<lwO+pck)oKN*(>jOWfMZ)odfz*3tfriAj3@M5cSvpqFSvPr0PypVD*x
z(tiDd%A{;VoXW!4p1)r|<^4GeWO|+;OP%3FfjSd!LyuQ-r>E`S*C(9m&>+~-dYFoq
zzi`!v`%h_(lWE%Oi(9#r^3)u}zb{ioM_<S^>EKYNl@KY@M4Nsnu9Z(`9qsi)g<jl5
z6oSArhFGc)>msCQPEkkfgz>T|1Y4PE{X^^bw(Uq;{=F#AVAzDR*(a6p`k_qU31!o^
z(v}|sPEZ<q_zEZK?JN5Id%Z0Pngl`!9H&V)H{wsA`|y-#TkTmsnP7V9?M4~O9<AP{
zpOoowY-YPwM0^I^_|$vvN)=Pd8d>C!Qr1sxXew<R%E=o-1Y#~kba}%i;QE~vbu_E{
z>bg2o4ocAMdrEpK_ta}UjS%HYZOgV^toyB(!D*QveOqV8Kx0m|H?E36$UxIEg)_pG
zJY_>Udbun56`COBDF@(ySO)PZWZ;&DenkfNH8BU<n=p0I=u$q?dr*Su&S5T`+o>e@
z*!+?@9);Bmi_mpt-g#B#Ww`7!4*}#n%kPkAj}-gx=HM9d)&%YL9Eqp*&9&%PD89Qg
zm#6%d`9#oUsW$XqsPpun*w^CIkVQ=JfIy`s(yRZr{Y~*{PTHZ({$`NcUh8i<qUoh+
z+vk+F_nm_B5%MCkzO--bbBU?@oQ`VxZMbc}Q|h`)rmNR;_PbrS{Z2<Uy>-?1J+`e<
z*IH9iIRt&%vTr4%>RURZz)vq-+y150b)`(VD9WOY3n3OjUHww{ICwQybJaagH_c2a
zN8hIvnnq4M5Nv5WrWmsXP1QwCZ#`{kDz-Es4Vnq5>nYsFze`W4W0tS&*D)zIJ;i<e
z+j3RvXq9QwR<bQiA+jxZrSP$YT*X^f{%#!=oxPhz9sN?bqu#~($Mp=DF3Hviz<L%z
zEQES`+tyQdl>cr$6}cXg>FNE*PeIR^lAbl#8fyV7>8_vc+^U-VUgP)~ECtW-A#&`b
z&+!2C{ECTjCN?TGFwztmVjhU}wCiS&*YC75kD<6>opX2k2x5;fCPe(^K*{xfj1^*S
zA_?^!3?As?_zRlS8YKNf;)Ns9b}=eEzmR$6S_^ruj5t3({4<SbEESMK`gvCNA<45s
zn<eP!PMC=T5jr9|Ao?SAf~*o!(2WX-G)r{xx4odQ$<ikvUFG}`$7Drb5x5qEnVF`@
zEF?NsTmU2S<j5hzV4cNJX)aElN+b683?D^B`vnFni}y%k`vKSsf+wyCktZ{RYJ0D&
zp0_AoN`RoOU6E1SyJm^+jC9-gba8!D|DG<E!9G<25le_%6y+6`Lbvtx^qK<%gr5=J
z5Z59;gg@kFQ%`Q}u%1GAz+qsev!Bj{w)7VD<oeuT=+~!6=Nj-uQ3jv4tqpnOenRzk
zRgw}oTAK8H*9jG;mdK<1md-)2TrI7Jkk$W`Y`G?8ZfdfsYg(ui<!%JTU#aBI|G4)<
zJ%IY8*o5MmUL16;7TTjB@{W+?Al3{gAkSSCsO8c6t}<2y%ta=IK*Wy_yCHhJ;+%I8
z+1`j1GO-@XrBYmzEVZZoHDJl^kl+6)+1isI*F$MTC_mnZEEaQ7Po^(QLq?DBe`iGF
zNy-8Cm%lSZZvlM~8OCKY#B)CQ1z<kF@qp|*69LJ`SAbOkCj-_5oC??!a5^B%uZ5U=
zQ7XSWzO#I=C~Pl)Aufv{p8azyAp7Gu!192z02Thc#hmxw;V%fZk}pgA4ZwHu$NKss
zGLXN*fY@@4uK|ed{rLKTI1Uis3@`z(HQ*G$o`6#ULjmy!R6NH5eLWKYML7q7R?wAy
zzaB==dH9<|rw+bvhP<ddw7U%3F<oQ384=@Uxw2i2K+@w~b=L3_Wjq=_+w!1Gsvaa>
zlIVT`JhqcwPw!=x^z=R;=Z%>i4DoFMvjBDi%nBF*_z@u6B|G3qz#M>zo+Ty!yXE`I
z{ovo?-}_(Y-}o=eKOSx2c3zS{&;PT1xz?tPsehrJ*e~Aza$c1Q{fo~qWC83A_z|EP
zFdN`#!0doy0doN!1<V8ZJ78YGyMXxs?*lpmI)L7%fYgI{MDGj#JNO9t<A0tH_DQqc
zKiS{nAuIZPu80iZWrh3z7Xfl?T?|M$GGBshx4Ev703?0B<ZM#DKLA<oWk4mL+uz7%
zL>UIzE>S;h?MOqg&hm|j-ZCD2F<ZRlI=qL%$CmcFZ0%P+87~QC__;{!6ea6z0i^9g
zWSE6<ka~-Am16vy2gvdBdqA#fF9U1=xB{>(Af6?T9|eee8sirO;%s|-BH(twy?{Fb
z4*>20JOsEG@I2rVz?*<cfFFa8<AAP!Cjct}o&u}_h_e&%bpYX-#<u}H2iO+y0-y=-
z5+LQ&4ACIh%LiZCAKAWMOh*_DJkCwAMi}o1h-cu%I0^lTFNxnH06F%L0%UpozMzC8
zC(ajGUKYTLhzy~?V|m~q-U%=aknPwDkomn4lS)YWsawpS70?}#p)2s1zZ)R=2>|4{
z9RyegFc^^K1Tnfw<*decmc#Z@#``|N<L|zJp8!Sza?L0jusxs|a2#L^;CR4Tz`20^
z0oh&y0TnvCN=kGlBi)wHXBekQrwAbF6a#DtSR9bNlmP4sSQ4-=U@1TgU}-?oFAJ#1
z)m%cNQv&I>a`gv4luHLd%B3S9<<bd|`DY^TDkbH=jPJ}(ya|X5FM&t?UI9`LZvb5Y
z-vYAjGJ}t5fLQ?PA7uq>1egtwI+Pud{&pU~A%J-SrvW+wQf@dO5Wfh}8E`#d0YKX8
zf`H_&H=?7=-$HyRe>njI5E(AZ{9Tp#yDsy0L+0-eAo+U$NVz@)q&#s4tdQpuz_0N8
z86fEy5f{kzhy9rJ&@EK|25ltpsDo}|FIch<#M9fi;uudTcOxL>36)dxnPorlGyadl
z_4(Z8d>(+#_`imn&y4TMhoyFklk?>Q3`Jz<jd79f8V=|J*axsOU<9BiU?gAzz$ie}
z!4M5dd6)s&KK%eqfH8p4fL1`tqb#C9wu5=`m3ACe6>C!bt7`$No&kWwr(AZ)@+*(;
zwsPqK`4vQZcR=cEPn|rCV%=MspV{X74su}q76G;cTq?`O8{Zw}{hYe^&U|{iuvMnF
zNv5|MkbG?cbO+oCsPLU2w+s2RZI_y$$M&oR$abkM)31f^$wsMN6#9C*b{*x@Zr%W7
z|9Ajc8}K0@>9UWQt4R4-7WvoP+1Y3Z(wzfHJ(>$hIeY_H1#lr?HNfuxS)MmyqFkP0
zXZ7+}3p|#$4v=<sJz!D59{`Pjn*bHQlI3#PrnY>24?LE$1dx0!1ted~0m}fc1f-l-
z1F}3bqNAHs&sq4+^7Q(<6?n9V+W_+cZU-y^xD(I?a2Fu^{7-<?`JVv?0`3L;9Pk&w
z1i*uUQvnYHDs&TNx?J0{rJDpi*5eo;<#7VA65wxu)d7D8Yy@})&=>G5U@+i0z!1QT
zfDwRK0NHP@0g|pCqGNTbzQiM4(qUN))Fb|;9?`yf0=fd$0i>RI0X7A!2Z+96@CIbL
zZiq>;|3ZE@qg=iH;CRe(IUdu09wys0>Q<1Pua}%J3m|Pc1IIn)!@I@fg8<>ni28Bd
zQ|P)?mFmMhtdE{<OW;v&ad$&JZAL3yz92at<!YM`cfpH%jR4Ex|His}3GboTRL<87
zko20%`MmMnP(k98awI*y{%^y$LOt6Kh~-<uPC(kBU4WGBZa~)8oAEv6904B7ISR;f
za3)Taa{`d%{069$6EBxj6X~}6>;WFj*$c>WegSj=JOEe~@F1X4&aU_Ha~gOo=L{gr
zIS0skT>vCMmjIP=3>DLs&t>4ToGXAV=Ncf(xdF&>ZUM3!em9oT^ug9%E`fccJ}m{L
z9a<*ayUzH&OQt^s-zksmfb3fgM)V)jF9AsUB>{^8mI9<bDGf+n#<|J(F953mP5^WR
zBwq^<&6Op-l=9h6rXey^2Oi6J2W0s*09n6UfYeV<K>Fo%0KEb00g^Xwz}A31fL#F_
z0-69D1NH^<1&jo214z5n7LazyACP=@1tgyVfaH^M@RsEe|Nq!~6F8m9|NsBUlClj+
zvUST4k_LkzG4>_P*cEk~<z|N2%!0JID@vgz5tWKkA!RC+b}CY-v};$XDAm+QrPc5G
zx~_9(?zv|%eZIfnf1T^$^1RQPYk6PqYhTVex(?GrZQM!DI#6=fgKDSi!*;L%lpaoo
zb6`_A4>pGiKN&mqEUSlnek=SFp*L>w<4)mEg{@!$RDY5P)sH2?32+*e?xw?=p~e^F
ztr<^jgc?V9@kO|L*E(x>d>U7%JY++)ce(IPI0vd;%!TR~FNRuQ3&OteDkwP?!SmsD
zQ1QiKgYNii5x*6m!uQ(OGiWcBKDHxG{<eqmkBC9ZN7ojd4{4%<S3-@q6mBdw!tM9Q
z@LS=AwjWE0U*R$iGWGOEIF#!ZP~~JLR5+?1ac=!kKNem;9zcAxm&`%TcxW^9(iOqr
zu?m0d<@yUv7iG%m@lsfizhCD1zZ{;<HEA;A@*q_EcLh|qQ?Wsx4OhP<kJ2#?D{~Eh
z)-}2`{qME#46YZ$u5c+-`FH9Sm~o@7RS#}}DpPsTOZPta-4l{e`U~wR-ou@)KZSMR
zXRg0ken*&RQuLiAD_^MI-)?C2wHGSf51{(XkKiEq2~_+M>eQy&bf%wX!%;q0(|ydH
zC)#wbfod1lLh0=;sP^S<sCu;?s{Cz$<Kael5xgI&o^66x!3W?<_zcV<tuMmM;0|~L
z+zIJ(oL!K<!FdfXM*(lZFW{T-C-^q}1HKE#BkNu`AASh0habZY@KdM)`8li(zk(6)
zYuFTi1KYp@uoFB8d%;8SN%#Ydq~I06KJX`a0sI-}!vDZ|@G$%y{t9bS0Dp(AR1j;i
z&P{_|1<r)W!9}ndyc^blo8XD?QCJIp2kXG96tGiab=VX(ho`}I&<A_Nmhd9j3eJFS
z;Vjq=UJ5(Fg|H)h2u8stVJG-H><st7uCNgeUN_hko(s{f(+4In@Qj7gwQ0}c6R;m_
zM1dRtW8olp85{*~fTQ89a02`kUI3d@5GTV9&=0%9sc;k|j^K0{fb(GrTm)ypyI?AO
z5@y1;;B5FgoD08)7sJ2cWw1&Fl?2v-3t?M$H5>@9f$?w=yc}K&*TCywI|}$>I1ny@
z32-SK-+=uKxB%V&=g=VM!F%D2a0L^bWpF#Z2~x+LmGDQn21Ykxoez$I_rh^-Bg}*k
z!EfOs@HhA<+;)oNJO=-PTjBU7%)j7G@Hw~!Zi6>AW&8!-fzQL8G@LKM6X^I}gg?O@
z@az^mlLg;}ufdb3=WoI0@EtfAz7J=>51`rw)#-ihZM(p2)BaJN3dg_dFI2oa+7U!-
z2d6>A&`{F&_whUb4eMX+qL22Ie}(G;+uZg??&4f`txIvYHN>5-9Cwe0xXavAcD%2I
zxXUlc-R=-~1+UxiN|W!g5O;ayxZ4uqE~1=xpAT^t>$;;@m(br!A@0_c<L*`0T^wO-
zbLR({{0{H`zoj3h8F0RXYUjU)8h88*)sG#96W}j!2K*JOocOTY+;o?g&yR-4xv!jb
zzY*dt=;m`<g&$UKo(pleublElT`ZI@t{naB3UN2Jocw#lb(f4xu@h{0xZIVGX0mXc
zm|WBLyD5<7!kGbELfZbI#&4-G7N)@wFcWG#Fbk%^Y^eS+2TH#Ouxqy4`1Eaf>4WO;
ze2kT8Q_seC2BevF+Cq(g&xAwZ*--fx1t-GJFdlY?S+EBT!rpKZjD_l-2f#<*AowU8
z3ZI1|;oER5EP&(SQ8)?KLbl1U5u5@g>r{9;OoSa^0Ct4QunSCu{a`v&dL={Nb2hzI
z>Hif*UG80qmHE4_P47QY^|1>6?t|6fXRs#x4%UHx!n&{}Vbq6RVMDkbo&s6BcbdQ-
zU^B>Cr_%x+g{MQwGZz~-(aLiZza<adpE-jKoNLG@x_yT}-HrocORlejXTim=J6r-a
z-dze+kFJMF@J2WbE`wLX74QalGgSOrvH9a{{7RqVr(1D0VP(4GPVvXU2CxT=gy+D%
zuooN%&xI-neW2p+3#Y;XFc%JjSHZz>85{!dgu~zia5#Jtj(|_YIJgathR?&Xa5o$e
zKY|mW<ll>p*lOj!+0D<!+>=|G8&0zAP98j!>t#^-TMpHptbiTiN*E1SLDi4jp!9V+
zydK^OH^aN&C-82la(Ew9`CAWF?lwTZFY|u59Bzi|U_RUgAA;N97RX+a^C)~1J_bi1
z|5msRJ_(gRmDi{nZTb%JTlo`OUeBpx^QRX)oxk^mXT$z55yrs<a5TIcroh|a40t=7
z1(nx1@Ig2ms!Ys-AHd7u0Z8RH@-Q!VBGy}ZGHK8ykIGpG?#p~cxmG*>F_gYPg+1VB
z@LaeL4uFiUOnLnp&f)qyxC$PElB)o!J@^T}0Dpn|;ji!@`~&L!x_`oYuv!G`A+S1B
zJ*)}YTX7hp1?RxJkUcV|A-o!%3>U*w;BMFivNz{6h3v&S%^`a&P7BE1iqjIZ7v!7{
zBVlVe61IV3VLPaKMtgWAJPU4u9pOW;6J!m@=?wS5Xm}zz>k3&*aJs`DFb1;5;q-*;
zAvov2G<Ys#F6;D$tU2q<U~nhw2U%lv20;2whcT#`w+x1n)u?BXF_bd`vc~C*f^l#(
z<ke)(SeOYXz+8Afq<M6vz}@gd$o7GA5!?$I+Xj!TPM*VRa60S=lVKE`3D1RTa6HU_
z@h}tS!Z~n0yaaB9SHJ`CO87lo2+yR!xf-4Y7r_xQ4=#qcz?JY;_$a&sz6=>-2VaMG
z!}s7i_yxQd9)Rm%0o(wq9nU-wM!?OmCwvHwgpa|C;4^R<d=BQp?Qj)*9zG9WfG@%q
z;cmDC{t91#^=dK>hB}b;25bZ0gsRU+u-o3U^~X=SQvGShJ=JZQZy5Ke{v3enXEknW
z2@k=x@JHAQGDkJ@VvU!Eas3+{51F%?{$A%YlDPf{X2U9so0r3?Q1xHuGuFf7VLm(o
zJ`QWcXJB2p14cl#r8=MSIy@PE3mZZ8&yC?>$kDxE9n!*4z~C8>Eh<z0PKW1n-3luG
zKJ1>CZ2C2>SNi!^IBx&cZTA}M=5p(<6ZJ*zeB7$7`<Mf?M`WjS5GtJSU{Cln8~_i)
zk??mo8PaH)^`)v%>8}RYz~iC%o0@PttOY-Twc!`A9{dMJK%GlD37!TU!bo@ujD?M%
z#u-iFMX(v13QvP-cYKgN0H+na6-L6<@C?Y=0;d~%8OFd@VNduW>;*rDz2QL^3#CW)
zcieB@Ba7P(XK`O`gUrwdwj2$E>d()E>K8{qm7`Ix4;&3A!m%(BG8Z-N@%eBa*OQ_8
zhbeFiya+x8{qQ+B6}|uy;n#2)R2ff()sQy@YFs%JCc`wy9=?+SXTw?WN|*&-gE^4B
zU}rYey8`Ayhy0%h^&Xf@;6!*CycEudm%}UI0(ceFIA9^X6<!Tj!$t5ecpcmVm%y!X
zDSQ&<!R>H4WR2gs8SaIvAZOT|TOnuDoYk-~yaS#M?}C%zIv9ZWLe^HD``{ID6I=`*
zgzODE`H($0=VAC7+ydFlavp`$LFaKu9dowAf$(WK8g7FO6P@ia1@3^^@Fn;Vd>K9i
zUxDAl-LMwz>1(hKd>uA{@59dUW7r3N0?&h=!kO?hcp3Z(>izBCz?JY%csu+HZifHB
zPvCLX*Uw;8_${mkkE3GNgeSri;1E~~#=+X~dRQ0U4C}!?us+-i8^8v%qm5uQcna(Q
zo5BIG8H|I?q1x%w;N`F-+zDI3T`&^916#wNVO#hIY!8p4J?;Qcgq>gu*aiAvSJ)YL
zhm3ul7|58^=>-GuTzEO`1D}I^;da;$z76}sLvSGc9S(-7uTj`N_u2OB9De&K+hn^F
ziIsUCcO>6=0ct$|qU&!Fzw>Uk{$lVWf1%^Q@w5l>Hvu+)lVJ?J2#$gAFdimC&Hs|%
zDmV@9gfrp0Fb)0*(_sX0WWts(7e>RmQ0dsk?_d`z4>0m{<Nnj!mpPkuzAe=LsnVhS
z(pcCJj)H^Xg>VSWfWzQ2cph8{hr<mp4n770@C%p>e}Jj*510;5AkGY^dEqRm@plgF
z2^q@-*}HUR!#Fq(PJx%e`H;2T;97VEd;nerpMeXY#)DTwjR&uRhu|Xk2fPl}qdiy*
z<KR*_2Ij$=AYE4Q7Ptbgg)8BGQ0I;}!#m(ha1Hzxu7y9syI@@k#5&jn-UHcFb0{*w
z0q}mv9+9&NUI`z73t&D}U+@Ur2p@&J;N$QW$kZtKK70Z)MsS{jYF}t8On$CMm-!=Y
ze)^F^<xAygHCATL@wOjX3pM}08#aOWz!vacsCnoHsB!*AcplsYmA?<bx`g=<JPSSw
zd%?%xDEK(!?342Zd;~rTABE3A&K^12;bh2|%g8&GFzt8i(Ivknuf|K`ure<)A5eYR
z0eit+Q1ZMCC&5>t=6Abc5WWF#fbYRu;rmeK+=sQ_px2pw8xK(xj#EBy>!-s_`we+y
zaP`+5cN!DPycc2h_W{&+?jxvr@F`Tk`#B82FQMw^eki?t163csg=^s<sCw}O{0jaA
zYY_L(Q04y@*a7|uJHg-K82AU2e*b}U;ZZmb9#@}n5af%@!Q0{Sa4)O{_e0(k82lR6
zhnyjE8p8Up32X;jz!;?$N?&T<?DyZTj(qr~xD~c<>llaW`W~qAbuW~^tyud_cl-So
z`O|nsV-A@OxKn;^glhL5fGT$n!NKrRm<%6-S~q+WE{0FRrSMs({M`;U&V3#}40l4U
zGra`W{=EXffqS6Fcke-S4ihGD{TWPxpTk-3ODOp@rm^2(r;U?7xNgsVwKXyY=tuJZ
z1SS73uqpfv_Jw~!rQ>g?@^BPRg;c^|0;mF&uBuSu_!{s^cs#rY)`CiBZK(B>y6_%Y
z4{nAL@L5<Nz5q{#8qYU^n%|!SKZQ+TO=NBgo51E!X=wpFLmy0pEnyaH1y!C}Lyh0s
z!24i3_$)jVsvV7nAHc4Vv#m}H)cEckcog=6oIP}U!zM5mo(}uLE^r|14F^H#dk8k-
zCEH%z%x}pk{i?3ZtZQiXeIM+}^?EoAJ^-(Ro8dC}5L9?76ZV_yltsc)cqegh9ad&9
z?T)TLfTzI^q2^y7!x8Wkcs2YCO7CC5hv9y>1AYx(g$Ll9@E|+_zlB;q`VKaRhhPi%
z1B`?}!t-DOoCXiWjqn#JxurAv-E!h~`(cget8rh3y(Tk{Y!B7$oC(i{XF;`t9ihrq
zC%6Q5fznG?sB+XDZihYKYp^GL2lj&R!QQX{#zM){7ybkL!Rp942&!Eg44cE@ur(Y3
z)jo}e=fbgYBpeTea3Wj^C&8WY0{A(c48MeasPe<!nJGVskh82#66EZzGYv+;WH=1Y
zfLfoK31`4GsP&m_cpc1v>bG+tXM~(NkY`t%OW?2YG8jq2wGg&}*Fde$EQZ72Qg|s`
z2J_)fa2s3!nR`1cVLkF^6>JLcfRXS{$k@nP3n##PA!8b6J)8qKz#HNHa0ASTo8d!H
z<NQb9ZumH4d*9g#l@C6w{f>L-{nlr0zZHkO{C2h;soaF`*DN}Y@iF(Wh3fy%mFf4F
zK$Rn%JLn2@t$MZ;D*h;}{kFROt#DC8VLyP(rd+-TJ8=JX==rnXMW?Oeez-q|C}ux!
z6s*JF<3jw|@0#0p--P>n40jqIXgt&oYCNR))Mwc5l2dm0Eq_Yy6s*jzxYPA-u%&L0
z-ZR{5rT+-`yTjk%Na&rz(6z$&1Nz~g&`Y2FzBp@u+z*#C4R?|=3wDG#u0J2YBX-(+
z^5zW`|H5&|Gj4una?gI>o4nw++Ob+tX_J{#)3%FqVFRu&hDz5wcow__Dm|A%m5s~b
zMUaO<%z3IS;H6w&1+Rq*pwg9(wcquot>d@S721B%CYW?psbbrq8t@d{9S>VT#_%S7
z)^N@F80H>ko%m#!!{1MZ8n4lYnD(1CGI$Huq%U|sq^%4-0o%Z*U|aYcY!A0X#zetA
zkhS69K1kbR<W@gozuRs54#^$bk1&2Sa{mU^e*O;IL*;Xnd)*EG!F}mL;n{C&bA#W~
ze`t7DGOpD1RZxA^LU<m$8qR{(Lh1K9sPNWf?f10pceWLt@@+L%W+(brcrQWS-vy=5
zm!az8D^Pj=8k`B=f^*?Ja3OpbE{5;Hd*S;~>wX`==ix{24fqLEzx6pRfM390;C`rn
z>>DU~S+8`zvCTy-n||fn$Ey4o)*6gHW1;GIUwA6)2Ys+VRQ(zP6Ci66W*j^MUcvQ+
zQ02}KS3uU3O+F_=$r*qjz-0I(oB<EQRQMyzftugWhT1Q<7&e3Rq57pOU|)C@910i0
znUFP*;I(iuTmhHDwJ;BAo^lg>60$a8*6HqmpL4wy9)Qon6DeEILCqVVheP2Gs518w
zRKK(b(v~`J!W-dxQ0r3f!{^{fa6e?t#mpB!gEi3Y=dc$13bue>L(Ln%fwAx}I0GJq
zT8E-g2JeGa;B%0*n&6wTDm)0Q!5?4^_#apkYQA^^<m`pRnoh7UtOX~*+HfkY18KXQ
zdT=4E54XdU;aji~Jf%A8q_7!m3Om4Na1v||7r+)UAD#w3g+8cnTAU7lg>7J63jP@|
z0=9#=b=t#DkUfK7H`oPEf-&$y*b6R!vG5ky58e-l!)GCT3}zo;B;3dK82B?B2Y-W{
z$qGgv&-emr-DxINhjcl-9tI(EVP^r{0<VV5U7bbn1<2k-@FU3DSFn0b$`3phE`wTs
zVl6D#58ei+z}q2htaAsv8m@uM;ayPYy6%Bb!u#OUa0C1pZiEGpv;~i&LwNvdeRwl$
z1RsX2A$upmGvHR(4Wff!FZdiB1h>I4a68O{FTgwD4ygLR2)m5}KoNHiV14}1{6=k<
z%x2mJ)aK+vwNDShNcb>R|Mm#%54XUn@Nt*{x57O51l#~gquG~u2JYngS@=F=%`Lbe
zJ`W|2+T{G5Rvxv3l855!C{CH(^pm=N4K{<XyZxs8?J39Ko36jNTz_x7{#Fsb{U$Sc
zP5D-Q3Tp|JxvZ{D|K(76xdKMR1#l$123`QKg_pqV;AL<ryaV0@H^LS0akvtG2-m`&
z;9ZbD)VUkBg7?6#@IE*IZh$;P;B0~y!w2AvFdwdg4?(qCkHVMX<B(^{oF|||JM%Qu
zdi%5REchHe8$J)U?)5U90$+tQ;cM`E_$Is^z6G`3^)}Rc`+HF9>wDpA@I&|y{0J(e
zK7|@z?}KgOm#{nB4~M{ma3cH`Cd2RHd{_XlhrhtJ@Ca0Sa7c^&b}?gX;!*yDuFIT9
zKB|0<fEwS%K_46gRX)eTbKwLy6i$L!a5B6b`r$V)9{via!G6S%47IM60w=?nZ~;t(
zSHleWILv`N;B5E~<jkL0XS@Xd#r36-XZ4)RVNW<8_JT}CgG1nza2{L;7sIO|V{qqM
zsC|ybP<q&lwckHB&!8ARH0GYx0A!wK-XJ|Z3#FfJP~*YvZ~}Y*CcvHWYWNad2499M
zr>{Vj)7|iS_!@i>z6C#p@4z~w=Uu3NcQ0g2=X?a!?|uR`AN&+*KDZC6|NR1vhhIWJ
z{0gc+J_xmbbqFebs&fTy{q^x%`Ajh=toQGs2VK7p)h_IH^`fzh{XTHfx|7<4Ls*&X
z8HY(PH^AX=8JrB4!^`2#P;KBUm<Ml#x5L%&K6pEP0p0;$gKOYNa4pn$WF6Ex`#rD$
zTn}|#X#-R}-UL;TAA~ATo8f5q5Y+n1BXADf0<VCN!)5RZsB<Sz!Mouz@E-Ua%!k{d
z^cIJ;-vwrl&Tr|B?#UT|l^IAqlHLZv2si|u28TiEd^qe3N5X+H4k}!&OW5!IQYO`Z
z6Rzf$-nzsOHS9R>N2qaN0o3^V7brQ7zzg9Ya2EUvUIzbx4?~1B=Y)=fD%(}z$M6LB
z13VF)Nt|`yB*<Qpd5-!dxRUEeQ2J;LABIif7RX+csc+3;9nx?*)Or+Wtb@a0BpeO9
zz^Sk+Tmieob+89~1onbkVLzyK{{FBIiW~sz!-237911mFI}e@(IeQR17qYh%916$4
z@o*f}p6+;f2b=`8&VK>i1TTb-K|g#4#>0Iu5jLpC{13K-0oV#A!?WN_cs5Lf7s5>F
zhgtAOm;-NybKz!q31siUxfH$x*>elFAb;mWAG{Kt4i`d=>z2TCAY&s_E>u_ScY`TA
z=v(DN{h~KsSjc*+>f6;&_ZP!6AZNYJI$Iu8{aOz1hb!Qd@MicDTnXQXtKetw7Wf^!
z4fY_eJK+$x7OI?1#oF%(GZ)~u<Y9PIxR0<5xh2m{umM~STfr5u6I=;n;VPH_Z-Ghh
zHkb=nL&f96#_hD@l7_k_9{v^1-=B5cBh^Ry?O*bq-<lhQ)<?>gnLp8&n)>o6Y=XPT
zVJy_VbdY<k_KGrS;t%q>z+LCLlHUrq4%FOQCJ%Q?H**dXE@j%RPp^dSxW5Vxgm=L6
z;N36)?}0PndYA?`z-+h?N}mrx<!wHc9%8ZfJG({e9~2KqV<MS1S?^GKnJbv~<{hZ`
z--8|C`_K!=eiPT86<2yf!x@V^g~QM^SPxzRm2aGNGS9tH)=fBS!|Zo#ZTqBfs5XWD
z24&so<!RW1``&(8GQaJ2X6bABEq_`knu3-2$Mts<s+=fax&vLu!s^V!hQJyy6YB4?
z-RmH%$^EO~iBRb^a*}wJnKQBBa;_#^rT2E&8ft%0{#Ie__gcwsJgeMAaBm4#W*6<L
z$~R}H%shNIRR8umRDQk%m4ENT>)>9fFh7Kkz)#>d_$hoI?t^c@FW|@UOQ`zy4g3Qh
zgeM@ww@~uMVeL0sX*>C?bcL38_MC$>GY)mvtoQYV>L<>DO(A0ivkuuCcICPcRJfC{
z_B*PSRemeoHKFQ+%mvIBl<vu}0c5TfYzh5P<DGb@{w4t~gGumC$lkvRU-@sppURk?
z-wHo8|DQ+yDn~Cs)z2MJ<=`ba0PcdSr?0~C@HIFCz5!FA%Kv<*@~`ylB7FNDRdkAu
z6kj*)KMiG=vzhdq3nd57?3i@*fv0la7pmS4grneKI1vto%I{%N{p|=C51I3sayb^x
z<$4@cIhX_&!3*F@$TLBv9885<xlV-JVE}#&r^9byGSoiDOxOgb!geqXs-Mn)F_5#Q
zX5T&=YW$Z2N5EXD@y}d%5u69p;3aStyb@}DvjAQWuZ3ElSqwGaSpqfAUJ74=%w^3w
z&2soV*DIjL*|)%k@HVJ@gxg^oxCVBHcR`KA*Fo(^-wQ8<8(|9E1n0udQ0G7&h6~^p
zsQrb<pz>4smrtVv%=c1t-ICu8bpyk*S*G3j5vtu_E^p=^KSP!6-(WmE0#o4cFbn<(
z^Wfj`7WfZb2am#hSdI9VPu1bm@ObzNJOO?HYr(^?HvARVgBq_lfK6dTcsgtfSzC2@
zR?M6WX#tgAK6pMn9VWuoQ2E3fgBhRlOj$6G>nNzXb0?^L>I}87#TrEL2^a&VCygWR
zH%!_4qJfv5LdTJ>;!f+#Z^6#+Z8#2o2vtYFfNEFw!-eoGxCMR<AA<*A0sIkGBkbRx
z&MEv3SwnXIfwAx?90seNXy?<%L+y9ggqrKuf$Lyh_#kWmcfyn5$M6*RIcx%df=%JC
zFcNBCy$x&x+r!qd1MChv!m&{O!};!YGK}K>)i4^;7dt#l7kmPCho8W6;OR6#z2F(J
zH%x_nU^?szAAtkm4mcR<oXAk9wc26ub2t(fz)|oh91ZK!AdiEs;RM(oo)7!O$#5dP
z5YB{tI3LEtn_wbb2Lq5ZD$aDc6Q;mJa3*B$#7TwpfleBv4|Fo1)(x|u%7x1C)PSu&
ztI?y%MMLgw!ph|0E&|Sm&EZ_w0bUH%-p+#;z)PUo+biK*xBxDLi{Kh~9efT-|2y34
zci<B4OOB=RFwBFRw=IL3x2=FVa3$3F##`a_a5a>_C~PJP=a%`lq~u4vP9#?5CB}p5
zpLRjj|Cgcs#bWKZCyV@{mcsE<7V|oVa|u-XFNIpixE!i~<(Wql&MI_lzb#20LWiOF
z^Z5G`?#p~q%eFtCLWT1slpeo=8jpPg)&G1C&xb!k^_PdC`iCP>;r$M^KJX{p0FOeA
z8>-f}{lf9E263MV)&AFl^zlwzm;viSweJn!ZSW*`J8T41-%f#>U~~8~^uZ5cOZX{_
zgaxoQ{28`|I;YhR>YPpoI02pw)s9EO0OT1|vmW0SUdnY048k7pG1v?4gy%w?6ODzc
zcYWa(Z~#0E2g2Xs5O@L^GZgB4*Llzfhr`w|4o1T<us<9RdG_A92wnsI@J5&n*T8i6
z6wHBd!`bj7I0t?M=R(eiI~POFh&z|UBXB;{^UPPl<H_p<Q1$s**c4s|+rz~$8r}fU
zfq78%`zAOHE{9{_N~rpNE4&Ea2Gihbm<8{Iv*B8J6}$^FHg(p)`{6xs3%n0%Ub!AJ
zW^x{ZjDei3@Ds?hz`=$T^e3VA4W5E}&fpo?4{nFU;PX)X2rt4UxC;j1tMFmC8*YJb
zz=LoP{0_bi*`sjYfv3RtVGFnyve)2z4BNub;Ms5=><+(%gWv&p9y|y$;CJu__yc4u
z-}xD`w(k4_TQI==6^@3#!3ppW_$d4nau&q-3v%YeISP3ON|Uu9d$dj!I3HGnJk#Y=
zhd05RQ2PNVz<XeA$XdEn2eO9lM8H>JeaK#*(-5+!=bQ{bgN@-&@KpF8*bM#wTR_GR
zPD@zj1p0Nzn81mI^!ZL3NFVQ<0qNtNwy-N~4+p?A;RM(LGIn&%f=RF=WbEfeLB@Da
zG@JvwLA7&7u=ZP+j5(>dYM+{M?+{kzfvUEBdJxv<dNWk}^eAi(Sqm}m33?n(;Cd^Z
z2cLvj!)M_VxDDP4w?mBw=nI3};7f21q)#;GTzIy|%x8APuetv^{0Z)Xe?a!m%)I6;
zs4*OCFy_3=yU?5?gDttg7xssGZ_z;bA=J3`GdKp)=bH2{BFq9R7PlP9q4bBYlib31
zj^gCp3LC)NU?f}(`@%b*#`$YtGF%I@;9c+<xDMV3DJy1PvmQRk^#-W^?tZu%Zi32>
zIIR87C1+;%EqN%O&H${;0k^;U7HWO<dw3T70gi<QFaiDyGvEaci_&SoX~`Iw`{C)_
z!TO2fc?l|?In!;ze+9PX`c)VOcf)hxYj6;J9cq5_226o_;Pvn=cpH2hZiMf^&G22Q
zbViXb`~6DV0DeoJR@{$-GDmPHz5foS_dlTY{uh)S|G-|5$)?%gsR}1?$zGp14^jh4
zo|<qL<m|cG_o)N#=Q;vD33+D7%%dAXjW-&?&*91NSJ()ujx>ha|2Y*lgH2!y*bGW`
z_7u%{<TS|K*zv(}FcMCMJd<Sl*>><!uFr&vVF$Prc7!*=v*FFK6I=tkz|Alk8oeP)
z#4EPEHs-gFztPPUj%U6g-*x>ZYy|g1`J0Nh-=!>?N7D=xuD{((Ig!3sLg{-I>;i9r
zL*T7&3|tNU@OGFE?|>SQ+zA!WK5WD;E8lO(Ciza~o^&g75$+U^A1a;%sCbf~#)s3O
z=D*2M<!A;}xk-he!*r<mZ5C8n$%Yya&Vic0&V}i49?XW9!ujxWsQJTuDE(dm*T6+k
z^N4HVQ*a4<1}=pf=Ufl>!#wyOxC|<tL4MnBRx%er;Yz3Kp~j*zds$C734Q=u!cSp4
zxDUp_{ZRGwYp8O25Ke{PLFx5-xDfsb?}Y{M6ZjMS0{#iVhJQho%fF%8J*|7SmJHRY
zpRfwlzRq!QBCHBCq1MGDtJcL<z~kXvQ0rjQM{W2dtP9_P4d54$u|cp3<1CHSkB7R}
ze5w)b3Yj~Y`4rE-1T}wR3}ME1r$N><otAJ7WbN9F?^?rGxNZaAhiAYKAZyxYT-OEa
zyhSwBIsNWX=Pi0d<%17vzblDIx<*F+6|VQb?B<u+jHtG@T%N-3@O3@b7)<-e9;?YW
z#;7KI`70>LUxw>1)Acti)L$DLpW4sx_&VWE^{)$5yA~bd&wgW(KE4!xj2(@?W>Ef`
zL+L?sW|ku-&l;HYO@%6#@gec$m*a1`>yNxN{#bh{jBn~0W$UxA>#v{duYZWYpzE(E
za)j$;Anv4>L9iPf9OBP@OOU)T#UIZG8-Jr*e{muHqS}=$=N#Or-(xMwr0?PofA*Vx
zw8f>w#~!_juOn2wXRqGqC63>jZhXC6f1&+1a~rd6cm-7Z%-LA8Zpqq}nLnytMRQ-*
znnx~#UjEu|?v;LCb35fg@w@=*z!yWxh5cq8?K1bn^*sQ0@;4CHhJ!-<=>cTbC6%pk
zf6OUN`ZvK2{QUvf-&B6v@7K|0yZ%D^nQw7di~DNl8p1<R<4C1j@#uPld#(0S*HfX|
z!)fpb=;_0Lm#%buB;ZczN`lfy!1Wi)Z~JXI=BE5sx|o&}&g(zK9nFjLIaGV{1#ANM
z!!zJlQ1Rzu<91v9T!E6*?x<d^!^+HIe5rnpxuw}(y9{a_oih~X{dzo8WYVekyDj4W
zBDfS@3l%nJ$IL$4Qh1Q-mGBq13Z6(@x5C=+HmH7&y-L%*-wCxYco$SZcrUyR-UmIs
z+3(3&dBgMdCDJFo?Se}G%Wis=H}+d_rTZJ|`eV*&{GAu#&wkI%j;q7t%Xj@f3|SsA
z&sBMH+V8QIp1<k`CFjpj`THN}`Lo|tD_zcH*Ix=$`euaqi*wsS&2PfxoJc)XeB3wd
z{O3b2z6iIzm*y|q^_S!N%MJ0DS5AD1uD>MLA8RFr@$D(cA7_J%oT;wAG}oWT9NXM>
z*DLqcxTm@+!x>5AZx~cLJ`c8r?8O(x8&^&`FLC{|hGX<|nd?vS#=7zP_$|GL#@oyF
zcdqM?XHU#|u|BSUl{=s7zqEdvwOb>143ykGTz|3rw%^mTbzAX<*7L^I?S9v(Q1d9>
z9cS8KjaL+BbEy1{#oBLNmA;S4v%Y5EECTv)TOXbYPl6rc$xz`;#oBLHv6jnk$rIWx
z`f#UqN8=;i*Z4@~Iudq<8XuhlH9i^u+rmMxJsbzmgkE{H-=VVO2enHIHxet;fObIF
zC&4!GWVc;V8)U!hL?6O$`Kt>x7MI~&8AdO?p!#LbPMCAgePCa%`$6q{v8HC`34>u0
z*XO~xa5!8HN5d6x9K0J&gb%_C;X}|5m5yYr{XP-*_$_(VK1{*Nd`&*9ef<Wi-#P#z
z;I~la<PcOj{~k(jKfsajN2u}kPjE8)86JkL7wFklC!)$vuiSq7i-)G=_CNWgK2LuY
ze~B4mbAR9a_gpnPeOc%3^-ljHeZ{1stU;bE_wW2U@y#>${ZZwoq{!nZzPFx8deOl}
zR9Ulj)=z(b=iA%;tRF8;7_?y%YlO!AHy5Y;`N=Dz?%CP*$$2M#v5xTPli?9nexLZ{
z#@~L=`fBT*C2hxVS#d3E%g7W_C8f>keTlseO#W^EJ2RIwSv8wAITR65<+3|IcqXE6
z&Pmt5oKWY&KW1jLc4xwQ<+2*nYph-M?fJLlFW8v>I*ILM+&>rB{ha<6p7{51T|env
z{l&ZHFn2QdKYSzak`LpC{aGvNm!6Sle)u(O`c#yNDytU+qHq8D%En2H@~<29Q^9EF
zYAirURQYAril!Gvef;H31s!%D+~NDyoE_r+opb9h?c8%zm#sS+kA30g!OggD!mqWm
z$+x?5FF$Z7dS2CPm!30>`ba|>QKj0HRxjMSu2tME=d|B2;qKp<q_<;06j5dT)z!Ks
zPEPyj{FSvkq}~4^h2u68?~#MOo;)G#hQ58@{Vi@(VA*!o_>7#-7tFdN;)VkwM?6;d
znS)>N#C>vIg|ji?iCY)_aNqgooptTFF=;Ur(sxZbH(q#dixC3`ZP|L`Qz!qJdv6A7
z#tcLvs>I#W;hJ4-9&EQ};>6888t!AV#T=3QlYjoM=K5J5JT_~>iU}8<|M4T#4|Bh7
zp!o@lJHOTL!xtwHJa@*!RO+rqp3BB$FP_&tXGDX6qsP?U@eq}u&IJl*XZ-eMr+ps(
zWBjCN=WnaAg-SHY+@Ev#fJc)4lRbRm7lW@$8oqKYYiAVfh$?Sg^7hL|f4SlC#fwin
z<&h<mxp&0m@AkESzS#S+fd$_V`>Mw$Z~S>Gb<~8@;fDvt?P)ve^M3xb1HJm~KASO*
z(PzVp|C4uo@)zlgy8V4>#2xi7WA1M5M>QP&)dx?Ed-9xH9{9Gw>wDNdxY)!y^2U}+
zT0B?%?{g+p`yu&(*!E_v4|xWSOl<Pyq{AIf$ZWQ6e%B)`UOj5k``nlBMb!5{)91Hl
zBk#Fp=$m~w+d@MeQ6;PSc{K(!Tk-fsNB-{o{sje0W-c-H;?M6#KQQ+E-<w|7Ywy$x
z0_Tii4rJ<Gi<L<)Tyc2xg1>tW-uS@1wSFgjldccXe`EXUdw0eL-y8Hq)qBTXZ^j6O
z|IxfJYoz_Xd3jW;gITRF|N4FQL`;2YaP}z!CqB`(Zcci~-8~PqN6(d}QUjG5sMJ8E
z1}ZgBse%9ZXn<jXli*aTFNu?SPKl4|G{rwBBWvcAu2Zt73{B4oWTgd?Qut))l-Y?n
z85ybBQ&LkBW+!Ix#om;(K*#j>oRryt%&d$Vet-9_J$iJBj_J~AN=Cwrq$zV_x=l&V
zNSvA7kxSMSd)2Sv(>~itPIG4rQ*@6bQWCQ=vNNXT_}Y$X=NpwtxGD2e(x?0QZh2-(
zY9Pz0;Y8NY&Pj4w@CJ{5Et#h@)_lwFM~oc5qVVVF`?^jW{+>%ZV#5EP?N3Qh$w`S%
zO_>*9tXP95_qQ-U^S;5oh<T3;Lm@M7o&a~Ck$qok?Wu|zQBe>kPUZr~`fjwoDf<^;
zEg<|jxZi}QIbYGYm{Yi~?*WH?6Sx}lRvD%;W?soq&*@9L^Y(|zql8--<hB%J=Ct}=
zaZUc%2mk)z#tZTHsDHZ&3;#r-xcfQwyUXj{xQF6LWn&;#x`-_ncW!z~ZB$GjH3@$?
zmLaS&z?GpieMrXCFd4mXiR)P^nQ;B&hskI)^xx~~nXvf1H3nNQY<U@i984Js_xPA9
zn6-)~km;HB`OO@j^$+uIy3=5P?w=0Fz*cY^Yz<ZJ+CXoO!REJ3r{YnvBe62kxYKo4
zsPe%O-1t*Dvw6jO6Tjt8Yia|qGVO4ud}YdE&KR&ZWy;A}urK#JLdnPaOi+2>33~Ea
z{gy6I58O$fo>20z9$@DDM=1Mc&DqMDgOxQ$`oYXqcD}NC&6JJ%e!Xu{mysP`szHLw
znxk@l;$O|F%9<lRg2MjIT<G7fag?=|@qc>FBG=3<ORhoioD%8%pRYAg3@S~f1}ZgB
zsewujRBE771C<)6)WHA4G@!Y_MgMmGpO}^tI`i+;sYguLZk@V@&ipe2*@46yGxaxf
zf5-RV&i#kizb!)Z8#_PMxjGr9-^^NhmIj;7{50w-J2xJblAaVda4d1BWTf*q&C#`Y
zS&A|9o<{Ec*oPuAho;3(5A=)A4%j)m{4q~+vS!CSa(DRX(WALsrxXQm?jPYk@APvr
zM~)j3h)-h0g0p(=9G`dhIhi5uL+9G-m<P+~nZYjbR5%Ow`EFW<W{=EBpOckhRyT&G
z_s`AB3Z&;4Ax*ks<=Hi;$cfuqg}HpJN!N+I-7p`ySmtmVIMwTK;t(XkM-Cs^sk6N3
z-u*@Qm`0YkCy|W1g+=a|W|p|u$=<W;3~do4b6kAZ^gxc$!G2^2*R6E3hx@K>UDsA;
z`?z14&U(7}pQK49=0dFU|9mX(L3H-GbN>k}@+7fb6_S<zbs3PHW#z5P0`F~fGFh<l
zGTqB_-uvie4j47oyRSUg96A|m%c(8DHOUaRZwvR^ng0isCicwDx!okl{M?xab<T}q
zY2N!uIOd!d<=Z^3o(a?VJ7v?HN1qK9Umn($C0oW6pU&efz{=c!J7w~6$h_UT8TN&2
zQwB%FHE=py4~fIs0Iz}@;k9rRTn!(AyWtl2E_@Uog-^i-#Hsr#+s{DBH5Y61%jTox
zQe8{M%Cy0q^l&EB{SJ`z6tgzLI*M77VEw|OAe-l;wHCtqgVP=MgE24;YAs?MJQu2*
zphL4J5hT8{_WjFRGbn4{v#d3Pvep2~T1()JF>~&c=O4;iJ1J}K{-~MLm)tM@#oRBs
zj~_*0i>T7-r0BMD-}`3m+dtQwwD+TDC}?G^!IZUTQ`VY6S?3VQj!ILhfl3WjYM@dB
zl^UqjK&1vMHSm9f1{iiSzxY43{~wr}otqhLR{=C0?^R#ZH;wJBsq3BvD1HWDL_8+~
ze0{UC18HpQXBnrTI_K7R66Yk9Jfx7Fl~{N-fdc{jb`K{^Nytq}O`4Lxe16K@w47oG
z7yL5=S?Ph)E}fmg+(7AJ+S3l+sfPi9*`1=NB&4KIncJnaIopty+EIRqzI6Yd&*Cyk
z+CcJ@lrEf(aJ3Vk&E!q<@mb%PIl4bJ*PoP;9w=P%(6fOucUl<Mh~RvJotNu4LVT(}
zH+>FkAIyc!e!jwMP!wKH1{1h$PCaI(ECRUe4ujnAM1>c0-P@4-$?@q)s6X0-=gq(8
zx_;Zbe#PBB=5wy!>_9T|q)(rbmRTr~cLqW8{Q<dYX%|DyiM{g|PrG62Ou39Gd7J}A
zAF=*{L!$lt<5N=yrKEBoWl(N<Vk~n!6NYzgp_;oca4Pp@M1|oC4P#tZe0uh@K-Rd7
zAvSF$m}0W%y{s~tZ_0=YCpI*k!KoPu@u}mD!aEm*(FmQ7x9-LSa&oiM<1$jxb5!o_
z+SM92?C^9>4Go(!8eY(`ow^y>G-qBz8F2HvupD&a{_>)-5#-WYOE&7(T~KPh8!B4O
z*>w)!e#jAFGk4cozyn-M)ek}yj?J(E%!enzhhRhaFqBR;*Z09Kur<_N{|xvTWWMe^
z4m-nVVK?|3>;bny=HbqE*atoj`@t9BK=>j&5AJ}Y;7&LOz68g?U2p<?8BT$(KtFsH
zCc@p2X{+-ZOop#RttY$zv*6os4txjBgRE1ScanV!wI1>byas*>m%z{9jc`9)1;2u~
z!LOm#JidXq!vpXRco6;!k<+V3j_Q?6Bka@W7wd{uoS=T51gpV@Q2B8(R6g+Bwb4KC
zrwYm+&%qnLH-}BR=6QId|47)9Yo0?6M#45w`EUl*+DKb?7HkKVAH3hntd+3VX!4~K
zWPQZx3|SX(c)mLr3%f(*2k);j=~={Yw{DwfWw|W&%*sgI=^pQWFy(GEtj;y>e=yIQ
zjfHi%=J{w-z9vAGE1r`!>EnGECVf0lXU@x90F|!EQ0bZiTf+;X^t%S@whN}6(51@l
za{a*YoM2GA3RZ!fy)yM+AyhrM8dihXz#4E7tO>7$C&KGsZOD5Af^{L!vzvV3{Q)Ll
zu7{HU2G|hh!IL5H6)@>p1|_G~xZJkKv_)JNTjP2Fce=-W2aJ6AP;xy4CD+4Hay<g2
zzb#Pp^--wwJ_aSn<52N$g=$xxfQnyb)@`#2+cK3em2H_faVNeFr6>9rqn~%7<aiG%
zAK!<PhoxmB&j;`Xu0Mp*&qq*leGDZB?<q2R_zX&(eXue79IE}``F0~;GQZt+uP`5_
zf7NZ7qqq~R@a&M}I}S>os!;N9M$WWn)uHN74XE_-yu8s1=gdt0oB$7VKMI>>*1Fmr
z{o!zf$<s#OaNSjTOM3HcxwF~aU)blO8wcjUl{0<I+qvh?>h=^KDov#ZDm754fl3Wj
zYT*B)8c<*Ve{TLiBO!4vyXUF@d(HvOWWd$iox?J|HAa2E#&sH#EMT%0b+DRa&g=)~
zCI&Kd{Om*fXXK`3Cge`@XJ?jo7TjmX$=bu!xGM+648vc)+-Xc0?Obz^JC9?mW6S{l
z*H|PLJDs?LW**1$0&d(S-0VgB6Ek>_Vs4H<E0CCxrRNwL@M^45jgg^=E5lt3^!i(`
zW2{fjN9~?;Rpc9+6Q4NK%rWgEiFb~E1Ou^gDG83|*q+Q&8Ry7oP9c41?0P*i$A;;v
zP-ZF3kJe1;%hQ{kUzDe}VXof1x%D{Wmfqs9OORntS$YeR0Uf5LaiXK_^Bm>p-|6U0
z<NAffH_#M~!GWA%31c(IWaQ?gu-Jl;ZndvpmTq+xz|*asPx!;m+fA6>9>2z!whWq2
zhB?~XmcAnu0fupTP}jFWmDyXN#_Q6BEkE|GzWg1}J(V$;f&5uIV{UB5+qgI5Yv#nk
zR@|QmHP5~P#=;As!j(KWk8R$E%d-Y|l4mVcnYhdKH<jNuU+l9D@+WzfcQVYSjXYOD
zjsF)wjrSKqlUCj}qj{*VyFljF=AF;iL8Wy$JPcP6?*HHR+{-$9@V%Lb{8p>#+g}|x
zYt)?ct6#O@{TG=KwZ}$OSw8ORFK-??dgq%Hw=aJ?{qJ)s_vk4;m8Mbyl^UqjK&1vM
zHBhO6N)1$M;9qK>8ty}$|If(Q!~5Fbo|YAul9rNg_sOTQiJd(qS6kWIz>d$%)K4}y
z*+q{}HM{G0lNYnG%|>*5W{N*2IXB&X{NL>TSD9*`0chgv&#dX3#C%IEzV~0+^ZyNa
z{$CH_`{Q$RvQiRqa{}4SV<YP)2U0TwS)q3|uZ*l8pOZ@1@`IHA>>Q4R`_tmnIoqGc
z`FZO`?-Mu?Hxt=2&zO_Vo>pZ2K^eK}oE<k04k(<y{f3t7MsoG(8#T8}k4}lxVxkkJ
zdcC7yNGIl8Y<g66(lU~AQv>c!dba+qcN7fb?|J6$f%L?Tq(G8?8e7_m*Pp2!<3N_=
z(d@6tR9;u=qo_1!54N~I^iGQ_C{r`s^|86C*qDac>evXZzcZ6=US7@mSg+Lhw1lL1
zf9D=aT@pLTL?!fyN{H^1*f~BB)jew3w8Z$B?mc?+=oa6*XHU;*O8V>!S_A4+5+@W=
z*)-N#48fLS>{^Vsjx`He%o&vcp0jwh2R^i3ve8`^nj!%)T0hVlgZ4EqMb-i<tF6Y<
z;<I!7UVTZ=O-;?r$@1s)?3qCm5TBEg)r*Sb^Lx^@os*ax&)<FRJLINkr%X=|B>8kK
zrGx%!*V`w@Z3|tuZ&$v1<WX8(m2wqoeC8XTI^*&e>qCbkSvyQlF?C&Oe9O&`4sLcW
zz-w1*CUyjAjIC1Lu2-6-io-M0bK|qrBuK|f6FJ}|v2D9vUS@Plh)(Dp)3s}KbeA68
zqo;M&W%sD4s6c$@PKiBwB=+v$xr~|CJ*i7Vr*56&6T0+>?%aJ^^t5=gwrgUy?(yAw
z#B}TJYg6bpF|kK{*M#_(_^wGY(Vb%wdUWd&9f(he>D;Yb*Fe{##NIv~6)?K+>4$4n
z2=dq<KF*nH)-Uz!k)H3-T4P<##5`cqsArF2%sHn`h1Z>;6olLq-Rowq*A=?yZu}Ho
zccS&Qev0mO#Z9gHdUog*7M(o(d*_aR#YZ*=a-?(J(>h=Z_u}1$#B@(-IG+4SObx`R
z<5KtZ>=NCDlNHF$P34F3^Il|i#?~aycmYiy**zl_*{4sW-_Nl%_kA>+E;1PyJE6ka
z5Q{m#?~sYnq2Z(?#l}WPj_&)ff?)|zYx?%ASF|b=CJlQA_IzvsX^*2-Fze(cg)S^)
z$1Xa(OOypuM~r?VOubN9_}DEAUVfa?+O!8V{V7R>`4JzIA0wTb^{bE<p_=eC+OwzM
zpW3;oRXS!xAiWB&K?TD*W)&bjm4hsAFTmArTkfkFYlFRnxVDvOyOLPKPYQTFylJi~
z-U1cYJAyCG7+q`qU;7G^(WT0|<n-3wr|576CREOv<U`aS?tY2Nu4!Y#<eZ(6lH_au
zui|e{W%A<p^i)k7HJG!p(v!|6Nly_a^km!k|Eu*h&CSoPuAExamYh0!Q?Dg@IufEM
zGe*<fg=nYQ>!A^tUX-yzhK?LNuJ6eH1O5IEA-^lAL$8h;N1QqKG0MU^@+zG<`!l%#
zWK!N<<jS0+1`QJ`b1nS){wtY_GQ8~m-F~;aJXuu+LS>!c%F4H$O2~Q|vQ7;xhvn*5
z@^vT_vZ69>M4oVchRZm{m67i;8>4ZE%0PW=HDq+k(q|S={T3G3kUTGUj8wJ`L+fp0
z9kRlN%5n;_M3kkkVzNk0wvD!-l=#1J?4oufR7a9wp4*4)cV%dX8#Q<8*Z-i6*@t#Q
z#*)WuivLZkUEX+$X2aA8jkkV54zIuW_8|4pY%f($Iv6!vp=rriCBd)_Xwstb@pQt7
zDxQ{Oc6~)@Ii}Nc$Bv<CnOaI(0^I8rNY734^OC*9-o?^#DP>wFG+$~FpwEsey`jf3
zyR@RT9Mfrq(^3ODDv~d=z438<o0bMZWlTjbi7?ju>-mZ|S}tdd->%~0`H3Ovux+j#
zR~5MO_Cii|8Qrjxa2xwy%i9*ItXyt$uFDW(=TvHQwMQK)S9$X+?NetPnUIgN6q<%b
zQZ}Y3Ryx=G>o9J%6|V~wsMns(i_%cmTnQBw*4_UQmsdtY<?^Yq!!*ZAE}a|o<2ItW
zT*s_<p))6fsBqc6s0_Kbx^ji;tGW{Ouj|`?r>|<n6{@d6Zr$0dMhr6+t9E=8b{uZ=
z|1o10(|TlIoShR$vyX}dvKh7b(=*gW;?(Fx{z@^XfAHE>jVlYAA{<X(Ts@n3%8ej=
zz<$gX2gy^rzRGH2GQO&#^}Ccrrv7dlXv>ezVjM^N=grMj&Ob2e<?J;wsXX;_^%JXu
z$rufR)t@V^O*Q8D)#!(X4IR`eT7=7Hm5?JLsW>yb5lb37?^iryynJxu@!?qUw7^Cq
zOC}!<qo2&ly4V~?>YJGvmyw#1crhnX;%L+Z+1cZG%_?iAS^^vq$VtwyXN2%xnlX7I
z9UVkRtE*|=oyhda9yPKnj@c&to?MygurWTYCsz-ZkFw<&o18I+N1g(yDyaif;-{x)
zWRnZ!>BEj^Jh={6K(3l<a4<fsCs%jm$}3y0amgCr4E5gTYBV<P;><uf`BYr4UFFC%
z%+1GDrO0&-a_uQwF1w7(($)y(cq%x@8kc%{YF54M{PWJbHDg^*#)tLv^c8uZX~%$t
z<ti({15$y$nJL+QM~)p@aT#hKcWfEflp@1-$dFfD2EDU4J}WTREb|SVTQM095st4M
z8N7PjRviJxhxPRE1Ag<1%P^3ZVytQIhU;0XK=!|pBc>cVyyxfEl_E#SmW&~7d+X)L
zpw#TXskE^bDhtxV+;Yl-7q?FXSBwwq>7WyF$CZeCP*xyNas4kTC+?nZy;xI9++Bz}
zvqapqY!mE6wIcOEX<uD|_<iblF+Qx9_O8UAS0etg|2qEsa^m;u;kr`d@1u61c=;po
zeOXzY9k7i;#q(fXIc3k2p{)k{7$4TtK|^FHC?UfDw!H>rWTnOD{G0NhT8<3fcw<W`
zGBiSl2tJq@($ArXf$4fNchV$Isv=Avo`)jYyQ^rKSWu2EUYpQMgG7uE>*=E}vP6}T
zWjGrMHecd0GR<0WMdesujvQXTY%4{M#>f#@QV!E74Naex@o)0w#d2iu@@2RN92g(g
z(?x$|$Sfg)JM6FpRGDM;JS(b?kIRu|q}x{PD@B%5ktMH$EVij0$J^xNI3Jyo9q5~_
zZcH~wM@3}PIOwl(Wb*PT=`;ew_^_USnj%wv37Hi6zpp#Ks%7`1ULF;cB13az*i%A=
z@!5>L0@LEzda(W2$apkT5q+pVjVVVKZ=4g9A}~Izr;mZiQc$WaqY`HDRy~zlwJ8*s
ziSk=fd8U*jkEfg3Efr#Mc}_!~2wsj=yj>~Ypp1ymE}X~M5K8=CIA)e^g5}8K>1K5)
zvUKNORB>4fN1}oLyr(aP;fDLJzkgG=*OViV*Um+rZqwugUS73CH*sO|WYh1aB!v_h
z+*dS@UMxoruMVv*MUK|Ukyl)f;r)jW7?%+uMnz>fQUMt{v?{5KR>+VUF2jiU%%YKK
z#r3eS0y5;6BEuQTkRK+4Y3x;V(FQuHa9%VlXP)Afi5T{pWqeq#OteFWJtbwx2^6a`
z71u>nIdXX8!mXvqaVByU6qjQJ6J5PuGh=SwipM{^0`bSRmKKWZ;Vj~hC_Y~+il3IN
zqUCXF1>)aYO8k1uW>oR`$7B?>78QzL{aQ{r@q2Z$mo^>4(%+f*<HF+~AM)7_+*d>g
zl3`IfGI(wGu2N(;S7o5M3=GWe6rMpx;>^LEb%^J@Q=nq9sO|1m&N$tx7jfF?#`v&a
zy*OLtq4+$(4m|WW5%p$KU9^N-A)QE$DdouF=_IzTLbTsd(V7#*-WiP?v34KHn<q|7
z$>L~B{OtIYRE?JXb_oZ!%AfMq<-Gm3p@eAy!H@1~{aE)>8S(Oy{hF%v$Dxy6$kUzc
zAtrvUvD-5%V{n^-OS#*RyBOSQh#&8|Q<z$B)BdA9@L<>1wDu+I%}v*v6>RfP3A4u5
zu?pWNCG0(6>2)=3(&uhrNX$@U`fG1Ld$8n7DoUHy-qST0!f5SVVHE1XRiDll=x<sY
z^>h*Pr@}R8?E$6-=J=;&+Vl?~?Y&5c_Ko(s>DT(F(l57(@rlVgu!nP#cIixhGVznl
zy)M6NtfH{&I(>P5*5PL=Zf^_mQ&2`cp?coW85bFbyhhLe@OvIQDzNLBUb!k(ju5>x
zQ%uj_P_CtC$*#RM<+pU><+;+jNiq{ZPMsqrzM^Lm<=)kg=cQ0b^0x|q!|*roH>)G%
zkM=T-<!=xECgJa<5P#BBS^l&Z{FUpr4r_VR-2`uq_Drh=ox!SsRXRqYyS(CMRGV%7
z_@pGJtJ(f(Ss7{mGHR*nXf+#T*#CBY*sG)AW!9^sHdvcgUYS*1l~!h@FE3wQABB2W
znxAsZYc1BHm1b`)wyuK}Ee9ygD!V7Nghk~gHG>^&zU-A1&my%+ue)K8l)|Kp<8>F~
zr|h)aHC8XJy-9#qKXuQO*%MZ>Ug4IVr+sRNdemRxUVn{WUB4IdccsO9jx|CDM=;W#
z+V&H%UCF<x_BmG89NgDr+iqqc&##)bm~ot4Ovi26eV*N4Q(PCg=KyMV!~<p^wkEa@
z_Hhc#K0b)fe8fGTRFUQUq3%g(8^2^P#h9~mo(>-+o=me#VB4jJr27b#q&f#o{CcmH
z)$NnG<w!Os5VWgc_83%tRdhK^Y&I4+TAXG!7W|2+@hNF`e?WRZ`9HQUDvZ#y*F4)w
z7@GE%a1%7{OG|qhTLwi*H@dG#+INJdJ%W5Vj8)nfx$=5xf2CyFv)Q}wCwZF}e!gDk
z?p}na{ZTh8g;6Z+Q6<y<9B!h@OnX_|5=DtuxvNOpp9xEQZSvtTR%wrM<?Zd}`|~B!
zo@4e$iavK|ChGnic1XO$6OPiVybrkHDIDGN&c7TkCH-&UW>1;vFTVXzl<JC?_t(PH
zjSTy+O7~t@&dzSS-zu5zIp!EY`!DL_1F1!c_0n4Xur25Et9#zN=hks8(*>(Ku3}%4
z_A~C=Vs$)xYsHjhxi7^8CA0d<Bgmge_?j|LGT})dw$7fXG-L(nRv7W|utc_>SJR~w
z<xQ^ZUhYEWO_rdT>#>S|5q30g@`}k@VjITDtFcfi#+BEe9aP)Ro(0<`e$#}jJyN;N
z!t=D$`03gF);*j#a%&HCcPbofX;0R@$0PfECDL`T?V}?1osD~qF^k-HF6Q3H-^P%x
z**pxP#Yv4xG|kj_icUF@H9Npa#mdqa>dXK;Pw{E|mhRW%cL2K5Vc1n6y4N^vEPvy5
z0@|o@52Ujn?)rO&%!|d}aIWul{i)x@+tJS{92wcBgxO=-xKZACW$ZK8y~0=hYVe&c
zbK|*|8}D6(yQA@lxe%*7)I!<?xbYeHUfWvgHkQdp>An<GEFZ)7>dVW=;<~eA=5Rfa
zVXr?O8Qo5=6yd@*`j2@$!{k#cy55RDVn|S1S6_NpgT@RQ#Amks-LZ%*mpZ&)^(h@s
zcKyh$bnJa6WVr@-m{_cI+!Gtgm?v0F$Aw#TMz7_y&nkZkCyFqr9jOUSU%51C*n|9;
z#MgoAMXo&F82W77PfMkCo1MTSxi`D+^mnCWi+io{PiQ)(m|3a&P6)!+ykt&&$JrL1
z4!hk~;dI#gtPi6m6_))~q#=g*l#X3t>FDgHgJ-<Vyvr-|Kf3PpcctTqdo3B|#(Vc=
z2TeRN1F+Jg(s2fUA`XSNv*bt7*5UssEmKKHP2yBq8k;!mJVoUy+D*%J-VGCaMpg3n
zaox&|u7|kSk~K6v4OL(<!?8-wAZ$C_Obt&@(N^UDAU(DXR-IH?;u*DgqBCVLiZm8r
zqqt5EOJ_Iak$awfD3Q*aT(@$gbgpr)l?J8L>mM_FC?@+pL!~ndJDa+eUo4$uTJi11
z3a9no^fz;em$aMmr}nHNvdF*Pk+6M1WA63gp7-V&wcTDnWA7DqGw82YeV-eKdORNf
zQ}T>n8<W4oNxRDHR#!J(-#r&ORCXkb-$q`nP5RAsFL%;yv+r#`Fpq2L)|<;jsZqkv
z1e!9WvBxF2i8AiJegNH;zKv>htUM{j6plf1NJBH?(HJDgm7@*mRz0}XO-I1)()#D>
zs1+&l_Gu-n<R9<)ll#!JG2|Q@vpQnQaS`@%++>E!Z}$PbEzkcgWg|7wjA{$VBFgik
zdST0k#umEg<+#QL(dZ%)xmA7Vy6N)rb-t?)cl?vWR#&lnz29{&chbu)_xcJ~FC*P~
z<A7cSjtOn+K1Y^);d&{5>$Adox{~<aE|QOD2Tb`LP8xm4q4w{9D`#gn->-7h8RCc2
z#b)o-AJ1}!hNLDS{CZ`e-Ve46%dgVj*u7S|Ld(RWbCq(|t+6T->DYz%i8Ag(%5?E9
z)(WTf-?kTCI{x>x7gg&IL8nQiF_v`2xH|C4&(*G86=!MfLbmH(?xe$2?sa&(uw0!Z
zW*k;J9En|opZstgmcB(?VO^@ugpT!<j@rbfdJ}Trt3IY&Eg|ih$QOmXt*-p--EwuU
zoBmve=S;xO*0p=$)J`T8w%ewB>H3u)>EdVi+8h6PV`cNQX#DlZN*5|#i}4fjW9Ybn
zHnQ0MR<_v^uIQY53E{b~XfyK?>0l}M+=h^6$L;>I+K*MFJ(YzZrN6O}LC<{I_VjxE
zs9y+cM+^OXY47j)lY8Csp3zztOQ4uItkSBr(hl^;Q;VgwXcMWFE$3tAz4BOL_aNLv
zcgvaqg8L+-`o5z1UUp_mx|jK?KNO2%^FZli0lEmrn(vW2$!@y5@(@EDDc(^{79hf+
zE7rEIbp6VY%ELPM`Y4@zX!{cEix3#q38iBQ_D1xWUtC8ew!x287QFF&c>7}JlCkXf
z5U<+Ot*%_&9Az1CGkLcsh(jt3P7BNWXRaT)HD%qszRAshZ>+VTpM2RltJ0?We=BZ+
z1)*iV#Mb&T^IUnS@HFPPA{OnXs15MeYNZ3^vFg9>h2}k8OXfW~$wX%LrHhP=Me7^4
zA$Mvbr>b)@iZuaV9eB!hFL%1<%@Z1{)5HX^l6f9>1#X-$9fWS}|F?N7y{N92xwes!
zo0Z6DQ)5V_UwX+l_dLzm`r?f_lLDNPwx_tslcI5F$o)c(irYt+6<Om@zO==y=IPlP
zJg4a{q^oQ$LjQ+p9EbDwnqhfxv&jRRpUh&*9EIg_l<QvZR4#Me>s4-^c;&Ld%@egp
z$`f7Qj+=eO^CbMJLxszw>YP^wOUo0bvl)?ojEy4h17YdBL+LD9vob}FqF0#ClYX*e
z7r9ee^ZJ$pTHMAA#wuNETGrqu%DDH&D#Ho6#PNv=r>(GWVI?fIZT0#V#4H@cu2nh$
z>C<zP?HuGV>3s(oqme7dO@r6&+~ua3@p|#@2De@vo9_CN+t50;Pm@*5d03@eYPb(K
z!D8tyIxZo-9IK9bZH(64lINt8s-iYVdtZA0sdta;c62W>KGPgLlwZ{^y`(}*)%vMC
zKZIbrk=3*>Zdz0qHFw!SJZbhoi9aD@u0I|>Ub>%h-O5d9y7wxhF`?<cA2)l-NcTkC
z{!h}aavh#--8)vg_mk!qkyYv58<y@(Vd<WO8!z3p+<hUr2~GE^AvnTlTB7{cl2Sfy
ze8u*$iXBfmX1cxp^5oXGkGHcin{OW@`vT%rf7#ZR$;-Egh&L;vXoEtT?a4pNbt^Zz
z=e0irhT;gL@Fag*Y?Y3Ti^Aj&JKkc_Aor!1!uj!P<cuPGAC8j4WPRAmnj3m*#*=lS
z>sD?;b=^#jBqnsc`T%b7ip!dlIyjI%hNpHiSg@{W8Pobt=(>j2ca>b%V4gynY9dP%
zvaAYA*Mmw|PAVIP>3+`N7#X~Dz2Lf)8{PBPD*kfQ6<UVIHbHM@U&U)H%RJt5%rtuA
zQni6BL-6cwcFMc}<;0(Gv3=iD)%reUIDj?f%H7ZL#@=tsA7gKK1Iz}Ycd5ANi@fxW
za{bA@?s<K|A~gyaZgbbZpI}FQ%2=`V@tl?4Y%hj1JvRTU$#Y3#%9+}1nyjPBi_$|V
zuIt0DENyTvSx(1FmNg}0VW#DuokC*0F_w0cjIPU*Cp6tth7&j@Jg$geLdTqvT5-8u
zjfv&h=?*PFyWDs*wXKd-InsBP_7qD~fb)S_sTY$P9Y?TTx{XYA1TUo-qhrP8wHKR4
zSZAp~^*<T=4jCI;EKQoJX$vSl$8UEJjovhtE5(>Nyf#dIoZcNXJK*`0F6<eh_xPJa
z4*$E#fX=LZ;Qn1_vph$c?(+y5gQXZ5`Th#-bbXI|Eq|f<d{Gl1OafMEya=l@lIgwA
z+q~B$WcEcG(WLuMHk)_HO6vjSRhtv`)+N(7=cD6o$e?`8GjZCnu+H-gM%G?byy=17
zk;5tU>MOMGmP1&*5(3jx(u?j(C+0q@ulBC(L!t@$X>47>f7%US=fMu){>_%8ll#(#
zXT7}NHHtrAHewrKS7W7@{9<{}j4ee+GHfp4#N>Tj{U~X!U`vp5COyr#qY*Jm4$1uy
z>CDZTX6FBTSJ0<iEAP$v2k*mUR!ua8=jF{fPwy!D9Cyj&2ldwYRhss@e!YVmwn#E=
zcc0BrS@^{*3v#RLF76o_#Vb8{>j;PAY$Bv1l?~N{-VCtz6)PK|-I~gAXz8%}AiGL4
zZr^F=ly?xWcgRF<_R_d*H+irR87AQSa9G(Gimc&fL*u!W4yBh3b3d$X#1Zz#*fR;g
zxx448F{H}aFv9l^zIkOsy6WM&^Ui}c;rZG5WNhZ2(w%#nN|TUm$N8CXeOUXhH2V&<
zwkI;?;GP+$!maLijH38$-&1CvpKn{Q`1{^ZKF+@9y%A*k=9~f*{#2}e_m_Ehx+8xl
zaBmz|=0&2{7UmA9I`$GA0Cz!k53fM!_f?n#Ux(WJeiLTGx1i#YeD+;W_8m}r8WorC
zwW{{JVXwpU<qvxP>^qF?cq=?zzma~m<42(Sj(<Y*5oMl5`}h9ryMXK&jPUr5LvM;t
z-+wv_>bp*!oc7&3_Wd{E{@S_zI>I{mJ3GXmeLv2>_h;W#^Y8uH_s7_GxrEC(&z19X
zSRXlqA#z5z`c(O;s6QWW_tDd;%r?U+-$Tpq8*V<!oqhL-);S12ten5@=BwP<_llGr
z-kTxe*>`r>_BTAd(0XIvl|j9C<E;uKu`+U}e0KPbKo|E~`R&7QbJNw7-({ss<=(z8
z!oEjBa)gGzoA6cNUW2E?&~)1OIoS7Ngop2?a|nL&&3SVB-UWrPv6|8%qwlt<?bUbM
z6#nC|Gkg+iDD*T`SM?0^%CUVPfj!e0F7IB7gv$R1P~m>))^8ubGtC)$tDA6r>w9;e
z-tsHxF0X>__EgYardxg`YkBhJRnT321>Hrt`E#sz<0|Mbvx4sOD(G%c1=CSbL3a`6
zxxHhTgQyC+i>si!%nG{8tDw953cA}<L3afebQfWsSE_*iD(Eh*g6{Gv=q|H@?(!?>
zZchc>6;#k&L<QS}s0zA^tDw7r3c8D^K)swq8)cu*vFoC0uhibE&6YWh_EgtC*b<%&
z)vmXKF|ak%9;Lp+s`KLd{%T*S@2{#IUW2vI!*I5h4q4%=zh91(>5DssKLDNq2SbLm
z&QPfEheOSwN5VmHJiHK2fQfJtyb<bqsVku$GIn$lAY(;m2K)_Xz`x-v$Twk~T-XuL
zhLST6Yo8}!eC*1}5LMs#G3Kz_5B&<&XCHy>;U7@)61Mps5sy-uevU`Tg5$Yg12V+c
zcaeg3!dmcd*Z{r&^*!95;K`7oxziZ_15bsLYY5gpt6|@xEB%G`yPa^SYjkV+-7fGn
zuDilkFa}D#9#G*azwL7n%wzZ+p5LF44u$tA)cEK#=!2ib*6>@Xx%c-l9Tvb$NE%G|
z8i&|t6YMh!yXeHLa?cy*{Dd6p*MEj2#rcmbR~*0Xa|T7_@ObVGz{(tDe5i6lU_pj<
z&T;T;T{B+Nyg}DJVRfi-SOY4(3fG?DFFo9oaHnt^LWSE1hK8$ag?lPgxJ{rJu00=L
zdblUxPT`&i6>e=98m_JtZat`QBcK<qJ$GJuxXp2=a9coy>w}@;>RREpf(kbhdg0nL
z-uC>J@;y|)`VO$d)pvju?oxOflzx@(x^54bLB)3y^uo1gvF#b{@Nn1QPT{VF3im$9
zQmqMhlzXi;osHaI1n-Alxb}RoJvSU4?hf23+?`P2?t&@@l9!`E<~kO>%6;u?yaBy%
z?U`8GJ?@8x`xfpL?t4(-?uG53!d1F;9S!vzVCnf2=!I*~sM<0c9_~KeDct=~;eHK6
z!_~FIJqXp_eFwd8?U~Wi!~Fqw3Rm?>;U0#e;p$r9YW}Kle}`VU_Uxu@>%-;!3wH|F
zq24K6%|}D$C%RVqtnU%4UDkJqy>RVWNqdGeJlqDjQ@AHVg{$>~zEJud>|U$yY0UjB
zcq;V5wdVv&FTc%jr*NA?g?kzdEx)=}`8^#fA6r2$Tzh_xb57h3m-kHEDclZF;c8wT
zTF!JG%l%GJ?P6!>g=^2hm7Z^1ai?&*L4_LwL-S47%C~c%@~s#2!nJ41irVkcdOQes
z3U@G6xI^K&Q2OofUJrr8xv%zn1oXnS=dJ9TOt>D#;!fd?g9>*73@s13R(Uudj)WIL
zFI;<e$?g$_hdUK_3O61q+(Z}}uC5jCG^lh;hhDh$oRDqf!^2I-ox<gN*CyOqQ2n6v
z&>iSnbJrX=4CX>FTzj^LF$ed<!<~yeg?llSyqCbxeABh^P3sy%;C$$XYtOaV^Dg1x
z-iAAcyBaFoJ78!z({(KO*TQk|F6f18&x+8`aX&oVCAd?#OQFKO0S<-IgW6wRE4*cJ
z9=r*9;o9>K_FPtYxa)DJa5q4Odp``#H(e{=9)#+{H$yL6d)~mFLkJJ|G2AKK$DzV~
z0*2<Bu9a_3L$w>vKrdXopKtfO!^7QyJB7OwD%@Q#RKL28<^HR1AlwbTaP5A1>EXVE
zJB9l$RJiZM&~SAf%l!|b!u<$(;oAM^qV=HAdi)*k6z(CYaQ_#3Zvt1-_x+7uE-H~C
z8iXrRBF%F&P>N6~Nzr&qX&zKG4@#6$L`q62WGKm0h>%Je%%ThpDybCpX?oV)_g*gF
z==%IT|L^nspZ3e~zUQ>g+Iz3H_Pq8!ZGiN4hVGG_bpXl$b^;>4ns8CpiK**`(9YBM
z7rTKD@%;jb`1SzO*OTa82%h%?($Yy;%N@S_z5zPK?=2wW_a2bm4$wWagGNA9ewzSk
zd?{<G!{=WR`YnjB5Fp|!3`n1UbdT~c0*Laz1n^t_scW9dZjc?&=U*J?(7gm8{D~k9
zxByTVP#91i5T#!M5b;C(S;{&jWz7)rqwmiy1v<oU86ZEPGTnQWHO1lIGoZe=f%={y
z^}PV#L0KcD>={AvO@?RgaG{_9bg2Kl5)h>yzA=lxN2&$L3HPf2(fr$Lz}bM>fM^`B
z1`z3WEg;I@IzS0P9Y9nc>H?y2r3Z-eeF!ef`XOaK1*L->p6!JTg-t+*^kWQ&o|^z7
zJ#7Kx1vCdl@uGSL=?&eZcGm(Bl@BXGc|aRLRF1a-qW0eo5VijffTn=xeKPfaE1)Ah
zN9jZTddk`#Wla#JkG}lmLUoAJcM*^TcnMGs@Cx82z^i~Jfcb!^-7Ww`d~d=<Sv#Yw
zsUg18;TiD5!3E-<3cp+dQ9j)ONq`=J0)SqCivhg>B>>^ur`SII0F~h$<p<RR=pL<W
z_yg(!1_BxYh5(uYh64HmBKlzJeFR__JdXm506Yk|7cc>EA7CP2G$6`{GhCGQFUoI}
z4_0`F`Zy@ug#04;+yX@UD*{CJa}RJi;C(=pJ{Us>tOtAmi1bkbi1bheXb1QR&>rwH
zU>9IC2*C{sJc-yJeA4$-%E@=ZJ0@P8HfO#E`;OL+i(kE+nsue8H$7c`C-lJ}A`(&m
zuF9^-vn4)u8U#OZ?(#X5u$%RA?Y4$4F3y-2#?Hb}I9Z?rL?W)9tXL@5d^+;}E0r7B
zEZu`?rBx;8_CHb3{xUJDrjJbl(t_h{spvjz%@o<3CG+?|+p4`{_pGlinH&Bl_qaut
zQ;lC4q;VsT_w?BZJ97j=cCC$>o;xZ1lb`dzEhpKaNc{`q!kO*0OSplKgyL;`e8sIV
zTeZEiMmfLpL%BooS3jY$8FLe#v-Diu*nj#7$QLS55;2f@P?_bh*_d@Ql{qieHU$TL
zcqac^%ClucN1#x`gwSH}8O8AqIvZ>B<leo@X>b3Jl7D2d>cORTLC=ZyzA>xMq`cOP
zCJ?Se+z_vmBzNhPr1Pn)eIL!*nI=0P$yR4mzy8MiYDRR!ENK_0`!U^~0bZ{%vAk-f
z@ONK$-)32DEw3|k(`$=l*_JMAyheo&<{F@aBoVh(g+vn0N(zbQki(}0T6bQoF?+CM
z!Ar7$PI~T|6>S_)MsWI$h;4AFiTyaktN!Xtj$L*~XO`C2v&?XwzKpYES=?fw5~!Ev
zBYxi7_!k7kM>FjXxx%9_61cZfHM)v}l_NR!R>tk{MVsrPP66GKh}<Q5<7ODf1n0{n
zPK+`z;(Tf1;mKqiYs95|H(%Yzzzo(R<|4XAnKYMvzn;Nc<u&`~m9=fk{kmyznuhI#
zbF2Ec)CW00CDDZWb=Jj%@GTn@<@RqR9_zL!YtSzVYS=3!bLhO|UH>D;pi+_GLHr`_
zK0S4H&{$#1#?Qx{T~(gvy@*U>^2(1fEZKYPA#>q4Fj%k|67lZZ$X=)M{;%`Lxfg6V
zX;XOP`)<{uIrl5$jojvTR=$Ty$qw`Lb-7fhd;iXo@`Htq`x*~l>nAqmkV<zqh41u9
zVe3c(ehpZD!CVHrU+NZl@V_eeESa0Z7iO)-Ut9LpjM>#=OTwiTNFUz{6t9Z2^|aWo
zNZD`}qkUvmJEnVyOpB^coNt`BTu)zqjUN=eek_-@?`PyxtyO<`r`n|cf~I8NYN>$)
z`2#-IPYqbURA26Og}DW&h)6^WzOj0lnc{)c`-@I);Z|6(qkc<Y!On<hyUzKByY#Qo
zfwlwF&6zFtaL4I3wQHTk>us!wujTod6RcJgRDE2z!9iMItq0l;oIY~sx-~8?vrh26
z+wE|JccVtNtLBT=#Agc{-CC~4rQ}Y4IX`IdNW|vG4;*ie#<uZ(3CT1PpP#PDX0IUD
z)|V`z#j=niJKPi6U$8+E@nPmW3x}&5TMx%S>wjXrxvwk#Q)FGz)Avn*+mkda$*DjC
z19uW}`u2fbww(F3-BP<>iauVVdheP*N5kCrCruXnuX3Fc2bG);PM;Rbx(d_c>_gIO
zxsPTrSw}q?Y)+ZN7v60+g=f;!!sG)`H)4Jr+75}~4etHg=IlxmcbxSvP0h*5h-nkH
zXxgG`DxU$3<Q2?sdFsRZn$%Zo?6mq%cs1N>7gBa%y0T2ZMIx$-FsDM)fj}t4{FLYT
zwf$4&ygy8<I6;^cS9bez_`>XGh4Ej?-GiH}grM<i!u;gVNYw<ciJrC4Z<^Q@S;PE%
zo@S!fG{YnLlJ7Pxe*abj)+Yr}ehZC^S}cXncls_WRov?KK*+7&v30bqN>Z$2Z){C=
zAym?{l@Oitn<by_sQ6#F?mhQeO+`(&QAbsCoSo|V^Fk}yd=y=wk*dM`JgnNjY#w6%
zG|g0OJ!fOWvC{Ae?~?>yeUEu+_kFh<gK`uEc_tCnnbPZux@PfYPM*FzSeZ8|T5#v>
z?JH&qdWBpYr}%btI<yIx?ut#;j#a_BHpX}7r0g>0iMp;}XeGT^p6q$JtWCdT#s~OT
z2(JJ5^Cp~6W3f0OxTvI|Us`G1^yEpk_gPJO6I>RF4(VKk#_s{9+gr%ldf2!nV)MEw
zYpoYb>^dH5?c9?b8lET`c({jH4*I=@%XxDCleS3f@=pO?9W(NZQarY&-^w7S?flY|
zJl-aLQvfuEQ*b>bUgI*9k>s(=NBXqriCcE@7XG^T{j^?H-Y2l?Ts@Hu@;i#-ts~rO
zY+D%1^J&gj^}FWfz3T!wUo<^Fc73sMvc36-<<PLbkVbMTu1OGx&p$gcI;4ez)VaYd
z-Q(T??|3o3bz}UCw4?XwL;a_Y=(yrlpXw{HHyE%;KG5A%$T?@GortTfjCVelrC;y0
z6lf5S;q+-}YpSblsN=PY@_bj_?Rh`FfUv%B$Bb*P)%+nxR=GLB8YiY>E=XKx@?q#j
z3Ae%2)C=6X&VuLX8s_e2R}=eGJhv|uY)>B72lYK;JB8BTpL>zR9Jl6!(rShJ3cZ#&
z86x}4UNFtO^YIz<MR5A8_}|Q}d(`-*a?hC<X3=N2PF=io`<y88(~{*^F3cdW1iBVM
zl#laz<Guv0nYGg=V`1(r)%_LkJ^4E<Ze~~W_r~2gsB_K|#&($BvyeG;mE$M#UO%8Y
zN7CTzMCXVJ`WLIZS5=;J<xt(R>MP7W2_b&B>SJu`9es~Ay!c|W`oJ!)S`F2sr=O>=
zg(;^W-xoLs>Z`fXAtVv!Tuj?#Rm2k$=i(ES8p?Liy+naGc<Bo#>8_JQ)?yNV1VS)Q
zpO`+|h0UkD@1>U>8XqTCtI4+OqSmEDV^<1AW~K)4zM2Jd)i{007xRz4oToQkGC|Zw
zCnw&i`_b~$sJ8LmQ&$LgcLWzf=O+jTAS9w*Qn^df!KXXfSBHk#lb=0ln6=}h$kEkS
zg=08l1~xdc!yGV_O%kzhdxy+jn~2gAA=?a>Ex2!D+<l$>Sm6Hl`SXXgbjfbnVE4j^
z&UAxw53{rMCy$%nEI}$QqBrXo-!wCS5;Wv_QdCC5=MePSFx^6pn2l3+c$^EXV%s{P
zRNT}z)lI$b!%5HmndbBFTwM<xu^Q-zL%ggHwC|oHmDen-8C&q`=?9b7TV9)(tooEe
zauyc$FxUZocbq;$AJvJTFV{U(u5dPB+w3ROkRg#bH{WF4$KI@CnU|#RKz=dZDJgF$
z<CRRcmXl6dzHcEn-Q_h%F<h)W=1t~B+0NXnjWB0}>+#UCX&;@14zfP&^@-`-b1=wQ
zqw8|MoZUxJVY?$`*HwaHTq%Ll_q?UTvRz<lC4Z}A^bGULvs~+q&RiRlJUP(x%Gic4
zT<@X(jN{#?NUBL16dP2klvrAJ(*A2s@|~n1-m~|PUb&DbsBsta>u7@b&3$y>#+Abp
zS<YRrou?&x@}{DC$i(g$vm2(Lm---m$+I8kE^)lKyY<>Tw-e4B=6!VeLK6SDJmXdU
z?Ng=4wJ-CUuF>8OdYcJtHHr8xYtN~ulGtj|iAs)Z-Uxq<{=DD*f#jj%OZ>*&GCZNz
z4PzoqXZk2jc|+xy9rxJ}=zN({DbQK4Y-!fxt?kX)Zw`Bw7=tbE#B`J6tOyV0)v(Vo
znH$`2UHO*5()^bxx$al)FI74<dHTuYFa`yO4H8kIL`gh(%o)z~!nGeGKcAa))+1_d
zSAX)u?N7Lt@Ur~_o%vIkU#GLk+vm#{JuB$c=-t8@*2W!lXx6#|RiVVQgRP?1vKGJ`
z0j3Lb>T@LQx>)2`Tu<_;7<@M4l98$1^W#q9D@{uGwH*SRkDG_$y=Qkh-I7;g+4=0G
zw$(2x?|j{ytt8Twz#rpjJ^0L68S48<nuzZ9t^QL?uFIIZ#`3VU#J+Y|A>R37L#}Xj
zQ-0f&h&jF9FxRjI(edS0?3f!>q~tA~E1qqx(LZJB!bggg`#TmIjh|&v6ln-^fP#oF
zXvyoO2D_bdN)=h<<I1_lv}(RjTBvs=m_JE;a^O7T6qvij@m^K@%zse*(Y^!0x+a(Q
zR^;rnEs5ebkJ352BF#(Gyd@dh8F9ofeijdthJ2~awAHyx+e<|Qeb$#&Y<AzHr?JnF
zN8(zU7K}}C{h~R~qK0`a(WPzDoMc<MWBskJH}!;8UXY!j)_i5aY0w$Q$~fMAuPh_&
zWVNDZp3u>#|GN9}^SHI{)1!CC&XP9T5O1p92Xj)G?uf|4YXZFy0qS=g#3Z~q59n3Q
zt6EpWwJ%TLjjp<C;4xSm0-cbEgktwAfhht@-nZPEZTG>>_US2SYmuNypZZQeYz{p_
z1iP=t{ALW!@$b7`Ah}lO*rcLrvPFX98iJWt;n;#bkCZ0xL_*o%hrE!8IR|u_HnLbm
zy|vcXow!!;sD)&~LCY-m-nr9#@2rlGH6jp_<q%ySe~xxRrdo=dZP@3%Ni90t>v`L`
zEt%C)1g{swjAL?ydJ^{!+B5aCuIsaJN==x#jU{-jPf=^}fldYPxd+Tu2HJL~Nx>Ks
z*SncYqRCSmPqLnTUSw5I=-W9-mM8y9-V~NFnQ+&cSIZ%<*;v1u>s~~c1eh$myg;U+
zaI&x;dy;=;#sZ_j(!4Vqm&-o@-5JcUlsAHWT=ihIn83r!=fy=nez`8qZo(cY*Z;-Y
zRa1H;lsA5ua3B%A28><Oj+G_yactSv8I-3m`$D>=EO*Mv!?zq1&WUzThISw8H*)(l
z)2=Zpcb}|csdRfI==AA|oyZj?#Z5U*^Czv8>^%%)aa?Z{2iow4a}`R;8BYn|oR>&6
zn0upjU&0M_O;1&uV690oD6Pinn|(6%ov>5qp)=m&%qQJr7b-cK?JA#On0RvH)X6h>
zTc<+51gGy(nfv%Xa(kjUm@Y(Xyk7S%=v0np`+~uU_m1)DE}<!>U|fOg@l%exr0KVc
zl-nJKUhJE8e0(}{+`ju+`vb4e-!?yR;c~EN9jxDR4KI&<syaC9^Uf6R#^!du<j<UG
zj{MU%H)kvsSoQvG2GHUDmEz}8{ov&*BMKB71vl3<Y3IE$S5Ff&h*R1q{`SHtyIs)V
z#pUwZ*Q10x&qY(Ew?4RU6`s+-bTMf9;=IjbS=I~2@XQiwfc6NFS3e46o+Ni|>En`G
z`0DcUV8yy?dwDW<TrddA5MLIU9Si-O8ca8L>a0um<tB9RtX5+qoQM^&6jfv!kapO|
zDl8}v`Z5C2X9N>A&_CtgSh0YxtNsLE`%MvP$(B}!wRfi}aUb;Evv)8^yek^oH%#~5
z%Y3`=YTeYWi4ljrBY6F`N*cJ;DTVs!>$;vlaHkk_QHbdpO-yP9RGeRxUoGB0`BB-y
z+e_Kz4)hfZXxx<5()kb)26K{_?ucW7|D_9}jm_JX8l8L=e2lXW;uA3Mb8+5r>usDp
z6WG8E++L<nX6t_V!NGEsYFk3Qdm^U`xrc0D`*Cx(;w|lnm&l7g9rv5EdTtvyx+{Fp
z`naL(oZ7~mpof_f)mLQ1Y_g4x8)jD~z?>J>+uG&gdSiLi?DToIN(9}imuGAG^3tcH
zYxzy7ru~-#?=pj&7bCgM`tV@R=j`|8Cw<7KzFB5mwv|o3e6bgFI~<gCTc_JL!CXFW
zSDEf`NWW+*u!z<t<bJJOzO|+L;>-$ztJ15BJoWoeRX{l}#&i)6>+T&_ShMNvd}SA#
z-bHM#k<Gh$BzBj7cpO}0%w-Jad@8Oduk|R%S3Q$dn={ncQ<oFKpU!UHZ2ncNU#Dk>
zb<^Gq=;L%_eqSo~hXe%iC)tqtG&U+6FgDub-o?LaU7F;E0r$`aj~Bt5DsDek6wJKH
z-6(dIwNAZj)k^7IN14AqUUk`IVUV*Y^VI&K00QA1o<CUmIbL`w$Gh|_iR^u6d4txR
z53BLLV^OL1q3raLh5l#T!N&pHY5g|0PgyyqE*M$Nj?d%^x>W1ZZFsh5@0oM*gLOyT
zqM=`6isOCk8Z+IX!HTQdJ&);m#<oulD#?D^!a8pGJZRC#(MsfmIVP-+xhco<vRNBg
zSNa_6UvZ1Ajrq}438xLq9~DUl&Qg$2UjuWlST1{|lSGDguhDl}R$et2XIYyTw0h`n
z@x9p(_O-Py@jDAPP=@2x^?jBvJM~F?LP=T6<??g6ii?f8CjPVZ)zZlMvv(HRs6e}g
z$59!{&c_#rCEqg)u~*X~gaqncSZ^>(^ApnsF1fjTqt88u`4UVQR8ZzsaC-VOVbu&_
zIWy8s$y0gn9Y`*5CGD{bx^^zyM<8sQkL;yskKhc>+T4<Wht3{5hSZEzcP<Q_p5)rO
z`oQY9yK_uo@@yB>sU+gHb6RD_!3u(*I%^AGnFowbeS7syvG*t5SGqw(;zzUnVNM$N
zhkV?p*6N7nHOo&r`1F3y_|#Mmvm*yC59GR!SNXd8c~Lp6f#P~RhqZ8?3kORCo3n51
zH3!0Oj$J#S%O>)8M!%c)OxD}^68I>rLh&9>nD3K4Z;F$&xj#pvnC;;$u{&>Z-A&nH
zOtL>1)S;;dbIq8}$+34=cUSLCu{mRm*SW6lakoz@^*?_^MkrJH`o4rfs81tt`uY^k
zev(+dnNU8_?hV)2n%jl1$^T4bFFBPfxh=l>Ojj(7YjJ&_XqNvdEacON@|Fria*=`1
z>(s}*YrI}LpQ$)oPZ&4-KJ>$Iyc_RkWz@B?igOHFF83BqmidR7*U^7Pir@yz6>7|0
z>!F>wgy~+TIy^LgJkMWoiOB_tV79~4$X|JLkN2b+rH9(zQhh~)c^XV-?&<hh?t&;&
ziJ0Y8*~cQ=1y4=vnX#a};RU<R=VzPEpl+VE8p-A2v8(0vIqMTx(mpR)w6Qouga7JL
zhevNZpFVcJU3z&;D$J>4x)sHa39ntwh78IVy)(aJ8n*Il?={U#^>h1jMGW_T@!CWn
z_+mP_d$ZE+l;rExDj$n%+PHkP@x{~cTVk2hnR`BSl<=WG#5qj&+<33Zd^4$kVy||*
zc9LjWc1-ZzO_wDuHm6oP&aCk7S_r;5n2u9A!u$FXi<29J43m`0tn_OvxE}{M<{eNH
z&|M)O*Wv=}2QVi=A}V!F;#(7)vVL04^IlhvW7oa59eH*vy=eTzp64;sl#W_L`zD6y
z>UxiwF6U9Rod4>^Du=c67DjzM!aU)V)<^pTXOdbQCkMgYJf@Qw7<X0n)I$~R%S(o?
z9N#5%aqM9yri3wb&o=AEbax3r|7t0Ych>a5?y^04;+fK?;)!=$ch8rfHffn;-8J(~
z;rBWZA2|Z$1Jf<P7b#kJIqK*xfln0*{wfQ4?o2A5vEgZ1sMo|^Wjk&rI2!=dncloR
zYmn9IV?oW<Dy<`p)p|Nk`&qlqyUS<3$jI8I&;ffzpszzB#)+^7wD@v6evs~OnxOsQ
zL9>F^g(GFeZawBpxBZ0Ty<t3!>1MlW&ss3Qkta=mhvPb{9pRAyYZec7w<&}ci}R?>
zN(6o(*iJX@k_x+-!BH~t^VElZ?}zT5IAJqkp2?MzEwRs^9PD(4K3EForxf-ws-@=b
zOpX)zEGr(@*0Vj>Q^KsMY)sY{obAtgZ#t|k;rWOqO9XX|2Q>twyZK4{_2+6r(x<Q}
zhn;!rd-+^RGifoD%c;^RABWz_l6qVBy?(}gI<AA`vgBsg)B%2t^fRXwPA{%AAVNJP
zg4^>xckgHxzP*lXpXENxWvg6!rrKlWbQvb~qe-v7@>zWxf^vlUk&b!~T)V*H;?8E2
z^FqXa*IOU9q>4ptiTQKgoC*XMoPqf|++O;{C`hWb#Y!4w9DR5v)2&#h??`Bp!Thhj
zn$M0_rS^fnT*U1H(O}0A@yVRi`Dw-JX9Z4vGS{Bl>lnJqMqyX=atDRrJXnKUgz`Zy
ztFRrElIF>1op7k^+$JYtc*i+z)&oa^T%s2pQaXPa#(B6N*SNAl`fG>#fP=jFHrHeg
zwo7Br7fd?6n!qzq%%US+xRXFoTa5UP8!w%mV76ebX+!)RpKPTY0@t}tx1EZ3F!%ks
z&Ax+?&<1AUcv&^hk@q&&l|BBlKFT_4y1&SEOL-=*(zugZ-16kD`nj+MgzGE0p*>fw
z`}~vSZN4~XW&e<@PjlK5L+gsrodF)1d>)5tU|j>pd-5Uk^$@0%gY2pTkI%dniz2OE
zSv`Nz1L3O4Q|8KsEVY377u+x5pOxfVkj1&yK4Ia5OxArl>0h7RER49`u_<=*y}1h~
zwL*Q0>GpSU4+L1f95P;2Fh$+z?%sIU8<z39%YrP8ZdM;m7wU&~H#`oQUzwPEcz=v^
zW5<QPo?M4sc8xjfN6?8(Rxp%$5iflL<eY)|J(lTPYE;-ZH)awi(@o=J>$8*^q#Glm
z-zu>@_T1RrR{{Q1c)S``XgTqQZ_!6@ug;>ESzX*;@_V(fXuS0-b=C1?eWXSJ|1%tK
z54%~F->f5M)@AKly^C3U$3FLew#MRmzYmc=$+EuSHuxf7eibh4jb9HXw0&)R>T9}j
z-Li%$o#h+zd1co)Pv_;%Jz)iFN!mznLy2FK>b>)H7j=hCE8od)czbVyo*!FT@|Dge
z&1)}iDT9v{<`>M(WbN6Py8V6J$J+^~3g;9YxyzSYy)AD~O<9#$>jzKhZ$R4*<D+Hw
z`Rt~gcIS;*;3v1`rP^TIs+l|z&7yit+-x4qH(?%07SpX97dt`SsMz}K^+bgUG0g`y
z88=p6-<_Xz!#_Z(XGzQkSZ9(){1UI1Monn2^A^6FtuL<ns=@5aoq1aXv?tx2SW=xu
zcnNlIjrj%lgz26*bjY8hcjx}l)pqYwLqvkj*4~Md3#%0+GQXSxa=~<)*EINFczA;S
z;n8I}{flJO>kQd;j}v-M7<+S2Q@ToC2gdu@PB)uZ<hiYF4_+)bL6gu_F;jVJRgyq)
zb^+6c)_0eLW1-GX!}acmkhc>82bMM}y;*fW$s@^l-8tgdCw5+DBB@#XrE=DE!MF#<
z`}FHfDWhxEZmx-KI`s`#eOY(5eRZt&3yQYAO`bfq1=^!2Yf*mr>oeIt+(}>E9s1gk
zhi6N{dZ|@0>rSzJ+Esd))L|6@<wFD04f<FT{j*A|N^dng+z(6(tcqS;81Y)iKY8w9
z4O>CKEihii_0Y!sMw73fbcp8K_9WjXPWwQwUzE)Wu6IYD_j#2KNWY&9J|VasvSa_y
zu4BC0LE7PvgAHHo5&!dMq^a*M#n*kkQNb;|3+hN;9IvDBaT9&EB9Apu)2z3#a`h->
zyBF0~Yxgpd$zSK0cfW)ED9{#?h_7;c(sDB{OkUSvB(K`N-`mW7d*1VnE!twO_iB#K
zN{04hx&op*AW}Lz{EOh4b<L-)Y07grO!kX#S+A|@n-uk2SYw=jI;`PhJGjd>&CkCl
zH0bLRok92Lb%t&_BK*l-^VVi6Tw4(SrRgl3mx}2Gqt`~W$hjv@O{;8FJ@?p(C&Dmw
zr9k1UYWr$2et}x()74_Sp(AZk^_NZsHh)c+eVQ${Ky3S%CSS#X3}t~sYZDLfnL~NQ
z^{J0CIr-3q4)+N0)lXC>Y+O3VDps;i^@#PnMeD3C^cYWq@gSzltouUX^IEO&d@xtr
z{Q0(xcigOt+=3Tp<}`1v+vu6=4C6d(FNgAk@ARp~9OUC^?Jmq|P|cO?9Y@mdNOvq4
znB3yhngZi#Ea&_c3zRxk7PfCvuA6zr+^uO6(~binhY#OSjb%$!p5+Yv_Es2kk%+Z(
znS9hdojhY@cki56k$3B8iWqCSog2Gk`GybEECRe>T@v%N8Ju<E<~#+vPF<IcQlb`l
z{i)%aUDFLOShRFho)>0<abBAu;^!23^5xc)bu0aXSjV$e&FoOW>N{VqZcQZ9>{VfE
zrs5~yyjWa53euS>*DX;QyHra1%JS0Z5uFZAY5s~+OtWm)kmkGaLObn?>Grw5)!%Iv
zcRYNpt;c}C1uZ!ZT@`Yd?*i-E^$(iWFE@kz;d=aoo@$AWMd;wI%F`}A%{SuC)s}he
zS@-CU&}&=cpp8aQpUz!}(szltlC4NIjcb}iSjAQ~k@URMuO~%Zj#~KMZ819HX9RYo
zErRH@vV{)iE_%4WzNgQl;U({8<-Q%s@@sW!C3Wk9)~wnC6)HMQ4XwM}&^k6wc2XUe
zO<8hve`xtTQSS%g(dX?SpN<@VWd$?L3*dOi9;&K&P<DC`(?1ffw+wZUzYSj9)TOWW
z#K1YTEkd+q2l!_!LHz8lZg0NUYT@_dW%}ubVr!0ycC{p>kOu-!vY3R<QQ0&GeDr4`
zx=G9$%K4k-W$s#HXnRyt>=oyOrMYP=#P|It<%JF7M8KZ&Fu%mFAKu)*XyPM1J8Wpv
zp?4N}LoaptBw0=;c5Smb|Dqi7aT@2N@t-cP&lR<`1G<5V4~zv`>tBX0RSADnI)g9A
ze{m6K1o#VKyJvni6xtflv1s~M*=yzN4#oux9(yOu{NlAwp<Q_?^ZrWkrNI4-*Khp=
zr(S7XoDrd-Ddo1FSh?-x+~QLTud*^;mhfAvLm8hVit=%IAh1_MRj1q5^7gfJrw;Tg
z2K(^ysmV6HJDj<N(3}i$p2qY1eO|uR4qxZ%>RcQrYwZ>8uX?BA<r((=`Aq7|b~dZA
z1b|Nx&WA<7dR?u%Gwn8Hcd%TSnIrH>D&s_1;qKWS6~fz=2E2!H4>#twB_@EcjVs&Z
zczoH0A!cu;;79#0iyw<NUUN4u`$r}r6y`-SU00m-ac+<5RgNZOKaY7fbB9-_$(5C#
zpENYP2w&KcyEqEUCGICSt+?lEujc0Pb%pu`OWm3=Z;zC<`5HEp_IZBcO}mvH1M5+k
zpHHA%?y|9A0(AqNif<EDUK?-FIbPS}w!vE1^W_<C8yIh?;QBP`?AL2Nq1_=(V)~X^
z%cc4aPCa%wRDaY>Lr|$TtA`irdkJnNzcV%$cok#HZ|s|L;(Vd6zH<17?j1!L4<_GU
zefa9b`j7j-UlrGr5{73Yx|KGvTwk-9>*JJxJzDCslm!b1-2DgM)n#N(4~F?fY^S$R
zmk!z}7N4tSa%!KgqCphdUmTQ^=l<j{YdUwcm@ky0XdJJnromyw?8$M59!4f4o)zJA
z?GxH18}NiPwCTmYO^fZIe_(;>LIOfKUvvg;H=S)7wzE3RbL=DT;K<}u_wlpuobWml
zT0kIV;q=Kzb@d4DnEi6&d%i6}l1(*@?&|zkqYfoSuZ=y-J73!c)?qQ7>r-~^kPwY=
zZtEM#>8fu67OAt}%g_pKd>$`0uFFg`3w)z+J@jFgZ`&IFl8`8I_Ov^u5^rK6i^(fv
zm+!V~O~_l{rppffD;^}jb|u9uaa&`~^>+lAKk$8O(aQ^c^kCfByrDkT@}z@{pf1Sg
zMRX(gn_ggkBkL^*m)||I`-?56f0bE2$gw8#k$+01N9)t76-#Cl7VU`*c`6V6rZP-7
zvORys=^ME|Q07DVu)I4jQ?O&~4c##bDPJzFIP)m@f%QiLudyE#H|N{!s0I70z;t<M
zr&<}-Y7R;6-5zG%A<^jCBYm)uXUzFW!uD4<j~GDTZ{sY)kMj{Z^UK&yd2M}zFaA^G
zH}vZnFF2DZcDVY>^W`OdI#8cp#&i!=$^AE%M;a`#7YQDB^dc*7Kv${X&SK}65eq-W
zx1MYP{|Fqf^BIl>1Vw#!rOTB`VhxdbHT|n=Z_FcdO3P$hH(Z?q^9=N19NcUojNw4f
ztQ1U~+)Uu$0uwJe893<K1U?<HjqD0v!ZxvVb$2uIfd5V0TrExDV-x5nK0?9K+}^~?
z!5zJZUa^&wlQDslJGQwkfhXwPZ6%H|X2=(98tgBA@67xS*VtORI=MMnyOV_U7LwM%
zQBV%HJKzWb5<0vdjv#e~^AZF&Oij1LhgjU<d%_kTlyhJNIJT1Q;j7g2Pmxcf0EfA|
zJ;Z_Dfz;un6X0V?=8kZthy$GRL7{PTw}P`A1UL-w2Ls&T90dUm4LGMB&WXj}z(jmh
zVSej(H0aySA!v*Q_DZCkh>r4X>W)6(1ZO%-;_v`@I)h#P@OO0T1bihBzR<S=onAkI
zpv@5oWt?_)1^ZZ}1<F|-696~Ch0d<1pnPARdi45t7U+bOZElpa8jv1`3E1Zjoyiaa
z?cOBd57js9<)G{fr+xnkrPUTL+Ia~Q)N^e2Qq#i)e;W_ibhv^c-vMLM`?NEEP$DR4
zfIklxa2jamgK^D=`A%*83O>VPALa$`19KEV?K~dv<HTV#{EuX@5-xOxh1d^q|8Rx{
zRT_-Q<NMharj&zP?NMY%PSKEODTo`Y57>+FYdN7aCAR#OcG}tV#niO_EVpAnrJW+V
ze=oapzldLeY78?V4@hqyHUc_p=O#6N6fgC39k8B}<41a-<t>298&w#H_Y}Ag?>Z`P
z562(5GjeWEC-5+Xi(=;#`zJxaj|HCT!-WDAr2u3HP^Du(UZ@hWzbp)kuzw~A5ZTB)
zzzu)`fExi90HSgv2#Df=Apq5WDd%;dc#yh)9tUaoGs>3?AhLIuLcs6oz;BA}QT*P~
zdr&nKR=|aVFwmj&L6;l*k3+ME{js47iPHyNwE%VayEq_9Cn`p?^ib?#`1B|M9ZC;0
z$v8dGMZ@pO!83|Jk=;UF1nEJlfv!9bV88f16~Kw`L=_O(ff^t!UW(2r`%izC1Edwd
zuK|d33~9#xtjwSQM*B^S_Fow75B+UFP)7YC8TEH$v_HgXKj&}zF*4c@W3)fS=s4<c
z_tzNppZweXHAeeaf4g7D=(_lS%a4)K`FlqF!Ws2XWYm9h90~QaNA?2{!E__98*IdM
zBm2QKI{#OL`Hk#<!00*zqkfT$&NDFTFTkkZI-`EvjQUeE>aX{={SW@OUjd_j0F3&%
zF}l7#20A~C_+2yV2f()(@tZNPa4@PZLpIkt;Of2HO}UGn96D82JSl0%`HJaoQL~2_
z_ZMK)kDF2dXGZsHFzTo9xBZ$K^{-=eKMA9L6pZ?rGrI4DQGW|Y{U?K=6Hg+J?ElQD
zzaFFh-i-QXFzS!V==wRM{(pbl&z#ZqBS!rv8TE@~)IX6?KXXR?6B+eKXLQ~EZ?DfV
zx^B<tx+$andW`xNFzN@u=sFXl{;`a%GcoGV%Ba5{qw7qJ`l&Ly&cvucI-~1C|EK%2
z{%!v&M*RgCT_<ML|CCXGOh*0w8TAWd)GyKuCZibH$HJ%|BcuL9jP7G$bUz8Bemso&
z=P>Gb^SAx$+@+8{didQJq>k^dmDtkC@3!Jttfbh6<QqH8+%9H(B%QxxaE@{RI!4!5
z8TGGYbbXak|2jtfUl`qw$mss=zwKYbsQ(|M{^N}L^E2u<$EY73qkeOY?$2Y?Uyo7$
zI!4b^V06C_qvs?r>JP`LpT~d8uZmH>FGl?y7(F-OZ~G}Qx<8&#e+EYP$1}R`ol$=-
zM)$Kb>MzCU{x?Sbmi}9QL5%KCX4JolQU4)E&sQOghEWNON?=q1qY@aEz^DX9B`_+1
zQ3;GnU{nI55*U@h|0NPYKBHUyrT_m{vbpnr`2M4Z)DM(Xb^!eUa}NN`cc11LeF*&P
zQ9ypV$X^%yhY8ZKt`be8_mzjQLn8UW-x%?WrtJ$re)}lEwlK^ae4g>X0F@tj)9njj
zFb?Fyu8w&S2$|r}jr_c6afValoJNfk`FkV(d*>hG{K5Yo$2wBJXy1)S-;JdAy{Gpv
zhcmKqpqHgAN&q!(^o>nAGh;}W$mbdHqv(V3`)8kN<eQCj2WrD-tV;qSJ;HJf_L<g%
z-xQfsbb;PSKHuPzjRW{$<M+YuAD<!24G3FA2yg{}zdH6^N4kS;I^TS_De|Oz6Y%Hs
zfW9$5en8}djeOgY7{FcY+xrxm44)s^B8cBdzUh!R?3<4A13u!TzT6|6T|4T_J^Y^7
zQD5%=*&e-7U+&@0njQ7!9{x<3QD5%i&t4t%<sSa5wlRO%mwOZT<>skMcNpN>(<#Fq
zGxo|+;er(LqwKGkCz#}%8+@-u+J9=)m-|;|RFC>{4}TW!s4w^MXSt60au0uI_^2=U
z@MmC+`f?9{Hu0!0_y1XE6Oa0G4}XUHs4w^M-v$`<<sSa5)KOpV;lI^2>dQU+nX03{
z+{1tKZq%21_%rNAeYuDKhS{hu_y6pS$5CHySa|zCFrf8+>wmfa|I73L(CK{cTV2WK
zR;F;Sp85X^egK=OXXZ6g{Q%H<FFL;rodKr^3&~<^R6hW8G$BoJrf^~++0@y|-qzAv
zLBR>cX729fDzs3Edeon@yVWvyAFZh)J^g1O1?0d(bhcjq(9qBhSW|c3YKzZwLudQJ
z@-*QV9C(KO4bb{}6=4cmJ|?801J59M!UgA@5iH@_4QZ^PPoo=otEr8LxvLe~%GA=_
z-d<_DldaXVA5y7gZ|-1WWo{}iZEi)D6}J$R5SNn>ld-TMOF}Rgvy``xl^2teS+<x)
zX=N@YMHaJ`vk<cum$xvNmaryUn_F8*N=nPii_1z%EF&%WMk^sEYb{|VCLv{QDJ~`{
zFDou1Eh&vISt}V!D=G11B${ksJ^fo?hhO2($3T9~@VSE%2?`vKKsK;859bYz=a8I&
z&-4?}UMmN38_yx}?Oq%tMWOlrOa{Lr{EbEyzw`ZG94)K=L?ey$@gCwl1`F*pebCN7
zTn=(}BfEPbouFrv06&7mfw?8+{7Li-<v}0lEbYnWjzCGTJ2T{<0D)e2VMuozboTWJ
zx|1=twzd$Ll9jfUm$Q%(vw$B~WJ`HjSt|>939_W+cimaYSxH&QTS`dCnahwZEhVkx
z#3aPztSl^~ETqiE#iZzUCnF{&D<xqmX(=yZE-oc0Ct)crBL|9<k+PPTv6PehweFgJ
zr@N^?>F(P-o$kIpqw4P4Jymz#?&);*?b+{jH+vY}T^vStqQB4`A38AbC*AEqy2JJb
z=V{_&OBpYB=CWitX)(|UlqO3#D{-<6*_uoS{aIOw%Sc$#l{+aJSqU+DF<Eg?ueh9r
zjHSGl1l(9yidjimNy_|C?x4iV$%{!?$;go9tmNgPXj*`6$je$-SjbC?ng2$2nZMH=
z`%k+2c2B3fZ_lW@`*u&&-M4!>-F<uZd);{rqq~}6bZ7Gm-91B<=})=~MY_ZB|GDnS
z7Gh)x3vnwbI2Pg(GN2Agd1-T5DYBJ?xs0`#<o9xCB`r?2kd(5Nx0bb%mb9|4l$5uY
zfr?e!LdIN@EcJu#tYxKTq{tRlRu<ycVq|k`IdM623mI!kXo<;kk}{INE_cPh(;co`
z2;b|>Z})V%`}T~gyKnbY-F>^K)7`gczt<h>FuJ=tjPCw{XY_UE38>#m>zN7AB%7L&
zw{A6ew1Q)W1(cNqsO>90suZ5$22N!It(6+Fw5UKZQr&1MMbF39N<~FLKv(sT*r20H
zq5nl`m+R0$oe&)0f}@TIMsS%!-p?~p>vnTgLHv+tC5F=sttIM5kboyGpgsjfKJ2(3
zf!fL%YFkNbuh4nDI7VBmZ|&71I@zx!Fmt#<8tElLlc<7%sj0n$f&wj#Bi1aC9>g!0
zL4G6Ff4~p5oyZPU{)HWk*y1r}2aK@!!48^GrvL)I9dIK%m^iW>j2PK3?0_PlKeK~#
zKiR=T2K6>#p9Aua>_CB0ek1iZfFI2c%>IQPj93FRW(SP0`N0m_*^m|dXa`*&a{>c)
zFk)oCumg&G{>%<;{$vN^8PwZ|trcVy*})73`Hk470zaA^1pFI27-{svpdB#4<_A0I
zK?4E^^!33~kV)Nyk?VtzM_j|V3l#bMnH@C#WCv>*)Z2*TN60&}15*b1jW}`ye#j1X
zP}|)iJSxV1*?7#3#)>N;E@#SknAUuan9T1j-H4>W9n+&Cj@n-|rdNY>(8iE7-}wL-
zS1M5(Wi$q+&r9@FcmM&7iP8K6%F9OJasJ1=j3}b-c^Q$E;k>N>!@RgpgTzAszjvG$
zG^g?cgcCsN57G28Vt4I(UPdHkI4{+Z4w_zQeI-LU^j(QMXTwV!+dl(3q$_iKGM)?j
zSzjtJXM+O0z9f;paNl?gEsrA(sK4iNL{f(Hxa1G@H3=P<|5IN0frs-?c^PTSfi5p2
zkusc@S$~+9XT#)W8`2A9tWML*h+W$6c^Q$E;k;P?VP4WuCGeA8e2`v#%*%+~>F;?N
zk(A-Qc>ZBt?9qfO1YWpM{f3Iq1t??Dls*wnFC%t?zvpE{Qik(#c7!^CzMhtX%|R&8
z=c5STuVcY&IxQa~cH_S1V?<Jh^Ks)3^3gv`K3d@Yo0PuEw|tD$=b_8TNTdwsqu~$o
zQH(ZfL7=aPr=T)Inct!1W5h1z_k4^<%5Xj={$Ux3Lq_#eUIsxH=YP!0h~4k+c^Q$E
z;k@+H>Ew6)nN;d}N&tLs1O@tX5|8pSiQ4x?QzEbp(Zz#I*%RpO?n<|OvY0ZdI^2Q_
ztYuLC`0w6^G%>m^6GfM2+PX|8Y|cY#0H{u&<<*3`kb#;WRJWmSX%f6!@i+47_dm<*
zzsW1gn=4h1%&7AQfj)03khg%ze?gD5l{1oslaoE;dO1d?7nIg5)bYSEYFd%$Aw8fb
zM-|GT&X0ZQ5j*+xi)Fy#xAp=_`PS!Gp)2q7>5`j`xZr)H-_oTAw9!ANYs3!wzfG6!
zFVa;(O_va)4ap0(pb)AcLpp!lPp2tT2ucUz@~ZrW9=D>+wh-v`h|ZFY{;5AY()7{4
zmDl25$csS2$@(E(d_b%7Q@Td#{Qlc?&HP2W4h@qoGLqMi{lpPFvi~++R=-G>7;J<_
zfnJZ>k-UCP*NC0cf156kU!<#;nl5B!$nH`4&VVgC|8ZaR-`RcEFYMk2HjJa74Hqk1
zns8kQ+UP&-TmEOdsLNo$kv@>{T00sC_rRP*0bRP#I2g@ibVH@!;9>7>YvJuq83|L`
zK3bj2i3a%)Xze^2veW~gV}IO_{LeK1%69_Tf2(uf)1{fd&ds8xi{AEFknR20mm0CN
z_it^F`4_gg0#&jQ=+o5$d5HcoT_bkf{%yL@+1<4H4<s)=SYtUh%$%yFlcSrvtB0k#
zDNKyuRWn^xgYWJwDk{3FI_Lp)Ws5dV0yC+b;0z7Qy4Yn{gF>MaF0?LI09QH0e{($U
zJNys@{0X<S)L{v_B_RD%()N8m6ZvN#8~dR@2HyrneNwdiQU?6#rfmosF#q@lp8XKn
z&kI~5PcLCUog?uXanhDjb`+@c(T9&5qJYXdI*(!nTqhw867zq`$JE@_)!h4cZ7Tt<
z1^%a8h#dK#2OWqD&0#ITyeaZS<=X?E*}{cv0bN1Vejhth7z8whjp|4w+Xk@R^Az1t
z6z}G44wb_9Pqiv2Sb3P+Q@`M9WA9{PZV!F>pG<@#3_W-&b4MGptCNSDDLNE{!iSo}
z-{tW~zo~1G9(r4rpvu*Yns)f6BLTVHpxfObR{|yNR%EbjCvQ`0dpAm4@R#Aj5AqZS
zK{#7mVHqhvnYlSknV~WMMTvoufzBwQmJQVDf<S^rZj`=BfJpbw6y4LYqNI^J-H6{o
z<$@Cb_j1wni*kYN|0?jMWB9Z6k35kA@gY8?zvnaZL<aCdHulZ_ac>cSs}r6Q2vB8G
z?4K3eKV6b(*8e-(_>KL8taTtRnC2xcz`TEL|8`XSp9F`mpn#eY)E1+@!coY7``;MT
zS&`k%Ew|$O?pN({4#Y=WOQ0Wz(%Nb?4#oAHDaFr>mhSV^bWer%QMpA+k*SdGV}E13
z24xl4{dPP=pYET>Y0Id#uY(FEgo$ADDE|`x_o6gX^!{zokE#YJOK5(;3elsnEOn@j
zZs`K0UYJeo#~|5|y=>jw;j7g23}}6tOo+>o>`DJ8Y?rk3O<GK0jjCs4m#AB|2j00!
zks*EhQ1Tp|ATlJFk;d96eJH<EfU&)~o4YC5)z!(>)Rhd5h42{Or?g?H(xud%)S3~#
zc}@00YeJMh8J>fnlM5<Sw6sT4)2;~oP+YQbA=$PwkoMo%B1#)-FL-{Dc9aH3YT1!P
z1q}i+MO1c>98(|-I)B3kZQV?_!-u$$K_GemF3q&E^0OV%(pg7MCrTemC(<*Tw;}zF
zbh?tk3)GDaEE!HGeK|++TtzJ}=zByc?1T%oXV48GL_%dLMrqGn$<FrXmSj^)4_8<C
zUOLT#o7xL<bb=q-a2nvX;ldB?9M!g<KTom6$I!;2vO?u%>uBwS%L=WJ*G^3vhz(Lq
zAfQ`hZ)TLT?C$D~TljCqc%(A&I~%8+*=7YFWkx{^E)*v+dGsyo^W&&<QrO=L`DjD5
z@V8&bNx<VDM&hiX#z{hP!G-FfFqF?9;)EKD66J_-qJA1GPc(T`+C_G}qOFNC27v?@
zeOv*<#6_zd|0j7=pqATAYP_hghwKcwwV^y78!ldIt%u?Tvf%=jEy|Y$mA}3?g$&Kh
zA^vDiaToBf`!#=4vX?V>+2iW<w>AuH;P3yl`W2;>c8=a<YFd@3X;lEc1KMf-;T%1>
zv-{}u4y40{Z}OnUA%zkR0rmfoJm$lN&gv8UK^{Mx)rVslN#@9&QN4)N`Kz<~P@Rav
zWVle=sQ&8$P1e!!N7)BL@x6q<jT9$3ldvAY`~6Hp398=FSQrKRxWXa+iXY?pR;N>_
z|KoowKNQbnYCH{)UZk_xgh?Ez?rw*RNb_if-aWP1By_@aBnvS--%22$Y2rh~AHN^3
zJ%$i~`b%p7k$tWOMDOXqRY85v6Mm!jm;hJ6g~AJ%3YP|a3Ahxn1`z%2HJ~<NEg<Um
zzXh}ed=L1IFP=A~><Rd*eDVC+{|3Hzj^gj~MS7w5$x{5Jwt^voi1A!B0O0|V5P-@@
zIiL|>6(CKY6u-(pe~;pa_vi0X{I>q=JrbnZnQA|%%|Q8s?k-;c1|U47=7$8o&;N$5
zl8%nzM?)E#XhK1!=eM0|Uzi`&zJ`mJo*%`}gVLt`HhomP8j;^`=;-rHS^KBV9sZn;
zvvm2OtgR1Ecan~dvUWW@of91$Wo?*&{8H`xclpKki^qhNcz>=}%&GN?86axhEvWSh
zdXKU`NNERue$SEmo)h&wXS(+&Yj4B97fXFFj{4pK>U+o@bg1@)<{p2i=jh+i(d-7L
zpR!IwAPB*4q(Ay{3j-QlpThi7fB^iR-YzNYIFvcipVL9(PeS~u_B&#FsrEJ;-4FbJ
zLr1eqlrPFU0A<YobH1{u`8orL;-lH=R`^Ysr>D%{qxVq%$pkJG;(;Euv4;TB9Oq#`
zwET7ikOX)X5DiC;0iv$vaX>l1bU@Vi$OO~`q}e-4CuNTPyS>xP-vQ`Rd*%p;=1b}A
zpE3tNy!>f$Ai+D7IqBi)XmWK1I?8-5Wu6!18|BjqE)+IG{HXqhx*MNm3vD6Jj~U=f
zcy0lx3up}p7r_S556}*951>6@Dj-bN1)%w3XoGS6uL8d*^Q4sdQxq@i$4J42f)CK4
zzOyeNlCwXc8ejnYTLBmd_^lnm<0#5prw}lqmtzsoAvxXwME&Bs)c24sDD#Q<d|qt-
zC_W|h9Kv;=L+QBzh~!ZSi26T>9}ghnhvY)z7Y)BDbAOO8sL)Y<rogihxKP+dr4Iv?
zfcxEmC_j4v*8@fZS^-7@qB-4tfbb3h_y&OO5n=!{0rvx50gMGK0gMBD4R{c+8}KwB
znu|OKh~%RJ7l}G&CJVoRmUAx9p?qHiL~_0aC=PfT5Ow<?u5WxOb7z!x3)Oc>J~Vyp
zgnA0e$p>&6pf4b*cl`j-+?zijO<$C`EHpp%pZz#E&l~IOFd!TJJ%Re(dH7A4U!u%A
zp?sit(%?ejC8QG`5$XZi0UH2OxoHAK{lyP}C>_m!^8s4{QF;9YxD2oZP#v%f&=wG6
z8Q=x@6%gs62QUG!4-jmFFaTHzI0#q^I0n+$4mcJN&4&@G>DGj2lzAu0JPJxTk~huH
zCL?;dp8|;T%MQp1I2Di^a5^AA;0!<{KRLK4b3w4b8Ga*v;{X@Kg#r)I!6O1MAd<sO
zK%{p*>ic5wn=+3>ncw-j-HHM_q{n@L3jm|3@1b}p^D2~lp!ewG4X3`h8xWO`2tbtX
zJ=FKj;5TKygE9|-(v8ZcK3ph(4sdx>21IgD1w?vV4yXmF0k{!x6`(obYCx!C2x|bn
z0oMT{`5+p~+yy>Q9LopELmMs>?gJf?H|P$Z?fn1{*--`HT);{|RIaN57Xdy2TmtwM
z5b@W6i!x6^8Iz!VFu}7GaG|gq@{9Pd07Usv2SoZ@35e`*72rI;)qqH6XxxJMYQjaC
zivT&Jd*F-s(ClOp(4qUqfQYXMAmS?uh~zB+h{~HJAdMeozF~NNGC+s;$pRvNa)5}R
z0wChI6cF)S28j3}yP?b@P}Y)A`oIJT0&t<Q0O(MCAP6`SP>Ak5%KQMupXcZI=1||`
z2b>P?&7;0&2EQp|b&3qod-V1Kwt?fD4T#bWWgFWI=n(4>(iI>K&ldnn0fJ6(dkoKT
z`vtoFCMU{xoidL9S?-{F9FHg<k`vU86nO(8JxT+j`a}khCMU`moHAbiIlqR~{B8tf
zh4+l8`9<=jjHicxPmlWEdg^=nfL-v8*i6tpH|Usn#^wUAVodpseN#@HFZ9({4*$@-
zqbTFS<lCzcUwv5raUZnRm@XtBg!4sb;C9p5reQm)vpmN>;tq~XPIVtY`_2ikBcTOQ
z<}sb8romyw?8$M59!4f4o)zJA?GxH18}NiPwCTmYO^fZUppC?IZBCNhrB9O1r?U2a
zG;3#??06(wolX7v8}F+b(G9btU7&8obbAJPy~@P$s+Gduec^qZWwo`u&dg1(Es|wh
zx~%aU6)-jlFgy}5;_lN^R|kz1wru=-+}Ty-dESf2G$yb77{iji#~v~lj)T4hrt@{V
z^ndwT@^-2yzfD$~>u=qbwTW43XyY~S%B5Btv0Z(0E-SeAW;dNIl!_$~@_7+m54%~F
z->f5M)@AKly^C3U$3FLew#MRmzYmc=$+EuSHi7UN(@kR5P|n{pFLT!tL)+oclAjMY
zLn4k$H+ts$=$Z42p+o2ll`DxD$ULaba@cIlI+@Cx7iyb=gFZZye=X(NGNB_-C}Bcq
zF^qvQT^-?8W81=5o=<bOs*j#IACUp=I5bKmqF;=Hq)J<?q*2DvhofiChkHWX2OUHb
zF|=&jM`xjftWSG=Vn)xLSB5sB3_2DhqOR|=eA%f_;uA{BTK>N|b3S1+ir1a}{+Ls#
zO<UgkR2{zddiEHmt!i0^oC<aZDY3|y?70Y?@k`LTA`ycM%Df6rPhTdinjtJ_Mw%&k
zD(}4m$tA9&J$6CY&V|t5sKIm|R&8H44>5n5W-7LxvoYaVX?TS9NrJDw$2_(BzFUq#
zey2bOibNEzaT&@;@>u30eOmOyExULNf8G0jTCXba6IgYwp2&v&-!e?+y^ViCKzuaQ
z?vN`y`XYgQ8&#vLI9NH7V{c{L4qvpno<P`!>6-Qk&fu)gEeUw&?6G4=%~*Bk!qDkS
zuAQq7tbV&Y#}qnG$1t6Swx+t;hB{uWD9?A*-JbW;3kd5Acg(ovTFoDFWR;r}f$$vD
zF&88*H2E;}qJ(?&%z0UFXJ{Anp;HZZu;g`8gWXO!rHZWb(KF|rVZe4x2+1XK`!v(8
zF)DYTtYWDgJ#)TwD$Eza;EO~w-Qe8A>@5As<EA&u=$Z5SxiEJHgHaN3vw20H+uHWv
z#bOgQN6(z!qXuh-FhNHmUMh1RzejFQ6bI9V=+QIhljWh`1d|aYVj=g&iUovS^(Xk+
zZ;qZhzXsa#8kj^O5f9}F-|16}ImpM;+Fh8_pqeY&JC3B^k?vS9FuBF0H3jBYVG@T#
zyw;;2U-e8<ZO%|%PhCy`e>%H)v-wx8ex05j)=hgemJ$fcm~O9hlE~2RHTq7=%Bu$B
zENjz(RuA1RzBl{9zP9!yerKU?Uxex6XYnv;$d}4YTb;`^dggpPJIql^A~`FRD2XSJ
zIm4M=xc1}dneztcz?V`A$wevbWmHSe+nF3E@>xdDoZqJp<q{@QNyM#HA(4c$l0u?6
z<nYlm=Y{$S1P@sx7yemEt_4|~YwZ&jJ{Uc7p2?9wcqE79(o)fV*qSM_IZNj8fzdPP
z{nKIXNdd`4!thK)x6($I>uWZ1jh;E50SiTiuwY6eD$nt2`=`ozf0$Nr!swav@AU`-
zZs_Zfh+AR;_}aL#J&wnhZ5Tas9+uWd!>9!Qw@Cn&F$tUg<@x{iPM)?-CSDHiCQcT1
zuua0mR#HyJ#MTLUv;V(v=09!!VdfZ$dcb!C`$|BwM~Hzjht4#-kA$)_6}F$@^M_5b
zdph`<|LRQtANL=Qh4G8^R*HZ6TIxO?E9CG10emj--YoFRAPi1}^>Rvlbejom9k-HQ
zZQbDre`{MffR2&^H`r<RZ7+{Kh1Jjh<Gnm+?@k=-EqMzL5wNw^6;7>(PZz+(9SG=e
z&){$K;cwQquCNL1n~Oi*Z`cKYBY|<*y5p!ZeJeae`JoEJ(#gZo9q~f@E!yF4=!TX=
zcPEGnC!Vrj4ei%f_!bw+4dppHZ@`@r&$k53AP_mSKqe|6r&Qp{!-@3peXk~p2gwxC
zJsJys9Y6=}0R(kAx*FiS4|M2k>jZSH9CdJy_U^(*E$nGoMSBL&h4vC8V%fvK2S_8j
z-$~^a4LlHy232=)sK7yh{Q+2aT2$TL#Pnn6bm!)7W$W~_%COyl8^dq`>kQ>-E9A!+
z;!y?O#dLW>I-$>d1<=_89SP{(Q|XXi2Z8P=C+Lp4MUIwVBnPBJSNI!Mhwk3aWXLb&
z+y{DjA$=lUJGs%`rpSRNFS+Ryoe0jQ$jg>`Pm>pIZwq#Mf!xNzB>`6;TxkD{4nDIV
z&RxfQwCKc!D<#T46XZ8U3y>57^9%G{2o>!2`15xm%D;UBKpyOOJja7?_u?p8$RqtT
zS$u!{8x7@K65sE|LF<%vzCV+}<)RVfA_jkh&6;o;21O=n)cq}sks}lYBe>8{1GvyW
zp7tN|`olgRYHlg{rJ5GJ^+Uk<rS0WGdZpjXgX|?_JorgLgy6$Q_(I7O)+yRo<^j)a
z;iB1kC;Zky7uDWTohJs4XYlWv?-}@$1)%i9^k4u95T>QDFB=FF`>=s<@Lm_>tAy%G
z7*=ARr5^ZAslzCB8{&&}*a{a4u%v-~3L(ybsc;WdvzY&KKv){XzIiZJOMs=p0N{;$
z?E=7$52ZH%mJ|sa08w5H0YUWGr`Q+J8191sO#pWTZUMXqXa-mSXa#s15UQMjJAgKT
z4*;PG33v!-2lxVT8(<9}RFK#Q)*0|C+`9pSKP3U;3;;h!0?0G~{M4{7JF2@q;U3Ag
z0xn8DK&c;4{<+{;5nL$v039<Rq&YwU&>wIqAf!ED9pElN3&1cyNHg~7g*0K`-9W(o
z@H`3dAYdWj5x{$ZDS#;M<AARL(*WB6PXG=8W&nbJDE1wn0+<c=;4eqW0bB@}2MB(D
z*k>2~4Y98-s@JZ<bCj<DxG3e7QjSr+Cc`tN0~Fq%_W|Dmf{qFA0963r1Fi&Y1Vm+_
z2@rHgXaNLW5!wLF0Y3qPZqUB10FX7|GoT;f7r;P3&;d?|8T_V{B}y4X>0p6p`f#Bz
z2z1D9hXCgSjsf2`@Vmplv|@nc;C?yactBmi34rSXnE_GySOB{K&1Mk@&m_@UCYYPa
z+Oscp`}??$w-Zhk&M7!@moK$?Ti%|UvMRII51@E9DMS}1!Wz)x%kB6<y1!|H_Jaq_
z3R)MAlo7l2m@nP-6N>jH5aco4Y&Y#$3+6ZSr0MT)TxYc-JThR-;=%4Vh0tPg9<^DC
z9UxOo*Te6=Aa#6qt;CjAezz6JVkN~kB;VL!=5{gTBkBC5(Ye3qkQNS7=LWNMk9!Ba
z<Hh*ajqxwij{a}X{rU4EJCGf3zQFq8$-+2QUH_+B()?|ElewC=awUp8@Cod7wOtMV
z@iK^xXs~05_+-xM{IufqvjQhSnQPDObqrl)qp+)bxr0J56i5#~MCW3~b@0U%c4eDf
z-%7#fM_$RwOfk3kXRqbM*sx_+Py0h<@ecD_`8i&AD#yF@EQ#!WXL*CxoDZw<y<<_S
z_o3|ck%j(ep<vCBMf}nyvvoiG;9$8*wJjmuJ(1Ie+(Wjn{kXYX@s@VPOSFSm6VvVQ
z;2sFDdO2jgs$hz`)7`!Ct~V^>b(aNM8r`fum_9m}=w=)Cd2dpS&h~oVc5X{%wG_eY
z1u^5$T%st{9VFu5D^1p-g_)bKO<ibFxUuw3P6yZRn<W;JIkDO&_APl+$oQON80N>8
zB2D^8^1AeL>Bp?HaN&kokGWn}p9`KDwf&#^vg5^2xiw=t=EjT`)=7Q^PwW3lP9T3-
z(48?qFI-2s(5u8oa=FmuLr}-Tx*v&{c)c`gLW7;R@ZD^Ean)B1W>@aa+ajPn>F&gm
z>MX)bOX!cxMsy9wA|Bn_((Cm2pZ+0970seD^C^d?$QN#5x~b5y#>^!i{M0c&=2t_Z
ztpOd2rf-$KR=)0FT)^P5cf!msUi%c<m6tN_uOtw>Fx_3YX@34ap+R4l=nT3?uQPPh
z5#dkvnzuGn;o5@mFHL8m&BAno(QBhw<lGadrd2koo_lP?6JeOTQlRivwSBc1zd-E*
z*iVb;hK{sF)n7Ul*!(qN_Gz}*0<rC5ntT-lGL!`ltxY_@2aU^g=%A2@2SiF|hkp@V
zv#$BnHBEUAhsk~sF6*^*eUqY|3u}xUo$J&#XIGNA<E(#aYED*0Oq;Mp(-u`z`9GQK
ze7hOj)os&IKc+~d^6hI4D|!NtzvCJwGO6{<5;-za?11kp=uG_W?{G5eJESLs(x*Ak
zqK0`a(WPzDoMc<MWBskJH}!;8UXY!j)_i5aY0w$ke(clCNxmSrmtSv{XChC{Q<k<N
z4%^r&Uc%M}c_EI#S2-EbdC-K84vDDFbVKXdIN3>cTsCFN)%~I6??k;Hgh!vZe|$P}
z{FN2Z*-OLqc<jaJF9b6t97_G<R$ZN173y+vh2NyYw3qyfFGMHzIzgKsjQO=^>SbNm
zXWx{XFmoGA@K~Rs*5U)53fyxKn5zu5?M?%_^$StFuX20Rax*SWUe{qHuiCxe+suA@
z-t&zu+G4HuYL3lHhJMj$%&+mEF0RiNwY3Affr<}|1zPK0hAveJe^WYxFUNmz5oZL9
z$1uN4CDG)mjVD=8J}<JWC-m){B+HZkC2tB#m`u3q%&X;4-WoAKi-7gIT6bsKZOHCm
zxh^wD;E`0uiL%1ovpFh+w=E6$Z_WXq!TBiVjUXRaJs2$}@bL0^agmQ-u1m9<um{TZ
ze{puzlwR2lV+HIxG@<mgg3h!F1JAka2${=_uPjM>x=U%m+S0&XTJYiFk9R?SOOc%W
zynL%2zRuUxxj0VN+AG{&^-jghGwl8Inbeo<Y*u3lfPMd%&L>bVciGr5fw}=s#kYwn
zuZ=h89Ixwf+h8s1`SJ|6%~Ys&mmz+uCo2}pHJ^^W|4QXXHcR(lT4`0ux&2QRw7*P@
zs_A2cx~dxIWA@3^cfwAcht7D9GoN&iU8v+_wyS)CVdBY&Qzy^lMLtlMaXwO5Z)n(D
zIQ2qq;<kX=Q03%;8l}52C5CcG6m5(;c<QIam>biba^xjVzg48%?lAOX-?Zc7)0yM;
z-Ot(|cy<1^`GE_UC&M=kF<r(Rg2i%DX5Cb|=sScxrTl?~f=U_X#@SWzy<r2_y^oFV
z5h-lk*Le6^Kd~`~RJyw<e5X$eTSwYB7-R7u{kAJ9W{KMxbFRN5!2E&lQ;S|+=%WYY
z#^w$6sg@@lTm*yL7nm;U?AL2Nq1_=(V)~X^%cc4aPCa%wRDaY>Lr|$TtA}?J?2W?x
zNejNQdYPHxfztbnPHy2=ShAyjOJBjxh-bUb`G&jnuhD@qGp3s}TkheG(`{<kI*HfY
zSQB5%^Die@tthDaxN?Jow7wb)%y&cFB%+>*r)9?1^-pGyNy=Y69`YoM=wx4=y`r~V
zTS0c)3%`q_dqfgazFb;y=27qi>yH9nV?QWv&bQl93+1hX56Lg@>{KhmTFoKJz1zdg
zJ0u!id!!FG@{BqENZ9@g=Me*#u;|Bh&Sy9l5ES*@l`dB%i8Vy#)%35fy)lo-DJ_$2
z-EehIEX-Zt{u<{aa^{z@o$}iH249BXBk~?5V@SmP*L3&SNblwIsYoJf%9|Hyid`Rw
zKXucu@PzlX)V`DHP#<7^4^_$iH<w2mEU^~}9(VL2D{nwoso&0G=a&%+Kg745gn@Sm
zZU;B+k_x+-!BH~t^VElZ?}zT5IAJqkp2?MzEwRs^9PC8Cr#iU*r}(*4KY01dhyuk%
z!Oe9|+Ierx)zicb;*>UuzrAqEZWn<Ngz40o((8)4X7OZBp1wR-nKvm~aOdsqD`pCM
zg<Kn__;xj<uL#p!vB}!8Dp=RX`0kvPUB*07*A)z{q!-JRJr9?)>37Wd0AutyD8Kx9
z6V9ixSR4>sRMOBdt+Z}>@}%1PtfssPE{jBmbS^5x{z6Q*WQm}z@t}r)bT>bVzy4fJ
zNct2O<*+kveJ`IYX(o;CIpNy&B;O`Z`#`T>l+6jQcSoQ1d6f-FzlX`28WNK8+^MrJ
z-Itrty|Y@4jc_7X$Wm01Z9v*#AFHsSK<LZSJtw?hLNblS=cjA3*(->(^(BjFu`J}s
z{%`I%aS}&*`#Rxb?XJp#&c%a~yK21m%r|*cAjtE$%5<OB^aD(r7Ttn<=lqE7OU3?>
zfFS-P8&aRfMuh{$Mtj`5_*bn<liV=i9=hQ1BG|h<57DhCn0b-AQS2&foqE@*mD0P8
zGJk!%>axkgAZJhJsr^IH&pCqQ?R82~?%$q~nd@LMmw0C4Wwmo3tBFf5A97pPxj9a(
z2j&h;F~7&IG1Cnithk!p^O&AzZ2Q!plI*uFtmBr?gBFb(twc^ZZvfNXv%8#b$t$t!
ze0EaX>KB!FzHZJ|66s3dkMXn~d}jRL+`}@uHzoA~cdoPG`MHL<``OjRJ{8aHOI3vP
zieM~2A`*(-uLPzDEP3B@Yqs47JKLwHoUKKICVlEV{jfRo2oWZJbuk@xiQc#whB3kU
zGKmwT42(Emns|6J8OIuNDc{XkH!?7TId4pN?VMJbaj=45sLtBLSLOj@Q{P^FQ|$eT
z_myr?k@(SUf7lCw>5}uGv_)E%e+uyGn2}eM;;}vbRt7O`=a;7B@iy_B{ug`S0T)HG
z{6B~pMes15VMSC>RB{p(M9cv*3c4(?1SPpFih0f1GoBH{odMGsP|uvs95E+U&YVTh
zc!2)D)jhMUi0R(F|9kg-(;vq#)7#TsU0offr>aXg4tvZj-ShM*BPuj_SGVktyT%J&
z1|PfA@yM_{6P#RTt&KS_WbQ)j9aOGC^;mDRr)qEWBI8Ws22I-*EsQlEHQ<u#ymEaf
z->iC(+olX>>Fhe1rgUG?@8FW7vkFYNyWY%n)W+t&&dS%+dSdcVy7E^s_pW2<x~E^B
zd_)&$v$?uU>Ym~?2b(1gIkl{M*P%x@tv26$;y!45$kMHCpa0d+))fZ~TxPSOqW9F)
zTYW8`1@B&W#`5j-T|fG*q5T&&PtOb5es=VTr}s}hOzooH*U9?YPv^?FPP`hoI`x;^
zLjF>R|8q7XUu%Ogn!Q)pG@0UGvVX#w(Wgx#vON#o%Pbl1n|^<J->J!}YWuf#z<6bi
zu}ER8K9(B!&dIslvPT7H9b3~a)_BabHDyg^%pKNya;;gOYiHxz4@<XWNug71>v-j>
z@6>9G&(TZco=4wXJfvO;<*LZmifX;fKf^Z`mhK1bjgDi3rvE&qO=Lp0RZ4TWChfe`
zF9uZ)yWZjW1K-ULux@AROq#4wPk4}i?A)sklfqV&8d7^_h<l;LqtlnKD(kL}kZmh&
zzsXFvbESOuhMD~rxVQ1U?$|DUSnC$DZAE0rZ`;<anDMsW@PU>U8oA!NIXk(B@Ibb$
z@cg~S+N6Y}fVOLlU!U)p7*zYGRa2eT%eEDkj~pkLR-O8#Ooy(kw;3%cK2*6S-<?-w
zFken|pz$x$<CmunExQXRiuU}yOun?=_FPl{S=8*viVcpvW}aF70`HC6Svt4(<G1V_
z_-9f-mF@bbS?^s3K3H6*OIYg20lI|b3JJ5)@XeH^`|V}>jOTrX)w9c=-JFtSnSWD2
zi>!>2&iOMMB$jHD@t?G<5ab|pK<0qV0ht3b2V@S&9FRHimpFh=PtbQXGN*?_JpyCn
zNtZt`(anYQ`J*FadZ{%r>Zm~YUWyM)!2f~qnvg(MTpaxw9SjFZ@Qw132|#pk2q^~t
zH`@S|6s*j-ODU-qbk44oc^4e^9@{q_`ma{zO`xD2s?tWrLNBKv?!6l||7@D_I6qzs
zK90dR9AhD@L%(>fI=Tb*$zsYhWQof>6ck#S4}~K4X;ClS&6vmc1vulv77jbq)Xzrr
zMM2)L;?)t#@C2166bk(zs;DT>KCzLZ@Pd`&^3GFoR2=La7VPY9@9yMo=i(gV7zU@x
z?!l^12UmBsTZp@(djnf3rAvstoyyT&<!0|5?B?PWqIR=Wg@ib`1UuS0g@%MWHc(X8
zr&T+<xVpI7sod2nwUfJ>oolG0i*uNx+C9YH-qqFKp@9OQshN&CSfCG33lk<Y-Rqz{
zb+1!c9R;gaZMYuwdi}jUG?Ta<bxxcM)4g7yPvgq;wR7(6vD3_-$%%7jy4Pewun^zF
zBwt_T*99sT!XMDpgzKCHsBf@z#efG9rwZY1PwA)*HxL&BZ!9rLN&3)Bp%b2-hySjI
zR-#%uSy?Dy^}!m;tMgZL+zX+rw|^HW!+av)KF`Xko%c6ogD=5!CNlRG=2d|1___1g
zMr3;CX{giMs-lcBUHT7**2~kErKACCcLfz71{zy9e{%ebkzGY;#7n#{Qw=r<#3q=<
zP#p1omjUnFz+c#7+#7O2;;084I7d0;c&YxPbRuuc@7-7C_r*Sh{74R_iu(Ie1rdSZ
zgNx(}pBaU7D9a9qK^qCMRbYMiD}3E0#KcF2$EZUUArUGK^K)ll;1H&XjplyLJU>hq
zVBbB!!P%udbwSn^M8n4+$M+rmz7X_D{ef%*i2r90hjC9Oc}pXk5VErw41EyMpOoIm
z9@!5xhFnFU?&w;A534KnKkk<%0dbMIB>Mr0SF;Ks5}`3JqQeW<C6ufC|H&)Yf1Ots
zzL8gP;L~)}9qJUqv@h_gzu0fbhz(g4&lJIh&jrGM;uY_=Up=hk^pr35W+p$>e?JZi
zHilDQCHs(_phJ=$sZV!7<vihGh6J&?C{w>7ou}kk>O)7cOkPPor22NGN+Qr4LVwbD
z@fy!(aM_UR`^D~=Q{OKp{p$KYH>j^<Q$q(Rdy0b?RmQL`ilT@>Fs#cR<YC9>b*V02
z9J+Gq^2MZIU6<d#vM!R3-pyiNuAx3AxGv+`fjkykvhhu-%NK>qaKVBs7`^zUn@9Li
z*0vkaOFWk7@*`pppnA#Vr3~;H(x!g1yyPsTD8EnJXnsgn#wX~ymj_+xNNe`ZZU5Kk
zx}J+J$=BL;8srh?;-V>wFcoPPR;(R;{Is#HVzItdw^2o_@!O~QAh5B(6zg6j6O!5U
zH1_lR>H7Nu=7ag)SmSZqxmf)@U(YG^_s(p6*H(Y;#OyC=2&A=jNNlJ&P8CjMv3@pK
zoO`v<NufaNG#WFgitA7(zjFWb-21oqm^GYdNp>awxOS!>6v2>gW2}jGe=FVM%ghHZ
zw!h#a_tWi~vqqpX{;5^Y7*DiIzGpK;+J6Q8)IKS=#-byqS7bbg-7|j$^6}#`glzH(
zOopVfG<O?QJkd}L42r`TE7>1Yd>Y~{vDzo6g35$AELq4F)!n>QB`P21wxRv$zP`ad
z(cedunOh||IZ!)c;~Bj;7=ib?zm4}f%Qh;B_$^N5bZZcD_)Y69Lw-wqA^+**KM_7F
z6G-@J-Sq<ePe&c9<9<A&IcMFK5A`5#cT``x>WFKJKoT?r8oR0QpT~6)d|JqOWQ5nC
z4vl;|e7Vm{bG;e0ixw~ZkvU~k8{(FgE6GYC8zB&n_gpL^g#aLxyPNfMUT&wjR<ZQ{
zOMFs@>qFcchN1W@g?DfdCKIJmLSA$*naO_t{zvc(2C|*iA=+3Co};wsV6Y-TXb$#M
zMIw^o?jdeAXbFjH&aB(n^AI|EJ|Ry3IAqDh{1(!(HEl=)8<(<REKTX+gLBeRo>@qD
z3VBMUlN|oR$24I+;;Bt~;QdkPSeRs0sZ>XBlWL7sLo@;yO1Ab|?7pa?=w+~3Gi94k
zdrtpwL4~(R_TDFr_fg+*7MkW0*gE?q3fux3CM#G!&0QShzdzDSflU{TPBUE!B8mU=
zz+YOISqkRt9hz*tEnwB$I{{v?X?wz8oUV>Eln2=!TaZ<G7`)ZeyO6$n@J*JINJrvH
zzAP;uRiXHsp2cIrM$l^^<h_8z&!E}doP1Xk9i{1Qo^g;If+xh&@1^lO*{-+1+O)I~
z9jv4m9Pv5Y7Z9IgTQ-Kox4`@2F_bOkD7A@4u6NHbE_zTFwYhYL!z!v20&Gb!o-&(N
z;a8NStIXPjk7kk!)(@LkFBkMY^_ARvE!Lu)`+EFtXy;CL?cG?L(_V|c6FpCHU321S
zD9jy4<gvK6Iq5*@M{#a>#L<w-`VEbHl8;hL^be8;YST}(DD@#~7sK&|_$T?N_M<@r
z0b6Knz9)9BM1FSPI(C2f4oyDgr6HE_7DGiIA!od%xhePDF8Kw1lLw8N7%PIlmBvrb
z?VQxVI*&`|4x~{>Mp%T4+9?Saov{#9hRNc`XDsODk;`A+a~fY8(w?Xt@|yr5H5T+8
zUQK<Q=CCaA=pxD=f&0F!Jc{T04WhhAu4!5Nfk=B6S0kifFQ)(0UIXuM+!t<889abc
z2N%tIP%9HILtf0v8rCsBA~qo^R2kndCPdjcQj6WzsMuf}_<;ommcw}Dvob*)g=jI9
zb)un#xZX$=X`oI)Y1keBXi$8>=g)QhFY}wqll&XoQs+SU4p#wOGzCvZc|lU0<CIDa
zlkhGbt%}2MBu9X}0$Za|-jXlY5ueE0>%+X+`5<4DZyk|Gg<;=9Aqp4qC<2!&2;VK{
zi$x`k>>rJLNG1jSdXoBPUh760S8}f#scsStT9F1C42cG?jIC>RA`RkPz-XY~^9Xtx
z=y#f14Ch0`Hd<SrKb;Q)4YkuBSQpJefvMscA<aADkv*(TTZ01em=uPR{28u|q_v|K
z@rLEo*h=HC;n>R7LEwwwI*4TXBI5XZCyvQBorA;fHQ|^O_!^wnQ=0HNtp<6rHIkGj
zgw{yL=853v1k|%3=DLUq)Zb|CFfl)ibo6XgFn^Z#LhGb8-}5wczz4eTCO#vro20dD
zVR7OsiVTU*IFCWdhgr?6H0#sR>gbTTe#&^pGf`ZT$}sTvc-r5j=jnVOWn-*gB4fm_
zKGY{TujmEM@V5?;{n>ax^`K5uhkox6o1h6%v+;}OBlZlBW66mZ8^DKo*r@Qt&(#>6
ze7uv+KT`T8#%XAkkKc(O(le=e#vO4Z4W6O(47Kg2p2-jX)Wh#P4W6MjQeMySvWl6X
z2haT=gYbWhen#Cl9%nZdGe3=Zf3y{k=R-z3@}}R6!E=8MFyu2?6V4tAi&BMSZCK2_
zFn$Zl`3<W=CB4354a3ioBA?4ekY*klFCUdDd5Dj}-UAAFjxzk{;@^Adtdzgacd{Mw
z;@>{L%@=PoJjeI+`CdP^nb1<aO##AMEaOO?Qh?t9Hvpj~%+5)v5BwGP^le}>km^VI
z@qKT;AO0=*(S9T4=LMAVQ{ZpDH=MU`-*Y&pgvzCKd{33{Pv-WaYUsn0?^ouXPV(XD
zkNo&vAoE-OvClh{OIu<`fQ^AifjZ!E;9_7Za0~DZ@Hp@+@G{VlUcRT7w=Ypcdifq(
z-sueK<$GRy4~%@IQM<LmMIm24ejbc5urBTk0IA&y0owwL0DAyUfH6S4U+Ln2C4j_V
zk}tmh#D)Ta+7(?(u);-QADW5ws`dkEJU#%Fp5yyJ-}c-><iYn|m`pJK)0{sY7loRj
zi|SVkNLwGaKnyEFZD2K^J&@$o5$Ftb0=5J?16u=KfE|Et!0teIAiAjF0i-#h9&iA#
zK5!(k0q`fFHxPY6XauDCdEw%FEbQzj#uu<g@56H$ekM6d2G#(s022RK0%`5E3P}0r
zaPfT$zMnzuR~&I#TomYh9_p8vAJ}<5CO}$qnF48UHwStHzXP@bl8?(UAo;kY`jiDu
z29hsJl27tsxeG`>EYAZg0$F=u-r@Tge1C)JsEXgM5Ko~q>Rk#L1f=pJfDyn*;2>ZW
za3U}oxEmM?d<TpJvU8(=@QWz)18RVSfposz2;c?aDBuI&SYW|?@OcTe1daz<0Ve=m
zfj<B{04D=chA;)#8#oO(6gVA-yo4D*JS)rrZUW8&9s(`^-U2QJW&sxg-vNIDnnAFa
z0BwOwfsKL7fK7nQft`UXfVA(k3P^m*z{U3<Sl?mtO7eIM7lj|dUoYTfpdWAwPzfZT
z)X~5nfz;M>fIkA~0+#@jfZKsT1MdJA1784fP9yV4yBt^&{8|Y_8w%j1&I!04=n32a
zq_gvW1$GB+1;UTEuoDQsvcfJPXcG1UQHHP&xCwX&cnXL%(Om-K(%k~40cp?WDv;{E
z78ifd=kNa{FEme(j8Sk#ItL*6#-ur)d}4M5dH_R!^?*Hr^?}s?$Tud*kuPvIuq6<E
zNN5k-1|(mNdw`vQCxPVik;c_-z%(H0sJjge0zL!=1F3D)z(0UtKqlw-o4;T4_wL-|
z8DyA^XOn;yNc#g&dXB&Ie%o`2$b-Lw@^@3>6OEHmxF`%Z=HuBoU>V#`1Xc%52D$;K
z09yd31KR^<0Eurifm4C-9jluToCBN-OadkW=L03W`THS%Z>0GV;wxC;qTo}Ak1zhf
znz-)@l%C`7bnNUqCfA0~MS`EGiqI2C<54dI{_=M-E)P^+!{?rWpEOQB1=6^VHqw{J
z-@EdD?!Nfk1MxYuF?){s6o0ScJf-qz+qE$+3Sr;_(HRab0mQkIY`(xAF7p}N6W9vz
zQNSQzG*GHPe^=t;d+vIyLI0<G*8&}Z>%{TE4`T^`@4?)gpZlI|ir*U}p27yCqkggt
zXbId2v<B`5Isx|p>jC!zsSXE$t$_!CU4Tb`)c(hTBY`J?Q-G&{tAS^MyMgC{hk@sS
z;I(iGXoLQH8Q21N1=tpt2J8sD2BdK!9T*P$9XJGd12_|iF;lk=cpI1kya&V>BHRZa
z06qjB1wIAd2R;Wr1HJ;j1HJ(k1`pl>O973*XUy4xF_6af{6NgbLSdi}&;%F&EDpq6
zBbWkv0x?GG`T)NJ4gy*LhXG3iX92$lrT{AfcK|B^cL5bZ8vm;R!4ts>cpX>+SO5ZQ
z1FQzD39JvS1#Aec1MCL01I7XEff}F_5Peo~1)^^X(0$YW2*f$8x`jYItJ@6p2JQzo
z0v-fnPSKqKVouRr0Ja3C16u<h0owpGfbD_w9^C;*@<`(de<x&X0l~WHhvNwPAd|;B
zKvSf(1JZmA*<|PZLAKbq>jI>80mc^HFF=gVI`l1eE+vhZSc~iOqrI?3)M4!*cmZD^
zp5EPL-?;zGb5H7fll+hFzj%IS%b~5$g|tcRZr9%I%)wPfOKR_Rvc2_c^z!oij>_kr
z{I{KZ^0nug$mf*EzH#MqO8)!KDS2s0<L=*g{>cBzxgx(~!%1OWu7JwwyEoI^CVap1
zQPb;#H=50MYb_KGEE+n@c=4*U<ab9te?&fiMD~sQ>GR2C-?(|73;DI@vV85ikn;I0
zgH{EVi9B_0P=#qJ?Vd$9Z1<>C<UPF8+R`|lzku_)IYHIiDDTXyJaC=oE~}koRz6uV
z?s%13ZMzS8HxYASJWIFyWZ|773N8B4%-ibR>Kk^G6m6QGsaETF&C|t8RB;_qKUffc
zVd?I-_dXIHJo4S%Q!9JFd9Z8xn(N0B#<xAY-}+i)z%c)=o1m|SmtBQ%Vs=39#S4$k
zt6<)v*YjbUJSwFuY35pXQPbIbqdnHteO?^jKv=rw>#S#OsCBY~e11!TioyFPViT!y
zUE<&D?4fU)c>BHl^!Y7cd;YrYLsvfMW#0)w2y!5~y7VwLB*UuyDfyh2Qsv8TSQ;w(
z(O5bCnfYeN?j}EFTQ*s;dZouo+w@Mxm$0|!O!D&ObASi1bc*@?vbUua>8&;Gy8d$Q
zs8KftnkJ>zdNOZ&mH5~lR@GNy{$S~Pn%&Rv3m6;i96c*Kyu!4(L)Hc<O5O^wZ~J;z
zYT25jDq|0vr8|^1$7<&GUyA<s`O)}V{}_L_-wTIE)E;wYENgVZeR`PrD<cQDqDS7`
z{$t?&24x+)Z&{bv{J3vIitHbw=+^HlS4%MK|LC#p)f**OZF%!{$rASg__mBqb)1iE
zxxUqo<VK4=?H{8D<Fi|P?a2+(YaH0quF?Lf&5atmXC{T8$q4bh&_&f{^u9+we7%2+
z`7FOnEz(2lUA0$~ubW-QX=v$2GvD`mQgKqHdpia>H44oiaT2;7*zErrzZbGUi#~x*
zJboW^vqi1ShfmGy8eir4sayDnw+ed_3S;+4FW%JXU+IeftqMJcIo?aVtM#?qI%!tY
z<Tlf0m#@~UH@=OrbeaohtwxM!l0Uw~UG)<0-*vTo%?>VWKJxCRnRfYK1l3)Iyzrq<
zVO*+D_6F1S)vmvE8hfSgxjNnlw^=>AQ{~q3K-(cLG^MA{!?z)p?taBVPg+|Z88OM;
zZ1H}j!|zij9#S`*<}<eEqdA*8JZWbJ9SN51S*z%IWA13P{&jyAf485Cuk{!4wSFMJ
z*1yAlyWfWYl%EBB){}$G0ht3b2V@S&9FRF6b3o>R%z=L#2cTvNo7%s2{-0zE{n7b<
z@i?{$HsE?|Pi9TUPXqK2Jk5=QNYC^;*bd!_E3C)Xks+Gc_}DP5!n(bUqHUZuGCHz9
zP8U@8#74)#-@67jV{~R;pAe-=i*pBq6SOc8Dvh`ZbyS>MV;D>JI9BE=Z4}Co&iNx-
zaJ4d86$A65Xf=7Br!?@g4x71u?c6`<EI-MfmUJ~KY{13zT!F=)M3~CYeG%<x)rsm5
zR3V2;YE3-1!NlumUV-U^lf4<`SseL=MQY+v4Q5MMOpJ?Cu_$JTNA{0Jk&e!RAUnG6
zYjV3f@;OZReZ>0`xF`FsCZY}IMUnm><Vj@(;v)Jdv-FbBb%}mMf8<mHUI(HlkMK=(
zAltWMpk*JfCdh2DL_c_7SU1UT@J6osknU$HU83#S2K=o+g-BO?A1(^e_hh=CC4j_t
zTuhhzJ77iJTLA5VrGcbVj%S(A@^V05+zTZ#n2ikGcfxIXAn6)^59|u81XKaBb*fVX
zt$?JDY7HC*v;j^4)&edBQhrOtdu(&inQBbev<`4B?(z9auhYug1K$o1PxT_6N8zG?
zZCX|@(pjZ?xdKra0oyA~=iC#B--P-=su$_3wgOW5?Ztb4pcmr10UH5H4t#(wfQ3;(
zS*P`%snfb0LaH!+V-|FJaK*VnVaGC>zqK`aoA1()i>-rqW(_p9ObWTZ<2TqMvvkD@
zH)*)NTh-)Ib-F~(uWNVJ;&}ZHi;EcF%3AJTv&;0_P=u}qSx^{%Ib9M<H{NyXq2N-l
zU3}h|w@yAgWYMXFM;A^vu2V^<HGbNN3+@oaV=Ud5eT5dRK;@oHz8M_7)jVSM%!^s)
z1G;Cv*#2~4deVhk_lEXKYIaKf6J(pE3pr3VxyG}6yV@Dax~j5Iy&jomoNTUc{&{%4
z^lcN$CHGJ1G;EoDgQ4rDrNSOkL2{L;?Kindg$XfjE^auv!Sqy{)n^i#mU1cNJ3r~#
z>k6Td-@}fIrF(L2OMK=!?~GGv4YxnPe<J$O>%rE?N>`b8smPnH{#h%}<J$&H=RdV;
z@tw<~C(AzdGJD(}77e}ntSZFkHn&QzKi$Un<o+{(w^N!qZffb2J;!~<z_1IQio80r
z`K<<aCYF@$!QK1jH@fC~BI~ODQ+(i6QBu1tICY@V)5|ZWKC9-_FJsxV-^c5sQfzN(
z$0v=NkUwo$DfA6lS5?+km338RT~*1)`q%m}mvvQTUxTu)YCq=<_UlwlvP#sqIa}}4
z)Mqwbzg1UN)<KnZP-Pv|*H11CQu?=TaHquc6aL%FyS9##bx_|v`r+Ee!m<u(%9{Xe
zt`5Y8slqrp{gqH5v8BhQcN<!%F7@)?A0M_aez<M&`Ul<9{rhf+!?~s`opGoB?~Tt_
zUb%hop(VdqEq|(NRpo8W$QI!qqt5t5dko(s2!FQ@YBOx|DvYN-E1Rtgz4AVw#f}ob
zu?Hs1)a(kG*{;E`kgmJW{J6wA3uhX$be0v9G&@#Vw27Kyb3EDPhxJQdpWnS_+|Fm+
zrgcA9#irOJoZrLJopZ^o-*wNEDpQJC6xtoIu)`|PJI;5<O}^n-<Xm6>mzmfvNn`0U
zO^&xZutsqrt$td*9ak^h54_gnT3}#{r^^&^HESkx>W{s3Y&0v3tDTy+VD{80&Uc@s
zOz2x?)|D4VzYG@qCNA*k;&geY^HT7|m!<pi{$xB$mo<F(psS0P-yGimU)3!=%kq1e
z`f_$yp@|PxxtyEvq{RfggJIk1R2lR8hM$91#ik8DCdj&=-OD^Kkv+b-Z^ec+_GD{^
zWZz6*mRxE$J`8wJ`yOaB@oj8@A=kF&*Y1#YL9JT}f~*VrzHq-n!_Q`2Idrb>-ECUc
zu|Hkr-~gVE`1qtSelb1l=duZBTEqnA`@`ts_x%%}2X1Nl$N4)Cde=<pyuo&oAPi&a
z+9#dpz3;~h1I${E937>;c>Yes{*P<VZyCDB$YM%%=U9B?l665bIDKQF@BhJn@%w*t
zWPHd+-~J<GaCm8CC{Fp*-~>+`VE@1S-M<dbE~Qh{C*%7PoqfvOr+rj^rFgDC=^JpL
zfAhuf?9#bb_!cY_z(r@5IU_$mJ9d68KlM8dAM}->YC6AH85he`E|}Xtg*ARhd{j*v
z>%QbCOsQ3b#Ky#H6*X<Ybgw`29NF0#-q_#>BmVuKFpr>Hk4Wi^YctS_<qp#wkm^*{
zm_LQ@)T~Z0BV~2ceN-oP%zt~GERFct;b*CnAo$`cg3Ak+6Y4G))+x7oiHApM0!|L+
z(fk<ke`mXSc<8ll)Jg*vapWN~M^xY<?r)YBI@=qn2l^ng3iml@<kRov!7s^A7@bRv
z<+R{{xV-$#)kb_?e&#Abwo*}mEuOVtyyvn=x*!RNi^N5`Aan(beQXtVEQH3maC{$Y
zyN%VLGf~%|kA<j0BA~AXj}yv>*m$jn2X5h#kdA?m(8R{zsAuUQc;1}w5vor7oSsWg
z-HEmpC@-h(#^x7Mhh)%Y1$z20Iw&uG=6yK~0;I#ERBJTwlA%%K0B|JJ*Xw{(uYwfI
z^i`Nl5<lyJZyAR5`j5-xr(Gv~t<M5OxuJILA&s4MP$5DoT+}D&JVa{Oj5?odSDYTN
zlsry|681rh@-{{D<PkpIrbJhJk*?G{=sF9!%naM*BY7jbG^)N#0%Ky;iKMah*J+V>
z6d`s@k~89w0vFL@_gPxB8l0JKAo-+Pr;X64RiQaPQ%ais6&|e@c@#>-Adr3){aFT=
z6=XNnkgor@?0(6&hQQ`R(#NAdZYZbH{CEkBCoeW6A5z`@aP}aDvbd=37PzXT?rZ;1
zb^ow07}lNY+CXgQTQuMzbT#7r6z9?krBK(&wqhS;3nqBhh{8A*7pu{Rso=hh%RSDF
z%p(*Y>VQ~79|tsUl9-c^g-~^HLU=gDH6k{)7jxo6`gnY<(SXrPbz+DbdZn>3{6~5g
zj|sVcqqFOo9wYgwxroN4y!)!+u?iFOkE3CkG)Q^=cJPI?9RrY0EF3l^YTIM6rU}Jw
zlz%FoUyR>;rK0`#8jcDe+S2ell`k$5X~1VZpx@H*+pmVtiaC?+=H%MML+IgQ0Hpi*
z;{80Nr~8%S{cPMDj!$D~qClvEi>46jgXFC*gQb^rI}O$npIOg-dJLC*zvTE;;H$k*
zWlTa;6pCbPNL25=xfAB?xCln0q<{KCq!G(%wuXcnnot($%tX1N(eg87f$v}TV<L^$
z198>~1q_RfAH)|bE6AWMar9$OU_Mvym-s>B0@YdagGBA(A@-FBD56rJ1vtqwwo-(1
zASOf9x&5fV_?^nL2Idi%o~`8nqXFbs4Yv~N_;}{aT<Q}PAC?fqyj&~E-vTnCXQ)rG
z-=KAE7!NUJ3y!GB7{n(;2SX>D($iQ*inG)!G<}$BAJ)F)JESt!Gtw9+=|``EvMq&U
zxTvm&aD4}!E5y0`qq>6W+!GqFGb<0z<O=^4btajW#(m=R3-Ey6lf>1A{#{U-H%J!5
znV<DrE#m=r1A(M|d{DfnJV;(79$HW%Awch#^%0sw3nI?079U$b=3xv59?9p%m-~n0
zvuK1^4#`;oTxd>Kjvp(hNFLpRm!ph{)xf2?CI;!hrawwPizZ+!qJS+QR$e_I^#ff_
zd9l6J%DyUXeC*fc{h#dv?&hNz-IzbbarqbVK3TlqDBdr{J+-ei23nUSF7S6w>LcE`
z%0LEov-CzvycXoad%buup3`%Agb(@&$rbsPl%6Dh!F3^%*;u&3lHv{LkaUqYddH_S
zpu5g!vlGWmqU~G8%)dfs?y>Z9bUz1ucDVSy3e&x3K4fT#L2F|QuZ{TG>TiG~<2ZLa
z=PYyaU6bmIGvl$>lk;3YoXJi7f_#L~UPloimDdax-yh&@n3qo%TK}a$v@L)efVMz<
z{?O4J@GH;@xEUzr$KP4`yX<BoK3{nv4F&QEK+7%oFVK|+l23q2z=lAYOBw;afIdKp
z9~o@T$%gK4@=e0uvG|&f=rH8R2+&LQ8VRJXJW8aW_-`hbNAGO8pTjmUd+rDExyj;l
zUPx;vK1Xdu&k?^Nwk%XfeW<(|Kq?RCw6innZGj5h*9J=UO%?N@HBavH=?s3#CkjYo
zX|%y}YsKei-uYUe2MW;1*SUQCOK0F$!Sfb~r!WuoBR<RrLfu_h2&@5I45ap20`vne
z1x5f@0cpI$Q9aD(#V^4AxL*U*0oMY-YhfL50&qQW8j$2`4v^$)5pW|g8Ax)5XPKPg
zZzgAuIbjRpcL28o4+3`rQ-QmHmw>y0w}D51Pk={(uYs7$b+jNo0W1bQ4WzoB0itb$
z3qZ)CfIM{c9&iOn?c#=uuRS?`h)?+uM}2`pW27qxYym6=1W%Y<PCKB~u6$j{eG}#O
zHBb@lNb*t%SRPneY}aP^o3HWs+K-;2a-{x5azpoZfTqB@K<cOVK#~I|U=<+w>d@Ci
zv_GQ$o4XzZKrf0A1_Db02LY*_2aENXjKBH%hp&t1`4Wg5fr~=0_<RWPJKTo?s{zA+
zZ72ckb~=jp-GJeU4+QoECIWi_QI-%5Tm+=_%fx%gln{e>l84^FLqH8s;xAuQ@U=#6
z{tiVt;_omZ^_$`1bJVVUjljp--250TJ~vK$ZalC$o`LMLa+~3AKIikb06lNmKDY2Q
zmHQA#{r)kK+T|J02KWj{YX`_C%g+mc^SP6c$CMvEFO4JQ^9NBv8K44K7D(+#zJI)d
z<$=TxqKnUS%odBavmsqpNJsfp1DXM8T&e)H23iAYe5wVk348&xL+6+6sQ#IDR6QXW
z3gdgB-EZ&x%{6>V{Vw5&Rk!^5DBNyTX64Nu+PCZOE#KpWL0Go8di87L)n|tv4|{Bt
znD2hQ?%R9zzm7pL6&(X-e*IE1w9EBo?;R)f8LfKea98uj`NzBEjMkp58MVb?Zl_kT
z6JhD%R-0EB>UGq5Za$S{cW2_Jw5*obcU3jEaCTW2c4up4@Yx>|yTaJwtUCEszUS_(
zI(B+Bq~y%bS?vR=ubyW&`^>9LK1VYB3Sq8e=}vm9vv&JT>{KVJ_VE1kH=2~!y*N5}
zz@fM+<81EFe6$<`i|iXf_6;EW29WKo{welWvCQ6T?T<g&)Gqsd@pfl|T!&0^4f%E5
z&VK4HD;=F)4Aq$wYgk9Nx9U_<wzrb)tz>&E+1_ew(Da|jw24f}wn}O4)})=6`o*B?
zVb?nxf8e|M0ra2oqNXr5X|hH=;X(SbbFVr~lI^Wzdn?)AYIV}1yT!5L6KzNR!zDZa
zR@W6Ly;^Oq^M1?EqntM8n;lzdj!~6g9<-bC@`Y6<_B2_#`y*}?9GYGKuIKM9*2?x)
zvb~jTZ}qDD;=Svp;QTIU>PNF~x+-LQtGQuSYqbrP?X6^cE7{&^^|+Uw{zZ1SmhG*S
z?#n8{zc)VUD2y9c9{l9b({WQrH$OC|regZB-~Je5v+m-anXgW0hd($i+gtrS^H^uu
z-U^@A<REiE=77urnFBHhWDdw2kU1c8K;}R$4&=vukH2XDAE8#oePsV{piIs!|H+o+
zfA7qHOIS^Hg!15Y=qBlH{|)L+Y?kc(M~OB*ihP{;q$f$b#-zvD8F}a&4Qy7Ky}zNg
zRGb#}mmVImu)|boV>O<zg;9v6|JEPc?kngggJS_c_!VV++CJ$+d%j0jIrhq=_b=I#
zZV>4wJx0=<Bz?_JpntbRZu)bbSMWKypk(<u`;hf0L$ar=hqB^uZ%9)!Qa(qhi;HNg
zjf-f?_=u)l=MDTDXp(GLwu>~i11+Q*+8UQTXi|vnO!g6mqVnl>;dXSA4GY;J8a_vS
z=r79F2I|NNuDDEa+2d-9GIfT0_!^tq&+^6almXsur0e=|$dM<qC8-ZOa_rx^O(3-;
z)rDKxlHHlH`EKxSE$TsXHJ;I(V<+f`^kfxHb*8J2Snp73bOh4<r9NeWt2xpJ{mu23
z==^kB<<yyM{0!?%^h$O;k3@P&_n-cxF@WqZ1$(g%iHC?pY9n!s3JxAHY;Yv|Twig(
z?__gEZBi4mVmOK*it)`s<Xa*MCPEWjl)e$J17O}-@k|S{%0<x;h-PJy?tLEN1AiW5
z0~imQDV=1W!}@GY1hZwkF51yh9Pvc5eGGz5CWXnks1Bs3?twH4kte+q)UZkakP*ZO
z(yNvNiWb&hHbTB$j3%-XK8toBTNqQJfcadOmtfVZjT`)>6fmEozqhxeJSa_0oC~|3
ztWV?0p2@klr|y+2jWg1inBPK~E}&hq<E45^<3ga=S$@H@RL^<1+>myySkJu11qISb
zf$Er=tB$D#b!^W2jJ}S|^!GV+%!%W5Y@koW>zH$&Q^%Y*XJ+q7)u1{Ww#cXI{v2tE
z!F-P6w*I+os7k?Riu!J8AoYhbK<PO?w|u+J79aolypX%RPuXmd%>o~z1%bxy+%^lC
zTXfWI(D*u<ZybR%wu2RV8v{Px@^P4Kg{Y6?cNSo8!ECgWfi)1b0!aC+1d>3l0!sDf
z;};*-zSic52{M;ib}k0dPg4=5a~8l`9noU}BtBydV&(bcZ{F|uctFol8$<P)1t7C&
zKwX(lLt7x(Sda|~(NFj8KtEu8V0$2qCmn!PpCDYkFY`W5`BQs$#6<yoXMGlVuzax1
zuk%5?C$I$&O9WjoupuxGh`e<JfWAN)D=>z!aw70I?@RD!j=!m#qQF306v`o;0}ysV
ztQ?FVtQ@F=vvMi}sT>7R2dn~|1O)$dvw>(c9ramj;0vH^yK&;jJ$L_^wi_Kfp`DGb
zbnSh<_a0q-*`nYJo=NAUS2uV)V&+-%>oo>93<)pO5Z~ox+YQ-vqvaC#3#&x(vL$>~
z{}#jBg$Ep{yl7NFxk)=cx`aC0x~u!nKK7*Jv(ooryNE$VVQjgn;M&DSf@jpIb>vQ#
zvuE2<3yNJoY@#ebr+2No@BKDnAoF19>eQ*xF5q1gE9aM%3d`GT(nc&PQKaGM)i(xh
zUUTGu!uD6Z@33@33%_evWOk5ITbEPoFE{EoeAxYq?$@09J}mfbsP&wJBM-rjl%-1-
z_TGJBGp*dy$`QV@?S^c-A=_^JQ*1XjDrww!Jm7fG!98rMcytUseRtl<$Q{RR+uv#6
zcS*g>EXpCU>`vKsL$=*;?I+uA$hI4@?S^c-adyA;wa9>B{#|i^hb1;A6vm0!0lgP5
zJT|X_d5>Pthi&qxl(M9mYuQCjXYY;nSW{QF-H>fJWZR9`&$QXm?)JSj3!0ezns4on
zVk=t;<+2YI@w4B9O(i>Q5GjlYYD-@CtGnred$Auc9DY;ar=QG&=FZrhy+K>R>-E@6
zvh9X!yCK_d%u0Et9cSP2ymvwW`bMGC9MipJ+YQ-Qj_fOk<`0K1vhBvQDNkw!-|OKm
z+irZ{v-7%VMRvMWwmR#yZ0WH*V=I}b*6dYZcMBiN%Ho5W!nns2U4<uQ)+NZc8~Cgy
z2blvh2V@S&9FRF6b3o>R%z=L+2cT{%bpDI_|9SfVi;oPCQAIJ;|Nlk3|MJk*oeYJ(
zSx_D`7DBX|s1W%5BcC#)C(D1Er~fS&Zj*ZHf0v$J$bMG^!{g0Izb$6J!P`Z&{wHXV
za=(F+&a;0$E)a%x1hYX?M*ZA+_=Xz5x$Ov;XE@1_09xNR4HO?bi?gw&SQPcOI?uW7
z25tx?%!yJr5;BAlxS&$Sbolpz-k^pC^v0_rl;H^~O(-0(k@E3J&hi+EId%}%HlChQ
zs_5WQl`<q)73{7KaS3y>54N*+vkP``3<<G!wGVM{aB+1BwrgN3rF3#~b+lKxhT5rJ
zLfz~`9Mvu=m77DTtCPK*o4u=>O9MsqoV39X?hYZrZlR&}ZuU-2YI_$aXIBR&2Uiu!
zu~P*%P(Uw{@kRlZf*JmZyFz-%L3%x8Lml1Ytj;-l$j9{eIXb#Iaa>1tpFR!O(apKf
z(b3I`<9f*H&<oxT9!q-nq@N3QNMSwVpl6&wdXyALdfoAelVq6Us1Az|7ZRmb#UQ1m
z+q=2ihkDH`pfj!LSXeNEYbB*RLUa{j)v%$J=nE4bb0GaOyg|J>e|0N(A$0ZjbMf|X
z=GCo>lVNU=p<Z5AR_(mMDKi|19wy3SV^Qxt8g(Qc+^)FhqONfb4E66nAY3nJUzVN*
zAISrWKIf4c^A|>X>1m?Qw$vtNz*kmcWT?JPVhq}(jZoNp748lBAaT{hL#d2%@bJ*{
z_DfO=dMLjgUzy(*`xf#e9rw<nT|uhIU+Bm(-RJ7SA5qrskH)54HbQxgJ?LPcvv*jJ
zyd~S9fp&acF{CB15E3Aej&cE9_(aNRF_YRl1Ou>vz11iEtFoczuhG(9lsjwcd<Yoc
zneH>$B`g77y!aUS)y?-UE&aK1oAjVb{>WBkA?T3C3CY%ooRN5nLP_Hs@l~qJi#+PG
z33&(~*5!+$lT(*3CjIOjWLTGVUs;zPV!KQrMRWv9T=ZupTq<f8E+hJO`O?H;I58oM
zuckN1fL`LUM3)sQt|NSpi|C@cegV=dKIE~}m%963rEC5t=-QqKU2Bmx{X>3zu|fYT
zU2AgD<sr7C9Zh5i@T<UVYv9j8n1ZyEJ=wTU3pI5g`0T^lA`Wh;)RdO`2ZjxOpn1=Z
z&D~!5v3j?DtS(@#VPhE0-S#m3p#D?9ymwBVOCE7#*1^(+=cFTX%^gQ(d%5EnX;ObA
zAAwW}rM6!j5l`_n$J3n5;>8J^;>qut7HRlWoclUt_H}5x3gA;Be*2yAMf5?4^nu`2
zoMA>tL-I&I$mVj|1uBc;8i+hETO5fHl5o+mPdEelWOy*1lbb%tjj!lqE|x}=&-4v}
z@!gbL#0iP@C?6W*nT4DXq`xm<-irUtY@Nt<%S(Un%Ivb7^!I!XWv#z=X1`a^-#dZt
zd~HPbmBh0IEDori8gWi5YziU}sF5Vw$_c3FT3%1?r~7McEAyP={+dl?f0Unl%%(Yz
zY_cR<MQZa3Xrug~pXT9hj9xxx(zs7;ZfH{}^`(JgeQE7a?TTg>j^ixcAl{cE;~`Qp
z@v(3Y$R!Lvf2K_pY#sb59!s)RtOVr(|0uYmGN*w)JAIk3W=@DBFQIrr`1*3C{zGl6
zREEWBqE%5;4$(tH2JsBJq4)4McMxTJw@44oeMArW>X`+4CNsG)!Xr^|GRl_GpQ$^S
z=e+7J`CuG?@_E-)YE{8e)U}x{tQpGRj*AA1AGxeTZuxw@4Gj{9c#=`NTtu3KP)7>g
zaS_dg(?N5po@Tt6W5ENrj-mMJi*!r<u7WsLNcR@{`vT@!U(t_Zq<+NS20ygb9Ys9-
zoBEL?_n%w$tVg}6JxKly`w;O_@~yZ}q_ZN@5+7kVCUgg#>5`p3v(csDjU*=+i%7{!
z-sgErZP^}c??mJ!uI2N{<f9e+mzEw(1|)xtekD-|LPJ~yaMi~}qvyg8XgBch%Da+O
zgLouoazU6!V14;hHpbXtV6;d!#>pZr)Rl-9nl5UQj5>+$T48Z;l^e=r{&VYm;v1K9
zGuATs$#@aLFyBnXnMwJ^C5FJwFT7oXBGl+>@~$JwXfaxtBV2;vB$Z1z)&gU_3!_=1
zij3FO%LWpbn)}c*6W0#(9KGj_fQ(UgQoqsa$6r35MTqybjyUPg<~q!0PP9eB)&eK=
zanAbnK~9{Lqm*vDKAjUJi$9wa=S*g;EWeyMCnAx}gYK?Uxo+&fn*N^l8a|#EX*^ws
zdTH@I`G=I6kkZn+gVqSrUIO_)UW~YzXf;Zkt69)4CgykXJBC1M48+{RmkgXfzQ#F&
zJjsVF$z2-K)4U~)nQ`2kGVjxO#JsrUQ9Cw{7KU6jF2(%X31VGYKKqcC#$GH)FeXYA
z^RYJ#?d^qUhJc7r&JVWUI)rDa-b!CM)1_G!e@kO9&9zikBAy$B_~!=CZU4k`(lht)
zj5nTX$J>$deV#<0DxQjDacjl6ut*Jyq~{0X*;}~4A|YCQp5_VKbILtW&{|FqWo`)S
zPWM&BdulhTi_{PN%TlTE=Z3vT5|-XTfAC$w`xqZJ5Kn!}lM;%7x_3q{8}$vKh57->
zc^79%-W>Gn<<9yzM`y~0(&fZCpi~~$N}tX_pDriPQJ-H<oP*d$xEvEBiEvuqk-XCU
zPxYozoaTR$ZITOG6Og=0QbF-_mH^2MjV#g+#AjNAOa7dxJ<L$ii+EYPj=X0xUeUW{
zj+~Q?zqEQ{%Wbtr6RY86Q=1VzAC_%w-U|7h#WfarZWQyRzCiu0E4Y)pFBr-s(c^@+
zq;-rR8^d_rNtT)Xi}FRZr=bixq^*mzN--_fk@{R-vUEYDB>*&#EIknK??4E+EEO{c
z%Y<aMr~N^##R(HGY_V>R64xWok(Sc)ee7>LD<BBZ@%?1J&rCM|^xoVN7lnPW*(Rac
z4<va#2y6^I1Z)XB0_+St3Z%u+2_VEoI0cLYo(4+v@x4OkOHqix3jvDK+t?pB=C=JO
zfV8)G8Yn%-_rSjWECaq@^=)SvC{Q-vTjG08L?^vVS>U2@N~B9cH++AY?M>xQchZ1<
zz9+)>O31d}u-;DM84k`s+Cy;>&v2mp`JM&e%gCL-Asu`VA@6h&9qGuAzti(~eWHWb
zXJ>IySd4aZ04@Q#1D685fXToXz~#Vpz%{@wz;!@s@Abe0U<z;`a075K@K@k?;AY@F
z;1=M|!0kZf!Th2g2JXTA1>ip54Itul_kbi<kATO4BnKo{1*jo#c7h3z?#+RxfwX6F
zMobrkB>X*^zgJT|4dt26NT9VTWSRL5#(GcZhI=nyW1u(C57-D82=oC)0Gj}N0-FMf
z9xq({J@#)nvqF3?utA==<zqC;BYMXGF~reWrtcU09gn~J<$i9M_}p;uxe?-X&5#Fw
z7vp0aJty)5zwk3C=pKEV`4vT5vokjQfyAc(AidLpH;fL-kH07J_om$W1tT5h7Xq{e
zf`=?Wj1g=+i2>4@8)JpOUi`i0+t2Xe?-_zX?;pAO;edWcbT|S@?p?)xM)dPFK41Ii
zroT4mDu6T?+u7M47-yOPT6-Xk_YOdMSHOg+r=PFW`8qo{9raKy<>v`34y-TIfqcbv
zc;3%>i_bL@pYsu)E1OSRWAimPmFI=LiXomtGW?~2MqxRS`t=H+7jP92vMj6ywgmnH
zq<*{+2w4#}0U>L`cHk7?4&Y4SPT&IIZXo))um|Xf{<jwhAKJoiKri4vU?bom;4a`X
z-~r%C;0a(V@FMUu@H+4e@Fwsq@B#1w@H^B2OCnueAYKu4Xfq)V2;K?51HlX7Hn0Wo
z4zMHe9xwp-7#IzF3hV>S0P28$07n5|0w)7s0p|j<fQx|SzkDt5J#Yum2z)*dGzO*v
z^8;@H3jl8c3j^N)ivo)o<6RAC0W<|x2ATtF080XE0qKk$dtf<W3m}bWe&T&+V0py*
z11kc1iNE(2@B0F)B7Q8e8gMGm8c1`t4e%$REpRcgHju_C9eByto_tM8@&TC^w1}rb
zew|4^EP+jcRe|X9%+GE=Ao+8qbvgNSCb_T!P6CoY=NUj(;98(Na1XE^@DLEPpu-r>
z{HR|ALMC*-0~-S~fWE+2z^1@LprskGIIuYoKBoovy4KkO+W=99&<@xT*dFKy><IJ+
z1^{~k1Azm8J%Gc3O5j*v5O5AK6u1N!4%`on03HWM0<Qt1fNy~DK(rz8hsj?8unO*x
zx2`4-{M6Y2hXES`M*%~CV}MaWl&OmWP5{!{e<JV&>gkUU60*PIf99DtuN$Ec8JE~K
zx`S<jdSQ`XOFINTZ}vk#ul09~Lh3jye3ra0@nZII`OKR+i{vwJ<TG!|IN4m?{PXa7
z>DwlhOYWc2Y1lIR21D0POT}EGpnjC8?Kindg$XfjE^auv!Sqy{)n^i#mU1cNJ3r~#
z>k6Td-(##~>7Jb15}&!wJL6PZ!|l)SpNKy6da(7e(pBbND)MHlf7Z(L_^!*+`A_Xy
zeCP7$$z^(--yS}_)r_};CxtI9b94Ts%*12a&bP40N@MA&l&tvcVYh-W2b^hSDlDC5
z9a6WRX|{9p4<<EhSdF|QpLrvndGk*>^X8?J`ccTCU-nem6+BI4Rm^p{ZMaib<Hml0
z*N2&yXH;vtpmO{W`OF*n%p3X48}lRbnK$y8H}aV`@|idDUf=)y@W#M_&Xq>L?>6gZ
z@TT`y+Es8YvU1*wUcqZGpTIlbqdGLNR@ji*zsjV2p8xx2-n8pT^{uyb-_7|&eoWg^
z`uo{8w?1?~(kE``7SBl`_H`eZ>3F9(HvJs1IjJyCe>-34Q?5}+wX3^YM7ODGGwJc%
z!Udl;e;hSKJ{w0q8)w1EKIhBSDR25GHVeCBGhAUjdQV8vU4!;L?w9y{-<4G_%D&qE
zw$+v<H~Jpc`1Lh8i|!`;#L}hqHoN<J)|@Bu**NmqIP%#zJD+u%*8N}=n_~F*xy+UN
zk$g6ed^QfrfqXX3`c?ATI11xnU59qf56EZZw0c!^Qd*`dDI>^1=D`1F4&+C9VLA5y
zDm(i?W#3p$uR!O(_`v2dWQeW~jZ|sXfqg=>v9VF{fl-mceL^$|G1|yzb)6WMHnNX8
zP7~WxsdROAcXxDhbF>eP4el8lnCRvbsMW;8la?d*1jx<<PzXXHc)hA9v`@&V$JUV{
zn%MZ*Fu1R4Z=+}n<?ZOm{*f`^3ZK~MIG8JFgo1*Vd6Q;N&@;3$r%3o$iYHc4d^~i6
zivpECaj_Ixp8js8idT9!Zl#RxtBO;Gs<p6sp!6l_w+>oOY)rT^7RKfpDb7!&A(vZH
zB;}`3<2Ei{uw;3oP?ZKIF9y%TmLe)DSOt@&57QuFPF^{QKFFspoeaPz$VmWNsD8>W
z`rlZ+G^&_zH7aIUNA`CI)D6$j`2a^sldc2TkM9V*2?{>A3gN1ct9=zg*zL=7*ugFj
zk2qDN##5<mqESVwo57eEJa+W(=&0$}h)lFvtKwjmgvKY2gSKCntiit})32lvcKcsP
zB@)_^F6`IZh)huA*jY*X@TL`^m(f`j1>GsV9<dZhIw++3D)~%&B(??ARhYgc>27sG
zTbMP;X$x2-^~J#lUtLv+eq@zL$nir*Wiq<FHQ|(y=#uQTld0n)fD|SpWM^6&^~&J(
zrC-O)92xm6KZz&AyDaDt7eyJl?bb{vE=Th8JS9D@$e2)dB9LfrBiU#W6A`ZCqCc<T
zx{Ev%UW}(7(cV<8ZBJdOZ5ZS`zGJLUgqpf6qgesWBQRYe()%ukABjGLp276Q%@D7}
z6_TLopvCY=c~E)_pfPxBXlq9CWfA|h0`vo$B*cU?hiQtK9#JeGAC)#FqOm$o8^L*%
z0bWu4)iI$YW-M>gH7^TVsAHl~4V5qPmC{0$S|4}MAgymqD8>~NbMnO~=E<IWf&14)
zlWz>z&v`8Qsw+kV2LcV6#AA>pBr2d|=uJHKR{CJ%V>Gkz!h!LU>hf_YtSgB~Dxc)>
zXV4$lz74An@isS4NUxoEOFR^n#Jxj9`Dickm+GCHU&LQaTy0u4^&yiYvMnKbqkN!w
z4r`zUOjWTlQf9=rTll>NI)G185QIQ7Cix^xCSnmxjd=ek0$iy;zipIL{|>$#F*L_V
z(I81_X-x5=Kg1w*G2C$;Si-I$gFP?!CWfG`L646CZS<Hl#=QQH+J&WJydz#2@=oGW
z9A%(RB$lvrlKjOr_F+8!7P%w-Dx`8+t2DjT8par+X*YP)2E6Jh@`~Dt<cSJy92qJx
zLf;Qa{uY~~4%|S8&DHb_waGFR5|@j4WIvF~c_R$Ob98@Gyr=YrZPS<(p%G|YAsy6O
zxE3q$ACpZZWs8L9IP~%lIGcOCH*6cqN8&rl3%U{P@;E<p^PT7~iS#^;ZzDhaZAhDS
zQA8kg#YJS&?{gJ`;3d-5DW)%mv^MH^n6a|S7n~v5L~%oE=)AK3>A%9_I8?wqhCMH|
z$I&gC7(Zevr_ZoYQ61=6L)nqqiOEjm$oM!KXT)}u+JovG_d(8_{}H@Qp)uOsu#OpG
z9b2F*;$stB-H>K?V?O?}zS)${@)1`S_&qoO5hVs*M~VN2w9}YD^=XN`r7<HfxtGQT
zs)ymYOL<az1(o{n+!|?&8)3ppumR9CT?1DT%_BZyJ#c!HR?S+8jo4HN{=`TB>*ot<
zk3bsZavo!25!Hk7S>N;92KQ8x)zOE%brKsN`s8ff?FkG<etsfNO&~qqF`=Deq9S8@
zu`)iEAIeh<pQVdze#U?Yban#0ehy$|@G}93Z>%0Z2^xc{FgYMuXduqT3g{(KSc!}J
z;!<3JXfHFq)>KLZL#*aQfygZnBu6}aSsvQ{MR}n5x}mOQ6Hkn9#AxJmE7g~^k2q}5
zKt}a6lzZtM08f!p!Y(BDV%sQv5)&D(a>V|lzAZiq7$dfgIhz+r?n~=Od>W6;ne0=)
zMLZjaOCwH_f5hoWeoAYB9EpC!W8^0^XR=T8E8_I44vMF7oBBj)y_eb#WiZ2(Q<=M-
zUSj{wT~8W6bB|#>2m1fNx1JYEa4K`xQ}{$Z9g+N>SkG4Cs8tX2(>RCic)=fXt23x)
zE4&c*jE>{elUPqcUV+K2G+vJ`4_lbvgfL1-edRe&fs4Ou@^{eGd>`7L?LpC$&JGuU
z590o2?;#!0XN8Nx&jkb>-7f|f1TFze`SbS_{{Av1SN@yD{MX_c{!YN(6*6#-Zbmj@
zES!LC0p$z&bY+02fC}JgV0GXbpe^tmkYpV86U@fv0<anGF9B(sz5?tEOal%AUIh*Z
zUI&f@{tlc3guR6>8F&*28U@&0FdKtAK=uv;r25Um#n;(<{Y`Y6;hKPp!eHp)6Wy>6
zV750SfYkp-0@18Ym!Iac(YUV-B%OX2AnEdxtdlN(L*OJ}Bj67}s?Q8yAaE`as(HdZ
zAdQ0yfDyojK%y_mNLmMDoq)fIKAJ;e%fJF`c69XmKsF;pH|$?@7;Xd$AgxDB0U<Wb
zhJ@OhY(!`cR|!abt_&pl6hL2K6<|xCC9oZkY)85Pt$;m%WJ5x9RtH7_$!3J!uj&9b
zK(due1d@&70H8B)Fwg}!0!X$@GlAZ~`9L2a$w*`13Sd*<Mqo4GZ@}ijOTf0kbYK_Y
z9bgdfF;E433JeAkzhGCvY$rm2nYa%FW&@*v0(b^H3td5=21xH2@j!Ym4i{h3^0hAU
z8Pl~8O7RF@kn;jS@JL5Pb{in^xh;_7*$;^6L+Aul06PP#0>L{b-~K>qH>_0|{{w(h
zxqQ9K*Ri?ForrX_ww(<$1I__bze)m9yG{Yt0saK64}{F?8UvRDn*za8U2`DT49rGx
z4Uo$9!o}B+f<S9aDwpc#gp0xk$X|XS*>q8PJAppHL%=4$!$8W1WSOtwxLi^`)L*1=
z{x$e(jQh7h;^&{ha==WW6)+1({U;kp`HjKF*I#HW{7v~0zX#%?P{^3~$HG9Os|b*u
zFA607ngDA7VOPa$4^4sIxGxT*dYS>zMuIs|1uO{+0mA-@$#q#^Pu!OS5<LrX@%0s7
zcM&~!WfG?2qA(tG6W=BRX<V2AtPGq9Bzk58?SOND4!{M#VBjKPFW?d&^_SJaX~6Zs
zAAu=Aw7IYWI1jiHxB$2bxCpovxD>b@DACE+Mx6J#>D-BSM{?l+&<J=CNbPb6NbPkP
zSO|CoSQvN|SOj<sSQK~)h^3rx9!T}T7^-swrU6N2t^%Eb*MM%o>p%}+I<Ow_cc4Tk
zU)$tOXLZOGk~7;eqO&gUiB7U1BRa{3jOcU#5}l4fqSFaTbdpUO(b)h<bou~^&c;BZ
z(-%l|HUScyO@TybGa%8~94OJr*Cu(>`2zJpav=*ybY=sI&UZkf^F5I0#F)eAGy)Qx
z`G7=cAt2FN3`lgsE}79;5=eA@2P8TzfJA30AkkSGNOYC~5}ouLUt3^o#oyHK`Ek))
zN}(Il5nTbm62R_2SD*@rItY{TBaV6y%!~%Lk00N^qPBHO-*)Xy_pb|ujG-cCMyCgy
zIsE?R4=?(SuUsZ&LIC34pdw~QdlqHxYcR++<3Wqt?pIG{qEp+WVrE9W{9Nn#bT68n
z&-rSD0{edIi!qkPUp_f`z-7M{nI@qxJ*;Y7zJtDpj$~$Z`1sJp{hmx3alq+^ZbRPg
zZ3H_@M$g`i-t*0VxYwrjCet1F?;Q9AV;wrYnUSVq%Yuz7%=op(n{0;*-7>5Np&z5O
z&6Fw=D(xzeU9WTgClRZ?YT_LW1CE(d=Hqs&J9K^f{W#ByLEY5#T0>S;6u;wm)u8St
z$9Z0>_&(*V=E`RDG4R67s7afU@;Cio*cOSakUqru%`U_<dUoABZ)UFC(eQPJHcLh~
zKh+Sj2S%G2Rhk+4+t3&7Mr3<7U9ozp$y>;h1;zW#wjF(_`Y$#MyL4IOZjp`-GL*#!
zJbzd?x%Z__y*tn7+`VgB3hZB5ytleyk?{_vZ7%N%@U7o-JtmM8mj9LhHw#8*ubFOF
z^}eRs;5!!t;RU0!WZg2pUA9=8YGdjg^SD>jMG*S1^v{kYCGC3@mf%zByN26us|G+u
zS$z71CBxgrOm%QAVR<8FhCc+<lksQaqTbK4A1W@o)_yuLxXJQWIE#g~@7pe0SG<0!
zxxG1cf_0}2Gsc3StlY@z^U^~+?*+WRb+*@p^0WHDPM@VeGN@p9!9}wkbe+9+#EP{i
z{4t%DB0ikW>~gAB`kzM6LahpQIiK7H?Zx8n_KVECdZg`=1KwNvm%6bSbgpIb%S@Ut
zo*9rfrM%l(C*#ijzZZo2EPm0ty^Z@fUlj1zX7uwDvtz>qA%V5ayb)@rq&vgPhK^Y~
zuI;mocGx>*?dx^0@yMd>GxjcQT7G3OyOR$wKb0nWI*rQj5)u&otn18Tw$UpuL$0<l
z`5ZL=(hf6k?RS$72N&=DXRmn7RZOlHB$`fi@M!C}`9RqYza4H`0r4!o$;|Q(4kZk}
z_sFTgasGkzT0pMQ;mwTl2Uh)U!Q!fZv+LDd-udU(y|J&%%C+eC$K*m0H)6)PWS29W
zZ$1cfIE%NlXm$J2mX2HN&0hVW<cU;T6v;v6fXspaISybL7P{qp|BsEQkN5QLK1`zy
zjK&_LS`(v=3dBjt@qr2WKQLYs5~zxcqd(c%S?a*VXe~WN4@5fRqkl|Pe5gvRGWg~n
zMBh-p!*}^xafS8x<!}D%TfMRm4%pXfHIcyyT6_dAjql?T>Zmxi#xR!F_g3aAZ503Z
zuLO1YP>;=9Wwa_r6|RoP$*(+(q$|(``>3&f<FSs1UO{X^3@B!2_)|XKjheG>?VnD=
z&*PW&k+;)g3xU>jwEnA$i_W=I@Nc|IWt>u}j1E@fTOsI4{LCH_Uw6@dHto@wA`i}E
zoRfqvhO{3}`;^joXwrU5GnB{6;xs5g1f~i7`%XzL$A~U0RoMF)rgrwegQ1?i50n8C
z&1HcvfQ2!?$u|D~OdJ30cmY=!zcC9sJ-FiBps-^Z&EMLZyv=uM$i>#dJF^BFTPB6v
z-timG4`Jzw6>idSd$+2|qv~{toL|@Os>Sj88x|KazLmAyy=Ir`wXqJV23b%Te>q(e
zOE=zi>Y?CLuU&lJnYT_pJ7m$Rghv-nH?C7js5O4thzssmpB`iBzO4IK5NjHR@yX<y
z!O>gIBWBOMm~}p&d*+MnPba1)UAT2`XrH8Jr_|VBXvorq9H^RH<5|94?TlpG{dzZK
z+kM$~|8k+K`yXG#o?;d1N7rr)sZnyvUE5{jyqY=1cQ8KH>q?bFD?F~QT6X1#WtguG
z_Iy~nRd0Ul6r=UH-~4gsCu<t{uOD_Y+2PC<7rXFvU4QPf?$jKdSH{xaby?gyYw(+Q
zdrzcIt$OT9w+*kmz5A|7WXhTrnLTa~i}uF*9ZT2dR_XPp+xVW`e<tvDN;AhzEuFIG
zxX&0EcA-;|S7$cA)!>_}CDHfb?tSwcUGqJWZTJ5vw)<;U)NVW4jXkq(*7oP+uC?Bx
zG_C7iVdLwWn?q~<;h)*Yxxj+z*x>usiqZ|+aV&Ai%2Ew#dM~T#7Nq#zamA)v(Td*F
zk7P`%{$ha557@I~=@LSpyz2hG@YC;<b{#D4&RKYL%(#Bbg+Uz?sx~@2sK-LcRf%ep
zpM6^I_sfzJ8Vqz^S$FB)o->1ov^zYw`PEa01rxumOV?qs(}1Px*UPfHZsz1dV@GT$
z*Rl4{33t6GpEfr!UodU&vfswk>V8`gda-o(#@8rqaec!P-O0Fw{_h(Fcn`1{St?2M
zyyc9RH^#14Vo|h^rEAivnQx=c>E%Nw^}TuKW#7X~b_gBz^e??lbH;MS+!pb%_$I{C
z72Yw=Ch-3I%SXz}w)?W}zHGan^-8wgmu>fD+kM$~e^>=8Rc7zF{(Emsk17<1eFi(4
z&t;qZqp97s<J&j+p-VZ3ZO58Jhtr<;(qv0#XW1rSw#oM#ePz<av>V@>FWp|G@ww}_
zO^=U1Qn+5j0CmS2m4=uc#J8w4Cz6+YjSp&~8pTJyZtR;9(k{*D#@u6126cI$_@S?C
zlP}xk%QpEBQ(w*wD>U)JDwlIJp0t=?cQ8!0$)|Bcw#k=m@<|T9yf0t2KBen1MOWcT
znRN+2&pg)oec^tEhM&#4a_C&$yW6y?V}H8L83|obmhQ#$u%F8&oM{mgnC}mxi{JN8
zd>*)^=^y9sJm_6BrSk^cNjQI+rE8ybqW8WZFAOkiIdXKA`r`RJ75hJ~J-=n>9wUn>
z*_~tY9c(2_mzg-|O!Vt&?ff?8cMVG%GsJs;>Xp@IS=9>pHW=`rQ4t-^S!d}64t3km
zAm3=K^lXcIH|BX=3+U|kbNZY3&S5qCURhl>93RArG@yF4EM9Mq+k=%84`21#wXVp^
zcZ-jnKC))&c@NnpAD;o`@PB{<|H}7&d`pjv{pj<*GCoWTg8=^dA9h8a=0-vPo8SK>
zpL^2xe|%CEpmqiw1=y@%A2_Hfw<8nP5x^`uJwUCB_V9?n=>)2neo8PZjGaM{+a3y8
zh#|+Go4)<GK)#awG=2YXBHCg3<>Sfm+Q@XoYXSX;21y5jt3>2Q1F5ZjMkgVse9}oU
zEMKw#Q9!XEEJ_s)^)!KKlI*lEiZtcsi`VD*qE$!3&8JGE=gz;%n<(fAQXoBvVz}@b
zf$?VHr+Gtex}+*G-q3SWpgzOHxAR77FG0+t6*8i{eQ{BHWqg_@I6%#zig@yO(Im<7
z2$3e@QvqB}aP7x?rC)PVj+x)f_=wm9I7dr}S1UhiDK1BNEU&<HiY1vD3Yp=Zfy<0^
zE&)uESlDaC`x5-MFdB4{%y1fL<WUBz!y{upA_B*TC}X&zVdO-7f{K7X<g^{vwILf=
z(v2Z{;u3<RB16PJia4T`**IhUA$3%Wqkh;KZDmM*d$Avyk>U-)AYAlkKU@dF!-XI6
zkkJp@{?AhXX}RaLOT3(K!TTSIg8mb?na!&{q(6kJ2$!r-SDcyhsk)F3w*nU*zbH@m
zzk*&annLeCtSEG~_34<*Lf1NvbeYg8lG5>hpLc$wdoHEp{gU_B+~txkyOfUi6+xgr
zlsg?%iCH>7{Kn;%=XVc{O*-(6aZ#v>bR=?M3A2@`4ul?*fKTE&FCfNI9i^=Ur2YUs
zDVA?xFoVk^^BE*izLoHM7A^|z_?hMc51<3k6Nn`z`Qc-J=DdL2agV&2zar$#{EjsR
z4n{osAhWrE3a>5+_bq`7fNg+Ff$f1Qz|O$EK&UqB4g&*#=YiN-)m;Pj078#nPyx#U
zLxIjfHIV$zgaP4WMhFMS03(1JU=$E`V?s1A2^a%h1;i&#-8NtxkoqQ6i5Wj|FUmNV
zec}g1hRS0B{Xtg{f1z%=l0Y5)kz5T0QvVzd1h0irKri5EAk^ZSzcAE=`3vg>9EW)7
zQ&WL2==X}UuG*fv|4d!AAf^jup-yp|VA;M!-+ATIE);q4-aK;J>GDFv9d~Q<p;y;0
zYxke?N0R`-R2cUTE%W2$EoKeFHw-#e<I>!#t}Z21!GBH&IXP`~gRLuv1jC+`rJJ_#
z(&ZY<3eNiJY5bWpKb;=gdt>9l#r7<|Vp;EU-QsU!F$es&>&VqbUs4#qyV}fTpG|VN
zZ6$4j_xK;(zy4X7-*z7fp16KmtEE5G`F#)UWm$bU{ZcZt%k^gO9Vhe|t$OBgSM$dC
z$Ghc>)}E~ywZ&p?Ck)D2EM44c^Xfvqj#|&nr;_aMOx%=~)$;nTs>T-1F6+YXY^^*E
zeVvtSy2x4aSdsYamHLlY9UD{gPQ`O&uAEsj{QF6L{=9wc=R<ZF<5)V2v+Cqm`JTJC
z>e%VkkdiYyXSENgzIvYB>@%+}`5ejg!{Gjar7L`Q*+Y|JgLhoG{pW%?>Q~iYE~~a_
zj9<+?iATa6eXKXn!kod<o%B{`?e>}2sZLbw;rZupG%2rpadhy2LvdHe+1#J`X!%2o
z>y?NvcNUI2d$7mb*mHkoy?69#w(pp##OxC8dwLYw?eVO2Q16+TXIQ#=e;n;N+^6Zd
z9rf<k=$?MB)u!K7zKiWTP51P-zmc+{CkD7-ES+zmCF%QKR4kWVyp+%IhUJqc*BJ0y
zpT^(UNF1>(zpTU8BU9GllXdtm-`f#9xudY*^(mi-hi5i^pW11wbIW~wJ7%p&?Fu_l
zOX`>7PNpCH*`sy08`T>24u4zAR5S6xs5cH{PuxE@d|yDB04!WyvUIOfr;gAKvrGzC
zWH#~lm=Vx*y!M4<i?)j$J7;T0RzHWuM@=jS6~>Kse7~{mUAwI&>Ao*oG<6;|zwqmG
zEj9<*42$bqxMbFQ9nP3x>CS1Ul<IURw9EtTrb3sN^?G{8Yr)`Nqo3^^c>Ld`!{?5<
zMqym2N?iDaGw<&89eOXRW?=H8RgHVT*{GRxbl^g>O)C~z;HA*Wiqh@r+Vx>b&9%=5
z)jC=)BL28_{El;BlOw&7rp3ISmbPvW)@Sutx@8OEezqOG;9!>#QLuX$F|>V3hfWon
zJuTF^j9Zlnlh<65b@=|<boe^fp!OYB=UUR8o&(%GQ&*kHf1-@hqh_~~Y}#)bZkc3X
zd}vkU60jkxPU#kGKmTN6*omjQ#Al^9?OT-4XUX1W#)}8My0@S}_{?rPEU53XbkEbL
zjHuAyUEQ)n?iw$A8GP(c$0Nh;OmK3UwKnF!khu%-LQ|QQyWV6^)!ybs#+k+qnzk)k
z7;8Riz$Mpt<@!#(S@j~<^=ofU<u<DtoK`rWaqlO^Dldq1TbT7ov%9@@(-hZ&jUH^t
zj(vw0h9P(XP#C)wP*o4xxO~ra?{-5j^jJJ3^6i2$4<gFUvyZM|H9-^E67L4AT)U2@
zDcx7}JGkWNtOC>Rt~WCswXylHv+^~yo|ycTuKZQZ<?C3w?&+5&AJGNcY_9H-x~F)}
z!DdNAPA#k6b?DJetIao`xR1I%Wa-wn&;M#@>xu&gF0<KC(R*s@t-hAef_JYwWBGRa
zt{?r@gkauh^_Um5{p{!wPw$_2nA%0Xuaot)pU#zUop?2Fb?Ps-h5V)P($&+O>Txf$
z`|Z8IxrR@v-z7Y;>Xu(0h1-qFti0Jn`*z*E<$Ij4&Kbe-^B?6jdiOF}C-B>K0t0Fi
zp9>yc>EZWX!R$+AdJ4%60=Cpyd|{Mlc34O!t#gf&vmYOTtvO4l>>T%|aGdkggx&p$
z4D)(eclT}E-9f7J!`}B@Uf0E8Al82lEZvHj@`_S>_chFjet-Fg?|v?@r110~4zHRz
zbZfO<)rQ*m;H7&rOSi~mSCjCR6_?$L_R?J+*>J&*G|vN5j&yOGTQ9upvvRkggE5+=
zvuQHLzhwV}HKR|PMr3;)x|dlp-Z%aJ^1f4(Rn_)y?XVX<eObC?zYD=WisbZ?Zj<*5
z<BwVn-BZJJ*@=L4r)Rz$oxQW)LiohRoTM;TA4`pV=j2>&*`tE9j;-kyYdq%JnzAM{
z<__yUxz;StwX<=a2TQkONug71>v-j>@6>9G&(TZco=4wXJfvO;<*LZmifX;fKf`-D
zOZS8JM#ujfx`?-IiGNeKwVRseJfXtC)Fk6(?y7yw>~?0)T(Nubo~8XR{*<|V34BJg
zbobkP9|;d0`EKv2mA&6Q*fo94^<xR++ZyUDj;&4kwfE{9vg~z-^QF~_hOZM&mRnHU
zZ{5~Pjo+SV<>A`v^5Bg)r-r3V%ns<ic;T^m70i3|dOmEEN2Qb{&0NbaYC3yww8xsd
z&x>Q<iluA5&U)5{S|>Z)ev_GS=SunR4Kw>MaBt&x-LYNzu+}ZcH-hhYmhRVM+5+R<
z#!oUYlrp)=wYE2htyteTqx!pXw_;{4={<7M3fS#olS*NHyI1_vRqI!zbPcXFGr7XB
zU$6Im+2xmg6IQQrf0sTt9<nBQv2;DR_Ia@FQSji)SC*`_v1>iQ?u&;>i`3aemlp{f
zS=kF`GzbG(x{I&p3;QqC{mD7v_~Fno%bpe5IINWIrtWsD!m1mUt7v@(=YOztvTo!5
zb=}5TYyc~aUl-hXeblKP&u!mL9F^AZ|FQQSa8c#j|5s7bwSi(|EhA#VI`pan_Ku1b
zbeIOBz#t5YeXw`2SL_9>VDD>Rdw18mvi2^zsQ6I%e^2gQ7)B7>xBGwl-tXq)^~>a*
zBqt{)<t8V|l$!p(AE;gF+GW{{Hs$7;_O6HaZ!x3$s9DkU)1Y<n+e5omH`(;VZtpEG
zub4F6y&$s5+dgxoY0kKNozcy&QpvQX>lvrA?Y5f^I@2g-cvsO@lH}}m+QW8PflU@`
z4tIPx?T;-bHb+hGnEFYyl@x6yf1W#JzO-_u0;7(#kDcL*bu1^+mwuPWPUAM)*J-p>
zJ+X95;M*Oy1I`VtbxUpSvu1mT=C91L2Fd7#H&rhaZ6!rpNzqnv^1!a`JCBH)exq*7
zLZdKFY>ve|(N=O-8PQgf^gy(g6m2E304+LE0-^*&35XI9B_K*bl)!(P1PX!Q?tk+9
zztG@F<yYqaDn(F4xRzP}|1aA9mtxkVS%qx;o9^O^fdOfla93GDo)*iKY;OS0+T*r6
z!d6IOur~m=`QVsETt0|16xFhD4XludxVdR?$RS-VRmTQ5!;$%Zgc^47T3J7hW&kXl
zRca4qKY2tGNfSyTcU$2s8+Ec<9tvAwVgG<|C)ZZ+L-w0wyD#v4EC;@KgHHNa@I9Cq
zmuZRhe~0g#27F)UN@E5KXP}cp!;Qs**DPP*_#?%T??`n&SrFY%q*lq4xX8={1%T@d
z4Fv8HA`exl<T5)~g(}d=&e_RTtx`G3oda#{9bIhgT-DM*M|(#{Rg?Mxr7F<X&dy0?
z?<loXsiktMv#qVtRVlZ3L_i0r%C!k@9u#OD99>-Ha<#Lo+R4^2&^1t{w6k*vbas^o
zDqQUC)OH4CDnT9uXNEr{w+o=00+>zl51gC%MU-iI_?N=nVttgPQ=E1CjxMn6E^O|f
z`P&xOb39F!pA!q?n@Qu$!esrn#q2vDCd<!}*^JXYbPKVDDd>@4hh7VE#ukMr(k1eP
zDGK)(c8_u;f3_z1Q69>HP8p(>hk=s(=pHsL{Bg@$R0#ecJrv4QRRk~K49hcu3RY!M
zfAU|R3Z>M}*)C9N=jbF=t6iK`O109#+1^R64s>v}vsGu6r$VZ7vA0(_xjH*L$ZeHM
zrL&!ror{CYQ7yM~a!|P#mM8Qf&_(6w;;2+ON~Ka;waU&e&{<)xu$L><a(l%$%G2{3
z<r&KIm{p!3nZL8jGs}-JPgN!jU!GaNv&u8e@7v|+nnQU~r7|whw)rT}wa`aT-=d_S
zGMT!c{%Sw#rcJG7GPb3It{ugeD852^b{DEjp2gq^*UPJQ4+q0|f>oZL*4CZ9zAKvE
zq-TNpb|eJ$QRG7Lz+8mg=Vp(59ttqr3zLm$k9_m2Z}%jKS8&v9@$xa#ZN=YIw{Pp~
zwotz+)MV$u4v+=&dpD?lr5V((j$Bdm=HSs#5`skC++?y4J2$sX9`mXQh@0Z;me2U|
ztOAIS>NV*>z@N~AJe$}2=|O&?$)*R|AHX=Ap&pcmOcMR`)`L6~%S8`(`Fx)q+%?hz
zNj}Rh&#nl0Cq1yuXMA~fn23+`z*}F>JWG;vaYqFzKqX)b@CT%Iu_KeOQWF}g36q85
zwr3pUETg*<HG}za4?pG^UY!Lu{x3$TLp0_oj}+-lWvbEz(E;hlQQ9Hl>dgI8b(ue1
zt|*fm-Zx79RSHHHfw+ZQ7KY1`@msiWko<8CAN-?271+f|{uuf(`cRE3N(e!FvS13&
z{IP8ghd}e$ffvR<=>LAp$e;_JaE*2l?qg=j$U@X%LAVT--cQ7P;#-h{LKBU#Am3L~
z+wcVMr&!=UOOxLNmI}Y(kYi>T{YF!YF9q+yA!qF5!*J3tRi2+0c<+Vu`1gi6;oslJ
zd*avNjleFGXX=-X3{z~B${sWERl+<Rn}6bQp-4dvyF9f+XtNzQ?D0IuBVNj9WH|h^
zfth)vd;6kM53i!Z>j{}{?LxZ2m%~(q!H|KIb(IfNw}^-c!v-bNFCk0`=vM>0pWKxX
zLuD}*VTMbQPH>Q10SO5G8HJ;JN6k9%v=OiiqTlQFVdGKW^gBuado6xbn3j57HUsbE
zN*3mIIRi2-fimEHzoE;*SQun97S>r&3}3mwRG*uG&z$s`{BzQ0@;4}JR>q{y<e!s1
zC*S$DK99xwZ|U;`yf@b86!_()&oA(9;5YR73En$_*WC2^I^KUvpHn_(WH{!c&m~d5
z6>$+xPWrqW@#dz_&7qg8VWUg>{H8~iK2JoL-1M2k+(sDE=Tkki^jU{6-_mDKrhjPn
z^!of%A6C%k6#Z{OpSz=v*5%ko>ziZRhivdM>e<}K$*Xm1AFt*<UadWQv+-E#&e^=O
z^{Hv7H{{x(64Thq8F&Nz7uVjfo){&<8vXic7bJD?HLOxAL+aYp!O!~iEh(wX-qf|p
z{1&#R1oRH7!SVUY>Qk>9jjfnI(#6qm)Q;2G>Ku3qQx9ez+~iOF;0yTWECu5cR-U~-
zzI}?Cr%)P5SH^lHO54Od1iE?%G8%<6YcrYfJiX9=C&^kwheyZ;$wTm7XzM6UD#8qc
z-&%t(!nc)i7z#(_y!?C0S=K{e(D>u4k{0}WbN%)0;REccCTCdAZ;@Z04&N$geS?@&
zQR`nBmNvDS#%0at>HEt1N)BaR7<D^;Wu50&3M=bkh|jpJebFCogq*0X2Q#_kUDgyP
z8DXfb-y4MaR#}hM&qrOgpb~*CKOS^b9L-Dh1Yc4)D-(XAiJzW{kOylc`LULp8!p6_
z>HC1puEV2sn~q(5y*f5)A(Kh!Vt#{F#X7ZY{Op`;`_#vI1;IgKYLz4ecZ*WRq_P6!
z;P^QzVT{(+7W<`f2X~}Q%IdRFA6?J}^ZvG({uE(%@X!0(F@MtS@%sE;FUKcG`K0_}
z%PAKK`o!GwEA+?t%(9@8x#jxb&2y`K=9$JN$621R??b}33lVx5?4}7KIKwjU0~z?_
zCIc!*%!g@}k;-rk(U=ZMzRqE0>#Nj+MQSB=zo(3|$})Qy_s%TK>}Bki>7P}`L-qMv
zPLrxe`Rfn*i@D`5tBf<Vn0q-=E`_&Q8O?9GW|d$5^4Twkd<th{IMBxh95t(?%hZj^
zKp&o4KC{XZUlZ9&@!u&cs$aeJvOk*xPa)tbB{!b3$)4B}WGm<wKPQZ=<>0cn6UMS7
zzWVC<>PH`waOLojtVm{Z@D-aIUpdH1U)mBLYq7Q^zvaFi`-}|RFyc+2=dGwEn1M6o
zEeyPw8O~7?KQb-f2InfXuQ|*wf3-32GUjinzTdv8=a0ttbcO{rA9YD~Jb%IzQl6js
zS+h-flCr*m#%W(WN#?mR^etZ#d<gT-LVrP*G<&eAxL_3(63JS~%W`V);SBTA5pg85
zdG7*QdC6l2*Dx=6kmfrtZN4)vA(RQDyi`IQ7qgd3o>MwmdC8MB-+8h4&b+jz4jB$x
zX_=1E&o3B*#Rjl(h)^zh4y>~Bk|$}t^YQ_F80*+4_<0B)15h%WccE{Dg;MxqV5Ekh
zq25)jikEPPde;~-TAp3+@?4KF$X}i_wp91?Q-@r>v#iqec`+=jhmePkp92-jD$fs|
zti0q&n(wmuEr+tYpU<*7A+*O5R#ceR;C0agI0`Z{>t!$|jtUDN7^Rl=Q_I6;;o69A
zF3HyChtU{0e6_5LVHN-KuZj=6eyiMR9+Y&I+RiA0au?QqN5C%}G^D$y_425!pHnrI
zM;z!ReZF5FLf7>diX=Z#=36GSbCAhm1DOaqQdvJQR}QkGK9R;=<3K0<dvs*vU#%p6
zMn^~|&g*r;nkqk>Vg6Sk|DJ!FPJEvT@}(5uKfiJ?)C-b>@ICn;2RTfF9FqSYJrGP1
zBnpj&rhD?u|3vU4^kIhluhvhN7?$HY(5C!t<(NGS`IY}#BmVp9$EF@NNecXTJk>+`
z^s@$Sc=j<+o&!!pYY&R=TYTB!z0ii%$c3+~Iq=mQw1=|y_jxXp{#m|S<-%78zC*~-
zFj$aRS<ohCmsg$x!9UAanOyh^r-@&<Zm=^d4(tqkkA7R)_j|{Gf_~Mpq4=mAam+#v
zF6%pj=271nj2oygOwrG+MyRz|<Kg>DQ}9lGBYkJkIgm5)n;Bn)1V?I_zlnJ`<Qsy#
zoW$>)GUA=5PX+yE(9@8S=KSEz`dF%qf-V=;Giq2i&IqH+t~2=<BYrJ|{EP#gkd|Q^
zA@Eg#Niuuc+=09#y|a}~o`blYbS6J#Lw8vSeC1X)uRvp1Hjz1$O$j7c6nUYtS?ia*
zY+`dMo00nd?z&zE)ZCMP(%jj2gz@=%+If{)D_8bI8l=BPfnU4qc6^3oIcl3oKWQw-
z?hBTMGhGwreB)uOMb0oUt3ey^x3&41*~xc)4EtLlKQs<A%#SeN=Z|wN$YC0swP~e*
zlR?Yz`uW!mo!C6^xBCafF}88PE9jF2<|xP+@*EGI&G`22yLiseSVzzHH~Te1zK#1^
z!9HV-o^SfrrFk?mhf#p<L+w~wK+6J}C~bHYRtNMp8iAUKP&qY^EN#LZ9J6r}=5MGT
z%VaDZ8{<$LDWq>fi=A+W=?5YGi+^GI0};P*`ofz2f*jKCh4hoN(l<17kVS<J2-6Iv
zQ;DPhZ5aqWRL1!l<cwvI@)z@vlN{Xi<E}Y5@UR7PSf0g$!HTeq^^nw-@tlA4f1c$p
zq+0^(ALI=4o``f4|AKUL%CAsgkLlB;rjy!#8b;ALKk@Hr|AQlGJr{O;`Dy>Dtv7CG
zgtlHM1*33=eAD>;(BIb9XR@Ae-i_NDLFO*DJntlHk~w{H(>J#6?~!?g8aBw07@6f)
z=7xPPwNZl1Q*+>(zKvu5HkoI#o^Rd_`&Z)KNk7hcVaLn78GyzeP4P@9hp}E;*1pS{
zMQEEVg1WGs2Sk~>toU=Tg*Kh+DGcrG$e-$PPPTN^ND#fT?U99^-q7}l#s;+H#NyHS
zG{UzT*|cHVn6*8^7=q^`%dT9=_XB%G0%w?ScXNy>bI5lO(EYpl&dKKLTlqG&xf1ft
z;`tN#cGH)4IL6K7=)0Nva}+gq7Ji4a^4(Rf<;%M@Hky!nP~HJKxy-d0(w+R+(2(v4
zywIFFIYVA9!!J1(UV4C;e}@-i8xP{8iC!*gsITPcvy|jg6VEm9vYfX=)tgjz;Kw*U
zm>H@UNb=+-xB4KQ)Bm5cJ2lLEsuSfTd)|LV-Y+sc#{xO!ovOs&n)jUQiv`jof8%z7
z+5_YIBG}xLzp;%X<=swS?pK{DCmh!p59u(Dx#U#Pg#dnhA&U$fthYvuWckhQ+l=Z7
z)lt@lB2Ae$Z*VJ=GuapF{hDc_!n7b~^9u0BM*!Y+kVgwIC>|lNvX*>hCq1G$d}`xl
zUJ*g<`6&pNCXELuLRlByD46mmv~y=&C;^V^iiddXgl9G_hU@b;$RLBV5WY<RQ+X8H
zxUwXV_8RQWQZpIR8d^^ICV5bsW0-F%*cf|Y{i0|ovdJ{)frRgqNXlagbJ7c6MiZ)u
zP|JeD0@>v}%oh1A(v#xxVRK}>jT9}cnZVB)54rZZuc8>R1CZLUjzA%t^iPBfKpZLh
zaAWZ|rAP7m;vsho!ysy+jsrb_KLeWsPXgNkPXoIH&j3}x^T1HxC15!4GLZNSz{BsI
z;`dbjUFneg_`Nc)9md~MbpD3&J7>b_sI5H@>;=3G6y(S6t@yrh5=^}Ddj|Nu1ZEH(
z)PS>qKe^^8A2JDP1*Ey0Hb9!<p>m|50F`4~U>6|CybrKHurF{fFaY=*r~-0`Qw=Nu
z3<Sdbm+J?t2Mhr=28IGV0dc2>4q>@SU@TAzTm*~)CIANm>Heq@z<UtTETCH<>|+Er
z1I_~u11<zE0xkva1+D=e2d)L42gU=h12+I40~3L-fIERHz&${cuLNoF_UOEw`hQYR
z-r$Ag)C)**(f~<L%YY;&k`KvgH<09X21s&xqnA?~<cs9g1xRw53?w-v07*`#fF!4@
zK$6oPAjyg3Lvnf#BsqNslAOq1Uyze0#KhYp^Y*JGCmI(xkUyM1>J#a&47e5;0IUrD
z6hN|P-U}pod*b2kUH`p!B#1}KY?t`C$fB4pM>3iB@eI(XM|6pLI<l!SrW<NN=abL)
zE`Ec~Furg-9d$3p=^FBv@(nt}_+s^R<?@KnOy6$iM3*f-JstHY)E*hi?}EPlk>DL~
z8^qgg7}H%cpu6~u_zdZIn-+flmGsCk-8}~7!P|!9oUS2%yxqmO<D>SMw_o7zTQcsy
z<j{Ap!rC=__HYXP7TRBao&Wp8@oVAyH-&L}RKF=b)Nvi97jBRqzlQw%;rKPzoWsr5
zr$_Arr8n0gJ$|k8`@%_xXMK6odX2GO7?uye=EtwO8Pgf+MdCN&6X>YV;Mc_X^%&A0
znwlC*N(85b{uBqQfHV#c0#g5mzDq|#KdN`FfEe1baY7idH+~NU1^_V}(!~IyfRllP
zf%AbwfXjfxfSZ8Bfm?v1fO~<Xff#$xzHHrT-~?bQa3U}RI0=Y5y|^hr>L+IavF(f9
z+tdI!8^5WYMBl3O1kMAZ59W}z&JVZ%h`yFv2&8^t5pW1_F)#)g2OJMv0bB=M2}B#t
ztp*+dt^u9|qHWfl1||Tn1J?sz0XG8Q12+SUqb*GWRtIhcx&pTWTLO0gI|6qDX^qmb
zzVhpIIhV7b4^)2qx|vvh|D^KsgpTrSdHQw~eZOJ<J`C*z)vMt^>d$E0LH))^Al0u?
zK%sx<*U|pHc&NSR*RS|BBIEXR0n(%Plg2ltfEYt&w%7a`()Wiu#J&Ofxpit+Fs$ON
z@sI;QI+BMi@CTqBQ0O1{wU?a3IqJh<N`ZxQ)`ycIj%1_sP&G2gFZlju@e>`tu8|dg
zZgk7P5ucSoeEeEL&hgdI(~<o7xqW`_+*tn8A#c)$89<t!M!n9I2S2y|ec`BW=I6Ef
zwFOEK|G4^i$W7FzHwjn?zb6BcCvJ*9T?)_7FaNpltr4D|<K^c-sr-w;&jSy+LP)15
zun3U!4Q)C5{wxY4nqt7FK;a%pijSW=%{jiZpr`oot;FIh4}`986@V09MIgmj2`K0p
zKPSo04;t&|A&8Ik^DwX+@CZ-{$Il<;9PXq(+$nuH^j(?Z__;oQ9?Uqsqu`6uI|i%?
zJZ``zKTno(xC{Dl7xm#T>BEt{0`&Szb5G<9<-fKFFRuh3$$veN`uz<+ny%XjbOmk#
zQoczaIDLFw>2EkgeR40v$L9e=o#Z@$oq%3I>bE6m-12+Rg<VC^n`{c&X6Zij{7*AV
zuT4BW!nf(fr|*UyTX(MH(RK^>UU>Kt9lnCmjn$2{xcN3_kgTd~!mukF2N%3ram=)3
zE478I9$y>1c-(>f--i*);v3w$+d}uGl5-YZn6_xi<^~oK>2=0C>wd8q_vGf!z3cZ^
zaoj;h_ex`5@ysuAi7ShzzYIt*Eg7~rsYR(42Y(;3cU|nGDvlTcy<v1yK3hhgmF~Ra
zG4cL;%X=GD{mv%`M0R;Kt=NDy&VC&{As0JTK-@ER;@9<izxcWJ?fJ*5@CeTvJ8w=~
zZ5q9QW{=ZTmtQD)7{cz)=td0OmE8H%@rLK;{kPuBnBRLd_FIx%(#!%bkF2sdAn<HT
zn~(L2e=K-o)b$REgP(?*Sj8zH9yrQze=xcdMO!xA-@8Wq_=Y`#mo}2#u{hUw`|4sQ
z4?ZQh*6lH;0S00<F|d}H<V}~~dpQ2-_bvX__bBG~e#HFVdnn##ctU>uW2YF4n@_GS
zKUlx+vJm;xW*4z990Nd!$<)IZFBbYepWLTY>5hRmcH>u#3k*+NHg4jQMllQ1OwKPs
z`zs;3mv!P3)T!cqhBE@h`wah?_Zc?tL3%oA*P#g?kMFVDUh2xy6Q;K+N&OyG`)Skh
zAD@3&=@Q!44}-M)-h0>?6X+5X_qE6FFD*9j_MY-TF1)|@x$Egc;RpA4Ojp`AdRf8u
zQ5$^d&%xkZV)AqU-D{MVc1;qK;$F48dFl9vK1m)8QWsgx931%Nx?fW-tWPt#&Lghx
zcP{hG{6(kFKHq(Q%XatreieTBSK~X4r`4=F>{yT|=GCkzzQ69?!$As)FR@bDrJuH_
z5B>JKb3yOjG2@GGN`G}T!SunZLt%|8%$W-Nuw5+O(Fe{(AJ|Z?NnNjXbzK4^KiaR~
z`5;s>aL(zJ*|k!K*<d_$o6$w7UcK*=QS^0LnY63L<3-EQOq@I<fg9l)Rm1z#h`!5_
z-_jUhN=$5T56oB>7u96A<Az3SkMy6f7}fdI$ToK_o#Kl7>|L9L!E_TwH)McSE#3TB
z(@A6ZRPt>QGxf1o>}B)f=F4UuS$A||y*>{y2gK-}OsQSo;_mj-x(ne^Lo>YnyoT9~
zD;F2>w%y!z_a<$XVGy{S(Y0*fx`lW5WJ}fb!S}Dc8+>Zb0j}%eq2>2QT(KIvxNW2c
zXLT^Tq6e1P_&?3KdAj01?S91n)V+uKy_fNyexG4}?{5_EGfcE?@bdjZM>Bu37?<zA
z&+xClr!c?w4~q8+4o~v<$@*Z04X@TuK3Dxgr#>UTOvB_#Bqm=ZCJ7gc9vo}BVxF0o
z^|ej+q|+rGTV1JH?_Ax>B}-R#9@`jwLVoWHv_jt?F%j<pyw$m~eX$KoQU@p!Z=Uz&
zxEBpcE|s@m99n()F^?gR+ijENEkBiRY;)E9(yTW&y$V-R9GiwQNwr2qxA1e!$Ch3`
z?}C*__ib4}_oMrm;Z~Ksogdv_7~hwBwhWUXy%^o$iajsZ;>JH*TRG)W14sMkFG4$>
zDC<#i-iRqvzl^p`jl~)Tqk9l7A5^zp=av1IOkOx-vgOEr_T3_rJ;sgn?HrLf_xMR0
z%qcOt$Nv6ztv$o<oZowLR>`Yp=N)Zas`}^jlh!Q{Ik)k7Iu;8aX^d`h*nv^Iwl#YE
zY=FmO&G1?;=LG&=zXwpfw{KgVRiT}JZ9k=yaV(V5B)VM7loT_Z+h$MtEZ*DKec4Y#
z10r{<dnrlW)olyb@Ek}k;=O(1y?vwyv))wvtW({}@N0XZbPLUisq-U#QqJ$(WVEu^
zp)2#&)cJ(9YD{2DOsuNJMI6{@(J^F^&AIsEGq$ez@XMjYlf`@c#C!Y1d;6$<ylEf0
zWa1<3r}lC)54+>xzT&-ok1>ZOF%j?WGrqUauP(`@$e9gpK4pu1zEPn+7vIEhPs7!}
zj`#Q+sO+Y7tbJkO%M(~66rCsmQ39d_L<xuz5G5c=K$O6Ly#!#k^w-}1r=~kN*!6$d
z=j&l!AON<5IDOZWdk|hU6FUSeBQ%kkKpf`Z#YWO8TpJu3JQREHB+WFT;kaof0{a@R
z&1JGdN|{`X8$uLOT6HA$0$Q8*Q-|PMJVRfyo3l2TYeSF*g`u1BBDHd@S{5n~!=*8y
zYT9i{G?7{r&M&bx=eO@ha;5NhOKiqe$@%-qh{nsi%{OU?ucltoXnWg0mBLl6Bn1%e
z{A;V<Q+k#RR^iBQ7-p4RX*|Vi!9FsG-&4<6RN}lJTt64CRpEYtNG*TdxJrZTVb~oe
zw9lE!=4+Sz9H8}BixtjFqJ5vjxy;c8`H<BC!~^YFC<q>6zsUp7lt=cH+uhu76$8bV
zU!Fc1@FeViwnBJ13k#=QM5&1v@anCXm&Al(M?UZr!4r;WU3siW2kPa;E(l|S!3~L;
zP?;uDhF_Wp(B;k(e;$FbCpW?Zdr$Pjr8^deLq3&}F4>^2W$Dn}F8Xsa;TMdDcr@g5
ziJng^>o7jCRKU$O2fsP+8H!^<4cPosd{Wvi^)jljSB5r7lk8|);Moi2B|>=`$jC5l
zQZSIR^h?kmU%PC3_zmSm@}Mv`tdU1VL;MK)riFVJQPfNpq-XoVk4~*Gvn*B4Gw*`j
z;~`KXord~+r|I);m`**+rN`>;|I=5OKb3~CM|w$NUMSN5B-=@N_8~9H`n=E~M+Vtp
zX%SrxE}JY@z<6G`r-^j#6Y{bEX+<L76Bc*Y*>a@&Io;7A$lHS|2Am;}Go`SV*UN!;
zG?Ybt_^VkiJAcc;n+wt*{?hn+1T)XR%Z)!lhWqvW)k9eNvo;>8!-;ws(rqrrGSn9>
zD6_e2G9-Nz+Kim^M39e*DIbSn`jZg$kX}BNzM*{blQ!)w|5n=Nv5)*P)j=4w<NlwB
z2(4U!E$h&a66PeYir~qF{KGUj0}va~vDJJC{ArImwTG42dqFDMNI1cko$oXFzJ&I{
zQWIp2huj~iZpDD9K<Z=O0V$j(9=@ID_druPQgH`7<d*BhtpFm6Z0{6Ip}AG~P5s1b
zeLOn+&9}jP+uRyTRT6%bH*)<zM`hg~NJm760I6*Z1!7qicgb=(cOdkM?LmtIcEs;N
zKp)^>paKY)=z@VmfdhaefZ@PVK*6@1Z)5qpkBAQ{KP=ZX=MOsKqYses(-(-Qgze20
z!t?DU_I<<OI6Qb@dlQsEn0B(gbS;1=N|t_W{LQy({J9_$p3=i~B6ElEntmS!mI59D
zS^$p$NuECgs{>C0i64rOZ@+SmZwKfozMVjdZx@i_+XJNd_5&$Cn9gUGH{VwA?E~>=
zSl(+u2QRi4ZWu5Dzb63K11AAD7{tT3CppJ6Lmy8pkm8vQq<H24DW17N${&?2U++1N
z>Lc+3Rp*-HA-5QGl)oiF%3mCi^0yR7`CAUG2_*fj4O|Hn;^pge&hd@|9mP8yNb!O<
z7VktL#XA{D@lF9!yi<XxKq+4S)q5Jmy$WrbIehB2{#xjQhf5<{*7kU@G0n0!_F%ES
z0E)^5yTr%a#yHM8me9ANTf?Cb`=%clHu?JaEh8ol{L}#o)RNIvtLk!L=!RF```(%y
zd{unOZ?0C&I92llmtVH(9_r}porbo@i{`GMsQNrSa@09!X5$_~(KYt$dJ!ZYpI&XZ
zoAzVUlZ3+#P}Kj_UIlRv!l*LyyMOB9S8LM}>B1}TZ!|ld?t{ia+=Fn_yZ4yUPp`ZF
z<}mnqkvB1Q78MzH5^W&cTae5hdHl*|cBR+V`n3@EAWU9|{uUjc#AM`5H+#=lv+aAW
zTYBMmeB?=|^u^=iy4CzJqV@Hqmsh5v19xR~57P?1t+V>UmYZ9P&gt;fqn+Esi(Q^q
zTh~C`gJACX&)kEM-@OI@^gRPf7)(k`V%}6}^d+v&?qge?xcWbvys%xmT=(+Ug2N3Z
zr>;)k_WG{4XF%LD;5;N81AB4LK>CA>6KmH76{+FBXGP!HH-4G-HXI*T`|40Vnl`Ac
zEVY2=iC@|lyA=6*ZO!XF{Tu8tb??1ZQ?o=X`;QCp?aSznJe(QyFl@x~M>pU5x0^dY
z`ff|Fr5kRnC^ez!npHDmszu;C*oNY(wqx~p)v-!5=L{S^bLF^F^R%bkEXOpysc}qA
z$Ox3$jl?;5jPB0%wAI_!Z7bR7O)pokce92Bgbdnwqv!MX(icD9US4Gx#xF69F5aWj
zvNDeoiYMGSrh3Sw4=dqZY5)73rHf5)ni%op-t)DvKbz5=v7D@4<uxx>YJFk1xM#rf
z4ZiX5VJI<~p}prjDPYd3i5-KZK3i{V<I=LTr#f{+t-!lo&pm6g`x)kt7+vv}ThvpZ
zC7-?azU%bBjpar)IH+_rjXpCcVPi#CbwA(j9CwS+^^srP8QC#qOnqsQ*4&eeKQ=9M
zInMfI(gD+LFYfQEJ6no*156r7OsYIRSM86a2j>%pt7RiL22=>X^khWk+1on532oZ>
zMY-T79OupG3Ke!tS`<*LqwLZAYT}-O*yEU6YDn_yzjx5HeJ>OvZ{Aw7!A9C)X`|HV
zaVylHV-kw_kE`a{y8zBjVRY9&Eai^hXtdI?-?>w&iR<2&?igLJ{?0zqje)faRH{<v
z5#~4;-I5Pae?PUuf4F1S2^qZ?+*j<(5cdp_oRdE;l{Ks6t*m+Hr?#OTYuHSGxwvSN
z*KJ;g%-t0C;&I8*m}`ShOH7<T7uxH*{(@)w-3>GLtQzmIqu@e~>7oMFH$Uq<^IfWS
zI_C5k-P5u6io|?w{Mh67wuy03aeke)n0)x9e{?{Dl^bU{Z0&%_klT!I!OptJ)4gZT
zt6b^DyTe-_d2M(8SV-dgW=+_E&n2G^e6a#&&0ua@VzMvI&Gqtid+%x)>1oMZbyjQ4
z<j>?E+I;d!8yfgz>bk}_Pnyw9b&P9}F{y*ErpfusU*;(9t{&Yk<HX6ItDc+jDy8Ab
z%^0(bdj`Zk153~^XdOte(yX+#Ru+DD*RJmitH|cdXWL7~Jp&|{leZUH&)>iKhuE>t
z%_VQU2ds$__Y9C+#61HqUe>>Jugu0hX&=|DaUI5S%Unn<JFT|1KM?P|A~JZwA5-I=
z`wV($nNm?%)O$tkg9m07G7aOntBg+EGa&96Abk<{42)~+Iq~;1<tuL;RsWa;7L3F_
z14+f+eOZ0Rc+UWq%|s_kK$L(e0Z{^?1Vjml5)dWuUnl{xqwCETFelbkZvL7`e~qHQ
zf3%BJV1(K~G&pR4IwDLR;t!+xNdGAO?;jbV^p}T+vp=<}V2yutsFuPIeXzZYlfN<q
zcGmKckpJC10D`@LN4<^mRm^vjgUJ%JwYLDafT3ARKLdMzY(5BPR}87;p>A%%Hiaxd
zgvs5OJ-f|+Q^YOU{0sK&&EOZQjX>nQ-MU~m?pqKM!(keh-Kj|Sne9Mp7Mv?@xX>{;
zOomIdC>-%rl>Ye2W${G!Pqj7R$<R(*M+U2KQpm^-SQY3DZ9Am5TMrb}h29}8Ya-S=
zGho1NvaR)GHo-q|Zsuo^7R-vVKcukvEhb;ix_w7mdkR8+H?#bla_}QDFuIFbbi|gi
zA5NI~$`3Q+<X7B0S%2S_Qh$*b*>?AYoI{Y;-Jtn_kDDWV<p+A&VEB_<N^!2{vHJH_
z%kh3>+ene~`oinc?&8^PeXqh+u^4Es0I9NG0}A2zvgFIyI2=q3*tzA&Kq~v+_2HJ|
zZ@vupvU!3+rg-PzAqUwrnZu9S@|FcQgFkee-IIheV79syfw14@DgiO=#8n1jSsP`^
z=?(#_1AhTp0bc@Z06zm!&boro1*nbA42Wf1-H$*l<LO98u>8hsGXtuKwweE}=ST;@
zu2y1Vq2A^))v8O|!AmOL{<YYv4D;aGmo2$|k6i1R$K2VvuJeD+HZuy!Dlr+Tsxa^7
z9<!!F+ecigePi(*XQ$F~#lNO1FU+3MWbcMi3ap(my4gE!+^oH>$byxxBd=Upd3oHx
z9nD9UIK29nmHW*`B|mB$V8_hzJH>g{NkzF2PR+iUcZk0_YQ?3f7r$O^-mofHZ_4bk
zzq&TXd8Ujm?{g@MuyilP-&ch0HSf1@{`F74`1MIo-T!)8a@?;Ep2Q4_Ykf(*5^HRX
zPI;n6eC;;{f9hOd(TexGns2%~=3L-Q>*#_{-TUnCKlE-H+#7?sBr*ANr*-jTHu1gp
zm9bGA?s?|;);AT79y+a<wsm&<wKE$2ei-+tvG{gwE~Dykw{?d7)Ik&EZ|ojNq&d!e
zT&Y0f)w&^jEEacb&vBm^UHB&RTAaJD)?@djIO(HlJ8yq#clW0nCKirPNr8{{R)g*B
z1eR{86^@dZlIUHx8o%6lc4FN}RjyUIb!E$#AEyuc*Tb``PND(K@A=iwSbRkvuX|p+
z#K;4`KK$3RMe6sp-mR;-bD~e(!_lXM?3>luy&(TKrd82cNlYFspM3S_z8^K${`D!t
z-m~?wv+~jlOS>NKYkJ7-O^1Mi^I_M{=-mG}<2$BVtH}r4AJ^`a{G|QP-{mb<OS{eS
z=xKXz+xq@6J|E5KT9~d$K9*XgQhdpB&BipfjEk*3?C7B8Kh};OyRVS@y>@G`=E>;x
z1Z^DJc1-6WzZ2C~jQ6WF{h(V9m1BKZ_27kPU-`Z%{}eV0%qG-oXOYC!#T0XE*E{{_
zlcPtca?48GJyl$0xoBX$Mj1XkpjU2;u3^L4o&CPFw03-FC9!(A<@VS$rHeJ4u<722
z-CIsSlhjA!9M0%sihgNYY+*owPEMD$ingc^N@DF>LV8fWOqE@yT#CFKcE!6Cw{~_N
zWh3`epB+PI6t7#`dfYA17S;0o*!W(yHP^H*72+m+mA<S&n_@QRNfQU-97c5V5|eRf
z%f1Y+Gq3osABWHUIAz{wzm}=H_q+6e*{E*+#b*zCj={bUMrV3lv_;K+e)V(oH4>8n
zHWjMcx*u74;A7h#p4E35R?x(|V|;3lXXdZ0e;U`%6CZ2^FnIba&$$-QuU@&W;`Z>`
ziPd{-pJnDPeSNZe`bu|<bz#3JG2u>X_r$EQZusE&k*fWl_7DDbeRyDl(IsA|Z@BPm
z++vdl9M_rARXp9LQ28D+$Lx1n^279Qy)16|M-4Xho87BI(-Zq!^y(IXeMyXN-<CFK
z{l>V}9_Q2X@Ey6X;L3Y@e?K|owdI}8qmS7xO&XPdo6!H%IoJ6;A9@tq!{c07UMp}%
z!r?hyok#uJclD^?kIO1N>sMikZD?idsS&~LIPRZ*9=3SS^}lDcn&0!q{_69v^Lw9B
ze$UN*S(n;_b-#0pW|H{iGA^)(oN~r0=5TF~b?5z(F3<ls;q$>E%keGCY*E!`F9v^c
zaICcMMUe$(xAfMSOnkGYV)40)M-Pmxx4<J2w#z*j-GMcxmpV1{EZEqg{hnrLZcKg~
z`egMe_tLVB!5t(u2mW8QmCf({L-{?2JHPh@iRX2TwzsDKm~X<jsO0~U?XAX^^82C4
zj=SS89e7*+%e3*ghfJyI|NDX3m9AZu&1h3@u4(UjN3d_3(S6jcX!>c;y7=v(-Kv{x
z`eC>CmX}vd8t+~Z+2n1XInp#|(U$k>Zqb%kwB>aST@V^ndG_K_i2;%_50ti@KKyjC
zV%_nWd%5XI^-Z+pO;d;5ec9)o`;qpOZ<WD<Lu<4hqAjo4P|=o`^dMvLtLYDSt&e&3
zVNul$rDh+H4l3|ugu8BCQ|kpCm&~m!$6c~+L^rp=nW_`t*Y42i+4_C0UCl#FjudTq
zNiL!-uV~9ldeE+<`(c-78>XGQ<N1?l%ZsIF(TNfeB_K*blz=D!Q39d_L<xuz5G5c=
z;QyoqU{3NE+y4g!hD1g7<E{T;llDJ&2Y_Jzf0-){^JttwRghO5m_V`f<dwiESf7Uv
zG_<i-_mc%h$s<%a^k0eX5gvmy!Kx;1ZW>%?AlGUl>ezUAgvdh`D!I(g#mPybws*F*
zlPi=iwsIG#RPJJD=iuU?bg`GJT$<DuDD7R9a;aM7VDIW+>*(lWt8i4<Ix6j)9BrK)
zlxn5AiKJF0t)0ToLFw$Ea<-MaI>?=rDydT8VyAX+uyt~Vr=p3Z3HT-(e3*4+I!w!Q
zW_QR2KOoZv|Ek^wzZC54udqCl4ZaJrp}(B@+ZL;6bf$h`^DI9n_WN`ujWY|A_1hLJ
zOnjIuKSySBPj>XnVH9q>@1Y0ejI+I?!V!*a^Gg6*!%wc{?{pwP%0oZ+DMQrqFi?^m
zzEF0FQ~}@&%g&w3F5*v?ol@y&AL!`hqI8toDHKkDwyt)8uJ%&7gQLp9K`qZJJGsIM
zMeE=w4^*iG9Tm<>dlzR1SE*VaXzyg}q|R1$O1r>7rBvbUZ097GLpSVfRgQsDshyLp
zi?iC<!6o;ylYXo0SRM_^F7vlR*=73a%P#Y`zU(r88<bt9-?z)Iehy{#2x}w8W%pw)
zWv45`m)%$Zg0XueT&e6Lzg2d@VcMLlos-H=s#2?!@<0a{M<-jUqgo+XD&#0OJC&`}
z*)^-^T;=w5fohebBGAcJ;iPbsx+?5c_JK}PslC+2PHt;h?VRk@ayvVFSGCH?S?Of&
zqEad3Y6n|a2j@Ulpo_C3Uv#YAN%-ur|4C<kjLPn!LA|@f@|ab2w=;idm0gw}Uv^hB
zY520s`khsFS$=%k(O#E@uzNACcZG8(yNfxLT`K&9dPj9p*bgJzi$Ha8E!v1fzC}4~
z`;f`h{rbtnRJa1hx@l8unT%a)5u#BJkinNVoSxl<)-TT*<O$cyt7i`f!+3&Ko}Sj$
zoxQ#*n%-0>f%^7-qJBeEDE#Og@m_e!K^~qOz21GzbY|P0C(mewsSTDOPQg(V#mmP`
zw-tZWKB(JzT_BkfI~A~zhKVUymDvvdW>6j-xuWK^z@wog1c}miv=BQtH$kp>wl+wQ
z;&aYte0F)YiHJ|ogXBE*fZyeogF58d8S2%cvsX7+utpITXru@E3D5K(Os@y=KY(#K
zLp|sWnOqF}N)L>f&Qymy)1*#0Cw<`Ml)FB}V8fQMA5iEQy}+B$wsuGPDU8a`h)H9$
z$a7divY>b)zcb#v1|}4*pdVbfyxIw)Tx2yDdA8cTezeX_Kk^ekn|_?6!3dn8e!N1R
zO!>N<Fk(7WKk`g7H~rw{^nLnq(xAPda?HSQ!}h|6Nn`!Uv!^3jP`qZ}ryqIt%M>r^
z$54H}oP)g_<Y*jAdnU`{@k5$s{CHew=JM3%tQIj(QdURxLrJ7&=p=01Om*-R+U)M&
zL+DF|yRo*xF5H6`E)Bu6<t3mLAD3ZXLJ)_KQC{+@Lk4-ti!|SP3Hr{w)Tc{o;0*I3
zrE+28#R8e-l2><Oke9qj^PQJ^Ipjr$?+p)qr%DB5sAH{ZfCh&u!gQ<=uqEP%<=cKC
zFL}1_S$WBmG~apg%posl!Kk5*34KD(2JmManVWF6^xsPNh?afD%dnwbB@5N4)VNZQ
zHkU_|94IXI0dp)Yt~b&|G|46#3-(o<y`0k!rw>0a7i5!XdyyrZJW2B{n?JzE_td}S
z9P(0(bk-;@d3`$=<RvfCeCMT54(0r<wqzsrfReMsL+v7!;d#j8BHteg<&tNgla-e|
zN%NhTpK~Y|W1Tgue~B31kV6$^c|jA(J)pdVvay$tmpq5tS$WBmG~ao-V~`iBD>Obg
zu4gnf$WJ|^W+u0KHk=9&&ageL2A%N9-k#<;oX?U$o}~Gffn^T5nNxe(SKnt_l;iV)
zt<kJJD*(G8j+F3h<(X$kY&fAtG1AyMKmD?=0l%bY0$&?*;42Wc((mqnvnKk!hc9(5
zd^ImmvGDhLQe7r_)dg*e5np+AkbhQQHo5S1ThCW4_$iKODxRjG<-WUL{90c6&u&C!
z=(3Nmn&iTlmIMT6s9$eUPo+lfcwVzLe^y>^4B7-k{VIV2G>rK&K^{`F*Wo<Jz<-vn
zg1N|RwVp2tm?Qn7Hs%EKkoetw#n<JSpZa(_7kRa&&I>Lc59!xxJhwqB`R;cAYrd#2
z`Pyaa7oBr+%YZK$zrTQA0L{I~Bek+XTwRO^$UjBz9~c~w`GU@giHBU9BM+lN=goM|
zx_34h@dRrryoq@T4pi|3T@dK}^mHTf?bHF~rPPFmYQkjv2n|aK#vfvN_GE5ub!=E5
zhpeVQ@8KsK_odP|4EW@SgZ!A7^x06Sll5g}Sl23nZ)tX&&a<=mvpQYTNT-E+hW&{l
zI0rm5bu7hG7PLMC4Cib3gPJfui5o*PNfe07sNufVkI<Z)(9avoris3PV-*N=*#6Ga
z#x`Hh9BBve{hN$mHNzdC{P#wf7UyosL%x+R$G$5q_2Ubg?+K4mgaj+~BXz`Ye19+T
z$i6|1%Fhn-uaX?*RgCqFCR1C>I(qg-+)ny@Ip8b~axr*lE|lgvuA`2`hA^2LN5SN1
z4I05wTfnECHCJ&RI#wS3R{Fdx#W*LI&k-hfs%xk=s25Rm)i>7`_2fBtFi!lt>j~l_
znNc05c-f~8kaWF^P_9+s0Y~+obP8taTql&PB<K9gBKv8gLR2zs#1NTQqp!k3UCLd@
zI5zK_la7&$Xe>#0`7#+{d6AD#CWr&$eZJf!nR9|jSRNFKU@R}fSz&YZd2xV0wXL|C
zgY$u|Nc-#S2Y<DC)|q8)ZvEtuGPFQ4O(1BA|J?d$p^g}z6(;0~coUc+`MT-lYli(Y
z<Vd$jzBoUMdqMie*IArZrq3<7&?s^1yXxC@hWHTbOm6ZJ(w=INc435rC|KHujMHX<
z7w-P0oh&&zR)%?{-BzFPiV{8!npdE-@tMxjPRTWGnI-~79vT{~zlE5W10Ty*|L2Pr
zq1{ZA@ZoO)Xe@9I&#x$ha6vEFdI#Tb^7WK&#wZl&ga!SfcU0f??z`JBk{#7Wx|dlo
zM5~UJ4UP!bYSlQ#p4C(1wvFgX-?HdY<tT`n*L&gaYId0};vl^z{iS~42=bSrKO-+&
z+l+UVr<}(M`D>GD{k&Q&$j|6b_3PCUIUG$nP?^(o8J(4PQQ(6NE1>7_W;_t);Fw&g
z4heUt(|If8hTx(6Md6|R`S9`b*@GYDD;MR>v#gq+&Ao;=`N)i0+Pvopa_gJkf-fID
z;q1GHU#Fi4B{GFyb3EjrmpUZP-2yfS-UiaU-+=9bcY)Mr-2;+s#sgqxylhPJ*Tx%w
zH25`WjvI@=iC?NWzIezTL;A$;ai9nAXJB*SNnktRX<&EY8K4Sy9!UM_C15!4GLZNu
zJ>}ON`F=MZ9f1k_tnrXLXTsled>+^fzb^xYaQqq-AI|v9z&Zu^a5g{+*8nJl<JT^}
zFPsE%nCZ)pz9T3-to5?_CjeJhAHM{D`+S40z5yLSXUu<>P`(Z0yP(e}#mCRb^7FKG
z#-SnIEWI3Ay8PNW8>Siamo43I&>7}~pHt)K+KkiPZjdfNU&YU38Pm-%pyTIsa?bB1
zgZ%RICH!};aXt+Blj`M6Lt<k(!~CWg(B&rQeu#trzK6W=C*^~dM*YbjZW!`G;|U%9
z*#PnFqpJrT2kZ=-0PG5!3>*NQ3LFWX2Gju&rw)FcVR`Z2?K$T&8~^(Hol`yqc~Cv#
zziTmW!{5ZeVLjT4^r`-C1Css<<wyDEzdQNwQR93gFD&07Kn!naY^<ZESOati4g|IV
zMgbK-*dXbsz7GYi1kMJo1{&%C{|&|G+qgUgJ#ax7{+ovH)2Mt4!LL3Za=oB0G?wZO
ztPb=8k_`NTRL{fl@ZTl;_X_0;QE<c?xxL_v!tVo?0UiWWJcocZPB{u}2|NL82c-5)
z20ROl22y)A0(coX3U~!b>9)qhe>d>o6O=BcLv19vK+w@RFbGIvQ^=pSqy2%t_&pCu
z?c{u*kPm(w&X3QH^MQC-KG0|A${}1+U?re8&>Gkb=nQNDr1AoPx{koMKtCYz#_|O}
zogBYA0V!Px9)8T6CI15Ov%o{{lb()b&W~gH@h$OZsCT76NBPG%Kvx53rVr<Xzxgp}
zRyb4mHOE5^x~8M?1JctW46T3aC~f3TR}J_hkmAE|Usn?dKgKu3%a1Q{RwVu=ehlM<
z?y`6hR!7rA2+Qh29UzrUU0^*Rbb#pr%813g0Dk;fk@eLqUgC@DG`YK=qxzK$q;j~Y
z5B~t@fZvaSB=@I4>c^i01As4qq?0MY6~H&Z1mGXQZNOCEZs14YDPTGfy2gD0UIS(T
zsk~h9@MAr`yeQv=;3w3VUqA;h?pI(L;B}xBcmqh`>2H3F#*f{M%drUhEh-OFAj*;}
zs_(~o;%|No#*fV?9HrA954mOfbe99E{8j;}+|~f8d^Q4G0XGAwo+Sa%mT)_O$U8R?
z-{y7|p^qk;g0@+@&piLrjM8fp50CI|I`Qedp~u#pD|xit!o3$BzMO&aG@~1<8*6d%
zZOkB9RoR4LS2hkVc(vk~Y0Fk>3s*h9HhS^61JGASH@J1Th3-iu=PbA|ZPAj=4J;zk
z>x_5S{bDih$<3d8*YA%)ImqZ<Y3wVW`6VuKW%2Zv0V$>>!xksCDAnTN??d*ki+xnZ
z5e?uQMmOcNW%OC;&MO`h@4vUaw^7yad~!f!msit@4Orvs*TEBwt{s$DVlw%}uj}`I
z@pJ3j^N&^G5uP`8-ki4DG<yHc9;c@+zfklr3avk*8!>QKa_3XW8=jvho}H_Fc;G1N
zgeA$ZMA4Q__xG+5KfYm);H8bEcP!2|-oCn+$%9V`u629NX#hp4iN+y6bmG~$;@P<g
zXo$tLbH%fB#j|sdU-5sqt+oBmb`GBxxy~IP_-nUf@2~9s7=iH_22B!^XOEwn-|JQI
zm3VgU^OjrNEWu!A4hAw3lb`$VUZb?MYm%50_p05^OUFO-N%Clry2xtg;J`1}{hE5=
zn}N}F9&vrYbD3Y}FFJkp`R?;uw!7E&tC0QdT&<Ggo4%sS<R}{-x9(N#%5|vy^W*WJ
z74HrxQ`WBh8jDKvs>W{@&&~~x8k*tl=QYe`T)DW2x9#S(yEkd841>kx7|csdTDEW9
z!n=F2rE2=%`&Zr#KDFim*Y)tw^7|sLSdCrWHd2EzFQY4ZV2O?Y(~O&^D|Ra*o}Ihg
z72i<!0Fsz&Eq=JhK=WdgONEb^y)TrTWIle_4d*452FKp7aou@H_%4q7zjk(Rf7D@#
z$rDwdhewV&2hD8UBPhDYo?S13q~p`8?RL|COnQ=V*kLy2N$U_@&+!fu4y`jk{lgz+
zE~G!mII(tZP>~w`dsg(FedCvTZ^QAyzK_vO8&p=7TEO$fFKvrmiu}E{=JlTb4fdG2
z_ui_hS)!Hw$A$RzV{}Iz&J21OHe&gsoA3SG%^e?ox24z84L4Sln$UF3su?lW&^}kU
zp>(V5SUp~KtkTRm1BcICIj+<^?P)j5F^z9(98(iA0;P7CjOxnh?rcw6y?x!blAYf4
za`k#QYe+!Ipq)2*K5s95@$>EFRhF4z-h$D^do)^B=5a#tgd4|H54rSVC7dhmf4{SI
zu?bESBYxa_z81%AVsvLLC#zR^&5M;<U)U|4vD@_szUeWEAfB-seCf%E%Con1eiPcX
z^NVu9PcSEi$q0!_p~8+yivntOls%eXZFrK$Pu2%3Y<RVP^112{I`tXxWg5mBk&G_k
zLeYa`O;^k_^Rm9S>7I1Dq+_cqHS3+Ld%0xk>ds>uE3gK_=w|KfJnOdO)XKvz#+kHs
zl^<&@J@|S4`a>fRuN`uIWqJZ88pJbpZKNHRHcEXSw?h3nCZU-BxN4rgF_||UlUov#
z>mQbK$8R)R>DcewDb>VvZ%lWLE?0kNAL+)xS_LXqsq={Ab~3spAD;exYKQ-D$Ep)D
z#4~oqGj_!@b_dMAvMCk){(d{EM=lvt_8c7kuec%d`deFl%5Wb3Y<0sPffvUO(?!Ks
zj#_Y=<32FDqwl(;ydA`CT4*VrvFlw$JY!cpV|T-1n^Bvw08$<cRT7gmB}=`#@HAA}
z*6Y=x`PwBG1J&XgyCj!SV-iN(S&?vm%+Me9maSGZN<3rtF1}gCGj@O8XZ_|;^#=+5
z^+&ahC_iTj$8~Tgxjd~h;#CK$(_^RGnyo%Av-^GKw3F&qvztxo|6<Y3uCF?qVeOL9
ziD&GJXY7)`h-d6#xmk3g1Vjml5)dWuUnBvtbL!0%FejE(ZvL7`e~qHQf3%BJV1(K~
zG&pPk_93Z5{IT;R(mx9S`$tA7{pI1|>`%JV-ak52OJRsU*xtp-UxvTb*f_<X0QkRr
z{$E?pjLB_3<^#!9z*7uQSv>8qPR41!xo?Jc(`0TiBinl_i?5v|bMFuBZ)l5nh4Tx@
z#$VXGL-)^<OT<GqgRl+bTxqRN;K6W@1`0@@vVOxEZ~LEf`g!kZ_?GRy1bpyv;N@d%
zYg|}w3#S7a&nuq?vV|*2LGh5okek^;Lg38y4KijnnXnhkypO&;=wMF9Y%^g7rt5>>
zFlW+50$~cL(*eom5$0~p<}nT^!EcgPbs&~OIq|-E(PqvnPPCa5@0-8!{zkLY={{J~
z74MrD@0))KWAUEoEF>ncuI-6TPx4B+bi3*Pw@=T9p8PPf&e`(Sm)t0pwzub}4KNm8
z#^`#^>Q(Y!LTGG-0l(}In$v#n$C1;6)>gQ`^hSF0+0Txm&75d6H@Ik-PZ>I#vBzxO
zu0_l&*X@z2!ZYno(;Mpsynf`lY~+9mZ;lK<_jlRMB{G{iNz<X%Erx_{YI<+)-5x6{
zwwgS1#i4CiDvZD3TeC{=nDi#1&75d67gNKeG;FV6w<IxHw*Qw`(*n=G)<wT5zw_9N
zs6lIvtTS0X?ERBvg@fkz)=kE~Ax8H$dFI&4O};d$IO?&<@^^}}k9<#$el*p=X+dJx
ziBXG1o4NDPFZNI$>sIHtmDemgMBfSDbaC@Tu28vCqAi?g3wM04XbYDxTrC^1F`$BI
z3)dbSDkUaulIkqjUhhKJhiU0ik8WA^X_`KCnQKR%yY`)vM|WsD#T)zm8Qre4+QL&@
zrc5_C-4@&Ow@&v*uirX2rPi0p55nfJ88~jmdh9V|HfawBM84j*b^W$pimLPDE05lF
zci_7on~zQ1w8iyH^5V$Y<2YM@(e>Xu=-Iv(ijg;Ot=S;j!kvWO?%_sM9*_O~?^=6?
z-#Nec<gAic&(1sAxK#De=_jpQ9&&Eu^K|S4j!R>7i^C3#+O@6G<7Wdr9&3izdO0U>
zbY*LK`oQp^NAArD5pCf_TR71c?)iv{VNV@DJt@-u+_`6NZMH2wYx1s3(OpMJ)|o#9
z^Vkkl->OEouTrb#<4UW2hlX`h4V^em*P;HGcdy*WowTha+QLl=6>Z@}Tey)`76$~L
zO=<J7e({e5Z;ZO$L2>ZYa1&uZJJN;fk!TCoV`VGr!*{NPT#;H?-^I78XbacqT0<|<
z7H$momq|=g;=61-=xf${<)R-46dO};_^}r!=e~8TSbeVC^Yg1otI-#2V04fFm0IDC
zi+AsS?i}NO&d>VA!&{;)9LZ0#g~Kwk=tK#K5)dUIN<fr=C;?Fdq69<<h!PMbAWA@#
zz&}a?Wb@tsPul+nhXrec<srdC)e(_jZ3E!1127=@-`@{F_Txoia4w#?I^*%eeV<Go
zZ<U;x^km|&;VVkLSq(*72cvw<uX(s{v<>#N=z83`=+nxtpLf|g?&`Th1$Snod!3J)
zR}X90HyPdZ%^&tv8uxDO6REGVO*4m2-PT_VUGQ*eWXswfFE*xG;vnD>>`YTd<$_(}
z<85OcXB|uEThXoI(1(4~4-A`pef*XY69<0k;DdWP8C|uiE*FMwc;&tCt;xYx#h3i%
zYSoNWH9v6qWvlL?j=tV$IE#YOrI`g>{`NfjUwxKp9CSuvGR1k;NkzF2PR+iUcZk0_
zYQ?3f7r$O^-mofHZ_4bkzq&TXS$K?2q3hbY&50lTcTaj#?4VOM>#Gjy)}B2)sjB(K
zx&s>P9(2L}kIEF^h4}l5(7k_!9rr~R-_FftR6Xvt&aj_4XoCEW-Q$Qf$9az{6-c~V
zH)M~+;%?Y{@rlueZ!)jNx%+B8c3+B<KAN`k_NR7tf2v_(;pmhU_-Jo6ocYlcn=vFN
z7FX5r?+d<lZSULd{irhYyMOB9S8LM}>B20#>)nj*f|vT!p=Q&%H4JGmrqI$I#VvKI
zXGRV?8GdWB&C~fW=nPUHZ0eAhxc_m+cTBTZlMlE*uH7g3N&B6@%Ui6LcAMkT)AruB
z_5H`=+<8XV!gNjYvD7M+;!BomHm0d%Tx{)OM+Y_kv3B&>eTCfbwOfPx85rH3pp8S@
zj_DlaccR*g@qU%2A9U-Xa;)#F9=!1EE8jQepW=+@YLu?k&LWAciz(*Tu6O#8XeTY&
zNw;~~{nZxlo?Ay>h_}14$4MHL)N56bq)Ur%?madc!EVH9^}tUf)4m)ze|uJqv#)w@
z|IqtO*_OfEwzN&}`*3uq7wQqC>-eDj*2^7RToCP~|I>ET1+1yu4)^NyTv<2q?TC73
z-1|kIs}p(PT3~FjXWZ<tkF#$l9mak&cSg5vS@^2@6PEqlV{C|b8*Xe&mu+3URcZa&
zw0i}Y>QiI4+~BxZ%<g(^hH3ML8_(4{e@r`TZyn!u{x5o+`*mJYk3R~8ocU5LA%)|1
zvG_(GI2(OnL%Ak(z1G!r36T6~zkcU~P|3hKr&DIvN*!i{&1|<BU6kt8`#u>(Uze3h
zyIMS6wEWD($wLyj5x!A1yibkjyBvB|n)U;l*xnwPu`VvE$#BOFjn*FNKVLDb^Qn<-
z?p!*>75CY@HVOG?!svz!u&Sk-A8R^k?4C-#4PvG~_KLl1Ufg`y>?7-rPOR7GA;%41
zbWf(#E^l#n`)S>U|8+a*|CIf+FFRXwbi?1`9`zsQ;&E}~`9kL_6nN44L7YvOJ!7om
zY)kU?*<%=;)VI{OKI@14yynb;!gHi|TbCNYqs^`b1zXjb7Qa$wc?W%J5~J&rd^7g6
z&fjKtEvJizOV%A}7B}kBx>~(r&g|S|zWe-BtcyQqbctOGy^rZoW!Ug_HruOs&ARwt
zu+<yIp`<HTALslu&u0sCxoREKt0e*ZuTB{I`f2WV&G|k1R6Gmx-#ZJm5IaLt);&C}
zXt?9+s6#`FjrM%r=+MLZhXUlkjLsOG(8$Sd_yT;VFuL_&mXdNujx|jQ&A2(E?5e_R
ziq4sFYU8Y!y)_5ajIn8kODHBVI-8a=dzKj*wPnKPQvE)AoP3gACbC8H(}cmZ;^j4Y
zd*wRyNDtI!F9v^caICcMMUe$(xAfMSOnkGYV)40)M-Pmxx4<KDA;<M#bO+X$Uh34)
zvtVO~_IsM0xiR@|=#$l>+)K+g26vFu9BBE5<3=#L8QOcklLF?fn%FTo>a+E>HZCnY
zd#Y1M)C#=Y_1v=-yPx5^g3%RkxkWwoS@PLy@4HS9+*oc@gM&&})95pE5;j(JRrmAV
zj{CtFT_5?yosk_=#?+S<Y0W*k_+!&Dm*cEYCLJ){_Tv7oy0fJi*VU(dRC#)?+8;>|
z&j0_jL(cD6n^w%uH~O>Rz}3soE~#wZcfi}xJKd^oThrRP;)+%akA%8yY4o-v?h#>h
zqTR5~RrgD?-q`diTt#tgS`X~~W_Gy?KgWD*>E-h-Sb22cmi2Q#x{n!dRoUD5(fx(-
zeYt1LTyaklqdQ!&=fzsw_=jsNryOeFX#f00XvY&}Ju1!{F=gtP(YC3vs2_~(L9~2O
z-FBT<_FFP};gHFeBm3ERi%j+yH`2FrMB?1zqTO({jP$hRtvahUX7Xq94{bjAqzw&x
zGId>J+`D8;^=+zST!V~B9eg!S&R_mAM|pSk=yn+=PX1i=+>BQ#4M%RqnD`i@n_s1p
zX-n5LPG#F|Hyw1QQOxkJXD;^9PU+HeMvqE%`_8t(S&@vc<(}@2AKqv`hq~Ghh*;LL
z)UJYw2TE*c$5r}#vY3zU;bFM9hn*=oTwCU@PotgBTuaRR^;BBnl`G8y7SG-NdAqi-
z=Z8r*j-AJu0F3U&^NY$9>&BO?Uf9Q$mtWdkp=+;A`wA>886(?M@X`AU4{%=@qf2+&
z{MxQvAMX4Q{eQ1e@b=Nezp4NAgW2iz+wDa=U(wFjaQ<qTBk8?l>5$L+wiO$wE!Au5
z%?2Uk?+q^%cd_29CHt#KY7SV}+JrNh8C`#~rzt*uqMh&4v!b2vx92BCJ72FY*Ho1z
zi*~-$zLXpEd3&j?HSfN2m~>0D^KFj#4bjdwFnZ!Buj3bQZ8G~*)3imCVb8pa>9FpC
zv6#eUc#O;TCIu&0Cx5nZzqiEmH^1&atCG_qy9d@Cd}~w1pfWh)3TFa{cE10pWn7UN
zQ38KT0)-GN@K3J)hXzL~zgqWK;q1R4SzvHTh)mlrLLJ#p6Qbgm{<;6<vjDyIX8~?3
zz!yUaKw&&T;7K*Z{j&OV_?ks%TdB3pNk}arBVR#86pGFOB+S9-@M+1>d4EDW?e*vV
zVX2ax_lKoxZjcl1q0LIC>$lROa?ioBbS$~z=IAEbp?hKK!CB=9FM3Dk5YmBsDA{c9
zh`+jA3G*n>NlfW3W0{N{JD8JBfaWb8DIQ)nSkK4bt&y+^5K9`&Vac1_or|Sq9mx{Y
z*X+(+PyEg2m7VFw!jZhOJ%>39&=tX7bUt7yAl-pX=QHBbk*w&PK(g16A_37}<G<5h
zV=<fO`KVdZ^wXeq@!LbYRX5r6!*1^_FRz$1-n}5Q$=g12q-oBgUB{vo?{_udbal+R
zz?at11)sY2+24QYU5w*IyAIK=WA;Vd*Dj&)e7bf>Y_ZBy!#ZByeqnp5OC2{|iE35O
z$+X4NxZgfhR*7~UqFu+BV}2F<!Z_}o73s_Si?hb+Mq9-NNzz;PberqfYl=42s%@v$
z_T4{g$JM%qwYIu7h_3m8A9qxIEZti?xkYN*R*vJB7X5Io?QVaY(c%AVb{!rn%5RCu
zmmREozp;1rzCWksy-QsZ-RhOw6FGe7(4W(**BbE=c4(qq$3N@NSkbOSwCnh9xZ_o{
z>k#caM7xe5j@xaM<SjpyZY<h$(0Ie?bD_P?>o0h=-`y}{&#LhbI|?q;m@X<%ee<)<
zGvB3Jr*qtDOtRokv$6Mz#C&f2*yH!MiE&YJex0_MeE6k*bU=fZ8)rFe?SRRU+l+3(
z&br6by=Ts=T<OKT!&@JDZFl}yNaFiuP1u3YC7%y`v4Z2uu<!1DX>P8UuiJZzb{(Q!
zhiKO!+I5(88=7JAOSKLASD#$7**f91ynXeLVdL5cxsAWlEYxkxPL8{e`Duwst3T$~
zEn|Lv%|^SV8JjIfcSxLYd&F_Yr7ogfM_&8RM7s{ruA|XL)FF4ON1|Ovqao)e#wLbb
z+c2&09?`DDXGbAt(XInadZPOd2^g*a%cZvdvcZ~&0sfBuk^XJMwCadZwJKPyRr?Q8
zYBidWNdJ&v#UN!wRG2n6RNXL4t_>cf4v*0Em&u$RU0v-RT<mS>IzScOA?P2f4poK^
z(J%kA^?zF1rFB`}mBM;%m#BhVhhSxdCQ=iqmDK5CBk6!eV~xZsGEyC?2vJ8c(tBKE
zb51!}MVAz2XOb=?6nLXs2{W1VS40JesQeZ3NHw!kFl1cD-)m@Z$El;$ImgN8R*1Q|
zdXTMyzaluyKib}o&s#`C3X9}(4ljhv&J%GPsf`E@3*v7})JsSn8Om`D^)>_+Z1J64
zo5%8wC4DX$V<#?(?i1wrAoy8IzfM05i{+|FE&EMt==7V|qI>zw@Eg<hoKk}l1D4?m
zn@jk3nrXs^bPI={CH$Hj`n8uw1gSe{2I=4RFnrgwYYV$({nW|<d|cuDJ1?y!v{^s+
zl}B9jct0N;4G|R9S}j*O@cs$L{y2}8=nonCx7TQhC-T3{`-2faDq9#qkpFFCdb}Y2
z27{P<GU*XL^LOF>`A8^!eY)d~=)oqVk2R*(^MBjW-&Y<SqNh(a_Se&!4rcuD=@LEC
zC0SQB_HW<99#OHhYxD1#qYkQMOn_wHP}sbYp?_33|4J6Zghg?B8@^}ZWSvkPEKYy^
zo%ax}I<w44URvJYHv+6dA-jd+`=9)W8~fvXpZq5p`|HbNiLpO&LwdHI_op<QYX*n0
zeB8+H*HNSOA}vv4>4d#c&i<ag)T;!O-OC)_Q(%&TB$~-v$PcB79P#h!eEkl&;@`P^
z{SG<f-?jhx9V;s;6E**?XJ{x?j@22)uCE$(k@yKUd~c8wdN<tg9Sh6nlHR>AeAhKp
z4l^N&lEwMvt9M!9EQYZB3-V?mDIdgZ<?Qd6ei_QuHv4<hmCSrNe*KOGC0?6nf7eB=
zjf%h$AuE3${vG5)Eb;vJ$>x_;_7qomws%=Vp?Bx9y~`2`y-WW3T_%6&{5xLnS+29%
zHEw98yt;+6cUf{a{pwwooXZ=&%ajzKzbeM>^g^ckBQ<=dmlW~u$@}Z&)GbV|uMrfc
zYvwy9D@u)(r+;>T1Md0qmgn$Z&k744mi@h#s()0Zwi)Xpn4Q^Ml;I&VxZ>Mdy26#Y
zZs>rvlRw-P*iaG91CrU>d?1;nEdf#=9|t7Tr9iU5iU*nj*8|G{Hvlbw*y5rq58Mo_
z2uuW$jaCv+0^9|}QZlz2i0e1FJwR-^<Msln67K_IyB@b6h+|T?1Hk6ML%{aH!@!Qf
zBS0VEQJ^pI7_b}gIIuhL1h5D2EU*{w9MBJV9vA?;08{`k0{a6m0mFe;fziNgz>&b~
zz_Gv^z{$Ydz*yiNAY{co04@SP1VUEaBOqkNJqE4-J^`)<;)oI5THrHa0`Mgevf^F=
zw*X%Qw*gatJArS2kPX?@=^z8{58xr-2O#psr2$U@KLU|Q?q9&mz)!$BD8SFa2EYv9
zSRe))y79n*z}vtgz`H<G;P1eqz=yzMz$d^TfX{)&fv<rjfNy~%fvG?<U>eXI_%C1?
z;3r^NU<S|vSP%+S4p<0S9%u@z1S}4;1eOH;2s8&)23i2C04o5i0)GTn16BoE0c!$l
z0BZvq0UH3Nz(zoOpe@h=Xb*G*Isl!3&Om3N8_)&l33LT|1KokmfgZqCz{bE1z$QQ+
zU{hchpeL{!&<p4f><ZKZ`v9YXeSt%OGT>0495@`P295*<0jWau1C9j-1IGdT1IGgg
z04D-9z{$XYz^T9p;0$0Sa28MtoCk~o&Ib+xE&vV&E&&b$E(MMNE(eYTt^$q%t_7lU
z>k@!5z>UDsz(n8}U=k3zqT31_2iy*f1?~dQ1nvdS0v-U)1|9{@0iFTQ1zrL!0R9SG
z2)qGY0=xx`1O5hF3QPtr2i^y+06qe)1U?3?0zLt*20jO_0loyr15<zr!1uuQz%<|n
zU^)=Cy1FmGO~3;9Fxd<&1l$5F3`_)?0+WD6f!lx*-~pgD@F!qR;2~fw;9+1L;BjC*
z;LpH@z>`2b;3=Rz@HEf?cn0VKya03uUII1&UIuyruK=3^uL4^GuL0Wte*v}y{t9dl
zyant8yaVh4{0-O*co*0cm<;p-{toO5ya!YO?*o;<2S63@Ay5r`3LF4@1`Gwh0EPiy
z0yV%_z;NJeU<5D)s0F?O4h6mi4hOyijt0I5js<=IP6nb4(8U5j0_OnH7U&iN(}7EY
zXcKg+fS-Z!z%Rf}zzpD4AXgCj1uOvE2Sl5pI|MWV9tWcB(47Vr23`Ob0bT{7Ez#Wo
z76twWECzf4`~mn3h&D#|0$3XO8fXT511t+n1){CdeE^mNrUT0Zxk9ih1{MNV1Qr8U
z0+s+;0?Po=Ch07IRe_ekYQW0C>cDD1E1(sy2GAO44Xg!3+oiJs)&e#Hq7Bp80&Rfy
zz`8(3V11wq5N(^z9oP`q7>G7b*AyrPdIQnc>6!!4*6CUU9f56tPQbQ6XP^(T39t*W
zDX<&R3)lmQwolgw*cK=QwgW1FutnFYfoKDD;Xq%Y7KpY_Hw4%nI1<<cI0o1gI04uT
zI2G6%I1}gxoCic(sap)}16&U53tR(~0oMZqfLnla;C7$_xCf{N9t5g@$AD_!X<#7m
z3@`|I4mbdK0T=?j1k?bp0K<X500#oE10#URK(x)e2f$&#r$DsPx|hHaz_-AWz<0n=
zz%-x^_z@TbOb4QE)_nm^0n(;`X~2TO>A=E3wADIO;7njKAlhtQao}uVDc~HSIdCq}
z0yqy?9*8zvR}r`n_#<!;unG`ux~>{9?*FlOC2%!u?R)2-GDK#Xj)Y{&5S36NnKOhG
zr|C4%+({vvBJ&V3OQw{0C}g~HGbfQLLdFakZ^*6qKkwS-a3q)e{e9ne@BQ}rwR_Il
z=Uscf>s{|!d#|;hwHB};a5YdD7z1nsTm#ett_2zbV}b2~8-Yf^IA8~0JkT7t57+~k
z1nddi59|dz0PGDs2<!_y1ndt)TQ467JOUgHJPNc0CIg27j{%1Re+AkBQ-C9Y$AJ#O
zlRydZ6wnEH2IvAj3zPy=fgZqfz%jrypcn8w&<BWnirg1?5txVO!VpJ<D?NYozJLCq
zwa1%5zTpL_<r>$IMcY-A&Rgl$vzyd@(w<*LZj;Jxli>kL2!aI!3kVhvEFf4wuz+9z
z!2*H>1Pcfj_@`L_-BNDEzc~M2@g6(GTSjmE-2$ZiD{Y+i@sj%dob~>@S{R0OXk*f`
zoinZ0M(>sMv?Y?UE)pjh-l97P$)tgJH>s!XA@%Z;2B@ATo`IgWlgtb6%_t7u!%G5X
zU@}O&oqU|!rQT9{+d(qessQu!^|Xh1`ndWA2jV@tp0*X<m%D=8;OoQ7SYR#RKbGmM
z9aal#&2yEsNlzLNr!W8qx}sb^91}ZWjA0_Zb5e8h_4fAlfj-PsW^Gyo`2@1ppkgeT
z5FqP<cQoHx3qUO2jcd`neWD3yRK_?j;}g*Pr}EkraE|8Ydpm`AdIxz+l<)m%ZoX2t
zsTlL5psL#h=$0N@l5U2db#w7>3g|-bmwrq)D@?xsv%1mvYH{7jZsHQ{rlQ-w(QdsJ
zWlCd(6zJU%+1>^R>1H^y1iMLGN+?y{b`<yP@UN9CaX@H2hMFjIPxv$WMLxchUwApu
zTVsCR2xT7Pslp>r*^?f9a8TKshn1WM6$>j$|Ht$2qvfy6!vNGA)jUxAlJY=fJruqw
zhluayLE$Aoo`)Z;U&=guuN?X-eCZ|D$Dn{Qf7B=TPJsDRWQlnQ^z?RxJAK_uu)27Z
zF7#Cpvv-3vIPFjEM72+~k=hFFPi;lDVy#6L{6;=Rd8xrlgqKfOtou=e3k-5|^9)fo
zE=?eR>C<oCp02K5Qi+p~tK>^DmgdV(a()3)x(1er3G$M`Z?&}@@!NFxVhs*E%J`C9
zw6!07lIL3zi6=N|?mQ`s@^A{jQyJCZ6zM7)hJH)^6j$+^qA{f3azFj1&_m_7xA<)?
z(}V0Taq*Hm`2_j#HaPkzJw@ge>FMH{_lsZC%{L&}2|ONOH@85kj3b$>;xYl!vDiLG
zs+6h0iM0LT-?{LQp(xYc)5xds4ghiAA@1sGlvk-2yM0MKoB}08(enfk&o_Wvfby0C
zxk#qJQjTgB-wx1yK<R_Ba&#8sw@9E4FcHY^QPWGRM+zTQX%Li^iS7q5PYL1Y``~9k
z`_j3{KG#0k_K$rq?~~luKDY+IEeH8P)dxTOO36M*e)cUN{9I?g_Q9{}f{G6o;hIan
z;e%AZe0pE|;OF|H$Xf|Mn2q@Kj8KF7l>e`MFc1Fc2miowy4=hepMCHH;{J#aQoUUI
z13s9~9$4^BK+z78FVg+!Xi4{b3G+ci)pk&MQz9QcT7n1S$>EE3knSmewjHGV(%+#S
zq`dtn+d)3PuYK@mwSyt>zdZQIP?YPnNuPc2XSai)m3YVb>Rw#pGtt*RsM-$xh!0ZT
z{j)wO+>8G^_u@kMUkLnzd~kR8zt0Ep0K@{VA4m6Ma9CJ77&-Zy_hQ2qD)(a5cJN2;
z#XqAR{HxxJzts-@yY9u`Y6pMTy;u(aE5tpB?!__k&p!CG@5NK`Y)Rp(=fNpI=7Xy3
z;E(v=&u9n#sy_Hndmb!}_KC>4?0InN&-cL&ihglvJi}1X#6jJB>L#zH=RtmKih5h<
zGCH|<NYNqwfw3s%9GO<Q=PJh*=#i7YtBx%w)1RtHzcFOW;%KNyKawBg`67KoMf!>%
z6-cTEemv(#(|1<P{SnvTuL1R#4M^8n$bb3-RtFWsm@3^;iF**bn6QPZ>7+mSm99$9
z$bY0OjUCZg(oCc$^Y9F$IMiQM>UKz>TSc6w@}Xl9WV0EUT<x2w8~&kgWW^uXZDBFp
zMkws&03Htoa~xE5CO9@h)|~en72RZ*?jj3R9h_tLPE%8i$@)13NF`GLASW-%JlV?;
z_;uj>6k6zWQeTQ6vk1Ysv9>mi5Aff|G21EiD=b036zC`a0sZ)P^=k!xrhcn1c1@uZ
zjz&1z<2VTYY`*e4h5d>@dwi`Pv!5ZZ^L6-aKk5VX{cYZUWKaJ4m-aKO&0j@TzjM$p
z@(1+$Bm4b-^&6z{zZ8XjbUiVSW;mjuU*)gL*U!mij6~^#s2SvTc#R=(#?%hHng|@j
z>_*r4I()X9s^3u^RqD|fV;2-!;lTE!TvHsopojP?JE`hHHMC?ss2%z`eAYv?{P?k@
z%Iy8eQH3644|<*@d#r>W*?*`9wPNm4nS{pwB&6VXZK0ZGdrAnQB@X)71ji1f`SPpw
zsd(PMPV<lQO=&9UY9=Ytr0PxgE4qDjL*%1;niw#mcVT>6f}ctXY|Ulm`<$1s-jBXB
zQR*PB%U_n#CLOBc7>9hzc^!gX0+|ZTmb~Ow|G&_o3-nj&pqkeWigZ--Y7E&mpVIkr
zc~wp4d+)AZL*?N(`1fc0`-^3GfkE#u`YN)s2U({4?*nQ9_XEYi13+EiL11$r%@67f
zOa{_>xnn@(_4#*T|Gw+<@3H<p*SA4l_;*qKyAiSvJwJ8FK>;Wyd-VX)qrMf8s;M;)
zpSj*Zd?tIcc~Y<qvkP69e?RnD?{8g~DnDJ9e1xvs4M^8Tn(VstzDf1EhU|UE&(#<6
zoH+hH3jcnE>_D!Yi-Uq4^r3ey0YE(<?)7rI--Q5s0Yic0YZHMu$Atlx0mFfqv&KyU
zCIBOV@F{Kv@FZ|9@D^}BFb5b3d<$Fv#GEQ_5fF2uxG115a0yT!h-=HGz~w-1;7TCo
z^ssqzA;1`X9}ipyr1@CufxCgRKpL};2VzbMw+TpooR7ngjp6fsxsviv%@*aqA&~Ol
z28g^eKcM{E;ydL(2p9%j45a)cEtdbCK+1m-kn*1br2Jn7QvS&fl>cWy%0JnG@?Q#i
zQvNZgi{-xokn%qONckTIr2N|fR|B1alz&$s<=+oT`Ntd~mVe9*V)-XKsOFy^Kjz1k
zOUnPBEr00D@*fAJ^4|fZ{G+X5`9BJz{9gr9{<DFU{}({YKa~mPUk!Rv{%ZlL{ObcL
z|Mo!2zYCD^PyRsp_W@G=Dc_X;aX`vHjSo@z#{sGQsn4#O|424=`M>M`{J0sL<HeO!
z{(sj0QHHGiHvp;pw*smB6M^LaxTmo4PXki<lOIs|KLk?wlOIs|lOIs|S3-GF`Bw*0
z`S$=)`S$}-`BQzM@*fVQ@*e@D@+beG@}Cc+@?QX?@+W^#Eq^~YX7j&U{|#Yde!PJ1
zqf+^caE{t~3T<JpGQbW%bznyzwVM==@8|P<$l~#uL9Q%h41f)Rc$WASkMEx|>J68K
zvQSMAkAHGa$WuF80Vq?%)5mAN?~FOJ_)PIi0Tqu~To*;Wt_pe5kMGX{74oX-%!6EG
zoG1S?0h0eI^TqcwOO8kWNAbx2DBcQ{czpkl?-v%&mmTC9L4E|VJ<why9^Wr3Ii8Cm
zo~t6BR3#qYU*gN6czRPICq_CEK$HbHO(h=Rzv25m#p4ZtTm#740Gk2_s>I{_BPFLd
z8FJK4$ni(%g{j2j`xJa%qj-AsyhHKutRrs%q~|GRIq>}gwhswwmsHE|4CKl{{w%OM
zFjXZU|18h<FN*u+4Mn^xU{%DssS=NWHZM87i;8#|KuYftFb_z|3wxscJ@-VZhsq=t
zO*y2lXC&IZ{94`3I_*s#dd}f8W{qEe&V0N$tF~)LTXc>N;lW=l%CG#rH3xrVauqbJ
zx*i(QD1KV2VV<j78{VvTu5;oBP0{_rO(q7zqFQc8dkLQri@q;s$MjS4?mcd)>+#sO
z_PXZ3+nzerdU`^>-lNuoJchM+HSN{%wir8M*PGpO;VI|p?>cn*pxrP2(&V)lf^x53
z?B1$A*L?P(saH+VFs3p&XZhfPy-w5_J#^PA%_AKe=v`_bw=p$&W_|5+gE5`u_XlAt
z7mcb|bUyx`v-bgQkL63R6<)C)S&(<=#oX-ZtM?y;jg7XxAjJ)~E0c3M(I~#@t5UxV
zR1@}2>2$YGEaqt9fmtlt@4j_>?<oV_?N2mVE9{*j?41%f%iOws;9${(F*h2X+H87r
zYut@9x^6vivy5#>{<1ayS6d&M>Emzjo${l5IHj@c<#gEKUpOiM!?Coig^g05k4Sts
z;zLy{&x9Sl3r0N%_qM=$QYP2`evRE1`}a71Jj3BZf_1ySecBhTFj*YxcGXt%ZAQ}j
z0E~<3l73He9&6vVEA?FG?bLX?HjQJgwY*FXpBKcm?4{XEd)JI$j1@4sh}5dj{PdTU
zzxqCO!TZ@u!tJf{k`5V<e%9Jx^vcvD=2I}|n#rjj*EYKT=&*C-5H9iEg>D{CGxpR;
zw>@CgCnb1D;pTKaFr8v@v(9IqTyNTM#NEbS{oUU;*9w^XWLkdPnQ4zN3wx}zm>zR-
z*i<jeUfk5MK?#Fx>sh~0A6nD6;he}FnH)EV-9KJ*(wtJ|=ACh4=hn+wvuAtwgq=Q(
zo<z+lFuc8U=eo>2=!^+_tO$Fo`0c~EA|Cj~qVQI?q92Z)U~HDYHLY}7O|@L>`_at?
z?Vq9>-KJt#BT*&v>6x725Uqrfo5!7uJ-e(-l;Le_t!aCD?ORr=r~cgdb#k4X_3$o*
z$&Jju9(hLY&@8D*hxFu%29qjBPreY>#4haY-fh}RX^-*H|CGt?98~&kSigD`LgShx
z3VW;wd#p^qsO3>)cIr_<mB1d^k2eJ`jCX2${J`L29H)=L1hGh(n(q0by;1GB+_KA3
zcZ~2A&3Lt=R{6y%!~G+hFEiV@9BZgBxx=yQ7Y4L4FV(qy-~HXrX3l!;{b<AFPL(8E
zJ^P6p`|G^I*e#QrFS|QrreoCl8T~zjiu4kC8CwlBm*!1u;&yxRxhFl6o?xvHCRg5S
zhjh-9?9|I|2hS7sSP}ME5%yTw7M+_@F&y*gFz6;0_E;&k^KgYNeYo01r!;NaBu~J2
z8T#nhD_&ORwoU83PfRK-xq3Rk%(`{jjw=@@6(!2bn7^BunUaRJnwVVX({z`YdYv!m
z=C+Hh;dEhp&B1ot4ywge43q3H_3&-Y`xrZCas{T_U$pHrl1nQ$`cBPKS-&RVlKx(<
z@|n$v?Sws6ggsV-JywK0Rz}@&aOnLaPV8r35M(<Z?^}$i9cp}GRm}2*3ygAJCCmw~
zx$H)s+V)AD&D<E%VePLkHQKlroChZN{qas=j}>8$6=9E+?3(VWF&TvsY4?OZR;Ya`
z2$`7S{jTvqVUHEO9u$IL0l@--1q2HS77#2TSU|9VU;)7be^U#ThThKq;`)DHzAjE)
z{N8%1>;LhmB|&~zKToQ<_n(?0%}1$<HHz;0X?(&j_x>B;hkXS-$74G(aW_ni^Q8U%
z{_1P~jaAG6tW}D4f?5FL`&PkmR}Wm|S*mk)i!DKDYU+yVrizsb-MxIBoxIHW*{TXV
z!ir8}15At?>*N)L*{LCZUY;&&L8l*`&wCI$DChGw!5m-Ep&3!xB`6>Oiy%t)R23><
z4Mb@OKks+EB42qW<m&^jnf<Tj%Ny%`d9vA#-_9DFt46;0b@;qa9?eyL@h|4hQjxc*
zM8HJ=2b?Q|!wAPk5W|o1^Svb!>_sV4_%gQJBZtQlWNy9?`|f-?<=pRh@S*&$#$*lH
zp7`IXc-NtNDVk%~TcHo_&q1LR4${X2$7SeauC(<x^eOHah*nZy^Zb5PFY=YjbQS#j
zp06nFN&99{P_<_U^yf;_|Fb7BlafEP$Y1{}QE%m(!9DHpp6-)V@uj0WFLVtV5<%6b
zSD};q`#Pzb^-q`gAL;jJZ2KCz<29tB9l<^`lo{knl{+4d>`<FSb4IA$i2*9(@%8l2
z#lvv9q7Lw7DMq6~McV=g1yE+>WL6Xyn^TE2<y3d70V!RI&-*NI_u}zEkzw&clVN+g
zp^C7%2cRQ-iqHE@$?1cZ%;JOo%hCrmhoujm|EKtT`Iel1TSa`h4oe@pv-IJ&j03NM
z3kw|hzb6O&zr}4AIO~(EEFD@n$iB(8Rffwm-ez_?Q(&Wxc}=LC;NDwE3y*f2Yun1J
z<&@H^_mtO>=bfE2;gsKvS<N0V&E51A^K%%-ywh)IhfL|#bJpQbIZa1qKkB>pj#G~f
zhPF{=!`s|V*gP7Oe!`ht5B1pWl)QSi<11G0Hl?dhbY#;BzmDx*r)kL4gQW$|`ly1M
z?VH_9T0f;z_Q5%|<Hsl1hR3z(61Gd=tpEQx>jD>jxanehyV<fl-QEK>v>RF^i)eBg
zH*SMQRL{E~uCu3Bj^Tmw**)@l_cWTeTI1d2-boJ4!u^6ZsuX^dV;?srcR64|b=!xo
zHJ`}#s%OTHdGXLZX407Hua1SDdup}2*D5?nL@~LOqmyD?blP^=xhwj4pX(QnzZ<#B
ztYzK`-37sJAFkPV1?NAN$qk%%?NG-mSC+0glln9%ZAW6K7WOsE{oeUz=edpRPe^e$
z$9{q6D~LtOc6Lu)40gVr*!*lKkHB;Kfrl@<MS7Y?FY<Z6C~H?To^v`exwsg=^?%Go
zKO?2<jdC$5Jl$a7$iOyfg$1@XTCSU2OG|T~xzX`T)ovcKF~p=kfr~D1(FHDgx!<as
zFS!5l#Kw*8Wg9u{Ups11=9ML{{md{&9TTC&qPb(MO7hgqPh9D(c_HvlQ{NZ+N4MOs
z-f6^c-^LYswtElma~_jB_F#eg1D}a&9$tUz&}Z?qklR)ktG8sX)tcTlcK!UY1_4;J
z4V?+GsKK5M(_B+(FNpFFU9c`fYl-ZPsm_$n*L{uhHhpw66u9UD7rpDi-0Gf>u&*gP
zwPI1}GDf>rI5z1odAPJe=q|Hg^p4cr@_h5Ga}Dng7&-C7TwToHXL6g)YaE%XzII7v
z3%$$R?i$V$_wSj}xcNDQixn$1>^QZvGxiZ?a*qdDoN;%K_;BpP7XSPwzeMf0of<TI
zz@_8*w><5`huiJNzOOAQ-H;-C{|#$WSJl-XHRg5rUeo#svDO`Ht?jw|n78SU)&dt@
z;Gzp$^mnghMcyWD#stJzY3&oZ=oqvTi>4>Ll>233%Cm7HuTySp&8zkH(EGmot?mY&
z4X_C=f5{T#Z|j&`x_{-Icgt2hfA{?AM9J_0T^?3?oi_ZCPRD+J)pcqmZgj=k>P&7*
zEp@lxf^}o>M?L#>#pdJ&hgY7cyDnqQ-q~5H7aemS2XmZOdrCK|WqG;4MHjf}0vBE2
zqEmaIar0wDuKZQ=>K+{rrVUsUCI7JIo`J^oTcOFL)6QxvynuD(@DfWbI-yl{(&YSz
z@OQ0jKFA^m3=6brsT&j0sDHfa!6q}_KEfIz8<||w$o`R<#<EpaHeARNxaa~GUErcu
zTTnFA7cbhjbf$VFaMAH-BLu+$f&~N%2o?}5AXq@KfM5Z^0)hnu3kVkYlNKOO=g@zV
z|L@}KgMDLV4k6w$2h|AxE@Nek_HW9WX{$N@vpD}+n8BbL%5r_R!$8P2Rq(efm*Rh|
zqQ>t{q6NGSuCaKwVh#Y~Z@c+nS81ofKu@=E5GUR<@q51xpSkX!rEnRwIgU*Nz~>sA
zhW342mv-&(^#O|?8$plrlQNDu?cJU8#c#A1PI+zReu4Z%0?$B+kCTtYH-Px;o<5#3
zQiUVlbQeWlk`#IAi}RGeHI7HPuKAo|d7(>5-JN8fW5I~w^Mm1v62i~R59z7gvn^4?
zC)HkIb3<TR5P8j)Fg@L*5}7X)#NJ+kGLj^F>zAM%PBET2@$@ObS;(tXfP0WP%uC|5
zM^6QyjW+n^v{94d9H>fMA!O;CpKsuI%jQ+FvQh54))3cm^>k-*JBT|@`$tk*0lq;#
zu9n!etRJ5!<-M(9zr3wwNeirJ3MBrwF7PF;zh)VqcRvX>fcAEhNu2n6vy8A9JfB<f
z@elK@<gxpqvEa9BmpEesc(w_9edx)`8vnldO|dyV#U=Z6sEYUJE&)z57mrVob@3bH
zvLo)7zbSW?CqFN*jU}0B&3xLe+Ql=_)7J-|>AV<7dr`YM`FYCtE!$AG<+VZIV#IW8
zi%$G~Ry`!luz{F+R9>6PJ`*-#cEwC1iMOvSIWEnMz^i*M6Bpp;Ym{8asJv+3$x_hU
zLmJ}b>dN~@BF=$|#<@zJJ)Hu19ciy_WSvv$fsaggD%;|IK<U$7<78*vk3`x@@a@zx
zY|jYpI4e^=KJ9f*Hj(rQ@e7ckM&mR21??YCaWvouOK@({a`FQ{Z?rEnySCyx?IA{a
zpuDTbjYr&YL~>ur$EExpf-L1t)$ggDfqSa>y-2$P;)dYB+WFijmH2s(RrPOWdL+LA
z#|+3jt@^Ah?JK6#m1LEN((i{*1x29!W9VZY;BP2X@#12BkIYehr*bVJ$amx9x9Ypn
z@5y(+@NLBTPx(ES&wtwQmHzz(_QXD5ZeDOSvIY6iJDj7<>%6GmDC!jXE%~#mFPSRZ
zrxxXStDnKWgv#jzuoT*6n}x;83AZ7cG{6U*{O$W8_C3NiNEf=+x5|auXquSvMVTp@
z6e?@{#Fb=MG$kdrC(1Uer1petMeP$!c=BVG;@bkT;#%$!H*cz^WFu;qKDRC9wW&^!
zk1N{-s`DgA^V*cYPxW~?GMkRZeLdn2XLkGChJ33Hpg4tygS{^}(W1}wiuOPzyZPa~
zvJR50KFVn$&RIu&mZkbl*N1*z)xTBc@dH9G4l0XBINrlI{MHmJS2w=?QQk`kf4lle
zz9&XTzIFdlEo1VHEZDGkJ)$=LTlI+Ay^`utciJEZAx6>Otpt{a&!w*}ZtpMa5%Wzx
zs_K7cchZl_j{HG+LszzWRDbw$U*3yLsylQYsyoH&0M#41KdaUO(x-SGp#0({?BtGz
z&>-B2sSc3usn&rt@V8V{Y)iz?V|nK56xp)4Ka*@}*vkR34l%qxQ@)hXzj$2bH<(n^
zS7kk*c;<*V9PzZ7AM@=zwR@zaVuwsuiAsZ9{Jt~;6XPiOE6R!XbEEr`<Jw~7<j&WN
z_PluU|9`uB@t=4eBR@+;S*X@0N|)MEYNu3vi0;qI@^+W7Cp~%=bn;O=Khp2yJLKnR
z*MkBjfu8O@5^R*|F7v>(iu)k>4?QoHRBx$oMfJRRouNl>iJPCy7dKHVV7i9VmlUV5
zmvta!uJUcMrQ)8MMU@PJ_6nr>sSbP!A2MH1%!f+oztO#u-LKdczWDdWz4I2Xr|5!u
zx}fJq57lH#x_45YRqfJ|-lP)M$1m=wI7fDbI2VNDi{Dh9|CQ}PP@q(z`mA1qtDyZ1
zddO?4;r_z!I2wrSknO2V**)Ahn4^AzvMjxP@!Y|SN`gJTyd-X{yTtlt)OJ!F7hkU+
zZ{&ySrt*0)iXK!E3~}Ibn(dFPf%da9Z__{zPd6Fcf)@&q4N10y@I}4++-^#oodTt-
ze3j20#oJEuUAid6;nnBuO}3-9#nm%V=H%l-kK#;kW#2Zw3Y~%PD14y?@B`UwDf0zv
zZ5-s~s_^e1KVElzK1%Wbf7r(({Ydxk^=-))s60!$|9x*vg7V4NM83nNth>egL8J>k
z1F18+@cm&b%TN2=!iE%T;-Ipuj-voJ;rKBYm^Z-112yj3<tS#hpmdb?KgnQO03K<X
z?~xryS4lSyMOjp4-qWH6en1FDJ)n4mH;`^*@$nG8%gxfKdr%31rLP75r{A(8`FoV|
zd#d7l6|RhS6#rSTZ~rzly&8UAM%(=JxpvBP<vyQlt2}pUKD#c(ZNs1YJg%V}N22ni
z{E}aOQGapn-`&R{`_uCP*;-*T)&_|c=TvU9tbWt875S$x)(G+S;rsF}aIPd@q&CEm
zenTYc%Tqq#QXi>pE8Y%KK9%iFNzeH746X<J41uG~$2FI+^5*L=-9uzJS5iNm;>=LQ
zX*!oLWAb^r2mDc-Ly9<iRpQY7<&WaLRK)2q?{hkrz7t0u{@e|^*Wmqx*@*fFCEXj8
z&pEFlzXk_Co(X?Mdz6I!J2`R`4hj>{JW>6?7=T<07zXSO3<nMZP6gTlBY>lT(||Pi
zI0HBZI1`A^+$`Wl;2dBka4zr$a2}8bH6np@Z(IP>1R{MojkhiVlAgvm__0d12Orb3
zG|rLFP*@H*(v#LsAU$c#1Z&_LMf_#>%#R^*9E~j=g)m%|^kJc_8Xq5Nv-r4Qv$X^&
z0x9iEz^*{ph+VfDkose|-O0xQYXRw6XxrtBfY=LGz6yxFf#s)wjeuu>O@NfoW<VO-
zGyqcm9-%MIkMr^4f27|CoX^5}3fL=@tqI`{q{mWEAT?oLz{bEp;C|p(;4i>n;BP?e
zF)P<YIuSsm#mxYk0A~U%fOCO^fb)REfsw!fU=(lya4|3pxD<#u9QrEqt-xsDLEswT
zRp5Hy1K<W=Iq19*SQ{7zGy-l0b^~q!_5khx4g>B2+5r=R9zg8BD4z)251ax#44er(
z0-Oy@25tZz2c86;2Brhg0&f9RfxiLMfSMxoserA37l0<fi$F`@C7=!P3eX9NJji9h
zYrx6COyCUQb>Lj!P2h6iZD2C+4)7%KE-)R4yvrW~bAWGvkAUxhPk|qS&w%CNurGjO
z;7gz`@He0#@C~pn@I9~-un5=-Sh^JUiv^YidIHsfV}P)+JP23;I01-v74p?UZD2C6
z3h+Fz8t@jdIxriEb&cdNfG8VzsWRA~6sQ5L2h;*K05$+N1oi~#0-b<*z+hk#Acpq1
zroaSXGvH}pbKrAe3t$<vA+3Qrz_vg!usx8*v*8QO--p9D`SCq|+>iVnf3&|Q3wKd(
z>H8yKTi`3;bzmVd8~6eE0{9V_2P_49)q($sfULd1XMS9Y<7m8!uCE8V7C28K1o7zl
zlYm=*;lKo71n?4Y8W7iH?Un|R+N;VyYOiRVav`uWklHCj;9?-vqZL5ZLALMj3E&!h
zKM&jhq<RtygfDS%z=uGjEzbw;0HUn9oj{Z|w;QMhgidmlA-5NZGUAeejerM$U4RFH
zeSt@Sw!ou6d*CtPSm3X~slXG!)xguh4Zu|34qzHE1$Ys70+<0L`#Iv^$A9>7A+jHa
zptvD8C@exblKrB9Re_6vra+`2M;^F1Aav$70gnSW1F8Mn27CnE4y1Ilaq#0F{CEhZ
zQyb@~3@G%09HoOivVHDtfK-lyfY!jlz+u24KsO-rF82bC0?L3A;1r+>klJT=AeA%P
z8aZskc>?KvGzLg|c>$jQeSvR*fk3)H1p(=K9X6F41IGiY{R{>A0_DKzz%bx)U<43t
zB{vO7`8<V#A2;B~6DXh5ejma?0Y1v|c@{|aM4QI!nF$<<?>B%FAnpfp58y2ze3iQk
z+zPx0+zosHOa?v#qO7^c!27^l;4|P0U;z+qB)c!<0h>V2cfeM_-+@-ZBA_+!BX9t)
zl!)KYzBG{XgZs6j56ky$DL-^ynu>!0?wKq<U4Yf_-5jU`v;b21bqBTpS^+x&djjzr
zy_b~ZGuF^T`wT?h+4BX;SRRb;c0kl2woh>x=rs!8)q$`L(+lY;`hkjdmY`Q@oTIcT
zh#^-72p!}YBEq{=<Qu3Dq<qc5!S~1bej4SAo+m<aP-v;f=L>b7JtwpUw#NDPKqFuW
zAe9$<ggp<L0$uUl3>XgV3Y-mu@5s*ry93GBVRLyk<f9jm{H!;S^fAQ2_l5XAk|Qdi
z2&bSw3u-7I%1<dE9ve9kkm8}8Q1oT^z76Gr%7J`^LVc7YPH_!@OMzk_`9VYA9-uC;
zJK6(1AnF8X0E91dEr6)&Tub0eU~AxMpfT`05cgPlRVZi*)B$z|b_ZGj#{+u+cLI9>
zuLJu6OQV1W0F8hHfqBr!udc9WQ*zGVbIqpF7UWNlTt_}Q_G?G?1)Ybvhcw#1FW230
zT0w&(Q`!4nk2WQ@U-aMGw^&%)>HoL3Q>rDE?~z9z<Fiiq`!xDZVmaD>Mz4@l4Ih?0
z9b3V0`sl@(p=xMcg*Bi~IHkQG5LWH_qswcKv@nSAa(dh?o#W0mAp6Zpu9myp{^_id
z11j}*Yu0w!`Up3_{FsOtt6GOG&ljbw!hK6ja?kYRH%aq^HK67@URQ5){Mj{(Z8apj
z+`2otX_fssE&h6IK-D!T{T$w9ckI=+=E~JeEpF{zEt-Dma>9Vh2bwqQ+WN3ZPHf5$
zJae&nROy%LgIkp8<mPF<aj@fS>-qL$c0W{eY1MYktN1k`*NV;w`y2mV*OVH84vAP4
z=;2;3$=`9*b4lk3A3KbySmw$v#`DGJ953H{+i7Tn)gOd4rEIGRYf1@gN(pO9`2|=T
z^?ZXdm}b;&)Zeu3o`LV{W!uJ;cB*i)vi_M(y8=vB3|qCST$PG-baJcU`M`kWBt!l3
zHT;ZT1RWix8E*cx_0b0{jygJB3I7<psdb08q07*ZVse{(bi~z<rF4Di{qg$zs_V<d
zYDCRHy>(&OfyQGRhc)XK!*SD@Tr;Z$!>f!B+99kdC9Em6b@%23JLmdK<Lid+yY2sG
z*!Gk;+jf|I$X*#3c^qRp7&sA&Mjsga<Y2Dzr0X|gw=^^Cx4L!S)9AI*qOeVx4iOE^
zM_?==l*wItx0*Yi*?OIk$GOw4GvZ#U?+LHoV(&=9t!_=!YS+_$h%rtkx9Z*FJE!+J
zgc{YK{&B>zd(L}5-WXW7o#vKRd1IV+UQfd_Q!bOMo0vYn;k*>HfBu?Momqc+`uGj2
z8|a4hyX?|GWTfGs${8oOma8IrWZUBY+v%HhQZSg*7K24%QTF@Ql5VvvT^ir~rMGwg
zM$P6uTd7g@MXzUGi-onPgtez)&X2uPvz3n4?-TKkq7C`Wd*8KP3&+OACwkj96m2V)
zWVz#6hNyGWvcN8{M@AXucjUN{?MUwDtx;vq?lWc2ZZWl~TDB;&=4dXyi~asq8?H_>
zD{^zOl^HcXzx>&WA79HViCu4P`CqKu6E<HrE;mMgJECjM;ViQg3(gEPUfIdr?p5sv
z7#w}Z<l^pd&fUcE*;S0uhRr^!8<yPEEH2G{*TtpprxzU=w+7?A?J2*)+E|ypmpu^H
z#uC=X64u6|_CQ!0>t65X4NhNJY8Tk>^@aO*Nw*a*e8nP@d3pIw$Jf6x{C?e0;q4w}
z<;Z&I9+<Z*I<o(w<vNY~`r{owlMA?7x$o4eR;2?6=SX8M?#P?>sC+W6S42+cQp3`D
zj>6hl!rEBE+E{q;DFnd+|Dpx(`W(CnHEoLSYU<z{NHh5zLX11O1xOu0h8=?`c~UP2
zY=Rc(5QP5@fdMWKPJVv$@mur%gI#34-p>5ae}Ba_0Qmg`X<s*QXC)WE9H*x}413@C
z2GbloJ#8zRbFG*cQ5N4VEPHW(EW@t@Fi0_X9$Y;Zh;u<4sQNhWGzNz+j`+E1{0@IE
zPA(o&Oed1LN<1)0#MG2OVTPHIpZ5Fn4PZQSDyOf*=lS%+m%oYYEBE;$o-uJXh+FOC
z#U@s=>G{Ot?V!-Hn&P6wu^`#8!1Cz3`EB5J<je8P`DE5#D?w)%-;Oxebe+cNHw8##
zK><EAF*!&|0?N51#4~rrJbX_d-ngn9bCvU-CY=#SoH!^($Vae?hf@GP6Sun-P|599
z&KIZ(8Gc_qN>8MnhceJWp5{Py6U!5?2h9_a;ao|aZHfba31^Sr`^WNJYPx<B;w-5{
zb2qT5C4QrGO76Gn93Ex5a$I93<g_>P*Z3aqo6_Y_9?gJ<6>-R(H0OwPb(Oj~VWN-(
z+;vxcW$Du#IV#^k&+!Tyi?pXA-9j9*AY;UQjnDJ7Z{(T$L5nld)=<bk#P#T0TZNB2
zQuqkzKxONPLmNI~v;GSo@xp25r^fW*>%ja&>668MfNWU-aa7Bg&OsGUwM@w#<maSI
zasMKpIECLDfSg5qfBLSp4;e=_Pc)yNLN^?gr>;0EB2VHk{XS5FT+tko7Wln{@E`Sg
zvIqIRsy!%=#PL_=newQdBQv8cukmOA<<X7eB9GbYSh?|48|Ns0Kda3CzvZLUeTX^~
zL$JU>x?|Z>t`c-l=Y3AmECv2$%BG}pAU>Tr4!*tTxp&4WKytnII4H!S-K2X%Jg^#Y
zGZ0M-@$KYvzt{$(>v*6|;M-(yNKv<!!6+D(;vA^WKxhm(vQtwaT?fB0-ehxNBYbZO
zBzZ$14h}<jY_CHj;BkEK089tM59GIiu($jnunUm*%%~r7;xk(SiO-CB!}x|hfc5a*
z3P}9sUO*Gz0N`NYAfN<j3mgL+2Al{S0mR$@#=~3-bi{XqQn*h6!TsjYz{!n)?m!FR
z7@#!})luFL=nDjQm)auvB;a`9JRta%a&U+lKRW>^$KP?_6d<^QjGyfWM7u2a0?q~!
ze}5j3?tKe^WbffP`1XxocZBRs_U(&<!cNH1_gz4;cLI>gEfENtFn)C(;9-210FMHp
zE0+wU>r;K>+Zw(NqU%#Lt88ahLXNHvIuE;kG?3b;)j*|wd_Cs4(KugRzf?th&_Lu>
z@cVfn@uN}3j5m7$Xo2q;K$H!41xW3~RiIKozOM0gu(*C3AxHX=|I+p2fmBB~0rP<Q
zFvdS-?@UV?uUN4-&hn~Bl$-WjwYJ9P&g4J%E%bPoTJ1*e-xbp9T#q0)KwB7CESh!V
z>gEF<>`g}v|82crfO+QL>vK1#ha6fk?97}s=QWa1$fKFuME`x+15Y1smA2&X%GVsl
z>|#7fc0Mtx>51flmd6+NQtN6`5bd7v(#7oRFsEVDQ*!73_xPHtnSPnQvt2vgY$Mib
zT~xDuSPjdiAICheH?RJq!xP(Ex|a4p#SnO%|36-*z}FP`nzL{tDBF<Qzex*B+nGOK
z)Xpw$_4(uRfu}kYtc-}ZZTxPc^|jR(*A=*c>(AsK<d=G_zv2Fl>$^3g`aL%5WBMR{
z(9;HSE&o1z&8E7P-zPbbweQ-Mdam<!YP?;W#<A8~UZ#f63u0RK(rl)^Yeq2Uo-nzH
z)T+<?^p}*s`aX2Q``Jsv?XB{X4jGSr*4kk7%G4v~Q*f_ma_YymjjlgB>>N3SOMG{s
zo5$0PJ$2G;4;b}H2_90oIUN&OPBFPz=d(|)H|;m#ZsV^0?(dsx1<ZXiEx+x|w8xjH
zq}bQA_rcsiCigad;Z%9JZnV3&z)IM&b4MoToZ&%7EP8RW;rL~#b-k8${Jm&Q3kTN~
z_v@Z}A3R~(%_ePw!WZ1Z{rsP@XXlUdK-QoWAr@KnweDd#G+W1YUhut)H^HZ44|9W)
z$JaO*kfA$uW$!>dcxN&>jl-*&IXwP&{Y))^huLwQz{3=Hm;w)TreoCl8T~zjiu4kC
z8CwlBm*!1u;&yxRxhFl6o}jOY!3eRaywwiroG00-m){Pa=eD)_<d#QVOw>cpMs3<!
z%S7ri1RdxbOm3u8`rg3)FQ>FHENjg@O0Uzk%Ef5CQ@akUC*<DSXRyc+{bh8P#iDwT
z&o%gM*Zs6jp;F1jt&TN4FFcx9cTvK?SKa~-Q{Z9NS~79=oDbn`@*=@gZcYAjKg4OQ
zL7#!^JXXzGK5mxIB#(Bsf!SselZFfo*tz)lsb(0XVRAVR4!8Bp{cffmIJL0irPL+A
zcGhZGRB%eq>S)JaHjk%H#~25bTj_In^1g)DIZwuz<@km+c^2gsURTelz~68DvAa=T
z>J9?GGEsf(+16p9gU_aql+7MwHGf#`wg*!&Q1}jmka*tMKh#LzSE}+We>QJY*xU1!
zc2c{M<<}MITE%YLV!EY8wyg;L0CNm}i$(LczdKkv;?2}YhC^I>b!%T}yZL{ezZg`P
z?BefQbIJAnmAkqpPQ1`GbLGvB9V$6F|31g%{G#by4s4n1%yE10(m*T{c#Z<kk^JE2
z@f?429ROjkP=OB_P#tT(n34bWQ2(XZn$jIB2z*F^4~Z9$LJ%w<SU|9VU;)7bf&~N%
z2p0IJ1&DX{v-$tt&NAO%m;WvP|F`x9v{dq_)%YT)2PlJs_=4_u*Rdv^=TUnGdP$vJ
zoyW<f5;vzn*=N!{<i59#J@HS8kJn!tYnB3)d}>v$FmZ#Gynk9Zn!+p~#iKPEYl2^U
zRG|xBexFsK^u-k6>%chB%Jlu=On$*GjC)-HvKE!WO$XBN_{jE%05ySqC*I^A@%QUv
zZG7U}Ct*BF#3{Fi!p;vo{hsmrb79l_&>cg0T+2;7&z|y5yl)xKsq*qw`QOXH^`roP
zE6YEo8gjLff5$KL??p1-<A49zyb}kW@?HT3@xx>V?7fJ$>by<9#pP~6l@tM8U8XPb
zN9#aeF|RLQTsZf$b)~!&*NOO{hB$b?#TwA`9feIM)x$xdNm+h<QS3>`c(M9GiYG>S
z@jk};o;92gbRdq_Fs0B=!7D|1GTy5R5X*L8Z%uxkRB%ig57rz=JX=d(KVWy@5MWOr
z@on*XLGBF%2Uk89*cZ462wC|GV1M8`;6UIFAmYkj0fz$L0m1*3mxfLwfV7_cNFc2N
zjcd!@fT&~gD4-Ph90;Fg>o5BO>%brVfnp$hknx&>fGzNSA`oi{vvu)9fpYv|?O!e&
zNOf>3P|3gLeUbN3vQug3)dB~FIgq1zi@Y&A%>$AT&j%{w^S;6RO!4?j6!Dh=t03Mo
zAo<jCU><M=3iU_VJrH=l|7@P`kMd{_>CiY_er3mtlj^N>bW45N>wSyz?@MJ)zShtA
zNMWc*H`?XF;a{<aG?S~KVb%4}h(__#S`G7D-P-VGwR4>lH)x9P7j7~!7#7uXJLWW?
z?H7x_FDLMK1^#Y}eYlr4Ab$zd_|R2zxue>E4i|P`w;VAg{P8uDTkV6NmVFhbzoKl!
zDa@f@a@pLmoafCJ)qc^yqlduX75KXXfA^`??p~{^VQ+>;RF6)MPKtHWY1?JzuIT4|
zu3tF*ZsabrmU%057X-U~xMttg0((I)xq%a}9qL%+%F-2QQlBQJ?MUp@!oFs?-#g#z
zJhyTE2`TR8m}A8Fw)rh{d$n<M+1Kr=*`;49jmy&uJnycflb_KhuH3`5wQJ;ZoSGh`
zn`~$I)Wu-u>xs?JcJc^3ryqFuvRkC5dGsQm_lvT2CF7x|6O)UJ@mt?wdd$gTQ@t=R
zdurIAgu%A;tY4@Pt!dnFP9*Vsf0V!bqx{$`mTr*i^S2{EYP_f_F&tbiXT_ScGiHt3
z#7!I$)X4Jm#8GQtmr9K(A8oSyKgLA|bqO`v(t6{u(Mz2t4?I1o*Uby3x$-s#Hts?`
zx-hwMV|1Iymqx13oVvgEkd|R{ax5Y*YM0lJS#&J!*BQ-6KET{JCiiG|(;C%oC!Ud?
z_X`^T(bC>xLbHhK(E+dfEbeo6=57fd+Wsm0-62iMe&MZdML!%p!PqQ)Yg*~FnrgY$
z_oJH)+CN1%x=qEfMxsiXW7mY_Vh&w-KG!Yng*@a{jlC&rgT}@lixX{_@b*zm8TX|l
z<g>7j43m4Ey<lqHE+1Ognw%qA^Ts*#;gB=o59hS+uxzK#iODP1prg@%rMtU)awC6j
z%~@K06Bixy=4NV7n~>RYRqf!&dyTH~Jl{e3l&*Cn=PZp<BLC+V8pL=SuPMw8I66qb
zXF|uamQVH<`F=o0V3Z}veSdz`6qc^x5Uqrfo5!7uJ-e(-l;Le_t!aCD?ORr=r~cgd
zb#k4Xcpl%y<VI#+k31uHXqMEZLwa&WgGrU6CtrwbVi$IH?>6nEw8zNnQzo}_Q0cc}
z{pw8!jcb-z&thTv{b1c!&PR7;=)RBoWr@uWbYSYUe5`UjbZPq37mw4PrVo>**y`U}
zcUh-j$W6a(>DwQ0rK_LDTyJ;ENAHg99<Dw=@5~1~@$yHbt+f|qv~0K8LL*^&Lw~pE
z@duBi@4~J(d|LbIN8_~5{QvpD<}BUY`=6e?-1OIq{;$e--;B7|b$^@N!#Y`5_Stn~
zg>{b!Pp@JxSeEXw2MgRE_)J{$@cLVaK8vS?+_th<y(M$4*7UBi>*t3x2tYp*+&;0W
z!JZA%TvKW<i1H6zur5MtiR_H2&XmsAeU0)qeRMNyI|+NkFu9wF`5O}B5-JXOWoKgX
zX5lzTud#bGhd=FWn0qp7O}!X(?AgNP;>}veRLR*?ep6<O>jSP}LWPdC553)6NppIK
z83A<;q@g^vF}brkv!v@SmP8uroln}?rscD@M~o^vR1PyPd@JyV|FgVdKjv3SJ%bi4
z>)hyB|MzBH3b!ORS`@UW)`8(Gr0wSJUb!<%x1+!>PKdO+HQ-+O=H0<Bn|zpc-)Cv8
zf5h6&7=LO-_2|Kvz!w6)_^-e(u3w+Z<KdcFmrjm)?|b?8!jJ9Dty5B+DlM;Mk~~WN
zsOhVIj{X?vd4hWgcv?AePs>-BbolCn-(yxt-!^#@*Ld#?8-wJKGw$uW=_g?zs4WKf
z#KL;80$&+}v0{<w8M8JqYTK&CCij0f_qQDtwg=7YpI7*=@Rfgbz14Lr-E{xTIq#OO
zc>eDB)rpef1G+q{^g3<$A)Su>{Hp8JO5EuB<LkT%>$3hmdCfn{L+-(N$e~@OG0PHO
z$!4|bbH$?U@Xl(ki`r#dtaNMCe1L00zI_F(4Z`H&v)^)cL;9Fzen{-=lsRVj@j$nf
zz$q=_cRv}KJv=xO&+P)Q`S8uFj~#CPuk)HWvggDn(WgzTSLhqOJ$dNa&OMtBz2LjA
zSI)MU6DQtsk=bXw!3&~p=sW%h|M^FG%^~c1C$y?gnw%dI{;rkH2U+BRVSzR+bz?#r
z^^Z3_*ks1rM;IR$_|F3W`M=43zRv1Lb;*EVZ0xOVTi%;?rdHv~r1xRfYrnm6cJ$E$
z+p3O!UpoVP8#8{kvwZNtUMK2|9=hw5=8+B!^e(lJ+nAa>v%Yq^!I;kS`-8B@aA&GV
zqZY{PKCiheX#LXEp&vEIsZY67c;nRN);R}dPN~0lSP_ADwM;HA%58nEpp4!=4yArm
zyH;m>$ZLoFJ%79M@QJ@c!qCJPcp)0j<OW5j`KK(oI-zo(i0NL^YgZoD8~?23>OQW?
zYD%881I8%DBCn$JnRjv>)%y0IG<`wapft0s*SWceOvcwV^c>q{bnIU2xy!Cs5Hc~t
z`(5LKHhW5UbPJg=+2VNmjct_+8>{!|GU17(rW|`eGr7<(<HRndrt4)FRqJ$jmH93E
zp*HKY^8<&v83f<hR?8hPT{S^I5R3X$?38T$WXs&sH_d<9rTON=hO-yX>{xikwC~$;
z^Rf!G=%ua@1Pcfj5G){AK(K&d0l@--1q2HS77#4(lPpjg*ZEiZ|A8`BPhW=+ZyD_w
zK>G!FwlnVF;O6Ni_3`D||HR!j(^hljICZWnr^DU%)A)q_JY52O1AX0OV*NqQ!~^_f
zp5C70J$>B8-F&_MaE$=)*!8p}lCdrlCz&k3(>X{c4FvC7PuoN4<tGhLJ&W}Rao$Ph
zg)}G*t?kdK;u3EsA18OIx6}t@T#|v#-&x21$JhF|QgHi|zyYR!S23I>4p1Dqf#7Yt
z+`@DF73#oPP%1#`<ZWu|<r|D|9!@^4UQ))}rgHc?e7U}VZ(LKkzQ5{P-+tf@Q;5N#
zfnz0(V<1u6DAMOkgy)B2D72*T#aiZJRl%nVa`y6cQRs^p#H-H(uYM?W;4{Imv4048
z_d@!UA>+!@<JX&4a`20<u}^xxhO8I|Zy(-nN#(%-!Z}coSOD*uahc8Wjn4<4zemVm
z8Jug+q=+}qbD=>AVO(f!;3E8nF1DQPfUGc1vtzw~(3-@xY3$&CXRTpJ#s#h>O)#FL
zJE(W?s@hpsHJ^Xf_FQyPhx2%7qOToxb9Wrb{QoTu@{hi&*nqh#V$q^Knb(`fm0h;(
zMPNq8x{DG1d%91mki6lBZl~+5E57%IWB=7T&8<<F#G(&3t;?r0iyv{YN;Bu=;b)KU
zepU0=qi3Aw?q1Y)<NQ{4lCj=6%kSRpRa}SNw*J^|&e-WruiEAW<Qpx?sjas2l7ZL$
zYAbE~V!sL|=eJF}3D;?e%q;0bwBf_Kd$S7r-2SDJsG3oSU2YE#G(e@E&eGLdYb1Uq
z4%v63^Rum~GYlTqyIk`|#*Qg<=8gURLF)Qbcz->d$yK`~jelF}wMpM0wr@-3NdM?N
z@g#P=^A^&=quu7(w(@E@rS$4O<#ptFXD3ZK<#%INv&TzwH$6o=_Ji-@g*B4}&b7d~
z7C6`cF3xpX4{D!X<J#SJj19XZ9j9|>RR_JX<u<?1T9o#7`Dxp0A=ggVM|-8lIL-fg
z&b7d$9{qT<=he-AZY{$ryeQam{z=42(S7t87+1O0nL(v%3|lbeP={6J=God+yWtQN
ztZu)^u4dO0hkDrAI%2*qlRLPhSE~IK)20zN{gZDx$xE%fd*IHgaW8ak4h&Cevw9aE
z$p0x^>d9=*SjRF>P2BcuN{+G^IQi<R4U;|J$JBh{QFB!r@49+(0z5I<^RLdO{@EPq
z|26LOkM03p+JM?W$xy$14L_q7K}W}FhMPZaee^+#qmE8j!aoLYYTco2C~+N`+-4sg
zarI*<U0-^Cygt9``ZBQ^QS(o4T^M$t@tDS8&AOpe{iEEq>Fj#VtQHKfGCpX>^ov>^
zMP{cS6;uiAk^Oj6@WObf#>Wo~KKA2tYxSE`KBTGXo*&v9)sD+8yDW9b2w%~RS37Ez
zU%WEhKeG8Uvz^PauM(3x9IJj|Kr8c7o!j@_-|cMXtk>R;HcakRNwU?mpSZEV4kkEH
zWODOmcZd9EIoJQKwVLm@Ap0#mIB;Q>(VV)W>Cqx<6Q>kw!y`pYHy@ppym8#Mbp@MZ
zIc__XdpyYEjJtEhhhrDE_~$?QC2Gg*)S%e|E*;mu<!K*2+zuRonJwvhgUo|n;@%Cu
zQbQ{4`Yz~v?U<G}yAIUv{ywd*X~!|wC+*=lT_zV&WbeOWP3o$;+M~w24&Q59KOxq-
zW39D4mml*s-O>7WMa)ZQa=muxFH3BGe(;0*f}n>tbVhb97$0NO-{y9^f!X2xde64x
zxN}TyU#hIkY~$JUwABS}Huoe3JSn@@R36E-hNm~-rajnL_vO)+M(v*FdiOt3)$Fgp
z&Hi8GQv0@{@_1Kv&+Ta!4!>^kVeYi7akCpc+&SE|_T`I``Ms(yRv*zE?cYi!_uhAH
z*TS)J@rmBH4Mp3^C0XuxmLck#v@Ed8>yc50`Iv)|!sM3LtF3Nja<)U&KEhhkRxe*x
z##$%s$j(2Hn=NpzT?S^U-CddbeB!Vt;`zaEbv7K^wE$zt7(*9}mfh<pexE!4)-{bS
zQNmi%0+)J0g=*?Y?bi(6YWC15XIA80GtJAv!`~F7b6ghMEU~Dd{JFj-c8JrmI%ky<
zxYRc=*Yrm@(gOE6yxpU$99a+D1M`+eNA_Q|T&Hngf6QS94^%7)xLUdI)Tvgb0|)0w
z1@7~Ill%Nv=QImkWyQ;30R#&O77#2TSU|9VU;)7bf&~N%2o?}5AXq@KfM5Y;0pgvz
zacbK1#nsfoH;}me4k5-Jh|lls=`%(e;3M^N0HHq6Aqf8+0s~weoc#RQ#}fJfegRmm
z-A&@+8{{LC_y)=Rf@F%x0RQB<09_Pw0pf|oj(}ITV7hZ0mVe_q!n%H2`MCh@QkkR#
z3;n?y0FH6<i8rrI!w`IX3d3;_-+u^>nIO(rR-_U52Wk8f|DQPibiGn|$28W-D@cmZ
zv<5u!{^^{rmn%nl(AxZ1)0{gB-mZv~`ZzgzNhO$(;euHf5+9E7`wj6spJ(0{#M>9)
z94KcjGz2f7?4t`L8(}%oPketqAAJ6b^Zjc;j&!UEYz3?Z90&v@o~;27s*u3<&mMUC
zc&oG}$vN|LmLDt><?I%po%v|SgwVBGuQs5<$FcbXFU>k_ZR2TQZSZkDjmLFgJRP(*
z;?lX&rS^U-ut<wu(i{$aoymQFkJJi`pXFS))S&qIHep5!Q#OsNW!h@|gHZ*CC(ODw
zZO6nJ{)PQ)IL?a6HK=cVe*Bi_mIq&pjyx~F>XwOaH_o;D;fv3D4)rz~Vwulz0^dLW
z(&V)lf^x53?B1$A*L?P(saH+9V$EGP590f4X_RGr`t$MkoV^cddn{jit?-Kd$b!5>
zFXm=PU%me*Y;3gk1?f7D>&oO@PBe;d`l{3~1JzcneY>ywwo6maxjoYhDfPJ1$U~#Y
z-^N55f$uNy{e?BwYmT{c$UUm>;`fv0xo@m_Z*^utNNSPM{fc<+E2j5z4Xf1KciOn@
zn+X|~THMA(`Yx?IX%!iH&o6J#R4?L&!1ovU{{Jq%zoiHHpW4pfZ7;i+&$~OMOt^91
zv7FC!tqEFvjypZCKUZvhww1lW_ZQYq|9h;RF7W*W?=<y&v43>S{py`Y?DlP3p=Z1I
z%m4S*Iv4o<0^ffw1_%NfKY!DCjU!Xl*Dk4Sp?7)PUBh|e{yj4qH$P`^v0|l$9jA77
z#$JE|-@k77zT5t9hHX!ovu%gThwPPsk;ggC90Mg{(dYwXpB&6}o^<_2?3QMR{Z_Zm
zdm6n~S`@ZP(;=dP`3Q_#g)+Ho?^biiGh44S@;G<ebw=DP^*!O$TkIWaxYezRTJ3uJ
z4>@ixlUw!f@txCq972uiPyaY#**)jIA8!n-+fH-Ks=P7IJFll%a$GKxtDBfUzTvzS
zvvEd=ZFV_X6;|rp>{6!-3tu&}D^t%oW$rNSy}@|=%ZtL^TUpq=@pSq1;Ev6U-*=i4
zs$18x<HLK)<3|a6|IRsPcY5!P4vMxPutW6j%IFZsmg}}IY`?o-9{L{`Yy(euufg#G
z%LPm7*3NyCy!)X=V#oKT#Y0}j`W!B*_|!jlE%?lBNbX?1smaA_?JOI7EXdE^E!T~$
z?DWLxU9Uo${PAv&=EQZzxB!!zV-(%;<IH|Te7mGw{1D}Gdqa4ik0(x@tbcC)^OvnA
zZN~tf!1u3ND(lzeThialRX(#hvE7)Z8Qb!(PQjtJWM|`#v-ckf{XKe|Q;Xd_3qN)Y
zeX^m|Ft_xG3G$%$x<SjbIPM*j`}NJBm#@ci+m`EGN=k^<Exp&icj3z_Mx|eN38^md
z{omYfJ1SQ<u=|=t?F@&;{4(A#a8KMb@y>m=J2-AF*2)lz%%<O%_cZHn9qo;WG`nBE
z{Xpy7>@ymjy4p*JG_60m{K@L5A5891_mcr$mVw^yy7x#B`2NrFPC{5aJ-+<>-Ldbk
z98I2e<kg5pBTqJLRv{PT<BZ3DxkEu`yX5B$1-}1Q->gZgc*mk?LiKIck+bv4J{&#H
z;KZ&WZ7gm+bliWu(I~yX6;6~pld+W(`2L4V%MOoqcy4-U;=SI@8=Std)Gn~$>kIdL
za@<zN<2RX?m)~@J{TsvY*BvGB{o8EBx;bX#SAKU|y*O?@IpN5-hS##vv)<Ufy7(k&
zw8hSy`rV(0b`tph-(JI9;QOO-5`tg>!2*H>1Pcfj5G){AK(K&d0l@--1q2HS77#4(
zO$!kJ|0l2i55j-2%U^l@e|}#9+9SZ*8Ee^N&jIeI?FrC<tAvqtjP;e`O<o`GRq>jK
zs{qu)xU%6+ejb1uvyuc;B{0Fl$&2y-_4z35Kj`+H-%T~}?adkgzZ_?(eF{8$@ZYhv
zeHm@zU348zuW$c0ba{5J<L7f&x#+8NM9F7z%|FZGP2X4NI?y>Sr14qKgv|pW-n|hN
z!;&tzPI>JLK-w!nxgP+{6(GGcLGt&*J_|bdejhsHRUsE3l?4U(NR-nGu#baC+Xfkk
zhn=S3cV}i7e(!)R#F61#NqYyFD(ve(lL-*U;UK+eJ_7CAzH<k&ufn{}o<2?i<0L-5
zUcN44n2kxcgdpFIlcax1c~sr=prkw&Lf<w`I4;=JRjSxALE<M1U~?rpDCULaDfI1x
zbSMp|$~C}0^KD=FgF;h&uLjT=N(#&$it9?YR+dNcy&FjO5_D_;9jRPY=aST=%@hzs
zC<hcJmxnT`2ffymq}OM6Wwun+kJ=GM2qT9ie<i!rKx%(hS5+S(KU4Zcpyzm+lEQrN
zC9bVnE;S(c0_Vmz#vU2c5L9hnR}!YQY5qzm&U-t%Fu%)3S=1`Sakluq6Z02d?h)k3
z?>upkjp%5rD8H$Yr_cZgeZ-RRoEUb>R?NBK9nQlk0O#v-RVWK3g%Zn-(oy<J>9Tw@
z%xhukP<<yqkt@oBZ#F);$)8TEq<Tx~w^HPDjw1cye!7OwC!bB|M0r##e_m_$zr;M2
zlx|6WsnnyiI)BCDcHnqBFf)+EpS5*KdZ^~#Ly>MZT${?d3Jxk~u}ZpB%6~RpO5-)I
z<$;602S9h!HJaa44(A+jP(a(t?B@zh!gn`dG7$0P=Ya4{`6b{O;4`2XumI=_)WG%N
ze{#Cl1Oh3&;W+p<k#8$0J^XQfaZsp4@qlnxc_Se5EvK6T&9mwUr1?~IjXFSoApBlV
zZ7sGsVAnUsXLDv7)FphT>r-2x^o=2qqwAxt$;p;OfiNdG3`qK|p+ga$+8~NgH_#{?
z6rhuw+9ljl<W%>X0zoUHd3ADYAkvW^1{wlS1KR@c0jbK2f*tV6QXT}f07e1316KkO
zSH1_>8<+!xJ><`U{edrmHb80%2Lee?TwhVw`8I&`6yY57VqrSu$X{jvsco345>Kwk
zUoD(39&dyqo;{H2I{e_1UHLj!vR%hQ4k~cLK(cEHknD>4;U|5$KS*~n<VasR{wUor
zm3U%BJov&_`p#Fxiv&`-3xIh*a)`FbpjfocJwd0_g0x@eSK7EUdE$_+GakPgpAvVj
z;;(&{A2|Qu87|<=<fh7}R=fT>Y^<cdWcq}Rt-+-()tWLlW}U1|{o@-$Rz{#uBbi*V
zwe9jwyDCO4J3n{Ds_iYS1r+E{>nOicE#lGjlOtM;cICJuOzydFyIN<jMDJWzzTlbT
zOZAFAD|hwK>T%@GxC3#K59=Ahd0#QP*+n`bsfK$q%x2tst8;g&t4CV4W8k3Yb2Z1r
zcC_zjUKjbOP5BV^*Ae#DAwLl2+X?&YkRR-K-#Whcl!5N{CmO7sW?y^W5z}F=MlDRF
z!OK&h4|!GNG46Y~L5W4Wd&}<Jpy|B0Y4bA=3ysVMRFA1}`*eAU&I<qLtv}lA>54t^
zm|Uw?O$XY4u+lSnqbt^Zup?_~Y$eUE)3@E7n6%@}6R|MgPMB|3FzP|Lw*~gcYDj+7
z|9*|#7yI`(e>}tCL4tL=y?xpjtuR>}>UPyu^KC}b`v5!}>5|-&oX6UC?Mgit=G*<d
z=G)EoAUlst8nF3bdgZ-0&+eW3AZB?T<3aI9eyw4ds$HS{kQ1RAc+OG7!y(qEx3hcd
zVzBe|#O7x^c?6!*4?KL?Ez;9GdXdljMOnL&@etRE$;HL^t#2_s=H#%cUY5PMsbPZ>
z2HV!NexW|Jrg6hLkvlRuZXc5iKb#tJcuVyz1{QG!#*X4T?Kbbd?=AL^I`eW-le`Jd
zkgl-5j<COu-#(5Tq)+~5-N-phqm;=1d4&csp2lkma|4bJ((jqjv8?5j{YAbX{IGW?
zTbJSQzrW5XOUkeDAldoEsHP{92U;Fq*h{UeNkO!G#!DBotHYdzO;5>1{rK7Y@T_L(
zX7<i@?R2w^Sf_PS&Gun6ESG*9^Ss`?`i~AzY;WmW+T*-1e{VDw-^G4^s|{DDnH9OY
z*vgEWo?rg#1fHANzB$5vJ;HuHRDXs2dW89V<OladoW>gT8Mw}4)vV>?X6a1wXlEOk
zZ5A<U$iRS|i;the0AO-!lFM;$xUFaIcQft4sf86Ur7rokvsS~Rf>U}{M?3bic{~*Z
zbNNherO)BX`x08`JQ-t_;~U!KS(ICNT|K7)f4}j^?nZg3W8h8LuSeLgN0`6&*r@PP
z*}mt_Ju&T-urgKjW{}3dUnl7=#lW&jd#Z2s1N+u%(m1E~h9Tp92Dpx&F<0KN#fLY~
zO(RaVscl(r)hoPzV{-YrvL@@w2=n&_y!$1+mccZP`CK<5`<=>Kp||wV_HvO^pK6O=
z4|R+UI=Oh<Qp36f)F!9&jhsIO@0>c2oX5qfbGhy9^jq(i&ZrdT_Igj2<GJxoZb<cP
zViWsy|0m7g8;vmzvFMTO$Op%M?dZOs^Dy_2M*H{Wx*JX_Xpm$od%x?^rsVdE@XiJ=
zIPiS%s#cNQ^~Oj0-iIso@I5hSX}~WoO9yrdcd<K~u_RW%5L^Hzr&}*N;PBRJ{k>K+
zJ15NZQ}^MxOU7isr|EB&yQ$B8vbDqI#m{@sF+AyZuvNnucM{h-3-kQmm<`uF(r;wV
zXO)U(_v%rvYt!T++2o>o*>UmJr{F~wo4<FW|J?V!WhUPe=K0B{Jh`Zk7pKqh;#Vy4
zoxACV$JzlsCxw?Uqj|B;s~!g?Ha5=gH&?xW@9CD3f5$w(wyfX1VsV`1Rg)+;?YC-e
zjmw?MfACxA@h-L6joiO0q}RC~K?&Fw*o^dh89!+2ks*~wtXolMjOLV5p((ki7QZ&F
z)o`(sdC~Kk8*tCs!sK#(&#U=c`t93A1H(F<v)9Xga3i9#`HVYfYt-F6xkXB~SsW+q
z|FcW;&4&$VFP_=4@QP{Qx8>$#6=<Pu2tlxbU;)7bf&~N%2p0HzSfDi29Qsq&|0jwl
zPyhcXulKLy`BxwkAi{`JjC;sg0}ass%-;Q(*X>e_H*L*FVgD=Re`GP9e>`}|#K|L`
zf8#w$o`2gm6oJm^eLjZ~h2rPhm?+QH`YcEEMHW}(97Y+6pKF62;%6Q_t@-c5WIl7t
z|A_0KqTo-L#Pv5;1E&+V!Eh{BC4uD$9MjL-?&4g3njb)MG+<wIV1gnJ@prEw9pZjV
z2Fn7ZPTq{;P4f(7xV9VmxfFL9(khL(?Gg7EmGo#11<4gpkNCNCD0$c$6y-_=!7F+W
z-2+Y^<@%D%olui7FIP@1z;8dwhgRD3U*+rjQH4dAi-Yt6&y;Hdy==blH=ZA^;&x0w
z^0gAe7kup>)sL>FoaaI12(x}PCw~DsS~<&u$|@h{ReAbkV<o5lnj$Ztj&j6Bt&4;9
zv4~W)F;A&y`s3%4LW%mTrZa>tj!+W^eXNdy%F<9_GitDuMfsz=Zl#^R$0yHHq+Q&P
zZ1_AfH-b8U+J8z)w<JEjfr8g>qu})yx4}+c4>G}@wsA>1klmFW{zOHZ#NQ?}Xyc&r
zP5+!GE8Rb9b4r6a*?u_qc9w5{iCbMB=Uj16z-u4o8-~FB_}&(H6o|SkPX(g!lxG0p
z3i7IGFVJwx4S?v%%8h}YfjxlcKx)@5fRrwk<x7?a{xhXZt_&_Z3u4Go-E0V~0@MXk
z`_TwU@f~sS^_8#36kikPhTx!3Q4wDY2y-!RKJvo2`OpdN8_&rHZ9_f^--(+q2crJS
zsXYMy{1XQ}QlTf+F-nJ;H9Z^@hCz<XWjK)Po}EfOzHab!rg*$2ig?7uXLU&tkL+Ue
z2X?W79NDEOknCa&B)jxd#78-CI~DQCPm8BJ0CJ?S4Up0us1h$-5s!SWcsz+Bo+FTa
z&<U6aoB=}#oONN3n8Uwv+;6B%Vo?PRtFDJeG>V_rYMAHh)`mB$o$H*qK~r?UaFdC_
zu&9>XIj%7(+mFZvp+bp8{;oBbT;E^0t9#<a3r#au-t5?+l9TiAb6n0Zn%?EWmdVZ>
zw}Htm+LL*`X<XT5>s|zAWURXw;lHQ*qzcI!Zs>Np-n!y@UsRH4mhSA13r{&$f7hYg
z2km~s9x)9T;dv5uSS-?7Yb1Uq4%v63^Rum~GYlTqyDV_l$u0tCeNOH8@d>u!ac#PU
z?OK$My~xC5mjc<iNX@!)eEMHYJfEm_q5rmwpq|w`sP|YMed}Fa*JmGbPh@h>FYga5
z*k$qZLRQy9uOFv*pL#b*Kea}~RhgRk2Zk4Jxx#TVOm6r>yNX9Pc}EJIb%C>9E64Ca
z`RpEfy?Yu>Tdnc#a_=OEX5oIp8dVBE%F*w{L!el6IbcC`+lQ_-pUC#AXU2_r@z6YG
z(wOP5j)k84cX8HFdQiH4&(dx$u95t!%kN7sx7}aXrs-LuE=JbNrFJc?Mj36~j)|yh
zcsLX|>lPE5MO2Rtc-?1lpSv@6OYpF`rZL&Ys;_kq%c0piuJeNLWxNSK9ebD?oIJk9
z!GH|isVjR2`l3(F<TMViYUc3x<MlJOY^$tGsFmo~bZ5h1i3=-R8ooHyuwY#$Jj>%D
zS}fvD$@Yh>)oXSC>9P6(XZ?SXv;L#pm!Hj9&(kOWJN96K`vaeeYaU*I>(FQMw2<3Y
z7OS^puGN~}HFo{{um%C>!!{$i275M4b4{teAj&^<!MX^oC9*T7I#W7d_chAf^wG_*
z?IeyH%;at+=5I)hOQ<;Dm7R&jn}y>Xy~gg%9R9SgVeZMSHT7cDG0&LE#hbN`sgkp)
z{HDwl*9Tm|gbE#NA9}mDlIHXdGXm-yNJHJ&#^lcG%#yCRSQ2TdcRp!no0iYs9x<xy
zP&v%F@U35fwNcME9GAi5>Tg<i&%pQfvTfr^J5@MYS^vzYT>&O5hOOFEu1du^I=Sd<
z3VX>2d&vlU$!M!5L|WY%a4&rG?%<bAKFqrBvozK}V(n&(CAXq_{$Nbti><piC)hdH
zUm7p$B@>DMB?jIEF1oOnjA2{ygHTzO+cvHDJ~64V<m&1CGV9i9JFZ-uRFo(yWBzVt
zW=a~yc9~q}({z`YdYv!m=C+Hh;dEhp&B1ot4ywge43q3H_3&-Y`xy6Sas{T_U$pHr
zl1nQ$`i`)d%;R9Zd&F3mSQOQ=y!`3JT0R07-7I%&zRn1an}C-UVv%_DxT1pzn*K5^
zyWQ7YdQJO3_PzwJrmk&&6DmV0A(@V3%G4l|Xh1?yiBL42C=I7NQE51p3=w4($rK?|
zW(tuxiOfQ#N{A@(l>D!?&N&I;JkR6%z5nn1_Ws$f_C9N`;a>Av*L|-i!Ey;XJxkW5
zb@KC0SL?cqVRln@?(#3*TG%e|)bU*HIj!BYwPAZ5IEv4lHCZmYT=~@(p3b9;O5#`X
z*D3jME4UtyUQa0>blNQXKC#-xa?D$F?BXvU^y+o52Tv4Jj#hk1N*XvD>s;8};Yb})
zO*KnTHs0vxHt+qSgqIdGpR2r8c9t>T*zH7mTmzP4KDKzranpecp3Op|ea4wth9oS$
zt8UUDED3g}u&KzA(z4kV&2r33)SZf^8rcurhE2%~tc7r-3_6CE{B@nTbl%7d@#>uA
zS!dqQ@3HSr#;On5|7ngn%N=(Om>*_zHs}5>`Km6`!-vc+HkQRY<~?jgV>}eDdtgZY
zd20Eel?FXoXZX-|g2m?i3cm@i>a*_eQl5r+x9kw&ZgjIj8M?(gV=g{0Jjrs$8TMi&
zz)FCX04o7j0;~jB3H%2o&;Vgi{mTD$)X=oEpXKd4!%oM}&u%2KPVdQeadYHz?Pfaj
zy}dpB>^$6@oIUw{yd3#%Gr2rpZ+Cl5&4Ic){WW#8HSN5e++FMfbo<-+dw96G%@m#j
zK=c3z@32u#I_1DowDPadn7cXqdi#01@;TkDdT`7g@x(Fm^W%Ctd2oHH>wC;#1;%-n
z3*(|^_ig0-e4T6J1Y7?2+mG+)%lGHmIr+PJAQql{QC#h3z{Wn;LtBgC25{^4NSHKn
z5{GeTYWA~(@p!ucZ7rG{Pmez2TZCEn_u?<VjR=Y2bgl=F>ucwx{Z%NAex5XKVxDXj
zIO^oW7CpTPHo{tjp^(3C?<f=|c<v1qoP_Vph%x|q=82xQMbGO+&savIzbA^Gu`EQN
zH;bOJ{7Cuk?|=aaUldkN90-@yLliIkEx;q?(~?&jcm^Gou>z7j9S4*FS_45LpthdD
zU8T036@i3jsstoFQ=->Ec&5rgENfBTsVxvwL2CP$1Dt|qaApaQSD*&u0<m35ZDEsm
zO~W(dKy6`@bhzW0q?g#lCQ1z+K*B|Zl!?kV;|0_QVtZbI=?LKs3k-pQz+u23pa~Gm
z9D-56V4xW=1ULp53bX*u1tN_^he0p_I3I{KQCrV;z-T;A1ug=DbIL3RIs%sfoq?-?
zNE5RLh%_;4fn`8b-1XhS^Q|Xm7+?RqPU3<#A%8`MB|boc-hv1#U(ZCf{iM)-p$AV&
zxrR2{#s7qFsC)k{nFCI#IbAf3`xx9L%>#mCFIEDq1Xu~M5@033N`RFBD*;vltOQsI
z{7eE3@WcPm{NI=B$<F`3pZ^n~{A~X3FUll>Wd6TbI9I3he|$&h@7F~0ck%rHk?2`G
z|8IPV>eic)`7l`@P!v6j=l`8V&t%>#)}s|*QZEXNo})*i(Hl4aC-Z;IiK!muSRg39
zR3B3oNc1tA0m-@m(X%A$0xf`;GgE!d@xV5C#@t!Z7D(0w+5<6%re`}%0(Qc)0}yHw
zR8O-T5NdLQo<Pi@1)$^6^#GE7S3Hw+ll1_SzUjaLKunDV1A$~+U=Wb33k(MGfd)Xx
zS1=Sf6G-O&vw&m{9snfs|3Dy_|Azy~ygvenG%=Atq=lISB=i0#Al5MGdH|XCll1_^
zm7a-&xG_udj5sjMfLN0tXIcrc7Qw6l`T*AheSsT*Wk3>#NII|I^xV|H-sh@0o5l?M
za@Xnh2X-9*qG2yq0;~jB39u4iCBRC6l>jRNRsyU9{-p%S{NL&8{=c^$*}^AV-mbn}
zJ5M(+;nukw_O<=&{K@V%+0%C9@yMUz!|Ul*J3b?y(0%S%ZeI30Zx1(TH?E&>2>>>g
z^cCtkFpM-#8CPMR@nmZ7TMocj9^cK=Ey&Gl8fU1tC(n)W02CQD1$+CM&i0OczOS2;
zKcDLd8%Syj!mah%ZwbdhO~H}xfiTE7h$RkW2YbQZ)6vUu8rPHSg-IZB<A-z58v||J
zyj;9z`C+cCreNaj@8tqogEuB=#Ep^h$X~jVLuzVYzk6=Pm??xSlYQalWO~dzt1tXI
z0U(2W4Q?|`U@Z<)+kw-#e0yg{=jmJ*`x=1;>O0umgC@bZC%-yzr$N&E>9B(50%LD(
ze4*3>yXomUXyLz~{caE121p5fWX}+UN$hW7xuLF$+Rq}k>PY<3FzI&Tx`K|tpWx`>
zPqwfj=cWpZz)aY&kz$0hrje$<3C~_9-=WBm6WKj1NU^{KoA^o2aOYrwK$J-OG4Yew
zlOt!x_k%2GF$xq0N9_8MHHm!4jjSI`q;eAaMeNMg<ri7wAoog<%pFL9$5mVAV-ODK
zh=ekC;m+iG5a~hSuHL?$w7h&L_g}gBhqBN7h3qf<LiXgle<FMRI%Ho2x!Xa0ME2dO
zyd;x-v`F?j4XNnAk-Y`Nkv}S->`@I+S<yDw)3WrP)a(BBAIdxH7xK>fg}ljk|3u!Q
zT0fR`7sxsbG9&U<rZSRD-a#UHCpQwxTOUCF)Wtmt^3JDgfb~cV@{@)I?SnJd&(EIg
z<?@}7fBfZJ0h6{wRK<jWfBpZPw&Xya@)g#5^4s?^Bz0I^j`*Txm$X@=NXg;WMY;@y
z?dBhDA@%gcaiMLlutEBTtwhc@=}iAgT9%6P$doj!xN4`xkkkobdsI6uziL&)E&i|E
z)XJ!Tm!`8nNmHmOO)_LL_`5V|AWb>Ka#uS|KNcr(N`Cz1kH!DsPvSpU+)mXIe-p%?
z5w=sc<6n21BThrzzy7gwT=_{l#C=_IW10=L{UG(E4ekL*2j_pfo(SuRJ>Of@c-Zp;
zd0gQ*Ll~p)|K|u&@k%_-ApN+w&WXnhr2elL<<I;k!tY7DC{C9F()ISobp5J6h;!*z
zZtBjf|Dp7W+c)c`!t`ONNYmE}*ca*B`#({C{$*Nz)>ez#x9(&^2p1V=l0Jy=F^3~9
zr+#eT>aH!~T&nxmznwpI_f3+OzfmGvx^G2kQb1Zr`D>0_2Whep=8pse^k3Blq0QO}
zjEsUF{FJ~mJw1DS4=ssC`@%iHF`{&2l8zHs?Q{%An7kj-@vAEG`?O3&T8zI<%db2X
zr{`C0YUR5yO(vo=1(VG9E=@fVw#E->`muu{-~G-O@hGH4>)W*a=#e-DKmPJVyv1dT
z*v=+b?YtO@aAJRmcik0%eEYk&TOsa5zr9wOs@pSh{OkVphcvuH*a5hO^H$;9>J-K`
zq!}aop5*F?Jx(&z!TzqG0}%VWbdR?yum_&ifn<-i7jPsH`@D3I6<r+VN@I8|z&<Xu
z-MkWrWC+N78Dm;%>zITuoWuR+!WYhC{xjj5BK^W~J;RXkK9N6ZZ^_@}Lh%xiXOu4i
z$(NQu4zM*4GDqJl<jkW_t+5>~98U|!ro=xfxKqPTE-aA<NZaQPB+Uq~)_20OYu(?)
zh`w7a`ff?B?{a8aulu{PqVFt3-&xlBPB<>B`@8+3?+%E*J1F{&$V)g563(x_mzR_1
zJ7*vnZeaLAZC1MimGJBaB;zT<Eg<Ee_$M5H)a@VP5)gSs0EvHdfQrB<An|WLkoXr3
z6#KVVBo8tU_&$C^;g0w>3`qPl0X7GY0FpLj6p)M?%z(r{$W7Ge3j1Q>ADKqsdwOkv
zJ5oM20y)4fz;3{8z&^koKpo(2AnC*R0*SvGxGhBSB;kHvPA0(}iKics#1G4FHQ(`m
z@g3?j{cfq~yJfY$)A+@ADDU(;YteV(Yke2{i|<y6zB?lN?kKPf@ikOKTLocrq^!>w
z&TZB~>-D?wkym(S!K>pJG&%BUMnPF?rMP>xJoT<vkD~5&?!GcRRc+4PF>x&qG);OF
z%KLoUdq6~t^?ptD<hPIdAT#Gvchx*wlZpf9&MA3#{G}fj6KS+^aDK#HDUXo2(YrQ2
zw2H+!8U0DPzdr}m6p7|Y4VOMSazldwP4in%%Sz0xipqZ4H}J~**u5S%cg8e4It=-J
zn1;JnV}fVive&Hwo*!$gFxP#3+sn_N%eLaR9HMk-$nsv@FQI&NA^ru<Q0*#M6)U}9
z&e1m3y~7t38pU2$Xrhp~?DV!X^LtKt4!#f4%#l*QWYwURO<ZJJ|8<QQkDsJ;-_C!Q
zwC%D<tqsnl4WBgLLGp9;h7KhD$vpTH^-56Mv*q*w$Fs+-TrQ~I@Kjyq-oxMw_w36u
zORvGcI}P_;e%zdPL#q2KhZRa~D0j*#u)Y*gu&7`E)qB0pg{|EHzjmTSfvw+wkX+A?
zT`VmQHW*O1Erb8md48lKaio5Ko}{F<77A$oMz$Wm;J#(1zv_eRS(iF(Yd6o;SoKlX
z69*Yz|EckZH$pCw+Ps(4W=T6VA{;40o@<L`WibQh%T8LtHFB3ezfQX6^{smgI}f$8
z9%vqV8DklgeU8*D)A4Ht?Q6Dt_0^d8b-Q~j`BrwHJ3w$tDXQq+`N_T9T^MFG^^Y4h
z*4)RZ{nmC*7kHjjnP`&hYkKe1x;tG9{a&6}zLA_Q;Y9tLBbcLf?_Kyz`wsT=X6L5N
zs((W{GA3~ozhQ^7TLaccr87(lmGi*GWfk3mI^3W5tliWI?V`Lw{&3Y}i&rPaj#;)w
zrHh#l$`y6zdt2UY&K#2le&Y(cNk)$aJ%`Jm-!?L;@a`&&24xO?Q=lJ4<2O=vY>xef
zeXDhh58P-a?Yj6@b@9gL?dF%;G;h=Nc1Gd~hA|&R()*%)NQt@Xr8$c=<+q%**LoZm
zbAdZz+0X^<ui_7lE3uTvvI6yQ=%%aB^EN#&cOO}`HK5@9+wKNF(np63e5tkgI@2+y
zuP5S1-3{E;FE89YwtbJ#78*wf*rcVkDV7@9!e(un_S4C|o;@)^o85+l`&NHYil&>b
z(zvr~GB4V_d1-Yh>c*7@^$&fiG|Em`*|Rs+^Hqqu3VDa?q3zc?xMsZ_`KecvPxbGH
z-7$AMQ57tun&AAL*v7v{{ad{I<MB38<#UQOter;=?N>E^$4$@G&)55zbQ9aC`qMV*
zCAG;vWH?Dj>s3a#t@Y#!#>;A7v7DTt)UmC5Z{Gp^1JhbNhkiP~@g~-v+7Wk$b}PEr
zJTm>Fy=dk<$5O3A-wK_Tg>CBXy`k=LRB7#abeR6sKNr=<o$_xKKEAeaSDZ}WJEwOX
zJbY$PU#T~Jh92GDiaX*C!@NWX$&uP?)!;+8dHdPH+j<;mZ?rV$*(}vkr&IfKRX;61
zxzb{fGx~-0#GTR&Zt{ov?*^J#kN*&+xN1U`m2KBu>onHnez-gIQl$kt<DE3zJ99eb
zUu)P*<-`ipj@sjQH|9k*vOajdeAKlaz6wS`qdqds5$fMnBW~5Hp)uq8c=V2Ju>N2Z
z6+zkM(AgJw_oI8fSoLcAONObU>E-QG=*kST=IbB1mY`7(b11KB^rMrVrId8~?{h6U
zMr`Omq~RtWOk01yvsFv&_`bmwsjIxpZw%eExTImA;xP5{(#T8<GW>K&I;tYKhdkK0
z{b^)S<70K(ifV;2h<0~oY5#N6qAzcqGs9*`*Nb+x<tOAfgfD&DrOTI*mR!GmlG}!n
z^xWc!91`yDZMO3;8R1BU%Tyc4u5qY0w*R%%d&ZL^BVODY_^{usmyJrpyT><*y1+0e
zX!}y)t*w0dR>Iy*O)6hIyp?X|wRYcdx#1@s2OirNThLwy?M5kexA3z{K$ga#T>be^
zKd3xOahaZ-@8D-u5+ge!X@IS{A@X7@m5WWVQR7+n$6hta;f<G@656|9o7SODX?9~@
ze@fYqd|2l!#)#D2j(&mtY)42xa&EfA`PoZu(K(gz8*O@7)_a_MaKO6*#|kk9qwXdS
z;^ZY%YgFrB(;A$$-Q#0w;@N~RD!b3GKf3==H<NRx8RjAetEeC9avGQ3>}ny~|8=Kb
zPiM$ZGkIX;)35iN!pawge%n76Vca@`xO<wiaL3|H%X0fR*7q`hto||f{ZfxB+N(GB
z32kuNW~)^>#+1~Z{f#XK6RzzFx+uTG;zRRmYVXpA3{JT@{cW+?<2AD`*>;CMEp^vy
zxeIfpbDn%hyH1e>Ck#%HADni7;{pEBi-YxdG;6tiGs9$eBH<SH-{MmhT2XyEJ8x;{
ztdhwGK2EM~VdA!b&nU4?`5n~1cf8(D?hfsFC;gqtr>RQwN|Ym3w;#LWdX&`e>Q{Y_
zr*vhQ`_x^8ccm9I_h6>ih3A~$oa#HR4o|Xozq{F6bA;XHB_*p-=Cx?M7Jcsaj$_rf
zdQ&I9-^}whynE<g%ogc@v^bkfi#A-9$!LIitSO1#nbTD}q<x1-m(_10FT3oa=P=E8
z_a+=r&n-$TX&&A2Qy}=p)V~m)!}*pM&-Te)nNe8x*($Fvpyo)mJCGC9X>q20pw0o!
zeU2to%?J0mG3eUT(jJo<ws*>mu>o(o8*vxW=V3yD`)pnPoRsVa*{$onGJTfN!|G_H
zYJz67@Xk^gR1c!@J2vRO>dN6amaK@hv^%^gCv}P2rNzpQi!F8!+Y->%@ns_RXf=s{
ztJ=4bHW_%ie~Zxvq-S348y-CFa?TX~LMxLcHf^+yXJPVfg}mcPnRa%{lc_J|Q_{3!
zqMPo9s#m_Jth$fbKcJCu@zKxT)jYH>G~dQNYn6I^%<!vcbM2n*H`P8gy5Hycfh&St
zZ;zM#kbC5lFXTu28K-vjt&)>9!*!NsZl9{G*C*)t)XMbP(Rb$V37PLxWp05v40YGB
zgYMO!oh8P{-$|V)X|nF&K-Hm)%dqt8uSZPq)Uh_Mz#M|6cgX|i8214q7q{JNVe<Ur
zf}3}jkKwnBU9haZ&ZG&e?1xt}%pU4)ZSSkc)jmZFhM)D+&<a#qVU^SQ`q)dYmmE@i
zY&qO0d;`ODQzhvwE_|WzWK#VSl@D{0Cuw#`GL`et(<rG->^)Mphr+)3vl!+%^{-WR
z$FRyX>Dpr~HZ;x5<vPWCnKKR}GwP==yrJKyO$_R!DrCr!N?l=5G*Q-R@e@}w%f@56
zt#{H+U+J78|EW{Ukh7y#Et@2{O+86%kTs(1{ng~BPM*gUrmtCbr|OpNl*+QSH!=AM
zx1SY-&rC4A#@&Rt(Q!%3nV%2HrFMB#-fzMEzBl_Aoj<NtTF~j)cDr6-qkLN}UnjY(
z?nTtUQZvtW^9%S@W{&duT4#CIhZR#(w#C)9^(LuJ?+ohS?`^_KYWrJDo#e+3FBMM9
z)0qZuJ-^&r(qePNB$?$)E~YFEKh|YNm+&4#Q9tUb5qBArCcSi4-}^44=jB1u{jPNP
zOTXzF>t>j+%<I##ynPumSZC8G?s$*;yg6$aw*N$6r#pE$dF7KzuNN<OH`=?m`>>MW
zLB1_9FQ(<7LBahEZ?3Ow|9<vH<-+2(?GoQBZShiVIi+}8FSSw6o@`^7JQ}XQOUZ{R
zUu532u-6!;R2aYE^8Dz)?M#TZe`n*1AyYRPp<lql8JXuL<!6?)Z<E}t<<Lk2m4w)C
zv(L;N*0x)~oZ}4!JsF*ZdQRQ_xwBt_X?u0&<9g=o-M*W2reC?}GJjjC^udUhy$(&$
zNOA32uTA^z1q^eA_N$9BlwPf|eHlGvZ1XX$J+$U-j&kKyBu33&*Ef7kg;X}m)p4}Z
z9I3>#TO~2B*>3~^rL7KSZuFm-bb6cAmf0VQ5*toiHCYgib@eX9oo1fTmu(6DLxOd7
z_T75geU(#~<;BpE53XHgnphm$x)1rWo`##xoGvWsv8>ITj?;&qbIkrUHeBgm(ajAf
zdZ{ORIKCK~gK?}5@$W)jyxOX?-Hl`Cyj0-4o8XY-e||;aDvfqy>xE^S#V*0Z!Jj_s
zVIXZMpI6j>*L};gJ@-;&mYcuOAFcO1$LeLrZM~N`+>`En_Vpcx`O`M}BWeGkVJ)|R
z%8tPENtahQT(0rRRBrCUk%w2;AJIJ~d6Pip0mhQ81`xR<HT#`y)QG{vomE1%Pv*+o
zv*kxe&GX>ixmD0U=ymV)qg^uUDaC!B;EnmrYFh5c4Ar!%-^SS8y3KU0h||vp$`yUM
zA6!~C^i;p1rANZgA>SI%dTBp_S0TgGdE<X7P&UHwW#3cJd!2G{ycO|f*7m;rwSree
zzlOT&VG=h{G01<<yz6q)KkHv8s#NqFp8sO|tfk40UCtgGhjC6GO-E&uD`w~RaI*6T
z=haVtaQlVb!>JGL>_)xW#^I@}`;QNT{Sn&UM`g8m&Fj9h$?Z?Uai12hjIcE+JCdgB
z{<^Qa``WA%hLO-i(jw{oy)EaD)ZLkKtGDlFGP~BO+&Hp7LAAjl+fh|-6?GcC9TL#e
z<n3F?<tbgy8S#FVx}w6<q!g`vOLnV7nD3pJ7jo9=n$?S}oojo9?S2d0D{T_4-X(p_
z#Cp4wk}}4;j(NYQ>2CkUW6G)$ug<*Hx{r$7Um*;0oyxh>#?6QJH7RH^B6wxhu+wrS
zGB=KCc~2O6BU2~5y`I)^bLbs)CjOmwKa%9EqBUgizJ!v|_pY7&IAx!H@3MH+xLK~%
zcWe#NzDRl|N#jw(zcuk)g7<Z9?ych(rckKiwr1+G*{55d+Zbfa@mLvAYHEcwQR>dy
z>(kuwvQMWpI@Yrt>pQxF?~!mhZ139s-IEPYEQt?SWSD)loKDHV7kf!y*W*an{y7=V
z)I;SH!me%WIw}0}p<N0`vR|Ohm`(kgcrImIen}Heg=*)afqfJE|0Sd16*g>Rw+YU}
zjAa7GVSIX+x_hw6^Qz;`&S8W4*zMPflv~q+`%&e<=88>|lA=6L8$FOhKaDvsM=Id6
zt<RPXS?k&<Or7yA;*eg4{Yj<+lsAr8bJ|mHPv3XV&|Y;X?qX)PurI4;c<$CH*=v4}
zyLrDk>fZaP^q|S9-d&oG(EhZBVG3xtj<dYp>+bI>eM!Ul*npe8XLj4sxT00p?1Fpp
z)85~i;()ff{b=If!41c<pQnzCm)-KdPtS=L=9s7+Tkm<}@w?kMd1o#ksfT|03XR|4
zEPlg<x(gTo+;;yM>ff*nUhxlocF(CEnEBN4sQtVVA3q&8O&-2y$${QBi#`NQhCLhV
zPWOEKEoU#KSv@k?5K}a9=oH(7JD<H=CX*yn@m}FlJ2J-EL*3oAUDUgaL%+Y49V>n4
zt@U!qhHmFi`SkIbwqt}>+nlhn9t`t{x>M4L4m{DvY5T+on*@U_7wbGH<(rX(hgRsT
zSq{@&{u1*e3)&wIdVkqEa_ETY^g)H)rsNly9eV6Ie2d2T<@ysfpX}e^J{RX+V(!h6
z(l2Y;&OCPGxE6VLKl%D^I1w;o?VSxtnGG9P+>L9Yzup<`2A$`<?w-7zTQ;?_b-x}D
zj%<z`lz;sDv%d1EyH1Mj4`0-6R6aY`SdQ7cth;mHL2{pUJeM?4@1_=YKN|h-U>a`w
zmeu813#~Mhb#|<hI_tZj%fJ>*hiK;?cbq)`{JS-4*J7=ox*K{vrf<fP#p~y)y~)uF
zGwfP%wrO^&3AeMN0vdlZa95UQn0V^W{?xhl)lFPpr{_(-K5}hgu9b!N(kA7O<=JiT
zZA+P}SBiG1FG+8P^2D63%-rW&+r2&2TSxolE6*|KTIegU3|Y9SIzqE77VRH(_bkA1
zrut~hP1Dy!uL+D+37xJz-Y;K2D%9H2ckha`7myzr)Lo&S-6J(a-h=F87nU}=k+t&7
zV7X48D=(;-oEk9F;>DbK3{yeft@TO|JG{SdVet(8Lhs<Nua~<<v{Q4e^x*}aezM#{
z+Kyq8Xup+Gab~<1U+=}p*Aq(i7*9-%xSFh$d$hmCw0)B{+w8j*kNoIG($W6Km5%TC
zJ<Hx6%(V|macJ#!tth13vi+8&o(7h$TDlcsU8*N>*TiHGcTsVE*3A#&7Q3dj4C{Tu
zd7yN_<>lK`lm~LBTOVMUb+mn!KC7T}uPEIq)|xr+@!HVoFLMvJ%^818XLRN)>#7|&
z7(ZX2?xL^epWm!!KKV%(1D|Q1ddm666wj^DT9EzXW@M&qYg;d@qtkiM@d~|x*Y9W>
zcl=UWk)JA1O_FykcKkT9%Az93wP?{c^ljzTzYjS}=LjNH6Q*%0O(yECu${D!U#2>0
z>=x|_pZQT;Zz2uqv^^b`-uB?H&-#+|ObtoT1T&!NSfrEC`^y4zYwsc1*Q=L1KiU#8
z`pdZs=Q~_kQu4M>=x*d$7LA`}$epwSinmt9U&?xUBzw<+LA`8SH~wqzgTXOfI?T?T
zW{7zs9d~X^<ZbRXFY&z191rlF=Y(7BA2+_e=^N<@t#vysirsS;?J0E^k)9QhzO&^J
zb)#+Sx(=MS+B*(C^W^v}zw~xl*Rt6?mN3j^TJFEB`;hQF@Q`KC@_8+?XRF$rSyW&Z
zDwmab^j(qZ@q4EYP><-iu4rMmR!WZ!ToPR6`3HS5w*B$UEgAG(Sg#v$v7LMKoqUzJ
zuA#b9?;BT_jB49PtGKU~w6dJP%&Ab=<)Y)s<9kMC*+%Mhi?SG#@xW0~f76p=k1qti
zQF&k)k*T?UUl{g`sedCHENe7;(goMuC)VjTiYs0**|sqE#DcVxlVO5>6@B6+U{8zo
z=f6Mep(E|LQk!IS_EC_Hmg9viJMPIWP?$UW?tpb|X2m}3d}lx)In&COh8tNi&vNVP
z)nN*sW-pBz?fz`joZgWRW6mzto%g7(l+69+46}*4n_^xNw*Tr@`K#-PSXA}wKRn+?
zZb5_YcbWR9s!esS546Dg2CYX^9CHr&jd>f{OQVq~Q<T%zK=FEl+J$}T()(XMJ*>V=
zL-I2wI?(=YokQA<d2`;p$bOk)!_6Gu{o$sYD&_$Xc)N0TKW7@WyofzP_=)xGIZqme
ze;!<@|9I5i1pfrvv3sOG-f|Cc=)EarX}?r+Y?|fLblm>fw%?@VxqiOuN-Uli91CeO
zyX2$S^U#P`w=>*k^<SbtYCeYer}{iu?#0=p(dAJOZQ8V%nm(@IsJO8^WZ%rae1uc#
zG6(H}33XQ;>?{?Qa{2n@)5V?_!?%QAj~$&6{m>#TvC|q8w{D?RB|nQ%(lZi5Xt-YL
zo9(RSGX2dLw{V@&q;-Y<K7Qt-T(eKoT<*utj^$4!Kl@6H$}j)Zdi$YmjGenYI62C5
zOy?epU$2#E^k(F1j}^NTUKKWrfZaOkuK(u-#|G@UYG`((&zGZ{=k_~Te~q_ve7#P)
zi!I~I%hW0v<^YXf+OV$rrG`D;PBzGIyUWq9sHt?&iaBf6oHSY{x5=PA?=1MS{fM0Z
z+?g7Zo<+8ihO0mC{^FN;PuePMO_LpV^U-s;D+@2l3^K6gT6gOZ*5o|q$$E7D)~8Q5
zOWSG_HJx%*j_UJ0d2^DQ%Noqv^(5rTo=e4?UZ_W<G`-WR+iyM9S<n5QrO(8EeVq<f
zZJKXd*3xFb)63Fpd)1}UzbVpr-s-0VIG<iEd3Z-==kij8Bid7%Z2GKflC*25-p*e6
z<E7B9^`_&4-=764>De2NXnz?Rr>AXLvP^r@w)I!fCi`9JU%56aVSJa5A*OfMU*A-T
z@ykIv50Dxk^hN4c$DL_gE+p+%+y2JUtkWm2s8Q4O=H?Fd)Qda>jy<jC+^ih8>V7(H
zw!Lb!y6!W)KGJ@{<md#QkEQ(2o&z;!_$Hdj9j?DOz3I-;Oq<UaWGyr^X2aeB^)Ee1
z`r6n&hV=*cGdnu;^4;ino<&>21~s=&aWm(1@lnCJ#F+Ny4I1j~i+AWc#=c-x$KZYX
zC)G~0-dVCE`bwu~W2b~vle4r!sDDfNPplU>EZ;nTjGO;wwf!S?O)L$$Wg%T%AC0?G
zJp4#8_L*pVs{3W((G$UcB?LP5N*z)4Wk7K8mOeJFIZ?9({>kn9SLb1Wfrh*Ns?3Qw
z(i>OG8>!vg^+aPaXUvG)E<LZPUvJjD(||dHoxnk$?p|0KU7F?;Rek!}PM?b6lgsx!
z%JN@0_Qu)n58Z4dCQgF<I*lde{;<>txy-&>TDS0=moweCchaHDAGi1RS??5b?&YMl
zp_4FPGwV&<jojCL^?{yO$33s8^e?!tGR2@WC~@Ezi$~g)`4Q%$78+w;h|Vun+b8&@
zrznl_i0^SFxyh2$q>r~wWkjDSoxE(y`A$8WzQTByhFgF2^}H)tI~Pj-rR96t#&YwM
z$k9b*)+29?=Ovd!_kD?Zs9_%xuKTf>#m8Sch2FcLw6lkX`TD+PFB3L$KZkFZwTtR#
zIJq9?Q8e78rOKZLF89CKj!JJn-22?3RlX;kS6L2;aGrE3cV$xdD#_2LK19P^_wmK!
ziwEt3bvn%ZGI{k=r$b-vTej1d-MOx8hST1A*+{RvE{R{4YwHr%EREACEZx6oR_oRG
z%j)e8Wh`P6^=$gxTcxuVa^6Pcce8)x;7J)Jo#L7*NuRRaFfK*EK&LP|_KCji%~=!6
zD|2Ailg?}BWjHrJ8It)rFyLM0{gg804{4vwj+#7~b=lWqR+AeDmhq+a=;4#FZi+_>
zdu@w0H0|d%PU_l>`<*WA(0h=w?fxZI*WnoNcI->yx8`&BCle!!ayREQ$M@`5@o7+G
zuxdNw0R>OjBu{0E69<BCO4ITCea=lZemOq!g&$YPmwYU_9b!Lm?2v-y@3JSRsSGgZ
zwNz0)u+;_Y476P<8g|~-!`RRB<FMiToh|d~Jz1Mo5@J)#Su*Q`%9hjn;uz)*^)FIc
z+I3dtrkT%{zdjScBco&b+H>tT<<2;?FfZ%6!z*&;ks)obe!ssOPRrGqotLYp4Z5)B
zk+k>Q4u&RDy_a5yNIk^AwWdjua<N7T@<SGB=18qOad~m00{1}mbNj3{jUE&@96j54
zs+w8TbB!<MrZD%>4z<)H?pE}^++qHQZstEfyCi`6cTTQFXjny5#K%4s)%@78Hhvbp
zRTBd`k4e@$-gW+mqTLL$mAdN|J0@0Em%mPN%e6wIJvUw2MB8i{p_cI=*CSU$RqYYR
zYLBS9FKbH{KR>)9y!c~$hn;fE(lut*D+(DT*k+)%dd#{N?HrMB{Ym_S4Y-M`_m}dc
zHAmkvYBX_hJ(p$L`9^D9JNF#xvcJN%DfZ*3yX5>2OuK;5dUvZ2m^t2^G4ZUQYo=dh
zujJI?Dfts;9pE9~XurDpkowt5<G7XW+Po^yNG&k>@oY1Lb|hTqbDfjBmDWFLSucL$
zhr`2m-H5#6`dTfZ{)<6V(%gd{VcnvHu2Xx*Y`;H!<Jb|Q5ltG(UT<4E{8&gA-F)*H
z=?<gj8QW`aMS*57RsyU9SP8HaU?uSXnFJajKDF%s{Vn}}4{v8j5AF}z|3nepnP_~8
zRR8}gb^pb>{8L4GC(kfWCs%vivbbC0UW{?^hBH*RS!jwtY%swdmJ+xk-8elxqD=0{
z_xA1HL*L)a&uy9)*M;LZ-P@Nx1b+NnpH`@|q$tvr4^jdzV!E3jK7l^0P+wn0p7Qb;
zqC00Lil?AHaq(?D7a^Xf{#HCayuGFk`B!m^Mwl3q(YWmp#f>jTqegTQs0@)LCJ^qJ
z+Hv#ua`W-$+E3>?^6Yth-|s}$>*s<VLbO_l<%ECk1EL~net09^-{;4yT4`P>O0zYo
zfVgU>*$(a;PS+|o-^ZAU|DUAvci$l%lBRE59qB8=`1<=i)on<VNAyi-o+<#t@Ga+0
z<!R`@&s0g%Tsu#NHYMaqau}IL<bSGDQ<Fv~q*3ti^6)1q`+X)#nx5KuNYdjaDwCO_
z^mIm=n&8Ir95t+I_^0yBh0BLs6I#|};P;Q$w{2T(xs&#e*!m!KiS|GCJlcl1isBxC
z^&E25j=MA5Zuob3A&RlEen=AM+OieLnbeQkarPC(Sxw|2rp8p>sz6dlcz;UXzFZHk
zqaT;Zg_Moo#h=Kxw#-S{5X(2Sj<}Mtp7ZbITN6V`<5ye0Bz}4#S(=j07Z;XZ7!p-1
z5iw=*(2dIwwWszT&i2l*M8ktQAbVGTFRX+7JWQc3t~meX;17?F9CQ=*u~m>$GS;DZ
zuq8y|FhmrGoS(#jBbJdc4jvxFFp)D)6pKF}kBN<ucwAUsqO#Bg=At3qP+JzlL7csp
zqo-ILe@q_YJjoNqqjsJQK+CyTXivf3-rm#6-r3(5Mw$Y|!uV5pB94OvX~=MO$4#0y
zY-uu<D7SCxii3wR79<X$?isGXxu}f~QZ7gtYl?Cq6yvwL$Q4+dB3B^VBrF#(Gk{8D
zt@)U!EK);Gq6{FTW;aI<w;&V=p}7Q_4-=^mKl~StC3V=Q(xY~gTA}o*z}EA+Q^a3}
z>+9?7YwwII@8!=UUy9>N%dfEbQX5M*h|MG<(2G0E+27N##%+%1y|a_Qt1Ikp5qnH|
zc-KkfmPC(~CE{-~-jj2)iMOzaM8}@b@Q#n)QBA0uB0R4_<~#F75+~HZ3nDjPb6)uV
z4&IC7<ROX^8PDd6-a8|f#151-^79$w8;H#Gqw*Afp9Ob{h^H^t)fwizNHl2Olw$@e
zv`VA$Vb&uqq`tnxZyLBa&~{chCSHv(DE`s%0btDPF#=MZ&4I0fV}RoCPW{907}0lR
z%=dkGj-v1!fMjstR4Y8;m{2%Y{5#)qMB$M!*!SOgiNf<1g~zKEo^bpk9M?$togu<7
z6op6nVDcRq0`|jAuG#RPRK;Lm3t$Kk%dJc(kc>0JfJDBAxP^VTurL3o{$S}})Q>U@
z>0gOIq)zw3O|JO}kHlvIunjO8Nc!J}qIi(+g?-yU``#4a3;P~npG55akoHF(H@SKs
z9MXpL1)>@;8bA^cEg-rUrXP^>VLCt}7vi6=AF10vUAQCu4FMAW41mNxBOvi_D3JI!
z3@G+b*dGY{iSOe#0`7=^r2G^ANckuJSpbQDRzT7gj01}O6SnJh$FBw45&zl%iGM0U
z;$J%;@vj4r#IGZe_@{we*hUN6ZW6!R^-~q@h&($3)qq_^-*Mnb*v<;uU-BKc6c{D)
zF)nNw2o!<HUmE^EAP3Lb5}|s}n0r&bXA>YPyCZ;D?x*_H<AB(TrncWLfX;Zf0xkni
z0Imj323`P80b;8jYb@{&jk7%vb)0bkE(baRQ-Sb9a2V(cyaSvDd<k>|qOqd3>>C0-
z@Z1FG36uw-ITf@9`T;uu{eiuKfk0DWFwhbh0vrbn1&#+s02cx00Mmg{zze{+z)QfD
zz!s3zDxflOBhUf33CIQR0LB4#0#^ce0k;9M4J0@O+ygud+zY$`+y{ILJPdpdJPP~-
zJPA}nh0Fk&0#5^NfM<ZNz)awD;8~z25Hb~P0bT;$1ZDw?fLDMYf!V-DXmG9qWq>)r
zX24s(?!enXL*N~t4e&lN6!;LB1bhTM0n7*90X_!413m#ZLP2{5Yz}-5Yzr&|_5c<E
z^?)ycX24?LRNzbCG++tPANU3s3`E%$L<8RgR|Cs{TY=?3qTBibcpCT-m<9X<yaq&B
z61)Xg168F_uu$In0_y?wf%SpIfl@##U<05%up!V5C=Ddz5LqC?WHj1Jt`97!zOAHs
zzJFT3PEvg?N%gcO)uWYEKlV@SK@B!S8z(g{Xv_MJs^R80oyP=B(Xf)wJ)hE8kzX{v
z*Rv1vwyR`bmR!$QQhnPlC^H<XrZOf5X_GrA&+TL5w!W{%1Enj24{VW@dRDc4pt{ZS
z-e?H^v_7z;`c0DV-%6?vEU6x?q<X%R>hDU*oBmJf1xd==l2qSTQav6?^^6*DNICsI
zPrNsE_j?}LMC$JM`o)RV-NdDnnw{A08QXfst+Z*&%~pI0T|8}T>!<7QRt98!)_K+p
zd<5$5_xyB8d1aF78A-~oN$N!8_j~@gr24y(>WfOMk144h&!6U#|7o7Mr2KD5^>`%Z
zf7eqZ`TKi)M@f0&a_+>xJ_cR;JzlG1cR?d~(7MBAgHIodYPBWD;6>$(aZ65h>w|%f
zq<nHo^&%zJ6O`1hjimhaKdmPyss5Fuc6TJ@#Y?J>DXHBZNqO;->bFa($0(^DnWT0*
zB<00RsxL1oZ(34)vp=mbIt~+Xj?{w#6<ZE$+uv+#>7;>1<x2w{JZ2ucJMpEN#;fyr
z8`>vg?hsDhCF}Q1R4m-yWc%Grm*-67?4|?Sq<uKlTy|dn`MzzBWp~A#kh;6963yLg
zv@%vh?dp-en!R6tIH4nNCm*g`^?~PWsxtx;9!d4MCDj*|RNq@ty;4be*pl+ACFM;^
zsxKv}K8U1xT9Wd=|1@7)QhiKG`P!1|PfDt%B`IH9Qhj+zdDxQL3z3u${r|h(;h)x%
zkyLL<Qhu<c`h=3|>q%;tMN&NvN%hwx)o+i{BK<<8-tISAqo*+0jolx&uAg@%<01F2
z#`2eT9MGPzDtA{I7C$A`^N>_uUQ#`HN%aaO<@Za<+yB#gReUTobEGO%`CT_PEPtdm
z^_8mMuno(!H6|pU407;0xa~D(@8R)SSd~<-N>V)qN%f^9)l-mEUrJIvJW1_#NNO+h
zPwN#(s?Q~<{Rc_yaY(8cB&pt#q<TD(+S!m)e@IgO97*lZC1O(tdc&%zX6ebs8~xno
zy<e2@(qiUwmAA^yGR7Obok)*sAnnC4lG>G%RG&st`=$RWeHuyieI&K}DXIO^KW%?g
zQu|es+TWDaewCzlsU+14lGKirr1pI!wG*}zo6oSf_g7i#_c@OqeYOlAbj4Qf)${vN
zgAM0DzTB!^YFMvKrD*JJQFl&)ah4;`wRNAcuT=I#|Bh-m`fb~qm9e0MLXP^3!GdSl
z_*5QD{F@plXjjsDpa14nSrfj<1WHHVsJegQX5Yf&e8;T6`o~AXo*i{pw%m2IvVZO<
zFT48h>)mM^6!6aO=!o~X3W|Ny_fI&`YccjFsk`6X8Ish#ucY>KWrvV-jBYk4L$`Qm
z%*6+WC-=#gS8us|{nDPLxAe?DG+vxnDTfW>|E3FDrr4{lN2n%@i=N$|;{SVkdkNY9
z|BdJViMjt1M0`K8Ur(;~xMgv-#=UO<_MUNgS3RcQ&nfBOaQ{7=y}f3l1PXb8Bwv2K
zzU9T%#rfZZaC!KU@SDUO^CQ^LCl}!xk@zX$UI%v?wd3~#$DBmxACb&|_aWuANs_*$
zh~xJh`uJMuix<g%5qJdTBK#(jK2n%B!JWmwOyAE4*uPC6!v8sU@Y_7Boko&pVxFy`
zNI;$87vU!nZq#Oy_J5fsF_HP_{K}ulPt1cQc|ci<-*K<=MRCT`Uk#6$<im!48D}v$
zSduss?(+9CH5QeViQsXND+%?L{J9wzi}*2@>fmEi6&*BVpsM?VOhdvZ-_~(aE~r@N
z=A0Vk=+OEnKHJ3wd<}9DzDQ$WOCaHa=2M;=+J~R;K);4A3?IYVnhSI$@%0TCwKm6-
z#EHm*50}1NKI*^l%uOHUlQZ8pP{=$b%wHjQlJGPMcM=Tg8u}#3bHdfE&GGDjcdu&P
zqM5*Pj9y<qp&ZaM{7z-zENqLkL}zy~SU)CL7;Yk#*|=@`f+uvD=7FnQfc-RIZ+{*R
zdHh8k67sSMFO|rFhd9@KglEDJoes~da3edIzo_3|IorfN-&3eJP@4xTY_I=54^-HW
z{(WAiuzmXb{7PXP@b7t%!g~47c#Sfo&!hE5Sf2>Lt^;0G;U-sO@QX+tYXT(gS5qLV
zKypCht~n6d&L{ve++!4hV}MFPJ77zoC$Ke;lo4g%A|T-l#sk{|cLLi3!6l=-!An36
zp26*6Issn*2`}&?Pz^}pO!$GVfZc$&DgP4ON=6;eCcs`mYhZ667f5)Sen7&@oC74h
z%%wnWAZb4cKNDOo#t?n1us#dxIg!V3yzeLKdkw+YB6T0{D6iKP*c#6xfkYmofo4EU
z;07Ru)q)*B8(=kX5)d+^yh0NHDR@TQD1R^#=z`}sAQzYjbOmk)LWY79KyTn#pbxMB
zNce)%h#TPxb_dP^js&8q6SxC|feV45z!YFO@Cq;zSOSa!Hb=iZ52yiL0JH=y1o{GF
zfXjeOfCqp}fj5E6fggZ`U)UP;a5YdDh&&Zc0<HrF0TY42K*&NcAGi^?61WLS_<x&$
zslYA3G~hPiWneP!3UEI#4~ViMcm+HLtOgzj$~VMXB~TTZ4(ta!2^<VO1sn>@0Ga_$
z1IGZ*1IGg|0PTPmfzH4yzz87W86E&$2VMc*1U?25-XY-+qD%^^fp>w@XqWB*TLANb
zq(687B;{y6Zed#}Y$HiIlEXXX2fd!a9h_5sA*oNV@!S>o28iWD<}Hxar&6E+unaf~
zNce;nz)wJ1;9o#2flxjn5BLSo$a~5sB=wE(3Gpq<5B!B4ca|SmH}8+-2iASg2Fnku
z+pZhS4`lg)o<@?NC&BUq?{1s%rob>UbjG~W)4^9>nxu|grzE+Z@Bb7(aHl(2U-cez
z+dzTuv0mrc*-4dtL1Wy*?{6M6U4t+E;&sDO*UIBqe&Be;P5YG(@Vf2oWOHDtys^fc
z3!N%A4Z_?A13l<9UEm)L->BB-*~`-%++Vo6-QK}-?H$qdP36w3#Zhaeo=JW#AIlG{
z+s-`858M<bw~~KJPbG5jJ#U?|?O$9qv@j85`GIwxJHhe;>$VTe@&oI(=gRT}|J}I+
zEI+XBbK6*cVBP2Bu>8Qf?XI)@z~<qu?+)fUTnXxWpQ~n(bijOAiNc?^JIwL}>pq8z
z<p<V%zB$Ve{CDSbv;4rs+^VSTr+ovj%#YpcadT%(!=uBnkHqo=T?6Ka8J*3!ze~QV
zi}dgzvx|*o1=x$jh8gV4hwB~~Qh%OW{%55@Pu3Yew4GqFIlsbhf~)$h`@58<DS}%x
zgt+^^#Sg?5AbYVAU?spxfRz9%0agP4WfA}->VJa&@8$3L-_QRS^NRP@6BY`>M+C)-
z*^Zm=icjVIj8_ctaDCmJ;qIUCicLg(W-+h-68Ln4TbKzXyyCZFzV%Od#p2LO*c$jw
zd|`?pzJAInCfwh*-*A87TOHhAK70~$jtQ^$XPo1&JmRmO5Y92NL0g-1Eao!T#VNK%
zy2%xWn{eX@e~oa8dDs3dr#KC~M+=0d2LF#yzkkgsCR{#Y8K8C&neVxLgd<4G3*iVh
z0p1460|`g4J&<q&k)4zyi0xm>5hNVZM|eLOm=Bx*B%DCP-Fpg*20jOZSIHCrNm(oe
z5^f>UQxTR8P<N3I5+7Z>&k~j2v2aJqktGnzV2m|T8Av#&9e@*oU4RH%Fb?Pl^Z_~n
ziOi<~p}s|JROSQ0FBFsjy@3@#xD|j`NV%ur@iGB;_5cO}gMjcu0DG*IdrCOAgnPOc
z7zreGEDD$noCkaZB%D)X0~5SpfhG`P3#@=~Kx-gW(ghB{<v=gs3Scmha8ILwtAI;^
z@xYD1wZP55&A=VNEx?1oB;YCFR$vxz8}JS=8Tb^q1NaJv`Y(6~OaWE`cL6^G2^X~i
z<b43x1b7gr2s{qd1fBpo15W{ifoFg*z)avq;CbLK-~}MDt$7J}8h9B<>U<VZ%pDb$
z`MSBIZQ+j8kIq0+&bk6|6PwtSJK6(CxTESo!W~7~qufzcCCVMu0@~ueHV}DBZ2Afa
zcT^Wh%HKfXY@i;n49MD+%wCyMxTJ8+@hYjpRL<oEMe}C|Z<H$~{AHFq%5q1?qcLY~
zOIGRVk8PRQ^wGs8_A2o{J^OyKIEcoFwJrJXMYiXKkD=YOT6J1?SGMBV#HyVbC?s;o
z8YF95a&mPG6Sw_)MpaII9>H=)o8%8K8#O{_?s}PzH%A?@>k+}5C8JpNMF4x_=<GRC
zH+|z;jxTU&UCciu{lAktYJ!0-M`}?EUB^eBW<y>qUU<D~ot1;mgMMuk`lKq(AAj*=
zyRm~XFk)>>vfNSLVa#2+k@6DJ=V3yD`)pnPoRsVa*{$onGJTfN!|G_HYJz67@Xk`r
zF}I-ZG_2+JPuUT8KI!u6hRZb`naa&QIP&o7`Xjo>BySR^Jiug(wJkY%#oT~LCPwRb
z-rXoS&md{@lJJhc(6hv(fg{!N;Fh^AnQh{h`vk|a+|i+ln4@A6#gXb^5;svX$bZkg
z>vGds?x<T4!?3m`liNice&kbbvpaLqt~~>*^Vj;to`wE!A5vc2kIgJT{>mxz-u<MV
zEO+z*+LjC~KEPIyo!uifL*9ezV;7dP+|g}Vq+xAKj;Q)FAh>u-9~;-4sM!Ml<aYk6
zp-j!%mK^I6G(SdQ-mAL2L@(-sW*g)7>q=qo0*iI5ZOO2`4jjd2&YELCp3G5JpW6{@
z>^ej)7xLoOR;BH396RTw0_WWXha~^=D*{((v>RJ5EYmD@i8bs~^e677U!N1h?AGqy
zH<de|<&Ji*g8hgAL@uiB6MWNCl*V|(_qdYWWJzk$$6Kc|qED1gUN+@?ryfmTVZD>O
zyV<{T@T82APH|0@q)*vy7?+}7pi>wf`$S*%=B$b3l{wh!pzbQ0TroShhm)N*IIlj-
z9lh_2bK9`E&XJON@FnV%ptNVp=>v|l+|g$vu-Agk29DIg#bp)Uf;!xv_^jPjmOHAs
z75mEiL@vC?ecqfk4BLMqu+yEqoV@Z$rPqs>yBqD@+kIF`@F3ro*aM{QhD)CuxuL;;
zrunU>WwG2*Z)}dSwk5HF$6l-iSP8HaU?spxfRz9%0agO61Xu~M5@03pUn2of5&tLn
z|9m%3E>!^dZ?^yMB;w&e0~eWGgtIM+yEX3DSjQCH6Y>9@efjooUVN^vm!pS0H7w5a
z_Hc6!{Ko#j@R$JD-X^lMcX8x94uL;}qfhea$Lm`=?RA|6kcv1EelD?bJw#-G+YWqW
za$)I*>MFDVk~LRG7*`rO5?x1MU&law=jo2Vy|l#ffUCMLK`P!7&b|!r9{i%;;_uqw
z-l!woTX1{ou8^be%jMdC7w&++6Yh<lglh(VG`VW0_b%M#|2$kxlHgzIWz<gZ?eD@h
z7RmWS9pOHQTZcO3Jc|h0o-Y)&#9=@EN!Y_g1*UeIAHgl>mtj+JOC0utpM-s?j<BD=
zt>G`jrXrU(?ELS-P8HR|w1&dGRsoQDsD%48-16?!s)yg7bMa%f`zME9{5@X~FG=h5
zQN;iIGcXR3G{Fy2zr<-zCd7VRB+p6O6>wjGyVyUO_MaSx@plvdPts1(8YIeRJ82{i
zSM9WBA+3hOIxUROzs+ZF9@p2A@9oQR^7i(SJijj2$}bXUUs0Ufk;V}h=$JL<d0d3s
zy?-))M2CA2`HF(0VSfGZ+diXq*%F`aLCRL`vpvN9#vPG|gWwq{YH-FB<3B-N?PyJB
z_ba)<emndS_Zvm<OWbdea~+!EHwNqQ^qsx4x4##kp6kFtJZ|9D#LshS*k5(9UcwJI
zzOY`@mi-)3A#f?;CV$G|z5=%nf3mzx!vPz(BrV(DmlLs^l^PRYsJ(cGi2Mfb!-#9_
zZQ6z*6nk%9^pspjKG$9}SRn36xDZ!e7nQU4tc;s#qWl#OF{u2jplg?lFvQ*w+3AV;
zF^?ufFVCYtBk?%{EQH%rximg*UT%ChM-R84+L0k~;nWoq6qnk0PRp8byo0<I=K1&W
zBYJ-%enhxLpOCmCXPOK_Vuk0I*wX_{NIA;?PG^vu1ELIh>LU&L_`cB%5@%s~Av%oy
z_}dLPahC^ox^Q<A&#EGK<h&H3pGeA~FW1lCgN))_xKLaBTE@g-OvkrZ@xGu|7~~8T
zaTr9V<en*R4`>0Wx>mG3AbMD&4U_+qWzx;hekL-<1%6A?CJ?!PUoOS*%@W0z#FG>W
zRotY1$^Vn>m-wKczY*WsZ5Wa75RrU`HG?O(jF91ESYQA=i1_lZi^c-Abz|wMmkhgw
za-tvp_}@1=v9-%C30JI>n<om_2j7!+(i1n;$rb9N{`9OLVd%eVKfXQl=KFd=%0H<m
zWXxZ?9=}8Q8n^{?{Pp+GwqZoyk-nDbi;`h2nh<)$z*{0)qIXH=5levL@J@-^=D+)0
z{y+TA;UC76^AEo>{D<EO$D)7#tRUeyPB`XSjZCPW4_-K{gY;|OKr-&*0mb=XSWBMY
zf45BZ-Ez@)D@5NJ!VlrN<lmh!MEntm!YAVfQhrEz>4%$K5%`(Zkw{<{U=&aXI2VXw
zO!a)l>2MJFqlow4r(?A!9czH3Z;uzHgEZ8_epA?=lJH40=7F1B<_L%MX=8z8?rsT$
zIsh{sXbPMFv;j^8&H&m1=K-exR|BU4Q-F@Z6F_Gm>95h=Qu)iH%@OvK(BVafk?=t|
zV;bN+xllJ~_^p5>d}SbL<K&z^s(;%KXoBZXKqp{lAn6BD{{#s@$V_k^h&WSy+wQ<l
z@Vf^P=NvJ;fW|;ji>aP9sI-EWc-91-0cru?0*O9vIS{fJsA8TDs+(XeP!~w_rHNke
zb|CVQo&f~Ph@ceDgMrFO7pBVs1E3+0=rJ1s=K+m@yMe=iWZW<uD9%q|KPT+}zR%Ca
z$UoA@ECF@}#)|S2@e%bm|Ln}FQ}|xk{tNpBk{`$eqL)ptm55(M{Iv>5!e0X<W2$vP
z<OKtn3wi?A13^2YXB3SDZoo6j20fd|8@L(Ik-#lL_(k=`w*$A~`4})6m<7Z;!9(B<
z;2R*yl0XXiunUNDubADyp1{38(tqs(68Smcek-y+;Df(OI%I*?xXFdGO6!#ekfaZN
zkf1FPaTBNleSt)lC`$r+;4C1%q5Al6OV5BR1G4(ttp2uYg7fqAGYs<{jS@$ysf>w1
z+T_m3bNkr1vHIJr{&u&XmkL<@?bly0M&OY8QF8OBU*$fdx7YFv(pdfNYw-+|-HFJh
zu>TgHs?dt+)7g1TJ7<+lKJby%-zIVymfrTDa-qht|9<`LIT&C-PaueIb?&Y-@8PJC
zB^)2^mD#%=%<wQwY;JD#dALK18FsAxHhcEZfIwD%yYYL)tCi2boZGr}TBFW(M>kGg
zcK6oGcRWnIj$@L?k&2nw!oIAY;kjF*WUu)>?&kgGsC)0D(t{?adUt6$Li-aYE@jl+
z>F06No_mFCD7g2*j@91|UX3{~CfFRQ9bPJ&mZvif-g<tyx1`19hDkEZmt0I)8h)(H
zj4t6lSpDto!Cd>06o=Ms*NQ^gE!%Hd>S<v4swJzxJ;|xVDpr5HEEa2XSWMzbJqvK0
zsXp3r)AV)GYXYNHLZ@qw_siFh3bnTM-Miu}tH0gxOJzlVsz5bK-m%#6<H#zDiXhjb
zMXdgIpkuF8R)2d{Al6p<k$Tj@&#ZmdE`@EjSO<Br`rBQx0J<BC(XfXh|KhEM?E+67
z&()sO+AUkl>TkCiK;)9tOs@Ru3s2`!MkVp9`0JE>xD{NFN3W-p4?1lYeV^FPHKp#B
zmMVW1xZM9@J1V{TaPM=AR{5TEUS&BX!g<oE+?7eJ{<fdny!VR|URun2uJTsdS;lx{
zw-f1c4WzxmyTAfDN9tux`5IU0nBtWFH&>L5TBLE_^?097^B*7B?3Ci27fROfWd{;>
z>rPx=+^E1kQ2pFKYfYmE1rA5gcAlzc*7RKCOSvh`eP>pGo1Z?@u0-!~$kS0hJ6^oD
zYLZ{4ch^|`?a+uO4P~#lEggO=q>FC8d5m<2QS*%LS^aG<yZZ0z-Dw*X@Xqe&i1)V&
zihb1gPdLzPG4_nH>By0?O33!fTzPx8{OG889^5;(3fc#~?!A7rOGZ7VxX%+<{cSW%
z5?&49ZZcC(fjD>3v-9?|^LBE#3()NkPK=$Wo7W7G*0~;bpl18o`Qv{(KVN4%M;?#-
zDdb<-1$gqwN8|%HZQcHM&ip{0ko*rn|C{;${Y6}(H0;fi3;XGmBZvKVrUd=(2Feks
zXK&A=BC&V%_d-wbD=yYojt}8t$)O(?aopUzT)n|t6moo$dte`%??U-x;y5T{Kb~Ao
zag#l4(Aj7l@@wKS>zharJ{X+Tby1!Z;WUxGW>eh4bO_VO!Co`rY+xyhUP{<I#w&2>
zgnQ+!fo<@NTYzX%E(4JV_MdC^{)KT8#+CRdh2OzxpjUIaBk@P%s4aRFOv-JLfd^X3
zr0(yUwqIpXT=vN&&A0B&2(dPp|Drr7bK8|>XGX6%cJ=w|C9p?N-OUlqQM&goe5QQ|
z`+2i-Q)bn_p&S{LxQXAe!`ZC?YopS^E1>RXnT}sGXkWACtFOkyuiM>Q$+xom+yR1H
zN>N4k&QI>;?gIPl)Ln_Uw({j$341p+seJA5R=Szj+I_?2hM#yGcx+p2L3<r+#FtWc
z3qPv_WN94A)t~?LgUXW>m+9I04t`c8F|sp~2H2V#f=HkR;c%p)&)wc}tlCy@>csb(
zdA^2s58aE|A{~$xXLD)MhO06esF?25U5L-&e9Mbx`~2_Si%z3^#})Dp*F)Q{b#Tpk
zJMvSnCZFox4ZCCRbfPL)irr(jd1U%Ud(q5!j-^_Kz7;wv3)|G&dqdshsM1<?kD1+L
ze)zGS3%kcW^7Vw0J;oDLBd#WE<sR*?F>T+Z%{KekJ?3egN|T9tD{Ln%<d><A8oNb%
z!e@R|*P9@!sdpy*%>SJ|<}-AUIkL>`+8X0l#hbQ1ba0;b^hDVP^ChyWH*TwKT^#o!
zy%z=-tc`HiMmW32%<eJsd`)#mlru~&CMsBi-@fUoy7#-)y8;_HHa#!j{nGY*z60ZJ
z)@^UB*sQI}D@E|O>E5yZ1YU&<Pv?#QsX*BX!<T(eJ@0kO!SPnams#8U_Sa(fn0sk7
zGG&T#+8QWcPf)wCFI{^7tEY$6muWzLy@;IKzqr!z{k~_}>>l%~B%i2_Ab-nXg3OV6
zKEv-#O6rdN>>l%?>IhACkGWl&SLGS01x5!3d}_e4E=}@E|J>}Q&#R5lW7Q<(<#>hO
z!0UIkjoCfs8LM)4l`UhKG%Ubzq;$V5JbEJduLO3F`S6+0?(7~jUv5(Bz1|*kp9IS#
z<n%0Am)6P8J6(<4V@}c9w`8|Ug!$fic_C+=u35dv+PStz*zUJj%VqbN>s+7o(<SXo
zRpj=N2OGCPjSOmhtVPEz{_;VuUiW(NL^0)P#iyjCfwQ3(M%^7!O*KnTHr~kYF|Qu8
zZbdss=-TNK`K{=Exx@Sq-OR@p?>KHcP{FfVXtd8bGs}>K#dp<B8iXZ5Uy!=fve^|~
zu0K)sg!z=#ubY2fIC6M<gKin0`C*@*=5I@G8HtSn>h9c_m`~mf!ycwJVE34duXi`Y
zzRw^cXYZKp_or_hJA&O~cFg*#e|!}5BkA68*>cy-%Ko{d*ga;^mKzKIhb8cD_Wzx|
zy=HR31Nfc*;O6(00`T9w|F0$5|34tw{~wKVME0&n;*Q07$EiG_tr6$x)Cvo+CPnSA
z{G_<ieRs0QPxjO6V*{L!1&Cb_vZqg;Jsth9!Y#BtBi{FS5$*f?<30Hf+t5r~xRrnK
zL)i8n_>JuQW6!>>i-s?@$J7FT2)PGBdpY7bh~tExzloFBR*ov>rXtRQKMzI>xx^h9
z1ARoY$`i#GHUp@v2#<is>aB>UASye5OitoFs**xLxE3O>u$0Gy0J|U&8ux{A5`|kM
zqhZwb5C4T@iV1Fo9<{a73MrE$zlcnUylTso$m<k19(Bo!xF`0BW_JOX!Qa)D>q~eP
zO%#Ydp?4UY6Jvpn&M+rwPnb5s-_r0KAx#L~iwtHVO!D0`{Km)MqTf8YUeox~@hs+e
zV7MwOs|-WRFtH~<+J#=Y$<-M{EmE%4fC!%2ogif#wizg=!w`Q9%Nx!E!r$b3;vUpy
zdSQ8$azwCvO6?}VUuxF^%U%LfUZF}*<BzZ$P@57z_(SX%5P!XZ3P2vP3(yZp$`R5?
z{n?AZh50JXZxSD3pJoegav8uKDFcSU4nSjIZ{Tp?1fVH!3eXG~0UQI22aW}92U-9x
z04;%6fmXn4!12I*Ap8(i0d0W9o`Ws0DbNKt8t4kN2f6`CIdlh>!98nl;eRj3Wv~$$
zbI%Lfvc98gxcN=zF#%IFtmJdgr!-dN7me@r?8Ch6Dw&tDMx{dBv0RuduCLVs>c1E?
zCCxqP5h`O2cu^dwL%S7SST4*!?yNOgCDx^_UZ5R@!64{OA8NFBi>%WMmJ7pjVZ8Wy
zFIX;2WTtIvTMPusRZ0E$kh64-AVM{P<-+K8S`@qIF2j7mOaUBIKa=wPe{JaUS$=tB
z9xwFdgxf{$=FSS>Ztv)Erd9l>bu1T#wYR|9TTr;fa$#65%mRnyo9B;l^Z%^2f26L7
zr6IR0q^s+raaW3mA1Q|IzMiB#ZDO*AyQnxn>*j}Xi(OM%hV?$-JWx8|^78E|$^*I6
ztq(BFed=zCW6mMJF>fPTE=+!e`KX1MU|+!mn<I5Ni{Ege?!v_i()(jg9*%t)u_JZX
z+pg8o&%9VJOjl;^^R4aPp6acm{qmLPm~$=kl~;x=WVtYv#&IiIF3i#T1s_^JW0)8%
zQjaS2cE8aYJ%!0`?EbiQ{k$_754nFemcO*)fHup8c^RVY^+KnrsFB%~E5&*v_pi;8
zDz}nhxiH7~%lfcfnB1YBdXa}1=4pRYk4C&-rLL&(G>PTH^t-o8XDj3~oN`xwzdp%w
zVT|_NbZHZ9vuT7{#)DjsTn$yVN7xW~G?0|5FKbH{KR>)9y!c~$hn;fE(lut*D+(DT
z*k+){a$(F>FU?u3DZk~cz1HKnm<!wy%Z4s+e-(ddT!|(2uNG16N~xLWy7>kCDl<oU
zeXX-R>%)qvDcj;o)SZf^8rcurhE1Cc>dv5JXvtsKc}wSwyb!O>S)O&~{rn#L?qsa`
zkj;-|xiI_uH?PW?@I@w2I`T%<{R=ny79QubTo`P$u@@@=RsyU9SP8HaU?spxfRz9%
z0agO61Xu~M68JwRfd)vg>sR}KjvAVF_OrZwXV~f3`Pq#mXV!aiUEILqwwvk9$4SV3
zb{=j{Go5{L9xu+z?BnIgcbm!O`FgwC+YitgI8eKvuC^wz2IxX;2-<maJ)J#yeeg`g
zN^}7j4#P-;joY5F@~>Zm=5Efu-hSS$d`@?(9-Of}`0W<t<~5Bo)Z3Hi<^ck9BgRZ&
zm=Zb5t~sIpGN$0ol8f+mi9I@SjF~~;Rtg?bJ~u)&o@5O|@2}21#a2oUf4e)@o;;@e
z(PzSSC(pikCR}WCuI5;T>SSg*4nNU%#6BN=XC-_m<hTptrdyx5!k#B?61R)EN!&E@
z#c>;EGuCPtjT;BQ{djS{(FOQb+z7YZt0lO_wc<w3!KLp+aU*Bcnn7Ou5U(TzW<}#6
zOb6kV|1ND}yMy3YGY~B0jg$0hiSlBDD7_>vNO>Z8u>g5xQIi)|^z>Z3rfDW_e!RX-
zbM3Iic^)g`@PqG7<?0P2a@|`K4izg6L;1%5@aEevekE6O?r&?9fmyZWS|ol~ORigx
z_C<)-X!w4e#^c}1RjezKA`;XQ<Q*wT1PwuCj}_{62rC!flQP~NSjQzQM@?y+=_iVx
z9Me#trSNYxvoX3T^9>cGYMuws=gfzstTOn$KYgB9^Q=Rk(`X#X@BQ#B)LHqNJjw46
zCDje^a|@#N=bx6l{-QFMFD*=M10azN!67IM%wt-|{Jn7Q@iZ^4i@iunL`EbIKVIT8
zA(YXaLYi*Gv7tg!;onH(0B!Oec~?{*mdgN5@w<$gcm1*YFLW3G^&L@}px^p^eWxRS
zXZH17O&DFizN-nN`nfn<otiM7etkz&IA|DYU*BPeOZaZZ*LVHI@4UXgBh4WFcEs0r
z8sc}Hns@zb!ua$|9G8AIVO;<Et|pAbU*FZFE%xiXnzXsqywk2poAK9oHS%lw^<9np
z%AShjqFoclm9Ot=!q{5#POB!2#INsa(iZUbT}|37zrL$UoBG#xHS&}C`mRQPc~8Xg
z)2s>O;MaFGVJ!aoP85c)PJQ1tlfJ2Tzw>?Fs;jMjhi?pV3;RZ4pNYqBbaaR=4yi{(
z7l(v_1PBy?NF24}3gJ@S8VB;5sQ)1S8@Xh0ThqT7W)$2Jf6yLMe~1nZ@rUTpr~-)&
z4QZ<^fC!Tr2Rsj)1SI|BWS}^{!v3S~_^QDjX&#~fL+!+N1>$DlH;pg)pqls!`v<Bg
z1Q*}N7nwrii$X!;s|O_Ug+39DFI0wUe4(#K<7)`?#P7p^r2ip0LnOXD+`@KQ*iPe-
zo|EoE{=jt&?ucBj1BrZdfh3%Jz+S*SAkis$0_=x|w-D$Dd<l#KmH-z3-vbkXWk3?{
zUi>X=^Mq|6p2&H=%og$<7Z>hGxJ1WD9_R%ml>%`WOavm{f-s;Da4XOkNb=PWh%l&5
zRa^Mwk7sh0@GKzFVG00R0|S9mfI&bfAp8={01EJr4~zifJYQxG@E~w5Fb_B%C{>?f
zqJiqbML<j7VqgF;7MKWJ3fu}@0lWfS1uO%u0k%cIyB25+OaQt86M<x$un~9|xEXjI
zh_nel0h5882EsFUM*vgs>;>EnTmjq*OarC@p8^j6tAU4sT^cgXQJ@*{IM5H64vYt$
z1ZDs;fJMMFz@`xVSzsve5|CuXWgwBOGVUQB(3`6_v|1~+Vb{K04}KZ>`TwzZCU7-v
z{r}%8l86$La7w038A1apM1&$l(Hzk{C=sWL%u(i&xe%4QnF_g?lQPdTRwPO)x8nc#
z?sGC-_wqdd`#it<yT7$ww)Z)wwf9>4yVhQN@3lVPwVaNaA&)FD3or{X3;Z`MfTr!=
zp8wz5#|!W1zjOchv-h^Q^|AKmU;F>b{{Mr;?;_>mHd_tGYzTX{1IzK$s)-vxJ+7X;
zyQ{0ao3)SFEP8(AzisU^n163G|9&A0asR=b`l4sRA-HinIC}dyQ*VpA8}<{;2|)hd
zc%O2#c6PINba8Zbbo0S&o1W!G?^}cE@9w@{_Ku=sQJ)3w<DBgrTW1$rI~V-?$*<fK
zdHx~|YiA$PKIDhq|I=~!pOG&~c|F|2Y3_j_9AhAVo}&2lj*MM7>*4+$Ue=iR0H3L^
zpl%=PD<I$heDOYXF4TuX`Es@OxBk|D{mXr?Vc&U(*RF_vrsnN)>j&vIL)lPzZ^Zjh
zde?q3y<yll82k2o@j1P7KS)m~POt4t(LR)3)=#FFihb!>%u>8BmH*)%r1u8<OvFBw
zU!<4%gY-mwRn6qF8y7_l074sVcx<6{8#tv_crFpu-MVX;udDde_X6L?@K@GV%3m2$
zI*Cnm4RIV@TU#4p4k`SWij4xEq4;?PkZ0i%d{+jYQ7_?2EOZCkg1#W+V*E3-0HkM8
zRd7A125tn^!5v^H@B`Qx6r!$afQ!IxU>1n}E#VoE-jQ-aJVy(=!Tx=~y<k631^Lth
zsSUu(9si83iM)yIDYA1F`YI5e(&a;Q#3S1)f@FW3BmazOfkN4b7ZB*Z{R6MMR(3Qq
z{Y7eklYjU^gVVWp_cyEQC_Q}eycdQtLcB-t@#Y5&OdTw-SUta1QTK7Q{sYTNraSVh
zyeBzn_}$&FG(!RJKDZbJlB1jGW)6I@Z^ilh`X`cQ-hJ44@ydn7H8*rjDjKc4S1pH^
zAhy=Vs)CKjY9tE|3N9`w44*fDn_THmlxZ9aNFez}PdA~rv!&vM)9MY2R9?RvpB8rQ
zl9WW+$7+L|n04JyQSR{ZRvxH4);jE6XrZRLz46d~H52z<cir%8i?>l{z2bx_<*8T$
z1(jAHX{RDFK0dy8kk*>4J=2wRdImh3UY#*->8(YHf#IGtV@x^Dh>zF4-N4HM`$`Ot
zl}R2ik&S+!tu~Z%7?yG6)rd*1TIPmTY<_`F+bRwX+kY*D%`ZUp>d1_QfKef4Gc3=v
z-?qrI^~&QqlO43Wv-t(8edb2Us4RCIdn@&Fs$AaK{a1ZQwCFEAd`k?QUx3Xouq3DG
z`v3I&0>OB27DyUw6K-g0&}eqE+b2hz?VA6wx%${}V}XKvE5G&K4&HgW2G4IDDBjsw
zhj-a4_Zgg&98)s-PTuLtX~}v$$~UR4_H+7h%W{YT$7S>J%mQzv4^X(Ve$$2Qmxpr_
zQ+2yrwrcd-p!<VXbZj>-Ylc3@)x$%HKr(a6l$Z7zNo9fEF6z$ozSPA#<GNFXvwlpZ
z+xy6S$(eY`(dFaC#d_@MzBu;m<WLtwV=gpke9DB0ZAZSAp46&t9)f?$S{vqgC=^Hr
z_k0lZeAc{ydbtTXQaP>a6_0!x({=oj5Ve@zO@cZ|HpMe)M~Y`;GIF@#q<m$Em3~jI
zzVkc3D}$Sm8PM{W*HyL9&7-{0`Ffj=*Dxcxt5wm*I~SDxZu1a~??UG>vV+~dh7yvV
zC5_w1IuG1hQ|xtee3ua^0~#2<I8y8W!Gq&oPo{WBv=4SG%00Ak)9ZlPCub`MXZE|$
zA~Nst9j7>}TZwJs(0O_c57z?8*z_AEE1Ys(3;j!5re$sOowMsyoaD}V6@{_&XRMzp
zL}zdzAFnKbb*ReV551HY7D#S=XP5ol{6g^a<^B3^NOC)~aPwAej%&}C$3fZ54xaKd
zOXWNQBagXqOXL^LyFDPfwO_=O4!1<}8Vs<Ybmum!cUI_e{!C<u;hk635j{Q*JF9x=
zNdLP5IWCKzXzSy>B7{Glrny|ow7qlB?z*_4ew60Jk#dWEF+Q|GVnmk}@!N&U_whoJ
z%*UISe<$LC(5ma<PW^K;n`kU(7PBxfuG5sDi)s7i59bu&9A5JAlEzC_1dVAsZ+=|Y
z)V2m|a-aICmD-(5zN+><>cl$JM0>oO@OF;2Nx!x@^mS3r%iPJ1SrfZF*nVAkjQ@R)
z{kaF8aZ)WXFcQkgvslz`@yR$gUqMX;o3DV)S8(lgmj}+4!4^}}@Gg&cE`g+ft)=JA
zt=Z8k^3!LR1*hq>OW8GYfYP=R8&A3FB=#z6f;s*8c*e<HHl%jDJmFbYweR!0%F~8a
z2gGWRHGSCEjLlbIWMKNv+5XpKiF?<+*A1DkreZkY`IC+D)43P1Xm_We^8?QZN*1|n
zz5;)n9@`Vv^gB4F9OJj><Pk`2NYgmY<|~M85@gNhEAXq{KIduFt6w+m&1|2s`Haf;
ztFzOV-OIjWQ(WW+-61*)1(H!cWQA<Lf-n2S=ArXcASu`~x0cOUFlvU*A~s*a#x<+8
z3QAL!`?cC|x4hng1)S-MSe?mizJi5SVZoI>O+WZVjGOFj+CweYzr)ygonxKCD+(cI
z*^PU(K(ceh*a(?{KG6z0^9tB}1-&5l5$KX#TFj|Ul{?t+;k$lI?)JLg)8One_0s36
zPxn}LUpUIEWfbN`9K**eY8zO><||NAU2CgfTe4&)?pgaFj1x!}{8rxTZSKQ|wPr!O
zmn_wbpWO``q#yq1VoQ~S3%h42;yu2Ak7p;GU}k)#&8$hur839+w^zT`FK%~s=8|^u
zxf-(v37?L~7#=@vHGQ>ErKHt=bG`x$v$4P|z%0Nlz%0Nlz%0Nlz%0Nlz%0Nlz%0Nl
z@PEbvkTm`$^#2}n{}1W^LrKhw&<cb!hHDOz{$E)9t^S|P^0oed7{BN5{`;@$|4HNj
zNBV#A)BchEKb$|$e@*|d`RcPi{$JJqyNUND&H2yj|LsaXr}wYu|4EO(RlF~y_cQwc
ziP%T)_2=|{r2qd?kFQP_B*M3Pd>c_+B0WA;qW=*+emL?as?(ynPI`Pf{5GF5j9`dA
zQ~e(bk{%y*o7dwTfuzSD0g@iy7@P-=0*`<u;4yG4cp8M<Stx+M-V7uk&<UVCt|@bn
zt}WR2ldfK5m+$N9n;{<Q>fz|X>*^tYXS#Z&i#KADw#!z(vUwxj#BFo(aJk{fAI&`)
z7xBEUmM6!R!l^<axvW;%KU*{Hs$Te$3gyQM4l{G|ZM?^qtdN<#Yk=h#eHHiz@cQ<p
zXKwC2`oU6Xy2aZa9$xyl)9$R;Dea%Wdh&(kTQ4`vL|vZ6#|!j4ly7$abkG02>-({F
z`<SkN^e&Fef-@1*)#o2u-a0-YWnyq#@4-RIk-6}V5|CY(uKup-xxG5~6XNb(P;(mI
z74t2rl3fz2ex1m4^?wIleI~D~zh7h8ZCU&frw7tUSG|>7=qdf&AgOC|_hZNB?jJSi
z^84XTSHG{<?o+eY+buLZzrgr@-g!>e^yuznJlqZDb?b9yt925tkC0vxdZe{^kD%oR
z1`$`}W#wZdPsRNj-fh}5j+@QLD_qvOrQ*ZX3&P7Dz5yQ%Ee+;%4QmnORW^F<=*LSA
zT0=L-boESE&vf-sp7U3450hKxb3sQrWY8UVt@1q|oizI_z`GCbAp*(!sZ~2u<5HT8
zE1jZk@NUgq8<#n0w=G_pXcnKnx3z7oH2m=Sc=39@VigMZ$nLqF<?xKFp4WIl>-37W
zrZS8BhkLa-nghRt{d~NO%1a%07_5uXRKI*UsdtZ8700!jSv3n9$aM9O&6%#A>FT2^
ziyoc-#cIA*yTu=;Zg^ss_VKQnN?)0M(dD!4lJ4Z7qocSdU6(4UxdEyxv-IX_rS?v?
zHL7VksOvS|yfvj=r_^t2m$d@EQSEuX{Knd#_e@t`PxZhHv(@j))vGZ-8LyWw3Vqxl
zsCH0+-lI`TF}^XD;}Rt+Z_Hx4`r9va?cb;m%2O-u8`07>??9^wQ}!RL$8_}}O43eD
zSHEljKAnBt^CwE)<~V&`FaP6tCYY}Nfcl=-wkE3Y-NKlzzGGf=EYsEBc`!e7R?fwS
zYw|FkC9ju1BiDQZ)75W?i5MHXQMscD#sdm57mz^G>t-{P&`={O?+FEty9^!)yA5x4
zHqJP#;P!e=sd5{ptIuyWBRlqLO<2y8UUM&nM<lsi-?yUvkzwdB3E_3{Z{o)%95-(^
zb^E3^vt>dg=4Tb3TU(~XboCgVV}V(KS%6u9S%6u9S%6u9S%6u9S%6u9S%6u9S>Qiz
z0g@X}|GfU6yEiS~M{D;vc{y6SI=jtw^m21_v9kB_@wW2C|5n~!_ExqY9{k5Yod4hL
z^8x@k{y%vQ07LN_0A0ko?W-VZpf7_}@Bui<>%hNQ13+Y&&rSe{OKX!^f!_&#xgP+n
z4WLK~K^$%Gj#V7-k#z0<&e{O9MxHPB_i}W#b#}v25aMI~(V7AJ&~|Tto;wKf9*Onw
zls4)ADIeckGl2G?dH*qOIT!inv!<TbIHa`yY|Q}Lw;}Z6^AImjyf39k`u{&mkLLZS
z^!Ai~PA~T-)APr^!PvJzyf39k`u{&mkLLZS^eo<fPVeMTrdNo4!?5o<@xGKE&Hw*r
z>5-2CH1yoS^3Uld{UAN^QRu^o)(prO*Y)-|Mty9U7L%($UEeCI>+n$!RdW3NU-eV?
zUfr%+OF$EKL3Ax*?JeY=d>1+(f9m+1f*pJV=(@EBG1WTOMCF94pfk7~oCRX~7!LA5
z;d1PQDO`nXKy;A{H-KK?7LeA>Isl?>3J-yEz>}aKcnX{gW`n4c!p^AI@SPCu0pVvN
zOaz7a_X`*dz6C?UcOc4GSP6!Mx+wFdAl1`lpb@wNGyzwE=3pc^9b5}Kfa^g|a056G
z+yveLH-nb2M+|rg+yYYD6$_T(d@)QfE>~z7@cG-d3&^K}>Hw`_K=nWoEC<=z1<c2S
ztzF=HRDR~h^|xwnSWc@hPk+54Kj!As!k{@ZBl8@$bKDU4(Fi2%&vc0ITq<$GtR7pt
zK=(28v1rw=>;1z!LUfsrg_kN_9}gZc?5uF4pnKd>{gM5=CrIYaW<C~Vm!+5U&+gC}
zGxc%DA)Yhdca!s4@nTU`pTC2T1?NinTk&h#r^^M#Ig@V849>A>K5cfPan*YNjP0X0
zY2S8o^TRU+Tf2bySV%sFpD%Rj0!gI{<E2_oULBI&Kf2M%iBlBsTKW1(TSiW4HRMeC
z@F^2*uy!mT?^vR7wq=M;=P=W;nfGml65AgieROW_Yvuc9!CAexB;!GvtzE#@E@+Pz
zGF9H!q5UsA7dd3LUd?<gW_JwgIutK<i#6za>uR*xLLtC6aq$(onYDW73ab^ohvygV
z@mmvb+wt_#38%1@HWt1UNIGWcI)CV=)jF=Y!G`R_sqT{DrHM+iYc~gbMs(Ytm$Z@N
zCiC$!c1h=r>!~j>sGrG^p%-s2Epsj0xlp&Mb%OI4K}S#JQjQDc<E`>xJ{HTyF&_)&
zV-c*PZd>i?5pe2pl#4Vvfcx-15&7@8SPyM&Xy5VviBYa&J9J(7YIDN|uZ>^1tlb||
zT+k#KeV%;0{<Ts^2kgD9Z*sWj$0Iuy_4`F)qr3Db=3_D6N8zDque2B1jn~~gUsZqm
zc6po4YY*3^`qbC2Tyi@rhvRJeP`k!_EXr~$(v=5{@o1r}l)Br2<8JjOyD%S%?X_w~
z%*P@=zk*ZoAFXryL#m1G?b#Nmy`8eWL%PQwd@(KG!Y|c><9@*cw*pDYi2)xaZ?xZ+
zzVqBJ=3_B207Gj7$u7*tV(Sx)hRnx8du4f5=YV#1EuN}O5AIudufS)x+R>HF$HL=L
z&)28*7p5Gat9t8R?!9+YO0T?#nq`ob)MZ%7d|j^=95+&ruA|}7CycjB4QR}KEEHGQ
zPI7OC!8I0`1(*ex1(*ex1(*ex1(*ex1(*ex1(*ex1^z_~K!))j(f@y10077Tzo7pw
zhnAK?PZ*SR#2O&4|K~N<U+Mq9UIYMfN&jz7JO4iXBlZ7_ah{LF+Vg)!|G(_rXTAE*
z>i?UeTu57A`Nh7pW&rfrKlB|SeRUAxX;p~QrMzbUKwB>qr<YRsIj^*4z|W*degLH9
zFBR`g>81Z5y*JorBKC=_`kdb3AEfuCmOp_S00h!@f2HLY)mvW6&o4NDzf(P>xZepv
z45{&cBvki@AeMupw~w=%t&g+28}^fxZ%jMkcW>taM{8#{YeyGHS4TG=$mKbXbo+GR
z!Sr``UoU${(QnX_f90oAr{(9MpFb(CKXkp3mY=leq&ueooj$MS-w%?OKM91CkV^sM
z!Bp@7cnFliu?~aHz@uOVm=4x}8K49-_b0%H;7L#p%mfv|U%~O<Y0w-z15N_ZgS2kJ
zMQ|IK4aR{OdgL|!SHL6qehoYU-T<?~o8S!)(|QSeqg?NRY2ZDO{EO~`)UG@L%aDIf
zY+J>4pz>qd{0)~^Y>Gb6L(!|c%c23o8;W6tcg{}jKFfjQj`Qmpl(_e0>mSTpdTUW4
z)8;d6{=_Ifi{6h@_Rd-af1`Gyv6fx=S><h8$2Vy)G-QZ!Oho5-zs?!frn7(OF)60a
zpI*(h`FEr{oPKo+{%)#NUzj%kmo~W*k7|w1@-wg5n>&T$&Z&`I{=V9LeO{a2{m_Hx
z!<BcUuUXBA^3SsBaG~SPd)MaF4-Wb;bL<G6Qah&2XX_t?ZD!hhIgh}|W3Jp1`9<??
z4~TB<7xARStpRgA@ZvDQg0Azq&FY;MdYnHK8De<nm32gqkHgNY9y-$hZa|L9;wRer
zcrOX*Oz||$<x-~YoqKlI#SQhDHlJzp-?)Cfv#R-y`nwuNtva8uCg^BKrp<qw{4{6J
zd`IiR1e;dQd4+*0ktt@Su0za<TR0bDZNctz9ZA*KO5SACX{`10_3h^;>zz<P-fCaT
z-ldmRpN^Xr_+bU^z21DhJ(n9E50&1wu9<=Q_5F`ER|>|CxZ1JXC5<ahnyL;69fbSa
z0X|;Qc!LWw?7}{r%G>8z_2NWS;=^oTrp*^fGHpK7=F|1IzHMu1Bkha*n~zSFo^!ER
z(EJG(bEo+%8*j8~a_c_FvW?NN+MD7T9hsz6S?W{ks@;3GSFDlTA&I1n#`{Kdt!vN8
znD)-ZWEYye=ALQu-<upUdhB=6%hXTynj!k^w)2|%T+e0&l^ZsdRF>Qfw6+*G_<2*N
z&8K>`;mH8O`{Gp(ZZ+H&RVshD?=)Ga%_qAsZT@quf~66U^<=L5S-h*xMIZS9vP-q>
zC6hCWf}DGU?nz|azgcAUVEO|qt5L7x1Rfe1zD%3nV&;HjIpfwv2|qAxKGhed%@6E2
zFn`Pn>2{+Q8(R0?jWIr6bI-K-R!2s>z482or$)-8)b1<MKR$@+%lMca&#ZMf=QSH0
zw%En-){W<F177vmGTI@t9@FOIVTJ`}0cHVa0cHVa0cHVa0cHVa0cHVa0cL@}tpy+_
z<);4S^Z(nsdi2CP0yy@6Tl?RDQ<wMlalmZlCh|eheD)O2S?&NmF9knrq){f}@q6?c
zzTtJ#^`LV`p79%LoEwAR3B1Nx4q9c}zkf51vjyop#i#EWR^+wJHDb-Sm!r3@ix0=u
z>6RfG5T_@~$2okbW0_#100|ziTZWcb*c9I(u@YjKlIAHFYJut?Y1uo1`XHnQLOPEw
zAZed9C4PQR;h&vzv9J^Mdz9s`4pkZap_kIa0?DoK?6RMmUkHA_ykGwfNp5ErZr-Ym
z4Cqk2Gh<i0cdx(jLAsPr#vH2>okxLBMs;g{K5zXLZ`HEArz1G-C9j7_8ZT85G^Xvm
z`EgxS+ZwFNed?!HYIidEs@nUg6YES9?QuL_r_@%vV~h8NhaG}m&R&1AYWC$r)>S8r
zH}vhhzq)irnA5S@9B0lSFSzG}nCG+R4b;m`$dSrvRj+vD)0nQ~kA$ej^llQ=K@!IN
z**PHx!?@6O%vS3pTpuC5B=ksY^BzIV3k)Kz$ji#dMxKiMHN4xjXB;<ypIh*LYSqrv
zxRfU2N~dTWyjwHZ#$`_0ZHt#Cn#E`DZEYJX4gUc?Uc6qfScQT;vU_f4IXvU4=QSSC
zI=v#Tsm$X3;a+Wy=D^1L`FIzVmpbk+SQnwGe)(`x?;fuzj%ziuY8EuGrozK(q}GUc
zn7f{j*KW`DCmQZ$8}`qYvTb~}S(giYlD)JyO^)8vNTEp^<zfZQCC1P3x7STs(Bf3q
zkU!QNpxUs&EWj+lEWj+lEWj+lEWj+lEWj-Af5Za+q4$4p4>wT<z~ANlf2a8Ue<sS6
z-nrot%Ke7-e~<U%H_gBQBhRAufBO4(0{{L`zRL7>-dCAl|4{VKPkjLNo4vc6kC(d(
z?+Z=+0Msww&BwELMppoSmz2*3w<14Co{Qwu|GWkt#TOrg-+}rL>iQ2T@1p#29DP2A
z4K4<p6*dYj@!CvzYX!=I=>8C*?|_33G~aKa0*=LZ>Sv(72mv@1q<#iE2K6(LU8tYo
zpVps{!S^R5EpZF!xUVRr?~sP|EiBe`c+o~?^%0||ukY0Bn{BKy@F43?VEqZW09ara
zU>0B&U>0B&U>0B&U>0B&_=j5HKlA?Y_DKNncX|J>8~>;G-ul=kVf!fHxcpD=|CDFZ
z`#=8lz3|iH|9FL`^}q2R@9ReI{B`f|Hux+`59?#&GrhmdU^B-?f!@O@Z)%_{NblpM
z1Hh29upfw_ZXw(d`0;)t5JSPjksy{;6VmxWEAWqdZ?ERx+aIZnn$zi)LgSoGih{UV
zZOVd^*8~NuJ=N!Jp4t517VY6f$#eir2Y^d}1!e(e0cHVa0cHVa0cHVa0cHVafj_ap
zf9Cz)!_I5=-)sE;B*xn*Ov6TF<d~|H>)V{;^na@x|EE0vmE-@SasG6qI}T}$<kJz2
z^Z$`9zyfg(W5ZNQoc$N^tHe5j@96@*>{}3>i|8D`?OTvX-vFIAq~W|KKoKNg0@4hS
zCV;d86F|}m(0uZ3z{y}+kZeVofpYMl<YS->y@x>ZxJ!4ddB0U&pLx1jW!a{t0x7MA
zGs7m14=IgbY&G{r2Ij<IeG9B_0ac#`W&vgaW&vgaW&vgaW&vgaW`Y0p7NGZkyMNRF
z-^JbD*2U4v-_^$o&i+nbj#kcn2lls`;pih$y!*`caJ2m&ng>7`^8i>|+k5#~d;8e>
zI9j{fy4lX)mmK4us29x<&<LFD?B?L^=M6u8b$KI<*E@)oEaT%C7#c%g|7USTa|}3%
z=NNb+?qk3^G(WD7cWkcFK#nu5<@*@K*|B%`aCD$t+0VB2@bS{~v!7|}W$iOqN9P9-
z__+zFynY`9{5pZ;n?QXFAK+NvGt-%-2H@u>p!a@h<OA{sUW?!+&Tl;C3!w02e(NKi
z=AY%)+Q)Xr5A*z0q@T{W6w>}S-?WxoUA||D^KBw2$~XEbcss-2fs>>2`?Gw1k>>?J
zGBl1y^FaKowx+(AQQ|!2it~v67Cw*UkI@WyjQGhs;v)L#JT(2nZj=WdaUQJ1C(sLN
zQyqX#gqzc!<8noPUe;r5UFZ@X>h9{{>*F{9EA#zX|Cit^{}<A?Sc`V~<m<x!HpbR#
zwxa|87s^W?abE6;^P-CVNaI55)wM#tw|>ft*K7kmI}`Zx#-G0vzRrUrj%jV`<3$mv
z?voGB=RA1vb$zfnePIL9;Zkvpk}Z<J8eAtH)#7W@mfDIDjy@B3XB~4iT?VuV)q`Q8
zUBCVRD|<9YJr%WwqCP&#ix(OIXE!HzYibDby>6YuH|UHLwUDIsk(H-*LIV4X{e<e4
zNVJ>l<H%pbv<{>a;`kxIqQ*jWJo+6zJ^a4*?hcOD9%$mk=?KKXJ9>G!lYx{GHyv$*
z8s=*k<<r{N1C3o>d}=ooQ66@_PEL;4f#N^KZ<H@vdmmq07i&j<AFS9YJ{I*!(%-xs
zJ$;?M(4dL`N^3n9e!bt9SwnlIEic7i1F#d)`?8LxV7?3rko=(Lz;@Ug!&aQQjBtl>
zw52v3KmFPD*$02G^V6a_;_B$??lqUnMN&Q#2UbEl)DPU4KdvY)oj=tbSE{}^f65na
zW%x}Ko2U&JwUrxiZPVqgj*Y_cdRRvi%m697C&0S>L~ZH!_e&P<hq}n`ckqk-L~R-0
z56gX<-f8iEXFzKE&WiUF;IpWGp>yK+{ZP$0s$Ue&i{ruU;x>Te__hJ|fSE`?#)p~c
z>!oW1_UH43d3=P_cA$HlKd+JaEV^!a%^KGb`%`)8VWTh|@#q@224z885MAvwKaP;<
zs{=^aKk6QTya;?2U58kk6B!<f#7XxSij6`)#H0LZfpjkVAf3Z-kS>rhAc~hmKemvL
zWd^<l$Acfi31B-McOp0dv;e1pHlRId3oZohL24H$e^h=mv5D%Qs7_KjeCco32lk}%
z?hDfOj$;d3fCEAFn{(P=Cr}r}IdFO)nqO`ZI0PI5QXMx0%Rx=t(E2D*pY;A2DayL5
zb55*kx;rT|(0oXE(Yt`GxJylb9li1B<!7%}!IpfyP+_RzowA@g*6pkp&%2u7Cvi<F
zWJT<DpZe`i@AlsumVx@f$MYLGaieZ>lPI=6re1MEl`@<j8{?rzAZe!}F+M)NcaYYa
ztUc3}bb1Cnn_ivqZ>^6x$bgQwIAG_N_G&?6uG^3GpQbs!+10ZNjTC$eCw6~Yv3QSi
z)<vu>%con_%;w61wwrC7vfmiL?=JgZ;`YK@W9*LC%$HP)v458FE62U%<27z*G$eg$
zhxkQ3Cp&NHrFmcR(xB9xGLlbg_GoKNj_Pp$+ECOPf#i?l#qjZ#4Onx|u0>`4p&#VO
z#9v#uEzh_3=9OVR+i~5NMTXwgMy1T=<Jk!(m>HjGGiy?Esm$^I?bWaKi`$)@xul(Z
zuEy*^!l$^f8sI_}NM4SAV#n6eWb0@y&r~elX!&yKv~f+xI(6-{Xh)cnM^$WCcyzCz
zja8C4(YU_|sJ^`F62Hf>oUNm|%7(3@d8aVLF2bBkt;`!b^X1k5ZR==8b)foucGlrt
z_R4(*Cnd*}jJ}h1x^h~wUXSukYODR6KHRb#f_p+XAI~iCR{8*i8|yb+$bNY^CoxsG
zyJf3JzYV%SXhp|%^Ri~>b6h=jI$q|KDKG6clF9<RUDTcFeW{Cg#&xF%XZ@H+xA&3v
zk~8rTq|3*Pi}l#ieR1sB$)PTW#$0I7_>>6~+m3uKJ*m||)#VY1xACsPk8P)Xc#)p}
zymiJ#`<lj4tDTxp*?F+Jv3=*?=Ivh4uHcn=2-ZO7j~ASg?Vqu)#b6DCIE{fef;N5k
zrag5Pct%}#6WOVJUROMC+~ec<I+RpQ``GYxb8F2BiUpgtUJPG4cMlh6?%ToeeBku0
zINzon={$Ph^ZXbW<2!i1)_-dq&8>X8MkXVN8&1ksc3A26<mx-W^Sd&*37G*ck9l2H
z3*9`*+Z}7G^YI#HM0d3+`grGp(nN*rDN3mxos(22r><#csQLPwYV~$qJTv3LO(4mg
z^Enc<O}*#Sm#5mzDw^edbFYU}kKo3ytM^@g@t;{A^BA9QZ2FCo6;3&?h5n^2)3Ubt
z&e?S;PIBkGio)3XGuBTPF6FqNotLqFXF89AvY8z`<z<%s@p_g&t8w_duV?wQ^E`%j
zA-h;C>bLl0ocx7GZxt?AKmB-S_wE@DI#?aqHa+t8jdf)nc%eDQ$6GO{xpjFx{WCX4
z$>e!I>g@jd$gCbmq;;nrbnn=BMBn!tIj)?Kck0>d8PD7Tw?4m9VKsW~BL9a*23z*s
z-X^zr$gUl$g4nv3e>@N6Vht*fu12dZ6ast`7hjQ^S*v%huv)=;cz)3yzcul;9Zw&f
za0<Rpco7vyI%elOf9R*xI<C0EhU~<t?vml9iAu6-HwSx0blaepgz}io$II9yoj0zh
zzQmw@CP#)|yuGx{wQ%P`-KN$F&SL}}J(Wv2E|8D6%IC595}T+U;bWbBYt>VX2O62_
zJC+A_a(X!7(u?7TUvOL;A5YdO(Q)~U{Os!$6IMDUv{=~VxV^Tt|HY_12};_IGtE;u
z?k*p1nr&{H_t-Zf-8CDG<O*}!3{kieqkb+qLpr7S$svtMbSOySWm_QGw&+rOw(jMJ
zrBB_~@A3@WwikVKJ;^T5W_!O*IJh@uie0<)@hZWG9(ul;d?0K2{zUB$`J25XPNNTi
zk2mY+oEOK6?H1g*yK7%p%`sbgmA{PH=2#oFN5(3wz5Z0Z%g^WI-KyNeoxa^`yVlH0
z=N-c1N~M1ZZqYq$nr4Dir+Tg1c6rWmX?#4k?j>9IlIkB@_i|Lt8wD+?H-r6K7`=JZ
zjN^LrCA;Wc(CZyrZ@=QM%(1UlyiII;z<1@?@|xJob8fWisVw(fAo^ALc#AXb8=VNu
zdNtR-EbDGUxl%<sTlbReS2*mfmy4mdYvr)vDfVXf>OJ0^T@pC?g<zFmh4Ri*$*a+C
zi%w3q?qxlP$iDdoo1Hpz8|RQxWr@z!`RF)h>s}`4v2`!09z-9%xU#|XS#vecB%Aj(
zxc}Vd$mtH#)lC|oX>{Rg0(aM*<A!QeyoUEbh7}7-yRmgI>*n82&>_39buZbvmsAhR
zqnvgq`Cc96W+m~q-mNwP{$>B}x|jO~(ebMN1FyPPb~H2nMQVVPfA~U!)46x|H>>F=
zJ$&%I7ltxIj=RIhn;$eVb+E)@_54~z-N(`T4=g8{?#Qq5p5&zAcXz+i3=Ce%z&S-A
zIl75%=D-*GR-C`De<E4t-G`kQuUtr6b3@0ZqS4BG)pDrIEHDc&3or{X3or{X3or{X
z3or{X3;etVq!88Vuhsv%V$nNi60iEW`#C!}l4A9LW-fsLrVoG)*Oa86+%1ebP}q*G
z0k$pJS`Wm3A9$Uyle3GDqnEX-9c*LoZSCY@JHz`=w5%MjF(#cahW;TSheq)WoiAy0
zNp~pH89VzpL!>J@qDa4LDAqnJO482g6TwEuA?=|O@|0AkMd!88W2o2+QEcY!lTmC#
zQEZ4uI$J(%eEueUl{a7faVYX;Dv}_7(qpUPcLzTs{yZtaI0eoC|G9X4N)L)_k!G5-
zoj%y??LPgD*C9i~$a$iox_H!OjNgUVos*uF-^YGt-5>dVNY6`l5g8o%WU*mL7yMbf
zELxwDG|5lIn&jmWaMtO5N8;F`auby&=~AgoF)Yl7F3^e6_pTr$65I$d5}XKb1}#7;
z|EXXZsE<u#b5U8)@#^EZe%L5DARd0=b+M4)aWn9p(((YQ%sjzzkm*Eo)@2r~D%g0e
zMzY|b;Np_P@OksM$(8Oz9f@mA{RVIJbQ5|zTPjXCt=_Om<@L+)X<^qcNlB!AtTxDr
zS=X%x`XTsuD-Tp2YaRA3v{2LB-gs!gnu&X_yKZ>4#oMSe(}^;jsOHA26}N|8s5XVZ
z{cu~VSC<VOYfcVbF|nshj}WOXzsM>J%P%gNch2MP(ym48i}$>QpFlf`r~CGzdC1Ta
zOEYu}I#0_lG)a48JA9`m(}^;j=;pAPi5)8gN8Z|UWqUQoDYR9ozC5dvDC@HGY2uxO
z4Wq^s>5bNTmOK7s`?wxVCn~SSbfW)BooKon)xT4*8_zWvTwV1+yYza<s;BR5tlvcS
zt#`KVQN88|2CGZGVLDN!6CE(u<IvB~g~fEDOead~kW2BpPU}e?RSi9~Ui+S$D-*2$
zve(IH-A~%s-U$Bax2ISCKJz#H{Ced~CmNVw)5<xoFi<5j#jMnIh*@z9=R)`p@_JIK
z`dZ1GY&wm#e!jl_{A9fo>c?B{E7`mBlIqiO(*i%Nz{|KdA8*g)hQ~vtx2<btpniS-
zW6hO<u_LZ_>~=}xN|UCl140McaohnuUeS1i3p4D(KAg(i=UMgQL{#F#Y~N+$uAT1k
zz}Yg`VoDnPm+>woko2#$^xU~MJ6c74`s}jcG@W)SyG9OB+BRb2DOa7uUS&-<&V-L=
zoZMwYYPZW1o>f)*KEJCxZAf)MtoB&bhkecRgU5_oX2@}u_;`o1ed;e8xNN1obV`KL
zgK<xS_a5|n(~0RsGnFiIJ8_Gi?N)hnvWHgRm&LAQ&otLlS{Jx%`G?@%<q;gWxEGbj
zQ-9kz8l%m&&x~HWaqd#(1vC3j^v>4{TVQVHm9+NsIdoWL^6?6+tRAZCd)&`CdTvdV
zYuW359VDk(TYXO5=;Q!n)1uJD99PB1+w7LH@K8#xf)}&(3f$*+dKKlwbfRQurW0j4
zQK|=3YCfH|*MIl0&-7w7?_pab`)W>#JrQ8z{Y%^{LDHd#i5#~LoqPgGy~TG|zP$Ii
zjr{I(nPJx-K9jq&>_S7`A(oEjo!c#xJ&V4_dwe{m6ScV%(CMzDy6LXeF~dsGvp$^H
zf6gD`7`q{*)Msh$(KielSPWu1(KyTrB9Oe^zk1M=%o5erjTNO&T5g@dbfPl6{*&oM
z+YafRS?jZ~_DOzRe2WkaAn^LnGh<i0cdx(jLAsPr#vH2>okxLBMs;g{K5zXLrW2jH
zZQO_j!Ls#buCyr~ew67%seNHOQ4G8NBg21S{9io1l$WCuzW|=I+l>DMa{$)OGxkP2
z{x1R2*zgBz$~4w48vnPp=EvG?9UQDbn~5scAJ1nc(g4)WXC;TRa}OWvi;071KC6*P
zrx+WWcCPhD(in)w(rNtL2cPXR#n%je_N&ixTGh=Dw?P6C5H5n0*RvqyH5cFNarMM`
zrCGPcnMIs`H=pImSQL(rxsJFI5_J3@=d*4uJrzkrM(B-=#>??a%C$#6w@QAQPq96D
z)7o46IJ-JpqY65DIl9?9it>%!z8Ail$L%1Vr(8t4^E!a>Vhu&SI1k1+0_6c?{hR=K
zXeRZYJcvvt&V;j*wXfT!oM4Qfw;}Mo@TYkhE6$51U9<>f2g(b&On7_bf6pFXjxLV2
z-YCJp&L(xbl6-MKnxHVL{>Xq-e@^oCu&(}m$^buGD3uAK{@eAaAJU|`1gXCF<Ll{<
z>yeSzZg0p~2zl80U^{`WE%IygRT+w=#k2OA>E&qq=_<ucdA59>1=y!9;8Nt0?$<*-
z(dWyp5vL=ci|ei>eple?%QvXc*K>7~vArod{<r#{f7ANTZ<=+#Rr7h`XkV)K{JvlO
zhPNS_+q1s>=ijt>%}qYi|FVscgWiSa@ry^FkB5%~U#IKZswgTng!$O$qdztk*h8Ps
zV?FT%fqY|wSqz8!Tf4dABAflgva8c8DN<V{YOEY^Xg+_WSNfbkZ~ixGtFEhmZrAGc
zH}QxoYB$k#p>C0023^WrG&TyD`%XytRsx%X${;>-DxfOZ9;9mnpM`iG;E;rHIM@j^
z17Q;3G!QQP{5))M0T%}0I|@O#6ND?P5JMguj4iwg;uu0q1;Al?5MeP0R~8|)?}NcI
z5Z$oiwo}xmQht#q?jAM@3lNX;8wyfB(7h(K2A6=|;8HLQTmi;{tH2a60z3^uTO_;z
zMuC)%O`sI)0(%JCf-xY?Z?^?B191$YBe)&(1948mNH7k(2<`=+gZsb_-~rG9ZS+BK
zBlruL3c?1$BVam6_lOLT&Q~9ss0|ji&EM*oXuiAph(q(;DS|ZL9qF2I4-it@H58=d
zSYQ*iqZ~)=D;)>_I1_9X%n^@{GZCcYOa|#1gMU9iFQFAk<!lX7Iop8LKHGwI`4qK{
zqBir}eBvI;AKw_H<BtX@pJPEf?l_Q+a~PYbZR0p<^XNDfKLHzsk+2JuFV2CV4{#JH
zkMB4SA=QJiU<Ys<*d0V2<mWLQ4-Uh3bI=qd{g@Rv8Jr2iK0+UGD!3fP--L-E>W=Uf
zXa_z99l>|t46qV(2B}S+1ycS|kHl@As12n2H^pzLk9=s1^X!99I5*yoa-adeHv{Q9
zQ2=plt~rQdW3B~=y2`Z#H-oLg-C!Fq9>koB!emetL>=NffT%-UC-4N=8KiuLV-vMG
zqPB?gC5PYUW22Cb{F7ZTfeK&_NaddkwgdCPPT&;~*D`kt#I?)a28VzT!QtQ|5H{y<
z?eN$8E6^9;-+=yLDOe6NeI3)+v3VFLKOFh7@A5f|ZA<$UcvWewD`;IW>6(Vi5yj0D
z(V*3+;Q3e5W50YSPS@N=?{Hp>=JOS4_i9EzJkdc?QLBHl)AOV4al^7`OYs!1ImTB=
zlxdroPpnv|uzpg_c*{=vqnW-gsNshpG8=8`jq9Ix@Q&fskl><Q+7J5qy=+h#)MZnH
zuyeSVw<r7MbEgVQx<<Bs-G1iqGqySJ#|0_gDZIY*cz2Ch7u%wtXb3Oy@tD4j>FcPz
zgk?8><<VuG?9KP{SHEAjF4)qj{BZifS+9C&%-WoNTpuq_(P|V=`ZUwm{b%Q4Y~W6I
zezsZvgHokuW|`DnFQe?C<K?F>AFTB#C|pw|U|}2A<xiQuj_K=|zK+eqSX1HQHBxH?
zUgEBHrFNs;p6yRG+{-rXpDShi{WUn5zK+eq$n<q{wNiU0+Zxq09n|%jZr+;Gu2br_
zwaZ$84wUx2=sMb18}#1D!1SH7{jbLo_pW`f8!}%_#c;s$CmZ9Zb1!1iX*7k8$MkiQ
zl{aSj+w|C;u%_R^G3X4rr%CqPkfw3E+HmzcmDa`YG7mmCNFDHAN?=~P%Ppg}$xF}T
zZRi{7P4SLZ>1bcM)z`57$Lgy5gF>}k&1_%TRvOosRs}c}E{_|8K0rR+a;=yiAD4_V
zcORT{<wKPH!=1sSKb|>vw%w&wC2x8zIH1aLS$sUEuVeZ;s#i>3XCqK}YTtWY<%wJ+
zjYW9ZzoSKVId^Z9`ug+(jUqx{$_vUS+3fN?yLRq+O_g!=7G{}5tU`yf0tPPxk~6P_
zuHX*z?b7R@V|ddbr?Ow}F?}7`MXha&S4M*3SeH#*FU8BQI=HLy#>vd3$4jS1PCKjG
zwQ(`VN(N9orms8JQ#Jfi>JGaE_j?P_AI~v;-K(ax%Z!IJeH~pNL)tGW`R$6wn#IQF
zHfac=vVVOW-ZlAF=K6{ppO6<<x}d+f1cRmmN%s|d?lOH{uYzMfw%Nb+-xP*1KRgpL
zeH|JU7MKN?1(*ex1(*ex1(*ex1^z1*kU}a>f9?E#Si0QW6AMN=J2_+CHIXcv_W;o0
z^yKT=U@dyCIdqXvJsN)E7-xGgcW-wmA3>M#T?OMjpx$;4fa8FG)+Tp$!Gg>RoVvWV
z^&ER^TOTaYZHM*By`g_sm!IkA;(-bEzW9~2tm^W%J}yXu_MvsXy?r2qw|2F4!|Zgf
z{36yA#~XUsM&M*;HwSk=Z)ncc<&E5Z-5~aLc89=?;uv6ky+4m*A|Is0aXrNv<Meu>
zV#7}yX%<PRra6$~PKq?OnDoznrWbxA9X;@!AoxlHPV?SbW4b#S1Njrp_veYdtcQy9
z{DZ~w4%$eF4iyEoz_timccdF3&+F5%u(=7ZzaDGr>S*NU?mEoT$rcm-@%cy+?fUKi
zL4EKGX_`r&+me%jJw@{n_U(!EJ-i)B8EnlfqeU8QQ^d>a2>tx0ltg(n6zB1&IFHcj
z@%m2a`1m|-mHB=iO>Es}3`KePVDWCUSL1JUDEiLZ>(BB=dg8h~%#;-Ev;=_6ki#n&
zpNHJ0f1C$j@tlT~2ioU5;ivM@Uu=gOaULjbI$jXA-YBd5=5={6^>W5S<a13NQ42+N
z<<HK&PH){GHOj+&CYg=TGSwF<JE|}CGf7h^D_@T9KKSl}Lz7+V>Q6p31PEhLX{r7U
z0w<#nUf77w(-%cC+|Ae3)XUv|xIe`wn{1#DzYl*{e?)URit3}dYUBDA)osX9KFt?N
zztKgafX&6!*2~tFKFi9_$2s`-z`U0;?2REz=j)|Ee*0d%q;ssBoAV^ji9%0YqjZk6
zCODm=O|wtuNOt?`1o`V!d`<H^fBx@3c7Ba<E`3lRzC6E%e{z0x^~!}rvIuXn(Z|==
zdg3^m3jFy|p*ebcf1ah2&P`nGi1}6csy<V_a`C9!Pc-*t-Q1(!vpLmAs&`b+oa=VO
z=P%2mv9u^X3xLWOT50|o&=g$*=8oPz;wGxD1rXIWCDCr*{{OqO`0|?gvOS`F7m_Vu
z7jI*4_x^pgscuuV_*MSW#rdOrku67H)51OxzsujJ%k6h<`WLq4?fGYUqU)RNWk+W&
zzWni(uiJDDe9z8g&$_Y?7dK3?h)W+ykFA0Ha-z1?+{@O@+XXj4{zUOJl|3EzJAuz@
zoxfQZ9K*%K+}6&;k-zrp@;TFa23izRyHCdn!v*Dm#;5N1)Yi~Et9%{6-@j^m-2M3P
zb#=tv)q}TvonO&%89Flci;2#K{J+$Yk9@ITipYoVdyg4Ee_kZ)ckwWGquN|omwi!S
zE*|52eZHu(RAzL3^ZEGro2dHZzW&AeeG#9IMd$Us@}hZWjiu>YgkBQ@b^7ik{=Ny{
zsXWW@H%)A!=LO!kh0Dc#lWrO6*eEDSi2N0rgY<l%2-1G~*hKex-baM@PoO5RA2teG
z5Rclutzc(xC#VDN2I+Yr9;D+~U=!Vwc}@NA{4o|lw@-CU2-2~GKwB^bTmgoIG2jX?
z3tSD-y?zZy$2Y|$y5I7?FZ}W8avO$?f*JBb$DaVw@y$US&;s-Tt-yKUG%yUD4$^Vy
zZ=!ps=)O*V1hV+e0UHH<Nzri)z^3><3?zFD2U~+9KuT{UNH!P+(s_*r$rr%{gbxol
z77PN%ft0R43RHBT6x}~5-R}6^1;0~B!g*6VsbB~2C};;}fbQUNa4vWXgijB54utOl
z2Ok~bb1)lx16~H<qrqJT)xn#fD~LI#g<jwtFcgGKnh<Gl`5^Y;9)Yb<haQ7%z-M4r
zun^P+UxH)7Vvu}7--0RNd$0_w0Y8GZpbRQvJ=nV|C<VfnTm#SyYy{Htl`I$xHU_i7
zCSV@e46G*w{}E6bYz6iKl|T~^c@(Y#kw@VMPyi-^s^EE04Q!4Ijl2u#`9uRG`_IHC
zx`&JI?PUK(_{|C%1s}vC`}>0(zy+Wk7zC32gF&)?7`PS;2Ook<!E$f~NY4r@K}s(P
zo9Lb@y4O;A&GFk#Y!osOkM0>KLGnjA4H|=IKvVDnI0?)KZNST*BZ%vqpGW!{xDMa1
zgB!pb;C}Efcmccz()E-NUIQP4cR@T~3-5!4U@`a-q-TI)kn&Awi|((YYn<}^<#mTL
z7Ahc4ebj4e9~yv^f0Q}z2h<20iSLa;x-T{X>A3Wp=)NerkJEAK{PnO==zw_iT^*$M
zstY(6L>&?ug5ALpU=NUv7miJI-{O7P`1U~#KhZTvVHoNmlHiO$x{gPHblg#(I%op+
z0mp!2LGs@+2TegI5WaCj7jQi22a<o85G4PyV37RF=>BN|Qhp-nTH^0LsFSG2bbh_?
zJ6&rO_TloU{Gg14R1Xe-UBH7N<s${8b~Y8HdT<z|@;?GnK8}O_U?xcI*=cY!cm|9F
zFM@PmzYNBMSHTnD4KN!-TOqs!-T|?355VW(W3Uj!XTBc40BiC6B`Afwmw^4ix8MvA
zbzSHTz6Ys2`3TavbFjmDP!fy*>w~*M_?8J1L0K>hB)_qi5*#NF_5&3_U6B04&_;8u
zKu3`L!=k{p;4dJqE#ALS0G`744q!E?4%UL?C)Nsf?*`JdKz9&%Wqw*cnV%N((_(&F
z+Kzr3vrEiNTNdG&q&>CKYH1CUcFNeT?cD9c^BOI^aV=sSKRhpMt-Q&zTd$9%zYO6x
z9X?*qo}JAsKNzWNy;BpYJxjb7x~r+okj48S2Odtm@IufXPOBb#Jm#mha>njfPqy5y
z_Rp@>dfEifAOf<pszTdC=La@;H}9&U9Jf2Ni+wL$xmqpPRk9kL)x+*Cjl*+*D#cr{
zTBommNo3zCaa%5*j`u#-znb}JkzJUdR<d4?@=a>1{hU7BvK(T7XW|ZI7qh@y=>rsQ
ztlxAY`{m)B#8lnxmaYD?ep(ydDc#|NH%SGAbun0PdT_U0{@FFPn_HNEIDEFfZTiQ6
zHjOvp;pq?_Fa?sq8QK0B`&tavFo@F_Xd`ITcW>HLSAl2Lg*TC%%I9@mh3kWl=j%{X
zG3{f+*UhapCny$d+Ilg3>D)bBpt)}c!}EdDx8i)8cBJF=zUTQdF2;B8e64-GcAuKH
z-fp4U`31)J^Uia!rbl-t<Kc2JA8+n#wNAqI5z<RSkF+-L5wyI(AmWO=tbA<bskmRm
zyG?t>akKe&h08j(RD76vL3r82H{he8rNO+eVJ%|3%0{mp{dmbiYdkz{<>MKdj2vz_
zDPP%PrQegQ@BGg1%HSqs2DCipbyY2N^C)lF<Tf9#VMcUUtD=v0E+{cSE#{}i{Ir;#
z)?@P}Hc>mm$2$Ags;3waG&0k7ED!AD^l-wZ7sC(ZMKcZ^2Lef1qeRE$FY>dmS4>#R
z{Ir;#7W32EA5&b=B$(q|HR<~3Un_NVz~0OHCWm`|JhEd^zh5Lax=U}Wr+VOp+3I)Y
z>ec8|<l_~EK5h_HJE%bK(Ws;t-x$kriOf%n?05TRuKgSJL3wJ$eIr`h<{fA?Vaonv
z^<tX@Ss#&jUeW3)`fkwyhjr<74!rI&dK#D0Xx5`v68C=1eBk(7qh=TOruLn^{_6g6
zbh4%M@dkcecI5c{-(u$4c0V|x=Hr0*FLw5v?35cePv{%3;=AD<$5rz2etkFoP1zi7
z|3>9&hf`wIq|z*zpBCAf`DrmfEvg5*n#jGoT;ys$%AjP^dY@=TPsb`pmxr&Wz0*Bq
zvh*$~pGNY2RclI>YK0DWKU$8;Xgb{e%<}bKC+ydo4Gy-Sa`NiBU0rH8&X<qJ{Irzc
zDA_kO+}8Pc#%d{PH;%hDknH?2_uWP(=@l;$`d?pLGHSWzStsVFMRw^kdH>RPdKNOr
z$4qO*{IufQVQfj4?85xC;&x|eE@>y9t1)|!@acGrJr5$gOkXWjDQT7LyJLO!q>l~f
zN{3vlxqI$9^V7m08w<<=%mV*d3rOM2oc?nCzbCH@clUF1ah&7mBA)&qI^2J*{=ZI#
zsSmvZ1#RddNORN`w8J|iC*U=>Vliu-#8{+PY=}7D3BS{{lC}^-0i0MrZSU+*r=Aw+
zqQBJ*t5JMt5ig(*|Fd4du2e+IebRYKA&wf3>w+UvK6nk|hd<UZF67Sz`YC9qztr@;
z5uZC9gz{;FO$X1Z5$*YNCm#f)K;8#mYkDc}cLJ}S;m-ko{IhfTk>>IypFZ?oD2Ffe
z8wxE61ubk1u;Fz0{OYTIo8LNb2~l~`HS?YD)A=Rc=OjK2Xmju`M0u*y;SUra{2>w`
zyO6GnY`C@6w|V+Pl8-n)()0cmb~IL^JpA5{h2lJ8*o)8eGI5>-ZNHaikv9e9w=v><
zC;YS>e^l;k`1C*Lx9%F9Utg5!Jb-LW8Zh#|*xI2kzyCe|i#p$gXsUn+t6@uOH-bQF
zH-x;+>wQt!U$-62{)gKR?mKM<wI_e1fBq=0L)3QAbuhQJs7}>=Z_(!Sce*a>%4`D(
z6%n9)<?Zt;NcKq*)v-De{wL#5{rWq$t7NY~vQ4jcU!Qwj-RLK7AXno2>ElvtgHT_a
ziRx=zqdL;j|MUIeN7vU^z6c(lcm399i0%*MGxX*C;mdMS5^MG2kteFcJF)2@Z$eQU
z`j`5gP#Z>V#-H5_=)CIu3cmC`p}LkKZgcDETAuiOofcn0?fdpm5}zY!UdjGO*y12K
z)#T&X`$Jz9aj_xxSAlQe>ijFdv@88ac~?br7dWNR-S}HSiZAb9CmV^5yBMG>24fpS
zw*Ote>Mjq_ed5b@7tKsv_``frJ4^fcVEfiTg~|lCupgF5T^(}p`<$0QYrpIKE9&f1
zcL%0&JoZgF)wL1vvZ7O22$1cmeIE#W2t@bJ@A|-eX$#Tb{QqCs;;-<5ae>bZt=E)=
zGTVuK+8~($e7;0wOyw>CLptO4I$s(3UgsM_<zBb`PZ#K~DD0IG`A$WH<R9aqNcFdF
z-JS3G$5_M9RrE|w`%@dyg+BZ~{O;MauD<^N`pr;%A^)o%UBk3y4b`_VuVJb$#rXYu
z?Poju?G65R9?!a;PSRTBqe`bo^`>7-(e+KfHuQb0_<N-IUUWqKy{>(D_{Dd!e;JM=
zq=N}W$DwC@(t=ZQP+lpxKtoUWZ&wgfCe97)2fBmQZuo*rK=MUc3(f^&!FgahNWKY|
zLGn#_1(I(9J#>+80=-Kt0x2J+*hJ6OBL9|ewfrWCN7uj@usI0-4xv713XTEI!O7r6
z&<30Y(s5CZIMMU3=((7VOKn7VY!o&k9<}qEK+@cA2I;vOb&%hGCO(UvRrz%{c>7Q@
zWrd9btr0@`QU)nsqyZlSk_OxbY!A)>1>km&wBU(g7w`&5+HZO$?g3JMEwG86Gx_y$
z`1I)bCfFzxAs&5y0aALeKuWI!oDIGK{lRiD7<>oP^J@i2$G5>IdM*^TCu9$5Yt6Ay
zFoMql9iM!Mnu6prqydu8&{%K`NOmTlAuo`8hN!N<UxxQR7!Oi9=TNqyXFbs~Af?kE
zzt{PblTQQHEAnZedPQr~P`x7G2C7$+K&n?$K&n?$L8@1@HqJ@V4upQ6!+Jo%rl1pu
zvfyTdTHtJOH0TC8gYF<cbMONYE(CqSWDveiyw-m%NY7&P!Pj6Q_yJr1;)RCy34`Ac
z`A7%_;9{^Z7!DeOD?#{iaZz9_2>$}%K5zp_J^`D->);j;ek|NpuoBz}!vBPW|A9~m
z+zoaH<3RY4aC<>>a6jk)BG1Aw@F2JvOaZrozku68_(=&5fycmKLD*Y(1w0Pk1W$sp
zxB&3HDeMfM1qXpBFQGAb9<%^+!5}aXr1Ff%CVDm%J+o4ID&V(hY!n*fdZF@!jrj7E
z1F1a8M~cc5eiVFpl1~(sr!q+8*%mwol26nVP#vrXyLSW?!OkF+EBQ#Fu5jH!D$iaZ
z%7D`ZH-Yfa5YjWW7D)N^z$SX0MA_go<(F=!4%jG=?+$+AI)PNr$#<s@*bN*8k`E7E
z6Xe6=1oi}}p7#R7KuwUIQ~H2Q!M-4+8;(u%tSGV>r7MTu=3}Ffg#0xC;g81qA{_!p
z;QL{4G<Xy=1CN1Iz;w_OBp)m~r%Z4;2)`0x1o$hs2E;m6!fhb=V(kPkf|MU>Pejjk
zpM9C=yzAPNhloet^TB4|6R->T4AcdmgVeqhfCeD>Vo`Y(fpq+t*hJ4~{Q6(NYahu6
zi`o}S*hdwV0=t9K;Bc@ZXbh4s7M-^oI2UXR27>ZnFsJ}hdUVdB=O2z+h|gqSD!)){
z6kZ@ZbUrUZ`n?2f1-=1sE9KWjqVsr*?_~FPAhl-|AlbPRoCa2b_8|EVxq;Q7A6NrY
z{yu>7z>gs13+;&bc}4UbL;0ffbiwZwrXrpKI2~*Yq8{>VaXEsc@ZA|454wQ1pesn}
zA#MJ8@dCHtJL;hDD2RKCFc(B#g!jMz@Bz30gblbLkn#n)@Yhi|sDZqot_u5uxF-k)
zf-Avc;2IGAXB@6gA=+4O1BkYi+X&7AW57A!b`WhMw*w3VcY{a3Jzx&F7rYMc2MfUi
zAhoB-;5#q{tOXB&@R#I$#n1+DC-Hp%cov)ho&zU?7ePEz@M~rTf;srU9?S#jIq?cu
zj`L(|TruA%<~zlFr<m_lwa?rL8I|R3V{fHiPL<0WyZ@^1h!*{&hi{2_P^seZ3O6hZ
z0q&uaCD)I5S0@|1$-6fsy{st5^<3qGF4-+rqi@Sp9kr<0cLTo4d_0RaQ<@y#;~LRw
z_KoxzQ6_8OFJQh?WWTXbTOPbJcKGGfSFN6<jO?2>x?k-k?X~lrZcdb`xO(_KZrGjG
zDBg>LBKgNtBubPkLgT0O?zn5DoQsZTNp)-wW0|h<$>F%kPvPS+->JWg@6=OwDz|R8
z@}joBJ3U6@mdx2*-5s_k^ot%{*7fS<_&KX*pJ?jXiuq14-znxh#eAoj?-cW$S~l+5
z=`IhPErTtlq+#r$2i-sXYb`x@Zq1HXk)J-hEI3W4UCOSJ1C+Ln*m%lSC$SgvonpRI
z%y+7?)Th=}yZ3CbSR=VZ5=j}2_l@RS*PfFx?VX9vHO)SB9nJSqcxc)y?S*#ZbvMsf
z)!)8d-e&XK!?meC_4O;4+|ELWkPRP?`A(JPSfnct7~|1GSt)flIv8*DCHsXaNjv#f
zZ=drt>ea8C_GY%v*nCE1`_<WL%kE`gu_-RX`-faViWk*GR`@bd$*oAMrm%s@rAse#
zj8iseOTHW5@X)Udx~xY>qc$I}owrHbP8|zc?=%l^8|M%ZzCt*r`-gWWI$`H}w>E4W
zU5Y+RJ|6R(V!l&UubA)D!dqkPj@QhWtm~ij9!Pen3E2~Pf7_lXApwn!HgDh2w^=~(
ztM2z7D<mALdcSLzHrl^fK3<yIL6eMl!)@Nqi{CDfd1*T58S|YY`>pM9v0ZpY=P~16
z>^(M8Ti&(Ff~B4lOw0mfR^HYyl3KV6^XlnPJmx!fFd=SriH2R_bOUQ`<~ubhxm4zO
z|Mu$F`Z3=r44kpREWj+lEWj+lEWj+lEWj+lEWj+lEWj+lEbzb30#eBH^uN~sU$oqk
zy}R2SvE%<g+3&y4H|zfOhdoJ8jUg7!koqIld7rG$Ho@<_Zz}kmz-#L3eBb0CFc<A;
z?M&;O)%j+|cZGHuYZun}B#p#@MCpipMo3Fdnt45O0`T|YHQuHm4#`0`&aZbf0mPxW
zi6G^763Dc{X6H|{brnAKy}wnaKH<g<jfSL8?GV4H=Va$Cy)^GDUK*6TQ%3S>%^q!y
z$x%HZTJPBA=i<fi@s<r(bIz_sW&fcc<j2HcTevOHxA^9jVLjV%-Ihg$-qeNzMK&ML
zPB_8L_)MEwf7}PzK!wu19RI}5^{D*Jjq7jK+_0QhU7r4WMSjf9r-eatVn*gUZiini
zAJ6_whxpE=5+}^+ZQ53GXxRR1A(xz9sryS5=}t?Z74T32ems1<v;ztbOdHI!!Au)`
zSM}Upo%;!KcQ2?p4ad!5mnvOv301#Nbo0?EGJZ9wB+<~~VDRPmK39+Q*PM|&Wyj>?
zyiM>s;o}wb-|1Pipz6b^oO^3JWS2}$t(^Lyxsh{9;;8EB&w^bI;2*@tW7^=#>!S`^
zbq)6LYp783QHc3^I*^^Od#!FU@wr2*7d~myx8r8Ney$(8VD{qDQ}ZvqG&*P;tqA`~
zKHk|`hj-a4_Zgg&98)s-PTuLtX@3`OaCZ+nk9w;l=Iu-E)OkYSmS>6irxW(%=wE3t
zH2+<zpy6W;rzqe#iLI-!Jw++iqjQq#<kU6I3^iY$Q?1^vi?tm)k^Q)HK1YJKsrP*P
z@>IK7MYEi5?)7l$5#0E7^}fq5!Zu4j#WNirPwB#Vsg{#hhotw9ZnSdZ6vew%zJAh{
zkyBa?Ig>to%0wIZkMr@4B^qa2hUjz-GaZ|G-&QEG{qfO9=jOgvzHb(s)q6`a90iZ@
z@nX|&l&o;dc`fuWZJCy}&3DeOQ*n|z=T#KO)}OI{Dmii%^6|>@SBI(${?JQlVS(h<
zcXrv&%`XH$U*50(h9tK$3pa1ohF^DQI*)_0nH@akWtPf$1V$cn<(9}Vns<9ZbZfte
zCmn7vZ7|aYGi@-_1~YB2Kr*_r=+XIKtmbRATl{hAh9`DuAMcu}^p)8cT|V0`=}wLz
z*7WR2?Wsy?Zh-2_EIp<TX4+t;4UWA$=SHiZ%5uM9B7|wYmUnTceWMeBS+C~$mu1~e
zC|9aTe{XWc=&|2LFH=9+Yq*TK?R>mk&t?Uc8#a|xmfQ@qwiq|~c~hnhruJpSlL3PF
z#j76NYPc_|RQ_<^X|mgE)r@xS->0*$d;Ubp+Z?B_Me$Z1s65s>>|JP~rn$ZG(0(-&
z_g;71@NA2>QD?p4gev8!m^+7$C)hH#_E?IHr;pr}gLitkEP6a&E+)5INp!lZw|j<q
zCrpBHfR8t;S<xF)%O$Q_t{Yrus6=jFn8dWfWM`%gX4+t?2c09vM#v2GiB{N|S74BM
z-J$i;$=gS$XWqZ+a#d4J{UP4T9^#!#Ao+1~$;xMk_6EJE+|+KLTx5pkoO*?Uy27|2
z>Kn#JuT`<dT$;S*muZ8~IgW@Nx@1=IrnCtqW*8({j(2Z?WT}a3bog_h8WY=QdVNlN
zm>*JL+F-KFkNf4>x(ax>V1ZfSZ*Bn^|DXETj{nba@%FLx@%83M|NqHj|1?(K5aX16
zl&DSIKO;q1cXiH*RZVv%Wd@oL2`_pVkQH~S$*-d~9=-hR)hf)v$j1v6hAQ4E3z}oy
z&U*2@s|kJ**OWq5#BTSg-|qBo|IJ|;n6r(K=QncVM&0BlQ5!C=*c5%BhoV<?mqi1F
zHx$DP@0^|5eHQ!`kMr?L-1{nByb+VMUAFp_%^T?^Zkv;b%MCyNXztOti05s!JTZqG
zA8%Q$vVXQ_+Eu;qCl$(%6C7sd<lA_UFIgcod)ENVG5Q$y?9-agW9gZjdyjsw)R}Ja
zc87<T{_V6oD|Slzr>~xTVfog}4Kq<;X7TX?JrCvo?;a~p=f}3In%P`g&~~$pQ}!F<
z_uXaROWgkU8Iz5H+m`kz@T$^USJ1j%(lrg2BZ`|RVnW0keyrSMzkDZ7*W5?%a9)h&
z^A&0LYDPai(LqvCtADc7^P}w}F@F*!@DoTXUUQ7EkSNnOF`rnmP+|R~n(>yM_D5@O
zyjpR4=!I%iY0T-!$GdFcSaWjdiitg4dW1-A`9)S)SblNAymKCRmv${$U%Uqs6`HoA
z<LSP=XdW_j#L^7ig3i<O3r*4<*$&^SIWbDlqW9yJy|Wf!?p!|JaOqw7S><h8$2Vy)
zG-QZ!Oho5-zs?!frn7(OF)7{0qv7|K#m74`BOzc^h}jIwGwru6vTVKbxXxq;t?q0L
zoQ;9AF>wCAa5?|%4xKSmA9oz$IpcjdIj<Ej7FG3Gl2dd&B+Igur5ol3<>%$9$XydE
z3|5PoA*eR8&{=CaWtmU8+Ng0m`%bF$3F~yd8^>wzW7fkm+Wewapm|g_e|Y(*5n7A3
zH2kNIfxGf!;Khr2-yYc@D7<iChn7b-j=9t0_>Jty87U5zn%HU0$f}iRW8iFlEH(zt
z#=zMaI2!|JW8iEIJjy9pMcuaA(<9*2<0uztE4-g;(sNk;`z_W(TN~PUynkYp>(~xm
zSH9ZZu)%BNS1xPW7&sdPXJg=ci|?*{dGB!>`Q7O<!>&JkCU<Gsg@(FAEFH}|w_7NC
zwgt!C<LBEd9Cp^r#n9Wea@g<`d$W7>9&gSr37q^wu*$DOdFQF*)mTG;AB$#V;E{dv
z4K_P<=r+zFrOL7~*5-hdlRz>)zk*ZoAFXryL#m1G?b#Nmy`8eWL%PQwd@(KG!Y>u?
zJiqYqBqs)Zl)TY?U;55-yAG)Dd2MT=`ra*U)C`?PSBJXlgrs2&4L;t8x9c?&<e%(H
z=##wafO7Ddq{a6FPut~<FUsDxx$D9MZ?GoH07{pQfq&aS$>zsmW8l3KaBc8o)-C4L
zrpg`c`0!o7C3kyW?`d%Mn0o1R)u(%`x-T5%)iNp?Ye@0&irNO2j8VG~y0Uk(ou{q)
zJX*bije%49Qt(@OtGBriAJ&=$>0Yu_FMf76Y><BVql+z74leATr3lS?fgZ(UW8haV
zB(AxkV^Yy*<-KY-=tx*#7GM_m-(>+B|DW}5j{iHmIr})<x;O_odU;#<yZTtU+s$(F
za<p>pJFvgiC&%?qahM)}=>c%xe50qE(A(Kkal&c!hD9o`Uye@;yLL%RBJE?fK~BuN
zZkP-H4zDlxv8K2&KYnkgA~8NbzITw;nyfw3m2`RrJeyvfF>mRuMTvpoo;71ku|_8!
zuYJ3Lmjm{d7#=H=JYFIj{Xko7DCaON<I1ZMlU%jT4XdzrAkzadpLnJR=-2iB;T<8m
z`Nx*Gjt@wg7#!Doa8Pn&F4p!G&~q=-128=R)q|x>58xExtREBU_CE4nawg{7(N!nA
z#Kn5-=)O4i?Bq}vLt`#9Xne|qiET%|mY&pVpz897#M>N~fW9$-q}%^v?>pe4xVpDj
zQLzg|qY}%CsEDZaCMsAE6?;JhU6y4Ll(N7gcGun&dlxhsEZB)%qlqn6><yLJ3nCh8
z5dEHWX9k89a53h6^M60)=lHNQ=iYnHx#yl+=9Y31o{b!$V=s1>Zs}4!U}5F`CA-{q
zyR+LMadNv?fhUuS<^vSX2Pm2kP&6N)Xg)yEe1M|)07dfwisl0xwxV{^!kX3f-JMR_
zf7dZdfAGnsV@C8incPo3t-Jdyuj<x&PqoLH^o-7ZcW=9*`2a=p0gC1W9GgFMp=FIO
z#YP|YjGfgJ^BUOq_Mr3QXGk{Lm^Iy|oLp&4;LD#={7w(6e?w{7bxl&IHtCp;+?LUe
zXsL`_wEcy8s#V9!Zl(G(FBVWVAAtPOCHu_g-iOlb%r0M9|DaENk3^RTb`Ph<-f<~&
zDW=csOpKSLu=xs^<xYDZ-7Gzm(mbX3{+m}G``+q*%h$KV^8~5N+&sG1Fp0##k>aa&
zZdu&oIkW8^zSurJrs|>_uZnFNCFwdN&e_ZM`a-*(Fi)Z_qx<rDrK0%&Me_lQ<^!Zw
z9dIh{!iNcG?lv8IdUEWRkV_k8l-%70<22*g_xp^s-4hS=H0Zl($q$3dj4M9kaN6<t
zFP*E^nJ;(EN}sYCbHp|<x}y02U4Kk{7u7q^Jm$v6Y6GxGZkZP3uR2y}cF6I`h8e%#
zbp2&(nb#jzpDdaW@PF&uZxOde8ldn0{$Kh1AItnB)zPZYKK;uh2Mm_Q1cwAD<dFf~
zHUN^pyAME1H_IV*fp!W<M<?{|(1w+m8p>pY6*9S69U1H&tyV@!zQ?m5Wr#`{DSk?O
z;hP%D)gcmN7Df@NmeB?UN?E8pOg=yvsti-(Okcd~6s(90j|vaOPZq|jyC-|@6)9IC
z(kLNa4|!NXh_Yv-JXp=1l||S#O0_&VBuXOwo6?QKKK=B}D>y75JSK|8=N=v%79dv#
zhhxno(YWC|LBTYhhGVdXf1soiTIE<zU7Y^Md|2EiaaYFuqmx7u-<F*<;1VJa^$(EC
z9BmvG4uSU83I`j7lcSBTqm|OyL1F2nbhP!i^tTIW;p{As28Rs}9|W~20+fmncz5oM
z0>aNPDLX5G&LTinDls#_83jQkS2;sW4Q9V1@te*j5cn;v$HgM%_d92aWQ%()egkYA
z9Rn2B{tADky`_UwV4wndtyC&(odTTvZTzkOaejZ|&vI}irQ&ic#+~KR95?~|s;n5l
zGMSughz__=0%H_WvQYmhnL_2F2$Dxy#L)jTwS}Ntd+R`ZCkNXACkF>BrLB{#+)gRC
zv2su-Y^;?|4pxd57BU&d7ZV(2V=eQK4h%#_1c#}Wkzw)>S-{XRd1$ag7O9L19u^!n
zfHH^9kAOMkb+NoL=kq25))E#S5+Xxfp}}D=`2a+$iYEJyL|hbsF`sYYupco8^p4J<
zK=w*}AiH9)S{4``rVyT!%}MZ55gwqFsZfmYvkB-weERf>o<}MpqJtxmAlL>$NOY7e
z7c1eBbVf!w!wjCDlm;DgIz_O&Ll94ThUH;Tsc>A_dP9=P@`U5{9pa+0D-XfsBbhQ1
zNiaJU!c<1S8snLbHRU50=2bpnDoUIT%kgv%AP@Z>FZxaPE!ayC_Aa2SC2udyfU}^p
z3`Sope|r&3h1rc@FV>DIybkg}M{BvIjlaFU!b;(9<7jCkcd)YybV9NH$LysA<jj>x
z1=!1p0_<h<zsz1-knaY_BeE9@o1DBa$X+N+8-yWy*(wTCkiAUd=>&TzZp)=bzd3(s
z!2I_?a-6st;4Xz5%i$%>p|e;sv40_-q7G;71+L|5d<50)d0hX9kI?o7<U3HbKFJ_g
zjwBLEXGv*8dd3%uoLBIl&dxGfh;>e_^hM7J;lz5aR+f`itXDbGk~R|SmHajI%De1;
zO0VClEaj)yagZxV5>Bu5jMr<<t334jMGwR4wFBSYaH+uQ^*q`gWV&a7ZJSCYew<zv
z;h~}7VKU_q71~9z+>Jk0B?@&`02ht+|C()hVg!4kxF^<w|3>?fi0B!$DO~Uj^<Q)d
zoIBZ7D(vbB)^UL@np$tNU^T19((qgbqbGMNSD@0P7r3a7JC1jx%j_@;G{W$f-W|p}
z`|rfz0)r!?xHzf2U&da`oOE!AJaZK89^OSG{+#r<Na@`cyyIozc;uo)-CfRb8QvMg
zf3i5E&<x~jed3kssv5B4gXJWWG58(Cbj-<p72!xAS=%A1NZDX{2>vGf7s70TvbN*d
zUwjy9laY@jU6Ce;?l9s_1l?@VRkg_Rg~^~J9SF^Kyk@*oeZB?Zh3B$tVX3{XXPAcg
zREW<G^e%jSB>zQ(D^B`G%NbU|?Fa@MfnN%@mJb&t3U`VR$6Hgba1>SuPdZ9Lcr0a+
z{K|(Xc^@IXAg`F#5jMOSv|)`onTeL#9s(`Nl8X3jK^FnK**qQD;6c!F<&c>S<3Zr1
zGhaqjkd>~tC>t0ekvs<WL>X~y!hBDGWrS}AWVgFRSWKV&H-^edS&1`iV|@=UgfcTO
zk22F8X^YDY*^aZ={`oRPHXM;pnMva1&a2FjeYZq>+2$b2DKk_K^D8qcc$Z(9p>n~?
z@>!W7yJ%8CnQ=wFy{gESneI&IT$!P=onM)uF!w4+B)>qf_xLb^U68JXGV>1crh;xc
z=!!MXDKq;JH|anq8<b;IzR71aW$h!b3#?scq=;)ZZYnd@e0)@9$j%BXGZZd`4;L&7
zw~G(=r7}bE8h~FaGrRckBro|>L0+NE5N!x(SAaIaGN;T?`4VWU%v1(V5N>kVlXyC^
z%S6z9smv^6ts#k|8sBcN477#bqz-(UQ4N)`DkXrqUCt&@b#r~B?5c(JhiV}GJT6wZ
zP@O?_3-yNrgF}=ubg7j1P0vx}+4BH&Rut;+$f5X6c?gkM|0esnEJPVLKpjMnNxsU!
zD&Uplg{wy>-$~}|G|-<Rk3o4$ezY$dpxI@K4@mFGM^m`$J`-OzQC<lC<v2MNTtD!-
zstSBUx@xJDuCiSW^&NH56}4Zo<v_ZEuIPETPVih;T{SGEt~@OZuPc8^Nki9OrKxWx
zlPQCO*f33`Y0H+Te96dGzEEPLT-&(1db@dab8BPi=GMEVX*NYjaFiM^#ludnuC9G0
z?!3P*PlFk_cAziX7`O;%4;ft@S$^c3pkTF>56P$_gp1nh9Pb9%exB+l^7G{LEwbou
zE+5F2sje27r8tEA(XPYER*_}7Y}EwM;t*dS@EaT@%g#<&lv0J36G{Q~cgq<r0u8mN
z$Pbd8TH^O;goz18pI>Ag^e!IntWggIVw}qzWvq={E%)O2nvQoX5RTr-xLlERM?YW}
zp5?13XRXe_7e})=Tbzuvs4Rtth<pZLp2${5@bANvG1Qdfd<y@bcp{zX%#)pyZJ@oC
zt=!Sc*1^ff*5A?5-pSTRE_bw-+uJ%h2B1c#G}U~XIf~BlCFDabk(ZCq#xjNBUUcGo
zE#+q{!cl&TRL$b^!1L?iGpFtqybxyx8oX!q2>hndfFfT)V;I4F{HX}f#yFaB>D|R|
zq6tJ9QWdfc$-MYNB=gFv6yfz}#YiIbE&5a^>qULUm!l=XH1Oi;`h{|o?a@fbpO+<0
z2HnaM)!~9I5HCVm(yrTuvLyCpLRq5quU{%l)Xw@+St1)WMO-@D;1@?txw2c>@=134
zcgqs#M0YtHY;5HYHcHDt6dk3101f(DDiv}|e@6usC>_hv5I9L&*c6o|Ojn`0faNEZ
zCCbmd$`bjsuPIA|`1pmgRH1e5vNVbxPxdt?tK!CcN&?{~CHIl0#D&>7Hv~Zp$kgnc
z0#`>kJF68@VG6W?qSynexwO7TbXZjIfG}l%6a&N-6y&p~QjDQSsipOqzKqEA=W$7M
zwTqhKyZ{#zfGC+ILgm<hUo=p;=T_OzDZ(6j>+I*$9#UEg^fv4{`ICvf4uWX#4Hu2g
z2s)?_`;fHBM+ZXr7OR1O_L<DWnEPiha+E<ng3|x|%B>5lLh2%i{>!?U!|OuBH^9WY
zFo!NI^V0=oG`@al+e0pE5Jcsyf-?g1?1y5z5gxKU(p4`mO@+M8Z6i5(p4&!}vi107
zy-elx5{vzR=@RS30($ZLJ9_yK>m$E1Qy6_L;q|el*5~@Lg+5Zb?|h&8jRMO|-qs=%
zDP0XlS9|GDNPB63Oy_*fm+eI;N5^Y_t{;2o$AJ5;_;>V^?NR<yddbgj3Zs|)XuHMd
z*>;2HQ29p=a&>d->ej~1&D+x2)U<UgbZ<;QQxf%vdT?a9Y5QWH0QdbOP0H!L1Hcrw
zJ#K5%XUX>Y`0^b8MO@_6W~>6^G;CJCp^r_!7OX8teRAQVei0{=C9AWjFU0kWxO$5E
zLOJzOZr@}Hp2YQ+(7rwRMIFh!vXw-w*F3aDZC+9nQF8zDO2v!5;3<sPm8l6QiC9;U
zNLMZL(N(T8%+w_mQL6uizjG@MNl>}e)*B~h{(8%)yK?L8K^}S=%gd9&%VUf*%iyMZ
ze<sNz_R-N{!4c6)zN;rw^B=FM`^TDJTq_3^8fSdEQS&mAJ$!y~bvU)pX`E#u_)!N1
zM-d(MW64I$QTx;24cWjpUY3-)L?MxQ;3iqx;68@11`S1dBmOAPEVpo<Uj-rmW;85+
z^OM~gd<(Mg5y?)n?%`!kHU$wbv8*AW)zr^VR^HUUfw*546L=+?)<tGtEtvy_F?nie
z<D&5y%HM{#D}dILeU~lfCl3n`8yXrO9VMj!!6=nnp={vnEc66rGz26x#q)SrFn=^w
zFXTySE&jrI{;HvkM3<PqI>aB>FVKlUUbiSrxmgsRQ~U+#QOsuzEk1=Zf05@CLljJp
zG;A9S+KjI$^P>t^=yl~?T;>HopPHASw-UU$xJ0_P>BX@newhCx9E=3Ic5`d%+NZB%
z2VcG%%}CRn51~KN6_Wf89r=AzU&1R-%;i`3B;u3wD((<bIpg$|Q(w?`92#>ZJEl5U
z+qVovdqdJYkMY*Lbu9DxS|x)A!H=z`LX4{oZb8ps&~x&)_G5Xe`YRn-Ub^P=mcOp^
z^=alzd`TAoKA}oF;;sz&rFP7Z>*O=|=Gds*9)mq)c2Sy3LhJvWI+ngyh<zH3VXj5K
zgn&1)`$mixuI{D!Sop?D<&ti}|FvnvB_Wo@jAUu9yDWmAb9UAeM|goGNdLOXB=&zK
zlN$24f=4D3<0(fb;TxDB(?s5<m$2YuG6GPYgHMN&)sX36q333XW6CLw#nVua)C}&4
z=4P5VG#eZq9Kd(s%`L<~Sjo`UU#<jCLK}%>5cofw2mh7Pr%EpLT+M%$e?#yj=D$Dh
zhfh&uiVNM(>^ffw+JoF&Je?=mIXesdn|)EQ;`Ud7h%XvPW_AZhE1oAw^E0WfuFD)D
z^1bAz={tZh%1`l9yPLjqaL?E*OIEh}^LD7loE5rS;wC?V?3Os=zgVu$7WDANFBp00
zA-}RD=z;u$lgPe=Hn=P40eq0X3HddGG71;D0xB=mWOIWKUAeio0-s-;3YHh2y0jf#
z3z1*C%%>Idi^iG@lV7%$5FD4#7Njw-RnVd8tNljd>{jd#g#0RKZnt1(X?gH%1f6QW
z+FuloZ?PXJ4Bzvtn7VV7j|}MBRg3R0eU-?|?sO?1&+{lBcB1mpo%d%!RH$%G#ZB=}
z#Qh3%ntFV{jm<?Lpj6AE)q#$fnXba5gHRP#7x)K<1gnSQR{*~1viaFmH<%*)=NC7p
zpT6U!pzNAJH~jXE(JCxdP$B?*4-)1nD54`HY1*CGr_uY52)hD~DLP6i3s;8bdQWA3
z7%x)|8;*mv0P;<4xGzB;$>#a>MX7C4=#FTBl1&5`_|H8)!f`<VbFvG4HSIR8@D1l;
z9y|{tdlBaBYER*J`Krbuh6{4B&Dt*Fah?45)^0Bj=5@WrmJ1OGAYJ?6z5>3b-&EH*
ziY}<FCDaepCKT(L?2c?Z8aK^>QAW{91zI@3wYSLb)ObfT`o(q>i|<o(1>q*y{Be(f
zY_SdUv!k!flN|91Y)gve6X!=^<rC`002)}u1(8sCxcOpJ;9I3a+1IwY{Clhz9-u`L
zIc4EXbtC1+B%~z|2*5PLDAosLb_n0Y<qS9eik}iC7?jBZ!y`l4lvFn6MtMwQZjnkg
z%d@_GyTlA@;_2#!oARt9ZX<+0_!VO^Y-%aO7i4qWD1O)%@gwfD&@+;e+EvOBZV?#e
z6WJQgo#4M)3)3f<3__ikk%tWRNrtZ*w-Ln9Sq^bOMUaEq8@kFN<i&XGCqS1GZlSMY
z2st!`&kKL$fZ#BSOV|EKC8Q&6zY9E7!*jaCJk=wfzDl<oTe|X8SBodXhaTs7f~hb)
zRRUhXvy5*#wxf_^01`EJ!8#QCm@``Z3iay<lv}#Q{0;%F-?#RQIV=~L?_!>#w0Q2z
z*HZ>GDHRu0vt*0ZEub+*ORoJ}m_b8lXGKVO6zUFL^Id!FuochKGM=YK;D!7zwaLeT
zr&Lo>{i5|%Lr7egw8{VI!4dOQ;@EtwCoFD>q&5aysjiFUdGWwr1ayh>G#R{X`KC6A
z#-6-jy@~TuT!#~{LV0<Y2d~lKRr;;%k7KvMd=~R7u9Jyhp`KmcoYO6hZ<pkCJPl>Y
z?`!H=QS*&#fQwoC|J-Y6sh(7+BeUn7Y1gOXHcuZmYlC(DSvjFP`7(5C@J-uu0ZRYq
z0ccGGh7;!n*|J!_`T3*rGzfu<ltE>icpeU(HQ(GGa@f|DXKjDfn{THq<9QaBH>w-s
z3tu;4{Y$|*+y;FJZIt}#MN3x@;S%#h^<w;2)r*X!0`pbOlXkr*d|wNpjvKD-m}Ez7
zxz50<;7L{Zv1q=z6&xrFQ!3Ejlt&KbbS9+)KD%<pqP5#~G;V9_Dv^``Z-WqS5kD49
zZ97`$Kt{-)TY&y)&UzjpToA(TK)BLuE(6!brEeb;j^+#tVQ37F+KO2iXXEA)N6Nu6
zE5pJ%0Gfj=&{G+vTUZmH*b2nB#JX!ly8EiJ?>yDV@>j}I(f%*D{>1G`(t`>*XaoM3
z{`hfkUGzuc)*>9!ADiFsW&JfmMPC^G3GD^f)|^a60HN)=2>LVln)U*QPbjv6e1^C@
zEJQluwyQnwGcNKxQMZ)Z3pB)Jjd~=R8zZ1W8u9eg0@9PPHM&CEp6b~Ebczuj^AqGh
zsl6W+9v!LR`^Z!dsNaHh`pnJ*o_yO-C|Wnh)os+~Xa=6Ta%(s9<ca9>xEN2un6?w*
z5cm0rS8cw?-aGT{m*hP77)$vju46xIOA&k6n*wKy1kifNXeHBG9=zcZXVa8s6Fxt>
zw&f_bWj~mcAGDOAfH=8)D6Gsv`l)>SVtcTJ-dwqFl_Xqt`e+8`b>*@HYQJdP0rg)6
zI}qv+-VWFZC+WkP*GG^$mqb+nwR5Pw(**n&aQvtum4kyZ8zN`98s6vMhLN!OSb~jm
z>lA3!Y>ti6Gk&a)*`&b7E1r)Epd~)2?r;PjmVbi}A&+Q|eSUT+=0zCSOKgY4aoOM&
z`W-YD8T(D!Q&GrjEL@|_6{w+ys~}%vjrT%cYPYckz5_fcmfU;~1K*NwJszpWx~_a{
zx3z_Sj9GiewuJUCA$^noJ`cW=ziB^)8==ybSFw%-JBkKhR4)l*T~v;Q{!K<6GQ>az
z*KggP<rCLc4zbP)l0#_YYC1qjTr@SG@`C(=0p##2d>fZ>S`eS&`ZK>aZsm?(0GF5_
zQ{v~V+PGh~0WnY7ZQLe&y)}>LN$fMt;Hxy;7yvfXp*flb`N^E`3&MD#tOvLK4&@Qm
zne<&z);c^)9T^@%@^f_<H`lhZCq3cvM)27wsOSB-^s&!F;nHXRQ7e6W#HXEp2VVZf
zJkl?LJc$>^K-l*uzWo^{kBkgw>*_@Ne-)&g-0hq%?fpP{5%_A;>2tl50$&I7;)^X<
z#B7&bT<Ol&m)6%4UoXLq6gRgA7qxq_rVklj3|JXAU5$%LGy)yB_f^4k83@DeImPWo
zwYE4{Htw<5B$9N*M>drKq<JPUfRye_AT6bM1GEIb1=5hrJ0Q8P_rNZ|zkpuAkHApi
zCtwT^2B;YY&;!l~mIW>amIJN_mIqQBzY_2_paJka&=7bPXau|o{2o{l3aAOBwcWLV
zb%C{k7C;jq?Uhs)NPBFV0!cq4H@9~Zx2MuSDL0BPlbifK$vpx<a?b^l+>3!E_gWyy
zodhJg4*^N;WFX0X8Ax*90FvD0ArHxI1SGlZ07-6hAj$0nB)Lg`L2eq3=k@^N#u`a(
zY8P7Irb`8S>Q_Vn%K^s%>jEbONpBRM+v_Ip@Xh(~E%@-=`0!prc<{pQ>4G{LX_Nh$
zB2LOHy6j*dWN(hZDL}}enFE9jnk7IN;7(u*AlU`>!(w`A4NSrBw!qiGj=)TyC(saa
zcLII~><Xl`x&f_$-GLs!o<Pt@yn#NzzCeE<{?<$Y`T~~&`vZ3Y6~JS_0N?{)AP{9k
zG5}Z{at#8O28IAD0z-jTz;Iw|U<434mBauS1BU=t0fzz;fWv`Fz!5;&3uh#d=^tru
z`+acxfaIk=BgjqqBl{x#Ed!GNRs%_Yhk&HNYe3Rp8j$oy@ss|_Aq~<W>5cT)07&|4
z2qgWr0+RknZ=^rygy|1DVfuq?On;Dx>2E2J^tT;I`a1(8{oMqT{yqRnfBKM<^j8f?
z`h!g~{lRvb{@MXaf8IdSUp$cXw-reG+YcoD{R$-goduHqXrB~8e=5kx?ft;*2|@ZJ
zI}gB3S1hVsvOnlfV+@=JtOtaT($M#Ug+TIii-0m9Y*M2HLdTi}U>uO_Zw-+A(N93q
zD@&K{qrmO2@K2=sj!(C$C|v{m&FvS!?IS?x)&^Y(Jf{mbprQFd@TD3%U@DM?fByiI
zTz7%wr|$tZz(+u`rzgOlfzN<c&i(|JLY$DD`J0bG*br4tnu$O?;5?u{Fb-H6xEEL!
z_y|}Y_zqYJ*bMmv+tYXep+ijwunI652-!3nfz^S#fX2XUz?#5^z*@l9Kq;`M9()Th
z64(?-`zKfeDL<HAT<IGNw=Vpj&`TDt7s$%=(i}*7AwNTUnG7VoEC7;TRsu;c`+=mF
zCqU8*>QJT^_*SNu4nWdN7?AW510=m{29jR(07)-5fTS0)f6@!>8$^1k&Fe+Y>xI_C
z3wn`)H3@4AbN-!t7?RI!U!X2y`eSr$IQ`K#D{Z=AB06r(>6hc<)?j{_j$50UH=Q_L
zZjIiT>9{pz614k1mqRQsx1K6*Iw4(4#KEmoqBZe|uRQV?Xo{PzP9-E7>IZoO(Il62
z29iDY!Og7+;?~csh2F^z@l9h1d<zQ~4>ZE_mB1RnRlxedAAywiYM?Wa{Er)OEl`M`
zTZi+{#4kl!+?p3|ej$}7vE9_+`CxRseUabEkB(&F)_!nfNZNYz;`P{v*P}PDM+(QS
zhv4S#lODzTM_s2e0}c5tqD|-dqQANM{e=tXig4V#cnO;?Px6$+Gh5tr;S&#QN4WwU
z;y3a{(+t=e*b&$UNcrQ6o12sV_u`Qv9&R2uH}0XW-^M8alpfJ>^Q{Y}BfW6*nz`@g
z+WJIWhS_CXAj#K-Z|70`+&o~WgU|Ar>Ko#N;^*e!a`SVw;~&h&KLl70v>HBsSNzS*
zTg|aIvEI>EVSJ%2%=#;hfE3;WNd8LD1I5G5BmH~vND&V=ud`rzgD5>V9?i|SBzeo?
znJ;d-62Ko!NU|1a1Y8F+0d4>`0ww}sQ<BX<@)=u!e!y)&HSlNPMBomfU{~CnN3`wm
zoYE8PX*B4{;kgD#{kkzg@*iV?uvN);pb!r?5ApBCqe7hAyg;=1@Hg>8=?CDZ%Nyy@
zZ)$&k2c&kRHP9dE2&8r+$xrRZ_CO`DGcX9)3m6RS4;%>e15!JZ_@{KaIeXk(K3&qK
zGEC``J}6z%2c_E)Na=P3Qo7W?rF8v(l&(KeNSA21xpdqdJ4#m{&rt5!)g7uYg}-_L
zYXN%#$)7_OjRmkb&<2RSX6-X?Ajv~{&&_A!=DAThC%X~q3p3D>9#JM)zM2E6zCfHB
z{7rMfS$ozJNP5ITK9dW&&WWG*)7|j?TgNX&oZK9+y#0?U&j+L9`7q-7C<d&In=XM4
za`1DdxbN4bXFcvckx9xSU&;WfJyi)<0Z4kJaNL}w!iDpou<Sb^H$G1F6Xl}|Zn}o@
z_0uq575p9!tO^_nBtJ9?Nd1Y?K!J}`Hm=0^LGAj^0dy3<Bar-;lPDZFKPPYg-$IWh
z_d6iT{hrq=$<57`DSS9?&I(sAYwH<)Ohf*qACSr~%3`*B-24%=bMRa{Tu(lKdI6zI
zNpDg9aC0~c7fy;exOo(ueA@LO@__Nh=y>}ge)FTdig(<c1MYh|(N)8<Q@H8!M0`}<
z;EOcXfn9-8AeC#BMOL0Ezu_x1av;jDCKyQNISS|l90er(O$U<x<^oB7i-7Pcnsq=0
za2pW*QnL>j2s{iN0DJ-r0wRwkh+6|2r|;_;^aUg#z(&AOpbIbzNOLJvK(aq3AO9U5
zeR`&c|0Vgz-nsAgoWId7Uuu*mDkssvion5q`J!^peOu?|MpM3v%lR+RAN@WEtPMO0
zr1E_n*bsOU2;WL}l3fnC@8Vp&Pw|QU)LGC``AG)imE@c#9QPfY3#ZM$3;3mQ&4CoI
z1<yap&3%i`JH0)8dVBfwU{j1w4}{~sA?GdkdeD*F8-OJDRv^i}9Y}Ix?3T&B6DasM
z?i(=ook3gf5uhXfM*_)TYDD3<Z?^E+c&;6893O5xkjmc#J{<ASeP8ALGx;0h*9A9S
zVZ6Vg@gzh1rtzd7fRR9wBMM06RShKmDL(GI=eLQE@`d{z$@vj&e~7UZW{)&3U<6tk
z7ZCKweFH39I4R=bzPWMZ`=mz{^Xz)GF0VI6$NNLlM}Bm~zlN``s9u|l!XvihOz=zj
ziLpJFpIIXQ{Y2qB5J(&jV}C4Mbs*V+G2h;&^x{R~wCzB{r$_Bq3O81i-oXOGP2j^}
zjEaSu1bl_?1~oA*goct-Z)Le(+y`u5f8DX{AkFOwE#vm5xE!5*!pm`KvjN^Os^3Rq
z)^L<ky^RC58#kMM=9gKOe%f+qWY3n9AHN=UIN@}K-#RYdbN2qTS@7YEZoFoE<?AoU
z43^cBO&We7F{b#%YU5_atx}h)b>ycZODF6{-;|}B@Q1{|wRCN&kz?!;$+VLuV-7WN
zNjT%P_58y3ld=vBjfZ`+_+mVIEpE28!n{RiXDnH^sd44VOtXm&n#+|ZJi30Yuf;%A
z6bBexdbmxslb4roSye9cnO}x}g|MYt+g5CQ;E$nu5@H|Jw2Q#E9Y!}T%Xr8s%N-Y7
zCf|Kyd?zs==uE0#RQL25Wd^Nr@ag1Q1M;GRlj==9dS(5dk3P=*`~3N%D$@1Zj_Wg4
z>krvC+v~*i__L)Cl|WmV(T$AQncD65BTddMIP`GV!^L|)=snyfJvrsk<l!S$R(!D<
zbP0?u!=+iGRj^Ox9!E?|Kd$loY4;ryE}kw?e8;Cuw=>HZG(v;*I-{Gp>FwU?6JC#h
zWZ6^EzP0U#Uh6M~F1o)W%DsV0TH-t7zG&ka6Mz0Sig#bT)@qF1oWtw-S95MM?0)~u
z{llkTow#}A<cJTQx=JMOjIMSq$FsvWq_^7pQtv=|xn;MUOj=6<+U!67tX=O=yPmDy
zVeHd_;+wO#+nf};=`}_qFW2*Mk{|Z4Jdm|;{lQU(ej0jpRpz=i63IRm-<Qu${FBj@
zFYVrPU*EcGCpPg4UeVO@X64h(lUA3}yZ2$8leyQt#+$HC6$MbL_hq^%(2Z2DyK9Uh
z;cbu0-z%jp-$tLU9@n_*);+b_yg%dV>@ev1sGqU7G>dPV!<^&(Ro>dS{%F`~?Zwe6
z&qb$QIp3y9ElHzkbH`tCLg(rfqx0AF=+^$|4+DE|eNpCseQnc=wh2F-Iy9x0VY2z4
z=9+um;ZI=;QoXZl@A`-CF$`L~@al)lKK(LZ?R!2Wb@`QhkH!pM?r~1J3jJY5r#M=7
zZG#uZf9Y0i$;vl7+ibiz?sVWY(;>wlH|w`=;IP|pa><Nt$0nlyuiGA<Y^D#MB!6N3
zF!G(<f``?MZMkS3vb*xqUY_tNj83)Du)d^OPqoXgbIUCs%-E6gq2uje>grXtv)>x{
zU{7r{p8B8+OZ6&WRIYtf{H2p;&t7jv8!hbpp}SB0jms<-UwCt^^@+@`=#1@RbZ6a^
z9}c#j(W^;F<8dWc{9Mjh^XlZN;m1`srZ#-MFm2sawCT`6lj=45^JLF)t=moA-|S(7
zeyNW<cl;r5yV|nXJeNLJcebw|I1#>w(Y4iIlY017&FX6_RB1h~rSbCE2E%_F+~$V{
zL&ond(d<q~*vnx?w|hY1unyz84e&Wyd*wu*>N5{Gdj;58I4NTmpGxof;`_%Kt49SZ
z)ic>qYRl>}{_`6&I`QCxolBQ0apiCSUQTAbB%)E%PhEdTzBx0xCQTZ2^ZDp*YWLbi
zYI1*b%J?;v%Cwxc@y^Iyn@>EETA)H!F}g9OKejBh*soX@`*Yi_x9U4??BlCWw`^mc
zmU=P9Y)PpJ$FVOrqf3?i`Y^rW-0IJ32emyaKl8rJn9A25U5Y<oVICJEf807*B00_I
zrXQ-Dw%F(C)P7wmbq;K3J@Lm0fvR_L6DBWfI%e@Zy)(-ohm_=aX0~>n@>T!Ls<sVp
z?)q_Dv(&xQtFIllz1P?Ts}^In&P9BU8C|A&Xl$7p)5AJnO*)%Y@m%MP7oyu$vDa_A
zV)?DNH3FV}LjE$k^h>*=GPk;AoJ(oB@8#n&p~v5jGCTEson_a`yxY^~!v=gbjbn6u
z=6F{)ur4&V>Y&T}2F&xE|9;fW0Y6o}yW(2rkW*Q9_t3aVVRUtjYVQ2qvDE9~7g|-6
z{5020(X?5`EW6NI<;)wHPPj2O0d`-9<QO&E*~T?}u8nuXinB-7Mjf}$TsmQSuX=As
zdR$#`epRLdeKbaQ|6TEyW~=XQzP_#WyiSi@Iy&D^?*6oPLgQI}*Y)cjd3F_T4n}wD
z&gce4yB}I4Om+3Jjq0IyZqSW7$JaaGOiZ|O!X&UQ8dYl;UE;gndWET-AGd$jJAHGj
zKHJ8gU2A<|x4q?nt=>O+Z9TUHXJ;_FhxV%@K8$+z@z*mcbLyT-@0;|t@5k@lgST()
zklFwK*ibi=BSzQx-uK(icW!(3$OYf~+dXV{bhOP{;xvCm;FVrw-dx!AJ`&^SCM55Z
zhmQ^Kco$DMelvcpw^hA09u-5JEz>jO8n-Xg&~WSI81!Wr-Go!$JyV%2D0k)kh}rL_
zEg0+L{%Y4g$AQn9nh#uh>VWGwd@Eyg`bP}yu0PuEAKO!s^!8lqpr;pp{vo;79=nc*
zV|spApX`k`G^3k(Hucz#&Yk++sn;@M!23oOBWFCB_|AIDna7vL9rmf}gO1E=M)xLp
z&UnpOljQ@XneKg@=lgh1Q@=9l&}Fqv?=1C%`j;AEf3CVDN1OdW{9Ns!<(_h>ZC`b0
zXE$+0>9?0U?DB0mRuxm)=))%s`T)$oL<Ce_aDBHy%K=Fv&o#KV^rnM-CAt4!(-mju
zPHM4d!)SlZXJPSOikw}g*MoqnPt-f~uO$q6{=hYE)SyW(ejRc8sr$C}%P>$ekI@|)
zxND8V*t*4*t;^FpUO#u_ZNIH9jbAM>nH>}O@v2Wt<i{yS*KOq0eGW#K7cMz*>gldC
zo0FPZ_*5<XSM!_AXVj}T{O|x*wA)NcjziwwPZj1{UXE;ZvRP2nX|t&PmjYvhU6;=d
zdp|d2>mju7nlZYBIMt69lj4qfjSp$nUNU}6_w7A;)%19--@B?~o$0ZguSq1CDvEEJ
zfBdrGXTLq4T0C-!N7ad5>#HAIztczGEHQYPcj#347Kvmhi*M}yQ$zM|sM5mREy3K;
zPx^z+`W^Q|r4jQ^WX!GqYIsAmb5a;xbU^x>exFJ||4wGvqw>Qg@h2xw9lB03vS)PN
zR=<zz9}jse)uVK+QX)PjERSw6!fr#;pMD*<(0_Ed-$%8-dG2>fxvqPD+6p;ZFuI|G
zOzLYE#_CTQzq@+R#$%>Gbc;Q2h)u@l{+jUH<VOAOqp!>89!+cTedXIpCp2eO(ZfEq
z@^Ks9a6*;kkuN*W?|5g*HW?as@r=&h)1z&x-l@g`Gh^;vcpdZmn*EX<hlYK>H}ZnX
z_@y19!trgC(Uso6tfBAYPuEXW>t(cRd$lB0gDrKulI9q+vV4BLPUfm+XhYX0IV8u`
zyT`0FZF2AFueAm~9vFOOy(+Nr*z(UaH=KPkVX59djMFi?YA3pv_}**wxPA7^%FgWN
zUHOJ@bd0{wT<@wakM3*h-OCT_?-||R&FxS5jB{=<p=;+uH|3h*tM2Ui<M`0$#y7i-
zJ#4jN>u8B&FQbdwcR77V;F;%|Auqn)ad>6);5EM{=&c_9=22Y90So(TrlJkc=w7DI
z9$%xy$EMXrKh%qV?SJY)&l6)GOt-aPv?c85=%w*a_%4irC8^%Fa);_h7?zn@Q8jYz
z-cZRD!->PMIV`Il6MMJrRfnM})E_+=-Pk6#mOmIc+|eaD@l1&`Rg0y0+*{tT`|fcj
z%dIMmsjF8BXW%kA%bpdt_gg>o*qW1zO3t&q?NM>!&+T_ED&Ed)#@baH<C~~^w=%kZ
zsn=sqXnY&)s&AissDk+@gXN>oCDivGb8^Q<!(C?{Lx!h}ZcFzPZ^m@0IebJy!=##S
zbCU1Hn7r^mxb=d``+2`C=(<^fZ=Gh$p8fV+oHYLV<1<f_y_AQ0ncZ4-$+**yo2re;
zo9;_WRQVm_IE>Dtu767D;(8J3<!i?UJH~%Vi#*uftlf5pQmvls&I<pCvN4{~^_gfp
z>0pB4iL!qhoz1-W>F7^C4JcLDclXNvbFW=q@KWW1{9tr527f1eRm}D1<ql=eMg7qr
z{Q2&Ijd$xe>$@$yUio%5?-yfl1xEMl{n-QVhmDMXaQ%&M$N3Y7+;(?cvEkavij!Kd
z`Ek~m+VHz|;Pa(=wSQhcG2n3Z+4CYs%w9F2;sW&vXXA0ruZP>cTK6f?(s~rem>Av7
zq<5>661G?9^1|E6?e(0Yej$T*T<i1H(=zQ?N_@>YeT?lhy0tD%<BT4zE4S|2;eh*+
z%;Du7s_%QVqf(hk_LC!j*mDMY-pJ@q8c$XJ=(Zr%()8@EEmn=6y*XfK;A=3(@xvQc
zq=#L**I1v*=xVK7b=N%n<)V#4OUTO~GcY@`Zfm5|60c?J${JPp!8i@=x)Q8EBkQet
zS6XHFJo@0!GGkqzHa&RX;-H`W^4L!?>zdkIk646$1*2OZW-P7p>*1Cep`WhL`tHY)
zYf8_X^?Tx+F?;F_syC)#>o}|#XLJqSXZJB07QK1W`HDeVF2^5b8b!5DeY`Ga&RTiB
zBYS%MitajmzEn?nDmnP0tzGqmv{H*sZSEVcH~GcpYUSoH9UBqbXpzen<cAld+rLKt
zT$d)U#hcrD?rweZ+SHe!k5-RvR!No^+(}w5!uSQoCK%l;^_`wm{O0{QxpQ!Img)BP
zj_%!Dm9IwD54_#u^pm!`o}fR&=*qcoR!)DCdg{`f9y0?ItBh`ZK;fi6<m9|{iPfBx
zK|Pc3Ef9S!v?JDDTUx%?{3EBgdIxw9Un^7GQAS@s@i4IM*hvveGxshM$qg1?KY8+w
zsLmPVEG$cTNFF8s(9-Dqa?|5m_v>#@ySvkTt|j!$`YAOZpRWDq)_Z5xjZn%)Ci+zk
zKKE#3jk(*qy$EgDEv-uMBZ;IHqbpI;ZtD`i`kiGD7S<lI)#Vq{164Pqub+Cl&b==E
zMt+=uIyH*Xtvg%#z<B+Y3k=*$FKxVIIaAuX-GzFMPMe>vP^pf?_~xhwH!-@$-Q7+M
z@SpJU*K->p-aYwc-san<qNjDac*N{hu+P{&-WU)vVf~aLSw0b~<4-NCVc37r%dtD0
zYi(cS;ZSX5yT!kTI&W_J674WgM%R9;*`lOIXM5a#ml^%whH<}^nZx3oI(NNo(=Byu
zrw-Fvq20;ocAip~oaQ)frlJ1!Sod39?v7o*EheM>$Eo+i7OshyuyQ@dPMVOO?+=Q4
zp15uOc5nY$3)j{dyYqI$Yp+d*r*GWs^f7g56#CehS4DIK_Y8irH_d<4^&4w8G_>rr
zqUo!r%U3G1#;hyjJE68KzDr5MSiUvBJ7e}ClYsDwjq1tAZ@J{N>sng}yZtkqE6$o7
z9GY=*5au4S_^!TPAvtob=_<RR)4vByPI#gJ^VljDJNj8B2G%cDy{6d%jFmCEWp5w<
z@%zudBkXET`qX#PUH=`QZgi_*Q)a`mSA+bwTt5SOH?wqCH#~cJNt<p@xAbV$Wy6Ce
z!>e7LIb@0R!7c}9pSNin5R;6v4Oo0Nl9GqjnR(b{s9loPR=N9!O3fQyY<6zWi-z7M
zYx*Ca;RS!+l;mBUHRip$Ti4gYir@BbUO)eRvvDI#YP52AaCh<A{*otgs298$-JxoI
zlIu$*-v6ma#=*vRHc!(+J0JbdrP_j#)24qMYxOD?<&x3e8zLWU-m%-Npk-4R51nc}
zD#)f+RI1B_Q9ZjwZkd1NIDEz-M)%Oy_qM64>gJg}$LCbIcxu6K%`4W)$~<oBe$b(P
z*T>^0;hP1cTN<{1^v>-~A3ho6@-Tcv{b%z6$JQ{FXGW-o{d#9!h`ulU25eudm->E%
ztabHPih4JH=@8nvZo`?+mX<E{y#2F~`5Tv~J*+SmW8aL<KC8qYhxKP&J$E(vwEM@2
zwm%nN9In5lSe;Ezy3Kz5$}|&mC>Y)2@pnp%$!h-4<&O?qmPar5>9Sex?d5?({2H%H
zoMXGK6WS3ejBe2m^COw9W-q8wJ?-_OZ4ca%9Nw3Z_I$A>Y=2gTrx9r@G2U!N{Ox_`
z>~#LBO{?0UGT)_c)0nI=kUx>XZU3R`yJ3NkrYAH<Kbg@@w_D!$)09p<!&{s=|8bt;
z_Uf@6KOH@Otk&sS=^0H%ZK{L0S<DU|DP$?3bu7A<Dt)of$`7lqzs_7@^^?Vu7aoJU
zos)Lic@+Ii7T>~})%D$-PTGIhF-d>$$);mQ^f;N^Pd%->`z){O)_YI2$2>wt=f1nQ
z-P;%HtWYPbL6LFp6?YcjvcLR>j*{wG$IEoJIy4;LyR1o$5o)8`U7PNB;#7XYmEYf$
zT(!#3Z|VG9SxM@Wu5YJYJA6hW@ndw?o+c|YOq-uGNwbOlUVd&<)gIm(_ZEw*Fh;h!
z_=7i9(H@$?=rWx*J-6=IPjaU0z(1-MPx<Z8E#+Tj4Nk02vKh4S!p2wV$M0iwj-RIO
zJ}~01<wNBb+uD8j<S^pN>Ly-+$rFZaqSw}lUX%hk7~OBLyJx%{EZMl&_~NeZ%S}q`
z@aga&!^o~gMvEa;+%qx^(7&`HIh;?pSj83FSb5E%&d+B2xw-tN=$V~geTX|d_;S@I
z#ufh>iEl8BZqgw|*<VH;el~Q-%fmMkUsZdv@4e@4_d78sBfG|wyNF^bS;gp*BMctC
zU9=?qZTgjwvOZl}JgD^YOrL$m4xLn0jH@O66o79mjBZ>t{lJ*aRfF%%d-mIs^@nQj
zUwX90stbd5OiMX+-Y@Mj`cV~aiNAS`%W0mDtQPjz?!%)}o~KVgac;kT=_$R}-AnKM
zZIs!<q3B;Sx>`}5HS5=VSbcTRVPRbYhE1NK>16Tob-MF}<5tyM)m-)hW7v%Dor${s
zs*<m7TlY^hiE0x+*T%AU+%LoYqJB<zCf%~L*JjKqVstK(Zp?g|a_0xbpZ1k$bLsZ|
zil?WYDBY~3kFsZjTBFMy!+2*3qkGimSY$}6sL;1<+HO~LODT3|>8bRQUQeX6V%`|9
z{&nkY*u5RevFNUY^nKc_TUSeOnD@ePmrcKNtFlbo*KFM2yul*1m)<q_T}JoialPS;
zPP$@f*52)9BGeVVw_R@>GV#ucip!H5r7zo8Cn|iuY5k3;j~LxRgU1<NeWrxkg)Rym
zP-E`W(OdkaM)wp}UEcnZT+MtU#w@Ngy5lKJOc(CkR5o_}Q$y*?-hOMMkIf&t(6UCC
zVxtdx#?I;qIqXS}p!4HrNH*D+HQlD1Txm?;%b!#HP7kYpLuuM|O;V>e>4umW!RSV`
zRK_jZ{z5&~sv`~u>C?Pez+9VDx21t~8+8fT{?4a7>IFu(Hua69#*mKA*FGkB%C8OT
zb0jM8aMU=9wcDQbOYIYrq{3VdMyJ<n*eAWqwKwcreSFO(({<0~o^{@bP3SPddE$lE
zq0ZxWV2&oEYxn0ub0fpMYZ9%u&e~)=w$qkLDI<^gpX>hk)P|)EM{ml&oN)(|V@-vM
zug^XXRdjGmU$RiWta60%oigP1vwp9e{pvaO2JI%`!RY3^sFtM(xbexS!~RNb!;em1
z82O80VYe1z72XFgELdaq0sUk~XHs){<o?9UokNy1JiWHutZi%FUOsqe>VX%1=k_~R
zr(yXtw1*hoCHu_g-iOlb%r0M9|DaENk3^RTb`Ph<-f<~&DW=cs%w*UVqsuIJ+VkjU
z>6w(~DaH5Syz<!hR{vYRz8#(?NLA+M(Y=OYY~GRNsCRBz+~PU2?H<0^K0T)Dq8qP@
zZ5k!%IwQ{6%l7(0yPu$!wv6t}<FQeU?!&lsBX6!;cX!;dvU|R(T`$^TSlTm-n|F*7
zcfWhTW{ng4UmT;`VY1D0|Jqh7qk<>>Ieq!lu7mFzXH-*^Znd((f&H^f=!fBaB}Vr&
z`Ss#J{TWXZ?Jvzw?=ao+Sm53!bteCj^rL@bc*>|#@Eb;vB*&2DO-dP6>=AxvWoSg-
zIiBxM-|?yAd7*y$nP$DEaka`Mpq<F*VyjrSae8)b+Qnbjq+MBbZ$jpV2g;kxWI_9*
zs)o9GHGrPWpsq$g{=mtZr5+3%YJPNUPb;^Z5Bzo?soUSwv;5JrCoUvPZlHfOyaUno
zIhvS|nqJPz@S~#j(57+rf0Z^48{KAQgWifZtx6B+@fvf~SbU{#ewvV`dC{m!ki*_H
zT^7vKe2l+qUi$j25r+nzIazwnIn2FgbVn<GH)`~|31i<j>H1L}+r=xYYh#nRA$2>i
zb>3Tl@|#DSFc+H9HHhsTTgFkn%xLwwhi;oM1yrBvwW^)zp_>;%E?AnF-bVl9HlzEr
zG=1j%o$JRudAp?6hKh6dTMjPvXk;@@LQB&{otMq8A;<g!XOd%n<CC=}ziH5^%aiqc
zJ)8_fD~y^N(ZjRb$mKJynY))5y#{k_7@f7(#;LDe`jk1)sbAG+m9nO_Z(FlvgF{*B
z(OGv>6V_H4hwoX8?r7&3@54)uzO}D}djDYGbmu=t-tEw+_V4EwdPmiHdG202%)w%G
zPBUM<YcQ<VjXw8k^dD>UDCMELt;wF5i<ZZBp1at%o@WI5-Ha~sih<|&@$My}dOTFF
zar;BlsI9@Vg!U62UR!8c;+0?1M96?K1gTz?!C6Tax7EA-+IGr~rk9$y9ouXA;z6Bz
z>wGOncZmFc-ZIP`Wps~gj!f@la$@{UD}&WXWY&Moo^f2+Zf@%-1Jjo5=#kzH<##%x
zd*K<nZ1My32T!?yi}evz&z(lw5))>poBKcN?<R9fz}WL4M%S|TsPw<itL98<e|(9#
zbl$1o{+!%!>(xUG-<(m8dve~)6LTaPUHFW3H-c7nX*X(Yxsqkh|L~&io{{w&Q#;Mj
zuhn5vE1A_#=y$u29I8K>JU`+(di#N)b*`o)r@Z!lasJ7?fo@y2n6*hC(JZnG{0pON
ztN%;;_!17~Q>zX*6?fsogfn-W4m~|Nc1y^m4KqsaZc`fL2aGObZTG|jJq`M<TJpo7
zGUJMmIGlET{!8a-b>_=mv(l%mMqRXl(LMa@Rn<R}Z{N=9Hm2EWAJeq^HzqW9o&3ki
z?`v!uZE?8rREgvvqx<rAjcRC%N%i{A*3?L^x;6U8g{OLdDm_$x+{F(!j$dl}aIac^
z>M#2x6EF_K=w8hW{IOc}g$`l9#s4gJ^@m|YUi$8C_vhsYPa@2>_fE2yiSGf7uKV&c
z5r-FC8E(*V!lV%8)yofR4tv&kMaO_c#VXIv>K%@J+ra2Dhm5=s`nF!Tu0NM>2plqb
zwA+#78ygKi)YEU<V)&C*Wi+U_7~P05j!7+wPclu-s@&|(GS^!^y}SOH`Yx(>pn1%V
zjnxJi!5_3BIXYHocF6I`h8e%#bp2&(nb#jzpFDqJ^PJ1ho^Q&|Ov$A4vwX~nuGGm5
z&RxGNm36J^K*`z`KD(Q&zB17zD^Sr(ZP(!J;%8`27F|UeDAGWY28uLLq=6z06ltJH
z14SAr(m;_0zNCQ?APAHc!w4DXtvmaMNBM^P5A+@4Xdf7<^bHLT8>Ea3Q-=6rr|Br)
zX#DRR6{+x*t5ozS4kp1{d5G_jP&EakAi*|{_P*HJDl|MGIz&m^ozdA^@+NpKahA9k
z7W1PuHs4|W<vmsDZ0r=QhzySk55z$y-5W}~sMNus!NY>X21r|DFMGrhiG6}h4P~;y
z3YlDu%~SlN)ygQz_jneh48b`m;-@s1*wj$24nZ0ehBnEjZJd>|P<a?O!VksP^&Cx<
zIsogtObxwoFkN^|6!u>=HFU?GfY??vI2>a|6ptI`WfV-~X*i~uM6!V2FC{>aG>Pv8
z_!fn3GOg{GoJ2oP)q&qLmhG2<<NF3H!56k~k%jtW$1PR%cJXYhd*Rp%%Rr^VO77rq
z6KHEKx3jUdvA4IhRa!YJtOM+nmJZ4md2Nax7B0h<-AsSnd5T~!uZykSqO(YdPhHL;
zp*;Z0gLWn45g$QCk<(r_=q5{!;2rj$lLbbHVKj?-UYY*DOYwODO+Zh3*3om?^F26{
z-|}6i3c(g+v{RN0)&&dX&ZD;my|51>sR%mbbckSihoH3e3_YO#^2n1Pz(OL+1CA$Q
zPkFX2x{P*~=l0zZ!nh)gF`ij<<knG>e6+74Oh=*}hR#th!_z&0JoJ04=r`>TBkWt4
zNCgg81Kg!>*TuaZIy1;+A7mHUFN`;hJdP&&ERXqU5nHb7AIW3wyd>Q~HJ^SbyU6C8
z*4vaeq-Qc5OTim^wouME{4vDZ*;!{xhghUXp`0a_<m7Y*l)>$adl}M7ZO4~0mSS+2
zjkSzBh9%!~(!{DHuD&Xu&ilE|1&_ksk>b7cgtKCVGDbS)&-PIW8-sIpRMJqY`<ZKb
zo@*zP*cBIlk{#`r!R<Nqhzt`~8{B5NEpf+#Z%dEAr`x=aRAcV$bEV5fJYu8_<Cl4y
zSI6lg|1;FYx+dKT`#opqQ;fOKh}sGHT)8r+vq|Q4_DkO7FlP@i@_9Q%Hb7;E{I7PI
z`X|qb8Yt{-#uDb%43`57Zn$au{9yaPm(SuOOeo)|&iMSwtrP9M5_k-t!i_5sH}U9)
zdlPsx_?tY6j>BNK#j66bi?957q;g7OqH*hTW{I#5s<bQ@e^mgvFbug%PD7q8`S~qz
zNf4dlL3-t4(*B?0S+FZQ!$Z6uCOv2QfzaB|DZ;$=9vAZBFwgsUprdT5gnK>WPyL&I
zA=|+rzJm4;w8nd3U(7W~SMZ}$wgZLs7a0jIF^>tL)%;B!`K{)4=1<$6h4Y-s^M!$2
z5amDJXTV>wZuu|TU7phwg6DDNwgK8-UOTUeje_!e3(qIn1m!jT+z37;f3w_)cb5O!
zycW*Z?o$E$;KI}m#v`UAG5@9cn>=c5dHU6PF4&|&MdFfM6G*zm=O4*B=<?v-v`Kz@
z(68c8@DJp_wD&m`_};?vEiOw`-sAtnd~26=;e3t~WSqG6;U+)23HNO9m*LLWU#!{L
zPO0w1I-~CBNOneNl&U$VGsoie*Jsxl@-uYKJk{0Tqtz+2(@vrz6U4>E`a4u6XpiF%
z6-7<`T+TlcTalm*>%oq&LR#ev?`3g)9kvxE->?(%kLr@+c)u0A3q5AO)rvkyIm0x(
zqxj@FtC}6VrV3UDAPvgH47{_0;fvx${{ws7<GHXOIQ2(rGyj5l&{D2{V$1)g{tEfe
zmxwO|H`h<)`mgcu_tbB?hnuc+tiPl>F9S%X@dEfg@FlP&urT{gVhZNJYTre!|Hbvo
zNN#G!S>UGYOZz7F0S(vhz`8~JP2ovTp1A3{hU$mP{RJQmv|I!l11|xo|92TkX<Y$g
zx)81R*Wfd<<T{Y@#gcAT=D0RF#gFc(#1uDOX`nL$J_8bMx+omirsdkY+TrrsAIKGP
zaBV=YZAjs$p0dSFm#+KLs6flL)428<#Y5FI*)CoG)P6FKh?{FqaqHPBU2%SngMLV!
z@jwIM1R(j3i9kW$T$_e#M`-J<p#4g?c1GUe-XeaogLgn`JH6-AqrBtle{TO7N{?Jq
z4cv510Uhx>m8YjX=IUYAZD95$wuk)o>+nD@u5RS&OiG8kdYF2_uEMUnCqB43jH}zU
z^;FP0d9Du0TTjK{Pe@P2futwehmZ0l2sh{3IiH`5MifNI-k%A1$?_3pjO}{>m&x|?
zLRr(a0UdmqrUwvuW%~kQnxSSOe%Ap`2VzV{Lv;x9gRL{SM1XI-e!OU1_<v?y_<w7?
zchNfTqIKLw>$r>7aTl%QE_faHe`|eqbR^BEGz+`zH)m>Ca&pMob~lE^cdJx#wfRH?
z>rz)NcT62z@B5kGejRtw`s{z#`fOd-N&mOjaqGJNS=aq#{_X3%i`H=$t>gYD)^QiD
z&;EC<&;Hiyu8Y=F|8K9SE?OsDv`)HcopjMU>7sSgqiQbo3p|z4{=G%H_r<S`zS_zE
zz=sifCd(D~_y30dVDQmHs`sB?C#~zc=A!k=MeCJ|)+_(-uUE$Bv!bg=14SAr(m;_0
ziZoE9fg%kQX`o00MH(p5K#>NDG*G00f0+hoUbKH<*Z&77qXwzN*&YB`qKx(UVFNzf
z10Xmm)Zc%oTFF-a<NT9<;o5(0PXSu*D@Z}}iNDQ$0QQnfY)=K8nZ+*5EoW;2#sV)o
zW36cywnk-$jOj@|RHc-K5FxFJ66Sr=Z_&lh78KU)l*eReRY<rZI4m%nXlTtxc_6Ll
zQAerSniY^p)VLL)@+ewwLF-sBCz?GQ#6P3>?qQvai51p}AwF5O3QOITY)yzYzot&Z
z%Rqe5Jak&Sa1;@3@#NOoFcIV-VbP%ltx1!xwdllWX@nQ}q_rpZd^#m)5<4zzf5_6I
z^v*+9ex0?`$<Y<j=W*qk7RgFF($*dEAjlfR^PnxOWo}tjLGr&RYeqh@rgq9DE7JMr
zWX1X1>_XPFbpVZll&>nWto|YLFc?q%YxTaIuPJ;wHhel*uEg?HD$ZAyPL8a65K!j2
zzB*sqkm2Ie&esgFtOFwDDl9S}Svl&@{?9Xgu?-*R)6ur!c(JT3og7&|OND!oXIi@0
zuq7?(z*QYLu|sQ(S$So9QWWD{&LFP9{vBD9_;hHE7^Oq$QF%2G+c1|76SlBv=^|?l
zel0((-yt5b9FNJGoLkl~6xXlHSHUkN@#&}#5BV>0)+DQCZdt>qxRRXJ@IH^LP<cx7
zKl*}iu0hP;(#~rGv0V>Rp^8?2mHdKlj_1?S&g+A@<Y(#pV|iVg76s)YYeufTR$=Fv
zzbET-J{@gY<8#YO>HK4|zRE||gJM4tqLc?fAB8Pf;`&Za3#f2u%PQg8C!DXKba=bw
zs6YF^P<Aa&KZQ?U+b<`J?Uys(uaZ-+Uq4!Sh)dfqYsC7@G2cR`rHijR&hwyMR=ehs
zm6>m$(-+r4p47;}^;w?gk~Q0W3!RoOvL^97Xv>-^=0P1P4~8TC8v7OU)sf!=KwDO+
z*nU|$tf&?`t%78wHHoftv$WXyQHcii1l2>fxaqo$wS?q4Q-Rd>z7Hf`9|EZ_@E9np
zIo-nSfNP^rJk&%q#Z4FL9Sy~c<qK@>aFi&VAJZvk+uGsKbYtPrG}llW3loL2EFisM
ze7F%nV}u(i3dglk^G*-#dX`=ckkT6>3a8@JqxPmYpR4eQniH#m)DB%E3Mb{|qxPeA
zxaE8}96iO(gpL=5%P2s;@t`ApqF=`3n<NSsUw}SG^Wnw-Nj~IZPX6(Gev!><^Vx+D
z*9}PRvF@U9TziQtuiD`{@Zmgx6mKU{IIfMu?R}sf?i?TP0+8B77x{1=_?v69Fq>k0
zlHOf#({&VdWUt48WUs#iX-)bmU|--FAd0NyEKsmp176R0$?Xj~(z6ec<n|SX<Jt~+
z%iWU?*BeOjdWphu^*z_-(Ux1mhf@M6y+BbouKvzDz5aYSKOm)t_F}et2YGwQOTMjq
zxFjH@_p>M*SBK`E-UdD#)*G|*HjBa~7htzon#A-O3#4*6TNF-HfZa~v!%YK{-A)&U
z>smnmE#kv10g`-6Md2iTdgRZv^I<L@Za$Fowm=jvwE%tY=ffQYQhJ9(;W(e3w?23B
z;r0M2y}iI!Kw87C>)GDl`Ydi;&kWG@%x+!J;@0(SZ(YxH*7dCBZ+*76u4g~%dS<tE
zE1Dy@WPU=cD^BwQ4c`>Ab}W11-TgmD9BEO_rr++ZL)xEi8@(N4At)f<^6YF~&%|EA
z_`B92HK5r|E2(kQtg5zSzHhbg)1dU4GiyECKhm~UK#3qY-v5=eu6122|G#o3cAS*#
z>OX(hwXSDQ|F_P>?!)x*<+H+dJ?mQ6v$OwK&cxRBOy~dBn(Kq;v`F<#)Z?q|9Obyw
zxT(|56PGRCd0fs6Y~xdFVV^(L9}W97bkP0G<WMx8zvUU*x~|RsZ=H$#t<NO>UpZr2
z*EQUa>XW^EyEC?RU7OvX)#r}g)n}9DH8^^xTdN~;+81l-l(~Gsg$#wu6)(Bhq{C^m
z{{3fhf9ti`x}G_$>)F}5o;f|HA=$xy{)}y1&(8k0pNU<xmbz#y^*?bo^$J#>|KC5G
zTGz9rzx5f`x}Hs4w3fPPEp=hmQlDbw^0r=+EAtzTH+1we>ooD9y-$_tM@G-@>swND
zf7F7bw|!Q9`!lDnV*pR8_vJIEbv=Xm|F^TL|66BHf9tcPquDrIL_pOA*LNGV9FR2f
zT!U*%Z#vjllKcNPU2%5qq!xQNjP}QT6SnsG|NfcNA6a?(@)^;(p6&f_UvvGf&wkeR
zEaav=$iMvO&xmgBM(Iu(wt7WvlQEqxDLN17XW8B0!m-4%M(RhsEbhITw9feO$^YJ2
z(z>46{oguETGzdJ16lrl`OIlu_u|#{Z0f}<-T(aA)ZhBdX?!*-y8b`WKncj%zp(TF
z`SbrUttN~+@K5^yz+k0P>FB^u{bzIkC4M>Q{*^4mxqlTUm<S`fN=ZBo&)1~&1l;_3
z$70;eHb9!U;0hd!2@4s$xp~wwIW16-W2T-WMiv#Nv<3~$H!3fRGv`n4+!XN~bwy0h
znKPK%B4N=1X}*=f!#<t|%qd~>s5L<1!S6F3qH^&-y8rz8oQJ3aco5bZv?<QTgdr}b
zhkC#(&X}X`&FevdNqmukDzOeoU!PxQY%U+od!q9%NM==}axk5s7#+pwg3ivP=fX4b
z+%s2xUi)gir}*P>UjrYi?gAg-Vd}{65Jv|YWd+NNyeC_iW_$=|Z%}$Tr$nKS3}NdS
zDF5ggzl<S!y+bsViqk8R+d1nU=ow`_J*4>P96<^j9uk1;%#q2Ed)69386C+_&ya5R
zGdcs1=Y@skWan(LGM}OJo@9@}eZ*2CNzKlKY}uJ5k{#wPJC_HAkzL3uu}mU4v-ubD
z?#nW9XTgo<WkQi-woP*@wm~U=efj(hgmut?Iij+~2LWZSD?2|0Ud8rf&6j5hO%}qX
zU7lV0@aYA`WS8Xp%Q3emL99Qa+)~*V(uX;)ax9b~6`wZE5v4g%#<-~r#R~byF`Qk9
zDE+@9YZ{+k2i|wN15>EX_TXe?Jaeu~XP;FEJd<1`yCA0^JK3tB=O7Xg7v=*oSuy{O
zr7hJ?8_p+xIdl6eO1mIm)r4Q?lgy{>272=DF1Sh0$^4v6-c@~;ZjP>Vd;`fyWi+=f
zakhJruR6BiJ(b5q+*BS9cH{Jm6GS;zgy$q9&3F6!%1Mjj;LCo2ekkoL{fn`rydj+f
zSgm6**rg&oG&DTSJw!eLE{f%+w(lVyEtGMTXJm7a9&O=OxqRky(36<PMRUH$+{mU$
z2hy&&bP%Y*bJ77IuPeLk>Y@WmU&!kWK7B95N`In>%>0Lx&ja3lu(Wwnt@LyBPkFr%
znXMe6P^ly7{9ir8J_wYC+XSJyu{d+icfA3dQn`nO%hf&PgO!|KINmsa9aM%(sz1sd
zrQH{J6JaF1INdN;gP)|AyxR+3_A^u_a{LUJC)M~l?^E%P(w&I=I?{FJ^Mu?fZ=2cq
zLUf;BIl7_uy4a>rUQkc4I)Q9Rs1w*T&V+K=P%_Uil~+oqIc`>71%6rEfU#PDt~g%B
z>A_&x$;?8#Lf}m(%ap%0koGCuRgmVNEIlrNg|fiWa<vcTt=RT8<q!xLnqthyQG??$
z^sM1+PjKf#n=r?}P$=Qj(lLlseH<xDRwh|Hgr4zwBc3mU-w{Zg)&NcAZBp>Z+P;eT
zeF?hKusyEL%GG_x@r>%B54h?2vp6>|_Z6@berE!yF8%-{+s^{hyy=fXV(t@=@(Yv5
zH5~xOfS6M&DGuyMkAXozthv-g080W#080TU194`u<`A$V@EEWX@OPjg@Dk7ncm-G)
zcn4Socn??=m;p2feh-;y0_y;40qX*#z^1@DKr3KfU~^!7Ahq2a07)P5xViQ-JEw`}
zBTGnk^KjEO5p-0IOafK_P63jQOaoF|Wje4va0ajma3;_JI1AVk7z^|O&IWb`&H;J@
z=K|%xdBB0d`M^lv0^msCVxR`N1W0^R99$b)BB8c7@kxA9okrIr<U?uTbRgNvEFkeY
z2T1uhA6O5#07&tz#m%*q*<5%QpAnud!%f#Jm@mZ#I(7!zdLX^u2qZh8dBk?Wtw1WL
zNkGgQm+S<RoV$Qz2YY}4z<t0F;4i>P;6dPU;IF_~;BUY=z@xyWz!SiDAcm<JzeDgh
z*S_Wa&vE=FIVn!M5+N7yyAAjqa0jp|a5s?hXD`qRxF6^SJP33L{s!y?JOZTrI0l3Z
zmz)5Sy`BWV1Y+oyZ;Qg#@HeH8;+TDQTO#tQ6n<|6lAUY=lHRuiDLj=su5FojxoZYG
z;@=fW<<1>Q{I>(v1$qD*0owzq+;sr90CogYx$^{e2X+GX2X+Pq0=oc7j;=r|cin)K
zfnLBvKyM(GyS_jwcfP<&z<$6hKpBwAoga|Ooj;Juof23bG6exmfx*D~z(GJNcOgJ3
zcVR#(cPb#2y9l75Pp-Yo`5$e4hC=V8PZh8tFcN4CjN<d78sg&Guh0elrtnhS<?%ON
z^Kq6J>2m>pw%2kX`N<W)I>0!fIWQh*16&EDva|}=7WgBuGjKJ~3%Ca82mA>b3`_t<
z0@ngZ0XG3*^O7yV1Hi4ogTU>;Q@|wP8Q>1!HQ-L*4d8CzL*OA`S@8ZF&;WQCXaqb8
ztOYy<lmdSTS^&=j9e@{rt$~+;?!YTR(r-L&u8qyLy-7b}zt)!5uRD<J)dToFumi9*
zup`h6=n1p}b^@YGlXM2Q26h2@0=ojK{B#47-E{{J0QLZ?fIWdjfxUp^fqj6JfZjmj
zvkz{rJ<gpAO?*<mQQUNC@J}B&4p<h5IGBH%2&{tNlYxzaQ-Do@(}9$aGl3NUTHIVa
z9C?GkDSji|%W%_`0y;|XKCnFS5wHgE36SDT13Cbo1KR-+Co6A%0?9t!07>rmK$1HX
zI1Km!NPaB~xE%Nq7zg|WOaK-`KCJ_m044%U@%d(nzqvLu*On%J^>CZwrVC|GQxa$l
zr1J0sA1(-gb8TI=hK0#V`trq1mjZMo=Kvtd9|Eilq_g<QPlW?(0V9A^9)<v00*3<I
z1BU^707n8zuT=iH_AAEq@Hg=(#VwS-r=X+sgfl$f;5XUVTVNgFJ77cLd!Q}wFQ5xB
z6G(dg0PF(H0`>)d1o{I%0YiakfN6#RiUDC85`Ex)U>V>MU|HZXV0qw0U<Kf1U?t!^
zpaJj!&<OYnXbh|ZIcfmw0&4>60c!(ofKs3x&;&^StP#)yXaVdEYzm}yy(N(JL%ebA
zY<8X^(+}BK2yVI>Lk`l9HIV$gJ@5yhBar-jGa%`u1<(=b3Z#5MS=V#~wgq+qf(NFj
zPC%3iNoOFX&&n0wj&;Lt${$M46E|JZDNA1lB);T8vU>%v9xw<<`7;pc41~^EJs$?7
z_`Blf+P7T0m*UsQ-3B*Z&G5Pu5P8bt2M_EF%+^3^KePp!0g>0N&j;DKbu=)N61Aak
zJ(C@!wyZAWKfghv6AwPvxpb)#SN`_z<z&W7A{sUQ)b(c=r>^Tj#&@ImF8ciDU|u%y
zgyR0SQ#BXvj~yRS)n9*Z^BFHX+*yCou^fzk3!|G?sdyJ<?7neFJJstoAg*dF$wy6K
zxMRYIs|~&5l2j{Dptd%k`1++@k3FIBZMdtxee$6S=A#Ujk3N@B-+Ro-9UBdIoq1dz
zZQUrMTT$=&e5opZM%c<KwPVhjE~@VF(J6Sl`;`ah1|BXsuIyC^4h2i~j&`2$KD^}U
zTl-3=_vgKbvl<2=)q7{6uD`0}>)Y1-(@dh;#Lu;{>>c;ZFu$mu6P`)8?CiB!_jwY!
ze!q9MqjbMKPeRx4btNn)zM79u*Zy<sy))}ZC}krP{i+6^do;4f-0j_7gtqLKRweim
z>R32lsoo{~%;w&Q((BAFUs?a4PkfI=mj`war^eoKDRU{N&+E)&-RHG>!=Yn7ceOsr
z^(7PU|5PL6U}HO*r)i;`kACM;ZNbQC(?5>2dIhJg>wMosEWU@nzPC+XRX5M<IX<Vt
z#ZwD@YhJNVR_1Y2_k#}YyFMO23H+fDNcA$-c27Le)1dFFB|i)*Gp_iE!)eFozjUrv
zXTIDuD}Bmp<gKpreRZ8D+eb?2etErvuIso`Sbk)dJMDRNv-C_#^OWNIZ(e!qd#nE~
zU*8VT6QnA0^XOi~Q1`=eNcC<ey<44>u)RW;7v4^8ujdT)3mLrQTA!z$mTAXQ;%mmi
zS$Hdnu2^V?p$h|!tg-enas8{;@#9S=ZGUI_sA=~gFN+rwUo5tkNWS%a+SRCJrFxIY
z-zhaFtNBBhKRRq#9=+VB%Vxc|mj@2<YrHCPj_tNis1z<RIclw2b=N%n<)V#4OUTO~
zGcY@`Zfm5|60c?J${JPp!8pwbeJ^GQU!GT}>-^kzEWV{-`$zBG-t^&<K`sx&N7R2d
zFK}!PQ+Z~DYS^!L=7s3P59vCuLD#cuuCsD}JY|XL!hM^{#*Tk#D1F)6Z%y>E`9l|4
z*631f^kL7~Sv|29xjE^t`|>jphZkHKZqRYUq!8uR%MWS}d)9bG$ACk{D$ma99d3ZS
zz7^3``ejlNi;~R(gI#~>;rG&Gmd~JV4~i+8SjWFu8$aY~)@iiGQNc;|c9?AQ+`qQf
z%BbK;e@<WiwCmve#u?QVrCY6RaA5!J68flkoS6Ts73Ep8e!Yj)SN9wi)+J!r<QbYy
z79U@yJ5M-nRlQYBns>H|$uZF2aYk34DWUnFX<^cs(jAiJ6R|q})Uq0e{Rh1qyTiHG
z_B9?3)mFA!{A;N5=B6(zpzl$K=x*H^-N0z~LyLr|t{%2gJ@n2Ex>4u&dgq&o2{%rd
z1h$2(oM!RuJf$u<&2idHL;dZs?zg(!9lL&8Oh)~WQ}2Z>ToW;2<$AO^7=MfII!NEA
z&AN59^oDsa40qY|E4M1k#C^@i4bB@ZQhVuL!`My}O84s96_O*@ny#`7I{kaV<b)Uc
zKaZ_qv7?`5VqpDZ)oYqPkVtf$cc$xlzED;^?6XSjaae!W)pJ*qPrHAdX!~>V#o_u(
ziq+Zlq}%M*uT0U<{eSFz30zIv+y73;nCcoc9SO-)2n{G>W>P|Nnof%9<eZbrctYkO
z^DJ{Am&`L=8Llxh4_C+(BG-5m|L?Q*J~|Ti{oUTb-+SM)KelgspEW$svz|5VwVw5?
z!mNFHW)Z($_G(~ug{F0H?Or|3K5gH$O7X+Dxs8ppZWWa{Ck6cx3s=LW>aO2g6n#A+
zwT&USZjOa-BYVRfo8XxxE$f&^-<T37e*f&;nk1LwgLkj>HErB#OX9N3F4xZ=eLEo0
zp~0)gX0yWmKVJ1{jRA*PyQBf=`(ZDW<Xhs<sN`pn5igT(B)qElX8-%Hdpg_=Kc(my
zUh*PTnKNld;Q}s<pU(Z-#G=tw*`zX2{x5gj^g1)V_6?bN&$ZjTwaYZd9(bnDPf}hl
z@;8{Ck<jeYyv)witd9HdYgl8_o$afA667~WpGJD+S$n#+wBhS>kAr<XJ7q3jpjujX
zsO+6A==QS#ukC;9I^_n<lz(9Q*FC-b)(hR+pF5iBd4HR8lbv0f<}9|IH`4!#Tk$uk
zyWcBN->iwg4tx68yv<VO1lw8<QN(sI+*N4Hfl?d0aFudS6z^%BGy>l~7=TIi4UQVy
zTz_=HC&rcA{`P#^fG4RtDyO*Zwds-^?)qUvN<WT!&BDD&nLS=T)@<1zNp^?6cJn;?
zO;x=z>)c~alRi1B=-QVsSk0<P=}pZsjW}(!Gu2_zy*H+J6Z`_srg<q{GN%_GvbMQL
zH^(ZNOJL=8NinOO+XKG}8LFKI*W!jef8ZE9ddS4A-$tH!(qU_-rDZXf!^T5DwwpT5
z((5(q>i*^?mlrHPdHTujvzxcu*Y~JU;;)vsT28N3ZA9`QM~p@B@g&iYiw#{}e`4%$
z_whk(I&tHpT(<RgtLpsRpihMsHKxUEMtu{zKdTl7>Jt4@#X7X!-@j)3gof^c%NtqU
zDto5o_BF-z(?6`YwRE4`;8)Cr)S_^Yrq(H6_V)IZ>T{uC!#}n0a2ioJy4*6w%P#Y}
z+?~8tihgDS#)=aCeVaR-_84bZC%R|%q+8zVLaXlXy>lY+x#_K5W0S3yCyqh;!p6nZ
zlFB|^<nd(6fF5PK``2weVRf{B=)2hHNlP0=EqbSab}7DD*!Xm7$)uV?jf+n)3>`IR
zUobb>c*2Nl&6idRkGWU#YV*j@U6^;l09>NK)NB96iQ}I?KKmraU6$--@yDu5rrjcL
zg>Fju^*&d)-0zsXLmw>BZ}DmBo`WO*S{CVDe{07NpPG-%SkutmKP7sEIxN0Q*utAw
ze`ov_JFv8_=i^V;PgZm@$^R@)FP7f5Cn>%!%v+u}d)g$Xy!ZKEEA;NSX`fzf=_u)*
zLJ!_lz(<;BJ93uZk=HISUJm0nEi%2h`=8lguVU>%%21<+Zx=4ke4BY?l(cV;Ru9U&
zJll7_Y4dKO<xDGXU+2ehS6R4m6%G8uvsVpEpZn~{;tfgF4=g!WWmW2sol|d~zToxr
zaX9KPbYG$$y2-dUXYZ<V*nNJP)r09fZ+_@<`%q2&vNp{U{U7YDJ_p}=On#9=%xbF_
z#28E-zo(LGgQ#f_onkH+mo$!@^IP1JN%aQY$6O23mx?D{3YT}EHEw^ir6p##^(%YB
zGc4S|V@|&ct&i<*-_Okp-<Fjq-zmqgY}otJ!){>TKUaq;9Ix%XK7EZr#Qs_CC#S7A
zS1hS8<~&$>Ki;?Ygz425m%?wNx>X%9GOq6Ss!p?0(!<TNd=4k3n!TTUXnxPlz8D{1
zB0-|x-e7H7@~f(q;!BrnJFd0qvY0v}jtpy8xlY9ReTD7sc3F#W^;Q(FOKJP078x6-
z|9;EyP-5}dAJ?3^aB}nP%XVGgl$dcd+YoKRNY?Jgr@i5-M0Byc_Hlbx?`uQ)9##4$
zE63H3-<mNXt#A1DP|VHQQhIe_y2li6p;~IP=KMpa&6oTtO>tk<(LCu^YEY_`nfYz-
z+QF2<Rj=0K-0+Q=ZT7v?KbTo^=^wUcZ8^Vo2QED8*eBS=waq)sJ+k^1RqSKy;)}fW
zdNez~^?IBB<HkO|YWqji@FzvHqAV5{jmC$s*!`MzEWL&e>-6&Y*umW9wVA~1{^pzG
z*On>Xdg7+LqjqmTnIWMwy(1VO#|(cNJ?35X*tZRPepJQua98$hU=|xuvwOVVzS@)C
zJVN`@Ktg<Et0H5HSD6;l{p$8}+YQfm-;^5Gv0O8Q_RE+3@wSTJvrm|lVD)39%H(#>
zMmsZXOU=LX`@15mRvCLOnYTM<yQ+xe+sW6G&%%cg%lFfg%o+E0ZHUTvySUm$!#M}6
zhUq;TWv`BFZN9Mk(s@<9F;~U<qtUbMnmA_8Y0@ul`MIO<$`j49mqagftMzu2^VQ`S
zR%JsErn7vr?S6gUxXS?UY>B~lDipeTB<T;?UnPuAZrI*r$b!^Oub}tKnOxGi-yUYx
zom1&~^?>%rywASx5mom3qf09e*0+oe@_yVF;|Q_))?%4le!Ty^HLI7t$7;sc$trZH
zm)_!)Z+5lYbaC7n|7YeAg&x}v*gtsqZ4-<;8Nc`66?$p0CVlhut;Obcd+gA~?tY5P
zlj?B|W_n#WsCo3+Rm{7gFO=vXSZi>;M?=R#Et_`T)ArQ0DKCQ`tr=rqMw$@VO;T&<
z-#L4<7#siHAEJDouyw<>em>O}#8(-+>-Nys?!P8a+qBvCW7-mB%u#$NvwTZ-*esit
zk#_pho8B}06UvQgaM0J*AmY^A^$8ViWdW|+IZo`pIzu+jp4*_L`pKw@A&+f7JSy7t
z%$W?kPTQ88)_?6%Y}b*|77HRdt_}N+FI>bXaj{qJ?$QSfs*g-`IAngX!p6)EQ_j>#
z?=fK1$LSbDtYz{`cz47tL}mB5)3ZLAo7?o=I`&+A<J3LPtOh0aTkW2Belh0uS$gZw
z6+1ZIVC8%xC-Y02?pn=|bnlp2tKJ#Q3#H4{Xg<EB561T_++!D~lY@MsKmK-p<Ir~*
zhvsg+eL8GvkBdhw{s{CK+qd6NtogA1ZThfZq_6ZGk6rFu{Jio`9r^P;gB$EIu<yTB
zUaM5cChr$vE{e4;BU{U27jDZ^O|kBB*{NvXmU@13nxr``@vm90hu^k$9;GmM#>V%Z
z5-k>PuXnEZ{dd`6`R~&cyWiiDmG9ua!!q_g^%;Hr#@dZ_t-395^y<m7m9m_u^~F7-
zt2@%1;!YNB>D$M5e&69a(x%$PPyH9(^V#|7Mz1POif>%{YKYI4>u1}b-)G;Ai*lmg
zcW~<YI?(sXzRervy|*7X(yU6G<`3>IiXX^j#G;NnJCL5XH#pR3Md9Y9(kcu(9h>?g
z`s}?%k!L2wYzexwae9$G?TU%F4^L+8{hmPy!#j`bHOS*w^_3GmD$O`(=k8}y-&PjB
z=yaxQR{6(RlVJT@hpx`;+w@5@^_vlXFZFf!?`scmy_1HQ-=|158^5HpQV!ZMc_`5@
zH!Nqn;nrHWUpJk6qtT^?PRI9|XFaHqzTUI`n9hpwbC+VSpM}fn8oYGU1J#GF-bN0M
zkA}MLGTE9CH!IW9=g~kXscjr+JHf`WQ_iIwUv1Z||J_=xhYosQ&rmTvW5T<}lg~cB
zG%nerf=39}U|4#stB=n7>q6-4iJeX?wv^00edNzcbrY{9EqHTQH7?@<oh@d`#+~gB
zRNnFZv*&xc5+C;KlJ6}qKL6&P@|73e+xx`!<gn0#dmLu?S~q%D!Sz9>1?Z=(C|uh6
z<<hp5+W6MGb*OXxXRV6ee^-|E=iCX^o~V`P4bz|eR&DU(!GTvcg!(raTk3iC#&a3b
zOY||m66=5F5gU&yt{8P4KfXg@W$%ZwwN7``_1YU9kLwiu@Y({a!mqp<C2*WrzeYD1
zzYBL-9?fnuYkrkVPhTf(ec-gc`TN2W*Q~W62Xab38Txc3+5`3-_2aV!Io+j`fKCGc
z)e^vG27Kh{VRnS${OmmCN>91ZU{6?3`zvIg!GR$|WQq`3kSCnvD?P*Tzo$~+>nYg(
z!(F_0knAhZ|KWjtGT#7ig-RYA7NiQyJp|yt@eF{1^7pUV3vd<V0=ib?E{Z!AcO|r!
zjvmaW&_6IpB~wVleU*@okJO)8cYfQxmS2M-n>lp*SRBPVpxjR;4fP%*!=owQWB9`<
z%EHbgBv2LT9VDd4+d8%p>}~h!Q)Ki5xG9~zxc@-kq1M=Nd(#;R?kKjlC^lDlH!8L^
zIJ*Jih&Bwz^SjvkpoX?EglG%edh(=wwv9s<&-sP(R;)xXSm2uBzo1Y}e!W!+yrXo$
z27g|GZ-C}U#$!di4~3!zg?^@tMWQ%Fn+mtD&*$G*90}ezv3%Oe{Jp^tv4(fm5XT&-
zV(GalWqx1&Zie5<e)k1x1YcM(KdB#|gp{-zafuJ|%T03s9ELASt~P!no7`IEw0;Xi
zHhB^uIuPvBaw<EeG%O^Ll`Q?oN|)>f>0E|F-~k5qV1Ukeur+ST^a%DdNMB<+=nR^8
z{o?h`8HG%`hv6i<>Z7RX8N+1tOd!^&)%d*QT!9$oFyES_r~UB!5*UD+*9~50C_QbP
z1?UA^qxJ_{BJ3a_mLAxebbsIwJY#x=txZP*F?3YV077<Zd`2^0vZRBf@%#!%J{raD
z?Gx+EQS9D6v122#bE#tIcEqmjiS_v?cF(-nwRy2~F=F?$?l+~e^gAQ33*SG-TC6We
zv2(p*eGHz44odWW)V+IkI#zjbpTw-<2b)zlzt}Wx-RY#s)r?athqP3uyNDl~i=D#|
z>w{D5T%}lFonn1!id~x$JGUtIn^df=iP*V2v2%uE=e)$u`4^UuUj2A2t^o`8<2l2=
zEZmQ62Vz;cAJ4UkT>}(5w<vZ_PVCyP*f}b(J}$+s*@^WvDRxdt?Ao5#IT5jIfMVxF
z#I6B~UE>wI2B?R@SV8)7Y^$X7R<unvu`_WPcE8JzOOqo8IF)Wty2hy)rtS2KXAT%y
z?GI1!Yl>ohYl>ZK5WAKnc8yZ(+@07pK(TXFV%NIFuA%O$P30E5|8nMZ|Fh545n1JT
zCa(+|w)VF;{WT-rJc=zcXhDDV6!B|fV%J*5+LVoBYiw4ohT8^gh&;ab)WRZjt!_IT
zPT0|D*TO;_EvCn>Qk&kYD&7WB?3$g}wcvubQ4>2yU(miu#oDM9wC$N#n=-M!E5+KB
ziS=D6c8#r|*SZRN4NI(zsn|8Ff?k^vYkMYk%}K27nb<W&v1?OeZPdiBVTrX>6uZ_X
z*5+5N4X0R}U$HivV%L7e+T@9~Z56u)Bi7fX*tIFqHa#M3*~Hp5h_yKqYqKEMChBct
z8gCSwZIW19#e%kB5^ED6)<#$CUWS!TNq!C!Z_Idd^KND1b^D9AyL9`$;hCu?i`lpK
zkh#{WHm2lp%u(KC;U2X+t_W(Q41U|L{WjlTH}&o=Ih{GmJwq}x{Eg|F-x6nux4jj+
z=RvIPtyr66u{PLZZBfPAHi)&c66*_7?A{WwHn7gkNe^acRm@TQ-T36u`9PWW@?+B$
zC=U59=+$bhZ@<H-^VeE@z}{dM&aCP(#esyf-Gdg_JriGY=GL`uFCR{taxkm^oB_vc
z)GhT?{N56=dmjERz9EalJ_I(Q2T#o?`e1OR<*`IpYo}Wey!ITeIncaosbeKhrY3MV
zVB00uwpy$$n^@aDu{LUAeGH1-Lm_sLmRQ?mu{ITAZDG1G+m**vM`d<1J2`%awb7cR
z(#CgYO+O*)IH&F8!A}?O?48*QYdm6YX2jaUi1mdjc5j$i+a$4jsy1SAN}~T`AB|#t
zFIL0?ltlmkzwbq{XMFv)`e?*5DAw)%=K8;%OgTg)4<&N|S;(-j3;+hfe+}LTD&!%-
zvJjQjUm*{c%9YF=;J?uZz=Sh5ZtY|hVeRAJw7IPnR{LrFwX1Oy7OwXSe$BiJ(OX(O
zhJ7{evbZztu*ZHN?`ud(OYm3)9vUW-26%_~1<9l;2QTjsc}QfiJWMGG@eY<LL%n@v
zb?of4WeewqfgyvGQaa*PrEFzqCoQ0qK;O6R5+v%a_+8`E<^lLn1q5Q|mDZ?vTZPtW
z(`X%;)~Gcya24zjFf3#;AfuBPi2I_TWiYzngz%rpfOsA)lzS<vV7Rn-eh;2kNDH{!
z<)Jc#w@R*%_{il!;>+%>R@o8V!vwnb3v@RD?WC_TVP$1yRnT<%2FaB$DELq1JWx}=
zihw{|zu=}nNw@BRH!ohd{&r2Wv*QUPx{y>p7heZ7`aTr$3PmWg(FkODV&5FTF-fK_
z0*&~ST_B773G-&QAwPzv(LXT65ACL(RPHbJlZW}B2?z-b3X;NL2!>eRD%g-HWoREl
ze7`F%?sMIQ*#_4N)cXf2lq&qKsjtlb#+$uj^l8d`i$I?V!cv(V;(iBWjS9NV(Lo?-
z(Pf@jM+Xb?bTpt;cv`8<>G3Y;RsY9jPCZv($T07qKtCz|50fz(DUYu&zWk|thYR$)
z66k?hI9C!k*~U;^4=rf<!C;8di1bN6shq#Qa@%O~@0M4F-38k)D=KJQfv{VnbY#F!
zp!o%FuO^lHQO87b3Gr4a<l*^s>=d8qU>zSle0ec_BwH==@AeUCYxQ4DCyBoPu)pvL
z^Y@o2$d_M9WAg7t_HGJje4qlVFJ$j44-3)gGTBFweg_G<Og2?1ct<u<@SitKrcegT
zL!=t>DbUE<c72g9Su4WZ9;Hh4gKW37>kQTBcY@8;q*{D^?kvboLPk-zvT>8_-r~Lu
z{=5bVZTn~0u}rks)(nYwxmh4yK9?xDb+yWs8_`d8Y1%TOcO*+~p2&WU`20c+f?$c?
z07gH2_z3*I1aZhl7_0DOm>4KHb?4>+;oS;zYEq@HKx%ut12ysZ{+;gw^Tu-*;`J5c
z_0x*S_mTO>n<&JaB*dF6#B)a8d>_Se)OS&S)U0W2;Ua~2!-3Q%j{sHxjsk*RZZwek
zx-meapLCk<L-@WW6a`IPBW&u}g(04r+MY_lGC)%x@eg%o@rfS3eJ7vQXbTWuo1VG|
zN6%<0m_L?!Kx#k8R*z&3T9{uk{QX&;e0xmoInSSVIl!)wl>>YptEv4SCh$RN@$Dkt
zUJ@PJ@vt3(@qsO0YHG$LTKVzq7snA@dCPAs(x<j=9FW?(@j`y__?vG-__l@eBYKzO
zrmHK`$1Czz!{px!SR2nSK(Zxt1v&%WfbKxt%+C<nC{Dn$FK`;r54alW4@?3M0;T{1
zfKP!#faEVI3|J314A>DE0i?Dr5=iB&#?9ATzCIJZrSXn+R6rX9A$rkgGkTi?iC*Xj
zqZgm~j9%y&qqh~%2fsT4#{!*zvw&@Yn}F?s*MJ>>Z-E_wuYms>&a3u7K}+<Dp4w>F
z^OvGI*D4I=;#+y_X}IRf1cw}dUpJLaopXzx9TUILbvH|IWywPw25sALy+w&3>f6z+
zV-MVPI5z8~dy6IZgZgDvx{t~#))rE%ZRInTZ`>Wur>!JD&7=kP>`gso7L`=TA?~b4
z;)Mn8C*~ZCT!D743h}%1R}(+?+s>bwOdB@QJFD?S#XFn%4=d?yxo8=*r|c3pD70AH
zyMngC6l=>T*0xgY{v)wAj$&;W)9aI*XYcDZ`=-sbDkD>t={wtcCp%jm%vrGE@aUv<
zkylq`uV0Hc1C15-Z~b}7bzIwyQx4catTQ0(QP-V!yxXs_a+~YW*ZS_Z4TC3$-|zgh
zY!WA<k(cPZIEMSiz3qLuyiC&iZP>X=u?>1A?yc7D{n@T|&4*kcy@TV#+OYmxY#e`<
z?V?y4!k=a1*jGaO@?+aiv9^n1Z6W_HHjZL#`F@ryq*xocf<FIxI%e)*gIViV`B=q^
zeGNM{>T=v5<3-uj2^G&285ujza&=7fFK;lQ73+uPXW2p)v@P1d#kNwc9}%6+WMGRG
zAD$`>yI6GG*1Tw&j6FH>kD>Ucv7q|VcS6&NhvSS-miW`;Tz2}WW9!xpDq7QX&&q*w
zu3eu0G86-Uu{M)pZ3xBMLW;E^jKasJM0fsmhhC1dSEFkC-|l@Tqy6rTg7?#*vvJJd
zzn;#<F@L|Ny7RB|_wy;%7E)*9n7`jQosDDuen`dIIO@*79#mz{k}+GnBqr&;);-=H
zN~vf$0Taak?Y59V%f?ZxU+n*Dwu`!Rt)G?2ncAs+)z)>Aa#Uk-?xn@Wmm7x(e=G=z
z@h>mdmhWesYyGoq9L3s_{wy0uu|6$y=T+Zb>iCC8pPsAJ-YNU|TZZ4*RB;d%3&r{&
z#j=_1(n&xk0i6VN63|INCxO2q0kUQ4U%>YNIKLLQZp_>tHct-5dR}Ck`3r2L(qUGk
z!ES-R3b|75uaa1})RpuIRRsnI4u>tfq^&$SG%yH;fMi!Ml@9ZjdaGdN?h~ex(V4&I
z#sRV*7&~jfC7UX9V{cUu@}M|mvq-1A%A~>GA@E2?+YtCLN|hgcnVB2A!`N0Hu7r)N
zxp4<r|M_{VU@ORnaca})2Vr>I{yu`;r-}@za8)mgv#)@rKz$el9rj{&fc!zuu-#R`
zYEu#DO@_UJAzv6$hRESdafk!?mxJLD*-|cKDf0hO841@Hw!O_@>@0`eh;FiNq`b-Y
z5$2)Togod94U+{);i54J@5%lWCVv`#a|&6o944gvd$I+b0OL0;14YP@KNpznGUeeR
zFu>I0L^f_Ejc+0j<;A}RKYlWpRPpJN4I<G7(@l6JR0a+LeRM9a1MIC53gNp4;j(;5
zHvE18vg3q(78i({(msvn4A}eNOlxf^F<WI#IykqMyMyqX{P=W;|1`uSn?@}@1j|l7
z-HZ60`21eFI1iJv1Yrwhe7a;mc@^=r?NjO92_Y|Sd(;%XBfe>`21sM}q{+fN-kO-V
zA0?aN{(|moFG3-4?yaCZX22rQoizWysXO7MJW>_ZN3{OX9t};Y{!{%K_YM6a`_%tL
ze~7lc`V)b&d5X%Q29M<ie_wy>5dT}{OzE_P+)01V3+af}AL8?S>25)~4WU2#hkU6&
zdF^z+r9Z@XUj3nWdG)82#^xOQLKmI2O7@9#)~GqPJ)wgBghp!DAx#s*bVNcCzrI)-
zL-ml-qxyn#!L`$1dQCRlnmQVYww3Ax*>}@B3QzB-%^_c!RJYLpD<Xy3NNJNzat;hi
z^U9Ly_io5=H~2C~yqk;<zMY_UiqfaFsSatvzChS<2pcezmpP?RZBTyp%@mLBHiG<G
z5R<sH<yQytb5!InKdoveT85-E-;$w5Pqk%8@5IWm9t?!@li@qa<O2+ONrs+`ms}ZA
z`r0z2uuUNclHnsEtQZ+;_F<e5WY`1o$#%Fi?vH2()xk`LvJhpM0yg$x3I**3)NY;8
zQ-#QB%LVVeR{N(fyF?~yRQ=DF*56EDsZ2wJGW8@wbX<Aq@sj^@dh(XP79E_{-=Asf
zAkb8?1W!{8fW$QocWG+pc^R?2Ki?Y^e0!hAm-~IlZ>@IwL1O}{2SKusL8<^=2Q>9m
zQ%9*T=k5PVo}C5SujWI0Wol!1d47lXTxp4=pY|z;p<koJ)W#6~dHWxt-$&S|;Y9}O
zxJVXgT9_}}lAu3@mpwmR<hxI{i;{07?d)jRi(G-hq>M(A`6#C_R-?4PzH;{m`3rPB
z&4&(C(6NP=<JWX(#3zmvR!6?3gWlxQGEAUlH&YC@Pl3s#5<-=wG7VvM<ZD{k*woIB
zMzPwG(2QuA%p{f)?7LB_B(>{PaLuD;O!7V2s2r(Y?5K^s8r}-*XtknftPdelO+Xv}
z-kQCq@*OSkvXl(<aS;zxz7=qrA^Zxy5B!>!T)BRe9U+K@1#pz-jfk?>@Ko+I?O*al
zJ_NLRqP;hXLVs5izY&ivToGf(KE-IPES1Uv_^rVT^VY4+RlZ8!0EMGdn_f=s+Bvp1
z|B6k=c8-p{oq9U8V?oT#5zetcM1!%X5p7Z75)A2ooF{_Y9Jej*V#wF%2lax_IlmHb
z#dJ_mEu_ZpmEq~PVr^mx&W`OpDv#eZ^7&So7tJFdl1CrN!|O-#kh<qD5UD#a5ve<g
zMCz_36HQxjq6{OO!+sPd6WWVX0d%B&t6t>lk|35mdLq;XO&!Q98=jYM%jR3Ulb>u9
zLb=AH4W+9FZmJJhvgPW5hr`P6*KJ||!$qa0WNX(C3!$$!nV%#uM3uK{*JkyQ+I1wK
z&&9Vnnlf(mje0G!`mzpCcuFugeB;mceYn714Ab5(`D+0FUVMwcFUyFrm|IHU;8H7q
zrtI=z60g4G)B11nnHxTrPffcvk~U1?(k@41@EP+hT@>2ryyd8AlfPG*LYTi*rr)Z!
z-zwAG@VUHB5Xv+Z<HfwZRtK-4KW@W6vzuFF-{ttLV1K84zf~W<#dB`>T%P*~JQps@
z^Ndd#R!>O;Wr*h=moJ8Mnp&D$a$@UZZaMJ%5w)uW1)5gmLsM1I)KgSB5Lx+(_lIK>
zO*@e*uUy(R^<f$b3YT_$s14eT_;0nZIzT2NxWs^h(D4dELA=O#fqgYp$-f==JG!y`
z8+AXoE#t>7nl>(1XL5BzQy<jSLFVDLE_jU*)y4_zYKkH+$C~$+=$!Iv6u`7tU8++@
z(|&(Bw#jYRe$2CrpnDcHaKlv@H}zXIo+}QXy?#6%3CXPx_0d=H;}As8=lZg}cEI;@
ze&bEs&+l``o0@Uc)qLoz2s#~qJdP(-{GyWZ)QXpP=g)L~DewH~Z6<ubb*;#Yfx1nS
zD-ChlA{~hr8xPQDj@FR=d$e$D45z89p-4w6^_MGxX(pK;uWIr<oKK#;kf-B6%yVcy
zd1~gu97ths(HM*Pq|a93b46~R`OGx@Gk!IB@6IQ0;&)2{<^4Urn_|;BUE1Ya3Hqqc
z&0DStz>3Kir7WKB@8!KEpS(*@oh_ie^V6}0n)aeH&o@;^DsSo@vavz?Fz;^zu95J8
zgm>R-%NpZ%n!BWLPnx@z;$$H#LSbDfcRfYgHh_JLY5MJ}`Q)nyp3^jbKA7K!yz4#r
z_|M?yxV}RlfBus;ePZY9`EMouJ8u&9FVm$hr$V5Y<I70!@sXF_uY6Vr)P7H%U()+`
z))$E0mmsMp)`t!=y7=`p+J}$5@mxE+rz;+6P4ydl=$XHUUxC(m-U4(6CIV?8Y9}xO
zxC{6mxDQwsAJM-7D*;ac>jO^$oq(r-LBI>Zp}<t&FyK|-XyA3=Jm78M8sHt^17JGv
zHShtj6li=5tPFet901G&1_56H#{si}vw<Ig3xOYjzX3l1uL1S-IQ4U&0niZZ6vctH
zfTe)ez%sz*KqFvxpb5|$_zTb%2;S67fu_J!z$(B*U^U=2pcyb3Xb$`xSQmI62;T_m
zM?lC#{S0Ugd<|?2<S?<>6j%Y+9B2--1=<6#rl*GQ46Y>*J|MW(z!ktYz(inM;2~gp
z;8|dI;8kExU<R-kurw;K3$O~%73c(X2X+Pa1&#sYyjAr~pa*b1Z~*WOPzt;X^aB0`
z^Z^zs3cnCQT8D*?2j<^_^on0o<Ja2$iC#hHm|meQnO>Dg`TvIUs|+N)qV*rrEAY<r
zDg;P+r38{*MF2^!)Iid!1whiPb-+8oN5FL8TOjF`A!sMPstP2%k^)JuLV%=K(LmCx
zxj@pZ#X!=lWFYC)4It^&pFq+p6O=3IRb3$Il?{;e${t91<pLzVk^xDt1_4R0Rscz_
z)&WVcb^uAQb^%GRP5?=-&HzcTE&)leo&rg)vVf#l?}4OOg;D;bSCxUJR~A6htJXl$
zt0*Ap6@0xgy;=h#z1jgJy*dIUy}AG-y}Ah`y~+fVUKv9lNUtP7(yR7B(yN|8(yMVm
z(yMtu(yQe_(yL2A(yKHe=@sb{=~W3quV{@{qgRKa1N>SWzlKD5Mg7or+;r7|{PBu2
z2O0uv1L=25AT`VNfHpw50#MVpMnj+@5N(>;7l{5ztpGL!h69@eM*&*^Cjo7N@j!dv
zUZ4XIy1`-IO8o}d8c2HD21x!-+5)YB?SZsb*a7$wzaPfUuX+9N<^ysO)}8qEA1V*1
z!)JdzJ@GTGQS}1W1oj4Y2D$-B4iukXC;HFgM<71Grh{)a{7v~&e-(tAE<fahSIkch
z^~bPzP*(#E2BK`)nRz{cay)}ZP6?#)4+E-zk-#y);lL;$bb<N784V=*DSv)l=I7)u
zLH_)@3eWdDv^h{S=I;`~{P7T-65RZ{NB-f6KTSA(O@jX}{9bzed_Vu)m^Ykudi?x0
zKkuD4+z_pN`8i*vD_q`i+UfE0s{Fh}-f-IK@$-}Uhtp1vpWn+roOXKr+*tnMwA16~
zllXS&d-U;hJo$&yPLH2&$v<Ch`uMqu{KILd$A91dxP1BV>-@uMrza7{kH*k3s(;%0
zhj*X#%JDnlOtiwS5W-PC&YK?U@aOdSZ#`b0^M<Ra6;Az~e9<?2PS5K*;V@0d!dZbP
z{(FZX-#-Gs=w7M6VHd`xYII}V8z9o=FsAq%kN;lb;}N~u@rDTTf`oX%TJbo6E^5E>
z#={tg<);$jg#lk7oX)S6&ac&|Nkcz$LkBGOY*C$GE1h2}TMS@zeyzB5b1Zxt*&F8A
z1kWsKS;sv3#*{eND%Zd`N`Le$yC#mAbDH#vTYm0nyz)e|>?P65+-kiY<$QJdg;m+U
z9H;YZwavN7&Mr-J7TeAn>3_wo_?y(-?-e-j+Kl8EefpPYp%(K?UU@%q*88dR$9i;l
zwR?Yy!Ot354qkHlpyN3BtYqN~jvCuse{{en#+BRt_I%rbC#gFsr?~C4>5?4o`e8##
zKYaVMa8u5u9bawNt^eIxt%nYJU(Zl6J!8VV#*@!JzBDe`qk=~W#})M1ojSi(ow)H)
zF57y$Rds%D(5FI+8q;DnU*k9nd@xD$AI~|HqukqOV!OSwN+;z+m!DX;S;Hw8Z0k$n
z67-gwIi9TZYZZPk^>z5~YY%X}lZKbyr${v$zofGgAE5v3XNKzhTFH{#EdE$^$+TO<
zt<X&=zuxBxm-`)aUKXVH&NY2*7AvGbG_zFoSe;+1vzU0>RF~v(%5;iswbT3<EAw-^
zw^%oL_U53Ck*85qiw|!?70xytUt^Azg{!uH)jdo3%Y~aF3wxJ3Ze($CeWJp4vHQ~X
zB}__JHhqc@M6qXl>dx*QndorH{9uKRnH#2@sgd4ez^ISY(O2ru?yPIoZF!?tPnNBe
z<wUJ7?ipR(5%ba9zvb*sonI@RU#kk~9H%?GbMc0x>Iaq_tFkI}$j+%ZPhaqQ`ZyeW
zF`80;G`B%X^^;K*Lmu0FcvQ6OnKK!7owhAGt^eAk*sdd^Ef!$Hzo5_V)cLj2`L!ae
zZLw!}>ik+|cAjQ++<#xg8k6p9U+t41zd0KABAm{zmCmo#|HRpyI=@y+e{E1!k!>-d
zx%zV1=ttL&_pd(~3+H0b0$qef{hx6b=zr@OpJ=LdmrepY3FsuClYmYFItl0`pp$@3
z0y+ukB)}Dh3<myP|9{@0q42Qh862qe^^6EsdCGkT`zvIgflXR8^JE@1a8j^B8Z7sd
zF(-ikW*>mfguQ5zLcB8V1;CV&_8)PRVWcTh@je&66brwH3R7_TUFybotMR`@KK7V@
zr_Unged#%3orv~{kPT)VmIoh)d}J}deB`rBD-P|iB7a#FuL@{|X$0pb#H0P3<d2Kq
zN!v$+D(G}+{7rG_uEv!zrr)k&!-76`e0r06MXkhNQd+oqUOA3rAb}8y16^^`1)iAQ
zdlMj*{@A{SdO$loHwDuE1zVsa5I5VOupQV5&m>FO=rcRgVwI5=jA<qMn+9z&wV!qN
z(9AOHwj_;mZ9VDn>*2|9XG$OGvS{zQ`_E=#&jt%OUOm3-^_Nk@q}8MoN2Df%7rIz+
z-1OL0sv^~nu8UX_eE@dyEL^y=+amkK(sLJ{o4z>z`G<onT&BE9#Z#A;ZCO<^`<d4Z
zgVG^O65AWLKX@l{Z(PiSsy0L6+mMBunqwMq+G=O2!=!s}Oz$T61)NRuQo3YLFFs^#
zbB}J0kY(da#K)9lS2pbZ=wUao@1Ltf6^_?-UZ1|kAY%V4_mk6BoGX@u3M%$IQ?cix
zUT68v`1S3+O3|;!KeBT5?bNpE2e%EEf*0OjuIy09;c3D<)BdnyHYNIesuXgGkGGDp
znVr0TU`4xz!|xBwJ}_d+)d`#bu07{|mfkxfuM4BAF7fg|{i4(R`X%2Nx;Ex&H=lza
zM(Ud_^SyuI2*-&%r?eJyL84!(Sclg8``3)0(9k__c_XV^WzV$SzNWZ-`iJ$lmhN*K
z{3`zZ%+oAAA9e3uosLx=+$S-s_`zn?%`Y~MTX#BXay8==%ONe*=`OIlL)l66&&A*K
z3EpcQuxP>650^a#WWU<~e0tilE9sA-hAneGFI$DZH!Pg*v6}I9vI-sQrMGzHn_cZT
zT^x7D|CxD2p~v<E_75I@+eG~NvSQCs6?+b?So_+Z*r4)nIB)geVn^CnLgn$}b3kKR
zxW2Rdl|HyWIHtmo%lik-?K<!M=oy37Rk*kOT6V<g9Gi6b&brCM)i9~L>-QE#Uyn#_
zWBAYPO@G$;sABD0Khz-kbx$w9^+Nad=Z>a&-p}7YRO~sb{}wyapLOo3o;j6AQonvr
zd@Z-U998d>eSq?eh4R29|Cm6>WphH_&$*eHgz<zu3l|p~y1M?v*yHZwgW#t*Kf6zV
z3|1ui0gD=cY&xT`bZnXPwR+WFf6CO+q3GD>)gAX{mLGd5ByGQVyHBz9wLk0J(|^l3
zrDD&&)!BXiciDXw^troY&prKF=b4H<zg4V#sMzycb#|mWJJOh=_(q140EzzKy~8s0
zJ@pxV{l?mj|86_diH(Tg^a$@^mR)+S3RpU2QREcU(E&}|lxYspqg{I`w#++v0yf)8
zEZjp+&)epXp|{TNJu$oV#nbbTv^1=dlYPRx!{O$gdOjXMk>lR6a7#iCjM=rV(Zh@(
z4iDucYd@RoKemdwclOZG;lJIT8)V>#?{h24H|_m$Y1>L|d~4l0)H%3&&AKz5Eh$#?
zd8cPV^ENGe`mpp^?Ad4Gn&lMU+kC@0$F92@e%iBoLem|E7Re13>(%%*qt~q0ugtSK
zZVe0fc>LX>Q8_IiI^5~J<)7JynphKk``+2vUbxz%P4!RN@6xua&DI)uXL!Hu^r7dw
z;r@@N#laDT?tE0;`KbRBcBCsYaVODtn0RBxlbd%d8?W16yxpbS_YKcXJz31YwTH~L
zPPH*5k7LvMO&0D^yW@(WHp<|)?b>hi?R8V{?vm4)quetjGsEAQuK6u-7JSawP<jjR
zHJ7}9I`faK#Wv2(GTz-}K*?1(W*ydU+Gw}2ewv&9HMD;$+>ht4MzC;_<&io2wiO?$
zGVHhYdV`<|cSjm7OR1N+bbk${{D66FIFkC6g&S=2_(e~T$-y?k3xof6+K29FM)K2l
z8~#cEa`lb-*PK}UtNHrp-d$_F4~gzP$ZkSv+hDtKm`wdy=c9%-C;H5)E>j#xDBC?~
zaoscVC1-A3`}XqTq$vlp`p+3~yhhzpPjMbQ3wNnmcFTTAnKfpWDr<1qV@2--hX*zf
zr^MWKD1Irt@9XRo=oJf>UGhxVW1A&sZ??Qy=)kQjk3Ihw_=l%w=jU;fP)o}&x8d+<
z)PnM@b$)5=qS>=-9%gNu7G7cDjaPcVj^=t!kF|4edVPV-I>@Cx3-{ysNhJ&SVchyr
zw^pvdH*R=|y}wki6=pR2>9hK`?wTa*dG~(pTH6sE7t6x!G~3$sKzy5(%D{<#PFwb*
z=dk;xFDm*LYqPS>!2`1j8(=@^MHcQ!%Iih`2GcVVnq8WgzrAU3TjFEs!BaDeJ{TNn
zc`VV@+UeE<uRTX=4m9st>R5@BsR`T-?DuWU!WFyqDf+28t6sT)=KId}m_Jwjam78$
zV%Pr|nKbz9sbaIw!&eLocg*mY(PQ34kA2&)=SNjc4|iqH24=AlHM_^#?W;ZM%_Gd8
zu4Ccq#B`4--a@t1WX<`9PMa_JRhr_ys-t<*t<<1YD>L)k*k5&<h5NK5bH@E$8=^Aa
zF0QuGaLxg%VS0~7*{kDPn=kCXbY2y2_!qGwKISzzRc+FnI^B9?Y}n^)YaCp9^pv5!
zyY?EjY{oUq4u!|8h0iw@uCe>3DX$&+7C+c+K!ty1Z<@f;vz_tkU7g|8ZuCvBGH`5@
zM>ij;+MDg2v2a;T_c@D9Yjwr^{Ua7mamA?X`0*VID|<hbt#!JiuGik^cwDFGhu0QZ
z6@KN_C;>d!6CdS<<!m?HTI=@frju_py429=_&)Qj2Q|{yd)6P*Sy6uOQuvu+;T~5V
zmD$bg<oFrZMr)2r8{e5V{e-OJoVJq(KV7`Dcjo_u9jVxJV}I89s2d$feh>e8RpHN+
z+qZLiMcJS6Fn@agMs!QZNq0__ud;Pa{p7M!#M^yV#8~HN*nMtf`DRCqN)3Knt5?q*
zg`4|FOd8{KH08!7qYt$V+P4~!(WbZ>zTQ~4kx?zSw<<KzJT0fJz3$voPIvuO3DElg
z-#-8Ed+YyL8xHo7NARcr(faPc@BBYHm$0>yRYVgTf9qzlW-=<kq8xuFpys@v&_aB%
z!k;3u2Y{bNt`YSEVay&tb0%PbJX{(qQz~&rp%hZ%J(g2U@>yGvPa^OC%m=f^CoG-!
zqmo5n#+&zJTM9_;e7*UD0V$jj{fPfmk)e!MI_r$i09sxa{^(>rVS@(orzv{-2FUz`
zbp8^4R}zI`fy{OQz7;u7@YM=oIx{|an}cj2EKYOslPQPL*@Ms!-hP12G_erE7AwcU
z)5vJ9J`u)zPJWh=HDqKp?7K1&yqEJnzQxFh&J@ZkBYO8gAtM#!qXu6jqyCH!aWZNl
zgw@DswqRG1Kot}hmOi*5xXo}kg^awydAkyJ)MY+r7ilXM&b+j<3keGf3RU5RK>lc+
zye{F{c|Cbwe)bI?Bo7%R-luwV%&+9<Q$5!|{+B-CbKmoR@W~zps>$`icNw2f6A~v!
zwkXR5xulRVaB0iM9&$<hmRvMiV`ujr(P$jw=M}`a-scez==q+n>8<!(<2(IZGRpO*
z|D}v_-~U)f^930_ElLvlQbx@oqnK~WNH{-4TR_h4-P=i}63hQYYqSoHVdW=QHa4KK
zAoM5qe1)&|$B2xy^2nwo@->S1M!m{ke?E)nTN?7M_n$Q<kC6VUjB@ovoc`n|qrrmy
z>=tAM6BX9>pvmMKLq?82&>wl2Dl|-mz5rbdj^QPL>iM3$K}sQ(-`qAL_gs(=fld_}
zn&J8dH#H0B{<s#P^YFLm%q`3ONc~2UiEsaM%Ydhq`oL3+7TCRkE^5a*2((uz0b+4g
z#!a+W!ri4N+A+aykT<qty|CawUaNK@?6>9jr7!mXWSl^Bwh`z&oDZF!Bp`tG?RtVy
zAfuBxj@PDAERFw3KTR~g1Q{{7`LPv0o;VEMErWOCanpr<li45E0#YA}=?b+a5VzV2
zSRaVbQI6~r`v5UzsU8T#l$tsKh$#W}SRjf|Js;=@+y?9bJOp$GV(N<P0;I8CSD=P2
zemwKvMVAD$@?!|Te<)VyOFyaFeq8xJHUDtK1wJV~zF)~doOXJA8=HSP?ezF|hQ_rR
zLw|=pzMk{-KW{iqdQ`@Io#N{n=?4uzY5YJ}Z}36&&lN~@&`scr;_*73e>^M`v3LW7
zc+eSUr<#Hay&K9U(O+5eP=`U=HeCO<|IdQ9XMM)<jl0A7w3WoCnY6%~;nY)RQAu?i
z;?8;`URdycV$Q+H6*{}u|6g{m>1bRe`m^`-ntjt|T9uJ0%k-UXy_21-4(2S_aCmgm
zy2z`mve&Q0nbD>c?#J`b1#KTY8P4Y=`Yw*)zHx7RUoJ0`w0;|Qu2O7+o{4*_wR?ZI
zt6lRU*GKQr+0nYa8Dp}b&j%Ne+MAYIElPcJt?kL|o^U3wv!lJ<rvJFHkFVPP(KP%?
z(X1$o#YLk}aNP3hq*rO&Zx1u;&Z+dgdO-VQ-e=$Uh$?&i(WMm!>s!VKc|UHO!f|I<
zxM@jcpDyxvGG#!IGTr^_HlDCL+CTJNZ1kk1jiMI4(?7cue*7hr-ZP8%^|Dt3vnw>M
zdu#XVarSBZrd5g`zRhiHoOP?H#5qW>0SlL{ii{~<Wm-u0tJ}|QH$2~cQ)*bpa?K3d
zFJJb@+bVv~KH&@q7EWhJ8{ar}Pcy4QiTzf)C!Sv{-e0WFj<$10n+eN{y}i_Vw`bk4
zq2a|$K73MR4-Lle68%exS>@aw_*KYI?KHR+H{|&P$Jo(BCT9IM^30PCTRSbq1jk$!
z?)c!{Ykf@{x7w1pEVIk?^GDwfNOWlMYO&d@aQ}~2Jz6{A3>g-#*Ql%eo10u-u=wQZ
zC%eyX-fmytqe6+lTHb0oy;ijm$%7m*e#2m<Anj<^t0=wGONNYDnO$l_dUA9~WV(yR
z__RvH>e){l*{ZhJfG+K#%j@iD-Aq<(tGGS1&XyYP+h-fKv3h=@M)oRvD3rxVhD4t`
zq1qF*(!62%li#Whempqv%7#$?24hP-&)#@0BYKH`I?k71;VPbVDO}!t*0}x6mX?^|
z*01ah&#-U<k2(D+v_7`KeLpuZj+?;3?c3bxw8uERI?+A5C*AT^7g}|9@0}Bo&rNUj
z8k=mrJaG)pBx2!W_g~JO?tk{VIwGt5&g7M0!`A*5r@v;zn@6!l1}*5Xo`Q8w7Vc%*
ztnpP^eQZ>5%tQSZuYFEGa6LKp!L+8$7H$bSHfG5Rtm#&-Lwsy4nN)MAaq%gJp`+&P
z3+5&pPZ)8n`O-?^G52a-Z5|oA3u9*%ZfwIpmOU6eqJ=|B!r8)SE9gCSPG45nWzRUX
zW!9ymYU<;oY#a+`<!ZQXz=p`<YfmjKGS}+1v*CmtopvoO)X`#k{3^BSt*SW7i-jAI
zc0J~#+OzKN+RajuN?VRLS~li<T<v~Qr*>{K-hK8lczD9XZE-35CaPQ25hLU3Zm;Sz
zJ0(5bEX(I`VyfBuxrgTW-0X{QWeehCsn`CC6URS)eD+C-yUva_)_~)5cC@EA_m}HW
z%GzA9<h&(ghsM-f=&)rG&WgeYMT!1_wFc*VG;}P~vT4^nZBJdB@-q0*nlbieqzQrD
zB(;W`X5kDT7H+2MuIps4xvM924-CsO-`1%`hhC1dSEFkC-|l@Tqy6p-*tM{5B|B`E
zP0L6-ed$f_8U6|7#xywSYikg3YVP`king)<*X<m4gM}O5ow8He{l&QYRz;n;M=6zC
zn_O6Cej@RJ!M3OOc3IBBhiPH<T~YP%nd*Ngrk`CuQYIah;8h{;{G(A-=4|Vg72LYl
z({h22us@WAD_q1Taj{qJ?$QSfs_X1%b#}BmJKCJmPli5SiTNdKs^>a8TG?MEj81OY
z-ekyv)J?DEU_PQT$)&}ose2BN{A*dHcm1t8J6fF`t<H{CXGg2Eqt)5b>g;Go)oPK}
zZMs3V&J){6t=HlE5(|hD{m?rNpC5G`v+ZDHjjK0PZocl9bs=N!V5coxEZSv`v{%3e
z%9(|0Z*Zv7io(rHrBxVoIyUt~^x1ojBF{{U*%EYV<MbkX+F^Za91Hg%-X-Cnt5N?|
ziz^Q)KCaNn<fkX*y|k-XW1hETPUhq_O*u|yNBht0Xg%0^S<zD)?Rx%FH0N4{!CZVR
zk39|7T$$jI<L~RHvZ-@!(X(Tm?$Sv>Cjp%VbP~`>;9nzw!r<gTwf_&2hX=~PasVh-
z`Ui&i%Y_X9|3>?Njjg}GU>iq%_~^ot1@n1V0qBMGpBLk_Y)N6~DN}@a2T9>6Q6>$Q
z2L<{@+S$oNWeRVVTwzhyLCQ?InM|bt-XVTLGO3@p${R+KWIspc^z|kAycdA%`G;do
zQ56uVq;Q6?p~euB8wff=fn+DQSD^PPY^msixe22e(YQ_smo`?5-ms9sp<yy<fXq8o
z3cK-dkyoE5J3sDP+1c?w7C=&>W#9-t^2%UllUx}b6l9RDPZHqIIw$i{vKj4xxSV#G
z6#(IOcB2bU2p~_aE@;bv%6_!K_fkQT@EO9&p7`z!zPA)O-x}4H_{il!qUm<gDnFuo
zxInib8Ry}`QaD!<H%vyjo(L-`aJv0uDr|&7@{DGxLtkHC);n!k(|((GsEed?L2_Tz
z_fS^%h6#L>Ey|}xHjSirhPYk9M@oV7F-WFD+G6$PTXH`k(2GwbCimJv(ie4s(~I3h
za6204Cr<7p<8RSC5^I`t5v`;vX1J+t_bhOl6|x|iw^D}mNzOmg6{1;NS4h7#cHkq0
z$ZqIM=+9ojR-oByjL;@Cr>lJL;H!{%tI#y_orJeS;T_5HuY!2_T+E*=>E$DhUV1A@
zHDFiE>uP`G!>7W(BOkJ)zy5&=7LfeLsv*+|5Ox*ujxd_|K8E_8F|{}@5GhhPbA(ah
zHb*#xnrP?4Y5dCu;+go?+?_S`Td?8phu?{R*xz!VpzAP8Lt|gg^N&qtDuq1qO93D}
zl|d<BKG$a%P};<sHort0tFL+F@|6q_xhLoZyWCwZ-n3;ve38BXC*k*MXlS*|`DzKC
zy1oz$mRGnAK;|bn>g#frg($-mGO2%nR2C7aR4FMY@o2#(!TvYG|2=Q(ArD8!V+qdA
z_yqWYSq{p#h_Ns0(>e35-L2s*fq&=o`CVfofrZO`XKkZ-*Y|Tc>t<iSYYZv!akauV
zrFWXK2l*lP51=q5jjw_xQaYu|TNMUQNLK<N%Xr9RG~T-~{`vh;H-)fyeGzNoTtpln
z#Casdq5RSjCk*ej^~+Ast-jO<;G*_`x)IXNgtBPE7=K^t7TW9~kT{bwg5`HHIp^h(
z%6vI5FHTeDn!OWU1*J?uYNUUsamQHU9{qKhlb>k0Qc!J#`*yp+@9)S<2g#bUBiW-l
z4WqV+<mL$(RKyR?c)rT=<@Y60n`DWwLSv$d!gQ8+`Y430TZ78g*0_{V_chO^TF<2C
ztpu5;2t4PN`IdZS9u}gJI?pdi%<uZ9+|TBbyT&K?Rq9-ET@&isabR-{cn*)?<?bDX
zd?9WBfDrULeBMlf=>ZqS!dd01Tl*m|P2CzlinVW4x8T8puM6Wozia%t9_7Bvtw)ic
z!{ye?+;@#X*SFkvntEB%I7O%*3Yju22$hP;_afxI9sGKO#}XqMU928by`XwW^@74B
z!{6%`glma#b%k)GGp7+QZyR_~c&FVDJVkt0#2<q6nrY=j^;=WlNe?J53Y&ni2?)Da
zD{LCVQlAkTC}-jNB1}B)DF}B(D;%{0+G$d{nwxa-u@IK(8$Ey0dZuuV1zilKjX<~_
z;x3B&9&T!LSFkeB<G;uRHK6)d7{BLpeN+D|^3;*0d7d4$o{27vezqe8!=*-9P`fY^
zNOU<0dk`^#W7^63dHhba2~jAT_LVPfR0b;WUJ8-sA#@N+mv3XK-jiPB*TzyDN5ol)
z-}NGSU7~%fG%m<5jy6xH>4O5-EAT>{%UvL~b%$9xdQyB9glIEGJW+eBxrjfbJavwA
zQ&Z<+S>64zKU@C!U1MuXhx)zTcba-r#MtF?xZHY}`!2UH%zbCwl+x4e*(F^hHPMs@
z`RJ!+j@~QfVG3XL)j{5aSU*j1NPiV5PyaxC%L|+D>HR~zmmnT{FT|ia_yF%ADoz>Z
z>kFR%to~A6(bNIb@fO4R@`yq2OV1sJ=LevH%HbvAQyTo-13xE0^_@O<HFEB%$Enfv
za@~M5SJ54)iO0_Y@N)xs<DqR~@w|Xk%syK2`0r-^dpd8t5Fwsih!?6AkN@t>Ki(W6
z-drKxJRzPV^5(z$`0qi=kNS01SilhoM_oSZllm9nC?JiEM+51*aSTwyFaO;|I>Wb%
z+HzWma3rTiKxDx!){4h}|FHdotUc9^Hv{1)|CvDQ|6+uA)JgE)ApBT_=%%)&K5n`u
z3GpTaE8%$xkiK1}3h`;|&3_MIe2jXPhQ_QS-krux7m`y`JA&%V@&)f|>V%+z>aIZ4
zA+<XYWv=!GBCc8u#5|BX23Q#g^M4MqQf~xeK8wvSRRiw9Gi0a!9Vh`_1J(dO0)j^M
z8(>XfVbBFVQ=0(M#H%fVb%0HQ7Qkk}x<GqiJs^GOfPYpV0Z4-%?{ge|2M~WWT=v9G
zS0jWY{-EEiJW$!yP<ys#liCNAKa&@DR^!uw!+=-a9tgRsI|A*1Zb1CT@{7mc5@8HU
z<8jK5^k6A&y4oUKV_-Yr7GMY9E}%0o3D^mE0@ww3AJ`2@desB?3g`mVN4mX%<Oc+K
zt1AHe04o8(quK)4A4qcY0JZ=Q1hxfw1L^w!W8KgC%8yxj{ULg__09!)LiM0G5M{u*
z0*M|fTYjvGc?SGV@t`B0_s0H)^hvJCz*fNHK=8<+tkvCtCxHP#=$U#L@C<M~@GOwh
zz5v_=Oa&$aF9Np#uK*7Mp|?zLpfhUH)f+&f%L+F?9?YMg{sKQ90zaMtKUR<lKZfJS
zcEk^Kk2A-6x>QKNF)$4100hlylqDAq><om7ygCp#7D)Vn7j-lcw|X{k0&oFv5^x=G
zI&d>^CU74RJgYAQX8~^l5l4Loh&bv@;6mVEz(qhR?<K&RK<Jga7H~DN5pWHV>H+dl
zw+F@nI|37cXk$6ZRE@Tb`xS^bhyxAkSl|}mN+4vdUI*L?+z8wO+ymSVOa|@+(wG-C
zGkJp_Va&sig-C9OcsCL^U3U=<uQ=$k+6(vyI2f1#r1E|Wr1E|S1TP$TW%79mOvdw{
zz!N~|z8X5iy#-zZz5}KK-vjRfvw?`izD4-44qkvxqKEQ#z)e>nly@;8>X5oV5N!*q
zcSV5cdpH9ijhTu8DLtka!gz(oACz8Ayw~Uj>LAk#v`y+}cwZJs`d$v`3`AL}QCGQ&
zKq=4^Nc>j@LZ`TDz$jpK;6z{z;C!GNa5)fVt45h}wSg!j4t1NIT~il$7|->AB%cPr
zvq0zoYezx1Ivvl}K**RwTd95lv;jhf9NGjmc;)PX#y|&PLm<ZR>Q2B`K$4#$a6Hfn
zI2+gwh(3$v7}OVl2&=}>it7Tr3#4%X%8D~WLw~gi2iui#6%G8uvsVpEpZn~{f7hAy
zI$xubmwmj}h8>?5xxlJQ54|zTU1MgtqQ8P7OY{RSjGxZ^+Qg#KR@tO7QT{J?-1Is#
zy!H*5dC#@myS2+ShHpz2Ze(j&?80qXswvi8E;|+N+fvVOPLnjJCH^(*_3+#F&Z89C
z0v0Yl?G0BYqKn<NkK4O?UmMc*sM0@KIj(;E){FsZeZ#khqOD=!biPLaxA_`vgt{)#
z|9H!}WOCj3{`*Yo`Xu!|b#!Z1g(HVg`b^(Cr|Y_z4eun0_enaDrDwR(M)FJ&vFk?5
zX9=e#Sw5(Gsltua&EqQ181~ow)2mNdp$}o<iam^bQnJ+O16S_<6}wpWruOT&T01B8
zv`mUPIjBini{0or#rim{R*m?0uwu%^;{)HzFa7o5Qxiw$<kQ||7L~D08fb9XE~}f@
zP;|&`Z7H127wWyv^{W4VenCHFjhE-sJ7SE1!LUUC|BemkeRSXw{a5B!OxK_K$PIj=
zKmO#B%FD+LT=wVI6`THyxR+&ferzxXKn3kHRqUQf7Ym}#xu(y}VukdFW|pcR8`xsS
zho_3eE*2fPH80vGV^5C!BidcB$`r1wY+H+IW-gt>msYxYrFiBi<G?u=Ou2vuwid=w
zx3<Rh5^rO=rV6DuXUDbcb>fOHT=iU;n!4&j^w1scMwd!jbHmL3dZW_s<xR!gqKZAc
zL#)ke6h0Ou`tc5pVoe^dFS-6&vfq6!dqk<`mG-~cS*G~JW|I_^_nxi&-|r)K6XWBQ
z=@i*&r};5f=I3^Av2O6}%|RO@Pot<7AKrv2oNYS3#y6lP@%v+2)Su;ZHkI*FZT+fy
zmhzViH$@iqE_K|<;^g{7h3#VZrRz(Wl&)<0)Z}mYzG3`s2r-qE`z^Wki{MY!Xa2If
z$l79aXa1frJ8EyOA+@6FwvEL%2MZVXL!UMU?Mp{@Hst@GvmwR$p!r!oa+a}ncWU$5
zCw$7iZPxaqaku!3V^*FIdwS(UyN1=cdQ<0&zhc`Ob0jR>|D7`=#rif9>mz48>j(Qz
zXgcw5obkyLf0~@jPXBal-MT?VYkKZkIdIOk%ky7`VuC<-CZ*1o&J;|T6|F)2<>*;<
zO&l}lH0c+&{M^xa<%wq5OQM&#)p|S1`ReiutFnFJcaep=|E|zWi#6$+uWv0jx7%Zf
zE_U}*T%J^qYcSL6x<SpO&#uB|g@ya$?wC3zdmh%0o8su)RM}hq{E!<pPHeEdl@NF1
zq?vzv^nq(xxP*5{+(J}#k2^i<lexJ~->qZM{a^Q`Be$mVcw2PG?Fr`(ysZCm`h=U2
zQ)_wNIZ&t4r3=!ToyyHK=wA;L&acfV+?$ly<JDu$mJO0*cj#+3&!gW|)hn~kJ=Qeo
zlcS2ReF+N$mYBek=(jsic}K;ER(ngPwSSer&z&VK-}myBtv?Kli{BpXRzrVNiQR2B
zKTFkbxqG3q)yn~Mt=={N_xR@7WlnM#d*F1$fsN%_Svtj8w(ycvZn9x#daz{Z+><Zn
z)P6OhE+(vXXIK8aeeV3X`_kFR`t#|-ev!V?b3AsrbMf=aJ9XsG_Y7{Z$H2b-R(Y*b
z9h<zzLP<fNAu0BZM%~$qI-fBsH((8^A+@LXhbW&XY~8S}pHH;~@m0p|x;^x@`>)B<
zHf^^3n6^Zz^BJS_8Kd(V)40n3?re#{cPbRRc_itNf2+?JEQ{(codk3e&`Cfi0i6VN
z63|KDUnzmY;HqHv|EnTY!E!&@|AGDg3Soaqx*o3@Mu6hDVMfKydbb)+w))s#hBFay
z4ifFz4E7GeQGdZQOd8wyg<*Fv|9Vi6+{Zh}0lVn2Y2ME}1PAiT!<16m0Kx~*Y*%D^
zK&Z^VzP{X(O#Wdt``~F`fM#D-av?sZ3!oV8?zm}Bl%s}Lw$C&$Bv2KI&A7v{qk#&O
z-+MxQ<#REcO4<uS`zULb!@dTJ!V|8f@U#!*5oB~2d1DHeb7Ogt?J0i_VHn;83gP?^
zW<PG23vt0hINCEo`&Ifj_#$n#-+_3eTeH`viasLZ0!wU9Kp9{?6pWFEzfh@$r62C`
z)80?PmnFX^%%aGbcGt-;U!`(C3M3gF6YN{P@Ha14W(&?aL*Nt+W_#>{=>@ZI#Z;~u
zVq^C5V3FC&!)%G!%R2$F^v&#+>jS&u8B-O^F1rzs*}dW&&mYe><wIgXy6nPoJhKZg
z3nY1z2fhMYVXacPUOw~TqJ1CqA8wVLn*3<eh><G|v(})3#Z{vDpcfAI3D$ugWqThr
zFZQ^~^CvDlqc5H*TxjQ~Y^Sr!=GQ}EU1#Bbd=`BvQ%cXLN+Fl{c<U&e*~#k%R<vt4
z{Qkh~10$wfov?Y-q@f?W^@Oc13s=2bi*v&_X13Y)QvYCP$)$hTnziNp+8wy?tYe>G
z8`m~4s1|FtqgyY3v#Z^vi{sAtKQoUg^w@sD{=vg<qe7%GyQiJMn)tcjcK+04+OUb<
zS&bhm-r3B5SV?coMa!T)WtX_2vVCCTLN^)L=ImWn4!h4UvwARn=gkjYZXc?tU)H8s
zqW^=v)#u<W5oX_5_M$BQO`(^zU0ro&#bik8@4_C>>ZJEk#Xhz!zQ{|jN3-)=b!Ww-
zm&UrBgyd4gr0TBUTNHggBDIYnw{DJwZzFrd9Gl>oB`xciN8iw`Z=1duAK%Zq)>>!7
zAUmtf?AQjKiq|zxoD`0|Q)VQ;=+nPE3$>VE^2+;>v))ggKh~qetKIus41U(ga`2MV
z2OY;@&kYM_aMal5`lACrF|OS9x98giJW1VAImK<SO_$_w*AE*~`f=O|7H-P9wBxJo
zy7j+XtM$-9@9P;Vre{oe*Ld>T$Ct(>dsOfUDfo5kf6G}hW*Edt^lfhL+IgkN(zW5O
zHrQm%Tzf_8>8`H-poeEpcJ<LVM_(S+ofV@yD@J!#%=hfte%5-qSi5bp_Sj<WoyFP{
zi(SueEYhA>x9+c7_t&laudDLna08nrPo4&MKlY15#rdPAPWw34`c(|aO~mAaL_a;k
zdzfXHUaNHL{<?Ml{~PQ6x_!`D#=DygD7h-fti#$(8|^mMPjl11hIvdIY7c%q&ozRD
zlPr(S*|)9uP~BNEy0c<*XT|8wiuu2@&$yuX59`i~36fpC{GjUaXAPEj@k`PxJ1eJ;
z9P4>MYyT^j&Hhyvmb$pXoE|Nga(;H6-d5J0(r~$Ah^LLG(z6r!tPhs?1!C#ibC|CR
zj=YtgL4iKL!K#KK-m1W1vQUM5u+-YxwuMbIYnvw4o^qeTex4C6ntA&2Uh))8r6F=z
zgs&`A#Tx{$^8h69-NXHYHC~snLZ7i)pszx%l>4hB7A|!qJwjE1!GXgALk3CO%7a7U
zK~I5IUUOrm$`Ag^%#Eea-b$%cyRK4YI2_cI&+fn=;(>hgH^M@v#`kKnur}|3--uUt
z+!k14TOq6m^Rx;6R<)=_u<xw3^L~VA&70QHS3r908IOVT5Eq%RT;Yefyl=oBSlDfk
zHGH3-KxKeT(Lv!IjMa4B_bSwwTZOo7<&blPN{C7MmNW(noIVI{7pM&NR{0{T5DM=#
z>*iiaTLCZMnsw^F_>Jd_`4Z#e@l5p5nlW8XvF=MUzz~i3!NYb{<|nNUusz<l1@-{8
z1G)m?CW85ka|XV`^X@|MsfD#~BfX{LWlfho7+cYA(v~SbvR?Fpk1Ncf8|l4!?69|Z
z@JuJCOK*Gjkj+kluPrQi8|l4w-@D=Md&T|TDbp<6w$Gc)aWX7I8|jse{4>TN;BLsI
zW;vCNmK%?Puc{LCe$?`72aKFlzs&gEr}TiohQNwo1QxW7^a5)yP4jhl<ncEB;*e>k
z3x~lE4SV0AyRYfJzOU*R53Q0m#^&82?DGnv@Qdzqp%xX(uI<}xLT2s21+zJB8OztI
zY}fnO_PFk~U$iO1<ZKF@H|>S5C?mZKBT|3=^m^v2$f?yUY@6nRce8$>_ll}ringmV
zZ`Z(gIgPLMe_;W7O49r6XT3J{?)Sd(6o;!`{blyuIBpN)_vEOegNm+Pn9*<1mhl_5
zoJGOxU~)Tj@3N7x^g!#kRl2X8*y%h9zy#%Qr1$%os5Oz9GsYilI<x<n_rIY)UbFDO
zy%@UOXy&8t-F6xtc>Lhlukh1rNZ~j5>{&c1Gp=8k29sS~f?L2ypa}}rNUz!gzavqv
zdX3L<=(u6ix{~iv)-0V-F3PFHtE#%0wD09&cr?+E<F>KzH-_IU8l1Cvu2s#)idv%|
zT;aICm>gmw45v4?>(ONQv5LKq{N533ps$#mO&V2b@4m;vP!-bfwA~}iW(d#9tK<UH
zj1ys_A3be4T)*&0`_9lc1EQy}XU!wAYijmfWN*2?&+4~B;fsysn{{&8vgD`!VQtI(
z(t7`W?-B56#pJnS<<P90Cz7kp8$2KB(_wuA)?Zopv@2`J^$MBYxOo|~yCL)Xe&RT|
z`9k{LXVsWi?NE^%`#yy;12#Eg?yoK@U$+T`oB4VKXZ2f9s($ds>yVr7(n&xk0i6VN
z63|INCjp%VbP~`>KqmqIn>gg}e*X{iRfL7$`&_0y3m|Q7V{6-_X$$RHfbhT&@6bT0
zpFBJyNH$CsRB&?uCYS?g?PL|vqPfhrg?BT2+R`_5DPxBkI0pkx#S3vTLJx!A{SbU`
z<NL81ezV7KY511W*ZjuMQQ%kp_m=qmDf`_&EW}rZk9nNa$4<5*U;Ox>(YpTWGtE<M
z#<xlvt_;2aIZm^OfWFu9sfBqA_#Fm4UK7|Jg1``VHkR}=VM=Tv2n><2IS)ER0m1XR
z_&otMKhR9b#|z)^bisWl%LnXo4UtdiWR{Og5y^HPbO=&9(dj4%_pP)wzTrz5*GBxM
za6Vp$^Tp8!fjG4g8y%SRm3Wt%_sx9rwnp5Tuk!AIGZKkLae1%#PTqC`-<~8?T-tm$
zLEc-w%DbaX)rUVgM{NEHBJ#hPPyRN@Kjo|Zd;jhHw|^)9&I12I_>RuYe{<yj;>-Ly
zect%dR)H-bIKQs9jMaqp5#q~Z|99x=peYZ`OVHI8H|aX2Lb&oIkBMLCAv=0T>OBmz
zdzeDgs1?Fe*-%}{=lXmmCjD-VG&SefXwF8WcR|8gU$i$R6td|HdYU8rWtM;L9GeNk
zYR)#}5XKcZ)tTo)I7*ZDrkpCPIYWs*hlBK9TlbTRNnG${&iKU?23HeldrkV1U!mb)
z{C%TRGyXK^K2;+6{OH^Qe!lSqS`%vWC@-3yq%=OuK&X{cM4;b5GW(5Wq4g6>>jQYA
zbD=_H;Zpxleh-fqc<&27Fn`GTGrH+L&p(Cr#kq+xKNg(vPO_yq(-5Z*;_TLnLwkk3
z7w0hIbVnRRrk{L1bpA|!akS;kCOi?36Xg5>f0l)eQuuaM)4uV|6MiE-A{pg#eIaM^
zGe&YIen~b|-Xt5%VKBrios~#u4_YI!%Pc>>3^e*7$VU_9vy3R-cErQ98CO%#E6si?
z%IACWo+2L2`wrELM{@dBJUTPxh!D1P1zuPC2zBz6P@$S2J!&ps0>o7X-x5}CdK%eb
z&fiz+?dON%r<6E5NggcyMlB`TQaWE>xqH<p%e*>U3h%z9vs6}^`m3$8Bri?52tEI2
zITO#F1l=o%IdjsN?gGz;X+st+?e&4;;5jr`UxMV`ep0M@D7?`*GJchjN|h{F>KCX$
z<0w}|BL25|<@-shpTuh`FrcZQ^iD&whFGF?jG#OFCDabt8qX1)>5LzGKA`nGulq)9
z3^56Fv2;1$hDy=7C)_y+{)=X9j8uwon@ak*YiBf*tn<0po<7obqS*@aKu-|l<Lx_y
z!ji5hLvDV^uRflOvh;K7Mk9px4^m3m`D*x`Xe7ED2;t~=dTuN{YtAmxoQu^HbHQ{u
z;wC<bpE!(_9P{$Q4--W5!Omg=U4bEfGIVE*k7>jM@*_Sv<l&>Szz3b!jGsUA5iEqG
z--(Z5!gDxEfq2!NJ17x^>xj4-J}yYGn39)|+#$z5;>8twd=Pk<Akd_#7fl6TXiKT)
zkUveiY!bp!7~*HA@LUJa+WZv5z7@KhaT7o7aG#NI+~K_Z<PKr}0Y7|yM(sW65*>w&
z>{ywZL$2w#t?+y-51-8hKIt6AynJQ}VJQsp`B8YTEAXi~i?lx0Sm^4CoA@Mt?GVO@
zZxe)i^xdJ-5Ba7wKB`;fm(o`lYDty+SPQRNKLZvy(phC_V2IRLj!!PWpNB};d(B~E
zR3A&BY>I*IrW99bA1sCTr3LcP+R>XgJDe_>tK02`xD<zE<RUzO0v)6an*FBycL~3~
zNb;fKtvPPGu!g9n=bk{4UoRlVli&^&`g0nGQ#?J~NSa+AwZg@S47WvOxD=7$UWf=s
z{VhLE<;SnY2bCr13tdYDzLx^4<9RudbTt;(47d_#4_pmw30w=L@$Why$!P^{eq6|p
z7b$&e;OF9|D+%F9uF1eEz+=GLz!Sg*z*9i#!_NRIpH!d=@FI|CzYJ6XuL6eyuLCy#
zZvlS=rUQ`{I|t}2@FAW*0G|M9-1-zqbjIN3$5r?P1xa+4!95-~T_FfZbcO=WfC``m
z5P7R<Y!MEmF*lZd)!l%jfxUrh{2K}!3tR?_20~`sG$45AW&oc9X9BUr$<ALQ`sU!7
z=ps7!F$+5zj6D+_4!G&sjBtg4TYwk>v2&EF0=MD025={k=-UOP^hjp>cz_=#Q2NDi
zYs%Xl;V3<XQ&$9HDO^qZjWLC~CeR1i9w-C40Rw=DLwnv?`aSVC-$(N_Qu-LyvG$dI
zDvWb_h<-Zvs4VdRvG*NtO(k9X7qMdj%c|HSq9QgB5kXWyMO19q1q}fLM1h1P6nn(F
zR_qnKqAso=*n3?IBKC&LTCtZ!fkpKHoVkfa1h@Qszi;3D?)`av$mC2r=gefvnKPw;
zjp&PtubI5*b4z?I3v2^40#dmtUH&%{h`$S_TLE;GZbcxai@SxsNS8iSx^zzx@vbUR
zmoEPsR(QJAK}YG<08+Yif0BNA=`*EE_bE}jbf1zgUH-R(FKfZ_(mhL*F7DD|>C$~m
zP4JocU=5(p)V}E6rA|P)cS)Bn-*@veE10eo=qO!lAeGk!Nb;w2X|6+`9e}vIPD63+
zfSJH-=zLN8>qXfU6t!=?HH`MNH#-{y-ZBfCZgz5xfAeTLl&L5?fTHXkc9fuWzP2+c
z%08edJAk70`-|GYFKVB@sD1sS>_UpN^C-$Lq$qofFvf?k?No}gZ}_Wr3=qHY2pkYN
zAaFq7fWQHP0|EyG4hS6huj2sCTmKXG|9;XSDYk)CzLFq`Qmld}x$n34PkZMBDq%jR
z^}pwYc^EykMndaO74iOn?~SLkb#J*ss+3@vUc{G)U#ka6Vb2$PhqU(SgH7-eprp0%
zaufq$@E|8w21|nIqyCy0pC4ZinkQ0O%!vpO)&tm@7}kTB4>l3-d(R<%XLCr&k~25o
zM85iMUB-ROyiz&s{_o8p|7ml@qUN+rF@*mF4hS3&I3RF9;DEpZfdc{u1P%xs5IFEZ
z!~vTB|6Tw8fl`UWD>7J3r~Y9h<t4Mh!GAKA68lJ0`tyBn{=B~__drn^=lyy7<MaMx
z<4?vmVu@O<l=+0IVaWdj!UCm1n9}QqlAVsZi9{WQv?)$u4)=K)@*hwZGy`D-CXXPy
zesdF7nAX6)2=@Lwjk8PFKcI0pnSj07mRcLa_1g6ZS|7l+BjR%0W)UX%{Q83mOCi2$
zF>&i#YY!r}C$6&-)L(m`H3pr3d#hqd98Y(=v}fG~Z#gV{Sh2jEVV|gFKf=Fdlh_j9
z7nT><{PbaI!F~XBq|ct(&pJCj+Ecf}%h!*;??6=g%k_>v_?mdp4@mrg-2>Z;r*#p&
ztb83P9@Rr<o8b#O`s@cJe)<C|0LfN@_WH3FqoFzn18M!FbWOpB{gKE2oj&XZ-}HiS
z`tBQG$A-mGk>Q?zxKZ6E_6hJjS$EA8&l<B2It=u)ZE7!#SepE@-<uzvzzzzFry@hM
zoh9Sfm+@KHsL7c}A8Z|aRb5r??r9^j>9Wu!Ek5<$0Yf?mM%TP~qduM=UCnLZnTgCE
zZcCfAp<<a1Q@7q5yL;Oi!8d(ybhQyz_XjL+Uzjs)cEHAJ_gCJ?jZDt76@1g5xa9RP
z(amOO_f~n!>=%ylzt+FZ`%AlXl(?70jP&p6<0mHf1{ZrN_@;m6y1na)DzHn1k)z1)
zm*KlN_?otCAD<BOvir>oC$fenI5x{%W;Qp%|KoMf4$d5x%;@@zy}sYB($&Sw&LltE
zow6;dZBx%`Wq)sXyWOk?bw(c#aDpi*Hcdo^M+Ogm=4%=Mc5IWgZ39*3EK~=s_(#i}
zV&;eB%uh==f^kDzMi;wEv99UVRlf|J6ohfxqzN90ef!sTdsS*cwKnx;MsK?T|4ZSN
zUf!j;C$<c2b?4-uYuo3)8@$!0!{V6{qpQ8Ga>o1oxhuV3^eNn_zBaLXlA=+3y@5&d
zj9si=ovN3+76!ys8WR7wQ|dhv)|fYc@a$-vfA^j0{a~yrGK^||C+5-c(QO=4<5G&J
zR5N()_8_LQ$DWC1G1lcL)HlQ?<3IiGbq@=whg*H0w9>^4LtmDwyGqt(^@r!m!yXo0
z675R5Jl&Hg|A;xsBt|!AN~@`dV+G&zAKojJZnj<C!EU}W@vqM2wf8OMZ<lNxSzJ=?
z7h{Vvn-i4w%LcC4T((mAnx@aO&n)<+_m8VOzS%)v`%;l-7i^BJZZ8e&m&9?mFkurJ
z4wa<tRP}s4v8h!_H!dT!W`{}_W6Vz_94M9e{QfRWx~HyqQ=+T=<Xqj~5+0;%9wQYC
zzUc+u^n!2txOuI%_rM}Y8rq1+aLG=~6S*#P7uBlq{N0i5kDQb2a*B)kz1a|QK=4g3
z_@*DRb4FV7MepZNBCuxHiu7ecGb7EjvDHJK*nY?;>3;6qQ-`jJ%aaY?d6eFDY@Een
z99p(#bahnjwHr2gTw{H|Q6atjMopWg>CyD#yO$1=Pg&P+slDP2&TBEcY%_JkwI$x&
zZ8_|@nX1$3`8HMqRvjAUt=bX$LKMHN|2CX!V|0#FZ_R#|cCV(%#{FeFUAg<P!nqk|
zO1JIcDec#&&Um9=szRR`T}G#0ltC`4;H*xa6Mg%n8Qfc*{BrETr=mF#?@iYqO_+=I
zNn57(_w7VE&*$8^Uizm6f^T|HEQ*f7At#aHru6q*t;p^UH$Eo0OKyx9bVB8STs5)j
zrtMFMrVolp!nke+qciM3>XYHsx<Bn-e`>?e=9^zh-0S6pOzsxoFh%f9FZiYxeA5fQ
z>Blx`lip)isXE=Jx`?eeV&4dxF(O07ugzbba2lU@aAdvfX{l-N2EV!Zbir`v_;`y>
zFUPc1q8}H0(+j@ou>~hQ|HT}j{r_S4{{Q4E+RP^p{<NVVEDISSRl>`h7dF&YUSas(
zOQrPnk|-4PXQBK5N-1;uqGtjCe<+S72HyWp8vxxIgeuy7`6b{d?O!jzTdfUzBxv{L
z_1S{2{?^_+?bp+uIGsVD6BYC)`TlT%{lROz<U`?#cCTLNr;6+d$WN8-90S=B(4PJy
zEu9b6cPntiw4Y0|GYh&i4be!CFF(goz35(fI$JRbFFm!e2TygSvkg=(I@^G&6*z2@
zXhc9P&ug%>!|t`W0%AFh`9Wv~6ytMqAXTCTa5&HgI1z|pzXm=YaK3}n%md==y@vRS
zqOv`I;oka`MgOgP{(bw?*uq@n(XpoURMXfsKGz&$t_E*ypEYUmWs|#&#&z%wsMY}r
zAlL>7wgG}|K($tlZ|`0=v2FUknKd?zO6(sMYu$cA!u(W@YbK(0l&c;YU8dH|ke=6*
z&L>s4&~xjhur5_wm+HJS=1x{EzZak2lZMf~ys}4?o8bKVLRyFYZ=a+DpUN6%k^Dow
z6*tOc?;Z5vr>pQy#OMai8(jY2X2CXKTesX{52J#yXZ@ib@ww-NAGTlY+4;O+8xT>t
z(uYqPoPlI}`B#*4tM-57SM8~KXQ>;pBVIjnS~YIO)Hg@RocnLF4VV~C@~!jS=x3+8
zx$4Eub6Tg*wT=#X&}jAX3M0&xr?fcvHf<anK?$}2f^C2TdLY;a<UaUxa^uE;lJ&jz
ztQj`{#??h{6<9A4?yVPW19m@!pH{Z#Z{)g7I`e6I@|E{}XA8CgZ_C5)945UY!>$Py
zOOl$L@B1)2H|)_Z)1e)5N3F8&+54_dpY*66-DbGJXCtHAm8>o?qs@%jCZ!UiUGMa|
zAGKwB#OsD1r#}c;ydiY5U>hLV1_-tRug%+CFnewj{e$Gf&(-=4-n!3VRrv|xJ;ffq
zul9iBX0>GVBZr?~3AO=(ZGdoZy<i)_`U9hL?kBg2QqtO`6+3YI+7quk!|r%_b$b;n
zQdnAs^&f?$b*$No3>#cnu}ZKF5Nrbk+W^5ffck^X1^(-*hh6Fx;#KT7gX=X%MZWdg
z)8)6TkDi8FCJsnyip{Dh_}LN}dc>rJ9$$2Av~l;zQw7@qPI&(D9H9OG0pD}~UmB^v
zC2-8y-@kd^zrF6xB<#D>GYBuX$LYK~=SLgWxb(_^GmxopaYu++DbZags8Y#rj~T!J
zPxN0u{M|^pyLV`>UmoPgJSY+^?f17qp6Pg<@p&%GhxboNcM0J*3P*MsV)aM`?XBzf
z`!{Rp0#P;!Yp(U3sL<Li(ESG`@Ycjjb_-TBsQk{j8-&Ekmlt0Z_7v&2pfGy{%3J5l
zAkL6at_A8syl4WXynBC<H?t&R_7bo+DD3%5`4eBCgHOa)vWv*KqcAd|d$SDDAoT4e
zh(1G0Ur-Ke@GcN_h(xIdu`=^=p!>em2oraXR4C~d8vL!3L#CF_7jhswjK*5I=<G1~
z&%7N5eLqzDy}s`S(luVcc)cSZ3dBEmy!1eZ8v0Cj8E_53iGbCC^?<Ok;4FZ4Kue$p
zknAx?Z^<6xEs$(Ac=_Z0FZ@mElc>z`(lZQnq$}P)(if-)i>JZgyzF4p0a;Q!EPc^^
zAMC+0F)LSlpavlwfJ=bRz^y<mf3bT<IsxzDb7x=%&=vRs*bP`3>2?Q}2lfEsjt9CY
zPD8rW3z!Ky!6(FjuYHJM_aWGQ2zDQW-N(&R^-sLGjyt33;djLF&b{%CD(!jPG<Ld^
zTPsyx!wVyB)jPGt;dWf?tuto+onctGfzicfAL}2Yc6ieD#ekRFTn25AI=`vqr9G{!
z0ulzV8<=om8ONnCy2q{8hkh8B{qbl@+PwP7FNY*$4f$BvRhB5&ebn4h{jt?vqx8<1
z-MZLLSy?*kO1Ir!jiVI*HoK4G%<ki6-KPD1Y?@(L&R%2P_v8JTQ*%4+9{uqCujL-C
zD}HU56lWX+yAQ$cL$LcO`&*^+g58JU6JlCVSy-NVV%IjVeVnA3V;lP4?R)NNXTk2H
zmdUUYZ=-fP)JfdnW><Ypm!(I89k#U)>^?@?CRry)Tt8H7*Z6YV3-jJI9$ccf&+%CU
zaaII}K17B~^CslDI`@7j^F6k2+m?knZ6}T~tL0+%=>F18!?>rb>~WVSqdQW4P-;VN
z%0t2KL$Lc0>^@BGdMK)zR!`c9g}3Wi&=VO>tX|4LB6n^0g9R^+E!%RW?t$eeYpuN`
z*nJ3gAA;QnwU1oE?xX%NbN6y5%bvLu$KCS9z2*3A6&aSk{b}-Z&6_4w1MT*u^jfq)
z^Ktck%hH0~hhX<1*nLp@`1jj=6vuv<&-dK__mldB1u$p#;y}541b^!vo#FoX`T%gy
z-9xC|OD_kW(*9^!yu-22o6h!d4a6Ol>P}LBNm!8DISAJZx`91xUmIkFJ#1gw6#LKE
zM&*iOznVE#VD}X8yZgHRbvomZ`wJwL2!-Ke0UrTICRGqbX)r$k;xLs|OH2F0qRLoj
zmxhK(RchE57@5#MyDQc{{bfN?afl?CXenF-q%?wLAqWo(_K_;Txc`u^XW{n&AWgPs
z+yF>?X(;T~hVDx5bNWPcVXxNSa^QkyKf_N1j0r@B<x0DD*gvHHrYX$_%2u|px?Sa5
zyQKAH3?F>htfPxzbTjPco${%g)w<(HlOCHck6&{k?D@5eotoF-n#`C#>6$%^3z8X~
zkEU;*t|w~_ACT~-%)!=m%`dl#-I#pj$2umdmLu9}9>4&iB$QKRcz)A;pWwYFflC)(
z|8UiFXl~~ISF_S%u06<@5FX=pLAn<93XIP8Wc^Kz-V{63$6(nSVXs!$s}=TYg}vIF
z83%l#`*BHG7di$$yR@TbYX7~q-H%7~`>-W-Fvp!TqyA<3`Sf4bIrJEEuR({<fSe{3
zl(U{r$!_^$%9AS-k9$`048c9UjP8Bvyh)lUvzP!;uInI&g`R_Fs58yF^;&N;AWuEH
z;T4>(w5(6*bvp2WWv})V+pC@V!lC}O4(n&S?KqrssdJN!zMi6*<;oiOetB(Jw@K&E
z8VP%~{VNH3wZdMluvaVi@Bh(z!8&2DR^}NsXz)(>qiaULmyvm%q3c&CuMqZXNBG3w
zOmX43=P>vd8P-Zl9aV4kaYtdVc5BS@$K|7Nx1bgArFCBMy>?s9JGt*}{%Oy;DXn%C
zTPiQL%%I-SPy5V$mua5MaqAh~lS%hVPRMKb*zwnH@iAdBp1rmiW?dZ~>D_FtuvaVW
z)e3vHO9cP@HtEjG{p&aB<(HT(`0t-vu1cxHo~!%DIX<#|JU#lJW0@-vgWlz);$8?G
zN)q;Jz4x3D_G+OACwtDyk(U^MXMb_^fpD*v4!@4Q->pgA(-#&GR@HlZ;Q=lIj)P-h
zk)g0xE9}*h9{l_FYO!r5JOT&4D+g%*-#>r<Ut(qLC616QM|jzKsl2*|sHMtash>=u
zmU@Nzs^#(^l~<6=C)`&V7NV8~OPhyaJ33sdP|Amk#dfy#_BO5B*jUpQ0)BLdfR`dn
zDGiq?)w~q|vjGtC_W;!9Ji>}`m2tk9u!qc7DObt;)glXz#-d&dq%9jI3keW)lm{!Y
z3$4VdadQ)u+7IY%GXDqcS8Mm&)doB}$^+<(GM0h4Y!S{T&tm8A#bR7kAeK=*u;V^L
z>W2gEzJZdE0I66ZXTgr)a+#k9bbeCbAPf4?xG4*=(1uwy=0n?mbFY3o@}<3Z+N*z$
z{M8a=fD{Lxb$j&qgTqPiFxpF}v*1It<u6?f0eI+~HkH33-rq$WrzooYxJbb78)e7Y
z>c3S^DpPxHnS!)sLXlaSu;tG^uEB9m+A^VHVv?*c3=+g(rXLCD5Atn^@Ac3AXKM3+
zc{g&#*?+utV8Uyyt%NRp1he`OUkiDdjYJ*roqQh<k9G0%%SGqtE3>jA1<>f%RY6S0
z1C?TRB|C{+5q?j!byfY%x{|#FD>L#Ve*!u-QQmKn2bK=BI?A7sr_WRrbG-C4DaL8&
zvlWnZ+8U^f$Lj{KGX>*~(Z<sNNtdGZ;_>ohEa2Smoqm26u*aa!bVmcpn|uRMeuMDx
zGGX^Luy|B2ov#6yj%Y}J;G3ob5N0D9;$bx)`3~SJzSh*&eum8l`4iBPtjRZlu0A}k
zc^MQe7vi#VfiEmwvLDGr{A{#)+Y&HyF&OKinlY-jx<{qXeLO0hNbuvhy(o~e!Nt*+
zPJengCv)VCy44bAdLnEj3-39%-po3OO60X2Q2b@!Rwq=nV+7H!Ytm-Xv5<<>>PhW#
zGfR|KU_XwffAn?eO5-^hJ$vk|aNx<Kldx0R0Y(`cxc2lly+0_kX&FVW^zpXYhY-%_
z58c0NY$86;A*)u;4O6>bfE|JjI$2|bI*a{|O~~vsDbKOXmaQ9&ayTxLh2I)=zhrRU
zwgp!8pC}uQdvuNCGFkeST2$*iaF0a=bx8AMhYZWs=sy_!n=>&n$DjL$b*x&s!~Tbo
z(eP2u!qcy9nAj&|UQ4@*X7@rC4*JA#j!+z9gVk$7-{d_LUAJrYYK)KT<~WWUUxvbS
z2JYRGm7{#PJ9VZ-|D=UKa@=T^udLyUbYI5|&#VWRN6a)`5)R+KFxUZ~SKc^a?5wUl
z`?OE_p}&t%aoir3&Y7_#14^!0@^tXh_(@yhQ=l+mj1Ma&Nn6D{imL86Eq;2hH?RAk
zUt|1V6<J|cONU-IyH8f{d+c-<*i`(^(l=Uc`t(%TxQyqmMi~|#)3zJOwJJsV7Wb-u
zY}NYuy_dGN+&o}iRw#roJOT#<4hS3&I3RF9;DEpZfdhY=0~k7DE^0v2PtMQ5>o48^
z2hVolQrrU=8LXx$KiwE8v%#!iqLxSgo9+H9VJ(7RSWu~zs4MY~)+Hvun0}ac4o&kD
zdN8c!XudQV@07M27r$C>U4oD9-~caya&Xc=NFG7%0{vuanLNZXEJP&>2$9m_1Xe0q
zx1y;%n+wzYtdK{u9f7(v2=Z^|A0!FDFr9_bnS|buves;$&4Gt&%NnPhi<^Q5Lw63<
z;Kre>tLGL{)?mp9sn}PHqGNqVjI|W<Z75ZWRq`;UuhfwOnqr~G!676pC`h4Jiq)UX
zjbsaZK9`%y_!?#8(<c9T{8@(aH91ZSCxkS2)|J^Ca}|2@%RB*P7A^hjWsaaii`8Eh
zyAD^W2v&1nl({{qzE$QZEuUW#bMXvC*-0k`1M6Zke7G<^D<n#ll&xF^NR|1z5F`%?
zXsWM#4i4WIM*F7Lx-}t8%?f*1U5M9IrW@v1L%}+mZr!RT%EybA*CU$StMU3s*bx%w
zqmc>e%SwC!HC9ShINk!Uiln#*X6cYW#4!A=(?>efvL9h2Ygq`CT@nO+!WtuJs2up}
zlLCMHYU5|(vl;%@>8=@Q4kJv7JcA{XVueyF4o0>zMbJocw@8a@mAKL-EDa`F-WMkM
z&h!J%Ye5d1klsticm8Y(`Gll;74+Gti{pkkR`@<~9_bff&f|zv8M4R9BGXMBZ6s*>
zfW~V+PfNV~2wEr5hDamTVpNQDSx5gI^ix2;TT4&%OV`$qud`U<Pi;(BNzhW74?sih
z+)oxDqq37ME*BP0;>Tn`dD1&YtB;dN;COt&6Z%sO>;ic^71oBnhdyc>npP!QU*^S1
z@YR3c)X9$DK_^M43hLx;gi%{AOebl5F_d_Pmv~RULJR67>GU7zBuk@!PG&;>@mT91
zoeW{T=XH|&juxep6ekUFtP!WxvV5JSc2Q6#iMAXB+!wTWwX{?RYL~W!=p@mTqt2<I
zZ?~LJn{+ZwTfcAVB<XEIolGq(UJ*K3-3XcDc?(^nKVJgJQ@_5D%3<(j&sT&_YJV^P
zPB+PPQbPs!`uV0#{uBC1(#iTLw|+ml8e#Oi|5y9TX^?*>tjp1u!jtj-k9CsbC=kaA
zajX}8TPKNjHE8>Q_NJEhTm2-_SAjz81-;Yae4QlS${*Jh-cJ^$lcx%cSA<T+(dH7K
zk6NAl9T)|jj9>Ae(@FiVlExvE_#zbi|C>7bJ^IPQe!Kr_KUq*GSNsW`EUcfb1^Hjc
zAdz(P8RI>#lk_`SR6j{^ibH<XPaciQ*GcND3-*&l+X}SQPX@2#X-Ow(Y*1J~N%WgQ
zzYp|RwDi<ZCTr{Wt$vdF(t`aYjVHd+<pMgX8~-k$%@#b=e$X`7-QSVaPe%WdPKy1N
z@?h=w-H{C^zcps3w*2+O`zR;gP~J3-(;xrRI9@kqCmQ_3@Mn*;V@3+Af-o)rCFBpC
z#(mV5>o(-apZa6{NwkrLN58J4QP=dpQP*#c_5Vy=3y$@_cU=|4EIb485^qTtN20Ep
zzgAb>Phg><rT(N9(*64R&&ZY9gT7otwBt{2=nXykbsdAcI{o2%=nEaz)wL+mvfuPS
zQ{V3;+k*Ag?W<>K>q}+9Rv7!8oP_#D&ncwMVlt&tNPN*WSow<szkYam>E>=UzwiYS
zwJ*|3{q{xeNmmYaB|at6cPd9yyg#BGso$v_)K^kDXb+sqQ4XKQVt=_Zn7P7dbC7OY
z9r&Ov3pH^JJDI=usVIwaVfv0ij4U_|ofn&4>ZW>(KZsh$!}CYC7f-)KMU`VxWj;D}
zt5gmuH<g1cv>ccreCKlL?qhhaEeFgkSUIWz<tWGN*}RTmZB5o13iPeDiI#{{Sl>)K
zpu2k^s0xVi)Wl2mrTi4gN1@dLJ|A%qg8x=tMd_ffo*9MYAB_Bs_423O|4u#sC~rR)
zDbS-|_YmZ5m7jOee=6_vLh>fQ_twjsGXGE1+l`D|@aXH7bsMO-*48Bgx<%jr*}V1p
zOVTZ!Y~u^bCyeT-)nUr#ujp{Wd~`Z&MU4ZGz8u4mkK&7b{+bT!=k-T=6jw<8O5`7}
z$Iri_M}H;nDzxZ^M_-mI<ei$I_g`we`g!ZiGFqFDK9AMN=e1rw|EW4=7g9&kBjbGe
z22mydfAv*OOvIyKN75rJ{e1pHo7CrJQ95L){r$VH&0AlNBanAApEq^Gf4YA9<8YFp
zE)PdqB*&wl#~}O|#(&P^@AWtOda}NdJm_~TH9wEPq>lyb@)qR}#LMrW@cSyXR)i%4
zPPc}b!Y^BK=Ybe<aH&B0nYjprnGtsx*b8_CNaN~j!12KAz=^<Hz{$WgAmwL;m)`^7
z_ZcWZLxh>*rKfi(-ltI?AgQVcP#2HihxlvpUSnaI-wWXP2q-_Wkb9urOL~ZM(VXBZ
zkh-2{z~;agz^lNQz}vvrzzpDTK)hTQ@FOrA_yf}V9as;T3#<>scN%A)fdQxK1~dfr
z1(pO#fw*%=qX3ozjsaEx&H@?(=L0JNmjSB)R{*O4V}aFydw{0EL%>?VlfXK_3&6U-
zOF%Q=4WKzN9oP`~0*E_(G_;R~yM#1kCu;>X2DSoL0@?v<0_}kffDXXsz;?i3U<aTI
zh`MRU0bPI-ft`TSz%IZgz^=gcK-68c57+~E5!eg(7}y8+3J9KP-UIsqvw{7Aq!0sv
zrochKT0l==Yv52|8{jaY6VMyz2J{8e-j5%U^o8WkueswpgntjYXKLjRGe9PH$b`wA
z<V|vK03^A01d`m{fh2d-iOD?xNOD&JN$%r;B==|_$$b%!<Q@Ygxvv6}+<yX++z$Xr
z?#F;6_cK6}`&A&x{W_53eg{Z$e+VSGzXg)q^MEAx^58Scy(*C8UJXcc7XeA`mOzrb
z4X_<h2_(5k0!i+ZfF$=Hfh6}uK$81PAjy3TkmP;@NOHdpB)Pu;lHA_`N$wwjB=?U%
zl6y(WiR3N<lHARJBzH&PP+)r?$=wx5a_<TB1=1diA5bTEeqEbi?=DR4=mJ=Kr|y;7
zJM{<D-tn^b4q3AHj<(9$y9tomJ9y6I4xTZ&gC|Vx;0cqv7)Wvt1d`lCfk;C$5lC{M
z4J5fQ1CrcHt|a#aAjy3<kmSA>NOC^`B)MM$lH6|tN$wATB==W9lKUGV$vq2b4*Uot
zxf_A6BzKZ4$sKmjOzv%fB=>eeJD@9&<Squ1+!a8Q`!OKN{XCH5eiKM?zYFXHd=4bJ
zlifMVor4@m?)88qcaj^)y$`StklH87Jpf2@mjOxcp}>K_`9PBULLkX~7m(z>2S{>1
z0wlR#29n%qAHxr*lRLk5%&#eb54l4oOzyRT)X&=jsh=l#Q+w|Sr1mZWlH7*_N$%9X
zN$!(@B=@;Ml6wr0<o+{|<emg1x$gs#+z$Y&0Z#)-?zey>_g{e|_Y5G(JrhWBe-9+N
ze*lu)4Iu}TJN4%zcj~`M?zTW`?<DV5Ko=m%y*rTP?gu2f<Io6``zavF{W1`B)uaPS
z?hk<^_qRZj`|m)KJGEPqdm|vp-33T;9|$D5Q~M;j2Lt;7<v@~q1d!yu6i9Mk4kWoB
z0FvAf0ZHz^07>pQfh2d@E6~Zk4caQdK8w8YH_4sWb(-R(#}nfR`hE8T(zs<9um{jr
zJFcMk{F>+AkI%0oqAp15&*V?zB>nvPwYk3+pT<+sY@Q3*YV!wsINf+^2lSKHqjmy`
zb{9}Lo=Vlmqi`y>e!RWfc>93F%l+DTBK*y-Bk|{IC?3?0Bi_<;RF95d=Yh^6ydd2X
zEgj|knvG}qv9ue6rC$!zNkeNXw!mt@)_U<2+Va;#c)@t~+IS8?8l$(>i)Z|ecu0%o
zhp{b-M`tT^{IdE+yaw8MSZZhS8tKLB{f&4nwDG_P7SCEQ9>0cAIA1zz<8=WNU)=QK
z_5KDw{j~9<+IaqY@f6y4h4B-M7>qB&fyB=ddhz(VIX~AcD2MLac<$PGXnUXe$<M0`
zuU~I%JhW+6KM%cl{5-kv{Q7I-4FFO((I!9VXZ#Jm4AI8(1QI{J^x|24gD+xjJZ~W7
zC((-+{f+#pYU3d<mS1(fc=6weC(_2Nr;TT(7ccc2@hr9RnrP#pO|vsUk##t(B{CNo
zZVgB@Z96yR(42}J<ByE(*J0X|ccYHSo-2Q>`_jGVAHJ9a`y@s;Ni(U+&9@W6#dX9}
zM_-DID0aE}#96D>s!P;4u`zP_<OArB7+r*0|D|mc$}d=Qe%7)TKR2tQ%(a+er@2~X
za>mVHhBO@xMLfvpUdnB%pS>Crzt$-Ch4<@H<wKSybgt0(;IAY1#zsG?Z5zsQZy4Q-
zJk!WztDTn|r`>;VdN0l|FeTkv<?(V>nGqZ8JbO5y!M20|;1lrVwJm!;dO8dn^xHax
z(&@&|o3qxJirhbU;F+1L&zC-eABW+LZtQ=(uh>`4RNo$LH!j^@X2(MFA3v4NjW`-w
zrIep_%9y?jXY4PLBo4Ji!};I3|1-;l%2)Bw)V@tiwDp%cZS3p))@_dGi0zLIe4Dpi
z{btkZ$m@CMIPRbBdo~QZB{B^4tG4Lo9^(!HNn<ZGy0QGWUF(VxpWkQto}WLp{obF(
z`(SN^(e3=XlHb6)Zl7#shEJ8eY57>0ZM*1k4TJd0mO*=}Ebotw@B^b$Y&B`fwe6>N
z+<hU&>d~y7X&<`ZJyhSYif!uz|3`c4&c~PtKRzPEDwn03-WPjo@7}Nf`|*_)5BT8W
z*>LL$tEHFT-{^QI7waY5Zbo<BS^D8{$65WG2Q`~meB}-!Q%&aCaidQuZcT6eWbyOO
z&#<<Fwk|Sk``g)m6FYX9exU8+Mnlsx+;{#e>Ac>m{{qKB*7p*(44(o!3`W<v)Q0rq
znYC+dDqpqZ#15u0(TzqQ3-463QRJk3#oOK!eAEg)Y6Ty)f{)sEx7*EXP-pb<04I){
z6hZyV^HBG4NtZ3!9=b86$++J0WI6XAZcOtS6LrFS_VyhcpJJeDfXRu-@W|l7&wMT8
z-;Ql^wr!y5oQ3MZ75`|NQ_TF3ocU=9M=%d)%jjZPDb_Wey6TsKlY(5ja+4-_B=+rJ
z+wE1U0oB^nn;E_BhTx<2pXQ^sA0|H{!>HzWVjc}2-NrFBE~R)%HG}7F4`Ld7?3rj5
zV_kkieZz{d@xo+DWVmYo)t9sUQ(kEz-~6!i_?ocr4M$@Q*N=Xmv8qJC;vt&p9GAi9
z-lor;RIB~R7S+c;HeCJAC;3soGf|Ibwrag3KIG*1<*V(nCc^UFZgix6s7aaW6%=FV
z?+fOBG?_B`hTV!95z+VSU$+}czHB`#C||ewK53<k8HT<rS9g`H&FT-&m4`hnx+L0_
zba}cbPySKCaS3dEwWai4H-%Hl>``fP72BRHQ`>7^h0!jZ!aet8G)vtwc`AN?$D2}m
zb|oYY{da6WvcS2|_-n(~kC)}Fs`fOn+6wF7TIMsAGE9UfvhrE=tB^Q!%gA3goLy34
zfz@5N3R8A;-L<4x7mHb&)@n>|<F`D4(G5+%8GT0M)p&Qq)~QFzTaGi18Gj+R;ou2p
zcWyP=o$>@cdB*7CJ&M1d(4+R~F|m!4YCF$MeGp;x#^-RtC9|9bhZgnT=8H8WR^Jug
z`!7$O^y*2<v($mo<NYn}ti58|Bl5OlYwFJrx#Cq%V~qt9Ka4k|iEU<@d31|dQ6ueI
znU|kTWb-eYa)FQREleid-X4ny*(8?Upee1U9*#9R^Z)M~H<^tS4`zJYly)*Sr2cPW
zm*Jt)x<;O=_o(FQ4dtw+4qtd<jDZn+L$Yzx{2e!LHi|8|WbG@}rAuosP7dACX<WG@
z>u;I0z1gCCjvNaHnXG(AAI=SU7&3PCqnq!&x-Xm(dDqo><xe-(RG8Xf!@4;W>MA*|
zUSq0n-5u+v_#Lk?cR}cwxoam^SfoDVU^=ngO}TC6=1=}sEyrQ)iqYLp%3hxon^?Zr
zo5A+Z@8*s44hr9SW6(2qtLML@t**TadeDN6!#>`2GdkXQ(~y0Y8v7g>boRvdH`R_E
zKI1cM`+WC}bDIBpgySZ#^fo!RSXJrqW~0qFj{802az~f5tFiz6&WdHGww|V}xi<y!
zoyyXyu*O#OLKL~{R=XE*$<r(!)xJ{g)}?I|Yt9b;{bBODQ&>3I%F;V)I$gTXc~P{L
z`T5=P*3DkLKWJ<0WjvwHhxa<)y-!(sr60#WGb%Ukz_o|JuUaO3-|$^*gPqfQTONr#
z6JXQPV)qh`yTsC~vw7`(OZnR+TSpd`l>5cl;>_j*rTwyjD>j#{RKBL^^GeVwHcouB
zdiv#GhULhw{QlvSjg#B)WJ$%P7444<D|Oi6O%LzT#aNHS<WpoQ9-zoBt+0I+c6el&
zD5qyF4nJ&q*jsWn>Qlt#7Oh*3LB1^+-IfqjQPrczJG>75baPJSbtN{GUNGl$+`I{U
z8;oc$p>fAm;0vQ`>^gT)rBPwqre3TNnCEyZBe#;ObNZ9b5%V@l8l2eM_bA6%V6rPR
zlqRRjKDM&05&OL4lH_ee<c8DUY^!dxaCuZ{bdx2H@k_Brz~~NaD0QJ%bEjhMTDkA(
zc=pEhx4{|f$G5F0j+6BeH3&6*!*OF7-5mA3eu6LH%O@=E2)=+%@9-L9TW9L0AxrN2
z?EG}APc54=Kds38zv>Hkxiz)79Qm3KAHridB?b4dXSlWOZkKH@E*ZAly+qai?a&2Q
z*>-5>=(9wI={YOK9c#GwHn@GLTX4_%jc31DUb^I~t}lWX{%`vX_GJA_$+JH>^sZbo
z??$!Z+@|)Pdz!DmHpMZ|-?zWow$b^eFHU0K&FIz`9dZpw+;X!`*%6w%lRK<Bkmh)D
z?wNsYmbVQU{HDf3Ec8`keA$=nV1MztjZ586x!LL4HD()(B~K+;T|e~B9_61gGqxS}
zTo~O<+n8pbe(cdt-ah5x#|6H3*GF~#bn?_Mb<WLs`MUYIpRw@wg5?|gE9cWuv?;w(
zo9GkVjI(AFjx=(NP4P^)xHxBO-ocTpv1f!axyaBfE8VVZ%WBJ4E_S}NeWl^l%U2S6
z8Sib<xI>ErfsZ#F@5gb+S-y*F*C^#`f3|hy?n$M>&$gH_rtjI*q3RhPu5$*~Xt^)B
zEB3+|o$H<fwpnk~dBOJ9Bb2LLE9@#3f1un?-MJchr^@uUJ~A46O)V+kG3rWpd$-v6
z)V|!JYp1hItX*s3y?o*Byd-rAr>q}u9EV|vH>11pEY<hF+o$mZET)PK=k4n=FU@vl
ztud)FhHmzf<8D?5^A>M8JnqQGk=NJeZr%X<nr1}j;S}K;o7MN~4^mNwtg!PnRyFIL
zu(wX9oD_ElyAe0X?ZDob4be?K;#>C6*yAroM!r3MD=xG8`~5lYdtC2DoK^OYFuIH(
z6StPprG^?m&RVkUW!B4UW5t7dwSQFcZOWkif{$duNAi5ZM>5*cmDaiK1|NA@@89nu
zS<d?BtdcwKPPuU4ZPSmlrlgIW(ZK811C452xhS5~wd%rBLz-Y*e7OzvFV9lnE%h%o
z>uFr;D+^zCn`!ln|Gwt+ru~|<&L>WuHZB?cOBu|mMTRR5o}FFt(eRO$ClmTvJKuiv
zwJ+s%Y@R%I)cTcm%_j7?;@dNFsFjEDrC;L8R#Ip5Z~EZ<)Xk>H&kFbB7Ugq!IOAW2
z-_VCgkJ$yxZ8tC=vi_c3&jYNc<ksEopw3Ci*nFfF_5%dp%w;ateA9Wa;G3D+rQn+x
zU6k+$91u7la6sUIzyW~+0tfyP9Ds=#*G=pHFIW~bLaGdr26@40zRD{M|9h#FzFrcA
zg8j){zJ2BG51t=Fe1jEQhkxYbpKM}Fey&{w_-K2eC{e)2e-8;f{)?PdDrvBf)_pvD
z`nNOTd?Wn0KV1+`8Y$JfE#xmJ2>11JldIH&;DwOx9|#U=-g!`G4wc}VH|L!b>WV8-
z1yd1qXI9e;_yR|2%S{*w174>!%nyh*7S=~`roA-2n}z*;1Y#D;hn33@!%86^W(+jL
z>nq1?3BWpB2@`KVJzv~wAPyu~{y}oNLhK_AkcEIxB}^jt@BMHG!x!KEfbTZ)-zlZ)
zFlC5X8XAV<^b{xli|`P+TKgTH&wGn}HK?1m9-OXzSl;8*+By#f2|jXUXG=l;z+%7=
zK$2q+uq+S^(~x~MwwsxKdMNM*d{zOg1H*vWX5+$vBH&0M*u;$jHUwh1RfFwLZY&VX
z!W_0MnZ33KNacwFV!5502qY#>2HFCr0I?KLz7#dEk>;iYI{;?@I{{|`U4gTKSo-B)
z{;BB>j0W}q&I9%aVp^*404@X$0xkl=hL*#&p9VbOmH=TR%VC>M;|E*@^asWO1A!}n
zG9b3~G{b?bf#3y)<x-6jxDf~*aIrw}fc$xBB7mELnLsMTVFZW_KgsM$TBYRF2{v!O
zYrgfYvYYx$y0Fh9b6(!D8>S0vTgW*sVgS)4)mc$2GH*%fkUFN<ZAMiuac=SPZUY-^
zEPZ6bop)tbk9HwJ;So3>a6sUIzyW~+0tW;R2pkYNAaFq7z@OwmanKFZ&i~>6|Igk3
z=NqinzxmJF+P;l#YinEmoBx7>RDnU?SQ9Ah-oL`u1g`4V1imU9txV|dB&6kua9{Wk
zSE|DlUOr*6AlyHQTM2MiA<8P|S2b)}>Xr+>tR*F+TRq^hlQi7Am6wk!#4FOKrEVdC
zmKtaw;V%?~QVx^`DWpn%?SW?sTY1o}JEUso;B~d~A}nc)c_Kfj7vqXOFp}02N|>bb
zVLf_zbVgnHu$z3CN9TS+I(ziu{ffWEcbLoS(%^JyBUzd&vj_8U4gFySr1cssWUw={
zt%0<@VFxS=Yy&J0#P&M7PY&~M=3B=JSP9|Iz$!o&U^QSzU=1MV<r-69Hy})*In2k|
z+JHNd=E81x4I|07K+~&-2L8Gy!MpUf<zcUe8D`^*H4?)8YG$<uk83q<$00-iaV58^
za}WoUZ)1b7^~dcFoBN!0o0~PpXnzn*+=WNrfWQHP0|EyG4hS3&I3RF9;DEpZfdc{u
z{*VLzsrkQukUC5y^<yglWD{T@;<!>=W!(Sm0oQFh>>+~{fJ*MK7Fl>S7WGo7Wx=vh
zxK~cp5&PpZvI{7QyY_IM9MIjQv<c43{$Y&-0)Ybp2LuiX91u7la6sUIzyW~+0tW;R
z2pkYNAaI}{2WbB9^H=x(!+n*oXqN>`^{oKJcDDBRHm%y|TLDNTRbl+efWpoN{8<}-
zJAc6jKwB`a4FKIzt}_JqT<HICa{yhL$Q(c#$eRN2oZ$~4kZpgCcE3L$40ouLeLv*V
zT6;&(Wvz`sJ+1Hv$wnYu8%G=vB=^A`>R}-fvJk(P9NGQ1<|<;f1pDP=$d8BY;^`rz
zxW;SQxdyQ|k~mNj;z#Q(6qm{~Nc(+Q;Me6LAN=$z=7Axl>8(o>7ozJGhowpO3lFv5
z2Zf3K<RMa)Pl7hgR}O^=36qMECgq==PpkWi*+Bf5AFh@wxX*VQa%9ASrwI=XsZ88D
zZ9OGEA?yM|F)mWa`4Wj*CMO<KeW`4gS~`iEFPrX;F?Vgc<+SM%Qo2@J`kwAx#69I|
zng2*@mKL4I7^usWzU(B!HI8cEKp1Qk`5n^K<+op(pU!4OXAk1^Ret$p@2;O;7dgwv
zM?cJiX%v}^e9p(58a^Ivb_|&e_44Tm;}fFMog?XuzqLBY>2wjU<jB^8JzlWwpwBSL
z(3AlV0~!G#Q)V;b4XljMK0vY&@dJ{rN-AEhK7Q6yvL!i=mmWG-LWnaJn&Q9+Af*fQ
z5ti;q;1Bq$!9TJ&nE<Q}i~<t>CIZcY%YhAmD}WY2I@dw^LgzY~0#^ZB09OO8fNOws
z{$wo>b}-yJpgoYzd$a@6`3`5`W?)C)Pe8J3*$Sk3DGWZhiO+3?^22=)>^TcM`r{ms
zf>MCgw9W%bE*F5r&&$Blz$-xF>s6o;@EQ=R$nLKqe%-)lvbDJhtOL9Sr23};>jQ5C
z8w1mU&49lGsh;<MHoyl!*#B@3fsVjOKxg1%U>9HpusiSxun+J#upjUxa3Js%kj~S*
z21539_DJIk{0%4rz5`O5dk<6svw#u69N=i+??4SO4>%e43HT$BGr+w=1VEhOVfU6S
z02asRg}@TPML@d8gz+7JYuo+j{($)9N8xx(Ku1^^Nc^q}ECa;dSd5=^ugMSiTmx7G
zNcWl$Uuy!1pLD-T10daR0y`>B1f+bO@M`-7c7LchK9|7T3NJm)Q6EC+7?U@6&+@kh
zlAK!tDV^1Lwe6kRZh7M~b>>uOdh9?)2%Ti<Kqpx`4nRt$Es*L99cAaW+5;(m2VfPT
z6R;`}vSsyj0anB3&cNzGoTXy*hRj)ef=+8{BD^b*_&_#YR8G<zZ@#}^{f9R`lir%+
zrN<j|gg(GxKtEt65bc(8!+*vGQ73-go?}xnJIT<{{6JMx2>VACUVZaV1CmZ(Z<(FC
zVP<2=)$JU2hJ~BoONl?axl&@|hO@RE9_<B1*#?C(HkjOD*xb(X7u5ktm%`eGw%&((
z;YL#U!;Rh6l*!KAZW?v@b??!GsBsIAzyW~+0tW;R2pkYNz!e7%{PXAka+R0dXE>R>
z`zxhhe{c?;P4oEqH6l?2nGFuz2l>kU)bbEXuoP3Nh>##@xRgH$!0Z6Lc{>2|2~Zk#
z06hM&9Y7`60f@!nzG8_QZU}tB)KV4ZiRLD}dA)up#(@ZzsOfAx#lhJCF-``krQ%>o
zh$KK7ETzNvI=h0hpc#l+vphnDyT8m$Tya+4Pdhmz8fTZTxMQ|x8Y))@XRF9IZLFoO
ze64IrrN~xcLUo#(@^f%U8vNj)v*a|6$9RZaj6s_52AZ21bdjq2N#F#bYlxpT(p4!B
zb_WAN0)GLOjE(7!uOAJDM3}eoz6i|lH!+>aDj+QT)2C0UB1aQsqRG^L_K~aA@?e@@
z8=81w!a;W{Vob<2XXT)9Ba_#<xKfpx6$sx`8XvUb!7@Lr6Yz6Fnislg>qz&S(lZe+
z)p0!Dd8ngieGzq}B?4(rC<$Lr8kZLGuzFItD9zSj2Cs9vczk&mA)owkm9E%-nio#s
zLnoBKKl0eX%FFZO`CsIPt9HG{ks1}AlX$7zNAb=@8ROYl*+49Y?+dlKldf&JckJ4!
zpWHp4AtZNNXDH-heh~_jyD4}?aYB)|JWQ>Z8m&7RnUEflPWbu;e(@cpMfyVVe8T+w
zu>|y4XTpeH>$^f<2hd!k7>;u!e_fp~YwPTU@RE3G{@AV!=D<bN`EzYibJU;dx;6>K
z{NiDCE=mWADwi2o&SV96?uN@8i*eMV^jXZ>8`lstD?t;82{~x=io{fiCqhwZt}_iU
z-(LB4EP`MwAZ!d?da%x>Az9;IVs=iZGLYtwRe>}Y$Gx>|jiEY_cw-90yo|&B#cb`M
zHW2eGt`4vtPy`$btOpbW>jQm&=0GY>G+w@K@okREQxRd4@Y0iwIVqJV2T0++1F1Z@
zz}mn(U<2SMAkF>308LK<Amwie^ahpyQomIa7z)Ha%$iZaGC-<3?rmjvXqN+0xt8GN
z^_<s#Di`VAOuY281s#>k87KmF0yYA60b(A@bp<*B-GRM;J%H3MdjbaodjqLFeSoxf
z&=)us*dI6<H~@%gBsU1SALt3B_U8qp@(sev>m<iH;cqG*mB$?~Jr<xN{cQrI_S6(e
z<;T6!Z0>Ib#5|s}2DSv^-eD%sR=`YrE?pDz`07YkxTDVS@pjSKA2X(n9<!#xoAqei
zu{DS<uN~XQS<5`D^gUr-`bn)<&pdWczI?8Dv7MiCol{~KHNnEvO-48S=d67-Ccm4M
zVb#yKYsXd}`fs@syyW3Zm1`r%=W*GlLvT;6DW&IAtC+{8P1X}^=N;cXthz(<Q4fdZ
z9vD6S`jl;Br-gp#(HrX-jIM5-Hs?qE^wMSDTf>7djaJ;TH|xmxbvkhIMVA4=w*6eP
z|M%{m`={S2C)^b`#k0ojgAN1zY@6CkBbFw=?Dyt}Cs=>1OZsQFvt<1GGCm6%H97O>
zgRNt)s;kP~J#8d5T^8D;#i!moFu-zPbj_PL>f`y*)!g=-naJ$nwzNqbDwgRmb?d#c
zySJTrDr&k5{Su>_Q2JwsGE2P;dbPf={ie&1iBV6k+uvyw@vP*V2^PyrPCkY8YDSmN
z9ew<=@%$RE>IQZ`DM`ucHKEGQj4P`THnm(8Bze*?73<23Zsw6H&zE{Wn?AHx#h(6+
zTTWRw*<X>pYVx!dEha3@HcVN8dWfhVFDy1~mSzsi74C`??urxciqpR<&cK}7$M?Gf
zuE$79?^V*xQBRjXI#RJkZvU>gZ!GFjV*lf3Wsh2MFD^75)!EcRxGV0Tc30g0)*Wzv
z_Kv!L`kifm_Aa~ceP`SM)*WjT8dE#}<Ga)T?44+T_O3JG4m1C_s^gm-^tCS)d3M3(
zxa#)Oz<x>C4{t*97%EBKsp|Q9VpFS<Zd^uc%?_0=#+aW<I8Z9_`Tbp%^Q|x*YD#pq
zpPZ}vTf&2s&10nEv2otjWEV2V)|#K#=S^^jKF_PlGT`%q(G@RYo3PBgVNda+#dXId
zI36-TSna2mTc)3@_n_C%u^(rd!9OOW+kC$C!AYgoEHZXBzq0k7)ofAEE|(fKIcIsX
ze8qZpliK-k+|P{eiHGx<0H4Vpk6!pGH2dkH1>5c>ht23E++nsN>&dUe9cH<qicv@J
zEeI;*g>?q#s^}klH`({TOH8=?D>25b_)gDmA6{3oE&jTFWL4MKuZ=mb85ZzFh7M;O
ztydXrt+L@r&lj_P+g9%9u-QE`Kdd?*ezjV2(+a<1kxaO&tJ9Uc4=bFTai(<J4xZ9}
zjp~dy`lTxDqgoOFGCKXD402HgXLahF=-VgF;NJ4&mtzM$70rowZ@T_y!d$HF+7g{`
zSC?>C7wN(Oox8fe_Z?gv?TLS-Z-1KnT=S+$)j+#_DZLgg(0p8d-?H@0J7bOvPdQt9
z-UZl+F}jl#DvukVJvl0?dGC+v=w1U=y_=b>imcyrlf%A-)81$N48Plqu2FQ)=rV28
zD=MwO@Ys3V6~7wO2d?d6e&qJ0pi5R}=64%%++9ZZY5B|94|i>u@HA^#ou4YqKVTJZ
zkTJHcCbon5lAbFT){<b)26Jzb;lgHT>r8v!s7J4-TlTrxn*^61H$Akkd!Ml}vu{|s
z79YO>dl!tZ<-o1e-#HE{bFjzIYA-70&FI>>c85ks^3>z=?x)9Ys)`L!a#}7jJlS(r
zj=aS9JNt_lb+?vqXO?hh)-r5j^=n7^BHWpU?KI&LI3RF9;DEpZfdc{u1P%xs5I7)k
zK;VGDf$zitvbojs|NnjL|AQq8+>Hl6ev*9uf8PHtyMLXH{{XGccQWkh>7nzWboLU<
zO`J&^*urjR_V3zb2)=TK)Q?Uh_>K@O)Jn$)-$02{tZwh%fG?C1wOlFkk;{V+mu$ev
zF7@k2^x5{G?6xZ+4|SkSMRa73tvhpY9QN$=oCi`mXMw9>>zvM?IndgmyLap%QS@b^
za%P7lSiasA@$2UcJM41UcTfb$ePtp3av~-B>~cV|(a*P}=ED)h?m_g6KyI!<k^q#J
z=&K;y8D9n|`YL@<3VdX?=P;ku*{b6Up0*ak6j0V6MJJq0;EBohTa-^rU$AsxuEWQd
z`$@$L9QnX!qP5V5`*c<+<;YFnb{tL@!f~A<i?2HaAqydkc(F=0ihLFDcJfugZ&^r$
z&QzY+*6Yp*!0tXj0`j7B7IeSEOz<9CyWC5?a~2uevjx7sfv96gc0VM^PZ#Gf;;ca2
zkFlgbe7Wcx2j!1^J{N%E(CeVp!_p-{jAtNTl6zmgBzH}ba{u=E3$k(6+1^)%tO}EP
zdxRGzb0q{^n9N_}FmhosFNSn@e(-sc%v)D3T;^KZFJ#Wb3XwU5>ts%KA$gfu!!H5!
zR~)9maUUt;;alWqg_m!$d|O@uIp7~hIz<oU$<9_^08$&j2&8!45E9?E_%`PT=EMAh
z>qo-FgDoZv$phlk(76FD32W*B>1;O9IRS~+&Op#|oq(XBdotJ={2@S`$L2hN9>8J1
z`M?0+GT?Av9&iM(9P)%JYw82hI5pjXILo1-GDZSt0Ve?00Ve{t0;d2IfzyEdfIk9J
zHxAog8k_}ScVX55!dz5?GYZ^lAkHE%p9s@|>+yLha075Ra1-!%U;?l@7?=pG1Ka`Z
z20RFq0uKQLfJcFgfoFl+f#efmFYr8&`mR(U@frNn>N2n6#OLA&qxMD5ZG4R&?hcUp
zmvkVtfoH%>pp{^szv#&0Iggj_`|w|9pWn`z*2SleTEDWc*@PZfe0xR?wem2&^h;dX
zO6rXMO&`3Uy4mzN6llLG(PbNZUmRC^xwn7v>#jLXjdF_J7=OKo&%qC449#MEA09Xc
zzZ8tFTxr)1`-jxuG^P1K*~%7Hx2v3Mm$bf&;e!vG?JWl`Xomfz2GALi;UCipcKqWj
zEgtZ}!?WSm6;?|xy}!}%Om6Q|9JjkR@$bB|^uytfv-&p=YBsU>${j|gn#{A~MxRpL
zn%?-y;^&*uKzr9Ay0*Wa?KiPwm+1%EK5jHLJ;QzHuaeH|t@<x;9Atejam#RYR8fqs
zbEysK$1`i!*i^o1$B7+GW1<_4J{I1oW~0bS`--={*Bu?vaYnZ%AZ}E*iG2b*Pu5){
z*zwOtN7_t8e9l#mj4o4aW=PNLN#~O)T<E#=QdpO&txI)Y8FMGAmfwp{I4i~IUS8Rw
z%1v;7eIc#G{<lw3f=^|Qvq=7--ijM#viA=9@Y7ZJ&0%zd<_#`?aC2~UwGmhM2P|-3
zm@{s6z{YC#SKi2tOwO}?P#$&`jILg#+PhA-Dfw>nC6@}^#`zY$E!tMdvkjhOWZB4k
z@~!EyIBQmq$~SJVgN@V6`8I=NSDrtyNp-4q?()eo{TpPBb-TXu;@Vta+)2gg9%dJN
zYq9>pwwv2aFX-{avAe^=RF7wMW1G$K7VP*1JO2Nq9siP%q^Fi`Ha2P9xtisS`jax0
zJ<^jrXIib<F~`iVeDkbgR-=|<(6I}HN0DLFf#k>oKUHmS=^Sg>##>a=X3Ne8!J^Ow
zXI{^5m^r%f9JCKc7v}f!{m@UPUsV=c^{w)F+3K^?rjOjrjqMj!-{th!VXN^QSg`@6
zXPp-MDK;jo{TSPyT5LQze6i2?KBvcZy?x;{XViP|#smz4+B3S5Bg`6V7Dt!*anha|
z{hCdf`Pe!7qKT2os`*D_k4<Yb^dZKKj4oqFqaUi=O**4FuLv9U$;H!obmPfYW0Y^Z
zFYJEr$L(U&V>P35b$9FRG9ca5Z+67}OYb61Z#cm9Ju>QteacH_la_Z=VZeEV(Um^1
zqOsSLPdCq07wq`$Mk;W=OR(e5eemhz#*G0b>wE24Gi?5itBc+$964^E1?lsw@XF#$
z1E-T$yOp`1`n8e#)t=$a_LOQnWV^gUxh^(2OL6xDqdWR=ZotEkv8x~5eDBqL;gra`
zuFfley0NCh)D9cg&6!YFi8Is8?!NAh^;7(g*O<E?bj;kflPfGzpK&mq*zTs>HgoeQ
zf2)?`FgIp&x0ABhC&ea~@AYP|z4N<yBfW#dcitHE%-!nwFKMf5ufq66u;WkOHbibX
z?aj98Mhllmg+@17;usHk3~WMjJFubDg<j2_inVLyzNh2a8`IwgXRIIJwxT#r)<e`F
z)btI<jb(Im)c5-R=)GXww4SoCJoCh^ZCv{}Ni)Yb^uOEp+|$mxpW=Klqcd{dCY|{-
zJ^9M}zOw~8{<j!6x#LW<$gpdI#ge2Z=led)&JBBX%XDam+)=CSd-lF-(<eQuN4FU+
zm@_lFUCHVaGuq6UZBi;R+VxJa`%zoAN4#$Mar%Rh#T!B=ui1iiAsk>A89p4LdKI^Q
zOX6UkI*T{eirRHI^xeRpkI&q?&HiKha#i#RtVuAs;d{fM?tAVt?&hrxKQ*@Mv9d+x
zvzRr~ya}7jculVBG{gWt5E$L{td-n}8!gt_2A(_ZH!b!}sU1;Oo9-NH73bg3phj(r
zM;y14(Fu0^QMJq^f*t?j+BHhK+MjJ*xqDKn@Utx@jOlweb*OrVhwGeyHCpaV?h5~q
zSfdjey6zcZoApMW7i@1mLb=Md!meWR2g?1_ovV>|s!VU|BcrjVgM~AZ;TUzLyS-cN
zd}?2A(Y4drCDyJr@m{`gcV3dZgj3d!H;$)ZjgHaXc$Vt>+PvKbv*$L^KS(b8T&?fm
zt@{jCm7gHqQ|!_EY7aPW7Ng5``1w`K?nAkhvcrF^RxIt<kvr1g%Nn2Al4LVt@ujVq
zSbW>h=-PamvFG5J-(yBfnr`p%;gj8%r|X*!^iQ2US`)UZR@jm>)PvC-d*|``Z8*1e
zsp;k2f*t<~{4S_lk=(M))D72`cz3tuu;*r~POInJSPfWpXq2~VN9+qx{I34n;D?pb
zIZnMb`&rt(nkF0fml5pv=k&w=MQh?;;KfO^xSwq-T5Ok2t2n{`?T$3>bE6vGlA8D4
zkkq5oOB49@WOQRXNLMXMe50Oj-TkU_$wBQ5`~*9G;-6s0zpr_{X}>0|^NEwEjZ5a>
z+sB^xvf|*`*(DzhA8C0qp`W$$?ML2wPShV}?q2R>*)x~oxLa6%5$yQGy<R%}I`)3I
zCUs9=SUgx&@9l*LT{up#;}`7s1v`FpB*G(bK;VGD0f7So2LuiX91u7la6sUIzyW~+
z{}>LC?PSQ`^#3mlk*Q^pAecuhRqU2M{aXNn!-CW@pOJ98uSdp?1Hksx(Zs;}-+3Ou
zLF*4c4*O#CV2c^n*{~tRYXM&~>HK+se4dCuGwPc@(6=K#*?GSOl8rK-4xhdVwjMB%
z{cNLb3|m*q6HC9$$9E;I?W^FMI_1CC_EoTHeZQ;I*2@#m`M)raEcT@B(EY<l-GyQc
zzNrP9R>7t<cDj>WD^*{^3nOmTJGI5(c3kYOGiLss@#C|B*~rFaAL}2Yc6ieD#ekRF
zTn25AI=`vqr9G{!0ulzV8<=nb2S`#F-Q(8lLqCkm{&+McZC?H4mqU`WhJ38-Dofnf
zEqB<%s9<M~`@raWKKNn##h#tdpSa}pFwxCsXZKcl%j_49@xRu;%==5bbCev{$c*-o
zo<4qJa&K_4m!|J0Z5nLdV1rwQAP1|LxvQFWEz{T}VHz%Q7|iG<Cs%%<uvlbtEoaQ!
zoEeLvJY6$)?{72wMGMQ}%aac}O~knqMpx>DiLGGM`k%CEy~S)=WgQPTO{`_3*&UT0
zx_))>3h{YY*V#9!>YEjoIVf*rT?fIYRj_FlY+6mul>M#JdBLW&%R7z}d{YZHt%G;s
zoHw&Ujm-1J??&>9S|-Cryp7uFP$zMNn_cxaU6vjVcG%WJuxTA>n`E6Jas5!SUE|Ab
zFU)(>cyNi@KF4R_(01JxG;Ug&HzCK>x%WGn@3DQ`wk*tPJ8_IzEf>2-_m^%O#ywpH
z`<%gy?nw1PsSUX)4>#6&eYlye&9mphJx^A4tiEXMjF}&!tTUrIZYraD5Ge__?A~W>
z;EL%>M@}~#7iiO8mF_rsT)#fb_=P7<VVrn`(LMI^x@+#FxSg{1)V%VSlNTLpSD{{B
z?kRKE!**SJKbbTY_lhyP<sk>g?@Da(_~{78$MP`^Uo7w!Y+6Zff=#R7o0{}Muxa%c
zReIoS-7D)*YIVygxQFVdE%D`4+A{OS`+qJQJ?WW==<NXS4Pn159J$!4Rxg9`$K9g^
zn^w<m2P$@!pPac^dB}HhpY~C{gAZR?w87#7{5RMU|IBK~C=bL{=^3=F@wrV#bGC2D
zx_bD?^n-7P%pdwoy~gF9;|vX>6Kq-qn^w{n!8i5xxY)TbEqyYEIg9OM;Sb<QTjEQH
zy5nB{eo--RYS&ZCEJX{FkNq~Sal-W@i{GcHCqBJs;SOItj7~ml^R2)&y}FExGAbe1
zv<fz@*i;i9fdl^{4$%I;PyYVD#LC)B93fYZ@Urz%d36m@OO?S=KN&n^d4>C`;hIk6
z6(sWs_f>|4sAa*@<{=WbEL^Hk%7=@^cDDBRHm%y&SbM<^z|SkPO=~ZIB`$c+_W>y4
z_xx*f9%03}${de9WWGwdO75=~S$H%S^->^R*(mr96m^sbD`Y{qkh~;kZsO|J3ioZB
zn^2%qs#1{%C|srX<H`cX9Tjp4G^M}YBr36UCwH+bLZT4+N!1cr5Ybnn@8CL49ugpy
zEB)xIb3UxML`jAWx<E=#DaA*H3V!P-ZDcA@O5q_dKd#tc5)|YEM}FknPLBqJ`Dx`7
zeL)i;m5kss%O^ltsD9#spTA@EQc6Msq^OvF9ogS~Q8&aPKZFB+z`fU6y8{Io0^pfh
z40lrlM*&BQ@SC@X`5|-(lLh&8l&F0Jd-)8P`l{WeL2x|C<QyUiaukbQNn&o25I->9
zrakW)j_eI|4{Qs#z;wDV-HG`tE6X{U9ELwN6al;}VKQwW^H*o?-qQxBH~Fxs`C&N8
z_f=R+U075;9cBwWon9C#2KnrRxdWF~8NTQ`NBT+?YVeKsJ!lAJR(SMee*LJNb>MeM
z!758>@%{#lt5BFcB%GyhWRkA+!>9BAX9~Ip6ov%&xGwMk$W(>-<~wD8yTrlc9*BRR
z@s#&fcO7w9{(PBa@(|u$qXK7d@=i;)83q|-!{MQo)nRIUc+8L{$;ucw1Z9qAd@v{|
zt8YlDa5+u;hMW@i>*QqpStjxMVVFhm{MQTnER&z|>Bt=$le=CRRfX~Ud&%irG9iBI
zd|rB!(F>lVc<IlBc$bRs-%+OfOcT1QzgF_1eQokS`M#xd>qy6-bL3Z$bZ#wVO!}pk
zMym0V=_XW;W4h6)BcrR1&#!8M&NVE=w=3^Jlkz~&S2`;~SV5gNM_3lc?;N65V!w{^
zhHDJw^O9Av6Iw+eAKnz<tc*P*$`Mi}O3H^*V-n%*s`8Mk1C{a!Z8#|dg)61LVM-PH
zcKlrj>65Qfs)H}8CJPBew=WNI_VZ(1G0EoxzGwM#hIdn+AekzVZ!;tx7p=bUE`!AI
z)GC29hQR8;@gmqVF?}*{m4*0ed!E8&G>IaA{b>D?mN035nCWy+u)d#iqzk+|j`*e?
zelOV(|4DWty!w2ja0(+uC@2?_VPSFs8$VH;f^s4LQ#z1JUo|<b#6#&PBfKPZ5Q@Mm
z3=gXaH#G4>11N_ENO24fGQKc5lJCpkNq0JiDV5R?wVn#HzDXB12?7d2e{@Y7m-323
z+(jbXXQ{?-Twk?Z!OCE0LXK+VLGKRwEG<3ha~kNYqiiyaB0$Q@<pkO|(3*nQ{19I*
zN}GJH4xqNgce+p^-sdXy#k~I0j}{AN^<IK-kzT#|^o>l8BfJ^H1NomYVh77N2>EV8
zzE~pRJoNG<Kdh}m@5p{=+nc+iVNiK4Bix0;eWU@hko@rdx^QWTA0Nu6{{ZQ)NBWzP
z{#<SP#Di&|Z<${nR+dhnTa9-XXyf$CLjGNujCEC2@xK?;h6;Oizxn%(sP-He1D?WN
z4YvfiQUu#5zTeYpSFUm;{z+v4A)kMyzHVyF4$%qe=pHnC-NV}2|3rUCGN3k9n9hrI
z;lwAszOJY?MLJ(t8`%#T>;~^hC&nDh*F}<jVS1ijmgAB@pA7mHT6*FI$*rKCTYxSe
zFHCE=(|WYjPtv$VtDj8QX#7-|E|cyT)a8PD;Hvfe8(0n*;kk^L<duqd5b_c2rg|Cl
z8>x`?Aa?NszORK&zkzykM(oee7c$o$Q<01)+k)+rcw&t3;#JU|`|&?6RBjJ#S&b|3
zY43ra((m*R;8qd*bL?bg6^nHvosN-_`s2~BOU;ja==Zdc=ZkU|HeUSR{Xgky!G2zZ
zu)_Lz(pCDd;O_<XM}_HX5E%WTJdN|wzwF|5mBziKPh*gf!as!dE$cy(jkgo%)@kWT
z9@M{jSEc+^FwD;HS7>~CLrX{LkeqsI<&>_KQzN8B{YpK&7SO5HTeWi17mkgCgZ9T8
zeXjoByo?IhEzxHgQ9T+WZJjUk&wUI!0sOXU`*B|1!cY!bF#LMENL2JgNaGLEHwyR1
zkc!48_>okSJoNQ$MMVVQp?Xk#;MSEhK%Vh&h1W+nh+q}c`+#WQu+{#uPM@g!TL0|S
zUhp&V)!0whjtbU`%HB;Yi&j)YJPq(t*|DX<)vd&Fuj5(SF%5Qb@R9h5rEE$B1{C-R
z@^6-TJH98LlN_oeU0s=Va;S|ku~;1_(dv$_T)Va9YKZt$E|}?YBG9h>50{I0<D%t_
z8^+x9IO3%;w8r}iVX52ld85ad&wqmKPxIsn(ksZ57YGygQnQh+et9yr<-t}tD^FwK
zTZFCt50yu!SL9b++yjdvyvuv`+d};_wF9x(U#<)$5BGeV(A`^*1X<Ce-zM6iO{D&b
zHcsO@y0gH+LHF0U`PmZr=yc3hudVCKPvfvJ$8GuT9phdlKceT$uhYLaSO=hofMici
z+zfR}En5G^ebG)pU-WNZ{#^?N+l9WoleA^1uPp<$%^b+WSg#D9mCnIo+~>dlLf-oN
zM|ls?>b_SMB!b5ZFNQPh{s|}W(fjAZ`!xMNS|_#q+b7z!qqK^i59jx7G#}}pCqrF7
z(GFp9zDcmYx4pKU8QOAE8>Mnm8})&ldMB`QsxdynK_P$nUn$FWq(S*oSq34kg6-22
zVfyV;$Fpes4$@<bm&!uzlz0~Xw|G|XyYo!fHbp<6V0iTVwYDgy=x>$N@|$|z68RL?
zHuZHaNn0Kl&{A8Yav7sMToHYR-cM$J7m+VuOT_%sWh#q&bn?|NlUp@Ph2y9gRHhnu
z9q7Z~;!%?(i20|>q~C|>mnp4~GF3#G(*Mjj<LgGr3iYi%N?&$G@oAEFkgVTNR7IJ3
z|2^4}=>K#-Q3d(vWT)#VDj`h2pU~-i6%rtx=6Fe-7I+(>9gFyWqOfs}x5`%%BvFd|
zq(M@wO$Fc&EYyc#yF%IMo3h-Fv~@bKKjtA>>gFn|3n@<?`gTR(efxJQOToTg_gm+M
z`wHj*>)3fe8o%Db2je32s^9`L#U(u=Eadq-7N;?4Ve_TGy1q_))XgPoQDO1um;E+A
zy#A^1->HIS=jW~e^W|@?UAt^mhcCYh`zbc~QvzHo!Z?HJrE^DY2C=E1Zj3^F?#)MG
z{}a<Q?(+L4P-pDtIGC))?-q5bv~SWpiTJ=_-^ALEB2ZYf&tWYo%K~B6^z+5Sq7pyH
zrJvOTVJ!=zYo()$-~KtSy)JCq=dhO4wXpQ`!l(;jVe9hgKBt!-X5EITD|)}?kLKSr
zE~H^Y!L@Rl?@@O~`luZ*>XxF}n70<bQ{&a2i&HxnA&llHJ>9!>#5F;THXbq<20dg`
zS?yXprBCaKtPS*)giAZ?CRL<=Mkd$sT~TY{ln<@R()TKg+P62GpVAr++Z*81`@BOy
zbv%Xdyif*(ULhJHd_Tge9-p)4_w4A-Bc*(#)DK^w4u&Qov@I*>XFNV9@-kuj4z#xw
zhA<hUGcrlV=S(n1(LW>tYwc`KP329~=7T%9*vc~1pVq+G9)sSGIFeywI%?PLp`V%o
zrAcSSVrigO4CWoEA@mQCMk=tmDD`u48tgo%w@ZJqO5C|GtwFiVRB9(Dry&^sRYWg}
zbqX3R<Ds?C#(2Z=t`MP&J6ON)WpenA+7-1W-9vx#<uGRb7qu&@H?^w@DC13*4z(+L
zR_0y&XWYj|t6_h-yyjL&Pd86t>*xQEy)%KUscZZHrU;QT&yHlCDh)~~V-YeB#c4VX
zG<Q-VPK3;vr;;JcEc28xb13sHV}!&VN~QnrT6>>5l3UOH-0$<;|MxxnWBaz(xz=>8
zVXw9J8j9k>bRv(>1tC6ekf$*ZN~8kx4{TUjF4HThx4Q?rO@$v_e*Iqm@!Qi1dgt^C
zvXT1vqwMkhbj3Pav96Vh;3+Pua_Mt0y~6Gxf35pPUCXi^pC^WT_ww|S2J;!=ckc=s
zf1-DVyd3}V9ai|(Md?$#{8Cuu?=&|mkhlVnk*Jb$0`DNKqOC0bi+zwbHT@y1LVl%i
zQaeF@k)J1px|S+1$`e$^<aMn*)5DK-t+>#vsIDzCE2?YF3gz?)>)Il-qPn)otmyk{
z-6Fe%b#0wOv!c3I!HlvUt7|J4$raYMMP__m`&ZLLUe8ipgJCmQ2|n&nML^~>22JKa
zes@yQ3KAi2Bkh*rw`DA?`0^pIOT2;vNANqPH{J5_8jd>3xG+4<@+bAd9w5z6vN)Fc
zDb4#xr2QR&ewQctzNx&7QvItq=0WB(7E)4Pl<(P~qXPk4vAAhmdL!-`B7}=CyH@^I
zMW0QEpn}8CtUjtifBby?vOOgaOYwR{8)1aH+4n!k-rfOJMWd2Jla{JZcs_*J@vpv>
z(RYsGWAWryN#B*|y`hS95FyU95%xQLTZ6qfs6S0<PVWtQ+R4AMCkZ+lhTlj>gK*Ch
z;Xi)t-pXJ6!{~|_uLJKuysD^-Qe9EP#q=akx8gdXaJGb>7jRp_a(U(t|6QHNWQvDV
zp2ws#P>PG{J{8>5C3}cGmi&u6R``Jga=)whsQ#t6{5#)5<mWYZqJdLfR1K0osqGRf
z;y80QR%jun7hr#hr=!G=zSPplw%(uUQY53cr96DCQ4wMy06QF%%qageGf#Xh5ag(?
z6y#`Vmz8<a>mPV$4Gr|R@N@0WWa&G>C>AE1n}**gU&!O2*@9f-&pf3#h;UEGe?GsA
zgZ}?$94M|-Ch6Qq9O}v1u#~?jURe|`H$RC)h#AFez7Q|^jp8MLH!T(7MNNO|i&C4j
zHRYjFj4iOw#*nAHqze9g6^*4)xD>yAP#EOj^=b$&Hp(9q2Ff24hRjlg0iUS<vj6gO
zv{dk4v95jw|JVJZ&xw}@-!k(5vvTxfU0qV0Ebo7dTJf5Lmn{BNp4;F-#M12NcZK5k
zCc<Lv;4c+s$^7-Skn3Wd5EdF^raA?m*|?_&OT@2r(ci(<-DyC8Crby2mvH@F7xJ+Y
zT{dF&<5;%}{Fjwx3<t_UIOMH)q)zGeq4*7p@}_)Dce@ZCs=_FbQyxu4cyxcE4|o4w
zmgMp8%7pw~P*T2-r$t*fQpeXhihkSw((eJ@d_U^n^Iu-)trPqwRK!hHMK0Rt<|U5{
z1=5GJU%vx?tP8%u9r<{fVm)i!7M|dOidp`n_C3uPjNr${#Ny(ECiuOy?=r={#1HNG
ze_=kQV&2FrA*{h71c;x9`g2%?0iOSKc=d(v6HD76Y`7HL3p9UXw_LXh4TRE$@$YCK
z)S!V-T#9wh77@n$<ozSe#g>YDc{yP~!^Yd4CT#ynn)CTg-cR7)`+jKinP}A(+VF#s
z_b44d!A~Fb#rS!{{CwgHc&7aB4APZZo|AP1KZ4j2g!>HofM3BtFc%C1^T9dbcW@r4
zrpC!4!7AWJPy;*zYJ%55u4<<2mhk)ltOoN8usZk!tO3$o*_vQYuol=DYycX94MB6T
z5lH6~H3r3?2y_RVgHyp4;3}{sxD{*#CW39ii(q?@&Op`!UxWG}oqgO96oE!yH_#Zg
z0y}{=pb0n_GzCY2T|h^$D>xoB2YrO+K(Gg%X`XgZkn|pbo1X)WIu-ts-YNY_mvn_e
zj`ThgGzY`M-r#J|5?l<91XqD#a5WeXMuA7c^<V<H5hVY%gSp@iP!)dd0xN>_OnQz7
zNsip$=hE_XY$;qCFq%x}xKdU5edp3aYHNN4tAW`dy(+ZIaWY-78rTJ_4t4`;g4SSN
z&;@J+%0Lmg4QvC(gKfd%pe{(^v4qa}xug7?QVI|0!3^efrQ>XFs+%)GdRPAeQoHag
zNclJi><{LFYr*f}77ztMwiCd)*RsQ)DwqhC122G;z*_K26Kn!j1KWbt!A@Xpa3I(K
z90WE2sm!zi{lIqM0<b+80qTLvKvR&;<n98dfjvNkmFoq<O|B2v6GXgOJ{ttu;~9C4
z<*(78AD->N1W*hnfsm0s1RcOE&;`r`-ND*u$czK)g2<DyAz%nN0-Oqt0%hP>a2n_Y
zP6s96TyO)p2;2&;1`mPB;CJvosHKX27uW!N1hxPlgKfd5pf#8ajsOuRnIrfebOQ^(
z01z)bSs+*z3<Ficm0)>r2dD-f0xN)Lz$)NbPzy`}tAqDIoI@^q4AuwBmqWb((i~(F
zNcrg`Zhp=rKbMm7Q%#ud!%de3<fska2c&#$2~xk(8XN$Q1Sf#D;3UuyoDD)(tiHoJ
z=d$g19uFpgUSJN0H5;;W@XH^h`b-Me1}A|nzz|R$oC4Z`Q$YuCI=BRk0BO$WN|54V
zkDH(O$Il0(cu+YQikq%=kb@dHq@7F$+z7S@H-o*vIB+1i6AS@&fuSJMR+bDN2g#p9
zxcNDIc&)<^@`uV7#gVS}$U5c0uOR8G49eFi5OOjnP#yFFQOB_Q33WHq6UvZmGt9e!
zr2F2W7Tg{H>VY<37Z7Dj)&m?4`h)b|2o|2FfumqP3mgmX1~IlM+Yd@W3V$cu{9HD^
z{f2zYkzU&3ri;Q&>755w2fu^V7c2nDz6duzcZ{DuL-yf3(*eNk5#*RZtX;^rSCL+v
zqCe09^T!jUF-m%-VPtPm9!`EP6aUS<xP8?5GEK<$0nuckaT4}^=&N9#pL@j5btrDX
zyI|i!u-^l04tIJA_NmV1=K~eR6H(wO@6e?NeUhHagLQ;w3OCu~=fH4m$dCM0w1>RF
z!aW+K_}VJ?$IoBk-5|Xx+Cv#(^*ZWc_Fh3*VR|C}`1vHfp6FT8-e9;-<zNU%gSRLT
zh4%QlAN-t<;{IW-I<r?F>;QWW6#V1oV(|VIw@3M!^n$$0{Hvy5kDoKaVN8_Omp_E_
z6v9RJ&Vpv(c_EyXkN9~Fd>?@PQ_M$|1pla9Q9h~+)&;8w{*rxu4noQH(KcZI9s|if
z+6c@(-noT(;^zyLoG#ZONBT_$>3yG~V2}Ss&HGFBgkrj!NBe@FFM##Ii$Z&Y(vSZ>
zT(Uho!QL3b-dMRkxX*u=MV$&Ak$+9$mJUdl1KOd~esTd#KsV4F^Z*BeKA<Zo1^vJP
zkm|ueklH{&;1X~mxE`DY#(`5nq!m?qvgcqZ_yL>=W`nc9st7|kSO=T~qR!*yg2TZ1
zpbNMFq;|qWPzo*rCxDB=dEj!8>V5KOHMkPo14e>pz-aIqxB<KmZUkR~82Xf%K_3_{
zkc|b=wUMDsz~Pf2OJ6sHk^k<-e~%-*Rf3rvZn~OR;AE}97GP(v71$kY1NH$sfGA^}
z9*DBc>4Oen#)t1RU$7&dCx8YZ)ej?a^WVjg2Kbx&s{mT#rt1{KMfn@k=UIF597yf8
zOCY^RE`#=966gqC0iD5XAh}QZhyUiqe+w&~?@%6CzC#{h`5b*1X742I@!y~L?^0w>
zu^r%n_AKQee-L#nCk4rWv{hv8U@#Z}P6p?LQ^80u6x;}gfqTJlkn#)KGAzGr1mEF#
z6Q}||w}8|R-wJAg+d$Mk+;))K1!()Qe$GLV+MCBfyyLh8P#%B&n+pG}rFi{>yw2i}
zG%KtZ$zB9*{+kE?ErjA<6=q?$>3V{4M(_1husZk@q;^mSNP77QQoi^E!foyka2%Ko
z`hnlT<zODT8q5btKLsGQ!;uMO>wvN#=}Se(FE;p_|IWa1!|*4COAYKv=D18DN8#!W
zYJ*)sE3g|#`Njeq2=)M}oc9DNzLZb+?*e@Pzj!{mh4zjLWNw2L&pRO5qxzH|r{~AM
zNN<#1<?V-f=#|2=2doSt&1DThv}p?M^JC;fy8yo_+CK(4vQPCe*{6C~1fBp3!_CHl
zX`JWh_Xz4cR-ZQm>)`k1!h3+?%a0%P;VzypS_$@AgB0F23ikMMUp_w-*V7e*i}Z9A
zr1t>559HzG$7_q;J0z!ro38ePe;q)2U+F6N$B(V@`LB35QMQ<W3&1L{w@|@9eoPc?
zf0!4y_XKj3Z&E?Z*H0Df@ne^KdK9-e9deXDVIbwN84C9JamSMFg$wp(3-;zH*yG0w
zp<}pLynQqla->Hw*aEayu*Z-2mHb{zKsh4)9tY`tdIFTE13&&&vc18Ay&;0Vp$hi+
zaj=rhN0LxJt_bDhs!%>CpYh{VeEP-VSux#FSFvz9gOq;MF3$q*LddWj^$S7<`_G-&
zP};v*uR((~&c-`)+z}KA%`(>~-MCord0|%Y+{U%{&a;J?js}^}uhMqgu!*e=^vkBq
zSl>D%33Uz>s9EOJ`rO2>A-yuw`@S@JbS)Q|Ob;(M%`zu!j63%jQz^f!;iInQ5;p{*
zPG{!#uSHC{Z__td-TAYrPMiC$(8t#z`HNRVV}dglgq<^3IC^T%X;gBbSvXH;`mWVn
z_<BJ90~!f$UY*;CcQ!JfW*NVR{mS=ju<YR2?0o$@qcdCL-N3>>U{RBKjZT!y?>t;J
z!)=FoYqTNMNj~@epdCX-<<y^JcGrHiq;r3?H71gI!=b7DrhIF%e8suN1Gy6iJ7CQe
zbfj6P_W-AQ&qrppt?1Jrb*f=DDu(?mJSU#t*3=Rwbo<(1z@}MNDc$hyMaI=E(`beB
znb533Vfki#w(i)ho`Zg24Kh!(&kxu7wy{r(o@>kIKim2T`nJs6W>wo+7n<*EwQj_S
zT_!bBAK@Lw%xyottq|vX?||>{Wy8medWeec3^TWoG^{vR|9Y$YiMGAEjN3CDbsqEg
z!Nlj~J@a=h)ouF5ui2DWcQ`JKg}+*d+Py{`ZmA*lYM*5Ky0sDNe7tBi%e2vXcQ~x+
z{0&(zypHefY2}CSc+8!Tm!hH)-?;?zs9C++v6l{$@D5?-sdqL_ALO-I-?*ywGp}VM
z3(y{C`dqi(_hbHB(Ou(qA0|8Y-m)F<VwN9rMjYAtHOKGeq2zfjhwWR2f{DI1{B>_0
znd)Tr+V<;<o8#xzTZzWXVJ3emq`YhS^()gyt=b*7b@x>?Tr5~PZ|06jX_NY`%tvP(
zwGp@D1|WTzd0Mc0?xRZsH=VOMGO^~f7=&{-GmllbidkX%a8bQZyA4!^PekE-!_3#m
zpYA!)YQ63IR<k}`UFGe9wggMZ$S{dP)T?QAoWpm|8Tc_1FRfO!D4fG)sv0@jdVU<W
zqH<f$ZTFGij<S3kvi4qrriHZnf{Tt-#(W#^k9RH0Z_z;-^Yu*!c06>h&X6+~`=C<)
z#^lvk)Jwk*Fy-|-gNZ7tlRNiC+YA+>W*Jqxre~sKn%b=D+<MFKjbDAyK4ax;tK;F-
z;Tf@``n8)qbg*Y93zS(Fo*Kb_M5wtv^9nc0udBIM3ytL{X0BVq`sKaDLyvS`wIjXS
z)nxW^M*&w}N)0GApwxg;14<1jHK5dhQUgj2C^hh3(Ez$noC{Y5y<5!dFtz)e_y5D(
zUpMS9=T~&@AG%o_x+KD-fw@ey7vPV30QPslj({Qye}Bw-rTzctdd79p;+z7Ve-5O-
zpHt!9gqRD1zlF^S?Hp;dJ3B{g62VR<RNS~wjJ>eDBpx00IZ2SDWH<TU4&}QZ_LNM}
zGq7`X_p%G>sL%E`^z>*?cHw==_T@Hz3=@S`;%4XG5xXN6YRAFflj2wl>s3}Hvh`SE
ztWgqUkw}1_7sfS(IZB<%k`zBaPI|P)y`eM4>;*eLFjshpL`rKQ*)j=|mCpsH@haLI
z14|^?9B&#=Bs0am%jnrT(8`M~j>6yd5T0EM;h{xK*!xR@pE&s(A^MIX_+L0~FT(Hm
z_QWoXTd^@7j0Lf=Og#`?Oimx9vHp%Ay6T((h%P3r$(B)OGy*ZCz!`(+BGXta8^ffr
zdUTti6aHH)qAzQTXERU->;g6eyMi=kW)5Q5g+o`BeY@xm(pXy$ur1gV#Bd7N3#9R?
z-XOxpzNOOmt|gw~7yG7)VHB<(p3On%o_#CF5DlAqGXU%Z^MN4ja5i8TNPq8RV>mW{
zoN(HaxN@Pxn8@2rv(KY%o{7O^jNxcE95uyY%Kj57E>p_ykYY?`mo1sk=r(pyuie+B
zuKR8Tbn!Jh3Wt=JQUgj2C^ewefKmfW4Jb9B)PPb0N)0GA@NZ~<`v0Sg`v2bkw0S@E
zZ(aN(cAoBDd_UO^omhXn0P4z82iC#IhyFzW)!mzQtzn1cS+CaJ-$5!3=6n3qPczdh
zV^8yRs-r*o!lyzZf9&&@wC_LLuU|aDNel=5+#Lg?*a*KC_Q<Cp1&N=cDUB)UXgNqd
z;0N~57bA4otRHLG#hwmc*bUDUJ00^f^78^lU;_;AK!5awakc<0wPrh7^D-9Qt=NA1
zzm~Dq3dMw)_CmirS?KGYhAu1MK8|}fI<F^L-?@yK*9gBBi+(TRVtr2ex*S@!>f%P@
z0V-N%a61XN43<*)zBtVJJ<kv&PTVWV$4`t^uK1h!<nn&GIi7j{`L!CU7<9oWW$I_M
z3-exB{~KP(L@+_0Tec3Y4pR6LeAa)Z{k`s@lP*%3UPsL(Fn7a*7fautS-tgC<AgQm
z8f>^R{=nRaN!RV)y}{fG4LB}RS=vrr_BN!B*BisU*X6CRTuC>z+Pfx6<@4YQ2hU7t
zxgr?rW0+hcf9r<Lo2Au_89LExp!3A=`Lh0Pzkkj!opC|0Zuf?fA2F|v$tllLQ=X+p
z`D#-YjnCKKcslj9$XLBX8d<|vk}dIg@_x+c&Zn*CJfK~zEHPLlQd#`5PQJ|fL4oot
zwd|Ztn@lEQJ}?HdL@Ecg_gE*ybzkrAKI@NpQEzP~ysVd5$Eia1^(~GkEK*g&IAaHt
zb&<;VN0#b|t>Q)>t=7u%)X2+c_k65<=Hw;E`FoaFZ(i8`=_#x!VeY+6{=CXXZGQT8
zqg%@|`p(lm?^68CwOPzPjrE42_oASK54ybHo)q5tRl{4gAKchAz5ap;-(Dtdyr7G9
zT1>7&TI^f(%2N{Vy!;luTJoj&=h$Wk!fjfg3cBRlu}8~8D=}9IgMT8G$m5q6lz%lY
zxb?aCp?VgNUfCZ$+jOjsb>(xFF5TG9J#a!j+lb^|t($Z6{Ma1tTi@~uI+|N1COK4H
zRn_FwShbU;AN$+;uD}=|bFadqf*J2*AKTP)Gd_BC;PR!i@9Unou5kbH<Wu9WUaqh>
z1#_^N+&PWvQ>JFmnD({3&39?Uz!Cm7?X;tVnhuCFJ=#3{%j=z3Kf~l&L=1?i*hv~$
zEhZ(+V%II_x^qTs=%aJ$(G8Cqy4pHVnq&SflPg%0vEb#wt)b~(S2x<Gu_QrvLYdbg
zon^7zbXE?CT-Lw=bB;0aC{kJ0?sB8>FD?2HOy7Fc(nQO%%9J_2L#zjdL@l`2y0_}o
zO&G&ua>}#b{_0t8*%+S{se~o<+K`^)BFhP#lwmk&N^q|>*8<<{J~HikM%99W`)z#x
z{xji*Vt`ttGOhjNs8{1AbuvrdepU5q?K1ByUqrPUe0aKclwOt4rYd+*4{k|vmQ5WW
zRw%3Dn^C!Ow0oy@dGGvA4sO|JuW|YA>4)>Zzx!~UeSMOvA=%q$p7!9rfsu6|-l>>T
zpyj^gdOgnVl}Ssj&_{b>2ce$CV7W-8m)Z%db*jddQ){~>Mc>GqarJqJ;49$~yFG4g
zn_uoQ=0<Zdm?tJuS+f7${T8w1S8n*=f8)l6>oa`!_ncDsRLleI&i6Z1$??WJdOCA2
zGj8zq<3lw^Z&+P_e8uTyCnvtUu<Vm*ohHj1%=0s5$3SjKD{}AAzU-KNv3siw{5Z<Q
z;`8EQdyfeR?u~qFt^4l$!*va#@o``qb1&^%R_#BMpFGJQ6x#WUt<Jlb4`y^R4}W^O
zR)alL+a}hSgSm*zy*RTD(bdwnsBgKK==_q)omAPl?y)Zis#ct36z*65$W@fLH0GY8
zY{($1bM?m!kN;TlxKU%Bn+CC)lTOWUq?O!yd>7e^!B`*Ig~B&>k*q;R?f8I=E0Ts6
zR0vj^elzdEg<Bocj!GSpz8U>boPoE4#p80lIg*VQ%OiAkt{vK~*Y5q7<A$1cnxUQY
zzWDfA8us~&^---UeC021GqtH+KL1|raa>$i+r#Z+?#wjHcX1jfHEeNh)%$bMAB#tB
zP{<9>ugwP8>{m5*2@0QTaW?tE4$Zt~YQ4HnO7C7#hV_|DZgOa+eO=4W(n-y)(fL`V
z`D5GRHXBp3{fE1>4t%hqj%zj4yZD$QQt4Nv^Qlhh+vZ<<WPT#P;^*%%m#<&iwfMHF
z^_NNu9_DJG4l3;#@P}AD)~lcB?YejC{Z5s}%bv{W7M<|W?A)SDBRZ|=>^kaW-Iw_2
zqtE2FdesxvJe}Ar)3f0I!s;8#ZK|+z;l=HXLyt5Y-z>CMk7%qjWOA`jImaHNxYTN$
zBF=JiFKdUMYGD?8)i(b6ikw;b$Ai(h)km9Mq_V?xZ@tcouAW#}b@T31Aw#=`zxg~d
zG4@K8GyPT_x%Tq?Laf_la$&Nt8uveiP7pT|&zf{&dtlj{b*9gc-XJa4=<Md8H8T=0
zUz^DVS`J&)Ilju$mDlF4j@;R<hF@;WnZ~l)HD<iNe|~h^an9%uFu4rxj&&~Ij@rFJ
zJ@>tRrdk!RHSxVPdL4fnd?YsFRYOD6FCUrQ-28e$NxBDan1w(8Qt#PzXSb`V_Wpx2
z=2slQ$=J5Pc>~0wF2!TcxjS2re77|nJMxc>K7Qu+4&0v~qZV{*(TGd))?KS`3LU#~
zOfJOtVCtZYXWL(0ekyHY+Nz^@DrtK}muJ5YpEP;B#>W`Q#WJ}}v(DS~+-++NIjd9Q
zO@j|_2OpSm^NMQO0|mJjSEH7<X@~s6<QDAwdbIA0&tb21hdNpHFvuIW^_J(#muvld
zw=jFRJ-gm$eEX|M;d5+Ic5qyrUZ~;X#4Tg%n6{tza%^tGq&atI?g|O_&FgQ2Z*5Gj
zaidPxCT`2<e)N;d@eK9I$0pi6IOm=T*WdRU?rAu*dp7z~@LQxZ*gViF_Un+_wIrf$
zUjweyjc#WXf22{*oU7KR#^di#*^l)v%)M+)`|DF0uCaGX%CyR9tDaN#-qgGO9gpWt
zR?&`fdYNzr>rt3o<qEyK9UI*=Zf5%t?rS^fKB{r0%f6V3DlhW3n6w_Tv>o2(%~*Z<
zd$}kkH`jRa1;?6Sje307>K}J=>iU#`cXzJ$Y~P4$Gj~bY9TR*!Ok#4suZPMbjYTTg
z;+{Kt9?^1Jwc>8xZQC)qS;s!iPmQ|s;&teRD9aSd2CQpga!%)(#<loZ_QaqvtJi-y
z*mK9t=~rCd>jag3(|OFXaTA}Q{3bKG13RlZk9cBP&~e^`Sq>ld)BLgxm#5V&v-@Ui
zkHa<A48sS_JSOL}L#sL0d8pLvP)d~UtN8~W=Jk7WqNz#^L!)??S4SEz5zZA+sc};h
z_oeJ76YHVFzD%vQVtC$Q+vYnWbywZ^a<9jwTpQHmFYtjC?eU|77C$tc*I;sTl!~Q^
zL!zbb@%$BAPfj_tIr#2|+%0Io9BRnoYaz)y*<=2&_8#q~tFGOzUQd>FdCH^<J`d)!
zdb8r)mbX}U!QO)-XBx~p8LM@v(jV2X<-RC5w|TQ``KES<*N<It@AmRfK4$p#%G!UO
z|F}GKdXGMH5;~`~7?b+i`oL3%UNO4EmYR*!d$xD$xS3eb&g6QjZAwkdYFIa}O3fbA
zyVZ+|Xff%`gr4<V1ce<{?fk4C!k5V84!drj*mwFMSKD)q*Uz-AyWqI#2xr5#CX&Ea
zNf|>w)_Q}rJB=wG+6T(-j;ZLltVNqkuksAd2G)$O{N$p#xZY~tHXRCV_9GvdGP(Bc
zTMV-O-do4;v$jb4<*tWeo2pjqHfzVTkVCsJrHk4g#CLTj7h2(aw~DLm%M3J1*>k`9
z=;_nm+%<V@5cszI$IzCm%g?xgvwoOdDt9_9qt%kS9~!&$I_GdTXJBZJ`>$`UJKnZ+
zw1>l+9?4iA$K>Xns_|}>?b|tH238&5(n^2k#u+X?+0iq?BRhny%2v4=iFk-89`9Sm
zZINV+&8=<F>d~Q%(>tdgomV$*;@)A?V)eR)#xH?;?U-DyG&rJSgLz&9?(Vy`Pa|c(
zjvE1eY8t8aS{wEFYXj%^1;{T<F5}i=|J-<s%#?@Sj(vJ_)$_vFDJ_#~HHo}eG5g5K
zyluD9PhoN+7muoPe2Zs9?eVvdxh}O{mNR96>*m_e*WSwwO3F8UQ3d-6Fu5kx8XmmZ
zsr=_jH@a(Zo0qh7>d;vu-_UcRdg~TCGak%|#aK=gipP{irX9^QmUJ8yyY|}IIR6Vq
zxoc)b4Quu_#PaUi>l<>>Uoc^EFSE;jY8mrl*Zn;emiB*R*3a~1^5D0PW7{pXzpvKx
z?EAYoJB7(Tem1p5wZmy`W9OJ#8u$-UNg4m3$%U<^kG97?xTNjU3-9txOm2JjnPFa1
z(>GS{hiB~SK61~rYjOHF4jbvZ#*f-KB0gm`)=4qBG@}^byeZk=PhWkwxM@<x=zU*D
zf3M!#eebTmxno~W^Rz&@WO4&u)Y@}>K(A|OZ`i%uYuWKYKZE?$Cd($f+!<E!%Z)=h
zepr{OP4P`nd!zMiRN0JrU&7)>={4JAso`O&n~@vc&Z=T7t@v<^(~M$rGm@&m_i4FY
z{Z7v0MLBbqPqXcvb?8{9aql~{9=9gxxcPLfCuMSKXSEFPzfN$B7|QMYn$pAV?T!8Q
zlZPEK?3WlgG;eG2D6HFMa&xYwp5JKNfAq6v-F#hh+GzOAPoJ5sKl|#NThkM5YuloK
z>8(fM`&xeglbI<ApW1$(Kl5Sm+-7!96I#^0bzQvBs^&7a(QQs+O$~GJOY-6{*);7a
zS5a>7k*3RRN6nRHY4;r%({XsdbVl=An8eY#DY@4(q5l3lX}U+$Q+s9g?PEA|ZH2G5
z`W~`tHO(imLbbdC8ON<*{^oeE@0K?qHg2EiuqG-yDjn*+>-`OtE{9h7cl|VGsctsL
z4#dp8TYigb4twQXJ6(D}?OyEo53kIlr;MNV@$}>?Z+q{timZV>FPYr=afdcJ)zj~~
zJ3cC--~E)cU&q9owaZ$qy(rM-`(4{^NVg;=Hz?%pG2?2tSFFC2^!CuzUHdw>wXI$0
zTbD;&<~M6JDbdv&dj{xGJWh=o_13BN?oT0YE_ZhGztYk_;g(B;yLr?Subd?h<4>VI
z-kHh8M*D1RJ1hG9h%gU~Q-*~O-aBMiL(30p!)teHGB0A+J&rrb<fbJg1tn~&*|oJr
zZ0k<;qWT@T9(ds?@?Cl<b4l~8Nv+V%dC24foHM?RDX8$Fx>$EejkMM4E{D$v-ok|p
z4QSf^V#wHah)30C6h6I&z6G&S0bM5>ZtJl5^tcs{QwLp~V)ZEHBByS1WOF>i*Okcy
zkJoN4TM?l)JM3`Xq3uHFrCCH=*HYJtUUEA2On93yFR}jxlY2e4MXef7_Fa-)^9h((
z(B0NzQmYv?qx?SgTh{N{>^<TvtledDy{#>KbswHu&v`-M^BbQ7FK$ZUhMbyM>!{xi
z?XWd{{k^fbEt9K|5ZTJ^O~L(3b%s^ju(!@WpBB5DjM%qWv%Btx3r%uqo>UF=1w<;`
z1?l0?^*Zfeygl7$+?#RkceeVtw3}A>L+-X~=`+@-yuiK^Os>wQ!K$@JESi4ID6-Om
zVWVn1unP!Ovt2T(cDHlKdW{-pk9FNl?&vP7B-`nxEoRsZIQ7UuR(8X)BTp{`f2j9p
z(6mIoweeH2HiyYYAG@6~-{tBDS<uH?2NKr@OxScfRwZWAm)FtdTvv>y4U%3nxlgH!
z!Wwk_-l5LaG?jIq9g|)Sy)^CBJOiVZyS>g$U9-*v`<AeN;~w=>O?|a0&e8A*S#s2q
zo2@l-(mmtIx`7eTo8C1J_QCsOI+N2Ks<C&>*5LD-F0U-NRQHLc#?1Xz2UnKu({g^?
z23bAYgFT+fjY+*9aY<&^>QHl|<Wp5zPtlB;niAW5ROsacJG2g6eS@&QWpcX*t9}XX
z-*D38*jD=*S}aa}5vcvq@nrlB?VP12mfP%d!uSh&Pe<AxyE!ZD!<(yblSfDrhqZjX
z;a0u=L63ZPB=3C5sn)y*y)e1?6RL}|%9x+K-M3<j|I-%U9}bUecUZ0S=sn)eD);G_
zvkGg)nB3`?i(FrNg{*sZ|BGF}Wix}G^tM>L?cREgS=}~mTo~FI^<NX#k7~R>W~Osu
z-9<}%CokGCLu0x0l4-r^UG94uW^E~O(bb=V_Z#akh===RSMV|X5O6ZM;xzNO9ZtS%
zd(z(F_Oyb)Egg*XC$GeMeJ0nc_o9*2CI;-9bzQ?P-|WKc+-m;4Qr~O|TpZ`n?Cg;t
zsIOY0E)uCol9JuO8yMD&eOG>E(yr0oD&Ze@)lpxzW}0tAo0Vp}5swi}E@6{e%E0#K
zWxE(yAMSDa-keXKuVbcmt}5Q{-e1(rx86tW_rl~BN}mm#ZNGG5_yG5Se4V{koq7*4
zmt=)BcX=}8N_wwD>1ekzIrZMVB=gc!lWu((vcP3~&8h8<JDI2jU0%9ndmR&r+t7X3
zTbId=aY#PkKOl2@Tix=O-0S4}-Kt%W(zy_yptkqj^MkFI=t3{7z1Hx}mBxR>zqq<(
zvP2xR-M+Sa%IlB@OZE=>=-F-1yPEE=v1bL7Q!Qs0zuLa}0P(98jVH&OozOX6dt1iV
zIaivz7&s>6`+U^l{!DJmwF<|>)YdQ8w9vV=<C*RP(SSZTnzgyo`g)bBO^n03IATi+
zCiiBr#U)qA8Q)K*Z1c@dKe2Szlca#T18<&f`Pkid+Q?A{Fkg}N1A_8xePh-oMK;hH
zJO0zO1E!7kZn8A4v%b%&)1IcgI($O=z?#Wf#kX9!ug$d~FSBz4UOlKcrd#gBXp;dp
zPdW}toz}na-0o-(F}Z_D(sFY<&0V0Swl|{p<AKkoZQT=?+5G#Q7hWqi`Oa9s72kB)
zQ~JIf@Bd-@o~?UFIW}4m*I?SgC%&IY>`a`uW0%SI)HVL-b8_ZPZrqUx=||r=PPzYJ
z)3#Q+{nvKLdK<M~k{`OIqTP(f=A+ACUjQa|_v>2j?7a>f4Bf6=bPkXGsJ4Gv&9(=|
z=x%puUZ!rtmankXoykRhee?9<e!Izrjb;^$UisYdK*57S4LVlb7MV5PargbJh{ro7
z*I-}r#3l<8&4La0>BT$r&a2v`)y>W+i$As+Rj#39;`|Y)H#$%}R^^B0^tQ11?Cx~t
z=&r5Hayn0+tlgly@vG;n;>L36(WqZWF}YK9MkY7sX1?6qAoFB9!;Wv?c@8*N-K@^?
zkh$}|Pt(haK>1*DFM=E<wC*=(gInaBRl#%WO>yfu%s<s^#+0Fh{B|!pdjVzg6q8G{
zvwNar?(^vCkqe8f+)P@2ri(_C{M-vVy-ylj*}Msxg|)g&ZjD#M)Ps9Fq@|BHOY@%G
z{QXjwX$^E7a(#U!o_@B}L(LBTU*uJhN@~tpagVy)otiy5(bsc8(^d=Kuc=V}gVlSF
zWjmtYrB#{6ah^=hC|~u6@z!hR)`!{`9Nsw7V1L<F-fFAMG})OxXwl~^om`A_F}XKk
z&&r49cS$pQ+IM$UK$PvkT`FI1j|;MIw_*EYgFXH6K6=RHRvu`5Hn;nt<qhh-`+RE8
zD~o-`IjW+eA2)d=<X3s?`))nv+_Lt@(QH$b>vubLZ(NX@ow`S+y-Cv{-QlZMo=x^d
zm)G-RyP*HZ<mMShwJVt2f2eoYtJl9Tb$SvrtzW^p3+EeMS(uU8e#*`!=zlP|6%FgE
z^)|U|RK4FmwF#FygiaoEIeCn9?%>`FN7U6nnq-CjikMvQ!@~`~ew5~Wn&^%9i|(y)
zu<Y)H%G>&Jb@MM&w9z{?3G3_iNq>{2)t=aNIFN2qdHJ1-+2uBD(6V2%>`?wbX*u(+
zv+pHd#dso<yZ1KPDO0CQiuSvX5w#prcGey;YRAzs(N#jlhs(bDQXB8f`Aja?bms^C
zeq*?+mBu}-UH0LbQ;#LzDrsKYy07E-6*qQdq2G9n$#p82d-(X|Z&ASxZTIxaD=?m%
z9@Bn=OY)3KvVgb-0V^LO9!&1c=fRnuCU84e)w_9UZ<My`0o%TLnbizcGrI=W?46mZ
ziT(%sE@^tnOfS03jvAXz4R}BQk6o2_1}qqml^1<&!tL7a>uG!o;kYqOZq_NMN+&`R
z-v<YMN_?<AtIn5WIo5}JKMTC<XA`J?6UB(zz~qvBHPgPXT%GYX<4%Zp<iM`4s(!jU
z@>o6N{ysJ9)!Db%8G`?dE>*<kuYUjcboY1q>GQv{qpP2fRQiA6`@ei%{z}y8bXCS(
z4tFKov1o6eyw9Iu(8EuPE$jzNe7yanmfqgu@$;YT(aFz0r|<Z3_ve)*8yL63T><w8
z+%a%pcDK-dO#A2E$MF&p{LI{^@RV?|xd!q*cBK&T8tfyb?M+EmzE8LcGKQPr7@5%?
z@?_@i;mk~FZbBsD?S`<0!Cp8E3%`H3eE<03a}#Kv(T?}n`Ub8A>NR@qukfrG=LRYi
z8j1(a$)L3e_`ZfXCl~3oFwTlPrTkpN^+TL58DMP1#cO~hkhdw{8(c6S=;6$pD~3l$
zaJUoVOle>MM&NxQW8p6&Mj97}r#~GogNycwtx-Z?VDv+Hew7Af?jkrwX+Zn?lNr*0
znNk{{Kf}Gljcx`PF6i>l=7-4bh!7t%g*i2*Pd?q~Tmf>wc)F1ujD)!^4Jtwa*BL0G
z8yE|2LApeo<@4fjD59sME1wxHcpZe>Fe~goRNGu!Dmw=$6xBRCn}g1nsD+s;bWVrc
zuA*}~^schJg0ou;p=rvS<+OAQ&5Tf67dJELBsXhXC})5c4KG(@W@PxYnE^%sc)4!a
zPzuRQ{u;>5x)z!lQLtH9ip&fP%?t|V3=6|oWM)+8UXht0-rBtWDPNKP70V-?#Y5$o
z%AOxv4^(*65i6^tPYe9#Kanr2luv5N-LZD}qKruSp-!P3vQ7YBN051gLUSAp?#Ye-
zVD5@w?gKw@9Eb<b>|ti9NE-?t!oemSkzW@CGyVV|XOvT%8S<f^V39V3i2_h`ASwIp
zn*6t6{t~}pzde!vHZVY1^b_wU{82}$`A;nRjg(ILxh29WQp3Jrc&>MzuU{x^H-)hI
zPxO#@39=_qnP8t_R$g=jS<*wKAS-6)Gx_;>c^A#6lKX*ucR37GauqKY`H@_LA3Bhe
z;hqcG>Vho!v9c6?oP@nN*sG6C&X5P$TCJt97l6N^clMklxI<}6Wm6tLI^&-9kGm(>
zB^}&_tQz#@<Aq8IeE>3h2(t|2L}msz$bKUH#lCDDy_|Hgu^RbJVLl}I<%ai`SV(xe
zpJc}kcHAI)Si#QjU)Yh`qx4z_dt+g5IA30vUva;%Cy(D<*ck#l$$}lqPhqfwtj0M8
zV|Ji8(9c~eWob=*(fh?!2p84u^qeO=CkxNZ1-InCH^e4#6!(RwamWpMy?3Z83~^P*
z%bn`Iuc!yNq29A+^-LM@5A`1OOm%;pjBM~1mDA+ZU)Ot<Q;X`oLHxUv>Yu{;%%;%H
z7$N8DpCU6uBe_|RLOH|2`mD&zxFos4y0Gdk7I*ktRL5x)ni&_?XGLa4&=MaO)j~NV
zR-aK_U1Vll=tq&6A*+`uk0DwAQoUzX%6gBN`?=l|?Ek*rL)u6Y#vkfE!R&{64|$QV
zqe`gv7RrAsx!x;Yw~=0dtS^7A_e98p_INqGfb0isdPw<}&JeOg*f{9M(;-M4fLd1U
z$)5==cEUtgM1*8UD#$osr7b4RV)J-EZ@CQB6Ujmx73<GK>evqwe$IejRg#P92@gT`
zSM?`_H4*lx{>)C{?U5fzCHUbCxs$l5{w#aF$Pb@V_>l>Fvth5&4c;EjskImEDb|-1
zo=A)pQGK~ZkY)8HWPhqJVOG4p%z{78uut{nAA)^WUkZMeR9}*vm9Rtg<?Ne9@!I_h
zJM#LH!kP?wR9`md%Nbu^{=y#Bmt?212KF?ColAlpI=e6ecBsB|a&z!=z!80Z3YDg!
ze>Y(l`^j=fw~O?66L#hAA(l7s%)jRyiZUnMCY{F!VdL8$Dq5OwZzb+w_&r*1lhxls
zcuK0jDIR1m8FydU`=Vek=uhm)>;5pIOqigarn-N7vFC%uo)e2bUn}-(B&3=AU6CX_
z%ikp~f}Z8S?-iaSP;-+1wT1BS5W>@3cz%VlO220a&-Cu0XVW{p?&Z(Jg=dNn#Zi8C
z#Y)(x3qwk*Z$cGoJY-}K$bK2Izn7063b%{cpMNh=ef#qzVto=S1N6I5b@T(e2e`Ok
z{XL}<vMv@S7n=3pYZAVVz`Up5a7vr}2Xdzdtgtibg{CEy4?63J+LdCQzeI;YlCvaR
z*k>Fp@elBj{t!QBEt0}~4BX{#H^sdR@v{-)H$fqSzdoDeKNCM{XBUqjrIoxLVOI?T
zxQ5^+JrBfv0J_c;`n3vi5mVWv`24rhi_(SSQ=QV*+S|zi-3CfS>N6CNBgs<Q(%J=V
zTu_*XpCGG?n;#3|$4E{hLe#z2!A;k7WK~Mn8z7CH+yu#95N>{qgCF}Kdz24JFLW)z
z&!n3b;5={@xEREzb+(UeB)ARFYr%Lh8axZG122Q?!6)EG@Ey1bq_LIFAo*{On;&nW
zbU+;78HLjTH(kddM`IHSAgU;~KWlC91fFTU;-uh?J^tp$39yd=>Qr(E)pOx~{O<Uf
z;^7I-0=>X;kVD~+VJ~kEbuK#(AP~f!u3Ruk``}LkX&hoQNa4l#2SPub@1K)D^v<BO
z9_ac8IcmG+f>vN2Ncr$Ph%m5y?WcmMG-S&NAn6Z#5z7vOsvzRVVJ~9YIgs`@e+AY6
z>HHPij~#o*a<m`24Oj=H?;UkPde7DaeL&hj-4|>KP68W&G7x8-$mW2EqiiWi`_|%2
z4X!2F0HpnBhk~?UEY7-M`^4@BJK{MV#9rF6Owbs_*%6!xXbhcT4UNnj>;?vd79h?}
z;JSkvsEc}nwZY!tK+qB#1oi{xf&;;2AmSv82I<^^PvBrM7aR(9M8+5cT7hD42xt$E
z0UbeCkoG(E0%@PqrJyUg7IXtsKsvwRj_~{f90&6Za6I@8^Z*M$FHjX354x1K0<l-P
ztRsjs5M<cXoVnv6JO_gTFrN-$4{_N-Fc8F^;vCLOkSzx%f-ztSxC;yg4}sIb1TYN5
z-rL+v5KTUA7RaIRN8v3G(lgHH;bw!4L8PIK`oIf7oRz~xfac(0urG+c%VkTz72pPN
z6}S_`c%tkSxE9O=qrorWdJubyb1~oya5K0B+ybrww}I=yT_BA|?FOkl_#ln>{u$qI
zqw+xQHD{R9bqjJ-9&UqF9`1lt9`1rv9`1ou9`1uw9v*;H9v*>I9v*{K9$tgzz;y5x
zm;q9G$OMsRxsM?73ik;_9%1LuAZ@uUJR@zmFCfx}ol8UIAREs!z+7-4_#K3fxB_q^
zNaxV(0Lz2=$mbehXHXNQ{qAdk!C+1B8c65SR79NXf>pu#U?UJ^N;Vv91TFxz!Ihv6
zh_gYsW?(zy?-rmD*b?*tTY*&nw*|2`IXl0G$^*i}%0owx$^*j0%0m~B%0pL>%7Zyb
z<-r1^^3VfZ0@67*QDAQ{8KnGmTX=pB(z!PuKr1i@><fMetw9y!%K;#j2OE&e1D%hf
zSRUw^%EJ(F28g<Zm4{&<m4^`^m4}fal?Pjp$^)IFL*>C9r1IbhQh9I&sXRzP#qvPU
zR32PGDi0VVXXU{Iw8XPFI1WTw$)unZq<oK!kYwk;ATR|)8p>{iQ@~V^&f{r^JRAyQ
zPjhZMXa$CWOTii7a&R^n4bu5MJHZ9uA#fp>3N8abfGfZ}kk0L?S`p<BGzX)=-e5FH
z`{k|&Z-E=Z=ip}W4HyT01h<1U9<l?Za%YK~Z+r4>Qs|R|nrM$6cF{iY@RrL3>Agw&
zz;^&?A9xy|_zqGVwg4pesQtjV_4qa*xrgk@>ENcTEB5<GHsHE}O+j;E|9=`h;oDVw
zdyDKLn-=cRj=aLc(Hb;{d3%uBV;#UOFs?rGG#Wt4IphET%^B}Gg3@jF!IQIc&K}m^
zr*UKLIkg9Mb!}fYKC$C${kPvYbn+Z)iwybSnloP7wH*KSx#gu@%kg*5K`-r^4?4q9
zREoLkrJaMWoLjD(Tdtg2{?D6R{#l#K`QJBZ{C~?_a2*T|h*Va5uJGETQgX;`>Grpm
zau&b5zvEK&y@!$EaTlNY#6R}^tei8hoHNeP887Xc<bV3y^3txEF72AK|JGdf(yo~f
zZAIn$_iLd`yVkh0Yk5mMm%g-Xd6jeSm2>WubMBRM?v-=ym2>VD=iDpzAp59wsN)#*
z4f)!=H|^MFx~*;MFqL~4>olbI{_po>n8f5nYlHKT?ycx6)flzsemjqu&n9a`CAZ0l
zJl4eDJ3*)U4y?sua^p1LWZKxy_B8Zd>FL^F$(pIVm3xqpo|Su$72iw4AA{^7mAvU&
zLLRN(@_hQlN=K?UZWf?9@!k8jkDgWAe)wPAgRHcBi<NdSFy$U!6YMffpN2f|+otiw
zlog}=n|w-n(FfmbOex(=7G!0&nAqsS$QKR9PV4ykVVbm;_K^iEqap?@Syiu@wJ*MH
zGC99Hn$}@qy;c2(q)9eeJe9TSrFlNqYDU_<6}qZf_8qpvEzHLesnnd1zfWUNvnQVo
zW<Tg~tG&hfqdFg7HF>ecuI<#mezlfHa$J8V_oiV;Mt|)~VGHy$W6p~8pDvnzLDFYQ
zkJ;nitv)a$V-V($%wuvNtvw^dUrF<<9W>4K&-x5KSnaRw@s+{c^Pa!uf!q3leWpxP
zFIVw;{g1tlgf#1v+JC-UqrS7ci}g0+TPVH>h*W%@w*PR}eCpog!A<TyOn&%z)W_@T
zOUGI4-rcfi#^la^HA}yTR%!RfD(#+E|Mb1A{#$!b;d7nxQffe{0i_0%8c=FLsR5-1
zlo}|7253Ii*rNUaOLzXClc%)37dFhFAo20@9w*k*GwEb#q-WSsj}8xTW~bvhxsCUi
zj{o=1{k#1yoco6z|NW!^KEk<wL7q6Fz}*pH{f{5^Cl3gnmB2PhU<V@zD&Y_Nlb;=M
z0rNQNYQuxEJo-N;+1dt9%v+-MAmy}f@@7u{db;fSnfw_WqR<)xnk#n*w_vx>%^EO6
z7mZyOn3_j_^a9CiE0E^SVSSAZQw-Vpb(qS>&aYDk2f-Xmk7&JutSUGZB=<1AN>&RT
z31W&IHwvUV@1w!`pe@({v;%4G{1~tai23L;e5&Uh!4{wsh)-9XGe~ppXs)0AWSU#P
zP{Yq;g!KTMW8>8mZ;xJk3v>Bulljl*<-v;bQffe{0i_0%8c=FLsR5-1lp0WKK&b(x
z29z53jRvUy|5x|_!&!PIod4(I<l*fv`M<FLpAlD;?M#4maO@g^4z)i1>IG_HAzShz
ze*XntBecJY#Lo*S_0gLCw!9VgKf3!|b}HK&i0#2Z`=BLaEj{(GX&;?xPuM;X*q2AI
zBUvCbts*m8x>npwPj1E)$x+aloPrs?-v4AqU2wMN1Fg{ut&VlH0gfK-PB>7}PvU?z
z>KJ?A_k*~ngWsh5o?mwnUMYUV9ytMiUUVQ~fCP{55Bq`Px8cpO-cfLX_VvJ;Y%T_R
zn@{dN=J&avy#*c$?v%6#T~|ThOKI^Ru90wq!ie?POy52af6%v=w}-dW_#(A4z0=r5
z2^Z5l?Q>DuILr4tP>dIu$@j7F<F`P-ehDgCSRctnAj}c)IE;mn-#4RF`|VKy#btn-
z!bXX68gq1XONuLgE1tJtB)>`($D7c9<K}$2(wLHboGS7c;mG9o;NY`3eEPfnr!lQ?
z+<aNWxD(R)H55VXMlnppE~taW4Mk4Y6(-2kY<~yrha$U=XRPsN>$1(kw|MRWlDjkp
zhP@5A-e4ur62u+^Y)niSw8k^`2w-DkRHkk4O!ijd=JOh#2Pr(7Fq?;)u4<5j5j#th
z@*AcL$YMYYU$OP$b;09!#yFYmHi&UDSsI9OGFe6VBLX$SCSWyC8x(;kZZabfMM*~C
z!MK?WdlAq$pNz@?>J%0}D%5=b;PVZIkCIPb=U}ZZ3m@{53}NL^S;#0~>4OwMvd^b$
z$@Xb1km5H~us=+&KOD@0c{tYGDc8;Z|9RF@Y0r@RZ>^gRKw%N7_&V2Ke*ds$H`je3
zDJ|};d1P!<)xq)GJf~|*W_3NXZK@;QEllqBXV?AH*VmTzOwPZ1eQjya?kw&4+R~o!
zS=x2Dr9I<Qxn5VfURSwZSGivIf9mX}7&Jn0=G$tI+Om(~cfvAnwjUER;@bZBt7((=
zu1Ze$dU9{ivRis8&v^RZe#TR2*UcV9-%6zNpFaz#wCiD~;v>FD#kib9bC>;FPA#<<
zH1*Edn5phL(Y4dvYDemMHqe>p=icw1f40;(3yQ~U=P@r&pD}h_)MbQgP}9Q)-?{3}
z%x!$gRGJh2ddn$;CFqa0B)Q+8DXColTlu_Z%S&70{Y+Mmh}=@CT9x|s-l6kY+I?*P
z?sdYY-FK$6>xoOdpN#UXuYd2XuhO0gTiP?hN_#f2^6W6>*<t?|&kif?nX9EeBUO18
z*+1(nGUd8x<+^Cw%J>$7k003oCG`u}AgG_|z3=<19qx@EdDh=0(SLf|xIO7(Qbz{v
z^WnJtOipFk!~&Jujkg_(xv*)c&Xx}j)=hG}X7qJ6oq3~&r|I+q9QT~b_4#8(>uOrh
zH*MFCU%0d0wEnwiJq$VPm@@cH(zZ3NrtZwdcPxB;RIZCIdr!G8n({%5hyf85J4qv}
z#iXQJ?7HP#cg~0neRNJey5Vs{S6k-^`o2%Fv8za>U`@t?mj}0orhi@CXq(281l<W`
zUWas+#dgzKIUsUb0|$IFGbOoY?JhS8|I(uW!1S$0ElspMt4x{WJH&cWNYsLRt$V9Z
z-GsfnnVkNJ9dkaLjjVXQ|CrkEtLD$O>eaAYi&Od1srk=SW8-R0$A>8<cW%J^9Pe^d
zA0JbdCMefMx3tDy)yj3z6@t~K-^_b(;Z}#Vqf&>YZ$_(U;M*oX9*b16mbz@L6L6!i
zmtEOE%G|9#G3b-s;XZ%dewFUqdhhUkZ5LpVbS5`A>Z)(z@;j3>`^}i;A-Q||Rl|wz
z+pX>Ae5y>1Mft<MHL*uIlgkYXx#9V>*&v(!s>Uus;ZrTnCO_Drnb%CMSJz4D-7Ctl
z*Eo}#9NKAL*Rr#8QuAwceimu|*mk(h#?);8;V!KMAMB{(ihg%ReCQUb^sCbORHyW9
z^DjO!KM`N?^Y@s`*Dvi_eB0FeOQi)5b2X6Xm6uWjN)0GApwxg;14<1jHK5dhQUgj2
zC^aD00L=^itMmUoyaP*^|L^4O>FF;0zcBy*x-cJ|&RwG`3^(Q?a~Njh($TLrf5y*8
z7dzo}Rey<_*fqex&spLu#z}e}W>^l;)zsA6N8;xo_4aGo%FN8e!PC*%K`ha8c5!eq
zG?uuyI2sul8W?mkaB|Rh*45Q@G%=Al8FXzcm+UAp&@(X7*E8s(uP@P+ICL^{GB9>=
zG0`=4khti(xO5dYFO-#ZlsFq28R)whIO;n{OpJ{T4GlXQ7&#m2n&>*~={j^3(bQ=+
ze_KR<2p77pT&JhBHo>0Fv8J^N$(SQv3+A*Z!44KjIxD>sTU)Tb@EMyF2r@-xM$Ar3
zp^P!JQ}nFI)-8~`MP`POQP)a^pQ~EqtRy#ge{z@1Xby4`^z4r{2c&Z{!%!%90%kbd
z)ZH5g>5&=5;StQ7JR}ZYkR&r&lOTn;e4akdbzcjA*A1`0VJfv)EOFzH_Vv^0)=ft&
zcAzw586N**Re_6}*ujfWN%P^QP7iZjqbw{fb#w+<{7be*BdDC8kl#e*=!u;d$k84O
z*n5FHhxpk%74qAk1hz1j{XXxMm>;OV;B}-a+k?L;KhT;DK0okjLT5m_xD}<xA%*l9
z&Q;L5gXcfhsHv$~?4fUJD%b08O9ajlhr6%;Wp{s9Cirt!CklFhE$F=-;!S&G(A@q6
z_^He5T^`!sYPKk1zZGTWk#zp^Rdk*yox6Du;V51<R-pu%xwx@(r2H+9$L{jHYnUR<
z;z4Pb4Ew1+#^bkIFN()+MN1uz%l|?=f@s4MT#E5{3i~3y-j%1vZ)-k<c>Fd)(E66r
zq{qWj#AB?GuXL#*!?hMS?YXiV_W{_CNM+?&9*^H<7R9#-oM1W^oTf*G>&LvaUm>h?
z?(j|KFUK{;!WDXcCOp$Q#gvca;l3a^ULP(~dBFM>?h@QO`7h_AqPHLgva~wBs1R<&
zaM@E}a4ClC0c5#<IbZy>aNRE!F8LZNA3EF?*I2w@NOg2J>TFaZx@?VJ863S%Ehj$y
zl&4F$*gKfk-;sTJJ=-01Un2Yz94KCU{x;u`KeSHG8G7r4Fj6~a5WjAao%btW(^h;<
zp4^TH>_ouMEd@J&wziGd7}?|I+ef^AyRo2)l5Hq%x)SlphT2kRK{N0?*b}?}V)`L>
z2^<by2A#pHAgxVI0e!&hAo+tTP<Su$@5?yU8Pr_U!A;i_$k97A6{Pp*3&EZUfAjS^
zt%bzzs56mVtj-7M3~J`S2!HeSCSMPc`-*Z;73BDOsbsn5f}B0v<I6o?ACSL_dO=++
zqdJ1tl63@WE!hANVU!I9k#A%YurWw_XacSPX$=|GD~jRf%PC(@{w&;lxhYvr9&Ssx
z&F5o2e^a>WHA87fmnQtDJgWsFOlX5~vQ1!h5a;%?HF8uQkS=TunPx+r!-@!sRHoNa
za|z7dFyY10_h(jbJ=Hj2&AA2}Zj3)L_hHg?`*&{wQAZh&+|qXHvbQ01yxth*y)JKk
z<x0A#)!sEpDxU{eICy4C%N4;m517d{^0#i-yjfb^n4uHB20Bj+pD*j*_WS1y(-{}^
z>UM7!`4R6?CYP-(ZN8!0=O_AO-)Z~zT(_j7?(pan6Yc%?$G#WsJ~(U_&c$SMX0skF
zc>C~KeXY&MD)zkf<fX=yxtA(*?q(|)+M>}^_4BAhA2PYuJ<t1jboclC+OyYQr$G<P
zJX@2L5i%lOv@q~Xy_nPSi=Y!^c#+D==f<L(cMBiit*~vWa&CiiZo{I=HPlYpt{bx5
z?3H2KoQP*;6>kNO{G6MNd}U1eC0G55^|@W5s}H+8ESvD?&KtYOV;|eu_5Bbl@@d^V
zVAw>IJuK)HsWeN8j9#^Pkzv}$z4HQVuY8bIX6F>nW`4Bk2!s183^yOZdRQixt!aOK
zO2akwE=ieIIc?Q*{^#d5ly;3<Y4?UN?b@}{u1PEHUh}10lcwC0UOD%I=3b;urgGVN
z=((!no*p=U$V1z0=gcjeI*&=|5qs}~RZ8UdSuysm-hclbjnb}FDean((yke{L}Ngt
z(o5}x)jCz<%Bi(olcI0r&A9r!L-3XGh}|Byw#_ehxF;G3rCqyQ+P(EldxlzR_uvn0
zMe+FkS!@6Fz4}Xg7F=o9c>K5KxRmy+y3(#0DeYNxrCl?k+za9V&%F>zySC)NwHLxa
zeeZ(5dryMW?ln-_HAbb~YoN4i1eJRYDEAsr?lthw+iRe-YoPw_GsH`~rs{voS>p#W
zcqdYsmXH*bu&rj-))uj?JK2lsciej5g{R1O>7~pi&9f%8T8MEACKuqG@nuXwg%8!m
zx<hKDtzLIId`|EdE@Wsx)9x2T#;&vAxT?*_J-vs%1+h^9T_+oE>#+IsxD}352VI<E
z^(f^cr*3m(b3FPBU71|)c<tu06%lH)!w%OS+AefnnnlEQEp@HvC8uN0gtr;<lH<lR
zxz}@B)T;4h-zC|#|LuDc{I~WR_@|!@{@+^5U)nYBrCqbGT#Nqitwk^G8gu2^apl_a
z|BGwKm218KS!=!Vxm0;6HK5dhQUgj2C^hi6Xh0RN3@<wW&)c7l@S_v_T>K<ByUuGo
zwyc+U*kSgwzg+<Sx1%%d9DID}&ywf=2l}~7`R)HrIWw&?_8g~%Sw8i+7d{mV+27sC
z&)eVIMJj4JxRq$2kJR1MeWJUUtEh*!r;odb#1Hd>bhO0c2~J`MsnpNiF+eKu$6PcW
zEjNh=X3Q&^(mW#_EeELw{2)6tQ5y&FNhM-W2QLR#iKoO%%FE!q0>NF9@pQy~^zf7B
zFzaZIaQAZd4)n)-M;)!+-T_|DINp%vkCWRL-L3vqhQiv-LN`dySl_5qM<beY27A_8
zp>;UURG8ywQ<hBmxo(*I#7)5c4RiKv^4J_trZlmmyO)Dsu$bSto}UL;gDm}gh3<hF
z&Aq0%zqK$cQ@$s^d`_Tz-g_n{Tsa1~xIm?BE+2Cbld*U+vA_F72{V5OcUr^T+h5Gj
zdx!hv2F>HkL^$R1<Y_)=BnvagEksP|d9&~=pC38}^XN~OFpr*(q_a1U6Of3dehyy#
z9!Mr<Or-aB7a~p5<GWc5<0W}N%@tK^Zf-fKdrvD1i{X4iJ2^PH!3CT`Aa?WimtuPT
zXgbS~KbN5`O*q5#9Bc=k1-~LLvbPF4|I^^`X%NR;;s2xZ!pBXsFbzmYlm?U@L)qV?
z7k(|mUr7(Li>$-R&sU&x5#lHv3e!?7@p9(VCmiP0k#1O&;NT(Q(>MrbC8gzQn6E_!
zaQ7DnNL^^XhPqY~xvP-A<d+A`Xu_V8x0k;+lFG@4pC5V?dH62oH`ak3YrP{K^8Q_b
zyanX_y#xH5Bx0Jviae#F)e_3ON%J8g-%>%I&Wf0fu{cjhu{>+Cu*hJJd5RpRzEtAH
z%)(&ihcL5@ir+{#r(kAI;S-*Z;W^O&_FzD9ior95A<#)2;4g7zVHt_A_#iCpK}&_O
zBnq;8Smg5RS|edjX(yNq<wQm61?=y`#Ks}eMVjCa`59Rx?}4DBE>hQ;ESUL8JRRJ<
zP}PVXgZX+)MXPN&oG$=(=)3`+_eHvV4LikkLvfbEoatCfb)&kLGoF{%r!zHBgb-KK
zw-jz>;x@;#+)c832(qLPcic2jS}xlF{_DYPx8Og??)!zTC1gz@`&2=8WieT~+Y~oi
zW3UnOD>C@Fkv<|IPda5<5KFzq4$jUHVd1fX{C3<u@th*qq44Z3!4J7VlolRHQ)B3`
z+Xvns(#<@<AEaGjTC5Yy940updpJ-9RFoEn;IA3nAsvku+#$bxU`J8sc6e6QxjY<X
z-wpOLWX)-2^5G!++aa&0caoReq5K#FJL(AgCczGsJzD2fJpC2zB*PA-vU0osDDr11
z>=;scKpijlgGhDrZC2ND+!f5FrDsdQp1kfJEId=)O}{4<`~9}U@8sqHp>CZ_lag_1
zApG<`qskx~^@vXvg{#c3s`>ygcPDRWN#QGw&GpBe<&v(#`ZW*nqxzN7mezL_)q{Nf
zgP^ks#>L-hFJP}owy4ge`ufK@PeqH?V2nhZ&cLbVEDn5KL*<e3fRB?K%crW48H#&7
z<n}7ay@MP}1DMOxfb{uXkdf<G^qEgL`MXlCPitXqKr-wjC|nZmPtfP?bOn9-Nqhs`
z@m3TUdugGiBG)Lbogn)qTx`7-<xBcq{$8SI(y8LR<~!mdyeFJ!wHv)yNcY(=r~26w
zDM;>9{5*vGm4&cUyya)~Sd*i;%A=md9Ca=m`GeX!G8TU!e@G=kQpLAF<S6_GHOS^q
z*H8ID9(H+LD2$XBiqf3VAIv%YP&|J;eEW0$pfZ>Q^OD}5nIw-m$lF3xkJ=#JS|YAf
z5x;vv+Ol#C*^=IgW|+LM19>szvjlkx_g%=7ZsqSja^p43e5j6dLCE>nD)OMZRx-?u
zFmawYXH5b2zPSl=dROx1sQO%`ZlpzWKM%j<BJAupm{Hh05Ec=_LiI_jFGcmq2gu6b
zukyT1r1ZWg$jR%E=fbl*KX(`E2LlcA8EG%1zdA_iAMsToKeO~lQ$)`Q^|8Fw`=8GP
zU5oMtQ|7Po0GYoa-9uintwZ`PF>gS(n$UwE(poi}*YB^=`W@W${Z(4SzkfBY^NOYQ
z$SNFH8DR-SnsgDuLgk0@SV{F(o**Mn=khsx_~q#=FXx#E8(qtVbPgBNc{h_+Ea%kZ
zEJ|c5=a&DWa!%!?q%=MT^Wx?F&(fIEsCfDB1f3p(4n81_b-wXBqPC8_Eb?s~w4^6U
z{Lt4y{id#U0q#&aWjUXkz|>3;$}0Jvjo<T;eoSNdne<C;QoTfZugG3e*{5`*{8RKB
zYlgG>!X~Gn;5+Z0o)P&6_o)1vRYmzH_wYPQ2s`D8RJf&>C*-n+AiEQ?!*h$`Np+|;
z%=mc9YcJk?9mwy)Js-dO33e#|9}?`yr73QSFe9Bf1^D@)!_Ie1VUOfb;y0?(h2IL_
zukt#nnc%kk9lKw6mgn6Q3cvI3C{4JAGw0d=Y)uk}CMySZumww+&nbRoSSJZNR_yIU
zy;XM)zQxGbPbB*D#jmR*9nw2?0EHPOKjmux5g~Tbx+s#tk_)y6UoyWoQOp`nFr)I(
z7A)Z^aSb5p3DphP9{NTKv;IDr;gPkC6#Gv%@g7$^<IRZU^$~-23SH4C!}{QS@E!7v
z=4)ObENsQj)3ata`2WbSk!-I3^TNFXs4s>!YlwC^t<|h8Lwg12nUD=KTUBVLPs{y^
zndxDL3vV{RP)?6j#^j33^o@Qt(_?1xv`}m#lvYnvJ;~ceq)XD96lRL=e^sQX2lN&T
z^NCDPe4B&X@g!T)nn|*=4t5UU_a<-nvP9+n?l0_6{*kAVD%O+Hbqi&k{yYy-8tDpo
zmQSM}-=(Q!;pZ!q(zy5-l49Giq&!98l;<fvpYcVN^jutDKew~hwPF#+iOpz#05QG&
zSyPhSr2ZKz<8BUq@=*b*cjBO@BsjbQVI9ok$m=)a7rK($A>|x`ohC1e^h;wUC8Y`J
z_Y-7o=oZGZ=sh_SeJ%WBeNupvmgUdO3jjOdIS8aaaWFU>oCJ!&Dc}TfDoF17sL02h
z_^~K*cRb9UVNTa1{7mChSPmlV4~Br`-W1RgoC<n^GW?qhP6L;N2%{_xoC)p*Bf$OO
zBJdcv7`y;31#9B{v<z$vVm+wL7F-FA0at^rU?jK}i~_HNSdT7y3`T>QU<_CZb;4$_
zJ%~In(*+R*S$}XVC<eEI4j|qYGU$Xu*kr4~cyJB47u*8w1NVRkv+NLf5Ig}M248_k
z!Lra%0$2?^4%P-wgCg(@I0#Gx$Ajm<CE$5*8F&#~3({KQBVZDE0=x#^2b00)U<&va
zyb0!jx4^Qh9CsV60Nw?wg7-lq@F6%Dd<=@gC!jO<9E<>8fLp;=;59G}Oab43_rY}V
z3-}()1v9{AcmW}=$il$S;2!V`cm~V{bHHz4jq)6q2kL^~K|`=i8RQobXIaV|!1CZ^
zumZRetPHLPtALw9E$|A6vn6G!$cweWDqwA}6<8N+12zPEgUB;7M^FbG54Hjqfo;JR
zU^{Rxh%+-~*Fk;o0oW1z3U&omP_bBm>R=DB1!xIUzq>DJ0`>zjY|Qls#oz!i2*eqe
zvMJyYa0NIVTnFMTP}vr66u1*ao|e%VuN_F`j>-f-9>I@OP`N{OLiw0o&XB8yzs7@D
zZp?Xu%|Rcq2Z(mN%mxeq-M~Q57YqXZ!Aam`a59Lp#f5?>Gh7%*e$NDvm$_Nsb#M;&
z0GtcH0Oy0q6Wl@&4Gt~>q;Ln}=KK9DkFt7*-dP^F=^BJ|M>M$+U>$H2*ch|}yMtpu
zE6@?7`pyYl1xi4aZEhTR4upF$lnvUiNQSb(A#Tin<aeQ;&iCI*Z{!cj(6tKTtP8FN
zO~5r^FE9#3Sh#4A{M`(OfLp=Y;5KjzxC118>;h4SxOfm{f!hO?gC6#SG%k7oYylnu
zJA+3-Colm-T5-q0Mc^rLBX}BwTU;V|13U-b1uuX!{%{c_{ifpP`=NaQl;TJ6LHTFb
zb;!{(++gv$2~zxSgA_lw$?D~MAjLBkq<FpnDV{IE9bg)WI)i%yz5?HZDBIjSuo}Yi
z0n`Igx3Y6xvq0o|E(e?d=7Q6}JTL|<0HG6VP|6TTt}OTpR0ZKSjkU<ApREQ`JT+m)
z_rv)98O4+Gi7L$L(u5qvQwuZ!tAP~H8X(297Kl8=)dne^O+kuh3y|X35~TEO4Wh2(
z+JetOeXsyD1RKFGBd{rG0-Au`Ko8IgMA_o{fhaqiHHbXJjR29B+$iuCI2wd5xiMf>
z#1HQnS$)tR>;gK013_nSDCi2pjB^8VbK^kjmyQQXFS@w-Ha_3>7ojkr+UIm|)72i?
zzZ{5nyo~w;kZ1Nf;cvd3&hKkL`c#EkTikT@gB+DhYp@#FA0#^iK=OATZoVzex3S5-
z7R;97ri=X12lYUdQEG$Bv=Hx(;Cavxq<n1z-Urb*mOTZLcCs>vADV$Oq#5nGAZr75
z0SAL!LDGu_=nZxULqMdpY!285q_(~#Na3`Hn|yncZ)Z|CTfv;p7^W)>daMb~1nYy)
ztxOx72PT3Gz^C9M@FTbc+yc8RL6kvmHTVRK0#R1D%^=DE7YkDUMcY8u3dFhDGNc)|
z1M~#ZR**r4+YjP5?f`fLMB71@1s(<Uk&wqg0}yQqnICu(l!9l#J>WTTA9xY`1YQO6
zz!b1767)96-uqxvJl_M&!TVr$@DWJw|5R`U_!683rhzlTxBrj5^8kxt+1B>ps9**o
zU>Xq<CZYsUf`SPY1w;iM(vT$25LCbc#T-CUF(778F`$?+U=Emb#t0@%m^L8)x2k6p
z!#<mH?>_gOd;jUj@ujL)S68jBuCBNWTnWAebHP_&9{3id`uaPt1bTVXN@3$dVdG-^
z=YPh=#TaWI)<l>Llbp{<>2N%6sP(aV1C%UGOVfNWzwt7^?&9Gx_2|pFRo~}hIScRR
zzyj}{cl89C-OHO9#y7QIR57-=<(yVU`(q8Qy{r47!u$w@j)1S&4@6-zgYtn&VaAI(
zb>sG5fAUBA64A%@A2QnQoaUgD7k%2-pijr$sjyjukCK4D?7*2hHJ=8I(>b2)q-S;a
zsr#N|ZO3Ta)jeMO^yMtxZ7=k5p$ru8pRSm3<;0jTAy@w>t1z(ae>C5t!Quv{d1I6h
znZ31l4?}~smlerP9lvIIYpr<ut6qbnN9zt#y?i38c0);#bC<^-r>@sLdIoI^c3+jd
z6^SpUZ#y^fGv0S@$ifuq*A<U+RBqji$qP7lMrGbb)Ulb|@%oM8CVoy#_|(net0ZZN
zi`b#7R(f>X!I@_J+E4pfga+(7Ca2ifMD;|*fW*R^i*&1(xOdOOvp{7-z;6;+o>PBY
zyZavur{C^=wVTz6ecErIwt2kXt;@uL;Z0MPp$^34p0$iEw%0m6d5)gynqxx!2g$Qf
ziu%p(Gd<wtlAVslLse0CU~+Hmf|gBtDk-z`P&L;-7V5OC;kK-d<YFDqqA^xN(+uR5
zJSJz+I<EMSOQG|o4mi0)N05?#<o&cx**EeQeLN?b^!yUp)@Xr>s(`<^r>{}-d4-L#
z#~RcT`qV7zxL@N;#?Xv$r>7n|vHElp!uq@SKT+7$u=+4>oO@v8&YL4%*y+AJac4!#
zbkrXewl%iub$#{mfRU=3YP?C=$I$TpM*YwjRM^&-+h}!-wJIrdPi4)E-`j3%yZBCh
z(otvDq4ziA0nf9KAhV#MNzyUi%rjc?c^%9%&bek^TJ&XV`GIjO&_+VXgn+-vce`fK
z<Z}n-HdwbcFV@Lo+OrSik7k^$cVy7wz2~32LVd`S$xW6{ZhY%qe5A0IaO#B1Sy9!l
zs85=mzDiP~)v<NaOB45_Ux3L)^><#}GrL|&>iOAAmTm6ZIJ~su6l3YN#)(C@PK@dj
z;ElcqCRZF{pnm3B+SXNdN?*CZQLY!fG~1@W&4CBw_GTnKZD|ySIzN+}S*{tKue<ZI
z`LstLH6Lbq`<*Lr7Y{3*U2E)GV^@327H9|hQaT128$4Zpe$MHyBL$0#0{W{ZU+!wK
z!AfQO<~CtIY2)`DLwYqxZpQKJ8}@#6H5)VH{p!$g%bPoI&0eD%otx}(de(~bD%94n
zWZ~W4^WwzS4oB*Ry{!>+H}R3h9=-c6J*}(<W#3-X-)6##>u4LZ@M6Pu6%0LftlPPT
zd4&pF9s7^)c<(hy&vjL7EpkV-&79KB#eaEs-Mfv?_R3jPi~qQ6y{V2%N>|hm+BL75
zoWfSe#D<H8mko1mziFB7;>#az_BmbZfbW9BR!5nU`H&{*b?=|5Bh*|H*13Cy!ww6~
zwM0jqfZwfKhoP=tZMBU)XbH5QY`HUeZG&1CQ#U<~-M!`Xb3vC~=(}Zd@hV>}YAtqG
z8q(w9wp-StCM7((VS3Ln>P5}B@g0}cOgxFP941%5J6u@YX}-qm)_yh$TOA5p9SU0=
zQ7R3~Dx?_0K&PvK|0QIlMOkD<W=@cE8~&!+yREmpy3FsjJ5}8K-RKnE&**Sf*y>Q&
z>fk@d7#s!)1$_0>!>TuRNuHG3V_EGv&LbP&c8iEocAY=6nZ@y3n~~1$=p$!x`?d_o
zcb#O`A<<!Q-dzuAwN(%IJ~%n<wdUQS2}kvoXHP`mHIqxvy;eNi=iF;)^xLL8kFJb}
zTzfc!zh=V6qVyWRi$+Oj@OVW`?p;Ch<QBcZc2}QR$Y1fnGykd6>4c}V411(*4L&|`
z=?e5&wC+Ih+g2y9ZJ1iE8TCVB=kE*RO;?*T;imC2ji{tYZEqNl3&r<CVXI?RV*Q1Z
z(`K5Jdff^!Dp_CQqpKf>aUItF5DpLhtP*PUI^xi{S_zgfx*vMd<&e9_wS<bO_1$~u
z$E0Fxm&tXqO&-y3e8iTim+JeKo1ZKyZ78-Wc(y)jUZzL8V|yJBW2~$*Jr7a-1^=&x
zMj9C}Yo_LJ85P2x_I8VUodru1!jd|tnr~f<u`edKf35PxA>Ayi^)j^E)91|18SjFM
z)=cc#K$zukFK8F0i9wZECO22|&}q7R%Iax@{Uge?w+}F}9cn2miEZz5-|_5oo88Yb
zro!av*lrQcdR~x!^`qk)pR6VmyB_c|RgONBvOY`QROIKB!{gm%a-%&i>=X}vGpUPi
z&HlWi3(YMWUP{wGnY~|m`^!hWbmn7#Dgtd40YA*U*}_|UR4sgSVlQ^Mx%94aj|Lu|
zf6VeaKYwcPy&ETbLVp+(6YyI;JKOqw_TzKwV?@H(Eca&q7mH$B%-=rrZIH##mreYO
zFc!t+s@E{eUgF+<u<+@k*8e@59s#VMu*iG#lfy@heUp2+_(r$gv+Jd=?v&EjyUiqD
zvWwQ|8P3Pt6n5Wd!>msGdM187d~svg=jR7gw%pH;m^tLiv5xorT@yx(+==x$T`3*W
z<*s3CR^%^hp*CjhyM&!)t+uc2Z>+wu-{QkTW?Q<ytA{Z^CO06vV`@(4^NvqGmqt9j
ztvTAFbbPw$V2Aq#Lkkk@2hK!a`&lNpD_>G$rpe4XYRcP_Z0`+ul(1o2)SLESXFLvG
zv^Fep<p#{%z#yc6|75KAb=I~G+edn~T9nx$Vb}ez4=$UJ&f2ua^lQOVG1|mDOC}ev
zH}d(um!5IAZm-?gN!NaP_mUTBD@En;>ub3swzed@>M>02#;4`HV>i36GV(in%6nSI
zTjd=IO}gwHt()c3UP+^6$EO%mV{*$rJ$rC!hg*zMtEm<LGqyiMS$lPNzliy%z1qGS
z{KdR?*~Z;%=SS>N-#cQ7$YA!irCaZ4;rlzXJLx4)eZ+<KyeUuCwRm%=tC7KrmqCM%
zH!@dW7&~*;*95(iB)peQ?s2q7q|TtBtNfPDSUhfqW}Kgav$()KG0tgd_|^r-PGV3q
zkI5Cfx!u>c48419@5y=fuH-K~(yM-(^3s#qwug)dI6Rv?6?1Ty+|uCv6L)RzUif^h
zd0|LQ`&TJG2`#ieO2b0OAAXn;_`ktM$StPlCc+^H9bEf6cYQSFw0han-CyFHXneeO
zCg9NCO^pJ+Xk5lz5=+u^VEOr*4_>+}*$s}Hnyepj&OGZDZ+5Qf_-4BPk?jN4;{9mI
z>P`DTo0(p^VPM_5qV#jYHmTNHRgdQ$p9YjUd>-#pG%EuG(H2Z@mQh;Qis|-FA-&IC
z`kLZ(e@()misL6wv^qPt_)WLC&27-%&f@nx?UY%Qx^_{U^M;@4)vv?wiy^xP6mIGo
z8+*@7;(GbRD9rI-;Vo*Zp=@h<rbnYeIm(e|y2r;jp1CkuGIN;iTo(=fefa~h-jm7M
z?ip_M>8+$Z$W(7^c)D%<UDdYkue)&&Pow-~EeE~43Fud0<6uh`WLRG}P4Q9tsHAUF
z`}F50?_-YjRyP>ECp&t;S(}LM7#GK&ynr7gX?WkE`_AX4br)Vg^|{8XRch`_7wj(2
zk<_sKH2vn$a~MNsayMUG@Oq=&>!Q|6gQTV&7dJO^9Jy(qQhL33;ht(wKQ==>Vm6a2
zHQW4Jf6!>&x!M5_npL}VB=4T+kJ_rIH{=+MU37U<3CgQnCTCJHbI*a8Khnl|blKLg
ztim|v`I>GnJ{J-vNFy>^M5Nw9dYRmj55wNPi{x!uta)X(!iEV?ar~(U&{fFu`M&<&
zLs!pD7!?ve*3HOG>^2}+A_@-@dHZ9HsavF%BqStI>=x+n8R-=s5sWqaqHe)hCLbvZ
z4G#$r3XP3SO$`i94D`r^fH&C?a0?Oz1%*U%)&OYzsJR-ZSzxxU{HV`s$s300v_IMd
zu*d#oAp$G0SQLbXn&C|NDX*6r&nwEC=WXWpV<gESfjn+xmEc?C+&m-v1HIimJ;Wln
z=pdLYs1$J_XV<_$pC^hI{XR@CwepbriX!z4-LOF4E!sezOIu(!x)!(p{q^!Ie~c5w
zma{wH=5J6*LmuKFmQMLP0a{~C2d(LqGa6&?1>F2(nPRy$iX=K)8}pyU60FhU)&Y>4
zq9$JhpamH(*fpSeTr}^VSI*`|_X!Cd=Nt+@P55b7_OtT{_Z8WPM9R(?S3c+HXrtf9
zPvkY03(J8!XC(;<>f;B$rU)yN^K<YB^!E+!FY@p<<ou`q>~F&Puc+*A7ZO5oqHwlx
z{)h+{lpe}A^3VNQ9w*4Z-dC2cZ}JG9`KxpOTp$#_?7luf$s?LfKJ;gKS^RS=`#WJ#
zh)n*<&;By`!k_(dU()s0pZ)D@3=kB%w{itbLtngyFpfY9r1c;*)EZRwj|k;XVSy$o
zi^9~Ze4bq=9D>Ke!Zhd3Sz`hEw`WfJa^n1*XnhM-s5^)1a`J9J`{O%G@_s-2%brKf
z&;Cda<+BvdpYGW=Br2GtW6zI%gF_@%lt`?O;?jBO$Mfu@EK9I-p8d^vx|no8Gxky4
zm8Xa9i4<|?RDL~&RB`9je?5nkap$`HdX7CSdL}m9xe-A@$a3tRVbOIG;a#No*jGMZ
zDJ68yt@1f`Etg6<mtXmuV-PkBWkIqqFaC1w`*kJUIk~>sm6Q&OYuS(ISpKT4S2ZQ3
zJNdPgSH7jA$*<?wr4(1~AI}ZLcAVkJvh4Zma_68Q3YODnuOIxrKYI$x;fHhIl|tt>
z{c!HPQs~^FU(bDu-)-(3MZh_frTTlhR`AQY?|Lr$<=l5Yf2@4&o2Iz*mH&KBreu15
zRI7c{v2&<QQxtyz=P%QfbFhc(ji74`zMW&bqPwx@Y5t=>OBok??s;4N=DaK_?E1k!
zp11N2h!9KquulX}z9!~SZJzv_!@fo8c&^TP!E)eF$4tx_B`yTv&DNGw1DC-~-}y9<
zM3;m0!AwvUL=#uq5Znkh1~-9C!ObAuV=IUuIJRa)0HUi(+7{dm(p=O%Aev;ny&%2B
z`#^Mi@p3^65JS1rzThFy4$K1wgNH!}5JP-YC-5lf45BH`*4!KiUEt0KM}lWTSMVI@
z4xR@+!3$sjco7T*uYl3uRS?}rY|Y4I@Fv_dKvd18N#I=&x?*cYmVi&-hOXFJ5$K4m
z6<G<QYec#Rd<L!qpM&ecS0Hr7){JZcU&Fl}d;{(T--6H$?;Qvo@ZN)mz)v93#@3RY
z1i!$IG_o}%m%uW(JK_PBgILeOs{kj1C`_eOz-r(fuqH@zca=e!d#nP|9Nt=B5m+0f
zx#)F3%x`CFPu_v`;KuxRnv>4v;$vR3^bfc(4_=D-?Yu@H=C|`2gP7OOYXV|kJ6oHg
z3~InlbAvU(dSG)<4Qv5ozB*g0f_dsZ%r|Fq!&`%`;MM}$ftY_T?ErQMyMnr4chCUT
z0}Vj~&<HdHdw|9uY>P<EKoigs#Qb%sHHh^H(!QWM*bnRl+Jn78vh`#E(%frH&>6G>
z-9SfB0*(f;evI~ll#T<1;CRpji~&U;){*giK`H15P6qwKL@)rv{A;#$h32-0z)f?x
z!$8c#W@}gGf?~Mmff8^b7y&K<vA#fx`Pght%QA2R+{?jOa0M6#t_CN9n4e8AH(Rq6
z57ON01aK=j3CsqOSJ+yvL@)>LBybm)4DJQzf&0PvAm(B7Qou9d0`MZ33SI{ngP3p4
zTL#_+)4+S+a<Bkg0X_m(f=|I!Am&~3u>M0@1g-%w|C+ZJ#Jp=>Cin)#{B!9?kk+Dn
z1~-DGU>5ilq%|o@Xq;>YtAks>8sJt?8O#Q0pYQFU0Nf91g9pKO;32R*m<M(QkAa;*
z%-ffC15bi9Hy!ier3T<>kmjhL0ZqX3U{CNO*c-eAT7j3rzTg$GKX?@!0A2$Jg4aPi
z@HRLEybBHk?}5(XeQ*R=0J?$?z%k%M&=Y(FdV!BYZ}15y0-u4jrtUcy1k#$7VDJ?f
z0v3a`uJJV(4!!|tj{RG3JcxH*8Uua+6Tpw)WbhL>1H^h9X%hGaOaW0ANEd^pAg$R$
znIK&amV=q#S8x+p0d50%m_xq{#JUIRK9JVJ90K{^F%V^k^fXulJP+0cuYf2^q&Gno
z@E%wTd<@nGpMxl4q%Xk+;A>D7d<!-LOF)!0(obL$uoP?x@~U%dWU7PeaMuDgz`CF&
z*bu~e6=`Fz6{rce23vq_z}BD^s0FqKwLxvLJ&3YP+6inAb_Y?0N%cUikB}OGI-n8Q
z1vCLswn=+}Sf45F1)_|TT7bHsHHflK+80DwC+!a!fdjxE;6M;%p40*C4bmD1TC3v>
zT7k6I0cD?bG&m5XwU2{9PtXn&fhYr|WV6Hxlz=Gvq~pNhU>xWIP69`OQ^AqoEN~Q<
z47!2~L6nu!rQm3A1vmy=3)0#jT3hK3ZUH^O9MBWo1A2i6KyUCUC<0G|KHwS97d#7&
z1!-+&AV_O7L%_>mD0mGF18;!gU;&7-S^5~906qgzMoV9TvEVx}4*UR41V4jP@Cz6Z
z(i%^c&C;*nOpu2*{cNxrNNZ(kfGDe_%3v~B3q+YMtpm;n>w_tv8n^&#3@!wlf+)kK
z>fmCqIk*ID38GAwwg%I{HsEql3rq*wf-696a3!b<t_2Ojb)XTL0rmhhK}!&2xzq;S
z4fX@~fCIq2;6QL6Xb0wkgF%$_(xKo1&=EWYI)izj3wRhD0UiNIf=9to;4#n*JOK*9
zlb{E98uS9sfFdv-^aIa=V?kQO69}FMgF$>#q#@uXumr_LfBalxss3T|-gC^2+fBL!
z{87+A`_%qC=!W?Ze0=_Cf4>jILJ~^zYqx8)7G+v9lDE}rIWo>LZpT5sPh8DS5>%WN
zhe87i4Jb6A(11b%3JoYUpwNIq0}2f&H1NMs189=|3&;O4(jD&Q7v2pM0&pM2_`is4
zpHO-HU#_8_$N#CXj}G)dQ}+@h-<<kA*!Yp`G8$v!Yz?yUe%XEo@;LwkTnFv5F~hVU
zt`lNz1vhX^<AP^@J?9xN@}Qw(cI~U5&Pyc0{&bG6t@zD3p%;v}iP5Kp^NsnH<BN?M
za4k1*&4znf80x>1i4F>)d(=l5ow@U(XqdF5@vv?`%8wU?hp>1$e)C7Fh2;G`jlRF0
zlbi8l*9Lz(PZ^f1K0-yfKaF80bLYa@xTd#1^PA84NkTXioILq>8TDz(o)LRylm<LP
z9*uF)fk!CS1xMm{1^v$SY%$&?tpjR+YG8Aa<XeI?CT0lISeOym0_*`|IS;e{(grkv
zyB%l>>VRfoR}kZ1%$|%Th%k6opfP9-LY8L>_5=rjy+8*LGQ1I>4Tv~0J5r-Sd$=(U
zCLId8fsWv4kjBouLC7-uQZ!cP1NRsZQ~9LspdaW7BGX7or+Bc;o>n+WnG9Kl*|!@9
z2E#ob#5racPXflk9SNeFhK;ddd`$`&W)~0VcvAesIbJ+C5ljH#$HpcnfwSOF1ZRVo
z%E_Ap(wN)=5Pr-KT{4LAGwFPA7l?CgjBydT5AHND7fc5af~&wo;2JOw%m9yoG)8w6
z#JDE2N0$YjfO{K=aW`oWcm~`J(wHK`W@Czn!3%KH7~Mti6o_#-DP-9gB4l|5a9;)=
zfLFnX;7#xmco%#O!jFw9;%_#l_zWzB{|m4P#CRbaQ+x~3nBsfz75E7(2FpMiQ>*}K
zOp&j|jVaau-@%P>KW3M%Hi&Dab-~Xd#PMFRabIQ=z90P5a1Q-$(njC_uqikYR0juv
z%|Sb`C1?){z`<Z!a0sXkQl4xNBHu|nfsSBj&<Uh*%Hd#l&;`^3DX$uUqd|=6@q}Or
z;)Qtd9wU>eDjhJM7HQqqt<}P#<<<9|$eQx!{d}E~(NvYzv>y7f<5-98sqRH54ZE&g
zjerz~LIVm7C^VqZfI<Tb4Jb75zgPp+5%)3Q=l}mx`~S&yHDHtL(ZZ)41KFH*p--p;
zo3Y88{jA-u<W4hl|8w>M{O|7hC*R+%hit!-eAG4RFvhP2en$A!Hb?zYncBZf*rm>E
zEVqjQ+j0=?-iE3W`Q5?VY-AH%1!t`wg?$Vq{$jBQZ2?1jCDeugCo}@trUbODn76;L
zzeLR1pz`=&yqz7b5HAV`^X7Oeh>rsoAF*FZM4-1YoOU`CMubvZzM*Pk?vkJXXYrx?
zQaEIz{abu!X$AZ!t`w&q&LOVywFlLZ1~Hq(PW=g-o%r9ypU$ZxoSR4+iy5U&w%HKf
zgZ3Yyu(()rC#c<RE!)3<=4a4B^Oh*CzF-Zcc?D~$D+z^IS0X{?L@z|RPoRW$Aj4nZ
zpGRMI^)LUi^vnBMXx|<A{tEJE!9$#6w(#XkEWV{(g5YG2hxsubBa?(80(2*Nn*U56
zEg<tdeNZ2dfX-<nEbMDZ`YC~aXztCo=OfE6x$viWfAg>O+(@T%jV%7Sf}ST|4f8R0
zec?YH?o6()gWZGnxgwe0?Q1~SM9Z$xgJE%cB`99B57$4sCJWb4v+7i(YyNC61bN&F
zWcLZI@%=s*{^UOLz8OE<gL@yj_Y@nFV*dlypMn3mei(XpHPB|P12zX6fUQ7HPyn_C
z+kovr{LSVd<8P?}+#NxB?>m8LE3^Fvxc3cVKpAwu#_*>;0Xp;{2QOydw?2q#*<5B5
z&=hVn&;mpjmZIIv?D(P`%=&TMz&`Nz0;#QyrY&n@PX>p<JqvUK=Yu1_y&(E#q(?w%
z8&ki4J4o^L1gTAqcUem11ohvL{~P?ccZYkYDE`n1^)s*|4006za4;DZ%dW?>W^MII
zkjlj<5c9xjpD8Kkcd`B*Z*T(KK_KGH=Dbb=6X2c!=72Ln%p+p`HwVEvaASTD4{2g^
zIv0Rn;9dk)=VJ~O*a%z#HUXD`ZNYSq=3uS{dx2{}3vfM1a~<(Kq*PXH0!xsN3rOVu
z6}w_pwHNk(#ST~tOT4Fiw@(Ge1N56MUB1Zb-nQlZsaLLUAELUqb0>@L`~3>n9>t51
zix*nJ|E%hMDX!&Gcc1(>1HN>r^QGF&i8t&$50u65wbHzv>_77N+X4GzP4{hZaH?aM
z8a;jdE!R1^zw1BOb?mmMN?zUcSG>(!5q+clEavSY4+{7*jpv>8Z1Sl`pRa26nO7#R
zycqHF`lY_zTJbv1oIm-xDGG;tCg&-296I25^MK*mZ)+Xs(OUb8VaB@ryy>mfF6fNy
zC4Gznp(Z{g0{;2TN1j1@)%+GOx>0t`b#!S-?(5kFY1bbY#Yd*~zbIOTK4T{5b-Zn6
zhqu)Z4pmyR^5d?)o32bc>+?!Gy4tgzqjLks-*1R_gvssP+|b+Qe*X%CS&>sc-s%^I
ze>PfJsG+p=ica93#!H>;FprnXg>F)7&+F+VG2eYLP50^Sop;Ix-9Olt-`J=}w$IbO
zt?@#SXi4#Fd_|P`vD!ORJ16Ilzqc2*o5`KG5|th5GuydaVAo02m+z>fDJ?k@H{oRH
z?HQe(Eqb{got+LSv<3X0@6R|*>eFw={+@*$Mi&&>?R?;2vqslB#e9U`!|fXa(D#?X
z<ZP7J791^UsgYT)NuNm;nrTTLCLD?E+q^^c<bBn9J{+_beY#9;k8jrafs=;%x*l)6
za*C_QoC9Vq-bP(aMNy0Mi=Ey!MWI@~HQiThXU(l^YI!c`(E0RJg?+DA6?nb^(o6Bx
zJ>t@At2Y<#SmeHYb}s1Tr?`&!P1`KHS?lxO5oH^%p{!<dBj$~)cVK-`QnRtwa(z?m
z7JP}D<GZfeqvbbCqw~v+9@oQq8Yb7KVar{oOlp3ZaM`*(Z{7TkUfp}vFE<LBTSupZ
zcH(V?eXsvK`(7WkC?9;hFmJLnK`YHyP-;8EY=P^@nUWH%fkW093@?`?w!hjL^V-{z
zT;Ki8cc>TY?yXZ`Q!=oh(Uj#XpRNwv?bazFRBpFR$mFhuCpU3^>fP+QWT*1YjIpnu
zTBgU1o%;50%-I*V+XgIajQP_{?nJ=uwO*R~y|-qk6%V>~@z|%)+2&nKmS`nM`Fy?M
zYGH-)l*tW^y^(9&@Y<p!r}JOzKDQ;OXBXFIwg2dKx7X};ttK4x#WzMto8p%@a^wpy
zovrU;JD=(4CqCOzy#K0ClD}oz{NOM1?_}qpa@3Q_Wu%9$?lLv~gv;bW>?J=re%N+L
z=a&6nD-UmG(q>lDmYZ0Q6G!1q5kznMG-FqUbjK<eYnS9;-nfvNz53nM+YvNDqv3IV
zl;gWtcnSOSqxWxY(p$$WL&wBj(A;3d&c{K5u$0qp=C?1I&}lB-4<;AkUHox$h05zj
zLS09N-7fy)|2uZOs%mF?QU}Ucx=!`CkKQou#M(2dHBxl%_pd)?$ADd_)%tauow-V?
zc^BW*Y$i9l;8xOUsavPr?R#9vtEUsEnl|xbM*ETRXLfE<+kNg?d+cq&<hBm0{xROZ
z<%F1wPB|^D=3RIkrS;bHQ1)f5FDVBXI&ASmd#5AacbR+cm8p|oKRfs0f{W;=bH{tD
zu4>vx-woY#Ve=DS^(Lp#R$+4e+j`znsm2d0uG>1@-(*GE%kV?PI`-RcT+{mbp7M~d
zp=cv8xe-$gryj~sJ6-#I!}Fz&D~_*Q=UcO_+n$wU=HI-w@Li}m#%h_|?8rvK5+%#y
z*9O+QD1Oi(<n^9_u6vYwj@lN|u5LerFK8%~FuB7|l6{{9$F6vK>!aJC1yiE$+gdH(
zcynd_sTONj&y8=5hE1DJl#bRr)=cp}s*#)$7L)vYdtr`D?rzTKH8~mE>kWB3()9Os
zu;ZCrrg``DhK1|vtiO5G`w6dfLS18x+>bjO)SB93T6pul=b-0JOzw>44AE+<g-N>F
z=Xd|!e)MG~*J}N$M>-+zQa6pO?os!IYRA*-v%^i7xGY;=yJ5ZNnlDjbtExRSeH}{g
zhG0!Wlfy?X-UL<L`n`ST|KIGM{oVG=@>x6JKv6~Jo#SD_ZQl#61Hz^ah(6ioY0Xn>
z>*`JoSa35&37rt)F7!OspI13BS$X9`RV(eQn;z=U5e)8kxn1Y8I+yA-Xk$FNm#4y>
z*?*cnv;TBEWmUCzs;^7=ui(paVIK`^uXcA24h$OHw$q$fOI2#V9`Gt~!KSpAh4m89
zx5(srU`mDYhVzzoySr8FSv|#YN43Qv%1e~mY<@m8`9q0zDf(WR+_T9KYsQ!NDl~sE
zaBEsbn(L4){7=^cqTRc$%9>}m%^saFcbHu2PMu?=*2xQ7XuSN8x9zD_j`5f30;jiY
zgZG!$dlB|>CFY#yQT+Zs`(uB%T``5du-jQB>K}8z*zK`>7<DGxA*#+56n(r^2K3x6
zgsB#ON?lU?srY)VaKw<_PaC{DHzHTl*gmw0rh3jgZ^iytiv6+vx&5(rVC+c1=R1$D
z;9qOKF?Y?$wVSoqzxJ?e^CdWOps(4K%YA~(Chb)0XSID+RI}9EB})G(`&nJVpof6}
z;=+f;KFYJ7XZ5(cpm^Xc-4j0hy0w}1AZN8_R>+;We3Tni-B+rQDTSxl2kOzl&aF>f
zTr^VL=H11|7%0lZppt-ZI;Z4whw-g$k9gc-OoBntokEF?*4{a(X-R|UFV<{lhk>0U
zCKrBP)o$`++v;M+LeW~Q2hz?q|J(L~`n&gc>W?<2fN!IGaKMV{#&rvt`R1ozE=xT3
zsQb9H(~`CZUfnpm#-6?^u#3Xv-eeBTI^d)_YSohFV{1*S7IXCF$p!Ds)Y~lZuq-d0
zzQ(ZX`yv&x@cz1=U%eN_Z%neZMRBw2h}DbohgYbKQ=W9C?Dom4-3#|gJo5kOu_O^=
zgG{a@#b>p8#N~m(Zq?o^-Do~O`kmXJe($e6eIBN>eRxh647epQxnXJN!j3MyK0$R*
z;?zLVjcZR^j(^p4`5^B+rN+tS!$VYIj|P2b0{&myUEavTD~*o59Q3K(P=_7WjeVl0
zO|&|8;r1rgvUbWgy(c`kt|i4@n@lby-Xy1YwW-<#<&AqjTxNOCb-2Uog3sdNJ~~mi
zH>vxgU0bU+-FHyEo_QwEH_kqF*YaR?tq)(<oVj#*%e-r5b{}icxl>vnd0BBNG@#Ic
zLIVm7C^VqZfI<Tb4Jb6A(11b%|G#UXIutPKZ=V0}<r5MiskG)_$^CzB?tep`wwi^N
zZnUwUmxr;J4@Smlj<vR$P)KvX#S-jfAjCXq4_{G`h%6n~#5pnMPyct<1JHft_XwAS
zMALocYXk<%)(Di5vT;nS3Hy=Yc(4uH^;@;MH3A{Qks?GA)6#uH#6mxRUq4}JxX8<2
z>>m<r?i~_=%@EMq<>u<YqzS{n9D?|5@T<);Q!B$<=%!c^AfLB>P6KmHJOU#y$Cu5?
zMw1<rp)n^}egin=bMxyWPT%~YvvGkUc8xk@+9Bei=+Ka0rakVO7V!UZetCqC5B6=)
zlFd=4`+T2!&dv$t6Xl!oRMZ}$&(<p>hznFKl#B}%v3(4>e66U^MO-ip&+Z@n_SgCC
zG{0O7|K*tD<1ZF^i-JSKVJ#hVw(F=l!M_k;vvlK*@;e|n7QP#lMB!uJGD~}3$WvUy
zMPU*C;UaJOx(b?W-vZ|x)Y#l;ChHFO4`~kcfW>#%-Gpoy&gtUsh~TJje~CmC408g(
z%p3u?5<uu53=;_v!DAsq@ic@yt!t3$Rp`MiakC6c&twG7Q@s3x{U!b$fn2m?*J|S&
z#p|1XD_u+R_LGMVd2&nOrg+l5>G_1fO}c}Dd1f&|EcEcfrXSzpNAvByF^8LMT1JDR
zoxabvcf++22q!EeMB*>Y4>}05G5jgMvebqmIDdqRtwKVAg+UR4693RZe_8%e{|B-N
z8qb}tCcwQ*@WV7wUSl2Z{*)GP+5P=xaw{P72ERbKdsLDOhnywF2mZ7cpz?39Z0$&D
z4V=VbiC-=JsLQAW^2XM>?A@&VYMYsP`upM;N<_Y*@E;twhSt#_3coo7%mx6xkMwS~
zMc5KQf698_-qCjO3z7IiGh967aTB1NphF)&id#4QIzl$|e;{t8s{mQ~byOA)8(BQi
z<;QD+c<6HFm%9hD`M98v2(cj8BS<6;_3#pPFf$W-g@oc=V#{u*^o7|Ck>pRjtFAxQ
zO8ToDM?Ymm3Wqj+q$>e_%^)lNuf#F#w{frXGyXY_17&%QElxtbEb)`)wa$p+o4<UX
z&?H`?knmnrjzd-QS#MdqwxZvfj^X%`8i(R%M9;V0Z{C4#QTa74-}670=jmOgpecU`
z`iWUNR9EH>hnwE<>JZ4n55qvbe(Zi+c}4FEl`;PK$=_Rfd<{u?I1KTltf`A1#W(36
z#kb9`@x^7bqiXS`c*x^$M-~U%mOWOAza1Q*4S%CE4{vXwmq&Q`I4+;d)GfdHZ{twE
z1->JCoGwUbRIWy#Ads)EV{TcXq-R>sMc;!6D2?K2D|@zCw9p9$RUjzJ7#`ydL_D|t
zSv+Os^f+1ARIXKy@6XRzUe93h#RtqA;gjFDI8(td)cYyk<fqU4@CoA5Cc7V9`#mjG
zX#AKSOU#X;qYHlY>^tJu2kCKd@Eg5*`lIUS<q?cvP{U$t7OPTDv-CpW@_G}+iSnZs
z?&TlsEuu;u>3En-$9H6LqWnnLQhua3IcWSQPOJhX6r-wvFDHG~S$&Uc36xa!epl8v
zyky6Zd6YeWoRRB`;wCq2L~%2d#Vr%*pd$+Tpc&{3TG8|WUEI9=BmKQ;kCBF|y0S8#
zuKgaLU+bAv52N!s2s1b$h%2VxCV%<6PL;DDe{2~R63%N6|L8xscRR=<TKMf6p(v15
z&GCUH4O6<jWpWWzy_1Eh3O`KM{-y5GrBaxc?)OuuT)Z4Ahbs&gMN2q6PL}z5$!<t-
z=m<ZY=8>Pjj}MEN(|12qfw(%PpZr>u=luMAB*H+Ej|94`qo)1qxo}kSDOgqp79jsf
zQLmR&Lpi2Nd4`LpI<EUUt@N&skonWQPT`xwP5D7g+Xb<zuw2_*_|vd%LLK3wO3ZVt
z6#k7b+;x@fag=wcT&8OraLpWCvru*o)k(`_*Kqgx_Vn2MAipjK*PX+4cFno8P@HvT
zI`EJDUY?UYr9BJs3nBli#drBY$diKnW#yS%HX7+PMV(F9>bvZ;O0p!k72!!B*9dY_
znH)XK7|4-6BO-+CxltbF$>J43IT7z7PP1oh_+1t!I6uqpe&Hhc(e-veT+ihtio*@W
zArx_dy?&lmoA1vw^m`bdA>rX6SR={w?S=)XkMUE&!*`a+liu8A;rpZTr*LOMrU1Y5
zxGq5^M`^1LIqsVvj_|}edXDmENnr;fE=S>?q{YRBuBrPi?%c<T!Y_iXA7qz7c8N@u
z;?e)7cr=ELH-5p8J5ovRCGrP-hs02tJPtpT?nBRg4X(Gu^{H*YKTCo9KJb@cC;#RO
z5H20<@T20X4Sv=rcXWSO_M=hA48%dEs%1XaQ{-hn-CO<*&6VAE6~bzQUkZNukiGD`
z`bLn)Sdp+&LqT@`8}w5Da{OAJvgZOh(xE&qq<?vv_~&m=W<xH}EP&#+96tlZO<JFH
zs`O*~<>$BwLqnp_NDJ{1N}@tIJr(?u@uWP*Lcx8heCUX_JNf-snsfCSf$SVQ5m;TY
za+>H}(w3d4BDC^%R{s2VH^xnHOyF~ArTt0z((`ZpyR>rcO;owq^Dlzzug9<Yr!>gF
zXYwX1Y7kVdVeh;An<hU;jW&8d0#pzv-ClT4seSDVH?^<7%L$PqVSXVTEn<X4*L3`L
z4Oc(XhWipSb+|9p{J1hlt|R%ko$^PE?{cUSa^*)B@<DankLq`kOds60p^NMuTzUOH
zHgp~3ae5c&+8kVqJzsdMntXp3?QkuMUzEXmOil$dTk+csx$`nPicf!;TtuZhoYS{!
zxjG!l>B`~)xd_q$-CGyoW#P9OZiA-Z@7?#?_4?n+fuGBRP|EN)j^Rgt?!wO)`N6%>
zU*`wfTjtl}zm^~9xmVUKrFDcXt+HxAOM~2AMct;{ovA*CPZWzg%`Zy&U7bu8@Hk-)
zLm{>;rLyeTc#}^@*3Tf%zpQUa*5y(;|FVmJiZAI^-sezVoeMn`&zN*N10<bpZT1gz
zD)byzsVHG}HHv3$6?IJSg8ZGM@{ROI?^)%tg~|tco(iNbO1T?CA9dACNO#kfpyNts
zgx($!5AL0%{7GSP?*La?Y2i9kT&FvquB&uL%!)&n25a<D_Jqt&g{Z7x`8m;MW<p`0
zzL{A>FgifS$_p^MPj7^gijA;-j2}uke=k<&r}sdW@&t6>0Q!E+bj`(G{{H_ie_0@0
zc{xcsqj!eN4{=CDxR;14kLexe%BApdG&p2h`~Gc}=Sf`+QaIWN_|dcQ!p|1rzxiD|
z@mrqs3JJ%3=vn_hQ*vz<d7d=x_WeDP=Six+%Ad77jdV`lQB2SMcX^i5OYKA|pXBct
z=}`qb?1Homg?|N$J6G014d40`NbU;cIzr9}avH3>;PTxYSvy)@-pb1yqWn8#*#Z~g
zxQn_Sy(8FrhP@+6zpICcE4Kw2s($`2z7zD0$n`{ZF4BvG?Ab=3e;A(@v^lu6s=%M#
zfBMdn9DOfX8720_7>IZ*#hv`+??tdEN*E#L?DCR7<s*{+)|8RS%ggV;pTd!UV}jt1
zYgpeVh0{?M4#~^?sr^S~BYhjcg)gRF)ezPa6H;PuKav|Mllz`NVU#~wIM`Vlc6?aX
znSDbHDevN$=-}OXsmgsrC|}9T3vX=7O3hE|hL*oClm|{~!cGC~D7?YtZPdPBXCjX`
zs~vG~ll(&ZwyVp|GnJ!@Ga{6_y5(;j*T3HQCmBTd2N`-N<aLIh&r#ehW!F~@TOJ3x
zmg)-hj4Gc;GFaV1Rdx;|AK17W5tK(%7DaiUCLNIO%%MBH>b$11_l52+|Mve*ck=6d
z$od!>x1u{kk9ZHL>>$=hfYMsBZw6<7DNuspL6W2L!h!zy^<Xxa>Z8o0Q|_!^l=5^9
zwPSVI^U<~&Y|7l@zqw7AyZbk{F>^nzEtl`Xz9$r~lO4X-sVRR#egD*07`=liHkc71
zGUG&L5LCy;z~toxd#)sdz&Ss8Nk;G7@5j98nyn~zT0&>IMkKRUg-&y>3@^tydSAHl
ztnUpQx{mBJQ5lH$!9#*u1xvz10^z3gQTf;kVOAaiqid*)yVnE$7`qbt`}ljYSA+W|
zbd&Y@2g05O9c1s9bcg*vdDRS2*H>ZB6#I~Sg^m-7*|TIiVbYcV6R>AV_oM4|pbuf+
z?=K=rRxbN1pL6sdkCb!eF+HPhbgd)zQKNK06->V}KPFCjS)KAB;*BKp5?MSsJy3cn
z<NeNd6<uS9YfN$eNu_K4k-aOr#t+x@#5Jv09_Q{;^e6YB_vIaA{qSCJW4_#2@Mm<k
z4}?GVykmz8UK#qHxPraG(O^Fi-(u+^5K56g2GL2uY%GU@*q4+S26}<9;8ZXUOb4a-
zcM6OLFN0G-?AOSf24cTOW^W1mAu>Bl*e8(LSsDP&#d(Tr5*Pr^2Pc6k;3^P(HB#&o
z$LucM2A9G85=;Zh4%2dw>@ckaX>ZI`pgp(_91doJf#7<O_Lj^7r+{0)xnK^s0^9*o
z9daK?dpqt2X)nhEAnnz75G)4|ffXS7H>4`nIs4nqz!Pw5fcc;)cpfC%W>>%j@CHbG
z2i^q_fd$|>@F7Th0zLt0&%Z*j7%T>9JoGh4d-%NtX)iuJTd6)+0(ygAz-eG9xB@H#
zcYx^Ik)8r!TU&Y+gl%o<9Z&_l2h!fT??BkrmVN^3gC^+cK%G$93xr*5sVxY5+EQ0g
z9Sj3$Z`^1Q_Ozumw*WTBm>n+@<P~lllgG2f-%0r1A^NQE9AI|FWMcx-MsOoPGduBk
zf4*JMjWu#(kUw9q4>`JC4{Qh;f}KGWE$sRc_?sIe<ne6qH|2LK3+(Wt1MMGneRGiV
zeG5<vYz1}#@rtqV;K$<C7VHiGb|Ae^ls;~Jj~n-+@GGaUBTiHN5EiqmkGM$%aCZgi
zdQ1GcvA6H~f!f))62R=})Ag2+C;eD~#-KGw<HUVr;ke^(Zmf(OLnA%Wbx!!vF&uJ;
z8nabS;Xp4^q@A-_4!XfT02~e4gJZxUpgTAe^Z+Toy7+NpTwEOKKFIbwZT#r)h8!M0
zD<??SM|Pbh{^rJ|xU!M1tDMeu$S?F<U~iq-x$6MZbL<F`j$wcOo4&YlBW^tD=Wt+$
zo#|U2#4}=hEJN39k7X)fjb!2U$KTv|4VM=w9Evyc9XnRb(y<1t2cNYd@&qeC+JhNz
z<Jq!uM6MTZtmXH5p}j9DeJerI3(7E-9@@v28wcUWM<^atIrb){;-I}G={a2nkr#Pa
zLAvivkitRPCmjXe0lmQcAj)E10XPwS3?_n4!6jf3h_vyZgS){OAj&2l%1&m_|26m&
z?zbSy4&Hl^+Jhxv7w`ip1V4h<*O^xeP6Nw9?3>K{3LXcMDWuqUm!|}pSHpK36oGt@
z%JUjv99R=v0b-wH=?+i@L>zgwK(en_7sNSUeNYut16zX)K|K&<JhQ9U6dVP&I_L*#
zf>B^|a2(hQTnY-n{h$_@54Ho(fgQlhU?=bni2akLPe5Ie_T0t2q_y#4WB+8fXRaZr
z3%3zS<+?FQd(&b+WoZ~_295{KLE1~!5~Mw2t-uRlU$6;Yfc~Hnh<%mWUZ#UUFSzZ%
zP;fAq0S*E8fkVN3&=GtOVt-|63uN4pU_a0m90`sFQ@}A`Cg=g0paAd!hl9vp(nwGQ
zP5=YIWH1n13*wt7y#ykEN~!XMeU_yyK{03!N<bGd5{v+$W9do|`!7q^fiYkKI1zjf
zO2I}bkP^Tl;8f5LoCd~&)4?g=OmGc22iyxLgO9*@U=g?gY=ZH_MPPd{73>Hu0egUW
z#!@>l4IBwB2VKDxAdNe&1m*85*Jsc5<<onI$IR2lkB;StGStTGH?{#+z)jaV;K%j3
zvpNO)o<U8#zWC9R2s!$WOaTSpR8SwB1`Y<Ng9+daFa?|mQn-HjasB12F2ce^bg5is
z#~hrdaOZ+l4kUv*Ak~ZTtz-3~{vg$hyud|ZESL(;0`cxkktW_!knZP>ca!V0=K8WJ
z{hi?N1b;drQBKnRqQI8mIIuSu1KNUdper~L^aZ6Ll{b^Y3@{PA0ZsvHAxxAJQWFqe
zWKv&nCKwLR0;!%j2h0KIg8RW_5c`v}J=^bqDR9347lGIZoVNu01TF>nC?`<%Nc)1z
z!C~ME&<k7%VjpF;H+vSi7Vc~?13Ut*2T{hdJ=q_ES#YE5V|%bu`9gcJ_W-wnWVaJ>
zl;Yjv?EqcCU7#Dd4;%~Tf;1+8G%!79LI+%5FxN*+dTt26W%$uy4>{8FU=Vc>o&(q&
z917BN#q*HTH)%L%362EmIlF>XhZzIX_X1_IR04W{F(B&VQsfz)H;8A>6M<=<AD9jL
zgFC<=a2FU1Qob00AJ+%Wjnz|pRp2MDFKtEnj$((m9VCC)N|n|DcY^etq&=EdLE594
z>KXe$N+0dXOyM8GkL$-p-o*2x@acRGesml`JjmT0@*P053E2KY`k)8gJwQq)?G;Y>
z%><<MnSqopd~2i^z+PYlXaQ>AK2{*@*<uZ%j=-}4`+&A!f6y5m1r7(HJGMtS@-o{S
zoW5^k;7|R~LXf>b2%GDd<oYWq9Vni@)wj%%4$@CAumRW`r1#4bv<9s}Di5r|F(Be1
zbq8%gFVGgG`v`DPu1}Ba>!bU$fq!H8({U899_i~CNdCt`1Mno+4?GPzf@eT)@GMAr
zI|t4Np)2<NzXX1U`wGZM*w?^j;B~MScnhTW_b!OI^X`MrU;*d`J_7O1vi8bq@G0E8
z!6J~_d(Xg*c&}c7cm}+eAhkJ*!C>$W7!SS$r-1LlE#L?65cm;13?hzF?7PkT1EfCB
zQjqk7^rE0){VlBThw9-?;g^da9UY-hdLF35u>9E#r1QF<1Bg7q_K`9K{o$s1B6P~@
z0YYayq+JSK@X*$kqK(8e1GPYUu9TlFKx2@eE9s{%h<A@Y$1Pw#xc>l=*QCgMya6Eg
zVQ26EYH%3bsKfCbK}t_Feq28X*Z<*wk3n7d1>#3XS0tCx(+#W->VlLH@a$QA-4LXF
z)B}tFO~B0{>cGtYGRhPwbdLUH*e^!BEWnzeC0GJ~g&pE^3-b!+7B1db#xL9^I5WLy
z+Ju;u_1~_kj&Fws-b?-)^PX9H{;rK3k7=tsYw`NUu$_rl&Q`Csv!c}MT-w6UctE$9
z+?>sy_Gu)3m|Udm<Tap=VVU!Wt3jzxmWypWn7_>WtT_tL74Niw@7bc-u*^)oc%yko
z*N;&*>o)$$n9}_dX55&vC3ad^nLRS8Et6~A%H;g`jm6gc-ti9<*I9PYRI3lqyYK!>
zulfxSGIFxU3-ZaD!uxAGzyB^f#0vYu3j4xcQ0WM5P5Crl<*P-l#qLT&dR*Lg%X-wL
zgl9KQ?-@qDsQEU&<C2<*DA<=XxdPtd!s1TzHD0&&vpMc@?#qz)#<z;Dt~k&|Cq2;P
zS)U8|wlTR`d5vE#c6~8p^pFOFeLCq+S)J$;`Z+yu+OqEPi$C+vEkpl|fbRRMW9E8M
z$(Yh+hMn&2UOlO2!M<4<nd7%RCuHdLj?bQt@VYX&QpvcaS}kS;55AFeKBxZ0!J95e
z^lQ>X*=Bj#y-zK?750S(yc%A-#d^fHg!7sDm-qD0_01l++9mtq64Wu;ke&;BtO+ZN
z`~3CrxjXaP<`<93`84WlBU}INTLzYnd6E!hg}zB9H~4YWZI=eyoIiHi?aB8320I5C
zmM<|~5aV;*xz@+ayT62^jjl!EJuiHw_HbmiVugL-f0cdVW)n%zed6<;#J9XC-c}U9
zEcNW+1X0=t?X-Q4ak*an@DZm?y8Qiih!ysQS8Z3%3GJ}8jZ4lvRcqbXC)<>+>WR93
zdwL$claf90E48~lesQ=}z_S4V>l;FSx+c_pUApo7^Teh93j4xUwe!1=#V<YgTJdb3
zbFZb*Z=3Esx-uei?cogmnh76^(rfrG8bzC)7BRVZ1<8|J^#0miePSVh#Rt#)r%tC6
zp3XAtk-9bb_{60vP(f{thM$1HtxjIsFtu7U>W9Y8-xtK2t~O=DP2*)6QAv;5-Y^~)
zitk5N?f14orB+adeHkXP`~K(JD^}PcR@fodL<2dtGv(*Gl7~*y-BVUi8|)uZuDyML
ziS1BJQAuojpZktypWEzyj&=%@t7E%GH0yam{?(6;b9}OzOze8V%Tzh~Ov?H!byJa_
zQx3)unA~WO3p>Sw-%RSFTeCl}=t6UghL_T`PiF5|-v08@E}i+hs5ha^7w}s?JKOqw
z_TzKwV?@H(Eca&q7mH$B%-=rrZIH##mreYO(5J!Vs@E{eUgF+<u<+@k)-l=U2el70
z+gQ9|#@RNHhm4N>Ivd||g?-^py7tSvm%K<@DJqX&U&}4AwI%gI#h_6y;NSSPoOkSI
z_f<xI3j4wi&n8br-w!%Q1^lJK`zP+&-o5boSo6Y=nD(zyd=gq{dz6NSjz9b`B~aN7
zeZqPq_a$VdMOkD<W=@cE8~&!+yREmpy3FsjJ5}8K-RKnE&&C)}MxGWZ><c@dxiDHX
zbC~U17Y+S=`2)~@!1QOkXSmU)x03Q8Q@yd_>9+NERolA1?#4kpjq;PV9Q5)gpwCI4
z^cN#(c;BJ>&gZ6e7hXU0xyGthYVJ!H>@Lrd)Uf<C{pQhg=>KMNH(y-vdZXRzqSi};
zq^2GhH#c(}xoMwLdcAnzo@!4&HhYXc(wSVT+2+^!gGTet)ed;jtlFI;dG|zr)K)#c
zA;)0sqRX2~=A%!K$(dBl+;br2kF;?fUAFZrt1ymvzNVXt&xOPZ(um9!5vg~O4kmZx
z!>~8+B6*t@YhKyCJx#0nPS=5DZyFj^f73g<iS3&=s%Yn-(@elOJ8iC)uC%G~+PuN9
zX20K3cXPy?!6jws=OeE*>!w-%4-BS^W^z;WylNkeJ^E@~^t+=9`@$#C>39d7jRJmA
z-xJ}1*5aT~eQmaT4ZWlEaA|&Vtjlx3+^CP5YYt~8W8A}t<We6Q3%<OZd+&yd!oIM=
zzHo7y<hqTO54o;z%rbv!R5&B)p?R&VQ6oN-qW|R%%4h+<w9Z+(<68vh?)17-ZU5ct
z&)n{fx##9K@O6eDR7WSmc|4}!p>tcnZ+CH7`r>)XMul$`_Jz-=%)5v&1hl0D{Nwc-
z#ZCO2nDD8a!&gbt5ErpSSFQBuwu3Xx_O+k(u?T|#>zG`Jq`^tGOeD)1uDMufwdJa}
z#tfHL{j~G$UJkshtEGJ(ZMXYOu3~BNoF}_B#6SPEq}9gy^Y`mUDiy`{lxA3Hrw(4W
zpoItKy0QM}zusS>i5bOjLDw^_rhV*SKjis_ef>?<g6hT12y?U>8k;ufrjBj(iEA;I
z!sPT_HqH28KBCqE`_au_H7K7sz^0`|hrDvh#PUZ48JSHcVc>$v9UnaVOGu50_j0RC
z_D8xEn>~nC*dZo8hs<7o+i&HNesKwPYSg;a{H@L2*mfob_Oq2+4V-E%)LVx+G8hyR
z@IxPTdwtAu;`RgM+T6Hv;m(JVZ!bMh39#C_wPWAnn4aM%@BdwPh+m_xP{6nExo&Z8
ztsM)rr&rW2jXE6GSlL_eT#Vy_nYlG`gkd_vFjtbL<3HD4vBC~91{f8GLIVm7{C}+h
z45j~<?f+r_`Czx`Ac<RuXMj(*$j#rtq=%aitYTs93HFs|768q7=4wjr|8w^L<o5jJ
zw)f;~lW5)y9q5{1bBsrT#%h>r(V4Ad5yC!|NJyK)v#4|HSx7g(IoMo6TFap?TlbVC
z3mczhUJd*j;YVSw;KKf{5%~Z4x?OILqI``A#gB^{7iV`whUS{s;YUY(RJCe?nAgPS
zrr~x{OSl_?{XoQl&24H7I>U{)Nh!=`;5!iAF0%M>bHCgXJ|BMC_|c&ZIZ6xe$>xyN
z0%=Z)CEDu$u09(JJ*s=mGD_=OG2PxNr1!Z?UsJs9uSpnGas1?oR%hoHzv&jYxeexH
zF}X!8HI!{l&-7?CC`UQ+O!xShU;0?8+Geh5UshH7Y%Gl^9e+J1rK){964v(rtR-o`
zs>X-=`eR;diTkdYZ=gFo{or_a@s5mFf~~upxBUHmJDXWL0#u*9ad4d;WE7Md<lAEY
z(urH$1q~m2=?(dG@PfL|6wC)mXKllsTHEaQXIifm`%is8EA53t<P*&|>Ru|=D?1$6
zpIluzxaxg7Rh?V&pT5UbRr_KlFg**Fk1OA|y;hi{{>W{&x&}^p7*jv(Lg(UTxoyND
z`?cF|!n==&W&*z7rOC5-n+-a4-zJ*YAl~QQjyvvW$G5*N(so#zW8b$J1%(Zhi?I-;
zr*3~MnV~o6npMpay_CG?8x&YA^=aFAi1$C&C-R7e*YEuzorY?U)@JEv&)uw<V83<h
zo!DcZ7l%E|-?+5X#LaIo7m)QOtgTo7!}(`HUIVR)mn@PjYaAx}EDF5;YV?PmhwWzE
zCaVTcZ0vhSJ5!IbV=P=Qe{meInR+;MU(vF8;^jxQZ@klPP%?3MQ;e;!@UHeK?KLv*
zAN65Wbqsa#P}1KO*CWO{wX;rpJ-M0Ra?$>z$==O8mFM@G{dVBP4OdL+p#QO|W1jO_
zI%-@r-99VT@ASK#2Fv%UrQhki^1$egqB>_DST^v;)A2coxw!1UDGjO(5hdkLI&R<2
z**CqJHSep`C&VNp=0>NH={cdx@!_g!oBr?Ki?phHDOGjP(yI1}RCRCDzq{|Gs(YYT
zwNK>l-gC(w^AQC6XDwrk?X^x%o};I_=9p0bLGtXAqJH!HOb>XuWT#{CP`pP~?IUQ{
zoWiTCVr!8*s%_?!ZZ7`IyX)R<e70B4np*tFW$R6KTvEECkE*JB?RctFc$1}*8{c{t
zA1Q1loI2rhR#des>XT-tuaeYgb!=Vq(!~8(zscl^Lk!f<Tua-!s!r)E_czM*f|q97
z)VDeCVBFq}q^B*7!Z071$;~X+jLz5HdD(p0qmP;ov%LMz6}XFs70<3UcCE3iJ=tQ=
z*P#2(IDUP@-mk7^V@AAR9U5+VbLXwuYm}pNlU+{FT5(<_5A~b?CKnsFt6=D<W8MCI
zj_Kb$C$uKwDBz#ZeB>FlSIuwnq8nw`Tt}Cd<i4I=kaqoXQG8@t|BIqkm<P<{ypFfc
z?C`eQ!J$e^R({;ochi+gXMJ92M^}5+b98RN`1`2nl`*-{O=|6VJ)I=xyDz5cKApYu
zPT8RQ2ix)+8}-QcdAhgte5`k6<&Y@<g8x@TBaMugHB<Aqj0)jTd%H!w&Vr>0VM(1+
z&9^Sbx}a7RKO5z>1xHI-YGl@H(r1!|W?E8*2}dIPHt!HUd0+LO4+o(y@F<hp<C`^p
z;H06xuE$%ioZ_l6=YW}uw^0{UQPkr6VyCxFG1<I&YYI<mXU(l^YI!c`(E0S!G9&XL
zP15V$KUGJlxg@M}_X>v{7XQ9Eh%Ri*eg9hJi$l6uR_kSGx2MmUn={@86|I@rvw<+n
z-(JuzjK=!Y1(c2v^G4P?us$fM+1P8jzA1JKzQoP(UDxc<@|&g6`Q=8B>s5VDfGO&z
z0{)ZF)!ubn^LWdxZ7M1D&&&szJ-IOKMeB^NbKP$#w>|diM%CvIOfskN{(7&maCYB&
z4<~kLxTmm7#th5;hGIwl#j&^BoZMh`H!I`zX)Pa{PMDA0j=~!^R;#^qQIhiX$$K=M
zy2j5cv`V_9R!1#;{^5)x(>jlSg7q<ME|L1_Vbz<uBu~oiv8?tS=aG$XyG2APyUrik
z%;I>i%}8hWs?Ry9YTt2H=PHiWqI4wYH+mJ?abcb7Ut*HK%v_k@YFn~9*CgOocb$Nx
z`3Ee~XPwfP<W2<aUhAc)-+OCzTJfM;7ms}!oo(K=WQkUCl+V{2t`=5kYcaj(-3hD6
zNQ>wlW3;jRy2AmBJSPr46*u7S#Z$aG4tv*SqrtR-$=TZVx3L~xpy@p)>e1y7QK#1K
z=Q-w$Z@Mr1vex9K1H~a&Kg#4(_Al$?_N?O8X?5p@|Gl|q|E{@HRo!#Fs&icaU2|9L
zuwFpGACTQKHK+4=$0wglBc9&Y9BolLKHYS%!+nFH1qt>8XIi5T+>PV{_C`M6_tG=&
z*6p<$e?Nz0CzD(D>Dhx*JKSQ7T1~AOmHNnYXT|NIEevXHTvjsHbL*{h2(LApQ?a-_
z{)?@Z!v}w_Bm1^&Sn#Fiq!_Ih*2YgCEzTUnd!CMQpQ_INQDOIeGFJRLYukqHBRyL!
z%50Ia>wee=m(53KZQ5e`wP2|@=@{1kFu4{v7sj`lbJTpCQI1}=hizGdUY)M=yg2V|
zr;#;UdLEtag7uRuevhL)B6S80UFElI#^P}^G~@gXoW%v^iE&Ot!?!Ltb`s@ARp*AF
z8$od>G@#IcLIVm7C^VqZfI<Tb4Jb6A(11b%3Jv@ZYXIG$ursElMz{4gbMw&Ea}!2|
zgpYMIaud4^z#doOK_YK|n4olv^pb>x1d81P{XM;cB;Cl4YNRMMJS0G<r)O$n)I-n6
zK#yhuc)LYo8bDwmHW8_`2Oy0t(|9#^)aSM24U4G8v-kH34-tp>NCX{+brRUaK4^%*
zN-P!yVXM1vCVGw6OO59h<^5~q#Nl4w;)K2Z@Hck%3ztNMx_L(U2O<`jn83wVI93!M
zEDD6xY*Do6_W^N9lP9sSC{oYR4K`EVq7C#}a)JW8(Y3he@2{6%`C~*VihiO%ScT>0
zMsP~;5C@UX2vw$Yvd2Nk1`doh(RY7{%^lzgv6BZB$=N=A!1>wfL6&Txmdo7wGPgz-
zW_!a9Lsaa12bmkghs^CPb7Q!UxrfW#7)E36Q8G7%lbPFF<~D&_J}<!m@s-8xTbyaW
z0onbb1Iv!2M06QQl|WsPP9e@x$^(vI4bU0HoC0POuMUWA24=fv1Xv&Lks!LbnQc7G
zVPLi}G2}<{H>BvkXEyR$f@9!Dw<gaWM0Xm`1MC2Lg6NXqd4W2hH;C?zA8g{0-hAOt
z`tbwN#lmcA_5vkvqidQM0ix@Vhesf_0i(bHU^F-g90%Him;%jg^<hZ{v-J`KB8|)z
zC(_1jaUxC3HkB(l1?Pp}R1k4wwy6*oW|PVvoC*K2;4Bc?g*O{Smm#yw83xXUTMQ<F
zh$FK_g}5;rQ-}kzF@@z4%qC|%m<G8?;Bqh#Ob2mqW<wA6Vm9<}4`z!KVbimfV(5Uk
z5nKRn0vCc?z*KN6xCGn{E(Q01xCd`9h_IQh&Xr&;+-txi;9Bq~xDGr9W`HNa60kph
zUngQ7xzgDCW9ISSEGmy))}nQbf!cLpm!=u{+iJBO8D|)`;~?KBuI47m7hD5HsVYUR
zIcj`J+w)Za<WDhmasx*rAjP53fI<Tb4Jb6A(11b%3JoYUpwNIq1HaWkb@={k+W*)Z
zQPKYYx&2Q{`EC1uo9yWjsr?_ywY{nR&-R$4_I{GAJuYwmZ<M*I9ZTm=%iQwz{|%Yj
zNOqpzmFpjnxBu(N+{Uu=O=WI*`@f~kZG!Xi_J4mg=4El?$>VH`^JHI~jz4SvJD{CM
zd2JYoDKe}dpf>0PH=1~?KcF5s9BwrbZDzLaU<B9%ZnT}H>fk7_1&B7ZQ~;v6C)Eb2
zAD}&mHZ`-&?hYa@tUrL-{nQ_z3sQdo>Bk$Sbc?{AU?|uNMBAFR`@_LLaHEaQ)>BY_
z0JZzk)@JQ~>JJzKcN91jj0PRSaiB9u{Q*b|4{dR_?t=OQ5O*Hh;8HhmGUyJXEzWGh
zQhxyYAXq;@05~1)KyU^a3{rmp;>h{~5I5EzfH<-K0K|pannoO$t!dng?a2`fF2Qxw
z{zn^~wf~oaxF>H7h<h-b`qchMo1EFAMVnlj40k3tAEbVOMIiM9APlxA2et2az`Ytg
z03s~52M5C7<-v_>d51w<%i8_uJ7BhNH-q``M;`*SeOm(d$FGl++VT68-Xw)~f0xm9
zgR%I;urG+DqTLVWC=P`N6dF)yK%oJJ1{4}lXh5L>g$Djc4OB;1|BCj1L|~xUFP!TD
zAR7RD+^6QZcvpS=|JMJd@qd|8SO)-fA)f<qMTt{PYngtC)CZu;wZDZP+;v#nUqj83
z^Rpi^%m(urXuW?8wSk=9FdL^)Hp9>;mABPXab6Y%?V-mG1WRp5cIcojMt|sm^n4H=
z8=FVFn6=SOz}oOP1*vUr1~vfEUS|7uSb+`Uwgwx6eZXd5Ur+<I0X4xvU<=R=Yz5kb
z^0wbJDYgB&s1(1yn4cOyA(6jfRKPGapcQRDC`xfCG@#IcLIVm7C^VqZfI<Tb4Jb6A
z(11b%f1?I|YX66bX$n70c_)K@LH@zq)Ok0|YZtpk(Cl`a)9w)(N`HEV1V@U%pG^RI
z8R&;gLV`SH!~bYE{?FO~)Z}Ta35AHE5Gw*CB4Ln6u!pZGNED0#Q@MS>hTmj@JjIf5
z|6pJ2@d!T`|6uQsC^5#<wbg9NiXoOcgkS)cuCuZp@E0<6YVqpWBTzQCe}rsI{2|)+
zDtKo1Ku2@T*=Fr^B`%8c+nbreEmNE@LgItQH`xlLcJprzW`nRkuMTYs%?rgt#5gtL
zTt}@gh%sj#f?{rJ?+?K}Lm@!tshxgP8*Yg=_U5dk_PL^>0%O`d*mCp_6nc)6h{Vhv
z-W3A)2Z}trnK%A!%Hyj!Aq`GQml538yK#GcQn)3ua4;pC^*>M_guH(P`<k-@(O`N&
z(s)DRaNzVHPc=(#7f$r&|NqPBy@GhPZqKDx-Y;T_G;q&=$D?N>fD+r`j@WmU9Zk_c
zL3%}BhO|D2J`6U;pgGtLZuDWW{cr^!`b2nbKnG9@90lTbQctiW7yxzxk@eV`h&Yh?
zTWAcP`derW-T<5f8iI>K>VLs_JL`8j1X6zs=E?J*GU*u*^Ay;AsJ+1(a9e>7K<a<_
z2vWaGIcN(iAx-^2+D~>Ms18y;4E93hVcvpt4Cn}kfllCf5Zy1*7;q%G9YmVgKG1F;
z<>ArbJA_Zqk$Z+LZcL9<p2(je`ihty)j;Ye!cR)qGy+S&&rqnoI@!|L<hxz7XY#p&
za~rJNniuP2G40uh@kcYx);lt2@!s=KUd_e)4JP;3Hl>o7TvUJO#XYm@rKFypy=2+u
zu8qS>J5Di{UTd6KbnC>ZE&<;E0^3v8l#V3}GOVwgrue9RRMI!8efsm0_c6zMs~e2o
zlN~+atWCuBzu!jHfBHVC%b8wo4lMBQc~?)M*}c4(VSH2TMHOR<Th3`!v_IC++Pk{n
zd8`w`OD5odR&~D=*K(=5PyU+$U%J%!Qtjr%8}^<D%3}ChX<kqEAHkl)Ozy93l~vWI
znPMMQ#XhKteNg}0rr8|<y_anow%m2fq~?bSm#ypb*3Iwe)xBr^a-*QRb#yvtC*Gcs
zf%;J!l8Z|=Gq5b4Z!j`r`T1j+;*&i}mnNn;xBC>^|Hkr5t4h7_O=EI@ZTqaMw#wGB
z@UlK1aSoQ4JyYz1I_aouGgs7CKcF%q;D5X@Z?ZH&E6rC>YCFPgf$PYbk`k?fL)I7!
zFP9{?zuK9{(`id`efKxtp<bxFw@!gg$-sU_Q<kfIx;k*TTc?E3D3yj~6;jNrWO7%-
zlbbj{^=|fDvQznH#@N?SEz{%1PJMeg=Ip;}AJlWWw}5}}VT}{-5}RcCM-<++IBnft
zyX*90kFWOND-}yt>|Eu$^53@)YE^AR-$9*Qz>n}Q{y4fq<#i*Wu4CiEB`eNMn=x)Z
zFV-odt@WwcF)OU9Zey;hHu}b*VvBvDW_D=W_<qi5>G{xz@fFstRueiUHc1PAH)z42
zhtszSQ5pMp*{rLo4Z$g>R15g~w){W#t^}^8t$pttWLDuy!jVh~8Hy5>u}F###pyIh
z^EnM7P9?g=$V|pk$UM(7hLCwCq=BT|Ot;eidG|htxVgH+_y6wqeS80GPkWztt^Ka&
zU2E;V*M8r%EYj>FjoL<8Tctb{%c`t@dgw{&q}Lh`Z6Z#0S-o=_o?+XPTtufwaaj{4
z_cTsVzFhTkW2HRv%((W$4@PRmb*UTPN`ME`fBJf<<Jsq?p2MYA_AF|9HpQmznS~Zg
zCWggv?$-;Pjc<<@kDhrt56{K_t~vjj<K;#uSmk)+#?0xjb1%P4AMJX2WV=V}Z)yw;
zdFZz_ecN-UYNPY;b7tl2W^|u<B2o21tzXox6la#5-MG=cdMk&6>&D04y|v_xA6{%K
zJBMHqo8QUj3*4XkgssiG_s(I+;u#^22b!(ka(7+5nI;Jv=7+Zkz&jaUx`cujd*f%g
zoNlsUk^hth>!a!|kzO#;i0pmOSHEaenVVi$yo~+bb0t@H4&=(tZCq7{${`x%_o0TL
z{_DUKlWInozU+MBx$X%^@vVrm;7y$kx=vY!_X<{SvyX<b(aF;$1>R-%<~P_-EuqGu
z`R9`th97D@v2}R+erphK&dRkPxWG;=G;sUOYxO)zjZ<@q)g%KlayJDpOcJ*~b7;g#
zyu0GwAQb#~&e+P%p~|n9`r*a#McW^z1<oFJ<4n6pp7s%TWA<Uppd;}dQfluXzcy`^
zrt0{KZzA>?HQ$|J-a~!epyemMjkb4w1Lup%&P{oV&2N92wA$>Rv*)QQ?~WPxXxOue
z&AWmN+I*Uo>9aJ!KWg1(jKg3c19Q;+aE?e*R_@1hUGnRt*1eIo<W%o^ElZ12wFjQ)
zVe!Y-OZ|7PsqsLM>cO&oI%kUeE?A=3B=2p?t}L@XJw8?y+7>4G94)Q;(mxN+S85ov
z!u|Jyk>RyF-TJmDEB=tNOQw~eB7Px$Z&70XA=E8rP9g@T{_Zt8D!ZmeW!K7Z>`LX}
z*Fk-A+3tu&kD-2zG}QNO#CX^p3_=P8k?P8B!Nu!?G8er%wPJHhi=!*gYOcRNao_9*
zY1bU{a)U93j6q7FU{S}~vX^1%KDqiOIn^yMU3y_;v3q5j;O+1l`%g`6w{#NT^H{m&
z63b?7T4y(jw+;0f<`Nn`S2k4l)7yNbsMIb^`Zilth;e6D?#FAFtYhVjXWpOp^1;)l
zsvD2g?0@s|^Lm$NU#QW`#NO4mZS!fh`E^jgzvf4vCfUv3rSXz`2USem_k>+-dw1o-
z9tQQrPQT7^z7jjL&!H{Toc{i`LG~KZbp<0s%LKPtY&jC2ny^iK(`&J1%a1-$gWZj0
zT<_;?6p8!b-@S&2IR?>%f`x_Zr81ZMW%h%Q)*s+|cFxj(<IYQM`b0R7IdOeSLc0>g
z^RaST&Ef)%CO5S5TG9SeQtkP>65iiBkuvL8;n>)5=UTR}lUMn*M)>toyO=%9ay)pZ
z)p%{oI%jKLxSq`1$GA^r*ASV2cVN7)x{P~%@>CD^1-(bRhqOAlKhIrnMsbS+M$(Tv
zb2g=PkNx+ptIDsJTJc&VbMTQ$C@8e_UKO1sEwL1<7<WD6XS-i*S90Qld>yBp@n#~!
zM0_|)VdYF(OwIrGn%}~i7O5+Agp1Nn{Sw`N=be<L?=DLtUtDX44^;WA+<*Rhsr)*q
zJ8QoE6o2vBh3yM(8CkxoHSa-jJtKVl<2RlGo&lZ#o&lZ#o&lZ#o&lZ#o&lZ#o&lZ#
zo`L^22FPD`?3elf{}%s$Zzs6_2RpOw|Nkq#|MeK<uWa_C<LV3-D=?m^5BF$>(XPTJ
zcLmhMF2e2tzlamP$;V#F*h}o~<RTWi8X9!z+N~>gJp*UMuHE$w-3;~hU3<EAcNIJ9
z>$~(ZGV;Z817fLfKs$Iqa4`gA<KJ#V)~8+#zWXKck$1+mq#m9Ul2gPLm?3z8PLSWc
zBBr6LfXm4iPy;*py^lv)S!Y(y-^Mh^D}y|wf%WmHbQNr0`S|-oX}@4+R+l;uR_H>y
zK`okxkAa)p=a`1_F%ED6{~Y5$@>IUbI7cxNR9=dCV30|Gt29XL^>z7@t3eQ33)qA7
zYzlNl`7*v=J_%dfC0q$9W&@w9D%yTiJ{O7fbNOn(Ii6ORC|^D=SDzo2Z!A+obu#p;
zi1_k~QFw`0S0kfJS0t36Ik*B<Wt6|OueV<yVrj%dh!YWGc@F$e@gsTooowSA7!ZH}
z8xfU(;zVkop6G!~6D5WzW4WU^irT6LkSE(J<Xv1r0-G0NOK@HnX=)*jh8`DNLiW0Y
zG-NOK+K?rVa!4=yt+43>xs1Z5q(e0FYlr+CAh%JTAL&5$pMo-Zc)ELtBv9Pf9brP8
zeiX+-zj^rvm;dQ=ObfLIMfsAD_W|VHuM4Lu@sWY_Y&?yxRO}^kMg)<RmG2JOc<ieo
zKT<AFWlNXqttcCv%aor}l!dOT*qt!nN5QBX=o4UaR}T-dj|-Mc(KZn&+L<S<+2SMi
zGBq7zW^PUYM5C?y_P4M$8z~x!P$!gBYHDg`Hj1k;&SGZ|R~He&fkYm@68vI17V%nK
zpJXZT(n?`VxYaSaz^ULyuRGV)zr7?x*!B&P&l^m@aQdpqcH!?@jFIXIl<z0}O?*)s
zlS0UExT|!O*eeib_}nI_o+#P~wfXXWKtmiW`T*jL+C19_P&}194^5yV)`?`Ot~NkM
zUcSy^s=!pgsXkWud=4y%P%{xR7J{^7=Z4iWM<sX|gyUSc+!V+1rA~fpBeIXm=nCzl
zXpY>9Fk~MX1;#P^gXZ~cA8oo(V0(|sK=yeCoJRKPsj$!2mn2#0pLFRD`9}8P^!;KV
zs*_|NYG-60vO};l#l&&(Wz<(G;>pM^3Oms6WEZY4=K8j8`(m;I*~b$*@ksGm<!z#9
z+X`E&F?CdzG-VjgW(*@>IOCEGwGsBZxJQtk_P|C(P<Afz9nF@Xt6$VF(Dg(ELi_?m
zY<JJLB}Ez`IHdY&Z^*S_%A4(@a1L32Zg+|{;Z++yV4IJ&K-|m*h7;#TEay;Aem9Va
z6fKeE9G|o*+Sq%7q8$YOpdFB$f^UgusH=s~Xx{)A&Mw4zdAktr3cC=`)E2&NA3~ff
z-#+L*Noi20DSMXJcHqad7Q?K=`9W+MIbNxs{2s5ACK_oFpT^Yg#qp|WYm`4)m&hs5
z&CNAH-a+D=qF<%7N01h-t&D{{EtQ+>{d?E@Aitim@t5n7?JIM=?yxE8nqDp~)yvAH
z^+4KrNL!D6PUE;q{f@3wMnz1dIX%>1i^fj%XgYRVs)$|LdgMe8&^Ti2PJjC2x7%0G
z6T}TApnB~Go%$nxZyYyf^W)kw)GG5MIS)=xs^^pr_EvPgY#Tp<^NN^BY7cb3^oJa2
zM0JU5L2Xjr)qZXxin7&!zanj7>{K?y3o@fnwivE#xNXpr4Oh1AzzVjn%BJWGNEf1w
z?4o$~qxPWaZ>XM-t`(Ijtz4NDeM+5jeM))T+>z@ahrCIDipjJi+jNt+akhzb`uD`?
z3bwEGFMl5+{mYj}(Vi9MX^7v;mxtP9MdhJ7rm&HsJPp4oPgi*yvaBAbp(%jMLq!>j
z{|Xf4k@s0R{hRv(os)0BDbt_5Cs5l`=uW&V^mKq<K5gdMNl&Wx4$yP$H+qWjQu6J6
z45EsS)$`xgr+!<uH_(dO9QPi_&Nt5VL?1`D5f{0}RjP1np;ZNH;#_rLE1)v4HLwPd
z>RBzI39vTM3|I#^0$2}-7+ppMNbilRK)S9ScJ955jqPQxOT1cQr|qQ@7oVFCr00hM
zU`OB^Al$Z?cfj7j55S?oUxC)ZVj$(8isudPy@-2XqH<BXBREgnC&<zD%79eQm7rH6
zU;|(aU?U)v?<XL+1gHZofEqv#Al|*$xzC#egK&&@GTCgP5Eu(=30wx$0@8Ce-l5qw
z###fn;<ycP7qBgGKM-r}$xZ+}0M7zD0<Qo&0q+Al178C5fF-~#!1^dlSD+TK8&Df)
z0Bi&732X=K1?&av4eSr>1GE5|0BwM#K#H?A13Ck-R-ViYH~<(390Z&Wv;eLH4hALy
zErG=4P+$ts3U~@Q40s-B1H1?v4!i^$0lW?z1$+P;4WxK&2O#PWGad-;84(a%Gmb!d
zzjXqVJx@TEd$wm7dgdp4>f`(#oTm*<k*z1F6Kp-eJySLw=S_hVfM~BWxPG$n=Q5x<
zj%NXf0I3f}y_2m44g+oh+5is%QHR+$c3WT;jz<FN1qbz4RvS15XauweS_8)ciAP*p
z763$@mrVjX0i%F;w3jUdx&iM3(f(vlfw+gsP{)}7AnGJLw|^6qANLa(>JYoeA8gOg
z>E8nwg7d~elu0%gI0Xo<m}x*PUI`^(H()q$HZTGh1B?XHILRDfec(KxIuOq^vNpgN
zpgwQ`a2RkAa2#+k&;_^z=m}f{j0dg*?gFj{rT{kp?*KOfvw?{~dN<nyBs)@!Klcv6
zy&I4ng*aaa=V@z?_DJo$18@(p6YvPIGw>8p4|oCC4VVtp2i^wu1U?1A7P11MF;EqG
z;vHYs1ZW0Cp3DHCC2$~cIM5t87Kk<>a{vwoIsqXga|c=hJ%MN|vc*8mF(KOr90{cQ
zZwI7$KL&UPh`eOyfc8MD_h?(P8$c287Elbl14JE>WdL1(&w#E#ww^<G?s=VijwgN^
z;T&;6+g8X?zqJ$C7`O{~0EoE|WXFJefmGi8z$D;dAmx7)m<v1(d<{gKm7y&&&|T&N
zgw8T=;CWy$Fbx<9ybOE<yaM!s9n*n6K$J-~8HlpTeg@tH()-4JAe964Q~tcjJx5YG
z==s8n&SQg3*>W5O(j&leAeHk3kjix$*bI0ENd53xU<cqiU{~OIAlf{Gy1?FFE&`|H
z_!5w=kM=EprsJOV==#-hj?&Qf6mrC4CXjCJS->X1Y#{mqCI^VN%;W+oKS%7`GZwpE
zCENcXOPZI0-O3<G`6;3Nl%D`d`Bek904f7Xwgzw%5PgR%8dw*&99R!X*XfC!d-h@b
zF7`TAaZVRIZIO_p>qG(7fHQzprkUl^bI&9k2UPCz>7UEfXUWrN1N$R=4zLJ#2c#d+
zL7Nn;t9^W+`|i#6de)jKdmLr5=I8_CvkNYa?zys;`<TKe&ta@rtX$#~#;Kn$DMPJi
z%o%3(MXm6Zw#JE<?RQ>V`f+CIu}N!D4b&+=ejbgv@ya1b7L2|yXYG|5DKN?eR1l#c
z%zuA|&G|E(E-y*Ro}az^aETy$m+<1xInk4+tgBZT4>^7wjn$p?9yYwxdry2#L1xJ&
zL!Hr!I&Q<fIC#$!3VuA_hMzmh9T*fCyR3JsS5_a5`;=@s&?+`?ulgao6|UXp?pnFy
zfmRQ+Yc{{xJr<@qHF|H*@004#q#M)LT@B2;eXW0|=1hm#vD0rGnxJoF<(y<AY%I<;
zoiJ)=Va;O(EwpcRPu!T6@^f?5be)O4Wtqd#-)PcxuOvNl@;;>Mv3%*Bl3VuUii?iC
zo|_SOJ2NLdD9-$<>w4UySUKmjt&-XnRyl5?v|`=6{r$Jzh`i+XN;{-VZm)4iCWJml
zV^3%0_H9#h8U5J2tlONRnc~8(*#RH)mt;3l+Hph2>tMr`Bhh)4uyTG|RogJVY^BBr
zuEyzQ&E5B)WXR*=tppAA4R*R^9cqDxR6DeFp`hUn*Q9q<-WXcij(o?@x53Z1@z0xY
z;~v|78;OP;x3)JQ+40$o3+g2+4}1)7)a2c*ixW;9+S*{k$0pbD?A(&-^P{KJ+NvGQ
z)=ivcYTjKkLU48B{g$bljUFZ^-oK#bHlRJ;IZR2;tMtm<CwY!amR3_|F6bI~**N(g
zGxvyLXk$Ikpf(c{_F?@gHow1b{*LC&>AG2KXWckA{-f{BUrWlmnVO$Y6W3o}-!Nso
z@(H8Dp^pAb(SF(MT4nyU>zdVoD`&1dJl}2JZQqdYr7H{<PjS0FvgW(%2R;Tc%nP>t
z*2qqLS-Z~Eqqm>`x@LvzyEbnVTkngu)=3Gu;NGoYy93Mcj;Tf0eUY83`gBZ{e2sV0
zlg4yuonT(i%SbQ3cuhx(n(bA0MhD{=mX(W2Yw*gi-ICh3KTcWjarTl3`+-FVj`W=H
zs<Y07m1)OJBe8BbE2n%$RsUYjQKuMNX3zVp{XAY?-`g~O<RSebr-N-vHm8rlJ2)#h
z>q^GC4Ms!9K5cE{@BXnvy@0tdW_;-S^X1%||84Vu)C(t`->*x3IKofunAITdi>{A9
z=Kr$y<CaE?!V0D&O>7|@-PHQuHy=n3JJN5Giqbim-}$q#k$vyI62){Z>wm80{(}bh
zLoa*Hd}e4`i(&rh^MUj>qjJm)jbGhDD}3lpXRDBLdc#$&pG&T#Ce0bCoB3|$CXLg0
zA>ii?*>`$fU{J!zL_z%IcR6dSxi1|{gC03;h`%=(3#M!K`P5l`TDD;ATc@-v+Y1p{
zbGjQW+u?I|+RC+t7}IJ?a=U7$wDMQ2Ijf#uSnOeM=4aIzlkfIe)g(CPS*treCi(5h
z7*9KrGjHYephgvee}0`7Ydm|dEy)WwF}&TN-94)JeQ~hV_mdyqh5M2mKX1r{jt7-{
zjoszjy3U|(AMx_{zcz2kM)rRGBJR9VqdJzs+fqhd>^-RMsH?vFEwZ<E3=4bYEVaM>
z7K6t8{3342jiz-x=4_}Oa&gh7WOYMV4_gcb-N!(PP%uuMzE5IR5UHzI-JHouZ)&1;
zElxXi=TYU|dC&Ii#Oi@R3>pXp&2lfb_+@A2<xNvuMPbQ~jXkgCglWd^wkh;BvB_)X
znS(V_Sh=dz^mndsY-1(LTH0dDPUGX+#~N?R-#qJ5%gkZp!amK#y<Eb|ZMst9*mUJ}
zOH|CXZ*G06H&19a=z8l8mvpYxt>3c8^xjSkvyGL@9d35P-6`tR$*WuZ`T0fKVSs60
zC$h(?_qk8b?{%1>-+X4-*k#Y0_LbeY(d<@p%c`P@PCM>hMjx5S%4zON4{bT`wDBbU
zJzaK+2bR?D-Tp?es|yR;kEzzo>Ga&u=$|`Ne#=Y4KMpjre(ULc>hSi>i$C^?oT8=K
zw@22q<w@h27i-Xuk74Cf)a}ySFf*QS)GRpBQNP>EJa4PB4UE;7gw3AwDWXeJ491XH
zxy%r8kj@aB^&YEcEuS<?W2#5Dk&+DKsHwI#0Xr6-NyYPX3M-fG;P6=6)bHWtL#Ye-
z`9=8oMJ9=LcMU2j>oMg;e5cWF=~0tqfk~Qy%N}5yzbn<#Q*VbCya{5qF4wqmV0WBW
z)qVDZOA6HVs}}SLX*95)Kn35tx{;jG1>-Jjl(sfZNU?e~_m}N;wgt|!Dk@oXCFoY;
zP8#)o4Z}AUR&HjBbFJfHr(aD9d2{-Ha*_JGBOfgf4tyGXF~B;w_6;;6W<4vH?yr*l
ze%Xrr_xZQOM0UgaWYy>A7a^XPJ?kO-m^c5?of=yf6{;TSHm>&iQmugrTelc((ajhs
zxQp>;eUh8E?fu~<QE#W`=-E13^y^+Sa`R2^WzSbj2DUZMOa7pN`}Aa1PPlqf>EYcq
z{iXHB?7G*{YsS+l_2SYy<gYr?QsR45yA3{iZe!&psN@z{+yCsX@4d|1T{Cv&v>lE@
zwM^$O!`>fHSJ#<=!SZ{oT<U`r+DngYs}(c-rK<4FD941rbBiY})zciNH0`uy%zO-{
zs~M1f9@nPNWwv!|$ImZv(sI^)HMApsevt+(S_i6x=DpH=_*5<V;D?V135JvL%@QA1
zgo1rqyDX0;^<5|NocYU~xR=&J&ov6voon=6*Y?=a1yz-O@NJ8gdzt=rxtsFb7s&=U
z7v~S2qj%2jaHp2hPxfqZO7?v)H4XiXD*GHexJS3F)mP?S_%ueiJZFNr>VoSXyKOeB
zv3pxff48{M!}x$@%E~=H`10J%wx{a)7gqCr81>BLV3)_Edztkevh)55^8u4z-iB{I
z?$vlcICgPf^{fe#bk6Ry<>xDzmVj^faKI1>x{lsD>#ea}&0|ByHGWmUbhgESW+rV@
zN~P0EpJgN_HNv<QIcf+6XRYRb^sP4S(UGdsqd^Y&Mo+??4erq5{MDsnBrV@u%^buq
z$*i2=yrK_nLz~~X%hVhn(Jkjewse5jp?S;VVyt49YqYk+2l*UUF5tF`<@D(Tt4c;>
zyC#@Dk#!iLaxT##D*NtIy{biyos)6RUUc0?L8W`@?P~q_ZTFw=cfQ%l?A&4P!mO5=
zn;dkf4G#Ee(JJ^#uyVQ0!t#e|U6?+vi%L8{UrBs-hS_3F{AK@I)cBY5$B#>G!h2n^
z*Uo!>KdQHB^plG}Y3`b)d%7XUE&l2AmDsc2L#tohVr1Q*dg<N96PTnv_6Iw~-=1My
z>gGIBs^9j?@>ge3-riK+;*hZG-tSx6SnsXc!!0Cwn%SB3`&(5?S}PCeGx<f|nlju6
zS-C0UJ@@pfGE+OFv|+EOt4tr+kFws7@j)`mO(*#NR&{rL7pmEZ@*7gOS4z(pTjrjB
zXnLHV*96@&zwr$44Dbx_4Dbx_4Dbx_4E%>NKz@sVHvV5Cb@BB5&FX(5H!lgIyX1@i
z{S)K=|E_iZ2Fv4Q&8u)mhd(bvexs?tNW5>wn6U9e2%Yx!^#Lt`5)TpLbw$Aeo`|IO
z@kJc!L}O<UaRA;eD4s>V;=04eFi`9h<xR1w&OnO8sskJa$6c&n=qmQ+V!ZJ4=a@c9
zLvhlS#?6C^Z>IQ5ilwH@ik%TEj96F6L@sU&{@fIsz|KA3W=gu#ns!_a`09qZPOzuc
z*+V4tm6yQV*Toeg48`!!ZYAf#K|p6&|7DgB_%pM7IGR<0k6_YFBn2h^2u=`#!PucZ
zV(4Sk_m6YZSHTH2G;G8L`7~by&O#kA?Z<M$RS9`e<kvNW<3W#2&HX3OiVnW28>VDe
zoUCl!pjbIY-JrNZN0ieJnNNgneym<!>Wmcml4T^U?WJt|9>vlZ$@AcTQ&f#Fb>egR
ztC6}~ouKl=*PWS-@~aH^Zuvjg1Zo?VDZl<-EkDX`2R(hEn<=Z;UoZb)c?@2Ly!;v{
zJC*+@>_b{34xtZQel8fF?NG63DK%#!BM-4e<mBlt50!;H@lek8IHTBvY&{^mQ@r3{
z<g1v=gWBalc^$k_os+)`ARTCYbvkUYgVTY#uE<j&5=%v{=%;+$L~fp5ik^zQz7S~?
zTRB}mU!VG@@_iD;;gL={u#K-o#LZU#8Hxv{zUdJB^%QeK`1wjaxz$!V-f1oc`rQ?Z
zl>e<BW2man_O0;EhyHXtM1CBNV=D7-MeL(8r)_%x6(7_vZF*qd5(V#KZk<@%$$r~I
zi!n7su)L#2y6^MP#Y=pzj}C9}{XUxOH&s-TJ=2cJ!}hJNvP$S0?CJ8^Q2#1D-#|AZ
z+6H%DW8+tt9O&E<=NsZYZ9(!FjY+`zIL0RdHdYaz6lEiEJPqgu3<u&jHfAac7>VP#
z!0EvGK%8S^`ep)m<2V|46!<gn3~&+f7H|phIdCbk2)G<r0$d4f44qa1TLR;Nt$=HR
z9f9kBh-+dJfQVmWW2q3I#3bPu@kY!RpgV9Ua2gOg$YOv8fQSoX4gnGO!yE>l03HL<
zeg8O6!4r4C<NCb6lPBVbcv=9A0-{U|@w696JV6JRr}IGK=^l`H$^{ZnAArOY-QbC*
zra<DUHIR5}3tS8A0$c~|1tgvZ05<}M0f{GyX(XP!fy7f3ka$`GB%Tl-#qxwWD3&MU
zhj^lUpn@mJ$?t*Oy^(loh;tb7XEzhb*Ti4=*38B#4FuA?z#QlW91NTR90H67S^`f2
zt$-JR!+_~P8{jX%;lQ^*)J0im=rI~dF=}Ig6q_~{=m-=6rve>;D}iEQ91wMvjk)vy
zlATF^?jH8V&i@qsBjoz8k?X%su0P#-75WRIKX(tJJ{RSw4c}QHm4UXJh*_d?Mq}sh
z6AW_|f0Lc+0jFT64S%zCLYtRSKB~Z$z(zm|U}NA=AbyjHf#}v{?m!`MBCrFH>UBq8
zEU*g@b&g#dc@xk8$8^8y0VI8>4sd-q*I$x8czj{BvD20cx$404z}7(2h0p1@{<PwB
z*X8MM$kW{f79o9fv;U$Pt0v%GFzf8?&4)hO8;!U7WrJUU>D_(z{##?G9Gg;k8@lf9
zIY(>w;NVqF9^9^(U#99AdrgD!$TDoF8vbxsB07kF*BZo?U7ICdlgbgh_wK#6iPe{_
ze=WIwef_m4|GoXE)=7!Kuhr{b=ei$#yZ`fJtU9AD2?d`Xn%6$vK56V>wf0Uab{Eg=
zDr|h}#096hyJ9Uj&hPXj<?oNhn#o?b-a38ZD`Cj~`@LT!r$y^zHM`mP{`KvVP3Hyu
z`aEqzDms?R#%xtKHsk<%-799UB`5mL9ofmNV`SCUduwaRiY`u_oa%RfR{Pwgd7ECM
zPei9!nb;L;R<74C7i}Z^4VrbdS9aTR89A2wo`?s;>y2DwY}e)K?#&Z$Q;cBc1}G<F
zoGxnCB&lwrevu{`aWQQtp9<>Vv~9@r!&Q4d9fD5wG%I(|Jvnr6q>a1%*%s?&*f*JX
z%xJWWzOJEb@ba{L+rpo6;p^Ih^wZi`eMfvvr^RhMT*xZXHy+k#O`XT*Yl}2i_;=`B
zX1y0TY$H~#Q>V5z_MZl7>%Y|!YCYfnV0uFRnkF;1J`Fpt{lW_&9|QK!ivg=_Y}el%
zvsKwxEI!8S|7XqRXW`V&eR8TO88>Q>lJUHY==Q|?pu`#dhEKIGoO)wM(I&g52UPxj
zF;@Td*eO0H>Yo)8H4QHvLP3ve;x=x3H>E5xvzc~#eEc-ek82vg@MyfMi?^osoB+=u
z7=vg_a(cG)c8}XU>0H9aWz`nxJvOg5W3R>jWmN{Xo13&=rtuK>@|~>QxQu%-7i13Y
z5415zPpPXjRV8lP)x<Vq!Y}UIs(RpZZX3+6#LDd$UiDr0&}NgTB(~qv%xqzLX0TSF
z(}|tewLUI7zQlUFGw%EC=(;~%OL>AB$^Ce3G=9zH9bG!UdUs4;#X%*!XURLi0CW98
zc<Ha~n#+~-G5fn?rz$%q$V}D;?#F95S9b0Yey!)f7K@dsOYL&uVVi{y^yg?!Nskkl
z8;Vbx>m4gyy7|P^l#P?_tS{b#=j_VHZ2gQu5TRhWX|QwR`w_Q(auu4q54_T3O-JjU
zhnn~Qc-hjZ$HaS6_ws8;^RZovyp$a<E`@hip&;YqYEi!?eVtoBJU-als#W`WuU6Km
z{@UV|*W#^ldD(R%FkdGtXHZ)8P>;=5Of3&|Dm%DgM)$o{misENP-?mDh0TJuMcT!f
zr<#?^o&L0Xcxmr!<0pf6#0AFL58Ezye``XBW5@N$3%l<cib1h|*V@s(7#zeL0M++C
zo^kc)8{JQHXFQlRyS2lUqivhqye67&(P**q*bXN#w#~|Y^j&9C5|o&<$9rT;!PZ&_
z`fh)9UC{f$GD)8|;}+?Cz<}auR&HstCdva1FB&u$vPU`SV(0KFBQB<olg=JKaQ^5f
zT@R;W5R+evnvWG5xgFm`Fvcbn@M}^3*;ugw7|a(6rkJ>{S+=`SI;+c&TV~bmdMmla
zcFQnZ>DH>lFqhpQ?Cap$0xOr4@s8098Dezz(;iFl-HCQ*ByOiAk-AB{UX07I3*O_0
z`S@5levRqzj~pBZzfKhT>F5NG48?b;p2TzOtE<*5U${U&yKwiM;Ks}D7b$I<%2>}`
zV>G(^y`}ma_hG(9R_=p}<F%>HRyw++6<B=Kt^Kje-D!7*Ivp#SBG8I+etr}m)g-K3
zN#v%mhwC;yiwv!G=>I1M?C*}*3Na*J&em%%b=rrhi1(eWKS^VTjh0w<)LIkL$|}j|
zaGU6NIot59la*^5V--`gr*xHC{MBr;?KfST%o@FZkao($>t5IOw6q`NJ?}9qSGF>L
z-t+yN!(Y5#(R@q2*rR$uN;zS@WQiu)%dA!{))eDgm=RrfamS0zqu;e1I_$;f!{&yn
z-gT$W@*iPo6Bak`uFk-!d@L5fcJzNrEEXSQg%890#xuY(z%%e4%0N}<?er(t|KrwC
z`b_|UyQ`G@#nZ>lSNuN^2hd0EUn_;LIBmg7TpWM|7-I~-sllv|uZ4VNu0gI+OLhe+
z3-E&>eb%oOVij%dJly2h3->0b{5nbGSBqC9rjLqZJu8uq*qheu;noNWX!!ZObdsMd
z>l2Psj6nlh??n>mCFRzDQO7y*0q4$%*mZx%ulqE7Z?!Nk!dX%j=;wlk!yv2hF>Z)=
z0nS~W%jW^)+1Lcc1c>~^?j%dPD16N2uI+68<n!7`?w{MU8U(S?{Pyq_W8#5xK}Nwq
zxnDHvpZgoiSk7*+DSz`{cvqaFb;ii=_$PP+SHvHkBmPKdFJ}?Uk%GI5I3@1B<&@-!
zKk{u3^7V8P$%!Rj`ViCwJv6RrK=naX7S5;HPtFs|s|f4hxJy0o6T3Fv6#O<1W#@iV
zuuJu$wyN$|>B_Uo@$7})XSC*g^c8xL9X;gf0$lwAJp-`PoBWdWo2~pe#DN52vAWO7
z&~G95Z7lqzTqdDfc{+b~LMPiP%6A0itAT>)T6`&=G15gs56*dCQPa5cx%`eU{eMRn
zDSorm`+Z%sQIAG~M`O0Fao5vBIwMr7KsKc0YhAj3=Xz8x9PyhL^1^Ci?0R%mX7VvF
zmD@23_NH^>hbY6&wQsK73(-*P;vAY6yW#TeT=G8wsScsO$h3jv2Z<)cfMQu6peB&?
zhbs=d)&N{+WT$Z~1U>^oADI%kZUt-x#A~OF`j^f?(jy6fb8UueOQZ+2gH<?B8~MXR
z7uFvZ*I@l&+W|-5JeoP{58Df9hhs6&9_Rxc2gIu|yVk}*pa{n)K*-3dBX1`l=GSM}
z+)xL);aCWq0PF+w1`YxuFV=6^4;YAJf8car05Bd1zGPQ{!9c8Yz^=XVD-gpNvbtzP
zlYt$9Q-D~Hg$V=F+8on>SVx5k2V$KQ)}P!J7>Q$AYat4_1ULhj0GtUt1N<5I5;zA~
z1e^<Oh`t9tsIs=e7+`<k0^mU4LZBsZ5pX1M2~Y%F3JeFv0cQbM18HrzwZJ&wI^a5B
zJdpaf1Yi;Ps{zCR*UZ`9gvK@gcl=5JU4Ekc-1+?6`MlpG?>AXI{&|GAS>@-j=lv%C
zfBYtu@L(qtq>LH!(phK6o3IWSdwEDMwUZpZ=@#Q@8W-#HG4{dE6g-#pV&xLo_-)Xg
zx#ryH>0W&;nCaoecaIp^%>1?TsKz~8&WYK67kNccehKL-!%yhu`W42DE(ONDt9i_N
z`jo`jo%*h2vBx)5|AdFi{cL^_N7F)%ZfVp<$1G8&r=zfGx6S)9y@mdZE)>MJDVp3K
z4>r8t<b>P_p0_vqxpj=F^SXG;l^0Pf1(|pj#>2EwpnhR^)t^Q$h&*Djs@A-bV;bIf
z2n<%Xj~&z4<m{0FV@5jS8IqMdyxk(rKGLXdl(kjLL$R#N`lpAUq)vLR@z5sXbeGjT
z@j!Z*m0NS<R{mVK%dcf2g+KlO_(R&V{)Q2q9>rx%nB3DiJ^6Cg%Z-)t%roQK4?h^G
z71yP1cq>8uf4-k%W#_u*{T%<ApX1-{zgStnMBd-<ulXBR){jt&^&<=^wfB!-o3=_*
zb^OFP5&Mjq?@lo9p}ua=@{`_1+dIF(V1*?sXR)*0vOOKHjClT`I56wJ#yFGW&^3lu
z){nc{WJC-dJi9N}{bS|!r%9{L?m2s&s`Bobfsckgi`cv?xS-9aS(!dd6a1srZN|H8
zC+bh1Pn5h)-nDu67^mh-lQbjtKlXn+dfVwaTelm2%2+AEI(CdHD>va#(2K))PE+sQ
zPuS94Z|LgIMK9ylxt4}+s_78b!W3&gGE-Q&JMULBXYO`hukUf`yi0Uqq4M5{M!NgP
z=_R|hQEJkRpZopAMB{AVDQ#XYa*NQ^78m>bg`Rx+zv&;y`}6U0zppC9m|}P8hdyXY
z+pMql_Hozod0LYGYh%0VjaqX&)KRiG@s)7Le%_z&uh0F?`|~B$p1&*M{jC!zvyK&x
zjU9KcW&1jLSW^_f#X`YNgW}#}Qu13asMApSg#FqP$;Mgw*|TDv8rQrTZ1=V}9q(nV
zTygD7mS?vMFF)x0pvuvQw{smH@&0_oUyX-lQF*e$4vjo|9KJkk$s*aOwa;{F+<P=7
zWy0l)H5OjQw*uDxj`!!|=T@is;`gM}>oca)b|0J6^3H?w2XDs|UVE`<g4vE8?fU0W
z=@o#FVCMM7DijP*K5ntLYL7Y@jos7MTrY{b{H*h&OVKeqyl!rpTkT+fjMLB@enLS(
z((vSCwkl)SuV^~4W@MEqr}I)5zcEs8xmavkn*Z~E)7<L3KOa8K@f*(o&j8N=&j8N=
z&j8N=&j8N=&j8QBe<=f1QLaBb|G%@ZPmpVX^fv(jA=1xo|IA;V|KG$+FGOsh=i=H;
z>`W$5W3*L8q9A9?Q7sMdbPANZO5l&It?J?G<%h}a%blh9p0!oQQZM-0QW|caXLzw=
z#(N()sC&EmNI4lyyA6MFZPn49J}$n&68QRRs}A%H^nuH}r!O2=DIYWVX#Bp6rD`~w
zdlhqStHalmHu7=BPy(EH8Rj6y6Bt|8uU)<-0GJ9f4)l?Dy8F1g2)%rL+;z!U84kfT
zhqDmk6>RKW+vKB7`I1k%Z-A$}rw=^1<qpdV-*)o#S9p<=JlvKM6s$NWaz+us0O!+>
zY}nrd#4es8_*3EAPV@d_MsOcjcaRa}%KE7n$o-=OT)oAfKAt}A@(a^-X+HQsq*pkT
zQ$DojfFCNFn`eMTDsq9cQgF=02GDsw_Id(UYjCs&zPQ71Y{Bxx=|=N}liplP&i9&p
z&`CZA^6(L6QsnY<J(@S13MLv5;uk==;ctcCI;9~$UtOFVJd*QUCtZ-FjONd$bR<i=
zVtt1kY9!beBQ0^h0C*I(^mF)uEkDm-|M%F_<g@KK|8^Yy+wAH89edJwKd43a(FD)a
zacqO*V=Py{Z%>jx0C}>f(KyaFKe8vK$wV6Rbw49dL-wTD4_XhPB6}XF4q<Hj<o4VJ
zJWOMKcHg(BNaX1wHR!Hro^1Qn=Cb+r|F7DowQ9xflWg~G`$SXwu07GU{HA?s;#5WL
z^8w1<3cppheNua_O#93O&$i$WzWq!n%N1u&#hN1Dwoj6ehCJD`!I&@h%*6G+*FGuD
z9;Bi6xk{eqd+k%P-pCwkl-SP6?Rg4#9QNGd_+xvPYodRPO}}lU|4y4$ri~r}*X_U`
z^^x_(oQ<d-|DH`r-U0Gt(`30kwb9?RDW!=<8fv3GoVaWJsEvlyf-tt9(Z7><qkwe(
z^t1WarXoqjcTld+rFvAs_SJe7bPrX;`ur>Jozy4BpfIayvhgfT2wRpfadO{l6O<-h
zp5~WwX{g=)UYa`K5R@@L59c_iI5M&;-JiY1A@Z26FV6vrdn8@Y6loVj?u<Mw*_is3
z-@Bd^X{I90*b&_ID9w%Uq$z)Yb*Y0y*yhS@O*W_dYX;l?mC8LU{l?axn=d^t{aIUo
z+h+fc`zqOb3iybw&DlDqT>nQgk>BHy(j1YeaUT1H$KSIxrTKs~cx+^f<!LHwYf7sN
z{>j#c_Ft~|d$y)Djz~kczFaO%Wo&I-4~ejqw>8~+W7uc0@7en6yKiM}P50jN?fPGJ
z&m~)XfDb8r=@6&JER#Q1QvLruTT_}Od71{JzHtA0wx%?hNJH&<lRQmjZB1#_!9Ush
zdAaNTo~<d3CDM?sLq~tn@%L=4xG&T5G;Isy?V4;(_hpswl+TZB{kdtg_hnr!t8f4R
zsvob&-ru(EhLi*Jl1I>f^$t|oXDqU}EjV$3FE!a)oh{Fg`*BLMOr9pTT$<mrH>J6O
zG}N{`h&cW$Yi~+h17#(9d&<-Ps2`^^#z;f<{!}i_@7cSPJeE60Zf|R(#Vw!KVqw<9
z-Y2YCdy6~`x?^O3yD#H0ucGa%c=uL#fBn7oOZRHBCmX+B?!EOB`qyuti|KyTRj%g_
z^b54ndnW0LsehT((9`cLJw+0nX6xSHp)0+A|ETU&wj2t+?bJv^hAGeYUX(*<RgP~2
z)c$BaDB_Wxu`1%beEa#cd<$Vm+RF326MCi(EwATa=exYF{|dfS<>ly)vQWJ-#lDRA
z9wsjbTe~aIH`%*<{YF>&)jJ{aO-<^L){8l8MPrzLNK1N}U|&dlE9wRGB(^JCFMgzF
zWyY5NXc@XUg3{Q^bDfMb$Sgl|jhg+}%22+({8_F)$n`AG^+xEaS5D8r%5`}?{}o)X
z#pDFEmFIc|%5Xwnuf6_Yy{7j5uc+59jX6EbbG-<9`jyl3k8u4XJ^vM4*I^$rzUF!x
z${>{Yh2Z)R)$5ANP`<wW*?OHW*Rwp=NzgN0Uav{dzshxaJ^vM4J7Qh}+S*{RhFu$b
zJj!6ojUk8v<qss(58|hawy&N?Dtf*wKZaM){jvOWhl&PwiPiwprxo_K&`0HKeTY`J
zZw6Gf{UM!**FW;yLHa75FV@QSEzjS6=(|>aAK~~5{!6-+uLD2g&l+=P&{m$m-O$JH
zYkmGQf8}-hEBs~1_0@vTWN#t%RaF1v&zYEni5`b5&EJp4sVZvg<?T5~6BonQ5<BVB
z0{ar^qf%ZUuvgjk@FRWxXqzstt0vajpshT2+o9`Pc|S?qQAhb#bS-b^A90r|*QY#p
zo1u?id42vOcjfi@Gu*u)!j!PfzlG7aM{_*blj=qE8@6_MgraACyid#Us>iOkNRKd`
zaZJ^<3y}JyZa^BZ?GEe(Gyu}Q0DrUVIpUd8W{YD}pa_WHWUjygz)8S?z{x;No6fH5
zh<8ERG8|h0Hv;j_!oIr?2d3b71d!GlwF3?YIsj>1&T&9mmvcPO1&C|0>y0`BgK+Ew
zq;)!7fHI&PP{9NDeGc!xIR968=mGtR2U8&NU=Ac6P!@W&mW=_L0-*!T!vrAlFbzmN
zgae6(B|zd~4Ul-)3M3v50*QwUK;of4^d%lf0*MC^ka(bVxrqmwKZ$rytWP=<$Hc>Y
zAn`!oC(HA|eb?f?cl{9_T0$SH5AA_eA9@0b2Qwh?K=vmd#sY~4f1oLFHjwJW0wD2_
z03;p~fyBdMAn|Y-NIcvD5)YX`;^7w{@j&a!5)V^=!~@l5;$a?;c%XG=i3eKW)DcK?
zU=a^HfW!lR*DKEh_dSUFPV`rJ=negd2b78Bf$UE_Ko^#WAfPFZV}Qg1*`0XU0wf;D
z?!?1MAn|Y!NIX0S5)Utd#6t;?c%XVtJdmA<2eL2mK<m*G4~anHfy(U&JP0HnQh>w*
zeGgOcfPCcNP`Ga^!~^vQ(1YDzL$-ei07l}B1o#Ok1yX$s1ik>Gj53cZ+&o?MZ3b<g
zZFiJEH*U|3@&1wg$H?=~m*?*#&!4^rl+T|VEB@p8e^38!^XJAVxpB+CLw_3gROoLC
zez@^4*4AvlR1N1)pV%!MJXXhFIY1p?E)aEvc>yFFp>D7|_r%}acojFULV8xkIbH0u
zU4<Owa}7xOTn7#T-T=M<nque1i7M8^8SDO1di1$$dRHLn;RYl<+<}x2>A{WTRIJBP
z$WcC4K+<Cvko15b#uq)<_c!jHh{{o(k4^G&YzAr}-4-CVzhs~(5N+v;9_(`<+vZqa
z%kvQpInv{2AmuX)XabxqPj8C9xv_<c^=K_GM;joeZwn+n+5stTd!T|3?%ls)J*q;E
z^r!};d@zR|tB0~YJ>|u{cUP>(9;iv__W~*XJ|O9_A7~0Z095F~y%$%kM=azhpG82*
zXEBiYKwtI6F6^^S#d_$;%h5$%j;=t`qZ`l^*d3_QgL`MJSdaRUBRy1rq=zby^iV68
zo_k;8-s8Tl=eUN9>dP;{mcSyQHt?;y9D4Yhd%xn|8z{X1=SYUO2lDg}fvs@-NS==B
zHTRxV@pXNmA6?fMNZ0iPQl9=mDmPu1doQW@x>#eLO^-g0y)NcC_{<mge!xBZep}w-
za(zz#o8cNMKq2s?TyM6#?DIVLod0ckSIg6{0k%N8weoaqdFA#dJA8XxJe#rl8UyLN
zy@5g?=6L*4UU_=r<J;?M$kR6k(sea~uoa`%l%EGNC3}AM^1~&9>|Mf(Kj%bGp0ci9
zVLUpo#3tyY1qH^vlDl}?Hym+ByGE|&>zBj#McuemwaUJ-VzbL}OFDF9n0u_;ylw9f
zH;H;XJx9;h*`i<fl98KldM|svS~9S$abEHV4LqdP!TY>W;G|h)cv4cAaQ%g+H;q>}
z>J<8XeDTrAv+m5;9v1CiG87LW16jEi&3j%6-ICw;@EgIg{MxG?8EW-oT>2lq_G-{5
zZ++XoAK=SjNBK=sQ938{JAXDdvhTfDqL_|l{m-@Bf6(B5=w+{&&kV_rfS)h%-TwYt
zZ$w^ld!-#xCAZhOBNIX&tKq(>N&M~GrsgvGv3XgyIYBeUg<Z1)KIkvWZlbi~hK|?4
zhAT(nW?RC_`E6Bg!}PM18XveCr<XN%--D7NkB_$!G}JfP>6Ue<1v>P~u3KH%^{DxE
zrq7Bme;gLx@LtZ%wa0XI)_93?`=w(Z9CTnp!JL$adCToz&KftYzLi`1t}`}7x%quq
z6BWIxbNKQPg3GJ$JSHT$SM8EExfYEtZrr{7!vh;4du1G+(<CW$_sEFEE`7px#v;Ft
ztX#2lQcO+FIX+f*_FUOh@2b_->w$wB87L1}9rx(Hrpv1`*q4>dzj;tnywj}U>I0J_
zZ*nhtr@o)sF72n5tM1nPaLBG?%Podk!^+t$98>q$Chr)2zC?b$MD=XFL$xyo6b&Av
zKVx-`_csS0aA+Ul7hFTFq)di)M?Cmoo{E44jYej<G=3r7r~IEeU!rRSl|y&pMZ*hk
zq)w_~p6**F&)#=N+t6~hwpD}EdBbPlnfey@BYwWb^}E&g__f{9a`c{sDt+}{r?xC!
zj{%H^ZHPZ6ReCUdopz_pmnWO^^Cj~0CEglb^Qz=YTi@3QCv-fh+-vME-_~^ob^Ev+
z?^^AszMOo%!2P*T*xIan?;M6Ko)PkRpxNpzch}XMX_ByEet3%jyoa<WxfXllXSkeh
zvS5+_lm+Xf>MfC8Fw%(Zea~0FXj7S+Ue~D@>tf{|?)ebECvkV(VTEH1&E77Y<meT&
z@2=fTOTD~v57stYql~%US-B+R&TG`NH`U&B_q5A%rg(Cl9!-wC+gHElOoQlvriU)0
zE^lS!E^5qj-C(vPMo;_70e-$jjY7<w-+}BgU;5PcXU9bwqOCjwOSN}f^c-ko>RJ@m
z#_jQlOD_f-c!Bp1R<8EI?XGiPWTf4EH)5V!a-(S-k2xDEhg@8=DOugn)x#D868BlT
zapLrS603qpUA^k&Oip@J6SZq`+NnE_D(}vFwqGX}FQ!#>>AKBwFSYn(XXfQiQ(Q%1
z$&QUZujYhl#_qN$^fs}{Yvh^3Fnw9Ms@3#&u5fH)CCXabf}byupD)p4)vV={W@$|I
z=r&T4VH`Ep)+S)b;xnme<0<%fB@|>kI6T%i^?P{vQ0l_EH`11z>Rqp8X>qFdz!N<z
ztaGQ&gpV{Ux6<e6wEep~XY=zV<`;CDx($Oh{CtW0e2M&giTd8lyxlcpS5DjEC{)XI
z?lSEC@pN^a8F<&fr%(M$>Vp;9OOI@;#m|>`(sI^)@|ZHmhjF1`VWE1d%;kQW{oteZ
z2l$?yvozqi^HQ5W5zb>yTwjvVt_0r<Svjp{aREn@8(Mj-Xn%>HFHzYC-{LUnE)={>
zf4kgGdG3p3gPV)<2hY(v=XSVL%jhS2HaI2wKA4)uFbu!`@vHi!vn>WRGijSrDxFsP
zEF&?g5k5}KjEKLpR&zi4R-5+dNLA_4AcuUTCt=S9cW80`>e4ZimT#_R4#KxWR?cu<
z(TBF7&F|Y~YL1WSmh&K6%FmZb{PFW8IvgDI%dM;z{yMuy?a`fwHN@~CQz#f7ciI2+
zlG~G2hD6Qua=mjat6Au)j;n{bq$o99P&&#N{U1MHB0492;~C%?;2Gc<;2Gc<;2Gc<
z;2Gc<_>W-#Zf5WeS5hT~U5p&WdR-hu!M*_#9rPU}4(y8c-mWg5m^IHK$XV*^>m_mU
z@^lJv4#3oLp5CsVeArpx`~rL@h(tZ~4Gp_>@7b-3gRj#B7l)9Z1`ff_5@(NqPB^Cg
zX)ZuU$S}%G1H_~Z53KSThk7~(_)2`;q{4Q?+Y5*JA#cx6Oe`nt=j-j~>E#;0RA($z
zB@LO+v1xmhC`Z;GnSuKoLopI@@LQ9y^9w0)7sh#t4>AQ-u*tgNq#C2j#=aZieXb!R
zk>YbDd#(-;zVJBb>;YisGur{&f$J0iU(4q)qV(yQZ(upD{S#)@kwTo#(HwN#IjO6+
zAD1W11ro^S<t>&>BzaX;n)`wLEq`Ks-P|OuQv8WI_Ec3*d`?dj0%C=B*8mCqMln*f
zzro+62UlK>2U?3A?vzX>cG~b6O-9_nMUeHar5GO!g^+KmYyhx3kPL(2O_?vS4{$Qj
z1Q-Q01<nUz2t^hT917e9q*#T+z+u2tpf&I&&<6MvI2`y2I0gv6Ty`z-Ux5xd7C^^w
zK=@O$F$$f4&NzlYG2;pB2ZT;C8z6?rWVHSl=woAGU>nwFREBeV1>`e4(8^iknO%`?
zO+U?yY5E_I<C`>lUafQE0izGLt0(p8lxCEpV*tNoRCE=k=1W~pg%{aOFEt*tdF#g7
z9}&mEo-e!*7k4_(EwEps1|~<Ii$TI}_Wb?OXVtw+w=dFbl^f7{YSwM|;<4v5ZYM<A
z_$=(&qrTQtpT&0Y&C;(%`G*ac%nofP9jZ3KW_Z0bJ6$mL$(~;|-L-pMR)o4s^p07>
z3JXBgUiSR)XSY;TMMq8EYg#4Dw73f5-?HaV7Wl7LnV(}dbYH!rxmjmH`ee3To^4iT
zI2-5Kzt6leagN5aAgnJApBELSh~&=B)lN1W`EIRn-dokqM-XoSr)m`?s|79RG(TRg
zwAZMr`5s$Mbr|Lld;Z$w>*vef&M%rYyG7&ObL?^MSN8mxka}~w8V&1q;H>(HQ|AY1
zqK@EuyNXg(hgPT7#J93u-b-iGs15I_VelKz0M7u=0M7u=0M7u=0M7u=0MEdG90Pcr
z`P1|N<82x5=)al%AMf6t&fb39TmN63|Noyn*S~>$K0#p>&g^(!Wn<~-o%$nuUi93#
zxynRhiL<AtNX`p4CV^M0iZ*u64VoLd27c|Mf_a%eXgz}3sx%%!#{oE|xk_j(p)q$X
z^24YF&FiR`gBdc4r2yFTMUbU|1?2VlJmpa$&x6iW9&}DI7iEB}1XHYV;|+b}<xG;7
z6XOO9UQ?N_*xlj#yH;LK%*f*98;n&L+{BpYAM>TV24Gc!-<zXF_*HqWRN1irRu3v~
z11i6-v)Id()5A!vhc4cQX~Szhs|V?G${6zwe5=P76@F))n6GtE#x<RhA8}EU4vM*v
zYEZ+$hInVz=AD6L^8#ni<_cre_!F|MX#1+{-?KH%HL8d5remkEnHnyXKaCgt{@k*Z
zrYdv{fox>CGz$BEyEX!iDJka1oKD8YRwOT50Wbyp>bZVZHW5tA@@maW|K`6+mXDj`
zkZkP-V|)6z(NGl2Kh@iB>-Y|w)9QlpKFEp!{jfxbE6YWiypDfc_Z4eFd|USw?WcU*
zSImQ}sQbiy9dKv~K8X9CZ239vX&!BAQ{VEaNF$S{*<CJ;qJ4gwMlqh}i2S%dgB|-~
zW2kH5oGo_RXuOU31@O(z-GgBySwkEn3|EFRJa)Wo6mTq#ML-9jJ8(RZ`XroVW3^53
zH`ivlc_%z-e`!bfi7BYY#d>2bO7;_u-vcp*$ovYVHeU>U12o0XwK=XWew&X{buOPO
zKxzY3fvtebKx(r!fRqo_AFkbS?TKQ?G3><7M+jih{MmB50o8F#<AexzWyc9?qi&)e
z%9;UDab(mE{eYBjG<L4ea&?*Vt%q|{u+ydsIpVVuFcR1q_z8&WC98#eXk3)WDbcKD
z=0J>{$}o=wJJ*XXurH411N#9l0Q&>40|x>h1I>Zdb}WEJ$d`|Gzr5r>HP*ei8To|G
z42@siLMwdeO=qi+aeBj5uAfV;r6$c8shjz3<|d8P7x`HC73=s|_aO<0sc261<)C|V
z=-@~jcl)y~*3GbQGVhqtXcv85L)YNtY5BH=KjorNY(a8b`>OAVuj#b7ZHEh4CHlt0
z8m+1G_<U`V#tQ!qoy)BE;=6zmE7z%0TO0dN1GV+vY6-QTZ+|d7p?*!1nOmQR9oT;1
zg-~}t`aV`Jyv8S!n#&!Ph8bMlb+7N($cWrKhL5@jzpP#u-fl(ps8q~%&B|pkC$sb0
z$2NK0!eam*>pm+H^YOGKdrVzm)Xg+Mw%eG*)mP3WNm31pS4PE+Z2dmW{LboY>x-SS
zRst*c{6m#D?cy`H-`iDV(a>DuAx6*Bhreu**m1t&J>^zsUfsd-IxF|+>9n?L2eWk(
zXPKIJmy8fxop`@x>Sm*d$%*$bXt@n&&oBwBT=IugBYmVsxfZWR<!|q6w=3dGQrGJT
z4fNc1j@dAJ=hYQhZ-JG|Hi-8xnfl?=$;%HGwo1z%yXXDbPYnio?%qC_k9Ggwh;@G+
zLG^U(7Png0+t1ysbG47N$*g(HRig9W%0A>RJrL96;K1I`@qoz3y7RH_ez-5#wx#+K
z(dkiK)`ZDDjnk7aSH0X=DbGAJuKn<Xky>$G>V~)CW8L{!ceT1rHS*N(TmoMKp+Gds
z??Vkg{nvpfCe@5EecAcMbKMh;;#(1A!J9f8be*ycV?eCjW*-e<qm!pi3cSni&2O-w
zT0)IQ^Uo(Q3_sL*V(aks{njwdOjfS_zy)?{p@G|HUaRL(YMh!=tR@+dk-I5)VUoD@
znL{H^Vm>{LCkX|vY3ZJyy6ZPd%&WdEZTnbXL3H7E_1cS9M)=2cSZ2IqIm3)*<&GvO
zUme!Tv`X*pmIwP?ygTcScTW7YUiC%Eo<oJL{rOn;lUKL+e|T|x(e}q_fwPC*IMeQt
zr+tLon0=UA4lndVK}e~+fBf3CRhp{fC%%c;XViRmf_V@1b%U0l^fubw`AuDneXw#C
zJKHVW)8Wd9=O2m#v+iq*Gbs*TV`ydlxSLHz#L&UB@gjVQmD`^ttv0*o?0KrnyJH4E
z8ulz=^RD26HlJo?`YcWGk6O1G@BDb#77CtEl)O&fwR!g#r{+tOG$Zyu_J2Ei+vz!5
zw;O)SSSjIS-T7Ge(z-AG^VVS;5Q8y7!Ql@^hS%<N>)WEN_(R4nnO1^|_=WhrMTzx?
zP`8{piHO%SVdduN$8{|Gd8n;#pUc-iEpmPwA2FotZ0fn@m*(@a?r(yat;;oT9N=T!
z`B-;8)_u#$_S3c%U@RYlyFx)i-Fk1Y<a#>~Hp^eJRJy96zv~BAug9;(z3s)vx<6dE
z=~-lGtwRl3v<_4W&3mQ$@Tpqz!4Dr35)AQCWKB=vZ=cpK%cDts*GW8Q{xT=-rFGDA
zjRJM&8hzKbJ$7_KRX)~z*o)1F%?(w(>rS2JKf=-`EN<Rioq<)SVVtl(J}L+WT}N-7
z_14&~=CPsU8uPL4i5NRg=|#Mlw3wRz>ovcHGc8hA=m;03o%$uZ{mwfnOW$3VM!vY#
z&XQsBSvlXio9=t88#ZWaMD1!duQe?ka44*G&y1mSm75Qq*;mwMBfeAO`=yYNb$`Rh
zy5mC}zwr$44Dbx_4Dbx_4Dbx_4Dbx_4Dby64>CY*%wxaA|NBZPc%NeT-2z-4yghv;
z!iU?{%fUH7Dsc$J{|=G>X9uyLAN%Kb{r`PF2LSvp`2Sm0;VRD00P-h|!d@nX)91u*
z{r_2BSf6S9T+vo3pK0<<Cx2Q7|2g|&CI<XT=M+B8<O8jU2~hYyf9n@bzSV(97vSnG
z_Vhs*2mU6Xa)p2RxBk)<#R@2VpcVeo<$cIa1;`K^t?5ae^Z*hkLXXcr<Qy6J?XUXC
zSHuVTVOzs4HJ}IUyUkwr$A0sa#u#Zrpx5qlX%xIv<h!l#o6n)fgzYD~E>I142IEeS
zo?n-l9OtRbwygAT{`=E)fb7>0*;Uq;KKVPo^r_$Rr6&$5sxu0|`ETotqCS@QvA?6p
zTOMCRcIpqlcYr&xlLyNcXQv#w?6;gN(qzihJS&$*QQyB!qwujOyK?Q4T?>%$gQ4o+
z98AJ)<TFpUqd6+bS6l>yI|Msdg*wm~#~7YuJb>E3iNFCsq?f@zo$&@z00a4=M*#hS
z)E@)@$tT?!JJ$xdwn5h~@9RDZa&-MrAYCsENWSh<f#mBh!@rimNFcST=|IYNEq1P+
zarKY#RmHhQ*lFtuIm)*?5NTQ8_D?|aZO58~j3JQnM|G7o2ATq~rXTC$PU~`_jO-j7
z<lF9w;~_v=kJbvf5jYI^1c>sn>w^vlDxv<Pj?1VWj06_pdUj2r3koI_Y<1tQ(QCow
z<MZop+>sJyYZ9INHuQAjrMjnvEI)MR`K$ThoRym{o8Iu=oA4k}bJ5Jn*OP;*+)$64
zyJo$#TJtj-Lsmu|WtbRNF4%nJ@?JaZE?RbF?uu30IyMX_Za1Tc>{i35oO|cS>P~QB
zm}9J5zHc}6i?`x-tgl`C%CSJXuFuMy1L_Sp_GHqb#F(sR`Y>1_D>u7TBP304-*w~Y
zXYVwgCcAiC&Ty0r&!1a!VnPr5p{ANBM-wW?th2W_ANpi(G~Vu)4SoTpclX_!8?PL4
zWWneQbJkv|kx~_L3anh1|Nab{^JhB!=la0^)7N{etdD*i>Yz|CyT`&*r$+A$`h8Lz
znsj5@x~qYCx3Bf@)ST%sJ9heQLlcHcW96J=BWx_rHk~kPXJO4_1}(I2bWhxvmhy9R
z)pVVSy=9rG=+#jdgn}zc&z!susd_A5dZ*-;{kY<yBd_OX#NE!!2@i@hzv{XkJ_@Xy
z^VwEOZ40X$w^8DK<$FEledYOe;do#9dpSp)Vr-c`@2~drczJzq)AW&t^oN`dwk_G5
zK89gZwb=X2m5g&6jE0VV+S<h5{bPrE0drr>_|Wy|%eglrPun-P_rcsztlYcwh0|pb
zT5;~e;(>NXi|xnEmKJFZ9v0tiRH-zo%}w}C>a?Q#`X6n&_kY7zz7-yLgaV_iF>@>j
z1XYV`6cKW*%hNL&b(E(h4b6V9_b9rs$DUvZ-dBF48t*I5`^wk)MeRy)X4%<|8{Mn7
zayYndeC*v@OWybyGtA+3)Q;u`H4qgknV#i+<#}IueqA`;S6*{ZdT7ger;R7+@9DBr
zJg}sG@Afx(U0qn%eoVDyPN(ONW|$V8soz*$8vb#hne|&w=TnEbZ(jVdSL75e&AvUd
zo-I!r&%9WJ0f;fIT#C9~dK+fO^NpGXCpzkPdzt5Lb+&=A`jW8Ob3R3MDT+ZX2`iTw
zA`a3SVzZw2mFIosyAB!0T&^|YN#iOHPNh6@{k4|Lh0S}qO<a0?YY_&|j$rUhDCk)>
z`{1!Dzs5}x>+Tv<Qr2V2i}+5X-O{5b%L0=$1D8F(JQu9oskg%mcwhN^qo~v_P5L(D
zedT#ydEQrkYO|G&ZfOM;A9ZVgta5kSouN+0N~Q?3;+&r!J;gARp47jTL~aV>edSXg
zUiZ4Lr=|V44Z}RfJzXd$TbV!a`Tot}FW#?czNKF5QN19goUmT9L=)|0R;w0kiW#O6
z>jS^I<HhFD@7fOKedSl|8<B5=Z@Y7P5r2i2-m9Xsq$QSO72~dF{A~BD?MhBukgwyE
zGu}*O$otBFe_UQ2ae+d?_ysb}{Kh*2H!MvXRaRq?a^#JY`>8iOXCIb|(|$Erfsb>x
ztX$C|w+-rn*9ZGJRQW~ePSem3-d7&q>-ddlfM<YbfM<YbfM<YbfM<YbfM<YbfM?*p
zg8{fF{ssSk7c2(&oB99!CB6aD@@xJnIdW_MX)u{^OKpJl?FfIo=ARm)t@_WN|G%1Q
z@6k0FxV?%*t{xs@9~UfDsBI$g00BgTsp%LqJ8QH4dKT6OX6Dv??YfwbH64p}_NuAs
zDbfY{1bh0pxCQz+d$~$~m{wa4_Ug*iC)Zx)K^6KRbIoGM^nT1<>=*H!-ciE(n}1dV
zr+*W3Kz8SJS7H6lYcWQu<i}0(eJj=<@Pm+-FLz8n(sb<M$;BFAc#4fb2=;W5df-p;
z!EXpO)}WXKTJezc;r<1AKEd}oi8#pBMI@1O^R)|9Y5m4j=nuCgW(lh=cOCNirt5f%
zLlBQ3P?bXFG<NtKGpowUQS1T9(S^vjoA!E)q3TV!4Cz7VbmUyk5kL?dK1Z^?`6Gar
zz!f9sDp>5tazsAT6>MMm<kNLAY{~MZ;Kd2YiZ}%Fkyr3SWypa3(YU@Y&bKaC1{9&p
z6hulvm!b@c^#ydRLm1l=U?bpl;5q24;>FsQZDaI1#SwUb%L=w|e9mIXt`xiR6Rx0!
zdRN_t(j)A{IWR!t%IQpH)`1>QVmkAsTohm86X^Z9Ty(4`m%`qu&`Du$IyW8HI*)T+
zz7i>X<Jq)DpSZd5afZTDSl&M1T>1KR2gj7Z#544>4kdCKs)Lkw9eLg!o?PC<Z47wL
zgFP1ETCG`bxO$f-zvj1b0E#riY78?EX%3c4llg-*w(>NCyjc#}c$o)3NRxy#_R!Cg
z<DD%>4U~f`yL;dyIp0;~=e#{#SQ$os?B&bJDC&2tJRjnn>U-`t$0oj<Zi?UUd~<B#
z_x10~zBwN4|Ml<3${mvqZ=i29cCL@%`krs+)gKFAf9j7YcA^syZAE4PbOAzbc0PYQ
zAo>k9R)VQtAfq-z$J2llfKfn-rI-n%7>boZ$jIV>A;68mDL~SP^5WVt*S<*~{9`QX
zJhpC-qvP&CR51phYh<l~`0T*0Yk*;PnJJE;o6H7?;b0l{4{!nJVk^*oxpv33N6Me%
z7U4W?TOdbmG#R)FxD`mT8QXwofV+WLfO~;AftY?#b`N+6_zZX$_zs9qNir4Wc^23N
zm<sFxJP$Mm-U8YJ?*hYs#9O5NI0kqR=Qjf%0I$n`zbik^0zSlf2JPiBusx8{ca|Sh
z%u@!=j{;@`oq#z&AK-i76ksuMHn0?U5=iM&<;ORHWjOx~C{O}#z-qwusQc`7fOKpO
ztP30htPhNk{~j$rUJPuA^BaJTfC<2+z~ex~y~r*BwSaelZGew}`oLE}17I=G2v`g4
z&KPJ0r0WloA5$CdgY!<nzCeFqe;~C}lG`RfJ`BVf53<|9QNZUw#KFjDeO9bVE5q6q
zj6JY1a6GUzPz>w>bOIUxU4T7-?!bY-3BXZ6#LdV&fnLB6pf7L+FaWp^C;=`7h5|PN
zCj*m!Q-Ozp(}0(OG9cX-W&$a;hF@ReKR33<DU!Zby&pDS5YnmOO7h4mP1em$TowDa
zn_af4a_8EgEUIfbO%?L%OYku>e9X-FVm@YukD1|PW_myDJ-2o9$*0{-8AeH)?jI>*
z#=Laa+3_Z<!^K`6l1uF*M{l~tc$&t=`h1LiurmeEt-V;e#5H~!bZ4$PH+s5PUkhe>
z`0(8$Mm95ltvsr6&z5syw&MYFK6^ik4>NEdGPuaWV@%)1iESS5kG0--?QPKJ3u#xC
zTWQ7Q2k|j8e9TObNqo!<A2Z_@V6H#tEyk(ZQ$N&v)B0yRzHgRoom5p^=bTEr3!8QZ
z7_Jz-YEvyfW`>WM;bUg_n3<I|s=u~)<+XTgTwZqF2#odVQNLkOTJ=zm%~wn<4|FO!
zxM4>3y;YX`Dz8v#x$T9`g11H57=Vgr<#MM#tsY+5JKOll;2m*+arVQu3*O(F5aQTz
zee%NYyM|&g<N+(UY@g1V;=T)(Xg0}vo3bm*Y)_AmRfV>N2|h>pm>E81X5zlt57MqV
z=H&)sEFFWxLcyYrwPi2E)O~XGOLD4PUb^(c$YS@(G{M{9HTIvH+HNTZ>kV1C<`T<h
zZCYnHiMI{)8RiliJy$kV_tRTGW@ds)Zh^J^&)$5@3?DPY$IP^{N-{d!Ci-0tJ_Kzv
zr2eICj8#m{p3+rn@mI6Ww%>GVGHdkuLE3!GOrxOEJ@t0Ae*Cuk&-Xju>|}QCuy$cq
z%gjv<y3+;+{IqBl!wkhoI-wx9Sy=v1tqarVby0~wBkKBO!Q52WL9zXQo{-1K%>0u6
z_;IOCc&|(L+Ii3KNA)(1esb|A&0W)UPdA)}Z+iH+DHQy8E-OA}1|QP+jc0&ofM<Yb
zfM<YbfM<YbfM?*plmWQQG2{Q<`Tr%-03T<+Ng~PrLJUA3xqo>9{2gg)07CJZov9DJ
zigzw+Df!bX!A08J*GD9EmT=S<J9~%&`atgY=7HaZ-)T;F%Fmzy{0UtpQcoYT)YI1o
z>EI8I^9rA7k*ANy)yvh})ki9!(+Xeo0z?W(d;<fVUAc1&<!Kb_22lPqPdj{T8F7%<
z(@X5+1yRIk)K;Z60?1Ff+;v5sQn`P%JWWOG2bjUhmb)e^&ie72!oQXLWm$h-mJ=?Y
zOyq+snTq_hDNQ=kfJUZCAm^7%<)%5_NngYWh@1l5+*|`hisG<-^yK4BY3slyls3Fv
zTAF{pGHFebHXLb>%F_~0|Hs~!z}3|4@9!K`B1J@|BO!CMCRCIuQHG>AO(&x9bkd-5
zN|Ygr%#tY?GL|9pJSLfEG8IYWO+}^uv(_oo%eCKo-T!^>{q6O!J?E^m#_w8tx7T;f
z`o&m@jx6b~d(fA$5?}gk`rC=RGf{U^O<mI8p<nb@h&n`1xk2!k{`UW(Kcd538?Rs!
zx%rXW;i`wL4X(?WfR=R6e!h>9P4_9mA0%oU@$cTJwYulHnQHDS>Akk5fppv@H3K6$
z*yMg8I@oH!oxt`$qJzB&m;nSkj@bu<J~Fc(*bqo`v5SC*fF;1gz>mPAKx``J7_dI@
zIItn`B+v?Y8aN1e1~>#rbhQ@%F9H*QS-_>hY+w@bDlipz9k>lhbh`HeZvl@3iEeib
ztSiywP6FNsHo`g)-EHzrc?cvr?+|a*tdn&8%4MN<jXVupB&nbrS<_}fvaZd6ghs^w
z{?<MWctI7x;n%#&I@*rdQ@6KAaO`yR(>eFHDOGlqwd^~sz(QVvG0<{hk%k$4>%?f}
zR;idgS!MRnam<MIx#a<4Jh}$m+ty-Y6NZt;gN)A`+Q{U%VZqk8^AF69?vj81X~V^<
z7j`VXX>48EVE+9IMPttI|MC0<`O6Ph^741{FV21uJ1uOjV(|v7X=+PCzqh6)Y1*ES
zDkD#8$h~a+=9S&vnb$AXt+Thf!aO@^Nw*$Y4_a>i_OgR5XTFbqp*6~FaDTnZ(OYhK
zFMGZ^z^b!pVOqJ`I6U{%NPDiW>)37Dq#dch@YLoBEsT4HKA%u=c-oxXvv!2X`d1Dc
z!7x^|T)Vc0mqWJ}SsZ-FJ5r>u>Y<T(f5v^l;j6C)j`7wXWl_%Q9CJFyoX#<)bG*Qr
z(>ea{);Yd7gZy2HJhyMz3irk~*V@^8oA+@~Ow`cRAAk7Pmdov$G3`HeDZ+bt2U70r
z<ozjbYC3&)?n){ediTodvhll2dz7qDPYCk(blb6?Io@q(Iot5thk7@;xpc*atXKQ9
zcVw7!cT{cg@!zSNybmuqd|uSytl-02oAvE#p4!#Wncqrx%id?+eE-A?Zx?kcnbu_i
z-koT<K=-23@zru~nhLZ=s^qU&b1`;K$Yv&dRA2{-^WhWLU>=P-lJ>Ok`&XwX1@;Zo
z-`Z>AiOEY{r`w*782sSMc}8KxfsMQHQrVZ53z?$cNwPFvc6M}T%TYZd=jEHnUsYC6
zPF{2(^<-?f@y}u3Ma#XI+qt>Qql^oZ%YK2O)fSHC)4I%TmLz&Nbn(z9vv&*dGB&C+
zok!1yNqLi}8Jgy#W!KGCl_?zbEUAlK<_z^D?M9Iuc#Rom4Q<cLdXS~Xm|QjY`9V*w
zy$?E{a+n!;Jhb^i(KYqxl|uqxBYTIIlRLbsi_^>MyBAvg-E@=fG|7Aib#T2eSBK|c
z)UaK$r{S8)LeVih&4KB?>su6LR{4JNW0*Jgq+F)a?rtx0_AOuWCN%l!*|NUJ^)579
zbmj70k5s4IJKCh;1^!?sQZD(>&7wGu>^G9&;^uo#tqq)-aw3(tVOr^n<a!gAj*~$4
z`GS^vmzxmXy6>l6EvD!5*1UJk${TedDsP^i!Lpq`XQr=Q1NnSAx*od~j(6}^mY<{O
z7ryAAH#1v#*0ejlSG5d^f7;=;RM(kp9HbevJ*`oS>EpMAoK3m7tX`tlqd|(Z_6**)
ztj<8qxJ~OMY7g*ozKfO{pL;j{g2buI{!Rut#~XExP)eG9CAE`7<i)+)l=o-9#2jAH
zay#wnmPQV1Gc7E&OGX>>g*nfH)Qeq@?YgG^A@S&v5j)&)R-<%Y<$UORO!S+V*{^c!
zg{MYqK3sQ0ZCLOFzim0&pEGrv;h+*t%Z;6-7jrCC`2wfI%;_-Cc1~O$YvUPMrI9|^
z(8|_KSQ6gJ<I%`V1(y2@a8Bt)?l%Ri9YRirnbTqBbeK6EX7W6+${eF#RxGaaHqxFV
zO14tmS7+zphFga+EvwGSkI+6o4SXscQZ7u~<k5&;dkc&jF1dBSyxzKX%FZhn@2|=b
z*E1`dediPyWX`nQomV+-Z#DW{Q7_buZ|-tsyXr`XZ3ktN8$}8->*STHK4X|TTCT!)
z`x{P&nbTqZH9u^cKG}c#)ge^})8+leiVnN)_VAkZBup_Wr(4mgL+t~64{LM+!+1L_
z$LTQN4?pdC#qMPmr^C$YFmpQ0qFYMV(a~0Q14iZxQ_LSrx>+inO&vTl|ISjax+TuN
zAaLSS-DFOOxmU=g*!Z1ZH@3#r%NziH$qdL6A=lVsmv&^7(ztaiT1}CkQ77zF;km`{
zj9au{>|$0`G<$;{<WaO-{>Kv4|85;-h}XEpQGlZWM*)rk90fQEa1`Juz)^ss07n6i
z0vrYYmK1>cAv2^#|KHowXNpkdBlL1|ga3M`K>Y6%AaZkZ@$;h}#Uf9iiGOnU4>e&w
zSJ9LjWq)JFRGEi1>wliDBK7xQ?>m40!(7}%zI^k50HHS&&PBAei0PxuxCOa0tOvpf
zgN2N{v6F9rli1hSE5K>0o6{h89v^FH;1rC@+pDMLSW5<zV0!j+^3+9E?QmTJyh*3E
z{?<1^*Ow$ST!bbB&qB%8PpVs8Q%kBt57q_~2i+26f*>`%$!qf5e0{_sUoYt2*Hey`
z*7btBavx!^nC30|lIQO0BcyrDq<QW&#c1A^&v~>MRFI{<x8I_lnlaHaLWIvirI&$N
zgeIb|OvZl(NY>yiP!@O&NXAX{ljVUIfKZ*LdddnwqNm&tcnR1DNc5Ezf!Bd5z}rCR
z5KHxwfp_s8>Z8m(Aki--ddlsA4}ee$Vx9uY*b0GNfv<txflx1^KEdArwecPEk$~+^
zeN6WTLfuqi43vRSW2hffU(!&OAwItug=oT0QfU$*+L7k4eTTxrn2tw+R2yDUK6bUe
z=WvhMqk0DAd!dVLL(8pIi61!EMEA&t_BIjk%CqfX9C*-k+nezz={Hj+&1+ko2VeGM
zNP8J=SJerwTIN5lt=etf&=&PBEj=~FzT-x@<B1R7Hwegso(Y#Y3UCzQD8NyGqX0(%
zjshG7I0|qS;3)9FKml@A{LA+LFbJO__N7b#Z&&Fl_)lyB{NOHhqg(;P6OeKKd&K~h
z#ufxyLr^;d5-UwZ*&f08e1ifITT4UP$~Vx*U21NR)3=7QIeg{+<1*IDkuARP6tZe~
z3NYKG_SLGu8_;#wNze8&q-T)m*S6KfmY<y6hZ9@=?|2R*524&du=}Sxf?C_|@;a!1
zl!`Hsy6b`0(09%^eG9xu8RCNgY8XFC)V7;#|HKAd39U55e|}!RZk|3Kuu75gM@S4h
zGFGwhOKd=5Pp=LpfB<C$fqo#hkopS9!B~%B{N&7kTgnGPzSJLq7<oVP6+r5g)YKUf
zBDIGnbx54RAJwVlr)Z%)>3YD&06z0UEW*Fiz(vv&@FVI0K`04XKQN7`{j~(2rL>gN
znA9VD6Vew+;B`=b3)+`R@Ey~XfVV+okuex6=q-^28UULD4S^a!n4w6_fKVxt3<kOY
zqkyi!XrMcgtfdfGg7!$vCs*t_J}+7lt#bEW<WxahLCmykX+d?ax0n%^yiQ!N?dgrd
zD`y^Nm?N}Yk*{uxi#L;Yu2ZOZ?fh1@k<ZFqmWq}~9)}!Ajn8YN@6RyBwA|b(wcsqR
zz1K`*pO&gUNpqi+o$DN6R}?2dC8f9HFtgU|?Z|aNSUzvgnOj>9d~!6NF!qo2ej>9w
zd+)|=kPSYRV1HrWn#*#>@gQPr2R)g#7w*3=*Y^DBo<EQIl!Gzyd3(1vakqaos9Ja4
z)EJjyoqSQb{*wHbGCQw#^~zLPIocXF@nB$quXJ6wskF{JBkNJ4OQ$zkI;PUjvD3Cy
zTFbAM-syj#Vg#6IzuT^QKkfIjxv=tB|G3dTy?V^3yLyj;nxy1n#I$pM_vUnYxwLTe
zD~9=l+G#hGv+8$fT!&4wdfI!g?xpoW<x-!F4f4Eam79&a+9&qd4xTHW@8wNTUA+$|
zPg=h8cI8dS@f9V9-o)i5-Fo&Sa%$3`E5db%Ye&nuo$0Wtb8(%cwlY7nZ`QFObXl=D
z)#8>>qK9&+jE-T03+2!M2s_=kh3@#wUBQDdSq8$fLM3g_Z<}%_#$=S(bpMqkt-QFs
z_bZ1!I@*D!qHnOvBkw@FMff{I+cUHiU(QJEeCD{V#p#8EW%?OaBu%{b*3I;my^DR!
zslo;D@6eX?Yx2j%Q8W4voO9SDzw`Lq7uI_pyI5|}8l7l5R{Kf%mdUdiCW@A`lugM!
zRnn&Arbf;B&*-O?6yJH;$*BWcbq<a`Soc3`x4fFp_s)=9casO&e6?Oxs(O*lEtXbK
zDQYvn?Tf?VdKT_=CtYTkB;3P%-rU{`&$%`$GwA<GdDy1w)7M@JEWCAfK+m>Jx4Da=
zZyEK&GZl_HV81E%sh|9EXPMy!S9agE7&jy8<!z&fdO@%17e{KYs6X=@!>p#|a+wqP
zMO_xPeA8}{<r$ak55pr>?!LIO=1BLh$zCom`{#hyOUunWu2Q(%@ztF1!yDUpbkUi$
zex`?CdGgHIRlOpYm-Dh$fgjE%{l3=Rv{_j4JM5s7X?tTAIy5@6**ji!%FRO)6Rj72
zh?qZdqw3SucPfIjs`Q`XVS1mIYu}{JzVn9l-%q<{p~!4pr0LenM6pWWdx1jN&KfiC
z%}K?+Z%@V-kzlNAR<uahA$9fT)0+a$8C0yCnKZg%S@@vatFNxBz~9+yS}xyUgMVd2
z`KJ@v_ZN1^DjJtjHtthXE6?;DLn<abkMcIhGnkfpUS8*&=7wiG?(UXL9QM+5sPXe0
zyI1W}d;I(CpvThr7Tw4UsMuxx_R9T!hu*!+_C8k@p_$dZ{i-|i<p;)AZoP?Ezv^VZ
z1^F+PpE%ShQY($#<e=R#Wsstmu~tz<a*x6CU6gml2I0P>^RRi=eD_rw%gd*)IXzDw
zq`P;hUeyYt#bF+|M$4C8+y4Qg7YEwj%&exb{WO;--1-of@L}$fC`YT3{f7)EzwXs_
z^2)3uW-}0fmzI+~t*rm|w1Z}A?<?p)=yyYu&}?*`yJ~@Wuk4-FDR1)3k|U<X6rTvY
z^vY`Y;8iNW-wv9sy{fkz8Q<@V<rE)H+Vgt8^+UT`j_Ku%VvOE~2qH68ERPqRxjn^j
z{k=AA*NR}@$JVa;KV>gnqDkg);(5Zv=RV<U^6r*84P87d_>q<Q>aBOyD#r9nS-&8%
z9rknkE~H$$JsW1ZpK6(q=pUA_Zl>ZA@dabG8GY{h>X&S;_R!La_}{Us{@wP?Z0*wj
z?)J@W?ahC;9dum?Jo!Aq7{78kKm9j>$3o<z%wF|6_PqNsXP28%)j^wk8R&#9gYPc7
zPakBIZ^%eZZ#2Bv!N~mm!VqV#seA8?ePyjxc=rC9HpzJJjG^syu}T=*Bs6eG%vHrn
zRi@`&R5S^&%ze2zXyGQ8j;9ZdJOO`Yw7pHHy^@>cZ&uiR=al<%rea#d-YpN6?rkg|
zV-PE9bs)PFd}Gma7uDtn*PAbi*V4GWf2Vej*QH1Fm7J6!4J%9ksvWcr9p4roHGZ=b
zr~1A1uD-jV>H2ypa)}Ghr!9;;&~Zw~$S(bp8Ag-Z4-2z$JU{8_w@fXpzbtFVIA30D
z@s1V>i&sYZ$9G$1x^p>VIMZ^6Q)I6U?`c-2kDhgA|BH9#yz_psVY*3UL7L|<en)?`
zVulH)<ravajN<H;ub<X@=;;_W)?qK=BljTtFSyFlf5V!rRjrjLOnDcz*SKwZ%AnpY
zIJ@Ql|8~o(>EH8b!7fv~4z*o3Y1N$NA#>CsCh3k2$TgiAG0Il7bMfhOxF?VIBI}m#
z<n&0x%<n<=fpZHRUC&x_vX5f>s)}<OR>yh|9`Q0d209Y7+)AIr)AyzK$}gB=n(rId
z>2;z<RBH{F3V*-Q6HgMoWS!t|4a^5VFZaW0LI0K(ZXF*S9pY`%q09W&|E%3|6EHFO
zyo2S&Mptj^TC}UKD9_z3QBP5FDR3zpTsfjV)Z@jx)IPsIMpHl9?>zma9@Vpljq>fA
zef3kK+oKIpL#xl6JKOfsf}*!QBevsR_Y^I+v`tG{E2E1BO^0U4PQBPGGHm3<oblqh
zc2*1QTk0Il8Vp?%T8^_@o^Ml9nS6QbP1T-iiXX!nX1p$0-<acW4UUGNdL0t{?$o`s
zk`|?hK3Hd3Jqfxf8WE&$-GX75b+lZLzfykLvK2*TMYqBQV~6+6Yy2*I>>;(@!~B}5
zwaC~AM%8UvZbl1PkD!WmQ=cWiKDlDc@pgw-o@u@A+TX!$Ig8$xk9a+AE$$YrY-q1J
zY*xO3W3zdur!OAoR8R6eV#%3Dj_Ys^1+$LNdokdw$jc(YyKI1Ex|{8NnI|i=io)#+
z_zQwc)i#{il>j~`wI5#gv^W1l;ev;^<+dgkEAQ7GuduF4-700<R^zSRb4T;;u=nG)
z2h2e}k2gBBns>9^)<YZ4rEJ&O{Kmz){Rf|!Lna!}y4K&@cm|&L|JUrBpHjLE{9|d?
zCdyA!(sXt$*sc~eY-h~B+ip3vH(8Gx1{HlAju*90Xs9B4%yG@gG}Ao&{5kPYOyzF`
zjeTDMzRG=Cu0r9G^_d;~?E8K0*E#&))=Q^{6COG_4SAEw_v_j<aC9hK_ZpJ+I$l|o
zynJDTetvQKydc$O_ex~8M=&Gel8x>4?k?5ei1iJm{55}f)g^Z`mHJK02*1+#&dLY9
z4H~<+ew^oac~MN?16!xNGK?i{uUyIb>fh6D`4he0Rvo!Gzkc52kgjKTjnX!MkmsCv
zy2Atw>xO3<T)39T+ykE`kkU`RO_Jzvnu?9riY}KnDJ<BXQg-v$@i|9|$1NIvwtbg|
zg$&c*h|o{&LG{c+NpZJklX@S_9=;?|@@dV}u5x!Dh8>@reNk@V703~2xigAQBc_+n
zj4JCn;*&UjxP8Eg9_q=#|4#en0Z?S*^K|UD&3SJ+R{qGa@v5&ISIr%4*`{CT<5lA6
zRZnwMH#Gxag(y7od1q|mKKRy~{_s#;@!_dXMaGZApAPBP?);Ud4gu}oU3oSTx|0wJ
z@Oi#*o9|6pJA7b7ltMlEtF4MH4}^C#%pDdd+jdBdg+O~F!}J<S${EcsDeoNG_TJcM
zttUk3zPO(+wp2ebe_2wz&7$RM9j*Q07mN1$_qA{C16~~d9))gL-A+An*bO(E;PF~^
zO4rV&HE1G!F}nM+(wNO^r!L~XiPEKCyNIHXSN#^o3_iD_D?c&o<R7tJcHKU{v@}~h
zqu{D0`25Z2d>8k)*fzGb^RVFsTMiB~Qub~XF~@(TwQYFP{5xH(>P}CAJj|5z>-V_l
zo6}~~(~pF-zkNUF{(Fbws|AUZ&3Eq998eTyB5KAkgJ?NR*`tHk)a~6cS9M}m^0msD
z*-!sjJ7^s$ciA>EUCksR`{;tk8+RTLAJs4R<@?Z6sh1j^9J>6#<>#-#ANQc^`)hmY
zc-mgjpwY`sb~Q>|b~$dvs_i{gL=~E|dP{Dq%zSb8?6~fe@pqbSY^de5-w6ql)<vqj
z0@p9i8dEJ7B0J-H<-Kz^dgUJ!yJUSdSTPfR?eGrB=anRStZxx`ZHSLkoj+u5w+an@
z=af0{kDGY~{$10@WOSbo{yi;cmz3>)YRRo>N<(MHcnNRc%xe?+y2t9F?#E?R5~{}d
zD*b*x#CV0_QVj(lcKhq{{~Ch;vB<?os#G8BEq3yCo$MhJO22#fxrs$yU;F=OoWIEb
z>oHBKO@Q2YHUY!^#Gc-sq0p)4_xJVo^CWfwiVPSaU#0qtwer<AINLBv$|RdFBmI%+
zkk`khjq4Wf^J8H|1}q~GxOs^@`~<Kw(4lf}GT$Gh&vI@erw&Ac0I`cWFo2;lb%UC|
zYUTO%_#NV2>U;e(&R9%%ZC{vlZD+_Pa&=Pf2kCQv<ag4ak1&Xk47&ePzy2go;O!DH
z1xWI0$K~tg-an`&uhwrr>e9TgeY+dhK_MiFcqm;UVq)s!Uh=D@iw7ahujnH8d7QQV
zi@p8&<IngvblFtX7uf2wFVbfT`f{FDLzjs{vB1MGKqT$%AFRWl`x6PpQ(e5i>yL*H
zknk$akaa(cYX$iA@wNR0{JB3q%G4$djZu0cgE<VM^J~BuE9YR{n<JmtZFHtIVl=F6
zw8?g&d7ZxG;WY54Je}ISGCBrYmkf>8{VI>_7OKne)w&NG+kYe>Dej4e%3@$Hwmgp!
z2nLvs6Ij}qTUc8Tp!7Db*@xY0HZj<4l-^+J(fK>q?n5$vvVp(bi~nfvD`Jn;jwt{e
z?CU-EqkCahO=Dz2<i6{Ui`;kdwfpNY_W!f~YVC9C)<XwKO>vR_8sj4UNkXN2jNazR
zBlp~o=lSj4A`g$R=T+O!rkZ|w;&(z1LSu4|uc_^a-s1o0-u}{0Ej`)X+hjc7-`gbb
zNB6cKApp`uT%->-Tx9>htr_E&<(H1LA%6dJl8*EHbtm6R+z-5ZF}T-1?*p<gJxK-<
zdCt_*YgNrynjoKiRK!KrC8u^QbQ}Kj>(T`G#3wxO!`71f)psf}6|2pQrFqcNLgqX4
z>x@hK+?PHVg7IA**C<>hDZ{3Sj8O$h_D^%5Do_>32etrq1hxcr2DS#0eb5d_9t8MX
zLv?>9;j{Fa4_-Asl71TC0?Umi9h4*MVgMv-Xb5ZxGy;<Q#2AQIR>lN45NHYnTZ-ui
z909Zd;#G_34<z#%giHF|mOjr(e`Fqb{iNwOZUgfDE|ARY0g&7$4}oNUkAUR){{%?d
zBYjAp%?v}H*`z%@a+m?QNJ>LF(%yC;X>S*hw3iNS2E>t6(i*rQNS^hXK+<kJxunlO
z`fMiclKRoONIHaa<e_*3XaPJ1B=bBD90xoJoB%uxBzyY|a0T!ja0Bo>a2pV>{1S|b
zmctmRt=a+LW#pp`<_hpE@CJ~K%M6$F*(klA$+*aEu7``HF`zS<uLF?mUq_%Ca6GUR
zZ~~CDGZvTh`6i9OLE0hfY>kVgKhPg(rxZx$T@EDl{{Z9zKLXW(RlqL5Y9QGUcv1O0
zPU-VZ`kecIoY*t8{eD2Qug!o8K+ux**B?m6N%o8Mc|~*)rRz(^Rl8qCqZ}FcIABAd
z6Oil!0g%ks1xTKIu0Yb>3tZA?i}aa8#zp9J9~Vg>C`Z~02Py%l1Igb~3I36N9|<Jo
zu@C6{X93B576a@Cj0KW$&Ia}Z&H?HG<ABD%1wb<(_Ll^6WD<Y_fQdjt`z1gd;8Gyj
z+slA<z~w-4@2>!2&P)<;JTMuExiV{jm?N_m=mtyylKC3ql0Lu4vqnn4x<I;CK+uY=
zLuVkl@3EG2-+*RRCoi`dbY|M&dBIcPTYu*UdDq3AyIshu)Hfa8EV<#M^9lmB75?3N
zRgc)ykG)PATOZNaKx96zaQU{1vyX?Q#<bUTde3ySeULtOVwQK<63fNPJ<Vf=-NZma
zST;NdF>Vq*uUuW+X<fbdk8~y!ss{{Mvq)EKO!CoC=YTz_ulYOojo!hYN6MCWXQog3
z{k3mLwrBOaSUf(j&C5&e{@C>_dvlmj5T53&>Urfwc<V*!w#DB4Yzv!tVxzO=@v)VC
zJ77aYm!rkloKDQF=NntUJ=Q~C_f?^{&6%dAEtZ7Oo%bn9y967Xt<3#6ZSU7IBDTKQ
zez%N#ET7Ex*E&pWbvW7bQrXJV9fV|jGTuW%mb#x#(Q#Ba`#AdCxn42p<r*(~*-f(V
zUOcOKIUYX0Tb8~-i}d?4`bquBsy_LqkB96`3QTewzJphGb8@hAk9BDa^>z;{fsQsF
zCVXDo&Fh|a^?kQ&TS#4(hG&&DFKpf=GFoB3YIB1ojasP{;-M5n_rb4aifm=`Y-NgU
zd76cIp!0dZmbKoc_xZW|D>RlK+TI{O`js;O-5BSTz_W`(mTI*gE;Id<b^HQ6#M$zS
zqHRgP*Bwvx?%E*jg4^>uS#6dcj*oU%b(LMzC$4zNlP%W`6?E}801tWS2CMJ3KD^0d
zZGdOYAM=u4jhOme?QIJ;Ig7QOj~q^@E9(Q@aN1sC<2u8I@rP!d8P;+1#AH<q=99$3
z*Dy8gb{B`_48PU*18PK{lWha6+jQ!f-*UsKP@m!Mp|Nq2VckEyFEXBaPP?T=n^nc^
zeay0z;fvanc|3eFy>pYy{O+l9%m(QNjO1OJa<BclEyfShQtw?*_prpCx<qvX_GO9d
z%{81mUs*Oi-s<7-r%_vW2fgj|Y0fjBr78Y1*KWbzJGvgfmSKg_^}SuTnmK)^*E;=4
zm(IJ#rWVWYiE7q;?|7{=k4`cz+i2#omrb$N`SqsvkwI161HHFgHnZN}vpRGAEWJH-
zmix-CkZHfYz&7E1iADu`oz?sFdG%`@Q?@$xY-6Xem0hrv$u=<{`(V=5=s0G(u4b>@
z!q~=<9`E+tcfJ(b>7GzyL`uf60Y%F2=Ro)UtDN`CJ!Inw(hP1aE*dgV>#WDYp6z2F
zXRLQk^SvLDg?F0fy-9m1jTGNse(CKt#Jp(5Qt>Jke_^@M>(T4+?@dlv&$-t`iM@^~
zTbVms9n<&fWPGJL3!^1b>PZv%6;@-77dtx46_=<F8NNYxOqF<MryF>=WNXX7Rwp!#
zzBm0^w!$_xj)?}DM{2U)`tC8wXYHfCECw^tk#^}LN4FXDMs|#<Vf%UUJMOU8&FqMS
z9-sGXTLHE)YG&a;0G*E=gR>lG7<ZmI!shq`7fGFUPYygj7xG5!fo;?&?bW-cv)3hO
z8)JoS43k6nTg~SgR?p2m6814E#HIW0ftA(0!wNR^wD-uFIZYC{sdeBo98}oG#&M?Y
z{n`gTYh4rC-pTiNZ{JO2wk=n?zCS%lz3yJeA(d~N=+}MQH@KPA+qbxndf;yopJ#l*
zR6AK_n@Y-Yo7ZuF>}a?>@OvGN->rMW)^>w!>?2#cUs_zStJ~Z@Va6eYRSo8kc2K$J
z6c{AyxX3}Z-<d;}4x^pHzsJFljZF|+-Bz}-aoF07u#IUMMxVQza!Z-k!9$Jje9EwP
zxie+#=>U&Y0W-R9+FdX{cWh9GAH!@kBJ=GWZxb(XC|=cM!<BsV9XH%t&aq!NP~-T6
zYhKs1)HNP~c5GuZvb6<atE+8H&#OIqcD8l=WTm11UY)Q0e8>Ihl*aP?VzxaA-@oHR
z0l)h`oQ3H;el1JyLI18+h(qG#ThH^cxt(!2L-C5uwrha{n;FPju1<Pb*4q7bHT&2Q
zk7&QuD~sko-?t^Qpln6kt%{2dYfY7T5pE($?WeKKX4T@>U|g`Z1z{UQf~_qLTiw=V
zN|#^TzOc2?Vr#4NyLD>i==<OEDFJWNc5g{{aBaJEQ|qXGkNn@;Z$C9}+YX~oxhn(W
zPvbm|zrnvVW{@I%&ra;2AbAzu!sn%a<%{~(mo60;4^Cg1#d~ijx9?<x=F$-G#OQgy
zZaw{7E1Wyo2=bP;3)^LSRO5*1)}k$QF13F)e0=z)IJ`ro(D&!G@{^-|#KtcNzaCSx
z!(#02sLPvlu4Ni%P2A<M-hS5=FpvUhdz&xI9f_7*yF|%c<HoipTJ!lf1Fv=LcB$*t
zMvdF|j_w0y(so+zrJebOiLNt0ow%~qzr5gR;*LjIfpdp{t)qKTlh7q@YEwapjM<r+
zL*%anJnroKCUbI+Oj(n0yL~%09H{$YIdppH^ChgGFnL*ev3QR5(3|G<$M%tNU!<FB
zzS5&Zx8d&T<&F)(gQV~GgLi2z%jkA_<n!{1z`T2E<NH;FCL7s|c%*Ba8#QdmTnqNL
zK4x@%Cm)zvaInxd;_khatzEQ+t?pIwDrv2-Dsr>D)68~e<7B`KrsY<Zy?lIrk5ia_
z+nDNc%bvRKt-fd5T33GSs*)+LJMU(r-*)u8y1Xj#gO&M+_nvMi5AN8q_=CxeF!k0J
zz4M+f-!y?KNX9+RR;OYZn4vgNw+SyArhXxMzP8ea(*m8x332Cy0~ht5J-Kkj-jPMN
z_`7<lEh(2dF)eh+4BLs0XWFfu<=Arm5o3FI{q9D>pygRbql%lq1TU~7DfjCbdu)CE
z&!gijw)S2Xn<uWcc2P3bIqf%UUz6QwsR>10U0+Nv7Z{~tZ0E2C@ptfY?%DOm!^S=7
z*w26Bhi;0ZxPn>bI<vE1-k5R9QPt6hy^c#)FemxE0f$@dX_2pWKq1$%WXM4MS*zvB
zZVcJ))FsL<NUlj`wS>KHFk9VQ75aCdIVaAHT&vOZ*{c(6C%>HRd25TGM~|q6Zz{H4
zE||HJ_YBYH)?|FYwozrPo5a?p`MwtEciG;qrz<QHmb7kJ`2P6rJoAj+AL{Z)6{q+d
zu4?qkzi=(?b9z3ioUu9l!P?DFXM{F5(6n90K&8;a*WDjHX_A&%{vjpBXd1&MjshG7
zI0|qS;3&XRfTI9M0geJ31vm<D6yPZEUqu0;*W^*-{~wO@U9_~F1VO%{DNg!M0ZxN`
z#6pp`(A^WB+2C4V>SEu^({-wwD9{JG`of+*aE~`t=qK`>ED-e8H!{-IGt|{4rU35L
z|319cxlIy%Z3n<ZfAv38NRes7*ag=4&JN&5u>qdc#s>J)AW4LR+Od%^1)m4!<QnMd
z<?iI_5+J1B3BMk=KpN;kSEn|Dz_$}8ZPo@9km3O0RBb&cS5F_OU|pTs*a9T_0EsQ|
z7sf<duJM>y8;*cbh(;r*)v4`Hh=kM){Iy!-nL_`K>UR?tfT)5Wh|V<8yZbs80ny(D
zJCNbyBBj)z&wldjdPD~w4)=T^lOVt4|LHeZk<eud{jL0)-+X*))c5IcN)bfwnv6x@
z?HS<W<vGzu=#D-~n;oUUdAoS}(4L4cx=2j)-s>rAefJxxU>^09y`=e2_xB0(@{*SI
z`6f@`8eCIWB+d6A?ioogX*Wokhbap@0|fLZ+HSHm-!()m6hOpA^EQ5!2k{)u+xAtS
zc1>Q!S9xF`QN3q%^z}(f7lFV-<m-*ei3k<MAWzN0yhB+z+*md1^?4o1a;o4W3F37L
zX|p{p=p)nA9C@<%qzaS=f^|;y3c*sQdX-@DQaxO-T&W%|SgKUN675L9N~AspNqeMi
zursMoLFgn>pMt2%Ky*#@E5Vwi`pno;5<-(9K-6J|0`VKsXO%!Tkr@W;53~Ue1P%wH
z4ACE!;5TCbB0(PG0JH;+1C9nd0_}m$K;%(hg-*c9_>Mg4QxU9k>Qj;I8E@oI1cJ>e
z0g(2X>vb4r5)iCo3F<KzhXlVf7>C3cI0)zu91O(PqH`eogUlfUNai2`k}*dC$(UyX
zZGkaBj8`%nNaipXI0_gC#P}tPfMbA*fn;t=fn;vWfMjkffS8X2`lJl>NhPa+6M$=g
zZoqXw%uA9A^Z;%KVt$gXKu_Q{Afd$$AhtTyWhOMpz<10|vJdD7%mj*n2Y~^=Bfvo5
zDd1G#8DJ>zB5)e;5-=Qi6$lzgt^+0bcNZ85ybp{9J^+Fil7~RhLh=Y03w#U&O(ai%
z^MKERpot_8I3Jh~OaK-D7Xk}`pp~Qum<W6e1kI=p?Gj)KzJqp>QXptY{a-Eze#Cds
zP*Me434|DsSp`JQ52~Zf1FpvRdcb5L@sqg*C=Xl<Q~-j;l19Mwz{bFhKqVk(E`gpu
zvk6G<E6`rj47dddeSZeDmq5Rt>b9!^u?CV>z@0$o`%_)_HbAU}gb&;UY!BQER0m>h
zBprbJff_)pjifX15Kt3%7}y1fwUTrN9t9FQV81fTAi9!FSV`xQPi_;#!$fAP?YBH}
zg>JPf$+uE(;}D@2vF9kyBclE`@dwxz(DJ8CmnNhnY5L#XFEp8Mc8iaOxWrL_qX0(%
zjshG7I0|qS_!lTp7j?&dIsYS&9uDv1d`oQkS;yh~#`r(TEx^aq%~xvv|9ABL|Brq6
zv-k5~>x00rj&uPI;(bpJANK*P`3!T6o*!idwFJStKDAG7Auay>|J3G<_^c;w7%0IW
z4+ly(Lm<adYBS#O+k738Pj~<*N__~p;Xo|L=jIGg88)R%U5pFo0_L{#9823EJ_AUZ
zANkNHb%@^pQfK6JdcLQ1-u|MFS52Mluj;(`Nu95K6ujV}BP46oCvzSIJZ*{>W}JeF
z?}pEGLzn_$*KJ5k|LMQqNH+y#6*T{S`~t#Lc~&zYFeoTZ&f)uyVi$-phcL{G&~P!G
zhji`!5#33hoi%loBH7WM)Om(F5$I>`S9Sgo-QS_CGcM`A#MuSwJqU!CN8Tu0B$4wj
zS&MN%vQNhY$$5AJP!Z(?z}Y|-U^37Z2s3PY#wYupoO4M(vACq`C|zIDk0SEIaFK*f
zP5aRUl6(VTGoUdr9%uq2=RC3<NPm5Si-BgqT|f)q4WK2k8E7#K$Oqa0^?>A@Pxg}?
zumtUqI0<b1>#();VC!Fpt&S2~TLred(`;?**v4JB+Y)?57B-o`J5E9$bJFjx{XiX3
zBjtYW|BP)s1-7;nZ2k9VVGr_ou9A_qgU_^@JZ4w1{1Jn88rStwH)b85-BvlL>y$o{
zXV|c8b>!IU2(yiY!PXXlZM+P&@h#ZeezDcvXRGtc)<&DHZaiC^e6~8}|Ec&4WBFvC
z{@R8&nU?#tF8h62?$<VUY<2h9>b$eHjZA4z=KE_MaJKOy*v4I88^_^)B|ZaN8#}f(
zlx%J6WHiY7{=Rq$Yr&W0^DfL7x_bWN`E7&q{wUqyx-BBnd*0zm_si|)HxJ)4>|@nK
z_BMNL<5sY><zZ{9#nuLpt!_M98#}hT;%sfn*xD$vjlaRx=B!<3vJZAE9Pi+-EI&ul
zFMQEKZ)UdgtZ8?8uWA_-|FpyH-XVSv7_jy2z}BY(TVEh-ZQ|J4TK;Zd5o~Q>es|mt
zw!R{Mw+{%mz8%=ck6`QDfo=Q<wl-|P+m`Hi+laCC^}^Oh?04IKvGwi1)~1WCZwIzE
zdu(mL*!qBAYa_<iX9!zcGPb^V*!ogo>wAZ-FO}aNpMkB98Md}iY~ww!wGm@&GY{qv
zZ1FP3=$93XtGtc0r-+iR6!+EHdAQ-$p-juFbMhm!kAuOcr9;YviJLqc(Q9vkQNty-
z&X?C)w@%r4<>LKS8RB|oWwY;`$_CGimix6$KU<q%wmt{SXurSD_MfdUkl*bifUV6f
zTOT-VeTuCGbCAz7jk!1f)%_=}ls6udA8_N*bHz(@FUXnna}<v1+;+OcSuhQMcYFr6
zzQ_Kr#a&<<kAkg_H?}@z2K6TUU}15KDvA5OYR4gm8(aFGnYUDQ)NQG4-zYbSW7n3X
zXjZb18^G4b8(ZIFY~wim-QzRJ8xcDHIzB^xTJG-~cY&>+f408N*!oIj>l=uzZ8KY2
zbGEkdY;Drn##3M$kAkg_Mz*&9Y<(MUh42XRv_6)o{*m+OQI&0^$t6dP!sqv9_A!fn
ze6e}!-P60DQkla({y~dAq`m+D@ej7rek+2*uX&esv>mahZf}p^*y-k{bM9?Zs_ZCh
z*>_rjg}j7|lfZC^qX0(%jshG7I0|qS;3&XRfTI9M0geJ31vm<D6!;+p{tf#7&|3e$
zrT>2&ddMU}O_iyKs~@hR9S}n%N~*_ROORUqfBgKT^o<_7`A_u!zsiSn>Bsv2U+dUg
zLr0vX{m_LbdfgeoTZAt*<GZod=-AilfzwJ~{`+lXBlZm{XqSzSecDfS>~DkKxtIsh
zF}J1j__dBbsiOi~kUDq1s`HO*8%Ui&s6*_-U829}<^M{@eh|t_*Iv3Oi0*rR<bmuo
zfyNTDPeuckf%ZVC5|Q{)G%l1QknAC%d;bnd#w=Yg={kO|OWzCS&;`}0C$!bYcc?;>
z_*T@;AL0{gOAh-9i8<y3_PvC}vNQp{0AgH{7N955v5y2|{E~UV!N4^@YarP-M901a
z?Q**G*-MV+FUVhhu#%U*n}2cki`Z#lYZZ$(;9<(?(y#8N^+4rPpNtLiyl0i0jk?+=
z_SnuaoG!gqUfkaMl|vsL?Z8vfH`wKocc2{%YdBr{AN!f-bm=E1S}*<(F@NGl)u*fP
zR0L;L=|5`(T?amqL2<hDRV$1Zhk4u@Enj+V{|6DnaJuw&Qm4GhGfR$`5>tF4?9wZ%
z-Gf)*W#I3wOP@=1>E9}JUfZ~9u2Csp&HdK<*4@_*jL-K=v$ZHFyS*pLI|;^o`=}0o
z)Zwh)!&{s6?P{Ld)zF#WN_WfNXWo4O#0zg1bt;+GWdZIFS}xGNsC0a_+?%EXt&uAE
zE7n|$ofEQ|2_F^M!Qy=Qgf-@fOWKj#N80!Ot5cH#`-bUn?X~g5<fX3DZO=yxesJYH
zqcGyY#$9-+;&kbM9PfwIrEg=tFy~p2da>)VUDwn<BpzKdVuu^-yEVzaTIGD`dQ9}2
zm)Wm!?1iUBYd&0eLv2{_1HWxK+n+Oao1KSUDlIptgX?{{Iz0cPhV7C)4cAl_ijLW7
z4ovS|-=ZM1%J-8W{58>XV`u5b97|Qc(BO|Imn)uCpV_!^V*L(InQJF3x^r{MJ3qX@
zbGr0Dj+4mg(tD&eo8IGyn~`kr#l+2NEsTVdMrAO}y>4Wmj(5q~8({NxMt80HgP0dN
zt@<^&nxt`V*J0W8!l(PXF4BSzf$pT-uj8h2y7WJef5Yk0hs;rnn4~*8AlGze#3)<Q
z&c&zCbwNB6FfE{)<>d58!_4nN_JMN?8(q&@a<Y$N`>Kj_8dk@84<7L{ItDScX}Og?
zho|pL@0DLL#WdeHtkdg6kEqrfE*1WMp(masddWJmk7vR*ek7+$&*{=zfY-(8(!1H-
zmwB=>t0>&QfWIK9RBgkFT?ybj>y!KU*KuMwUHTu#1LSn+4?no|(&^!ZhfYpI-lX#V
zx^@j59ST2~U{dpW9j~lPUcN9vKfgGAUXbdtdnGd4BbX6!$;S42cbDpKgfmV~mtGt{
z+&*AL5B22W4mO*N4|a+zeE~iz+c=YK<0*2w^goU($LZ2@y7Uv9z;_meW_;ezMkdD%
z3%16ce_(cWm;C!r8!leGuw&s(W9!le^Y2$E!l~8YH4*v0&p+w^&y$1)@Nw~?-u2-&
zkhlz#I<*&yg+5a~MZP}XLLc!|7m=rntC!H_>o@>1&I}{VG=;zTXMS>@ahRu@$Tz^(
zL(JE->%t%IhZqB%p>To6@9*pF=jkOB!QY*RvOqA^P2eJib3E5Tu`mGs*ff+U3BCM;
zqOWs_%vD3#MeKz>NFBrmAdcwa2j1Jo$7Q0B3{6@lK<v)^E}wu_j1m#)QeSoivv7fp
z$ehEq4no=7nNqpCz=e!wq)=@6g-~N^2nF^e^>+uk>yHwZ#n<}&e~aF{{A^sjg;HIB
zhNvOU8{^^?D5SpXG9X8v4xw+5r@K(#LyJ<sfhEYV13d$`sp8MN1eIU%v`ObgUZ3@K
z{i(EB_;NE+o;OP>6Yl^)GSN98vTCrbYUU`NdyXu_C?L-r7fFpFLnib<x74RShEM&>
zH3gCmTLK}k#+osbk-#=UFJK2C*!&FGyOQ}p$jc>!rkX%bCT)BEbkF}@nKb9Ot#sdj
zZP#a9@_4NgT<4|9_(PLJAK`Bc=eO<0v3fbbZ9k5sK9*13ML550-^cFe{I-oXUhL>F
zS6re#WcUW%F;(K3oo;~t&o)-{f68xLyIEvEJ7mwg8(=ald!yWH_1?K%vSxLNkSY0C
zskdo<!XKMetMT3=LuJ0d&%YZdYhIV$BEzrq&i3{h3zaOi-kfV+u@3Ke|0%z1Z2hPG
zr)1J>Wx2C^ko|0D7UY&%Hu7e3A-`W);N_OdJx1(0(00IwY-{7*Q|?CWVVJ+WA2?1X
zy;Hl#>(V3oN={0VhLxp$qCxrt-!ly7->pg`eXyaGt(mYSypzYHk(UZA_aj&o=ilvJ
z)L!GZ=_!MHw^%!H`3Z019lhQ`myh%Bw#&t;vT>g-*G;Z0Ebih^uZ`=eI4Hw&{@pUy
z&(hmdXSuKJ3YqrX3v3hKmuOTl3@4N3WYU~Wx@>@DIwzAZ0^`&YK{Me0u%9q_S$eT}
zj`q--=Jm(+k#S$7n`^$(qeHjh?&;-@U<ilNa+`8XnbyHWjqiNQu;yga6*<rq2BVqJ
zt5CRPeP#zg`+lGMbvT*yJ?OA<{@tcJ6&XJce>$XFyYp9;Is~+TcjehYhT;6X$zN?%
zY<VEOqhao_IN7#CVk`vO2)xSqcayo@Dm3_=Q|7=wZsryEcTFFY(H%mnDC)P(E-Bmp
z)RJ4%l!nfX@e<y?nb#)tb&u6U-H*$tBvg&@g&>Uc?*>60m;NIZAo72Y-!1?54HWwY
zirs~-ffJ=6?4+Xq|K(VK7BzBz4cJMOGy@kzcvK$#7WNrCsjOT^AeH+Mrvw^62sDz$
z_#+~JD)WcQ)(?_Qqz-Z$FviM6KHnVD_OIptVqq{e8NS%S6X80^69jmMf;~=U_(az4
zkHx0>L=m7SzYzI>`0VEEGgT-O3*GUV$oAD@q_TaZuVnj^@SAiV()khDegot|{hB64
z$l}SIiHx7bjw7;t$nl}w!AQCTF*iw1U~`}rkjVP`16u(-fJD~s2W$uAWcr*;pR*tL
z+os%!F&QN`-G3#Cvmf6Brx;u;ws$YHz0Z|JXl6BUzv_;B`GK*OTW>N97mKY!R?)bO
zvT>i9T6w1L7*a9ed6YN)s&cW|h78o7wOX$1#*qC^U84Mg<eF4gOAyBu3Uz$m4N*d~
z(RuEw1>(K3|9|YqeW^@;#)>hADi<u039eR@G@WPutgU&gOEP=ff9!Pr;EX+a4|j7i
zeZRoaY70m6X<cSEOA@^sx_Ic5*}DaJDf(ZD#m33>6SW=<Qk=DC@V;er25QD_S|?F^
zfEVEZRBSg+rq9Xr)ruJ=oZ5vi5I-3;+c|N4tc_<NC)0P>%P?HbwsFgzy6&yMXWLp=
ze(S1|DXu&3W<was#ccDo>Ck2V>y>i#-wb~3wRl@nVSb}1hT-hYxtMJq!{NhGm%L}k
z9CvGQH2l=-kl=Tx?xmHqC_VJSI@9V&&_&URAcgCkOrMkKr(_Hpz{&KzR&=?vNnye6
zl(L)0j?Xz#JZ{nWv+cVyEQAgrmDS%csOaNxyr_LbLlxO$j%!Aynda%|&xwCxDt{wr
z?0Zh8-}TI{QQGDY@|-hIcbK4I-SA9<3)j*ZPNsjTuJ|w~)7P|S7%pa8wOokojO&&6
z&fVyhe^Bg__0eF(OvGrXvig!lkM%7AuMP2Ws`CdY(}yUIOaJ2(AoBmo|FrzyQ|#&D
z1tGI2;7>jPJiL8jZSLvwxro&I|9@ErfXJ-nAk5Z*@SD%uHZfhzBq96gg2o$n9uFVY
zFZSj8&{L_G8l4=v{J`bsuNN?kD=il-iB`G$E^?}%tsrLFwX~o**IUepOI|0g*Y@<r
z;FU8EGfX@!7c^+}a+6(+5|>?$Td`_;4;4{`=B(b5n<_J3+&w$4`(z02kI-^OzPc?g
z-b~uLPNCwp^IO?QJ}Y-wDq0?S9C9EvKCg|wKf@H$a&xQHg0r;tUNen-TB`OW&3#gK
zu5*B0QJnmgl-`cR%vxg}5YY2^bI#n_a^RDr@r1E|toIX{-PwCLZi8&_p#=L2^VVFJ
zJB|%BnU)Lp-<QkDtT~xAC$nz&=)8hJZH0fgUezNwne~<X{SI+5>nkf5hO<Ne@3cdg
z(I9^Zf1iE%0V)Hp)~)m`QxbSKGd(eU;f}t~3||Gc?0#`ZzXLby>_!+QP2hZ<k8bk!
zvP1t**_X4GmH*xC#@X7*bFyeo7R||`Ph8pRUtVxDamS;qz`4V(pVoZn=@>PZlSS*d
zjj85j(VWlorb9Dir(Wz888-4_&Uo=$JF5luEp-lNA!uEhHhEvO${eF#RxGaaHqxHL
z$)Y(~wDQJ7@&j%>daihB?gcrMevZOXo!d@VINJ<%z<OlAyclp+<Yf`y&B>xUS@hvF
z6&p?#edKULU0EN7xo$}Ak5@VGmwU*@6{H#5SX?w@p4M59gFV~FKF(P0n&x{yA`854
zc_UJ8)sc(y>*q}l;bhTIb5l1pgCU^An9${nP230Hdea|rvS{&)f~%Y?di~O@F`O*=
ze_XuEO^>6%-<kqM{{NNzzl)Z(lOV`fG{s5ZDZptkaq#agboYeUe5a{yVqagc04Fa`
zS2u5QPahYt=TxDe$ak_pTieJ`-#}YmSKA3u0NkB|4Go;!g<c2(AP8`C@p2K>IR2-y
zf4<c3e;dXwunsK4rTA;V|HPL+@zY<Qu~r@gBXfgVdwUrvd0}JD@NmKAoC(DjGitvs
z<BOmGE@EF1UpgMCjlHzSpZ=G??Ci5$eOK7fyL$P$O+j9*Z+l|1E^U|Ev@_25PWps+
zfF?fv)RXV(Kr)U_K%x^+jxp}R4@xptHg0N9$Ch-L_iLRyUBCP&!yKqj@~=+2cE0-k
zf|8KA?Nrm}IU;W=7Dh>?_(D?BsX~vy{>_^9JM`RT8tfTqe(tT58MZzPb$T~ef8w)v
zY&G-_Vn}%tZ}Wv#J?<{o5Nz1D-en4m>8Hz+{15gAwv>GkJ>Q=*Pjhs};@OD(PV?WC
z-&(S#bk8E;#NEs6PK|`4{!E&GA-w*?`fHaJI4s{8y=7<iScaKK$M4x`Rj!-q3&*l&
z*Qd-=TQ(K*sz=&C`t+ufvfyyPveq^!F@vwbPInsGQj)27ZM$ux!-rOLOm91n6Ph4^
zye=Jo+okR&BTH<ft4s%O*|t&P1H+`#{ClBK>w8!2NYv`^Qq(ab?-s+9(0-frQnj?t
z)KnDv^vp7T(ba%qK2o|R2P?+u7!TLof2PIAljjFQXW=6p5-7<iELAHw7Z~xPP%o5M
zH_T)R!|1_Rfs#yJrw%8RH*^@W+@$N~G3(2q3t>vfxn`|@an&pS?cP1!gt=O6PGcB-
zI<IiMfVrV<#KW3c+S)0e-sR3PA+%qcg!c2=9<5hpGNx|Pq-|zh5r32R8@~F^VI^~M
z)A{FJ8;$=sB>;=hC5{3d1vm<D6yPYpQGlZWM*)rk90fQE{7oo;V;3{wpVa@KBy{on
zlit6#ix-Z~0#}y+;s1qre>ydM2&FpG1)T*T@$Fy&&YV?Y7-!0dFh|V6&t#!~{u)Y)
zfB*kCvHgf2zZw^QpMCg|JQp`{po^E(yI*sLr)&oPLLsg}Xl+@I-#+3WupGYqzUN~Q
z-+miv$_$4cfFd)Y=6ik0%c$jbfOSwac7`Ey8iYyVsQfvOAF9$gek4vG+?G(^eGn5d
z?eQJQe98kE3G9IHU?0$UeK>A2UGO~&h$FK^0)#(63859jymLPP{>$wrMvf+OE)9uY
z|5oNPYN=~oZ<!|D^xoFDEPCm6<wu<(`ngS1?WfN$T)aOn-rvv^hB?)i?3c`mX`w@A
z*iLjj({3#n?{85K!}Q=2x>Sfm;^kY<^Rc;|ahZ$vXNf-?Dfr{U=cSdO9PJ}EemVH{
zn4%pPV|Pbg=HmSkx|HTDjFv>HCr#v6SaEh1JMJ)y4P+vG-h`OtS!<4V%ZN}Zo332h
zB=DZ?)iAwdO{?21T-{4`(amn0odsuS(L2O%AAA6GCi^9-=fkAD$<qu?bJDWwW~<5+
z4tkc<#V&J(dXjdd$PPR>x903D0v>nveUmx4N2aXFxZS=T8xGX{upF{FO+vpD&l4s-
z_X%H<cem7O=;B$ykF3mBZ@sftF{WS2`UR2gL^vbhS<dIR+p}So`>B=*iT+^;>t-r0
z5nnJ?o6+a4uYSqqY7Z@)2!<I+%RR^_-;j}--e`ESgOU0Bg(1#fQ}^B(`^s9Y@a+9H
zZIU6^i=^c?nf6L<lD}DD^PN-f&zXv84STmdRJymZe2hV?sMUe&P7Je+mb<7nN4Va6
zNxYWE<^7zU1!rf$*;#awY1u|Ik74%WFb@6AvX_s~?{Ny_>?}?^N%Z3EEI2!h;AU2D
z--7SfLzmni#urSrlV!H4q#U<-9rwqMhT8+@+muu$U!HnXwWpdQXJ^6LSxi4=9lu}{
zbjhHn#OF=A8Xd=M*VXK`TNv9o(&OEp`_7j_JKYm%jNt4nI6DhDi?y9OJB!%T&clWm
zY&kf{NZGql#2o*T*0$kE^Y3)EsyiKg!U5ENLdSmFocE?<<&O*-ull-i)!f0BZTfXS
zUL~Gh#o1YWyy~|wX7ITcUHOSwC;y1;vg`KorKQ=NokfxAu0YPt0^&6;aTNF=1&I9r
zEB}A&^#7;2i2{AZp5DT*tpEhQ^^J^l^$fqZ0`LnI38#9B!~%C0@mDbb`Tx2N!1m_g
zH(~6#kbD13SNmtW^*__$eouA2PrUVCt+e2U&9J?ShhOHM+5U6g{h#T+|1KT(ziI>U
zGhOzd*#P`Zr~hZV>_4*&2&8md6)n_D%8P2@9=mhS@Zz_&zfVX1hZ~p6<S4*VfTI9M
z0geJ31vm<D6yPYpQGlZWM}faYfqzB+zb0n<pG*Ke1A^SdA%6d-^#60fhajmXE*ys$
zRb1~(p+g@l%g8V?f?Apgy#BEd0v*&-gzi4EA&`a4(G5s+`H8&%`R?r!Fa;l}JpjHk
z4e_5q;NdHRfdR=U`uja=Y!bq1Y!dvCPue2|N-(CkQr`%*L!$Nw<o6#WYLCEXJZd%e
z2KpFJkS8KPxJ_~q!B9a6eV^v|trE5fP~T)owt#F7e6F=M(86aaouu?5wgxc!|Lj*m
z1GWK#rX7KVu2AKXyaSSXN#`Q{{Jo6=)P1Op0<krKO9%$4ezblMAnX#T?E$e_K>rdm
zAZRbK0z%9yf%|1f59kVn7*9fI*BeN9PFh@yhb71J7vwKLSjo%Z&A&MNMeMY&wTi_X
z@Gwcm4Z!EUH8n}o_H<Mkd0Ip6W$QPu?Do#QeyMJqz10=w*-1;fVFB*aa`U&B9c(%C
zee?^hQEr3#>s5~4a>IMs^VI=XolOhV%GJhUf5X6p&vR{E$8OUm?MVHFr#4S$VcawH
z`GktY)8^cswIe*%zjD|JhOwgM+O;*j9J;m0;@~^pks^gv4~^9OGwuTpUwu7rjJN(M
zi*knPV@}$O3Ei-|oqFW38*Vni<F)LRuANP5&_w)VboXbaF`Ly+UF2*OR;=Z06gV3N
zRlP0`_OG8|l6!Do%T1x_qoY!_`$q2KY!p)Gm<`ek7|FXb<zD-9TZ|v1rQW-s?!nn8
zJn7iaf8vL3ilVrJS>-yjvtQnramrEE5k4f}tCQz0XQME3belnMWXGr)wx1VIY!v2G
z8-@3qEG_vK&qCsbPnQpLwAj_^gF;>1El<t0ra##0)#uVF&PIW=QQ&M8lrJ>+qsirp
zXVqsmZk$-ZgHz_(35)LBT=LEjXPSeW<oOaewW**)#_Y_^A@Wx^8->Cq3{w|}A3jeo
z#;;t?PybEeu@Lzvvsb;2J@0<Z+2v+bb<pNs20CHOaQ30)w)m*=o1Hk-@2z+B-33k8
z*GrL0TyQ>ZVdR01Q#wX=>7UFnF|=G4tAw#lLIZciTveP@WqR&KMUw!_+?Sh!7H)Fs
zc>2J|6AYt?!xo<>%*yfnq^I99wXpuOtR3Tgd9lSiS|}`D8RZ|}ZJFuL<qTs_%N<UU
zy)wL~S)D$5)|ve;-kI~x`^ARoCXEGYp2PSZ{W%*2&PIW=QP`K>E5BfhX})h*r`L%d
zQLQyxD*XLIIU5Blql*TdjRI$*u&&<wM>-P<)dL2sS){8qCi!TnbHJX|*ZiIPM(<#l
zwP5D)d8RS<=D)iCq!nkQz}YBB-0xL84msS|()Y}~rJ|#5OKtl`xj7uWwj@Qfl3@bD
z?B(;++a!rN8wJirVR4U(Z8;l-{<9|+uGl-W$X1DA=9!TDquAPeRcxNP(%MDIROhtc
zsC`X#r==zob#;9)!CYXJ3jZ$0X}NywB8oU0h1qSDbGlCHBY9@WFfIBJ`b|iXwB~FS
zAX4Mfe~1F#$^Y5u|FiJ_@8#tk==GJ~e<IJV|9OszKlJ-Q%*9RQ%Qp`Q5PG|M5y3Ii
zO{R}B;}+!3xEnitJGcOm+vk`BZXz*02Z&un;y^zq*FaA%L?Q4N*TgCiOc9EFgkHKj
zj4)XE<A$W64QfLi3=mG$)^l?8^l=K-)uG`GyuEsoy6E%A^=oT>I}kF&NkT8gAaL^3
zMNkAOQCtGNiR@X4ga}~v*XRx4^^_)p_3?a_P`v?00Jni4B+&_|r@UO62MN0SXW99F
zl&>jE<kd8(;QzFm&&01D`3RT%60+82KqBjh7*x^#XaQ6N_6MR{#u7;CLk=#1i3RZ~
zD1oS!8484mm4Qz`No(LJARh0`7$8{tj6D!?d1fpStT+auTS<4IBM@!{7$=|>5OQ^i
zHqaSZ0z~^vHhADlGOzV{A%cvn?aw^%?d;X*L?mSU5cVTxf_fW=2)&3sM|mC*^|y&X
zppGZW58QC7_c0CE^Mew~!W0g9jYmUV;wZpTfTI9M0geJ31vm<D6yPYpQGlZWM}ePG
zfSd`({geLx1H>XvpNW4`|3|iun~zv}_@^=doTc{uYRoe~ImG;v;;&==H9^cjfnche
zz(tInTm!|z0O*oyC`*sjU*{6uf`+n-*o$IqoWRHyM5kMN&JL?NXAi)9$@$j|SAQIM
zkJaes3u;D<>|g4`6McNr##@}=r8M}Wqfh+vyZOR90)8iY^TY?gIr2P_LB10`_(1#y
zmAKDmcyb1ojsw1K@cA4r!YhGV3r*;Tp4p+!LC@;YWv6=V2wg4#8<E%=NX&qku2et0
z4$k{Hr1N=hXF6=^TwLd<t<2B#d2MlM=kr=zu&dkLK4HcogH;XYk9JVG=M)$u>$u24
zwcnXTmJXwx8Ri8o_bxXfx^>@Ay;@Aq=dF3~nw2-|LR8*7J%eRCea=i@xyA?sFedH&
zI@a+k>T7kUUER{iVQr>`rFO|^W4<uwS&(|M>#<$e)ITI1T{2>a8{#a+lJ?g3Hk+_u
zdgbb!4`gO}MGc<R;tlVE(&K8Sz6HF;79ArU*!ym^(<JQ;>fm}`t`5(?sA0QgPs25p
zg`#72ngi2&*S9Fhtn&Tj$1r_iY{2J*Oi}M7SsE`pJ36!Fs2-8?^3CI~Dk~@_FFKKW
zGPc|J=YM}6rEK+juzk41QGlZWM*)rk90fQEa1`Juz)^ss!2dV}$oc=@=l?IzM;PoU
zgcZ2^H?aWu|GNJ_M+m1an8s9wu2plkC-P@9A0m(5jXu`QrndJJg<`>%fe3s>0(YT@
zOQ07yqSLcJsq=#**^SIv+xMM(*qDo@a(9Cop2EDEesLbB_UdFX=_n_W_AB_d<9}@T
zPx>PE@U?Ag;tWp`Or<F=0JiK*2A^R@NZSthW={C6Ez?9v4)}va=Rs`n>F;17_y~gp
zlU#h<iH=1rPhvY?IzLj5@GRhTfbsQm|6GoYt(KRvp=NA4=#20wh<u;uEGW^j$$z0W
z^8eAeNPWUfAv_V%-<L5NDI3tXXo1gs5-og{t||2aKy(Pc@e_a{NXS|eehJwFXp;H~
zAoZkc0)7HMJLBTv(!fO$;iHi6*isU*hJ>H;4mb#xl-|;HaK?8s-&(#5SS%9q9q|t-
zU#1-ppJ@z4vKKqxJ6SjML)(LHL=BCouK_v^vL@EJNCHcQwx<as;~@SEFc#{!fDdFE
zzoj}BFqxt4g6>qeg6Mb<U5aw-$G_?e^JhLUf9508HkRmKT&-)>)$pD8aZ2d&ORp{K
zy!^lCBlEBN!u**}&5zhXN;1j8ig7x|!*%zcX)*HT`GMG2AEBJ1B%`oYt>9c>#EU|`
zP+r|IlOga)AxrY>I(0aiyrIL0<tAM>k6B;lPc{daI0|qS;3&XRfTI9M0geJ31vm=)
zngZm!<ncxR|E-GsU?2Ez^A@^$x`>6Jb?v=8U0M787fymszPQ#AAk_un|MO>mt3i4=
zuWBgw_x1J@2?GMi?1<c-$om@r1^xYeNv0b4Jjf+LU_QWF5D?_zhXcRZ#S>ce<V=X)
zMv6tgJ`=$SaHm!VG;aiK2RvQ8YBNcDA|bx|1%RJG+D4}?A|cTe_*_@u0rh-W7q=;d
z=kQe-6#UZGmqOo^2@<+Yk#_c_0LDk=C$Rtg8=aTP#b+W^AHJC*o$pA@4Rz`>*2)KQ
zc(tnGONeXE=Wx|P&$&2HGIwz>&8gu_2&_ad-oimr4uGz)@j#)tf1pSt^bwCFt3}W3
zsPd!qjX%KkXw%QmhWhtwh|)Z4rmuYw5?%t%<jfnKXZ)-JecT57c=+Nw;U!qqjI}j6
zcq1v|A|FXR&&VNqj?{1B_hTI?tQjPV5Z(gdN9iAqlZ@v_<0K3r@J6IWz~@^3goE%|
zN;`%jG`)@MYd*jooWIG~?*khH9|HNnM?k`dcnl<K@Dxb+3WOgaou72xq&-r<mLE}o
za^(9fAfZPgkeu&>k@;88_vP~Bym)+V#i_pGmTwD&JU4o9xuPY*Xg47FM@RHF=|8?f
zRUQ2Yee0cC7X*D4nt%6l{It6xhEyoHzc<$Cb~g|A4HyziGUqQvZU`xwAALq|!MN!k
zPFOI^&-erhV6-U7h}sOTKcMyEeG|&7bZ(7%3nENYAo&%qZMThd_|R&O>22q6LX%+(
zvoMzA51sIIoR+!sTcPcfCpNdI_J-f6dL;kf7n5U<3Tc1D^6oL`I&JT=#@>F1kxK3Z
z#FVA^j_+Q{ZSudf*MH37G2<QXr!&k+nr|*_BR^N?YL~mG94-4y-aQ6<KkR)anR}s6
z>w8!2NYv`^Qq(ab?-u-RV$GCfn)Fh&w9nL36#MkdGJet3fMNbyVtbf_Ii@6Yy~6%V
zx7?31#qJui_BS`#VBKkceu!tqgA2n`&X^wvZT4itG=|wp^HUWDZ&>PhKS9lKryg%i
zXe-!L({=oFjF6YK{Mub7280e?>-f4$%)9L6z8>Ix;d!PcGkR8C12;$SVuz&-yL)fF
zyZ!gY6cN()RYLxVm!0&)C)S{<rP6BUaE3{u`C2O0&+lZ8I$*MVTS1fToYlDbxWrL_
zqX0(%jshG7I0|qS_#dGFIsgCr<o`IC3xvULLO-#muMbrL_*Z!VwYvRzcn`O$IYW-B
zk;CIy!$3SnWxR5D=hT{4bB2UfzQ8Zg)yvaO;2{zU1%AHx7-DSf3(I^Lv9Cz8iz)F-
z-xqbsnUc`t&xudv=(X}{S+p;n<Vn~KIJ<ta2O#Hha&BB$Gd8W7vp96~>DVBXX5PS%
zUTf}GV+-{0^bZsYCJDi+@Dq#ZV7dzgKOS~pV`J%0f2|h!WjnV#jPLuo8Q?tk{oE>R
z=7yi>+{oGYJ?f75SLPP+&rR;1nHyQB$u;Y=h8(z&zMjhm%!T=S5B)WYf7xGrS6^Q*
z_Vh3RivDDbt~FyEQL{1IV^}!W6TJhb6lMMX6?zlanA;?}H{{UXpVPPd{_DL#?ggSN
zLiUE2uN#<Wesu5Gj<>L8yo5<Z?n}bU_=xfH{}q}-sfLV^?RtMtOOF~_&ck_>B*K>=
zwA8>w);s54p`~YlV5*Ckr#spr<NFmo3GIG1zV3v<gha+g#>dA+?yWWd%J{(06uJZm
z(G=_PeZAgfFB;d-?`_TaiqIDM2%Z(w5Dzz{TE5*kkA8uhuU`o5lk9~bB+9R=wX1rH
zd3uO^;Uz`-Y$f|97kOeZ4{M*l)%flj=;1*axV5oIi0zd$5B*6^u<&f2pd3fXRPXci
zt8dL5CXr2v)DsuE{k!98N*>U)H2!uD?n1)*4Uy6grGAvYnFkp&34BWm65723YLScX
ze`&0fP54gwChJU+y$mBE!x{@D&msrl=X!Kp)Xt0fzMfl6Jy#%k4!eI<Px?HTKHI*p
z=T}qDzowq(t9sIB-;e7puBo@Arry$;dS>Wb`aGg~P;{K+R@1{pQaH+y{Tu-#I!@Dp
zAQK}2lIK|@uy(%E=LGf?^1mPV3X~&sS_vfkW7Svnr1!A&-u}K`Jj#*&6M%%~3v22b
z;<NPLlCA}*R~HxA6C};4sW%r$bh4oPC*cF*YU;=0vvlt>47n!;;ZnpEhKnT3RYL9)
zY%hr^5U($i;XtsPBo08dDRBnkJwZZlP`qA9u+^w;*?eGId`|-MfvLa_z-%DqAh`$Z
z2z&zU1SIq${Y&?;bbpiYq<_*kNkoUNX3tB=ID6uIYoIm|Z8JJRGIw2I2~Y`t>;I}w
z($9F+IUtsj%(y^-%(Tp_BXrE8X1uAtWE8{vEMD^@3{XjCi)-eJ*rHU2p*?1gvhy}H
z|2c2?XFTaWm@xba*|@1a9b3{}-mi7;bp7(9&|Sj@1uy*RO(kW);eKVUZBqUpdtU-q
z<JSFu2$c-g4IvzfNNCU;Dr5>FW2jS|6ipgPic_Qv5h6p$Pzo6`WDJqvl4KqV86$}Z
zxt0Fkwa+<pyIkkq*Z+O*?|skyczk=Fv-aL=uf6v0>}RdLBL-c;hDra|&vE|$ZKDRY
zkOrv)q!Rc)ECCwhoc_Ok|Mz$E^`7}t-utEB{>i>TXx~u#+y7d8Lle)-*<=!Rx)m3V
z_ZxB1<iVEBIprPt1_s(urSuoC%CMi66=^Q?jlkx!ZAI%F^nKswOT^($Q{mY`ap*fg
z&A}dGQscu?7k=oc=f!x(QO9qdyeaO^!vZ{=Fkz?X`FQ>r6F!(qz!m{!CVs-XKKTOF
zW9bY6os81?I{2=Rxd(=Oj-P1WOz!|?psS?#WBKm*iM<!l`_u<|CVEJ7?j{@)r8H5z
zPxy`Qi$wQ6kehg3o`N)lG7`#;zR6>*#)-p4f#zQ%PcD$k+8#*rbCiwEmuMb_ITf3S
z^#pdpJ<YW=f&GD<f%ZVM;pd6&U4Zz+Eg&I+RxlfgatcC$R=@~gUtkn)FmNMq2(S$J
zPqYR2-Z%g6&BwlH3!t))=3~cCCnp*QH4IVg+Du;Cb?x5o&-Z@TyiRHhFzL5xXougM
zH~uVJfbV_t|DKJ2)D{2@UK*qlkV-%*0jUI}5|BzjDuJIQ0ld;-Pxd;r6i++bd;3lF
zcA83C-s400L{E1w;nw*R@hRGGVgT)KPkY+)e0=CnXK$|=d?4+#k609gZFBGG<mc}_
z)7kHLKL3vN4N$!IpBVrD>;cH^|Jm1b=6&Gc$@Ah(;d{cqo!*Is{sO|i1?dYraZCFc
z3hnF1x_h~J&-BB4qK1++J|f}!4NMn=@hq(dF&q5v)7U7{o`a^MeF=`y0z1MEpd2t6
zScMn8=;gw1|6(~gxRalS7taGU^xe>wBK<M2cX9gGMQH`lyLew=1@K+^!g|4vy#v#`
z>2&%H@~0%kHuwSf+s{3SKgeq=+#aZW3Q8(?Mtc(yA>D&@4$+~w>|PCcM+0fWze4=Z
zPQMGkv5i7%U%$uEb6>tcWx;4q;$58HYw--9L<2xcyvQh#twtQ)=QrU#fyqJ0BfZZP
zy+i*%A7A>4iofaITpZ^%;*foY^9qt3$w@)!4dPI~p1eSZ+TZ<Z#%%<-uK-=PC@z(y
z;0O5)L>$U*^UAOJ-Ig%F`J%WMF<;~6N*MPL;x0wLb3}28*R1dGN@X00b0HkZ%8^VQ
z9QbacEfh5RFtw&e=->gn5;}sy!eYGTAX`g^v9?zI23cB;5!zWe<KsWy1y(26>cQL3
z-@?LT!WaGBQy+{VxPvFGV{k?TE1<vJrM2`|oCRn|e+N<|QK0@s$e$v!pJ~W3Roaj8
z;JX*oSJLI0`bv68I$TpP>HA+zy(GOA>m{uPJx6-KfQZ>3h;&k{8{!Yaq(>@XMiphE
zb(H{C2BGfJTGaP+kKznOoGysdY?-h=DbGWQvl<`iSPz5W#QH|`aiGU{TTW^X`X{11
z$j%6xqq4G}7d>;D<<F;QRCZb~<01_oQJS<~^-z?~GnA3?5%0s{LJLv|q^BfDQ(W&+
zKLt^>>ql5G+W7q&f%Pj?roUPjq?=S1jlh==gzqkN?_uS*j&iiaB3SJ`Q*33099RP=
zKdf_c%BfGR%`+62C`q6GjPHL}e@JDe{!o&#iqCd=E-EXE$I5C9{D2!<VOho9{}0Rf
zcj|_8sdgQR_2v)>9-$vD`qKi}Z^Y#9`EsCf;h!S^Z<XgQ_<Ms(IGzf}SuP5MX32Si
zivoTZP#HnX>>}O+_u&2`Fdg^_sD!p!32XuU4CDgq;Jdy#PzIO-lm)&3$^%~m6@c%7
zje)ipo0<Zr0)GMe0h<9sfU3ZSz*fMOKs8_qunjO6{b@U37!Y|176LVZtAU!pIA9lG
zB2XJh^M`IgDmSf*3;SVV|4ijJ#Pef#PN65tL4CFXuse{}nW=xkC9nkc0>bTzoeMM?
z*cbQt!2ZBO-~b?G#Tf*w0@C_(TckY<*coUG><t_Rv<4y#!5H8eAZ$_CIY85Z6L9Yj
z#M-w2wjb;qAlQ6xCgDB;=m4aBl%@gGfiU_JWCDGF*+5_5Lm+gK$shf+pcMB(z>h$z
znF}-_&k&#`a4ygexB%!5i~vptMgnI6v9v6h4O{}84_pSM`iTav0LB831J?qt0oMWZ
zfa`$;zzx8sz>UB{;1*yNFbSxD`q>I>3`_;;19t&wF0mUp6bRiD3<vH5(s+6hNcBm5
zgRtKg_UBZe7zV!BpTJCk>2W5I`rK1M)FtOMP#j;_hqAMqIJM&&L2sxX7y~K33D62?
zD$*y)U)V1RZA5CvzaYy0B2XE$*+7bOsYd?7{zKTW)Q;a*lz%@U#qSTa077@z_YAHY
zY)(|6(=t1!>}zGVJm<u+rd#)9hS>FqeDOXgEBR96(?ixCx%~7MD$I$|%@@p9x%)PB
zhC^G2h}qXtXV$&0Ixi|=vw!`zXSN2e56?iIGP;=qN3S(YYaFxYa@4xGUENfCD>^SQ
z65Lb?e}4De1nsFV9L{k@SK_U&dhurbp3MpsuN>dVHuhSd*1t*r;}2&YNsfNj#$Y;!
zQ_AQTSG5Yv)=9r+9{Kn~t4FCWZaD>xej`hw<fkPW*$=g#azL<LnRTm@t!|mbxGH_9
zqi5XkLiy8o!Do7_>Q6eH7C7iq{{Sd}UQ41|boSQvBcJU}Cy#r##mCp;PWs)bMA^V&
z%g0_=vhlK9CX`?*qYIgSuwcZmXS(OC&MaJ3xb|qJOyOSc#f8r!X9sU;Qkn?5WJdSK
z+$>es-CkwX84bA?YOi08Ob@?)sb1am>I%!8_|;vz!55g(E#39;Xv^^T^PlV3IS=aF
zvvTzI8=h;PZt%0#G%rpqZ-s{2s1@<&q*ixiN{Vi%!HTSHlT}T-2R)r!kuiJG?FG9-
zBBxglMMq%G=-Rb4z8tip#Oml<nd2o2araHs`*K|RWn6tVV2r1MomDy74wK8B!38d6
z_jI|fdQ`RO8QR<`wt8Ago26}^XN2^$a;fKb8GRT_uUygb>YO&~9bL2E4Em(4@Tu;d
zxwnTp9j^?QQIB_ingPXs$LJc#S@$_Mp+m}o?ql6I^w7Dda;ew;M0uGfmD^0T#>R9*
z1MG+afh+T4x_Cyn*l5Lhr)D1w`+im$nsR;arYix(x32c<-j>sK@yhwPOkfw3&FGv2
zqecum+j{Dlv{L!whV3-2_e|cJomumY#|F>^uFU0>$4;I{l-$<F-mbi9KdGYZ*z2f*
z_*+k&ht7x}c!j@N^1a$~S$gTalwHO?7+9^pWJUz9RIkvt++cNK%Q}0mYk3@2SwGqa
zV;Q6K*{RftV`k@Xe&|ZP&a<fW{K_E@PIQn_F)&PXeRibXO7zifh(DF<{FD!M-<sIi
zjs7rKId)9tNc&DZ<8;<u`*5f4g$kOl9b$BsE%}uv`$moK?$K>ty$uHxS_#T7&Y6AQ
zCvQ=g7qP|LUZVeKOX-=tyJ$DB?|?-aW`&xQ3ZC1fKjigK)EOOPK2G=1zU@=dF^4g_
z{<290S!HcnrZjHWcV3@X@zI*IPtWMrS~GC|(RyZ&hM+^uVswY6qy`P1H)4wY*>;;2
z*tcAI+;psqfwl>M=GyEMyVB+_&`-9beAUw%>`9b&TBX_b!m~;P^Wn`B8a?<`!J*Z<
z>0NtN+a5r@nKHWW-8Dzpf40^zc(2Y?f4Vz=eo|BUJ`p<~g&f*_p@^%E4%vs%h01;I
zBfr+M&Tzvkd+%CJm>2fqw#ogTGha3+4eh+HLHK#-GovfuoGL8ova;ptc5eO8@^U^6
z4^_GQ{Km%P+FA)7ycd0Q(MK}6C7CM4Ywceynl!xWFxM`63$}#2`jjVxN5=ICU0W`b
z6NhqesT{95r)=YwO|EFsv&+3hTjrS+99_~fC1~I1uw>odp=m3TUN=Tp;Xf-{UTulj
zu-p4D?{9Kt*v@MK1DYAi_TLbH|D&4At7_CQqbs>_*smhZ^39d}KF8j^$niY?aZcy#
z=I!I|$d?}(SGnUR-oqK)xE13YAK&H~-D29!V^d;mR(+bYbjsEik2l<@2+XcBc+wc(
z;Tc_f<u(U@HE!^J_BE>}oUJQ6JNGbaQf1(|OhHRiBRp?WGS*7kQ#s}=H`TW&S*brh
zdBf#1DSqb-E7pg{kM8&}WZ>-$S2tHUV+>++Ps{7R?VR{z_uaj6F+*RN4>5h3JMv|_
z<ZjCx@5**K^XfL{0F3Vbqq&;OhYPin7g-GK={HK|%Cx-p=eL{QOHIzZpzhiqFK9`O
zF17shXfJ=$7lU4nDcNl`Zg1G-6uoPQ4RxlZjo&gh?aDfwH^}G;4HKtV&ME(VDkpzM
zhwPFG`#(<j{EM~wzTJZ>CO-}Hv_v~%bi<xB-+Ogf|I25tO?<j<pnm$0o>l8iRt3A>
z8ZH0f+M!Rrn5(H%d5a2PC_Nfqx1`mF`6=UdJ0=Zm;$f;&QjySYkbD=Vw8)uwCuDTt
z*}uH<>AYIu)~Dd*pBAqUv$rlgbj*0_s~%cY*JmHMn1}aAMkjkl$>8qu45w&2&i;>A
z`ntWmcA$0c=pzP0vS!*<ZqFT$IUu83bh+T%7So{<9(C+9eafe<O?;z@7L@BP%z1HR
zUY30edoR2bGP)1BE9MKr)Z?dcE3C(vuCgD$*uPAD@bE<aF;)KIoo;l+-Uc109Q`s{
zA5bmSIigU|zijXTg9RJpKHeC7XkwQzpP6#XmDK{w*%;jo-{s9lKXYkO<ex5kCwbcI
zXBG)_rbU#V3cmExdheh(Ofq5^-MOiUlAK%V_1=>fUozzGl`|hFrI~jtTc^H!rt9b1
z_I)7dY(_UC<n}Qm<(skVE@Zzvl(T!knYMk4hQIZ?*DI=H+u2!DEYQDT^2U`JtB@Y6
z*{A4=&z24C;?A#|T4u?!-Eio&ip8!$J(icxHo@FogXl8HkALZ`wdZX}*NbLuewRA?
zW!!L$cDIOM>Gf%4ep)6bLuQOFIl*U(c0|ItvGYB!zBfN~<i1g(+YEdyJEnzk`z6u4
z?_iF`=)y9x12c9s>#b#(tYz%TZLPmO{fQ@cdd!74D?63V?t*!V(KyO?mSUZA0-s;c
zuAFCe_mx9*x9Wc9+8;b@m=~1e5%Ji>q9NK5OE18s<in(Dx!1oq=!{Y+T(|LJ<f2*I
zI3acc9jty0nY<BlY1)y})6Jh=og5#~JJ?`HkFBSs#yZU%@#~yH_pbcPQLsI-H4WvE
z^sI_$EWPK8HJhtE*ndHA*(V^V+REN?c9-yG@xE_|tQzuY;a-O_yc-~Iu1rKw;)ZtW
zp+j#t4-1^6Gg9%|xzvWr{?A8iKlu=`tyLB#f*V<S);0tCTa77b<+60<<7@9{{+g7*
z8I>8-{HX6W_4(@u`*~xnhSAAo#C4hYqWbOy)zQkE_o?pp(cII1?EV#sRywcGx3Ac2
z2Ak+klrQJJ|KZS08r`3~Jk@sUi>dCnw)?nt3v2YcV#np8@bxlJI2=jOELp(PJGy&N
zw*5R)&2ZacnfG{tx|<&zd3b)->sI$hgk|Y&NSiD9*&#<+dI`sFmPEPcycPtOHc!vm
z6fh&{RI*Is><`Zq>Q9NCAXp^%St;!_sl0m?GCNFHl3&!sCuHSOPtHQ61+(uM#kHIn
z{kX$zqgg%}k0d>_WU>{dXFSsX^8Ogjvza5T&a4<zr;kZR{FG~NoXu~I<&BNVDu$lU
zWBKaXHQ6_5`>b<G7uVE}(Rnbi$$|re4z8&?pmS8pW<jfa81vH@-K2uM(H8_0yBz9d
zn48&HYmQ?4+$+hQ#)n=^->Gyc=LKXU=~*sqI}?9#j>oP?%zynN=Vk6#e%9#D_cz~Y
zH8k*^&(7RkPdW9P{mS9YXLREh^o%%}taPE_JLSt2PpZ#u-8!W~hlz(bO<sBD=IXaT
z<{ZvZMi({X7l*Ps7H4k`mcQcnP}BSM;i=sY%bHEt>)o-@0R2yEu?GjEJN0z=l&4-H
z8=u|%FmcGL1%VH&EjR4Av#Ci$pQJ6zLffGqZ;vsAE7R^k;sTefmdj(N2QS|o-ek4^
z1=CjZdfoLlDBD);s-rjOpMT~{JuNDS!x*1(IUj@90Vik4hgrPraq_A5Nk`tzu<DuH
zdKl^jufh8VqucJ)iref|R-ZSX)pwWuvZa2KT+FgxQ&)r@={T)pXqUbTc!y?mU96Xn
zQw|E)9dWgZTb23w=M~C+{R>`fo4F!|*YV7eQKw+zhB1UI!_Urj|J>7{WpZ(YHQBo-
zc*{hV?p9S;wLWZmbk{ZJdr%)^8C^z_?3Ll&E$a5_X>+*m#XF1MdOlB_Yu3~u)qN<p
z<MdXgc&BG{%lseNEp&|85;@F0ph{!kAY<zh7W}f1POc9|T`KB-s0i;pj84INH-AY{
zLH3Ogqn5g+Hk;e+xU-3D;Ki72sj4P?H@p2DP9CG1#LG?h8}??NwoZeAoaec%`zT+H
z*EpY+A-k{m@j<PXI+%xPQ#snaxYX`l+LN4Z!F-31RL2(XSDuHct=u=F)U(fs;%4s8
zv3AMm>eV+$Tj$tmn8UN!cEM@pCp3<?*io{5(WUlJhEEFl9EGvhkI`+rEO&gq?55R<
zmKry9KGIpr9X8-v$F7&Ot~PGk-e`U=C#)4Px)&oYFHCU?|9tAoj_Kt^Ct`L#$PQRM
z{Q8;B_ucKo#*I&h%^}|5xH5rN_R|wLX2+>1O`i5PEZwy2zNCRhs+$I^J>_Y-yT@D1
z*K8QwptR0w_IJHJ>S=jJz_YwolloKyC72AeeV{+0AZ+O1#pp9GF}j1<{`D6dFJ7u7
zyD!@M{_w|P+xO0V)9Le~Ctk5h)5AAy$68@`%J=Cszt^dIx9=P8)HXInE$rZf>F>wx
z%388>x5?*%^?uQ3u%5{1rXHD5bhOxM&fUDE9bI&WZs<|=GJX@kDs-Ft#PD_&6Y9V>
zhSA;rxPf!#PLIt7ZkK*_iA*k)JrLGRJAIN)s%xh@E!%W{#^Izhy10)o9{ze@Vz5Em
zi0TPz9y_I1=Z#R)m){XrHqB|z-5ivon9-^2&kbt7G|POJ!G7H|o^@r@UR|!6U0G4u
zWqkcMPFYc7vF6r;%CWX8^pmxv?R$6U(?@r2U-ijsUa-2FmC>`uYf~n3iV`r77|-Z3
zRmbIa;w*T&Rqf5mZU*`<i#>;({l#2$b;#l+pTl&^qR~DW-IGAx46Pv}HoL_wT03h|
zt2u7^qx}lZ!{^wI@ZGcO%z5-JnT)P*;=~6U7C!fKj+|f7_<Hv0)4iIsuc|n&VSUnQ
zknM~45m*mrbnCq`<{sSFqp)b2d7*c3r&lqqVQLz@is?Q<ryj+4$WBE2g|2dC3O;Rc
z=-blDx#PVPgFT0J=(6<HdbtL#2fgxGwKKlBuyGjH)EJ#%RlOrd+b>(#9O_<uc*}yG
z2kNf%mR(n;{jQ=B%iou2RB$+njPAw!M-4)&dKH>K9K0t!Al`oXZkdlarv^H9+nl<h
z=iZ^1ALKK-HR)PsDy){TR%==OK6CFg%l$^5>T&H#le{vj8o!)gyb0fT;7r7oIa+RN
za`m>pRlDkn@`Akr^&~}J5%1%mO55@v*XK);d*S_;(Je8E?^eBVsGWE3oU5N>oF62H
z4XHkR{#@Hj%SzsKpR=ny-Uk_7Y@3#{)+QGXe;Kl0cE-gXp~0gr=1%foJkomE*p_-n
zvj<^qm(f`t9%Jya)W6EpM0c8Rf_0OFb@ya6+A)OFvg*9Nt#0OQ_~Gdhf5HCB4{Up+
z7nw9#ee2iq`kOZ^Ij&!IsA|7|eT$C^?_}lR`xT?R^D@`@jYh94>c#re&3RXLwHP&i
z=g~R|jYAy{*M0V(1?DADjIP3T*K55YlQ=mIr#@^^H~)0zeg1C^6)$YxuRksJ+Rie(
zcOPSP#?^}t9}oU5eil!A?|{l`qu`>%?qgkZ!)FTuQq%(0<f9yn?)3YSZ{E(}>|ERG
z`k{UC>h;p?2UosPHmLWecVIK?H*Xa2KB!OSFuh=|n^0$`N>b*qS5fbFH`*1jbXZws
z!sQt^TXb*L<hKy4xiY$lOy`CtLb6`X3VfTDms+O!;n*je!`6>xUi7t{sc;?5h_ji|
z<xW>D{J3Ua$;XmgAr9k)_kPy&ZO*u3t&E2HG;5{0f2#}jL1T3DRApUfR&1W}B<9uW
zb=x!BWvoA|w)xt$^u_tvR~?IA;Jv3wPvS48n}XnFh^p5MgUaU(Y%X0YG99#UeYVW|
zk#Yx5&*>aH3-5!BuC1R<n@$}ITPE5Cc@1|7ii{Er)&Bgx#5DZ8ZcD2+ai#DBWpw50
z{+%}0fB!&la<RH!zl|&Pb;cx|2y*m0ko=0f=iunw_{PlW%p>xazRZ8rT50Ps`F=MZ
zJZ*Am@dY`vKK6V&&9-wD&NYKRGrH&f&iQ&+`FVcq*MFb$i2OQ_)@PT5j4k3WoB5$t
z;;FRd&}RcG$C}4R+)u^J?%$T%5mTykNPm*T<|=jTq@6oVcW4)kmbruekJ0^jeQh?Q
z<8GK$b#$NnbpIyf_ulR1vEWf~lla`OC2_~v`*~+*blQn=fzeG>eDTKCexav<=Niu`
zYAe^z-Q&nre&Vb<{NssSRjmbBW4O!c&gZYwh&{HeVf6f$O5C?&9Fqdht(q09qc*(G
z+$@{uWp*fsA(g}J>ij6qF8$6u_VOc}hPu8zkneaYs8b$a!!~LE(0(OK_(rNmbkkj0
ztiF3#vCowKAy+i-tiNYu*p%n=+Y;x?D<gUz*)i7%Yq>1F;6D6>HTz2a7wHbUY1v?0
zuR1O(^$RT5yLRY0++|<6eIxYuj4q|%14k`zi0Pfr`)zo4rj0w}=bGg=PdjCA(WHWL
zGxz(zACJ+=j1H=nx!G>VvBdL9yEL}F=GnCW<P|=6is^!DeLYR*rDH!mMmOMHtd_FU
z<D^u*v}L<mg$>;kksor#>B`6#**n&EnY-%^zVRASIg%PTd4KtZr}JRTl6A5EaVpdK
z<$R9^uO_`WJ7u#dk9HCq$mmv-s#XbH@~Z6zXEg2aeRfH#?+NGF5xv8l$Dh2mI;nFd
z<ihCG+r;~3q^b<_Sl8uJio&wJNgr>X%v^N5bi&F>=h}B^RE&8Eqq|{P(QABWN&DrE
zRAf)uZyc3s{>-3oQS>8o`5QCGy|2iH{xP}=g-bSPcXM;{d*#>7xOeNt#QT%)Pn<aT
zbu!mSODkY>5NzU&sT>`z#3ig<vD~1rbl;MhE!O0f)!8)%OZN$;V|(6>HP{Nd^k;NG
zUO)9?bd~eAh1}b;?eV;zhDUyB*D*jbsQ8uky+_Kahs!@DC7Ga~Oki~B>U(W6Qmi)l
zxktQP693Y6#?w}BRGsClHfbKuSYA)oi^I9j=w9Z&U+XFxRg`LYV^zuEB|7I^k9Kb#
z`EdUhr&RC!Ioar6<T1A5J>dAor461<ouzd)%}&?y-ZRI;XF5#QuxWI*;e~6doIGcI
zlVWso_o~B-1*Kh^xfvbJ8NND3@Ok57ExEh*gEOb*T$EdJ1?%JNef7D^q^GA&8%<f>
zYwVQ34u=mGPtjRW(e99`|EIL)+cJBugwF&^?`)G_=FBY*5Bu2N_OpNV@Uecj-P98T
zI}A%PJ=!Vq!}DGEhQsJIqlZPy8~ev8CtfME+<n8P<)X2h2WVv8yXJ9CM_uCq-g_P}
zy6W{MOP?Ox9$NHqUE3W^R%YnTsPjC;Opx41W6iL*RcbtZ3pAzjuIhHNZR7{dp~H)|
zA023-<k@)6qUob-MufyKy`yDaZ*CI4n=m@Pu{#&NHy<Z|eCVVWubNgZ9@M{0AI;1v
z|G8C<3zAcs&BF&5M)%`0Hd7g$$<nfN&7ih<<DRHZ4%2_0U+CXo{m9Za@zKLpu5H!P
zW;)(i8J+JfMVtBat?T)XD&!|wJ`{BAuXrwbP<Y{;Se<%hjy+OQ2E3zlWtz>X+TUbv
z#|Q6wF3jt3qr2s~qZ*~p+CSMgQG4!S-{vuK9L`Wi_o7Wm$x!tR^Ox!>CZ2K7d$>I6
zJb%E-z6+-ouS*|QG6L;w38O2u@r;Xn=3i;UQ#98*<70PFd2ed+@)9kl=aVfROp>t%
zoXP0=w3}1%+f|<x5rfXJ)8fWtpMDqFCGB=*?1voxc|}({+raOd(RoL0%X8Z_e88MA
zh5GVWTbK4f64KGQU}%(V+rbf54!T?MP1~Hx;q$Qj>oXQ}_Z^?r{&s$D{`>KzSBqk%
zTJG7?xnD`JnQt@n2aK-2?1@1e>lrmFXfY)_;aX*Q&f^}lE=5M~@wl-gs{Y}Aa(JI+
zbZ=5drXIIboUnOa>uK`y>IP>OpI`OXRJHvoo<&v3!bFTQI~ZNzZ)Gjs<vw^&H6qmP
zlD$Up)4cFr7LgAxHdos_S365(5r<RA=zjctK^1c+uFT}+0=1GBX#rbev&U4+&61sW
zy)y6ojUI(Z{dw8H8LkV*`Uaybi*ene8gOl}*TlN->fCM}6!>=H;Q{Y%J}a88wQtOR
z?WI_kXLKXubEaplzBOBMNO*(?|MtyiZGv8P+c3l>vyRI0sxjWEw;hbGA~58d=f{pC
zY!B2kat(}}Yk4L&Z>M5qN7??pXBSz?W1a9WqYDl--ru`!ghoM?irJ$$i~IItY_}AY
z`;Bqcnwhs#b&4|jgWgn*A&t#4jf-|f{d&*hM4J5j&xseWUf8|jrm4+`hD-A+nm|XT
zK`H^M1f&v>N<b<BsRVwG1nMD~pKbpSt7Cs}SU3K!+y9d-HwCie!!(hz1}Kj?k>h%y
zeXdweKg<4KY&-3PN_Fw`XLk6Qt})wbq3ypFERDa~{u|;)xO4nlZU5KQ725uLGZ{!`
z`+psAFeT>b#tH4O|BCIu9Av(NWG{*<iS2(s#G(8=;=kr6sqMc&6t}^KuW=={{ojwc
zn1*w#L~(y)`!Du0$*+${2&+)<m`-ydfU?lDldEg#SuHz#7Z&Re|Ak`N5q>VF>|Dm?
zoVrXuNPkJM{D5SS+z3eeBla^P-4p8?mI7ED6<|#}eX$L^&?iKgP8saPgFA|SN`&#m
zz8UVKyvQd0NA~^16Zrx7BMy%D4DjQV&x(u^`QS8ye6Xy}dB@}-)H$jXqWzY?3B@r-
z94y&$R>lhJk<yPtoNw9u6TJ`UVKdC}Su3Qcy2}>j;pyby9N-H#q`<F!0u<*w;!Hpu
zYu5?mkPO9o=E3)3{QH9@3)e8vZLC2@J_|y>31OP#7eKxO=A!(?z5?AvzDWKJkN|=`
zE~?A1xQtO@jzS$lSL8)52+ZD_e*Z@Jou2^fJ4Aj{;(jLpk;Hxs<=~I*#kxTIdJw<P
zKEL;2=qxMD39o>RFM7?ZruW}J=<bhg(TR`0s;5*>q^FYD^^4DD6>sclE#jHh%w^Et
za#z)AZ$H6@K`h&UwNIyVs!3Q*vHwDfND-(nq(8B|$EkyIMhnX+9=?9)Bk*_Xh2nhA
zf5BfKj3D&GMSNM{st>*_e$Usx?7#4{WdE(Qyams1a0%xE!Z`vLg=vjvPjFEf4%=ud
z-w0q+AbjVT@4{#xmU-D;k?=p@;9IHyeg~Y1K=>DM9DuO%<~RZ`0G)tOfiA$8Kvy8y
z(7OQ#Vr-oXbOL$-rvYhC$N-=pFccU7TnwBEd;|;x`k?;`0?q)=28IA(*Dr_wh5@61
z^MR{?u=5wt+$R!9<tBd#;n*Y`v#8ty@Vp<MQy7mWP8!G1Hwsz;Cjq%Y2cR~P2gIi*
zjtlSz&<%J7I2Cve=mE?FdIBqf=yC)NP+ngk$tMJ;0fgy~Ko1xS8~_XhLgt+LK**94
z4kX_Nj2(ht;6h+H5KDB-cVRJb8Sa+=V}Q}XEx=X4ZNOOIG2ljE8E^}*F3Ok$Q~;&`
ze*x|Q(s|FRKph}H`3MYvM}bry$AL3|nZO9(X(0JfW&sm{=Ye~G7l22Bkb$59<b4C!
z8h8`f0eBbK19%TebDaA?8{k9WSl}a|0}%Shd{UkPH{kv`a4WC~m;x*YrU738(}Ayn
z$APF@!D--o;2q#cU;(fkSONSEC|?hDmB6;ZDqsg-HBcMKfqrxc)&<hui!wk1Ao<u#
z0V)E6fl9zopbC)YI`G?JdgX{DgyWfToFl!WuEGu%1(<)Z_M{EO=Pf#0o9*R^&+SaF
zbb$C21OGbc0}whUptwDOG+r72QAXAe3dg5!`)afUKggQ-^w8MS9`~j|brGM`j|#_%
zZ~JP{o}?6iC6MAnw**$eRW;%Z``~Z;YLL$m#n%EV1G@q#Px2uW^DpcxzwN8BK@>kh
z6n`Vo0`WHi%YXwhkVt(sq`n$bUyTuU)@}N5u;0$>^Deo*(g>{k!fev9sX-6W=%l_H
zQeO?JuZGlD<A2pxBN~%suFTo?o;F#kO`8nsaphe1>1tWOzIix((e0hfiw`$Cn43I!
zrPNpBa7(*xp-T!aqpvC{C?%{sm3%s~>!hdfhwe!7llp2%eKklAq`n$bUk%a&sjr6A
zSA+CG>Z>93)gV2P`f5mhHAoMnz8X?r4blUtuZGlDgY-b^t0DE(AU%-!YW%PJYOL2K
zJ^19ksZZsM<dprMqua~uY<S3O_p56%y$-GM>-~08j7~W|dP;pd@L^LLq!N%yKq`U%
zAql{I26k3|Z~uSczWIOH{vVH>dHxPU^M6y0xl$d+f7agrbbj9V_wd(Hl60T{-Xh!D
zGT1gzP=qka?xqn?pT^w;W)JG@?dj?5<>2q^$HZbzTY!_fE3=!lqd)!_*k0*mvq|aE
z`Ra7|w7Zw^FaolFZ$xnvVWWo)_u)U_fRnxHfCE2zOt#ASiSq_VPJZ42zRrB1&9m4h
zmp6mw?!j~Nz+-lHHrZe^`_iv@IJo-@<Iq0pY%g|}4tvb(lFeby=2Dm0&T%@kati6i
zHrU^?tEM;`5r^zab3}2dEMylRfM<WUk3YpFKY-bwYq;^NjWyXzgVk@^aZ?;c)D7i#
zR}_cxBfC;b@*^9$FvM-X>1%%CJ=?!mK7lB|YEc}@FH6Gw$o?NTi5#=dU-LWkgYvyW
zoKc8#OB9Fl+y8_7$W~lz;~PUA00P;a*2hKmmYbX5KcVi5+cMKtJpEQ+cHuu$SBXEe
zQ#*-E*oK5{Yhy$B(&O2FTohDck4NnTJPYu-8M=(Kvr*?TPZQAI(`|s$fo*}IKrRsH
zcyrnVVOz(}ZiG!8M+5h;bz^5XegJCXJ`lR51)KvUyTL<1vKKr8BzwUuAeuO{uhavs
zLp}5aHiSG4fYb+IdkSW62fIR%JcV*Dm;L>j?`YlvlD!I$<c~5kJG*hHl>gMc{J+M&
z4+8yP+GAO|ce2zTPr7%qbnj&8-pT*B_fF1b_H()k=W-J-%`s3Y=bkyYx$WadS7zVe
z{nCBpyN+Fw&Z?@wq2p)ov0Mj}q5s6*$^Y~{k?k-k<jRC~zaRf>>TF~4+|-<UIW6iG
z4}22eW#r*`>hZdbLp#X8N$bC5Ph?5=9DWVQ7_Q7=lf7ME<Q`nR?sZVY<8vQ-XZF0%
zY~_{9cU_Yw-rn6N`5=6mIuYH!fA3^T_vD_(>Q`!KC$+O9J(b$oN$u=N52SW>Qad}+
z1F4;z)Xt9dKx$|AziwwI-RoGo*YSUHuVd*R#?n2ErF$6v>w6f}Cpl@5N<b<BsRX1F
zkV-%*0jUI}5|BzjDgmhkq!N%y;D1E|FjM7>`J49t9^NzEz5ihT@9g32$7fsr|2NzI
zUlrN@*Mr?Jh55K(_e*=ta{BhdKBOtk_TRz5*%z)5d^d+F0X$z9zKer1&%?vq-OInX
zsj0UQ-<Rj_?c2GFxw!|=)5(SBpkrX{r0Zm8;Ht~l;kg(X@JyVHO$>O(F2>F-I(#FY
z-r8bHo~xdTv0hK7o+dm)BNu&r0|SGe1}4TXhR!?}Jtw|lZ*HeAw0e5_J#`FSbxmA)
z8W}k2x*9v_xaje8dK&RvO!N&6K>NiXfeZe{fqV!8AJxGQ@Q%#JoA!jKebbxcc@s{3
zrAw@g91WXc#_&0)uay1eUYD6X6V2CWhAd9j7aAiL=j**L%&CRxetl-Zd>Lpz__Z*`
z_IGpt;@?1a-yI=mKfZqe$y~fAJ)McgbM|-l#>V4fKL|rSbN1l#yg*6MzV1Ws7vKTs
z0kSvW0A2-S<v1|^c5vXkx$(SQJovsEefnrPIPj<rnX==5=V=bEZVvdF)uhE3iR;4x
zVZ7zQff^bkEdNrh2_zR^k-n*sp*VskE|{#)UdfzxD4$QVNZ<a1*)Ll5W8L|tK2TpF
zl#wFyPa%DvedvYyAoNwK3#D;&`&u7LHR@vwM@~rx_kSu;Q&R^A4?R;;v0Q)HBB=k8
zQ?mT4>He@y2=yXJB=;vGxx=@B?I}!U?t(ly!gek(w|}KzZ8^&1QuK|${jwK7?W?Z=
zK5Dm(wP=Cnu5PRzNx#MANNpfYu4Xw*5#QqX<@lj=zLw*Mq|A3jl5!aQg>po~hk`-}
zT(rk?8(ht)9Kv=Wu8$vT`qy&&kW}JwDE^=v;=YQ`#xVEsccDt6I+`rfH7<2-2;`GP
zWov<}1JW$`ec684GHQ-6NJ3)%)obuyldnVH;HxKSxqn%AzK(o<g)jZ@@MTLvLWseo
zfGZkTQ_ybQ%KF5=pbLNGOH^c}STp>-{WYn@m)I|`5&V@XoWw;e9>uj>AN82T_+k?!
z2X8+I;b7z7<xQgtXsF%S%(q6{Vg0W7JOy!I+X-VDx`Apmd5*iEgSWpM-`By<-$k4-
zN=3(Tu=7D8m`pHcz{!Zt3t1()|9W1CBD@CC&x?46PZRTLq_h{pK}lzeaGYVx;~DXa
z{nWn|SRYlJ*KeJLAU;=P4^<w*ISj&7{?kAO$W}42MxHeeOQO7KU-NH-@8(T@lj1XJ
z24mc4gY+GQHGxSP-`9)hQF{dXamRo(>8zRgkXazgkc@j<#<S2TlKd_)&G@E|BE?BX
zoPGHHV~sfEcloV2)E>q1(q>Me%<t@Xb>vgCj=rkZPpPZk9HD+(7v(((eAAFZ^AM`5
zJ>ST?MwR_ZAB3|QkjA(4rDmO}L)U4{^Mx+fZa{orUvFQeK{6u$K}Wh+-z1!$-)<so
zhjw^QAq#3wbM`Yp@)11;><2s#90I%m90R-vbOGi7Y2I}O=mWe8q<pAt2<KnId08&T
zCVDN<z(wH!=rn-^K$6oFQ9LgG7S11-&mxE7LFLI0kcEde=!E0*x9J|&q+?@*a9otD
zm7aACI^kF%9Ao}0Ut!<=Z8~wj<G`)3uNC&elrObk8(}dxX2=&RPJX!T+zyO)0{X2F
za2U`E=nCu$i~^z#1kpe-zi#+j*k=m+Qc9n?r-`^ID1x5)SMsBT4=D4WY!7UUdul`K
zz|}z1hhQDBGcXOP1v~&GzfS6#y922{sZSC1bE39|{OaMEHZBT-K}Y3-jtG>2D2sq}
zU?`B{55y(xvqXIv;!_(T9isr9WAP1v7P!auD}q8G@)fLu0+<4+?;8LV^CN82-{!{&
zbi|J{koa){5<h%Vd`J8(Y?tgT6%NUd<RxwgBSA;}jRIm=;EV>6{Gj`+U7&v1`4e~%
z5rCG?kYeXyOa_uZI{?do#%(y9+Zf-tGV@erU1wHop7A8+)#-KHGuvgXKdZL++O+h=
z`Po+;i(kw{JMT$!G2IjdFGEzlUKmt9Z(wujQjzJPee1Jj-j9?!czRCf*jXHo38QQ4
zXVa!r$HJD0c0pdlU4kN`1Vgnyzb`QjKd;-;s!d!e=D&=tT;0FZ=KAj+=uIwG_v^QD
zrM}LXgcCuIeg~3YarYb?y&Gp(Fgo*yyrnPmAGKE6dQ86GjR#MgTv~iV&a96;-%hjb
zT!nKGLO!E=-tU~Rhn1h_$A10yIgiM%^Ju-){*CG_xDP*J&Aw9qMY=<7S~eKhtB%V`
z{Q}GNt{u7#ciC5N--yErhH`UdQVKqB)B=Z?-ub-WhIeP$xHEpPS$^}hQ}z~3Di}9&
zzmMc+w;y2X$&3!Fmbuw($FaooNxL+*z2@1p|Kt@uc#7$QYkfUU=cRKvj~U&7cd=T^
zN{^FL_0pE@Y85tgPegvm8K)~FUu5rC-(~KuHyD@E=(sXTjhno`{KC_Duw}`*SpPVc
z>HKoO$Aeds-kY7WS(K-&h_=k=R+Oq%30(53?FVNx?eBedNvyAQpE;7>kN27Dfj)sN
z^ZDLDg{&?q6OJl(ampNb@yy=R7N<{MaEjWy(q`+j?hiAuw*xvquFT8a_iJ5cql!`u
zZ>%aAyhP`m>(TD*BOmVH;*{#0KPMY~Oax1>$tDBtD{kPyyk4(Tvm>>hwYkwE@7nHp
zt(VUD?P>Ow^XUAF7@b^U@=JwAb24r{{Vib~|3jzu$sN-pZM8B3FHF(z+xgHM^n)gp
zZ`|>VOB+0!I!o(pnw_rYy=RVx&vclqVbkbr!wc6^IeF+<+hQ=`$~@b+==!<IpS*AU
zR#~lYF)%Be*K}=Dlg!DoCrwL-I!=$p7{=0*yH_1vEGX^T%+2U%&hXVSg3lWtYsuZc
zADlTg=c3#SOdzCoeE;2cd`%aTzPP@&**4BPdS(l^ad9&1Hx8>i_~vh8$E}+0_w3jc
z?rNEL98L))M_d{2sBL*}n}!dV6Q)pK{%Y&e{zpPO8W#+Wl5IOU!ph;V*!xN9rzoj^
zpJQv{PldnFc!~PR!87Ap=HHSpsaA4dd9@YC?U_kurO<nOlSiPR#N>u6(_i+)ppEs6
z8WpsdlAUm^GCb#T?fv%>)rfB8fjf6KlN+qr{Mzr@war(<ryuAyr%`5Np1RrH9*sYF
zW9*&B(tDFKGWEEf;)KoXT2GUoS2sAT`24E3rmF2%@hqxJ7AAsjR2NF`-v08${mJ_p
z4=){WV)=f>EJu$S>37Dxw9zR(m%p(Mwld-DVCfb9R@UNO?t=$aBSOtC*=rO(%?s~k
z5&7_9bG5y5wX;-EXQ3>;6!RVl%7xn$w%y5cdCIAn-N>lru@C7@<s%FueOn*N>BQj_
zvh<t;qecum+j{Dlv{L!whV3-2_e|cJow=~BQm)ptUV<l>EYW&2S7!2Zfm%t6w16$K
z*<-5ZX35UGUYU3PMvuay{=Dqp4A+HYF2?A}VqCYV23#BbuiH27WaYTnY7u{n<?3i1
zjmwAj=yrSc;kbd~M8#0!$`3xi0}Tee$6OARV6IGqi#tqhe`!#4r^QrGN^kqa-4kyu
zFt2iT9_??Sd3o)tv;Vn$NUpJRwB5G(v6lDSH9Ke3<25>`*!jY?G+&c-W8=0pRBqh5
zRWT;Lhgdl_DV(sLvTyrc<A&1&55oH-WaOKlU4CJ#@p`i<<4apU#k@|B(f!!J?-ip<
ze#mj^%S|azHjX~SS$t7FG*i<&ImbTjYV4<os^haZ{uiBt){^vK(b-$uk9@W_ojmT{
zmjCYa%@*RNk1I3MVy1KQ$5A(%^SOOK23&5L(9JgONZWp&a%@bErrn)$fWwjQr}EF*
zPvr?-!nralj*eK7Z?HryI5%Eqpb0N)pw98C*zG6hWNw{xdvnFMB=iSt{&(4uUwN``
z)adRW-R9NXa6qAzpzPwD+2?)o7Ik?MTfFTh)`hSbz?B)dpl8I%WTguY-zi_Ncv5|K
z>((g^I!rvgY4XZDH&?&)L0@mn=6`1IF51oOJ77_US)t~ng6B5r4|)9)bw<aSkJEj$
zZ~N2**e{IH^_NX5$SP~oGNo~|zVrIDijUTueR@W})|!FykJdALB;B7yx<89_f0m!K
zKa006wcn2o4m?<JCF8C3=conwvle%p_%K7W<&CQj%LX-DB|D+(DV#}*ML@31hujtO
z1!3y(Q@9n@<4jlCk6-LxrapLhqW+jF|L{&Xx?)YR1JU)%XnjDnQ0It3LI1MB0}K{y
zko$OJ@S%xa!hB}RDOXktI2=j$Rd!(M-SA!BZ1gji7DfK)vUifFy?$nqFlSms>8apL
zFRk|uic^v9<Fcd2)>Bhso#u}Cb<UuBSAOLv*dE!MhDFWZ9jQKMO;hhAh>ezAIR9Tg
zFYUi&f0qB$ek%X;eNv9H@jPnAFAimOEY98>EPuuCp{Doi!&AE*mNlEO*Slk*0s5cT
zayVs-?$p!eQ=WQ-Y<zb2!^9!076d-9{=561)MM`p4r6@E<$MfY2b`QGA7=5g$H}MK
zCmne=!>VU)>tU!DjP<4nM%Tr9`8egEfZY*So48e(pMPGV?AO2G#kQF%Qg|KD92tfF
zsx$f`t_(jr*Zp%(gO<s~4c27up5QGLS-M+QVb%Ju>Cs)+nD0S3#xlB$B-ty&yIa)l
z)zjv1--~w^z4d&aIM=MHL#q2wZpZ1Zus$Bb=$83EvRmjFvn6tvdq9=OzCp&;BP{r3
zA)Q<wjJj0R|4<RWT{1ca>)re%MFrV6K8#xGn%Zn`x8u$xvVj+4wxz0?@ZIe8b2xd7
zZW1py-EY{NdD=P+26CR~w(g@W-8Y2lO}cN0bl(ut1L?jY(tSfn4}QFF2tI8{gH!_l
zb_tMO!{6Wk-{l+j|JX8|&+}vs07(14*$2Q?WDE5iwi*<$<izYMS^!<Jp0Bu5Xt&0E
z0L0d14z9j@zJrgqhr9Evng*KYB3A)_$P~tVBtr)mo<Fa*(8iAH>5qZS>;cK1lx(7c
z@E$3)0~Xs+Ie`y+W@k20M@0M<*A=Ejwlea#5RGF?bg4D?4e)ZG9>8~S<MVtReEfaC
z$DX#3?QfM19uC4Ee?n4!VmJ1C84N@@YRjN6-XX;@7$%Z|zl=}@SoUTzz^4Ju0MNZj
zsUZW{P=2WlabapcL!3Xe(cX*S#dXsMX^Z(H`?TXCK0HJfOZih>DB&7|GDQFMx|s9x
zDg!)9TJD<lLFKj*m3v}+B!ch?mmaP>T>Vh)liNh{XMPMqVZ&p_8%JmGMa_cc%>}(U
zz)XX)hWV*jeDO=D>8BFCozf&f6%*7)eWhhz?sX|^=9lvInGw4W|3V}5ZTWhy3kxS<
zoUhLeSv`|q$r#kLu=NVt+!uREQF&(~F8vvR%Npg~!}6&ka)}U@m-P^$L`cpc{Z{zW
z_OVRDshzL2NX~X-*o9D2&xe6WN3oolf70*t+=VX|IO0iK&$abCNR+=CzP(bwG8nVX
zZU-Do<^JjV?ZWrxIlEC_#52j{kKy}$1+`PM)1|(Gw9Ui8hxM7mL^k=hq6E#LNc5)>
zkn~k&2h&$qcQ^!j`#Ojv=Mdl(;0JFnQAhs8w43p!`bWm-39C;!N23^gI1(Q`KlqNZ
zp@5y!LN>wl+|}Lp>ko)Xw#Qt^*#?ZsgRfDHC!sAZjSKFGBRtPVMkxz)s-T0-9>+&S
zCoX$!9inuJejw;0L4UahJ)Id-o1WS?U1FU-k9ZXDNrd%nG~NscFM{vu9<zX#RObdG
zt(twRSm%PNBSpYxdZu$&`el7;!B5vYUmUx`^W!6ZNpz0%t9E}VZl{$Zo(Cf>n9p(g
z;~I+cDSls8{=T!m=o`zQ;)%o8`NCJ7r~GTTQ*nPB*iaa=c3o}!e*OVoHT)I6<|pQW
z@N3?rhqdeLEhuzw3Fk?|`BNkkqM=y>7X_O-LfhV<K$=$#1B&Ab=PT^o7f$VXJW)JH
zAdRU`HR1`!cwwJ-Na6SSU4VL0Rs0H623`b;^AnEA!ZT=U=jSEL&s&tAk0?JZ`H99f
z;aK+^ZGt-VCAcUIMEZKbK|t93GMnOlKpWf-0m437FcCN$I1OkE^aPFs1_Q}vcQMco
zh~+?LyPE<WgZqQPvA{Dxvfa%EP6E<cI~hpja>FGYgE$--n}|PB1<I2G4|Mf`PQYJ)
z&OmBUE<k*GVK&AVKv&#@N6r)=(x!A7pYA{!>!t$5aukj|-<JOy(2@LM8pUjp%S7=k
z@Ju*n2*(nVKk?NQ7lql7w*oL2NPLC>)qrz=H0I0&QvL<Fgnc&7Swde)<)yLlIxY&0
zkslsm4j@biTe=Hq?1BynEP$A&F`M<~K**AvLF55M8UimM%%ub~fXG`A4n%umHtpa+
zunhN*oge|&1$YIh1-t|73Z#1J0W1XS04srdz=q({5U30^0=5F005ySTKy4s~A_0v_
zy@6CtE-qm|E9`$s&++pY--2=xoiUyX`$b`YNpi)%FShQHkQ>Q$A&}&R^OIQpFBZuY
ze2V%gW*5(?-JV_`AL^Hifc=3lMfq~^x3F*dHh-T$hq~uDwvpP{WEL(fTzj-qrf@I!
z;=<>Vvx7G^DNRHrC8I*PGH=YyQgz+!RYslBkb9x_`sK*<@avcA)lILiu*`{H-L)Ie
zK4WxCcYQqCGW`Ag=Q?)IgZlQY9KHR9=bEP*{H!(2i&M*6p@V3I0h%l0q*ixiN{Vi%
z!HTSHlT}T-2R)r!kuiJG?FG9-BBxglwZ*)Z(Y0%9d^u=GiPh1!GRI34;_jQM_vN_s
z%eeY#z!*;hJ1Z!dq_%_qDI1#rG*U^<OqbMVF&>SdE3?>W#d)V@9}W9{RvMaeeeR|!
z0mZkj_Uqo3({=I6`L|5^a5&kF?#H%+4H$oyQyx2c9#L{z8+*I*rv0RfvSY8K3gT})
zc^*0=e&7}UX86%CI_I+;QZ!5Jo)}SQ-KKBb>_}>hoy*co-=*v__QAkv{UtLZc%^!U
zzU2n13tQINb6v~hu*&+;7@#T{ozG6CP8>5kfAd3E;&q-yrRP@;d2phGjEaF_n(MP8
z?N&-|vpo)NohzeqouBfd?pqTZyU`!!D#wng9BJQaXPnO3Yaj0Py-;C``KY9}-ICe>
zNow0IwE;TI%lR}sRORmT8yk;nYbAK_Ui8i7a4unR<H{__R4HC-|8mi!;Z29RcF|j~
zCEV4gJRv+Xu1DzFa+#bsj4SB$xiYUhr)=YwO|FpI07-3tevS>$&$jLPPuc7YUPSGq
z^?2L67e2ZV>Y`Ne%Yv}Z&7F63`h0X#m#dzirdU1x+`BI3aT-LIIez?0XRSSNL%Lox
zbMw2@*)QXUYqYyX{7SD+EA!JbF^M%}bjb-mTeKq*&W)Y#VKs;|KXl~2QKQ=od@Vbs
zg>m~O(Yx<(I0qSBSVneW#*SvawJejhj2*eH^|z-#@#IdAx$tIXr?S~yFnRr_pV9Q+
zV%sCB566GX21ruhk-2Q1XjGrq$@Rdt%oxiNb8k&foa_E6p+%8fi#T0RHH{^{?nB_~
zp-K8IJ$vcz+8#;j0~3muPWWX0(6>cW-w{cDGbHsfk<^AtQXdXUeL^I)$&%D3L~6Sg
zoMwJP<9Lf5CEFKWYX4;Tq>#^1SorYMCjHxXS?>6J*-fhzEj4cJe5A9KJ8ZzUj$JQl
zU2WX7z0v$$PS_uT(f!!Qe;1>BG1BtF6sPddr>^XnUS4z}X7_{afW^bFpXq$x-9BvG
z_;jpY;2l^JUk`Og7g%LKJ#k}poSM?)X>Y^QP228E8fc`tX~5c3o~FBdyu|{M4Wk>B
z)_KkTu9rtWEw2c8me*=hpNgOalVP?G^hXqg4IRAL3iDz{C$$BW+Jce({c~->B(<TJ
z)aE@43&UKQ*fuR?txYZ({xW30?2L;&LW4(L%$?-Fc%=2Ru`TtEW)H%CH;m5u@EC)S
zrT$f(Cc4vn6RevYth*<p(T*XUmR0BFZFMteV=WYmpxAT3U-^M;kMtswMyqfAT3&zi
zW+ka@8Oi0xwq?>iIZBld=}%JFT%~TEv~!2)4()=`GI;N?Fd+H;cwKZhqvLLvRdsZq
z{B-{&<M-a}=CR;WaFh7lt|f8D+WUEDXmr}i;p}2`Qx#vlv9(|5Y2dlWbBfx^^>g<)
za+RMr>kj{TB3D&w0oF?HGP?8m>oj7I?P?f3|D_W5?HI?TfOD&6#p<XHuQNBxCVH72
zY)7!@&y{hzIzNiDOTTlEz5K|gp{{Qa<U3vp>XgUVuua-Ov|kB6Oi0h9lAcK=J(Fs9
z(e|SQO_V$v&sj8ml+B2c_@#HWtn1B9f}MsbwIjW;I~Tn-A18l&=%f~}npQ0y)W1z1
z&CDwQxmAw~l2e+^!v`lucXn9RC-3@m?;oq@pD|-%iRr_T$Ai1J`}Iofc)#{<uRIxm
z{n{9v$<nfN&7ih<<DRHZ{_oz);%DzsA?aQblI{T^>D~_i^gSDP;3F<qrXn!pn&-!k
zBWw@UGja`#oNIX|H*cq6Wk=cmy=NC$$qO)kFuLGS<NdwsMragNshB;Av$$_R#&%0V
zx!)L9t(kc{Ri`M!<^~^wxiUi<n`Igo?TGsIp2dkY`S+g_FJ8T{d&Nytn-2|_=2tX<
zE=z+{0#XV5Z%P1W1h5sVgIOeOdQ2yJ`%UzAnmRGi*bqjj6FuF%reRA|zQ;sZiTX_p
z!2c8de4Quqe0=E7Z}0!_;m7As`>)^s-&AB5nvd@>6cT`VP31%Zz0p4_?qPPJ&fcD$
z-d+w&CgvXAUQ^H|Gh01;KK~LF@z<eR_REQ|mursaWUst#uh@QB*MuU`v$bEI>EUgn
z_A_0W2??J?eWBAOQy&)h>oYyPVbp%6%btn-2gG{}lZ|L2&~jm1<?ZT<ZTBgjf)epg
zG~T}MQ`}(yMe$VdOuWY~(OgGaFdT7w`NIA7$*$BG#z={fRWhCjF<A-s%B8*jk@PqB
z%B48B5hoqLw@+g-f$gh;((UiW5!#|QWx7pvO%x7`>M0pG9rd(_$*0cm>dApNtTpUO
zRmJMcmi`b0D(~%Db+xfZU5z;K$GWop^6YC}eSP+|uKInU`&w6DpM9;Xuh0Ixt~%7J
zE2@{;b)|}DHS1~*%0l*YHS4MXva*Hzw&Qu5eP8ANXLUt!<|EEw#5q?Z&Y#tlm8ea5
z)JG(Q)40eM?*uMtQ_)O5zpE?J?#5r5)*tL(5mg+Ref7`M>sHV^vZtl?;KiQ_haNw7
z;i(fsJtlisEov9y?Y+T;(EmZGkG3Ma{M&d=WxS4y^wBY$<onGseo;%ZH6}g$M)=b*
z{#AXTGLp?X#rr#D+z(qF3b6TOWh?~xp^Uk^{#ZsAI6Yz9__A9yl~IEt|1o^AlP9^=
zmhs>1r>Gwx|BWMU#eEr7sjx1|)}5X+2H8_#-$!=(^jstx))(cAX?ZhX{x2k^ebzs)
zGIKZ!%&CtwQL49F*p6u5b-EuRx)=ZMQ0w=Y8o$@nqm3j41bjwiGREsECjc@&$>@Kt
zN8ggMC^{ukGe{)kzp77EH`Hco%8bgMU!!bvUsR*)RMzeyUlMb9A&U?pD=Q6X9w@7h
z$j^?AvUo<igHJ=>3e48}U+DvAENchH0vy}G+Ov2s_5u-aSl(lH$!&nH;7uUZb>R%4
z#zyGG<F^>ZvwxY#n&U6YPs}6jHBX_o{7%-C-<KBn@0Fw2XGBLq$YV`8PK6wOgnhqA
zjzWK$8scPiE{yqy|9`qX^+fuZE8^7}SyDT)!sSK0)|98aVNc?S>RX5Y_+$7}{v>H*
zxwUlCRK#B(P1q2~ew~KY_PE@@-^Q9c3I2YD93|ni=3JwuUaB<)V+gh7$f?bz$c^gX
zDNC_`Oty%}+Oo9$Hjgz$`nPrS@5uBm<hT)+@cl#hUPAl5(<C?s7lkRJKE@3=75DBy
zCCshyw}8&x@Bm%|dIIkPF|8Lo1o{B$U|#17Y!1ZmDCi3G2aW^=0PTQ*KyTnIU<fc6
zxCl50Nbg5;fnq*|^Kaq2{LlCVFO1I?;Dh+g1rne6K;p9qNPLz8iBBcuLwt4u5}#&3
z;?oI8e7XRM&jmo@GX_X}ZUPdY^nM`b6Lg}vr)W+Jc~a9t{wzRm1=RjA_A(!(fxtGn
z9}Lt3Vr*vn<l6uz<9;|0c`{!f<iUJ-<^#vz`7t2*?3@6O1CpF5f8o3k?;iM@<n(v*
z=OI4jkL7Nb|5D&c+^+^w{y9L(|2j~d|3>^RoU@7Ma>&1?J~anDmA?g01=tEmeVrPx
zFA%a|zD!&o(x!e$KzyJr38-E%&tpDJ7*+)vaIXp60_+Cd4<w(M3qYhPcmUJ|J^}Uw
z76S1C%;W^Qi{?F|`4ISQfM@2oC>Vo|_{5T@0C~}Kfe8>@qQDYp0UQ9t-z+`Qi{=)h
zF%#+4!!vDM6d*H}UMx@<_iKO@XDyKGjbtDk|8d?9{-%190iwJtgyCoEm*)XVU*?PA
zQ5wQA`P=z!1|5|HGGh5A0x3?CC_d#Y9526}?-I~azEMER7dr5zyuz_d)ECz(Zye|-
z-*_OE7j-4D0w##!Q@+BnML6cvE^h?rDBnmRbbzx^6pwfp_VwS+HwAQ*?=~RiyB$dR
z?hwVNe1-k+xAR>NI?8tikn&v#ECWi<tGF$<BS!jdTzX!G$GR?;q~Fl#8@i-EQquD(
z{G*4D^|S4!o)Fk!Sc>V<PLUs;@8WQ_VnF4}Xhsi<mN)i~Q%<~6Xu11_OUp%LHxJOr
zym!sxnvS~00}Q?o7+v-HlBG`%ZVxT`xUTJvCMz>^X4H8eVkSuLqp@aK+$uF5{B7B{
z_Ep_3wvGItIaK<Me_i^hk`apVABW>FSEkg)GcNL(f29pi(OmD0kKIA#y{XB|OSGJx
zPquV0Np8#GWHP!w?dFvHcGYJ^#Gv!*w74<Zr{6_(NxPjH`yt1FUeVRgn3yhDMCm2F
zxHZ3;-y_Ux0Dt+e$=Ab2k1%L*Eb5u@kf(d9ZrwZUBt5S}dR~R}yox`wrI6GoLQ>xZ
zNqrq8^-a)IrFOn^%Dz@+%X3aFYr1t$W{6#%$QSQ}vXU<~K0RdZk;_kC!Pm=)(ajgk
zSGoH(bcRD)hlttNQfJn^t~xI&VY7ezwr92mt`E<^doiP%IdJq^v$V!BYc5Bvi`&&r
z#kZpK0wcjqmGI|x&rQ&t>cZh1XLKdr`l=Ui#_!pzQ1Qy~jcjAD^=bW^^gsS^){*4s
zXKf6ob2z1pZgEwsz-*oLYvz%UKeT$3>f)AD;OIB9Buai-l9ByT3%pqBwWM-L&#RE0
zS3!F4W8e3m?b9x)uezkZERy=FOV6vgYc*kB*o)gH_j}HK*`PGE^STD%=dl)n1s1MM
z0q0a<Ntcx^U$=AXFZESll#KN+EO>Bb<}5eWw<uYuKR$WG<ufUM=M5{?hsTfZ_%USQ
z?G0BqS2$xo8AkWCyzbl1iBERl-76O}^o98l)2F#3U$#r`w#-rLtNwF*)g|?{`Pn}0
zlKSrar+nY*Xpo*tecHQ(H;eauJ7m?6M+^5lV3G2_#i#v0<*WWr_br#6S0O#Gf_$DO
z^<`GaM=`F9)JHjQgqptmj<~XEPJ8a=;A2p6can?R{@kGUOS8;p8SK|h<5^cW?bYSF
z*_9QgUB=gM<CGPJkB{x}F_9~?wkq_KwWaNQcjwbbcW+<y$!wm~N15dE&-GE3`V{Yr
zSFe|DKe+OZvO&E!y#t$Bzj=do;BNX<Z>AT_brb6BR7uJl_A2V#?nb);mJTbcOt?Jb
zW{d8vn*0`meLoppM5c4Y6CqizW(B^@%1bR%{c!A)&0*_DGcWqu&Q!Qg-&8j<x*z)#
zgH#%%5|BzjDgmhkq!N%yKq>*L1f&v>N<b<BsRX1FkV@eHhy?0^&&hw)|KEl0H_hLh
z?E&EI?e&c_0DS`dXF9w6FPs5*SLCy-LWcba;kd{lAEqpvv|jk{F!Oa49qz|>bC?pq
z^L2r1s56d=G7s?bbD!eHcj5ZEdHed~z&vjszAw+;+qZKUb8`=#r;`iM!PQvLSih&P
zs}tYQ#L386$EByUfu50*j;^bop0SaUYj15ar3qih$&lw{q{lOG(&zE@jd(65CPpqg
z#!d#hCawlLy}6yf(7NjA;+!vM9iFj^p@EAbU#F+8F5kt~h_AzQH83(V=*{iT{Fb;V
zf;eEgiKF_s4*VV+nO{poj;Rv)p27bEKCJbXJXu-koHgN@X&zthb;(4Z(R_Vo$nIUf
z&=_%OUxTmrx^VLl#`*fp05l3p<afRsvK62GM9;`SAR5oGF+qS2{ucWIhv6B|S?HNf
z&!`NW@XQ$pH+g}Qo{`@#`2~o5-pMy@D|p#BR*q8#TM;<$-Q0LyE*^YejXr%eL`SvJ
z*+&j|$|}-gjKp<dfiT{3z}TKO({XpPu+Y#LVfmMmnE;k??vBu(T#XzY5XhfK6W4fL
zi%`xt2SxhF&eQuH(_b{~$9nTeU7&tLC?7@UD@?jTzR#o!;`(UO5k68RCU=)F^)b6f
zeGKEsDXqtSO-YC)YKpTXJ@iaX#d7^&D?q-KUaF+&{Yd|j9_c}lNWKLk`NFq}L$1Cm
zxCF>6S14aGn?Drg*Ao4Zl(j#S^B)73wLg+G?K2PrKE!Q7?AzQ9PD<v^y?<ARRC0zw
zfcYFN1JzX$;uaiYIwCH^54(o1W%wbf#AVo6qYUJWPwiPiWe_P)Z`{|ck3je)QK(s#
z7^JbWR#|@3dDbY)k4Pmh%Q6YeGFhZs;=>AIuFdL&bZi#V*z=cl>+A4AvLQcNN%SYM
z2EQa@F<&WE2?#i@hVcdeK28E?Pu7z0kD5}=VU5z0l&=ln;md*=AVN*PmV#DLi?1J5
z=-=flsuo}3{Ry6n_@c3dnpzuNTq6$0LevKfXGMQj{@?rl8(^@4X%@!{{aOU_bPy&`
zyKDS$M}jn{Ud8(W_%y@=1h@t;KEWd6)8}`5e%%P*`}Os0erewj>X+1!uCp7@*Ke$^
zyT3ml-Zer##J>KOB0i`urS6q{`yx?JM`1mRiYwxyhDSB=1JZAW-}%yu<wyNVBT&;m
zHx3T2-oBnZ4~k4Oc?)!;8{s^J&EMz@Gpb5EdXA6<)uK7w86e5*9I!7CW`}~ozze`J
zz>7c^U=EPR;VVFz2VMnIK03IB<FRm@c0)ciZ3J5^T#~_=Zulz)NaOcaAjRY25{@&%
zvku3h@58+0%UN!}h|(vz0wz0QzewrVq`Oihy^ViDcUeS7{0jRZ(pmTeBj1|*Dj{Ez
zlQNL{teSkB6s1pX^w0PZ{0Uu6K7?&ZxQ9V)KAIwbYHv^q=FbX!Vsf*^Goelkb)Dkj
zAEzHK3h2*RJeZsdkOn)$kH$o_TN-+(%mRE4CHV`ejkE`f>(NofH|cI|eo&tR(r36i
z2_PHh&s+w4j=@UOGtmYjL$1t<Qq?MfOJ248;EbmIz0WR*^*!MnJEC`(^Z1k3Rws3?
z#Qs@~?uKDSuko2B?Uy%Fkv(a@aa5}LGlRlK(T~jKZ_FI`z9JWAw=lX2g-bSPcXM;{
zd*#>7xOeNt#QT%)Pn<aTbu!mSODkY>5M*df`F6Y#m#}ula)ZLseM@GxSd&*)XV)B#
zZB&Bk*q(P|4YsCZ?=F;uE3@*zox7UJ4c2Ua{XM^!{w%$6MaQdi+N^hU&3-fJleWUA
zx_9Q@9_n<wGFV1E-uY?9Y0TRhUFE!OA@??Idps|w;gMh3bqr7pDt@JX?~!uq;qp&O
zNhY%~{xG_9^}RM3DOQ{O+#}vCiGOK3<7ulms?Ks&n>3GSEU))}!H@6rNRnUN@rz3v
zJexX8>uj2xuI0UFj)%{5n5<#b=xoCa*HSro&d@<9Ay?+v#zoi9P5$J4<G0FceT#uv
z*}SG}o0?=!mOW`&I@ED`EcP^D^{d_{-ZvvvW!U%qIr}odJGpz+;l+Z|uFc$xj^+$s
z9V7U>@v)ZN-TT3rQ*$oLtw6^W$mq^C`DM=B^6;>a-EBYrd;I-=_Flb`?p@ns6v_GD
zzo+j+3(D7{>hhh3#g27shRumst{0GFo_d!Pb<8BFg^v4-PE(W6-iBh}fqhP!kdmS5
z7v?Y3RZKkNp!aZj)Or4Zm3<dZE&i*1fs*<QN$Ni+sh?(Bb1H|=!|t!oSj^pbd{+D0
z`MLS;$Cq9$ikWJ;XHVyTCBbIC&2TO*qw6nwV$jBVMvV$uOvz5TRvDi2xW}wZk<oiR
zZtRGvf4Cp!r;_dwEUDj<E7OC*-^yCN%YE>mYDB2nC3}tHr+MMMEFvFXY_7I<u6CBn
zBFX)pB;9j(Ez5WEa)DY&i?o0(vDss)<z~swyIz@h{zi|&qyD_?|37|rKYK4>N&Uut
zwm(=V>Vzw!TAo~@TkrGb0k01DoZ0EAeI@w8{1%4pGJ^Gsk8(e?)#Y#`J&Q=vy_hBT
z<7-L${n%g4PLt@uy5Em~Hg&eKd2VV>y_^<xiU&T4?=tf6JoR|p#-SZ#Fj<lG?ANI*
z-;n7C3r75UrhCrn@0}$p>6u=V`cWxaQaL6RsoC#|c`TPT?Bdb12GzrLm-MV!Y+I<*
za{BC%qsE#o#@q>$Ev^J-e*WyUX(c@~OH#kAcbEWkWg5v@_xXS9oe5k`+x!1_LS={y
zS27*RJQT^0C?PYMu2M9fQku_6NpZ?NN102wrH~;qkC`q>$~?;$NroG8i~gTy?Q=L1
zj(hvw`~7|YXTNOk_C9NT*0a`L^Ex=DNy5x_quti%8{DpSu6uH<hU&wjja^%fj%<td
z@u4lr+>g)Ta%b{;;ym`zvE!Xx7k3}+8rWpto?KUhnT3t^8jIg2J=vJjF#_#3Ru3z?
zGh!7z`%BTYUlm;stLQpcMc30Qx=v2fv!VW1&VE(&jA9?Qo-S1Vqp8M9dzGP`GI#vn
zTz3~Ep!{aF#JcL?jh^9kCR{n_8aZg``zZ@uH`IBs=6YdZ+6SYDRnb0T<{H;%u;)yd
zif<-gG}q)dM6__y@22^|$a7KUR?YQh-29pKbm?d;3RJT@#rhUaDfoCS{nnBuX?bIk
z-;McL)52}%wgH9X9))=#kN;ci?yOjR^Dgfb6(;q3nR(0f;OnR9o~PeUX_59z<EZNz
z1^cavHeW&86`eQ&)tv07TKBEX<>|bgo?zX+X<R=|4`YM8!kD)GHCk#V%?`j>&@8?~
z9{#f9!jL}aPhPZrw6mY#?tvXYtm?Wn*yZXdjkg!~zW2kp1aogjTFvJ^EtXZj`aXE^
z`+3X4Y%KEk9_-@&T)&n3>a@dV(>N}QnNvHdWmGon?#g;SouX%<{#)zm6kTuS$=ad+
z{JOhpO-ZlX-|{VvkM{2oY_wT_!!h^ej#G!7nbQAu<{7TC<^ByxsNeTs<|a+hZ6;YB
zt~O`-zPcmZhR)CK8Gb>lvQ|vQvH0V&TaSIjaTA!iC-a*BQtNJVs^q+ne^9ZxP0z_C
z*VE;<Ab*cNTI~ABD`f5C8*gm~E}a>8*W$09z4^bgKJN)Ss|2dAvldUU-{Ygc_S9_E
zwQn5L9*;~7dpy5mrxn}1PEB3C7JUMZSp9TI<&-AAS{idTeL^A*cye>JW=_7|IjU|z
z_=6_bI#2T1^WT4_tD@`f6g`tv(KAGqXM_H|vq6>X<eX>6zf#*3R=dsau?C4Q%~a|(
zXz>_lBCz#uQSYAKJG09+*r?&G;xQ{8IPNa~Z&@d|hJ9xq20Bb^HE`Ja@lkVEPMWJT
zWxU}iQI^S!DI<sZZC`rwG}=ZfY<*s~t?gYsGoRb(`%f>adMRz$@$Q<9KNOzUvpCwh
zzva{EvpBARnOp63XzHGw`q?=XOtQU$n>~+o39GN?Q0VIubnJelhng++iNPR-KsD?A
z8oOR~&7GRwJ~F^_NRyTepRZQ0_@e)FkEL6pbF-_4VLXPJ>-3@g{?41un+@9Au6W;X
zGdu1ox6)f}l}h8SIl~se$=55ySO@wL1gZxLjJsaAW@z51xUe8=heS87x<ih`yZ%L%
z1wk%P=Eq|UE0(!ecI)X(nZNUmqT3eF89dUvNBV`2kxqAG!v+?gI{kaYbBpp`wwtmQ
zbudNu7f^IR0Oh*7|E_g+|Ltdarm=i}SGC>MrLCuHbs61a@XYK^Hnr!UoVs+3Z3W4r
zDa%gXwONn$R!7Q5PkR6E=V31LeAm0rPN!kFRPL`%%L^HuBUlvhRwwpY(qiN{47>_d
zS3Kw}c%QrI&bRj~y}|mqeteeau1@5h>ZqV%)hmrQAB;U6w^eWB3x`3C-+Rp%;A%Yc
zVlPkQY3OhN|Lx4r2TU$~|5)CthSr0)#12V|w(5ip-ahMA$Vtb{;ZM^xuWmVY>r0%6
z!N!^5s%pMD|J2iIK+n8Y%f(T(e1!!<kGs#uzUg*s(A=Bf9G&Nsmr?>s2`D9?l)!(B
z1j-{IWqbagpU}aXpZRahnP{ol)0~@{I1}KZkNPJLc60Lc7J0jf1ucfR6b$tdyLq|=
zxp}z?dU<>LxM89-<`n5^+1X8WvU3oN{oEY=#X=FzSJKlOFZ93^dHJ_AhfPn*LF@rP
z$PP{>v=fOP#6mky2QLR#p{LMG%$pJ6%$`axGuq9|**idl`R96C7T*3|&JO(iaB`=o
zdH)}n8Kf1eP5adI^RC0o@hN!~M0XW;5llh-Uy{n^)QbHayhI)p7_l%=Z0G6iER@b?
zGohJr{Jd&7SK9U6v%EUh#2%ggE-nxiWW~>GrwLF_h!3L6&Z45TyFQz<6M8xG@9EsC
zlILd89636h$p;F-&x5yflet6ZU(tJ!x4)m0Q1+fb!!H=|Emq;U{%0w^d{|(-*av_6
z;6N{m7`gof?{uZ_>_l!sLi|nh@94az;56Ru0mzNs4Uo$AB~3QNr4Ev8%Y#Q?#{S%o
zWQ)Zo4t{px9{gNO0Xg#Z^<DXzLY6<0FU9GzxzF;Y^#rBKm(s(x6!}tm(EF0|r87xx
zA<iwqHtC<`OLHrI5g&Q^(wc~G$=B!nm-6i-m9Gc<q>JXdRlwZ}_esdt;1rXu2<uRU
zb{^i|6CB1PPxG>bk<zYGWl3|<Y2Kw7=_Sa|LFMyJdGZifByO6Mw+Q!fO55-FEe$SA
z^5<}{KakaS;1AincRJtDWjy~(e#_>7%I2iL)Iz#WLVon|#vzZCd-!n4^7Gz`^akO9
z%t`0wfrk*Tm%o?LIpk|MJ8wTbf3ZuK&r@aD+~%Lj&lD~SC*@OV`peV~<=N+aE&WZF
zz1eTIV2|`qnqR-L$HMUWw@>!k!A;UblGEoRNmfj`;jB`rYtlUWt#UyZ?vUP+JCxb5
z#zyETvXeO^gt{Q#t7@quons->Kokz{r+Gc3cv0S=@(LE*JXnJ8L8P*b${T;!XK#>1
zvT~v-D^od+&dif9ClW}3aOL5qG|RzF<pftU&5%~@JK4GTd3)Mn-I~bTLsl5`x(#Pb
zyGqqB3MZx8=luWua`>~k&*cQgv$XPn%Hfjb0mWA~&)kD1-Qv0n-RuCK19u|6;cO1G
z3Q~}AD<7wh^oR7K_;q3Hx6D4R-#Q4te!+WMdo|`DOCPM?>R?D#=$-YacZLREzw3Zr
zDc;=RPv$yMkeJ=i?+i;b$J{HKZ)I|&@>8bJq=OW8(ii?6{{<nlX$U`kr(|olNaqqs
zA0VTpz+>sWZgS&$=arJ3j<6F8JCpbGdP;V#N!_>W6X@e-H<3*or?imyGahypz)qtB
zpY70^I0{oqJ7iCGcAOQ)oasu2eN5Blwu6+0K1_~$8p?_ln(w}r41axnG2dNQ_Q}c=
zl3~fRp`n~CzxYl1Q6{^xdH^dRy&OF3qzTaszsd4uiQk}eo(^tasKOzPGFg}W29n$M
zkc}?P$nqc6h$vcQhsq_A8x;p4sTR|Fye<xEDpy{?43$4?@t*QYfE#L6B?3fll7Bfc
zv!)il338d9ev_47V=zJ8I{-^COL2hG*azt{2nj^G6vOK{3+wmvg6v3Ohjgjqp&#po
z%%5b~AzivAXXiA+Uz#q->^y-TOnu{)9RBRj(I42UkAmwr*qMCfvz_E0*s+w_DLVSu
zPQnlDgu{*{{4qGe+aa0Hh8_9zm-}|GVoR2{NQUK+N6;0=&5*MnE4BYwNBHvG1+4}c
zW%)9a3TD`y0c?@lB|V~gnICk)!$Bmr6Z-ji<LgiU(M|PGb*b5W%(bQG-qPoN$d~jy
zMEWc{vvs-jnd+_dyUZ`y_vtnKpN;Px-xlCFY9nOfTZo|=E|@CIxR75Y^vyz*MFJJ)
zCV=RQqjj7TFA%rH2Sj~Ok^o|=g(L}_1Y(#K>k~Q2Aut#`1BQXu!0BKCI1@C0U$ejt
zAaq4C5`>;ftii>gGl;2Vl9^y6I1gM6E(4>%^&p+`wHaIs?g!U_2SMn#<PI1Q;?u$<
zg1O*!unOY46RZa&g930rXa*hz`-4Y8D=-Bd1O5)Wfv3SBFcqXW#$}Ms4!jCRfrz7I
z4R{;e4&DLjZ0{`aH24st?_xGcZL%kzEIs)41K+MFi}XO;Sb89CEIkk>mL6$f82r5n
zQhF4ElpcnV&n(agr1Y=>DLw2#N{<O3rN?5B(u2~0(qkP+>9GZ*^w<rq1yjLwU>Zp2
z@fwT=-+`1KP;izWB!5bejv%E+SCG=f8l?1a1doCf!4xnM{2iPRQhG##lpb`}J*5Z9
zozmk3Na=A3r1YRO+9^Hmfmz@ikkaE%FdL+HoGd*IAQQg5!M8&wJ@E6VHBrrBz5<?G
zfUUrmAf;nJ+<aSsZ$pqh{QGp)UmKWH!*g4(Du_Hs%XQgVf}SA!l~9|bJ;>aHtoS-U
zU-u{Xn&Ed7yr(N4=G4JAAg0D~$XhJG{t3b_uDlBL8LS8n12w^MU=7d%tOfdmwZR~;
z9vBMN2jjqo;8w5^Ncma-?gN{G>0mSP64(m73$_L!OAdLPg&%pF=@)cMLJjfmpdM%n
zjsbguq+h*2(kBZr3hW1Ff`dUi>vJf03q%>g^ayq(b&zh3U<1$@Yy%3x_TYGs&d~G#
zsjcJ*k~~-7=Ih^ly`1D(9k1rodtAm+dG-Kn;n@t-0egZ1uop;j?F)7WAzO(zH~{no
zEkWcFc6MbHI0Dbx!I9uD&<dn{XANe77z&o;fMY=lUjlBvzRcI7DSS2Xj@+Uv2=V9u
zP6mGkgTZHD2)GFHnF7{Fd?jEDFcj1W!@y49bnsVjCg=dp0zE){4<yULIp7L#KDZ5B
z03HIv!BlVwNaa@qNa6Lt-+bMWuQO732jaam-qVG&q$&p&4Pt1VTLYc|V?d-4w-$T@
z{svNc91H4#8^A<xBX|bf1U?2)#z<a*NnmAU$W!1}@HB{Zc^t|biAs62J-{kpI#>h5
zxvY`~AaqL70=xj4f|tQr;1zH_2wjutBV*qNjX-=uB;CNfV0RGT5=k%cA=n>$0uBXn
z&a32CFdy6jqKuQ=2MfSw;CnD1{1dDL85M)pV7YRfWDckbE&<DftHBE3VNe}>2UZ4~
zq2Q<j>Vs9mE}$kj2CN0{0Cm8lAo7Id4yXq{2b+TBQBbr3X<awY$CcCup%aqsU>DE=
zMA<7D1oi;2%>-u(I)G+iAZQK-fxSQ~c>00ML3}eME5X5F95@6#2IBl($yv|}%mY!T
zODbug4FXmNp@Wj%petwrP5_61o?sB@3kHJ|!31zJh%%3>-T-C0A%`*3Y1(Qo0fp-)
zK8$>ReAT9uMu%3Ps=xl?gx&LQrCqSkeHs86btH3<Z7WNjg=l*{H7a^ianQMQImZ2W
zu1-^ZGhBVo@hL5qqvFz)nQJH-)Sy|@?7FcdgS>`12hCm}8QkXMn>^zgr`y*xZxHng
z^?hcpKv&#seT6r7JB-WK74=>lVQBDc%#k2_(XROCg6(@oZNs;ZnKPMnbK$dF_v>kG
zIH=M4^4&+8=jNrVcQdsSj%?m=YUST+m;IQtnGwbJ$79a_zl|j;I>uhsW6p}MnN@VH
z<iEAHR=H+&mGEt|H}Oq(&$eup5}4|0*sH}}R46pMQhqDDHM9TiYhe{#Q(4w)W)o34
z`#09Ymh~D}Mc1yX%%k|0YrbmZVAJ8}dQTS_U#hwP{P3`<kL-NXCl4)jZCJC*BQzcq
zT}!O!8dpWv`YF0LPvN}<OenrTUR$f^8h=IC;3~T2ZZiwtkJsQTx|UASHMrVHV}a^F
zzXn&)HFssbcD1b6{wliGPvJGQXz&YEH+ks@Y9Bjc`qH!b#-f_PRftoMTy!RJN$CEj
z6Pkv$?1hdHMc1+`x&~a)HO$JhFZ=iESTt(WWzQ9l)`%>co8%@I=!`+z2@QFHs$>0f
z!xIwPhZ-$8v2mQXal4>L;|dQ=o_lTPwvgGrMT60Rw_xTPHSBUeXmg(Vf!C^s^D0N(
z>8jg{bMAfU!t=hrdK!&1M@NgIYcvls_kO(Bh@xwCo7SUv{CG{TqH8MCn0t<r5ySeQ
zs^|V|(kqR_of_#~>KMNvEoDwat&CO^x=S7oM;}ss^0(~P^eVb$ThTSWimusKbgizU
zYpkcYAh}r0>^SRayjE(ZKWdyWd{}&H!v@!iO>FnA8y9i?%Cgr!_;&oStkwNrS%YgO
zpmh83TGJS2?w?<)`){qmO>azc`SBXzB4+N#Yiku<t81-G{{Hi8a1~vfQr2sA6<zD{
zZ>`l;(WCVE=hxsWx`z4RTC4lNvbI*ywb;rvxT1T_y<hBeZ@W*e+n62RO{?@Ze7_QX
z{p`D6c5AkkYkIjS8TCwST!_{?opeZTXYPYNts)FCCV~Msfog-N=NkQy^e}y6u+T0f
z(Y}sb=97^65j%&y@-!WmTifjk#wM7#@)eAdR@pZjV)uA?BjuXj@RJz3!636h)qVfO
zoCCRzQ*PXh+uYJ%@EZO6XVL3~A3`^3*v@EVhVfJ`n3=owZVh+xy8e2j@#oI`-(1r>
z3j>V;)&KizddqsPuA*y%6<yP-T!Z`HwFVc%qRLAt0i^_#5>QG&DFLMfloC)%Kq&#G
z1e6l^KPLf9#l>276)g(5r<>OVp`Vw~!xn4kMYjI<-&W-3Wb5F=j{2juowk9VVq0%V
zcNagQt(#$&PPQK2uI&w^2mR4{e@qSLFpXAvX<`l5L!S!Vm+Sop<18|7K~IrL=;=sn
z{ps@Jx@&Px0nUmBf)fS`IcH;AZ;`Fo+uK8AJJHFupSMVCg)jx;_Vj4i$Epv9;B)QT
z$p_UzMAQF2t)(<Ue+*r{craG1j=9zuY|Rpj9{ogXA!GS>?pQ4*biq4XH$-!@X|B7}
zJhQ(R&v4??T=$xoCXPoAQ&8EO1gy7YYZA0UGFKPGZ;%xy!QUK)i6sp|+>$0B)*G<3
z1{k)HpevNaJ2p2S!v+#`+i^`nOo3(RjdTH<;~Den*;<Kw@HB4PYg?e&eCoq%OKx6?
zStZ<}dHiJP;@wdn+nl_1Zs;FpH5|t1FBf3mJ2U6I^@zsev%*9*-_xtB<yILoW@)O=
z$IxC?woM(i?%_HkXiESl#S2uE8%C82{IJ4zOhcV(hC$jD&MiMNV06<B>M4<T-c%Aj
z#zKZY%)Q5<HT$nS)LUo%{*>i8*OwL#%Qx(%o4D8_u4Q<U>1tOI=5aG~Lq#2?Oo~|C
z&ZhND<I{zeLVK^(Xqnjec;^Eh(w+?uJ30~(QC><3C?%kjfKmcV2`D9?lz>tKN(m?>
zpp<}80)I&Y)czmxH`@PBLN^aPA8fJb=I`0D4Eg~k{^$Dvz6`RoKR|XiF4je}>$X&y
zMCuRVGFg9s-4~Yen)(Gs@W1)t=y^XcyFm6Xgn#GdEw=M=@Z!yd@$Y=RMQ&oZi9%*>
z|0lb4K|()o_Ace~J8v%`-_KBktD=P^w%k!H&@RW>VYxfG$-i66zccqjJ6iT`JO6GB
z?<Q|9oPRfz-26pqH-mpSMCi(lVh_0LtS`tCYrp9-WB>CcIUMEtKu8QMtoh&Q6B!Bn
zQnOqG$kY<<kQim_|NqTC5sFeL+y@aZGtd<MB}Cj33$Q0R1T+UR9iQz*fbI^iH=b?4
zKA;^4vl3UZFE|102g>#+5aW3uo+pBXz{%iXFa(6#l2C9cI1_|yB(uR`;6f07N|t~~
zWVXk_XmB~6tw2nN<Hmq%KwEGfI2Mcp$AR%6!Y0`S+Jjp`2XF`I2<`%%!2O^zcnCxs
zBq`u{@EGU;QlAkz$|Px^7nlJeZj#HOFL(p=18;#)JIOr|ah5y)5ofkn0`yh#0?&cq
z8*mc%9t;Bi1gC(U3dc<aRlsRrC2%^3eKTnP9*H&x8A<Acvq0+4f_q#KD3U<6*6LNA
zF9eNqo2XUu58;O!M@P(Qo@{lf$)yq6Yp2~;Y1CNpekx`E6NIX~loC)%Kq&#G1e6j`
zN<b+Ar3C)xB~TtQ93yT2^TX*F-KP<B8sYyd69Qa>u0pZUYoc6VfQtP;cLo6M;ZOVg
zSLFD8`el12_eT4Hu7<cP;KmYbF0DKECuD7H6<Mg+{@wVgw2SQrM|%#d<JWVrE8BBe
zHV?oI?|Julf9xS#@~b0my428qp=a2aR0FZi7Tfc#5=h~x3{v~X3=QS7KDSKKH4bIH
zCPC42o)lf9`K~>+`z-eTYV_`v_=9KH_7nVKEHw9&+kU9Z=7C(@52rOO+ozzht?1rd
z1|7(~U~!GRmioJMx>i|s^-Mv9_3O3lS1;ZBAz56(?A@H}C(;$)i);aNuh4kwiw*<F
za_N=a@6{=H>v+l?;h&YNr*29%oUr`jmi!3xJuq`!is$V+9Q<eWB!@OT`W6*;4$g^f
zH`*m*#$<_qLVf=gXk2eKqVTy_fBMqWW{#(k=L%2P`Vp(AZnqcIc<9uA=({5s+O1|b
z!ajeP_#sf;t-E8;p#<}FBDYz8%#VI%Iq{LsOKm50^L5P+A6i^q4GsCRhGcG5ic_T{
zAt#<s3VeOyW@5hf+k@{1?X$QaaMsT<pz<a3dvNdYpFp+Rky#_!ROsg7X0~C3{p)^<
zY$oh@tm4$J!`fE~YXh%+ILC48nR^+&)wAENSe5rK?`nvh)zBV~tG!OQI;himuup9r
z?c@#4|K1*Qik=^)=pJn~&~YSC9e-i^0&c5e3;i9!+0{Z_UhlePe=exmO`)D;T=L-F
zdFVmw!^{Pn3S(C6d?lXSe&Cg!6|K6fI7b*}^<3@Jr1eneodq^kuojG&OUQc5)ejtK
zeEnncAcyM{tWJttPKc(pN!XDyHp?m?*$4X}GIM2jKGzJ^f6}(Ic}Pn05W|I6#vPw>
ze?#Wx8SRC=<JV4{@ZoaW6rn{F_L1#O@x9!su)B3iUgO18YN;KySvw-p<groq-0=G*
z8kYmC-V~y9NYTBFrlXTfpnA#Xc;{A?5>uTXT~BMU{80FG=Q@sR5#1NO8gPHpr7o4B
zQ;P0+6oJkofog@!t~=+i7@zvOo8g)RS~0g;uRA<;v#|2nduG)fQd+qj!Tz_*-^gm^
zh6=+EPCGTY=_uEjI_BI*iHmoa_~2_Ttz(jX*4W~k!1Vs`lj4M1r+mGd{9$MA?mN4G
z;OWMXE1rp~Vlc~n>Gfb06x53DWu)jHMT+i4rs!Tlfn7;1r!;F$nOZO->|Hy{kK*v5
zqeYf&bz=gX3`sCP&}{bGC+HkhbkCj*%)RE}L&7z>h@)!6W@h)?cG<b^+|ld%>ZRPi
z=yB0NSMP2!?BB`E6|c@)_-N0j(42Rx8gAB%IAkzU<w;04NxZ4viXl-;>pS54rr_Q_
zitcSz)_ayIx))hL6O!|f_tH{yFBy#<<lexl-BP;bY+i8Yw%L&+jW-`-&t6E~w&aTO
zptqG4-YV2IMqjQrnVT+|UhBr|(1~^p?Pg8Bm>5v*lJ>L(G3&(@8lKz`xOxUUcMmgj
zdESQFXRkzWUthWKx&2GEs$Q#;`e^n!d~eeJ`0&RKjC?un6*D*QgHB+Y!S0JDvmd<G
zxu57fK0V7`G(2yC#)P=eHiOOTBi-tfzjIGr-L(Isjqy0EKYsJ^GrPX~#)4S2z=MlN
zr_Nt{UOff%9(QIg#CK2Durnvyr7ug#UX;D^K#^+p4#C+uPi9XJUZ?pg7Us%&ub{Ht
zJ4ewyan7@HNSK!4_OYW;-T2&!E7G=&@m8JvYMXZDrK`hy!&|Q~*}f9{1ET^;`VyCQ
zBELc1gsQcBO*7Sr4sSmB_{84zng>olP`=y!fpHvnf|=Xrniw=-+Avp}Q;pWmw5hxB
zu<>YTqc&ZI0V~t;M!x#xDb{S`+b>Yn-Cc2etcK&#=B-m77a5rhtsPV4?wQJVI;(tJ
z>la(@GR6E<W-e6yqp8M9dzGP`GI!iCA2TiN>9wwRItDze_$su;s){qv>A!}V%i@k@
z=e3Ne`=ZhKKBpYg-wzF~b>qq9wTIiZit%uG+6(3VIc9EtO0C?LHqYjc9a?ROOUn*3
zf1BarQxG#_c9eeT$^zANd_P9Frtlq#Q_CFM&a7Pbj)V5~I(vQYYtJXKQ@d5OOLQA7
zXzHu;3iTHOnfvkHFCommMdJG-=h#R7HhYMh{|CLD{kvEUGZW^AG;_H-;#^Ljy*b!p
z7JdH$)kg*8Ubl#Sxb4Oc^~k|bO$Hi2${7BvQGDA)_BYg;oP2%_-#6x7Ws7aX`8io>
zm*0+9=#p4_YTLt3UDX25Ms7^h?kXHVG8tnNET6wj7@l}|Wc4xYSJj)KF|AziiQLmm
zUmI&TUg}`>A#YABD*ArR-#hoGHm|WSyG{IDvwj^#BUCdd+-!V$lkx4u_?xM^E`3@m
zey;s6l&Jz$?bPAre;K`a+QCjyl@^Y&u65JaKS0eU!n%&>se^s2N7-Y4WM=Ni=eJ8x
zcHp}(WWjsy3RCYKEH6GZ(KgTcUdV$1ts9-mTy8CD{5tbtUyf6B&lyGcl8J0W{{HU1
zH_l0?LyzrA(Rl-JWS)FCHp!%I{wm$Y0WKe}*_ig^I7Rmw`M354nbw@*VK7p2=h#h?
zevdo5qC%v>-F})gclF=1qFmn=3li2#bZ$4mzS+#&*sL4jsS?|kdz*F2NU7RtO7-Ze
zneol6L(lHsqO~{uDbnm2Gq-(s`M05i8%z$4Z<*Yn=aP(v0lKdok0xEzeII#bndLSN
z*eQBm{Y|FNV;wSfi-x?M*2bV>ztZ=5__y|O7}S>J*FUMnisaVkM?5Mh^nZL)XRK*q
zP)ye$mUj(@WrYnMFb{PwMfXxr^xX4C`sDA*525cZdRo45b2@%t+oq-OyG;w$t#97>
z@q?8K<G7p{)Lj(a14F$Xx%X&-=tbg=O*^d}8!k_%AGYVN@0-zEPt4!4t?S3E)gsyx
zBA1z~pPUiYc;N|?Nk+--lN>CHs&#L9saxifS1qk8G;lnz00X>=?xmpUx#wuYDKDi2
zloC)%Kq&#G1e6j`N<b+Ar391`P)a~40i^^!NdR52Wj+2c`fnWncUIw}>;lmEy(8{S
zjNx+^XkI_Y|M^g}@qhZgl#7l3)0wjL`vo@s@9QrViE(x;<~!gWoiR#h=QeLcXJQMT
zCP?4Q<_C-?N11;(j~0L0L--i`r+M7$Qp5N^xs6-$3rO<=nt~W6l%U&$jx=Rw7-H^#
zq&J>xfYx9w&>pM<QoPWWubf9<S~M{}A=z_OW7RE{_L^^deo?ji-W8%Aug69j6ktqK
zIgda&kKkv{qEpTzST2sL<tr=@dfa_J_D#2AgXZ3>fq6>D*gOJFZ)=<T#gluF*lhf?
z!!Pblb!K_J<!UrJlF*>trqsjlhb!k1DCZH>)5*mLOF56=q+N%5ix-?0_KoN@$31t|
z?h$#zkdKt}2$b^(8ev|bavp(l9)WTm!PWP{i{H;%7G`6SzxQAl_viYp+*hX^Hp2o@
z<varAJOb<8SW~T>N1&WXfW8jprIdhD0!j%eC7_gmQUXc|C?%kjfKmcV2`D9?m;`A2
ze_YwF{~zz|;VcYv68ebc_5k4QKkorhfvd^R1yC<>F2GP9v74t`keipQpqIC&j~ks0
zK<oG~U_C_#>ArM=QpWLV9lwuk9RIWLKOD=Kt>sT8`}`0-rztmvPp@QS_dbvl?*~72
zPtvW7+nN5rRS{$EG<Hv8__DEkEbm}z`f2Q*#_YR+G-gj@_cg(hU~Q20l*4j4Hilmh
zq%nLfwPR!W;fQZB8)FNtvT#7=mQAO1#g~V+eCaUdP^ZA<0Z~hyXzg4$d2ZiLj}>2o
ztLWO=e`_tQqHA0gUAwC2T2n>Wyd!y(mr?>s2`D9?lz>tKN(m?>pp<}80!j%eCGdYv
z0wvo24hHRQ?E<|0CfFL;ifsFPiG_ZiLT5Jzu@DFB@dxdBxH&p`iraZP&>r?ae%|hO
z?b~<lV$`X<kzso}8qk@Yzvm+M_UItj{#S)$&_<SCnp^{JxPQ44?f=rw1-v3V4*;7J
zei=AAnNSucI;n7?lSu5~C-(QTb@X@hKqzohAs<#d{!~N54zfc7zjjD=h9J-0!inuW
z+B&-7xI@DZvf~8lz(G1r@FxO7K^!mi@Dcj)ClK;NVJ8mA&KuY+?a!cn0qG*rKKohx
zIsrRo#STX$+M!FuN6h*oWPKq|zG3%eNxN{9`Y~jCA=;KBpRo5B4@P#z!A1Uz1NiCI
z0l#VDYy&O+-5^7A{&}SA*@Azzl|FYg;Gex^&+WhTvpOjNuJt?^$xjJyp5p0Go|2!d
zrEYYQ`jIGo?ke@;fb1E5kogqZv(*0YvS;igM!#3Q#NsumYbXA>s_Yr-0O<GHvS;l7
zATOs_X_z-l!%U<w8}R1&w81-aV~ErZBWai-WY5wt#mk<hVcIBr#{Pa}f2ZtO8pbr)
zGr}kzCM(LYxc2d2WctFJXL9tA`dKJ-qo>r5>X&&r^pyJ1NcJq1LmSyM<UnB($)0=i
z&q1>1Ui@>Y>=_+eWPYCP8R;hLH*0}#N_Cm(HU*p15B*#0(t`@nA6Vxic@2_zss5H~
z9(`#N7=bSH<`XCn@ag?YpAmg7N}4wiRS6zBL{WmiIj#$cbu}Ee!I5BH4TnBCwil-f
zh@|Dv6)4dH&A=KUqAtPu8g>>$9S~7xdv^8)DGq%=Y=y+mf@lKv#WTgBAJ_)$4<fAG
z01!#f&V)d6urnbLCUzzS#Ldoxz}8>vOb9d366WC-I}-wKu`?my20IgC5Qx4*c1Fc0
z5N5ew!QtR&a0F-tQvc!@5WjKgW0c?>J2L|B*qIU3?>G+cZ9#hwf3ve9@Haav!Vz@B
zdsomIbOVLp1keTa1o4~13mgx6gYKX|2s7;L3lDHIo?(`yFD1S-&wnZlAagEXnqIIg
z!6Q3Eg3>Dh&y-$)U}bO;SQQKc(WlD6ZI)iaAf-<TSQnfE)&nK@*8mI!1z;FR=`;;&
z22KZCf-}I@;7pLxZ8k{hHU~5S=YphH^T3Yad=R?CEdZfQ+(NJ$7!E>bxFsO60T%&6
zC%B~`rQ<S?(s4OB7+e8T`mF>h{Z@fUQ*JeA4Mu^KF3}*R#~Ki6!Nq`-9&16!np+1#
z#w1gg4!?n7Jja3)!8j1I<2Hbh4HpkezyuI7;WmPh1-A)=EV#`eWWj9#5oc~Ih`4gw
z!9`#axES04B97cnFcM4#5m#<Eh&XV2K*WLD3nGkEUNJq;F88S%CBN8ZhX1SJJzXg<
zM?40S9vlZXz!P9)@Fb`So&qVq{tngxPlKcfXFy8-RFKmDEZ7h{2U31b2OERuK|L@7
zYz}6EEx`*Q>A^)%AG`z_f|o%`_bZ?YcopmkUITl9*TFvE4X`hG6C4EI0*8RN!C~MX
z@K^9IXa#10W59dhSnxh*2R;BDz=xm{_!x8nv%&G;6VMCH0e!${pdXkE`h(BG0PqDE
z2)+bK4_<?l!9TzdFdv)>z5zqQw_q6f4x9$Q2j_x?AatKA0vCcGz;N&*xD3Q%O34ZW
z2wmpNfvZ7Pko2GexE`zs{syXn&_PZegzj+~Ai~Dc`9oR!_v_QQj^x=J@9ENlIU>%9
zVfs-MB>kubl77?%tAf9P)xbI+=?Tu0Vfs-QtczzIupWr>Wtg7etRjg3&keyQU?Z>@
zh;b*T7mdNTc-93;FPeY`U{kOI*bM9lHU~R_Ex;~dOOW)X71#r84Vr>&LDH9Y-~dn`
z90(eKq&FSF!Jr{H6zm8N2aUi{U?*@i*cl}K=>n4ebOlLoj6u?uZlF780(yYmL0_;3
zC<0AE(ibz3^ra^l44Q*ez+NEfMQ?B>*aw^qT7aY%eZd7_KX4J)A6yI$03*ObAnC_o
zko02+xDp%+lAa6$W5D6yI&dUN`Y{TO1AhhM!O`GG&<Z4du?9DTHeeEH3+@2Nf_uPm
z;9k%UgpPBRRy`2V>MF0oj2?DM4ZoGyuai&LGk=Uk-l#+GEp!`LPw6;i*AZ2hDHXSf
zq4>&6DS`i036w{~%5?vKI~NR_`-|N?M6C61%$aDZ*nb}TSO1Bz{~FlK-_CBLlbwTD
z?C0j_FBXch#$Hd0Z&J&@rM?9{EeA23NvEe}+S4GgqqBpNLkENQlx`)@1aOqjCD^M%
zzw&L73ZM?|Iw+jOud+P>?Cc!SufXDCCmQeOBDQmM6N^lQUjCi}`QIEIMPfe(C$XKA
zx0l$@+k=Yt@0=qbVC56-6`&4t*Sn*x?Iw0{6M8t4J(`nHMf%>;K{P@3t~&jJ|5!lq
zC$+D}N#hYL{U+AOds#fRC=^%zT0GE?BK8;cP&f{kz7Yp{|D!m}mBt}K72(AND~K7s
zU%2%Vhm4%B;s9ZLi9FCHMd|V5<Y@C%f_XYPjd$}BvR;*vX-4^>l#8XAZ10DU2&Bl{
z-_Hq7KvY69Pw7eNCik0*hl4Api}#dvl+Ng$!r2&h^xiIDywJ-IdrpvDGE?hYX8gUF
zDN1jdtS(6dDKD#5q__V;Sp|0K{FQzyBCCS$$V%?FGMCj%sa_RPhQMWvoAiq6WDOxJ
zpXYyBulVfoeYKKhA(n>}k<;Vv$Vu+EFXTk|>qk0Osu?+*lF3O=4T8ZXFQ>YYlfi#Z
zPNY&lEvI|mk(1nSWiBUK-m|1a8yD5(NuQ{0-wATEeD<^YR7xrIwN8EW+oFh0QJM3t
za!T&EFJwjK*N=3nR5PXMR3J6TaLMabQ<BwBms9ex`d0S)B&wg*Das??l9SwTU&x8_
z<d5W3su?*s$#g2V5-%rtooWv`RsYL6C0APi7w8m~^FNYRsb=J4B`c@WsBw==UZ(^k
ztG}#MpNpaIi0U8FDJs8yB&Sl%$jM1ow~eIA2rl_LA=PcUYhRU9u>Etj+lCzN{8HLg
zc6D1>JZ!7-{>aCJ>b7QI*KHMy$ET$HN9woZxN2GygCc1>YT|FIlF-W>r1#6GEIq{D
zb|uQMuPe4+7lM$(x6^{}2a(lTsVw^B0IT22+7NvBqBId8T=L<21Unf&AHL5S>L<cS
zdR<!h7E0wen>z7uJ;qJn-TS!9!Tq)Oc=>&56G$ucG+c@q=x*L#cGLv<TAH84Ew%7<
z=KmBN48DG9CXl=p`S!}S1EhATeOXzn2>Zj)x0gRVPUbG37P7dCrMc^pG_Dz75$xFC
z{g200?!&>i{}hR<Ts{7$<7&@x2kVb!>6(YQRzkXRkN;v^OG&k_leT2yD;`(5dec{N
zr8NIux(=#=c;U*zO*(uFw>s(YgTEP9xm5e7;!0^=T3nY%^Q(Xg5?p4uDXvtvAsyzv
zm0#VwT-?0e#FJ!M;_u{GIeCyODVk?X(_?CP%i@$TjT6O%;zV_SN<Xtl-$=h7$4REG
zav@eE1r?7|Y5FQ3r_<E&fXfm$#c2?3N~i5v--wfspU}xoMCGbf|I03+$|{|rY9kW3
zC@vJIez+-}UOxQmar&zXrD&XflukasAQHH!Ly+R+ikrTF;rG80CqHk0FJ~;JDvM;I
z=||Gk{+aw#+BZ;M_j+Tzg)aFxk?xs&OZUn$PI5W!XX5muGD2IMj}xU2rIQnG_C3q~
z%jqOjJ-Jl)XUmA(QsPAUN%F1y^y74r#Yrv|{+T#Uk$#^})8H?zblj9qsko^=Zl7Bs
zo%rU$cM3V)z}KOdMUj&2%QlB1bt<_&Ki)FJC#yeFpM><=`{_5zSF*Up>cB8A`M6PC
zKAi7Q_}qWa+x{DIqvZSfxXJa?eG0##abtt^CF1r5aTDBDFx|dRmamiUQ}yuY<0jW%
z^i|v_O~03Jw$#Wi5x1AHV{q#y<MugO{;{}GnwAzf*<962(zsDGnA*S8jiZJ##DE`b
z^Tr%m2eG$bGrayzo0jiipf$R(u``<EK+n|OLElhEkn)1e-$4!V0++nMFJLZ%%~e$S
zOa4+C%lk{uCH*}i^_QAA6klq-)<%5oud}rLOa9XLRNh~DF6pmHLwJNsKEBo9?@PYF
z<S+S4dMocQJ(u)1S?aHRd~3pA?r+4GzP0lH(sN0F+caX){UW|q;qTGE5ns|}d4K7-
zq`$GH_)GfCeW}mE6gsK{@}VsG|Ih1leF5)=eEO0;ul-V=f68A)^f^-MuYCHFJ`27~
z-=FeV5q+-Gn2)c#zob`3`F>29KL3=zis;pJslQZ3rTj}xinj2#dWrOf=oL=i*03+H
zSEZF#MWy&#ANIDFNZ+6FSEq!(rIlA=T|@*|ecTjZszP*yJ+l(&`!oJ_F5z!!<yEfK
zUwJvVfW3?_^KbCa_}i?6zonH|&NR6XmwbFX!d_Mhz4{q{JCyLZwDRhf)L;4dHi5mh
ze<Qw)OZY2aUJa3sgFEZ-@$Cc9x3eei3a}^mdOUz14ftFK`rP<~9V*MDL!fw)zxc9D
zwx<T^wycAUzQ?j~<VwRKAOGhtYtP4DeqK!};rLXg`eB}vg@bfmW=lRC;--AqOUlFS
zTXTOt$wRKm0w?~iJc^{@C@GIDKEHoQ9-k|D6q6r)V}2x$>8$3()-!yeA3k5}hishX
zlSJeirhi)=RhskZQc@n0ul1wUaLCg7@5&=m8jh0svHffP_$nOo8uEAbqkfCh<snc&
z9`YLUSLM+|+FoXhS`d^rxT(EN!74`HGULaGXkL?i%Sx8@nLd24y-Rsg=Ep;6TxtG2
z`9WDD8-5&p!s^T={g5T~Px;|Nj^m=a)YKhM<=}hx!F}zAd@?dW1TgmXr5;N2jVp1+
zY;5Njv_5DqSQf^4^5HHfL%R8SdwB}I__ceV;wlXXef}t}4RPOxc^|%?NItIe$@rbP
zs<Sz2l+S65iK-DY0m;i)+zLP78jhRF@gcY?<2&HPrz7T?eLEegjaAC^$zO7hzVWie
zCpl19XkPiZ<WRmf?_xiI?Dxj~7H+)c)1zc~WKm*rP$WF`?Uz|nBs^=S;c-SdNI!nX
ztpWL1ejT2_tRJ$nnCb`evigzEm{8`!H3m0@Z4mBPaAPg6GxD<fN@oNx`}Os;?#jYO
zbqIO6eJgCn((+-iG;DV8gwoLlH}y}ONymHS#<yirW@-41hS68^EoFs^%rfb;%<qnE
z`Iv=C{hk6+KXS$$zTf0qeoMPGdCQ;w|H5xdqtg7A<>M@=-y*5s-XQh&N~B{#-lb=!
zAL?&I<Q<YD)uTRrXl0Sd`)2q(Upkg7{Q%({vae0b=Y9Kju!u{(&P#n~oV4%k%dpB)
z|9f?dFXtGrcBE`FwA8x1|5fyv_q5iH>Bv$dWW`CxKR^5bMb`SEo+u)#mp>`1`O>h;
z%ZmEqs!RLgz6@*G$!fSXKUo>@vhoAy`{0F}@{^@hr@xx-;4Jj=_VaY`kPXz>x%hc|
z(iCSt{l51Nmdz2NvRgV2?vtjGY^e;V-%5HxA^e3?*P`D>u=&uv_!;mNR)ks>mt1LF
zZ1JArVuhRX$jg#_wo+g1N_u36=`k!OipPcWP06@Wm@K62A#r;I0#{$$l+SwMz5_e<
zH(8k>U+)$M`Z#zw+p$3nnRJ;>lD$$cwhl}tQwqnIHhI|$kcPvo1MdRKgxnj6`!4Kk
z|2iC0Cvfui^u*BXmo9$0j>)e{`(9Wmed)|XCNH$~zI2)7{dvv`<;s%3^ZC0vb<c3M
z4C#Ni#+Jop3jV%<xR~AeN~U~V*m4OzO{K%o%)Z=zOqMi1UKYkrCES-q1S=17rSX7}
zuy+HBL)L->KWQ^R*IqUU=aXCV4H$S%aT+5{pY75($?M5&#Ho7e>Eq%f9S@;RG@SW7
z_~lF_xUXn>QF&U@vb?+lJMxkW21s`TabJcV3EyWUufrtoPlXiu|2=uj()`Qv{L?TN
zTdzQ}rr*DkwbU1xUVY()T&+Yt9!1i4bVm3q;5Nd23vOq8tv6K1`IMU9Zqx93PhlXr
zeCr!3ABJG^6c-f>6b35(uObXw>0$UnmM~S?^+h@Gg&d@|$^X}|NyQ_-=7|3`Td85a
zEZ*r!U8N+YFrmnlP`{ihD6_}0cHqz1>jyXZbv68Y8}g6JWfR<VVXA?Ip3w$pYg{o@
z%GR{PZ?>kj0Z8j}&;`!ILGJNuPs+|cetiZ%&-Z)bqiQFGkJ638N7<FaN9#P~!^f{<
zC_DG~`To4j6bT;{^AtW(bqZgX65-?L#Ft(8__^a{7e0P|b=icERR^xoH=%UB#kZL0
zJKBOw-}`_veK-4#zJJdiKhKt*-x?0(md{_vXUxB*AbrT1$@$06fBiXo<KYHBFO{FK
zO8(Ilf2#k`g}lS^moZ4=INd;!3GyG?yMyxkL_AY|UkOrvKM0zEcR}=7NbZB?AjyUN
z<L8F5eF`{5{G(<I`8OCO|2#qRZvjaDZ2`@|b0GPb0m}Qw&(GxNZGO+cDzHcKqx?z!
zQG1&Fn+%eFYeDkwBxnZafaG5uDDNLXN0OgAsfd5n)FJ;YLGsTJB>y5o@^3e223`Zn
zzgwWpKPu1od5X*olP8sjaF1OMFi+2pAblsCK`L*AAkviWg+gZC@J#7L?(uU3c{eEh
z-*S(-AIQB9Ah}2GB7IqTA#;!7#Lv&;=k1YuD8gCa3BdM-A@@f~?TrR0Jg8%`Ju0lh
z0eH3rsSjZ+NZ}-R`8jfY-@^CYrE-kiMcOiVAv=!TwE)RoinGjJ_$!^K#?SR4ch&KZ
z{H6<bm^@L(V&UlzQdkg1wzt7Ra2%dtUILl0J#t(@m|@{2_xU+v|2g+L*2lunyZc`F
zDc%%*iW`N01W4f@15)^*J1qQ8pnUlGxm5od_n|-1c}@JBAPRpayhA#%i@x)C#m)_{
z3f9GQ8<4(N2s>8~bO-B$bHD~*0@x7z9c%=qf&!5Ai2UQ{8vS$r@$-NFIsf=MIsc4*
zkgIf_3_q`f>KiI}R|_{?e@Nvnz~B75meS2pzNGXabM~x_z^_9o=^pL9Av4F%8!6qr
z6>{!z-*J!jB9XawRQmlUJuB(&TzU7{I7{jN%Ey<V_fWby`S=RH6F&L)^79Hxmy3Kn
z_;~=Vj{H?T<ip30+m~)mK73}<@F9<V<(_=__;K;l-IGrbejNLA{YqY6<m0hcnjR<v
zzVcU=9tQZ0A1CI=2Pxg;>ra)DzUnYj1?&lGO4FO{*_Uu%-ku-Qy8_IJz}lc#n*L;u
zABQd7zxOal{{0D(e?@Zk_;J(E@{#wCzSra*%3kIleP>B8$v=LavvmJzN#jR*3Xy-b
zmypb!<U8>TlKO|b4)ZTq&Od$}v2_2+N&Qom`d2~DKf!nWLmAEDH$m#3htxkagqa_w
z<Hzr){3kikH=HioONh#U+C!)sNcvF|q&<RKfV4*t#n%isKNg4mjPQ3!cW5sqa)<U(
zB6k{s<c==b6l?;LJ6&+|<8Ayn9Jx~-ujrdY*9U~V2KW&qf6Bui$({C!lG*3S$*4bv
z4~M+{=defNKpm3p@%IA6w~BiOl6|T#@Z(+lI2id)`h@Q@yJ+ttdhP{Mdw}*jqIl4r
zM)>xzJ&h<_1M%D&q`i%XfV8)f%zb|Rim&^Xbf5N!BKK);C~}|ngd+E84=8e<_JC>z
z(jHL8V0)1Kp}nBUeKXwrcoeHEew7ZDV6FztP`;#aQobaaQ@$JlRs&`3@MA~(m{Q5~
z%!j<loi`x4^A@CTk^-<lNcoW5VfmGf^I)GPJd-=}`ED1?QG8M7W@nx3le5Q<(eQnS
zCGBmI+S>|Ff&Cp)dlVObe1(-A%s=_`KPR=94pO<60eXWML0NeDF%Q0cEa`7Mn4|om
z526l4@niPLUw*8D?br8}zsF&Y;&}oje@}r+LDY>t`OA+Vl<qHN%=~QylE1B`_9Xb5
z@ApSvGXAFU()SbPCA((B9A2@#31OG*O-Sjq5bsUEMPLsw9P9%w0ZG>*z#(8Hh%%Aw
zO^7mt?M;ZXgY8A=1xDd_lA9%NzR#YoJ5o6CDfraxfE^YN$Xe1F?|s33Ai~V{E)#*j
z;&~!y1qOiRF61licjx=#OQy$b=qt%JAM6Ewkm@hF!S|E%d7A8zIaxmD%JKHffmHse
zg63d(Z~#~l915y|!$9mk$o9<C0x4V+cE0cWvwo7CNv3rDCJk3CSRc=EAjKsfr1tG*
zkn}bYl*N<pH!eM%4`GhN{}`lrzL46Za7d)}gJAqk@stn8VyV3)AnNX11W0<Y6!ZsI
zf`Q;FkitQF%=fLbeNn&C<83fU`j5SdS$UKMl0NN_v(NX7^8KY09{KziEw#S}Bt4D+
zk(ao&Aj%Z3OHGtz5R^bQ>-`$LUUki#n%+J#z;j5GmJ6S+R<HP?|8tL}TcUHbtA=6h
zm6_}Gq5S^No6egJ+S{&p-)}QJ?kcy^TWys}<E=Tv7Qe~YE5tsR%-qxI_bY~e=$>tI
zZ@~6w|7e?`+f?6OaSya_yFPJA#~p*=d3gc(`@BWMMq&QA!a5yW-roD$v~F1k=GRRK
z+BqsLzI~6-q=*dkKQnWUYc$w%rc1>)lP{WUavLIAIO%uO{9xp{sB)|3dNXd$jYnTX
zdvb5SQFPnlIfF-f_ej6+G1BR7Y}ml!Q>TA#cy3YN%XU+?Hb$Ai%q?$FSIwg9*-kYF
zCaX<6s~;LX;%vrP@x0*{i$>S&a3BqZ>aC9C-jm+H`+1m)Jm2;1v(stVEtUJL)AB+_
z=Li-Byw!<4mb4iAgEIHtd#^Jsni!vu>^Z8j>Xu4-&9^<jsM>w+3Q>>OV<Qa;kO|*0
za~Au4HG20-{K2zp`w4zA7Mgp?Z9i0H^FXfdhtnFC?NgwvW=LRx>cXw>4%D6TX8IF@
zkxu=4bu1dS>9XgFM{7hD%}sI>3v|XHuXZ4F!QvWsE%kTjbgi=N>Y0KH>(^`9uU@+M
zL$bJn*}FN{Po$%4V(}=@6*pU7;mzF+<8pOHz1Kz<8vGh_B*<R0EB?7)`<_wTuzxCZ
zuh4kwiw*<Fa_N=a@6{=H>v+l?;h&YNr*29%oUr`jmV6Xc2bsAp#q;(Z4*oNGl0%yv
zeT#}a2j|4L8|{)YW3t3Qp}zl$TiB<R#lyY&)0dVub3BbaS9rSCk61l*yS<>sL#Osb
z-yO-&ZZ#7P))-_0f$DDE9fJ-fn6DGL&H7`0^fSwek91yYJE@zmYkv69;__-J{Gw37
z5U8r1)H1s9<d9?dNG|zZX0P$jF7B$AF>1fjz!L!@i#BCgW8YC`ZtnT4-+wb6Jm!8=
zQ(xEjtu_4?<jgGSFem-#<!L8u>e#@&v4-T{tQ4n8M?y|KpA`7|#LdKf?Y9Tt587vO
zKj5sNWkBUiR7NR!7S$W(@7s(e(<NcL(XN6*3oGNLHrDgR`MLv!#v1<mK|G_`Wqe3l
zH6ed{AF8)YJKJD?<*YvW1Ns`xT%-Q(@_@azEyH{Q)N2$KOR#?|3txtB_3U>mR^`3R
zyBcC=HMGa$YOm9+4(fCs>{DAuJ9&dMzVpnz%YKV%k9zD}Cr7+n?Rxx#7mv+irc9Xi
z>R9l(XBIp9N7cf16U@D7+G;KVh3h9ijC_84)uxn2hgP4ezy9Kc-ScjxU9iu6iVr~=
zb8lG4wS%2&Tv@&<HSO8n^li!A+St^o^k?_m-4`@%IQfLD8Tu0SC?4@KKEJh@74!S(
z=^p0&x#^+9ca9j<px+C%U+Z*fJU@Kfb<}m3{zbN}EO{29?e)~C=t;#v=g#FA_usiX
zP4&%i^*zU@v{*g~bzNqzp=eNpW=*r}#*Pf~8tNQ0dx2zdn~!hujAxu~U)Q`r)GO>`
z%lr*HloohsbL}3jdd9cvVlSv?xM}x8Pl0b_>dS~``IB2NLjMy!G|0d6n*UPkZgQ&R
zypMlSvAIpp$t`Epj`n*!aOuGNb9UI}W1rz>WbVMW{%JPTjGND}9FlU|K~ir0{r&e&
zPkNzqdsx_s_G^-+VxAAv=M@h+3*P50x^qo^bL1<ny@q2eum7NH5w~Tt@#Z#Jqf`;!
zM$O5+9hFm>_-bj))$|F8IN-_6(V98=dgrLR0pSmtT<bi^XAkyEX6^~rO!{zOr-rXs
z(|X5^wjML@2Wv)Ww9bn<*jVI!NUs?xUJYB2dr|fWFU^|%;%WM`jM2gqqgvcqe_3a6
z;BB8R8CxH5<!hfo_&Slf@fW5q;I<mJ(BC1PT`kn*^{!j?=YpEu6zW;VB@gbMr-eE+
zGZ$<sj9Ibsm3VIZfmeD~wCb+n9ATK%bG1v8)<d0l7T8q5p7hLILe^WZe&9gk>mQQ`
zIb5G$byDPVLNu*S!j7D=SylnbKB$H<bAA6<-l~SygSf;FNsG4Xgbm(4>sH7~$IRhR
z(>AYeId$txjAfw=6sX2k)qHdQsi)I`o_VX5i=%4!3JZiDcb|`a)9u)xxi@Kb#<T@w
zuFWaYmNAb_kMw9}yZz$eq3UmEe|VP?-Ke|Wg69X;xND(;6VKec+^Mj;bxL02#Z_vl
z9kp3IBGKfrQTE*M`z9Kf1FYT@;`=d@rAJu1JJFBbCwDQ)NK7xEUPmRj-^1vZ!}m?o
zjc#8xw25jp>_0t>{JmszymPBciK$MHuBSCvekgppa~(&ui0%ts4Y<GQQkTleLyDf+
z7Xh6Ss8-1Ax^w=D@u{!78Ll~?6?3cgy2E2P3oD<!XI9N2rIpJOeA}77k=4o#6^0+2
zc4~0bQLZs{%(;&e7w<0d!Pi<^$0Yl#u|>W_VI)vJ{G>SH)+t}FCV$wOyZg@WA9%X)
z<BDhEsu;|2UwS=Qr84G!pz<nEy`5YTn;gHh>d;r#U3<P+GRfX!;_mBK&juOf{(ft1
zgBVm6Lz%e*6aAPP*&8cwyne#@5mz|5O6R%<-|nuaF{{&Tzk2)AkvDpECHK^C7thF*
zylP#0eCGq{LzhKLKCXSxO8v&2;1u`tv+7GSu|G9)@2t*T;cq>cg&XLd-@Cni+vjf&
z8&$Wh9@?eot&d+nqrPu2HqP8TrCD>z)Pfmd@7h^@6o(HTEwXH@8xz=MNP_W!X0zWu
z*@`v-bFbmX^$%Kkzh1FrQhA3ezgKUOx-rSG>#EUF8!OeQT2Cjp2KLcr?llh|60Xrj
z991JWGrQ-u%g%M@j$YqaFXi?{kBbJndUp|zyUbki>b!-I_G}8xdAF+JX3dC01`}1D
zgmja{o9e9?61B9x1L{MlunAN*dFcphA3I_C(zE!+qME-|h*OVTbS800=>Db?nufOQ
z6@$9AF`4Tyddu85CRQ4U2am1uyxNC({rfa9ZJzQ$JoUqatoVf5(@^JR=DIG-FK8ar
z@TS$n`s2b3pWMn8_tD+Ia7A?ZkcgE!O$Yg+8P3f4U9CQ7`gDu(q7m7`xSsbUt@~8}
zJ-+{p?CZ-7%IDkbC!%fJjr@JuAS7?FZtC=f?W@P0wCiwh@q*LBz7f6VxaY3gJtA)y
z@=-q%GS^4#NdL9vJ6Fl7<C+$8v1ms61N}+oW`}S0xV(8mg?+tI$!%JX%vDjhFg-Y?
zNy5x_quti%8{DpSu6uH<hU&wjja^%fj%<tcpt+X<)qz#JrF6;Jyx`1jvm;3wZ$8GJ
zy^y+X$ra;4Z!0alRj7$LIBJu*>5}QSZoCeiXxGqg*5r$c0p%`fPg@YPUR<H!$qj+4
zXB^_V!^~Wsx1sjgE79B6S1x>R|5B~0*XpD`ntcx6o3uYZ{BZ*#$mJC?H}8W^V4A`1
zizc%lyw$m%=sZ3>%U(1*Z-K^yxXw0%&FUlF>XN^6PhH)#|D%oZIIBN?^YJsgzWc_4
zShc`|i$|x<Uwd9X1(joWW-i2cPu8$AC)=ejOUYi8z4AbjYW5Dn**Q;UPYzzE`6?FX
zs_2k=j`hn8Pe^DVYP96U#&O!l?SdYSD?BuL?zNfQLT39G4YtIX2{YHIVVCnkoAb;M
zyjDG&S2^lVSKVHmbMHeJp7;IL(`cl50on-&qd@h1!UIRo{aWK!F27cE#b#__{=pXu
zvZAj(d=fe_x?iSnJ?gQ{oYSc$3C&-XJ2FgV)w;KPdT+Tj?VQVVy})u$yNx~Q9&{Ia
zU&PG$Y|(1QbsH%**_#<{@OZ)QTSWu!9%-Ul%cxV5%j5lxBCxMID~E(>8Ezjt8r6-@
zt+*m>+Zb=v*{`-~S6;e0%s0IC3X|<C(XMJp;p?Lomvth)LEVI^wR=r7)rk&oKKb~>
z-u0RXPCrn-+x>xYs6R7v`&<))222~~YICa5x|ue07aleq?QGPht1w_?THeT4zdS|#
zz7e^nySw7{SPjRe&0D8FE;2G1T05r7-7}T#bXNJc)-Sf)Ws3eEW-e6yqp8M9dzGP`
zGI!iCA2TiN>9wwRItDze_$su;s){pCW50c7E{i*so!2s=?u$m_`<!w}e?K&|){Q5Z
z*B)-uD#pX%X)l!b=a{+qDYbG}+B};(c4)OBE-gFE{B4GdPeII#*-`qTD+^T9qcCQM
zx|l%qP@G!k&~|3!x_2D3uh-e@b6<NtiJjW5nq8vXU_nz~omZ%zvi67766>mmH+qKG
znQ-NxYviD%@24zu-B9Pjn(KvuX&;Opq7xv5xwlAsf8-qd$lqoUar6J6x3hm2i(zKM
z{E%iYcSoGd>9aQn^&GT81geh;%Drw8`*7Qh9qN&TpPCFbev~o%S)=&2i|lWxH97hG
z8oqDLy~-Bbg!6N<(k{OpvCt*4_SCkAow}+8o{ij?sNGdKeq=KGUAmBaMbkEh++Mfw
z!L*=C`)f98>R&x5_j#M!_iH5XD|jCl*A?xGX(nXuWy0{p!y~JYS-+~@1dVCsf=}e0
zUi#WtyYW&7vk!T5Vo?XX#N2z9@n)rq+Jc<KPM4SF4VZ86yUT%gjc4CW{>?Gb`__~+
z)QkOCJnr0|+PucT>^AXp&H8l|jZn>;aI^90O~$tq<8P+wy7WOA-h<V{CQZ<7CRrY?
zHfQ?2x+B|$&d=@{enG3UR!qdP_~Wx%k9~xF$5}m0J9T*ZUq&yUcCb@arG=xcYu&W<
z4^Xp-u&!fz>R=!1QT8Y&nYq_li>KG`@ljuUYPRayH;!qKN2Z27p5L+4itS#frmkL#
zvYtBZ1gfWoEO_r-Vd|ZO<;904+U6PG3wbc0b)z$x%dJI?UuQn-i+sf5G34PdJ1z|A
zbN=K-+ebV58SWm~@x!XFOM_jmj?#F0aqoLSjH$Bv{fxAl&wW}ft9<o+@Z$ILmWA0^
z<nKM$#r?T{EBDoDhs{vlN3#0!@9ul!oOC+$*q#)fH}FR0$#-LuOxotJ(p?<j^6{FD
zX-~K(r0}VD4w$su`D9!N8(p(MN1Z;cKWk@!-V^=d<43o7HS^U<w6&@+`L)00TO1$l
z-y_&)v;Kx-?#msg4m&fY|Lx2(TxHAs8<J3tuVv;e2KDP>{%e+w^TL1!7vBV&i95uN
zND2DofZs*k>8l5byfFuhnNvR$)zbE9@r_jNQ8m`@)K2zkzP<72<R#V34PKmXT(}<J
zm|9HE+-dQ?&~<w49zHwP(EX{q+tp1zE^WiAyeQm!K4->i)rY8`GQIM-*Y3qhv#C1|
zPilPaR>rM2)~_z)M7sCfzP&~7yx?wrwV{8k9%e97bLZGilYWmoyP`s*!QFnEGk5jh
zv!Yzz77G&AOLT6d(=~~i8=G|_JXK=ba&NOv87Wm;O{pF|H8Z}Mb?DjMTeSA3KSkJ{
zF>~98mwy{NxWVM$_?F2HdM?R$7@+&g@o3UT-S?44mRW9d;<y8>{=8sfO}l&*vr|_F
zXk?1+HTQn8&%NzFwQgf}csH%m*YG{cznd(-jdjS_EgJH2S{s9k{kSI?^-ODAh}Juu
zbVzMy?t?w8A`CD$p$(;5`3go!tL&Q%v3tC{QE-yU5xv88Hs@`cd#>@rp<_cnE`Y9x
zn7NJT)elcsTeqxwPrb`q?i(x=4C#BZY3p;XE>x}7xbyVxj%X({b5Do&Om%gf@$p#Z
zX5WIGBaz$gruoksdg)|~J8m{%R@S@Gm)4g2?Vr?QMRM!&BOVnL`aiy@GuE^)D5mQW
z%e#idvcd)rm}idugLY)jegDLq1G$b<ZrqI9+|pq18vXod(d&dCLN{vI&S+#dMg@Jq
z%v{vFr}xh6vJEzBIIDQfiU*Fni*F9AZ>X_3Du06G_8aMNuaQ2vxAH^idyAfyZ`_=Y
zAK12O>HBWef_3YgcYgd}Wx_ZvCkFYgJc~zzr{@~|k@PTqW3bRJB+<T(TjrCH`Vl*a
zz4A02mRsBH3BEJk$-Uvx>AokHU7cKg;EY)w!fRI^Hwb#(cFjQN6qQ<wKm6*A`inXX
z-=hhl7l}JI?X-4mxICeL*q*z-Z$@uDF@MXpt{<~ji^5Ohd<|x<esV@o<Ao<oCK)BS
zPjav*s@A>brEZx^UbVEY(7^G;g3%l|i^bz%pu@yg1Bb02A2oO7q`5j%#v6_jWtq&F
zGIE&T_N6CJqr56$=2m+hn!0DFes<0TlWgzcX3ryC!s_ce6#DuE9lIatp=OH$P<bgO
zP=*pfm6IFCsc4atIN8oyL`V41k#{bBLR(KaFaGE}TWo|cvh}B9_UKGI2Ol5$6BBVK
z3PCz)54OmLn_-tuc+V!O`-@$={3~Yw=&*AGXzzZSXe-1D94`k~AzOlneseu7k=PmQ
zr|4_}GUG`rR<KbP&56;|8tvxg>>VJ&o+5f$7PN&Hjyd%9qW*S0t)A#>`o5V#TA|uB
zpNXFjpM~;{E`0jfxCB1=Tz9l*Udr~=miOM+7~7{{b~9UQAQb!idHrynxNNPKKiu^b
ziYGdFeBKLXD87$AB7QErZ0)tU91P+@6@`TdT_{{PglGG=!b733bMx>Jx?)|4Na*V?
z^l}o?yq_A?tB^xqUu@o*Y=0J67(VUKqK7a+_Of};sPai=!OLg`>Jy}oDAL(g2h}OO
zV)K$v{b%!%NQP+ouyG7C{LP1*j}zIifOn`)vJ1sIvk&EF<G*OWu=&9?L5h1VFdxi7
zTeJhxO`y8Pb*E0Z#py>DRok#VC1j-O?5A&nPQ;(9dVJu@{pTM&U!-_DGn}~>&~Mbr
zZb?-mSDat4Dr#%nT7HEsW_FfbsWs!tjo-(#ad-X?v`6vn6sWFR8gG8JYov?TTa^x7
zDy0@Y`Xl&c4{gJ-`;r3tpX=klv+Ucg@pZ}HmnPj3+q>D+8gWuj{b~Id&xY@wap_$7
za=VKQd!|P(YmK_Z4QB4g;|yip4j#wk(q*{#d~#&-Qz^sDPcG@NV%oJZ+V$c~CzGqA
z9Y)VOk&E;_2;~x}7F4&tFr~q2dzZAA{ol8#{Jz}vsn-TO9xe)2)s1#~bm%zdTrqP$
z?!Qp9pJNRR-}M1m&fRXe7wG7JsM9g@7xU%C6Y?4?Z206*NJn$$^5f6r95~i*GOzQJ
z(~h;@b?Ws|YjDD)sp~TRbFW_L-L4_mdS1lzt6kB)O=IR9B_oFQKUL5D*Q8e(hdVXW
zyVNm$Lt4t5hFTe|CUloP9A5VQ0~z&6e!I8Ua2|cPU$No*iL)GDb;$NBFj|&fS7rO9
zRv!CmtsXT<@qPp=)XfE|wJr%0-j;jab<oIBZ>QE+{%g^2n`T?03|3xzd%ag`p`{wm
zmt*G6_Y@W#?X_T3JCC;0%CFf~Sx1t8cFN?_J~!vKe7Zb$<1>t5qaYEecKhS($Z5U$
z&OOvEyZP9xCxdq1bLbOmFe=i-s{Q?)o7`vqd;Jo|tRJCWyXM1eK3eD*z0nouKH7F`
zdR#RP(^*^YhwR;!nj>hl=ilqUC@&!S{doMeEi+dro)oT8f4<j{Ysu%6H8Y27x#-`w
zb|<wyYohPGtMB~07~}TLT;An<qQaz}FEekM9(?^Y-ShOjDJ{}|X&iN3qhP;P(dH|P
z_lMkK?)`Y&wjw?x0@W#tjSbE6A`GqL*PK6@AUfTtaP^GnQBB{4^t-m^!umqA;}q>T
zQM6woj`^EdaD0@P*!XGx=fCD{Gq>6ic0QrQ#eJO&T$8MS8=aK73iC>tx$I7{zC}|C
zJ|0WIwWLW}-k9WfV?NfjaND_UK;gJYVV*q|??-5^OYzOgeyVlfx?G;l+vy3`?VHB+
z)ATSl$SaI#+h3!lR?_SM#rqq|dR(-u$1xQhpH#HpMA7j{71VJAswvji&zxFqe;v~L
zY`5{Eb1g)NF1v)gnMFr<y^pw+l!AJSqT`sy*tnGI2J!oi6?R=(n!jGCzhi#dHO;ld
zXLh!kJF4EP?h9>c-v~v=CvUOv`8(&m9b2saqNbg}h+5gJ)}Ea`chW{KWTbx+^D`mi
z)<Ulo?f+4<pH0zm(SNHyNzr~lMaOLquzswVgIDqvxTL?31it!Z_lb4>6XTA>tHw@#
z`y{4<>+&&laH699ii(c!Dmw1?Z}p2QI<Bnfc<1yMl;5mocARxIUMscIA2rSwJ}f@9
zVS{VMCbs+5jf=Q`W!Y;Vw1pJykIQH79ecFc^^sS|+Q&EE+74VgGw`lO&o!H`uhX1m
z8u#0x&_?K&ZOq0A8|{jn>3pK@;z-}%#p`EiE)%C3>rCr@!`mo-W3h`thbd)0E~@Bw
zr=sJS<=MES-LF0c>OMv<{Etr32s3-8fAmqCqxKG0!iobn>UZi8yaMe71;;06F>@^~
z7F*Q_^4~V=g68-SCa0ei))4i{db%-SNrFSullw;;!`xTa@A>2LAw|ba6deaqbbLe6
zepyBPAOEfXTV2+F8~DM-H+F4WRDG>+6JCeyHg32xu3u;Eb$wSJ^EBS3|GKK;{k-Rx
zdwbHv73OuBw@^!MXSl_kp%20~?Fe|;?Bm>rUd!WrXRO<#ct5J5{l>wpzxCR?HQdST
z`s<CxpF86`JN}j0uCUr|c8@hkbZMqiw?T`?iuW%o+JCEPKeRRLzfIA$%4o*Te6*qd
z%cE_L44>tC4mnlRM0;7ty!ju)+UJKW-XEO8+{?DLy{l*Db31+i=_OS!r7b(&U9<6r
z!qa*dM?3eod^&xW;{C?|)_lub7`qUtuGrn`WTE-uW%cXkzDe2fxMy<b_vHm6U&VPH
z`cU<mZ|*wGBWh3P4ip%7y>QLYyisvsLDmk5Zd`ST9EW%Pi!2L*T%OF2M?I&k=UXZ|
zKT^?okM<Zl6R2K)mf`eLuY0C$u3`8u4w+l)jIiEvKqaPXsNKGDkKfjLSoZTC-!XrW
zzZw4W^+ayVN}Wr4cSh@$-)%FX=w%I~@-KS?*0y;05*=b~4JmxasV41XRJPRmf9!n;
zTutlx|H?)sq70>jwnWKPC`~jVp(r!OZnxVdn%ilh>`EdcV}_EURAfjQLWmHO$Xv+K
zAc+hq760$McAeXC+`oPAb?-U9bJqIUzU{T2^$yQFtaq*F`#f(#)}+^w?+>*<=(A?h
zhlaQti|#56R+9Z3C_Yb7T)v>VJiwpL+Y^_Ex(hE2*(}5G!Zojop8X=X_q6nwJ5Nev
zudli)Wng5(pQhGpsmx{A6UF7{ip$#*mv<{JZ%<tQ>qBi)-<+ats?nzpwu@T!N{;<*
zhFyZs<xT$4nmr~<EX}rvT08BJ<M;W{?~yzm6gEH1=w#%S9(Ysj!S+WZbUJeFKd<K9
z*bqMI<o>1h6m=9Ya@j1_^nkCdyUP1d$LAy*R84-vwdh^v7B<02e|f=ZSN+gqKc6pX
zK7!=CzFM(S=ur68W<qAivF?{vM|+*+MO%*w;mtl*usK1!fuek9IhCHVUYRLfCb?|u
ze?3WN?U95}ch6--oT;9(VeaML{o7ZH&nqmV)2o-cZgJ@lJFjSDQLD^H_g>mQp7+?+
zcEX!Pwugp>&-4Jqr@_m0HmmQ=n7FO$*J+nkr>*u?*i!gG;$RSE6&a^LbNIt(?Y+>;
zSX%DK?>oiidx*=c7MJfK4I3|;6?5j=nzp42{53A6PSY}ZRBD%TvClkJi}sh=T`fqV
z3h|ysT)v>VJirBb1_qDUVQ$I!3nQG?jhyM^*C*q6rIY6JdgT-Pg1Xf5<gDQvem)Pd
zt3Jth)1Yg;R@A6jPOjK@%3M#*wL?&Z=Tr;pz}PhpG|XBrO%R_4C@vr6XY&Qw;Bv58
zT^BW`%O2_b<m2#_g+uNPHo1ICwYs$Ti)7n@ODA}B+ZZE0uW&V;UbTg5%!*P$g9W#f
z;n0g7(~ip@Nl9E+rD0z_&xE6wh<CeLw49N0P}S#K9_z!$=WNqpZ_K^$entP(`&rR7
zd4kZ2Tk3fKTt&;dM<y4}-!*w$P>4($>07^4k3AXKSGU+QQnJ^Ca8r)fUh#P*;_@EF
z<wNbqGb@`__W6Ut`}`+Q8m)s3uG^?qmK27KG+y!aTDKlYmJZDB5`p-rwA_#1^DAQQ
z#AeM~C+tzBkm|E1I(NobDSye(+YN;|cZQUm5^!@r>ud`HZ<&_+u+edkqEEpDH``Y4
zCGP(c;P=ipW8C|@r4^nUX*1FXt`VP4v7b(_-Y>Ag^;2JKtD~()IQp$vYH~5Z@Ia@A
zzLH}{Ev_(?7K-A8!LKA(H+@vAaMj|*E(XtHj33*~u-a2x>pjC!!?*B&qLaM%d{Bxx
z#L_@(Nd0X4zpK5Mz@0a2C~f>l`udcioP-_m73>V#?F$d7U(wQ;=jHD0?kHfZPwCH|
zjQtv2odaNtXODJw^>B9Kdo|hV7x6e;0j%`)J_5cs;!~;0&F8yd%aE35MK*e_zy*0U
z+xGvr_J3L08}c7&Z%h4_58%NP{r0vM)>ZiP8PH@Dd>^Zt;^Y0655NI6L8M3yp;CzK
z?s%N~-Vu!DKe!41h(X-U4Ool@_CQ;Zi<<55CU_3;Zu*WtDZ(EB#ex1EHgT$@-Chyj
zAK;xavD=gQxz7>zZ3l$NUVS2Zh3L8$IKLROBrB5l8+>Quy9?jVNid(p6qAu7F*rw~
zzMz$GXifosC$R~unq=+$(YhQrKHq`wfS>4eZsRvnUVFZiGby7I)n0D%FL-~{llT}r
zy9xMSZXhRkcne4#EI9`W*hHY$e8}FT^(xByHPV>`B7mc_m$!gJauRVPny(p-wwXlI
ze=CYhMauQ6sa!lCFE7MzZo2BX*SX-j;keGb#dRcBE*s}W_3`4na-l5{ObG9Rd<Hl1
zLlnv2!(ogMOaioDsS)(U7WIeb)~ERv1M&NJ4w`TAv)Y>IS{d)HTXHnYp-)l&1Xlxk
zWuu^2qEJORPYwleC`eyMKM|6?q6F*(>;dcxggH})SAA4(AnAlEKrHE~K0sq2vZG@L
z;k7Fr^9QdzgbQ(A6X*-XHA38OC_Jvvv9PfG6~^H^(x79|;5IJI!FQ-l_z-9ed<--J
z76VOz?|@@~HNdgJTA&$F3Ux3C!atsl*#rN0;yWxvoC4Apg#Ce5z;QrpApHO7*h<#G
z>G)3gj5B~dpbanrI2Q<iS2{LS5)d6(2!C2S7Su@~>L$DibOAmEx&v!~o<ONqB46ot
zKy+teXCQPS><RP-_5}t2wSX9F!jZrwz;VE(Kzm>aknntPD;KT=E(dM~t^_6lBY_8j
zYk|jr>w#n*!cz8E-(XSy6ZK2d-lUs0_dg6pno}bW#0N9E$j2O00?nnV#n@!HH2;|o
z$e*1{BQ96vkK)oW92tfq!*FE&xzA7$n>-6L9GP!@Z5WQs_kH+(Hb<rn7IbXZhgt7r
z8WmS-l-KCrx9%}(dXbXQd>uP6=eS*{9;>JVi#Q2YBKPySG~#k(#Eq@NaB05poAtA~
zG~#kv{wU6kxLlQarlddrn1lRh=jJe+oA1XMU^qA5_dRAfHw@>7_;fOyoBvIWGlp}+
zaBfJ9E{1dS{a9Il70!*g9GRaTdyC=RFr1rzg>xe=mquJ}&d-j$#c*!EAIpp3+%TLQ
zhI0cWCvz|wU^KvJfYAV>0Y(Fi1{e)68elZQXy7lP0mAK^^KZugLmWM4_uobT<6y6G
zdmqOp^8cTa`~Uxs;U|8azX?q|?)%{Hk^}pm(L8QNpdQH2R@E){y{EOs;kvlE^GHxa
zsK^lx3~uiD4pQ)s_GBk~bWm}rU=VISeC%DEd0^jr@wu)zNBG}lPx~3jv-xCmjJ+uQ
zE-HtpeC0@_BhD?uha8~9|H|jp!gs>sh06}j>joE^-un}rVVcjq9SCl>Fabz--RVF!
z5N?DNs5-(6Koo)AqnPlztMDCRGKA952f{)KiC(}3r+LD5;P3xsc*5NYujA*%fd8}e
zf9=5WMocz-n(k_qDHD8Sx)<G(uKFtHyy2D-HNR9(T`u_1kwg&Y|0w>ixOS0vI4Q7M
z8;(ABsFv7v%kDSc1qHirg?Szw6VyH{zEH*B;gAk>?!*85G53aGEU{T%9+}Hz_fML0
zO1{5+)~st6k5nsMICs@P^2i2@y=w<Q&4N!1UEiM<n=hQsS9X^+`!(C|c;U#`DY+{&
zN_*Z>C@eS>`pcR{pG$K0<iL?b+!%fpbb3-{iLYeZ2W8$X`5d>6U(@enV&7vctTeLx
zt~w1Ht$t#Q__6+aVX|VgN_R%wzC5qa{m$oxufvSZvvau}w|3OankRWqzuMByGn$DB
z_@C}+&>A-ZCMMwT_flYD0{&-vrTtZ60*<Bm&i=P&t7VM3ac+~>w#2Otv*#bk9e*V5
z(EH7iVL=($tl_KwIKDH(V`g~FWN$cedCW`U<jH1@Xv6L2cr-a{qlxv>d-LL#I@iT1
zRLob1(Q@sfy4uTm;vcv7hPW{X86NY0#$&djWBs+gwqM_>bKAxT3Ja*DQ8pQa<L@mu
zY;@#J7ig>9*!ubs{6}fIpBH2B1fAY4nX_h2Y5N}Pwp%EC5@r;aS!8%=-PM`8+YOv%
zS9dSzidbv3+>c`szNY08pHlXt*-6Fny4c@i)issiEH%T#Je$;8(RJaCXZ&|EF$@3G
zJ!f9Pi5M}HPFb%n(q7$TNq#KLT#uV=u6d?0df&OAtiAsCch@K5<$}0-)2tjs(wk!J
z%S-$;^=>yl+vt<ejqY)StWr<*8dH~Np+92b!=R(^Ij7~A7>M8QvBU7O|Jr<Pcf8PJ
zvp%&w`egad%y$F7L@qD#U)9(4X{K8DJGVG%$9LT%IcLCm@%NGzcMoeOrXmwlk?ifw
z#8muq#Z+W?+YE2}U*T;teC+>h&txVB;`jG{W?~@zd14?E`~T05|0i(wb#eFQd;OW?
z|NSfuz|bZR0EHM@<QM@PH?h+X1CAX<QBm(i9Drt>a9l*Te%Q;uchE7?n)lC>M6fL$
zq)6<%_Q1~g?g6@hvzsHrhKbI9fZe}0{`Pft;Pd8ly_(M#;k*jg{~XA3d_1s?A)n?6
zRO0*{WZs-i%XoASO?BvoMB3m3E&yeQI(Ufc&|C$Yt3dMk&heY_lX8*rH**no;%|{Y
zM0zrZqU3OHBR=F{gBw6}hwFr(InXiUV6voR#Hj<-a2|2sXik9%5RdgjOW+Wo9}v|Q
zB0d_W0}KP|0uKWXfZ0GJAc+w-21qyw7C>d-WFToTE8si)u8EJR&P2zE5r;ytfX!{@
z2sxsk`9Pv0XW$2*=3goH+24%QFcKY#%?b~Q-=VA$Y<Y(_$#1UaluiYgQ`*T3%BK%}
zQ4^l5lzr`w<1{ca&6t>GOiVK-rWv#EpJJKjNtxoYA0~{`UcN)>)13(?Z2O0J_)5t)
zd=+B7(}&FCcf8hhonGpoP$4)b`M-&2CV|Dl&x}<TLURVjv$gzrS35fE4)M!wT^e+_
za@7XO<7sW5Pv}v4fA__$y_tRgrpxb6Q%v_zJKTF_`ua|$ns0J?*YC!HuL}sMY!;Ox
z$Ozu0I{3w_^S%BzHvT^<2AQ}q(*EqR#l+<xFt+>u%y$2?ZSvyU+L?X-mZTb<RXwAy
zziMB^_1-Tg&kg(%sRG_UZ5vO%A$4Y%<gU$~OjPe2c&53AJ!xD)-vQS(ZguF`d&IJl
z_Tt;d8JqW<Ezj+bePwLk<UUwjw}UgfyD6{lqq7tK+BR>-M$PQ|7gLS>6NZz1U#lYM
zx4X^9Cqw5|s(6ptxnY>*jJUG_cHT!5U$YM%XKd7ezJ31~8#QC2W^B}_TMIH5*;eU4
z4SYUffbx}_(X+jKzq|Qj97Qqv^fCMNG5hqv*v1?`MFXvoiv7Ro{|_57*M<MP002Df
z-N*If!xJ5wp85U_;sA_l;s6Y9vY+pQPKg~m79Vri&-356i~~TnHiUYn((0KB5!#+k
z<iB&!_H<(ZC%@~!{%=9+d=l4{{|{aOULQ~nzN1||%v`um-lFpmrR7~bL>a+0PV)$e
zy;^_|k2im`yN{co`Mlyc@<W^CiT%B$JUQQN&$q+hqPl_WiNDz>q%?3EKI9<2{-oT*
zE-wqjwL-kIriKAw%P0Hhk?m<|d%YQO1ilmdJ<bV<?nVPY0Hqka`sS>%wPjmRHL%K#
zu&=EwU$J<}F4^jM4BkI`tbji%1^{C(XYA#Sy_~U^GxqYohrRqfZ7=tJRMTa}y3xk%
zce*Z^^u~I?_F0a;rUe5>MBG?;rEH2kh<f7g0mk^mGxl;;$3MRhJ7X^|q3Rd6AJP4E
z&9RQs;W{h4emR*3?#BTH9%HkvDMj%2m~4*HRK0P6v6m~sE)s}`GB#_i;Mug5b{qGs
znB?rk?AbLN0qhuiIb$!Ew8c9LkpJ0?y?pAm{JDZvQ_R-R>^}5V?s$q~e7YH*ZpL2D
z*vrpbL=?*7<+3?m)*_ZmwPK^tq42BCgv^d(-7l?<_BzXpwjLG2n|-cebAoyUMfuQj
zDm`PpGE=%ta@p4ZdXmiABMG1Gp390jQ$1(H+{?ZDx39!|Oj_=aPW{N)SyjE)weKQ%
z&SvM-6vI;OvWTc>hSGO@XML>Cr>G)Yu3qN4#ic{+yrPjstr&YbV=rgy<$}<PTk3FV
ztOEC)&2o=SE}Xw>^0=T7nKq2QoUxa~h{ha@2EL;KV*mg5<Np&2|L^SoF#NkY^ISb>
z%l}_F{(rOYzg?5vKSM%f_dg1p2tPF82a(;sSs_IIB+fsvwSVXMjqm(hIr!+$_ohfJ
zfc6k3-@Wji#QG<;eG32ahyfpecB5EwhRE{+K8x{v3!SgX-d_uUe<H&f>*wLcS;Te0
z-^703e2qHFPOj<vk(5<*&D$SbW7~AinikiT|C4J-Ud?(kB%KY%BwSB;0TY1t3@OUE
z=C^ukj*&2nmj2y;|AC%l<hmfaZ{sKsosu{TlSMk_cnG{`u0#^feH%l8a51u*>WcOt
z8ubAcgO(?H^TFR<d{?fs8-_;H`P)tMXwP5eNuH!_NS@?8$&;MRZ%&)<?c;)mBke@u
zGUOuw0cj_5T34d{{+Z63uW1c^lWQ)txTd%%{qOY$l8-K~3Bom_KK-LV-2W%nH1j}6
zJBj)_MUgQ;;w6yw#d3r`pc9%0vIt1}zCUmS5L^$Ttf<clR{{g^Jq{?uKQe}bfg~Qo
z7JNi~MAUak`eY2O#)ljv{sYNR3m6I{Jd-a#!ZTTdbPzK_7y`tj1Dy}ym#oEi1K=j$
zNZ>A@DKHT@7FY}fCq>vDIsxrcr~<@m5TPCrp>2hv@1lN8+=pW8D;Edn{h#HhFmWI5
z+RUy0aQaPTaqPVp<-v<$&2RE|BUTECUu+idQlBKX>Q-m1CARIVIX>pV?a=FvuT}k8
zy)>A6dO^Sw`Jcb1gt&V}oajl)cf*9=aBg(u^uaEJLR;@RDx)O)a4l$Yjz?ic|CiB~
z$*-8b9hkix!U`i2DXML6(qDqs=?^om+AwT(;*J{^le}|u>bHl*PVf6E(ER?6Tf6Id
z*tdz6E2(YuPCfp`p@&DLHd?+koXG6$5Tio$CwWm$`(b&eebh86o!Q&L$@u5**&w-=
z=y`rw#`u6Qqx;G&oEEjQzw`U+9gFiW?w*mxO|H8dp`{2LF2iGC;y#c)8<@Bc^)J3&
z+Pl}OZ6Di=UGp|PxV!nC2c9WUsgrROxu`SegM{&=yAz~udOuZjf0MCbP==(zoFndi
z+m9Pow-wLKwA}fUbxtL2fjdhd*4R$mwA}BBnaPg*4|d6h8zt;n8?5Ywm~=FsMEPj^
za)<2h>o$5WS+_e(cC+BBzEbGOhwj=RlD|4?4#k7hR9fy)dTo4qVp@mE)wA_XKCbt-
zb6Irk!K_ynnw6J}cJ_>u#Ip@8mt;63PQENzCiy|O1H)rEjP{sG^HVYtByUb0Y}{((
zaEpx5*B(T?b1jcwYS59B;%v$8>&fs~&fnbcSzB>-<Dn<HKC33*zNr4#*(PKb!(-9z
z75<gsu`oQA&J)um7hM|?yoBMg;3XKFrGM2>D^B7-mxQcIuNfW-!((B1EDVq3(XQm@
zp#kkqc2@4|(<z|x^}t8Z<Wn+g>k<<5U^Ix+CG*BHl_M6JNv6BJox|U+j(ugds6^?l
zB2UV6m)e=kb*&}cDC#yX_bUJ6R!7OmiWHqYo2n+P*1YU^YH;rrPt*6<r??jd<>Fnu
zv>r(>=FGJ<ZA%yUYg|g5re*S|)Gp&<pLwbl?Ju>vT9869JQjw>!thwC6jFWmMCZ=<
zD&;R3db^=8=gyF_Qvz=8XB~#ef{BDV7!5EQU^KvJfYAV>0Y(Fi1{e)68elZQXn@fG
zqk(@}1B8<O-;Dpq{aeKU>j)M%xYOWhlOqO71vQdd1DuHXe{XAPe*1Vg0pH7w>++ib
zfF_V5J^^;X?;OELaIzhxFV_GLb~iBhn_~gC2Lbxqy#U)o_Ioh`30E5Qt>486BwTnC
z{P=B*K*G@`J_EdOVg!N``WyM7_)f~h2DX%MKCjw*-ra%E@!&c&^W@3igkA97*w^02
z(UI>(#OZWS;Cw5ThszWAa9udw&H;S-JmIXjkO$3MB;U-dC&|##_=S|GnXmrqdE`Ji
z@ngX0Rz(|~0D9Mn`0a#qPk8iOVJG8xjHh>2Bt91}aE^`k<9UeuC1fc*xdTnt?0_uc
zzBk8x^n)BZrs6|*=-5w?nt*nX616*r!{vDiIKOLly4^_|eCMEj97x$ndc<Er6l+sd
zKhn;lem%!=Bf%h*Ad6F!7ZPj=z{znGg@dI13P?W0hXlSTa7@sm<w-jeeK(!sH2af~
zd`VmXLw+bN&;E`4&|l?=&PiL7w0JGrnv{v`H%WXbMCEVZiBhD$cev(0+CnrwMB|2y
z3ZrXKxj0V_s9Gowg!zE>9U$C&?E6S__wgGAst+AQ66zKj<2%{oaXJux3vGZVKzktJ
z?9T@h&b~Kr3Xu2;%mS_g&IWD*+5)!&=K>RecEJ5WF7PPO8F(4E0GJ1K0g}BW-GQBf
zp1|%vFJK=a#)WVIkoZ0f2l@c#0DXb0f&RcPK$u*FyMarADZpUh5nu@LG;kR(8@L>J
z9T*0D4-5zPZADQlfm%S+MQ8xr2%HB*U4(q#4&XIl9Pl1+C$I{*2iO&3A{jUkm;#&(
zOanRs5gJ993k20ncprEI_z8Ft*c1K!Jg^V&0?-I}5lH5}8$i;&q%B3`Kr}u``{HM6
zAU@<MgdFMPML^O=9|OtwDF=Q4GO<7Z@A_6Su|FA~iHVp*vwIQSZ-!G!z=Tk1C!0&k
zyO!H@Uvox(ri1oCJ-+YO+^T8S-Ckl|P$qIJ$J!o_m$u)eHsES$gSO%1u5s<3T#?}@
zZSx#3<g3+DOz`@&+~C1#);3?vRJA{<uvJP96)j8XC~Xve;91~_Lsu)<Ozcl4_9qkj
z^Y0P+(`+r7H`Xfl=ujv#WQpT*uj{K_=k(rj+obnYpNw{TYbX1LW!=TXh4GnSd?py5
ziFWVhZ!kU+<33VUL4PuD^h)0ST*Lj{mIMB+x$Q4^Qoov<>ZP}BW=wKB`3}D*RpQ~3
z*(=jArR&l`XLx#&e%Cf8rzq<2=TA$=v)cfozq#D}W8RbAh7QzhYfhEt|6(M6D^@ip
zHB&OJ^7(O%4Vus&9`@L*o-eN}zfXOUm%N0}2~4q5aK2d{*kePQb+xOJb!As)Jn)&)
za;@8Fr*5<BH;Gdkt<3C|8HERG<H1CK3r;SoI8|vM^sq2te}7HO9Ya36irvL;3{IA|
z4O2EI?-Z8Ma`!*&pe{ZbvRixp^(zi5600SThIAcxY_4XCV?T-RJ=II`Oi#<je0urx
z%2C@TjL*dRXB%A@p9#ii!mq2@+qZa!IS4Nn8J`Jeugr(qq#xuIZBvateXt$lGr{;w
zFg_Dmj|yB0G*wieAjbX^+Na~|_Np}{$M*$SeA?D)zwCxg%|#OBfd;}vBh@XFVm9^Q
zQdCzMZP=_$gRb>jQKM!#xnkcbb3HlN4nYx~Q!T6mW7j;;Fl)UO?+M4yazkexi1=tY
zOZtrET!q&i8&{1V+tWxbt5LAD@p*A#QrA!z257lUlOpTf+bn&|_)IW96O7LUOl8c$
zXn@fGqX9+(j0PADFdASqz-WNc0HXm$1B?d#sRjravjzX3tEpwn@pboFXsd1OZA&xO
zUHJ~qTmj#95l`Um?&59h;%v`z6%2Oc3Y-`5J-pl(aJ01abhUM~w1;Wgy4x>su=Uf`
zvE{lD#;=x66a621x*N)YHVW2s^C3(1q^9_^qAZ<xUhdxRjsmv&l>Tf>aHZYZCf?qB
zS9=#eShP4EQX}Okp05Mtpl|!z0(yJ#ek~U`*7)07!1WUNc-Y$eIJ=-Eu7alWau$Mn
z&vzL%l;ZpGzn_q(dd<}w!(XH|+}7UN&DL+&P`XO4E`!On$n*QxH(&YNf{-G*I(zeM
zorkql3)kC~uA2_k39RgY@SU4^u>{+~77^7*^VB&aeR800dp<`?2b}IUa(hL;HT|SZ
zbJ7Xt_Aow8*Zs<~?TmBr_>co>3kkvuD1_ONj-TEJ2ve;Pp$X|Y>g|9-@x46|<`AJQ
za5xY}qT{KPLhImrH=qGf0Z6#mzW_-*b%bXIKb{h@fuQUORe;7oRiFtFuMg>X>uSK!
z_)fUK$e&sTE>9<k(wDk}51REqSkkLa#`bo{$AKe`3_3}esq~y3G(70&S(al^+XI3+
zT)-TR1{e)68elZQXn@fGqX9+(j0PADFdASqAeIKcdH#3zCXevsao5p{kLOl5(POhM
zo@u>peaMq7d7kBZc#uCuKE1!&|Idjp5P1{}{5|--e+&PA(KCDx_|uYuJo}R8Y4R*=
zfrsF8^mDpIlOOmvzF;ctggp)FnF$fv51in44%!dA+2^15c00pEokJ80VdAGvp3jLd
zxJcu~&tK#R{tv%y+B2Tx?8f2E=X!aQJV<&-it-%+e{Gy>PLKGw-x0l2pt`|vw|Rdz
z@?0*egQ#v~|26V1hdj%Z1OC`TQeW~ufz)|O^Yc8u3{@oDp94;5N(Srl&aUma_i$F=
zG@}(SKL%tcUhi;W;?|QlN?zlc-=3CRCS2C#;k)2PoL-#p#RVz8t!^uZM#k+HwCQzm
zuiy5tOuW~i<$TSjZ#78muyM<c$ZatP2X*nPS6@Ctc(+Sf`NPX|1}<=*s57)&mHRNo
zYj<N0@0O{5ZTD8PgWLAhv9e>&JoP`B7**O+8_wF*wA`vjCBIzFV+DpQp4TWnOL3T=
zS8V4!r7BW-VZsO-OXD7>M|V<>h)ehOo%~{>KX2CiJsw`h4~{*IjF<E~y>8~!)jMxU
zWnnNapydKRk2CwC*`H}x!cvLlm1JI^sP{@lf9<8rj84z#leB#BOy?a#G#_=jJ~BOC
zn)RX~Sx;l;#z6-usxSJCIC8PH+^P}lbL_i*(i#0l&NAut(p@)wD(~GIGq@KuVAY0Y
z_w?}MDVLVB7f!Vvf9aP6Gg7Oi&*&(t-X5N~H#ci#FS&e;g(HP8rr=#0+8FzZB|W!y
zJt;STYxMmFW?!@g%MpKo_T3#TnNXblp=bA`4qZow8Y#s_sV%;+Xv{Bae#=g^Hh9MP
z_$mzV|LDY?P=n%AtGg!!q)iV=)EX6>x*;EPBb)TAdVznGbdS|;lkTVANSD1i=|F+c
zxUM>qV|T<p{?x<a^;g89pyjIWWO&!7n!LSPWOVx7%RJYdPeJOr-FnA7kgh#Bt6~3L
z#BZSGX04yy;Y_k?6yxK|`1t-ke0*=xKE4Cq>=^Yruv^BBe*09;NaeaO&|KX^`IgkJ
zltqc7OU|tbV|;w4%QHT{jE^tl<LlvNuFd%Pu9)QP)2Ny@Uf0apnExTLpW~CM*DJ=J
zsGz7s+ILsR>=1u-MRD$(nyG6TAK!N!@Vt(PSvG5Ys`{4n0XL?W)Ykiy7Anm(st<_M
zn`HH5n00Z8<%CtH6m^}JJDw|Ovr2c>8ac_dD6_|tpNH%_;`_GWmxvc`(FvYmyY?Y|
z6&{M&tdfP^Z&HrzOPg)qD>|u1$nhthA7>uSUVY$@-k0L--i(j${FsQX{t-$+^M_6M
zE;bAcnr7{Fc+<rk_~&QgWdfU3W^4OI)!5@v-pQQx9d74tzA#d@cVm5ys@b^_<E>sU
zLlCrDT5h{r=F;P7L&_=^8kV^)>Gyi0V@MBGZoQ{R0OR9prgu$;@$qGRe0R6`_+;q3
zN)_)hJ2x;szKoA=v>>L7C%=~O^5pg0j|Pm7FXQ9O`1p2R)R-=Nr0<iD!&ep#xii@0
z@+sBo(%vtUZ3ix$;MHwo3`JQQkafw+o`F@CDp!}S(dra`ku&t^y2u><xDBIME~wmg
zY-*J?>@urqxoQj7m=&dh1`BQ{!=V>FrX80*l9ITtO2fW<o(V@U5${;DXgMS0psLTe
zJl2Pg&)KHI-k5vg{fhpn_p_pF@)#dq#>W??HRfP6@KZHF?Ef<;37Ufrdi}p-|DVt2
zdi>7%58eR(Z(#G+XyWbX69PRB!eb|Ktoz{89@;FX?dT>%8?=3&{PvyWH*wxIaKEqz
zsbV1nbzq|>G5;;WAK?25ytuI7!^ZE!6F9rOd2<}yy%14fz?+X??i_ezcyYa)`NX*2
zY_m7U-=Z>z%0}XD6B|7^{PY2T06OkA%-_O}I0Lh_uqzN|P$8)U8%Q|$O#E#o{x)Nq
zrwpbE3{TvQ)hvxXR@5-@$=N=vF4{V&j-@A+H^6oa!VjC(<u*U5rqw$=i)qtqmdZ!Z
zXqaNt??8;^)`FS`qp#LmNg{SWEqB9&-*9ep<n+NVgF;*HI4Ywg{BSL3agIk}ME{r3
zmC3It%8ItR8@#_ZEp+s_h)jbrwYkOR7RR1)$Hr?;-)J~X>si`9#x_59a>q%I{f92!
z6Xxhq8yB`BW=QbXT2>y`=B+V#v01Oxlal!#=G8N{`G=ByF225xJt=w<y*z%lR82mk
zY+z!9vH5WCsjQm|3w!76(|?qbSa?;%aV*}sCeU&zwHKzl3G`o%e?6n>km;-=AvcnS
z7G&sXI;GCuGc)z(Hj2ul<;ry8JsW~*znsr2THhzPYEJs6IbS-PIj0?(z}V*h9=7>z
zQKVlzxc}Mh{m6YMH+Ec=o{+7&e9=Hf`P^cQfT^0Y5<K})SZFfww;9_!W1DAe^NekN
zrQOCojBVc8CS=xZY%rxl+tU3SZ9L<5=En4po44>?$T9t1X$j^d6nBl=dfrw4&=AHp
z@2{P%mC7}1=s2?fZG)TZtNYJx)6+gX5*`G~wC#IqV{o0BiPcAE-i1?#_HC*&2wkGm
z!*oRH^Q}qqsERl}>~TiRWhu_e??){!+1umoxk1{)URAnIy42ZFadY6R)n7uiKHy#+
zPRqUU<1W&eXuX@U%{O*<<ypB4{uWwfopY*IU+>oaVW!Go>uZaT2vrg~aVxl=#y42i
z1~`_lP8^AN2ejO3?btzIS6WVUAC-6O%SPUl_>hTTFXdeBb$xBs+rdExv3Aa;<)V9b
zmt<`7+O6M?Vr=t_ZJwt!`P12aMUCay<BPG)Gq!o+JLIiP=G}(S<UqzY&)DV}+x!s!
z>noxTyWH6y*(PHQ>^h-_WPH3$nv!y6TBkX?xBaqEI<(c2?8=-?@AMUWZ{iv^R;`SO
z;b%WBSN8dX!u$LuPa3U*4X)d$R+bcojWk~I^jfzbN0tuE?h-*!WwhLnedZLg)?u^e
ztrPZOZ1XUcF$bf8|8pAn>GpqDIvgF%03b2{B<v_klIo28!(Vtv{ffVh`8U}^;Oy!g
z08=)bY?AIw;{M4~s&X98A|8h;fU~^4j{w%~Za6oe@8ZGtYI&B#6jYVt3S5u}xdxF5
zIEVr$;B#ELZrF6*mG34H$#@GKsCJN<>Fnm<?(0p-;%_r|A2$btGIVzn$(Wdq|ACB!
zTriC0gPZLCF%qIChy9$kuOmzyb-4>-)qNpx`%FaIz`0(OJgocQJ$}OhpddwWd=JrP
zTfQd#7Ntkq=_z8%XW^V`Q*yA|)Bg9!n~uW=muJRy|9{;7p4mH_**lx@t7mNYjP3qm
zd8U2TG%Eem&C&B;6&(E~fBH%7iP^r>8usPSrl=eh@(dDjqxkY3eakt|`WksU)eVsK
zimX^(J9K5<%R8ajHVQVlw|}JNYVy}F6Nae7I<f1`X6bLTnY~KzL1n_^_+c{|1!4W}
zz$a1z<To~JOy(~~{~osc$#~xn{q1?RxStH$bL!v<HRX@zrt7{~zB4oId`Jv0XrS(*
z=v>Bj&-m4k@MmoIjP0JW-7~iP+ZWXzGq!tX?`+1ep0V9eXm~5n*zRjp1pOG>J!891
z=pg&?#!FY;1e2<5jP0JW-OI<{EHgQD$Dw<~%-!Qu8QVQ$yJu|o<b6}UUtodjr@q!!
zM_Z3@^jopi<YIo|fldv5CC83hTwy9L1ow;P7Ay(YO&`@NT(!8di@~!P<Ht5Lto9Vw
zde3mw@GU%`=p;{3((sREvnF;h$kMIYA9>}G@!3@Ak6+@i-MV^c{at;Fns#f7>SeKC
zJaaG_U^MW14G{bPoPX2*pXctjh>v{$$S!->HGu3GKyPyA3lqG%tNovr10doS5T1am
zeRJIW|CARX3zkF6qb()k379qU1T2Wb9>)ss1u$(<0l?XqyNtgQo&fd+XjvS6eGbQ$
z=S^$To8u#J)TQ|Y>U0Xf`!5*#^ntUWPsa=B2G)QqVh4aCKzX2X9lQnfcd}1F7>EL7
z_d@bJAtU(U<HC2Nzk{+sO$P7F13?7H@1QtP4?r;R0B3^i7w{Ib2y}1}&&SIPgbGe`
zIv;R;NngY*@NtA3OU@4UdeMra5Mq*YpzB7s4>EH1o35w#XXLm$a(M0ze2#~^GsqcA
z_`MvzlkzsF@4!dFaga1EkX|u9SMc4VDNVBXK_#vsd<ieUU=i0vv>!rIQ#t~^s|UHB
za45*9xoqZWhXpuqg=h_gx<TqzjBAK41nvT^3kv3gG7<T5<T(cN^YGiuCV7(Yi*NF6
z&V!&n)e+GjV3#5T3r96FA#L#*$U%Dx+md`G(7bf(BC3M`8&i_fi#Q@s`S%W*BSQ2<
z(&~$LM4f%S+&HMW51(8>>OtCA2Z0@k?wrZ~oFKIj-IKN^dTMdLsg@$0k+#>y@4jR+
z2>eazNZQ{D<)xW4_?z^J9>C^4LCQk<1ZgA(z9ZMiMZod#<~!gkeLZO#dJhWc0J?l6
zO%l(dGx8Db8zO33E9f^Hx`K(0>L)2`6D35@*bEYjCj8}DB54t$rzvgH=SaR@d~am?
zk2ZG1o|xxm(rIuw{Q2{_ZVsRlsT#EyOU>#wHlA%V-pXW*wTYD}XXbcolj$5w%mrW#
z35<<ROlFA2Bah3Q&v)Qp3~=VVd*c`5Imq_cHa^|7nW+c*i3ZM30nUZa4of$;aq|#v
z&Q{dMpfmq^kZvL>bEn`V_?wJlqE|AG$=})Z-=g;YbxgNtU!qsi?pm;2db|60@u2ON
z<D2M}$dESvwmn;paUzrZP5Y2^NM9$qcE*Q%ZyqadJkfVD-pIUw>5BfHjN_K`!SFVS
zfdxH9;`)cQUPN`tZ%UUl*3ZL>bYuM9JWk0qCveRkoSQ5o>JubyGKY{kf|RFu%r%cU
z!h<D8UyL&{zbXK2$as^Y+oE~6dAA&Jgp<W47ybSS{&r4n9(yAO|M6pwjOpgFhn~gx
zb}k^gBIA$fi3~n6mz{$?yFf=<@O?e46Hz-fx9|7bfm~yZYgBN}sHV0fX}6s7o7-V<
z)4UfW4PhMZn&!Q>z*fUCmT5kmge%{b=i$%srtfE@|NZ`8|7NZuF>yF!T6B0^K<ZEW
zJekv4{x-G6T!Wve!Q}U;qCr9C$1cs+h|baCL^otV8%>lOw?AquT~3j1nsxj=-H>Y>
za1Gq*sDu{RH0%AJU9$z(Ak-W6xWzSO%#gPF_8OwwW}cx%I|$&g#s^tbmiSCT|7J_H
z?BAmKh1Lyz|K_0eO7uXk|Mou7Jdb>PA0T>cId710K-!<&FTd?~q`X6$);pRqqTI&<
zNPZ^xOh$S0@eTLCU&kYnBI9r%`Q!J;Z~DR?HTG_!zRLYXYoV5PEN`l#G0IKqNczt-
zGUv2us$<jikJCS_<B!_qd-FT#|Np=F{hyWFSeBHCqQ2nXORDf0ID?eCxi2-}wy+i?
zZL@-w{@s87^|tx8&h&iIqRwPJ(z0)oK1|jaO?{K5(USSfuSNTj@m`5avpay(g6k9M
zI*Z0T>DS*Iht1d6;u_M%OIwllCAtyK!z4dft{(?$U`KG1MGHurBYma$+9+I`fODss
zt|jgL|C@VB8FQQRyTbZMe&l{DPJU8oV^UVv*8jMc^apXSHN>^?xHh@zT2j`Wf1;a~
za}=8d62oy6A94>)#Ahb@)w$;JAaJ+GDY{Qtkw1Qa{O-O>+LVkfNwj<O`n2WR^V>P7
zd43{m5PF^2)G8z^(iaY+9?fH!q)pZoWUbk9olE9pvUVl+PEx;jK=RxsdR7ztt&4el
zFwQR_9RbG)2}(%noB_mESJY{sD)0=DtPL*!HGx-vI>2i{(muIBsEE1&90R-wBuXj(
z&IjHDdI0YO{eXo)A@DIU1o#9P0elXO0=@vQ2bKUg0$&1?fR(`0z&F4Pz_-ABAf8Wz
zw}2mjg}{%%r@&9ZGT>+6TVOq~4%h(v0&E15d;1rlEbuF^6R=e)aL|EmfZD*eKm(u@
z&=@EUGzGQ;P6KuTa)Giy9<US81t<sf0m=h?ft`WmnYk;Fv<Dl1i=L%K&sd~AdgFW-
zoF@nF%R<s`@aj)E0tj6TO@U;ZTL~NuTnohgNl4a2=D@wcNx(<I$-w78+;4@ifK!3h
z!0EtR;0)krASj4JlIL8Y29N{P0dj$cK(wWBEYJbS0XhMlfM{ExD{ujD5zrM#>W8)#
z1_M2T`+<vr$AN*sOyE-BB_P^f_y`yVMB7v0z*j)@1tEFXTm>Y0nuWhb&m%~?6-5y}
zspGr_&Xc18avH!&Aej%Vfaif|bGm;Z4Z7YnKvM5dKx|h<;cuZN(tr+x9f1wN-a!0D
zw=X70p*g;{0$KrCz$w7iz<EIQ9lHKfKzDqX0mcE*mxOzP=u5&hpga&`is}qJ1?&dQ
z0(J*J11bT_fjxof+f*+gdFDo0gmpkwAo?zOE)cR%e>EWbCZ!IP1P%Zy0|x^K0kwcS
zz@b1>;BeqLAlg(o88`w+p7V5pM8AIch@LS-&mKg-Wc}rW4>@+@XL%s{mT(_13785@
z2A%-oobU|r0I(Q%5cmuT8G3xB1KXqg$AF}tWdO<eItgsfU$nLst+|VF-)NctAjnA}
zJ<L@?S)eAcD{vUl8aN!t17c1Rl6!+L5M`jp&r2W~H)Q;iaf7y_jDTd^8v{xHz@{~*
zXl+XB-v;N9E`3~w9LYZqNNx`|fD?fEKuh3FAV~-LHmwcmF-iB+);Kp1A97&MqSMI+
z5`A6-ngB1gxL&mG5|xRRqviF+XfIL@6Ck-Ba}YiMj&5p4l&5L^BU%@c>lJVg`Oyc)
ztPrZD<^vUh3xK_Vn5%?pK=fhZV<6@%;R_(<EPCF<m=+d8U${>Qd$qzi2C4&>0tW+w
zfnmU9z%*bu@HB8G@Dgw}@D^|lus@5U)&j2sHvsPeHv=C5w*X6k+ks>~7Xu`E^}t7T
z{}tVrNxeut9PlB>ZpaaR>;d)wCICr&5`pA7WgpNKcmPP+?I4i!?L$C6U@CAEFddi(
zJPP~(ypMM`Cp6GESi5A-nmMKId#KxPq3}tVQCwz`;iYv~XX<V@aGG7+y#$@{H7%F;
zl(HYqPAZny#eOKOuBilPsTn5b*`(fzt_yEG<G=GSw3jFp%4TiblxTWSZ=<7Jjl@vh
zc2{dl-Y>a0N^#iSj8wnz*T?##{r&bF-9hW+!GvN5gGX9yr6G+9!-Kn-Mt@yc)pJd+
z^31^DrVg#=V*>f3e4{*^NV}aF=d)qU$Ud(p)ftXz*ngtW2A`vfCueQr4~smq{cw>A
z78}goq)hzNfmlp=D3ksYEcL}mdaIqpWSyHw9-7Vx4S9KA@9}WoS8c0<)wi_`%b}<p
zv|KTDzO1VMhVE~a=a0R_&8wRn+~r~Uot<X}YQ(v4UyjBN>N+jAI;%_NR-0E5O#IXP
zJ8tc+=V7hVo9MZuw$(fJ_!oyB9+BE;`O<Kreo6k6SIUWl*4j1uP(7r_Z&%LbvsO0d
z(+53YepRty`-!^XuH9?yUR!YP<blo$>be);y%wF`kK?4;8k2lo8gD#!T4^U?F)1i~
z-B6!A!<2_q<Y~PC1x@Eg{T3u(;g&$B_w(YZ_QJx0%_`j)ar^STI`=!D8@>)RHqXxG
zcHG)gFKeFUIsIx&JI`pW$?1G2z36u2)}*mFE*999q?r#pHgS04HoZ+t9Pdq+t|>TC
z=Y?kg+^g9vsj|dZGVOyh@0EOx+s3cy_c5{Wu@zPtS$<cYhK*J~u?1^q6(Uzr_EPTI
z>{eAuHOrD_YxPYqmvzzCtg4S2G+w&DT<Qv6JQLA!VY!`Od#G=gxmUMjUEQk9AvR_o
zPMp?V@Op^Gg6+9yj6<<Tq2(km%4st`ULzlkjO^QMakdlsR74cfv;EOW?6K$B6$&F0
zM;z7&+x~Q_Q;9_7LFbzBI}bVub)Qg_gesBCnmzj!Pvh{rzya3`=6hdP_s+cI80Bmn
zyTPq)Ls4oL7QF_vTw<KZo`K<UmuD_>fsgyL;3;WSr}s2}BRNAsxA*F(Ll4CF@ftCU
z<m=x_;<C`=%B2mVrVn3pq6U2(bGi5N44uM&JeTn2ddBT2s))|l$Dyib?pLWdojICQ
zyOeF)d2L06e=-#~&8Ls)mB4vBO(?2kUy`0yk>}UMSf5c#wD%9$dwxN*{Zi{ILE|6Y
zyh6!Xo!py>dW@pw{1>Y96Glf#u3VPUecGVl)nz78x8!8x;x?R5ys%=x+!BgfNXwP4
zQtQ^`N%~dc4G*7yuckI8i~EOljrDpranr<SE01unNF9m1*{tw@_#MhB!IpP;ll<mt
zPU%!|Ii;PvpnUqk7d7F@O4-*aYA2nZnT7dS(;3A|4r_d$7ku=+l8{MF%?jvt%Bw(S
z+4c$E?y!y0a#EQw{cT@<eRx&z&*n2W4GViVD`fEF*wO`ybq(`V@>=I9NK~4?i0wZm
zBUB|;t3z-f79P@0;axYI6?gh>RitCy8=+ryw`1A6d=@2~Ph`a}t|^ae;}kuIymTt3
z<=z#qTh?RLmm!Kv%UC-<+UJ%|yBboudbrM(!)}+BZr_O)G0JqlM`W`4c*;pf$a(~B
zIOR&Mlv}>|!HAgdzERKn+!y(lO;IQLn)k6Ul4`~BtZJ_u=d8Q4q0;Nz6!mdwBifo)
zWHh>e!2``adYz~{MQ|g1quQk`YtxJC$4eOL)yFy&yyY3*o5`ISo?W>XadGH;HK)m@
z&E4mJIpNxtHXAjcn9D9dI{x^UR^!wolXeT09%1fFrRC-pKa9F6wC#VQpH6;O2aTXk
zu}g0z_M07i?brdi6L~LD*H^UM;VG?af-QS4UXs{9y{F0g{1?6|)%NF73smYhp51J9
z2=}92bUkA1PTvk+_U2{YtNfY#?CI){ci&O6^n2uSApc+q)w=5yJoC|Vvz8AJKbI(X
zmGLe6SAEO&I+6ZT5qm|yYkLddgIP1KjU1;o<EH!Z@nr`F1qMFm32X{J&cS;C`uUPG
z!=qNpL;H=-Ie+O8<5xq@l?*&*$Gsc!)i-&F&d?>ezYV43_PHssyPnTBdh7c2;o8o7
z+9XJATze&DeelV?3;PE5A03BhbXu;z*}7Ts0X~PqZ^_PYG|VZlm-il9{4&{heG<3t
z#gkLd;~mogQa*lezVnyi+T9Z?+iuA{G{>E_qWX}c%%<%jo>2p~7#`k=cjUBOW`g9+
z$%BnsjT~-~G5Xqrh<C2#@k<Rla#EZv*?m2gs`2iCmRl=$HjVK?V|>tJKD~U(_@FU9
zXp9dU<AX--GmH<K9b5jzf71ue2QSFkEKdi8%?~p=89Ai~-c)<A{m}@Wj$HfCt9dsz
zgpWG8f2lp}7ci!<Sxb!gaa+==1rb^k@0zroHB!Q1!?0qL?T&p0Om;}CwSkdl2`!gY
zTtoHno2dWbOS%R3!NOS=y&bc?LkA`ushC?l%QqeC-J`S|YkI&})?MZOr{i-H4yq=<
z;ac>ra|@f`q`$miw5xt7-ZMO><;J~_){vKbo{%y$b?rf=5X-~iMS&OXZ%%ocyMKHC
zr3c@_hK6^PY!>6Iw)DQG{h5X(ER|SZ$sg&fCP%MhCyW?Yy5q*0t6yfbx0Ww3ms?jb
zXxKgzskDQ=Jso2MPF;jui<Wzm@#^v&wF@0QtJ}Cf3VUvpq4i{@fr;tF)WU7%V;8@=
z2OB${x!A0jGuPI%EnVQRaVd40mdT@1yNru{=BZk=ztrw(K?+rf=akX3oYbSQVU@z_
z0bS>hIF&bf^G4y9ozFF-9zI@@wIJ`B)Or}`7SPYh<qmU8&R-bev~J`~C%--!$19yQ
zm)9$w&==IDmM3Qo-vC=Eo!%wc&Ou9S!$Lj{w)!H7nmp6nYLH5tU!O@y`ltG>s40hW
zaW5^W7BwkKT2~Om_{eFt{$MvG1#Jd{8=J-W$o<`Y<ZS5Y%eL3{>sxhh+xS3X0hKh$
zCS!2?z2%0Dj=bptZM7R)U&HXde<bNIj4vI`&CJ1QfYAV>0Y(Fi1{e)68elZQXn@gx
z7#e5|nR)-J|34gw7Yf`x;KFQ+7y!=hzl#9i?B*=MFLVR|!omOR?gOw5KF4pr<8y4J
ziu!xIyYM;gJ^~LP;-u;B!FS`pCz<$bdifjAFm&O%+B<MLI$As}dtL4@T^`?o#~tqA
zsO{*$(;hyQufyYU`8p1xjB(61F*h;&moAw@c{TZD9&RP-2(AE76o}6P<u?kxQypkO
zwI3AJQ0#KDktXpM>m<sK{-5+Ok$yS}kKk|O(@cCMyWwx*j{{l<<%#PY@t%|T<23tR
zHv4wVQhIXB>2gw3DH10BI04N*_AFeCV<<kLHPc*iH>A}`R4=j1t*<Y(C|y5Nr{5nU
zztv_RG(O59nD6XO<eGi^7T}zri-#%gCWgONP+z<TrWTU(Zj*dm?fG7l9Y@0n-+P+-
zOfP2v66psSqE8pmwZ9P}A_6|Cu}ClTn)E_^q{%S^AEFnSjVT966}P9`TkOi}>!Zth
zaRu&P>iv;~*mdV2ujaaw_G{DBeh2V=i?rXQrgDC0DkrEFw9kMluq`Sp6qS?1aUel4
zT-<$~-Ql+FEO6$!z{3~*bu9;0Q@H@&J7^z8QiiQ`n&9Q5Y@`e`n*3Bf+K4U#wSz7L
z86P9$@LuIRW#GGc`*?kue~Xei;9AoEMJfL7f4VFr@8*~wl}&k*JjtJZ@FDd-{F}TH
zAHtPHbNDvnALm8teZ8sP%HY|Py!D&v-OyH4KGLvc43aX~K{r;v$=jE7!e)ijbtC=t
zI|p62=6<e@Iy854BHP^0Rq*$ByLpogQJf0;gp0@bx;gR9l9Ka58JjxBZwjZ6kSQ)h
z|CNy}(#KH5nqVQ%w@?DBIb~6o`)xnth{8#rh}1iLK!IzTKWX1Bsu=ntdbGfY9C*bo
zBs$dxY68*qX@3>sPh*Dfcy%Y72t;*+Gl0fGGB4v*JMFi@#^0iOOf<id^d)ev3qItS
z(j-UH7L9AscqejXS|nqM9LPgR<^YsSNalf-*NMg%;%?ylx7Q&bA?cIoHbRmXXi{{!
ztnjyJY=95ibe$w{3_j#wH(l2oNc@e^r-hw?$b<GTQ3pbX#LJ-dgEG<S>f)TJ-;4Sp
zDG!?ESN|W(WpsJ8fC@N23`oX{HjuOj(SxY(QWWXa-`2+*a-@C614+9~1rk3M57_kX
zBQZ8BR8i8=w|@7c7aLz+*tRcAIdl7^9=i(`9$QtEd&{o!C3vl}!-?F+K{CQufr@S~
zwHwOYT3o+gp+7!tdoJta6shAEg4Cn^(e|`lFK>&U{rZ-5kDnIcHrXLyMWoPj;Fph8
z`e8X*-A#MOfX^eK<$i3p%|)ZJSx;Dl?`;~eOip*Ey5;gR9h<JJFD~6Q$F_~IBxv)c
zCpNpmx1`f6A9LBu#njvN)0nYoJnJHfXWMhD0%umR*ZS5d#h*`Ihx;s)#%67KK7w6W
zx%TmWsr?(P<xUKnE3>;%#Vp~#e*OIei>I?5AYMmzBDdz?r&Ha-J}xWQoW>hJdU(V1
zeRo{9l<e>}Q!}hgsZ|2MN?iNoVme>;4*$keY0{no+1W=P4su!kY>8}a{(!2O)4jdj
zGgbQ?fR7O^x1iI@w^lYQUA0}exH|RNuzl&_|F(ViXWMQ6D0^%oZQs44Q$KQcR#oqH
z?Yl^xv)MT{#jsSnEF$Weq4XW!Ss&~3(O+n}dYS7MmkzP>ibfW-%6xS1rS0Q+k8N!y
zyh&txXlVFM55PQx!O3Rzy%`g?b^SW+vg)+ez6x6kKS&%5qO2n0^k)u#7_Ge*_UEy*
zTx}=2TR}ay+d1aG9bY$4rmoe4|F)fV2qq^s>&qi^ne6^ab56<kx6hh&?c$MYg$w7d
z+D9JQV6k`Y;HOy>b(=2VtNf2!9VH_xQgrTYs+zD`^RnZq!M#^JP2Xdm;$9S#i#Z{j
zPEU51Hv2W(?|9+J*D1LxG)jBkQ79}p6#C1WMW0J@_vB#05tldrg&w~@w#SOg>-VAC
zO{Hh7S7u6=NiN&^Ur&-*dnDo0-E&zHXR7CHn0vW*|Mr#Q+jsvcyX_d<9NDa)GY>?3
zG@K=U#&WL0>yC}9#*gi3q?XkvSlal!I5DYfC?;xJ?$V^lI`=k9AD?b5$XsMwrT;YW
z`Gf(=S8hhn_U`@e=8JLgU8e1)?vcrb^LI@i7Zf7XM*7w-)niWv_SG%6jFjv(A>5Rs
zwHNnEO#W<^-kJ}!Y5~0pXT9h#FJxGGQJG+@%E>ibVxuN)*s9dm!V~;vI$y7Qoh+6u
zGi&WVwTz!&@>DorY^TeK<HO1xME_s0+g^zx^}V-7u$a5?Wx%%jvlA9KDtF&=Ec@Bp
zQ|4|@7tLsQ<<S7##Jke<-8AT0uN5_FmXj;?oif*xbL|im;W^d9Ixu$40}Zp*OB1l}
z#3F{x@_0J<%|+v-X=nU<-!IB9`Z&A#R>j5zCWjBJkEvQ>;MEneP_RG{hi@(}@7wMd
zl3o{nn(k_qDHD8Sx)<G(uKFtHyy2D-HNR9(T`u_1kwk0w^3&xTD|vSO&ekK^7b`gB
z#uYS#<vst_t{jhhKby7T=!1u9iEX#+e&bzGu=`e+=g~1i?X%(wRSX^u=}_m6d#bqm
zt4_tjgUx!BUK^jDnATx(^=v(pkL&&IToxUBFzc0tX65Cgojv2A=b?&3?toL8lEJ#X
zvuiu<J)9Ld&1l8Tj{(_<*E?L8xb@_XlGos`JJS91$NRMg)A=SD4vCX5OO{D~knK=H
z)h}*8qWkHZV;!Z#byj%&axxDKuqZlTU-Ri(4N^O7+;SswTg<^hUA*emmyZzM?Gjf0
z@ba923mnAX|8*-}zW@FHuLtP*UQ>$T?=jgNrKx)3#9^&LuWQa|ce3pitlLo2%p?EV
zF=Pwqe0wGDey-vEZp#7x*4*}&JE>nyPW95;HZvx<oqUI1lq%)L=aJjf?XgU_tjoi9
z!HYP(IN^&6QhZz8Rt$}d+bw9*>*8L&?O~aSAwtVlxerskb~pC$ZkhVmc5fv+xNT1z
zD?9egQ~#5RQKdb#F<({Fa;qAZ{Bkvq6&S8~UZeCZ#bJJ4v7Psnsz~XD2_tMQjnU_S
zHorhzKkuRRdNShDy?rOY*yzuj^?r|sm+^yR4<q9x{Z6l&d3E*98&X+V^o#2co=B(n
z*3ckD%h{&O)QhT8FMGUsHRV{??dz>u9s62uk{7#qz##CKXt_Yo<3HFFGM}CgjvbVD
znEAx~>#)^}!nxH$%e-o}H<xvnIDA{fC8Nvs>3EQuMXwLK+~z0Mw0fs!F>QLy_x)Yl
zE0J+--=o!(q$I6i?e*Eo^Az<52b9dK&s-dFfBB)n6`l>2RupAM%PIHLy%Dg#%JkGb
z)|o1qn8$i5qbY|mnYUh#o8hWG&9oN&^mM*AO!y7wMn_H`>@p~{^^T)5O2QA<f)?j^
z6h`!a8C{wDilW}r>9v<KGdew|Ptx+iGo5z~(R|e9`pEQnY1WH|WIc_U8wY`h)t0XB
zjil%Ht|#T@Z;ig+aMxyT{fE<UB8y}1y(kY}6l;EykLL;_T8?+APm)@7tFzV;+jf0_
zZ^i~%&f|bwKgwX5!0^P)Sk2PNV?_-UpPcQ(>Y}Za>R5VGc>`k93?zD4f697&k@o5y
zOY&n`=6c+0bImi2(fiH?W$pF9zq>ve_Ze~hV^*S#*{mtXzP!XwQ}1@;vyDFa+~^)R
z$SU<@uQ7Fb7WyL=J`6gF=fhq^&fxvEX`!RXMPwS3sm(1ew>b8cJ2qZ(`bNW9TF=t<
zEm)4&Dzw~K$%NwU4?Vjlb?7=e)JQ2dN^S9lMPq(Z^ILYRwZXGLa&Ja){mcI<{>O1_
z(r&ZX&+c$0*)>XG;oZ|t8!a}~1+8(~tMGisgL=Q*M(r0J@H|7y^_K5>{EBYdkBbXT
zWvRUz)OkY;WE-_z*UD(9sfHCsB%<Hr<pi4*v`&ARan*)lvlDmRxR~Ufqf@^<EOvU|
zPl4vme#LpTT$xV1XG2i!m-Bf=>-*$Z%}M_>=SycZ=d?o;>gSb&xSELXe=M$FvAF)i
zv*`L(-O2E-Pc?aav&iW5yO(*cIiG^mbG!A9c_3YTa#q9syW;!pit8`@SMl!^*FTkm
z7fo!|9j|p=r<Xb?R0xhqK1f{nrqnntXkmEu`6bt1nH?D)(}kio(sGv<oJim)4IOnj
zHMVNv!<!dB%}q5N^kJLII$y^x_ic>OUvg<V>%jY`N66oe-gY(j)rq`A=>`LB6xw}m
z=?5&XAEqn)eEGlk1OB7@cHOl|dwgnp^vUv@nePUEiCkXfzpAh8(@eGQcW!akj_<lj
za?XJBh-rqGjcnHWl66icZh<>XAJ*7T+_c>9iJ8fc{SS7@h8rd9SsSeEg;-Jax=#6M
z{Bnov?&~&sE?KubOm?&2s=iX_$cOIQACkX1Y7Pye{xW{R+iCsPx$iP+Sd^HQ?mE3U
z>p;5`riWe^utuKP;yvo!+>M&Gc*pRw{d@oH{<x>;{t~&UGv|YZ@uj;Hq;GmZRdaun
zv0zY!q`{mc?tR;j8&<bfe1B5LPc$&aPQm$Rd0>wXY1Y-QM%I;Goy!q>i(db=Zlj&L
z&92`hPHD9Al2pU9s%I4TSM7_q-uuPmxq)9IRS=VrmP@`Nb!M65uFaiHRPP*krn!ba
zX<R|y0oOHdb?Df8#Ilk0cwbD*y_{ll)yY2W%lVu8J!>n@ZanlP*Jssa#!vLm>nFN{
zzHhzo<1W&eXuW%WOvG0I2&JI;!=`%|8-@i<v-Uc?>0%D%<}4V0*sL;J+b62V9*^=)
z=B)2<J9qPik+QuT>vL4i&W#vv^>SG_ViMAF+ubsk9#0!mR<Y2q%za6}*Bc!}dZ=>$
zn|`A5^n7}%R$uSd{b8ocU+Zg&j|f!~I&mwwpT;*>)do10uTC6^n5uYZ%x1k@_N;Ai
z<H$0@rxOmx`o!8yKE(QTcY&YXpxr6!haa*0fORY_x8<0|#d_0qn|pMx{Frs5)FgdG
zU2FEV>IApU#tyGMD|g|!jLvtpcI=?9D=nwFkIK9CWh3uNe8|MFmvS!my1usR?ckt;
zSi@%1a*UtopT$oUCI;qUG{9(p(Ey_XMgxon7!5EQU^MWDXn=6+{$>6@*MsK%3%s~)
zq8<Of-2u>*E12)dbMqEC01*B^WrsZ+sLt5y?FA^eB9x*moq1mF-tLY9w)&L*?8zPi
zXIJL{XE!JIXm?i+XKda@k$v=T!R|GxiMOgKAyO0Jj}v|(Ub|AQJAtDlOLLn!94_Gu
zw_po<d-I1v=106-!j)B^(*QSKPQ(q>Y07g&Q=aBXM+%=Y_^d?6=R`bnjyGSxnL2gs
zP!8XXYwyCR^CEKJIcT12^PUz02spZMoroOa=Dq{!;v=dH;f;&p%ab<3D-Qa=;~dR{
zR0Yc847iL!q63)sf8{}n%0=&KK*y(N;djW>2TX%B4-!-gA*lyUb~Fz%3Ve;$bbMKr
zV{H$|OWSW!8*sI>LECV0*SPjiuE=ndws{U1^40375#q~>Y1b4tu3o!!<hj^jfamhy
z_6hzg_Pzt%?^Q$()p^%tcBT(Imgiveraf;j3aU@!e#`?Bmscq+Us7BipE1o_{4rlr
zT>eaJ`n^`qm)Diwr@qKbUc%>m|9zUcd_QsDzs{!Lqhu-0%I`-lFWKAU?YTkP!(LUo
zPP)|DP;qnMs?}dYv_3?M&+ifU{f)Rh8*%wU;@XeJwWEp4BM_HYDK1}VHlOr+3D*h!
z(GC|AhT5nYf1aL`GbB8%R<(S{l=(9URxhvKib+mf9+0^F8FAlNiOY)#r~B29-}i|d
zhf&=3ed6*AD+d!j_ejqV=)ES}&|f=UE0t^3&~aq{+Xgq+SNEUYrl);&<V^6Q>2aP@
zv`sbo^ucyf%U;Q`-_5W~@VUInKU%ZLWQnEO7Ex=bfk%LMe&8j<=6PmszPGs3#ISG|
z{{6e9Jp*13+A+}~OQOrV#u@Iocg11SXS0r}9I?nuGTr6v9R7ZF>?^B9B}#7<c~Yjk
z)XrqCYc1&}KCfI{{<I3soA7J2@r>V@8`DE>-okew$Mk!pC76#;+%<0Nc~|{IL*Buz
zF0S4BI-TC}TtS;vx~ta6Nv1`aJ)ZnLWZx0rxBb3Eyl{(7@C@6vPkjFQ61qL^f7(G^
zd@y9U_WbKt99AS&OCAmBI`G(B%@oIe65V^Mmtv0`x;=i(D;Jml;Yz=M)oE;fa>TwH
z#ug_Af6dsleE88;TiqqMN%THgVZH9-2i1DqFWIEsUaKc1^FPe1R~X*^(TP2w2F0gV
zcTWmPn;w#=H7YoDL%#UD1abLb;@X+Tjqfyf7^z2i7O&me!0gxle($miQ$8rxoUXIT
zFni{E&CAMH=C&!;3i3KcZvL%hk<`Iq>O+q3S9A<^e0Q|S?s`DKLcXe1Lb~OcDy*Hv
z<yngxhfG{v!YBGYw^_yv?N8N$Mpr$pg<f%Hvd3E;&TPMbBGtVyN7_m&Yq9uo$3Mab
z#b(vyuU{q%QHgb8*PG4K-()j;mEeQQgvs&4W;6=I`rUy8i@3Zyad`wO^g8Fq{A6)?
z1V20ecVC)^`(u8YxN*3bWAVynojNo=*Cte7EzD|C)+4U4)$V5}pXT_#QF>$@lC8BP
zb*cFKABY=oTHH9zr*Us(vvj|%$~d#+bF4pi;E{0+Uq>vdh#x%DF+Xgv&?l*f&z2(b
z<A2-H={<Or&wHyn@}^4Vu&8d_n+Fx9&OUHTBCbO)C!<wqjlzq6!EQsRcj4odx9=8F
z2evBRK9Lry()yUqziaQ<P0t7Uo}J1*ZP`}!sp?)JXV&CVr5)ep%{r|#!qTIwl4AN^
z2l4%;#N`Ew8{gfU?k|d0r?l=ib6x0ZotSoOrqAwDXzSxEX|rLrg3+bZV`opd0}q$x
zeg2qlDlX4K-1y((@&~0yk$yF?gF%*V#s0`EkBrZzN`L$kf9=-QL+kJAThz2$Q&caD
zxj@`Fk>bYH6PIr)E`Ly59*{o$d^vcqnzhXrGga-6Dr}XKLq*FHI!YUbA9xmc;?UI!
zHrY2tTz`~7^!>M9;2$O3W3}6)`{_5*Wp7S8P~bDJtB&N@9kGu;^>BFo6~2M=_*f#4
ze_}P{ScP8u&G)X<w%NT~&Tjjr6OHMDHpZV;KFH3)UW$68J-%+QT2pd-UvR~zZN2u(
zZphSJBvBq{AWSq;-7+a=QxC5A{J}^%-+KLnZ-!2sOXam&@Km8y(S@wX{Lk$=UEP;H
zY+-c4fe+xrio5@dxbeir<x7go>lJr@m7g8QT#8=*l`QmrlX7HV+HCt?(Mdf*jz97I
zIP+lk>H~-Lz7%iw#$I7mBJRO#mW<gU{_2Y2+&eW>*EpthT{`FtPfybC+Q#G*MLquf
zY3bNIla`yy%|GTn>22sh&9>%LdHyd(^0#7Db5b)U(<+}I*VurypSXUW;__I;<#YaQ
zzKghgCUN~9E$H?A_*C^R=>u*|Evc>dDJ@i*Yg8W)r#H#!$uR5U5X%Xxuuv42A8Jgu
z?}C$yDo$0}2R$rI*xz5%a>tMluVQ!c8-tUjZNrp}=iuGjF<S1&JQij8`EqMxaGjZn
z)kkOEg;R(2ZK^W}U82&%bVTX%tx5B!ia3mMas7iV4M@Lw*)y=pQswHhHCmnGFLH)H
zT^E_dAGcxj$_16%j!mty#`9ZtFCv%WloBu@)Y{4BlJc(QHr>~p(Vyv{Jy4JDyEV6J
zT6MRV;`0Z^jRU%xE?>2UYs`vLL4yUili|>d9@CD?A4y4ESEXTJKF@@smx!|E(CgTU
z8^xFR=v&Tt*4N0>scwL*S7gQV+Mz4+Ufv1Kwo$Ng1J8y|&qz6_>hmp+_2J`lwrQ|8
z=3aQeqJQfBtmv9NL1@J-bqn}z)BM#jnZF!WEYmzGQ#|&=gmK!-cSwD@GvS17{}2yf
zDfx!4Lfn7p=cwYk9h}kKO?iDEot@x1sZakkueVFJeKY>G%ccXdm1P}5#OJYeq3`=t
zjvym=m+Igbug>>c@N$9ky?q{zgF@QBso#I2B5XSg>n3si8pQSQ6W9MnT;7g1{k-20
znjH9OSMu}FfOaQ4EBE#36j1qk;G<{qDH*kO2?=_O@xa9#j0PADFdASqz-WNc0HcBb
zf(BY6%?VBM{}5(sA>Yf5?_vuZy0@(liSOs_#j|Z`?*G=(@8a&HrO9!2^>F!zt)JMN
z+x}Ws*(RI+Z*BdSu+zJ<O<<jOg~{BDmiD4X%27OD2TII>P<%f=<)Clt{{PrJ54b3@
ztZ$cKz$}Q0sMsRrgeZz&AP9=0D1r&JX`l%TbVE0SkwQh(F<_2}8C1+UjsYD5B4#l%
zDq_Si23%0T|GCwTj5FWbyX*VT?!Hw&+lRV!>V{Ld!cFI>eAEg>sLE%QzfVtvN<G-7
zgHH^8VWF*^2Rm~p0@u2=Fj1jIc4ewCq^cd`Z>c9__^Kw~M6$&-QkWAUb#fI>4Uh-Q
zqC(ZMRaeGvs&GuDmPOJ~KF0ma7_Jh+oCZllRBU2^S|KfY&Q{@gxFRx47K(GK;GEq;
zm^>y#4PBKnyd><$P!s|3Vo}ToC}Vg_I2IBfC{;vC!)5qvXW_3j@ydf_>X1=#X^bZP
zizZw_lOh6XUc_jYM%k(~UxHK1RX7kRjggL#M=Ed*rQbj}CUuUCR7CcK#llcb$-pt1
zqd>=Fg*aiEjjp}6bd--uh7!nagHv!l&dt3C@)w4&%hsBC6sZ~=qnW`rBI(#t6Q4%M
zOt-#5*obgB;)k4eencqZ(8zPuP=J*<hA6lh_|aA!(*%e$z;YnwP%!&fCSWD(qf3y-
z5CzJ?@sQ!_fcP8Nj^oii#o@;{0L?)Q5KSGvDTu%MmS7{$5=2vkZx1#BF)Tthr<fd?
zm)sTPi^}GVFro|C73={zfS5<ZY=F6fy|Ld5><i*=-W|l>`~VPt^Mk?u;1JLQ90m>q
zr67hPd4CWxd<X~`ekAA(Mu3pzM}fmZst-7a9}oJ1v0wlg2L^+aK*YhvgQ%B0=@a({
zKNnPji$UC_d=iK_`PJZPFa;a~ZUD!Eo4^U+HV|nrn~yw*ZaofZ@%zDv;1LjM@<&0W
z$sY%&fTzI(@H{vbya4_LUICFO{u($7yamn%?|_NmeQ*x=5JZ<6{|KB9J_i?oufZi?
z0k{<W3@!sp<65Cie0gvcSOrAc_^RL<@GayhPrVR1Y=1qCPq@}^PElsTqGQ9l&Y936
zsPx;^rY4PKcg)>i|7`OLd1G?xVoYoNTF+<b?j_4s@>@KjB3tUGF5kWSeeJ<HeP<pt
zSr0pexQG({U1rPmVm>X77;0vEqum&jGUpei_Zrk_y}_~hci&Y|J%ZBqqVVwb8&}<R
z)#2`@GY%YE^fY_Hm;P_t*_o%!aaq?av8da!AQi`bU~=v%s|lm$&1vo3Vv6nQ!U}QS
zSC(&<*5gFSgH{>OJSHCXL_x$&)PSe~Q3Ij|L=A`<5H%ob;QzD+N~83B|K;{SEZeI?
zqQct$>wN&D{<r!7inA>A0~n$08Vz08@1VBpP}UgMhACNCUm3O0sEtc<)mWG^ROT<2
zx?x`{o5k9`PEH6a4)bNQuHk|BPS@JsHqj>u*tpXBN@@$+Yueu0{swI}Ns9U$h6~4w
z`y8k}?k|LOckb)%(Z|6}>f!9^fwmxPtM94C+W7<eIXk)HkdwmzXKGrqxYC7V-MU#~
z(}bNV5!O}{_PIoul_pFdmiy5}V&}F)81+q57Q$Tn_Ve<Ty7qNJFbg*>87`=ih1V$=
zKGfNR+P)M|hmzq!saRRuN{07!?&09+IuLDa*6%V*IEGNEMhnP*YhPDSD1vk}LOAZ^
z;N~WEb9L+^b@uRZM}wNuTlDo@oFwh*fD29i4ccpJ$*!M!xEyI|!*bYl?js8d@kbm&
zop{B<f<vTXGS$cuvi;ckp3w?xtK#!{7Ur*z2L=|O&#^G{o1j;P^i264tf>z|U(46p
zpv}iomZqGg_y*^s;)d4LAudr<x8@>zIo;^ksBeJi1LFFzJ_4$W)JISjq&|Z3pf6Yn
zl!1nzA6OIg2Wx==pa~cXnt|b9LogCVp9qJl&g_jxfmFAs&%hc)KLp<e91YU7qrQVa
zAoU%1f#bko;CK*ev%Un<JM|?{AID@6X|X;7q`~?Oa4zdJm;_G4ar7T>(?K+eS>FNr
z30U93Ja8t$7lE@twEtNjLNb_${WT!^Iapr?^%bOHpZW@RfRN$$fvZ63yP!UTqu^RF
z9b5-eKLPqf_;X+?NPQUS7vV2~nD)$H2RDH?LB!4aF1CQV*xw310k?s#!R_EX5NY!t
z!JXhIa2Hqx7j8F5eHME`LvTM>13UoM0}p}?z(Zgo@G#g6{26Qo9tGQi$3ScFIM@X|
z0Xl%EKxgn5&=oub_5sg={XmqF_XIP*!63@Y`+!-XFL)6Q08w^67`y_8gIB>w5dAoO
z6bPO0qd@3{9|zt7Cxe(y$xj3CfV056;2iKCI1l_4TnOF=7lRMM6(DrUuLSeJ_26T0
z3kcovd%&mQ0q_}k1bhyj0AGNo!F=!>_!2x1{svwK(GSE^zup%x8^ptpzXjr2@DISU
zU>;Zwd<hzWZ$Vrm{ym6m#D4~jKs`P5Q-b9{W3Uof8>|YNf;GT8U>&e7SP#Ut<Qsqu
z!A773*c`+)<y(Qx!FFH^up`(K>;&Rk^PR!gpgq_IbOJ5G9w6!f-wU(?-NAO?0I)qc
z5JcVJ2Z46rFt9V|52CK{L10&q`eeI-O3)r01)>h|F`y$j7IXr~gT29tpc@FCa!v8e
zn!}-wE5)@JUrq0|^@TO(?u?sZGt;lu*74)?q!yuD$4_%zvmX^u+(ZqC8W1%gYCzP0
zsDU4&fzpV^?;rL5S8_r?NIM#B4^#Un{6+*u$~D96A%0;}ISn6cTmYio`_J0|Fh%=H
zjeK^l$9yy?$+`d{r{Q(9(ggbe+IDrCzMz*~WrVf*#Bp8mjltS@rQjs0IBQZ>lv1g{
z&^_4(@D)z`_J6iszY5Z)13hc8HZR8Ph5bsJeQKBQsL765xb<z<mSiccLvff@M{U@x
z8d^CkYi$_+HLRUBtkKu7;`p+Swdc0&q?McSHLN&|fUjX4v~nh2!`f@Z4p%RZ&q^ES
z_ce@~ZESu*x#BPzwx4FCJ+A}X?_a#%9_1E%`jJm9S!9qV?}DE@O_(Mv!LJ>K!5`u%
znhZhy!;F#U7+kNAaB`ZcX2uc7PvA=U47`M^AdjK;c16P?>@S0`wlWBL?PQoIwB@-0
zkR_WA(}lcoBuo3b-|X89Wh*|u?3?}f-|Y7n^jIvv_nUnq;kp$cAO6k${%`h;g*s9!
zulQ#FS&4n>lhE41u%R0l8z~c2ocX^>LKzcToz&KI+#yja_>U8A7?S^<9Sp4xH_{iK
zDh<P(hVw{wn>6*EbgS(j8INmql=WK(9X`}AL19@e%+a+6&eewHurQ&chx$xPRfFF(
z?YYu+tX^ot3s^Y1V!jFIcC!9CbQTE*=-Ds<=^3zac5{cK-my6&+GEwe9#dh~O=uwU
zM8{%rp2;`IaERIAxPdl`@XSD)8wy6h1<kYIG7wIiE!u$wpeNV{#4$b&90pQ<!*FmH
z$W?vCqfO5CFMv{nqs`0tf@tG%au97&4tZj84oIHb@wAUN9Tx;zfx%!$Fbt%2Ir>2O
z5g^GcHT&_P0^u`3B{&z10;xSr{Vyj$lBf19?dO2e;A0Tw<6nT|!9s8XD50`KzA;Gq
zc3><>?MEK}dV=vFwG*d+)XpRMIL&?nn1Jxv;8buvI1^kAQvb^a5W3>Gfb+pa-~#Yh
zkmAYH>=%Ix5ndY4_C;WMa5-2DOaeQDB=4x%?+LCzct0>1^a9s{{@^-rDoFCPH2Z77
z^$6btrhwZ(>Yq6RZU!HKB>zOS{~4ryo3gkEw}KTxTx-5IxEt&Wl6-f~{t$2v!e!uI
zFc74E88vtqTmq7OvSxo5cm&~xz@Nb*U^<uyo&>W%>W9ezsUPM(Nc}Faz>8pwGD3WH
zK-#wiFM&27>K?Nb(+?uTvqE@=Q2j24Uw8ayYXv!qrZrd*Yy;K+Ex}q~Td*;Ro0j$O
zwFlo~-=OASXGg|lF7+cUN|#FF^6W14&B|_DHNF430cLxC>TWaP>h&oDJ`OBZ#{n6|
z%`4iG`J-Ltl#ZmA@B57t?Z^~9{Bmmj`k=B6efF;!J}>*)!Z*s!cn3&Gf8Y1V@K@Q9
z(beydu6AT}_4}i%y%}Bo{)l#IM7uPiT^i9YjcAufv`Z5)|Lm)Ijo*%KhK9snWtV0s
z`|hl?Cvj?vl&*I>Ug&Vas8__faoMMr=9t}|yCBD`VZpQR^+fwMyUL9^*CuY<fOA>H
z)IWK+%pO$R>R^T|=B}d=A<-A@*NFCOs2(&)?3-BLM!no<?ZrHYtycqTPam|phsCiw
zmqRaGnp@mMqf@kBBigSae}AI=8qt0Y`QsAp*ZjGEYtep<XuqZnI<iIkHRzZYw?EYY
zh77o&KYaY(UmjAz9suY2ui5_BuF=PwM7GrgY3$7ioQ$!^EX|lFrCMS+IveY(CY<u^
z|C(`qVXPWM0&IMb#;$2x8DnOgN;XO!;2+J#vtJ>MWFqA%TKZo+_DKuRecAY7xI7xN
zZ#3};`N4QL@<&@G{4l)Dw&oaqpuE#~iW!Ke4;w$hz(4PSeRRRIHQX5B=P?$>bpbbk
z&fq@K1<V9{fLS1#Pdw?NH%Q|zIrw|UT>6e)cKCYK-lMfst9Jjnsdv`q**4d#XGbWT
zhxr%mxb2kr0pHP{O-OEH>$^#hMvS%ToRyYYI<r=(=RF@LHS^d%$vmlT<+z6WRiWel
zBzML8M91b8($4zlW@pq}bU1NxKrO#=^SaD@-Ru6wD>fBT0FS05*R!GDZ38|1i2O?R
zlS6D)7CnzV>d~~v&W>drpYH#p_^iYnXBOZ5s(SA7#6y!#^=af4lw8Y^`^*O_Y*NPE
zXf`BymvV&<#-Jn=-}mi1>gvx~S9|Na_J8ZzudS<nbY1P9<1&kzr~y#}q6S0_h#C+z
zAZkF=fT#gc1EL20VGU6G|DW~$7pm}=h06ap`QJZGrc|jTVKgq9P5-C4|D}At_5m3D
z1OESvI159mbd<kTrbdi@Q7~AC`QH|X!SYZgW+#^jC7Xj5hB9?1=JwJ#<OdMT<kfO4
z#}1bT$-`iyK#)<X1Goy1859y8pomssZnK4<iy|sK0H*U4;ew2Vqw9BM+zjJPzOLt|
zHITGnelPOD)>(6tx?+B_3C)$qd~D{I(9NljOgVt5W{@x!oAm!D8|$CY&c*JEeg;9;
zf<ZkBr#^*9W6TGZDW&8?P=$T!zkn!5@+w7Cq`#czISX^@QFKk1)E`BqT{e#%Mc}$Y
zJ^+RQL&60GnBknd2-o|4c=3rfIekNW^fLsb%q<~T#L6h7Mg1pqo{+vYR309r4yL%E
z75Y&hi7$SFUIcwf&>>PDVV?NWW{tiK(joPMP&w_u`d~K@T^5`JXbC!k=s#h7BQ_xQ
zg?NL#z_*}59rUlDfD--9K|4+D=4AdnyXyLF$HsehoBHJ4nDmtMl~43ua^OPl3(Otx
zV{()E$;LO|#Ep`gNfX9iPK(yNVlruF@@jP%vy<y%mc?VTZX%P5?&-C}ZhPhVi!aPv
zx_nD3<H*9MQ#$h3jN>2Q{AFm%5dpgQx$5dWNLODby3Q?3sZDx$)!8nsZHTw=fRh#m
zPwKvW=CLRK%K6fId%hGpWF{?afl0tOncVk%8tUp3QrEHDL#C9!f@;2(Ce&Nz8<_FR
z^<&G5AN8_hZ}jmyQZ!EAJjp-z@CmHXW^&*6MWpN8kR;R@iT+O==brYf@u7p$XTv_J
zS7KLPjCy|kQuo$oT#KLPO}^d<6)}U!`SAn#yPm2uV&L}I<&SizZ*ir4%KD6B)65LB
znvd+lKSYO~uD0lP9m~wZjR{|ITZ{q*-Rt?K-HcHQve#C5kp<QZ^J<sccBOgfe&c0c
zZn!6zoN}{aW6sV~-Fe@|B+ExL_uMY(eedUn`o`8Bwg)~sP=6lgtYTh@MBn&|JoUZa
zn@(<?UhiX#77Z-&@NT?$x#g0}@3WoG7WTu$@O@0~f`h#1sMAcZ)}gH?m0q#CqACCO
z+=Q{GmA9rhd$Q>H1}v)A)yLXIbbd<ooy)DuNq<|fc53AsPLsNsCM7l*dty}gI!$6G
zA1rNmzxO)beJkkdyHr;nG`jk}(bad$c|5=*`ZJChKVRbgZ2B<ws(k~SSxs3JAE+!y
zj-R@`P27?K{mkXM`;==Xq4>VvH#(TfeSc1JGLsuTcSz+U8^RK6jl6a!XujKmj}vAE
zt*`Z9MRs9K#wTkUbHB~x8W`2vd&Z{hyRnxYt8nY*HT7>}SLKs+*zAhUn^?r(nx2As
z-+=NrVUBG(`}}$BhNP^xa57bOx<lcz_$04JAIA5*vEtI|LVrBtnOtsx-kYXtA8x(5
z!(e`&C!KrS=4N?3tDn+pw(rey4Ntzffp;B~yL&&jiP8SNmMPQid$v~%(7!nHR)f<U
zZSSO|+&XI>=-dqJJD6Nr!3nQ$we1tv7X$ORIu713@j|NA<^3HjgSHP@Gidw8r5u;Z
z<nlVKjVPK>@cDS=?YRvz@`vvFF!XbEmyn%Xdle4PofzhT`-sW)eOPnHrM}J=PG0uO
z-PyC<p5E<0E$y^mT;O%D^6xM2`xps3u;x_Wr+H5d?+?+-H+?@jbx7Mr>v~oRwYAJI
zOm5{`zM0|nsnNRoMp@3{D|gb+`sU-qeu<vkt`8TTf}dU9T_?-yfOYTmXwRaJSwnR9
z?V+nLJ6(Ny=<3T(S6_v?`m!r!L3%zmWXLoB=G)$kZ*k5pSarUs>hRUT#1Q+WdEp=D
z-QIo--xIp}yt_G<;yYg^$kDjQ&XDUHTpC`M*u*}}Y1k_+(;#I=>E2Tc9|VM9-4084
z;^B;#!<%Y!ZSIiL+{RZ@r`^Uq55puS=OEr@a!~>K?}vRccv)R)Ilwq?>B@6cr;pyi
zjrWXd=y+!Q@Rg`ny86u0)hC*+zV=o&qVl@9^>lU|m}43+EBe9ZchP6o9p(lc8&mUO
z<Yn{8%X+C4y8E)z)hCOtKHGHl1$YqSR}%f?L)Y?W24=qGV_w(XlfEiy)Vkv-`fJC&
zf1F$<Xwgu9I_$qNxi>j;CfDuyxs6F|p8m>rei@HE&rW<aqkV_P+rm%9E?e0NcAwc;
z*p7<F8b%nFpI${de%`?_ZkpkgvDqD$*N#qn(C|jb(aOELkD2MZMn+d3*}D3k)77V;
zu48q&`cT%@*VJ1!MtD4TPEc<6_?3@tzW3?9U`otA7l##_vR73}=(cXn?6~@Po;JX<
zT%uop_u44|>9yy~j~F*+b$peD>a(_{le*kgSijxyCD77p0>}NkkLi`hfUiVfI#5|)
zptOD&b#!$3iT2Oh9L;Tc)K_+G;+N<RZ8}(uTa0!JliL_>DyeZiz1yp>FE?jbUsGnC
z!Ti~0(&ok;Xf(1>Tr;O+tfyph&0OXTHX0MPHQ`c~;7^@TKQ1&<Ip;jt5Ir|l*68Gc
z0morirv;@e&&Ue-+}^r&%JZ^|Gqw&@=udsU)uiHrWfLP3TP*IpZ3%3MGr7a-%3XAC
zZLim*z1x1LbJ^41ggssxYgbj87Sc!3D8lqL)`c>;+3NeA(|qTznc6ob>XXGzR~wi9
z_VTym8wcJSaQ><DzNbIl7n`m=&~^32_M?5Q>FPsSSKn#6`cT%@H=eFO)^zo?tgA0J
zU43cm>a$H(pY*!=7}wP&y{<mSb@g?ot8Zyt*SP8GbIhnMJr52R*mk;fqn%^@FNFm;
zJ9zVT)nrd)A6$$26^sddJR_wG`dFCU4C|y;U#9i(RCLX}^m)Gjy|oj2e>rvf7qj!T
z^Ix@|um#`5=}c}>z1rnmI-ToKz4!ljZa<UzzE5UdeRTR-Q8~WvJ6BiVo4We;{n2X_
zboIIYqkZw}>f5qYd(yL+%B^1GMtQZ@dX5Qq4;V9bCf}#!=Xd$G@u%C?cC5GjH5`aA
zxdL-_<JD!}-Lo40++5Xt<-B&51CxIq<Ez@8@<Ot0uh&-CO=NPN6K>6VcKd!E!}W*C
zcfWcsx61jS&KlTt^Ok!yF^jGE3l^B)W^#|a{}LJMs0#bg-Fc^f|J$YRFU!auKj^7s
zcJzDGwa2&5L0>022_^cAA9R#_d_Mc`4TDYdUmNagH>~37Pv$P`HgB@s)H26QKbzz1
zncVmLuXObxzlFs&qS}*J{k*4zS%)nS3#vPBS?o4niP1y<w(cK(&N68}1#SJCOz!mU
zr51}0ZK;qr`I({Q%|PFEQNJu0y~whzd#TuTx5U|=C`Sh>$M=1z>pI6-S6{)qS-SdO
zW4`ELtH0^c+SBW{SZsJHb8GN1Jib?u?Uc(-VYZWCwBP}g>+##7=0=7O)}>i(pS{I&
zVxMgZx5uCKyXf&GW7D!`v0GlDFBucpB>L+rS9y2gNtk~xhy10B)XR+{<OTB3doPB)
zvpeoK{gx5>g?lo&xvxz=@d3BKc=tM7)md?B#-hld{TKD`I?;c~(aQ_hH7$bO3MOY>
zFDdeHnsMLIrOnQ#R-C<K-G^&Ok4-=Fdg#1izcgr8={dePnB4c*tlwsGg%!`co!TnN
zyxrxt-r+mfpZMGze%HsR*UJ=%vU&3;uQ9OeYeVH|ba8p|lDTuN^Iq?q5nXHXt+%DN
zOyK&>Otu}={^la<_0Wqmlly-Eq^`amlUaOw%y+mQPIX+R3Q72FM$)r>qjF7OnfMzx
zu4;1R@SM`+Fg9_8$vw+@w<NIK%%^D`t}e*$HN*0kz=N$DO#OA&8oxBf?Fkti`qR;-
zk?1c!a&A`HM<YfzKegSnt;3y1zWYx$9B$!O=~RWYm(#dg=znoyat3$4#6Ra>x2O@^
z@nEL=!ukB?l@FR5+`K#P*oe$?26HcBek7ASRi*lb*n;?pA6obOtWI<vr0UnoJUOOe
z-&EU!ji<hUyajeNnB4c*@aXDmxrQy3V?nEPW>eoc>Er%%<H4St48tl<m>w~}t^fF>
zS=r59O2?v~usf5p8nk)(yUv5lAL%o!){Cm2esXoL*R9F1PwLoD4{}mcYfQqx0Fyh_
zcjiY$nb^CBN~;f#^2xXTb^L=~E$W}SxM+x~!JCT@d%*q&lj}6=Z9$VUX14}EtUG*S
zyT`Zl)XwGyW-U%i>^pCXX(P7?v@e-l<n?N9lP9~BRt?CLuXFg7Z{b|+mlW6dyzE7m
zrQiC}9Bf^Ey6QS-UsvC+y83j@w<A3(W^T9@yvn`Dgozc)l)qHxwex}TjcjuI%q(Zt
zE5T9Pc0I<dI+L98*VZpj+Q;rZGP=Qy+gZ2Y4S9X(>HHB6+qO0Bo<GhmvWD(Hb|<m;
zUZr}Z9r3I-boJ6YBg;?H8<+n4^ny3GCJh$I>_6pCTZ?zXCMK8nx3{%^%er^(Q~x--
z^WGNEb8p3Wv7h?uxteu%#I{T~o({XOOz!*r@+SD!k?0Sf!`IEPwLNOhqKtuG3`Uom
zbfxIl>8ow>4yt7tf9tR`9_@W5_jZ2Z8k4BYy~2I;ek*mO&X|}tKKpz8cJ0yAh~_&7
z?rJ#;K8={1M^a`)`oimDtM!gg2$kQs_Nd;N7p+$G4meiIc+RJR3OxTdF}cE+@t4Cs
zH0s}Pcj=CSF;in5PG;TOT&<{4Ip?lppE{Q3@%~_P<Kk>~b=6C-$oXV!cYnG4UGIVY
z*5nkZ1_m~dzO~sT$O!j2#u#<+A&*CbxQQD0g9b_?L`VOB!jS$ShWjzd9vL3uANH@?
z{@2z2-`9-%6CMDIv-^Ahe`EuTHW_|2_Dqbyw@<&?%+?*o?^XUGA=;Cb#dhvyqQ5sV
zBvPe@JdM9s0x2w1#)68+<k6kaX$RiP=U=E0Z)lWK4jK3o6!ujkLzHbH%EIP;4MVF(
z2wNtE$w$cjDM==`N(c)G2@I5@>x_kM6vEUBd3XTHX~*8lcDJTXtc-LFU7uWcP5GVi
zilp-Q25C&*4Xg<E0V{*<ARc2}Kd?IJ0pfAb4FGF__@w3Qf<r(I@iBYz5^xyyNe5C8
z>Y=om{U|>WU4qP>Ji3^eJ+#(f5W+3NV2}zw0>o>88wujFFgs}Y6k>MH@CxSeD(3O%
zXLjfDNaUa#-X0tUI)bCY?%){E1sn%rz5ug#hO%-z{-KOq9EdV9A9ejfyaM=v;1qB$
zm;eq1@v7l{z!~6M5c=TiVLVl$-@<%)yWNMIq?tr?-5WbJq4KfIQ`ZN53GvID|7+Nm
z&8K5@_x*+_#ZA<Jr~y#}q6S0_h#C+zAZkF=fT#gc13ydyr4iFVJOAHb5k5*Dss2Nc
zfPdQ#k!nSlUrF2lrF{Rr=Kl-p3TTZ$n4i#}z<p=FzlGuV)&x+T-5e}q{5x36<u+}p
z`HHm#<p{+a`75Ax11?-OLkiUTXse3$H>Ry|6~P2*z?y2-4V28Htu2-{Xp}3BQU{^|
zO!nNXQAB^-Si6~Q=Tp2&Txb<Y`_xB)b})yi*gl=_j>fYR0(9IM``H%Q$2tkJlfDph
zoymTkKCJSq<&ojCP$|}T(E0&=!x-duh8}B=b1PV$g*a#(fFsJ`53}ynFH(SgvX`K>
z^-p1BSApVI%fpmNvUrWaK&~p&O-p?W<v8kJD1%>h{AM9e`#MZFzOryd_~<Z2lu8mV
z3zMsq@Wt4~*47_2FC<(J?+~b;0dVpFHxxlw1|sMRQT)j!`JJvx>V|Zs)eZHb^wQ)_
z>t~`7j#Gb01N^2TZ@zywZ^1HEi44)Tqx<iV+wb#JGJOwC`t3C*w#Uhoz9oJ?A^pU^
zn|_E&$~vn`WCG{unh&jBNDtb4kd1QMzRgG0_ww<_%kwYgBY-Lhw#N98KFsl(34K)i
zyZKP56_N5ksN^5jhxVS*UMJcwS^r62tu^<1fhM2m-e>nahRe8k<nt)&uPdd!yO}Op
z;@F>TzpJbN$bEeU_gj4^i0*4`f8ah!Ky%;HGl<sW(EXpLNf^VXJUu^<PreF>VItPw
zhb*&xJA07&-O$IzQ-7HgH~{Ppq7RSRD?yhRvsV%e_C$Cbh(0%dIY|AAD?psX{49Eb
z>DV6x-T<i|F$YAS8(#=|gY=A~{=_%fr+P0u4}|9g<)0oK7WmOt8*-#_Q;?n?c-$19
zC)}&B8;bC6&ohG@)guh$^K@@ZN}MO$V?v$(_PmCg^AIQNzl6Gr(-ZEAKR*xC9a(zl
z17+vo+OzZUh}YC%p>9)pbjxY$1|F&GJX|v#Wu#{%>u0SAl78rXp>8o-GOU~>&xiha
zy1wXR<&D60Ak|6S&#YfF3kv(MSwn?ND$!rMAjR=|r}=?~?@L+PR5)9Z``fsaT}|2z
z+rK@=^}KV`PLvmwMxsCc)b))AK6~2^AN<=IWu$%fo|`k*mWw$wXVBRhD=!!vgA)H+
z)>^G#ddcpU6JU3zt;Dp=r&{gfYC10ZGBUs3EVIXl$G3M3C>?wOJ}Xec#5Gx0CY=v_
zVG*PE#BSK35o7M*rV-a<P4TWh>xk{30PB{W<k3qq@;zVIe4@J_5OGb`n<trJr$0<+
zno+aC^6c^j2L=~yx(44h61v~SHCf`CEUE|H57*gkl4p6KVvh6MUOlX*tT6a+wbwqM
zW)qds21Z3+c#N&$;{*O%BInfbdK6IWsd`Vj?39r&AK52Q7@6?;__*`WTz0rF$A`j?
zUXvx8N9pcg|2)lZki=!4V~-79ts_czZgt^o*`Le5tk|&M*=J_Ao5N)?KFWUN+AVQS
z*6N)myOd3~H5jyOZZ${Cm!}&PuC~MXJ3cxk`rK*t{<u{Ztsg!+ZZ_h{h>+_Wm4U4$
zR(e^u>B7_aW%>^}?nkf5($${eU$u5i*ELVW+4qo*hx)><`Atq8>+g7Su4}1ooeGnJ
zF2C~ce0`8?P(u3i*&O%pzQ#*jyS1%ts~7K&SXc9@7H3oRUK!cby2m??)72iMxOOWr
ztwwCCBmSMr#hjbJA<d+dJlJy=$K66BRiZykmbFLK_tm79mSubXxgBzG?Uu`3_XiU<
z?udTX`1ACK;fvNq#IM?jejiM5lIZ7-RJ}~wv2o`RKeI)tbtmq<7x8Y;mh>5$w|4rR
zvrLtE68#!XZp496PY*u#n{e~ix=qb2`>bg5_F2*@`KP!I<$dDo+Yd!wh`4sE@|BE*
zC%RN=@Tu^$h0D>7uKk`&#zZY~?UuN9Yw_(L?_Wk-yCtsO`bXAoMb)L}eMCU5g*W$C
z>lU<Y{KY2O%kFgSP*vvlw;BEy<|TAJuqoCLYl=FM+_-M?<i$H*tEac^ea)fl;4Y;C
z=C#XlSQgl@g?qrx0`E$A-ZQz>ocCPanBKP8pLe;*vPTX+sR~S2O=_9C<LR)R!O^>v
z@I}ky#5G>x8ZW9>-(TZ3!hz%-2Mo(SexhU0oGyccVjAw>`#i{UN@4wdw(5`DA8$C;
z9&LSbEtt3#Ok4{lt_8y|p}2_}5H%obK-7S!0Z{{@21E^r8W1(`AEW`A3pnZ@_5TNB
z@gvm=C8nnPgoKBvLu8>LW8{&lKQ07NgsT*xa;YLpt&CDjOUVA$`vrIly#`~xoUV4|
zb@kDytG#$#?TqL;*HKq{@w(25)OF6BuJ*})wEcNq?VamtfBr|?f!Ec(`+ti)c3tiA
z|F_s}|EuQyWn!|sMF0DC(f=yD?Smzhzwg_#*VP`ouJ+xBm{Yp(8P#7Xn=Y(){o}Yf
zAAedn(c9(izC$)6UbJaGVp+x!`$-)4?{2qUSNr6D)m%bd=Z1xO(DnFncHmdBIgGBK
z57fE0A;GN8w*D<^Jr152c);Cf?afUOk8g5}U-2xepYC?x|0?_LKia<be~Z0%(GI*k
z-K*){)mKgX#N1JC&f1d8m9B9{cc0BadM=@^bL(`q@2;y|^f)ZElIW*)Zj)@3x1r*O
z?DT+Ku5fInj<pZH-&3`GLWil5bq-`={_J1n+gY^RK5l#GpDm8m+LXU>`uPSA-G`0;
zJQMF;(Qf;H_uRh~?0x<)MmDN>@BXWUmrq|Zdb;U^;C5cBoX+tRJo`s(TX6C;?%jWP
zyY0H#S^v@Y-9@|YJ&L|`9QSl>>p_88@niX@)VfjP+`oU_ZhHp1FYoEMzP_NvWJ8-l
zP5VsA>)>5u#>v<PLw(Bdxf2$iy63(6$J=e!)$gFLbKL%~*?0e|?6!;c*#F!f`)76^
zecv9tu6FPL-R-vjXnX9s+9z)_fWGhl@7QhE)js}TWw%{d+Yy26x_#fiyRQCsb+rS(
zgr)nxZwFqq@BSY&NGfJk)WCnK259_$#6LRzFH?Sh>|dplTm50gpW|$~&W5FY|GjJh
zR)F2UK_TG*if9$=-&q*CD5AmxWa<z_IN1{WzTH2qO+Om*7k$oWE<BbuJ8#LsBK^D_
zl5^7@PaQjMRh8FkQPFgrL!fKh??;dMi}sD)@9n->v~QFS<8QEM5|lQk*QEYI-lyuX
z673t!%i_3J64Hz4b6)g0PxWB>g`8j3*!CHEzfre{ppPx8M9zFVrNC-h=98<F(!FbW
z<J~FxoOk6W$9e1=;8m~Z%W?y2*)*7uxHX&Oir8F($a^;%Ek09l`|U4#*1YlfY+qr`
zus6R%dbCQOz1Pfb<s=xt6zv=Rd)YVAb#96{*Wll4uECF<6Qk>#guiO8fv$5aM4$7b
z-J+iyIZpIBzjfn+k9L#Bnb&pf_~^ls)ZyIIWEepfea<IEC3(AV)&Fp9M2v5%)oF9v
z@92Y04$<d)P1(gQwFV5?e6Un<<v8hny+`kB!JeY%bAIW@WAzU&J5_h}<&k@Sx}9;!
z_xY1(_=9Lq?S=WRD)P_9n}k2HE_z(n?fm(twyryuW$3^2FxY!yLeoW~VPl@ji9YA6
zBxSY8Uw){8N^#ht@n((_ea?$M=S83MqR)BJ=e+21Ui3MSK{jy{H6Uu>hiHJt|6MfW
z|6w8FBjMgn9_oXY{VJa*THmjV^!L#W_p2ji;eS}-Z_|;21y6r8woks7$`<FW3j8iT
zRF>iTg!o4)REj{gq^U<UNgo;ZBo3G%5at)kJl1nuIM>CH^N$YTbj$=NkCAf$wmu4#
zk6NJ!Rr!qa_vxunsR!G1@QJ}MEVQ-rU}p~5=UTV+32BEQO;%;9FyzmOD`S{hm;A_a
zfi6SbtOg^nCc>`PV`0(|6@1-!x(|TAIu`CIgu~2%B3!9ZM#&Ke$@kO9N2)`@1L=q+
ze3}rqv^ZQPXK7X|PSewUuts*G5Ed>E8iGJM{MAJ=*?L;p!Jh6zG_og(;|)|qhAM)P
zDwEa3;V-pRD=am#w@b<*JO<%Z?iyySjNu9)DHfKYP0Ot>sfU$qs1W8Hqa5Hb3zY{@
zIGumGSk}D<36mZ^e3KRm!(^9e!UJ90`fAVj6~g2(O46=ye&3RM6x7JhkJiYJl7~Z{
zWGfk>%Zi(|vlM)oNudF&Fc}I)c`y~?pbClE9KzM0{9Y5n!xd^eAY4zwud;MaS&AeZ
zrpZTOAd(Af%i?`6<bmX%!~jJ&E<UBVO(UzVD^xxTA1s8c<ZAbU&K@pq?r>&C;njbi
zCaWz~5Z*<IKhVW$Fq2CV_Jz8GoT2J4UC4!SO+69f9A7Mp`cUH9UoROxTBsAINJ~>s
zhJ;!Tc8Cn>D~D&qkWq-=O5>ldGd&QnRTjWlwi^5zYRVd^MmkUp)jRSbr@bDFh3laT
zlZA%LB86*zM>t20Ye#BlWg8&m%Q;5bSK-Rshmvo$GKTd9S%f27?on#@Ko41X5ZyDC
z4AF(atrp@BmW2kgcy^X7UuZa0`C=b?)yfE&|F#U4nsWkOoCo)V2wiVYm^MgLrZR>P
zHRX*`$(4%e;80XOmac;)94hb&3Hn-pO@wf5-DCBMuC1p2v+Dl_aV$pOG|vF8te%k1
zZNLmop1Z^E8hH$L2FrskU`4P8NaZ2Fc~wC-Py*r^!Z;Lcf_-lg%cM9T5N7(BpS)I}
z4Et7~ABb)i&L4z%U=BAmPreA{U^g%jbO3`uCvXIaJa8jH`0nFE!Cs&OL>@Tkg{K=k
z0wkTPK=|;3O&N|yo;X}P9(mz#i}J%kbo21O;202j;KqVTn;QorO>P1h0>W1yk2E<R
z|H8n@U?lhxNcCYEh`6{FAmZSX!8mXwI2Bw4P6OA0IEPyg&ID6HxbEOm!G+)ka1jWz
z{LByGCU7P8H-oFeE#Mk(9|#$4KbQs{0C#`~!JXg{a5wlfxEDMM;vDWY2wCn7cnHh@
zA<JC=kAhj?aquFT4qgIJftSHw!0RB+;ckJD;ckOC#@zw0f_Fj4aQDD$Fb9Mz_bZ5F
z+<g#X+yfAQa}PoMxLoiNm<Qs=Jp=Q>=ipoL1^59(82=G`2^NB{z)#?7@C*0`ELDo*
z-h=ueWO)M+GJFLPFIb-ZN|pwzf%x%8pdnZr#NWIrSRHHt8iNhN8ek)^CfEY31-1fB
zz&0Sx<=cXFKr7G;>;%>ayMl;=w+9=8j$jk8C)f;h2b+Waz}6ZfPTm9imY^qyxcPw~
z;^uw8cHl6uBPa!JKpBWM`5@313<2#xCD<8^0K0(XBNut%$AI0yaUk->PXHZ29z-7b
z1keeb3U&u)fzDte=mO3Kdw}ynl!adgx`IhyFEAPG4Xy-H7JfB209*^AO#FJ#3)}#r
zZ2U%W5SRuI2DgAiz+E8xO7MF?Z*U(79q<Q0=zu>A4hN5b&;@@K^aW3Xe&8uE06YiE
z!Sf(=#9sn~!7Cti!(Rm>!5g3oya}qoTi_`0E*K5|3POkcLvS>h2aW}wfzT!Y3WP5C
z-$3Y+e-Fli1>i)m5S#=Sf$`vHa0-ZrJqMlhWx(km)%%tB^_|b5zq)<;u-$unYdrGd
z&(~`j-pwNY>FRdz?gO8-$gJ<3b>-n)<ZU3y?J`@g7xQUx#85NS8|}uJlsUgBz1N^d
z>kW?0zx%F&>Jc6Wd+`90=s$|9?z-x5cheaMjxBncz2Hm#x9#lA)8@FWYnE8lZCMZ=
zoU>TEQ!DS)H#+3;TbU1?)_*X6UT4nT?EQ7~a_8J!(y3HnB=-av6gN==q6S0_`~VG<
zMjZcI`#&H=rTh<R|Ff(L?SE~1XE5Fcv@I3DNbQ{kLK|61AM|vZ6^>IIE=>qWPlY^C
z78R<d)2JP>O$bMu&p(>NsBNT8gWlgl*jG{-mT=~bL#&+_5GXWyOP+UHb6y$YG>%B;
zDeG&`LsL}K=TP!IW4zC3t0#bw&g)m4o(wHvD{8{AyoU<mXw0yn;x>>|vAkNLqI3e}
zOb03<+&@?q5{SkqYXp&QtcvA}o8M^LRWg(yAD?$pdwsA&AGN|$7UU`OLl~VCR<bOD
z3X1i1T2qcnnsN}S9KOZpP?KE6&Jx<9WekV@?wFt)mQHcrwAmKYPtwSvgsN~^cw0(J
z>#IFfUr4x{0FFrMztWrod8!snhmADxQzR5fb)uyvjDko>+B~)?&LdJ4)Czf_otw|}
z<W5}-#d^rn<U>;(sLrr_^eY)piF!cg9b9~@xO;=Ovwej;p%X(b^$(^dwp0}o6pnQ-
zWej@>$B@+#?Ar7%jw8G{pIY7c(t`urw{?uyoI^E+)JbJFL)@W4c*%6x#iO*f_sKp@
zoSMsybA@u+f0GYNSF6kR#m59)(lKowOKWbNZ{yphIR~X;SBv7(>i<2{zh`iyTwWZ{
zI88iFDROK?ss~3k@d#zLVmiC~HB4I-Sa|N&aBX!cE`#Pi!?UBidmjf^YEBpHq(GB)
z6a``<QrePlo=;S9>AH9P|2&`U{^a@e2Ip);-O|Lxd1@4ePf>2Irp^W6lN!6MU%&|r
z#(sA&1f+g|5uh755~PfWg8e|W*?A8z9P|XKzrYKO0I3WUHJl7mJ9!F7?c@aTC^!{7
z4o(BncIKvo=RkZ)vv%+dklMj$)3bK)ERfp4Xxp=Pa3V<U;5i`L%-md%+Qaj}91x${
ztUbH{e29JY1+ez;BJeTx7lZVvy##y);{Cv*P0aco&=%&BuutvUZJ;r@6O@4X+-Icz
z0!!>4)(~xe)?P)K_znm^0os5l8*d9{fStkfU{^2`v<Fc}#w#G&h}>1MJ9rI5n~?Pn
zpe@MVz&_f59QpuwH}DSF2fPpV1JTxJr1n1Ah8)Vs+PNqr?~DBp8Ww;m>{B~F3j7<0
zHWr7rKR+Hso1dQya%eB1&BT=g>HStl!?NH?>{ryV5{O%hs|@Z2tAK|<=#I4?4MA!*
zRtJ9pp-VmstgWFb_yGHLz+A8{NbSFR;NL(qun4RV>g#cw1f=$yIamp_0IPtFz-l11
z_leZrHv-#%^uBBlnu69~0}$7UZwTVr@Xf)_U`wzIXbJYvklNu^*r#@Qdyv}SwjgxR
zcLw`{T|sxy9;9};BRBx;4tjyTz=5C}NbT=FpfBhS%E100wW|k!0pMGxe<glLQHdq`
z3yjWxZue-xprOWwU80wEn_R8NnJ~xO31{ZnK4>_m$!~ZWiS1M<OWZ^ah#C+zAZp-u
z8Yqpu;s50Ne}4rV!283TfIy`*FjN+#5_$#x_t*T>nthcz0AKZPhH)lezopUl%r-Op
zUlu=8{LZ()2MufYl#)vE1s+H_N4ObhRE>1=CmWAfD!#QV8XACl_!bYBN3#NxEQJ?+
z`SOLr6`=ve;nc=>gX8x23F%Q9!bYF??KOYnG@kNi2vz}&z*=B+kn(E`()&LKKMo(S
z68+7`6SBJwKhUa%tw(ai{!VMk-~aTtwK2yx-LjgKKjZAhMD+bPA-RdI?<PGOG1jJY
zR$6B1%vz<M_k5Vt%wzu~^Q5+w;~MH$)!h~>B`t2E21E^r8W1%gYCzP0r~y#}q6S0_
zh#C+z@SmjtYUBPZ<NyAOurS4c#{7RxR)0VKPh%srRTfY@-??i8VT?Ucrcz7gF(GOk
zH^=yzs}NosEOi=$wF1&exk`<B(E)5sPdlDT;~ca#7r;nkcfB=nhso5z+PG=#PAP<I
z;zG<gkLE_Jgz#@t(vE=&<Hp^0vH9>Az$Y(@qtOo`gm-4)u5!8DAz*|T^-l=lEm?SX
zztBD*7^0(o1|i%{h=;~zVXLtkx*;&%0OJm{)fT`=<;c*CZ)^I2uv$W`=-*e?m&B+%
z*}`!QkGiS`Xu_!<g!GuC(Sd)k+<&B0F-jg87^;Yts?@SbQgv~Ds<HeC<Kf!;Ox27{
zt|38eM9R;!-^GcE8yMWyTsoGY<HGS^*(ijwRTk6-gLNR^hQn^96tli5ZYsxB;rJh}
z%MBs?57&jR+0CzU!kDB`I&FOV=B#c}KC}gA^`?VH-?ug8t4SwdBU1UA3UOlG9y)`z
zrO_ekU>8T0$4<gAl~V2xcbq7;Qm7x=v2bl?7WF03Mx;1*Yp!9aLKZ+Zj;@b3AHkXq
zFei2f=B8@S$<>^LD~6LanZPkB_XpuvppqTaWCzD6UhVZu)x?XwEVdCTFHt4S_q9&2
zOGxKy@2ecm`871>6Y2bwntZ9F6`l&{hYr(u+B$DhT<2-U$k%(JJqy>|BkpWYGshzh
zO?=!8&3%lqW=^e1yD9qND2`?z-5$8d=@gE-6RH2MB}n~)t-uOkYp@d72BdyHOAuM+
z+JflgL)kD63AO{NJkT{`caZKoXRto#0-A$8Ky>SIJwc?&xq?WO&HpF*U>|X_`TvL$
zeY_ZN2BlypPzKU`7C#Vau=M~)gU!b$jzc)&=Ej44zzLuS7z=uWJpK&?<3M^&#e+k^
zDc~?L0Yuzv96u18hW!wb#_>mjKY<Ex1{ev>0!M+f!O>tMh&-_Id!)(6?<a%v5RSO1
z>yyp%Pt|Y(h`881{yE?#>@Ng2gNwl};1X~fm;`PISAa(}{25$}{iEP|@EC|V**N`1
zFdh4dla0p{uV8;Gcop0UUITZ7H^BX1Hh2)c2_g+PfB!g$xd?2YKaJ0y!Twz^6TAmr
z0CT`B@IH7Md<Y^fHeVlUv3dB!R|rR1Y#u(%b9jS&#KHXr;#}@6m<PTCpMYgBZcL={
z`R8Cc@Fi#f;vB9#_#UhPVyvHy-+uyW++Gj$pT_M=gEU@`bJ)CnjP0{=dmLl)^^L%q
zIBpEme0}`be0_}Fv+;b4*>g0WkFj|+j*l^UHjdu}q;dR~AdTa<0wo~E>e)Cx#^~96
z{`Q~+!ZAkA=JV71iDuaE1U3gTR?o)u?LkZIJA!S&?w}P&^Cf7!A7l1xyr1Sv(0D(6
z1JHOs#^l-jeoqi_^B9X~^ZUI)ng@Wfcs9S^AH*CDHs8M+I1>9vlMe$OKm~}j+5CSe
zP=$TufgcSzgX2Kth0Uj+c?1)&k36w?6*P~4=2akX#r^#D3!o4EK@06V+VtON-S<T5
z^D%~RZfu?J-LP!;=_fbM^OBfN_Hg;}<NUb%;wEZ9)PSe~Q3L;_8Yqo&_0o+0>$vpZ
zN8vXjFj6iost=-d+5U3P3IJiOpPDaai}j_u4S>l1c^d%5*%f*Lgf@LYp*<#b!ldYs
z@F=-6wGDe>-hXIFco53rsA-qoz<ZfC)^^fxZdZJ3XwGMiSI=k#Rxp1X1=_R1d;xQu
zr;?3gZF`z4Pzn1KhDp~_SwH}N3NzViU^IS8S)>fh&{>#C$uKKwZ&ftR!CZqx<N<50
zrD_G*eYh5Cn~tpAqs{kXJ)DTGGk$bki1TqykCORD6Z?N6-+wQU)Lx7e^6-Z?G_~9C
zO-tXoTK#eZ@HcIB@WXd8+o;_|WoieO2it?BQ){p)*a0*GJAySp8<4J_D_9Tg4@yA9
z%{K%+!N#B$*bE#9wgd-(ZNR}GRL|O3NQ1Sr5GQMAbpnUuxGg9J?Lc499+ZJ-)3NrJ
z3mAxfHxTuU&6^Gekry_f8sF}0eh0sRzWbh!&`+3r_P00pk9oga(CBi%gRbWLcAc22
za@}=$;LCDrGQ{sbs7u^L4Tu^LH6Ut0)PSe~Q3Ij|L=A`<&_M&#{`dPQ=l|2%c%c^{
zCQSXiUICb8YilW0%V6G5vkHK015#tC9A>f$HUR}1d}ABXU8xQU3mJokx5P;irVJtb
zfHaT)5*lmTcF}RxE^5@c(w7Q#Y9Bja-_84Z+UF0C(*27HC)uu>>vZ?({Oc#t7!&8c
z>reqi5m5u821E^r8W1%gYCzP0r~y#}q6S0_h#L4mp#f_D5B=fo|G>!bfUh<I|J8QC
zb`G;iiSc&><hwe4lMOLfl#L;ml2WR4(P-^H9slEIz{YN?XvX3lAP|Eejm;Ne9G&(t
z$(vdA(~dv)M3@l2Fz%1t;xTmk8)MOIp05O~i2Vj&We{WfY<_Q3kn)MK<l^~!Wf#)8
zZeU=eIc+u%i+!<j<LZwFk9y4gE#~Oyx~Hdvmw7q6sMRaE*na`FiJPbaQ3Ij|L=A`<
z5H%obK-7S!0Z{{@21E_~APxM>?f-9w{sWc59CVHGKN|Nh<@<Hq-#|0|ugkc<5$yO$
zrK9|%GPOD~#4k!MS79x$g<-HfR4I=v8A@$(3qzSY6mtvc9C$9IrQ~Y4G)xvQ3zCP)
z$^V$vE?@=741$SzMYIZb&n*mH6j-7SKWK_@LB_$+mHT@#LcWAFA_cd4h^O4|u87w5
zpo?bhKtIhKe45WreG|{|%fcM|ZJNFdO_nJ-TU%AIA_}$xBPn0fC?!QqeHyeT;E$Vx
z`JvL<BV1t&+uSNC%<>D4-KcM)5>BG<P?ew550(r_mg1r?Aq@%@))OFzg$K)2n7<Jc
zN++lg))?n}MjweLetC?{UmZFcb`RjgPX+DLR1b);bqCu18m;~Q5QNhleG)i@1hN{@
z`u9?_2H#%+p90^rwWwV?5ry-aVM&nsaLCRgg(05brF%mkf!IFchyE9`b<Hh;u2(kH
zq{|jbv}Nfg;@F>TaqSRTfwN_4)I{t?oFTLKNP05X<f10RNVh_mLdgn)eUc^pQh$;$
zt;_&P)}%O0+sh=#N)S%vFopw6fSo@MWutg&a_Z4aD6S@_Z<v8PbOmK=f$+PmEP^Z#
z*`p|5P4r&*;~4c_(NB9Fis&ZCM(cG+AGE&rIO)Tpq&}?v_w>Qmvy{{abc96}q$3IP
zCg|<=I--2*q9d}MP=NAwf&5)ozQ3;{E3PVf5IOE>8TwyHo9Zf^e-S#W)<V!x5Z31e
zhRedJ4*w(dRa+~x^_8wE-4Crf1H;RRUs@cot*ulVYGrHNIVzme31~$ZzLk{zR&|AL
zDj8mb{Am~!f!|9OifGt%*4jl-Y92xH(18Jt#eo?(hi@#D0q!0GLdhfsDhZXLA4TxT
zjrEcK**&LymN-DablX!$DV2-rI$ay8y(IHiQ+L_DDpj(&n-2YkB7f^q2kSSb{0OqI
zG_tZ#IN(4S)$;&cfMCcDg^+6r*~c1L*jr`xEhw!UnlJ?5=`F;Wg)pi^+8RW0CL+!N
z#EEtA+(J#9v^J>_vX+o7`N*Yss9dzRimn$PrqEYKL+moyP_hXV5E2xkCettQ!2%hI
zi=K}Z*SF73?fs~w*1iV2NRX%J0$nd-{1Q+bw`rb_n(Gz8oK)Z#T{DvVlkHFYwYArV
zbTJw~($}B$b8G8Qh9+`a_e8ft6Z}r2{@6Dc>QAIBM5U=dEH60xXWQ@UPdd&=T|tc#
zbV|?5D5^iGER-LrJEUXnbDhFS4-}@ocPNZKJLx<;D)9JV=hg*F)<x2<R<}LL=mxeJ
z6oiUJJcYdYYVPOavfy?gInr%Q`s0tAMz@vNbK<n6w(gcO>>&JY;nufZM>>sszDT}?
zVd<F=R^e-ywKnW+8x{|p+g=D0)(8Gbed+&+zF3&%#vr{)kT~f&L`BwIgl_|SuVVZH
zE|&eJ+IJe&C8|4gpQ~`6SK&Gt_7lp$DQo=xIb=)&A=paRqqER`wQuWDprCg_`VasA
zkJTglKhX;d)98ijQCH1(TcV~c+O?B5$YvTUsJ-Ty3X{?F9TTp==#wH0pPTAn`W#{P
z3CaA~#>%DrUL)OWPGT>5N?UtBhSJS~Eg3(m!^`l?r29#u$Ef1eg!Cjh{wLe-^hoIm
zUlhVU#O_CgmAu#Jo}_1n=2m0(8oU35Fk1e|!X%*ZoK=sKg$nm~Q-o>X1=?rmCEPjm
z(xI}w!Ew6bgzsKqeWwAwYbYOxf^G47!kF4rkm8#L(sT7EkZ!d3U>LX%Tna7%_kvjG
z%6zOY0gqyTIrtPz0-u8`KuUibe!@4X@Gh=aUKmSUi*VWs^@TO1pTR2F{{o_l!-=V|
zcC-{&AG>;BV-WWg%V%kj@>vF?e3k`iO=vlg^ke|`1j~cHzzU!TSP>ioRsy|2L(mVb
z4$`~D7^HkF@e{sbg>PHRH&xF7{Al}(S3T*g6l{msgJiSC6(nCPAt2da84Hq)l|)bi
zo&XzwC&7l`6|gb*7=&FGmM)LKg>OaS8<NtcF;1#Ww83r)OP73@*kd2|QCPYGpcnS#
zAeAc!r1W7gh56!zy%gqSHypf%aM(>@Hf_i^Xdd>}U?CU<Qu+JgCwz|y^^Wp^S31`n
zKiUrBI^i|X{R*0a_rX@+1CXx6L(mS)1?l_l5lHcpKNsN}33iO|%|!7!A>0Dtv{8LB
z0Fyy_39JGefGHq-i>HF^!3`j#vk7zscYp)HouCi63zUI-z|r6#a1wYJJO%y?Qhttt
zAHd@vt_gPnBwINr!T#VWkZjeUeZ|LuXcsV_vFE{=*uMa-18;z7;7xEBcndrTJ_0X*
zPr)bPGw>bw0{jf-gB4Krm!Ki|3akmf0d2qn&<Xqq_5}+;53mRv2z~}ffM38Ekb|CM
z!O~y?SO&zs%#{UagXO?EV0mx>SQ*4U%T)o_fmOlnpdq*)Gy)HT#^5oq26zTE0ZZZf
z)dLY1X9m^*8-NW#bFdL;0k#C2fL35rurt^KbOzglUZ5=~1?|9Kuq#O4)ZIY3PV_Di
zzSV?pII1`F%x{SwZP}<+RBv)XsyFvRWAFjU>K*<TzO96JC7qAxISc$~8x8&8vxOT2
z(zn=Hkj_InHQzD9cMYBAi||TxGPc#YUnt!*AgzJl2-XHSfek^_33gxX0j;sW7o_*w
zKCm}<0Hk`0y25OFp~=CXA4k9lg#QfEGyEu+03HWtgC{^tZQ#<ub>Jy*Gx!U*3p@>;
z0O8+>)$fa73)HtupcK3e&IPZ4h>N=go&)cKIL6%r?}NXBPeJ_6e*_<brEvXo!D?V0
zXaYV4n}Cqz+knqN^2PKLgig8FAl1h=Al@<DTM+j;hkJov27Ul>FLMRpX7F#|0T3@T
z{w}Bo;@;u(LEJlB8SoQW7DV0W@LuClcRBc<;#+~p8{ZDZJ;ghMMqq!iI_Lw|07rtj
z*Z47DEs&l^C<~te)&>`XreG>q2iytP1CN7dAoUN_2k(JRK|J%g=HPp<16Udrv?GXj
z3}*w@2Rnf+L0ixkv;%v9@L$Dyf?Yrv2;K3aU^j3y=nT#Wdw^uquP3+>>;)bHdxJ;8
zKHwD)&kFt;*bmGFy+M6c@L^zWa5z{8^ab03GO!)!4?2Nipeq;-dV&gYAgBaoU?ix$
zuY_;SKfkXgLJs2GB#`c_$(r+e;&0)*POy<d_Z7WQ=-!}hDeimPUj|CRB#@r}D?obB
ztODtouok3zEXGgxRujJAD86b4n}Hu~0g$8n6xW>Dq=3IkW|JZeY>03LNH!;wAicLD
zz#gCq91KQ*!Qd#6-o-H>y;nwq^q%EGN(;{{W&>{`xD5NKQ*18MX}lz@Oz<6`zd2~9
zsok8+pJ!KHzwOv~&u&wnyc?6Aa=!A3-b)T#$bEsE+mFdj<|iB9d=ocHY9>t>dpRvy
z?~2K!naQiwWz0^lk69Lf7;~kVTy#&bC3f2@&tH6D=F;U`S{X+cHl5Ouzh)f&_~tJ|
zTaE~T-909kuV`m-?po5e)fEe0_`WJvIegi6=PJ%eejR-vCGk-`YdmaTGr6BWnZ{&T
z?z!A~>Vx;D_tOG`Gjn`Z9{DrNk6hQ$yN`WcT*LlUjw{|LIySG6cGf>PJEPvB!-<mv
zYWbC$*JbAGUiUX%v8jkoy=_cxepNkpdE%i-r}{MV3QDf!$bIGm6*ej3ZZsQ`yi2(P
zFKa72FeUoaPhH=5;Ip^w@WH>WQAXNl@3}d1ZMm33a|WHAvGRh!G1TD^Om2L{-kknt
zPPWcmcr0&r-jahw`guDf=cYZLI(FQuDzDc<E``ax>TH+RHpJU_z)1^(Cv{&w^Vk!A
z<$P(qJzokPGLsgzKqb1#<YsO8aIkj#yUC9&J^fvs+823kyc)JRcZJHON$2Nj1*R~x
zSjm*~=T}$HBQ>>cob}xF4Z}@rTaU>dUU+!y^cz#Qj-MJ))CV6-E=;bznazbUoAMnG
zzR^FDUvc@}PUcQrK=;F!Ui26kX6@-%0DFiI6yHXJ13i`YWedjKPOEBns(d}4xmCtG
zb|2+^@NuiGjqwTP@Xf;FE2!psX+phazJVF9TtBv~_)#xA_C_DSBSqu%&6E6d51)V?
zLMB(qz@^)vp$$`~v>p_)qK)Mp<MUm1tu3$ruxLZ4=7Z+9+5*3Pbtv8M%e`dz>tnZm
z$)WPQ7g$XDQlT*Vc!Y7efVP?A1}ymLP?=rQh~^%+Cs}+yb)0+Juf~TCPM;0?q+W?#
zbusGs^-JAbn{h3Enm74+r*8OWVsd``fc~zh>Wmn;{dM^x9qL<LX`iw_<JdGa!>r~b
zyYLSYUs=>GiT;Ju2Yz7(41<>}x>0n^dsyMyLoa9MBwc^_IBrx@&x`WacqTGA|5FW9
zo4nThxqqpptKRSJzWK_e^MNlcV)UNa4LdYq%snH#QyeM2sy`<TXj#TCFvNcS0N*z~
zXM2y_@u-x4Ypa#7Q&+~^_;eocNEY9oEk*%@?)CiAZpNqt*=wu3$O7wyd9_PzyV5*#
zzwt6JH+*w3Ipt=<#+;p}y7Rt^NtTah?zvsm``*tD^^L7NY!7^Np#D5OE0|nFK&^#0
z_gCu{v}^puCfUpGbnH-7=J&T5{ukyYbUm;s)(`e=>QVlTugFv1>%HmZ=IQl5)@aed
zA`kDzo0nTIx%@uc>1<&?)PsFY?t+87=%~|7uhyZhCY4^XyP_%o_S}TAr<J#+H+!<^
z`G#kB*5er?(YO2UoaZE`9@7uo<uw_W^Vn_AuQKPgmR|Ea4{m#Z=f)9J;186^IhR|P
zlm50|?bOOOoF;WMO-gJs_Qa^}b(+LXK3LlBe(!bowqSDmgVM(In$$nY`&9i^Q@m@>
zI$}F0z`A88dGwNue9zZ4pWr(T4K#_q`JS@d)|U5M(4@uLM@811-D@OQx_73c)O2Y?
zi#A{S?M6MYWpb@sH|g*F*~P;8ow>w3ckAuR>#COTmazH$_<dW?K9#gY<5J1w;tW1_
zE5F3IlzWGZJ8n7-oiy>ujZSylM?Wk3I<D!`vhk<!E?{yw-0{5pX7g&ltRL)rN|yQ2
zJ<j;%<Etx=v}~RnDtqFT1;0~FZpJa==S#ewO&{i7wQpcEt0`;Z1C<5I@l%(#iCa>j
zpSc|6kWe{ZG)>(ge>=ReR{Lgm_N|#@mveAN?bI<ly(Xr#?Hadz9^z}o<O<cJ6U*0~
z5#IO4t_!=WT<p8~a#W8R9m+YcNV@x>ZorE#xV}s-|LT5K;dX~t7jJhv^yW!s*y#@w
znr75&uspkb!GXa=o6s0bW^#k)4yk-(Ls(+1k=G6d&39Yyal)*i^|c<X$S#b@_+<UC
zGVGZ$xduk{_MWjR`)=%I$12?Vc}@M>*j4#t9X7jS^ClMYx2C7yK59Vam@vn-oqhhi
zc0*EDTsWDkI^CggS$vXLqYvYI-dJ&Ib)i4LMVMS}f!>>@YaedCxx-+7pC_Gr+va9@
zJgcA5YPRpqat%+uxPf;)le>FAwu#aHyp}1`?R&OY4bZ<h@>YY>8*T5TrQAAe9_ZYR
z<JK{`w1N{};cD9_t}h1WZ*?5JW8#HWtIPX4SO#q$vS!fsi%Ze3!sPNgtc@s|Q1JP9
z=Iyx+GxCS-`Y`l!b(fHxTYD7_&z%_NfcuTf^?g`#$ECi`7fxRG$=%tr-Jag<KP~OF
zU|isJuk!CN@B0{uwuL#B_i5e}!}~+@@=f1QP94&=(Yl^hLTxSc3zJ*9mTzXbeQGrP
zeKNWDjOs6xO&3<Y{&C!#k3TJ(=<V`$-yxe3FWNL8u`J_={Ur2dFu8Ik4XtlJKJ1t1
z$?f`Z(JA=Z<=u6%ybf6RPLK91+L$#2-`GrU`h}cd*4XwLdcRS(h@g)xszlCwI;FsB
zTIQ3hlhVCwd84QN9g};XHFq*U(L5<gQs^?+c7gYhpVV*7d%3S|H}I1>zVTIj+%(6B
zh(y2p;X1ob@+=Qj%yE9(tB3WJ6$T%!_S)yuY@#ySz^Ld8k8unpcQtZO4X;N5wVtZ?
zl*>*T`SOu{@`RBIuaA#A|IB5F>vA-H<}<lpM(kVXZ)(+b+xDdV-Zw9v{4i{L=T>i*
zn$L+2{CvZ^8}yvP<ob`laj2uwwM9$MW<1-MxpkLaOYd40{?_GAmzj;s#-<0^qp!n)
z@^@^=kZ1nQx4jwP;+$Qu>U>kx;j4j(A@)i0!avTtz5N(Ivh0{#O0sfI%Y@`#22Bpd
z81LjbkDUX&>h*kCZeT5&1~U@3X2aGS8ZZ+5){Z;mo8SJtA-+j|Z>L{kE-dcXwZ|Z@
zfWb~T^Xsnamyv)r6N_)+;f$EWn`(4z?vT>l##d6O-Nro+!z2;&&%T=1`0dzc_-?w*
z<e~!d-w*p@@Uptpa)5E((v|0?P9MF28}Av_(DBUp;VV(zs*Nb!wzng`q$EXk9cR6%
z&HCdb7Wu{YKQqDg&c!oa#eN6YZ$~-0GP%(s%^UNJ63b1SyuY?*tGF3?4vCixD;g%x
zJDzf4YKvjH_@-oXkAG@X)A-)5v-|~R)R-@h-VS4%#n(uReA9bD@B7nsNZ+Dghsn9P
z^>lU|m}43+EBe9ZchP6o9p(lc8&mUO<Yn{8%X+C4Xv;D=gTu?4`8@e@^Q?)N(dwNh
zyOd3~H5jyOZZ${Cm!}&PuC_y)yfKx7JFVUyx5}dR!)M3MMm!l2a($yRu+_v$FAFza
zcpAS<{~_$IF*%d79;IsznltH8hvgM!c?~hX<r5WM&U@aFTHQ_^avtL43wzQ`?%-C}
z4DU&{P2&6YJ$6UN>#e?j;MdcmUz*<OKQX=SitVvzt1`LdL)Y?W24=qGV_w(XlfEiy
z)Vkv-`fJC&f1F$<Xwgu9I@*Lx?oG~|$#uJaZetRgr@!)@U&bTPvlAc9Xy0M+w(wK2
z%T{(m8>$JFV@Jhf4I>Q8Pp_gJKkr}|H_dR$*zAtWYey$OXn3RJXeHhYy4o0+#NxB`
ztg>_1#?im5JGZ#Ze9L=1t4!JLx_7Z&kESzISM#QK@J`*%<c8(kOgzi`G~3s>L)Nj%
z%_me#ioKZ9cu3s2J(~^pWj;X}o-w&?9;M&M^{F>@TuQTD^&IAAJ&ZPg?RRwhW%G~o
ze_q&ct3TR=O{pBqeGgqpnEdid=CiCp@^r7JcUNCE?GtlHxjAb~E?2t78Qp#V#j@|Z
zj%8$x19xvYHs7It?DgSmV?#bB*LoUUYkAwSx)w7cL(qvZnWZ~;O8bPPDTZe&{AP5a
z@ZpzJ>(>XBZRoRq)$n=Q*A~7}cE)vMax+I&m%c4!f9hJV@)uRVHc`CXKcdzCa&|*^
zC>mAj(eC3Cv<cbwnz4MR%?xvoUeU{I-@aZx|BGSByi2BB@S{#m4dd?YNWr)LTNdB(
z+&MwH;p106y7}Ix_kt-g_goxSY|36$C8688HM8UD<N4eG?*@r}{oQM)1f<uVGe2V7
zoYnDF7OKzMnojC+Q(^sf!<Rrys|o1aWO8?Q6|CKrva_=L>mi*S-pw8D8#-!F_TXo3
zmd}5=y|P|%IXtf%DZV3*zogzi6%pR>H>u-@h^ekIryD#fduClF%Y+dNvd5LGh_)g7
z4x6_-`(~4rvWr*0R9(Kj`cizv?(P#R9b0?L-0o(Z${!W&(Pm@mrgm<VY?Qa5;)d+>
zfLyL{Y^9F1553=0wR}Q{sgZRKWTGClVc%h&@ARyg-Yj+KL8E4V#|ED}x#M-M6GzYb
z&D=51ZT;-lzaE1fbQa$^)9Lax4hs`4EiUZa*0$A)_eZR&`BaOuDSEGr>}lQO9mXG7
zd{tIiOI}D~_TK99A}wQT^GEfr*1C0h>!dofM*Z#ov3Di#F<syP5lQSqsZh(%*oj1h
z*ebEa7Q{}4WHOl~!(?X6OcrVxyV|u>Y!ymvK`d2jFIugovDVg#eQ9W@wS@oo-1lY)
z5$_jo;`jOe=X^3bZ|=ME?mg!&@1Aq+IrrM(Zw`7vSHqrHY1PszwYB#X*A6WpFZ#1v
z&0kk-&^MXiXW^>CrHXx2J{{}b+w6G-Z>;#MNYRlyf4}zc;`z!))gP{?wq;Uq?Y#-V
zM)|a^xit~%oZ7^{(B8Ty1$DlE$L<+gXpH|~_4iz>yC+P3dd$oCRrMP+7>;}mSiaSo
z^0G2N?r)h9^YYw`5593;UU2q|Uy{EV{X@0E)kfE9y%_zTtrM>&O+NYaz^B?%|2}`|
z<KKS&VR?ypC7SFV=(?xrz0P4n=7L`Kyjp>?`j#3NyME&F;?bGS58ixM%Fs6L)~fg~
zR?4d#_@T#-(52vAD05OCPF1~V=v!_@x=Z5W^`B~;Cf!@_US!UKF+*n7No<~ie%goS
z+qvBJSXWQ~{4E*=ZEJn#?Bx3~H<yiSRw6W6)mc_;Ncnq+tIzVyFkbHYdD!f4CUsH8
zW_oPu;1}4<U-@7}^~j4oj@)j$^)}>2maj<QdgavHX@^fe>M=bsxy-0~yA(}a6AsN@
zmF(U`8QpU;bY(2x0D0;bLzj%Pb-i5Lb2n2zYFX;|B9DU`cDim#zw&+UFVSuV>Jl9l
zZyl-p&xWf<R}EK&jz|tGt2%abM1?Omb-NeSvRir?)lIwyS-t|!z8mI;RqqmdeQxF9
z8=CL-*j0AT-PMziRJq!9z=#*qu!b<Oe5-ydxNDs2lCRtXJWj2>>@{81rQL~Yb&k|N
zUaUlw#^YLqBmO?icdL8AuTkOSU;KD%&5$Rzch6pb@o?;vt|t%F{8QC`Oy7Q6preHh
zEOSc8>_22#(&2>_N)8-+f6SJql{PJJ-`IUgyLmsxG+kf+KGvN<EMJEWH4``2`K`yb
zC(mN9pD#b4<+EXnn{)}j=+iB2Oy`bMFeZ<%eBU27I#2PNGQFhhrkR0%cD*uY^~U&&
z>Mtf=)y!Q!Wc-rV(A9ZTxz`38{!ZSwdQ-pfN^@6M81wzbArJek+dp;f`X(>Z78qt8
zfPRSO8}vim?d|E|BhQ^*zNVH}=dbHO_-oM;W#;Hrg+j(x_NRRd!&$yFkH6*)oUOmq
zH~Ppg5tCNjbNy~inYvpBcqK<x&sVNu&FioQuzU+2-@5e6cOk=lD@}a)Y2uaeEicb^
ztKd^;&B6zR!&A;31s&-uUxm%7!>UZ*-+ZX=X73I1z~?1e)H>Ph*cbO|^>eNmzJFRD
zytkk*k~z)G9Q`yfAo!t5v2XkO)pMRU8#}yeg;tHPUzxXZAa{E)-f#U_zP;{!Q>$|m
zu6<h}V^2L_pTE*$y8QG(bN8=COqu#(jQ4|?7#}R()dYE5?M~g6MlYN^Z|LOmBcpwK
z8Pb}MAK9~;K4s2<gP05UvV1o}LN0pv>;5?U!@)0#ojm;2z81x+WIj9S5xA#uhu~Y|
zCPJ6W@-5Kp9QFOC`ZsP5Zhk{My!xHlkz*=&$e#_-4g2x(Y_)3$bZp*4$5ZW+me1o>
ztlS*atBTXw!dqLdzjMN=#nwc_C-(=;_IlD7^8xy_%qi{Z*P*S;wNh03V|T}xE+5yL
zerG{Jm%lsQQO{YsDE&sUG0+{de2p>-{LpyyZ~j4BJzsA7W<ta7^3T({&d*n6-R*9(
z9zO7RhWVN0yEX2z%jnD&H=1ASn6fB#QU9*%ogSYaln_>LY4R5hH+IIl=>p4_xTW@i
zXRT&^RiRw^!@V1?2W)Qqw1BMVz2%ynnZ^DZlD-5wPBy=|99q*f_yd>Bvt<WyD?jPK
z&2!oB6Pjm6DtZ}xYy39v&QH(<GkUi_Y1-uY8J|{_Up{-1w$W5|xtsj9{Beip!B2)o
z-kiFk1@sIo-&Eg4^<IA7xu^D%qsL#&R$N>*rqj!x4*p!}$c(!go+H;)fqc%&T~cIs
zVAQ77=llu}HeDRwa`Da!&3~HpYahP_&7%6<D|Zb>%{wgLic4I0YuU=QQhw;;Qw~)f
zy|+g56-WDTI6n93#LQholOT7qa_3eo=Nj1LP@@kzZFY@2RDbmF9*0r~7^id(oYALT
zgYAbq;9Li+$z@I<kJB1=Xi#>+*K-5@-1xQA#FM8sb#?opPOX;pcShe>zP~5*AnbX8
z+j{#xzGuvgY2rOtzc{e?_xV$H7G2YcE0=k&P_Xyj&tRKtK+hX)EOjxs{+8QKihlL`
zFHfA8E-e|hV9wUe%|>Vc$Dg0we-!HjmhbFesfrAb7RRcl`^@}Mer#RY9{tvC&$qbP
z=+JHXuRkh_b>}pe?^)Aze>dnffIC`v(515ZFYMd<r}E#zZojVH>@#@oiM0=)FWJHJ
z`MsR7ZP)OB7Y&uy-PrE=%f`cRFZ1jZnL7S6Q|!tLv56Nz2g|qbVfT#taopN@<xg(i
zw5V!<E&V$_&nV?vAmfvSGJzQxZjjHRdz3jf{k6IG;(TjMFW=kc&a{8l7hM-Sy~~5=
zi+_tdUDmUF@qb6amci!9FSd94;)3tg3d2(uIkj&h-{0PASLWQ+dq(d4cIcU<&sHsm
z&YV4O;$B7J-6Qtj8Jci^|M}zx?vHjn4cZoXIsTA7IKIe9OdH(iZ2s%+AFo*PxX0-a
zm9mzPV}C2RxL)vvA1bwZdNinM<H6@feg~TodtT}gw;PWW=ihyN_xBN@eY<{gy~O>a
zeRq^^+*wzqy!+;FBVbcx`Nq1tM#eu|8h3T}oqh9H@2$LZ!A}*Io*2Ak%7w$n!_sfX
z!{&iCjLd0vy&|T+M!0Kk`98nt5_IIq?WP?zEjaA-uzSJp_l>MMcPQk2mamc_sABbM
zH_9#RIZV?vV%Vf<rp|R=JiOa<{6X(>ttu|O2U{@9_oS+^`cmhI7aI&ruWD$M^reqi
z@5Q@^g&DqEaYvT&eXsS<!LxkLC!U}F*M-X;mHc)`p*E*3UMqfN%C7~Rwd}9#S)<aZ
zB0r<wUtsxew)t7FZe@sh+@|d&MYjw2E-yHIcSN7tvKjG@$}jtI!z_$TU!o)NN@Lm6
z^cjDiDY$0#y^>pf1{7JESv7F^+BHqr)J^N<bQbRgmhbI)+s{}&+1Eoew{I#m#8|xF
z#&h-56D|)gz9_ZM-Gw`<7_>V*s;|ZSlI0uZb}J*e|K~BjF^Mrz6~0_BDkV%->Z-!K
z>*L+2?zJaChjfnRJ9uHf$J`z33eOz(S4r9Z-eJpQf1WdRu2+Sw`9|#znmMB<=x9WA
zL?0hFja%nav;Icqq!Obe?|*k8?8va{=anA8%Qts!bGIaHIxOGtmdeG6o9-DWdv`h=
z;L^86zKAb<(gGGleq5((#HJ_xi{kyp@~upJ#8pV>)b#9&%|Y_BgZmyZMD90?t-EsL
z?Ez_h<2UPYz7)&n)N9yFr_+_!>{xbi`8tnPf6IfaJk^Zv7}a#biPkYq$8Ld5l;vyp
z&)nLjN?uu>++f3ub>+u&PMLUN#DVZ*-ESRUv!K?fbs4aYVa}I1EiYF5;cvHM6deQZ
z&Yx>sSbB)^iBf&>&VYx_ehiv?z7)n=dzSBud+wR0i1RP|cidT`t@fv>bM?CwbGv;q
zM$vE2iLaK|d=9-R%U8AHBK^+f(p}W^YaLlxWX8tjk5BK}J9*c=Prn@SbCp^})3FX?
z`A#)@)}r6uyH#ctE$zCee^QU+=GT31OrCkUd7)GBeIGtcMZaSCo)tL~^wWCT(F-ju
z<lp(n@3%t!9QbEQNXNfd$aJ-9$MzZqJCGmIQSI2m#q++H<$L4arm68|6VE@$w{9dC
zJZ*8)J`K;!_5BunY0L7xUEgkC`JRtmHR6vYtFDY4R``bxDp!kj8<u{j?jM&+C2xE3
zboufom`@k8d|Rq+4BEM})e?hh;y+Ut{S_Q{t$c>NqF}2fHFoWsRlrpP8!XHBSL(xg
zk*?EjCpS7Z=WfTTUOz`}_pCDM(&lf%leHH{9>)BlW%KxBm+vl4IJWbC-51j)To^i~
zTF9lHHOiej9y+5#nK`bX*7*^(eXKbkhweHw-R1hAp|yY7(9=8MkLzLE4tzY&BdF+4
zg?~Mf%$<k4+M4An_{Yof>85*i%0xHbezfaXvrR9OuGB7g?$6<S2OT|B@QY)xNe0mK
zCJtNnb>*s~JD*Z?Nf_YO-R;EB$%RW9Z}zHt_0hyt<@X<gO^iM7r{W)s9Q9=Un8%*M
zFN`z0_Avz4tGYPh<1Q<kZm&M+(am+(m&)?hnAv4!AwT27Qp=9r2v~nAqTJ*@OWS$u
z{o{oCgjZFMi;%Z2vV1QW+?{^y`_-dwKb~J{P4O>xdd20tIii_qMN5ywE(_;Wki(YS
zl<GI9-l0m99@XgF_4exR?VFU0DK>KQkRCzZMl70swsv5FQJBZuuzU^rteyO@dEY|2
zIu9s&r$pwI4s9#8tg$!KI4bi>+KQEB#=@4z^8M6h+EcCbs6TfUFz$>Cx!d&8h$|iI
zRQ~1I+<t~C_m5p|2YVFb%gu-Z*M8jBIBHglK2ZrDZ~Hzy%4@>2%3GTnpKiFhYH!0Y
zu?K)XugUZWPihRSbiVJ^3IoUZ+`MqZ*tY5q(-RlX?DFNj^3{TdKwrZ0>3??%8aFPm
zfT70?<??__raEoieqPaG{Ef47y$U=CtDg*7n-RTb;xacE-&pP9!-k)quYbxj;OFfg
z_pVpDx+<jZsE+y%XD@^;nB}`wam3xuRev2f-P>*1fzSq*W=%V&Z1-jB&j+Q?-_ql5
zH;mt@EZ@DLn1z$B8=nWs-I_NzpzHa4sg21iX5FnFesf?zXp<F?@%FNOEh~?_`|okx
z7ZW=ioL^fu`|!ShCe_+-X7AibM~!1|AFmmNJuNJscG{}*(M!6v8#$(kbD`rO-D~^9
zh-!Xmou|20>Nv4gsQ0&!8=Dgyx=WsaAMhWwY1hyyXD*~(c-ZgW@!PWp1*D|ZY;$*b
zGkqD%FDzeM*WDeG3N$X7RyOMJ;uFuuAH7n4=#fb?Q`D!{Omp7WrXXz0EMLaT?#a7)
zx_!EI{zrogjm<xNfBL~W_nW#`nIrely!-hwyo=Vbd^i4mQ1+kHix)Gyjc#_NzeoDD
z^W$6iPr7vI!wMTm)!kouGWIsGd~df~xnr#;a~e3yRN-#f4YA+MJ>2_c!J)2WPd-0?
z@KpU9+l}(W|2CRG9{MYm@4@WIZ`@-~bkv08|0my>kA@}O582l4pVQZG52?MW_vX6O
zVV`07x-U99WdB#cf9BR{{6w|#%<1bDhux|7b*G5E`AW~q?5#z+tzr3|C5$)`^SD~K
z;O`1Fj!c*|D&Ros`L%A(tGTxQ<g?qY3YqZUV)=%T_S^hP{)rxGnWdXuUg-a4|K7ph
zq&+e8j;tMjeyw{{Da;$65FMS0HQVcVd(E_8{_x+uq0qw@%MKm?b^RBon+829JpID6
z;^?CeaB#rE0S5;h9B^>J!2t&c92{_Pz`=pHbD#jS^nRE4f3N!g#~M{?8{dB}%<B8^
z{2%!Kn`8c)eVE<y@w7nQ$~oiXh0jdrtAf3G-$b09#|}LwKR!O^YyX)a6!|1UEaM<1
zGe0D=kE9Xb$*Gill+0yfA36j0$8hwUiolamrhfyz%m}3dM-)J2M46@etgrshwoHrP
zBbbk933vkZrKlJA-I?n_-_!A(>WLTz%rCYy%E#V$wy$_Hs{{W#v%f9*sZ#xIX~3Rr
z26ge@1)rMu90m<;0uAJTOjRHns4rv#+0tOHFCJy#o7r#ej8G;_3yg12o3OT$32j9_
zbKwHrR4(y08_2d?3-9m)^D`*T>etHqqS^8Q`=S{@#mMSIeTe!_8uQD{7s`D21RfOS
zv%dO2+q%5kcc>oJ7Sv`q&yo4Wk)NNrUBgv!gOcy2S=xwv)(K+qp}uXvhuUbSnO{2I
zWA8uh+r)$WcovNnew@HwhHC;U(t};`XVp`=FcmQWHBVsrT^c@oUuQmI_y!*Yd`_|}
z*btGA+HL^whrk1YKLQQ~t_mCmTmx7R+z~hexErt%m}ray9u6E0JPud|JOg+Ta3b(v
z;3Qx*@G9UK;5EQdPnxy@Yk_wGV*r^B1M7h=1LN7ItH9u=>0jVD;8GYjLxJG~#|;Cf
zvHTe@(dmy5KOU^UJH(HM_z--Id^C2d0TZ3*&nDs>Xk&hF7*m$#@O>Qn=5U|D_BlSt
zNBn}yp7|A`KeB!PP#H5nLa1EXbJ`;h-#6L$mGl@kcA@%V;EsIs9PpYwrvfmwOGRLq
zS233PGb&*oV9%oohVM&!AH&xyeuH?fiRuZJ4D(Nd%7wLKOJJhIAJ`i>02m*x6)@GY
zH89$WYXdw4xGgZXYas9g;F;j@sIN$W^ZoQzY5o&_E%NMIu`wfC+$;3i{K{ut4*c27
z({Js`R85-^;`dQ?uSw5q|8e+*g87|>+$~ypvC1#$dAfd2_nPfCHFjxrdt0XV1qc@F
z4<L4bkJ$Y<V)xmI-9ICCzl&JE1~iKU92{_Pz`+3r2OJ!5aNz$r2MU0GN#%c?Ha=Rd
zV;TS{&ipgWl;+s~6Hs4T`;NhfWF(!BAd82pG)5t?$$uhKLMC9bOf2#v#oSXyWRcGv
zU>!@a0GP_23w#NSWUe7!Hcv9I2f*?)JIGOf48SkU^}yPm#WXU<t|A$e>c;c}2rNS~
zCdJI6-^jxa2~-%xx2k|TW#9vuhAZbw_2TI=%bw<#FJ}D!$vx5d@ce_H1+EDS;}gQJ
z=v+u%&QJo&kQNC{a!(X6WECd2wF4%(jbseS0?hxI<TVq%lblBFL~<IH7fh96JmYzZ
zZzMx;Z73a31^I}-ByW`ft`1Cc2Y71o2d)Ji1PqzP)CU+_o>|<Ky1=L-lV4Fb^f#Od
zWs}@%BAL1YFl0WG=S-gill(OYnB=d8z$AZt4Gfx0tAU#Ue+LY+GK(ui^3g7QC%I@J
zus`r|-~ix1fm;Fp1x)hLV_=epr~v|jU4h#JQ|!Htz#jp32Cfg>6}TC2FfheG=msnY
z?hcIDC|nQVDZo8}DXvFv;Mu_afvFFootT`3xDDJECTE@7A)gm=yk5y+&(}P=SLAAn
zcZanVzgqQauZJBno)l_);#-HD^(H?Bv2vDJ|6PYXhJoM!2L~J+aB#rE0S5;h9B^>J
z!GZre4irF*2EL2^U*+T1DCE^m0Dg^a4*`%;4^THh&q9)QAr~^4_X-5FBqsCb3pJNa
zxkwL?L>I5aYw_KSBfd6e(=|5B&dw$M8?kG|==FvuNw#+9k_|0sP1yIEmhXP-dj-q)
z#_YSB<$EK@=_T3T1Cr%STOzKKoX*FQPelz%vq-6Ynj7*BK?9YhXvyA<Sia$q{bP~-
zp%5{deybMr14vUPKzBiDI?9LNe#jy%^UsU6{FaY1PkMuucoyQsaWKJg<M_I=-@hrQ
zJjw9|!F!(HJpV}vQ3;>t_z?I)E~U01c^NV{M|MPi-~eD9a2sHf$H`te9GK+e3BVnI
zCjmpoH+=z2a`J3ol8?UzCiyrCnB-xS(|Z9Y1Cu<w1vnh|IxyLPN#2eJE(47EnP?9O
zbS$RYz-0fe3yiW&zQCh^N$#Er91o1LO{0NPwrLLV9N-neiNGnq^MDZxky{A-0Of5h
z1HWn*TV*2R4T+80B{mMk-%Remyza*di$->+x}KY;`oS-=<Iz14osQ05H|Cd;bxLgg
zEshi_P-e)S-tIpl*3V9?|D0IAF0uY|V*NA3`niks>k=EkL#$u5*tj8L{i?<KnTWQZ
zV*tyX-X6cBuZ;4&J)V@<IC*0I=fv9W#qI+TYu^{E*Acr9K&-#H*!==x{q@D_yTtnI
zi}hm@8^=JbU#nQZB(Z*vV*QcD`sa#`XCXG8nb>$1V*QrI#;FkNw=6c^pV)W|1=#%Z
z_V{-fSiZN%p%WX&RBW6wvHq%J{q@EAX^ZvG73(kkyb8_ZZ;xvyHg1F1cy(gq(20!$
zD>e?DSpQeCap=UxmlGQ|PHbFMv2otS#!(X+mr`teG_mo=#KzkY8;35e0rls%#{&@?
z*F@?#A4{<rROTdIybZB&V8zA{6dRvUY@B4VareZ=wHpJ0Q|9#cc(G#rhsDOT5E~~z
zY}{qBab?BEhZGynR%~2^dhEUW_PDZQ<MfD)pCC3~tk`%yV&n3Pjq|pc@#XFDamB`k
z7900g>iBYE<DN+!hfZvKAhB`i#K!rRI$oXF_?2Sg>WGbNCpK=d*m!kf<IstXFDEuW
zhS+!@V&i^`jb|%1UWwQ^Bx2((i;Y(zHtw?6_;+IC#)*yJD>g2^*!VGG&w~&fcTa3Q
zB+da24mddA;DCbz4i5Z3<N(?K!{5dJuhAOiF%gX#zP1NIrBo_oR0ahf3_yxK0A{~@
z8EmfvP@%B>_~i3C4z}}|%yyqIR1qCzP(^8&{l6e(d>yjgkN+k=a<dNt&cR~<yEZEq
zCRJ`%If~`T`vC~$Mp7o)dr*`vUWY7Y`{O>@&&_4iceC#}?foZz@~UVgJq+h&pL_aF
zQ3Gf%zqxK^KYwrho@j<IH#<u@)yxyEZYX04(*G0x2&$Xe&piOwu%TP(O5e?OwXI75
zC)@zE!iVZY{F;XL2{!Xds0%TQ>f#2R4P?tFstfVeA0KmF$j5=co9jY($VbAKZ)QFY
z75GR#6}Egd_boc-kwAuzGd@r=@$nLx@@*Wc(x{9|zTUW%9b~CD@rZax{4tl2CX~VU
zQsCZQe8`u@WG+Lez!BpH#+%Z(mknfFhPe+J@dI;P+m_pg20MV-g=q7~hsyO5%2gR~
z(m2wnO@Ok4Y|FJRBTXoS{OqaiKLn<+xkqSwwKgi89!zDpXIBE)0M#w)bM$*N|A;nf
z=UAi}<Z;Rf;rwtq6Q1(ew!JwXhB=;xd5rWWq5)O#p-XJpU}Ge$3E#FFWr9&2X;kWw
z{-5&T)iGkrlfy!}6@+rj1K-4;ND_ErP{`H9l-!nC3csaxqcW*awa15_3;8(`UvbBJ
zj$uFWn0Wgsa53Nz;17TY0M`W$1Ex7u4ouGr#)qHd__2(yoGU(U=mHRdeDpjeFg-6C
zn4U*|L6{y{90&N=Fn=JLGqp%J*OQ;0IL;gC1h(~rZxDNKO<;O1`Tx*!$^Qo*=I=xE
zoF~51^ZMe$&oO)-$5++|gXjW)GT8GP0Mqk)f$4dTfT^D32Sk0M32-yu=D;*}wE(8)
z`{U!r#tJ__;4AA#4e0_<A|D?|!3`K&f~fDa=fZc*MDs{FV0z9ZeE6}Bvqy1FP#mA(
z><Z^(A|LS+XZ@OJjC2R~2kr?BA0m#<S?&qk7kD5r&Kod+=iC5b8Xxc_GR*=G15O4G
z2mS$A0elLW&SSm{90_cui=P9me4{RFrVD$dO!U1GFtuZ2VB$*?V1MAIz-GGman8<~
z#+|Hmtq0je*G6FC|98MufwuxT0Nw_SKFRF>HURGeCV#d)z{`R618)L80DJ-XAn-rH
zslfU3;T&0Dnr}`5Q+>Sf;m0;V=JA!Isn>%p01uFl=z0iD?f%H-cl_8yJbTIru>IX+
z;dfsGm&d)?z<3s&_sZ3ui@xD>)T>tCv%ec#92#^n;=<)%g<-&$Dy25os<OA#i9?4M
zPC*64?*9?JU#A<D`}XrM#qOICyB|jEJ{Ph3SH$j1sV5_P-)@%>Yex{fuScx^7rKK3
z92{_Pz`=q4Y7P`Y?IiX8S4UvkExpXY4DWS<dw9pv8iLMSrx<RgW^C=wN~Qa>hNg93
zHju4cVP3Zz@dJ_<%rX?Mqip32l08ZxO{0uwk?Sa*S<cW3rBhm(MIJH4s_{@tGs`H5
z<446XfBhujB+xVy_!Ogo&zp+hAH`x6@=PcNkfSxdd0k%<`FVPIKH#Sut)IyEpP(Xc
z6K}A*FyWfTC&QYT`Oo(QCVzQ7FxJe>|DD#&>+l`xB-3qRU*IRev>q;rXVN;j7I1T5
z@>i#IaC2a+{Y<TaTLQNQ4gkiQmHEGukAGWy$6A#6zefNgMt})xO}4*Z3)}_Y6M(w{
z9{|SE#dH+7J8(L158$e3-(J9VfO`W+0i#__IP0CootqAfwW4V+@BrYmz@fm@FT#Ln
zJ?4dL16z-s^0}6_B5Gv+`o+_?KAQ4$TF}+alOnGjpZxISvJbqIJ02Im9uxci7rSng
zdL8q>vc3~*&lkJDTkQG{-Npe94mddA;DCbz4h}dt;NXCR0}c-S&vJm||4-k={{O1$
zzr~0qoesckzk?lxK^6Qby*=sdCz1}}6Q%>OluVg&YfB5jZ-?SzmbuA>z(1e2A<RS_
zY;6IsgE1Qd<Zfm|C<IKhC)onlFxk`h!qUql3de4b=yhaxiJ@am8SD3*3~zqUb+zxp
zUrSzC8!uk=6f0BSVCDYPHf_~6mu{)T_m}W&wKO~~aLo9B=8nEtY1|#vqvuWZdvSJc
zE7GBt*gdgFUFT+zD*tbLgxzmHqyONI*Yhbn8zkLZnUruQ^9bZ|7~W(~e{6oTZ1aju
z#k$_>*CgQK7em9;aa+#z{VT{T{pSlw6&HgM|Lrz|Dv3nL#eYwaYkDSqNrMylOPwq~
zc~$-!acvHq=sjY?z9m=ZpXqQF`VkrBlg_q)?%)6i2OJ!5aKOO<2L~J+aB#rE0S5;h
z9B^>py>q}W^1o3VFV{y%eg**9o(bAQ04F<l05Hk_DOUNPFB$hp{x|R4qu<y-j{5-2
z@;}+_$>xv8b4tBFfqqYW1;~~k-xzTMkz&>nWZ)iO2fl8U_al5DN-}`1g4yM<x7Ab}
zDWo%~1WdYu8o-5t>jD=6hE1F+3QYSTu}9LR04@PM1=tPvYhY4&Yy>U^{1fm8z=wcK
z1D^o?5ZDR4Dhpf|*d3Vm2w+=*342As8_v`O`U&VyOs#=sz~n#hG4OL>58z7RZFS&=
zz^J3?6X2S_#B<t*OF9nHg$!ge_2qH08qYN?IxOX`Hw{QVerQsQ4>z~C;oIf2=)eT;
z`Z`of>iv#V%jo|rIu1080~{Q1aKOO<2L~J+aB#rE0S5;h9B^>J!GUZ!K=Qw&`~O3Y
zN`ujA`_C6f^6m#*dG4yNpapkUDfC){Hqt1o*}aymtInv3Q4LdRqGYYLF*=nR9=N4A
zkCLIGaf(p6(WqC2$Kt7wYduOvE7dxs-ZqtdMm<W(jcSGs#t6vikg#pwKmG2)1(h5P
zp}7%Pg2aC=4RS8QO?*i2Kyv-x*aV-^p6xq`M1}NvxyqmnjaM0?dEEnK_3S{9+lyGv
z0SIlIpit_J%ufJvKikhA8mN{>8LWQxMx>(%Jel_$AX)wbKJ)OsNC&C|pO^F%EHD2^
zi|>Hh@BAcWdxCF(iH^m<w?T)08%9TH1f8LXbkd!G{OlmB?gX7DG&sRhcVbp(U*;ac
z(#-mk1Vyx5k9(v)A)kpV_?^y%zACsEsh2CLKsuA)DhNtN-DtnZ&uz{06)iaebxlU#
z{rsFEHXM0N;mn4=kT#X2#mEhVd7TXDWz00UhrWV<&H*5r$*<uTRMe}LKr?k$q!Z1=
z|7;*znu!*o&rFMLnaycX0Zs^I{sw#p^>k~;ml-KAn#wHAXMOd5mNNbA#OEOJ#t+Zl
zgwpG>zRdG9A3E=aZ1}t*2R^3=H2;ie5uf+r^E3FYYi*{PXS7&8n`zFD&*uF=UbG1a
zP!k{M)<|!~B@;u1wzUpSzI}x%B10Bnye54g)tmZ)?U<xCu8K7NJQKcunfumCp?n%E
zbP2s18&4U5Jk4sGcE+vjAWJ(3pn`82PqzK5C=m<z03Rxs#vS$PV1d`_2rI8~D?7-x
zT(ds&41U4SZTy@^V~A)xEIf()f{0g5fuWmZ{z0VgL>FiN-2T9|@jU?82e=I|`O~)r
z#x?T`3IcA2@9^<q=YPP5hxrFZ0(V5Z2DlS2wnwq^Kt=&~#`j6U<Tvy!a1Y?kz~mpa
z1Gq2ne&Bw<$AHN{=qzx5;H$voCv+c}^tJq)$IpdCpRK+&3i*h>XkgOU4gw~6)WD5^
zV}KU{qmHI@U@h=Jz&c<$8)XPEVgPWM^O)Y%09*~<;ZtU64;%*!-+gvIi3&IY--iJY
z1s(%D40s~&Sm61<<AA>fo&fwK@I+wplL9YHu9zpG8#dJko(9|xcn0uT;90;l$A1Y-
zbb}sY-s9&(qPsBCLhvELHKV%-Fwsr==Q_Y>W7AAvObhH>7IZb!C4Bz?xEShzA!kDD
z1Ez1L`L!IrQ+cWM8#d?hb0L)noizFJGgyFp#OH;;RNmLX&@FRG!0<)mmH<=xF9pUm
z_YLq$;AOx&ftLdx07hS6?Y#o{9KNptegV81nCi6#nDpSu!1V6?4!Az>7GOGmbt`Zm
z;BCNk?#mCrp960P-UN)kWuiHJ7qFR+{Je%a4&}Vc#~R2-bkzhVy3ltRU3Gz}f7b(!
z2KEI00@w?9H?TMGUf_nn`+(8cSb2W9=I1niuA}k_APLW75Qcm%xC#eGTW|_s58w!3
zsxO|;@pBSCj_LRKWAh~t_Z9Lv1J4Ei5IE81cl?~f&o!_9j_e2YI~g$g1jSY1?E>g1
zV&kiejSnd{PN>xWU}EE#ij6ZZ_WS{{@i4{4#TOf=TkJV4V$U%W8wXo#ynC^6N5#fn
z78^HRY`k%?acae$7qtL`QRdY0MWaK9Pma|MXfpcKtxK-#-x4|P!xdM1b_*GB$!Si&
z_cQVC!C;g*jV}12WubXt`MNebw((r6PsfhAb*9Om4defExi`Aze3$VDF~_oeY21%D
z?$-LU+~1X>+x{d!`n2ol(&uiTO4?Po_F}dCR_j!b6MGK8Vhnzq6ZA#DV!Kww%q%<j
z^p2?6L35stoF4UU*(+b4eU@-I)AuS~Buy|m$egY{$$!7*va9RQZ7evu^R4EcnqEuo
z{#WG{^=5>fbN%?hoipO?gksN25xZx)9-~9LJ-=e@iDJ*)cwc*~#m1Qy8@J`RQPdBV
zhf`HA8v2%7k?xXsc>SkZr%CtLyBC?WV9b!2brPGW%;Pw*an8k_(=q}J8JW`z<K>>8
zht2+GQWsThrpKlZeu3Tml@CT#kG$C9$nCaUZ*!d3IOk%|+Y%eMU+lRIV&hwjJtsqK
zyl1iJL5Mx)LF{>IV$Z=7dv3&bEXrg~)8ak|eUQ)pr_&t^9Wz|2q5XT?pnBU}n|-=b
zTdin2pQq@5V$Y8|&-&E>dFmEJmyEG>y<FOJH&Z`qS?c&AkAoX_x^7Cp@_p?uu>cbr
z$6jnaeyQWwi#?Z1Y<zluEN*2^gMNs+y*)jA<hk?9*VOXr{B`{Ye=S;~%pAR{P{{bo
z{<IfG>bUb_&p#7;u9?{Q>SE8c5_{g8*m&)t&#!@SA#)1c*4y{-J!57}6Ys(L#ev1Y
z&!4ih=$cMkxy*xwg1z^C23es2<r{7+buqa9mfKB=e)an=Pn?%7Eg808&eqJ$MrZ%W
zpP$`-6tX7E_pIr<zZ-NKz#T0-=u+AI7xwM_Q~7UUw_jIp_8C0)#M%cCJjI^tBldhs
zvFB(>eZG#^^D4xiA1C(w%mu97o@$r0d>*%A<>r`PRh-rq-r8#YofA$iwk8@rxj$gG
z*OSK3+d*KKIVE0cEPI+h<Igh%*UY|Ga;wjPB1<!?1}<N_rs<lxX}z4zLhr%yO<(tT
zd%5us$KCYmsp!zU;qzXrPsJo&``Qp#qj`Grlk!lUh&}I3?0KPL&&v~g{+ZbG{Jv!C
z4d-J`Hcd^8{`Gz{pRc!<TzsL<l3fGVD2p7r<X=L*w|3-i=%yfSqu;kwE>7HZ&p6q;
z)9C=0zAf@aeCd-Gupsi|I$a|+J?UQ*F&bIEm1&Q-3JIN>o_(=7NPc#3-vfro{f4o1
zS8lvLAgyowW*u~8t>}5XZoXW3;in;*kN*j6HE77B4haXVTzC0pc~P&4gXWwap05bU
zU185__s`tgrAl5|p4?!=jCJM5bWWLgVZ?#(W8H5ZUbCRqsC608EuxKOPRolGfB4(2
z7)8f`yYuH77nUBPe4<oeyfffovmb*dpQos;Vtx9=o_i|xd^@q{35h*FN$fd6V$Yp~
zdcpw?4mddA;DCbzHXI;5@;k-<f7Sm#QW>Q*^479Qn6det0Awp_UNT=;-tPr4+w#pe
z!w|?E1ZD9d-E|p!Dtv-<Z%1ac)54Z7H){3OTOgfml|b2mjM?$YHdzpN%j5TQVET?F
z0(TNWhAtj<Y8UA6-AFagJrK(6jBC=>cfjW!ewW7V_xWDons|HV608sPN^7h^DnCDJ
zZMIjM{TQfD2BX{<3uBbo&L=}&o^GBWHNg<7CfN`OU>9QcgD_n4^<*|UE)1Qf5Yl?$
zL*R;hL=$+y>>XrBBK~4|V<Nj6Y#^qOfys{45*XDpwF3rYOvHy$zz=}^apQkQ-jaHK
zFZSGBvFm%Wa-P`rz0~rcSb0IL93WP16uW-@Z<jB{%7bF%Jh5__)N+*6^3f?~PieGk
z^jEqCJ^J1D?^|GSa+QgHKEGF~%{|@B&;*xTN4|^t6?$MMZ=GuNtVO@QcdN`QTH19_
z|D+zt&9D33m^|}x^FpWM`#yY@D&Afp)-Ea5ULjVl6&v?bth_4Lt|8W5Ay&Q=8)sgu
z9D1S_$<viqExl4(dp~jQ&;s(JKfBfZb=3xallgrXt}0xr*hl5l@nVu%UKML65i8fe
zFFU(fySP}puETyl(7mbWuxkUK?fh)=nF;GhOd9gMb1?Qwm8X7Mxsu;+!`9qwwf(-+
zuDeAR{@J8zYc8VA&f|C5^^WoF+3E?_locr7Z!52a$NW$-dfwbK&rkOs@a(~kzo(@w
z`u*z7(Q%8~A5$(x%x0EP@zcjEYuwAfyIa2bOCEjSX6?zbM<VZdB;>!<Y`~5|!!DxV
zi?xf3wdcJr`}zB_i;J~iinX7MwO@+0vrBE~6l;$cYv+{O-YC|-Al4o))-EpAJ}uTx
z{J!kJ|Lyi#sqL^*+gJbF?WSVw-D2(2V(rON+iRglaDamY4h}dt;NXCR0}c*2IN;!b
zg98o@I5^<oKsFq(gZ<y|-)#R66729~Cnx(qY}MRD*x_ZJve^Ge605}8|H-ya_J3P@
zf1CXD1djU=AKD|Z3!i^bPB6dEAX1ryOMF@G$de6Z@lSq$XXt2S1?>1_+ke&GUkPax
zqmb%^vkF7`eE=%0CX}rIO2lE{eeh|IK&-|%RHuw!cW7S#-6MZzMo+lG2$y`L`6k_a
zBHXh+)9Q179~GC;hw+icFy!8}pI{R5@qFO<6NXNRJpz{VuW3I4@r?Eppqk7tmG%?R
zJ_49+*uH^o!0=Tx^#jH|cCI1#XM*o5^FM`eDV^PHS_WJZ7(SmY-r)}5s`yUrfjtS1
zeFtyZSM1n#5LMyJ1*1~JWTmbuyt_W$o$6kDLS@9x@FRQ6mZ}?rcCKu-#Gsn^&(uYK
z1;<@0pW&`3*lJ0QT{~wLaMi%)+=uc_+^Z<Od&K@bLlf@rKcD=-{n3u6LE8c^#~;!M
z#}_%-3VqSB@8DcL^@PjAi!Vy8b9dp6DhBONkLqhN$Fcp<(Z|P4<JS4qtiMq?sl@2W
z``=v%J2I^Ld8J42^39#w+{H$s|Mq<c<=|5!b6Q`jaQ(9zdT;5t|I}yyK5epUK}LOU
z*sp^M6$!YX;pg(OieulwoA${&_8kPQKNV4Ka-XH`Jof%^LVd!ks>j9Z94B_4ykp<N
z*Y&;rD1D^G=4FMPu0CJYq;{X#_10k@Bi2(gr%uJ1?e)98X4)@*`0w6O=;4cHhmQZc
z{)^L1gB}&0e&Jd1rr6Jk#f8jioM~L?bN5Hbg;olk_}Pi%`1~i`$4*<k)aYF4z_$qt
z#_z;BkLA0o^>IIRdQr;KBG2xGWw;j8EZEStc-vi<hW@Z(=JkrcL$LRg<(raOKH;#}
zmJ`h<U3paga&koU(X=o__q)>y4PM^3e`kLzVE)_v_8t2Up8GcMT4r(4i@y{JEkA!q
zo%%0>zr!Y1$G(H?{resJ4&p-YHoY|BO2;~te>pa{pP|bAV^^^m+Oh9o(5*qL-&gA*
z>y0V;_p>#>-5$Td=_+C%)u4ITt7q{|16B|HdHJD4=h<Et+ZUhkU5D=z^S7%xZRJu^
z`9C1wy)Qp;$G(G46R(7Cd3nBD1)oA|7Csmpo^tLe1e(hAsomyfj(!>#5d2W3*tdQC
z>N!uFjU8UKLaWBtugqIHkh{IOiFiMI$G!syi4JgZz`+3r2OJ!5aKOO<2L~J+aB#rE
z0S5=(fdgd!AIRl{1qJb9n}%o&A=>akAqjqsBK69U7?ozQQm;{}Llk<WAtV<6LkxOF
zh+L<mOBjeXA+P)YQ}AitL@YS}lkYzlX7&Ad{twOpApia2knhd@`yPV*9%=#RM^Ap`
zpTl9@i?`oLV()>ubY{ON`m%v6HgzL1yy`Cx8}V!Y^8QHU%VB5Y;Tyk)pdq_r*US$d
zzVIf5ykz!kRGppkNA)DXc=B_nbMpo;d(i#wj$XW1aN)+i9SYsJ`t##ufBtc_d1%4k
zp4LwZHr@WP0PJ5<pPTo-{5-|_Z;JKH6l>2AYga|HIKaUH2L~J+aB#rE0S5;h9B^>J
z!2t&c931$c<^ajZ8ms&-_wo)2jo0c2hxmpVLON)SN_~tnLWP~<A#n<$R;xCIs8!*L
z7^9~~ZdAo7b$acfP;c)he!h*oeSN%1c@RO`1NzwPJ&#nW@uV!V0A;*Bpd!~jHb3+M
zJbwGRfOOU$o$*I{fiFLxGoJYPdWW6(W@-r8nqtv;0T;st@i1O55X#pel&WPgC>w-E
zs<j|M6BVk{;?O&rszxXy<*{l~2{8RZPyVs5{%86F+7nOv)McoL%@Y*b2qk`7q~sp#
zm#2O9DovbRt%?Zcg9~CWK7R8d?xzU%V>J;<Jt`EBbo$-FSJOiyR0estS{Xrm*Nc?Q
z5bj4PHCla)Ty1@DD7*^zef;S{o?%M87C(<uMJU-#dj5_#{+_Sb*4KZ_>a|};*XflC
zm4SQ;to0&#HVgN)aTaozPeIyizhl*8&%7Yqv-%X^UMTNZK>Q_N2I8UlnLLGjJ(FL3
zF8Eg+zabw6`VAlNkR8g1lMPWRBRM+|hxmMFgnX~Hj}2YKZ#uIu+jbNlMrEE9@?_H{
z7ADcNQiXiB?PAG*dJ)Z6g*=viA(TUHcUZV*;fKwS&2b%r(f9d&kF%t3-5$>+eOVh^
z6QH{?Jr(&)ASNT7?Z)CYLRZE7D=GndBOON@nEZh20#n?^dcc9ep1_@fvBkqg<HHNM
zKQMk{3J1oPcasXZA+Qb@A;;M{Uf9ZQ8j0_XfyV>m*`}$$c(&<FV1MBGzyZKZfU%8)
zo%humcs;(i0p0?PI<WJx5IfRz6yG}np8`gmOliPffNubI1HK2`9ry`wFJLF|pf_+~
zVEB%h=v+vIJ7?#D4FIl=?*oDB0n34D9sx~EZ}$Y(zHl0H%QvFCVal+I#?GbMcI#gJ
zzy^%VA28{-<vae_iC<nmobh1jl*(l{P3@1gp)9@2tSVD0?RL&=*1N#n=(YZ}apoEH
ze{T8q-QV)r`QXQMsvY&cn&yLc;U2Q*|Cll4YquFUyL8@CeCMs}Kdr-=WtiXG@&$HL
zl)uvVLES>S3TdN!pX^3D%fI`|X}6N0J6k@k&}I3=4#&VyA583S`6|tg*f;t?w{e-x
z+pS*vZIP!q>yf3OA9lqhCUgC4ua9r(tBt(=JK~eF=a;Hqwr!tnHH#ZHo`;*>tc?bX
zWBKp>x@gh<^vKxOWj<)R<C+}j1UzTyX}>QY+fDODgT^JQUe?U%`x0jXBIu`EzN95X
z?q&WZJJYz{-^0TLS0!`Ys6v$fw9gN#A3xP!+nPGHX0Oe2KF1krP>O<|U!UFS7GV5f
z`Y++d2K+nNfV0?G{$EG9M7b<UyxnhJ%DB}jNBhEOiP5`ooU-Af>toy_CZ$a7dM^VF
z{V(J5;)LSU8Z_<dv-KzU9{YZ2hyAnvvga3>TmJUJ*pWBW8xC_SFuWN$OhZ>Hw?N3p
z`xY<zICx&O+N*kh^LPm2-ZMU^sxM4aG{4#Z@zs-qr<PBQL&G@0!2t&c92{_Pz`+3r
z2OJ#uAK?I&agarM`+ujl-Mh36@@e21p;i-l)nT{CGKrlPOW(-@yD+yM%i^G*-koJZ
zY<B=sJ-PfP=`ItjfQ$7dUwSOaLfa{gtz-3irN$Vn*D90-gFj>i<|i*znK!9mzz1(G
zvqJ<*CD}--GR<cQl*^{fp3!=xJc1P|X_={zJqRk>mf2Yw5vx|Vmun)_%0B)Ox1`~1
zZJ|B=^V1VKu9|I`J&ba_F;>?>6RD*lrQmA=p}eg^d3CasHx&ChVtT4#lmUi7m0C$x
z5|wN2w{@}RC-AnE+d-o;s-UwOrtA@<G8o&VNhK~bNhq_iwM;`BWq52<lu{pz1067A
zBpWM@1pZc_!47C)Q>HL3wfaCM4u{Yy&1F+(lCo`Q3uU*ql-(^>sUI2)O%ds^Gzw*F
zE#grq^%C*fOtTy0MS>2Na(gI^y)@Bm%tW+JP$+dqXtL0=q$}Ipuf_>wceRw=6Y5kI
zG^b!QKOK^KMG`)n>1E1KJhPXj%p8c7xa{GW@(KD|%4P~=wN^1$84(<7h;FMf>W8us
z<xhl5*}onLWy`ZGJ5Y_n`EsT1*J^q}0-`MCf=H#lwH_0QLay$iR8aRqrv^w#?^U7P
z7)!Z9N_m{p?&XG%!W&?)l-owB#-_XM3YLOi^SkJ<Q0`DmxwN*>#$f7*z(PbBAkjPC
zTwZhNp9n_1p}am4mzOM*H{Q0qAi2TVR<GCU*{eX3{$r-E0`y`8Q!M3SUbL1cS%0lA
zyn7}I<;}8`*ET_ASrtmNjxd+?KqzajrK~``QW>NQ*UR-oC3?S@=lE#oI|&w9%0j=i
zU6-{@=;QB=6^;b!PjlOy5z73=woH1X1Vlt&>0qGARf_V=GzJyrX<TJn9#12!$hyd5
zu=<pk#vMYL>ut;IVT|AxyVA|4<~~!i7*FGOmh$>w3Re<+{&Xgl6#O)oHCrfayQM5F
zFm(ZHyeNr{l9XlcD+P-4bnVSjR&TOLVj04Ule9deP~Oj$@-QBHur)l146Na#<Yk&r
z-VsZA-HqyAns}8a!rvSA3n|KKCCp*bWGn-mu#{z$6JB}$1!y9A=u{fErj=~1W9~mE
zg?gN|)T5``z;_=KuO*?`To#?lMsU%#EHo*4P^?sPn7OQEp{#4RW#P5Nm*po3T~&p)
zEX_0)9QT)PS@fEa=>1?Gf8&I5?pewS(#o-7VecY4yc-?}<vq5PhsJ7yp&m$Lma&h2
z18Ls1X8Iy<Rt!O=ZFwZ4+o`;hLU~U8%sM740(Ek|vWHQR?HrQR*M^L;fI^n?f?9W$
z>ugGsX1tmCxmhT$grz*RUyv4}gpyaeU{aG}PBWM1QJSZ(jHSE|2KIK~%am;HGOr~P
zh4MbKln45H8I<}q{Jxu@)*af=YF7#x&1DuX!_!#BQf6CCYz+TW;>k4hk!sCk=Id~w
z%o>(5L8l<~)7xHZ8Z(6Q>e-ej=w5l9q;xWbdA<($kmsw9ZJA6*hp?g&&!dNhvYJ@R
z68dRt?6wM)M@dzl`Tfukn_~!CTFOKF1+)&9s@=>yOcKgzYg<m&ww?Ksq!|b1vWmL%
zG<C8qt93A2mr1RU87Gw0%~BR#<gK+DgI29<ZPcszb-Z4(`Ncf$9th?3v6PE;<7exh
z=#`LDq?td>I%{<~o~HvW<#opHK~<}vMrBWJAMCno9WB?>OBW!;oMvvzGeWrvOSyqq
z^0roM4Kxy@Da$;62H^}k0#%l>0#$m0kw!bMVi<u^&}VMP9YUGfEM<04Ca@yebS()#
z&F$Eb4k`x3TFNswUQey1Mg4ssok_!6bGgYvxu03eMSpFpiBsvdniv=X_^ylhlSJ=C
zbGaVa8$~eMQZ6livnyDd^`g1lg+jR#E#+cfuqn2;T(6?7uGGR(^e1y4b|Xhzz%)y_
zU1N>9SR=E!m{)TcI8u~p?!zXb%r7lvf>x^zgQi?b$}`Ui=|Xw)EalNkg9$aHR*<AD
zGi@Q*BucP2OIh8Of))dkw>0IMX*(#Cw>(REJz$}ePKROcqyCkt_8hk+OIgfbMej<I
zqe!PuY9UE^nj)0D!BTEp4Q(b5rY-8sGA3<#G8s|Hao=0YV>&P4EsaTCqB+Mr24~Ay
zaokQzdCV|F?~qopk&#NhfxWsU;i<XIf>ro3_gTus{3=k$&j8Y`>C9szK`8T=Y|4b%
zR4KKraZ@PoH{0@vt28{?CP=o%GV?T~D$mnXmhv#KQF%f~MUj$^jl)8j=PhM+m#Yk*
zPB7p~wXQSIH+~=UG+wfl$JSOB^|KW333FM?gtBf}%Ib~{2gFe6`B>V6r|V9Zva$?$
zNyeXfEQ}M%`^QpVYiy9=73-K`Bzp&%%X=V{_ta8e8)bHLD9;7Qe+LH~9B^>J!2t&c
z92{_Pz`+3r2mXI?fVSn9688Vs7Pj=uYK!0dUn*aVlAIzwf@|G0q;*JpB{s3NMld}k
zeTTU#N-vL*ktAaXA)kSeaFr%Rt&XUthVOtUWz$83+x|2}p_Xf+6lzbM(o^9{3->sc
zGTxJNDPkhHdfHfH)9kb0VX~@tZn#cvjBc8J>A1@m5aR9Q>E-D~u?#|JtB5w<P*qk>
zqg898w6b~;v=3W`N04385YoF|kM;pwM|y_@=yb58%R`vWFr=q4Mi&xI1lLo9`zi25
z1V3P%r##oFWIhfXnA|w-CFBqp+_60o648jeA99ULw!_|UO2b$9N$_{dBfU)rK5sDY
z3+Wy)8uAHmTrviGzUVheL1g!4zwt=G@2RZ(RF<wFxA00n&Y$D_J@wezBj<m2br+w8
ztdQ%>cQ~##o=I&_`MKTsEcZNGW6xo`Sh+r;cchUNv4(&wc?;y2w>7J4Qhxrq1#R={
z`TCg49KMg0*}8jAkG`z~vfeXgxfj5mY5v_f+k0@_Cf=CuO|rSy;gx4j&2lg6GiPSG
z$J2nOW4xJdd#`oY@|M}&d!;TbZSDmNb)hY+#P4L=dwsJ$b90t^S?jsg_TDSy?XbDm
z^A+0n*xnO<SCg;Hp8fni+6^Z6fRdQ_N$~?v&pqk3_n;fMz1REzYd`*XzWlupu?L%e
zH}xl*d(Z^a?`X>#-CKIt<{kn8*tTB^e@|~zcytJOg@(;G_db1v_N~@?JzxFZ4x4-C
z-(7$$8FlgB!{19_v|}*QSaPDV6jqoEhAy4z>&Xu#Hf|}9C#7)!Cyu{E^+yx(>9{YX
zd!V~B+BOOI`r6)ue>=?s{@Ckb!t>m)UlqR#Hz1wrP=M-SD$LFe^~a+<y}T5WQT+4F
zeF%@`3UKB-{O_FUcQXrf$!I?U&p55x7_MgZFsD(vv*ix|I~V$0QeiF(0TlcZcEMAx
zRBIKK(*X_+I5^<ofP(`L4mddA;DCbz|7#pTII)-Ug}n38lF@}LGM(HCX^m-mg!N@o
zer_hNS2oCx|2$yn%s~tS1PQB5l2v&inL@?|htanwa~qW>jA#JdNqQhahsQv)%>ucT
zvUB$<swaI&z9zR3nOkreeLvA^XAdAian6qt0OW5^GN3Ksd<4njBN~(nMf6~%GI&*2
zA*+cfg|$Mgu@HN!46$;xtcNi+LZuC9;N{&UggKe&^ss=3^llx}lLcn%+yj^14Lut)
z@$~WX_VHob4T{AGEe9etMtA~q)RN{l;AIJ~J(TA5Xu(OI))HK@K=cz}!Ie%(VP`~0
z#)BwBs6wk9tWxGZ8yF9W5AGna0xnDt2hDupiFM-=NU;D&qL^d+rRBereF1#XD|K4E
z@jdW?NTl{B{RmzAb6)-e*#fO4IkS)RP007cc17WywEY1pJVbs}Y2E`HAQSU^a0lLj
zkH4G0Kc)S4Ervo50!nc!`3uh8;{u^cBOvg<4>sT(z|Rj2p|J75wTbiELupp{fZHMX
zFGfSBA-Ek_Zc8~XVvQ=b$~g4B@PXcg^eV`}z#j%o?+W&A^!eZ~p4igdbKzYf!vGRo
za`{{MFC`x^KNw<l?`MLbcLdFg&=8sDhdq?0jM}jk2vCNrAn-wlZ#0+Kf|Pu~zRPH(
zo)06Or!P$qgs#r_2l&^~JCXVWrR^R4{0AVwhn%~>hrakGT(Ud#Pf9+>^-*!5F|dui
zhmk?FGulc~{AQjHl=jQe$6o;f%H|m#6bS#ILa^ZX!wG)O6EEDr3v-{Kd7xh59<_)Q
z6j?W~`a~pbZ10N`G&c|*WHx<*(yV==T%Pekql|xFY=ET0^TEr850qx*LwU}8ewn@J
z2qTL_779H+JV)QdJVEjmy*K)T0rb8wVSO#Q>f;;1M_i&XNhaZ?A-KWuxA0%e`O>IS
zsFiX}tnNMVfn4>8Or1@iptQjY;}DIRpaLfo_+aloq13#$*9McHh)fgsK<i3+f09h4
z+xKAt5TGJgQ{aO?`hz{!l|qRBP)i*9_s}oMO`ph30Y6C2AbwC<@0)d^fB=;&x`<$W
z6IjFU&_5~1hdKT|+~^U?1)e6Me0a3?vC;xN7_ED3_(Ew`zErl%q4wsBC6>QJi@;@C
z^?T?h6sw={BNa^W$2Ij6O8Yi!cP0=(#vK$o#~zFucRtbbU&?-B9yjcz5{gqeR9YN8
zLB3Fi_rV&jG^ixfWnhSTPNB4W{&$2Z7*+CYZWUyc&<Knl7V_;qaD?Ve;zuy}VP20?
zT15AxAwYnt7Fn%5GTKvSjTov4HL49bcSH3))LM|ncwW$8G4q1bti1Tx!izBQg4V0H
zAnCXfcoAXLzK<!Dt*vM+HXLiQ0>Grx$-3V1;ED=Lo;19S>^X-BIvtD?!(gNKeXPiM
z`Y=^;wBLyMK|0T@G*{#H(?9~yoNCXt2#pWe0^Z9Qp%4PZ2iiAh=7SJcfJg^a=eF_}
zoI5ho_^|~k#|ZI(kGQLUFE0}^R#B6ufJmAb={-wn^XI$X0s_?FE|9_puocWAxy}}(
z<V6&1zkGixKc?fS`C^<!cJtbkRqtPu%MixL8T1QU$J>IGyin+3=`^PIGEq>d0wOaE
z7aqXWCn)V@YUE}hK&?E}YtY&2?{jfMp#`W<%(Quj2;l~Z5rEp<b9&JN4np7;6kvP;
z{)_GtaSA=+KqG*d?Fn<CjeVOm@oDI1d%~PD8k?_m*r1(fD=kaacvC7QG`@fMS7B#r
zvHn460}@RcJmGb?FyZB)!`zYeoof%CU`-xsM3@^ayCSvkjV~0&fW}Qmb#^8g;|ryk
z(w#T(e5uQMP-g<H1kUyQ)zTnu>noPG3ya+Fz8E6|y~LN48t5ayG@npf;JJj0K!AGO
zIDs!F;9SqEqWPi_1pS8ZizOU}4&w=?4+gY<gwm|w$(0s(LK6_JS8PH0c_l^}V^HSZ
zdd$*R{G?J9#8Dp!tHW_015+QNG}UR%Y#=~=PA0_v+=>ijtF{I3Lu;U8IOzn=NWC%y
z@#Y6B^%|u*1aA;S2)#!_40=U~T&JT;9Q6^B5MvDS^rSx)XGA0ClkgCFfXWA3NW>4I
zKD;}PtP|F?A>O=;jW>L4JR5jn0*B8HtAVgBg|2zJiB>c(muR!*pfoFZaYo_&(ia^>
zTDqAogYm(ZXgV}BN8NcYX{EIU(Ynn1E_L(TLupp<=E4MdtUX?`Ypplf)w{JZPQ|1H
zJYJ)gSry6KA*Z<@mlWd+5!9S$-eW^ErCFf?H=8;>APF?*Mf)PSPR!ekhq)yfuRcca
zelxw0xhc&GK3uZU#{QDGu~9GAyw<=X%;&kKmOo#V=H@+UWU}}8yLtKJHOG0i)7;@{
zZpbC?Crvlrf0y%dzwn8c|L@wTX=fbGW47ZL&Vq>WWtZ;E)kMvyKOeMdUrMurFL!|i
zNWhbN9CwSqwETZpdb1zHO2pK+552UWCwfns>BXEyX;x^&O{GN*U}X!ATgP8o{=XZ&
zyczSg29C#z`t26ZTz6_(lF*ctHqVLa;ptsWY2~iARPcl~=AH|KdQV-Pt;#1_{=XZ|
zInL8C)ff=&*gkEIr3a(iZLJe`4cA0BrA^)4=TDwEKh7x3)zQ$GOyv_T|KE-7Z09a!
zfl){1s0PS&JEQ4X-%iJZoAkgY^leJBLK7}n#(zt|i+Zi~2D^GUdf(K}T8+I%Go~X(
zZvj|IXs#xGFr`_cDR;(`|K^Sx(vD>;GX>=@tv_Lter;GI%^d!c*$<dr@U4<tuA86E
zvu6F>|5qojEv~7*Q<`blf<JgJG~;dxg2xjm!t$p5X~_*+Y>a)zczqB?B(*;Roer=+
z_PbIVr#rKs5KeODE)?LeW@3G^p1-vGf44p#qcSL7Z+3GmH(Gata=Q@j1q$drM)CiN
zJR0kiW`!0U*+2*qLASJR{YLqU-~SydsJ=q6%Q0tDQLa0?H|V0NJNTFrw+S79`Z}d0
zHo4mY2=ED)VWuBS8)0)Je+&QLt=-ky_-xi`c#GR>8O}98ovFS3p?qWQjk%7}tk9Bs
zE{yG)7~9g$b<v2w`dU91vqde}?dt==sC|>pIB_$8seLK!_=lCg0s{DRlZYXJU?{Vt
z?cdpsYnsH^p?CHe&<#Nck#iUyYG245dnnDiKRJL45!x49tt4*WH@&;%;cxNg$aVYr
zf;KjO&pEMm7wO9=P5;m%3<%K5V!M=qZZqlpy>}hI26o8CYdsptiWvK>%^IQN)V`_s
zu=d6HrL-%u?ZR5LH5W~bHb7t3ywD}X<Pa+Cu6&!eL{b;7R}_Vyw=q7{7s4(&vAr-f
z)+z1OqYN4jfHvG7$^bCoBMf``$^dh@WWHQkEDzWlgyotdr|~W+Yb@Sv9OnnhsLxM5
zjdwgS=^-f13T?TN=KQxa%{XqO^#;3oxA$AN^F0eE6iT;pVn{A$geIspHF27I0cN+Q
zK0s-aL4NlcL0lkLlLii;CgwkB*Ks+_2fCr5Ia=m&NpDloLG-%eFxx4>H2+cB*hiTo
zfdK6+`{B}%F|X!7wK7MywOmrmap<CK+|I=Mg}N=tYLsS$_FULP{@cyLd0}^r)kJ8p
zO*E&zEa~8WecmHJ&|D_NrX6%?#uG}jLI=)#rn46^+TXqiCDh;?d%ImZ0(Bc36RB4V
zSnP_Frv0sLSDq&wxoBbXcLR2_GKyVE`5w^W=<4^eo9Po!!sfy2{A5S-0;O4@6Sqv@
zK?3BPY~}@V??Ov=e4EW#nE<D~_hwja3BrjVrke$@3cy&wdx6q+58VC`2oS^t3H(R}
zGawFU0nvRzG(QG~D-!f^^1RzcZK;{CU4!!ng+wxK_B#V?f=>#iS)nsmx*Pv34V~w<
z^#;3ox3$3=W&d~xM>-YOl(CweCz0H~L;_HIqFaW|eLc}Bh;B-=LKkivKWw<Im{6sa
z3ExQfTPMxj(%TAz5xqv(Ux+Ny@lcu-x?1#kGRf)9b`400f>%XOFV5Uj%*W&)nltbr
znn@0B4Q!Q@g1Ne+2ml1bh#{?><Be_n9|%jir@akmBHEwe<A)D)nR_U0*av;K0s*>l
zUV^Q4l1ysba`rkc70zt2mo1KT)I{%a^j&(F)0&Xdtk9iH!aagS7$v2Zabm*Xu<DNq
zSJ2)w`}FTX&_eIC)LPEmW?*`sQQG*Dp+5ovdT<x=^H<T5kLfq|Zv#$uQ%2;0m7*O;
zqc)!j+Gu=Jn^T$<dU97w@!wLbNIkx@)$6_HHfE2OZx51)?%6hUQ<@ceabaY{0=QL@
zn(l1pa?;<5aFEOWd`60RqB#*Xo5#1HoF_5?y}7CG{1t7ikyfV9wyh1SC~OO}Lj!jN
z88oglS~|16fHbZtZJy~aw0Q)5xL`qGp>yvAb31<v|D|828uc230w+}FM66xKIj$4v
zqV`X=>GPCkg}xTOUKnf^(yrIuu-8JPHoQ&UncE&81j2~k6f?b8yHJ`H`f;U&_qU&n
z<91qau&Z}lm%m}}pCQs19vhicC&(?iTxZmpUR4E)vnb(AM@eZ`_>?P6N<0AB-|2m4
z3-3m6w&Ob@JW8*#$JU`Ps5sFoE0d3l#y}@KGo>|1Y)0ZJpg)%=jPxYQ=kIK3g>hAr
z<L3C>HY_PyXfE3m<;;2Eg61+x3%*(XPar^ub$>T#-N7eX{=ZwhX5Wt$bRw)=o#Skl
zTY7_0bD}p`<;)EQCVDCDmrRctK!5>UQdR!yASUj-7`Ks;>R3axU4|{B2%cWf=*)aM
zh+azD^k?TnJe312wnq0nYTr<7(Z+EFcA2QUgD4ui6a$~uoc{2Wq%<ppTB1O@N&X(P
zY&oYh7+&4l$vV4r*=?WAB0WGTy_aN|pBVjkFHxFRrVitV6N3O-LBF&zb+&UCZ%e}d
z7&Ws&8ltu82)lIlo}h`wHWv$JDS-5;lx77v=Ps<f$zf7pgXOmL>oWLdD0F!j4DJ=}
zVJ}cd{4fo3X7&Uc`;@lvoR1ezbU3#X>lXs@drILiE&tzjZr5YCXEviiud$QisW)m)
z^zQlGnc10%UP}Av^xO!ZC<V8S?;4y5bmz$$lwX>L#_F&VwUeHqk3cs!#X84RTHv3N
z#dx|SIIj=+E4LaPw}rp7{C~H0#x~bDC3Z!=I^8Ma?6EfMi&|3~r!95n1_4tWQ`&`5
z1^)p8DA}G0x_W~5*(SQM0sGJzuP|z3!tF7s^+Vl>UfD`#W=kb{DQ!io@`AV#$$8O4
z571%no3!hdH??g{xKSIQ<6eo}uFpON9Yk;N8fR`XFwskC)%Un;00KmDMq%PUQ!#JW
zqvTR$pVc=>68!smkBuBjX;z5ldJ6R3%p-acqgi8&M4V$dHHX^KAteMvQd=h_JF`6l
z)Yg>t`xmA4JpC$59N#n<=5;>N^8ek&a`v)EB)o6z)3bU1S=P5VI5V9;(K`Ut6uD9K
z8Bf$8ZmXa(NR@mnznNZp4CH|zh-mfy&bk((G%F0YEWjvkIjvc30c|VJwvByMwpML#
z?<Rh}jl6wrz3yXidYdXPr`cIj-I!%(S11S~9;DdtfYPj>w(#JL{du5Q=D084K0F8m
zvBU$fEzZndPko-!N(OaU1_X%V+PLvovRWK>lfSh5f44FIMjJ@HN)xKns#OY=GRHkI
zxqXdsa!|n9ew#DrgKMIj(z<+fEuAM$!#yv`U-?y)S`K@IK9s~$JKDR#K@QQJw$GXS
z2=f@xOlfzgy&TU|s^tm@db40z9?~46waZ2~1&AVgGY&g*aKmBrQrdW~#A+abj_Zqb
z0za%prIodFXk$%mjw3y{otlIwM(;6aZV0ZaeJL$Yb>k@zU<j8cNF2H<c}On{y#g=V
z*ADO$j-|*Y!Aej>OD|asP>psZJuszpc3xT>2%zUGPzFFEbSZfvPug+(MuHC3zUQ3b
zQNy<{rIk6}{u&U#z$=w-Me9{*`}3P*4Y*y|$wVIoI*8txe>ihnaY6l=(p0`(g(bL=
zyDH3ADQJJnYYU>+C>Fhp?MfxP_&}sD%GoJF(zmpwUi@yeXb?v<y4}S54NUx?H0!?X
zST0eJHN(*U(%Nv}utOtWVNl48cG;J$66g&}x6(^#R(j*|ejhr~Yo~qaq%WcNP5RrJ
zgLuK(m(q^^y=^ZLAfCf^Tn4Fm*uENjH83cFl)=;dz)CZvS!qt-QUscl@|0#fH8N;}
zRKaM@c;bu}<=dIkZmj(N5D;J}vun~-BHmxZ%Z$D<c(*lo4&ylIsV$dpX_6p#dUa2o
zIhwC%-l8<uyYZy%1`Oj?3X}KByrkElv&*_u1B!^8G|)@BPokHl73;DTUjd(4+BYc=
z>D9dD-Id!0)`B9U*Z*H<i?0Bsy(sSS9S~r+#eXm_>D7hnb36?#xAf{j5z(6jdaD3a
z`%+rLl71fm0Y)(U9$it~A!*lPZ;&gZltzAJ(_+j%@s>!YAi7gBo!NPPL^q{vcy>{s
zdnD&B$Wy6UpyUbNF|lf+DtxF>35~ZZLW$^ec5(72g(su^g)^5Q7eqUyX}bMDLmV)Q
zOB8g2DR_D33GIUIO0SG$x?p<+Z-G?7VVdH$`e1L7AZJn9Mwer4fB+_Lrm$Oq0?XwI
z?db2JLvVzlDpG~bvOFhpQX%GYup2=g(eBkQpT+l+(t=ue)&>HM=IRPEH3f9dE82&E
z;?M|fJZ!abO1tdDfteoE(Qx*Ij1>$_d*CUp&v5Pq5MYdD&)}rI8t;5dlQ3$B)`qSG
zR1wXyK{G8o$>)L6CbV-UQ5!IpYfcjZK>GbDJaMm?YNOQT{2Xf!O(?BDsedQi?8l)r
zD~x+z`*C<?*m*-v0tlt%4D)cY?7yNkt8IQf*S<5)4O1hjW0$-!)&rf!7OzrAC=j*V
z9?j17))Czqfi7&%Aid9Mzuo9%*GRPln7|bj^#1K-QqOB|)ca#rN7$BFwUXI%;Sy|*
zmCP_uN3^GOa^cDW6YZ4dduxoK`=7`)7v}UcGO20L8msD!o-ZmxOgJrT>@drH23l#%
zyLS@y;31v?r6n4!{Rjk@#EmP$UlIM&`Af_HcauL^EH)MZ_SGFJDy35C*VqmOqvpf$
zp*A;t>cZ^;rZ%UvEqi}|4g~m|#hIilipP~F?{V{j6`NDct5|zbKLRwdvEJW>Q{jSW
zr?hL&+(=yxn9O+;=C7pRFP*i&XBV4|mU6c7*&_AYm{6@<raf*X$Ru9u3AN7mlxCgp
zr*KoDXCk1zSkm@`xAOvVtH26-^a7Gl__fU$&_`<<@?oVkD@^6u(8K^pz!+G|Ut0dZ
z+qlnm?<vUT1Czb=fW=&{-%Y4JwRf7)#iBE(G^-AI8n<8Q`_Yvo_iM~9CLKZ)#)NAV
z?9;}h1$zAxTsV_3)+w#d+#45w0MohDlKfTsYErLfviDon8Y16zc0ev$mn0CrPhT+i
zY4|WwniXbnGC?QdhCI@a=j`b<CfG0b+*lAs{W)oz3)`DUb2+62r@WZJ(>&7>tA^-?
z`Y8*Dwuy<@w_}O)AF9zRS)j$7`n05$G0PsFaiET-tj*m7zbE(;P?{BHabCswZv`RK
zm9gGnSEBi0vBka3Mi|eBUJxalOUe^V4b8DB#)CrYD{hlrEPHz>ZU2zvKQiLEFSs_8
z0pJHF=9)Jm`bvaSjW=5;Y=vsMKGdKZmgB-!QodOF3Jnk<*9-jU1WaRx(rykYNGct`
zms~^YOaSTk3uNo}OP)5N;c`Qc+{o?ZI1zLZy)!{?A~4ZQX>;0_DFFnS&CcMWE9v#M
z+0v^gzcFa8>_svp7om-(xUjj8Xr{DH2Hjzz6V!9GSAf6^?*nPqIN8#yOwh?S_VB3r
z95fIq<m+hGRZ*H1zOt<6+DpEk%a&GaT)NO`t=2Bq7m`-^HqMypf|E=5eobjR*3=_0
z9x#_P3T^BUoa=ebGNZn2&ez52m548$qeF$HbDE`Q=DB_fsAgk*npLMkX$pOzW5f~k
z5^iOA{>oIB<M#2FmjCazwtv&!Ai2?A>)ffRInnFC#Dyb$9r=<`+V@ePl4uK<$E8sQ
z0AXQT=M(V%-ROOT4IRn$vawD>or#=1pqGH?r8Fzd=S~XrW*|}M{+8RK*Eu5I<!ZGd
zI!BX(q+Q+e`eu44qASTf-(jsk9pA5SyR@Dsbb-Z3uAqf->xGm&h*U!#ugq~)w-XmQ
z7K53ZI?bjp%&?M)tA&<*Q3vs2aL#hi9`P+$T)I44{J%Q+%>;ckzT5Z6$L#L350uh;
zDz*?z8H+d%feC&Ph@^ezzrkjsR;X|`FGaPqtC?;V=%l`2TJD0VCYTqn-l4Rarz<Q3
z0({LC6=-({?NZCXSkEh8vsbAVF>)P0N7_Sw{{^U`_D;01Sy7r57IP`WTqymzCr2N0
ziyqg`W-CZ4e7n1?cHw9-Pwh@={WhxUH3&%J+&%fLz8~gA4A)5g`;6c^8>CW`>-JmU
zkCbMGC0ui15uiiHT)!VJlh51MgwPGqVWK(iMv?RtVX2vUO*jX{6HoSlCqDvHAEC6b
z>Z(fv0hU_U3}KiXe&7==|KDwml)Y|DWsn<<IeOgZR@wz!s5xs_&{7oFCae!A%?jUe
zVWs$Q(H_{hWWB+z-i_XD_1k<5oE+tX+|xT3wPx*m-rDCW%?isn97oRJ3H}S+-*Q{Z
z^^hWZu)&z4yeDa2w=4=tuR$bcfCmkMsgG0IOXu@~+_RiZBH<X|k9}D?`Af_HcWd)E
z_-wKOIXNwda^L3jP;;W!>!J%c5En!*rEUDZ?@v5Y-&)SJ^aH(lF{bIrLwm)goG;Lu
zdfCO|Ur%XP|N0eNK|#Qeu7y|<JQFPc->rSKpTpwyD!bU_7YMYbJ-3c$O0&XBu7V)g
zxWhhg|92StU1GFxIVvY59oDbC!XU};{XHx{ggyYty~4tledoAUmYCBw!4UiN1nXM8
zBKkeP*11KXoaTTeCs%GT2&OrJ(#H00v72YgY7QZ~d63+u`6gXYXr#`l1#|2(?|ltw
zh-Mv(IE96IkJ5f^`%qZru3_;t7}0g5w&T8uW<?~zFW80P#R9$lbzBkQjc;R0`~CQ>
ztBgi2*>bjR8un>L^NE)K?>6scdtPFs5*s!22s)9Y)+3j%wj|V?+IJ7=C7^Mh#IDT$
z)^c@)1q}I!<a(To(r>+&a0J{EkV-tz)wS|~(yXw~!h<Bc^WeRNBY;H0^T4Z~l?Rk&
zh4mc8Vj!@$o)d8?40$-wTh_GSfHopA7(8eWO!GUXS=T%%Tn5^oU=n1VP5h<h|GSO-
zH_mlF4fOVkqJ(qHQG24<RNs~B2~0FoTGU9D4-jAj7e<N>Kt?s3Il*6A{@aJ<m~fD6
zmvA%7QFEf#>l0V5JTTEqX|c0LO#}jL<mw7*y-8K`Ms5j>R2%FR_L2J*6cN1{fv(&}
zVa-BmW9zRQ0|eN_HFxH(q(7hj4LVx9&-gpEJ;@%LN{m^M#M(K?)#5WnX{UcXM$Hb`
z%pJxUCb)@yEv<g`O=CI1XeV;Hm7s%-<8W6l5*O63DeZPyH(H_szGJ@pbY;REhNVju
zz&I8cSI8nNyiE^B4%>M+i(Bf&YvERbI@a$Mt{mK_7(Xa&=!3D(dBV4FlZ1XRy?&n8
z!M~=T2TN3T@&#Qj&?}2}<(difQre6AzdhyY{hmt~WRtWCc^9KVV<&>w2=uzCUAapT
z+o``(+TNsMfAI8fwVV@@3Rz6r@eTcxS{43U`wlVK>!?sj9m0HObhX4Npfsz${x&XI
zXx}{Z*GD(k*efUlXd`<ejbUAaE9VbPvI(Wl-1)uGr+?s*DFYw@I2+kSYY0L7n~(&*
zM%eKcf}?8(EA<+sIs|)x4I!~~Xt_bJ2$Ab_bQz&mvnIuEas0hu3?tcI{>{`!iJTPB
zTMn4|G^NeI{qqDMz;?^|#?t#rWZfhGM*kSxfVZz*WN+F`fL9YYe2F!dKBblXQ7xDg
zc5nwV)(LcYi%;b*E&tzbE&68vm`L5*&XCBZ@Qs?M;6rUbbA(myqBJY)<a!DnI}GDH
zn?5e_dmA16J-)ZeHbnf`Gt!mYjtd$Cl-BM*kb&pPE-qbQ0_`J|dS1^qHZ$Jac#mmw
z+<TMDF0fIcH+76F7l3P`m(p6Si~WwLcQ+R-(CeO8^wPX;CwfU{ruI!6@5;{kCVDCD
z#-KP)p58rN5KRJr6zrXpwte5||H!-lsPtM*j8bEalj~LTaJ5~WAVJq=e251r6I|id
z%(pqERjW9z84zGE_kYBl3H(g;_y6zb^O;YmWQq{t60$@iYl+61vQ0_Ib|s|9*vir}
zgjCX`1+613T3tzYCZdw+TCyb#m8H-iTc!T5b7#(-bLZRp{=ScIefr-ApF8(H=e*zV
z^Ipz5@AqA%TDlJA{CjnfdZVp<Cuz#}6~xSpIyI^Gyts!X-O)*LY^(l%J@?!nPr&vo
z==(=LfQHoe!G{WI#j&UUPv_>n9-n|6w$)lS`U19p_1OR~kN%HdYjT#`w1v=-R5ef+
z6yQ)@(7Dd9HQ0(BwvV(D1!fEW@;>Up1$>*lwg_60Ij@Yh2MX8eUI{vv+15C}C9@xu
zQz8TGPyhTpo$sOU{eS%=)IZt_vZm|WVrWNwA&I^a#-92DovXKdM>^tLYp+}2l(zpL
zw~4Ctnt{Xd2Kxg09mFNjg>;Tg&cuFnF0*~CEu$}B^JAY515zjO_rLB7|JAh@+(P&N
z!3Hda9;9L%b<h%fYIi#4FZ;tt?67@eKTk=YCc_q-M<2xY_hSB(pZkw_JjFkK?<$ZB
zjLT4V(%1iRA?*t6Nnbj5UBlC_VTbKgjjprNrlY|xOnr3z{?~2p46y%eoo?h^cu)qv
z^ZhU0RPB^4wN|$r+EJZYsFNDlQ=QPcSuO87f*rPX&a<S2VKlK^>)QVLI_Y;iz4+z-
z=lvHeprPGQ9x0?9#%HP%I_Doyh{6VJpE<t)V4+S*rcOG4|M@z>npf}C)20KxUmIPZ
zeuAz)QN4tw6tb^vP`%K(iW`d3X>98?U)oU8?|&40Um0=xup#&SYnC%>=xA|hY%Bg)
z#(vVdv-S_$j2*VmwPoq+S;-3j^zRR<{3fj);rd;{yh;MIqm<6Ur!zX!xs1+VXrqdd
z?szv~MY{6g-u|A?Q0WYH=`w8r>AVUm*zNpMA?JMxbT0Egg)jg8cM!u*7St<hSEuz2
z%r4~IUrOgP_m^7QwsUa;o2k>vsC)Z+ZT#2w9~RW@r5~Z_)V9evnRQ<}H{$j8`lPhl
zpxt|R>eFQOXNni(_V;xC>w9U@wEg-N$lLNYZ4C-f`Uc*~+-E`OGWS_*)U2W@4R5dX
z@3ifp;r;q~-bVdDuJ5f)>l$2G$a!Zeof|i!V=Cy^HsObEQo449eWp2&-2PtMy4Un!
zxdsmTk6_pSVV?r|mCcW#2)W`UX^IA?_ZZT-l2<(W1a{aqYdzBKybX@pJ@@&$&x-!_
z7)Gxyh}-BeOG)+Vu$8{w0N1MMT;Cewwvncq_LUZ-PLGYAgUL^QbpHOmcK*xz1_uop
zP$%FOnEa1j8Z(rXu5svkF?6Bpa&+$LgLAi}6x!naHrGzfWzykTLF(GK-@rk=!&tf<
zIC5~kg3x(gTIa-uLK-e7+wnM^8?$0|dh~A9+N9ezikmBLceG7?D1i30?+Y!cmsWj-
zV%zF$#Qh}rOmQ}y>)&Wg`uh4d=Uv*1{w;kA@FiXA)B1*mzI5(T(_hGBVcV`%PPeZg
zeLC%qQwV<xq<!fZVgK(J{QR%O7&C)Z8z-PMZ8VPQTxQ#$^}rm8wofpJfZDDNI{$aq
z9{-E=r~V^`47$Q=;Qpht%FG({7tn~BHTG2@ja(7+b2_*G(KBfu^|cnMj}zDe)#wfK
z?yUgYy?1{M>X9P`4l0PL#Fr>O>1!S;q+NwQ=}YH2KJ(fz?6B?BMx`5?e#?ZeMau2(
z>8qMM(UVL=?&>{qME^!!ec*rW=@t|qo%O@%`$(WOo$FBUbwnMseWR62_wxXZJ6(^I
zTfyjT-{ac1u4kwJ9~DO7H{d_%96C}+D~Au%&UEhe@`FCa4%;qmCw+l7==^WYDSG3+
z&w{$obtBXub;3sr*=u2>FP-Z+Z_(S>Vf$9QJ>9SW`RnMaevL&CgrNoVi{={59BiGf
zV}<Nz7)WP2x8&Cyr$}R5Ww);((x-p^y^@N1doh&5eTMZ*t*m>li~Y}?n-;dHts}n_
z(iY<b=}qUXX**kBhi$hOOpoVAuwn0}PC9@8-gr)F_8-$IoGz$)9lt`!N#E$HLRu&6
zNnbjb_<cZny0}NXm+cp>E4~9Jx4)<Ff78wdai;+8)rJzb-e)rLNqT~jR_{B_qAy@e
z;(tNLC-!yWK6M&+xu*gOQ8c<3PHM(c4`^Py{psBGOA`s~uzj!TY30LZ|LOj&Xn)x9
z)JUM~qXje0Y2r+JC!qJG*i*l!b3GQcx)(caKREAE=nB36*?#|*_Xp5>1HHPy|7_E?
zLmSf7|3_vGkj`zqd)F=4VcV<4(tZ7(f49nC>YBP2q5!nr0c}W?0CeSNO6gqYnbLh)
z<zhI2&5sC;uJ6e0@7Xhzuf7Mj02j=U)qjn`+v{MMLy?)L-?pH0ncue9uhmPLI4y`+
z>;tJRKL0&^|C=>H`v-8nuj>7eJ$on0Pi-A9T3Bm?J&j>HSF*;-$FRe8K%0{8*Zz{J
zcMPV^r~dvu-PQN>4(>DJ_WphEDu^i-W)tcDeO_Vvz73jJ)47rJ{z$JC{iwa2w%0Au
zG5)Q!z}^D~hduA{_#fMNS6bg-vBFvudXc_#?zie~(rceTY3tLAfC&tMbaUeysqG(V
z<LsX_u-85dazXH06rEJM8V;GpG~LHV=Q7(ttwg$E+gzk+k7a=U=^xPfFMrDckEIMw
zz1h703^z)iz<=tx#{A50SkSrtuQXnS9kxTx{hKu3N?)Q&A^a^Uy=eisAT-{MGE;v|
zmM*OI#-8jKo$EN|v6|RnJFJD%WBFg3V~O{?6-4B<2U?NNp^FM@eXytTOy^dvvVW=u
zpMKU3(igCq*r(M`oxtC}*T#zZRqyl!s{k7LJCvE!i9_Ee*i#$RxlPgY9>xw^Qu{qU
zmQP{4|4VCPbs7{@Kmv`v$A4-!Q{0D5=Q7(7t!uiC=~<gMGQj@y_uAMUlX$+_58>MI
zA%pt$PTiee(6?t}Mv<zQn5Y*zm)VXw_U)hl9Wu|F7(Tq;6$P&UUMNb<?#By{&O!&F
zu}|mXKTl2D_hZ^1_G@RQd|#$+{_fcS%j=kp8q(<k829_qy6WW%+t({eS31{hZn?%O
zoqln~y#XhWf3EHCjRA$Ow+$Q~E&yHkqvRB?wBvXMa}YY0*^X<2(&POToTTr{?eFQT
znsfCJ<J|{+1{6pXPBV*CUykX8?KuXuFP+=nedwu_ZYP`=tuXrZKdbX!wr}b}M*+0&
zk7->4l?rS28X<J0bEht;UNxobN$vTxqyFcgmHkUy2lT_8#eMq~L~qu#pP&?}W4xcE
z`7tnq{!oz4mFnMlT1wwj_A}G;IfDNM(6)aaf74ADy+_c~V+GQy4?-6jrctzWDeNg$
zp>qd!Pn(Dxw$t|Y9{NPrxc)7@`wuIS*Hd9Ok<!<MzO=?m`qH^gvr43=7QbrY^rx=X
zQumetJKNv0TYuTF`-cngnmpa>P5rv-iX5#l_Vi9|I_H1vtn~f7ziEkdqf)>B7w$u#
zOVI^jv1k^NYTIz#!p`$wbgt?3t(Rek?RV`|+9yqh&gsRI6vE#EXxlJe9z3WZEEe@$
zQYBU&{TLspAJaKwYnfTtVLPJ*()QWHI@qJBlg{6NK-a&tSB)ALTxULl(v!~7hK04d
z*ptroxse;`QZ%+dG%FoT(z{rSrcOG4{{fxv8Zx5K;M*G1`;W_Y^qZIT=HP<p*hirO
z=^bfYSUZ9?CB5m~S7R@HE2Z3@+8p`<w%gIK&r5xD{{91c|Hpb5?jtIQZmrQGuB~g+
z!p{AzbnfTsSCvaEltcF)(AEZZQ2=e6tt+CA5q<iPD4476zd#RC$ArGE(00_ebnd}o
zZ_LFGTTV_etuL*G{tNb*^u>(^_{HJ^=*-7SBT}n*VGZup)|bw`H0GN6bQ<0&$B%g+
zZQDv{+8wEn&ffy)%e_b7?t%hPRXc%Fldg&D3Ty4Lr?#bYO<(E!CU)5Ja@Zej^Z$$Y
zc-p`5M-!!j&|1?@LNn4kbbVpxef4ziqr6k;C2e00ja_>?|6kIZ?)5BSy=f9idI#DT
zcCIhexk`n7t887h{2YE3KY=g)3uC!Iv>u*Tyg(ZJbXsQvI@g0v)W_-Es$W{|Pw9MC
zj+KrtyJCM~>ZJ1*<M|)E=M!&b$~;ln8^1jMf7tATy1(LAX!qxzDHZ?3MxXeY&!+Z&
z{kLta8#}aWhdcT30x7M<RXsw(h77=ua_FrGViKrVgPPTQ{NI<>2Gd)rdZgY@g|u)X
zhjRN3|EZ6j?uPX^>~(~UbS|?M$~jdzbCmt*y1`+*lkBPjE8_3Skn8HN>#lH4xwL=C
zE*t4pLvLrlluNInX|<NrK0@bcvwaQLFzEB6(;Hv~Iz3jg?~4D_Z?V&?>SZ6HJ;_D!
zzZw2B)4C3-gF~Aou<wEY%sStm+YW~|3qrV+V0Yhk@sG@+U;_l}_31Es8bbNeL`~**
z?l<`q3fO6ez^39e=l9b~mp{QQ0Y-^1`(Q>@M=lB0MX=2WJKe-`^d2CJ6-kcr-_(40
zCuRoNrZl7ByZ!dnq^?Ha3u2yF6(2~BSnnM@;Js2TjJTVo&&)Po)s2ROEf)dv3Aw>f
zKl?JXDB85TkgM_Z=a(^ygPCcDthI|S54L0$E|kfS*jBwyC1w$@(m0^95IfU$O9f^z
zu;PM^`?HSDEDlDtndLSu9eE=&Jfh<KP7kH|%SdwovxG;QH2J1Z$7$vtpZE#OVL8#c
zcbd{{^Z6RITB^<rFnVVR%UyG3`UlJ+C?wt1!ffad+Zr&7f~j<f0n|*((NJpB$VXjW
zqqeoc`e9FL5-Yp087*<zEQn5ajbNoN95R?$1dRJ2$(_G&>hsK^0M*m&PVD#NqwN(I
z$}f&j*J023bsD|wLzeR+xW7cOk@fRuF$;pV5bUu|v+4FGyPQ$5MuP1w{dGfT^c>(u
z!LB~%+3w6t42HIX^?l_y712(UD!QCt*VGAZVWxv|-zEL7YJK->%tBx_h1|Af&+E)0
zU<h#?-FHrYrVX<g7!3ffmm6;ET#A_mhOo(D!Mxm_%#vUO1*<({`zy>0jM8y}^=Y~0
z9%f0fF=>WwtQD?X{3m8%WHwl^T4(QhhFJoPzE9;uSJgfpebQk`Fz$mzz&;%J`x2JZ
zF38Bycch#jjOEaEv|49(qUzPCF?1nEok+?B1Vb~sSP%><+T|phcmIl_?Xk1d41wXF
z!+z?pg{s$PVUZ@PR=e~0yD7Y}Sp=*yK9la0c6fEkQOry*m^+(MVmI%v>DY<5VEE`_
z7ET1ya%7)gGgh9#&d$$|6I?IEZo4ryl$nkbTo&q6M}mhO9YR8m;x8#@2v#zSg~3Q?
z(vLddx*z)CYEN2supmA&tI+nm&CKFp4+>VI=#@j5g-|%|FO;TiKLd>QBPQ)`7>wJG
zm~6iYSOatpF3YHEKf8tVi$h^meiqoh_#(^A{B7_=mJ6XWYNr|bkV`H+e<`zw2Q$H_
z&r+IX@1K3P&;gc<gQ031)^kQA$t(dz4aRc(+upVTg2I;z)^oM}NRdV?0LC_%^84w*
zO>}6pFc|kiVzLiLz>uYr--ug}Zeh6?7~49M>k+C%!`DtT4%P&pxtwS1T04muIa{{7
zB)5I^^&^=D!MHw&JrMeZik2!TSUr5^H1BJEe=TMvm`aB@SZ5)3sKTapET><D-;G3Y
zLTQ%8$!29wKhBJvL*lVQdj4tkf1g<tC(5V$5_R^9M~;)YT}~4xxPKCp{WFde<bWtY
zVqH!T{t7!=E{1zB@y}t6%m4B<vpB$&g56MJ%v5IdVqUUioMs2#$`_dVv)Ht^KX{gz
zp2bdde)~yg0Wj`oRL*I|?(WMh1lAe{oZp5XCn_?FfjuCY@!5nE%yeDTCJ5Hzg(?p*
zGr^<|h34$0Dzxh*4mJv(Ils@FoT$buh@5$>P~FL~Vt_SH%MshNwA~Vxi-BD#*u9Y|
zN0?b)T?JdcWc*2Hfl6r4oK#sT%{$FoNF}?ResmVDGh%XV2Efn_Z5@cM{QkLV*x7O+
zFsZ}rStey~voIL`IdZEe72Clq20#@-^+IW$ns#-ZndOmY5{zvm$=%kn<}sF|7uP^V
zC(Vb-4PVDB07jjh^K0{N!_CY>U^30bJ%7By%*bNx;w^4u7S3W)E|SHhTog=IpC*{9
zJ}odbucJde+F&4;MXRc=>j0Rlt_?6%ei1NPFS4$qVC2`iK4<=X$Qhd^n5wQV50(V0
zlTH&uQHvbRpU3(I(BZj%5|i;@2#n$+DhsiZYZ6Y}V}QYRI&7iUei;rm3<E8amFB(?
zLmDuPf#u_X)0BS21nZe*I`*x1jQSQkJ54_-dQW<c5%V42OigVw`$b*&O!rh!JMu<l
zA$Chzj@Xntuh!`_F$2N%CD>D0sDBUKa@SMX*(?f1j*D3ZUlTGLHj8;M6ReDoTRt!K
zjx5U0@{mh-uq4>6BF$UJjHRw+m&HJ!&+SJ#oZs#`XN=Kryi>ce4!1s@-;m{EV8aFb
zqz4{g!$#%Q;X%<9j$Fmv3&t`Ff$<ol{1%OENL|vF3xmORI&z&VymS_`s0TB_IG&(1
z@1L>QU^y#`g@+|ET2uKY!6+VQ{dT_4%ISj?FmU`yX>M+L$pn`3gB2BWcRu-AE;AjB
zDv8rPXNdm}W(F8S7>DgnT(^{21gyDWv%Woh7BdTs65%wTT3_oJvmk;qj?bu^1J1jW
znnj~_2m`R4pniJ6iH2u0i-2v#0i{Xo=&4>WGcy92_9JF~`(}b!)Pu#rxbKo&*<dTD
z-4kGJmx!&|S8EZcNyg=N6qw60ZgtD*%)(cw(~N>4jCSN=J6jxNITMWX;WT|SzNp76
z0S1%iuqtgzI{n&T7w;+(?CW=4@4<3WFp66^%}c&%?X-~zc5a%%6>9p~UyNb7xCgU5
zSi*xP!HT8pjPeVXIQ|6Zr`2~e{fe)8GxNies>-Q*uz&{(g0Y>TvK(JN^bO9>0Ao8y
zOxnS)NRtMotg{Fh`$lT3%T6`S<1|e$Zg*m}x)fT+%mTwdyN!q$M=A13jR!wkxxHYc
z&GA1mGr+i<B)5F`vYVKN!PsUIn;z=9k69E9|D62fc((v}Y?7QDn>1OG`hDELI)(5W
znp6vbvHhfd{<%-z&ddO#_=@@<v7=L-qN=dvB4B8GhrPLNc`s&hu;PMU^!+t`nI*ue
ze4OUn7Z(1LnI97bU9ban#!g}u0AqViWqE(yU8k6Zve<$fV&^amgRz|;xof*tGMPoe
zFb#6bvUGSYi<t=~bzk&lHzz*}j2sE;a7pv9Q)fxAiv)XV{(;vxP5)JycBit)cGtmL
z3%S`^tCB1i_F!=j=5LH=T}7JbO#kp_PSfyUCRhg{xB7!GTCp7cz?&+~5SU7bm<LOG
zuwWB)eo+sW08{A@XsS*#0#-xlet1Cn&aAr$c7b5huUKGkEl!`fe{aA0S<ZiryDy!d
zeBN4S0Wj5A34zHmR{Ev6B&N~0je^N?-gl~LCuVW5n)nj;&&|o4Hq4SicOR5Ck}k?T
zgfFsO`{p?hvRo8wf?$hRu5tXPj$lHLha<HvI>B;5FftmPru3TznAH9AqUSnsK?JP4
zkTawG6P#uY>|wz=BqBa$ffku{Xc}W{pX+`vGXt!hkn47){{zfSFoZr%IhQT^{Cj4J
zEH=DGzZJ~<Ei-Wz<#+$WZqt|rz@&bys@9vrECf~&2V5_;{B1`ui-5t5IBb09xlWpK
zFj+5Od~@a=mP>%C`X^neD<#sD<<!Ac<qU$U(lo#-<z>n_`qs_IxGYihxb7mq<>gNf
zW0nMKE7;Yau11ed_3PkunV5m<Gj{%O&oK*SvEMtc{fe0ZCdbP30mf=(F))PRPJR9{
zXZAW~7MSe2eVgY+nI*wK6mp#&>gKdx97d2jIk#WQuhy?;xj2-QX|CAU^a^GPu$Yi5
zy7ob;CM^g5Bj}uC@qyEP{*4_sFe788Vv&w&rXdBT+>L5RKWeFz>x?@PMZ52u_lIqm
zY#q8G9`t2&xZuxWH2iJ-qCN4BmD~(#G#NKjq*=(oH8R1jTGs9|X8yhyw<66q+pa+_
zsWgoNSc4R7d|vk_nZ@sPm$Tunmd;p-4{?_>)T(R?ma~Ry+6)|UJB+C~?>=T>1ni`c
z!{%NzlUWo@j<M1m<L@&w!Ac9c$3y2<WM+Yl6>MFNk*_lgjm)fj(|D-xdsjy;3ig4J
z8~6Kd=s~G^3El0Evzo2>?lEQ&Fe(`9(691+sNs}c5H&PVut>Q-DGQC-)&%P$SUq2z
ziOl@4Ub0@KoezLf<#K+jr@#I%%SFJ73HJ7a-3ypSJy;B^vXHA4I~8O(D~mOqu+V7-
zZL~T+e-<n8;X!BI>RC*dGmyokToCMBQO@?0UwDSg8OmaEPC`$Ns_HWWCVf@M^Y0qW
zX_{c$#5j7~`syxbQFy|YqAW{q`t%615PEn>u*$UuO=lJZtAP%{?f2ZR#cpC|A<BUp
zaM-cOrc$x({-VRX&JwJ|feV^4v%r=JHgWDGr%yy9ne`s(^M&dx4q|7g=^vLBUw62_
zG_wF$KOAs5i*;%7JhK?s-n<N3{pg|N%%bSU9|`uxjN(O@87P%%Oh>?EoYga@+>b10
zK0;4)XYw2N&9CJ0Y#m~crk=y$ayI$qAZjtiqEj;K*QEQZPS@rzi-WBbZTsWHcNJw8
zecT;SoM=?Tsp~kHN{0kkeI&wV`EL7c$A;+egi`K>XKo(I`319>v~>npO_64c24l`*
zxhNRl=Rx}QuHIt@Gjkf&JfJO?rR&i~)V1t7vtZRP$7g0gd|lP)XWCQln5e?ej!(0k
z4yFsa1AEpKVip8@K`_1KYp*g(fYlQ$C$i*xW;#-rV_J^efCmeLT`1C&HqrpQK<Iw{
z%=HvP*t$nxF{m+F_v_xv|BYE3j0QimF}I($n^^!O_*uak-tp}aW)_$%%NXIul3=pk
zW!w5^sQp*~Oy$Q+FbeXxoab&zy<Q9|Ye}%hf{mKjuM(HjoT>I>39$Etob+QcC{D_9
zeh2EVK8MrvKd1I%VK7-QvW=o(DnFJ0D<<-j{vqkXG*~E=9}8qL>BkH(Res?tCjC()
zi^+0EvzU~Nfyq8E{g|1><amgKsp>NUrt)L->&x^GWNyFir?>6o_DjB`_G4zu?Z+Bk
zb|Mo)&vN(O9?gd6oTd&&#)k8gek=@ze-8U@)g&5LS`M9i+3m+HbJ91=5?}}=9l7Sq
zcYn*wn636>5wLzjZcqNSK`fU9lYZ=;*%RJjmUtca>E&heo8F;HHHW>W9@F%|XIUu2
zx_^DJ?l6|qk@_JVFe_5$+-sTn-*x-3YS&y_ftfZpbDtI2`BU>ha%^h^>`T$M59BU5
z&T^sm)P5`irm{;hu=+@Z%PIX>B1=yCF?wmKDoq_s<;Ox`DnAxpfW9H>^IG%nH(9?3
zqUp;;Ii(*n!O9CJ{g?%&3nu+o5={EBdq3VxLsg^x8C|IMV-}bk({kJ<JXjL!LQxiJ
zBmIliek=eZukvGIFqI!mfT4>zZF}wYvz&QjbctJs{oOz8iLcta$Fi8z&jeHHV1cRZ
z68&I?D!xuESKFo73b$R7@pTeR6<_Od54!|53%YWjm+`g!q1!IW_&Nb5?UIbIja43Y
z2~6508DA&Cq+OEnbporMs`%PmryhS6m@2-eA3>FNNygVnu%AS|$oM+(xjMe~f1!@A
z6PDU8`8TL_2!N^VQaDRa+NEd~lQEbHrm{;3FqK`x&qgTYYyB&=T?&Dz>{1v^7j-S|
zQWQ+uB^h4_wy5n=7))iCA|5OXcA+SXv`Z$KD!#V1s_l}0o7yf#z*KfAu-&bLv`fJ(
zChbxPOr=8@Ol6m1V5)d2g2-v5s24f!4}RmeOEO-Hf|V9>GF~#lRPhpCk?pceGF~#l
zU|t=YCF7+qq9bXSWW1CFyGY2rB<B78gxfC3cqsxV?UIa_!r!aorSN|Bn2v&};wAHd
z+b+p?DfXk=F3ET)3WGI9=qKYP|3P)UlsN2Rmws035CE$$@{{pWI7`lDm$I14E`cfS
z5}4919aYCm{$pyp6a-V*B?C+s`boPK0h4w~#!LDyYP&=aEUWBN*n>sDRAV{@rm{=%
z<7&G^7avsdQW)%6q5JV)UJBz-%fWyDN!ToW;FzJ;xr3Z|K7K0md=ACz$3Cfh1<T>}
zDB2@J?(D|#UztVmNwP9+&w7BF{(I(GC`$9s<0a-X3!K6AcpPw91{`{y%$r@#2v}t?
zN7y#Ck29As|8$r0+Ugzqvs@BPw$a4x)13S$Wfk*#Fx`U%JXkP`)qLx$hFs2&2Q#u*
zgEqZ)vs@VL5>YQ3ewuzivsiA9_8ktmK8?>Ve~no*FGtx2O)!;TNr0*1-S}BKO1}~*
zl%rfvw!l>Ju2v*R=~qHvvxI&!-lZ2JFA+?}yK%7Lg2{L{cutPeuNYvec-I1xenrN+
zaojAWig%;MbCmN<6HFEFCQ9Te<6Y~*9A&&4FPY=q4^87wt|uqKRO`v{i*j7or{#Kb
z60DS{Pw4~vWpb2$B?Knrq+bbVF_~r*OyyVNU@E_ozzZ}~>&f)+!{tH;IS&tjsr*U^
zOc!#}uY|#*Uy<>yze0|3Jvjs>?UIZK4G$IuQ~8xBnDi@^ZXMVe#fJ63bv!*sIS)^Q
zsr-sjF-PfFv`RTjzhYjJ<2?77?N^du(swNXzVvD?XQYaoz4O$r*3A5u;yt=hhHc%7
zwI6)VOvlRyRDLB4CjH9T+Eco*Tnt9(DjaZ{(yt`IWE)AplJsCSpjC2y52kytKo*mJ
zCFsFISxovB15Emr_Umfj%k>him1Do(lk26d_D~0Ak=p7$7z0!J6$?x?Uoq>b{Yv->
zw_lO-l{lDczLEe_%~t|--F`*RR}x^-ugLjI3@?I^enrk#^!jSQ5(JZeMb1}DFzHw1
zd?j{ej&glB*2HaFrTvV9spcz*rf$C?=PTAVZoeYuEAe2Ca=sF5mZMzX^|w^}l^~e(
z4^jsMtiBkVa=sGFl9PTVp2cLE2{4sk@wZa@l>jcu<_Oy(*LQ<$)P5xlrt&LMFkR>;
z{fY@D{feBggsxNjl_;3BJ<_klJeUcl@+%gY%C97^SNoMfTeV+_ft3-u%X|6bU@r=`
z^0LgcJ4U-4?Qy|w_~7*OIMm3;CBZNiaBTTy7rp$g!`kO4uTzFQsCAEmwGe5_`&bfS
z#RQYr)sh}e>j-}&<m7!Ufh^{_{s*SYFPz2Xb-YLxljV$NF)0@VlYPl`{V$8jeijE)
z^`!)u%0Ku+>Ul@<Mzw!1JGuRXTxZvAQqMaAoz?y!0yayuk(_q~Zg%?zIqyh<N&g_{
z9pNr&{}2U}{z0y@)62!Be~|NzWOwzvBi>tWTN7Y#|IS#E_p$i<xc!4%XV-3Z`v<ws
zo&>8T>P*f%^uFqON3x&VKj{6{It0N~{vnbjC;dY#i%I_w2UGcnB$#U6;UB1;cLeTG
z`v(I|<sTwox~Na-A7WtAKgfAU@J_XVh=9p4Eyr!tgT=s9V>%9|vgHXdl`W6pCE8C2
z{U&xP;;dQegWa+I<_=Rg;;Xiu58S1;<tCV_oEDhMmg_^*wl(0vf?z6J9?oLYmd8BO
zG_#nr$?+^EZMl`jq+9|_w!5_D$t))O1pNTFsy=lvl`Ri}sbc-WaJ4N@f`vq%kg<Mn
zggVwYz*Mom2_|j1jP;F?Zd)#6ef@5?Etj!=3`})xA`T{Pxs3G#_qc7jjP>=g>R4ZY
zz{3uLsbYO2;<n{7)(?$y+j1G}2gj>p{WzHFUXJKQwJnc>sbc*En97#xliYIBmIt$#
zwB-hv%9cmLRJPoltd8~L536l?5=>>w{g0?^c>qk>avAGeVD-d!koP3|A9asuIc{|i
z764O?=@6LeKL60;u#vt@%pmXcH=fMV=)wW77woJw^dTJD_BsY8+oAdJpPcm`3#^2Y
z8{XmWxh$8=Vyg#~oW{)m6xN=EoV-6I4km4#ybfz+F<EB`Fjc*1Ppj9#VqmK4E1~J`
z^(A?IB?^Y-b?QuBU(si}nY_MYKI`_4^7=~rIrTc2|9SU1n7qCce9>J_xegWqll3Xr
z!J-~4=D|!47WZIQ7L)5>2@jUcVsaf!d&#{HCa<pqW~r~Q=r61LOAt)u8^d6#>novG
z)xOdHn%g(Zd5!^AL-Zwizkc*}wQo#-N#7{vIng<8-zeufp*P&VQO<KLFqLmif=S;f
z=Q+lkZr>>9IiYve^Bny>w||g6AP81d)Qg<wgy*|`qnzi^Z)N->?2DY|gchjhIT0|`
z^_9>fwQr1oseEG$OywIBS#r`h(hokX($vAEO_ulThrm?6F}zeg&xtNm`^Gq!$~Pv!
zbWzuGo}(>y`$jp>iGitnV**UtENSPH9!y)I9@9FQ%I8>MGC%2a5?Rbu7LWY=E7d;7
z1XKAO<3qPCmp&&3CVh^)_7Yg_X7bug{3Ex|k=I_VHEN%uuXXzzdF>_iiMyQA=S0C|
zeM+Ab^I)b2i+eE3gC(+<^f^fnrhV$xLHZm&nCjX~@H6$bm%w^;{|tetd`<*RH6Js+
zRQnv=a{C-P9}9!2uDwLTRP(U}nDjYvJ{H~J_BnDs7TW0cIdVQ`fhm0snDjYvK4xrk
z`y4qR3vE@;$3kDLZEF~;tnfMV-umcHx6hIDvB)=WpCjjE;a%$aSQ1P%AB*o+`<x`0
z%0Kw`sC`ZdOv*{06V77N7e~QVJ|_;Q@;Qm`)$_6B4{D#I?^XMpAehSM7+|XTn6^*t
zbAn*fW=T6A@?Zv-YTgk68!CL`8~b(4z*6%nZNHjDz~uO=TBLAAma{yVen6dO%!BDa
zx^2(&X4`6TejyJQ0aKRKgXurzXxAYFo^PHS-kvVm+VjmYn2eWBA3pA^E1F>Cgj~6g
z-*)aVu)rz^R{EMBp5`=@9&-MJYPkTI)NjRzSzS2I2$-szaWIvB{zK|C4Y2OQ_I$kU
z$tO9#_~9J;H*~npe(YJSJ+r`3HH#frGymxv4Y#;D?O@J};ZC)5|NPZGRu*2nz7ew^
znAE+!IrR}{5wHnDhpvsgZeZsBJ;(JPiN|-9a_)CCz%IlWSwDF%cmzyUFNrfbu4n4c
zZT-hnoL}q@wH&?FzNE<S&>siMyxDzF2kRzu7*X$&b<83;x!P@cnR4!2`plcml0G#v
z3agoQPOdgy<ahV*Jet1PWig7X%Mw2?SGy12<2w83oVk9M3l>w$#r(PS+D%7pOuwm4
z+gf1sTTPs%>}Nq3c@;BDshM6jS8FcvyLfi}8C=dVn5rx>4`z8Vt(>~9!xhvlQAy20
zRn<Dgz*IU|9!$G5SJ|(PYU=v5YN}cAay2ur$W@NbU_EtNV)fNbYpCvLMk957T8-5#
zc#WEw&DCQi*iv1VSSvNtu2r{R08G{AW7n&hzk`}ZZcz6n3ry9Qv>Vkd;K2+qmCdp`
zt68v{nwdS+I%qvT%IU!jFjZY!hMEO$Q!{gbx-1DWRlS7nRI~V9Y8Du#&d&hrA?$pt
zTk%)e4#tP)Dt)RpBG-A(EZvWJ{u+})os@qV>F(Fp_dc7tkImwD=epkAH@w{mx}0mX
zqzBXQaqH0XymnhzE(E61!5pP7r+<vPoZ+$Ra>hKE1t!OeET?v_JI$5zD>%=f2EZ<d
zLhR#a9KG1_M@ANV>(Bynv38wB!FmX}6_cv{#w?kY-`<NqrqJJ()9-WVH@f3dTKckC
zD2rVmy2Xi?B49GVR%^$%WVr-bRUEJmQa}Iw?);>F!7L{A3xmo0q<$8d%unj4J>bqy
z>KDjjQa=Ms<|p-wgXu!QRocpxj_z5k#@RKT_(hB4y58m0enh9fET@B&6KPJEdX>|!
zgC25*hg<|~f=KiF>t{GIw11qsECDc8SwbFiVGp?|n5r!Lcy(EVV5+hh9&!;6xfqzL
zEP)5rWeI_)$`baFi+aeJV5+hNC#cI}fT_w7@sNvo$i=}_WeH7Gmn96QDofNu&h(J8
zz*J>1Cgm#EBcoudYhdArbCu5+1s=(D-5(;afknV-2;V5Lftioyy5`~XT_4(%T-SP}
zyar~1$$P=&HL&nwxypO}l3=R!NdMGa*LtM91{MKR-Rl>gmaBZmDELgSYfVnByBT0L
zMZL&tVA1Kh%4dusFhewnWd9(qfrV%0YN~tvVqmIkVBzO;wTdE5`HWEvOs*?R9pYee
zy+GazuD#%vlk1Us7L#cP!Bp#!VKCKtWb~z6<ugWR%<aeIGe!w8)ip3}mfKg!YhXH<
zT#uC3z~W%4Yhc>TxytoOzX#L7RO=`~Fx54NFxXCbF77Y#{XL;q)nnTKntM#kYYYZh
zY0+Qg^XL(<R)WbfZGp`aOkQJ%yzU;;@)|>Mj(beYYYcHP)tF9z^%MEYYYd?`++$i^
zV+g*Jt9-sAIM3a$W#2WxRM!|H@43gcyv7io?;g|g8iVnEuJZYg1eod?gSk*WrW0VQ
zF|939kLe(ol#^rH$YQcyB4Da9ZGx%Bw1t<H<_H@ppYKR4RgY=^GWD1afa#)7$T1xP
zlVe)m^OXcsjp@L0^_UKNun?GPOozebn3ikzF%M>e$@_knoMjz>y7rtT306nwUi+#|
zglraAk?Z_+0?kF=EI)QHGXrcY4%mjwnDp=$%#vW230CWY8#^%5SLSN33-;Qw%boWY
zT3{ClCg0(m1e0TW;jjZ_ZtQaU<GI=uVjXi~gV+tsLaWufhrv|3n_!oSvPj(%U@G0i
zALTl~!$@@&JNu=ZxGXU+sr!g8PCL)dht{Zd4}+<6kAl?_y4S2*^%l-A{)xK}P91g2
z@60SP)tYz`>{c<xYF|0;ES576Fi7@RWj{UYVz-0!S*~UXxwkuC_B6A==We-UuN>XR
zEcQjN)?3K6dG%X*G{a6)v)pOEP^65*j16vf`^h()d1HK|n(3Q!wS!2X`)>8|3-H#E
zbYJ=^SEIqf>_~|L(;c=Y*ZF-lYTKn(midZV5=_c%FTcXMPLkZ}mfIBD-;m|3ZEiW^
zn`KQMwmnzdjRP*rjPJkh$}GOa-6tA%ddO+p1em<ODcd~>rfPTp*X}hId95G_rb;se
zrb;vHAr}ENM7u9Iaph3fFR|0j0zb_d#VoihSL-F@?${G~pIPi%x7_V_j&bf&)pqA<
zJ%wDGLQ__=oUzB9X7?2z+{i5cotvGi)|RGc8j{lVAJi<eH&>&M#qIa)g*)c6TzFru
zW(l^c$H+p=g8SWaMNYmEXBIf%maA9o)%%%gKf2|{>>3$mmIT{^11`%AA5@7kvwl*y
zZ30ZLyU9M`Kd6?|!Bl-B2qyhQzb|&*%Vh~?vBaj}NM<px8aQAbcHDX8LS|N$+@ek|
zzsyWK<hIF$n|E|<WB^R2`Bt-^saZ5?TLX*?H0Sr(*cQc^MLk#?OxglzL*j?swm{mD
z*w1b`X+vW85$)}wEYgNVj=1Hd4T&68+mP@v_d0{T#vb)xCYY-I5?M^PpZ^zkUCZ_h
zg2^;x`-Q=(3*BY=#j?_r?Pr0h+D|*KW&tqOxYbX%$DbUxNiZoV$8F-ITTYH!^ORdo
zj@#I2^|+1vs&2m+n95$8VA6+6|E~Y;X41b$&$w-?^zX?(+;Y;t8(N;yzsGa(Ts}bh
zcRkO|q<@e2)GU#oryPHYv+`WyNRGdFA-9|yfAPX@IXV7fMci_7{Kd}BQ~L1eIeE%9
zih-%@uH_+@08`mr?Ob(!elSD$M(K;gMcqvLV(Yv-r7sTn-Ez_wN6*hw`r_mT?lh$@
z4wY~->5I(^)y!Wi&owrsFV;%uDSfd8rW(`ni`;T@Oh?PO<>Z)-l+9E6Vxye8jly86
zJ`wYfGr?4S!UB_aSNdY@VmFhvJOC#BrnKcomYlTZQ81M)k7uPRZFv$*Wy|&QY8C=h
z`QlIo_n4NpAfUVDq%8<kbjwLw;IHJCleWNriP{!umGfL{{?ZrgV5&9>Wii=C5inI7
znOSnOjS^t0Hu6_-rzzVg2&QVIum_8Q$uTC!X0)n%j7fiMT<VsS{x($2EhopOUfnGx
z$ELrAdTb`aDDdZaP_~i3rn}u`%;&$%-CtxsOM=P%Df?Lx6MI$6XVrGg$$n;CuI^{?
zfLezHn5rGDI_~<E?GVG_i<Fb?5XBFm%XyA$2cw=_PPRj+zPcR(4b(b>z)FcWda}Zv
zqBykU`LG9zf?X`+^cU)X%yOm&v%pmMu>`MDGqZ`B>CM!3J_L4~SnrYdB*t5+S)h%Y
z#oDU#v%orwdbuXNi7q4B^%-dA_A5QNP9ZmAvycZ1gQ?mmnk6Ui)ilB6I+$GZusm22
ztO3f!<F-%htDJdUpuI<5@?haC_V(fRV_Em82Q$G`{mjaellCPErn=|Z-$AWIz=MUr
zr0tP5E7Z|#d!)?@gxqq{W(96=%ej2xjcz$<v;3XZHcPunt)C7iZIARF{?2aOBW+d!
zOv*`{W!>zSlQt{X#VsdoR<x_yW`(<{b%=tMNcYcb*q0h};Q{VTCK!(uVzuv_H-?#&
z#a8ZUxRF`XgZXc9r@7X=-dP6=fL(}0Xsl3vOV+n`*1AGj?8xXcnROemCPJ=h{%)r%
zCKxRebDG6VmU$J2ww;KB@pT}|@3x1pn#?Q-Rs;tuCx4Sw>z;{|NlrfN<p-N6<R+}&
zLSeI=Ukq%CV7bL(4l{b>IoC-jP5G{?2$-xFdCz(bjIUdeoV;!k2dgXcTT=Oo-8i(%
zqV>#kewUl%?u$Org_$2r<~MfG=)TMXVAtY+>*dKYPyEg-0(O;P7g_mbnZ?1_eo}t9
zn;&pk0!;QZ`J3cguRP}-I+ByWUmO5?PvrM~?fqLgza$vnKS*+c3r_537BVt1EwNR1
z+Ltu#dWnG1Io419Cb9{}@4%$*$lp}b`{X(IgAtSWg9X7jb|WV52Qxh6A|7%vuzN%~
zZ!Gn`)0gyHGkuq0Y1wxJV0?c8v6HPXcGiVMVC0-gcVhDQnZsawEt1#|zMGq2XV;m(
zuUl@;`PO;N0$^O9Bv)p2_m0dAu*&IqKe6%ezUcJ9C<2X5ILBq#ebs^SEEn#VrwtSA
z`{h%AVU`4|CekeXXoo+U=>zgK>a3h*r(ub=9EL!uW%|AZDoca;h2Lcsz9Uatk)M&f
zyWYiZm<7Ul&TqAo+_#C-H011hF~Q!%XU?zb!;jQsW(-9+MSk&h_d54@Mu+EVzl!|6
zYu>~ex6#pg+TwH!M)`Fc`b1$)Gjv~`c9SoY-^H88*Jfsp%lLkhyWwlYNz($O3z}R`
z`P<@2uu6jICcT|IrJp`N&v~B*rCB|6rWG>-><%1onoq5-b&Qz>#^Z?O<TwgGn6ZPz
zq#ZQC*e(&1b}#~V3C?kTz8POQb!~$2J*6a9rA^6(*lFk{S^|vcsl?>(I{PQ6^9z8n
z-6c6`cSB&Z&dzINt;JXD{32jw@R`dg^^1Y2>cv0N-F{EK_3WLTW&li;W(Z7`W*n@!
zD9g~1W$JU9{z(}-Px{?F@3I&(15A})1WeUNF)&pdSzxL*(jHQ`Q2<PpUkFUqMqx0O
z4pEOZO)!-X2{4ro{>f?`f?z5g3^0`r5wN$>DBPE7ubSYD>A=Hz&byqc{p4>0hQat=
zKVpxJss1pxZR`=XTmnqhmqL$b<_MJLtTV%3<ut=!%DM)V^{Kr${u-8xgHeZM{UX6=
z9y4u9p7V?!<@fa9p`S4efsuh`x#Od6q-N1*yvM-S3pQtE&#Re*AIsBL3AVBBxsHDb
zPDMG90H@ip=L<a@xySRgn}yt^)7~|iSzws5IC29=jBm$Ge=<)C3c1IN44}};E~f!@
zmtbQzSKQ0Y0_!eVc=2oNm<66f+#}e|%}aYRi-O%K*ti$^IrcgUcClcWeA9Xs%lV&H
zvw#N+fl-jhbtYq?Fc`-~)P6E1ih9VI9&#2K$3&E-jEO?ec$5W9Sr!jD(?iYzQ<i1A
zM_Is>W$}<RJ>)DfWm#r;lm$##77sboL(T$ImStw1R#fztwnLZCz+q}UfT`pXU>vuS
zFPCwv_N<!eU_3V@IXO2Bc(5SYLVTb4HOVcT{NVuX>~d<)W#)#&rhiwq8#6yxAsn#W
zv@?GcVWwxvHQ6+IGP8gO3uZCb`vg3g0ai+srS-1<RQ0wF5f2svqo9&?*fOHl5|*>T
zNFiq1CfT<-*=Z)g*auL($hb#)KI8w0$+%7jWB))*#&sbu_P4}jTo(bOb6ge~*O?yq
zSzzpMNnXZvNif_J=A`*i(F2a1kH6$*kI$Up%yXhIXY41XDQ&9>#%pWDE?f67xe~k1
zEHI7>h%N8b@e5{2urX=BLhJ|qerKK&eobB1Q81aNtZNfYRo4kHRbBgESJznp%#ZSM
zJIHm0AXrPmau(mdk@bs$srriv#=eSlUw`V5(+(Dx)X!CCU@*&0S$5Bzy3Wb(Esy-b
zWSX+hEHG7_X>Y6REC8nJXCW|Eof%-NIy1pkb!LIdI+J}c>B0Q(<T=0bP!p9kWo4IL
zTxZ(5nOK9a5tg}P-3n#~SVJ68yAzvJx&8)bF)*4WGaGo*o-xc4U_2Kkx!fMpA7Q4=
zRWluoeFw=&-w^;~TSrW;FNKJu$276VUG8wMF@)!3+Ll<)$t7>WPP5}kuxj|sI>>b*
z3yj-=<fN@jf^lCWCi{~AJ$HW6)&;?M{E?irbzv}-eo?T?MLFgAS=@sq!8q2Z{Nx<n
zn4hQNRbP(oFAT0w316}6C9puPdk9QbXAv+}en~LyyHpn0cl{rz^$UV={7G^${xrZi
zwjn0t&xnUy%tI~?MxBTIgnULbv`}4^Fqo<=Q4cxOL(T$ImBm<;iBW2yyfQ`!d$5QH
zi+Zpa*!k&tq5K+NIP^*E?EVt>U<r>jlOBu~$eN4%Uai>0@hc%P_P11)QH9SU7h;zs
z492#c*bB3h^O?oKsGm^V602ghbYeFPEFf6XnvD}UwA0j<WNa46$+a~djBO;bbB6fu
zU^&A>F5)2<2UFE`!h>l`-F-sFk$w-Rd$5293uZCd2SZ>SCsV!1IN1O@gLB*tJ9B;~
zcVXAHvCM-l&%}e2rtxXn+gUCOb{`Hn&1*}S?7+;wLM;~rQ_01_+KM#q9=l<#ljce_
zGr;-?xj8R9^B&7t9xNEo#O0*l<~Enp?HhKzggsac>|A`0b(ig6g30k9{ZRsJQrZVl
zenq?Mb)5WGx$8{E-Z3!te<UaUUmQ$T77L7hD#^Kgsz;js)oLArVC+*VO_xsvBg4S;
z;?e<3sRJ0tb(E%@KP12&7Iikd_;17Ul~fz8@yHKMnIBjuk>(%AzNDogJ5Bv#H@mIl
z)?>^fpJaS0l~elE7+6o7W8K5gJ~5N!v`^h-k@2+-R#C|9`RIyESuO-d3sIcr)O+v!
zn3?I3rsa{Qwl3pSNryJu|H$a>!Gd74@I_^zxol*`bKh`TqF|i`E1DSStVbrnDyJF6
zRO>2#{2R;ZpW!-sI*uf!wX1anv*71>+Vwb~{D>WWyw``!qF~(T$%n{!e+;ZxT8@}p
zpD@Ajx;Z;dV)tMD>Tc{boYG=n=4n)D%8%IVR~rvvXR`zt-;YA9Z)}94pKf71h%}!)
zbilc;7TS=f%}?t`1AWGohp*!_{hKrE(8L<mdS?i;IM|Cgpt2B~SuGM_W_*>YGh%B7
z&l$@svNhv3iAld111pYmoTgmwiG#77pa$4ccdK(vI05!tT8>!%oiiI@XV*()TP8nZ
zuKd6r$2rQcF7_KsmVX92TQ0CY6MquB@_OSTW(F9KTVmtKuX>7E1dL;0Vkhp~*^-$F
zMiof;(M7Cg3yhP@^c|Ud7KjC6TlX;wfla}Iu7!;H*bh5i*<h9cYe5WYQv2U<Pn&Jb
z0$*p!Lag#{fp?i1VC8YZawiX#aQtQjtV_DTkleI8H#+O(iJh=LLay3V?PqYB!EfBG
zZ|T~vFpGh)O{O%*uDs!OW)>LVLqP2A-zqI;mIUKD5V4t+_LpVm-<7!@M=Y{DbR)AM
z7zGfl-^%Zwo5sulD=ygVS!P#e5wMDa#iI=dGBd&0PEdZUCKcPkECI&tPVCgQtK-c4
z->UNqfcf!7F6V76YaU~{AQ&mjtj)U(H#0N9N~9UZnqQqru4fhjBl|~k#O5C^<BVGq
zjO|h*`p(&3jA6OB2eY!6v}Xx0?n{(rsV##keA3W`a3R*6pOo{1spJA+<I{bR(kxcK
zsuP#Tcjsw02$o+yaT{et`RU)~X;0H0x|7`DLao|iXR|n18zEP5%4^G*`G3e<A0s*6
z<F7d5Jp{(_l3kXDZFaF-1guuteiD1;fyc;Y+4-6K^0Yez8~OhE)a`7h|Cs0ewkpZh
zeCdkUn8m@Wh;lw~de%M6l0Rka1j)6#_)_X_sWcC&>oW*8NTgXkvZxEonTPT;8sJ=K
zquQN(lbLZiGae|v+rD{oD6=RS-{(PW*r?jWnZ<w3)9?yqC(Yu44H0IsBbW!|Wmw+p
zvrjWKf5CkaIN-7zxoYKnX5r(RdrB$4$c`aDF^hp!7jpORTH(~01r`?U%~R(-!*anB
zu=Apvp{C;<pBg@yxzB_0E3|K|kLC1JnfWHMjXy8`kXaCnV`yTlR(!XdnRPl(dkF`u
zU)jfwIO8w;Yo101n%Rp_)?UeS`fnMZLuo$v$?t2K1;N-(5UW-6Pz7cN*a#eOn!P{%
ztU0p;SYyGiTYsnzGyV5G?MuN%jyk-RSrUwG9p(2!TR)j14b`aWXEL^qSciMc6=D_y
z>qy^8kInu&OSNPc1-nwPhx@g6;uj07s9+5qUiur$C9>GQ^P0TKED1&#aDJPPmw1m^
z@DDe8;U23KvnW^v(I?KE`b@@t{^{;#`zCM5lm(0ePR{S=Ymz58&A8^%?ht*xYW`*I
znFV}4Eh6O3I``s5%uKMk`I$67Kf3iSX2#h*t+inH-Ta1QvrPP04>=1iORrbj&S1Hy
z->2Oo%2Idvm5z@~7WZi*h3+F;+_Zw_!Wa6qzCy0uf#f615~Y1kAEb8d->%V7X4*wQ
ztw>sqSkJNJRx$IJ^J$ObfMT1guz&ExnfsZ=z<Luyf1!TbdBQg|b<?PyX&3vPK1giJ
z)s^ScX<`Ae)!4IK{n4L&#Y`*j)6NrY#meuUcJPB;A=n?grf*`o5Li9Io+$F!cxF+s
zn+0pUaI_<r1S=)jum<yYvYfwyPrF*MRa>_un1!;~qMRuaW>K)cIAHy@6kBqJSw#0~
zhG1Rm^qkHt0oFvY<2zcHWu{m3IqP6lpEJLIJi;slRt^W8U*(RMQ8n3h9R{l?*d3GS
zI(|9^R#mX@nqKQz&H|%(3a9z%`hKr6(<=G2W`Zr>V6<fx0>e-FIdVI`X?i`g_$5B)
zHw8(DCXbeK#;sA==h#+a^G~+_jph7ReA>%6;IeGE?S3aNh=c7B?A{BfuVgv1s?T}X
z2c@|+r^j>5l3;8ji8U`0r!HyNnSQCePh8nML|ND@2&UsRm*vFVx|EE~j4Zj{-)tn)
zZnFp&jUSfF$xpn^EDpxLk;?L1*UHpnwp=nxZtz|Eo%Rb<bC+}3j-J1=TnOx99B_Vj
zwY=pmX5lQkS2xW_GK*%(ZLiadrtEfE%q+Rao35bYVKXaB?!?YZn=?yh$!*)b+_Cfi
z>h5yRIcu{M4+g;G*lfMIlw*5BS#l-bt9t|I7Y1vJ1J+%$uGz)R1S7}A?4n^C4>L=G
zjTbDMXy>$hq=wJAhlkqeiqL}oESCVQAmr}dxw8c`t)|bJ_mkZ1Cl?=N7W7~du!bVd
zF$3<ni{;`Ta@u7c`GG}5nkAde_{2#QY?@$SUAz8MW=1WaW(qd1&Q<f6`D?p<z{?lU
zAQx-*i7=Q<^RRiO4>SMe?)sb<DE<MnFc`%q+(sv6{#1sU38u1H2{4t-@&|m{Op)fc
zA1D3dqzN`su=U%&p>AjE5UAs}yS0u!S(2FnMw1CH=dv}mobev@kc)$bh1~NEo;kp2
z2Ci`T`97mQYr`xACT-Th@xM5+egtf?Nb{OfZ@<ZM{<??@1nbh}S27K@ei1PIb9AWs
zL``Rm#T)vxaYAlFU|27f3pGOj%*)74K7Qm`X3@q-@SF@=f1c0j6VcW_ZBjZWqVZ6y
z-!gnNRTjOSPivQxk$dhKCPir$Ztv6H$7inVmfcP{<qUN2X`=<3c=Uv0mrStUxf!`-
z5sQYZhHNzd4L%J&(dDH1Nsk+x`m}EJIrAeb=hyx?xma7y#LeE{;xm_}^OEag%%Yur
z+HAo_uN+^TS@33`Muld%)*szmky#w<F~O$Y{!9~Qp)Nk{Nx_yh_<_Q7yDUjCOR!M2
zCvRgG@9J}&cOo5T&S`f!Gqan|xhJ1k>q<A?=dfFR^wVBWIm=$UX#lfu51)ot<2dZ5
z*Bb3(X7u)HzlgS-zVw_W4(sRBo)>90sPKDBX4(M63}_Xum+Pj^uEH!l$)_zlJHvke
zqXjJ=Xh=#6JmGWR=|np8e52=s%=BqKXZ?j(<JlWOV-^I%Pslm>{Wz&yXJ*<{h#7=_
zWj1H}ZtxkO^9&B9`NZ|@j<Z}8tdU5wYsYQfnOW1(=fxQN?7N?DVrD##a>Apt?(bJ=
z-Gf==RiD;el%?j;ebt#+ult<2A(ds*l;VS!`RBmCh%~$G2s$xzWS&pENu)XO^+I!4
zE-@edQ|Pe!<=#$TG8XtWytdIPXO#{Qo?$uvBA@n*V8?&%>XgM?g0UiW|8wt?dsr^I
z(x>GKxlhYhna?ctA?8k^EWeH#@;bBRD!1-)<`;MROJKFz$8{Ol@=lgB!DPFax!~Dr
znT6N*ob__5&!d)a3p4*(cYYtX&F#x91XcnE+<vm3g|p<o9x^<{awb@LA$Rnhm!>eY
zvRJ=!#ydJB!E_<_b+b2|xv2kRw1Z%8jh+89r)h$b<Kl9D^5VTknORw^dbQe48znuM
z{}Z2fQnb+><GPXQ({M`juk$(UyHuake(U%XvjEsQ9B^6QJn(QuW^u6Lg1tAaEx9~9
z&ERJ~t*FSa*F)DjJ}$H#X$p2C+RT|xCqDOSqePk`YuL*GcACZ)KIi=!RL;%=a~-=B
z&0_CN===efB@T9}NOQ)66;?1yX33T7_UOaR^e^4{-M^>731*=zw&bby7{w{wBVf|^
z?_b?M$;<?kWqJRTep8txvRI)u@7>DGZ@K04j)M$lL9k*t;5OQx)97Yqp)A&W@kJ+@
z8CmRtFKRk*Yd9;vXB(eh%yO|Txu!>Mb96AX<a+OF4Xcr=mqZqe_MJG3nSX=Nx&B9O
z`|AVR$IJ|{uA;wOVD6=_*nJ|t5ix^c3x8eEm6^WT=e*;Z1ZJ*!$B7xjU}bTR>uglx
z!%mzW1uHGsMSm21mD4mm($v0k&yS|8y4Hy&bTB!l3(Yw|O=jy5^k4?q08y63zubQj
z%UNLO3pTS?ul>xDV5Bqax3*MYr~Lw3d>Y)e!`^xHl?5yp1S7-8a<a~%S#n!f53a~^
zF)%s*lWQ|^uo@!G9`9b#n&pyUe!(`z54^}s+v;<!Es-wr+L8_?b)PZ+T?+40^$B(v
zKC=$J-u=XhZNgb{wK`Ytz;aQK{7f)fsNpoN%kFW;bP}wlV0T42IQi+@e9m(yq(hrI
zdpB@?5wL)eyL-ssYnYi}=LuG9%EafG#lc8fF3WX!nRikq!6*@CJxg~R%W{G3?zIbj
z!y%_%8(^|NWxYhes3UWlvK?YzQiqzW-*V<v7MQHFzIpoZTo(Th_xf4z&eb$6&@hy>
z5Eum|oL_@48b+DL!DKlP9eZObvji9gK`i&mt-Yz6r_%h|r;%Z2R&&9j!ORk1(ta-K
zkc%iNC6@%dQpovwOw5d<omh(%w&$z8RjAw9`31jGv(PSgS)N!}X&=ia!0L+pqOtlB
zW;%j1se_a=Jy<ZIma{yVv0JS}c#lsjEXp||wDu(~X9SE41K0IAix;$DW`fE7(x$?F
z_cBX>-6P~KSRFac%=k{t5@5Ha<*vrQPrq$jSuXg!&-wj7VvT<OwE?pz*o8QtauTaJ
zar<^=rU$dYdZy)Q;y2{WRvlR`@IxjhBKAj}s!lv;g7Gtj#2#v}EzWX@y>^$=Xzji!
zolI{u9*9xpQaOoL+4cT7!o(u`5PM_KY)_BD<hpETfpHu{a@RB|K98BUKVz?n6}j@|
zbD8O27vX@@-1JCOGVOMnL9jA{?R(~rFf$`7&6gX0^e3|j7zJyTCfTQzy_P!jF$;_)
zS<Hq{eqtia1rGRVdBS0jjcGw4XR0h<>{BVt7V$%mGBdzPAxbld{g-Q+l4-Ez!eA6w
zG3$12uS(1kV5AVU6PJ&1#&qb%%-9U#I}2-^EX#6HFbaZLuKvi6&M?z|%Ji2YP7XS7
zy<;OIV04b<>UQex#4m9$t~2`1;w$U4!A_%g_a9U<1FRjs!)exgtZ**NnP8&?D^vHn
z_n8F_x%KOPXEDb=gu$o+In5J&7rer92{2VT1BZRiHPavjd_|^S$8shZw>z=DoiC#*
zOzHQt&$$<e*vF?EWNZOg2<NygohIB%RbtDTU>yW|@!=6~Gt-hjEh5;^&ms>ni-55W
z3F74N_1Z~h39##N!1=A)Q*sisz>&;4Ll7s2HhtwCW)ZNqIAFPfqZc~k$ns$N(ag0h
zN^|a|M=eg%0HY4cX@1eLrBi27Ffz2vWSu3zS_x)+RhLYjMim!0re+ZjW_d9E7Y`l4
z>WH$eec%I=%Mt_QHRB*omh3UnvDX$D*(%m=z=$a;Sk8Z3Ef)kEB;>}OzQGxrCfJ*T
z?LT05SG!(}6PY+Ui0>>t{7M(>Y!(KiLCj_OwbhDqnI*w;QL)T6<d(ainRY4@O9gRK
z-j}C?aU4Qy^Y&AhV`t|V@L)kO*|uNad?O`e%SFNJ<1?4#-3Ny{v4#b9g(&Bix;MSY
za{gb{<qUwaUkO4$KG$P_sdNZ~>G(dErD2KW7dT9nGmAYPUQK4$W@Z+9s$|6j%&aVS
z)2DN(XtrE3i*4Qc6m@r-`G0elrBq&-II}<&E7|W<H)f$Mwq?oPGnj?5n7_kRa$PC?
zve<hymOFDUGmC9Fxu+A$Sy}A-YJ=!9O-jEkHmyk)Cl>bq?$+<dJ=@2yTp){en$Y+=
zW}z(hWcLM*ZwzO#7w=qJf#srEtk?VXcQG@wSnrKnuVrRsv6qT=b8Krei<K*V>s*%e
zpK<HA^W%eeF$-j|m1X8nW){j~53Fh8_@i(ZTU=+&4wj2%vC)UyI=<h`VxuO%F`nhD
zEVii2rA{oI%wpY6&!TWN)j$7m>o>FN<(ruWve=B^=k1w=vRK!bT1;UU&SK;B4Goz^
zvsm*#d!Jxtf>DR$aocT8l~c_8fBKwf=YlvXpPdVWk&|J$=g<FwrmePq5wH@1HLo_T
zD6<&Y1%e&w+ls<bTP_Z!vOP&Ka<H7Ae1_4l<vZ8dgZR#a&59e?*=YvAIHnEaoP2H~
z1U4AwI8FJCUmT1&0W<mRTmr0|VDi~HEk`Y<gQ?_#U=u`|^4U2HtXG;f!+yzx<-cN=
z(l0mPi9?7@dH$o5%pzc1XT+jIf;*YTJXjozV{ek1G`E-I;}T#zM<@2=HBoA6yDVB>
zzH_~}InI5N^Uh&rL9mKAp!y^>$=c}n=`dJv!8)yb<2ROzW~Djsy2WdmSzy$$C`}r8
zl`8bf#H}7I3C4Yw<hloE=5U$;U%s=3OYGO;6Z$eUz;qmNemiGRa(r>bgT=rofM7Y-
zGe%$m!FtSI@7Ux77`GplMZTjz%g=Y#rHE}@9J~!XjT8xhjm4hxyP(BfCw?)({DR5n
z(c@qn1Z&m$+739h(~O;!8Ap^~x8V&xXBN+5a*QRwc#M&p9AlwE`ObJJmV0rF_c_f7
z*d;h%9ptmeCYUNsy>Pzs?i)&T-&@n;oMsqIM+I@3l??NHX3-+~&b*4`+CEUb4YLFo
z+Yn+>KkaOFS;AoCL^;3qKTmhYLljJvrs<KUeonq~KMIv)Ws8Bdgsf4!8(_R9N9_5)
zJC2=*ft@XM|Ne!;yIIaWS6vnhj2sv15Zl?}Aj>7eE)h&VAEy`1cVc}ii+r{$1jcK|
z#N@MO5inJLF);QWBqyIOi)ZEcYo*qXA4`HY7Uk^ua}mc52F}a)4oXu#2NnWjA3#j{
zfG`-_a$?d4L_Oq84>=3$9#Kx$`+JIclm$##77sboL(T$Imc{Q;7BFR5JmgFdISWi#
zmh(Nz0;VjBhn(plXMripazVaxe@IKTW0g~dR$^z5%_JC2G-w<VtM~Y_yP1WG=R0#>
zVs9RQHpnar#`oP5tN87UJ(<Nz<ZJEIW186X(!*#;!p_fMGBe(3{<yBy@!HJvQu)pt
zo!Ek1hks&bfX%`Im6O<pTUR=BN`L8m=Xn`oMau7Wd_WM4eK@h*Z;UXov&&+5un1T~
ze9y_xH=35gZMituAi>5Ro}XkExG3Mbjz{^)=hZ@B?Bj?@A7^;TMZjcP<n!opk2Ec?
zTwg|qQ6D@$kjt64INy0!5|w3mmk%klvh|CV&)0U~GwWWs{IVyQMJnWL`RTSLxj~7B
zN0~+SeC@p4jNIw9n}1;ztCX+N<c!mNzWYuZ0(O3pOEUJF(scP$F!rg$q@UI+=R400
z60@G`dkuDWnsKm!d71p)tv+uKvp}_cXU&S_c8;hvk68qa`Yf08hsmAWGqb?h?vk9e
zyGbw})5N6R^;cKR1;A8tAut}(l%}-178nI3RL<7ePdvZ(D(r0Cqc!q11D}~abnDO?
zm?goQrWs9$zrXm!XP5<Q<~wWf#6l0Bx`SB=jOReadOvrp9<vBo6C6-}#5TX!{4-{8
zFe*E<1MmJy)oYj2e_2L%l6zvxJ4cuWz%IuD%T?XfW;QbetcqYSw`*`2vnW`%bpNC@
zXXbqH1G8kUOsr3AjsMASnCZ3io%atCtNZNJA!bQ1_Wi_Utl__0%>rPR@qO0e*p5k$
zbD9Pi_cKbfe0*;SW+qr^At!B!1$MDuEhpbVS=jZN1Y`R`X-fNo;M>&>uRPRvGs}g*
zWZTNMwFsDO2RYX^!Km+%eiW2mxx7L%PE)IssTX3kx)fT+Ob3hNfaN|tui0(POt5za
z+i=^I>zNr>Wa@>|l=Tt;V;f1#Wh23=i8Q5tNif!r<fMLj-F%G(4wrMriA{gv(5~wU
zSSi8eygvp;hKS^7p=W8K{U2gy%O$|L{fHI$rug&Bw0il@IwrAcZHDU1{8{Y8ygREi
z)4?80+g+0TaLM@5%*+P)8XjAA$};ZFYLvZQmgrTP`Xo77pC%aBCox%{Nw61ij`chF
z<dj)BOr_a4V_!(_?dRSY&ddVqi366~zVvKL#+D0Qo$oy3KypV{J$o-RBa1yYb|Xzu
zQu%@L@5Yl{k46z^{WIPq)9%Dv?GDE6M@+V#ziFmV5R-i(2u2fO)}c$Yg-%_E!Pr-k
zob*)*F!mk9r0>wK$=E?+(s$@!D!HJCoB=jLlvA$TB*7}C84a$Pk;8?sv+Gk2<~#Q;
z6FaqT#Rg_tv&=k>m_GQe?#zN<97ht{xAhIm!cH>=#_<xd+Xr>gnfaR|X2?m^C$Y1e
zmZRaHDocw@pCC5+=&94pLST2{fZBoBffr}jVHO9wTCktW#TPTvTB=#lgGIm^i!_&A
z_WX~WW*m&lz-96ISJTk3b?~>!cb?6q?^K>R^d4q$uogIAxoS<zJ7d$|I^Vh1f#l@9
z4mw!fv>XN2?E+2bVQ1%OfKf$In(eTky(M}jvltlJIA-ycpN(af1f%aWd(Dc^VHUhL
zGY_Zl{MdL54dYaPS*+wQc}1B;z*eQ(mgHKNn&s3>=sI^<uAgx|g@<;UF|hmanaeW$
z{>BtS*i64ZQ)d*Iy|TCE31(pr76;?;PI7Y1D&fJjw)xIFG|7c$-07@c7+_6sj><`_
zX4jXuVwchZ>|DX*bNZ$Si+eE3gC#sz(t~O3uuhw9BhulMmeKE6hfsSpi*?AXN0MBL
z?s_Mdv%s)?@6^kUjg~w8%<80;({94LX?{lT**$%xa+>~bnLbGQ$+fNk7{_PCWPBC^
zy9DRBjpSNT1gxrHaxKUNt09<N3rcw8r`?iS3!<{fwICg=bJ|Z6>szhtBJAw`66xVC
zr)v%bHW=Sy9i(5;d#dXt2&SqR158yfQ7~1##KBbclJv;W-%DLD0Wej)L=AU2Wxd3~
zRP_?*lUd`Wx|Z*64P~*aWwtsoN*JuTsB3wxJPIc3Q@&%#1S8|kZRC3QsYiZEkNo_%
zs`Cqg$^2aFgB~mlR#uc##vxHKo{LhQ$vDLHkh47Gl3*N%P?|ChiS$*MB?hJ{OWZ>)
z;UTBprY=hqjOUacP|hzGSNR${du+zRYT`4sEwM{)*`;G=vn1GK_{^;TLr*v?($Ae{
zu?nx&W;qi~m1Y7=rn#)wRA*fy+&|yB50}dF{NUA&pN@fz5M|kV<}sR{+2zy+<U98y
zl3evJ>nbw~gK?iH_Q)SS>oSXiQ6R_q)$+F;#VigMNc)bCI2qbs)$!rU+cS2Fn6%ga
zfteVE*m+M)?8Iq?z((VM@(W@A>6yxpGqb?X7i`0mANOOH1fvBBmisgR>kZ5Tceq)b
zz(O*8cD;nbc&&@_JJa)&6KjO-bj$f}Xgr(cqF|Tefb*+-ptBR(#IxAez?^L?mjt_9
z$oWez8pli@l&_IOoMzSj+jVA9F#001vo9J)Q+!(oeQ>@;oq*Zcqsf)bEU?Q2TP1!|
zNxLgE4=3Fl2Zj!1xhPnDA-B2g;2F#;u)%^!e-s>|W+s>}<o4$d9q*(GMw2?$LH3uV
zN18?$b6+91um3AfpHG6Ztt0)Ut@97f*cW2b)&;;+av=}7FxWk!EONar>5-;?m`7Q_
zlx6Xd3xg@k;*q9*xJOyQlx6Xd3xlx_pt_bmKpT;X%WnXizbo@hlMZI4>yucm*E;sW
z&hGOTSot&~<00Q!l?3D1o0xoOl{PXTXVA}Z&+|?8r_`Su+JQmT?t{b@G+gi<ohB9;
zlkvr!as1wnx&dY}uu?dnzDrEbE#e+50ajGV$#-KX!D<P%_5PP)IJC>6kIh`~p!^>2
z4SSne2&^#<xGWvI?4wJswp=ue&E37=8)g=mU&sxu@Udef6JVq)r+MJ2({#DhPSby{
zn_aS{@Q2KTU_l(PT+XqPk1~s7v1>oM;4rf|SP>y7f3Ls-BcH)(_Ij}TDVEdkQ?sxK
zi-YkzmFlzc=a((xG@}pXYj2|iaDG#!tf{~(IL@8lyCJ<LvnbdGA@}@!HKNSI59Vu2
z1=}*c3b`)3J_8f;o%@riEbklllUcM`6ik`sLmp{9?2#r|6{OGlHNW%g9-LnsjGP*=
zo3UTJW%_N*v`5q|2*!Po<l2wfOT*XJA>zT}V5RXr&Tq)x$KPkUga^|e&5XY;5Rl_f
z2fH9$*Tf=wi$2L|2B&1!JctD+RdCi4qG0#<Qe`1FNPqV}mh(T6>GQ<aPW;5Fmmt_V
zBENE_yH94h(6oGQU3&gUa+|v4k(sjVMSmLe6(P6z)y-rYY!-Y5afo1TciKxkHj7M$
z-xRFbu$N1*Tx<qnl(RBAbi3pjj#6n_FXn463AuY}v~<c6j^#Vg%~Ls#=RM)XpT?|w
zZK#lYb9swHoMz(XeCN02y5i){2MQl!7Mh)jO^FT6{bevS3#=IqsNIQu-stY1ndz@&
z)_aKM9bUA7Sr}|gUPi9T_r>pJmV7;P?S<s(H!5F(nLa182G|WJUvFNf9Ww)rua6P?
zpjP9m%wk|X=OWhgnhK77aj-|yZA)zK*7c9ET<9&-H4aF>Td=PhKWiSdBpCZKVvDL=
z_Xsop+xZ%mo#eV>KVrW@Qw9yyuZ6*CVb84I+qq;iZ59LL@kfJs>$DQXm?gl-fRP-r
zo?E`#%S?MGGyaGTUeLK3GaZa7kmbrOx^XtMAebt@h)0?+Fn+$D^82A%wfdZ<IX5#8
zAU5i!Zm%#4n5eUKA0*ao|7bFmw(g;MnS1?u;@mm=&i##96pZVdSP$c6XYOQz(ZC`7
zh)Ek_ffW}_t_dVP@(aADPBR2X9fb3Hw(3<B`rA4rz-~$RB`Qmc3rag}8(ffyUwV;1
zdZRu;>~`!aO=6EdcI_y_#7rUAn@*-TW+QP-a>QPF?m6m;wp`$Y%$&=>x%1my=d?q}
zgN3u0oU28%n036$@0_0rRvHIX7RqnSAD_grv&&+Eag1W%+@R`XopGB0yBg<MZra4h
zUdEv<r!UOJtp?6r`}op5%z|L5G(%u7;ESAQa^LE0ESL01)4xcarVge`GY-~N<agHa
zSxq=UZLvB{KbR^_6Rd7J%|6(7DEq@fPBRHc1Dy0DR_(nK<(U0HzU~9MiDL@`@B&6M
zgd(~L21GYqbkjvQC16TI52BkIg%V5`-IN5;f+3KI?f?%&3nnyCLkLBb&<Ua&LUDl5
zLV5pP>CTS!9LwjxdiV34wzD&{D_J)Git7)r3bDoCsn&$ebwIl}q`0PgYCUH2!Q}kf
zyv$RY&3rJ}vXq%Nn#~5Ig%0N@-~Tyac_fpc@48^LP~|xJ`K}j6gEyP}d{;S?c7A49
zTKQRFY2{~!rInuxR!}O7{JhQ+!hEm-27euTA^yp?AE#lX&~>XE&#0`yH&j2ePNiZW
z(qS_99~qU2*s|3<Gn|HK)hs8px>KCo*0C_IJDJ?pb{N;4Om1rzjO$J&x3w3>btjYS
zo(jXqx2xss4V$K9UyqGiPLEf6?ToBxovlsT>}Rz4k;(N-g?)`<RCijKeKX+x8xeOF
zYmGpgk$v)WRnab<a~TzUG{1-|GI^L7>zo%eDs=I4n)!P#E+Eppq_rodDYvH+#_dTa
zx2GFcOiEL3Pallilj7v|G+ox7!IR0aO;}-R<!6J@jT_fNer>`5qlRE>Soad$@+s7p
zJi0WC*6F#E&8M?#OBW4bQ?3M;<>$%wrm~rJCZ}oDnVhCgXL6bj822-37rCFgV00r)
z^`nXQ<HLjE9@Yn=#V?!uydV|EV{$+IOrEnbcd=31#d0;HGCR<h$YwuVu!_xdP5b=^
zGV}RP^Vm$+Gm6iXBioeTOjDPdrW3}WIo2P?22^X)l`Zy$w&o*y(4%YvHiynWE!|O!
zyKdNU{2<kj;-+QZD(-VEzKqIA$r^k<Q=B8^W=16}Fb7bauVx1^KbTUqIhEEN^5?}`
zU`50H`H}tCx#9QNsP(fw(&DJ2$Z-x>zQFZI_IZ}mNgU^Ts;yfG;-LI_%^ujfKz?Lj
zUwDH(e}1kPTHGLg9IQehjw~$SzWN-O`dWK_HW&x*C++-$&HhGPXAQwY<C9UJv-x11
zutRM<6x(!JTd!oZzSZ9U@)Zt#$X0v@n+sM1I}~TfHatf(EjiUT^TPO<F<JL9Zm|wg
z{?nefl66{Q75&8y<Il4q^R%A75F0g3%X@9iB9q6g*brui(ZI*$l%J_OVLZN2n)3MK
zhBXSr(b&A@zZ;@{%7={N^IOSgPaD?`8?~Hn82?`DFdQ4&_E&0N)jS{Z{48+&k!{&>
zYCfA+F(`ke_m`8bQ?xTLn=6Asyhnn}^{zY(eQKIM7`HXq;P->}vYEmR;x!bqLUCQi
zxwXO0;25<F*`Kq{i*dr5(V&cztW2Q`@!0j(0TvN3x<*TW-LMjy4`vQr4`lb(m2JbO
zWHN|*N;2R1&6JFqrVDl!-&0x02JC$&o})N28<fv7YWDhnJF0M;H@iW6)(6EcYPJ3^
zHk-+yR0y;+S>twtUa&cH7!>MQoL?{J$`m$BPJ{AXvLOkpiPUmhav8+6LTM@yC1_|?
z%?WFP?>Wt+t3|2%sOE!BldNgIMwi&^xedztz<D2mgV`^%5OcpdpFymN$d0XzTETHH
z*bVGZeq_CGmT$)9h%hMg0^<Z(gDVxaGz%KU-yk7->ONM5<J_=wfi@#cZPc<Qo3pS%
ze6|7EoW7Q^Y>L^S)Rf{@MLeWoMy<QGh(WwALvdLr`--wTU^HNI9c&Y0i?CUWYVApJ
z8#2#+#^!*{kmB~_d*o&_6*Gv>n4q{B9c%VvbHS+4oL|N5JC3rMiyOq}+K$A*9vS`?
zeb)x#du_T9<a=#L2y=xnPYCnD$_C0w`SqDuD*+p|JxwJH;&Z9U<lnb9!)oFf)sL*?
z!NTI2w!wIvMHaLUfz6WQ>MBD%V%MKv$+YWkfn}BACjQlzmL6)H6;@5Ma#bRlvpHZf
zlC|F4_#vAY)>yI?hf77UnelKimt?6P?ehSwF#18R`{wjRX=$aF#ion1^s7R*ZmKz8
zCVbCv@_Ue-usF%g!}|QraY~dy+&5Bt=J_z4hD<e0E365==QJ<Q(>`y_2`eR8>b`-8
zIL-shELk2y-_vYfSX%9ADxG$F+F)t5ryG`5dwOAMwP&g>PHs<AnY7!}3{%&Zf&Q6P
zX4o#SpA$v{5x1G#o?cj5?P)HXc6-Lc(rQl|>}+7%rSsQnbr{`#`p;hlgYrtUf8qy;
z`PNz~_}a|s*!UgC*<pOIMrqz^o?Uy5sIoRslNEbc12d&Rzf@TL!1zhFE8>(Gmn>Bc
z;<+hVnYM%OahwfS06W}f_co22$L4_LluTaRxM1>m|EGMTG92fDwUy$&o$sO_Rolf}
z%^+UOqOuHYTP2#!4r?dX;o+s;FW9`*wXvMyK4hI?U^CZ1Ka=8mkL+}t%^Gb`@TX8k
z{pMvfH(*oh1fTcJnW`nSSzzU{!|f8(X0SBd43=h_!P0CqSek8CH$<Dk(rmMOA=<1y
z>L9h*^Ztq03-n#9K}nX{?5L^Z2R5Z~h&Bshwh-oo(M<@q^^e{kM4$J<_!$|UcX`d8
z3X|s}`8k8BN!sVZ0+YvyUyE11$@R0t<nzAi$yfBFYTtFiXhF^8yi!bi?}$g2pZr-0
zKA1dS%l*vMG;OoO<aSw=uANvXJ78&*(+x|joL-pRKjm_!!uAB}HyYbXtM7`r*xgK<
z!^uqR$BKJHFU%;#$$ul&2Wu)>%b`C$#je_(mKbebp)}=r+5zKhg-o8OT{_zqS!_S2
z>48OHht3hj$#b|*7bnj-N^@<_p*VRCH^KTzY07hs1IB%c;^aBU1LHY|OrFC{EwuAa
zCePtkSVbv6d7QVyc$}v=d7O8*G${E4abvKp_F%Gj?(K!~wL%tM#a0d*^*p5N;+B1N
zUaVV9t%B1${It3@M#AXf2(>k(d2;LXYn*1RF7D>bX`R^YFzU!0H-FXEf7sl*G#7R*
zG@s3@vr<3U>5+-Q4mzt;JE0q!=`(G-rgB!yw^`gjSYUMD&Sl9wD{mCXxpZ+S7H#Rw
z=FwTZyn~Li`Cx^lG#4Kpj+KDFoJ#B9vK-y?yak&X#(jy(nPc%%G5^_ML1}h8`z6OY
zbXMqD>>W0j&Mu!RRDsO{ll#luKH+ECd^$@RaiB7r(k8eLnVoYsvzc}F+wvKrzgS_@
z@q^sfr>2Y&_gr2WP0VC;f0ehY>06Oztk%!S)=h}1%4UVl!Vbr+I95?Sr}e_*G|PTj
zNvzMzZ4F9CDeg&yb>ciYVAUl%yn9s_&d&p*LUVpq8%z`Z%-+tRtd?y3(i7nvXKrus
z|IMgC{aPP(4P|q~T446&G@mD?e!-@EZcx6Itb#Jo#b*1$Al_p}?Q%G_)Md6*SYs*f
zO}b8f*{q#{t!<@qq7Kf^T0f&SQx~qj$Z>91Y3y)0$L+r6Wb?sBO4hUWNH3eMi$Of2
zrZj(Cm083&VEY1b<FNhZz{PhQXYFbbe>Z~c*3(!2v8BQW1nM^)2k-u867{onHz@Rj
zR8F#}Uvi4IsqIT`ULiZ*^mqqs6eOiMV41MxxV<;`2y?<}N!Dh{X)2N$=Y@SLS<o5<
z#^WyK7qmv{q0Pl)^7`5W<FSA&XpI7+i<rxKZ^k~+UtF-X^7Fv>8N>v{%g-QuAxyEQ
z9cPB+2$Y4=tdZyI1=y(VVhv%o5atMBE*QUVLHPy!j!_8nzzQ4uZANj&9(NLBtFIsC
zV#y+I{&a-vU>bsFhm;Tc62+a4oIsa=T0a}CfMoLDe0IQS66Lu4EtmD@I4?}DgZvpp
zJ{Vmb9G8%}M<I^057o{sl|}wt3@5CJ6es_^YY!}~a{6FxrML+X58dSatY4)aXM?3x
zKQ}C``gve-{VvpfChlQl?P=G~4oj<kE*Q^a)Gi19$d;Sy;DPbjO13>^%inCKVQHsn
zg~@TJU%jfwan9js$9Y0nY6vrrFetww13K?CNnKi<(v9=;!T9_+a8Q2zNEw;7nPDaj
zY?LO&U9Go6%yE`)(l+ZTZCs+b?QO$pNv$9$#Re;mEvGqnS2b!@)tn*B1Is1F-5QS@
zgFu`wM4Tx;?fk4TN1%R_kXG5n_pfo9p3w&7g=81Ie?mjMT29YcgK}B2&yur8vbn|^
zl>6AB`caw#rfi<e=A2*<e^-cXLZiYZ*=!RH%I8v=CzC&K$mVev#P11HT-eT3x?NJs
zVxEN81Ejdkk?qA=(J|Q|UJs|Z8<*45Qb&z*hcF+E=Oc=f=Obl`c8!tA^N|@=49B?c
z@@w<4Fsdw@{Mx(&MiVTX{Mx)bM1Ecv--}XN<oPcZR!~Y)eqGx%Rhx4r<7ebK#{x42
z;>hItI4i83WP=J%ScP4+JzcP_0h@wttoy@sHf5SYyw7SX4vua%K&+FkFe{Ex-O17)
z9_zwJP16y=JTQKKO>wWwd?)fVO*e?&OD22#wf46bZ7^C?a()I=HthNHv%|O!6!&36
zOj9;5j0(kZ>%yXNz#r$GVGyrVQe4NA7YDGJ6SQ>*S<5SyWo$NB1}V)e;a}cjv(MDl
zkrX$<cjE$^Q)m0?x20u?+GcK@?eDzpJ2tP*CQh$QQ;-^$s<U?s4E@+lv$Xy)4F?Z@
zz2+dB1x7DWQM*jXHl=&`2sQ_d=P@$*JrYhB-Plmv3~U$0<jKx)mf2e0O~Aoz!|f;7
zVqyFlQe-(7&aTGhn4`TmNR~3BUR^dHjLR|;2d7=0zlALoRuMZ?78)S-Y$!j5&HSzQ
zEQst`(-(AWqqdn9#@8R&->omuQcg7+EGxd}G(G(@IN0nkUh`3$+@4Mt&&9K0y@zEw
z!*OmH&tqhDexF`~%^M;vHAI~0yR`GOz|zVuHbk5~M4U53oI8YhLs)7EGtEuA4weuW
z8^Y`%%n7TClS1d6&XIDh&{c7cU>3>#dwE{;LB(khe@BJlPL!!6*2yLqT^yX|5K9f}
z!fHP=!`ez_Y5(?LHV2IF(J9U2lQzy_^M#1B&PzMa1>?Dq()`un{fE=^z`A2K%H_=e
z=|O4=e>oQ!6k4gW73iN~v#=#;r)h=p-=C)ZYTovxa-4gaLBXHx7HQ^+YeGMw=I3^4
z?@OSA6O(Q{WV5a?`2V&5exHjPWM}^_bc?9Qd0_NKzw4zwKvDNJD@=xSOLo5L`ToQh
z!WEwsH<u0uzSxRjpW?_e*gaxQHm%g&A40Y<b4@Xp+hB{OxFYo%Q8H?N$|~(OFp4wu
zytRVO0^_lcEWU?Pm=(r#Aajgx?&LTd49zLZ`MTFhF@D-%)_~Fd$K(Z1-eaSd#SJ?u
zS)MIRhOjwS8^rHgQe6A?O(=Uc&a_5*E==b0secMlH3y9Q?mU?DLZp~CeX!Gk^G;T(
zh4#B2?w_@_6q&r1^1<k$qVq5x+eKZj6vf70mi5{-MmOM{w+<H9iW$a#ADwL4+fgQt
zb8XPZ7qUU?`u@b`fqjA<%8#r@mG{rtyf7Z;$*TN2uozn^tRQwcu6g(#t-owc+bpn>
zQe6H0b~mSK)7dw3--tf%gk_iF{<Z!-oa0<DxegDebQW`?8^-;b>L7n6kPjx;!C8Y|
zWefD({~45q_@3+6rhg+k{pxv$g;^vkTX5KKYz|m1$({{feuK>gD<#?X0V77Sd0}al
zQ`wYuInA&-Qkq9g&;6Oxw87+ZKC+e_%jSg9qJ-;LVO#V1Y+hI)$!662NK>p@_f!~l
zNRC_j*H-Gns+l(jmvh|Ny+$@GOpZJF_Q9WQc9`5J4#Xcj&gOzu#17~8Oa3NX*}O2h
z?#7{Oy=*48cArD%eScy%@w~taD=Vd$>BWLd9A}4BkZjwNPrqVw!Q^r#zaI0H%?p#y
zyZm>(Qem_R;yTPUJvqj4<}GRG7Ymc?*StZAUL5Cy$$eM8{@k#%u3ImRUa8=+{OGZZ
z{u#Sndmjt6S^f#<ME~@_)=70}ux;>bE{lDKLHy1S#r55OcM+TN3+|bvxQL~D`?A?!
zyKu#ES=uyuO_zs47oj=Xpq!^|U|g#3Kg&HfWmnpDH^b&g_4`n6@<)zy??xY#@|)|Z
zOScMYe!e|;{UM{4Ux6;0u;(}Bpg}o^@3}0MW|dmS=7lYn(kxhS>SQ+iVFP`u&^*0R
z{m%a%)sL(d8R|z?@x*cQ?8yV;{HP(nFE?29UFQ*lawyy%_dRUgmJ2noQ7BE@DfGe2
znuTRKu#?SkNqfH{#ZCJDkB-7F8^qu6C7Uq2#_w#NE809wCf^@<VLVQd1^uo%tUZoV
z{mA6cmx{frT@Pe=3bbC0jaml>tS-LiIQg@uJTUsA_FSxf=l_rDPR7?X*}%l8ccf&g
zu&UTnnsh%G^cfo0(l$GcpW9H}hU#NxV56q#y^gsbiF2BR+ia&{N;S(3?e&}`IJWg-
zr=x66pF#Y+U9yMo`@Cec+|<^XWb!keSQsr>C_gg!vnf0<z6T<c-@ELCMM`n<=Rqj9
z(vCC3(u%Xf=zgEeB7g3I7sg}OQv8hkJE*4H+C3%NPf2)qi7z@w78w4_rkW;M&H8WR
z*-R;TPjKLxCYyA0_GvcvL+yDT+1d4P#F*^(+o0SITq|VnTG!9YarPIumkFFdvKg~8
zS7vkkYfubQev5WB9nR)_g|St#kq_H9VspPSh`$F-X%7C|*_<u*oz`Y#pA1M(r%J86
z4@O_quYXX#^Z!TfLdKunKqh~7gDt%}y{d7`ba7-g0`()yS@ES<@47M=l|g~E>2lbV
zu66fQIOS(DA`V+Rw`7y*XH|zTvRD}ZekxhdOO+2}qsH08jpFm}f5b8Q^RFG5j7n;t
z&B$K7XiZasKQ4<={Qe4=$CQPJ4b|K*E54_)kQJQq-iD28sUggg)u?=dpX0dr_6^0k
zb;5Wopfrn3`f>!P>4mM7;-37MS*#}<*^J6Y$$HJ+RFLB=*^Od;r!>1&UE6`p1}i7U
z?f&crEicqMIAPbNc3FF-*FZLVPNTSvD9xQ2W_Dq7!|Gv&>-Tw^XX5;&!um@#yJuB#
zPif0#RE|iNbfvX8x0c*SWo)2NP<}BftAD{pEvGx5QK5H^aejSQz8cCFn?JZcw;7)O
z!{&tL!w$z~d6q6Wn;SMNFjrB2<JR4-%4R8U6z{1atG`PTbFl+f9LG4#S5+4_<v2GC
zk1K@@jd?H5pS7$}=@y9l3EPWjAKc+M7c7rtlP4b(?c#ya7hRh!^*jH6bUl!*$Ck?C
z!uG38QR14mm($`_!1#;e$Y>Euab)hK%;U((EakO0>WlovRu~5;jx1_zm%-#@v52dK
zEg3CN<Z;&tyM-TO%X*^JfA|qK&QZ}QK9^%Pj`g1~pbDE0Ryfc<$uj$j>}69bqph(+
zX_D3NZc>X&WpToKN;V{Ov02zv^HZuA#qab|T(5mkXn0c11&hJ=oMuu-dkeNym{qdY
zk?TsZS*jY9_kq4kX%^e~T8tr<XruUB?P?vCP3t4#Y8jQeQrx4pS?D%WEsLkFQR$2C
zxhyaHRuyBGrJhkdUs{8o898s_433M1@%=m5(PMKbvpGVT8+HaiNcmA*p)c2q`zmLB
zqjDl}{>b9LJR;7Kt$|TFFWHwrKc-<yt%J3ZQSnN4bb>98&D10~Zt%)(V!lmnivAgB
zm$e9(QgM^0gS!Q;+d!IRiymE>!)aPt8O3W1>u~VG=`)|QIbe;kL-iwTXE@)R%^M=l
z{8`#@c32T9%`X;B`ij$Z!HP;Y;!<sKZF*sCBzu%_t0KplTN}mS!=!RfZMu3mn;lj{
zio0W9eUQxsD=FEWo-2ve^WcRwl1y$FbDI$LgQXSc2@z+CO}kyJu(aC64oj<DJg``)
z4syGg+NRwuR#;l?Vu#I4ul0#^OA=`aQ`=1GU{t0C`Wc;vh{30>vpGLED&I<RiTAY6
z+ctMHD!)i^a}4<xaGbAmaNNLuPtRqucQY!Bq_{TYD-U2ZeQ8wYN%?K@jHj-wmeXxB
zD!)l_VX=$oHbgZ?FQd{gU`aUkFrSH*O{%5#HY!yD_A`!+elg`8o29Q&ysk}l_g&`g
z!ulJ<=R=d7Z{M~qn+ryhC|zS@xeIOE$>xJqmuzsed*Zq^#~GE{fwIti_Tky-Hymdh
zU{vx3>Q2@;X1F$Y48r*fq)GO);4Hd4)cTnQ8x`DosAbuJV+UMW#rac)8^v=|vb_u1
z3bVlu;~3R}Ec}E$J2q;XmJyhb0!D+J{JXNTuv}sOII@kmA8OBZ;sbLB=J5Z)oO^eQ
z`nh5G18Hu;cIm_4remY#=Y_2cv<q3Wj~k1#ImRGA>`*y3W1C##_dnQNFk0lX-5FQQ
z!RCeKlq})O)KP4yu>O+euk+nGHrrUEc-@}z%b52|Gn*5389SU`x^>#$H?)t_+Kl2p
zJ$*skZ#rQXDQ-t{{4-9|1FI(4pU0MZ*p%_w`J*%+bk?5b*<fX)xDIRWqMtco^hIka
zxB8v`KQysI#(&S7Y}jHW-G(S+o(V?rxnf(e-|R>$F(x}4Mx|Atf0E_Q*gY>cYMghn
zQE7nhsa<HjRd>_K9c<<)MkP5AM^+@)`rT~4X_#-ZLvh=%y+809I-P2o?&(JHS^-^@
zB??Zh&1RjU^$A)$Z&~M=%4UO6$D%apqWpYq^^0t&FnhpuVO#Yk9-iQf>TXNW`X|}a
z)T@2j95DK#_WV`-&i^09k?~kS_T}fN|0X5#z#3yqWuZ!&3fvuujcTTu+Wpub9BW?V
z&04ltSb6MF9NEK~y~Nn#fbsP}HtAy}Gd60PE?7x?&vCsoMT>QT7smZ%FMei4<MID+
zoHENOUT-9;*K_nMHWTa#b|}q#*qZtqDSI_PWwv(xk$v_grY)NV7J(g(+kfYW`E0Q;
zt^>u%&v5OqB2t{kS$zP<xnMLfaGD3FXTQScg+)pBdVU=bn=&Wu{LC<u6xXM5+2<T*
zf$^9{<$SqvTs^i}7@aUG%YJN&oT1+&546j-+Ijcjm?34@dA3+s9qdpXS<w9htf^$Z
zYM2UOSD}P`Fv^_c<j)l|e`gebtH^_&>D9B=8*J1#=RBjbA+W|IbKdVs!?tSHMOrxz
z;Fw%aCydKUCYRF-<8qS8<ure<m6J>^rw!H>$EXfu$2Mk+#6~TP2ev3ov#@6~SFzcC
zFe=Lebx_mHdh`^V@{>_KlRJom^85MBFjF8+viBpZE#o-LD($*GgoE<4N_z-%!@A?=
zsSXr(FDk-^jamoOYHf`|wxqeMBAaiGQSo4h<63Xa;bU{HH7W}wdo`~{Pd4j1Z9bwj
z<<Bp-!{}iXrzt<H^ueg}u*uIVl_aBh=16JE&nnHZwBoEG;%u;~QhxHY%2XI%M~Cq<
zBi3yd^)vl!6u+lWcH`EqKe18U(*~2{vQMu*o6P|$gdM6M#r1E}IXjyxgn3|(rMUT<
zuD0Sh_j=rONtXBY?pbV>4cgj`^82&KVqx};+I=dS{5;tS%Oj;JzemswD<+xz9zh?h
zq-64Y1Wo@lir1tlKl%N978qZ*M_}@GYlrc5OZG{J;bQ#sgosl%r5zUw<2q29L)v#Q
zij8{y957x-lF92xSBN+-j3!Y!w-o0cRDLctYMP$SM)4jqvUQ7}hq0O5M)CZb%rfTV
z1UC0pqp~Zo4k4SBCl_@CHBI}Dw9Dy)(KW(l`S)^GG4|MgF^bQ0qBLLRGxXy$tvj`O
z>?jUSO2myMzS7~J9abA#N|Wr|H#@X-4~+XYS+B%@#hSqjqY0hk<bIY4<FSC^<gvh(
zY!sipNG5;wq65a)JDEIAxL`CubAIwT;RzAv3lXR6GK$aMp!^!mJ55V6wOyRB8-a85
z8;;ffVQE%2`yQjRJ(IsIWR``yZm?O7YR`VjE?%y3kIe?-v6bw4RJ6E%P=3?aHe@3#
zy9#n#Dr~M)miOmRiGJodZd5Kx_DAMrnK{mO(x`-I(8^isYR_wIc5mQ01J;qpaIklo
zNtf6>u!86uw8s1$2Nylse1Xk(M(Y#Dad6DORiCgaXL0X~9Xdx;v3}7PuCv)CqjmP<
zdM~J&3iUxBjJ_zplj?W=|JX8;Ax*MPYYvwnB}+wITBe*ciqEN`ID6;0VtjGHR^k|^
zxv@vqn%Gs-w4BEpMKZ^%tzw?`!FEY@-aKB^-SwwYyswfj%9Ppf=V7C!>4xPC#E}(j
z*u6TNR~J|QX)7C>PZw9%dHP>A<$`uSP?}l8KfGWw!{q$rIIAvh-k2@JIL@Yvn{-3_
zTq8#abLmX3p9e-44z)FvQ?8#kL|kf!IOSq+nsQs4U~=8%vRHI+a#^gfCQ><PjXKbk
z+r<gvu}9z5?htXxrQkTZt<5kwzfY^Lr(&!9#U8>uupCl3uQZ#Fk;otC)8&`VbiOW|
zaydBe6Ho5JY-XLwX<A`&-Q_fGx;Qya2W%WN;PaksebPbBPq|_gzb8!XIpfC@3)rl%
z$x_^jJMYV}d0{mqb1l5Klg)J1s5F!8YV)`lHd_dD!#YWEwW^N#p5si{g6p1sz?4mF
z78sSC>lZs=S~8n*J?%I%EUmayST`xn0^2_SoYRc`%c#(W%K2@G>e!gg3zOR{SLK3P
z*laiO%wLL|6<=ML)rZ%FC0q6NVgtvyVX>0A?^SNWrrgwCm!Z1k{B|czYii%M!g}C)
zF6SS<mh0GDFq#b68eP0Moy~bGxGcsxLzb~Aw~fjYDb7J3c8)Ka16(j4ww&hB97}0h
zQq6Hkd$va9{BS6fm>W}Jt)#e*Bby7e-qqHv6qo+R*VnM|rwJP_#ns$CJ|~-U&!{|;
z?2n>bstLOvT$a(U>|%bf!-`6A3s2P$eb)u+BANO6;oKt46z$nPm9uC;hq&HjVSS{y
zzaG{f%5ff8Y00M7KY5rf6-JqJdyZJQ&B|tdpsj5vKU4o0u|~1O+DUO`-?tO}#S7zS
zEEE^?nbRT6^w21NH<#j)TYfSa8}&TIhA=0L8iMQaGUs>gInEoxOn(QT_lm32(`Dt)
zFN8T^R6fqH>%)9|InMSdZL>U1yMFc%=9cU<GHUbvS{fSEa;Cyc;Cm_y*{G#YZnK%6
zXxFV52j$mOZ7_bn2ARt>Pn_G>e=wfmVxu(Az}6KSe1OxmKf`MU*daTMZJRC08`+#N
zem@G?n_Thz*}Tt<$_ngI+&OH2eS76Ko8tx6S%Lg$?DEdP)`-pe(x|jf?~fzvdUCZ`
zgE?Ot6*|$B=AYR5-u0*Dnu4U1RM;}Cn%R<v))Dt(&i6+8F@@Hj>OxoD^T&~uBSV^G
z4a;|++ekG{4~!a#>>{=;cKdwTsOE!}!uMpfu<o{_2~CHpnLcRG5-#J|*>C=$OI$Sz
zEOVglv|yFrQ)B&z*WV?}>3mD4T8;DKx5s!rL2=#-u}|5|>B7bDVvrqOQ<W}NHO>L!
z-&G*9&fZ9;*l!ub6)V1{I*`fz#RJ<RS&55F!m;a*GlVPuNabvn;ar5U@NlJsWEUQW
z(=CG<=gt(a*aPR5@_StDkBV&OEa9R(uj1fmEf?2hi-qxcMi#T{3QZUOvcO8>d#VH3
zhhB4Xu(@G;t&lZ+c89vM8s~#i<{Xzbd+WYzrmW%O{Yw-#WN67|Y_YH*Qrv(|tG;9N
zz<6w>2_<itmCxBs*}}zjL^iYRlZR{;nELy^=%3edaO9Q`qR(5ihbvBMGuU6S|4PSD
zcT?-&%@M9_&*-lM-Jt$ZqH}pRXFjbCWKVZC7GsDPmN#&Ye6SJ=Mx}6EYDBo0-*4hz
zn>pW>WsA)p?tc#m%5n<__a9V0sz)u02UZuys6A;wI_JzbljD?6!<FoT{Ky7IJ)gs7
zDxjS|vK`KohuEyJJlNqhtIarMW3$2d+)`Y-)#d+TbHb`(hvO=_8dqoY>TGGgoIW;F
zWVru5f~X&@V?0m4OJ*|{3RgM=&cl5iY_K`9Hk-p7E}o-ML(1=&b;0IP-I3-4*v+nA
zzvehg(Qri_&tTLUUKcA(U0K18D^3{QFi;&HVf*Oj{At*z=7yyP>@l|IR^-mY<|-Dh
zype41=vK4@RO4L5!<8&l7NkjWPh-~8RNzmuM7Vejh3v}r7hbV>VFR$kapN~t{g=&J
zGF&_Zq_~6{hAM0h*t85<T)$lld$O6zXxB8wrPipqfX%A2X!E*mY<AdB*x|BNI)89A
zo2hKLcx{l<w4K%73vPqO2d)*ecgNE2<~W}vT)d9{1P2dYbc+6It`sg_%OV>Pccd}L
z#lk9Mhsr`WaM|}`*_^PElI7jf^jkJl<!~|QP+Z>ar^c{ZVMPMxh^+s;`hT$5tAvZ!
z8)@*b*P`hjHl=E~@<Skw?BnEpG(9Oeq`0b~zXXi>jqT#6E7+Vh!o}y6&;^uk<XJI4
zcwv=rjOs@gIr4G=jx$Avi`R(A>e>d0u{;*mP>Nf8t@@7~=YmB_7S_eoo6Q5`zYj!d
z{yh52acsVtXcsB&Y3W*&j9Ncat#HLGneD@x1U3syF3ZJ<ai6g{V9%tu^KIvdxyn%+
za~xgos5|}4pJVfE5OMXivd{o8m&FZh66o_UU{kXHyqV*ahT-CML%M)|8dJX-n+299
zaE{1+|8KGwdtw`fi}f{`yuP->e#0>;Cs~1VaksEh+r`>ATv-*U16h%{PsX#QHr1|o
zGWoNdP0hl^X91I~`FfH=#KnXwG{$j$*9M+cmsBXa;%go*K6B+I_Uo<wd_BimT4>`L
z*|aNWnwHdZ#=;KbdrFfAox>Sk3p2OGm?hbb35lO#SB<m4sFPD14XQ=M!zdZmY_O_<
z_N4Lf;EN_=j&rpN7wfvBuu&`4p5i!<WR!N_sqfyg`9hfTnU<zL&K$z5A<P!S96I~F
z&aW%DoURb&31PkvrnC;OpPZjLgjsbq{!)*#TuxgEbA&Kg2=nMH==_B+rA=`C<T!H(
zvxYER2y=umR|xZjFkc8$Vnfs~gjpqv(p?WWoqhE_qmR$6Lub9)cM$6dmt?fAm)qJC
z!h9i2X{*&wpQc%7^7U?&tPIMM{o8~tTnAeSb4XTBR|i)J^S~${8nY;_^3oe8IKNaW
zt~?GlI2Dt~W@@L^Pj42T$!#4Q!t9boBO|%)PMu|Z@pV%!i(6-(+49e2^TMcnR6klE
zm;0p@O%3XpthCqaV8t={yqhI!q%&&>vxP862y^M|>u<6hLAGi+Jvx*7i%+s9x^gNV
zv~>tsvE*g#I88H*pCvTc#aShz#fjW5wh-pfnSA}ZLYPOgSY3X;5T<;t)j=O;)|p%u
zD~$VmJo1Zu@l|1L)V8*VFqf1j#f{DW>N3Z9LYPly@|>f5q1A!Xl+7&JXq{OlqX$cJ
zS!^N9AsOA^$k(PzvL!J2ynA5WW=mn89(YAdVztdur8v6zY5#Z5^=zh&TK&jc?%Xn!
z%>v^zX)*i9#oxtwut{+qSm*hF|H5$&$qwP5Tuzr{M|I|b@%rov?BBoK?K#a<Defu`
z%I6_#C)|hQm>IV!>f(!n@I?bjt`L?#gcS~9B|=!)5LPLK)d*pALs+8_);xr@31Ody
zu&yDjX9(*b!iI#f;UR2v2%8wfriHNCA#7d<TO7ichp<&4?B@`+IfU&9VY@@vfe`jv
z2s;_V&V{hcA?!v7yBos(4q^X<uva1MeF)3YIqk70QwYl*!t#W$0wJtO2rCuB%7?Hj
zA*^Nys~^Iegs_$&tZfME7{a=Tu-+kTKnVLPgpCYgV?)@a5H=%(eH+3Sgs>$c?57a6
zCWLJWVOv7j&JeaYgdGZDzlX5XA?(i(b~S|E3}N>}*y9lPJcPYT!_up(AG`+)TdT=r
zrQN8xNAA#;%!Gg8_-9otRy=wXUt|&Zw+H{MCaX0gwx{n7QJ+VW(d(;WWQe1C6aFH*
zgny0kkKzhpn``9t)z~OxW-P=U*pd~+mcPhcFtscui?tZ`du}YVlbkFGMh}Ut0ZT4d
zSbc^|b_rHlvh~&lv;<V+O!$E>RkNyTj@mzg9_gt@uO~*U=Fcx|bk{%Gl3>LHM%xcV
z@@Hc6!Un2lwURZx@hBTx9W)|6WTbMEJ?riIA6q9FJqKay`o2n6HV2H_o2|*gdc)Wf
zVI?ISvuGaO>Zx_`z_`t5y=-YV^fB8p7%hCMt;t$sGSO|d8h0!#*d{KEQJ=-4YRWO3
z?CMfnSoi-m<2c2L_xfUo(+q3Z06*zZGY*y@+4H+rH(M&Kk7P4f<?hUe+eXpWrEqZS
z8;@wuc$iI!yD_-HY>vAGGplA%>*uWf*<`lYx-=bo{O{MN`bFYQ%5f2ws!%so+r<iN
zjqkaB&HuBA{^EquIi+(%<^1nux@Fj?amlb&s`=acOsw-GTUchC7uEc6WqrNGxvdK0
zb4zJ<&(Xunaou3_oQLz<Jgwa=wgi}6HGh8B-!`DjPA$u882z3%*CAoWQSIDj(XLI(
zukkzcIgT@7kVux|@-|AK+bcEAV>lzS{pxy{kIiB7U%Q;&<|mmNvzc=SmnD1Dix{@l
zT)}A$D);^nTT&jpzd<UC@z;oPZ1Ko>t7Px*m!HOF$se3%+riEyY$>=fX^i1=4o{a^
zy)ULdk$}<U3vAgg4bR$-<9slm6lYX2(50%jiw8ZYp%hnR{kU0dVYoxCuA2Y6pEz*z
z37ZvmM@sX<pEDn@MHRtk6{>Omb9*%X(|2rcSQja-SG^sgtxd&XQrz^CTjp?_9Tp?S
zr7L~yBwI2%^)bnm+XMe*bD(q5XAN+>yiEPN4O?s!t`*5_@eSItxk}@+UL`Yk?V6j-
zS0*^WRrOt|Y)R<wa(+F>wW48PZR-&gwDFVr?iSPj5^OHm80>I4%NIJ*jm?Y{+)`QQ
zthg-N#cRQ5olDmB=f7rfTmmMQ5mK6$US@N$(F>n)pQ!%+fGCTvYVf)3(|+w<jyr}9
zA)miT%|GqW7KO=3K1aJ_w>M(5*9>m66?LN3*A%JmMq^Z$+wA(}q6axHyl(J0I$kT5
zh8wj#JJkz5N0S!aYQUCQAFty}?b7IYnY?WA_^H1nd$PNx$gdMh+zUU*=OJa<-c20m
zfi;xkTz%rzXF61e@FsYjO|n7<{$9ax-llk8l4P-sp4!<GF`CG8)y_@7e#7Q%9^7Wt
z^DZ6Cme?}5&A!X=Wox!Rm|e}-;c>S||81YJCBWo<mU{i57<a>wg51w;POMUd<C1aJ
z$o*_im*Gd)?6_*=e)j$C8K|-U9Hqco;CpV*x>Lq4W{Ym;U;D5<?ri^$&D0@y9@}^P
zj3}oKHeX8f>ud|2a@=c}L2B!V8>^IOqXBZV6j$-<Ws}$vVD#QJF3atL?<%n+b__o6
zpB6M-XY+N!du61!z4!fpJBa#(3xnBPY&p&CsUJS)I9FG!$t2rwD}4`Pxbo#bk=K?1
zqo2P$FLe*jZ({lvxC;E1h!kj@$@vv~`uZO>YtP`ezSLxDB3nf7;5IwHBW5(4xleGr
zJS+U7D4V5ka9Iu%Zhx6AwO?@E?dSdxbx*~JA=iD*#C-)sTpZprDAnP&cR37f#|GlP
zl#(fz%3|d3*F6DOhI}4wKUszz>$jMp!R^v`a}IGmq<*ESzmv_^N|UVLWac<ppct{k
zHfF)y*=*skeX9BAxaU{9<81r$I|hrA%9$EFOU!YpUn}b86Y)7JKB@W?j*A(F*YTye
zJKulvjBW66{0&U(a9OG>TKPY=L>S#eaGJ}<TG3<uWwDRMdQq|w-~NO>zd13|(0k!H
z&YtkkO17j?!R>kU`dTr+$Dwz~^*hnNX$6jRVsMe`5b+=%&Zs}X<gvl!%v^0DdUK#G
z<AckY@a)46Z0-rc<*botna6f)VsL-icO)FMx<5_Vq~JP4t?!9k{ANR|o29y+R6e4|
z`pq#lc>Zfvss3MVeWq*oT%~X@u4F&_bRa)iZYj+lwyeUQ-;!qpkJoK-{}#`dFf-UL
zCBBVd>x3RBkGr=%i*vKlUmKI_U~XJC2b<-);5uC2X`00r;S4Tksj(lfvQf**b8(-3
z3;$(P76i|m9ed0b=35v%$30lrxf#bLeIJ}=jek?b_!5s%NUmSCeMdx}w=4}_Lo4S8
zifc?+7QBW&|6$V$&M$d+@Z4{k6DHPDi9ZF`;mP0YmT+ABir_hXP5aXa*sQC9>$jm_
z+t+O2Yl8b=`1a~I*nDe)$E*Pt58`SK^p~XIxJNsNu49W|A3XmpRPK#nI|hr!4vz(o
zZ4c_O(J%PPYnzVQb8KSsZ49nM&dK*rvnAoD%1LRiAN746wo9;qs`<ydnD(vavNhg}
z>sE@3T5^h}ScT?4`XCt$g<^cETkJsvHm}Y;?cx937K)?0ZVXK#ZqunsqCJyg;i_4z
zbfFJwvR%wM9$1)UpSrJ3!me7D!@9Wpk8`zSI{`CDad$=)6l3yvU7VcXHC=vj`?Wsd
zgV9Ay=ZMNVzVhW3oZo9$cFEp$Xy#)J--6H0SIuh0Er@db)yaEo39uN+=s0~*n|Wc`
zu%-Mc?scUDl&xw$SYFAFp01U|_8OK`vI_Nwon*_hRjUJ~`Q4)*&=dS=7Kh1cE*sJA
zQ?@!V6Lz>P<;Jz>%@zx@sphZWvp4lyv$<j1&nUkuXP1caI&zzK??iSsa=De`8pEn#
zhx1D=w3xcGT6YKR3)TGjMHouk*e=2N98sF9E8P_1St^YC1lhSkr+(tN*D&s9WUh&2
zXev<idj~6t@3}17Mrw0h)OJOE4=c^L6nAp|j3ON8hS3S*xW(VS6J@ysYo(e$uHW<$
zmpHEYj^MJ4GdG~_pq3>HCa2kb@jHwFev5@w#`m1xU!NVoi0ZeguriWO{KHI5sHW+L
zT~p0pmJdUJ_>;}~3+5cjGDg4c#WrGRaJ%GNnMI5RF4!I^Zq2G6vv6Fu<ly?<9@VKG
zn++!C_i=SUQTN8Xg7Zt<usoLI>@aFTJ`W29)6*}1{bGLA#z8tqZyUB8z!nda>%QvM
z&kxu-?AFF5ic8AVRE$~lp+u8$jPuL>=-=iXmjdIp6vaKM;<2-t_TpKh6nACS^P6mm
zFiScu%?h>>E7^`=VHzjJ6`Rq2G@E5V>L<nZo!Po4o6V!Bzr)Yvoc+$*ne8=9K1cVr
z+_JK5KcLM4R0nIFY>U~vuoyZP==0u}?wo892ZPV;xmPP@vYBDirMUHFzOBnfzim5N
zvZfa%k7TnP!h38aYvrp$L#>h?{~R#NocsLfzS+b$kq8?jwad5X|5(m(xpAjUgB!>B
z`d1ZYvA~Y0=D!~P8v7!Z<6gtUrMUHr8h2%*Ki+}UB-&;2(r(mDYB@bHbTwhFqaDQD
z@Axe^Zp7q!W{$I>AaXfpRLEYO%?2ARrP*}w4KbFVfQ6~%pF3U@9=d?zygJKz>9LjV
zJj^1+bzJ)<k}drA;6AwRVja<!?6BxS9E~$?YG$9raY?WrRkK>j@^))ih%M&0ww@p}
z^mrc6mJFklN#}^H=h@1Cu-$=G4_H}jm*ll|WHaNZzEsU>B|CV3Q)V^?jN6m!+ZN@;
z*s}~)S&g$;Dc=^KgjM1=FRZC*Rx3Sx7?kxRu5$mmjX0qwb0oXCdkC&%zpaLqRL!Es
zH649*J)0Lsm8I*5(oFVtiDHYvjO`3qMLKA|beQcDjL$7u^8O1g*ystWY^!ftMOl10
zd$M_lxNh(0Y*w4_@tkG~jIT}V8xLm9Db6<dly=_9@|%a&U`v8wnp5jXwx+T*D_ghI
z_zXGKELO52cXx@t>x7L_&8k}1hfUvdTo$jQer_T435qNE>USE#6dDVxFm6w>6E`m{
zXG?~K)6WFrDxTOmkIe&{u9`o;n`6JK#TIi$TQg9a=?|4et^E1L!sNIY!&e_<y9A??
zLg$v^?9)nZV2e7djW3mOFsyk)^e%szsjy!7p5n+})x7@$TZePnSV#8bs>zwy;$Yn8
z$&5Sdi?SSpmBTTrJK6cqcYe=tuVD*S^XK<|{059h{<1jF<1-E=n|36k3|kmh2zgcW
zr&%?19#ZnhMZ$_o_Q$M;-Px?VxES}ZqMvnwRS3jY#<oI{tNl1G0mkh@maVZ{^!Z0H
z8l<RxWQU4Oq{~rBkALA8wDFAk+d=0azpzEaT49IUx;nNUuW!rCHWkMGMeWc8_@XrD
zz;a_t`O%oiUt}&=Mr_$Gw$EiHCrg4Ev1RMGeo-klH;k`aO0)Z-)@srew_O+aIQ<pT
z2lwdAl#)mEm%}i+P&vQ5TMJS*P|K16qsFDWQ$|((oKl!A_M*1-Cfl7g?<=+hSP|@S
znpsBHUB|W&mO-+5n-+@e$PJ@&!*R{-Cy(H`J21+J?MmMyx~vqcd*r3yIvn_J<M(V<
zSS)t94*S1bNT*nhbHe!CQrg*nT=p~DHCP?&aDH_PT)>FqkBhjB*T+@!x64o6A3bHu
zaz*P)l;+Nql9}18uw_zQWa{HxY}a6NeiJUFZ^{;N6~9-c#`*h_@AsMW**d|BN>=pY
zsfBFgU=fn}+8q+-HWAibHGds09nX7><L<x;NO7$rGB;qOg|OV78$X7hWs8L+sd4@^
z%j}Qo&-NNNOR`OcwDnTLb=-qVwxLmX>OSf@vizlupVXec+l^?%mJEA{9X_|&BBr)s
zOTsGruw>&8O}4WQ_67H))|(!P{<#`P9g@%czz-e7{NRJ-m26}Ac+t;Z!+0#9a@L<X
zT8vrBO<eP8oWEWAS1%&k%mte)*}w`lt7BKKd(<s$Jwa*KcI2<gW`{*#hs#-G(n@Mx
zH7-#X*KWdD8=DW7A3Gd3I#+6UHs!W<-$D7gT0JkzHWgM#iu<V`J>B!?w;Cpw<y7VQ
zmDx_f=z`<?vR?Vng^h0Fib}R)Leb4^#bL!I`{{u<ku3&RU$WODGOc1ufKlh+{7$Tx
zjn%lnoEvp%8kV0FbB7mJMvD8*Q@b_Cz0=tbtG_zP7Ijyf`>D-rLzhftv%uu~&AC@d
zj9DFE5%@ta=d%^l-f`Sum`Soc&MybDjf3Tu?Ag&Z?bw_;D_wKb2e#F)Po%h7k#(uN
zD(Ugh4KqsixLOI(*2%Ccl8tlKbz@hJdju;bS<$*fE3)Oj7d#Grv+$^xj~c`BNpXu}
zs-<vTH<;WmZO-(>%F>_T2pA1u+-5VUWZ1^$g30}}YXfb(_Q2#mvDTCNBgfr=(WJ&{
zma2AOC0p42;QVSmj=)d*%VL4ih01XSGJN-fEe<A+A?FVMFo!J(7Nf@b$ATJD?-XN8
zh1FKgKhDqY)buo4IkXV<FV64L$EPB{KCqIKO^O`Yh~u2FCaU@KJMig&;cS;+aRH-&
zW$cdB(rnfT+B%u+_=>tU*pgvp>`+<AGX6et3)>|aUq@s=C68&(7WPmZC&=FZbEgkm
zIanR+aGK5YT%@K@sDH-692sDW)k+5!=B?6!E#<MIWWo-`kxk#%_e-`HuyDyXO^&O|
z_D&bqvG~0FY~fGv+NTuv^{YEe*mA@8I->mcnzOcKGwZDL${UouT8DD5toWYG*{6At
zTWoc7`HlSdrf8QKm{E$GF|}t#j*HdB)!+2(e70^nd-vY8i!BZ&w@Y-T9ARvBm|Va9
zFOLsq8wbmR9j?O{8&_iX^4BjxmtXX_)@9k|!_uj7CiNWAar&ZjyAVbd;xtb+?;_68
zGMHS>E?;~&!f~r%6wh({Vp0aOCBe{Lgxx=9`HF3$&OYfoS@ajTF3sC{eiGO1c3s@~
zdR?1xn#npF(5JuX^Lum_bL*Wbiw7q6-O5jTZ{jph=;BVDiv60+3zO>}bz+c6^SmxD
zu0vcyj=Q9@Zgcn3G^3_<O_%1=E@jMYKAjDCZ~unvj?Rit`Rfo{3XD1ypQE<JkLF@~
zq>CF89hs9YRcH6T&r{f5=<MU@=VCm24U^A%iw;Ygaojsy-1q`V8n7u(gX4-j3N~g7
zgUM~ZX;38^y3}Lgy0~o#5yRNB=;Go#>=9$6NoQB=(Zx9~x6a;HpEZRoLYLn+y9#||
zi`3bvbv^%LGwUp2cI6&y#dWs-W~#UzqI8yZ`FOE*E2p#G&EIt9G%Y&Yabl<#udBl3
zKJiQT2g0It);?FC_nc-OU7C-EMSa0$)!D4e8N^)GSZ84^kJAvQp1&BFJkCE#`A&@U
z9dwrW-r<5AXM@S(Qq4_EeqxJ*$=7t;vQ;bDM!@o5hp&eZ(P1LZIl8z9J6^r!xI`FT
zI2<=G(`Uc1ZG=%GY*S_&_OP9R6_V^kbS2tV>;6a=H?rZ9c(yF5!ExuFETU#o<I2J0
z{BC{tQd~!^VAPShEM1nQEax~otbk<uu2|}_&4Cq>EJ|rhKdR>EhM6U+*?IR=HZQD{
zWKp~3&trS7%kO-PGNNDS{zqG1(;U9DQ~#|TR~#ny&l2M=j%1618L-3kD?YkuV>XK}
z%>t!fiTTzFliQ`i?Ap|XYW@1a<oW&HpVO+b4Tj16^XGord-CI9+3|y1mLmfuwdJ@3
znB3O6MhrT}wi+g%zld*#{l#_|#_LFGmx>1~iMitutOSm6eodM;?#OYup9ROYcwH@$
ztq!c56gPRr@d|8lFu9!Nk7ho_HWeoKiMrOUv)Gbg#iTSRZO!IoI{_;#*^<IF#dY)=
zMvD@z!^4Un+j3m-=i2i@s(aZ+55%}@g~@BT@27RV&2h1?oKl+UW7m9O>jRV5OQZfR
zdWX%fi%VYXPGXx1qXy)1uGm`S1e*(%OR{e5M=oI74wKKVC47>F?L6#LDK36>gLZ7G
zu)LDpZur@8Hp7dw*KXl3dF_^=`e&bUoCzjhM{jFb_Oj)MWsvf#zwdJ~CP%<>OE$ex
z9~;M&gURFP=CYqrG78PljbYia<u+?Ju;fg(4lwyzSzR&W54Juqxh%@9-|n-;!Q}S5
z@G+kl3ld;*{RXU<ewX9sz~pxMd+WDiK3b@Y`{UP|qd6{77nf&9w|Z<Ym|V`JGWqJW
zt%k|xc6wx`i)<d9^<GwQ2irB6eEt0vk-G}pYnVL8W$Eqz93^UN<=^1?Ro`fB&vD_f
z+}Pps@akjUeQc31xy`0$Iai6z43q2Eulb|tY{g;n^|$uqyEAO`scfHMhx2P(&^VvX
zs<V7apFUt~1(U~@re*iiFs1e-JB$j(X-+9vk%mRpR>SC`Vw+H~!dSNRFuBbh<fu8A
z?HWv87nJCie1I(lCXe%9Js6XZ?FEc34$iOeiOpgRQC<e8`R2DH-*8+OolOgC<YtS2
z$!YfR{<n>-I7~hdCp$;1WQ&5y^WWs=&HJ%gVDdaxyli%wF4Q)QhRN4M(XZEuYtyPr
zbJiDI`g2?iOm3HKb$fPa>!6EU{Lc`vHtnX1tNzVD<2Wu3CZ7kxidT8rM!-zi;kN!f
z+sU8Vro!Ygq<G0wE!Y;q<UY8s*4(pfE|^^RQ}Nnsrb#gQJp8tC`)Q8b4wLJi<FeXa
z)%Ntj<m)Kg-ZB+A?y$~oZ(09{?HEixw<Ui#x0>w)OfF~6xX2M~=V9`BAG3OKSGH@q
z{Mz2C+J?=iOS65yVPegYqDyo4oWZv_E)^#CrIe_26WLzt(mXY21T~Y|F3PLmIOFj*
z#n{4O^0m3(=&T4flg{2;>?QJx(AmPR&qZ6CVRBz8+$}+j<>g@V`J1rjTqn*iT9@YT
z(;N1)S#@c8vW<>oYo)VS$FDAD>!eGwy=(UtHu``$`P}Z@RiQas94tF_xX%ykkohOJ
zc$j=1EN5~Mscr4h<#+zQSDg0*o!u$zy3BD-nB13EjVdhWjzpN;W*1hj@62(lVRAVu
z9r?Kh+jf{-&SopZHnQ!3$>;rj!P8<qJFJTvUu()$jynO9&+RAG*6w7x1e52Z|J}|m
z))Of(xqiQnZHpuRHcQ2Kaye)G9)5-GHB7!XQwuc~W6wL7e7)y<qP<3|V09~xA=QV?
zKg?-nfyry4y`!5nW{ZRc<@e^?P&PA6F6Znu&r7mJ!Q}dtREk|-v*^;?@T|%qwyH3B
zT|md_i`Ek{A*@>nvxl&$AuKV3xncCMl3r7+jc;33-`oTnwVduZ!Pn8d2DQ$yCBx)(
z!4^j=F{h@$r~&yJJ3qJCb&fN=Rg{{N4XM;)6I(27m}>sA<T%@44BIhSC&?CNF4~RF
z{Gaw3E!82qP><GZ^qW?(fjBE241Cdf@W8CtQr&4g>0S+SAE&(2UVk84Ts+qrY}9s%
zhQ;7}j%%}OZ+$igtczqZU8{(7j}O*LvXts0OL1Je_uA_LRvgUS<d3Foaj;t0q4p$;
zJaBP3+iDmsn%TOaSh$z%jxKJ<(rypg%(!c-BgI|K_hWZ98;lx|>-X&8+v;p?*cXze
zdqhtj{OuC{QG5N?ies7Ye?mo5sI6mRa+<EX;rH2Gu$<W8I)p{e7j3;=XUUOtw*6@y
zgYj5k#j%Rp*7jk$1fvGzI<zjGLfus@iy0k0n`-{{yf*(UY6{gXFu7gMW%=d~+hCYU
zifeVE&^@+sI(s_ozydZWOg``Fsx{oi=7Z6~gUi{y+%mc%)v|O*mrlF}X2r1?JsUk@
zbHdtThvT*%+*6$G4lGJFfBpVBti5kEOZs$TY_;NNzA*Ks%Sz491e5Fc;6;8hewtxC
zuTWg&LR08R)wn2K+}~46FJz0>#g)z1^iwt~jK@eT4jK=X67zHiUEH-P-a#DKO_$%*
zejA3e4c5iU^&6p!>s)6@H;$XCiyQw*xn^v0VEM7b{Zp|;RbWff#dV#v|9@<5SS~4U
zX5WQ$%G5SHtc#P|<pfMV4}C9auWMh^#T}WIrzfX*2Noga*K+7j1K8fd!X(=jeQ`OP
zk|CXVP1uTq*Vk42oy`oB&%4~7Q82ljRq|e^;a9C+v@TArpA{yzXTpP=Vl3#Ui<9fu
z2S%NT&%?;fzx3h!9J)C9{3XEhN^z^^_Px$=E?wN2{8@fvOM*p8aV>|ek7qlqi<9ej
z0w#}V>3{fq56AgJ#HGOGap`2q&Qm$=wJvT)zDHsmqJ*VW|DF`L%lm4*^Ke{ln0)@^
zaz^Un@-!(f`n*LKC%0!bOulX#9(X0jkXE`l`FiL8lgI1C^^R3sPFsk$I9*(u!V&v9
zZUjv3*H5FiA7P7!@w(NDgZbL@rzN%8KNCX4&4KaSo8o5Q87s!}WxBYxmNhAyrVCaA
zJA5AgJ@!XswqqgUPUzxBZ!KWpxECSfUc-t@`F%HS@OX}k%oyA*ayiYg0#e+#(R)OG
zbzpLT*;uIbHBPfJOdel~^qoyptlFO4ba8zL?byrK2PR(+c^><y8>n&dy0{-pc3jWq
zfMvoCw`anyMQAux<K~2jTd1=}2O5a^VVTb4{8q!{{+V?Cg&3FIA>xvCaew}HiG~}s
zoQGjFSx_AsV*5PnX0d*G4U1FFs@nE9XO3Z4jkDpG`|GG?u{OdsazmV0M=pc$xZ8vR
z0$;Sw+6d!1kcI#HUgVdovo2X{E~8M2JFK&}*AEwF^XhDHssA>!U4vD{4%LtHi!Aa)
zEfS?^GNu#n2aCae%bpiAVx#644dc3#MLug!8`WH}iuj(=qy@p8U7N&t_rffaZGZVr
z^iL%`op`@D#r;-$R1a*_G;J_$7qY*%?Mr4G45NiA=l8K!o6>A<Sf9ZCQA-@0Hs=nW
zQ2Nu%jSo`bv4`xhR`2X=5js2HVzzjO8>zF6|GPoMzFJPR&W1ZX(p0Hhah?4&_jW8>
zl+G#*s@9#YoX&pUEBzic%!nVPx>Fqz){Gm>anU-v*W3Gs%?b;b;(pC|brxF;EVE>#
ze|uhvtphBRWM_JwAHZhQ<=6b}{+DcVy12O+Q^Xo`1WY~;{d*h~<5IlNvKy1uahl_F
zHl<dtx@-=ejcXM<kZr2YVs3x`7h8hP{^;;noQF9&YhL~8R~+Zm*_5~nUD+1u>}&52
zqVFc^%r|MrL5^Fdv)<!NG+=Y-?8t{-X-Zf7*=m@4ZVlfw+{3mJCZE47t8F9Ll3_HF
za9{dvcRqSqK~2-6vpmx_4P!e7qk%!h4d^M#;?>z+-~4|#?h;JyyE}(ZJ;&yQ$$hZQ
zvUH!YJ%Y*gYZ69(Vb@>I7cjYgTjow4#HM@_Y~QV)MYsBD{j$I)5w64j3v;WonRNEL
z@SxIcxpirJkNqv?Vl#{yg41+VZ*+y@s_Npd{C;INn-wP4uYbyZ(U)R$Hs#?VC&$I=
zY+}E$)7d)dtXJ5N+t_S6TVpOGuIV_PmA+B^DaYA$mZNaDcWm)6UJKK>^!t_tKeHw1
zEcyDPTWpCi6Lz@Gd^hua$(96@+jG&n6I<B!z<7;9`5jFtEz0TD<ySAq(d!)N)5Yz6
zTKZ467clueJe-`x#r95TpA5WHk}WJtaNPOc1~*$4ovm3{jHXJp59Zd{pLdM?*&=n;
z|6t2#w&FT_l)2%2wsJb#J+Cw^0oDAf>MZv7<`lL%I-9W6v6QW`&P?-fioV-QXSp(u
z7xQ}un0#)3wK%@uH2c8h^S7_>MKPzw!+7qebGzp8P+?PbcId-Dk2y^zOddm~_pH#K
zZJEy2N0p{2NNtxSnA~@3MQNX_k_?mk;Da?~j&s}zm|VYcbDMW#y9Sf%*KEh!C2XlW
zyPKG_oGmPC@R(e>^BD1bB8$%QC8YM{xZE%~zaL+{jAV;~MPY}pv2G>v?`DhD#l^pv
zCf1*QVDfqB(6eJA$Jt@M)HJQuR@fTb?K;bL9!3)h<wv%=)?;zKhiB8${EPwuU+J;U
z4deDCyZ6=fcw(~Rx;V>)<#X69u%g(Z{3z~rlV_rw9bmlH(C60)c2AA7s&P-Nc5B9I
zTJgv6j!M?*;qi@Z;ih04(akE_%nQq>#`()~e?@087No#v0<xO?`K61PKZVnb$)T-<
zshp`3XXIc@g3+MC^}FiYEyn9hFlr=Dv&_T0#W*fDr*<zxX+A5|MU2S~821UXx<7Rg
zbx49?35_&OYP(Q+^hM`kBdi>@T$VAf^VDX$1bd;Hzka7nY!&PI6S>l<@f=4n^hIfU
zVV`2lmi1JT)ohPoa-VSg@J#fHcRDLM&$5Z*vfu-c_`0R~Wj>feJby96mZ|yq%ei;?
zfwvszfzcqv?YV#KsPEY#@W;TYyj)H?PG5A)42uigceKWS<;2?c*%I(!Rx~hBnq=FT
z(K}oGad%*ORkNs8qDOvlzw!=77cu2WaV0*gzt*Sb7m*M5IjUK$ZL!_9Gcgl3sySd*
zd{6mxq=SJkDyIj=*8|yy9<^%`lO5LC<oTW&Y{zsqZ2bVrUX44Uvuyq6i~i|_@t92c
zjV<s<+>>0>+1A>{7jT*>FscyMo#HyxX)CUW7drd9*q`q>PKnU2BZ|A~DU^@R2CIr4
zPIF}9o)K(`uw>QzZPveHl(-Lw&7V%8j>YYnr~I7l97lf~uZ(K`a(1a*O58JBVCYUF
zuEe*t8XVWSfHuxkIqPkxaF;C>Hd#&6UzT^33QS}>4~tOEpWms3@+;UL!759(_1Yz|
zMls{V){06tF~iKP9M>3Tk*x9AQ)k#lz~nYtbF20Twj`LGU(+voiMi1Si&4|`*P+PD
zRyK}{Dws~ZKGq2b8~*T7tV7~p+^@-cpK4FpE7U(vz_<=%U(Kv4#?Mq3k4t1V{+n9~
z8#T^cD4jwDqx07pTVIKm1KCnxoFCb^x2aaPPKDEn&xs;CeXwJ5wqvkI*x@vnEz9#i
zwq$cU#U|Mo6JLsXC89_=@t$Xz3(hUf7R_<dFpeXucR$O0wnP|@gJgyeb*8Z;NpUpJ
zBp)87%~eIUHY4l$O<vKS78otIsSecHuN8Y?#zt*3CyaLJS|KZWXu@-BRC7ylHXL(=
z=NEm@R4ko%O_*$Ir^RM$)VQfI?n^y!Y<=|e-`SF3aoC}<kX^m`lelip#nXx3Wh1Ni
zeEDx2*9pdbuon(KdD(Oh+Z<RO>`)!Zejjsd9@{Y(pLeonxwPMRDpx{Fvp1}m^|?5I
zHW;U=+JB!-;51z@PLs^I;8{3ZSjlwa_Y~=82F%<M!4?f0gB_|nnfp$z)ojVIezFz0
zBCZv4sdVa_Bq)v+f}dqvnT_MjWzs1QFk6|D>0E5CvcXpDz)5k>WiF5TA-xv2GG}rN
zjw@bKTQg9ZM*p~ZGFvQ+%Sl^z{-W*Jl3`}-(0QP9oW6SGEw)QAZcnl;`@R?BO9Vbh
zC{~TLs&O%uCnj@T9IU8n7AsxMu^B7VC9a_8${fiCVZY<su1nb5unyRvcCll-ul9kG
zY~hu(*L}(Qb?-(SHO&sNn)sgTKnE`$yco;ogslv;^)MVXPI)Ni{^%;&xg}fge!7<9
zl3`gg_{%aJ2e%r|G-f+oU7M%LI@M1q#&!(G^9q?Mx!o4FYc+!7N`7_fB%2SG6FXD~
ziW~Anmj!GuVBDT$+uY%zJtLxnt<%I+)D&vF)PeE(h2lo<@z!PQ05f5S^PA|*B<8U`
zFu5%I-Q{|6Ts({}9FCjvZ(GqW4xQbb|M(rpCFt_o61n^YTOv%ZU*u0crnBvVQ77R1
zdMzycfb9;fxMXuC(z|H=bq}wpT@O_E|FxQPkIe#$#15zV=fdji*jmBlvMkG%L-Zv(
zj0OgdThQ}Q>aGg)>jYRK*+#CN#g?RtEAsQ<a%>)$T!%x`mOf#-ql>%Vu$g#{@(yOk
z4{}-Db8Cuz9a&3v-g`8(;z!kTR)v+p_Z(NI^$1#mt7e1o96)W>@2k6X`Kz{2m*&;w
zFAuP7)Y*nxT}8VbhRJQ#vgi;8$6bTTZFaEhBr&hNgPHMzT+X+-{t;z~tR38D&A$J;
zJ*R1feJaI$-F(ytwr()9WcE9o>GDwPHx3phS;38s`>?In<rg`BjHvrDU4F{4t0^3J
z2PXHkyUSXMIh8&rUbc3L>sNAIBrLa7mgl>*ImZH%`)AvARln!B4lubdovArZq!|yB
z&wHs=tzK~4YF%7``dNQsI|egjhtI=-g8zNTmI9OOaQDw{qAX!`gUdOzci(Ot7X_2A
z>F%3u$Fs%4s!RFhTE4dxTLR21S*=rVzh+B<$>(p&*xPH_yfC?4jwVI*V|xLU+w<}A
z(_gVg)C<mU@zwUU+*12XG)(ThrAtROVe15w^BeT@$mVS0ba7=9t~6#_29wLO;lKDh
zY#x~0uZ!02N|&fwmTNG%?nUByf5R45Ke!HcXZ5MWRvadm^JVXYA}&T3mt{_ABge(T
zvS5e%M4aLBIJOZmgJkwc$9A%f)0wiMFI88q!&F$f6!+e~>>=A6m^@cq{ZD%j>oT3C
zo_#CEkc}|8oUZ+KZgZN+Ivcv~%P-gt>(czR$@WZa=V5Z6zhhpWku6mhSG!^FM{J5U
z_?m89^lneK+%S2JELnWyGq!RtxjoNT7)O_f+GbT@@;u$*$jkj~F*?h!BMUXJ8rMyi
z-}r+KV%SE&XrapIR=Jk>FSe;Lxep!~^p!}{rAu?d1^XP1OV-6Dmd0WnU+MAhye_W9
z+F9b6)gzePKliVwJe1>14T7(~%7#PYp3(x7&r$ZiFKOsg^NWQ|!1uJqqzh=$>y9_r
zys&81{A;k^zdiCLTX;jfM-ZjvxDpG;)MB$W(w;d|n#Vds%wUUZtUY5P+y6M`99vab
zIqYy-*YYf0%4UOAmh$Vod0H~t!Y0AvXXSf)#l6!WSY;{A@4mZ!n&VPoxIGkgh`i<h
z8`E?iayJXU{&MYjDb_@hF!?%Kwx`!sPBTguS7hC|t!x$;&to(Rx2jt~oQK9RZtHkh
zo$#JHIL-m1pQpAat99ajRkjx}YItfhvdJSxB(qs!(kTa3^T!oV_*Sg1U%=$JVR^=j
zIl$69onn>Zj?ajtZl_SY*kKzbE8k|saW->{bo3T_QO^8TZ{%W&XsNCB$Kqh(@Vitr
zHBB?D55A}Rk>woz?IE_QFrHV){>hc}4_gw9E&z_3T)BJ_TSTjLN~3^{$F^m<k@wiT
z!Ro1Iu~Oe}aHatb8){ixFfI$(!}8AcY~i1!6Q8Y2)@x`rF@BDKaX%v)SmeC8??{3*
z#4#!-+4pgU24JJ+mkR43nWs`JT>`4bwASwND6Zs@3cs-}gcZdOop-W^u`x~Al3{c*
zIlpIjTI^#px6#(L6LIi}_YD<W&94)T+mozJ&N~^{j={{>q5Q}Stv%SDEd@q{4cR1Y
zt1qk;&1R0(>OfX;mD-im{Oqt^YMfP#i)ci%n!haPVKgywnk|;bigk#ot@hdkrTJUm
zs+~A)FszUi_vGT;ZESO3QIb6?_TO^0?J)J4RxH-3bTIIh9$OEL%R=_cpyS<$$!HLy
zL5kX%tXN$CU38di8H^?bssq{VW0^!>S{=eRhOq4+Y>&?J99t!>>0_`j)v{Qv3E28N
z?aq&lTF$8U+B`<~^hUK4Y%wr1RytHaCk|FASa%d#To-LFCQI4=quM0&pIv8v_dF@C
zm3W=afBZHpr|E$4d`oG5l2`joSf?&-`ml$uI4)6VWv+kxKYQl`nB}<s@h75DYEdM~
zA_-wB87iY82}2mhw)Us3_OET#N*Iz!7(x<45lTh;hA<>U2qA>f(Kun89HDdkzTfA0
zujjqr`+c5!@1|%w@6O4y_x<etf8E!8-Pir+v4x3wnWM4GhTVOygqyFivp;z4U}1|j
z_EGnmtA$l-?5>-i=pn2|V{eVPdZw^ijU`XHYd>MDG`91!v^rsHG<N5wCszwwr?GWs
zjdg9eI*nbB_uv~6u3lpoF8kRXk2Y&;WtZ`-B%F0oXuIFstNjpRF&ew#x@XT47OSyI
zC%rpKSQm}$dh8YM+&)fY_nx-sKnd4dV_93;b`=({vABQS?1oFwSV4!IGbCK1#%`}Z
zie1O<D?>GQM8%gc3rp76aaBEB`z%FcH3wbe)=Rp^vNwH1m13uttFaY>U${$HvBuIL
zUhdAT$~Ct7=##fdxC)K!|8UkaVU-%oh#yJSZs(;+W8ZEb<K|_i#(GRX+MOHD(b&1?
zo$H31udyB@tA3L77Hh1{>_gn~uUccLytSsagsaim)cn)k@u5~@ab^GbRKl&&*dIj?
ze<5s*#&&O8_nfeG8hiez>+Tm;r?G$U!CRr7`mER3T{m^QQP^gU-4xrJCZOF8R%&Sf
z8@AyRnnpH@(b%-L1!=-!HP)^CdpFK58hhyOY7PZ<oN*c(UKH!fS#OOk`TStl=8M<Z
z*F#U6EpaAj?BOe3cgM{{jon(7I!?k3)z~gS^x<$}=QCMjOK0Ee+6*ZgyI?}AED4tm
z7K0BQr#a@Nk8SPh>s*Z$+`rtNKNM^1)(-8Dk~qu3Y<nUQXVNLtrU{#(vER-rc}G~4
z#_qrS|E>`>TVw0epL55}`5N22=Cef-ZmGtWbokb_6>Bs$dz@|J+V#0oV|x_+%k^EX
z(bz4o%yaeidW~guAAgnPrCwtLN8IL)9a}V3uzv63BwWnJq4l}&)!mbXb<)_s=Ug;h
zSe(WlJ^r8yVSP0A$A2D67M7r~&tK@^>f|JiP5mHvH(|2IQj33q_2kHBs>ZfVxM!fS
zT#aR1zUVVyWg5%d^z9&F6&l-h$GDBcrfclkCl;R}Y^KICI?p^o*j$b6w&Qd8!WL`n
z<Bs$C30tPI&1=THI;2)(W9~a4Tf(i@*sTjE-7ajM#uiSx!mXE$8mm60Vt)y@S!3;c
zOm=0W^(CRQwBYp7?@G8>jlEg@t!p!M)7Y-F+Wu3*^#<D$A4G@Tc-e2RTqkPbR_*<^
zE4#xrmV3a3G+FKbm!h$qzgysraakIxSykOm!WC<*P11Yr9B;D5x*r|1X)86>>BLsg
zN}Mw^R+%`}wV~%|EMveBH@yWKTmJktYbDNVjn&lh)-$K<%QcpMS-+LSR%xv0+`HZr
zwpL@CuYclfVRagNsczIpVVl6z_WR(2XQl{imli57S3Mu&_USGfoA}E7V<lWqjotBG
z#i7FDH8#HXq|1a2)L7jIQ+o>=s<B(f7xWM|LSuD*w0cNby2g&0_S$e^`5G%c?lE_~
zE!Wtn<GZIyxG5Uz-esZN4pkaE^UVi3Nx0b>D>&@TQepGKIG{^E+Uwajt`t_SvH3?0
zx>{JR#*V+c{d!?*G`8D;<6je22gZ&g>An2rd-1|HX{^<fdvb+Y>7n6z_5G||SUZia
z-f+#s!n$Z|@J|~D3+t(|-}A375f-np`|Eyl?WKVl+t}{pKP22xjkP)A=BdI)Xzakx
z_i@L#bdB9QWYUikE+0(oD|dY};9Fr+v~aVI_|9E}uF}G_J?M`N2{&I0_r)<!#|c}i
zv0LXn>gtIaEzWbMzwn@hTLY%b(r%B;yGK}^7H9Wg3nvNNq_IbLi+fR+l@Z$Rn;*OC
zzrxySY^TdFb;ph_8oML!9oL5Lsj=h*%l{*B#)GMK-TjGvwZevK;l_3@J4V<DFtzNz
z=Dc4gEK3VFsq&%kgcWP-w8RZx3Y)C4As^5AO<1MIR_qsC=bE9h1MA<qQ^L*B*vDV3
ztPr+9WB*+6@aMv+!PN5gJucntE45m<U+0~$hlE?Lu`}D=)Lqy*jb$BKv`*MYjZIy9
z#&ltuHTJ`I{SOk>dSs})oc`H2u8xcaQ``2`8z;MVa&IuTe6g?JcE7}#pvAeU=Xp;E
zOVZdckM?!zI$2|nW`Dd+!lmkLr&kMv<$|gCyz#E(7YM5WQ}el^rox@)RB3TOGHRnc
zcbcuS+lF_%RpOklvCe0o=+4KMf~k3F`{Il4+;=6InwJfI$6Y9KuGQk~cI?ol!s;~k
z)Q=rM7Pd)aUv&K9X<=4oXnOY#|0-QrESNg3jQdyVTw&cb)_d_~^Mv)**us&gTqCT%
zmfmkCKk>M*BrRP3goE}ImaMV=besOWuvCq0`Kh`{Sgyu;W==mtSeeF#PFwqyunLW>
zAHHR@u<1HWdBJ5fHTFSL=GPK#uEt^p*X}KBvBrLU`?6SJ%QQAI?y56|)oN_Wn?Kzl
zY_-O&F8%ju!q#al_xfjCJ-<<7^&iC?FX1+8?31n&Tsy0ER;aw3`SppfO1M~!#Vpy!
zZHI0eJD|McQ3=;uV{LyPc)qay8e4Su<K2WMYV6~?$Gf^`IGEbU9zXoO1rjb5Y-fBB
zTdI7ois8a?!PIqx%x-TTCaiKyXxaC?`;wl*W@zmCk8(E(o1?MKrMJ6!Vu8kf?C`nU
z->WsY=Q;JCN}S6zcKBV1?wGSmV|`xR{Tm6lR%5?rf93j0>NK|Tryg%gxJ?=>+5ebf
z!mRwzdU@!^TGxhdr?E~|AGl*&7mb}Vd~LeK*;8Y~zw6|-L%hZY-tu&{gd3=_``;|d
z6*g33mtFAPj>1NOsrvfzgMQs4EMH^4U$*4~VN<j?GuwXtlCUa`{q+0B@xo?nY;4hh
zyM@iy(i?bV@NUo=E!-nVAH2VWTdA?S*AI9^*cy$UGHQ@J7O&S>eMw@BgsazC>u&Ct
zx<zAaPv3`K&e{S0VhTcK;^}#1UkK}@vHY1oo+2zxW2Y4lzF1fvFttw~eRP%UyBMg2
zoALQQuIvug*lw%;ah1e5LSsKawYxiSOxM_3PoC%M>wJyHb^VIPw##0wu>mP1cM6-L
zu|HZZa_3c58hietn=X@Zvo&_(_*L#4eZI!VPU}`D;g)JFG48}XVKo{{ed9HE3|OhL
zyT1;e<zAz)&%Xc92@>aejcxpTq}vYl8ngDf#??z(G<Mpke0P2uQy3~s^J+hGWxkWf
zHk|TEh2$kpWBYDi>z1#N#;h6VJul%BG<NUHXMQg%Nn?jynC!M+vc`5yyWgGvrE2V7
zEB1X~;>^|9LsR;={;V>MJ@9st+gB<ywkf4ot;9K9WA7eax0A4$8hdZ?H}49YtFc4h
z?N0O1mg~hDOYhOs?MKTr_RX_bxbu}-jm=y2#YBm7wZ_&wan@JD)@f|+hE1*=vQcCE
zyi(xy&CMFC__j-e#M!ziRF)n&G0V+otj1DyzR<PHyJ_s*Q_ptiPQ5iYtLV6)l3ss}
zom3Xw*PN)a2NqrMx`Z39vFvN#SuHF@W0#No#GMCZX)J$foon+IYb<Z}r?*L*lQs6$
z&PSIEtJK)0Pp!Lz&Cpo?|F(7gS#vbDL;P*7owYz??>>9n42iQ^W7%h1J6qUtjjexh
zO^UEp8k<)z-Ib-a8na?ET|Hl?v2Jzux;Ew}jg9(ar!q;;Dh`#Ub?4qoWcQVJVCq=4
zU&nKM3G1eX`)R_3uKm(mWA!}_`&q*E*VxY2f9Z|^i5gpcYj<}(He6%7>|?p}+Z2tZ
zU$=aoq?e_!L2>8*Q&_Ra_I$jbTQ8F}mUDBwt6wTLcGs>)xwifcjpcs0aEzokM`J5H
z?c>g;7ijE(+n#p&X0^sTT+^Y4#JOB!|K0T!w?0>C?67gy43cnbHTK5P)7|-4oyP7x
zrTcUVw@G8aoFD&-Fl%h6EPdGdW;eZd8oTS8_2)^rE?}yh?Q~OJp|IXMvyMAPSc1lW
zTzQ&1-yEu?cjM#}7D>1f8XNI(-W*}+8Y{Z3!kxe8Yi!~R-`*qP$~9Iy@?BRZrfBS&
zTMxQc!c}Q3Z*^aHT$!!0yV|UG_lL{}Q|s)l(cRs-MYYC$xa*()k@RXccFfKHb;s~E
z8tanY)*Wx_H1^ZR!#Ycxn>F^x*O$F2ET$w>CNeH5n<cChSjc?k#aF)<)<<K%-}TZ;
zVM!Vr^F;8DtW=GC|4sZA60Qua9X`mM`Ic)+&lXmpu^k?M{xo6JHTL?6zq)KDnA#3=
z?sYa@(vY67g<Chd%S{sJQjN`8`>(0OYBcu5-iNz3=1PsVKjp{=B-|Q}<-M@8>(g1U
zv1y%dpCjSwHCA6zcZ9Gl8r$jN1Kto8QySWSy{13iPgtDB9{6BcM_~zIYCF8Ldzov4
zC26d7Qm;oPTr!wi*XMq=u}E0D#x{O^+)u)awK&gy=%M3;P1e{04?UkFtWsmA+}H7G
zVKX!~<lBiS37ey_tQ)f3x#$9ob@={t*M6x6yBv|o{?C`n&v)fBp)9zsxe9-CbN6@S
zB)tl-OO$Y%zS`5Zq1S;OZL|2qoAGSbZHy}uUB(65;Z{Z#_@V6f1lt`?_7$>Uk89)l
z3la?BlE9>m7_R8$Z{2oJ0ZX^zOiW~<?@vxT84ugms0O3)%k;=TSbP3M!fL^iZI+mL
zJDzdvuG=JxTP4#K_I&@H>V=hq(YeJq8SY;l`nvPDIbbw6S=VG0cg$q+c3vh=2o3lB
z72oYAYz|l)K1iHDy)%8Iuo^HmpXb)kbM;wldGOo>)7xQc!6XTn0M<c?^Ou*G>?>?2
z7==gD`(@yBHwa4xV_ONER`<hi!cxFy+RQ26v3FHg3abY@R0+3V!a1i1i<{WWqQgb%
z<@sA%yX9L6wuch#humk}@nId9$P3GN+g_u3OPrg*E>z;Y#fo$1+9{KQ_dzh+FPplr
zl5lgt)bgEv`D0HCo3Dktb=9u!I9(4W`h{`6Ir_e~63)7`mBsI*d|9pT*eq-&7!7e@
zo8tOiBdi{5y27SDANRSiipjyVAB_9u6Z*NbH1x7ypC+q}eT!MM%T)^&hu@|BmVETz
zJB8JOsj`&Oc9d)DCtM!f=g&AF+IRK`5^f3@Cxa5_@X~8tS(*#Rj0xL3wUWiP^Rg7I
zwZgL2J?HAyYOq;0b7ZMq&JC_@lX6Ay4ix64W8a@$-5OI7D)VD^O+FHTVy71mruNPC
zgGWpjmI9{A%jY+p_=T`)Fgk6ejox2%*i*t<Um044PuGn8NmvY+8g9v^W9}9<0*sR-
zsh2m0RP80K7)<R)^LAY@Us%jlq4Lrz;mM<frGrhg<8<mQvG7)kvR(Fiuo{JJJfz(#
z!WLiM%6&&T>$CFR`z8si2b-dVyYaVforRT83F<-SchUv#yLQhSuy{LMd?ML~XaB>j
z*?Eb%CU~}m?AlGQv=SB%mW~gsYYOHShyBA1R|O`rMAmEG%%OPLan1pg@rZJB#x9>+
zEX<nP%9VMt>8aQ5BP<T=5PV=ekWH+A|3hKPU>q!%7qTb2EcicRGr`VQ*p0CR+%~G$
z*rJsBcO=}<YlCNZ80Y)XoRcYRF__3F*?^}CU724ECh|gd=WkanlyLQ6Y8kG7VO4)&
zah1WlOelOGUo&^Euu8B2_`tH0y*_Brp2BLt_E%WqO>NE*RtF|B!En$2G<%Y;{Of{s
zO*Z7ICG&(;fyM0N)aO0;a&*%0{|K9TOHk&?{_oC1+%X{j)?mGm-7xMccMKQ-mVobA
z2C{E&-zy0Zi-KPTR){CtkL>bwYux&@W(3bBk==e(aRnZBxGXTKYqILAu5@kF3NQ+t
z#QEiCds8IsaJ67Eb}-z(2Au5b>s4SPFJ!A;@3WhP>v>ynU5#x2&nA}&iw9G~wcBt<
zv9Kv%ZSX<LKH;_j?$}?Yg}d*7UulZj`CG4r+iS(YX9%m;!hP5EBea+kF6s8re9l=m
z>;z%M!6<Z+m-}8RbK|T4OR<^L4vUBGxkSRP0Xt7&D@(r{E-e0zp#FRSU#`p8JX%-<
zSZ*L3*;nz;OcYiJmZ-2LOHa5?SnruZxn@U5{dIMXuw<|td|=y>ouAR|cwyCGBNaAl
z%!wZf>vm^QUKs9;l@(_SO91O>hl{u4Y}K~-S7GU3)PIuRTZ>+&8Ed!EW-#f~jPs+z
zemO>1&so8{^vGJr-t~mA6tH3VAaTx`f3d5V=7UKY*eTbZv}LM<i@hsoGmu?B`n$ox
zs=$~y+x9^`H@p__rnd^L#Ab;$`@b&tZ;)_FvxDb-8E%*5qh1$Q3?{Y>S?z}t*sbic
zTXzS?02<_n{`(Aymd(<^q;HbFHssPBg;jvDbFl1WUvzkTtgw18kx#PJ7f*aqSkHTc
z`6L_NbH|s2C4+Ur2bP`exT06wF(4PLdw@NR=e^&|&cnmbXC+vc%@PyIF23k7*GAb0
zMn%gw$u=%a-vbXjT<d#7<6LlMlG}bg!FE@|6}Qh0${ARW%@PwI!E@h_@BaV~JI*;^
zQU<a&zyAFfVbx%r@PT<DJLbij(ZW`OB?K5J#EW{Cy7dw>C)h@0N5%j8t%S=3qru5I
z$@cvCyIq8pfk}E~PmLRVu&_$7IDC+BpPyWFiLm)#(vKd)mv8P_f1|KfV1;(L#6+?c
zSD){;d*Xe;^vKS-Y4b%AZUk5_J6yaSZc*#J(}Yb1lQJyAmmOcqzg<|R#tQcC-Co!X
zu-^E<GEm9=F=??YyES0aMr3b3|C!szdfy*Bqe(XUrdo=YwFCYofvIt}xnsi$VfkSD
z<AbEP|FIJf6jlW$a>h6(&FsalZO1tuO!D$LzPqz^$J2$yJ`l_cS;-~WekLp)>_U8C
zAA26pWl!f{F02ZyQenqm@vN)sy37s6S%bg%{n!0ENVo*B+(0<8gDSQ#8atnJz@&}H
zX6;w{FJZM{v+;p>A$z}V<qN{H=7olP>X#Q>+jKfuA3I#U9d79>cfKm&s=*Fd*naKH
zGKAHE#RV9Z$Ld{D*gfog#yl7-16k2?rTM~&!K4gi$Bdq_R@h9infSmmkX0Rj!KcFF
z9|{fE`Kpv;VJToz28O$6`k*z!D#0$n2gdm_p4Tql|0iK}U~x8!w^{eTBd-+}Ge2mv
zFUOacfB)`3g(ZMVoUh=^!Drw4zOb2KUGaf3NOr=Eci$4W6l|cv?zy{Hy|8+)RGTFx
zvH@<tf8*=IhCdwae`E`;T6&JK6fkKcvinxP?ds1;Fv$y9)-A1HlW=pvBrjxXqrWW@
zwhl~m9a-gV7r64-<&n_z9!x(sPr?laQ{#-8{4dv6QUx{?f0$?`Co&U<?bU09gj)w@
z>ld&$@#W#qeQ>p~da#lB!1j9w&*>{pcKgGKM}uea$$lL0^Ij6J5-cYWZZ)2#rWd&V
zy&kNK&EgZuX1z7-Bs?tYmzV`X9Z7b7-={YSivy!^&%Cg~R}HRMC2S5@iNY=}y>7O!
zP78xJ1H-i$cjs5alEKpPfpLC}XYA;Q-SifNNg2qljyts!4?CY-9)n%iDj2Tq{Of-c
zma?dobq_vBocCRLayMa{!KD8&&Tl#|b@g@J;^4SKHgDy$TO?c(SZ{owT$BBK<+bkk
zPz=V3ko3yOA9$&ROI#AHYliE);nH)3rGOo4hjZdgyQr33&0;&u0E-Q<Pw@QusULU5
z!)A-YV#pvbR1i0O-ourb8Ze9X0`?hLPD%9_c-Y};9uLOJ$;iSR>vk5lN@E`$IN6om
zbsCGiy81f_R}W_A1@*!>txiw4ZM0cqd1u`+UBX#Ugoab&jM3Ozm%X=G!o_NA{qe`u
z3F`vp)LEjPm!Soxx^{AJu-5oPwjcAk;+R+21?+n11ICIFcFqOE*!^wRUki7{DF;pz
zmY}i4FTXxi*g&wI@Im6-Wy72dVM!WGn3EFJbs9V5;t$74xD+s_uATB#to-<XVd-E}
zzIFIAXYO&;!ivEz#0Sd6*LZ&XL`ABwRbYbyj2*AzQ(v4QEOu!tD=EOf!Sk_BxBn(A
z9V`|JCdMWwa$wji=Ulh16jz6`f4w;NX$e=cEI4PT5Z!a=(H(`=g0V5#kI04}*I`#-
zi=PYDC)pkc_H}h#wZ;lR4f^$KG`8`bdFc{ot;S+*%yP%ZRbV0$Oz+L=3tXMG22ARj
zY}3;}aj3I)z`wN`d*#2o77AOZv7c8BI8WGmFp(F=IsdbsZX0a`Q}c54&huZ8aGSJn
z^#?snHDl*xi^j@+zvpsct)CB#^Xd!k8!fDz#_r$!<{yN00&9a0lxya5?#}x?D6AWp
zT80~L>Up=Yo?4u*cA3>vSRXL8KG#f&aoaXtV|SjmhpVsqYix&I<NHaR30iv3?$K_I
zutc!7_#kCivUc{-!ji$HkFk96!?sOP*!TDxd&ABgBJH|P*I2@oQ9laH)mZDByScJd
ztg*9pe`%P6E7zE+BP$ff#;H1C?RW`S2`2SvXMzAfEW>oLI6PVQpYc2;K6sXG0ho+A
zWLwrB^#&exxMhZLYr&j4bK=Y%wanE$)(euC;>50uEbzm;w02p17>fbxguh`v?Z#2U
zbpw-plHFrHvXYo__5l+a)Wh`$qah%1o-+QUV<lX&lAb*|C%_Nm%u>=LQ`0L`($m9D
zR?;I=)0=5XZ-JKHWo-^T5y9=eECbsGzq1T_dbL`5>3eK>R>G|}q_^3SUQCUDdY!<e
zKA9Iay?8KbKRusGVA6hMYWYSO(n~j_H`$P0l_9-3hV&K~(yKM3x7Lu}Mnig=4e51y
zF<76svQYy+l+WH^QlDh1d?tWNf6&7vf=T<4sq&d>NUvB+Pi?;nFp*C^z3Ezds=Uk>
z2GQOUC>tLv-*Pa=MhRy-yoC3Rv_c?{aFbsS=pNkjwKpRR{4mZ6g;7_^57`uj>ES93
zY`VhqII9e7hQiL4jNr+<%v6|dU<EkYY=u1;_?{24ISTuS#^x$aFW-CvTcEHBTAYg&
zwq9dP6{eT3T48!#mKj)$fh`BKb&rQktTC{SZk*wAR&QXN3~aN3Z80!wxyWvKURoPi
zjDfW?uvi1@WMEwkteb(w8CXvP>uq3t3@qNj`Wsk+fekdUL<37Qu%QMv+`y6zY=nWO
z7+9)-r5jk5f#n)lzJV1RSeb#98`xw6t1z%B23Bcc(+#Z3z-AcOOaq&3U~>#?u7S-r
zumuLT*ua(=ShayIGq4&1TW(;r2DZ|`RvFl816yNYYYl9jfvq>NIs@BiVD$#J$-p)n
z*cJn`UNMY+1{Pyr?F=l|z&aUN7X#~NU~vZ4)4+NgSRVt6H?aN&mSA854J^^Xk_>F9
zfekmXWCI&vU?~QcYGCOGmSteM29|GN#RgVpVC4oj*}y6cY>I(Z8rXCLt1_?|1~${c
zW*gWX1Dk7L^9^i)fh{($r3O}QV9N}w#=w>vSgnDrG_X|$w%Wkf7}#0^TW4VF4Xn<<
zHX2yHfo(Fd%?7r`z^oO9@z20w46L1j#Tr;A1M6a7-3%<wz<L^3Zv*RNVDSdl-@p<K
zY@mT98d#En4K=Xg29|7KBMdCXz)}q?-N3R8EZ4yD4XoI}$_%XBz$P15g@H{muu21)
z4#vf+L=V5zEU?{u*aAbiXTWUVuScA(gLUzV^GidxpA6x4eKoL;%p<)xFu(F04(9A}
z3HN6m3+CsqI|IzGe3ux)m4I=*$*ZoXgZbri78n<uy~51}^DDz*Fu(SD$-q_{*w<k8
zo;{Dc-U8-VXR)>Z;d+7jg*(;|E*Z?Pd?Ug9>UuJmU;9l5^KA!1xJSVJ^0Exfug=~z
zusSfmdf5Wz*X}W|`RAppf%P%4!C-!Mc7`Ebx*=RKm|q)BGsHO?%&$Hl2lK0!=MC(2
zFkig{<|h;NhB&u?`PEsw*8_XEJo-_8Fu(E*1M|!0NHBZt%p=ar!Te<D7DKql!2IO8
z2F$N~s|;)%m|qz-8`9hL4gY$HGq3?*esY!!=2yOvV1DH*0rQiy%MENAm|xlN2lLD4
zGBCgPTLtEq&vgb?57ymhTxq}3KfV3I{K|efnBQ2H0Or?^PByR+V19C44CdEYrh@s^
z%k5x(Ww;+~H=lZ03})|R!TK%RQGU3-xzxa_4Q!c#)qpwc;faY%_lo^vxV6n<dg~O%
zy;wVrJm4f@)|<g_`{K(5Nn3sq)(xyDK5)Or{&@cM?TmTC5*2ok#<C2o(!drN*eV0t
zWMEz13YJ07=RgBXH?S!NHs8Qj8d$x7b$Z*s3<(C7YG4%xHrK#v4Q!)<#jf%%Lw^HH
zF|f%7Hpjr08(1Bf^driP+8<)x@n^jaY^Z_d8d#-)%>|Rbsmpb(fo)V+Z>`_Pz8j2F
zX9-|ZFJ!A)e|P~Nwtg952v@F!`*~6D9*~(}j4Kg)W)H@5pV*H3Nt`uGoMfu*S#Mx5
z?*+@ChwEct$p%&qCS_-wA!RVIY6DwiV4DrB)9PUP4$<l*!N5`#)<+9h0mkpB=lR_D
z#V-%xVYlr9L%3C7QZEdr_LX`AYxjPz42L0{+P3iqHp0Nl4QvjW<g+i*yYRZVxP{g(
zUyZ{0;XAbq>lBs%cHIxh?j_-@4}x)$sr?~NV``j<8awWoFQ!SH=^E>P%R!@sRcK62
zZ;r;)IBPVf=4GA6)Ns~^q2*J<#c6EDeuG&Bc6}ylOf5sY#_G~K-!9=MgNZ(4WU5Te
zF|b-KPPK2YH-w8>6D*&-|1<AZ_iRf~FzF9uYJW&p!VLmjvUKwrDMLP(lpzscs%5BB
z!jY-<xj+dwL<_gdz&06Jmyd#Z(c>IwVCe={2`2rBajJDa-@s}Otj@q<J`Sdrq@~we
zVKipdyd;51JCLdEkZWL7hBy~1Y^avrDvhaaTd%NF5l)r)*iVAxBU>@|h<rTkeiW}U
zRrd@Blkzc~TE1c}oSK*EO1RUtaElFWwSjFmu(-9s@-aO%FNp@0uCOx^Zsfb|mg8a9
z%VaPqdosRL%Ra}zmK#`|fyI6rECbV1<t*O7k~OB5y;xzXh*Q<ORSLTptk-M*aOYf$
z6;=YK#<>zq>ZKe^t(STO>-3p_xC8@BHLwZ;o2#&iT0UzP#=|~p88#YN?B~HYx)R}3
zd5PDUI`$`POl^mJFxw{pn@HaaJ{hbX(xJUXcJDpMZN$Tt&q_B=hyCNee<lf=YhX2C
zVhc0Q-P*p&>9`$doyLy1p!E`AvFqec5+}Xn^ImvgST308YsRVSkV*ra4<>ox0Db+^
zrJQ2ed0C~g4hxgN6t-E3b0)r2ZIn)51m)~bFtu$Hz$Bk!s$8ciY!=v?o8B9bhn<%)
zB~CIm&Y23EtFdJUwhm0j{znl`9s6Uy4CZqYn3~T%VAB6;wDgh{_Oiyxl{m@NIA<zs
zxyGs$_6nF<FKaZW+Gm@<B%dp^yma|0SUxf}F9`~J6-@0%BfuoikF_|<750h3cEs=U
zlW4`)$nSg#i^1<?^kK#R`>xf(_<idDqd)7bxMx2T#(pV`e<$a;7$^I)uzfTZhtK@M
zIn$aR&ad`=87>b0=HnmcsWk`SnUb>006gq`*5YZ$85>{2x#9VDjJ!$MN`>{u?`mFF
z@sIGs^p0|Vwg1cX$RwXkNG%^LLDHk0tj0-0)Q_#zm>TCgF#a$v$2z~-|7Bj*;UDV}
zx~_({@IiHNcg4dldp&=_55w_{i~KMgndD^%epl1mjL*zF>oW<@Nqd}MjfWj)JkG<!
z?cgxlZja<I=`1W65w`+oII=S<SCk1$VPXoq_p&TkCQ^0^=7r$~{r9GKBwRWe^D1#3
zylDM1!jd6e%oy2ec+S78A60^#Prg}E>V-^xSoT;jDLdJFzub2nIaw!-sqNQAVQ1iP
zt6%tFn1t)5u^)ObeMMND!p^~$YF)>J@rP|R!ui$yFY}_ZOAIW{gGu?a!HypN5^CNl
zUw<VpWY^d3@`$hmuw;B-eU8KP{K?jTg;gry$mECloDK$&K)852T%TRqv?V92(!%Yw
z=DS2;GZe-_W9lhwa)ixPnB6!8_+gxL!1%*Do9_H-|5s->crd$OptEiS`}*lGI84}a
zE=HWO_?>Z5LEL=rH2#UrYLxV5@XNpt(<76*z8#;{wp|WJeaCtsJF?9l8}P8>T&1yp
z95cK|*g7!&FfVsFzuNz0dMdliz-AlR90R-0!0tD&g&s`mg_W%Kqk5%$i?whnvpaf#
zv+Ont=#W?OdCwzny_wi%?Ckhqol)n@kIr5bfTzyhG_Vgmn3Rv>rYgJkAw_)0ynL#K
zQ<<#*1DttL*_VcJUmMs41N+9nzV%>^%@<!oL-*@Tx(?!>FrVFaamHNAHSN}UmFadd
z$p(T+II^G4U1qB_vJ|i`crx74c=mtjL%Yh!iWSCjY}BH|#^7P6R|!VP9>bBfAN!w5
zVRN)_aTVuYEUX%AZzbFXyB_|3!d8QISJ;eC_MIzila}6|7xvsNEOu9CT&b`UYxte~
zunb+my5ScxewH8p-hVgTJB?=rbPt9t_lGP6jN;31TvwGJvUFk4$$JRElPuT3iosgr
zZxW%Rw%{p03|D4g<pwr6z*q*hhx{<k3Snp?+W-kbvMFFr`QmH#kwAEoO*f=hC2=A>
z%Aou(+zdmwnM!&GNFY2JZjQu>eClkj!q`^w!*KHrY=MC-Hn61zR&8L*46H_B2TB3(
zWEqwVLw)wrSgpc(Yiy-3)S1p!fzi0Ah>Z<ntCesEYjLgt+X(?HAlHXzY#lnmt~+?M
zjTodkrdA*?eY9|!4Xky?pbQ?Sg=+`KzQQ<l7HeRg6c(?=*#)dOIy%dzvqW?rJ3X|+
zky^MUFxD~q*Z_^?OE}~+L1V=RR%T%31~%EiDhzCjfmIsVbTE-6y?ng2dSIYlI0ncM
z<$4uZGM=n!oyB3m;dsRQWO(^uIBxt{gD3TFq5wR}x?te2+X!{7vpBF3lwE{7K?_#~
z<tO1z)L1zcV?eHxbcReyIGs%fgJ@eU!%14W>0nZ4I;)a65$+T%+zf>c)!0lWy;C(d
zUrA4A3zRtZIoD!gsL$bAoJ$R?8Y~8X&%Swq7OqAKcag@HD=b}OwFb7*z*d1tUF&n8
z)nI5^JD)mRqr`cImY21{&_-8jY#mq};{=<cF$)8ttp~w4w~!yoZaXlkv$+EBB<o~g
z-3+WJSZjo5UaGY?dn@5qX)Io0A8RZj5ND!?jWSS4?{h6&q9I(8lHONZxZx5fWT{SJ
zEEj+HgpHY~+AsW0{^@Kd2Eq?z!rDF7z8`gN_1cO2NXGAl9faRiMp^M=Y$rd)y!bIm
zlX=n8qs{3Tj<Ujdt=;47aC;mvZvsCuKFXNNhL6r!FN``#Woo!i8dJkT?fT}0b+5*G
z!zHiJ!dG@)Xs`Q~Ar4FpH+A%--{31dTu(gx!X0Q}w2{;}-}&M`SS?PRv|0S(q+Ozh
zQ}YsU2uE8$4X2i!wt!!H30gQcy@7^sgSBvK`A#&1OVYxr=?yi68>WR*%Xfw$T(TBU
zO^=gHzj`@O3#XRvLPNMzEu5NOx*=SKfsNGSRLh=Y2sg^Wa<w?s^5q-C6>8zse#>=B
zRR-05J6>aI873Lho2-RX^I2gC$MI0ji<;h4L%2#UoSNQrL%16h)*HX8`uau#qrXsO
zP!CrHMqN*x%sJ34?;mQL{M4<t;GdL_?0{EZVAI$-i(|UVF8y#xxiBh3mEHKnCARs)
zIPbwf$qVCD%W$uO%`ve14D5abn+vAq^X|@FsT%F_%~!%vm#X=E*uWl97$Z}|J*u&@
zo?N{NU)kv`(3l!-p~5)-Q`ut%M!%-iwH|J<fjtf;^}_MslcU>pz{AexQ+SHJP_GZ)
zHOVbQwZ`g)jC~1T+2NkSQ}V)aY8jq2uw`J97lxbj=^BcW9cK-mesR7CCizUn?{i-6
zaXB7#xR>#iaEbU`&C7Cy4bj*u2DZY$UNx{<1AEQDUI&wUISId?oBhlZJnZtlg{PE{
zOfBEr2DS=JjkE8t^Nz(=cATpfb_#wUe#|U(Wt*+RQ_?#XzpLqeq_ER9_OXGj1(Uom
z+=jy*;4oyTw+>I0_3nGz7sA%#7s-pB-aicNYlS7_ceM-~46M$;zA><G!K4fv&l8SX
zbTS@x`My_J27bTu==O<t*z6}fB^)c{(u00}QrN#0R*K&bJm8jf!hX}(#Z~9o)772u
z{eSUK`U=CXIPVA!iFSIdOqHFm^k#UD9JT|P<fRPX<uAR{_K7pjoi*0xr+?VfB(hyK
z*5S~a0(@<!*Ir|J@n^9c*lc$&{NEm{%JER!Xb%JHq{PW^pC9wiF^q<J>0$`iRSWl6
z$BtA-cDU|fQZJ0NOZz<!6c%TQbAK()-cOxIQLy9eWr(x4!Z?8&_}^LVYIe9ol=R5d
zdO1{KRDde$V_=7aN!xO)f2bg#2oF2GBQ@6V{(of)8=%B_C%#nEOHjhi0-Mrx1+#0%
zIZ$JJeEH51!V<xxt{G0P>l3wbHE~&PxRW)OeopLX66Y|D&0So{X0-EihQ|6_+ACMs
z*<fm3R@DA?urT`Egx!NLZ#?Msn}nUGv8uO*xb>N$q{nbiA2m5e!li2Aww(9lVZtua
z!X<q&><M8bH8$k)ONR@~(b)P2f1?>;mwmLxE`IcZ6~YR^@PE7i&Ba4)+ad!iR^ogR
z;fDNQ$-|6>{jW@6w2%I?Am?de<w~4ns=YK3OzL_m*r@|&oFU;ZRl?QaOEsU9mGoW&
zd->y)hf25#B^+%8HQbd7V}+>fDlo|l$KJAzKW&ycr)cc8f+16dP1RWYx++$QT`!ej
z(*HOvcUpHKhfAAHSJ?abZdyirs&|`JDRHjBcX!^A<I2)4N;pQgY{^nL-0ey@vMGlg
z@-`lJoHMm>=gr-4h_KljoA72X%_ckC94*c}ew%!*u=~OAe_NJ5!9%Uj2b6H%fh~My
z|C9NrtekloEB$@;OTy-ZNuAZ>%LN-3&LZ2H|KSgKqGg@9#s1*@$7c9`Ha>bWmXDp^
zi?!YX`SxM+!8nL|h3mN^-t*<dHiA|8u*oRg6d%UQ8R5f5fK~Xg)nFXE6Fur>C@RM<
zFKfX3>Lsxa?(X%8a}5{;(ks3A7`$)BhgF05wb6)O{Nr2zmhTfM*TenFHy_NeKDU6)
z_la|ETW77ut9+Zl{K`<(4tK5l#JLG9*N3I<<{#%~Fuyoc+hc9pC(b%Bzd9Sy!3w;~
zC%hlc2J>sbp0QXH_erlB%ulWd!rJu9XDygtoT<C}vwE-!pS%?B;UBJbC;xgW2J@38
zt26eG_@xKtSH3M^e(jLEr+>d)3pT<hy?CreCiyU~!zTE!1z@Q@ET)TpoWsHV@-hdk
z%qPxHd;7~-Dwv<VtOG0ei8H0Ee>>EI`Q>HcK9=(iUk@Fb50>SV-YPJ^F<^K%?3MEg
z*9YrB8+}-p?*4sj4jA{pCVJ#^)qehUHX_bh)AtHD8ElQ^9p{K1*f->pUgiFnqxi7p
z2l%(qz@E-NB(J=rgU$5G%VsdnFTBFV_X_O8^{AIRFh9GX?jWo$`NX-Yw|{+>AMDSz
zfDQGDGYOWcU-{O8`N{Q&K9-g4Q!h)wR{F3C%q0Bc+zjS7R?RrvU*<Q1rTC<me1yNA
zm|<XR!18_KOp5pKx7A?DKH*~e+Opy)FGIoR`h?pE=BLY3kMyq>Zlv+cOKd-XU6%qj
z+$S${!65dYWvB&%h<dVmFu!)s?eAaqc1K~4mQS3kz!H2|%mC;KA2txoFI*W|tzWpK
zVe9+!qeMiwz$e^BFh4z?evCg`4F;9%U7uinb=~Dyf7`7B%&%USg01sOZ^m)B1IC99
z9q4a|tO1+i6E1a-e;=y_^9wh8uw`xbi8JYVe>-bA7`mrteQpBttLxZA|Nd72HpeH<
zxDzaEu@74XmgK`aooMILGoK^C{QC4<F#7BgJ;t1sL;U-DCuGF0UXsAN_~bJctj>oe
zo#Zdq)nI;otm0&Uxt<SJ?UP>mDX<xQ%ARm4_QUzGnA70r@QJe<m|wrG0xS0k7X#%v
z--j&*OY~v&U|BwF#Ocny6NC-%CA6{HSi7NYG${VS4}bgPf*5NT`@0?7?`GpnTU-0P
z9o_GeVe>hE*V_Fq2H|7uzuU?EZUH_!f48&yT{`j;vjbCW<9^5V|6^s~+g8>N*jd#Y
z4uYM*ksI8b)fW3^cEcT69k6e&qqV!W2kN~u?zh?t^0hba2HOYyZ(r;`-_MG(dSKts
z0T^cv#JfWef}T4V?_)m{XB-d1yJwGptoF5zwE97h9c2x$j)pEj2JiJe4tpU7;k`x2
zqkd1YPPB%gf1PBVY@LF+<EeNr`)L@{PPfjm&P4w?%R1XS2XlmTt@Et&VLM!a_cdOG
zxyHqK&u$v*nhd-HHWO`;jrXCB!aO+78f}e%Jy3vmT^C_29*cLcmO?hhS>vq<kb{YM
zPwS<yyDzgYx2~`%tShantgE5FuCb<C*J6Hpoi)w69&@f6tQ)PHFlW0N>)f|u9(kK}
zyLAWbuRE<-)?KiD?#5d6z0fE3S@&BHz#f=qJ!m}yS$f!d#CjCt%R=ihYY}wH66<m6
z3FzY|t*5O2L!Wrsdd7OzT4p_GJ#W2W)mSfDFIg{R+<e7aVZDmJ_L}v&^#*LRH?6m<
zw{ceQ9qV1|J!`e~zV(6iA#ClBtdFfvthLss)@Rn|7z4hrzO=rw)?5FuzP2`?kAGu*
zYyA`RgYT^Gtsijq>__V->tEI;>u2lV)-TY-zgoXpzgt_-=CNq$ShVG?Xxp}sf>!ST
z_QG$S?N43sUrIw4yZv{=-?u^w?}bmX2(b+RTWJ4#4e36Ha!$9)y$~f|h;lw=f7$_m
zy(4O25keds2-y+2Txio}Agn9aRxkYa9O~*ZyM7q=V+gYt&!-Ugb9Q<)c<zY*)!AVf
zj(^n(p`HJ=hurdiB=SF|#N0fFHg&#Rh*bH_zQ|8!I|lwuXS4)+1AU2%bs_S*BmQm)
zzI_hQ6?V#xBW$ky+m6W93n2X4So~XL|JxD&oemyMy)%CAgnv6CU!BoY_QXF*#3EY~
zp0#CSC(vB{Z&##sDN=X>rFF`-5Z~~(g-GiuNas!{?G0!Xe*ZY+Z6SJZ>p*^3Gq2b^
z_<Fks?}pz;2jYdh!2Y=ngXfj__dUku&aj~tz+PyTjek&}kB!ARe>Qxgh433^VywZu
zcSW3K^@ELFhVNdu67Pe)4F8}xUN|WDWO#;U91P1i7>;rC?;DfOej~!uVLZ$O<6=5Y
zV@gNMdKhEnMQ2#nc-VVal{jfK&k4I*)^`~=&z9)qiTTd&;pB^XW&S@(amvsYf5ZH-
zybI2ayi8Iy$<G&+;dx<wY>TvaLHlhP@8mae0@glImS<6heNVEi50NIz!n$JG&z$Ad
z9rMdJVV>AN(q^nn)&c8~b;NpP9jbLS9&vOHwBs9Bh1Xlp>zuN){`7iL+s0HMt9G=k
zU-xpttL>+@`H>ZWzK)loydu9+2Yzxp7IGBn-@XIeMathAHoq>f_nz<Mopl>&ov@GT
z@~O7%*DwZ|&Yx*p>6?0fz511@{k-zZxFfAUmg|QL8>cG<qn>r0^eAjksUym*DofHX
z%h6{Tj_vg#3^}#_9`B3udz~!nQz*=oslmQ-+?b&5k^aK+vA=xO&a%d0UUEC+w_?20
zf8H49^e43+u@4=IKG>~SFptbf$NeL3N2b|OKb7(`?%uFfBb5<T+^i$^7s`NXoM0R)
z&`<StIb<m2W`|=fw%D=?;bWK{i+_;sfvLDpv=!#8u+xXP#eDcY+)Hx_&e5aohM{fF
z+XMT1EXz6#{!9KGR*JK<{Vl5$<$AFX=5&*Bj{kDRfp-6O3iiC9A7-3rSx+7do!Fb_
zY+;Wl!(W9ouZ7?0;!&3M7JmN(-;LZCHaPUbQ$?0_IQ~7HYgxY_&VFMp>oe%sXEIP;
z^xMve`&&Hw<L{@S?S9w|dljMYuRwlZM*ff38EK~B94+#=6sw=dBhHL?%ZlrO@JCzL
zkC3THd*B@CFq}(A_#TjrlTe@6ooQL`?1}gx_h+KszC#{vfh^P=f%^(kmI-+74ZV2p
z8F&XN%5&HbDC;$r^<^H?IS1)=!G0N(ecq*(bvMd23w1XX={<^kO}zs79D==H=vVm%
zBOcUuYqUY~)u>n0$*6MNFNShliM)N<)v|s+z_P|nv#huG!dw_}e3XRsVWgLUHk(#~
zc0is7Al)S+vF3_)7#(L>iI9hpry!q*=i*%~>y16|8Dr3XNHb+L!h?;Ngz}<JC!)TG
zqD}{)j>lewHiT~7G67+b=dV$=<2yn&AP47mKwY=CtPfDG*uj>?gN}XCA7>)HuIOvW
z?~49%7W&b}Xd~3=en|6yo|bhv>hlWJSvkVJkMbUJ6w)k)ulx{{ZEx&R!FSV6x2)e#
z_LA!?Yc<+(r~QzpD^c$#@1ZBcUO@d+qfTSM4n4uL_D8s1k<K8LcNpTHdn(=^pMX6I
z`It?O$NPC>(C5+av+%hu@~{bEZ$KOFiM-r<nPt6>dT5NiBbg9+7unWjo-!`-PC2K%
zQ_d;xe}}AZJU1xsk;*#dTa|apHv79S^9{*6<y>T*vQC+gMBXXulzGaz$b3}Z|5|xh
zb-OO(BHxs4%Jtu+zk9X*d-ONuI1-(`HDx!dqZ_tKnyZdpi1AEplBkZ3+9Z+M;LSlt
zPb-M(=$39r(+;4`b~0>i+5@!PXdC_&cEN?12XJmjyHcOuMXF0xTUWPn)%hH4S&sch
znB%JBKka4C+h`|0i8+Zne`}4u<s6Q4LE5yO4~kvDd7*08a*il-InEPhKF4{QKBwcn
z&2L_(+X`)W51-R<{vz|b(u}P$x8odP_ck1b!{>RwVO~gI0Oxz0BdK#f&XYLr6Mw*;
zo&P<BxuiM=OhCH&Ja7``#|_N|Ie+22#m@(F^6{2+$)2I}LO)wMsU3XdJusif+?R7>
z=I@_l9iIbz44kWS&PyKy^QGpOb6(C_&&T|gb5_oSr=y?IPxBt;yc{oNPCV**XHL8T
zbNYATo1ouj()msv>A#WuZ9p4M8Q{!S?<#ft80^P4p?%ng>96@0d@G!n&x>*9%WNb1
zVCb6>|Ip{~uY3!?$wZXzgMrSzx$3L29t>HhPi9G;Wvw6X)M3Zn9A6UUntf)ciH`4q
z{f539@h$y6%(4o4I=-BJE<hb0<oE_Sr>Ad;^M3Xt&imPiIQM7YVV|KLMIXTPh?{;L
z)vv_9MSl|eJN-TMFVR;a{vP_1#CJnIKz{{&2G?de^H}zM`Yi6Lbo?aL>-1~TN3sC<
zqW+=JXcEdl3~fsP&^h?`5bA|}p1PzJd^S7b$$no|j`E-!d$+Qz(@_TM%XiQg^moz6
zH6QXd=xjXOh4+8@yyzpM-Vt9H{W{|BqHl<Lk$xWfyy)+uKD-_BLLXOG$PxWozn~w`
z??b;<0iN0I9sNZg5dB*887(>x@`ZT*5Bcl|nWc~C$I~30COW8fM$k7z-A~`pCy>Ga
zlsNt&`tRr;qTi1GAnH&0oapzWpNqaP`kchy^;lQO*F|5^$*9+96^>4!uaUkk>Jj>o
zsKe+3TnKrlPNAQQJ}LUD=#v`X+3_dQf28`8#5YBM*o%D}-%(@yLDZ?u!T!1l^4FAc
z@Xz`<qjTiH&X374N@SOIP$d3)+H0!((q@yfLHzfBho6UbiI=Z_Xz!>TxAb`g?JchV
z&<^0(`5ML?+CE%spibvlOP$W~ons&MKga3OagIH~^$ywyvKB*Ig=<$FvuS_RR+IG@
zj%&0TxK2X5f$Jo+t7x0hCg8Zw^$4zYaJ=LA&2fg~_DrNlTY}>m$84^x$e2xAjCKHR
zIgU-V^=LQImY|KpF^}Ul$7!ywQPyd@sbe(9IF8XApJ}gfZ01<Z@saCNT%)0lFY>@K
zkK-L}Hm+gOo}|r6TaxQjw1K$Z!L=B!rwl@QXv5J4;uy_wk>fM%0Is!gjOO@H`-tN-
z$9#^Fw2x$+iuMI<56*SCCd4tEHi?YiYtde`cR0>+&8h%xM!SjQILB{}*R+8L;mLJB
z+F-QnXwz}sjy4_F?Py=nhM`?Wy~K4N+MXP@X`71Pi$v$C`fhvBbzXX|7<C;TuUq!I
zqwU{=4BP!5I*;=`nP+nR=A4asi{mfnWHK+}yleydi;U0g?;N+i{4A7juQhb`Wm!Mx
z{7hX#r@rL+IrS9#s>~~7PQm$<DzjC{8|PB1p*LiHL7gJ&=rWg*`IWk!PWw{U)2Xj%
zkLbP^Szn~zh5DN|rRZ;&?@>RAP7-~jubqp(MfJ6apGABuqvJ4kKyT`6=A2W>x;gcb
z?puj;t^Bl@;95E7;hY2ct(SA0leKcwI{C5ZIBV$~Yt*@otdny+d?;kdYptB~A&#Ts
zC!rpFX_8|*()V!r;NY5hQ`XCygRcDsG8fggEnC+%#y*JDm-lzCd#{GRY-w^kW1q<V
z*^%np|E2v&%|YKLm9;#%75}H$2(q`Xsdhqhms!q3xAh)Dt{-tu&2=NL8F9Ucd+T&N
zD3U#c)nkJD25FPh7Ud7^BCc1_pFrD_>oc@H)pZ&A2)O=0zlFM%MB9}1JpBr^=NmHy
z(VmaAFVkk`oM2n8wQ~JY<^Vk~M^NVgjor7x`GVN}y1nnU*19$A`$+c0M%r&1)21<4
zgNU?E*`8kWIj_0g*4_`j59T^8&8~>*=TP0$7`bf@GW!MQz)_iv&f&yI#(6|@klXI?
z%SYw5Wy|fSIe4dBJFHW{7UWq;p1W$l*VZ}nbyqz0Hk^g^FvQy!oqqDUq5Xrl$+lh#
zp?%D?A=<?BInyR?>{+eB*v}K~FD<*jsB@^s$n^H8@2@<-SqJ92u4#_MIj7h92<M^w
zE($$|b><-dHIk*UgG^@*qx*5T?S7mj=s4<nxpUwn{N6RuIeW}A<?8uex&MIY&HoSU
z?CLpWo=yG&`{#Hrn7aKntlg_;o;jAhgf;MDtlw}<;Th`mOM+*YImXDDX`ZF#IclB@
zF2z&s7Es5d_plFQYn(x5`64}s+`hXr7Bc^G2EAycWgUEd<Z&>)2T=!)V;_Qko|*ds
zxZjq09_T0HzFXP1%Kf*pca?iH)IGQyo9LV1-U;qI;TkOW+;Xq2x<8eBZn;h>dr`UP
zmirdC=a%~xxbIf>q3U~3xu1hR5U!JQe+BoNa38Md0ItW%eq8Rwm3~cM3HRgD=fwTE
zvKO6uTVxL|*KF;*A(TU`=W%}swo_TMAD8=7Wj`+WsBk~7*Ir!Nf6Mh+eg7?eVBDKS
zznAQ3{pL_-FAdjM>GR^=Tlz4##wz<_M#qJoN#^<{Z36DC<$A5GHLH7AxehA(Sh>Ge
z-^(g{WMu!U?7Nk{tFrf2_T1|GZMoN0`~&J<Tk&72`&efp|9*Q|x%Y)@&$54&dscbQ
zS>2;5dsDgpmOj$1XdmvqrSDSRciYf@Thl&P?!i5}+}U%>wO?5m=eYyfPfNe1?5CBz
zw6gbH_R;G5&$;)CYrx!l#c`SI%iLGXJvZv!^Ffd`?p@$`tnW4F{vp}VKpz+PE;RQs
zo_$Ci-#>*Oj@qa#+eU3^GJ7m^a8zcaGAsTwo(0<;=To|_eGz`XsNA+}xozrNGS4A$
ze;v;fsC(&5_s(q1HRV4>N7s}ax|b=srX1YAFXwO@V_P(r^JfoYF4WxhH1&u+f0cRT
z-?{IH=bRh5Pb&fQZ2CZW-kEdFrtFc~miKBk2V3LkG0k6ww@3MHNOmc=+oQ}j7aO?>
z4w>ezd!uq2zUQ#1>txMkAKINMQMr|~onjj{buQEr?%r%J=Q834wmi9wp34ZoH&)h9
z8@j*xgX5j`%oSKW;u@^Fjw@@ivR>RZ(Ybq^>zaP|R^Krdb4IMG@s4SA&G<;f->p~6
zTTj^!Ym8C*rDgm08sqc8@?wZ@n)7m=(a`s=ZEtrl{~LQ0OnZQ2?O#71t)7+Oeju+q
zm^l}bbJDU`fag`zbJE;@7rlph`?+_#CEeG<{iHk(L_0xWquKGysQzy0c06@UV{~|P
z@tv%08<pLbF1wA9+vaL}T!Xd9ZDo5z?T+aCPPR8&dklOq+e+S}wzmJBMJ>V4*j#md
z+w^TG^HCk&a&>%jSbN_YcTYrpfKeZy>`&$WBh5i>$6pzh+m=3me4)JY@6Eh$uTc5z
z2>*%hzup%2ZnNL;d|PABT`$=$D#tBdjvM0#X%4#g(F>z88<pAMy~&OBIrF_fTk{Ss
zz88yoSQ_(g;zd}`Z)tWf_pCQ{-!#WB*$c%r2kwXBIvVd1k@LDO^_|4r=gl+eJdduw
zhnxGmRh`Uz-hYKX(G*)^2+kpU$u#A{YYkjo|Bk+o#<?qicNWOIi@5*c&-mS_7q{j6
zwf*kCG|4mNSC!}OO_qO#KSK2{Q+6YHe>~+^m1pkfVBgj6z`Xm~;C_yoy9Dol(D!u6
zeh$BTT?Rl-ntBhudQT?rRplM4P1W1f+4g=1=&#1^VWoVFtT#o@uN&r^ccGlC_v1%$
zFRa&@my@mv-;2%nPd0Twc60SNuk9Jy2bwDXUi+D%{^pkJZ*H#gKIWXLyvx1jJhw|*
zJkooT8>{pGjK1IA&Nenzd2f}w?c|*{kLY;XdP~u_yzZ@w?pekCVz68Osxy+b$$8g3
z?}F0rxc^_XZ>n&{LbdU?rhUUU75R_KzVm*>?Oo^ZgFaD=J^Z_$ihCT<PvrN%^PS$D
zBkOmpZSD7Y&ublee;|E6a(^KGQM^BpJ}Iv|1l9Wz<vv0BKlS?r<qk!jSBSpP+qp;3
z>n=pO2T{KRG5S7l=bfdZLt6U#yx+zdKrbI^)PL%{tGA`D0r>g<o69{wC*t1GsN6>P
zamhZe<|4OKCq(5ox|blhm!P@GZG8Wz+(zX#D7V}5nyUC(t~w?vvr(B1%4~DdwYyvy
zmD`psx9`9|)l@(D_NaT0=m+1O_WlB|`C0V+M2+9KBEG1m>{;2~)-bn6*?sctsO(19
z--GXQ^7D;tkFxvz1yR|J%5L+N-F~ovqBaBel6JE!zH^N4TI0LM_};IUX#c*5eO{e$
zmWuDh<NNUL#e3~0z-FXP$o<Rb<BW>FFPZOu^9uJI_Tn}r+`TzX3wHz7#~VtoG3VZz
z%UtxAi=uPUme?1YI`?cYa+}%$-V-u9F7zFjf9A}@sn}ohzr1(0xybF{!=m~&s&AX0
z&wBL5QMrxEZS#}c)|g*-`KhD(-=h29_&)3H?Yyw8ZGVe*Sw-bGy8lh~zip4cY2CNC
z3GaH3%4}3-o0H6T!2JnPnQhrJ+mha&!8<Pa{tR9BJ`=nB$nm))cy|@<I*jB#k;^9H
z{uZ2{9FS*OwYa~8XTuiaAata@v40-8{hckp=yc24aJBO;(sOqFYu=&D^UsZ0pV*%5
ziS(Ve&UxC8lEUxHY3M9%L-*uFBGV$zjg{s9)phPd>@AyqkYx=_b@t40e+KU@<5^MO
zZJKdn(C_eUZ}ctb2cAFYSx~MW{)+WQ-VNY&2OsBmBe53wM<K!#S=QnB_b}FC`;Em}
zVyw$Pli}QR+Uk6)T_UY-@%#mG^6V+kq~24BJRmPGBX39SjJ)7%FVA<YI=B_yX~esl
zRwLdx+%rdeVlS*;a=o($blcK%oI4A=d=6Z5<a%k{5zZQ^*BwtHvy@G)pYjeT^?hAj
zL){ztzx7bdN`~GUhWnQy)xTb{dKuPmN1lSdgF28k3Et-+?=I(=(x%GlX)%`7x07Yf
z#M%eXBXiH&@w<B8VRHrQrX1zvody#zx7c`yWpVubeQ(Qp2;WVE4E%<&^1aW;qK*&2
znvlL9t{QhKaxI$oGYv)i?vJp)!k5YQf<cfYo*|xls%7zxry=>4)duIzc&`C<=}Wk~
zWIF1V_ZwV3*s?Yut{c$K_g-dMuV-4;Taa7Yx@%FM0{qS1(DlV#o%DFFkmY0<x?((J
z+|(T`2k-D2jq<bYS<g(5>*H)^${yvOWo29QzF%o;*8eQj8SmR-o3njbKI)kxQ6}b%
z_eQc#K493hEbHyP9J#&|@w3j^-mGu-l{fZq`UCp``yg!!)*tWS`V2D8dS(5yA8-!?
z`vLm^`zhuB&=c^t=vN~1^rukX&m7?NHOllU$2$8Rt~=A&|3JABKdP)*vH!BKaPI*7
zKKldr4qSVfQ_m0dbncxSgz~U2vu}NZcz8z_`!e@d9D1VDm$|=!eVzS*eVqD%eOvkl
z&qYiB;60F6_I3LFr)am|53sB+^PD@x7Nf7R?@z06Y?FnM70L!>=HgM#{ezSv$`5q|
zWr(^#-hawI!uRu0M^Wae-+0!TGTWGOy1A@tJ&U%F&ZAoPJW3y@X>+o_a(*S_HScir
z8?)8%ddxKM@tQW<UomE@<Mn*#)5eV1GG0@E>-RB=9;Y6Oj@MgftftQWGvjnimD`sw
z4n^e_<0*AehtPYS|E!(4HEhg3E4PiY6Sn91ysT-x0UJ1KBeZNAp(XiR)j7V%@Hotm
zqB7jFWteuYKAzNIZYX{W&gcDn7L7T>$9G|Jj{PL&$h<Rq^}d$H`?GZ)MkM!7FB$Ck
zIOu1Pee5us>^bWrmpeWN`V)9xBmD{bosD<HmSDNneZ%xMus_q+;CDAW?SHTL4A72`
zbWGx0fPOvtKfHW+Uj94!N%~=aFFrigf9LnE0p3L`KD-_X@72GX(zo?F0BwKq`Ed^5
zcjx-{;7e|djX^nzv`yKb+p;aC9lhFccNktxX~%}<bJC{lN8*!XABnCR1pTnoVNKCr
zUiatgI!e_|@$lDu0evwZ{p-j$=%*g=9}cjr1@I?7e~e{ygFi9tGRs;%0pFc#Syw@4
zufX562I~jEWLL0OW$?#AzvZ8ezlDFa75o4nrC8Pr@YOvA-O@GDvUY|q@r5hlvxHxh
zf6F-exgC6ijECtlUdF|E7ze{L9K$nz%op>=JTTu(OVUx}d<}ljNaOU2k7+fgPdA7D
zJZVg{Ka0;?-f8q#*eA42{;K}m7@3Xf+&spiH`_$zHY&Hlwd>}fYuAsA%4}3-o0rV)
z8y}U~mM*iZog4?>LZo)G$@XrH&GFk=p*9EiS?Fg+xHn~6yo=e-pW!tJzWm6ovv+QH
z*e+i0+p_Q@`;qwGQ~Ctdc`<!joEy`pMV}J=TAU-(uk}~Vlj+xyJxj7*$@b@A?k4Xf
zqA!c@SZ!zz6a7;3WBrvjH+@uMcXRKDX)euogK!Uy>}eW=wvlzx#?GhPWLZ}Gc9wMk
z=B)C*iawZMAB46`hAbR>J@#B-KG2vx(;V!bx6x;#zM_`x&u@&(HkbWYCu0v>RBoek
z+nml?T|6Qxv;Ql0`gqvO39w(jgN^bPYzpza(;rX&Ieqe3*h{SX&mZrLee2jW{VDu=
zDN}>~^yA?F_429HpZ*bSma(uyZ{N$ZD#knhb^7Y*A6NbC^!Ia}fa?OCG3L|8p-uBw
z_))j!I&TK-QL*i!>%7k1be`2v&uK*0d4qfGW$w}#8|Y;8P1Sbi{7Ikda$kVVbvd8n
z8J)j#&9{9)bZlwqW6PJ2G3xEc$TFtHA+k&#4Sg26JX1%DJkxhUd8Y4zGELvbU%i(h
zWuL9%$MN#vMBgd8b@p$GpT^{)*;@XY=4Pk7JUVKp$azvf|83Mx3Aa<4D(5^m%e|L8
z2h1~<a&DAoLgnnJzNg>ME^o;1>er_SW1RRqZ1cOXMVVXSeCICFy_ikii%Gjc-H*vJ
zlIKBrewJrJd485>N2gW5p1}N)_f^RG{sEY4j>g=Q=W_LP)3OF}(p8pqA<luy8pL(*
z-^uy|&$2gkKX}@qIDdS$WB)u3`KBGzd8fwNLR|Au?Ru{@EU|(9ZhQV2*k0SCf0Juo
za#lDJ+0f;}Ykf*&Lgb+#S!k+`Y|P&DZEf4If2sR98)MT`ZdEzfZTY`jh6}K6Cg(*W
zm0|jFcqUcOmhv1a`>U?cWbJk7InJFDf5%?r<}SnR!;ze+kg;6ugy7i;?gKFGOIFvO
z<(>?l8)2RC4h5baVgKg+5b`bv-qXN48|bT{Z0qM4XJTyOd6UmD&d9r>#KyVwBFDa=
z{O}$M%1sUYpuCTQ<rMkg9EI!gyfcC8@!w%g<DCgS+rc{|#HQgIGRw=m9A1ZyM?E_$
zXFX)iK|RmC1JdSw4HqMgw{Vw)dS-)nFZ3Jh+)cuB8pBXl-g!a$SnhqG-1D9expReg
zQShDz_0ANvFYt^7?>OQ84Wf@ZPIG+b*t`(s;CRk4o8vUcX5N?a8*C(5-?pv_{(f^=
z@OLj=#4%dR&$I5lyF}`NHs|)Nk5<AyRP_;Mk$2dze&voDwVpd)=-lDqrITo9tL?!1
zJ+=p(r1m@Bv$3tmRN9Nu7n?e+atvgDl)l(hon+ES^wavC-D-?X)5hJF<1FoC>I2%y
zyn~5zX8PTz59o)}ef(Z~pDgH4RnE_ZGSlUpbGvOR>$L0tihWMaN!~d><=j-x5^O8E
z=Q>4GZAuImAv(Od_=)$K8Y=U;yhkeQQ9rR`lWmK0zT0{()l`|^o^2M<<M$+PpMC(b
zIh*1G_^WmIpS4rAwT<FsZ~NKW9MhYF+<uAqLZowlb>2^#Teq*(JEi{4d4E)HL+uOh
zUE+CPp8e(iB%c4}xnG`D;5pwFan3mfo<Z0F^I7hD;`w3jOX3;h#>jnh*_XOUN>uJ!
z`aX=t$gQrgDaYG#9@)^EtJl0yY>m-FqOu#6-JoCZ9{41hgROCU`>5Qubh&LwbG)D6
zr=fqJcSnov^|F;|3w!x5Xb<<px`%2vbDYub=Kn>%^!7N{tA$_orF7?fp}L+#ndUrC
z?hfX<t=C=uvd%<*HSY@N8idz=Os>Pwwouoew#9w_>fOQfa0d`&S6xeyIhvR3%KC0Y
z^E~>Hxpw!zeAhqsYtaw;XYcxlYOv46()Rqbcm4B@|52^~-aG!e&dc>;uJK0i`FGZq
zU&NZ`UwO|zeIceh{<~m)&voYOJG9Js{&(0H?=@z7={$9uZb<Km?v#BC+_Mn9V-G$h
zjD76$+v{3FbMa4Ia&1&@Tl!q7G5)FTd46BAt9gFprE95QRej6367MjH&W-;3ex2=U
z9c+7++rei><#sH5hqAvjs&9in)$Lhs#TWH%)Sv3UqfO3_w}dkXst=WGw_J;rdnHDl
z;M~=G(HYJ?&0Moxf%RM7Q=#7N9CD{bqO;b^bzR;!(HOg<x!hqJdv(-aZt414y<73G
zzE`oi%o_)s7VQTuy&pW<KX?X&{zRUGkaH<~AL*%B!{Gdib1I&j(0x=qOCx=W{fOhj
zpuwSc9GTt`Anymz?=F%!_4||<zr5dIJmgdFyIyxG$#~ZlW0(GJ0`)E>?qA}4O1w)+
z9rNT4CH4IURr@+)DeqX4a;x_`HKxpdWmWHungjp$)-0=fZ<JSAy~g#%oSoR-_Pabh
zEp&eNcbt=mo{{kO>29mD5vuLm(&YJwkx_Z(+0w0jZhU(_<Hj?Ls!XfDd&#%oe)8?n
zAMt&w=>C}hrMnQC>RaJh(U`NRe)rup<^HN;ah_bx$BRvD;fH6(AHlvAp6{l89DUy)
z#-=pq{J+<`>YB2KuCL{^)b|Zio>cwZT+U=>=7icKTk}k2Lwg!|23Blqp8e+jF`ob4
zI~I5F;vR-%`16Kg9|7-9Q13h9yAF8Y5!VX0=9xC$amKOwe@UOKwn%f-?boJ9b$dhS
zNTPT5h2Pyref>Ukje6f6Z2@)vrf!2Ai+hZC&jau2)9n!6OT#;1XlD$?-e7sp3Gav)
zgtYjs6Y936?&(zbBKJZXa({q*w=ryR+BLE_nLa=6Pi_q#p}I$zHV*HI-GKb?y*ISU
zWWO@^u5rII_pi}6NF7W4O&#mCfBCQ8yWEt0%U-qz$D6JFj^oSVd)4pK<DD*YpC0#K
z{@JnRG}x%}PH*1lLtEPKz20))Qd9N$-({y?dTdmeM|FAQ??d_wedFByoiiK53h-Vi
z?8Be7XW$)C_+32<{#V>{_RK}md(Py}iAe4_`>WfhJ>-SsKF7@HJ#^?R73O>BhG9-5
zeiQYcKH2Y1dx3WW?g-n0=LppH<e8?=;O}j0zq<l)zMLAoXHd>U^S(j)COEe7OkNzG
z-?nznme5A%fi=K02jC8;ILoTTx+cd+-uw1hkKmq486W5D+&txg`|Ihm;{JM$7p8j&
zJ7SKl-%U6qKXi|6r1ulvfVR}{DD?7Qo7Nk79!~X>$T_%r*s5ZS{@r(?%HFyk;5TfF
z&x?IUw>@c-H{=fyU&z+BPfd3{Z|l1U<%}o&VU4jX^|K?Kt8B}=2OBHL+xtD5UG@p}
z>(Q^(RNr3o9!+Qb*q+xIRX?7WEc>k~!W9srkDH6%x>ru9d^c6Lz3vihNKZ%o){gJY
z^u7vRfB)6G+fUw`%O1`Zn8!wKkLWv7<=$@9X5QZR=!w0YpBI(cmcH+}F}6i>(Y5=*
zcM;XKQC-`dbnOL|QJHP&y7n^oKj}|xi8}Y6Sig+w+^EiNPCEBp?2U}dY*c2Olgzfm
z+E-L&Tei&pFTFP@6?bNezkzc7cbo@|zBeg!pCo;~f7g4H^gV7(*(ay(1KrwtKxO|Y
z_kI>0=)BL7Yw)tCf@?7PSrpp*FHLgxX->y}c)mC7^1*noF7}yn9iDqH?!_7A*RgM2
z_H3$qMD_il+<PkfLmRrgmis`r_x+#TPq`HPai^j_yzUm`dZ*l9tFOg#zr)|P4>Z!V
z1$-|h?F`=G`om6t?;WnZ%Q1R)>-Kqf>!Xm3m$1jFeLL(i5A1zhex~zYQ<0x~_z}1_
zo$qnw9%Al);=5g`gLtlnd*RqeM#niiiF=v3zex71{DQu;^fb%bc!+aOj=F{W$7y#^
z4^g*puQT-!_nL4&7~fyYJ@I^>>5&&ZI%|87qa!<8)>F`*+#AMyVOu6x)^(^a-hsxx
zDLy56uPt?<?62aQB6SMy*WmkOse2#j>Fi4xbe40MH}_h7f_QlU-ov@hIcL7R_8IJ7
z;T>y#V9y%QH}xB9Sudhqx2Jo6UxZAkdm?#fGt0od^XvfIT;2267{63=SigGk(CA!A
z<iDlfrFJLARO(7E*){E3+}`(l{quy-c~MjM!$kLbHLty1s?E<mU>u_wW9M%VXS;e~
z9?!Xa^t}|$zINHqPJ3-@&u2MT=Q+m4oMBYwuYB(}?MBX5X(P%!)oYF_^HVQf>$g9v
zIoJt{Mnvs|mTo8PyGw9Rbpq_)$1&%TITk;sToCl%96Bw?D&UupzZ(iWUwk}o!B-={
zd-VsNL!!Oy*DrQ&6S`0LH_SKmePBF;BWEYLkC$hEdEVDc$9uhZi1R$oOL$&~Hb3Vk
z4V_1nb2(o3h0H`9QLjg0i>UX&vz~OH4d<fVt1EkR=`$1m59cO4m&EhioTKpEHs>i%
zVt&Ut>7MXk$k_^>-`<wzE9iGp&p+*lIU?uFa?V10^_**-jQO$YE-d=sXovF*w#-M>
zv0+=i|C_$G)$kYWw4Y^h50~Fv@;sAq=n28I?&>%p_wC3y!Mk<n!|aRsviLC7J?n|^
z7fAnLU+|i5vVY8ipP`|@V?W^Esy?(n@KJ0{9|-eESz|hswdUggi26R9b7s7sVfsNh
z6NvuF^K`w2G%Q!*3t^j6#;)t*gyHYhPr|)q_gm;v(eZbqKZ^`M0Dlz2dxfcj&X+jn
zULOo2-+6_R{>Z*4>9G&eSEbGsWSo(;?9;jj&)?DKMgP{tkZbm#4-lC;UT}=y*uXMy
ze9+52rB|r0=$=Z)C%6Op4Da<>3O}OU?L!+<?0(&kPhXol4$yB;e<kk&x)S3G&mzh>
zWBM8Ov&QsA(hsTXV>yQ^dRN|iK;7Ww^Ps<!I-Tc9=`-bdQrhJm&vNF8^l8?he&w7S
z$00di%66r1m3mawq4bM-<w??F-k28eNMu@)N2ba2m`}#7j|t2p^Y>YgV16VoJ=!<V
zv#yknhR(QBepK1fWk%#hWJQ+~%9MVt^{;N9_d7(}r!nml2Vbq|P}7-oxuco)Pj@*m
z{4Qp{`<{8PwcK&7-m}biEets}bx7*a?EL(qA*ls<g=4Zy3bXT5GfT=!Q^(=Isd<H&
zshLG3+4wyzudoa_BR?&_XhL4m;khA!iwd*(cd6Os&L5?gW{t5!Bi0Fdg{ft^CD|ES
z#YIK=8O3>}*=0V#B@H)tVOc=|LZp@Z1PG>=n^BUTWhYshH9jq?ByW6nNojF*W@#fr
zjvAMjm6e_26T%~N+4(uhozLF~^A@O!oV@&O{CQ4E5z15?X{bOABH-9@*(DQ?^a&T1
zyFj?Yvf{$x@JxEOc4<jwDl*1~FD)y{D;&i~W=2_B>EW5h#h&dQmTKv^;^LC*(o(y{
zvW`v7i0_-4Hle6wOzKgorKwEeq=1N=kbG)s>bZq^IeFPxL(U%IG@YHSPYJ{7Gc!Lg
zyRgibJ7l|{C@VW(3)(;_3-U@cA+nj-#btR#g=uIXNUv{M!_p7b@PwiX1Nx(eBM|FA
zh+;@*n)HyuvW(Kw>=M08G?4ZDqRfo^?9>TJ)cMuUwr7Qp&n!c~D`mG%9iLfRmQhkR
zuGnr0$a==Oe027_!tojTd0A=286_D7*{FoH+>FAke2>a#AX^f9M#(62!i=(vu-a@O
zg0hl~!qmKe2?J7diZjbf@(<4pk-G*$yW$9)lU7`mpO=}J?JvAx4VqU_00D}i5=+Jv
zmgN;>+m#sTDt4andr4+)Ng5jTaOln^Wqnk38AN$pem2!bA)4b))M0+nsJ`)Oc?HG!
zhi8-)G$uR2b|}aw%gxCwL^Xzl_tp3mvk3)gDE8&XS7&x^Y7T|4NrID>lU+D|Tv=Xz
zB#j;%F|vvST|abC^Aa}C5fRN^R>UEy5u(G0Y?;X{$jB@yDs8O1*bS6c2pP`Eq1I|R
z>xz2M#W<9T5g7x2X4=RMNUN^ky~?gcV5gpw4ef&p4+|VF8^O9RDbCD-!qxJ7-VhD}
z<1?jWv38)Ci*>CiF}ocd`J{cJY1BdpK%*)oDDHNbX?kx-IGRy~g_nGXshmLm+0V0z
z^NML7M38e<PwB+c)Ut`i&~Kq74Nodq`KY$ijGSzQh(J<Bm$TV(v-69yOB{jC&(F#m
zA9)GUJefs>UO8<*#@se`q%5zbsIUOz{rHTMyo`~sq{76mf%rn&xJgPeFz7-<k7dWn
zDw<H3pFJK{hu(X_+aO>9<`vQ=Eo1(*X7lO+7>`^vs+#Ive>*+{qq!~%4b+HZ|CE#z
z7KN3-D`Ze*1-faN&XRHmn=W)3Fs`7qEUat#1_~JeT16TDytowI$KUc)4WUtaWx3-<
z!obb94bRM?0@yy;<`FI{P#BK=8Kd+D^r|skV{&MUbR0!|)NC-KvT19CD+Z|uKb=yV
zojI-~uWTaqdm}=RD;!feq0k-_LKRCS1<c7t=Ws0QocxSYVPYkD4ik{VvZ9gFc&ey3
zkZ5UHR({^d)Ul;SFrf8b*g)94!o0FPn7xxQQB2L@^Z|2R_p7kjB<o?-O@jy1RL`F3
z8wh{S)(uPvBU8vSI8v%KtFwtlr!tJ&vmj%eg%$k#yh5nJM(UgpEezw-)`bxpmqjB-
z=Vdi=mM7zwJtvuvm!FlHQIZvIAT}T^7{lOEC`&CE30rSMX5``#Xz8E_BtLspM&?8a
zyE9>I<VY-~$u7@ME69L_-AJj|1gCgp$(XRQ+^Z_6`~x#hAM4>H<HSD8_8B#@u+*2(
zV5wOX3)3)g*!>gw(-=#BM&T$_ZtA$gELv6aJUp|!+^pV9gLcw{!op0SVJEB?1ll*R
z$Zb(oe~AKc6<*-aLkw2f#9C@zEuai0fkvE=S!%bRE&`IMUtY7aM~-71X^Hv<gQoK6
z=;41JtU$+;DE>Fk_A-gfgiJ)$c%_KBBf449goyeC1)9nz68*)$EzF*v)mH<Jq-eUl
zkp*e=jB%6-9aN<fUHJ&Qh4Ql+Ijgf1Ov}olt?gHNrdk(I?*!<&Fb{77g$+m~9))?C
z1;r7!Ku&&9hF&KPBo(aJ%<R1Uv|`K&^2QbP57S~&wSK*T^WT7F6|p8(hhVqKFf&SX
z)O+MEFG`fuw?vdynpcqJ*Kn%ws?C#g>1gY(36|F!0oKw;xB??fLIxVD9oJEqm0eg=
zQh-GOPU%Vzm9Bcc+Rn4AIjDO?K@X9az6@(LXXN)VOHIve`-V9Rlon@XHpU2sMlLLk
zSU;lBH0B(iX}Df(s7^flTX?a8+BGYCd|pvzS%VGfHx%X-<~LC3!L%mWGxtEfH>}75
zHeqVtcy|padpy=4N{Ys7E$vk+$`BXq<$2lJ*$GGcOq-<dxTzJE+5UJfF;i^@TF-fe
zFaI=<&k(yXv)_>s^$4Y$=#zOxsX3YXMG<=8*qci8MqwpRD`Nv0b!*B?U3oTasLE0G
z!Kl*IQKjyP7NKJ}P|xsN<rU`8TGH|lA5%UY5tPj2lA=*?0>_;U7kFu0@A8BJ2d4%k
zEAF&BELcFiP!IXzva<2(;qiwb8Q-se!r}4Gs-<0}TI62pkoqUDFkbshuWDqSXWM>~
zNVQddcKAFcTnGaW1t^cw@iYM=Xa;ozg1v*XrnxIvVX`MFx@{k51Ks+BM>ew5RUxpw
zNAN$wpVd(3^h(ye*czt)Im<5enPq!5nbO4qZo3J2S=qEJ%ZduH=#@8eVp+J`TPiFp
z`9KLq+g^$YBqk(zte2-o-ocfib`_)K1tYP%5Xn%hgjFmutRpoxw5T;W#tN`BI<71y
z!H%Lq3Dq5I5K!pUkm1Iwx!A)nNMvH^SgT#%CPA-3F8$>8By~3GF)AT6dUTO)VoPdn
zj|tl2NGvCBl$JZcvWRUrAuA8tCurd|SaYFPo%;!EJo>~#G8rbNsKH|BortWY;1EBi
ztU%oJjmRWLEuerH8guiU$lS<^j0OjJEW3mm@D0^%L3TlA@kH!Sh^TT^)n%`LVY>i)
zm1(6|NYB8ME&PCCokS|yLmDzl3I^ylw^xRh(n_D2fCc%2kzt875IWeOokHvCAS|zl
z4?-TgH0HhfCP9Pp6ci474sUPE@avdv<@h9+Q99Arn_>)Gs80;T^QkQ_z+L3&g=w&A
zZ5xd1?T!dX&<#{^a;Hc3f-bC;;E?RMsl+cwS=psy%8KkgI1m?%8+1ui%{8gHGjehm
zexjzdeCrYN;)q!!T}spR<z*#(ozWs9W$&gF(d@4vQ{MsRSAl^IOw!jf$A_;ANbz0a
zb9H<<8!(cxyV}`n3kaO?VY<vW&Eo8lW!WPeY@lF=R0b|jF%22`wEa~wD*YMF8C(d?
zDJ#l9GOVNxG>r5c+Z&HHH%tZ^wM>*<9zJuB$_?tTfL?$+ax4rF(O@R+?Qig}!kZPL
zmqStX!C@`oXva9$3}mn5X#q+5*fSXVSi%jC@UjL)BixT1{?~z;DG5x#JVhvU;-}6y
z0)vpP=TJM8bnn?;c;9m7<zYKHy{bZ~%0Pll%fqYaTRg<du@7=yRKleet$%sV2Hh^5
z77$S_OamFU+dKybMQLFD6BY9(Di=8~C>o#L*xnVG>f~cnQL$5X;m+`eDlNY>BfqF<
z%(zJQ=ul9@hUv&^Dz_*<E8@<fNQ7O{3<@W6L?exKstKM$j#p;Yt|)>`serYZSBfpn
z+%4KT>5z7@cWtJXWanfSaSNeA^@Zs&WRxY5SrUwdA{fm9;cigU^ugNc86ov2av>#l
zU1~^~oeAC&tXzimB?;!0VFt^|8;J#WCtQQsbUUHFE5lYZ?pOA1lSafqnQ<o2Iip-(
z6)G{L&|b~22%D{lQ`1Uw%0`aMiEIMw=GQKQ`^nuuuL+KC^<jCUG-5GR%*KL|0iB6o
z;PCJ@9K+g+9+vW^c~}DTDXc1{@z=Cm=nvn7UHJ;gmF|p!`avB<(9mK^u)Xw|sNG%j
zoYFTks**D7%!JkKIJUHn?|$;4G=Q>+1e>ml3ZXHw(~8EG6_4W~ipFd(36AXONRDUP
zvn(ey;Ohvu1vJTX20^s?gnmb+=5l*DlF%o4UgcHQqrGUZMI0{D!Ggfl#x^SKq|m~6
zrK9viG3PV5&sLubMHn_Mr?{*LeIugqY8f$KcUDx@sY(Nh2KpfF7UKbmuwICk9+ee|
zy&~Nx&Dpo0)n|Acgie*&O~ZA$SD~DmX!L?`V8o-qbCEToN>>`(QM^vCvBP=_eyE|U
z>Vwb?t8n;+SyEC%Qja_U#qmm4M}=X_@Deht?J_dU^2RsaI&j_6*kBa!RX4WU6y@&-
zt=?B8?{2Bxxo=q+Pg+5YJZm~c#b~oitOujDBNadnGcazE0q1;x+Nr{F=hY?!O<AmP
zT{PTrm&VP0jjdX@##|llw6tFhhe?OCv9c)@jLv{vjty3@qGfsT&2idcAS}tV9nfAC
z9hS*Jg`>x&WwMqc84uWPmGKX{8h$H`cG$%eR>{)BVF}|1)Od_j`YN&fy<7WU5&=;v
z%P+<`6`v|{0|$lOb|XZ#RoFG*Y=aJ47E0}dNj@FLUnSYLsBO|_7LQBI$}5dz0;8zJ
zfJP1WYtN4ApFT_^C-uPDuKsC-MKS@4(8>uo*KBhy(CZ@>fA)KyZjUw%J9-*Ya4w+n
z0BM*wd4*Jm?yzl4=9z!vms)%zE=;@wVjD0A!$)3`^RR&9O7gJ)7m?OD-`S?8?!BP*
ztE`lpiqzikRcj&jZJ#Z~PHsns(E15?BQy|+E$xAQ3c8Fm5Y!p_b8_;>mHI0Xk3K!7
zDULqpG-P&pUbvsQfo$66pi|4rd0a2D(IiAN<v6vyO`j*M8`nsVHqp;*M$|!+rna3a
zX>?kJh4ht37)iFvCj#}Ox(=a!#^JackH2JxcjWNYf}<JSnqF&25j9UyDONy&3zNxz
zYGa9bl57F>cF%fcip|c0iGH0}RoR-KCO@wL6VZ^)D>dcO0mfk%j3klZh(=M6alswg
z*j+sv_oN2qnUIWe7{?>ag1@z1nj3Ddd)2EV$APgCD$DuJ-eF{mbi)PFtl0<}Ijjkg
zyMS*_IoR#&6*;mgwSm)_A*<72owI@Ja5O0L1SfKYx=E=_nQUkF9l*^p;Vacr{;<Ic
z+2Rxm)B6&{hmxzKj&CSz?ey5O;8#S&(nOz1#XmV281$|LEpyN2S36wjiFn0E%N<i%
z7TM7VrRr>bT3A$;QIIvDe=2t_GR6oT)k+*e*FkVAbt8)*eT#=goHbcEPaC`EGcv(d
zRs8?6_a^X>RaO4@qgg~&#j!<2Xb@$aZjy9*g+|g@x`RnNB<TeVJS(*%MJiQAElC<g
z*%U!g5jWg*RNS|583i{+$H8r!anw;6o%uO#KL?q{aUbRXJ@=mT?tNR;dzE(nGrte@
z>FU(o&pr3tbI(2Z+;bK7s?8eAQ`29^(#vVFo@wB`I;F&*(GGIdccI&>cq3P0knZ{(
z7mD6OCp^sCVM2(E-e86&fLY^s=0Gsiw&?c6iJJ*5jjPUAD@$`F+E65*6nn_LRRnx<
zK71*v70A{49IUG6yOU0HbVD&o!x!yNhFfBV6||=v@KCuqL~d-{9FFCnnjtHSNRH$o
zLH36{8aSb$W75!>Wf<1bK$c0F8o*4{INF4`g#B+K131%KV-YH{1kG6NMUe|wJe+G3
zf;&+A3RJO-t`{;3#S)p1q$DfmVQRmLqb8zhazN3xmVo#JM<u0v`%)o!=8Bo@at$s`
zV#YhPZp~?U)Af^vPIqu2`9)}ulr}N3X+MrILc7<vj9BkAxwS>Gf4P%cBKPZZ4H!g5
z&yf($jIh_PD;DvwoMxR*C%eY)n<h%1?3XQ~5MwoKmQ>uB>(G`;DVaj7piRRfN)_vT
zh!87V`(+ZFMMFN%gFtcm99kB`jL5I$ha9GqJvdW{S2=jx4}Br&&8Gm*7Rcf?0a@7)
zdo^~dD)k_#m<!T2l}W$7h60RxS)nUIm!%w>Fp)iHQiY(%S43j=Nkg+#s^u4Aj~c>r
zs8*u8RRIPbrK8HEP@U0aY4Qz98*2$^b-7VVHYt4*OzTlHGjb6>0m%p!30{vc#hsH!
zA;shSO34jl3O`ebrIK=EIUBXEw?U8+Z*w!VHMpfoDWH0Us!z1k1zgRP!l)LoL)5~v
zg3EO(DXJw)JBEtAIvIrs9}7;jGFkMYh5IGAqe#NUjC{i~CJBHxB@2o?w3>OWMmCVW
zU3Zuela`7&4Hkgn#*8Jqgi0Wft^+0{)UeWKCF003y=WM)hBR<rDxWFCtSbra+M_L4
zc4vySYI@Fwj_;-alGU>v!qvZ4wm*YyG)jy&eY=(`vI!w-WG%9@)_rwRpo7(yt5CCM
zba1qP{E~HjlcSN;Xa?U9ur|0)Kv_Ph$s8TaaJf;y_8o>|Y(5eiIYGN=SvF0X@b$Ac
zxKi8=p2Uz%M2!?YoWR$&0&977&D}3WwrSgw6UY^dcMNXyIiR;BL~G&DSECv{_~h&9
zs76cS<Q=aU>kBiH7s#SIN^=SE3z<YN;sRTsWtP#SWia3TiBV*d1HVoPkghIhZk>P*
zMEs+^Ds)%L|0->{5tDefL?2g0E&ULz;oYc~FK72_doi0UL>2IOD&41oMgX>I0i?uE
zCX5})#rjVQO{INWs?Fk*Q_T=5M}eECAxnUFo5{;=j{l;Q>Mlv5_VhtR03%VvY|Syl
zT|Ji%DIxZBW~8JnHlo#LZJ<zx(KM#E%hE_V5=|CmF&@B!P=>d<F-7=xO2ulAMo6G=
z8}Ma^Sg5+>eJQMhYg1mSa|+eY4)V<imZQzoq8hhF18qhe=&_*7tV(7*gabnCWSc>=
zl5i1T$T0CzJ988zgEqEqR>_5$ngo$l;oo@M^GU6UvrTx5^2~?*tgIb&gkE@if^$}Q
zVg)e4-bdAA%`-j3<XNo-VIX{Vnz%TLpDEW-#-+~|Al;Tl>3nhNADvHWv+nH))g>!6
z8fs}#=4P4hjiG&Z6e85(8)cvtl{tuX)f`N(7F>N-INk6YVamUIY16VnxqD?3{^`g;
zHk_`LO-7>8v*)KpfsiRhjBF1M)d8hq600-6#)))uS7A15-AmgE7Z7$T$`N<Qe^S*3
zUABNu6O9hd5>bXV*n%eVaK@(~Z9(@_XFv-S<smhyANE+aG^6w&L@gmD9X1(cO+p9n
zwip!Epw(%$a29I$WK?Ap)ThfX6_r~NDVpW+qLBjBi747?TPqSu^?ZIlZBd(0CZ{GQ
z$H!uKavrutuK>e}LLTcD?((Zkd9)J`a`D(T3^TVx%X~-_jv64FA_NS#3NIhn3Rg3;
zNv(_RYIp+>NzqAUB3zsT^GHWrBG$kFo=ga|SQ80>fBltx1P!?ursS95J1vQSFC%8K
z-YDe-eKjLsq69HL5pmf_CM1Q~WxEmfP@4iZ)T&yT;x6mN5+d^sMOMV=^0}~zJPKlK
z{@IgAO<~;1OyXMJMwLg_QFJB1OD0c~w5TrL!FW59r9;w6jpknpv@u2H=QOKsL6N>W
zu{Uf~3H}?g3k(6y*!FD_5{t8huZ5X37f&oT1=+<wVsmZV7<zTYg`4@H{1*aSSRQ-i
zO*id%X+Yy0tqi310#)TR3n4g@(IwbTIqITtveIf+p?#_$2~k_~f`vBhRU%)#5G<Q5
zkzZ_Tr{|1P5rp*~alH(X22SHU*a_&NEhxMG(CEbWj|e{BSeg%zQEYymG+1xhUuH56
zrKU?*&lPUQED;cz!WfhSA?{OdDC^?T`L7f(18Z7{e}pJ*pjczX!~~@XIVIODH*A0{
zO-I10TplEV)lY;_rj;^_>5Zs84NRo5p@3;H#I0t@16Y7A+8{>LpmL=JnJPquZAxp|
zQLCCdD_g9PURjlmTzT599I$1|G#e>JDNj!C=%o(bX-xUZ!D)jrLt2Wejr!aeSlW_*
z6qj09Sf4AyC2#w!3C-a`m24&hnZp!h<``{#LKpPf^h#+GfDyf^??~yWs?bNlskbmn
zouif-IG|d9XG?TE&Av^QCz+mhe8J_sP1i*%#|=Xe1|O@mC*|PDLYfm$y7yDJtQR6%
z^KSxdC7f&ma7`jRHxJ{al;uS!&IoI33m9Tk(b8TNsbjVzxY8){6-EkG!>a<6;BF#c
z8~Mf+5KR0NDLgm)Je_=R&4t&{_+s_tg`i_m$!xd*w?X!i<hU&%NZ`Dso;0v%3;|1U
zJP~N54V`<SqA*&7duH6e3=6+)YT<Qww!}K?;A9iT7@9GRiH8@BgVSWy_TP`DHf_rs
zKpS#5DU$NrEjd6y$U#d8Zu7E9HNr8gWcQHDee>;XqL1!EMTPolP|0w$qdrBu4sC-_
z!*<DSc#M^!*F}M|jEkjYD-<9<>6aOKo)R6c@WPdsz$;tbw+KPU1HpF6F))ToX&cmd
zTQ?s`1zA782AbTNj<rehAkj7gE-QOPxgK}zD1LDWXkF{<crB8s;%o6vA=!z$p7x=o
zHFnHtg{xXCoGlW?7UH499|-*<n+3UU8*(<=v4l=e0;+ae!d=XXxa(yh$_6~@C<nw!
z9!)SOf>v2=AZBh#5;WatC1#pnphO`^(qUeEx`%hgh?f+iTBkw;G+hD^;!|$~#&Mnm
zL}E)`3E&q#PSe06H0AuR6M@{qVY#W5ByC{`3_KLFq^R^sob9L-`SDIeE?-N*331Y!
zkKmk9f)gMDMv}9y2D>h4+jY<ABjlzL2iI_;8q)FzB7|5Xoq{M!@Bp+?)Ms%%wTDwi
zC(1!ma^A883*jZ89ZuWHnNTe+fk6Ao0oUpTsJOk0PBy=4(+{6nm103=Pngh1i{@mM
z*Pu2no8@~p50QwTkPNEm1P6w78F8$$BQjZ-7iJ>gd};%-#`Lt(NqXjoHnIg^kJ^mX
zp<S(oR5($y$0PD&OidUnQ71#FHls8n$i-qBrc8Cn1`Yd3T8_i6PupP03@o|CFwePw
zPJBEnsv4ptvB?Weh^Xw=gk(lq$`*0wg<c2=yylpKwGa^A7#PpLaiigruJ(pc7ceF`
z^q&nn7!+DD#LW^XQFgr;+!wa#zCn7SMu%OAFwHAz0z?x^LhEkKK!rPIW^J`nr7MOB
zTf{5H>i&Dw6bqpZ2qFl@K^qpf^?_!h<{GZ2x|zic+)U4?m&pP}+F;$DZum`Z`GY(x
zss_TQ;<f2oGh@7Ylkzr`q%CWTFtqqnHXg?l%!^2gheaQ4#{x4AWsRb&J;J;4Ruo~m
zBX?m7rS8rofXQZh!mywhQE#00CLn(cEwU!yUbj+%wO0!8M8%djwck6fXCz})vc@f`
zXQt}pIkgk<S(X{&F)jh-?9sHhThTY2;>cGXbhD>sTwVz4(5xn)bu};Y8N9fT%qhF#
ziQ+g3>qrBvBsy)f6Rnr`-=!rshBsrq`?NM9gx+O*B85(zh|Oi{bDH8?mNr5}l;>+{
zEW{8=(i8{+$d@vb?48LkWngX<x_1>ju)GrkSbEH&x?$k5mH~a!d~>p4w&!|)<D%KH
zd?LMzY8mBaF-|~WcFV$Ll<`U;HXp%bvIV-{9po_W@GHZV1YLp6p*ACi*?wDrz=BqB
z^J$nb*X7VZ5?6!vU7t9$lCm?3EN*Yj15nEq37ejxkYvGZZKR{wc$@ORjgYP^^-jnF
z$69L>JDgYS50AiuL#K2BAWImYD>Dkmwn+D6T(y}NBAdpt2H`0nKBpfE-(hz;3u8bq
zt-NUAr3*Sihi?NsjH~XbCFqpBz{z0||4q8c+EsW93;%%KUOrn?H(`SFILvrhQXqxm
zRhB|AK`)|MPq{QpMign8k8F*U#W9geA_im;vk^S$tR1SpB!VYVb7;$enxLNytVV5S
zrVux6H}Ft%SiEdgUIvq9I9YHfB?1`%>WDtwC9}oQ;jRq2H-7*Q5wPzt1&e)c26j-v
zlkhg6E5t)N(m=;?YXNdCK7V}hj}IP#zh_Xuo|iE8D9>g~>+o1CRLIakFBakEubP{2
zR#8@bs2F{ZavtW-(fsQe{G}X^d>+BTBN%uD1CL<fe>4VU4S48I0`v5#t~KjwnMt(`
zTeEG=>G@)H4MkqA0(BkeU2_hCsWP9QpOLa_Rb{HQiq*BXYU$t>K0RMAsy=OAa}Yo|
zJ)iqi*5(1*-E(lDomoDZeGk;;A>&U3ZMc4epN)ba2r}a<^5q((P=$W$;JiRAf~?ka
zLL$}gcty(bt+vJ9m9X|D_l8drj7d&M#UYjQHHY@a<F@m9UmK^0@O3?+1Arjj({Q`O
zQ6}~2JHnQZkp*pygxMT>^1ppOC$fCI9#{{jcT^te)7MrLX-Dn-i`N^^Y9ek3{Wy@l
z6Kw`X0hY#a(}qDdNNu#$?U2|`gXb$BAmbF&8z?CZK${t;Cu(VdRcoBJ;L@t77hPUB
zeJk*0y#hy$eLUU+URXM9cFpNMfEO_1k6u9$vtGyanwVZ46JBM}%c&l87}5m&>^2g|
zBz&zkjM&lb#{gkRNg&;8SOQ7ef1yG0eY*fXP}2Rolq1@e-vR%*DIg&(;N1{zJBwNq
zA>S*EY~5Eff`uAW$@awqG%PD*>ViW2tuHtFAP+PxH6&R-{WHPlAcl+ScO5$Ji09>^
zeGL&q05;spD|!+<w7S9T@4rwkQSm|0W@=`_SFxZ^ibOy>1fDYV;2X_#3W>h{V~+ef
zt;he4P^Y!{d_{L!N!V;PWldPB{odgcl#iZhBrYZQP#0Z?cLtSS=J4pvcdDD9H}<sg
zDv8$McUl`x|8bOvd;FOi%#EN~Ztt)t!Nkhp$?_Vu3G^BT+{5TQah-xF9abj*5k?v*
z>lOYJb@ishs>D$-Dd*F(BLPTiVRy#~V6iFHdnY52SZ!05w9kKi4!TIxN~)CcBry@h
zoE4Quby|$`q__kavHKNzF*9X(W#tldw6tQub(1IyJalaqQ8w*5rT|ojI@Z%&DLd&6
zJ{hCi9_icG6FBV_1MarvJo!f**n-I)1m6ebg+#lSjBLJ@Fe5fVsSAoUxC9;-Zy(UA
zX|INa#UrFRbFn89ew$SX$4g)1ZclT8a{TsB+vdzL)24&(NF-Z3ZMGJ=T+z1S0KE2%
zlC))srm^~@#?f-4)~yej+ZQ!>V)X>tbQRFv3sG&s_SYdQ3iVuY5v%)E=3aElszh62
z8zrW!f^A5|m>bs))xmp;T0GU2*Ui}D>pUCtc&1<&g;bY2u`3F{b1R4Aq1y38P}reu
zIJYqwL-nHjvd_H3McCv5C+ox{rlTCyC9ME$PQw)D%4WW{KX^B)Rl`&cz_$0)A3{s9
zO!lyi%nV$^`EQqo+cUT^df_xZ^LutnQ<62Y<a5LiWRy7r(V(zvnO|BI4HT9hN~UP5
z$!hyos0?C^vLvc|EgOn1nz)0?OG8WtL!)k%qSRnUx=RpDh8hC+M4K4D=w}$(bualP
zQ5yA_`vGx{q_Xx0%G%FJLkO1A*hX<2C?V%)u^3JM)R}J{1U-ht)(<XBvpalEFAj8>
zYDsTo*<j&S)&R*yUYYP7x>WcLl!)yK09FiHj&Ukgay0<^zQk9tQ3F#i`3sA6A>RrD
zDo=*q;a1z?la$;r|MD}u*tXD6eX%{OGB*kMWX`6}*vc6ZF|HtD#w_f~BCgA<oU}oS
z%PQ0+tQ3qL?r_~AE)+*OHVpU3Oi}I>MkdC;LVUlv0;AFn+K3K@Av1CW5sii}(IA;F
z#XP7M)saYd-LXJ{`z4W{qzhT{Q*RGvY{mLX^F-a0%Jrm-G1s*ljp}yMGK#hH#*LtN
zer{)u?G2gTE~RWiC^~&h<(QUY!DEWohY?|p6kCqEWjo-B!i7x8I3X(DQ(8!9pynDe
zeTy0=+KjQ^GY<;Sy58)kY^XJ9prNJpJ=1g3_<_A+&`dZMAFRSiL$#RFe1v0z5!D-7
zAH8E^J98{Jgs)D$M?fLMz8I3uSSBJ3qGp~ci^4l&iS`1Kh2v1-O_Nsc^&?3sA45v9
z_*{taV3YtXeZ?^$-=i_J%{!t7+9PJUj}?7cDz+cMa~-zx2_fQfU8*c??2R0mD0b>?
z^RW(Ny${~Giv^9k-)2}sy{9uo_%f`AuC%us8>uNJCSsi##`dZb@n%kZW~Gpb;2~|g
z6X-?DQAv<D%$K8T1e=I|EG4#!dT~zx#3DR{gxGH!9>l63YRVV}V1%M2($EEYdtBwh
zW<1LSyOnl@0>%b*(O4Yq)mC=_B>As?Vmd}%`}F5ZazQi-Kj1F#-W9%B97PA{VZ5Ie
zQ+c$gMzoHu1iBi=j5TyXPUvyNRs}FZMtDwF)VdcQfUw=L3x8o}NP*HZXq>6wsI?ty
zHkh!WQ>-?d<iei4)%Jh{e(X1@6A@{)RLqwfG&e}lit;rT9uz+f6pAzOKa+0s?LNy*
z{Y2mzDo6~i!F0UO-EbdGsTg<ht%}rhi*9^laYV=3j2P09QI3?tG4jb?!m;Tl@sra2
z@unAZSjLM1HI7@5E0tWeSWUz#0*#WJgLE{;q=G_p+Tov%aYJCQ5n+e@;UQ-rqr4S|
zGaHgh`ZBlLFi^1o_%VzJBofHj3Wzq(XT}X84ngQhEXi0fc8EA5+<eE5L6nP!RvlR?
zmlJEpm?&EKEQ`Xek%i;lhihA^?ZEiyU27z(SV>Cx*-VyHn_(&rBZVtrjXb&a2b)aU
zbhJ7@wk@b#QZ%3z8nZJEy48tog=i>_xLa~Y9BSmqADDmshubleb3R`y=SymZYFo-s
zIQkTmyCrxeI5p})Pv>Fqd<~_NdMR@Nve=o&J~-murV4{)VXd(c1y;C-pU#WKNK#NX
z&tI~aNmsC0E75K9<Yd6?k^G9ZmP`x|qCHZ@qM(+BiDt5m;$kvAxF5rqIbjdUt=Scu
zZ>8wD-iSr)c*C7H=)%+tG!X?>+Q-ekB|PeVlrT7qEYe!oUKOH-yyZmJd?wJJ*yfmw
zuc*wVTSvoNxpqxJ8Ruq6tPgIJ+Z9ApHK<>c_Gm7hmIw$?O96?5b!=}VM8Y^O1-Qz=
zvqkBQJw&R0pXUUP?)GQB{t2W#frZB@4nAz8Q;3dC31+>IWNUG439(0dO^Pc70F&&W
z84LA%Z4o<@pm|2rRE>VlLB=LZpj2aI#DU<@L^T2n@M@=$K-5EcVeot$D*S+i6tHOx
zOg7-81CGJzOf~8BA=`_3P=6BDeXNx!9R2fgMmi|k3rqe9q7VVI@XnqLqi3DWYtlB~
zjiO)cKuC;?mA~Z3hn3n^Ky8B$!4FL?^+SispNf5TWd%0L`s$o#VZGv-ylZ*N_Pdjd
zg`Qb-uV)tBZfI=Pg3Jy0{c7NMEhu<Jjf`F1v*vBrsE;0KIN=iwuTUlON@O?a0jw3h
zT#H}yiw9a;9=C&)+SC4%0`oDx;(&MZl|A)n^%0)Eg6H^&ftV@IsymCb%86EzPB&q=
zTI;mWDJ{Q}zl%r1QAlogSb&rBw(E`@=K-0tBs3T5c&jYX^U(Ssg-8v{&H!wzw#eVW
z_CC01NOo_zP5FL@K*L>#eu73C5t8yOeX+tW$HNqtJ#_9Ds-L0piF0v|utJ5UOXbFL
zgwy$U*+alZEz5awGum?0qI$594Q|b2f$@ez?U-X4^TymdJ|fp$m29l<<Is@!8wzzk
z1YlIZ%8jr#S_($OScTFFT8Ef!g<vc%lOcQJ+^{$a(<I>5njSI{sZTd)2k2W(l#SlB
z_rOle!8H`7nre?VQ=rwsS-9h{99-Dgo4n_$_B7zA`eO@tgJ+mZaRIJt+W{0!B$&V*
z7mNkb!&!8joitdi_O#sHdQHlxR`WBB{7ffJspliu04L@Z2AN2qRwEz5O+>bgs%2$y
z8J;Sk7Nbzx)(5diI~H@oJ0LLfY_?q@qZ))G&pI}ziPvO)rL*0r$QW{y7!WAnV^`VG
zAhdf6G@^jKSdwU{1fKTvFCD>>Tq>mMK|1D2xzj+?Ofc;Y?9~=0%MrL#+1o=CO-}%<
z8vjmgL~E^HxQoc1O54XE0w(sbkZK53Q=Q=<Qz(#$<^Gt75;cvzxe~8e3ZcU*Q!PiB
z&?jO!*+QIETBtRkv5*I+!G=o7*sabgLWSGB^A?d`ncBr5FfM!h(K555q@Fchv7SJ#
zh=(tEub^u73?$kNPm{1-{MUJ{t(QyKD_2u&+9b96q;L>fD<O})881Pp#vAjX8|F3@
z_;gTk-hiX=*+jYrOVU(|Bv2*Z{3y^9JN7aV)jaK6sZ4OujLRGOY;II$3nu9orlCAA
z*$yl!jZ=pCMx{!kG&a`sE!HaK1sE6^|L4(G+cMvyxC?ZnVN=F%0ai-VNpb9+JEr=S
zC&a1GdX$<w>FI-C{fu2v+_osDGf{fygv0G~Yn^1k**0IfK=53%kT#b#b4lhB5px|6
z8fAhzfi@6(Of>ej$Q5uft&TMwEK^`2{fpX!0que+MKkJw5ubmc6ou7jnKS+*!xX_9
zGBXv(-l+?dDY<rmj$IDDDVEg#ySlobWv2w{>UoOG>jb|?GI%aey_J*6x!$osg1Uq!
zQeC)_4@I$Y5TNd=74>7A?M8wI9Mrv#Nuq(Z5Z~^Zz&0~RZz}2jiFvRo38-?!DCpzs
z0B$3{P{qZ((7AFH7}Vu(J$cxj)9af7IVq|F3k}>4MGp8a?_{lfx*t4Yq+6=;Bpq`g
z(~{80=|05#X_&;)!MOZgmt9_N@4_PBal>QBsY@>FTV$=v#erHZms%Gj;UEAi?!uPx
zsY_MV3t^e`%`LOHo%Styc7Og?P3WvsKONC>G^wYan@3fH;=H)A0JjXu98`%97UnsM
z=+&b^y&b#n&~FZ5MyBmPc-|E=+2tBMm8Az>^&I;(SKI{>0PWb1HS2}@$cr*DZ??xu
zg<vXlAX9=MS*gq?zk40?P;DC?<w0vGB}HEqqo@Da30&Gm)@wa#p-TaWmSu_+?N1Fa
zGTS^BPFr!VyllH_wH(%xi*fPY$_`t#!&>dgom|0_H(PISxUnm=72Vh+J4j!<;*Q>G
zOuLnj@Q&+M-|JPCqWg022;UPOz5)dq3xchF&^Fg@2h@h7)C3B-2~0~Gp4`aK8>TI<
zpkR5OL_eD%QjUyP6KwQGX2n$<yqY}8-y@)oS9HAwM6q$tQy}57?K%=zF=YiyLC&n}
zz~0ysdRKsQy+!g=I%!zBvapzT>xG8A2$!N4iU9EfWDPc8Dfb?#s5Tx<SyDrsEmd%u
zR?=QHSByG%RphrPQuJN}QYe&~^|`d&XS5gaa8w6)_b%PjQ{$>C!_N|K^{v%hkK#di
zxs>X(Hw4<Hx{{6T5jrS~Ra+X5-sKb*g4X>}_5%my?O<S{O#7jf<jtHx|8bjDy5Obi
zuu+(jyNe1XvGtfm9ngis__#5hT}(a4rRY+&0cS^P5h0~hyy#A2jvG-R!jN%L)PgSA
zqmCcq^2^3~DObdHImvF>Cd4JWs+VAgO=ZLhXL^oQ1ld*6qFZw$nDmqz1-K|~LQ9;&
zde0&lW{a@<TS}&ai7cy&wq1$+J39N-<7TOpD=v1tF~dD73_^QRpd|pc{6Zp)nuP&x
zyMPUn3rAYTY!OPG&Ugqd6Gm8GG5^>o?88%}Z0uy&WClmT(H$V_+KNHjAm>dUXd6W9
z({`b-kZ*xjZtCYGQ_McAw3_Cf4VoFS6io}Sv|l<;Fn4T8IJj^_8JtQdz~%9bXExKo
zGb$;2ZxyfZUrF)u3Y#w{SIAnFV}VbI15KwGJ*#lNnp$8mrOTwj@3`&iOl>}GX(stu
z+?rHwX=o)4zX%+)mRh*uN*0>1PM_J2>+F@KVlJ<&lv8$wYtnz*TE3vxF*yZZF_&2Z
zw*!XUE1U2;Tqx#qt_HAkWM7F2R{V^!27)+8r+}15&VspE%2D#|UU;mmxU|*DNszjE
zvQ#YPvUpH843sD%y#-e6H?Yu#PCX>EIn<T&>{@AhsfL4A+If*ID1m@b7p}k@Bm;ta
zrVtbZ!zH9iIGjx7^Jxh%#+&{`c1e&D=tY}}E2XAE-MF;VEamC8I-Qjy=K+?Hf~Vpu
z))!`o5u~LAWxJuY^2K~Uzj;%-1x!;SRN9*NV9O#5DKQ*YXUO7$CcSNSK^_3yiYCn!
zGo$Ww5>5a#*w_HF#2vFO3sBUB;-*qFFY}~W>y)wqdboud+<8gKIJ649QinxcA@%-7
z7j7&QrE1DbARq~Eq17tn_uVa5^s%1mM}pdHam$-KU_Ury3~=)VmD!;2VRQ+D>O%Y~
zWomA{cvb58qpBg5l&kKJryLzsnp_Uj;?!{k`Q>V+jQ7yfNl=Ucc%^aar#pvZrA|gg
zQD+qg;V_lzSlyAK>s%>2z(Smyqbo^{Y%x+3LJ2FAw&*C8>T{*E`(K;T_1R=XD1^32
zbD?@sh1RHE#0D?nHab*6b|I6kfm^05Z}*^FnxzxYw0m$~2};=_o*km)EHFD$usg3R
z+<DPsoP23yrfZ2t^=WTS3MqV7yr7uFp9DlFqs7=R&_h|BOgLex;LfDHsihw(xHg}L
zzP14qX_|8@K!ZG@xzV!^@lKq2x;A=81fGh4A`jj%*ZQ6<-tAtmU5b=lhu1DedhMp5
zMXl#or!|_lB^YOWl~Lu@+|JI;*BkR`$BGq$>f|OZf7GitT@I($#L_Jey6jS|$P#6O
zZrkK-vu2!VEL0Zrop4pVn$f}0{_#uJ^-Yc@VeoOlpvGEuPEVN?^ogr+aeYVe+7uKe
zYA3f)ZB$UtN@pOSQ*78Q<n7UX_l7N^;!C4h5dgCV=(5w&joMBW@{r<dP=_azNoe_#
zBLWfe+=zS4t#*64$`V<VCm2$DcG|k{RI2azN<@9V0!W~RuQQ2uKv&uIJ-8dclA|LO
z=TnFkEDV|~JstB())+pi??gGR*(ZEB)H^saW;q13tbZw|foUg%%%<f=MN2UW2qTVp
zk)9ZY(V>dDxFStwIdO5C&WXMGkSxS98^#J=ho-NrcW#vpc3NJEDq6M@O0Ap3tlI~^
zF$|xanwT6PQ)^X{8EokpJbey+K&O(H+Ke`*P|d=$7__nidILHS&RU6DI$0{wKH1uX
z>_L6}_-hh;dIY746H#<hT$UmbGwFTg9?)W@R-_lnI@pu2HJv^p&XMtm?qLU26&vb7
zKGLWbNI4VQ+9Viu|00&DLIG-NL(-C-QYYwlLORl92%{|4VfsKGA4y_O-3xmwk9}Wy
zaoZ!AEWC9l1i|Ll*qk+S<&55~%WLr`K_3DY<l%}=ELhT)1|M}j)A<g&0B3HMrL+_v
zBS<_95=8hop^a)>%A+U=FsaKkyTG50jx%|?L^g71d#=R{G@Q?LZ~{)d@lrjXpHJMZ
zwO{~gD6R}gQXACi9s}rPa=NwHnRN!QmUVZfoo2q`ofihXTEK|~DZ5fE3#Rd0v0inn
zxZ7E5F7$R@O*UUFnQBss4GJ2yVd~&)feUwbFu{fADy5vL<X6IP3yn&tr=zh{dp)uT
zPCes=V<-oBWw+TVY)(9fSV)j67G|*R!QLrtdEQ}QlhDBqLmCIW#9T~og~~e=bRRdj
z^P2yqX4{5sCYSLoRuBb4;+>8yf*4hqIu6NnZ%j)~X2YiYL}Em0bSOE74s_B|f+YZ@
zEh==dghReGTldg9KzeUfmbQJv63HDTo*u<a?2M(V<-jfCVrAOFGccfzmDkYSwKA5h
zwu0D?F6eXHj`2Y?$c-_-f3-H!kiiG7FX`IniBQ6E5TBr=o(9Yn6dLHlEb)f4Ln>sQ
z?cUfiUHeXQP$4}C$40iHJx>ZDz*nu__Sf@0E2+_p*XB+1JA|xQ^(79UON6S<C6LXV
zNR$b+*oMMncnVc0$TG93S6|a(z5b?c-;|%tW6MNu9CRW)>6uDmsH>g|@0fQLYNW7E
z&G!mb5uef>v8e8o*waCqRUG}5QW~2YbZ_1y5U1{Jxzfli<TmzBleG}7*c|{*@@6Nn
zgGL&eg7V9e8g4gNP)ddLEZ8;8rY}roA>6^Zt^+*5K|y^52QYe!X=ZmM4is?78?I0>
zD;q1QgSy}mTLN8%EfB&UF9UP3y0(p2hL1K~6AUD52QAx<aD1Qjhxvjk@NboHTvW_w
z&(*OPztC}RoOhf@y~O0Y_Z8+h{W|GF$N5XEt!B+}malT0Mz7-xU+g%qe=_PgQ<piJ
z|5E7LJ&x1$EXO%<o8!FU6rE20pFQn3uQ^tS-~B2R{~LzM#5m5j5jzzAecwxU+*5CG
zod5e2$NAUG9cT6lCf}J2^P7Gh&+Q(w({X-mwSD|8j`M|M{CWR<oj?4E7dXz^HR#KP
z;~euO$2sJ5$NBy<{dpwx5m*0uBl6Sd?58@;DQD>4^#5}<I?jI{;y9}wZ{p<FkvGXN
z$GKtAagHmPF#S69EEB%&0>^p5GaRR9yW@Ok*2D*Yz4;Eu`TC8H^OU^fT(}{aYQmpc
zGQXpK-GhElU+6fWJ<oBj-r+be1O3ov8*uksgrhzm*lS|nvsM58*^G&6_3P$k$N5su
zalY|to$Hd*!nq%O6zJ))a6H9)@C+UQg2&)5@I;@VXB_8;*E`M(XhuF449YM4*KIn^
z_X2T0&pOUeF<#wAnY<Ui!u+OR=Yb~Z^J|R9&1)U!YmA=(^n35~9q05D9B1lz7%R+)
zKGb#T%N*yOpwa&T&0cVu<J3Wu*OwgUEVMO*d3glp^CvLxFTuFI^*N4n-{W-s^8YEI
z$uC*`koc&--+5wGtmE8$w28l=sDFO|^ZE;Oj`P}X$El!=sL!vF=04SN-jBJo2KYSU
zB=l{S<Ggo|$=!oCx0D^{_6toM{W@%o30F^XoaQFb)3bq-nu(WRkNz|HrT@PAI@Ecp
z<9z(lj`J1Zm_D~KAJ8GkdGr?jtBUa`j7n_hf4@Ab%ic%$!I*zw$Z?*B_TTh09sg%H
zo4T(J(1fJ?7htB(bpbv@agPUm{M(<?Fa0?ebYOp;+HXQ%#GJ4{?+VPjkD<>OPdUy{
zp6)n*b++TI2CToi%5ipqmgw_ljFo&YT##Ss{@x3|a|h`7w5H>{@^Z}m{owbY&r86=
zuYa+ws~7Wf6nx@@4d8c|I?k6tEB5Dlz;zRN_64AK`n+Ym{u}lGlfiTU88k_sP5VHT
zpgsF@U4TX??b%qD9*6mNTaV892Fx}3{1e*gXZoP<>fMg>?(-dIaI@nqfmTnZ-{8-|
z&&LN$%t`qDeZb#e2RRf#4_WY6{2h9U$rJbMoadU9i8CGNr6&T1$2-pZF#a#K=*Z-X
z{`Kxb$NA_hb=vv4aGv`?2lN@l8e)IG3|!LZc+l<@n4ec)q{B_rXMY|5?Y#C99rM~(
z+bPk%KXRy!e>ZrW{TX>I)=cn2`b+}X^y$A={b~E(H8Ja}6nq!|c>5uavlHXi?sGWP
zke%-xCt&=quw%l%Gk1jJDCTpZ!}$@NcE)KK|0g-lb{>=egEi^Fy{6nhg1#!Q3Dd8!
zHvP*1w&3TVRy)qa7}FPmC)^ME`}=2rr<?^o3|TA5=Lg`Q!Oy>4V`9E`lH*+UA{{>c
zI1?|wF1p=uUWdLue5=Hmzc*kEPC~y=0UxNNzfqshyj;hw0dF|@WPgr3D<*tT59BQH
zvE9cy&I0;&J=4{<ndh3E=GR-hu*?Jgm)-~-_;eHh4bY%`MkD$!X>otYt$F!3t03?6
z>6}Y@fQvgZ&KUE51Dy0Z8T{~>;1Bd!&FfPAC>_2RID72#9p}~iby)uYVZ(81r%K5D
z{WZqnD9(Fp-f=!W?Km$7AMF9pus^%3^=~|YQ_9zSHRQf^;Mc>DDR09X&<oy+F~Yyt
z&qEPoAI$t#;5zCv#$z0nMsfFJoYH)rf_ZW^){(f++h=vk28;)N{_8OP_r@jtSN{JU
z#$oIx$Z3zpTph!jGYT2;NXPjjc;d6p#=d5Y<6Lu&&i&{M^xwWKr8H#5ORxvP`az%H
zppNs8*1zTdzj_Mf@mn0{$vc4CN$@?)tE-XcjhG8Rgq-9oKqkcec`oSs`8mh=80PQ~
zj@PA!xIL*W>hBonI{5hsWQVCU{IO^z^7D1{S3bQN`PKUGLSU?R7Ipq3K=brj3)zA`
z_k*Uc0Z!#}0p@7|IM@pu$Y=5_$GQB~I<$=TpK^z!ME|`4^Q;H$kMbP&FxUTLi@p}B
z{<7zTA3meo#Qm-b8N{0ZzXx)@{1}r?zdlpb;je-=J~s|}z?gmXx!B_&`odX^73S@C
zK!2x#e=qMtA9y{}rS$)&KgV%?3BDNoym}aG@QWcMFup$v`Urmhi|5f1bKvJMah#uF
zJZ}Ymq|b3zIL^op{rk_Dr~M1sdjB(Z-0hFkf202Y2ef@IX!1X?Ha|QM8Dp2uHHJFp
zj&q!Q%8=JFCO4fORoWl-8!LD(`jhtaRKU>5XD9Xsai6Je;AP;aNj^t{_Pd_#&-n|i
z*UiHn=fxOz`8<#5TEb6zvf~U`>$t?z-^=dQp~LI??>E37=<~1O8DD~2@Lw_X{aDcT
z$1ZZ5{A#cS@SaB2aSoj5IQx&#<>~*g-K>8fZsB_W;~nR&Cqf41dHjB~6a3t5t$UJo
z;>*D29)&#%`fGpweHwEEw0|7tu6(|Ft^Cq|U%>VK&Vuc*KR0=Pgnq~;f4%<o;@chP
zMWE#kz^(mx*ApCP>nWHgi2uk&$JqzkY=AE=f?ppE-uBp8J9qlu%b2@Ioa!%k_fg;>
zXPdb9U@d$R=Gc1ze1mdakG1nKE3YY~f4$1$BTpQJtb_j8pZTYm&`#jx^UsECfU%~}
zSs3f6&wri?-nqtceuTB)qwBCfpW!&a-QzgNUW$D#aQ<HKucV((g15c!TGWR*b1dlZ
zU!Jc^ehKT1d>#!P$>*~r&=c~?XBjkd(JdGc@V@gfE-$%3QZQ!VeNmr61AB=UbGr;0
zI|}sh_ATJ2FTy?v{6;=MM<4CaR|8`wX<a>7uaWmC;FLape4hSG|6j*E&BT~rJO51o
zZi2tQ2KYDuH21)>upb4U>9gAEyN+r7|K&&e(|@xYctW4(^EuGYy|-Z>vW&F?^X*8q
zaTsWQ9Pr&ai9OGf<NP(lL-{W}p8nULj|A{=(lwHz|9%2%j{W&QaCvC~^f3dx9D;sz
z>(noUSN$5evOmXN=Q!7bE?RwFZ_(z++HlSffbYb8_N_4~U%3!`Y)pqgf;mo~FJrCz
zAmIEZa5wxo$WY*OpIe0f^?c|J&T*Xbl{#P4{}<fqIDZ~7PoH?F&i&IXz(*PX6muK%
z;b2`=@Re&YR`U7D0Or+k64HNHS-~y6CQ$!#=xK{OeE22k3+D6NEIPgMVw3k&rp4bg
z%vWPxe8Ot?F`ISXLqQ|-`2pxL$>-<iInI@PK|k}3^C{r(yvLYQ+voJ}(=cwAtp{CP
z2Kq+-=(7mC2S4M(kYipA-V1(nCh-4vJeU6VH0&>~3g(864K&>9vunttzHfv1O~39!
z{qnhXtNhY`znFKN!$A+ngI?}F6Z>Z1`3Zn!uT_R}-ewPszlujfk6_>t3_OB?M=<aR
z1|Gq{BN%uD1CL<f5ez(nf&WJ_aP$|u4^bOP?EbQ+<HYIaRnAd|JpAxs=<mZ1YZc6`
z*p1Tn9f+g9^ciywSNr=Ec4;$BILn(}UT93iHaxq~aP{MS>wBDEJak}ttNI$1N~w<5
zRP^70{9<?S^b8*KSYF>V4coTq{*iTq`vw8GhG}hf&D!A*U?_m=r};XSsO1~ed$hlx
zsH}8FLt68{;}YA4B-Nm*B|tovB(LA)f65Z|n)64-XCx|u{bRuTE9LCORJ*q1?H^nn
zD>ZZZq}lmZqjuRfy5&+Q+DKhMnLK*5kgT|vP9|>8DxlhH*USjscIq1+#xrEGNDI>E
zFy4gBjN=`0+*huYQP|9Y7%*dMaE{=4vGS^7YQSWPLO={W@s&(x8l{CoWL-AN#&n;u
z3@+=7;tE}3`Nq(`>BZi48wl^tfuHl7h=Mg#cz0R(PVJwVqQVEMNDw12H3ze4w6r1~
z0$+2-Tz(OL$W@0|@wg`fes8f%j$o#{yQbMwX@|wov>t<%mY>en_QTIl+G_T)AJh2-
zT31rxV9#VfJU&&*twtQvQa$X`S1po9)^eeU7Y!2<h{-;!7BP2nbC)~OKaOWCr?=zY
zOKuEq&FWDdR;@1Nb4A>3_m(ETjIJx=QPstKwN|;p?e5;PdBeu;4ePt7D>GMMvE97U
zdFa6J+R%NqIRn4%)0NEp^l)@ff&|%`Hz{^-X>rZkas~I%Fo1jEQ*7_PHEVa}@ZG<5
z&DsHXbh|s+H|`D$PYm{B$r*4l(YB8a=%oHh`a3bzk3aqW?!+LRf(-Xh4euIrC&vf-
zw{`3IfpNEg-#!&`_n^GHcX(`l5B)zjwXJKpYeQGJW9IyTJ2^EHk%gL~!UKat!()SP
z-(>&ru-iX%$@m~3?4Q`BVCfqf*|palo$Pn_3{JSC!;_<ZQ~f)ss7@K48l32x+BJb%
zw(s8IjtuS@9Er#_v3qQ4cy!Pm8Qwn8H*txbL&H8Y*f-|(jR8OSf$GP0O%6`%8SWp%
zZ{!%DH+M9+BfI(r`iFJ^gOh#RM+V*g!6~A5yT1x24Br?49P1lVouT;Q(eZ5xeCzk<
zq$)8mIQh(}UE@d{8sD`IPWW|$lT!o3yWGBs?ZZ<F_PxUcgK9X2hlU3ysN#XaJ>8UD
zb%l!U!@UDFJao@U{TQ2acaN)I$ULHlPWK%D>rva-rTVC2hX-jOw{&r}$U$R|T876a
zF~-h;UwO1W(7$VJU|12!PGE3kcx;ER-`&1@cw_)$xs%4%-L{xrs?FD{;OVGnU|^Vr
zbP}|+O^47h+<^_~k;IRI?Oe~;;9hrf;F+q@T|+~|{lk4Dx^9J}?SoT&>c`MNMI_@B
z!+ZLsKn`deq&Kmxe|&rjl)QFR&)W4HQ1Na>@q=S~+@Xo#K|p-TwgGZ%f+SP{0vYSy
z=}ulU*6;T30^NY__VkVH210`4JgTs=V*wLuaA%$VL*GWHFxhrsST4<ORZn}k4fVTF
zsZC}pRmg2SCQx7paxLY0H}wD_{M|y2E~vl2GyZPuTCe~1Y*K$WuLo`r-%H+r)n6Uo
zyFuc&sQ9ies{Dqo4Vd~v!@1l{rd)<o56HelnAN%Np-jColqr_*yT|;d8aJZFOA&u*
z6;<vS!goJ-*hAhpkB*~-?hRc8iKfiKF*O7B>>BBt8pc!@#YhbFP4!XT<w_3Bt5B&z
zq(q-_<$P=QoO9IEr5Yb_*8wLElW>qdj0?buH|^}3ba!FUhIe7u2Kz=QQRC=#MdM5B
zdpDBXL?D$M#&0I1E_L_zY$WvIZ!c(<{!+K;?`A>|{%#?3b@#3(+NQtcaSnes^b)$d
zdpCCLzgxO=JzKhnZ*O%DTYW6{TC1=(I~3o;@I4&gBk+9`zDMHwXnc>t_h@{N!S`5v
zkHdE(@O3=?u30<V#1*Qo*#fXp%*>YIH?NqjZ-vwHJYdhjOVQThK4L4xZTC4X_hHd{
zB9cAS1@yV*EN*@~@q4-8GD1G9^c6(4A<V6#z`AN~#yRjL=g`$S>_ra_!S}KFo`COT
z@O|jO)15=q-jnd*!U1s&4~*B{CjHHoO1OyXHtTuh>tK&cec|WTrgeq5$dx4l93At+
z^mrdkXGg<S$7{oMFB}f6-74G+z+r}SV1j8mv_+-X<8dr-NqspBv;e+N^ug949>iBF
z2)&#u<!ilk&6RkM9}iFRwY8e@Ks4$O?nI|a2Iz4v>a5QKLw=4bnuUuAjH|!>r})}$
zNx#0`fnUHEFN$!4c;Gnah}A@Gr{Ft}lVS=#k;6HJhg$W;*G5>VrYB6{9chm6NcHYT
zy{F-O$&++DvmCB+c!9$=a`=-R{uC@=sQjlnd=G~|%i%jY{MQ^NE8mu5&<<`~hz97|
z&p*TdL)3jXzQ@B_gkbqOw{;oRMil-J4(~&_CC=h$ezrb6Tlbs*fVWV+zd*g~@FhbV
znRllm?7Hya+;GVazP`n;UihYYS12wky3u^&WXhYJ!&A1!99+w~B`fWEq)lK!=*wQ&
z#EV;-HNER{k~UTu%9peLw3|?FFS&f3fM=ad9f?Gzx}2Bh6*OtL`rGR!zAxn@jf?rx
zZV$AFM6aBeW(ppVdHG6zdrmN(i-6Z@*k2oH$Hs@3CWRDl(B<CbZ)an#)h|ioV!pJu
z1=>TR*Do*46!iKfV>6LiQe!6l@^G&b9`f=FZV|2UD)~L!>4XC(FdhVNi1u*i^`9cq
zcd0}AhiKI|iTB{w3En#P74&(kO5%rhOxF*m1~ZxL{Gj%n=bXkcd`;z>%r_*%l#*Sl
z(2hE?CVoAbryt~4ZdP}|r)(8tAo+BgR$U{N^6XHvtkya!-#3HxO=Pn9y~W1dK&eE1
z7TCTW%r{;uRxlq(c9T4zHpfW?i%ZT}6#Z}wkVBrze(9$m!lJMLM0>89>L^{SRPA=u
z+T-G#?Ir=B98=(hxypPouldKXQI>da8J0}~+s_cbxS6l*2TTx=7c!XO{q!nbzUJlm
zSLE4|Z%pn7$O}_=S+B1?ga=6Imm_r2k38h^1MiY}ab1XmCuiIVcMhD)WBDUpSAVls
zLkGrdm2AFVAI`PrlkIpk81!teh{Z*(Ex$z@m*RW$(V8Fs9=}z;VQnVxo`X1Y(^9TD
z9<85`IORxg-tlPqX_Swj`vSxC=t$u@^fED?svw~oa7a7%>pJ0KRFA<Q5GGhw!Mcrj
z`okO^!<a<lNE16y<kh(zW%Qe$p*ZrI?eVZDBcJelJeE)+_yw-bNFyhiG+utWf>szK
zb9T6XDY>{*$>i|*xsqL|uaAB#Zpoqc3$T7s_-KR)7stSw)DHvYS}_cI4b>AMLVhZD
z+J>d1*HS#3rDHA@%OXQP0sX3?b{Mg?rfdKDAF6lRs+jQgRMcBTz1vW)tW!@zoV&2#
z;@Qw@v3sLit($ejPHP6z&a}$aT`KAv5Sii}N^|??^4a;JN=@y}XY;j-n)Sx${(d+P
zCH^OLbPV#6=PQb9DQEfnD(48^9!j}3MJw(V3*;XJYoEOj+V2}HnI~(}HpwjGm~`M*
zvKo7QcO&&fZ38h2&>6Rw#R`KtS~Y#$Wb)`#m9vibguo56`5g62c=WlH*Ue%F&y|u7
zwT7;n@(KP3C%$~D@d9@Jc=1Fv|ImRR=7+8GDy+<4qdrgduS-;>0QjgaCt(|vx~n%j
zs;|<<`amD*a5m?nw{uugtX_L<Y>v;bdT;e4aT%{C7H-?MLxU^0ZI{>T`HE;)Q-gTy
z3htL*=%d}1{IuOVmtQP5upe9mqal8<13140wSS2D=`%U}We)E{nE30r2Q|OFoWn=&
z(BT}1Ukj^as&9_NcX0X@9KIc4nRD}qbNA2=0vh?@h0JVzJEVTYbIO!Hgbma9;G|X{
zn7MW(r484|DrI^kf*c|bmst={H4%-A%y=Q?Rc|EW-E&^o>xiTNi~(NZf9FxY{#s*T
zW_BW9g&Xj_dYx@@-j`Z=ClEJS&Vqw6$3VR;$D<9;szR@Ur->tU1F!LoxyV{tZ(}`r
z4Yy?ERE+waf_M7XiF(G(EMm52W{M>UeVz<-HTwE`KtUHHgnum|Zn(}eSEV+T$E$+1
zJWgShdL|VNA^xq@S=nmSRbIt{bAWaRW<3{LissLb$LFpCysYP<y=`uP*=>~SEZ6d0
zfpE8yF;whc3n?qro7wP1$Qy6<;lRJX(GJPrM|f~d|M6H-4XcpeD^dStExr->%2w)1
z$709TudFE=JC4_nn~)FQz&u%)$~7`&U%6Wlhv~OWdnc*urHE6GxYT^q`&}waxg-zO
zok3+i$Rl%^;;?K~_t%TFWh<V_V)dL=(ddW3NAXaefhU<ZP^GU8@?ak9dm%GZ55{GH
zkWgH`SPsS^%Gdwf2)4QX)k>q_wM%dnN|j12(0^(|`cHYt`C_ns^ryQE<s_fNiK^eo
z<aeMfx>caEcHaqHDM$4aeko6f`c2WN3cV6NMbIm0&<st=SiS=78~x^bZ(Rt)gFYKs
z+K&mJ4yNyzbUZmNn5N3Q$bmjeyP{XkSBpU9dXN7H;;EEZZ!pcSS9r4GL1xda<wV{z
zr{KvpKMd$@*GJ%%Gy(><wD!Igc%`-NmZ#${)BSr1*KRFStmC;s-qo`d>EZoDI*(fV
z+}XM$dot^X?est;gUe<=tHuCN`O*>^Y7FBbYlyEs9No|20bz*Np>|(~cA;h2U1r&G
zP<e&Jc>**Cq+6gqe++r3&vWRr)PE=9VhgExam4C-xZKUSIY#w-n#0dVSk{)eBW@~R
z!_EwH3NLv?Pm=x)q(i6S*F%6_J6ucjUQ?qlV!TNUV8&ZuQ1mG{x5lnR7=-RH%Fylt
z3jZ4O{YV%-3p`l!*@a}Mc(l-9FkR0fohvTSj!CY@qMPV?yqw;+1m|oJo?yCH1KK)B
z^A(<`gZs}P`*4?{9a~mg%yJ06abe!ptU_2*di}q~82l71-~yjF_diGDLQ)Usb=9-W
z^lXQ7ptZec{9#%uBhKKNWeT%V97g=N*?Wo|M7(iblvz=*b8YQ<{-hRqQ4rE7`nH4q
zV>`##1%xerscg_FZn~VS#<hdq8`G{avMy?C4dw$aiTPLvo<$gJM1$@F$C!>8x=&Pa
z5$~f$8+8$Sd~Gb&wKL)r1xj&wgOn8mLoi!fOGnSPRhvA<VZ=8~;X~ODi=pqDU{+dw
z<(7^fFN^~v1>O0Om4v2!L}Umx4isPgCi_7%iFCx?aiP)1HZlsrAVs2cEzGcEET2PM
z%Q8hKqZim^Mzu}Fg2tF>>?k3(8GBb{8}%nJsU)kb|GAcwB->gxklKoHMOKy6-~YLm
zl+<5q%nyoHC3^h7%9fIFAo34j@7S)AM!I8LN^MFxMaGH$jpme=eRBtPm9P^1-(^hc
z9Jl~Bk>q6M-?2{+o5%<7n{1CB#P>h&J%H~+_>!Fv*$Mm--(TTN=l<8jcI!9ztIRGt
zFw0DCPnql9UM$0owMx71dL1VEFfQFkwA!J*%Jb>&ZGn_?deSY~XN12)?`V%rr~gJ@
zq0jfMeH4j$#fGbPQU?Jht2zahA0|5OH!#WhpxVQl*F@Z0zD$-ECFn@WrbFotCGY2H
zA6TEOG)p<9_|}#(IG*$#mo)mWP+tqM($GC!G49czs!4V7AmGgdEpjYZq1Og)ew-fa
zOWV`RCNci}#-phq?xlYz_V~8$&#SjkYQPv*Ka%H%|4}~p{b@(|(pu_)eA1+Ub0{{Q
z$^sWk2GWuJ18P1B-zR{Fh)(q%5f&?5nx7K?Rf;d=s-W#E#fuJC>#OLkNQnPhv*zig
zzpTqBRlew|zd&(?9KGk@<@=J3^X0owm-XdS_2pDHPiL<3>FPXKzoP5&V3oF2AGixW
ztWOQjyRi8VTl|85T)slOimjXJeWmop#?Y!ZKMkD-jKs~IC;HMve;48#<@}On8!PA8
zQkBdrKdevj!6SOn`)N$w{M=$btB#FaT!5xC7fJtKOuEqNcT{>`t(MupTN&@7Y|FV6
z&nKW$1svHd9!6F@2&_4$`QVrK|HX!nK)2@5|A|NwULP6<eMdu#dexG(qJBUzEdA)v
z7T@D<KG2w^{bPGZ05|qpP1Z+-MuiR|$K8eBHQ-P3M2<b@iNil7OIi^Bl$Js+iPq<O
zZ_I$%0#@R;52J@<FVqEoOW`9<(BUU?_$&^?nVw3&fWtKoPjdJL2&do`(eTkTMr4=B
zYr!1q-T>HO7NXjI9*1!Zqr$J{@bw)2OAeExK<dkvIQ$`mPjFVP{t4=O2;Zw|o?b)e
znL6&b6i26vR^0Cqw=|bg=h3S<-yaa?LJBGk=y^`@Pe2=I;A_WIy%c{MzIMImAlyrF
z+&-13xbyK1mZ$hll$YV6ynP5?9FdpeN36Wm{!IwKl;W(mDDF;tgKbg#%PFsggEt~f
zUh?ho6!$@VgXJmyJ(Slf|1pH`r8o=M6!$qRAN7gi?!z}&=N`n7Cw!@s@={zOkasct
z`WJh=FpZlCU>rqUgj>^p&N*v{9P4Y&B=G_QYHf|E6VC#lCi?m&V7VAHaSzkmcR2ia
z9R5CsKhNPGaG2%_mH!Ec@8j?TR(|0l&qo|=OGuUhG!U%|6}OCA$TEK)3e@?lh&oCU
zb<Ab7{RP4CTdNF(|6tYmBp=?f(hV^A3;*D}aImZTbSMso2q)A>;bp6l2R9mPWZSz&
zKg8~xA6<vEVE+i=xc=tlImXN5F)+2>>h)^XYD1TP_y~40XToV_?uFBcSLpd3PJ062
z(Q`hWX6QMbX6Bzijd1=b3vU!YDiA(45Pqx`7Fu~+1fKAWDp~5MvG29_37%ZBI1?pT
zRDmV4KCX1lmo_?F^8u@Wo}eSROBn@s%?Gz%9w6&I)2EK_s{s^flChF$Uh#B{*CJ|u
zBHzV2hr_2J+!AlT{Zsg8WO}w)%z<g4A;punq2B#yhb~|e9bJSl*)GuiG79hFu-r$R
z;4s}+TM-<%+klN^P2kvvdY=n8?uPecYImB$f6w7(bNFvzBu?o$4*wA04&?}8&rm~v
zd*Cj!@W^@8eFI>59PS3n-f=tPhU<e@HZ!FiyN3t7_<qC-uiCcF=q&ai-W@KNusEpW
z6kK4N&*%EecrVi9Q_*>L)##3t%+csP`zn-4<m=s$ZNc?JEx&-vDC*8q>%0T`sJzi_
z!{P<o$=N)r1y7fHTj%Y|QNLvmy8-Zm%iyYV&5P?s9PVwXI2zw7!bFER;htom92N8S
z&YN{zsLsTli#WPRV&}V%<FNDh%C1Ko+VquWIDBQ#M7|Q7uuy*m7A{+zsm*)vokIE8
zR*(8nLzwzd=ewQ_4o_QsT1#bA<)&`#ld4<x_-YSjYs%C!xh{<P-Da883HcmM4l`;`
zMr|*lUb3P7D9`Kt9R4eWr4Og6wh7>e4y;t)q`~olq8O>4SH1<a%J53r_g)1!WDfCq
z|E$XZlgI-R>8<Cyj|ax+ke0x3i?nml{PqUGK(<vUF}`l*@Q;}P-pb+MaQL+xe$Ek^
zAH9{s-+mOlRJW2bTfrtEv8?o7)cGF3v=jGjWuD!LI9KnSNy;l$a2*zmtl(CvbgNz2
zgo@2sIBz|hDVwZ<-xpAwi-jewN$F{0(&}{ADkiN;X~Hk1PTgY3lkNQRRGk^;S135@
zWdn#wyCaZBB?S&HC&jWhjDa*?-|kenT&zn$f<@qe1Jb;dFpN^fhmSy83LgUFt2F#s
zDQNdQm_`K!j<@J?OF=yP<NbKNOP48og+NaNM<7kXFKxYBl`D8;AZ7gV{<i#S1i8T>
zrwQmD48C}(&Vuhl47&#e(gePHd})T(D1NbC)<vxLKcVw`RY`xi4UYHs$DgMABjrBo
zYu{D4leE9mX<4r^t51P6A6<OPU(TnO4&Xx3wcz4jT`q)MUp(Vh%6txG7VEkQ@%*i}
z{+Ru4c$b!;w@^<G`*@8onT~7{VKM~s3bFeW=?ff~)~mk-Y~KQ}`vmx_@UM4LADPS1
zc@*9{UKHvi_(ewgOhi82O>;*_t)JG}6nsb4aP!M|-gH4LzU|kg`t(s5psLRO_!3|t
zecuOo9r+4}@8$5{1=9cCN|*jb_FD~`mf61^sN)+}9fG@;ATEeIkI_K}lD0k&m5*nV
ztT{p4EfsTlALc;oQr~l^K5Ya<mjYE*I^U!@o&+|^NA&P*)I;>}5sMyfkAl@(E$SZK
zd^j?nOn1}wNIY}j1=be$aft?#<g@STUmF3Nti00qf9Afw34Is5zA2(yT{Cz!fBu!r
zyp83PA0TYg;SV`XbSOOQCRL~Mu~DqdxCM9%@Y;)pQxhSL&ri9%Pg~>D0-rA7fXY3<
z<=$oWEkH9oH5Ju(_-#qgxEn0v5Dm8(`$YLLKM2+b8D}z=4{(@pm_oO1>qqADnd-Dw
zX~FUt2RTYeR%?ZQjsOwel9N|@X4is~N66@_d~I*-j3?&jm><&pkHb(SJrL6&f6dR~
zPG*Md`yIxB&K&*#`Vl(T=VJO?ja14sk7RH0F!Ea`W_(M-$U}!fzaVFFQdVf>_b7||
z&f2AeYwHqWC%W8F^X>?gCwLCEbOnDzIdhV1V2P<O4K3O0j>ZdZ0dX-)`=JGrn13D%
zxQ+*0@8NalaU8y#!zXf>9`+$xe-elHaQMj_UXO4~J&%7~v}s-I0`u9NoXz?7f{zDu
zW-pkc4I2mM?g0*D(R(#-PXg?ubHzhf-o2TV5!Y&u8Ii8=avI9fnUZ(Dg)r^uAH3Me
zDQrJLzKSdf!_&Wedp9dzvmBYz(8|-$&afwpO^(2=%1*chP%y1y7;b@6ZyLKU4j%wa
zvSy!yxS*b#b-Qi}l@XnEs5cGqFnuc~N^knqPRBSvM-7m-a(ffOub$>>L*{)C`X4pk
z9qKv4eXbX;%3B?mb|cO%SeIe*_cMJkAGC2Gm=uPHzuE24$%UC~L^B(KADSaiwdTm?
zKQ+$E6&$ZumK2B<kKP*7uD=iG`ucEb@^#6krSLeai&$`8VIT|OuE*D|tU2e0VfJ`U
zM4F<3gCH{~cN2m?KYlj);1oWf?CkX3uHI-u$b-UAOMD)4an|uZ@B;J+JcIa{Kd;TL
zAjfS?li$t4Cqfa|y3PIfSeV%OBGYJOaLLxYFW)Xd94D&$0+-sa1o{Dol3CBZ3yL!A
zQ5LEtcw9t(Ivf|dZ>;=E62jn4u}X5Te_Y4{!pyx^<ATM^UO`%pi^`i~TtfL1j*BXn
zVqEO}GA<qRH^DEegx@YW<x*6sksQGBpby6#j;GBVu+b@Hv}sguJa_oo5`Lik-6&oH
zMZ9txbWqk;4TrVP_-X5+NLV8HsdEtcr45UZVftYjjf5#;JwAvq1r}qhEq<8BBVmeI
z@0^1mA26QmB_#+CSwR_|(Bb?D)2r(V0D=DR_O(ar{~&lh$*}{^)H37_4qwFKVGfTV
zoI*CY*IM{AnZ_6XgChCjr9PNe)&}j|R3l3M9|P>usGatl)Yo|q_j9;`FrDvSggvC_
zMz2Af3pXsa{H)pr%DjG_inm=#Xgjc7h|l0FJdSLrDDK(#iVc#)T}pA5U6bUiY1g8F
zVb$t7<-u2E)-%sC`t35}Vb5H`8L~@WgZ#8jJvFo>a9?NDwFY}52q2&d?RO-YMtgyk
z@JzCWRmzN5J~bZ+;|&2A367QUDS{)GNriYq*#}cg8-iA6cG*e|hv(jXcG-hIAAPH$
zg>#waZb$fR%(vfh_*Dp#e)AI?eiMhkh%nh9eFr*(@8WAzsahX)8q&Ur_;2BBZ6SSn
z><-6L=5BsDPtp<8?dx#ih4pqH0(?u{AA;{?2;YG(oM5_{YE@aAiSFUUoOcWQLbUyI
zgkQmV$-fQBT)}wNAW~#Lk_-o1^U6FfdSu`yM)aT*53@T6b6)RZv{O-jV|;nw7u~JS
zR)X0i5ADTOJ%Bw>lc&qJ<VZe#AW+~%1hT2@_oDNd^pBw5u)-NdLA=Z`sU0M!{_DB;
zHl!;6NMWR8M;)(p1$Z$7HYDOk*2B%sRE7|*k?H9^Ejc-(-5o<>QXU!T5NF=Q;rpn(
zmXB=-5)z@g&+s0~lV64tFQePP)0Fd2hLJ!iW4oZ>&Z>fn7k>g}h;DinT?hI$<z2V%
zWc|BL8@6vO;>kYWP%@5IpCRJI%_}^&<%l8ylk96^>ZCqI)@hBY)lV2Kp{G*kO9)Pa
zkhRrFRm4Gr0{80Bv6Pj~rPyy+x*r<3rudJs)QY$|1R?<3vX6N;wSfhRT<X?b7Q&S$
zY?OlX0ZK@_2c9iX^f*<@D!cMeSNHTpc3<IhKhnQFt)ZU+EHsX1Gryu&>M8sTgk>%$
zy3`Cy1FK*)zI17g)j%74{oARJnihFE^wX@YS+6nqJokyBr+u+WQ=UcUaIlB*!1G7?
zwujie+=hHS7d_qaO;py$#EcH^^}60X-FU)1Hs$r7c%1Cv)R<ZnB6@c4m29z2Ov(7e
ze5ZjCbXqp90x|hL6?2jN4w`jZ`SNwEP(c$n*8WKaA0N<g&$*gvh#<T^dHjJEM33L<
zx%U@Tj$kH!<C?Ld`L1Ry`X_VCrVWn^xeJX<XufMsaS+xWo<>@hlkv6Y4(JM_3d0w7
zCWC2CB9W1k{)YNS4&=~p+eg>uDPHzwT8?re=4GI6I-PL|gK#B0+tBsdI<<F!`onV9
zeP~N$IFh@FUS!O^5RtYL*`I*3<sF5!keu@&ADjoNJ$rK#*lT>)*Piq}h!>JaR|<=k
zIc-pa`>c=oU=e!y3dR8si)elg(G9Lg$y+xVs@5Y(zQ2pfCo;dxlfMt-BUh2iO&rET
z<QdANo~0Td8=k`avEv1n8r;qcFa0O0PP;xySM|YXdqA-8^Crz#rF#Eb4;W-Ev(`|_
zn<>zeWAQe6rz2v{NPd6aqVYrjTeLBghcZ%o3gz3sn9D8lla$SiAdf)n`mOvtvdAyI
z`&%>~e*BmNK3<7s-S|54GOE*@)rmY!UO?nG@I`Oh5b0?i=ikfyt&d(??n&a$-IQK{
zSfo8O{Ox?v*N)85Ab-+(##O7ohrP!4WA-ASNBrNk*oz3gk{rCmi?1aJd*kt48V_2%
zmBk1z18U*(q$zLCe8;NG=CAit9X@xeM$Vu!S(66+Z!WLoG$L`T<6x{^_TsgYu_L~2
zj01u^?H_$(w?e(ieocnKHooC&!%sWk@}+f%H_`1H4pY;LU4L72L&~hNG9QUfc^OxG
zj2|IPcZgmGS(J1xbQkAAd~KZzoq%n?*N&sRKBPgl<0#+yKpf>8w&F-0KEQ3hisj*7
z2ExDQ@QXS9_g4B!X+y91QT*e_fYRWr!?98PLkmNmkfj=<ejoaHtvCE63<X;D!>2RB
z#1A}1iWkP{3iAw{Y(r(DZG%oi-9JMQ)-ldb<+lC-ZEa`Wm7d4?jW8pV^0H9Jt8cV@
zpcm2HDjtQy0<+-Os}RQv#jGduS#|i<t%zE@GG_u7UM~#I%5r44i@pfYQ*!Gtpp<-S
z7v3VhSynlu{2A1yU4AK}_T!Qssviu$SlI8$5N8L=V`OvKVM_T>dS(V*QjP8+lwPP*
zXoo804@dnw@{Q3-u35_ORF8`7C0;6W(aA{1^*<c4^|M4U$*$9b{N|@Vx|Q|lXk9;f
zImHDMxbudcm&i@0AZ-E;z8iy!^xTXuzQ0tdGd!No<8<WT3-k@)xkS9GQp)d|xdOnz
zRjiT4sLn~L5&aN2o`m>*JXX-itHwfo9LZ-ELtR99k(VCE+^1pW*MR)Ez?GoMDwIR?
zHVw~%wP=rY^KS&*)12$#@U^h_uyH#`?&^Z5MY|o!)e$lZCR0;i<n#08Be0qpKGR`)
z>MfOsIj4Ayzr7=U?a8<V^~WTytmOR0TX*$lv4#9}v=5$^e6W?AR>CFM>4oYtaTL{S
z%?Eoi-p8T^kc~Iqn-S-_$g6~MW^&|X7c}F?6_qq&L-f<f^h56*P<W8T@*cv)9DZ|`
zPQMgk(p}$-_666^MBJFT6`sl~-vuH|??f7u8t^HOsR$x3?RV8%Y_8I0V5g3U6r`Su
zkQX<mb1p6?!=bNI-O9Q?jWk!Qsl5DJXXN7XHoSA96conh_HxQkxZ~}Et>Gd*B)meM
z?a*$3l}|E<^u8zJ#2RIV$7!1gmB(Hyym8TWD2oavWwSStJ_mI**Z_F8%KNAfo{o=u
zK$f@)GY`Q(*5Ru$3{HZ#C2hMn>}9I-Dxs2(o{ct61yxW*H2!&niND;5@s_==t?P+;
zd()RM-k8F}n}ruMLe|=7;og@nG-ajRcsEuH7$eE6$4HGqY+nDE+v8>ShJ>40#?4*8
zjlYadC#H<hiA7^Jv3mH3fzfM2(K3{H*=8fpbHG)qTHs9J&|?(+&W6w$ofXFEpMq(`
zFFWL2BER$BC|Q(lNE$xWVLM6|CBAG7pMv~ugRh;IckleX*q$%72Ho7D2WUW7L<h^D
zgH5RUdY&`aaQG!0zLCSPK)Ay>iZ(M<dfkoMdpGJk5A79EpYW}>A+GM3t{ZveTEuHn
zPoo9TOL_eAjYz}lP=nHvZU(A*7eX5^M%n<qNR0vzs%GdMPSRd#rA=sa8?VmSBaIy4
zFX5R$yk}o0CAE}O@7d5f)sTJ$its0M;%<V4(k7u-o0klRp5I65*z=F(7q*k&I{-89
zNqTT>*2tirlsfuI*PD?_Jh(q4>ARIh?QVLrN7_FUX~T8XV|fpT@O>}R2;XaYJU@pp
zjrWxn{@;Q)pc1a(an-}>*DDdf7k6O#ao={TGTJOPire?Yl1y+?MfwE2Zh))Od37z*
zz;rXx6iy&G58?_^joxU)+deYp(q?tPZj)gB0?H6<;s@kD4!;nvN?&h9oCnENMZojY
zZ;5Kx8vmDB>65kW2pwN_s9OMCPvZqbw#We9{PM|e^u+K5!P(cSeJF+$ZdgYuX@3_?
z1HL3p?SbT+R6W^bXxdAgoNG3)|D^L6!Pi%$za;Qm;~@3kq}sIJUqaawyhUVb()|%W
zJPFT_i^~GIShf0Y@b7!@^&Lqm9P0BMrAH(6p`}EVb@1y1GwINHMb)}A+cdz)MBdpF
zIpDX>P`*KR(3z9Fqzn#3Hv0#}FHyU|Lx*|=!3mvRs;bng5u%U04<|BS-y*nZocq<Y
zYdvnG;&xl(`A`1z-eCH-{pon<-CzDY{&ZEo$EyFk{&ZE|PQO1Qy%*(IFo$rGx|px&
zjX_`zE%<QMa{tv%55tEaT6nGN1qow9eCPk5PZhLezsqdNiJpzH5#ZF}pr^zC3E@QR
z*jt`=%NQ%01CrC#Vo#4I&f%3;qr<h@CK?JfYv%pGpk1(6tUB}>#V}kT?R8q>$S)TN
zozmP5$T@(lKHsQlgSNn!Ec(V|1>;WrqODQHK6u&JhVUxl2?3Vi`KkDK;6hDXjH#?K
z52|sYIj(Jrgnv9h@iza6xFp-5949!XaU*ad`u5z&zNs;%c|X=%P<$FXAnErn2wqCl
zYbhQX&U)+JFC|U*`xM+^S@ZeV!E{=OS2kbCN`U4M8G#3AgFG>W*Sy~m44CEQ8@Eu^
z>wSm%3pPEd<8Gn8we8s;C~$&nFx~t#@X%bR%^}G{aO<Pw(L*`B2Vudtx1K5<JXj~)
zgUsDWA;00zn0ndyJ(*hF8;?gzx|ZX1=1KQ~^0K!%TGCbBUilu9yH+rlKzG@Bg@VvJ
zLpMqd4lZE*^05R5+f=}-zgw^8dt5w@2Ay(w7Ag*0TZbBg#X7J9g>Cd>rFS&dJA>4q
zsa!)5Iestm!Jg=jW(hufK%MlyN2!_1Pgir~Y)bL@6VT_EqsFsvhmmOEi5xzc!>4oj
zSsXrx!w+zH1BXw7JuQ{Ljl(bF@Y^~3@5rBMuM~teyU1Q1^}6(4)b~2T`!T-%_CXGR
z;27QhJsciD9)jmS4$pD;TO58fhwta`?>YPf4qwZ@U4F^oCb#!n4&TJ#KXCXq&VMwV
z5tFUwuX!$=g)r$`x;AQfh7l%wf1S(cIs6L_7ZIlZ{a@(d2>u05|0w*xQ23P`KEU|>
zI){fi{09zyg!4Nm^7wN7V;nvcVY0(K4)8x7-^r``we=e4nc|;<xHWb><Ze1&`wZgl
z#aGVFL^pIY+65~f&&}Ype5h7g7%pS}l}h6<ouYXx`JQU$qeRL(1eb{_qgkhX^#La8
z`vhPo-2Ct;!<WuLeS3;n>oX<w<U6(1A)SF6*FC-26xt#mA_I)qJ>2#x#_KfW@nt;D
zF6X}$`3Zl$fNKn2EUC1gQhP}1!wi@EE|<%3c#gx*<M11~o$ENf$mut5_(-0A&*$)^
zNS8JKShPEY_p3*WGqp@@zoMI)kdJWpQ_!jK^mpK#l*UY(!0g2JbUnti7~d_ZLu}M(
z+$nA=;$TRq&djMVcXQi?!%f?}5JxpBR?p-1Y0mdihWWD`{xpaGn!}&v@aH-F1rC1!
zVS@b^JSV=$>Cb1H{!b3yfUxxKN0@Wy+Xx<xR-%JVgQub&uB&u<$fA$1hy=&rD|0Vk
zCOhk=qrZdnU8dIqy~ly+)TNNglD|ov=VIhhgr_{cQ4&8YhI$BZRL`^U-Brz(2euEZ
zGir*<;H%E67)QTCABf)Q9R$MdZ@Eu5G7f&n;TLiE_Z+?rVHx)m(J%Nk%ZmQsWVF8<
z?Ocm^1tYpj(~S<)2p<F=rQe8j8<thL@Ju}Fos8eL9KH)-DpN)NC!l>PLpI?QcM{@&
z(7|$Z!J~PCfzs9>O~D|DCea*ym+@MSJnmAxiU)sTKQ-r)e+@}{l1f|1%;z}?u#4<)
z3Z(_cQjQ}DkLNP%H}X90Mwn=c-dCjbK~67l`VJ0%kMaCW4*xxeM>zbC7T(9vH==o(
zbA(r_x5)W+Vr~emhZtB#Dw!Nl&%tG)IV$r!F7q?sS@`8$7@zTh?QvwN%3aUpUe7Sz
zz~R5(@QoaP8;4)b;adP3wfim({}}DAK;D8>QJUuqKLHu|x4^h9ZzVj}n1#}@IRgVK
z^)%Tu{0EWyN(J-B0W+=HPXXUcteXkcr*7%vMJQ~!RGoi=I{$z=zkZ~~%Rg}Veh%Ny
z;U9AN2OR!6!kxn4iF`~0e?Xn9u&4Vb^ZPaM7f9hj(C1Nn9t1R~Ie$3fKZ*RJ^M4NN
zAYKrRe|k*(<%ky@&!<oiy)|60;^<voilciVB<oYX-GIj(Dlc~9jqWOV8jNwF{-n2p
zVS9r*9>iB<1Bp98ab(4Rjb2|U-vd@Y;vW?EYkZ|IYi25VG=$pKX}>|5%P*T6Ia%vY
z39h36my{)6oPvjAV&abr#7qB9MSRHXht>b5BfXY~#)KS5$zDL=Y}M+=Ani%`N?%D1
zptzIqwS890+&+`ybtNvp($I^8XB~q&iEmKf?xVi%gcD{u^VKh#`|iC^o^K?`^P?7d
zr2l6VOuq5Oac(oO_HxwDpSMY07n4qWW&_g1-!rub5_h6-Ks;1<|BnggS?D#f@bdE<
z9`8S%+HwbF6vi912|Y5vo#-{L!hH7UVIuO18J|!`hU$Y%th`H`^(I^&R1eB)vdMF3
zsGh0Hb|Po=OZt68D9_{)$zO!0O-Lg?^m*`Snj40O{Jx;2u0uj~_2Xf3qdPl1GTk6R
z)~9gawB-xIEqTIi_2E4vJg<v99qKROD@N^r$+c__zSGSdh}{3K0~MOJL}VYj_mEwv
z!Yl|!GHO0*`Z^DNNBs6nrUt>Id~thsO&DLkoNquyTH|y9$~Vj21p;`M)$hlo=&PJH
zYG3kX5iz~I(3pnDXNaJDyL}#ymF7$9dz{wq;07NwO!0uN*Vc3rIO1M36m4l>m!33x
zvz#M`^zE`k4~%CtJzV@LU*0unfpR1XT)qN|aNCs{f%c_ud|0$EQQ3pzip_-op-K-I
zb+}Q~?|;U?+qSBMTtm#Ond!hlCCOhS_TB`I!Xzo~ea9ZwYn?F|3l+g}a-o>d;gpTW
zEKw`%iv$r8Q*$tz{}ElsdJi-Dq2b`$u!*1#o9K2}4EVx24R*QG^8AW!`~LdI+Um#N
z+&m55^!!31Q2u8;jf-{bS1jX4L9J8_3;A3Twrn07u$K}0iClNnhAmsx_ikR_Jzbf(
zBA4cw+Aw7WsWQZ$d`v~Lgp_aH{@m-g{no8|t9ASC;gJFLp6B-dN&1UpAN=X>cP9oX
zrzVE`r-pZpxs&6A{oA^AJU#clZ=VY3=U(;GvG{*%YFpQG*M=_2`2X9>w<Igs{p}kW
z*|pc5*gZBiJUZx(3~!(4o4CXs9iANRo9f>QNK?FgJ2bv)TNibX>?tOv28MUJeG}V<
zr&N`DhX)1~qK1ct2PX)Zcw@Gkva1%T*ghOXD8!LSrhbe~xx2^JuZ|z21zlV3+M>eY
zu}KUB+WTMiHZ9=o_&r)0^No1#6vq?}`Cr?FFZrO^g6~#*&%>8|hi$``>;<2J@3Eu{
z#CId+#)Swcf3K7#$iCKhG(?ObS<A>Yv=(AJgYzyelhacQ3pnzQuPewJz>joMn=$3q
z5jm}chKTT>?O-;bM~9$y+wr#_-#&a(`IZ*BnqZbaM1F3)GCu~yTBkM$`F#*Ilb(q7
zRy#QiRh$YxlfzpPmObaih;v2dJGgWG#F*JjjUr8wCbQ5uOl4-|0tAjcy?yH>)uHc~
z&g8Lg&*XYNo!(xg_2X<r?HrqQ5rNMX^}U36TvJcu$4zkH?W2GMwV%8U?TrEl7jd6w
zID9#WujKFmhw04<%1`(EW#5-Wob-DH#(1TEm}eCAxrXdRuR<PoaA&W(qg0v6l=M4=
zJ;wfRQPQdN&;vtMP$%zl?{k*YMIoYw5euC<B*&oxa0quRIieqd={l)zs+K9&3wapi
zY1J>@0}+^>D|r;q{B)w4i+V3e?{*|U^94;MI$QG3DH20q(sc#qk+%1|1u$I#{GJB<
z_VAwc*2unJ(OjsyGtC0}rX2zJe4X5AmmwVqWk+t@dh&ccyx7j;;nb=ZeUg3ghoJAn
zLn8Bel$W?yqI{`Ro(1&YdH%~)og52O94+!WY0m0p?h<a)=0A@YjIrr~b%@5%ooFKi
z9GwXq2`sNi9G!2>S?|4YoO(OP&sS*HA2hx~o&~g{Dc~!Gj$Hc5JnD*>>~amGfSCyz
zOkqzGs7Ij;zG&cIi<mR&>KrCjmmYOg<;P*cheLnbY>TuxUs~s|F^%C}t`*?RUe7f7
zg!)<Z!JERy(H@sTJ4BKiZa?0Lvl_ber!BNdBMbhxa#dfN%$GOl`2x67+4{HW6RHZ~
zZqe5^t+8)LyX1d*59V&-a}gth5KpKz8b$W}t=IAQq0aqise(GM=e<ITdof9LUdf+y
z#C)TE(%s{$@uj=R6#fjuNd2bp=Q;c|4u6xwv<{yQy)M1+cL%=Y<OQY&HHZRmA6dbz
zRV9JJj}SO3oTpM=dbjZ13G<TYi;pMBEAr0$fQwAziaGtr8O=3WlRt_yoavGxoGx=}
z35C{D9OuwkGK(yp-1C0qcWH-)gZHV*o=P#N&wL1`&*E#J4N;%&vf@OSD|OKM9F-S1
zzt43K?1vJun58DLHfTJ)#HvTueyV2(_s#sk8(HoPoIW``1!Ks3gK(hCR?0Zw2M*+%
z=046hnlRs<n0(T|ub{s1(Sb%~SD^sGK+(!K34YMhJxnWf`<=q}`=Av5Jg3w9pcIyS
z0l&v@3crfe>3vW;Kiyfk)9Ecx3QKu<UzEb~z9_x(X_u#WKJEO!3Zy^GVR_q=?!Z%i
zxdTsceM))ZPj3MpK<cDXSM%vnRvwx^bg!PuNT2APOR0m>A8UnM>&@c@=Om0FN*5E{
z_9WEA|F`JP|H%B&r<6(3i3Dn$gP<EquIY_}nTFD*^z$otY2LQdp@oXK*W6N(pjvgh
zoU6t`2P`TbXkWEhpB^J!lyaz;SeKkc7a4+Q5qnRW1Bn2`l2a&Rmmja-_Voh_`ovl5
z*|r__*Iifk9Z_Hhr&$aP!E71tjG$3kC@9d$@HMK1sL_qf=c7AI*<9Dk<_?Piv6^63
zT3(dq?dTw`8|`)G5oDJL=p-cVBZ>CZ>Fb2aK0T0M?Cy0ZH+Q)c{p02gF<+hD4lO~B
zZ2am`FstSdvT{90mT1F&tmos<N^KtIuOW_QF+5VX!EijPKUA#RoGBHv)0NEp^l%v(
zF;B;yMmbMfVJMTgYaRUmGL5`r)`9_7>)D5=1}FNac1^eggWGrSa7PCB435~!cFy*{
zTOIF+3_zo&j}L|i>F8ri7pwbm5<-U{|1T=zNd~aaSBCbvI8hnv-|0?XGKNcpyKvAl
zIN|Q;8`%w%5Q0V(E_N)eU9)y@C%D7lPMrFVPUY6D-GM`rOS4;-=y_eYp?<@!kW&02
zaROgtni^lTb}84psb_=wyJaIPMR?0bAQ*o)cCFWcdp4=Ro7Znve|tAz;v&6wgO2ar
zAn{vNeAgCLenZ!W-Zg87hI6@@Oc_u8uA4&$`u$w@5H>(`DcaxPT#v--+Bc&0OK~83
zX%*G)7{YfyI!7RPZ|EXW^jXp1Sl{-ML3hutk-n*6{1_da>Ko{r>O(_4<w_2$tWc>!
zHGoAF_J>=u=bQr{OE7&>IMFu<C*gu=7#G-p#sPO{-=w>1WWXKXg)_RrzR^k4IJ#Y(
zIxVg5-Pj8p0kMQv+@~a9dV4k!{_wZANB^aMQ+PAs2Y<H^zPfwYcR{DT6=x~OVz2X7
z><{QH<!$)B9pAg~eFwhp#P?nJk{?~VTlijl--qw}@vVUml3xy8+h)RgckhN?!g_b_
z#%}$0OP7XbOBY(5ZDwlda{<UGW@gLqFAXnKTeEmN9H3{Q>DfBmw;oXEy0^n^_L{Z0
z-vkdg_2Ob4xY$SI(}5m@I5>3rqzX}nP}m2P4^lZdA+Ow|5Bea!E72vAx4^udK&Xaj
zZ}l+tX5`CT&P@)(gIeS_e^S{=uUh>>r2h_IY@3yh8ijw0uh?LU{U+_tDeYJIitkK`
z`z7MUR#M^~q&W7MPxg~iFWinO?KR<2@=|%Zqd<8N1&l}HD=?5Bec5Z0Zv^Z$;ToZ1
zT^PoKaHXt<)tw}|>_@nI4BGq*a5c$$?<a70io<7dcsGa73xqG_@Gee&4u=Z}iw@#8
z#6eGl6D1`r!XE;jlvn3UF097%ot>kQ=Qw=r{u5qKK-}X4@pOOTiHJK1-}6hEg_&Fi
zHIvVEoHXR}+0q3x$8?@ktg>qsq0(7%_L+c%a;-W0tTUDJYK=Vqy$0|B?@#BlYa;3g
z7D=Ce0ga{PJ3S&FIeXR_>C9)<>T{51T|_>Cw}<m|Bah%f!)t@9JD`C+3;5Ob_C(Yh
zgp=Ce7?ID0^ElL(MV=*mWo}S-5nm4`wrwUlrnEY~_S~Sj8ou`2ptusn@!X(x`ViiY
zue3wqDSV^ap|o*)?K&y$B8s!-o4^{JZvvA&-=w`@UTI76iY@Ll&{hl$tIL(R6zcgu
zzb-N_HkM?MOZ*DPqO*B@DU-?(ozpuSx1gN#U%#WF<6jhrmw9yq;+5#HXViGJJ_pxo
zwf*YVJvFcNIpO6Bo@RM~HV}xHGsx%r%MX=Mft2<0YvQJcU;ERDdzduhDX&Dmr{HwF
zjyoHP&m05y8yH)PN8OA1eu`GkU>@@&4qw6HZ*usZ2zPK^gMB&HD$>~ZVsPln6rbb$
zE9!j!?Y@xP`4NYu-3K^4%jv)7@P|13M-Gb~^q7-$eNDcv^Jg61$N5j>u;}2Q%;CE@
z{bUZmiNoC-9^tz&{T#lG!<TaSB)*SV=J2^3zMjLka`+V-eglW!%i*WtZVip=hd3;6
zbKcA0K2HA{hhNFzA9MJ99R4qakASZAKLCFRGKDox7$ERpg6Rk>@`qu4d>`ZFL=JzL
z!)p+xHpwR(<zLI`4{^AM(=X%jc1~Z#V>Ha^UqyNcXPyMJcRJ)9H#2>Wq3&Y<`=?NM
zhxlmJ%JnQn1JtPTaXIQd4t1_ZopSc@D(ISV&1{KXGWp)E52X3th7Y8v_uu6lK+@pT
zwOnvZp|*6qexqLGm{(&yERj_X4#7L+3#H-$U3pStKZm}qMqg2_8ryjelWhWxb(zEG
zaJb6hWe(Rk{8ANOwfas}^cs9|ny<<?IQ?!;e=X8pXQeN4`cFCi^+<bzmA=gBt6A=R
zBhubvrC-JAHBNss(%xdFKZn!b$mxH9w6|L6&*k(lbNbtm_I4}%T2B8hr{9INcUbAy
zbNbU2zgV^Uok)9^m3||qPjdRZk@g-d{RNzU9jCt+Y45YrU&!h2=k)g@?E_Z&Eu8+(
zoc=+ieaK3`mD7(>{AktczeL)Ht@Iaj`esi52+}@krQgo!*YSAY!QnjT{}}TA73I$?
ztMPsXr@xZZKaR9dSn03g^e=Gw-AKEK(`jBDj<w=*2+JC7-{rF7&*!x{nE!&9`17qh
zVRk(iSn*%A+O_Mq<L&zGc)NZ(-md@KG4<Q=cKvp|UB4Yq^^+X=UDW+OeCc|azW<`*
zzK=MO?<n7c2>;TGlRJe&JA0L#%{X|$p;%)kV6g_dNbw|!Tg7p^%XHf(@7ZBd+Tlo3
z?mj2-CERqveZcL?WQo=n;-8e~NaPuS1=m8AOup3RU&w6w9w^%0y0srk0G{ss5*_SD
znG;YZlgsfbsjiFSAA@+vykmn?`EnL-qvTMA`t~%$Z^2jkOEMwForkZ`(>dp8S&`x|
zu;RC=c6I&>t#~~iI=;_}U(5MVLEO3c626q+7>M7SDa~((9}>a^!6W%89{z~oXe+1A
zuqRN*48At(6qmy{2s_1JVa1=yG_VVCllacy*&y=OMR&(2ZXdoH_fxg~%G;i%nX3_h
zGro446n87W!8R%W4l7>I%T=qF5O)o}pgJCO-A{^tF20H$IfdYncny!3>*?{k3;92a
zuMH2yeH`B)JQV*KE1uw?`d^Q@cjJrADF|wKya(=N;GR#>$CnZRU3~5ODeimt2J5Hz
zA6oHLKix(BTf}`8UtRxXzB*jxCUhUp0)N|#uiXa4U5Kx=L3PRg;ZDT6ZvXPKX9TJZ
zBZ*#Q-}D;EGr{jcd3o9T0(r&e;asxeqxuG5t&wfWg-EY1<+G8}cbCQUY_K*DHtll@
zdDX>zFWV$un)ZAS>{GCj<;19Z_C)qoF9DBHb}hvUTP_;uiTWn+KAXzxYlcHLY^@Y$
zKzfpTT-XgrJ-1VPOLd?a&pTLeu#gOMH`*ZicC%W;k68Ulgh`$~AK^spu&nfHF8494
zg)%k@-@|neIeJ9E1@n9_6x>PL$WdS2IICZSlS@^;?ag8-*H1_l8yo5C45gD{3;c)g
zE|-esd4)R9RyP{=N}5z_^k-3?_JYSSKK`1+r=eeo{0WhLYhbTA1Ml>N>(8Su@;7-V
z*Zl>q`>8BH+{fY5Is6rbN&XZ+D?de;#_D8F{~5xxfBXoCAK>uEIs6|Su5tJw4lg1s
zGBf$E((di`8iFKe7xJ;+2rMO4+^E;G|L+k`vi~=bNAOL+(3F{?Ti@PDJ1fxXs{7+g
z*Xq{;yc#VVJwVI7lJER8d=?F3wo0{_EAb->O4jc}KVE|t)?sW~?(y5zUCE$kvwz%-
zdS8cn??=5Wg1K3qFE9Dug_uO$Z$RBmjEC^d3)FZ(g9zubGunonJZ5*v8oLK`JBu&g
zRKgQ|P}hK;$Ubg2m38}aS2XL5aq{Q|<&n%!ZBM-e9&z~j2yd*lydw0#{xh}P9C8h&
zhSTt(hiR|qsyV3*&Y7k6K&~O$+e<J^<{KEbiK$)9#;yW7QmO6tnj`!884?-{AH0yt
z=z35x{to+A$_Is9UNrhjUtK8>4pubg&02|G1(iMWC1~fJ7?;y9H)-BK3t^%y(rc`!
z9j03}q-gds)cYRPEBX(Y+x;f)#;>TIh5GV>MZ+1?`+l?|e#^256HT9Yl<r@i+kFDg
z9H_su2vdJgU_Mvm@E6g4N}uQQ(`ugsKVBSO!1_$-6@;n1PjUGxIeio7uOm$Oy&CHp
z<^TU!`x1CNhx7l4o!SYZDnczGnnWbT8c7f&A_++~9OvG9ZgS+_bFOpl%}rF%Dy5d9
zs8XdZRV}*EDlKYjOD(mR+JCfEseLW}-|sxnGw;0bJLlY!^zV~#?(@tu&ph+YGut!s
z&h#lf4*CC2Z4A>Q_6fYK(CV@uym?<U-$eeOc=vN}q^@0#^ruU}oA)?Z!25ryFX8QF
z{xbO90=^SfUtdxEY`*&cScYobQAxKcWjG$Zd1v&d=u=o1Uj<Ct*jn@cslwcuWBgSr
z%Vm&-@HK!b>yO<UeWfA4Q2N!@lK5)@)0SRR+xfM^E2(W<ukdRce<NVtDK}U1zZo#)
zF`wuY3J+dY_&=%X|ElSqR@lbOX8}{b^OWE73V)>XzM%9!M*9D$4n?=V4*vnZ4<p}C
zb`d#W(tOTUIsXNiZQu{8$A1H+oL8t^uW9`FZ6*DGH2w3M9+N|-*Gm<COX-grF7)pJ
zrrwTIe(x#$g`nqpa#g^S5wNT+@f{1+<p-K(1Ff5n6#iIw{8!;;H2xEXpHr9*lQYkM
zDm+->A)0<Cz|_f6TBh-U*?v~n_?-dMRt9PMT>;Y;y0q?g*Z4cM%zG;QD~0z`_zRkT
zZ-vJwJXv9zE6)c^d99tDuJC)>FP;gQb@ae+(dk(Ve?j}nbCv!@mH#_{DgUD?&jkuU
zsqlq>S)Oh!&qWF!t?>7i{%xhd6fkY#b>;sjz?An3+P3ai*z|LcrnkB8^MKj5`*DX8
z>vzyFfk$cE84Q^6{#Nr_Ug4V+UJ)?!x4Z0C*7y%Keigth&lgqxRTVxQu+2}$!bWgm
z>Lfb{y*g;f^Hwd>8VcX0@LCGrrSLim->vX^fN4W3PLMKf0GK-2RCThk!W*efpH=u~
zO~0AKe^+>Og~i9X(vYnbw!7$dS9rGC#GZhuQ|o^Y0Ze%w+(zV?qx4p%hbcT&<(a4O
znVSC*3Qtk~M=Jasjqgy{`qxf{zpwG<1Lm6I{|2EhbPjeUa612=;+#k}8N@t^ewvT5
z#{WCk0+<a>D=ro%0{aBwp9Q{L$4Mde^(46IRhh$ykBRu_K#K*&wBr17JFYQy{mLi6
zF9&?+BNz;LEd=usn4gOHwFCSJ&6D^I0zCbd^nZ}|^1vfcWM}>!xu5Ivz;A;P=1bqi
z1cYq9#P1s5Ennh8U&iL@dm`@<2<Cg@{<Pt6OPD(&LU=m_$mZ^4<UT9srB)|jWu0*D
zo1WK?4rxw|)402WSw9<Mj2?y%mXYg$HUul9_+O+hABQ}_Onr8BN_S815~**qgXcwN
zTsFYzO;Wc{0-tz3xPBL&k7aqP56adcKSUW=Ot-jKf1Jf}?J#ArO!UopW9yS8EPEmA
z7trgJogO9sr;vXGDlg;H5gO{*);K32uc`H^6~88#g_rc4jmaA3ds>D=a3LsSdg12q
zKAUg2wC<JWWEq0;R{O<oY~{JymB;PA<H`^$uw6wYK0(t7eN0}@T3qwLP$%)S8s9`N
z`c<;Dp31d*DckYjN%x9LVs^DzU{}_6e;2f_9;fztpV0Ty>EY(ZzY^T$UYWEZ$&0=T
z9IEp=H2p6I57!nFBXKrv@rx`Tt3h5*Egqnx{w`zu{`ekvc6AbN8827*<jOcpe-Yzl
zbvhlV_)54KlqaKIJ7vH11ayVIPZyf$_V5DYkgXsCyZfi4naPtG2X&(FsUvef*#Nt-
ze1GQUp5ngR#!9;y-UTjiKVgfY*f)PcaNTy;2jqM=xHOL!=aa^4>sQDJ{Y)XzZJ}BV
z?(8<(x|Z^!3H?6ob%?8{cr4R5&U%iov|xd|_&j{;)XwtFf?pu<`z*sgw&u~vN_2ju
zrt|cscL;RP??~8SObO2%^0wGS&ZT%)A^fHk=jihF>x4%AHC=x;l{=|v<CT{E(3I@y
zxGy$|o12O=JN^yrhQ?7Z6>zA(QWrz^c7A<>_+_tKJ~7}*mZ_6MN<JG)*{`ro6nItu
z7Xo)e<#dv9&SEsdJ8LA>m-NIJYV9bX>2t3vDHV@Pg}h>I(mmOSI<>ZT19c*I^>*T_
zTxJxLC6y0}n#(JaETb(t2OtI?e1oG3aNT4~&kLe@mOYZZJySQ!C{wh3NUuR%hV5}-
zN+uf<Z*+R@#j3TtgejJLbVCn!!dA<C0?dz9QCb{p?yFTit@$l!Q(AvsU9f(i4_tSP
z@HCdYTRM^^Rj-j$%i8wkEm4!gRb5t3N2l~;_V|0~DRU9CZ@<4o9LB%w<>1R&r{2!`
z%N4lZ;4y};J6@-KDOs1%hJ1cFiEb|tyYK1k%<|nRUq5m}mAZBBYYLwLnDd>R0N;*a
z^Jv4}Nu1v0YkkB6z|}E~mkRj63Wk>IN`m(PKIR8O`|s>>`)Y%SJcRTwAz&DG^AE!R
zM6mgKc$S=TFCv8JWr=$M!Q`T>#63-1aJJR>X3wiydONSmc|XsRzK!%I1J9D0-P{kn
zmSdl;`b0iX=l4TjXIwicyX}RJw)uV!>E2Wt%$^Q)*XnwnyyrXN>24DDarYoCQl##(
zw{hsf6kk}Z=NtADtm$Ojwz;S4yL$R?u@2-7#)Xf_lVh93+3myujlY*SLSuIayzgYo
zo>|9|Aai!t`mGP6^t?MMIp@2K^8?pMP}D_uD<VEWI47l}L-lORQrt1YIhb#E+Rpj%
zTvusP2{*prV*#`U`j}SQ9QW%ZH@Kc$+Z(Fz7{J!1HUSRj@p18NhabC9C!EQbSXb7+
zt_nK#@pz@C0~bcP2Osnji6xlUcVjag^^3-d`+&`U*Vi<h_IA4mya)O70Yieg&T_4e
zhjSO<6C+-7<!SfOwacafE&BfU0uJl&2#@67AT@Mgw!1};-sUIa8gz#s-Z!+MKN+2l
zca6q)@0gDB4a4GhO2_*KX|_8)h@a|vw9JFsctPCgCxBktZ!>bQ=M@}%wr!+s-FUAa
zrOme^qhG5<dTVzZM(N|SY!;=>%VO)}Ptm4v=}v{0JQ%JYdtkG>>aM=5FWMS>f%Elb
z_<vx40$w^<)V<-i6?$K9%Xnu`s$VGh5i&b};HyJP|CyeHu_Y&QY~OoAHl9iDMSC`R
zCpx|17;`V0DpthS76W`=#l<Z18p!uOWD}oTT$_^B`kKfc>^p|{(6dauyWQ^Iur?G+
z$M(C7eJAF<dKZ=41D?nbozwj`RhDI6@8T9M9ubS?abqfvWgL5~T>hN7&B6AEP4K-c
z?u}B%(-r<VV9sIa<6Q&6<}jxBIiPcAyqwR*yi`fQ8jasEIiC=X$2XP6f3ERAP%eJc
zTl0MUVT^ZvseSofqzT~Ha`PCUcz04nEY}Js(@fA<x!5o89Pc5(;p<v=Cer$*eaK5s
zGsqW!s4I8To!*OwvC!JsWYEs+)q4klPq$NQI%%gZufsFvoEGb=kT#YVkmp~(+4hq<
z6`q6h39Qq_3QyNP%wrTjRN><lUZC*F3g4md=?bs$8R2)1!Xp(vU*X<0CH{K~{}TNs
z^Z%j3<JJ}UCkpQeKQrU6QFwjySA?%qcng$?@Qn&jRQL}He{sWQ|1Jp+b9V6?D)PS{
z{P+gjBj_ua^?QcJ@Nsa0Lw^4Rzo%IrD~S9rDZHA(Zz{Z=!f-A)`p+r6uEJXZURHUQ
zVA@v4E;r@b7W`g-JYQN)<k?;M&(!?BsPIN=FJDr4eT9!wcsSr?wb`nBhZ+}&p>L*4
zHSqiwWWtY=u~*?O6h2j9Y(ck{r`>9#*Zaf0=dStRp?&dU%ky0Dd<}VaX&x6V+^O)7
z75;(3_bWVdu*mqd!h0$F4~4H)`hP2YfX08S@KA+ULgASIx3wO2RrtpWPf_@{%S(Q<
z6y8zm>2QVd0k+fGLcr8vkLF)h_+o`mSNf9Xf1$$vT3OOxq415^XKtxp8|fI|o12b*
z2cCRmYCo0Xj|v~E@FNPJqVWGI{3C^5QTQ%}KUDY_g+H^U@IMOhvbGKDK52*Jz;9K^
zyBIp6kB?)(o~Sph&)w&_MZUL*wuG$<Y#hn?>X$Hgd<P*JI|dI~usP}hA;kS2@XY~^
z-w(e7cunvx98~MU610F-ubYhFL+V94g8vRmvo>k?97_SKn#D`RtHG=Iu#CdjSnktn
z>fG%Qg6CM!o1cK+5x9Lo;3treJdc8Xh$J2NX+O@yYb?eri5u_IcA)7dNh5KZOummM
z&z+b~%hz4<X<0yw&%!%HBRoifGBwhZ$xpJ@^kgaI?0p~PT8z-Ypy>8#I1eE11cb2O
zi2E9G!Fy4}9Ust9@5FrrA$(VfJkJE~oDA(5fWM1?jWD@o5j#%gLHtDsb|M>SSEoM!
z?lJ_c)9p~FHecTpZNl)wh7ZSAd&#_OFW9qwA-r#?LVGDq+Hb}bzXo_6JPW82_YE=D
zj+FP;z`cNAI-u<kcQXP$b*|$WIj%is18^T6JKJLXzYwr~KcvDB5rTM@D~M<QE+O$Z
zA<brxzoQMytXb}kN%*Id{J<}r8|;BHPD7f55KKnH%^*(eiMDBSgU_rb-EGw_{Z`s!
zx<zC@%%Q>C(%dTegW#)V6LZlf*Rv8Q(z=rx*zAPPjVJZQ{CE{N?bp&7-hHezx!hgC
zcS}{={a|_CA?cDBq&1$mOPqMp0-kpYejj}i*qs<*p2k!2bm{EOekN{WtyWypAWq7t
zk=b<OSvkm^<ITj$X^DyL?fiNw6X){NsH~j0`L0?qSu%Rl(=fBE!d&_e*6$xh2RK`T
zlh+4zdi`;~!}3<$&Mx83P*|?3PxdQ;eOTPY+WbD$4c<t_U7oy)Awn~~TH)@$ktVXJ
zzKvIk$jWm!<mHz@Ro9Zbim<Sh9cX!&)?1gAL;3HGvws~Vh}5;SJ87DU{b;%=lV%;_
z%5HXLc)XA4*kyFWBOx$u^iqrH=YzEdwso)Q9Y;d2GviVx`Dxr_e0}d?!m^`n%&6hx
zyxI~UooyqgSf+LF)Mm<W@ve?Caqg1{Ntno^<(zIW*_k|wpUDT)%5FE(9V*GnGg&|1
zkxN-!|0;IDx<q+UALVvmnm|XUU+CROn~pUtKR%>tr&h!->hxu0`kU}~@5pt!7`dN>
zHu<Q;@yiHwxgF%6;$dZcK<FCAKN05PrA*q6%IVsz6Cq!|1F^3PkG)&`W8Rc%Gqcct
z7U!4JHe|A?esZ#9>~r>lay_M&Csk(oT*5{9I?Km7(fzohI-Oa<754aAv(%tWtn;p7
zJ2oucH>asGv0XsdCAXHay3(>Z--2{TN#CwIJhaWd&5)K?(;Z5tv$+Z9qI3E`v@=L+
zc^Y4SUpB4S<5HS#HO{`A@il8{+0S%TIb8Ghuv)4wk+^BI4k#_@#}fyx4cgp5;$V{F
z#(JF!&P-Xl1oposi^Nal9+d0tu!-sR49r%t@qD1H4_3qe#%w`o%oOUGyk$gT>*Y&X
z^6rJynWe**Qq)hXKan^YQ6w^(AG^zgDqYyC$jAX!f)C5Eptz`Ho&OB<?AYygvZQr4
zrM=!q-&QE!^y<_OSlT4qJ|+j0GWktGPux>4V}CN8F57j<{D}R-O9+QZ&AK_$NX(6X
zm6<c$1o)N=?s33R1~~J<eFEInI;Ilk4lk;V2Xby~D&qY-v{LG49CgDv?S%;FC!uI~
zMdsiQ-D;nGoa@RHrSaeB3jg7l%W_`jW{G;{&irh}AaBl%4S!_={2m!R>xXmEb%77(
zl*Fwa!L1X)tq{Sj8Nsa{!7U%b4UXVeiQqN>t}OK;`{a;WaPHu!#|;4;{mOl?A=)y_
zHk3Gw$9$)h@9Y|0(kmMEX!;TSA(JNsv>OVKsdb{Yy^^=l&UT$zlBcJaZaKqSkm>xU
zSMgM)m(8bl=$y>u3d9cO@bohzDqTi=<gaqDU!>fg-bYDaoRlf)s>S{@>4NC69JuIh
zelNZuv-~%P-eAw%LuadZ>p$kPso=%V13iDX0e(y1t=)<3i#)>{;J0Xi-@E~SSOffs
z5RWt0R<3Ou;J0dk-=+b6>jwCc&#?{iwYw9j&rr?~AMy$Dp*$fzl!th$+g%`MM|B2{
z5Y${-`yKN95TRV(rw@l19364*BUs-;T@m+R1YdVr7UDk+@LxJyc(AX&4IyPmisN^s
zS^VvY%h?xjcL?6w7t66C`qottLLP?8@+N*&>5EggOZ;krPw{>O`Mrf;WoLfGy^9d$
zXSi&B#J`7-EerAQ3qF<K-M~G75b`!$mN)Sa3XfD-h<`}%Io|gJ-(6hj<|Zr)$IE9B
z!u$-E&5!tJ5wc|={yD+>{A>)n1p6RxU-JnLWWjbO<KcfmPkgsKPMP56C?51~kDLA4
zZLp_r0&liv=a*=Qj5{fa<98J-7x8uA!+I+L?#|#k0WZkl*zP7raPu-a=5clkCqCEn
zfUEOThhXgaZiMcV2;IlPh3%2DtN^=|$Kj<d(N@<-2+KygwK8<X4T<1}MsS;?a8i!3
zz}fyGbxQq>0WQp!vh0$<QKx%kaHQKUz|mj52KLNs58Tc&%tcx_t-KF@3e&)keX{z@
z_YYu8a{$tqy--fh6|YAKZJM~>B4lls_!|W8ZI`l53-Td+a0Z?YnERBoacM4Xv=6!#
z|7rS7ai%>KwA|a+9c5@~Zz6IZ#9}A~Z?yPtJ?Dbw2k`adQ%|>las*)R(;cMnkt*NX
zgJth~J;*l{A*?&%K1-bX94TuX(s5tsqUD5dr@|jAyg=c>gOmFl9)X{n=V9I9DmYnX
z;UM3eAEoqvz`jg+|CqTX`^Q$7b<o%4QaJDD?E`L+A>ABJ`jE@fw-o9XrDnSqd_U;B
zi@37KwLifv0Zs}1nbS!V=FO;8=R@9M_&}&sAGQtde&2SUUj8ub09@)eZ}cd>)4<0L
z@aGPrb{I1XZ@}&_YF;1fhzn2rqEg&G;MbAIY8zqfgl?>#I}W&l2_M`^ce3DBctk+f
z!}N^Y|1Y_4e@kyix$14^G~~G^<iqDEUcPTSIXXo(5M$j$hDr0VPU)&nf_=%oQuyAY
ztGa`|X|@hH@xOKTmwzYUi}0L#aB_9Nd%+L~4r*l{eWPDh>Lo+x-X*g*zT25P<c#+h
z!?WuF|56195vvvF?(pBNoQ1Nb(uY*gx1I0G$e^;iQ!Kdpp$eZXorej1j&Fk$w)V{M
z?-9RG-R;p)YdL=YcE;o!VU7m=7P=#_*M=dKyY)Q7DD{N90&(py&Nboz3z)DoRbKk2
z<{Do4=<N0a=;?E)#s5PaxBe-{g9kD(4$<=c*(hHJ!8w2SBR7EOF!1~(%4d3RQU=^=
z)aLFu6Tget2I*@hUVf@&#4NFhuOvpaR!(pCLveOvOUTlOc1hW8*YdumecJsBU#0NF
z3csuH%L=c&JloCSAvXek5y6)o_hIdzG95aJ&z$=TWar_PRj6Z@%?syISCnHR#=q?#
z*E*2P&W`;HeC1AG-hy0!ix18we_U7Aa%H4@6?A?+Bv&xIvaR%asms+NE61hRK({h*
zVLM=7WBILuxMumWyk~>QML~W%yKU)L^XY3<9{Vy;dA6tzdSN-&Qkiy#KCSMm74EZ@
z=9S<8<^$*R^vxGMu93P6hj$9>1RWixb;r9R2ycz@k@wLG+dUt=Cxr3yG@kd45azuj
z1LloG#ufJF&<}Zk1iRT4X}k88ym-$9dD%S^yn}==?;x@IZ&<E!rOxj<+4~^}$A3NO
zWlyA^i8eBzY_+OfF`}|<fV2~lb~w^nyU*wC?9JI=>M9ZC!Mj8zfd|ja4Jdzudrqbx
zJ?}Z8zBbf){t0y7tRIQ>MOYxvdVF_lIvNU|`yr1}t{;*9EniN3oW2^rYh-_<x4T9@
z);e8jMhiNR+-WlnyzEXJ-Z?|~=BE0~)<I%lymMs+(%W4S&nj&9hHQeevwwJA^?R$z
z{`BE3$ey`hi1+*)0$z`<D0RjAT?q4j7uFr`A0lk`5Al8;!gfCo@1Y=U_fYWu9KyUm
zhv|904q@J}GoUS_oz3q^?#uZA<vJW`SBESErj<H|5~Ypu&XWSt+MOrs4HMYzYTz9u
zl#AybC@1gNApD@hpQ=u~ca-?|6g~s6-Q5-&3me$5Ot-XsZHoHqL|zcV<<0w5nD@>&
z2xhz++A=bQnt1IP_n~nk7CzgkOBcX$3<vKrcx?gR<8<uF^Ga+_*~w2wsngomizx3x
z@L3Bs)|ijBuM`u#mPpIG73Ap#AD%z6vVpv%c?duF#9Z6g={De11+O;nvc7E~UVf^p
z@|=h<@@VkjT$lRVUhCpzlyg8EgVK4|o9T#mX7z%X-I?_~)*aOSc;!7t%igc>Se5^1
zg~w~&?;!71%Y*K)hI5@>Cx;==W02>m;JKRCH^-^h^l$fs&9vFWM&hNN<aHXnOygeR
znWHbi4Ez#I>u<Q=rJYeb$qPNBcj5~(9b?Cgk{5c$jAnlMmwMta`jq$r4d_c_cN)dF
zVoLIw4SvTve*DFoJNvpja^KbR4jZ|k+S|k19QnLZo&Q70-3vl|l4sVikq6-=p@Wv-
zy_m!B+zp<_!RnM3?M^TC6W2b0??(5PCSjI^Jn?kTSmc5A5?|sOEh#Fx;qLa<TpDSH
z!Mi+%?Kff8eiI90^y#5p_;wfyzKeTe2Tu`=7lrINjs@#LLFIS+PNJZ(e8LE_^x{hm
z9{sLEv^k3=jNWC3F_6YTgyZ_U6?mo5ps&CNjzi#D@p$~Ato_1zv}QdXDfh;-xmI<o
z>4@r>Tyo0=a6j11LTY$*sJ{bcM*U%{Qs3g?yGwJCm#ou|1@|zV066*9S-#UPVl5DU
zpy<|{el9EDw>p||`iY?)-K6&4qhQyZW1X;qw9}Cazc5GO<rN-0H(9gpg7)N&4f3IR
z%rR}f=<sq(PGZnLY@WI+)4=&dM`WqkZI8hFwHW(|y|tbGSljKP3f}?P`o>s46s(I}
z(dN0_-3JhEp4SULr=yJ1!H52-Ie^;`LSGDVM<ImYVG_51bivuZJpk`RT<{$xakCI?
zJunh)%~(E6Z{K0EjJ;S>b55}z`XbKl`CVpzkd|}%rS89R6Nz&(Xy1Db_??eDrl=l|
zQ}_tL<`;Pt^;#(O;NN^)5L5I1fQJm<uMyyxOH*v`?&zv`UP&6kn>~CD`MNrf@H)xj
zG#mRqf@}3cA#2x|{C4wOT%0FzYdu+?(m$cJDf>=QLw=iE$80B@M|2l^7ucBdAmsP~
zbO;w8#w*G1Gf~-ij{!bO?_E%;;k;$&A5qyB6zhc)k+q43Lw<a!C{5<u&gs;Zdn+lv
zCT+28@LGp?DyVB5w8zW9`wEm3pHsNDaVFpk5oGx&`=i8Nf)K8^tqd92czQFnUjCep
z7b3qbGEkK`oguy=>gy`xe>wQGduZ>g;am;73AY?^$7F22(5U{p+t8_CN^5n;xyLo&
ziGO~s(I_pQIBrF#ZRZNe@e3rJkF?a!x|pBQcR`=xQm?6S*#nPU_Y~)gcShHpS0ayV
z!E=V@aU)>*e~w#G^1L2)!9IEMRs!FmaCLKmf3NTb3SXx1g-U;$^1B^<49oCGh3``M
zE`|TD@Y!fboP&O-^4zcSd+QqhL4}W0_)Wl+|JO?YuEGW7w<_dd{E-R|1<dljtKSN2
zrtz4DJDd9(d>g+259?E{|JWRKY|GV3VUc=B{W<+c^_lgt$zWH&iIJW@d&6gY@ck3y
z`LD{igTkw5`F2+L5RK=1W~Bdt!jm<AhQj+Pe3zy_RN*sGz82f2j9V(DeNT5J_}q_t
zZT+%9`M#q0^eMasY?JleukgkSAFuEjg-=v?Hy!K00hs*lyX`9#wmJLF3Xcxz=~t{L
ze@0sR#Xo>9TThhd0pO`O)5|joQ!k8vS@~P}(BV0HE8l+=HhKBjQz-AI3Y)y66sEl7
zzgvcWZic>`q3_GkpPixqVTS(N416<SmiN0WO8$RP_%elWQ}`N%?^O5?fCuX1U?BJ!
z9zC4)Q-4O<*O1qxYJ<-L4t4Wig-thW;I2Z(n{GA)9Ll<p!Y1obg-zDaDok0a+cAK{
z{H80+{H*=X0M6{fwvU+hFr__D>#0*=vx^E~%4T-3L}9aouPFVuH2rrKK0V0$BH&_q
zU#_&4_b(N;yl(&;=6#34miM2P-tvAyVdic74UuveLce-Mwp9E-z|+faJ5=uMp0u}@
z8pKn#?;wuyAE#~n6NSwtKULW3c@R2b(px<*udvngP{6EbEALJUv%Ji2Z>6{V4p7+g
zJ5XWEZ<@lE-wcH<zfQnmeqU3V`EgGD$memF8-k4$#Jvyr;{X?#gUK*okefRA?G@+V
z9CzMBI?g*Vd8^2pNb-0Fc${r>dHxjr(DewGr_Fu74%u{$2mT9fX~T&sCKX*yKj(vn
zKB(=ronE2v2*9>4^V5V+sp4*?&<!n>y1u01_T{YnPeV4h+3VJdBJbP4;mJz8SgW3Y
zH*c3RKCETrc@o|~Wjb39WeWLFk1GS0<wN?<p+DIcA*+L{64@K-;HHcY?hAB4-d_aY
zwg~UPw!r(jfEVrY%^)xGJ_md+itv8B1>P%;NY~vEg;{sx{Uh+bD#Cjs&<$i4+XlQS
z_k<uX^8OfnS3+CO>U*~qcuxy>k@pcnUgSLoe2)lt6L%co6C=2jfKwl+D>LcNCta{6
z{vqHiiPJSP`P~Khz6kEGz=ixs_Z;bhGZ4o>UiJaj$DAL)+*4y8@D@TlJPFvda1IoX
zi_G``fPWPMXWH44oXn(up7eTmV@M|rPS)#|)?^{w#;}vk5W=z%w>d&s4&ug;F3`(-
zz+J=zdLgcY5T+&Wc+v%FPXhcc;)1l_0eoqIW8Ge$b-OKWl6~5D0AGY)z6kmg_<bY$
zI`#uj2L<*hc>JRR-&7%UqZaxUmiubt^P3<q;%)}~rvPX9U7X2}w9kX?m4KGG2LL}2
z;4J+mk@W9??vsF)=~n{XS_q~SOaFsN`VqkG7|=5PP{6|joTdK}aG}0PyE}0E1hm9W
z2RtXhS^CR?%cegVHho2gmhG;H;QCxxE^U@)+(}z!T*sm!J}D{mRtva671vc2@c|rY
zX!C4$=OA?A9#@HVD`ebXpQJaw?gQVxo(?t+Sw|Op3+^Ig+;}*@Q0*+>R2dur91d$m
z+;t1T1-}bm9w#G6ns$69hFeoWDBpxe<6%7Q{KUn}m`UH+Rpgyv(X{>L4xDHX%9lyo
zQ3YS>Cn6V~R%<W2FCZJIcSitCcNyNj{QPYX)!ibLxvB2(iBzC9aW-f>Vci{r5Vqa#
z0lqR*_v|CDLa=<S?n!$yLbJMOANdqQtnMwn@m<!sXC4nAG^+bZe5&pv@xJaOajCkG
z#QVCB#O3NfLgVW`66foly1NyjsqUK8J=5Qb5Y~MG_1+QGJ^KyfIuXJ?pSXU~1%3XP
z0iQrz(B~8PHH0uNao;9gkd|ZDD+poQmm%9vNvHhSmWcZhp_#pLEZYGgW^b0hsm@yH
zYnaDyghuujiBH*EB;MOwBraudk$7)!k+___MQFUeMdG}@wWPZy_Qv!>ptG>v#{s@N
zQ^&;Zi_ol&Ip_E?LadH0{r_6W%%h6XsE#A?sXC6t`#O%qrRq2m@9Q`cm#gCljj!WK
zoUh}Sbl0SgnZ6yt>e$UO0AGj@&M}DRy7X#<5YIW`O|S>9Isd40Le3>m$)peGgqRIr
z*3o=U$ox3}yEVgyc&-gMM+oI0o^!}wMCdsWd^m#VI&fZu59g9EM(8;oTooakFV}qM
zMfh+|`F?~C=Y^k*@ZtLI#}Pi9TaJv-bAEVm1kbhHAhg}AoSb9sm7(W&F%z_9gs|V{
zJYz9}v?X^#H?F0HXWX4=lkcZ$u!Um-d*HV}tOus;_i5X!eVDMZ{)y+jvyKlcyYPv~
z!g7yJ_;lK+gAOK**i(+q!(@J_FJf{|!~8g3JDYsrS8)v%_z{Z#Ch+ba5T1h7i#263
zs?#daa=vJ?=`<E!<w8Pf;cl*J@hZDaXfY>?q)oMLlaKR3Hd=UUFwNzCw@LXD{9(?A
za|`N-KC%~9ku{dhM-#ewgY?A)_>Knnz6SVe1N__u_{9zIJq_>`_@71RoC}Bc;L0dQ
zC%Y5SvFYk8&~kIr>e%Mm-v++uUL-6mNbXFRvxBw|h!Y69DI;fDA0CSPnW5+YS{bXB
z?!K<xGA>n1Rw#BK2iH*T2tt?GjM?WYK^)Gvx(}bY=)pl1d|@YRTeh!-2-e54&0P%m
zI^u%466bffBQ$Gsq`A%0ByEd$&g(;6YGV<0nYMKoXdg)UBx|os+aleQq|3A|;vYe1
zrEQsPjoOyQ$J&;~Y1&-dvT`JCL)umzFKz42Oxw!SN!!ZfrETT$(zfz=X<K=`w5>c|
z+EyMfZ7YwLww1?A+oImM)(GvPQQIPqzawPZ7V%FbWZM?~(QH3=wa|XJ4!s5;)_%zU
z!62?t`(a!84MNy{{ss7M<ZtbVeF4`vb%g93lYKPf<}=>y^XGjHk@(cyFcR<QhLO0`
z+%OXF=Z2BEl#N@tGP3)*VI)1P+4&l%qyHc@omV%R8#4Wy2%+BjR^VTt$58KFAASoV
zrgz4jh|oyyk@%F}Bk^AEk+_uJBk^AEk+_`RBQ##`kvOk+>S#BFWz{>=?}=b~=Q^5o
z@diS(v4J$Ndm0%VY>)6>)By%1JTuVczX#&{iSx3Tk%nvZu&-z~c0|^k(Rmr^Mj~X#
z4&t{$Xl3j$*&2-<79SfsEUwYmVdcn<9eKQr9rr<p;k+zQCu2t*FJng@FJng@FJng@
zFJng@FJng@FJng@FJng@FJlMw_Ho7@8jT&~u{}a|>>&ON2>G!?_BgggoQ(;wexGLm
zImSE)o%1L>b{PxB+I-9>1^-Y3{KF0Kk7V#{Q*38@AT(=Jq}komq}$YE;Mu56*}A;d
zHWgXpN81$Xj-fo6`55tagjU*=$=0Y%S$wQbSzMzwW#!1WsXSiV)Zd`PuubLZq)p}V
z(x&owX;XQ;w5dE^+EgAdZ7PqKHkHRqo66&*O;K<AvyOtbZ=*Iv9!n6iZHo9~5n^qM
zaXkpl+7#Cvzkt54N3ijmxM^6!&qWAvrvN@9g8LS5p>LRUKPFw^8)hCiGLHcF8PKdt
zI$iIKLB8B0+!(n09%1?eTf4iAvXamG<P-3I6!3Gz1%B-1-~(9+A&XlDxKMu5ZA`j=
z-|m3-CNAJd++>6>EpdmCE=aqGFhh`*xUV3DX^A_NbV1tZ0RMxyAT4n(A%tm(`+#&o
z+8xnf?~D+pC2j&jn3lK$NEf8t61v+q(4Xyrac!HMx9Q53^HQ#j+YrR&lFdENx9PKB
z`k){1YhqjbKLs1Xz9Y8;*|)okEX75G&c2H`T8e*#yv{|a6l=H^tx&;5H9Y%5H<3HD
z%yHrw@WQ>vnEwTf_yRwEa5t=Zf5Wp&k>`2H(=iNl#GGlImhbdb`FQDaHx7Mb6I0|A
z5$&cM^-0l>l-mCj1;d|INK{p1xdsmzhdOzl@>c42dB;9sKq=eG^YNu{6)!xx^9H1Q
z5p*&-iO+$!e*lL~*&^q8rt_CuC_n4gc-Gr-<7fK<l#O0I*&8<A7H4_TPs28S9rlHI
z#z~G7$-4-wqgRl(_<nJ08+U4U$;ZQfOlN#MjxQIEDb=dDGr;^lXG3Q=BV;3<-#h*{
z=o6*!6Lr4KmX!6imdYygiPy=i>ZZnEQgHKp_BU)BQxL-Tay#HZ6Q}Kz?d2}W$hB;<
z_QJLB)d;cnV(F9ew5Qq&*Yj_+P#(5D@_GiLS$la0yasA7%=6u)$n#myH)=1G=~0BF
ze66(?^JDn6RD<?H`zGysEyzo|qC8I`WbKOh_rW8PGi_JQ<AWCRpzY93?h9;(Z91}E
zkIwT*S3~etuWgw4g$M)9^H@g9D=CZk#`1WXi+u>b;an_FCv7s1m$_ITFLSXxUglzX
zyv)V&c$tgk@iG_7<7F<E$MYK^(aX^&Yj%D``d)<C{EBg9gl6+A)^Efw5UpR*or#dG
zU*f-k&`SMUUfKH1<E4H-2H&uL^K??bdA!tb9xwHq$4mX@@lwBeywq<VFZG+pOa12Y
zQoqEXfsn0V;?F{e)i2||j?k=rhh)Ajs`Xagow`f?{TyZnNQ%St@=g0D+hJV5clB?r
zEZ=@zg}*lij`y||+I6avY)usE)jn*X%6E{Y-3+weUUUrPn8Y<W*V&E6B=h~O4;tUU
z@-(qLMhTX3vy*$*3$ohUdl>U8l@{8XoMVpV71&~G{CXMv<`ziT%6yN!Mj^z;FZT1~
zwdGRq8Vz2J#wF&3GmAlg-`coD8R#?fdTTN+k@oW~$jiQo^3Z3N9hZpT3Oo}1rpG1b
zv2_c1aKC;M=(6@U1-Mr2ZC}vF?9JAo&Fqcq;39(8TN8VuT^Y}$-069dTUWPGZsYY8
z<lV@w$m@Wm;B_468`%}*?q%?MzOC66W!M+N>!*obk@mnA<fUCvo?{TQc18R&@JQrL
z+ZFSe-a;On?+nLWX9j3(Ud(*yTlf-!mB-E@lC~S6*_k2w7Jh(`-B;L0^J04AyR7FB
zna5cOIh#d)N1KVnr}ifz@qT|I5(jhX^=D8c@qT|I5|`Vbh|u``iAWr)*zF5Z_dNsY
zuF1X-(|;Yo)<k2VC-ddx&-OI-<=hG$Gc)$`C~z+zSiPFPkoH}KX7)l~&Jcu{y;yqV
zyR7!YJXS?$WG|8Ul)Xgay}d-@QuY#w_x2Kr%h^kW#@kCI&f5!h_d!r6QQbAM7pDIh
z!R&>7#c1eoR#5l!InbYWFhaKe*bW&t1)-7NBk?J{N8-KSBXKFcN8-KSBXK#sM`*m>
zBXM5u)X_MErZ(F|?@Yf7La6tn0ME|ooxaF#BE<C0xZ@BS={*vk(t9M{>pc>e(t9M{
z>pc>e(|d%*>pc?Z^-djC5tdc&OkYC?^?n`TLjt{XeoovC2+jJm=Meu6Lbh%=23q>2
za<*_bnt8m8(5Q|h@u@nF#QQpq#HH#u67TCc5|^vv2#v4fNSv?ZmUP#oZ87~*2w@$s
zi8=V(OdS)q9zwG^rcZufgjgM0`v0|#na8dOjp{fOpQ__XyszU(T&j*E@xG2Dak)B<
z(D*uz#Q8dINq0@^nCZWO5Y{n$-@9`xQ{S)M)iMwDuHRsm>$tYGqiqRx0=jU%Rdz~4
zAAA9{1FeJ2U*FaOt*y)3K^xmE@5tc?51EKNCZ-|S8DYK=z%iKfINrIS`@8DGPws*0
z1TTCrh8uw3C3n}uaJ|4AJ(Ig==98ve?<nK#-z<%l>nP9+qyzdVxcAcqT2`u@oz?XT
zzE;EQestK|RkH4kG3hHU(zCqu?~g)o=QV9t3BFd&QCQb|vaWTn%zVt%7G$^dJ)lkY
zM`W+zXyC$nGQPDI_);f#p^SCVwyG1-_qIq+ozQQ6cSI)~v&;{g>qpev!?~K#B=V)#
z?A!zEZ=tNls}Fv;*qYtq7twFWjlak~9cAf8NMsp!9d15i`rotbW%64b(<Ryu^<#d-
zX8JLjM5eTUxX1A27WG43XCpMy597~4Xrv#;pMsFc(wcslj{fVceuzJ|fqvK~1|e>B
z1nWPkYvR^JurZE(rO~cKT5W$uyCHCOyj_Ln%CA~+=bG?XA9(CLy8T4@MZW@AdI{GR
zxxG^6H3XrrLQ3iLh}#IEhKKcV7D?GkpGQ8&BMy6I)kURRCptdth2r%)y(8S+Ck2`l
zK!ZDi%H4h4*gWLLgUP)JDVpNqD9r?vfj+!-;BP@*cyH0=z&%p$hDD#z(^CS-k9Hvh
z9@xTbdcAIMn`yra83yW8+1HTvYc0~Ut)AEdE!!gbo&;L%{U%b=vgExF?g5{S_^j`k
z>Ao>Qx>FjYTLJoNmfxwFbXNXv0zZ(h*w@nUdKzex_R)O&A^qts(wolC0DZGEoQe2Q
zXKWkW0JkGT*p7(X6(QS>h~I^@K|3ODPlRkcB7QdnwhqoKX#d{=oNY&>+XEqNN5t)g
zkZnh_ZTb<9Kv)*rX4<pBccA*RarEpKXsLVh{WfTu>Hb{Ahq||P=QT)Y@dtx<j4x$m
zzUQ|fBkhm=+3$e1Rr@3T1ufE>tlw==7TVbsm<P0T4iub8;{B5cAUHeIK9slv5qkRC
zy2@_P3b$?|j%D~9@FR>~E(t(a){QA5JW2I(q1;)hm5%N!<MSE!9w+^aUqz5HH2&=w
zX^!?Zayo^15l_Exc+O5YV1=C?hO%$WB7V~7el6*~Prh~vMfc;0KMz6L2l|F4-<X+f
zjm}+KeC*t%#Wgy2Y2`@lME3ggc-afS5Op5z1?TBxFF22vz2H1v_JZ?x*$d9&WiL37
zm%ZRTUiO0Xc-afi<K^5X^+sQJXb(<DVhyQp%*f+ngzUaC@jpVy?;Fc}{`=6S>>D@!
zj*R;tM<Ce#vOB#78{(M(@;@hti=BtIwpaq4_2YJz<t5sFV|Q6H-EBzoZ>G~W%yu#o
z?Qy52Xp{8eeuU7hO_JtAPm{Ds;_15&>!4YiTn>JfsE?f|>~K3H=ZBmNl5Ty3Y?~y0
z4TM(Oq{-H(O<H`cO<G)|HfiO^w#htR+T^8~HkqfBHkrpuo6O^-P3G~^Ci8e{lX<+f
z$vj@#WF9YVGLM%wNxgADA+(1^ZIV3JL&&yC;x|NS)Fv-$p-nyt8UBe7Ym?-^8iK_&
zYLjeRuOTFDQua1>M%rd=g}(Xmo<`aV`+~@RKy*AJ-3+GBj7P*zMHtBT*?ugqtbOM3
zVxO01>@!a%_L;|vedh6EpLx94XC5#1na7KL=J8^mdA!(X9xvyIh(8D+YjecUM9ABm
z=yG4gHM1A`2e>zIG(t1mAWe^_No*ssXA!jx(w)lm8QUQKYY45_hUJyDjXYj#<0l#0
z$kT~!<ndw~dA!(09xt|$$BS*`@nRc!yx2w_FSe1#i)|2p3PRR4h(8S>W*dw<9-*0S
za7?y6iLhU6HcmbVp3!}q%s5H9w-K`TK>Vu+1K9)D2_{>kanj;r<D|tk8YitBSzF8F
z#nyh7v9&y%*jgShwwA|>t>y7zYk9obS{^U9mdA^&<?&)`dAy91)Z6b_Z!LT?L>_M;
zWbKmpcM)QC$+%Y#2C_@rM+xO<W|xsYnP@*nx_uC`c1ir62(8$q$=1j&Ek0(K7T3rw
ztsGgq%;Uu_ugTbDo=)sCj~Bbl<HauXc(KboUhFcD7rV^k#V+%BvCBMO?2>vL!g_1L
zF3DpGLe?&c-wz>XmyFvDp}Aek-Ne6w&Xc=OakajC0HWPh89u`)E>SnE?U7vz`f%^X
z@YiMV?DL{~VTC$ez{z`fzhVB8o!bqQZ`tT0lsz%ye|?6(;eXoze?tTOjScX>%iwKq
zYb@rb*}W~><M~S@&gA-ih9Ac#?tR<@e9|78`$9>7bBpwr?=6vhxu@`l7Wq(4(%;%5
zJ?CWfKi>v==bLm@7koH|wI*#LpwaKTl5fj0Jp6}n0T;J76!370tHHaUa7pr6wSn)@
zbaXpp&H5zCd$j@5-H}OW{O$xkY!g=ARR-Yq#|HfVl))Rn)d%4B=LYFk9w6Oa4brVN
zK)Smdq+4--bbraDv;CcWfOq?Bi3MPDTK1m&Jq(~he^qZU!|z$|FLw1TaNp;};(M$8
zec14+*%?UsjqgMHW_B9TMC~+)PozwY(AjA~)6h;ybLaqix*xJ;?TYCRX^@U~!uYuZ
z#LpQZe)a(Ivj&Kt*(Bb4->3uCZ(Ff_AspA}C)f{|FHhEY!96p&KhC~)I{Mw22r|C;
zYH;_~TKc4qP45lUpZOs4I?!GSbxB^AA;k8Exeq~J4=n|+%R%30ADMZ57a@^*;C*D1
zA$1m66qoxR)@UDYL0<YcC=dPh+5Kta9|4a<P94LrS7CWP+Cm=GFY9qOg3VLt(=C*{
zdw72_ZDBdgt?5H*W($uY{og&0v@KZrMAoz|(2w?bi?Wi}MhJ~;fxMnr3SL9OtC1}*
zuQd@8xm&XZ^9$PkrEJ9W^62!p(X1!Z{=EfxLqBoW7AWVF;E~9gwgu+#R10~~7Fdr@
zAvCfD`i|%yYGe!KVKj+6>H21SeYQn;$ZHlttiCO;*@$mchfIF}LL$q+b!a|C`X#fv
zCcozz=$dWCd?d~EV>F3OY5lOiUT9H2<aIhiBmFS`41`AdVf={*i7c(@hw12>%j$>t
z7n|tkImC0V-bg>@Kl(dpeES*T+bZLklp(E8`X63uQJ>`X9zsl?Y_H_?@>1}6AM}lM
z&%FMFkjOo-?o9@sxAyuGWk&lK%KNVt<fYA1p0^RQb?WrnpiWJmf47ha+lQ@*o7F$p
z<s%V%`39(e<C*9&UH|0wpBCg}e?neU5gOG$dA+_Ay!HouqxxrFdm$upw^sj@VLb$|
zpC<KB+BaH|m-SD1=*P;|Kk;vZM<Qo>d|@7MwU9^T-5z~zq!4+yhiBTvH*zm{+ghU+
z=a9LSpuC*J&PL$*6dvN{U8iG!=N|Rpehl+-5nQU$3r`Q8Z{Qsu1@V?~zDpbCnDllF
zWiZ-zTA;Oc>ARo}*AK?yy%u<|Kjd8RebDCg-{9;p=|5<Zp8Dec;Xe>E^Z2Iv;u!T|
z3-X%|J_2o42jubJ7I;tx%b{QTxWzIV{U<Hbn~a}kWF#Ms_k*@?UH7D4u0?vwcQEKf
z-7sH{qszC*$LLpRk)G$+I4=AR!L7lU@{A_au86z_TD#fUuu_Y(Y=bMeK+ArbGOP;P
z*x5AG>uQM4`j?n)^#<vT@7<t@@wM`NrUe;UCmc7|0Bx)7mh@}3NN=*P)u1e_WA@7<
z5SFEmnRe|K%1NED9k0^@EoCO(^%}@*^|n6Zv-QSw8#G8~d^ZJ6qk3cdAuY(rdgFMv
zA!u8zH_~s^BE88vv_V<ugF}xqXk*07o!=a5YkVUPN3q#U$lE@fVch#1XmC+iZ#%xu
zagWG3QhvfB>-HT$v-totY!Aah)65qa&_sQ4L3}dUW_)o0jhj5ge8!}?A0bwUX77J(
z5O21#1<DfkrIzl#2I(yRfdS(09U%Um0pkDCAf9t#+UAx6)ImTKt%D%GVI2fC4eNk3
z!x3V2U^@PMM8{0Gd4qIj^IHxOzr_IY!v=`oY=HRBHHhCz@55>IHgadFvIv*l;QNe~
zhHQ<p--pLqQJwCMgKYux4w5?*-cI3T@rDTLM*`;g)c@iw;R)Kd<L{yOE^v11zEmsl
z`hWKrCcUzpqpquIuj1S7QxJ<b&iY_qK^%@9<0Vb^YQP)(rnZc?ymvs}_FdetMb&c0
zux$$PMRo9z&0!<9-NvCtY>(-_`_N-pSG6*KdqHl?Jng;CQQ*_;9d&yr{?JL2X3n0s
zsJ({ib-BAVk8i|#h)%FtZ(k1-Nxh5#&%Z&B!&GlODGXJ*^ZNK1v@>w}o~tWZ%Wp!v
zjOH<of3N*O@OqMu?4n+5U9snI*YC-*>Kz4qlrjiw0eNqsTEUC#wGx=f4(Pm&j)ks3
zEE-;6H+z_iH^iR---%$&a@7_7jlz8jf2weY!mFu$9HH<rfUWPJ23dP+OR!F<i6Pj<
zm#7owF%$887krBqB+rV%mjLED*<AonL9lbO#<vcf?lIR(T_xOBNfq&W!-YQYMG1`?
zQn>V{z0e+*_o;|y-Vf+o+7~K(KVY*L%I`SS;aRGoS@E#E6+-q0r-Nn&0{fYA#jRv@
zhg-gxnuWN-5v&Z{Zy@d{O;haXz~>qGn5k3Vpk!Qu^!jbcno2)k=zaMvCS9Su*6a4y
zDN{jN37>w%e~o;C?*zUH_}c-FdbkAecF@CPs8_B<zYq9_2-e>Cex!X<OFPpu22^EK
zC#*LsLwi@XUUKbw@DS#GMuso*V;%1n!BhTYGI;W)z7Ik$-d0zcwv7udtM~x1r|PB>
zZXO|h%#V;3wMcs@Ep9LMxHoh<%U!5nXZM#Qo_4X}DtOPcQ5&k`Es;`(Yeq1N{&Hnr
zrMIKhX>I8W@K|nB^a(2^?|NH1w5iR!x^IWQJ;k1~rM-1+te22>f7C~|4M)=U)PuBF
zBHtB}cI0PTN?XV0Yd+tfA??aY`z!SCE#zBT9HhM(X;($sb<hX2kalr<koM<DyE@Xo
zr2Wb-l~*;wE7FJcR0CcgL3e9{*F(^|_2o_U-rbF~1z!86eZsZKdu^oO8aikp{X*(5
zO#f@7Ul-|*ZLRKH{#NhTBklS~dppwF{dEmxul06y;^|vlLW{2sJInJq!LKLfxB<L|
zfY&(H>F)ruejd|)_9lgoUs3wqkD)jA{Wq`LQn{VYh2{Pf={EuYT~-!;?<stQ!nYtl
z#uw10*yr4;`L6}o+V4t8<NI{Gsy2A9J3`lo*G%zIX0eN}*t+QkzH8j0$sDL&YoCX~
z5uN5dA)nWeqi*u28(`HA9)NtqA@A3rKO18o0uG-Nm3&U1wKD<_GmZm*eej{eu&n=4
zUhH29FE>(nzpC)M3e*0L-}=B+@H|ovMieU`ZPa8Lg7`wezJ46!HA;CMu4D543LgpB
z(jLgP>7;)CHO=w$Dsl3*DUY?$CMbWe!s`IGdD|kFuD#w~>~-(elJ3jEu^+uG$on|b
z6}s9XJKw!<Z<?E2U$eL_3|NR~d2PHu(Zv-x*tJ)CmS|n$TIcSP9}iDTXrPgW?n<O^
zygwiDl!xOx<-0;*j{h829zi`ljbP&?$7$kTLa?!LSX;HqHL20RK>A>uCjH9@Fa^hR
zF!ER(!FXDEt^`hPJu2&sDx1mr7llpM*OAAE%v;BH<9qJ_e4h^ZPzV1B^06|#2)-Sq
z-eNn}3B+v(nqdf*7xhBi2!xnk7`GMaRWIZ*8t??-R9^BRZZblQ2jli4eV|+N-421e
zwer3J*jWVIaJkZnXOo@(fVN|8=`GSE&D<#5H|or1it@CwZVfmrKWQdraP5G*5v)8+
zJ00+s0-VYC4sbG0b5kZa4aIdNl|IbTSqB^JAoH(R(EcsWhQM($S;cju{b*Bo<qw}^
zmT=j6&Dqs=!1K}|FXn$T;BN&uo68LaFVivSa>Scm!&l-atkf5I5Ko(~VN#6;$Xs5(
z1J64GzNGsp;A;b%<+VvBFVfxzy2k=q;+_HgQh>Acn`Y7z&w8h=Wo0Fvc4o4YmUTs&
z%F+@~dotQaw!w4H=)-(JygBP3upM^sTtZl%wFTo#i+fP1+6&9tVjS=sKlZ|SYh~Ld
zQa0AvsR-Hnxeax2Cqjs)t;|!tC&E_9mv(SrBz+z0=p!TfvEHtZ(6gUfF@k5^-yFfS
z{+^HE*)P47k(+YT1|EpeQ_hZvoWw84;AuBo0=GSawYzbO8v`8I*RlrWnPUzOs7f6E
zMTOBFu|&7Y^jw&%1<FXrI>pqzhzAGJm2k;`MKSt#`g)jOoVVPcfNB`j1sXXQ-`3tU
zcDx%~s=%@S7wTAZw8AyOW_#(qz<zgskF`VQy90vtf7Ic-(BB6U9kSm!ID@CHoTz!O
z>Bi~7L)d3^X6V=t-?$~_IiL+EQ{mWq65`M%O7p8VPO~~nU1jLm&OnMDPX$e&gF;ua
zGQW>%4Eo_L4c;m!_uzeZ(?>SGR+^93O_Mu}vhiVES$j<DR8&g4sYAYF5zKC^pFIt@
zX5;Yp5Fh#ou2z`iGV5dl;5`t+c51R*1H3vo(H+UL(s*2Q7s}~Ka~^`pN!c$3{Nn(}
ze7Q#d1#n@$#FO^Y2%hC%6u~pUZ)NbzlQ!`T0tSaZwuNx+%~yi)gvR`0J5Tc0%Eh*>
zQoYdSe0#LJ>%ot<Pd}0Q4Soll>KWZ<mF8rRXYi~Co*G$%dr-w+74uyN^LBN<&0`w3
zYm6g)-Z%Cr^0^p!Z>sa(+p&hEZw@X*H<tY#@qa`x{nGx4`zwO!GMwWv?jF(ya~b09
zMX))7+0x^{sgF<AWPBmSl}yHjj}cGV=pUn=R{Da#UsrfLg)M$;5YM_bIkRJ%$!KGn
z)zvtp@2J{T*{>st?wTAow;nu%doR0!j(uQvwWALmCp;n2drI3Cnms_nu@PRT`M82y
zCf-5Y-cxz7{G8x)l`E;XKN0cLKcpz!9E|cmfWUd3ttTcaKc_yOoBSVWUPTD&j<^pb
ztvSD(AI<7y3i!zI>}mq%0J`8au66Ky1?`;a-y+YTexCsRDRDYirS6G)3c+lI^C(OI
zHt=Q(ru%)6??Afep4L<?XCvK{=0MOi)BQB%k<x5XHwPg;rhC)%!J0nQ^*X?9f?zse
zJ0WgsqYZqPrt8^=Yo=?a-y9*-^(ufz5*O&2xYZG|x@P*}2&QY+3+D-kW@xQkbAT^6
z#m(>T>8<&`XfE*P!{l1BSgH0dz}0zvvngX6)~@J>rM<k5KwGuG{EL=Pe~)AY-CMtR
zSc`d?Zo<5X+X_M2g_QMhz@c7D2S;Y`hoLV$9&6oUBlqneHnP8C?2e<yx!+yJ?>KDa
z-n9}M^01MIwNK!!jUAIqu2UX4Y~;b*>+G$SNW0Uhu{#YLiDA6fF`>P4*vQ$FhK-yH
z-E2H)`5`L~Iu_i+@Bn(YH{US7Rf~N%+*`J@A$?>Y%JC35os0gOedIS3{s&<0XLB#;
zl%TABFQ^^vUhD+vR*>8CVf$<YZ3V&X%WU<Vz%?89FG74c?q8)a$9?i$1o#AmEZ=K@
zYsUAMfDg;}SB1H*x4z>+$Ahj8_xW0>lJR3R|I<KoE`sGx-1h)q9^lCT0(^JHa@?o$
zmG1z47&M^`G3_6KyDLab+|L33Ho(!=nEp}V!t}&5?@J<h>c14hQ~om}c;@-52%h?0
zlEJfl&jGg|$~P8cDCJ-|ZqLv)&}(jgfc!o}TH0Ta&KI5s{0c&-XX4&OuzrZTBJK^+
z={Ul(B(&B40%y9)+N$hYZtLs)6VNu>o3wHa8kM5Um4os;23}7E@`N&4AJc$e&fct#
zSswXXSvdYtUn>GfeSHr4vi|Tt8&JNU0^UPgRIXtLkN(i&9<jK7i{v>+Swo2bw}XZs
zE=7z@H}2J|oAYLZrg_!zb7?q*!BkQmn|kO~b75Lbiatv6d#F)bcgQu866Ii-H$j=%
zrp|}&oO)de@VW>#S0>G9rTLE1d=~IF0gaV;8_1w@Mn6F-g(Wtrk@xfg=EohS`oi9-
z^KC=;d0_!OZ#VgKvt=pEVYqL0MO5Ck+TU`HO89z(4}{EN{C2P@i?=hd(?Qdy!gv|1
ze0Ixw$3*WlTBPTkgSwrSp%;4^JcK$uG!kd)$vKE~?)pFz;d*p#gLtc(FCt#+CT&{*
zKdT-~bJ$X(u{lB}AFZp<2$KER4F4#tjd3=Ij)?2q<2ckOE_V)h8QgbLTo-%^Wnsa?
z^qsY8ccEJMK8$%RFT5*Q&IM$A2TA5i@4=p|&#-k>R=!vv%vO$289Ms-VXk{9KFG(k
zFLzJTRyIWN#*V!p%j;m2Gg}t*6nkB8&K}bR=imjEBh1`%!9HLN;&(%^af0P1ZXbkf
z`Hg;W(g*%+((j7^IlX?51l&l!oF9H3A<I8o=4SeBll%&;=$GwnBtod)aoVQYk0tof
z77A@R{ej~+{17kk&0BkEXZhS2_QaD=uB6j*gM{stdZS%-APt^P?<&DJ#IcFE`GRZ5
zbl&Y7k(T#qAB<q*G-)}1r%i@yXyUD|LVQ?HHfEaK3zkxD+R#xMxrytF$W2)$A%t>U
zU5E17I936z?l0(Tr*?H?!Clk{2TQj(Tjb`VWM8evr%g!3XEn&(6G`3HK*ME})et(1
zR0UZ(GI@GEPxPMd_0`tpS>)5k<)O|Nw<wRzTb6*{+KA0tuEH312*&WsR+n|gzZCuh
z;JpVJXLbL$yIgO_nX2>wl5h|CM##Dc_+p9b{Tg3|EQ{NFuv=AKX!}1Wf#4X(f~M@}
zP+zAWj_xbr=oGSZ-&*>4;z^7vxV=!U<Eof0=_xhcAF_GfH$Yde*Zb(QZR=y}>&3&n
zaJ|v1iuPpVPjIG3KAUjcOt?`V-tbDj+C~4L^(m)-XX<;(fQs{;(-Ggz`FK#~vnVeN
z2tE$y6WUn&j1X^KgRR}qW*T<boi3G|cU=J-=Uwx`n{D$Pz~4u(d6&s}2HL!|2RHd(
z_u<bQQ^qTi=6vv(7U+9C{Di9SN~xc&u#!K6F~C}O0nUKTvqWM2{{i{TK>e?&^8O6)
z^?|&mhwFw(`|{_@pl_?gJ3vo0_&82+b+aOz%iIY%=j$l8(IDDN3yO=%*ekR=wp*Jz
z!JHhk>&b2N_rWJdevJ7u(`p<%1I2|C>7kXk3?cfUyBQBWv4xJd`OMe&-Xn3`*wo16
zET>DS4k0G9y1kcay6Jdu+*<V+I6aFc^G~N~XBQ8G-#qAf7G$-#-)2~Q6(-esXO((`
zA|-pmk5C4QhdTDAjm+ky*p~irjo-J_>$I^S+H0uqzbENa@unANPvAdkL8*P=v{HAq
zw#3)Psc7#>-mWTqeLt^!Cs+5W*1&mER~bu}gW8UQSB5@IlkY{Pn_52<hhI8o=pi@X
zPLHNNBY%zG4+`@%#^ax!hY0Aj5aeMzX1Y!$ucKEqJ#;j=ue(P?4bs1=@u-7Tyqyn=
zwJV;pZLjshT#~a)Z-UQ4)bHY;e&12vkld-*o$?Fv{xFH3T<+{F)v&4!_c1;W;vqXU
ztva3s2{3Oo9a%lH0HUP>(Lm~cpFYE97G|ip0ltjGD@k2_%DhlZ?gn~1v288I+W2y#
zgZOG^C&$`=%-Q$~prMUFgL7@x&#fG$%d}6USv5_QYNwWeibnGf*_kdr6Y>h$uZ<&X
zhVh<HkR|#J&ug8a%x;m!9wO;i)&?)Oa&ES3$Kunji?~2O8#;XadXlz-uc2_c(#F;u
z@LnJBmZc@O^~NXYH!z-*@jghY-~<S6!ZzZd92<Za=437lxe>vo_I=%kh?o1PL<%ea
zM!-uVCn9o!xRB9wxiR89U~?>gq3W7H-Z0=J1IZkkW7%-faZEfK=j^P1-7?7&58foU
zn%8NvI=6g3kF>r##fmpuR}C_AaP#m@K({G^t#>%rB5pGT^alrGhp($NJ84H-15dt1
z`S8b|%C&RwcFxhC@3gbA=p=Z!w!Q?V@6?l?&_Bz*EqI=WHo<w5>Gcc1_2AME41uh5
zc_tV1oG(zm&mq{F%lhiitqohmWDX~K-Dgtr&5`&jMuQ$&%ACW2v^cD7>30N;`U$Ws
zktK-f^UigUUgm1S@(3m3xzXMQeHHX2W_x>ZToBrnJ0(q>%*9r5{wp^RoLDREgKfKs
zJ>~ku>9eK|dLye>bHmJ2eL_cz3Z~=vedUhe?DFnt1Lr}n{2*hg_(0G~7Z0II{Y-~m
zz5_ll;S7xRM+Z}%QpQPG9N-M~tX|&HGG%dcf7@XR&6G-C_pBv&Qlnces!qBV=jXo2
zDg6b$uL|<H2=d(r-?7!@mYaL|_UWomWas1K`qv5L_Q65Wz`j%I&;l?lW8>WSN!zC4
zF(PU_?YIUxIA=Z#`Zhf+N_4>C6}=JW1Kq`5mfvja%PE>E74E}#%;gYN+DDECCvE?@
z6s;(8DjF2|*_!q_wgagf<SA;OjgMbu;EZv(UYb~^i4lSNH91d8@nvLQ&Qnq}htx~8
z$#U98#F)-AoHi%0e!y3r*(knM*>UG_?#MB9cFQ`02K@we_jTA7;omEKHDJ@vX{mhE
zikVid`|}E;(2jUk|H#(P>i6O3wYTxJkjK@KV>i?t<yaoP2(vD&U2mV%{ZxOLcTx?<
zdeKSF!o&{ivC#g{PUP0<Tc9ZPWv2V{61oE?O)K{JmK4xj7}89gJi8jOGCmgvG_K!f
zjev5})X9F$d1;!ax0F&ReFY7^H446yKs%IPM*Hu}!1FiI)z;9J_1{+{`Aow%F*rfA
zcXjc^q#gY%7C$G6zdDJZ+1s^msWKC%5vtvu|1X00YEm1%-7N>-khX!D)kA{Q<*@l|
zUzi)K+TCQ`eQSk9JJ*mj6gO5~hkS2BSzpFktUYx7dwn9y#2!q~@kqxKG`t!3kOxJd
ztzR3#IHr|w*+a)v^Q1d_SAKT|{BDW!o9#Zv^JR5|IM+HUes?Ip#{+(Uiu0SbpxQsV
zw5ZfYpUUKNaek%B8LwyO%6pIUI}iNKM|gjn-yE1l6}B;d8WrZ*By*uz_>fNP1RbXo
z2fbYT!hNwdU4&N9&)Qrz7;oD#eZe+A7V~0Ag|_Nq-zGD3eR#HR5hm_MJ1v9Z+4&Kz
zFIg$+8%r?CS{IL?V=~j_8Vr0iAa5W8c`pWQOeh_hm-XR9AM-Kg=U|9=3tI_pGY#5s
zAS<R&Wtu?|oyH>e!`Xf_XOmzD0cvK4e@CA8!VZ6czK(YEEZ~J0dj>C;j6E*`$8Yv1
zRCZ#)H2*|A$ITOi@#>WzO?F^6y}TCC#0GZG(dL0>K7!3Ft&e&gIJE(&Jb$)-xiK;i
zw)67qD$IR#<FP()RxY%&)Szm8^^i18d{7PQW}`H{^sYLv+PFG2P19^(^?my$=`^W<
z)nwf?O%oqjA*<Q&W@-9V4_<czV&Zq&JfO`FLdh7kML?Gxgc4q#PtjxsA;@R;v2{q7
z9f$(DZ8LP)!N|sv?E<=RFtPZN(fB#O9e*K+mrC2Gui{4QQ9F(c=0KwZx|!ji64=R@
z6isSi@%zzZ1DaL_1ojbDw>u#%Y<f~(jh%?}kyGIJaQ(z=d_{o0k_kHQjBk)nqk)3?
zSRcMigR~6>1>fK9+8|xJ^H1isy9e}*I(=)`dj_=7!9-VPVeIR2Vw&c_VqNKGRD0-$
zH$6^D)9F|&%s8{A>)hJklr$~dpE!}&{yA9(@f_F*`^<eo%Rck`V6JmOkiJtbi@Ih%
zI2duOBUnF3+#BcvKMeXtuDN+0XBz0j{S9kRt6={jI8Ty0Ct~xEg915lEX;pJtj}hZ
zYju3{u&7w>;sQfYiBeAHPnq6E2=gbN{dggQXSr6)$ZNVkIFO?=o~y5?*`O_9aagD?
z;p$Mw;W|FWFb9d~eG%xW_upcCvo+o^K|YwI;mm6?fA})u0-fc~!i+)L4gpOEf|Yp~
zhUCn31pRa-6nb$p0qWoGFgUiwG?`lrc$I<PVIX-Iz-PCvVs~3dQC$-?y9!|ss~5^R
zH^`6sUS=1WGUn`p_Ie!B(yufY-)9au$H2Lql77(3v|mNqRW^hFV6|lI4d*a^4a8c5
z|HI^J<o^(=WMAP#@DJt!zFq@-UxkUFd#iIde<RK;B^xIxe5~~?ak=RjO!V1EZbyZ7
zV&jeTC38~c{E7?s$xv!PjD5J43sjOvb2)l?J5UazX(R`!tc{(V$^$WIF8U>W57r;<
zE)L`OjRv%|G1F^~2J%>Wb8##<?)<T|!JL}zSc>VtLp{ai-RqVv<si-5ZXPap)u2yv
zD$?K#RBx@i1b65qzK_#@ce7?(C&Wo@QtIS<$mz>KQy?Q(q&Jt^CxxXG+<)+5cQ_ZN
z^GdPp`~-4rj<)l5Fiuc5o45Kb1G~Bs@m6leyEhh44;(YjK-_l_Y#iaa6ykn>;QO!O
zn^wkMO#0wl3UNO~fa?4@nt5_}xVP4ayEl?tEzj>GJ~_W2zSNAIZvAm1=vdxsP+pe*
zFA84?nB$1aiiM9j)=_TDgL2xr48GIFZ&v<+(1CA{O0{ZV-K}7B<;8a=f;N92(x&7`
z9P@up^IxR$ys2;%F!TK#;5!gZpVn611}^B6a^D`WxTEx^T#qoHAqv}h;-4b@wGqA>
zfvy?fZ38~!J0Zx2`s4ZdU4gT@w(l06M_#W)^4ooY{HAB}D+KvbKlg*@6A`|}0r=Je
zJ}k$HK|bXB4tRbN@Fi{~(5!`Eb;0uTyQq_Z%a(Tpa61OHOg|Lx@BnA&zX4n}{XxLZ
z4QQEu55W5dI7@#jaM|>2z%2}DnZ6GA*Z^ngPXjJYPdv-IY6MSvycr=&Pkp@~!L!Vt
zjqsuUT^*sP-bO~~S@ww$Jnibm2p{TiW`v$PSQNq2jvkEgp&m;adRu3o0Xz=GbQSp&
zw=9ILkHyIEz6tf;hFiOhkMH<yuv~3nUP7v5ZN$C9V3Vg@!AB+dPO?M3sFKmjA7Dm5
zW@B<D9d5NMR|^?(8&l6l899Xjk&+ZJJSOAuIf!>>Il9~23pn9e9me6?Zd`przpeDm
z-*)NTUXnh&q@$C2KD7<|h_aPtdyMW312(FWO;4D|dE}#bn~AeMe;0V}1?>m_yz#L4
zknym2V7yMeAg=$s4*WPjU7-E)C4hg1fI-52ugLcG8peW;5DaH_ay{sp6*AcsP3AH;
zAdMBv<`OJ-i{HC+w_&7&i*ue<iy!az$M?8B82>KB`h<GA2l)_w1hDCex<;Lg3u4j?
zj6+gq_lr!k_MSA$&w>96+@u-3p_|{&k39V$JqPl=B=#%R(Q;TPCUz@#GE$$9AS8HM
z4cgp-cm0v(@g_7JlgWR1@NYIITfIC1UOLw4=UMJcQ(kqPzEm0Z&icI(^migy|8H&j
z$%K!a@$-8`o<d-KQOB<$p0;CS@h1v%ET+sX*Dn#8$;|wp0?j`VEPrQnfZq#n)~EA8
zT(*yX4RmiHWbrK5O%Xivdp3s`TNn)f-KB1S{*~oi893U~aI_I?Tb}_=bzE9pYVSk4
zPO7+8_v?fRUAQL=%B0_m-vMYhp~0<<?IifDwZE!)S=OU0c{1O;tZ#DbggjjZXP(@B
zAGH#$K?=ST-ykU?s~tzzcu3NH-|ySWBb!U!$^9CM4`@TCM`Mr3CcSbkq1}kI?2z;F
zd0O+GdA{1Ux<RQ)LQCiKXfa)j`{VBXYEJB6e|$8`b}sDaGq4}F_o0BtA|wWr?h|-l
z0^etQ810=ZsTKR(%0O0_^1Up1Y>8lfvf1TMzy*GnoKJ#ni)ptSIBm{n!#2&dJ0LV`
z)BI-3<mY;ez0U%Czr=%zne`gliO~L9%WCrtz5HDk9o+A9`|Am<oCOLwM^XfHgLvEG
zX;U+=WQ^Jw<#To$MuV5l9d;QYegfm=%yGz})iI6^3wI7yCG%t4Z1BAdcC-fUi2dPi
zfDb}Q>_}{b_^Ak4+c*TcX0~BAl%dPn!5HMtZ}JWWKkIXcsqaodAKi8ve}gC@;4`y6
zC|(b|Y!p5PEwFr3F8%Rb<RP&vo8UN(*NQkvfxgpZKHQbf&AZ&Rt~|fkhV#2txqi<%
zc2+XD6T!7*$<L|XjdP2^`{&U6IPAgNTtdzPcj6;oo^Vd)jUPcTm^bohI(t=oE?sx?
zk+YNshD%p>O8}pa5Z0a9*V(}1+u<(k4Pze@4nf{dhdgXt{x;Lq@oirn?;fB>#>`k%
zl*n-|XjH46@HpcUuf%?Nw+GVeq4XrJ>GC|Jr4qG8agP+&CMD<PjP88UwPH^hx|}_k
zPA?Fd^+-SG^<rn=1>W14-C64mP3+5bbCHwD*+F#9auwpkIm=B7oBx3Iax#Lo9rl;s
z1AI9`I6t`>@NWVf=Lxp}CU5&j_-4SjA(-s+8L-_l?JpwuBY-PL@XY^`4Bl+TpGPlr
zw{fwC1FwrYKeP6BC(@<og4{-jryqt>MBm)j$3wlzo>oZj)=zD?Jf@OM5PXD`%wPT#
z<mJ+qFk#GQ6{MsO&EA~j8>+=hA`kV%xETnXLfBg#Ev^&X+HYQ=-r0)+x|XbSR(_{>
zKicvUIu?idXGNtRLphQ+P~@#!lh0)5y|Y#?_fQvdE?$m(^WgiKB>urz{G2g<kNuHE
zm%8ODduJ1ae&DeNG~6q*_V74p^h_nyC{wt?0-nNOsy-2?ifcV`b+YRd{|&y6LytE=
zkF@>Q6$Z+e;msy_GtG)SrFpEX@UVc#YQU-dcKoDY4t6AE{7e%Xw%;cp$BPKoeoZ%P
zAzd?{;4s98eZ^>nt*>|sJU@x>-EjcElLJ1~!y!RFoFDRAvAMvp50-tk^j$LM@A#t9
zV6V~NC4*66VWry77Q0yP0~daWgVrCag<VrG%%>oD_YI)oiUH30`ZmoAZ{^@iG=CIG
z_Ge*lwinR>x<b9u@6HZ)7WD4P!9)1HS*P-7R;Kw%Gf<hx?<mk_%S3#a;C-2hs{}YJ
zljYT@Ow`BPNH-M0Y=^kb0gni9>?62;+yh+L*OPV%aMJ@?;>H5rJ-}J|8gOBH;+fZ$
z5j<`BDTI)owsaO~*)D&8HpKLlf4xY0$}m2Hr%k^b;d>2eL%uB6ewp;vu6_=@TerwZ
zb?j_#k5Rps{VB`ei}>RaOs5<Nh&vU*%46R+^R5`ieG>sZ-QEG=lM!rR#CV<rob9)m
zEWeO+VaJz}<s8Ic%yhwhn#5g!5R-**KS3~A2w#Q}%0k?a5KI=<gOxA4|3W<Fw*42<
zTK-vD;~Ua)U*bBXH(70tLHutsc(eQS*75xwzEH&NxbR@&TXg;EG4ZF~i1g;;$kA~{
zigs^2ufQSq6s>;LtxUb|%>13iSE|WArT<P*@z$R>z8twaaR0eWlJqsdqkJ^9AkOBJ
zzjw0x2=q^~c3gccu}vT2<^_X?ypKL&FyfHaAUmJh%38t66s+}cLB7K<fMFTn*9y)*
z+v#pur}xaY0nQz!Aeh~;-fb>|ddHLt^EBw!);za?Z)ay$UmfRQTa-`cK$6I>As+#s
ztsviZkk52X-UXqvS-!8=#~3GP*~OpkWH7SiEP<4f^0A1?TH|j>uj99*4E%?$s4V9~
z7MrjB8#t67UfvRJM{`NsX&GKf;;yA6<n%Il$nBuL55aV3w)h%w;kd5My!(><<fowN
z#9V!Q_=gFvJx<^efUWOX2e`CeP%m)6@iiTr=QWTw@y(G(s6V_=0E^XWcY1#5=8^nN
zN#8Gc95TKTl+WbaAmJHZ<7|caaNaUrVVk%72Rz>o__F_m(GOY`!E{M`<e0V#aADs<
z+9AMg7SIy6HQ-SJj_J9FxGQjBdg7Va@)11i^N$EwddmA|1kXH2MEFo|PiE*@$J0Pd
z+dl{PMmboHp_%mND?AAJtljbybYB;iG*~y`b8WF_F)lYQ?S?e_Aeau#9uEd?AbV^B
z4egQkM_KC%(>~+2hK7XAI4u5M-tD08La@A9Co=(mDZp8s^Z}REF=-Ep;8~_UBY5W5
znZet<bQkn%DVuj635v;E&yijG;agQ}6u$3S1pfAYFF(A;XER;1an=LX&=rn7?ko$|
zTKnQGa*WRU&?Vr9>(Jf2(E7eF1E=+jnyjSaz7mPEy2z)4AEmnk?Owj$h`oDL#<jW?
zZeQULIqUcv;QuAqBet%ZjydjIUOYTQ9a#tDa#KEMfY0IJ(*-__-`UVNGQebBDG<bs
zf7n;#w*laRtzswJ`O0$_z)i~R?wz;zyuL&yP2yd8>f%Dp?^w<M5`~ulrmb86_#y-j
z_s8H+3QqZ_&ZYeTaa}l!%J1vp8+LaSlkerq2cM(3a$TYDX$t==fSJz^0bhv#o8Wf@
zh0@WuFsIISyU1{{#&N^P?dEp#11Oo-o`Se<BG|l-`CkK=b+fPLcdf#c0W-g=0RJ2z
zTP~)(UTIDC8x%fNdEFGi<aHh3-yy_gXFk8wxR~r`BktP>q3pK;rtFsg?Fyf#`TsG1
zng7jz??A}r&$8UDw8rZmg^yHT_XjX}{R!~B2w7hCeN?o4)r)q%w%k?jU1HyAd>QlI
z6Htz|kXOt8Be%<}T|zLwdjK+h4ZP4?{22craN6JLcDUP-;*MY^&ox-T_)w0{@5Ku#
z+M>;a9?8)LJb6*N95VFZ96pw#PxDTaaQ-Z3yq?D%lk;;XkuHvV&7VZ#n&~duM|F0=
z365S>`>Dqv<2RwZUg*yHguf?pclH$2ouGZv(@OuPfc}{jeLI?bz1+D(z72ap=?@0I
z&6QqC(PL&=!F|j6&5w=GuYks9jvIL^yc+~{N8dcpy4jlI^%Pyv&+p$#;Y+Tcc?UR_
z^@os!_Wz#39e|DB2dQ+O9-rnn-=9<X2=uVX8aC7X-2D^cWLkogdhoa65Wbat@c6J?
zG)JAhLcd0{LW-s{MPp;+N~D3)7;i$9&?jOcpXg*2#MKv+J285@Z{)3BR|g(%lk`^M
zmJai!F3yJ!c1z54jt=%y)(Gfv2e#M6TEHtC=Swo(trO78J0i;sfocb>=jp}Q{s`tG
z&moANS8L)MmoYlFz6<TRzZak3s_kw7zLyV^c5h|ekTP_)@r{*K8BNBaL3}9VCcsOw
z<m~f&?8)HUc{~=;;f57=W2skMdL8Jzfml4V9dpfiFoHX2rQ2OBquI7!Z>vL2?g$f)
zS4d}Ph;T7Aa_z)oi|=74bY?G`vP_+D0iw*ZBa{@~>}9hYO>$P*#f8b;*eP|#IANXa
z^%3XD1DhL`@W<Byi4TEzM@wvA<HJ4QLK`j&!0bKQ%d)!MGU1sNDB!V`#pjFdeV^N8
zX&|%d#Kl24OHTQ0UdlL@yFJhaaSjDKvnN-Vj*taR(i2ZwVlBTBi7eiVY#iE-ak3`m
zw1c0j@Yy`>*7UfKXTiJ0vk%659-Q)$xQy4c+I!qtHn#OK$m>?Lo88ei3FBD@w>BMy
z?;&ig+bJ!N?l{SzZuY?@71K{peupW)-IU)5@EfE1!@H;Xb=Wtys966!QOI*|<;l6G
z$uud=L-riFcLnElsmoH!IjH?K{RK#G`rjWoD%a};W0bX_12xV)s?iaWB>nRA7HDQP
zq2YXWd&G}Iuy3fHuS{#0d#jB9LKrV`?C9+;UghNGzT-f*b4cqfN34as7(YIYHx3bA
zdw_1QkT%1M@q32xO?XWP-9900h8N?fgz*h{S=-=yVaZyZXI+yW`huJU^?Q7-&nyHR
zuLXX6meljX$hVM+?-B~MY3q07I}ASL#e)QVFhxkrR>JtME`Iymj%gCJNo?hz4O~9p
zp>ss{WQ)ksY|a*(dys^9g|Xc03hDiY-6+FT!{i<Y=TiVY4<Y4e0Njoc`oL!bZX=!l
z{sHfV0w%A+(N4&#0(c2&)c0<<6MzeOk?wfX1-$q^1$l8F*W_Y;<{LL&OlLUyKj;@f
z9k{IjgZMKuc<T$A+C(>Q+Q2KeoG03tdlvYlZOA!5Jmu2Y36chDkgLJ}Rg|6cT$b}}
zz~4g%^+?>05JEi?_e0VJdSv~Q*BtP&zKi$$ca|3y=3_?LgFa8jD#?fGv-<ocaG^e1
z(i^@x#Hnt#{vSYZM%n85slb+zG|(H%`aa4^KS@jNo%6q-o&6f=BlYU2ti4_j8g@a+
z1=?tq%4g~8-AzC_nz}vrhrs(|$bU#sSC0bctc%VeIaKWD9FI4Nd$LK~Gfm>2ZxZ)n
zB#!p^Ti|a)F#F`ZmAHEl%x-MI&*=Y5dT*yfe=l&*tzSF-6L8Qwo1)$R3i;oKVD@kI
z^Dp4i`bwsI>>o_7?A{yklqqZbuL5Uf;NF|Hq1S-NIWR0;Fof#3kckVTl6j)L%d>p}
zmMgqEP1Y+m|8sG;UyCf+CJn#QhR&}EXRz$ITRv|?2KZ0Vc@(%!?xGvSx$Az7-@8Z$
zKWRl$BxBY4DSjFq$l=pDZjI9=cMHqB{{zXdy&HCJbK(ybSMRC#_3VFv)AqM7j`6z>
z0eArm&&0GiU)8<=R)mE#x;Cn^7|vH$-Wm6?Z7zK)=bP&Xu#MTyFFj5C?~~+a-dQ-?
z>if?Pk)|-MSd;rdi?gi%Tpsup5v(21);~s>Rts?4?<Q_-;ArbcvnFY@Jy<=tvy?RE
zB5xy2){+~6R`oOuZ?Tp4#>#wlbxygXG|8=(tSt-$9Udv-k#bp%*7cYb>eOg9PI%!>
zY@1-zN}a)Y7tm<)NYk0#0y@_Or7{w^Kg+ztgJ!Q#PVt|iLna$nHcezoe|{ni{atlN
zzga@B6s{=JFT-JMw_4izAy4m%l}j^D*Brxgc}Nj80WLr6tN5Jo9j=Xe!;^HVZk!rM
z!|yEPM5ii;Hn<gNxS#iZ>;+l-9Rb{IT-sCToY39;mG~LAM;sc+f&S``eQ<l@f%uqn
z5*PKDsz8^Pe?waL=-dEwdi@yrnOr*{?-{b7oP-JO3`}TY!_v-2ArAct-B;ee=8PUR
zC=iX;*)aK(#jr2qIa<myqgL+5MC(9Y!IAVWmY(7UiT(VVX=lS_rJ|Y!eEd%7c#7gm
zZniK${ov?9KQ@hUiBll&&g7Y?8*5J!q$~%vmpihx;$@1^IGL;+W#V&X%EVhOd428%
z8M1X`yxXt=6sZqC=30EH@38(EuL4<h__VttUn}^2rNz>L2X%P`Jb2COYESAlsY_p1
zExvarElQuO#^L8hVZVO`d}s%t-$xeS_qaCzNkr=8J#4#MFMmf=t!rL?4a@CPtv-*}
zml*&jBH9SsasfQ2BOkc?oIj+f@M48K75+JVqon_;!V5M2WQ9-F_zM+2UE!-U@qbd7
zYcBG;N8xs*e@@{}h2PG^55@){<)u8<pRNF$jxTyEwLTK#UJ^`RhBNw=a`f(Dm<)B&
zfAOt3owvlFL4z(^9Pjb{NUgW8N8UK}k_Br5t|N~?`Homl^s_N!CA=$OTO;s2wt?iK
zZg&XMa@<}S@EQo=c+WGJV}Qeitf#HE(C0B0IQJkoPpNQtf_AV%f)5tn7(Fe*Ja~SY
z@?C)Xv^>^l9y&L$etjHpiSmS#FF)EGdCdh4c|8SQ&Dv1t6E}w+y;eJpQOVRtei-;2
z1%7*}tsSrMx1dYr_jSM=$HuH6@b?wIRN>zOraU8+{)tTbCjs+*&vTXk(+Xb-*mSWr
zaJ&(n?agrO0Oy>FuG~^D#KGZ-wl3#jUj&RgsmO<al6Di|Hb)5Sk7r3=653S#{R_BO
z>W}XLh4sfgwqYKb`ujI<1J&P}6O#I)ez#PZ`eWJ2drO2+AH;ngA=HQAOdl-cR^XM^
zhm7Id0FSA&E4%4#M26Pz+h_1rAL}B2c9Kv()-Z#Ij0ZdcAzVk<c(em};4K;4!H;Vw
z=;6lKDEwZ5yuO4qT?ke`HZLB9G@MMamoYmy33O)$w47%XcL9RUvk9L?8m$Y<qmseh
z0QgVD`7@)Un=zU%=G6M|r`Qqc?+SSAfxIsPd>Mk3IrsgPyHrD7IvcTl2yE-;Q%~X!
z7tE)8U9jH9W^_*d5<f13H~ZKMGK6*UD&W@xxwxjay4V>!Vs&A9-&M<RdbjzT;X}Pp
z2Wx?TeS~Gv0sY(TUpGY1c7i!}rNo^KdgIt0_y!l-+8p!`HcuCSs{c-`ueWn&?1c32
zaA6Pjh1=Z00q=`V=Bc|wP95{`4LUnzXdb>;KdvL5ecuTfC(Um9AR89(#n1+6U+yF*
z`Xbg1ZTJ`jyhULLy8L>#nB>XKkSDWF@;p)VJV^7To&6QT@+5!a9?9_+`}+~_+54~D
zXH|QM&!7Fmb_k91%QwtSzx-~2^|>BGBc3)kos^V|6RQ$DS1g|vj&u9LLry@xUqfI!
zwr^|0Z?YKwRfMcAzYLtbZQ%}IxN+_b)zg8n1M1{tz^5SuD);N5Zw(-u>GaV|KE$(4
z{}93K+0J59FY6+Nc>2Js?s*^-m0RiS>f-aN-Yyn{7ry>0;x;L_W@8>qb1Z^479Hn^
z??<q{p0s-)&xw(I%_d^`GVURSY`(-lhLFvd_y-ZfeA|#`DU&bdq25nL2zi)IoDF>9
z+nMHWlf!vGx3r~yhwb^7pkW(3Psg`&0Dlj``e9pRU7PTVwwt?@kF^`}`6+^xf$f*L
zOA%}=FggDMoXQ!sU6zw+uOeMwV61P$$MkM8Wc5z`H3*^3Ouj3Cx3+G$D}l3eP?qZe
zUyl&lp2>JM)4LaqlD6_!;HcxTXj{1l@O_TXOW^F2_<IpN7ItX;{e!^cEJJr&+rnZO
z7W6pI;p6^@eU>neePbk@JB837or`Ofj@LgnO2@c(IukSTsU~u|IPZ5!%I4moM^^DP
zJqwDFH26%bXF-EBE-sSBR1wQZRFT(TkE$V>#;GBnrmd@3!FM{*^0>H&Y&@=lB&b81
z10;H5TvG3e-tZn-xvN1wE-sSK!eRwCO2_kIT$0bju)W1%V9xU%mgiC0C2thyt9SN{
zNzRQt7UF~QJA6CJQR__I&GR_vF-L$et=hHocw8fyl;6D{<)e~3LOi&6n}5RPjR8Q@
zFwS)OE1X-zSsVAoKxnrPZxMxhy@aw@eLhKkMc$HwiE^Rt?!UG;S01kbNoaFB=hF@o
zX81~4RYoQ*ooBnt(|mqUQJw|;1z`O=(&@qq4E?zhz=j&g(%zrRPh@pWeOl|EpLTWQ
z=6B}so?Z1`@MJz0_`WelxMOPai816bzr{0-mwyx2IW1!ER_?E7zGLUfxW}G(PnJ`f
z2pi{=aO2zy$anB?`G$z&-X{ugfj*fq*N}|g3$XbqKTXRTd9_zR$bzks2mJ`-(Fq<L
zJ6=Tk*AQ$h<#<Kh2M9KHgnM+1d!6*UR^ob!xc3pbp0fG&pk2Ag0G|d=7gamqFYV*y
zx18(X6V)122LCngFTgo#+zU{0^E1mgy9Z}^+MJK`#AlJ;^O9$Dp2+y;5G>6e>Wf|u
zauo`$ZaEx>PclYymz)=ypy>xUPM@<AP5p-HWO<}je^NH@&@MFDz;|P1><c`>Ch&2w
zuGdFhUxT_f8CG0M8O-jC4{e6NtX05=n~U`68*Wv>xsNIKSABhg58_I=umVTw?TVMM
ztUQ=o<xC%sdEg?DFe=f#^<$Cuc>S7bHRR0(R>i%qwU7_&eg~C#b))f*T*vccnYo5!
znV*C12y@Lt_!Yp`=d1yK&c++O=V^LbOZ4KtG2tAH`ddeE{=O;Ru|xd&z|%NF$;?PO
z7LX^`^&4t>(?4+=3C`)?bQXEH*XwL3=$q+`JU2F)0d!_M*#z_h>4bbY6<NJbh}%qX
zDV-2M9Qfus5kHKclXf;~W6G9D>-=+pLS;T7`rb<Ntd!fUsqYuJZjz2NZJSAF^}3zl
zeHn-+{m2a7>c^kc#RsK0JHk_j-Zy*zI(}Vq;HY;$PN;(>{Tzq?#^BRoX<FAA+06-j
zxC6Fh>!dHZvbpmCj&De2G^3l)u>W=bY|!X8^s=0gy>;(f9gFyox9Mnn22Xy}(aufy
zF@D!fI@9g$8N7|-djPNclVj5Q5VTwlq^D+}mzK}x;JV6r)jG_(v+BB8q;+E|^4SZ0
z!&>MYEbn>QyzPSFROZRvhqD7Yn=7(vr`fpxA8Ftldfts>Hsj78x&;`%-tJrgcWSa<
z>&}XVeAsaCjkjc*%opWMG0qSe3zWt9yExY|fV<qX?c*GOObqa?gpV|vxr%GNFmG(4
zEi81pJ+Ou}dT%(WT;H}Q^fnbCoR1JU3n4ZiVcbEa59TAp%|_sSg#9Jq83=YJh<0N<
zvvUpOmp$)uB+^^{;@^=z$KS)F@9bJR<&3DCj|NATgou6pIhe~`hS2OjHCqq(^B#Eq
z4<Cp7b;6Zs^Yu~}-l%XlqWkreJBMNqJh~)F-MTn+?71k^yUp2yI6p>opxn@rTczlQ
zP(4+Ad&94>Y5Sds|9|YgWporv8?OCyH%`!vYl6GO#@*c=B9Me2K@!~E-QC^Y-642@
z;O?+-w{um`^vn?0@_xU*a~4_aUY)M4sxEoFs(K2sHj}o#^XyGa($x7)`vP<cbzs%{
z{a5Q<t;oYZrvRHyvyEjNRZb=1@>%%;?P<z$w9?wz%9`@p8l!erK9$j>Pb#ljXTChh
zCEI(fyaD<0klERPwP(Pyvuczxt%EAB(p=sjWKVM~8*HVy<m+gq5eKo}-N}*mV>_+9
zw8_y<E3ef~rDInl!Ox`*4k_|IC$%car@C#Q5wuHRn=DZIy8g#}-T!009{-Y0(L+)e
zxL5M-FOh8PsHz>kDA&fj6&9d6->){)I~H_2gW7iNfcbCA7nQen_;)ZDs@_t+sJHL`
zP;b9q)T`!1y>kH1pz$CguI9Rt;$f9O$d=xgNVOkASusI#>{Nci#HLGCp24aOaCjT_
zQyR8ksI`Twp+T!2Gmm$dU*@seFf?2nEIp$3PS|B?X=}?#Wyb~|`;W}=E-U|7>iH=@
zKScM#57&|3ve(9uzZ^dbrarGwL49t~+@0chft39hAD1;Gb+XvDU7~SowzmYgHMgNV
zHpn>r+ljoZH+oVX*s|p0<X^s@YV7kq&0a?7R?DWFLz=yhE<c%6!eN*H&2uvXqGZEA
zt$F{vH@<Z<K9gdjTicF7lOEN6!GZLpCGAr5srCz6_sWM>d->v!X6X#ehqn5ifxY`K
ziotPc(^YnvdN?4+JD6nvtM8`%MYh)R4Yqw>jF7q7t86`ApvK1axeBJcJYN+4xha^P
z<rmwZLle&Lmr>rb4VJ3sb(L`U@wa6tA^-8aB<433ZQm2KeNaq|oBH<G7{(Fz${a`a
zJu!8U`{mGQ%YS-jJ;$@v>RG3tKr<q0|L&9}YuBo0E|07}*uHyWMh2`CVGbQ=es9GV
zG;r9<aX4$~Y5R`LPiNn(ad*vQ?UndxE|v4oFNFNZ@iOf|wiBr`CKIXgIzXSMGd?ON
zq->k@-0uXIy=3iOIi&jj3tP<j!wNRJdXapS5;^_chxYqB_WHxPzXh!N)jJP!f7&HY
zwQCCB3{mymq@1#^)Hg&PlgFZeYfVg*J@$)q)sIcTNLTN_5-#1E$ET!wc2=K=Hx;4z
zeHP0`_{;IkY4f_|cf?r!r@1iS<&<YHc*k<)0#;^DZMMZL(riuYKxiv~7_JriA~I|4
z+WhgGnwH#t?<i-Flv&vcl2I<eBGg>=_k8$={CsFy9V)VlIOzD3qm24U+z-_{^g*~h
ztdr-=r{Z?D5C1!T$e;7&w=y|oku%Sa$1g1zsDAX-(_D$?TU5jd%~b%~abib%BC0$#
zI_9W0Vwkh#YSGkg>^S676!L{X4{gy&G@jYM8*IKoooq2>xEtxi+|l36pOrVJ%lldf
z<J}_r{-b}0d7##`8#nW#n5%!7oI1BbC+gc!ihp8pA0N2#luApe((HbW#m63`*(+Av
z_EWB0fPV`PZ>rxEw%H>8q|bi2hs!6x-!dK9!ex#{R^GFlHkP4{il1}X@0A=@GEUh#
zxkxkZIG6G^8K);m#j^~+>XT}}DwF#cWjJNn8KYIrcxUyU1j`1>OI}M}coebO%&Lw*
zNw=LfZ|&>Hes?8b)cZ2K<S#-!mVK=9n+mlZzcT96)#Y_;Ax8hJ{uLsR>TeR=w(rw=
zk5$f+-738Vd7B4xQoD*wJ)zP{l7`KwK1pKEscKJpVD<l3eJVnqtg$RbULTIQay%oD
zt>_RAo*iwo%9ZB1Yg-h3s`r+4Nyi{HzYlDUwW_n3d4Ag#RyRYcCbg($@<aC2Z`D)Y
zwI2MS+^i*8ZL7#LwH48NKc6D*z}6Z^+bY|i+mfAYV9Mw9!yjRJj4u*6*L`fhFyBn(
zm;oPZQ4h_w{FChcCEfZF#Ix@?tV$cgm_PO18Z~BIqy}lta_8!xR&{J+X*=(4`&O~_
z6B0IkaD}q9$j>u-2~!d|e9YQBGf((KSC&qxOIjNrzR%3J@~yP`wlwuE07p9-nrT6_
zgC!<AeXI60c1`EVj+zVAj;5rm<DzB(TQkhLP|v*V&+N6?o-&XBqfD|_?$lk~srN4R
z$I+d3buaZUs~HX>#%UY&wmr9+(!#ej8=mQ(CC~fvoKd#*+tdC_yXvE9CSB_Zym{Un
zSUj$5f_(P5Gtb%E<h<+m=G3lOn>w`zKkbU>zn3!uq0Y4gORn~(9rm>t`}gUbZ?bfq
zm3IJn(KqVDbg;a)3eKBrTDE;{w%kglM0K~tLYf#h8M-Zn?Y=(umYq0^x@;Z#@w-^o
z^WlH<T=^8%cLLS-;*<!sZx42i|47Q(btUGz%}cC6tn&ZUIVqb*r$U`SoReypl;2i^
zZmfOfYE4qz4}`ugIv7JcD%ig{60RW*-$|8WcpScyb#L+2IMtVc;I`iIiIp}%rJ<Bn
zn#J>zR2qk!%tYwS$~(m>@4~;+tnw~tGaTieF`8Ls*?f6yl{)3y95XM`7~2EKyXHCb
zJKD9tC9k4?t6huCyhsL@el1aHbU~$A{aR+0w<o%kUtyJZ>BB0kyi3|@M|o$z)|zEi
z^VOT2{aSD4HT$I=ING|=ncvZ_%`SN@eZn-#R?_YK)FrrWmmlg6_sn5yZU2Wd;hs6l
z?EHr^;hs6l?EZ%`;hs7AxtB6(cVYmi6N%J0>`ZlL5grR_77$=Pc9b!n*~_T0v3PpF
zs*6F#p~LKP2v!H*n%{tNJpb_vFcv)=w6_P--fWOnw|(8mYLEHYCU0#z(R@yuY!94t
zc$oUy2k|2UE_865G;HV&!S-~EW>2W}&ivXHeX`nfN~Q6MCu`rl)t)n?+v&i$johW&
zIi9N>pZq`x!|H6$d1tzV-yQpN*c@ZE#lAO3?aXn|scnx9Kb%0K)xK$JEkdn*sC_@A
zTlT$eA22ow`)Gpr*;loR#(HL!F$?|t%=TNG1OYk_WKf0ZlU2^Szec$z>S6e2s+j$e
zOF8>~7_;G4Icpr9ZLxL0dTzbbg&tVAw8fIGzPrr1TGVv5Q;o5jG;^`@$1>(xqvM(L
z_j%@FbJ}$ZA*V8dodWnl7j-_Ru6Kt36*Mei^B<m3x3v%2iY-1@@3ZN2%Y}gwo%?;2
z9Un%XE5Owzu*$!1mak@he%$=ZV=Xg;taO?+7Khbbx3MjVS!){BSiDko1O(a7V>`bu
z^@emS*_EzK#a3-LDLc@WH{PmxlnJS9I)=`w{~hU8vMWt|_#wY4;pCl9E@hOwwdVZu
z4`ujS6q|wNc>eW==T13dwdK2dPV<!g>)J-Gh<RSXOm=OfLAo>lk8O<TQpUB7k$))j
za~q@n@Z8x(i+}SozDgW5V|1<g%gtF(r_5-Efn~Fem0pRi>a&IF9F_f(-|$2HR;|~X
zWu10!a_Xy0@T@F#TWvDqtl?sQF7LG&k1lfCYPYkT75Y%}Oi$p(I}!lP7qslil&UZP
zAtslDe6BIM683u)le26r^*e^PVR0<(T8%K<kdrb6fz<}pE_d!Tx};fgx>BUM@}Ejq
zc~k!)UG**2FVfZf@`Ovb`dylId%tbAy|sB*@flXNqDhPA%ZATu9;bHZQ~gkOa5-T0
zEtlPgQ13DKp0JU^@rsUtd{CQ>W;XlX5yw(}RP|H^F59)uu~X^Q048uN8^74{Rv}G&
z1K6rtJ+s=Q^4otj8{g#bzcc4TpSJIG+ZtvPsPZAa=tFbpGowkLdV+G?R|i&K)%#Rh
zJ(Z6S&@{8Jo2#_CDxW=mWaU$7;n%X8ljb_#7Crls?%6uX*SD3E*e%)A!tqS4Mmkv0
zVZ*d^JhzjfOCD=(f2<=sTRClk){eTIwrijxjrY6AerH~b{GE2!4`r;!F8a4Eb=u{Q
z*=twX*!~yKtg#4R&Z^pa9=@#g+!}|VaCH+Q#_C|y?bK=I>-aDEEcs=A7mp9Yb%q%J
zEiT})XAqr?e6*Ew(BEL**$w(ru}X_BT<W))=$Q8*<oC4IVSnbFctwMqc-{wC^lQnl
zVXB-Z3)v;&_((hRqxfJt&()bx_3d(Xzrud6esfaQJA?a$z^YfJ4d;G>OPVUTihEU$
z_1jD<xnB!h>0ikLRd&=b(pCGr{vutye|ETZYd+SKuD(aC)-bIxbfj4$NI(ChoUp9}
zsrt-WvW<`O!-q3ZD>)Nm)$_OK(^;VA*e**+fkAEA*4{3_c`khuZ5>HH8<}rQUhgE$
zvHW0LCP1Rv1NEj*bgnn={vofqTwvRcV1Jp_U5loF%x|tks6B61HisVA`$N4y=d;Fj
zKlw0t*j}oBKFr(vHF@jV!CySHY^4yMnXyVjii+>8^fP8Uj)Ohjs>_yNeSqAzOEceg
z=6MoDU!mkzamcDJy7@e5cG^}EOUJLMcf{7S=>KB4JeI4X@~C<*+3Q{HQt#z(Wt11g
zFssuD4!huLxIC&}D^F3op1c+=kIfrGMXD1Lo}Jrv;1`$qatIsGR8Q4<mHDx2#~y?0
z;mX^$6WP8)YrTvywe<3haQSWRHuoR?R7Umv7Wvhf_Hya_ZPHY^HfX$nKwr-;>imG&
zV5j|jk36iAI8Q;?pQ}3W+v^<RQs;wkb>h1HROjQrsnhD)GoHK7wQZfk*#u{m&hhw{
zGA><n(&cmBW67)@$Q6r@UfA0Ai(zr*c}X5c2fxVlU*pJ195nV+)Z8&RptbEwpC+BY
zq3#vPkNYm;`u4{*xeTkbP4B|B$t9Cn?+2bM8c2+Mv-<jxwD2@wk(;G^zu4aGm;md!
zqJeMrI@LEGtUAAkt5dbZDr42D7yXg0tmhUDMCAFu(12CM!4v;dM$v$yj3t{Q^PXSP
zKond1T&LGj*6L?e@`R@WE0dKc+K=_P4uyl>qKB);HPf%!nGRabXO}zS`^@j^nO~50
zOqOe}P5o$#Vf|}4*G9O=@))$$8ZXrjYd%dmVST5^;&_*GvHqr<DGPp4&Kkcsl>3<u
zSmi^eTeK3M_kTGCcEM(~*W~eEy!SuXsm3Q<ohFa|qE2fL{|Gk*);<N3zZ~W46oko#
z-^FQVC(ZtIe#h#yqrgAsH`Ro>anP>r9J=V&?Fpy3T;?`@xPDo*Y4Z3_{c7$T*tP?a
zC99eCjg~CcTJ8OHxxa7kuk-)hUW=v@{sT=}Z7})&r?&t7ocucf-_Oaf^Z$Jxf1Us5
zKK_c<ly0-;#FR%r_3NiOQM*By5vNW1>vDhJ-e2ec`}VrhkZP}G+lHSji?>Y)01aCC
z5{H{pr>#v+>a)frnG3D<VDErcKE;15?`ktB`Dc|6FQ@*lo$mkfJ*oeuooWAL`3!$k
zKGT0JpY?CbXaAS-)_COnmweWI<oTQT<ol213xq4LcwDXV7b3lbFF*Di=*ce~@jDf*
zo#!Hz4p4cDn0b^2SDvyhx2xY$jOXUkJ=+<qIEE@$f^_@d0-o5m4_I>Jr{8O`0$cW#
zWy>l1x0r%`53ntsrMw*$rcGBBnpbw0@>O49BXV)X&C95EIo7<K@$|B!Tgj>)mK-c^
z_QO0+QOfocJ+;hr0QH-<*8E&l@o(a3)*6|W?y|PQr$(K1R{Wbf)!Ksf-b&=DU|-Ar
z;l-?b{Ks#R*;dlkMo#t1LbMM>_QRUG+DrVI@tMW=sPR&JiLHC99hIGJE$8|TRM-Aj
zBTr{`W2@iZaQ!Xyn$C2`_}4bm)LsqN3S7ppu4_8A#I@UQ_006(wm#&wXtDumo@xQX
zR*PeAie<MnGRxT8;|vQq?64-PytB9?sA!e<v^}>~;CQO`zS!(S+rA?6EUy_OVPA&r
zps6j+VgD5iUThvN<>O%NNwQ)bw)H%-tm8Pc(()=mV*UJuHTGU+Kh3<htsC}yia!5o
z?_Ibv;FKcXrdq>)uKdxF`lF{2smc6XHl0iRY<+X~B78GV9!th1RP~KCwO>!g!n~<7
z5LodstKVHn`>~q{6O80QORlidOU1)f`R2f~pVeL+YhKKC4<(9f)hd&VK{tPz(S=td
zm}_X^&px4}*<)sn=}hyiSnB{Ej!hu?_>Ipt-s<SC+E4UvV``T-rcWA>JAb~$wrV=I
z<G0O&?fb*J(f0U^X)?ycdS?&PJoyz^-f25+8DuMB$xE`z0QK#KX1;u>qPef1HycZ6
zPo{r}=c|2ce(eH$ebo=f*yUYc-jkSjBaXxxv;OA0%`tH~vrx~$j{|w$EN4EG)~)s^
z`90VyXFaj8SOR-{ij~OGrCGilzP|Z$=CI17;JrgBqxJ~F4E#bg=j`n~tDX(#nL6v@
z3lXp?;>e-e>GIq!paZ|D=6r0<n|eNy^0s(e_$)U2Lgg7n9;6+cesMd(zlbri<njs5
z^sv_I8_aKzdb20jk~QWW_;oPPHCpkv!D?RYXD8e9Q%$bl-k8k$?7^y>)*Q?uP0hhZ
ze0?QTm)P&S+3#1_?|a+t*Vyj|*zecb?}ys&H`wn-+3z>m?}P34TkZGb?f2X5_tWh6
zyX^N<?Du=@_q(~b#$z98_I@~YxT48JDxI&V;KgB-0_M{ybL59-&h?UGKcqW<V=6?Y
z+sBd09Pd7<(mOhN(Bc{MOsC>?^9OHj{*RT*YJ>Uh7oMw4=N28Ry{f0FGyI-xtIQeo
zJ{8RIQ>TUGe~Lq~lhlk%y2{XV)K`T0-f7t8JB)iZ{~SXw=l`<(zM*~muiEc@xVL`0
z@mJsRQ2cG$=XSYrgK{OQw+!`KeHo)@(;TBNKkShSQR%9W1W47m{E%O5u>DoKs>eq?
zaIS}$^#rvuKmTs=$S_qmn`kg996I_IZBv__TeNoWgE7lCSIXBc?r6gul{f#Nwt?hb
zibw9+$Hb!9`}TW9vsT+js`sh`_3E%2zgKIe?@FxFTlm|Ooo#=p-oqy6);{6*yLDTC
zWlLD)P5ut#Sc12o{X35~9dEYZ3@$joCvBz$1R({S@3-Y^XZ|pp>sYILoz?#MK9!EG
z>D|Hn9;NMlCcQ&o9Xgl{=NQ|^svqV!I{RU!@w>1Lt|Q+wmCw(XX34JSq&chP^OV6Y
z9BXSRJNr6>Nz$euw8q5M|4WDeXVv%GECZp~X77hGZ+T|v>|TtoRYvJ-KS~7I3#l<u
zvgP;R?-BSt0>4M#_XzyIIRbN{=@PNCA*b(aGQ!=EihTGhW=vh4&SqaxWlgT`(&SJs
zO`2BMBvk}MdiwIaQ0om@T}hXNlui7R-|O*WFIfUjGF3OE-8VzV_A;dKVMCJsWyroT
z^xYRtK5oa~DsM>p=pqMC>(czFF8AXYk{Aap4OsI~m!@2+g8E<ySOh}AF|Z>CZRC0$
zTmc9DG`Y<6`6gY~T+ro44o$j_7a6S?l0QI`KWi8gzo;&u(+nw4k>5>OX^7iyLw0hX
z=o7z3+=TNjL7K#GL;id0&7!TB3u^K`(2xdM4AIZh$4{ChkBYyXS(moGXh$c`>D?9C
za8i>`{WZB`81j6wCL10ZvS*DU>RS-kX;b8Ky67b+e^-}pae3zsU2-JS<u1=|gA~Vf
zSw`Nb%XIl`n=UE(Y4VWt`=He#&K&MD#C@SAm%i%a|4fra-&MObiI<$VfWvDzOBdOY
za_lwN#!;TMcI)}Q7_Pl~G8Xf7*|$r?Z5n%ZrW(?pXNOiX*5pq$L6<wUr#9EbUYaDC
zqe-m6nk=lv`J)z^xP8zic!|jIS-KQ>V#w&%<g3f~iMBB})L#=c1HPads0C_(sM$1W
z;6|Gm->Lz+G$id=4PCsrMmxf9J=Wv=+bPZgT+^k?LS1}F@3d5;L2N_PFb`iIV~d~G
z<OUmhj^*GRbni4N&_$PM*$nC8ugfV9-gjP?WQCxsIgA4|Rg3hl-*l;Z!;tl7pwEub
z$5l-x9yg@SL__KhF{IEYk<iwfj31=QBj$C(9!;X{FeD%C9Pe+)Na!`<W7__KbLIIo
zndz=eW5#CJ3Qe+h(PY|EO{T;&Bx5z^HK!p79_v!Ct}cak=`xx=H0+^E?jp2-J`b({
zy$xsI(I8!B@ywrRi@7cW(Ow!7ZLlH9Vr!CZp&=g7$DSvAD|LV_`;$StjCp8nk;SVu
zS$j^CKGztZEyR10LtoT=j5^+|Vjc$>(mIJ@()%s?5GT}-oX~2{Mk1Fl8uF|MXKxA{
za$<=t52``SC3Pu$K$DpLcvg_M($|zZbeVR^kdn}G;3iE<q~p5_%t@hbnv|KZ$(z}_
z^oqjxzJh)-7~-8ylL(CECE742t|t4RXtIYu(s<^3?jdNdtu7v=HK}=@?|O_OPFY_U
zb>^iM&U3bOhHN`#NWuy58?@NvHnbNDxsbw;9K5^D23=D7Ytk?w`$Mzn(&n}%Rc{+I
z__HSE66&H&FeEDUoS%MVhaR#sK8q^q(!Uk4n2v_rr%f?Z@Le>J7BmEP+Z$4gs~?yL
zrh&7dR3}Z2BxPRHYmyrp30rGObRW*~9TZvD!jM%nc_(B4-q(=gYsI|2hc}z7(qs<p
zu1mgoe`+#m3cOK@y=2AN>)KBjgZ5sd{#)QaI0nvvFz}6Xm$<6u<vMC|m+M1N?-_09
z8ZD*Br}sFe@P2&S(i$E#&gpWPIyGck<><PMD{DwP=p!b1<A6jU8OVBBmzKz+Ygp=^
zrozYZG<n_x9tqRL<CP&X$P*XT|6)i6t~Eei&;Se?t4lMk{-6@51`2i5r6$*@D|DHB
z*^tt1x<r3#$htea<a(n^K4jA2l8mjlCddDP_B!a&i2Q@#?<a3X9zo-aD<JQfcekyY
zob1YZfAmH3XS(@LPx7wofF8ZB$?X})d+wWq2-^(ljvV+4-ix%tkS&Yg6*o<W@oWN^
z4CaB+Ak|)7rf~I%p~>P9Lxv`T)}YyL<&YuBk7d^lc`V2*#<E5gLn1w*U&x*p@JaN$
zhMZew$i$p{Uk>_g4sSK#@Lf^H@7!bb7Hy6J4Sw0exN<%JiMrqFvb!I8Z<HYmkW>4M
zXtJ)QCQH#Z4-3%OmaNT$^7~y4;IXIFzu#aiX***T7x{6Hwl<x?9M#b!CuRCWb7x5l
z0~f$mF!?*WhwDuceTXjazVU4Y^iH<shRm4&&5$0EkCfLsXh@@~=(`QXa?@zCn>Ih>
z*|SHwgm66uPJ?8-4B5|IhVsAn2hDuf&^d<8NAHDoVlJOK-`&16G2r@|%pPY*OlU9(
zeNb|(1@FH_`4Jxssq<8mlIZc5+o7pM@Le)puAyUNmP9vkp9G`^9v~ICKi!aTW7#9R
z)sXbuXY7VdrOv4Q9}nyY3ID`?XoZgE|D>RN1x-pZ_d6$J546*zSRP#-F@KAb@GWoT
zPntfAA$s-J7IZTC58lvZ%@jjE<<%u`HpbT5kSvEZIa*VfT8!K6=em?Ep~(y8?KZsr
zGQS~9Gih>bBH#4JE-3w)dC3lcoYJKF5lvF3(qwviL)y+kcQ(+a!fEv8F!V10yv><(
zSz6GLH&qQ;bWoFa`-$(|(k0t8UA*QRav-W9A#R*;q)qS9MHO%AGWHnt($1=&HYfzY
zh1AyMud@73Blk6dCs>W_95;{eYQsYlnTHYI`AvxYx)k-|d+x~TvV9F169HO6_Egaf
znX+Ewh8VH~8POjeZvkD5p`ICF78nj@)Avj-_`dfDU8Zth-NTUCTvw0Mq%G`MgG15n
zyD~2OIO~v?xkLZ&zKmRsXGp7+tgoRrZlOccV(-12WJrl1#uC}tFFW#{dK#wXyB1S4
zxygL>r@s`J>G0Nw6q@)1!h?HsNeT}yB=0fci;jJR?jQa}lYPYv={VewKX~7)Hpt;l
z=;FQbX>RyyrzWQxGDf>~iM8C2BFKf>k)eC)xZhNl^)rx($h*DcL?W$2hOoJH6}DFZ
z?Pv<`zk<%jqMw7YAKst~Yj@YBTv_NUDK;a0ZPrASdRLGg@L-!=@Yr!pqCC)KEV^jp
zXLM8qc(AD<*)D1_e;zV(Iy&Sq^x&hz|HxnZ7a@koYix|hQ8h_%6uCnEb)hNGUW`dQ
zO&%XGWDvSII0T-l0$)Kxb*?j~2`GO|m%fb83HtMHl`g5E@nR1(c^kkUImZ4f={Lc3
za2s5xZphR3x(rK>JS2V=VTmT`xw?T3eUU@FBO!KkNp$aw{hIi~%bzy!oy_8z<b<w!
zo<V*>qnnU_RnMazj$`AE)}+}1zR&8b%Xf60vR7ZmhaXz&l8Abff;H}p5&S)uI;$|3
z-IFqB%*ovHBHQ8PEt|0+$X9}c%*ByUmHEFqXbikTmKeHRSfNX0_}dd%KYEQJvlbYV
ze1sw0c$Vz2CWDx>tC=+!7zcgihYqsWk#ez!JL8=$5@&E`>auo#Ci-GcT35s_Adgo7
zbVbm%O?3G1FnTAUCQp%R+bW`m;~*PmA}it98|bTMjA=8<v;d>Qedcl;*Oq@kON>)F
z`W@%EF7t0OPsnx;bVNzU{27}-i~8g9ptr8U>qjYb3b^et<WytyE^Thd*gsCA%SqBh
zfk$8LTVz62H}ubVUACgL&ws?8`wL$N`v1Bgo*0I1UyALEOzVhEH|GrY|21SX@A=3a
z7NRd<<#m}@+K||J(Y4U>VC3DF{P+Y>kOzU(i~Uj%TeNXe+LKE++cuu`0ULE00qw=#
zs!KQKDkpOEa~WNpp)W5r*Z55g_-VH$v#=9hy@AfKk8@+&?F<&lcS4iM<ZrgxkloYK
zd!y-3O61#YY%LZ@qSM}JAOd#WM|f-cOZ=&Pn(W97--coHVGqP(95cH!?$AwQ@}>c?
zKwRJsrht(k=N0rf*BL;`_E2ygJOIbQO>h@H1aaZpc%U|@Zok&&Iul$54}n`6Y#OkI
z_D(Fs7~jAyN2VoTfSrf`(U51xJwx&?HpGknn}Qa=7rZ~JOGU2L?f1jE4h5sZRX+MM
zlI!}vuw$lSi+2{8%YE?@*!NtIgQMUSI04Rro1h-!cpLjLab->3!8?sJ;;RK3a-C;)
zz-@2~%w^v5;|EN^$Bc$NO$aiT*JJ?v-mig3fe?5fyQ1D*d{mw#1?miuI%8A=)CVK_
zV2g466Pe=6^;k?~1=pcq3|Iihfp0C*mCc~7zo2#Qt3`lrxn2ej!BOz2uqF?<x}~Gu
z&DcW7*v)70T{;*tJenqxZ)?&4+vYLtZgfwVGDQtZkp^GQfQF%gzp&Q>zC&k}DRUQJ
z0v%KU9W-J)eCv<wpN0K}-w=5zc0Ydevv|l5-sMGlMda196Z|Iq6=<=k$eBM4xq!ZX
z4Lv0%&+C22au1QEY4Mvkqri3<QffG|R7Y-J)1)jqC>AzuXJm0X#$UT`$js*G(C*mf
zbu`HZ-`A;weUD6uh+aEAQ4|0B@EGsDoKX|csqkn-O_o4U`<dr-KG<-)w>GE&ZsuW)
zU<f|{21BA?tLK9E{7J6}8i5AjG;|*)iY_atue}%7mb#=wckNz=kA;34N1o458Ta(G
zryP95-1VJ_3`eJ2B%U&#=Le7>U6G3y7|Q|mh)W3lor~S_R+Dktls}38ii~=W{))B-
zTeUuO{f>4q{zI9Uf?=AppdWuQPG_DQvW$5cPQ68tx0AT`Dh;hBBBsLsr@(da5uK#I
zE8n;W`eF(4mNH&xu@kBwTac$c(FGw_;St85_(=^$B~}qtm!T=~_mIEg{T`*al;5Lt
zneuy-A7uGFDzEZ+lzvlw&j<98@@bULQ+|!|X=JfTG3LEf5<{k+G~~f6boUMBW`ZFN
zqr)$ku(uvTr`52rvl-$W16vcFa5*iysH!fW(?#yluh{94(`j^RhmBnMwjmW>Y0~30
zbT$(iiSJU{+mIoZbnz{wNiy;#2Y&z$-~(EK6vK&IL92P;#hF*oUs2KZt+9iS)Ay)`
zg!UxXPz$=djE%I3dGe+C!>~DS8ZrRAp8F88J})-ab>vVSL-rzb+Y0j&6Z-vvT&a)F
zScv@vk3~nmZ_9+e-_ww_ry=o0jAK*uChaJSjdYCb8E_qxtf$Lyt|!4oa1GoCiI^*Q
zkOp{wbRa3H0DM4QFbvEFlfg7_3|s{#z(bI!ICJ7b9l#AF1W7<ePzy}`Ok9O)7W(SP
z^>9p0>Yu00*hNKRQAZZyfR~U%=n=)UHGs<B7&HV47;`VK^B>{=alMZp*qm!D{A3@l
z>1$%say|RPFzbJbj2yxJk;sM&<N6SpK89;EbmJ(l@lxnAfotuf$U3gGmZ597W<*C%
z;u?4!eZ_SucpRq7Y_7+sV<y+U+qt4Q2UdhXY4hSdjDH#Y!|l`s-(D<(jf<VoGgy~C
z_pn)sfkf+!JroyNG@p5GCbFp^@fP@HMrUlwP))K_N4FKh_FDtrKfo>-%5R*bk4sQ?
zFZ?woBD9As+#A{)2fvO-Z+2zwYx3?omo(Y=0^5l9?ivF>klvuTAzm+ZNl@32uJ{V6
zXCwQw^W7|Lx0utAr$ewgpsCI1j9TQ2`&5&!{Ww!s9vd?g`ad%?x(;8;i#%<KeGVjl
zYiwxj|GA98Vi19`U&wV8?b^wB9!`MmfsBprj-OBZQSfLowhz}6;2gMUzn-!Gf0gTH
zkaInD(PjKB{&%~N4LcMYvI~AOwpOxK*mSfj4cAl9e*>;}kUy!g^NMzaFEwnk8Ki|E
zmuBk{VIgv;FTTl2>^SmzgM#RHf3Ch@?^Hu7ajgKVfhwRDr~&GMI-n6y@9_lLci``H
z{h-<EyBR?<>s0m4XRcJ8!@)Q(1xx}nz*I0B%mnkmB5)f#1ouG*I0jCGpm&Cx<QfXj
zf-rCaoCjCHC2#{=1F>S#SFX2!RhL_8WFtrkl7lqB1EdFOL1j=8R0mbS6fg<Q0CT`h
zumH>hbHO4o0-OM6K^Qm&qPh`l0B#^Ahz;U^xS(TlUE*;~01|;DAQ?yjQiHT01BeD<
zfpqr!rd+*1GvEvSK?P6+R0Fd?kz2^U;lwr9;qzzLB=bSyOP}H6^3Y%_{NH?r<oS*-
z{DnS`N7h~=#xYVCcjUeAB5c<`b=f<NSlLHp?g!`uS-Bs6j#L-ALoc-|tL!i6Z>TOs
zav5@*`eriDLq8c3Zv*jzY{YlaVT(?|OUSHfPgq-k=KQ;0r?k}M+jC@IU1ZTmVpuH<
zDH{{IXwCR8p|6$Td-QOOo7i_1G>L>PZ1o74PzxCt245n32B#%P(~q?QWPDVA;-p34
z<$KU=2k7@Hd64z1@areFLBH?QB{KH;uu;To&=rp!6TfJvOTiDiG@-Ad*yXQt!Y9);
zDUVJ$sp*oTDSR!+#&O8>!kR3<rpx$f=rGE9coEYYp-bn_#KRiF_ryZZG3FOR7W%OR
zndQ+8z9>VS23hiGEpiQ;vmJeF-<$Zy8sf`Gu=jW#!yDOEhi~YW!LIkf7Tc*wrP9PV
zA~V0FKMY3qViRp1j?XZkF{i$ySq$-i%Q!KvsX#yY{|a-H4PCYmUY=T+SQY&ZNJ^RS
z^d%Dh*G7>&A<)%5Vwce6^-|FO3iNJeO%@E(CGfB=kHLf!>>ESwJ)5A*I%Ia#gwW}3
z=#cm5?z%+5cUnZOYVu%By6nLAN(Y~>!pA}O3>t$B31d!I;>S{FEy~mbUOAvI^k#|g
zhI~PGr=5*WTL^mPT}=)`KRb!_Bi94baYG_QThLw$%2fm2pczp2qrpTl9n1y`!Ei7Z
zOa?Q-d~g(~SV|bzAm;Ei*E8S>hzgA+1yyUqgIv=AAJ81s0+DJHYvtMmj03$#p}V*)
z0;53~cmPg;^WY(f6$|+Rs)EMA57Y+r!9*}0i~*0~hXq_uf$Jaygn~ODeiZr@k@4gj
zJGCZf;jJ;V(T%xv*#aFO|A>4jsL4F|F(-E7kUE-FIBv+@w!DjHD%N>=0<yXq>i}_e
z=|Ef{Z6`yn%pq123B8HFj{*(#uF6`B598Ye|DYT6-W<Q)8=bTiUMm2d9HKn)7x$v_
zFIc--4Lzpgy`^~9ROYO!F0av{lcQtLC&FjO?yC}sHX&o`4uJm)qR%u<Hf7Kxe?4NX
zt<gJu=u181M|R`{^5OM$Vw+=${lTkuudo)Bgf+8V*o;^3_y5EWtjd~YQT!?RCMNpJ
z?G5q@KE9h+mpvY=qoVsx9ns~;J5AC(ATG9oxF9;`(*xubage;L@YS%v{m|KE&=c?Q
zS2s6h{pS;7LD{Lq9s=Oo8|@kIs>G8%K|9UiA8fJ+%;&fj$V}|WItdIpQ;PU^N==F!
zAq^R~pZ45_x8hGDzndYQTJW9(x+I~#U4`LG<||$Y<}4|8lOXr=WAAj+WkGFt*blkb
z3E%A;F+yygKh6->f)01)fOkCMu?Xl?#^p&iO^TsA>z%}wPKF#kNi4NB_U~xcm?qHA
zc$!qZjennsb)P)MUKy9~0gTZGY}@1L!A{ubZ&~|+r!LM$HzTv!qu&>GGo;5{^js=k
zHl~HA!dQDk?k(WH^#b@TIc=aFsh6XpkgpxbK@T;sU!Ncw9zxG<^y4^dJNc2rXNX@j
zXKlL@&rZdhe`MVTKA(TjkR{MS1={~8BJnZ${0w>HmX5wJHe~A`#CwXNTaYVm(TKCm
zW!+0d7BlwCkqbUY@GaeGcTV_;xsCD++iMqey#zhI2;1yAF~PH}-)80aM;V8AD|NYg
z8Nao$F6DFTQtBQwQe79n0`Sm7-ZK|D)l!q;<d1h=N0+na<_ljlkH-gSQaV2Lo)Lfj
z4Qt8Ykq6jQm+6~Y`<cEB8!ifR0gO4td|+=C$NsyS2-}>rhM)=f@)f&>YdXf+o2x&l
z0E+ZSW<p<;_`e#c0XFwRE~@|G0kwAD3jJH9Ej&<?cT6P)nwNM8&r=>Iei@8^%2-U`
z{&rGqR>tN%<8ijHjxt3C6c#Do8u`@)d2-B<RLFtjg;_%%fgKSY+XOvR4f>f&`Fc&^
zVXj%>k1-X{JzsTmKR^g+Vc;4#3pPMM1HahTr|P3u@<TtdqN1nLunyS<AC|H5)EOVr
zYVWn#Si`Za8UbYwRseymbaVZE2LCJja35orjQqEls}x)ZKOr_sdKvhz30HU0_Mxv+
zah(cpDEm;Y)2Ga7vpef>|7?=Yh795VG~`qJ6>igBmDeAr`l<nCpD7!(0eIDpH68MK
zc-w46Wm{b$UD<JJ4}glvE_%qCAN48Q@eVW`o&UYy8?^@_2s&4N?+;(Z;o5sOz7cd0
zpZ~+U+U#Q$vrNjp+P|RsQT~N3Hv4@O@x8jpcl2!+#`89Ozic(W8hkqGHaeVgDh{mT
z&C`)T{#S`Jpo=R}hbP$H6WZdsBC0NnyzzzL(}mFe><EUWj>8-z!k0nb^xsGPm3;o7
z%u?cLdx&cw7vEz4T~5L}XJz7}@Lc}ttlK{#MoC}t_~Q4s)5UumG2ZUXK?Yq$QvT3<
zWXMVQfqWjB;SKDG;_!*;^QlDmROC_nNT%&4PQw55fm(l8>+Wj(U9D#wC+!qC3)EUk
z7}qOy+~68F8a4~a03w%UjqCtx&G=*Sxlaf@fQk!L;aUTDf)?M<b@uzFT)k8p7y-tB
zabPhhGKDon<j7_Ie+bS3_5VE(6@Ewu5`(nB8`K0%!89-&%m9nQQE(ib1nbHZ<FTjR
z;~GC6bO}-c50DNd1NA}X82H#+tK09rx%z^+AToaXNUl@u_b0iY1?H7GE?nP`N%@H{
zZ`R}*=?}pJ5G_9b1MmRJL1j=2)CF}wLr@)z0HKWMsLHw|Pev?xt}bU8{};<>V{CjD
zo{t8bMna?Rx_rQ2d@zf3|4hhBXm4Xr_7cT~#>f)}G8RTZmd8%!|Er+rQ|L3EE-?~7
z=ivN%;)U+;1^=f3S<&<P@$c*Ke+w{XC;WxIH@*(Bz%{Jv=7uim<El3BOBYR=lV=WS
zguRg~moBR(>+(lA^x{`!;WO+3=)F~OZ0u#kkMKp?55^vS3-4m1&ZAt!eemc@e3laM
zdXUIhbnztoo3GR#d<^-8o{trU*vEX@7sHUF*v;u%V4orT$6z--D5*&=?B7hZb0uv!
zge<Od!;tS)h*9ojjSSh7hPfEG0Xf`|bt`nu<Zti~?Yox`y;cc1+yow-NjuS{n}!mb
zNzA%iUG~VlglCEpf5IkK^!YFiwn|oH9J*!rQP$03uwK*$`}{6zsvmSYu$(nj#yEX9
z?BeCn(Q{;>hWtYB)~JiGgpP{QK$k<$iB}_!n=~d~CCDnu6y9h^W8Rl8Hn9)dY79dT
zR6<_B|M6<#dj&Jjg|RhOq5Jj|7lWo!z{}l`<!dKtk`FsAD&w?}F-=LmJHteZU(jVx
z1oDqI<THL(`ug~J2k`^eXwtEYF7>f%qQGmhMiFm+kKMyNTNh+qs~|MC1A51H%bSh3
ztG_O9>aoXWFFXXTm9LH*C;zj1=oRGR%Wu$kXLycxzrs(s|4?V~g|)JE)X%tn^&(!8
z65C`map#ltcMfrvK*p86c4vSJwqZX{MB<Kf*n8#!j|uke8P>2uDFaPRjg0+Pf_1Y{
zLpEh0R*bA|TO2<NJFCoC_U`cB%xPJ}!N%RX1p0#qY9Y7FVrNIqLtODHdSNMRIoKhU
zn7>m2=)o!Q&oty|2K-(0wGX!5-CFcJfc*mZSwl;q$%=8rEIoDU#8_{xL=3tD`xu6y
zgDxQ})-g{t(Fx?aH<$X*u>t6vj0^BZx5EE5@Sl@tQkb!bTmTtR8`{l_{=}XPq@Ph3
zvsMSt6Vq6eAH=?gX2>(<aXCJ;;)gK$<W>cHzZ!E3AG~>k-`|i}(*;cqT%&#HxdP4L
zYaiCG^XL*AJ7YTb?cNxggkYl=xP#nB_J>B*Bzq9NxQVsk0lH)vL|pwX@l|hZPH*)7
z9CS?^<k4Q_Hn!Sr-aB#+w#{?)y%oa7g~qee=0uFcbmnauvS`Cg)+=urtiz(8y5c`T
z-=&Jsx81}y2}<R=i7e|*{2>eW6}H-wOYkxFXPa`^z@Efrq0Ke)$-6PW><0Fp#f0|p
znHD1J2DD=BzcccQxqOoro1M5?efVG{{dmN@lznH&i?xgcJo#xMehT)IbmF}_>sU9~
zvxE(s51I1fy&>5d)3~j94$V$TgKS>O9*UOC%b%>9lxEHcu&0Q5+S!rVSuf`B4SZZ0
zTA}}e@W0QW@C#QCYe*URC+Tfu0)BsE?44G<S*uD!U(orj80(tQ+}!=FDNbfh0exJx
zGWDWI4otyzp?va8#AKJSR=%2b8|>BlEAeG>vZj&|8NnENE<kQqKp!oErnaF2kyEY0
z3_17$dv*wVAet`ssK*2Ph@6i#joZx2dG<WQA2GKOYy4oyN_gUWdEyM!Si{?aT=Ozy
z-WO~g*fDiNk?)1kYuFwWyRi>64r@K|X15B46vLnF9L<n^_yCWfqcpKuUqN=4nnxOQ
z)L<HBD&ts*I=)f%I`&vp<YwXChOA(Y24nZesKB1h@0uJt$XZ8H*6F!_5(=F{7o+Pi
z&b%vRkRdGx>hcMC4Z`N@MVz1vyx@a<oAVuZ&JkkE*lf?C>6Xn{(}o`R;_ue>#s93z
z-WK@qw1He$1T8S0t+(N)Aa~uEC$)Dq5%!_S9_)nI_+ij&q)%#n7Ci+Y6*XA1FQv;W
zWNbZX+3z^?5(yumJoYtuEN@dyf{>H3o1%A;AfN6N<6w^Zw1RiG5Q8|R$=pzE;u84c
zed!~1*8|34HS>EfIkuf2a=#WnT{+rIpN=w5c^J1YWAQ7_p}(N_)wH3)B53C>@uvpN
zO=kS_%bFC2*Rqv@cHyr=y^-@P*f+TY-SvQV$h_G5&yf?u(dE!w<XO<bQ)GHc5ijO7
zEq!ZuoN+CKT>@{UV9aLqV=rwtO&Tr7CWf~@<6BIC$5%E%-XaUn;@b@-wv~apI}C*{
z1|q*#Y2sH9zQK;%jLaFt9L#-&3`b6XC;)wIKxSOl<*g_2{fh8ga{TcD_~(paDg2b%
z$j=oyU`5(~emwg>ud(OmiY|XHWPO&g>of(v%K?3yz~09GT7$f4*8rWa8#0ajwX3iW
zc^jV&eYB$-`j2^QwuJo|HHk5tCU(hqbnL|VB*Bh)s7Vg&lyUe0TXV3djq&{Yn!God
z^IW>zgr@Vs&wT_RbRT;qu{RR6&}1d!c`G*i-r%#NDX|O2A*YZF$wsr5NMB!XXKghf
zbd{d9yy5u&Cy0MP#V?-0-l2xbW7d~cT=7&p;^E1;NB%5;Ck8P8ExPOSYBsb9Ef+*a
z#4@lMJ`<~Kh8&oPTv@?5WJgY3C&twWIfyPDg#Mb5#E?wLjwA5WW$c)qS+UtW60=-D
zoCz5^2U|gZjl9i^KghUgRp1|g=p9)&jCWu0M=!y*FCSya!4Ii>AP<lQH9n#Pk&`LP
zAXkw2-{H9njM@0y=uzgq5VTzUGUbBUA3Keh><MT!jJ<uaiO1bwAA3VhMpA!-JFFod
zKyLYB|3C}74kEYUfz#mAM);h$S$~o^QF&c1A}=OIfKKA0m!QEr&`dDGXFoBL%h|B+
zsV@~Yu_-ooQax-o<nz^|#DI_qF)L&5G9KRVblFgvxX5F8W*vM?A67I*zro|zF0xN4
z8#?hUz7z8CaV$+Vf-~c(w^erZFnPbO!zb;BowNaai}Bu>6Fv3_KAVZ(vljaUx{O^4
z{y^S*oXI-PCrx6*hn1#kk^vf#mz1f?yS5`wDiWKa?!vS`ls>&GN~{eU{C0y_HS;q9
zyKx)#kJ?95kk~|&iRdiGp)52wCIRs^<|-2N@a?Q^jj12>6R8QZd@FH`B*ap&ZJ*PZ
z^C|F6nWHGg%d&^EFXt{i{!EvI1sMbE6u<8H#Fd!)Iqa>5>Aiiim+1SVYs4gOV-GYz
zmLqHKW4}B&rbz;Ls3P*$BNe<g3cql?E*&!y*SQYOJ=A3g^jk0hyAL~eU|Qr;Th`u^
z67#;#I@xU2W7{DAR=_h)u<aPvWR2KkitI>$eG`VP8rTz?0=0NK1m7_Sda*SASWo^(
zzeR%HX0^qxKhL^gFn+{rY{kUT4>rInWb_gA=|<W-U@>|DeW52q{vof2&PV<rAF@N+
zxi&$M@!8vqAJHHKdyhu2hJF#cI7(a)`e?v-`8UM|c#pkFA8JnL97Pq@o3S|uw`bho
z@2iYSodfv7&{^9O*cm6#X<3k^(EHi1$T#S5Gxhy(ADsxj&t^R5G^Njtkh!#bUTxMQ
zu%ox<LFX*fqz3JYm7aHXh5qy6_kJf<2M-LR{wIv@I%xWGO!B%D8}osGaueq*#JYng
zG6&nfEc9G(6f}<9dt8zj+H7cBC=ZWs$HuRVZIl&Rldv>>fo6x^LZ36&D_*f@jWP9@
zYOsG9-p<b21Gdy@^j3#P$kA5FI>y6;zLZ}}Tp}aursxtq5wXV<*l5Uv4nv@Y)7Z%x
z_QG6){eG;Y#$b;geATKTatvM9e1;)wu%Bw6zdqw*l%y>Wu)#k@#ZG#Ft$QB1Pu`@=
z{l5CxmBa&!Mq;mE5B7SFz_#>34nYrRzhHM@uVwb+`4;?g<Y^@OSgr`;hir)h{s8g8
z`k9P1vL^=ec?`54mv((*ypr)OId}=bsPmt7`M*mF{0inp$z63;LY<SS2GqHVbfh;X
zPkrzTd6^C!TDKSL3EVFLW8wEi6F5H*m-UG<&^h*bvd+Y@kd;{uvlk~2--UeH(FrLw
zvsTiBwd>Q^2G|3+s?*-P=v(OY(GhH8@}0Sf?ZEX^6I=W$RY~^$a9=Ma@|9~b{F;ee
zKQBVobDat#$QDZ*4-ZY}{_0Zv4z86qLVH|?!;^El&Ib#DikqD%?2K=z_8kSo{y<j5
z(PjBqd|2*R>|orWrHlL@H4c6Wm`VT7AiI+Ae{FDc5Ak8-TxI@m3PPSEBe@1ZlS$%I
z_7*W%bjuvlMuUS{S(|T(jf^bnlnotmhjahP>IFPI2hKxJPqCvP^8ZC}p)Y)22p(yN
zy^Rj_VO(a_<LuHzT~6OY77d4f&%nQh;j8x0KKg0JNNi)|^2C_zS&9oyk1@o34QGz9
zp&~>u<W*#3{#*2XS7>(&aR+#%e|-Ey{IZVY*msbhzFlKj8RPh!IP*~+KM1;93LU#s
z-w^uSZ#Ta232Z&?Uog)rm!mHeB5RUs(iu7ldd7NRb@rj46VkyCN-y<<W|w89PUL^4
zLyXM=Xom6)KnCoN+%=)a`Or3VKAbe4i0lW)#%Y-zIts!5zQCLhV}ByFb-5$5h<W+e
zh1eQ-CxYZ>kVVMil<2c_9_SNzt3NjHJK_vw;kWaf(S65}?dZeV<R6j=y?vEA<bQRh
zr4nPP_S4Q_4CBosPPPMkmuIn|i$6dL@O&!mg8%c4M84i+-E<|k;0*EwBTFvwPCx9q
zSB9jlfenUSU-wv(3o)R#*Z5oK8GmF%5@@~>I-)4NTrVYSy>&#MVi(7t-Sw)%EA3gY
z9Ii>7gz&JE1<-emulVVW@PY6p+~O0{N6zWcsXt>}CKCJG;O#rSdpu(n`knR0NW?&B
z?`SXq+gQc^Cw#`H=YA4cOh1<GpiTUL8L0J;%z>;~K^rP|G-NaUi_Pd^Ab)mZ8w9b(
z1AFQ;`t#a1bbK&8L%A#su;*^_ZvOAYctm>7TEt82d+0R#Blb0>(IjIc&VixF{g6fV
zk)N@X;Rj5^M?QzHO|4;{GEW!q)kr^t-I|Q+SM-^RLFA6eK5ph;%|kuX)jZt928qIa
zUb})0$xI9<2QgpWkQwvvAET()KC#d$>`!iv4KfjZQ3ksdzqdKI)@$sR#c$aIf}D9#
zjCd3EKJI{AZfnSU<datk=I)3g%W40RRoJkl@K>wjhtyX-5OxQ=pA(trHB^)S$g*+$
z4Eb{h>%ktlvKn?$b9j<DE{_d5nmVN{@)Cch9dnf8EAMW}dI@ss6Ln5Wg-i#l2Qn{F
z*-KFwyEYN>cL+8R`gGL_)`7^s6n|$jeXo*-wPQEp3=1?F#eLWJI%}28EB^;|MFt}u
zj`M#b^!(VP#7ojc$Bg@_N4jjEj*ZNi-9)}b*pD2`hm8jfTq3{v4YhR8-}XhEiK>S#
z?aRA{5%+w;95cTkk*CKPqiYcvm&WRRAodD2fGWF^7{}@~hSXeuESrh0c}BmmSxca=
zV<ktAK$nw{FUMcQpUh+D_4sM~kS_&@ucCvewm^sUA)bQK6SW(*CvlGj=mMYP$Xv=l
zJ<FaeWW(0S$jeLk0^``@`Ihl4#k});M@3{ydHi<hMty58tIl5L#qcw_PyME<fecmW
zjr1kNg2{h6r)HklI1bIK`y?Ys8_byocse@#(15hmt)TU^?5SrwQX@nBKf?!)*c-cn
zGZ#EpaePJp=K2IOa60#DjbdXoU5f96$KlU|UdYQA`1s3cH~gaF{z;<~vzd+DN`)T<
z4VJ+U8hDcP5Inn4*;enWyZAudr=Xt~xpv*kmAWc=aOP<h<9G}@ioyPAXg3w(Q9mEL
zk9@~L!}`R}xULFA-pnE$8!jun=Y|cF7>vbM3O<hP8^AmyApY@%eaUU%_qoVpbVG+o
z_#5;iacV;%!0(5l|Bf?w_ay8H^vo098|DVjAk*IYvuA?%iKL?a&_|ygto<Qhw`Eo9
zFsw`RzM<uaMPNg&f=2qSB}RdKIEEbhaFYI(<UHdSc;U1myPhGd$p35?^HxKb9_Y*}
z+3;0|5&uPxjlWLZh3Ct*;TLc{69xMQ-I)~HIf7m+j=j4AS$Z8>59}r4?uM+-fv<s0
z=8p`k^$cD3k@3YAew%?NGauUnSl7XiNQJDJHiUQ6&uBeaS4TdK=N;R8iS3WWS6q#K
z9}79uhBz7Y@7aKTujua&-SOecr_S;nXhYlrc^!L@As?`3Lr7EmP1{lCaZ+?G^p_kI
zc4thcu*S;&9$+25L}}~=<2JO&y&qWq2YWw|E$UpHT2q<;-;Cdd?_LZUj!Yig06Pwu
zR3II;+-uScl9w^P3++bzMqGXm@}nJciE+vOk?}@vKZCYkd}2Q(w(bb{JNHxmN6x7I
z0d+-}_s~V7nE2C~k>`)u<M5PtF0!)M4fq*Zez79&OH9m!_S~++-r_vWIsc!7*T3Dz
zeqF)2Rr<aj{i1B5i#)5IiM3N?Z;D;m>>ZIC_>POoSLYzMcQs@&dD0*^jv-go`LlbV
z2R!i{I>~nmJzEXGrWW>Ma^lp1_?~m&N!mP(@!7VAJ-D^lzk;3dF)DH=Dg1!ENK79)
z4IvJKt>`(N7{)UEE6Qx9pA*yJ_pD+3Y9ed1z$ehy2V`DFWM-b8tW6wc-F&Jh#Sao=
z)Zq(a09&wK)EeTbgv5s$aYm#!{`OLACFVXDyP`9)<1BjFz`y@m68o9FPfD{E<H>p@
z|EqXO18C(v@~P!U_CRGK25<=9A3i?aSC{9|Wnb*2d!ekGkbeoth)*<fB(wqTEaHBw
z4{>>DdEX^sL2AC4yY1LWU7)L$>EQD<=%KA@Eee^5e0>667KIiE!9R=9M-Q+iQ=Eez
z2E+64%wO@CPwKq_hErE;_&pxzhaR1Y{~zxFaS6sVI%&y3{bTG88_XVb{`Ufna~V<`
zdRT}bzhFFeD!MLBcTL>OQYHs6a%`5Ce)zV?m>%cxd*&lo?{J3sJo9=Meq;V3pf}rG
zAZ~M*J^aXz>D0T0xlcKfJ(tkIMDB;d6D^>%PdCY56+Wj=P1Zsy=#CQbYrzV{tI(%g
z4>L~JvGX<Nya=|<e8$U%dXQlu(Xi>V!<XIgt5zE_5WRX1-4rVmV~G7xD~-;WV~hQP
z&D#s#xIDHY?>_aN*liEiQjjCH;h_epk=LZRaU<?s75TIbxzr3_m$V&kpo=%`b>Ut2
zxlft|8Mchr9eVZ}I<3Wa*3|kTBk*ry@GJ#rbrqhNhusvNc*GKH?p(zBb@rTY(`0A`
z;?sTbM+*^u*-Ct#{N<W3?$}XfX-n?d=ugrbf+f9Kw}5{d(Uz13vY9z~`UUyKIIbDX
zoEY%RHuf?N<aZ?Kd*DUnW@bZ1EoQIFFzA{(iZib249tre_(#ywO#Ux*4n6acv>nJe
z?iYccGtlvskq7**%8dgna#AO@^qdLs7x&Y^${oZgxGn%o!1~1aQ;(@@4)ejiI#+W7
z)PXn7aJ>jF0L**YyaHP<xy?VgO4=vpYAQT8E(2?H?KrOx4S7BVTLt;3&gC4$F1W`v
z7c%e^*A0{56J%e(oWy#NBkKH)I?uDY2YQ_A?ySUf*Wu@!My4XGmbZb%m*5YcwC!!L
zjjyvRExPFh?|Wj1JMw?TUarJ%wqrA0Mi&3s3|}lKvY`Mv7yf#mmAC>tGxh^Cu^HVu
zowyS^?@l20H1k!X7`9G)ViVYZbt7Oqy@6&DAqQd*H_t`;pqto{b*a9UJx&er*CHdw
zcwb78kN$XYO%G;N!KUSUp(*-|YaHln8|Bs6`R|XQ3-~hACU_BfuGSU97_Vu_&NF3*
z7xl)s8cFN|oiS({v25g10&J7)ec>;3hC0WTavw4UJu#)7CKI?n!h~c#&bnkJn}1Xk
zd!#P3Q{lWW#m5uJ+Q=FPdMP%tdJ6eNk7&{zoe`7@n}mBES+pD-e`hVa^(lVNe&j6t
zub!Q+fdB9Zx@|OT@dJtNkd~kLVR7hhJ2t^^WJ(0=tK!%N2P$z+4;nA=ocQN*=(q&-
zFl|wLX)An1x5a{In7{40iN8hXJVGh#)g#0%_HxEG66-IAkXz$a9oUG-@hSLeLsGNG
zj_)+B1N-gZU$t+?9c*H5GQ7hs-p|?UF5E*O-I(u6jAyL!$N*?|Gd#2adFb{R>$li0
zM{Z#YA^Rp^1N3BU3*08AO<j%P_j<^ul`)|+<i=~-^$nWynuI*aiVW$*9=*xT0prsr
zH}R$_=nHS?gfZ6e4O7s!BY)x7BbPV2(dVedJ6p3xGMhMeGuBZf<164ZY&eD<-p{^Z
z-dPD$1?ueBC@>F92I@>$7*OZLZUS}2t1@;?H0;0b?!>J+(zm$SMWinpM2wSbbmY>_
z=<I*kNsNlQd^sQ65qZ{}XY&|;AFk@0mpa?E2&nU2w}CptbsxN9d?#T;ZLI@+zSSfT
zdTkc|LK}38^5e>(d)pr4UCeoGu(TKL|BMd@9gd>kmA|4l|6(r}d~piftT;AXE_Bx&
zbXlz-_%{)i9MmLYO!x)<-;XWV4qGP&<5w;telzs;@G5$N^iJrR<fqwBfzHp-3jX=T
zd9Nb)>*y!tS4Q58y@HJPr5%T>;5TH(FF`JNP<AM3?N9N|j}Yt@<n>tSK>47@YG5xe
zVh=_t);6KzplE!jfV@HQ=j?`@m12IL_eJL557!@x998}IXHAYc*f6eoY371*HyX2!
zHk0^dNA_;!XRYc0{si?jz}{F$-RJoKZY%aAz%%iniG#>DH|q5}2R}wZckiYR$k-X!
zRj<9+=STjG=z4$J-wFO+(U4dfZM`-Z*<6Bk&u)USVvWO(^|}GrJmrw<yl2UD_7S10
zI>YbNH?gKvl$hBoVm!#H^7!nP=$G-BeK6?p78{9|w`HFsa~pwn1&xAU?=e2yx7vd~
zSdQ<5P77<mTqA3DRX3z0e&AT<_XYnit47>7fhJcfFi-GiBi1M?&SO0QeX}5xeJ1Gn
z)AZv$P_!~HvCX!*ggx-)2>otC++`E89$Vv_a6bGYYj@CG$BVo>I&yG2>k`<ODsH1_
zci&PQ&FzO?lHoHgI0H|W!&ku8>x7@EXh6+rgLvp~=I&Z`Z2s2Bl+Nh5cgQDf5Ot2U
zjz6|hA7Vx)Sko+vowJizJM!uVeuYs7p7df~x3P|s40%_bdGE(MW+nAMK3@p(ZXW#6
z6Mc}0{bk6q&}zi%58-nlACEFNkKh;8UTr1x(v>zJ#Fk?`mm-gbq(dh|yAM~RZ?I3V
zL2p&ziA(6Vs>u4ltn^_ty0a<z5L)kY4n6sby&UlI-do6r`>gl2gdTTev)(~=W205&
zT{UTAz@P9gW0MCR^C%Mb2Xvxc!2j}M?jj@qZV=alKH|eCFIux_&l|fVG3$!GnD-~F
zC4Zq`5zx~oY-{1e7N9qWVOJq<<MHn4eTacTYg>^ww^m>)<<R9yDb_xx;S-_H(?Dkl
znYY=rCqHeO$JH}Hll8Y*)5s5hA+wZxt{RFRL_KYS8LyMrK*+}X$lVCcQ>#zt%52!L
z(2BBc2S!G>H^5E_ByLs~ULgHl4{S)}cD|j&^>zGy-ZLM6pfqt6b#5&bv>3rYsx!n=
ziGdlP@fmZow&~71G0rQGDjy164Ufj5Pglu*9Qj?f7V)fx?0K%mp2az=tuW6~^00?t
zDeGF$byH-<)F^zP!kzip${H5>AU*%97-}}?W)XBhau$0;NJ|FNrexg!9!dwlz3IxD
z6m#|g`B(y3;=%I*$M78(r-bm(Jal%7#n4A0Z1Ur3t(X|vVeA-aZaHJy<|TG<IqEcs
zD_mnOgz_ihqf6MhJ+~qg8ZjR0$WMPyVsE@o4ZjO^$SPufad|iS6V^pO-e*m5IOiU#
zVteCb<U3`^VfgnL`P4a`dB~9TL$NjBi+g{urra7?#n>o%Ry^!U+pT#l=#K4ze9q6f
zZivI&jYPh*VBFA=QX2h-4SXU6ZG(rSWJd2Ww~Zs=e`1?7-+-J*%UbMR>O{9LrafCL
zu`ZGpU5T$W9J%%&8EYpK_|C%&blhm@g}#o$4i06Enl{F_WxS>k!<bfvI+L^BvXi*;
zRdf)#wE0}@pqs4gl|-g4;#*hn$q{5`>WRb`PGQd!Lx(hhE|b!JbaF8H=D|B(p~Lll
z*bMQAfA3`s`r}Ju$6RFmaxmVDX>a*i$c;Xnx#QU=?D1gUm$x3i=mqRV<o9O!Gl9A7
z3Qv`W4kJL9X^}NUj<DWDz2~3fdn5M`ZDEgnEn*p7(2)l`8I|+d^N|}V@wxE}uSSNB
zNUsDMLjObi!e<eYo42q5ky##$QOIlJLw(pUeHj^=9{ITd{}})DIsUqTTkPy3>??sT
zD^o}N3g{=~_d(|R(Fttcn#iP+#P<>sgNAqa#UfS|f{)dWb@9U3N~7o#GNTN<l@dmq
zfzFGU8~Q4M%~p_aYIK6$sdqfSX_XbwEdBK>#~u*Urhum#@Ow%VH{}1+*m=+6BFhIN
zcjmFySBUQyP|sQPgrco0$fH^0JKh3W2ptvoWE`^K6C+R3K`+_HVawNJEge3%Nxq2i
zhW9e|G4uZgXzs~AWEZj}asp_U|BsWN2z@*p8FiBXBQv(W;fILm>CTK{<D}?T#_se<
z+C0oK>#WZ^Mj|usl7H@C)=Tm-cKrVW8hLyN9SWVDV_xE~!7u4fo8q7g>Gxf9^!#Pe
zq()4$pe~=$OJCYT$8n+C*~FE{(oSf)RV?gfWLeT2j3@FiI%D4DAu)yXTqonN3?s&l
zUwyDTbhwWg<xK2mY{FAhnU7TPeFoxAQL#OU<utsDj?BpYXyQij=#^*KLEF*cDex8H
zg{{~m{;eqATa(Y!vle-sWE|%vq0vFi=Mn6qqI+1w$cgU_U!}s=+=M)Mhb`=j-t#8y
z8vLi`rs+v!{(Wq^`NS<M5vxW%ydF$Fv^OQX${`PmqyL%H2gsp8?!-?F_+SHPL70=L
z#aTB%-#>+a4;IHJ+DtzmAxn=Dn?dFTXU3jJwueHmgKO}f9DKj&D)#A7<^#R70bcYW
zUjg_u(+qS9Hu!MvLpQ@GLM(qX@^3zI5#H^doc=B+MvJ_iMLVy-3tevzUx%+hVJ8fu
z+ypQM%mCBC954&a2Xnz95CYmIBrY(7_&I#3^s$mb`eR~8Th&=OY=>&>@knX&p)ZmD
zF1QUIs_Pfz2iJ4Rzbkjy&q4nSGr#wcnQw{_$L|CUqnrG$6GtN7N#H-2ve*=mom4`1
z+`5l#ogE*!IO~t8S(8QQt-M8yx(nxe=o@NH+VsX|j03+ngU1)Kk7F<UZT#^c&}9;v
ziujwxRei@PJ90X-7~_bo^u^O=FMa5ZkBiL|HXC1$>%-mnw()s>gEaKXhwsGK(ZyjY
zS;t_G9u~tc!H#<BiTwv3J?)MCg>LvVn>k_ZU+iX|C364j4Yl8rG5L<|;!ZutwR;}u
zBl`Y^zMl3(?!dDzdh4o*zyE%Z!0!?GJp#W+;P(jp9)aH@@OuP)kHGH{_&ox@N8tam
z5txuIr#7hDig9?KqOPAN^{idFa%uPKrAubR{gmvL0|HxB2=r?!+0_p*1>wFEkO!(j
zB%uDH0b(8IUqstQuGUcQ?(e_fBk+3!eviQK5%@g<zenKr2>c#_-y`sQ1b&ae?-BSt
z0>4M#{|6%w-R`6}p)HNiN0mCqB1*Dhwl&@Xw{Z0}zG=PQP26{}28_S|f_!rpvR^4W
z`=t!_Fj77l{(t?L>__GQ3<*Wti4Tn7|KM=w!+l|%_29}@KN-Qb3m9QfV{3@?0WYX~
z2x+1GKZSZj_+Qm^g#Ch{tW~RaM2XCv5w2Hrai5tr{nYGZWBvLCSFgp9`5g`Jr*k%y
zePTChQ%GsnvKz6!P5E}IXao61uzykg7S~nEd2wZXhaBJ?rFn1uF6<d}r(V)3vyaS+
zcl7}3TYBzXKd_ggxCdiE***;3j&$^`4Ev3^-;#&+azCaB`;k~{Ps2KUb?$Tck%wy(
z-rt)2R$Zvyi|6@ycQW2PqZH%Ev(l7Pzdf*kHdZH3aZsK8BqK;;3yxd`EecSMy$1Eu
zvp<4%)aL&!yypOUr!anBxT^MVQO`gG#;`VU11-RTH0%Z7y_Ko+4da(1C;zK<(jL{O
zkpAS)!5C-bJ`4S$Uq@)eoKlP_`EszICE1_ssU-a=^%Z6hLLb_7nrBbJUDC&J-4cm0
zD98JFc7$==A-pdNb<$7O*Dt&)xHM-cc&_FzB%dwc-PEM<j^LuCGdB5|@2BJsuEe;p
zA0mu*o(3V**+ca;FYn3(-H>NXDI1+F;Q!OA@62;`t{Hg82l`x?|F=+|JLOvQP9ZIn
zwyJ(NC(jZ7UqZdDNk7e1jaf)U`azlE?7LHKS;JTi;C)}HV+8v^qcBE=8L!5q<<HF?
z7|P|L%vFMDX=rbL>Q&z=-q3_J>a9-O)bD)_;QtN0uLt$4p<QfqlnLDD08eR8erTx+
z?Vke;zoEW0YV0V(b~JOG=cqoVrhV+~Q0?Es+^g>pvaMO%xhA6RY+;fYAcVT!(Dnh;
z6M?-UjmaC2|65RpqN}Iu6A7iQl^Jiv+p51`(%9(z(>nT7lQVVXS2Exwcm-aAH{dOJ
z2i}7Z;3N11K7%jdEBFS!1EDR56=6%Qu<ZyL!yYjZ2}B04n;A}w##PBDHxL7`RZrOV
zCb2;r5ErmTN8*9_fUTL55U@Q{I1VCg5tO8Wtx>`@D`C5pqy+B31Ed0My_7V7?TwNS
zqz4&5Mvw_)23bH>z*bku4%B$&1i63;a^?YfK|b&&$PWqtw%th~P#6>eML{u89Fzbh
zK`BrglmTTyIZz%{02M(cP#IJKRY5gS9n=79X_8u?HmC#Yf_k7nXaLlfqDG)GXabr7
zPv8Z-fe&Z~ngd_p2mC<`5CB?&R-iR#0|G%?&<?Z*9Y7FJvbiH*i<EQ*N~U)O-9UGs
z<b6-j3-ktkKwr=g^algLKrjdl21CG5FboU_Bfv;75L#B>7#a+eei#adf#F~T7zsv!
z(O?W13&w%*U;>y3CV|Od3YZF}f$3ldm<eWq*<cQs3+93OU;$VN7J<cJ30Ml2f#qNY
zSP52v)nE-+3)X@4U<23)Hi6Ax3)l*_f$d-i*a>!l-Cz&c3-*Ei-~c!X4uQkq2sjFk
zf#V<qoB$`mDWGKI8E_Vy1EJtNxBxB!B|k5L%is#Q3a)|c;0Cw}Zh^nRbMOMZ1h2qr
z@CLjE@4$QT0el3Xz-RCUd<EaYcOb|O4d}oC5kN!`2}A}_KvWP7L<epl28an_f!H7p
zhztGzN^Zpm34pzNLDdK%OAwKQnl_gu5OIRY7DTULN=Pga8z7biQ74Exi3d<$>a%!)
zm=(6q3F1)@hk{rY#Ht{Um6{NxF5H0!K!gjTSJHsA097jK0jfbzU4kl*%mCFOs0cxo
z3Tj$V6N0*xTmV%eh-E>2393&}sgfU{-lZTY1PX&9peQH?ih~lMBq#++gEF8jC<n@e
z3ZNpW1S*3npem>as)HH;aW1t$ZBPf)1@%CE&;T?9jX-121T+PnzzcW-AJ7am2fn}$
z_=6T80JH?HKx@zj1cJ7p9cT|afFKYII)YB1Gw1@kf^MKY=mC0yUZ6MV1Nwq~pg$M@
z27*CgFc<=cf?;4d7y(9tQD8I}1IB`JU_6)rCW1*|GMECUf@xqnm;q*jSztDp1LlHx
zU_Mv?7J@}!F<1hYf@NSiSOHdoRbVw(1J;6dU_ICXHiAuHGuQ&Qf^A?s*a3EeU0^rZ
z1NMS_U_Uqj4uV7AFgOB^f@9z~2mvR+NpK3B24}!oa1Mlm^WXxw2*SW6a2Z?ySHU%K
z9ozsn!7Xqb+yQsNJ#Zg901v?<@EAM+Pr)<r7kCavY0Lu{1IB`JU_6)rCW1*|GMECU
zf@xqnm;q*jSztDp1LlHxU_Mv?7J@}!F<1hYf@NSiSOHdoRbVw(1J;6dU_ICXHiAuH
zGuQ&Qf^A?s*a3EeU0^rZ1NMS_U_Uqj4uV7AFgOB^f@9z~2mvR+NpK3B24}!oa1Mlm
z^WXxw2*SW6a2Z?ySHU%K9ozsn!7Xqb+yQsNJ#Zg901v?<@EAM+Pr)<r7kCa{fS2GE
zcn#iwx8NOk4?cj8;1l=^zJRab8~6@HN2UWE7$5>*yS_vMkwFv?6+{Ekfg6YcVuDy8
zHi!e*dM|%~cpyGV0669#937FwAPHbAzp&L^l7ke0?aAT}JU}YIc5A-9h#Us#Kzfh?
zWCWQ2Th=8D$O^K7?11A2k`v?txj`O~7pQYee*$Gg7XTa+kV2p^C<2NCwna;EPy&<$
zr9f#=29yQmKzUFBR0NekWl#lF1=T=xPy^HiwLoo92h;@|pOE^X0cZ#sfyST-XbRYl
zZGJD)o2w6K2ATt3;0OFc3lIQWf>xk4XafR4ThI=)2OU5V2nHPiM@6JF=mNTeZlF8p
z0eXU7Ky3r>1Nwq~pg$M@27*CgFc<=cf?;4d7y(9tQD8I}1IB`JU_6)rCW1*|GMECU
zf@xqnm;q*jSztDp1LlHxU_Mv?7J@}!F<1hYf@NSiSOHdoRbVw(1J;6d|EHb1Z1SoM
z133K1x`H?$DhRtQ7?dC(At*|Bh=7QMbV+xI5_WfYchKG4-L<=HFWr4D-@$kPGjq*(
zf1f!o?q}xrFqLUcX9hEw#cbv<mwC)*0Sj5gVwSL!Wh`d}D_O;A*07d!tY-ro*~DhH
zu$66WX9qjk#cuYnmwoK#00%k5Vd6<3ks~CLObV%_kxmAg9OW3tIl)Ozahfxn<s9d^
zz(p=`nJZl78X?O6Pd1{snP_BVAv-yc@`Rj7gKq4Uxx8~DuL*gOLIkN%a2-U*OFkqh
zLCO&d5JN1oo)AYN3L|fF*Mk2axlJfSQHoKV5@hZBB`JlZEtIAVWhsYjC6uQE6{&=b
zC{(5jSv$K#CR9ZN6=YVS8r7*mO=?k_I@F~e^=Uvu8qt_0G)2l2nju9A&1pePq-CKM
za^BDyiCSnwTiVecIaKICM>^4&E_9_E-RVJ3dXcr)_ofeh=|_JCFpxnEW(Y$W#&AY3
zl2MFi3}YF`cqSlYxpCez(R&h;nZk>_#LK+GtGveRyuq8i#oN5YyS&Hye87i%#K(NX
zr+miee8HD|#n*hpw|vL<{J@X=#LxV~ul&aE{K236#ozqHzx>BkrZJrv%w!g`nZsP>
zF`or2WD$#5!cvy8oE5BO6{}gpTGp|i4Qyl+o7uuvwy~WZ>|__a*~4D;v7ZAR<Pe96
zCxJwckVG;mq>@HD8Dw&lV;tuMCppDw&Ty7<oaX`;xx{6zaFuIhEnYW~jVQ9t7^As`
z?Bw89a&jA4=V-ae&F$pj4({YG@{*6c$xi`dh@~KL6rwQqa4+|9KSd}?F^W@y2PjD?
z9;7s7C`&mWqC6F-NF^SoGF5nlN2$tVJWe&LQ-hk+qBeD?OFin-fQB@pF->U76Ex#V
zn$v=oJVh&>rZvydhPJe$J<rmCj&!0kUFb?Ty3>Q6^x`>s(}%wFqdx-}$RGwYgrN*$
zI3pOzC`L1ev5aFp6L_8%n8+k1Glh5(NaP4fB$GlaX{3`uCi$a%XJUw@AaO*V$OIx2
Rh)f_dfye|R6Zrooa2?)35byv1

literal 0
HcmV?d00001


From d845a118c4be0b2083d1961bcbdba767aeae2582 Mon Sep 17 00:00:00 2001
From: Shaopeng <81775155+shaopeng-gh@users.noreply.github.com>
Date: Thu, 16 Dec 2021 15:36:20 -0800
Subject: [PATCH 02/10] re-run baseline

---
 .../Expected/BinSkim.win-x64.ni.dll.sarif     | 331 ++++++++---------
 .../Expected/BinSkim.win-x86.ni.dll.sarif     | 331 ++++++++---------
 .../Expected/Binskim.linux-x64.dll.sarif      | 321 ++++++++---------
 .../Expected/Binskim.win-x64.RTR.dll.sarif    | 331 ++++++++---------
 .../Expected/Binskim.win-x64.dll.sarif        | 321 ++++++++---------
 .../Expected/Binskim.win-x86.RTR.dll.sarif    | 331 ++++++++---------
 .../Expected/Binskim.win-x86.dll.sarif        | 321 ++++++++---------
 ...rupted_Native_x86_VS2013_Default.exe.sarif |   1 +
 ...ore_RTR_linux-x64_VS2019_Default.dll.sarif | 331 ++++++++---------
 ...tCore_RTR_win-x64_VS2019_Default.dll.sarif | 331 ++++++++---------
 ...tCore_RTR_win-x86_VS2019_Default.dll.sarif | 331 ++++++++---------
 ...NetCore_linux-x64_VS2019_Default.dll.sarif | 331 ++++++++---------
 ...otNetCore_win-x64_VS2019_Default.dll.sarif | 331 ++++++++---------
 ...otNetCore_win-x64_VS2019_Default.exe.sarif | 331 ++++++++---------
 ...otNetCore_win-x86_VS2019_Default.dll.sarif | 331 ++++++++---------
 ...InteropAssemblyForAtlTestLibrary.dll.sarif | 321 ++++++++---------
 .../Expected/ManagedResourcesOnly.dll.sarif   | 321 ++++++++---------
 ...aged_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif | 331 ++++++++---------
 ...anaged_AnyCPU_VS2017_Prefer32Bit.exe.sarif | 331 ++++++++---------
 .../Managed_x64_VS2015_FSharp.exe.sarif       | 331 ++++++++---------
 ...VS2019_CSharp_DebugType_Embedded.dll.sarif | 331 ++++++++---------
 ...x64_VS2019_CSharp_DebugType_Full.dll.sarif | 331 ++++++++---------
 ...x64_VS2019_CSharp_DebugType_None.dll.sarif | 321 ++++++++---------
 ..._VS2019_CSharp_DebugType_PdbOnly.dll.sarif | 331 ++++++++---------
 ...VS2019_CSharp_DebugType_Portable.dll.sarif | 331 ++++++++---------
 ...x64_VS2019_VB_DebugType_Embedded.dll.sarif | 331 ++++++++---------
 ...ged_x64_VS2019_VB_DebugType_Full.dll.sarif | 331 ++++++++---------
 ...ged_x64_VS2019_VB_DebugType_None.dll.sarif | 321 ++++++++---------
 ..._x64_VS2019_VB_DebugType_PdbOnly.dll.sarif | 331 ++++++++---------
 ...x64_VS2019_VB_DebugType_Portable.dll.sarif | 331 ++++++++---------
 .../Expected/Managed_x86_VS2013_Wpf.exe.sarif | 331 ++++++++---------
 .../Managed_x86_VS2015_FSharp.dll.sarif       | 331 ++++++++---------
 .../MixedMode_x64_VS2013_Default.dll.sarif    | 331 ++++++++---------
 .../MixedMode_x64_VS2013_NoPdb.exe.sarif      | 231 ++++++------
 .../MixedMode_x64_VS2015_Default.exe.sarif    | 331 ++++++++---------
 ...4_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif | 331 ++++++++---------
 ..._VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif | 331 ++++++++---------
 ..._x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif | 331 ++++++++---------
 ..._x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif | 231 ++++++------
 .../MixedMode_x86_VS2013_Default.exe.sarif    | 331 ++++++++---------
 .../MixedMode_x86_VS2013_MissingPdb.dll.sarif | 231 ++++++------
 .../MixedMode_x86_VS2015_Default.exe.sarif    | 331 ++++++++---------
 ...ve_ARM_VS2015_CvtresResourceOnly.dll.sarif | 321 ++++++++---------
 .../Native_x64_VS2013_Default.dll.sarif       | 331 ++++++++---------
 ...ve_x64_VS2015_CvtresResourceOnly.dll.sarif | 321 ++++++++---------
 .../Native_x64_VS2015_Default.dll.sarif       | 331 ++++++++---------
 ...ve_x64_VS2019_Atl_NoPdbGenerated.dll.sarif | 231 ++++++------
 ...4_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif | 331 ++++++++---------
 ..._VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif | 331 ++++++++---------
 ..._x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif | 331 ++++++++---------
 ..._x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif | 231 ++++++------
 .../Native_x64_VS2019_SDL_Enabled.exe.sarif   | 331 ++++++++---------
 ...tive_x64_VSCode_Rust_DebugInfo_0.exe.sarif | 331 ++++++++---------
 ...tive_x64_VSCode_Rust_DebugInfo_1.exe.sarif | 331 ++++++++---------
 ...tive_x64_VSCode_Rust_DebugInfo_2.exe.sarif | 331 ++++++++---------
 .../Native_x86_VS2012_SDL_Enabled.exe.sarif   | 331 ++++++++---------
 .../Native_x86_VS2013_Default.exe.sarif       | 331 ++++++++---------
 .../Native_x86_VS2013_PdbMissing.exe.sarif    | 231 ++++++------
 .../Native_x86_VS2013_ResourceOnly.dll.sarif  | 331 ++++++++---------
 ...Native_x86_VS2015_AtlProxyStubPS.dll.sarif | 331 ++++++++---------
 ...ve_x86_VS2015_CvtresResourceOnly.dll.sarif | 321 ++++++++---------
 .../Native_x86_VS2015_Default.exe.sarif       | 331 ++++++++---------
 .../Native_x86_VS2015_Default_Debug.dll.sarif | 331 ++++++++---------
 ...ve_x86_VS2017_15.5.4_PdbStripped.dll.sarif | 231 ++++++------
 .../Native_x86_VS2019_SDL_Enabled.exe.sarif   | 331 ++++++++---------
 .../Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif   | 331 ++++++++---------
 .../Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif  | 261 +++++++-------
 .../Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif  | 231 ++++++------
 .../Expected/Uwp_ARM_VS2017_VB.dll.sarif      | 331 ++++++++---------
 ...wp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif | 331 ++++++++---------
 .../Uwp_x64_VS2015_DefaultBlankApp.dll.sarif  | 261 +++++++-------
 .../Uwp_x64_VS2015_DefaultBlankApp.exe.sarif  | 231 ++++++------
 .../Expected/Uwp_x64_VS2017_Cpp.dll.sarif     | 331 ++++++++---------
 .../Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif    | 331 ++++++++---------
 .../Uwp_x86_VS2015_DefaultBlankApp.dll.sarif  | 261 +++++++-------
 .../Uwp_x86_VS2015_DefaultBlankApp.exe.sarif  | 231 ++++++------
 .../Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif    | 331 ++++++++---------
 .../Wix_3.11.1_VS2017_Bootstrapper.exe.sarif  | 331 ++++++++---------
 .../Expected/clang.default_compilation.sarif  | 321 ++++++++---------
 .../Expected/clang.elf.objectivec.dwarf.sarif | 331 ++++++++---------
 .../Expected/clang.execstack.sarif            | 321 ++++++++---------
 .../Expected/clang.execstack.so.sarif         | 321 ++++++++---------
 .../Expected/clang.immediate_binding.sarif    | 321 ++++++++---------
 .../Expected/clang.no_immediate_binding.sarif | 321 ++++++++---------
 .../Expected/clang.no_stack_protector.sarif   | 321 ++++++++---------
 .../Expected/clang.noexecstack.sarif          | 321 ++++++++---------
 .../Expected/clang.noexecstack.so.sarif       | 321 ++++++++---------
 .../Expected/clang.non_pie_executable.sarif   | 321 ++++++++---------
 .../Expected/clang.object_file.o.sarif        | 321 ++++++++---------
 .../Expected/clang.pie_executable.sarif       | 321 ++++++++---------
 .../Expected/clang.relocationsro.sarif        | 321 ++++++++---------
 .../Expected/clang.relocationsrw.sarif        | 321 ++++++++---------
 .../Expected/clang.shared_library.so.sarif    | 321 ++++++++---------
 .../Expected/clang.stack_protector.a.sarif    |   1 +
 .../Expected/clang.stack_protector.sarif      | 321 ++++++++---------
 .../Expected/clang.stack_protector.so.sarif   | 321 ++++++++---------
 .../clangcl.pe.cpp.codeview.exe.sarif         | 339 +++++++++---------
 .../Expected/gcc.default_compilation.sarif    | 321 ++++++++---------
 ...rongsspbuffersize8+fnostackprotector.sarif | 331 ++++++++---------
 .../Expected/gcc.execstack.sarif              | 321 ++++++++---------
 .../Expected/gcc.execstack.so.sarif           | 321 ++++++++---------
 .../Expected/gcc.fortified.sarif              | 321 ++++++++---------
 .../Expected/gcc.gsplitdwarf.5.dwo.sarif      | 331 ++++++++---------
 .../Expected/gcc.gsplitdwarf.5.sarif          | 331 ++++++++---------
 ...oworld.4.o.no-stack-clash-protection.sarif | 331 ++++++++---------
 ...oworld.5.o.no-stack-clash-protection.sarif | 331 ++++++++---------
 .../gcc.helloworld.execstack.5.o.sarif        | 331 ++++++++---------
 .../Expected/gcc.helloworld.nodwarf.sarif     | 321 ++++++++---------
 .../gcc.helloworld.noexecstack.5.o.sarif      | 331 ++++++++---------
 .../Expected/gcc.immediate_binding.sarif      | 321 ++++++++---------
 .../gcc.no_fortification_required.sarif       | 321 ++++++++---------
 .../Expected/gcc.no_immediate_binding.sarif   | 321 ++++++++---------
 .../Expected/gcc.no_stack_protector.sarif     | 321 ++++++++---------
 .../Expected/gcc.noexecstack.sarif            | 321 ++++++++---------
 .../Expected/gcc.noexecstack.so.sarif         | 321 ++++++++---------
 .../Expected/gcc.non_pie_executable.sarif     | 321 ++++++++---------
 ...objcopy.stripall.addgnudebuglink.dbg.sarif | 331 ++++++++---------
 ...gcc.objcopy.stripall.addgnudebuglink.sarif | 321 ++++++++---------
 .../Expected/gcc.object_file.o.sarif          | 321 ++++++++---------
 .../gcc.pe.objectivec.dwarf.exe.sarif         | 231 ++++++------
 .../Expected/gcc.pie_executable.sarif         | 321 ++++++++---------
 .../Expected/gcc.relocationsro.sarif          | 321 ++++++++---------
 .../Expected/gcc.relocationsrw.sarif          | 321 ++++++++---------
 .../Expected/gcc.requiredsymbol.4.o.sarif     | 331 ++++++++---------
 .../Expected/gcc.requiredsymbol.5.o.sarif     | 331 ++++++++---------
 .../Expected/gcc.shared_library.so.sarif      | 321 ++++++++---------
 .../Expected/gcc.stack_protector.a.sarif      |   1 +
 .../Expected/gcc.stack_protector.sarif        | 321 ++++++++---------
 .../Expected/gcc.stack_protector.so.sarif     | 321 ++++++++---------
 .../Expected/gcc.unfortified.sarif            | 321 ++++++++---------
 .../Pass/clangcl.pe.cpp.codeview.exe          | Bin 0 -> 1178624 bytes
 .../Pass/clangcl.pe.cpp.codeview.pdb          | Bin 0 -> 6270976 bytes
 132 files changed, 20199 insertions(+), 20069 deletions(-)
 create mode 100644 src/Test.FunctionalTests.BinSkim.Rules/FunctionalTestsData/BA2006.BuildWithSecureTools/Pass/clangcl.pe.cpp.codeview.exe
 create mode 100644 src/Test.FunctionalTests.BinSkim.Rules/FunctionalTestsData/BA2006.BuildWithSecureTools/Pass/clangcl.pe.cpp.codeview.pdb

diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif
index 6c43d65db..bb6cbc52c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif
@@ -790,13 +790,10 @@
           "rules": [
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +836,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -923,20 +920,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -951,20 +948,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -982,20 +979,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1038,20 +1035,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1063,20 +1060,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1091,20 +1088,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1125,17 +1122,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1147,17 +1144,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1169,17 +1166,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1194,17 +1191,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1219,17 +1216,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1241,17 +1238,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1263,17 +1260,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1285,17 +1282,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1307,17 +1304,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1329,17 +1326,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1351,17 +1348,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1379,17 +1376,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1401,17 +1398,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1423,17 +1420,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1445,20 +1442,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1473,20 +1470,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1504,20 +1501,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1529,20 +1526,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1563,20 +1560,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1588,20 +1585,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1616,20 +1613,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1647,7 +1644,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1672,6 +1672,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif
index 2ff88948d..1f7827462 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif
@@ -788,13 +788,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +803,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +828,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -862,17 +859,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -887,20 +884,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -918,20 +915,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -946,20 +943,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1005,20 +1002,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1030,20 +1027,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1061,20 +1058,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1095,17 +1092,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1117,17 +1114,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1139,17 +1136,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1164,17 +1161,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1189,17 +1186,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1211,17 +1208,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1233,17 +1230,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1255,17 +1252,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1277,17 +1274,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1299,17 +1296,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1321,17 +1318,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1349,17 +1346,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1371,17 +1368,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1393,17 +1390,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1418,20 +1415,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1449,20 +1446,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1474,20 +1471,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1508,20 +1505,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1530,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1558,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1583,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1611,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,7 +1642,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1670,6 +1670,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif
index 96bd3efce..8eb5f44e6 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif
@@ -772,13 +772,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -790,20 +787,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -815,20 +812,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -843,20 +840,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -874,20 +871,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -902,20 +899,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -927,20 +924,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -955,20 +952,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -989,20 +986,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1020,20 +1017,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1045,20 +1042,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1076,20 +1073,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1101,20 +1098,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1129,20 +1126,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1163,17 +1160,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1185,17 +1182,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1207,17 +1204,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1232,17 +1229,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1257,17 +1254,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1279,17 +1276,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1301,17 +1298,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1323,17 +1320,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1345,17 +1342,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1367,17 +1364,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1389,17 +1386,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1417,17 +1414,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1439,17 +1436,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1461,17 +1458,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1486,20 +1483,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1517,20 +1514,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1542,20 +1539,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1570,20 +1567,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1601,7 +1598,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1646,6 +1646,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif
index 62462cbb0..be14e14d1 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif
@@ -790,13 +790,10 @@
           "rules": [
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +836,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -923,20 +920,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -951,20 +948,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -982,20 +979,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1038,20 +1035,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1063,20 +1060,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1091,20 +1088,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1125,17 +1122,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1147,17 +1144,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1169,17 +1166,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1194,17 +1191,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1219,17 +1216,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1241,17 +1238,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1263,17 +1260,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1285,17 +1282,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1307,17 +1304,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1329,17 +1326,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1351,17 +1348,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1379,17 +1376,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1401,17 +1398,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1423,17 +1420,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1445,20 +1442,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1473,20 +1470,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1504,20 +1501,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1529,20 +1526,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1563,20 +1560,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1588,20 +1585,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1616,20 +1613,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1647,7 +1644,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1672,6 +1672,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif
index 57417ded1..bb317f7e7 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif
@@ -772,13 +772,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -790,20 +787,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -815,20 +812,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -843,20 +840,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -874,20 +871,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -902,20 +899,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -927,20 +924,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -955,20 +952,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -989,20 +986,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1020,20 +1017,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1045,20 +1042,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1076,20 +1073,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1101,20 +1098,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1129,20 +1126,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1163,17 +1160,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1185,17 +1182,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1207,17 +1204,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1232,17 +1229,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1257,17 +1254,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1279,17 +1276,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1301,17 +1298,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1323,17 +1320,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1345,17 +1342,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1367,17 +1364,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1389,17 +1386,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1417,17 +1414,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1439,17 +1436,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1461,17 +1458,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1486,20 +1483,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1517,20 +1514,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1542,20 +1539,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1570,20 +1567,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1601,7 +1598,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1646,6 +1646,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif
index be4a16ba1..e43aaf0d1 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif
@@ -788,13 +788,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +803,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +828,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -862,17 +859,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -887,20 +884,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -918,20 +915,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -946,20 +943,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1005,20 +1002,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1030,20 +1027,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1061,20 +1058,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1095,17 +1092,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1117,17 +1114,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1139,17 +1136,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1164,17 +1161,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1189,17 +1186,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1211,17 +1208,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1233,17 +1230,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1255,17 +1252,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1277,17 +1274,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1299,17 +1296,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1321,17 +1318,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1349,17 +1346,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1371,17 +1368,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1393,17 +1390,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1418,20 +1415,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1449,20 +1446,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1474,20 +1471,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1508,20 +1505,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1530,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1558,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1583,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1611,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,7 +1642,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1670,6 +1670,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif
index 8efdebd1d..92dda9ce4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -839,20 +836,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -870,20 +867,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -898,20 +895,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -923,20 +920,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -951,20 +948,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1016,20 +1013,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1041,20 +1038,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1106,17 +1103,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1128,17 +1125,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1150,17 +1147,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1175,17 +1172,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1200,17 +1197,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1222,17 +1219,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1244,17 +1241,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1266,17 +1263,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1288,17 +1285,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1310,17 +1307,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1332,17 +1329,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1360,17 +1357,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1382,17 +1379,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1404,17 +1401,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1429,20 +1426,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1460,20 +1457,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1485,20 +1482,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1513,20 +1510,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1538,20 +1535,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1566,20 +1563,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1597,7 +1594,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1642,6 +1642,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Corrupted_Native_x86_VS2013_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Corrupted_Native_x86_VS2013_Default.exe.sarif
index 1ed0528af..657da81f3 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Corrupted_Native_x86_VS2013_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Corrupted_Native_x86_VS2013_Default.exe.sarif
@@ -50,6 +50,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif
index 55823c135..737c671a7 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif
@@ -795,13 +795,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -813,20 +810,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -838,20 +835,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -866,20 +863,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -897,20 +894,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -925,20 +922,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -950,20 +947,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -978,20 +975,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1012,20 +1009,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1043,20 +1040,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1068,20 +1065,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1099,20 +1096,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1124,20 +1121,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1152,20 +1149,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1186,17 +1183,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1208,17 +1205,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1230,17 +1227,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1255,17 +1252,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1280,17 +1277,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1302,17 +1299,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1324,17 +1321,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1440,17 +1437,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1462,17 +1459,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1484,17 +1481,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1512,17 +1509,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1537,20 +1534,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1568,20 +1565,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1593,20 +1590,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1621,20 +1618,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1652,7 +1649,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1677,6 +1677,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif
index f946b8c9a..ee7b4cd70 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif
@@ -795,13 +795,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -813,20 +810,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -838,20 +835,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -866,20 +863,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -897,20 +894,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -925,20 +922,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -950,20 +947,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -978,20 +975,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1012,20 +1009,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1043,20 +1040,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1068,20 +1065,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1099,20 +1096,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1124,20 +1121,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1152,20 +1149,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1186,17 +1183,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1208,17 +1205,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1230,17 +1227,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1255,17 +1252,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1280,17 +1277,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1302,17 +1299,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1324,17 +1321,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1440,17 +1437,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1462,17 +1459,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1484,17 +1481,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1512,17 +1509,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1537,20 +1534,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1568,20 +1565,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1593,20 +1590,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1621,20 +1618,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1652,7 +1649,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1677,6 +1677,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif
index 5eeb6b548..9f25db574 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif
@@ -791,13 +791,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -862,20 +859,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -921,20 +918,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -946,20 +943,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1064,20 +1061,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1095,20 +1092,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1129,17 +1126,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1151,17 +1148,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1173,17 +1170,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1198,17 +1195,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1223,17 +1220,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1245,17 +1242,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1267,17 +1264,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1289,17 +1286,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1311,17 +1308,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1333,17 +1330,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1355,17 +1352,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1383,17 +1380,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1405,17 +1402,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1427,17 +1424,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1480,20 +1477,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1511,20 +1508,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1564,20 +1561,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1586,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1614,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,7 +1645,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1673,6 +1673,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif
index c7076a5bf..ddcf41a4f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif
@@ -795,13 +795,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -813,20 +810,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -838,20 +835,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -866,20 +863,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -897,20 +894,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -925,20 +922,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -950,20 +947,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -978,20 +975,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1012,20 +1009,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1043,20 +1040,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1068,20 +1065,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1099,20 +1096,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1124,20 +1121,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1152,20 +1149,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1186,17 +1183,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1208,17 +1205,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1230,17 +1227,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1255,17 +1252,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1280,17 +1277,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1302,17 +1299,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1324,17 +1321,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1440,17 +1437,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1462,17 +1459,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1484,17 +1481,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1512,17 +1509,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1537,20 +1534,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1568,20 +1565,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1593,20 +1590,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1621,20 +1618,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1652,7 +1649,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1677,6 +1677,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif
index cdf60b472..3cb656772 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif
@@ -795,13 +795,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -813,20 +810,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -838,20 +835,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -866,20 +863,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -897,20 +894,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -925,20 +922,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -950,20 +947,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -978,20 +975,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1012,20 +1009,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1043,20 +1040,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1068,20 +1065,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1099,20 +1096,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1124,20 +1121,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1152,20 +1149,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1186,17 +1183,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1208,17 +1205,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1230,17 +1227,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1255,17 +1252,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1280,17 +1277,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1302,17 +1299,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1324,17 +1321,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1440,17 +1437,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1462,17 +1459,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1484,17 +1481,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1512,17 +1509,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1537,20 +1534,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1568,20 +1565,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1593,20 +1590,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1621,20 +1618,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1652,7 +1649,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1677,6 +1677,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif
index e22dcf742..4cb3fc583 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif
@@ -786,13 +786,10 @@
           "rules": [
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -804,20 +801,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -835,17 +832,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -860,20 +857,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -891,20 +888,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -919,20 +916,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -950,20 +947,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -975,20 +972,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1000,20 +997,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1028,20 +1025,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1062,17 +1059,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1084,17 +1081,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1106,17 +1103,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1131,17 +1128,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1156,17 +1153,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1178,17 +1175,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1200,17 +1197,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1222,17 +1219,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1244,17 +1241,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1266,17 +1263,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1288,17 +1285,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1316,17 +1313,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1338,17 +1335,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1360,17 +1357,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1382,20 +1379,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1410,20 +1407,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1438,20 +1435,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1469,20 +1466,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1494,20 +1491,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1528,20 +1525,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1559,20 +1556,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1584,20 +1581,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1612,20 +1609,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1643,7 +1640,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1668,6 +1668,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif
index d0f304d5f..9a11763c7 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif
@@ -791,13 +791,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -862,20 +859,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -921,20 +918,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -946,20 +943,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1064,20 +1061,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1095,20 +1092,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1129,17 +1126,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1151,17 +1148,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1173,17 +1170,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1198,17 +1195,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1223,17 +1220,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1245,17 +1242,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1267,17 +1264,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1289,17 +1286,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1311,17 +1308,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1333,17 +1330,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1355,17 +1352,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1383,17 +1380,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1405,17 +1402,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1427,17 +1424,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1480,20 +1477,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1511,20 +1508,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1564,20 +1561,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1586,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1614,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,7 +1645,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1673,6 +1673,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif
index 300460d03..a548c6db5 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -839,20 +836,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -870,20 +867,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -898,20 +895,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -923,20 +920,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -951,20 +948,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1016,20 +1013,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1041,20 +1038,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1106,17 +1103,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1128,17 +1125,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1150,17 +1147,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1175,17 +1172,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1200,17 +1197,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1222,17 +1219,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1244,17 +1241,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1266,17 +1263,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1288,17 +1285,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1310,17 +1307,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1332,17 +1329,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1360,17 +1357,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1382,17 +1379,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1404,17 +1401,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1429,20 +1426,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1460,20 +1457,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1485,20 +1482,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1513,20 +1510,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1538,20 +1535,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1566,20 +1563,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1597,7 +1594,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1642,6 +1642,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif
index 376d42a07..424eccf83 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif
@@ -771,13 +771,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -789,20 +786,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -814,20 +811,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -842,20 +839,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -873,20 +870,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -901,20 +898,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -926,20 +923,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -954,20 +951,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -988,20 +985,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1019,20 +1016,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1044,20 +1041,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1075,20 +1072,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1100,20 +1097,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1128,20 +1125,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1162,17 +1159,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1184,17 +1181,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1206,17 +1203,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1231,17 +1228,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1256,17 +1253,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1278,17 +1275,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1300,17 +1297,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1322,17 +1319,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1344,17 +1341,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1366,17 +1363,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1388,17 +1385,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1416,17 +1413,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1438,17 +1435,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1460,17 +1457,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1485,20 +1482,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1516,20 +1513,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1541,20 +1538,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1569,20 +1566,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1600,7 +1597,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1645,6 +1645,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif
index b44604fdf..f2d68c0aa 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif
@@ -785,13 +785,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -803,20 +800,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -828,20 +825,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -856,20 +853,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -887,20 +884,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -915,20 +912,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -940,20 +937,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -968,20 +965,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1002,20 +999,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1033,20 +1030,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1058,20 +1055,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1092,17 +1089,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1114,17 +1111,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1136,17 +1133,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1161,17 +1158,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1186,17 +1183,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1208,17 +1205,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1230,17 +1227,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1252,17 +1249,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1274,17 +1271,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1296,17 +1293,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1318,17 +1315,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1418,17 +1415,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1443,20 +1440,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1474,20 +1471,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1505,20 +1502,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1530,20 +1527,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1558,20 +1555,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1583,20 +1580,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1611,20 +1608,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1642,7 +1639,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1667,6 +1667,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif
index 9e46dd05b..42594fd5a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif
@@ -788,13 +788,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +803,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +828,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +856,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +887,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +915,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +940,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +968,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1002,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1033,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1058,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1089,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1123,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1145,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1167,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1192,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1217,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1239,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1261,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1283,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1305,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1327,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1349,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1377,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1399,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1421,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1449,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1474,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1505,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1530,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1558,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1583,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1611,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,7 +1642,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1670,6 +1670,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif
index 3a5b828e6..746bbff38 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif
@@ -790,13 +790,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -833,20 +830,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -861,20 +858,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -892,20 +889,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -920,20 +917,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -945,20 +942,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -973,20 +970,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1038,20 +1035,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1063,20 +1060,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1088,20 +1085,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1116,20 +1113,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1150,17 +1147,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1172,17 +1169,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1194,17 +1191,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1219,17 +1216,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1244,17 +1241,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1266,17 +1263,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1288,17 +1285,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1310,17 +1307,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1332,17 +1329,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1354,17 +1351,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1376,17 +1373,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1404,17 +1401,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1426,17 +1423,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1448,17 +1445,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1476,17 +1473,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1501,20 +1498,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1532,20 +1529,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1563,20 +1560,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1588,20 +1585,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1616,20 +1613,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1647,7 +1644,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1672,6 +1672,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif
index 8542a50c3..409780d31 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif
@@ -791,13 +791,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -862,20 +859,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -921,20 +918,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -946,20 +943,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1064,20 +1061,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1095,20 +1092,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1129,17 +1126,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1151,17 +1148,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1173,17 +1170,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1198,17 +1195,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1223,17 +1220,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1245,17 +1242,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1267,17 +1264,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1289,17 +1286,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1311,17 +1308,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1333,17 +1330,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1355,17 +1352,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1383,17 +1380,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1405,17 +1402,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1427,17 +1424,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1480,20 +1477,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1511,20 +1508,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1564,20 +1561,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1586,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1614,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,7 +1645,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1673,6 +1673,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif
index 0c6ea83fa..425c672a8 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif
@@ -791,13 +791,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -862,20 +859,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -921,20 +918,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -946,20 +943,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1064,20 +1061,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1095,20 +1092,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1129,17 +1126,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1151,17 +1148,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1173,17 +1170,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1198,17 +1195,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1223,17 +1220,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1245,17 +1242,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1267,17 +1264,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1289,17 +1286,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1311,17 +1308,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1333,17 +1330,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1355,17 +1352,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1383,17 +1380,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1405,17 +1402,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1427,17 +1424,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1480,20 +1477,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1511,20 +1508,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1564,20 +1561,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1586,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1614,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,7 +1645,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1673,6 +1673,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif
index 41f311b97..5e422baa5 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -839,20 +836,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -870,20 +867,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -898,20 +895,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -923,20 +920,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -951,20 +948,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1016,20 +1013,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1041,20 +1038,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1106,17 +1103,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1128,17 +1125,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1150,17 +1147,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1175,17 +1172,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1200,17 +1197,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1222,17 +1219,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1244,17 +1241,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1266,17 +1263,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1288,17 +1285,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1310,17 +1307,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1332,17 +1329,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1360,17 +1357,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1382,17 +1379,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1404,17 +1401,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1429,20 +1426,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1460,20 +1457,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1485,20 +1482,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1513,20 +1510,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1538,20 +1535,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1566,20 +1563,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1597,7 +1594,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1642,6 +1642,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif
index d8dc2e5b8..c4762c40d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif
@@ -791,13 +791,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -862,20 +859,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -921,20 +918,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -946,20 +943,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1064,20 +1061,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1095,20 +1092,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1129,17 +1126,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1151,17 +1148,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1173,17 +1170,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1198,17 +1195,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1223,17 +1220,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1245,17 +1242,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1267,17 +1264,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1289,17 +1286,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1311,17 +1308,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1333,17 +1330,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1355,17 +1352,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1383,17 +1380,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1405,17 +1402,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1427,17 +1424,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1480,20 +1477,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1511,20 +1508,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1564,20 +1561,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1586,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1614,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,7 +1645,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1673,6 +1673,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif
index baace4b16..07122911d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif
@@ -791,13 +791,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -862,20 +859,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -921,20 +918,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -946,20 +943,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1064,20 +1061,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1095,20 +1092,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1129,17 +1126,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1151,17 +1148,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1173,17 +1170,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1198,17 +1195,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1223,17 +1220,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1245,17 +1242,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1267,17 +1264,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1289,17 +1286,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1311,17 +1308,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1333,17 +1330,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1355,17 +1352,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1383,17 +1380,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1405,17 +1402,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1427,17 +1424,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1480,20 +1477,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1511,20 +1508,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1564,20 +1561,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1586,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1614,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,7 +1645,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1673,6 +1673,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif
index 0520c9879..ae31c8c2f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif
@@ -791,13 +791,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -862,20 +859,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -921,20 +918,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -946,20 +943,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1064,20 +1061,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1095,20 +1092,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1129,17 +1126,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1151,17 +1148,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1173,17 +1170,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1198,17 +1195,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1223,17 +1220,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1245,17 +1242,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1267,17 +1264,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1289,17 +1286,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1311,17 +1308,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1333,17 +1330,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1355,17 +1352,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1383,17 +1380,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1405,17 +1402,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1427,17 +1424,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1480,20 +1477,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1511,20 +1508,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1564,20 +1561,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1586,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1614,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,7 +1645,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1673,6 +1673,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif
index d2d9e2629..5451af733 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif
@@ -791,13 +791,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -862,20 +859,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -921,20 +918,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -946,20 +943,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1064,20 +1061,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1095,20 +1092,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1129,17 +1126,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1151,17 +1148,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1173,17 +1170,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1198,17 +1195,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1223,17 +1220,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1245,17 +1242,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1267,17 +1264,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1289,17 +1286,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1311,17 +1308,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1333,17 +1330,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1355,17 +1352,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1383,17 +1380,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1405,17 +1402,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1427,17 +1424,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1480,20 +1477,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1511,20 +1508,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1564,20 +1561,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1586,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1614,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,7 +1645,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1673,6 +1673,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif
index ae52f39d6..28542b0c5 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -839,20 +836,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -870,20 +867,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -898,20 +895,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -923,20 +920,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -951,20 +948,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1016,20 +1013,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1041,20 +1038,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1106,17 +1103,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1128,17 +1125,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1150,17 +1147,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1175,17 +1172,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1200,17 +1197,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1222,17 +1219,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1244,17 +1241,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1266,17 +1263,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1288,17 +1285,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1310,17 +1307,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1332,17 +1329,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1360,17 +1357,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1382,17 +1379,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1404,17 +1401,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1429,20 +1426,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1460,20 +1457,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1485,20 +1482,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1513,20 +1510,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1538,20 +1535,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1566,20 +1563,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1597,7 +1594,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1642,6 +1642,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif
index 6e6aafd03..bff3c2ac8 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif
@@ -791,13 +791,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -862,20 +859,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -921,20 +918,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -946,20 +943,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1064,20 +1061,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1095,20 +1092,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1129,17 +1126,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1151,17 +1148,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1173,17 +1170,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1198,17 +1195,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1223,17 +1220,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1245,17 +1242,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1267,17 +1264,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1289,17 +1286,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1311,17 +1308,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1333,17 +1330,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1355,17 +1352,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1383,17 +1380,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1405,17 +1402,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1427,17 +1424,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1480,20 +1477,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1511,20 +1508,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1564,20 +1561,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1586,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1614,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,7 +1645,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1673,6 +1673,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif
index f803bb07c..8838bed96 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif
@@ -791,13 +791,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -862,20 +859,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -921,20 +918,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -946,20 +943,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1064,20 +1061,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1095,20 +1092,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1129,17 +1126,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1151,17 +1148,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1173,17 +1170,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1198,17 +1195,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1223,17 +1220,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1245,17 +1242,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1267,17 +1264,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1289,17 +1286,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1311,17 +1308,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1333,17 +1330,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1355,17 +1352,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1383,17 +1380,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1405,17 +1402,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1427,17 +1424,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1480,20 +1477,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1511,20 +1508,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1564,20 +1561,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1586,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1614,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,7 +1645,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1673,6 +1673,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif
index 8118c6ca6..5bdec020b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif
@@ -788,13 +788,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +803,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +828,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +856,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +887,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +915,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +940,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +968,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1002,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1033,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1058,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1089,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1123,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1145,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1167,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1192,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1217,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1239,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1261,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1283,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1305,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1327,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1349,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1377,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1399,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1421,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1449,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1474,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1505,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1530,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1558,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1583,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1611,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,7 +1642,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1670,6 +1670,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif
index 98061a657..a90dc7ec7 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif
@@ -788,13 +788,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +803,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +828,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +856,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +887,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +915,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +940,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +968,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1002,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1033,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1058,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1089,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1123,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1145,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1167,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1192,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1217,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1239,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1261,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1283,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1305,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1327,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1349,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1377,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1399,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1421,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1449,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1474,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1505,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1530,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1558,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1583,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1611,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,7 +1642,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1670,6 +1670,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif
index 95a41397e..6b7d4c235 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif
@@ -789,13 +789,10 @@
           "rules": [
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -810,20 +807,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -841,20 +838,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -866,20 +863,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -894,20 +891,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -922,17 +919,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -947,17 +944,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -969,17 +966,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -991,17 +988,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1013,17 +1010,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1035,17 +1032,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1057,17 +1054,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1079,17 +1076,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1107,17 +1104,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1129,17 +1126,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1151,17 +1148,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1173,20 +1170,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1198,20 +1195,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1229,17 +1226,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1254,20 +1251,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1282,20 +1279,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1313,20 +1310,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1344,20 +1341,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1369,20 +1366,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1397,20 +1394,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1431,20 +1428,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1462,20 +1459,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1487,20 +1484,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1512,20 +1509,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1540,20 +1537,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1571,17 +1568,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1602,17 +1599,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1624,17 +1621,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1646,7 +1643,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1671,6 +1671,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif
index 84d8f59c3..61a2ac74f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif
@@ -548,13 +548,10 @@
           "rules": [
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -569,20 +566,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -594,20 +591,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -622,20 +619,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -650,17 +647,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -675,17 +672,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -697,17 +694,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -719,17 +716,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -741,17 +738,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -763,17 +760,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -785,17 +782,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -807,17 +804,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -835,17 +832,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -857,17 +854,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -879,17 +876,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -901,20 +898,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -929,20 +926,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -960,20 +957,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1019,20 +1016,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1050,20 +1047,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1075,20 +1072,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1134,7 +1131,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1179,6 +1179,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif
index c7a7030bc..5e2b8f9df 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif
@@ -787,13 +787,10 @@
           "rules": [
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -808,20 +805,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -833,20 +830,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -861,20 +858,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -889,17 +886,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -914,17 +911,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -936,17 +933,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -958,17 +955,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -980,17 +977,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1002,17 +999,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1024,17 +1021,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1046,17 +1043,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1074,17 +1071,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1096,17 +1093,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1118,17 +1115,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1140,20 +1137,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1165,20 +1162,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1196,17 +1193,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1221,20 +1218,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1249,20 +1246,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1280,20 +1277,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1311,20 +1308,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1336,20 +1333,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1364,20 +1361,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1398,20 +1395,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1429,20 +1426,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1454,20 +1451,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1485,20 +1482,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1510,20 +1507,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1538,20 +1535,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1569,17 +1566,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1600,17 +1597,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1622,17 +1619,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1644,7 +1641,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1669,6 +1669,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
index 13441c362..62f8441bc 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
@@ -790,13 +790,10 @@
           "rules": [
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -811,20 +808,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -842,20 +839,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -867,20 +864,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -923,17 +920,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -948,17 +945,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -970,17 +967,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -992,17 +989,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1014,17 +1011,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1036,17 +1033,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1058,17 +1055,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1080,17 +1077,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1108,17 +1105,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1130,17 +1127,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1152,17 +1149,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1174,20 +1171,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1199,20 +1196,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1230,17 +1227,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1255,20 +1252,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1283,20 +1280,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1314,20 +1311,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1345,20 +1342,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1370,20 +1367,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1398,20 +1395,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1432,20 +1429,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1463,20 +1460,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1488,20 +1485,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1513,20 +1510,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1541,20 +1538,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1603,17 +1600,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1625,17 +1622,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1647,7 +1644,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1672,6 +1672,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
index dabf629dd..c4872d266 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
@@ -790,13 +790,10 @@
           "rules": [
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -811,20 +808,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -842,20 +839,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -867,20 +864,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -923,17 +920,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -948,17 +945,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -970,17 +967,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -992,17 +989,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1014,17 +1011,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1036,17 +1033,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1058,17 +1055,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1080,17 +1077,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1108,17 +1105,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1130,17 +1127,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1152,17 +1149,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1174,20 +1171,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1199,20 +1196,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1230,17 +1227,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1255,20 +1252,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1283,20 +1280,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1314,20 +1311,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1345,20 +1342,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1370,20 +1367,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1398,20 +1395,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1432,20 +1429,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1463,20 +1460,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1488,20 +1485,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1513,20 +1510,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1541,20 +1538,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1603,17 +1600,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1625,17 +1622,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1647,7 +1644,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1672,6 +1672,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
index 714196152..31a81fb66 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
@@ -790,13 +790,10 @@
           "rules": [
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -811,20 +808,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -842,20 +839,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -867,20 +864,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -923,17 +920,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -948,17 +945,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -970,17 +967,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -992,17 +989,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1014,17 +1011,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1036,17 +1033,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1058,17 +1055,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1080,17 +1077,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1108,17 +1105,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1130,17 +1127,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1152,17 +1149,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1174,20 +1171,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1199,20 +1196,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1230,17 +1227,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1255,20 +1252,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1283,20 +1280,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1314,20 +1311,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1345,20 +1342,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1370,20 +1367,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1398,20 +1395,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1432,20 +1429,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1463,20 +1460,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1488,20 +1485,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1513,20 +1510,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1541,20 +1538,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1603,17 +1600,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1625,17 +1622,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1647,7 +1644,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1672,6 +1672,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
index 8e43b9e59..7c214e370 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
@@ -550,13 +550,10 @@
           "rules": [
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -571,20 +568,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -602,20 +599,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -627,20 +624,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -655,20 +652,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -683,17 +680,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -708,17 +705,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -730,17 +727,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -752,17 +749,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -774,17 +771,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -796,17 +793,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -818,17 +815,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -840,17 +837,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -868,17 +865,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -890,17 +887,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -912,17 +909,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -934,20 +931,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -962,20 +959,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -993,20 +990,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1018,20 +1015,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1052,20 +1049,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1077,20 +1074,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1105,20 +1102,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1136,7 +1133,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1181,6 +1181,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif
index 15b954d5f..919eb0d23 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif
@@ -784,13 +784,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -802,20 +799,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -830,20 +827,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -858,17 +855,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -883,17 +880,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -905,17 +902,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -927,17 +924,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -949,17 +946,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -971,17 +968,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -993,17 +990,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1015,17 +1012,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1043,17 +1040,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1065,17 +1062,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1087,17 +1084,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1109,20 +1106,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1140,17 +1137,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1165,20 +1162,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1193,20 +1190,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1224,20 +1221,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1255,20 +1252,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1280,20 +1277,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1308,20 +1305,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1342,20 +1339,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1373,20 +1370,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1398,20 +1395,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1429,20 +1426,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1454,20 +1451,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1482,20 +1479,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1507,20 +1504,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1535,20 +1532,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1566,17 +1563,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1597,17 +1594,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1619,17 +1616,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1641,7 +1638,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1666,6 +1666,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif
index fab135633..9ab35211b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif
@@ -548,13 +548,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -566,20 +563,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -594,20 +591,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -625,20 +622,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -653,17 +650,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -678,17 +675,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -700,17 +697,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -722,17 +719,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -744,17 +741,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -766,17 +763,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -788,17 +785,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -810,17 +807,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -838,17 +835,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -860,17 +857,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -882,17 +879,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -907,20 +904,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -938,20 +935,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -963,20 +960,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -997,20 +994,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1022,20 +1019,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1050,20 +1047,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1075,20 +1072,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1134,7 +1131,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1179,6 +1179,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif
index cf6a8bc4d..970d913bd 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif
@@ -784,13 +784,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -802,20 +799,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -830,20 +827,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -858,17 +855,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -883,17 +880,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -905,17 +902,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -927,17 +924,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -949,17 +946,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -971,17 +968,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -993,17 +990,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1015,17 +1012,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1043,17 +1040,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1065,17 +1062,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1087,17 +1084,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1109,20 +1106,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1140,17 +1137,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1165,20 +1162,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1193,20 +1190,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1224,20 +1221,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1255,20 +1252,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1280,20 +1277,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1308,20 +1305,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1342,20 +1339,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1373,20 +1370,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1398,20 +1395,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1429,20 +1426,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1454,20 +1451,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1482,20 +1479,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1507,20 +1504,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1535,20 +1532,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1566,17 +1563,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1597,17 +1594,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1619,17 +1616,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1641,7 +1638,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1666,6 +1666,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif
index 19fdf00ea..b06af7739 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif
@@ -770,13 +770,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -788,20 +785,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -813,20 +810,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -841,20 +838,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -872,20 +869,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -900,20 +897,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -928,20 +925,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -962,20 +959,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -993,20 +990,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1018,20 +1015,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1049,20 +1046,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1074,20 +1071,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1102,20 +1099,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1136,17 +1133,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1158,17 +1155,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1180,17 +1177,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1205,17 +1202,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1230,17 +1227,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1252,17 +1249,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1274,17 +1271,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1296,17 +1293,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1318,17 +1315,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1340,17 +1337,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1362,17 +1359,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1459,20 +1456,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1490,20 +1487,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1515,20 +1512,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1540,20 +1537,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1568,20 +1565,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1599,7 +1596,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1644,6 +1644,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif
index 66059aa34..1a0b2f52f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif
@@ -791,13 +791,10 @@
           "rules": [
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -812,20 +809,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -843,20 +840,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -868,20 +865,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -896,20 +893,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -924,17 +921,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -949,17 +946,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -971,17 +968,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -993,17 +990,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1015,17 +1012,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1037,17 +1034,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1059,17 +1056,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1081,17 +1078,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1109,17 +1106,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1131,17 +1128,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1153,17 +1150,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1175,20 +1172,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1200,20 +1197,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1231,17 +1228,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1256,20 +1253,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1284,20 +1281,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1315,20 +1312,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1346,20 +1343,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1371,20 +1368,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1399,20 +1396,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1433,20 +1430,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1464,20 +1461,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1489,20 +1486,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1514,20 +1511,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1542,20 +1539,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1573,17 +1570,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1604,17 +1601,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1626,17 +1623,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1648,7 +1645,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1673,6 +1673,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif
index 9032c9d7f..59b669cea 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif
@@ -770,13 +770,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -788,20 +785,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -813,20 +810,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -841,20 +838,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -872,20 +869,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -900,20 +897,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -928,20 +925,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -962,20 +959,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -993,20 +990,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1018,20 +1015,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1049,20 +1046,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1074,20 +1071,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1102,20 +1099,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1136,17 +1133,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1158,17 +1155,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1180,17 +1177,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1205,17 +1202,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1230,17 +1227,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1252,17 +1249,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1274,17 +1271,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1296,17 +1293,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1318,17 +1315,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1340,17 +1337,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1362,17 +1359,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1459,20 +1456,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1490,20 +1487,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1515,20 +1512,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1540,20 +1537,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1568,20 +1565,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1599,7 +1596,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1644,6 +1644,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif
index d871a6de1..1fd5f10a1 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif
@@ -788,13 +788,10 @@
           "rules": [
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -812,20 +809,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -837,20 +834,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -865,20 +862,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -893,17 +890,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -918,17 +915,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -940,17 +937,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -962,17 +959,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -984,17 +981,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1006,17 +1003,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1028,17 +1025,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1050,17 +1047,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1078,17 +1075,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1100,17 +1097,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1122,17 +1119,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1144,20 +1141,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1169,20 +1166,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1200,17 +1197,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1225,20 +1222,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1253,20 +1250,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1284,20 +1281,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1312,20 +1309,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1343,20 +1340,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1368,20 +1365,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1396,20 +1393,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1430,20 +1427,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1461,20 +1458,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1486,20 +1483,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1511,20 +1508,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1539,20 +1536,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1570,17 +1567,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1601,17 +1598,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1623,17 +1620,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1645,7 +1642,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1670,6 +1670,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif
index a806bccd9..d337b9ff2 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif
@@ -547,13 +547,10 @@
           "rules": [
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -571,20 +568,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -596,20 +593,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -624,20 +621,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -652,17 +649,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -677,17 +674,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -699,17 +696,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -721,17 +718,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -743,17 +740,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -765,17 +762,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -787,17 +784,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -809,17 +806,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -837,17 +834,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -859,17 +856,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -881,17 +878,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -903,20 +900,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -931,20 +928,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -959,20 +956,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -990,20 +987,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1015,20 +1012,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1049,20 +1046,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1074,20 +1071,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1102,20 +1099,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1133,7 +1130,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1178,6 +1178,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
index 054c162aa..740d26351 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
@@ -787,13 +787,10 @@
           "rules": [
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -836,20 +833,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -892,17 +889,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -917,17 +914,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -939,17 +936,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -961,17 +958,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -983,17 +980,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1005,17 +1002,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1027,17 +1024,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1049,17 +1046,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1077,17 +1074,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1099,17 +1096,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1121,17 +1118,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1143,20 +1140,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1168,20 +1165,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1199,17 +1196,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1224,20 +1221,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1252,20 +1249,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1283,20 +1280,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1311,20 +1308,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1342,20 +1339,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1367,20 +1364,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1395,20 +1392,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1429,20 +1426,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1460,20 +1457,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1485,20 +1482,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1510,20 +1507,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1538,20 +1535,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1569,17 +1566,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1600,17 +1597,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1622,17 +1619,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1644,7 +1641,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1669,6 +1669,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
index d1c5f94b6..a312bbe48 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -792,20 +789,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -817,20 +814,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -845,20 +842,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -873,17 +870,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -898,17 +895,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -920,17 +917,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -942,17 +939,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -964,17 +961,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -986,17 +983,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1008,17 +1005,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1030,17 +1027,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1058,17 +1055,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1080,17 +1077,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1102,17 +1099,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1124,20 +1121,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1149,20 +1146,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1180,17 +1177,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1205,20 +1202,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1233,20 +1230,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1264,20 +1261,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1292,20 +1289,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1323,20 +1320,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1348,20 +1345,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1376,20 +1373,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1410,20 +1407,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1441,20 +1438,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1466,20 +1463,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1491,20 +1488,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1519,20 +1516,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1550,17 +1547,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1581,17 +1578,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1603,17 +1600,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1625,7 +1622,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1650,6 +1650,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
index 6e7945105..e0b79a3a0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
@@ -787,13 +787,10 @@
           "rules": [
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -836,20 +833,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -892,17 +889,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -917,17 +914,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -939,17 +936,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -961,17 +958,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -983,17 +980,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1005,17 +1002,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1027,17 +1024,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1049,17 +1046,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1077,17 +1074,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1099,17 +1096,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1121,17 +1118,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1143,20 +1140,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1168,20 +1165,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1199,17 +1196,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1224,20 +1221,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1252,20 +1249,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1283,20 +1280,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1311,20 +1308,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1342,20 +1339,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1367,20 +1364,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1395,20 +1392,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1429,20 +1426,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1460,20 +1457,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1485,20 +1482,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1510,20 +1507,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1538,20 +1535,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1569,17 +1566,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1600,17 +1597,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1622,17 +1619,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1644,7 +1641,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1669,6 +1669,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
index 8a4f25a9b..889776c6f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
@@ -547,13 +547,10 @@
           "rules": [
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -571,20 +568,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -596,20 +593,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -624,20 +621,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -652,17 +649,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -677,17 +674,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -699,17 +696,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -721,17 +718,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -743,17 +740,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -765,17 +762,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -787,17 +784,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -809,17 +806,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -837,17 +834,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -859,17 +856,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -881,17 +878,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -903,20 +900,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -931,20 +928,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -959,20 +956,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -990,20 +987,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1015,20 +1012,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1049,20 +1046,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1074,20 +1071,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1102,20 +1099,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1133,7 +1130,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1178,6 +1178,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif
index 30520d43a..f3aa1ef58 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif
@@ -786,13 +786,10 @@
           "rules": [
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -804,20 +801,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -832,20 +829,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -860,17 +857,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -885,17 +882,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -907,17 +904,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -929,17 +926,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -951,17 +948,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -973,17 +970,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -995,17 +992,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1017,17 +1014,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1045,17 +1042,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1067,17 +1064,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1089,17 +1086,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1111,20 +1108,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1136,20 +1133,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1167,17 +1164,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1192,20 +1189,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1220,20 +1217,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1251,20 +1248,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1279,20 +1276,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1310,20 +1307,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1335,20 +1332,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1363,20 +1360,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1397,20 +1394,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1428,20 +1425,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1453,20 +1450,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1484,20 +1481,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1509,20 +1506,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1537,20 +1534,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1568,17 +1565,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1599,17 +1596,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1621,17 +1618,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1643,7 +1640,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1668,6 +1668,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif
index 9935e605a..70b6b30a1 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif
@@ -761,13 +761,10 @@
           "rules": [
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -779,20 +776,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -807,20 +804,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -835,17 +832,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -860,17 +857,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -882,17 +879,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -904,17 +901,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -926,17 +923,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -948,17 +945,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -970,17 +967,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -992,17 +989,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1020,17 +1017,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1042,17 +1039,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1064,17 +1061,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1086,20 +1083,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1111,20 +1108,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1142,17 +1139,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1167,20 +1164,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1195,20 +1192,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1226,20 +1223,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1254,20 +1251,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1285,20 +1282,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1310,20 +1307,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1338,20 +1335,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1372,20 +1369,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1403,20 +1400,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1428,20 +1425,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1459,20 +1456,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1484,20 +1481,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1512,20 +1509,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1543,17 +1540,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1574,17 +1571,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1596,17 +1593,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1618,7 +1615,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1643,6 +1643,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif
index 95879d033..c60f2fb69 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif
@@ -783,13 +783,10 @@
           "rules": [
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -801,20 +798,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -829,20 +826,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -857,17 +854,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -882,17 +879,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -904,17 +901,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -926,17 +923,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -948,17 +945,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -970,17 +967,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -992,17 +989,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1014,17 +1011,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1042,17 +1039,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1064,17 +1061,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1086,17 +1083,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1108,20 +1105,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1133,20 +1130,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1164,17 +1161,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1189,20 +1186,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1217,20 +1214,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1248,20 +1245,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1276,20 +1273,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1307,20 +1304,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1332,20 +1329,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1360,20 +1357,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1394,20 +1391,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1425,20 +1422,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1450,20 +1447,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1481,20 +1478,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1506,20 +1503,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1534,20 +1531,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1565,17 +1562,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1596,17 +1593,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1618,17 +1615,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1640,7 +1637,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1665,6 +1665,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif
index ccb761236..d2eb7b22d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif
@@ -783,13 +783,10 @@
           "rules": [
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -801,20 +798,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -829,20 +826,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -857,17 +854,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -882,17 +879,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -904,17 +901,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -926,17 +923,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -948,17 +945,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -970,17 +967,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -992,17 +989,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1014,17 +1011,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1042,17 +1039,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1064,17 +1061,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1086,17 +1083,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1108,20 +1105,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1133,20 +1130,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1164,17 +1161,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1189,20 +1186,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1217,20 +1214,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1248,20 +1245,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1276,20 +1273,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1307,20 +1304,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1332,20 +1329,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1360,20 +1357,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1394,20 +1391,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1425,20 +1422,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1450,20 +1447,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1481,20 +1478,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1506,20 +1503,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1534,20 +1531,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1565,17 +1562,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1596,17 +1593,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1618,17 +1615,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1640,7 +1637,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1665,6 +1665,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif
index 66eed0aa6..fbe4213d4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif
@@ -789,13 +789,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -807,20 +804,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -835,20 +832,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -866,20 +863,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -894,17 +891,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -919,17 +916,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -941,17 +938,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -963,17 +960,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -985,17 +982,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1007,17 +1004,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1029,17 +1026,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1051,17 +1048,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1079,17 +1076,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1101,17 +1098,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1123,17 +1120,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1145,20 +1142,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1176,17 +1173,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1201,20 +1198,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1229,20 +1226,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1260,20 +1257,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1291,20 +1288,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1316,20 +1313,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1344,20 +1341,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1378,20 +1375,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1409,20 +1406,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1434,20 +1431,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1459,20 +1456,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1487,20 +1484,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1512,20 +1509,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1540,20 +1537,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1571,17 +1568,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1602,17 +1599,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1624,17 +1621,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1646,7 +1643,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1671,6 +1671,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif
index 42bb4375c..9c26e0574 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif
@@ -789,13 +789,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -807,20 +804,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -835,20 +832,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -866,20 +863,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -894,17 +891,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -919,17 +916,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -941,17 +938,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -963,17 +960,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -985,17 +982,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1007,17 +1004,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1029,17 +1026,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1051,17 +1048,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1079,17 +1076,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1101,17 +1098,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1123,17 +1120,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1145,20 +1142,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1176,17 +1173,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1201,20 +1198,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1229,20 +1226,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1260,20 +1257,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1291,20 +1288,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1316,20 +1313,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1344,20 +1341,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1378,20 +1375,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1409,20 +1406,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1434,20 +1431,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1459,20 +1456,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1487,20 +1484,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1512,20 +1509,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1540,20 +1537,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1571,17 +1568,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1602,17 +1599,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1624,17 +1621,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1646,7 +1643,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1671,6 +1671,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif
index 929259100..c795810c2 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif
@@ -548,13 +548,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -566,20 +563,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -594,20 +591,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -625,20 +622,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -653,17 +650,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -678,17 +675,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -700,17 +697,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -722,17 +719,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -744,17 +741,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -766,17 +763,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -788,17 +785,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -810,17 +807,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -838,17 +835,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -860,17 +857,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -882,17 +879,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -907,20 +904,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -938,20 +935,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -963,20 +960,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -997,20 +994,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1022,20 +1019,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1050,20 +1047,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1075,20 +1072,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1134,7 +1131,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1179,6 +1179,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif
index b29612c1f..819864167 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif
@@ -793,13 +793,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -836,20 +833,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -923,20 +920,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -951,20 +948,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1016,20 +1013,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1041,20 +1038,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1097,20 +1094,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1125,20 +1122,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1159,17 +1156,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1181,17 +1178,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1203,17 +1200,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1228,17 +1225,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1253,17 +1250,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1275,17 +1272,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1297,17 +1294,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1319,17 +1316,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1341,17 +1338,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1363,17 +1360,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1385,17 +1382,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1413,17 +1410,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1435,17 +1432,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1457,17 +1454,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1485,17 +1482,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1510,20 +1507,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1541,20 +1538,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1566,20 +1563,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1591,20 +1588,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1619,20 +1616,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1650,7 +1647,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1675,6 +1675,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif
index 29983f715..ed35008ef 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif
@@ -785,13 +785,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -803,20 +800,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -862,17 +859,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -887,17 +884,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -909,17 +906,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -931,17 +928,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -953,17 +950,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -975,17 +972,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -997,17 +994,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1019,17 +1016,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1047,17 +1044,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1069,17 +1066,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1091,17 +1088,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1113,20 +1110,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1144,17 +1141,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1169,20 +1166,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1197,20 +1194,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1228,20 +1225,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1256,20 +1253,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1287,20 +1284,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1312,20 +1309,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1340,20 +1337,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1374,20 +1371,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1405,20 +1402,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1430,20 +1427,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1455,20 +1452,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1483,20 +1480,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1508,20 +1505,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1567,17 +1564,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1598,17 +1595,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1620,17 +1617,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1642,7 +1639,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1667,6 +1667,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif
index 13aff9024..2655b2e5d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif
@@ -770,13 +770,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -788,20 +785,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -813,20 +810,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -841,20 +838,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -872,20 +869,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -900,20 +897,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -928,20 +925,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -962,20 +959,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -993,20 +990,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1018,20 +1015,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1049,20 +1046,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1074,20 +1071,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1102,20 +1099,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1136,17 +1133,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1158,17 +1155,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1180,17 +1177,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1205,17 +1202,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1230,17 +1227,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1252,17 +1249,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1274,17 +1271,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1296,17 +1293,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1318,17 +1315,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1340,17 +1337,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1362,17 +1359,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1459,20 +1456,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1490,20 +1487,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1515,20 +1512,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1540,20 +1537,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1568,20 +1565,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1599,7 +1596,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1644,6 +1644,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif
index f4d840892..2cb1a3d62 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif
@@ -786,13 +786,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -804,20 +801,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -835,20 +832,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -863,17 +860,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -888,17 +885,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -910,17 +907,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -932,17 +929,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -954,17 +951,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -976,17 +973,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -998,17 +995,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1020,17 +1017,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1048,17 +1045,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1070,17 +1067,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1092,17 +1089,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1114,20 +1111,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1145,17 +1142,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1170,20 +1167,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1198,20 +1195,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1229,20 +1226,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1257,20 +1254,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1288,20 +1285,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1313,20 +1310,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1341,20 +1338,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1375,20 +1372,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1406,20 +1403,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1431,20 +1428,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1456,20 +1453,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1484,20 +1481,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1509,20 +1506,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1537,20 +1534,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1568,17 +1565,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1599,17 +1596,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1621,17 +1618,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1643,7 +1640,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1668,6 +1668,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif
index ad6747277..671bb1a69 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif
@@ -786,13 +786,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -804,20 +801,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -835,20 +832,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -863,17 +860,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -888,17 +885,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -910,17 +907,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -932,17 +929,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -954,17 +951,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -976,17 +973,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -998,17 +995,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1020,17 +1017,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1048,17 +1045,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1070,17 +1067,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1092,17 +1089,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1114,20 +1111,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1145,17 +1142,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1170,20 +1167,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1198,20 +1195,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1229,20 +1226,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1257,20 +1254,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1288,20 +1285,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1313,20 +1310,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1341,20 +1338,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1375,20 +1372,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1406,20 +1403,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1431,20 +1428,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1456,20 +1453,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1484,20 +1481,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1509,20 +1506,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1537,20 +1534,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1568,17 +1565,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1599,17 +1596,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1621,17 +1618,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1643,7 +1640,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1668,6 +1668,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif
index 7f9ace01e..21276b14c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif
@@ -546,13 +546,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -564,20 +561,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -595,20 +592,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -623,17 +620,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -648,17 +645,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -670,17 +667,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -692,17 +689,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -714,17 +711,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -736,17 +733,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -758,17 +755,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -780,17 +777,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -808,17 +805,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -830,17 +827,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -852,17 +849,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -877,20 +874,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -905,20 +902,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -936,20 +933,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -961,20 +958,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -995,20 +992,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1020,20 +1017,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1048,20 +1045,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1073,20 +1070,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1101,20 +1098,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1132,7 +1129,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1177,6 +1177,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif
index 815688fa4..63cff34d6 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif
@@ -785,13 +785,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -803,20 +800,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -862,17 +859,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -887,17 +884,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -909,17 +906,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -931,17 +928,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -953,17 +950,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -975,17 +972,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -997,17 +994,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1019,17 +1016,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1047,17 +1044,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1069,17 +1066,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1091,17 +1088,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1113,20 +1110,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1144,17 +1141,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1169,20 +1166,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1197,20 +1194,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1228,20 +1225,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1256,20 +1253,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1287,20 +1284,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1312,20 +1309,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1340,20 +1337,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1374,20 +1371,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1405,20 +1402,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1430,20 +1427,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1455,20 +1452,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1483,20 +1480,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1508,20 +1505,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1567,17 +1564,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1598,17 +1595,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1620,17 +1617,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1642,7 +1639,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1667,6 +1667,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif
index 4feb22244..848b1e3b0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif
@@ -796,13 +796,10 @@
           "rules": [
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -820,20 +817,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -845,20 +842,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -873,20 +870,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -907,17 +904,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -929,17 +926,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -951,17 +948,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -976,17 +973,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1001,17 +998,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1023,17 +1020,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1045,17 +1042,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1067,17 +1064,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1089,17 +1086,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1111,17 +1108,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1133,17 +1130,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1161,17 +1158,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1183,17 +1180,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1205,17 +1202,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1227,20 +1224,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1252,20 +1249,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1283,17 +1280,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1308,20 +1305,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1336,20 +1333,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1367,20 +1364,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1395,20 +1392,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1426,20 +1423,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1451,20 +1448,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1479,20 +1476,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1513,20 +1510,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1544,20 +1541,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1569,20 +1566,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1594,20 +1591,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1622,20 +1619,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1653,7 +1650,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1678,6 +1678,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif
index a5b456f82..8df82d0c4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif
@@ -624,13 +624,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -642,20 +639,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -670,20 +667,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -698,20 +695,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -732,20 +729,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -763,20 +760,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -788,20 +785,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -819,20 +816,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -847,20 +844,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -875,17 +872,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -900,17 +897,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -922,17 +919,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -944,17 +941,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -966,17 +963,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -988,17 +985,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1010,17 +1007,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1032,17 +1029,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1060,17 +1057,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1082,17 +1079,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1104,17 +1101,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1129,20 +1126,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1160,20 +1157,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1185,20 +1182,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1210,20 +1207,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1232,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1260,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,7 +1291,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1339,6 +1339,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif
index d356d8b5b..80e240961 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif
@@ -550,13 +550,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -568,20 +565,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -596,20 +593,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -627,20 +624,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -655,20 +652,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -683,17 +680,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -708,17 +705,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -730,17 +727,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -752,17 +749,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -774,17 +771,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -796,17 +793,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -818,17 +815,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -840,17 +837,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -868,17 +865,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -890,17 +887,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -912,17 +909,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -937,20 +934,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -968,20 +965,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -993,20 +990,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1027,20 +1024,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1052,20 +1049,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1077,20 +1074,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1105,20 +1102,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1136,7 +1133,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1181,6 +1181,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif
index 317a07eaa..2657e9c08 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif
@@ -790,13 +790,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -833,20 +830,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -861,20 +858,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -892,20 +889,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -920,20 +917,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -945,20 +942,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -973,20 +970,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1038,20 +1035,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1063,20 +1060,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1094,20 +1091,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1122,20 +1119,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1156,17 +1153,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1178,17 +1175,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1200,17 +1197,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1225,17 +1222,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1250,17 +1247,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1272,17 +1269,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1294,17 +1291,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1316,17 +1313,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1338,17 +1335,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1360,17 +1357,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1382,17 +1379,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1410,17 +1407,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1432,17 +1429,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1454,17 +1451,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1482,17 +1479,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1507,20 +1504,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1538,20 +1535,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1563,20 +1560,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1588,20 +1585,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1616,20 +1613,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1647,7 +1644,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1672,6 +1672,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif
index b2a40a893..7b49280a7 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif
@@ -788,13 +788,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +803,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +828,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +856,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +887,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +915,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +940,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +968,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1002,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1033,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1058,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1089,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1123,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1145,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1167,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1192,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1217,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1239,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1261,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1283,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1305,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1327,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1349,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1377,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1399,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1421,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1449,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1474,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1505,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1530,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1558,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1583,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1611,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,7 +1642,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1670,6 +1670,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif
index dc600b2a0..952b46338 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif
@@ -624,13 +624,10 @@
           "rules": [
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -645,20 +642,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -673,20 +670,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -707,20 +704,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -738,20 +735,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -763,20 +760,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -794,20 +791,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -819,20 +816,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -847,20 +844,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -875,17 +872,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -900,17 +897,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -922,17 +919,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -944,17 +941,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -966,17 +963,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -988,17 +985,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1010,17 +1007,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1032,17 +1029,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1060,17 +1057,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1082,17 +1079,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1104,17 +1101,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1126,20 +1123,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1154,20 +1151,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1185,20 +1182,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1210,20 +1207,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1232,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1260,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,7 +1291,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1339,6 +1339,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif
index a204b13bc..69ddf6274 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif
@@ -548,13 +548,10 @@
           "rules": [
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -569,20 +566,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -594,20 +591,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -622,20 +619,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -650,17 +647,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -675,17 +672,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -697,17 +694,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -719,17 +716,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -741,17 +738,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -763,17 +760,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -785,17 +782,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -807,17 +804,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -835,17 +832,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -857,17 +854,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -879,17 +876,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -901,20 +898,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -929,20 +926,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -960,20 +957,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1019,20 +1016,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1050,20 +1047,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1075,20 +1072,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1134,7 +1131,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1179,6 +1179,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif
index 0278ded2f..ed2e8e1e3 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif
@@ -794,13 +794,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -812,20 +809,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -843,20 +840,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -877,17 +874,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -899,17 +896,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -921,17 +918,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -946,17 +943,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -971,17 +968,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -993,17 +990,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1015,17 +1012,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1037,17 +1034,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1059,17 +1056,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1081,17 +1078,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1103,17 +1100,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1131,17 +1128,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1153,17 +1150,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1175,17 +1172,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1197,20 +1194,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1228,17 +1225,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1253,20 +1250,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1281,20 +1278,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1312,20 +1309,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1340,20 +1337,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1371,20 +1368,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1396,20 +1393,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1424,20 +1421,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1458,20 +1455,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1489,20 +1486,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1514,20 +1511,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1539,20 +1536,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1567,20 +1564,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1592,20 +1589,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1620,20 +1617,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1651,7 +1648,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1676,6 +1676,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif
index 50a1ecc3e..a8fb7089c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif
@@ -794,13 +794,10 @@
           "rules": [
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -812,20 +809,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -840,20 +837,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -874,17 +871,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -896,17 +893,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -918,17 +915,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -943,17 +940,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -968,17 +965,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -990,17 +987,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1012,17 +1009,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1034,17 +1031,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1056,17 +1053,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1078,17 +1075,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1100,17 +1097,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1128,17 +1125,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1150,17 +1147,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1172,17 +1169,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1194,20 +1191,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1219,20 +1216,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1250,17 +1247,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1275,20 +1272,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1303,20 +1300,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1334,20 +1331,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1362,20 +1359,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1393,20 +1390,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1418,20 +1415,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1446,20 +1443,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1480,20 +1477,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1511,20 +1508,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1536,20 +1533,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1567,20 +1564,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1592,20 +1589,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1620,20 +1617,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1651,7 +1648,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1676,6 +1676,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif
index b8fbf1d45..36a857b6b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif
@@ -622,13 +622,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -640,20 +637,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -668,20 +665,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -696,20 +693,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -730,20 +727,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -761,20 +758,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -817,20 +814,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -845,17 +842,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -870,17 +867,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -892,17 +889,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -914,17 +911,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -936,17 +933,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -958,17 +955,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -980,17 +977,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1002,17 +999,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1030,17 +1027,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1052,17 +1049,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1074,17 +1071,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1099,20 +1096,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1130,20 +1127,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1155,20 +1152,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1180,20 +1177,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1208,20 +1205,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1233,20 +1230,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1261,20 +1258,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1292,7 +1289,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1337,6 +1337,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif
index 48497a80d..9c85f2193 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif
@@ -548,13 +548,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -566,20 +563,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -594,20 +591,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -625,20 +622,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -653,17 +650,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -678,17 +675,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -700,17 +697,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -722,17 +719,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -744,17 +741,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -766,17 +763,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -788,17 +785,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -810,17 +807,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -838,17 +835,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -860,17 +857,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -882,17 +879,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -907,20 +904,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -938,20 +935,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -963,20 +960,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -997,20 +994,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1022,20 +1019,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1050,20 +1047,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1075,20 +1072,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1134,7 +1131,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1179,6 +1179,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif
index fa8670fd6..f78ae0aa5 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif
@@ -794,13 +794,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -812,20 +809,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -843,20 +840,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -877,17 +874,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -899,17 +896,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -921,17 +918,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -946,17 +943,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -971,17 +968,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -993,17 +990,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1015,17 +1012,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1037,17 +1034,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1059,17 +1056,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1081,17 +1078,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1103,17 +1100,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1131,17 +1128,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1153,17 +1150,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1175,17 +1172,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1197,20 +1194,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1228,17 +1225,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1253,20 +1250,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1281,20 +1278,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1312,20 +1309,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1340,20 +1337,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1371,20 +1368,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1396,20 +1393,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1424,20 +1421,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1458,20 +1455,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1489,20 +1486,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1514,20 +1511,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1539,20 +1536,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1567,20 +1564,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1592,20 +1589,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1620,20 +1617,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1651,7 +1648,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1676,6 +1676,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif
index 38aaad5c5..53a852bdd 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif
@@ -788,13 +788,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +803,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +828,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -862,17 +859,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -887,20 +884,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -918,20 +915,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -946,20 +943,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -974,20 +971,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1005,20 +1002,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1030,20 +1027,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1061,20 +1058,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1095,17 +1092,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1117,17 +1114,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1139,17 +1136,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1164,17 +1161,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1189,17 +1186,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1211,17 +1208,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1233,17 +1230,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1255,17 +1252,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1277,17 +1274,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1299,17 +1296,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1321,17 +1318,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1349,17 +1346,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1371,17 +1368,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1393,17 +1390,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1418,20 +1415,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1449,20 +1446,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1474,20 +1471,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1508,20 +1505,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1530,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1558,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1583,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1611,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,7 +1642,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1670,6 +1670,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif
index bbdc49129..1efe8af75 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -842,17 +839,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -867,20 +864,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -926,20 +923,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -954,20 +951,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1010,20 +1007,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1038,20 +1035,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1128,20 +1125,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1159,20 +1156,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1184,20 +1181,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1212,20 +1209,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1237,20 +1234,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1265,20 +1262,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1296,17 +1293,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1327,17 +1324,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1349,17 +1346,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1371,17 +1368,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1393,17 +1390,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1415,17 +1412,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1443,17 +1440,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1465,17 +1462,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1487,17 +1484,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1512,17 +1509,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1537,17 +1534,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1559,17 +1556,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1581,17 +1578,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1603,7 +1600,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1628,6 +1628,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif
index 7b2f7e84b..4dace2bce 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif
@@ -790,13 +790,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -833,20 +830,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -864,17 +861,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -889,20 +886,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -917,20 +914,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -948,20 +945,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -976,20 +973,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1032,20 +1029,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1060,20 +1057,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1094,20 +1091,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1125,20 +1122,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1150,20 +1147,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1181,20 +1178,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1206,20 +1203,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1234,20 +1231,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1259,20 +1256,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1287,20 +1284,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1318,17 +1315,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1349,17 +1346,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1371,17 +1368,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1393,17 +1390,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1415,17 +1412,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1437,17 +1434,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1465,17 +1462,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1487,17 +1484,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1509,17 +1506,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1534,17 +1531,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1559,17 +1556,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1581,17 +1578,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1603,17 +1600,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1625,17 +1622,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1647,7 +1644,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1672,6 +1672,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif
index 0e544ef02..2106596f9 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif
@@ -766,13 +766,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +781,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +837,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +862,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +921,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +949,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +980,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1033,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1067,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1098,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1123,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1154,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1179,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1207,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1232,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1260,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1291,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1322,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1344,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1366,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1388,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1410,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1441,17 +1438,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1463,17 +1460,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1485,17 +1482,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1510,17 +1507,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1535,17 +1532,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1557,17 +1554,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1579,17 +1576,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1601,7 +1598,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1626,6 +1626,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif
index 006f5ebd4..9ad06775e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif
@@ -767,13 +767,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -785,20 +782,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -810,20 +807,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -841,17 +838,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -866,20 +863,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -894,20 +891,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -925,20 +922,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -953,20 +950,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -984,20 +981,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1009,20 +1006,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1037,20 +1034,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1071,20 +1068,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1102,20 +1099,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1127,20 +1124,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1158,20 +1155,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1183,20 +1180,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1211,20 +1208,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1236,20 +1233,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1264,20 +1261,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1295,17 +1292,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1326,17 +1323,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1348,17 +1345,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1370,17 +1367,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1392,17 +1389,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1414,17 +1411,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1442,17 +1439,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1464,17 +1461,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1486,17 +1483,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1511,17 +1508,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1536,17 +1533,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1558,17 +1555,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1580,17 +1577,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1602,7 +1599,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1627,6 +1627,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif
index 2f71a5cf8..f97b4d9b7 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif
@@ -769,13 +769,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -787,20 +784,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -812,20 +809,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -843,17 +840,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -868,20 +865,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -896,20 +893,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -927,20 +924,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -955,20 +952,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -986,20 +983,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1011,20 +1008,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1073,20 +1070,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1104,20 +1101,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1129,20 +1126,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1160,20 +1157,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1185,20 +1182,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1213,20 +1210,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1238,20 +1235,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1266,20 +1263,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1297,17 +1294,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1328,17 +1325,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1350,17 +1347,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1372,17 +1369,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1394,17 +1391,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1416,17 +1413,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1444,17 +1441,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1466,17 +1463,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1488,17 +1485,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1513,17 +1510,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1538,17 +1535,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1560,17 +1557,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1582,17 +1579,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1604,7 +1601,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1629,6 +1629,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif
index 43b92a5a0..3932661a6 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -842,17 +839,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -867,20 +864,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -926,20 +923,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -954,20 +951,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1010,20 +1007,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1038,20 +1035,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1128,20 +1125,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1159,20 +1156,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1184,20 +1181,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1212,20 +1209,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1237,20 +1234,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1265,20 +1262,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1296,17 +1293,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1327,17 +1324,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1349,17 +1346,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1371,17 +1368,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1393,17 +1390,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1415,17 +1412,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1443,17 +1440,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1465,17 +1462,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1487,17 +1484,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1512,17 +1509,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1537,17 +1534,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1559,17 +1556,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1581,17 +1578,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1603,7 +1600,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1628,6 +1628,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif
index ed0c44d0c..8cd3417e8 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -842,17 +839,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -867,20 +864,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -926,20 +923,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -954,20 +951,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1010,20 +1007,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1038,20 +1035,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1128,20 +1125,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1159,20 +1156,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1184,20 +1181,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1212,20 +1209,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1237,20 +1234,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1265,20 +1262,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1296,17 +1293,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1327,17 +1324,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1349,17 +1346,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1371,17 +1368,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1393,17 +1390,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1415,17 +1412,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1443,17 +1440,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1465,17 +1462,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1487,17 +1484,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1512,17 +1509,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1537,17 +1534,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1559,17 +1556,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1581,17 +1578,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1603,7 +1600,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1628,6 +1628,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif
index e43b55a5d..2bf4e51a2 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -842,17 +839,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -867,20 +864,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -926,20 +923,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -954,20 +951,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1010,20 +1007,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1038,20 +1035,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1128,20 +1125,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1159,20 +1156,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1184,20 +1181,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1212,20 +1209,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1237,20 +1234,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1265,20 +1262,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1296,17 +1293,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1327,17 +1324,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1349,17 +1346,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1371,17 +1368,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1393,17 +1390,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1415,17 +1412,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1443,17 +1440,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1465,17 +1462,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1487,17 +1484,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1512,17 +1509,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1537,17 +1534,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1559,17 +1556,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1581,17 +1578,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1603,7 +1600,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1628,6 +1628,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif
index 46fb26cc1..fed7f4958 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif
@@ -769,13 +769,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -787,20 +784,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -812,20 +809,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -843,17 +840,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -868,20 +865,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -896,20 +893,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -927,20 +924,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -955,20 +952,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -986,20 +983,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1011,20 +1008,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1073,20 +1070,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1104,20 +1101,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1129,20 +1126,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1160,20 +1157,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1185,20 +1182,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1213,20 +1210,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1238,20 +1235,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1266,20 +1263,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1297,17 +1294,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1328,17 +1325,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1350,17 +1347,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1372,17 +1369,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1394,17 +1391,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1416,17 +1413,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1444,17 +1441,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1466,17 +1463,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1488,17 +1485,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1513,17 +1510,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1538,17 +1535,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1560,17 +1557,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1582,17 +1579,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1604,7 +1601,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1629,6 +1629,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif
index 02ef550bd..ad3165422 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -842,17 +839,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -867,20 +864,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -926,20 +923,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -954,20 +951,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1010,20 +1007,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1038,20 +1035,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1128,20 +1125,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1159,20 +1156,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1184,20 +1181,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1212,20 +1209,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1237,20 +1234,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1265,20 +1262,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1296,17 +1293,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1327,17 +1324,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1349,17 +1346,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1371,17 +1368,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1393,17 +1390,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1415,17 +1412,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1443,17 +1440,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1465,17 +1462,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1487,17 +1484,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1512,17 +1509,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1537,17 +1534,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1559,17 +1556,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1581,17 +1578,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1603,7 +1600,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1628,6 +1628,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif
index 0a41131de..eb72b4850 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif
@@ -780,13 +780,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -798,20 +795,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -823,20 +820,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -854,17 +851,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -879,20 +876,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -907,20 +904,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -938,20 +935,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -966,20 +963,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -997,20 +994,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1022,20 +1019,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1050,20 +1047,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1084,20 +1081,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1115,20 +1112,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1140,20 +1137,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1171,20 +1168,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1196,20 +1193,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1224,20 +1221,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1249,20 +1246,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1277,20 +1274,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1308,17 +1305,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1339,17 +1336,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1361,17 +1358,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1383,17 +1380,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1408,17 +1405,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1433,17 +1430,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1477,17 +1474,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1499,17 +1496,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1521,17 +1518,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1543,17 +1540,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1571,17 +1568,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1593,17 +1590,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1615,7 +1612,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             }
           ],
           "properties": {
@@ -1640,6 +1640,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif
index 0b2801743..62c28fec1 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif
@@ -769,13 +769,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -787,20 +784,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -812,20 +809,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -843,17 +840,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -868,20 +865,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -896,20 +893,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -927,20 +924,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -955,20 +952,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -986,20 +983,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1011,20 +1008,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1073,20 +1070,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1104,20 +1101,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1129,20 +1126,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1160,20 +1157,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1185,20 +1182,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1213,20 +1210,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1238,20 +1235,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1266,20 +1263,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1297,17 +1294,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1328,17 +1325,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1350,17 +1347,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1372,17 +1369,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1394,17 +1391,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1416,17 +1413,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1444,17 +1441,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1466,17 +1463,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1488,17 +1485,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1513,17 +1510,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1538,17 +1535,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1560,17 +1557,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1582,17 +1579,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1604,7 +1601,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1629,6 +1629,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif
index 68c182933..d8cf9c904 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -842,17 +839,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -867,20 +864,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -926,20 +923,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -954,20 +951,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1010,20 +1007,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1038,20 +1035,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1128,20 +1125,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1159,20 +1156,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1184,20 +1181,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1212,20 +1209,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1237,20 +1234,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1265,20 +1262,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1296,17 +1293,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1327,17 +1324,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1349,17 +1346,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1371,17 +1368,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1393,17 +1390,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1415,17 +1412,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1443,17 +1440,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1465,17 +1462,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1487,17 +1484,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1512,17 +1509,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1537,17 +1534,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1559,17 +1556,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1581,17 +1578,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1603,7 +1600,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1628,6 +1628,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif
index 7147c90cf..00a2a57b7 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif
@@ -767,13 +767,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -785,20 +782,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -810,20 +807,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -841,17 +838,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -866,20 +863,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -894,20 +891,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -925,20 +922,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -953,20 +950,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -984,20 +981,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1009,20 +1006,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1037,20 +1034,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1071,20 +1068,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1102,20 +1099,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1127,20 +1124,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1158,20 +1155,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1183,20 +1180,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1211,20 +1208,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1236,20 +1233,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1264,20 +1261,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1295,17 +1292,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1326,17 +1323,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1348,17 +1345,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1370,17 +1367,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1392,17 +1389,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1414,17 +1411,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1442,17 +1439,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1464,17 +1461,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1486,17 +1483,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1511,17 +1508,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1536,17 +1533,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1558,17 +1555,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1580,17 +1577,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1602,7 +1599,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1627,6 +1627,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif
index c48dcf63a..55e6791e6 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif
@@ -769,13 +769,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -787,20 +784,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -812,20 +809,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -843,17 +840,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -868,20 +865,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -896,20 +893,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -927,20 +924,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -955,20 +952,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -986,20 +983,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1011,20 +1008,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1073,20 +1070,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1104,20 +1101,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1129,20 +1126,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1160,20 +1157,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1185,20 +1182,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1213,20 +1210,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1238,20 +1235,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1266,20 +1263,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1297,17 +1294,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1328,17 +1325,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1350,17 +1347,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1372,17 +1369,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1394,17 +1391,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1416,17 +1413,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1444,17 +1441,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1466,17 +1463,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1488,17 +1485,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1513,17 +1510,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1538,17 +1535,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1560,17 +1557,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1582,17 +1579,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1604,7 +1601,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1629,6 +1629,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.a.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.a.sarif
index ef272b59e..f89139875 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.a.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.a.sarif
@@ -50,6 +50,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif
index 4a5305958..578b66b28 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -842,17 +839,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -867,20 +864,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -926,20 +923,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -954,20 +951,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1010,20 +1007,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1038,20 +1035,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1128,20 +1125,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1159,20 +1156,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1184,20 +1181,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1212,20 +1209,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1237,20 +1234,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1265,20 +1262,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1296,17 +1293,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1327,17 +1324,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1349,17 +1346,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1371,17 +1368,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1393,17 +1390,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1415,17 +1412,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1443,17 +1440,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1465,17 +1462,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1487,17 +1484,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1512,17 +1509,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1537,17 +1534,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1559,17 +1556,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1581,17 +1578,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1603,7 +1600,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1628,6 +1628,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif
index 2dc9dc91b..6e851b19b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif
@@ -769,13 +769,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -787,20 +784,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -812,20 +809,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -843,17 +840,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -868,20 +865,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -896,20 +893,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -927,20 +924,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -955,20 +952,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -986,20 +983,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1011,20 +1008,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1039,20 +1036,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1073,20 +1070,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1104,20 +1101,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1129,20 +1126,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1160,20 +1157,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1185,20 +1182,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1213,20 +1210,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1238,20 +1235,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1266,20 +1263,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1297,17 +1294,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1328,17 +1325,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1350,17 +1347,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1372,17 +1369,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1394,17 +1391,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1416,17 +1413,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1444,17 +1441,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1466,17 +1463,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1488,17 +1485,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1513,17 +1510,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1538,17 +1535,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1560,17 +1557,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1582,17 +1579,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1604,7 +1601,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             }
           ],
           "properties": {
@@ -1629,6 +1629,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif
index aa7b2be06..5b0b10f0a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif
@@ -428,13 +428,13 @@
         {
           "ruleId": "BA2006",
           "ruleIndex": 17,
-          "level": "error",
+          "kind": "pass",
+          "level": "none",
           "message": {
-            "id": "Error",
+            "id": "Pass",
             "arguments": [
               "clangcl.pe.cpp.codeview.exe",
-              "",
-              "clang version 13.0.0 : cxx : 13000.0.0.0 : [directly linked] (hello-d24821.obj)\r\n"
+              "Microsoft (R) Optimizing Compiler:C:19.26.28900.8, Microsoft (R) Optimizing Compiler:C:19.29.30034.2, Microsoft (R) Optimizing Compiler:Cxx:19.26.28900.8, Microsoft (R) Optimizing Compiler:Cxx:19.29.30034.2"
             ]
           },
           "locations": [
@@ -783,13 +783,10 @@
           "rules": [
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -801,20 +798,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -829,20 +826,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -857,17 +854,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -882,17 +879,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -904,17 +901,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -926,17 +923,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -948,17 +945,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -970,17 +967,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -992,17 +989,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1014,17 +1011,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1042,17 +1039,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1064,17 +1061,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1086,17 +1083,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1108,20 +1105,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1133,20 +1130,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1164,17 +1161,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1189,20 +1186,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1217,20 +1214,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1248,20 +1245,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1276,20 +1273,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1307,20 +1304,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1332,20 +1329,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1360,20 +1357,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1394,20 +1391,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1425,20 +1422,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1450,20 +1447,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1481,20 +1478,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1506,20 +1503,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1534,20 +1531,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1565,17 +1562,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1596,17 +1593,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1618,17 +1615,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1640,7 +1637,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             }
           ],
           "properties": {
@@ -1665,6 +1665,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif
index ce00f81c7..1d40f5b78 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif
@@ -765,13 +765,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +780,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +836,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +889,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +920,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +948,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +979,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1032,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1066,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1097,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1122,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1153,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1178,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1206,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1231,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1259,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1290,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1321,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1456,17 +1453,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1481,17 +1478,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1506,17 +1503,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1528,17 +1525,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1550,17 +1547,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1600,7 +1597,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1625,6 +1625,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif
index 21efb5993..e9da98295 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif
@@ -786,13 +786,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -804,20 +801,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -829,20 +826,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -860,17 +857,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -885,20 +882,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -913,20 +910,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -944,20 +941,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -972,20 +969,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1003,20 +1000,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1028,20 +1025,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1056,20 +1053,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1090,20 +1087,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1121,20 +1118,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1146,20 +1143,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1177,20 +1174,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1202,20 +1199,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1230,20 +1227,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1255,20 +1252,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1283,20 +1280,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1314,17 +1311,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1345,17 +1342,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1367,17 +1364,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1389,17 +1386,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1411,17 +1408,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1433,17 +1430,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1458,17 +1455,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1483,17 +1480,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1505,17 +1502,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1527,17 +1524,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1549,17 +1546,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1571,17 +1568,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1593,17 +1590,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1615,17 +1612,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1643,7 +1640,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1668,6 +1668,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif
index 4505ff73a..a1e549e32 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif
@@ -763,13 +763,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -781,20 +778,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -806,20 +803,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -837,17 +834,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -862,20 +859,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -890,20 +887,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -921,20 +918,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -949,20 +946,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -980,20 +977,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1005,20 +1002,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1033,20 +1030,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1067,20 +1064,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1098,20 +1095,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1123,20 +1120,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1154,20 +1151,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1179,20 +1176,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1207,20 +1204,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1232,20 +1229,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1260,20 +1257,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1291,17 +1288,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1322,17 +1319,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1344,17 +1341,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1366,17 +1363,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1388,17 +1385,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1410,17 +1407,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1432,17 +1429,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1454,17 +1451,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1479,17 +1476,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1504,17 +1501,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1526,17 +1523,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1548,17 +1545,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1570,17 +1567,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1598,7 +1595,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1623,6 +1623,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif
index dc34fe47e..ab9c258f9 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif
@@ -764,13 +764,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -782,20 +779,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -807,20 +804,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -838,17 +835,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -863,20 +860,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -891,20 +888,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -922,20 +919,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -950,20 +947,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -981,20 +978,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1006,20 +1003,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1034,20 +1031,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1068,20 +1065,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1099,20 +1096,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1124,20 +1121,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1155,20 +1152,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1180,20 +1177,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1208,20 +1205,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1233,20 +1230,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1261,20 +1258,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1292,17 +1289,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1323,17 +1320,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1345,17 +1342,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1367,17 +1364,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1389,17 +1386,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1411,17 +1408,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1433,17 +1430,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1480,17 +1477,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1505,17 +1502,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1527,17 +1524,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1549,17 +1546,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1571,17 +1568,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1599,7 +1596,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1624,6 +1624,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif
index f960deb6c..81fd266b3 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif
@@ -766,13 +766,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +781,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +837,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +862,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +921,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +949,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +980,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1033,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1067,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1098,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1123,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1154,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1179,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1207,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1232,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1260,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1291,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1322,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1344,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1366,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1388,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1410,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1435,17 +1432,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1457,17 +1454,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1482,17 +1479,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1507,17 +1504,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1529,17 +1526,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1551,17 +1548,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1573,17 +1570,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1601,7 +1598,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1626,6 +1626,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif
index 2cde19251..3ff12dfa9 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif
@@ -804,13 +804,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -822,20 +819,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -847,20 +844,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -878,17 +875,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -903,20 +900,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -931,20 +928,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -962,20 +959,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -990,20 +987,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1021,20 +1018,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1046,20 +1043,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1074,20 +1071,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1108,20 +1105,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1139,20 +1136,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1164,20 +1161,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1195,20 +1192,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1220,20 +1217,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1248,20 +1245,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1273,20 +1270,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1301,20 +1298,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1332,17 +1329,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1363,17 +1360,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1385,17 +1382,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1407,17 +1404,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1432,17 +1429,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1457,17 +1454,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1479,17 +1476,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1501,17 +1498,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1523,17 +1520,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1545,17 +1542,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1567,17 +1564,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1589,17 +1586,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1617,17 +1614,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1639,17 +1636,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1661,7 +1658,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             }
           ],
           "properties": {
@@ -1686,6 +1686,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif
index 8d9950746..11b0ddfd4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif
@@ -791,13 +791,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -834,20 +831,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -865,17 +862,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -890,20 +887,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -918,20 +915,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -949,20 +946,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -977,20 +974,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1033,20 +1030,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1061,20 +1058,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1095,20 +1092,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1126,20 +1123,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1151,20 +1148,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1182,20 +1179,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1207,20 +1204,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1235,20 +1232,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1260,20 +1257,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1288,20 +1285,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1319,17 +1316,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1350,17 +1347,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1372,17 +1369,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1394,17 +1391,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1416,17 +1413,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1438,17 +1435,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1460,17 +1457,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1482,17 +1479,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1507,17 +1504,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1532,17 +1529,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1554,17 +1551,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1576,17 +1573,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1598,17 +1595,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1620,17 +1617,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1648,7 +1645,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1673,6 +1673,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif
index 9ae289069..936dfd938 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif
@@ -786,13 +786,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -804,20 +801,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -829,20 +826,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -860,17 +857,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -885,20 +882,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -913,20 +910,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -944,20 +941,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -972,20 +969,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1003,20 +1000,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1028,20 +1025,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1056,20 +1053,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1090,20 +1087,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1121,20 +1118,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1146,20 +1143,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1177,20 +1174,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1202,20 +1199,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1230,20 +1227,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1255,20 +1252,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1283,20 +1280,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1314,17 +1311,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1345,17 +1342,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1367,17 +1364,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1389,17 +1386,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1411,17 +1408,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1433,17 +1430,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1458,17 +1455,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1483,17 +1480,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1505,17 +1502,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1527,17 +1524,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1549,17 +1546,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1571,17 +1568,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1593,17 +1590,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1615,17 +1612,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1643,7 +1640,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1668,6 +1668,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif
index 9d57a1972..18a6fcf49 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif
@@ -787,13 +787,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -805,20 +802,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -830,20 +827,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -861,17 +858,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -886,20 +883,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -914,20 +911,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -945,20 +942,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -973,20 +970,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1004,20 +1001,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1029,20 +1026,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1057,20 +1054,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1091,20 +1088,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1122,20 +1119,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1147,20 +1144,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1178,20 +1175,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1203,20 +1200,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1231,20 +1228,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1256,20 +1253,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1284,20 +1281,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1315,17 +1312,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1459,17 +1456,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1484,17 +1481,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1506,17 +1503,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1528,17 +1525,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1550,17 +1547,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1594,17 +1591,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1616,17 +1613,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1644,7 +1641,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1669,6 +1669,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif
index 9fdc9593e..c5fff30d4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif
@@ -785,13 +785,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -803,20 +800,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -828,20 +825,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -859,17 +856,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -884,20 +881,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -912,20 +909,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -943,20 +940,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -971,20 +968,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1002,20 +999,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1027,20 +1024,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1055,20 +1052,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1089,20 +1086,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1120,20 +1117,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1145,20 +1142,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1176,20 +1173,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1201,20 +1198,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1229,20 +1226,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1254,20 +1251,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1282,20 +1279,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1313,17 +1310,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1344,17 +1341,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1366,17 +1363,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1388,17 +1385,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1410,17 +1407,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1432,17 +1429,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1457,17 +1454,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1482,17 +1479,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1504,17 +1501,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1526,17 +1523,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1548,17 +1545,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1570,17 +1567,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1592,17 +1589,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1614,17 +1611,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1642,7 +1639,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1667,6 +1667,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif
index cf64d599b..8513c526d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif
@@ -768,13 +768,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +783,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +808,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -842,17 +839,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -867,20 +864,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -895,20 +892,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -926,20 +923,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -954,20 +951,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -985,20 +982,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1010,20 +1007,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1038,20 +1035,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1072,20 +1069,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1103,20 +1100,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1128,20 +1125,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1159,20 +1156,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1184,20 +1181,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1212,20 +1209,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1237,20 +1234,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1265,20 +1262,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1296,17 +1293,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1327,17 +1324,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1349,17 +1346,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1371,17 +1368,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1393,17 +1390,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1415,17 +1412,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1437,17 +1434,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1459,17 +1456,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1484,17 +1481,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1509,17 +1506,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1531,17 +1528,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1553,17 +1550,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1575,17 +1572,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1603,7 +1600,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1628,6 +1628,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif
index f5b8ac7a4..2592d3ea2 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif
@@ -787,13 +787,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -805,20 +802,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -830,20 +827,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -861,17 +858,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -886,20 +883,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -914,20 +911,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -945,20 +942,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -973,20 +970,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1004,20 +1001,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1029,20 +1026,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1057,20 +1054,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1091,20 +1088,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1122,20 +1119,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1147,20 +1144,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1178,20 +1175,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1203,20 +1200,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1231,20 +1228,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1256,20 +1253,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1284,20 +1281,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1315,17 +1312,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1459,17 +1456,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1484,17 +1481,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1506,17 +1503,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1528,17 +1525,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1550,17 +1547,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1594,17 +1591,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1616,17 +1613,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1644,7 +1641,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1669,6 +1669,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif
index a0c7aa7f8..1b13fc73c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif
@@ -766,13 +766,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +781,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +837,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +862,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +921,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +949,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +980,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1033,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1067,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1098,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1123,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1154,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1179,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1207,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1232,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1260,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1291,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1322,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1344,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1366,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1388,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1410,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1435,17 +1432,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1457,17 +1454,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1482,17 +1479,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1507,17 +1504,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1529,17 +1526,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1551,17 +1548,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1573,17 +1570,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1601,7 +1598,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1626,6 +1626,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif
index 35217331f..aed6007fa 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif
@@ -766,13 +766,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +781,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +837,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +862,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +921,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +949,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +980,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1033,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1067,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1098,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1123,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1154,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1179,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1207,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1232,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1260,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1291,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1322,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1344,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1366,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1388,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1410,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1435,17 +1432,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1457,17 +1454,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1482,17 +1479,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1507,17 +1504,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1529,17 +1526,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1551,17 +1548,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1573,17 +1570,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1601,7 +1598,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1626,6 +1626,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif
index 4ab87a2ac..d06cc2060 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif
@@ -765,13 +765,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +780,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +836,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +889,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +920,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +948,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +979,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1032,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1066,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1097,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1122,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1153,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1178,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1206,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1231,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1259,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1290,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1321,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1456,17 +1453,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1481,17 +1478,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1506,17 +1503,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1528,17 +1525,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1550,17 +1547,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1600,7 +1597,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1625,6 +1625,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif
index 4dcda324a..572620b5d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif
@@ -765,13 +765,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +780,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +836,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +889,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +920,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +948,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +979,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1032,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1066,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1097,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1122,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1153,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1178,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1206,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1231,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1259,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1290,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1321,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1456,17 +1453,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1481,17 +1478,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1506,17 +1503,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1528,17 +1525,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1550,17 +1547,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1600,7 +1597,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1625,6 +1625,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif
index e6498d366..18041a37d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif
@@ -765,13 +765,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +780,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +836,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +889,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +920,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +948,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +979,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1032,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1066,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1097,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1122,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1153,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1178,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1206,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1231,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1259,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1290,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1321,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1456,17 +1453,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1481,17 +1478,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1506,17 +1503,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1528,17 +1525,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1550,17 +1547,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1600,7 +1597,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1625,6 +1625,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif
index 47a394dca..a77beb456 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif
@@ -766,13 +766,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +781,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +837,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +862,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +921,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +949,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +980,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1033,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1067,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1098,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1123,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1154,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1179,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1207,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1232,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1260,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1291,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1322,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1344,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1366,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1388,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1410,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1435,17 +1432,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1457,17 +1454,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1482,17 +1479,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1507,17 +1504,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1529,17 +1526,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1551,17 +1548,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1573,17 +1570,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1601,7 +1598,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1626,6 +1626,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif
index 38e30ada3..2f262ac72 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif
@@ -765,13 +765,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +780,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +836,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +889,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +920,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +948,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +979,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1032,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1066,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1097,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1122,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1153,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1178,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1206,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1231,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1259,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1290,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1321,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1456,17 +1453,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1481,17 +1478,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1506,17 +1503,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1528,17 +1525,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1550,17 +1547,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1600,7 +1597,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1625,6 +1625,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif
index dc36e1ebe..f85e732f4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif
@@ -804,13 +804,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -822,20 +819,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -847,20 +844,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -878,17 +875,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -903,20 +900,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -931,20 +928,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -962,20 +959,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -990,20 +987,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1021,20 +1018,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1046,20 +1043,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1074,20 +1071,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1108,20 +1105,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1139,20 +1136,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1164,20 +1161,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1195,20 +1192,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1220,20 +1217,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1248,20 +1245,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1273,20 +1270,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1301,20 +1298,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1332,17 +1329,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1363,17 +1360,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1385,17 +1382,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1407,17 +1404,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1432,17 +1429,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1457,17 +1454,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1479,17 +1476,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1501,17 +1498,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1523,17 +1520,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1545,17 +1542,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1567,17 +1564,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1589,17 +1586,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1617,17 +1614,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1639,17 +1636,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1661,7 +1658,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             }
           ],
           "properties": {
@@ -1686,6 +1686,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif
index f5692be5b..ad4101d3d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif
@@ -764,13 +764,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -782,20 +779,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -807,20 +804,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -838,17 +835,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -863,20 +860,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -891,20 +888,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -922,20 +919,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -950,20 +947,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -981,20 +978,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1006,20 +1003,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1034,20 +1031,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1068,20 +1065,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1099,20 +1096,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1124,20 +1121,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1155,20 +1152,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1180,20 +1177,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1208,20 +1205,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1233,20 +1230,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1261,20 +1258,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1292,17 +1289,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1323,17 +1320,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1345,17 +1342,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1367,17 +1364,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1389,17 +1386,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1411,17 +1408,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1436,17 +1433,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1461,17 +1458,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1483,17 +1480,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1505,17 +1502,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1527,17 +1524,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1549,17 +1546,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1571,17 +1568,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1599,7 +1596,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1624,6 +1624,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif
index 2b889b4af..283ccc4c2 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif
@@ -780,13 +780,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -798,20 +795,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -823,20 +820,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -854,17 +851,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -879,20 +876,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -907,20 +904,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -938,20 +935,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -966,20 +963,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -997,20 +994,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1022,20 +1019,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1050,20 +1047,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1084,20 +1081,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1115,20 +1112,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1140,20 +1137,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1171,20 +1168,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1196,20 +1193,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1224,20 +1221,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1249,20 +1246,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1277,20 +1274,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1308,17 +1305,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1339,17 +1336,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1361,17 +1358,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1383,17 +1380,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1408,17 +1405,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1433,17 +1430,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1477,17 +1474,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1499,17 +1496,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1521,17 +1518,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1543,17 +1540,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1571,17 +1568,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1593,17 +1590,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1615,7 +1612,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             }
           ],
           "properties": {
@@ -1640,6 +1640,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif
index de066311b..336295499 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif
@@ -546,13 +546,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -564,20 +561,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -592,20 +589,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -623,20 +620,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -651,17 +648,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -676,17 +673,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -698,17 +695,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -720,17 +717,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -742,17 +739,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -764,17 +761,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -786,17 +783,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -808,17 +805,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -836,17 +833,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -858,17 +855,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -880,17 +877,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -905,20 +902,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -936,20 +933,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -961,20 +958,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -995,20 +992,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1020,20 +1017,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1048,20 +1045,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1073,20 +1070,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1101,20 +1098,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1132,7 +1129,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             }
           ],
           "properties": {
@@ -1177,6 +1177,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif
index 7a31b65dd..2262b817b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif
@@ -766,13 +766,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +781,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +837,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +862,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +921,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +949,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +980,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1033,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1067,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1098,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1123,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1154,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1179,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1207,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1232,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1260,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1291,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1322,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1344,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1366,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1388,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1410,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1435,17 +1432,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1457,17 +1454,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1482,17 +1479,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1507,17 +1504,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1529,17 +1526,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1551,17 +1548,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1573,17 +1570,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1601,7 +1598,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1626,6 +1626,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif
index 129304a9e..f1c44447a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif
@@ -765,13 +765,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +780,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +836,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +889,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +920,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +948,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +979,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1032,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1066,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1097,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1122,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1153,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1178,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1206,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1231,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1259,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1290,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1321,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1456,17 +1453,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1481,17 +1478,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1506,17 +1503,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1528,17 +1525,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1550,17 +1547,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1600,7 +1597,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1625,6 +1625,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif
index 71ffc0b1e..5fbb05e12 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif
@@ -764,13 +764,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -782,20 +779,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -807,20 +804,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -838,17 +835,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -863,20 +860,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -891,20 +888,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -922,20 +919,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -950,20 +947,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -981,20 +978,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1006,20 +1003,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1034,20 +1031,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1068,20 +1065,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1099,20 +1096,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1124,20 +1121,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1155,20 +1152,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1180,20 +1177,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1208,20 +1205,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1233,20 +1230,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1261,20 +1258,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1292,17 +1289,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1323,17 +1320,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1345,17 +1342,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1367,17 +1364,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1389,17 +1386,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1411,17 +1408,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1433,17 +1430,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1455,17 +1452,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1480,17 +1477,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1505,17 +1502,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1527,17 +1524,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1549,17 +1546,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1571,17 +1568,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1599,7 +1596,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1624,6 +1624,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif
index 50d43532d..312145eac 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif
@@ -786,13 +786,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -804,20 +801,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -829,20 +826,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -860,17 +857,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -885,20 +882,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -913,20 +910,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -944,20 +941,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -972,20 +969,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1003,20 +1000,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1028,20 +1025,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1056,20 +1053,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1090,20 +1087,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1121,20 +1118,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1146,20 +1143,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1177,20 +1174,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1202,20 +1199,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1230,20 +1227,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1255,20 +1252,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1283,20 +1280,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1314,17 +1311,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1345,17 +1342,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1367,17 +1364,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1389,17 +1386,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1411,17 +1408,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1433,17 +1430,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1458,17 +1455,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1483,17 +1480,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1505,17 +1502,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1527,17 +1524,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1549,17 +1546,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1571,17 +1568,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1593,17 +1590,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1615,17 +1612,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1643,7 +1640,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1668,6 +1668,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif
index 16028c0e8..843601633 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif
@@ -787,13 +787,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -805,20 +802,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -830,20 +827,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -861,17 +858,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -886,20 +883,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -914,20 +911,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -945,20 +942,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -973,20 +970,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1004,20 +1001,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1029,20 +1026,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1057,20 +1054,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1091,20 +1088,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1122,20 +1119,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1147,20 +1144,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1178,20 +1175,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1203,20 +1200,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1231,20 +1228,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1256,20 +1253,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1284,20 +1281,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1315,17 +1312,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1459,17 +1456,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1484,17 +1481,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1506,17 +1503,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3004",
+              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1528,17 +1525,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "GenerateRequiredSymbolFormat"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1550,17 +1547,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1594,17 +1591,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1616,17 +1613,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1644,7 +1641,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1669,6 +1669,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif
index 988b54661..87314dd22 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif
@@ -766,13 +766,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +781,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +837,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +862,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +921,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +949,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +980,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1033,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1067,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1098,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1123,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1154,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1179,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1207,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1232,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1260,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1291,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1322,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1344,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1366,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1388,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1410,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1435,17 +1432,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1457,17 +1454,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1482,17 +1479,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1507,17 +1504,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1529,17 +1526,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1551,17 +1548,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1573,17 +1570,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1601,7 +1598,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1626,6 +1626,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.a.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.a.sarif
index 989407353..a5ab148a0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.a.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.a.sarif
@@ -50,6 +50,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif
index 03618d784..e498ed1b9 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif
@@ -765,13 +765,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +780,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +836,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +889,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +920,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +948,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +979,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1032,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1066,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1097,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1122,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1153,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1178,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1206,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1231,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1259,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1290,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1321,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1456,17 +1453,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1481,17 +1478,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1506,17 +1503,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1528,17 +1525,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1550,17 +1547,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1600,7 +1597,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1625,6 +1625,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif
index 60341f525..c0fa83431 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif
@@ -766,13 +766,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +781,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +806,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +837,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +862,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +890,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +921,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +949,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +980,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1005,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1033,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1067,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1098,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1123,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1154,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1179,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1207,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1232,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1260,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1291,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1322,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1344,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1366,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1388,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1410,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1435,17 +1432,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1457,17 +1454,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1482,17 +1479,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1507,17 +1504,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1529,17 +1526,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1551,17 +1548,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1573,17 +1570,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1601,7 +1598,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1626,6 +1626,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif
index abecdfb73..9c7fc0650 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif
@@ -765,13 +765,10 @@
           "rules": [
             {
               "id": "BA2001",
+              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +780,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "LoadImageAboveFourGigabyteAddress",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
+              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +805,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotIncorporateVulnerableDependencies",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
+              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +836,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSecureSourceCodeHashing"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              }
             },
             {
               "id": "BA2005",
+              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +861,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotShipVulnerableBinaries",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
+              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +889,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "BuildWithSecureTools",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
+              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +920,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableCriticalCompilerWarnings",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
+              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +948,20 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "name": "EnableControlFlowGuard",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
+              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +979,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAddressSpaceLayoutRandomization",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
+              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1004,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkImportsSectionAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
+              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1032,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
+              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1066,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotModifyStackProtectionCookie",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
+              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1097,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "InitializeStackProtection",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
+              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1122,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotDisableStackProtectionForFunctions",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
+              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1153,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableHighEntropyVirtualAddresses",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
+              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1178,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "MarkImageAsNXCompatible",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
+              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1206,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSafeSEH",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
+              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1231,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsShared",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
+              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1259,20 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
+              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1290,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "SignSecurely"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              }
             },
             {
               "id": "BA2024",
+              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1321,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableSpectreMitigations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              }
             },
             {
               "id": "BA2025",
+              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1343,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableShadowStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              }
             },
             {
               "id": "BA2026",
+              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1365,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableAdditionalSdlSecurityChecks"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              }
             },
             {
               "id": "BA3003",
+              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1387,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackProtector"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              }
             },
             {
               "id": "BA3005",
+              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1409,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableStackClashProtection"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              }
             },
             {
               "id": "BA5001",
+              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1434,17 +1431,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutableMachO"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA5002",
+              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1456,17 +1453,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotAllowExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              }
             },
             {
               "id": "BA3001",
+              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1481,17 +1478,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnablePositionIndependentExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              }
             },
             {
               "id": "BA3002",
+              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1506,17 +1503,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "DoNotMarkStackAsExecutable"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              }
             },
             {
               "id": "BA3006",
+              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1528,17 +1525,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableNonExecutableStack"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              }
             },
             {
               "id": "BA3010",
+              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1550,17 +1547,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableReadOnlyRelocations"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              }
             },
             {
               "id": "BA3011",
+              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1572,17 +1569,17 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "EnableBindNow"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              }
             },
             {
               "id": "BA3030",
+              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1600,7 +1597,10 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "name": "UseCheckedFunctionsWithGcc"
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              }
             }
           ],
           "properties": {
@@ -1625,6 +1625,7 @@
           }
         }
       ],
+      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Rules/FunctionalTestsData/BA2006.BuildWithSecureTools/Pass/clangcl.pe.cpp.codeview.exe b/src/Test.FunctionalTests.BinSkim.Rules/FunctionalTestsData/BA2006.BuildWithSecureTools/Pass/clangcl.pe.cpp.codeview.exe
new file mode 100644
index 0000000000000000000000000000000000000000..83ca050b552274985f65a903f56b74b95226789e
GIT binary patch
literal 1178624
zcmeF43!IJB+xPb{!#Io?G7Kdfqee~>s;ST(hITbFNj0GwIW$U+GdU*AkZDXLg(50S
zrJ{q7G$e*p{z`NtRQEJ0h3LS%-`~3Ly=TwC;otLrKF|BS?`$9IUTa;4bzRq5>sr@Z
z>)w01^_uCb=yJJ&`CnM*a;@U2kH@5^PmTkw(Qr)-*BeznY_uvU@xw+vQwNQ74;wM`
zt`U9jb@%H#WXRAo_niaWBhrVs2Muv2bidJk@6i4OT7`vGjdoa1>U;F2_gzm`^8If#
zY;NTZlp76us&Y^BTv+*I^L(Q6CWH4xrKfn#Nq?&HKJ#2yd8c{Kt-Q^^pRBZz=l$vP
zD(l%}P`_01E~!aU7niI5)KJ&d{de{C!4A0^yQ)>F(ZF?H4VUYrtm1O*XhjlXvYsG4
zl&|1&`55}1u3@!oBLc4IN}1#%a%dgGq6fJm5c%9DwOlc(^nE7QbhXRy6?i7qa;1d2
zT+5b3xZ(n;OJ)xVZUl88?pm%~Ta}WirrauR!00q`$LpiBbd&BH3;`dv%azh<ME|~N
zSnB#}FpCAJI!`yxfRBe^)5=D3)ocsEQ`6<bEUp$j13n(qZ8gkBOnU?Xy1HiZ>{trV
z(`t~7_jfpObTKk+F9R<&w%@?JT&^3Wdn|bLk!x>hygPa%#P^JMxf%=Z0Z+Q_D~;D`
z#DKv=`?*{XM*_$8t~xxwFNN2M+W*y`ZTjR-{oUotpL9-DSAL&sD!KAUb*kvf?^ICT
zmA_y>h%0}026dfBk*vFhx_ReTcIBr%670(VWhBWLOG91x1KdzV^oBw2iJ<%*4odve
zF!)_Yan!_WuKXTf!7As&AXk3!!xZ;7f$ZVCNG`v;iYxy>Eht_M0nn>6WK+(EU(!qf
z%_~B7pNC@n?MU!<bCP2lD!B4%Jq)XNT8ZCl6yIwP%7kD9s`m)WZ2S?<h3`{$?P`iQ
zt%Cib!{mBTg~7mCP{gmJwZRXORQ`bCh!3Q14rIscfZSP9{ahVDm7ic*dl|{Qhe#g!
z9+akwV3iaGH2YeVo~m|(ZUnIQYuN9qNZoJA<QAL<`<M#>^lL{lq%OrOi9i=is=^j9
z*g670mk%hWv_ssN9wF&^K7dL8qHg+npts~woLm4|hp%876+yAd12nlV664f+61<J?
zPz+~s=3nt0dPLSi`k8qE##JG=Nlb&@g?9RH)Qu9;5u3<`Z6}FZL9$;Ob^IDGRUUvr
z+F($I{!MYKRQPTVow8^o#=d7i&<onabj7zce(*PBsk|534WH1)JChLd_yWlK4J8>e
zf+h!9AopAa-i!pGFFr(W$#VG3ypdw|?KCv?6Byi3NU?>w;=vqpJ8p&cwhJllegMu*
z#)H>!D69tUhx4aQ-29JM(@`&ePc9^nTtoz9_q2iYb0a9mFGt+J+avwveXx4wTUh1f
zz$$qX$$MA8s?`+gE<Z@F{~fSjcn^5j{tIZArPOVIfa2R4O#?rM)gwJ&)qW3kS3gJc
z+B^UqdQ)df(*1wZ_>jA4{MNT<{6GR`8X6AZ#r5D_at!Fqc%Z!t;Qajt>ej2>_DA6S
z!xD1OTnO@ln-Syq1K{-=27_1TQFrTN>JrXHss|=gtp7X|N4r4b9tleGtH@otAC#JJ
zlB`XjI4T_ES+&qDYy$EnpCf%IL)-BwP+s_we)}{Lz`HLX#uv-L3wa4vxiZtZwj|H>
zB#FNQnb-ECwK*dZ$ny-zf|>wEOW(tbDLy=o+&oQ)1Fd1ua2Q?jXKVPqA4-#ZHSVje
zAo=VE8d~u^DDA6JyyZ`zlb@pQ>v0t4c9p(|XsuNRMEm0^inCjRT<C$-MN43M^nS!h
z(cH?u0@^y;shjjUw1dY|eCs9fc3ev_XAVsBT9RvfF@|_*1%P_P;n%+rb?=^}jjb<I
zH=w=xV;6NF+)Hv_53I3%Gl1%9{FoGMQws)R9muUJ0OfEGBsi&#`eP?}J<kOYuGZ?y
zem5NeC0AqPTrVh>$~&%*ou?O&yG%pswJh)&+)ukpr-Aq0Qi>f1gZ%j`B<((iRpCtl
z#ttF5WF^q$tD${Tjd#rlx_&gpWxpfFvCH7{+iTRF=!m#;ABLjh0l0i5e)FPeZSk)(
zKH~={eyjq6o2pXhR@W8`2W6!UTk{0P`RdxMSHZMXI>iOS;KjWP^u|t@<eN{)4Y~`!
z0oMEc?v*HhF<Sf%P`6wjr1ysap8JO4w?DvnzL0l4MY}sT!t|$6AjedL?9q5+UiT)s
zG2hU&v-?xrbAn{+Feu*aL2l-Q$WrYDf?x0=te*Bz_jen(+)^JdwKUegK8LxL7f$g#
zIqnJLNb225v7IQwGs%suNE>hd0rJEQip@3s9={CEedWH+TMXW@mqDqpfaK--sEeve
zUB>eie|{b0dCO>{_GPH`%clUguB8~#jiUQwl7hEk`uH2v{rVco^i&$U<!bPH$S2;v
z56x4@BGo5%l6xftrd8re+R4{ll?=+Y-y%!o>(sgTV2HQp0eJipijA5g%lv!cH|J{r
zv!W@!yq9FIT+k=d^7c1ra*Jl(>^Gq3J{!Onf6>~TUqLZb-t6t4;diNeVfbDoNR*4b
zY$|{Xvdf9eaG5q8Xy;1Ux#I~?vNSMjCjgjnC#{X0OWm8_P&`x#&R1RqzfGASKV1d&
z6ZewLnFWIp!w}=%3ecunh|yV0uMY$Hg(U!@e<io@A^6=rkm5~RHTKHC{PjJ6=iY~6
z(in={4pTg~4ZA$k8qN#6v>Q5^q~c^aUw<6vmPbLJJsRkY-2m?Xfx7fgBohZg*1QS|
zPR$4Tk(+7bs~cf@Sp)Do#evdtAGA>#=uOn;xBrMnFI0xr>_tfRZgrBXBhl^6#?+-K
zh`DkC#pjm8boh2Csw>$%3A_peX)R|l#@QVVm$pm5`{*s8^RA|~Bd^j>_uAyD)}?Mr
zTarZ=p#EQ4od-@M`Bf$v-xCJUA0cV{IsCd+rJ-c0Kk|Kqtg(lNR`;OTKN?vUJ_nZ{
z7lJ%Mri*<6=sj)F^7rN>@z;QoxS!-LdEnn%2-LuWBI+4hJ1l2({%Qc1$5B`N0Cn%~
zLxQT3bcu=+GXONd2noKIkG)|m6l)ieyYMa~XtRgh0u7L;2>|wIlba9+;PZVjJ@5&2
zGt`6icK~R5C%M=<*yYPR5v`KiowS>}^KK@&YZqj%DQJ87C=z(1$-O6WhscuG^g^x0
z>bE^69vTbnn~FAvwM4h<2;}=+rh8-yocml&Zu2%!e!Cl#mg_)CmRqW*Ubwv)4PD-!
z+ySwF^=F_@d`8^>O{?5&ls@-w>Ms2rii<<w+(IGjs6Et;=m6&iqsXlqhd`ga3!v3W
zSdF=ax}I}@{_-jv`cQXR?YsuS%rD^Adoy@l3qW}!2BvGZ3eEY6+^lDTewc}Z$7PN8
zYLa`nADrhEBHH34xHP<v;zP%wjl2ko*y<!--j2ANmP0Z8BZ`BU(d4e@DDKdL_Vx9U
zB}=U)&r+=ME5)qGNse4Z@#ASwJn<Oq-n1B7EqZ`rL0j6W(~e~LyRaH84|i-4fM>+u
z<<}+Oa~Ps?b&5}|A-B30t@YP((mE2nyBm>v>@wPL8~@UP#y2U*x>!SCn<B<z7gHRe
zCI6idVIQ}Jx{Us4IiWeUFWdm$;&Wj-Lmp&n5J^)lkP|Co)9lA-veGL+A8Ado{jC6Y
zNtrt}N*Xi+IrI+zuYXJ3?K5CC=r?3e+eky<65}C_(~uMZ+fz}n+La)8jR$#nFbvMS
z4V26BD7HC|+&hvbbQ&lbipU;5ikSvgqK%$%rG*7RujoP2^gQZv+mKv2g4Qn3BKPef
z0Da~n>GR#7-4{agp;isABEfThM~w3|Y*%Ysy)g^Uzf`Aq?F49dYWC#DAVKp1FzBjK
zW0H0viE8bx+klQ}g!CO|z-o68oS)S~^-4U*S(3T`mn1{AMECj>l<ySvCB08W_h{w~
zJcnYCJmI#6v{pA9nV)$c+6AA|3)3_q9+into*<dml_dBx$bPvKvWqH{EKztl^DXMW
zOh?F-_mQjl1}d~jN3^<f(z7NZ^Szk}xw{3${TGw_`FxUj!SG9H0Y&S<6xSSvqUn3&
zlC)`fNlW0R&BzU(Pea?bgLn1EB)_GR<g9`=RYtrq9i|<(k=(ipS!OQ;`mutdFTNoe
za2v%#a;k41g>%=r@LTa6c!Pf;x$7wa`xI0Ev=hyjenCTrZzK8U73wZm(9!c{8Vauu
z*_t89*X0;w5r4y~_x<F4|BZHUm`HN)7mB;I8+)xAO}^8Ly14IP&{j4*84ZIm-O1Jd
zle(c3U{F<pH|-76Lr>FWH7(`$^@H}}*XfV;&8T~DG{qjWX-m2P-6P4po=Nh`pD@T*
z=+eI#9o6~-w0Do9jgTj)+kOYhmx&Yy?gH93mUgFWuY1{k0G%#{eYbmPe3kZtpR@w+
zm3HLjY2^&w3rcGjC>O<{(M~OfDbLY(^ZxYerE24mk14ho2l8h5#L0@5PH6kTv=Y!8
zzX96ndg@+KfP0`7fQ6Fpi=%LU>^Ok!bx5jpCaLrpOdH8A+xBC+V}-OkOJP*EP!jJs
z(B4=GzmD2vRhb8aPiKL*XFpPnl|MMDoyf3TK>1)Ixvmd@_v>EB4$6bnoeAfChhg=y
z;@G7Mf7|BL<ht49#{3JEjj;e0s@-0Fpq;V_!!F+izup>fUFGoNp8@Z@8PruiNE?$s
z0`Fz5uyOg&ww1o?J_32(p8(PlDGnV+@}f2{?>`8|%wH&GZ-UExD`>ptE|6O&_PJW@
zf75FE;Z_71y%D@~{-XFz9!ZtqBuDyU(?U6lH4Dk5E1-|P6y)s5G(NQ{Nsy*c9|eX#
zjDUTQ-|6#~OVKDQ4P{2kh5x*p#y^+K{q!~f@2W#DIsnCEoZIGm>LO`@cJy_wh1Jtf
zKv7*`<D6s~+VD9^*i@jq--qJx9iV)pJ@J?$G?aN2Cf;)dl)JY9xFi?6LppHDu83$|
zbz;*u5?0eMhT;~n@1#JkTVLw(G=C4TL*|o@(qz7D)lRGU&~Fg;qFy9Z-Uda7a`_)<
z34HuB1YiFQD1*;Mw>ck!GU7TIyu1|J&=*Pe??9@PItbX3Kx=PICi!J9fL>a52COBw
z=u46U9kUGNXf(f(qO`T0Dc<!R{GM4#Yd<LpO4eSt$wjdGIiKY6O&~A6gu3p>K^d!K
zjQ9Idw^s|_xDyz*Yf~7k{~Y$`$t1U&2i~l$)SdVlWNQh4ks2x=J&qprT0k~?2+)sn
z$&LLNfJ@YG5vd5&do^l(b~SZ1Ujq7f4E!qpicNdSQGES1$<hm;t*Bu;LFXl(FM&2~
z44fNw1^LI1Xf32KMUR;F{+;ALEfbRzMIKb$v5wHTc^@ue9VxC-ygO2T^vV$cS%L;%
zN<%ZQMwTD5VH&a%2__B!<pXVMD(!^q;%b;={=F!8*@ploD=cfNJ*V{}(8DWf@~LA0
z#>jgg(MEC4-!QFz9b{8Zl5?+w_FSD&e5So=kfQa$+FIV#oF+E}!KGVs$VNX&v0_)q
zI*x_xb8RVlO6eJ4&|dT>P2ThtWJx>GsP|fOpS6LaQ9bZlgp%7OkKU;rx%>YDdD<OF
z+V5xhUH=SR#@q-+LStx$t|9l(3yAUlrJ(GUb9?DKguMACiobpc#kSs{%+UsQmb&7d
zXe=~Z$5a&`gjK7NaCt#1#724Bg%x2?UuR1@KOi^rCh%U;8CfMA7{qJl%~urkppNwJ
z`~!Zs%_KMXFWNXf70%~t3B2_$kZTVHub~Fg*55!`qIntd3(&W3rFiLFXjhB}W!WH#
zSF58oJWAcYvhz}PPm^OXJ*oJ4^|g@A*79C>7Zg_{liS&t)?62Zmo27`yD9b!qS&WB
z$qyN{)=5!)w=NiBsTyxP9%Y`&qpn#y@$*8_Q0E)h$~fO?If?iKRX^wo;JNwa8m*&l
z`aYm{$*}uQQ0!J6>&EH4_;m$Y4{LyAEg{*Mj%W{jj<^qvMey$$!R1gT@ZKIwvZ)Z1
zr*(kXUa{z|$0`0c8qvb`lAE?4iua`SQ=gO6(_(!<UZtVj$d8|+?{^B+Q`W+u+E-9?
z)tvcNdz{4jG*tOR@G2|=<z9`P<oii7&V~IeZnzBki{wBWw0DT<i(N>LRskhR=R*ab
z(c0tE{96T2)hCg>rKMv-E_EGNBHG-}sMT2~)*ahZ9Fv2P2j;+KMrF9H5tldjP@I{A
zK-X!@c)>x6>+6Et=Ru&iyi4(!KOk#xA+05=-`Xl@tI+`Io9VzWO*^2g4$#JrpO9P9
z5b1NjrPy1v19ckkv<C2W9bvxpG`%qE56JG9zPsfUpVh2=coZ_<`UlYHD`5ZbXrN;i
zT6H-L^2Fuv`|C1_-#-Li-ycZ^UkP5_T<{vdPO+ud%P0+j&f1Rr97OU*1(G*r1N|kE
z&U->@)OQ+T?v3P{A1B!)zxL}R<d*e@-(BNqt+B*?c|WpDlOY}z#YfSg<V%Hi+Qa^$
zSyo?%?p?N$o2a<>gMA<mR8aY})|s`Vs2i1vKzF`N-8<Ul&%F~d9_<Rngp(kT(Gg*$
zX5$@iK(TcUxg~NLdv%I9PNv(WT|y(}mL)(tN;7nXy5i-=B&phbe{vY;Q&*D9-%VYx
zR;GpuDlgK`q3N@b<?7_~+(Xn|pl$B2xhOL~59sFeknfrAq5b+L@T|uHJbF2JHF}a{
zbz%5KOZs>324(CqP`c<)J3@i_J@->rM{(!+b5LgRA(H2{lvmII{!npZlr|>MJ_4Yl
ztaj^f<PQ7-ZFmKeYqepE3;`uq9r}TGxEJJtQgb5>jn~3*OAbjV(;wkLqo%>-oG4`e
zrU`A_nhlqB8uH;isjI&l+V2!;#V$bRZ1vFvnsmc0Xt!x={=ClmCTkCN??W({t3&N3
z9{^o<Ki&OD4~iQVR$Mg)vM=6&!A&yuUU|_19oeqbcDRvt*5lJ@ZF5Tizcr)or(w`~
z<xkr-g#Gn8eS1Mm(Gi9A4;%yK&qe@lN`f|bDomgBV%<%ORr<b2-E=MBb+zl=&;+s%
z7s4t}C*}KfKQqCC-xdvq#X1f6<tr#I%7vooBNTIW2lQ7xkSpDXh5pq8yy_2AyzFU;
zlNHRqQy&IV2f*v64*jMBZRDrZT2Hx=SG7xcu`@=DOeGg9>3iqEzS0*Uuc$@wpaPM)
zKU3^+1Gz9omX`eU{_7}yG@fF;hf%Pn1R8oAio4|mkG>6xN4tc3`qSEd;{gQC2RSi8
z`kq7X&b9zreoC_HPgt4p*Gjg!rY<Pa>izDM;IdVcE}4OD?kN<<H33lPQ|kI^8f?=M
z`txtV<+V4^ZGkpF$!p*;Qf=IRgkkZACdoz_XHQG&#_G7^eYx<YniQL><3C#u%EjFf
zW7!sx=U<|s*LIS0n1?dQ7r<qI6PSK8O!iw1z^oq&tAYH*Q0jIbB$uKdJXdkaCao@w
z{-Cap`tsOU6i0kb8!ffTTq-m5t54neNuazikYcpjcvk`a6Pk2KMHVrG<ZX@4u4`br
zVjji8E>x{M1ugIF2j17$0G)OfWUoJld_Q-mu3jTl?WvvI$I^1mNRV$jhfYqJh~`&L
z6Tj-<tyhQ6*EXo``JnuEG0+AIAXEPa`mFBh)-3_$k3JL+e2%z#o<PX@Ysl@~M4ek9
zd$qlg)%k*4O`Wy0-w*Vb9NHbR3I-h%d>(%qriU+wwv|@me4RiZ$tBnDOOWr@Zt;?;
zaGBT>iVv#N<nNDBeB@@hw2(<E%hPlk0rG<J=(bcrU}xQHta}yYD!Qr3)V)S`9Y9p=
z25r+eu=i{xIafj3%?jurxdW8*7Sj0D+WIz@^Z0rjb)j9Ud+%PvI2jA8E$ZLQ{h)N$
zX78bA0i^$g1QA-4uKS+43#!oWBlRerryi_46qLp~vTb=Y{6_C0_o(hG9)1$Qppo!v
zHvoRWC|dgSY1&wFA33+8+~zt%S(!$0#X<NbsxPlr;Qve)$XdG5cXUTk_HTyi?e%HA
z%G;o%{fYDobwk<fCmQ;02Dw98KbmXKY<drhc<n?EZiUqkM?k*wFLLjEN<(vX8h?(?
zE!Jr=U9Mm(Z8*?9+7I5Xh4f9`)VOPa@}!Q{SKdM6>l@I<Hl1KxSQm=M+WLka0ohv*
z+RnOdeq|icF*^4?@&m{ZY^0$lc9Prq5&RZK!s@!MbkF0O$=_--a8RctyJWBm!;odc
z6+l;MY_xq7z{x1szYs=UJ6({?coKuHX#`%#Lh9TflHBtxoV#v=LEkM<Oy2<QEsA3&
zF9f+|2V{x66bn78?b48sX|mZo02_5J@#+DR`uBr;bSzx9>+1Zv5Li8~xfL`Xz}mHt
zJ%2A0jc35Bo3>EicR)F;+whaS$z5|P$n7qNwovDySDXh$m$u}#&xP#D4di}Tq}52S
zs>N*T>NWtSQ+<kITD#-42=8wMtB>jdsFH%XZ#)dy!oF~R=vR7S$?E_PDKh%<PVl-8
z!3M*(qy91(wz5K!5jwQ{`bv_}!6b*ZIDFF>ls~4COXvgHjDh5SYyy`zbu66wk?g0g
z_-rI?{7WYZ<K<cFDt6qUmAyeLkf%ws!`csiv<7JYJK!ZKCcL9N*7zbHK>B;2xQ0OS
zl5BdjcFcXJ0iAyd(7V2c;+dz(bxQ*fbsNYdb>h12H#E=J{l^g<xD-ByT5EKj{+K3H
ztOnteT4z=&-0CZb+(LMpuZQ!#5#+jwcJ5C=+s=p8kk`?u$`eq`*1&u~v_CdPpd~4w
zY}ZcdI&Dk8KSc6tLt2~v6LpmplI++)aY1d3mqn1BqoMrKJ!o|6h0rdZNAjvp7QYw|
z%91&dC7lOZ??(~xvqX}MKOotr#pddLh_O$N-!GRt`WNcXIS(;TYB|YQG~7;Gver$h
zt3MoQ$O|;SSEK#9H%O)$`yB?Qx>lFXdZne)M%sO67z~ovQ+#%n_-PAuxdO-|I)wRH
zeyF~d<C}DbJnRD+>is-=tlR~1qxT@2-wQzHDyY?XG{pt0VGyU_>65=m);$OE3yL1v
zDbgQ0hTIo(!8`gWc!%V#swp;myaF9CNwo77M9+~Q-yzKxXlz(lf!A5y=P8{e)RQ4T
z4TImp9OS#`dW!Fh^WGB_|GFR1em@9BP(D&s{}AXcI!v0ZnEIWCka^_~4#$zaGJ$sU
z>p_wEK4R=ql>4J%kSRKuJtQxct$65nZ4`rofqtbyeYHhh1)b&oq!8AtBfZWKkX%0%
zXugie4(Nira2s`FUjpSjZHQcpDgLFqyPGQ`+6^_3VEPW)xLW72vlP~v`|~`x&HY13
zuGc#Ff_AuzHNo~=PjT#{6yI!4@lYp{d$ej?dI_>Tk^`XnCK~@?6SN~fN7bJ+yrVQ&
z`+Y`kf<nnHnz{*!u3rs;L49rOBlkeIs1?O8bziYk9lu`dZ=ZW`9-F^`!EcE`J1FRl
z`i<f_zk%{iB*pxyNYMX5_;uH~f1*AN-Y=joRtr_NRUqHj6ZtMy@Htq<*`@vTouYVI
z6E;=HUY{gUy#5LRV-CXkKnlg776Y!T0?juSibv?YuG(#g(N+4^)XKDMmGsro{cqEO
z-j+wQdzAQTPts8*cg=nx2_6pKyKSJoTN|C7^0713+6NCI!E<ugjb;G-`z<uuthIZV
zI4{r+cj<fNo()5w^S=f<<{KK%H2zAF%+>{1=>29SZWjy+-a+%<uYlrTGSjl>C_b+d
zHn|UV?`SSW{RUpe`aqv*MlMT7W<6`ed8lT<7g9gnqL_3q$mcGmxKf89H>kL5KgG*d
zVCTk5sk>KQwyHN|ZRaAv?U#`Z($0FZLb~p|Wxu(!J4KR4D2Og7#4dGo)cHsOb$?$3
z#jd+4zNX{Fdv$K+O``F0J_34DeU!C=;(>EX7ODs9F9Rh~+k(BifXcpG^4$&R6_>**
zF_L!Q`X15lycgtMnqYHvJ@srp$@z<sWnK#a8>8S79)~Pj#k7kY-pmJKRgjC!7rcc)
zPd^EC@W=4moB{2f+DF~1tw+obTI=^Cbw68lUVbkCwdKQp=?{bYZ-H`D=c2CLpzW>T
zy{k4(>$PCCf0W!^1CZ~v>k#dPLWodJ;wA$?{^khDH4>xeuhhM}oLtpMXycMR0ItC>
z9XE>Pv-UurUPG?MdRp83DazF93-XDFXl?HEsBn(-?f4$KL1M7@2a@n7KzZ>H$<B31
za7fY8J=$M>b{D3*L6^JRworFr1i5EsLUF%lMe1_&%~0_4&D$W~suPSiJ|wwA3+Wf~
z4Bu@)4EN0x-`2s~)aOYWg^_H#2fVAZU^Q8q-&>8M_W-PJ)WTdtdzX2#X@X9{-qk64
zeQhm|27?lz`-SGZ?7Tq3XT_J~s%JuWp-!!8MbJInbf=jbO>#IJG1h6bQcvD7dK`k!
zkP2&b+j7ZR0PY6>JSoRhrwt0m%LeD^l<5b(r!Z>_$xll1qQE=+2^1Y46~DDKv{8<%
zwNBce&<uD?L7Qs@O^(|PV3P+fPwzy?#O5Ry_JLx<TGU^lrDNJHG&J&7026K`xkh`O
zcC!H7p(y-EdGw=NP4`}eHG0bzU#hyAvcY+JH>Iw$tdIcNiPvBdH<8vVN{?4GI$zLs
zBzQZmwU%qyx{usrTI7cP2=cfou)1InfZ;F0s)crAZ#@l4<GZMPIh15>4NzWx30CJz
z%Rk0K8?43kW6|FI9m!Ee*V}cH-#mkMzuyem4IyZ`EEc>`UxKnjcni(}C0Pe9H!h^1
zb$T~t_0<6ScL%xq1aem>I8OfzXv$0E&XpJ|_3B?E4a~2)0hpux`M%pxD@Q9%)XNkr
z&H;H{1jSpmldC-iXrVSRcc%cIA{V(x)BZY(hA!3XQ;#T|-lipRltkO1V~3nNXlX5k
zqTj=Gz{7i>SY4aCo?2#y{)=3%pU~(M&8_VUlwPU^zt5%sedKqF(}z>sr3o=h$Fo0O
z2J)&Yu=+$}eBEu}z3>&vys;5h4W;ka28c00u|TZ+-;?Ug@Am=tHiu$je~K4sooUkw
z1#i=R{Ho3{eOA5jvkb9Cac6(I$UXCcj?JX*yP42#UjbP)tsjpoKIl6L`Ks#`qq<rf
zJLzirC!J7vQ!q~38q^J$NU_=DAb*-hyT81N7}w6B?xs&5+gp|5J<Z_qnTB#-g*bz?
zE{xL2ajmv+IS~tB?rvD^kAm!@=O{LdMZP0Cr*8c#$yQxwz8M2xxz2cuz5}&d{i*}!
z@%s>WR~7i}yPx6-b>rNdfxiA2{7!bH$ua7!G&#XnTT}PN>p%zSO!d&W)Lp5~#m(=a
z!nfkrLa|ik>!8?Ihhhhf$vCaupF9ue^JV8Mi=bG16L?q2RxhfxqdH*E{RlC#zow0w
zYa!`+?Z#Skr;P_COPf5J>@bkxw6~zx|1lJ|XTtebZCZP3o(~O!>>)X_DIO@2Tp015
ziU0;`*L#Cbj{7J=d20yb?$BnSo38ewK4O4W>`k#oHcf8%6yyW91NcRIlC3&Z?J}Rl
ztryn*8V>EItssA^xxY-~^jI8t8&(52Auf430@?o=xmVsJ8KXP(%$6A94((H_eh+kj
zPEJzB0H~(ZnUy+M`B!b!Z*c+8QE$QOwZ_ynkTs@#NO5E(7}Pi)ep@73e=TDR2LkBz
z4#kj`7$W6sa_1`csk9hY-zt{>TYKla+feW|Egkp10@FPCrhf8L=T9QZpNlL#Q%Hsm
z1$wP)@SP6DQr;!^c1LoLy8wKv7dF~YfMS<+6OC6$zAveZ)9O-jJpz5S3BaIbNENMD
zKpScyxVr}JHq{u4)mqm41#+7d`ChDXKV3&4yIR7kLVchwOQYnmwEL{0g7cq4`dj}+
zuHE_I{UTK_QcpKM0p8wO$nwEzl7R|I;zLQk+QTUML9yNjIe-SC<d(h)MaF6bYNhj%
z)zhJk_8`@(^Rdg_ib}ia+{g1RtO|D1<R*EB_1gP=bpa?>tBoDEq3VJju!^b)AmbHU
z8*&qXe7%#}PJkJY0r+tMb>CS?8X*aqYyRG+qshJ>P&dB{b#?nt+^79-2SxR(4gh$)
zKe-xuL8@78ptbpKQhsYi=JjRCqkRx#Vl(jG);aam&q1lFRd=oSzdzgyU`K6eKP-gl
zXdM;5mxUM;x?qjVZv<L<2F0t!fc&R~>{5#)b|-bcHSI6G23GOmkWH@u`(3&}nk=Oo
z3<4S_FM4<soLd#3OuY<L_*5SF;~?s;=t~<-HB+_^hW1H0qu)OO@a-q?JE%9SkM*Oq
z9?_uOuR~Nzp>t=2WvwQl<sb1B-%zj4$b{nVX8{b*7TF_{TzLgdf1eK1nq5hz&w|06
z^#B@cfV2#OHd$`u_2CqU+z!ehUE$1bNK&XRUN6NU>2g{VpCET#9M-sWH*E~R5zdK<
z>Mv|ZyZbCC!kz>rbv%Ga<yyWO2ZJqNkz{V5-5JxWxXc$w%9C;nlv|+O0_7Gcw?MfC
z$}LcCfpQC!TcF$m<rXNnK)D6VEl_TOatoAOpxgrG7AUtsxdqBCP;P;83zS=++ydnm
zD7Qel1<EZ@Zh>+Olv|+O0_7Gcw?MfC$}LcCfpQC!TcF$m<rXNnK)D6VEl_TO|5q*G
z%{UmdIUzdQ#mAcyma{d?WqtH=Vd2HO-i(bg@0C*9ss`fWnc=Tk`M(zy7S2q}Ixo63
zRw=UbigF8-TcF$m<rXNnK)D6VEl_TOatoAOpxgrG7AUtsxdqBCP;P;83zS=++ydnm
zD7Qel1<EZ@Zh>+Olv|+O0_7Gcw?MfC$}LcCfpQC!TcF$m<rXNnK)D6VE%3kA0(#%l
z8a%GB(7J0L$;TrK3;BDVE|>Mq_`<^QmAO-L)2ptotcsm;fFH^(EabJ!F*)R$WRe7t
zo06O6;H(f%@3ADgc71h_2aKWo_jHnH7m~z0K+^BN!ouu4Yv?5M(;swNN(-^VCR5So
zA(Gd@En=Ju<F==G1@yGGH~PIk`;^oM-dO5%v_<L#ZosRi2EKSE@LGB!wbVPPz*B95
zr7S98u*HuT7H&$2cDt<MNIxwhx=}`l@vlX=g3_zo7R>;mAUUJMT~xZ#uiYHdTTnHV
z6Ipw1nBIR~z#mYz>P)pwv5Mck=MV3I0m8^x1|e}K2*+WxIivy96~HJ6QL91WD-)v|
zS<gR)=yQ?Zo0Sk9>&;e@5$8(l;LT2qj<x=x157WcwXk8?E+KkV@G6(orETsSac#Rr
zbxDPhf6l1svTmDYbBt4EoZ)!BIL28o_&J8zu<TIl-1!L67`b5>V}1Ux&rnsMh_PZv
zs*K2twGitraNF)!5oFDs$PfX);1Z~!$wl*QVLe%lx`nkNE0B6RV-nOB1?sBQ|A7~Q
z&3L(r5zXjs{#3D{WX7q1-@_~`J(PTKuk}=#ZQU4a?4#uDK8dv+rW><mLwBMK<IV0F
z9g79s)*2=k{Jdr8tM=^i*_BaLx>4Y9R!&A?q1amA&Y%T2W`%+oR|dOnM*fztLccmg
zN^|sPB}PMxQ`zu$Y3R0X-mIR{5k4d{dOR9t5gIEI-hQ6;8buM_ih17b^#ZsBa4Q$8
zTxj@Pp4vhQ_2wi5MX5f@S6|6{PcBADq{dH9Sr}Qt(FN7L*}>7?3{WVkI>vi>aCBNr
zRcCvudoO3ik7(d4Wmk``7$2IQYpO?9QguOa!CK>k$~4Sry-*R*r+SPxV|;Y1D?PYP
zZox1~6KjhV93B3at3$V5E?1gBHyNRgS*k}DspXgp?QN?}ic9L^P&5%UdLXyRI8kEB
z->b4&R#+ZXdKeT5SRyw70h-1#|DC}=*Ltna_sby}*%PfPas}C*P%qLLb7NqslM^=g
z<p>uB(=a{c4PQ}H^=|3ycBR#lm~L4&COvq05VqaeM*h95F&rq88CvhLHnBETwqhQ^
zgVwUf+YV9&t88s$F*~)2qHnv!a^dXl)lEdFF^Oq!H}kOwyRJ1H*JPKgSSPW?X;>Kg
z>+uKHP7q7WmB@T?Ct{eWViUvKix!x;4c77or8k$gl5P7LyUEsa0!eLmXvBL2k1342
z{h^vJ**lfG6l)Q#_*C=QXHz5JNYhwa4f^cJOA#(>DfTR=VQm;{WC*c7VSPEpm~rg+
z!vr*Jk1H;T=5q)3Xs^5}<RKaevWDVltZU$3WY&7t4BVJqu0|KF#z~&Wu#N)afAcL!
zks7`-Bo^Kp7t4e4zh%f~tc{+?!<AOs$psOogiv8sQS<i`r+|Hh4=r6|_Q;Fq|16=9
z__WE*=TA#&9X_h+=|$C(sV*4h<(n#QzIDR*cbt@&0LERJwbta~yg4BYp!epm+Ih2&
zd$WIC9R>a2#eOo=e+Jp>uS<e#f<p#8fNWDpSL%bzU`oB?_OjfxuY3RPr_VnnOO6zc
zIEnxLE$FB*r@<CuUG|r+qcnSZ2-QI1yv_3*zm3E_H7tc5`ln4z<l*;uI9i-UwkNtN
zmY9gK#VJ&dfTtGk<g-(2ns2#zb+j3*6$<JqmWYL8g@WpMpPaCoFJSuzPvP{Yu^jn$
zFoJ$sYDQ3)c*IF6B&wrGD%N_QMbgeS99Gs$woUD`AN?4z6lSuTt#@HMAy#5^k~J^g
zNXmM|{55mBpo$quSi+@BcfrL4tz|!kKv+MRSQTj-Z%{-MW0S=ANLWtJ=sJynKKbI1
z&+W)(`{cs(8j{arrQlr)8Wfx>Q9Mqs_oRb!!hU%kSw<0})7mK(!2tf^m2@x2*s-c+
zii9l)_01V6TAGhXbJ@e<Zl+4x+|{8F9e&Zwox;fb(&gU-!>n%n9c9*N#CChz`i36$
z9m}j2li0$@dIG9f*6)Q%nG*DB-Ce43l_q*2A-D}`;&0A$8Jc+RIJ+TRY)+zWoOe~5
zXZEz5*BsWDhrBd9!j*Ooz4Hti@3HOPtdN=H3c6U|p0uZtI}jg9)5E>1+WHvCF1A2f
zAt~Zu%xu_Pqv9z$u9#Fs1=F8xbN!mF(*DF>+O{nKWQbO|Jg0@1#Mk=4$a;TCgsU)e
z;YhkSquAH{9QYF8R>d;bm*qhL!XUv0SMk3<RkDmT8xAi&QK_=x;nn?pmNwQS{?5oF
zWYj3j3bJYqw4pKfNHow2f-)-QWlk|OY@4D_R7Qt+v$W%@vN<?f<}9d8hNml=z%*lH
zlwUYVkZ;iY#pR6;ENlJS9I|pT{P+Y?+U*H`i+9q&L#%tN>w;1kIc7vnt&-KUGo$&l
zb*}8Z51a9~-&hsDpMqjJnd}`k$d5Dmwg=mjZ@Q@~jI0Ey7drmnsPSyt9eQ(m5}Kes
zd&8fH17`?&<>|eyw0QZoI7y~CHB2BD*@WoPwp;PFr9qnr2d@cf<oS}@ZYhjhDsHrP
z9NE2DPOH$Eaz-u@XJ)j<qhy|_HjK>tabz6EX1glV<?@itq)wI&<TjIXVPqn0WE>Al
zugsp=6J)l|9+$kohYfqYpEDAs_)SA0Rr0wdA3i0eFfxoR)d{Gb;7UJ74B~OvRc*uO
zuq*XW+NeJGCqBaN$$ysOPbVE*B-JrHo=&}*O3`+yc*B0fj5i#du{TJABK$4-N&R6v
z>Z+is%8mHqaz^nrU#*`~(6{(J_DNsH{Ew3@4-U0Q4oiae2kDBvCeffbo5qW6iH4Xe
z-&WCGv?;RZW58A@L6|Y@7^8}IKPD`T$ylWkQDc;Xjq_J&iDB<(mcN*cwL#M;+dDIR
zV{qCD?NiKoI{s?v-7FQ6g+oxPxE)IA?*z!K$69Uet-jl+I4Q2*$b0vu4>N^~(NV$a
zY{sz0q|t77$fNbrF7lNcsdS#N)L12Su`ykqc|qwdt&joqi0!~a1)?Qq$7VfD80>hj
zP;1{E&PmzX>g>(xBL|al(Cy7>a7$%Yn4AvDp**hKGqQeoL;A0x*8fU{ksI!pG2ROW
zG9urb-G|YbvC(~|0ac8D-71EERMoQh-}w*u;~)dvrZ0YpG6ppLfm6;d?U;T2?ergm
zPeJ0PeM^jdA3q1q-+`6y4dNW7*fQrIMJ4e0le=a|vpSy4hs{b;8T>NjXFMtX>Soi^
zddL$`VKv%jpoBcEyk@z<GO89vHX3h6>*;&GNWPqq?SF;4yde{5LcBPU3Hj)6YRE^3
zB?C=IIsPqyF{!DHbt<o9+dJwMt6)rkQhw`{&X}!pu|p-ZFJ^rAWanb~q*;)$VYpqo
zl8Jem9ykkrpW8N#wD}bfmBFv_DSN26%q94jQnCb`i52Hx6uoNEW8G@Ef2m!%$8KLe
zylQ??4=+=`WDj38_KZDTx_!d4knjH}-qZB1F>Yv)_cdKk!YnB2UC(|0wcaKEQGBdB
z1P+}ewVB8X>)V^hmFw+21%2!6Daa_SX8}1~1Xj}jdTykJB#hTK3xl=YD4Tf*T6E;)
z;@Qr5njofaZrd&4&m^*vy5qB4@ma~i@mb!`_^hPr{FPL*h9E((8y2;F6+x=F<mv%K
z()n|-LfKL=JF&WZ(yxPt47jG+dS7J)yK+d{fWg()D{!Fc>VDm-O9;gj)u#nV7v~(G
zo|fuk;&2`?ByCVB&i&%MCHOf<_&J-fQJf<PcS22Yf3_+Hhp!BdX5^3cZVuV;AmKY7
z>>u3p&{c)u9dauLxzdt~$|;p9xY9gD<zXtv7L}7KRdl7fi^?e~M--KZQBDuf4%s^|
z!j+L1lohgzjL#GmeHL)cUp>|bso;Z{e#lCw9!q#pyYl!xt8}MzCRKxc)D`S*E#hm~
zHPv+s7C@|Pj93-2LOf(Phpd@uU*v2Kd4n8Seo;jj+tlUKF++H!E_61BOm}dyLmncR
zkr$j5GKq{&2Oo(mR3!X;_|lLFL0+>p3fk^nzt8Qhw%wb(L8IBY-6(Iy-b&t#<CVgv
zWScglXh1=Kc1Ru5W@uJOSU{UnI5uOi8|`l298xeP!bR)~az43?Ja<;eUNSxb4Kg}a
z+}=Tn&N<X<)4h;*J19-Bw>jiFDA;bmWU*o5$qIRrj1GwLYTmZntoiqt#WSgQDX&=E
zhyK4*!uzlv?E4lIG3^w-ve<sG=)Ac2q9>EHee&Rzd+Pd5S8)|@FDx`ux^&p!H(_ai
zpDb3xvRxT_kK5~q{~XY+UvE{g_X^DnB7u0YnoDt(0<y!huL(W&xwqdIZxeHe6X)&c
zgc?W}9Hc=RE80|o&<Mq$(4=~~ZZXbRkQC)u((uLMD?JsX!^3qGopyo0CfDMkgvxtz
zBfN7(A5*jv89EZJME*k|8dQ9C`5-gIlK;aaY~aA~hT2gu-meVHpB&*zkMOQvA2IOQ
z`ohBWp!dA%w?yPWb#q~%-|YU3Kc3Pi=;J$CpCxBu<XW<Yk>8N6sS@mBj^q_a?iTnI
zaifo+k6)a#*`E##maDv4PKW?9C+ynCI7&In+?O%qI9|H=aaKOoG_G;Arw&;U0t;e&
zRcD1{JBLUf@-u*J4jDj=WZE2Z2RSVzn?nXUIp1CihGBh0xj8t<xIbr)1>>+Slf*bN
z*zH3OqH>w962heuxzm1w9n|TUa-YhleKNmd%o(CJu8(0@BChm>?~b`{>ubyvifLkX
zFoHDoQN!X7r5k&3#1j%E`(Q85T#daRk)GKhKkAVc()&@_D4x`|(Us(E8+CDVKDA||
z4%9JWx%{ggMDdje(0q+OMoS2KS}lu!W<KjG$+xd`6w6HUE9P+&lZ;jiWb+M#7-<kN
z5LSVJVl{2WCUa)BIV6?TR_so4Qp}w6+!vvJdy*?%$Gcu?O?8d?s$xiQVIH$tjd%-l
zvqCyS7ifYjC}RS~SM4B(-6Ad!of~XY(Q!@a9@$uR%no<q`s^*d0TBeDiH)zx4$k#v
z1#d0biV5$TfC)#X{znE+ky-sY-~1Zw&7K}T5m5^xf4yC^Hq(^6*%OabDfi`d&c+BX
zIoT?V+#xjTJ+hRi<k^_H+%somDUR=R7|H}X8}mq2ue^JbT*Y*8%h)*j-*seV$bWI!
z@+Z+59(1ug!(%$bBhf3|e^-fPzhk%As`-xnIu|?kGYT2iQp;AY#IfHBxD{03-?V>Q
z!NR8PAuep%(WD-eb~0&#NxPcVYtm~?nrPDNO`2rV9wzN+(wj}1Y|>t&+qRXt{!Ti$
zRGrR<$mMB;azCU2k!LFHa~68eSHWn|xk7WZHZnSV^{m}=HcMn?^l~V(J;51!2NKv#
zsbHLsU8^(CnTBtsX-s9Ec>366d&DHxOrTiPXJ)C5%XTq`V#705Fl8A?v7C2BXkf-=
zCj<p+ekFxZo>>Mg)P`lGm4s!C4~lSwXZ9(hzIu?^za#*16?7=sT6J$l4P>NDkxwwA
zBh{NdJ9?GW$eC``E94Fv4EsFwe(v$|4`77+pFv>=Cb+^M-tQ<aQ#mJPmw7Wf>>nFO
zB-Ii}@C7-mtGN|S<F+wmD`mAhY>nhnXNi=ChLx1i7{*%^P>hbZqbQ$@m~FI`q?ccO
zUFD(*lWu{MV~6a-s=UEsx_P!U2zt;hx<iA7Jt}&zlJtyrCuHX(I!wIT|B_I$LSf{I
zUhH?TODrtRZ^!;Ve;*?Idf2!VA}6;qf|7lJGj;ufl3f+h_2bKc`MN&EY1}_3*%gFm
zO3t!8gjr0?X!C?;Oack(dP<G9<PrT#)|=*%N6O6^{9-0mZCreIVrazWi4`K!FFZX`
zb&#s3S11U{=OTw*g4UKOEhK-AEmF}0FatTQ6-Y&OSSCUPKRKP3jRK~l_Cpm4ZYj{l
zmf5BLQg>#>tBqphzESR57JS}3GkO{XzTv(isBpHa$oJCC_9&aQaVZ%8u3z^rQ2(E0
z6yI5!F_@KnYv4->b*;Z{@|CMtx!$vRmqeyB{9c9?N2TTkrxNc53C_zYY1{#pewhb)
z-@63X3YxUMB*oDT|Hn#I`+IFeiTg|6dX4KKOr+(%G#iUH0j1#QYOx4}2fS|=W8UO6
zZr|#3JvtWQ`2;Aws|>)eRW^R<{bQ8o0^Ti{kWV+JW@cp9j<#O`%P4-m>1)>i4A4jW
zwJYu@A!UGkFb-7{5nf(bRH3Xn^Y7z3FO-OLtkrpVsrHM(Tl70U{8hcl8EEAa`dzD4
zq%=GyBp81neQf-kklOxoV1LH1zLBAym=p5Y$S_wxXXW-P!8X9Yf%E|+ZCGrINn(@u
z<TbrYXR?F_N6++T)4OGMWtsTu9k*ArRIcw-q^3ce-tOA6oZ#8PIaIOR)T_>=j#YGU
zS+?{(d;izz<J7*#n;qfJVG>vm>PFPmI9A9w#UZuNekJH1&^S3e`oR7bNt_n4*!1AG
zxdrv@az<_yGrGMQ>&a}lt|~c5{iCJG9zJ<Eh8W(%j`rR5Rc#usN!@E-T^6|*x3%XQ
zTWFjC2nE}*`ROm0XxFEIjCWPjCXF)>%>V5JQAc=Jy^iD4hEv6;K&TvzR$r+FEVRJ9
zcpl1T(-Z{^4PU2Ikc;j7N(N!|Xy4fo<VCzyAO32dd5MiTeph<40k5~vt{8!817~f3
z!OoB^@<+Ou&ovVwGkUvu=2^ivU@>$^k!e$0X;md~O8yY}bjDGf^%HO231PH~ms=m1
zVo{7?_+W>DL}oEAI)+G97G(!%?^d;O%igX9Ozu2;yV%5987!4{F1v?s(QM-7y$QuC
z`q;pqx{AiG&HqAOVW`7&AH(b5oqO^`HjlHxZEu5rmM=mOPx!io(87%4?(`-$V5bkT
ziF&$3l!bYQL%~|7Xu2>}g;e?%PjByj;#UtuD*WDpA%4GSZyc=mrHieY*Lq*?Eh41X
z>c^pqIYdlvDaEv9(#Hl)@YravR#itu!Sj##5ym+Ek|arzY)SM&ZjQ4lGp|)dfX-_b
z!U&JC0RzJyaExRTQY7kCH8wV~MzWRIO@i8eZ@R_2Mw4gtzKVLxI80_7=1Mc~{_^Tf
zX7nPzJRb_j82{ETHW$GPuCdj*|4zGZxA1jfU``KTyPj!_aGW$`Mk~a$kth3E)o@rD
z*rbiQpq%M;{tScte*moaIek9F97iO%(mI(waW;vUn1Xqo!n{C{<a?c>k&QLlZC<C~
z4Ltf0n0cKdB>!<^OVjzIW7+pk^_R0fu^FR-oqod9o><?JcoJvY_|5Hxl{ecPV^w4n
z7Ptx$of=Q9j@h}qNxQ;V!<;o9&gWc>RBlyrR<2<YtI<ORxx&aHeatD4x2(wLpBcZ%
zKM|=Kr|(s(ra`xI#;JJNHpi6d&I9cqr;A0saxg*Sdi<JEa67%xUl6zHjayCD*Bk!V
zSxj&EUuRKoq_?(un&nh>$nqM|U~ZqY#8`0-j8zAV*X;0bzR*&_Z1z|}$WYDt(suTZ
zwKywRp=!3r9OStRY>9nR`FfLg28=Cr;dObaS(7Ul?DXByoN;kPwg7puLhi~4cr(xz
zyjcH5sks<$KbJjbD&{%snyJ>H9iQM}*mpRfUK1*hflY%ec>4uYVBITDXOHgU)n+-2
zDs7z-#`Me2mq^qwv&9Vd7$b%K)uu_j{?(&%=e=oNl<U@=+?C4dT`2b6eXQi$WoPrY
zrQP?MbD<iVaaMZ=#z`7|A9*EPux3<cFl8s4Z=Ek_MsBQdnMNepE*2bk#byN&9#vp*
z%s9K(sQrrh`afCxQtaT)dh<3j6wG|_b^TZ&U{~COX&&bu>q;}@-|q#Cs}~Li2{4Q|
z!!r8WW&%{uy1+q|);etU;Er(Udgmo4EcreT_SfmU1JzQb8fqn<P4D>C@@LF`^*eKQ
zl8Y*(URpBn_iea5LdjbT17Bjp3DL@i558O-Qwk;_ijC(~Es3LD41*ABZYSxdNXTa@
zU@@*Vdqn$B1i^?g?!{b6#}sofDiygGm5h54_bVLknA|>=HRDAkd3WB!XUur{23oKg
zcaozxjB8H1#$6DlPB-@-bgTL*BiANDShs6JZ@bc-ps~J*W_+a*=W5loWSqZO4G*(c
z$zJeh<U5zWN!Hj@^A&;0#+mSSs;Q>eQ~z17`@8=vGXeLXM4JrOp3zYW2pDnA=Jk44
zu^`lDG;pRPkN>{(O!5WzI~Ksw*uMD}XHB8YSZg|2M--3B`ZBJE8yN+2s-TPPDQM32
zVn#&x%I4@X=Dy0SIXl)R>1p;UzV>)4Dw2i9OtDz&JMMPN9>B%Muh-feZ-l(l>K-Vh
zSu+@6yhAOKSlA!yY45SlT4czGOXGNPwn&My2@8tJSG0MHvl_QAQ>6fWnhcf9j7**s
zO81U$z2eZUFfu+t0jP1dM$0k{R%BmcS|dstHUKXF9a<RqTW1pkm2^DL$PK_3zbYk9
zIec)lR5D^1C@f}Z^B+C0_>Z3_Bx<jPlpf!y%BhB|Pd^5dzAYTq=T6p!k*rV7@urDW
zVmEt6pJXr>KdLNq?ica17cjmv7;=0p_r&Iqp+Z5p|41p;+H-2R?&s~}7nji?w=XY|
zacbYi-an?-$_{&lD(ihtOU-;PFxz2|e{Q?Yq;9(-J8Y`(7HE}W)WlfJ?1s-Oo+8S%
z-s$YLpq6?09RIJ;Z$?20!?J1DrZ}TREhBAZZl><{?}Woo@CsbmA1MeE;Rx+9$`qzI
z&?@bP(%BET162)p^E-;1cDWMfEA;A8<Jrybu7-n^lpiIm%^T<>T9~62UcrOViH31<
z5#ulawizeqe@7*ax+n5X%n93fN0=*q6(<R<HL9_{6rQd3mF?Yfob|qTxwIQ+jlbBp
zTfSK4y-@9Sl*fW!3dBZ<IBTn@ji3XZR#OT_*c^5k#(CCwG_d#GhSS$~!0CuK{%}ey
z;xy6E>0F0XY5^`*vMjj-Y)mrDF5c|N{PiyY7;G5dO;Ded<$nC*?7u5Re8a6{2x=9Y
zaK39{<gHhk?}E6q!+yCPZ7b<WL8}i#(_I+Z8K}BDrZBylj1Vg$*dv=A3uURKNa<|6
zH~tmZO31h7QbOIMw3HPxmPRu=j3h-OeZK+l&7%-R_OiR8igixxSzd^Ue@2I<;+7Vf
z9o9e^Ex`F~4ymEKGdd0E<1`3uEm6&Rt3wklXk;f<n6K^Ug!Mp1I|AY~WX+;*1{sG+
zL9NXwuVS5OWhAbZ9dZMRdXeNBo&_%(pLI4f-5voZJdw?KB~2H0GTv_DWheI1YgR9G
zIL(40eX>J7f`YzsJMXFFDQ{fIeQk`2d7SjvyvG;keH*;9LuOD(P#E$c&w_VOt3g@v
z#uVonbUJwxc&|4qV9|Cq_5O7OaXp(oq3RxuO1`tjYkfK}JLjq(qoS==?F7?PzHrlH
zE!D}Ih))+RVe$kn#M}x6iwnVWq~&;jvdx7EH|&bxx}P_Zgb9VThqFtdda}F`zKL;)
zmEP{(f2?m4{BTh>meO~kmXv?4Z=Ce?Scm;q<2}4#w!RER`)hQOd1;J8#(X^|yvIli
zS|yd;G(1@IY^!)EB*`kKgVO4#gNPoT{eas#+&;*q-@GvWtD{L+pSinAxygTQ&rfLo
zH1-U-@jqeDXB8eAwQ|D#<S1C<r^ue8N80w>av502@?Wy&vseB{>{)UuYO1~AoG!=k
z1@wng!(2>R4(yRPe5E;x(a5<d!KZ17fTTo^nfutlL%108LWMY)F&Jwt=7?W5D{D8d
z_nVli#pvyk8zC7Pa!gIE%p039*yIVdGi65dwqPanwO!0u^Zr=m?%@%x)ow<nbs@`_
zJ<jdXe7=PC+C9q^n#R2~{t6qX<X7K40y9gDufQF#2QtCDhf|@ZTA?!XDjFTK;zJ8g
z2|0rsD`DlL;_37|KFp`z)lLlKc4li?`px&v`VwF5|G!tiD8GJpwL5eFt&RKN)_-wB
zef{@f+cWF;mCwukuj#+!AwK<{Z*yk-{&wc*|6TL1L};OJqH+#0p1nnQrhajZ>@eOI
ztV<S`qHi`wQxzS=8RBT$3-!1cD`<hVo@Uo$uM?nflvqy=h~Jel4k*T|q$LXmv33WW
zz+D(AwqLXzP)d;lN-5!hQgA@|(`m?V_lv=_8>M!eIqh;fIG%6Ir?uf^QA@tQtBu@T
zDkkWMM|fFKn;n+;RJ9mq?R3@+k1db~RF_{MkK+-~Adu}514K2yWFS%Th)Mtb_kaKO
z{+o4=um8SfuW*|F>*|>6Kh%Hq)voEkK~B5>ZvV~o*z*4W-G4g<`TDOBTfEcs-_-8^
z(fQX)?VA33p{33E-|fE<SN`wsKl}U*$Ksscn)0d;Jc)grVwdBKmvty$oSs$FjR~MG
zJD4O)@}2L2FD!O94?9;Y3LlNTIwh^5tN?m#7*m}v_>?p@zVz{(j27u8ex>&_UP+b|
zfSu&q4^y8^xNF`WGH<lU$Qzp<#)u(fzL6WFU|sjzdMSEJJP4e2L<=gmBG-tHD=_a9
zn4(@A=KT*Ri1s&-cBhYk_QKb3amQDjulLuj47K9xsmWZ<{Hj=<Yt21Eb=rtFZ}~?T
zm|xUNDq3@lBTv$r^B&UVk0%n=0>a_8vlU3P_FrxHUXc*yLdq#>spFj;ZV>rFO`jlo
ztI81{W-WB;n`X|-16nrWwptdE&$0!4c~8H7wXD54(1|jzB5B!3Xg})<(F3^oAvU+O
zJs4AG|2KS!#rw{nc3$a2Sq{?eqZIOS8KXm86U?t@#U-Gq#E;VpfhfvAHZK}!N@SFI
z@97ggpgrheqWhL?UUW13>@r`sbPffaN$ex$Sz;@v21|<@usgi;3==Fs9^WOtPiKOc
zWTLJaj5a&MIo{9b*{_bVJta59CbFudLC7%EVf`-+Y*@)<ImsBxQ8Y<mRmoowGv8lk
z<~7yVsD+(`B_@5VJzupvem+z+8c~gkjWu7jJ)DY+K@(?r<{Dt$Qdw?3xev475vI3`
zPS;S}TOqBc9u)%>0Yx4{Uvn!`#8XNUk29To2Y2EVl->>%z1G^RG>!F6iM=sD!zS2B
z_0RXa(#;ITBGZNXhJfmeAHx?LFZ6iG2Ul|_({`hD_A1WpVz2m6rUZ=4lmLz~n_MpQ
zJIZ!ke}66W^Tv`P)q8BW$Wv8_ab6yb(NAJhw_3kl<URJQz6P(CJ}^+sw4jneLya+0
zUFmBaH=btR(($u1yf?Y{N|7dyxY)mMv6|nOay4h1C2-iwaE=iy#k!@b?Nd`!^y+Kv
z@3)}lAHRT6VuY2l=eVwZdwL{ddo!9O^r`IW#-4(^9fP?`+N8)}?$aAg?HRTCE>a%v
z7Ok#b+$3(>Bni<0CNbaif35j{$|M2neNNb%Uj8Fw-!LqKZ<b#$!HN$i(;7Ix-=GT|
z?iAvA$~JzK1m?2+`>e$*kJe^1<XKa+bvA{JT*h~vmF84%ejV}|cO;DYkM+n3$u%Y8
z^FhrDS>!Kgg-j<87iwR0YMIR;&yn90@+2u=y<MOOpUok2oSf6{X%~=E<Ht9D?Ri>a
zebCZ$eY{VjoUrs;{T7YY9yD&6b0&YPWviH#aDY0yJfVFK$}v8}G98BUU;ev>xf~y5
z9IudOexk=~Wtn0{`+m$VmF@d6uYYKJ#MtdW3ja5pS?TYqm;oGXB|AduD&ndDt<@4;
z=~G(@QDP0IA2)lVd}HcN>$tBQobmQ~ANvOAUp$LB%o6)yT{mGWUSf@skC6qRfyByi
zV^S>}1!gH#{X?pM#aU>Xd79v0n31YCv(E00tXTg!qrAw`7mII72Q`m&@Qs{P1~mcv
zkuX%&#g_kl@ytN&(bQL`7_b5IocU^OgdNwod;8*=p$(mG(9+~~rJ2s~n!#z+jkIC^
zP3L9k#5#YLz3Ll%rJsTEirwAL$_xKEe_$0`Djta?9zo~0p!7>ML995Pev;$uMgn$Y
zZ{I<DY*CbNb_OD~Z>EaHqNnJf(jphDDLr3e5X<8lUs;bT6Qb5AN;H$$YVM4MxPtBl
z-HebKafNB-+akPz$yUY#x?Yg5(f`(kgUnFi<`SK2CF6An0eY@C<2KH!=PYa-9GtBW
zE?STHVH5u<Q>2m&_YFni@J?HWf<e4y)AwfiV$EoN6ZCpJ@9xreOZ=+AY&&@$Z5RmV
zcRs9U7s;UprB~$lS@n{E8>L+FtA)pxCgzG!PGqB7^ay*1ht-w~iniKX&N1m^>HUv}
zS84ysbWp6%yBsmrNEu9SOZPh|0wmd!<!v2-Qg_B6ywv@aSDP1y{aD;_ne6+VEqnX^
zD{xW-NMGRGV3d;n1aDKEmGsX2T1ls49J}tg@*0Ve`Qc|37wX8JmwMeYlGl3CKovKi
zdfu0|KZ~%Re`<05wW}B7f9+ZDFMWOz$UhVg>W?IKx7*sHgS8_0f7GHyC;xN#ml_U!
z{vQ>$&qHUyzqG#yl-~=7BJ;OCubBAF&w~B7lKgQStlWyZDw=}~HiyPPhEf-WW8_yL
z$VE82yV5VX77Z2qhp|CUvYIiC^d0;~%xW1lSw{`w4?kjxLdfJU5x-H>9=wL8YHhxH
z;w)fy^z<ElzT(Un-^ToMh4c)!l2;F=72krN?3`l6ST{O%mc{q(`aK)dW=(;eS?&2}
zcL_!MD-;r2?!uec>gz7Wu9?luMBmF)@>)~vlCitjx)NWg@8F1X0|T;vDARdM!eix~
zOU2bTS$CW4Lc0_UnLL$Q*m*0l21I5adaSzjAu@l!0^b&4bMAVft?EB=nnmuv*m;ek
z?v;&=a-(z>r*G2?v0GfkimN`>d_xYYcS$V->uv`r<9hgll&y6TO{(~U6hDRAYJ<*Z
zO|h?#%(14-6Js-M&!ABU{&TI$>c6}35*ohx!8*z0b%kd>=kLorCN+BT!wY`Bs)z9#
z82WuJN#(T$5#)m5>=t@c(pq<et#`%^KD~E10hnKJKS#GUw%Td+u8PSNS*x|b=vm+R
zX%O{awMRf#n{41xV~ieaU5B4Rz3bF`thJhznRU4ac8aTzrl=;aVtNF&F{2~a`h{^?
z&`{MbMrj>r;;fhCcWs$tt)FzOLLZ(g0xm95vHmi{D#^N_hC~RT;+t>DR<teD1l!~h
zNj{U`q48ou6a?Z1HSnD8AhSlW;=V$1QR%ySG3U%ld@U!}3|RRNG}7NA!jYQkN5CN6
zvrG_n76C(X^-7hB>FZ3mDi>%(RZP3e9sqBjZ+d_)4{JCa<a|f6A==rU*PVK;mM|sO
zYxAc}a9pxT7JrwBsYhd>-ke|#+4;thH~WyetG54kh`KcD^nU=P1b=Z3l_IP|Je@+6
zZ-2|BiO0=6W1<PP*<(%|d<9*W72mCvGN=E(22&ch!NQc**Ur<b$D4f(EqjfIIF->+
zuC&e$)I+7gAjpl!tBPF5=DvYYw40^g=D?Q<1~=iyq86SeASxlEexF0<e3&$B;x%Dh
zs00`L3j+T6XnMkH4P}8~GB(rrOEo`ZlM{Bl4S_Sgk>bs17ZlJPDFs~%5&{uF7GlLb
z^Q}9Ei~aVs0-_kH>b91fMMI2=b!!Uhcu(K0eyxheF9J_Gc%178JJg<TV$zVFi8_G_
z>!OD_qvOlJaqMxd6;<qU?9HAY9aV*jQ06DV_5k&LJN>1L^hVBhXnJ&nP<}LiCDRo0
z)4Am;xI?HXh1yKNV<blYpI0&@-!qrIKvc-@B$5^)IU$n9-t5_iL^2rcJS|l|?Al;6
z3fxUy6ZJEz;h8o06MO*`X_wdqhGhpAdZ&l+#qJoyXP4tDsOA(jX5pxMMpF9%{d5p4
zQ^e9->ctuKP<Bai2A8K0abWFT{IsjV4mQM|f-t+ttN_IW3NP(zE8~+ft%Y4US0aHG
z@H<#)Ai-%M0cx+gNA#)&J}iM#+SDwrp2N$pUR5|G`h`t&cxi(7EUi_NA2G>6OcEkZ
z^(>)Pa&fJaLD4nNT*ywP8G;(k^y6RleP|!2kv=q%Vl+!p4ZKp&EE!XriWhxqc=h-5
z>hJLC53f|iE7jq}OFdJn`+0fHkMH)fJ~jS1?J{d?B{NrBd2^;mr_g0qIB_yxx_`~B
znqjJWUk5h!_Z?!a4{EY>))#D|VBZo}`eAoRu<DoY*kYZb?X<1_U`OP^h@4isGluyQ
zhdGFP5h)Gpq?PE5(ZxGsG$^C#j5>_oKxtar1tSfKF`$0J%a&%m)5v(H^F&o@E-0gq
z@2_2jXRe1Je)%|W&g|%!=<jy~UY2|PMnEc!$~cQ;oQAr@pfZI@&2&9Qx!j=?vUSvK
zAh+8N=&chc+5An9j^zNxx`~NxeTFY!((!X@=1e9h@`sK(f#6s3)WSoAxhi-7db9s1
za*2sKnTE-0Ed<t|B(YAKJHyQAVUh;0p+TCxjx?&bj+(&7k)|2a`226=NT=OH;#JFO
zH>qU1QqNSHql<Iot7$()>NFwFvHGw*WN8>}wXg%Wq1I7i0~8!6k%VUtJpFXCmFP%3
z8p-09GazS2M^G=LtIGOBTXFT5(a0R~%#L<D7^<}9n(e2fPDD5n@!!?$4mu?8eBwaK
z=aPIgoI;Wylbu3@An8tFuOO)u?2$Cl%q4ydP_E2B$mLKo88c>NX%MNP4+B71<W)>q
z(AK6)F+Np9)2Q_msh|%;$~r`hL(%e=0BvHr0?15i3iPwzh`~g6YQPnMiJ-;BhE6=C
z#IwQlH?D#{G_EWR=kq8n@my;CL@MY5k+KdEQi#@-HrSS+vYdP+W?vuKJyyM(RhdqZ
zdzl_>I%N<W7Zp4L4lV+kPD*ruNdk5+0-8>14KV*z$q?X#%Icp*;P?esK_3KP!~?;X
z@+htCVru<FD(C}|vJMg2ik9C}4A2%y`NA0rrAX!{@wbk)M&@zmI0;WH;DjQe8F;q?
zJd-ZVXwNT}3i=?HvWWEtkJ7p<r`AuTf<6!_>ky%fXc<3^z&w)_tHAU#R6!pYDhtD0
z9;KyNORb+s1$`h=)*(WQT-B!aDnkM@n3$6$h}j61pP35!z)V?~<?%2+T^ZrQSy@+l
z7wgaCC*_nHs*@(FAJ+Ta#`I`2=Rd2;qG$SWrohjX0FNLnv?kXzo~@tN!;XGCirXTg
zUxeS0o0^8G`a1}mMY9F~kt0*3^(!R)RdkRVGb?Pas1Iso@vXk0v}D7!3${HFb}&?k
zPGI_$y=-*1mz5XnQfq6P@w(|3_~K66+3ppuJ;?8Gr}eRu=CsBMHH|a>7j5fjfMStY
zAL-|od%PJBjx`koyV8=m7zc1jEUmv!7KIX;_14(HMz;Qbve5dS;KH`OiSV76_K1!e
z=sXhvdw7Sd-~oHv{JF=sZH@^61*>{!)=Tqxy3*>(0?Jys=GZ)w7f7J4F2R-4M~syh
zwUkjrZJx*-At_^#+nJ+A!ChFkjNum*7(;J^v48lfpbrfxOFN(PC_MqTQ|l*EK_7^e
zb%@YRv?W~rZfc6VeAR%f2UE5i{c<LWzXH?WxC;8vxUw{UfJbSG_fqR8Qb8Yx_VRFu
zkV3RbaUPhq6h5~fJ|&d8_*K<`bDPrSQahG$%j)au(V=v~Fk~+k%N$ZaF>MSGq*zge
z5sRu5X9A30PNXwC+C#mDfU2z5gKhX+3JNc@f(R+eK~lYyuHz|~EGlA>;=om94RM$(
zb(kdaG?F+-s<&btCd(-}l1y~qs<N7iiEk3`IDE1&zlYy86HmD)TUg0&Y!&pu*vcaD
zAs(fB=peOzA{F$3NLh!79uh4*q`zws&_hhx^l|a4%u7Hyk&m^rduJw^SZ-;E;U|{W
zJ3gBjAV`ZuG1PH;tBP#0+_8zOtjLN1Hd*%@4kzB<^hHk7xni_LP6MtpOE#@;FqOtX
zJx6HikCNB7wPoKf2K^ldi%K%kpfHs%+AG;;B?2Vt=fG`EV`R(d(5pQ^-JV`2qeC|`
zEIF7o4mGkuI#L$lAvM(jLhYXL@r0EOd+R~Ymo>g}jT!iHe1cf&HAq!u)u<3)hPQq_
zc}7ojgg*0kunPJhjk2`!H;>Yz;yAT_A{F$3NLh!7Q6XAJg?=&G9u*T$IX1=3&(P#V
z#2lj%hMMN3r3elrQb8Yxly!)ZLbPYG;8zc1rh+~&Qx<0Wdp%~sS4L1cE9*+Hr9Rk;
z?d`>}^C6a@*9j$AhR##Bxz%kw|8mv<UBS9Rv6tOg!Quj8=|T4B^ayf2k%WJq|M&}x
zA2chj%{WOYgXHFXu3$4LHsch*x&^|{a~Ka3<XOeNKB@{ptczKWk+`+izF3rTrA0fZ
zWOzpntVSAGXzJFeH!~!hn*6D-^PeG^>P`p|(A~TsX~O66THaEzR}o)x-qcGGD|R+(
z^J0!Q^0V<9r(!UyG=q^Q+Hn~46N77uGYFruMO|4WMGB*G%A3^rccb66w&(Xm87K1`
zY07Vtmz>|eow`&usy=;^{$X%zH@%Oe68Q}}K%+8`N(DxG%5ck#rPw{on%6tic(;&p
zh?GrR%w^8#G?!Ixy=6{H9L@OKSg!nG!9GPMnvGtdZ8303+eQ)l`EBbJgVx0vq?NUu
zsqKt#Gu&0s2St=cFD=8R=c0ZbL#T#G1$`h=)*)hKiMB-S;ijs1?4cTP^}u^95}(o=
zF#qwM_PWua3fnZUf<82^ERE|s0|umwK5#eLw65{1+?0tO>b9~+K(4xQvLXRSKyJwq
zpnf!!ru#GK>HM$hsWRk?3XJAj(5{*`La3k*@+pga?Rb>7Xe_ltHAE`t1Cg>05qgNW
zghh3lTHK<l0auSRSX9S~vS@oyg>4#FK_41dmc~6i3`iM$;BK<AXe?zc`cn&M&6GuB
zIm?qpx0hv6Q)w)EG53Y}+3-A*MH9eL(?$pt^g%vlkuQ-)X^VQP6{;apK_7^eb%@YI
zv?VN>L{)K%ss>y=u;>EuImH;&;i@d!6I5ZF##PXV#+9Y<WF7{jj6QHT*|g5_t6EdW
zqF*+*ExK10{YINLEV{QWi<(Mf(LFe`g7yKzr8@_g#vhMHxQ2c|Z~Sqdd>V2Ye_Wf$
zI)JuJchLudC9{!U1$|(kEQ<B#QMxNqs1>RqQb8Yxly!(OfM`o}MJiRryFxYK>OoiR
z5}#9ag>P^V236RmaTWBTab;<I7!LzdMjyDFY<gLz2F4NjIynsr5gBq7^ntUoa30OW
zfRxb(&L*4I#O&nl{qrGp??SWvc8(gC{K>lR^b=jKn-=SH`6%BKo(V!3S{HLd<7rdP
z8Ua+$2icTGwoD$S`)MMzLN!Dx=mU|m4iP$t7TfocT<`p$(~t1X24}I-OoL9OhPw*-
zz+G9m&*V{Br0LWO)exzm4@Am3M2I9>L|QIb>EVEdJGgM%W@gR?RoI513i`lMSs2dc
zVL-|V3U_5)X*b84KVitsoD^fv%m`T^L8lFL)1i_x)AX^H5CZ|jE%e6&Blfq6_yXmv
zZ5NEZv>Bc`>@1d>`HrAQY8CWBA!Si$F^|$_T@*;9f<vUNLxkd@EiogPQdN9Lss>y=
zkhu0)NW2VGVH=56&<BZ?rSUg-l$LlowL&#SD(C}|vJMeah}M-BXh)*M@XQ#h0}WkP
zAhZe`QJV%-(1!+;rGZ=?rKMU+txye-3i?2#tV4uUqAe~J+r9A2S;8$nT#L=)jgX4k
zG@yb$G@vXEY~xW{syu3iYKT<O2O?!1BBT<nD{WxFm}3&BGt3#MT7X_`Y7g^RjoaJg
zq2!IgDRIE!97-Ap7#^X&S{SgG`Sd7znU{aGJw?;A@D$sTOu`xYRnQ0dl|}yDJW4D5
zDYZg1L@MY5k+KdEN{bfLe<N6c=`S^fTxv6pdyJp>3Pj-=b}HxtJ7r;afJcE%Rs8y9
zF92a1Iu-PRPFaTzF+}c4>m9#}9e`|oeY9=sBpL5lo#bQ5h*R3yK)^^5dS|nSJBvr^
z5zdF!pT#7!kU&BhIaSaHIh94uLp(~`_#m}HHAE`t1Cg>05z2`c8}Ah?z{d8Z%cZu%
zL=t1=BcKY~FjPSw7%B_Hzj+k1GP@c>cN~DQ4V?=5K&Pxjhae(1R<6bqD<5xcTX~qw
zmaQ{jZ0J6vl??=pi9-L{cdn~FeFdGu^@e+C{fdtUEjtpz$f<%p$f+!HhVm$F<={Xf
z6&xaE9U_zyEmq!18YqSRjz%uET#PCdtscnj|FHKZ@KF`X|C8fEh=d7hARNkwK?h-F
zR#1bYOfcerL8AgjJP3*y6*X#tQ8|JMmqXm>qN}b)JQt7Eh>G!84T2ns8ZW$dHQqfA
zt9YzNUC96Yt?u{c%_KoUcYpieC7;ja^-*12U0q#WUEQxABm4si3<4V!woL*wk13St
zF2sl_#Gokz5?EFyMlgu{UAmX%Z!H-%h;B=8FVG=>B?l071fS*hi`>2quB>b~iHz_M
z?P3rl`tY#ZRqV8@ue%T<{6irIO(C?4WfSJT93;ihdrSc=AD*(w>Kt(bxzy)<KFy4J
zwr)@QE78<ohs=;1Kr|A(6c(Oi?p+H9lI~%M61+Ch&_<q%OchNm^Q5?J7UvXpScT-E
zie`dmxT`n-Rm3k09)#c0UKrrIM;>$9#sgB$NvWNIogCQ7ft?)K$$_05*vWyN9N5VL
za=?Dy)SuT-2+I*x^Obw@#CQQ-J(;g)hFO;~p{j!yT=7;`cG&uEk4(>iN|cAa-sW?A
z;nWVlwukzq{Bo3+4<T)5X}kOkDUVlWcd-0Hq~C)EY&Qne{=O{lN!`)%%Td0nId!{h
zciJ!IlXtlMK|(*44%>|(Z2j1WZO2Mj?lA~kpGzET1Btuum&i45u;D$WQhfw!17P*t
zivyY=Yd93`Yv(1k8txt=@0YwuzpZbG=>FVCw;_4^`Ju~y+FRryZAZ)Bjq+8^#Z@iE
zZNFZ*)!}5u(=@3cEBzhl&;6vV&-ABmPY<CdX}ht-^h*fWpfvWv7sL4>#_}HKB@w=>
zdabOq@g`UFyk+}vYul%my+g%A6?A%p>ppQN`P7*&Gh$t;(a<x7cQvhZ5S4E|TEz_6
zuNxPt%ReSK5%2E2)sL6i?CSWEP2ANR+cY8A`mzEqW8~14qUqdI4!e`$^*DjRm*vJG
z6V$EGmNtV}Z}lNM>2W)0lDB$aB;kyIj=tL}2l#Nnj|bg}>Pjwy!`31V&wY&#Sz*|^
z#9&YXju@2pd1eOr=rU(GvWt+dIdTj_y!6dSw&2aVi~&ecCvR|=8c>-p!FRM!<L$?S
z9B8b+SdEGKn1brQ&onpj>Qct{Jpm_g6NT{R<?OwXv>r)n^BZh?d3V+pMB-yioCSBQ
zPLM{`y=dbZZas+na`VLy$>i~*Xm>3fl5qcfNU$Qe;p-&Cf%o6w{{pe<mJf*rdqIex
zCo8tUC%37)+W<-b%d1vJx;LXe(80@jXLn8|I<m-H{S`=Ja1y>Yev}4U4ItekPa&jU
zhkV0xa;$U2>+lTioKYyM=EB>=4k(IqY=>&_HjGJb35CCU92(by*8nA1l;a7`k+TcD
z8eI#~9bnK^B%sr$@re;RaTraG2m*vhZlK5bmDh1`rV&k2_Zs#y5;+(X2gL4!EW43!
zB9zwv#}Dm^_qu9g(pc^;@$4*?WAzF2EHR0uhLF34H^@d%nyX5w5F~WQMm^AOWnS1i
z19j?t@PYY09G~R_qiz`T8Jtv>6PX}*<lR|Q%|y;SkRxfx`5INW(~xcmseRs--hy}B
zw8+;@w<sIn>NSjay3&@iweHteLN)rxcq}u4$qg(4CI_M?IWDvpjUf1my27Ad+aBt-
zgu9F7;CGw;lT4zf{*xDM3kwh`<o;i-@PNF0-S{}eh8JVskMSaUCV1-I-R@C~Aq>FW
zkPW<t8#vc_Pf(=eSq^!_)M#HG3UinI2xHpLg)fie=)c#OXU`Wh|Ltnef4$uEAGSzj
znu=6OmvRC;7s9{nWXicuRb!`$p@5noL&8jkMQZ_ass@=tkg!#(@!J#QafoWAa}-19
z10U`BLUsDzOpS39V}?z~j!le4Q`+q<0X<FK+qSn<-G$8xwzo9$zG-hzefM{yQQycZ
zH*<f4Up@WimR7m>Z)hXt8E^GfC}3aG=gg8*jYcR`2Yx`z!k>W3UBie~plJY4%6d3f
zK&kTCL_|*o(7piDoZ5q-u+_sURgQ~Wt<FyV=1hFCC0#BcjGWcl+PZ9(?wa>ysbmN*
zRi3|^HiDNWzv|SK_`WX(bJ&^&vc$6TRv!mttnS4S13R^8FpICA`oKC`8a_{X2_*}j
zeI%&RE1L1ayar%`kSsCZqAtL767R0onW4OT2pZ0r5&{wwQUi<y0cF4~7`5d!wioAi
z5Q%ic(SyiyM$6!vw<1?~mxF-4#X=~<>1f1IU6#MKD;_wnfT&s^qK+LHsmS#TAZwRI
zj03+~D0)#2vqA}BBE1me<U@O9OHY4o5lzK~p+(@$Sg+wt*;xHP2Y0~KZkU33xLH_{
z$&`CP(XA~st@R;MkC%f%w6p!uyb2b{+z?u>8-&);+*=|fo5W$S3t0o5GZz8DWpZDp
ztk{QVj)I6sCl!EqM5oVM2T4vJLrzg%y&SYIG~^VirNGX?QtY5FHhIPBVmIz6dkMo{
z4sh3kK=mm{KDaHBvgaAWv2#PZ^yFwvc1}-@0N%*Kg51zP2;+v$<=o};p{I+U4@LK{
zl#ze~tb*0mhw*K!1Xgu0Ep)V`L{6cy0Ld|pDN(~XjUc-;CY*I9vs4|9eqd&W>8^T{
zQ=t}$FgCG^q)AgK<3>26)1&7Y@h1UeVEpp9Y$fWBRnjD=jG?(<r3RsiY>xwz&m`45
zp|)?DVzqIn3b6mZvs)YUxJ^RLUZ%)!02btws4HIulMsSA;gS$-CLr0b#=b=^T37Aj
z=(S}ij+B`?1s#tIF|6|u(~5g4LeK&^$Pld;D9fa_JD}_cJ`OA^ieBW{Zw1MeSJ=I(
z$ETVO%+3jPgb3hQdqgoj@l9R4+{Vt{M9pIl-3^V%>+4uPO$1mAqm;77NOT&$hKTN$
zy8P+`h@mrN4olHP=6V*Y<xod;&{hdln0w9sAbQcfR3`P@Dk@3W11TeK|2<NcF#pgb
zMn8Po#p$Q_uo;Y$*O?;ABJ{Df8Zoo}k#wkP-kXkjbT8hQjw`{rz9YlmfF&SPJUWsq
z*ZeAV1cT_s{J!1=GjJG<H*DnN`i|os#71=W+`?0maLLAs)@G-F>!p8j9ECH^Q0f@;
zUnN+Sz~3c0QR<DZ#WI+$C*;ZH_n4V3GFVE9<?kP9EVb=nkwn3A7qRRoSTG5q<Fket
zES1FaCxfM~JuH$aSSAz8$2gPawCL+3EiSdhGR0u2Zx4$k3YK2Pa*JTG2w9W$h`~}v
zEPV`?#`dsCqF{LqW>loejpY`Prlp=(-k?be?l!fDMG^%|4Y1@j01L@D(2&tc1WOEp
z=JpUsq9C{y-iOF5Xotu~RdWhtVnl>5l|s5oI@_`~9I;7=X;~|j^!%LRkhQ&7a4(c9
zfFu>1<XvzFB^Q!Z07>fnX9`_)QqHMKIDIj9l`T;eO@0?O@)&@f&X{Ew&_w!Qr_Bil
zY-*2wNfi1Q!<33#C|C>^Mj9;5#B!Cv;*pspP6;fL*O2t!7)>mL1Pf%0ytE9KO~ev1
zSTftgB8ftahgd#=d^#scUp7XV2Z<`#VDYtwMG^(e6VCz5t!^wg7%Z8@@)XzA;7g!A
zERrZ#%82D8!IGw1bcVs=BbFHkORzmGk|<dACzjm=i#fpd8-pc4ECGY1ustl2C|DFM
zipYy#q{El*w`k)uNGzXo!HX6Zw}(X%1<UQkvOuty7OgN?3W?=TgQc`RERrZ#P9c^&
zH<qx$QcNtT87!6UVUa|^(t}uj0*uq52?k3kv1A)8we4Y%M8VRu5?CG;ED$|PT_1y`
zl2~5lavprCYY&Sg3YII0<pROdO=J0Bv*vCsu`D)N>f6I2iGn4cSOyA=bzuqz`dVC*
zeHKF`ftb#G67<+}w0eQWabmepiA~;58^mF#EHp-)NCS}bH6oECp-v*}L7bzijyELM
z6LG{C&y8(J3@^!f3kXO;BO$-U2*cun)~p6LwfXH?o3*{k5@GAUWV;o&A>^_bdZ0SK
zMrua-Yq;%$6*RGe(+nw1ZAd|tk|=HN@hrIYM`;i$L-DNRe$ZH&i6z@$X>JdTBnp<M
z6(EEwDUU<ycS)Mzn~3Jy$6XA+L>3ifxCbg5YqJD~f4bhq@Yhis>Ucz}ciyX@!JhZ&
z9SG@pU#<tlyg!K~LR-Tu%Q)#zT3g?wwRI&PX8t#WKkY}|NbJX9{^wF0eA|@RNN4pV
zIe^F{_&j6IOUv(F2maAZ;q=0(KWWrH!oKycM(x2kjWaDA)RF_#0fO)6Mtv+%R|B=o
zOPHX7@KFYjEZdWhqr`a`98;Fb*wJNO_!x(4fN|E&v@yqYWRRGTHH2h#NQmTskV1mr
zM(f)iA**2~gfJW^z^VY2C>;1XT&pobzY|i-tZ;18z^~qYlr6UnQf7DKK(hxD54uKP
zBg4VQLY4F}^XxHFkW;FfAtmhiE#^`|fR(C`F>uMbQeuXyl3NhJCC?<pbvH<hc@Dn#
zLU%<es~;yjMmRm2$N`Q)Nfac<h{hYw3)jq$oJe`K>CP7!F}w(ZYVNswj!uF=j;LzJ
z{+Ir|iDM&9GQChq8rE^?%+79)21x`Bg=+58a()u{uwP40i0RSZ23IX{%`&)x?ctI{
z!8IFNGfK~H44avB27j-)Q%7t=47S4dut}m|`|K}q9bmKQ#>ZkTisnT7+rnXdn1+#?
zWyPj7DOV(@7b}w5CkvB2_AlwUBoBW_nO_Z_{Plth_%%Ey;Ua-v_|+x+nD72=I59r%
z&U*-D&quz6U-1e0cQ>B=Z8X0F#wU6Bt1!RbNYB8p@5CfeDz*roM*3JhPe;5K&kgu3
zMVP-@;Pv$U`M;!}0ZC3twK{c9>yo}p*Nkr7%<jAH)^qo)9@A=joCJQMz3$(INc#tV
zo=!=fk~^hzO6}D4&uX*s-kGqI13NkJYjYqUOGsRo>iWu)Y|0j@E$~L@>F)WL#qjAo
zv@vou25r@0pS9p)_T`Mvl?f)}86>FPVan2h=?`0L5Dy)S;6((&>J#6H|2?KR<obxy
zr#^!vN8mu%x{<))jLZ2*S&O?xss96<GkyI0%=MTtF;5cFZc-aJaKqR>3f1J}bIrg3
zhYZv3y@T9~3C7!0XlGUMBO_;2=TtJzT%qPA#G(h<&e5zKshzur7eA#*3KCsVT(KI9
z)cpq(3tL}&@5T9p#!xtGJwha-LOqFg!#`xl+iin@JY+!3_m;4x4`<vgX<4)RNO>g`
zem<OaCBkGuMM285V_?;!a2Ez06ru$l1`Mr6Fy;vIn{dDSp3L^hn7uzHU#UW`s4HPz
zldKM|XO8(#7fNqhmw)HAw|Y`wKEo_OTc=d1Jl(lg5fZcq<QRm2n-`jjS9Evpf_m5h
z+Gh#D@~fVhw$(K--e}v*Kpwz-Rn1#aLOzs>62&?dS7&6r_eXKLy*164+-A9gcR0}9
z>Jdr=um<CdVM=C@$$m8-W@Ds#i~zIkGt-pA0hKt{hp__v>KK-L8|{ArRt1boy!VHQ
z$~WbT+mtKT_4Q!6+gJ{ql5&|W*VU9OZBq`WC+U3e5tKWd<**`@az2)O9R?~ZuVi98
zscu(d9ZL^lY3=HPMaa_EnbNiGm6k-Q`*fE6J7AvB3qQQ1!_q~jbX|L;B~eP}ur#j?
zd_voSu=rWJw<%rUUTH~`(w{yIbF%CSZIEhDhkE}B-RQ>lib|psy^lqQKcTN%GUo~I
zG)0@*D=LXnv=l`tBv4b@i=bA(M5a+*2il{DxP0tPP*dM<<>GXKV~0xaXjd-mP>vef
zq5Drw@>~M3oo1f5nCAxb>~^NkCk%gAn)q7tEHKX$lYcm#+cWO}TVM<LJ+y>LP#=fF
z(B$BN?TU+cu~?Lid#I=9zj72-59|#zAm4+Fv@wD*9+a%qq^g#j@(KCqeXf1D1oUy)
z#zhq|u0;WL`U6@FC2|+gV~*=jC?-&FWEr@SBO8LlNaU}2Ct|Fwzp5o~W;z_Y!8{a@
zTZMx?q^LDe0}MhQwH{SKNR6WyAyll6K!}cD(k&Yn_}AawYvRYba#PEG%ZKHy=A}~%
zcJfwNLd`MQ*;{>=38s0g?*x{}bBL=w;Ul8XU4<gbi($*iW28vxe-^c(iKS1V5yA!X
zO&!mr7+BK6M7IVqSIVvhkS<@f9FW-A<lyG+s+0h`-Xa9p#dP%=HlK|nAf*1%AS2kW
zPqDrai3RngNvSyHyhJAou@AuZiG0rjA$Vfl4JlSXylxtjVH(mxxJ3qWb|PZa5WY>S
z+5g0&x*^=+Vnd_^8p7>zHiYRaJ=Tz7^(~kLRb<!aC%1c<`uvIYQG_HB4JlTiK*}Qf
zlfXIRZgBTVz-|bxC6OM<CE`Ys2M*;XA~p>PnTCYaSLkE*NTX?pltAr8gg`@>uJSej
zNV{f2YLIS-U0(?RRiUXblvp1dB8k!?ebJC;3El_gh{821&Mu`4lm2FpT87D^m?<dN
zNzvSn;J=1N>kO-T8oqy$45AT0FFrhv`JPAEdi(FT`SCJB4ItDW@6RCaefsCd`&%fW
zF1lCqRU(hVVP%hZCXijykn16{4q+QHVM5<bl1lL6ydLlQc_<*H=9}?8TmxXdQ;*Tg
z8G$Rg2K^ITkYTH@&V*+MAJ4J6A*L;<RD=MT)6ctLFs5~}lc}H1ZOnvSH0^DATb9Ue
zhN19}?(YKFspuAb{|c^B>NlLoSR(g6Q*?^JA@u~*f#Z`qKsuRf=t*oEqveMiX<A5G
z5lnY113bttB|3OTae7kZh>o=L-MBub*r7<Vx*#6cQiBVhEH$_)9MT#Lt_s!Pjq66>
z3X^5cnH=Q2E6Em_vIG%(MvnO!O?*5!2Ea||34ErA8r#_jum3>%sn()KwSbj@BPBo_
zr`{aGBnJ?05&UiVs~nzfp%oFfPKlb?rc5raRfKz<QesYdIG9?biHmb8L5&&#wdG)X
zgr-c606O+<8VpF)+s%us2nCbH`uuadM!D!Vn~+5!mrc5>`jNe1>scGFJa)htchEls
zG)E%)4xNoIrK|l~#I)dr5rW_q1rs@Zs_~@DAl?L7R4+V3VJW*@cTrcMIt3+9=?cg3
znH}|0PdAo(Dbe7rpKW**8jxID2nIP^%S8@H9}`t4LfC%f*=S{SA5(QzOV@JYMu?ae
zy5YK`!5WJ0&zM8|+z+)N6tTo?mH;6Y9SVZvP*e!sMDx}r<R4B2@Yk{ev*Ehm$GU<F
zme|8ou&~1lBnK5NB=`mH3YMS(@!D(jkRvcH>$Q(G`s)e*G}oFae0^K=`c5AX*rkBf
z5^}WYV<RpH8ua}&dH@l9g+bpy^pg$xrR|}YM4(^mpx-F!+o0c257)by7rgWO3kEQn
z@^cKvEXMUbTg6J^LTpq(13?>t7liT)6hBX7ijBtZIcUWPo1oJ~f~e}wM?DxtFvggs
zHxk|=@uS4JH`H8nGoa2U6me@PMX0`ng7np*`9}G*utBJlN$L(%%KYmQu`3}{(?|e-
zn6A#0wY8~gUsiRX(~Kz)e6&j_jMbfu;;PQAS2o?mu4Ib}VCBdb6&jnalg7*TqFK7g
zjMPa6yU}}-z};wqV!T`STMWQ(07Qo2U#v%70O2H3nE#Ysn9p18PW%psDdKwMI)N&a
zFR-wfvmg?RrV0~Gh19(<emm;T&t@M=K(Mq9Foxy1hMP=Mf%|p-QbZh<qt96jDQ3F*
z8al|Hk)x+ZPqrIYj&HLW0s0JEE}&m7?k4Bs$$b>3svHFF)txk^1Z}r-vAQcl@qf>`
zr~j7q+s=0UZ*#!*KZ@5nsHV}RfuRtfJ}XownrJQ-ygm$PjC1%X`L1SI-r%5hnG8Kj
zhh^zD`B7u8a`6&004L`OnPO07t{Ngnm38L_u%hI=U;vxl0sZ<;V5GPDQ<PvzQQ5!<
zcKXE>$#qml6LQrRX4TI~1p9cX!5R;I+JG9%kW@vx7`l6`bCT<bw>W3>Kx&3@3Bpqx
zx5_o|JV`anIptucl4|HQkB)OTf^U-rKmpv_E5+58c$l*QRyvN6@=LX0Y?zYjK4P#M
zbiBk9RNvBUQ@w;CnjZvhgtZduk+t&fEc=5N2J<iYBPo-4E?50yDI%x|ZhlkKCQMv5
z;n9QQ^CsTs%8R|IBNR5c%KcjpnQmo>#{A(Sb~HNAr*bP>TWi(Lw@B}vjPro+LzbS{
zl(EP<4IzEz7;b@kxbILPc?x->5F#&%$){o<Q)98_tkozdT*1|#z7jNYK4zK7X)?=M
z|9nrZ{i>Fc-g$o)gT#s;NsHS12sHqcz21FUfVtisS$@8qkp#!ra#zL#)>x{3M>`{I
z-6T19N4AVFo?L~PMqQ0i^nKC`ueG7~MzqM#d)HhSy-$-aAjS7t|3Fz_Xg^He80U}~
z#_oreg4hThdq)ho^8JWioUp=;5i#sXxv>}PR)6z1v+VI!&(uTi1DztTy3%=0<Uuu#
z0w$p^v4=(Tavbu!%dOP_=PGhN__f-43^5toL0WNj<e^Y{JA5FHY2W*9;ZcRFqQwGf
z{8=B+X`shJQ2qTb*LmwPuW9SN5#Y+l)fvW4B_eU-o&F_B1PL4gn(jYytpIKnauCbP
zy_tE?jD;%2P2T0Gk;lx<ir|e`b)B04t?nlv>a3NbE*--<B@uOc9Ig#Fbrv~wa_53|
z7OCISmu0VZI-^c3^6;*UF-h-+@rnd|yUrv$Og$sKJRb%g46klF_R|eAUWUZ?`e+=k
zGBS1C9G6U;gX$wc3h`FUyQb?!MnBgvcKbYYNdHX-fKHTkh-o2y1|ijiT>*&qX+m}R
ziJF)`SS^6GF=UYsRjC)nj)Y1xyC;1`t-9s&CJ2L}^iQ*0ls1CMXo4)ihdK@H<!)HM
zwG-XfagK@HTVSApJ=O&qJvVw98uQP0?6wb#FZL2<5K}DMU2GWeqe199GivXO0e(3v
zMt5`<a>A$HMOrPiE!Epj({?K}!M0_^?w^>uku0@$C5F9i^!Rb*J(vcqZ26F;1+@o5
zc>h%cK`{F{eJJ~BA8=<2(*q-s--{>7`tU7-G2mUiK|0)e*-jen{oP6=*{jD1!2Phv
zQ$s@6i*`ZUtw_@ZT+0w_u0mU9sGH%@l{2MTw>^zKjEg#8RBuq_(SVDN0D{vJkkXYj
z)<GIHNby#QQJ5j_s<5=)fkvp9wc?-II6U|cS3~bbYgx3C6<_gt<k*qBq20X88>!Cs
zCJ^@b-?W?ZJVQ2MFIgVzO9pV_UVNWW2AA8M0U;dY0B>X^lc5E4qwoKV#zM8MnlUwz
z?A$26k!0YTnK6V~gBffOzMzX&%Lssfrafof?rP6FC=#8~wrWw>zrm!atNyL2n%Y^N
zX{rvos-|jIn`L#(lMtv{jzeIgHnX+J%*NYdRYy+;iyqowR7tsc9T=?^-B%_4O1O2S
zJ<U$NQG(~#8LT73=2fr`{4>p4=&Hl$kYDxf(`_4b|4Jx({em90O5ZRH^j7nbGg3~|
zDOD|#z4K@}Bk5>K3ep#NDWW4x6d>hiBR&{$J>>c`6t?;}3Eg!<Iv#kpRv)kM0pf?(
z?IK?ygr4B5r*c>#Wk&2B<Dhy<=4l86zc^1*=m+r%Q#z_v<?dj=*zNZ(gT}(zOpU#j
zVzmwDN3<`}IutbPOIS+s8q7)j2Vc^biVUt~TK$-cisMWpZ7D-So55CfUmal3>X11X
z6vh`uWZZMl;?66zpfe>x2RyMAs-MJEvYvcRv$N&I@?F$;?1uo2KRQ^AL6BCjs)vez
z#^qjZ4lwAwn;Zn}Jy$<02fxQ#y^leitLilBVvQOI@fmUJc*Jzih7baW1|!4A?y6Gb
z83Y=i<z4U+3CGcLANFy!RLJ?3&?4tZxp5xf_M*#{Yvw`_ZNdO|8FJb-M{=&Z<r-`w
z&H!HL-1vE>yy%cRDc_F$8LEk$Bgs`o#1arJhKivEOC}Q4B!fka$9O`_JH0~7uEfGK
z%+5vHKdjen5nZ#p!BPi^gyzJ|@LaY2YGAoju;}f`td#}}2~;mp`9V19+ruJ>Ld$$$
ziB54A&9w$akSM|iMPpkOM!Eg@TBDKiRt14jUolI*Dsxm5dn8wV5380vAq$;Cr4Wq{
zg*4>9B4USr#}s27gqW6%!3aSR0w<Pd5Me11=A$A;Dj9jB1`%y-7pjluYwU%gFdED3
z9<prH_r62pa*)Aln^xOxL6YYf{FdN%#=<1eJ9zr={8#G6|3uu5z6yn@tsdlVWXIad
z+!rOTq89067Fr>m5^L_uMss<qcjM3xTNmh**tmA?L+b2Z&=Xx@kL!KPWn6!}*csRQ
zU{}`TYxG#)AW~_xr65JYgn?kruLacVt1t?9SG%*RG}n}`WBIkT4NxA^k)Rh~#<3yu
zS^gG)Ms5%!a4A5Hv+@lR4ir^okhH6Qi6jq5qNg~6$ZHBWvhZkAxC6};P^l~&+mR4O
zvOCsZG-erzyhf73R@O`QaDhX>>Wr8kE}LHzRq6-JWybq$Sx=0foT2izb<TlhT^Kt!
z?oE};R=XybyTm!wj_Tt&HxSc*W}f+8CN~+{0oC_9ve#S!C6wQAeT;J6GvgTPk~_k<
zuNcA5q&#70di!}ky)sFD`(Oi`ziIfLi{Dc7`%fH49nqA}^H>Gw4)>wtxf{j!fz0_;
zwe+r)zuxY`Ll_EML-BCkmz1aPOBz*H4ri<H2yZpzN#1?J4i0yA@NroR3H^;#xyfZ2
zu}DgJrX5-1;kb(SvEx;_NpLrqVrx7i?_sOq1)G)!5Q-dt!E9IJ+T@lYS;6TE<r#_W
zDWhI*P_6bPEyE5!TR1XI80&NgYZ0;jmA&rNEW<r)9qzykBMe<~wp$Ls8U2vR^C_@H
zvh8%b>pDB>u7#k`_ZDX@o4(mV*HJ?rbOYjjlDK;R^t`UON(ELlr#_Bcco5g2=BygY
z>6(tS+f5vEXy;`}3RN{G<GsfV5afVMnsKPUGtRFLfbj+Wnqzx|r@>N_Weh#p!mh$Q
zNwSP7zgi3HAg>;bq-R>P$JV;C??E=lzfgfAH92w}PRlyG|Gq#d+ApvEG$N2K1;6Uz
zMo^*=tOlGIo#HWSaLPZx^6pC#o?>C4qZ{10#3~L+;q`q>NQ{<+XjUlf-U&9z80M7x
z9ki`G8e{*L>9PHj(A<q2eEQ<do7Z~H#hDuygDac?dH5dJp26crH&PAd4atdjX3Ax5
z0j?UMZE3CljXi`=k(yMki{#4YudJGBQ4PnGK}^8{FqxWwy@DktS2U@zoNm%{`%LLO
zvtv>RK=p(4z8<hNj*#|CyT*C*;zaOc6R8PX6@P|24qe5)>t>xYagC8T*Ld|{SSddz
zNVJ0yIf;(q12u3}OJL>+i1xOl!{_89x{Hb0ei|-3zh7++fWI>YW+K%bO8<v32&IMx
zQH^Hq30K%`z6^d#<169LKhQ08(A~n2bjBvGu)^9=0-cfu$Wi5&e(lXfmwxT-&P60F
zR2dgPF51$Hj8k%g)5dsbzg<vcee@KjTn=#q@s7-#l#y`D&_>ZO-`txojt@?`#NyC@
z#atJMzC=!hw{95{^1SmZ5&K5S_=aTUeB+&j|3VTJjH&P}O%fJ}UjJJ*RpSz<$~RQ)
z)rP9Q+EBHzGDcPO6!5I<IlG6=U83Mxi5dg%HDxtm-)x4|3N_SD)s`pn3)yG*XZq|o
zQCV6lnAnUqhK8<JyI{Qnxuuv*{-uKZZ&D&LeIZ74NE^zdSJ~X!m!r4@sgAA0*E`fm
zF|@GXg-GN*%$8trcU`Ee<)E2xU|7j^bolK35&dSRpoAaAHD?R1RoIf?7!zFAXk5=3
zXmt>{&mr^(60}KqFG85HoOe_PmeWtOL>ItJJPNV-cJaedoQ}?Nr}(+L_y}akiavE_
zXDY(Zv*p$^UMv&spv^~fhOz1V9JWcchp14EASH%?sjaRvw9?A=WEwTCydR}0{FRUt
zwJXIfyhOOn!R%LGVGSvc2fp%)bFzBaKlH5OV9;CrItn@)M>pY{;>1=@Y!`F8-HfZa
zb%nDtB*PaFjRb#ACP_29e=eRFE2Jv|FUJy76XBNsPV54G;;NY`_tKaK7h_val>1Pa
zQ$t@-Y6j~PU`;$9Da!RnH`Mur;`Yz;E9{<bWGHMsj)yh|jzH`_9pj~i-0{50fxZSI
z*HT58eztK(i)bC3f-ZBP)5ORXsEdpW7O3ukQXgL;&ZT~AzN`)IvlkYo&l;hyqI)pg
zht5%p6S7ZPXm?;LxOkqL0@Y=+Gr$6OVFw;&mS$&=DJTCyv$NRgr$Xs=IM&pQH&Q|j
zJC9`5a#*rh%Ek8b{p#ZdcsuJ`xFb**JQ~J7aTi?@=qX&AW;P@%4eAngksI~rAX}rZ
zCF=8Ht_;6g1k}`Z)CFohhAez;hYCV{30)maTt^j+no7+jboHj5QnfcdA$Ak4Kt0+n
zu^Mf=WW2E^LbOXl#x4n|f3OFEu`t>tv<44|7-WJP8HquvWtrIOkgUos2P_)hNKzie
zv`G%j=0FouexREMrEmkB+>qC7h^tWZ=edX*g0;W;2>-ytJ)BWkCST63WbHCUyAbM9
z*iwL!FK2IJ6}@HJF&*`3naxcPdA4PatCB;-F=Q^B+kKWRryix$IN`7PBsU8W5#3`D
z*EooIOMu$Vo%bP|0uBbrL2VAx@XAE*;k_uxHn?ZRzCcU{t&u3p#(!sLPlue@>JF0{
zXNH~oi~pusdE2XT{AD<{5~jQ792uuu_wVD9cFd`ii!e5TAi=2zG)8eZx{N3Yh`6-6
z(3}hhGdW~@%=5Ko?SBpKaoOr-giTMjl&GpmODgYWFO5^+F)w|*E8GaFNefeRqN%G>
za~Rpm=N`=WCQy5tcX=?atx;vyhxU+qRERHCnwEsp)D0Mryg4pv$wsa=VYk)*8()Yx
zVDX{-U<U$Y5ODZ`MJ6<9Yu27uXYwX*A3s#!gF^g`T`J8kg@98kz}!G<mZ~+SaK#vw
zVcT`ByiK3Y-%L;0o<!>drMTPZde)2H8UuE16O(OxMf%ti4*o!aP;VAf&*iFBG<7Kf
zdG!zw+3MwTal9zHd~Etuttx8UD>3=C@q?e%rpIlo(tV%*b25QZ!_Q=uK6MKe&$9h>
z_%T@2m?<=I0d@FnM^pOL{0kVdZq!(55P(7}jHosg=Q0Ep2zGEk=_XDv>{Q#<m(-)|
z+PAYG>=wrCXACMdlCNV_HFgeFHMfv$h~Qle&m}T>6{U&#6}jSpzu_UDw`w)h<`O8=
z<C($t>pww?^ZxwD4VWO)kfnxlmH<jWQTojU=~qXyCy*S_6J!8|A#fc3>@~t-k&lxo
zthK5l+f#<+lTZ+Z2vJrRK|~Enh=j7EedFVCvCIaN85+cvk$<5@dA?}s(8lOc*bO!s
zWCeYpK`R^xlcQ_oSn`G7pi0|8mfNh~re|FL<dP5=7_t759t)a<GX#Y!6CR^+l7~S)
zyk;v(Pvjd*C+U2v+hew=ItQZY(J^ivmm>Pra%RfT@)SfrG|{S-Bg>CN{8hw_pKc9;
z&OJXrK1l1Hs{MK{FF8cw?0QGUi&cJ=7V%=egIug06YEY7)6fph-u#{ih&xb-#reDP
zu8`0q*g6ruyNaAXI)~nnk%)G+qr>Mw-C3I-6^2x)A>e8%5;h`156=$~0>4uu4+Bx;
z0sLEo=|Cf0ZHnO*?h+JwOh-|B7t~$_nCRh1uCt-?X8IAm+Kv{^=@m}RfoBx1*qM^p
z1>*M1B1}1*8)SvYg~aK|(UcS+6kUX*V>Jelnub`O18^`x7)WWsGE+VU_#wU7Thn~o
zB%W=6#5M06LXtK4^{~9y?S7@W<U*)Wy@wFY;R5mt&s;u1@>P!ryU~DR#3~WfEu4W6
zcwLN)AQ}>!>|IcceOYdI1u-cfJc%x*>ZCg#misKz@Q@qQfMbN<;H7y7Amlg!cq@e3
zh1Nb6#Ee8X5g%x)P@_N_&+718BbTrDlD3+~`euR65K&GqI7(`^V^5bwr<k@CYT4Pk
zg%#@k3SfB}_qZQk-j&NFV!j8Sd+o)qP&d<y4>waIYVnlqLOK|PpC44uf7pz}axCG@
zffph94>Exmk`E)vVe2FSYc?IrP}mCb0p}o{muB)YE2*ckE_7BgPjR_{YQ@L7$l8^q
zq?--`10bu1*me(~GQM3#ig>j5x8-~3Wz%f3fGaUISxjwX-JdC|7&i9{ED3?ftD7LG
zuPGsajF($l^qednOpDIN+t`seaH)d3>Pzja)d8>%&XpHX&%6OjC1ovcgK?VE>mqD6
z-hi@{D^L}O<3I<;a0ka;ZE?JDA#h9p4sbD9ittXFsfd01kj>=J5rQmEMMgekF(0z{
z5pIy6Eb^A#`%cudc+(>yi>Y|nvRE%TD2sO^6fcW&c)ZM(#i<D#xCG$BeAUgN{*3F}
zaG)otp8;Cj+&i?LviruB4a4&S$y2M{J@En1MD|O-^<{lqI^O+5935sO^D^Rscr>FQ
z)LvLFb9u%{$gb^0BYiUXE@o{{!MxCR1I;CKS4yr(lZhmY^emAVYaK+@ZbXR`ALdY;
z<#29b9K|+0YiGJT;3JUYX5x1b+6|AP`S7~9hEu;?2aC=baN>g4RaP@HG78nvPzfAi
zh3a*9tuQivqhlArvcn=KwoNVFaUN$&TOy7JK^%23K5+C1y~UD#Rc6+>!o>Xn6S)L0
zg-0&JKR5XYw?qEkZOMQ0{4K3^F?3Xh#}osl16&86oZ9a@(?wyut4<bP`GCzb9#W8d
zBRn&A;V8+)N0h9K5?VXQxTK{eQ~74QK<d%{ryCPkU8n|uRt(Eir4|lS&a=lNrZwS_
z2w{+xAVc=;19D|W&TqZdcR&a+Y;z94NqlGt28Vj9SD4^1Z}oBnBX8oLmO>vwYAJfo
zydqeKIHgn4GvLXfrmY83$2p~)M#i1_Dg^)#4F)3Cfe<_<s(KL-qX5sr$)^am>rH24
z&@2Ru?(78wM9qz)=rT$N@HQeluO1)JGWVbYE0fg47b9P9i4cS8b%rk7%)*D6!fRuN
z>HZ0!Fq70l35EZ9x-Kk!Ade~B6f2xbkw9T4sUM(+-8J8e!iJRqQ&(~d0^x5-adBh?
zOmQZuClZPmqqwZyY`Hh@2wfv^hHXRPb&pPLXMmg_ZaV{&K`2^v``%AEp(5S`p?F37
zoj46miFe`Wj^yB<JuJ|&jL3bqWXF`j8`mUAC>)OGLL2klUR1bTicn0aBeoPVEvC01
z1TmeC46bzGHspblP@wF9Xc++K2q5V!M<|}oW88EO1&L5R8UiBXVJ~lni;wamku}nV
z=9LR{6~~zxGlN}a+WI9(b&mK;c9dJKb~f+fjr7vZ`RrbDfXyidm2V@aoAWY4Xih0I
zM&LO@pCKKACXLAOF1U%^j8P5KDPvxt98mhFJv+MjyGXFZ)M!j~bawgGZvNWz?=I$y
zp??TybE6s64x0Vr(117BQ{-M0Hdx)I0CxRHmX9Rgf@G08i#&h=H?XfvX59MZ9^n8N
z?ezI?Kvc6}Jwn>CUdZCllI^bI*Pytw?~z)EMgeg#Aus3h9+7|y#JKZROLU@5!lhLD
z81JN=qfYv2HZ_smS2;i!p$+8b#{oieJX`mK740&k%x1w~C^%s&Nw*O*6St(kS!%bq
zjOPnKW>nr^^s)Vjnf6OMofaTBlVbP?7WmP606pYj5T4!cl)0WEG>G6%gZ?Z!$n-5=
za*WOfj`K7Q2pGr5WCz6rgdk>R2jCh8n<ewH<>RoVJ21pccZS&Qrh>1*%lPas+*2!0
ziMjS>gyS!|0r(<NBEbD_fU5xj0t-B4T|+gTy1#%?6rHNW&xs$t9CtUQ0SqVPI?+S{
z14}6xQ?6itLmq`aF3E6a9LWJhCBYxQl+8BA_*?Wb#o5~vTzZpd6i@^U>)OBFg*##I
z*1tdeDao_7-@C|v4L?5rmA{@#lRV?NdAQH^{Ute<&6;w~owK-dwr6&)-hKM+v1dQu
zUj6sZA;5sMQO^xq`MrTW{`R^DXImdY+wtV@cjjrwx8>OzFO|HG-`n`v@cRNMe|G!;
z9HSV_b`RLTzgWAa+%5y`t9Ij?J)r;IlAp5x^|*g8A<myWjp6s|V`=w4^uKqew~doy
zXTnYn{Eu=V<}a?m1pHo|7zJ1$#$Fh##T2IMIcLEfVI-0QRc3$cc+C_}NZh*1krkZG
zQ$BUsM4jwYhm~?M?5%!;Ga<fzrE8G4ZEw>_XCp})8<P=otf`4y&;oOz3K$O*OnujE
z$!Rb^0G~P-CW*5vQ>>OwC9#H*O%oWgQk{CaDQ5lSR=dt9LqG+y#~l7jfuV1=6=$+B
zp^6nFd{}BumoWl|YsC)vu(wCl5|2h#ZS?2K0k{Gf<iSu_j_%PJe|s^h?r@*guCpC{
zM-E+=h-|{PAp_Fbeunsliy#{86TERF5@RjC#kMQWy%_y@8Agt`x-TFZ%=1=11!gih
zs%&s%0M>K`5VQ(pI}4;zMARu_2UY7Y-Sz<(JB(mzB7C?I*~6SIiuXly%;NWJ<E06;
zksdivoU7_jh2?grW2-GQg=O{ns40vsqy*8E<Hoo}8inb@At7vdiCRUc7Vf{k*_N<H
z3`y4WaIoY(PJx2UnL>vRAmhm$C8Ni*?l9L174GAVqkus>Yjetq8&DH3Xkf<vCIhY4
zw<jSlo@@KC0pKTDC?8F7S+&B}4aNg40IT$R@Xeb*u|A@`p24v793FawI1E<rFnoVX
zu2I11Zx~j83r1-l=?J)8@cpSwJZvB7VwP`h#FF<4!DKjPH+vJ^7&dvMb?qlPMUF)%
z=BN@D+XcTE?<$y~3;LXbJs5%kt-vZZ3fciaWFNxdyWBqFbeO)1RDD5p1&!fgmsO$R
z+Joq@NDclmTLkVCV2l&E^OtD*J`G$}bGiJify2Cw%v3NrSB*Rw0*4Q0n8iV!DV)v1
z`BGT>L=wu!d`G$JpV%RZiJe)?j-AFttJfcGmU|fj8)Q{H4y?|59Gq$^e9sw;Co<3o
zGJxf^8*MD>5OTDj$jt4=w<_?pl&tf0p<A3nOBk~G^(c-SfnWFnH7>~jMOml)Uh~V(
zCLd?~8cUhy9%i;4;962=n!!>xoeeeJlL;Kr<D7Rv`xw-@MExCC(O^JBB5I=4i3a5j
z!aIZVF94VC4uKCZ++g!z1w&|(u;6a@u&ELBR-FTSoq#6D`h7Aj=_;b9+Kr1Ju9ui)
zKkL99u=d;|RSq_eamm}m>3y4`Lqrp4^jHWM0Rv{Id(fRVe@XH*;`al7(WjF<r{FjG
znIzBU_+5(pWAJ;C-Jbpn|FB?*!@y63q^G5)cd=)mozMSk4&=kt;(FCeCT%JnNcsoY
z8RO4ey##6kdznFGc)ZmCoxeioSG5#*=QV1He*j5ZyWhzWL{Wy_bC6WHnT~cYs=Bd8
zk9V=5rd-HD37aKuuyZ;@iguW(bTcoo>WClIIPVL7f0ag62MSaVgDMz@ibIQZ5G8U9
z%5!C2t`^^0<PD6h2DT0pDd^7l<XU@%om`%8XK;pH@5&ftXCx!zVJBl!`L5vJ9f)Jj
zOu<ZdJ%TnUkuP*WbG-95qf$GQ6`bqNY<6X`l4G3A@!okWNp9FW1Zk$CAq?6~FT6~c
zjyt`~Tk+iur|MBoZ4}25tm!yTkwZu^9J-daJa{Ke$DX?<dV-^|?>9ZzNMyGfWW{mF
z+-ygVLHeyxtb+73_Da~gWQj;xRm(}`^gWg!s-@^OhA=tj3Y@{P7QSVNESilDL=BDq
zQANx)lJ^o|A$iB=HDKqNGfnF6w74{p?$2msp-^c&-8DRA15T83s%R$QNFmy+Af}#z
z>G~|Eifd6Hs(^DZLs#*T;qxYztd=U^x?^74WTtDeUywI${0*|@W-9s#b^+<|In1j#
zE!K4V(^ce+Gii{k%C;RDf#%P~<6pim`M=g<+gg8n@0W_wTgVQ=*J8v9(A$#5vneZb
z$K8+aE3onX->V(fs72FyM5ov<m)vDXhtK9)0N2@3+~YyxOJjxPg;YSg)Z8|D6RbTL
zM#I?QGEBod0ecW8VIADNfPjWEHjp6cbCi~ODRZJOBOpu&2}sLmElgPUn5%ZGWuWM{
z*&<ybB++wXX0awHAERHJMcAD)s7h4R(Q@T3Gm_+93ksUP*CK!bzL3LZCm4r4TT|Du
zW3=GbAv+@fc*BVnTacHlCev*#yq0J=yaX&vGf&NjL73R)T(vJ71Q2QS85(4WQ|5S`
zV2<YGs&1m~W39+lpB<@dlr<MgQoT9e&|*d~ZYUA|apR^v`NbJHe|{Lkl(=laMKtAB
zeE_z<XYR(eY<1X*Uge1P5wgay-qtB{2~9vJt(GJn74%l`p_3jqNmVWR-rsf6X}2Ox
zEAnd@!uc-&GI!7LQj=K@#Kj0fZU)01@nK2nOYttimW2p!K>ZHVp`L;bzzR!|tWR78
z)WJ~9Pw4qg>sZywg&<@o7^iJ1T0tfURBvcxRsch$H!z`2-}g<ejeFyXy8Vdz@sv{q
zN&5Z&<g$^`%kp?rHOR^8vA|`!+(oeh+V-YVsqOyrFj?Ss15@~K^Ig_Ti78y%hSXwB
z>IEzuJ4n$C0@OjAYayhJM0k%f3I4tb-S69bZFq&vK2I4u80ZC3Jl#|(Bjp=zc!IR}
zIgk9obVvUDh{aUo-7T%H%dmORgx9!EL4F_<Hq+r(I0I$V5IxZKJsT3GmKfIsBhjAv
z&1T71CxhC&)H-(+1@1p?eEr-!67z3y)Ioxu3>(`eSUwQZ`w`V5e>+1le_T&#JjP<Q
zM-(prIDWd{Oe8P2I!4_z#m1}R7()l)Q@{`jeGi;Od!H`jWZp{giCMihfgCvx>6A2w
zWN-B?NW$fnU62GLW<La5uVhdkOhf}=m_T;bmI=Dc8HrqkQ!KjbD5?hLdGpYhj=bGp
zsf9cf!%J1sqJbUN2#7d2FMt7rm!D#n-}ngr28=6bck{>N=|{rA1Zn#S{IZjYi}Q_o
zUVM^bD*06tAnmL02BHD*O;xqvO4Cc>IYY1XK$7m2t_+1OOT%Ea<bwCPRVs%;sD<3$
zco%eHAvvB@lkwCL?aKQ04RK|?g@?GZ8bE^Wb!%9}3VC)C)B6IX+nF@k|LA1m&Q#PK
zMqHCJ7a`{~8JAXS6`KS?VmEUZA~}SyU8v5M6_9D}2gi|1)=0sPmg-Xq0SEOy2;ojP
zu&S7NQ(zvLcP5OxqJ|DF)KtWyH|T>(Q%{lVeXP!jz2{eJ^6)tsNS4z%r-Ft^Ply8u
zS-y~s;z5@C5kjMIn-?mtW99pe(+Fd4_thJOC2ENqVOJtt4XMtn4?=65PMko}42G&4
zSV?&eS>$<5mQU<5b5Lq;@&#Z`%u6(|MZP455TvGD9A$=$H_H5&p%&m8&+afMAojbH
z8>|vt*TnRzAioha?Y)cy-FMF+<TSIHh>s}H&BUvPrxM2|)5ub_)-WLUITD_;3Wa%u
z_V=>HGUV(6a^&vDNFxhlFbCDO;)=5-I5i*bu30qtI+$bRfJF8Hqc|XM6;=^L2>Kii
zo8=78j9F%Qf(rGq?APe?mkI2v*5@$M79Z)gYdD|k9S6KBQ3J<hkge4WGE?x=v5^^6
z2SJ{q@^T{S(~auSG_Uq%Nh^P32??DFuNA1J(L80oty#VE(s3+a1B}oB<E3h?4uWjR
zlT;iai&mTIf<j@lIZrl<{bL`Sxa}B5tk!vUfBpj@7e#(m0*Y`2B^q5!?4@+30eh`!
zv<OzI!OujsPF%#MC-Z<mn&${eB~kPrt5MMYcXVH^LBT{d-;H7mq$V=xM_#CEoe1jm
zVVn`z7r|Ay{EqgBptt&I6pK8Gf8>o{oq7(LSGK!jSNl~Ra7L~Lgwy@qE;l9!iTZ?9
zqLChvR@at>K>?{E*b10gY<?XO@q%9gN4GZ`@|mtCK+p)ZRDg_fZ!!=}RCmc*$M9$m
zG%(sdj_KbpAC^XJ+F3wt1Z#)W4oq^+c`zAp=g}FjBzYdeuLz@>&#|v2d7i-U@Ym6j
zq_*D^HYxnvu>P|@I=u5k!*289zb+iJm$(<hVd7JHkY+PBVF#;4(ELU-_|yW9Qh|C+
z{5nRHV*g{VXd{|YHIQYD$`v{Vvv1jKXLQwHqDNOH<$VEl5|AaX4$Q`KvYBcFR0oAr
zqjiFrMt9oTC`y}zc|PWe`V4cee44CNWf=L?23c8K!yIDDdw{k9i0YZD4?>YOg4gnD
zAW;z*NroM>fG%>E6U_#9;*^L_olJ--Kse1@H$ykG5s9jf^q`r=aTAE6L7E6Nhci9e
z6J&de*`8)3htQs&>dSQy@<L8qH<`SUx+peZ`_$(lR%9GvKJ=$Li*q0J10&E6?BoBe
zC56ZzmJ0APShaJE2$g4R=1A+$6cYfPiJlncMat)BD44J1__~jEGNQUCk3)zDttrAe
z5K~%oIJ-a&J}uTcaqJfD4j4)FP?TZa25~T9o3CfJ>4gfW82&X^<LKaPzU$YwJwFg)
z$wKuC>@tW^XHrnaFM`R-4R~*f6N4R*caO3CKoLipyxSO{7XzXsemBf&%)m>@CybZ3
z978|zN?Sf~x%M+O=gFcxp{IO?K8Ia?kmgaBL$J_oM43Vw{Dsg8urD)bgXQ?b@|00%
zd>n1|<q!J{G*RHpKz<Utf&@#`gX*G@x}1>i#|yO4Omq4>jg1K*MV{N!FScTC%Wusf
zd6Rw5yvMP0!3=HPa~Z}bC<>CsTy-5508xvT;^mB0{;lvZ5kHD#^W)i>7h{JJ58}hS
z+hfueN?S5TG$kGX+QFNMPey{sB;SO`ikabXFiqrwJr7-J80l974>uhUP1g*Ib;h=e
zbldt%h^o}CGZ2f#gi%=PCrP;lP%f3CjpQ{wj0qOVZOvMF9OO~cV<5mK-^It+_~c%K
zP%IY1j`p(AC|l^p?$hE#7PMxa3GC6%y32g%vXXXKYm3BIpKaSOjSJ+5Lz$!lqYccD
zNy>D3MYkd%GQONk%P_o3I20<(YkOCn1+hz6>wayoP+Zg2lFLN*X@*(z5z|U-CPMVa
z1<Ut=vOC{_%0aByftskHaweDcGJD{hxCe=^0G%nX=%T<7r@#P&w64rmE&2Kd6?)q@
zA`HMz$ktc(^hd1aQi*XQ=ei?;s3z`xgrZGI+Mpq@FxeNewF1D^?$Zc4s=QR)C=)XX
ziVgtSZ35N^us<-Q?OM{kOo*Tm{(_F(YOlvKJMb4{I+B4$1vZHN#g0Le4?<itJB=Zv
z6w#AkMCmA`a0b=+c~D*GZ=@k=dU~rv(VkC2U`TC+J^z^t;(?@4ohdUsq+V{4#p$6R
z&hLuv;ZbbpQ2-?<Isru)_ESapprc<05Q*@sOHPm#BkZS)XIS#=SV@dktB)xuEk**=
zp`m+`)q072o=DG`h3X!vd{hyC3B$7|nN)Px&rLuv*0&q7`Qf*HL}*3EC7?q)kVclD
zXlHOU_%tUYr##EPA-(l5O-&#=l9!@b!vUn_bqGS3!gON-s$5pN#^tCDUNj%?=^ttk
zY;B;oOTGI(V{ZSzTd@~BJrs?N=*HF7iWy$K;4BHh$NG+*h__`0X#E~JGUU9~Yjnz7
zox-D^)sG+v$ogZM3zW1Qh}t99qVxwRtnmg|@oht_zS)jTS!I6C-c%rd&&(hnUFHl2
z^ge*rEa{67r5HtIKPn>y32NXlazHHTfLelCCbF0YWZ3$9xt24?yY&IW;zz_TJ$=<k
zdP$Ok@bn>#Cs<Lvj~S0LV|g$cm#ySrZJv`;HkFSFWjy7WGqLP2K29v_!pEetA<^?l
zH`_In73yOG7a|xPkF=6l+Nn$nB5iyuZ482}H%WT`P{eR+LrPW4#BzK+!WyIjQ=xWz
zHlXc8wIZ-JMgK`5I1Y2lk8sP|7iC07Pi9Wpen9pf;+l`IGX$<zs9QyQ8Qv8^7WIu>
z^t-4n;!rbrBaEDaml@ZxxF{OD9GWzHFC<-tB=yGwWbn#WP#ByUXEL!5oVmJ(7h~W-
z>7K&|@cW@%^|i1;HIm*O^k_iKTA%&2qj+z?VBZ7I0uY<kaE@N2h;!v94hA#;s>|i(
zAPzaX8C1#GIO2D9WP}_c_4aiRT*(^dN#g@&B)U%|YjZ0k{^g5thK*>@OXdy9S82Au
zZXg^MB^)UKS&Nbm#`caRJ6A#A`qHHsL$)+wP-N6yWJ}Y?*d<F;YYUu=9QRw%D6UTA
z_8oXfA8}-z9+X7@#~9%a!Q&VVTl@0?MF6F4?PtOqCHt5#ta9UvTrRu3#*2K9i3C~G
zO%gG-+al}T3xTr6Y)&n*UN=#KqTUxJ%IPK*`!)8ce+H>~r=k3}sJ)&*a<=tugk&*G
zKR72jS-INY$Gx%Wi1y8^Ptv)?s`Ei?v<w@+vXIL{esvY95>;rO4SY#v6qi@<ath`j
z!lge#rRu0W7lLm4+6WE>-uOEzfF6bHo2GxjdRlJ6KqFC6KeS<EsWb^OzW4YZVrKj^
z1U;GyX4IQ-5aIhxIE3(0hA|TSp)mZ0<ndaWX>@O5Bv3$h)R5f~;oOEYG9SwUkTg9j
z{WJlM(3kJFu<!By>jhwmyb1}mWxaryX2}Xk$28^Kumy<>U=j*U^e%XtTV$}5prA4;
zvh*HO%U808v=|R_9D1?1)>REm81Z6&gvjG88Me+KcJ5*Y%XvS=c&FO22ssDo-ab>S
zI66L5w)n2}p@{@77dtTPLmlc#(=UufLZ~o0mM?HD&dDa8lmN&<Tc8*h=lGfO>|mXO
z1q*DWP}pn<z?vvhO?1l81w&l_v`D;Z)?${jb3R1Qvdby1x$5>IT3!3Vxxttc2ZzL?
zJ$Q^vkb}qKzI~x4mvxU8EHXH9)d4w>Uc3!YEQi8xCu72%bVrxvbACNau71x6m7T)a
zn6e>!5a%?uCq$fmIm74ym#f~}JBCvq3R$ebVgH@%vYDD2Tu>{F9w{NNCO6bIfXb_%
z<#0#{T{G0hhj*|-kGvt<l7>yo1c71TlgwVuY|zS?LzN;suOX9jNzIZRg({t_M-K*K
zz%fyIF)yRjhN*@TqBbrKRULNVd6=BaE`a<DMu>e{j1C+&pp|nLdasz`UlPUwAU~(1
zHS5b!dQEG)Iq+>w%)4!_Ge(Lm(GC534sbQ^C(ON075U+{@I@SUMpw@hntnrSZ(0UG
zy>}bbd%N2xCdISRW_B<8(Ubn;%lOKOe|%XVJ|=jp3C7?=Z#7@@jZ6bK@)~*x!?ISL
zt_Mg3S@b<Uz2KL&=3Hh#L5<!xV(pR%poJ_k+IS$as|Qm%CibQ3>)*OsZK2hXFHoaX
z?{rh|^~5sA)cY1`a+@FSdL<L}E@g?A$RTtW?gEXgw?bX!u9t5iL@&*2=&c*u(^T3(
z6zQf?wY5qmlN@1*lcZ8TBgWNhAFZKYu*dVRsM;})M5)|Fo6OGs1_&cx;9opUg&XE&
z!aR?E?2{Idsh&18OJp}pgfRYM=U=3jgWMQuSlCuKoj7sY^<PZfd<#LYKEzPBp{|Ao
zaiGSz%OB((heO>t8T-4+^m6C4iZN`)ZmV$GjEeqlYCdu2bd}lOlzG9Ovp~#elk<=}
zXEPVIcH91d9Op|+M-*!Te+y)(9wZ0Myk5$>1e}7c6AgKf9~eUz9RmgNO$p~UIyE8)
z8K;H;epWomnlAY+3Hm<9_d8v=WOEA{gxkh%<{}F|c>wD@yL~Y6-Sl~qXE}cTu|GZn
zzlr#j;&&x}cjA|1eoy0haTM<=wDY^`%OuZR$e)Yn;~SGaH{!>q{hNS#JiWK?53efp
z=IaS*cCjw$yY$xYSNHC{>u$Y!>vycT!J^m+^1sA^nEjY7dck_~Xvco^=#(4IG?rXZ
z`4kMaD-qQOWF<n5CAZ)dJ&tQJwA3*{j^o4~HQLt29AN<<R^OY6fDzH6k>_-M1MT{7
z{z()h5EZI{u={05atE_BA*&AS0Z5Ox`UlY`wuP~YV_S+$gqa3{znZE|2bi+vo~}E^
ze8fVTt<Tlw16<<uhiLP`&)p8(0Gb=B$*1?O%{LlgKFAtD+VOs0t%;-^$sjCxPF}-q
zLPXZ=lQmQ75LLsutpdVI6Q)pFq~J^`$*U*e)l{&UJcDKuBj!+;PO8J;C!iXYx~>Ck
z^gO4oT}@q$MDZf$ec-D^q`m55$M%~D-p|w+N~kfUUKkjwF}g4O!a&;0B2S4%mw8Fp
z(8m~wnpkrp16uS%cEbNZhxlbY$hH7_DyTMaLPu9Xb|{2vOf;7V&Cx4(^$=3TT{nmX
z7V})oUbF`}wyoZAyFSR16*%1tv`OXMKG+LUJ<xhG#G2G-5&+}@o;=Y>L+zw(@`lpQ
z0lG;)9>8inF~!t6xm>Pe_dcPzp~XIA-HI$t!L<zG{Id<4=UrTdc@asM+ewqWztabb
ztP+!?@^G4Fv94u25r}VLEJ6@rrlT4^8skHiURH^)zp6P2i}!9OIfKd3t~!P<$RozF
zneDA<1^byiz*8xU|2-wr`dMo$u<c^7`OJ~0XtvJ1wUtW@)??=&h$^#@DlY<i%60?(
zVQFQf`N%B0EJAKcVN=hp5*dl}Tvcm>C^jP6T~b^%%iU6}CpyPnayO?WDC~^<V0_W8
zOactC`l59DI*s!>MUj^u&5$T-WE2tZYWbqw*{iLv;+P%D#GQo*pmm*)I~eU53|;vs
zn!_N@g!7SF)}N0~Wme>7yP>Tu!ozgpjL_)PwdvF}Nxi~OHB8Y>GX=W<q#$~vlrs5!
zG>XK|!CrDSOJ})z2FXa|u;X%_JAgi(3y5po0cn^u2I3z?u;nx(!EkC%NfoDd4%3^F
zu4QfmLt*P>4G4sVXm#Q7-UYh=T<?X~WL%x9-5g6&lKIwm5gy{^&;(9xZO!o1ip=`t
z#dDo}7L&mw5*c|(FCKjZS_K++DoOHV@yXYi<T@w0ib!Uf<V8pZt$Pctbk!HibyT}K
zjp?Erlk6n4oGPvR3J-W(P~~{EZhVP%K^i9xIB~|qiSuxZZr$#w(mG|g4plX<yo}8U
z5K{a0!G6N4+KY3ull6Os!q#Fu#H|yUc|4-C?C9`0yz}>b6P1rMg)=6zObS-#D`1u%
zkBEAqw=D8~WFAIACi%l~<a9c5%qL<HIvvRNVre0(CyUmiXyj0Ut+Dn-oPPlN=P5SO
z*9fU|3Dko?K)S^q3YJN5#>TgB=0vz0v%!FAnPB1qVkttAWaPq6ngf5Y^#`Yt8isKH
zEgpso{1ne6cJ#p6JVRfiqfle%HvU-Cq_t(JAAloGIoT8{GCZ+0p)>e9)ND(@g7!5V
zbLe!)0S&to?*NX?3=jA~jz_f;(`g{Z^g_|k>RzA%5cP?^FjKT8zCK88nVY%|+VYfm
zl}9~&3Xq;6RBc^b7RMK*wk$@`Vkz3OwwxNTEvKT$R4Ed#Pd>z`OHeT{>w$RVBwNC2
z5sEyjQ>ziy65w5&qmwSQlXAVk<5zCb!KdjY%tCtcYK=pJmgyr9!ZgTqWZ#4bD8rc8
zr2AhdfzSYw1NaajgWz%?&AZ?>&b-Dq``6aZtx#5#7}YUl)sa@7zKvSBq<yVi0#Zsq
z$8<cWlZT|(o_`bP#nSlhVo#R>o_8<$BAXH>?>6&C#Wqq});^_WsHqG!Rp42XNNJmS
zcxF7Ql&qO3I8#VHGJ(_{$kD?I`l}1Nu9~CpI7u~p?{L6Y60}`YggKA~J`764h&hq?
z7@GmN5CG9kO%RO%or03g5bF6hht9_Y3xdV6i;_KPgG@Wc8ZyeUgftDN&8~4Suo43{
z+?7^p(gwKFDok4Z=n@|Be#CJnnqf1%93LgM4o6fEhhYd&S#E~TmQCcnZOB8*c^GAP
z2QnQYSB29}g+2g%IZ?3NikIqMD_(mh;2sV*g6~03-kjw5?k9W)8qfBARmi&$zxVNb
z2*0)X%>wNCv^%@~{9lp_L|^ykN=SoqrmHL7Eu%IUxTpM6|7Mye;|%lHg5Pd{8H3+1
zzSlx7wMa@&PESd<ue6A}=fXs~;GBBElk9m1zj;Z?o+B_Po`c^+{AS^IHGX&D_rK&X
z+1b{e9M~QXaAoE?&&v;)z|lk3!sYb2h*#l+E_SFNye(BNDe@T(Tz2Y-PS+5fB|W*U
zr|J){88#J;gtkjM-qv;pcj&0f`uI3#SkzLiCgZ4z*)t5PV%W)WAi(Ve-xH}h776^^
z17{9T`6!)uUxu76)~^lmasjM=;PC@tz?pRqQRA5LkJujOVogq{VSn9hMcK&o#}xS{
zK1*{GigoA;9>G$B{wzrW3V1>I521jBU}4eS$LYh4SGD-cgBpx$15+lj+T&wlKxPwH
zae~7{Czt_`ejGhOBeVC!U73QzySyN0FMU4P!55j16~C?lju^jpc^3lMO<h&`pYlCY
z+n-bc0ck$g2#D+U!%DDHEi<lHMk24^AA2KLdAL&zj{5TIvC%C)&Vn4DTFd?oTi0l8
zJY_mkAJRjiklJN;<~9+7U!7oKEBX)}KE)j4C{n-a=K={3WR?aQPLQyb>tL3<3<n~r
zje>p*X+q2v-oX@8u$`2<?lNRl{nc#mF#=y$#jkQwL->jF6;&IHK<QP-fTQ|WY3$hI
z!%rviktcieVXG9mn(%1|<uzcn#c@(ThE8BI_+UCy$*4G&ti$S3^^r6WR&sPd*RfnV
z&j1lFb$wZ@RQ+AN+ek%Qi+1>YmMt&2{Q9FG1bc=y;)I*G`Zf}e?|+VST5NxW4F_we
zF;aT6E9k|#RC0LIqleR$pgIxjZ=HXV$;W4eOsH_qp3L%x@DU;J(-5+%NM7iSby&g3
zh~{@nSw&qB8wKA9>JCygdpjc(8P5S(we4?)w6C>w`}L>1QOBPP+76jIa6-*7Td0gg
z_>P{I;1~U-N7Vpq1H|q2O0kf;*v%-WkC6D);n>ENV_1gWCnL`skg`t+`c*Fgfv9W}
zB~mA6GY=@+6H=EmRG$_ZR(2L+L2vbZl2(O(DDnw+am07>E<+-HJ;XzAM(RCDaFl3;
zY&AH*4;bK(+FyFl0M7(4PM<*j9mr|}S)}T{B+@`0PskBbQ2{0DK^fmB>tJNrx*>>T
zCM2ptb(a~yfb0$s&DS?E5WvmY0Y>5Gk5o_?{ftEEe%dltx{IR6lkZ<5s$2aDLeX?N
zWg5AWcR?79v!*|5FxxkR^Api-8Yh+qT#x@MilcpT+wRoF`x=~k7lxQ^hJ-hpV(_B0
zN<yyr)~8yateu<3KFQa5DX4CxoS{1~>BjB3oAaqYb+=Jmg{qs3dg(8pnhNKG=B!Vh
zw-@`ynm)$q5gx!h6;a(IColxgW12R){9Ktiv@XX$F4-X+7T4an8^z;^Ci~3@^(l+B
zplv=?l}(xQR(t6_30u#G%ux4Mb4^8<67?y3z+!&L*Hr9RX4G@tbaL!%MzL6+q;gd)
zMM}%RPo;IYYs)gV-Addz|E6n$q<X8TBgyH7$w%ldLJFShVa7$MO-JBFDBG}y(KkNz
zC^~|zQ78xe-yY?(W`j=oP^U<ZE16Vdt|K}c67Srm(7<X(?x~w68;<r7BGJI>VF5ag
zE8o1CUA)LaERN~R5Y=5=%8-zmEyUsT)_DKVfp*>Ka?vQ==(kw=UNR;-JlX71eyEX1
zC#riv{v>7vEb-}S-7?y=y4<VhO9AMN-m=AV1Dh7M-q3(l6co$Vh-#XjLJ0PtlsjD`
zmQPsw3_f$`>VqQPM(p>d#<NA4+kmQ$-44aX2#<{5u|v|l-Rj|2FOZMJh}q7eXgOGV
zJsTCaZXX1m>4T+}I;HYRJ=VoJDHjfTW*z|_Wlonl{3iSqWNRj$h!8!r*w?{(z*0D4
zDALpvY)X)COpE*-K2!Zc8uUg$olKpB_g_pUEjSIp8IEs7>DyS;@?8iaof1%2iKJQ^
z^Mxi@u|X7m4>3)`>j;6gAdFX}ua<QB`k!J5??2!niw$wv`=KGU=ZJd5BisE#)2^^&
zBU|*&fRC@Lz`R>MRLgP`WqATkUC^gz);MJ<+x&J;ODO!+<C!S&&7IB${_sP9D4ek$
zNKxe(+|(>TU1qSnhTQ>)s)i5(*qd3^=ag(j>X;X=w@p<#$5j;?y8Z~Xx2kbBG<^kv
zQCzEms)+pS;Zps5NLAl;mFkO4_2vS`W<sFGO(>wwHPzR5SiR1PuYR1aJ_FT{LeN+|
z-s;0C6hK``)Q4ldt7W@t{q_OzR~<G8&>n9!KXej1Oj_zLRiXtTg*Bl2i;0c^YI!e;
zNt?r>&t}IT7M0T;I3b;I+5;&(EDB^EBKzt`>OdoNy&-_nJRX9qB$ZGJg#^qb;CjwG
zphHexLZ^yq02QUGB8~JI6mO=tiy}Z2iwp`mL<tl@B(fnD>OeP&B}6fu=inOw0L{q3
z_i>&cn^1W8irZrSamciNTs5DHVgP&+fO?2Lgitg`UtV(;Q&Fs#bet8N^8;!h6my-q
z2YWI~0IaTtEdYsi-h?@UiQQ#5n5(zyiEBnz)@n}Fhtc6|6OM@l*n2R)5dHsDbN=e8
zc$*N0t@NPRGr$uxW~*M$K-Z?>z1S6M7i{UpnX?J`-P+HWkJ7>s5UR@cly|{*W6>>m
zpVxdqHk{h=$64+5WH#4#zN*|V+gIH6J#wMHYy0#$?aTO?{IvG-o$s?pVQ_JsAq!Qh
zu?tGr8wk>B*_1}}Wz*qj7o2wcb2(6hD%=Kt`mcfCX}`Cl_G$jJMa|hOTC%aEpR-;4
zXbWFLd!B@?2JY~S)Og=nCRtHQ!BDu1e2HCjuTMI^HEZ&2P_bKIqPyj>Yn-HN3M5}V
zjylst4{J~S9{mq3o8^R$-uBssUbFGR;^wIke879wSrU{N?9qpX{MdV}X?|wnqt(^B
zX37p5yO|)FoF))B9szKo3-Ja*;pYjC+aD$X9FV>gTyZEx7Uf9~6^8NA?yBv0DOb}A
zq!{1r-B*BW(_rVMd1m(GBXw3bcZ$=@`|YQ322WXw0~ygC`jw1xal>;>#%L$Koi4CN
zL7q~-n1xHhU2Qi%L@i%+SjC|-Mb}ZIhplrFlMQm%ZC3zPdyVyH9*&hfzNQ&0KO3+I
zBW_-h8;qcHrnKj8X>f2HZRRSSCRl={!$WzWpwD@M1*YEsVTx5@+^PjOW@Hyl)P_Sk
zCh7^vlXpkU&(`nWm#P!!k+2tcgJ`Xy0-w4B_I_0h{qfhpxPSt|bsW}(8aajsgv2@*
zF<3dL@KIw7n?pgVgY9q0n6_uwYyrzMavcgr#=q9u&y}&CT_PDJIyo6w*XTDDguZiN
zIq26~Yr%T8@_SdkXQEzb_0q`f54q^YoXm*XA^ne;gYEGNmU2;W7fG#h-2jr1zXn!g
z+kE*bxm$ne@zdVt#S`$|_$4^kwmw}x4IAqCFg8ZqqP#RSaCG@tez%{=@A@<O8SUoF
z)t%(WAb5cwez=emY6jY#XA)Q<0E*)1wg+({eR7C&EA*$?^|J=Mkv1|s<M8RZCQgOq
z!vuEif5DHQZLElB8te$%U6Yza+J~p+T-+N8;jUOD!b`-HfBrl#-XvR?njU=vZE3H!
z?D}0;!7v&wdb3AQL}p=UR~P*oLLDJYpcgtc+f&ZzZZgnjx2|1;|B^^68ywNNp_X)*
z+{*Mm-Q~~~+NMY|gn*5_WJXh!8GTs8FUP1S{PHe?R>X15#o&Zs0TjG1fk-el<b6z^
zbO|_qd{$A)6$p3<*A~~`#bj*}>nv2eaPj=}Gf%tq&D|(oC+zUi)8Q%aJhU;wlP0X&
zho@)gI+cPYN-gh);cAHMeu84Ex%fb=3p~(4`QgQ~C?ZU@foUNUXt03#@SDwmFgNv~
zG}oLu=j<;qB-tz=+lR;&Lj~8O#_PFULMwgHVWe*xIU3JkX)lkQ#tUso9k`J?l&AO6
z1EP&e7!u|dQ(D1Su>jIkD+mDwIj-fIl@6v1gY&8t0*^#w48wESHt?R5C6FTIvA;t#
z`M91O$a2|a?7E`e=EGO+US5fLlcca`a={ZCvGf>scnioj^*6`EMNVh8)5%v2MZfg%
z=uT$m$`Sb`@{*kH#pJI$>fd}gPVN33O+5F@@^c6KHRc~CpJ1FpTZb0J)<nNNp9md&
z+?$hY+xf!D|B?1YT>hFy%7!DWf~v-PaTqM0s>U>Y-wAJ^KEqf|)>=Fu=QnV$xN*28
z*p&ZsT=`pd`K5Tsx7O6e4pEr$HF4$V=<*9$9?mcLsei8gd2!_@>+&Tm4=0~TiHo}3
zCYbui#g!ka%ZFG#mF4;BOZzNv^`~=H7so~v6EQ`IA8lrwu@El?^OfOsU_8QU&`Q9H
zO#A(x&dl&fQ=_Zk=-c`-#_56t{Q(U@>EPMkV(6=beoJdG6-$7%>d#+kJ%$UOa1jSd
z$rVM~TX>7}w4O4#H7qwm%}EVYK@C$%5iU`?gO8*YgBgcHJ>?gxWx#?gRFm~`fYo%x
z;-g8uNoO?xg9HqE%0{b2rn+Dmw&|=FXk$yGYpjC<I!sNH*YFORT$6P#5_PXH`g}92
z-lX!B^|+&_QBDz}wu~uK8yh8#p0#SKsWQYW@y+nj<YRy>3`v!Zt}0gzaaZ}7u99>Z
zL3359v0$^?87vOhf4x9Lhn+Vh)?p1CyWkYApp)L|CC^srv_9-Kv@$o+9U;@(zWvd*
zaMu-T4Rc+cb)f<9+Su1TOC><5i2PGah234Fq}y6G--yq2)nXIYUBv|!x~dh4ns4u^
zxUS;KYIfBv``gViT{W7HM4+_0>bQiiI@5HIACl55uF9))m83&gd9JHU$|zR7L%v0I
zsG2j*zqHq4{hu&jV(ejplzEwlRo?pvTt;)D2Y7r#3_HvT=AJ=cYu3DPK=Iawy0&+L
zHLt;wCc6=6YOpnHJPXD!>w6=8(L-9Z-uW6k4=pE_|HgUcxp^?<g3H=oI1GdJ;;#BU
zjmDG?Owr_R)i^diA@%GJacwIT|BO$|3;Mu5RVD5UbV+O0iX`08*Qqt@Y!HYxw{H@d
z@eopXB%sHkT=G%G(Ls+E6iSD;W}QLo=}c(N>bJETVtvPuQ{TngS>HFFSbevCwUrjd
z*C+FZQ|aLemG0MGBPlOMu9jZPnz4>DsjXT5ZLfa4nDXxX2t(=zysF_Ar6KJRA?7@*
zq#)Tm{}T6NM7>UGYu5ZtKgS5ye2HGfSZHG(#o0H9`~dajp1AdVopJ4cFw}NSTr7jt
z9DwT3Z?#f0!>%kVp+&7(2ZC}n0m^=>gOB)3U%>(wcTYwi*1RutPaIkCoxFb9G;cp1
zBJ_ApoG2coug8Sfeskw(_Nl#CK3ro3HCgjt+T1#(s>SPF&=snC8vg9^M}-$(;R){Q
z8JF^WUh4-dvBF6Xk4?+>J~p;%zIXZY-3k_Y7KPHL<u3|#&0kp9Z6)%N2Y}^c(~&m~
znfVJt=_|dDrB7Rwwz4*yj<Tatncry<%LP-B--+dHye^b12GCK-D4V}9m>jEr`Pi-+
z4yC)=wVDbgx_oRJq6<T52DOG>Y3essOLY0DRKcFQG89e^fk^N2^o422BE8^>?~<P1
zcrQr*W|a4W@yVOM@y_Xj;GFSEn^uMnedXeA$JBI99&_kA?-hA4)oQB_%ggY3QoL7u
z1mkMV+!l||<C)Qe0Z+E)l8o=HTl#rD$=-QWaY*O6Ef*xOx^4Ca)03MC0M2{ouR@;{
zgx8I!`k>#Ks)%pQpmk#gy)rIkg#&O001P_s0&XL+w_^PToay)-@58@ILHs+t__@t<
zy5M)55C2XI;@^~Fq+eMHM0j3Pr=K@A>gVmvd~Tkzs8T<#uG7yO8ujzGW;{c4SCHJ$
z+-Lb1Ggs+{ZbMZC=Js(lAvEBF=5gV-$E=82M}=>?F(_j6PG0LrZ1m!E55N$bv$%^1
zAq}r{nluwaTF^-|A*2;MX(n_*L3$;T6?EYPu{s^&1F=ROlgIR==I6G|@jTaZ3EqnU
z2io%MGw|y(^6NA5>$7d)*Jp-bpBa9AX885lj`M43yZoB<SzCTF&8Ioy@QZ1Q{9;-h
zzh-^r<`-izelh0em-m4dVOhMqQ50bp%z$LC>MN3cC2S6imt>BY>B*Y_Pzj0g&ZhyT
zCEE+h&U8yQ0cKq2?U#@90UT-G3y#mkzezs)J3TNBBM!ggGV$*uAO1}VAbo6*V1)!L
zCRiyl#smphNVsCcl|oL58*<7A<WxU|qKlV6MnTF4o3xCkQbrd#JSX{(DGqh;NXKe*
zj1Nkfj`4w5y^irgdDAgI5NpygJ`iixF?mc+qC&w7I<~$o2)|trel;}cl`$!6y_xyl
zH-*TnDwX-&3U3+ii(C-`!QM>drFQpr$9j3ixIrt&h1ZT*5$RlZfp=h1boV%Y;2oHk
z=^fZbP<b;8x;KaBM#u!DmwE?|DP~3?GlFAU*CDYGi9sd?nCL@F04YAEWO_5Zb}xT`
z7{^pK&++<K=z3GjddKvSw|f#PCV4<uz6p@tva~#JW_q5t`!2{G6JGhRT+bv-ggc|Z
zkOK+p3pr#d-oTK03NEcs7>n#sc#}EXBgUD!Lo#6RhiWc`g%!(`RrxCa);3$VQs2j$
zI;igj$=K2Q=+lH%AMgJxQWwg>7q}imi$bNe--=~ZG$^jepgP`U2a#QZV?((~^bZCw
zviMq`pHFTvE##BSqyl(<D-m(~H3VmxYJd+-B@^G8U@1VP;PrT};jC&l5_fb#nc$zX
z&B-ElH7#3Mza6yiB9krcQ&SN`1Gu@iC{*#wnmhB8&8=!TqW>2(7yjdR`g86^_5=DQ
zh=;J3En&Zuu#@Ucq*Tq64a;EcF8C0EWVunu5N=qMTZ#3%J>fLUMNw<kSy;l_*rW7@
z1mTirmD{iBei{8w$;Rh))Bh)|SAQk?wSa*IX78;1xcG<ZCxHj(C$6GU0IxKmYw%nX
zgdy#O(_CSk(sR-?U11&<)MdA}C=yK=qsLU2u*a9U)x?%?m_Q_?x6=^L#-fIlCKMI?
zzqEY(`czkq0~sCG=z@0+F@Z!s$_x*sm9;qogB`{W_X62~7(S?av@u(>9-K#^n$m1X
z%R`}cpu}wj<Cm@s!OOf>G$r~K+qKva1aY!i%bsqhx7@A)c(O2*!ojW>dE7M3!P5sH
z3;xT-B(KKtd1f4=p5uBOh=ZXscrYbcj2CMV^|h`GuM3^KZg=}V8{+eagQ@h)&Xz?v
zVrh)caeUvmZL23rx*PtCcJvK=06a;GGr$EoMb!AvAaVmIeP9p23t~HTxpjaKZV%2D
zU_j754*`Lv_6Fi&bZYX#Bn_gsT#Feg!AmraDme!?5jWE7#+|5Q)o+7lR>`8g)EHDs
z0@U+wI#43(8W#@6#o@X$2Gx~^Br7ovQBzM{)BIR&X5<MoM2V<L89d%<+!+H;F6k-)
zv~=|N9Bhg6;OHdI>qx>$RlayI?F|7C$tqbB6a@gS<pTzfk%~r22s;^l>bn@%p|V^n
z8jN&v3+-1r#%m@j05!N=HcCoRVPH`xGnyP-&adB*pfxc@L8vr46WagU>kgOXNJ5Z=
z7uy%7|GRv^S`yp;pD-S=#YUam$Iy+DhygAmQD-E_GUSXPhN#Ynyrx@<627<+x1m?q
zYGhEc_<v@~i|H5JRV_RVshfU^@BWbbo=z@EQ#w1DmQd`Fo1CNWco4Z*;i?bq#L)v!
zPHZz2aBWRLeANn4!%>StWIG(y=M)A=5vDAYR;(h>Y)HyMib!m+$|uQ4GCOMWv28BQ
zTcbGlqIC~)ebfuE2;DUV)KKkB4E+oPU2S8qE&X_B2l_uz>jeHEd*1>dS5f`HNt3dD
zq#K}t@LnLmLJKTyg)OwOfgra~WQzsDLkYH)C_W<Hg$SihO$rU$K-GdM2t|3xTg1LZ
zNTJYx2<0IU5q}j$CM^8qAy5#=|NA{NbMM{VyGdG$;{PWfn!R@(XU?2CbIzGFXXbL4
z*mnI&;**~pRdb&}c1fY+YctS3k;9^hzR;o?--#9@iBtF?*m*(^bhcGb4#o<G@j4di
zbuw@3M4IaZ6_E=+#z>P`EzS%WGN2S>93m2j^kDIex4HtMjsX$fLZKduTp}M=)F~9~
zvB;%A13WpoAiEx7@`d|q);y0}HN*sT1b}TUY42}>*a;FYrnQkGVC0%Fgc@S*gJlqS
zST@o*1lk1WV}F}hFb0gGc?G3sU@$~4$*HS~u+v$dtL%MUKKMXlZK}oZ8>~S*mKe_%
z(FbKPuO+xMOf+StCe+Q3euRj4Y7`qrEd7^)D1}<m84aO*0Er;&7aC3NueEYDmBh$_
z6|{lw@|Jfo?owo{nePdQ@qVVUp>se&_3@J*^`Ukh`5e8V)j;}_-vX=$9IG@d0AV+K
z7q5@w3e5;V$0g=sAcg<PZHam1P#`}Rvm}i}_ZtZ~39O^&Q=v8+OJ<9-b4fTbOrO02
z;VoO>vULTlVSQw$R7?!d-AZsa39u6@=9cHWbU#89_1b2RZ~$z!3X?EzTL7!;%Y@P0
zD5tLZjrFE9on!J{wwNwejjq(OEBKA^m-{ymlHO$qjjCfELt>EcPj=MTk<4!~Amm3R
ztzI{)`8|+OplBO_VQ#c;oR}QMOxQd{g7_Jh^!(RW5btc|)OSYNQ)Nq;f<9to7S%n6
z7Zt_Qm?@ZOCS{bQ$oVFjiW|IhR4kZs3x1RO87WaW<*C1X)R!CXKp8~U|E|}$EpF~P
z*zs{gb5Hz}ozZiht|hX}*Y&;!n+!DPY8h;>9zSzV!ut~Mecn;5(S`&U^eJfAfR3ww
zpk*yA<n|3LBhU}^!T(rn@tRaQy!IXsHezm4-SRqfsU2AuCzSF#-Q>1(9%edOCFzoJ
z9S~8gUm*hKdoEdXVhm?)?s*>R|K{(zSbI#&E({iwP-g`u1|}6(S`630JdHY?WmzP*
z7e#^E`g(ez3M?A9STP|h0HXpi4+mFcx1ApaqPpj0SxlUaM643ZkQ8<&e>GbivpSpn
z5GbHvII^q<tv;pjT3AS{0*lo^R-QMPg7k~b2PG_1Iq5BTK5*<f><DVF`Z7DA2cBZ@
z?dw+14*(5{5>@w-n>(jgq--LVK8tirr9Tw`<BRk$G^X-87oIX(sR2Da1mqd%LIBnE
zIkr5wl}zQ4$h_2{OqJ+P!sW6j<%7FL9^5eWSVbyY`Tgz4kPbm*lSz&Y2GC82F@cdS
zWM(kD&A<TJh)|d;UwHzX+h|(o1a^L%CaDhnEU_5(hGDZk4K$u#dn0f>e^=Gdc>a<r
zV*ki}QsXJ)OUfWLlwk%g(jzjYK5V(7GH>)YZKU(KvftKV34;g8nF${UjnJts7i=oO
zOnf|_Uw+NC-M^Y&3K`G09)lB5!em7Qa-lxwJ|GA=)ZaHx^XrS0YJe1j-HCZaAP4mi
z#PcuVm=NX{qdjD4VeAR;p_Y(g*Ing1E#UW$>Gdm>4-G3h5+z<bYOtrNfwVT}tMj6#
zif2#>iJ9C*&HMshwSJV75lQt!RLwm-sI?ern@5iX=^^;QZyi>*L#;#HG&-;!le4SU
z)%KmzCO6CtXm)Es?Koj|t`uXRI-N$H*FNZLXEgm71QWNdvGoiM^DnQ3=YKn!EJ&Cr
zRnS^Qpbk?@V+BclC>7=6oG7{>C1UD%3V%=>GSg|qCs*%PqX2gB^a9tZ%LE48gzZJE
z6UO(bjLvTk%D3@2DrFFf1Cby|n)59^Vk+t@9|T#K50bCMiDw!duG%rY?wu%Sk=Kj+
zpdoDnyd5?fUMn@#LaJyCYZG7eYDJHlqjvuvJ!;@f5DVFDESuH4X(?4<va!kHG^=<2
z$inVQEP+Mx5Y}2v;EmjUl9Ly4fN<9r<d{a`A?~!XafazHW-FM7sBD%I$6$H^N>V7f
z8I}=&<E8hT98B<L^%d!wp@${TO~lKvw4;Vfe=)w6ID)oIoL3+{$nlyu&&!+rXxNkj
z;*hikcy$B!r}XPowgoyg6HcSb^nS$4n1aaIMF$DclnqNlA{m$Z$w=hX@`rt7+|<1;
zKcCv?Vt*D4C35|YB)kpU9nn51{4wu8GV=hp`%z|YlQS+@UrBl*2AUs*TfgEz6YpF~
z%W1TlRIlF8K@j$i5+P`9jS$?;Wff>75xgKRbZww&wXKTb8HP^Oc8(6(NzxQ4u^$kO
z<dOX%331vu7Z;1=A&(_?=k)$MU<bzh7V8_wl7-R<v~f2&y0AJcO_+^`x12MnB%uww
zV*Y_rbmO5fF()2U#xp{#^msQ%mLefJ8jLS1AF^95+0Aia9MTERlGmdo{25V9fI=5d
z9f%v9U2j>{)b;x<qc{iA!<i-g9LtLB;i!lIjMh;(HJh%ZTf}vg*+LF*=0x@7qXLw~
z9hGh9>4)hG#;m{BVtQdbMPO1;e37=Y7Fs~Dy|p@&87{c>UI!WoD`ivClSb9|5_*EN
zawa*hR{TmN#8^6j=!wIxbqEC!P<&jo52MVCt2wBPp4JWNkq=$F4)#XX`Ug#}CXh?E
zY2xZQ6cz_^EO%QT`M4m4BfdnScYj3j<$3lZpkcx$t04q{8y<Zw!fNa=2G4)5zR%ut
zPtWGrZ)l+SgnOWVfq#@_B_C44QzEywR)o?!s49^F=GL7VQ!32PXIxu*aj5|!#Y5?@
z7Sw!dHK##Q&4jL*V9mUp#{{l6EUU)M*wq6R4rR8tZ&_T@5el{8ur5zaj^gnhgQ}a8
zMi9AYHAHg|@J40NfVu)M3jx6yB94rx%|q=rBzxDSYSo&B7lhc%#=-o@Kfnb(>94@s
z_7I-PlZ|9m1Zv#NB{bfXX8sR11}A6t+IvU<5n*Ec0t2J9WeaSb$qTDL8$&J%Cr$6(
zlqhb;+SiAH!>LRllDMt`pH=cV@+GekZIFPCViH;q+}64NwtmgoXpmxmac@VYqm%8F
zZ0{{h4qF8>Z8Yx<u!Xa!7&$qrwiJ`xAb>*n<a0P<qVRDcN*W?D7`x|<*(Q|O#fKg5
zl>j$>c%SAeu?1&LsWsf_Xr6L_IY`7KQyJmLHhC{3+5QDxF!HDXBWqDQF?9s7!XP(O
zAvIB&HS2!v4Pxfbcl$4c(_lDYlI^2Gy*?QAltw*eQBQ?LGh|nJWah|JfD49mih?_Q
z7i;B)sxwe>G4P^b`n3A6ed6yEe;mAg3zMVv{k7&OiaZ2+VC^o8f&lq;76(*IMydI>
z%sf}V*_s2(HyoF=fJTORi@$!u&WK;YRr>{;n^h>`e6_LMFCpMiyA9pzPr|*9T?8%R
z{=)qPpM?9vqopO>%gaf;K}fhVYFUZ~O1ORe5-wRWpop92wK6CXx8wz1W1Ar2BGR5G
zy#htte$pea(4a-!yTA8g7a-!c6X|5us+%g}rY>V6KI|}{5L~52TobVh5^<jeF$XK+
zz9>Sg2=x*o?xtUQIQB2%=Az_(MVyhGCFGkJBrTpL1ZiLv-m#o4(ORIbVSzCEK^s8g
z0cxd6YjIUtlX~$T{e?FgzGdl={3%b*>P2iLi~@-w=mr$AUBFOKj(a|*IVUOEqU>tb
z^c5UiT(k#~YL&EKq`H2mI7`LU<F|p!z8u`ZgV-`8YdZc0-j+F<-+*88*2^({HiK$r
zSszmyZbvgi)qcMKKS5o7A}4D5A0JPU`v*uO2N~=#@c8V61C}6$L@Ewyd@eL`MtS3N
zx5$Tl^7S`9``=o6eD*L6<c-hg0~#23d>Y9HL)9fe|5uNXy}sP|x<n9mX=OuqRkv{e
z68RiEwJhCOYHwgEB9mWzScjBQdN;ZX`N&E=_%#zt?-;9@Vli~c);#=YXa!Tqyz(xz
znS7IKGr$T+Xi=BkttV28u}fOHJGcRmam#Fq#aFNu6b1E7UA)j4*@WK&erMtrv&?h?
zFEKsM@C2U}!~t==Q*d2Uw^V*j2g~7-!}bns?ck;8X0hc0=gX#y$2FMT8#f-e-9h3G
zZafgK&GGp7u7BTn9M2WRzhyjRf4y0jW0ik+(%p}3L<+pVP4t=LdyNbNglkudA*M=x
zVUgljor+i+&~GNx$;`evJ2_dfn#pH5bvdkX_^f7Lz;*MbkOCZ*Hss7t%$WW4^^pbF
zN@<-29a9lmaH%h4eruFF;ykf$s<lRUWda1No3I-aA`6JKO~h(C9*QhD5=rW*htOzy
zE3P!C?7em<67FY0HVKPWLr_2030PdiUPl%79Q(>T7pgF!#*2UQ9zi^m{*ukpeaOgk
zWuJ&YJ`m$!Cb-M0K)P&j$2Hq|xbrJ4rZM6z%fy+G%c@qRj&=21HBuufXNp?Y#}A?p
zYm*7gU=c;F6kcpYEjt<~_9W!4JO|OiD{+TRwMpadlKpZic-(IR0-}(YP^m1M!z~$S
zJOUQ5Y17bY4BB}=A-P~+qMU3F*daza$|&`u#0QxknNj^Y&Slt6=~2DLm$DI~+RSRU
zrN@86i*zFwUW0W8FuD^MX|ZRRQ%gRWsmNfs*i5I(h;~4DgSg(!;MFc;Et|x=sG(dH
zTcc!DpLv93m(+y-%}s2D{UhX!bZpDj4)SCE{020@mJtKR^m$dlb1WV>2M{{<6H7_D
z2hFaFOIRN)sv0$3M#uywky(+*2C1ZEyz#4I+|oqidVk^tH(}_cC!)}vzQI=p-IK(Z
zAaqPm9O=OleT%Zqzx-Zs;Fl?S4Qs*w6o=I}(&=gl%S}No>azja*hs-RG|R{Qn#J4N
zOuf`%?-y!;sAvvFE_saDR|)`L9X10ycUYhsC!d)Q;5TSE8wt2b5L6p}Cf6yK=dPy8
zya~8NWi~R-yUEp^>=3XZwGEdfIqWi2NKY_hAt{Czc%eIV*YN@!8o*2xf0PV@i~O3|
zw(va$Z0CmeMj#}6vxvy;g(-lWuSv9}D5-vc=`)!k>ui8FX>B(f(q|A}Y0}=h7L<lB
zh;s5w44=gVhCe{>A|N8)Imt9GpzqUFGU$x~vX=!M>Dbqx%aY6|m#M7*SdaOFDnF#Z
zfuve!?4^Ecyt{2I(CI|g_e_Eipc4y&=BqVR2oeVq2`(E9MGpL|5jK$pHw#OG&;m*O
zLZ*VfdXQdHq1<{S;875xkZ*iN#<CAGtZv9J^izWR3BPgvTB@;B%#B*0@kV(5VU+G6
zoye&-F&A=aSI(S?IklksoEf%#3`?bYl9LF0u)-jbz_Z~ko)Domwvo(}9ge0aV5bP`
z371K8<i9SBEUIf{BM97@KvQ)7nr6KI>jJkni}m+kAe);4LH4xRZ#`s|Y~_v*yY?IT
zvdDguJKP{lH%M`Oy#v4MaO?tsbN%+4F1JX^sU!rnYrj4IQ#}RNqh_J~#<YC<O-lLg
zH<RGmZzdt%eq*BFe%qRUTw}joR0)*J#j&gHHx^cJ%IYgA_S+jsaP2n%Mf+_wtW+-M
zm|*NTKKku9zI*nY<Qm+?elrPzyV!3gfw*h?jR}Ici16zm_EjSh<J^Y*HdP~O?6*Vt
zR%pKwf_gV;jWySPJK}JgWb8L7c<BQG0cpA(T~fcHk=9jnZMU}HB<;KCG(^g(E06_Q
z#bLMhn+!4PhS}n^U;!489vS=X2gXOuG(D;dd?|VMn^f~#<t9Oo>gQO^wsZ+(yU%{B
zh5==zroCV=N?A=*UHgqV5<)loxtO>@T~nId!~pw^*{Y5!I#@>QOj$|%;q_Jny7t=!
zfBtWvAt}vazcF3xw-52)x8L*xa_u*luxQJ|Y9e79NqHd47g=mbL*81v4e#nt<OI~b
zlbKYaOe|Yt?YE_TolG5T%YYP;IO|7lPaGl95(!!+RV05XCab#sI@APIj!A(1c40vF
zM%iyi3V=ZSjZGHXZ*iolFc8CDud(04V1gq1trm&aeluJm_M4CwEK_X15wceL;N&7^
zqT;7yp#4U%XGx+O|JINFMlkAZ_#=Jxo1|U#LqmFPze(DCT*Djt?M7oDNk+3RoIZlh
zGmXuYYt+R*uz>bbW5ly+hKhFA_9j6Pr``3&5^JT%yiJ1k)=D82#Y!0~O?T8;3erk3
z6wI?y1PxHqoo^*cv<KJBm(VNgS}ALPthwq=k`h+RC73j@QhM<EUn^yEtNni&ypr~X
z%(`slJyb5^*HDrvNF}O_YK-{&1VnrroGTx3x_p^?KaBo~bo_{->jb`o&suRi?-W@o
z&^JA?zB-L>o?8IN9(Tn0^f$cs<B!1m7m=L+d^_Dm$l)c9^rTJ~dpnM2wji7w!wWe%
z%0$ezTKP3jjy=J|oFu)UmpQ1HgH|O97|6~xV%<j*!@iu1eLKuEn&*!}=DO+ik{-FR
z63_<1iT8E0GnC?Nfj}tn)$Uwe`4pN~0~@?!OnMnFy6d`?EW4zx+W?TnSD;hPGJcL}
zV4Xkz7g%4I#-Y=gHLn`)PvZga#0hSRt4Mp&&gYiUq+~Ftr$U#ambywbmeDe&T?3pz
z{U!%mvq?gWYSmpLA9%doiz{l@;SkM$Adwu+A<9Fq&fI`HExJw%>#P8F`czLA>c&JA
z=@a=)++<A3$gaZ*9OhpmZNQZH@GRS~hlXuLl?ai9x43p>3xbWSLk7=Q9j{>3f07)=
zg;7mF5Q*p0RGz<vQ|JGRNGvHo8ilbc=iKAU4-Nzeqy@jO{NTsq)E->$`s7Cq-!V*-
zAHxib_~eHM;K>jD?#hoV0AI!!ZQaB+@k05rRHuvlSZvZoek{Zb<wqM6AwOE>cai>D
z+C7+m!e!Hq{LrPj`HGW}EQwj&jS*L$qq?*&S6t=Fk4rB1rMF3X<ieqVHV{sfAM8xg
z^p_9{$d5KO%N7^&*MAIB%MWI&t?639Y+lMTDBFf#wa_yoFE9<<>CayUqMODcFPJ6r
z<8D0Qoj6(fL2CHqhf5r^Xd%AA7VEn-5#%Lt30^QNO-2?V0H;=+4U@^qYWZQKZ~BoR
zQs>ZsIs?lOc;3-A0(7hZdAvw~+{A7HL-MQPo1_DZOP_?ff(6Ln`Rb{^K!BWR1c*!x
z2#|v*Sm&>4MC<=Y1W0jwaWhA!#VD08z*Z(xz*X!9tH!i~h=Hv{sl<#@v32$isN>%a
zUjgd6N+oWU%5X{UJyZA@2)J>i=~^PxN_E2kQd90QTh1VQHz#=kqW&FnRc)|h426W<
zVsV*Be@$&L6?Hni?6NiK_=(UM06VFPkQ5>Sza%{EQWHK?6JeiHL$&N;fbFI1v+YMY
z`XMK)&`TY!btW0T4P}^sxKUp=-++#n&EQ3^HsAL4XXgXw8zUW~B)WG&3owZyWTW{L
z+=(8X30<21M8Ld=)t4PsE0p@-KdJMxfI5TbKYj~Y#-8zm91zeikO7ad1?7`(wQ77o
zt9cA~sVPv%fam6=7c!vq=-KZVQ(;gHxL}zmPcq>5(U&|16e)}-851$+M)+C|^yQNU
zkM{Ezna-Eb*M0o?<T_ver=1CXtQurb;dY3dgnGu%aIjyX-h^InZ%tyudy(X6-K3qH
z={Y0@b=CaD-dv{%arh3mUL>=lJ%J1xMz2Vm`E$zjp1W*h>zaF_CT}UxF)-?Zi{KNX
zfA4IZJ27e3BjiGFAsMmwQ{yls1R2^{3{%zL{5C5J)a^m8`W9>qX10Qn;iY{JY3R&X
zg{?L60wBsV7bDN>5)sRs$9Dq4S}sakjL$A&2f!l&HJ!q?W6DG*tTXx2_}^iMK>(*D
zLgDpAyl4am=x7A$Vjj2^sHT>~fvEMv{l*G(J1F@5Kw$ex9$C=tOA}+qQhkV6IXD&;
z1%}gs;q)L3kJlJZ7YvU9hPHYcQJr3lDlMn%)Uv1=?jl<QWQz-$9sK99{ipl%zlP?9
zn&1j=@wbrOf0-M$T{;|D9fqg@c=B*>ykUZy7g%SRY;2N%YCELCF_ytbt|`^QQsN%|
z&bOsKll~PLhGr>yhHvccPQ!aXDuQ`&ar(=?6!@eC<b`_F^Z>vdjf+s+MO}F*1()G*
zy_0RFc%Eqqb=1r;!hZFfx)!)G+N2RCAXTEYl%&v)(W#ASWQa#{Ju~paB?g%ok1_J5
zpoAA$VrbG9hn|s*Shx+peKm(&6Jd3J9j7rTr$p8xoxthQGr;5Apd>bMpl)14>TfUf
z=^=-Wc@rS~+qJJx@O?@jOUPr6CwAYizRg|T>X9@%GdC=Sggy@2Gx-vlEa8{X`rVVz
zd=HS&OfHbnx~3<g-#`&{4_fs}Xi4jCFCn1`p;$t*4krxxOHKS<o`l|jG@pca0pv+&
zrp`}z5}JUlgyu7Wvk^56N(_wcm(Y2Q-}7Ccggyqk$Cc2!7<~E$9Os34@jF(USqV){
zJPl$cG*h)w^dvOXILVr<h%G6hb<>7C+iMK9g#OuuK@wV*x2U=jI_@HCC3Jp4bGcIz
zc7MKvHq;aeEmf>gmN*6bvLm#GmC!7uehO`<w=+aSOIii}0#-sx$^|TyFQFy<s<t8t
zy-uj8WBIIvW?H_4mQsZhnu$IM{eGvG&^lRSjW$(6hedq^NazqVFus(~WMVvu;CzFq
z;6)^~CT&OEdckjrNL#DCJPG~d9~Mez3!D<#02c{OY^;PHbVI6Yy_L{bYr!i}M=dsg
zO%E{puf*O+JyGI(JjNgVfHgDLRz0d3f>S5Jv`QlWDJgGw!L!5XM0@MVQ2GRU%%&vR
zAEu3yRL>X>RNUbgW(`n0^r&a&5-5%<cfuvj#`r9!f^m<myr?tahRflLxyW6M!R5pd
ztcq?O8GNS$`wOVmI4>ft;`~MrugU;6VT&{H#SPZkDI+_j3#D%x;CW=$!-XTd2M>sM
zwjZR6*Vm|N=_y}VO9(xAhr-1Yv_L8q(lUF&fV7;CG29HaEW{VMYU;=#T=P;3wkScV
z!uq)BhW&+i8!Ku3m`w@9l==}}LX<yF7mwNAFh_SXsTl@5C@1Wku<lmUV-YxeO5G<>
z$SHaEF@W^$-7uqFp6{xPtQi48C_TcQ=$HH4@vj%ngz%GBA3$aDwt5csg680^s(Y9^
z2#_9rCxNS?w)&BI)p<r~!}xA}z4*<#j2yb=t*Y&-k-JV+cG$+-*F^1itO}{|sQ$i~
zzfqYRT~$xt@8Vkxu~5{YnLB3Ot4lV}fbj%-Oy`C0atlBq|A11T<o)o4{I{|E>yED;
z(uL$nKS%iTIqSQsu3YUBj`9?Q>ro3XE~w>=gGU-fu>m>AUvfDwOE9#>i|`Y2aQW@~
z{60t&qVetPr1(H?aSuM&2_QJT&_WCi;J*9JKXKpvCjd{&15Gt59>dD-%oF=<c(L1b
z;Crp}`VaW-Z7Vmn8Y@m;It}Z@=Z-B6w<Nq9u&*!c_DzN7jz31*em@}Q4s^7{KzsQ3
z>tjxlgLsucZ!*&GCWKdx-gJ1veZ%0a$IJ&vgsF4px~&MtgKEL!eLm&kZ<IqyTF_Q0
zRz&u`95Qc8GsilaC2BYfd!0&_wi8Awpv(C9NK3Wv6AX>i5+%s!B2_S-vtjipmNjey
zcl!?FdkmhGbBpsnJOT(bBQ~wPAym>&8t!<Y9YdNejXE1hHG1?H6iL@=kv<&cfUnN`
z$_L1k*_&COY(99>CrG?=HWI^9{k8DU-bi?!CUkAainK&qCiF&AWK}IDDaRqMF0`zd
zr*d3g<wF3xzhp|mJ8)olf&QIR_vsyn&k~nLP4L_(c-K6zdExzS`R0W;@16nS>G`Y=
zctT%Mfb;y|SpM=TMw5L=@If6S4p~NRL$;}X^;?v0j&;7srK(F&7!$NivZ6Li?%U1F
zYPDGvT&w40#cfu3QC73f!pf|mR-@*`mmz7@B@9ylV*&|8X119(tWFS?dA7W9=K;6m
zbeXV<M;D?3`jWKpw{YRNV}m7>-iD;1>Q&=({T3GIx08`bWi8D&tCP>yfSPiLlBiN6
zgc@s;NmLHONj(-J6Fk?)g~NH5X*?6^v2CH%v7lt?{diu?$E14qJa{7KU~n=`lzLGU
z0{?k=fzPHQ<LGn~{Emy3SjxnA>pM7&t36}y+XM~X%F<3rkF<Eag`GroG6Ox(sv|@@
z#=NCSG(yGhqrMjpJ;e>975LsZcnld$@Nis#zJ1C)9G2hdjN#C5IPe?iFZo^AoDYpm
zsb5izzvG{Du)u3olj!T}GAHrA1<I(gqR{npXi+=sH{p4gMP)jyBlM!_AUvO!<xV2u
zd0$qC9DK8EDQxe{#ay&mmG-7%v}ZT$8p?^%NO!Icvt<CMR2eX#-rzC&Tw`qm@U7-$
zOb}*KY0yUP1cu_Po^TQKMox;UGI{eR9C<~Z%55ghAlGv%6Ha>OO}MyBpVeHGWRo)C
z8odbz<H_u6eUl4F&PH;hoY;UZf$t-fU$8q<__C%|pVPgkg|L{GZCHa1A*p085lpDZ
zzXngl(PR#3*g?Z)-l|D>M*qg*BY6OgQ@`#UUM8xFcj^s?(Q4=L$6K2@+@!{x`-#lq
z{UEaZb9g`Cp)M1rEbkVf;Je7Yfpi#$Z{rPJn1C**uj6@bvei!E#Q%p*N<H7jb`dX^
zb{Ia2an$~gv$`=+tYZ%X9KPR*@WR7u$sTdB>&-XKT%T5CS+drCCJMK{Yp5_}d(`z`
zC0hYlXT3;Zz)IG--@;1g7oGwxGlio9g@t`z^U5!Mv<Dh7ZN4_kJuo7lrOj?-Klc^s
zxL%7Mc8u^V>V{y|*S?`Fql?=m|EjZq&J|WLfF`_fyR%_<JohCZcD8nTW@;W5b4u0D
zD|KRCDF`3iM(>(ZNJ6^!I@|CSL$mA@ctP>Gpza`q5m|sb`Q0tg%*=!ILGvIW<<;mZ
zS;N<n0gTH$OZeaOQs`d_TA8IhPo*_Arjr&?F*T;hqdiU5pQ*8nlq8coSboHuiB2pd
z-f}cR(W(K-;kC@^UIV(V!8Cxd82X2J|3YSGbqy2%1hs{18j)$9E8n=U{*@jZSsxTS
z2|+~OZ3L6Zb=NF`P=#L6pD@gfROLVpgh)Z`YMe_rfCK&ixDQlq{S9y|RV4#L77O*v
z5ql`WHoU7hV1BSkbvgEoF|Rp)DZ}t58?s+!EQ8*P_C-3*1(^VdS{QLO(a0sUkRW+;
zar3fn0lTlvlL(ehOg(k!*EwtQ@7S9Gb)T*1K~r_=n<etw=k(zA(u37;%tuK_9a*9z
zzOjXiZ-ry@HU~=kqu{8~6NvBNN56R35W>)W&&E<=^tXtkj>uqJjp}(3k;PbBtX47~
zB~$8-5+z-%Qr_3Y{PA=3D~5o2uKk}>Cx4SjV82-X5^7&Q8C!=IqP=s$7V6#k3@nI;
z=I*R=c(g+$0y&1E>S5Jbryi>GR=#1HTd6{jL+m+}MnTWFr&ZJbDZh0xh`;4L^ahM5
zA~HrUaw9SnnR-X+40FK*IX^0dE;u7J4rV0C8&}-ww&cWY#OPbjZ{(&7PS~NkJv=0!
zx=b|Nhci&Ki=Sq)DMvKvlx8>O0565BvOQ0;p&2}7)I5vD8+05}bZQq$F#ex5r06*d
z_FQ;77CT+$LJ*t!%;~5NUl^;Y-=6Aj*#Cgt1zJFYIUisj%>-N7xc?QTn`Hj@Y+|72
zw4~%6DbQuM0*`<!ak4wHO_K4WIyA#n1zQnmmTy+oK!ucrH9P?gG0^WG{-#HuZ{2u6
z<^;^i37C_A#VcXAcgyO9r0%Te0dCePOOG;7<&gy!BEi08b^;`=|MiJ4aokpfiC9x^
z+rmtJSzZ&zvYJ?8uK@*HL1LH+`XfQ=1lYv(=x+T=PEAT@)R8ao8EN@@^enemUcH@A
z&ranf27Hg|A_oHWLLjaFI-AqEcM_-Z{@5Tk)3}a%#YW=l^@p9t3G$tH!e~1RhX0>V
z7zNrBZUFm@i2K3t$aKI3hh#cX9M%At`CLr7!nDIM52$nI?r&rqS7qSDn3{xPAfF=G
zBOlB=VCh_KVd}eI)Gebh41^NOwzQgebNcUJ4Ul60C~9DaIHC0Jsuo*r?X9gJ%he#q
ze~HY4%q-TQs+?tWyQ_EL9%2!knt2tE*<>p-)F1I|mSclP+vo2^oocA;d<Tp#-<W!O
zD_hpYaDIjLSnOsN;!zSCU#<B9XgVmHDGxq&EO<?j+@;WXhJ1q}O7BV?rjEW*zfL|P
z2y#GBW@&lUMY=fo)z807LP>;G!G%R}by;DaKJ6Zp+lpfPZg@iE{-xY;6bBly(A=-6
zQ%y}=fuwIL(rbRo0^Csqq9@d^X6lBU?YRyZG<Cj@EIQ;Y%xUv^Oh;ufg|Xt^0*4i&
zW%#0JD;!|GyW)@Cgxjq5Slacgdo7OtOUUeWO2`<EbWy0P*Qv%p#+0u&_%P|iqub|%
zVS*i^9%TV^Jg)99RTS0^u8IPXxM%I;otfyWx$t|?(kKyAKZ7|U8Yx|IXIXBG-qS&d
zaow14PCg&H6Ka5mJbr>j#7{mQ3sEijbk<kPIO7_w_Vp6vho$yto3vU%@5t&~muhbv
zU6$6-Ie0A3;5s@&TL-mm%GK(W*H3X%cFf^6JnFF4(L;Do04rSMuh8CabVYIJisgsM
z!6X?9Tm^L1PwBWS1$Pkj?``j=ejYtVH9`7{&V<l%Me(=9Ud7}9Wr<YOeBv69@ZOd6
zBS0;G3TX7og62f?@9$j!J_!Pohabk<rOF?<-YKR^F+EJDC_y=NQF6Bcg06v@>6?zX
z(h4BR9z~=;AW*8LMxr<<$eI@{eSnb`P|#mJ^4yS3*2+URh1rJ8EWQEw`Wd+1ySUdL
zU**#)|NClnTucDc;J>eyUw<k>3^uO5;H~Xx`f@<;gvuV@AC!FjrGEbR-A<<oU%C?m
z*1re~u72z5_%|8gByT8!5?&5tL6`+nGit7OE&PC5G?<BGe8+dY!p=9|oZE|`NTrjs
z2lZZeT&+LJBw~it_B+}(UJvvLV``Z%QHNzSx2vJ-HMd!pL3I1Nyxc)oP(<=qFiKcw
z_{%fJd&gYH703nE@jY@#2l0RScXFHA#}@4_?Gg1-m>~4lB{)B+JbB!I*OKM|jyBRf
zxZo5(Zsij%Y~swO@)F&PB|sZ=UO`@hP|HLYLrag~!>)KJ&uz(d6s92#qpJCEr{*rD
zW(U(w2j;MPlIn@$I4<jGuZyu?0e66_{iRGw-R6~{6GpA)>Y#n|9fb7ckxO4JkMRNa
zwV)VuD-iTP$15286|!3g^1x+mT>|XnZ*4|;7&;p5eGd5Q-lBt2^-|6iEiP?EvpUMi
zEMkz#Aw3ry%atMswZX}z>sm~N3Wo(%VKB<fHxTLg(B{B4q-k7z4GSi=E_Pou_e5@*
zUUm}L-GYUMr?<E)NT?En%Fuj}Nwu8?*~7xQCkP%x&^S=2j5|j*=0VQ~8#<Cr*6FB+
zK}S(|^9djF?N*g_W%)BI06tGcZYuntrQn0{Id8}T_+6W<05jO<u<v=K@44E2rl4~7
zLb1~^j*hba)RaqN+rJn#Q8D%6>d#aUUR9UNt<uH7V=h9%Rb#sfl8zJeeKbe@Cq91r
z7hU1EwW71-rgltVl*_FL^b#LybLE>IPrVir!4ehe)mc%8y}Pc;A73#7mP`c}D)`r4
z^p$3}ds-eA8znIEU^-EFpewFT^Y}Fb#$#+${K<Wn4FX<%JgbDp<YTovq6>T@;`NPB
z?)b^*_0=?-9Au!(nibilgQF8VDSJPHKBr`R-oANC_5mAa>*Y_)J|9{3<dl_V=D(?t
zJ06+RzM(pD;ajLZYf9uBt7k=;x~I(F(1!POt9#F4vRD7z%E=dx3YBMm5ZSV9DuVjj
zS0mi_Pj5^ev-;R<&y>}@TcjsXJ*4XPb4P_D7d4@3Wbd-b-dHxwU)?5e^-J-3=ajyO
z@zafe>+o;=Ec|&R^YoPV_4728iuBfzU05N6X4nQQWd4r)NP6huku4j_-azLbi0qOK
zMaGmx#(40@0R9*ae+=M{0sJxb>+$c6%<m$%Z(s|#tI!>nUQ@D9Ozo=r>wzEj9g*#r
zzb?5|XzGxjDfmD8Kz-kzW-WF)r@h%Z?fqGu(>_`_t?vQ8|GjhChY#TQJtpAy?apcc
z;A3Q$22APBX>WB-`vB!XMqV}l&FV~r7p8{We0gWOgY<l1lt1*J;G5TfOnazw2nHH<
z2^todFj#o4R>xt-p>LhK;V5t?O=g)zTh*_?nOKD1a3|1{B7=d~hZP9mok)0I&HVNY
zT6t72T4IJu9Pj+{ocKwqZ0ATG$ylv^#2S=YXz8`jdYBuu&(8<A87N$657Poa=!Cp3
z=C$H058)*86^wx2e&ao5|D4kMv)s4ws8=W-)YHe5$ggD!kg-Op^4ab(_A6nv{L!ce
z#THrlWZ<{s+Rj1iP7=n}PY^$_UNy~@sG3Q$PErh(rF4pqo-oo_rP%=znJRh2CUh9u
z{9tI5?|+XPr2!UISLHQb`k9}EuV1kh7#im=UP6JD!rX6yMY%&i<WcNe0%DT^Bfg9#
z0WVQp&E&Ku`pfkIHb0aMhkCCjIM#9y3>@K71ABjH7(FC&OqCVMI&GaDMNSbr?E|!_
ztw>xI&XInTE<iaj1wev%QfJ)gpbp>_Xg5c_kg~wO-H0c&)=b|4Ndm;mbnPFpc^GS-
zl;E-B8DqN)0wDcmFkrxj)sALy8Yiiwh-E`RQ~PF&Z+y*Hf3fV~t|>_X9tP9!djWKO
zVk!Aef{fa$X3pR)1r2ROK*0&l2o=_hfU-yuNWy;jlY|_Uc_QPbzYOmXsKfLWi7HT1
zeKk)uK@)4^8ywqLvuc|DG8nv|g3B&0E+9b$XTBJ)l##E3Cqu~}%D^NE6<ll3#0v(S
z?c=GLPl8Shce4<4MVoOIc2hztd2+O`Cdn2z=f{D4bhnQs?4g7;2T2h}Jp|Mi^D(7z
zcm(!QzBQ`XD`ihA3YH7D34P<s`3tZK35Nn<o5-<AwLQ0)01*?{q&aGqVSqTzJaOoO
zT3iRAMpQXirY#;Mll%CUv+fqoS3fKI@WXI~*{f=A#uw}FKzeyKjie_S?+_f{FyuVd
zXqt%OtybO!nx`9!pYAW)c?fHe;wA>l4=}YgpP~;4`U8Q;w0Hq)>*Yg2{cyS#NAZO)
z)Fj_eVasXy*XxfgyJIY$v@(Lv4<)MwZ9K&E0~SYP8UFR)p=^f5+q<zD*`uzd-x|{n
z+d^PRW^}cJs_8n%ta&97aLRJ~tFsTY0@#Erc2y-?;ANL8Zx&WC?W~Dy?4sA@x4xP!
zkHz!_rQ8FqK~(YR!6ps=4bEP`Kxo&XjEJUuWSLW~W*$+%<h~)W_(2weU~R3j^2}DN
zs1<dOA;MS5XlgPG-EY87llD2l!|zM~;7GeU$7%d6NPhA;A|h=m8KfznFRCr+UqCaM
z^;iM2_IO>puG8UiFj$oMdf`3V{s<$9i}xqTfb2n}mP+~Msj}W{C`~QTeraZ>TBuEc
zZ_CsykMM{s<EX^ZnlIg4EUv+ZbbDowhw%r)nhVvIV{wFr(+eKz@YHOXNP0rWP=wWk
zCj$sFlcpW|u0vdWCo{sYE^yQIN_-{(w>nIwCDWIwg<RF2dVqj*B!&fm<2lCDOI!g3
zr=!%F;w+i~@-z=5csvs4Jr&dMXy7m~z0n=?JR9n)sLS?ekoxAs{MRJ*0)Y(O=xa!>
zNt;0RDA%M(w*Yejh?am5fK5m<aC&xx)h3l!wCiVW25yO(Fays*0c{4pD#X)fpauYg
z!i1}=oT!JRdDS+ohB0qe+ema|hrUP&t$Lr*s9#CoQ@bihvGuN+bLFS1=i(6|^*DlB
z^e4Z!$240>{MEMz2@o7|iNmo;srM2{lc$F<7i7Lg7CbCCGkZT$88UANgu$RDcVOdv
z>GAyeI6anwy?Vn?=L#G+J$UgbiHK=`=`d%;lg?RBI?j;Ms~z|aP_Hou^Rx2Ivmp5R
z#zARpYn>R%G?oU~ducxan*`uC24E8b(wv@bBY1~{11F&udeA1Z`zSIAjVIA!QV-f*
z3%x=6^L+oHA=aA&UDjy_?K6`++g$_rqC036Bq1QTxP#WB&H&5P{^}th<oO4Uz%ghi
z1322aUw*2tya<D~J;Eep&~ljf=2o#fF1-Mul@3-3YDd_G&ST(|Gyn?*!)biAPvA2+
zHcW<efr+VouyiB05g&jSNBFbvqU8KFWcN*+mU(mZ)AZt-&o)RL?176SGx%VH>$p1t
zaRj)q5k!iMo3Nz#cGr_JU6@NjY*5p*yNuCefLp01CpqQ<s~=6EsZ@v`mvFb!NF+=*
zCLKnJ*z*Hn=jjWX)loH`Ti@V{DB-2lR#OOB7Kc&wn2|Bkl@trWEDRHI{1SUegQ!{s
zEo=HZm_2`y&qe!XfQbc4_t;|YDwO9SST_jTqu#(o3lQtR@+A7P?4N(MY(A74_4+tW
znms~rbYqoBQNWnML7l6%Jgngf{@I|(;rX{&1~#vZQy7g`cZQKvUC?C@o(5O?9c)?<
z>qDHp^1=BoK5YBFb)-T#+j$eN{o5S@_43*|pRWaYx&4LfynXT+o%}xaU>q$P9|SP#
zLsW5fk>NP7s@dTA*#;ddO@4~2Ut@9rw<t!fH2?>h4{|eunXWMU#V+Na%5F+6yjPPW
z!%io>`PdquKIi4C_(gKHGqIvB4IYA~M}rf?nW22nRpfprLE_fiXM3Fgo7et)Xg4l}
z(-q^pb2w%Pc|nls&xKs)!SL$qGneWoaJ&#@bePNb4DZ@JADWn`VpdjzN=wlzHH3SA
zC@0H%EaX{EUx{yp5;C##FO~)~4<r!2R%W&(usA+lBRf435#K8x!ee$>X1Lb>m0qhj
zOATGnhIS1a`p}zRQUMe$%?(Euv|+NCd`?U86+lkVPf;mu4`3uJJVnHlq!0~A84Et(
ztx-%!eb*<JSsKCIvjP>dD5&P}83F8gjDg;<yURn}=T5dyk&at{Bud2g?FxmuSqOcK
z4UJrMjY)^av2Yi#RLA^V|5P5r=6>ILR{kZxq-W-E(I&{e7V$(Vp8JM<o6ol<`_{p?
z<L%o5zBSml@9^zF`^FfooXAVU<gJ&v?QI_L3y~Xjdzavi&%(aaQWJ^PJY`kO_^0B>
z?Q&ICN@i2l`iKjPHuu&1@8`H=0|c-c2BSK6DBs+Xbpf{Usf7Sr0dV%SsVNt(en^UD
zoeKW8_SO8v!m<;Qqbr;MRZkDs13l}@LyPh68T`8%|8B*<zu@00{PQ^aKkLcLBVjAy
zOZasvN40uJ9b#g}KdJ5D=5d}e8$tjxrh6G835Gq2P`9D@S3Yp08@DxALY#)wEC>Y*
zh@1#1%P?AQ8vw+NuWFxsK<lWGPSYSuFEBO!a7D^wt$gt`H(b62DJ%aDDbZK6d@|Ss
zZAm<4V<;`ozs5d%?t|ZNq?4=p@0`0Z6opCbq?JU}6Mhup#KkwrwvY^+NoE7@B_hj)
zEfiBAZoJD#W<4wj<LO=boQN#voK4Cz=6tz8K#yTlFPFj(CHsV#(K>{ti8zyJPGZ;q
zOa;{_ALxN>VEh&A7FoE$xz|_o>?BTyMRn{tzu)kyddN~ZB=H)cIyMWVTK<7t<MEE$
zu&1Pb50$;gqFFT(-b0;$U1gRy1_{06kR=;e2;tcd66v$&VAzKAV8@75fhAQrfhj&Z
zJh5TrXt0f;iX~)Rh=?`8i)|x9tE50z)%%%IA+;LrBa$sfYSECnRj5|=+T0ObLoApl
zYlz421Ka7Vu$?qIU+Jy@BaDBTx+^}bb7VQZydu@{I{x9lnhOqzz%<Gn0T4%X;e%pH
zK~tp)8~nL$@O<6iXx-oiz!MF=e+aNc?-FXOeer}1iS`YX&Y7zr^^G-|;K%xl3mDB1
z;E4?^o78WJ>6f-D=Lt&dG~~(q6i|T673{6PdVx@&9e80Cb&p1<83>_I{|f+?jCZ9$
z#_MQR`pNh!4di+a<WLP{TU0}@b|(<By#?`2f;giP1dl%ek1uHu|G*FM=+Ge6AIu{M
z)i67eR{b4jRqahESMCo)+CRB{lFc$10Hna*Y%DW6JTTA8bK)Cn=9tPMlO~c2Q^$l*
zI_g@zUszh+Wh=LtJ<2zm*#KaKJ1ajv+n;XxW9O&Dn^fL=(x}kNB<SzF_a;3I*{WNS
zBFyfLf5OQ=f{Vv)I8G>C!tBe3_l<mb8uS>>V;kGoNND3Lk7P6L0kOh)_IG3%s?tz>
zs>jMJ-_l6Bl(+t?W$CEX=`(A^$koa1xK4+rEzB%hx_Y?=TdKeC6>q(&Zs1;^NT99?
z#8m{~PK2n>z@x82VX33Zqwo!$H4VR;xPWr$s|Tg4>idNJ&VGOxh=MH-Jy6xmq7Skt
zkoYTiAIWFNj;2YzpP?7TBA;T+kHaAP*7U}|Zn5w=_7=(qX?-<Ijufw~W5>brQ{k^|
zKf%gLbvJ$f(rQ=L^XCGc0|gz~Pl47g_7vxhXUurEUBOt~<&x!JqSV}o@^=N7mkB%n
zwdXiT*6Jf&-2Z}8b3KyuGUJO7w<e)HJ=#2#$$B}#LgMdCKyA<vPk<VeF#RWK*V!aW
zOeE3Dy6GGGS^GPW77L{21r*T!&JSXFt}_5QR4t!?$ghz2IH}awTK!7agz&yr3*+5H
z(^NeLxvCz8t9u1Y_udSRi?0vuTPxbIQIs0`cLgEfzo{^NaNkzVWUAdR^X>2{d!jbG
z0WD2I9QA2wd`5;DD9T^84~7}wKL&XAu7yn35=!skRR??EgI5*&^nt{e!O+qxs$2x5
zcn~_<CeXxc15nrfhMqcj7we~09)PX&=)v$83zc?{IOkSv!Fx&sZOGMD@};A$rV`SQ
zoVYrXLk|Ngu098sj#wv|J=JOBNm|DHp}o`itIG_7NX9sxraz@3)h?_fmv`vBY)MHo
zg)KQ<6+O(lN$TgJNw1?M!=0#i!41Y?U~IW4b1WyI<G}8#d=&Fp<M0%4Bh)(q6=Xga
zSK+X~e1!`N_%`9mlsy?^4iHVf%aNqL3@KG^Vi8iRS{&1`5scUK7_bLMOnZ0JyP;+h
zulVRZ{a<Gy4ohP&L_?jKLynw5v*$z+twHzGb#TshR&H-FPO0zErw5Ez5Q&G?gJ^|K
z@>OHpj3>c3rOMn^ehhybFldI+`W&(c5<Z2(=>LQFPg?%m^KDQ5#J(CJe@;Em%AfPV
z(>Clz3$R1gLGjY^XIIpO2>FTpRDB)|si_G0%9B68#RV{6*OKz*BN#ER{J9o8eRh?A
z)T;H&G^>OH`7<6XQ?S`3;KF?Q1F`3R8>uC-yp;S|K+s^<HWvTq<j=vwD1W3~PyX!8
ztqv=Hp4rRJs>dMCt^D}|L}-xw=>!ciC;akfXjD%wks_F=arJk&bT(Q3EDQ(BpQ$js
z_3ZyVEgMh%Y=KeaYz~w^&%*&;B!7OthwgGpb$o`Hdh+KV*orGDe||w{pmeZZLoJd&
zQ{i}}{JA?q`ST;##w?#wYsYAejr=)5#8e6SbFACSPP&!<!}6y@JPFS3gUqu3!}U4r
z%b6fmfW0-?`h7Ly#)^emu+Au0KUwp#(Vdhg{tz72iZB$d=ILnx55;J8;JED$RH4nB
z4lpvp`h|-D6ls=&HcW~|?hUnX*e!F6IT|C^zKYSN%{K^w5VI1v^ggO9EaL_E2!>!w
zI)*UD5)+WRYws$*<N&dF!H9O~%Yi{LhvagY79xg<#$nWAKp~k(NgJOjYU49(BeHC2
z-L7g?H4*EE9d)!zlud5W?Z>_PSkNAZ8j%Ih(Q(7n_6^bWDDyNdvY^|h!wn*a9B2WH
z2e{)zk+%9|W3YwptUPK1<Gpn!N%^RbLe#@B%mvl0L5atkdE6lE6@S*iV@u$$_cZP0
zy9s5`HA(Uae&ZZbul>_9a-)<xlBgS(Lpkx>@4ZsHW#)~4l38MszxQVLejs$JAyRrz
zYu;iLi(?A&mMmq-V)`<cNU(8JO*l<<)`in#x1Cv&Fviim)<9K$@0zz$(AO6iXCOlf
z8hH1*CUy;xZFwkkn*4gqWOZ2qC+6<3ox^bKZZX=$CKioLWiKTtnnGxQ$CY?A%?^f@
z!)g?yv&*Z#Y4cAqZi&80CoD(zmVr?VXe7h$n{XxI^upGas*okJUD50dcx#65R*Mog
zSHNx%h>iaTjn>U*cmE6J|8kN4pR;pdIHqZ-S*fST^3W{I#Dr!u<H3(bmLrMj@!tD6
zJ*@FqLL^I|x={hkht1OJ3Cm@@A7GS#Zs_3Rh7Oj7BFky=m5;D<3rofloNV}iFpXLi
zq(gBC2Tv9JmLebBjB8b(pP&kUY11JSs|~Waa{#o6<+e6Wk6_3?6!EOi`j36uU^xQ}
z<hnAn=hp^&8RkOMREg!Du>&CLU;&J4f*(NDvrfVM#1J<abua;gWz+%NJS`(L9VUcn
z6O|{3KA4bu-nI_mj$K~V6Dd8xuM<u)Y?R*1u2_stz><SH!P3X}h)O}Wbo}fms!EhX
z5{-zyNV-bFHV5)fAaeL6UK2zq@XjG8ls?o@eTNmNp}rwJ5D|}z%VH&%CHFJi&j8gB
zFi4fX_o5Lr+yK?El<naePM^VWTV#1y)nnPAm4o;^JktNu>|COQ(mi*8d;eynJW#H6
zxpc6^>cz_KzdB+w3jRTYvI_!nV8^)-8MS@jLd3u;F8?@Pf$b&S`SAaj{?tj3X8+GG
zukU{VJ*iY4DI|`Me$4+KT^D}h73BYB_x|%A+qp!3!rf)$EKPD?ZxJsmY~q|O=&+HY
z4X>!4$7Th_7i8g_TY2s|JVT5W?=pDIW$_JY?^SM9K&pNs?bT{LVHI>%h}@34HYMIm
zZ%J8v|6TPL8um~<yA_O_rs*s?EPWHhHy<P*%?%mNR0Y;AS^f|@aQvL6+tc*GIAdKO
z<R9LA`MOgcJpC^8=&Jn88D_Ip`p<X;lOXxo!u+h8Uof8J+rfklx(saVixrA#B4-++
z>d6SG1*#-1SCyIsCF<We>YuBBE5jHD)4t)S1RV-V`0YNkjocnK9Oe)<{mtH46c2i}
z-2Y?-RfPWIx?K(|_CGZ{62yf~yj>WM({eV00ejH^_D0rrGd{?9@9w%bBrv;GvLE3a
zy3^vU#=TmQ37|BM$;chXv_KLhh^{?`*@qzETtc=VrpEv=K*PAJVXLu+JE4mRefZlM
zBaDmK94g@!RSUz5t&8{<TjE6=pSM6_Y8UbL1d#$}#wptZUp&!D<#yIZZ`%$DzziFC
zl+`JdkEo|jK0e~|oqdq~3CwKK7LUI~8z@he=H>7IN>RQypPbIh$G=b%vXGa5Ur@fQ
zpMiyMzxX9`a6T@?nfvqD7&w9ZPauux4pA4GD%B>VEPK;p_8}8CY=7Frg;x^<Pu$@k
zOw=6n-3WM@8Zw+g5oR>b&f@BS>Y_uq-{<8*z40!;47c;6iUv50^(u8F7K3<T>Tp!p
z(^MFsGah|vycR&6!uFr#wu;6szx~_6&(i+&*e~_9|B$ILsP>zIaE28q3^|4R&?}_X
zgT|_XJD+-1B-Al9^}yQ+_4#e>tk{9`N@lTStQ;Y`4^i!pm82JCZ=^@9X8f3)U~gi>
zNKccYqb;c20IJS{imR`3IthfC8fYC(m*73Fy0I}XQUO^0L-s;A)jPv@UBp)~T1uBZ
zpY{-59XikPhg%bGa1RZJ3VLZ~a>#AzgW-ZcjhJRvrrEi-Iesx8Nbfy}W&yq5#2Bc<
zL};wj{ay~z=%)*Iv_vYP_hJ}?<WnEL(*mML{Rt<JU3xzc5^9n>Q(-|B(EB0k5TW-W
z8mLR}YdP+qViK5NDLXkXy~py^qxU+>%>sJQ3m4M+G`FQEFp@z36Qs8hh)$k;E3u?e
znc(8%PRj~7Dq9khjbq$8GD(uC`XTvMo4i={P>`XQVg%q7Gs06e(cFzJz%C6Ky<^Wu
zw7*swKXKI@r*WkhAQ-<P2v%{r8bad!84$zkHv+?auGjj(UOix97=A!kFX+)ou#F%S
zWx{MsFX-A4UvPCT{0(5p9yOG-w1Pm<>X%vl5o{=}X?NmaHKDYbpG`Haz?h0T5O{P?
zEM}gJfK<JM#<6BQjEW3tq+=Y*3P1mWGeQquif~v0gp72&12DvOK7N7g>8H84qAnVu
zxM)0pjmwNoswu<-Fq3N9Ru<cd8vSY`=02d91JGtbkoJ@6x}myOTwTr?4Gfxl?{ag0
zZDtp)H6Tmr@D8}_)Zdu_NFu3-=0el~nzcX^@kT50gZ=(j@dKjnX)Knc`i`{0SQvfV
zg<}_P2#z7<+YlSz08->JZld>Ij-wFt2(A-B&{qBWKU?c6t&C;{5}$}@%xAPgz6J8*
zjUSfg$Ma8d$2iO(0O`)*?z-j2JKeFmt?$DU{CE{7oABd#!Ti`lHu3n8Q#jJW?*@^a
z33Vb@)_MFW6T65XA3xc}RmU@sAA2}qEI(dGt4l`pR2cGl_85LVawN<3s8`u+K0lti
ztF9GSPtu<t{3yngK$@@*(tvysKgQW|06#7Sn&8L1L0RzQDfmINm%Et#Mi4H|kH2L!
z1#l3H9eTS0jElEk?sRJQJCDlC<Hnr~(w{zV^yIm04@$@}tPU<vfPPe;ID&!abEM!6
zX4h!<PJt+0FP9C$`Oc?Y>pH1AkT8&GEHg&W2L{E$irnP(YYN-17<Bts6{zDWF52_f
zC3ZT){)wprxmqrfuaBWI_OlJs6D+{EqIVI~V+>%drtoRfkUb=JuuMQ|9rBDOF#4_u
zEczL5{6a^>6hvAzApUN5%~C0XOS#~3Xp@qbfenzfpF7c=fJiV3;ixgFYQ;r@T@jI)
z#C+2ekS1Evvtw@viH(!&l`~dS_7RF`Alzj5UUXSAFK<an06(o&nu(8B>T)KYQ|>Kj
z@E}jskQ;Ibp+yG>ihPNyHqJdgU(9*=R&_M2FpcOosMY&4C<~|izx*3{PVo350(0|@
z?|C17C?x2Ae7`Z>9bZqtp1C(DWyg2IFiW-%s!NP-6>M`(ao_m9X<VlRjqlA{=z%IR
zzQ5Q(AQz4Aw~1lF_+CUQD$I2OYW@4h*Yn?FrVD$+M+Wl1CJn2tb^?-l6Ti^^h)L`#
zA1ZQs7W<c^k>pe?kF^f*TKhd#I{B?xDdhcb47}H|I2;I`mA`_O^m)gAYZaGo+W^kZ
zqmhR#^^4E{B8vunKNR||7d1gT29p2+5#F_E8YmfIDHz7cMm&P>r$280)}i4WXc9(c
zxNsj&O(c}N3#bfY8RMe(N#VEqQ>ha#|JqtVe%~6sN%$FuI;3m2I3(aupy-)chT}n1
zE~iewA@HD4aK{Vv7xz;?U9!GAei(=_`%`U#<os@YA3Y7eEE!k#LDuA<<>I6BccIwx
zGfzSOvs8Qi<nK*^l%EfL%^I4QoW(@Th>FBh{Yok$sw@Xv@?2cJ{{axV0w78pp%VV^
zugMb@V4M&Aw9qImq||q*JJ~`YTNcEx*p`4{GdUf<jOG&FZzAtUy)M`W4zyheY``5E
z{Se$<Bii9@)YuMyK+EePav0z*7$7_{4})guVw1X^_7l4}a4?e{-&%4mW-cs=ihuq7
z7TN|Y2Q3TDe$7rt73|lHHVI}w0>^Qx-v2DlD_ve7{q+70RSDwHS>RDvFFp=6@Lxuj
zEK2Qu&>EAFCyxw~Kq2=U285DXdWnqO`15M+e0DE!-n{Vj{5Pm`t*}Y^RsXK~c6?Qs
z>uSGb(ep>f%jZt8{G1>^C*A$E)2Kux#l#<%5-_%YOwFRLL7|BiWk2T!jfB9WWN_uV
zepy?*uVTf5tZ(*G!O8=Ln2$wr=6$YhtA;j!qc3_JA`|B}bkaYLK+>1U<k_kSvu}PA
zMYC0JGkxc`N&+?rX!upPvGmdJ6et6?{i@5DKmViPe09`cOEx3@J9mKm8wa4zd;QSI
zZ{HXuppXnQYaDIT96-j9Wi&Ln#ENM-2q6o@#`*n;mmm7(0+xyO)l41<o8gz>!xHMr
z4x{^<CqEoQ5i={M@qv?9uQWxR%jF@l^x@JLSDh9g<jM+<hF1LeFCMj5<x?z!W1hE-
zi174<T*44a4`oMi@ym5`@ylS;k9S@c_Q+N56_00uesZS=XGTJe!WO||J|@*qu>g`s
zN3}|PU*Pgx+n;96G*Y`IxkRVavWcsYIyHvtY;+0J&ZNcEjV2BE`e8oOTxiyZ8Bimt
zP6mL*gHm?nUprrUe}CmSwl6$SeHu~-JMNyRJ`s-E0KsEMI3M25`S1eHQ-=v{eC0da
zp_yW7R$!lF+->|tU(LlI1Xc0z7swLkSX5_+mA=q2a6H|b){-QcT1PG%H9(_yt0vP0
zTA41p`_~sP)c)`Z!rx-y6YFjRF1?9jTwOv>g`bYTe41-v^{4W@5;ot7EUO%L*eGs#
zR`$LP3rimb=&E|<&{3g_WIH*9S;t8@15@J$EZ!N(Ngj==)ZZ~tCRTQ%X!;<?*5!Cm
zThZ(T<6_YGhb)Zg8hgI=$o<NGC`Vj*Errb5_qM>%nXal0toAi5GIMg2LAO_y!Ht1c
zA2Dkhvxcg<y&r<VQPU!{HKcud>k$O8Z#7Qo?Jcg-n)x-7^wrTw+J;HGN;1q&Z2eH>
zc7SO+maKjV&n0YNm)M)|VCgGVApP(DTb@vn=vv>v+VZvdPI*uq6{joiHwyDws>~KL
zNc@nW3&GZpsVJovnL;ncBpf(Sr$HBXHdMKrE1&<0xd00KXyHM1K&tiCjC@acWH?tW
zbm2*KZ<H3f1pb1A{cC~-@Iftgl3(V<Df8erYzbv*)II<!em{KHh8L`y0_iD{*1RJo
z$~~PHio#~HUP4VWTN5$0^8F9Zg|7Gv5Ng(`r62IF79a|y9(GsR&&yQDyC0f%h70Wd
zfcKz9rBKF-OZ9md&8_=t&Ur^)QHlM5zM60Gg_Ch9itwSYX6JW<WEBBw`hqhds)Fo&
zFJF(4Z>R+y*bj&Y>8p9|?`Q$Eh2GZJjE(E=osZs;>7xiqpM2~oxY4a*T(`Ld%bAg!
z#37A(8?Abx&QGL{G$k8Y8S(7N+Q}m@2vQpygtYb*9e_RRT*BLVh3xyB)s1^8aA>Ig
zp0b6=LqrGi%J1Z)>YpQ|8}1+WM@@Sb!-Na+31ZThoovM(O@Nqf<4r4j(3Ok<wclqH
z){s$#Ji?JOeeP?}jr-Y9RIgGrAGNzOs;XbXi^#ZRAwi~QyCG^O9zFu$9DOy@Kyt+I
z%YFJ$bt?S9xv%Q76U2#K6GuVr7=0a_sU;!C2C*)t#@?(UCYhFwq->n!5|ESUpYp{k
zFDm;9DB8sI1nz?`r;wz$eFIK~jpJIEypLM`g#ecA5b~!wlar`D&_MC{5AjX^lPHdF
zg8i*;ClGK@4cnIn1~h2z>hj~CMB&%}QP6TAerpR$dHo?g$o+a?rhW~!DeQ(TztGs5
z@I8A<>&n+rdSc}W)J#{Zz5k3i5F@E>V0vfe+Xu;%9f)^*_=>Y3uC_0YEYS9qmsmNW
z|0@twg@~IjTKq9NIZ|hlmHZ>+=BtOubS#AR+5EgR9<{8zVSI$_)5s+s+(^}eTzp1k
zLvW$~?6X{Iyvq?_WF&#ol@IKrpY<glXQL*j#ED6J$iC)fJ$3nQ3$!pHlsQB_`NoIE
zmwd1$HaT}hO#pbAQ>CkF8Gh6&SlP-Udwi?2tLjP^C90XW1ZL7t=}to*Q=MglH|hP|
zFM2lP;XtRRLP-d@o#m+wPow1t;zkn*_!=UST*X8>zTP9!)qDGi^ktMs9}hUp66p;v
zo9`w9A<}KI3yN++VNDR}y+egat!$yIsuv_v_hTnZ6KOP(&Y^j91bBnAxhTAuXhUN8
zRW<0*EHoM?Pi>$PuWW3_*S|I0@Pv=hl5Th^A0*xOne5SRR?JVg?KR!rM*)3<%!-!^
z>2|2f{BHo=SQB)+kD$A1;zGWv)ssNCi(x}b{A}+rP-*xSF63+bhL2%)j1@rG7!B$C
zF~|o8H-+YGldU}9;8FY#Vbkp4bU?cEMO={-&zKy(OL3m{b?N(i`Mb1}?$VxamtOu;
zUYF!joS#4ftql<qE(oLeg=3gC(WTeW33TZT(zB{>;72XTUb05H6^H?wCVLh49TUVX
zY4Tmgovm069a){wpSfdil5TI3Yzg)0Pi;Wg8}t=F-}d$9!9D%G*%{@5Oe1j81GH^^
zZvfy>_4I22y<tuCW@p`-OXa7kn!V}8`b78UW@1ANaQhblp`nhS-H@9YZ1>iU@4tJQ
zW7SD+<Kw%bt9e8Ft8B~&vv>FKcV{o%oz6pScbxU!;N-UC9<tzb#XrQ-q#(i#fn~C%
z2zfdP?{bm&`P3))=6@|%BWh_seVouf8o*k6w1JKwaM)kIu4MU%3vp2|bPH-!Kyp-2
z!bCd04;b<WVCntk2~sA~!2lusR*tu?xo;JCTaP-uzeAG0;ad(UiD+ci8(UxuqpRN^
z>dbf;j64rzc`!X%-@g8^V`p?9dsesOWJf-7_`-&=MDO_pkf-$rS>;3Cqd&-gbU%y-
zq5Dun^~6x`2k4)_?7G0RGQA_K3J|ysWlMI=5A^&%phTc7H^*P__`rg}t?xP5)<4?6
zRQJmvkixjHY()qhk=wOxQXM{aw1Ui%8=b4dYZ>#Pe{z-h!F`LR&meu8CmrqCzM79;
z;cBk(zI{i9`fA?SFZbg`mQ#6ab?yh;>HFp=1l*TV&|S{s{p5{&A68I)O2Pa4WBu^0
z0ktvq<hBz%5j;EU7s2Df;+TkgqJY*Y5B}a0!P=fYRDI{K0V<z0sUH&n*H!aNw$N2|
zJKod}u!pNJZ31I}FDCDW4rt?KKuzA|!}Q@@{FqMAn9e~98q*!}F@+{SL_G&<xX7qu
zO<;Ps#&m?nv<^R54H-;v^$4aK{99FX#*h;>r$yI4_uKWvMy(HyI!IH7>w}-}?5EN`
zno1|4fTq$r&lQj7U4IFn5^I7=I}&tP&1Lda^~VE2rL|ZL<c;T<`wV(KzwX2I{hj=n
zj?tLjiWW4c$K+!w;~5UZlr@3r*{BIjbMjMFfrivh7E^CL@7ep`FrGfAk<Y&jN#jOD
zCe+zrU&zcn;R04ES^n^iEWcH7`9S|W*Yr@#3ANvFcRvLiY<54T2af@$3S;*VZxoL8
zEGFordH^Sk<k3-A;BnL7eO%?jo8iL`shbAxF%KTT9c1xy7_C`6G=u2xy&k;X0mSt8
zrf_L^GTug}2kuAR!XO>kYX1GGwI(fiKk6&+?he{rHDLSl?Sz8%FXG7@qy@L%xmnvk
z#<b<{|8iJ{rQ640sLj~_Ljvf3Qor<{xY6y465v<q(Medt_%i(XZn-i4?VGvdXub>z
zCw!C+$z9dCa(Bd<xcwZoPsQZP4}C~oHaMZ)k|bH+Ms(7PuY)2qU$1f0Qbe`pp1@4#
z$0_G)4^4zQ*9V9PbK_0i@*BH9*I)TSdE~ZaclL;8sr^Of!9i@k*T^?GiS<YB2H1P#
zFa*(~KYTZ~{HL*hma4819L$gIC~Qu8Y%KjYNBNEI@4vHrAiwZ<1x6!D=5`Er@`Bh9
ze&o|+;Y@<wb5A~$tPL@_(Wz{No34K43ADkmI|E?>s~J$#s7GMWz-tskjvPTqL2%;;
z!Z8QP;hLx6<bk#JbvT3ISDyF+{mX2oU*Y28Bl~FWWieRdYL}-Atf+$g%ekNASLFry
zUwXJiz9ta9`BV!x)+vT0$!gty_81Y{Q$*b1p==fDL5F#m@cdLbNmJp-xKQDb+W&Sg
z9B(K*UYltBNLSly@3#Q|+TWGH-_Yj@7|{Loe|rAzxVK+{`m{N+Azl}Wu7%b2;GD|?
zB}n=3L3tEwSeI9<DE|q#EPY^fzCMo$x<y}tY6sUmxW9X_p%E$i^D&n&wo>mDI_j7|
z;spvVDTAS2Cs>*!?&-=bu!c=b_QpaMafibJzu<e4+`i=Xo6x)D;Rmo4$s}H1hWilB
zG0ki;O30vyn*iM*dRiw;&2pO9=Onno7OW=Rlsbz0P1$uT!3*$+>yQ5}#B-3q^oDv+
zPd<4@E557pSMODsj!Q&1zK&9JlTA|f<Ty<gZWI?TKG0&(c<q`$?2;dBsxV3b21?a;
zcf#gKnjb@KFE&w%;E#R`D0!&Ze24r8(L!oUfAEZZK^HF;ZXBkb=9<J5iLy(`*I!}9
z!&amUJ|i8<%DNsS7goE&+iXTn1FmK*jI6Ln6z<F(0j)Ema;j}tuZ6CfZ8ngwVf7Md
z$fzClI^tqX0gE9e!Z2t4YK>*JdID=&uSi(^n0uYRj%C~UX}I?F<q$GQXDg5CtHKMe
zxX(=XmvXXg0uVe0My)zvN6_~uh5%`PXRsK@RLwwZYKM9lZJ>zsLlBO6jmrD<w@~#H
z2)zm9S38~<17Z*QJw}m)-*5jx&?w-+{PHMvEjA+p_(Q`({?otdKmYCl^6LZO`{rdn
zKE!*J;GYb?fv+ujd}}*jd>+TDTB|(VQ*w^0HJ-d5eei3ICapCh*!zX2V}<ry9RQaV
zw8lqIeJCduz~|;lh@`60YHSdiBmh4TA&ybf$)>=?@(@;uLd<4q%re+;1!kiT7OlP(
zKfr7TFq4`v7X}-LV(DAUieOvJQN&@%^IFVDPIA1L_AP%p>H}ZUEJ&Vf{QlW|H#8ri
zbpKiL^LBjfED((tRil4vSY;FMo4UiY+9uXNt!E?KkEv%wjOuug)d4eKO90zn<Ik1P
zO5OoBHglcUKo#8S6y0&!CGivF!l*^U=_2282S)wMu1fK7-iz&D<1_40SJKuMkuUa)
zT;X#Pr;2<t4jKTztEXmr7@rK`@Pt+h=iG~0e%Z2EKv(?&Td|nIlO)EWCW9Z$;A<b(
zWWkx^;NwYF%$5A*{-wwBK&o2nxDl&~PPnu1Tc|5w-C<!+)ij!6uRg(RT1fU|YiN6F
z)oa0)h6X^_8psu{pHt1BQ|1lhTx{<~m^vSd8Z@rB7|E%|(Z<Y|@d5IaLx5w?-9CBT
z{zL)MzpaUWXq^x}g2)uuWpVs~=wo34Nm#0UCI=0tBFj6<+CUeW8Dj;yQ^{8jeiX*>
z9Mto^5aE!pNtJpw2nsgl{80F6p&T3pWjLUq$AeHLB{?8JBhNl{>Q_7h3>f;(i7<((
z7sP8syd-QMUfpydR+o9SKpro^-7m7>GEl%~A&eLwEHt0vn3tbw0xa1AEHU=DekDHc
zz~!o}Wz@`H6%0;;9-M1;lfn6sY!KD_LTlSgAN9x@(ckq;&FWlKPPoAL8T@cr0r;WZ
zaP-C8`HRv05_KcdR8wf;`X;XVKJ1TBSGvzq_`G9<BeyeyO%b5<RavwoXMf3X7fNtm
zH?B&eC9X8DURBVG6Ll|M*j0M*w6+;u*S&ZcMv%FIdB2Pg&ECHN8XGLj%rFg}YRa9S
zp5|jc+6V;*>{N)r=^BAkGy<R32%M%(0|yA?&SOjEnXgGp)w5?xOW^V0rpd7x+a#&$
zYf>*kd(_P<3;O&e-Q+9S(}XNrulKGV)=mBn4vE|r655g*=eAIut252waEpY!HwyWk
zt_DZ$9%}485DwGL7}1qKA3o_fyOp5cTdkQ6;-LWsm2aUjoD7S3rlad*MNGy8gC_CY
zgkOFlAl{d5<WDF)l|N<aVf-miM|03E9>kt<lF!j{z4v#*oL=twkNmm(pp@Jjw6^jK
zZ&igDUex<jq%l-TfBg)@uCYqsfw30_fnIaXW+xZAH<w|4Q6e5W{^9x+Ehvvk_aX}D
z?Zgi;%Y89_vYohcZNSDSYl3-XAGNDy$6Y9zt7-s8JqG!t`G>lKzN*F|eX+U6)03Ac
zQuD<)S8y@+A^c5-(&L5pJU5n1@8x8X=48`#&PqB--oB2R$+byN7ZE*4HJS<?8tn8h
zmcU%v6Q-H}8iC+Y((^B4p*wyJzt@vQ3cf7X#BrHZW1cGKjd1YT%tSFl4ySq1&NjPf
zjBrfsspJkRCZWgI{F>`#sjwwo1@Y`60j$oX>jp1uj9;BSk}J0PYluw=r28Rypucne
zYg7^F+Q)x!yS9`m=tehZg6N(;2otMHP<WAKY4vkN<^r1o)#K%$KQqBQ`@>u1WS7*f
zlU5eh_25^{D|7|^OfQ`d-cf|r`TLR4YOcZ$q<QQi(x9VGp{8B;bO@Z@W}v0^rWIFt
z1!)ZOHglkxv1t?KTa$gmH0-ErV;S@1K^YS%TFFx$ESzE<JspyVfphRo6&B|&WiGC9
z>8QgOsijBH@wdx-r0-&`*iG-%50~Ku03C+%I)pYGN0F8Y(KzW-Y9$E3d!zP6zrCDA
zb!{lCt}>a`$VBT&q=nSeU=e)<4P_J=Kud#0=As{sXs^Wu1+><&Rv+wQ48)O`A-IYi
z22zKl(;RCe?owzD<}zw0b2|s;Uj~bf`Fff)*g~r`3E7>oWK)2918Au$e~FjAZaJW^
zM3P)8&4-fey;ta`8AUyd#R>`WU100duYGq3+KY=eBEg#MZD#}vBOV`*1P~trx88*|
zL6;b*f#2v$nxT5P6NcJntT5Cq_yI#b`v3}qWcU)GU};AN9axI$Y7v0-)|ydfLoTI`
z24XS@k&Y+HG`7oInqK@`5<7IKL9$jmGeR(1E7l>GeI0H}@ttgva7(eTw06pXWrGA5
zXEI;0xnkJa+&v{XojJzlimtJ_Vac79+1KU{aUr*FNMyFL$rWxgv`m9d^%veZbC6B;
z3KK@uCRh4k$me(By&r)$_vB<+$l<_$jwS6hS=;K2-kZ^Xp0&m2gw*0)H+INZ-dQl@
zVQuidyR8iQK|CAKRkH#=Am(4F@ui`U$SG#r`3Xyl*$)6tBfVJT>>+&>>|E=&?tO>d
zF$^fSdHQs3mQVNCs*p>~+#XVhb&bY4sj;5VV11ky*I4fdtaDYcw;)*B(C#cw11$*I
znI>))((;AXQ6OM<UQ<AvU34?gZzIInUN`fCZf0#a`$sU4ks?PeQGP;ogBB$bNG#=K
zfEv1&;ODO)3v9d^>PJKUH*0fJ!1`OnP>REgPZM+{7$KxqK}Ij;n8VT18V;qC`Waga
za_h?*k=5b8hqJ4pI`(87-Flb?U^pD#tPlI{vx_@fC#=@o4Okj%HH=6D70$R*v=icU
zUR!VxFXOJ9ZWu-OHSLDlTdPBvUC`FHe{|a_<L9M`BC7ogI}3|7yjx%oxWQs^btIan
z8TZdKB5cZ5^#ZjQg)+6sv!E563ZKWZUF}qmRkGf3+YwsR?6}3%{wwg(MZd^y(EVCZ
z%T1?AK){S<&Rh4e0`zF_jYv~Vum)4_(-1-$T!8LAhNFw$FH*<bgk}-SQ*EgT#A{3u
zy*1s%%?_kDsoDSI+f!Ti0$yxhvpQ<M&J#A+{twI}a_3Vpqub_w^UoSw8$sFDf1a|M
ztNr#gB?>IerTEd-GoOt0d=nGJ?ED1;49DRVXbOzOZ?*~;hb6LKzK-2Us2gc{$<vR(
z7J3|F>P0Na_2)lnBcupk7doBp4v;_9JH@p01>MpaUQ0B!^oZ}{wG>ycP-qJ2?t9+0
zG)~RVYe{S~U8v(3i&&1n0kqjD#{<|qE+Npn*SB<g7XvoB&1K+w!(~ae>}Cxlsc!zc
zZF7?9gHh%6uF3W;sb1s;g`hapZT;(}^`_pF(5lX*0|H9t$G_*y>rt2SA`+>#KQd@+
zaX_G9mg0v6{*FjUeuI4+OC{A1Sf*s1W?kt6@O3sh5(!vd>tia8IzbGi^a;AivnWD9
zH`5g;EgdZ;S&w>}h=L|9UN5$Fdy%B*KyeH+ogJWIORw0Cg2o)MtodlAfP9bjfQ4Lh
zn^3c5rpcEJ!vvC4UAMA8M_n7cC18(}GFsO<jP{V!CSr?nGWn!t2dxP_#no-FuXU->
zf|4oqFTZ+mbE*v&Rs*Pq-F)k{mgOU4Bt!(MicHGLI7dp{d*&0592Ts><B_gT<cR-b
zS1sb&^?fR`-GM*J4YH-hg@=6c5RUbt0%#;j3kUj%$LwkJsIQUIXgS7~Ie+%kw#`RX
zV%yAus}kHi4?keB+;Z6Rr^B1V8VS~bMB7ZRib8qDCX&(w9vnWn5{_T8Uy6jvd0f2>
zc*u3PQRoBu9)m*s<KKqMv-ah5%dD;05`ERaoH%5H&zB?TH(!SiD+={zO{~YC9Vz6A
zv4yUxm4Ktlp+?}Z<#JB_;dU}RNTt4tU={T@%u5sH!g+V^b!2zmdjjrnQad~gx}tE(
z=`x>R*EpLGNaH2SixQH&C;?T>eWlH6wyD?1QHAkJM{wjBz><;vmrWjPA2nl0#MS5V
z2vW3~z(W#rk<*Vdq%7myFqEG2F++r+p8-W(d&E)Il(6VJd}4A-FJ1TFmSw)Abyo;^
z*;VX=sfzJW$~Zdjy(yHWu@6d%rH}GjprJ|4GIURyX~yHCaqNmjof!~B&RGxFg6R(q
zV+x>5%am+GNKW#TgSs)u1RkB59XY&y1+az~H-t~9@o=92(|Bd1YXNd1w<~bTzT^_G
z%=<KofQ38d4w9}{T|8W-+zd9*RkH{`m~ySqyc$p3bLT@aN`Ni+QyydQ@ia9YQ+L2}
zf-VUIy6hD6IsgrPCWNr90hV16CAw#I108;IxP49;%*MF|sac$fD>PhBkyDljxoCqB
z-+#?Nm6B)(SU)t(PNkP`@TQX6fIG6pw=AKa`57FaML59~9Dq}N5IFVa{5Tz{aT@31
zG;Ls<;_C2XoYpp!iDWK770JZCkg6D%B&1ncqM$g^5hOOfOa?5`dl$x|_a^*tiIP+g
z-4sNRO&_Dbz3Qh&O4DOE@U<3q_16z#jK&4xwCQ7XY93A}Xq+zD!s2urq@oqUE&*K<
z3E#xk)i)N=Y2(HSrA2?aE$9h>WSNyVS^Pj~6Un*C-beKX5Y3y*gm-O&|BDZ@zwMes
zxb3<bW;#6QYkmvES#JuYkOEcTil0#WRQk}{<Z*YJ(R_p%%}gh|sE%LWRt{_z%H}3~
zXlh1>&ZEpU`7(}@Pm$RqDx&vkFd)RG_<*h0beoEF{1n;NIVTOVUG1x%8d-1#UTm)T
z>%H6~A`6c2<${x73cGbrk1W^&FLVbnk*GKjpZ}<&reK8VK6e<?fr`(r?Xd=cI&;SK
zIN8<C6B}5|C`SD$7I-Z2xsF3*wO6M5Rix@fJI$L0&197xbY0cwu*c<^hG=GFnHqYZ
zc)Rx~C|SqdFy@zC0}Q!8g#FF(+|?v0jZWFygnd$Tkm*Z8-DUb>mH22Wt8ta@D4hTj
zXsvnaH5hAd4kU?9LOZ3q%-2&!Usa$u9n`~GZ`u%1oR3t9;(QxFP@IR|hQfe>FPn9f
zP|b8KHV=ioon4-*ROMLUX!D?XR%ge^#cZ}qN7F)1$1TgKcQ`uSH3TTT<xb2v5=p14
z0#WT8IwU#Tfhk@V7$cexzMRN{9kAak$~X-Q7?ypILAn6Zk{d?l+5$X4UMh4Xrh0b+
zzD^gIgvm&Wu~75`yiEmFmLj))MLYAlmgrBt7%o#^c-dN$XfXwM)pIC?x}wMYD-6vK
zY5s)L&A!2oS{z|yKxf%Om<pdO=rJLXT5E|eaz~;E_M^l!Mr7^o4_oLxAFBwo*@#<3
zY&&Y@I|k?6e#n~O&$`-VwQ4f8qBBA!SvjS0Te&bY76yr!Vlt%&-K-~(3+Jz)nE9^&
zA6VlQ$>%E|P#~Y{dR+P3#uSWhlZ*x)^swMT*jT-IEhvt)J|`C?o%~kza6C9^P;NQ|
zHh32dQq0`k<Mf!jTVO1zyAy4yHh#_z?o_S@nz4GIuxEU;7|0m%rGl#ATGmvTLmHrh
zsD<K^Q187_!U2;@@jZS7%=LF?sQob;@x`c$`jyuMCm8gL`-WSq4VQpX(4ap}l+;by
z)%Fw>5$YjLFHu^9QAES8GsO16#lK^9jME7Oyi+=lg&_K+y+O^KenizQ1GwvR?kzwB
zM0M8{cM7&u<31ivq|XnDc)Sij5RXw<b-_4sABR?|)oZfb#-`dg9FZAsQ_Hvq$J9Kk
zTHM!a+>ss1?Ln$?FjX7OZ)e6LJydjoahN(g9$`13+&M1gkp;CVN^X(PVlmt4P?}8d
z>%jsjOAl@qw-g&s6MCDJMkt<>@)dN3mQ1HwigaCtEGoGq#em@nM5t8UKe2vfrXHh(
zIEMpG0Rwntn03y2Sm+AbUNPLCzof2>*`1?T=Z?rt^5<xju3)ZiP~dsx*&)d_i1$u~
z{Bto~Pzeg4FQTm7zKh!rf)~5Y!Uqui^(*J02@K}P8^D1`<>v=Gp@_K?dI??uB!wUC
zLrMujQp6~QyO8G1-c=qkat(yIM<2mr!HYPvj;Tz^JyO5oW7KxCHD6zYY0iN|vicU*
z2^i;Edm$hSpnouyE07z?ZBv{sIFv}wFU{RH8S3Llc8)Id<@txKp}eBAe#hJd!zE=I
z9Jlau$mra5CaW?N$<M0waXBrWnV=k|W?40PXsLA8{Nnv4yyK3()@RRIao|qZdTgU}
z`fB$21#bq7bSz{&J7Le#7N%yfCEBwo%RE!SEM9DX7Rj_$FHpo-5H5c%(R00Xi4<~|
zJx%IX7Wewxj9CHUcNXZ6rTAYS#9&R-?$SudNG4jydB_zn>>~^Qh^`bb?w9?+zi=GI
ziP}}u`~GmVa18&zTcr7$D(EVg_;3Hv*H2(mR3xs}`HB=|8)Dt=E0HJU?Sjok!cx*F
zfwWvsj}U=uoZ5lpVHgM3?Jlqa;>E}iZKMUvi7=L+{3;M$|7%VRY)<^gm9XDasAb$t
zw6mhFeNx@N=~4K*UwS0|o{rDBkHA-KM~X(o-9!|HaEI5H;0Eg-m90<|h07C)4ze83
zS5;JpqLisgwH9mzW1<e)sSY2R#ZMF_#R`c6VQ^p+O(cSv0O#6(`1!AGATHU;R$LQd
z*3#=GrK2uP;UEi%uFCJyBEWOA7cIT0E`$PVgbA!@fvZ(ayaax!T%!EV?air#`(qJ9
zLBA<q?1BfW+{)nx5|I}r{$-JlYf(!UvK41<f%|LcV$v|DJiQI=mu7Z7rm|u#!WPUy
zgfroq#h7A%0?)Rw5SyH{u=c8zY^QTkMH}I|NtnHhDnv9(5@1A;psi1$h=eAmOE1~*
z##NlQ@e;jbxTzs2Xb;K~Yo@aF9`akBK0<znL^|Fx-AGkLI{pDV^>RyfMXeyw4GGy%
z(Z*+-9EG3|Lh=+-@1+BkN}`mBg!&EuScqjo5T|cp%4SmimYWI_)NI-ITdodcA>|}6
zHi=&8P`D%>kOAwd_i-dz7=gW{Of>jEiCVU7ApT2WXY2M{{L6#-xyaHa(`w-bmYWIU
z>VCTL0^6Nr;ibp*3vaZAC-i7=>Cs^6(a?LJuaANBXt6LN9RrSMhaIQ%DgEL#$I{rt
ze@GDBrUPSdJRKK*$Kvng%Ext+LDwUNn(WY}qRA*Tf&|NdoaFvw5cbJebE^S@eX7gl
z?rafINq8SYZAux(9@)o3nc4B{Q73eQ&XA!ojs#`t|6}h;z@sX%ZUSkENE=ilj3Pz_
zjSCtU#~`SUqSGj9R2-wCW)v}s3ql8@0s;vd46V51xG`>njti~?L?^gFR8U+{T!(R+
zmucKbMN#vgbF1nt-LJdTNju{F@O`A;Qp>HXb5Gs6wY-nfq;Owd{e_Iro`H1*BkMo-
z!T4+{?7fW6*!GtXT?qI##+C-V!7Wvt-(h?g`?}*qzFuy>);lu8TqHEuC`=W@%+p~)
ziRBB)t0t?eF0OnJsq#IHIadr>)_*1C8~C-9Z!Rr5h=f`z@~t)cxVWrg`}kBJR;i9s
zsoteh{Y<5LC{oR+)>@C1RP}qjl)%())pn|W-Ie*7VT3B_E~Ozl`UT{im7+7&x&oBc
z(p0IBcx;7qEq#A!T-~o$we<VXr0#e5R_eYSKd92)b3AoFR2Ijeh2Fzj6nm@i8ZQ2E
zqxCJ7;zyrKimSen6ql-ce--0_R<-8k@u|M8QoTZ@dWlN40)jx!Nl5h<YR$xUPu0Hv
zlv>v9n<pyulKsft%$)!Pr}ggDVKm0=dagpH+4Wo<KO4MM)yO1FucA%*Dtw=eAJoWM
z*SE5scZ^S!CwYNuc2=pr`K7epI+bcSq?+}5j;l}Gc9bs%7HPw)NNEb(HANG4q3>B3
zfrcA*sV(Y=>O`qS@cYC4kcW>3<i#3WDQPzH2Lm$y#+%xbe+^H`2!4unU{=RR*leJ)
zsbZMV3@mt(-j(1=zWju1sQD7Mcwp&bd9i>mR;U+PMmjUF$>VrllWJY28DA7z*JC*w
zSsLpXQ=J#D<U95)<aEIujDa4i9=}O)(fhr`6wZlkp)BOiXx0)`k}?@f&|KU-5qHRZ
zhfUNl1Jw~Yc{zZ`fr0F$+8W`}<?Vm~YC?KGXv|FhA_rN2bI#R1>u(qn+VL;WG2xtQ
z<`50uh&yXKr>kMjx5VW9^wlWdoZHR$>6kXFY2$ul2;Ucp*%p#r-|)bF=2LI(_ovk)
z)~g4f?(-U-W`~#92)_G`V2K#Tl787*ny(K7EVH)7xqz%`z9_d=;02l{>F{xR>(am5
zNuTHCIq9E+Qw>w5FXc6x2HCO1e-CRc7>dvUZ0+x1eTQz7&-~B-8;(|<jjC$Z3beHO
zpQ!V4=ifbL{u!Qshz;W0XeZy}djEl7j{0a8mMYahjq_la;|T}D&iA;M(p{bi1l@Hx
z_~Q4yu1H94QbKwYGe~cLZ+br8_bO&;0|JH2#!pDEe4pL#DX&j@tKnltde0$XE7H3)
zZF+Soy{csC#qX~Nc=M?$@C)Nt-}I1$tGu)I-dGMU{WYOeevj<e2ycp#AUq0@4S7<h
zukkKjk@YNC+|#at50_vHFVogGu}^@bd!_sW3;3p&-p9Tv8N&4nJtoE}Z#!NhCl+5}
zH^o!>9R@UU@48yI>vt7w?Fz1B2p7!w4qX`UF`}chNUgM3vaTaZ2)q0_l@3anxETp-
z94}*?860~CI7x^rnYXXz75-pq#rX<Th+St0XPXQ86|s0oL>y}>2~Jv#AA@Jb<M=Wf
z7^MAknD#+Vm<$E^LOL!l6HYI#MV<1PvRN|eU|k41#mtO}s~W+ryDsBH`npW8b8cl*
za8*fFMCGg}DMQTr0+siZnBru#WO?7mE=}b<huQqZ`3cORC~uoyu(7K<ZwdD0Eq30z
zQMp!>Qj{_`8Az9^ii_qo@e!JiFHztS>=}7ffiCxFI19~rY9-d8=;4|BTndlyn7M;n
zQ+;}}60XU7x#t^c=*kEd3~)&ZXA2l*W`68-2O=R5K)$sds|nd6EiCO}nmQdw#2)pE
zi&dWUBu_8AFvqEql?1HQbkO;}LFK6&hsb5X`{=L@zG3Al4ok$+m1)mXRa_cmnCXAx
z*X}=9_dM@!<Wxe(Hh~k~|MRNU@4NZMpSG5;<nGF;_*Dnk8W?%F=WBtf^Gb2g$+L(7
z+AQFgxky19^5mWa^}Ax~8rIgJ^T%(CELyk=sR6`;FmvmCw`v9#R2d~G;T7~88p$is
z0;FUKl8dEINLj_>F%!x#gk*S7KGtHba$ZgdG%pgNBt*XTk0~k#VJaO*^>&K3F!kyB
z3T$;t;Xc>nQ1iH=<y)0BcOg_o{411tgnm~^DMA#nqDuRla9tS@(JSo2g?J?{kxILm
zP&mlj+?g)<C>P2{s*#^mUZlXD5-qWAoQx%0&s+ZirJxdbVAvh3ZWk%p%Hm}s7qhJ1
zc9N$&iPZ10(lP>M1Jtra{9nOZO3;rUY=|NmUFKo&1Fx5%M1(5tTQOgy8nV7C>$k|d
z{2JsUO{-I>@t=-zpYJGJ>4ICmh@sdq>~tL=T~y^Nj|%_H3kbhc+VEix7s@DHiM38I
zrYp8)pyvUKP;T|j$Rg{<uK}l;<bywxKh`j+od#+UiPJen583_H5AO;Ui{xR}55rgM
zVsy8T_TF@X0-gXIVdZRR087V)7P}6-<sH$Ltnys-VlG|w8b0#IX~S|?$@kRD-Y|=X
zA+)#T)77`I!>K_mXMo^)ZFj)_js}0v%Ksj^EZ!Es?Vu`raJ%Oba2C5?oEORKskruw
z6#qRF_qR=0M)Uo1b1Z7!{M=Y4>zvE|Q(L~=FTVR3<iqzftvBEib{eVdO1qIb!T36d
z+H5K7-t*1XnaEK+yK|DcdKb~sxt)ys$g>AIC?4c|pW=uyRNvDpP<^MPXOOJo&s;a@
zYXS^Luny0<p3Jx`FdEnVXWmuv-9_qMdEC3+%kb`G^{yMP-SK+x-GS;|zJBM|mIjmV
zUn8IF(y;z99*&$fMO+Gs3fUBQR(DJ@rAW-^UopZ@LHPIzbl!8kd+TlK#*=k)Ne>8A
zAz*w`BDP1L+IfC`5h^i*^Xut(124d+&57UBf?c42>9<2<pt2O-_l@kJ+f;(*TX#)F
zsU&VRcml(rON&REyH%WPPkD8xFf*@r44pIk0h-9Bf8foayx!a}&PR&LVs9d&WQ!Y+
zjpBpAbMS4Oi7<>zf{)?e`U{vcUQC9!PUZ+kyLQzlWo@dF_cbtvlVHZ+4Hb4&T%JRj
zXQ>Z{oZ4{n4SSBas^T*;c+*u?Q{5vcf^`Yfr-a}aK-F!AymzCvNX@YpQ&f<Y=S6A0
zChIoZHr{qK`ITCCGmxTi_P7%m7Po>KbZG2}^hX0=5GLt;r9Dcm6D2>2OS#dp73D-^
z|7ek<=(YFod8$9m+B_$gV;#%BEP2vWjSiml`BA7Eb$mOr!9h~;S!xW~s?i7X;Ha+9
zk+1J;egQw$0q2?x*W0s35h@s@o=V^^O;BzHux>=d=rYSF3_YtT2Y&S)|DmRnwV&4^
zVtD4zt}1P!nJY4+BhI&O)*2K7<`KeqapBp_NkZX^#9WN3j!WLw)<EQ$Z{?5G!Itvu
zSqYDZOnU5<8*&+48$3v}m#FjMBU{?Clu(vRAHTB6M8$`EAc)39_m#HK^!t)T+d##i
zww4Qq@G0i9TzV_YQM0J#+TLC9v_9O^+63QwRI3d@6#8+fXP=f91e=3q?Zt^ES+I-9
z;F@S4g4M_bU%3en@%9+nz^Rspafn-!b&y#gQZS<za&dy;P>X`vxo!bMJ&;g^9ikp5
zAHxYSRf5bC8LdLmo?5jk)0VIp@kXQUJcBOG_!0*<A>JtbfN>FGG#;X^DKD-#h0&1<
zNO8?64E?ox>s9cWnYW0I3D@h)=U_nTI7LkLF!M_0Bfb*cFrP~Ndh;3Ulh0YMeAp<c
z9i3HQW~Fb!9fuaVYxGMqli$i3Jv+WeWsGccdWPSGv3)J>LXAT?&PF+;MkNkzq(<km
zNpwlaC6u(EPf4c&+CDXUh|XNxE1u?rE6dq7%^Hm)<a47>K0RFd=o(c;s;TaYO|x6M
z5h&;Lo7MQb-Z9TAwb6hQa$6dmIS;?bmf#a>B4|YPqhJQTHFm}FgqFx9=C)pdTy1W#
zn_qz3C^2+KBXmYg2BoWJZ8CxcQbnzm^VV3;#Ob!{6LGrRbXTqJZSZ1!!HtbN+MPbp
zzMkeplS-nIUWSFxGy1yghlMJrRkPj(7u3*6@daBc1yey#*doGdwY#vVh(NWy*We)v
zI|+#hs3an81XL0OH&P7@$s%}l=mMX@?CdH`Y@ACp5yN6S2I{N%IR(h}g*?PrQ92XJ
zQ647bc#=<!kHYh0uq-tP-yLZ+k#r4tZ~Sd{4aodXoxLVjA8ZbIz@~DX^7*88G`v`I
z^)TVMAQV4%s%&5^P|fRI@HmthX7J!8vfL{#_PQ9QDXd}heG9!5S09B)|01UUqWY-7
zT_Z3h%*`zAID;!Au;xdlx>Vyiw<oIcY4GD2Kyj}smkH(2r(G+T;_P96D^m^Scn3)9
z9;^a`r+XH1-~cU($zlvBle$%&kAhnH5*#9kuRK&xdy~w&Abh><+H2Nzgro5pCTc%}
z72hE?-}9(uU5BcI`au7y`LT(v65vV+z?E}girXO=dQjQNqMqaXCe~4~!!T~#Chl>U
zZpPB+r!yh7u!dgnQMsY;4VoH??dOUh{D2aZVO8`ye4=-7Mc0vwb?{oB;IF|`U~<#J
zl?_z0F0Ww5KEjbgTBJJZ{8hy*S=UueB|HPYaryTcvmKPlR5CETGX9F-<9Nj~Z{j1x
z;ch8v_S>cbgZqNoyL9Wb%#u608Rqn(c#Mp-#7$pdy{QOn-M*!+X&j(jA9#HM!D0+3
zyA)=ohe<u8lbR!08T(0jR58Tp@!I$^9=z^SZuFTgA!g|#@KlJF!dEWAr~_jwJ+W10
zbwyh@t7U=65Iu3OnyJ!d(EYp=V{e`Je4Y0^{;KNIJ+-c}Za*aI(Y6>~I_+j>f7MpV
z{x6cCYA0zVpt)d1y?JW7tp@V|y5VZh5vr1J_>by98YNV%*aW6gNl<81rw3=d-pWOw
zc;PlKtKd%Zkurv6Y92zXz);8vxT$8NZ&`=jHuf!PdXR+e65!}Hs5o-8btQ&1HnCO(
znh(aJd+;nf?c6GS3PG>#Z|Z6|=^&eXHQau3opK?g1a$)0J#ZJ8wzRG}$E<8>{s@B}
ze8Bke8$@TX6}SZM!5zUcj$|OJUk!D7;+U<cZ_@RBjK)e3OeT?wd4UH-{2d1AC@6BJ
z%CT=)2m;SxBAC({J&9Y`ss;jV4`~?*ynZ()0`Et-0gSNC2U0>)@E<0~inx6d@zGCI
zL?$xzZYPnU4R!1`qJ;xKGP}lJt#Hz_lX@Lh%R-h>zA}y}AI2g2Y7r&VALtUY$dmpo
zmHulVn)JuJ(ytFZQO|BCk5+09Lo)gJvF4ljc$7BJ<pehsMmi@h@>e2>abB+Cdxn^p
zJhC49LTPxN6TBFuk!gc6(_hL^c&iUkIePCZc@TM(Bc#~1QyCjKA;L(K!VQ^!6n=#y
z7=s~L&C{BlYIb4kaCkQC=2G%d!mYG~ik(@<Axc=G3+EcFpZ`xs!nw>3!bmJF3`ff%
zjJ(vsJnJt^Bm6c-7;<5mRsT6^idXT&)1%SnwXP9Hdm3S$h{&W%m^AvR`SQdrVr60x
zuUO+0k<^VU9*u%XBS?C<kw%cDaN`=AJM_&)nB-sXCfIbQ+|5oST=AKbu+b|aI#`j`
z)d*|<;Yipdp`9Lr!f=2sjUX>^Lt*~zFU(+<Fp?9x(vAf)rWqloRrgrD=-r>IWNTzu
zO?7cjgetd%OXco&nV&-&o>eMWfm&1xHd{tH#WjrsM`Po_5%>tkdy)?u=!pxJ7q86P
z@pv2|_boU{m0VHPpm5K~kw(A{Rh<phiZpk)q}kph&2lBptEe$0&H294)CVmtQd4Vr
zW(MBDO?}{&%g7G+9GdZo2s_}QmF~J25Rh2qw-+&U7t{JbD8O}fBG-DCT$laD(a50<
zT+<HX+t-%strHV#3CRXZC>IgHeHl62499Ev6rJR~DHo=oyW!J8fv>QXO>%zTm2=RO
z^G7P@#`jH)oRXL`Xe97gu8Px{`7~D-I<-Y<Cme@ElMj`k%R)WTo~~$6xRrJb-yc%|
zUyUd9gYb<8z$_WtTMN*eY_v|&SS9~EuigG<%g4Vw3~PalWRUJyVwl*rD$bPQUnlsP
zigIHC{=gc*U#{^O22fUx0B|cXSb$2BTWW|w;XzD1fWbNut;Ml@8EFR$B;`!>GV4ch
zA?%(VtnEev+(M!Vk99dhekJP6SIq2pi2WH;A897beVWOyJZ5zfhH?;+D}JtoKF+pE
zFuth|Y+V!N0_u@9`)!4*mPoKZuo*6}OlD+NF6Ptrn->*p@B<dGK5!H6DEBy)FWwr2
z#<4q-V&U5KUd0GH5)X@L6wX5cs^(n$;-ExuuqZQZ!m{yV6HcPZ%cwb#{gNe!?%{*C
z9kLVi1Lb-JrmX4qVtXObPdX5Lr&U)aMwsi0(EKBoHzGp{XogymZuNohr<t!*5)C1R
zhLE5k1T=s()j6Q|P2AD?!>OuOamKQoDkQC1u3EMEW~Q$yz~YfJ%DUuS>lBxmd&Y~Y
zO!jZ#k1$1}MKl*uvWKI=F%{RWQvPyXcW~*$XvxCjQ?YCc)gGoW;hd@+t$BY^;#KfT
zg$7-P7VjrCMSY+XN{a(K0xeU6QbhPyBNc4xu)SbMu0#3AOj-^vLS5~fWg+RzRScAN
zE<@?>i6dZ7bPX!jvQRN2HFrn0;bn~&@3e$>4?Ox;z-zE7-o##ZLF<Dz@kPfb9yvBM
za0PBK@3|~64HpvA)JT1Bx;tPMZ|Vb6_%kSQ27V?&5d$alex}?5;M?O){8oXj`5fvT
zmd>_|D#Xk{fjnlh>w{n4&8YdhM%=Z4!YaV4k4ST9A<Ce>td6*Gm4SOgZDv?b%4N1A
zXNHSSp7qQ}s@<NLT7+*f;8~OP^*GfrhOH+*LalXF)urZI>_9Ksf#x8P(YQq`bQ%xZ
zuP<a8fJr43XeZDfbHy=b&(1-}jpKJ8j&(nB=AXH$W?VQbhWok!jSEXqeP7=jj>0w7
zQux@(o72c2Cd>%FsKZMfsDQndPvL?LG8MmgGC#NZK3ov^Q~68QWP{+3T3(GD@};>-
z)no8<=>)D)s+N2Bh`~w4h*8qg^xaBC--D;^>_K=Hg?DNa{b6$EVX5;_Qp9o(ypHV1
z6jUUwbVd-B!>+McW6YJCxNDvrcS^Q^V&<DgmQc86&9`Q?DdrMMIS+p-QdxIcKy6LJ
zx&ytnrw6M{lXzaFkL#{Oq&v8;C^y3IBNla(uZtqtoLHx2dA&hJAica4ODLT7##xc;
z5FBhW=VGX;IxBLGJW=irHvKs3MGOWwXC20y9OdceH)<3wqm}6+f!$ryb;4F`bh*_o
zQsX%%xw3JwvKHwS)D$9$>{3+27OO#y{|9S9^nA2F7BVpBCGd`Lz97Uw5d8|)0=V!%
z=bO<c2>}{qv3y8YR;1HMd{{Dd>Z}TD5^RKeu?(#9ajDi>O3d(B<kfLeKStaAm2mwF
z;juUd8pi-!+l_?ADykfYPx?dy{o!<xFLRPnKwMwK=$X+t`486iNYUPRKp)Zw`gNkg
z=&S6bxzr~b%w=RT&!WNYa6PnPN2I=pd+xC4p!p;$=30G%Y^fVLGr#!`nRzBhqhJ-%
zzilB$EZ%mOqO^*owRy7<7uh&7v?aXZQ^ul^@H*T$qI9ll^@~q;b-hxx|K`#<DC8Q(
z#MuSYPr>~L>G72Pbfg_DzOiSarmdBBf~%25r>oI6xvKV{jkXex*<&=}7tXsz{1BY%
z&bZ(s7sYLU6&|yK$JLA}K!w9tbO3IZ+18GwIz?+jnVd&{3nEz!*b<1fbJb#ZR@Cfw
z6RyPWyapG5c!jb%OJId!=HPqDG_VuyjIG10rt-0#5OCa)ctP1wUXYiPUs@L0Q-OzK
zfHpFw78c)3r+0Eb9?969&+Bm0QuxdnVvJ5<&9EAjG3uK*?aY;luo-rm0~;|$i(XNI
zh_mozi4nGPMZl?A=R+lsc_Z@1*)@0J2g32r@LECb?1YCMFr9Bp972R-5<e3!u`)BS
zgaK>J%ot764_|hKzUI<6p;ep{-EoemUa&r`ewelv6E|`&tCi1;mfh{2`IfGPtRMeq
z+|sCv(*tZXop8sKWei0h(UUqMR_V;yj&wsCMs+}pXyK5Tj1S_SL!FY@Nxk=_vVF>h
zU+I^sqLE*wjC>qe$`uBrR3SdV{8$O-@mQ7H9;-`S(yYJIEzN04ng>=GX%2TuqkJn6
z0W)KR0uSFD%$bl-V<R+n>=_wV^=n+dX6uDxT{SiUt8EO*v3u>liCbFt%KI*82h`|R
z?)T6F8A@<OXZk9aZujA&7zTXYZ}d;j7DJWHpn`{Aa#w%s5LciX5Gy{=?Fhs%b67?w
zy<y(A6kc&GMkqDbK(>dF%go&Rz>J6*flS7)uJ(c%gfUF@Yj4843F5DWL5=!?y^lw>
zSFMUS_F&=+-kGEa=T4NVX+>fJMRSa+8bQcjx!?fC(I!t|XGwsCRe8z1@!<VVUK&<J
zM!`<*xIg@vnFl)Z*`UB$+{w`6Lq47<_pH#c^}}jye%r0Z$ME<84EYmb2bmnqQ#97@
zOC+uYLeo@+JF**QKTq@CdX2sXJ07HfyF!&IZj5j*0_rNRf{7>vou!xWIHMS$5Iu@P
zQWf?n#Z+xQJcQvQ2QXDfyRKyvrA!xb8@>RIG(7OeEVq*I2s5bc%omK36#v1kvc>?4
zY-*HIHa%80hiO8I@aTG!=M?oP#b!OaJf{#NaNv#Ff0^rIw!=MwJf{T7u?4y95U(J_
z13jnT&S4viGT5F|^-i^+<2hx{4G1k&@Up84UaNOk!OJS=OP@DY&?hlx!si@jT(jTl
z_)#O*Q6dQ;LN~G0IW7ao%42EQ;2>W6j$CI3w$tG_?xSsxEpy&IRN8p`KTrc0<d)X#
zH|Toc4inNemFfd~;I5@<P@ovUk*@WDBHqJ=)C0e<%7Vw`0s77ku@jdDw!*_)YqGdk
ztJsB~wbbE*rFCv)=s~@X7G8(|YGS3wL5><O4LpAxgjg1MfIs->GZ<_|eWN^;@PVFd
zTzsA70LA9>kTvXpl3e&iPK65229tk(E%k@PtD61R;yMQtRvbPtbFLc+tY!f44#Jd?
z70T=`Fa$f6!+H`Ik0k-CbH&Q`uZe|(>(ZT?>X*RIfYnN6g%KRW+&Hd7hAN+V&8ZsW
z?);$KRUe3)qvl9L?v+$n1FsXMT`m%ri^N@3R^&+$S(!j0a&s6xqGW<j?V?-JnuTi*
zx997x(vr~Tnl>p>suA&0p$=b!F(-uw3_7FI<kLJd`W#4MP|$&BzsmnU?YKro{0f$G
zi&8>4MMfkn(Gtd;Cv%aj8a8(s#zPwpr?DC>T=I;;ZAHjwC**+hWCmH=VI^(C_na6L
z!{*Bn6A6TwLo~Preysj5jhnAwRRzu*Yrq<4o`xr=-oHaJW&?qL#2PoYV5xF60A}iz
z<wDmelbfYxIRI9LRShNxDi{Tz;U?F!SHc=0I63kTV_>!GTip&i;O4t&+*M)-FQ92D
zyz2z4mAV-@e>D=OMosI^K52zICIo?(MHy^?{%4_V%F8krr4C2AVP?=69J7<p+p##|
zyk=4!Fus?0kgFf`st@dq$g=n^a)f!?LA{Oa2N-X@O2L?re&E7HNM8uc*^G)%=(Eun
z!V|F$T-~Dmy6^*BbR=p6-%y1>ZG<u!aS-fYJ2vj$n(exG&c|_v^E?O;4P2)E`DMyg
z!$;*g5p8}s&s=VQhzZ)Xzi9O`Zh`zFK1M0e8Y-Y7Q9Z6*#Kmm>Vy=$4cC8-Vp%<8i
z@I$3O01}u#jIkvUDN8NKBZfRH#)n3W&<FfUr4hWf5`+D4@stj+BenG4P+?BEf9i)9
z!%|TtkgerlCwhgr_f@?>F(iD2yr>`EV<vrBT&+jhPdr+_S5*XP`W{o8fU~wfaQv03
z9=R*Gud0G+A1cGX2yM7Gj80*4j)00d0zzq83a<}y{F6#VaoxC^x(92eC`bI3EUfq~
z@taeh=jXOG@>Me0xE#OJL?ID#VE{}Lu}dy+S;hmVIqER9;Uh(DpFCx#ZN^|nGgJbD
ztOH@TCr}$>g4*swOi<e@TENlZ-T1MNgD0<f1<HbU`*wf9oJ=nU>tw2t%^G3><-;BN
zbbVwM3QX7;q6=?v)VhQ;z@Ef;BFr6o9`(PUp0zAf#8_r`(?|%T{MucRy`ayKBUWV0
zGOH}@1ynWb0+TQF1XCXa7>8#|^6Aw@vzFBl?>X(Cvi0aRWX*x|%waF&CyQ1hakv;M
zdE}Dj=_s0{AZwN*!*yz0dkm5ntx-#fk(@R>$Yr;}-$2;eUISF|{qV#YE+bT3!T;_P
ze2Oc0bE9^$qQJr3W)ae1F&lXQ0~WgBz5-dicZ75bze0DOu^P+NzsCr0Yf7nT7!g>i
z!BvXd90Je`QJV7ci>iWI*_%#rDtl<dHsa7OT>OO5loLyxdRGYywt5Wn(G<pnrc6gn
zXv#4>sxBIwgp91daCgJq!g*wBYqe76kS%0L3mJlt!w_JY5;CMuyQ7e!C%c8*RteeN
z7V`0ZJVGLY!PW#&d4f7KCWL%%kqG$!t05YElS0;EX%&S0jv8g=wS;y!OjjrLg|(c7
z<_O3+Ldm((Rhf%jhUL(Po=VR1keeC_Z0?m42@JMgJkUo@#)O=ED>*k&a-Kms*T77L
zoJT?`So#Cm^C`Y?eUK5d@f(UVM~4Zs67^k1IE<&F1f=rn;q@b$sB=%3&?zIIZ8R#6
z&`G0^4xY|Wh?1|OfJMfkftQrzRCV`0$>*qR6s&Vf#_KYD-JxpB`oNKY(pC;$?1L99
zS8j7(T+tgunaMHL=tZHmp>pj;0zVDKy*EGw0#vvH;9i`ANJ9-{25L*b%x+Z~2nn71
zDwcf4s^6vvra$GO4#T0*vst4d>$>GQ0}zis91i9K@4|B=-94^PKF`rOGjQAWFh|W&
z_x~n8_s}HnG;maTT>pLKGAH{9E^~Hh!&0S4J1;Pb^xObP5?~4jz#wb-0X~Yvm{6p(
zk5khNe}aPw3jYa)=GF}`j+@s27Rfv6(=c5LF++%Q&0{!17JD3q$-Ul_TS{~hVk_ZQ
zqtfv9(E4GGC8idiWrld=?#Wo$c271-CjnR^7^!ZdPn7wtC?-OMi7?+M!X@qqzu-70
z85m9b!}R5NC;wnEt2?PvVS?&mkGJp<pHNQ#sn{MjnDk8i9x#H|oWUL%W+H002+qNk
zys!5)8%^}(_I!Ha+fkUW%j?a!Gr>Vvz3La!ZK{T$5PkO6I#OnhKxZdIf-@<0ne`{_
z_?Ff#;h^FGOk}G?QM5vrkh67L-apZ4{-F&cId>5)ta#L*xTVBF0!vqd4DiLKo)F+D
zcyCZMtzAi{%Uez??*mLDu?jWcwx$Wfb8@IeO%9bPZw{O`{h&A%Es?G0;OK`yoe^2w
z8p^>zf<!U{QIt}I#0Zt8oA9(#x|gfmrQ226*wY^|rQ5+(I+ef>>wVbW37s-yLPx`h
ziRyWXIYfh<@nd~`6vjh=y-tKfZY-o50+DELUk2@;T_5O<=a7zeO+^d#&+W%j%cg}$
zmt}$B)8Vm0_}G?wZ0{}#?2YHk0(;>v|MA_-z={)sO!r+hH69E>#kcBIR2yy?U%2r-
zA4}KV_@2vqUz9r8xZ;aaP&@da!!o~(m1wz7k9Up7asQU*UIR#`$I944FGb}LlUOIX
zW*sKGFo4wzhbLB^nvqdw4!r!FnKA9JVjv`$Y!}VvHu<T^zYkH%HvgR}xW_bJzOzoI
z$(n3ZR0qD78GQ<Br)yk_SGiKOH$Fl?^Q}jK!3@;Mso=OPXML*2=;oFJZbK>JM>osR
zO>*EAR(<Q9pb%v3KaNkd->Wee>>VN`c~N05#OcW=mF9`qD_#>dt<&#x^j@Y8e>dK(
zwUe>30ZO<0L8G-}_i$PViUp@%$SQ`#kf61U39Y>vF_A#W=R|9N1h-lHaU7*)Gn-%0
z1(Jb?ZLPT=RcbdFdeeOC&3=fB8ii#iV?<zZR`01yM9*KMl2FaN>*X&sYdSHsEM~1k
zsQiiWt~i^3!fF$5m}6`vh$T!-X7z=FDpF^>FqWrv4e!pr9?4bkU5L#HW3!2C&+w*#
zZz}l)L#=146S}N8#Qd_ijz7(X$7yS&C>XuWL6LHJTA<#7gi@oRe5#ktX}V7foJmU@
z;H+_3ghLyCQYP6o_Z#5!-z^?EgRRe@0|~%kOaSM2!~}4TW)9KdR`{{<;9SPo<_FL=
z0X|nsfn}z;vGI*IJ{sQ{>L7TMj!Fi*XqC7j?!GR`clJpBvy%L+`;6q(yLu$Y7<sU@
zx1Z#U3CV9mOh`VbQ6zr_Kh~kJj3GJ4w3M7Rt)VED4&)?*BHt@Ovuq$+0kj|xe{`b>
zI+2KI1^%cLV$FO%@sA3?E*Di%STiwkAS+(4nc$fcTpl$azg!+Q55HRLXwdw7kW#r2
z2j`)jD*6I1VuHws9(A><K(E%dMf&cQ@J`SRy`mekjbjvu%t4@18r^9aoiP-@=u;LH
z%j(z>D1DNA)Ew_PIHC#TUsu1{tG!9|Q@~)5U9~sbq6tMs<)H&nA5UfbG)VpEj~U`Q
z+spdLo*1qiObZh6`6Q>R8yjOTU*_&2@Y`80j^Q(Rw;iGisfXU4yYMN~bIZyd2?A-@
zc^^uTCnYm03RUO5^L~!5SY7)Y^#=Cu!9p3fCSYV*nu}hWtoctG^LT(Qht6a_|4f!(
zW45snSX=^E(-|*G;u_8w(%JosRiRkGEyg+p9NKWS>Ia{lXGr0+K8_5k9~^8Ip>s;0
zGsXldT#lF^g-4#`PjDDAvi62U85J{I{9cQtS#u&nXKX)eD_gpCbT-x{`Eh5tB|k<<
z-r1J?p57kGh0eyn4oZ-mF(LWNzl!AFGlyuf10}y0qYp^_2I$Q0o&lnKs}v-!SOJS?
z;82>&f~du`@FVFx9j3`N14@&j!Ognhe8v%aQJpd0D+UzcYX%fL!5>9iVZ(r$Ote-w
z3|OJq2X)H21p`L*axq{K1t9}A;T<)s5x+JAR#+C;l2{k(7rq284tpCxY;p=aB&d{A
zOJ$RwJVgpZ#E=@i>LtNyrd92zhE0O+!)u}5ArjWU<WolsKBhtlwfsw-=yjv9t_;I>
z#+G53>UeLOgaTOeFii3`-<<$8Gs9u*8}~`HhvR+uUC+c<=0tYERN1mdxCL6m-$h_A
z4o3GlVM}WbY-_t$exB{cp=(a07u#>Dw4WR$!jsHzg<DuKsZChC6+8kWVi>c-EqIW|
zDDF!Te>MW(vY6NqEZ|1Em8p0kPG1gAN{G!0s{jnkh#+gb&zDK{5-#E>ov<5GQp&J!
z5QA-H;U4aJ%7<CBH{exk2lNIEiDa@nVop-O9B);qLee~83DG^Va8NvZ<kcTehNL4e
z)#^#o7ez#>s3q2~<OE~02sMZ*G`lC6mDomQR&Vsm$SSRyM)H$MQJ1~0C%{8Fk=`D>
zgou~$gaT_m*w)}Bb{J&}OPk9erI_0}D_Hh&$b<4@YS#J)181ogwrdf-G{pDv(G={X
zvBtAv@SrG7?Idc3z139v36MGPfqVr|A?uvqOFbky@^n&3%I|g$ryYyTy<2sA?7T;w
z=I#PZXnI5oJN?CU-gj^3=>jo`EwxUAm7mZBGA6pf6?3Hv9K#%<!F}*!RfCsd2%pW0
zth{exfwhywS0;7rSPscc2@AN5))nd5U(v-7d~L;C^F9@CiBJNkn)QWkR{E5j3TxY!
zRYTDse>%)4HcM%?wa95lw||pa9!!x@vT#e)wu%BG*vG>uf$7hPSC)du@*$L<3BN^n
z(i;s9CliCM$Jx7_Ik<=8^_nDJ4kv%7{V9nC5#5Rae>djBrDIrx2St{vO>h;8?ZjHC
z76}OUaRf6A0Dj;Ix8>Fe`?e}`h>?I_&3jwIXM^-gkz9#YhV@RdV<1#X%cPz0wUQE?
z!<lml3^o?{bU;c^l;!aAYCEC5VmqsM!wI+Q{M;$sC}GG>aC7jzthK4}adA79<8$Ts
zo7^oYDvz&X>O7cviS^|YASqo2?o={Ty4~+^l<ps=xRtKE@@8Lsi&46M+r%qf$odQh
zM}pEZCX}umF`>27?h&PX8i!L@9oa2u&(SJWzU>nO(ym4&&$b4<fzqPf71pDuT(~jl
zls@-1N639WLhhu5{Pboc<gDL0LaKDGYSfx2DoB6+c}-@(!o<IXV5%p;yz$BEn!V1@
zhFw(Rv+cz9@+3}$)?4C2kpB{P6>Pd+PRo6Oq#rr@=jng22O6CnDw;IbucxLl=~zoi
zW4Vx*Cyok-VRIY@_~0-x49cwIUQjhxg2;dAt4ddb(xvSUmoInl?U6^IncRMwyOYx&
zHa|jqKv`iw6++{xRcqcrHHE~+-NLf5){~k|G?i2dm7kG?L|V3`bOFg30nlviv6Q}p
zEuO{JkM|$zt#S5PxsYQp4oY$+c19DYU2E|!y|^eP`_^?Qx<P&rD==C(c)rn~L$`J`
z2vvf$7W-SBcJxtm#)O*ZA|?{JTz-NRkdf6B{^SO3h-}`BDg;p*af1V6_rf@h_A7^k
zOVt||q9t-}c$z8?OzKOpv0s-icjB?u(_5+r8pnt-4#Th#oyfQevW8HsxN0?IGH+2(
zG_l^>)zU~ptzPsqGNQZUa5lIRsdXzr-f-34q7&S;H;jp5-uVGjdtC}WwTBfT`&-YW
zGfp5$#zgHsgP2HQ1apW6&tdJo4_iys-U@maOgT^}^o`DOM-_H`;0-hux~uj;i*Z|_
zH}fJC;&BIUNnL)yQ(yyxE|-ToL?s#-3o_+oAAIt?i7<hs!WqGd9b$h~R|PXhBx$;W
z+NrDqck_*Rn(qv&;}&c_GyHM2pn5bxHa|%cX7no?j_sy217BBbsz-K%PU0L;G;k(s
z601M(<&flSKv1@kDB4Ih**S($@Q7ORLAknC)PEGq6fNvyd%p*6<!M(Wu)p<XFShHB
z3<@1A!f(#dg^Y=IjVT{;M4aHkpYUUC0++Mw6>k0pVN4yh6x4piTUP}Z)bcy=Y$G(Q
z-hrkDX;{jKLnv4`1vL-guXR^}s$C8alSJ^Qpk2tS+9ejMeGX#B_Gndn9ojD}GNN9G
zqr-A@IpAfgb|bxs-VsiqjoWyV_u-kmiSHlqxd<^E*|7mMv>O+GpVn?1Gp1nsTC@@x
zZTDBcUD7Git>E$8ee*h39T{#}Qrj3g7|*KK4u4{*{x^J4%g^fH8PUAXeOho7;ePAz
z=K^>Ta>IiW@$W}OyL1hIw=!I_B!Bo$ONP&QCi41##%IFYHim1Oax?Y$yX1q1;=8xP
z_rRlx1=eF`U)~k$Rr_k>lzE-1z8>D7#hNnwiJV;dH!WP>_3-*8`r}4)d?EbZtHTGp
zGJL1kB38J*Y#rhqRr_t^58);M?uzR{xZX=&?||#>>T&1VZ>tsp%=s<P@bAy^_b2)L
zqx@Yje}9m_-^<^1nHJD)a@VM-M}1(=ea)Jd;_p`0cj?VtIB3&iG;YyOuhhS=*^-%o
z&InVV=eM?+iE=+wec+QpdP@eD+ed?qFvP7U^zPPFOec`{ib(G8B6MEJ&f2;aBjEbL
zLlOyRzeRRm*d32s3NQH`H`zowEoAMl*mbC^sb5r>lM|AoGp#YOebm+2FyLSy`p=2m
zg{6GP&%ib3fzL`k->bo@-FNXs8EFH!g|vR9^@f`1PvU{_rgy71J)iHX)-g4F|AyJr
z_zd1WR;wsf$a-yiRcpmI+pAUE&gZ&Wo4FAj55z774OYY=$at>k(E4sqhi7(cimk|~
zeyZ64OqEtx(p`ORj(7IAvSIjgRRU~waS(-D3U6mHv~7rOi_!N`N?VFJBxdDP!|4(<
z^rhniPfz7LqJfT#5NRY#xyuGT-%>b=snujY8*bVIRR>Y<eGVRQjgznFrMeyiJ4%e&
z;lTSTx|T#1c{{WRZdrlwi!!ckX-x|$l^??AD-|^POEZ*M!!c#zY3I22TPWN*;BvjE
zw~%|(U~Q6C?}9@lmQT@OXZeFi@NJ)JA>T9N9;QdTvSdgj9L?jGww>Hu`e1#_xr!vA
z91Rjzqalssup6l{KvV?o+#7%%@GK3k`FH{|cO`yWB3%F@URi^n<7|G^D^CMrAI;N%
z)akzJ*~&cijDb|U=(o6m?CN+C>jZvl0_bUC#>j3p?L(v^_n=)qtHv_~S&blw%VQtb
zsLNqaOn8J^3V-UhIYaa&<Z=rEIY0sXP(D+Si-e`Bw!=^FoT{x83pKi!bq4c;vS7c{
z<?vL%)L@-t?F1mF?s;YKq3|u*qaYm(zJgV2)|xa#2!4jq8N7>OpXo;F^R44p3NI||
zOv&fg5iAy}sYubbOytWL2%0ptfj-itdXi*3UJd$1RhL*zyCZ49qC~YgT57Ig1<tDx
zCN$}knR%_Ai&D&Fjh47fWi@U6R<T7Ac`Dh8%*-lh1q$HM>NtmRtkSre29`4?GD<6;
zDmKBz2ZC4b4&3dyf#K~Jzd@8K8yA(va?lx&Fc*V?B`B|@uyV)EbDIB(5aIf3MF=!d
z9u^K-uLdCt8tCzzl}vhc6gip^ODQGDmw#|o-lp8kTMGZZ1GX;025*(bR)`aQHNV`>
zRN~F<=FAEKxPcB-7)|KllZD@s;mzR4mCjT}$O-8fz$d{+v9?G)?W!#jXt-mM!0*_o
z_F=q^iItYZHxX(PA7a>#bM$eSOubCD_OGMg*r8Pp4D=$jfq{o9INDh{mXLLmc1INf
zE31z~xNkMd7s*U7!zI;8J2PC^`B_UhRT)61sp(p=RgUrieP(!Oov1rPBuQWVfr*0z
zp(~lifc)A9kZ!-6-9Auk&#}FW>2(GPwNCza=eMKro-Ug@4*d`RN%qU8M%=gT8AEEj
zWnDF1=rC)7=;UNS2_#-N^&|If>k8m*3|yx!kJ`TMszQo^D$M6^nH=6^SL7>j9B3&k
zJtawri`4lWG*l3Y{_VG8&VRT4x=0r+wg11>e(!OtL`7IO^}pGE)jzKPuj=38P3&U+
zZ?)g1nDzJ-+V7pb|E~Tu{-E*lzs8>f;XKb?`x#S&{Ycol^n?yMvw2x&U5ta-NT$3i
zx9&fs19y(V&`#pZNXF0J^p~D!r~d>}bfy2NtfYVU$xix6(MkWwimasnhLe8mICuId
z;YAke=Madg>wm1L{!hw|{1ct@Uo7{?kA_bvzsLVmE-n-~j}mT+3XYgU*1iXI$Wex%
zc?LY`XC?Hch(orLCKU$F^n27Hh1oz<c`Lkx>GMBfXkz{ohpA`&`8Q=X|FaHE%>R=E
zQsrL>n>>5v-_57~KhZMzm%kDoi|pn9wom!5Pg(vZe6}%r`M==T{-IR$KQDv)lZ?N@
z^br(mtCQmgpu3!uS!C_}pY<(6AIjzQIzYctv1%W7zBR2_FpznEhi(32Vt!X~q~4nR
zeEHk?AVGyFI~+~(I1rIZ;<U@xcEB<bO$dSOhPWpaWri?XSZc2$`PaAW?e*_)Z(#Wv
zPM=W|eb(b&p(6*AhvY<IR%6K83e)fO3^Z_5gm;bydgwwXj`_xSZbFWjN2U<b;B~mO
zmSeSwY{+fimA*NYhSPJZG_t8iZLi@oG+NyDn%!NcSvJ^Rnw=0HIh}<p)L{E}-qK(_
z`pI@_tS?n*!gguG*1<a@FAWn%X@aUWQ{*Rj8-A>x;TKlhi%$+momp^r(e%tPd%qD;
zwPAuj9;vM8wQ8+32)NREbBIz8jC1u8Y{UV4we!5(x>Ph|LtHxj3*hzq8&#`v^84dK
z?iSW~twR9S!uvqC&3=t|yl#Te<HqClG|rTmCh*7W?#w+}c(eQjKc0gY?%BN^c)gej
zNmkK7_d)K`XuK{$7OFI7e(foZ2d|}{C*t)wO!FrzjmGOqNF1ekNq&N#vouFwqOF~H
z?OvJ&uYbe`+W65RdQ4kkRK)o>e#zTk0Iy4~cUpMwecUaq@wyrTR104Q)=7rfKYp5s
z*GFWGn37*FX716#wel0(8$Z_B@Y}bUUteTG8n0*k-d!4v*Uku_O0y6e<|>T`uXSq^
z@%r($Y4LjhbyAvM6e1ct06*5P@Kd!DuM5)Q^=^F2?*9#5x4716;TZ$nEv)fci~y>I
z-~7ze!XA6z?tdrZwIe5jQuFJJ*GLNwp%BsF4BT0Z;lge+Ubl6XX2Ae=X*6C>Ko+Vr
zn|e#*!RzYgM7-_|J0)3ZG{63IwUp*uDOB)EmgX}!+S`fOKMYL6uit+4{|K*t(jR!D
zJ+P{uyM;Ags}Vr8@Gf8-7bAJ_`t83G@p=q;_GB&0#9{Gm%iN=dv*ahZYBpN93)Z%^
z8LwlRkmlD;{oJL|c)b@{sL~uC^OVMe*J527xBWT;J$tg!XuKYd#8H~3<R|zKmS%s9
zSK5i!1tn?lx)fjf{C~r*4_)E3aG$;0Ev)g{gaE3AF97Q#!|Nd*C*t)EnUPOv4~%8*
z(ZYA-C)fu+)~GJ+!0QuCNaOXmJ>8|zc>N)2N^_6pDUAoO)gLAD>nfRn@-L0X>n%te
zrP*ASW-pfJip|=M*Y5q(;C1WY8eUg(?2Cc496Tg$0iP42(Tc7El|Go|H0+c;+zorE
zte7d>0Ra?DSAODYSgbiZg9B-Pd&#=(12(K$mZ8Ve`fPx2WoBA`qDc^BoX|rTG7FIF
zQ}xok|B_Y?mLWsyK}<6%a^;d7mT4WzmQ%GIFD<#;l9yk|B{xhr=y38fA{!9orEEYL
zf{fH5igJb%{0T!KN(h5R95}&UHZQuW;ey@W)xeVufxT@YqpF7Ip^+|aMFLJW%=xFP
z2Kr^}YT%9axlFwKR|B&^H7vMXs$mU9i3SI;8s_DjYIqBiv#7WdHI1xmeOH|w9VcP<
z66*MiCgHuc={m>)hXWs4lhAhT6j+Pg`Om5;xb!rZ%{=8fth0J|<s+<q#O$%kgg2PO
zRUb{qw=%f;#9}IVv<AP{+|6bAR0$Wt{9G`jGZWA)gT>>wGbk31Ged5kP+#A1XNnc$
zd^zD_>jEi`_&l_vN+!P6+kmmLqFimPkX=F*G5Oe`lqw-CTDXE48EGXHmdaxFH{RGw
zzu%RqXkDXk{zElj1F~EsM2%wd#tNeb)pvP<cCD^>e|-xYg{Mh6RlOgk){sG2^UfWy
z!=#C_LkLx`^o`+0K34|uT=l9dA)#^)!cqYQEMY9E28bi&>DYu_(Mv-uIa2Laqm7ER
zRLQ4=L@7J#!Zf-I!yD^jU^u=oIjS%tJ%t(9Q3^A%`S=bfhe6W`c*=Zp3ZmoD+_K;n
zM~Mq2DBaS$Tn7Vc^NeYKwRwhj+&nWwBovpdE}z;wQ>ofmmV%5^n`fl-YWv4HyH(ZZ
znQ?Yoc5Q)fDjf1yZhNam+Or>bpQ&`7*5w7exb=Su@eKXH%+`OP)TRG8ufe7N?<x4O
z)ou9j#`+w+ue<5pK2l~u{l8S{KfmS>4c>?!YaXzqXz(p0qOMplmxA5FTaSWWg(m=D
z2^3-u_hYc;CR}3u4(-b>yxM*TEJ>}Z%^Ogy>Irf<IJUgj_MVDZv0h2S>i6!q4l2zG
zHoH|W`bo7)&g9O}mJtM)?Cs@VAL`-=_=r{`yA8`n^h^4m{@2n@;!k6v5~>;4BS+Ud
ziul=1Zbj7g$W=8)5kmm9OA$TxNWt4m5$8ezyCdd}HHHh=Tpa9HL~W1ki7cS<$ITE$
zY{Z?leXdc&wXL*Ao^6*sGT2oO|Ju=A4cZ>Le7dQILEs!$HF)fi{I^s!%yU-*Z>&>b
zStP3lZIA4NEKm()6eSwGht<#neWhZdkNxbC8&|9B<|Bs$d*nj;u1ycJmPCnGSjUjI
zJu-$|Yo4~%9{FN3k3GV(cU*LN7c=zGB|i`1&eSmG6zgA7oGjZTG)i7sL+eQx6V{Z}
zL3G4X9rz_OZUeQ3({w`!>BWb=sVcPrZ|pvWH`ZgQ#Q0u(-#2_rl6%*$S0>3`G)bP*
z1#Y8B0&jtsB-q#CDg--{F*Ao9^>Ye)<RZw%uB8!S?UL}uioKgyl5wk~Bwl-D4b~B%
z#~9gsy4xOk0Z+9(!ZrO3c*jqhU{|>@sK(6ff-je7Gc+>Zjev;QPLw});_=qkB4ZmY
z5}vQ&YS)@2PIF$w8OXL+CD%<=noq0bpS|2HpskYHDTW0GK+|0;;IT?Npe9-GO(>&X
z@4T^&mt|m%LFy($ZI$eREWiSXQj}=0BYvzcvG`B1z(0_Px{~7(Oa&Lz-h&tJN-n6q
z0Z(juLF-sS%`{4JiO82#%Y+I&6=|bM>ap~{1&7SrSO`bE9BQlD`<y$ZDZ9}&`Cl_i
zT;=hzPq;0qh@EtOAed`!OX|uez;PJAYAr%q7s_oHJ6bw;Tep^8O$0^@-@nLcX%t9z
zX{j+;%8;2g>J_D>gsp9|@Wy&XMyR#D8B96h92W|+z}VqpWPzN9QIu#fh#%{0bRtSO
zuLtY1Od%<gxJF8ODMxOLLqwKZh?4{=8s{1*ausjXHtym{&lxRjxzH5vf!967Gp2|X
zZ}Li2ygFoT7mqjA>ln0AU;T>5EKt0gkp+r(x|A|_1%9mPccyp?q$`lYKKG0jAqw`4
zAwd?B^;N+e7M?eiTrD>aVbJik_)Z0@W=#j|%&&4PMqFpZ7)B~aMvpwEd>D=`uMVpP
zb?OXMtBi&w`oVHZUi(c{NwnXDNaB!4vck$Em_T!pveg5fvVAiQGz8&F*i5QzWax!Q
zVLQxOuS(w+ZeB{0#-v!YCKtjN)C$&2BUkMroE9lE<1IUpJ}QwB&C`%b>_od}cw$AQ
z2UoIUbUjN|o$@gt*g#2bQeX8|4Uji0b7C(fZo59DNKJq+QYdTgjl`Qb@rubhj+}4f
z5C^88qKLP<$A7@m(|-^f>XEHV4z83&^oj=;NNj6=xtnWI&rXKhL0;RMP)(rZ9T~eI
zh8<fPBdm$4eeBzW+>lDST5PEs@>L)kr7n;4OC|{3a;!VbZiU-a6l4mI8<B%uff2e;
zr#)MQ+h1r`po<Xy$1c<Gd*Ah4%(hdh?acW7@A^9fw8Bm-bQ7TF_n#w%0Pla<Lx3KB
zpY$TyS36E@0-OqjTCc%;CEgTmc-PNqe!mG>fB;8RlxVOoeymwoiKqDe(suEC$W^>a
z-Q2~~{Jy<iyq8|`6wkx&x4fW=m&ot``968^G`}yNAjO*@r3^lRAM1WBl2OI`>#xc0
zU%y7-+rsa+EJsX3_8mdH>G*xrH=5rc_Y$Y#_bWYImXzPSt3*aLpHF_r>OmK)MGDoJ
zP5MPFD;zgwX5LY)Cif@NMG3igC%J!5ahyI#$o(vbYw^)qMee_g8;mh;4#r|Q?$ae&
z)$iP*T`L`o3@2k-xnCHWr#Lw!vU)cq=*Zalu|Ik<8R$;Sl}Q4nzk)S*Lg{<@=AXdl
ze^KE*e10d!v>W-nZ5>TAKIdE$?DdnrvH5&9pMcMs@Y_mz{qyq_$&t_N3*3aK`Fu|V
zP;-6nJ?|kr!{;lJnRVZDXkTAG?+6_v@E9zKz5e34LU`9wlxXlI{8)>zYQ<}>H%gh*
zS!%p&oxMJeX@YB5y!$qH7f<u~k;q#W?`N#}cMV4jpG)ypJgbVA$mhMGU&)H6`F!m;
zQoP5cl)?A$W4(uEEUI`(?ezv-UlmN9g-^8C=kuxCUS}ND?ya-e=b{TEpRbnWwY{zy
zO55v1676-#%4M%#hOwK?=R+|YX!u-2s7kcgkA=e%OySt;T6nL$E{&YrUhk?Baog)s
zGjaC1R9$j=ol$)3^+&K2PAJ`Due<74+3QNgB=$OUcI<UqHf68NEo$2(p4VP?y+Eg8
z>~)o4BC~f?^4j*glbhJ<{<$TP`;%B=E9CCB*FAzH@cZQ|itzhvA_w;Rv-A{Bdv-2v
zH`?nN(tH|zpZs}y_`N`XpMV7Tw@uvysQLYfGYtX$^o)l9J^a4>?`U6Ne&2~R8L9a_
zRw)GdC~^Y7PsWe+E-1rmuM5o8QWe6lmHa-NX=;97p6@Q6=J)fEx8nC+-r{-q{nMvZ
z@e=uc7_=-|@if18QN>#&Kf#~zWBr6B1!?Sc(J@H=OY-|c=+fH8?+<b%v$5CbVM$&(
zejkIy3&QWlUia|3vDc-Mlk@uyDiOE6E;J_muI+WHx8(LZ!~2l?GE9#OxqIw&H@S<w
zuH;K<uQPAQUbjUv_PP@7TIsDl_PSSQvDZ~jiLBmB32NKxPA1x3Psk*J(%->Mm{7WH
zuY2-O;Pbz!@E$(@4;_>n`8-1=SHY9<Ih|Rs*Y9t(`MeGOmjgySg!fKIH{oeMpK_WZ
zyuKhcmqBazoQ@Ui$AxHLUp_yEtNy{~Df}<nA`AFmK9Zl{{rIuEU>%UxUZ-~wr$KW#
zqI|eq?vmEO-pDjHpa0mwT|CX_x1DN=cf^yP;u$`d;%%pkm&oT4EXYk(Jk94rkOhht
zP{rGm#p}Dq6fdd0E`9{V=i-{hO_u%ZUp!6W+v0y&#CdbW=T~ET)bP1#n?!qkF6v46
zygmN)6ICK^dtGWK&R&<QOKz_-iVvm#jOG49=^lH%gi5ByL>riY{RkzmZLixkk&%Br
zU!{_Xe|;5fEmV}pAJdKg*Ny)5UxMFPeApg-KSh7lfcE<OpEeaTRL5Lve!ul3Lx6`j
zcnHwL?>!$y`}*?xgb&FfDfxXcvH$_*QIu$K1@5dp-Z2E&KL7d}Caw9sr>A(D-~T?!
z6z|*xp5l4<eZNOk@e=v{T234#DW2x{QOE+t>m#KM9>L-rj)}`O_WFN=->+Fr;oHLR
zvew@4`^`}9bo~A?dQahZW3OxC%*ek!S0&=M*KJm7pMU)jm2z3L$6j}n`v&4)zXeT(
zdbI6zyZlwH_OG9yk|>Ya_PSurjB${<cfNEt72d<=!{~qA$mdz(b1a9M1N)WMD_0k`
z(wTmHxx;SzuXB_4=A6Zf7XI@%!)~)5_OKhsTaFcJL|)b@50Kq3^R8z`@wFvu@q3Eb
z7(fvy%;_TB;4=nH9P2`AkvQ^rk3vL)TjR&7f}2+H+6X-@I*(D5S<Z#2>XRgCcLXhT
z73}oy+yyI81<SV!w%{R8!9d$i!7jaD6|CAWShe-xyU7d2#8I%n{ZR^*rwZ1W1-tom
zQ?Ln~5C!2kp)jgqaMP%7WKRhjP<+^Yh$W`10<!E}{92#C-6C8m6Lba9EAY&-0)v6g
z4h~kB{``qtwwTYK@Qyn;p3&u#LreIOpXh+GTc&n!s6%Jf4i57c%`EehB9z*}QEu-Q
zIAR6rQmvJI9jUc`2gjL&g6?J?`^Mc~+o<*`Kh^-T(|k{RnYEIQ$j^G?Z)~sH-cxa7
zua)GD)fe^vYrPRS@o;1oXti%fN~;|qjTd|qKh`Ih_*HOx67iZJ#UEAgvt)@Rluhcj
zp!Uy977LT*7S&u(TZboPLbH#9ZzfE%j=E1Fs=|JUhLyUt_i<FH%CDf9m9cG;1msKi
zD`^iIlW<c;rQIY?pl@Y3kSz&f<1URv%JuVqw2e=XKE{FZXJ5Httoih+qYaEhP(81+
z!=asmdlX3Ae0nyQvnK(t=F@>l9DEw35YgaL+*y6#7E=Ho*)Bdk(^arSPr)>wHXLON
zb_NjcDwu~)e?LzZ%+06QaHOB4V46=)MB*seqf)-$do0)ptkqEkySROPddWK;KD`z?
z61V7qnq^j?i+-yW=tkAm3UuCa1^W5Agc&m`X;rO27fp7rKwr14jjXyAD@?QMDPOqZ
zs9Ci`nQ66$?)9{qhgGNE%~tbc)i*h-nxySCtKN2`wB0)71W-;xOIowhOQ^Q{J8G@@
zas1J&`ZrwCgps-}sJ)rD9#*{^Pi)r1Qbq=xP;IRj2{AWeziS7payepU{L*u26!+5e
z)0S@J)kG@wePYfZ$L?8nM1lM~G%G%q_V8nR-$+%bh8$>dY-@h7g+c14<{*qrgN48Q
z5{K@&KWCAUN3!&fcBhX%K33$P{(x6oo0G~qS$-eDhao$9syazAV))pYr@$9rkeIG8
z$Rb(#)6=Ejy>;m)9^GCZ7JbCl&P&J_A=fRe!ODq!!u7Q2FSwmVfD;H7@k_RRR%*SD
zRk-~do7cz#r8tUmQ1l9?t(U?9qUvVLFusmj%=W#Y)BIfhO$3=%lt!odSuAg&NOI^x
zu7rbe*7#xPoJGKh<XUV^fUkuIK}Pvyi1NpABUcr6E?eUZlto}1zJLC&%p3Qy{n#Kz
zDy#$t(weOEuuMojM}ctuWF2Kg^c`|l^viYh9nf^GIbJmZpXnZ?YL5fF?QsCB$8L{*
z%}s2NVd(ME9v`~f1O1Bh0<OZN+ygM8YfqE({lL>CYoKj*lRQUvo>cw{46jr!?k4#?
z2s=fSyo(+$Rg-*omx}(&G>PYY+)BzZuBL%s3dpVM#seLzl{P#HA)4zrJW(O|VSt=T
zY88G>1Mf!5wxqOMP`WfZ-E@QH?xx>ErZ9ZgA8NYk&UbjaX^g@vB=>NAINw@*tAd03
zJfXc`QZ+eFK6NB0aK_<G9=dfil1DCuYo&{xvJ74Hr*O{zMfYkHq5M3!J-6y?$*n##
z5Gf6jYkYob5H?ouGp_q!(HWkHltib=mlCj%4>bbv2uEvkr?NN*QHBcRK9!<j^6f|-
z>xxMFq|9+v3DSx6k3l)PpCLY-`dPVkNXL4BOO^|sYGmrz^PW3D7y4QGYm9GNiI<Bp
zIL!)P-hIx&OWh|vczH2w@bWeo!exwm@iOn`M7#vJ?pf-+K9sLmBLOdGBYEJZ>V3h>
z5s=1u5^Gg5#>-0B%Gton$FN<~<7G<IZwxR0Mx8d#%mTmM_l$#=@{fG*a?>FOFZY5%
zlH#TM&xv?hr9015{4xZ|122J(1TVcHjTK!YcoBP_XfynBj$qHjFAGBZVr_~L%*W_r
zG6l>6SOD<^bM+Ig0nFjB@HYs8X(hiL&;BSIc$u`s!AtQ6K6n{B%;4oBP)Jg|gy$sU
z<u2W`r@~7YBoDmwc|-8>StIar(%;*HmoTivY~bZ-EMrJdFxzp>^@h+PdGMkKT{Y~6
zo2&<Jab(2D#Z;#mKe$Q}|J-)Q-?N?ZKVz4r>$r9DC%4}YTMT`<EDQWP;weX8*1hke
zFN22~eL3{T6#CNRx<q}cBB;{z$M1$jUyg-64j0Q)PeNb%qHO4o#Y^qx*Od0#1&cCQ
z7k>LYo?gcx9c-uEE4BUhXEY@S2EV@fhVi!Rdz#7d^3c^;!b{J^4qlqx^})+#2N=9;
zb3+QeSP+ONn%mw#SXNxoZcc8$-M7Es<+0ZVFIPMPy!?dqXBp$A>uuS=OP{~A1}|s9
z`uI)Z<*I9emu!p=*DiGMGUsg{yu35S;N{=QGiiU^Fgp=1g^lU?WfGD{e|+%Uf|rva
zjkN+jtDn7}+J5VUsex?t$FIVtke*-$!Ti`D0Mkl-c>-#X6}&87;NYclwGUqYwy(j<
zB2Y+DywqKhh!-xyN!K5ZK=Q!L>B|K#dqNuP7Fh0?<E0LBWZA$=2e4auyli^?hKLuh
z{q_}VL}NOs`Qz=+yzw7yXZ-Q)jNd=w_{sa@H(*O;MPFt;>gY@9Dj$8hcpsxLmtUDe
zU&`wf_2n_xLh1CSCz6N0T(?^E<>yDBFXzBF>!&X%?YEa<TxY5-e)ijZtguKw+?meO
z7W{n!FyLCruLbbqX9X{#9(M4O|C$e84%^${<%DPoycEw&#LEn<kxhq}wF3n&-@G7r
zdFdhGWj{1o#(4Pw%M7xCm(yXSrpL?CEbVUzFSS<zFWK;?>@nZL%j%Urc-eM<!OLz?
zs-*q#x=R!BaxCY*(u@xm_ZPg(SSfh9^+Dhzh!uOlONRcpiyzD!Fn<2GE#df0511V;
z+du%*N`7epz_WsvAMbbYGVdiHyu?ZjUVf-cftRM*M7;Fj#9SJ@%tG?$kM4R}@NzDs
zvEIYnMdo-JQ<ELM90=T{$IF*2?uI}x9=v$%uOZwApk+*Iz@>=)BkY3q#9!Rb_>(e@
zpWJ?Xfc<ez7W{9^?{)O0`b8god7`h;mltNF(3d&WP`T(3-Tsts(6Oe|mr+O_`m*XJ
z(U<)pjded54*GIeM)Rj*kykeQ<1a9|9_t(1UCEtn{`3VY8Rkywe#NO%SsLNNdvd&V
zgDsU6yxcs`!AtmgAH3A#8xm>{{-42MN&Dl<OA_(&9GAkU;nzL*iHd09-kfHM1~-Q^
z)?_qU#(4P)930ue%U!70^mzHRlx%~;i<e(drV4Xik_L7B)J7uSyzzTw96vc;Pn!+A
zW@CO~?OhID=PdQX>pR5;um7H!0<R5|67gEd_2_BvItj@Guirc`cs&`?SS#)jyk<7P
zP!A&_8+h%CWoYT$IsZm(1q(KS;i=ajlN>MoVEbnUFN^PR@KX7#4_^MZv%$-vDJk$$
zcTpl<KE{|a9bQHtdEn((PIE+qdqNuP7Wg*7Z<*m`$u-%*%X2W2)8l0kO7@$=OXZ!w
zOE%^gX8py%OX<@-c)7T@!OP{Kkfi-#d37RQ9)ppW4lg~CJn-_d>JNXO3%s0zsU_eg
zVf|U^`GvRI-~jU*pN@xTF+E^rqG%fgU|MNEjo|n+8+aLYn}e79MjyN!wxhwz380Xq
zcqyKkh?f~y#F7p#Yj+U51n9Pn24A`rc-apvpE+JGY6HRe;pKL$vP+K_uFu)<@DgYL
zK!vr8Nr$K2{>&Ty{R`R`|JHWKKRM(0$@}B`!FA1-W?_7~$IXtutX}M+FWYW!^kp~5
zpHyGgjZf5<W4R<hjs3Q`m*~shSV#qZx%DRKOAwRk&==X&!q{g0UCQ}|<FYi~C__52
zlGvU~?quWB<7c5{b2fnGAzr*E$IIhjfvn)=#~U5I%v<Dxmsn4OmmeZ2@X|Cc5iflp
zWIDXeLh|U3uj4dFG<YtgvEI9(4S4wi3X~0dKY(#|dc5p<`ELv_7fk?OvN1kfeuIOT
z>INUYJh6?z%L|~8r2I1H+(f*5gN`*FUgWzHSg+Y2c-bG)SodQoo1eX(+I|b52{Q$Z
zUw`~CW@*y{W*z4jHUxrcrTx|ewUZUR+<cvbm+<30c&YDU@bYI+NK(91o}Gx7=Wa@m
zmpza?_~l@_ZQ=idG}dHTVwvNm5+mkp;N=6X{78?NCispwJiK`Auj63jD;blUZ{GgQ
z8^3!y<G+cac6;)_A>;VT`{M`EXJw^7KKp7%UwS;^qc8lfgz^`kbxsO>DLoUF1H8KD
z7p{XXl#XA2>?ZnB^|<KE`&U6<4u@|sWBaWUm7A%$_^l6_eMM{3<z2WU`N82|dv_N1
z)3$1TZ!K)^tl(wHYzHsad>_2*zLmktzGGA1CI5^>yqpfIN{5%_TMAxQahf9<eBesp
zWji!k#(3GR4Z~wUyc}HB8ob;GSLAOBFAZa|)E{@b!of?!13q|J-__uyGbki!f4q8h
zB3|~!g5Y#`xf#i$KR*2d!ON5=@bW2o*3A3km(YZn5{#ey_7!^C^!@S07+!1;fN3Sa
z9CB8c@bWIcX0NtpMgw*C`QYWn%?)1O21b+OW!|ZYcnMsc9xrDjdEjLR9JSz=BOs0S
zB<zOF@$xbNn+?3|$O+7}4u!+ui`?+=;<dl_0!EaKZL{A#2S2nY{)6p|e_qD%liP21
zS3+NEv*3Tbug=kz@_T&r<)+PyzTA6S3Vo?QB~f2ip<_+QuS1YL^yRVpL|=MA8Y_CK
z=*!(1tq%#JLNZkszy5e77E0ml#yynW$^36iAmWB#y|vnYoA{?J;bqdL4ql4?>VucD
zn;N`aggle-Yxtx@yxc{vW*UEO7bFk76mps+8vJYq@NyEG4E&lIUVaY?JR5kK0V6d%
zUao?OzbU+YfU#Qhj4bfWh*}3P>+bZy%ivB1FNcCclH#SuiHUfrg3~7*Uf$hA@N(Ck
zf|sXifS1101uuV%=a<y}w~?bV2aKQn)*qHxdcagb#ti~6t+d~kU6>`j^qlVCrRjDb
zylfUQc-aONk`ymic_Lm8rUNAnzucE6czN!6!OIoXfR~@(Vh6uuh?g7SLCut4{P1!r
zR@tS;O9|*~!^4Z$e%lQ88)Zyky~Xus-uN%Veriwr`gX=Ytex?{0;gsse{%b81o=5D
z_TLmo-^y?E(YKp&jlSJ`d<uQ5J{E-o-rfGYRnqIF-fukw$<zM3UG%LNq_Lu4$c+2*
zV-P7*b@R3VFc3<wZV!!CO<8S@iTG8{R^oz94?lbLWi94EGsBxV{%TH<wnJaXXrrg~
z`kox`+o1Q&3f>pHzWH8xvk%_?_VcFNU%lv$Dezu*bRynAmIbn@@je2{1MkOPD|p`%
z(pa~k@5~tQuV=}AeXgQ4cwd3(SVCcg#`_}hQ+x2b>j~|PAI>;_a=f2#dY0^|<<$<q
zSKsJ^_b1jHyuWZv3cSxbG7<0Jz@?eao*ISZf%iUKwh;~P4{5CXv9v97dum_I&Sy&S
ze)iPEV72rFze@MjzdGPk@cYZ{<o74rY0u2g*q%#{_h;zO%Eox}-6{v~b=Ujg{Y8Ar
zLCr_LU6umx^F}1%Jpdac9p2C8mm=W*y<G5q1f;Q^1bJqT_ovai*}(gbn7K=j_f0f+
zZpe5apgW<~+Y?@U=J})8e3^_tlH>JKut-+ykv%3jcwK#s4_>$Z*5GxwBU0dX-S9-b
z9t*=F9bOmngA&+p#br`h|2Q6a4W8cyd*o^K51GQ%&;BkuuQhNjg4MDC+9S#F@&)K5
zD|q>FoP(EnSNY&2_O-#w4~M0|OVb|`@zMuWkq$4jkUa2m-AuvDxsb+s@7y-v<p4PQ
zvVoTXjP&&M_65Do8=n1|94~7R$x?r~{9Few)mQr9<%us1US0r&B=x7wIXDq7--rQ{
zdb~3V$<zMBLJQh|kjA<nOXD){5B~^jBU8Zm+JBh!O%IsA)7`uw0LEkgCC5t>2r(=6
z)6Hi)cnL>+@KXP|!ONdPAxZI4c~Bx=o`VUWj$igb^1#c%aJ&L9n?o9FGFm=!yo|>J
zp={uVGa>2ma^-Kpema#dx{U0fVzyRESf7u&V>{!2FtUC5-=10g<H9v-anhsuG>bW-
zej9!>tWIWrX7!$mU+XA(Qs0!BE)!H8R==$iH-q!)N1f^DPyXdT`g7P?qdzAMi`Snq
zCQCW8zE3Dog{H$iasnkih5VD4XwfNHt^_S=s)QEp1ATxNeJW))C6$Bg3ued{-J>{r
zK3u<UK;y!Eg!%ejlZ}1gw2EZTv?r3vthe9@Ra&OrdQPNQH5_&wZeI>O`5kUw9<JBT
zQ3l6H?6BByle=Gn=9K##(UH*STtS#t@CpQ3tDAQOZf54o!S~}%`87_ym+kZke;ht<
zB|Zm)vx?8fV;p=|Ugm?(zcm|tE*hE|pELGL#ODWW60LJ7PFXz!nSkYwyhQL>44JGO
zfTZl>^CY-wvx?8_U{tpjpVR4J`CrH9ov7jF)mh`uo}(RnHr4vzbF+ULd~S0<YJ7gY
zZz4Vq6rYvms^q5t-_0*aL<`U3;)Q6i?lj=@JFI2_K0ov0&)Iy~TK+U=_A3HC1?Fhm
z0O~Pr9Rht7mTPMP`cGv38v|&@{8@>CW)|@|=}!(mi>LeGb1Xh0q5O*%4M~m9gG&?f
zc{_UPR`BO0$OQP@exl&hssKKZLpgr|eD-Z~2cHC=S7TvqYw<Z0ng3?-3G=g*hDpfS
z&y&z~urx({TEr`{ufrq)d|FG{Dy3;m6$k$b>G%AF(_eh(FDw73tfvoiQ1)*pexK?h
z=w4R*acA?x^U{>jK#wUtd~o6#!v|*}&!pq!(t)aS-Rmc=!-88WK?+Oi$A1VDRH^au
z`=h`Fhoc7o6J)j?@_I~Os(y(6ocMLGE)zb@_o-%MAe?@<d<D90!v0sEZt$+3NRF4^
zqbah2mmw!Qc(E?_!OQOWNQUY^_WgYdyyW*!#LMY0QPSaM`FnzwRh)Lf{-+awm+jDG
z8RO+Uv|u*yaxezD>G5(hhZ?^nyu8QtD%qIN>~g$=mxc>{@Us3LgO|>rkfi*wdap#h
z><yD49bRrm@~|{czfkZpr5t$q6fSq*CByZQSAzXA1&qgpfOCT1+58H#w&?-Wckl)R
z7*BtloL}k&WeG3u{?Wlp-32~)dGRfSm$&<+z{|Y8iFgUfEJ|vB|Jg_$c$qO)@WSuK
zTTjAompNV@#DqgO@UmlhYw+?D(78bnj0Z2p)K1&~dZEU2Tj#$AwKM+r98W_B+nWEv
zjN>QQmya;roR$9gzGEDHDUbN*%S~?>eYtnf6#7!VTcW<Kl1YKo`Z5H`Lth@dK=h>-
zq_Lt{r;u@f+#h*msxE%>?<-NU>FIUnT{jSQX|4UXIo3{O1uv8Ek#=M67mxSB%h=Zq
zUM|`r1zy6%iFmo|IM!-vymUeGz)Rs-f|t+AfR~fdWEtb-n*Fnbml-fp)8pmaoquC^
zx&H7h^~WQQbnvq7JRiIae%0XRP*6xx`>h9S5DM-dA6ChPTxz_$`-<S@uJZ&hPaOfg
z^hMb+?~hN$=sZ(`@w4ChW7ar5V4mx}fdIzSA1CjRruWGbUV0wx;HBvtAG~aak7TIv
z;WnU<q<FD*O2o^-Sm2wEU+#NZ@bVnpoYCMFBY>Bm(DIq%<s7hIHt=#Pm^(dQuG?`#
z#EaK{D*#ot$9{Tw@Ak#NvYqjd%s75>ec2w^%}Rf~cDSQ2bI$V7mv@#Mefc*yC8@qN
z6rpnC__Yv2&2;)Q3CW{B{^lIfmy;olwE_&6aesUy0Gz41_}On=4{43MtmWz)`cuaI
zn%{;`*uRt<FJHj+&I(=@|G~jaWu*^Z{`P{w%OW&MQoPjlO2o^@=vdR?WdxE3UXI0-
z4fu6WNMqfCk#5F#nY?>;@bVmJIz7EE#!`Ua6kg8Bmi;#CU<WUyV|?&(ag)Kz<)DzH
zcq#9hh?mDWVUxz*?}_Armyb^uy!<>2csU2kn|XhHK}qI-@w4B?!xftzF!jd4|7#OW
zEA6-4paxm-*N!^K!At&VAG{ofk5nl8?F3LrQoIyzlZclYT;rbxFKeF@yaeE=1;4y>
zAn>vuls9v{d;yC#(+<fGFSieC4PH((4*m@aFJAlYar8lAzZn_*KA_^kn>YT%cE<mG
zJL7-bw^j0w=$+rt5er(>M09xOZ|lAe;$mjJN5NB=W3O3vT4XDIbx>r}WqG|(uAEpW
zTwuXcPQl}Oy~8!n_DD75p6&F;us%h=1-5|ds%-*hJH5E_j*c9x>+j6SV10F7q@TX3
zitM7Vsw3O!t8%->cWX<H|JwP-*C#7LwGS&mU9kex6)Qkpu>#Z;D?nYfsRH6wjBaT1
z@VHP7;bKls)U3&y(HO~_pBwvwy3NJyzUs0AF1H%+yfqvH$M04T8rHjXA_Mla-&Spb
zw~ubWzQummp?@PZ(vMhmy~N>TTotvN$}Cz<^-itT?TsJb9+?Wz-uQ9yPq4M^n6_x!
z^5xl1FTQ*fP-#Qk1k84N!(h|&sB@ip+k<Gt!@QbFz4JOmdhn-XWK;fhiEI+<0>GY(
z|0ncsjQtT0OM+E-xIAp>u-+YVNO{HVWV-6B36V{fqLYc`;cqU1ST~Hn_%oxis`Ij8
zz4HaC`MgqC#YMU<$ioOC{}}h7y>SKT<tf0XvBLSe%~v2V{9J|~7=lyrqf3H<RSjr_
z5gO@6!?Gw0bq+&oS&CdKg{Tus(SfZfW!*wwO^9?tCFJJB0{l^>M8J+LZifQ+COQsY
zlASWUD_{iM&ue6jfaIZY{YXqq!lhASUBIOdY*jxdX+`{nuzZuo9|nafl16X|F>UP}
z)G7Bc@S`Et)^Kj&L-c6!UTEl1c;viWy(JEz#KY$8^Uw;5d(Y?FNH2ZWVNz#()q4uz
zGK6nqgv$^D2NAh@B81ip<y7q(js~`K9cOamaqi)UZ1jj0&U)MoH)30Oh8swriW1L7
zy4Io~ij0)27j2DO8R=Wy#U!tl0BXhyVie(Z&d`NSd_**`7ZS(dblpWV*tiNm)=Dfw
zLAVNrvn%97WDVIXns<X?iMOSmx0lf`I@7Gl)^)f7^#nAP6g*zry8*!gN><1)TYrWz
z4J6987)bRisae;zYBM|;Sku(O{V>v5zuvuS3tOafbozD^Y_6}m7R<O2DHFgYR`&tx
zTaa^i6RK*nWwp{|oe?A!u~XY#r6zV!znXQ`Dob3IR~0A3?TWZ|%#TquEN5(&gm7et
zg2zYp?q>%+aG&)p172-t!N2bw6**AO(Mr^_`^$KZi-(CR^r+$Sf##cWsj4KORf5aX
zf(KOy+*5Pd*dsbN)i1$4x95zOzL<4A(yr@~NQKFaz`ODZd{<__E7R}Fkj}`>kj|1d
z9dJ32mpaRG{6aT%%YNNemAH8riox=g*so3n5|GWnnl<@Qo&nseH5JL*?<ZpfgUl<L
zrTy^I0*O@FyaG?j0?gfN#8c71f?CoZL(j#pwX(AUTODo|?Wo`I#@YqT6IAAgtV>zZ
zvEk|=jhP~tE0ff`20jL)%d?5f|Lj;<tQX#YytT9gcAn|?pKLDaj>93mg-%kPaasD^
zYSs*|@av%IQ57Q+p7tzxCDri6O^q9`Q3FZ%d7f@*Qi-)ad@Bw=SKyK0L*88pYZMIv
zs#5&i$hX4Jyi)wkE5*+tTq%AIQ6Ug9gq9ozejcXyd9v#`lJAf5;peqD17Ep=4(sCK
zXC!bjF+^pyw#j!WQd9J--c$MJd{BbX`6MholgI2w3y-EK(O@hBmfj6rBot{hQgDiX
zE&Nd^!RY3_;#gWL<|@wqfTgJ`luI7215(GJ#6r_ec%x}LY|}%SSs+!)HjtJ>B2DXu
z;7oP3d)1b91~-@tz>bYfDng#-6?pn4{1njVWZlxk=4rmm5uWCi@bpAGxv)-d2(ucZ
zh+18hSM6%Dup=9ymZAoYB*N58+sP##Hw6nu_8wwq)C3qgOwG_Jf29)ki|)b@Bf!*r
z0ZttOroIK2s3&w@9;RjpMCGdM5g@iQ&D5iCUuiRSxn14m2+m~6@NSeabs~$8L^|dE
zOg#!&2~$gvw}Dk4t=oJMsTu_os+M>EQebgYwFeoS!v+Gv&Zazet@MWz9KxOLrRqXZ
zavW6)==%f|;$|ZWo2q$ZO@fhubdY&Us(uA)CQu-uViEe`Z6)3~P1XCN@5Or|UU`4D
zdLKzg)zx;1DpZVWQ1v`WwvnpSbwc7#r2lIG?BmGxdeqUFPkty;clDul1&`;{<@JtX
zx3&yQ+^@0!cpcuQ9_2ey{JQz+64kg1fXy813KryynTY~ok9lGN7lhXFWx;~<-btSS
zsQrmjpa1RrdiluD^3~_Cbiea?i<fv+-<qOHBYMmC-_9>teTM6?2rx<evHW})ZdD<@
z<=dEFeS$u0tWSr{TC49H@tIxy%N}3*_@Bs<B?V9AXg?Mg*w=4S-(-F9^A9cIl+JJf
z!zVqRj#zSCRpJZst*zmr@JY?fKQdtn63W4z)qHveuuV0WNysyHT&iQ<$$sV&E~6fL
z!^(fxRONDa++cTIDSj1@K@aXN|F50@E~$#;bnH8(3YJ+9?=AnYoqyW;H^iE<{WIyY
zyyf4Re+spdYSo6<#`;fJQ8QcD18&5hd;GLf|I)!~qyB}VS+R}$lMW~w`3D$D@8-ym
zf6YK7CH@N9V1L5$rz3sMW^tngBOk^joMjK>V_GDP!O51nW)7u0V}`7|8IxDxj!ohE
zC9%G75pLL&-dr)78T<kryhsJd$Ryp#H)<4IXD{8DwpKZuYkSitTpu229rz^%Ovs`l
z49{~Z9_C<WLJ7p>BRnq)V`8Q(H_}IbJ4D9IZ(c#|69_8T`31Fk@TE7?X}+i{pJJv%
zT+TahqRSiU5su1I1O4K)|NOuS+<vjGz0Wr-lxfa>Tn^EXGrY|!5)yp{9&Yh`$0yqT
zM@h7Qe4=}x){$0!CfZ*TtxiaEQnEz9|5g$m5TEEB@L?mZ0Zep&B)U^VqPrwZv>)mm
zaR$aGdXSnCAIL-pN}?~JI>kxJ`D2+blZ6c-Jm!o=+{9VlS8B4X7>gVlfA5|+!v`Zd
zoz)Q^vrrRfTS5faI%-Uu$vK*AHaSQ0y|oG!mG<I>N^4&($HxSW3KSCeb1`94L~({L
zWF}bPaO)hII(zc~nK~PXvy83Jx02P=|3DS7Y$cee?u11(FXP?@%Pl!ZIXYq4&7*vU
zq{B?wi>j3!4FGl}{z`Ku??AMchQC`)z=juv5XDY*HfGLaomBw7H3g`tF3FjUr46b$
z%R(i{FeesXl<$trNo5lRqx&+ZkC_o&1*e5%YKPS^qJAib{wt}=<E)#hwU8{FQ?=!y
zB6oVDUFj_ijS&5*$gkRN7*}k}k&q)PqE?ebIzaYq?3b9QcitTja4nkZPP_r3m11D3
zMTuBb9nOhh;HlHQ7qg`cS<dj-=TSpgij|jNv#uoKq*{j%EMz$=41aRMEln&`xpryr
z(b60gTcuwg3b!<x<Yx{I<K)n3&yry_&gr=QkMY;3`1s-2FUQBf1DW|!X9aKxzDeNY
zdjKgur_v_l<7dA~lITdVKO!ga@qbjJDf#%kWQo>dQXh#X@No&IUHLo}A8(T^(IeD)
zq69wPWu4;bw(@agt>R$vaY;XQU3Bn(=Z7|EKAwP&S13N7j%H8A$A|wbk&o}isu`n+
z80RPB<IVYnjA-GTdkY`0!70bqDQIu-Z%RJ?$bh9P4Ie-AwE;kD`1n5v-DW<X#f3<Q
zep}7QUGkFg@eo&ft>EJ#3$iES<1Ie^A&!s#_LZrZWPH3$r*wS04mz}vkK_3>+xMyX
zc*jqEIX=Ds?eELSk2DMMB=B)FEQ@q}ykoLNzxzTGP2l4$%EV2{$19Rq@^68+{P?&=
zEm%y+$JNOa-2!!vL=*UUClrm(+selu@q}VnH{|2FyZi9*hxmAd;^VKN&Z+qL$$uvD
z@iyp2Y<5b{$5Z%)h-hJ_LBhvnkjZ)(y;?dxo@{!rbbP#nJ?v-=AK!|Cw3&~u{}i>5
zF&|HoIXXZ4_z+imt>EKwjE9r)@dUi{+Q*xs8%S**UyhMtYWuhnAvW@Hw)r<cy;OXB
z^_pLfk9SQ<NEi*1cjE`_pTDb~r?QV<x79Ju39|ABiJZX47eNV-SxP>>Bw3=<F@Qtl
z1p9cMDnUv<-Yr?8=P2Vkfsa2`o|QK9@yLHVeB5<sA3i>&&hYW6X!cZm+!rlD#dP~C
zE*E#19;_$l<Ing-hiKt<hY24y;^<-P0Js>^@$ov-&!*$!*D~@~-0)F5`1l%*5;ErF
zwHW63`zsD|rPm5Re)YZN_VGn{=jG!k()ufYSpP#BK3<Iw8~He%KeK(GijO<IqgvpX
z@E<=3JJ8oYzDF5|34GiG3`U+##mAM&5<ME@HS%se$#1Ky&Xjz-RkB2<d?tw|@bN!B
zRL?1CGXL>Yut9x`U;CXzPT=E{RL{|7K7N+x7Hj)>YLO2gKZB1qDEs);w^Q@+EpI4T
zxcT@8w2sYA$@%zXejy@SxZrof$0d--dhn+o((>_ZpaQ9_bbNdU7*<tlYwY8L;V5sj
zeSFPZsD+IAcobYDN%+{6UMu+cXAC2g*~dpCDK8%%2}r7XN#?IO3nRtU_Hh^?Hu7<{
z`8PhjRD3*sm1==sf{%|%Mo3@6IwSAKQ|HUCsOPEp_(xkE<Lu-4pG)KfK0e_C^_+<&
zo6q}evP4f+CTjv8uf{N#c5^B|J~~;VhbxbE0w1qXo|QK9@j#w)toithZG8B6z+}V6
z2cp?i*~dY&1e0>}@mZL0v)L&*AHOt7`1rCO!pC!0fseO`#hA`MUXAJ4R`KzAv}f!2
z_^9^yE1p1aY?rvz{^RBJO8Cy_jdi8h3O=3>hE2xDhhPBX<>L=g($swXHavQ%`M3cg
zHu7;ie`fnW6(4`_vTA`}f{*WjS)>pWN1Zu}coO*d$d&2&_=seQKKF({ANNzUWGU_A
z?+qEmFWOkDBue1p`&Ojq<2#cjdaa(fi|>xUQ5Jri`S?y8BW(D%qR@wr@4&|+lzsd#
znmrXCPkvFs!p+BT!y#m|Q*u7upI@km7Vgti__!-%vaUqIz{ekBZl4{PSzob=izv+G
z|52zEhmRNWmH+yR!;K*wX^nmS<UiVBAD4pk>=L({k2j%_>C49!2cz2F1|R1#REqT#
zWk7T?KHd@y<mKbN(L74qrkFh9)>k}-ahWu~Szob0t*<!3ZiG7!!pp}sR)_cn77I(T
zf?~|fe3MK4##I*WW9(G?eBcYJMScl>o`kf0`ML9JiihI~s)wHUOJy(bk}T2VlGw{<
z!HGw|Mk;&x)#sB)n!i->aJ-~@DGy9adwFuQL~GUZzXW^vQW)5fw9WjS_oBnkjRijZ
z+z}t2Q2e|lYB3c*zxSMig`1!E#SEO$$rS4?ZarW4d0AKC=W#f@*!mpa_jLR`-z=jL
z|3wOZ-nq%NRcrY9|JXYZ_$Z3@k6$2=&<r35Rsw_~MM9H+fI)(uyg?9AB7z`ItRN<e
zg&I&|i1NpV6%|n|2%^$d3>_8g3ySSk0bwyHVk3&0|L>WyH+x&}E|*|9KA+*Tv%9l1
z&olFVo_S_&?{Fmk@^|F<h8({bOHQXHpYK=7^T6lV$hO$*xA+hf9wVQR+al#+$LD4+
zlg@muj4NV%j*PaU-|fWbr#5npM1#+R5w@`8bK&>ad`<!tD9+);=Sp^k&Voll91ce5
zA-*){$mb;(36?dzgV)I9KVQ3^J<O5MS$2gE!Z0Nc2iNp9Zb`!C^Jsd{vWRCSSGVBv
zsB0ykCqnH`eC|=myM@Z<hhYG9TG{*0|6IfPJh(pN^M@P3=l*Dz8=vbyC`<)ze2)8{
z)Rh-Lzx7rG{__o(J?Sm>>_2Zt@3!W1W2HO~d~Ubhp3gnr3+D5FIQzU0+wpl8MuIb+
zN8ySXpF<~XWOq36xf1#>X(Sqa&Ui!in4tK^TX2Dh!@+=h`+c78#OH&r+Y~w%NU`Gc
z7+$C&pC7g>^wpiLP!pf;^1$alc7@)<opKYO+e2Q&ZEAiv-yhldR)Ejb;w|{RVXWly
z$7`MW{MZ`aEmS`LiP?=#D|<d)j)x$=(V`{eb1LejErk>7#^(e%FLLAakE>+|@WSV_
z;Z=sc{+Eq<>n--o=jK>uvF3A%Ql1As|B0Z#o&UTT#^2~af3ix-#g5P4VbbT!=MA_b
z#^=ar8~WW&d>)D39xXn<_Oa|SL40n`0cGOz7c1TQJi@NfJ_xB=@%c(P+?4MW->6|%
zXp#+|`>$h#I{MEmFuW|C@-JZ%iNnF>X%nCs37=Ee1o-^TKZ(qjHhiC?=@pXC9iVn6
z|M~A%dACscJOtqvomTdIUOR&Exy!HgQETpM@Hq*tog1I;Ld?sP|2!N{C>N_2K3^S)
z|NJpcE<=uQ+yQi2^Ld6+o(Dd^fZ<@r=QQ+KBcIPh|9AGE`@lRn^SLP*5O{0&9-sJr
zUo8F{I&VY0!->!9U*Q^whW|VXW5W_qQ{QADGVwWY1J8HzpPSkhI^Z>SvnjsOj2G(2
z=l4NI%bI3m8VO{Y{O7*hk~s4D7P~_G!?CvF^Py!tKV1KL=Boidr~hHW=iJLApXWjC
zPJAA=ly?i2&ujjNJV`5iKA(n%z<++0^ZBP&z~}K;=yK!p7AY+^|G5b|k9R)jeiecL
zyq==)vc;bL=e^k4X3gh`N_igmJOWOD9iKa!;?LFf*{YrYyyy!zKIh_!7@tGsYoymZ
z@wv%MTqDuob5)Shl6tSa%s^z~^L}`o0GDI@`DH{FEDJr1`5kUH@wp}jKIJ?4&qM7B
z{R|w#%_ctQ3cs2PwcFpEU{`1z$Q*^5{O6{81`u|9W6w(gK0on`1)q0cEcyKN5@$ZY
z`5f;SDxXgx?nqkM^LYv$Li?NlqK{ewP$%sJxV+%A<M**AOYAZ}JG>ub8RA&p`8)vz
zHthJueYA^3w%9YDZ^!J=n$H<ZdEm3#`!ODL@Sl4lZe#SH=j)D(-Tvmguwd=HpKctk
zF!DL}evC-zYrfx!$MY6*4Mc;-e=L_HCn%ng&X?{?JkCRx0;n8${Ip%6orGT;93|M!
z3w7jif4f3Q+pGuHMs$=o?Zo3hVRbAm#~C~VZsKtQ_xQu+@u24dJg)tt1&=QpAbC6z
zYIpLN+dj>^h00@!IOue;=kbsIIgjb(Nd>hE7lX%VL*H&Z-U!Rbq~*rrg_u=%=ka!2
z9X5}z1@!b5d*<;0T1&OuuW^b}o(CR(gz$%*zx-dEGx9heQyeZAJ0Aau5#r3_owy>#
zV>3ZZH^+&`l@@XhM1#kJ(Pu1ybni2qyTRyuTg07-a(3@4s$^H_r*QdzNRxkj0Ia2a
zC;xZ}`k`e_SA$!`-Qb#z5^)VD9%tDVdgv)usENmw(KI|PY#wi17~t_V&4R}p`br*u
zj4C+s__4=%w@`WfC)%vj$)3lT<00^m_x;9roQgVWOJUXAcsxv+L^mGC>C+A`@#QIK
zNZ35S>3OBao_RbJ;VEk#H&@E@z~dqCR_%B^3eyQAkN4~I20I>KjhUh|kNvnJ#^chZ
zuemfQ9#4FXYakjtu4W4)PC1i*{J}#ENRIyTtNL&Za=MrC5U+{HLof*3cs$&$(2*Dt
zRy^MM9M5;+ado>w`*G*m#N+oc8Y1Cwr^f?4{%My5k305}JU$0%cj9p^Xo3c&%HylI
zB2UiV?Roru2IKLkiEKZ{6OVz%jerU_9`BTP){V!n=-lzb<C~w1fX6pJt+d!PkGEl(
zW6k5HN_if5{3K>}c08Vk-fraaBd+m^&k@mc=J6_A5#zC$prxDR#N%BLat%a-$B)7H
zw)8sla01{l@wgZZ8kFzkAN%bJ?ST0jZZ`4w2&@9-JNd`IJY`eU%U@tOoBZRqp5XaT
zJbv7+(9zi3fEt;2+=E+=u>Iqw>CMJs|MG~hEO@-|Y{}#0P`eY4C*RAvh05d4VP8D(
zxF;S0|M)@ra(F?l+NhIu4|dzR@%R;>fOQr(9-jxo@?PbI$ITF{58FS!@d2g9o_X9I
zArc!NE9H6M@ugIEo9~w_d@-2E?a(E;T<rYgz6c39^SC9hi1D~|>1!^{iN^!yaScR+
z$L;Na^bx!>;%;yhVCmgF--*Xx>ccU}Kc0&oYQ^Jj3wXX0kMFcA^c?Q8ns~hGaaO2f
z{J4W%p>26Y+r;A~7!AZ}s%bd;mFv-)jRlWC{M3TS$9I!FZUVJC@%V=V-Yrxf_r(<1
z1CL+o%6NR`4#wkY^T6X07$7$uuUhSq$6r97-g(>}iVB;@kH8x1E%wag7bz-X89)Ay
zQl1AM|A66O$K&(SE~9_E0Xfb*UW169Gmq!viWra01TEbhCmye#!!-~M9_PX>;yok?
zo!{_~u8GI(Kmp>k6OYfZD|8WDIx8O65&Pntc>I}!LGb%Ap5Zkz@p#T%?mV7pS7^3a
zw+l8$JGh4*Hjii0n~epJ(?7Q0ac(Ec<9SfK6OV_@=G{W&@fu8#bvoI{D^9~h;2$^m
zjPdxVIpFblGz>g;d_P8e2!(YP<{vwJ|GKSoq&>YK<FQ90;BiBW+Q<lvXCCiG@3!Xg
z*7<?*z+<=fW8~gp&*K|lyNx`q5B2cTX1o6lX3=?na<15xo)z1lT)GH$EX|3}P3}aO
z!I+K)pNFDsOFn;p59e?&po$l{^Ett;&@MLqa$f}Th}%wlUXGDqSyOEW=WuXMlXwKi
z(O({BSLkTI{m<ktkA;IBiNCyu-gGSZ{KPg3KJPw5^7&`f&56%%qTN)K%IA}aJCauR
ze4c`bfX~mq$M`$|b<#dS^xcimbLBP)H$GRLC3WQ`e(`A}{_-aBd}WJ0^Z8tIIxYR>
z9Hl%Dd|vyAJ)aLk3PwKvm@DOC$LA_Alg@nJjfe@UJ;rB8pqBDUCqB=Z&NUJZK6gRb
z!jgJVJj*#8Oud7sjGO<w3l5QGp=03kS^3W&@ufLOJ{Q;(I@X5InN!)r9QmAPS7;{;
zQ{r%N^Y7=DBy9gVgWh~B`0U$a!ROwmOFj>Tq@DPD>SW$6R6gGd1E|x=p3nbl$@tvm
zW5(xY)4}I<XqX$H4?#^#uWo$)_F>rpyzqI!?GgCT7h?9Lx7ahEpF!`o=5w4<o(Dd^
z4UyQzGk%6EW90MOaQ6AYu;cR>l;_On-nb&h=TgS6YjI9|-gO(-NHqAIa*OOSLGg_R
zF#g2hU_d>W&-0z)8y`%vDRcsmV#Vh^yii9z-)dLrefP6MP4SJZJ@C1iU7_RQ=~(f(
z4&+7o)ckPb%}>*tkOiMdth3<r!lshX%b|8BK2N@xcMFxzpFe{<=}p@6xhEb1|2g41
z#^>6olXefBST{cJld}ysKEHpH>;PW)+-PP5d>({)>n--o=c-s{vF3BUQl1As??FL!
zeBPQD%;yz3QZ9CU-h@e?GoKgYiWr|=fm+HJIPv)$^mfunH28c!!WfpWZdDE_6Q5tt
zW`J^xKd0Lj+6*C8D?XnGFP`$9;u}R+d9keN!TZ?FCO)^D!t<$6yYKfsU{~lH@ae4h
zya>>YgwOHxW@N$V!q+YMT=_J~=ekh46Q94jfp-g)&)pDy(P?GR=f_WFd~WbE<MV`@
zz~_UAySnlD>bXJ%ZhSr)PAJ!v7e4om#D88+lS^rlJo9-h=1tao9;uY)fzLl;Ma7QK
zD-h;0`p+%U|DFBkW-t%Ve6CCe1U)Dg-za4SI~M1}=cgucjYNabSr{9Z)Ej;)1Cfc(
zS54#jPX2RcyFybZvYSo&=c@2R9r^qc$Y@#9L1G;+*wb&tEs0}%<5Igq+rhE6;`2w>
z@%(W8=h5_LWWnd;6&8FR)ll+zBGm50=N{McZlUt|;YW}sX=Tsne;P18-^uy>;RNux
zKS1Ng=Vzs~-1uAxoyR+$M<E&#_I{10C<-rI?3vG-X_uU3{CS{Ko(Dd!pJ&f!zlqP^
z>(ezm|9KY7q%)sK;fffa9bp=UlTLiDbPd-?H2Az1K>$nY-FrRfa4_}WhQ|qTIr`84
zXIJQ_nBU=M6Q2)oW8lc=?skQ)2FFmS$$uUt;vP=^^FH|4md!tOH7nE<f3D1D0Aa^B
zHqx7s1)rxav*7cFx{}WyqY6%Zerzo77Al|rM4NS5+4K2wJcRZ)<Hd5=-<*m%X-nbq
zg3pfc#~3ED%lPc@evG+@V|nNE02tV?`J7F=SVHFWP|Oak`JAGZ2R^&KA7dnXrJeu$
zE81oBpC{>#i{1X_s}VwS-cRSp6-GYC-j7lGKz8Es#4%h0(ctlC<K@T+iZ>_or8~2~
zj4tKI<C%7a))RhlFyvq5g*x)Mon4_B@Nlen{1ZAZ<va2Cb66cq9v{ae;3gjLLl6Ol
zhRx$n^d@A%<DZ_l;Bm)VlE>#j?M^(dbp`JhDvv4Rpwr2o$M4tVJYLFp{KOdWxDoX2
z#^a}9`Ixlac$|w_g?ApmimSusaVCP*dW${#%iCxz)zV-7i%2c_?t#bmjkM?Sw<aE6
zgDDP|iye<Y#|Uxe@hV&q<8kQ|*jS<yk9Q5{8i)puyC9rq38WiGaqb4A^EnZBc8Xu@
zLYJ{DbR}Fq(9Gl?Zv$&7p9;16J=OxdLLUORh`Yfx?Tz6;`A$4evn%u?$Q(DDc)S}o
zP(BqJ*7_g4`B?CH#3BnGFHDd;UXCg_@p$rOyj!R|{v2(VG;#QSsh)TU{NpXl8INnD
zPTD=NYHmF4Ax)wikH6KY9bV$gm!lzJ^Z1f0l@@#Ead!j~ta)5jDbE9szrNg_$5laJ
zqksIiK5ww&abJXpoO#?5SHyU1q-W_LIq`Vl5Uzn}@OVGwTbAhjh*QqwA1}Rx0m(65
zai3kGb9so@#N%!l1fZNFkI%L%^c>*_2lIH<SXQVbkH6Q!5i~t$i&&r)kC$LHM8e~G
z^rmCM;|~{D@c8&jlE+P;b|)VHa53)|Dv$flLY|zx+xy2a#W5bQq#w5`s5NZ}cwB-h
ziW`qtN#pIt<9l`Pc;WG2Vp?_j`a~Lu#xEO?J1NySxsE*AlAekmfb|vm*CgUY|9R4j
zXqF&b?3u?eVqwFY$CZ`xJn;AhTy7Vy*m-F%k8g90SFAxq&zZ;baYc;BrB7gEiB3FT
zKZt7}8a$pn!iL9J;RL{A;_*%pjPjlQ<Cb=X)`iD_n@v3af_t5gJpM1-MN7-ka~vzw
z<R32>#`B&0<0*E9W{9{%Fyv3=mLqKccqYBsSnxRgVGADT{*@?xe{~+z?!@C^19-Pk
zdAtTjOQ(}Pk59ux;2+;iUk)#*_0u5mcszF7x$*d3pn$2sjmIrOSgtECJg$QEk??tZ
zk<wz%JU#^>5*r>X<$2(7W9*l-<MHhX?->2#By>qG7d!vB74C87aU!mW@z_Yu(m!(I
zafkj~1JU4d9XlYs4DZZ}$M^h)=R5KE4ShHUd7TrkVmF(3e9};!PlejWE3ULFv<Y`v
zO+21|87tJ$Kdx(6Xe}PmHpMFnFd871uzCC|z1djsc-egxJpSc($>T~;yAzM!>&v@^
z%Hvj8ar40AyYUe4_`G?H$0JZD?Q0kyHy+Q&4n0piejWPs&f_{zRM<Se4c1t1v1cC7
zp{Rsq{J6DJo(CSk4<Fc$$E`4gj67b5mOAtJVMO$tc{~YM#CTl#1U8oF#N(&V=NgCx
zk4M2R;yok?orOH4Yx0kiKmj-Z_&B>lXAR)o4fZ+@ac|VoKVB_i5d40OJ9v#uJihik
zcOH+nD|8Uwsb}KxYuv*Ro5!Q+&BlVq$@f_Bc+?@u<B3qa6OViJ;oU;z@xurR>2$L9
zkN^3J@%ZrljK?3I4<7eN!@y(5_hZz7Py#%5ct1uh=}3EeKgMKYTDb9w;)|6Qd*<<G
z^lob&FILI}kKNvn@x?%U9=FE?$H?Q~Zj__VcK;hjg3JClTw&yK?DzYOERDvI6Q3((
zaE(NR&)reBC7<8P<Qxu0=}s&#yYYEnZ<|6J*!at>5S2rrj(nbHSLoKWIfsL5dJt0q
z6zb?N_pmE8gKz&c@%dah*eEn?K5wKq9Sc5B%d_C~h9b%5k5M-#K0k(bQ&B3P|3tMt
z@cD8)1pe}!cQHPvqE6aUMBm-`JV9=wVDSqFKJV=%JAjw?#mY$h<wfNAh8$0BPEMz#
zzkIP$o(Dd^ILe;S`vwQ|`TcY$7dt+Ghggm?pEux&7@woTV5c&j_&l;F*GM$@+yHYf
zOFmB<%|K-GpFcol-1xj64v}S{ec<vDhl5f2GGCf=<nwiQg`R7}=QiEh!yNhC(5}#W
z7^cMG;F{)eOA<DpQ|Qgdg3sUNTJX8)UdiVUkhBw@|L)4Wh05n4Fn~I(?EUAp-!VQn
zxQFq1Zcp$z2@P}O^G8sVC;xdJ$izE<7d}r#L&El-+hg{mx7f4)d<S~BHJ`tw$!cIf
zoSXkV51q^|p7G8(!F+xWi{)G{c6{yw5j*p_DXxg|*@>mmIOoLY^=Vuq(cp9ZnX<<O
z#W$v+a}kGw0hQ<H`A+fXrJZdG9ng*4Y~ph>UZ^9Vhu9UGjVUH-YKm|4^}y#Uc7^tb
zr(?zEL%4zRsrljTkDEzvLKb{ZpJKu1+;1eG=RxgGd>+<`cMFxzYv9gFx;X5QI}Hzk
z|Ge)>#^;~Xz~}LBV%_+>Mb0+d{O6ZC$`0U#&n1v`*nIAUdh0Fr%;&wB23hlY4;&U*
zo(KQ=&mQ)C&PCMS7~goHgOrOMpBIgA<8v;qi19fZ40bBhiO)^Y+estQ;ByYb7?!T?
zUhb8e`20wF1}Mk<8Oe5qR)KQ@x|#Ug0)v9`oz?^2#X_WIO+UDh-E87>(pfy83blJb
z#!YsGJ_?`CiqEqE%}DsXr(=N6PfW7l^X|_jpMS<+cH;A!XYg*J^7$m<j-2h=`_EJG
z5b*i%b&SsgP$%t!i{1I$x1Ugf8=o7&srBwZw~EAno`+e6-eS*uKKD}GWf|W%M=8$(
zpYMlA?EL5L=$J-6C!qg3`_ENiZk+w+-DE&OgRI#5nVo=I%IBQ;JfkhwNHqAIhOuEu
zy|cS85SjRVJ{$%B%8}2z0Wr%$Yqw)JoA~@4cXb{4e79Ypoy0m|u%}<0TN20kMpwH+
zlZ2lfT<FWKBI9!gy%|~f&%PTi_}qJk<nutN-HFeqp3b|4%I90Nkmt_l|7~Y{zVdp;
z=Vfid=XO}Sb@QL^l+tqJ^Dcc>=EZ;Rjc7>N{__lq!pjzW=JPYOOU{zd9hCAs@OivL
zd}A=88Ad+8qfgiD{O2(+lg@nZjVoe&E@k|>7MB6$HOw27Qrn-GnUd(wJ%C;J87Tw&
z)Z_BEYEMJ4q?9y&ekSFv8=x)08Vnt!`3o}Q*vV9OQcD1@I08^YOUg_2=Owb@Xb1n)
z1oX=+U-nd%lb@c-zg|BeuUBfvk8wxVYTD0#_)z}(+`?4UD%p@rhC693a&wEjPN~oS
zN?I`}Wd!Q@90ny_PvzpVzN8hIDao_hgXz%EpVQKx7q@?WNeSxCFXI(#z15$;j@3V}
zmtQ|sQb<{Ji$8axe}k(Oy<gxW?@l6ipvb!iX5myDle`}k`zX-JGL?5DZhtC-yf<R5
z5Y)flV~(tayjzIn^0Jn9|JD_!e-A?636l3PI9`_hdnF>B<-wETZ7Pnu_rNg?lJ^go
z-doE1JOVp&;mVdLV|l!xLhvM8#1<5OPeyFrQr@4EM^+B<{-R06>EA<}aTzM|Zm962
z*FPj+;h*fH6+;Jk*I@oh(#+ZHYlU!vTzr(VD9gf0St*>9lalB!>7?A-_|KBDNoxz)
zP56WPE97G2R~rj2L;56QOB{1nM%p+l9~Dz~g5MPIS8@w0QC>70mLS*0#edn>)TEEu
z3U3Vh7)UFw<)x25Fi?*HeRRiICmAc_qZpA9$s>b4*1P!cQ5_$tCm$2~crn?ek8ub-
zSn8w0x%^r?e>1B3xazcHLLa9zGU;O{rjwTXc*@29kE%ZA!;3fucs1u#lRo?uf)Mjx
z1F!00)w|s6$15it6Z&}CY|od_l)@?=ksxA4cD!<p|5Ue(|L|PcFx&V~O2zSKJDKfu
z51LX~$@@XEyj|AvZUkmllz7`lvps$f(|=2Ow-B+SvX*!M6Dy9q2bt~dFod@(<-IZ$
zCmiMn(c;N)puM8>?>%OF`U5SmS@GmN5i2U|{yi2Iswnc#K85#LWxh4JrH#Bl70cgc
zE$=UCR~&f{J>Demh6+y%{^Bm0XgTo2lmD*xC~EviaZ+sJKS{@gzqqZANguNn-Wc>T
z5IZr-O&@<?pdJJBsqPr-Bx8j~#VwF!HJ@7V;=f0Ae56)8CiL;*aVC9?Yi^^D4q`3X
z&OSs{A6L~pCiHPiEt5WWVmfI#KAv*%|D&pp`S2o+0bb3iVbX`6LJ(HGsw>u#%Vm7L
zl6Xw$<7u-!UqVv~tNBBMh!xrC!*#w^+cN&cbDiQpbt{fP+sSONd(f1^O5P7*NzuuF
zik7?^fteL$zP8b9kKe=e-%{Q!M69T+`*;6@iX-nqW_vpf;Vnyfuf!5mdGzn$Kzl{$
z-+RpV^oIsE@;*<*ipsiwk41$lioCO{^FFK0w<e!pBkxbK<Xs;9`-^}6s4(&#8fTJs
zLxm@Xc*8E5Xhj<TQG66N{-Zc4Hu0ao|2P)>_iZJAFc~ZTf40IKgFXg|y<2v?@id<b
zS08_1pdJJBsqPr-)aMm_6xR>%$e@q)F8+H|^^tn`m>3@~{$<j~xOz7F=pfdD%Vm6A
z_2)66k5i7A^sy7uN$HOo#>Z1G{(n@*$9#AZ#{jS9{9)3EpF$9p@gK34TrT6|mESAS
z`0(3*0c@e!pub3S3afxbRS_(*Q%FtvW@45vY33a^JFICNH2)fy|L`Gy{(5{1O?(r~
zc*Y?Z^r+ACWMY)f{%SPMu(>*VUk1b8YPO%+LH<q62D}Z;F|6c&2i6#!9Ne;ye<c9b
z<7Dn%A^(MDgZ(1n1D5iyDuPMn+5emTR<Y#Y)NG*JARcBZ|2wc|Ro?x-3G70J>i=eg
z{9+Xw`BxRert<9nC!%r{N&ZcXO%73;cpLfOfi?8<?*CH`RIL7g<VTbIS5^(k-!MU#
zPBS@&0F!Qi?+L;G5m6=!2go|m)T$_C$8?B|BUBz=G;{NZuKB^Fj}{7#4Ei`kGr98C
z$6O5H5GQW`CVhN??nW|J0!$B9wizE+c%2_ab9`*sQ=#?opYKijNT_6^kB_|07ow>T
zpH`vu@j99pG(K*|6jl1K243~@I)8|!KH9;%sKC5xz0ahNeKf_k3NXFwbv_YIee|u^
zyy|VX=b1F+u!?UyBVr*D&M#=Mwsm|-o^gmTb%#G#k>(d0%=UX5mSQaB-yCb0p8P52
z_@0!qIld>)ILQAg@U$Yyzqi?5XCj1PDgS3gETla9|N31OOa2?o_IcZ{Hu7(dHL>#U
z|Lb>GEcy2~+vCh%Y~=rph=r7A|6l!c#ghMq?|7e9=5N~$*~q^+83r%&=_vC5w9hM+
z{2%$!B>%w*e+=`3#x#-hB7bLpR9abXe+}^^d5Rfe>-f?;J1g{jt;QE7eQd#ym-g78
zkN=~ITzTswb#H~%$8DdP^wCA(lR+PGVy)WMK16eTT={W@)<@B&CVf16&}Mwx;B~$b
zO?^DEqeAQBvQJF<Xh2IAR`HB)z0Mz^sgDmZdMj{z>D}!necXv9F-v`1=yg63O?`a-
zQH9pWZupC2qZR-504%1|hv5a*=aQnl*mGz9mbN5Y$Cu<8=3ZI9%=%0C9~CLSG0JSe
zucax6ReW!=h=sV??<mUu9PqRv$$z)mULQaR!BYO`?l1rTKk~zhCI3-o`+O}zXqNKd
zEMg($+5bnv98{?OZ??w=zOj-2xnvm1ng5rfaurGbqyEcfs@UIazqXP8W-N7;xBS;`
zsaWzq>m8H)4}TkwzhVBojwW(m`oFV3D!m+w_>w%u93boX($$+Qv_Ja7R+B!iRCr|2
zM|-jN%+(%5Qy(8<09WAo+Q}I2)aMmGefmF}@$sbB`9U=Gkx*En^^w2Hq>uByve8E!
zv36aq<0E}Th1SOrG%sj;tfUaRReWi>*ZD&<$H#bh7ZsRS*Q__`qXmUHtn_in>wF@b
z`nc<@f3-d`@v~^j888qH1HWXMdmwEKe!l}@9$!&)d}S@Uq!1S*<F5f-@j1CgCbTgk
zlfKMGKmXw;<)mvTQzV4)a??t3Diu{K+JxU0OLO~ev2dQ>8vQ>b#jn(2<%hfu!`akd
zslz(AI)w9l>-JaMR{rg8ye_B?-rAo@`d7ZB2Q4O&K=Gq__!I}Yz#lkD#!+qk9DbO^
z-%vlo&*J&nuN@`2X@A=`%ctg7lMgl(!1VPms_(z8eHC54q3R>l>tpgW{-9E*@(cC)
z@|Jf9D8iS+8~U<q5hlS(g{~&ZDI$z^`HH-A545DZrTVv!<@fQwQO`69ew<0C2!}Ye
zCB313uq8cN|9f+K3cq4YdP_ZXOL`mS?^ONo&FN|U;?3z@<z0T|Y^Hda_`TN0+1!;X
znY*#2liU;$8vZ;Q+S{>^)So&wuU9uF<SpqAEq;;B4#RG-<@kVu=O+*EANIvK{K_o%
zo;JVBy$3)2sw`@l?$4V(BA%-|oiYXpv&;^%qzAx`#z_w#-Ob}NsAF3w^=p2V*Ka?Y
zsK7HlO67O{(Nw>Jj1=@4_QSpz=zuiA$SlZA$;!lu0see_S}{;m+GD@6?N45x*Np<0
zz+hQD?~O8U-zl$^ZTl9yQMS*U{ao2TZzwGQm0^ErMgfvCd|s31%l3Kci_7+T)5~}~
z)Ob0h_8I&Y1n~(>#7doz$=c*+97^<Xe-DrM<Jp-1yZEij^E_UkiBicSVNKgI%?F1=
z`hV&EDv9KOP=h;uOwUf%2Cs2wtxY_EM==nt@KG6w{=8mj2wJl_y*B%4T8B7=AMr7M
zu|IcGqA$B1yV0MY&P0L#C{&?1qTyYyyWYah&7n?W>EZJ7gRk%7<$AcB+DprV3RcRa
z^A{7X)dvTiKY^B$9L`T)?R@^{SDnv)>~en4OV0Oqayj1zyO*8nKW?S-`RkWDpa0}(
z=kr^haz4L<dbfjo>$u40BO1#N_g_NGPY&lZiS`cXOI+kT-9>(zu>HxY{09~~pRe<Z
z^Z7Ys{T=GR!bN}gVs+l>{+x}@=chT;pXP9!XZc&T#?J;7B&J0Hek83(uRW{K5;$=I
z;3&LhP@qA4oQOoH672w18BN8cPe-fW1X?K%gskn){bnj>W<h+fz*7TrxIleDSBney
z`RNA|tI#~MO1}@P`}`d@`txR{{KRIKGgE4_GdMYi{h66haIWpgTwt8`7<IRNc}+U3
z9y11Llb#2flT8d{G!z&4l{|)iT!)E;yb%v%4;i8DT7ZY(WEP<v!Hx|2)pBWPX^{ad
z4Ps7`<u90%G7Uo1ekYL1gZ5ASQG(l2^^Ey6j93dgLl?Lks+hxD+;N-Mi3aiXjU*Ba
zi3MaE&R+_z*;5m>Pi=Y{FFi;<OWq4fKYzc7mgpjll70@;LqgTh^KX*|gtB_R5Tu{y
zUZ=Cv!|uoap<w;ow;X57Og~+Mk!?`BS)UJ6cU2K*asBiIvyWrr?W=cneNJFGGgIcW
zPd47@Ps4a?3qg@S`87s;ioC#h6B&l_Ch`p9jpqf%+r&rlkWlq`7OiYaeeS{>!7$$X
zEuyoe&rO)VOMOnDmSVhZq_H}EBZ(wR<4xz=b?@l%_QJO}*<@8B$tZ8mMfjO$X+(Tm
zNe>BC-cQmPkn&y)0UG4}14a#(_r-7srMy{-A@4zCWXo*)91eD=EXITGFXty}L#X??
zj34#-Rv})0rHA_H<Fm(By}z*Ds*gSE@mWAD*RL`57cuk#{Y7MiJU;KFhlJW+I;!LI
znumk>%Nla4*!XM)2UPYKIX+XC;A~XKr>f5(s9Y%ee-Oq!l<WU|D75R}3Gw;_5B1S`
z^wlQ4e|h0iTjFT6?fJw9@Q_gZ*O@fKl|1?Ydu|LodYpnroc{=q$^IpIw2{2ADDjAP
z&9D$b?tz9$E8sf9Wv{w9KBZStJpR8TX>EK8Y8sC!#pi0>@Mj|aOwLD8q4L&z+MUtR
z*(AlvkI5(2e^`hxHogp=4L{)X1282qf7%4hsQJs>6Z59i0gF}UuA)CH=frm?EV^CE
zsgzS!9A)Et96LXh<!qToIrL8)ep3qti<hV-Zke{na2QzFPu!BOFYIFu&jP1;lc*lp
zE4EAtT3EEhE-Ti)nEsCb{t4qxLnS$X+BkG~J_eKXrqcn-&s{}-R?4onB|aq%<EkhD
zf6xF+S`nY(=mg05f2@3KLa4v&!DWQFX*`^;6SzV$Q(AUS%<(RFCH~1K4TC6jhbXGH
z^)Wb+&~ch^E)aY@`=$+)KCPJH6AJdthKg}xYSLOC>eWd8owT-Q%315Oli0BzeTF>R
zq8;)yd5wls*gh7I-xk@%%GHZIU0$DCJSO{;z(Jqjg5TwZp;!cGC^T5Il|7LTu+NvR
z?eS7`i&JxCt@t%Xdt|}9(m8Aso1utAYG_6ZUrrOPfel~};!Wd4tjJ7>o1IAex8op;
zN<|xt;<Q$B1i1nGfyF+H@Q>lVg^6PC>sGhM`)TJ?8tt6Yx~@W(AgxhzvT}=)Z*MLB
zx^-$}{+E{QpYPBAkh)N+Hg(<~CFq@T^!?YODx2{?x(EJ85h+^o3QSxwQ&N(aVqTC0
zF^#Ca4kubdge_$OJy`)hh|KTo6$b?7RR3FOu_lE2zx96(^&f$Cbhr9XVFi?0{RdK<
zDTMl$%yp=LeS`(v>c5s1P-^vWc28*aKijGP&)wl(|9|j6jMLKUKV$9=t^QNl<8Au?
z{#owz?^(L_Z;7yGDE;RxwAXh0zJx^`xBfGQ6%e}o$EsFN0nl~#%Ld@P#sWb6F9Hzz
z%K)H%3LF}+0kMC#2E54%2&DmxKX&zBa$jim@99+k${y<f_nc4%fMfmNrR5R^AaC-Y
z!X9rk07fHj>?Z#nrCa|KL?kYi_Z4Qqochn&e24yX1j`I=^`FcND7F4`NvQq*E{FP`
z<)Qv>vI0u2{#D7R459z@bgF*=;=*q7|2r?#{%`Pa)5NYbEJ!7-NYrkeNu?E%=h>XR
zyL93Ar5i8%9$HFTSvadO=X2wUj`IFVImhw)a|<hxJWv381bLLn^f%V>6`z{CDOA8W
zn|YhcQ}vq~ivqA=49+Hetj4mWba>%-0`tiAJK<WV_;TKYU3C4vV!*Sq{>wODL$w1F
z0JOwM5<=~h{dsZLQ$O?lD}7`0_zZ#-Kq8VQtVF&`1X-4cEe+&?cE1-r4g$sYkHUty
z*Yq8Vu@uZ+MRQc{VFn)uo!%CF%$~OjlU;E?KdxkZ99+KJaq#nkk7Lg#{e>@o)zc6$
z2TY;!(_1!OhxwZKd9)lIvGOqPV)FAG?~3)8$ofmhZ25hDgXPX5=#NWU;g8n_VWLac
zkYWszv~&4UV-|>jiLS=1C5Cz{mO~dcK5Jc0bp$=yu*hX1{RN!Eu;GvWUn4V6_S5iT
zQFaqv_5=K=Y2f^@Ty{Q%pYP9)no&tj@a#tPM^pT90{xMKKWfn*&1MxQ&73Bl$ck=?
z8Xd>3p@Nzrik8r!aQ`4#m5ls!7UM#D2e2602tW3Hd<8cIb!(Y{^=)3-pp;2eHFowb
ze)e=KwI!8$x+wJ@Ja}2${=@hPv|}SCE-0%xZ^sIL)PnA9E^FO_YW*1QV!3o-3sK^W
zvZ&liwW~47cG4x=3FmydZ=_7a2S1mppJQt)WV`VahECbEoHK^iDBoXOYj6wqB-8W7
zmba>ufv%M9KWi&{Mw(tu8p>w1N-JV+&^TN+0YOsIad-Wy?((Yca1*k;hMOez%k0y=
zzi-Q7x)S|;Ek7!y{(cF97J>fm=SNC^r>|Dvyy)-k_)!`4_a6`}wD0d9@UtHKdnWck
z1^RnWepH_Qy~RyI{rv>WI0pLr*bI2Q{Dm!6fL{r~e>9ybD>-Q;0e%BNDuoVDWhZfD
zH{oT+@gvdU>HJuZ{1kpZiyuX?!>?2TpNuYG=<q95z*pjDJ#=_#$C;Bwhi5Wu$&bpj
z!=HI$P={|u85O_7d+6^A5LJcVMSuT4epE{R{ZT}mQMTysck?5qztemg=S6=%gCCVq
ze@{gZu<!46`B{(sy%$0;D62Uiw-lJcQF-?Fb0-A#_s*12@%uZAXJB!0s_?kjF<h}}
z;@DqM<<ff-0}GirK0oNVYtZrOLB}Ts9ajrF{$rl8{QW`4p9LMi9dx`p==eGH7}FEB
z`kRPV=G*JhA}RjrI<-3gOG_>4CGxJ&&)%w^9bD8@ob9Eb9ipG@QdDIX?NV~|RatzA
zzHdrBJzYBtvLhUrj0j+INp@9u*U3c~1PCPJJ6i8xxdAhwI`X*L^?#J)YVt8~i#<dO
z4Mut#`Rfz>`Tj($;WfN}<2yrxDBelIxwsj~gA=a5H3gSqCR4Jt*J}FVB6>3d!gyFr
zmWBLRIQf(ESR|B}y!L8da@v|ExQR+m(>mY4BDHAD32fP!_R6MfJ=k&@H5u_$RwkZ?
z$wkW>>8i#)epLf;RpX*2;wl6*Xh#>WX%fe;`GqZP;TS?0=P3VBCkA%%+j*5)e(R=%
zD8G9r;RXoEAipW1WL18@jkl8D-)uR`O@5z>tDNNbinyli<TrnuS$@-}hA6*_ZnltL
zPf@Zezt=Ewuu>4z|K4P)S#I)sP+a9CzZ=ChWhcL^E6wujH6=v(9WN#=hW_`@SYEO!
zzntr=<i}Uj+~hZyt+`=5JB;6s;+nFPUqjJK1OEWy(D;{)8-mC0+A(JNb-vb0em&T7
znw$I@h^w6B_X}HBD^vcB=B-rax9+wO<##W9M3elch?3R*_Zw`AdHnu8n{wUc_o=wb
zNq(=0Ys#+w%^zi!-}GB8<(I2fvNOPMfjcGv_7Fv@0(=!l#Vo)#?(`zS2gFrQ0-PwW
zDRlwb+25>@X8H9Zcf{<!ILL1*xMPyv-&gRWRrzJZsF>w<`yF27cZs;lNq!x~HDxBh
zhN6+`_>CiXBqaHr4K|tN_vQ$*{5rv0ndR3V0ZaD*e1f>jNq#?L#z-ZVnf!JR=Z#e5
zw~owdNb)NIcTDn|EQ(h9->)z#X8HYv_?Nr<J`q<r$#1#1rp)9w|8leZrXw~Un*81Z
zc1-f?A&OSz_bQBvS$=O|!s9N#2gFrQ@|!5GDKq(H4KvHH7r7%L^}ngWj!Axh59LLx
z^2>%zG0X3E#CF}~cZs;lNq!x~HBpcseGMr0fSCGLVegZ~j9bn)2P9Ja{n`-b!P6$8
z>TD9fe?Vov;5Gs8U8?QNrp2kCWim`zJE5dB%-z#`Io%KmnVOJ@?;6o8xuD8rixSx1
z$$dJ$-D}m%swl0X{^Ph{HEl-GmSB+Q7RTjO-qx{@7ceR?ufFXvu7Lq-P7qV*0oqQ6
zT0To=-?45<s!qmvU$50vd}cwFv+4N-^|ce|qt>CSi9T&EIwo(>R6Lj3Iziimc>+^r
z(#(-86QwHe0G%LTpvtEId|!S0zyzJ|Aew-eSk-2kw6xfMw!bSyM%vS&;~}i!u`{`o
zu)%!JE_s-Ny{l}&ZvxguyYi}hDrUeFX7|D=s@!An30dW&BDTo;r%giWX2!c{a7UWS
zkw$`+3!#zj5Pv!Zn$9)yLt;Q9Z!c6e@-Wv(O$do=<YZt&(Fh7qG_wCvu8}NVBU#$H
zaJr>fOd6r$p^+t3m_{zC&onX|wbA}Tlz?mG2Q&pij8rZyk`5}Lfy!qjB;EM{PWngT
z7@EA&kF9kxr;lD$)#tCguH+josYZN7A+_jwe!L6QXGBd?i!K+(aGKfi1^k$%hwQi~
zKVE`}CObZZAK#9y!j4bl$7i5@>=>KlNHb5vy{BUu@u?Un39J=Gt@eNTcL}4&1nm?#
zPn0KX?ayN;(Zllbx&VsKjGen^WmVs6NSly$Abp4Q8&VatuRc<!F`9~Wz1%P7#;fO<
z!yO^7KByEJ9WOkgjt;@AA8`R69e)ooj1B-#86EFlV&+v#W?Gzibq_tipnh>JHadFY
zNc#qJ@L*oGl*Xt0d9{IjGa3y#ul__Jwe)z^BR-&!6Bno&5xg22CpB^nkYvlNt{0nm
z^#FWiH(veiV;UJ-lWAmWWoYDr+oeW4^J-;p#;ba78hCYq<dNW2Wz0z#Uj(n_3>L?N
zSA!(a1h39OMcDO%SDhrk1g~ny>jkgcp)0xYsydrC&?pixv*gvqZ&dY-LCQgzg>*mC
zBBa-lHX&6c{)E~Vue|z`Imi+6s?k4uM38@V<Pmjr2wwHX1)Nv?fFxyf7<qN_Kr^o<
z!2`7&9m2o*`foh5p#I`IY;^n|j<i(79D;c@6Z4p(#J?I!AvpuDdSDcm9<K^Y0vfsM
zVO1l7S1<l0HS+o(gGP-0Ro(!u5!Juii}7r$5#e9;L-Eka3ALF<N}zu2aV!di=wBtA
z&3LtOoq<>R!v${yudW^|js>q)%VWW-O?WWlli*dQk>XhJsyfUVJ1=<k#YAx|c$J2@
zi3_iG;u5YrCtg)SJL)4fL+Xsw2kBy@F-SQ`p^ov2biG$z<zaqp7$)J&2gm;r7#;t4
zP#qnDS9jwA&a1~RG>i@-udeCGM~6Be+zM-GJ30if+R^jjUoB>%<J)44j%kPy1oP@4
zJo_l&)$0^OGw|x+tRO{1G#~ux&wxf&->+&!@anI_QX@5hB*lUldG*<UxJFc7oyk~h
z<M9e!J%-|;k+IJ*jr2!tv>$<i5P3DY8{<{>W&^Jpq02J92wufwLd%W?uP#GWfgKB8
z)q{y-$AVYqqQUG~@alExj|pD2l{^!?dM1-!?=T<SD=nd;fA!iX_)$nZkiJ9u4XFy+
zRv)PuQbpoVsBQ7etIvXmNjSWE>({{Ocx0YBIs~u&hYL8bet`0o(P8A(>xfrS98Bd^
zLl)_=86ARGQ|b8y_2;ueQmZ|Vv=6cKA(&S;V&-#{@M<{X%0^zLl&XK#_V<8Bs{Nm;
z5y7j>U!+DZ1CkVt7<qO2d1hYS!B}gf5y7h;er6h}O4TT+wcs~sq$l=LgvhIBJ2PIT
zyldc9dlbZYBY4&80&y&O)$k&5EO>RJ;7yU>)uVmIdBLmu<or_bs(pWPUhwKy!AA#P
z<;#6aj=UQ44*V#jSxEOIEkb$?X%o^8q)^9rMY`TAuTIBoAY%V2>8HTxC@N4#hv3y2
zxPbGj2au$U4kNE>WSDt1j_pmb86ARG9~@+(Ba!oJI*zntgoA>4)fLY^N_f?r$ZYVh
zx?z+U6cLesHTh6LBbUxmH6nQR=#Nq(FPv-8h>=&foMYzICm5Wz9<Sh44-^jzauYxW
zULAz`wYw2!3XxZbQyH(ee_-I%iQ@!M1h1Z!^Ett*ha`^#uYN&&RsZU0dB5P*)4jxb
z!7HD<UhpahwuSC@;MF8dLAmmr=7aUoj%G-mk@_HAj5G!*2Wb{kMdDAWZSl&hpAjN3
z43mq(SRWi-6c`<6<*B1X@M;P!;Jhk82-TKXm!UGj{?#g2Q`^xYc-4rW5B~}iL5z-%
zzQ^d8fF8t0#|(XaFjxALNi)Z|uMg7u0WwlL$Y<jx8~7Unlodj3b?z`W&)<zUGI#K}
zM7VMQew>h&ojP1W4O2tztFRVf&_zVZdgnkuDbL)gDn%e`|9+{IVvJZtDMn;%?!lF!
zP6?Z0JxmJ5Zi(<N6c43T=0>DDYNLIDksl(mGTJa?&E9T6Ruya;QC+OGAY^3#v+TS;
z)>l~iSCRFy4ABc@b(b!fK-SsN4ZB_->!6rInvnILzC_qVA4oc~?g(BYOlsuY`roR)
zok$u|F;XHL))1*BQW{dI<Gi9=@0C~QoE0=i!r|4@y@8>TKT{nVf>-b30?w<idK!j?
z(Z6~D@rqzxCBj>`9U6jH<LUW`w=*}ZR%0A#h3Ij?yh_K+hw<R3;MEv}RgAo9fl*O<
zygEq>DCPGVs!{~6x_&2>;s=s!d38cpt`wD5H^N1+Rf=%2KHtNXay;|2YR%aPrL;y^
zIz(RG*MjjX?K1<fI%3&U<y9dZb9O9TthWIVb}V>xrsP>qZYw$k@oKRQi3whP3ZGNu
z)l(wG<-n_-aS2zRBd;dytm>PMG#_a((ki5_NIQ`<q>93yP}|{^SM$!4Vix<a!r@iP
zw}GMY#Z+}@2wt7GOAd{;K$0>vjJ!I6cttR;vS3PWhlb$QTlD;b`jZfofq!)aj<nk7
zfx*0LDyLjW1+N+)Ol;&;)`da3h{(UXdUrr6=T1?TB6yYeja16~G=ox%{?*t{Tq!EA
zHemeQDn;<B6^e&acGJwXpw^e@0UGVE3z1iQnlN5zUm1Ayx#ZFHoIia!8hJISyOCG_
z$dJ6?)n`E=_c(bhcy&L*b}Fw{BWgm&4!l~3wt3)HOEe^n8iSODG!AJJ(rl#pNTH7N
zigLYIUi~N7ria6;{$B-#M(f+up&@v6Jucw>)np*amRJ92&xeK@Z(j_XY&$druafBb
z@UQM-t5NH|#LyUlxnD4^`g9Oo>Zst=K@io*t3Ty>K&fmQUGu+yQXaTPRf^!%XJ1IA
zXc+E_QjEM>(T*!c<<;@S9h4$?bt{U8QjX7KN@;`IXtcjBL|%0|jqz&!E(5O)%Mg{|
z)toLyUL7y_BmAq^<@`|aYJIA>{tV8$+rebUC&8;Zm>{dX+AQvO;MKOao_MwMTli5(
z#Yl;0R70eeNNLnSq>93yP}|{^SC7a!k{l!9@M^)%z|gquCUs~CUaiFioLBFmrzk_i
z=wCg8U`4QhRSdi3#;f7<eC%&$AGPY>LtBPLqF`PXz_&Yk=7XCcc_Xi8ogurt@O2~d
zud06@P|DtHRVjj3r++Gyk_IFxN-^@PYHO|(l~<z>X|q*|;MF^yFr{3Cr@+6u{WB<q
z_Sc2TtC=S<UitSKc=dmhKY~{$^)d2l3BbsBBY5?WJQlpV9#K?wUhrzI^v?vZ_6E%d
zr@+e6^$xt63gmh4uV(LsABD6SX%*5|q@73_QZZ7f<Gi9=@0C|Y&<q!I1oOdz{|yX{
zcW+RKhTzq4+vU(W6-ZKshLKlA2v!91%8$5!?a&bZ)lzzXLH(VaS6ARj^I`56%&YHO
z9!<RJ(ux|U#@inb_H`rT)sP(lrJOlIRf^!%Egwsz%tlodr5Jg2Npr3gl~=DIeq^f@
z!K;%{Je1O#^J*J<fJXc4Lgdx<dW=`aMFw8oCjBG9tMv%LG5%c6{iQk5{}Q}vCHW?J
z)d`YTdG$n!I2OFRPL_8ZFYgenp9`<@W#<ZPX|Rg7r%^+YvXI6hO+uQDG#_a(QbplU
zsO?a`e~xdLu`dha*J={=UlVgbPv1Y}w+7yt6sQH~q5b*5`)KJJ49nVh7jlhtr2fRb
zUZ&S)Z;M?YlTV;`ZQCa8Eq|9b|1Gz;oCee*lXF+GUp8ZJ)yB6C`LBY}3s|jR4bO@_
zCd<=DyO3w7$87vd*{i>LSScrdSsZ^aP9i^V{8dCBJ71|oq3t`Z0{n=Tul9TSH<OPd
zzp#$+{c$;dXv9>~#}ECoWn2iq?q(j3$3%G%%b#qY_;F8V?2(QG{Xce|y`VcP^1=HG
ziDBvZj(S)4o5|Dgy29k_boywT-IqREXE&ygw%OI_BQ^WnqKnqhuRxHalCCw!I!Vzv
zYsj|njQW((ehqdPiHvy4NM4hyXZ(T<1w~0~67`H-$XFJKuaJ9q>!BR|vVTNc{~?$F
z8tQ*OWvKN}qYSnFEhs~+{|U$_uljFCbj48r4V0nQe>r8S^?#Bw)cVgwMtRl$vBp95
zpF<gH{cocTwf<LAhFbqikx^dtKN)c+gZ!&ghFbqWu*PDjzeX8q{Xa!UdDZ_gb!K(^
z?xhU1{yQi`mH$S{Q0xB+G9s@3%5?e-d-l3i@CUETApXz?_(LDy4}Aplrz2vUhWa<5
z47L7sC_}Bkk22KyA4D*syz1YNI)f_z?v$a{zcpp3^*@O+)cRLLMtRl$H$+Pe_1{Ao
zYW@F98EXC4Q-)gqmyuCk^}m>4qRKymGSvEaqztwGO(;XHe;s6$SN%s|HPBH1{*<BC
zzb9p=^>0fVYW+_^MtRl$(q2LJ_fv*i|1OlF*1tJrsP(UpjPUF4C%<KYb_!P7Sy(zd
z0YA#}v2acXXa`S~`Se;Mi{DHEwK{=Jo%m~s#?qPzvgkzy9WGO2pj-KCiE`eQG0>Uy
z4KYv@FpONW0qiZ#1MBb@Xqx_7qBL!3I*)<kigeSSV=5l6B{~7cBL@04dpl9BoruV4
zS7PrCe$u596Orei_YF8&Hh*#dJokW*-^)#<oQ(2Y3fgkHdXisrC5HU-r55t*{DzcY
z2C$*Tkd5-ITiYzZ@$f{2gl*;b$?HshOZnI0=2Hy01(wpIFTY3S(qT~ls|0@{1o`b%
z7Dkq5S;+6VHBx@@$2-XH<KxWoYuD3Veh;8{^uKn;u{{o1v@o&{OK;Ja-^~rAoQ(bN
zpxl1QUMuE0exIQ=1TlUm4z`frYpbRFHe!g{_P=?x%<?;kJ!5YD?-CRb`F(H$lV3yB
zMtinXS;((`BWwAc(M;xh8oy&d3dpa+B^L6_StaE+6GPNiegkWo<+l_&-`(VQ0*WX8
zVX+!();m8W{$T_~zyBQujjZg)W#}a#jNj&{vFv|853-P7=ao`^8A%TEt6Re?zwxwL
zpIaDv{;gp0YlNNVkl*|dh<|V|qc6Y8O{AQR<M%MER|xXk`+h)v%P+E!-*2x;`Nacq
zw*BwpYG(Ph>*_AQ2T(lv-@(I7ep#rEwhv2((U;#=3>d5aM-$W#<oC>b0r^cFXd%DX
zUX}9Oh$q_0Z(gEVeg|Pl-TL1pC?4{giZ36a|20Hyv}dumCHnHqwc%f8i2U0YkY9%j
zE##N;ij?0>3{hM84NNf0Zz)WfoBU2d@sQtAyiAVx_b%}do<;QKcUbQB3-VvOfgU0B
zzvig1&cFT^^6R`@$}gk3gZ%1NHOp^291%D9eeyDs-@!3Ve)HcU{-I^jm){&H+-m%u
zjaG&rzrAk<<hT3+3;F%FOv*1Fh_mf~AIF>J*A9+|oBSR?@#udGs2T;evhbnp!wew$
z^1E4|XBh2AT}*C6kl!;~1M-{L&q98$EtT@y2#wjwZ(e1y{0?F$xXJGl6c72`!#5T+
zL~XQZ5uS>o{L(sp%p>=W5XNJY%AsEX#dmbEEa2B)tDMY_a|`hY0{@x$=O<?77qU$G
z(%)q52229I&cx;XQGb3<+0(;+{vkLKVL$&PeLqe3?T_U7r=1kB{J%y>A?)@iN)I-C
z`45le`QKqnRD}KSYcwJ3_7A`~3-9^j8|}$jS3oH2=ii+i@$*-s31L6Kh4gen)_<V=
zkvzW(rpyt_|2BA?VYh#Ww7}uF{|Jf*`}xcMDvr4QAv}NfpcL$PQ{SP#IXx3=w(P|?
z_#L^C!h=d@SxIZtyCN*o-Jg#im4gB3u6<LNe#0(l=9%&>?g3kYkRX*JY{dk{R!oq#
z!msr~U{yRVy*7UreX4%!w|W<SD&9q}S4O-i-u2D>o0`Lu69Jtk`=|!}8y=9|^Q<)J
zzmycK1|2(vSwMCI3&^fJQf%5Od>V$ktg<N}OT{A~I}63bpkL6LIh0*c8|@QV3EiNV
z?vL8p#A+$qP2UrR$7iSSpAfEzMBf*m91vC%^}Qn{pzoJ^Tj={&{CordCQIdi9Q6Is
zA7*`@aeAN$cKW^_#Y5lMpTYEf9%`fQ1=x>1eb1<b#$aIB>D!0!QY88wgIxu3a70nx
z-!%#7dtEOJeaAm7^?f`5t2pe&@%`;#v%Y)6BbH6D)Au6!?Fsz;M@Odb!KjV)JEj~*
zpT6h$ob_EB<~I_3kE#(6RuuL9TXI0(ADwNX?|M&3eK-BnLEnddGwb^TctCFYe(g!F
z?-5MjSE4prRamm4Pv1|0ZcgJn8TyJu-#1c(lzR)&wBJ=41@!%G4-0*#;O8wk&pQ@7
z=sWILv%W9KbX7LNZhUW|-)bnRzxFhy@0;<Vod8RA^yzy!=;oyFROl-bedofrl){SQ
z_^y9yK;MVXve0*@$ECh||L&mgIzOBBeSPCV6YTW8<1w!9#!TOLo&tS0hb1d}eUCMM
z;RDWjoM8v((SBatzuN}eDcIB^adUba|6@zK{$td%0hoSXn|c@i?xb9t=`*xhb#G(k
zLzpr7@IDjkKe6$p!U2EF*hWjjN-D)Ka*JDKvu}H(A~b<m!-o{fPSyHh=SWd+{`c}j
zY7B;bw>(uVMqEGyrtqDf6Ipq=lTv+?YqCEDy;$7G{I$KHS_KY0*KaqL5@h{e`%$k7
zERv{SJA@|6v3`@P1nM{OC%r0x`mKT|T8{O*1nQIWyUR+yO;6ARkL97?2O%?AzZTe&
z5Qu>a{r(upERXt4fafgh*VjtFy8{ac(W@W!hue(b!tVq1+x>&y)dKx56RQ$Y?|=67
zTY$$)`6XKQzZc54ejU-hWc?N%u#jKP^3`v$!oN}2vuGM0l`sz|NBxdb#%~d#hNk+>
zLS(fZ>-UAy|C%CbZ>ryV4DjgHZyXuP3Ecjkn<GQ~K7Z~viGKV%A2Z1G!?X!xfhTAU
zG0ogx4_`3DF6>(PQ0~4UY1Xe|9)Xy=EFo#uPML{P67^q@bzK>Fog%ejW#G=X>P!=_
zx2HM(JNL+$=4bnYXPP5ez1YgYv%C3B)30yU_G`4aR$O7;YDdLmW#AeVkEhh59peSH
z+M+hv8(0GGP`JN7-aw9z<M06~B*^!X=T5>NXWE77`s28BY0*J6?Zq}~)9&R>J9xKj
z+CO^@O~acwl%{RlWu8QzjxJ=|G%6lVn~UPnw63(7yP#Gj)JFRj;Rm#-n|$rKSWrqO
z=PXw{AC*nTF8b8=Nq5$#OYr-+_yP7>=Y2$7b7tJHsR=&(PVP2*h~LTOzu!<hX{|4}
zcwA0XS)<yfl_N|j>D!4#%vr;)A$Ov$CPJ*s^mVIz#ILBBjyZgJ3ES(Dksg;@+##n$
zpkUM6&rw!&l(m1g?0@`5lyqj!nfiUaq)s{f2a@R$^Lx}$QVpu(MCC3NGdlZXW5!k4
z8ODt9*&U4;IoVB&8I!W>7&EeRbV*d>l6b~c|7%?YO5gts2o(Jj0xcTJo`a^)H#>1W
zP##y|$LGjn^btDWK^|kFjE;H5aeqyITvwj2#gF+H7{+bDJH+d?OYn_EUs#Ux-WdtL
ziTFGXX$I0$Nb``^Bl)UTi>t=}RT7`-N9Ahq)vAb$s@19`RI8R4@Xup^g(d+xp9zuo
zqsol;?@}aJK=HvA{BQmn?t=H9=Se8;|JDFStQ09wT=|um_w}%N!n&)~S91jKZ$t5b
zV#<2@sMQ0t(YC=eC=K2}L5mWiX>T-Fn<jW)GFvw7IAha{y#Mk`Gw-|7PJA-qR!tMU
ze*(p$Y3HwFO{<IAXoujnh0goI?{ePnIg|1J4Sd9S&qU8n)G^BY_|6Hwf#?fQA-&lN
z?8oPENE4CfA<aNqjuhj4Xv~h}>M(iVW`A)R`S)Ku#6d`3#eB9g|J%U(?{g&-|M<dz
z_gg+S^FBpc3^T1H3Et<Uc=GSL6WkBA(Y{0^tTcGP?2$mzwk4}g6TDB-n|7M9X-3{3
z_{7Zn^J(9g3-6cBU`^|~ojz(cL2a}+-n0<?`ztqb-f!>Dc>f|kV!V&>{?~2^zH`tQ
z<{>S?-vjaa4;F(*;&TSlM5L#XV!V%p;Gx|cChv!AFDu>`fql{mUU@SA+raxjCrjQ}
z1NV$O!4&`gQ^Xvo95tTPDb4|kg7=T0c<}yLz7uR1YNH*%j+D~iec}CqrhR#m+BCuY
zMtalE*kNdzk@tUnXy*N;v@gts_l38!rk%)})&aHA>hPw8$ore$;=JE@4&(i!_=xd7
z#``_#3BC^K3p0=&!{6uN^T%G`K0YTRjYOJ<6ytqp%#P&hFnK?2Pg(K)NI?LKTk5M&
z6!DzulO*p?1ov!tzYj5oVBTlYZht!{3f{kPGlOErgY;4BI@Ct{3!BbLgZCfO(twEP
z9H^%@P4K=Qp3OHs_WZ!mG$Ze8il(VQA9EFU#o9KFibwqZ!<$&su6lqq?HtrbYs{M#
zBJb~9&3XT-pYeVUK4QF&@qYWc3BD%i3lotF@OKA%{_i|+AD<(U1|rQsit#=Yf`@i*
zn7n_k%;GsUW^)iyJm=FS{<p!uKWU<b;_2@gplFQWA4bd}nD>L|+W;=Sf1Q430{%VQ
zAY5zmoq%FZY&R(l-hV?&1A_N|9j7);@cwK(oAdsHw+&4*^8OUjG?n+a(8hPWrU~AE
zGl4bjMBcQ4sEyVhJ3-L25PARLE1dUFU%+^OJ3eB(kMVwEW`eIS`oc)0$@seoKHtaN
z6*}N^AksNV6Om%P4~^N8Tph%FwtvmT{+zuO&pCnb&q>nv=dim=d4JByGXhZDS51YY
z@b6n)E1}qRqXCLW-X|2Ac|ZD~0~D!vIKl5;!=Sk51^TE}Fda}l1^a*i#RhzTPHnzF
zr&{RybAF<w0m1v4hNcPL_s6q2?=RnAXqu7tZ4geOa#Y^uVT-UE?|-_QHLV(N+DOz!
z>xF$lXj*rDe-2cNk}dY<G*I^EJiCPR{=Pws_t)Yhi1#bm{v4OhFP0m0UN&sdp>hlx
zbXKNUGHuX_XM4!}dA({g30QB?p^^+6bXZA28+6Pi1#i%yVhkH}D8sNphcXNcwv=Jm
zphFpk4LX!z-k|d=Ho!=g)=r{pu65f^RIWR8=DvnEhsC2W3_`jNf7iq3TNfqxQt+99
z)Cp-cQjGVJ5InSd!{q&?pO+QyTT_r(K=E*8{<p!u?>1IK@%*(0C>nX+V2zpg*_frs
z5oEVs`^6Xr#f?1Z@z`yEVjFChDGlEH#IIx1)a4XI(**B_<Jp||*S~3KnvwV25l#u_
z{X_VEifz+`fA8Z>+fT~~1+^w(u|T`<n{ar)@>$ONnL`-whvFl~d$|>rz<g}-eo<C}
z@7GJgcJzl~_&Xk-OL1HepPi6WkOm>ecpn<GBe^<E-lt+|v~2wQvna?cc%SeOexwk8
z8+hM$goNUys|-*y^1j8ZX5P=FJ^6M)58>Yz4QIR`^df`ek{m#>J2uOd2JdTQ<v}*B
z&EIO%1n<Y=*_`)NRvMaS<b5W>DZ#vdj`rl+HBIooHgDQ3+`pfJ#RBaL*zwT)`z=p$
z-e*G<*ngjij~MS`yubhQ1m7O?u}<g@{qXm%_<I3TJdRV4>LFzy#dseH!9%+@Oy2*!
zzN~ov9||%H-Zv;#p-4bRWPJ!c1P;ZkmK&gG<b9Wy%)Gyk_T<|^QSkl<91=Wbdkywx
zk2l8yika9fQyRQa#>#_iTKB_h(**CQ;@P}ucfV|CnvwTI5l#u_{c75iZ`U-z`()m<
zKdQ5)&BJ1Wb_3#cq4WOJM>y|CW2yz-cgIJJ_c7kj8lB+VjyYrs`a=)=y$65agY+v>
zJ><nBbwY~qJ~U=Wa&?%z&w;mGHvau(6l4~>Z}GDVMZx>45dq{-yyZm$6pg$;Z?T#8
zPt%@!J17d?*Ff>$eFlql*Lv?NKyfHG%ajK1Q?Cs)E%T7tG{O6OE|N`q`~^ePjJ&@V
z;gn$BzfF7c?V2WdpNitqw5!l2#B-j)Vu3dO{cw1{?|#nvL1++o--g;%d0ojjvI0EX
zJkBlJ9E;zJHQovmzt6##*@#|M5B;Gn{@#wiry}h^ibvkB_)NiPjQ5ccJhXem<o#mo
zW-lAwUjxTL^1jOf6^e7Xe}5}h_&M+Mo-sht$os)hnR)*z?a8-;A{CGI+LKW{pqPR{
z4xsqeC_wRAY?dhv-lxO2kxd&~q&7|PegQT!@TR@A$j~$+?{7yqC7Ac0(Vl#}rU~As
zqj)s!{A|{=<?y<+|Jxc4?+@R@d7ps^3wVDD&0Au;SKxhY#_z{qYW^x_jq&IYr{eF8
z_<KCkcBEgC_8`^6xft(5V|FB0Gu{vO=N=fb8QU=U`oDN-N(OL|k*oEBbDe>gret(U
zx^p{i5x`4RGJw9ibNC=nLlhc=JduLYe2~)%b}EC3_@(#M{ZF!81(bF7LXma1o^>ib
zQ@W~X3V$t6y11+8dVW0PX>tB?e%u9NY<B$x{J8aV;<zV2-j1LRJI~%}HbEOC%R7yq
z{{+(#cK$eid?F$tbeyyT|KT-33BdSSY@-cT_%AH+vNsm7ADe0_H{jq$?9=eO0Q3Vu
zNt9QBpJw&v7k4aNjU(SL&-?N2oHYF9TT@$a=*?`$Vj;a5H=oX=>t}|^GuiBwe`%XD
z;ybk^Qm4^7W+3~tqM`Z^-%rrau(-Un@$$B7=-o5Cfh7oW@g_827g6cShRf+-0%@G~
zh(Ij*QC7~WYm)VXR_FyKprf>pE2=^tJ`!AeNHATw@rvyF%2BUux}k%Q-OwS9Zs>p;
zdeI;05P3EFqZi~knr>pvXK!!Po3E6WWl?fRUUEm2JSe5(>I+e0tqUf4)c&;D88x9A
zMV72ECYt>7@urD3t=IYI`&;7z2-?4fUJ1kHwgvGs{<13m{uupNCj8UajbQuH1`*B&
zVwHbTN^)lYRvIk+<;mI;w3dRuCj@?{VgNsuzf<AIZyM34lXs>03kFdKqMrwz^jLAp
z8hWt}uSG9ei){ZI+G@jdTg%*>km{DI#iMTgXP72vwP}r?>X|z!*>}5I{I+GX%Y;;X
zvbG3aguR|}#PAJs)8Ir@LTZUL38_AkA89etIHdVVSxB>yRv`Im#L?EL8i9Y6=+DYE
z;&~3v(+hrTRH4JF35hjoRH{*}Mvdx`u<uyBH+<eVxr6$}%(#}=Wdhz8V|$0f`x_tT
zBvp8SI+jxjuKNSLUn2P}c%LUsg5>=oQA&~E{Uhj7R78>B{gv{(;QjNjiSvT@_dh6(
z1@FmCX7>x;uYQOh6LZYGp9SksO1!U*hOwedy#ERF4*n2NykBQ=xdZR#>6b^y`}6gJ
z{sp{mi^>uk!{_}FwgL_N92!%TwPm!H5;pH=qrWP=-~NQ`8!C|3%G}WEma5f5-6Zd?
zhc9Ez`{A<q>=1eX8mz3&`<AyR_<p`6!PgL<<B+N#r6J8n%0ilr<VTu>^bAsr_hn;!
z!smU5Y1A2K#x<PDc&}mmw!-`05YlCE5BT?e;Wz~G{!htg!TU3??U3>KdhW_}T_KJI
z@9#lhWakC%S3EC{1@Hg+fH)SsA1v*I;QeEAJ|TF2;B|hzHSbSZDu)~S@)7y>iPChK
zc>kk?!|veUzh!Z`1MlbRmq*C^^YnuL1-$<X*o=(#S#mlP8dH<CLRw1+oA>ko&%pbS
zr6+Ij@86KQq17!_OF`Wv?`NZLTl0RHEIw4;Z$da#=Y7Lz3BFxZ6MTvI%tHDNf49Wv
zY$QL@B&0N?aYzp!#dv?T^ZuM$IqwtiV!Yp(XW)I^d7Pw*fBzFYa}e+66bL>G-fKbr
z{hu;EBY3||@LBrzmkAS6BzS)*=EKY$2;TR@A}u=>yk9NL6TH9hZhqdH_cy{HDkcAZ
zh~$Tf_v!MCw|Gt+i_0B&ze^vy5%T^ay`X;q@2|TrQr<r=gBqbRHCa3B&PaH_&*<N$
z$XXb9f1Jz>t!}B>0?f!I?_Wlw)SCB8buTAG|2`eX>%33ABf<CatOQ>%k{^G6htG!i
zoP?ByG!CgHQWnx3NHN|Y?YtkD&3Rvp_pTtGvlSnTf4>mMp20of-`{qx$O^=BevteX
zyzhpIIOFs6+`m5^1D72O-Vb<O9ACiCKP`DKc>kk37QCM({dvLr(Q-XN@c#FiygX~(
zH$}9klz4wP%%62UCtIHJ#```NmpkzO1pV>|dH)`awUEWpAHV+<-6S&q{(o~tb3<cl
zvi6_pk?{U7q^!hqvScj`ygx_ghE}&!Z7F8tlK1ry*|g^UZnpT2P*$k^{QwlN^S(GA
z@3u$MkkYXAVFx}F@i`8uB~lhrLnJ@aO-M1`AMLy!c|8q@nQ<Dvo(bNsqHk#i)@$E2
z^M2qg4p$|9KLpzh8P5gpj|ZMq-ajnkH-h)q$auWqeKNc$cD>;JlkiR0vEcpO+2UC6
zzIci_7QDYu%m=J_f3FPUM!sIVUXD?df4^9s@y7dGEG~E8eP8|Z2zei;7xXXi@Aot4
zMiRfTE1?$}Q<JsJZi|HX3D^Un@O}=apWMi*@%x)(ZfJE&)!xF4T=KpzThg{#uWcZU
z50&>LP`u82?f>v@d!(I6E$1cpHsP}vDGPr$MDimgBBddXMT+shjCqgU230;-T+Qe2
zxRG{+$n82aQ>I~AJc++X#bU?K5uBAfc1Dcj7U0oGnFY8OAHo96VWnvI3jFThM0e$j
z+y~**5Ty4nRdZA2wGXMeErr9rKUdAIbC<w48X*eZBUWOIhUr=T;eRk=&{xme1fsL7
zE_zlKvG7oYm%WIxZWV^A2){ujvhETS4b@PrWE*(I1%Dw@6_^`5%1#Mc2DbOiqHJvM
z$>Q64=of^{+j~TT6BmmDlV&c&bz+B)IC-%=nSI)-woEdB-PpX0Oq8tbPAR%p?DP@0
zou=H@+Tpg&V#klTZ6B1t+jh#TWc%Cv`GL+OUJ#>ZWaT7_{Xe4Exq7j7CPlsd3i=UL
zHN*2ppzKwtUMrnt{Sd1?LCXR9u}NzS*}TFmdRbT5gY35l32DrL!^DJ~bC!ND+v3B|
z>-&W6OPR)6W8Nw>8pcDvwF=u+gn^CSLR@Nm%aJI}YR?e*4(%B_`%&EniK^|x+<@zU
zkk~dPPP{KqgjwfQZCO4yNut0Z@aJTG*+!zE2M&`D%nnybXXAk|QfTQ2f5&aw>O4F!
zcjJWN^!r@D<DIy#B7K9@XMTe39emcr=M<z4NY@}WLdrtA2PtN=%Eo3z@)Ui&n(W=z
zPex?#CR{<|U}oH$h0NX!#fQ<}ojgNWwoPn^icWp*WRYvIcWZ?W+i$RU#qc|sZOm0m
zcvR#T1?*j_2%ahSZj}s{1?*kCG?W2*cNU_s%mfDPU6%zSD`4-o<nk<Ad-nh$Wu<EG
zj@&2;w6b^qlP5#7ch4%fg<$U{=(m-sy*p7a_TOmlR-s3froF2%QRq8N+mWng!%dUM
z!mv9wG<(+{4xpHGi2*y|2HCfR%+FwXBFs9cYK0g!GzAk+dKb1<Ho?l??VTWN60W`L
zj|VFD?rjiCw|9FVPw+jB^dVB`1qr@2`1}j$di>o4=`y4wBtOzrq?o;n#1fUwy#{-C
z@ZpH;-LxUp`)0=7{yejHnfNf;yYbSp8SGsS0tn288SLFF*NR+&y;~&~_>J?s>u(YU
zDPZqPZWmdB`Q39^aAKA$VDIh{4=D=RyBVT3%KYws^2UI@YbLI;wRfjrGFhtj?hed%
zS%Fse?kagQG<(-Uxh({HcLZKHZ(FI_yQlSH|Bd$Uo~ujO-aP=niwQYQ+mWozMDSV~
ziwNx9aCCK}y*mO!%Jm;)?{>)(Vb(cS`w)as?A<QdGuZ?ydv}9;VA%7!;dr28?>?h&
zteoF{vM9lKA5tMwvu6@~&*Sp|(&hNOF4BLHN^qQp&+$kxdsj9#E0U)e>|M#d5!t)B
z7tuJF8F%f=%-(g!htb}>F;&<wgT1S48PDuHR$ObacLQz~xrX`O22rjuzuPfM7`K4E
z(-2<|vUiV3Lm9Al7s;%^{O$n+IoOQ>dpB9kC~fUstJ1c2O-BjHSlPR(@?>cC?t_sM
zT&JxH!QRc+Z!1-M*Gn(<-)Qf~jVoPy*O3KF=o>KMPF?P$xrz*4h9A!yi-sBP-TV=<
z+XUIWsq#dabxzg3#>%5&?@}?zl})g+cgM*GhHdYz#{(66w;!&pZtpg~nBbd<v<#{K
zk_6ww`1}&-0{mSG=`5s!IBtp0;Ycxi7l|b*n|lrRE~y|Qd-p^pw|7HVF?-hrA4YpO
zRBVScuHUsAE^L@#e%Bsz4>s#F*t@-Q)@QJHcMTH;DKNk5A|9p0Gk1>{R|V#GlQEu{
zB@5U)znt;~>|LQSvda41(;^URYwz-}l1!lQ?v%p%T?P!e?fkBVJQ<q3`w0!>j(SM;
zZnb_}soJ}dda?gTd)Ea%S82vG2f^=(Y<{<pZ5<K8%kb^pO)$Jhd$&4AcAFr3_k=tV
zw!J$jwv>o?=IM&bwz7Ba<O9RDcT@N#6S;o($90OmTk%SQFB|Czq$;l_`0m2zHl&{T
z`)7Q%#^=}gY>3bPNHKd?Ha07grx@&AqdOw9cgy<FIG7oi`4+Qxr{KeA?`Ga2Y?xtw
zcdeLF8TYHKlCe*Nz55%^CbNPDd)EakKg?_e?A>*8$`_d5?GX1C1?=76F(!L=1Zxni
ztbo0{P%h~O=6BnM@~dp^U0=EU!uB?ng1uWQr*KyDyNBh;(CpnP<+c#!cWw0BO4Z)&
z_*c*Ge!jGH?cJ7$=XbBrTqW}P-5pq^FxtB|vTE5u_U?FjB5ZqCf|0Du?=HP0&;%=c
z_f*95ySwo~Wqw!fO2ytivj)FMg)|rGH>6vU-atCzb$pi=pC{w<1AHdp^K7J;y^F*W
zmCe1(-r@CWEomcPDu0hwE83NYBkbU6<In$)HZP@W{opMYu`OGvTIY+U?-}2ru&6h`
zpjc8cCw^I65jMo5gxpDOe3KjN?|w?vPGw^dXYlT-!#mlHdA-`8!{u&lxxq_|J=gcY
z=()1Ki~C#Dw-Kh5+<|te?-j6XtR+#eZx$wmvc5Z5V3=ZAihT7bqLX}!E-0(|Hix=p
zeTQGKi!#t3et~o2D&LI^Xl2nK1`i6<_tb#u1ND7LdMHlv9SEPPZ2CiTR-nEmh&c#R
z2I_mSoYOniw<jVWrCDG03#OKQ7=fOr_lJHK^*!LFzIVZZl}&xyp?k{u){wy%b-bPB
zrT@N4_K`?eN_?=F?<?@bWqnKjV<F!;GCbncAFl0NR`s2W^(a~2o#-2;{yPy4qAMT1
zEM-2}%Xbr)E9-lY6(7EXs$J`Q7^Rd=e`u}r-$_>Etu6rKT3;VJO+@uwRSg?Q70Vs+
zF}*EPy+6cb{8Z%mTGc=aIPMyBe0tFFi9yG2?={}PI_UVhpyP+s<Jp5!YIC0i6i9@}
zl&&-e4vp@wkQYyW)D8r}6>rCM{y5C~l=EZpeom(c;6<Ex>VbxMdU9TTN^bX*8aI#j
zkBU#h8*WoO7nk6hlBw^CxWg*;bGQCg>~{!yt)jQA7Iov99aoXui`wvyX8hwc{?UMc
z)aF-K<42V`7NV97H+=a{f^Rp{_eh73ijhi?s^X!wkWNRchjcPh6C^J_o_dWgpXF>5
zeX6$ga)W$K=O4hFOOc=H{C;rB>HKXN`%dSN$5?YZU+D7u@s~N@|0Mh>r}BHa)c=mb
z&iCJajq~|5gn%rbpGI#5PDUTW7mD!4SnA8^S`$P=Ib!I=!@KDu%l`p&5cyc#c$f0=
z0_J32c1>bUvOjlHqA#a|HjP9@H{hqJ)9DQU^QUV^81s>x*UQgxH>YR%#D+awlaZg!
z-ie!@v|>P4aaW=?RZg|D*;_(T65deDUsda8Whdhop&x3!{-a{{M5XAsBKCb&>pOxk
z_OYo-nsJP){Wa9TW&gC4?-bq68|6ECpeOk*9$+coM=*OcwaZPujr7Pu1(NTXy>vMm
z`fpo(eoKpUw*B{QDM(}gJqt69kmdUpu*QZ=Me4sl+VEi~803KuuM_IbeE0&rKV<n1
z$3&>Y$#?R(x*QGtcefsjaqPeUJ;zeMw_O;9d`n=~Dx7@(!k%2wPYv>IsLvN2<?FNN
z@5wS-F+#5PZ2_Xr6;8f;;cHmQcO9ZEBHxL>y{-H2>nsN5!GBmepquVLj5@ml%J&0A
zFRkRuzerE<MaTY|2J>ja-^<7YCM>)4Usb-9dsaaC{xI5FzHu;I9{O*xwS7ARuP<cz
zF6>?b<vUmpVHo}2F6ViY?|sq{Gx}$buozf~{kQj76;Qqffq8_%zWoWodFa2xX{v1Y
z&(1nOjQ+d3YXy|=aLi<__<M7Pp6_Je#<RsIbW~&i{Q|u|WIp7k{fp&0*gyS1A)*N4
z2Z`pSe24?>BZ_q3o2~4iwP7lED*K5Waca1M7M0kkne49INvXcc8MG&W%HWHiS7c*X
zi<;3ZN6*-jo>~hR7A46mkU=k1DLPwbP>DJ1<q<FO%HR^u%TWuUXq>zO@xuY^?Km<c
zKRva|FkFFO`4KJ6%<q*b7G+0h{oqRS4%STG!HUS=s*NQts4cr!+?m%aHTa@t%!A@`
zVx6o&e_0I01M#vL1beXPD<qjCC#md*rYL}@7nq-p9|g)t85hW4KLv;lNL-d^h<rJS
zlr@eA$<wmdFVoxuCng1-psn)$Jh53(lqqkzjT{o3n;k4kh@m(6FgQ1toudk(bc$uA
zbGhS<RFsp3=+gjvrs8uDKG|~kBszniIpUiQGx1dZg!_1D1(_*X+D-5q_1Da>o|x&E
zBW-|e1nU*&$Rh-~617&{c)jMUb<R)6P@kFd1k1ZGg`b<lj<q=yHx>=I?N^r>tFlh-
z`NoGY0c`0(i!C0$Ogx;Qo0CGv+5);kN*%RKTI<U#Zky9qe@hT+c{;PVT;KR{s&x7R
zFwu25!2+jP0as;rHx+t*HbftE-Sye^OnDdNoThKWVGmDXQ2~DE=Jc*N2JS#eak0|R
z;k6=&H+^Fv8aBN20(qeZ{{AJ`v-qSnfBV2ClKRyiLw^pKIs<=K^w3Yi+Epn2z6V#*
zhQE7(0ayMmg4ZrZ=z+hN80K@);BR}P45(+~ZwcZLgp6qzHTuxXg|z}>kB~!xb5{J_
zK%E5V=Cb=rpTEC@Oh)MS*F7C4{yyJ{*UK}1Ycj8k^TjKFH+GTT!^q#Z;^Ch8+lX!m
z#-fS8ui|m)Rb|TGnk?#K!{3%bfb8cn{)U2n2mY3{3<y<geWvVcG*ve6ceo4<uxL+(
z;%`5;!=3_JX8*T0q~q%UvJvCm|JC>9k&vUo-<J{5x8(0sT5Gc5?``DW*zmVE`b9MP
zdlSfH<nNo9{xh4H?Zn?!?RdRB^LGvlMux`U4zemaM*c22gFoCee;3dVuKc~enenPJ
z<!|%$frp#@U!|YN_*+W+O>9FF7gOV^fsjrxf4_%i6s~cF^MB>4iJ8B9$>h87cM<Ef
zp80!oYh992;%|EvF0k@{v4z}@zemW6x8d)GRDLdM{x8U6<nL5Z@rUP6=k@Z;-<oWy
z5*mMhwTVBp6%Y5!-$rzUD}Qfh4iT?nna3YGqHoG7n)utY1D)jkJjUNr;_qfm^rTR=
zXZ4x5$^YE}_o#yMx1Sz$G5fzH9XI|qQ%snL_`~xCAxFjkW#Iw~{!XPuJ3IfEyc-+-
z_NHNpbJ61OO(2tzzfF<j!T(L+_43T$IpoL-1bU4>%m)y8&kyo{oAQTy=I;W!!Ii(A
zI~%VmQ~$U3sey-^_`6u?=P~}45`TB8@rSB%{gy2a8R8G$V<uif`THJbzr1NC{_Z7{
z@5bLn&8gFR_kWY+<DwORXwSk07W^&2{Kk&IN63q};qL~T6GxH1zk^Ih{%&a@gya~1
zc>XkAFVFm~sm!mv^0&LJN>Kcvt$4U+{x+f;T={!pdBz`ZV=k^;{1<|d{XE9sQsVFB
zicq!BPEpa&MBV>zqdrNe-F^x7`ybes<JA2REF+Tr53B%n{{zb?#r+S6BHHkGY+H0W
zH~uzj9O#!G{NF^~pCbOg8QK1aZdhhB?|)$70t^05g%a)fdmDK-HvH`klMzk+-UKok
z`Fnc07yh<7k=M&Jf9ELkYx=pU++vG<6}121alPjU`M(YM!#(qN0o~xr-}i#N<mmdp
zO^y2>5~1i-H?mb$?oW)(>xJ#jG8%$S5DS&g9)qw)2s^C5tztnbE^O`YBuOGdgMq(4
z>yz{f$KUtlT-PH0OV-Jazl%<$apl?nJs%E^m`Oy5zwKGLz=FRev;zu^oyJC(7*)Aq
z{{wmPHvHXi5<eHM_`~lYlaaqoYI))B^T+dgdFF3THdWyb_sZV~Yf60?`P)`J+%tb0
z(G5Dw?Dn6vP^uXH_-_z@cVK?t%-^PP(PU?j@i%h*K9LZRr}kML+0{(^y-}Z}S2+Im
zLln`@|7`;4xbe5y2>}s$@qZCxi!Og(X5j)0{!XPGP&WL%jT{>r{`RiV&qa&BH-St>
z{+<dikO|2#{?O_;UN6u5okNbiK%iIt&O;yI`ZDr&2}}eD%rk!%&<(EqO^P>ORi^&$
z^m=amU8r>S7=I(@Z#rCFY0tEabrPBQn-@THMT<YYhuN<UfA^BLcjND(+5r)I;O_xA
zIML;AdloLR;BN`-fU@E55%S_~_`88R3C=}}zrTY_M*g-cIqZSI&nNPFdFF3THdP7D
z|6TBps7i4BS3KM^e;d&auKZnE!+2Gh^7m<2ZWsR-9FV+-@i%h*=Bxhi+c*fI!4Q9F
zgPto+RW$zgLln`5zhfJqx4H4R85=R4;}6y0Oa_D;mH00U7g+FjDg~Qt_<I{UHa7h2
zU7eqc7JqL7nT-5>T?)zB|E<jH<(a>8$dM1x|4o%u3F7aPO8nuT`MZE_aOLlx)F$Ps
zGUacRYHs{psC4!ie<SDbMz-84;=dQ`Br^NIRds4qH2%Ja*{=<M_mZ`D<L{y>G-5pS
z_dvjsMJxVGl(GE&8?Eiw@b?IL@izS3KyzZ8ixz)>2bqlgeH=MVCyxAm{_n%AUY_||
zlTB4Z^M8+*RSDv6Tk&wu{B1-xC}g$%{&B}9khOAEnew*-46Td*3l7N69^-E){H6EP
z%lD@qfSt2=Kc#+tGUi-P=M(EX-~ZC@&iCI!gb2K?UcSFkfBqqt`rYhueoL|Q^Z)Bo
z|F3^@zW;8Q`)@pGxIgfI+uQ?qxdUF8Am6_^LB4-;f<He|E0L>CNi)}BiL7JcSWq;T
zULTQ4?<$#~O@>?pzH<`ZzQFU>!D$ltu#Sh>@*2IALA+2RJ!vJ%p~BcpKPSj{KHN#p
z408RfPBQmm%>5}B-#nu-atm>qy*~vn1I<WUnVHfl6DN>4h%VWxRf#Ju!R2XqJ87CP
zyBfP|b9!1_(Iv6~cG*AZQ>#&9pZ}V-=_h=|`!^<NgAsJ(m8Tc=_uwr$s8f%ASfC{<
zX-m4F-7l)eN?lAnm1IMaANF3+anXMrfmeODlS_AY`h4#%Ykh77s>9IdN*Wd>ea>Qr
z!n-~@L;oK1c?OEL)Mppji`k3dg+71RTk5ROow)9()#q@SC#DuVeSY<`t~dBrf$`bc
zC%ZVUo_QXh`zSbJ(&uYOLK~lBpePUeyd1?^>T@NW7Ss6bF9U?^MfvvQGm$ELw2sev
zFz<HM=W%~p>vJfA1!0WO2IRb$^!eQ%q3QE}h}45V??$nf`V1Hmg|~O<vwY|AnMRd8
zTJ`ysoFv+f&%a@+gx(C}^RSMrkjCeEY+e#<KkJk80R?%rpPL|35Bgkt*hZh{YO<3m
z`fR4R$XTD`Q0h^u&x4S!<M_PZ#vghE{#h8~^JX|5=JDBwoY@fc`5Q#)L7zXu$Fv-u
z0VAU5^Lu^$&sm@I$#X61@u~d2Lhb>)=`15<1YS2E$Nkr2{ayDXv}<(AP=Kd_@Lxx0
z^$q$e5&r84=_QXy5^q5rL0<CTvcD(InuaUMw@q$F_uv;6Q#NO$G=o!&8c63iRUF}c
zVSoNW!twb>@%OBy@iSrr+KK~Q&FPsCUn;q{X;gFkVk4Yi%@5NLrM7{Si(lhnPA=LA
zC$}woKKa(n2#%0m^pz-XHT^mSxw}a#2c@(en^!N<@Wc#yB1#{@RxPQ{!oy{LY*zIA
zSkL-u05k=78PL~gy*CmsUG&v&pC}|`ef4Dmve8%7A}4*#hiMN<Un{?N)z^Kv<mlE{
zjleiEjIY<QQ6|7c7kxeUUAX#sm<h;6UzhB6(w7F)9g@BhP@K#7+5=D=-TLw$vL0WL
zAb#LkUq9>)S6|;V0omy584O!8d)7QmL(n-SeGNu&F8b<3Pduu5xZ`VGFNX1ToMFE1
zGQN833Rhp<n1F2b^*e^Gy}o86LKKp|o<(sk`kF~kJgW7j!Qfljud`rSJddw}Z^G5r
zT}(hW`Z{-ylfHKHpqh7o<1i@TqOa|^q+Il+$9KiMhv_H0vJgO!;poG(<{JnHo1)rQ
z_tylw<o$Qiq%_3)t9}u<zqK*k>*@LZAx!!FR-c9b{C;?*yuTJr!a}V7bFj7Y{yo%{
zLcD*>kAeHU8pG+H+Fzp9|J%@?-vTm|_5Xrgxe)80us3l3qZpx~-ak*#-wnWesQ1@E
zY);mH80{?cQ2%l4oynLJu;2emr?EIe`!HZTU{m_B??Y1l4-iU#QJs;mJ%>I!t1xNS
z2PmN<Uf7pi9q(XHrI>h8BK<`rV;Vs(iSC4nN+(}VH~f^}OP^I`uaRzvzpFRqe<%0p
z_;#;VcT}gE)bE#D)yL4G4aEa;i{o-CZ|hjd3&1prEhNy}mOq7*Q1pN`C*V0$`2pIU
zY&lL@YG|qd#96P^RD5PZl^<u|nFaM59Hx(2$*7HXHlp@u><CmHAD6OuAPUL%chc(8
zSi)2M^lNASxa^bIXQk{G>@z;QGy6=;?p1U#RgDWVX~p@;vlI7M5e13NmFFjq%}d;W
zkkwXRnty&W^1cvx6EGJ{rl#PX(Q*4XAy=1cnl9HgWRqOeP_6E$Rd+7e-#<r#kVSG`
z-iZIr<vN$k^|$F#uJNB6<cb1@1?2ki4&LG{U9MSLJGQ28BUdUOa(w{BL#}WAMjy4t
zp*Gq+M9;B?QiByv)6=qA5iubnq72D<%kgp-25!Kn2gb{NfMC#gxn*ZK<7LVx0lj{H
zs;XBpUQV6%|Lk1}d{oudpM*pL5+|b3xQ`G^6txks1O*)`=tHB8iW(I)D#a+aL`^VK
zlwhEehEcSr)D?HCR&gl=su&O@iVLDuwEdL2-s!l|x>2p<`~T0qZ<(1llZCKo<)@kV
z?t1Ro@43sf>AF8UNGUJhyqYX8r_j=AiPA9$A9-0aMd&*C6QS$6zk;qognU!T%e#hq
zwtjhe_6--WSMKh`tC5#yuCVd?+Us$6jhB}@S0~F$E8L}&cs24e4$VVe-iZlbO8|{p
z2*=@vE-zJZF8t&r0_QYAUPghJI&NQ%d)1}u{kwYUYUJgU$u?d8`&t}bVW28pJ^1{p
zWO?a_g|n1&HTLCdG!MFd{e{rAc{S+z4#u29ULG~vv-Qi%4X?R)Jz*CwUX8q5{~H^x
zcSF^9^iaIKT>Nsfyu2*S=IQOr&(J*Zdi&>s*Bn5ju0kmMhb}K~fkFJ_rP5ssM9fqC
zv0YHK<MOiSDwnR4cJ|WM$jg(L*>rv3l{mV_%gaqKCd<p$vV5L`u0~$YMDw6)zn|fY
z#*y4vFN3ZRf00sNt~A`U^~=k+S6saI*~yDnBQL+KweeaFRg+R)e*QwTyxa~0oKg=N
z`?3w12VP$uBzRo|DyvgI|KZEaO3WGj<mIk)PP#2G(U&?SFQ2~P()H*ay>vD55}9bz
z^%ivCp=-RnT=0CdysUr&kdm%OUJgX_pz8{%<4A4=pixs0w@qPRPB7fF^~=l8UUKpJ
z@7`X#8hJUm#>VRis2UGm<LyiD=aS`R0@uJ(`ME}3UauCsPN4e`$({Ei@Y)YN^Fy~U
zlfWQ;@{$7`oZycwTG<(SS@N7q*Il>w($&bz8JE~}y$~IE=o&9Chpb4Jmm9ejo{FwU
zUN&4TbX|yvKImEuXw)wdY)T<7eGK<({qnNSN*Axof?m8DdCA7WbsS|!s2UGm<K^Yu
zXOiXRa75Em;?>B@y%z~y&srmRt$iMN{TgxXAG*9u1iJj><sa_anQdPhS~?>yS3m30
z^`E(3x*B;opvtD}P;}s-YrMSlT%Ig1=fMF;NmnB;FHI1-uK0)0H2`STUWomrke7cO
z?%Dd~<@FUVUa#xr#jBB*zy8|B>-*2f;Wb`f9$l6!FTsDO!K;y%iD({nd%{}5s|9G(
z3M?A`(B<VkS1!OpZhUNh+?uk?Urq%tb$tGE=F=`+7x(ni)yT_t7us~~g$`26%UjLK
z@-i3>KwI*18=41QPeEV|_GQ&F(DgGcjHZy6WrlmUetEffxr^6xdU)|_<mI06HeMfp
zIu5V#@^a-<$@20J3~)-k8hJSq%>%Ek+8-+bH0nkyvi#8HWhbD^&%R7eUVqsaywq`d
zIk4HK>+iaI>1yQV#q({t{(Wg2UE}S`{ZA&#OLy7PmVUnfYcvnKE_{bSxpSWaU7td%
zJcYbmXSiqUmzRl4UAzw1#*0@YFEy1mUZ+9Tc=S-byqxevvb;PD;<qI)JE3{t^{lrA
zuL@LF=V5K)hb}Mw#xkIvynF<oH(~zrpCz4<mkm$2bUiK0OIIT=w~n*v`XD;+&^2CO
zCM`~ump9-5q@=6y#|}gDpz9kUiQ`lO8g&g8xKqf>Ifi?-et9`^iHq0FZeF|^c^Uaj
z8?U3GYCL$2mzO?^lI3NJ>?BK}hm3vsaID~U%3gxkrYC{d!C1Keq07q)SkU&9m$$IS
zl^`$A{iQSV^3o!guKQ(p>1yQVSLfPvos14Vbd8snqZcO2%YASF+LD*;&^+YjK7tX+
z4dX|h^>#{m8DO|)>z9|E{^H_wb!)b)^~bI6=bvNawGgVtgV%U@`S+ib<>eP2q`|9^
zmj!1FUVqUfc%88rc<ugwKYV$)4r?BM@^TfX*9r3Sho;WR%WVr>x_<MWm##)$hE>>f
zEky?&y2i`Pu8$|n%cXDt+LD*I&l0*`N_Rh!n+IsrPZ2{;VP7&A=w7yddHHami`P5<
z>&2_FFCUy~<Mj&+%7fQ<d0F<T9<g^n%wE_tn-Z@^UVe+_p@;V3^fZ!N4rtUH(7it(
z`%+{sso?&}{SY@5ai|V1uEYK$Zel7{nJ_B$uCxV=6#4E-v-j6{+dBiURC0UwBGqp1
zy+=CI-nUrlPi}7(+OXRj$@R;2!}kfc+9bF49IT1m-fJBi?^56KE<`}wZg2k%!FN68
zhRN`C!-URmZ#@>L+CScYaE+4Ndl*X4Zf_3Pv)YZnGDuZ&dqc1oVYl}p=a=nn?>E3s
za(l-=?6&tlDAxY=njZ3NZ*O?lHhiCV2!EH^(~&s&xW&USr$9NhAHJD@Bze5qFvvE1
zQ`)8nRao(gaB-dptUM3e7SE4nXz?xPl1nlP9C>Z4{@Ywk*@*hvbFqIT>ep{1{NK`~
zZbbhxHgfzsBd)eF{qGC)u`%`U@mD$RrvFP&Y8%u40&Hm6nEGKZey66N9JmbQgd{fT
zu9981>f*<YSji{P-Z6$OtUj~VvwUxTg^`zVeQj}TO;7A~4z;$nPKouRK!h8^-0>X3
zV+g-Eu!%JL=xEr!U<F;~sN1l9qlNegDP`5yh66R*sh3DMy$g6a3Zg#GuUh9yYk(99
zRwKUt@e%foNI6_R6dM@V#Co#6-NeX&&A1)K936d<dWJdrzM}f&C0%{8)8-E!{N4bi
zDI-q6?>HzzlaAH1uEOtOK!P8Bd!aW6Ice~F74?rnRRVrPoSpjOcP?1St|a@NHz$4{
zo$ufg4!q01Kef$8m-6r1aB=+b``D`<<fOrGKblZ~{0?Uv%NM_6s1!}5&5qv_?)S&9
zXO~_V^6wS)9J4xJKkVp5P8$5Kp#Jm6??9?{U;Os5iMJ*6!#I~u<M{Uj+kNU%{@oL-
z<j24B{^UVU8vLGT>*-|ud(0m_O~mP6F7Vhy+3fs#-F^Q2yDKb7*X!RUm~Qyt_a8Q2
z+BXfPuy5Vz!us=XE#nZr{2RsMy<KUu<M$<aj0TT!{QER4N!Q@lTs<NF!<F~?<M+^c
z9^|Cq-}~Ty*r-adZ-4PN5y!v%?{F(^cKlAaN1Wh4oU=*r+vgsC{2pzipbh>#%67t%
z^}~D!qCfxUVTd+SHamW|v!~?=`0Zv-uQyu%dii(RUH<rOwe@Nn`2C0>7JvOP$E#xE
z__vblaHi5`$M4hbJR(j%46(xvU5ejx?)1lRt&M^<@XHvtjj9Cw&<jg9lEo(C@cXm7
z-AbDszxgl=e){*n0JrP)ZzlABw3^_bt%crjkdsFL_Vc*13HW`(X6+>W&fJpzL$?(E
z*<}xG3jE%AyFY&Sx}|;iT><|i1^<48_^3moIQ|`EbM_|le@EbEsDg&kg?aWwxrkGH
z%$8+pj|-wOwXeAi@Fj;X<Q!{z>L0w3^}oDz<NE*eM%J&{$odDTsXuN6;xcgruqdQu
zKzxq+C3Gf_Q5Q3+gE&vXWQB1gdqiPTtS3r_TAT6A2v7MC{9Z0Gnj&0ajWh6arEO7g
z0qWtNT--<dC{#PrbJ<Q2udik^aWAn4*(RuMbuJQ<c0AY9SLw>}yo<@v797trbGvvv
zy|?UmzJ!kJQu_S-!7WOkeY$!)7sIq{L4G@linJ@`=T3x>Htl#Evtlm={p3lE!8ImH
z`EPQGJ5BygP+{rv7hRV={|Q7T)75`0-dH8US42N44Sc)boIbxNr&MX`$8JiWzxEI5
z^FO9Dk*0kG7EYJHpbh-?h+l_F!q3eR`E>0MY-@aN^nVS50cpm!v<>>6!H{^G`uB3m
zkS6~j?0ZR<UmnlD-uuvP%O0>=Tj=kV;bN8G5*TiX;GV{`2Vl8_OG*pN4_&ISu%X%4
zSJ?2<6&UA)D{TIji9Lg2#v|EBz2)6ng2T4l^l``#duz!bX2)$U!Iqst>SUO(6#==m
z#&$A>FJevHq7pz&G_Z(0L~<|2j~dTVSEro=c#LuPYq|)jSD6k*aA|2gMi%0d&<<ea
zxeOO02fyiqk)jeCBUk-C86zWLG*V&Y)4_s~k2FRq(2+WoTi7~}5y$lgW%Is<(_LDa
z(>SWAZ%ZS-0)Xd+;YD$d*pKCZ#E<s^AzS~JQ-4&{H&tf^0vR<y@=k^N<l3)WqpNxI
z6J$F~O)`8DE=YoG%c`y11YDLUHD$hWE^Jq83mpumh2{G;`VL-QsJ^L+%?GFRS}NT3
zR2-NrdMhm7%PFkco@rw*?}^?9IafptV!vo^5Zcur!jP-C`u-lGWc1cGfAvb~f6)ij
z&T7b-J~H}`YvQD|#9WP1AuvDO2>C-hmUBgvrF1~ZbJ4N)Dj_xx<#ve{<)QN^(Ye=O
zhb?i-p}G+Xy94kFP8#dh<^}?oRTW>snHClA&=^pQhIJMb^lNG1(1sZ-&DnFYHNLq(
zC}2gVWz=yvBuC?@K@Ip$h&+$LwOm7nHxWr@y}v?bV*^;MU#xFJ6OA)7W}pd`Zvr_L
z4a4`BSk@-I1=-7C>7Uc`-+gc|JHmhO&DnhXch@YJ|AMdj@ZSjs+x&NSBn|)lv>}=Q
zX3|F>o7fj^`|#iAgUERKf4@QaFCWmT5pZ3$Apc!(V_N>Zp1}z6@%M-S27@-yS0QBW
z)PJi$0I&Y5Zx*kl0&&l_6yU-@{rZk6z&=;I40!b_9|nA7fX#qwf0u><ANp-F18yrT
zlIa=nVl)p1eBd@=z}XQn;L`{{Y&Hg5IO>oD1-Jt1P-zt4j*PZ!Z48)J|Aj%fj__X@
z=02N^|L$yb`ER?IeE9G9Vw?XeW~AZ21E(ePUn3`3Z79Hh|5W(zF9ai!yCZ(o5ty59
zLH@fB=ug9cvl+(STKP|+xW(8%2*;yE?QRx@i)~#UKZ)>|ben(U>;K(|T4(FuvXS-2
zbh3V3ZBd}6Cy7+7_U6KjJCQeIw#SPV4s1JAr^DvadxTdeF0uG$4e~L~1`DY4B+j6(
z)?k^Ef@ri*+BiJNcyJ+gm~aT|)HkDCVs;VyST-4Itee*j4)og0>CH6-i{(ogC>&Cs
zPtgUi1*Iqxuy<m&o;|*D5x<1_z-cfQ9r4Fb1i)T>gare@*&cJaq{HU0?{rrkO?l3%
zj`qw3;v@OX`rGR0mHIU5=yu{TVLtF*#*|X2BQ}ruz`1B1z5MqkQAgKLgF1Q~p}Nhc
zj*{mCUm_BfMjd4{5J++~3@`qk%m=QU-ZB1rb>`;dzq@!9Gx&yA7Pmg@!+$^D*XF<D
zr>5b*y)IAYzsZb=w!wez6$$^{(jfeo4`|dNFu)e%ztb?YPQ!oGZ}{Hv-!ULuNBps7
z5WuVdHtl?%&Sk(WmisW^(x2E2xax{D40zk5WCr|Jc7Uds4;Te_4w{DoJpEc>z}dKI
zSv>|fVzV(|@_b++!cl1$Fbm=Atxf@^wZHvgP&&eYVNAI<8~@#TxyyeWmiqAD@Issa
z$|k4bzddV{`R_Nf!!SMnz1vs#ZzaLNd;mXcAVTq5kpFH3`qS{=G(=aoTK<do=X+hR
zL4`lBeT5Fr2VO9u*4g?qH?n?dhwF>)j(sfr?DC4NLWxFq#{-=BKyX1;A-wB?xP_I3
z`GG}yT_*Jz&TjKd5<4nadYYGbrKd<Q!#%c#Ej_(2i<2HK!<DF)F^NuEbYe|-rk9~6
z6!W_uiC{c{AN4*KQE_-XQ~bV8?$pr(w)Is<$6H8fjJvezNuTjPy}Lc$K2Qjr6YVnI
zci_UO8gBz?V!XYH(MaxJKE!yxfUnzC<Mr%yGlRy2`4n`ZcTcv9+8cN;p&9+^C%mJ-
ziL=B=e*Rwe=nF4R96dhHfz?d))x}y*mN*L+CF(?pv10vGH}0;;vRSagl05}A=gIZ3
zxwU{o1vM+=YktL0?w&|lZ&8yt5$gQHq$3Z$`09s9eFyOM67L%{_`35iKKS~;k&Z8F
zQsC>^i<0rxSK=J0@pZKpolE7q!(0nL>K#B1R&w!GjSh*gBQQDHH29(tY8P7_Ww~hj
z&0;T_)@Zg`;t17?)hW<)dsQ-;{tG)w{zzggHVd{oPfJ{LDY+|m=}|ya69OY$A#s+o
zU~ScZ+)*Vn7?9X(Gk%c|J|5c57PBWWNr8`RCM4tIWA5=ugO5|tEQEO7k%Es$@T2Bo
zw$l~(7%>BZ9@+DmjG1yUO3l6kn9S>Q<T1FQw6Jo9m1U<_HCTC31;SwfRgkF=))G--
z1YRq+&l8a!etu{H^iBsP^o!Xpssl}4RAbspWE_FdSLo%~6QH=_^|^epr%aY(L%&W&
z_vI!mh7!qNc46~i!S{C&lz(@(pnM#lQ3u0m=?at^P3Hfz+2~OT3*P~HjP)#!S1s_N
z$72OHJ(fY@Q_^GBg~{~zgj>|WF6rno8qI_1kv|AMUgz@oJ=iR>$?1Xp!)*x2ezqV~
zG#CNF=Ag=P4QVBWMG__CeQ1UbP-HbH#>R%d{kRWB_TJg1NHJPYNs$c~Bva&cZi;Jz
zBFlCXimbdvC^7=js2#4`<P_PA^mqyexC8X~xn}|YxW|0xac#a$kGa1}LyupdpG=RH
za1z?0#{e`B33-5EL~<X$2K1<(waMvW`|Fhiud1%LFr#LBd4z7wlWjQr$g!<o%g6Fi
zL@xmZg43JmLcpW6@EeG)Qam}KjUiX)gcWtNp9mFVlijUDV#ceiM!j_i4>+n&1amXJ
z`HG|1uw}Lb9U{G$O+z)i={~c$A7*${MGt&WZZ-X`53#r?S-LZ>hUiT;Rc`O5Ap(<G
z&F^YolV(vr0kW&%59|GwRSi?$=N27+Xzy*RvX}OOC)wL1tslhJiQoDrRtQYqN9vei
z$<)$h>CH}U&JM>N2qv-p-}zo%y;3i3e9+tG)i0nPd~}D#^0IN7SH0gE+)LuH0M^gC
zvUyn7-=cZ&>NUR*UR`qlc=ZizYJoN%CF7*aP}SHV+nr``$cFxnb$kKfC59x<zNZqY
zhiWBy-;>NlEB$8F{&sh3N!?oIX$}0@&dJjaoX3!PH<3IY2FSLwJnh8AIwMaf{K-e2
zt`FMsboY5_<muvbljZ4U7*!(_$=<4wr=OvD$kR^;iagEO5At*s_Ims%PcNjGC+?Ec
z_Gv<U?GvlS*(WA++&+B?^0@M(cWbrJJ{@^wC*)~X`|Z=|fXqjp%vw{&43r*MCk)gx
z{ak^{xZg*hM&K(Idir<b*favQcSW*5U4dN$Z3)x|+loM)Ia~y4FrZOCyXr@QdSR=T
zr+Yx1&dJkPSiJ18ed>TbZ41b@xIEQht;{x1kKF4cPhaHN^3?6@H1hPym}Gf65W6DU
zlBes@JPg#;1S69B5ti1}hX}d<XrRPC&ChTg)lR)Tp-jxb0@XT{jK}WnJF)eLV_e?2
z{%$XCoQ?SnsJ3Psn>Ri>)0a2OWXkpD(==~*7Z7^Gn2<M6BH4Li^Oy`=hUU@BImZic
zYzt`A^Vk^CHK85b{>vP(tW)^8>}VH1HFx>orzzXU&x$kB;OF{NlkxL!GucdspHtC1
z@N;pc;3qZ;__@DsE5gsIfXLP@C*A3TpE+4Je(r<%@R>|%{;4TX#?NXf&$jqy2$~0e
zP9PYO+?80fP`|@k(^kVjLjaMDpM&r4!B1^B8$VZ_o(4ZBosx{7N3nylE&S|)=7FC+
zxGEj^d4Q`a7r^FqEq-dP#+ik6h)t-R@g{60*Ccfpzj~Tv>CjIm14MR$8{>FeVjMc%
zlAsK62C+3s=gQ$HeUeG{WZ^K=9BL?(0|&7%p2D&1_{=S@1@f-ZgHu!C;IvCkASG-=
zYc-BSDJw^+G%~VK%rj#d)jRVivwC0tbgMp;KUvks#?E)(F*}=oj&-l-ZeG|;#<ssi
zMy5~3Ziw$iqrg;RQ@328>01$9iQIwB)0;(qw|R2yO)kO$a_$uT>up~CYSH?;0AHHW
zzH&dPAdmcEdFNaQ3P#QTJz9g{z0ds@SSWA{C2MhZ0xkYnK)9^*aN)9%fJtRxTMoFa
zdvyGU)>a9~)H-%<Ym2wI{M!e*L&CoQ6a0H6R<V8g_n321@bBq}`T6qi-_PqD|L(%o
zUc<lnxA^dH`G#!6zvrEto_`0Nkj%f=z?WzT|9;NTOGNS~%dW57=~!`9BQE<s^6v{L
z{x9+GGOX|V@^9l=Dfsth#MpfKcXw!P@?l5y@2OlWHvD_iAAI<C&bK!I-Ur&G)4v!0
zBAI_*miei%f<9if(Z2)H3HY~EPSNE)gXK~+4J!@bKmGf_vHwf_n~C*sU;bSQSJ~Hp
z_!~l6zWh4|8oM+6`v)%M8vech1|R-iv)<<4kIK^X@1v#3{2PQ9&<_232|A(vl~v{3
zZ2YL@i0pqa__xdE@5Vz8PCwW<s%6d<2YuZXy#^>zRpj%noy&f$m$;OEV78aigR^C(
z|LIpYrN28aj?&m9>Dg4X@@P$F?@YgF63LumrqAZ#BVL2%LF1fyfDy^P2+*jt@IOG~
zqjlADWqr@SuAt2FTvt%$xvrqhTvq_k6JGQxy}{^YY&+?S9jNI&)A)G8CZ^XfE_Uhl
z?R7r%I_yiEUdKXfdMryky>=UwOt0G7w(0fG7ecSvONCxbF9N-af#t5DS0kpgKQMaT
zUggs3m}`CLb@k^qy>2}w4ZX%6l}xV|81uH|>!)ZQ@-=Ug&}(}@qw3%vb%tJY`Xx@j
z7FGV>==GUr8}QB7_|WU^f7$f<1R|7DzWy>YnO+65jW@kMoPy>-uQhr*@Y&oBybAt6
z*U;<y&8H8$!2VTot7w%K;UVbVM*yAj^eN)0G8Yd{e~!9d5>K=!2`wrN(*d_d0yeGH
z0~w;(P`y7)Q1R0B+gNj8Va~caC%~IV>)$=xI(M}-ezj$F+Y$FzEu*_*;gd9x?3ojD
z#QBl<uvJ$(Bv4b%mi!ysE?t9V(%_+{L5WC}1s8;e6=t}*$mH@Nxjs$8Isi7|8luwQ
zYc^ysCnw@%$<OEjMDkbu(`L!jpd~ykiC|8N+8Gm!q;m|c3F~_;YNCOjG5+Mf2YaIS
zM=T25rq69`mfbRm>l@>+y)q|=E7o$btbTdVCVVTXHCl?(=qBxu%X9UUDvlm(ClAYO
zMS)0;^N!GFz^)v0QZHa?P^urm645UZjFi`5>pT_Sc2d9bRA7nd(@xen><_bh_>+@b
z#Z=P+OGK}8vOe@wnCzsk^HgAo=-E!zINXF~_i&7pTE$em2RuiMovaT%6?Sz}*Lf<i
zM6?yu*MlC1@0Zy<M4i+srrJH=Ir@^5HLjOifp<gcW~!KKSHN@hRwwI2Plc<T)ODT;
zED^oX$r=ae)duNgC$);Hb`N-t9_nP3ZRb|l$4Nbnsip!;M0+|}t2`CHfDX}Pc*|3P
zC8BRSS)riY!_!XceoQqzutap8lNH7%;_NY8=cFFZ)Lzot0W1-lq<dbwGt#>YpU2MA
zN&jS$Da!2FFLZidfm?K_PTG}8rYN&xg}S9ZOg7}g$;NXmTe7#hsB3y3yCb<!lYbn$
zO~4r;-v5yB-jMKqS;G7I3Gb&SypKwFACmCCZ^HX73GY1;-v4v12i{U{FE52TDwyFp
z*i=*s%U}f;jONYfygcOElZ+v(?oB5!+!)YzUxXVnV%ti}iU3t74h*F{N-1b{`-{8z
z(sa1c>F^v(@wD06xDMU^-0@)mSa8A24XWR2?143y9BYV`S92%_!W>x50<3;W&jt2S
z3+$m5n4x+K$I4mNThwlf+mOw@fzp?`IZOACj!FyjX5ht!2v?ytJ8(5*cpRIKFr}xg
zJAMzoo$k600jG5m0XT?|H%=d1FgU@&ncOm_(Y3KCNMda;G*{=~zip4jCe30J%8;}f
zh}z;ye>s7gtoa$SpF3sGI!t@m!l#G}jOJ=rX`!Y1Nkp|(R?0$9`uc9#5FS8WeRF(=
zZmkh`J*2At*af%(eI)|?26jZa0LylB8OTG!QULr{Y_AC}Y#!DM_1pzeyHZvEajn&u
zJ*E==?7-y`2ehMZ5T{az6V^p_6uG|E3QPgRn3!^Q1(ylw5j#n8UC_+JI$%+xQ<PL=
zi=B@zHo9dS%P?S)V*F49Cclv?rsYQcVSq62-$Z&qJ`gZSJ`jLU0q8<#3Tv~2g43E&
z00m1}Q0N|97#K(YUNZr?5^w0sX*`DsIBo_WE*{<le+_;u&zpfUO4P1UV8|W{XCB|I
z?v5Wg$UE4zSA_XhN-Rpoj<b_22M=)FO&=-nz>_;Ax-X2pOkH#+M!vVSM^sc;17A>2
zF%(+Ad~>gOCh|k+xGlyHrysI4@k39{8aEd|oINC&A0B4Rbj$O@(6L*LAC4*6n)u-x
z#B4SfKO8?enICRv6l2Tt!~W-NF@Biz^R0;={&~da<A=K8$^3B5ky`~n>|U|O_~C-^
z*2E8QfkvB4KU5u_%nwr-1l{ubq1TyPj2}*e&%gEflh1=jn~NVRFnLJyCnrE#ZUKIX
zn+jFZ6|d6Mi5dwzRLNZ87)f^>XiN@x{!_eX9OR6jLLf)aA6UehJnW0PRrGD+`Xe2i
z5x+hdBL>Rhj!V(BlL?e?W)e4|nSssD+yV7*4L&w5!ZoidMX;f?v6-t4VNMi^)h^gG
zhF<ii0H)+gXYTaCbneUz%HxM-nhPRuQq1<tRVjDr>QB~TEyL>8V&TgfXg?f1R!<P>
zmv72I`{tt8WydGc>!?ASg<j`l4@wu(>lQ@T{s-vw9Cnr^$k&YnHVeHLVJAr!((7X=
zivIz6<^42?ULO^27JBu-PLeL9*9JoU!`Fuu2PDyJFi5x=?ANK-Nz#S%I*w5P@aZ+b
ze-gc}0tq(*z5a-uBwa|a+X(fRqnE62B;OzA2F?2;Dy)O%MRc7Izim->a(|OV`FCVm
zd1IiPxOwoOu*lPwX%(bIsFW@hqpfhmMl(Lm?IF8pPq=+y{WjriMC>*ZzRZn+?*&8>
z;HhsEd=}!>6@i*;S@|YDfB;0r`Heo$f|-0zmpNv^Ot4ug*sNgTN_)wyQZJcBKQRt=
zLTh<)I<vp{sq($$3dZD%F6qUdi%5y$SWhyUP^Flu#X=t&GA>t!%w=ym>Nz^@4$J`y
z#6_loy&=QR!qQxPp8l*&8zbtkApwLT{pDaYx|pmN>fuX&7(VD=Icvk7Ww|bUOu=6c
z{YGL<${p~=((mg{K);aHt=XoInHgb{(?fNmJMW<)2pF;=St5j>P!D`8(#`$>P*Sr*
z3VK#rjWY}R84mUG9zY8u0_%^QLINvAs)?vN*It(@Ev$8?eIhKiA}lfa%yoz>%+zf}
zUNPk?6r9FwBc)h$Vh>CY1sCM8=_)k`vgE8ePAlX`KlFn5OnHWYk9I&CWI!ufyq~ng
zWv~bOn))?pP}kSGAhvg@84^2YyN@2OyIjWT!||A`a(*0ES0NAvG1^3v);95d*6zvp
zwgx8RJCZe=NcCb{j)CIFWxZ|~hwj-JZ9KXc8g!4}w=Hy^?4bLZ-85ugbPw&53f+AZ
z(LHYQ;h;5XybH`t^f(9MJ0T9b$q+8Ld~(kn?hFuv3`>pc&jNMeD~Vy`sLG#7|Ni?(
z#MC=?sKQF+wNBo1Dt~~}DLYa%3o5avFKc*T?8%5_4s1@Nfek1HXel&&GM8yXr(MCr
zx1qE3+oUUaUp5*K#CTsem-rjAQeKz+0^39FoU<qA@n_PM9uTLTdKHRg@gWHk8x<f#
zvC7^%Y2?D6vMIoGKkC$vDKA#z>_YAW(_(Ts#RQTxpDC2@Qc4fGY_2IgM}CbO`J(t+
zdV$5da(Tb6TSXmAUCx%1piFJ9+6~|B<f;z9x1Sfjrk`wb_*xNP?Ff8@Uib<&J$z?%
z48G+DdEu+wXOrXaDejPIKYf??_rkZPaFfHgR|nzS#|vLcSHq`eadu$~WfFo~rl!E^
z5r3<gq9v1FH=dv-rxiAvWK2nB7B=C9k}a}sYXPLsMY@_aKp>asa+$gU_7{>Jwx%v;
zpB<2Fk3W*Ef0E&U3iGTkf&b`3yzno9LE8lI+xk;5NJXhyF%KjB#I449glH2@3e-~3
zrc|akp6X?mZ8gZnKzRq1DNx>qK6T;!#YVt8_*gHzr^D)WPWg8P-rKPor?dF|=v*(n
z4}>-cyq{qYO=saf?+h=z-|n?J;5~dJ;O&0A7v5tw3%u80H%@2q+wVLtyf^Q;QTT<A
zNPiOd(C2XKQy}3CdBI-&EDJtlo=0nn7ba!lzcTDlvY4mTxRJM5eO`bu)yM6CcFUtI
zJX0x&j_UH@N#esRi5{WH%R>jww-8HI=FUlNQ$wdLzj`O%^1k{7n@sIbYj8$jsRerm
z0<-v7rdHySN|0~m>Wp3Go_$PfQpA_q*Z#ylPW%1QqTBu+=naTU-M)<1IL+nq8Dre-
zf|=rI#D<{93)Qv-j{P)gMe0VAR>F8*F{xI`U=g-ZBBr25p@CT#P`QW9M6K_?Hv8WV
z2PlmFcKW~1r1|%MK1R^){uA&^Oq|kG2Xv~ed=R|<TI|7HGt}&vm{wSY9IO6`!Y2IU
zOQ7<B_2_tPRkc=VQ-@@n%`#>WuEZP^T*R%ct@(HC(IbEla`y5TwNSJIoNG0%AK1Jo
z8&99#kCtd1`NEd?Y(-}4ViE1Es2gBo(AF;pKBp$_jr@jbg(YkTb;J0z>q;8xGR;C=
zcBO)xfrCGb&@gxChL~C!$vykG+u$d==ZtMoHvb6xAhdfsV-R-DCny8xs#!oXkmG$8
z-+>jThbNAq8j>W~c_vwr5joAQ$3#IHPK0B~dg}CSR>pyLA|g=9iP*jFCbFCPz-gd*
zXM)8?wFI**Hs69|oY?~o_{4vNgwM=f#b4yj#V`N4Efw*R+2M(Mum&4tpHc&`Kh5fM
zk&j}tkS8}@Wv{LSo{+H?8MwVVl6^1{XA<lINjqeg;F7EieFOr$!S+#5*)^{L=Iw-3
zHFxuL9?5?3DqUlp-9(coAypIG1IRJwWJ_1;?TS-OMJ5mr^8j3cM>W8C2F?KZLq_<~
zblocx+_G%;4AV-EU9`xPz@l^AX8Fj`Qe#WAvrMy0aLcmUJxwbGcF|W1rkEf_0jz;`
zE}qzIh-HT|Q}c-oMM#RwH7F!~?r!>I0>>)9rncKKVVG2*F;-;5aIArW32rwmdX>p3
zwu|=hBru>z?!j5jepdjGjai7#Pb;)g7E(NW4-I`88wEUT&1mWjeB>3X!CGdL>U^o<
zix3VkP{Gp*g)(@l;0uYtVhI0gZ1bgzFM>Y2SbQPEm=orU3<@s@BTbX9k};>4FSAUi
zMSLOD%#rC6VIJPpic@rp19?b?Tvla5F84-Q4<np|it0F+a@@x@t?)s<h4Hom4<b^`
z4_tnf>Q8HLpBTVz@pbGZlKb3LavkEbc>Wcyn!s}i`f6X?y*FGGv3%jGF-Lv5>({O7
zeHeBKFZ*f80T<}zkA!Ax2F>Fkj4|ZrRfRX8OEi5lx<rLmezP@_-!e^9;cUP+ys0<P
zg|y{ofh+8R9+xWvosTYo8~$LRx8Mie^QT*NFY}aDT@o9n8ZiAO?aMhp<nR}VM;7gb
zA9V*}AFcU!@6;o(7$;xB3@xqsx8bdcg&2LKYN{e5;Z(xD)a6r`(_o#|9&_t!gMUoi
zav1RUKl*|Xru718#s4TD<oX}TA;&b~*YQ7aJw$5%0|kx$v3Gu3{zp$pZTtL>iy>sj
z|LD03dIvL?keS=#e_Y0BzgOrgP!mG;kIO~qeupo^LcpHJ5B!h4=!Mz-#{^kBXv_Z?
z?`SIsN;5?$GQz4Oh*V)s7-N9`$D#xI02hs^;~IKp+Bq31b25{1ME{c(#vQ?<Dl<^h
z@#vsCA}uAkBS`hQBi3&@l(}ded@u`n+8sHfmYUJyj@(N;ngn}j(hhkCGcng4Vf!fP
zxFZ2kxH=(KO>sv|=aKBgOke9bWcot;dJ<AKL5um~sR{1LI+{iRBUTLqoQFPacf`O+
z8z-HV8xM>LB!n)@W?wR`&;m-)KX?*YbgtVhAK4?l4=I~rnq`7pmd##cS}CxL{@jxw
zMFDJTcf{>;zUgy~jjxEo7Zb?7@(Z9~Y%~ngFky(DlHiUkf!Gj!vD_FM+YVH-=z5b=
zY=irIPlC831S66=rv@#=yCeDe$U&nt?SyA7;lg_zfARi(b4R*CF0b3qbw{2Gdfkyn
z@RsC`+=4_ucjS=Eh;QwVyv>_=j5~7EoJ4nITyMA|C$T4AcjO>Y!*xdp;g}r~G^24x
zRzSAlj#SA#K>0%^i)PHu^SC1ilPl<su$iZ_I_8diBMYA?+>zdh2DRqrZ|8MKf_RH}
zNBV*-;EvqH0l*!>>yPfpmUAk)uxD?4rjp_iW_$=su~pD9{K;tFrSy+aq@*C|0KF7A
zk}3?7hmixH8{TvlRZ1lPJt(0?w9V>-K-@hzxcclc6@)XCbPo<|LM;AB^@Z;jvxi9T
zG5Ar1STfL8&rqznd8bw%&Zd*1kCd0-fuXSy0Adam9|G83^T1g?(hFw=%A=b@9XRiA
z{mOe^4^AZ?s?OWi2Ts-moEaL<Lo}S@3Fl;larA{BeM%#o&mrzsYeg6`{G5ll8&@qN
z!0Ppnbx3OyZQ4k~FI`4|ep1+`{|GN$ZTjQ(Ktulxad_4A@9BeAoBq575%kv|Ej|W6
zst`*Wout19&hjI?aFU9ozXRv}-^IbH>EFW#PSzy-HJpcNIL8yt$ygdlLH`pW3l9BH
z{^ypWf8tUlg6NFuhevSxqTDVb;ei}=H&{6#R!_ESZ~fN%i*tHFQsaXCY3i4<e+g6M
zS&dvPcrv>~{U_C53&~CH-uXTbM$KOKN-Ra|Z}#3W|M&m-D!vs@zCqOA!OA`z85vA2
zA5Lu2l+-^WpSlvzkwYl+8he-vKzt$siS%$PS<a;)rC75uSLi3Mro^p}I91d2_kD!V
zMuiXhyz4{G_|un<<B$DdGvbKvp*Q*GsKiyNg#7msnI|EC1)RcE?SuaiBRhM$xDs~#
zTErmv%}nZO-tQsiQ6wE}Y)mZH-(f%~P=7L@m{zqoP%RPjI_gHfp&11N){x-^HJP!@
z*o&Mi=*)0VeMv@e`sXYuHG|V4Qj1`P^IBWbM;SXT1`C(r8`O9#Lz+IvS96YJ$tLq^
z*%qw<p-{@+Rd7D4TKK{>X5#YbfP>qJz|JxG;%HdJSRY`_aaIG1)feA<)fzjA-)N|z
z7x3YQuC+R0nAZwiMVKS`2mi{pR(F5xS^-tr%~t=~`aBQo9bL*flo|3p-XS+*c-ZZ!
zhdf#jc{GR2G(ZYGBCmRa85(ZUNjLO_@#;!?R->PRD>RCIzUK274#BkK8`L!9L^<&V
z3xw_fu!zen0y2inBz|!SDcU3HjeRh@s#koK^F9Yx%hLtmZ`s~jQ$QwytJtbe%p_89
zPh23%psX%<5(UA9PDYEN%VjT?8q8e4TkZl&%I>A>?!sIYu5j>#q7{@vf#DnY4=chP
zgxo*FUzZK>DC}IR%f5uN?5GkQ73ie9DMErPY>1Wy7iVA!N3v}G<J)n%ep9^I@-J4M
z`eAsyhDpk=UJs19X4=lD{>aM)ra_ngLH+UgS8@8|-bz=0^d91)KfXi(?d^_*?AW({
zsv>Z<p62|3^v7iwYm)w0jj)2FKR&{`jTSX7$Rz5I9VpL<`r|OfI8y765OY)Nk4)yK
z)*tUtiMLaKEJWD^{qZda6Q@6Rfyw=!(I2C~@YN3m)YTzTzS!+8&$jl*d;RhPKW7UH
z&(<#+S0DYsLGatHsoPJTFI$uF9j0^49glLqEj)zB&83ef|9bmQNIQS>@NDVM<UdoI
zqkFgWpD+mt<D-@1{&*TK*&mNzZfi=3qOPiM`y6?c!;pF$E1KH68Y<PN*q>zgpHM&l
zGul;pF>TbB^)L6lp_xs=4bW#;D5e%0DyK+U><#|j%)&aLg)cB$Jf4H6&<H%?ItW<^
zUxnuiwF<&XbHuQfg$fM!gu!d=+L&aF?WTn92t-Ra7Cvu$2FSpS978WwBM~t2SZUXD
zNKroj(-h@>)+ce&M5qm)iSaxj6}}gQTMl=U0C3}RxD#-M)va$yyQ$AkZe;sUzT2_(
zZFaRR3AX`k8A^#B3Y}i^2}e@Nk-)>`1%!AlQ*T0xqkOTmCV+fQINCUmm@q!O|8kYD
zC?WdP7gJNQHDR&Ynj7HYqJ8$^SHd@#Q-pC-F`ynnM?01Sh{6Do2W&^Qlh5P$fg`G4
zn}vN!ysh(S{mOO1Vfrx>kNI%)evX9=>+3a~o|H^v(Y>7fn%>CY_TLzrlbJc7*_Rbv
zrt~}|#wQSOA|b*i*hJpGZyT+fi2R~Nv(b+F(f?}Q<Xe9P6n4nfN19$!Kb{A!AhnwC
ztB!=1rk#{Mf%`G!7$-01pI_0|kBRaUPOQc?Gq-wA^OQNcr+F&8f^-|oT)94eC^bGR
z4h8+fLRguI9(%$z;!-ng{@j6HNAeSt$3*lAgwwSnxm(nABy|Hdgo?XS)IZ<HkkN9j
z?359msgBx_Xmk%a6_K$+C><ESh>as+c@`Q+A4LQrlDiZibX5Tc;vpC;=L~uWbPd=m
zqT{jrgj^FmFz8xHTY|O28Qv=2p~?&jkPYISpAf`pg>_PDw*2Z{!0SFW=&r_fpQg<v
zrh4qP;DTwg#Sg4WjE)e?nZqYEM2wP{gMv%Q+UpOf*%m2->RU3siPb$#c7J}#()2LK
z^x)8NJM)wmoc;&2tYO;*vnBMrvt6oYTkL>nMmBD055%gS*0$5F9mI|fs$XBLyTns@
zO;J+aJk)h+z6L!(M8*0gmCHdn-YI>MQ}`h0sDZ0x?(p^F0td!9R)cyvLeqF7$(vCT
z;%Qx+9p&~UjglOq1dk=bhjj_OQ}oC!rQKQ@m*Tw~?_))<iR;l0u1BL4HdBhc@=KV<
zg=5XxWhSo-?Tp?Q?JQlJiN`^FG+mbC7kb!W{@suCh@;eM9G@_WNZ#>aC3G{Wer*mS
zH3PYOBaW*sglCV=E7_&fUJcYGDpf{bM5?ingVe)F6(J5zyULUnQF-bgnh$3oad97$
z!xy#F_IBq`i8UOg#5ZE2G(=R6At=A`+UvN`>Ho_Qr2h+JWwAYx{~8z_<E?V?|Elw=
zV#Tq1x2c|ZEctp3F~cYPy4-Y^u2GGp)_H&|Q3ra|>5q?XV4ywvzIB~f-&X+RE^|%5
z#2@sjh+fzpeII6B(f47a@5Nq2U5^NezCWYX)%R}}`RMx>uCn!g|M%kbJsS88SxT7r
zo3~wMYE-`Vnbq;o5N&Av^U(#g{s4l4?=SQF-92G)!S7=UzQecGU&_$OMlbTy`WJEg
z8uU3u$EmUgjBD<3Gmui)UE`p|SuTK9J>W!$fHLT5RKpy*e(co*z0VD)8nYIG1W9P`
z1_kjYl4QMa5}}0kQ~w%l5;k2NY<FR++iH*EzZp$y=nlmMC$-|A=rs2sEH6ha-+LIU
zH9tDVQ+dt4b{CG-$V2;1)dx(~l&T+>)D3k?j{_qnss2h0?A5TKfPv@jn$ZK4bSYH-
zt#|~UU=96Le;KmqdzKm1KL+oWj_NOW&|QvJ*i0Gn#)#@qHVdQCPPxD89|O2t)!zi3
z7XFAHLEW!!;WLDpuG!72`{Q`)L57J&6kbSp9IUJY69Kpj<8}XIYyEZq(|^;<I0sEQ
zx}Ps<SFHP?9dw>n_fNo*Fb3r6_A=dnmC^lc!0pI)HF>eluWn2C*E%EG@Glur?T@;@
z4b9%Z>=gQcjbS21;-8EVt@igr^pPF!LNa%zs-<j17ikNy4pp?r&nNBi^GSRBVLYX^
z0H+`6T7WnD_*j7Fr`i@^-~UUr0GE<Y)}jZsehpa}tmt_BRqCW1t@~Mkc|IQhuh2Mj
z|IY|SB=_Z!(EZzCI}V3ki&`RBGVBog=CEs{%b@+4UlNzU3~MIT>y#b>C6#i3E8FQ`
ziwyO?aklEDl-KG1_FY^1i_<UFpF^MG3X9Xf9(9b<pGx_6#OaqF&NDqgF>5kX_wy;v
z>E9lj#^`=2CF+|`uG25A?V?*t<@Cqb%@Y(DM7{HOkJBGtE(hftr(e1miuE<_=43hB
zlnz{Nt!QRYfViK*jIaM?TVp*PDE-c{39M*r!lQT;J*RDg(<~Hti4}af#aw>Mc|a*A
z2IcO}I2Cj&X0a>BN+ehU@=G~$D>^tuU`2^BiKUQ1KM7S$UWgv(og_%s{(8C27z%uZ
z2B+`{md%AnaRtkJ5X{afeTzJ;_f|(^Qbotp2B~*Hb}WY7)>;%$*Z!4arVr^k7GoZB
z6s97ANwFB)iiD6Lu~T&_rwc`x4tz!NLJRYyKSTdzZ)!-G7#kb=3Cb;m&0@JGZ@HUH
zIVQ%2#tPh~<!+)925BJZKpX#{cC)wk7*kskr!HTEydS3$?K2zgF4Z3UayuM7kA0~E
z9b9hR4gn>SuPXXXd+dwF$}+<crHG1TfKtpbO7#rm+rwS^a_R0q_T_@#*!JbQ*W>I9
z8o1oCFLPFt9pfWPUsC5oe%2CxfBTY)#$jJxClHa`3HVVDaeouUu@1HP&ymv|5i?<P
zbx4f17%LOTi(90Z5uUl;#7n@|&Lm?ka@6I<ubUyoypxQ(;q7}S8KOT1+V%A$V?8Pv
zJL417z%V;D$&fBq!8!|weul=KWV{X|nA*_DBtx2;YMLwIe5S;iWZ+3pGS*=T0mn+^
z2^Nf|Insti;!E)bb5M{zxT|$D$c!FSGYci+Obru^shK0S8L$mv7{JqL(2^a%0F1`;
z<1svnzDhPVVUMY)K$+1rH5IO@sU%yleHxSSM22F<I1>^RkEO*xZl#!-<mpN|S{&mu
zC84Ov!baHP!@h6Wlad2yYwSshV16B<b211CNQtePOSo*4vNQa9GWR?r@}HA27~v<5
zf*Fpj2?MA>YN8vNk};yKwJ4?bc^OrVrEqM`eCAAsL!zPJ>_lu$*w5Dd4!fL^Y{;J=
z0)(UqEg4&L3=LtTwU}<oHM3l@tqB`j1H3U@kJ>FL=#2L$Q(F>$v^DLv9~~{2uwH4e
zU(66%c<(nmi|h0ecu=CL85+>crq9Ds;EGgE?5oz{k7SHM=3Hq&_IriZo0z6UphH%K
zYkcFuEueV_Gg5ZbF&CoU@IEYi%+kYK0H4+m-Up%NTzLNi{l4kpZKdSf_{G|2GJZp9
z9xR+6yiZ9`j1x3La8CeCsVeFOhTDzbU$g_>rf>b>ohM$f1Mg`-cW2?1^+?$?fmLRH
z@h>cE5Q}rbSvU@w{~xi4)c8Car#+nz9xx{&3)ZLDrr?N?w68Z|po4K}mm#vSdKRQG
zR=z_GYXOrL7iiomNz8BZ2_gQ~rO3xBr<{f11QPZX!dI-$dmdP<Ph8;?_;sVQG>UoI
z@Fs7yV&7`<<4;%rmk4$zciaB@`)p+Ws^{A1-|VMO!q;drun)dcmA`+bfBE>&wkF~C
z65nd=$IqV-ze@(wQ$H2F)xH(m<cDFt)!NbD?|d1l&HhgGt=5kIKIQ^&2k7@i2g~og
z!moV|*tl`Qy{3tTTK!)+7JA@<ua|bmd-Wc{1sR8A^{hF=YF#?2wWa!mY0cHgSvs@k
zy-|OuGyg^{Zrz~&MY4MC!>cfct;e5Bo2|wS>rgbX(5hdWGpb(YObi|y>6K}Hy=qk7
zrK6@lUHvkyQ?+)(4vChGB<0{>&3#DP-!Qqb03TN!*c|&MRc?XR+Cqa~zzydGf$GDU
zh`U=kgBf5yQ@`W|7xp-GY0aLJW?!nC!?!&9Eid+`#2WpVwg*NRT6h1Rb0HRb2m!#t
z#Z=#fB&;sgBIUbD$Wc|0_mKmeom$1}7FtCge(}n$v%|kc_4b!r4?h!Af|?GT=a~LX
z0uVO51w>t_^ZOkoWD~X;&3?QOF@<7_ZSJST=B)DiVIS-Qds)+KMfRI~$b_BTp?=sZ
zJa@x(q3q>+AokDAeiDzgrN`kFTm82i?rhbi!R6il`_k{y8~wxTW<)fZc=(I>ZOFa~
zwY7`Vn=^*`VKqny)ck5i_StS1r<pEJ)LlFfPU_-WYHs^1L5b<&?=MIfg{BKjJuLJd
z)?2#hsrN@SNC)tfK1K`XAJi>4?Rky?Hy97XeGk}Dm^<NL-2v~2jAC-qT*xQKax(*K
zo<c{nP&bKmo{Q<2)tEoG0K;s^dLH;6v~>M8)*LkT8q%<rU{L+Lhg;{aw#KivES{im
z9FbQ<`NLTOe4w@!XHodOp*kqPf$Hwh!h^+U-1(D1m!%j%%!BxF5G1s~3&*l`-7&U|
z0-m>(kB8yrmyYdS^vYpZJ!7X@jtGjz=pF!4Bg-fTZVpttV^*ww`mC(Sg+K%Sq2Q2w
zC^!U!gt}D^=1?IYxku~_<O=Fq)Yp_IliuG>uW!cw58Q$C?#nrWSd)?H++N65hf$@k
z$o}t6WL8kKP46!m3n}*JS)^B)J~LeGIGV-m1*0zpg$JPkj;8XoP~Kr~NUg9(w#2^l
z+2*-~Dw01K1@tDZiBHFc)X>18Y9QwINoSi`6FacJ8^%Cc{y6p!$-NJ6%EC;#i8lqs
z&f})IG74acYFYwR0HpFj^-ek^mwUeIn?<FS^KyUWR`7BPDgPO!a8z~`Ca2P=_gCiB
zH|H@Ik&p~wJFBC5KN-{hDYm|Zz8ekg2G~OC<0lDQi#kR_qRId2i{O)F0{hi}(A3}7
zTmR<t^^2%o(G&V;hVE`r>k>7)hTrZF;_l#nDEkwvR-s27PV5P_)F$J+G1O(8*fw6q
z*<Lfw+bEzJXV}tY#`y*+GKq0m6O3~=n~vn?3;*Q)8gD8H;6!cW+aCh$&VrvdHn94W
z%}I6r5o!j@+@#(x7MrpW+hj;V3(+7)h(uXal~PTDC-E6?3eosq>hW`@<2%`2Tu|yT
zlye+h9Ml|#3p8-H)o5;O4m<%`pyf(u-Lq1i5hFjD7zXmZ>z-^J=*rgUBAy^;?~KjH
zb}t)U(QFt{kaGkF!;UyA)x7*G+%jpeEdifpYS3RaAC#$WFd-H`2u^>Fl_Y!oQv{<$
zl|wrMieiktxV3s9e>PO_PxiBo%cZ@=xD<PgOSc_iT$XWU<+xJ_^!)^imv7|T^19j~
zftvEv4gMrugB8-?iKf8{HduiV&<rbtfx>}E*;d)+M%A%BUGjypyyP1!2*|(d5Sx`R
zhN`kpJOSizpr*<p-|)qneBNd2+srz^TsD+IJ~j^W9f`)lA`i<??i%P|bqbc2K{ShT
zP-G2bWoWcoHGSDvtqjLVbB2B(>MRsc5pWNB7~xR)S4aRpM#$F&tWLyV96{MiAH@F^
z(XIcu7NG}lYOy*3E>Wq(uFM8Y;HQrG`4u=E_zCG^7sJ8>IU%U!+En%-K|j=gEQ%A(
z7~_lGnzX<asS0|1G&*QqT;CFW6{Up)E77Mgi_|a_sjtloT)u~{ygNw4*bo?&$34o_
zPY^kXji4`82B%73EK=RsFdBtwmp_OT!NknSv0wT17Su)*G=qC{L;JL1oET7N4W2<|
zkv=6mgMmB&uULKh8i(i`&#^1XCU-)kx{L8nEDRp<rPuG@PC>6TziIW*YZ+8lTlDg_
zU*y7bkT39n#|B-XUdU-d{18+4S0!8z4*}I8l$JUPDi+$5WV{KMf)oq!wOoxy4v9rB
z^PM5a3zla-hnbM9y2o8;99BI|`!F=-LSaiiOF+ma-0>y{4k|hJVsctYahvZfbYGr|
z$vq(Wju+sA;V|j8XO?^^u+KJ2RtRr-9H+ct4uRvy_8XYf0ydD>HUOUS+ttx54t=9t
zzXm#9UdN{@*<2O<B@6}UQ--5`nX86X(bHslPcDwz1N_k}enJ67w(3}%_@`zNeB%w@
z@C73wN}f}Scu6C6V~VimsE1agEfg#vCBmv7_X{D9N3kp0Muy0XhPTLRvOB%CcqaAG
z&-U-!@)s;<SNX-wSe_>`iq(PePg3>Zd}>FZqT-;oL&U5vER`{}9ST1?=Oc?2HydFp
zRu9q9NHIch|H5IQ41L}miDl3be}cLA<uos&an-h?;Vtn+{;Uf=vVF}z0c#Op?a(nr
z2gAPdVZ27iVcgcaORuK;z~<;alvrfW!wB0sCEMflY~w3LvakI%ODhx!8TTccBKhwR
zu-%dO{v79yU`lqn1$#Fi<<z5(0Fz`t$D1rsLE%CFb2Drl?#NYW9DS^ppWJItgFDiK
zH4y~q&afh0KNK&r>V_^tr4j9f&^KY{R>WPdD^quW3pWPE!gOSb2)<a9Dx~nfsBSFK
znH4yPH0^pwLqF|3gjF_|f8afY2_j^=jgNh-d`aV2lx<k;!HF!`u$`a#NCD4!VhAjg
z1J(&t3qR%YQTXXYgm&q<7m%-@SBll7hY2#D9<n`maeFIRM|RUx;DJ;B3XEwiyw<UL
z){_5IP#Q^`we0&JFP|NS^5B8V#WtV)=CL?FLjz;UXB2mJH2XJ8=FWco7PO%5fN3Ym
zSxk3i8_wa2*af(47j%K19+jWm`U5f5I}JN`AUNOgVpw1yz+uRMDxCpUB8da41oRhT
zKo{x(J;+wffXdf<2V|i<x_JO2)>G2^AB`Ij8gK`6*+Y6jt5C@q5MR_PI%FvZ#4a!(
zi%5;+|3iLqcLhYM0c62|_Q!z0W@c+6jyRFN))0Mp=cPS?nkr|2RcMR@tioujF~Dj)
zz;8ViyYy@C07s!bx_ur9)B}7D((jq5paFM)bN-|UxCWJ+0rEwC_V?5SWEU9VdFTQ?
z1@r*V$B&u^2MYr{CYvyj5$n;po`3D26NbSQHij8HuN9804dluAYLNm(FiqovhquV-
zq#@>p?v3DO6e`4l#CUSn9h~+$EtYh~4N`i(I;{`=ElGUg6$~E^cW~NvPFj;myS!GH
znP<OC9L$5--M{jp*4*(n;Q$-8zn<@+b}`0by4-;i0>FtW0QZ*mZ^3?3(Ay9?dH?{{
zD*yuEvnZ`mG{KWP-$^A*V>~d;_|gm0IO#S2Z{R6S?zbR>Ho4OPF%O}0J@^M!0orr%
zsZ8uMD!C-6>p+UB(qj^ZD^^$8WlTCr!hA~m3}@VDqZIYNq(G;GSUKthx)DwyW<nYt
znuLOY{n)t7n(XPU{%zEIej5Y*5j4<&5j~44R$n97$iC;XZ#1rd5yQ1R*V>v<K~L9Z
z?%u1i=uO}T(8!Wu2d{jC+$P`*Muc9|W0+15EdWI;$_tT?)qj*l_Px?z_h>W@VYLDi
ze<pnZ)U^N=OrY69?}g$PGekqcBo0!v(TtgWuc$WPj8J~@-h}rinF~N)@Z}P?nPxvN
zvYU|-%hd(UD{`3%kqPVZ{E<SBaohm)O1s8!@vt>aFldI1$&c&!0Y)&QwdOz%XAgmw
zk!IK@q9ry2P8u<hNB_d;b+Vl3=K0mhNSO?%>HrR);!oV*!GE4)FSYDOFYyBNAizum
z3}-{p$JvLF^|1#v%P8p;v+Ljz-fuq(ujE-x+}X0jA2?yMx_J>rskLVJ)V;*cWnP*2
zda7ur60>+I&VI2f#cZ;^HWawRh|*BJQvpsZoQ6JPJZZ}ZV2(K9BQRw}_oO3)1kr+1
zm#;^9yJiaQa({j-^gYKw3V)G`*Y;mWg3qi7r5gOyw*UIl0~8NBtdN$lIs<MVIlG<y
zt25tR%w<{%H6leY{q35+p_`(wSE27LRt#~TU%zz6U~Ugi-Kd!G$<|deX<OIXNt*+o
zwvh`N2ZE9+uHm&0`|BvzolfE|dH@sQ6;K<#D(apk+kFRw?$4bNQk`hW?fyP+nlM(n
z+Dkt1TJl3s1n$&9MYbi+o9DIUW=EswvTN@G{POgF_mNI5>I`T%F<Ld<2Q)`lI>zit
z=A*l?9^(>>g@X%Qhqlyg2M})lMhD<aVn$ufG!-n3sfejy*%c-^71+@^RQTD4APuXc
z*#np-V6hc#Ls^QqLM*<Lj3Jp{(5nVn5&poU#}UI9or#gdpM1C<ZW2eSz#{sD>PqpV
zR<TZ*I&YyK=TP~j!PKrmnR**oa$CDdck#vwB-S_Y&Y_p<q~%P)(BVAd=0E}D5l^WK
zophTiRblSoD^@d+vLc*ExO9=<NJ5ASU<uLxaP)+zmAb^KrV*?=>Prgk{3@M4#N<~w
zo%GY4aNN4cPP!8&%+J^i6XK23hi-h_-t<Uc!s1v$>b<#S2Jj$ub!W!L>%@l<=GGi?
znoii^9@0mg#uhaJRTkG7jtQwFxt=0zZNPfwif{<H7es~BCtToM5zcW_{w67W$E>kE
z!B(HKd*X@MpXk|tbKQODu0AQE?W>PblMGj)Hefn5OT<p$@?`yJDU0*><fa6g^zFUm
zws)f2UK1WW*WMDhy;t4#aBjbo?Hy+~5?1foO<SrYO?!fG6NLBue&0$?S0KzVPtN!A
zzNVH#S{Hmjug(5r<i&*k?@QbN5IE`W4Y$Xwhxm?vyy?q3{;Ld3{^LKjOZz{a(v&d%
z?rF#0@Lfm8uZ<=QLk?vn?fuUl`TW6@Pr0}Ojo>%lbmd)roPboj5;5#9-6YK{{QB$4
z`?0&CeS0WLz;^;)j(<qJ6srQv@Z(fzLjG^>Oq~xMg{a3;`p>R%_te+<U)+&C|Ft&q
z&u*jr*?#r4sK7nPe|4NItZPj%sf>pg6&Sh5QTZ^lo>94mGqF4_*Vb!l#q{Q}q}JF&
ztx03=;_IWQsffyYdP>TF91cRd{Neuf;fQfYMA&Q`P^*Qwt1J|NcQTj-LW{WFVqI`)
zPU~}xOR-3l8QTlK@+m9f-eT4eLb;&h6NJ<iw+k%kmUTV+&b<Q+eoG7oot3Q!7eSE%
z9L5nMxd;7|lLFw6S#=E4d2?TVp8om_63_V{)uJP$I$Wo54Kp*JNS(Ee3R}8aQ8yP2
z^B?Ugy5&9wd_EZ-*s4Xa(*bqC`c~OI0q@xqC|38H0*GG*)TsYx{odIv1}^i6yz2E$
zcR^i;z(OXlq6w5yJrD@W`LugLjVFIYRzp@KtHnAW4|22?{$tqc_KMZ`JO-kE3mnIq
zz$WQPBXDT`0&2|Kw99W`jAAl|nG^mVD0E1V@b;~7Z0L;1uJ0i=_(y@VfVs>Xl2P5;
zv_hhT-w#1U-W01!^-D}DS34#qRj7=_q)PSaEeUN|>TiijWvV4HsaE|tA!$Y(34MEF
zYBN|zH6YbtjUshAwrDuK^ANtZ<m45r!@()c6SleTt1e`lBz(8UKYLo|L-aJOa2DLH
zg;zmf{(KBs<;9e&V$-ug)B}}ALsp@FUI83Ytnl8}{lDZd)b%k~SVpf^_W`feMqz5B
zaBEEutfcG(ev9>%1T1~A$8dC8it&nN)KQJOw=IV>?0^kTm|Ss{`BMNx_3{ONu@(L=
zyEyyQIcgmR*d04)KoClOiMod`^7L2Ct#u4xzk#b8b4Re{MVxt|Jxc~D#b(TBZ6rmn
z<iI7Zkm3l?%NnzDQ4LQ}{LmX>O>58wpzFs*KYJRDjx~*zyNwPsjh4sY;S#LXRPZ3o
zyVN<7GU{&KM}>aPFf}TG_F5m5I=s;p4{`dtL>&um@!Aa@T-lMVW!bD1GOU$C_sF&h
zj4Gtoa9@TzZJ<flR0*j@5SKk5OvF;Zp~C^3<D-hc$}E9DJAMDMZ6EV=w}bE1-L`#R
z!@D7)h>+r1(k6*|RgcrJjWhVFE<#KlO8f`~J~*|R&BNiMKn<D7{Az@uvR}ffC7o^(
z`<f=|ScHptyx~%KOgCEYthS>ygoY$F9*X!1uQF)lx@R3`5z?=I*xrD%RZcDK-I$w?
z7j-LX2(sA@1sNlofFQw_aHeOrr|vT}w<~AHcBaTY(Ts)<GI6hvI-A-wZDVLt+Pe`m
zFfTCK>Yslg!hN8T@|RN7JiuqG#c9eHsljaDABl1D0)CL&7wB0(_FvyR=pUS(I~`7k
zdgKPIK4m}qRQEvru&3}B7#`3Z+gaUC`RBy|xJKqiltE%9Vq?Alm?%_H{jkf~LUn#)
zZVevPb8zfeWRGJS{-vrd_$zA7|MWK5tY4I@T?lV${<vGy<d>*pZnT*}P~IrqYlPZt
zND8S*b2LdH**N5oimoO!!kckI4OxZtLkk1A&~IpAMs*N>GpqAr`G}UngzeDuC4YJ~
zeZik>`9Z4%$wP?adF*&!1JR<?SG4B8ehbeNPb<6=N$`GU-^n~Y2WqmT+?l|2DZb-N
z*i=d84FkyH=)yevf>hVOBC&kx<iesr2w%wNvS1NX_Lt@V{h5Z8{gG0LDurrz1X1_w
z?$PeNVFR~~HD-ScUBPT}ZkRoYmO>mC8UUsV4Zue3gG_TYhvl#c*X$I9E&^^@965#b
z;Dgf$KMRWPL6$`uYqi4DTcDHcOE%!;kJ4ChK|o)bml>PmCh+oBT<VBzORf1Ufik>i
zM{9t0f?{uizxciGJYf~`-2@NUPy9bof&8S6s7|Cpiv<_-m|>Mf_d$Dz|B^aw&@hgm
z8~FnMrqwSL)RJO_a_XrNI4Z=6G)AMCXb&>-t_-r!caXp^(Oh3!)LLy6Ii5F|4;*2O
zeo1h#>Mr_z#_*EZbyED<aLH6*hfF9Lo}21<Gh|I@4;XMH&3hCrlp#maLi+SPc1`ci
zaP!_^U1)uvvNeBy)JA2S=P)e5M4l@`Yej+TlQoPiOe!F=NVZVdug|R6N%9D1eM{H@
zvyZ1tH?jf7sLSLyWq$5Sb!ti)BGyGR0jwXE^AF66feZ)@I6U{8wX}U%OIL*Tk-0j$
z8ugvt$lXakpgmXwxB}{!Yrks6F~3j%TKC=tSqa1JSFMDtP_KhF%*)V4UxbrF#J6GV
z2$Hi(u!2qFU*dER>LOH!^h?6<2M!dRaI#lFw1tzgSCP1jli1j+MNORrH5$pzauQc$
zwMe`3M9H@`0W|uRwBgsf<WNgsGSBrCXI{~RKi#VLiWN0xU-G`_qM=eS`<Hmb)6nRA
z^wpSsGG3$i;E`Y8l8tI@o)<cFr)`9-Vg0fne#N^SI1=q(Iq)15&`WU{Gu`Dt$^Z}D
zErE$iIy=RhSWYWq(~<l?%1`d<d~DBp^-uQMsm!iD50@Bkocb}b&rN%)@EfSk=OcAk
zK(0Bmpg+v@UQ7cDDcYXvy(SlCJ7}4+%8M3!rk$hu8wzN&{PTBlXu<VfhpGGE9wecK
zHG!5p*mNX+G4KJ8V+XvcC$M-bXAz?dvNhCeQ8o~qei+~cq8ew)FvelY(F~)t`Zv~8
zJtFAmDb>HSGcqQgqbjb_cE6UEQOqjNfWYe1>djTP+_+SS_G7pc(k);TnZ!)%m9=)i
zSPjoCZERk=0m<rZy5xXjEnf6y$TA0+WlS?HJQ^%AS}!@D=RxK%FME->E6M{GSNFA%
zc`GE`-aMuoI82>(y$>>36UZEmnrPrxI|?#4;7v`yMgon@^D*J)aL59rZ`c_wMU3{g
zI52Tv%3N3<?Z-#>SgO7`(-dbheG@=&>}6dcIQ@i_L<vrt#;&}CndlN`yjn4xgt51X
zxv0lZsu`%LcT(|*g=XP5i9$@|DC9Q<g@)cEs%YvCzzNhqo}&zWuI~aO#sCjvG@))_
z6(ms^-1(xHQ2p3%B>#iGZ9;tk9`g_i4IHK(`MnRJSQCVL05#FT^4{nnl6wF;QqRH{
z)`V*2LJ~%`mc5|=D$=0}G~wlL;%rsfM3F3z3x;xB18!tMKFU<a6AmN7L0t0zLqk79
z?#$R-8&Aj9dQHbUgcoo-GNv~rYC1|L=r|XJlIX}p)|B5AbgY(57TISLb8&R6a0IRb
z%~0SffCJBV>N8mdNu=XjE4_3afbt;29wD2K`~NnMj@V9pn2N&Wt_bvDQQJHYU&NZA
z<9mAv9siprbo>(Ss0~<>Zer=^dRDPDRB+lyeDw%JaN1v)0(jw)&D2<vy{Yt-57lT4
z)<1$W>eeeYhUcZO5Z?ksh-EeEr4~>>A1Sf@Q*;<#-;^dzSWC2@c*U~~oI0jETPu@D
z>Cvu6d;zg1DCw!oTTpQ``pBJht$wTq3?%vsm`?LVRoD|L_#=bJ^+`J|H2M<jn@`(-
z_sKoR-)Q2a_#0tIV#7>hPY}-$&{O!{0QXn-GFOOFVvAb55_<&7Lt@9Hfc7^gK{Py?
z7Y!Vy24C%?d07(@dk~w3zac-lckKp=Ekz_lYu-I+A^~+X%EI3`7;tKTgTpZX28YpF
zeK93j9_eq4WhK64OgvSsyMn?hYTIlC*8WD-CA~zEGp{z5N7-T(V^QIqAlbMXB6D6h
z<I>yErVW_5vTgco0S^w}f7Xk`5$rXR-w$KgIQ-evI2?-4_Bq_!B%h5nfx}OB6&y}P
z1F&8<5{Eg^&Kier8S5ouz))d~%niYKsc=S(7cpfO#;!pJGTS&CD2JNzodILlcsoY9
zq}pXF!7sR&LhPEm$rp(wfr-Yh;XH!JKS?B_>z_D;6#qmMa=hwyxz@UM#FvL!P_9hU
z%9T&H6Qk{#LsZwZnZZKZt|gK77FoH;ZXizM>{^?S<ZoF8XrYv3;vQc<>l;FjXMd6W
zk-OLw9z7+F!tg{7Q`<NC*frJ!g||gbG%#C!a`!+->L<|a@petH=GrwIiLPA(f%Rt=
z%ozi1*I3TjwP${#F+7X#g5o|E;#&afSyrQ7YQa*?L5j9(ZPquXNln%=b`8~LYgz1X
z+chCmoL&3kCS%uVPJgs(8)Y{W?S-Gc(Q$R3V6WIKL?03xaVNP76bjVrL4~<W9<gF)
z=DV^eS0P*TQcQ;16uSxeuGlp$^@<%YABNPtgaTTz{vY_;W1K|nZo*U{NwKmf#BMg5
zj^tn7UEIlS@TMNdg0fbu_nXPEj4n9+CRFM8Wcb8dZJcT;0&56w7fyy>LHGk}o*4$v
zwP+p+_!!5Ek{I4uyQ_c+iOk&NCW!Z5s?~$2PcOV(Izilx>jL19wSYlS;oF=U-o2yC
z0yCcSvcO`r0Sd0%!DfNCE{kIUnHk=QiEk1MuqIgGTGT`Xld^>c4n;@m!JBOskR@p#
zf{3KH50i>(&5Pxb6gg07)8z0Bi&b)XWSds~#e2(Za}jCR6MWQ1i-|T@&oJ#W{D@#x
zYMUFC2|t>#dl<kreR>#Rtoi^zS1tW|d#Dan%QPj?s*9<wG!7F6#d$4E{nh%ZrYFS#
z%N)XDau{*?72rL0@O!)RLXA(R!<72?4NYZuit><{Tc9I+x}jS0shE^_K4nrDO@J?%
zjb0+z6}`bAagIWp6W}vg1(>Fz@a7X<c6|%rf!lW9-e%YS5IK*=k_oVai=8w9W=*i`
zyZAgi`8`wE^$WD4zQYn)yrUq}?K%qb3b#4IQDAbMqre2?DBN<1#_&9ru^ol@3h@)z
zHYUL0D5R_JKLHj;L07XK1rfzKM`0!Q)PRqEoB(f>i?Bs2r`qq&i(IV4nel{lGh;oB
z`1SYtVUOL`J&-*a@n&ZszGpZ1u>E7Z)(^W8c^Q+jQs(60n!Z2`2Z5c0?<fVS=Hl!z
zvA-jd`n#!z-Cw_?{yxPWmT~<ZAX+rV+~2RiS8q)m-_gD7{uUxHeta8xC-iqlhx&t1
ziY4TiydznbR&<gCl^2R_$Lx@8UP44;5zRzM{S5aV>J3)9jE;I|#$Iw73>kg&%6g!?
ztwk$MYWW+7e}NCiHEsbOAP{JQP)--STPs}v@5xU9Z~@o<GZA~YM{EPwA?OnLqtp1?
zCJ{Wj5V&jccM`Tj%q2TSE(E&jKUhn@W<C=dMiy}w^vEJ{wawXWpl4T^%&`P40!ylw
zur3-sl-6CB4^e#dS?`9CSopXcJ4$<6D@K+eou{=Wzdv#sMglkZzhPups)n7eU|yQg
z^d(>%{e&`Btam~wq@g}IawOR9B>Zmxx?J|FjVwTB$Qm-Tpc;F!M;1iq2+(GDjmH*f
zZXTJVK7!N!%!Vn`=K{WGHcT+TQ>HiLUE1IznU!_;xM5_O08+Ln!~*t6%TW~nA6w=W
zt3XN)QYuVOm4FieADg3g+re;NaQZd66KvQRS;fwq@lIgY>U5^bdw>8$u9xIUgm3Cn
z__-_^!V9bF-zn3>QZ&LJH5mResJ6|sBLf++Ec}H?jttBgiE9E!W(c=K6#~lo<`5vr
ziJr<07&Z^s;})?WS&J(Nbx|x>abPFa%3zLze$jFcNgIh(5-mlqy3HJ$;|hAi^g50#
za%`U3o*q}DexJI0F2FtG`#JIV=%cA07hoJ5I;lYgWRY3$<1jbwK(OVATj9yJEUSKt
zO~ujKMvhn^kBBnt#f>v?$jk6WATE=XBMU~PNs9DmCVB$*@eiIVbe|PYpAaba#U)w&
z#8Q>99TUqjm911VKTKtgKL);^m<@9!T0LTkw?yyJEs4G@<1k}}CdRf#V<}Yd*Z2@m
zaEe~&7#EyiKOm)<<3nfCg`mO+7=pVRu&M+cfZ-U$MGsZBl<8n0(~Agc9ov-7?eL)e
zwQ278zYC^UST#7^c6Ey^_@c8=OJHl32f!wNCve4_&w~^2KN8pC#fsRgGUf|Ee?&Z5
z2Dnb@Vu1Pq<pV@ZWTyP8X;`@j-FcaG>K#0pjB#=(_4-=HqUfPUAcdVUK*5t4;2iX*
z4KORnGBS{0e>sl>esnuqHpK=P*}}Qf;ZWeR$RnL*kubvDi_uETr%9Q*oQ(bbluwWA
zkl;V0vwvlnW!Qo$>L1t_gLgSR(&)an!Amd$pv2`x+Tay~JRXAwPJ_{F^cX%rGZ&6Q
zvudM=U$`&{#tk1&!}3Rxagz%eVdZQiXy5$;^OkdQ2hE#ktdW+#d9!T68(9JP@IRD$
zw-))t<j6|Lz|kKyg0>L`?qp0$+cIz`V|1WWhYg&UqRs$nW7}d-IkKA)KemONysa%o
z+QJz>@ihvEI7>u=(OuK)Ky)#01F*I8`)S@>dzMZ<+Up;Fip{xOm4A2!0P+!`ImU<?
zin{*c3Yf6X>mP25>Ep(W&nXCxw<SJ1Pw1TZXe1fGIK6*(SWdk3wA(-Y7q(}8KLsek
z;JEUH=@!kXV}0ReRe8)zoIkkJzaTffN5tP3vgi+5#vd#bQ{(!B7X7y}x)NT`(ANvB
zz|Ha~r~O7gRrvURzgtI<k+?VgwILqgZ>@|+vb3XUYg4!}YWuOB@%}3Hh$~Zif0eej
zwY@+4m(Gl_Mt=U^W7&>eb(#Nn=!|yye{~z>|9M%%9in)E65uE@M*xcA9Y8FgnaP=P
z0FCW>!C^s<0|-xeu2?U6f3Y)vFy3EU`D^$5>?faY-Se~Gev(o~)6CB%RCGo{H_`lT
z2WY#lo}cx&sD1MJ{^X64&(6)y`apTgfN?z)=Y1WTpN%^G2P2{J2Gf<-0nMCoy6-rt
zfhi6r$S^^nns#1iE$2m_S%0ZLdzE+lC9eIG&_S5NP(-vD3>71aTeKt!_g!@c+^La_
zwT<KgK{!>o%7r(5do>+y&mMn>F_0n#CdLJ;GZ22rDn$GuE5)H~7aqU*HSMS`mx<#%
zx5mR8LKT;0`aCX>m7^g_%n!$-;hFz@)|?iRgmPT)v*uLeiW?6Mp0jdu?uSr;^+_u!
z_IY7^Lq^V#6M4nz*$;dR$MFLo@wR`7fBU@cvmg#AoRK?kEYHaK$9wwn;80)Wj?h6p
z#L*CODO2Nqg>P_eH%6}!Gg7p-KI^qNlmuRI)~k>Yg*bcHvk8`6-}tHC#ZEe&-C~VC
zx<((V(FZm5VU2yzS1+{#TGrY|j*Jn2o(Luuu_Za5ScGLV?iVeJou%eu)}ssa9AO1c
zt>t5w`!o6|fsIl?ygxrUQf|3-X8aRQL#(el0=iV(MHZ@vFI1woISaY<oA8jAFFoEk
zr{nb43y4)$oYql#oPgoChaUB4x!v>#fj2r#kN+Tq2YNg<DIGn&!#r`5(j(P+FZHW6
zq7i`>Oe#uwM~zG)^7xBL8SV)=RUq@<rRM6NPPf07cuCe5Zp-?q)9p_x-?Z(A+6TX@
z|7^rwaX~u3lFGN{|Dz(+;cuWQS>B4A8<tD7vVD^`rli7jJL>Q2f0AC)$F)BQgAei;
zc0)+_x(19t=h<);?#adjtUz8v4xaK7s@UhxS7a4JA3`-YX7NODRv~_^`t=7~vJW33
zxntkS4&d;rxFUHv>3AlMSeg|(H1<5^=b;@g&f`zvr9GN**;HYy4-b3t+M<hh;1fT0
ziA=;u0<rEm!p@Hb0#R)pVK*bwKL*|s6$4o@sxU@{ziRt)^_QR2bf{&dgmBSPz0X3s
zm@fNJDCt$M9*3!*1}}nfMI3=^2{%?DNixfh)0xG1D^m}gqkBO~aZ8HT9o*TSM#00X
zmZ&8Fjy=HB0vZA}J+OP~ox1LU7*=Z~wVB?G@2&u;e}zx|o8#)E<rMXuv7+ntelYUJ
zhxN`b?(+Kl2K}tJgWpS%Me?@+>1Dx9jXYjkjBYOsY(@`*0yV{+vrR0HtzB=toy}Sm
zs0CIUg4R_Z#Jhz7VtFcbzQ%SLt{vFe&pF!iEFq)zj`zNY-0^mc8}BSV-kmT2J>HYb
z(v6qJG2V~<PsUp&!_FOr*3|&S?(OluE0Y=UQx}Zak%!aHj_0xNO<0$}l8jn*o-HVd
zz9n&qQ-9Y~^#=i3Fh2y%uYQ~>C`Wyu1@UDn94cQ5je-v2En1rL|L`k60stoM&#wQt
zl9E&<x5e<Ad6&WXV7u_8m|}9VBY^Me!op(dG`J)SOaC=z@}*V{gI|GluA093a}1L9
z7<LUnH1)yo>K>5C;^<G&hOQBW+oD&N$3KVQ<hX_%a~QB=V=tZ|eRgA6IEo>38^9NQ
z<oi)rn4Cc{u#8rRUsVCUfzR@yA6$(rC%kuQ&A;|kd_}QEU3oGbua{x{8w1e=Qi-i!
zcOhyp_BatYD;TH0R&Aq!)!%j%U<c{DngpUVSqFVs8o(3jQQ%c#qY@>>W#QmDUkI0w
z`~qQ^5QYOaJGJJ2RxS{(JqZvVAP~l6<7}84XK|sC^!g0cr*KAPf@z7<+neg8ef)9k
zM4?p;`2%qm4}UBa{urZ&GKjmx6Zm5icqWlQWEYzZ{t;kBuHLf1AJ1mxNC2Dk`+I5o
zxg(1<CXqWXIYn?kb~JGR$SDcj(TMRRbH~e|KR`{v9jCC4%N<|SUu!RSoO7%Vp@%zO
zIawfFb|N4Q3WPq~@!Bz4k~@<8wNqeEaSs`dZsYoa%|g1*?;jyzp;LLeHD1H&Q{t<B
zdGT3k**d|W>p=TY)9SU^zDHk9{aBH8u>pTQe)ahRi`q`+vli2!y+~8feG4z#=bE;n
zYrLksgo-PYfBKuYX`3`E&a}zdy}=Our1J%=2`jfZYNCPr<tO)Cbfikh+vf`|#PphR
zcY<oIAZ#dWzP?ekyUtt3M1WhOH+DcZ>dSm!K}1pV8$e4@22=gw{qX0Y!|`VT+ToWE
zL8B7&FHWx!%Ad!UfEfM;YDU_hD#K^g_3{c@%uyF%rI8E|^#;daPxQeXL24bat_4^~
ztc}ixiijOq8qr%~xX2*w3s7k1RCu?jsPAErc1GiMveV8e-Ol7_CEAJh;ieXQ<l7wp
zIC+1O-Wo)^QALoQ0{_=nqoh)!1ZGa7q|zxdejk*8VW_O$%>oW8)dX&6$5R#9IwOPl
ztcpE7T$@2yjw;zEfj-pl=;!Kd=)&sf&`%7+gk|EXC))?&izRg^35ZSJcbq%fz+bc*
z@S{saBf>nae!&P7!FXCwQ8!r56j;9bl7dS-k=w*)RF+bBpJCo59UxaYz5K0@#z48o
zK)H<pgkB8$oKHUi7$^@;ljbn?a&<oZD}&i)Z`;VMFe_+y^lYVCg;L}bmZn8S`}S@p
zR8dz$p^-dA$d+ptX*+Q3;{LB^llT9OAMpML{J@0o3KhuF=~1yqUh`_+g@SgTy%UUO
z%;FseAMNd6{LK?I@<eVLGR!w*2!uxNcxnxRJqs!79o&3^Zl*DJ>T-pjw7P0j+2F0Y
z-DLgQm_2Vo_kcBUIr(x8Q5UCC!=SU)s9`)%AtanApLD0IQD1NH(WpIMvo&fFB*Ak8
zMoyG}@Qc(M_2pNEtIE*;=1JS5BlXQMZH;=FzeXj`shxJlFu)1x@Innxtc3?VlFjvK
z)Tnr)Mtu`yn)bt=aTq_Ppy_b)vKqewo0<F?o*a3A+!U)87y=?}E^~k|{u)h72pmld
z#hjyd#xVmxK}XWknpV^j`BuQa58wizs^~qAre!)c?OgdKuxKZ!HLW&hqG@?jv)XCr
zEZt6Z^bBg+o<`G37q8)Z6r&I3u}O$>C4Mm~1H<q4#0xc#MpcE4stTvX-XWBLo~h89
zwn7E5!fyc^P{u~nR#MZVZ-73UyGixO$yA8SLu=X+wdP1lEUncls0poUivUiot!7Kq
z4Ir}9?e7p40di`iGr)<u;x>mPAINWJPtw#Ehp`9qEi_(~jNJJGhbe{kI`b~+7^!Gb
zLC%ePpdF-?>9J$Gt!9%l2Z(+4LJ5q$EI92sX@=2{Aj1&adfED1_sMUs=sjUL-XI7v
zJH)iYr<!F2s#$a~+p!hpsv9OzerooaRib8(dqo7|M*Kj{K1MGTTwZ4&DmQ9Y-i?~o
zc^oXTBT$;{x#iLAjgl=<)zZ*R?VLc#!g`}ggW4XXvdtym?I^^U%+^F#417VIgpkLN
z>b9LqKSexQye`s8-ElIoNv7hw)qFU!zwx}lfY!vG63B@1awrmi76}C&!wH=cIpXew
zLBG%(B*Q$P1isM{=}hs%Y8!Z^jyQhJ$rcnC+X+lOU5nHGm}QAT*q$SuKZ*){%`nU0
z^X-&lbXCNP?D7`;qRU<J(H3|FebF;Kf(!8jR?We*#|v%P-o+zgNM$gXUE-^TG9Kz7
zt{++Kw+`*HU&t#xk>iFZ^m~`?_s$ok-v?fnewXWhXB~~gs8*sr79L+^HO`d#2~>T7
z=wwWOn0qBO3ZxMxVbfo+9LFhb^24K)u6FRl$?f8YksyxY2d$>*vVJ9-y;o^WJZ+)B
zM1Ht~I)Dl?4L|%jj50p_(DMbM%MR!n{4fST;D`0>#lyYH{BWQc7wy<tMrWnui78|r
zZ{LO|u3jm9-w4(~-}80fli9aW{Sh;8n<qYlslg}>Py89Nt}Vh7UIt0His2OOBCMd}
z14o!5E>~+dW`Fog$Ac?lZbTdgcS288*D?d6!`yFLVHIDXPD-i=$mBA(Ade_1R=aO+
z?@GaU03^;fQwpnr#y=>DJ*8_b3DmDYq~;)}HSnl3xEH^)S%>zG4`k}|d)Lu@*e!61
zJ6}zI59XQvs&OZtfeYHq{!FN5{3<LAfVx!}uvEwA#B8;oFDz6aj3htJ*5iV)T7{A-
z1hZ~41?z`cpCL&ol>o$rb75S#y8V$@-_qWRrS>=TKuay7BIZXi5Az?;04!?(oui32
zOFd3s!0ve6QNlT+qX$FCEQ1cUx51#yUFQN6)yghl|MwTqW@e!zF2=NybPC5sZo`b+
z)~`RXrpQjlLKcMA1ay0|Z>jzXxHh^Bt=r`QfGNl7L+xa@I+ORYlQW&ti2DVdR&PYB
zu?aRJ_!-eUbm3r}J*d5LuL$5a@q~jxX2ui5%bJVA>O{1mk#!ZrzW`XM^fc@U%9clS
zyjb{&Q}_^i+CUO1CiFUg1XuHe)Bnt~el~KKBgjCk)snqx$%&OUMWFc@^bC0*iMIFl
zdaUksO!PX*M=-@30Aq!N)Lg6>kkiEQ*&Q8&^LxY*sHok{S!@8E!reunQ`<EninWHz
z;vSg`2`s3>Ft-4!;{VzE7Wk-&>;Da8$?}LBk;R~bs|H;KbQRPEK{p!pqG+Qc#8-_k
zjJ5Wc){UkXC74i2m#ws=R%@%awQ8$vv9?02w!tC<Uj^&iTJb$`ZGZSit>*vzo|*gD
zySsS+_UG^aD<93?J2U6ZIcLtCIdkT5@odPtjFDzr7<WUDfvcY7r6<F`dJozJ|BBtd
z_t=})Zv0<)?w@^JQ@^$LafPv0KXT54`0V2mh&_mTwe8~yv5zpX#;Wm@R&NIKZ5}P+
zE*xzj?FuK@6{eyNDkz$5AThz{uZ>*A0ordP|Ar}JKWyYbk{%lwqC#farEZ{e(u<88
z2cFO=jg4H&ZN;{xKYVy08#&2H(Y2AoNwwcbzK?-g+eq<ZF6@NRXymYZp>3o|Hbzb_
zYPdGC7IkYISrB}>y(Z#<Ya3}w8yl&yx;FA7IHrBs$a36W-<yrRo6fC>_8iUxZDHMr
z<a`_1?i3!4RoEOGdE{XQY~*@IMS8c9|6okiu61u+Yp*u)%Vosrvyn&R=ph?q3vJ{s
z2)yUo$T?oJz6*`;+sF-Q(f`=U0!F{c{31ppgZnlRmMyaX>J0Wf|7vx91zU{&h6$f7
z{vR_&^cm7W<1@y8#Xg@c{p0$F-xDv!&K>ch^_)Z21))2POIE-|TMA(p*s;?u_?xHo
z2OgRVb;ZW5-oJ-v?^m{0*#vAY#xHtY=B2{>f<S<q6LntJBxAaKuWJaN{by!X@AFlk
zpZI~&TNu8TTcbH$9Cv_EOYQweURB}b;Aij|3aLo3^5sQT!YvOuL-}Mt^ISy};s6&F
zt7fH>A$nZV)F|hJbI1v)75ieKe$+_=mXP`x(h6&EuFcyP^&ecI{yhd%KkhSpuBV4>
zqv^>6e`nrZd+hFfM8}1&>LD00`v?<5DAgT|w@V269xMb0(43a~!=%2X;PbaB=t>H?
z;^MNEM3{}ZNtcw#tTKyFF!<HT5$d+aH_yv<C9iFdwQk-oHP$?xp4!1YO-u0v3443C
z3=f!GV%vNv_Z{}S|8ntc+8^2&98?JZ(Lt}Dh+aQ!A$r^wZSU{$G9q7BOpsVw;5Z*3
z_(r=$8+<KVkFRNQ5%@JmMOu5^Z4Wkh<Pt7tLT#FY;_@_yQIK>Xog9HGs<2nJsv9?B
zHC1w^z$abmcZj-yj9B($^%j<C5isceh6{o-)M3DzH2B2qXqzXE_6(iQSnR;JP}yyR
zC>QJlzEcy!NrwYztdeRXmKt-+16mT~TZnVPE^wdgR~RlPpcwyx1Dd0``k}Y_uA_^?
zz9uMPj`HgJ6rS!t>+>iem?U3E)A^OBV~#gZ_>x8izNA6cEH&*2y-OF%kI_JC7q>!k
zYOPJm0Ep)(zx}D1$IOR$Kx$d-R%M}`jy^${SKoLqR8>>2<moCp9fEYji=-`SwcZb*
z;NCDHb^~igdvvL*z!D|*?;tsc5x+fx?X2!N2|9}<jm^Icx}QX~)I$e>8Bg<~<I*z`
zlAFwSQ~mXs0)CNQX(4$%jd`Zae8db?w9lXHB|R>h)gKd)5l**J$TS#+yjCn;QrcE~
zb-^vFcGdD*sD2(VDqR2NpF#bOzgGBrp<-*H7T~GSZVui5bbhjc<?dfT{2BEo9eT(u
zj*r&j%S*WIOoHekbzck{`W|(1`E4BECSH$3J@x=i&=a|1KRJ3d3?`1pMD<RJC?4dH
zRurguQ4ZkEq2GU4p<nqPdl7R~DXxAy9_;2b;?}2!?BefKzWia`E#F%{H!MTEjg&Y3
z%&f4cTA>ub>Ux(%d6~t{8H=umpg82!K_z98aV~zb$ap!9^P6=nI`;aDyZeguThCFX
zR#nJ~W0(5y5Z$be78*`+zPmqDOcgjx$9>`5hdA|WlK71}=~EyN8$57DnxwZ^<107a
z+o5px&^!nl_zA15RhtLXEF>*)h~N_~po5gO7j8G8I^9_Zcd{JWi=EHJOz@W92DL+5
zEt{<E@UfX|fs~N?7Te9<OEH1tm5kU)j5T^M1xML9dD0m-$HipCv#0C#ZaCJ47cug}
zA9zbjJlinoa*hPcn^OVoQ-IuHKT2bt0!<qDSncUH+w4*6-&X6_*gFg8*Q26RM!!OP
zP>x;di+g+IDf;zk4O2ds`gPRuKJ{xK;Y*lIs6BQEE23Y~or~yK1-PZ9wDs$FSj%mv
zU%!Rx0_>kR{Q^lv$0LuuO{iw{j~eZVX>Up$jV|jBuKa8+?qH!8cL{x?zJ>$ud3X?!
zKOmSbBaUJAjPHfZd#4!*)wQ3W-skr$LT@P>dLZ;l(7-vb{a<>j8FMJrCcsCp)v5;N
zl(74Ej6#d6SqD?wI8d)mIzb)2I6)o0M8#m`4|dM@>BKXxk>0#j_?-6FN+R(pD{3>5
z%O8{|FW>ct<OxUO;M3`0#YW<>mfrEUf8`zea@(W2N}98m_Q);25w2iC|Dg!}Bi0u@
z1?rJUF8-6AC|JIK=UeWJ_UnAhpy}YjcfRGK9Yx=B&Of>5Th=1C;Q5xN=qB(C`gQtg
zIjGA!-}1dGIX%+08=TDzXp5ZFPp8m{;o@P=>8JZg3#moUw~QwY{R`??vnmJWe63}7
z!K4oU=qzLuKK-<vLm_5p_UWg$_7DnRLY~@BC@gTkWii~7|GCpoTXVi;6{mBpeVuRd
z&ksGF9G%%js4H#f(dpk6IeC@(%{EK~>tD3lo)6@P;yHR$MGD7Pw`n}-n#m#}tAHJ{
zO_FV&3&mfKG#UwCT7nDt@sOjEsDPORh`)I3jfsa;jv^LH<*&xsg%*3_A!kB^-68n1
zjfeR41x8N2jr#RhA6D*8PrBg1WCZH9?|sg1^W6cDzn~k<#pit&)64Pn`H{K-wqiVW
z+QaS*2=I8vKX-gfI-{bkJ$d~X+ug23G{i~=2Os8a;b>tBXE{Mk!KzpCFZYLHCWAdt
z$isKtca^VT>+n(2_C1jUkpO3X&s}JpvL|6r1`jofXNJ>E#3x?vpC`h$t%fOQ4p1hT
z+^9~#I01!;=|Vr$9uaN<V9<0ClntEXi`LlnMnu@La|FlIg{w(<FI~lDx|b)n|N2Kt
zR{l?H7g?%R{Tx&#kCsZ1j3P=USWNu7jzUbzavpfCCqGr{G)fc9#>u~=#ncLumf(mH
z=bAwSqjw^msN%ihT-vGY53e~~nEpDBQx1_Y=n-En>$|w0F}0FZm30C0Net+)%z+_1
z#&ig`y>vr%EePo?qEe{-8#v49cl{;Xs(z<`q=)i&6b69;0`%Jt2gqIor6}C-CJ%#$
zUk9|e`fU3RkwOO$Z+I~`PGsj>%&%o^g#We37P;0=5P}xMS)CaTWdZdrdK0rL+UgF<
zjj9v9$ChABeVaQ{@(~5c7=?opmVb0UQ2oM1g?KDgfT-g4*vgPlN4TiqFAH6=!nG;9
zD%7(sy$Ws~w)hFnIzLn1cqmND)KE&I-rz;jO^7U{zGF<G!z7#~gsOlWF1cnH5v4rh
zH}$aZ^)^KI(%bvavgPlz&oYwfc6NJd3Uo!=ORE-6ueupFA~hBdxA9>gJp7&y2jk&x
zKGbCE^e#p2qRNzKe~J)6y0j!)W2Yi)R{n&Yy04u&2&sRvQ!DM%!ASjuovMT11%k4@
zuvvI~0ym~}82%c>{>!uuh6rjxYZ%`N<7)6p?1kpPR$PeiY15u-gAX793WH(c=$-Vi
zpo_mZRV;Tjds+5u7XE~VuXPHK)P;?i@6v^<vd3i)WZ{1`?YlO3p((8K?Iv+WvuI|<
zitlK!Savj6;CkIeUH0obeIi<}A+OK&BA&b~PyaUe<3%mBJHOXZip9)MtcT+ll}F`e
zYH3vp*9|g>X0tt%eF`M>(nPktRoaWCAppyTIM5$<<jX6pb2Pf>nwpZzK=uWxZEcbf
zTj|_U&*qD$wYDXS;feq9Ft$#w8gltaqMN)<Ec(3mS%;6vZp<raSG}uL4LzKOj(pCj
zDlsou#Vx5`TvJh*U0(>0s&M)42Josw@&MZ^XneAd^e&dXb|{vh<p(c@`{dHW83&=l
z$#T>Z_thY!t?DNHE^IF4vTC^PJ`UY7@S2>oRoWBz!H%+<ukA+UVu-Az^s>XysI_Pb
z{KW!oE%~~5B-6ro!%{6?Qrf~&&)OTi18dqOCF&$tnVQmh7T`Tci{(QCb!@@9uv`~g
zZ9lUfZ=EJRS%PV4?WL6t3EPnbyRPhCvOfpGvS4lVnogDi7y1YGki-6v0BlAe`Lmb=
zqUER(E=(z_kbQtjBsr4O&<Q~b5W&J<q7?5z@W2%VO!Z1)wd=LgOR0IlJ0H^+lue?D
zlUoQc+oA|wW|<ap@m6WPMVlww%Cn}FPk2RJ4ViD<h}&3F$1$m=lVL(QuuunF+gDQA
z+Esx*THCWKjn06Bph#a_Gpv$jnQo_r??$_V&BblQL~&EO_y_fZKiY5nVAsY!iui3p
z*R++e(m;0@K4ACjc!FGe;r{`Yfc31c{@NG#bLyqkq5-kq+9_1q+}l)riRjMKST8Gz
zwJ5`_svy?FyzT*BDFErfJpWjU5g6V+8fdFbc`+06zbf6GuW+XfN9#E}vm}!^=!T^?
z58}wH^dMX}fM4}G{y?CdlBu0H%MNLLr4lE1rI7eq=$|k&6XhebK_pjq@Us_KlplP(
zS(NXH5&R&Ax%Bc_RP8eeFK`W_YTQtJ`C?~K5l0J}j5FXfKnLU9`d0g#Itf~Dr9ZUN
zn*{kgH)~{fGrpknHe2bpa`JwNytUAB*axZjTM~;{kDfMBy^9Dx?Fn=>*3-17dV}^Y
zfUWH8HB(%g){POGrgZND7SX?}R)RD5uR%3U7XNaH%y)7#!5>V<D3jL0wWcnlbDkPw
z99tWBF;mqYWwwM~+=0ZfGi$<kC`AsaO}Y)iMZ$K0vyrPVuxFMXA;lQVn@M3%^N`4%
zMyoEZomr+E6mqFmRqwD9t?vkuit};Zy~}56B&*a40s|a8;eaw4O(LJJX}b+Q4k^>k
z9Q({K{_p8`IsTg7Bnb(iwHU6t3~ivLDW3vLTCFRWGB>>FM*P*Xx_Jl#ec&DqV`d?A
z?vQ{fnVjj1rf^M)Z1tJU<fvam#$utlX@6)4I#e_jcJ>5B)eS+kxkk<TH6}WCa~G&C
zikXfk>5u4h+3oXb5+b0rXM{9bxS+kx&9}tR+5Txvz0ciN5F;i7rK?a=te{f3<=6DD
zJVLGEyMy08rA*G8-O9GgL=K8We3|m|k*c-}quxwp@Dxd!#iZwkOVV;EE=ujsq;p|s
z@a;FG(*khz5(O&UM<-2W&hS7$66lx#sNsaFApm%a$`bqqc<7?bgeeccb%5Pc56((=
z%}THOZAk|{#Mh%1;7DTj*K2|=)M3W6ocmOI3x)Jc+_t<bh0b(&102|N3#XEMa7x|J
zTe#h-cz+|fn*<8gaail1IHGD86;A{M)}YMXi}#qm_S44!;Nd!!zd9H2%Mi_@&U@S1
z<lo2qRN;IHd&MYyElAj-xO!Kbj8CV^0(dgi+8hd`_M*XwtD{Vs_7c$=O#D3*i2Vx}
zdvec3m0*;d>vc{QmUiVmjdxI4S5PBe+3?BCZz-dp<Y8~binWYh8*F66ARN|iphmLI
zGpQD1$Sl^@VsD&Db2@nM-q1--K;Yp6PougWpZCB^BQ(#wKXAy~JzUMY4s$qgCbAOW
zKPK~y80*HduVA?KbqpBtc3~%DHHXqvBN97xR7rTz8ss^8&e=*-pre>7L^*T3xPobH
z>}EZ4{F^OBsf)8rNELKdm4;jY0qJ@wdV=<Aa2LKk1#nE!Yr14_rRSa(naRZ6$qvfJ
zIW@$|(KhZXvU3o^@#HM@<Ul=44(NyqO@@PfSenvH4<~0FLNDfiYfx3bJILe-T_B2T
zM}BryGv;T*Du;Io>24~0`|OXpXP_T<e<~+iagG&mjqO$``(86<(LfENm~NG-k@zNs
z2+wL?$carc;SITXKab#kM9bv}4s9iq=4Nb)wo2z!x7XB;$aV@=bvOoP=)m`Zy1N7f
ziGrkd29J#jbJf)L+(_NX1JoNsoStGQ6<wI_a{<6YGND~`jZHEF0<v?M<a>hv5FCo=
z>8ueijo^?x?RdeK0*e=CmQ!F8KWNtRgXc9rUxT89p9dhs?wj$4)9fS#+!Hxi7znpz
zkPOUG*5GaL;u@=4!_!J0*1$$`P<YW>Kn4Y^I*NVHbG4f&C?eoU)KhI-$|=uD&IwPj
zGyJ;e6cUw-0R&Rx)Dhjt%o|H{)J+uYPuay}j0)sutOscq7sM0F$FrK%i~4;po2!13
zVRV$yC#|u-y(Mk62D*)Pnq69F3_lUmDu%4MhW%go%n6c%qG(L2<7&$j!^FC7T^udf
z3jg1IbLVe4o~lL9q#+>FuX1)CyqepDwNi!benW+X&Q3&uiGik_R1otBJ;_mRAH1jU
z{O#t=*F;etNL5f(8t9AGg<Itc8NAo=Y6eadp5gRK7aWEf<d}wB?<k`!N>-sRy;q}Y
zM|B;BNK;p(U03!jw}P(`M@%{a>6LK}IAXw|H&Fn`$%12d5U3u1AN2AmJ62y+Jes3!
z1HFcNP2QRCY-P8D)sLZli<C<CyVQWdO7BK3MCi=oTwF~9!Tioc0}3^0f8z&mHo2Su
z5jG$zG-eO<Mp)>>A<4!-YIj}gt5Pb!Lhzz+cG^NQ#;Btr;V2kquqKKxT0&SNa4mWY
z(1>2b+;R0wte{bl@Iw0I<ai`uTobMj0c-WjGW>uy-j`g0(F6!{{dliGlLy2`NvL%k
zJ^gTYmHzs;VaL?>okDO0>$8D$eWw(H^VOGtAd^EykkKR<&F*aP@Z}o_NP^)CAfoso
zNz4Qa`|e(P@{o@6BPD^BT8YU)UwD1=LbP!4(H=Xx^7$&z<jK`bPacq#&(uP2`Sr2=
zab=8YjM5@NzWO{sy0V9R`&a-fwcB4@=eT+gTc~n)^5U0XCS59~9`AWiVm>i7jS(i9
z930Mm6jOUk$SD~@5T9#pO%t^2G%sQ(8q|Rxi%p;*zOk#BIq>9@GjE8gb96cnq4l>L
z+5C9xWan9p>vnP&GXnSWXWGjMUCVDt5xD&Jf}7`Quh~W5eD!&NbbY%Nfy=KCa}iH{
zuN3*Hgs(mikgo5JB5?WjY5kw;(f>lAzWQ>3bd^&J!R6OS(NxP<y>0tf2+mhuE|9Ko
z-G_ynUaEBUC6pu2WkrB|^?87FWv3T`bNDk+V9d+8bP;WrHR%Ia<I5KZE}UM)htz4U
z)2sGLos8EBc)jElJnYMdBk-_43rxeqWIpVlosP$ApTr{<vVZY+l;Xo(d>DlXnVAg7
z1Lqp4A=z@ci{%`dS~rHWrF=lAs2spx?d~___-mxc(U-I5S~V796#6wklhlmg7<~<#
zGy$W$L%V_gLOq+4g?l1TeO$(aRa2149qs*b8a%c3SAMg>eo^^x**{l)<B?KSemFpu
z9fAKtAUPJkXH(e##fR_1FjxVm#eXsKYhHM7RSVQlT5FVfkrv|t(&|7q$e$8=HCV~T
zEKPqtAg!16l+xp54fB(jD-CBjO|Lp3oMtXpMwM8m;vYQK=M=3&)e?C#cZ8w<Og;bL
zi4K!s9m8AjR<bCk9~!HP?4xWw%gXGnflqN1xD7?|2pzzpE}oeVHPH7B^2#j6a-j@N
zYQbYq<S!qJKCo^$*q_PGgVKL>5D&G4*l7_d!LPHU!tSa1*N*pr3&yx6flg57`e45N
zu`rK?^VQn~B@+L6y1kL1<VIb|?caGiO%Kk~Z7vH)WYZ-nhXI>DX&Nk7pb2=Y6-uaX
z?Zyz!C(OpHW%eDV7^3!v7oU+gY?BxSjuJ&|gjbY>mizoi-5q+=OLS*ZeG>AJZ?E|#
zPSm@iZlA*=*3zhxJ(24_Kp;mibS2ejx}b1Il4=QR(Mt$p*((}R7SRXh?9MXax3PNz
z8%@&oB~6f#cq#SjPb`AhW|osQbDx=oYo?GczEDzaW-%a72y#5c`G8-UP%$UU1Y-el
z<vje6)40%dEs@{`^Z8YEfu=ophhYl~;-4mG0i8Z{loq6PPXLwG9rN&rRlf5Uc#huI
zsoIa(l<Ns)sRKXKu9>A~VA7|VpG4$~0n2~7*o|3TEU79@HO%kEuwn}Qo-Q7)GGaH?
z^n^to`liKvh9RRm@B__sZ!NXWzJ?Lb&%%NYis@_dn)V@KH=zdp(}WFi2wOns)mV@0
zzB+fxhngx{7oGCt8#W_fFy$q0;c6;I5w&&n=imK+alg4I^3Qi2WsRx}=<=cEqUtwz
z@+fN(^b3zs)x<IoaI*U&Cv73Qg(Tx*Rn$oHYO$Q8S?;CFC?*ylVQtu0-9f}qqUhz0
z5_PF^%2lgSOg;LJ7HLc^gJx-x<X~nkAcdrux&`g1$$pxS87i&K*6W1VNiC|Z<7-S^
z%oQQLq6d+T4I9l#{5ld|ulCt&SGGT+8z^Yz7&T4}mzWwFKBG~=)dDxFu<%VrMmXrj
z@f&E0sAJxK&xBKSWEb~j!sINId~%vl_aH*TZ%|;tYIfBDR%VIhsUz7V!50QKx$!(q
zr6yK}c`U4aZ+gqd3}ev@BP5bdsE=QNk8y<N?&lEobATW<yJ=_iEC>YVPs0l4;Q2ur
zVG)4{o;ksL?fl)+WRU|<Ku*!BJ70azxpp4)%_j~vjU~%&=F)pGAfK#w8qn%p7!phB
z`Wovx-&5B+`*`bGq3c@n4ZE%*J#|SP;Xg8-D>q~8ufNZ^za0JEAC6629akwklJ?vc
z6v=_-=O86CL4r+?Iu3?2ZL(5HHTa*P3b-b!<(nM&X=~|<aOG<dp)sM~$G!9F4Q!0<
zZUa6JFmbp`yTJmr0X_feW^B_iOzb`jFj%>G^FS;<wWB#mR#O9Q`iscM(d%cytM}+N
zDOGo2D}(f=B~^;=-^E3DJRSRuPpJuQRU45Atk)3hWMWM((P?l+pfv*Xk#xfHudz(n
zu9?Ix2C&QEQ;;wiWMVfiWFXq31?_)(iOnJ##7-(i>=2jO%_yd32ti%yd;ieHZbBlk
zzJ(QC^*m(`VkJ!zD==fQp#)_fVVMq=p_oYQ5&*lz?xTriVs{ycMT1To3+#GVbdvoe
z8E86dawnRVns(o1u2#3><E-pOQCwMDz4B8bDsuYQZB2XbC689?5y-9gx37qhIFxnc
zD>nuE5{w@hW4Bb_#3mGNu|QCLAiRVhr?&U>0+?P)>-3U9xQ(aY!@pK$(*O*#*fc9W
zqD$3-SEFO$HW^mY$Lfi;Rxfkcnq_YB%LT9&Si1tLUD;Di0vzNdr%koTq-Woc-K(Rz
zvVVs5#kkK50wVt+6g$)vqFew3r1Wwwgen_F<Vu_x%5_~R;@k8Xpol9)j7#J;S+y8u
z$o29^qH%uA%Xc9aDTdv#l~#s!?l&wbQb0{$sdPj41r&toQG24@mjN;VX@CP>7Wp%=
zJB*+}_cW3(^7!Cs(vPt~Tp>7{hv4C2s?N12?Ka_mqkW<0OzeIb^L!UTHguriuGS%|
zzD7WX&0WB|H6Rnazvl&{7}1E-?MO4lh%q=<jL--QaZj|Q5hB+d)oLm`g!n6C*Bh<O
zk}AnL3WkVEjHP1|a#Ic=lQbbr>>fr!M3(0e1l2UkESj<;XL#ds&f1zTHYoea$eqYD
z%e9AWix_UZMd&wbd+|or4iTbZI{`&2bpi^Y<4?KNu~JBoHf0GlYy?>m&#^&$Op^hk
z8q{EPeLd_?02?=>B>(BWc`xcx33WQ2&?L<6o+^Y8_VV|T4+@qec~-^@bQx@R5)Asg
zKk8p^q7WMZi9%<crgKS?+)y3?x!6Q<1%4psXXz25A{jCv0(<m>VzLrTe{Q2qe>Vc<
zx{$ag+2iQrc62h=vnKq@RuC17kVvNTU4HRiA#5x&zlPW&;H<+SO;#3M&9wo390dq(
z!;h_H4XT#1mj*owPr%6R?4DX=laU07JCMYGy4*Njj)~Z~MQ7vl=B&DI(SM#kClct*
zKm8@fZN1#5{nHae)NQYS`aVh&@K3jgb*2$6>Yvs+n9*fD{^?I)0AZ|}yI(KjpJJZu
zx~TPEMW;qJbW!h(dIxjkqF#*x+C|;&InQ98<Dwe#_Ox^(uaEjeP9t0&_0OKlzK~Oy
z@lkhoD*MT^Ze_H+R(M4c`^1a+s6%m^FYNJ8M?t!Uebluk3qEQDGXm|Sj=)H4cDMR{
z)YCBcg2iY7Pu)MJk9tcvo_hCD_tG$Jgt<WbsMZ8HU$6cR75aVDgTQN^j~eFmil*QA
zoB!nQU|8Fy=y$>tZUkx!jc@M*tXC5&%&nw(eAGFNA!W)RWtj`@nmO_<2C!`$6Y4Uw
z4H#r%_r2Oj{h6SJTjmmLeAM>F0>qvzTQP;$&A_6r6N0)Fy#f-u35g)&IAWbjtRPm>
zJU(g@o$pNf-YgTbYbLR|KI$Ww?0{JDQN!9ty?Z2kk|=M!k2(hQ+G_pkSg%?eA9dwd
zY_&f4X;;%w@6sG0oviC+V)qY9Sz-Q&$L}Y>DKX>y3nNep9jcx#$CkRO9nk*I+)e#G
zL_kV?{*~jVu10@1x+reyJs^s@SV3O{&AU>X*SM*_`WF(NU^Ly-(fCRSr6R>#H}yqs
z5rn^xq-#}A*QyUU^)a|Ekh-|3qqfXVy;`HVmaVwK>up+nxT$kAptz}WJOGx6UpE}&
zaZ|r?5ye={O<f>DlRhHOXwx%Vh!4F$A=0NrSC^a%>HQaTQy+O(gm4o%2s>`-_r*H&
z?WU%~Yzn`ddb_w)Mr{uwJ%!!W%$J?MkD8@TJMpW|De<_eapQnCsP|QIH+2Zuuri#j
z{0jyRttxKnp+X4V)aR*1P_5;_U(`)4qeoo8O?~xC;--ED<ibsT3O`WR$)u}Dr*%A4
zM%vrN{lrEYsB9OipVwafsXcevT3>ZPIM(8;{s>Yo;;Uv6$kL*D5l^7_HV|R^s*f_t
z<@Z%Pbh-cds-F`#@P7>%_Igh<4R#CEOz)YymE92is+KA2GcEjujk5G72jPkGs4iVn
zI%M<_Qiz%Yz>b+@pSE9tCb~bsG0Q!^!7(2pB1EU$`xACb7)4Ixhkv9MKdGV^aP$N>
zs2+Jz_gkBWxGwyLguf86&dQZ2xPMoZ6lcW=`z^sY<nhy)cS)VI5Xbz823CKFq>l7W
z*Yy4Re1|>=0QB)z;;U$gG==r5nbSy+eVqKldYNk)>(zg6V2;#`&{|OK2&x$v0=4`W
z98e|Hq`#w#*IXU0>pf_mn5(NH9+<0@_(2tIaG}iShbfzlbmbs%3BD)Qd>Uz>Z}`kZ
z?!D^rzgK^@gPc5mG8>|sDr4)<9*^NgG%5O!t3R2?S;W<0qdy<B2_eue(Vx{Eck=b;
zE9W`%>EV(3bF@ogy&5GxK$m(=621EKJ|iw3{dwxI`TFw@|8QsY=lyd;f4%_mK!2L?
z1Ig5&Dv$o0_mpPW=ue2Vh|huk;Cu}n#3wjILR&=fJXGeY()prXi{Arjzh^#f_c+e1
zT*Z*~6G_w80u)^V$9f*|b7jHC-yv|h_?ry=NnC0L9mFpy3+T4IcAz+Zcfzl08g8%?
z3A=g}JsfrMjr?iz8MUoblsR~V`8;!0M$9P>6p0Gog<uwzKL%wV(S<O-0W}uRXM|ce
z&q(c<mnwyC(siL^)GROJe%I`n?BYV{7J|F2MfVQ$+VM@MXTOH#e*$J?W-7Lo{NKK=
zF#p*2TY!J0{*UnA`esaB#})2Y&#n_!ay;Lqz9$ZK;e4<DU}>J?M;Z}OjvLVT1ro0=
z2&wDHk$)b1Ph`rIWq~5334$DWeZCW$2*ff#(*m5#%2G#2&BNT7*CrL)X;Oe5AHI1&
z7+&FGJQ=GLePQ(9Cj@Z{MYGr&e8Sp^*1vEwI1Mroe3QWOw#0WCJ%nvYUxpUF4}A9c
zEK(Ddx|iNmQK<a#(Fb}fKM;8??zLv!L<7Os%F(bWCk6D;^pA6(I--RlkGX4l!;;fK
z3c~*ybKK%oEavrbRN74W%pDQedaWzBG>&{Z1>!8QORka#d?t7xvSjr^m(K)8nFKGq
z8V&eGxfOWo-@xqq*5}rrV}1~Yf%Tz(oW4J|nA3l9zE=_puW%s7(|yTrj3W3C{5xz+
zerfD?$F5aJ2VHu8u8NfB_->D~-jiYoo<z61xCSO7YF*e#@n5+MEaBiT9Kpl}@_TNQ
zFi4mB1Rgo2<HIrD@3{KCo&!3wBh$gF#+3zdnlrcnzuDUdbTHXz&U0wNb<H8CW;m=p
zkqiFPi%B-^l}HB%p>pvU^ik9<K9j4!B?pkJo-Q1s)A(=O+2%~}j{*L4@XuqxLsxt7
z5BSaA*KZyQ(QoDAzw^;v=$G-X6;l;`#r-Y*&c%G4l_+RkP5l-ctO=B>bwB{lbMA~~
z><%K}*IE<jS?SX8_2ObBqc}n|9*-?(P&vt*P~`{`LZK6?4G$>Kjn8oZ%f|rsRV7H6
z4v|jBrD9CSW}oRP?rK<ZT2Q=2s7>&$GH=9q3Tw(lhMaCkjDzSXt(!}l20x6WAjI9;
zuWiy!fAT+g`2RZ8My-SO-3tCEVHzU*-;4(j|6_r>7yeK6@IRyw{}7N~2nw$H%=o_?
zYNytrQ*H(S7hxJN{J(++5C6LXcQ5>(;^9A7h<^yk@Zb5F@XrI;NzfbZRllR^BIqOd
zi>g<sn0+~CP&UW5YCAs$;?1$czWl%Y2RC2-lbB}r27k#PeEHOGbh%JT(@@?LgO6F^
zcr0TrW^KLy`9rYH-v<o-O#iXZ9^j-#Nh*TBgHj><9h|DjMx?sz4!ZggD`6P0fuG-y
zp#b|jYeD;kvEpRTLko>xV&BM*I)M8<^NJYw2zTn{WwL!}A1N61c47FO0n)h(C853x
zMJ#~P<G(<qLTvSc?5BTctq-fO{onWd33h%Zz4NF{1WV0*erv%M=Z1JME@us|Nwsyt
zYa@O5IdLA)ogOwk{2ZCrRB)~xRS!~+CB;x#tSg~?n(1#~L5l&+MRS~hkA)Q3xvS=|
z)7T-Yqv(&xe17ly?2wdfb=RR)$+`5;y7t=cFF<v4>7yulSOAM;SynK>B~HB8>32MN
z&gNUp5ti!Y+Vyao5>X@3>+DoWAeAN8CS$Vt3*3B(qqLq+tw|>AhpEn;6G*`ric2r1
z4U^6TzeBE}$W4;Z4C^G)h+6`ZGparn(8bj=+@w$PlRmbSAX=eCT)DX1s1dismBRHM
z7jLg04Kat}w!rR>*pWnt$J3vH80z)w9@I>bQ4eKn{-4{pW9u72<UE0n4>g@hs%lB8
zOebP)(_%WpMC5qFMAEcT=HOroa`XXoB*2s0?*aIBPdY}RR%Px5)2##XK#aYtTR0yJ
z)KT25FpNz=114vur7>7Hh%!gc=^#CMk~=_t_tU{Tv?kj=Yp6(>NMyD>K)$ll9Uvis
zDS@U#)lV?$tPSuhj!uNEx`U9|^!^-CXCkwJ0Djs<cvE*HkhzkjyMK&7pf7=+KnKEv
z0d*ueUP>%Urs;i~NfVh(rh}(clm#HQ`uW)E9&8y7#}&$x)VnwbWgk<ov6p4a=Sj|N
z<ZydmCO9Xjq#T1zU@bq8-98;00+g+t$@btUVMzaKO~!?fV4aSAskPrHVZBzZ|Ienq
zVr-LDn}^_tN~Zj_VRDO2y!EBStaBc-E_@6&16N87zF(B&qx*Yt*Y$nt2C1CS#%9{5
zz-c--4(vg6$#5%8BI--p^(AzDNnd@f^DAOK;YHV>w7TIz-RfshaYcnmv3N94f+((0
z;7>_vXZ{RI?U|jzEda3&d~Up_Cvw%FA=%w^%6pR1#FPr1@~)(ugA^}OKSS6UDEvgB
zxl#SBiWt0wvDux~o-hkq_0$EA@{#{!I~JO*_s~}V8_83$P<w3-_10b|uIjbDTHmbG
zDtBxL$j8MMlm>pIWW+lIMvsoRAT6Bf<e&m08ilURN8M2WRk)+=N@S{6=>VR?U~wi=
z&%E~12ko-8cG;$2_k7?;2Zxm#-7mqzg}}%bjX}mSb@H9k17fz4?4X&9<toXVnu<gT
znk@#niQRj72z$8<l~Zkzlcd%pUBf72Ao?acn2w)wbx*WP#yrc6d4B~%gyhJR&{vfX
z%1WRI#b7Qs{fSlN<U^(KF1gPlH~Z5I4O6hiW?xFen!uaO5I3-{>);@7eefaj;)8J`
z5-6$yf-0NoabN;USXG#5r`QKW3KfGDLkGe?Vx)Ys!}L9+F^qA#%}WsyM=q~nuKS-G
z(>&^J``fnZcn|VP2VaJP(5B;6zI#l^C&5C!6niTwbc5+NS}(*y1tBn+(%7^u0)DkW
zVg#InA450@PKQZs6H}>8Of)-T@?*xn?8T<u1+Ut;RPwbPuiCN<#jBTsnT08^Tgw=h
zN8sHV!%_j`_n8|O(+I}CSnRX4SQq)UX?L|0TB7S$2Rl@m4{de-34IO{sSV5@oeoZe
z(L_Vl_HWb=9EUL(@?}`$NAG(_{Ze-1Ok~$t_Nf2Q<^ECsSoI-1VMEqU7`5{p03v|{
z@a(au1@{xOvP}6Bpj5wSV1I2V`$l(<)~H&$%iTU$G^#eY%efjQM^_U-tsNS19niW7
z@S$Tr`Wy?Yu~}R7o|m<tW~~NP>3P`>xvWhOG+An#%i05&@#e8cBw(%Q7-22O$`B7G
zYtJ&=t69tL1-cx*{yL}-Uock{G4%fa9L4u`)6eYLI~|4Zk6{Q*Sh&3ai*X~kXDZs-
z6~)o9D3iwrlDrr;RW2FfdsLZ|(}D)_fK)I;OmI(R=pQ5y8iUrx0!=&iL@MurXu8zU
z6>tkhC(;lva|bnTXR1sRKDz@G2RGStgqWySz~w{Z%SC-XO;I)K9yVAd>Q`I}@O0en
z$-oPqcEhLv&jLojN}UN+G<B31;vKUdEs-YkS$|${9$h@Ef*~EJ=zD=eMKL-~rTm;?
zj}|P3`YSNAB0Z}<9Acfb4&CKulw=UIs=9UKVaJ`*dEA8<Ak!lrJbZCY$qe!!w-fA!
z$mncu1s4^q0QNYyhQoWQAtAE45)KuSe>R@fmZ`9we}Sry9xpL}XKZ;q25R+fu7yAq
z;%lK7X#X7d391ACbZ<b49wKO5x=>pPB*hSSXc|u6AqIU(0&-11uhn9F2lf9P9)S89
zVyBQ*&dmUxcnwNAQ@e!v?XU9-LnKAZU)g7Q3WZ&)k9d%?Ak)wC_IegD$5qK)KC12c
zaEvv_)s@BKhm{mABu|HQ;PE5p(-K<@FOFrBOYssPn)w&-0g95Awhu*B+~&^*|1?~U
z{=s8COWn@4gJObz`O~r#%4votUZo4sMb)#v(I{j1>U~ji7*9;7)B1z&TQ0s)ec&73
zAAHknd{&TWr;4By`u^~%e(?JSD}_A3Z}IIoPJA0P1UafYT%CpB8fBT4{fTH&eDNg2
z1d(lPACo@ao(tdH%oa!oC;fGZ{XLA0Oo8R7$FDpz*bj~NL$f?!=Nb3RJKN;3dAE}p
z_-7wkMd(cLoyRWB5=sl36?Z_yBj;8KgQvB51Y8d8XA`Wgog+Fz0I)7xr|$@<?kKIm
ztI5YbE+Hbs1%(;C|6Y9wW(PxUuzNP(X!=eCIAWRIM+EK7bqt2f1$XLO*o7vs%q4Of
zLfs`{wJvqqFW6-I$Oti0L)8y4I1=F*8sW7r!a+pX0y@-G7vZ&pIr{gkpiAA!9)@PA
zCpO8sgrhOAeNkgO#>GYfX>3_~h77eXsk({SCfu&Eok+U_Yz<D%+jNS7?M#jBUxz!)
zy4Zf~V!Mslp8uuBR%);{5}V}QY_Qd9Y`^wl<8{I63of?h#CEm8cK2^JZOz0cIdg!G
z`)?PcSRfUp>edHRmHchyjg$Co2&AC(a&R@+eZA~4!?`Z9$o;Fe1eD3Y?+YuJ@60Y!
zr$4a*YmaAp+hP`hu4Ve1rO}nNHKHf-+?~8R95eodPzh-20_NZ)!S22AiqC+^JKDVk
z$!5oJN%-4;!<(&f3!6vqYNV#gq>IJ;bkT!ffUoc%+e-5?<<gR9_HW&6b1TzU^(cSI
zm!9g^S#lBq?{?@JHDOz&z8g7po}DTIX*=}`cB)$z7<0Y{W0!E@I1$RD>(TB@;bKy7
z4OVa=Nh8Tt&#HSue7W#39{)(<5g+){J@QD{;~Lb)Z3%JmN@iksiSlJu8fW9B<JuiK
zy{tky=sL9wK|~S#AJG3;W#cxi5<SpvA)Gn1tK7}5(lS-nBkBU>CGBL&woB=mBQVp9
zkrf;fVhL_-ZnnRCQx0n&l$QXFEUaOPV1fQBQvJO45rb@LFQE7u(BjV8f}}LMDHn9M
zNWD45+(aqqD&A61VzXrwFTCg`AOHi!mG5%I#%k|Jsrftdi9w6Y%VCz=@DON$#tye%
z@D4s}gGdY@)(Yb5!z-3a!FlbYs(pF5iwh^F7LQ_t%L~(Jr+5Dsr?AfvS!RHm9&WoC
zV744xt>yjT-}2-@9Hw{lQ{#{I5ZgiSIoV;O9q!4HX0y5Qr90eZzt_#Lf>3j*M$kBO
z4Fq>v@g|v#h!L8uL=~!Dxqy<;xee-mlMAiS%WYIQORhcWNf*K(xls_9)N~8s<QSLx
z6}|AHdr?L%tT>p%bqsHie(<?hy|aAW$A`qozBBAu{-m4S0EVq#_<%)-`ZkH@290ap
zrN;b>OgSV}NQoA2i4T67Q=&4z#1klC5ZZ_qlNWWb0p-YGzINhNwM51Xt6fUkLMLw9
zm(ZX4LsQ5(M<;cmFo8ybMI)VV`GrC}a?k|693k3N4NS~!w?fYRq*;vwrMRyAY!F~l
zHGS&CpE$fx2j1|$HmK*kuZ`+q?`yNV53i!~-NS&lTVgRb|E*dFQeXB6zd-vp&2sV$
z#HC!pT75{+_NasFU-qhk2rCoW0|j)zXZITlsKQ#&HAn&CGflQuv_q1xKkqQ$7d>{x
ziw_e9e*{k<Pq-rXOt7}5K%Q6dYxR}-m};U4HnMJ9C;m<P#S2$&#_Q)JB)nx4_5VQq
zpOiq+_{IG{hFbfABf0So*eQ6lea0_x;t{{Q-iOtmuWxO<!8hN30&^Fd<bKBs5Y(Ly
zmkWOPJFs*F#R^pU`;TI}In}C6?O<%GBwLm0<{xSNEcA>n6!jH~ss)}x_v%71U!j;f
z)l=w3T`2A=6juj&3SFrSC47Yvs=`y~JY6X1E0k1OHh|&I(uFKvAxo|C6gol|YVZ|m
zP(Se$+EW*5^c8AU^F4)z>O#%FLd|Nfr_h^^P~wYQU`<n_y+W5HHPKUaoi56u*;kZF
zs>D<D7F~2{eo-c=Cx7VE%FmA}kp3Z`#JdfYy73MSdYw$5lgZRNyg1>E!5p6?+YV<m
zMeR@rJ`Ur{3%AWI(}9Q+fCGVuhAGb6oRdNwh$xXgQZmzTL86)~ZdaGO<rc^eR7k)F
zQQ2W2rV(98FZVR!L9Q8UM6e!#U+uZ5{r{+=_&hSCw={JR4rv<Z0su6;GTEV_6e*g9
z%kQW13Juc4w}?;LrH;Q=)6k%2>Ow=xp&@0{kOB=eNrM1iv`W)36ExT#yW>vfbwH+l
zo<@kp7F)hZ!)+%9HOXgdlJ_q}@`I?w8^3u6t5*!ST>k@2ay?0|*J5jSNN%=CZU)K6
zkYv%*d$7lliyy~;WN&PGG)Q(_!3I_4aPVsc4e~iiw@HkPt(HV<#aS6`0-Df#k-NGh
zLY`<qWr}HKczN}m@N{7B<NOv8U}5_-Ow>$EM-_m%ya<dvmBmGJdG*XJ0uwj&;DW+D
zm`D*AoDY^Mb7cXT7ZLU>#81+|)E0pGRS_834S}h-bRnPIzFq`IHlYCq7nf;%7$l^i
zts(#?7{bQ*0d_0`aH0X2?FV@6j>4>;WB^X~1N^=Sz-$9B#}Cj}1mI)?ApM+zvY9@q
z2*4ZzaH7A4-HQOsH2^310p3DzvQT?B7ywu2F?GgtludD85tv2;<LbN%(_REd!i8vW
zSLa=rlMBKGTS$o3U{~v1s9g&~(Y_fdSBG7wZUjQ}<q)KaF;K1+yHI!epu}HFRnr4Z
zsEr`Ru|Ns6=zE^m26c(|wO*Z%S8ZXp1A1*m(pEy%!qR6)W0H3M18@S;^SLo-QwN72
zd`Z<F@X{@tNhfQS)hR?`%utw<gEflwYPhEb^RVJpT~Q>j4taG&^6HUSPkI|nEI@2G
z?vqDSy-v!GbH`}d)&|hZXvg<ggCn#fXf_nJuH3{tJ$>$EsdNideBl#4eU^L!A=BsJ
zBzOA!oyWb?=k-LDiA+HOJ$-)p+qu(cgKHzo1yUzE^rTyu;;;Px)2Ox>7gPA^mhU*t
z>tqmGWsu=wM7ROb5i;dXLvLHm!rnAkX~B${^}^M+A@hIJCt5#0&f<S4$&*0t{1OMC
z8Lw>@^@Cr4_twqv`TMd1>zAnuc5_}7JRI&Ffr&x3S+|L1XF3HoAJVj+&THo)IsYF~
z6~23B$zoU@yzznxogo!B{Y~$Wc2ISn&v0$=!x(woc+U^n^VJoG8BRs_?d0q!lp5)s
zIfc~w8FouOrQJb_SRvmmETlGg3cdd);;|}xg(}n?o<d_ZraE6CT-f3%^e>I6-dCtz
zoy|h|@r42`_nPF+k2p>^-Ygz0yo-@p&R^Kx23qDurrIvC%!MR7f1V@`e@<Sw?MFDP
z1RT+N;J_TkiaB!>R<7qL&u~3eEIk^C^C3Ob-H5S`7EdtRBUR1_SKaYtK^uH)FZ&DS
zocX9_oSbsf!!H{C?q<GpsngTC7Hm0`V-1{j)j89LI>5=Ss}9qLq=vlWcY5xS^i6l3
z1tv}6zrY=}q;@UAdl6E&ZD)+z)g8?!g<W;kx%9qrouSvv^-2uMzxb9W*&@l7p7EUS
zkbF9;<lN?TkX+3fPYV)M7gm0mTJ4+hRDo*8->6j)hlzs?6K0=CeoK2MKlS9+o*>}T
zN^!#Loe58a>O}Y(79elJ1K$E#P~Cwu%y}?Nion3<5SWSrFm**>;EM>1OPlSEHK?j0
zFc@-uw7D>wu&CnYM@)$A!tHgdN2CdLf4k?^Qg?Y@Yt_wo)qDT=)m|;fv{j+TLj2h}
zb~Mxd#N{c!<_~m#Wc?c+Q2EvJYB}#$>36tfy7-^;JKQk+zCyoCdqF#?G+K$Y>xH%!
zJrdVT*9!t_QHrkDP68~5O!sSDshFo-FVi8J;&*;z<wEiegt%Vct#Vzj(GPiDuRltK
zkq#8lu2;jNT-VFs+K6(-^)j_H#b3MYdg(&qG^q)Too2C(iT24xBEvN>a_V9+newJ#
z!s)nP8Y#VKkLyJ<_8-@)*8yiMGynhdN1XkMx%(xrgzgs@-);Wg@Ks!K_$g3SB<+?*
zFb>MhO^b{BRi5X?ba@Vped8B1DfnakD(}*>nKc!0WnB7Qdb)Zo@5mFz4;FG@>nlMH
zwq8=4`n4!t!A6mS`IWS_(Jk5U>ClUvjzp4_0jSVDTS?M@AaH4yK1n&s@lsK7NY%E!
z*OOfb>Uui{ruosLDYV{d^IK<+{6SV)@9gVq8i669Y)~-J{WMyE&YXn0GUeac)p6!J
zp$giW8-Wm$@x9_|D8@YcQgL;`?et1IvEybZ4s{7&!broM+vgJiNm+axh6zW@1_Iu$
z3$N`rD5v2j>fF60w@azp00vA+7t>h=Q!<P1<Pg&*81UD&&||`Xrn>z|62^N7l|?2Q
z7`Ry5>U>hp`d~wjP@6HdIDuq~TsM;zcR50uTWwFj4{d;m*+Onj0-JHNX$wxarzPa5
zF;6ii%CPkk98!oq_!d|P``HI?rSAvo=}4Teab-$Z0cWCh)&8PxHR*MXR$GqqR;vah
z3XUR<^X7rAS;Y<W0N$q<@EU~YivYK+swa7cDz`nYTJ_D|;IDPyef7KWNBQ8ppT-$9
zNNfrvClZ??5|cB*Bf@Qiw8U_VlY-9FtZKx=l-5->#Tb0`nmh(=;I>ukQHh4v-f;ox
z{=8Rs&0v20E`#Uw1|LVcg7v%b<9+bm-4Kwio&h6<wvsp~5fM~(#K4qaM_%}Tt`uwp
znDL7oa}exZ0KpAK5V#a91<iRBxO|*Z1c6I|2Z2k0i(nTY0`@~}A4<B6?^=NF*Ouin
zZlEj|Dp~+)d10tp7iw@tzK|~~3?-woo~sPCq3pGQqYH!F<jT@z$`!@-g`sY9p<Je1
zsOJ!kMr%8E!iZwI3*|E9LjBwaB~vL`c%<a@;%5>MGN(<#9yk1FbI?}0&IQ5k@!t3^
z+v+}&!OeOc--7)k$Fnz}6CxhhrDouStA1(igm=`XCVCPYnQ*L=5Tw~<Qo>CV`-P+j
za5UEOmVkLNwM>n>%$W>IeT&(DRmh*p{;A&ny5=Zu1v!4Pp14~Nha@JAb(7Ycq-kyv
z?J`U4<tB-BLelU21hTKH%TZ|#+3btze19tYnmWOsN@qbGLbAOMZ9y&Ac8Rt=!Jpys
z->=9ij1=w_lkGueD<PFYwt;P0i)M)8RqeV&c3&r*ud-blaYF>}+~W-qq}arn$onXu
zLj*@Qc|!z(6t>7}7tB}=X&vBEQ#sF*rO;?vNhbajJioNlH?%^;==2wLx^d=a-7ki?
zo;J^$nlsOG=DcVAFl^z*x1<7rE4Z(77Tjo79mDhH4lnCfn)TCAK(l^K%4MBLC*_bQ
z?sobT#95pmUsH3ZzkDj%Zny?CRI{e4*`ez0aV}M7=TOCORiQy1KmkqF?=E(!B1Q0~
z;OeQ;77!&*U*gV<G!A>}Ll`ImM>wQjf}1OfB8Ar7h(SfvW`Ks@Bj1?1q0!7UQX_GV
z5Ne{^8drffOq3!NSpsRW2IY6(I3%Fz>1g-WRpfq8yOO#1I`DD|ART-h-_@}uujY}W
zn<QnK{^S?9X;ftkAd`EmI+4*c|7d)FTb}T?08P#UbKs3pjm|M!i_$o%QflqdrcbMw
z`AMU?3p;t)(B18{E!g9~6gUtul-W$9s-RD&F|7J9wD3hXA7)?bW2kd@1*Ti6v(4)1
zs?DMC%#~RhPF@8T*NjL?*W}em;kz}G#j{GCL^+#<vn=?O@ZgIFWrJ$5S){02Q&XDc
zWTXb>CXhYM#)5&{#lpE6ttL7OcI#*aM;iq74gx8V(VyV6(wirD@}}#+JHOO2IslFu
zWQ5ZxP?K3YZ5-3^+5r4C^_=yvh0uEp8obCif@^p?wb_gVC1_APT`ESW5|Fh3G$K3!
zyEcKNHoK2~3WSG-N*UL4TVuAae7r6@+k(t*A_i<`?pO$d7OtjJocXzQSY$qGU#d!X
zK5<W=g<cjr#?N3;d_7<mjFtYLyk{o6@J$_pxmP|U8fY5J!(Z#cbD(J?9~m0Z-(ffz
zvri{86>%~z8AiFY#pIeMX#vU|%{3b;GCLr*8vG@s?=GY<%>K@63@-pA%+9_;OO4r?
z@n5dl(FhJzA7LQZU&NyRMFE0E7eZpu<z1rAL^3<Uu;KnBys0o2-&b;PNjI#4P^}0O
zZaWoplJbr6y69NE>MiVKc^<!~u35%?9&Jdm(7`DItW7RRU1DdJTymkh=|ZZjwtI{#
zvy|0?XpT<0cq9{Bm}pKWW_R!wGl@)E%t9MBQuRoL)w*gBK6-o)_x{Ubjzg|oA5rHB
zx()@{N%$e{(;=tRwV-eC2>Qyqyn^PM8tpr75!Lqn@r!Z<4Frd(@4&$13EHg2rFs8o
zCQ>y<1brX{eaqFhpbrWHJJ=B(KvL3S7cVf(ZK7c8;f>mXxMXh*$w~bQ`LXhBpRWTf
zVIWSzX8)oA!i!Ga;^unm0^M9oDFe{rX)Y$|=8{ab%(Y0#Yc3`dQhtjx*E|V}1#kZV
za)ODjpcf>qCI(ZwM?KK6)#}07xoEX>b*ps}1WD{358vr+wfU?!6A9z)Q{8IgzMRu)
zKyavf4i+%4)d-31@kCHs?JGM<tIb74Y7^|W?j9|&M%X6(f%PL?rY%8F)7fkUeBTb;
z0;WY??Dmle7g`S9z`XWQcm?uN24g>)-JFq3f;pTRl}`gWO=((wQ1)lt(!EfoF>uM3
zyfsZLQqwe3(=^mHKd+|wffSr3kJ6Z$<e+t<(WJ)gx0#F&t`1|T$E8Zr<LS+Y7hPd2
z0}Vw_({8R+;Aau3E)c^BpRTOMQ};0#AKd~2F&h`0ul4XIpz-M;le8X6CiL(&q~z%#
z6A3B5MfC9R-$X5$;6tT;J#28SM+4AM4;vuPFGDC_)_T}Q5F}9#YkuR^!|PdZCUVta
zTMw^6m$I)L)(8$&C&7hZ8`zyiT{BHc=;3jI1cKK_i5{Mbic|yFs#&^wGeKP2`#N7e
zwm01N1XHAeVJF!f=8F>8S8|B%&f(TOk*vz*X$dbc4v>oh7Mo?Y=miR*Ux}3L#3B{u
z!kf};6GDk8=e)(JjeTX8<3t|gn)idSFa$kXxVj5~pGzOZH^unR>o$}?L4OP@hqGXr
zEZK0*Nf#_H{kg+%9ih*k^ONH7>Tv1E+EUIkrO!lR#EAuW<PV*&s=c(Tb$V5xX&-7g
zk^&f`#_>67o9?LO*l)4yAJU~&A3VLN^KyE6A;*M-h@Yq=omXaQ53rQ!z*mYYLldw;
z9&}f3fp+KeqbUUO*%21#(bVA=&zgr5G}SO(A-&=jvN;Gb2g4LOh0`Gbln0WA9<r)w
zltzvHYR0B)*qj}my)S!he)@no86f>f^oxGEM1j0m++Qd34<Sq0A=!trx4@Y6U)CP_
zC?84$J9D(K3N_cj%RA@Y!~+beGI;hNFz1#bSBrJnLX%R+8rorvO5HB4ouHNqK+T<6
zT6GEb9^+Noe<+6^(NAVW5eg}w=e{u90v<?>k+PJ65d!oFRfuTtCr>0b&V0(nwD8T_
zp!~G`GLmGtQSI@sV4yTJsZ_afK7lrw9mUyav)Y5hwLKk9f?(bp2p`LAD8@?z;5V{c
zi8om@6i?z!*09ro)fn@fA-4ttR2LFxLmFU0YQU4Fb~;Z-WiVFbaNo{=sud_9p$a>r
zQM$JKa$w|r7;zcLy3|z+_MqP!>P`F_63zLJOfa&Y*`vpB=-XdIl=J!LDS|Gwz{K9_
zv(g^*QXS~2w=(8lmG!byr-EWgs5{O<Rr0i6SK2flMDn}_{00_y?Gjy}SvA3d1-Y}k
z<%SNMTnNg9sIDdgaNRg7y$TB{pyi><ZR8gt4_R@vUW~1an1U@XEpS;l6_LFTicn$}
zL^dnXv^%J&bE&CwsCgYxI#5%WJwnsDJ!+T*r0Y?bp($*hT8~$H2R)HPFOn<dPS-_u
zaFF~|BRSpd`p(lfx1W4op6vdJIRiIdrmkTB!7fZCodzLcyrlz>UmRi4IF+Jld(TG2
zFQ1Lj-7(C1_+cov8!~=(7(7IP(Fg6k+3SNIM&-;zju>u7C`X>@`k?6K)_|mD(~l8W
z&s!=s^+0dsdF4hnwEm7{5>aEmdU7}A=JM5(t8#Ps>d6hT&$^iTid^Vclwh);9hC)b
zxjQr%zWVz}X7A(IW1@&~EM9{6B)U=3nmTJxEVZAT2c^aQYkmoCq8}6fwen@8Yf2KN
z!$D;ij|K`Mi5Ei>2a@hN=5`GTM@RmbAy|wi=xxKwRw}ODUa*X!XDc^TVBxlpDW6Pm
z#&;<etW;Q27cwW@_7XEp*^PKc(qEh;-KMSh7U!aSoJ9L1il_uMxP>i?GEI9qOE*ZB
za~$dp=$^)&*4qwW$0XdYPOE@}hOhZ(n5xe6qxmIvuH@9Vk;M*0v7A)0sA3MVxlqD{
zt%T{c+zY{KFE(__tq{IDLtg!&O?A4Zg8ge!3ox6iy3`s^c4dC{t;o(Hi|VYt;{s{r
zuwZ?m;c;Nr8gA~>=U4;{zlw;(ifawOrCn<{nvxoRk((#&t2KPC(Qtm+D5@Kt8cu$v
zd$SCARE+ejl7xEq3^2^fyctVY#Yp(mcAkq9m7#x(&L;tb=)C;YXrQTJS^1dHv@+MS
zy>_G5vT-{UEZdl&wq;A4>alE&Xl(XD(Fyr=qsJcN<=hcUoI;6uv%I{|Dv7HXPR9p2
z&&9qGH$y#yv;iB{t?c9fli<d_h%dMu49c6&B4B}=xI#^3+~2(*D~@N#3UcF_EVszj
zKC9BJ3J*KBy^85rREjvSH8|t=`oaP1l~{u&I=UzqK;H1Q24&%ha?1C2EI>HT5m(bs
zljbPmJVS7P`X}~EKRD{KuO{l9emTyb<b4n`g;Hm*l&Jy+oWg^plUs1GbaJ(&lsH`y
z2A8j!dYs&XgJoy{gXL+9v?<xL!7{{7rpH}0iHxlSA1p)pgXLz#a6j9@lKQ}1s1Q{Q
zA`PgQU{J)}rE*2pF$k0C{g)#8C|YqT%Qa2cpG0dug&(uXl>g~AET=wU-07&ba1~48
zE>iW@xf-AOgxY&wf;YE4H5#_qv&aq$kDHQ%Y8kZ`x#$dA>LYmOpX3afEprngl(Q6f
zpMRYdK#9bA1R0z}q5npk%H%nFipl5BTTbyfEBa>xTLKsCVrr!&^Dg(h=#)JO5N&O)
z2sBlq^PaX4x<rI_(cl%DDR{tJz?AN<&V8O|EC6=B?7UHAtnYG4Co9SsTd^>MU~j;2
z-FvuCm-C0XO2Gj@5cZ1G^lQ%vAP6B*Qx?rthfwvbbQhOQ;{vDZzko8fTCgYG!XlaS
ze_$g9!n8;2j4>(`S%4qdq;x$wbZ>aNnXSHsH$2()(D>Wj=1g*1HxHK0Vo@-sXSGp0
zfM2vFRkhs`yPLGqR!EKWLR2{rPN<6zRqd91g+1BYT&X9_F>r_vrkLgrsVgZ*>Y}M5
z)^3f$Cu8`1BCLmi{c>*aQN!nud6JQ=7*E;5I!E0E6hVTvTqx1Hu?)MQ5u5_R+GK_B
zuqA3ybO_9sUq$Tz<mX7E$|ntO#DO#<l49iNlg8m8NaK^)t~6RVmTo<-Ha}dqM+K0(
z^g8Lvvcki-B^RGcDN|UePJOE^*PBY`wKI%|Q0C_9`9t-?saK5D4`<Dvsvj;}z>h43
zWHu#3ij5H=Ge5>5#F)K<<<XnBBwp$4C$T#=$1?0EY5RuLvDYI-)twAM2Cro%n2VE?
zcx&@6T2&L=<1MkB#31NUbw?8K?7g*^@uBA|soI1DbpZMyT41yQ8*P*A8r@;8!)9>z
zqhv{^$;keQ@FKluO=>e8V>;DcYMWk?R~xpMo7z?*4pO+bpCH)ltu3UYdNW3|R4>L0
zb%;YF7Y!JUbB==yXsBSsJXQ)JFS4f%)rw<K#%rjaLKlRgs@Yx))qS#%6nP&%FjOyL
ze9@mQqd28I4#N57MbiOeBs>c9Kao01Smz{1VVOOb_WiLS4n8ljX>aYqZO9B2@rndP
z`HyDxP5CD?eU!hbDgRc5P(D~wK3!8DBjqy3cPK9*<yS%wPOa;q7BDtnbt#iw(K(b2
z>IY@#_$hl+Q??0e1LJ?e4r2U&iXX`I+jJQWQRBHeX$Jp<+pdBEF)}rJlyvkcnXgAl
zhl}}V71N_rh|;6AA@wviuuu#;*_EM9@tKC9Zi5&_4!3<rB&C}jMPy{BWSo6J0)x#z
zB^(XWz+ZGIdXzfWhaT={`C4-Xus{#*Mc@-MJ8-1P>?`<z%ua>h)IBd(=^nD_<L0>2
zStFI|km^z4Maz-JFl}6)*07cAtJt-|)A>tmNX`5}ID3~Z-3MnUAMN98jOOg6a^dVW
zbTqgE%kTrvTI#^rRuCkr*9SqXkMa?;yC&!aP0)krKOktZCg{KCQj)sa^?)=C)<Qz!
zIyesDaUH6Lt-YR-#ICNF>4z>{P19U>)>Cx&{ZGbLN+551<Q8p=kLRYG@sS(<RN{Cv
zQQr7yEKS0(Gzo2Kn$eQ7A<!NlxfM-~L?EZ|h;;`Q0hR_<397>$`4wy}MOoO^C9;oA
zbx;cnYASK-!D*)&l<^Kui?ycSir_Vj!g|<KXzD325$HNca>TbawF~ZyJ*N1Tm!p*#
zkMTg|l|h(dq4Mqt;{xTS-2M&9n?K)522#6`4{ZJ6XcPg5E7&E$Pf|Sq`v5Vbw{hMT
zq^Yfz9ZPJT=soxnK$KCAW^_OlE5il7w}VBxe1k6^wvzX>cmEIx-D1r%kw-_^h#$rJ
znW^m*r?w7B#Fu*sm_0Z9MbL7rlRH(@a!3(ch6gk)Z(@K0Eu1^<t_dmA_(pLBnN00;
zxc*`Tc!C4E1(Up9`i$-WTId7yu=q0htEoy<cW`}AOYIaqk&;@K^w3%@pP=L#K&_SG
zZ2nE{pqVZCgRl$?m;_bk9nN9;w=&}EpK^wkGMJ4>5u~&~B!mgKY#V@c8B)`6&H)ZA
zT2*4JL)F3~WMwUSNSBCIe@wamQp>L&{Yz$rc0Z$LVg4NpU%kkv4pyC*2nu5S2;OxQ
z?%%Lk<}!%eR3V59zm0L5^eDJXTr>dL3lMuD*?O`umJuFL$xKa&jIy;>dr5Yzl(~Ea
zK&$WpdsHOLGgUI7h;?5C!DuWTcqTf1cOr;m-{rUQwqiX*<dM?}8`Lfw)g9ZIa6FvJ
z>twIUy!Iu7*zw40!k&cUxl!wbzJ=SlQJX3vH-n+Dg)folUM*WOdH-RE+fccQ7W3hX
z&DgGW8sfu(86g&3Ry<`7EM~u4s2#bfrzb1nl!Q9!EdwNB6xrmEAmXG(y!LG%9t6bb
z;d>h7HYEnz>i>4JZT4Wk_n%(OG$_xKb+kxhAQg8+Ly{UXAB0ogw39!zt;Edh57%|G
zjSU9u;FaTpEWn9cQm<l@Zpe2w%2Bn{lOIVhh-ZiOM0WautnJ1@0%Gwyb8S<>Jf*hh
zlr=8jeLP-1X+dHq8Dg6Q`s$8mpo=3cg{A%$))8(Sf)WnFY~f{+!$xMe&=iZIrC}YM
zglgzfD`BQoHiWhCegVKfg<1xK(yMd`2@Il3bgAQJ02C@5W4-u|mIFOJ+-C>NV0K|C
zOmQZ12YzV4IXq*c)`GGeGUa#SDpp`-t7u)0%_@Uo&zSn8&})E#y@GPut4?%5?VHvG
zNI>V^b0%u;Qa4=yN>IVB4ml=!U&&smvr`xa`c*M!-s%}dISkG8b=idS36Z%jk^p$A
z?g%0m1N~k@u=@cNOO3(lJ~{4zqLAZvamXHJ_kcJd$I_t4F^(y47AkMkrqK=qs_K;*
z;d*L>ngV;JPhzwV@BmFOW6%E&S$3GkxRGPOl<P*mh0(}kD%Fd8Pq*9z2a?@6=D2%P
zMo9cCD*ed`#KfIIOk4+IypCoZEfejDTz0JVX0a5pwP-o?SG0H_`&GxogmFaJayX*x
z(5iz7rrOG7E{~mPpn@s*dV%K|?jh3yt=dtHX`{^q3A%BpnIe^h_{2I<9tYN!$gvrY
z`918R+ulvI{gs5e240aXT1ZmF2|gDbf{b1Qx`y3d%-sa#Q(^dfBF7$6hVH{StKm^@
zkxXiV_J0g@=rg!X*c?W>y`(4dciilZW|vkrab=OZc`og{9vi=<uBrC&A7_2|6H+bH
zdS_qM#>BG$0D&Fvg(wiuCWIZ&u3ejyt(8)p6V3I+wuOdoLN~N}bI5^TgxIz%?tL(z
z^hEw<X>nt7jvdvO{h#uV5*Uf${W9W+=3q=)n!{X$1~Cn6mrZd?W6Kjh0*5ZgtFiSd
zq~cS1m#0yuN>UqhB;tv0164?Q<J*LQJROO|5NPR%Jb3grQ9vK7Hh*q>8)VuMXzAsj
z@0hlxf8m>T&?rn%?mO49uN=+QcMkP7T3jvUyK7(3(U!<TLG?If>}aH8U-JUpwtbaA
zHx(ED)KOwzBW&NO$G&#g(ujM)h3HAQVWo=kLg&o6qYrsOZf{M~bxq5UEK<{J^wK;v
zh16kEQIqugXgW|{N?L#=stt9N2#rNI&!ycRu+qW=yOhMGZ#5~1{ErHx&ShrdnDmb^
zfkPh@{}k1kkaU5{r1yV%AR7U01EPz1Ey|`Li;)OYBmwk<_aT|;Ly0q{#N`*{5>+mM
z9GTt-@ExKOAlVUeUIf@HWZGCX=dm?KguIaGa)kUWb`Y^OpLGRi2Y(H9x@vu0DW)SP
z>}!+W+FTmQ<-a?VBXL;^7Lh$P#UrxA8H|nEJ3wQ~(gKpP8Zzj+n(P3IULdVb5i%kz
z(u6LYlq-q#I+8U*2%G$vG}~|Ce8NiizbdEcOVRZ7Ac{mu#Z89?aUUaK3s<w}{~H2L
zKD+sOeYNeO@i%{UrehBopHmAtSUH1OTz!@Au06z1WWtN9QQG!I+z!-xU=z&_e{)#1
z+kw3PX7?uQHabvJ)QE%Lbvn#;oU39xQiEc)YDd*Yuv@kgnSoRsBJ-T@hGu)wSGVG*
zu2}RnCi)sxg9cg^sm}3u`v{DdGa9??J>K3maf`=yNc|*xrMgl-%v%uVL+}|K<(Gx%
zU3Gf({L%X1s0HOx;6qd3Lab9)gjbBH%G89`Lz_a`g^<~RmacO`OJ<W-UVQhdkFW_2
z+Lu(X!s&<gI5<D3i<k*~*`COShl+YKoLaBrVn`f<#Ow*#V=?i)-NAL8#ufA8(m`1p
z*RC!uCm5TVxJ`qxH~;{7y@?ip$*0g^7sbJrAYZ8j`AQic#N1%>u#3l0{?<9O@S2Hi
z`mhusuo1`L_z>AG%RXXH(TndKaN?V$Vv7~mj_*O|z?BXdT880=hCv;~QQS2pu9T|S
zeL14T7<@9_k#-VIUxmPEZHhtKIuoRo(G9EdjCR8Mz$viOL)G6VNsu<?57G|Yt9SUZ
zI|4s5Dm!sN4&$^{;j6ENVd5KVukr?HqxQzS3Q?|{0PWx5@sMP&f~{k_`AT{Nw98Af
zdrFWt7LXuq)DxuDd+4jW8!^K?ptJAUU4CEBkH0p<4ZiynWA<@|TV*DD8!B485}^e7
zzA+>Ab-2$+T_`2&po92e2`j^Zxjtls6gwPY0zqtD1fSi&Pz#N_PUUADpdeOjGtMhv
z&d+Bja0@9*UMC8b@A?Y*Z4Yh&>`de1y5+SmA<TNLiQk%`!xYC3__kk46@pDicEfEy
zaFV1l*-_=GOk%S!rJQ(dOig@S$7AJ-^x|KkeEFIea|n6rZy@CUPkQv`!<6iSHT)E*
zVv(ncbqFTweY3s8oZy6vW9n5rlT{&$f!77-Lz2KS5Td;%-iqa{oLF2hG2i=5%vZ;G
z-RSPfsnR7`$xf(5##*T<ZI$*!X1lrnqHt01V*Ca;+t$}Wu#alBi0TD2Y)Y$MDZBmn
zWm1lbR;hY?Unm`bml8PK##J;T;HwpkqTYf~HxSAc%Z=08h<hTx#H0)+o)+y4yQ~##
z0b&<|!7u{>>)z}_OmHCrAfmb>Ka_a^R_wK%1gG^3Rn2C^v~_j!{{=78Hj}W$xT*-Z
zI}PW|vDG;a>Et6z9B?;Fj8l>G!nC?kG!a^b8(QaK!n%}?wdxyq<aoljI>q${Z6Jy)
zN{K&U#wNM9Jjv)B-O74etSZIZQrIivPFhTzZ_==)1LdWQ*&r)Xgovt{K(G`n*7c`-
zUH%_~ojrc`kbrD{vp#ssO5YDlG94)*I&1O<EBzpDLpq2%o_tbr?RYM}PfzmWdlM<S
z_+Ep>?k~Py=i<|(PUy1ItMo^N<LX*sn;cxkY6=nQ@xLH87;T(9O%K)mKU6?q+oHS~
zbqb+3=La&u*|5&6-jN@>dmM9$?YT_ka*~%{GohD!j&s0qDHYYl;kFj*%e_Cj{NvUk
zIQVoVkZLWaD&r|O^Pa|wPdQ-tjfy*VdAySwx<MmC43&o?l2>HaRp^}yj}Lwj9okd4
zAkZHCK5DTt(oJ|z74+HMQx#QjpaU2q-qjPid9p;1tI$11ViOlW&afM`d^Z)q?SViv
z3y44kj;61U_vgkaYi%dGhlpCl0Lpmev4mc7YiFtK+77-0N7MM59hD$WJy}*vfChfI
z9QYmhmWfp0M?S8muIUT@PS)tu|1(|xP59~Hx7O60zTh|H!2empcM^VQ!jJ9?{;ThK
z>pzEYnMgf;Aophwjwzx&a^8XRJ5Ix6^%}e0gNJE&3qSfE>uZXlF!DPv2YxRNA16Ev
zDERLSeryhWSi@Hm9_AkW_XQu!f&buL;XgolPEOR5i2W26fua8&gpk#H^8bQ{SNM@7
zOLa|O@XzPK|3$+;O?Xfa{`-P|AP0VhhVLXiS|0rO1^=rY_!~9+ZG;aA|Bynj{9mWx
zP5()2_{D_hwi<O!U+{}GywRUaHGB)<>CmV-eZgOp1AnH5Zy-EoxZuAp_%m|gzo6mk
z2+zrddNS8(@EB0j{>SCOAEx0g!eiYL{PzVvBL{vz4X-X39O&S;SJa%o;LCI1d)^WK
z4YB^P@ZT4FBnQ4s*Iz;S?S+5z!d~0|_pH&;|66ta%kk3z&lUXl1%F=-{BJb;O2Us6
z{`-Rec@F#!H2h73-$D5A3qF$rzd*w;Cj2PjpAJ{S0o1hrMLF<iYWN1iM}+^r;E&Vr
zrvDtK;gf{tULZB6FZl5}@H=YwO2YHAjcRmX@WtD27vUd&dgZ^k{Kpdhn&R+2{{sus
z;&`~<Zzy#f5q+>MwL9I8DBPMPTa~^EHxI=EsWS0LvZdM8awSW@c7gf)d)pI74fUA8
z|N856Q%YBH<4dLr4hMd%eY9_sP|H7nr;d<ILN-<&Dl+Cbw|G(wsomV1M&}$64Bq1k
z|EEFCVowxzUgojkMc<@+<`ENcFWFh*M5sD4S*jlKATJ>O8JGT%{m9<B>LeM)zR;u8
zBtt?{jyhj`u0Gz(5&7e@y+@tTBypL@r*A?dAhm!xZmfIM88hdFY#<PbuS~ckEN>?F
znuMq!;TS^#rtq>e@hGwyrxYw9A>|>VIfsO=Y7)NTknrFxE(sb-Kj$nS^SjlLz6KwA
zsoUUnT%$r$Nt70?I)*GKdZe*;CNt8=+v5ojXtMIgS78LxBUY)k%yk>N>8qx|pDr=j
z*WOPjlug>cUv85gE=}7bvaCPLZO)12IVy36ke20sS-Ux}K&#pJ!Xc2bz*Km=T_GpG
ztnM{#eE?;4^PS*pzMyF`YEVbLSA$0BD(`*6u5!4iN>QDj$Y1uvL;zLew(9=PKDWC0
z9?p*!BDg09u{bZk;bTY{>_#b7+!DYbO9k_jq!{ts@uaxO)J2H1=Ua*Dl>xXydg7Dp
ziM%@=fG%cjd!pHsu|Ekpt()gIS=B4)d!g60oC!h7?5E>khVxUCoUD_(sWO}x-Jr90
z(Xvy?)j*Zy#^T;6%#|VLH;9vY<~MfSTaA1tM;0jwi$=*qOg+U(B*?(sJg@<n>UD0I
z^6ZYC_Zd-Qf{jM)iR?E8^aNLq9~2--{R&>&^0U-qj8u9g=B<COzy9TODo?wm;Td23
zzrkd1i|hYxFZDk~o9^X*^W&EsJ-TkGum1hErv4Lqsei7&{^uT#f4bM5-}2S}n*#>U
zKX#O>9eq{r#`e@rkG77V_{F353jUR8n9Lum>p*Ysy<-@)D|8=M>zmE$74ASrYuB;o
z)gfYfy^JtSKx#cJtLIY#2nd~g*}FR~zMY}WPL@J4`lq?s5iigb^Q}3&#PNI^O5ria
z^qUNX+$eP|US=VYVcGODeamm!?3P814Ly-B?=SHLxq`Y@?KVm-k(!-7ihWKOR449%
z#3i~Cb_qP|N?<W~ZB>CvxXbu}J;ao3<EX0ZpLiXmI<*=BdI}1rR`xv~DqWN*(y!#Z
zIZ4R&uP-F5y;@c<P}odgq!GrifvPS|07G^f_FQInae|AMn)VN1POsM!-!rm!8Hh2r
z`#Z!2OVSg0b2pJn%nq#?a}?9LulaHxemFP(?!0_&ycBhqE9rY8%koNU1uZPU232b0
zmz41~kdkHgB;{vOlDMk?D|?XN8*@(Gyw@i%gs!Gh1E~Wj0Se3-0A8ZJevFF?)W8<}
zg1Tmk0j?jA^+Y!93sEPvb#GMJsHmA>GHNEP36MZROw_SIMn#$pwls5Xe}CREUrDH=
zxjI9N^{}YdpB;M;JGr)H#g`u;(Xa=Hkm#VAIR+N8AHz^#dr+rln=1R#*TWy5KWWdV
zmw9_$VST-Q66o1o3$b3^vg><2xn(J)xx0#(`V|283C-4DOYQCx68tCIXo_ekKn|5Z
zIdk@-2UV_ML)S6`N?%4Av4ImQJ&~7o5n}o^T0RVahRqMuxgV8KkMrCGl5KrGomCak
z*VE?K9zXiF?{2Az9yigeqSm;9tLPr%wn|04R?br64A-`zn$=gx0X>g@OdDjM`{H@m
zOxl1BSLbbq1rxx{PSA(3Wn7=*wSdTncL+~-@D8HTeKku?eB4syK7tM;8M^1>5R~39
z?i;t3V@UH+^pAZ&QBZvx=~v~@%^JTdSZW;&G?HzhOf5pgvyUB6d+1G9lIwau9p{mb
zu#*Zqy;J|R)a@Tv`p78OKe|pkb@RA0u$JWZkJtA`?PGKwu2nB#A|U~PcHNtI?jId?
zw-tLMLh_Cbb*jox*O$Gy`00bj?0fP%VnZk?*lG-rpw%894<W5P<YuYkMo9bh!@v}_
zhs|pBo4OHeX@YCvAGKq^U_)Y$f@rDjDZ#?LG`IHbU4Qa2$C^%-LV?f5KdSGE%!+|s
zuQyb)(-wI{6SY2VV{ZulfoHkOQh%g-;^_*-?85<1&)#Fm^KUr%PC>&?pSc&9l_PVt
z>SfHo`Z1}=GtHLzx{rur{qg$K=YM0zS$EM3%j=I%U>*v)@bdP35#j1nj%BJ-lMNNN
z!XG9)QaHH|;YTMlc3ji`tUG9m!n1eU8b4FhGFQ{mhmIGe=jAta)AU78?3vM3SGC>S
z3q2j<MK)_I`qSr(|7fY7nfh%jxnB`08Jly^gTI;nE01-W$@=uHyRXqf-}j|1_0_ej
zTNk>o_3WH$4t;A8)8J2KtHi)1inwsO`h9~BaWVbwn0@H_tJ<FN>-PfG1+B`2`_d}g
zn!4-HmU^i>w{I1*?=$CAw*K+t54`rhjP>?Ug7in%U@XJ_q~SV*HAXck)Qm7mSlwWr
zf-HjXD#@T%WG98@LHyhEU)BhQahC>XvT`*=6c6$_M5shj90Gsq>stdKQ@6g<)1zME
zpRu4sUCTcwy@Eg6y^23G`KRVJ{P`3AT*g1|;SZ>a<!J@zsZ%?WAM|7s=$0_nrJ_&L
zzoBE-KK-@ve_VDq(-J+At9FNuxn@zyAFaM)u$UgHFKCNqWjBAE#WASZJ|$2-_P2`0
z9e05X1Ba9u7UDm|JCNC+^p85MA<sd818etDy+dU^ymnS-A<B5{*+Ya@Q7<7wTsvIR
zxCzZA{OPp-Fpo`kA_a0OXVUfc;o=4w;z2FuZlUZW%kf#Eegq+t{03PIYf1-e_XjDw
z3=VF9dKt~fCr4V#OS*Yyt$NUi(S(JY%8>CBLBPV~3c}lbQvBfGJpaCt+XtMsAt$LP
zn@yz$bn>(!#sU4AF0L`+GhM<Kiq-N-`vE|;VfO6*D!WbbsBjeJu*ZwVc~e2X*(QPT
zAtCB|BHu<u+)D=h+askxA3NdeAjku<X_Wn6qapr<t6PAkKU*eT<Is;M^Jy%LeYF;S
zn9^ZIXz5klyDt(2X(Fj8$wo_a4$Pc{yXqq?E&0;Y(G>3Fp#Gqgas6?<YHB<ap%{rC
zeR>XAp`M6U0dY&lS|CR6|D`BH-^RQEe_{`I9;)?K=)oV)Rg2iDg-X#y)G@<QNNP>D
zY$ihmjSTTwtut<}$GX0Jqw9N5BLXa3Wr9b~^hVqdAd*bvmnfjuY_1#Z2Kk|`X8}jy
zN<4g^J`6gyP$KQY{RCphUQ)TO6}eVN+HY;JghlXgd5O;=8TwyATWb3M`jkumRhF0j
zeKh@Vpn#_TnL#=9|AhKbP)J_-a|T4pw~jr(R=V9YtN}^VSE8=+R8XMOSW-BO)fAM9
zLQev?0v1ta$<<;<5Burqr?0+Y*$YgDtd7BCQD4$IC_5;72U9hcrc!KuzQCzP-?%Qd
z;L2oROdV@#Y2Fk_VXLmx*u0rlKCIu;$<3t9HFXKpe#j|@Hr;aF4<@f;85r*e5iiJI
zFT1C=NMk+1!()z@Xt4?-KQeQ^ey6Z{VM{zo2v4)}bPg+~FOn%gEAX#-FqzBVI-t&H
z&o5&bG+x>bJt|i{-TiT#JqB->;NM@k1S#}r<IaA?Zz7!Q$KuM!txxtp=He@`zc4{;
zlY`?~jgK@zYWtrutCLl{FFoOQka<UXJIMaJgM1wYbO%}4^RBy!w@&Sbx-e*B=O-6t
zKMkN}1TL;C7k>Jw8#(P?soSpI^F0^X*;3CQc6`!<mXt}d8WhSt1vV>vM!*%H+a799
zt_%YT<YK|RkZcI%$Xhp3ru_EPu-|az5aB7`{c*}$>f7)Sb-#veqk+@`h8c8PK8X`R
zC5--cmlwkSz-Co9-f-y{XN$FSKTdz;M|*7#z0k=gO7s=I@16>>BQdfZQZEDzX((_O
z<4T|h9j1_zY4e|hw8bF3kw`o7bz>s^mW`C0B-Im$#gToi%$8rua@R^Z-Abspdt|Tm
z+D&HH&;Iq4o)_du-HkuyXpT!Rsj<|1@T!-Jh!vd>-7d(fQy=rSIR7>s_OH}pI!zq~
z?ce`A!Jzl<e}0`E2eK%<|9L9bKbJ!Keau`n1+F}#|L^6uC)1IVYflcM^IA;39eu?q
zJlLmC_sqdpz@8{J>*U}QC|D4wrxhU75JkR?_bc1q3(Axy>!4Q0!v<0P9?&7K9OZz>
z9C@*gxj%XJrzr1=BQO61J#Dw~c$+$gX5`H`Rs7W(H7^0SrRd-Ffu>1N^c&`aqI+2b
zM;NJ+wCzpW*cS-Q?JU^|DExI6zB;e)zl`0G!rYBTCmg$l#>;O>YAkxf3hah)rzbC9
zRgi*)k6NP1S|U9~jz)0{!88Lpi4=+9$&ImG{8a7CZ?0Mc6k=Mj%J$x<GJQ))fA!Mt
zAAS8Ac_u(e5)zRMwg#of(L@eORr4pDBDK*-YDfNzPL0bR1!2`-ORYNllXrW-Os4!$
zzRl*_M7$;Vb`;;n;cXwjCHPi>w<^Bv!?%I$OR)Ly=rc|MYD3Y!4aXxRk4o}7C{>|3
zA8NkKmMy~r>`5Sv0j}_{=Cwza(#)l)?d5lHY5-_#cF|wl50(qNP!|uo@Kiy{g~5A|
z8XTyg&c&?3T{zCbZ)@>vRB08`qEoHXCfuG3xYFzz*$z^4L@uNcC0ZW_YYiyZQVCx%
zlET^kib1?$OE$%4N2)SRG5#NWX96E*RrUW#+d#U6DND30>Igx?A`VbrQ(JI~0R|`<
zpkQQ;QXxQvNRtwwD@maxjevqyM5*Eeh*&ph`&UR=N<~Bjm4c$h1)pJ1ilBr=^8fzM
zz0Wd}r7iL*@B7kEC(rZT<=k`6J?GqW&)vd1O)U&E4dtq`I!5vyyhGNSNzHKmKjUrf
z1z_}w<(yplKfN~NWbMfp%oQ@kYW}Fa(0;g(ogTqd=2F9e^AwOx1e~dWw<Q9a6|jv0
zV!ahLSlNrlPr=SFNyl-n-N5t~|I&*VUo}X)wZ}qt-!s~(9_EwEo35w2yC%Kh-O5(r
z-G6|0gm@ytJh3wvp;y{y;tuIctQTZg>_kNHlN+96BVSiVs&;IuyKCWdyNyldN3QAL
z!0fXC1O>n7sj2V<cs;1tnu-D{^jD10y&C<6w`xf=1);gdhdDpUCKM%Y6~l9$+ZYhc
zNnXr<mg7ZB-K1w4NYLO0fM5AZY~Nn|-lToIMqPJL&5udo?A!Iv#rCZOa8PhnD&{zt
zLS;-{rJSszzf7QeYWnO^J&8wfBfbk)fs?h85_CY;`GvSiofF^+Uk5^T2e6I}aM<Ss
zndGXUzgrB=S9z0Q6Ql)i>n0_!U+1tNO9F@ePNmp$IoUzM!}OM+yhPY5C)oe|Uc>&q
z4*T~D`=^-qbJ$-?x1}5CwO&B~<S)tMFB#*6;GE~-D5&48IO?@ulwb$dxk<g?Zr(ub
zC|3J0t4W7GI#j1-HDhyyojsvLR2?B21=8Fz^mzN}Wk1TTEZCApW#B&YGHiOP{@(BK
zYU7Pvkm9qdwjKQ2*tRkLZB)ChLxHDq3@lvjgbwCou1e*GdE4I<ysPiIe!Hn`dQi*j
zJ*lP1_*p2$d!~A&Sf3wRA#e*wLHO-1+^_3#`jXho6^j&EDyrY&#<VRax%yV5C1SMR
z;_eV=2@xy)q9{Y)W*P{x?5`o${=u(gXQ0wpvt-WaL<3!bRE4zD)>GYa6;;j-Tx=G`
z@@xf%s4<Z-edL$8)kF+b4tOa0!M9!0-96s+SO~f0B<QdC@i<1!=I$~O*DDv1_5|b#
zzR4Zh82*%H5-6g-rkmU$B7?S2c;KU3tCHu`oG^L&*x>4a&?wVtr!T3Zn_1|t$i4gv
zZyTHX4!^Hw*i12^VuXJB&x`)0Qe`^xjnB=eK+--ya^0FWcx3^N8Jx@NZe(-Y@cV6j
zC~lp3Op7VOh_-$FTTR=p{_Ra|6a3p&ZQJ;_bb8SfB-bR0bvliFc!Rt0Sq$zF{_Wg%
zOL-0HTPoi&Z7X?_Cpi~0_9Exb_Sc;LvO?QNudRIf$gNTpT3gZm;#TUj>Vut-2w10n
zNtMc}2w|ScSqM@_IVmI7tlO|XC;fFAnqM)E;il{nvUnU@29p^QOZ0M)4PG_MNn9pL
zk!mPZm@Q3>mT4@^<jvQ)s%>}wHmYrB|28%z<u9me;XslHk88jK8n}_oz>lc?9VOXG
zusLs@^Q@eCHmRch<f*H)0~Zy4&RwIzTidF~95^x+oMEFU8<gX3H=y_&Bao*E<UJ67
zT6g860@+jZ>&b$wl#t|hjb7Y`I^_kV3|4yr=7nEA)xJ#_u`R%gbCo>r^sQ-px4(Tv
z+o>qZ(<vgfDp8=;ZzwfyS*IMcp>njrmAMA9{!({ejBL;CRR}3!l~H6phZXlfeHXd2
zC%Y?mID9KRbt$wj&05OIcZ=^>{+EZ~e@)%n`n`4iHK)B`0<ueg&64NYg1RpF;LFe1
z5y!!usC%+xbgb;~#xrW7WIPlW%JnvKvi#_Y=lTm5!2@B-J4~MV^K)EaUYu#68)m12
zV<_;RlxBqpJ}$n=S}us{$(*LuU-P3r{0lUDMwxJ)*;biMu`cMtv_+us`KiR;BEv|1
zI_Re#h(L}geseQwGPuqQ>6y=Ss%v8^mr9*~EOt#+HmD4o3|M3EVT{_8R@QL7<S^m9
zEjathEFBb{9bxup*)g2zgD2YTR_A6dNH3*#h=6UXK%|kx=#1gL&^H6CU6LQuBC?Zp
z9F;S$vb@OB%tCLo-<_R&<9W`yl%;vfyWG3m&2f+l?y332n$Xf*Q7EyKC#Kpb2Ot0Y
zAeN?bqK4i>P5>;oNA*++3NFIyfmw2&K!aq*hS}Q%dl?AFCx!1SD_FJ~#cK`~#pnOs
zaY>V9NpS`x1aboaR>^p)GN(7xGWu4m#vg$A(|D_YdWhhB@E;D2S6PnR^2LLd(@j5|
zKS2!F6g(ClO5$dtTZ?b)ubK3m$x}Z@A%)Zjv#`5KOvhqF-<F}B(Sx(#zZ9BiZ;-DN
z*0@1NtqYOZf_U3$Uj2vnGWdMKoV7X%yqn9-7@rGnHrR_Q+tgEAb?{@~0kV=?Gufg4
zth_P<_rK7QXnzaiM3t1;s2*iNNxi6yu%uHruOwG;qQ0&^+rN)e4q#X?NGT^IO0nMF
z5P7xrx#1v6x<OO11M9O9eHGT{1>Xm6f^x1tW$TwTT(`qgqW0~soV1JU8Z1Mo&*0z6
z3=#Pyqx|&AlFIS=?&f=N*HU?YX=4~1p0Yow{F-25e)s;Zk=O(Ew|%R%c&mz|_{(^0
zR4wBY8-?g3$#KZ`awNDAZmX!uuaZjTh#yc$<#$`7GrC7xRf-oBu`Hu9-j`=p0EcT;
z;9<4U@{Bq+lYdpIJO^!!UMbaFd{5C<x(+NQPHaWCjkdGXIh(6;CF65+&v27Rt_im2
zZ-V}V&@Zl=e08Rg<?>T?M8VC#=Ja?iX;>6O>J=WgR0HB)PO#k?YV+yaHQn@35MPm2
zHBW0F{;Hzw%CxGvTkqdn_^rNgM|ax62r6Pi`j&NqJ0btjhJ61z*GmsoPDbmZ1Xnw1
z4NhlY*4fkp@H*f@+kCB~T*@(Y$2n1*B-6n#W6<|%Z`YBH5&?ByT6FQ-=V6@#?%4Yd
zagWk!AEHZZqkDD6n`88BQHz%*9&~=n`PVS=`-J=4vG`T&jSqM7(b>I7#nRgK1gxc2
z43-t&**iABEI+BMb^{-?tI2gaFIFXi(1-q!TCWVfujD}~dbmFQpxa~b(WQGN`}A3W
zp-X<t{|o!{-#nh^(?b|cz%Q+xK+@p)$21CYgZS0E0$(vJcn1CEgy^zlVvf3m*`!kF
z|8HGw{ePpd>8ZZqHatx$v0hdRPGO7`3UzouKq+B?o_xD!k^xNXq!*14>Ld_eDp2p^
zdFM69tJ<7bt=h|mlr*%6+bGz4*ant>4{e3npg=~pqP}V+M1m_}7!r2KHc7R;b?{~)
zzQ8y$wfbW|t3U)zzjdTqu0WbYPxeCN60KF^NkG7@sj;Y4gH5eMUrExpU~nu(+xne6
zoxLMP4n>7wYt3%!C_G&0!WLMZNaPd?py{c*93Q1npYBx`KmbX|l_BxrsfNUdKa#$!
zq4vX_!Fx%zOh92T`Ezs(p`a{KSh+Bs62f1bV(c}bs3>2#Izo=O2@3!&tJjrO#hH3>
zuT1TDkZV)>g|CT<L_uJ@(y$v80gIv?TSMV%H$$-%N)}-p&)g^fQAP+gbPJ>Ort3j&
zNiAlO>}x-;7U_#O(wr-^l&%XY8$)-gPP9PZ5@MRudl^xlpt_hii{c#PrM-NFc%?rj
zgLlZ%b_=tHS{xU>G~e{j-mD7uAAOVNaWtrF!}P8A$wqSjjm3xb5|>SPTqb@fqo~k>
zn>f-SERR}r2IyCwP@<1`j#G3mg#*-`tDdUNABocLLrG$T9by@Jiz1oo<*W!Zg3?{L
zs370K63AxtFwMSuaUbd1*rt4XoB58L?c>n)H(N5}w?y*d&lKFMMNZ9aQ!R<5pVa<#
zidZI`d(*e|s!;(nS~Riu#TD-QS3!4oq%;!*<0W8+(Bk;<<#Y&}a9$>?(cl76Tx)1j
z7!qLBY8^r>PjI^71k(*_CbilLL$=xiBW6-l?j5>g<yA(7wWQ`GklQ=NGtv6YQ2XXs
zJE-Ci>Mi-_*Q>Ew!le2DNB*eB44_*A6vmvxUE<HL(pUcZ7oa_CDmGAEoJ{F0QG8hr
zo$cldvUYW%-A>m{5i?@=GX!Ld;QJiI!5<UD*V#T>2H)oh;Y+QyY`X5Qe(0pwsa<MS
zyz%u01sny2urH;!k>8a(q^X=~ChNUUAJ(_>k(t&*zc$s3868OIr<-u>-p7gw1Wx9V
zgTaUSy_XAOI}Sf@iAXAo$0LWW?{w~$CiH#E-GbG`n>sW>NX;|nOmiIDtWe2$lTcc&
z4?7t#zqiz_;5w+X+nrCRN^hi#VJfb{Kq{_5aXJY&Cy2}RF_NLm8lA`7z?8E>*DI8&
zXL*-lCz8+)I5PG?4egw3luH7wwl4TGz6MZ{qTyP*olDF<6=2pm@x`N(I?&mg`5q}N
za@Rqubt(%(levnewY_{ac+#p@T+Vlha&W0W7T%>63<vf9L1u4Yfpw;QjJfbBVMog@
z=aHIM?U{l4O|hBxDGG*;Q#yM`yAg|MHG7bjBvFoRiRt;hSHwe<Kkt+rqRayZLzD|{
z4u>d{ewi4e*!=!SL`9K0sQS5#ZkWgqPIQ*h$25WC+rru<F)|TwMka3oIAzQh5<S(|
zew&fWTXAx^k;(RSUox0`NsDQHo?xxyy|ezEHoDA5oR}xnI597TF4u?SL@<)+xm@w{
zM2~4vo@olxwz6sFp%h<;Y9WAN*J^!u5d{t%Xk0uKQG{4mtr!{jJfo7#2qFV~pT6br
z3Rw<`WD(Im_Q)W1FFEL=6ZIC_jY8Jix=|I#pB4^Gv<fW}x<(0|p$aCdjMp4iFT$JM
z)n-N?;pP<pB(oGw9Vi_wbFP{Mv23<l1i$?asDenH5aF4*mM6EUopjSEwc`(5JN}gi
zQvBraR4>)oUk~4;>Re9_n$gi>ZR(IRnmFRx$=R|zv+1tiks%~{cW#uOBVLbYs87w^
z4(RpIuLoE2z6@*$Qq7p7g);S@UnQf%tQ6NEu?3o4T#-!CeMbZ@YEj^f3E{}N7#@yG
zF$f$PB48?hC@G$HS^?A%?RBC?lbOxg_MPnm9Hu%anLE6;DX62DFcW1ld0q#~>OZI_
zhbnro{#i@PTJt^X=4?sXc&MlCRB@LI_5Hvb4#=pNZswdNG=g|maSQBO71ZKKCW+c-
z24bUV4QB|N7M}j?WzK|*@TTGcuxzvMtxbAeZ{0{<U|a9!byg&RO)kqI3Owp=#R6XP
zL1d-Ad^anG^4+Y0Ty@mVPLn*-`>zY$%Yrm;bKO8$H!Hxtn{6nvq14MI$?G(6kF-M_
z^`?$CS2}eI4$2tJ6e68>wZ7&X$A)NdYwz;@l0A_kY)7axYNdV_fEnuN3?f<?sn)i0
znz|fJzB8$dI)*wDT4zEtYu9t6URir->NS@zOPKnFSlKY7LRl1IEo)|#DJUz(I*oeY
zY1Dfa<D<D6X})dQ?66ysCKzt9GHjR2DpO(Jq70oPAGrJ9o~YMo1-_k;?M_q8b*xSe
z*k)Hzi-0wah7;w}F)7Y<TJ^;pU0J8)MhSV=QmvB>M|(@xwx-gbx&wL)4)m2u0rgG)
zxd#X7&FZ}uCsCjyI~ATgGseGtCkv*<o?kzi7Me3g?F170xP=I6OVjuJ5WWxLS#{lZ
zwt2Fa9~VMcq(t<t&Z-?%rQoAXnA+svX07=jg4O<8f(O@E3!gIe(PPHCR>6*^Do$nf
zs!|fhq-2_mH#wEH&T1Xn2UWo*o-tXMb>B3M-2}*1NPCj?vJGmCR<*1NdBhPmB$0mc
zN=~mrrlV*KYdI_|(qtWuxo}x6P+HVR;PdF1qz$~QE|k{7(^W&d#Z|&xt*a(%3@%}E
znj~&%W|>1+NP3kut<cAZs|ZrwFjs<;bAppI!O0;wQ{$RKmWG$-$fQ=8$})#T4`VcK
zY*CT#QBxSI&RHOAZEW!Xxsn)L^*!N&eOVP%Jge9u*_?{<!O4TZr<W)DOndiI*a#Xk
zQ*9%PzqQb{xmQYPWtz7_nzw1lvi`=oevD%-2cLhJ@_iK&5%c@vc;P$dAq;@AI7&Xm
zj#=A@2=Woz)h&esP|cPC3fl58qHwN@L!AzT?_7F~8$0@)&$7dNGdqZDcD7@zZroB4
zNac*`i6eL;-9*|Y$FrVW$}<c|KD8Vp*tj1a%;mestqZ>RFj`Jn&K7579cN_?zbu@!
zUm|y7lv|u*Tb@};YeSbouFg^kvL(8E#qjxQ-8xn_JRvMNMdPca{e3bRV}JjKGO)i7
z`Ld0p=JB9=KkFC&Hg#7vKQ4m<H{nxtGz0_qy;PN4aOST-o~FVtkXM~@`H}3uyB8g8
zUqR#Fi0>S74MUR6th_-cVSy`43Odsr=ui240aKh!nuKk(Nm!&83|ms|?~toJ)7e)w
zN5)o}5g?|kE8GmFga5kI)K4wBYE$hynTNeu*f%-#^vB0pxz|NXys)(?*s1+J1{s!p
zn?uN^Z^C&ZV*;K3>-cXUUW|qIDZbwT5HmagW8iEAAR7Y67Dv2RTZ5BikKU8pt?Q^h
z)TSE_-Z@kY#`2z68M5#xvsW4XNawnJ1SdsxIZ0u(;Yl>6t}JVIbE)6`3M@{L)<+#Q
zCh4eno7~(zH9!Ai=%~2-t`bKD0M1ZfrkTm$)LwYaPp_<ILL?R0FSk5R44PlbTtOP=
z3Yn>^R0Lvn4n<JX8A7F}I>RG4m(_MF1*fn;wg+`mkKmjyGom_a2&y{GpaSZN;XLgw
zI5bhGvqmTDlyP<X=QUxSeh340GOa%Hz5{w4fVfWGx4Sw?_eXWoNAUZ<4qYb|L7lFq
z2<r41(;(H~=Mj8?g@vw8jP9*Y>xIAZoR-i!rj@C$I?bd`t)SHE+ev_YJAJk)S*N$V
zI_(+NDY&DgP5_AObn9)dPRl4Hs*^r~ZHB3nil9zwzhHH`T?&|XQl0MkQ&^|<LW6eN
z05I21ZBd=t6h@uesDPV$wsv}JqE2^govhQYu1?2MpxXtqLus8ll6CsSk6fLWQ%F=N
zeQ>De(CwrmsMFuBwmKEBwK^@OYQeM2o4R%yMH;FU0Bfo(Y}VT$wy;@mhqi6&V-K^*
z@1r^Phu-UGTQ77p-BzO*zmJqG{;AT^pbttcdI<<7K46+}4lO(<)%Kn!{N%M-QiW+I
zkL5H{i|^&YmQ1H_c>ujIC#cqn^fOS03Hal+Mn$VB7LX9UISSE#STF3tp+A~6!b$5|
z+Lg?fUyz3=Rg7fQX|Cy=!BoA1<Mel=FVQGlqX15Etv>skLbI#ln&WLZ)M6gC8!9R3
zdKX|o<bc-1lW_}Ffif~vH@cF{<lex$*xRZsu~3y&bvY1K^@u>9c#OKAEmTMmDwY49
zqE6>PqJnCWEUG@P)vK?>O&n+#ZJ9DzIN?h$AOw&ez6HKBV%P%NX-*anUlz(j6?!Su
zSxL<Pdx-EIonpN3u9dXGotNJ*eQaun<Hn}u^V^X&e}rdh)TmJvBS!Lf@P9r&>g(Qk
zdHqu$wnq@$s`M?nQ7D(uvbd_cQ^ip{$Co%tF&(9@;NJ<cL83FBR!DSFk`m!m``&R!
zp3!TsLfxH!dc8-V%oZ13@%>}3zLW7<YMEc?i~(NfpD**WZ0Zc;<hjzIg?$^c2aZ?2
z<z?%Hill748~F6nbEAIdrvDeqmIGjuF&ju1TzISc8G2>k$uP|ptfx<x+$n)8BDQV>
zoE|3Qdd(~BQGGA{O>hNksay}UgKCPFSN`B8GomzRqYnH@E$kRq_$O+AQMbVN(0Mvn
zYZaf*-l!!pPF1@6)099?Z9jR`eZL#q4?<~rk!ee+sNl3w^G8GQ9(0VZ^Y(~baf|Cw
z7f_BCs{1`LpMp3At||ayho9R*clM7*P(+nk`RPR$p)W(s4&(;k)VvQ10b>9z5#d#8
zJvEy<nw^Gs1t>n)R-?cWiE$o@#l)=Mi$99dM{pWON8wR*e<9#>*Aq$*0T)|1r?6&J
z8;O(o(MaQ2XXe;q4|V;XE#BWhBB64d1+1s$^v{PX_o`JTY%$%N9~(#)%=m#L*5!Oe
zYY6ob{6AZOH8^uLlK|!zNfDIPW{>Ktcm!?C3AvfN=Y7{B+GxU6jm@MNwe01sL@-Dx
z!MU4fp_f0@x=Crmmdf|oeo8qaiOMPpYCgb2K5bD}g_vX8`y_iDb8)S8eq3-TbCggj
z2gl@6ZDV=paCr^4EhN229Wm!E+_@EVOc$gVy&zy=<7}$ccLsR0b$F8lmZ`ed!M9q^
zKa;K2sX}{dR(vjOwcjDIVMhs`3|MAF+;#K!T&pc3Q`Bnu2rB;|CLFxgR0OSd6h%<d
zZT6`C_9^WAxb0EjYDK(!UW|_LWh_@2AqVRt`10>L%3<e0T2cdhzYBB)317!9r`LZc
zHVlT=Q=K07a&9R=w1@#=$pt$wjU38~#3vVwL;q<(<!NlQR)C2MK8x^jf?ffT<SRBC
z9ORrEZZlHb1Yp%$|K(s|#G#Vvi*Mqu_AE_tWjx0KjgTq-+S-Xh`(wIesZSv(-g4#b
zyPi7HaZnkoZ>!ApL`pd?_lYGH`EECv7M#gIjFg-uA&MO8uw|9pmaX&{Kzcd>19&Yx
zKuGl9Ek6UdWfrjsQa`lDuo|4yUuJwb7^#=I@K;0X;piJy<ri|#Z2@J|t`45EPyNu4
z-b~64<`2^RY_qH&R(g+>s#!ogrrK+TQ$A@&sE=TGYUR(;Td5D(&v)=0Zb_%zzob(s
znCU?~wVuADf<)sik?)V6^M+AQkoXhYE$xR%j~dU3x$vvbqzJK=P?4Jtdq!5&9;|E-
zQ-N$YHCJ7>?NkI>w(u48^BykOb62#1yDNpS5q8$wmp&bL<QF`j>=KSqIoNlf3A=>*
zz7ux|A)J9$OgnapZ803LG#yN~g;lp1$-*{<lig=z(N)0*Fc7%Xo+ZOwa(jfJy#dF$
zgguoVAffTLEYg?tPK`C%TlbG7#-}=re?pa<=VPZqFcux=3(haDjNvROfpeOJ(;2~e
zaK*ry3(mZ=LS#8TVv=i`Imi3@%Z@7B`WdDcMRNJ>(X`@36e%`@Zd>Cm)6kvgMo9>>
zTDMSkA3iR)l#Y;^e;~>$4eHA}&(;jXY`F@OFqPw(s`@6x2NE^<o>Q|`XZ@N^Rywq>
zRMqo*0N%y<Y{_;_CY0-G0_RPu=Os>v`QywTm@aAS#K>anJoa5f){G+YZqSLZLzpy0
zm^1|&)ZGgcc3i2jeCJ)w|A#v3!SoI4266Vwy-?=a;6Y|rG`q&MakwV4^md@&{mu)P
zk&e#>edrOIA_FlyN`{vMdh)W7riylIHyfP1$wKd^TcJ69p`DvkC<RPl>*3edSJKk!
zD)N&mzdL5DRQrJKZr!5>-|gn-Zv^8bF^qGDf&q4;;O0!KjXAr@cZE3!u5znfszSEr
zyqC&700Y@ZLAD_es4AmiOuy4TYPR{f#W|zPBp%qB!E<ZGOnqH-bZmo<{##Og$s>=#
z{o&=I`Z^IYPT1fa%h2R>{yVRCQk9EF)4AYMdVfi^TW_k7N=6l(YHQ7~yFUh4p#RDq
z)oHK@4y7>>M8y3-duUHbRwc9q&!O=y_p1<Du%VqJ&B5R4^b=`LyHR>uSvoiG<iavS
z4)HmVzV%}9eDHz$s9`5(T7f1SMt@F&rGgPcxsE-$ma2|aogL#-b2$l4xwe+K74&ne
z4Nm0;g3A~j7d^}uf8r>a5j_4d{3hw??sj#3+j>FZXLO(rmCaGvVUHIZP%Crlgsc*Y
z+TVUE`8Ikxxt1xsfCdXL!+H^wy^Ou>`;N+)p(MMUUJIX+5en}g@Jl34hl9roWTj#t
zOMP(l*QmI?&BU5^8<F28UDIosnMM;rvUP*Ax!$}mS>3j!zvTuo+PdI67T0w4^|zht
zg0J<#OD*`7wk8+6*ax>0yryp}Oj4@Wf*1U2FM}Nd)a=qV`*cSs`-b<C?(ANy6~EfE
zB|mc1z1E`@We%)jyPJKf)!0*&n<TgR0y}YGYdtF3hp5Z7?A|Y&D=Wk5@}vZbx;%{H
zOVs5dAKYufQC)uMgKr=>s!IoTdE_Nm7nbyiwpaRe3za=tmsW9VM_898tIJ=wsathH
zwE06_>UUoN)#=ZNsKRevrV2M%E5)~~xY382YwF5M#r62!0)!fZjksBGLT>GZeHOYQ
zM;a~?p~zf+FQsdep@B67xw%KBZw_2Fe)<i`hO=sHkze|@u2JgMNzY<{kX7807%G+z
zn!j#jZ1)9?DPAjYmJOJ?{er>+?h7ti3EYKuiA#s?sRoGB>mnc&<vMp!{H-u7T19#z
z8{C1~L{3YNJ}8lYGxZQHCH}RXUuB7@VM+Q(U)=HIq4dSf7y6U>;^}X1LSK}?PvTQK
z2=d?))z@Kt^*v=+qiLQQQF7iuyo^S6Wn*g2wt9@5I|jxpTOa`2l^r^A@};p^UU)Lu
zKYk8|p$EH$1kSvlj1Eimj~qIZ3;L+UfaC3ylP>V10^L)y{Zc)upId^%uv)dbrxy*^
zU-*pRgK5)??c0gp8%dP@HPXqtm*OYGkbgevLL{?x`c2cz?QdDdiANkZ^_>-4;o;DR
z%$}NGD&3M%_qwB3n_eQ34y5X@S(-?+B1}{hg8!0%*CLK3JFwcu%Gj)9VqUduNC|6!
zj0~*03M#M!LyUqmm`4-z-93b1=1Y_(C^UqiUbAcN=FM#Ga~8+V{bG=8?vK0X{uT*b
zb5FajytxkwM#Jp`np-((?pXreQ}aiAR9Er{-g<X92zrJzVB6B)RzqD|Iydy8AjP0I
z>al$dHWE?`(9%;#JH@%a?-M+NH2%z&V0@m#_@zrijIaJm3B~}J9DL~JK`>TMFkVAW
zFy7x`e3~$x$-)sgSUT9yZQoX$(hO_Pz_jfiwXnEX7;vl$0JU5glv5D)+mam?QW4oM
z|NiBsWz$<?l@F~<9gSh}{jVZ?dvAd67T<@kI8$X~qj}(SP(+@1z9jX2qrNScPmQ;g
zrwZfEd1De`*(fX%rQ<D`4u{To5J=6@DUf;_Ime$d+QzWkhmA-tdfdvc{0CjMDf^A-
zHC6p<y4T>U_|)CRO<kq!72LBdJm_&Z@<m5ir^-FMPMQTaA<VX??10sQ8|Se_wmj}O
z*VMn`f&Fphw@BPmy`Ne<r@0$&$OuCXV!G@#?1_tM_^#e~(09$0xPYX=*2>sZJyAej
zQs2_E)G!MEY9G~mDB}0L-v?Sb>7v5Nt3aHx>Qz>{>+k#}u7O7?xEaIQPP=RkuH)5B
zFbbO-i6sCTEwNC}sVj@@a9{1HK$#hGe-lX~ja$z@_pqQD5F&?(7tib-W`tGW-z90%
zJW5aXjTgK33}iZG;z;1`3L-YfVMF3x2u`r0kir9D6L1ZwxrZV(+f%R7!tay;Mj;XH
z_j0uV2!)a1V3pHTvzw#+&j1-VdHZ=0H8?}Lr?S`6c`<kx;qOTV$OKYETs9xUVdZ73
z$D=}j>a?=g()^VDIal_vls!$1oGAzM!K=%vpe3h(`H}-O-+^fa9oT1Fq6+CnUjq$o
z#}Z>h)hWL)J;6CBXgJa94<+;x&cFYBSz(i0Vf(qlwsVCY>k7M;VINQ)A+WUO*OWui
z92Y1TFS457r<U%i`M87fVW31@p6=R)q%>F_Y*^pJSim^1E!dM+&v~H^fUC54L_)?Z
z223a);>e!rj{$$`N)8oDV25}HH5dz|R|lU@!H_@m?G!QO`#}M69SF7|L+<FAQ*eKZ
zZ?}{oKM&P|#ejh!+l(OrECOFtLK+pmKZbD$Lmui#^T0wQ&3B+Pq`AW}#X;1$c$l#T
z)QD*;Km}@10_aEw=n@C0#Q~b+X#97pqMM8mVIlA|Jp~{m`JW~Y0oa5F%ZdnYGj6bq
z?hBGlQ~HQZM;n<c-$a37FZeejnIr$cM*diCnJf=lX=}(njU!K>&P~`|aiu6PI3Gfm
zRBF1b)OQycbv`5TJvCjfQW;gM^T0)Yl{n<L;jL3|>8@jh7l<~8HEhv~v(X>?65b5D
znWIT6q?_Fij^@N6lrmh}G%|AMTz9LF?ar|xBivOKo}b{xGaP68P}7u~KlSBrYY@+>
zE|fonL?N2g!ILW}y}#z$Kd|FRYXEF>>cE{20=dHHi7uQ^8-Ugw&pWiD<A3qW3Qg9Z
zYh7krE4iCg8<}M-AzCXfAlwV(Mq{A0^0?N~mvlTKv>1Ye78FjP)l07anh6fA?Gk8d
ziCL~#S-1e49MulTwgQ316h|#LX!zfG;MQQ8YMVheTM`TI|M-V+@AB)+{FCnoD5sQ2
zCk;X*rRuM_^!rAnYHFtywz<Nu)RwUZyWnRD4K^zg@d+aGom1BIx19`19RM@tRZ9ey
zz$XBklSqEBl4}t=_^nr3GG&xWj@AzCN1GGkn1^Ia(qHqZuVMnnxcv2gkIM+OX|;8+
zDy^H&DUoVjn2NPO>8`D*j`MV%-D||U9LQRVqo;b!StE*-!JasJq|6k!wrkWz#nCTG
z&!yUq8qU;MthF!HrA}E?r!PDCId87X&$07Oe%g4@S8R~cMKM|R4iI7kd7@&ri!3c-
zmJx%Cf+dc6(?5&ND4$on8x+WgnF30sK2e5?oY@n2dd>^xBY|q#sG}W2@A{>mR;D)g
zS3&oj=q<}nm%W`K314`ZOvL{~(*m!0{Psr1e=h|F9nWMJq6Gf<IT+W*Gb?XL)41_W
zh8Scrhj7Fla1T<lpQJ=P=~9_+oRZmgkT7I9Id+i@W<C;ySze?nM=@?Zqqk^0Q_mVx
zAIo^g7JBtmzT@6O#xwVlzg)=(M+CD8h`}##6PGBNzgC!aSN%y-GUvEX`Z69UnG2Vb
zxTpGYzWQrME=PlcM59o20~)<b`79^I?CLkmaPa}s1&ZKY`D@A9Q@tyZ{WU+dkEKSq
z{+gRz)Xo<5Wj^9T%{~muR9=h9OLx7!f=`r~mRW62h~CHZt}zP@;|4ox&`)M^b_BQZ
z8V`0_0U`~Tjp{DtDbS|(rmhm0*nU#WtYTeaDmdv=rtzWy(5ZkGjCvwfZnoMy>eW9z
zUp03Fpgql~(rVD2>XSK~uhib$^UK(q6ND(eRdN9I;@E^mB@BYyvD_krDJ(Od!T{P#
zVVGcRFs!hseot{U*8PACdBhEXjB+*r`k-%@>p|KY>YPM?l)WM%Yfk(U+yI&-W!Jc}
z|2W&qKE##%4#z0RP_`^xVO<Jl>9u8G-t549(Sdozb!utQp$cOYRfq>bk_6ai@;wRj
zK^Ev&$W&U`+sX^u#TAxyg<ata+s+mCr7zk5XgL)rh4Khkl+^sK4$715R`VkrlzkkO
zCZI%8Q8oZN;2O`3bAmcv;{lK<4RIrsmsIj<10W|)v@>m73w+0rF?Q&c;A^-CNFNP=
z?*D?rHe$$kfGy;j0=6MTE}Q4x1^2$%a)w++eS=E?14GV94uH-aog|G4zp|Xbb&fPY
zYctYhRZdUM6^<zmq|R;tr23ZD;>dD9`#3-sJ3xQN<N;8Xqw#aTiqT+43N|6E6)gPZ
z9y&Q+l9IWfBg6rK3<+_W;3B0Wgmg|)GS>x{(UvH$1;_$|q=y^oEMfc@qfcqUp3BNu
z<N$~MJ+q7sbq@VA9s2JU`ke<}UBu|Nq0TbB4L{WR^A&EWb2>?-p@tjkU~kdlm|xA|
zn4;GL!fB;0v+7H&cwF08+6~nxX_GHFaUHq(Ywo(<4RwI0#lkr#I*lr)N`^WQKk3jK
zZm1KDz@nkf10F4VLg@8;mkxDo1g6$aprus(HSct2>39|!d4*_|40TSCqt-^Km4&}(
zc~<9vyMU=1>NEidGF6T>+?~a&PGEzA!6x8YN+cV2WvF}t8>Q;6x%L~;P{#&bh50It
z;f2>#m)#NTs&tn$XCm?<B5k;n?y@@z<7_R8=^nR+`;?b)xkXoP7p1|9dW>NBb`ejy
zy~RBAPs0`wEBMC}V_aJi6hqs|pt*6<MkQAdqI~if2!?iiTORQOaLjrqyuaqnpSSu|
z7EYk{{WY1-X;Jf5U~mNAg3~HE1~7C$l*#1LME7W6+cEMGkt5Pi^PN~;(;ACqAI3*0
zmTmNArDEBKLkdnjiIzPn)z+p*W824}!{tJPe-R!2y7;;NpKpL}Iw&_m@$qX!S4W9H
zMI|XAD58YrNl-!w`)j`S*{xDV))8tg+-!fgqdP0P6%3Y<M*k9JeYKaelJJ#AgHmRd
zA+zXWEj%5-iEJm6jcI_+4H}Sc6V|A|rl&O7e}&0xL^_(*uw$>8Wj7vPAzT=d>Y2*;
z5$We}HfiOeTL*CZlCE*m$FP;Uo<YW>iY2j`i(iw^ncCC|plYS-qfnl|J;xN?`#5X^
zJ>ATM?t9v2Nem^Mfh&p9zOkqn8<V<@&pA8Xm~^E8^DnZ8X=&>VmDy}Fxu=y%W{P!?
zj7js9K(M4Om<@wTQBjh<M{p2qPvsaa_r#bqLxjep56QQ=@UASMZ;VO*z2mJnN_%}%
zV2JgM`FxL57Xnr<6Qf>l@j>9ahofa0;m!H(=){6uvHM76L#=wrHt||qmLGPR$PndQ
zsm%jRZBnVM1Dmde+^qEqZZa!t=tW&az;6mZwoqEj^@!?(viev6+WJ5hX{nEyjJ&m~
zRO}gB&r}uM*y&Y|_5|6whz50s#VS(eAc53=!)DIb+WIfs6p&b{Ve7ZF$RwqacxQ4&
zN=Z_dqEO<2S_Igxdtzs}Z|TsvJG%95-PJFytkjJFQ?&qudm4)Gvk0wGt39CCma55t
znwjc+oITTPYn=o6_t>JWV-nnP%98N_z-J4V(Ajzw5wc2r#2?*f;uh#t4aOKQsV>2`
z=Dp*p=lXX~W$dJ_G3tn@np@vY7}hkKsx!kP#L|d*^3^J}Eq4z(FUH0eC~P;kh$>@?
zs50G^^I3DpGOA3v>j%VX8a~5~MxP*5hMO*D`gs_5k^;L~<N@vKf*ZQTOzVPuU@Es7
zZ;vpct>cpsLiG8UVW_g`PAj)+t<c&q**JqoGCN(E`=0LXk)Z$vtLb_vs`^Q00`u4q
z!GuK==5hO_0`D2Mh9s%Nesca-@fJ+Om!&d>CC#f+Ohd?%2~2&!agFYp?p)Bhm4D3#
zO<Ple5-yI59v<GOVt5aQulb;U%i)O!G9r@LDj(d!=zu9Dt*k#1xX40AUroV}U<wE~
zG*1~n8$0VzIG~o_AAY2U1f~ZOrDn$--+*gPmr8N6CfqBNdc|gf7g)b^IrQ1A#T^NG
z@(9#x`BOeDEEhbgT7m#`@*aVF@PtQzvSHT<fviJd-4-CQ>GF4yp<h=1Y>(66<zLUT
z&dnu2qI}5c^-1^WAyvw2k-mHM&<bl%_(LbZZ%}@ZYvOZ?8JWGz$4WE9*LYK*gK5oJ
zo(9Ed82bF{_z2fJuww-p4Kh4-CHK$8wH^k)!Rj-7d${#*C?uI5tUS5k!ty>erk3z2
zPk*ZngCVq4d3wN4Tu_pHAiRb-BtZFJeo;w6kAzDf?oX_&)Fdaulgpo0`3%#LB5p3P
z3$6*wt4=w+C2mu+xn?S=X!@>fy6ZAib5{HD67c$9%sinGE+mJI6nF=U%K9q0weQBU
zIa{HRI&{gWv85?~XS}8(ngH4y+=0{z7ko+rce2RLXOqmNMitQ%{EVBS3&%=5ZQ(A-
zWDAwP52Wwbr43M;JZfJvD0A8pU=-~>np#x_x1p;-8gw}7cIU>k>kY$acmHke5%$8;
z*KcDvNSMiP-UVz`aPkGNnQs6c_3?K8Br&<FZhsjCABR^hslX9$&B*$Mds5Iw%(evv
z)e!ZI`Tf$4!T2o9R!Tqcemgcvg5AS-Yvf$8ObeO(f`*J5Iu|UmAP6CyYaz1;xhFRs
zwo^Ahd|eXqY(}285&|R>+|x!$_VyCs9DPUQ-_-#S#p7Mf3#yv4{nrJ@kpZWPR;y!s
zPh6eC@^Q)LF-dL!+IF$l4sKym0|`6<F^F@Fume1Y$2O!|{N!*VEw{C<KdYWMG%R@5
ziUKmGYqfr(S+Zg@s}Hu)S&H2cIOA*;cgV_cZ3Y)vf*GWy&IS*)dLyI`GH#YNP@+#o
zPiv3WxH}vHNA2HRWGJU*>$ubgEg9H96MP*+;}q|(u<fuBT$o+?ji_+K9x-g40m_IK
zx)pHK)QWeOM>hN`xG8r-Jx%6k=hSV95%1OW1kouR2n^VKHq2dX%1_>^&J80w`$n{h
zAlvJE_g+Y#;f<@?klj|;JwS+T@NL@LG1jOR6$U4}yV#C~RDe4vuVni`%sBq7g#S%f
z!Y6`#&nF!JXM_83XTq%qhlRE4zVC-X*CnjfJT;7BjhzktVcs{E9DyN9ZnQgto%oDG
zvcYQL;>OIR<_nDT`zrjlFds>C4)WFQ60dc^CCm&F%Iy&h^EH?S6mrT}ZEzO78F9v?
z8Y;ED$z8>1b*P;iE_dEzHD<L(_-O{Qj%sN)ma(*R;760d&1CcelpH)D)L+roi^DW$
zgCx>L`jxhyq*pTf7#?#`3RcCzw_YOab>FE7D%rM^(2{Z4VR?Di?Ex|qynL=}%1n@j
z$WErD%6cid_yN&66BHPQLh3KliMj+DXLAjFq%yAa*DzzoEB!08T&q(J+j6WX-1w{^
zHN1l*M%CUzeCt-{)Ii1}ACQI8ne;NmnZopW`NA9B8v2b)vWNpgt#TBr`}OW_mfhAG
zy=LpP!!`8BgLb&dBcf0?c=Q}cp=|IX?CA(FqIiyD!?V#BVbF;#Xxl5F>-Xc}d{yw~
z*?i?Rq_Gy<A9-<aPkx5CdvY2A`?&QMqHiB?4*_vswMC?hiIRAW_wRX4(LzTsQK$b1
zrH)`<Fn5*FuJv0Il)LxVB;_u&95qLs6;f`O^AeOZP%lYCz%v2;BNVS+%?R6<vh;$m
zlqvac&*p1CPIA)aY%{uAIv4E5RA(fw9YNbC!wnTnpl0z%hw_e>cwihc5CZ$82bPbn
z<H!fU!r_+ywnqeP3c&n5?jpg{L>LL$IFMWcO)P8CmOoeAyFVSZh<e2=%Jjcn%+ADw
z#)ny%9YK`^X^+m5szed*LYj&@CXl%rOTi3-!nYw(q;@)jg+#0tgSaC8AzzA7_vR}i
zG+e-gtszbKb^#X>Ao{<A;o+K;$qm)#qdwwH7LA}vT6b6TYu;jk%0XT^M`2y?-N@dK
zRc1%<%=w|p935pv7F&kwkP^K2pLiXD->I>q#X*oU=J&Nv#+u^M?+?Q7C!Z1W`#vbm
zNK+VD$4ZSt?>;)bGJd}Xs<~2Pe*e{3BroIl0}z!2S9GB`Y!_uA$?tpOymR~+^ZODH
zEXnUrU{)o7y(a=z#_#<^IC!4lTi~~t-w(my_8O>+-}fe_jNd0%&;WjaA0Frue!r2f
z+tsX$->)Dd!S7p<(KXa<Fl(p?joiOS#2rmNzjsUKq5oJkk&E#Bex8r`WOvB#G=C|-
z-?}c?4hz6#OY(a~h-lICyEx~61izc*?+5BV?%<=KWu_z1aaS3OPRxf9FMrn4EZsFh
z{;)7S-$MqNv?&VtFNJ7?g=)ke^!6LarOZ`_@uL}<B6nTw=f9H_puBWTPt7hQa2xE3
zXD0>7Be;I4E3Y{!Z>>UndCgIIlCLPqbzu^B8hT3<aj8XM6xz_w7tu~&cP?WmqBGX;
zp{FWTgNOWhIz+or3In1(H4m-tlT0CrW_g!W6Iq#9uZ>mYnHW^UabPs1a4}J2o7mr`
zOHU@g(zXxjCc53*oWpw?ljj`5()s)M<xhJsfA)j<{77xPw7UiyZGZMrpRY9f;gG;n
zq5avN8#44T*{L>x&KYki@57QZ2JP)(7veFT4j$ZntR(_E>Rn3)oE-c33lIPt_U3|V
zRSEndCAQgO4La&Ekf+#)N5+bqw#e~961wGLu6R&b{c!Td9inA8Rj9XLX7^@~fr1SY
zgoY48!)xbN`S<lCasT1wyUGOW&1Z@`*9D{K=iz{uS-y$gX4)j(rPX~A6FrZySSnC|
zQpk`3HS;5}K;>^9M4*1s917IcErSTuCBD2^pxP7V4Ixm+gh~AMRk1|XTTGcm?M5IH
z#n~8;AQq`{3Lajh3YfwnPbEbv8+;dwJ1J6GCsJ7_QrS?Xe!AL3Dm#owy?E88MJgL?
zB~>wqNL8F`BK28G0jCQ{q%;Q^YtDDbnjauj%w108T#qdjDi{S$iG(T}+@zjMLd9~C
z|3yNT5MLXw=>W9GsMl`}K2GDC@Yq%E4;WSC!ae@-FnnJb1<k<?*wK<EGtHZWtM%zc
zDVv{E(XJciuZXgLgMk9FdbhMEnebZ8sjcfbmkP&<m_pYId0E@f-WVRPDUL>IqwJYB
z=&$+yd0KL2c_wT0oAcpU#^Jk3v*zU79@c%-_?j&3iS?5o&w;2G8$g~+uv@dl%N8Jv
z2mM^|$}^jC-wq4!p;OD?;dp`hhjX*V`xhcl+wp2{Ooz(UWk{y>EkG%-><ERrkLgY-
z(UA~pn~-i8&%BK_cGOnmtgR9Y*{0P_(JHycYV>Y*ScqCE%f7F3t>wn_*Yuskszrft
zZO)pxeD}sx2I{Lqgiq9#7GfR2(24proqEcv9p4OI|AkNK3|{RG*Z`t7A<DTHJ)RtH
z#{jj+lPDz0AASH)SW-sNpmcG20Lj!O$e1bG0T|w8<p|PW^9nRz#oIEY&eGauk^~#h
zkT{fWJd95U)GaTK?v|HEGX!)f{L%Rye?yS%De<j9;Z~^HQ*$uZ2oi&I=Qxsxv|Ius
zljInYe!AOeBFEdaH=^BIz{W~ATHDwT$6El5BndWre+Uv_pNv1SHyBaNdH%gvOR_}2
zaAMqXroWNwINb`$n%|!gcAOviNZfJKBwEGCe7n{W=6IAGT!Y5QRnDDUhS*_4A(kI`
zhfe6oas6S{K_E7w_<cd(PO-&|uFIfQ3<JfMxa80Nv8=VKgMxX?&2g)>Ey=K}Co1OI
zePIwgH%GPqC6#kJuBUR_uP1B&MQVf{{>Kl8wLc9d5e{T&A-PRk_jY&sb!gc}hm!_)
z&)Rcu-CUEOye56w*J&?k)D+RE$?$0s5D;ma`~I>DX1+IA`*{->GBxE-V|5mdS#{9j
zt{wVB`Wq;~Hh<dbK_^)OCs9BL1)MbZ9m4M<X*SfwNh5y_VyFGs^dBDf5sSOV8H}~S
zm>D5C(_qZ>NY0%5o-!ma{O<5b&Rh$6sp1bL0lh$VOzip$g{er1(>k8Cb?d11D#~xM
zt{rS!B$|>tb$qPvcb81)CZL`x-L_UV_w?WfjeBK|>=8>E3rCeNp{lwpr0{b}7fo33
zyUaD#$aVe-yL@3M%VQGh7mxY7$=rS@QIPA1{0F<6jeY*n6tmBR*CpBKPF1g`=4&4c
z*{AlDn0=^dGx1JhnvKxSDxf((*%dJNgZ2ptOs-$pO6}ECv-NkN`463L`!i#s{`}ef
zjE$z;oA3S^Et~6Rzx2o#yC2r5iFcI9sI3<_Y<o~~8I8A`0s;6GkC9^AE_>Y!vR%!x
zoWf&}M`ut$KfrRq<@{K(=2)m2%yGUWsxtyrk2$KAEW-3<H}F?Qnyq3w(Q}00iXGOI
z0Ct$ONp=tf&ko9?j(mD>waxKwCOh0A%?Wmcvcq2llQqafyK=Tv#RW8Fs4AZLa<Z-e
zVCC1WIxcMM`jbl9dIs^Xt!G$U&k#{&ghZKph<%o~_0HcOx~(PuGfG?dE3~k1eN`>Y
zN<ywB8mMVMck^H}j*U^)k)*q>f<4L<#0f)XM%hPdTDHgapzYN4qaTH-bmpv`$@t0R
zV}iFYPZIoZ<Ukzq(?f#ab3#n;GBh6g)?jsT$}~d5xtz~_P~EC2)fDv!H-}f4u1Mc9
zdND^-4Xo#RgBB1HsrIGvhCNv62MBTZxO*2jOgd15JZU}W#*nU4iH^AgR$^?fs(XUQ
zEZj_1liBcoS}(h^=*NxB>8^tX-DD4+5K<}uo^@gw7N{08l&1$D+X56$1BD2*OdXr+
zENh*2-?SO6<9n*@7EiA_s4V~Azd2a`koe<9l@tGNr5}p;z?ODIMmJkG&ZEC79v;&R
za#HDtUhii9W^<cNd(KMeC2PGNc((r}s}}<5WN}G@R;lG6Yex5*wrF9(bi7{Pf%PZs
zaVoKZwCFHBQk&I7ep^5(C8Hebbh~(JoUnkWxY0_blofpU*PMEq4HYK#*ZlOOW-teq
zEHrtC?1<H=$?!ER81(aQavQiC0g&jOe90WFEJS8)PA9Jx)GgY_boPx&FS?blmDT)_
zGoo!k)k6Q=bmF2~Euk)`p#A!5p8v=e)T-DHsfA|6EKVff6b*`pQ8(4rxJ@s7mvCR<
zaZLkn5|HrL#%T@1?mQi9XyILTe7^dTSi<S>#_Jmtc!L6iQlJ5S!b)CFSv1dF<g1xJ
zH}=(dzlnTh;}Gy?Z}jR+_5|n6hGUPcv_6|sQ10#oBphzNBb=#83=TSC(w*M{gtx%!
z(zlvIv#lGM;K$RfKi58v%;YugI<aR85CAx(xO;!iekX6jjZ-|&_JN=<+mASXRdp)p
zZ~!~|s@ur_%t@QdzrRW}({>7PIeW|5wgpduVO&RPY`%ZZbu?)Elm}W<g|0v7p9?O=
zmO;(S^;wYm1@X{_bnSIm35=&o9Y`{I>vvy3TA%H^yqawo+;tq4=yn@X@IJ)1M-6!&
zyWPRw_ReIfdk$Laf;r<Su?vXhY=<Tjzx<T}D8h_&c{u=k*y|&__?lLQFSZ^A0A;@<
zZg@XrIo&q*dr<$~%4Iv?I6Lhah+_w^yyt?*bGLvP#9<|mkm`G?N>^G?DdCY1=h18?
z$2xMT&+FAQk|CCnn9m@VHQ5)I1~JG>!WzxfobJ?&o4VEc0zf2Fw%)$s1Fx_`khuC;
z=f$~ZovwH9l-tkV{gu*$ahbDb4`p;@B|~o`X{*Tq4pIQEP1#1{dY{9JsQ0spmLQBM
zUX<_gsL*=#(TcxZ!fxT<XiWg+WQ>Uw)y~cRHNX6@HSym4HSgz*iZB&r1Yz^A5iIuG
z;s7P2cq&k2I?gn63(t?BQtyUYZ{Jkb+QLn^VmFaWZKOt)U9va659|_g!|T;98HRta
z`(Vhw=bt|u|DJj6ruesINdAQh&7VFv|2B$Ej4K<{ou_*KohRbb(#;Xmg#6oV{G0Av
zX#5f8oYgKUjlS#1*+<yX5K8OIM$YQZ*!Uf!?r_~mhndh~wR$egQBKZSc3qU`W*wdF
z&*zV$3g@!aHNq}t>HN?8@Z+(wU)w3;(FWrHv35g}wOjgYUOYZz?H1n1)9Pt8ENctd
zHqY8^f(mQr9cv?%LuRclT;W-Jm{dvDZandI&)TNK2j_1o)8I~ed#9g2*B0@&bOhWQ
z@Cfzul532=6*Q=RcHRRr^^rm}+NfuwqG>ko5-ghwv1GJslNhU2yxWxSe8qElUV8$G
z>`?CIVrV{0pLdu(pEWDaHR}w$H+c^CLgV?AP?%pFo-<yTqTV@T>%3=cR>L~Bwi5EP
zsE~>(fsLbz3nN@$GCy{Or-9upb{;rpKaLTo@-+I&*qFU}ny=9T53bUkm_hbqHkCge
z_b1meGN|r27Jm0MBkkoT&fG_B<V`Acg%tiuG^IE2kTEk|x;)*fL)Q61sJceE;$07;
zFtDHQXE0`z$e}F`$H5qOG0w5uUvn-9xsmZ>$7}&=#p5Zhh0+?lKsFRklxBcctnG<u
z@|~SKx1;bk?Lq3<RF%bJ;!|}o>po<1D29H$b}^f4N?AIsN|R|(#o14}IqdYlWmH9S
zZZ#f%c%wF27{BkCOg{IZkL9;<JmaRM)FHzS!F=Q$Ud`l{C^(MZjpotL*p6fYW!Tz&
z!m>gaKD7*ZI`w3^o}GQKv>&cES*cP^SFb5q<r*W2NpR$81cb2_Q(bIhw1~MeIECf5
zZf);QxDIiq2x@B1j@^~NM)TkU()X+}@OZX@H#-eJ%ZvEC?7D(^-d$XW-~PRqCSAw-
zlOES`^+BQQcxglII!5xiu3&zI<ySu7uxxU5XbLXTU?r@>fjJl39Myr973V5Jc>Jr@
zPK5p2)Kw~)bIv|}Aa3oRnwRWR{R>WD365oI+0{IQ6Oio7NgAr%?LKE}S3#v}*Ty66
z0BI4WJ|c=KAc#_SME)Zbr4|uUc3+Yt$^pOzrM@X4QO<vV2~jvAKPF1gQLfr8jwmg`
zdAO4!qSU?5#kNL7X$=;!Ol2sdsAz~Xm!iSo342t(OGG&cXO<(%SZW5*MS<YIfKO%Z
zp!70A6<EN8%2KkS2$f!R39%8f7aru0b@#f7O*?}1T1pf)@t4&#dPl0N>m_IbQ^C65
z)ut)#_)<*P`!7k7^+1)?Q}gA?Az3pA$7C(CUE7I@<aC9h<^1$vRo{!i&|JCj`)s~x
z)toG8k`E)SWwQIf;d2oEgU@B*QyuUIOJp89JF;9_2$AyOk+LmT7c$SMsk~(hvD+l%
ze|GvK&x`bj<YF4)Kh5og`M_=Q`t}zWCEIkVy!1UaKb;h|=`^%JxGcZ{Fj2XlB7%<|
z;rJ`kABSlmM0;B7KPS7`=IFk#=HLVt`$|-lz{zT?KU6fLatuX-!LQ*e`i8G^vO%yt
zoZ&=;l|s@Vmy<oz9}j-o#6m#>#UgP<(^$KrDZS`<D8ftvN{Ae`1o`=Ay6=G5rDPfj
zbChfJl+&ql-el1%=}e*Jl}v9}l5(GMl>1D5NV)A0<pkxhd1A`d9qwooDVge%6O_C2
zy)HI+Z+S*5`-h;MiiUC%C|dIPUZdO{Jc38iU5;{0-j-8t*%iZ3&M!FLMN+KRiWVMo
zr4paPQ^FB^#C0M_PWDV6L~{!voI}v2KS=-#%XIu-{I;=lmyUao0g%PFFp;L2m}+~o
zJ<^|AO_W|o%sZoSvq6j*2GbHv2}rGH%b^YhH{avug+BYJ?5d@H8s~+?8i^3OD6%i#
z{fuAhRh%XjC7_zxq9W9oVuQXX9kdA+GXyjjnSfTfh2+2!Vj++2d--sb-hBb3X|2<q
zWC>|f4+ZKSP3kMsU8_i<kP&Ss7g8h}iVS9(d=N6L7Ih@dcMpNMi%cS}N)H8h9dW^}
zPdm8v!@+ft3An{$hXT4@Ko9<#1DYQWsEgbzpn-t)JnVor4F}XkCV-+uUnX}dy{LwK
ze2JfRhM#+@Y@Ze>x6FH-h$g$%xtg8|wcnwKD1jf0T<Iml_pg}`vkivb%JhenLk^V_
ze2+<fC#zaTQpQ0~^$f>Bof~qjD%&<Mncx!O&c2=8xk?c>pZG6_&0-+0-i1Gk(MPb3
zQCXDi3XDY|EwkF$19}Tun>=R4?LbTHM{ZF{qbp@@5t$jK?0O{m7v9yu=l_aP%Krw-
z;?>o`kGk?&yVGbxpY4L};EsDzqs1G&g@<`y4{*=go4PA^LccK{Z`{1mOE3LZ*oV%U
zo9sjVKHT?B4Exag5wk=e%IKv&=*D<=Xe0(7%1IYkNlv=J+4iXZ5CsLx5jOTH?}cnM
zhWhwRmm*CZ_c735pxetaRQ%UB*p`vqX3>t*`u2R!Oy<10E603PCf(inC5KGNch1e~
zl&-n??xV87`wvBkw1w#q%(}T4c_WJWD){*M2DX^wJJ+Q1lh>U;CckPUP6qy^^PP`x
zWSw8|=p-^S5z#}hN^aabWOAo}W~Kpon!dY_W5|8f_+Y;SZF*=7MONWoKX@ymj+&4^
z;HSaKhXJPNW0{lx6$^aO^LhOF6M47LS?(m5rX_vx_h>xnu4Zusv@usPe*f6HR#&Wv
zg6k5&3TzRSy7TQw6PsqNS7^N%C7h7E<hQ3>b!+=))U^ZJW{uF2tOIY9vu7Rz(2!9D
z7q5{~(W;a!N|_B#_lOauy)J&mBt;eugz)(uCM1K(10YxD=AL^|#um|Myx!h81xA_R
z5TkCHwr0K4rt+8An`>2$DV$SVm1>)+z>Jnuk78m>&JNX6E4nOs#!tWyOjXmjjH`9w
zbw0eVxSR@1*rMhhw0##o)rXY{Z|{3*CA`gweipVXgbvh}Qn%OWwF)EN4OE(Waprb2
zU4{lK&D3!QwVL4uDu2($=JwH_Osa~TNROn~?iZ?x>u86BssO;Gpjo5o)SHwv9%m>g
zs^Uq3?x{Hu0E{!1@)fi*%~|-fA5M)Ima{b|Q19ljY~e*%wt(eKu$<|z+(R%3lIP)@
z9Z4*|MS2RE2XwdF@t^ybU<rUp!D@!-1F%$1uxxNx{=gp9w+YLiO$W=V9?J<4En6cj
zTRoPoprrGM+Z>jk7YvVOWeJvMWcSppe^-d*hf1*oz@%V@!LU?Lu>2A^sb<<?nH83M
z3d=8m9R$n@p|Isg%&IJO60X66m_jHu>O*WHb%i}4+UL{X=H1K-OE%KJNZcegCP(B|
z#Zr0x`!0{$`Pm`4=%_lMlR%c%ibC4tYcLUQvg`c36LrSZZ7`?o9Q^OrJo)FJq1Z63
zwl7De=7gePg+`se7pPt^xh$ztRYP)RCynCzYj&At+UCtkOkA3vLT7X&fXn34w><&A
zYyfaq1*K73f6eVj4g~J2`Bkc!1ist@w<o}_=erbh%V@P#Tz}0+hXS4p4m03t44Ne`
zGB)Y0UT=1)S8n!MD%_D?a|sbSEw$SmHS5qMf-5|N_5{I|0}wQ_k>ADj*Q`0hYX8}|
z)boce)g~JA=a-b)>r1sKrLG&MRK@kz92u1w*UwLBM>Med)z2;|=>cDoJt=AZ;3Yvr
z7uR3&I9p&A_0Es$SI^B&`zINR#PUF|<W61@p<W$gj)SGG8EBAP;VjMiC0e3BZV78G
zmt|H7-8QE-8+>i-No|5*YNNRRn(eJNZB`ps>UqPKYRekRXt>drYEMe-8>Upn_1Anc
zFB-a1O?8Bo6XDe1GeP4ww9NTXM8n2e`^x^!I$2(_^ezp3q7W>MrFU(_^#Yl*wjP3n
z5&@{6pJk_|vE(1=C>)8L6pu?p#$ZWN1{M(-46M<r(SbGFrm658r*m1^>nJ6Q%FCwa
z?4u=A4(Be1t}uu~gsyOED%@&Edo6YSGefsCum>5ssRQ34Lm;wX-gx=nM1djfJLx`k
z<dWr7`&;xXMV4ycPOs8s&L<t3Cl=XeR-Z+hJ=GXlDvinj3zs=r-*>08p=3{;cy7|3
zvXMeh&6h~v?5S_<Sz=G&WIZT2>)nIcQ_6{@GDDzyYL5B=4)C7pU){j~aXwCqm9h~F
z-Rj=M+NBp=Ntl$TDzVnZs1p602gIcX_S)Y+zwOMh>J_t333h)6VuXNog!)?+4GN*d
zNp44IJruW3CP0TR0CHFucDdBMf>ys`;p>8L;7?-M9e8tk1Ht&I4v|6{1jTgM0^&>1
zv`c1%bj9p5f_b|OO=p}W5n&c`F-c}^r$D_a(d9e`;H$u}WRI_cB7C2hD+yX|AkZ26
za<@4%x=CSDl@Q9^lVLMW3uq0|PR%~!<H=^1N0?Uo#+tC%Z`q@y*-uil&td>Dz>HQ-
zn*HPC1i<m%vu1y@ntd@Yc-QP#+D;C?X^Zl6s@Db;$%h#lBAY&}R~GN<qa|dO{`M2C
zt95%?trN)mp_Map{9-s;K}W_`rOx>jIrMfbeqM#Kgl?THhQRvN>=DIp6z3&Cm#)k+
zC<49T;wpjO56~?0F9qF}YTIWp&{kfHFOQn&%1_Gsw0mo>GC0Qc!X&-uLNS^bjsA8<
zna(<qu`cm&=ET}ue`;kTpM|OFXI=$gKC!Fg%VmNYmLUmprmo{li-a$ilV|{6DljbB
z^QD3!zC4vVO89G9FARZ2FkbVVHfd%fP@8mbCcW6RY%F@XvOr_8=iO%|*;8{Fa97ps
zA$z_V@hTmQ9u)i{EB4$~N#n7oa>AbXbD%2#Ze3yQxdAvq0WZ)>r7rwkS-f`bPj~%M
zp9%ew?s`xm#y+%$v8r=axGhf#NOx+W7A$_dqwe)XXDEdL*_GCj-Eu+p6@(N$Q<WyC
zz|sJpdNAZjXpGa-P*EXeC#X>)t!C1ZLlzg_wT{p?%#r^AhQ*-v0%uU_EY7^m)yc}X
zfl4;GmXl=hIMof)vhmgfTw!#kmA{_mT}pBj!Y>Qp3`ryEHteYo%}}yzn|Q{I@(j8y
zlbO4_Y~W0+T{Cw5?Ow8aB|2*xM&(k)d-aZoOk)L>`ndNseIwm|YI)Q;AK%(GQ$F<j
z?t7W48<iW2hr&7A*1Ry1ZOn@s#^o%h*Y9=3Z|XDafF2ya8&CtF?8KHp-fayCY;9?a
zHmj5M(6YtvA{XRn)^yAF_5=Ij*EPLb)=AKR;Zu^rNE>%<NQ;V1!j3;B8i()}g||GL
zJ~wrGdOj3CJ$<gz)TgJP4qxWG7aA)EWIziNd97n?^_^0yx}w%?(wFG6aa8V&W7Jd}
zO3=M@@pCVaRhQHMIMA((S?eoYafP>#Iu0G-Lv<N)96Hj6K11Pg=qMlh>ypq)A9{C5
z=vF>dr`E*~w)UaAW;+h8@}Zq2p`%@Bu{BOO#s{4o2aWYXN5nzne9(L1plTmf8wYLU
zgSL%>(k>_rXp33{?zBMuKHN()G(vdJ_~?3sPMoG`O#e`!+zc~^Lmq6I#0<!pDr$E}
z!>aMT=J%E}Zt@zN{~4kqCGiZv<W?%f-sI#%El+dn4dD57`jXRJnR$%!RaLA9>ROon
zr`mc=|Ar9pS$)2(qkyRKcPDog+UFZT3RoX<gBIULp?#hkqJZ@wdpul{%(F+FEaaCJ
zCCNO$#K}Si($S4kXrE`GC}4faQ6DWy<~b@(7P8pnl4PF6;$$Ju?NE};^IV+F2NeF2
zWX(R$hjB6=P{1BcRKfFRoXiIlt}RLC`87@!GVp~_P@iYuC}4fa(I1L}`aDNR0qa8+
zKOhR~D`W9l>wQ3x=eY@f&lD$lZZ?y;C4F12!mj|zL9tYkQ}C~Jrj)l+g0pe16}Drf
z0HfwGh~EvXnW|$+HGAX+D85LfVmWh0j$tBe$4i?A0J&8Az!G2RqeK>ZN(OUY22FVK
zNKX@*umQ1PYIgkWfq8$Vyfes~ls0w4(@ffIDHzgr3YAqL(spE}Nn2})v{8vr+OmcH
zLSC{^CrjDF&LyEvbh3rYl29ip*}~HyV;BS{7}>%jC816ZvV}WKLLJ*@3z`+N<~9h9
z%d-V70*^x-Q)decOF|tFXN%{=2_3&?izmiGjyJQ#d>rIhF<X3h9OO7JTii7ca*UQO
zXEe}s9aPbjtUAPSaKbtbt@-&8SSEt7m@hZH&k0}XEEiY^4D4Q-!<Q|JYVCzaaSrP?
z;Y|k;#2l*pP4oe6_>kSWSQ6n!$eLquuZ1kLps}5P#^1-L=JNXtzZ>}7&hMA}iu@}6
zF*fyPetYpdkY6Le)A-Hiw}juZ&yP)A!0*fa*719q-<$eK%Wnq1Zhqh8_Xxk#3u9BY
z{PO%}^1Gbhnit2W9_IHKej{HRo7$1zyZ9Z#??ir|;CBhXtNDG4UoXFh_&vez1%9vA
zPI@EX8x#-)6818qo<n4$N5h@p?rmmz$#AE9zTfXPV3@x=#Xs{%WKp8dVU|@Gin?qY
zz|$XzJrW0;kn~6>0}h2>ahS35lP=n!#3R8%n#sYznL!+8%85tf8gc^QE!*o+eK7?E
zA7Tv|9>`v>k~>1~0EcINglE0Nz_V;+{?h_R7b(w4_lJ{s?niox**C)TvF%InWM%&3
z;Oe&xf~RtV=X2W{p6!Ni^~F4bZ{z+2&k4d4on>wd92v{WaGvgx;N)f^u5@eCdsx>I
z{EPzf_V#Wq>*M6e&W<X!C`H-jmh+H8h*Sq7Rk;_j$iNKQ!q*J4Pv~5EImO`XGryky
z@W`B>bNSb3ZJti6?Cjl9RI-s(j`5;C8kL_vvafCOl<>|CT&K$!a$im2M+(6ElW^Qz
zR_Egt`MvE1re;^tueBclc+LOwme`l9ipk_VSsJ?~*QvPs%QWPekdV}cPX)9XygXhU
zJn#M5>Z4b#yvbwtRq+~J2S<>tm3CLuBwpvHp`ms_yP)D&efkf^w2i<L&^iHS#S1w%
z^2Yx8?%X(%DO`a9FSc6YlAE-f+_!0oop~bL1OkwCJYu(@meUHC&~1jMX(LE*gP$Wm
zpzBwxi``$;i~+un>2Cd4aLl`40{CZYGVnkGr>;7SQjn?EG#AKYJA&o9;79ljS3mZc
z`#7SGyr8_CNOvK!-t<qbw_MMjr8apUeA*;wycn-3IA=TZ*_-flr>pNwy*ezbMSLBX
zDRk^893gxy=yZ^Rt*5gVu}-pJYrn&ai+bjX>Gm~$m@=^8cLs>2ljb-WA9P^n6rRO&
zcR^_pAo4x%Vp>Zf(tU%G8yq-_jT)vXG*5wjqzl&LeW4&XT5f;4mFw&&SI#eLWl`5I
zAZ?+Y(s@_@-BVOhmY+sbut|onRJu#^Q>4%rJk~hx?VLc_MVS6McwG*j0t>rGwVAr_
zu(bhMfix2GZc334NI7_=Mh;r3#Ss$yyIG|aU}KZQd^bQ5$^99BwoEZ7?gL&Sn>Bmh
z`xSvxS6xSD*lculg3XRc1xIZ52O2F@xQ@-PCyV|?8V)vlfbU>$lzqP2*sLYkdOROJ
z(#dCS8?xEn&~d5db#!bArceb((fwUz6kT`-D!IH*3v-x!rOE?ZQ}CD%=~c+koC61F
z%AiidZJGH93GEJvEN7vsV8xh)_Vz4vxi7dSxI)t*hQcMh0aj5333|vl?H4+v-zyY1
zkC&U_WjjjC6vov|pbkXAraq05+e9dgawsUudODV?T8i6c-V7+Zdl<$m#b81S26dhY
z%OWBy)vSdP;UeB3f})D=aD|_%AW3{z?KM6}Q*eSyX8{ZE3J4#@)BJ}0`tP8C%?}Lh
ze@(F<6(P$v1@C`T*xEO|lcsfIj>gh9!F9AGul2n4y4P%;cPDFf61=Z);ThYu#Jlb6
z;VH#oEJc^Lk?9Aqykn}hXb^D_Hj%J-m7KyXMSU=5=TPft*{CUY>&7#{m0674GSnH_
z<>LXCN(YB+<-w&FjYrGMW7WKwBZI$h9b4QxejsUapA0Hk+~cakk-^!xSrc=Wj0_G6
z>KH8ym`Ybp)b@h{-BWWX02mo8<tsRFFSkEreqp|}D0sGP=Ez`oL7^=)GWf(%Njy(+
zc+LR68^PSUbqSt~3=RqwU`-6bQ#rwNFNf#O4$mJ7&#TZh+F>)_b}!@?GQXg&^VM28
zFn2~*ju*974!jzuOM_cJd!yiaRM$>RqIxRnp~$MOLR2S|q6&b?!7njS2B4~(pgNzN
z0BALgtEURpC$Y2))#AHK7o|4`+oRozI~L!3$N@htkE-7W;pzNW*P{R1^g%h(`%5+G
z+m=HZw~}atEFD6mAvTlw`$okrwabyomU=HRAauGiY^ihbdX_W)-q;QUT1q)-sb30o
zPt6Aa0P|nQSCC^Viest|nUJy(H$rujBjeo#DCGYmlBiC0sLr4W&;O%JP<8x|!7~6=
z<rM!rRIjr~^$&&WRV+?&sNN(wWf8%0(r&&8d_%B2ws#($#CD3q_Lh+$wl$^LA_4~m
z52gpfRyo0T4mlz0-|fNa1z`JUtU!mYTLb0Cwmq`Q-r_C2rl1q@CyplLw$C3{$*^Jg
zuJO@wAr|R=wxRMJ{QNCu^WgRtth+VLzzJ?{WEZq=8BhQSkUN3QcO-n+fJ6~0Nsw1p
zj8}0>4TE5sE5@d_Qti714<enewa_<>BD*WC!6DFC+z~YL?)sGJE^1E~HT_@foc<jG
z{V$eLt_pCX1&8%N>&J={%2yDq7+0bLa|v(T`{6uvV2QVFAaaAQS6KLznG&@2dKyzh
z*#$g<71e?mu5^4Wjdv2kaeS8y6#@%i@Vcs3(KeLdWUn%f(O@W2t%oK>>OEFOO=m?Y
zQg@_E6aXT1OfVlh3{U{diAWtzPDJVsdsP3SpN;faV#0%dv*SHqy}KDYfPQn~H(r0q
z%yQ`GB}it%<P|3NMEny634APp{&x;ZqF+yXO23N)PJfLoMW2%hjtP3l4uZaNg8rof
z-BUBtq5rbb|0O*i=+7uYe=CRnjKW)lK056I@<%$YF{(i$!Ky*oTGNLB95%qy4apiz
zB0UI<h-xqueoS;0tTjC*c!gC70~$a%slhsd?x~q-6{$W;HBjG84O&WS(7*r+#99g`
zf^5WfH)`M&pShS&Y==c@E+);i?sZZ>s<jlI8V?Or+siZf;sjH4GouWTV5w2m%)&+`
z3mN=<uBh(Z4zzA-6kJ!1L3fuaw$K9<CG4kG;dmYBtw5>wDDjGo-sRBZqb?3N8(nBl
zUFp=O_aK4%^+NuXT@3jqOfZ%myd(I`=#bP<u&soGBV4uGin~yJlhdG_sO1^_kC=Ug
zcc4Ti->=fbAE-nACx?`HK}8kyHyuGcg8{we0}Ts;E9kKsbSDM3@I*{?9m5h@($-a_
z+IFWgYRPW^^1)A$2M6j--k>@s&Jh_L7DHl9toIRq*g>kJh3isny8>yS7*b~h>5~r9
zKE)#(Y9GbCmdMt-f{yi{aVL=LubEM0XX#~Kj`u{c-sxavUu#|%Vtgw`mQ=3r1nLM*
z6ShX{AHS71=M+Z!V$CyaMABZ%;!m0SGbRHy^=ky=GBq{k0F1**fx?Y;E2zA=IqzmW
zcSj)Odpjr@cmjb_SG^VJsHUI3G%|MaK8hBOd~avSRZEdA#nE!=w2+<}Xh$sKw2Y5n
zrKH`t-15PdFF)%UW~D2%T?{eZav2}pPs2NOPsaKL-RT9lTvklhMILz~bI!fmYi0SW
zKSi&LKUd(IVsP^#aN9U=O@(e^W36&h*ipB!11Huyt*$z)F{CQt3-Edi;w7sWkU7aY
zOIc~ANr%kTRj3-YtbAsyy9>_5K>>YcIL>-nBQ9%BEvct^GvF+>`s+-~401jqrweI(
z!rIFDyH$qUb>*}W-J12hM--8(QFcH@deO1!VZ%sh(1dSQ?&t;lAYevMovOc_ryMU$
z2JA|I4*pUbV+Rki-I2U*zf!vEZqkZPvjX5;4At*?VWdBA#$8;2&t@;2-<p;I`eJef
z6QrmJ|BJ+lc47TsMHIR81(=eyXwp1U`xp%(`U?kOoDr5~DsGuBV`4k}x@kS(2!YLC
zO5a@-Oc6wosiPRH)kk<v>#2USZ=@vWY;dDfzlI0JS7B^2$MP_Q>94td#8w==aY36e
zkWB`bUvQA_AqldE-C+=9B3cmVi_grVOh%T8B8#{d3?_hqJBBAB%l7hRi!8`cFv_cz
zTyO_wAqt>f3PZ-8v1l%6>w8u#+FaN}&@In0QbN9o;&ccyB$B&0B>mQG!Icf;;qKz#
zwiJG*1~<6Jq1wZCA@NKR!NolNydg2O@D&mlmhs0k*ogF^3CbTam>W|?iqUb?QsbuJ
zevAQ#Ru9qQCYG@$UaA+-7CEB*;U5vvs5H>m1-~@~W<<*e->d*pP)3z8TnmXNzmN~U
z7+)AfYc2fES0NvqMM|lydZ)HZ5PP>n%<sFlNv;^ydmXHf!q+2Mm1bnQfhjx;=5vTM
zTIGW=F8!S1CyVEKDy7<4Ve91+r?)gRd8}9P5|>^byk)A{+|zo9adVj>P4IbyhCB<%
z12jGGv6yreCkUv3X+ufl;wnzesI-`Tw{zrcz480;mZ0A1f%Q65Z?8L3EY`PXX(3+B
z?>}XWquB$dwF6PBIfHp(cvCO^wr#G+uT8yEN~vTkQKMf6-blp6=hsVZxHP<R3Y&#~
z-!x?R9TJa{Af=YPjGp}#64rP2veOmDUtCdAOi?qaL}IoNj8w`92UA$HZ6lj_N!#2S
z(-+N_<iJdcpxcOD3DczVXZIq37@BKGRhXbhiEQPtE+luuO?ic+t*3yqH-2>b+Bpbw
zI9NOQJ;}k^v7|>W|KPciez<w%GbMwyoP4lH|MOV}Yr86`Gz8Do)K$ufUcZo>0BBGN
zJ=K*wg46LXuT*NCzd}PWVe2Vnt2wY^31mHnPDghURE>M<{IMIn(aX4_HfY2+Pm^y%
zTj*i?<eSd>9xH}A?`nD7iq*fw&-<@@CsZ_k8uTFIh@&9rzrfXRBYVWv0}3j7rgwZj
zAX*I=;W0R8pEr=Rd#RV*$Sux3!0sIEIDN^u5hVh!dA$8;Rw#tLefq>fc>9rOLf&5a
z*MYp<{^HQQeJwfR?G}~LQ@tmT;8Gl@j<;uOts0UZQzWp<IXrv2n>dpEed}m{WHe_^
z!{G7x(TRLmUhbgjB#+<xI_B{*{tlNLb*Ld_aH?gp(i%BFV%0?`8o(KmDDHQOi?UvE
zXTv=^3XHaUIz{pPde;dkx!#(5@2mG_cOnV&*ESzcBr#P!C6U5Tja1J-iWa318u08C
zr`fq2#WZ`?Y4!*Y)9gf=1e8aXA_=g3%Bl9tRbNzlE`8C5yZ|JE))1Re?an$6wR@D#
zBw&-SxXU-j5-?-GK_uYezlIWUOR+=(aK%jyW?@(krQN?sP9)%TmC#eY2ajMe<I9A0
zr`1fmLoL(P#_`&<g?6vEW)-!|w0phN?j?Cjw7Xqy6KeP2&Y%8I8!)d8|Gzs@^r!_h
zD>$OcDFUPCze@_#6GT!l02Av8A~_fky*ZL_>_ADlQ<7jq4Br*FQ^~{LU<+lT>o2h^
zH0?WxEc~Px%EFDoKv_8BxuIp@3UVR~C#Zy;>YaH6bMT6l^ahFMb6VYtgX;~F@=)3v
zaDPUX6BeAXQcISvv^VfF;d+DDvrHsqvP?d_J<mZ?KeX;)GiRoMH6w1-i}p#j>Uq+#
z%zqZbR{g~jC9P`9GOqZWTD9yrGv&m7{eR>Hz&=k}tA3n<g0C~&b0-`;246;#=ynE&
z#&FKmHvbp$QnqG$tN_t~TAA_i-bqwvIaH5`P~Ec>RhyZ90`q$Ss>%tf;~lCC?NR*|
z9>GhvE*z@+3sv9gN+m;JiB5mpIhxzCR~@?197a^kJ}y}Cd;C4%im~B*2GZelSxvLX
zi5c+?(W@56Cu0>77DGR+`NigF`}yP%T6h!n>b5*Yl5I0#Hl^nrtCL)5Mo?Y5<PtRS
zqOprsJNda^ja{A$VuD`0SCXLZq^Id#_;c9y>;G8N_IXX7U$t=%iB?VsdOJA*kW~pi
z)eCt9H{yRWi7q@&8i=T|{fP5+@Nc!Y=4D!h^E6_Gv!-GFf>z;tTLR|?_e|nEoAeZU
zNQ853Db9`Rksp705GGJga31S$o@0;d<An1+a4#4W6zO*z_33<Vl3mz`lkD=R%Ot}w
zv4BT##YP64|2?~)lN#Xl_5RxEqeGixp8Ok5K?zC*huhSZULSqzPa#h>AY+NiPt!*g
zj6((pxz|T~lM@EH#vav=ol5(@31_Jj@;_|3KDtnVKu`MUuo6_gK3e_95Y^9fvuFZU
z(?`euWe`-oK3YIdP<_T8)!R`}aQ4U$)p}6X2+3KtG8Q6@bY6)@nh{1+%>Hoj*5AHL
zjU=_C1=OxM4tpJekI@uU@HM;_p<FQ5cx|-ObXD4ubtBuSV-E0I>9jwDWIcF830X}m
z^<#$*u(`cf+LN4+^=f-m7kLCbpjiKPtyGu5c}fY+UMqe3_aV-o`dtamrj?E~oXdJq
zua(-#3C>U0qxyE?+>C?xRcNK3{Pq8!R*H3GnSP4L(@2k$_huSQUpp~o&!cxsvZq&2
zcWnrp`ntzTn%Wdpb72sv_X_G#a?;c<*`s<21qJOa@Nf$1w_C2D9u*)jNnhVJiK<sn
zJ4UGX{iXy}Q&2y^iXWg$y@LAP?+n#Ohw3MI1oyrYqI!T(-9m$D{v)qaJ$YwHxxqAs
z3Afi=HLX&uJwcCqdy=4DHLd$?*!JJ}bqPUDHO=_*(5mTE<fQHU?NQxGLBS`{u1+=m
z9`1a#22)Q0=Pz^FQLIkAYT6;f`PoNHa5mMn0!w-T6L{71=wpWSkq+lt;e0of?@l%C
z7gB#XgGs&00xB1zbw9-aEsN<j(nmEPig|L)Ta)eU_0h!Nggm)DGM2DHOdmafkvyP%
zy*_&J*Vevg0{|obrsHYfKjG7L`sj~au8)ooATK^|DnZrjqa_r$3b?7DWqk>%rjK?X
z3{|g>KIl;GwMX^iJc9Q|s7?apmK#ie`NgZ$NW&ORZ8$+fxp>VCrrlI&PuAOaNpgVK
zO8Y+=l6BjMOUP<k>3+=Up$w+JM~nl`1OObcnn&;lX4e08t@OMgdYs3W;Ow>1JW6(~
zaPqH8a5k;9li~a(I3+P{=Cx9T!}$mHsQ#32ewT1o>f)AZrB4?B&uOKky;Qn2x$`Nx
z4w}cbbGw61W1745TAXPW#Y#P*OM)P<yPcUqGLr>|-_wg<lG)ejl=I#HtWUW>I)}g0
zVhH`H!dtcoi57FEBvAO<->q5m!%uCNZw-5`>R<Se*Z(4&%DoBd-*;bJfA3oK&A-j7
zYkjz(G3fZ+W>y|HENlM+5;XtjBavu*L*Z^+p|#1%TlpdXCyIvsH^1l-?zh78kN?N(
zf1DcyZi4y$o9f^3*nhnKcL)E;_W#fG|8Y-kas9)gGDlLfL`8bNF`?IO&Nmkv<ykwA
zaMcf{S<B>kAkZf1=|<^k5Aq1-MjaGdQa=p@H3)v+`h#P=*APGM8<Z;9Bz|6h3_(7~
znF~(UHGx!rNbH8vhcVCu`3&T5{xlqRN&0ODewY2`HOKEhb%aAwuk8FH=22u;V=>xH
zUyI&y3ajVtakC@!9?tC6Lx8$qTdY2!GD^l3<Vt4C*m7aA9Le?xo@A1qs4S_n1Y~rB
z9N)EcbG0l+<dI3WUr8)eCtI?Q)mGW*QfXG%aZW4HIi_qGX7sbOMyArYj+)xJp@K00
zm+o;alP$~&=KRFAmlZ25ImHdPWz688?%S?TSFC3bOfh{jm*ZI@h|SD*6j^qz04<FP
zw!-T?IN-$o3rwBhq;-Z1$AT=<nS9RX+q^@dzWcM-xZjt3;%Y4C!#`6Ndr!?85;)_2
z!M!EMy$wkZ#NZz=Bvnr4Xf6@xo|@bPHXu2iui%)cFz&H2=NHxqI_=fuTzQ+EP<$|f
z=f&wHo;r4hVs?!1T>s+|JQ<Hp4zBv;Ab9!%YkqgX;knGvtv*wD-iVXe@GS18_JE^h
z5lzA8Qrym;&gH{K-2eaCI~Vx6ifaF#v<ZZ^;e<yhPdPve5n2ePK!5_L8sGp`qZSET
zF+40$s^-$91Sm8mDYmA;DtJY&kK#o^u3!~~w(>}!rQsozR<3waDd1xt4k{F`l$ZH`
ze`{v%v(L#%TM&HQzx{lgv-j+oHEXR|vu4ejH8a*mTOOkG#`;_ERJ`BOZ#~5C)DJft
zOD9FkbCZ-tr<g?B`jBTW&)xRZeA6GceVnBSlOLAeO9t2U^AWI^H-eby<AQfF=N{7Z
zDoN8X66n5~*X^h3z5E2HKNB{6rT0ci1RSbcjNJU00D--hZx&R=Q9Z<=x(68?s{ga5
z097J4j|;xMz67c&393&%XsCX`p?bbh{T_Z_C#4@%Z(_l4t<~cFUrzun)8}8_g`~vx
z*^OWs$8R7en(OMq{dBJ}qlbu=sPMuUd_?{K3O-)ge*Kb#ku|^hq&dp}C_L2XHmS)b
z)Z`3a>g^@elay3(;<T3-%xSf4PMO?BPfgy|Pl3h=-h2<QQ-z4fGk6p2C4`5V+Y)$q
zei>W21aD$+UIg!4a-2&CY4qAy-5PJjXnq<w>hw7JJ2`~6?E>loui*2<B9PenR&S(w
z3;NcZ0a4r^byXqcx4A<IuD6ybJtneCNR|Y=*v#no0;~6A+tTRxpvyMQ=;(Lc?WVf&
z0mar<T+rYe=?xB>!?J29KQh5>E2BZ`oHsZ~Ro$2G{tLH@cmGSp+P<3C$l$vF<M$MF
ze;cH(dALOPS4q16-2%-$e)sFA>be2C|4qLQyZ<^theKOCNKJ_0`6OyiZR-Zp%N(B5
zB0LW(#M1_;=NL<dXjGL1&)prKx7bhBD&biX;+dOJ>@_)<)vV}<kCxaF_8(9GJ%%fH
zeqOOq%yTEhGiXV@ZsnjgVohEYF55QFVvTaN<nv^3qOcZ$D;~7^ep-UXDhZ2k6KLXK
z;4Px?m3v|Fw_ukW2{>H?QSg@(nQ67fL2K_As_VCjqk6bQ^~4C(afPVbp!L*)B~VpK
zP#xn?oo_!?w+hvlaI-p8ziGY8-<{K;L;U*uFcw(7;T||xp^-rAslg@q>q`$~M=Ee;
zg9<X7J!ZfD@U;6dhY;|V2*?VoJCsX{ouaQ1%!W;}*l=cLd0|BH0C{PP3coDLB*n&}
zEsbqA7#@Bsst+EggU7};qv*Q^&u=6Ft1S(0OFfBQ{JIftegt)x5l$MlG0|=swao|q
zx_bv0_Vz0p_6(_Ouol2Y!`=Y(l$v@Et5g4xKlqu=u0*(3LYMZGl|Ridw3ZV|S2_11
zdcsDi9LbFBD+k^E$fkwmwV8AHe?I4*_f@^RiVczFW#kCwbYo!dm_$cKZ+UHQUwgiE
zG|zSbd3kO-J<6D=%>9R?Uh||~x1OD$7b1f_S*>UdAZZI}okzabBVP;hb#psFz82K#
z^2lp2W~*RI=ucU88pSeXz!ck=xMj^1zUOSc@nAka(Xn%s*|POEmR067X&s-qbPT{#
zMpbR>+L5~4ypXInGqo7v57sdVEs6G>Ikc*U10_(l_C#Zuf><pA$kOU2(QS#jnoGB_
zZh-c<K@F+B%e!z5q!`7gdiSYM<+T0QH{+yx;H9V&LmO6vd}#>&<RhB28>=mG*#{uH
zO}hf-l(SXv6oF{d7}j8Cr|JmCv1mW77lkd7YDNLGi*?`EY#;4U_(4~fzi#_z`<b3l
zI?bfL`;AQdhwW0KeBh<9<MoB*QEIw$u<~_dg0rUPRJn#d_BSx%0_EB%-_m_m<L)-8
z2B~5EP9XweeYliZuGug<8T{s6Y5y^R1?YvAj7e=PXejeUj-%Dh&X)}Glrjkx3+uK2
zqw2rLR<NbGYE6ZScAd&|M#8qrT9>N}T5(?B&)D9iF?cVs%68vm@R@j}BXUbY{LM(;
zgAa1LQMJ)Tz14}1@}*_DgH<;-jj_kMo@FV$_#G~lx!;7}z)5*WOzhu$UpD__UdSW%
zQ5`n-I|Z)UsyckmC<&3VtTGfQd2H&k+mRT2`&JvnoC7I2f4<~7U-+_ZmzG%sY%J~4
zZ723;e;Ve41pEW7+811j7P7Nx+g0knd=9&Sw7Elt6ou*mr3b%)N9nM;54szQwKkV>
zYjY`En@i=|=$*9*B)-EoaXMP++joGzmI-EkjE_jNLoY<q_}o!ej4!2%+0`rcQL%ck
zaVvph_nU6%P=YuAySei%Fsd~6I{VMUqg|l1(rAh_nxqlBIj~4hi*<)PZ7om0Wv{ah
zl+Oh*r)Rw!*?+ec*na>xOED}PfE#@C7H4g=t+0h@dUjjz8WvRCHmQrPSNkZ7a)6_D
zF14Sk6Tv0;F;<X^vS>uF%0yfy%q^;Wiw7Y6W<{QwrLV=Q@lh66v1#8~vm*+r;Q*vO
zHIMwz+fETRox#DIp~eSd9072s`M&*BHG@m=d%{i}HM2(+ZOu|6X=@e~_KU*Hs<7kq
zL<=-olQk)sCTlY1DdFwngfU`TBzAVT2YIGZ%Ad`nW<6gxkfdh4{?#}m6e$3bpL;1}
z#LGV}XjTsQIWKC~fggww&gfgQuS$kNOM4U5J6z-XV1xsxf|{1tPt`B@2_7S~Wtre)
z&l}+ycYqfss?#Hy>^v`MnhpUi>Y`3mkBrf@{*^dQ7Yeh!np@c>>>77mAx!|t)AZs}
zN7Did`S$fj`>BM~4o8!!V50Crs-UI^?WgM7qN!XoN$Rs#L4nGvWo^LLiwLyy<YD7t
zdyc2cc7@W0dlTk%;>yW>D;Ws|TL;Nwx0AH*;hytboLhbNRu_oiK*aVrN8r3<VHP<N
z%YD<=8cE-ri^!uX1w6MH|Ftn(8+#$a)UrRa??G14oo==()TqaH>0xd_iwzV<b=aMj
zF~VGq+%LmCP>Pyp(5^_wGAnneuHJDR>P?p`k3VR3N_oz105Ik%eIU5uZraObaj7eb
z&d&65c!)cBHn<WiiQuPy$Rl7jui*d5zUIdxSt=WoJIETD_iQF9*{`_ymz*7U*eWTK
zdZi%To%|*)l%{%KXH0rc_4=RVz4{}Pz`mO5=*YeIp^ZWZM5eC?k1ZJ}YExYPBr+?5
zNttnj+mej^B|Bh}vjZmC$UKQ~%)>RZA8xi9$K`ZUh5qGs%-ATCNK^ySrArLE_@?(I
z{DuW(0LgfE+l!i|wUByUp4%qT?#$Q;Mf49yPh|F6nHlMQ$H2LP%q~+LS&f!`J(Ul-
zLtQc(lhuy4;NWF13<fJ%7uc8_ugO_G_DDTu(OjEu)B~)mBcm%*Z7Bc!h&(56`QJDv
zyHqXf4}+n8tUw2boP-=f0<Z8$Pv3i9#Ei}K;g^Tl;84X+$`74fqzlDXIPcJ++9n3+
z;155N;^YVyUvif_ylb-kC^#aUF8^)(%`XhP>kP=9+J@4LRFBJHRn6_k+18+fY*vkx
z+;|fusSZ*W)jmff2OlUZc>*PEdIg^{BRJWp{hbk_{aoV^G!`NHsoO(Dk8y|igcMvs
zUBcj{$3o;6bJI~!o-c2x{_HMLJvt&sS|~U*DjK2RQbqcJOr#i@*H9LYa!dS9=+^p(
z)9K~FtfBJymmZ5z|4x!6l5Jk-(<?@KR#>gwEYoEAuC~UC+Tq%@W{unR6Qeo~6HJ@r
z+dz@NH*u(BG1>(j0W{Jk0x)+l2u@3MXim*ZO_D&{wLZ=7T2H$z?GXgw*9v~UOx+h&
zI^xE&Pq3LZiS31Z)Ad_;;UW&QDp^_O1_1VSuI_M&dZ9`i{{>Upf+2>yExOjwF7fbb
z>YW<NbHcGDd{ZH%Y9ug*jU34I+TAOyD1{@f54PGi`i_e1EDhUX!(Wb^yOFIT`(Zwy
zB(4FF?f~KOYy2ec|LQR-^d~B_Ez`UqydQ_R3p$z*#U|yxK+5h%^uSQrRd0-U(H8+s
z7u}C}xHDnS{$4>Bomxo-b7;iwj2mn}%Z`+3S}s|5>G|HfX&98;5e2Ej!ZkDuY|Yqh
z#K*9?@WLH*PxTSZAKMkjcw|}bT6j1$L#}l4)@ijzEZDg$cV%%&uDILovh6c4V=;A#
zFFLJAVw8ujX3$qPgZl-fyD&%8r?YeLd{`mvDGgb_Ert}x6A!>2G<3Bdj+7#|BMovR
zTpY6vAsm0yNZ(~>*BG<;$?ZScSo(hv-GcZEvl2~QGQHcm4eB;_Z{VC3PCj9mUAe5y
zbf)|6auw7`Xj6Mvu6R)W6iG|T_B&-i_d>2MIfGzm=+LNB`T8}8rYo)U5Xz@46XX>S
zTG~MH;A$yavH^Lx7?eVI!sjW1B&<|#qI<*M-JABtxg;R>rYjS<T^u~Jjb~&G(=mKE
zUrSyR3hPVWny#dOR7Frv(R_7yY>VQF-V*-bzt0=vf9Sv>Ajs4Oji@UkwmYh_y?kPS
zF1@C_R*jOY>@`Ppd98>`^(KxguWjFlwB9kKm@F`<ozgpXLHSWrFE6*U<+%rzvJZ4~
z{_0}+lXOYef<u`?xC@X*VF#s<183HygpBl03cy31jpizgoN^IO93Ki%+ylx_y{-dY
z7}7DOR)Wsk%0Lje<XX@B;|eN)C3OZm`Tdo`Kh?XPtE^#2Wy{P^I={cHx4eAI6-Mg~
zt`)@k<Q@HBpZrq4_rY1am<}$1epo&%$l^p)a{Fa_!^?w60$y%g8d}U1FG>LNA|Gon
zZXv)(WERo7Hkw7WSqftdzdBP=UiDcFMH+9e@o6VTcJWI(XlWs=V*vh-XX1nI<8ngu
z)x0A*rtA;b<p*70?(Jc!p5BBRKy)5ghku`ml{1s&secDl$aC=Ea8{LREGwtt>ExMS
z)^S3?cY~?#K1!u;k=;iX3}_h<yAKe`68syk465vhXW7qV1OTgn`hLj!aPV&6TLyS*
zWw>`1!P^ITm<Mhy@=`m7*4@jUtlS6Q-2FnO3mZq34*}jihl$wiDhB@RfNwozw145<
zcyBZ<vhNEk3oGf*uG6%P0t3p;KRqvSkD5T~z>8Kha9WMgtq|HenC$tIvVyL%W>#)U
zA@;aT9G<;XKUbdN%6D%ADx07yo6<J$O!n#W;ClerNd021K7|H}D+CJDRVd&~tN?kH
z;tqZaE6RRID`aqZ37iXd(b7t+#qKggKg2jlh3rM&Z-%{m6Nw9_l|`(lfD?i|>%T`9
zS~Zaq>-C~`5OtpQN|L5=G-b~;A*^j+X=vtb^^*6vgqb!Cm;}u;VNin)G-~5rr-j?f
z5x<kIIVM|kOx8EROtuBKsaAe!?o&zy!el{k2f0obl@fkCAcEh#vOfBa<eoK(++jT!
z>2Ms0z)dSMuBcGws-47~z?#!_wt4DojY{XZn;{>Xz_T&9ogPlE^s*G3I*12ebUJ7{
zG5btPV)zd5)3|;Ex!W0Vn$|zld;e%nPXyS1Zd$*A1f9$=X~gUUNT<S)TuDcfkow-n
z%gfgXq%@6ovzsQ#`&ug1KZ+=N!y=2^yb4%sBw92Uff76l+O!Bez2U<B;wg?UYwkt}
zcCIrMhoug-PG8m|pEO;etU`My^)*%w7M7JX%j*&L^fIJPB^E9!S8}Z2UkVF?xu%q`
z>>@IWClWZ7$wYjcCcgFF=X<Az=h-*S*f%XsRrjWm7mSb9_<Ek3j#SUhX`Y)Z+$aK`
zqgK~lt$s*Qia&*|CCs&HNG_$gP7Q6qS<JgzAx6ksX3PE1XpS6N9W5Dmg{KX>&IOuR
z9{G~+rNzT=055z$V3>Pp-kSVATw>Jr#aBL=0`RoV==+(`&bAe{7VkxMSce(?%+&$R
zEz!zjOCov2Lv(yeR2O*bAJ$7ozt&~(xPXf+s7X+hNp@>}EqQZ5LPi)^cbPU1Gh55h
z7k*9p3qKE;@?`0aR@D#exrQG#vR=)GAx+PM7|Lo)NZh3?M^VMB{DGu+YPY6TFJgVr
z-2fHm>qkCfVial4&y{EQKox+BL^X4aLnGOJGjFhC2|xNLADw=U9nHp$X3vi1S)DxT
z#&+vrF|4VW)aIxQYjnYub0=t<h2>o2!xVSnJPVDlE~7XF$xA>at1A-JBJoy^Iwq}U
zhQ(TP`a!P6SE!`y&u|S=w!sMLG@?4)bENxqPi5z<UC7lL4jXGAh|-DNT30qq*I96G
z#K3rJKRkSqMU&@7_Z$j$>>B@=FQ2<p>4q)rX+z8FK;j?bvS3Cod+lE{^8DoOUr&E?
z4utb%#FwdzrU-B7dgA!~;q#u|6@!cUM{rLx|Bwlm=|h18yEA`uDxZE(r{w*l=0lSY
zOL~m0TG=PGLHMCeAEJS`drmolwWA7WpfdA>J-Pwsusp<6ks>wN{dy_v9(z%up+o<h
z_+9IN!uPN2fB9KwM1J<}0`kGtLM9v=b|T)=?0wO>JO$=2JrCZg;xs!uwN_N2<#d)3
zLpOY!6r7G@o#fi(vS*o1vT105_d2sDV8J5Uswq=>Ma-!BPHAS0yWy>32GUzFA8kOX
zA`g$Pj2M!#l%CoQzugUG7akC{Ecq5$YA<HJp3~$Ae*S%yDMk<vphi@R$}|>~QL3Lk
zHflT)<f#0av_E4bA3VS-1n>v2UI61+<zJblb+9_O4px_tPoqx9l9+P?FOrSVRt8s?
zrpZk?Hc>ge<Q=mlbt5)GFnSdf6P96~W>+i@saeJBxWCr0SapbDFI}UyAxFfNtIEBT
zU-Li?@dZP<fD1lPcG*>hW!IcUN0M`MoU>kn-aCo%^7q!*C^_ClMwX?#{o|88y2G0{
zHp5~1^p?+~xMJwiiH?K7qzma&z7E}7G=5D_PY((Dr&mC^9J%jMM}3$Kgj(LUAePAO
zOvXu8rv%o8R7&2b0(DaRN2#fHR{MwYHPu>8wS_gQSY%#lDo_i7i-bxeFX#c5;v0L*
zFXuNMG<@48H1)ap0IyH9f5O#q_8X}Kw-nA-n5a5r0@4FD8T9yT=3`-Sqz1pCzd>?+
zZn0I=v5(3%NiA(}zRk6fRNlr^3)kMB*>-vR`&gS2^iXEM!dKjOyryVRnGdr_!F*8n
z`YYAf-+a7zqZP*WD`zdjm5POTMCybMeu~Q=+=YcQ_^W~D2S1UTGv;z!aw7Qfe~NwC
zWn}SL%Q_S%cfIkLd68hqHAdQ1u{3p8T`MBsV!rbA(%}b!uVTH?ur3gj6Fte~fXtdT
zF??awIxK@PHZ*k&M#2SR=y_pT&ZI))Qm|=7A>!A5%cNq2Yx}iAgSNkrRN7v=cstrY
z;y03vPSM6xHy`trMc)ZpsFXPNR=oU^s69lJjbyv>$uG4<oJ#hLb}9wG?xy``TS#fc
z{&1X_YPcz-smY|&nxF1tWA{~EYzIe`&(n7tlL~Qu$X0lH#lJsNNb+#<h>`L=G)a@P
z&lRhqs%5=GkX*^MOTRTeqF_9o7HrERbogzg_3jWJbuF4^aWc{#<=2uA<AMqn)mB4Z
z@H)NFdBm*^&ES}1n3?cdo?k7oHk89eQ<yNsJe7Tho?gr;8}oJ3#iT_0fs}Ago4%@g
zIMBQEyr|-p4A`z>EeLq|5bGr$r&A;Hp|*KD<YP<ycc{M~jSntNG>g|Q)KFTqIJUQ(
z8LWKt<@5NdN8q$9pc$pwyfXSct+sNZ*r1RZ%@+Zj`yp>z;kJ*^j?1s~C-Qp~re?+k
z-AKV&t7zoRTW58}X|AOdrP(PnOl<`=Q$tsoJXTF4HkpxTV}!YWZ~@}?!Fj=Vk&$_6
zEl&*o;m96NE7MfpJ9S=p@N1Np;UTx7M#kAgV|KAo*ee`@7ztOqH_ftq`#4)>AG2ll
zA>Y0-7xu+m&^TG!1?s`&#36fisak`Bz9EUtegV1)fht;VKkH)_hCgez!Lae{xFQ(8
z|GL3=kL&I(9>VQ0aJwip&eshNKu>M5=V`~lI-0yzRKgLdf#}`1MfVK}q*Q~=-W${*
zj8k&&$qB1C>&bvqgUH;OR!}N!rGQjWs?ka{`ce{K1yo2Lr|kze{7y9|+_|L66*AqY
zHmwiH+d^s!spoocTPyDr_BCLANb_e$;?V%L@v5ZA*s6n^@$GU(U}(8wku&1IBlPJN
z3o8q4fX~Pm_0Mku6vo53*{HuxyHCrGx9h-=KIhYuHlX?Jk9=##X9#6yEMYvyaIc@>
zVmnic)u<OUZ-Cv-gQF*<EY<JAOeH(%-F&J!7->Ge2xcrQ&h`zYhXko<JsBLD#{o-6
zGpO!ET}M0AI@+Ohw2A6y6ZtwzZK&$kNK!2__AH%h#!N*PNr+T%+*LFuGE%2Z{HBhg
z^RVk=G6$3qO?wkRtiL_P4+h97|8B;+#Q|rGO%<>Sq^4)j)ZC`exlV(lt}#Q!?YwvQ
z3VKw$*3wvO15R1Hb~;TO(LPr{Ba=OkfrcK-lRbx$**5Zl#}1`%zx<0uxS!~7?|RH|
zf1V$3zrf*s<(CZi7SZW&KY4@U-eMQ4QO91T>Uc+S9VfXu_H=dhxjJ+n9Q--Z)p4$<
zbanjp39IAW>~U7C;+>`HSn-7-Iuu1u8!Y>|(eX}K$LCxf_g-yuwC3xW=jv#+dm^FZ
z@KSYrsJM=kT^-Y09jp0)SO4znINQ}RGhfGEu8x_xi(EhO5tQ7>?II{qMQPnA=!H%;
zEMk8Rd>C9A$sA)~onBmTaA6~|beE8=_Yn)KT+Cz8^r&q(YI7|7)~}6)Z77`ueEoYE
z7ttvG_j@pXRlJ{=lTftUpgn9XxmD3zdTnyi`bD7<^io+aetX{TK?efiwq6G>_Jr~A
z_rqYfexZrILf;uCnv>n~<ZI25E7LSWH3cVYHb7nMu#;1)R+3@^S}hM625YIyZJX;D
z8*G=aYe867?yP(T7YIhtmL*`+g<2v3jMa;U@4i3}8U;g7xxL)EiMt55R?WIw9C{Da
z5s5|Xev_NIwxXGdC}{}Jm=~Xr)e=aU(sFNmojsuu+sE1yCUX0T+-~e^+ua4q?X--K
zL_{v*OCr2Du)9PUON5Dz=?T(I08ukfbc^|gp-*}Fh%C+1Dbu1xVuRR0nLdn*Oz)<{
z`j=Ny=L<Kgt9J1uhGjAfD-E&iN#I3^&P2yyYM!=xrO0e{Q@SKBCts2?O4RP1-5a_H
z2();rHkodn3w(xW;fykjOKcj{=DVFV>@-MlG>G=w6_4&ak*It>4%T%h7!NKGV><_*
zARL{Y2W}BQgLV=2!Pf~^c1EM1iK~LPA*b!PRF&8uP?HS6V0B{lPyo{fz%IfR0JVnz
zJeM1qbE0zY55nSUL)itD_B(R6!bbn_DEbp|RRqf~*2E)NrUDVoI{v@Iu+f7q&quI`
z#|>s)<SbS!?H3r+0?q2JW@B*lc&@12Rt=SwjJIV*vVr3M1!elUGT4S{J98_S5xkMe
z90a`3L(2_`17w-BegmDj)1q7V2a6ERi3Mn$;n1899WJ`H2iXn-&}CF~+OCz+E8W!M
ze1)Qb%7Sv+mTB8qXqqlTK|-&P%eQ+~%g6p{w6&?$sO!*kI-Q|bAN-N2&{T{a?!R^B
zV6g~RFj|VKDUDb4!OoxK6~3onK<BXZ=l#{z@pK)Y8n`-nXF0}Q$97InygN5J{LI)I
z|7`lB76qsdL}`o63`=ht>J^!O!=e!B7Cq$kM;<e{fXdM1QPfSP{@8Jqj@Uo+I@)d9
za6|cp2hh{l|G*|V&57z?=SiZ>kYw`BDF?8~-+4rtt=G?`@H-t}kPL>%>cAEO)3h`e
zhPX7AxPz|40k?#wM6&1C>c2FkUX{6l{mZ<XNun)M{*eMoVj2HZE1+;hYu!e9N-4)^
z<HN!nZ`>u^(KuweCj}2l7Rb;dCbSH8q*Y3$u<Oi<16owu&wG%#*yU_naiIU)7JO8z
zMex5RdmPQ3{e?aVPNHKk>CQCoc5*cFLEN*EUC(RwNBp4;CaDdQSLmv55ieTGX3r@>
zsT9Nn1u2209O9E!2BWH^b#>5^DxWlti1<WR;+HOo;B%O!X5<1y(3k#V7lpAh`ZRUO
zr`(9#k-0sh43mar(5Dv16};PoVNiWKdzQF8gk`?<kjDlWE1!8}Q+5y9DZ7gr3)VD4
zZ^Eh6X6-)%7~YPk5$Ce;L}{JFHX>iheb{}$n1!xgnoNubH7xoTdvB+{xIxr6nje$C
zZL5Ebn%OIa#>ZU`=qS&1<j%0?a<?5kLM`_$Oa6;(5_(GBLy*%@a^=eSP%<4UU?`dL
zNT{PXT$0z(Vqnt{2EJkp6!r5~sjK|+DC7d|wB?sl`T_Nz8Auq$2rC$r{9ayT^_tib
zd;9grS$(X^_0{}$bi`f<{WBa61w@?~rRFv~=*8c3V_Ktqw6ZKymX4Gjm*`Q44>-|X
zqgT3ac8?0GAyK7l2kGXsKZ`z>{0)#jXqoFI6L*w4VQ*qy=a}s4)M!(GWswx2ww=6c
z^b$tV1dMdy9W2sVZ5?DNqI9ulr=+aPk94@KEp8gn5}XNFvL7<691gwdN<f+6U)DYa
zWmP|-UG`B`jMK~SjC0x>9y2+T&>0@1FN$&6lV&z+=KT9&hs{mNw*tndXW^~J9+Bmn
zV+oH1j7LF;@!vwHg`J;8m}JjbK7?Z_L#^Xk$gAY7JF?S8)RbLD4-Q*@l$5Xl+RP`-
z128=wu+_9kE=WR04yKg9WE^DsNm`+uIlY-N!F%b&4EY}q@p00TuV$!_EumxqRY*2^
z(hJ6qXSr5tjfRreU`LFY>`l@izV>`2MZjose15QKuEv~;tqA9H=2=`Byc@~m@F5Q0
z>{$f)?l=^``F&Pn$VF?4eh@9>V#)5Hu1S?+ROQZqG*&0CyjrCT*j;pMoUn52m6ZYm
z)RBUTSHOT{0XcWp&QaoCN<=oBa@%QyXwv6cYbl<e)?)qCno7&KP3kfN7`4=Oh$b!7
z5i#S=w2Za4tmR()H-}?q)N-9cGwVOu7d#`D@EdFRsI6@1f5>MNL)^5y=ro2HxgxSy
zI3>wLNd5t%93*}?-wbb59QQY(N{y43vSfr&FjVcV(JWe~&Ae4o;9F<GZh4IOSB^K&
zfs*4Zvn2JU)^KE9Kx37ZJhY<v-c<TE@!=W}+G7U?-hj%`XLqW}K~gE4PspKkZa{eD
zg8YEs0Gy*<y@a}g`#$Y@OmlP&NOQ11D@p31${?`uQ%wXM7wKQzX>w!T*@6L81yA5I
z%DDR=vd;?zAc!70I04cCo%Ot$d6~8c<W|y|z?kc+_}RlO=3xygCBp8G3mtYX>UsQ$
zhUg>X_}LJxa^VDXh?8SIe)p`r?&>RD<Yaq^escQ?FiwMhp_q1x7^T2wqtJ#n#l3{Q
zjuQ}N7>e6d<iwq;DN949PYcX_n!euhXA9%!xGT1h_LE~U`;@BENj&w0z*&vihm~}B
z?&Phjzf1MoEWxP(QNLJeZpLMgP^RC+?6c#%K}QXPap-L@r2oR58HV4bRW>sc+PU3w
zJ35@*ioby8Dzc~WNkCoOidSwLliuuf{mplrzfsAO{j>Ox<fI7ihYy)G_}H8^JRrWX
z6%zih)nj`~kCy7pSWC6*PaE{zY@G&VQO-QA<4lIh9OkJ`{nG0E)MfpT;+^`365hU=
zD^`V_dfaCUIyC^!Q@42zxWS8`RJU<WRCNB!S6$auw&Jd>D(Kq#Q3W;CazZ4b7#|0t
zpqw=vcmB(TGF3zJl0BaTjI-cHuQwS*?_j&#RcVj(k@j;#_UNw43(j}Fn%S0*uy(iS
zHo4n#EefyM-JUA|-lf;9uF~x9s#J9acU8VDM*)aE#s{ZCiwsNkbC?}F7iyviB}wzd
z8MnlleVb$UZX8YLH0ZKV6)>A~q4LcB>?a(v7gKS>Y`p}(W))8)KF3QjvsDGmzLn$N
zVD@ds^Qt9O7<?H&y<_$$Z(|2mK2(jKWtfW_NS|#YX>5X&7ERgR2UUp1%-0^%lJ+Hk
zG^dyuOn(`1rVM+6<$+4hzgxBbwN34q<GnqGrEBU|*VL`5v293GV~NTfb=Q&(Y3l9e
zQ3yqSyH>~jC19&bl^@o&p~15Es~Le*@AW&R`Hq?F3Bx1|C)~UB$tyld_F;ti5?#Ei
ztn~T0?VrjE^Vz|-4FT^8iBZ@&i<VKc_i#8jS(w2ms(rcuI~=L|EfA@qfaX?NQzJ!I
zDc{A$m~F5`Qbm#^d(qOkWIyaA`}qD)vVV=L2&d&VJjTVj5pQpr;dpxk6-P&7=_M#<
zJdMj%+(J+lNcJ!9GRgkcO8r!A4@SWqec`gxVY!|2oR+5umuBPp|02Hj13%%SV)dvQ
zMLi=7+2^fVM#8^r*}u_%SX2%3oyyQ(OfxN^DF!=|Yz$z=`3+vOU*S)9`5l22#IPfm
z@ddNP`sEUxgdI3pW2ajlXbK*d2b{d7_K{eXA|KWjf`lX)sA;v6G8ih8gVVT4(#Fe6
z&3T~ebKB{548?JA4G4c!3kI21S?^=&q_l>=-g{TPbnIMXGHT<*j1V!fXDO&BT;PTt
zMNmU-4Bhdkt7PUHf)UAdU|Yj74XyqqJ9Y`b;R;HNF7>f9Q$?gB?T>Bhf_i;(bG%{f
z9T~U9L{0Ext58d{pDFs(6Fq%;%+vR}wvcR&KCwge37G8kCHkeY>Vu29jxYDYVW6jt
zd*AfX;X#~xY1J4BOvOjPS{AWxobLDwS(kCFy9LuptjoMf))n;(_c{ze7eJnC#&qyo
zX>$;F=*q7cZ)`C`+|Q7{nBU<3=fe>h_N0T?HB$rYdaxGMEhxfa@KFt6&pXZIV?D1v
zL!%6+et2oKhJOEIVyRYEvzau5sW2C&OZW}?xhW|xnbSb@jSJ>5_zENBv56nEMjq3H
zv$i+ru{|Y$u~cVmTk6(X+q>P7A0|Kk-S{y1zd*(;%iJCglee8yFieKl_9pTLSA2|y
z@iW)R0K7(Des!gqj7W5WGqyrXikHNc<*I^V^0z;+Ve-8~rLXF<R2cj_jy7iiYQIcG
zUfkLiz24g1z@xXe?J=^p^(Je(yhZ5Q`i-{?oe9?LOt5BsYjGx+ig;_gMWPno46o`6
ztnFU8&f)u7K6o{tM`lI(Cz3bl7o+7lew~eKDb&^KY*c+v)vc<?*?}3>-P&YfS@Uht
zem@0fIj;6qeCPUj^NnQWp!pWA2%B%ySq04(+V5(YV9iHe^DW^eYCgRL@4#LeuK832
z&9^^QP}AqF6|0u<6Z||3(8<0$LVaeDHNU(Bn6+2CqZUXMPlMCdz%U^)x*s4l*5caM
z;0&c9Ep8_12EL17&Lq`a+3d4}9nW+v-WfH7Yw^-1sY-c2LYE$CJo|Ol_mHMve5sh?
zhzfeAJKjkfpjAlLQ?LMbXE~A;V4}@=SIqhrI2H@~?OP}%<Vjxf6(u23k_*nn=-{<9
z<;k8NvdAFcpsb>PwhHR4Z1(xV&b~bt@Ls?GHy@t0qY~{SeReUKoMo=!ad!%t^wC@9
zL)frzj*|^5ruoCxS>_Kd&&%w_>*6xIm+0@SdGxkWW*bo}B`otzAQkNN5y$tXyhN6{
zUV=|*tOj>wbDblva#RH}djVBY)8oWApmHXIQLrB&HOuy;NDhlFKY!Hu_DxMB=UbxC
zSYOLGZ>;MvG}dYLCPt|NlD05Pl^ja{mG~BLpwxIO`+bSpiDLv7^J{Kr+PI!)>wHV~
z(7vO(Q@<W9EOMP6h1|zoqmQ%wLWa`)V6;qyETB;VVb0anq%=tcdQN9*aM+?;U8{bS
z?+L-R@t*K*@*|%QkimIhjz-JGdIA8<e=YF}wrf^TV5st{Tc<tD_^j&#%23<~1e`wb
zY1Q6W^LzWLYTzf>TVtAc*gi3ml4vulq5*9tFmw(36FH$z$n@FxRT$Y9)|yhx6Y)OY
zVc1s`H=gc7M_#CUV79R~*>fiYMp((v72D)|MMJ26_Ul(lXO@kgm~Jk5#(AxiZV@+Z
z7E{568SYH5B4v)~`s|Co&b*qY0+kK@&3eu)G)<meL+0#GF)V>AWWvQTE60m-jSq@=
zi9~+=PrCUUG1HBBKB|ej2eRh_cChBrk5_Qq|HZ6%1KQYsz=s_B<AFUr^DR7;EFqP?
z;r0iJXAqU7#VjG98XH_Vi$&V$6~4$J*sNc-RR!T}W^h`l0;F<EBYbMVR4UKfo`lNa
zvq*!j-L`)$T&T6kGCo@18HWRT#6NwSLp;71`2fa&Q>I0Te~SK6gkbhP3~mtxwklx<
zTY~iTP)dg5zm{L8N9<Q$)I#|<4cBq@E1t?@+doa%y0O178fWZqI4}2%s?UC(r|gaX
z6<#HVN^b`{FrAbJ>(67^a&8XBy8eU)s-vu}45jp73oApVXNE?-0`w<F=$Co)7f?Jx
zUoSzkf_<HM<VNKxO^`Lv&s(*G&;MuRdESB{<gWrzYWz`DXf)03)0}@D0RhsJQEaF_
ztJ&1BUHk@<yk9z%u>vn?vW48FwzS$*vVOloi8@Rx05KiB4-}-x({89hV>m5F9b25D
zpTrcM?uf5TkUj!#pthA0^djyS`<G$?v^Nn#uz4mWi3k_^o=NL80oVeQHp8FLUvW6~
zzFE#pcrMPFDIoL)IWr7?1IUD|QhsdYd`u7VnLmQz{Q+?=ft-a6%DTDLx0Ao0H%U%o
zK4Kg_;jsIrEYoEam<ydZhbGDOA1p9Q3j6`H-v`@D`U8G?ncAhaajq&bOlqitnq~`?
zzN*`J3$B<Q`UAdO=nt@Y5a7gvdmTGA@Hp81>4Mo&i#VbWWwTEU{%pv-32%Tu?rE@J
zGuf6Ee*vBX)#u5V2K=?W|J^(R>F?zm?rUF;H(ZNrxVy;UY{@^qzo6j?JOOvS$2Hs%
zNGbFL>}-?X(ha97Xt?RZp|9qSo2=n({x2Htr|n_GJ%?E$WwHs#r9A=fQPY|#!3xpx
z+iJ2#qMYpM(`%`=zObOJKap?iGlNm@6+M1wYJ&j0K|g>5i`l#Eh%O$ZMqkA0niRCi
z2|hd3aqR|PVm^Q#7@gfD_FKmv>I1mLz7_ZY>~;}^={Z2*1Ne;3Q7qrdo-Q&J(0xIk
z?(>2jeLK2w#MdCw->?TD#(>3C88M)DrWhbqA1=d6!EA9|ZY@%w2GP3Qi&w|xv{R(^
z)r`F{l+zRGr?ELtxGrZLuQ}Cme5p{{SFE5d^b*We5d1I-MpYoEKl-l8X^l|nt2$0{
zI*#}tH~T+Tg*OPIL{WOS$-s+J>M(YU93Z;<-t?eJ=UP7h%K=a{l>bA#mKr}b|KDH@
zTJbuO92s|Zg0(7bo#u<i){K7DpPti$^9Cdk9_J0%Wn1@AlIW)TQh;t;ZBd$r2c+j*
z^w_y>s=vead9i<;g?9;;3spOp{D^&u3{E}24`mV)djNbwf>%iu!8<Ze?A5I!^{khm
zLt$b_uClrQ1sN&6Fq2Rfi2WVkF|j{FsPt9M<t;c^Lzka7rnjMFSkXzSE`jk8C;6ze
zQ!{<uD_FD-FswK=wa+cyNM(v=8K(W>lwgaU!7<EXvg;~H2^pO1nI+v1+o-R^#3?!d
zrv|_SWZIujcK?@85^T;)IhJM6#AUX%!dUgfiH=p*kQ~j1^b(wcF%c4ds?ea`bcmgg
zdIML3d+T-!m@c_dk4oT(d6e}nbPnj5hGx5?k869$(~=Hj>ay>$SuC|=ALm<kp1D>W
zvE7}OWy$%r*aA09#%AxO8Gy0QqY->dZG%1K5?#qmpKZES^chWE4;BfsD@W*x5Vw6K
zviqPW5xN`+!c=%?=AdpanO49{I?;X<KiomilyV41l6R&R!&|h&Q2Dak8ogdZ=bYf!
zzJzKbw(BKWk0}tc{bz8%$A!OPV)8TNJSitDOv9$dAt^gMQX+h_XHlg~8$DQa!8GS$
z$&1UXMu+zealG{s>=DCzPiwgXF}zVC?j_glTxg}5){4tC9L_|%&<lKSMRaC{`ARk2
z)Y_TWZuFkD6!O9T0LNO2x7wK>xBbE{)TLb)j%E_=c{*Nux1(bz1tb3JCHSC1`h8!Y
zhA~FTsfjtGwK6=FgD5Iy=Yibjfh>yy(Mzy>3`i0nt~8#OwC^|^)hZF3?fXKGXZX-W
z*+gzEeBhQlIML)J%*ULPtdrB4F3kuW-vo{>@EnEQK2?G$%GdH1-b90-yN?=(-KG~`
z;l)&#`*PT2<9#&yZhXB~Z}v1Yx&6An;fDHZlJgbO5kGr3f(ia@I-^djS$^AEo4uhR
zaF*F!Zfzwr(pm3vP16tHsA=>PEF(rEY#QfL>Z$GGgDDXAnESlyS7P?d`twEps8T7+
z65<5U>&Q{cpOo)4JF%i$*lWBvnWbY|^rk5e=K)|vIO`=S&*SVoN~k+p!&^uk=JYu^
zE$6M;K<0mWnEoN`p|=}}f?dD6N;>QO5XcxR&&<Md+YZVVw(OGCNm%HhO1lc2J1DI4
z(5=X0y^3oj*7*#CsQV1=zQI(ccT8=xZIe236|T17@0ut@dnx;HsDExEW6S1UPgfH;
zE_zbxi1oqgnhhGg-J99G4MHXBFXf;6J~}_sr!kpY>ZAyk(yOe>E&AtfBU+47-aq#f
z=1rjXmiy<bz;N?S`V0XwF(ysa1a1pV+6;d}|J;|(ee<08Iw56w&Rl!S8|F;0zjEHQ
z(u}fdHC83sYxMY-9=GmZ+uMKPCI*@tKQ=!;N!Se-OcM6^pE5s5I51r>Nnmb#T=08X
z>P};kL6}m#Q<keFw*Qj?-B<I<{Ui9P`XFz?Ypmk97@MzEIIK6QNOFDyqoZU@MBMAX
zh={><^Rw8aA`Z;YqPMcyX9nMzOgq3#vyPRxSwBmd!LPN1mC=!h_*rVTUIQC90COvs
zRd0&1@e4h1HtsIO`f7gmSjfhwk1Jp!%c{o(OAv%1Y*b0u_*F^*;FkN0jg4aCkBKdE
zY&^~EU>}<fFR)>}$B-9xxa&%n+4Nq%n90(<r#*WWNp9tGnz13b*5yympE^uy<UK%9
zi<k$<wa9rv^)YG@ALbDvvSklYtZ5dDTV4))(<mwO04@Bm`d-CD126--r&?F>*ur-+
zD7)EkGY^^#H^TwDAIHsxpH>l)B<O#-Jl;YFkRJw5{CU_yQ;scYq3LR&zc33P(n2ap
z3vK#uYoQ%f1Ltq@6YRvAglnN&WU)fg2Gv6S-fYWXwcF+!!#<?_9lLfW8@XExnv3Ra
z<!qjUR`YE<B6s~?+j<{3%C+7#!nCmUl;k3K>?2LQgcKLS^O&+rg#6C6!q!v1sP!ID
z)IeXwGV!aR^;)9VYaxFLU&fDB#JAp|^Wv>Hk^Hn?`=ep&bt8m@zKr97^hx0%Offa3
zlC<8@lmx&B@3q#ON=3nGte2Z-E*nmgMI^4#->5P|pzIZel<Zlj6zfHy8ET8gYEz~q
z%I9v72wptWarcJd3lu`Y#i_iG?N$m7FC`_%$%pE;h1sdFFu~_8m6wcCw3)ufvNCBu
zL5&(||I=-){9kcIrOdZ~xU^z>faA8b(vep51R^5a@V=L@g1QTj-HPZid#90}wX0du
zxC5||1p`NqPUm)j1ZS|O@`MU3jbQ+Jhz0g|v#@B9g_;gNdzkvZo_=zMKaSTFcYW0L
z>ybir{d%x*r}|pN(!OZWu<IXjX}s$<m<-pv^Xkxzxqv<v>-yY$00u+@1s_)BfXzhV
zN}1rcvq_^m3xbXBq!C#3!n&)>b=eJcwEEY6h*qD)=wo*><UZ|4xe~M6-C{?Wg=l+G
z1`eLL!Q52rAwi<BKK%L!)iw~kjCNY=k{+-myZn40=piQv+6Ibru+-;1^Kdf|8OT>P
z|7}A0hHbw!hlcI<Dhk38EqBwTsQv7mdKjuLA?^rGYrnI(J|Jwr*_XuIug17j^NBBp
z?Kc3qvG(JT@sGIn`>HB0YQL8hU|p*H1eW&O5wPg>Zu_bF<x<-37RDcIo$OuY0eRa*
z;#y;eNuH`?j~(A&tyTv@l3|8nnyB8qV18CpWuFFuThvsR`Bfk&U!Z6!72<gvF24Ew
zwrR%d%5k@^#9_l}<mv9L<KSwS@GuGPw&&hVUGS&|3(I($GOkJ2fiL5Xihdysclevh
zM5HWukdIIrB06U5vq(dx&tD?a1(w0`*KLlI5&`wW9T-!zQVJ0+b*k79ct;L__g!~;
zxrg_u&BH4>f8)%<aCRadW`Ywj$`<RfDL4lCMY2+QYYyJS2ajz-$qpCSlFhbf+oCyP
zK#S<D4Su4A0w7}I)9Qi?eOiOmDls=^*GWH9A{CsBx>&rmJv`Pw0aGcgtNl*!%2EiI
z${*g1TdKet&+p_RqpsM5W3V@|a?>_=`1-2$na^4m{eaXRdw1-9>iEn#>oVuBBWL+a
zPUfp_=-yC<704}7zGP*vyJlX!1A{fE9bX~8W;sVsetfXz$YU$iM)kqHCnHR-aA9R2
zIap)2L`T<gCa!eaMJE233*(w*A2mQ<P4e@hra2RZ5^5UL2=G5sihpt0FZCSCZ=I;9
z@2w0zIsp>$gXEC!pZY+-ci){_<%PzzyXh|-HNh8|*gDdjvbq5g#q@7W%-N;4;>!!l
zb&*KhtWnZmk@6j8@I01-ZbIezGQs_Nc58q;I+ncF7qaA3)LY0BYGd#`E~tz!iP_C6
ziGIDClJNAfD{XxISub|;UeM-HmfZ|P+Co{V=`K$o3T?wmfvAxaz()%4pz=lg^q-)T
zkeY)EsM(49Aaig;&83GFP(!59F~QM{y^gOjYE%+xUR-3<eB6ktnk{PH_x^A!M@Q@U
zN_uNkaEU*IP3^5KEzLkuH$<tUsA&4uHzP--Wb4hO<?T5g3Te{iPZK-G&(9=doPXhi
zLO<JpI6_87F(gurGtHCezwUdW``Too#LCbV%*A|jjl3HxQ@BZ%z`?|v-Fhotqr)?6
z(fig(=Uwt?P`NtnM`p#P^Ao_JJ^$DnO6N^<t3v6V8_{r&MoYl>Q+}I+8_dz?X*lzp
z?rTd#Lrd@zO+=aaEK@axKsY{3S+1%Ph*?w(2EVkQsv0m2+M7bk_tr4sC=Dh2ur4J0
zY9s!y6Y_V(m~!F;ai)CIG36JZ3z>4w_yVRN<awstEV~5KT3y4o23O%@idc4Xo%`Ar
zF{Lf|jz->Ln4+p-%9&IRQ`Xo|)iv^Te2j=0Ck~_NzKGQlvIeIEAC{(N3KubI)Z8sH
zDmnkNA~lrJuN~l!?TnD^3|{_FjGDV;i!tBrqLhn;(o=9PqeV10JpI|c?)Xz%oUQHT
zg{aFHhHRa3P@b*11LW<Noan@FO_XV5&BjAY{{u%RY)*&oee@qx!<*e7{AT+6KT?^z
z{>fWPB@_@5PriF@BdZw(MhYm0uO|9>?Kt-}u7LhBjWoZg{LUg3bP-oez9AJfd39a|
zJ@)CiSa=n5{%1q6I1oirpn{U~=Sg%zN+$bBW~7GpiBt0PT1QD-4NVdy!}K_>hMv8`
zdfaJXfk}1cDtg=>q}@XLhbp2QFWF-MvWfQ=N89C8=9D9GJZzNEv$Gw%B5DFR7eADw
zyT@2F8IOJeYxbGwh>w)fHj0!98F%}B?rU5b?e;-sD6OHrGJ0gbvF2#wP}OL$W}S4L
zXU+C8bu^$FhS5hCU%W+r73rff9^be=`h?87kf4b+T^*v2b~quXk3QI)*GC_l8RxFo
zM;m)W?*3r^Ja=>NEY?SgT8JwoJNhuLkzO@1{Qp!X<@Hfy4|PAQdudvNn;5wy({7n$
zu%lJ>O=ocMJ}x;OjW+3^mytgjNwVF@9pz-Te4Ep2^8Mmese`_n1~RyQ@e-Xr>=$m3
zyqqkW1$N50*5+Ibgi{5R=*Ymd6G#U;wzbSTZIWsU4UBb!4wAp6q;>JSC|ddQHkoto
z1A*(wD)=o^ID`E?=k&kl{C;L#WA1;~g2pm!z^cbeeVhDAd4A{hf5`C3J}{c<6>Qz{
zNyqRz_8!Xc-D#VM;hmS~89wO~B^bVj=r+gjE9jab!$U=|pn&Dxog>#o8lJ}mfCD!B
zWw7MVi1Yo!v$vY>hmdtxzH7qp);sd@{EiNR*Zm1iC_9@HX8Lf*x#M71D&$P@{P`}p
zhs|w+<P6q4c!(z49eWPe+&=*?FJC%wUsV!5<mC1a3Io&mp@7L6g!W%Ln3}vgH!4|D
z<fIog))IG-&!U}iZBt222{yB3tMx;!*4+kcrp0RgA^||I1Dv9>2~sr4+{=z(M+nyt
zskHgE!Fg9oI}y5guTX?`QRM(n2S3LUb5P3Ry!=m1Z$nH_p8qk=3H~N`5Nk*;y$_TI
zYi1m5T;5}_=G^g)%gu24TP&=HqGv%RLbkN~X^5$3uKSp3i~Mqbdbf{`klnf%t}slf
zCoo2J@e{0fd#F;GK6Qn$O!PdLN_pw>)#mAqRT^6^Q1d`*eK1SMsO0@1A%tP^J$?)L
z9`;Jyt9Tx^*jtP5dTn?c2H&_Uix_+*eZ#^}LI!Ifj&u0=!swG9Y09-lob&vRR~lom
zbpYe=7X*JO#v!NO?~tXP2>*xZWt+wSP&jU5n-h^2H4A$y@qeT=#|!Zf{b#KjGq?~&
zd)TY5$s4A%=fuYY@6`J8oNzptjbez#17y>jIQ79RyCOan<J-!)TXbPXEx%G+d(bbq
zzUmQ5PqB+`R$xLVmM5y|E?;CWscZk}E$N_JK0Z2bvwqEjuue3Z$PRV%23?uvaz678
zlI-Ij@mJ#UC-iLJ6=}e_)GumQVBa5-KQo<DWw{eqBv7m_y)DY|J%iA{r)tc&k6%#|
zHD<yZ>w_yC9ELUzpu_T{D^;w?6+7D(;{+nZvp#6DQq)bUzo`ey<bCKOW`jGmjKM-a
zsgr02@2;Q2qfQ#LFZk<u)k$N+YRq^qD(SE970CdskNN9Q@@a3Azy7WDzvJd}orJzw
zDSmBXJ;1N<sw>N1y|W}VuSLTC#t7}cUyCDk*zfrJlebj{)iniq;yrkVcW|@T;jghs
z1sMi(`qJ|4U~}*hMMw`n+(qSs_TB76Z<)q)ky^7Qtb<CX)4?7`$3Iutk#w7Z8{%m4
z5mv%IxEi{q>^v+v#7`D2mAAsD$jyE5OtTe>+}yCTx=u3Itf;ass7|zVlm?M&#AJ1E
z8rAWkIE-h`F9pLbm<*KDzHO16e-~M89#P89&rOR%y?QfHH@sQ^^%I+esyVqRkf3$u
zk85U)M}c_In2w$>)1-0S&Ka$3>Rn-I-J5n#&eu9w9KjbpIXu}L(wL?NOj^B}+yf&D
z$oVQ+hi8)8cfyeqoSlf3Cj9*l0ljd#1o}tYab&x@4-MHrqIB}KRJC&|wg@vAc-Bk7
zIJp?chHztmMGC>ES<HrvJ?S!u#5f1X$NC#n8}3cmhJy%^TpamRN>_YJamDAwE4KCu
zZFU(0Q>QG0I7SXXGiV;HS+}1p#VJgmkWa1`gBABCY?DibNp=UI@*(O7<36#O)>Q1*
zi5B4|N?kbH5Zbt+w?swBTR}|C8@zj4w7}UB6wBTzVQUx;;^CgQHFs;0XF!&ZWzk>P
zpMnUXv!!ax9>H?9zI00D!;5?VrekENtNsyxhv>sjuOLFV#UAG&30K#4AytK*3wY|Z
zVvDq*W+(|xucowYXd?3^8)p{*duYZmz#{eNW;c<B{5l0>pLYSXq>^kYs$u5lYd}>N
z)o{!fY6vOHP*6l>`pU7^G!}SLz0wR1N0TLjv^9IZS%rgJ?`h)*dh-!r6ydz=<D2D*
zY0qL#_H4ckI<$z+4^m*WoID~#Q|6ghrE&FDAHRGH7m&Mrt3G>BG%~2otJ;r=!|_^e
z2%J;=MO-mB_eP3MxsQQ`v)VnV^au&lLH0()<;L=5qtqJoX%0c=C?WAZ#3@%mi(MU-
z4nLYIHd?~l!t&*^?<&Ayh<0sq(+X+V(1+3fj!3&Uap}^ss$r4J{uV`4)be+pv-y^n
zrajG0;uQn-+8oK_H&b=;HqGjtKm@zfUb*%ND2^a6y6E2e&DU{Uq=DhnU<h#1jwoTB
z7Az&a$7ayTKCQL)usXF|em@S!CYBB``bSin|3Ek`@KFNDe`Tn$ThBtOrqx!)^!3P{
zS7v(eUT(GlcW7!Du3j*$^5`L<4l`nIp<Oe5jkx+2me)F?;{5&ujh2d(bAozgnWbWy
zdFsgW`%ms2aEAT)>+qGA*G}P#FYL1&jt;?;6@XdZvPCdNImf`L%8=GM6o%H+u(Xc2
zx3Ti*Q3%(rLuh?7%~&+w4a0xJJt)rcD*NWD7tG%!w+Gv!bx-np7z#i=vawcv%up|y
zY;?`3J}S|%9T_v(Jv4aWn?)PTS|{AwyDRwGfFVAv3vGjGy`$7$-k5uxX2vK?TWecZ
z4q$r~Uq|xJesb$7=5+amW}!NZ>w?`pfB|V%JL1i@+@^E=_CW`@{lt~$dlTi+bv40_
zSYK-r2ZDq1G0#M^P#xQK(cbBf-FQaZ%IF$7;ICF}$ZD$qA0jUN<jhiB@bP8nzhuwO
zl<;WC%5N+nHV&$7D5w&0-zd2k3r1XEvmTvS2iOya1-sjpz?P{yoe+W@*%1eO;;>-v
z{^$_G3$Yy`uqO&^o{?^If*L8eyHa0zEOU)l%Dro0HBlgAnEdi7Zti;11!1j|86yKt
zeu7kE?|_0CaVaj>4SvDos@Oj9j<JI^m(^70e)-R!;aw9iRM8^nj2lzix7F>%Ww{Fd
z6twT-(}$30@q=jpt|!aZKB<;Iw)XW=D}{ZeTE0!G;U;~@s!L4O3A6tnTJb~dby`$?
zAMT|?({xvtgp^c9Pt|(bRYqxLvU`(n#Y$(Cc4)n<KGdiOe#9EAKBiHlfKQv6*GH{1
z_+i&d^|1jU6RuN6+s$1qRUKxB5qs>cyIp5-<fE{;%~^K`+goVeRYs;xwYTo7Lj$fl
zd#L%JtSr97a=$;=8-GS}b@H|`wcf;x72M>_J7ZUMk?~RYmW&Tu8dHY&^P45jOrePC
zO9kJ-nYV_<p)bCNJ{J!n-Byt@x`bCjq#r;f(UdJ)7pAxCxAOk>ADtTax62#Ldh^&B
zp}&2bZSwwhY9omB<Y0$9Qp<J-k%~oN3J9@f>ppJb9LE5QNSEubC7k1@EIBy6ak3j4
zqQ&sl%_d}}7sC}*Jc<EqixDnArxJ}=TFHO>lsIARGZA6Ofs<QUo={Oh7@>A22Mv2g
z+<v0E1YrUKVK1L+gq>~lRh=WkUL>N!5k@4M?md13=dT|qI3DT!3y{9dA-$0L9MYZT
z1xR!1+Q~upo)OXq8q&668v1~yEEf=vZgfcBWIt86@)H~%A#J`pg;2C50ET^G4wYD}
z!v3dkzIi&DgPW2e$Aahf2vLfb{10cC4~d*|a=c|0I3lk*CnWN!k$EC>V@>JHifTop
zwFDm?Z6lJ@TT8H!r4&>~2EG3_ML%q*_rCq#i}b_1XH8cV`<oEooR;X?J>++A!1iG)
zIC1<m^H01n%AA<9XK%$j(a^-x>3voe$5(6U*SFkg|H8A}5lSZja}hrj*N<DO`_<R;
zJ?tWuanz<RhU^={hxl5~$Z^8@Kv}*WBN!(K>v8*gm3A@a#gO=I!9iZH1`gm(INP+x
z45|%2Pb`R|>Y6czq%aRhsh(*_s5|kf)IeoB6Qo0QKBS9DpC+OZpJ|ZLjBaao6kZjh
z@XII0Dg36R@RgR3!YsX|dsA7*$OjMWcK}WfUSuWGllLE3UPH(e5Xk#6Kp=01QCYRO
z$XmK^NZ#_%=#blMtI0}7bk{iO)<uW+bdUFR@NTgYz!p)D5h$-lo;V?n_Y#NqyCS>~
zEyTM;YGiUA@2BZwL$*c>2zbB#F~j?2L%(VbKfxyAt6Z~`fj2EJyc6w{kfL}4J^g{r
zH_!-_yk<qW<HnH#QAfwP&HCr+$qpPn*OPuObhbizt8236U*(1JH{8sd7s~HY6gHm(
z)=nso7~B|dG60+$OtEQ;KnKC75~K?Vq>pf<-(o*izxgFi_IfHLeH*YYB6#Ebhanil
zMvhW<{&-QLJBBMHv-l{cCH2HZ_h}9FVR|}=we=*<?3z<Mv#h;ZKO>SoBN<%n)(p<*
z>apf9;$M2c_im<p>IE959823gOSSc(9hSB`mL4uDy)=E{-Eo%Q>sb2YM?;oA{dxgQ
z0nifskp)EG3%;~n36=^7Ed4$}Xr7ic^;5NypWsG<$52HI(AFU2Xl<v}phSt;uT|RF
zV+C||Zz?y-r&Hle+=*61Hgt5-(L4E_#P6gj%O7<0f0-I>lOA)LKKN+?0sc;r&!C)q
zfIuc#Mnh-%{FmSTWuwPyr=3U!YFe}UbfV+P;QC5Yi+V}~&#>yaCIPky=((MrJU!O|
z0eX~}eQ;Ym+2#lVZFj_4uu(N2AREX~Bp_dV->_1($nrChtFF)P1cAkDh+1C;nrr<z
zJV*!5@xk`=yDlY}M)`qS$IC$9l(-CVgoxVhxsQZ0@WiVz83<vt1iyzrUJS0>R*yxt
ziQpgxHvk84XG}LSIGSpM|CA}_;+*nq`xKG}JLGlGeu>lUc$ThFv&xGojbW{k+jY1v
znp333*#ThC4;n-)nd6G;==To8;kXat0okvG<wguwE;BObXuA{d6Mj*S#|HvZGbxem
zxojw~A9IlH(BZ7mAHc+$C3vu^JbJ+hN10#hgvthU*vNG=$xh`jR>#w}rUG-7p;YQY
zl5<LmDXuOFgUMlx;xd-wJjI+S98%0KwqjuSOx-fYxb@#W#b<9#1rfy@sQCM#vhj|R
zFbXLik*E0EK=5t+)uF&1Id#hv)2?rx;<l}+z$gwC&nQeR#^KY8MEih}fI=_8xGrd;
z)IOQMtKB&ifa@o1u;xP*ZZ!li&}8QfVk-fI)?@~)WA$*X9C`}bk(7-{&hO$;GK&X_
zPLasG^n5h2)R~~ykk;7SZ%mQrs-JhxF|b-X4j!!e^$7D%J<NE4_RzlXy!JTcWz!x?
z%%1LgoWNzykwdbtd<tr$A-hp2D25cjsHR1=J^X48f`*|X@^vmMH_CSQng*L%Ig?lD
z#6Rc;58#<+w4&pvVDSiPKZ}o9&p5;ErD<U$7=BH;`R9hYzD<Uq60<+1hvan6OVg)1
z_9N#K67|pJJjdl+LPD0UjfvcW0vY_Aaf7_qk(`Hmq|2+s?8nFp#zK_>4I>A7SBmVS
z=59E-lwcM$cgH@`GN{rU0Oqjz=}U&c66~NAYt!~KJd0vYYAmPXl=ePIZBOlGIRgHM
za`>G9XL(QU_ae|2IM7PSsw-tBGhTq&-zAqxLmvKANyycv<3oUt>YOfr<XNB0r+pm2
zrGUvz&DoXZn}_i927~Y;3OH(?__I-~gxn~X^dLzbSGb9!zlrnc?Vo=BtA>AZ;Gc>E
z7XKFpJ(}Y?C7ZA^v!=Y3Zkfng8mCA0yX0Qn#d`K$V|S>U1w++kjw-KhACY@FqdZ%?
zUf8I06m!aJ;WR{~6~lUgs=sXS489vZYHopc>f$jt6+0R2q+~K`RPq^ZfN~jS^#=R8
zj7kn6wvP&n5K-qYHwUah9fWrG^F5u_o5<Cd`fg{LG@*mtjGzg(vPNLLW{lryx%b;f
zJ5p_6YzQCf_22=*V3r;HnclpxkmOJZmqF3(o$}eW1-IiBf|+mIp8EWHNXUDFG%eCx
z&V_451yr@D@$vfOM$i-EI&)$@W%Q&KK%OB<nS7KW*w+RB=G>1deZlfpF5)EwAhf)v
z){YNOb-C*KpxCyQ8iJg);8C0C*pr`>4tC^o#-G)P3)7Z`=aD8^d-Lwh67&bR<u<wl
zev<RIM-Wt3i*v2iNA2#K6NEuDc34x@3whVd!o%Woz>CC6{C)2W=YWs@AvOo}=S^IL
z%{64!r;^P2zC}p@9D~GZePAR06#0<lN}8KBe?53|Jf8d&TlD--h~fF<#5kT8J3J>v
zcpg@WC!YV~g6FW2hTy4^;Q7jX4bQ6#-Ktf>vm(OtQ9*xW{{G$nkZ0);1*l%)P+drc
z&RezM*#eg0?>{Cup%khr399dNs0Q{^^@C?Y^~0E(#?ssbe`AWBekAvK)pHvMb7R?t
zRs3OZ7JdFIA$%K0jG}l8*U9G<9hxeU+2T1?6S+-BU0#btH`5XH>|EK0x^^fdK*O~|
zf({gO^m2~XalswfdP77;C25B>Q%z*j06?_w`xEW34rj0v?XOrD3@=+2s*|H$IGOU&
zzLUWvjrikJ(gvCL#ZVntfa*kt>W8S%p?cag1*ihxxM0UpsH!BW?&(ndlKoWuPN*Ib
zp=yEAu^VFTa#kFyeynKZLD)8etyf^e_NZs_j6Lm;IAaeZKVANYQ$uX8&lX@yV9asB
zx&K>&u__6+pQa=Les4cjYqMZ`5z5vvHVtC(9B&}6i?BIZDU3^NNl^1P>*X>3(xN#+
zpqD;3u?)JXSvfZN9BeM~U;bM`6aZil1Bwd}skdjZ_<=0&eh}AOrqfRT3?2?l_fmFh
z1Z{yqb3v>s*Wv&kYR?`Z*x4}U2USq*0xQ8hG`J*!*-EBXhM1{-i1DE~DMV+gor$es
z%^e5Z=7z!K`~y(16w?4dGeYSioRuWb{6Bx)Y|(zaP=A;l^i~|aW5IPU2vfDB{jz;z
zwdv7YZJM(NQxqNJl5;!wtb>=z%s2q&Bnhc}Sv~r)yQ*x3E30HHs|Qy$S7BxANFb(4
z;`kg-I*2PhhT4=KqSd~ASV?kzlk;c@4!#JX+A+%Zyk)=Y0P0KGWuwf~oV~)ODVx${
z^JOm}Ez@^(Z9gxVZ>ngp=BAD1xOOaD?F0ET!1gtlwZGS6Qx>HqxOKFzqB}!ZMaHCF
z-*-@43(OQfeKjLa4z<9wzl~`D&+_Dz%g6?7p)+EZ$MK<Z7450LS0Di1<nB;t3S&W<
zjJynii5YrDle<f_{k$+0|6xA${o<_}lHL~uLaOIdY|N-*R?Z>5ct{5GK>7@GJ%f(|
zscZ+m%JK0)UZZv?rh@7c*~+(?3W?NasVK@&ii%kXfuq83BtRg)Kb$ct1>!iu7MW<t
ztQY6(L<KJ^LGt$-briZkqFLP_1q``nrrYh`1Lg(G;3%9DPrL-z*p%gRo1x!lpX3*0
zv>Wr)7dH;B_|>m~!OH?x7^GeolQB0Yym?tjNsTL2x@;-G!CDsaGQHJu$+QIDL$=)0
zS}LOUjy<5J%?etE-^o2jO7;Sc%a-&Vav~_xEj|vCY&xU9645Odg>;Yo-9~(-2DUv9
z_VW&Gdv*`NQe&NciZfCjQUKL91&q8Gl&RIPNekW1JY4hUk&?ZKV&Y@7XYOH|ScS|D
z6W>ANl;yWl9OmwJVvM=pcp=8zgI;mWy@rgAxq8w+F;~xG?lOLZSuE#y=C%g!`;B96
zYcR{z-Z2hrZBa>_Yz-FTWpg~8D}Ni`vZIB!eLS8ru(`Q_%>`T`YsBWI)J6Mukwov(
zPom=>oSi*-;-7=LYgFO(&cUb8cH4>j{s2qg5~C%)L`$&Tr`(_vuut<_YNiXPX%w60
zE>R9A7yf!+6^2s@(S}@X;x$;e(GXss%tr4Vc?WrF2`=D?mbXu2e@t1p?c{6ElVRSf
zfY*Py58uW)#M=qFq<!J<>+SNQkO_8SLLpJe1aqWoT;HM}Xj6uC7>}5ji=1y={e$Nv
zF5P_Q>XOCB6i7?HgQKAl%(R1j9g2`X$Le&+qgqR{p<w@PXYw}J<BruH-Hxj8HOnbE
zrW!)w&IFCjJ6x?dN)>RSkl~@~=XH)zG;v2`Sp3*7(7*IBm;DmUzBYNQ_l5n8ckMW0
z|F-zE0ez#*B=y-pQz&;)1Veo-gmGjMjKv<tL<i$*9>&D%4}r0)l0TRTEUhU<w)^%n
znL3G%cZ8r-`y^NLY+rIx?vkh&I>HJl2PXsI-wBUkalBgLw18muE;87`_n2ujL=@C;
zgsUOpYd9jeo9&rV<&)i~-x5opw8?Lz{Yp0K8%T_{P9L_;ZJvIWMRyPgqhUFVrg=tk
zZaX_Hj{UMMpX7XIVTl>Zy2tpxVMcP+`bje~$;<j@BwyX@kn~7>31%dxO?csWJs&b5
z$8WM{zALl#h2-yEn2|jF4}4jjyy6f`eY|EY<u)d#kNc*TKjiQOrl`zgG!u}<UBuhe
z-hs@16@$Q<x?fc#*-n1s$&*K}q~=c#0Bc;0N?iVgT6$$Lenv7^bB@8vRegkC4u#m6
zC<Cgvf8&(o8Dmz0<RkoF$%p^KEZvx_-s?Zf$8Xj7_It+vY)qbUKmYF*l^c`Id(E=+
z=Bi`dchW4+fWDpNzA67Nd4B*n6K(-l-mA`czkj6iER|QYTHaT4;`^<#o$n^+xQkql
z-%)ZE{~zT)wSESc(+<t|%&>pSz1_e^ftpq;FukJ9ew){VB50gR_0{8M8Y<NjdiW*%
zIZ${WfcNqI2+#We6#t(gZCt%WdqT#3qi^ecKJrx8Jb0WiZT>CjgJAXH-{T!vH2&jz
zx$@KR;rj;C?&1G~9zKMf@eu!i%{LLXlK*_q6GaRCz(7y0`L6v|KLf~`DuG9wplQ~l
zlV&7enQ#z9A~pY;eV*-eGZuHe11zepICdoZu;MPh1ylcoTPqXePt^kV_1pS-u)ZER
zV@CKrb4<k<eC864V=B^mcqlWv;yfNCO8qky$8b#U-KcT8fAy2I)=paW<ja@w^y*%x
zl6Unhzk6Zz%a2b;>iOkECTz=ZvS$j?y!w$p{ecu@`)Q<?JT=EC&#TkN-Q)5eekv3u
zd#-d}t0q|L<9i*h-zR6iP`3KXpWUar23G&#@o{s>3$$@Zs?6m-@Y20Ho2!|x{LkmA
zF69>?KH|f?zA*j%RV!y9-6TAU?YH`cGghvCwR*4nl=s!@318rM)l<)Zcdr}#!-V5`
zfSnsG^>WL01}~2+A6WI&lgl3jK-KpqyTZTWchyt({a0RwFURXh;hpbZoojxSPs=No
zTHfZnSHB#!^I|HlS!U_eEBf`DYhJth)iduWeO$lQSUuq}SM&3$UueFMIv-i}RQ9{$
zt|Czn6K>Sk+!>Foe*BE5_+4ku>(6**_2bRIUH$m<-@)X)zGD!k-$U94@>Ol4njSx6
z-1ho?`iu&DfBKBQ{&)=UuQspZKdfoKCx)rGy0;-Xy=JU_ADOjo((3HvH5aSQ%XN3J
ze&m%2-_VCw5XLk+2~0jZ4u+DdKOb%KcnD|&x8uZ(!FAm?l0W4RT<!|xzOpd)V#IPe
zpW6@MVTm3jpKEw9Rfo*42Zf-SQn~Wv-f1w4c>M;n{=c%mRUFuu+(E02?gloxgPXBh
zYUm?mLYa}rQvc@42uWr38}R$#%&EwA*yOQ=53@8Z_O*`QZWBI2N40RI*%<%Q?^fpe
z3l0wxo||h4v+V+lRB+e2jf2@*v`cRL2%D^S&}EbSi3%NWg=T$NPQv;`M|D20W+S;{
zoqM;vE-aAf5*96Fv%k>XV9yO%;gzf6#pE{oU0$=-@h2<^ele0)29q)q2IVIJT&vB$
zKr69ql1dyzQu0<<BO7-82JgtktkU~SET0yzu1V=lg41TG@K<Pg$MhI|O^M2;j!_QP
zT($AUP;agnO`l@&C5!g&Ir(Y?|6Sut$HKcMx#GE<#BV)Ab@P6#D306k+H<eX?@#t<
z_lBr!;s)`<)*W_VaOz{2Y-DR%Sf&jaCP?*Ss|iv)5Axa<t@Q12RNi0r&9QNRoi=o0
zqr8g@ZjIsjM`HduTj@I{xcOHly!I-I<DpWZ`)dBpeyV=hfWo>5_k-Q1m7CyE-v!T`
z(H1QFd4zthDoUMAD#rzOzqw=mhwa|sDsf$KK5LcYTK&SZ;73sCo~LkSLCpLe0>{eh
zghuPRX%1i-_pr($qP>~&;8-mw^hxsKS6wr6NCp4HY@f#2cA2$|ZCXo9qK~TVu!~{!
zQhQXUJj^k|5UJn7nTH`g(FGYyS8CPbnp32Lj~7%*P@B4vYUSiGo>Scedn0ElmwB)M
ziDS5J@MWekhD5{gJtUG}CPwV-d$x`SbO#8Ygae0~(sbnfbYciUhcCZg@q1fQ9%2lL
z?OYG1GYvZOAfp*gIyeGEW{C4dC8k_dVhZ;uFC>Z!O}TAy<@^#ku*G8=E#9LT=>~`v
zSJS}*p5Je}su@-Rf4y4pY|Yp3+*7WRO4YEPrjJdzZF6>f*4B{o;1=k4FK*4higm?=
z)JXzS^8D1V4@_7Ff<2*W7$MoJ@;Ar}SX#&;v81C1pV7cmm@g6-`b|pxhV^k5o<Czn
zf^DQ~)Ng{GJ325GT#Z_?EExL<vao+uS?0vD{9Bl%++`_uS(tZ4P~ID6k#7PhBfO->
zvK$m<skSU#9I2y<c8X=G46~#hlrop)xhL}#{r10kRtMj*WDn_@B@;q<^ymA*iWyUu
zC93Vb2kQavLun*$TkAB+daMzjrP6J@5DnwwS(fIrl&=uS49a%#EPeSbBUXrGmgRTM
z?4pW38D;58tPsa6%RTWdCq-EjWh+u)mL>5lwPaBjdh6KrU?g9(a*J!9?>wPe`lWXn
z#R&~c>5$w6D7EinPida2?Wu*QopZZ!i_X|(2_!C8y-ePw+;+<nh;q&i5u4G@4?Y;S
z*9sLdrhNa`w%kxqH!ywORO0I<f4*)|Qr+OFx<PAe>Xrb7^$+P@`6l=cgKyZq-pO;+
zz48sYGL~hVFpGpGFAm>`WqEq7hazFg3)LmDEd5~?2}@pjn`2qN9%e}?i~76q@9<cb
zi^=kqcCXU>G6ZNNhrn2DjF4Zaq7IB-Mn;6=i!7yuS?a<ph0J&)mZc)hQpnPqV_BX;
zsaQoqBi}H+u`G9mS%gNud0S&yz9!Z5miDjkxEi2V(>#^3l;hUQmcHk$hU8sL<dS!B
z{^ou$2wN&&{C)Hm>M#CYs{YYM^*b963M-+ox;HVJ;CV=Or(RXYsinU~QK(y&-|Dvt
zM1QpbPTsYh(6ncN`a)4H`Jv&B))(r7DK;C(Yo*3}oK~8$Y*$Io@u9Gfcj>iQ3Mq)L
z4L<*%jrGGRJrBRG5KevYCzNi{&~HQxhtF3TTcx23;iQAhU3wm$!3W+HKG~m^#s?F+
zA$jw3h^6uwEBYBJ27>lq3|mJ*e#f?f-~^WDhZ*ss@ko`_Qc10-RAu9iXA_BDT&)_Y
zUt?m)NCn?h5{NJ-zjeu*bqf5Jt%{JpL#pfEU?X6@r5CfV{>E#{(_`jQ73#^*v$wgM
z97S&2-QmynmT$Vo`>l<~BU^RUJU%##ge}k%(nJ1qaNT_dK!wx6zErK%oLb)Mf*z{Y
zn}oJ5xR<K+wy&loDWS7(aNa7WC8X`Iv|6R@AAFFs%_9)XH(=|756KuD2nIHD5O>6%
z87tC>8Osx0!Jp_+*iDWnyCcqq=CVW==*th)!2r*O*4)Hg{S4VBX(cdr<o3z!9Rax!
zAW?2cja>Ow8U!K#R;Ui++uoR{Vw4#?fNI~xo~W^X4|^hG`>wgYFrd0-EKlRor*4dq
zG%7;I2zYO0-7$MaO;#UVPH3<ln^Ye(3>fFbWv@uVh5QaR6_bcZOXqY&)E|Q*Ip<FO
z_G2trco|3qHDP6`;DI&6Hgi~?;deawJbwQ!A5Y=b#VWM=UgF|9<bdNq^3{zD%cg=4
zyRs!!W<h;>gRk)Zxw{B&2s5a$Apd8`PrbY9Sicgu3BmmS3^`2*(kW-AtZOA?jl6JU
z2F*i^#h6-u2c|6V>dm=43gNM6jN}vpj656}xR?p{`U$L~8R}M;XN$DD;9@ObyW2vj
zaWhVqsSxb;cjRk^kk(9Z#q(L*T!*a^Xmj=2@yYlf{nn3;B$03@>`8zj@h1zQR*tXE
zL<id@D>kz4P~|!m*n|MfsJ9@LHh#$%2D}jX)UTr!vmeD8S9qG>aAMLniqXRZu%B~h
z>}T$b{n%tVUVe@7@)EuxKya71R2^?N!Jd7vDQTpTy00Gg9oI!(ARZ+Q+Y;?#ELF^F
zTgcgF<iG_m3Jbo-si<(I`t049dk)M7z#QApAHyv*B6o^Qe@^KeqV$oui7tJU()H2h
zFVAr}v5)QQb^A$zBM2DIw)h%SV7!kNRa|Up1v}{z2R+hzznSmrpX$AT@V@;tNY&*y
zIMnf~*G7ZzEqQCY92f|U=j5&FZ9<r-?oA`+7(aL_pS!E-*@qzTIosQl)ku)wP!z8s
zIyZX<4QTmvYkU`Y&8l**w7p)%{RVNg)1NvOW;-|5Ms@^NXS|IL2D@4TsvXx46bqzi
zABsY?P&gVC)SFgr*ha|Kc0YOiXvdAq9V$n8%--W(4|1>6a7f4xb&Z9U`V5O)3(QzJ
zrCbT*i4wL6rBZwSQPFjY#}bJPM(JsgCHUFyX|Osmdnl?O$27@)o^ps&rpx_K)$qc5
zllp<x-W`m{T+`dwBmaHfEKZm%5{tcolAG$qb+lO6=5P-wQRh-XeI22zK-TgCgM|^!
zmr0V`aEI?e(6j+%K>20`Wo_&1%hp1(+H~#zkAF()KeyWDP9{kQC$JQd>62p_)>^pI
z4RBkbj!XEBA_|e8#k>a-?{(_f0)EoLM;Xo4fc0Cq7*i4-i?^yc>o<`;Zi(c;1tu}9
zc$J#$>7k$KbC-|<V{_!E^h8*(JIK0x)))~)d_O|UW?w^3&)UDdgmNP88kOe@=A2EN
zGQrPoca&ilt1IZNb+7pmE>@~4mAx+ebwfZEBi)&f5jk_qv;EMm9nNAUPq<KDDtjZ9
z<aXAE9Y#r<%o5Z3pcT8*>PXDCv+MarvO8rnd1o4rZO7ixu6Bn#8HmhothAA^K6jd7
z9)?lF9(9%3MyY3otJ0r&?T?)dHzyc2QH{pLtj4K0y?}w<Q2Qyf0m*(7ifl`F6nr@>
zQ~PwI_gp`E+rnPMV8?dCydn3I+;}0~keF>NDV&DdSbjQm@1oCX@q<nNp4@Z}26_FP
z&Ywj}E-5;HZeS|g&OjTLZjml{6&nikp!1(d7r6C<;$4BR!%Dm*wTbr8dR(H%3l+OR
z_8s}Pz^h($-NJ2+I+`pj<;^C8TMPW{kMnDR8WNU~A$X5(BjYH465Nwh)_#U(rrt)h
zpBldT@Ic!%@Qql-yBAbE#Z~<JUSY*E;}wJbQZgjkSvhmN{52H0{;2wW9m)CESz`Vg
z$`%psiYCLNlHX>+p!+JW*LD!SDKyY2F~WD%`<n5lL9MtK^f6VCG6=PW$3n^tu|w>U
z%S`#)?TCn<M_12rwSni;RZE?Mh_2E6cZkaBsIQPYW)^48zi$M<D=iqnoskhDbnGCt
zTy}hks@J$9Ai}EZd{u3c(c2cx#|M)Aqvwc7Q4prc<c<m0A_8KxtTCe$B5o&{F?6av
zhj?cC*n}jvQG>d1y*^R%5`IXdw>efRLo8ZSRdGmBW=!x?{HCzbZC`44S5veT_gDf6
zMNLEu{J{4e13M$CIs^H$b9<C1OJi{A1`C*f|5g6C&vGa^9{TQ1%d~3tz+B~oUqxeM
zr&#6GfJ~zd(&qvNGCatFR1cVn40BtEl*1?Kf=bfHp4l%U0z5nA@GSXJ4rlBh_R)bK
z<duU1z%@C3m&TWGa!uE=!VZO^aaw{Ge@U9}z^)1qN(qfA%LSZRg4cGV_P&}LA<<X$
z>ph7jxant<@|VQk#MB_F;@(?b6+ZALQUe_flKw0Z;jZz<b?#v-l!yB1Cm#fIDB6<o
z2B9T5VqFyP97=3*zD{wWt7}T+MxT)b8GNWzh~2Lt$&WMXI4<-Qf1rvGvwTENS58@0
zp-TFq`_A^~DmNHfpP0LSNck;NE#rV(&wjsaH2k$O{Oue=K*xn=b@Ebn211ZKBlc-n
z+#LFT)c3jks2_e>BGe*-z~113emM@OlIp~*CcTOt+JY!1ZZE^SSwfn#tZeUnQ;u^N
zJaEWw+Iq%d2{mQ<WC>N_`id9>tEDZn-M((_E^^?pu?~0Chgg*7&dTj;NkkS;?PLBR
zJ5>lunxqMXZ!zT#*&8M%?<_Ba%e0i213&EKTU|`g?Veritsy5YxCg!U=jVXf7T>%J
zVg0|XnYK>nm9|%$gJtn!k<!96H|L2NE?qQFqJ2l7Bqe5@)1sXk5I{9s0}?fvGHmyk
z68rJkyb}9?cfL3!_8s!0V6LtSmDorWRc!M&0M1hLt0jYVH#iNGj+9tBI7HsHP#&nY
zPV%23H%d&vQDR2|oI0Kp5`9(g<R=Io_5o4Zo5({6o1*etFA?^n9aji9)>%@h2{#|l
z>xzu)60iKPc>yQowx+ZuGF>2`$pse-s7tNz<%I*zpsGl1&}qxyEVC8OW)R_DYQEF`
z_MPpqH4;>E{Of)e<IIi=)wV>f3Fwu0Imt>&5@NEF;z6>KqSbUM!g#L73La$;ar^v(
zX*Y&#bUzsdqJ_nAX|+~O-I|l#Qu<~dG8YzCg74alAv$kEftaqYS{_uFmRst9M9}5f
z;1l_}g71a_a!6ZP!3Dy%C?u4Rb-?gvc8m?i8H{~_9$Y6FddltPV(oSjZmnwD7Kh#;
z80r?$m3h0SG&b|dFDl|H&DiKEsa9x3vsN4GU30`-GnEiJ$p$@CsYzIi8IOoLGHC~V
zd7a-7?7dzcPUC9#mV*OJ>z6_YMvq)Recpj#L-JCXXm*Zuv&|X{$KWeBlIT3?;PXGk
zV=n@?R<oCs-$L|$s};r&y)9cW&(ME`yZ5iWj!h<RZ6!*>;Ik`&EPu};J6j?6fGv97
z?)p-@&7{<=GJX<*Jz!GXVd~nv#_cJYotElmpO$I|Ol(nkXLiaf?-#KPtz|42VU{ZG
ztND2{RNg0EU#z?@iIA@OPdI@;b_tE^^|za{1T%^I$@JyVjfksoRe=g`rwVGiL#Xss
z-MS+xd>pHVh;5VEvms}$WZnh0o3g)RDJvowuahJSWh)M_n_XYTfx-4qXE<=f9*GWb
zZwWt?%|0!dX9!yl?y)S2h(__WVnk7g9c9#(Lm}nA((YI?t{NQ4>i=yk{$h0x1Y_iC
zqhcE)O&6v?!Re<o57JL*AT*+%ID1Cp=BIYZv;LwSc=Oqfn-^0QhD_f+Wc>r*E?_+X
z@~r>rwT|`bNfGPy5<JgLa5&bh3RwSgm9hR^@Eq1ZUJdJSWC{-Jrxmb%CnkqbFfGd&
z;>PQYP^7`FH-}8Z0u<G=O=!h;k<{r-QGKx2I7Zgv1VYU0l$j|0$s|x)2A6CMyPLH7
zpgTr1*6?4YWY{9{hEMi%=}WxvFZh4#eG7bCM|Jm=E!#@sM9K@C5XiM-C(6T)@*o(;
zcBI&H)?hm#wi6Q+q_woNgr!|&AAW>{ILOers;POWC4kFEA#EvNXelIV0lV-8(*j=t
zw4^Pi4$!hje8dnQZVB=C|IeAZckbQ0+FePOoMi9*_TD?MGc)I$IdkUB<NCzklHaXS
zrec}Glm60SXYkD*-F2ge_XE_(*#Sl{mPd;h#LHuc-(i^JHI8E+6$(89NbJnC#o|{V
zR|EA;Uc663I|3dy9r>L?0_BPvg$0?e+jsr$zf@tGE5Wc$_3s?gUSa+(g@$|fOS!0$
z+x63$y`Vt_0u9vB3eZ4LLjctzB%X(cUsDk`2xeiGP$KV)IxPM+1p-)y!{UxSvhZ5Q
zAF`@gKYyBO8K3!Bpk-iO4OL4^(p?{s`W--akFoD2>gmXT_ZtY=8!eQW1zN^`oT^$z
zqmoUhx8RZA_kUE&Xjh<2Cjb2xifHX4$_UqFcvnoJk2fDz;)nuVsW-coSdR_UW{Xox
zu>}DEsF5!5rvz9hx;XX<CrXhhNBOJ9DZqeQ?{ORUBkd>6hG(q#N3aMdsfFv=hf_~|
zH@X7a6e-u1sm<Q6pa!PK9xB4)&?V8%uRZc1#6XY?OZL+2X;0t7L(NohZUI4T14?Bg
zTr)B;$8~UUamNv*EiHzu#Hm_Tx|?cp3mzfs@f4T(FYc~oV+I_xDY`AcT*|R@<Yg#C
zvtPc8#lM-ntXeq6BWq~$yzeXf0bsNx1O+%7%_CAD!Ws{h#zj6rF_#$JiVE!GYg>L8
zuS5e~oAP(S1vI))RU?;Q$odGFNnwHg>5K9E=HZzLAft|`Y0w4{<(L!O6T=IF3Zw}~
z0mMxsgZaJlFZ>aRJml|B4~Ku_i;>|mrf-8WYS{aPNXt<)4P{CiK5O`_qF)iYz@$|4
zjSat{4y8B_J%6NcWQz`q)#X3`0P+Rlo7CAZjN6ny2WpD<Nt}8A4Q@dMb{LC(An&3|
ztso!mJ+}tZTqap|J?M8BYUf}%Bb{h2*687uoaX#nIrTbp?6^AL=?lme?XS5eH_x1P
zK>h0SXNZ+rtozt?h%xvjmE1LqI4u})njdkO7x7fI3pLbL18g<?<)r(3uDVb&`&dbG
zi8_5L|1<Pd3LjGE|DY44Y>ZuhD2Gj0BV0MxoIj+z4;?@E6@SK)sj>{2dHme}`~+rd
zinXa|Oho%?{NNLK6pT&z9b_LEUYj6SSgrgMFaoIdtb+eH^dT@3+jI1+pjsuQfZq30
zC6{oJ*nYrKpYFlO#l`fTe*$n=`51LAN|3*Kgw@xfTR$M7Z5}VRDMTn<IC9f8btDd<
zI(MH3+x{=6^9(S$%ljT!{#QOHejE!nSP<dF*8m1MaXUUXCRF(~TAO7I!}q}M^-4Kg
z*I|>?VN?F+pSSAp$@fbgI=wn{=4%x(eT%m}&SKV3X`Y*@RGI`z0A^f{lIFhvGn3SO
zEv2c{)O-i%?w?NQNj$84(H2amRAU~o5F#pNa>zos!a~X)e&0sQV#EhhHlt*Ml&8_u
zEu_Fgc(;d?-$2(RKD{Zv@4-Ifg}&!~5<2K1Wl*ihr2fg_kZKQ>{g7D$DL<Z}kkY1b
zbNV0s5=eOnmK=qYk?U#0Q;GL#3-(^ky1OuIK#2UL_kKXaYqK)+sh0J2t{T1XD`e6F
zsT<u^PDbBw`+ejwVAyWI8!=!Zf5%k&eFnpcGTSdYd4;FPfJFjOj=Le5k-pim-|w&n
z5M4-fkoO*6*|3<h)m6v-%HBXX|5k8<kgSY-I|kQ*Rfmmg7YYT&;(R*T4@SgCIaTlK
zb+u7smi|>m^{3FSZrJL7DIPoi9_aOZU#{<z{u!$+FxQ(uANWyo*!jCrzJ2s;%;(W;
z^^BP!gPY$0Nm2i~1L#?%joc<F-$grSa|5^$jg6r0VZ-@qbEEIGRr%1Zquef0>U^J=
zf-;ACq7>s}5Z~;i!T12Gm5%1IcO9m_=*5YTr!avJtCuN2Q~s;UquDD`Q~qz@V^ypv
z|8eD^$|ykIt2{37fxKOLxW31o@UU@#B|tRm*@Q3*P~vIP8xwOw2hO?XYrkia+oR_k
zBF$A)t5qv(TvN?qxQB{<P1)e57h{hH{tIGj=m4}kjt#nI?4lcFh+(jBFi&47WDLSv
zlbq}bE5d;~<rd9K84q?}rx*y4^htD!^AEfq)dvL@=NAGsij}f&5Rba|7>{WqpAxUP
z(YT>vUkv^b#>09KCjS!T^~gJz*`R7ynnMPUJPGWh-*7L*69=k1hy8Q%_4mg%!ADe>
zWy*B$1R-t8pZx)3g4NKsa*YCNiNSM?ggk?>3Uff^FzA^!@)mInJ6~-UE>K~L98Im)
z9C&PhJ=@En{8bQLI%)$UHRu0?{fBzHgB&4#v>=%BH=FX0oO9$;Y7UZzu<xdBs-g@{
z_H2#e2k7r?FCTn2OL8dxS4376`<nQeC{>MCRou-dX$De0y0I10{Y-kFf5GEqD2PJb
z>Q7f9v2M6#_=)<*eu4>TiZ9-d)_>;A+)oxbu38Fx3O*kIrgKJS;RR1Dl^K=oy;f)P
z*Y*A6KB@1<KP*{aFk7Rn)*z)ni#$<k*`=Ag==izMeyG+NIyN&mC;#Y&e{nqjBZRZu
z&H3NgF;P9Yv|NiE&k{2P)({&$B`_`<KE({o7z}ZM;22^depF`yESUPMbwMtQhEjr%
zYlbCR^U7hY1)vX`^6=>kzd9YK&K`fTs5WmVkeUdJDAG?CHeN@~0r2H9{F|XKKK{FD
z0Qb-za~ao+Cm*NyDKSN)hL%IiK90E0=Vs*hqT`4SEqgzl$JHoghS(;eSXI$nr|)J0
z94a-m>~=!Jtm*LSZ=m0~T~fEkBKT6{V}BDJrpwl#Rd;ep0*tPD&dbfWs<wP6{|)T8
z7`0BNzDKbl>U$J_3&RPeG4#ayfk_D6wtMP9Bz(!;7?)3@Q#+`jHY1)|=|L4$y(kI+
z0u@RCLj&;FcBm6o3EIpzLuZ01ow8{OjW%N!OU>&+fhKe|U5|j;vKzx?n{9CBe09e6
ze?soS`7&(F*L<!1W5jDi%O0m?&nA2UDpuFBr)~BlwFu+^fy1-0A+8qNKd-NypIeCN
zHBZD2{=ki$_C##>?|m5(8#+7_!?~H5zMOFnG9c{X8Qbx;XGRWpOt7lP0*lmRXsW1O
z)0>J=-xC`}UxsJQ14utP)vcjrr@#-h*`P_?o*6Z84A1y2G*LgA2Tz@!fRl01xb;y*
z&}(6V_=;W-f#rFxK>7K}t2P{ygU(qUmeZX7A(2u{%6i~&egqDxcviv3opMCrZ;F8b
ztb&g_*eB2RRpr8uD8J*wKR>ek7nNIn$h9aWfjwu`f6n8nUd_#HCeZBLYO=HWn3hc(
z`66-x(xmMuByVB^AzRenc0hUXuq2tSQO+g`GFs^Ibjf`!YGA2W5@0aP78D!SbCVlB
z3kBuPLHM2Jz@Mw(Qx(-GR)WZ#VferN>t7uApp$WXxwNC^LyB>uZ5%%JD}O7-FD{qJ
z0J-2tkDdX3shFN2rX)RY_-tu<Za)IsoDyi%^Bf}_a0a2KFxkA;rm*7s#VULkQYdF7
z6#mt_K;c0O)lMWYmZMGcqB)jH^C9Hu)yJdx=`y06c$(W>0{+M5X0O-NqsL9;Oj4h!
z!65md5j+XYg*2C7>ygI9-b95qW0SPB7tS2y_h1A{#n{ci?Y%s^CU**Wx-<U;%vvds
z%@8`9A_S#fNbB9V=g}U3W<7NHLKakB>tK<*jAf3+7VJXqJdpc*85=wgjSm6t(Ba=O
zzS{R7iE3#B)rokh2NS*gQHp{5*Sti(WulP*NdXhAp8^pj1sit$gI<c~Rf_8+#WbWq
zuc!*f-BnDX%iMt1Qy=9(JAb>E_;-Gt7{0(HMKmTo_fePeFZ1F*!}wz1I2DXLAEA1k
z6U83#<rr~s`DnH<KKg5veskYX^T-tKyW?TqzGc=_F~+02E=0*Qe+;fbnVYGVu*ar@
z9iF<Q--^*N)(oNBfWZ7rs9Rv2?Ru5QwA^cuY(Fv?I#dHCh;PQ@@Y6$wrfEOLr<~yi
zV`}ARFF_+O*b8>cyecurgY}OA2+wq8hSc<+zmie^2>MX|wojQc>}@DQ9b!1ywWJBg
zcNj;ia-*Y0x!F#3tCa}K>B9M-%7>cPQI_+4^XDKvG9;M%-Po%;a?!|a<Ni~uXw(ge
zgNfHe1_*R^Ku;h&dxK{=?3|i|%15Pl>eI#OJ)~!247o{dNIZ21*1!g|%4uqI|1zkZ
z^{CB{=k7<{qo}P(t;8ou4O#4yT9KzTsbK&isXvS*9{GM4sKkEpW{=bxo~^$fg~VMJ
znc(GpdQx7q6Ieiq55>-{Z~WIH)P5Iim%pgL{eVsJzy5?p@mT(iA5?vT!ii7u8pzHm
zp|}}8&N1gl)}di@=y}>9y`0`<J8)xrYUhJdc>^Nq6wgBUENYiBQbl(-a|omUvHZ)}
z8u<=zASrJESF2d1HVT|cugwBXx?mSr1w!(a;oA8_hZ+D$`BJodzIC22#JA^L>-j=N
zd%n{=Ur1lix5o1Y)4}&t<c12I?Rj^qVOK4La;+RGRqMDA8<$~QZmrXdw{z4RqGjie
zT#nR8IdYLeIfd^pmv<I*<TSjW&Lg7?_~u;-d>z2oHD~7mRGkB_?0mj45MNHzz~)%M
z&hvpe&U6B+9nE@Zs5JIx1bv1M-vE5=90sY>Y-Wg1Lx<TR3-Jt@h7Q+xeuhXxhuJeq
zJVT<P!>;FN2sCt<ov%%v@l=_^sr+ZqWcQ%>`LA>Og1XJQ%1#l{!_t(XanJ}ECr2@U
zl3K=)H)n2RHxM6_Vmx_NA31SnR4SGS9lpz6Rh6V}7?Q&8>m%{6R1V>;S>ypl31V1d
ziR>qyB!%`o)$_FQd79@*ok+)=tvwewP<4E7L(Bz=kI|~_rh!JJn+9sBn+DjuuxXqD
z;HGJu&Ua}VXhwdn;B3es)h4ioT^(RT<!oB^Jnc6<d;Z8gAmDV>i~!_ZIED^26P~U_
zJ;9BKQ*5dhf4Atp7=>%T5MQazT@1{`j^{4)4jw{vNRasp4q)x*vR$vj5e?Hu&W2CS
z<B#V28&E}y^3i#cUxHxQ;1H)<<;0K(1<@)W2L-)2_4YT<fu>xH>T*&TMMDQW<EICZ
zIo@U7`YkNV-g7&=dF$m^mT9JF6_^XB*O5rQ`2-f#;$<b6cV&K&%<WyvDDddy>0x;G
z{^m)voog?`*%Imq1uFj6!YZ~nH<NE8eTcI-e<o~kfYem~#TncFYC0K@aGHh=H{<nE
zL}|*8{2qpO7d$>=Bf=dC{1TI>z;7aO-^e*(@6W?qg}+;l^{HU65>0}DuW$eL7wPk4
z77UBHYaz#Nu#bFK@Z8Csw=>^|wjy&TDXzxfq~`NPWx;N1@AHzwe~Mjm+$%b=N}}Cq
z(q&<c#})+f{Vja4DdWA2_)4`SU=4EVrR}4Wn{2s;>hirnTXrNZDRvq-IqZ!0vbzA;
zjkH;S-vfxits8^N4dbJK#*DzHFH%E$U=CmV0~rrsjHEY5H04)wB4y|+%@ekEjEGm`
zN3|%Ab*)=){2~}|QG|x+HIbtuU;hC@T+A0`E1QZi=RM6~cJ4Bs%yIX*@_zi^9OvH3
zpncstztX__o&^s}M=FNr;{!}5Ko=axCkhW9K6M6<|JVZ&h?+MJ&z_I-0}A!I!u=)Q
z(w#40j7Q@+wu^{HUjO;`DSI{*{axUW{56mYN@!63Zp!~)7o0>h^4Sqdjjw-w<^AYx
zS7Q0nocqzU!a)OPj7yn1F=S}qOD|q{7*CTN#?yqx0tb>@#h0rf3}#(@;K;XGfc+UI
zd}Q;EI`{Kh4o0*65XIM0VaztGH}*swBXONg_5zcQI>BTUAfAdoIJBgNaTbrH_-I3k
z7$fwdQ3fp?QOCcujjX!*z{ri>;<P`V=8M*M|E(=rAEXwr_uSp**XY$RKg{`}_38sa
zU91S|0&=HZhtVGt_ltG~RU53~jNB%EN;88W@aBxH5I?2C!4GA1My?b;DhT9u;L;g+
zh4@jEpkFQh%+%g+CA}_&8?ayDzCn&{SLMA=zDGMe<NF`=2BZ%o3o|N<?UgT&f)6>Q
z&cEU9$}+VUe7Xznp~KH(RLQs4-re$vQV23Nj66(FN;O&x(3X|OKn=?Q@~BF|VS6|A
zLJj=O?@&C}ls^lWFcH%$AlsW9Y_La$DiOhB$RwGm5tLhh+rPo*ee;<kYzE8=VyY>>
z2P5f`i$`chYsznj!!x%LQvUos+I%b~7}@Mio57cMqjBB$l|zU$k^B+nqtWTH?jr^C
zpxK4=VCfCY4nh#1$qX8LC?n4<Mlb|=T8upO3*v2%B=c}e$6>@NN;1ivB>N0{8<T$n
za0QZJc@0FEkZiS(>_(DICGtqd%!Fhp$%BerA_?~drr15geGv|iaD<nSL(NcCQH4iI
z9%i{gxS2zfLO4xG)85f2kw0vR!?p7<>j>?5>HJsT(-iAM<J@`xs{l^l{QNX7wQ^s3
zP7O|Z@%>*1e@O9~I-EiH_iA(FoKYCgUyrO??)}IWINpbcn0DuTE=rn(B*1<I78rP6
zc^3!>9a#*#^N%cmQ1OydAX!O`nfH7#^ZsC`NlG*C{3D#r^O8bt)$e``(#_A=0q7XL
z{};SvUDHPa!ivy|2mlqM78i4}i};Q5nBzim+x=x0UOAi5tMte#;@9sc9~|L46#+c}
z2lxRWce--MkB?7twl%;tgJUPfY@0^TrTbjC>u;O!&xj!2R#MDZ!_NtvFk&FS--GyV
zleAMH{t#|J-0gV>Aa*K<+-7Tet1_<eApVI-+A9$66o^-Q-d0ld)`U0$V`{L<zXTUa
zm2WZW1_j)W0`7;1psGA*CB<X~!3i7C06+i8tI!8|v_yYXzk4=&P<ZWUEf#2NeEsfU
z0rBXg)xK{p0Y}Q*a-+UxZe@fjFPhPYBHT5ze)k7SGFXhE{rZ*2|9CqaG_8UtPTN9f
zrc#GF$XonP>`}dEE@+{|{u^h^GIeP*SslT5yE$74>Lbp!2;~7l)mO@?OD-BZT+e;H
zi^OrLK{=oT&2{)$0taJS=ptywxHJFh81CKE1;0iyz|@0Fv6R@Ws2?($KxzoYe5iq8
zPv!xM)w)8`&!#7gUl$s072%4JJ%HQnWY3nGf~yu`J&1=BW)7{4yRQ+68rwX{WS+B<
zC+5w?9U0eu4y(WEo|k`1@)yT#J??bK8T8At;Y}@Y(5(i(<O8+7SdmUu&`h&D3yld0
zAt^Y`;>#BjTS3vB(Ezf-OHa0Z!Ar%-mid4<-%)zsO7M|nwGu=l^Q}ZjOF1@*+za=c
zRd+N7Kt_A1#2m#+F1}tTB-Tb}XuU-`8UK44ft9<Q-EAV>$U*9$P!L{Ebwanp0C**w
zog9sBk`d~C?1oD#*G2N<{Iq+z;~ZcvonLK62O@dnz0P`{&36_=tee~f=HhflNjBVE
ziy06Wr*ltBt;C`RtzuySZ^cp{*Ysmi_g1mq9f(yMgvCx$#d=pDR$VX_dtns|U9^>B
zgNel&_Hv=>f?cQ!8xW;eBP*ubBPVHCMK=F~houO^tLuiIe&#e-do&c}X`q<CnozFr
zpj@G$Py!u1JY6MIP<~ScigekkEQ;`|EZlF*vcO0LD1tNv<+nwkfL5kPs-y5F44_;K
zC{G^ti}Jf7K(t(8g%*1iQlm!zSqvaPi05q(`6HO`rCQNU?7%{Vm_RS~8PitNJR6f8
z8hvU%IwRDEA{bhF5$Zw_3`=+s8bT2aXL%9aPz1xEDuOVA(+RYp+(sSR?5RWe7P+Si
zxt=P7xeN5AtQ4mFgtmKX@DViab@(}G|5DSMkxOh}op;TMI<t|<4?m|PBJGX^$FY+4
z;Ncm9-&5{;`a<XV<35IKFyRNLhE{f$Mk&6>WUAwOUWcF7SQam1&A=R04Q8vFK?6mO
zPCsp@=jEjpFQ#QjVbZpZyv@rdGH0*iEy2to7Hc3XOJ(jS59V)@x8<M3_))ERY>_p3
z--5JpkDr^n6H7RyUUdiawctE3-nsNq6owUg7Ln4+HP&9V=@HRzTx2-fw1{Xp`7#*o
z$$UgCoHQGZ6%hw)XvYCZ(C)0e?-YCSn(XWOn3lbSkLh5(q*t*8$3F`D;OUBiH5_40
zVQdu&#Rtb8N+u)Mgpwi<T8a)-hhbVNwZF%9u*=G-HKynUQ?y``9BK^GS^gkaOB>Z2
zbVn0wjE?SttG?sFKoNaF=^yNT$S!5+A2qa<mexP?_?<H(&ERvjCa5Oc0M2%6-Zqzy
z>2IqanUjCp0CvGRb5Vkk)ADyJ$2=BiC}IxNu0Hs#(B6iv(q!fQm!3gmL9UG)_BJ}%
zJ1GiS3Oon#Y{D~(C+B5$;K@?njptIZ_b%j)*Jix#me-Y@frKJ5-@FY7*vrY*SEINv
z56MEZEX-?4DQt#uWqvTp=}5wsl)qUbX`|kFnhodA@}Ie1*@svy7qi(Ywwpf)8zS8y
z3<kB%{B}vHZ0e#|>Ti#tn44m1nrpr{%|-b07u>rGhx()1?5CI$rnesWpf|mR{LS>1
zo1YEDaC&Py!l~9Ekkeb-D(B{(={M6`0q>{a&3ww>Et?O_yO|$ZoPQ7oEM`WIrs{D6
zbCqQxUKzF`vk-y|ApKPMeS-!iRZ#flYw?uU_oRn@T37$+3+4~kvPN}ZW_#ebQR=?T
zS<kvh4`8BxuII;5{9`|x=48&{+aq|}cIq!;^$QQ-cA53npHLw!C+A1eCNPzRk~ebv
zecghi_d?4!R{H=Duz2t8x@j0~4?m%Jv?;&g4uyeY+Ye-Z$^#fvsoGe$AO1fW8|LI*
zW|lB>MXQT;;T(AmH)edR$`}@ocN~BZ5Vqmq;n`>>r=c;n!Myb6@MR*7{*7s&O_>(N
zcF*Dee8geW`5>99&8=!6l4DEV@Z@3mZopgH0>s({4S>54HgHvz_E$05;OQPe1V4A=
z@1$VQ9G7pg+$wV64CRZiQCTf+y#`-6=TflzYudHRq-o?b&vTyV=~t52UHCkhoSBf}
zD1Y2Nb%NwEva&_h;;$ZQ)LhxchSoiMu=?jqwewY>j05E;7?lS2#T(6@iPWIr#S7|p
z0sYvcdGP7l(+<*#GZR%(tXu#|%2)&*_z_rXoS|?O06u%Z2b*6cR*YL%Ob-E4U+Cx<
znI642cLoSp=j8N9Q`@!wao=Cf_~6KqmGjS7a18BW8E=RWS~(+ESpIAzx${uS*#{4w
z4ld=P!*wtNsRiErfJ}MDlYo3}BrCv1-He$POpo|Si#KR<HpB4|$>wty4kPx;8nqd+
zZscXd+RV)uXvzl~*^kwk_%mNyJ3n)k3d1;yXMQbCE556v6R_&0x6}<EPyrce!bl41
z_g^UMchRQq;n;pL@)VnmW*l7!S%G3SsoLa!GpM>fp181?St##LbMz~PF02)}aboCR
zc9uvgr?fk2>lEzY>~fpu>(;BLBwZ>YY830@MRgh@%z>J~Sd>dseocx!;9a1${`1bV
zwYOtnMbPW$BSe}#-=~p6cHMo8+gf$JixnQthE+AJ0_~h-r-8>5pi+CmY`mIxDIW=h
zDU2(RV5(wIoy}=%PgWfiE@Am0=45bD|JWShNwEC69l$bzu#q%!F&8oo^Ctmr#7sr8
z6#jaUK*|`i>5UCHFV+l!OkrZ-OpM}maB{7pH`i?}CL<s+*M{5+=_z#gWMv!eNQZmS
z=1xasC<7GVTt}rG)9653gmLpie<g@z2)kp0>gOAS#vIgV9P`eB{<~q#o^$4}*@NDC
z?KS_l26pv1Yc79cZT*ekPOKTeU;&IL&f4q0oq1VL%Y8p^j;`JNA?N7v<1LR*r*H1)
znqj0JMp_i8!6vL>fY7rvzK0Gd%wiRTYH}WC7raRmUwzX?NrQ1>_Q8$g$E?S@k3rD^
z<;ic~-4x`v;|pFDuXT<uaMgXDy3beli`BhR-7i!3E7X0Fx;Lr&)#`q&x?iX6i`9LJ
zx-V7t<?7z7?l-FYN_AhQ?lE<Low~14_jT&trtY_>`v!HtRoyqK`|ax9uI_JE_fB=+
ztnS_F-lOil>i!mW?^pMvx(}**THUkizD?bCsQX>&ez&^6P2G2?``guhx4OSm-S1cT
z-&glPQ1^GK`#yDlkGj84-9Mo252*VetNVlM{t<QGukIgH_m8XlC)E8Rb^mj9|CG9a
zTHQN4Y8_!;tG!(Q<m#bgb?JG(J~%6TPS3vIuUS%iX6}mE@q??6AA(=*XKRNKtv+~U
zdhWutP}u4ve71z=ejY<V`-%fYPaXgAK17<9#mVe7vFichO|jvYy4dwA&#cR>!D|Cw
z8*(tgwanq`oZO<=&_Q?g@vr5+u^RKVI+N^&OnQ6(;9wnte}>>$BSUn0|KZuE#_A8n
z>c1Ad{-ER@YL(?Xi?rXx6kVIxWZNjZAU-+A|FN5`A&MsjUrqVgeBa`(%)sGXBSfED
zlbf5rGtK6WRM=td=DW134X(!gQoy0Kgp65ShK#Xm6OihS*f5O)23SJKY&6y5=YAbD
zF4i{?j@>^&#B<7G=<rdB{yMtqo~=(|Zt`BJIX(3$)V`<w8FhzG8>iFosWE)?>fqCL
zY9Zy0p86#GRDz~o)DJ?!N$Mt*8u!5iwg-S_5l6*$RTS}Qv$BN$h{_&WDyhg4)}w&6
zDglDOdjNH<RRW4%3BxzSYPr0?$tksl+84UuA{DB*1b(K-W#oZjC?kJ&fTaPpYGc!x
z4P4EN2kO6w6YqeY>knexCBi}bmH6P$DYVwas2<TX2J-Y)NOhY7Dtq@=g{pOK(5p9r
zW(R}<iej!~kptK@6jQiwiz%CTY}rv*zUzPQOS%p)D{3|YEx{(hD%b>fk8$vxGnB?V
z;xs8AWPmt$msBIcIEeY(1ABy;+15f_qxq;7NoM>!2CZnL2G=U6PH>G`7QuC$oRHaO
zSfXv@I+DOnthDVme$++$q1I5zRFfi1H%(=E<QZ<*AD50&9^L%*sm~h&>!|rA7<nIJ
zwd&u&lT2vP-Os0PyrSKDQ~~Y0a4tkw=x(#yvho2j&>Z2<re=K5x@OO}8yEN-Lao-x
z-9Q{Q7+i+4H0h%tf@-xRk0Es}8;>lEN7HFIG8f~zBlrl2Gqh~=j_J;{`n@yl)fHo{
zUH#{FD{Pq$;)uKwKd`@fLA9Gz8)$YE4w_XRa5rs0JX{Y=yXWr$(yf{zg2tT*ib9`B
z5D`|VP+R|wPXI3PQ&;~58$aZ|PQ<{#Rtc0&dh}XfFjFENvnF7Ya*4wto5G?I`jrzN
zFhOXCD2`upxN48w44v?r1DE5K68Ium6ptUmoBB#OqnBBOL8}IXEcc*SgQg>AU_^Q3
z6x`(G-~B+0TA`sC+G1=@9I7>tj04$=Z!ofn<S=2PBMV-{fe2{Z>XT?qNB#`)M)n&v
z@g!oiN$IyF!xBqykiFZiCbb?#VyFJbL+|)nc0n*0^Un`(PHsOU_#;!1cEEc9jFp6;
zBv8}Hc_wdZU{dHKTd9S=;7@fcPxh4=>-d5n-)a=uGLuxJRWVS-KotX33{){t#XuDU
zRSZ-yP{lwM162%EF;K-o6$4caR54J+KotX33{){t#XuDURSZ-yP{lwM162%EF;K-o
z6$4caR54J+KotX33{){t#XuDURSZ-yP{lwM1Lb1C-*0#Pa8w#Ae8KInsV;7g!co<)
zih(Kysu-wZpo)Pi2C5jSVxWqFDh8?;sA8asffp|Znm6Ly4jkw3lh~fM*qz>rzk>s#
zT5&8|YxD40Jf6sZrwJ!>;&2N0j>2O_?DROrrWJolKioQh*$kY(o;&5Mt#XLlEWBXf
zx-;C$gK46G0nIkNM!;*V|J+6#M0zOy<$s7QgdczJS~vg2XVpnk7Hlv4ny=+&Mbtxu
zqtdK@C-Uoz?FAliD(B+iy@ya(yy4`7y$|D+z9`aOo&msjcg^tL{diw9{0@HBAvXMe
z9?s3O-qiF<g|OxbgoRk?gyjFp3iEeSe|7ReAzeKDo#=4jA4fH`4zAhT3M6ktkq+hS
zKQ4GAJ-vd&hSxUdKmIas!_YmA4iAEAb@ky$H}idH$DG<+tMc99x-;H;UiN(Lm`eu^
zZ$SJV?mRehuc9M1j3bjiaR~t8yocF;g#*IDNuMCE<Y!+>rW;-xQ->@)-zY8|1ruv5
zL{*5g(N4b_d-e*uyn~N5d)GFu9B#eB)O=%+ns?^^{9F`bB5VGsiviH8`KPXgJAan0
zE6)DF@lv(gg>y83t6vjW!)veI6WcLHEcm#w@UgZR)WH8xe)ddcph0^P^7k^^p&d=m
z+b+mw_>O}tnqqs%F0GBj&hbMaR3pxJFDhG@s{)4>jrMNipSgZuhUD60xQ)^Br&ziE
zj;PYP;y|p{#X8r;Dp#f}d3n`AVK?Q^IOH?9B(=k1`B$CyD-RLj@I7l)5iEI&I(*^$
zaDq^Yy!sEX?aV(ZSp14r@?ieUmxsZH!ml4a{3FXo4`27%(Zj#LxM=vJ=v<uqv*!!V
z0un+#n)Q?w6heaKwCl4e|LOaS=BMcOuHoY0d)F?`KRK;v|1+BWYzCvDf4W$g*zPvG
z@{N|BjQaSD*WQM6j==pEH7$Mz{KwDp8Qh>i!Do7ef1+48`v-)-Q->4T=2Gc(`FnJD
zLHRZORmI@z@QX`?&nyxCUvrAoPnZ939bQm=Q~zS=b@)4rg%iHwk2fcd6>YC<?;qJR
zdic+JMi2jH_vqnglz_i3K6?5^r~G!*@-I3)GMxB<Vni({{~@Q42!>hk^!Qof>u0MY
z;c0xv@?Y#8J^alj!k^zfdiv#EMZ+JR#oD}=dd6ryid~;rK6$h_JSDGIlm(CYl>E=u
z@dItzLZ^>UiT^`t2W6GF{&TH!ab8s$^z?(rX5v_>y{C7spY9BAoImt~8)9AGif#Q?
zEH+$w5Qj20;Ar9JF%~%Z-!o%fU&F^;UxSFyR_3?h6#cbb2i9&qfT*+o;l}${)+|Q6
z{LZ;0O5xYQ!=DK4i^?v);-7DR_qkAYJ$R5;|9nniG3@ZqjTWxpFRJ}rG5C-2#PED3
z0)$^V!|$Xg@ZAJ0>oiGsy-rs^SFd~$@9eVSqrAQOSN-nis=Pi}1&{LiQJi?@<iC8j
zpoAjY3mW=D1HR2Z4QH3_ow4cK={T<#XIy^8mg0VuyhH*o6AiEVJ_E0=9C&Q+@|ntu
zG(1~G`<WYjdh+32Lq+KWe8ln}88v)U{>{50)018@w#$F|Re~@dqk-c1?GNKdH~-}S
z{G6vaTBTR`Qt}bw%KV|{NFV5Fx!;BfrNOHBx_;0{{_*)J{<F$=MmgoP;(z~@<<^J&
z)%Tw+o<H=*cNYQ+mj7LEJ|0zmpWfG;S=dAa2=?)}2ct0GzOZz-b*Zv1WY6Z?D`9EC
zmzrCf!Q}i>b1Oen3QI#Xs8Nh`Dj&bRd)5L?t@tbZMI*)(9{ffRzI@;f@a6k%7_bGX
z9VmJMe7pP}eA-9k`xbyIpSOVVr3BQ%e5yWG3{){t#XuDURSZ-yP{lwM162%EF;K-o
z6$4caR54J+z<4o0yGr${VjzrxqaSgUsV(eZbyqP^#Xunjj()h>UTmy9QI#JyI-DOh
z1^MIXX|n_J_2rib!{?t9bO(S{9aRieF%ZDOu~7ROoL6l>Hi90wqKXe2AJz9N2C5h+
z9|N&Oe}C!<_qJ5JzniJ{-EyYVUz*m-GYqMFNqfBMs`ifUsr1(N>)JEznRHkCwyta{
z)t_naN@ww&&Ly*b0|^z9=xxtryF0Qw2NNBA$)41ruED`DNacRd(r7tWVSatdY$BbE
z_qPuw(jD2}bRyo}(H+mmi{^WO><m@kI$f#<w4195c|8;ge?+@akznVLcAu)<Pleoh
z?Vhc}kA>3Lu9o~~>hK2bHt^k$yGgrE`I@!c<lm;<r)hYdq4fRQt%IFG?XJ}xJG9%t
z->uzTp2O>Y?Z#JG)%6D<_r6g4_l3eA2)Q2&x%X?gp~t5};SX!KDbHs^;g5vee;0~>
zAmsi^$bCq=xmu9d*F)h?gxuc=xu4Q*gP-q(!VibSe-sMOhr)jv3O^ch|1#u07E1qI
z$nCsN_|25BHsr1gxo3ym4I%eA+HLSPC*-~$6yFWG=ZD;l+HLrMamXFhZo{9OwA=7Y
zuXdj!<a6#1g+HL(XX)^Vwfh3?eoDKsKuxaK3%*QvqjsC{wov#E?Y>ASe@MH}*X~2w
z?P~W??Y>aE=d6+ZF4pdtcANCQ+Kta|tLtv<Hu&GA-CVuQ>;6#u{n~BH_jT<y^5-e-
zHu%qL_Zb4tan?%tOnF@GHu#BY_W~V%hjy!#a`1a76#kTUU#{aftP8?#(r#CWZ_@60
z+I_!vH){6*?Y>OAk7@TSwA;N|;2U||q}^xg@R)WR`Pr}Aj}CS=h2jrtw}JnFc6<D#
z-3C8TY4>>=U>JT_zJ=vexP6D^L0CS8`Tv;C|6Eg{>T^;s(9y9uo=J2YHg!5Wy1Elx
z{a)T39fR>qSKRaH=z!h?xAEwJHq*xl+M}bRC!WdL?rjNZVQJ$7`2EJw(UFL6?vtzl
zcY9w?w&N<DvvFVTxd*f9>#nuRl}==`>AtS4NuPsy)wd;?Q0k&%LQTcoWMVsGy4{KX
zL^h!kEyI2Ja>rS^)N$tGeHlFF;{T>Q947@uEsk<C;zGn>yS*I3VBtdi`Hnwj;lkyY
zIalIIxdJfGQlv+8XE~l%;MsVo<Gc;eH{*Xd{ud+B-FUeS;g{pT5dSOjUx5E|Bw7jp
z7vueI{NId!=eC|~d~<)|5~StTxovaEP0X55gj1zW^>`kg{V7CnGue2yugl$%i>JH2
zFa?iDOm6Y~03ZASEWtlV!s(DsA)}xV2?}GV;yIn&iJo|_KkIg-k_Lp^)t}1b(q0`T
zUlc2zE)7rTYlG{9E=}5ag;sb`Y-Sb9jfw{RNj#}$DX7GEUpkuu2D|$*gZ=TY#6TjM
zbqC^u1}}+Tx11t&`tf|+MikMCS5^@_yHbNYM?rRHt~=|d6WLrk>5;j!HRg2QvSGt&
z;!XG?#ARXsQ8EAwwk@_9UP91>aXOu;fn=Xc9?kUmTn6|)GNna^n4}>5O?QN1NPe9I
z@nn2UqPr|2AW1m>sKj7=pKb-1j$$w?zM)@;K2fQVPxsDbd;m?fFWHyvgCx5vk#>7h
zY1i<X36EzJJNmLVpIfm2$79B_vi0IuRM-eSmW3Rq3&<lG2}g(}PyV{|=DA4bySq{y
z@$K<GE%rVCrOPOF!G9Yd|J;>{Ojo*Z(2^1EjTCDu`s10573#*buIV9Ea>tI>l1|5W
zYW(Y@u|9~NbXV_A3y3X-9Ct-(V30kGd-LYEK-9QvAb+iLbjFjZ<j#RqF5`mUiOe8G
ziUF`7<2WmBUE;DN^XK<EOO`lJHUV&;`NF|?8u20d*!uvF#R62Q<7`PJ6X+cmvO8dk
z&aemkE<whfD2_xb1gJqd3;KJU8*b=WLHD9Xi=1^E*R0|D0(7;0IaE%eQd;?T5%u9(
zSmCH!Z>qZ>LNeFikDi~|Ioncw(z)Z^&)3UR#kuDa*SUxF+6JUkW+!&Ml>wexx!{g>
zza^JJ9ODk~r6m=56a7#H42k@FO_xe5jysST*o^jScPF8As&FiaL3334;@O(yj_$}k
zx9OgY$6&f|8`wpd2%dxKR2FQQ=+-`ixy}83U0$&BrfhF6x%Ccknp}w;G*r3sR!FmR
zE_EHJs}~(Lf-}9TbQUi#X3^>Nr=SP$1y?Q!`3~jF#XIT5C$DWOaBp9K!c{Kct(~Y(
z_mU-=$Q=S!1qJ<0Z0J|83-%3W`ZChooh!(YxUL8VxXDyvM^|Eya-wT6=fnpFohw|a
z3*)Q0;EB4ZdeE<@KNV;E?i7#&6>&3+hxG4&i7>mEZ~FbJ>%?K)*BC8ThX?djq`m5D
zof_o_wv(ytNnLz}+r=G5no0Sty3Y3??ytGpcW<YMcE)qrlqm?6cDBGqdP3*q)zPv2
zx@%qa>TF#1`gJ$owoV+l`_w|7RMm8dYY3*@ow~ekqAQcrtss}|OC?>2AUd8nR1??!
zT`AkeJb;Hpx(DJ;#YiM`1AI|=<K<%haqH^uTe2ih!Aor#;dBr7B|9Jl=yU0t9Otb)
z;Hi7~ME?lC3~ugUH8j)q_V^O9*A{ysin<=s@&D%<iT~yE<+=B2dER@SJWc$?e=YD|
zd8YXP%O&!B`3>3~ihoGQzvJZ+zU|fWOlf=aa-H75-}G65|HuM~*QKAYZ5DUOe0iGq
zc^&`k*NXqYULem$8|0bPPZPhKr?Fi+c&YI&yazqJ5dA{Xh*I=YSr-kRoPctwUl7N=
z;Re@u&bd|WGhsJzR*Sz0H}*^8o^BF^o-5+XWGd^%ySft4NVdiMa|t)q<D$3E?sQXw
zS+p>J(2cYu=Nq>4L6UFAtVVx(U$Uz`0z{w$-OduH-HAI*&Q*AJINP0+lXkY^{W|<J
z>YsMH@Z5%b7NIGpU-@?-UKajaoIX5zot(2-#fBWkv(HJYR4Hc=p?ye|L@r8<2J#O(
zGKkGGEkTN4%B9F5iJbe8W70_=mW%RssGPDW?X?(hn{)}3Ee=Smi>t=$;e3pHp0ffm
zllY|&-^F_uehK80foq#8a}I77;XSw~oB>s?oysRzLSyqYu+{T+;g^_x?$b{bCk|+R
zup|s1zlFd)@wN~pV967B>w(W^yrormKd7`&{|y9rmV%RUb^>x2=(G@2Ae5`|Zwdl|
zYpcqO`0aPDK^$`}fE#M5cLnqFypaPj*o*YtpiQsBZ8y>qgUj%9oz>1d=T@i1S%bHg
zh!ey6I=roMTH%tAjd+i~#?P<h<Fw)>^5p<ZMm`rFC-$@ON#jXwZPyf$+IFB$DflE+
zeYPQ9zq1I?2JtI(mBtHkzCDDqLa0GFJ;>SMm1P%x?Nhk#QFUaSmDbmRS|(Ke7?Wjh
zbhLs{m`#X|c0Q(@^b1}_=FxXmf2IX9w_SFOQ245J0?L(jg~D%2WN)QB^kRg<*W2MW
zh-HVb_J+?Z(ilj?@UR~0FQjSf4i6q*jz53=clbZ2pT9MM=bd%lY53Rbr|~Anb}_H;
zW#&70KwLQNWOBby%fI7qL@)Z{GSO@PJ+w}7qo~uaDEpwZLHg$;-LDo!r`sIw4y0k9
zu@F5;hjW{fUhES@ZY9y4`thU8XRmTGelFfk{FQiHg^&b(CQXl$B5ZfXt`jTI5~u^E
z8~fA_lwt?kbwbrZWJ0;p%W-(TVYm)8@NmD?;Fv+pjBo_F8-a^P<h@>DEdhKCKxX!#
zOq55&B&E?7xHcoKOZ7k9N-|xFly~FD^gW0}oU+GfkI4RnJ$51FK~QNk!utTr<RH0H
z+Fc4;JmE1N<@^rZ2LPuV?~EM>^n}ij`3vQ#Wr()Z0m$qDh&>-dhX;fD2ek=mDNHXs
zGFQbNz?~WlOI9pLmaw=?jzDiwFB`WmW;KYrAO}Y$9YFb#0WF|i*PXgxPQUv-CVR#~
z%a@!+?6ku-2kd4_^pG81Jfq3^y>C<r!D9!^+$Y0d2{-j_bA2G>-V1k~3B>bVA@?7K
z-1|cAcZb~X3Ax`Ja({MOFu%VExvip%`Z_xldLZNuk0(wEg&XJi=t*7(>O+)ogP<>U
z{|?;A(MFG=gh}Ja&~haU+ZNlsfma@MQ@g_FcEHNuKL~x7ExHk<As<q|-lAJSTjyOU
zD>eE?j1HuIGal<gUuv$@kOozaf-u-ZUCjHr(4Iw}ta0W!w*)ZZLVq=wn2WZMRR1=G
zn=QCg3N8VJd1bfu(cquzoaz+9F2oIe3h^_jOGS;B+At+#*pHYLoH3O3UFyY=+EBVk
zdRJj$E8L<hFE6W>mB6!WCiUUS#-}*tQE!QQxaj5C6G&Wfg=_6ocM<q`5$eI(Uo$Gr
zB&J_NgKv&TCzBry&z0gZ@{WB?MS00}9B;?bLKCB67t4FVhm;m6#Ai#Tes(MTGT=In
z*j$X~FITNI++x-s)@IfA(vS_|tC)V%`|SqjfR1eIH^t)LUnKrOUveu9>WO|XLd~@2
zxD=I3Q{#h!>NOk3^zvYPJiTQbR$8Ppn52zd6Kb>-UpFzbGmg4#!3a?Fyg^_isq`9Z
zeiD{b?VB==whhs(%7I6@NL{HE%rH))+~ezysMWA8Sx|crGS#m$%SIcCXp^OTAL?KO
z_|Yy!?T$}smRkUseVoDBwooOC(LMj2Xg#=C{Dyz3EdCRSze|^;96mf+Bz`eI#FW$4
zY)bKBBDt*{|Gso8$wdyB^w2ZWn7~OTBe~K?Ql<2z=AD7Q$$r<@BdOhQ1AXP$2a1qB
zloRA$(G+QQ>;u)Q>)(Z^v2&EBJxj}0!*Kz%8@3qc7tY78mH);OOB^xThN$gl0V$|&
z&<4X%O<avb66iN5)w1Yoq(5Q4cY@29n^?)neWH7?f1z9>4|1f&nr26ph|`qS*>N@`
zeY<o!id*Z<RE6#j_+RN&#H9NJE1aRl`1Qa)V<JJPE{Ff-e7C`~E|wF&7xAOuQ*R@F
zh%4ffwnW>Cydsru#X5+#bczOaT|nzmDBo@dRyROD+k|^@DacqiDqCd>bh|f}h<RI?
z5I171TwdNAVWYjyi)&S=#A~JPFF1blN4Ff|k!ub9O0_ELHg<edOpe`qfxYEw1loi*
z858463utqc*T$NEsgAi6aiT&y5Z|^ZM~{;^vZroftOSz3jKy8pXKse3+zNYhbZQ4V
z&jZzMORDR^a#epyeq{Tm9Y{txgex`)YR=4^^`aGmvjkmu(obeAHY>k4{5ekU!H;7m
zk!!Rj^(t2!q0}}x!l>*r^z!wC6U*<#N@w_i_8L<rJMJJfIkAF_Zk_1R(z6&G;*Pps
zKX5lXB*}ez?W4H<(XINDI3(2Q^8tQ+wu4u;05@V!G`Qgmob6w#PCh(4m4Sx2|B9et
z0(aW<+8Hxv)tz$cX|qp1qrTzHv(7%}+?Tz4&Uxp*;(}Mc>Oyz!yo=^9xcHLBOE0_p
ziiL}=Y`W^|Yp#9ub+1|c+9lUx>D3L*EjO-M*}Cec*y`84e$Co-H@Cgvmh~Gp-g?`n
zH{SlH_B-C((HY;2b;Uhfdi&n8wSOR)8oV=|$>z3g-?8(qx88lv+wS!XUgYg?&hO_K
zW#6*t%{6!))&9Fz$i6V+->^;M8~^lju>&`T{G0UreJtev#S0~VZ^-{t?O&vrp7$Dz
zM>^DO*Ba#~?iG+jYw&AP65fl97Zbh#eGVm+xx{}h(yfE<2Bc)K<X;lL&e@1|)rzpy
z$k)Ckd;|O$?q9|F`=)<sfGm`&oc_BF@tZ4%zrVuxhboNU`LEICiIVR!b`a}@Si30m
zDcfmpw#Npxe5O?AY#eRT<;&{v$sapU&P__6Yx|a#KjqX%6B3VN;{`o#RjcI^?b|bn
zth|PY2ZnDs>+8a5BsP5FjhNn|u*_akv;tx~93p89oEGS9Q5WTAAvPrDGUs~r!h3W)
z>K0trK#Fb+fRC~-^&=KbPuWe4y%9NAYEiUd6j~HB3a-p@jIIF`tB>Hq;M1>?vG0Vf
zWhSP~a2UR3?YJI7tZBhA`!LNLwkZ_FuZ)2>st)S!raYv&*vEY9ou4x;j@RQ~hzm3B
z=U8boN;-&jAg{rDKXT%{60JhayVw;)Ut`JSij3u;?Ol+{L1<&8dTGc}ypT}*W@hX}
zUyzYvFhuxe3ozLmfvI8`2>O?c4`24J18$7ncq}a;3MYlory4KC_{<&+1TiTtAD=#l
zmsjJ7<gs$_$u_o7^<*x_o`o$fs&?WhE74zQ^`(ULSH~=Z<e+WmM7678{KN4JSJ2VE
z6?OUi<4f#9{#k+aVnL#9d*V1J2zM&mU@`nrn~~Xj#we8Z<>QY~+BA%b#h?v&s&Kdv
zed3}B1`Ey>*qUTe6QG79a$YnAS>s0w==dN+6e-{pML)Zg>vXAZ2LET#hIuFTqT;OA
zS{m&;E0isXGX{)37|<QL&X3YMu2%w48<P62Q5vG?{3hqI^2&Jf402H=vO0j=2*>!S
zNq%_S3FU|=exQxR*8L}ke&fqENI~*Yu)P`X3iEYztZ2@j2)-CUKTtw*rj0Wh!P5IO
zC4v#P*Nd0lW*x09seFu(BSw!wT+(hlK7Buo`N^TT-G|7Ska`fU-dwfAxm}UKw3%0S
zMe~b|<B4clrKwXo#`x%0oK8V}2|n!AG1L_8p3>MZ3VTJ42v$Uny0Jf1XA^~QzrU2c
zh>Nh_8pXQ|k(C9ad9#=0>?!+OvBYK6Y)q?KeIT}emY3SHtidWZQW?E`TrChR9epON
zY((LB=o7|il)R^XNM@+1(G*UQ+M)LPBw0TyT+DSNvIpg6*hO2F+%a?UqCas(t>GhC
zRY$l&ORkgU9vsfWEyq6?FSvt;am<?EV7zE}T!CF)&Rp$9USSTh8kTcwu5$zam*Ll_
z@DwaD{VzobbKt6C!3p_}R?J}e!u23*=2<!x*8vvG-#y{^6C;y(5l^%u8ouNlD&6K1
zeoVrr)Ogn(Rgq7_d{EB1&Lkv_tUfcAK8|>8$c1{^#o!dXKY0`Q>JBAEIAhP<S(RXv
zqp~YZ<?$@9{!?j>4A!2Q7d@nsTKg3)uf9P$#KcnDx0@8wdi-@QzkW8?O>7Nq$S0zX
zq^94lWtM<zf7$PZFY&cox80UlZ|+hk)!!7h+i;5*jT<{qC}Rs@x&8I$9IJ@ju}kG^
z<>A^yw^uu@(KgA!gv=VsyvF5_6m&(!4#pa-E@o|oS?|FWHqk3P&52sUI*e~VlB?vo
zf{3e)W%r^fPw9C`GeZ?l87yD1`RN1Si=N+Q{2GAx9>UGVy%Kr2cWDoXo2wZ7#($57
zUt&HK$8xB3ys0El=Lt`SBGbbkmh}oI|A#*kbjQw?^#)0O4#7ShzF$AjyHvt|t@pqE
z=Vjvl{j=n0;JP0bxPPhr|8|aqU-KGy9z9o{FMFjtPdiVZINL$3r!a8L)7>8|=PnK3
zgg0w<n=WUkem3Z5vwoWRl|GBnsrmcS>lE()psf4Yr=Jh#=Y#tBas4#qFq=`=rP2d&
zEHGSg3)V_(Nv6`6I$Y7;hjp+LvsgKfJ>B47?~uC6SuZi?2Mx~Q3gYiV{6i7(J1`RC
zdT81+IiIl=>pM6z&D9G#p%aB=$3(Sv_9>eoskw8{NP$vqp2Zhjy1l8?Ru_kXrEn+`
z78Sca@xFeX499brdU#6Ag5HeV-<QNo_oBcCh0)Xdaa+^rRC);y<VmG>S~)Fox#LrN
zZ$|!GT^^U>C)7B$^GPQbj-{vyQb{<WoGUK(scQpO#K}9rA<);jp!?DgY!+xkZ^FG%
zRU6Tob}Sflx5qOEKS;cp$dVI$(y3e)B*<Lh=5S<IhxYEknbo8l4>XLp3_q?$-+wFm
z2CmNT#vXs^C)&W59AV4Yz7ZTGz2DXXJ~f~@I^Yfl;jwOQktbC48|;~VZNc<`(V<*H
z$X3BM)m(GRcUd)H%D`O_vJNFWSH|bcZLT<^Ei)?b(c+X-0#olwpPFw5Q<+R34lQzf
z6Y)WuLzPbF)EOdV3LKJ?OyC43QoSg6mS5Ir$egiRRZpyO&#npEj(9wQ!;IGFDr}li
zS|&=R6il1m-_Y04Fie4HZY!)tP@m%}5TTXNX~l8~!V1FSYGTe6k?NH~61aA%(RSko
z?RuQa*bHv<ukp9v9vr(+*m!L@#TZ5+hee2RfnOV1cXmPpWJ~f-pJ?>jD_1wmetJ7i
z4!Dfo=@n~jX>(WHe9J8x+cvDed7Znmbwlfl4XrC7w-Y$#NqPp6+l?1N#F4Sd(2Gt*
zkB!q1<&ZNs+YA3JWF6M2;hZz+WVZ7RG&h^_#J@mPIvWq&QEg^(uBRuFUUX`Oa@D6$
z@a?3jPq0`;UB$~A@4>lUs$-rY^b5d5vin5go|QZ)>QfZkPDDG2?!AoEiViKOXEA-7
zk+gox9IekX`HmK+oZLr2!Kgunr7e^rri@V`(mz!Kg&NE)SYgfmKWnhwdWG|PPcMkd
z!JHAX4smaR_RW)x?6jj+uOKkk?~K-e*>x%agA&+wjnVtB(ID|`3uD7B?2Q~}Wy{)@
zn_5?T1t{L$pygwOA=^5~TCNC@u}JT@EvQA(Q-@`*g~7r&<@S`9-@|0|iy9bl)Fg_&
z(%}0t?t;}hsP5SWMol=3a|~E06K+AFR_yG8w%M1|^z84;@JwRe3vch`SPn;za&I0F
z3m2lRQJ-J_u!^Dbh*5vVad>?=SJey<N#1Y)jQ+S88k+2DHtkVb@k+Gfo6r_+!Ms(Q
zYN2e|tI$SU;BWNTFcdktj3<0?HyO|S;=Hu4-%#SQZEiu^82vKiq4j{3#VKdh=2q#n
zc1mi@Tp4Xn!7;N`#m;OoaOKn?j%8X@`W3kMAuo=xZU(fs;GJ`+;c`-!rH;<CibmH*
z#l9d`1>efReQq+6vuoivH-<;oJ*gaec(0vT+B{3aGr1dlNI6%cZ1&zd?xhW0W_(dD
z9!zS(DV3yKu;}Vdt_Hv}CIoNxNWx#SWb%=7N!Um8EIOWa6r8DZSK_?kCGOG%ndR<+
zjNdF)<_2&|>J~SpPMyxU3ztjSMXT5p)hO{Ing-k@QX*|BFiz*K3;Mh7K~R^nc?G5P
z6>cWCnbs0_!Hz2mM2;!BJYhM59W9(bET;T4I0PXax%|ukMxV0Xjp}3AD@SkJ(qg5N
zN!s+&pNMbG%=PgW<{w%W2GyxmGLj{|dGbWK9W7W*n+XLkWFQ?Bq&L#QlCiUQ*5G6Z
zd`rQ_ako4n8Wt6t#Ox*Zqi#rLfi~aVl!=VxU{%C=NTjRrr&PNQ&voDt$`G+`a8{Et
zAUtlC5xl?amhz1)#aQD9v>f8-KdQgCV;jB8pK}O?awo6R9ehd$-#DHPr~=9!rH(`u
z>!8@AjP=P48l{TcqE^NS@Hqf8XcR+NZ(mn$NpqLa5~`r3@D;R|L}5(oTL@=#y~<!|
zeE5kT>l@g7a&-f3xx(L^S2K1SnJJXMf%^)%U(t*q?DZaU8UyVXoCh|1mr?RcR(v$s
z8HV1=wMSEC@)TOm&=Kd{gH3CU$WqElmc1W7tcl22+NRAuE%w%Y=Xqqkp)%M`!uQVw
z37_uZ$0P>0;(#lh<g5nb%U@k$Fy^O_w;K`P^h_>FPn#pxK%`V#F|E%})d;N5gAP+p
zs(BuL3iplkGzwx)&Y^ID16syh`0`u@uBI{?Nc5V!8yqZ^iMr&N3EpcMtZviQ;S)2R
zX>irn&fw4Se$!`gKF*&bnN~N=nO=wBI%k%HquQp=n(j<@X3Rp2S%f%^=Xx?suDY4d
zO#ao6UbE_E@vnX=p2TJRI`v~D4O?>XU@>H>ubHZlyw{-exPY_ib#%|Hn^x!4)Dm-o
z!@3##3F?TWI=mttli?3M&Qf@srQo3c8k3Br@dsSuwT^$4mqRQHMpc&Zo&`+K0!H~4
z3^L|PhreR;aJzog;B@M``8-zqT$BA3#y?PD{KFN-cmA`o^1Btre+u#43h>kP<I2t{
z8mut>Lx^8Vd5+~PE6?I1mBo+!q_X(;R~UcaNM-P!s4%|!|0;vuSz-K#epVU$e1-An
zJX0AzG#{<3Ji8FT5`NqN^UB~iKU-P+hkjXE{A2%9S$yZY==fR$K-ZxLWuN*Ueco$j
z`j?ymJG!PNB?#Insk=#9?hx=-<N9ZAE%p56w13|wBl?}u|2T`u6L-z5rJOZHH&6F8
z)@*YIm%&Eq=ZV1=^|BP!xEIHmXth$S(JeN?I+R;pa{_+wJSd+Y?I@qWZ=m!_kDwmC
z4OsUrA3atPWlo-YZ+YkUgyCk2z%^NLjf&B?$y2Na$Hj$XS373;7#_Vm<i_AtIu|p>
zvSS8Iz8s}5Hm2hFCO2Ajjv8I?v=TYJHdr>g3hR>$U^rYOGxsADWcw<Qjwa`F`ExAt
zhqeuyXM0ViqdX~(%-GWB{vagoa<n0HCm>HKG~W&3IBRKWKfx6UmDwDQy2{N(T0QH|
zv1~9;?v`R}m9;eC{FZ~pW64p@FC!IYmyL|6W%sqLm6!bFymnfR!a0vE-|^H`tPIj0
z1Sv5Jp(iNFoF~L~LtCv_+s*kwMy^pxF@(Jjt@CNL(&BB<E?T*q66B2_7K9&7e|qBS
zV{)2I9yEDQX6>ee?<S5PxDwyjuueSQg87Y=Hz+6MWMl3V<jO$Kn7wr6(8TeB;f52>
z2_~l#!2<^NWY%IT<bdfTCXW8W_BkH>nXy-}PkJ%xD`Ttai-TV#qNSCGKa<l~<;7TZ
zT9fCAZwDqPj_Tyk@kLOBGp&8%pD%U!VcQ?<6+Zqv=!wxV%H#Z?Or9DJ3G&>;@r&X6
z$!uX`%d0XTnTmQ%h2#*vm^gk2^7_~)C02y7wXLz|c;d$+W2@0raK*&&!&J1RiRXc-
zsKr#!-SiT)hw-FmITJ$8rgAY8!&5bU>lb(V%lDRxS;qV?XNFg>nVe2u`BSymj&7N@
z`BUsUv?<f>E|wh5G01t^L0X>(SMU@rGb?0sulc&C&%M;o$-i6+9KNFKBfCvyb(hTL
zm^EhM9oiEoKPRp~t@87D`Prs_m}5??+uol^I&!V&4mHx`8CFgB%Rb!8;LlLbWto-z
zoTo4?;u2@RbBPzb7*wwK<<~B5!QKk)go-|^->z}F{63a3{8YC9$~nr4!Ziw_F$PaM
zl$8r+6$76fdCKX~Nzle`g<Qc99FrI=!#_9A#_@RG*`KdP-ttW&&O@4S9QkvET*t~4
zq&#<?`$_DwaRs=)9=G(YSCt<qYotH4`x4;?(?+?@KFk9)p2tJ+VA^u&5w!INtyk6g
zN490s$E<C#u|)}C)2`G!ziI11Ymm(=Q=vy0uBq~i*@rOtnh8V2v5z?YJq|WEai2+0
zTQND6!!MJsr<BVtW9k1*%_kejFXTSIN)NLymMw{Ldvg2Sa`7K*^HKfnRBOLuZ*?c$
zp6ct;{`$Z|$r;38Ir4Mz>=qN>-v(<tcIuVeF9q`(>)fvBJsi27-0Oj&^|Q(AZ^h~)
zC$H^*Tq}2lbGh=U5)C#?`KbQV@OP<ax#cS@FQ-CV7<(%#CL^b!7AKcIccRvBPX#7l
zD*P~+a<4pos6>7l&WN_|jV`e!PF@A2=-4?&PB7qJsi2Guk0XQmjkUiX%Q!BW^W@j`
z#VOyW8mnWY<BOAjCQlxQrBk``=!J^+DBY4HJ(=sWzch7n&c9UYQ=Jb<h5BZH#-O})
zVZOdHc{11JIkp@{8>_T-CsRLd<ZQX^H>i6>+4H6Xqhq7qSo(^os9kA(nf!jaTz+{W
z;rNBz2UqD)oez<(N>|$J2FF)p9WUE!X<k_SQ=%>2lRZOHZu>3W{|4zfww|#Py(XAn
zm4CR$o8MgFY9d)lYjms=`LsucW-X-8*^~)(iOhM@rBj)&W|S&>x%~UWlN0093MO|}
z-ltNz^e8P)rb6Q#o7Ad|x2B?Ar8W7<>UXOA5nSyorwG}5XirZ5u%)=)+9&?4T>f}r
zw7D0a3@;b|rR8@}KO385oqT;zbe9voUZy<DT@ZuS^;L4BIVm*yI`Oe#ckCQmY^_O<
zeq)C})*0y1z5ZlLb$<WaZp(|TJwL%6e&xy^8(O6^^HEZ{+@7r5@|Bj4Q_;_lod=8Y
z_*B%QG+$4aHY?wCpP2J7rvj5N6@HjZIakSgs`7d&!x>{)PsRO-m%s+Yy{Wd&%zcO9
zGdEq;uVyg&&+qv0I~NnTAF;GNoVea{Y^&GD))vMx&otFFwdJR=vyp4f=>o}eJHrWx
zXU>Q9N5!&RmODJR;Ljb__Gtr!XJw4eqns(0lV#Z_@Js^vCeFm{^DYIwy5HMBK~=^t
z)V+eMiVAT!9=6&JDtBXq&^w`YE(Wzq-_rDz6P@KN^*$cQO5<|%Z@aIX%z44F^*xlx
zQKORbSK?Le{r)KmrN)E4J~erLzR7cJIm&3aJl--n1?@#s)z6pPUdN(GnVL>EPETYX
z_R_%D#Ptc~;;XX$U@AGw*M!YEC*`ijo{B!8T>QUS$A6T}#cX5Mao)*hAFH$n9edAG
zj3=f_vKS3>vh{$IQ9hJsbqluMv92#0i(V7VdF(tm5%Wfq%`f3`VY&SCLdElm)Fp|_
zmmdBmPPeQCf2H-CiIDu|NiLJqWXdd)=ZTkACa3E7R_4?vVl6}vrzcV-ok)3PYBAY7
zSctEQlR@R;tF-)?YOP{yRH<y-KGk)c`kA$f<Cm#uO_RYRQ&F#}=L@4(PaJ<tbz2)7
zuS|};raV0@h`|?@K2y5CnTmEc@jNjVwU|n2(TEiiIjp$ocjUVwjmcbpzx9a``Cfea
zqiwN4463z8Jb{pQF@6V{>rJ>CgR3&wCTY9QI*nNEQFtyezXU8Nx99NeM_OZ*U`S9y
zutS3DMyyI0VOYkqTzOeOMozBpu~K&}KI1^ja6cjGRY;c(thC@9MZ63=mK(*V?da=t
zip8sRMaD~$zS0ZIDf-fWY<&7F!NyP7@G1O8o|^MDFLB!Om5ob^vPZe}nVkM;a^?@l
zB1;Tj$KC^$doHcXDX6d59Od(mz3!GAX3`cV_k;(O%Ret9oS#fG`=x_lo5N3>%q$n5
zFD7{>n2p|ZXCy{du8C+Ymp{fL&w}I8@nC%H<KL4>wh`kmO?*#|tg8gSlOylS<69$>
zUP|+8Hb+$TyK;8?5o6`9!0<WBtkXGJ#^fhb{+U{z_@2h(Bx9E7KE~$omx_KjIr1)O
zp$l@h*^}j4#SE<`n=4Gqv-x1^C0)7g@5R(V3I$Hwc%V|Qx9#yK7k9i+^waX}X2J1?
zFRS@QUiPIj2f#g1Y3vQn;gma>HK2_#4Ldcz(Lm|KZ&u5!f{dBQbDy~O7p&cQq}$lA
zIkp_9b{sjjn%eEv%m>-~n+et5UpyY}C_n8$Uvg_AolNw%ccrtL_8ji*eaWu&u2edK
z_l~|~7QylUj!d?@FV&ICWe0QFMZE<Xl*^A}q1#0Cyya2M<TUkdyj*-vPXAgd_9m}Q
z8;XrBNA{ZIn_oCt+VRBk%L}tV7)>{u>KdJla)09ZWhz?W*jxJxY5&t?>I3ES!&v(7
ziEDr5jgW%*O?_WZWvN{JmhR7kwHtd&DAxuU%x^Mn%fXx{zosXn+%}4Lx%@Pi_Bs&~
zy}Xuca+>-!S}s0Iw@*{26VI<Er^#%SCeO*N-O1PvCyrmHTFQ-$l9k!cr@D?O9|uhw
z|4c=ToD80sih7+qd@^zTG1YBvY`ii#<N5NmlpqF0S0SfxzV^ju|Cx$*H}O0&6}32d
zq{qoQ-Yn0G9Byr6<Bh4(PsUb9n{$HS5H;hy6aAdH{$?UtUU^tFIgNGvQyGt#+{VU_
z<DY4mT)vn%eh9Yb6OX-Mev`u+!8|9wj<);|%}Mr9`Rjxx@5=)ssjB>AzIT|_t3SB*
zL-r*Wt}Q$H`N!Tdb)x$s!k;+)nF_f*HVN>;>W`*Y&Q$qhGS;hBs)v>ChbBvoOdNkq
zwQQaYSu)jiwD~5=qH^ND{4sI-QtfY2=)LWEGTO<;KmM5-zA(B@l|Nqi{mo?V^f&uP
z%(usza3ajz__;Vs=4#xRI?HhPV_ocA9B@ncHO_VVyc@%Z<{9QkeuFZF_2_JCaw3X+
zcbz?WIcti;@QR(@Xt!&gy~6eFJU1tUA4fb(ovH3is{N&$P*V=o4L6PdIdS|`?LQ~4
z|14KJjGsTcAl;TJnP*PcG4k*-XbXd0XjhS}!u(~+yDmTo>KBHGWM>Y)*2Wl=U1=q)
zmU<_?$ShtCQj%YF%NEI<_6U}7uBw4KiEI$@(?wF8*zyMZ;zW@$*xnOeo}iR37mI$0
zCZjx+VCm>P>YHm&yt;SFbB=zR65pnFcO_xNBd7RRD>#6Cpy7iS)f1BAvWUx*<XmSJ
z()MBR7r$I-uC@^TQ=L;0k8tEWgSIWmz!7M@h_xNDcH&8X=E-y{!4}-(*lXs3x4Ft$
zo;j2!fp_uYmlWytOLr>vs7dJvE8+0uI>ulceyxtrTT%K9^5PkHuCv0q96x@OlRdw`
z+l?o#1xsq@mT?xDs#o-!H{-qMg%i}kW8bthon{>{!-`NW{=*f<Z=PNm{C!2@o1(1*
zCN~3HTY$L*z+(oogfwpp&~Awe?M0}>F?ZXi*gIh^0L4sNLT^;?MLTnyTTli{tewb(
z+9GM_m&#B(4t^R`I~B=ChNhPSS|wK{^_7y3_dd1tT{@UfZAr%m++=(p;pUQCld0{=
z<vzyvJ<$!iJ+TF+oUOor4>*G7P8uw;?PuUmD_Is#N*li&n%$#w%lQ87fJ(a+^i2as
z0`zQ0K5X|Hyyf(JJ6!A$+d*kkU1GFDim)8??*`XWvaqjP1RutVx}x?GX3|~l@xeiE
zDIDm_bhUSH-jW{7F6tVL05O0XlN*he&;dDf3ozD!dmElH=Vts~5BF+kowFW3EzTPJ
zj22OT`dge<XDwjeif8eQr+^ONCtqfzMC3dUB_vl=6OSFBrqI!bLR@dR!phYdg86X=
zF(q{zxaS#{{5~c3om28hU$PImPtjM_C3PtZ4x+VF_i04A?Ovh-@Yq|3#BW55KIbmD
zQsBu(hdP;@gi8LTtmuK8y+J?Vkf(~nyA&f<SM?B0cw>Jenw1$XntsYJL5FGuTagp%
z$1mY>?83d(jo<?LlBci9H3BMsW4l@bmzWUzN`FPEYpzqlQ^a)w<7nU4f%IDifA-;F
z|FtM}H);?JqkhB|<l{d~Q}zZu_z|1L(zQ5m^0gT6^L-6kI9mYuY^7>}l--8&Sc3Hk
zF*_GUnp2+lqb$@<Ts)~6tOlRE;B%v+%qtsjCn9%)<EUo|`Jr|nw|DgP^(TVzV-Q&6
zSHb&$YcmRvRej~QJSoli<RwQRVlin)DfpEIa>Hoyvcqc?GIB915pAwui%BVNWP3=1
zp9(KK^&;!UT(%PXnz;Iz+Of5cRzu0%#|Gp3*F=_wJis$NM=K4>VdDAr5%!JLYW=I2
z{<vf2na*Mz&DJ+f%89JccGa>;^U-P~IkR4V{NgnW$0Ic;ExMqG6i;Pp=P2FPNUL&M
z7JG_>>R;G@*nNqyeKtadt#)pQbm~BV+~RD4q`DISa7xoN1^L-8nY@|rwMU)aZKS1<
z3oB4>>DLw^zf~wHM@hYS-;CU|z$eE)GJ>K!W$(|C4z;vxcy~b`!s^DG>?d_C8pwCw
z?RL2kYlVpcVuCYWwEVJftmI<-Cc31Hv>rJZHDqrh_*tZS+zd+0x>0)&oq(Fx&CteL
zL93N0eP!jJxb{IQ--Ggsq%74!%IjA$J=x8<o?y=+)F~zp+Gd>zD#~TcgJSUq5x=>D
z_zzSV|3HQ1$yW%!p)R`oCGcyG4{0Avq&u>`=|sG{qdT6B7ohsVKNh>oe*OHoem<n1
zpVH5V_4Bj(`G|fV(9c8q`ILU<_4Akd>3m4?nXR7<`gx9i&e6{c^wZVP`TE(YpI7K-
zlYU;SpNsXgSwGwKvt2*C_0z!b*Y2!--mRba>*oXd`H+4-qMu*U&qMn8gnk~@&tv*o
zqj|3GL2cL4&qn=Rte-Lc+@znq`nf|t@7K=<^z&i;Jfxq8_4BBH)_qv#r=N}bxmZ7A
z`ngFzd-ZdNe%`O259sGZ`uT`{9@5Xl`gu%0>pmj+#<Y8mb~ozhViT^Po%*>$Klkb9
zL;Cr!em<g~Pw1!fQC&a%)M!2_9_w>SXKgC!Y{(^?+Y;T*hTfdBD&6O-k7pf(b;ox)
z3|CLY$*31ya>P&CK1iE35dg!B3Rt<ccD*j1bXFxcJ8R=<r)4mW=T7H!D8uV={Z316
zi?cp4=-k|ub=IY}IV%%l;YXTWJdJ|r3+dCw18}-{!VqBfQ8xpu1fv0-N&uL-j5gH+
zb~Z7vIbrOt$S38y9Oh{UGk?$Bvet3h@aMI5?Umi#SMKx*)Q#&3cP%cLFFSFmc(K@$
zfq^9%PZeLUGzk@?ZX6BTt5r52ToqnNxeYGg3hcm+(Tf=VwMyxJzI#1-VS83W^5Z&E
zDUammyCuI2@-Q(3mgLKEZ7@vo=hz~cLdxO$NjYdE_WcO?bxKR{%ex9WZ1$bd?071g
zf3-jhx7`f)kdA1t3*nP)TR(4s+qS>2M}D?B>1OCzHon$@9^3rvp}A0(^DiksZQHbq
z`j^xrjogAEQXkGQ$tCsScuy`VzfW-~zYkf;PkmELDdnfGKcKWvgBz(wD&WT)q(0%;
zj;>dse+wwUt4%-G;&~-#*p2&6tH$)<kJbmq;g9xV@nK9mwgY=y43-dD$hfx0YYwPK
z(pl(igl;dF(aZh07;5;&9?^mHV)qlRxwuw5KK+rY#hz&_c~NC3rAx9#)IP-)7zIIB
z8jqkokE2uO&$dhm{<R)Hz8xoM{WbH9wC^xC!2w|eWeA})Dx1;Rq0IxeWerL+4WjCk
zM2(Dn%de5VQSW#e{?qh-x_;K;IR}60%%|f&6aQ22pN0Qy{Ok0SespuzfnlfNZ^8(d
zY5A<jpLsOkProzqKTH4VKNo-czZ!qKTeN$HcDLclG`DDf@-5@vhCkuI5r5{*_D%l*
z{9XJhb1uN2?UiNSg+I%BpMJg_Px=qxPdK~rXZm;Je<}VS(e6LNljZt2{><l-_%q(;
z@n^Zdi9f@?i$BBP2n1e+=Nuq~_?f6{qS}|V3R)LNZ%w}a%THm~#Sf>|n{AFVgK&da
zvGLZ!r&TsSJ62)*`)5}M{}IH0Ko_07Z?0nHKUN|9#?zzWM~%-S&v)G3m%Qfc4vd0(
z66uKZ9mmHX?Csc(X3?Jxs@W!<l)4SFkTV<o=w&DysatTKxcDrS!CF|pa<+i0-Z)2M
z&S8y)?n4N^MbDqu5{}=1i&|I0IT!YtQDKytVrg>GD{}2$R4hV}@TgGQTdALAAvc)M
zWpJAu4RlJB@~$X;u;%G9*?2me8*GoKw`}X!-q+vV6;F3(3P$UKf06w@)~PKR?EC8i
zIGe*2O}1sbu&m|apBxfAU)P4YNL$ot`6ixd&$<)XC-&H1+BQgr(_YUI>WiE$*{M<$
z`tsCXYBgIBueWTgS2^{e^|0I;$&6a5(v_;Wa9KG}jFsP?r6cS@UmL6Cb73L<i^;)9
zAlF<S-IkjV{h5rvAJNZ4`uUW8njGE&952MEg8e+NyFkN*m|0sVPFTNFaKB#l|9<!e
z)&J97tXvPDaV9iix$JTki~khjH%G)T(H;jjXR_(O<d*h<&0X1@gQ3YU4UdmvaJmzj
zt=W{CgHI&4wQoseJMipFr;-DSWVWLxof_y!MKtiD^=OEuN3r-#XGX`DwkcoDq=kPA
zT9|NW3X<Gk4<X-8l=*=U*q+y6-ahK8w147SgAAz8w(qZdU_0N2{z-Ivah2B}6>IMz
zI~tK2Wl^}kTt{`4k~?M&#MF^<=;hYE0{UkXS&%<Mo^zZgD=uUfc?)RLg))fV<*!SV
z)nOcg5L3lRZNc$^88dMd$k9$5y#X;JGfy2F8s#yqC;s{A)c4FRRTR~Izi9mX;}d>A
z)?e@7_sf)OHpdl{VN4<Yozy&BR=*_jR=PZwp+vG)#PsK-daTP7HrSIfMX{1f{?w<a
zO-Rot`WLBY*4G#xnKx%_`Ycu0W?#2lt?(fB8Dl3}9eJ0wtmu3zZGXY_MqF_rV_cb!
zZC83BSAuW`T*}agyi03`#pIw~ht!|i-j`}mWqSIOJ*kLh;E}NyeyGhEc}3h3Pd!R6
zFzt06`h^zAsg)R!b8a*G8XvycCa5{5Agee!V!xckz0{~n_EnQJWCfECN7^7)d6Ek`
zTilB~^=jHAxN0nTG2EZaG`53Aqz~ffQUytH6BSDRf-8Kexl<w(yZrH>)VEj~&Q=OO
z2+gMrch{`K{AHW!L;PGy@=I5|KY<hR`?4kaUqykjuD25z#}<|VMM+DxaB8MI(E`d@
z2f!7ZoXzipHnZGHc@?NgiuS<Ij22|KWs{Etyp@lKfmAZ0;RN&VSGlo=5DOn$ayg~&
zi!}cBL75iBCvA<%664GA@sP|7RD=gw^Y|r@^6+pX>Mtc2U7snx{@K2P;_4_`-aKHR
zYqF@zu}9}ffzpNR(kLZl%r4_EO45Gtx~pV?Sph3!xB<{nT7;}@6Z}yxVNWc3&x-3I
zK1T)LP6U2UO-ILYupBQ{mkU}4e~sW7`33!>T`^dENBixD#Wnm3#=j4?TJx)M%KO<6
z-tPFnX|U0j^E2t)mnzv`F!kPb-`j_FzvG?1cmJN>AO3^A@A|`i?|#pF-}n9xeDHxk
z`r{8h_~DOybpM}x?0<dyPe1X=hyLu(|Kd}B`RV`t@Mr$&uRr@YpZokHk3ROdfA@ti
ze(Au$zyI=A{?FrIJ@mDI_{Xn*<D38Yi6_7H?eF~4KY#bBfBDyc``*8Q|33~t{evI=
z=s*AK$N3{a8Tsk|``I%`fBuVSfBCCl|K`|#|Icrq``z=$otkOWYiG=yRd>p%r_Db7
zjQWN%&pP{@b6@uIIp>}KiVI%(stet@^Ddgd;NnXfFTL#YD;6%gvgxX;uetWs*S%)(
zYnNQVblLJ7n&X?hx)VKHdi&n8wSOR)8oV=|$>z3g-?8(qH?`mK=8n$d;cvbBp10jQ
z<@KLnPMPxhjF+A*H?COOy6UFb>esz~&DwQ0x4q$(^&2+cdfTQq-Y)bk9{!@FrxWTu
z*h`rHgO>WzzX|9;YVPxXHDz9=2jKJVHU4i}O?f|)-mYJH^|e#*y)L5vJgbKAo4k;7
zoOAFlz72RcZ;VxDg>|%W{PJq+$7*o=cX_L+nP3qyD!49SOjhnLgvHK`cj+r9HC&Au
zX3jC2Ykc}8$7&osQOnJ$5g}I(ls_7j`5AxzlB_?Vwp_RZK}sz4Kic`Y=7knm>g3#8
zYVSax+wAIOD6OY1G<$yMkZY#nqgVtDX5@J*tc_xCY)3t5kC1sX87s&bnETJdmLaa5
zkR3rRAJ-~JU*(NsU=A1iI&JHPi&8Dn-0zePjIm{OBN$D<VkUD)Z_+sSeeOUh?eTr|
z>UqOa<H@CPWEr(zot9;D63KXS3)V^Y_L~(egv)WBtSA{zE`@c9$|>3=X_0T-uj6aa
zHm=$O+)!u_AjfYhVWlXnPTN1qd>Cg)HX^t;<lYx@KVrFC5dSIdUI(k?jc^~e!nsza
z?&|{ocD3>g>rX8AYJ@jx_X>n_4NbEZ&Uv!lQ1}B@IMW}p!Z*NuOuJ2a+;0Ty7qi?f
zf3M|U1NT15&GJ8Nxmmx%mYexI-}K?X4$el)eLLJS%gy@jvfM210n2?8+=neU>EZle
zA3oi#cCW(BBg+%B+$`^)<z{{MTW;omK)Y9}{TPmux7<uW=LyM=;Y=U1+)UrA-Q*Y6
zf1h@*#)?#iKce01)SeH=c_QRKX1O_++W4g8$Gy6&Pp5Xb0vh4%v)l}S#B#HIhb{Nb
zaMyjy;A=hl3CCG%xmUuy!*Z{Jd%xvwh5HH1O?o)r_TiBq8!h)*xZ5l@>$Agh6F(1G
zZt~j`mYe)>%yM%r*_`kA`H|i+%gr@qgO-~!n)|hTJ!V>1pF`SB`VoImdGXgdioYy3
z;pancc)h4D;@rND>H2b|DZ?86N$`CWxR3a6)NaZn(sQxr=8iMaBNV?g<i20KDSyas
z`?WiUwF1QdBVPFJs(pPY<UXw3CjVn0cf&tRdD~E0@>i2~lm4%VyIH$$NA1WDo!b3+
z-5z&^!uN;54`}xWv`4ll!#@T;M|HSy&-t#D$KdmD2)_U^q1Vep&}43wbHmiAl3r-o
zpEJ_zA2}yTP0(E7cngchleO18D}^xZya<as0Q&(y93rLSp1)uS=UDwxQ19+V4F3|h
zth={ow}So)k%}7s7PTIQPjiLiaqe*dx+u%eSwCvQ_7xSM@HpQ}4b?6K(}m;9yftfS
z)?g4%{>7c{98GW)O)*?Cc92R7kw51E3h7%IkM!}caJb|tXBGId3iAtcQFJ&<vsu+5
z%msz<Wv!T>W4K&gXCyNf%-O%f@se19WMAQMIi-p#&A2*@<0@$pb{f8i(~)j6OTzsb
z9GjU_UU<eJM<>B6oIVH6v#-K%n<|C*lWKOoWkkpk=jfagj909cIeLU?;Bh6w4&Z=$
zCOE6fRdm5C2sfi<%k6y%Jd=Ve>PdNWr;!T5*6jeU9Zyyw^r8h2Kb#j&D6IQ=hvSzj
zXE1(YImve->554-$(!xfmuL%7Hm(n_Yb^1&q9%<nj!*5n7W%V&^OPFm$d>?7@wiJ^
z{JEkkc!|{Ex?ir`<O+_2k{p!3ccBDPGMErD%F@7ja7uYnh%_eFDVMlPBzT46v+RVu
z4SzdsIG)JA!j%Vw@nj_uInIU{6;IZVaQ3pW?S|uXb-Ro$P0uH@p7yyGc1^?SWoJ5D
zJn8CRh4K0!6WB)kfs@klNiErFBJ{U$$XvqkrT=2@K+5{EA{>vs0N0d+<#S;?*%!n$
z|MnG*M-Cw@<|<{jV;7cFR*8$Owqu6j${DH#roVryFdpSY&I45#POhgFkCrmw2wN71
z;}d_<R)YKD!trPuq*iekVpC%&qz~IT`*CSMvO<XQxYEYI!g9j&1Ev=a%k^MC?!(!v
z>P8vF*6CkHzcA(NLW#+<MrShpOt@S;C5ZM!u8c1Ro4Jth`c?gd^)mX@!jMKKYwi}R
zQm`%9`PzLmcPYB6oIz<r|AmqMKAjgTT+oK=Um4`ZorrNQAxri1b~x843pQ+c?DwcA
zP&O9o34VIPKsbG&zQ7ey<kDz;f!0~}G2|&iBv!U4sly#n{uPX8R?$)J2d{~=r?Fq)
zzB;qQ*4K==cAu-FNa=D`QH9sXl?ypoH@f8fC+aI^hg>7dfPK)4YU@#6^3ihO<t~gL
z{W7jYSt%pAE_E!Ya#fN?;YnRwZz*ea1#caoFxw#4(90PnW>smiGE2RQ?Ig-SK6vIF
zv8#%#IW5F``977<X9eiP_2O;7136-%X%mKDNEe<5#@610Gl*oZ)2l1QiAilRv<7uy
z3ufLj^THi4t?=V2wKi}kd9oFKb@Ua5zwuFftXLgiu7$W}3$nRe+N#JqmNCfTqs5*`
z{x$TXRz@ByMX8$*CmX1Tku0keZ3onjai0Ck{q^>ad7<}<nZD7|HcZ#TSQAOl7PLIG
zCy5xB_PNkIW9;To`0Ux|&z{wAUG40;g|*XbXE!v|y|T`3nQi|e_PhQ1c~n2!4vYT*
z{dAueckK2vnri@{SGyn4Pv-{`-lm@q>!<re@!zGNhxK!xhI3528-675diB#T<7n@+
zPjT(?0Q#SWYV68!Idv#%E(>)(M4pxz;)USatKcvHLdd1ynVoC~&eec*bs-qfrxZNt
zFR5qHHpM<u&X%;{U*$n7d>K1@YHZZ@*ymC|vvUlt@wRg<l^^w7wg75w)Z%&-9XM_z
zeSF*(!&xc#geexQEdhAp5|@Uv6D6W_=I#emGEy@d+oj;iNvj;M8Cc}7aH$+ncyxZ<
zp|B<+XhM<_ML`m(M8jh_{5C+_2ghR^PntF&XTpwNR^|{5pRi<AHg)@*fSSRbw4rS+
zd^&NE@`X6D`HQ1`;xO2rgEbIaI$O>b@G!q#Qo0@{k8<D(Ed@iYQ(>!&rmf(sTaDI8
z<!da-z#4F^x^EGa5=G;ezJtJl=#TxVUvQm^UEk=IWaw?mP;8%N?7Zmxr9nIy?C~56
zwwbZ+S7BQ6h&eyg?AH=3aLqqYH6r}dJGSHukCt>|6%Kc88SKlntXt0+F}Y^oQEwc0
zu1F0G#?y)QYFBKluboZ{#cRd(jP*M+I2&qBid%RxIxf%XILm@}QzF~amF?S>xUDbQ
zo!V}N1oK6_mGNw1RVqCY&szDO63Q3xT9fh3{fX{P>$6Od;6YglZ}>aAF#k32j4nf4
zYA`n_MF`giaHS%vv2o4HpJ#=H>eH4^btN(xsSpd%hqJ(V&B7mW1T7n|eWNX%=<3TP
zS~5gEJybOBX5$^{7@?s45#`*NNu*aMdg8f$UF3B*65RleC@<sRy!kDOt}N?D{G!0O
z=>!q@4I*}JJY(COd7g}2?r`~5XKs!6_jL;{t%8N)ty!@)K4@{-^bp)ND^{=EkSYL!
zT>!!S{TPUiG`d>qY#6(ojF(LWs-~ib`DHCA8{d++F}0(mM7UtkD2cbER$~uaAL@RW
zqJ{6jG0EL+eu$hq(=s^Nmg?{8+6lsIhT4!wV^y7^&e}w_H|3cTc}|TTe}g*b(aTSz
z*nkCgrtabR>w8n%S0=V4`cpV1a%Eq9OEQ(o_H~))>Kq&!zHl~n#jj0uC$u20MQj_N
z>%p(87-#@pTW`YAa`9v~;T1uhrE`XtgX2h}Sd~jc7^IR-*IcK=cn-S1Uy}Q2DdVEo
z@LAx-DPK)K?U19ABTru!TV;8cEU|M2Q_-R+tLF;)?(y{prj+fF`R4q4zqIKxR<jlB
z*Lq(O-LI8c->JSgkm=i!jQ9V4_TB`r#^dWBe{K?y4L4#*Vv7)hBw~*x&l9o59($Bl
z79qB{_E0KPt*9cD(%K@H21Tm0p{fzPqCvHk5}|0T?M-5d{Xb{soO_>K_a-U6@B9A0
zKhs_(pXZ#JIdf)xX6BhG{E?n<oG$W}#_7f9s5*CFw*Lfc(|Kg#>;rgn@MB{!OZO|l
z`Ud!+5^U~VHTo_Y!lD!4p^t`<{P<#a=Dw=@hw+A3V}aedmeV7?Ehb4g9R^m7D0Pzb
z_%HDuNmTk<V4^mNiP|A1sx{$znDG5g_(3N8!ns`-b?(toV&9KTJ=*q=Vk1P~%KrB5
z!~Us<qU^c%1ojVM;CJrPo*?-1W+M&*emVQYJA!(@coZAE7JXj_oQ4kjwxMLe3Lng$
z!>THLsSD4<$qZuENW2>qwt;wmQ_pUTbxZhy9Ojb>pZ5dvX7C<wo~u4X1|-$*h7+Vg
z%qM*9{wDhi(g|z-W0;=eM4Xxoi=8vDGu-%2NheE<W|}}MCNlp9V;4?}SyVD@#h28^
zcMJI56;>PINgMXB*rx*HVK^tC3F<8F&VV;BsL^z1lFYbpOQgbn@b+!Whg%=uY(A0h
zW=KmqH*PM!>HH1#NZzb5*h694!uhS^GvOt*l<0Y2O@rRVinbQK!Hd~hut-T`0V|bM
zR-DKMy*d14*_Sv^%9G_t1C|5uU&-&$FlW!`2LAr0J+S52)wSc_l{ffK1x}c0iqu@G
z0=}g?M%B8TD?bq`0n7TAtY<Ae&U!vJipp|4&)dn=#t;Vdy3m)3J#2+rsgh_~l>d@x
zAW{PTcR$vOL5m1|KD4<|4`Jt)x>bhO5Ke%AwgTEQ=+BG#+FhJ$M0;dtbW>O}@x>C{
zqtutRSK@3XvM<qB+aJN)I;<_j?wO)S1+f0AmbH8{MM=^rT2x9=VQL%)!i=fRdl9fP
z%_G8Ur+N>LAH!-taIQrpdnRVj07bBo4~?&(=811?)P7!lJm%+&3a8XOdbRlrwt)PF
zyem3?Nt=GG>~&<84`7ypUNBaw%R+$C{(OCaT!Fm_u(KA<h7h)=_#j`*-J~{^)s>0t
z{8#v|c=z)8MBjsnxjq=#!a5zbDX`izgw=RRHKbX583pUQ|Ff3xEZ!7mC0^b>=Iaa8
zQS&qPh1Gbu@(N=Pm~DphlAv#a)wYtARTw=Q<t?{Iv1}hdeCO7e&7VViO<#+`h)(47
z^Ah5GH@fGp0}G)yTlIrh`FZzp=?CB9eN%m(U(s&}LI=7BtPihEz1hFiSHa2i&<dM(
z!&tu}_|zuSjehOf7aE;dU4WZpLiyJWq8IAPR-`*HYtgrf>JVUW(mQ-ViLe%h0r&WU
zuOX~fb!MyG!auYSmgGP>nAN#XJf@-~2e6!I&(47qV^B-;CgxLbd}`T#>>ZM|T&DIL
z!oL5obnjbRW3ViR@J=(9wKDMD1E<?{V^3iAMZ7`5t|EcEvuCh|XWYA@zG<!zf2U9d
zjDPltj$$`Nc(jX&h>eQ&Xgh(;(Za--N5=>@RXntn2h13IsJyj-tJ%!ld+FoRZA2_e
z!rVK#=iet_CsaSCCya24*7<+)ZoDDw#!qY?IlOnYZtVDptvtjGvB$)*V?9QXjUDbW
zcDzUDo*o^>j~_dpQYxtV^p-4-z%m_KUelYpct`YPUj{+Gg1u;*2mPS9%@;<J@Gj)Z
zeu5S!4Y!Jx{0-SyB8Fj!5a~31UK7ng=@&B%P-4Z-w~~}m%O%6IzAqD>C+j6(lx;3_
zSib=Gvf;;C2;Xahx7W~m9<4mQ3`<6Z;xq0h1gnVMg#UMI3s?Om^|xG3%;gWo2t6>|
zvj(FM$SW~6g<H*_?A2lU3!_77E6v%lG3Tn=%Aza|XOF1od+M>Vt(d<cjf$o)8i5|V
z`22lduUB_lD9j;>JuL7Z3cIw$&U$!zgLVc+-(oc0hdrVF8|G_D(dngr@#SteeKCED
z(yXZdm)0b~KlQ(G*YAI%|7G?Tv$~KI?Qr!6_TzY%ZTHo8%tL!mqYDoUiEYDY6JY!y
zPUAD)zN@;ln)!tqLcJ7)1^u}B@>;U~`_+}#7rouqlKzy^qFYpG2cGYbAyviovFaYV
zB=RNilS>k_x+oMUUsElt%J2WF{+r6zi^K<(wbX-C|NZjeoA1HB*q9#L11~oIg1LIg
zaq+CMK`H*?+k2>i>R#yoLhZ3sf6Voxrux5Fe=h6={kZ7SsnvzmCfI`wz0v=j-rP7o
zEIxmq@6TV=`^}5>j{mMVFTwjz>}1$+;}I3Z_FzO!j2=J1V?->zI2EoFYGgjYO~-8!
zB^m+$C&q1-_A8`UcV=(Y!j)1b$dddmCLi!G<n3yh-w$Cae19fyF8r69Pl6FO&8Hbp
z|0>yyydtr$HhySx|4r=dd=S=0z(`h%v0&s5X@akoU=|u~Iu2%3thm7aL=%|2XkVbE
zfjv26___hC62KF&h6rI4=F+|f<9uLIZ!JaKH{#(eWt%A{_=sr(sd>@;oG`mf=gAvy
z6EA8eAJ%DL{0}y>JS!@(xp(-6ERxxI0<-8OX3=5H$9SCS8OriOoSskVAPOreFh440
zjbWS$YXD*<RXh{<J%oh`b09EEHkGHa%u!2Wz<OvTo5O{4!P_GAIIvR)?lw}#K(W(1
zpSd{H&m#Dn70mb<@4hg`L#GH*XmsN?XsNauS*z$W1o1+iz&EE*Qo;TrMNn5G*mKyQ
z0p&%!)xo}x(JUv-=M=>WrC+@YP_zz(%LkkeApENLYJ#4^j-pIJpDuPxz?jK{?YgG9
zV`@>shj6d1yn~%!lnMLaiz@LVUSU^~Cv8N%)i4-e6LvQW2YW^n84f`Vd~(Ki!Q2^r
zGz%`i#<Oe%3hib0qlxx>G_!sr8##|-77^>w#oNOuD|CTYWGJ(xxE%s^tOy6~ESy_I
z>tTgY3N)sJ{`$B1E7pTe@AHBBBidvr?Za8x#1oJ%*-E8YYlPcz!3V50QhLN$_S9pT
z%SB2H&|>y0j^>-x2ak>#6QL6)Qd&5T66y%_F(N(CN){Kh(Bj|PQ+&A~?g@eWkc@G{
zUVmuK#mNg$uZu4w&>orkf}L4pP2j8JfSO-)x}ZFX?^dbpG{2w0T)gUhp}$|HeMCzB
zt$j>=6}C^w%FpoViJ~OI^)?nt(5om9>V9A_U+1Q?QK2UhXX3yvmWX1@M&W%w&wsVr
znUymLsV!v`QnHqM#<V^wmtw|JoT^E?4GZ^NQ0k!8iu?RbdFuYil&AJ5#(O2*efP5M
zvlyis&jW^Ut4d;BINuA}U2*ft5dKXTd}jr<t*}$4yYOxy^Sfw@mWSMdJ`&DmfzZU5
z<M|zt(D%Z=Q#g%C$U_>%`WCbSFndz8jX_H6XM$Z_@J<4|aKt!K{Y1z#VSC*QyTW-2
zBS=drE9}p_U5zrMSxJQ1@}gTYqx`FEe?&_Qwuc_K=+>FqN0L^z$)Mf%5~jm69AnDF
zU#~uWqJ1qsg(7~^&*-agN}uN!PJsrYldqP4Hx1wUfUAHQ#(LnYB8Kl#z<DF4xqtw~
z@SPI4AjI%(7Pt_^^nFe!Vtc`s!VuG1dN^W7<i{X}?}otX5YxP89Af(RB_1(-JClf5
zE4)idh-p;295H=!mW<d1<x>$?K%9oSBI0z!l@Mnjc13&?u^Zwn#O{dCBd&rt8!_C)
z4el1=Y641n#MKcOAg+N}@)P;#f!GdlO~hKnv~P;e(X54hSLD}5?19(|u{Yv6i2V`Q
zMI3;b-ll>O*GGN`;s%IA5&IwxL+pz<9C1U$F^H+%(;;qw{5ZrkM--2^CGryy)2dJs
zVg>oj5eFeoM%)&0D&lsC(-5~uoQ@dII0cu1xRZd=QN*1QXCdx__&nmSh_ey*Kzs{v
zPsDn}p@<6*_eU%>6y<@|`s@(H8Nc9M5!1dMZ^SbNTiQ8ae5azp1|R_WR)|9oTO$rb
zY=fBYuPuc*2Kly#;}DldoQT*C@p8oWh+WqReH;;|BHsydI^r^jk0LIM_&nlrh;Jd*
zA}&DejF|4_EsvP)<#j=9=P&GA0kJFMiio`tS3(?s*cEXIVmHKLh}{v#Ag+Qq4slh)
ziHNHqUXHjr;#9;n5T_&dKztN&O~mIBdm_GtxEA69#I+IIH4^FfLhOpT4q|V_brA<3
zu7@}Taec&Lh#Me|LF|J#4zVxd<%k<1PDR`paXR9rh>s#}hWI?<=7?`0Zh^P}aR6ew
z#v;8f5xXL8h1eT$Ys3MFWyB$f6~tkPgAm6cZi_e$aXZ9`h}$DhMce^#I^vFqk0S1b
z_&nmyh;Je8g17*2SHyNrM0&d+c17F+u{YwLhyxIZA`U^^8*v!o{)l4`4?rA;_zlE~
zh@%lNM?4B~D&o<I(-F@?d=#+;2O#GW+aRX<wo4<vg?xL&1&AFG+cg#Ta6;^gSc}*j
zu?yk=#1#;SAg+Ws46!@n7{qiMP9kC-<S$3u8gV*e8SzoX?GT?wJPL6EVhs+c?3#)6
z*dTUATpF=AVtd2^h#e4zAa+6=hS(i(4C2;^6A_O>yd1Fx2WY8?Z4jp;E{*soVtd5r
z5j!Bhh1dyk0b+N=cFje4TO)Qwtib`EH)0#a0f<W@4nb^>I1I4^;uyqEh~p5uBThuz
z8gVLO4GtL75!)j^ir4}1dBjeLZy|O^T!6SWV%HWTy&4=)dLy<+9DvvXaR_2}#9@eA
zBaTC?@el)qM8x)pmm_vSoJ#%?r<4EM!v9h7kN7<KM|_L?BQ7BS-on3KfJmP`Vpqft
zh`kYOe1v=e$s-OSdBkBP?=R$INFH$<$s<lA`KCgCImshVC3(c@Bp)E;j}jm8dE&Pb
z{9D9FTtNIF!MAHE((i!Sm2i8(_a+=7Z~)<M0*4R|6*vsB&2)id5W6FeLoB$j|9x$N
z|2_-A9#L?SY!(k3%=eL-#^#TF+5SawD-iI+%p;sD3XZ-YfisN3!OX0nLJn5o!NCc)
z;NYYQLB*NNFoOsVR-(bdIsD+@%v^A>7%r?pf`gkA1Qqh|Z8<nP!x_#w14k#BPhhKI
z0#D`?R<^*wdI&gJ1p)`FUf|$<0&uYQ3J!J|gM(AI1r-?9VZp)q<lti1>LWNf6&+kO
z3mM!PmJ)Dq#xJ;0=nv+^!O?9KaLyLEQ7AtO!-Mmk!A-(&VVx5ke4hpm&dde}^R<Es
z{b4^SxG@HM2tIsy4-RhN00(v!8gj_An2J6Gh8bCra)F_&_~M-{@C3??FI(fL_kAck
zzU&*FK0=(A7brjU{te~EmwlH*@B2`G0CzxnC`Z05wBCrJ{P^;(gTw<UM}UbB<;j<S
zJ0$pUZj~=9t^LqHlrP|uK2Xj8_eDOGFJJbhP&WgP<hUndC~v;(J1649ZV^Z?#Si7r
zmm!jeatN5>hw=#ekUW%2upgx#%BL?|9ii|iFlz&!>;dJ~muZXL8H*jl>uU%P$}i|g
z;Xyfu^kH|%w1N2g8P;E*e1rZ2F?~?ZAwHU)f$|RdNAW|s_hs7A{0f{60hsIu^#J0d
z^g(^_WzsZ%1N8#Z*B#@7`T_V2_Ai`?IuXkwvU$BxmmjD<zRWkJ59EEB@3!b6j@!qG
z;XHLUAL^YNL;ZvDMd^cj2<3_L59%YNhx8xA)7#yUUf8Pw<%Q(M`FPz8_JsQD%e1BP
z4)qu?)eor8fGK{c*N{J!>;d&%U7jL&`i=TQJD}DV+5<I)cA+p9^@Y+0?Sz^?hL;Cp
z_|Sf+`LNeQjiEh({GsroczWShBH^H&QRk;<Z;T;`_6ACzD3PMQfe=NBgEPUwLcwTp
z_~KrjpRg_g`9by;?Neu|7sfBz7wEr)gZ>HfpY(%WLJ(UR@<sa+Y{(zcUKst0_QJ@I
z<>492gJ>V%7B%4}aQpRPHPn207xf*!eiTk!KicuOShUl~X4*pj8QTX@{(=qmSC=Pq
z{>h#lSepz^*sFt~e2V@aZpji(*srZ2J;Hu%4egt-pRv6c_G@RTpX&6R(?_Jon10eP
z6mvl6*UeDBgnoSt`U?HJsq}&THO4RW>txWM^rP}1+UH=EzGK)J#8|^c{Ot|pOT-V~
zt*Y(Q&5(b>KF0DW;)kzUg%j}`^@aT{P`cZ)f6cXr6Ic%p`cRGwec;Ro;Y56$4dqqD
z7i!>(__||m!?*_ObJ6iZ4W|+<;_GWDUm`wZdn@8=Z?K0teDnDYCoPz!rzfj{>hyF`
zVX#ksL;AoT@PtZ?&~KoDFZ63?Qoq}&^b;*sVgJ<ni191fhuRaeC$-lizAlFFM0{{d
z8|e?)wKe3okQaAyf&|%*)+a>xR2!*2c4gl!Q+QCGLsjh;gx`*p72!nqZB^+9em_Hf
z5&U2i|Dh)QUWW1_^r6-k^o8)?Ry)!Mu(*>Co(R6UgVKoMRy^U1?+?O4P(HxXIt#VK
zI$X!`5#FTaF5*33jNT=Q)@_k3r6K=3KFC1)3*s!qUm(s#oQznHcp+k`tBCIh#9GAX
z5PKj#gV-POCd5IAcOwo(d=POs;!B8ih-qCd9`Om}Cn5e0aWdkgh{Moc^$@2ae+A+!
z#G??qqI^xndgMnTrgd-)VyT<32aO}Oh-V<*1M%00Y2DlkaS-yU-UQ&ftqt-+kx%2I
zaKv-SKgyRvtV2Gv+abuOb@+JXr=WZi;zfv)5mP^#hWJb5XCU5!*c;cysGZG1{ygM|
zV*I5MXCt51HN%i^hkQNq*CCd=3;Ui#tVR4eVh_Z}5c?xuj5rAK9>k%D4<Qamyc4kw
z@lS~35oaMzLQMUBGU5#6ry)LzINVq0Z;v<w`KJ+QA^sI{HsYTV>k%JEEcFoK?Lw?Y
zydSX#;vW(FBVLa<2=P|Lp@^>_4oCbEVjbda#PNu~L7as66yjvWR}rTnzKA#j@nytW
zh%X?{Mtm5tx1UIFEyQ}{M<WhLKJ6ordJ6f`$PYq(9mHDX#~_aJ74i;<J&@lGaXk9>
zL+p?I35a#*-w|;T@|PeEMZ5uVIO1*OA2Ido@rb`deiGunh-uxP_9-MIKN0z~kDvwO
zH00B|eH`lRg!~NT(|buGrne#TvyeX#@p<&`iZ~nj+Y###)3_iW<;x&n3KjP5i8vJF
z^G2*i{z$^euYuSD`4NZ{G5oTK{gIE;)`opO<&YnQ{H2IP5%)s89K+Kh4o5!q({ZSe
zFY<NB7rnJ4Ek}MM<i{gF4l(W9XoWZl`3Z=VF@9&nb`6ES6yl@&T*PUJ`w$=FZ;Utt
z`BM=GAm0md7V?K9_D6ng#M#IfvvTadbi@mgAA|A@5KFy;zGDz;5x<ML0ObP_dm#UP
z#J7;&8nHj}XCqERzCYq1<gY>;ig*g*aKw`k>k#)toQn1?k2oIrA0tje+!t{&;$?`_
z(7y{|<j+T(f%-NljQn>Hr=$N0h_jI2pX8BW5pg#12O!oXUXEDmE$sgxVlCn|h&>Re
zB0h@YS3>NM{4m5>$ghkz2>D_bf|UnMUmN6yBL6+a;fOy&tV28*aXjLch-sgj8{#D7
z4?^sL@p&RnM*dL5X^8hB&Om$saTek<#My|`5$h3uk67v>?0E$7EwqO_VlDCqBc^q*
zYluCNpNTjK@wbS>5pP5skN6YBdW^3M;$-B1iZ~7Nn}}1<K1~p3Ab%QSS8Pv$5N9F(
z1H$M(0C6_*;}M@neoMr9<j+D}fcjQNEcF%kdke7^aV+sMylRL&kUs=*I`W$#_DBA7
z#I#S*191@YBN5x7|LTZCksppY4f#zGha-PA;&{YwBMw3Nx`>mJKLT+Y;<1P`5L+Y8
zLY#v*8*vh1J>s>9rGCPGI}mFTZ$|8axFceJ#5(f-n!dKcf3XF`x&_=sC7hVYiD2_B
zY8=T{Kh$_At`gEb5`34T=8wSDP~wloRY=04aJ7-}Xtutm_CK1<NUJf-<*6}ztD?r^
zO!%;RpytEuzZx4?gG74a3{c|3Du9?Bk1{haE;!;}_(s<llJGCqz2G}q!mw^hE8eh<
z3G;05RUYwSo(sP6ggbto4^OOf!t9rDur3bwol$=TI{Gr}ll{cH=TNpfB%GMHhH%x`
zc(1PD!@p`ieBoIb)A*0pO~&AAtyo8eTX=;N^Nw&^pc+RS^c8&L%0FS!UtnW;1cvjB
z)!~ga<iFq>Z{!tNXDF`%(`q)&i^8|y>hO%^U&v20lut452&IJNMSfBLB=}J*@6>$w
z>ZdR+>>uu$QuE=P(ZblMAH)aWpsD#WhVmogAH%+8QuE>K6*Z<+e40mvlSd2l3+o4`
zk*N8wdZfmaO!)9M7V%*nF<OOTozPf*#X2tBRxg}bcc<MOuzv&ANom)D*v|p=gTfc<
z494<9nA#_S;a>_L)*;|705u+Cu(wz@H0meTHI4OCtoy_F_`->GTQwiThx$u=z_dFA
z_FX{w;a}oIeT7pYgcIxNv?~Pmhd_SQZWXa#McgAz@?c-u#Ul2x__CE78n1|TXE;$<
zII&JV%25BrI;>HDS|_C^fZ^U|vY%L29%X3X#k#!lCQz|%PrFvc_lv%)bW-~y*41fu
z3h-f_mSO`8?IHXtoLC1|^F@6#@&S)Als~a<4*v=l%kl!^r}`z<QH|wCVEC8hA%3+y
zgl}vQ#JaapAF)q^b_c=!7|0K}d0aSw;a}lsoe}P>14o!@JYlMlVxI@?HWK@d#BFdQ
zJh3ir)JLpq8tae1#`Fjb|B`>$H$c0V#Qr0|)Ly{47xYCG0$~b))(O>oST|Jj!J?!Q
zt)m$+>_dUCe@P#zKTyhHPY`jQ=bP&v#X2CIeP5J+!8h+8_MMP+U=P5Q8o;oR0?tbz
zeLzQ$5G|zG_h8HqI4MJ2zQw*8+6@N#r@%VK@+J1!&@M6HLwTZIX0RU%@(XVB6;ABK
z(HZ)8u?{c(HD^CH-(32|KAOo)E8)aG7o&b+T@A(yqDL}fQNjt6e}Q8R`Uwo*6$>Zu
z1VeiwFr2bYd}uF?@sHtc#mk&m1APU2y*rrw3n%x(sS|J$jJQ7?&N6{BZJ<SnW_b_e
znWDdhMMaSm{w}@!b76I3YpAeGsxRYoV?WY{ZdooInz{4R;QRvfH#Ea{=TYpx7_%V*
zSN)B0J=3T-emVP^es3;LK?nPa@9vAYWMTV>`#gl-VJs)${22(X@Tm{#gs4;a{P*Z3
z{l46rl>)e53;I>~8e4tGPGJswX>Pn-r|56aK~EiPTOb`J{=)mZV_z$tKy8%oTSrEf
z5{V7^<FAPwvsU`7aRMB1clVa>)(<|ATQ5q?`wZRnq-m*xXXXrB{Gej%(d~sF?S-W1
zB|gECKWjR8ep<Os-JURq8DzDz^!~a1Yghg3;i2JUj!w8VX6v8hHQ-_YsiAdKqK><+
z|Htd?(<gQRTp3kE{$te;G4XOe_UVC>Bc1jRYh0tHpS4woH@phYjO*Ve^T02qB}u!`
zFV(Kyj?L5EYc2>n^+CSlse`lYI{rERz!I;moy$X{?!W%hcg>0KA_iXCvSsiQr}m}p
z4zINLbnoq7KdLu>Vfd2z5WiH@>4R@7uV1je|E4vaY@6@s`eyc!OYshypX!4yEJ)3Y
zcOO-Y4U&fjbZh+akpb_X3+{3~!gJGwKy90E$LIgHXkx{I8D%zByFL0seeKyBEHv$V
z)dxlNj2%(`ZP%(fp*9Vg{@U>Gx}i~@j61fm((hdsc>CE^9vj=)J=P7Z9n`o^&{mt!
z@zo!kJH4ddHzx-T``E8_%EcKEqd)I+dCH0ukF-7yzB|0dYf0Dc*KDL&z6T!N$@1(S
z>Rs;Z{5+QdE){|=&3LorPoKCAET|f=So*2Lm+$YMvSC`p)33{qj9@EU*PW})AAX>}
zM~x+|<~6rpVK+ke?Y`*A9)BLJvtre);T2=;E3Rsg*La*uuaJGGQhw{ud!{=i;G4K5
z_pLG}R{2nRQ=c~J@Wo9Pc3;T3GQM1Nx31n(DrMgrlewr}uOE&rt=n%)&QEo3q^{if
zMIiGh1$D`~eMg^IYv!Rb4q;<$zH4{jP2YkLJLkWv4orUNt-o_p+2H4vJnpBxbJ~xX
zp^1H<UDe-x>ZJ7xCF$yp-EAf%CVW&$IXSA;&bgQ8thVdep?i$e#*0rDeN_93%k3Ed
zy6ty<@^{-=UmZAZ6_(p8=0b|s<QenF^<X7v=%X9&zL8gM>wqQByW*u`yXtxTaOTj@
zGsY+zs&@bS<YnEeUjo}!`nt#QtZ~a-uK%3WDyV0UvgN_pDc$Sb*zN$OOxvj67W*?{
zP8+|k6VZRpyH!W-zcXjj<Xi21e(03kc6BMcW3ug@<XcC7xY;k`;nf}OHUFf&<57Ep
z*Z9-39;9F2R;ps@pvczKdcL{-RFk$jJ;#hGS2M3k|KIw%?Dtys^Pk?c|NQvul-8ZA
zZ}Y9u$s=Iv$EQy{{NUor%RS!Di0QZX%@I51wkcnGT!$H2c0*;=x?L*A4%ilXd-Gh+
ze|~+G^40Z!u2#<bc36}6#GNf<pY-n*UH;t7Zs?sKdyIV6tnA4C!z=8*7<9aK{kWJF
zjYnNLwEgbh5ku>+^jyC)B>vI%)BXNR_2{yqV8F614o|mf-rnfbWyI3&s@JP}@W|#f
z=gv<)()_ejzh6E|T6N^p)bG1`xlY!Xu}@6BKT%tw)nn(7-?lD@8mPVb{jysley$^r
zzrOSR%}IkiTQ*rasr0n2i+=CqJLN&_r#FKfD;+FY?4;EX$#Wikz$<v(gJY`}IZoI<
z{aLB^eA}gsnAE`6XZC=N+J9<fNkP+&{1%yhYh>bi?QhFZ9zE1=uD0J-1G9eI_b9AU
zLb|nEhi=v_k9BwZTsl-EC!^ccweiPVpZ5LY_X5u`Z+$v9;O+BnQ%{Ybd^m2+?%$^N
zuwHVVHyx6+_V*tLj~+YY`ih$uT0dAjHgZa@rt=Qp8ra}+*yT1qggxu%S#kP+)Pa+3
z*6A~RO691pZ~QsL;mNfTEpIhxmRu@z&hAF{+LfzO^J2R<&VPKj%9a#2CB}vsaOl$+
z`x@FD>zel0-K)R!Si5k-Mf>Y3|L!@w%$kaue%iI`UfGWWCM?SA{O5^f4TdaL0?OU{
za*;=c7ICMq1fSl2*;B4K;L7$7hWvJS%Dm$@*A433&^oZ^&0q%>uB83-PH+1TZ(a@F
zxy`TXm+Qu^JE_D@^WJ%X%KoldN6!q;E=b)ry!ElIU-myb+HuvYrPBV8L4hCa>vE_0
zh2Gt7T^x6)X4MDwvpRGcd4BWH)4N@@Te)GyBq_1Yb+N`1wD?DDuFbyjLtUNrH=pxp
zOI(F|+j~83x$IA`ivA6{IhM6v+q%tD?>&zbr-Zdzoxc8h;DpS)j?<S%PFz^7rrX7B
zU#;`oQ6Y5m{4Fj22yXiEvQ1a6Xr7+UKND{?HMs>-U9)0kXztcaM|`#h2DIpYctY0j
zF@M;muIN>eXMHf`YVYJ$wX{EPn($uxJr~OVVC_0bx1!ah-nV-1_^rpI%B34_?7r{n
z&s!XN{uTM*+qZY0su?uwN9o;)Yi~@tb|SA{!`ZXIHrFdp8T#n%*>QoBlYehmVaBj-
zcbfR+rsppxQ_f|?l5P`H%hd@Fa?!MLNE~;frtgLp{~Y_}gPo1O32xi%!B3-0%{!W|
zDU~z*uVuXtMjVLTeEyd?m;Y#z9ucEo^6jT5Tt=STKi`)Z7_G~#=F<+Zu2<=fgVH(w
zhm9MitgE$eeZruW6Ai~}o6T&$YG1lbW@?Yd-HvT-vU=~Hr=L%5T(g^B<C8A(&P7jk
z%`Xi8=DlSVf}gmb=veS;z>PC=N{^^~+RFWD?k;)TmfZ)&{%u!vpXfw`HfILSx-g}{
zC-CR1<CZtPdCoqn*Z5!EQnz<}qyA5)E?L!o`fJBi^J}}*-Fl|h*KXg~9BgpH_Uq$+
ze$nYtSNm1Rtu7r}(CbE{`2GhLq=q$Y8eH9GUWMPjd+PG|S*dbUqlQ0ees0+0(5t&6
zZJFI7(uTV`XwGC@EtS=JLivk|-<owft9C@>T#Bl{*QU;r73XvjAA4QP+&#&$LQS7)
zHNr=_q^Gn#Gk3y_-0&+uA3xmS$_U#QbJA=7W&6>vKVv()jlDSkqe%%9-)jD8?4d?q
zCpAA5?0s~>)NQpdmxW9k+IIh^iRV7?X?MZ>W_*fY;Js0SQ#&WL+jMhkmm5z!Kh^z|
z{m&1_OZ~il{<rK*%4=U<>aii#E_Lnd4htt9?YrRdfWs3{{CFTeI5z6SfD?muHT(Uk
z%jk$+2i-63S-NXgkKDDPHy>OYH#4eqgEb8=ukwWWB<<X9-)hsp#guCS>%I@{x%$j3
zpVjx*PdxJAz_OcFM+RIU^7+bn`K2G;PCWPd{x{@PC$_(*Q);X_JI42xlk1GiW0#D0
z>#EO!p&>2TE_Kc>*EFn6<(*6Jh1C6aK%MD+zs#GIoD|>M<*SRnNg+RsdB^5@?N35^
zoUi}+@3epwtD4qqTx(-5X>7_!no{K@jjgL>Wm{dcD(xj%+4)M=cFiPfds(t}2$5_Y
zdP_ErZ%Q^!BcxJJlcZ8*5~NaPlcZAR)=0MHwn?_yeUh#74^nC8Y^iklJgKxxDUF?r
ztH!RPug0!YJB@v%fg1bDI*q++qQ=2BS>xcgTjSt<R^w3RZ;fLWdn?DPURI8@d}`6+
z&~LyR`7Jh5(Xz$M<o7jFP;faZ{^R9r+;q2;bo^7=a>2uZb7R}H_X&8vhS?Q(<AnFI
zsqEir>@5>!c*IGuFe3`*(ng!TN2H|hXD|a1#olq@jSNnf6({mNe|jg}WC(9MMh?ss
z!p+MxgKE(PoKaGJU|t6FDSSSl>HA_7pXr77+v467P2UsYol3kJ7uHw2JE~8618b;H
zcvEBb8za0gd$M;s^XFRoV>B-tej}+C|LUhBi^s!kj!RObT5xl)aIYf1UTjx=TlO=b
zGKjAiTv5#3tB9{pvGKtT$geIw_=>1~G4{lFVm`YG=h;H7gt^qhH+!nf1I+>mJ?USl
z*KnSsxW5|e8O->>nZHm2#SL&Ctky%Fp2Rq<83#^59L~<CgFD`!wu}3`hO&^L%)xAe
zWe4-aW4XStG6nMpaQ2*fP6AGrh8hetTAb4ht9_!yfm2DvJ<B7Q6s+ojWKm9>rwljZ
zz?`Je6>LN&9n+b4mbi3&o~1Zmb^FnTo&F2=T8Z=ii)%&TyJGMmtmw`1WD@@yZ0aqw
zVE@7mzvj~h_q#psES;ww;N>hOqBzdsaAZk7jLB0Atd`fY9295MmTU&;)!G;07S@Hc
z0*kjUe7|g*;}mD&LY;zHYe2={eOk1i#?NN}KGCt-ToMb3@S%5tG9ykv9KtLQ^S+`U
z6^;UC2BA%)vy}^<M@+SW&ZF+k>gWI#?s)Et{D}ENy04JJGk4-+ap8%1Npt0}u-34y
z2BoHOD&Y)GXr<Jrd7JvPloC2S6TaIe8B@Q2p?95#?H}a_^xZTbq0&qz6Srb#cS8FO
zUru%B-#>R?bLAbL3))h>NoMsX38mHbrevi-tXIDHdHAN|8A=_Mtm117l}B}HgcE%&
zl}NY~UX)rYT`ylEjUoPL%Oqrzx%3uQCe`!%eOT#*u``|I3gyPq&D5eCQb{ErgbUYG
zbzv*o7HUcH_p5DhMb1)hHlYM9E}che^aJOW7FB-!ZTl0f>ienvp>yZ|ee0+WjqXY<
zNqc54okf)!bxy0}gcKAm8-?@q<?<7H3K*M-`-5Ru5Uhknmna{Hu{M(A;jClhO$f!e
z+EA|w`?q8pOYLY}9rO3ayqrBCJ#=3Pw3TqeG>lS9(k`myjd}Fy^bzme(QKu<C~Zg!
zcz=hQ1-S`+$ie#nv?l8N5Meg~tR}-a9o{{m?}PC-)KR!E)Tf9s|I4LMUH*o!cMj-_
zMGIO~8X+ykoEtx3;?NOe2M=NA#z#&X<`<>YQTmBmDp#p>&6g|k_j2h~moKQ*aI$yN
zDHSKagPd^c{smT<OWMO2!zo->DP5oq%{rLAW0pJ?F`g<uoZ@alDK>vckDbEucYJij
zP?OB{=B;H(HGrG!s8uIR6s9ki-(q$G+BUeOLm=Zx-9_iT(1Ugo7=4+Z?`;}tVg1E^
zi*~Fgi(4fc@$?#RZ#U&P=6rao7UO?YzVHuxaTdKPU-+llr^33JLoa7vs86&*Ma(6_
zx#_U`6-qO_7Yo}Le_ul}?Frsv5;b;=E@FIikvEw@D)r9_r&T|*FfK6R+Zou;#Qp^X
z))@X0e>~%^T;ZpB6Ko7lD*IcVif?~^QBiw{Q{iSy$9cEdlq#$Ep)T#u8sxp?$jiz<
z)@nY82C3xPpL&D5c%E&<rU~Ez;YL2kM)`i+oipKQ8Stl{fIDWuLjI5e^WX{=W^l^>
zdBXO4Jnzy9%S(To;9L`|H3T8-|7<2bxX~9h*kzFa@$ep|-&_M;(<`@ht<I4Ktbg|A
z(Wdcj3>d<JFeyAR7c2#u6a!-a4^v~lnj1Gj-FkiovFKUCm#gn$rYjcL4Pa&f_Fuv-
zENDy3IWa>jBw>U~JGMyH(l{WkzWMnrF+zg*O4yM{^OiJoVE*0Kyr1IdZb?TqeL4HV
z=n%$!FsnL|SrOjf#GDJv1eBydQn$FiY~Pu{U=6VoUS^|CC=-#419xxu@lmL;l`eX|
z%-HYzXXAkxRnfn_d_1sAQ{*M&GxR<%j-_!$J2po&gq=Inmz~T*-&m^i^WXjrZ?K|o
zGcAE)9P{EOkj6nUCNj?bnUBldyh};mip73WV~K;&P0??QaAO<H#)=!l&Ba^Tg7n^P
zjHBon{_on8Mp)+a+g$5WvK%OEFEN8t*jn^04@efCd!Tu#;&mz<i{<-2r3U{~?_0*%
zilW*%uq(6)@ZMZh$t-5PDBeHWI59e6jL92{u#BaCr-0eR8;z%)ABOp6IC~6QlG>)m
z6*y`2w}W6@q5E<BD4^j>cTWVGJbB66oOW+I3uvg_irGLj#yy<_G(PFAc|i3ezgYk@
z`CW%aK(lx4S`0L_=a3~pr9P!U2AXwX>oTDF^}Rm<>ha+2r$BWFmaPPuY#Xo|XxgEl
z)^M!ZlMK}3>YTMeGpzcha5}u^I-p6;e{mYGNnZ~*J0M{LQ0?xn8-WJBTj4XH8Otwm
zn)Ps9D#x2gZUUOM$$v9YrU$3er+c;lPMZJD=RmdR+HM7!JkDktP~FhOoThD?vmJ1T
zcWpi%)YqBKY0{Z%ocjB;`vUkuO;b1x|5MrlSlfFDr`a*zavJJi<x6;;of^lf|Jie#
zCU0-N6P{<u3pw?e^(UwPQ#$eSVtCDUoCd`|6?DnKuRvb^=1xx2el7boV5!0gPQx_^
zIQ8FHHJv}Vp3JGg>kpg;-Ke`8o+pio=QMfSc}|&q_Q3PxA&H#ovaWEN_PF^s@I34K
zd`|u6UgtFEk5+r(xz278r`qc`I8C0>=396ke{K<{((N0ZChu>(51yy>PvSIr%XLmO
zG6KHi@*jW5slRVFr^%Ua89e-+?Klnpb~LB)P9JkB1%Ah=w&yKQ^}){jK|a~F6{qo8
zk(?%toX4s5=9irMcf2HUqD>~qXMgU)Y1YoZoa)z1=QKWcJ*R0NCpb;|DxXu9j|ae?
z$AVx%vqo?le=mvCa7{X=+4{?z`X4HFkf-AvA5OEX_7OOFs-X7CoJwJbIrabWHm5-w
z%k%dY|BV5hhJN@Kr%7S6ISq2$%&Bhu4+7V|%W2jJ?uQ}1(DMqXSx(WM#(RGtXoKyX
zW>@@C@NX7ys#{y_2)9RYFsDH$hH;u4IFD2RW!pK`UO3BXsC5CS9+j#d1%FA-L7ZmX
zjp8&ra}KA{)GeH{^2cd%avrC;@|F1eS=yMEoW}1M%&ByBCa0kfQaIH;I>c$(&0C!6
zzjZtg@x{O6$7y)IUYsWHo4~0~{+LsJYC5MLPk-UmUw$I!h#KF6|Dc&|In~8SajGBv
z9;a#TKNGn0F-|kS`h!#dUQQ>#U+B-if_Co7Y0zgnPW^Ki30(I}PUAcO$f-8$E~iqT
zN+-d8c&iqImJQ=n`XP=}-Skg5O|G<u)2vm$aH@BH#Hs&;DyP6dt4ExMJ{iPmc%A8-
zX17@>XwY6x;~QV%G|Tz1cz(Ic58yxRlh&Lj2M^*j{=zg)b#HyjY0~N4oa!52;50d*
zfYZ=y$1EQI<SLx{+ce-*JGT|5L8ZEInjJTgQ~k9VPIVpQIE_!9!>Km!V@~~BZ{$?}
z_AX9CcOK+4{Q6nJce=)DMuR*~we2*gA^xD=T0sZa;M70Nk5j2<Ag5V@-8fCIJ&04C
z^+--be~IHXXww`{!*w5Xn%r;$r>uS8G~?q;PSfPmoa!%M;Z!%}Z%)JQo^YDH$ngy5
z6YAp5scybEr&_56r~aclaGG_h52sRtNP%bSI1M`a4yWNR^EvhCy@J!^xtlo6-u<<p
zIfpn+v-y$J&>A_MW;E7w>Y+U4RM*~#&&Q+%yK|b|(wkFl{pOq&ny+DcbGOiAhv#00
z9f3cV@oO@o+!uiZ&b)K0%+gbVBgRCwZl8ZPaDd!=!yj+l33UAKYMYpL2Lqiq91cG@
z_d(zqzZxE6BcBAG{Pvghc|Cs*tmq&7&-p}2-a56xMi(19`QX{VGb%4DC0lj=aqE;W
zTLa7bx6mt-%gP7t*>?Il@@im(z1?e^(Adh~{dTWccK#oMf9AVacbsM~AF;~N&0Uuf
z*z3puN%GUmWn)kNEe)zDZ{KCDtM~quz%lEZf4O^rR_^(SZI`26UF5BM*RKAhT_w5x
zANO~DHmsWb&*S?6**oq9ChB#E`~IFE_~r3d_V(j#<j>x$dvl?#ntXHjxGAfz)R4n%
z9X|W6uAMCOs3Z@1YozvG3tPEs<n&yZk>%x9k@2T?$oBH(B^7@^?O#D|l)O-@9aT+k
zo43bt<(x`#gS{Ky(%3x<96kK-$-uAb$v#^S?)9;1Ah(bHbw*a@2Z5_wSPuvfswjt7
znYLu!X(#!eP1EZ}Z>=nE8nWh4_e5toA<H)WpmSxpz^+jnKl_GqtE&yJ9jZ`S{<P<W
zC!c*&M}Bv9_O69@o&+v+?0#fL!&<V7)6|e#6CMP{h8?!sd!o9$yi4x~zgMg&r#EUe
zFsO1vxmmzauX#UIk>mfGS1ol&4f*<odJnpHsVy&Y@;vXcyu56G&E}&J$NKWq=#5+Y
zcdsEw^=j^x<Wy5`UU%TrxN-%7$EzOoO6;wbM@}3wqtDXpKw%$Oxy?r%Zl|W%%9}3U
zty1uYR<3xiU!8|JmF4fQZ~N}{z%ueWCFYlg^Qy@$TC{rdYkF<jru?>ucM@FWHRXQq
z{Pu@Fa<zfWD(e5JCpUk)QS8ReZgM}{@%H`4`^kMjpZ2&()jD$Tl!zZ1467&m*FETb
zw4JNm{QEZ?zZvQwuh-O_?bOsk{%PvMUHulg%b%`#Yh_K}-vdWJnOWvWlp<G%>UE*)
z3P0JYS)^N1t$OmTx8ed4$2OL?Z`{&t<e=7a)yWGkjr7z9{^j1P(a&Al$d%_$n0{+$
zMcH-O2f4QwHj#%-o^p5f;y^h)dA`1NNK3g+*yg{>{@PmJ)52=tuLoPoM~?rQ{d>N<
z{CSzW34KmAllSbd-)CaamU7?s6PMO)T3Xh3z2+#r;e`2ES1$PQubp0!mz;bi@6^20
zEPaz4ocz3N%Evz&*d$+9M)nFyb$MrI1G)O#ng?S2o5-P)=0W!<53Tm|ht1MtdE%1y
zJdaLpC0~30a__@s1Lf^u?`NM_-%wudkZ~quc5C_cpv=6q4Ic6*_Xc@}{}d><(64x}
z+!uE8)$fyb)k>7*dmmTNcXnwme_AeO@SGZc@`l|lJC9%LBj<$4)0UPBkegbs`J+y5
zL)pInf`NDYw3I^*_AeN_zqx!TBCnk1_qFAeK7r>vt~QhV=gp0n*}IioZsm{99`_HB
zfBD%v!OzKG&c4!qNtR1);KqS}l#SAQ$<9AFE*IxlNB*He>wZE0EAYLOUEk>vT}!UH
zHNJD)pi=VC*e`zcZCF!wy4&)?)`KnN$MNGLXIJ)?BRXF_64~pIKvDi0$%&KKHt61_
zg*+?p_v{U~>dV_}R?;6%t1k~5^y|cV)&1oqeZRRq*27npPV^i<Z>K)6UQUE#jdvA!
z``*$Am$?@NZvOiFs-wMS`6CC<&W=&u@?f8o{S_Ub1$MNrdb2~{X7YPuYzzEvw3b_r
zzM#MIiI+SpZQ&R1ooFr}O|34C>C{xNakkRxM5Tp1r~cG3+5t`Edzy%CQ%|>+bM77J
zuU+RPKeAgHsq+q$mEmXN1NO9%H_oW{eUs)sveh5|d=fCbrhLQBW7V+}t>w_O-?lF$
z1;|%NhS$kl)Ih${;Hx@Urq!2^#U>o>IoVa#$CUdmuxAbV+R~|$j)&h5?9?m%>^s9A
z2adfm((PW87V@Zf<$Uee4P_VY&^@t<EoJu)w`axlc@#LV-ux;fK5WMH7~>he<Z0kC
zNwIw=tcmQpro7cn*XCG{n#*0n?PhN*t;jX|F1h|)(>AiBf7`P9F9PJKDnHE*Zl}o2
zC$@acKB|>`*==|K_k)|t8!zn8EI!^`uKH2^RtW)hW&g#M%O*Ovk)QS+GyhUxBf0YL
zo^#Lr&C2Poqh>E2SWli;*KbJoi)G}4&1~!EZpaO6+QuhQAKX!XtJA&DR{ULGz8>D?
z-I-nM$bM7X<ph_hCu@4T*m>0LCJ*}Ir%HZtUF48qzf2t*+Fq`Cvil!DZt5oQJvTiv
za7I1ZW%J$#gTL^Qf1Uh8l*gb(a!B3H`8VFJColQ^*`1-?6uI0Rx2Ese*HKR2*yG8F
zm96D1>xaC%VPpgO^k3zs9yrlX&h8m>uv<nwdDZzz)4EOwlFL`hK4{avio7J`RA%&{
zAo*mo3vDYLX(IP%J*wa0_2UEEU21D>|IkCebK#o3ZlRyt;RBm__o{T2`)_)9rT5>m
z{B87g$$nG^Y#+MI;W;hdPl*kY^(jud+oL<m6K{uXf8yLwK5}~f`&IUJlcOi6J{^?i
zC0Fa>?vQz^t-NMMki(FZZDn0(oumDmcaXz9y_=nXr-giGcaZ<y%C+UZf2O|u&w?QN
z_W_q$jy=*{9&pF$vyW`L$xa(LocihAF7loMhsx-F@|PXHy;XknvG#JsTGu{u^9huL
z6Nb3dJmM+OnD|R~`O~^`gU{NISX1ygu#sJ^)n}b+$`>cin%;G5582^n)KmWvJ>-Ue
zU)X1RwXM9kYHmV<7+-n%`iqIVrCZ7O#_#uS`XETQuwFyMg4gu51zuaAcnbu1WY=K-
zJyZ0hA8Tf2JX6X))NHQ0_L<^QFsnwvtY^xui^-pBqn;__g1fAaZqKkot@ii4o+)-U
zrt9~Yex_J0=umLv_oqt6ZOxaZPdrur)a;oSzwN0q{A>M|MvI;**F%?WaG&^8nfROL
zSgQd~l?m>brY>srRH@D#quCnv|5N3I_Y1E5^xG5Vc(vq9n&VHDi?eo54&U}f`Cw-C
zT6v3~C{2CR`+ha$iLzt-r1;MVKT)dv*p~hOL~$SVc%4t(C(6W(*oC{Co+yXEYd<(P
z@3G>z!g_B1^N*FA-)lY|v+uF8=;~XgzFhxU3I5>G8+GPAR;nHu$Nqn;yx+OZ=_O&0
z6@9@0%|eAePxfoMtIlI3J7bo0>9UWNdGp`@``x>bl>4?z<~I2Ck@B{j82#knBPDCk
z{t6F1f27oU=Gvh8(nrd?CcgxZp7BU2_4mGOInj@lo>gw`oYmuza?196myi~Zlne2r
zgPMChQr3H3Xw=pIk>b65?cVqE9x87oEtz@i;zOm1?vT6g&_m_PpK}^k+x}457d0~c
zpXCpgfmi)|-AH(-jB(G}s2TH6>GDBL>9zwND(>ssvi~0{$yE={sqgbpvFbYQ!P!de
zd9sH6|4_NmM7wms?FWi)%&5w1etw`>t-apkbmjx)7j3^kYHxd>i1p<M%Cn3GWg5Qs
zKpCIzRB&DQK-o6sn&UTvA1K+s|MWO5<biU-XT{9JO&=)ra<V!<@_3+}OVX6@S>}QA
z&~@d){SOKhrA6+v-Zu)Av#$R0HD?QyR?par$9DzF=KN9Rc7I-=temU4m+?t~(j{$+
z{<rrFl--Ln_ST(Ppt!yt!Tv8$D%i$lN<9mdU-#{pwyaHolDs}a)1^M+b623)x`xMV
zYzvg2nVKi1?%Y?Z^?ak3SI&LqPN^Afhh*JXrfd8bf4T3za^QBho#)p3%Dk3ejoQ58
zzH)SZ+^lXN+*isR{?yrS>V4&lO--*~8h&3HGf9(qy#IZrW92s|p6+m8ng6uyA$`;P
z%HGQzXL{GZuh>stIVR5KzM`AuI5^wtzEU|nuTps4J>^J?cBAfJy{AMRomFS!>3d4$
z(fccn-hWRCbYJJt`HOo>()d27+pN8(WMn0_>a>XQV`f!~nRQQbAFgS>X52mHfoHFg
zw<GQ;>$<dluV?Rj%FvpQ1CIvZQ!ZzGklw$^JtZhoGv#5ed&-h+jbgs6a8I$V6c#?K
z)IH^~Z@s2N@7+~yR?JEtbn~vVA?Nmi;pguv1GFDCNIZ5|S@f{e;k|qADj9ERMwR;f
zuCn<=t=x!Jca^`wX8E64a90U06{hJQe^+TWDzwdC<L)Xsy{GS47Ijw<`w8wUPZPem
z;nnG`@@Kg_A@(irDqTyZ_J3CYu2Qie=a16W?ka~4I$!lH$8e~I{eM?k(e2mBh52`s
zmZchgmi^lurJK*CeeKTQQDV1y%}GCgN4dIi<FE3!ca%Zj^-lh2`yHi=X7bjVDR-3N
zSv#(^TzW@|57Bs*O1z`IU13|NtJCf%!@>tPJvHWz^63wEk9;3~M>#(ENX~^mca%pL
zBBKjB-ch>$y~V$7t2@e^8t1%*`QA}_4ScK4E{{7(1@4&t=(491N;7$vG)40$Un#wP
zL-4}C^A)R2*Z2D5<SU0KZC-TYT)uL1%iHUh9?Mty)vI+O{M&q`LhCPFT7QwRcpjY=
zP<unZ5;fD+r|Kv9$^yG#XFcaLe!wi3fLZy<-yM#f9yBRm2`PO!fBuMkrJ(+rA*bHV
zSN6v>cvQ7_zS7Yp`}3(C^OYTY2MoI2Dqne6ZRB5r8|EwDX&ZF8Rx4lm>d)W9rnu%S
zNvHiaZe{Y7aI1s$k81Ljn1*Y=oqaD)>3aI<+8%%ADa+!!W_V@iDaoO}8i#X?`poM7
z=vbcO+~SP|5BB9LK@BupZFc4<rS|79uDU5tSzZ2my|%0KlnplNgT{Z9r?{jgmQPE}
zQ@Wp88}M*Op3<!Dtn|<cc}iW)Pt(7Q$y0I{$Ll=b%2ResS@h1TK6%RG+MU_|dCH*h
z%FDi%^OP%lKaK0(G*78tKG{=KKTnB!RCCtXHS&}j{X*iWR?Jf_WDIxe<d~<F_t3Ea
z^Auf;{WEOt=PKROXSTU>J6D;QuC)FqCs+Bli{J3O=W~^6vr@L&{*bE-%&z*_^H8o*
z@2`$QUB1axuI<SiKK+Ya<>R;ABX)n5tE_g;cGIlRRaT~a7~f|}u5z(K(z|IN<SOM|
zXF0ph%2j6nRK@LsDY?qj3Bhx1V{;Wv<Hw=%hvq6}>P{L`eNe7)?A()eyL;s-txr0X
z9TJkO)b7-Depw|~aX#9N{hzCRp7Gb*c|N&H6aP1FhSkbd>V$me=I_q<+~q3qTFt&k
zr5V;g)#{(>l@zZpAO3Y$uOzL!G3xGZz2Y36(9ia|UirA=!c>oodZpFsX8qfr(JQTg
z+1qp6F}*Ub?Y#Ft%g`%FS9#sO@wHyrb=z-z!|i(IGi{8+tc`jl{N3#vFRs!neeE?Z
zm8E(mCwkJCTRzk)v$er?HD@#YM|!<AZ|jxA_d7Y%nV?r5m7ltD*GRqccvJ3~?vZ-s
z{Ym4K{~oAUY?}Uje_1cRa%gC!6P-Kj6|GHM_CJ&Bl<@W80KMY=R*hYY{PoK3^`<-?
z>aADoY^-JldFYiE(|R?p?aJi2(<||k#>&P{5A%M^5f$k5zyCKaFna9pVW1hKjr`eP
zjEcWi>U#69xZwP_I?_9AWpxPqYNs9h=4lA~0<#C(=U~Jg7)OnJGdcK%4)#S@-p}}Q
z`*Do>nc#G<p;B|HDch9;Up>Nqmi9EMlE+eH>HALjVjK2+!v22Pf9k<v7|VB$l;k^Z
zilYMl(Pq6kmzq924?+wl|A5<@EckS8c?RMdf-SX2c^Aap5Z6T97coCBf;}6IxD4`#
zBBq^=qY=~2yorcu&3rmyItP3<VmRIjTq0r*jwI<r#QeM}_ACi8I}M4u<%laHPDV`U
zo~I&qLw*`!y4N8cu`BX35YsvQM-huNS=eF@VsV^>B%McG3;kb0OnU*c5qly3I^sHr
z^@tJvM@V#>PSTB?B25?(%Rdc`8asj0i4g)vFa|^%!5Ew}22uD@a>BUr{E$8n0})_H
zMUUVIEDjqzb}W1eJS-xT`yDfOsHpoxAy)Q1Nt9p=iJ7V!%R(8(1R(5T<B>nrUm7yC
z5&N<4B3MHa2~6gO#74(Wj2JdC8UnZM;*mwvASw2PD(#RSFfjNZ`k94s!85`_{vQ)Q
zm1dHX;_0uXukc*>%2JSq9y0p=wc!x}Vb7?-em?11$tP8WLp&(cP>)A5-e}}8$X$Rs
zFnah3sDF@iAw3O2`j_X=J&+on(;xpKeJJ>nQZ4G|k2DBrTyG2MDrvy4<z8FhwFO>V
z;I#!_Ti~??UR&U`1zua=|3?;356{zjI!mEDw2}w=73aWTj7ly}^*8v1u*ku?5&Rv*
zeh|Jnr`F><^Lw7jrCN|x`-k@=y-LpRORZ$83&=y56o*<Lh{v2GS<VY(-;S|x1K6)P
z2l~XT<d$2|M`B@89BO?a9&?Ulf#=Qq7BIP^7G%}_K_Bf-W0>CTZ*%s6FewhTJ`j&N
zN3y^RWquP`xM8Yz%=v+5pii<&F5QAY5GKW;)(7G-=SUWK@yxI5F0FLSf~?v<=;P01
z$%U}L&DjUSq&U?2Ks@Fg$pSCFhqIIl;aZSY`v-p+D!DAx-xL<ftM!2J%{jFmp-d0|
zub3SCig93<5S3gw``c6(2m->SIMn*^c+A8>vcO7ZHqBt+vbhj5l7%0Ezw;`&TdKc7
z62c;<)&s(S?Mh~W-hJBlsg^wM{PYDbA>Y+4f9k_`@7Dvnw`(=H-QaekBVvaSj)H%q
zM*Hca;VUS=sIfz%Cy$7p;-?!L$<BsmvS;uIF~Z-k-D?ZHw!mu(ytcrrv4F-#BiRJA
zwzeb`+GLPRuq<y6{7iN}MS0PF_gy1NOOn}om0ej*L2Hezm1Nu4D%23Cy+*PJ9e_d{
zKp_sq_CQmNVb(~Mqy+ZU+Lz_@xiG=6okp??R#7L7<OG;q&Eb$~t1A@_z8J2okt#<r
zT9WjGf06^80GHKBWywEKNZWWTok5P|fs&jjle4#$>@^i6D;?^g<_D|dak7@2H2b7d
zB!@Q9IM_%IO>HHI#<raE90oZa59&$bliubi=;xx5Tp)gPl=0mvvh*#s^8cKL9VAp2
zHenbXjmLoUFj5$G)kv<voXz=$ym8h@&XJ5yHlnlv&0){gl=;_Gv68B2DjMY}kIBC&
z1^=EH4#Wd_1>wMRpyjQl@)}pkQEgi_ALPKFIvn6rI7BHtbJP?4n+peQ415ZQD5V2%
zCi2NYP~w|XkcaR<j})W{l4M^-Be6r~4Rx~hS$6h2`-QXm0~DO0PJ(PC!|)7$oDX5b
zbBKe5Ww4>C4uC<fw3Sp^!^ZM}Ngke?vr({x=breS{1FCuwXJ|p@lu%}%F9eOQ3ewv
z$r&-VPy1?HN#0&oQW~=bIfE^r+%iAB`~n5tJsDN!TO`A3n*atr(2CYlMNem)He7_P
z0ow+nJW!BJV3cf*;kZ>}HcpWwbsbYb3qeH<`jB3fM`{~KvhdZ<0h4|dKgp|~o64y%
z>08c9DmUIy$I}mdb@~89dWZ&_;gdY+QC=gJPhfIHDIU<z6T<^O$g}XA%i2g~HT9&@
zI@|EOY~w}BK`pb4_ZCLJU_Yy}Ni0*@28YI0Nm77SFDuE<Y61JrD9unyEB3e!|M^%2
zOFryx?hJX4HgT(GBURQkk+iyU;gBEk*uZHj!}C7;Ie64?UEbun7;#M_Hq8UAm8505
zyVbImoHf-Y2i68b_}So@IgOJQYxiA5-eocj{u7F!IgIaUEji|ZMR+ixUa)XAJicbA
zXJvz4ZXRI6wj4wJ1(-hZyq4iPZwx>$7aPe%Q$ypVbL26Idd}Kpo_=GvT;E_O&!5*Y
z#3yhg6=r1w<aoH1B}2FzH!$LAHc~asJgJhdqKKE*W7fWaT{6l4GNU|?w}~+x?%&zy
z-_=HP)zp%xc8d5FqkkTMXCvm}H86$;@#e62fr9>E_XL&Qxx8Cp`AC#cQTa3IFUmBP
zZR#^M&Q`2^U^#$zC_bWG&zdSd(VkjsNt;R5MEz1!`avDbWY4*t6^(jgU(MT7PsWFK
z^*>3=Sxe;-9CZ#nS6O@&tfUHOv^s7F(9g6@qI8?1k&qs2bI2dHG3MkUUD%cw{DB;V
zLzKc%`&auT|G-Z`e?Z}RCZk}_NJb%Di&?selAdI5!j>rcgM15S;Sr_qiIN`B|A8Jv
z!480_ZKd=9KZQM~^ilkjZWte{`A{B$nS4oTq$*sJ$9Sx)Y$WSSlC4#^Mu$y~Q3sIm
zRQZLpfez|4f)3C|vUZ5)9ms?3@LWwJ8K$&Rf1*xf0^?)&ZVjQ0sm9v~XbZDgdk2p5
za~MUN6e$<X#>hOJ%7$=~c__@ki4C5^q!;KLsfw4{I?$7a&-G!{9-q@#CNR)SdYAn|
z9m;abbr<g=p{BAk+E_^k*e{E9kwDe5eB2UDEhCE$#xZKF&W{wvC%vi603|&m8K0i3
z<r3I)$`?~g@?;01(56MI+B9?d?}_?A{7`l?8FjOk+)^s)DunZ7K3_gSFOVm_0Yf-s
zZ_>|Pe349!{1c^eM*d8w8-$x9#^Y8@rAuE}N%wZJd@ECy(^(8#e`zI+W0;&_Tte^8
zWFyj<bR`OLLK@VR>FNe)VEqY{8HoGbMk^_o{X!kfatgTNXI9cwhRHn_x2YXWG1!5{
zWoj2uFKY05@kuigf9@_T>CjhJQU*&aP+NwNGkO!#{wFEHDA%Jmn>PR(03{nxd=_jW
z((GnPbH~kA(kAu`aw^Ly;C%L*z%aSz(oAuIeIadH4IBG03S;2LYz(Z<V^8+nQoo}v
zBf(6Lbf<iyG?>N*aw$w6;z?kX*Zqo;n=iZ*yYaDO8Y<82lF4Ks44|YN#$gXM$M`<z
z_Lh}&C7iVdtla<#j?!-``!Lc<%8a&>^h_4$bFwMMaNUPnN#$eMIG2?rphd~<Vf-B<
ztR#OX3sfyD%8jp~Jq@EVDsN|78lI=o*qqzO1>0d!-k?3d#X}|A5x;@Ke-L#<OwLMU
zEm^VtNdtL|{<u!mhFhRqMx9r|D*Kz%#X@xx<fv>o!<Y}pwoGrs7>x2!O>;2(NRxOV
zJSs~h5AA2Ls{MrL=KR6)1m>UgA<FftEXq?RYfD)B3T1L7+dP~aF6vHFmK8s*)==g!
zZf7WSEH3J+1~Iu2>=#tlOr4{;qlI@QHufb9VX^oOb9SUB<OK`ctva-Ay?9;FS&2;J
zdN7_rAC%=dLG>Kc=&8b}w_&b|<`bw+5hmLZh3D${ARG#po)ZoR8(K+@nkw9ei6e}*
zNcvOQQO!?R@wIxiGsSC~*I@4ylk`x$k@y_wi~6H@iCU-+hA~b_`P6p;O<?*#A5Jty
zl^%%K(+sA3G0i`SKa<H5MLsXXEPN=#X`_txFUvl>fOTIgH)^?TmE2>dgF!A5^#Ka;
z6i0(m-jh+@FRSW2=}&ee3>4&nLilP7;aLdB%?0M;TzERQqmAiIVq-hdU(F9v@pY92
z-_RC7d<hsY#HTJl=AKjeP}4}}4=~76`Y7KlQA#Jt6II&*!iDFIy0N)syA+YHNwLQC
zrukrcz+W(vCrbLEe?z?|K2kS#HfN3DW~jpTs4v3hYZVE`cJAl8)>5RmwG_|VIiS3M
zfbk2ge^8i}SXsv~^%$nVmw7#TJIeH?cGQ~5m1Vzh7Ct%ZyPaXpgM~}7;Z3cj+w7NN
zDhp#NushS6>jV`1daCTBwu4%Z@`3UV<bV%2g;C(=u>A0Zw!8svo2j35#xQ9t>Jeov
zjb^|2aw07svcFHW-wMQqY)3YvJ_4y24-Me)BwGoK(EA-PtC376EPHNst)z;Y30yW_
zWQ|CFCexSmx^rGAg(JqD#<8A*mE_RdR?L3}LtD<uGz%ZvlK9CY4ccIlk8Y|wPD37O
zm!X)+XHT>{3+uW1ZKlj*tHTQ_9G*H}?G$4f32KXSregxiPj!BmK%YW-n$ug|E+sHq
zsq7J?*2_eHKECda<7?0Z@(#i;A$6+-W2qWEAG1Yq5H^J{a7@B=2MleQno^r!O4YUr
zX7kVx4x?1h*2&h=HujUumD^(c_F?|sV!v$DI;v_fxV~oM&1e3evY*Eb#M_RQ!yfDx
zWX7*)`aWWEtJyEyjBKIyJb~F%o!&^yH+oJq*hCI6FE4I|{ga$0%14^<hw-V)m&a07
zxla=1-q}^W2SZ&AMLzU{TCI@HS}x>zeIgo$NuLS~MTpv0N}D>acnm88<Kg9$^fp6H
z$Hk7!pBww>&DmCMOBR-?-z^KRrQPh8WzH|vYig&7(sNS^W!{sem7c5RBUN^%=k`{T
zeeY6c+d}VUM*C+aW4lBCh*G{md@THvfh-PY>*MRJr9auvpXCeC=j;!<kd6=r=xjor
zfuCutpK)ibrJZN3r8LZILzt`|bcS@N7-g%RvzF$wUzQnJH#ZnlRTg~>*No)}j8~aX
z)E4M|ww7w2XZdOBpXxJ{<#V#0%rEGjY4m&jg0+-#k-f7y8|}x--gwquLtDjUxgQn=
z#kVNiT3X3|{-%Cd+PGa(&_2P8g6%z77(m%`3Zu_&*3vrm(^(25f%&Dj6ZFVon7?zg
z@hiT28~R+51FG`J%dRTUocq?2dx14OOxPr?kSF*~K>96ZazC+OnyD<<6zm_&(gc1~
z;fFk8W#=)=M^ir#KI%r{Z(?$n*-vjq){rhLW3Y#T#it?4`n5`t3~SB2Yl9rxobueQ
z9GgEn<EW$ZUgZEQZ|tXI<prprY(m-~P8PPCNgX+Sn(ZZFWje{UjIp%2xm!u@Y}`-b
zcm38{8ob|H3N@7-kG4w?V;|UO!QY9n?)o1Q_13K_jN@u>Ubebk?+|=$cNPZOa@RF$
z$?rOg&zvoJ8()*Hfj-|yyYco}#G_qqEEE1)vHhU;j!ITiCD;>!^$#d-515?{V_3-F
z9MyBQAJ5BR_8je6s2u_SDCfq;@D(-bQdu?^^tmT{PsBq64E`YeObmy@Go_I#K8+_J
z-W>KEu$m9g!9SH1pn#!Ft7)M+M|IB<W%DTiN}j?|`2)Q?F&&vmK_Ai=Xe8<ha_V%#
zbK<L?gMUgtJ;!vrvAr2p@SQc_OHl@N-ZtWWRmF=z9uxtO2G8@CtN3Yb9hkrGs{9{S
z@x$4AxGBFt#n;w)p6|WWSUxknknd+LRn@GQDq@+@VwrKX@Z8XDQv1ni70k0LlJNJV
zhQdq2C@noNWP7kN=8;=XR#sVFK-~^g>HQBo7y{Bw?I*7rnI?IYz%Z;IGXI<pRGs&p
zCOBAyp^lJzCO%I<3eTZz({sR376=EU98q`<?_N9DyBEc8>YvIQt&^6qmddcbUShYL
zNq7`)ag@dDR+Z_QBiey*C~(Yi-8~tvirBvbwoOFaHf)V{HF=*FbCqj(d!n}y;i%_R
z)6svZyC_d3$<JG={QQRE1-nDKsEtzBwFLH@-g(sd1M*-$mL`LJ$<9R8@|h?H;gQ{m
z7L$)KhH^M#tAlnmT$sTaC-_Y<6DH^kalN8EHIy|dLrf3IV+bGe(RG)oXk}WxSU!fJ
z|In(Kk6;(jy`*+DE!V}^^Z$Cih(mjHY4~FHOeK3(c|m*rmz2x%XosUsUd)bmUx{*^
z<)*S@4wg$+2YC5RF`-m$GgWfX4uBj`;s+y+M7d0)#E0kqW#u{m?RkS8c*Xlsv+ez9
z4YYGQ>bqgSFh#U8F_a(ba-D;AV}44UA8s19*MZ3cO+bIajQ&5;UN1*GZt;Dwd^k$^
zpze3Uj#$3c<EH|Yg>LJ!Mi?Kp>p(qK_E$eINq+p7)erBlMWMH+bv2Xv!TVqfb`C?o
zVCTgxUa_73OZtOEv{4`%vzTpvEWCGEd>;Y3Kz^vpZ4P2jq$wtp<TF)rulol+j!eh=
zS!|(Q;&vwc1*83PRCa`XNGXB6{~vGvZ=s#5P<w3J&QL%2swmF)Qvbm7(bFW~)Yw#>
zFi{%c^Yu(N2V+X%-G|CSFvbHE=Mj1Qk*enu9{BTQ&j~|$Qe)G22vfM^58kKM{@{5q
z3zy_gDexmPUXUYsqNehMi}IIQM0}?DLO38#l)^WqMfn50P2~v}rRR(Iqi{_r#8X^&
zz^8OlyG>Y4NzRmJs{9uxPvyrFRnJ{|vT#kYC4cnXRNfRrc?SK7f<M4WP1nX&u=kuz
z?3Y#^2j6TgVY-fI$?x0jTamf!7y1HzTeCPjvtQB+_`S&D{GI)DFW|Qd^H-1k{9nND
zH|*P{W9+9j=a<?|urrhwpb1DL8T~ICx4Nc_@*>lGnx+24l0D!#*oEp7;9#^D(M&ey
z^nZLFEClVaR5m}pG`wF@`B2x(1Wd0d+5s@1-)8GJmgJxu8RYQ$C-R?(;k*ci_)?gE
zpb3o9_b|m_$Tv?WPZaVq*aT-XO!@q8X>swJ^3BB$`q1-#OHIQs4wD^-{@eIW<%^5Y
zl&_BWf7|Z=+wuQz<hyD9{ab9BpT%Ly@8aZ4`7i5_{9B@?<21r#55lID_|Ts~{#gpY
zsOK;0&(lnNrgke1lU~KinexdWyzitiJ%~bk59uKa{Rr@ZCb0ey_6ug>T<IJ-<)7`{
zs$ehHYgPQ^YJMfb=kY|caGF?4H8r6&6>wcv=Lxe)sE2{CGxBR8AM_4pa-=^{CSM2>
zKL_<q5&9lg>62!K`n*JV1*-7;DLk+<#7|TmzWTW(K9xtJCjOrrPiyR@P3)ItZj4xr
z-$%@!J=0rXlwVUl{w+4qf#(z0fx@vwq5MUn98f+^p}i1hDA|+7Gn}$@drQx$d_$Q7
z9U%_V70Y^|=fH=3C@CsAkoQ#ir~NFHCg3Ni<RQ)+hT$D5m{HO}je$?kaZKb~5%xzr
z8}{<V_Oq8d4zQQBE++3#Y@d;NJJk?jMq=2Wj8a;Ol6?VZvU<bXgR&{2-ke`#tmo1o
zGxa8z?eoI%Cha%c`-Z*rJ^KZj>InO%Abn~boL~<q%Tv+?(jCck1becupQB_ivbUO&
zJos1V13X8p{)Xh%QjxZ-I92<VBGT>pu`%8HafQ>Z-fJ47mK(2<V>-C8v_KhvHS9Q*
zT*fpLIn_SwRF#}=f=Z61K^^aTwVX-3v}cOb9F}&nEl^Lykw^&#qmAG>+0@jA7!J>G
zCQtc&R%b6=X1{QA`K^wd`7!l-fZ6sG`(?a<-wDj$JM5SI0)A^Te}3#2Z_Y2KpYK^^
z_MmirG{;`r&VJeE{6M(`+X3}tv^4BXWo;0Im4MHIQk%s0%(1=Ig)n;;gSr&V<anJ_
z?Y*YFAPV6^Jb=}-9Q&>X_7SqZd+b~oBPD;Pv<jTR)Kqc|#Xi;<_5s!s;YNZUFUcqU
zD4lAWfc5}N<%H5t)Y5Y*qhxoGgK#W8CppR=Xoo=F)E=f7!i_{dff66$$y8x@&iK5}
zGs^cLtrKm?F*bhT>p>`ENGpX6=SuWu=TevnBOSwl+zF<2x8lO#c~}kibXMd0o6d{u
zHGa1V_67Z6?3chOVRhIn9b8u?r~a<y7V6Z_2h#<9bC^ssYjz&bX#P#Mwk_MYv%Z|v
zM{J+vv3vZ2?HT253E~Q2VUU|$x9IrdOyUc=ViF(4OVqS4qOt~h1*1*W6rOvs=g4>S
zhJCMnxP9ZTgqBpF)#V^`lSo4sT6a~a8^Sj&2c~%f`X(?rD%(WCALs)Z!XZj!9dHVU
z4}5j{m_NRcE>rBI3qvFG_KQ8^vLJ)H(%$9f<sGDb?B`#>Wc<PUcDLF#Y_Dh^se;ZW
z9LoPKOm|jU2T}eZ{sb1Ls=ssHY|LMs70O{975nq@g?&q-eaUu2DNRUC`<Hes%pUBg
zHKVU#EC%rfvox24MiwDQV>h5FOiqm<d~+DWGxr?iP4zLAqxUvu&q@hQp5{dX=cq96
zi`X~gP#)m9+Gdd^I2f_|IoKMWo5oL=^rUc2F@Nv&!u1=kLTyR5D*vn3Q?-*2ALt8u
zP`NhEbLvY_KXn_W-C`_PAFvDH4DIg=gv;%f!}Or|{y+Ba2Tbni?*ISU&1QFYHyDHl
z!AOJnQ-*3At?Kw!OM@w)QNbh)BGQ@?ZKyI*C6somv}pw+q*4u?s%j97P=a7es`0Nz
z1VLI;f@p)^<LvIlO5?u!{r>LjdtcXmcdzS}=WEWqKj*y9`<&0`Gy7*Iah`o2H`*I)
z<Q?k}^KaCn!Nz?4RralG?62?RDQkEf#~Jb=?c!H|FUOn5c7$7w>j;%KoFm<@fo8n_
z8tBJIcZA7fIzn*`vEB0=YuvamBIEoP_vSIhxG}F8@Aq}d=#H@NksTqodSCH-nMSP|
zY|J@wNN=BGd)aurr^k)G+PAh-w8zJdc<i~htoEM7M$GE`kH(H;uAWmPhgFQ9@7Cw@
zz1Gy<f7nkve*O19A8bv>PwCAg_7lgQ*ZX)zpZ3-B?EAQJ+}PFPV|(B6*7UeB&qm#P
zf1cL!o{bGxy=SA;xW~lj<2dnqy?NNUjx_Gejn}@h-yxn~oqhA3;`#3P*LdyRH_zCA
zeB5A+>wSLp*Y#uX=m_Uhc7uPur*)4V`-tcEJZyY_+S_-}dz5=#V^tgT`@nPCbl<<y
zy>E_L<GzdYGe-POqIiFtJtTzTjlTMhr+uR#@>smu-@f;aaeU7hAAFy8qZU2SeK4ng
z<+)XLXk1(3d##MseXP7zG46pG9>=)&d}B|<d(~o(8~3c<wfLv=ys;Nz+`QF}kNw8u
zV!w^&V|;uZYZw`85!p9xac}$#Y{WO>;+~7`4X&PdBfin!f5ygq`*KhH_kC=<_};4a
z*P6Tk=H8D%yT7_~9xFEH5OeC?7u|a=wy$2h*yo<TegAJ@NAG+6;~K>IHtN%O{2}c7
zdUNuU_g@!eU+MF@H1^kf{OUi?+C<zoR9MsXq3^nmU2QGm<Ho*hFpe>$&se?3H-5&@
z|0A7YGb*iNtkvIV`ekuHrpg*(8*}L%f5`jet!i)V^VMtC_<V)c_Ez_6hQ;sSyZ^Xl
zXPC5AXUJ{%&)3X#JLBi+^nBJ=yzHI2MQ3<>NM}f|9vkoTjqziBVxBRtu^7+04|}YA
zquz6*@qNj-jXOh~!s=uAzGT%Hjj>i^-~Ew&rO*Bt)cOAREqlIS!`1i40CAg8?Zeg~
z&Zn_g`*L1ypHq6Dk7LB=BO9+J8;m&*(H`p(pKm;Fu=}3rHGbnB8ovjaA+GVW-3A9X
zg@I$WH~u!gaj$J$|NITaMvrWeZyFrmJGWl<d*|ZCspm6L{hYS@=T<nl+4Ft4X+NLa
zxS`MS>b{iq<iFT)vERtp?+yBm>o&yWxW6LfeB<+tHEGPh@8kG<Z+p-8+#7V?Ba1yl
z^^7&v>&sZH8Sn4WPaoeI4x!@ed&0i!`5jcMBmNGm@i};j(>lY)zttJaz41Fu>I@ft
zyE8n{`}nnN?|`u$@jN-n-s)vfe_JK{_V@ZZ&gH50<VSkWk*2dc!xk6VE4`10ob}=T
zt-4Re*GlHJYP}ol6lu=g^_|jNpZK_UzpVZm=Svqk|9;dNvb|%+kw5UaSMk_b^VnD8
z+>ehJdmQ&%d_JzhjNZ8TxUrUzd-guBz3=D#gaOG_lPpf}J)Z{j`I&!=cVCPB#-ACa
z`^I0=6W{mz%=LZ#;t!smefuf)iA(nO)1ANZR_(RkJ+}JK41S|dw^QN6YPIM4eXM?L
zKRK;UrGNEU`82NmM>y_ys{CiiPBDJtHD81A-guGsV#dewdY_N%{r%CZ^EN)eSj~56
zasKY;{2rK_J;eX}*8BQ&-QM@AH*(thk<PH)qpoeM=M=Bqz58OLPshHt?CvYMhxfFu
zo%H$CtCl?^Z|Ggeq29wiqvtbC<Cu-lP~T{mmN2C0N6n2~3id(#`j6Xxx+=chi1*n}
zjn5eE+kf{youa=@`+Z`akE@dNxbO2lpI3B6cU!IZeW2avksQ~J@70~rvp19L_3Y*N
zvxMXz=kzl@^V$OA*OK1H(XTqU;(5BK$BpZ3_s?cGl1tBZFXoYp2l#4S<9gPr&wIYR
zkM;TaaleXR^;)v`dbjEt-+S)&Ja#YW9_u4vqwVA84{Y5%zf|wK^u+j{DZZwhqR+T5
zBG>eIZ13}taXv9FjuqLs4#mgu`86FM<NEd=<KpAUf2F_0z5UMXjgODxagFu{*Yte6
zW=#>_ecw`(#x<;QAML%bteQ__of@@`H6QEvnC}dXk7Iw0YhUAW_i??yzlqN`=GA>Z
z_4)l~9543QmqXrv-19jMdv&i>Xztk;J)hh4!M0U<p*N47m~(s9xUq+0&av;fCXv05
zdt$%c9b4`F`Fzi~A3VM%?yT;(dT(4~-aYYu=zcEW+LPz%*VUf$>ZR`Y+ogM7R;}8*
zjeAVYX|ddVKQ!ouf%#Q+TmAJ%_y57N-uwRtOZR#<&XLu*Zue)0H9ohXc6`ryoB7#*
z?$>kO?;kT}yx$}zynlZxUD@;es`ICNO|4zr3o*yW<KDfuk?YN1|9?#UJb>6&*H?S`
zO3vxqkKf@nj{A^)y7z+h>3JW};O_q7bz#--Y`TwM{da{P$93IPUU3h`{2J`t<Ewv;
z&L{pnAY>^WuU)-g-PfsjEsy(XUT+^$<kIJ7^u?2U=2d^TcV2Ov#<;lp>)~6)-AB3A
z$JyC9@#hAMjni27)gL$J6kor_F&dBK{<x@je~gu1d_CFcGgUtN(tyzZ@_<lSeN1y(
z{qt9T^OphP(!UM}<u$}MHO6hcevaeM=&j4VUK+o<)(!6Y!Fny7)Kjn0+r9N_Tx0%|
zx=j#&D%DocOWoFu^_ubiYlV(=*9zB=U(hs`vge)?*RuPb-}`qTL*yEdm1B1;=k-2r
zaIwcRzaf2|Z(RHO?z<VDZ|wVz#m@v;?e~g}xy8Qp8Na&!pQrK7-9HcNe!Nz*&wp?}
z#eAlCzHv-^?Giu3FFqctz419d4aU8>r}hRL?G48EcwB?=+R}I&k6Zn5qo4nXjpHL5
zd3_ig<F3xW<Hmj(j~o3o#*cd~J|FAbmyP}!&#&Wm`tfu4BG<#->&ix3J8s@;zsKvn
z|8zgMc(tDwHokX@>paD{-TnBTf1|(6<L7h??EajNcpaM7y_({BkK1UN_ciy9m+gIS
zqmRcuv2I9u{Z~Id8NSuq9#I*)R?qj*aXxbCUZ=>$_Z8j0A94+E%s19&$_LM>QB!)(
zsn}oP8@>I-xIOjL%hj(#Ul4aVrB**j;&mt<Gvxha8+~jP+sD5D*=I+cxmI|BG9T7Q
zWBhrm_0{NGU)|?djEn0Z+1UT_@svL8y<_+N-SPPE^qKeBz4MOOq<QM&Jog#w-Tx0*
zDi+4qM%y%njTiT<_xPSB-vcy-4aOR$m;Xvk_qAe%V;XA|*Jg<RyI)JL;pg2S_FQAn
z_x?_x`*)NvmqvSojpuvE>D~+aY_Pre`{2g+C5QiPtuT)A)+I82t-6;r?z8b8agv`o
zG_G%b*F5&!cpT5KDdzUEfBqczHMMnr?tGuzR_)vF>#plt@45E@&Uk+=-R<#l@7&vC
ze#URiZTN533VTu2+#*-aE$-V!y?Xab_j9qWS$~ar_T`@1JDNhr5L~AztYe(UUT^Hn
z)&Fn54Q^d4e3#N2uiecLjKBKp=H9uk$|L@tgN^ye9OL+&>~0&2F}K(j`<d7KcnbDj
z17bh_{`z+X{#}88SK!|j_;&^VU4egB;NKPacLn~ZRN#S+^vq<@uIv8Ol$y2FwGaCA
zKR=f}u%|8l?jasHh~C>gx(|L8)(|(w`{w`s^*^TqaSwEVPi0DR&+M4$o!g3D_Ts@K
zQ;!_G@V)nTp7G4be!AWJ&o%bY)a=@s*pEMt{lM4Rx2@CN9vd6uG>&Psec*sKJZMU-
zq4B?<sad}<r~m4&*l(=m|Ld<<*UayF>fM-EgE5!B{y)p@?7h}qwQg&Q{qKH$^_;T%
zuQ}h`Ej{%}&+TFMC-3ja)%*B=@wmE2PoDKY_1(+B|0in`^Ned9zZy9gLPtkO<G~s@
zKwDxB?f-R6$q)VN86)+fU;lME{CD;=X6#qS9dqn)<By+k!o;tB?Zo`oPda(hDc|_!
z<Wo=U$!d>1_u6}(&+pr{-~L}1alnBGWxsgvAtMhx>`S8#|MGul*8lUy{?KjM`@`=K
z-G-_EdA0bzn9={jZQRt{vg*=!wZBcsO*wVS7QLnW`7=G{%9%Yp>x$aS=rU&%x;aby
zomV|^RjTLdfBN^VcYB&Lz5MOJ7{5nv{7vE?p0Q-c#^L!HOJ^MM;r*X+W%m(Z^#2lk
z@rk3JNQI-HnDE5T{~Z75qCeN(4q>M=8kzl5$bZ<-czw|bn$qX>U2Gfpg`WG{OJD!5
z;hDW(gL?a2*4yv@DI58I82i3{*g;U#yY8>s?-)MtI;i`m+k4-QKEBS2e<IWSXELkq
z%Z<1Oh5V2BYWh#UnpgYk*ZcKfHTk$E@vG5a(`qlAPHFstxe@Sh{{N~#X=d^R`+tYe
z?Qz)HG2@ONGjZaHU&)+2X<R1rf&M=%{+P*MIVL~p_!Gaj+A(X2|FGB(4D`SB!J6u|
z_km-+ddz_*jytB$TC6GVE91wUv|3nLQ(S%xfoqIg!@z5b>kd0)(wIr7oV@z*YaV~h
z@&8hulTOVabM*0FJNCpr^ZsADE&i{kU6>TY6;!<~8S0mXFynIHC*Gb6Rjg5xuVcp*
zeon|I@uM_?Pvb+S5K?^R$`B5vMf%C%*Qmx9@OBDfs`wl&jbq_jGeTIwr|=V0=QDT+
zjTE25t*(;89X!5F2|jgo2veveri2etjj!Q5w1`i7y_TUBd=`(P;MhF=k*eD3xY^I;
z!>4f{s>gWzDV6y$-gu3_JL1Ev5WYu~Vmm%Vv-mph_=^zc@EN>~#_=`W?%EJ0#&$fJ
zM)L*S{g>(%^T8!FDEiqUoI}I-BF>~VAFh)d4d-+CUCQuP9Q!N(|3vh-McLnt@)<mk
za(o^){I$QMkL`FEjgRfvaf82q;?sB%P34RD2u<U|Z`6lo#Te|OGM~k-(tN&vS5cL(
zV9Sl_&!_NvRN>3`DlO&1Z_S13d;wpe6|w!M5RRuBU&MQ94qwM}Zn1V1Io}$>B{YyP
z;S;nAU&p0$L)f0r+!n%7l!@^;lP2*Myy$lI=d1V}jpXZi!5ty&9b@p}ioMOJ?hN7A
zG>)&~Mf0p<Y`-gn^X?7dbiO=4gy-pOKHTSTerS4(!JX-9K7)tT1$++kbTMDVYiZz}
z`oa5YFki*jXfz-04`B$6<kL8gM(_okMo;M{JYet85<Z2)X{eYCj-r)uT%1gMYcJu$
z)WX-Wc|iyR_$2N~v&Cm{0&TCof`6gqajXYJ_!#Y`J%bZznf3zCrd?t@zC&}hCm#x7
z4BZ%GaEFIOxSP*m@{tf0@D=>sqhcHz7TWJLDfW*~QjJglF@!Vd^w>Xs_AzzlbJ+4H
zW5*bLlCI{Hi`0$Ij_tT7UBG8?EM3g!@eCTr7x52|n-8CPLfvR7pTjY<EXL#4sm_<N
z{Ym?lPvPe%F;D;a5Cy)D>pkV1itU)EF1~=%D94xZR?6~KTuKGLjvGJiJms_aZJNv%
zaW3U!JhuE<u6zm)r3|0PhiEuo#|@rwory6xx8~Zyr=L|1O7mrWlahRLaR|H8AU=z8
zsL0oFz;mv*d<svaX?zjq(k#A;pIjoh`Hsbzl)cY-;a1O!(VoHQsi-~qLI~fW$=Zwf
zi5K;$J%>N1lJ*MLsh~Y94dK%?mCxckl;hJch43`x`Q*#4z0}3m@v>Lckgwvmm#GzB
z#^hhshtFg6RdwUjb$R_wK78smdyJ;Wx!|c(h<W05ROD+obGh^JF7a=e3+>HUaqTyq
zBe5OBTh3)ZgMXose0GI4--A!)OL*en?L$8K59b2a?v+1&Y^Ce1u`+lIEsEpf?(dj`
zJPY^~4RvgIH-s<HE_dq_|4h5_b-dv{xkZm>hNdurFXLx?^K>>}z;&CO!n8ORewRjS
zFX0jz&4+$XVJ{lT=kQv3%D5Hm@Hc}?_!Lf{Wqbker{#PNx9Q&$R`Nw0-Rgaa`YGb)
z+nT~qzJP=My=Dua#qIsQ-#|W(H5$wZe|vZnozB<suugF?27ep9{xklz^Hv(n`@`dK
z0cFjrjMwel6v91@{fy^#YYGd+r11z!iOJ(nDH-GOaZ2!Y+~l)OVK|@0BPbK&@uw7G
zJU&kKxOTY7?oA=BJ&RA%#F+o*n!<LpLQDovpe`{5yp{&>6?}z;@$oyaU1_QKEWS#G
z->dT;P2uJ}<)%HgS5r9k^ZGQe?7rH%nnF=b21oAK6!LrtzjQ!TSQKLpYzns>WGp_F
z)z6XEJ^C@m8QT=b8#nirrf?<|^k2m7k2BvGGhUr1HHFE1?VIK|*;srQhn&_FM)4&q
zo~iEUTP-w&N4{f@F^9A5jqj?VK1+B9P3EhZJFh9siv6756uwHs_yV?EXbirL_Y|AL
zRKEDbrZDCr^NRi8#+O)M{a3JlsX4@BFKY@{&{Q#He2eB<>*VE4VSfto+`&1t)O@S>
z`77)J?Roqa&5vt={Y&PqpA<esQ;ij_YzlkKus`)#!euld?zgL&!u2#rd=1~bx+#>!
zXJ<BrU4CnA`1H+9;iOxdLW!?p+pX#r`^S-#<Ma6AJFSJer0#Nl-76nHIln3FdB42*
zDt0~~CLW739#l6z`;h!88)I<DWAcePFKP;JJT8VWJmGI?pER$S4<0~Wj?LjCw7^{I
zc;!<~;cmW)8$K=nST}r%>gp5z+!XGkVcNqp_9|7iXK_YN&iV|`HihFT9goFB7F&1Y
z7IDaP>TjQ9@%$H>LPdM-#inr4OXkR@UTz8py{6CDzPu?s{HAz5|CU(F>c58R70%f>
zcf8skFDK2t($*ZVZEp@a`J_9V!)~3;VVYwLxUKgL&x!NJkFM1mhR6Q#6z_!?&xd4l
z*qTaW()d@J#izUna_;)gp~&Y4HitL8kEkB6Ki-!&oi0|ZGCoO@;=H^E;$oT}+i^L~
z=F{H$Fpe(Z3wRIR$R{^#4*OG0&N*C4gVe3KS#vlo)f}qE4O?iV6=G62oaXR(oJtiw
zIixvc=xTjdaDe}hxrI;Rk+jnNI_dw*9ZPfg0`9h@WBEM(nU?WktLAVxEsyOuaO>t!
z=1Vw-7Rjv=Nh|m|4j$I*b*nkz(Ujoxcm*Z-GCo6t_&RRBO>;=ac)XBm`YGcE+o>&|
z#|OMmpvtHHP5oqA$`|oHn$M?pXbuyp#24@(n#I>~_Z{WT=kPX~!`E=%wE4z(oJJWr
zl<>DSoUh;;G>lK~)EsuCG@r#Bb@6$8{!`6iBwyUMIlM?q9#FSWH-|6Laz2lPKVuCR
zI2Jp1vle^?AEr4m{<F>D2Xp~n!@YNJ4x{y%{#<i7o-XDKIGZluEBG3n&AVZT^Jp$#
z##iX{*uIDU_p}fB>|V`b9^J^-FuiwkxSP*ozkQm+0zQoeTFIAi?R}fW!Wa`tgXLDo
zZTB}X?G>CbqB#tWIpcZ<*wflmIEyCoRowNU=I|6>!sEYa?lB%a4t8F|csz)%jxjjk
z5cA~I_%j+UzJj}r)IXoYlV~@-fEUpSzJzmWZ@!AlXe1vFZ4RHLv-vEZL#M}h{Q6<?
z<jZ*Lm((i8k7^Ew(NJrY$6IL^K6$v~XnVed3uz!<$Dv=A51+yG5o*Qf@zBxo;gd(Y
zhUC=zVew;{!yk^ZxB2R^&0*8=;;Z8Ew&U$9J~^Q|eEtMA;Y;|~M91>!uUhv>^5pB^
zuy4O@Kk(Tzo5L@ss2gAWj=7&>P5J7%&YSb}W324?^0`0^U&8}`=z78DFLJ*A#5Iji
zPjhb3GC3E1+8i#U(R>+q`I&X(OW1j-wcyiuEM**9z?&(}S8>>M=R2Rl^C-dRE_43U
z@EDKR(;&Wr{Vq2beWvhmYI#s@_zN2RkQhu{(HyekQ<$RxF$T*tG{)dETB#o|Uc+uQ
zP<s|Hr<NFlAHULCipk;>TF%#Ts~Kv`=kXV`gs<S+G{CXRtD3_X=wj_Typ*Q%WqgIY
z<QA@O4xgc6d=}54k~~ZJ7|qsC9k-fk{j_KB8+5hyA}+qhbxC_+R&$v7OXsZi{OsoN
z-1X)Y+ke#@&Mdo6#k%2uUpI$*tO<_$jr}Gj+~~cLzZ37+DxNyWT5B(3`et>Ged2HE
z;uwR^-(qd_lfKnls1W;{Yu`ngV;u+IW}oOMjiYIL><4e51!Ah$bh~qkPvXwBkk8<0
zv_gC_wo%Z39f#dvj(i3u(7-rHyq2~XU%@(Et)EbF9j3uzGI%2GBBp?M&>ZbG-0)8A
zd<7q$r{<1L-PIh9y4zTM8K0$DVv@ga4tr3U&*Q^1QcN8??vX=`!SOVdFW?+X$+?QH
z_cn)7u~v8(&E@kropO8`@1qg=tYMv&Iyb|7wY<;X<CFK>*A)I>U*Y+b;EQ+@CHV@r
zJ>Y!dv-njS&6jaL?ZQ`aDUIaoxbXseAjadjX#`)yxwLnT$M%QJi_hU@v^`(OMGxCg
ze7fpfq2Z4>7XL~E_~aj~9bGLZ^N5^jHebR+9yJDEz!II#*Kn<c>d&X}URuD{vGb3v
z&#@gpL&Nl+#cdyR&hk0@7Nuhj_)D57zJhl??tJHqPc(=7X&GO`4W4wp;?p>umh%OC
zhL*(kr<%jTG@Z}kWLg+wa1LF}SDtPTFVG~ujywF>xx;7hYMLaU3jUSG@!=V3@vPkV
z!s6!eN4kKo<FM!S$!GBRCC23|xYLX3!&h<8Qgz^ScquLA%UGuxpMI%1e3KUOMVw7l
zzJhO4g-^ch9HBXU2Ct;~F$VueWj?&p9EMQwQGMdUlw4?BoI(k{h?~7?Uy4cAT|ZxU
zo#Bhiy_TS9d=>k>A%_@)kG}1kivAzX;jQ=N%%_|Bg)dNv&*8Ud5npKT7pBoLzJznA
z%vW#`E#+&tg1Y$7uV45Q1-a$%UYZ|cu%o44Nb@P&pXTs6JfG@(32&eTU&Yrb$%p>^
z!Vnt7*KyO<ej&rBaWoC*^EjO<d>Nmj6)_%%w)G1sK8wdE<Q8M_9;&Nz6<?qge7e0~
zIG9%aQEqq%4d=`FJZ1RM(JzdpVSE7>Q#!VH`fLcFSurQh9WPi*K70+2UfZ~jiN~gO
z%!N<mr`GKkMme^Ezh7Vd`RqV7ra^oa(;LV?w&PLM#pm%1%JW5R{fKd6JH9Z;+Qj&c
z`h{;&I*yCi&~Uzt&r^~Q8}|#JpkaI#PoPAM$4e;{<8dpW312mrEZ##a_&RRkGdt$<
zX&gg!zJzmVvK%V7h{p3ZTtQ_%`0TJjG>uQ;5tMUm9&e-Zd=)p_%pCa)mS{3x!Ivo;
z`|-Z@ZK=Q)@TXJ~Q^H$l7GJ}yQ~ko!*bkmd(_#!hNIA#WaIG!G$9(VrD)KoziOS-O
zIG3hsui`Q)Xb(fII~Dmf?oM5N7LTGVpU2<PD87o%({R3y{Xc47@k!i_hVg0Kozi?3
zkD@_*9?zf@U&Oyt#u}xD_6wI$7hl0YQk}2ird!JMPx{0QX(V69S7-zuw$cZ!5TC`9
zX%U~_+FWTqU&L!^ay%CA93}@oxsCc$p3mUHG+BHBZ>B0=#g=W=oKN8#3gT<H`F5@$
z+Vi;K_STNi;E$-rm+@;Kvo3rIZ>RBm9XtKs%2W9i4yOX2!J{b0=kdFg<%{?T75O@L
z?r1Ie6z)!WK8xdNh1~LZ0oC~u=F{@w%Xq;~>cdy@-Cg>H+0lQZU-<rTbKx_)_6x^Q
za*?s{sLz-$U%?$d>-^$NIFFV;;aGf)R`OwY*E(9pr}3+leNsK~HX6uRajnnEgHPd+
zG@sAob+nwX;HDXMd0akt8FlHif}8H4Zm}INqcUH?_b4wWxo5v{91Yf<`h34|H!aX!
z$Hczos6C0pXcV8uE=r2Y;_qo;jK@S5#XfNuO^)%{Md=uiC)0SofIp**{7ZNXRpMOm
z_WjI7OxV9)_#6$?PZlT8fH-%Y5xw>@-cK#stGL?;eLA*;cTqu16<?;a#niFmfPUe0
zK8f4X96pWvQx~7ZDKyKmMO^1V_ZWSq@p4+iSMX)3iwOtmhjM%dC(s}<HC!ueKkz9$
zfbwE;cp(kbUcv>mLVFDdd{KS)6po;jm>ix?E!vAX`e5z$RSgID4;WVRSv-~o@p&9I
z()BCuJv{15)|F3=GXCMl<*T^umz}fv%-}OLJjNWMpE1r&K76HLc$G%*>2dwSe#clx
zzKCaycaHO!<NJk8CiDw8@;SWy1m_)}nkcugJCFG6Nv^%$u$TDyH|@1E%{lsl9L};&
z%rS!((%rEp_`-MXRX&{CFPuiRVmp?n>OZ!h=h}F_Joy^F@ICqP=?gqh1-^{Q3+?~d
zj^|R%d`mc&(od-a{)JL}_`bYo7@zz>zpy10`84iBIX;UgQTl0n7#Gk5d=0lRI)C{L
zUPiOTS8&rG+QYFOzeNN1B0fNQF*QtGB>y-T=4rT?0#>LL+b^~^X)>R~X+N<~`1~}l
zsp$0BCtgcu^JToBGJF-^{h8~A_~NBvs4K?c6I9S%$HCLpicjM~G>XsRnUsyk;(gS`
z*YNPm<jEKCF3QAqe3xqaPhQ?He4Ofh4$q<$aa?S>!g=v$`viBPB%i^PX%Jt)_oyqz
zl<Yyu@;N+(5-|oVG>Wg{)>m3PK7*H2imzbX413SGDcpzV@L4>bs(c;`w1_X_%~av5
z_!7<M>p1KxuRCM^co<#G=kRBA0bj;9D90zS_IhciW1iJNUPi<DI*$CM`79Pc+vg=-
zXO7y_SpKy&)n2`!UpVj<_2IK~)sLPMle*2`xKkWooagn=U24MDaJ{?jff$1)P=+ty
zjC+iypY*-@e%Q4uw*SGs_!0Yr&*C$WI)CMyU8v7LT06du*FI*iKI6RjlQmkTo_rDi
zL?ie*4tZSvd>XHR(zS`tKGiS$;u(91FVw_SF~;Lri=BJXW9m8QJD<kG>1yNV@kg{k
zdkH_iM4bF{_?ze5YqTd{=ofaS*)eDQ8YRr7glD~|ZZ+$UD=EPzm-Y*fzGRQ_*_Z9f
zzu04Z9jCpff4=&<*J;bG7oUEkpWhuj$N3^YOT+o_rZuMwU%{6sY25Huzp&j3>!`he
zi)m7ff7|y0l!`USet$PEpT==iit)JaO4o|$@l{&LC*N`3dDmRTXK}}V{(ozA$hWkF
z=`@wE;MV<H!n9Z)OtiLy5}&~{Xf|KOWLrzPnor{iH2OJXVTH!=RZJ&Z!bm=g&(a7!
z+1?VqLc8!qoJE8AGR~)=d==lJ?PGjLOZX)1&1Y~l?Z)Tv($1E!Tn=^IXh4g<U62nR
zKu>AU;rD16U&3|PY6&;SoblAPTf#u`Rs0*x)gIPq3A@tWd=_WZ0=|lyCtJcoK7(h{
z626Gf(2C`bU00oGDPP4;t*3Tx=m)Q$y7mg@)^7<lzKCy85R)9(5{{<S%48@+ZlD%o
zviLh%6#K-@H*5)m#AL8W741p?-}g7E8vDejXyMyxg1h;D#HaCDoK8zts57pl(b|*#
zfAi6l;`2C{W{Iid4jX&?ievG58vUYn++h>_|5ZC)Pm^BOjynvtzJJk<*VE9Kv}0=1
zme6I687$HuzKoA<ZmcENDAf|aGsJxP<VRb=$G22NzJkwft%lFbZCFeA(Y7sNqW08w
zEn%;Z*{ggNukkss<Hh7Ysr|G5&vib0t|k0>ua+?9Z?0o|w}i9yQy;#(e@hs1P)nFB
zrkHIBI~^*gc<f;<VcjEI!Z1EF+Fs4I_!}1ajJ21JZ3&}d%yBJY<_Xr1uS{$S{l6*)
zb4lTe(fb^;B0fSz?RDJwYv%Ztn&5>ewuFNA8m7K(?W|)SKX$Tn={@@sk32<v-Z3xy
z{x|jWuDMKZ3Adl>Sn=u8TEbXLgmpt6XV4%qWn4@}{nT;Dx2(H<(zxt&G1_zAcAlMS
zZ0$un;4CqYt>Cx6BY*wZaf`F%qyIFHp_G_BUP;sRQ^sehq@Oxoca9kCsdHPx(^J(@
zd-gp4_sI9eIJSVhUnn>ImvJ!-(tjO?d|$knG>)Z`e)2ejX6dJl<BRr#8rE>yMb?y0
z{-`B<mV&*S#cxwpdl5%mqEG!)@bsU!2E{z_x}WOPSgD`M^HP1uCp+EVpp<-ycqgUB
zRI%wY@%l;P9#oF=!p<wiXfNPru51azW1cwiDlv|&;q;m2qW|R2?IRkd|11`0xR@eV
zsH~qVhHK1AKS_LGmKg1sU$lgOT<du4`CqygUMI$}B^>=Lx#_=(p)4Q$CovNxCW{4{
zqn{#HqV!Y6^KNkMc+<Z6O-s1>M%ONTGX2|@@bXRi)SmlYOW62kxoI!r?UYs9D!xm3
zG09u3DGkz|#WQHQ_9EU+qhdUsH`m(5v2JsHphBD%evPJyDd6?g<=m;@sdw1h;_J9s
z#h#RN8jqsM+Vglhr5szv3G?Ksy@qSwr55^6;ej++Ob)+K!}MRmFaKU0%&Us;QX<y;
z9&@3LezMp;U)}fu?s~s{CBBRk7RW!2g+F`9bwGRaVaL)iV`cFS>Jn4L+o{f1@m)&t
z$*OznBd+Is8Sh;vMnBm<+UI|=XSCNb@r3$lFXAKArT;qa{G>QBS-gmnu@3kerDOk3
zwS@bgHkVlEKevRppK)y5Ked*y?P7C}`v<?gMBU>4!FOqR+&|Bo3w6c)gJ)1B?jO9J
z=Ewbm=e;OKdsu4!yku|0HG0|pc}0w4bIa_XzpA1Bi+DR_^k2nyDJv%Vs<CLkezJH5
zRrOQE{r+ZunpXu+eO;b$?s)AR>c*$uYza@irB-})g=1+2U&PyKK3~Omsm>?gHWpQ)
z|9eZ=hbFsj<nR(29`A|x0*&IsKfK<cLGjvxzoP<Q#ZRp?m)MSTD96{Z>m7TN&*PuS
z2iAr<Zt|}6(w@d6XjqKF>D0xS@hM91b=>kj=NF&BQz*?B@gB<ZHQX@t4@o|a^C`qV
zgL9kuhdK649k*!iFGn#rhKBKZT+-S<<oRTxfB3<G{-KL6uhrk@>-7(#<eb8<Q;sj<
zb2Oe0>+}zY&<g9A$J=SXv1+(OQlDb7cohZfSi$wz?H{IE-!y)QirP!~IwiCx*Xtj?
zLP_lfe3T~3r;dBAZ!A8CzoE(cui{4s_V+i8>xK;ei0bkw;}R;WN!Xx&*qNsC8N7;0
z;w$*k4f}^#@mQQm<=Bo}endX89ZQrluS(<~^^EN}lM?oA1-INtKE}=9Osd9yaLbMR
z`_onJIFmBX+HuQG`iE(;ADl^3V?Vg%V6}?zIFshbesIf8<rdp<CM9A&xaDT%82iDQ
zl#Ko0mYetYy@mPWOd1~Z$1PLVJ+|Xas>J?r%Pou>`@vB(OH2+IP>HYOSGLlR^QEx0
z_1aEu@!Ik+>$sErwU>6bzMm4KpY(8b-mQPA#c@B|KYV;o{l;t5Uj4&;`x;Apy{msX
z{s8%FFCN%Gv>#$$X-|*rAAT{ae;A~n>f!yven;6$`pF;NKfLr6YY@jh#<<6;XB>Be
zaZglp?diO6C+Smr<rL$dCPqKmZ}ks%ooOxfQ!CiF-?g8`=g-mS`RXY?c|rehUeUT}
zFaNNA*yhK^)t>!{oG&%5e(KZZe5JM4PjQBvuTjr9?kwZZR`WRSb;i9xZMA2AW8B}_
zpW174jC-3H{p4?V9?k0?7U?J4-9MZ>-?=Hic%MEWvd?3m539qYYRgv_s>9=Q)=&Nk
zIse&O>nB;0^AdH_Px*N{zpQR?+*kUCQ<jOhXDayoU&O@o?yvpBp|7fy_7eWSE`NI|
z`M3Vz6R(+XJnwMk>%6^G$F1H_H^&z6rZ;)*$+!B4&#zFc*bhGTw)0Lt>A&|6$Ns~*
zJ5MY4=1T4Q%)TR^cl8<b!ROyo!<bKK4Tm<hhFa_gf8X31hR1yRwT4f$wE7!o<KoQz
ze9Q;8YHJNEVm^3Nf{*#Mw}#Jmw0et<e(<r*R&Q>Q&w$o&>{_j%9`nIB*VZmRyH0C3
zCD|IXF&}(>-PSNF=ChuB)^81!*bn}GU~3o@^VvW?8@7gA%m-(Fgpc{)RvWd3MKK?|
zX=6U-vx$5Lw}z>)AAD?6bBy)bOg@{phHA_Q-%M$b_1U5|Oc^2v@l|Xds(*cEamtph
zuIbvbdF$4Yl1~<=3~LSJ9b3ibZTUDa{K0nmbZiYb{}``5kH6ZXH5By|c5DrwOSgul
z@+soOJIPr-shwNH(I3~Y&oVCFMW5o+pJ)wZKiL}c`Yhw(Pl=E1!?o|)>VD#Si;F+q
z8YVk7{Tc1M@y0FVtDjYW$7XhK4QGCi*IvbS_Gk?y{p9e9J*}gB>bT?Ha*$5}@7PDX
zK9iqs4SVj}>i_wWGtTR>cKS^2r+xp{FekR-yf3u+^G)kDLi+*g>DVI9JCHYS@}Smm
zP*(jNTf%3)$ZJm@+!{_i#2(X61>YNKj`GPKs-B0bzkF)A`6%uB%;O(ul=H5RhaN5;
zK97H(Ol-$Pzbv2Fo@)&s8)JXQ?-_CPvFhV{=Pce!743CA?ko1^t8&J+an?&r8n2=8
zb#=qdk1>|-qcive8n#TG@jV*;f^|IBTqyiqKlluFz2-V|oVin%{_}VTm3*IG!yU(~
zVf;QFub{-zWT@ae$IJg8a=<fb&g<%iuToh)$qB7t530*Qi)T?q&UM`Jgx0W|@5k%7
z&P2zGN#W;cYMeWcr!I5J$2O|_e!PgYXqw#0IG=LHt>RKjnqwUkUv(~+OA?1sE!GOV
zXsX<@IG#r7Cm-7=ZH`5pMH%sBoKFdJtm0D28mk`LzQ)Hn;xH=txknniXiofD2acyi
z%pa#x(mpBTESlqIFJ+uhW%H`yQc78`Iwnq(gLO&bFe=L}ja|{pA&cWFZN7P&N}0Gf
za25q?RL1%7aoijDHyWYl>3nPW8tol_9)k6+i;;ikq}Ff*-5r0ngT<4Lrw%pz2ThGX
z|C!Vpwxd#fy@a__tf~2yvHA^<)id?Y*6<lxC?<<1&`8G?@KRd9m+=7_!PhXHYJbK(
zh9}TdjxFG&l#KEC01b-q_zx=b$<yRR(_%iD`<8e$FXQW!l~3~Y)^G?7(|;a+L&MFh
zitB&d*l`cz$<(E`MSL`Rb*tmY&(MGTxfcG2%5lE<It61T&(uF9tZyEFL*@AMH(bA<
zw(;jk-*K&?LDnmIwtYv#;<<)%Xlcv`2YuJPjGM+h4YfuEyoR>t%lPIwtzk4@JhwG$
zGqpABVvbpSi3XTs^1RmY3mP2z#N*Fz4NKzrj@x`sKXL!yOVP(Yd_iltmQFXvDo(ht
zHC$|tMcnrLj<uJv_%bb1tK<*F)5UR)IHA}YE{NwQp7ld(Ew>83PB}FR7r8&ua6XG)
zrvY(Z7n?h6FaIhgE@=%d@=xI?8Yurf&Z4K}U%?eLRQ|~yTOS%K{~S)EN%Ak_Qo2C?
z;U~tVr(*s%m6piAgp23``PXsSwAOI8{4+T1XZDYCFny``%bZ`%!PMog;nb2nA8UK1
zdS1oLAve=~lXfweD&GBb_lUS3t}%~U=AfS}?)?krs&y~o+1KjRT&j5YFJ0&3IX+wb
zb-ewM#eJ@K-l|CvzxylKF5_15_hrYLOY+yPq5lo$W-eLW=Qm>FzQym}Xl`m!#k1$g
zK|Y0><#?N8<GgNHgF9U-<Wrkx4ewF+xHs;V=L60c`D7NfhUE|Q@~KzVe<8`I^hf<Y
z?tGU|_6f)RS*_#~p0SRL?OpklpEK7N#l-q7)waxYF`rjk!`gLuTB8&mMZs8kyq@y<
ztl+!R$Mt=^H5^C@Ip^?l8YaGsf2C>S!}8X!J57u6Z+hKDlg+n^$Gjzf#};wR751U|
zX7PC%X1>X{#Zz9NRXpbJe7t_*mj94{Jg4w^T4b!`O7S$ze5-iOJL+k^McndTF>=V_
z^Hh!J)O&IdZ6PP0EOs@uh2b$DoZ9TMe5yFVUz?vXh;L~NiT-V2lzg(-)yl_waB5py
zD93XI=O-xU(=NWF&EExz$F9z{kc#=>)B$4TQ;l4!O<l#W-4;%y@$xC+tCW#XavklI
zjr$W{r9m;Dq;|^5r--jcFQ4SP+G$SQpZF?OV?OI?r<8n(_$m#PPjY?jRFzK=U#0mm
zpMh=RryI0|ynMojZQ;C+n1g)kc<M&x9``36zllEOQ^mtKmA`x{xZmb{+@C|+!f{)+
z`I|@mW7}5R^^?YHXmYGG?z^@5>L-sc(p3E<hqZ-sX{vt8xb-$|VNqOnyqD_cRmbDD
zb!?m$wrwX*^Gf42RF8GWeYbB5OU)~fTkX^qrpYI_b6eQ(Q|2h2?C`eG`q{QnkWXg!
zw(#bj`jJn1@3!zlm;B|E+P^J4b|4??oNWvDjBE=v`GmvT!cAXp3oBwiN3?~X=Nv1a
z+L*TR<72Ize5%K_g>xo~kx%8TZQ&ay$xS}xlZ`*QEtKR_I@KDUp(gSvp6R%=&0Ri)
z@0#EF9>@B8uPvmD@|REUhid<0UOw5Mw1tJ!%~3v?%iF@;SG5IiehTTCZQ;gi9V?&I
z?6z?AudQ8N_usUIi|2@OjSaW7g|qLFn|$h(Ht*FoZp;U_pC_kSAAE}P@(FjfdH<91
zMLuQR?QV68`QWnXV|{+#7N%2GJ{25skKEKJk1J_-%;(;=Fq<;5J~(>581*UOfcx4)
zO+MNC+rk7Yd;OWm^QqvzQ^wo_ZDCxz&*HVTLe6EppQ>`M;>%Q%a~(Stw1ru6PU5yy
zmvb8Tk3QBAC(sDjz&xH$<Klf5ucaI1T*mupZp;~9rg8B;g&hx?gZoqxw|>YuD4#r@
z`>;I|^T8LZ)>=O4KiHFxI2Yto#A_ZkNBPvT?T>uS2akJ9E#iF>@BLF-7%HFSBK<$!
z7ADCjkLNyN&0;?I;*(<JlYUD7Pq&4^@xG7sXVpYL$>*%$i|P>f*i!Aw<SC!zU$wuc
zwlSaAwZG*$AfM#h+TY>jQ+&5AywRKpL*<k7v1_L!5@EMkpY}v}W35EEKt9QJw6C8C
z7t5zOQ2QV;@=0#2eX~T^CFZkvB3w(e;(FozREYJ#m#G-n3p-MYFe<JWZcC-OUbuhs
zu|7C~R@!5EJf8-}eDGQt7uO5#r-`vX_%aQQ>xCU#B*K8WUU=q^L@3Lrh6fEzgsJi=
z<K|l>!Zi65@YSsoe#UIvVTo|ZHu9HGYTJbG*?IZYao>+6LW}y8@U0yZVX%C%J0`+4
zX*tLz?34&!+Bp#>$)}8MyNHob4uAIvxy5`wnFza5O+HyXmFC3t!kcNne5&|16=Quq
zC7u?^CyS>>AJ+?Srd{My#kXlh+&{y`({%Y{@l?7xt{2`+Bji)Xw`uQ~&#sB^!_OrA
zeY$JQZi#T`?uoEeKKaij!r%5tgcb5B?U@K$?2`x;`Bd?XU5SuzE{FXR;jAz4&gJxo
zMELcA)<r(KgA(D{FDAn2alH;sgmn*1gaz`c;2xtAVWE8L`1K>i$R{;A5w1K+-Q<%!
zTFt4hJ|%pH=F6v!JLb$?J{dfdO7bb<!?aX=YPk6rUVYMdBJC}o0^UKR<x|CV#wNmS
z`K0h@x=}uP{1uIsPX*tjk+D8sNrXKqp*~rhLbbSFIFIUay|8(lb&TtUds0xJEKZ4D
zeTq1bM#uHS=3~q^t{3h}cgOX@DYPK27tW(ealNqlSbHqygIgSDEz~EEXN|Xq<x|CH
zkGEIllb)c?CnQ2X)(5YgC^z+~W7F68cz)rS6YWX)l=04dB5WV?`MUm3vM%z;<5?#s
z!rAhv;<J;)$R~Y@{=eZ`A)g}NM)T!U#doMApX4_a;j>hhPZqyTlVd)38&%{}#do5Y
zPjYf1{E`OCr-t7;)!vp*8NYCv9OP5LO}^z?B%dt4Lc7HMb9y4&O54k)jve2&2jr8)
zZK)!kH11E;m=8{%Y4XYA`Baln5wDG2K4rY0c8lwUFVjf*)Uo3X=ahVsxGl|=Pa5~9
zk@Csn1R5cqJf2U%{wd<Mv`9W>yq}iF{ev%4Sw3~_IMaD2pCoP@ecaEuKaG@67AMd|
z`Q-6@nk%0oUQ2h&r;PX0#JGR(Wf~XjgYyfCFg|{7cvd1jL7Diy;n|6Bz&Y}X^Th|J
z+VgVAo|gy*e$U#uzgO|03;DRWzwg>YDft)iW=hMmif>cheLVRC*CLu0@AY^x4UFG=
z;*LdY&FApQi^Ruu$EPoLEi!KIl0-P_C+;1_t>K@4${RQLvqU(Lh8een_t9|U*0B9j
zwK8rB_oI?=b9f=G^tVGLJaoGIj`<dGpUdRT7x3iE9qV;S8LzrRjr3E)-<9MR*B$S@
z(y{ssGZNv`S0#LZr60WiYB|U`HPiY1bLXI(%ed?sUe1|Wu4C8Q12O)W=6=1piLYVd
z*RJ#8(>K_gH}c{uzfFXhH(3{ZxQ4&~oprHxVNN1EPepqvb#o&0zePT=f6ULduhcNy
zW=?mQi}(uG@3hwXFU+&Q?&if8exC?`x<`!o^u392?tF8J`QWGScYhRL#1|jnWBh_d
zSnDD8zPNUex_(nlt?IbXLj9^$?lHMhurA3zCBmgt)n37|kLzE~RXpiQIjKVpr#vlQ
zOdT(JM$PU2P)mdv&)NgVO)gG^8=m9UJhdbdzVW>M9QP+~^`dKnbt&LuOXXz$r(a5h
zb6!q_r|kb4esY-@`@e`U{KYj*O)`IVu24drH5~n_y2+t{OX_N(&&=Nv;riFS9x!h5
z^+ecix%!)L0jIy=`WbV^!Efr*zAE5cn#hN@5@AD{#HaAbbT?nYPp*(BpToy!L5zRf
zyyybHgd6_d7<>kAqKo+&=Ko<o#TZPlbkE{*_#8dOC*MhgAJKBYf_uGdK71Zur>ptY
zd-gWX<*Rr|Xb-dbGCoFU^U0?6urt;A`JE$<rA55|xYO^f+rtXJii4Zm!!9j;*MJw&
zWbI{Kt6zH<#;0**d%O3IY42<g-&;?ge0CsiAU^sH`H!@FzZpNMJxrl#jxFL{G$)RQ
z%^S6c5}(99slsP*Jk8?sIF;t}Mf@d|`3gQs)!4p?SXvSD!THpsy^2d|5MRf{VEyt*
z+?MKm8pmwj?)`0is@-eU_OQLVXK?~8)t<*IKiVEr(GP78=hILzMZATA_A36JvV3{V
z_V6?%`8sa8RlCpc(Lau+1fR$0G%Cj9R$I$C)(Y>TEMLduFfn`zGn9)lIF07;Wn4jv
z_~bV2VG`x}BCfry`SNMJlrsI*4gW?-K5W+>cA{Z?2H)6Gt@!j#Vm{Fx($Rm)al4s2
zU;L~+wP$-6&WF9*!*{5z4rToKKI))7htJar?a9x#hf64-y@LJrwI{Tva5OEA$Ks<j
zhp%Brm$}3k+@C6Z4$r6gd<pNTYK+Hz`>6?^#E(;v&)@`_#uxBf8qZhoIm+{O+<1R`
zl~3a#RN!-XK27CIco&uUD!xv$`0$1H@KGxB8N7|UVtq#NG=i_<>ok%N2egMFG@Z}k
zWICNM;I(u%U%_Q`L5x4JJuE)RTE>`cduaM%d$^cS<KYLZ9bd-9G>)(1kVD$T#2AAI
z(`-J6pBUL5uIBT2%$JN2V@9=yQ)wYz#QhI%4@>w0UPW{HGFIs+zJ}X;xjo#-XD~;1
z^Ladn7Vt%UhKjB7KcYPxML9k<+L$zoPafGGwxa@{!6RrYpT`TSi!b4ml;-QW)=~B!
zpTe_gc#OgRIp+wU!$&B^*Kxz+?Por9LVLJ~2JvNlknZMdxa&l7<g<7ME#xb>;fdxF
z<8egZ-1!2|pz#Uq_!lbh;p^?;v$RXQe(*wCp}mAp(_Fre2b^T?ZRUs%(h9zg2b`>*
z*p3fUHTrL;2c;cb#95T(%XmN4`6|9l`Pe^peABf^4oTdWZq%N}{b?y*z!KH<U&g0t
za?AlcCcD<fV{u!W9goHRX)>S1n`plHDqeSLd)O@=i(foVzkC6IP22MoT=Fe>^Xb#=
zaT=tbBHlv7`8w`&hBb=q_#lnqYq;5&_6(oKBdLqe<8;dKWjwy1=K3$;pD3lhjziCK
z-_oAJW2lAC<0Uj8#^d!gkgwok8p_vk$0_Z8<n37eDy@v`jz6Gfd<lO=OZW<|q+G1q
zcbsc9ozLTj-*v9>1zi7J^^6|xqVaqU51#5=j`4W>dDe?B<EM-EXN>uwd@r(p_!O@9
z6Z@0TPE$`>z!&i|SICF2m)tw9v{(5IPNTg$^ofZXYQ?8;GVR6}vF$2(@@bq&<M=A>
zd$n_n&tvB`u0?zWe|fDr#`a&@d)GNP_~P}><zKtz@HPC!jjl_4?zipX3v=Ykr*3v#
zrP+J|Z=s=l6+3RRXJQN<L<9I7{(uJZHSBk*HRY4IHMQ_*JeXFRZw}9-Ww9oB11;w(
zxMHq)iqGEWoVs1zVxKtV4z=PlIE9w;C0tBP_)zgWgjVu7{1z?bi#VH>@s&urF~;9%
z9yB+`;0E*5xl{j`r(O60K2Ce{b=>qW^WxKZB(?B)9Co+9_#6)Uy*lt&{0<G}i+C3e
z;H$Wt3Tw&X9?w&bPvg_~8f$=K=eLJ{+~*#|=kJ#<RpYTZ@Bw3JPh;+3=TVHQwugro
z%7d@}(LVi?>p345Ij0|Yf7gHN3D>7T+h^J{&*=L(`%HUoiR&a)v{$hCd2ulw$I@`V
zfb%HB*Ko)S&I>++Qz*}u@L`&ypBk?7qSp+3d8z9VWyMtSHL96Qcu7AroloNrX<UrQ
zbze4LK8ru0-J*ZRHGwAUr;N*~i%%|V56997F$GNh#kru*ES4y#y%PCXdBm~sIttpW
zn0wW080|%TktXq>u1^{r`@|P$e)NB94>!}OI2UYr&3Pm~hg0ZuzK#o)YZsq=!@hXS
z>!LUouD^m8Q^33EV!npWZ#!rCG@eL_I2PVP747-IyC>2}zJ&8=1YgD1Xfz-Gp`J93
zPves--ACk^eaASoh)=)k9HguH9Nt8=I2TO4r{;VHZ=(udLqGWl)A<74LG$@!Q-_bL
z>j+c%RC7l-k_N9MPkfLnYpVku)~_S1<n#C#wTLOUbcAbZAYaDE`*(ynV$!W0VSgH+
zJ&Q}I7Ten#m*@zi`3#;*8NP&<w|9hbd<`F7t0OGst7~_Jeb?;>)A%~Rwq8e=$Y<8q
z2c`KuUO>b75{?<z;e$wde4G+|9Y4B3M_6HwY3!mw+Os&Gl6)TjO2hc%h8^JmO7S@y
zv58~&;^2;O-=-a*9&5E(M|hMHN$a(FM;J;4^G)Mus`7cfn8x!ZTtIX98g82E2$N$x
zo<j5aBHl<vzJklB#)mCB!WPsO<MD8s#^-S=W%(j*JftI(_zaGrT#Uh=QkgH~A7~U`
z!}gDMgjswF_n@VG7Eh%Wd=YP?seA>O(IVarBn+iIpT^Nt;q&-Is`DkhkNi^AXC`!n
zZ)~aNd<oyBB%j)<Bm9<z#TZ<Bn40rNoJCo_jPq$cU&Z!q<j<$@GnC=8_%rI_YdCOQ
zbLZ3e#qI5r*p5SYuuu2`zWYfv;ZwWX!+Tg4zPeXO_{l!zwXQwz`Ht|XeXS{<?Q-7G
zQZZ#*Ntqb4pL2m$Xix6XQ#Q7Lp(AWYb?s@~ow{N_IGK`s5pSmPd=*<psG;~29!7(-
z=W!+#`3k;4)A-~89bq3z@HxDMa(o#dpupGgA2ce)A1IzC$9TMirp9=Dl4{1S<0c2G
zkM=a~M@8*foIum~B3?_g_%hx{CBBMvn#}u!eHcP{K8;x_@VQ8u$`|qPR5DiTi_R}9
z$K3FCn#I>}z`@of#^7+O@EJUW=Er#4@(^`ckH;-Xs$2B9<)PL+dc2ZWh_B!x3fgP2
zjgovg%yCqYW8rWbroDuVDHUVBB$gJ%82mWZ_zY&L%IEN8TFMu21`S@{Sh#|g$9_f`
ziw0^>;r_HzdjYSb0op6Lj9U0`ct`l%m(@f}`iPEj4VC#S4n0zR;<0!uEs5>;%u#9^
z<B#qLC(yDOgWntD`pGB9n&VfjDPP3%j`29QAKMYO8E<d%6-*u95w@2@1`nm7d=95j
zi7(;}G>cD7&<9P8@i>a|F&@vSB45J$X)<5K0Vl|TPvHnE#CW`va(o$Iq4B&IxnXx2
z#b@z*v<qLtg|r)A$IHLj5%!KTr*(vrXenRD`Bder_;*^wC%@%5s>OIb>f81hU&oiv
zQD;7Vp6dY3=fn9O;SmZ09s9kGa7@vj(O&ssM>y^x`%rrkZ=fPy!KW$D*Kw^MnHQhJ
z&(e54i(jRwd;u?`$$S|fqynG3*nXrmpT;iA@>x8MhVw;yfkyGEOFF`KKXweC$6GJ8
zmVELu<5Cx&#nUOn7xC@O?Mps)g?&m%K2_=nN6<9BfXk@DC$Ds0p!s|aht9Ac_zX_G
z+J4}}%nqORr{;V*a<)42mFqjgo3w~e{;DHfPfPh4PA;n_U&4)l?VO1oZ>2#Ss3Gon
zgZlFY{PT_SjQ+RIr<>HD&)`pfXTC8WkH1yj_|jbc(QrO@TSvJ2cJ<*?cj%uoF&>K*
zbKomjxU(b7<;!@@ypC{ojKLq>Wxg>6kGfmE_#*Cczt<u${sH%w1?s@(9&~?y$oykG
z?(nd=^I7~QE#s?rP1SnvHGE@XN0`Ki$6Uw$WKB1;j`#{?`Q#$kK$;la@wCU)hp*to
zC!80233q<d>kmGM$33GaF}~IjKC;-p=L@*eb8_Z0*u2EJ(c?5aoiAhdd2^5PxYG-2
z&gbyKmt4E#S$^4hP05YS1)rxBU&q~EvFG_LUPtK|gPqId%%|`Oa>MhtM9#VBwdej~
zUNnj?;Lj+_m+*EP##eFEzgl-bjhE93{Z#Qin$IU+?FgTvMSK>|q$*#;JE#`paU~^U
zd|f;xV?3TogJL}1L8%yz@6oUr|2OfJj`4UV4Uh472W4VBzDHd#{x$KGjq!LUjf(Mj
z2jyZszDMI@{OjT=ALH>%njGWt4l2ZWe2<DTez|y>8sqUynik{n4l2cXe2-?u_&3B;
zImY9eG$+R69aM?&_#Q2d@o$Q!dW^^GXz549;FuNaA3bjOceUk<xQOa}9Z&m*$9x&r
zT4}%WX}plmj_tVCJN8~|#|!C#*p7dr+4f%YU9acga}DD2xPs>Lsn8jArMvkIeu)<F
zIs7Iq<O_HuJ;j&t+@{X3gs)&zb7xq_r|^1O&e!lW{W`-+K8M@3bcPoB<nR$1z}NAh
z{+(eUpT}ouFdtew!|^nfFXB3FonaR~jXNbe!}fdu7t?MrzP&RXM|;P1e4R${$&SwO
z9U94(uuh|6duM0ZpT_Yyyp1OEHQaeXXSkTp;yE;(FX8=kb&SD|wK~I%d<t_ko6lqG
z+MQu8pT;sxH}@+3VI8%N@kwLR)!OU0<GP*U0_R``FQ%*cGCoGr`LLec>0&;QC$4X-
z7=xc4C<i`=r_hLv%^h#0UHB>{H&7owh2NvS`7*vm+w;i{k%saaJeux~W8nidm#^cF
zAF&_!3|>Pk_zM1!hHs)KxZ|MCP~fw89cB3{c5c)e(tHYYl!@*58g=nu<Ib=#<zozf
znkMrZ+-DPehA-lJgYCVTC!R|S`4T=vEBP93u&KSrr|~>m5@YZUTE-_gGhbT3XK*5o
z<_q`;jpXatyt%y*<8cU0<kPsp(9Tfevs-qC^@nwaNqh}=-p0DfGm9(fMn1i5XSkde
z@D+TW=JH{?&T#hj>KtP}))`Ktg?tg0M8%jL>`!`%&*6=<EVl318MdM2d<J((tIuHh
z<2)L`*Kq5dt$S?8`Jc8oV*75L;r87f!)HF%8BW+sEn>{x_Vee}fzRWWUFyK6_fzLD
zr~{uG(dj)=_6c9d-4Ar0@;N;JAp451VaS@l+>&_LVa{vqrBR*X??>9heD-LbPUq9P
z&M=EE;H!Ad81>|f*gRH^_!M4qjQPj*W7Uvm^U32n!+5%yFJPJO<}0}Ecy;Epc---w
zKHJfr$B`494}1Y1q-A1ic-dFw9OJ*{Jfeks0cX&1zKrkC0zP@7wWg=|4345Dd>((F
z|Nq)M_vkjNJCENy02Pmn2m!>SARvHvp5g6MmMYi|3OFDVL)?&3nOH$4j;+cvRUiZb
zp%p9-H4rd?($T}#$kvNCr7jIY(3I6e2rA^XE)5{Mw5SwVL1}9sJ?!U7laOw^J-a>o
zN4u+>^F5!huI}8q_cy=al_N`IJmcHG(j?}i5Abei8RT5@ym0f4#0u{UHHn3H5);|y
z9_EgeBbX07A;LAqJK$!tlRjm*&o_uU?H2d|nvJhQ`#Ne(_J^(aa*gm2_&jnQ$+7UW
z_Yr5j3Rj~dJ_6rCRXOJRCee?qvK_vQO0=uPP2yrypxq5`Kn~dlj-l1~JbVdR@MXB|
zLHf%vH#CWp&;;!cSV2YFZ4dFffSk0u;I(Ki-Um0L5PeGU>WA4|Xpg{;ktUD*CV7a4
z@p<?T^5MlJP2yA(#)sfW6v3C^8{c9-!K)f;L|)kkMvxn?!DFLbOS}uNL?3Y85Ol|g
zKVE|$CWya{`HVD)Unhw(KBU8O>Ih$gtFqJ=Ud=U$Q}SFRybmVPOnd?U0V#OPqfO#x
z$a)n1+f8EGlgvr>d79(45I1=&yy-`*3txgC{|nazA1U%0@hmZweV%I)S8b#A7{~EK
zleiz9M|&Q&zC>N))$N@B=j0x~u%k&l^$L5kJnyUIEo#Aw*QhVlhgZwQ5cS~8@QDh!
zgfG0sUh*E#;j8aAiQ|4tJ>ng({{!+^_JR37QiHP3C+wL*5tDcu9G$L+GTt>q5jUbK
zd;~^5qwsxk=F_Bz$591eg@-8$_cUcb@TO)(nDDm!6tQ@g!r!c*{QyPWimZ4IK76nu
zY|>j5p&z0MJH861AFhZtd<4F3Q@A%O>pfZ#Eprs{0loweKVA{Dk0EaGpc54_Q+jyf
zDT<hbFTucRig=s;?$Z^q@7W4}Cxda$VO{4cVy7Jc^NKj{3yej(>QKabw4L@mJYcRO
zw&GQ|9<7z_@PG>xv0Apnbtoa*p{14e$ac66b;@>VX;VapY=`U6M%fN6?TSdtcDN4p
z$aZL%r--Gp9j-)g;6v~SXa~Lo%@-=-KD-THiSESv;5gcXFTfAcCcMR|h>KAG?}iVe
zK71ZtIG^>ib{~8UwaK`_{Vrn8cpLoA#fmst`VK|BcZnj-#OE(n#2OcK#uwn#3t2C|
z1S^*_f7#~>MVzykxZ&Nfxr?~r9q{}wG9P>hzJ&VlRe0wTgtuL(i0hUTPkagPbv5h7
zyO)uVz2wRqj$MIAn`q}37vfyB5$}Q;8m3PHR^(&6Sg8m%+CrZYd=qVz$M!42fws$I
z;W}iee;&>lAouV#co|agZny!hmVKaq6>G#-Zy=9WlZSW}zK?b=rh20yK0#HyV~rvn
zy_s0iCvuA-GPiPWylt%_p1(~IUcBRL)D&vLm*IDBC(rS|JIL+3$r;A6-J^&vM#w#U
z9`5rE;vmO?XQ3@}95{I|>%xcb!=tUzuO~Oq4%z>HMf5&Mj>-NT6!BS&+Buebj4I;m
z3Fd}(j40yQW5f>cPAlU03^ho9H=LGby|k<Fyd3ethv56@aJ(f?tk7(H0S-ULwUg}=
ziul|UiU{K)n-%dp6q4;vD&k%gl>OnM1%<y?!}u_Ry!aA)@EPJM`xh1Q&<m^$ANsK(
z_I^>}JM{F2>roM(hiAN`hyvaXA4e1T5?rud;qz0(7M5RT?>dfgb`WDUMSB7M4w-1T
zyrPH|uaX=161=I*-i5EiQ(tFK!#m&_WWh(^4iu4n;DTRJFL?29Tx+yc`Zri33gK<=
zTolGT;DNs)Pw)|V)LX>)c;@gMa{OI#60iL`dqR~lW&3;7<@?kTJ_K{W<r>NHKVW}A
zJMkg79c{u_;nBb2y5m*27H!3A@I|zgamuje_v8}oF1QxGE&ISJv>k8x1A7MAfp^27
zPEpq!>-bO+ccCI)gMUQ#;qxCU;#o9-FTuA^0bhm9A5;5y8@vdu#=Bt*t;HAMD=07f
z!;e29Kkck>npxblmsvRRmVM0PZDhx*CbM{|$t+s%dBrT0W;1`Yh-(eMzrR_0z&Mdv
zW-;Gp=JRfhe~eiiKF7@G-Izb@J=QF`WIGHWXXajXcxXPsEZlev?sJM+c=2TzKGQ5h
zc*ogh@iP>}i*wB4!4|W4So+VI#i8gvybV5gzM0?s(BEMedtG1_6ZjBJw3<Z$UxkOX
znfaX%Yk_f8!WZE2?Pf8FcfejGPT*LWLS@+p&YDLb+EsWXs^TN?byUWS3(aByD&gJm
zZe+r1a2u*HP8t3l6=i=Xu|*-gI^Qe~yT~kt<+1QbD2y+|xfh#>4ejva4#vSp;0+6i
z8{T)RSv-y`_!4{%RXG>GY!??Ht2`FojHYOhz$}`ey#QZDI=%`oxQtlI{xFU5vJX6H
zA@Rqn@BtLT=i&3H3txr{7jaGTKDZ5e@m08gC%J^T!OtTX-UZhn6(50*A_u+z-$6FK
zxZEs`KrMI`E<kp?8{Ut^iOd0-u3%lX+u)%~hy(4mE6rjZGRZ#hxU0<KWPAz!rkl0k
z3s;-PZOh3YeCQgpXz%4($aeVQwPrB~?^;35BPYHLzud<>Wq<fS>cU%A61PFtg)arj
z)gi76-gcc?^daj>^oOsY3hmlgxn9UbdjY<TEch}U50XptDZ|1l@(nMpH;ePo1l|Sr
zzL6Zm7vN4*z+2Xklc<Q-;L|A2n6{gU9~#Cx;KyhwUJbD>6vkU_Hj8tShIhf=-oo|8
zyKf~Pr~@B?n~;t#!PC~7MVssoeW(*3f-j-6Y`=~CN0WFBzJZE(@intJ2~FS~@LE*D
zhh!Tn;7jn1uXBA*W{uDrCRX?|Jo<L#k9WXZPzzpzzd)UMaR<5c&s-zC4}Ke|_!69b
z7yFTHhkrmlc-!4(an(IsCwv~B_6=f%*WfYtn#F2-1ipwO_$oZ=KC=kmRTx~)+VCZ~
z;(oK(f!AOGrDZ#O7j4Ij2goV35wF6F&{n()t{-MEz*k}0gTxx|hBu)t_y|mFV2_o3
z;DHZQ3#ZTyH=!1M3GVw%){eKqCCG{Q!5C8UdARQ*#7Opm?cXAA@e$ahkq>wkdZOeu
zz5tJi6CZpC{sc|nt8kl6tnijG>KcXcE*L{Pz5q{qlvv<P-{#tVhaAH@;93;HYtXxq
zT$LU^gNm|0T=QLW1D}U)qM4@>!^em}+DW?ux{!tTJp47X%Rb-ZHE4pE;5GPTq~go)
zu<x^Wyb6QJD*fYJALPV~ACR}mg)hK!HW5#J2>t-A#+TqbXszu3gjqa+?v#GBSzLmK
z@jiI)ldKo-fL}s7UVVz(LwV_+CO^?ed>MY`hg?g%4eDFC?s&_O%%b}l@&sRiJDz2(
zcx{R}BU^#*6u@VY9bYmv^ImYXXxq&91>gcSjCaG^(BxBm=K|`eyoK)<z#@9%X^w@b
z?b|GNJjZu};G-yyFTr1;$_sqA0`Aq+EM}J&A0CSwconvzKD-OALLWSDsnMb|i=B7}
z97L6EmKqN-H;XFX1;2uV^pQ-V5WWE4M62l|d1Q05Sc`YSC1~l3tP5U`5<lg;9&jAB
z;S2C*sDv-Wk5J&}e5Yf-W^pKL!Q0@uD35o*CFpIu8(xpBI~Wr_ghG>+8Xv=l@g?{c
z%D+NP;Jy~d$6KHs&BUv)9j$$pH9{}i{yN|LfVZIlJ_3_S$LC=YP13&vD`@6xj1Nuw
zvo5>^+EECvLMPgYcR?>|<6g=>7)DdHN1%@SxMy`97SS-i1S@DOz6wpV=#RI+6Q$=K
zGAg_XZNj_YwaA3`!8=e0AAw`24WEb4qOII>rUc(YhtFiMfcqZMEV}R(cnY%YO<lkx
zXd~VYuSW?JwFWn!uFsI?@NslFz5riFW%`ui$LLPlEwh<3a>&mV!HZF(nK9uFXovi)
z0vwm^^79Gsv;&((58ee=NYC#gLvRCH%X|A8oIq9iK0lm9hs*c6;YTPT--|w|SsaG!
zcoi-}Tj=A4H=tpB1dgHecn>oVpF?Z$lJBBB@#0{{LEG_?=c65X7hHjy^8Grv0R`lH
zaqw}J#~0ws=xux%?nEKp<FZ(p7fSFxk_s204*7oycs<&P55b3#ouAwDa4YJ>m*Gd~
zZM-<7Ssa3_{M=}R=c4oEYd5?Sh44Q3J!F;pHaz%HY9Ft{l_<b|)%e$lKqCT;2s9$l
zh(IF(jR-U%(1<`I0*weXBG8DyKUxIz<7d^T{ItPIgYOzN+3U|AVeoW=9R}S70|p}o
zvjz(WcNnZ1oOwch+?G@8JkEH0ra_lMufd?futCk>gu#-*DT6altdBd(pv~Zk23rhX
zWN@j$K7(rvt}_@jm^HY?;EM(;20t>WoK!!*)!-b1XBuoX*ky3J!PN%C1|K$<Hn`bf
z(cpH2WrM#rsGMxX)u6-R5`)(oTy5}fgO3>8Xz*EsKQZ`*!S@aBG}wGf{d_iqryIP$
zV5h-8gF%B|Gx&(XtijC&Uo==T_>sY8BX15hc%s312LI9O@Nb=O<(PWh<?&XT`?gOX
z?>T0p&g*e$)OkG)jXK}6I{yCsl`}6J^7vP|JpSba{*~SR%RH?EL;V4dUmQLCLQkM|
z$nW>`2VDMvWuC#o`90#eJz6`xeouD~jog)rzKd2320SY}dslkq4$kZC^GL^iwdVKt
z270^udaw5^>gXK|I5|YTHgjR1ueIA381i#IP8SS_H)UJLz`%+j-@KvzWr5y-{`UTW
ze-*b1md{+#>kkZd_g&uq)!u&2c=wF?gKeIxhpxHC<9GQzgG^Fv+w1avZ+CxBpQooi
zxXj~|LogA!7;)ELi#&n<^6A%V^AB`$3g7(x<pYbwdd4?aJ>Z|`>6SCyb)H*f?*#)r
zLwz1+?R1OzSnVEhF^=Q@M4cZ0%HIC&0EgBB$ZeI{7hcldamMMV_Vo1$@s3<seM#*>
zv4&VN*}j2gD?B}}p+RqL{k5ox)q6fSua76|?JMMYJGuu0?SB6N>s%n$xyR$rO=A#`
zztzu0Sk~RQ$Wsff5YNx(@N{42`Lp)f)7m_Jp1_|y5!mB8{-=ZH_V+CE_4e2DMr_`z
zvu|*2A8X(?BhoXyE4urJJmM+&h{@F-Jt-f}^LsqvyVE2(daw3(bFnwc^~h+=?djpN
z4hr$ojE;fs9^?7;AhAA+H7y(H@wf(hYnkewxv;x;(6jrRbHfZ7SJ$%60hxy~<4A$m
z<;aTyJ@rc_#2I@pCMX`+L#&a{)vu_0d`b6859jetYY+DB%6)P3r+w-})aFv2#*wW9
zD=8i3*zcLk-5&n5WwBT?gDLpxL0MMwi>L-6me)M-=<OjzxTSq<hP5h^Nhpq$kBthf
z*BW0}mThv5ovVBvas13nhXTH#K&=uM1^m7J*D&v!rp=>9TKfhDJ>s^SpV#XjtQ}RG
z^Zm89ODH-y&|>irxn7$^s|;%QH6HGi$64mKx`c?!^Ih7$K>FuuD|6N6_Q{L|Lw$kX
z3swa@odb(|dpxb)ZofEk?_IWYVE6Ol0y#!||8>3of&P^gYJH-E%yeVz+W)1eRGG(n
zJaI+0zqk8pIa{xMW{>OmD>-_7NEs7G9gr;@1EjmBUd-Z~yH;3l701t@$K`__f177{
zH|ywVo!=(Jm&mK3mGy0`-cimmF>T)Nj2@MqL+d%5l#h02^oV>^%jlEk`P;ap^W>Hq
zV2mT>`Q(1MyX6r<()halp50gNsTm!u3%Y%~AOBE}V(c3-f4KFWTshn2;6R_JHQ?{7
zr=ee5Rm-E=sYQ3qFZ9&2&0Tv`+u>y-<ZRdzg*d&Q`^H#{#bS9bnG7;9*@?a&&m<ok
zB}S9jSN1WEsArwbiM{t|rGUud6mejCl1E=Kw0yb8PYvHXb0I}2n*?{DlYaN9#qFY&
zsYY3D6Ro_c)XQ?Qc>B}+@$dhov@ydyB4C=u?Kl6*<GT*|)91f(@Lzwt$50LX4-kPz
zPMa>)o<3bn!u{YKXaKoUnYJ5YJ31Q`c)SSO&=g)n%g>xHzKkwIt>`Rt6f&a^&zLTL
ziS9pZy0{13j0TYhU55S%oq!HR@1H$g{06;(UO-Qw@1PO%0J<IhcmAFKuhYfn(KYBC
z)P_1y4>}X|AtwqUA95fUaw8RmQR81D0{?F!pf-y+EY=crBwQozQQv52G%{L9l~Uy~
zHP@2Ub3Ezb^L4<cshUG`X>QG@g|vvKX?d-nm9(-})kM@1wMEsaBkGE}qrPY;8i{Jr
ze6$cPMa$7@RKzSXTTG2PVy>7w=8J`5k(d_C#|p7htQ@PxMBEa$#nreY?uxtPzIZ4e
ziEHtEybv$N%kgSlBrFMALQOalu7o?`ON0`UgqFxB3W-vpoTw(mh-Jh!qK-I5TqEug
z-$-aAGNO&-M+zgQk@84&M2uQSZKLX_W7IY3Hdd*P=0^*orP1<ebyOrRN#Sbd9tnKa
zV5EyNytPrnj5AytX@aqewb3e!H&q+a%9!@rs7}W1V&r_XkSrz3$#SZas;2BY8AEr@
zoAb#yy7{aiaAw`vP!{8B7AFHaYbW#Gb=DxW-*sM{HB5}qDZ=LxL475=&fCIzoVD|M
zSyPZ}7v}2eqZ6Y=)-}n>Dx+OVchZ~mC4)&m09reLX=IX^I7Yd_8h<yF^(H^<6H11Y
zk>qevOX|sda)Q+qS<fUZswAt)sie?Nx<$9@Hr=kPdW-JRow`f!(%rgO_vt}Bq=)s0
zKCEkcUZ2nldQmUwlX_XN=v9467b#Q9lCq|3DSJvywWJ&=XUdi8O1V?slrI%bg;L>E
zBsHAUQhF+%nn)E=MKW<RRgdOWN{pGtn6Oq~$FAPobgj0I|NV@xCDo)O=^}!@WQe$E
z#H4<Gt3<*=6jUPMV)Z^&9??V0USsC9`r-PEG0T{3OdWHKxyIaMzOm3)WK0{&j}^vB
zW92bEcq>$SX|uywEvskq*@<i+Tg;ZSli6~%lC5T^vLa{7S#s8#P3BK|KVb*%j5p)U
z1T&#bI1|YXXS9r-$!8`qg-kJ1%1mbX;I6onepBP7v^8x{x1^ovuCzBDOo!9MX+1rW
zE~Y2bmGo5Fl(A;)nU;(*)5VxU#v5j=3C5YsR5DW;Q`VZbXIrw)Y**Hs4Q9j4RA-h&
zW>{f%CT3<Q!=1S<ay*y|=Z4uaCUV8xWUi8%l5@84d0T$KG-+1NuC-`RtxNN2K`pEe
zYq~a}6}3sNqD^V0s5NSjwnUxLuBbN}jE1AbQ9U{lEk-A!mFQH|6tl+cv6h%K))n){
zg0XOHIHt!YV#U~GtP-1wnc~*CJ>C*`#=GL)crYH056AWRM7$WEj921QaZ|#YuqRp)
z&O}$jn+PVtiQ$Bvm`D^8lZi@VDq$M2j@U<9sKYKQKS=!zkLXlhky@!x?WR#HmEKaT
zHZPSH9vwF7Y?2zA8Z{-YNqe#->7<st)LNJt(y5;!wNs&POw^2>dT~-KUg{)Fjp$TJ
zk?N>W878X2PDMDW1}~KmrV4Z_ph)&tQd23@n03r9b6>Uaw|Dv9+5afhs$*i@GHx4J
z#~tIYard}yJTx8|*T(bXh4IpOdAvF<(w4L>t)?AmSK6KSr9<gRT1)5Cg>)%hPFK?+
zW69VuYQ~XqW!z+6h|JT-x&j$j&QvoZYsuQOYSxi;vAg-$-y-C6o_sEm%T@B&LJq4r
zN6y85=*xw2k(`#x=L)$}uAHmpxPc+x)nj3rMYH`Mf1UYDy9(<Toh;w_H)pwgm2&b5
z<Rup^WTP#~jcCMD#&q(EU5Z+%o-Qh9n3^e5Gu4=nI#FwTQy06Fm;EWo4i#pP8XnWx
zr6$;?itJRA>{TYR$Huh{W%JZFgSz$?vw@(hUHmklYj|~*(YEUv$_|ZxjR-U%(1<`I
b0*weXBG8CHBLa;GG$PQ5KqCTw4-xne*sqkf

literal 0
HcmV?d00001

diff --git a/src/Test.FunctionalTests.BinSkim.Rules/FunctionalTestsData/BA2006.BuildWithSecureTools/Pass/clangcl.pe.cpp.codeview.pdb b/src/Test.FunctionalTests.BinSkim.Rules/FunctionalTestsData/BA2006.BuildWithSecureTools/Pass/clangcl.pe.cpp.codeview.pdb
new file mode 100644
index 0000000000000000000000000000000000000000..f6fe6f42a24db8681f909d23483c14334252fc98
GIT binary patch
literal 6270976
zcmeF44SZZhx&P1h%>tz)r9i<_76?!Zt?3J;lmbaNNfStukfbkQWV6{lNtSMQm)%X9
zVv(g5t%|%BEm*K%MZkg;Q4v9c_Huz+wJKLp(Oa}4c==<CRX{=h-)GL8&E{pBwrmit
zGoL*9?Kx*&e=}#!ygsuq98AQLvDTE=_aWbDr+F7PRCv#vR$P4O!N-&}SeOFK@&NxB
zX<2oX<c4Mao!`b71`Gp+0mFb{z%XDKFbo(53<HJ%!+>GHF!26i;PnyjpSTVX)7RfN
z#xP(QFbo(53<HJ%!+>GHFkl!k3>XFs1BQV?8L<8_s1;+uFkl!k3>XFs1BL;^fMLKe
zU>GnA7zPXjhJp7v1BX04-7`lf)>-GT1dt@jvVgbW9?pN~x-X8hJmcivSZj1aN`8pJ
zkBdFS#|=9|+?7=|)K!;W<g2Zzs9NA}@Rin7SJjmJYwOF(>#J%O_!reQ)Rp_HDyquM
ztXFr78_%F_>gsD3)R#9jR4p#oZiWr&rmCi~yuP~BM=*bJ!r31;{zY|l<@H3ex~!tA
zzM;|eWB7iA>#wd|GLRou`t89;s;I5^mHQWwhM6<0sO56&4<=InK%#BAKN=J4?69M$
zq#HMn)$_bFYIns0(U2YLZ*N$Zy#Z|PUTl5fh*6d`O!9Xac{@mCt!d|#E}1omrIHeB
z_iX&7geZT9<8M!FJ7OW*@uv4ZT#<K+N&lg^bjn+5W!$!Q%XOScj<%wK4t-s!iXya3
zcb?1j1dHn#J=b0<VW*Y{BI57Enpcl?e(ijJ?fmo0eU1K_@<xAsX=Ayc0^C?%TkS8e
zDV<+k?s7bAuXY!fF7?kZttnelRn}N(N!cE;SNmlRzB+$n=>ki=2Orq0-NmKVRb~E)
z>e2-byaN}*CGV=@@&j<Ww-h*TR4xr_P4Y?JZKnoMgjzGKkw>ugXV@sham{4QZ+8Xl
zcq$x=O3p3nxx|ZCcaPHbK`(BrY6qlNc<RM#UwaLWa9UbjOEt2%wtCURa)+;8-1c>&
z-=LbRMt`Z#N8RBst*&<5jm~CkaCfye{)XC$M!&DL&T)U(-rQ$r6J<=e9O?1~O1=q~
zQkD<top1eOqO!Vgwhd^@c~3r;sVC}UE9}Igq@Acs*h#7gC*B?_bH65*av!;MW9C^^
zG!RUMm)olR4)1ZZFwhn5=<IO(%DP__<$Vf=tlbq^X&X!0{EHgO>tVmKYH?NLMgBT!
z@bVg8xqi_HekkSdU}_x??#J+Dm@?d{`#hGfc45`R(go$tE8wr9I8<Mx;yA4DvzasI
zS2fm`U%05Mp4wl%TO<0~sjBu@SIw_4t#|ww-S>F|FMrK~n$m^k4OI(jGT*9#zV>QL
zNnSa%L}UF$b+uI3I=r;(pX(Fn#`;p<1!d*)7cD3&Z7g-_2kZ?Tf9R?xua^Wk?}x9p
z-oLoKzM+cpxUlqmxuRan@l3fHN%&cAs%mQM)qP28y}zuyy1cQx%r8mwSC`i;pvH2_
zg7bWFqttr~O6z*rknlW~PITi%b>+lmsoyu>tsmc3epgj5EN`r=E%P@>mD;e7S5MiK
zWH(e@tlwXc<z%SDW?@yO-*HpFxHR*P@BO^Ivgg_8K5pmZuWx>Jt?vSd6XBk;t2Fpk
zdFaKJbAR?M%8AaeZ2J}UwF_ydEG(^|ygB@5bK>v)++SbbSXx!%FRiO9t6j)1mkTK?
znK<|q2el225MNJ;(dE*cm5%b##`FD+m5XXF@GFvpYioq!x4M)HOmfQg+qqvyd6HK`
zJyCT{v0Fj&{?zk69<A$|Lb<l%kwDN+`eKR7P@;y$Ln0h3vs=SaJL$ZXd$ZxxG4gI6
zq~FboOnsxi+MUs5(b$TpKM;?*d7$nGW6@+RV)xwF?T@z3uybz)@pRh-N8q>928hS~
z>Qk>Oz+Shcj<`P)c4Hkib9ME6sGy3es;!s0rm|{*^ZoT$13u?fpipMY*?@Lvy*cR^
zKCmBEHL9-Ps~unMB5DM_1M{=$#-k*S0|lvT#(^G5n#Wqhk2s$EJrNmgNj>Q)xQyQ;
zNQXQtz+ZWWQFZ7sI-j!Ljpvzs&n+uG%(3eJ@A-fa^gWOAJ(o6@gl}24za!8V4ic_=
zZy5K2Es?mS)x9@D?ok%p>rrx@hy=6kj8=96iS|&!a_t?=y^e4+5Q)Tk*&QSI16}>@
zkL7+c*%MBITxW$lj_Y8OFIQIF#&a*6W#>p`r^k;8Tt`|165CAtkKtZyc{Jwwb2R);
z<R0JHOx%maj@`lMu!o0}^}T3oOxZgYcat4=GhDx<Q#Fr!gc-G0Si8?1IFF=gRF{|5
zEUNP_sIOgA=VVpiyA+mj^wW5!tl_kgPtYjkV0=~?nKEz~3#ZSRQ|frEe&XA!Dn5r(
zmmG(C*OXX(r-Cl4ZSYr?mr}7g&idZP2dOtE;a0xs^4qI_pPPA)JEP%fI2EQTak(8*
z-zkrkxf71IIq%u9o_pAG%KeEtO=-%uq|v=5D0xT5d5G{y*r~~?XHMbT?@vm9DjJa1
zjz5_SBvPGm!Iaw>$!&oosj$5GE$>{j3fpZr^Pb>;Pam0f4A+<TdWU?mXetqlEQuwu
z%gQjTf$%$%>b5Sg62=ItG0>J}SMH6ZMyHLp+zw68l)q6{c_I-@)W(C-rE<!k<o{@W
zzqK`Kr?`Kh{eQ~Uk$6YVV_6-6a8%0gIBTT3=bPK)Yw|?`l2`7%cAK|&T98k|tGkb}
zh95anxfCCyXX%<(ch_h?LUWq}#nYSoD`JUdO|zSlP02*CX?ZXei$#)6<QBhmMm4o`
zh9jY-u8vewB-|40Ncor9iKrc+!%Uni_U51Co9k<ty?pwtrj~HDscYtpra(t%_N*pf
z^|bP(GS+Ya@sb#a?AAbMBt?{C9UbA6Uplyog`Dvs{6HdXC!Gk;NtIOT*f{A6O;d53
z77w*hu00OtQ-j{ARrw%oAaDA|X|bJ1(&HP*a^H+1vsS=o`@Yz13#ZyUTbh!oNK-hv
zPbtcBVGYw<5QBXQOh=6OFIe9=m;))zfp}P=73mDw`)a*28j^8|!K^z4I?)+Tg*)th
zP5Sa+mIJ4R^puBv3(<Xr_L1zKcMb<mi2D{!c0|K7=gc0=RW)pv)>Z9|?fzx5ih49q
zN9E1eBNnBT?v{tDWTxiGk<h_C>+J{r4U~if@TMt{igdIN=v(%Slq23^rMxReeHVzp
zSF)+bPE{;zT0U#q8Nwa)*57pfH&Ar@xn2|vw}$PIufB0_WzeZLL-z7ec)8eXiiYC3
zyeChb$i>4%u8dX-^<XTzH}89;XK};e4*JDsIc-3<UfidM(KBfcx9u%bz0$EfxbIez
zQt|IS!M*)X=B)bqm#!S8qK`%EpSle2EpbYlM1OC!SYJkSk=QG%mV~3B*otJ+^x~#u
zXxZKv8pIh+okDYf!DigkPFNXF#jL@~Laz8Magx!rtRq)U`V!T&JekXCuR!*tSobOx
zgO|`={`XjKQmq<)!<=G&y{|5j;lhqL%}+2dP{Y@0z&NYmJM2)HR&b{JbQ&PjoR)Gt
z5xdksefn8*&X_&@jG5D$Vl9`3a(@*16iUh>A@r)R_o<5QS7&9_c$tP$t~`i$wnW0g
zrdVJZfd?~Oc&A<*_D+q)BC)oZcj}T^$Wrgr+7PmGs&{Icf8l&at?K+`3?uqzDU|uC
zA?H_@Igfk|g7u9)z~^HSh!Mjo#yVxVm<g_PraSkg?pwN4UHKQ|-oK=(X66j}U(<L_
zaaZvf#bVLl&{&=0iMS~%uaG&k(gt5umEWg_-F)@6DhdpK)GqNaZ1BnOAOmR(w>A1I
z#Z%`=74u-FjcUY?kw=F57MC*`=UB5|)pbOc{d$Hhs$@*i86I`5iVY|3(gF1|BF}(b
zX$^O4Y8mHUT;(fwY?RHM;ry5lqlz;o!b;106$@apK?W85zH&vU;zLJLX6tH7t5u5R
ze$~RdbHsUR*6)Q4%0*du!v&4Cb*|?Pjb#jqm)6UeFT=UeSXQpGK;{_h#ly1l#nX#H
z6@4q~+gMi9$V8vY9PCs(xzs0vW*19xbmml*OP-xotbHR3CHL^9s-}VL<TuksWmT#a
zR6-F`p9>sc{qq-9RhKO+^;Jqv`p;P&T#;CojMD<Zd0APNJGOg{b44WPNU)^~%Vy8=
z_xx(8TDYiM<>o;5WXdwj@{-#63rZO#AgiQL^h%~pppv7qNBJ*aHC#|t=dY?@<S{z{
zHCWB#viUk0HRVhE4P_UoG}TsARQak(tDU5&)X!%qRQ;$}s!AgRa*LTvQ)#D+*Pr97
zt83&<nR@1osWYW`EK+Y&dCg)5RjbM&?4onZ?3T_p9^nP!^EJLof5SyJKIY>nmlSXY
z-4>Ax66b}A{skSptmTzS`3Ic~8+n1%9GUz5<2?_~T@h>#B>XA$yET?*2*%<x&ll7q
z*l(=!PF)e2b>@sS6rMF3|G7SEHrWf#E}rS&j58I^nMvkwf7Tf^X%#y6XPx2RKTF*&
zK1;bjqxcNcT2U1WwFIJ3J2Z_>Q3drzXnI8;nW_kcBmADx^ILqJO^6qB|Kd1aE~r3O
zk~WFv^fQVjc<0S>W+!D@jCly&EXL4F)#L*CeXcd)$gy;>N7K`mG24R?nR6P0teZC7
z^NHWL1!QdG*o~JxyXxA*D<3;$+>fsL_-m)Sy>fXbl5L*5aAx0I*^kX{!+>GHFkl!k
z3>XFs1BL;^fMLKeU>GnA7zW-$49Hsl6$edMefhWFmbLzlyoaJ_qGA{@3>XFs1BL;^
zfMLKeU>GnA7zPXjh5^ICJ7j=uA?!hsJtvkWdH_l^0<yP=y#?$YLB!ts`=|gCV2okF
zFkl!k3>XFs1BL;^fMLKeU>GnA7zX}L8IV5xG;3a=ECASU9jaM)a)$FGDBGUB%k^gO
z=`*JlPb;>pDON$DJWo58tm8Bah(3UHNbMI;Y5^u$;|gSaVE|JiVGd(tVU$%}I2?Dc
za*g+{`;5Ob{!oO7k>6twiT4CV#wYgZ-{0_}g3xo&7cX79^`2KQ*>={&>ra|-*Og}6
z0(y)w3>XFs1BL;^fMLKeU>GnA7zPXjhJk-`28NM-S@W+9eQ=rQ7d`&ck9Sct^hy6*
zjI0Tee)s7}3DStf5wWA(@Y@)}fMLKeU>GnA7zPXjh5^HXVZbn87%&VN2Hsl?eBiwm
z9TOYFfMLKeU>GnA7zPXjh5^HXVZbn87%&VN28MtESx4VudDMFTe#ghXlQUqNg6+$a
zsb$kR6-J^xmpuluc7MBEC^ObN)~fFuW-SZ{6R~8hHRYXLf2wz3fGcllGHG|TMC^pJ
z`77(3LMyl;Wc7<+_7Pe8dMKdXWe@C;bC}QGP6O<S%$_w(+!OA=ez>lCM@FLA5l-qO
z(_Cf($qvgp(i&6fC6(*{IgGs!MO~plDv(^+!JZ6fkHw4nl!Y4XNL~rb84lL{hsv1@
ze!oLAXH1SPEOzb%lhcdUb%}dDqgd^;kbM%($dg{#C-H+nK7YmN|G4wW51#*<B{RPL
zcNTOUdc5499lHO9CvN)EVHd3V@gElZuKFHfs{2buyj?S;e9V}`!`H58`P!Y+EbBUT
z|MP2J_*Ag?gWpX~t4_UiOvh?xAIC$4v+F(;N9z)Pi{Z>!YcnFz_p!}GZ~-Xy8$elC
z!g`YQvEX9R3oZdq0+)iakK`gy)}92wGr$&b4j2UIg3G`XFaqMY1;yzLz$hr(#lSi+
z4ic8dxw&clv?yumkAO)~*0{(s{4mBaU>GnA7zPXjh5^HXVZbn87%&X{pJ8AaDal^{
zFZ=0_Khv^KK$M}Aruv&)NWZHZk-kwAV){prV2okFFkl!k3>XFs1BL;^fMLKeU>GnA
z7zW-43=G};f1o3jw1aI)X9d8&{rrDhvI$0J&yxQRFTLjfORn!d|9`HY{~sd*G?+;a
zD3tM-lKYg7MZX`vIuqg4N)`gx!DaqnEVe9c%esP*g^L_J^>#89OW5_nF8nx#`xm+Q
z<FQ1lA`p&rCUD{CV%!5ZBR^4d`#0>a_tvzues#=m|8UoiPqy5U-!%dfPO%dg);l=n
zAV9{KNTM~Bxp=`3fk%PG;L+f8P}T^{08apCf<@pgP}T~Z4W0^~2g+Rjctpmoj4=!t
z1`Gp+0mFb{z%XDKFbo(53<Lkp4D_A<AMTPt$IG4fmp+vA!@TY@gN6aafMLKeU>GnA
z7zPXjh5^HXVZbn87%&XHuNaW||4WBt|9@L&AQAG1!pV3b6>QIk9)REdAJYTShoN5U
z0la<I1I*X!0bcev#Y-;>U|+v8PP6evM;}0MKmFlgAQJIMV{vgMXDzz(`$sZyUf>CQ
zv!up**GpfoSW@o2_nxmllHd7#*{^@S6EAC=L;xf4oruVI68rbn{61Sv)I9w&JlvES
zfWm??h5^HXVZbn87%&VN1`Gp+0mFb{z%Y<E2Bbfhz5idXrE``&_b+<cj4=!t1`Gp+
z0mFb{z%XDKFbo(53<HJ%!+>Gn{ma16?f-8}`V+S7FjrImvj1N;mT$KX*Lwe5?5+R5
zHl7N1gf9<A+q}M5M?5TN0Gxo1{3V=Fa6OaA!>t7k{_?J%jlEd3-VVkRAz^<Kc1B^R
z_;78<7mKFsu9Ry-{HT)WhshjtwjXt|Fg6n?ejjC37e2(;hr9RwSv}V-dgf(cdNHyB
zKjLc7`e?sD5eO&k%ntlkcPITMYg~cMeGgztrgQTItFTb~isDzT$95Crk7r_Hp}+sE
z!jI~`@oTXs*PqbW4a8BduhG}n>F2lV>vdeqT>o6XW?+>X)Um9e5~if%hsf>N=~nh7
z9V(yvZOKd$;B#Do=+z&<s5Bfy8cKM0B2w!~rUJcm4-^)9x&LLtsP(uS37k0pNXK!r
zj-$J-VW*BG*=I?a9E&`No$dFFo`aq^CIZnmTd6we9oN0_EnK*Hn$qhFHsHVPYxz9#
z9m3hA!l}$~;i^?|Lm4bjg%8Qo6OdYuc7-;E5SkSvuijGrbN)e}bjKyJn8PS*JhBc3
zpW;XN*LtVBPkhQnm&3m1(LiyUM0_jp!+91DBmx~aZvipxjHb9R>8S%BCoZ*~%yZrn
z(Je8&unQiWh<gdwAKRjIQIJk2-yJ{0stiinf3DKfllF71!z8KJ=8^K>vTi`6Twa4b
z!4vP-m4CrNJcVWoKl&{ab~HuQ)En)jThc#(QDsxomgZqafr@*dnn2?3q|GV2RULsg
zdww8kt2CG3?k?r7qB9zlI;K3DN~~1Rnt3*Sl=xX0h=!<{$~dfpdlKGK(DARFm!TyR
zPPW^L3Srd=Pq=oTOLP*kNL^5si|I~UtsjzZ;cBVA-mb6j($~*$?UZAOJ4+wj`T+h4
zcf3}LyB&^wm%DhvULKBhCNtzonR%z&^`x~ocap|j+_m#87kAA(+Z%UM4*PN^d04`I
zDXYA1LbNKI!r^Ysnak-+NRq1D<@73j?Q$w>qS~<#q~I2KCVf8igRAyjxaO^S3+}z|
zu0!6itPormc)q{uvfB%;d$DHWx5hsD(hE=UKHsJ6zg&9CXWl&Xx5aB8Sp8z);06v8
zId7QQ->}A>b=wQ8Cxq5+`E>2>T^Dj@3FW=OQ**=d*GzhB<XdMi9`Q>1eI-*YYp3$(
zryu><Q*ZzEx;-mDbKFtixaPx@vmz2*;Hjty9`pO9drm(nK5@sDXT1Ix@l^M}*fsXE
zGv?OLeCUY@4L^8l0gI|`Q};(So%n+<ZaT5<mb0hav-nG|U1nL&tNY_VbX570?@S(>
zicZ@$_r)o*Eo(LDF7WJr`nKD)zTDdBJL2&39{EGyqr87ba(~A!zWnhEqc_et^RN?s
z7rlAu+m`j{aJm2M%YQ$r<E^i)D?ah1#7Q4};TN3AqU?uH-moJ$@5K+lw)2@~*BrBc
zxn<p??mzbXpBEJRA3g82i8WvTWYtel%JM4VmLSe|RILM3-&Uy(W+7sz3(``qZv+d$
zn?PANwh=4_?*PT0^@#HwbG~o#jMrDyC4luy?1?|W0w;jafyaSIdaU$m;87s!&#Vcc
zoELL6xClH3RPQ#(nKIUKU?=DWuLO?=<=b%*xEVYdd>ott%J=m&P~s=?alT;|Eg$C^
z8ZD?%=Col}dIY~t2gia_L2;KxoNtn4$+t@UITVrdF6Kx0KN|cocog^(P|}6IAeF8|
zK}pwGP||f6DCs&J^n>HUFnA;=FV0cmXTV9Ir0Y0P;_(pTe2biKl*D5^B54*=Pq>ml
z4WJiX1WpF82PH3W0879d!8-6JP|gGTJScU-dN2Xr3SI?n06ztO5xgF}1H2X71l|RH
z8RSSJ>nk96Y25?93Em6-6TBakZ|K)RiNA!YzbEQDBk`B2vkVb)4pd9|;9Bum0ZO@m
zv$PMa0xtlOw0xi7Q286@x2|ig2ly@i9)g4rG1QUD-)2zqrv(&$`5dGP!)gPC2l61@
z3N8b`0+PS!d%zXoSHYE_)a{ppTS(U$es4myA$t(Yqg954khMrRvI8j?#(gA(+>N}9
z6jAV+k!{F}h&6(H$Q+~+X-8He>ya%;H?kesg^b|koPeB;R3b}}c4Q5*0g-R{R^%CE
zC$a|_F^aN+%t9)W2(k*f2HAjYMRp>4kkMqy1Y{P{h_oYXkafrw<Pl^W@*MIeGKRuG
z5jh>1hg2g?NEfmW*@Sc>+mW5f9%KX=eL7N!EJfOpHOM;TZsZ|k8?pnj4u(Ud2&qHb
zkuGE{vI%(**@`@a>_o<p`Nc>RvIg0LJc}4(7<ex;z^gq(=l{|Fce;M>xc@Kx@<Ki`
zQs3=D_P70$s~wW7y_c&!wwkc_r@fS`-Ic2ym8-osLf7s4Qm?Nej++qo`yk%~so&iC
zJXc*lSUv96+u3!tTUWdFv|B$9R5weV?AFIp|4O|(P@U`6w^G;kt!GJ=F@^!dfMLKe
zU>GnA7zPXjh5^HXVZbnOfDB0gzja9V{|93o9pRL}gDFtG`Crxmc$yiLJAgF+qpYIB
zWGZCISippWo;iBP?Uj+?Ofd{|S{|MkGic5uf1921Ga;8qb;cQv$izs^ohk?Y|EW1d
zcdxw68C-gj^!tDO;lo;d<BmD+5^wYaPnTad*_p?XabF#l<;Fp<Nc+o}ep-IA>>w?1
zBWh{ke4Y&E8)FzS3>XFs1BL;^fMLKeU>GnA7zPXjhJkm90qKiIhot}SXrk+CZOf|;
zz!&~c>HzG;QZGG#ll$latk7%vU)SRvES*wDP;@qQ_tFEH?Qd>ffInlfqQJ9y;d6oQ
zyFa@2>fcRSw)*<RuE@VGz%5!A;E_7cG9EG!A==hF#zh26L6!<wOUJN26fwpyU>GnA
z7zPXjh5^HXVZbn87%&VN2J*vz^udh&zx;4%d@&3d1`Gp+0mFb{z%XDKFbo(53<HJ%
z!@zr$0h#|Fn)Uyol~I2xlJtk8VMhfZ`sfZ^2cWF`_n`y8o&R>%{mWdj7*v8-GkAXe
zZO*!Xe=?Xzsn!44@$k!WcrECv+voNFqnT&Vm%f1_wU6MoLr?nF$;bR@{I;bhKYsbH
z2OiF?cj~>Shd}h{6eF5rOSrE@viCcn<0#E7(GirEJUIe9Q2hlK^Z)Or-hz3AH&nU{
zHkh>xQY?%y3>XFs1BL;^fMLKeU>GnA7zX}@3=CcWAN_yH&Uoek0MhtQ`~T}$AU<2`
z4oAPNGNKDs*1n6L+LP%2i?UcA`Bm2+t>KAS92KgL&hQfXp^ZCkz@^&nFZ!e>bMZJ~
zpwE6~l4A&LuI0Y;dCyk&<94Dom=b-pa^DM{i1gKQzrl$Eny4L}-kbGxslMLY=lXel
zUC;AuUG?blRR*1~mgG|mkv0DDFSuhIHoDQnsg-JsMQdBc&R}}sbH&}&d63UBkGDxf
zfv4cs@2s0zGTr;VTVDEYW9grteSeL4bit`ESC*7F8S{|td;}45F^{DTHi4q+7yZiV
z6Tkp?I@ku5f$bo6tjj>|S?FC(uK`zqw}AXke*^p^DCK!AC}S?TbMsv3f0po3k0{|O
zb368=eB1*{_^8`gI+(YBQ@F-2rHlD7u$=41!A9_Duo?U>P|6m1tJ7Xy9?>Jb0~t(*
zu*7{6vJDa4oZYy2r{gt~AvT}7CPnYBt8a23J-^!sPskL#lRNn>x_(9Xr07NNtAFx!
zo{u+rJ0Q#$!+>GHFkl!k3>XFs1BQY3D+AJRNDRsT|8R79AQBGwGiQhS+nrOhGUow!
zn%}uDz~kr-*XTX*v*>?_k@;xXs6Fu;oc^+`L<ke7%WXQ$IU*<Sr2p)??}Pnx1HPu_
z^vBHc|Kf>X->~E1Rf)&H+J49jj&8uoIPP}B&csQ&^b@tGq7zVl((O-6K5WSqs#r3{
zFkl!k3>XFs1BL;^fMLKeU>GnA7zPXj?|=d6cMgsIzmOf_L~+*P2O@!lKS{4!9|NG)
z0ld?`|2S)O;nnn)>lQ6(Xsq}9gn~)jdzyQVb$(xIb@lvG-v$2in#EQ1wKe|5Gi9AX
zb>XpISwm1jmz#M$Jzj7uzvb-R35fSh#w0c$YVjz>Y=0mXOL(1>IO77+ryszSe4U%)
z^jd+h;d`y8B@$zwfy}kf;n^+fp5NaZOLPPx&OE=&naVut{+^$lYhOUFa|LfWS?1sa
z>!1GB?yf)o<x4OAe#%=Pc!Ps)pJ(wxfv5ku(7Db<%yoXX9J)~8*?7lgyWjd>@3Uu4
z{qw4pihDNaJ~unp`PkjcpQo=F)i&ym^?$nPmMv@U-SVTQoC$l1_<zOizkIZyG<Ep3
zPqiHSk-slv@;ujhiMjS`B$YpheEyg}J=yuO7hj%r`S1~|&OSf)x!J49pZz)S@jhOr
z0?!*u9=`XrHxhq%X!|vj7d?3Mr+Utb(B;aK^45&VI8_lMW)fpSQU*E0S)Ehu1;<l1
zq<rkpJiN@^%UQneJbe4%J?HnjXZPkh>ru|@-P_!|oXL9){<-Hp4t6H5dls*I?xUQ;
z>z==xefHyK{Oo()uFSzd!u@`8@M6~(!+>GHFkl!k3>XFs1BL;^fMMW(7?A$|r9(3R
zAF`vWugki0S%x2RdjI)418_I}{Q0^c@1@TpM*35(k$L~^{pbDrMryz2`YY-D7kEY<
zZXNr`L;rQ%)q&><ul%L&;hwpE9bP6LbZ0Yj{q8w{L@O<vr(~hFF@^!dfMLKeU>GnA
z7zPXjh5^HXVZbn87<iW$kiKZkko5ms!x7ux5eqrf{`u<nzeET6T;1=N`B5>l_gc(I
z#KZFv-S2O+Q~qQskVtjL{h8QcXMfiB->mxlsm~4XzT|;_)D>NI>+}!&>eefI=5%#f
znK)$6>ALItrOz*MV+nxj`)@RTf7md_Fkl!k3>XFs1BL;^fMLKeU>GnA7zW-=2BiN#
zH2VMBIs=JNFBO3ARR7<1=}5b4_uakztedtDLXJj0MhDyalG^KEZwEp(u?jmHv}e!a
zuIls4`u_gLo6-O0<>5-TPQM}6nF!iqSJw0k%Ch5H&*DI&(^fkA=ISws&3X(%{FZo#
zy&G^*+!K$wSU8%p6FNFPm+^;z_Yw5Or5Jmk?h_Z$&v(8KcaAJBz{py130K1Z0`}{i
zaQ&QgkW4vQ5Nx-D%lxf@aHKO~`$Kk1XIo3c4mf8Z>@6P0==}`C8DOdPB-)dUTT_9S
zh+T&U#O%0i)p0pd$3^l);*uULF0I5-;)VUeI2kN1?zs@v!|@CwV?r|KA|i3wGFV)q
zu{c)uGB)Jojl^R#_6FnRMIDba>`MNehe$lS2a886sr6)pR9xoZuD|JtO9>ALipyBE
zPrl)VWqp@$9ler=@r!ja^3r3LAriM%<oi7FZqj-sv&v4aBOXZkRS|kec{B;$q>P@3
z)OwaX1*tv|ZL=HL8Dv=}XkMM?6win*Y>pin#Zz{u0<<4}?UYADJd<>~`am{F=3|6=
zc`xT8+eqh@{^?9cVk^*8l4^I7n*El%v$84al00<M6%;xXwoY1YYirU@Il4qkGIlxw
zT~*PL-Q}dkecwZRkh2_nk`}QqX|cZCFVFg>CG(cOlXvW$ro(+dC$on{jN~KZqe>(l
z&4Z^yy`j0sZhPK|T<@o(p{M-h&WoOM+B+}Yay3E%z{q<ec@aP)4e7ztko9&u<x0v%
zf76qe5*`lpeoI;^c{W(Ns>|5vNsH7Czjor9sT<DMdUeN0g@6eok~Vp#ektYbuDzAB
z>{{Yq_r3@xk~Mp)L!|!hR|e(>k~Z#~I?~x2xK{HZuiZ#3x5LA(I~^XfKdoUoRmksr
zKn5$HvLCP~j*Wo?lN5Nb!gkj)?$Tki710`j%s^yb<9eM3PS{SUs%B35?I;@ygZALx
z3`wIK&QkVRi5czyad5)f(JP!pt5YXt1%kc7(kbD{{zh4wnQK4ZZDdq|XGGJ9KltLN
z6YFj{d&)hFzx3K=mUUB++<)x%KQAcsKYHG46KlTw$*P}Fi7z}^?w|SP?`>~i^_5N5
z0}Frf+gWY@%&ki}*S^YJ`zKcu-~HL|_q>XK|NWD>_F?AQuP8cxRXy+}Rkq;PvhGGC
z?@vd>{P+YbEydzzAZIFB&w$eA{clj*7mH~3Qh$m2;RsYJGw&qF{kfpL*XMz5xVp`#
z+LDz#%MSNokK^tTP^PU81;u~n-ZJiWJ5RlLecd0e-5;afPXr}>Cu;YT`K{Y#lo&_1
zvXnztN7ma^tLpvJ_Jt?ihO)}E{p|Qo#-8wWDoFNNr-AbQpP}7L{B%1<wSVMV!kveR
zq0B1xe+56t_1{3YjasjPV&@I875qEs@~7Jqs-4j{{qqS|`1XNkfn}hyLoU$qQTeXx
z;&Sfybzi65U#Q*JgC*FzNV}iRZ~g65-&Ap*&EF;1lkaS+wlCr7@09v}^$l+s_9VU?
zpu{H*%J*%Bc3;A8{Vh=62yrj@GfVDc=4kh4fhTc27nJnQ14H0BpztQ~)^+KC`F;t}
z6n|SZ&r-g1{bxzNDB)(8Z;F0e%E6bx8Q@)6?sR>o?DuuI6?<5>{sR==o&ZDCS+b9|
zn?>6%B0KoKKYMW9y|=rF&<GMS0de=<F6DQw{kMB~HrO6qckk^s+ELFTgPm74nEq>5
z_qD6{y6=A5@f4n7q!C$*Jc7K4Oyql1hO9z%BIEfsRwHTTZsZx{O{8cXeNto<vKiTd
zOrU_3NFg)EFkl!k3>XFs1BL;^fMLKeU>GnA7zPXjhJkm50U0w{J|ye^Lw0MRGm`S7
z1}_j{9eyYr^T*<;a4eeCiU9MmC*VN!0D2jlaL2*ZjPHmU?SLgyR5N6(LhU0c@%KtX
zJi%;!tDBNR$H6CAV+v&)aw+}|xBRsZ0S%}X47AzY&mNB-Edx-PzVX;KP(0A9810G1
zKF6bdFY#Ec*A}eN@hB%QQa(x$(WhYD=FEMd(=m}!XAbJq6!wzUxKeRb<D7EQ+w?k5
zVKU)%BL$xRIshNTU4iEx|L?;48ZLU{gP)%FZ1ctT*$XWz*I4`WkiI{<4ao@X_t#;V
zYs@~^oW^q}i$A}AZp~p|Nl*6vI&sE_C;8T&%2|I5A{Th}UH2g4#@PS!>%aKiH~;p{
zo9wm+*4J-sIE1-I#s~{MH8&i8&7{XhzIFEE5wEo0S288Hj>Of9x7|<QcH7pMTRVM6
z9Dd#-e+Yb(G4LYsXU8wT{P7E;H_kZouoHe4y?H5v?YVRq=9)`MQ9uejkKgf+t><1*
zzUxot|KY6P{P-VCOngGc|FOC=&-Q)f;J1dI@tbo;ZoPAbWqnie@T(tR|IuI7o&S$R
zLVulGblR_8$UWziYp&*1(p8K&@2K<6$T)5GnDE66M`A^t%P8;kN4R#~Iq%fK?n2sK
zD=6;Tv^!OXop->JccU92`I$MI@z|4V=4aITk4J(fTr+Qy9zom=<XlB}EO}q`IIdz`
zbth$HuyN#UJ&w7?lGjlYxw;$W48;xjJ&@i;IXlrEKORVD<2Kw)fSfYK7{h>Jz%XDK
zFbo(53<HLNe=P&jULBhK|51BI&-VYk==>M`{S)c8_uc<5ZGJIy;VfAvSEu^RmOp#{
zzZ)B|mwWA+)vG@`0lUAREd85{H{Lw?jo04#uLZAO`TFe}|9W=M{(l{o>UW6W+5Hcq
znwEQXxziFin!#z|`$;+k#ux?+1BL;^fMLKeU>GnA7zPXjh5^HXVc^|lK>DLYqyN7%
z6^?{cE7?k$T$YN(-ve|0KV@vd-M24$JjAe-!4eMS?6rI8uy0ZGd(8RE6t~(d-)1NL
z?Xeh}r3V`~aQF6|hd=C>x07~aIa~4=ml&1NTd+<KR@_MVV+iw8;5V?pU4=W^@64@d
zw(P1fcQK#m8h32~*J`Xn=_eRvS>IA&22r=@?4>Tn!ky~gia@d_A#sUSG-X+`4{|AX
zPDE-w;SN?K_*<N9kc8>%Eqz$IZ|#f*Wz`0I3{#1fSXXZAK<7+DeY}G|9+YRY2eTQh
zQf}?8psiLs_~VWegrwLJ|I^@-K6VmzFqVKX;jxV8kErLwm}MkfDtBJ^8l~<_xOP{{
z@46Cq!wcJa?uBDXf9>t=e!9ZKIM+^EZB#<GM8e5-^0hS)=&)6Kx_IvFvuzJVLlK^Z
z0;zzLcd}phc|GrY4`IvoMD6zz`g)$e{*k`^w7&kCzJ5ht%lMSIpYlZ~ZlBQ4&(PPk
zJkMSeGFb{I=0ZgFwN)ZN$IW)fzAi6nq^q4R>?^|25Flzdo$|U7`>yF*c3hnbFA`?0
z$JLY>W-F-^$3N>h{f6))PVTtdH9Ai6&d5)Rm!zv?qe_#GQ#cw<>GdHU!lV-)hSLTz
znQ=Ea4B0y+hOAV^9ouW(m?I2Qj*0;FzGx?Xp<fv5M><yS0wlOQka46VzOh#rNq<Km
z%KH)W2jX$8s4&!80J-RGR2agmm-}CVw^~m~_I#s`#7>A+Dci!qed<}<b{|QZSiVt(
zYrU-bcK4f4<oy=IdIA+s9;@{@B}CX`S(<ND3HUpsPU#K#d)_=WpQ3$4+)MqnH~u9K
z7dU=eQZ6OW-F^FObsYNTNAEbKI$Pw3)9l4TPUa6*cS=~Uu7hG(bb+}Qk+O9&vWNJ@
zdxbT4TKASmk`E>L8^zyRPfzV6b(5F-Z>#$~EV{Lf#B&eN|1Ydndg~M!+rH!DSDjXI
z{9}bX77Q=h{onslwf}3C{z64i;CbqYS8ZDP%C&2rn04L7SHAK6`MJ-3&9$~E*SWCo
zwKY$<_NNcFR>^5wIBkw@%8<NEMTnR*e^Lis4NATG3Gh{LyNLewNSmRXYneXSiiqLe
zNJ~3nJt+H?ZvjsRH-g3BonRUG7+4QJ4*Egdr&*4r_PbsQKFxJE_}`#}`Ezh5_$%;r
z@YmpQ!ha4N3;qV21pW_rF8DieDTteNGx!HE2EGJd3H}L`w$A^8lCBa&f5X(bt($A9
zj%OiaWbKr^`?7ZG7;pl363Fj#C3q|-{zw{2HahjD@YaoF^Gcf2Be>T9ihqq+?wU6`
z?!<mKlI^Y(d)%^o;4rXEyW7Zb{e6%<#>yR4g|!Y5<HeqYcRVQfPXJjCCvA^3&n(iA
z{t$RFI1{8kPFI7cffs@7_fLNWoCbD)*iByso&ice%?3XX&IP{!G8L8nB6tpX2Y4=+
z;e{I>?#Xwf8_7;z2zwGw8<cpqX1QzD?!<mKlI`w%>~YH?&Wab7V5;zza!=RKs^0GA
zdbDGY|Fre6C;VeCE%70(Y9IZF!6esB;I$xWPu~PKgOqJ60B$1@`?Gc~J)U!eak~u>
zJxq6VZIRe^B2WZw<yy{2Zbw!j>yaJYdlSiCZ?~QM6OZVBescRrXAk!ro{5g3&B#{d
z8AR6JRdZj~-;GCRArY?EAeHhPanD%Z!0)ZdPGk=<n(y8^>`ee?A&p4(nadCIY#sLo
zJ9oJW;@z{CH}TtD!zbr2%YN_?@Zg@qyp-Qt@pqtgeFd!RbJzB@^IOhjUW@cw<A?ia
zxc@RJg{=rFL*mFf<Pl^CGM<;Y3^C@t!vIBmi01!;@lJmzoYWovcdGku0hN^7cYjkV
zHO%LDx24E^92DIHyYABM;cznG4=hKqoM@|4ZBf<sty8X?f4l~+DV@%*gRQxRC19<`
zqjdgx`91n@x%Sm9sw%^MVWCtbDP<>O2bSAOSGl3|@ulA@-=c$*n+iLSLfKxGXyxe$
zNbi|P$`9e&@gp7yq~vi!xGkz|tA41&%Zt={N;^~Sbh*R9(uHMCpPSqI*#bM-8IIzA
z%8tk@H@t8&&t8X@2f)Yfaq4~Phw$CB4pwpM3MPu>IE0kVElb+5Zd+FR%t1a>1)fQt
z5B=b(Jr}NdYu<u;@4M@eH*&Y(9ym$tAN9S)8xMZXKmT*5m7X~LH(MV^uM8i{0?&pu
z_N?1pSUn-McFU)0ckj9|_qz35ZKnNQcb`j_(DNrseERF?Sq%sKqw6QvK7(BA;&ZhT
z<=b2W-@2@-GA!i=IxSbHWi8)4Dc6g@si1r_7l0Ro@|~4$rQ~xnh&~?m4W9zGbA2`#
z2GKVo`fbuR;AP<bAmuLoDA)!50$d6123LVncCG-AApbrFeh9n@EC)XhHiDl5F9AOd
zwu7GqSA*Aq*MQf9UjT0ce+=FN{vNy){2RCdl*Ytu;9=lK@I>%Va4PsEa31&-upPV?
zOn_enuL4PPTHf_<fMvvY4IFGj<U1calxt)YvK85hjHW?287V`WkX6XOwj-o{;I;*1
zEMmk+zRO6y^ti}(-PPqX*!R4eO2Pe}XMfAxZ}=L%;o0Bs9bAiEm+bGie7pPVcG&<Q
z#ux?+1BL;^fMLKeU>GnA{ChD#({_mZ|MYvAVol_6-e1=L7Z=FbsH3A7U82fJpP8n)
zMU&c^#`6L?8a!g!PQ^g={guW3|I~b)J8ypyZfiY$nZW7@(64s;$Hlnwo+|yt*T3<r
zUwm==&LcPc*Ik9)d7t{B8dv9j|9$Dw&l7h#E@~`Pf~WhE8S|%)mzH=lG^X|$%UHLh
z<)IJKmz&5BV+;d^0mFb{z%XDKFbo(53<HJ%!+>GHFpwt(r2iis68(Q@{PU+)vcgps
z6sw8naL^eH$cNrP84D=z_UHm|=T2qbRQl91SO3Rx%#m(BRK@}_5t%#pW0~Jr+3VQA
z*Lg1M>!nZr9Ddb$QtjcSGcMq+&3#0VL9h<XV#-n0XIU>{H{CDXW;FIi0ts)(j@YSi
zw2dFhRH8G8D!^0rwl>#W;>JV96Z*zu5BDmOyVdx_s2k>AcFqOi$7d{g;!DF;zrtkk
zxePcIcs_gR>0e!R`IK2RhW+H~JEmO0gz0ZsZ&cv9x8*yxu6^Yz7hN#*Q;qc<b4ne(
z29xnm^QP8UaLHIm&zUTRBv1I2WXdqbHva8G3XXNw2+aYTkadVLh5^HXVZbn87%&VN
z1`Gp+0mFb{z%cOMU|{Ix|LrcD8TfECe|>(@rC-1teF>2sX0essAI#clnqUpS^Sq7$
z0G`K^DSx~z*2{{rGaf$*=(lS>;_=>A=+}-eyc#=oi<UGr*86>uQ<J#&H1`_o{Jzra
z>iMO<3;g9Zi>vBuYy696${C{7>iJxKj`C(bE^s(*g=1N2D|@61SS-yWy=Rv*s5{tM
zFEptza_!G`&V!cq2<K}5$IC(j%<Xt4{@((M|HaCG^cN@{{aOC|lXg4yWFM|ze^a8?
zLX5LU7OuNq#j&WmX8IhlC+j1;U@=nbX-A(xP)04(zJo1<`y_({C19hIHnopI#t<Am
z2$DE9>FZ7WvX4Ui`67b|jHg7BihDmpBaxOsaG470c%D1D3&Kf%lu;5kScp4`Opm(|
zQRs0e+{iu%iH|I@m=3IW(xKvWI@bfmN8HK2XRo#^>r3Qbjpq4D&9lUrArp&X7G<`-
zuEv#`2PXQIxpSMR^H26(7l~8FyH~k%{*BK3E?7N--@^MFj-SH&S@Kx!{j%rYnQ|{X
zFKV*#LgHMn*Tu;DAx6f+<R?k8e#^g-8?wt@G>}N3Du5HHm!q8_5)Q7MI~Sb_t>HFy
zuBh8MQ}LF(>~EZLDGB!y9qv{gu9S88Da+80BA=TF3fGP<4<};L4z{>tg3nSJko9<<
z;xI$!*F+io!>|uh#X*Ra_ag1YAsk&ETjtbDPTDHPa(|=V1xcIxzNv*e*b^=#ZHFM@
z@AhjIr~NA%z3XSNJ@*oZTW9RhaeqLEai0!j*JqtDdRKT(0Q=&<n}#wez!>(>sx(OX
zkaInD=`@J{*_ENYacN(|aP<Ui(P3oQdo`4S?Y+u?suSEoCyEQute^&q_nOz!iLdbG
zhBZ+Zd|_mmQSxL0GMBJ+^$Lr3(9V=F2}@Oqu6_(v!QrmA>8Wqsu-59Zvfn8Q%X_2B
z8(j_b3#--9#Ig7H$W7O5{T{uk!x9eV9g_FydxTZugeBzp>KhwUfkdh^&a=VtN9v4X
z>^b^P`mb+`Q-9~$x3$0LdvxR1{+!>E>pYNL`>mcoQT*?}pDWk?H3|&&_x)U#kQzr{
z{nFPrJY4*_suAg6>WBUZ|HS?{748?i#(s9j+}fEBJu#u-2Tv_v%zJ;&b@?L&wZL=P
z1FtOl$d^C&)3zBqmVEN^C$8o!BEDPihx1-Sl+6Oq_jg@(d%<-t)-3$i*hgP_;febX
z?EDsa_jG$mbR%1`4^iG@`BsZzk5^i*D?xb=&IjdPaL-QXzHaY0?I3Y~GS4|{T$z_G
z$Nm2U<-L6cJPzCi7J+{Or-FY4W!~mBumpS^oDaSMUI6|BTm-%aM!<i9%Rw4)=}!T}
zz?(qyBd9&=qd@k&SqFieK=dV~p~yN6d>SkS{{|ijN@MUSP}Z^@4RUV1<pnvf-Z~i+
z-3q6G3qYQw>p=GUr5Axy!ArntU<fP*g@c)396SSD1<nSq2IXw_Ye6}i{U(sTf@x_t
zx@WR`iIZ;EsJ5Q?#h;o>1C;--f?h<oB~%+D-N)XY`0Lu!-+onx^|kkHZBObZ{e4#7
zZ3$PJU6My)7V>xmSOd!UycQJyrTpmculg>FJF(}MpC4jRu73(j`FRGE@AiL#;(j}#
zzpZNDthkr$>01#o<Y`*muLH&X=Rhfcp9iJ9-U1eZvcGW}_$6>AxCuND{0b=Ti@U*k
z@Lq5UxCLwm9{{C1eG9w{{5B}%>QQht_!xLC*bPeg`aZZGBz{WQ!xJETBdw>v`#{Q8
zh8O)!SKs=+ygZ9NN!N3rr0ch!ydVDq3NKznf3Gv|CDdff0sLm{>2Iz221_{E_U2{T
z)89!|Ui#W&?o|0F<v@SqRJfz@EV~>WhCPXI0Vw&vCo#PVJ8O|0NWn1b3?zlzjl7H$
z;XyO9Z35Rw!O`rqMe2}k++Tw~?fe!c9qW-T$dd?pn9(00IwM?t5uz)?-4`lnGHu3B
zcYmn6H*^i{xW0NJ20NEYbUzHF^Wjb6(pTrhBZMh!gfXL;lSNKP<{|DL(Y`t#+<l^b
z&u^MQLvS-`m@Ey#gW(2o^*!X&^?;o^?5B_o$aZ8j>(%R!2(k{@fsE$cI0uml;?0OL
zh5^HXVZbn87%&VN1`Gp+0mFb{z%XDKFbw?b7+^SKi1z<SVu4VwwJmG^ztt>bZih2g
zRNpx)gA2pKL@XI=O?fBRpX#keU3^FQa#<hmi*>}AyGbzPQ(btb7u}V_br+IrEIyYG
zxLmr}a?Kg!(n+_Pu=hu2-18@j{r+<mx#l)<>AVxYy8AT7rN^_}v8(5p7#lH(v6*q`
zK0`Jm#ayS6O~{kTPGkgw;zdXZS&Q6_bQ9(_@O4DSnnZW#ItJfljL1t~xMN`M*jGMv
zqq%y~a-B;q`q28GO`b~!TK0HWU;SqrNry3p0mFb{z%XDKFbo(53<HJ%!+>Gn--Usp
z>;I>sLDb|&JDmdn^0DXtK-cBVy6^dVZDkYvS}{i=l6D@cHL&pwYVC?%$C<SdIZIo>
zVCyVp9r;Hcf2@(LtH@rf`lJq5*4aq7tYJ~%Uf(O+&gj4)55C4z!jkb3Sp&1bI_Yzb
zcjOwU_{*s>uCf0730;Z0*Z#J>F1qaTw^rU@S-HkLa*ea(I@c-Jn$28m4|A<u?S_ki
z)}qcjMebj5`!63YC`}!H?Ncp>e&p}Vl8k|<@tTU7;4!~ny65zR;uCjVdB*FH<sNU!
zwe~ZY&V^j#Q@M08?C*HfeH5$$&l^h~zW22^5`TDT`!$mnJ$Un{9Gwobwn~?ARrZ^?
zX1FM`#!l8$>GwgM2gFcOW=)nZqiXF|Uw14;Qtnu$l$J8ha-j6-l=VT^W9hM~hZv*U
zgu88sjB#b_-Iw)M?)cI`YpdEByUIRyN6y?4T@>#5I@xFI479eY@4BkJt*Oe^yDz#f
z+%;9A^CDaKzO1JjXf0L0GjkY6>-MsS>v-%NV;C?D7zPXjh5^HXVZbn87<iW$kT!qo
zkm&#G>B%ON`O^V#pkn~1($Saxv7B?Zzx_qJfb^^S>-f*rKi=PdaIXGtzWSrN`knu7
zdk)$EwqNTgUS>1c2s*eEky%JJ5<*rX>kzl!+PBZTuX}>ztXS!@9%z4cuzf(;eO9->
zdZ2yPcd0ru!59V%1BL;^fMLKeU>GnA7zPXjL&$*i|67Kn{~x!Lb}*%v|D)q-UZK@|
z;OqYjy`o#+IrmR=nuwA9m*|1`A~Nwz*0$fPbh7y?!qHG&c>|$`V^N+BHgA87){o?+
zFIMY`S9Jv1?D>JDjZ<{6IeO=q8s=GIc>olBO7g5z-3w;|lKV0TTFO8CscEdV10nV=
z$bFWqTg!08{fvE?v(KzcV6Iw>==%^I7fjn)e>;JHUv<({m8^+HS0uuzKug4~iuyVe
z2{fmvsH*fW#cF@kqtowd#~;xxH$&`6oSMNmowzol2F^}#y*DnzO$l}~TxeHve-8Ht
zO5gcfFWXY)d&QiCK(jh0L9UAr9&3@E{=KBH$kn1J`REl#+6bqP>CvIr>i8$=oGH&l
zhu&E|_omCe?6lW-;sd6g`@PCRcG_#C91M_l-1N%Zxw^cH{tz)M5XsvFGKuoqt@Czq
zAQBD*Qg(KL@1)F1T!ovy<xuig%I8spO*v$%jV_?vlV^Zc<CKT8+J>HI?%I-eGAh?v
zj$CUqW=@f@vl9=WHM#5Of4t*ouZ~{&?5`i?&B`?fmupQ(t~DzAJ4TjkEG*ZU-Ttn@
z$TcRoziV<{B`?|$U8kwKu9$0<4OmTxn8mEMkoxb#AWK@T5LgMef|r2Mtn>@vPkJ5K
z)P?CUfN}6PkoqevbtgK9)LIYjyY-E#ha^1FmxRB{px#sI-@z}XFX(nq>Vl1+gnu_U
z54;Dg1MdZ;UfK*woWB8H4SpAt`t4Cr(&<HXJ)r6b374Xl(Kqx>ZLf=a`khhllGq!A
zL=Z72V^7|%)4*}y>7W;!1{Q(5{OPm78KCeq3#<lt9nu$r)M4o`I2Y^ysjJcn@LW*V
zjjiGLCS)5@dECB_CEh)rbt;IA6Yc=tL}dR|wU_jO6Im4Iu5%e|A5}AMo*7A8Kp8*W
zgH+>wU&ayLeN~UJpUd4_HPD(D*<a=A63QM!+{1l$9I@|ytCxw-4k4ccnyp7@&hgHf
zFn#x4EtUJoCgfSf7{h>Jz%XDKFbo(5-aQ6rehkt4e`saYFZ$g@PkYb&ztw!;V*oc7
zSQ*{V6Fd$_G)a`9Nn_2R2eXleEsyj%e)_cj?0EF(i<kbDcG?#*y1)1E#EWP7(l@Y0
z^@XZlzjghZVSgQe{l;s5++1+`KXdn~a`k!kw@;F*Z?nJa8gliuqzx}^am~FYc~Xf;
zm%j)RLz6cxNK-W}dBy&V^a!{;5WNNuGA<(RXK6d{Yr9$6%x-&mu(q<alU===ZacZJ
zuFZVuAb3v3c#JU&7zPXjh5^HXVZbn87%&VN1`Gr50t0lRtV@Sv{=XxTYPS;!f5=Wb
zGx2H=;GM1mcpz&GV4@xaIEge!I=o0VV*t&)#sD}&t}|&TIAqU>59bCZnL5X=i~&pl
z2Qa<H0L0GURNsB-tDpVM-QT|V-nOR}9R0xfEzLc9t96)`#6?VY-&gf@xpx$OUN4A$
zY3U=6Ve)JiVvJ$HFkl!k3>XFs1BL;^fMLKeU>GnA7zT!#0qHjn&Hn#XdxGWf{zxns
zh}fCFzo+>?=l_celc|s;X93)wH3lH_^J1jGEoK<v;d%20XB~j707$0PNy+|RG4eYn
zGw<s<02u=q$AZ!V&zhrJ9=SAi^4I?Qf%2zr-4<VzH3r~>nTbpG7y#>N(|954Rnrp3
zLqXyG?#Xi37{h>Jz%XDKFbo(53<HJ%!+>GHFkl!k3=Ay;(gz)y`Tx#fg2nf}CjSZR
zozDMnq;K!;nRoX9^qv2Ye>Hm#fXx4^s6-<Ea8%X;2&4Nm_rHb>r3Iek%3)7TO)YJ?
z?a<%UKYv0uyUX2m?>fBwn){zazrWe^{Us}mF$@?63<HJ%!+>GHFkl!k3>XFs1BQWj
zfdT3N4~_o6wq$!C8j9G?=Kp`?`G3>c6X5C&d_=DoK*y7;!?(^r+QzYW-5oPn&`{|_
z+t+Rfmkp{ra1wgcit*zj#wBV!<y}ELE?Nic?O-es;=Vke0}fZZ1<P5A&=LtJ*%(og
z2y`$KA$r$JcwV90`(n|Q-Ida=#cd_eK1}>-J!Ro!Jdg_FRNG>$!zgr9IXV%?=mik3
zWB+jEFUT_7?HV{;zF0>`MmOS8><(bm9tep;GY@mcU!J$~JXahgeQ};oQfbJLTNX$K
zGTg)!H@;YGS=d&zXyuD8H#3#nMbQ=Lb*zfE#_&$@<^_2KH;&ud*4CsbF_bvT(28uW
zaGx!WB~Y{1sm6XpKc3`S_H!;3pQ7`jjxv%<&s{DZ2)T4b<T@iTmma#$!$pDTto4Uo
zb^NQ}>3sTs=imOHTR)BBvem?^z_a`5+iu(Xa%-pWh{Ml&<PU+5vgf5p?(g`;mp^`C
z^u`%y9(Ka-qBk#n+p=y__aFQH&kG9ukDmA1#F{UEvg#-2p#$LrvH#PL{_Lr@|9ah?
zm7h88sBc{JVZzL%x9)jJD)5Z^&{5?}zB74jDmrc3+!v?JR%CI1;~kgne(Qg|&z?E;
z&#PK0?%9k^1{Svrbmro#IFa{2zh|Oj&FVs={$W{-GUu}<W&*$JLCK$wfbxE#%TDQu
zOY>WoXX|x-i+k45ShAN#OqxF_`{>Y29}j*GWa!TNJSckUZULnLYy!nC(M{h7-Vd^L
z$NCz`Z|m#eGvLGEOQ7hhllSQnP;?+}<6V1}0=9;G_@(s0?clzgy;+8&kh_tWks|Ci
zBckU*bghZrv=_O46Zhj!wXAuF(w8>EvKsl_4z5DhBkf$fdM@0v5WBcHVkDd)mB=;X
z23&(|KsF;=5m(>EMzK%+jz=mH_pFIWxWAR_oyZ<!G;y1NxaTCgy5jbx|6(V8tQ!pn
zNVcB1%7eI%xMxkgiM?%HyJsU7p(Cyi=|a{beRac4m_k`Wj4=!t1`Gp+0mFb{z%XDK
z$Ug%#GlyvXf5?t7`R`A%{6Fxo9|Jhi+cO5Rl(x8-V-cFAY8+tIRLd&)n$oo&i`$6+
zN(;SC3Y@h9G}i|*CG-{483EE?`5NO4wVoDsJS@xfC8b}G>%93~eWm^Fi{<L85{Uu(
zX#3lT-KN$*oZV4+W5v{8-BRS=^zAPNmeHx--@a|G^9EPL-Tw4#bLmpgrO)s_3VDI&
zjU^A?``R0cKRmSkn#qeEy!lg>l}p$B{`Q@vZ!7t)%a1Bo-CWbn%jiG!(sz`yb^<7U
z+>=2WYd8@7hkg5m+5N#>{lLL=9$rJod9Xg8^!40+p7inD{#~xV-9TsFug&oyL4`4f
z0mFb{z%XDKFbo(53<HJ%!@v+TApQTLng8cRx#en;eO~we7Zu2POwOG5c-@a@`brt5
zy{s`j_d5IV{n>l}GqJ(W{_Od0Vsf&;6I^)Cl1G1c<5gF#c>ULZY5m<#d)EHzu$YN=
zOm?4dEPXt=dl)EjBWg<TUo&%C*O>V&p~e`)fMLKeU>GnA7zPXjh5^HXVZbn87<iW$
z7`py{XDS>Cr&c;g|EYcdp5}L^`|kv6j9Rz7i+T3p7W?|c(Qqov;pvy#A%B3A1|t#X
zRmT)Aprie|vV)Gl&WP>kAoO#>dRI8*mlgOnXF@yn3dV_FeeC%!>kJ2%`LnEZX0#Lb
z?!Eh)9VONUj4r&IxYR9L($HA%_eqvc;@;ETYpnD8N~^2qm-;U7m)9(=s;{l_FP>>J
zj!<2=mFKgq!wAW;o?{MQ%o7OX3D)Dt9Xx4f;WEP?tt^T6$600J9I@bxZOp;W07k7<
zaM#q|j32e0a7Uoc_O}Eaoe1Mt7hj3PThueoxaYUnCpy+w)V)wF>2F7?qn!}{<(bT7
ze^ote4JVT5TGSDdXEN36Jc|Uf9&z@cb3Xlj%3U<&dMWGny|{7Wmbvc_ghHIzki^~a
z!u2HjSvaZ1-gburwf=%jYnk#dtd@hz-UyKj&EvB&FoXFtBJ=Q9Bj3b+^G%9J3R66m
z;#dfZQ)H!oIfW|Z&t^x)jB-p}XLv2fPiGBCwo8X69u3Ih-nbBMA5v+GsZAw;h|84Z
zvy(5mxRSKb(Bovq@{(f?c0i^7N&GEXr_x@N@^vN>q`lE@*~{3NH*+S2tAFEV?QaYI
z%1_qot5Y?-j=%a0&Ong2DM1m{S~%767!{6`wE>I@$1Oh&pQ&~-s5RW;lshR0vk34-
zMAr46=Y*Hp6XLjut%!!BZLTY~Je;pNX_5gs49k90+$C@2M9_`B;!cgy5kP53pf$w_
zB0bfOKPYbZRwkzNT*7q2+or>lHAljg<gJ9aW5DoQ?A92R^$Boa!mH5fo1+ILrA$hA
zvJXPSE4VpZH;S7+(T}3FqXtr`K(KwE(&mP>Nr!cW4vSz^SapMig?5<z4QnfV6vWsF
z=c!oD$ge2N@d3lK-Thb;g9ur;_xe%tOy0*5@VEF${TQXxMuP+<_ocl4kGhX$+oak)
zrS8{p-zjr)v`k{T9dh3JrQCmB+1L7Kq%3hy-rZ)<@vA3}!C1)l>*wuYRJrYW9%k>8
zJRfVFRrrXLUgf`2&pBh_#iOx+nTANdpNbqrhU^-UpH5y8_Y=DRWqP9y>j)i|<hz7b
z%*Gq4Y5o4YWvq8t34&#1;69Zzcf8*#6*r~|k)X?vm*A+bS9sYeN~EwdXc$u06l3oa
z#kXz?q*lhIjAe8CoDN^kt(Cg;EkwfKk}LdJw5JJ?bmAfT>Kfron@pXT=EgwrkUFo3
z@SjCiU}q|unuvxfe_rs<D(>N^`f_pY)^|0!J}5YZo0!ial8jFvui?g8pPg6Kve8&{
z1(_p_B<df3(D^ht-$JZQ9VF$tzbR2^7-x+vT<!Q-R9!QDy4aI<rx|=x#gWed6EkvO
z-h(;dKeO&<KK9&qzX1caRfLZnBxDTflFIlvCrst0gzHQjhW1`|c#_Xfn?$!%dOoQc
z&KB!7!{{+s#+-vl6*pThFa>X@b)vd_55ifI)I3EJtm4iqKeW-W4_5`NXYgORt8n}l
z?&OxbcXZD^<xe)BHJ;w-bNO`d=i;-bPuow*i~C()tJD1<!k0M8RMp6Flyiq;o$dtd
zducch@Livb{Q-<B9};&-#GNY7g*!W$qQaE$-S@mmHuYiHt|<Dl)n36v34d3w@cYy!
zl&HbJk5b-xh0PbCBODE+XeUT`5;x(`iCb$T)}gupDsI#Cd$d`{?F#J4d(?#-LEK8%
zTqt#(^U6DMspQ!JCc{G=4=3QZ*3;S<4a&A*r_4(no%dN+AgXEYywmPJ<}T?BU@kx;
z9u>$${MzBfBaq7K!|+IPBWWAJWa3l8!<{N$ddJ7h{ej{m@8A~rND-G0V&{-sojOT)
zmNMX^%}qlliJAAz<#eY`3*8@;mT91*rNr^i>9=uD^7lZ}AZ2S0?st$u-Siy>+Mk+h
z?eKeTEq3W?68{fxxax$b3x5CA-~DmqxBqbS_t{LFueI2@)<ox8!@e3`_h;>PuC>^?
z)^s1pT5NeIb^loPo4dJ|dL)8~p*~MbkvkWh08-DSr-LQn*<d-?0P;?y<KP1DMz9L}
zHpn}deiU2?O1YsgntmMQeOCLFujjY!SE~MIH`lBIQ2T`eYa;gKojn%hb+e8Gr44lg
zI0-xvJRLj<l)8X-DNP)tEtkF!q&`lwCtCJRr&~bkX%$cGrmy6B2KaIC4Df1@@0N;}
z_@(=Ns{JDS+=p|o2odvzk63BJ4WPvDHt<!j9npO{){5{BA=3V7Ld1Lq|D~;Y4Jg&)
zb)cjR&eEjKS_i_N+K;^mT+j7IAg_1&!ywBw(jNhD10}p>MEAo~|E!y9iBBUUrpx1m
zw-S`_J_?QlSApZfD?zxmt^$t-*MKL3p9G~|V$Hn@r-a|S|CL#@KazX15HV5gNxEX7
z_<tFAB$xuF+;oBx-=&D|SE+pf-CU1Gsu3{{U{Cyc5G(+{1xh@>1A4*lg5<S@Zi+N{
zY&{0@np@qV_+NtPzLX{9q#MbO=MS(a{{IIkJUszQ`TkE(!g~^Q{n7m-)qm>dS++ly
zU{Cr~e()5q4Xg(*1)ITTp!idV=>CN2XLNJ@0i+BO^BL?(e69f{f35|O2CoC<J8>ge
z1g--my`Klg-#LixJ7m%+{>Zx^=2q;<^?l$W;QgSa?`zt9oZq@Hp!x{iT#LOBBIY}m
zv;O8`P~OK!K*>+uVHL0MgOcv8pz!~n;F;i4Aa#ZHG&mppAy@|f2$XnlM06j(lD<JV
z*HZr1Az~&IKY3qH1ttGZ1E~Y7X<#u}3{r(#Gr@)6Y*5~ZIiSS-Y%m3$1AY`d54-{_
z2R{KW03QV_!9Cyw;6K1>@GWp5DDhm2==Q$q2Xu2O<zy8ihH|XR5AUYZqi``O?{5&4
zc-r7Ba2Z$yMnH*Y2goxk28Kc6n!X%d4t@+=39bgIn^b(S0wq3PM7O0?8@rop=(ENn
zVo0m9SI2MN_LRC#@ta-VHeyfSw>v=LeG_;%_!Uriz6X?gbu&oaY261(_~Nf_Q>wOR
zH`m$z{sentxc76=3qA`LfzN@{z~6vUX8#A2{M!M#{_6Iibp`jkk!*iSq~h5FN_iL#
z9t(~H7l5Nd;r9@*3p@-If5{)WeW%)e-CSqaGe=|ZAnqLliocwXtNfh=p33!cpp@$q
zz%#%T!3yvsQ2duX)@?3J+G5>E_V-~N_Qe0gK}r9S;0`iuEh4x#{THG$V-0R9DNs*R
z8H7%>tm~0SkR8Zqh@FFM!p=5CbY$F3K`0u*`v_+1#n{31n@ILPsEH(a7k2yZg_^_t
zzIrj%cxmU3<o)2;h*6Gij0j=7x-r)Bdn@;MA_M8h7-+B5BNJ$2kQp0rI}tn`nTJ#(
zeRX8);hyZD+Kk<HFk4rK?4_D;OpmS%r5l9GL-b|LIlf0{MmKKz?XTkAGuYb+jyQ?$
z7*dC<LN+5ikb;xRV<e7jK(-@$kfKxgo+Im#t;oyBh{=}aMT{{F7zPXjhJpWk42&R2
zL$m&0#^Gg*)mZ@Wuhjqd0UCwwxLJgDiWq6f^Qp9?eXr&$?v%D?+F#%3^H*i&M8wXy
zg|A4X5-ka1t<u6O+?Oi5r>XHMuRPL*&$?^Wn3~MfELC=$aWxr-a^tZlM?9|2ibta!
zp0x3Gpm^M|AMtpoPdxVEr?lDfHSUsYoGd<tHiu`yn;+OQ_fy}we8SRm|6cz3xGyp<
zMw@RSy>hv98RQz5vWAI2{q@j=J|OqMzw5Hw3$A;yX5qKSKKjxNPux%6N!j19#-4TC
z3#%uD)^7Q9?e1L{($-b?pT1&L+o(I%|LLMzwye2#%a3Sq=Nk9gUmXhjJ3hCX{K?0-
znzZXHk>Wd@zSVqwHzT8vd59RAe@_1t^m0ufL5-741*M&TDk$#>{R7oc5dWNV>bytI
zTxa_?3w!$AQvRLAwKOBo2E{-8QvT7WPSf|@=f1<6$J16nfwnbLhBP6Y@K5>+(g&%e
zGRy804AdX!+ZT|2fb;>}wtsfJ-_?cJPFc!s^FPA1s~1n&{i4@T+Wy(?{w}Vw^(E}&
z`gGd%x%4JvxAR3WUca_I_fn*H9b$}Oz%XDKFbo(53<HJ%!+>GnKpBw!f2-wDJ>1aT
zra<xZCjW|9Vp-GdresqU+UOG<b|}mejHczmR4f)rHbufM!H(24SvIrWjwfQ5`lnAn
zYt9+7r=Kx%dQ+_B(oj>NBQ$$fQ%3*4-JZui00+9J-s_chM9vz?3Bw$=z5>vEx9&vR
z#xW*-zh2jsQB$wZ0PvSr4!)j8*1X7k(%#MipgU>h(xWeH-I{rx>l}b~p6yM?zRcYW
zq+{P*L)Ta!>x|?Kfmo8Imum5<JoDmCx)imZ1r6C6_T4oz|4Lo>cb+bN;6rBFPp|vn
z4cm7edhBJjV@_d`aW(PXpT6<_t|7@amXT}BBG(v1t}zAalS_W;@+R|?Y8{#MnVS$X
z^XVH)*{lJlfQ_KcK{ta{U;tbJGB%W62g;o6=fEg<J9rr=<vIb1zRQ25&id>*xqp?e
z`o42;(jU+6i|5i&{~+Y&(o?@xGR7FgfMLKeU>GnA7zPXjh5^IC`-p*|oBy|?S?d4j
zd(SKMG{3X`|FSoJ8vR&z-zn=Gm0_u%GQ;>UdtA3{P;;IBWP7YL!Zz;AbiSWBg%h!8
z2b-O-EBi?tm;L^$`FpnyEd8)QslMnRr<a|(>B(`QIONqA{_D!Wg+JS)2T+G;xp5IJ
z(%z1x4<<iZbDWkq5@=d@f6??Ggcf5A1BL;^fMLKeU>GnA7zPXjh5^HXVc=b0VCee)
zt&vn`(hlWu?qB-<M|oMV3omim$Y_jVz%XDKFbo(53<HJ%!+>GHFkl!k3>XFs1N+2)
z^reS*{eRNk0FaM000+AM{}^x2`u|xn36FUck-7bc5Ly3k-8b<1{{}Vy$XWrm0Ssi+
zT7iG{`u{n^EZ6$~VxIX>h*j%p2*%=eqdEYAd++DH0Uu&>dVy#DRqICm$I9Vz5}w6}
zEV_Ix>poVKuJ`-ifH-N;Wl@#UE-nv2LUJGDWBrJf+ggyl`%3R*3AmVR_6dlN#<U*{
zf-F(7+Q56k4sbJw|LF(8Bq(K{wJ_=C_u(Fa35)?&X6@a71Vshe`}aq)FMk5!?&Dv>
z?{$c~cfaqR{eg6Kx%&i)3F~h5?>~eb$X<bJGhRtaGsZAr7%&VN1`Gp+0mFb{;9t#v
z^#704`~NQ}udgYuo;hQh9HfVt#+rSa%hq<eP-ZN8(jV$XqjWf!h$UmKDevU^Q@zzy
zH5bU^6RcrMkAUjGaQ)oZq(4mqeF+E3*cD-p-D9itsJw-DvJP*jiW@riIE<nvJYOuD
zj797v`3-ZL4paI|VlK{v84lUL_CTUBwy-mj3eR7e619DKP45gH_6{BPo(E)~1N<(E
zwg;l2h#e|-&%1(bb=*~6!*}^^)Z-_2x%t}|NjBK2#eqm?-qY-c`J@hWV^)|8hA2$8
z9M934IW}j7S&^{wo<=vkyLEWCW`$Q8;k>*&m!m1V9C_vC$4vN!E=L)KlXZz$P)=OT
zZ~2|A!`-CA{kvO!DLi{A!b4JqCyZ1{w-WCAOB@<fp-S~0<vHDM8NNn`xysF7!mQ?G
z%<@DchMtDJrqj)1(QPPZS5`WuCa#NxMY&74j4kD}PIl|4H9Fi#R=DLoyRQ}p5@8vJ
zq;}44_-_4d$%hNGEh~KeMewB(5htG^J)dcJIq%Y8zv!0l`c!0bIFafML>v_>#4DfS
zy5;L-9d5`iUxe!fsIob)VY+oz6M8hn{QkT8+nWh9ziD*2eMX13Ju8iM!N!=B=}LVv
zZ9chm%TpcWeqw%?m8aFQ*s{)eg+AD-Jeo?Z%qz!knxE8RKbIA@FAz_4CTxl{ry4VW
zo6j`6c{}G|C(Wb3?&d87JI%PfhUb>w%{siX+2Qpx<Ax+m?;%bapU#x0Ksae<+EIB8
z)2$mf>M+0O=I4c-c4B3no#4>d4mobr7weSDSz?yYe09sygfUK<i`=@gwlfv)OqJO!
zoox-N1gGIG$!oaoJG4%R+vtXyX(>0xmgwelzSHcMt<i@%Y5ty@&(*O&s5;z|2qadP
zcMVN?*XS_UX2P@s%Wa=N`n174vOBL_yXk#hhu!URUF};Kh`YI)-*V-K8DXQdm^E&g
zRZ02;;ZSuf7|3_u&n?UD*@5%=gz4if-8v38m-yuK9dh5{5SzKhjB?w~RY~1wjwLGW
zfYi-(avHE~G|y-FZn~e-;lJY6AyrBB{<hhPAqm$_cT<6r?n~V=t#ky+ncjA&t~1%L
zzJd+a;bflE?badB>hR+OgkKRM0z(*fqZ-}dJg5xk8O;JJRB3+*JNeA-bKO3_4trfs
zy4{1D`&1~U(NIG?997?t{Kmz7&l|@%Wnhf^&XMrAdehMpndkJoZIP`y%u(54HiR$F
zcX)0Z=N#^&@!9O~>TS0>p4U8f%l3mh%-?2*soDlrocvAGK<jPHXZdpZEgJ8n_ovxm
z>%oqp2ydMZ&&m!@vzyQG-1>41XMKtJv>P6SM~gVDz07V6FkV;ft18QDp1S2o9mGbs
z4`zki81AquRDR~S-Qm{J46rJ*-L0ocYr{&8S?-XKOOw)smtSHjpIp0XPU-N+Wu@5(
zU&`^&g!!TlvnxAH)s}7KAou+8?54BnD2L~tyLGbgJVawiZaIENhiSR(4i#pA!G*Yx
zoA>b)H?5Vj;0W_X7Qec|BenmKlp{G?L(D^2{7RUmp%6{0WM0E`>%r4Gn@~(;Ryu3T
z7y9bBm(O>_&Cg9byfIn%xiA*$WHdt!MM{PaMYt0=V^GX1S=?rao9{l6o8EOg+~4&J
zS8Ao2K*tchtD`^Yr1xW4`RepboYy9w9J}w#DjnwXth5f*c&{7gE*<8itaPgSo?1{C
z7>aa;COX{ysZW^FJd=^fe1_?^m3HVbo3p~q8eeugy2+ub_Z#J~R?PibVVBYL9g1(d
z``&ERVLqMpP4{&s5_B*d+Y@v=szQ0?*$uZ$4$j3)$VzLkaCtTq`P;3--P%9B`m;lV
z^BlID<~f{ED`s3)ovhQW!_IG--Eg<)aQ~LgwKI$DjL`8F$|u)uol)df$+h0>A1<E+
zJFj87Y2Bd1{Cig2=!<nQ{K=?XH2?ELZn)!*chb6N;BZUjX+Al2+ZAhcxHZ`v*X6%G
zJV}oi?9$=Q&kC<}h{{js1c%cHTu!CmsK-|G&8OSP*{Q>9b<-zd4)g)YbAGzzsOdx}
z&BNTe3N`p7U)uSdt*v$<ndflbcXhiC_s&eZhkorvS&@_04OwB*?HH2v9`5_{pbqoy
ztT2ai?M2Z^P8vU#6`niTlh69V&BygRyxE!X!qHF-Q+ZN^X!PeZOt;L++23M{v%{<i
zCz2{qY4PVbTsJS(CKddik{zxu5=+t|&1X7YZsk04F)zCHQF&K5mHBe#H%yn?$SF>k
z*Sl#fk9KxAgC0&dBhPJ7w;lYV4tI4Xtuk}iXGoZ+4F%6llbtkg?Fl<5(=N`^lKh70
zruSJL=Cy8^Wp>0)^`BH5iu6{W>ZJD=x6b#`@OBn94%xU%w+{1Rw_MRkiU$(5JCipQ
z>71qY5|7WMQ{L6g(kNAy945?v!+>GHFkl#XzcMg_i04}WKgBw-*ZTjl>=@q}A9(Hm
zd&Q6UYd)BG8wLymh5^HXVZbn87%&VN1`Gp+0mFb{U?>@o{{MdK|63kRutA9xq|>6T
zNnUQp6R}JE{xi=w>#Uix=FFVl6l=LO)D-9l&7Rd1jith^E1g3CME{>`ao(OukmwVr
z?;O@gpTNQZ+6BC&$)w%E7SV*V{epE)p%q*avO;s40>#st{3~LKWlgi2l1<4(uxWWP
z6^liZO~FKp-#T(lEuG;=sHr88w41s*QcaO?OXit>nVpE*k(o0ryUQNfPsc~s=Q4Zw
z^jS?U;b>FW%o#du9g*3yripu^Ft8u4>)!E_7~Ac=2?`|9&W1VC8dK;6U%X)$<LpIU
zp+G8-T-jmGwhGh^0C(@dM=WCm4`NS5^V80mhyI%C1^%*dG9E|;+h;g)Fs|E)dJlbH
zxAAPZ^)`D~qPTS2&d}kyd;ay3Or<wb!Y$EmCD<C3*N(eAxNk<friwnk?pOY2_W$d=
z;M}Q;zkk!`cFjTY;-RchDDcb<-G9RqH+|`_3)cMj4~u<QeUJ0*)%_(S-maNaK4#3}
z;cHj4eC^I@mUW%F|M@j9d@5M{!SDWm_Ra<_sw)5ggQ8h!4r*oQ+N4-$YN(`!X84SS
zf{M@73=e~#z)ZuSXk@pf&B}_(%1VohO3RAM%33Qbx3$)a%H6D=wX|95w$@r}tCep5
z_xId;hs(eqn*Mfw`@i?ahtJ$|&pG#dzUSed=Tkf&CHU8Fg;(q6FXr){cwG+1D1OUz
z0>}V}=orZUcEW>UnFgK!%QVFEV3~3=1ePJgp>RAr+~5&#68F;#PKU*x<?Q8F32ML&
zU|+TdYz^2Nur*+7z}A4R0b2vM25b%38u-7U0cjHc{Iek`jT^OX6D(~zX*@MxjAZ*A
zX#=`IJQxO&fqmH;ur*+7z}A4R0b2vM25b%38n88BYrxiktpQsD|G64C*5m($-oorc
z|1Tf^|LVVN{J&W3O=V6b(3KQE2cY_24d(z1FvjA$$|MS|-|3`S`f1|TdOe4(a-MZ^
zw24VF%!q`6(qAKHQ|rwJnPzkA%?6uho_ezcF*^mfzIrpa_cC_0#=INm#TIkse1x9K
z`<B!{JJ0l6t2Y~Bnmu1{Hq<n$sW%%YX7aA>^=9tOocSfi!9fh^>(6#HdNz>ZeO>mt
zM$d++Fzsw)9<SConsXRBpDS|}j{n`O2m6lvUA6m-EpskgoV4ud&S4lvN1RKS!||aA
z%rzGD!`une&!*-c$ee`E++P5n3Xg<k3#kiX*%BuScER+?X+7bIuq-vd2$rS77sGww
z6qu<Qj!CfSbuuiIK4gvq^CBG6;q&1cF!Lc~E``Rs9GAdJ@TKr**bR?^J@5oL6Xsp&
z3_|=?XAq{s^D&<aFMyd(;RwLIL!Ci53l4HW2QGv0+i?Z#ftSMB@Rjg9SmQ4rz6vgc
zuZHo<L3C*N;V6eo;cH<0aQqs^t>ao4JC5Zra9jsp4+HHc_y+hEcm;eLd?S1(%x~>(
zcqM!<d^=nT-vK`eV@G=gUInj%?}8tPaidkk_rOoXtKsM1HSk8b3f=_cR;z&@g*U^v
z)waM-z`uu|gx`VjOM4G~3jP4bPwkKJGjKaNslUT93)q*f0b2vM25b%38n88BYrxik
zt%2q=(29rF@&DGQWf~o7?4Nt7UvjI){LRNU+ZwPnU~9nEfUN;r1GWZi4cHp6HDGJN
z)_|=6TLb@hG!Tub^Bqw!B5|Xo_3CWDLT^q!yWED>*jty;AA0?No;t-QP^`}Ya5(He
z0My0_YS)6$9snUF=`#S#Jpdf{Hyr<;YK;FgIIXU}{FnF>mcAO#i>+io0QZ>8f&z{f
z4|0&}_y8yBxb=gI<*eZRq7rqA+{B_BuMCr_aqf|Zzhe!5CtxoA3X8ur5&RujB-=gf
z=Z;J^{8(l9A?xYI4`K16B7z^rrU6#j<aj3~SEAwPcEisk!%t!H(;2}}9xL~IVGkHH
zK*sM+7+PLAH#Yf)D_7mVWy1Q@K1X-_z7EAZba@=d$!{(hKi|f0M0Lb6PAiN)v@S4l
zrpE2hfqQV@5AFpcs@jWyDF+%N${HIDGqr~Sza4|Pm+|=oco@uY?E-iRoCFVr$HP3+
zE{2golkxXN*aN2<JOj?*o-ubdo<0{Y;$Fu2i($s#wS};Z?=OZuFk|s*d|!jJxMz%A
zjqfv-?!Ygt0+w-mVHvMq2`_^g6IbK%GJgJR?jMA&g&&3)i`Uk}_@Objt;XY@g=IXx
z1~$jX*Kxm@dl?^p6Mh1I2bS@184s_9x5F|%{y(sci+>7lfIo-vQ`-eU2Y&@W5C0v0
z0sant5#9&?20jQgHm|iJ?p}i1!Y{*JFi#?)W`PQ@5$pl>Woy9JfUN;r1GWZi4cHp6
zHDGJt|B42rX=NS%@4)@7r!dbItOoZ1bvgAmmo#Ri?bV1ess;PO2I|Yw?%4r$g1z7X
zXwS>KfLI{&nnwWpvNd39z}A4R0b2vM25b%38n88BYrxiktpQsDwg!&92BLYzvE2WE
zQFd{5UZ8&czYHYSIyxKs{+rzJOu<w?XA9&nVffl5r`>WOc7S~eQ)13_$@r+g5B_TU
z6Xco#p9H7CeHi?7KHEXY!1dQ+-ow$!nJg9?Ur7ToJH-(blLoJ#Pa`!-UzIObJ7GQx
zz6_*BW#^e@E`EH-;B9JDq3p1)>`8ZsZWi<w`gONrzXXWA;syG9MAto)nJ+iD*c;?0
z>)B&s;$hu=c3x&6Gn)gPWe7GjhMh-%vT^8)>Tzez>sRfaQhsp6ghwBL_{1L=cRfzb
zU)yupz0R9=O`i1JNiY5N%QqMtT|Pj}r%z4)%TKR;P_+N75!G$H9p7V}IDIb8sMY1(
zgf(AY-8E-<_4TRW?wP{4ZW}S5e9M_Ddc4x+;P4sI-{d`>L^yY<_r8Dm2XFrT{mpw9
z-*CpM&#ai+mOh+bVt@SP>~5dW+S~7VfA_j8&)feBaw_xtN>93RP-5!fjc;_F_WGL>
zy0h+CnMY^zdi}ntUTJp?@4IfsgZohKXUe?Oxu=es`9j=D!J+|M6L<9;qSkfe|F>_g
zS+jX}ZpoOFJ72izi_FVegAyz6t^4qyWmAf79W=CK&p#L4KI>=3X<Li=|19~uZQ;Qu
zSH}1HYoPbiFF$lRW-I&oXRWTw9<gigzMb0^tmw9CA?v!8`759Q(HY}@>B4>8CqH!U
z#P=@L&lA{!?u~S$(wD@Kbc4xyZMnGDB+ZfBv|qt8){d&wSo?4|iTkPWcsLVg9)%iH
zCmpIW^NH}Cm|p}luC3POKL_JRtqD(u-{5{aybYcKN0A2R!X055qmO~J;689Rd_Fu6
zo&e{=k{{;7F1Q>&s=!vToO_w8;3OT$e2*Yl3wDE8bm#$FL2@)>>YxVf0nwz7uAm=C
z2D3mpSPj;L&0rhY3HE|$(nuLt0XBo3U@u4@y{3aaP!3jtO<*h70S<un?HrEopdT0k
zQa~wK32Hzs*a`X_k1U`ZtOXmvR!|4z00<|D1!<rZRDlg(Ka(yt!`pz<UNeuf?90}G
ztpQsDwgzks*cz}kU~Az27Y$IgKc?+}Hlw4ZTi^btX>mm7|NXb`|0hZc-~Vq{WyAUZ
z<~e>cr$R0#ke|XbC!_9pHUD2%xjW$X7y1@TM?x!lPh?F&Pkz^e;~bNCU3z8~zs>#>
zY3s>VVfZbq=6P(i_{np%r=V^&tFUmI>co(J0q0oFQZfVcy!w88{zm33M)2$V@l{%%
zO)F&8g6^iek-6?h_Ws*seU=``%rBsu2)RUtE!JoHIfnHAw27&;nk(7FzsWSSb$8Ae
zR2T`&=*2;AvDz?D{EOGkB>|(Xf#;d_6B?Mu(+!~eGqj=kVAFhfL-T>A`N)Rm@uqoF
z1M`7Q`Pcm)+rT_N!8A{9XnwwFp4Py8U`U?y2IldhaCsV-4-EOA)4)7_i0S{lhUOtT
z3mTf!J)+C+Z(u$!qzA2`c}Ne-8=9;4N?P8Fe;zQ0MG~AL`NGx<PpUfJIVZ8-w)2z!
zk$ZI4b!Ze=wR*mC)EIfAkaq_$cfup+V-X$+$G}N&XLuBR3OpJ<4ITrZ4v&R<z~kXF
z;0dq<m^B)Tr@<0YBu-5NEPX&p@C+EYj+t;WOy8t78J-Q}My=!EnOd)LDeS=<sP!6t
z7@4(2a1p#1UILfFbg8NR5&5kx<6hQpTnjISuZJ<yZiLI>Ti|Qp+u&crcf;7#D&ZCI
zgD`g0euy{0PjG)T{4`tvKL_K7_5yq>%-RaIzv8R#O74FP-wwY8-vvv5)je=6TnT>w
z-w%HXKLFRkkHeqCyi5BF{3QGpTn+DrpMm$l8{qF?S?94ImUSIJ!7sy7h;D{k!^oh?
z`kgo6li=UMo!~9-De#-{X)rQszk+`cp9v$Y)*F5smOi<6;B#PP*9O4v!GqxU;UxGV
zJO=(3d=boA6KyJt4BB)!8lDBWf#<@kLD4)g{eD^w+y$Nop9(L4yTL_pci0cR;2_)!
zUIfR&rSREs85{>+2_vhf!TsTKI3B(h9td9#BeN#of+6rqn0`j>PIv@-4}1YEeep@~
zeefu_5*`ab2#<pwfycv-!V}<X_+t1On0`v_d3X}M5l(}D1Jkdsy#k{XmB0M`>AM7L
zK@G4kTLZQRYz^2Nur*+7;K()53a8fj|7}dKoMH3)F=xn4)p=cT98eW|*uHEH*cz}k
zU~9nEfUN;r1GWZi4cHp6HDGJN)_|>n|7;CJBi^x`|Idv2fVlub_WpBtWK6`I_iu8`
z=Kl|J)sI)pUIKD;CjfL+IJ&@R4P|WLIW_;^c&$GFf0eS?=wE35e<hDrbdtIH4d?%_
z#XJbC^Z(Ph*XQal@dkYQTz@TORzLsWgPHE9zD~fL=dYU;WEKbA`UC9A8iXWR_t&2p
zWC1`C_p$~-!ge;{LbgD*J5!lSKTHW=ZGl=`Anv(sa&3VN^QP7oh~E<Tx<5;lKjzr#
zk*qg(dw`6^_I!U;n|@EdJof$jwGIoSzR9xJ8?<D-!5+rBjC8Bgb3E}f9PGqgu1Sm$
zN;;SVp9ar_&xU8i(g!yOo&YoMt1(Wj)&=Cj425fq^Qv_LcfgowYvB1X<Dlv+J{e;z
z;QnK{5Z(b_27d_$;D5lyu#A~5f*FrgW5zNTDr3en=Be?Q0GGpz^Qk@kvf%5uzYM+}
zUJA>eemBE1CR_zqz|X<Az<+>mg};SwgAc%W!fnat<X^2bEMvlnFk#SU!uP`k@B{Et
znDJ-rX1EGo13v^m06z}D3_k^LfuDx|06zmCfS-rkwr2eRd?H)}4}@QXr^2tp3*gOg
zAuMCUSHdy|d<!gNz}4{E@E_oJ;l1#C@K5juaK~uY8^BUd{SjvTwZXcK@(%Q`o@B4j
z2w$HO*Pn!EU$zEp4cHp6HDGJN)_|=6TLVW;15`(u6MF3S|1S>axPy!RUUz;`uFp6G
zK>7iqJV)9O5F3M^w1eBlTtlNMZTie<=~LZfL?JyedkeGlH20WMDJi2zjk(x8Zt{$Y
zQ&T6qXAEWzC3^_G6eI1Wj{K+oO&wgWZa|g{pA5Elrd{%anpf{0Q{XEu33%O$0-1il
zH{c#LG(I6K;ruN3z{JE61(}6eIhh1&p>F}tvU9xI1tazThB*9be7RJAgS5Njd3YBR
zq(-^j{(<`Zd{d^bv`6H!%5(skst+a8pkFT2lVLKM=M8KyWa^1rG*Q^Q!QnWq3-M>j
z<jxKRQH1nbWEQw{175G&?<>g9UYwZdLvNWuUm&i}2-(|Uq}q=ml761TUsFGA@jo>x
zn3rEH?~I9&c5XY>N8?xP8BE#IXkW=?m8}PEWuh<9>u#BB3w`-Hzf86RN_V<!3ynQ0
z5+rkRB><w(aW3eKZ1Ig`EAVA6@aDL)+3g~e1m`V9Sw-_ijY_Rbcdl$-QE|}KPxR>O
z+mB3;m{?R&P~Z;++(A;Fp7y%RkH%M$=vMlPTyQU4x3WkhC|1Q>;$#g%rbd}B*UcrZ
zo~7*T!f~8O1O0C{!YJ>RJfy;jed%CmsDC4j0dHnbQ{ieh?>Iv8i#*}-OTX0}hR&;u
z2~3hkPXOJ)g9ue=m8YaA|FROVJI|ZxccVU~-hPpj%E-h-{o&!d<K43V2-L*oQel$x
z-j1iYDBahmcX6c0hn}X)@RhgKy|RX{CvIz-3!fzKBMIN3+#yO!!`HEi@ag4E!|=)8
z5OP`5)6=+>gBe2U>2TvAF>&dUMxcbRCFPYh{;cUSRw9?n8lE`9<7zHEhthk*@Epov
z^WP_H`D=|Y2~UxczqU3Jo|gzuQgh*vBCGlIXMQJKSw0`#ku8_=1xvcJ${Ccxh|8+?
ze%SRiC+DHmSN}abY&p*flQUq{L0nQuanb$fkfN(S_zQM5L(b;vAR(oR+^)W^I1;&3
zL;CiKD=8|@pI79~ak=HgJS3qH-nKZe?hKQ4z9FmZnIe}});5&&6^D|Qx=BM>Es`3t
ztB)H}wzNEHt-eWmc`5O3)}KmG)Mb=!t<+Wef|1y*)MfOz-3@A_?jp`dIy*7ZGl+j?
zoo*lnzA0~<AycF>U?BdRb(RqpnanziUe7B+mP=!Pt7K^7kSdE+=I#>dT-G|w#rRcs
z7%~q!LYXHvA+xny9&P0N4Tg-eW=*nIH;_X*ac;7d%c`<s{mu_bz?zCv$%l<E{Tpc3
zOBSm-RIow4MBFS;=`r9fE-47gz3492kgGrvBbUUp$kiM4!G4leuJG^0q4Rl;H<+n5
z{gU+9oa_?!F5YP^FU|2dU61I4TCpEHB6pS{xAgVPB_#P?g7FG+%LY)t;5(;kbS=$8
z;bo^OTU8UX^+&eK=43mxP7h1A@bc1(@39?G6jy&B@h$mMzCSh1$#&@PPkym`VP-*o
z&LPvP8Q<Z$Gv(XagnaVdkp+hl<Mq(GJ8bzP>95?VjrKG2C*z1xze;LOzC-IT;4ScG
z7JK!)J`6t_U-k9fBp!y>mrVV|QU=Inl~3wRvRL#N=<l%Qv*u^Xx8@mn)rNc*Afsdx
z32QcGXpJdf!_SM+qSN)#^f$!OpkE+YmB$5n#rP{}P5jr*0?JHeG0Wr%+QV{90g@L|
zKoRbpFB`gQC`*o)=?%Wc?t=W{pi1XW$CECPlwnEucbSqW;PVCDMI830_A7K@E{mL*
z7f})jc#Dijv?E)`Y(PI{$aNNW5_CC2?aP4jtH@hwIFPWM<TyX(Ov7FY&&A9<_fOs-
z*Aqa(w+@tHM{7EKd6~s|DqJnsb53S3Q{qOSXQ6+qbBh+b_5B&$S((Ms{~)^P%Dd~I
z`vdufUKKwWJ9>fCD9Vo#uhPLv!e55$b1;9_2%E%ZJMQ)QANfIks<2wayG=TvxT@)I
zk*IwHzLxNMUTHEurRt)>TO*E)OWt8zp>$P?!FPC=8l{I<!m}N-@VFK83e1f<3(@T^
z&R?R(c{1jMRGdpPaA(O^9wVi@czCONR>HB8**<!F=*&>!kq%;F{5;qDZnF8P@~E*j
zm9EmTXQUB%2hH;wcK(#QhQ1f4-X2!(4^7k=K%d{u=%}fBoiy7EEd64GMoPNW)3qLF
z;exmeyhZbZdAw8ny|ab>4mA7~ce?Hx`J3%4DN=DRd88a&RTI}z_6GF0RdRW_Ka`&I
zJacJGO^u`py)G$vX#1-wjX3T_X0fvuzhsZcNc&ty+SfDEKANAQFlSWbeL8!P;G9tv
zFHG|8{)cb+#T82@wi+~n%3(H@*{1d@jkM1wLSw)3{>#2S_&3+~q5c0}mNkCe`pEm6
zM%u@;M)~vB6>aCWy?@nLv+t@df3*6YS(HU6+ZlDmy&t{g92M+*)0<fxF8Ogm@!{`d
zTCDsz@y>2vZ7Es0Yj?tu*3o6dFQSb>rQR8JV~2i^O<&SCVNk30uDQSO6<Z_kd-@6e
zIL@d?vtGD+`8SWuzPSH&=~D}bjXL~&PamiM%^CH>%oiWs_e0=|jkPP{rf<0Yy2$&U
zen+}+0i%yw)#E+fM*)(Kx~5aan)Zx-=Vt9m{x|x9RU4*)d(`2GRlYeKlUc(r-^x_@
zSFo({7yreb(NBBW?u<TE)wde{zR|7pJvhe0(hf|9&G#AolB!=I++7*=<U7M$BK7IH
z+TzaWKU96+;qI~tk2H;$^Q4^$=UBpL^vfN#JBQx(Yf?@>{)?Q<tx|FZEbnt2p}VAJ
z+}&=x?+)XA?Eetbr{@UVxsY8m+)2B~10tnAqi;dAkD9YrY4|7c9d2)$B|X;}_9&hj
z*-JO<CGpH?*E*!VEAcIDv;-hmwvkS}uza#};Zxvwu(XSPu%x#nf!;1r?bC37t}yh<
z+&JYA`*CPz;zom|9eWiVO1FkTl8?gE-`&^~`Ph#`6MeEDN64MgW>a<5!*OS{r&K#D
z++79!OZvM7j)QNtyw7Oo9F{w&hZ^k<RqvPg$*_X70pwyI67{|t;M2KZ0n4}ZM&rHW
z-e?~jk^3av8})aG)ayOK8sEgND!<6vDt=Fcdtj$KEbpdFQ~KsJW7fS@o!rAcpGQ?M
zht&K>(c22_<5umJBW2{x+z*5ax0VFo0`o~x^C45<+qjo>;0H$CSJjC<+)H;?4v>p9
zt@MO$w65F}H%d?B33X<4JbWqUgWw=M7`_oEU2Di7Z5iz$7#*m6sj1ee_jV<78g)=r
zH}zo01=>rd<r<5<PH-|T@iGyXe0VW@KAZ~U7o8+~v@yp0B;$Unaeo&)6MK)sv*EYl
z40tDe2`uwY-LUMv<AKkDGhvxWnGK%@qX#wrG#92!RP$b!!TH=*!v(PHDN_i)4g28l
zVDze;)JmW4dJepV`@wJ-d?|btoCjYG%RJL%u++`V;kCH01BcpA8@mnm;I{6so!7a3
zk8N{*?Q#;}_Wt$zYv+;RHe+V)u^mnQVJnHKxjnXb;a>LHUV;BD-D`V4Zp^*5+YKOJ
zkbuqow)gNpbI)xjiQc;B_Ilo7?z!C^cd>jB&3(5w@vMq_ncJDdGwDZ`y|-8K`v90l
zV%ZAXkw9}mC2)};DuIi{S_$@o<iY#~d%-XgZ5gNndqL89gcIxl{f6)iYz2FPYba?H
z*q5yVTLZQRYz^2Nur*+7z}A4R0b2vM25b%38u<TJ1JMNh7_a{~m;W=a`^(n<_jA>+
z|KCoZi(Jd$4zTp|$ohZRGv@k#UW>WRg~=0(jW0DmDr27X|1`P&zZCNzIMn)ox+{z|
z_Vs51x<Y34djeo&uG?2<0-9sO;p_X8u;-_Lhq>6yw${g=C7ybM)ToAM2RbopYJI;s
z2AGFlB8|o6&^Of7*@6F}56Brc=Y*HOsJW}8uxCpCvw!)y>^plce@oW#Zzn#CG^o<1
zqz&nd-3sKQyG!-a(=V#}vJ>IHm|qBwfRkYQOV$4IbK%k4OZuhXRPEa?eXKWdFMX_Q
z;EUiV;mPnO7`K|pFctn3o&o;^OW$e-(!wnG3|RVD2f}mUkudL4`;to^tL#Tkx>Ng)
zOW&#Ft@*GEF2}DbAmNd`R|gK&_i63x{BJ%>Fs>g;u`gQ#wgzks*cz}kU~9nEfUN;r
z1OLGqkap$#W4Qi*exbi)QGQX5vGo5J_W_*k;w&O#4Gr@M)zydpCxKXSI}PHxr=<@d
z$*r%vDJhcoi$&=Rh?5_UFVz=d?$Os;wY}5TI;8OdnPsiF!H2=tXK744k-4}3QtxB!
z5&aKlySp8-W%rVH^nIl#-8d*Qb@0YFx=wrj%?Zq*Sfk9NGkU##UsbQPyN35&H{-#5
zmqnhd`y16Bf4$41VZ#%KSMR&?<5?+x-^RqBNbUMab9=8werMFTZ>?Fgd3SEfn3FqS
zxao_`%W1EoIA>JdhYu~AQgrK}p&fhvx#;#;KRX<sDLEU@`HeJ3I9AyoKRLVG=d<?q
zJKo>D?#lD_zrx&e-Ye~3JziL!#c$fNj@CfpOfJ--=2$V!MH90#;AnK%(l%x}ZmNK^
zOXV!X8gMMyn&vzj^St_|&Z?Jl>Z^b`cc!^B>aFu+mNO^DoF`+>k!f$YDTz`0vNd39
zz}A4R0b2vM25b%38n88BYv5>TfM(J$9slPr`fUGVz4b5S|I+5G4GDe{YiFjGv~o1u
z|9?_ucEINvRb1>X%qmbTfE|vn92dkmvKQqzauPE#;|FHA7x@AUGKORnXRt4R#=`6%
z`vw(fun`@<1FW@WeRf7xNq#|228+188Ks56jDq~E&@(rC_7!;x1`l$0OTA6|srzX9
zJl4B#U_wS#eo;p0;6WLgg*ihKG71ZZBn%Muh|shjrt5}siNyK>X44~GNtwlkN;9W8
z+Q+!~m3((A`V(SHWz}}^;zHJzw}~0jQ=L^m$+yrutuV8oU?2@^F|Ro@%$&6oVt#L!
zxwON@d|J3agLL!qaC5`HE8Ltl7~;?NF#qv}wW4iezB|j5Cw^98;b>VdUd$u)EH^gv
zY_|2;0Ha?=+V66e&<|ts@lNJM=<m{#6c6P674>qB%0ejvS^pvCkB6BP)2yjSPrCUS
zpMUXmzv0L3db>08gL$(jP15Zq^-^*oV~Wp*<sP`-qMM=r>Hc)zp!0@=T<Guh>tQq8
zOima1<-OItm0y#6qh>G!uiJe?H<P#&UuK!_b?CZ7Z}smj2<cPaJ8;mjkPF>^$Jxq%
z3D;QPq9Ub(9=aL+@QP6dYzU?6|2(UCiga_Ovo(bNEUnSA)Dkv!RPi>m(X)v~MaHwo
zt<O}-toO5~(K9_<l1^%^&(Z^#`33n!^9=obYJE1<8!X{e4C!B!_}w3t?gp|3Nc{U-
zNKXSBr8{>h-3@Gz?!>>2^=Uv!Px2<d+sDY9n;dYQBb4QEtH-On?~~B`1~q!$l+gPI
zHF{rVxcsDBvtLuzdC5hRC%igK`cJc_e|Ny^FZ3;xOeH!IS>6rFGPsc}V?weFZY0a~
zVPQv=%D-1b{v|Z>@4S$I2@U)cIi3l*JFk(uGehpqYv4}ez!xS5Dp7Jg6!LFKBmX*t
z{2LPHpB{I3VU0WG-<=`<hBor=hfw|=8s=Y{7*CjdEG<+1T^I6iSR?<w2>Caxk$-hz
zX+V~!i5{*9dyn)xcQexB@`mBzef7_h8b0HFx_{%s{A2EslKYNO`4b<KO;WbR;mx6E
z^?Aj7c2($EeY!TE6^EYHr!(`JH}tGN&6v-ogr3!>3-j3pp=b4RY(DD~dR8A_=ChMS
z&+2tA&-N0254fK-ht8;BnzQw`KX16aeVep>`zk+VGF68&#e7K46Sur^+k+i1E`Rrn
z8Dp+`nK@R<d}j2|llzWq-@bGHO^dRge1HjEH!Jfy%fGxXJO1?F6c0!V{<T{no$b=^
zy`4VYBt4!T4;kOHS@dgf#a!~Y^m7a2g%$%--l(;-z2TF&KMU>(v#wUn7mI^gdg(X^
zrmtMqJ8SqM>#enTc&x!PA56+HnGePsGe;Uc5}pF{Tdj?i4^bZXGS5urd0h%GfIYAe
z&W8PPF3j+R#xr#$3})&~7%6*#m@kA&V1^PL{MN377r`357+wa;n%Zk&>}V_CGWcfr
z3ivj7DSRi4TWuA56?_kj8nt_2{Lm_4{LmhN$p_ja@OAKd_<HyW_y+hHn0IK;!#Bbk
zVcsQM4yZNOFT=NR|2ljt{058++MDo7_#OCm_+1#8wD)0T(msUmf<K1uhChXoQLBUR
zgFlBW;V<F);lIJis(k}L2!9J#!QaCV!T*E_gZ2Zw7Cs2CgBiSXJPOPB$78UpeSRF4
zF(tyN$-3(&;f`=M+zEaP?hF%lP0r@o0LxnGXW{PfbFj?&Lnmq;AG*+ba?hMW?QHlZ
zxDSkOv;pud@VW4-u*?&D4ITocGi?~W86E-u7QO)f9h?Mjfycn;QX32Z9-aVig(t#q
z!!o}R-D)XtEzJHP>Z}|Y&)d#@I{Xnl14f719C$aJ34aZHVRWh$z<-AeVRWkbVRWk2
ze(#4Da*uAc#qf`?2BTB$S{R*b>>uDjciKuA-D!8gC&O#tQ{ekx*1l^G!{}0551#|e
zTJnDI^KgIoWf+}lo8fr)cQ88Beh&|V--QRm@57vvq|Q2Gy}BlIn1{fBf``Iiz~{re
z;Y3(I{^&-FhEw6=VRWR{s!xICOr)vssqi$oJB;o$iW|ptn9q`920Q?s2@ioOd$f`8
zY<N73ZneqqTzCeY0n3{AOW<7iQn(Oy!$H^sUk(!&+SRb^d9oZ1!YkksxB^}X-v%#&
z?}RUh?}N+W2VmLz;vtwg(Vm25uZtI8=9+4+!{zYX@UP(yVd6~t489Kj8!UT5d=IaH
z<qRj{Qfu9sd=8%gSHRNPycO;W-v*xn-wvMz-wF4HSHb<^yWn{EaX0~f0zMyp5|+Jv
zh;wZW{1iL^ei}}JpMj^q8{ir6v+$+xb8s&FJX{2Cgcrguz)Rs5;a|hQfp3C0!FRwf
z!E0dBlvV}50zU@Vz)!=k!W-fD;7u@TN~?iCfM18V!M}q^TiUzuNAUab$FQ7D^$GkZ
z_*3|=a2@;)_%rw*{5gDFv^slClLO+u<o<N{FK}=8uW&#3D|j$WTGbNaui;Vf-(i{W
zy9Z8%zk_GMd*M0o_wXg~KVc8N5B9^PacvRY23`yw2WxOU_}6eZ_<Hzs_!gM7uC0Q9
z1>Xyw0pAb1;D=!HfVK{%>Z7fPsfKA!!m;qvaBuhpm^`A@z?>_lZH9-#Z^9$sci;=)
z4`A|)_94u^Q`!zV3H}To1%C;ThW`eSfo0rzEc`t@4*n4)uW3KS6X57JwC&;J;fe4`
z@I~;+@WpU<I0fznPlEfx<WWubhVa1ga3-7pXTd|^Y<M_44;}-vUxhXv&W9($oRg-d
z!Q^FaCM<i@TnhVPFC2gi;9|HKrc*{+0xyKGf=l7$@M8F8m@+`S11^Kt!0d~mRl!%n
zkHJ^LPs7XL=iqX<2EHAB9lis81Ey@y-h@}dTj9Il_h7m{v_HW2z#qX+!8_om;ZNb`
z;m_cW@E0&;hqeoT5#9~|2L3y|3H}a#3H}~_9o`Rbh7Z8Mh5rS=0Y|mvI|e)9ci=AY
zyYQ*-dvJI7efUiH12_)e2KR&i0LR0BgwKO1v$RBbJA48B5j+b17#;`z4}1~415SlM
zfv3Tr!ZYDN!5MHJ?14Xnv*6F+TzDruAN~R^gujAi%?M?q7KC@h8vHH14E_gvExZ@L
z0jBKKZi4>_SHM5OE8!pEJK*Tn4()EZ4SX-$4!$2g9<G8ZW7Qru2?I!zpcL!?N#|0B
z0@c92Yz^2Nur*+7z}A4R0b2vM25b%38u-uB09_}JpMN%Fa_akDsylwmn3Hr;E9PfA
z{np`v<G?UrU$zEp4cHp6HDGJN)_|=6TLZQRYz^2Nur*+7z}CQjz6KbQKBnvc{UrhK
z!u&wcy8b`PBlCVb8*~3nZny>@)z1|E{3T2Vc8%dw^n6(d(AE(f!;yB(r*0Q>4gC^n
z(`QagpXweXTJC|_TbQM%xyOu3Nf|wA%*F0;lV?nvnmXA%W3U6aDKP~xGJnm<e>I;&
zNbSwWR6NJ2U}|T^GF@sOwdF8ynYzxIW#+Nyp|i{7&_<5eRVVJo$xWYr$|&q?+dlfa
z^75`GuF$#W(zlYz`#JMIbpEOA4=7zQJCWEtUry%w&N0Hk90GN9<^S;j=MFdjv`ArS
zaQ1p*`A6cuxjhn?W5)c{n3#AtTvn0GJR@<vA=k;+lk_EF@F7>FAr}XMx+Ps?vwp$N
zLH9YvB9G?YJrF<S9fORp%N!lK&I9rektvE7)fn$E{l{2^DMDYB+V?@u|8rqa*R$!e
zUNYI^;S1egWyc!U4Tc<N;9laO8(2bEooDLlsQ3uOYVJj$%T(lDR4<OwgUn%N?#?kk
z-)$G;_|B*Y&lz^d>qQ-xpXnX?)801i{E_#b_-{SmEz+JHR}&A1v!}+9oYy94+bEY*
zc~!x^B)eE37iZR}^T*<0DaQuFGWS^A8D&9}?qu$cq*<A}BW1_c7I#Kobx0oe0PFkc
z`_&}R^?{vmUs&Fk42=Az@}-A+riwU50J)@S5_etTlVJSTPJxkGI|pW7vzo))12*M1
z@{u}+%Yz-O9KEn7@}mb$@?CG3d6_NRld>H9BPbNAVCJT(eMYSNRGMe<#GX(2!u%ka
zdzB2z!D_G`YzEfzc$zzl=Wx&AG0)&J_Ym312f{piC(^k)*1bfmXYQDLiPT-dd?*Te
z*M-ba1G|BJ*&47lU~9nEfUN;r1ONYNK<Z=1bpOAs?9u>7qg&hmQlUJu_J2xDIc?#Q
zj*k3SYi)!a9RXD_wFh86mCTB_)OoUQX|sF%LASIw=a&@vvr2N^#eTg#DDE0xuFyV!
z(jL#ouhgiEa5=gpH<u0wE@}IXH`<`PsB6kK8%RAg9lU{L)nV@^`1!2i_qwxvML}<A
zkfpmElAd$OcB!-hlkjsqmF(20F}mZax?6chJ>1xja9S`kdqJ8nAMcS;`VCw>`$4%&
z&(GqwRc_||tIOJEEhelk7HbitklsRai}KuP&(Oi4+UaK7HIn`=GW6$>$~@OnAnk$0
zU>S0xwLlJZSy<>RQaY4&N8_tLF4K6}lq@~b(=47{uHt!|N-Pt+!Hcq{`KS6yg84;W
zY0n>?o~5tg8eM+nujpOc>Kcm8?kR1>9(U%ve%0P7<p)Phc=YjyPh^2w&T(S?+Mdhq
zb>6&d@}%cZdg-rUzVQU@t9UWrcVg=gzSz}2b<ylL%hr9kIpf%$!;q`qyE1*#=XXq;
z^2U2JUtRe@(ZS)!PlM}l_Otv<*>Ajm<l(lNBkeain}(k=D*vq2b=f0!&E2=NCFe5`
zG_!nA<%Zl#GQ=x&ts<(VEV&DoG%4#mr7fBUjC`%~ySO9T9Akl8<FF@XKq}k`#=cq~
zF$3<;{Y-cgJO`F?;u2W=6@QF;r`ou3Z<VJKd*bi?u(WX>Fx+|gZR8V`f5e?x2Jus^
zzZLnHVPE<L%HcENYv3gKTG#_$56^>df+;%G`dG<_E4gPaptx($My|um*-EW%a>#nX
zwScuIj#z~DfURH`h>fPb4Dvu3=)!_uS+6B~d(;3~BPH$XuE1<t&*FEa_Vr$#Mbnue
zYjVQd*>MygdogcEgmeW7ARS1XyBw?pn}E4z=K+4pzMZRMSw{x<10z5RXs+E|j)GSL
zYx}!Slzsv_0oL|+758%9t!jJo9y#x}OhX3H<to-o0{gNxU~9nEfUN;r1GWZi4g5Pa
zKsC%!bPV_ZXT08MhUfc=j7|XA2QbQWq<sLtYz{ySZM~^R`;)yR)Wx`yYJYZx3#nwM
zv3Q(E`Wyg%NmfCAwmUcA^)mF&&&7#}KEF4R8T19>`i#iV%M382(#*KIOO5eMn_TMX
z3-F&Y{=EERd1p+_FwEM~U`UPft2X+rhHR|gSC_~})lv4xcMQO-W|gg^DF3n&uRG71
z>392s0VPboNMesnOw=D8o-5uf?R}_;t3GU0ogJrzg-sl-QElsnVKc|>Mc-0=#)@ME
zZmWMu*p?ny;3D^B)Q3&t%^Ego)6X~JX*+ElxvXKCKv-&jNm$JE<;r4L%a*6Du@?P{
zj9F$nmrTyp7l^)lgA1{{=a<Ns<E76jPo)hBd*iEKe=Z(c^(S*k#J-+3^iw+g+*@Ui
zqrE4Wv|;6E2XGNG$FreBC~qEKN={6qBM@&|oSwt=nQQ2Ciy@n|>qVb&K;k^@m&lf1
z>{k74hI}p2X(ajbWYC?f9}xM@29m!jeu;bmZ-JMcRPjpbZ<zdObk)as63?u0E^(V^
z=ug_`a-B~^O8h3k706d>%GcndK~JB5v3ln$<*Ly?)n_Z^tA|Io;!kQ+ZopTl_k-qP
zwo;h|ed5xbzcfpk)%R&iKc9r@E>dP{ly1(O*-2Jpyfj8*1Cc0FqM1%ZbDfN^Fto08
zt^B}m&&x(SZ5WmuHrfpM=wOLl?l?l>k#a|uU3P%g^T%Gy_M@)^BGnmn#l0WB<Qx_3
zeAAm*9WMD%c38cd=f`qB%5C&zIHO+q{EyBU_e&S<>puCRYbU<PJc9mo!gFS9i971@
z7v4`BH0tVQe{Xw7I&-ReiuwDOfAHqd-`~7<@eOC3`pk;Cq|Z-)GwRW-7w%sE%_Flf
z?tfkS)WTt-*r$c^)EV_ZOFnN~c<{-U@xA^U=)LsI4<nyN6RGbsQeW%g&QD^$ALLnG
z?oC+p<<(ttmRDb&`t6=6^kFIUx2|YAukHP-zM6ekb@`*!?~p(voq-dn@3dIO<B4~6
z`)W(c(p|d~mb8v88-7vbGlI-ML!*u&b7maFNDuNEB5Kq%GfMBfoCSBqWHxNNGwKgb
zy359%)HP&JFX=PPvA8q7&FVWB{ysnUq@1}7mT!5$;?DREHtA0G;u3dv81C*g+$CXV
ze4EraOWr3%ZUT@?_6`$wOJSLxbR~QytiiqEt6(#{#`i*%GvRXIjXm-A9$3CFt1a$~
zvRw96Y^2``?8*CYfu-!f)o>?y-zZ~M*(>jpPp_22a><@$;_e3cbXfK-Bl^|eWg_o#
zV3dKXY^>m3%163R)kV>y$$cl-19yQ-VdhY2;+8nmZh?t&?GBiCXph095$!d&2mAr-
zg8u~ff;%E3=|(#fMt53Y_$*lDNd`ta=8*DD<dILy2q4!v*pu)OJ~fYP0F0lGfv|*m
z5G*<w43EX%I&i4I<8tg*fvrH!erjq?mh>B&ea4aci>0r4E0yN(zGCSow)PLNAi*}*
zM{MmMZmMs15AQJNWjRr_wQqR6WCk)+c;9eSbF;QzPM<Xqy%TJ^g1%__wAX{^D=`O^
zU^}ocTLVW^15!R6%kh72UY@sr=5p~-YWt5*PM}PTjgdtG0dH}!=)znVa02G;F@B#I
zc9Y-9nZ@o=V^iG4i)bKAgC)N}?01r9)2N3P&2uvjuLky&Sz2Zwn4ei-8j62Zd)+>N
zv7@K*o0nz=yl$z(nQq;=%wo@C_+9qymG>KVuvqU`y`=_r7I`xl=r60cfP4}@_sq~U
ziV)<;ESl#fVAe3I-_r=23e(}Qi8zHd6XW=3q>P$6VVry7<n(b9#!ba9Su1e?WtUlB
z-$GqSE~$^o_lI)dkt!ds%`#sg$vp-QOyaBtZ(w{$QFf4yp7>_l2z<xX9EBwKNp9%-
zP#q#thnH`TVOE%1q}SJ7m`&k*sZps#-cf;h<1v?U_OsRd^=Hz)7;Vf8SuK?zu6uxd
z*X3K7j{79tzI%Lr0rMoLd4pq00s(JPP#^h6Z0t$BT)tUNT&i9!?S~{DUgT7A>r*a>
z7g<9fvbzB7kMz8NZ_#95a8yBoZ;>}g!qGZrD|%doY!vH`8HViQpSby1>A`Ev?$GP{
z);5zf8cST(xh`K)5pe!i&DjVp_Ius=MY+Dj#6adEcab`@vZehtpW~0&CnfJR=eKM$
z-Z`1~%6EPucnvw@^>?}_7Kb#Knl;~>9ZdI)_KwwCI1=VV=~8r-grEAEn*K1)^tl%<
zo}YG_(zQB@b0T5HNc9y=HrkV8sSn6SFjPHJ($^)#ccmdGF+DTCXlgnq8KmZtP<?^L
zp?68z)pM^dulUo%6^i?IJiJ*?vmvLVGjs2L*`rb}KH(~_Nc}7uS!xVf+@o^lmlOv>
zb9F>V)YqE2LhV2oPYoTVOUI$)lQ_&W@t3?)h^mzt<d8ieG2^rZT}Pu09c`0}8`nM{
zdEz?(dAx>-A=NCmTg6*Rc70~hqZDf@9wluzzLE?X+r;F&uKbBjnJgzU==nAc{+f3n
zkFIa-CC+ETE)Xf7)S<%~<W0m*sqU|8w~L!6RlD6ky=Xy^9CM-4fs_U74SUb<Tu;OL
z9I;BHecl_lq5|r`>hk;`XT(MhcWf?&M66zpxePZ#694+;ym}Bn<ZO?nx?d7@S&pR4
z^6Sk8i<#teQy-Hf=wosd<%YEkh&Ntdg@2MC?*loc0nZyo9I6~LU7dHUmvPO-o!-x2
z%4L*i<4V(lfnq~mNn_#hC-RtSs#JvFk~W6?d>G^+PyFu;d6-O<R*)IY^#uw;8P3SS
zlI|rPG;ygkCH*lT9tMdt($B==(V00?m}X;UmYLzQNg11fj)DlY1bcIIIaJ<==YENv
zZ__6#KPZo}n}FRu+%Glk%A7C>cQ5r`ubLCamqDZs<yp~zD$jB6$Gv<H*BS05eGlV)
zqIy@zz2UZ4rA={fjo0n?A(xb2QshehoQEErTMRvB>))yRffPMnMb0KJr9W#tB}t>6
zE8PG1i2j>16<hWmvz}1d#C!4xN1FK_f54YbosC7E?x1`ikxA0Qp~7L7tp^PMPr{w(
zNz|s!1ycUEb5k$Nar0#_%r9cLWy}0FWpCFW&$vcWD2V?f;04HDVaQJRY$!6_^0oEl
zD%tatt49AqWw)P4pQ3oauQ-x8h>0o1OwVs#d93CbN}4I;eWZ2&n9Lx<N*sNKnWS||
zyA-25%P*WaTJMCF{E>v&V>JG8V|AkZbMcH%0MD{b-y~Zr|3u&6c}LRAUd(G+M_yC-
zBRX<MJ#ym2sypZIxTV{$>V(!amLPMaKECu5#s2+Iy*75q#QW!d-RIix-nk34IV#(U
z`Sf2$56PZe`0eaF+xIJc?BgdQ_x)WwNbJ8}J0O2ik1_kZ5B~FCUJO3F;NRCL7$osI
zqh7uLr_Cd;7`NxEi@rGjlXrijj>2B`n7@)XboiJ{PB_@=yiZ29+57;B{Moa`{Nr~k
zF8?^~qMuI8`93lBoR7a`Z*?Np8P#R+KPryP`*YFqAqP)$-Wx;3p~pZmkMEN5#YZos
zzc~D^$G__IPVK#s`%DkFk8-y1Kk%!I+m7vi`}3FXKRD>aIeSPHw<z;b-d`Pm!=U&3
ze7t$?xC`b#Jwu%ZfjmEbJ>~Ifvwt}K`VrebbG*YRF%O%x;*7enL%+wSFX@{wsMUMd
z+~4;KI&S_!269Hd`Sw*+i@&+4{EdX0=Un;2Yom{S-)Jrcf-`Ef=iu^~A0M1>_Skz{
z9sKj7|A^dIeuGL^=fv)Qp}g0P5A5Ap^zt)fCkEJiTl#FGw*55oy>se*jQTbw_PCjU
zTss;0mHA&5=l}G{Td5DdG3v!7C;z$X^26_QuT^?ZyQ|-|Th4l-Pvy*+PoCeU?i0!~
zCC}XN{?=~oWgk6v*^Jv~TrzvdGn`4F(%TO+Uwm}m4}mW>)~<+~zTx)k=+})EIUCP^
z{f>Mr<%!-t)7x!Hv^}KE>?h`2kI*M4<=k4hE4&Vt@7SZTxc2~~y`<Vv72HdCn-1jq
z0DJPC+6GeuIsO3mg8v9hx%DwD1<wD#H^V#Nm2e$=2mBc<?~$_2Xv3(sO&oHPtfWs;
zT?N={!>>YE<SjDXrSaQnhd78D)i-$@JQm1x3Vo|0Z#Vc{_;h$A+#Mz<I(ooj_Y8O<
z?1D{sjCO<iUP`#F@;q(GL$s*#dNx?(G3xlL?l11F@*snfpYW<a>OnBSRp00(a3c3X
z_ySnI56G(Ik>5rgUDe&iUy5M|dQsOG*pqnp3Z4n?hBM%Qz+z`FOcGV+pj5$8g!5sz
z6}%CShTnwcJe2p~wy@~o1cP1tHtNdKKdkgjF(-Y``eoSjb7#~;RsXHXN%8N<(QT=7
zdL%xsM;=KpE8tP^O>inq8d2v9;Z7639)v~ihv2(lNv~^QNuN^hT@Q<#tAJ78RP|7K
zuM^<Ex-Q0^yf+0FnJKoko-k=f>kFsB!{8}!5<Cr-^fVoI!!uygo|?Zc^_5xNGkoVj
z$J#QOxKrmDVOJCV5?-ZWFD&xK1EU_-WO@o<FB&`K6%~)9fsi|+e%7QrWKr%)4R^>C
za%a@Hnsi6^vT}EY;cltLoqvm}Z>su_=+T<)UoqU(z@pDr4R_1=U17MBx|6s&3Gg0u
zolW|X`#AVlFyjkK?{aRA#P2}(I(QIFT&r_(UWPB={!efcybs22bq-N7EaNH{!HIAR
zEOoU>@BswN8%o@R4WJJ5=EfU#U}rZt0Ho6=4$K06upF!cYr!V44eSQ(&POJY0fJy9
zs0I5$S2FPkkONkL4PYm54#ynifaRbXYzNUJD33upC<B#XGuRE<Uw|8s2bP0sxu;Ob
z11o{!LSz6Mr~+GnGYQ#19#{!#z;4iW6y~4+RDfzw2b`lZ2RUFRr~$h`modBx6oA#B
z2J8R_K=-jc0~w$UtOlFF4sZZ;AIEc$0m{H?unFt{bSybyK{6-+tH2ge2Mz$&1o9&Y
zf(o!1>;+wt$w$Bg%E1P(9UK7tCgLB+0cBt%SPx_!!VdTVa9u<=fd^=y64Zb?upe}#
zkVpbKU^%D)HDEXBLcx&$W`QzL1-5|Qz)4{e57IyZSOM09EuaoWQ;@`gWRM4>U|9vK
z!4^;l4uI|yfC(T46o3k_0c-=iK|2bmIFJl-z;du2YymsL0pOwl%K)oD9f+HXT~G-&
zfdilmg<Bd}1$Kh?baV|ifdgO!g<d(R1x^aS6tDtp1zl$n2CxaVn}t3=8K?v`pboT~
zjh`R|1i@;s3G4#SIn+r&2GGC;upKz&5_T{P_`zzh73>Ah3}gc7pbV@A8^JcP2RJVw
z{y{njf(lR#YQbL6<x>0x>7W3VgVkUo*amikXgB%?@gNywfFM`_s=y|&4eSQd9`p=G
zfOOyo%fV`}0n~!spj{?%fh3R)^1yPi9&81BL6<CK1LY3F4zB<kz;>`7bj{{HAOn<x
zYOo#12c{oL2c=*&*bH`o_Fi-hazHs)4{E_)&^?#B5%7amU^CbWobz}O$N?3g2J8gR
zJmd#{Pz7qi0T7puyr3Mc2irlr`Mek8fR$h?kb?w=0Y6v^>OhwQWB{dLJ=g)9g_waL
zSPOQ5_C>rK_(3J81#%!^Jjehmz$UN@boG<oKpCh8yFu(_*aIuU7Qm)Yj$yzL)`Fd&
zdokev%fUvl8@Pg)ffZmg*b8DyFas;VW^e!`EF?}rCD;MFE+Rfa1*qb6TR|<q9i_w-
zm<7r~HK+qJuHAhx{(uya2g<-|unBAf2SAr4xCbe~4=TWVuodhE?Jh??Fao5393X42
zO5qit5^MmQLBBF|3TlDp3j71*U?o@!HiKbHNgH4<*nB1T(c}prYq%U5;RFdl)^Ux6
z(?K4n0<x}aBYXhNx{7qfz3ic~mfyAV4Bi7<$L_aawnNN8*Q>GL2ARNEe#;&!1+eV1
zQU<R8oB3S{Zv@dm_FmZnm+_vR{7&ch4zO3umZ2{o^8hx(+kwmnNalVwzn!3f-v{7!
z<=E%9i{Hcey+Yi8oj~RbBx5FP%L?QfSPj+#a~{EFew+Kdbh!rk@kizq#PWM3Tn*Cr
zEo;y`u(=Mc5_^8`Wj)#ke#@FPnQu^ynYkuy3%|F449v~>2fMi63#u@)?hhk#5u$(1
zGt9fd=DY+KzvDqNm~}j1JDK+&v&>hRh1qKKmj{>0bIi>(ZY#L21RHU)707&s4cs#b
z8Jg2j!~M?ogby<ZGL^#1fvo@A$}{U+hh5yudbknT+s|)V6W8uq;vU3<-N=;$=YR^Z
z0qg`_mlH3*11i7<PzR!~!yQNmL115puK}XTk$Vj1|Eqppd+c8gG5#lw{mU4CO{e-X
z{?gWZ+M%81h~cLTo^Tpvk($Ta&ON5IRE=qmGe<<QBYpQ|!=^6P|1D!76+CTje0LSk
zlXwq(*vfx%eAn#X?#1)esKU&7`Pq|8WQqaz@@y8IqPxosFxpMGe=$b1dG+yh>sXJ-
z5zjMS4wWJ&;-lB-N~ce}b&R7G<u*FV#NOBX++F3@Fz%=6@0sb%*Zq&f>=NC~FNV^0
zE@P0%uc$e{juDiTazD$s&&96Xzh&I}xi|aUJ-jp0oZ5d^fBT~-%Nh0Z>yK0oTXMn`
z&T~#azF+QLPe<-=&+aMq8}Dn7*+$GK-*V=P9<Q`HIDAI*H+hdI^+kE;+8I@O|7G7E
z{F`h0(Efif%NoCKJ>~v!V%~Tkgnw6m`@gGSJyQR9q&eTmdd~5GLx1>MlAT_b(T1UH
zlX8jT&#@ZF)q@(YD)(T1JI;j9hDqAm1#m1p3GNNgh0lWXVC<;#&nXksIpzJ}XD}ZM
zzXy+iKZZxaJK@prx9}MFCwLr8->c&ySjyash50BSPCu6PL7Dw2(uX2_CDKnK{Uc^y
zNTmJ&=^Hqj{Q~8L>3_2gYqwvipY!EA+U?io+OB3BQ`(JE&riClVLMUUhv^z=7)ZO&
z+8&g)V0b&wZ1-9B)r`JcZ{JDVE|%Zn?Yro<dRxwH$C>T7@V1+@+st;Fw9(?1(T2lM
zvyCS0GY@9cHnX<N!rNqKd(3Qug}1%TwwAShCG9F{Pn7|)O=WFMS=&)Nv14sRS=&u!
zn@QSB(neZA`^mm+4cHp6HSkL{KyiFb*Z(v1U*>vwGjrUsh*9+f9G&(5u`w5piZ30U
zJ2d{h_{>3~haQghG1S)_NuV`TI~QgLg6`Y`=9}esOEEi(=bb5&<7t0|o)@#<ez3%E
z3hDm^=L^WZ^*P3T+db6f<Pv#K0(7-GV!H6{`@K1*582dyeMKxdh_t(a5e9@BiTlWN
z<?7enN;|hL?=k0dn|lnjS7!P;{09sfceKJXm&nGaMeQ;0I{I;Kwa6I0#=2f4W2b?p
z0ugbqftI;O76~iV#8n^Gc09cod97g;N54^KdRP~RtqE}P{CIFWxB`1=dRRS~MZTiN
zg}#zvm&~0n_Ge~$&rVD%X6-R&Kgb4>1)0S`w>J>*1=zlkUHzMV*z&l_Z6N>oF|&1f
z93x3f(nny%RjFiDuC74j$C=|p{%J=et|IK6(9+0iX}Yw=m4wZVn_=`5$R%+iVLJs}
zL)a>hJZ_dY6LT%jN8xc(ZN$wBM%<WZiAdd4E^FL;j{LPpBW{jxFNn{0znL#Y*XDi|
zmDHQ%l5QB$b#L$qcJ~|&Sr2nh2y1$fd9H|J<lTmQLYT6TrH(F_l&7Nd4&X~<kAM3p
zlvjtjH$=F8i;OaLw;^MHWE1_y0Z9vKM?=OV*drp6oGYd9<mv}R&a;7(ClyCS&Lh|>
z!kQK&y_$Rcwin^J5`g?X7yOEES*<Q-F}v`1-5epqw=`eY+vP7|n;yR5k;|lp`zsjV
z3S8*rtvT1c%y{p4#(U+vdJieo^^TF&^vVUh0#U)>Sxet%tZmB;e_uQK0CQam<kho5
zZ^G$s^gaol{yyoOZsH2fJx}7HHGI-<F6mJ>%aVhQ+(DnJe5h}Y8Fm@NlS|45`Ruqr
zA7t6nKo&BLE{Y2Kp=1$1tg=WPn{)3+oXA72)zq0J`>cfJeXe({y4K(4F7kOx^MmT0
z%ayA}|3YIA5@)xPrc<NBKi>KnLK4q)neeih{eI`Eq{H_|U&FCqxs|hb^nl7fAm1pN
z+Bi1y%o>J0Mi?^iQ*<^HNEqVZYcdRyT2&a5vDd^E3WJM>e<IzbM)?YIER_&(W3B_U
z>Q%-WM(OWVbqKk48~5gS%iOypy}kINre!IaNAX)~UDXX_4$D~BIaFHL^RIr+)<)wU
zeQ+mwi8bEgeBY`UDwz$lZ;Rfs7r*LAE0M-eBCSg}+&xCRks+N?S<g=xe(pIHa}zGS
zqNe*5vDZc3&-rMLdmQfg!@p~M;A-OGSnfIV9sWyRHrh_AO;y1?LuV>IL5|7H|CD+`
zDlF}pG}v@!v}aU1C){0gd!86=1BVO$Jiz)s>ZqEO({#tF`OK%n=KG8~xvCF_zpuHy
zQjGepst1R^ubc5c>d5MSO!Wx8&!}fM`MzfNSkdczsxByUN}VbJ$aPqItmxljRWAz<
zZ?k)>81DM>zHoQV?y+LHle&wzlX69V%XK~RF7Xm+j}<9zjk<#htA~535;IPtuEB<$
z(Su4yeE+pGdBXQi?c<#YOC4l5Eb*NLj5<N+%qy!NKgXWPvlBi8{sI>N{sPCtyI}Dr
z4H(~gRR{2JFW<tkK(1Qsi9hedo!}2(J}-{#@Mw4koC<#eOWom9Sp1dn8sBa8J@;^L
z4etZk6a761Oa7^XrTz6VEbXy%unT?^7XLN^<GZZB*B<Ugj`ct;zJHp?Jr8!m`7n7y
z)+?xR`{04x`(cKyWNMx^11^E3?z0FkgPGo@-3s$tdlJ_8tAnqCzlE2<|ANcmo>BUK
z=ELFZxMz;IT4zuI-^jhxCvJj8{#n5ICX1{N4`>HcfLy#&6Md|NJHWTYG4P$R=;JQ<
z9QYoXwBc9-&xG%V#eWYlzMnGPS=~##r31N=uqXbHf<@27ok|yD;a=QNfQP^nVbYiy
z7rYRj#651*x&?WU#H;ZQRqIzh+*{*y3ijnaQ(*}Q@7KD*)8U>ldeCBF(u!7!e&jpa
z++2B?PhF1vRVcU?>;YBWZv`@+F`1XiSWgWw&rXXbBeZ0np03yH^Y6mPZmi=rGG<dw
z!jkbC>sXD9)0p$-%rTl2{4>XCtn=e!UYt2jbExqc8H<s6aQGZH8H<r|n1bsGFBowH
z^;QtK0zH78U>J#RIj92(B)kkz23CWOU<Z%|FR{SBYz^2Nur*+7z}A4R0b2vM25b%d
zZ)$+*I&H8hY2vVMH6t^AV1|2<FR&nENJeqSL^)5c(3_Lbb}AVQvxDqLUYt>opGDs{
z8zbizdIzx4O8!DG`?}0`yN8~4{`rFwh7BH=;mewzlaX1NGbAB{jZD<}?yBE5o74D?
z(pmtvdO5@%e}}&xp3I4lb4h=w-gnu)m1srZ-$B|=SAcn)Xg@w}>>V|R;{?6g`MI1A
z5FSi%C;g<u<VWKx)W4g=v)MG1Q=>vN>qC3M$-H%G=jrp-$1ziZqX>%g*k(^=yz70~
zX*?gV+&4TQP~6hSbIe8F)TpufjA*l|j5lD|QhmoRo~J9f0ktu@^xN*mtdej?>U)ed
z*E`alB9Z1MN1EgO3h!@fuaQXmCr6qy9%+B+!`*NBtwADBTE@CBww_w_itpU#qMoYQ
z*qe0%v~8Q3+a77Jj!1jnT&=?U?OSWsY~Gz)GUnvY7jF6@^K$xFV#WWu4<A}KrRdf{
zLp%2TbJ6XyevaJNJzLptycbBMKJe{y3OJ+o|8>NR#~0o_YSbV0rKNgreKqo)G?Dt2
z54SHp(%v=<rXWw_H32osyzxHU-=Q~2-$q_k`<}O>AHv#~lR)2w<Xie_R9_AKD4Mt#
z4d=pR;2=B}UJOg$i{x?goHl~@N}tD}=2mZyBd+LdX=?5Dv6x$3g?!TIB5Ps~)n_C9
zGP34W&aIO<y9Y$pW%Sqeq2B_?IzXAfn=bd)&^L9JKEG7@a`J$j+b45*^LXA|-%fM$
zcV%vbtjU!5x?O;|22<wiN`KELkptcdWUZyl*9||zFNJ;*YyVI9eBCDdfJg{tA5i#Q
zUF)9BGGABLL59!KJ%C*1nn&wAU9(?E);LD$8_Ki$bx5K1Woy9JfUN;r1GWZi4g9BS
zfa;yYvi{#!ERA=)?ark147O5T;0+Xc3o@8XUz}0G|BT{5c1EV(FF%89OK&vvOACYI
zR2=Co{{r7Uy?LBjU}^I^JTjKunYQ~*e;b3_IVR<22Yki8+@LFNY9CjspT33sCCtZi
z$!_}j1+4m(w)yHFj?g~aBdFWTMO|LzV5sv+?q%S#u2gTE^Y(%9=KFbmsJ6JwlTX6l
zD3BUe%3KD$?XBN0R_$eJYnQ0!**@80N7~EgoVl${$Ww_tNsBG=<kkz+QhAcX<k9aV
z%QML6yO>4$MXqrDRMyKA5~iiH9IkE>jk)(4Z4bFz=!j~y<0SY28RT9P(v2w#8xI#2
z%0~Pm6HS+<u2BOqJ;9L}lLx0pMX9*b_-&PMdFWo(RR#CfxRbeat3qZzKR;C*SHk)p
z>iQn~vNu2mx=bMqGCyI0F0-;LZOPSyBQ<JqAwN}mFzuHa_8+m>_cUSOnueT`8M&-+
zCTYljc}P!|6x8xGorIs(G_Bu9PD5tAne+0;8u7*+eU3+vr?v@s%!oUZc(ckU@n)6p
zm&98a^eJ-?ByvwJQ#x!m-o$=_VgEXdeGl%#<Js&hlYG{RNkgvI`}Q4w=9?d{`_nxM
zJs!OH^@o3$`tXl8^?&TUvit|~`j3oXN_laSvUl}>PuF}o|MFoYYS+IL{m!XTyOVdW
z=`;0(Wj)sn>~K}D)*adFRM|`Jm9?W?tJar&)BcS6@`qI(*d3^u8aLsYp>0Qh^}<2l
zzX;UIGvvK1JGM&oR%}}K#-!fU=iPVeXve>_T;H%q%C`5JecuNEy-aesP5Jl9hW%9=
z9(kri>bJAcANBpMi#-JkpZjRm-%{dt|87U+ukNGW{j9S0Q*d#`@!eMxP2RrY-3=$b
zH~H}oN+z5<<hXJ7uK9Fd_nfckgW9I-tsQaheVzWY?!<K;ZO-|^@zdq)hn}|SpU-tX
z{@NkS1E;_E&RMkQmA$36Bo0pc=C;AJAG!D4->xm*GUTUwu30m^_r5EVx8M8z13zW6
z?t_jRSL@$*yWacYs5>g+W8d9aJ+S}R|9ts8XNL2tVF&){4<w&A;d}aVl)WD79{9Yk
z@4HoxFOJS^|2t>gTkD<*oPYPs)$2~^)Zz4QyXo(oqwGCe)XjDBYnw0JQ~2}8H+O!p
z%|q>0-u&kJTd#Vt_k!M6^%-*?bB&a}J!_|~e>vSb=YhLVUvT`gR%M%aZ@K-u#I9%F
zo|$y;o9n8ubDOgF#^f7+@U^+}(@oLAmlkGxlla*cpI>y&8E?LK=j`G$zk6>dok!2A
z_*hi_+tFA4`1Cg~@A>Gq_q3|}_YI$vIC9&!e|{$ImEX*JxW_Js;~C{&$5*bM*00U*
z-29}6r+L0hzIpC~r@xHK9x$l#+qIRY+Yi32pV1Ic+B3dss$AgKA;oE|{NQ4Wi8=#~
zDJ5#30=gd5JS1^ve0!R7M}ei>QPe7TK8ri!8_}dY@~3ilo#BotFrj%*MtQEvd6A8-
zmC(GW0QRKpFNRT-n&&kGri@qne#(5WN4Q@KKL=k4%f1NZuzWABfu+w+!ex|)P0E*t
zJ*f}m!xzBw4R;=X8|9Wm$}_pF@=e8_$TtlZ`IytC_IIF+*PiEo4*UYlH$d&@;D-C)
zPYx{QBH3FbS{<$m=Kp{+-~k1o6qJJsPzMrj;W-F`3SeKh25b%38n88BYv6xd15{rf
zKmTmJ)v5M9a@<E9U)mkD)MwrXYxpf~>v#CQ6+FamX$QQ|@4Mi;!976g$mVrFzom`$
zE_UvOS6QB|?ZUpG7Odm<qu?=c4{dyD=gY;ds^=uZGFRIVG_V?M1lzz)Ame^rK^%}d
z-z$K$$9I7JpdEpfa|L2qqm=_HKqXiYHiFHd7Syz7oT~#2WHCc`a2z_3u(vh1H7vU6
z3`_V<fJGOr40BxCm#qO?1GWZi4cHp6HDGJN)_|=6TLZQRYz^2N_>a>-G!hjZ!}<TA
zeLYwx;49K60vw(F|Bh^ae^E^Rp7-n#p|11zFM5avYX1{D7kFfBe-;V>UHtl(Yn=RO
ze5pD8GA?NDYg29be;Rhhf9cOqyV^03Q18F7J7Q)qn3<i|qJ2+H|7E?lTnu?B|E1eP
z{C73wzh!T(mdd}v@L%L_2Som9of%hZ;J<b6mP6}D_8<~HKR`UNKbdh@FH=1*6Wy6-
zOYb$_O>k7$=$=tw^F(~NJ3GJ*P}!LUEz+U6ztk)lOye?0{gyL@Ww3`hlE`-#dJD7t
zi`}^;McI;w8N$-TsVq1C7fJ_vc~*xf$9jL74-#bV{Fe!vZg`@@39pPCJ)!r*pKpK6
z-k+xLx)~4dyX^4KXN|OmBhnfR8JF~cYQ5YD?E_*RU!;prlQMuk9n?M^j7_R>$_ru1
zU!&pP@L0GnJPsZJC&Q9oCc^TbB;e4~rbFC$KpQ|3P*)E2<UM&X-Ir<{RLX}1+)Mr~
zfW@C-z-9O&&pklg^#gLrc(B}~K27po0G9Ga#&5-alAswmQm`jw#&pBo3|QVX8x}ca
zJXQP=IXs3xlGi=JD#s<*lY1F=6@Btt$&(3-`#7K(?py26DM$3ZOd&^q9t)ofCy*B<
zKel9_iz?h~1+s?Xm+Wm}u5(x(+i;!3k?w6_u4$-2xwT*?I9hvJY`=y6auB?gesR$L
zHpZ=iec2kYHDGJN)_|=6TLb@H8j!lxv26bb@{6<0Jphbl0JM)s#6)?hzcBy*SB|MA
ztwP+AbpWw3vi84|<H*|oaxR?NevX$4BUe63I33P}=XIi9{EW2ylHBgb>-$yPa;<XJ
z=wA|E^E@V|8g6b)Kh1<@*Ywx$Jkpx}Ej){~reF50P3CzokQ!Bg#GT0G!R*4$VjkLO
zV0?Z7?QhIwF1)lcdIH?3(-O?{_jI%L%mCZ(>Q7{Uc71OF{XP1#v}|!76QkkB1ofVD
zvu*DyO4j#);E_7JPwM<*l$~j^zkWK~8mPV%@wb#`y1(^~ME(lQC!%1B{AoUQ^gywa
ze=N_5I-bwSEGY3R8Ph_3$*u<hUjahOez@0eP;Gmq54qoC+;>1GxxeOF{rN28-p>S3
zngJ?Y=DcrdM;z;ReGfXOoKb7ro?mck&)}!)Zh7+WA07O3lHIQV-)z@Q`%f<q^m4*O
zI*@jGnIs6V)=~Ptkjy{Q;<!H(J|FH0Pl0>ES#Sm{X<PQ2T@L5Kt6(p@8J-7s!OzQJ
zna31><KZAI^NUO1NicggYCiZHcp?02_-YtAwHx7E;pbu5_jMaw34agY4|ixqzZ<*&
zeggKxPr($xj%VN{@Qd(m@NZy_t8{FF_rb5g9a=Nz3LXT12(O1fhM$0$Yo$E{e+t*Y
ze}aDte+_>Ge*?FseEk+~1Mh{8gON?^3jY%x0{;Ndgnx!JVCHUVneg$j%<GbTcc}LJ
zN+!X}z6|B)wF*c(eiLRAm)5-y%zY5dJrEAH??Ekc>;cw&EzP|TcH+PF{IYFy%E;aa
z=Dr7A&p`+Zv1Il*F#7~rviE^?--AQ#ducr*I(*Lq>)w~~$g-Bs6gi8mCHowNpG7A7
zUv9XC@Yt8F0b2vM25b%38n89+e^LWfXRPc0GmrNEf4Q<%on`%hl;_CX{o|7pXrIN#
z$ff|C!B#8^Z_B;(2b=)A$M}6>*iC*XXBN9hjZJYEFUs`0W$-({K<sytXVYj5a@dP6
zkYlueF-zkZK+X>`4aGl>F>?F-#k6b1Z(f?oSwqDZx9;4`f`Y8fYzEgF*ui4GU-gz6
z*jePwT%f<K-U9MT_}nu?&s4bBWMQ6{fLX(+eorH8Dolsp7jg>yC*w|KUHho16UMnG
zPEH>;Vcb;wl6@B5qTM^gSi4_J-CeFv;jXaM<=>*S#5qZwbw9c!zaVFfY%Q3YHQ$>Z
zO!gLV;-lI(l5-75xZP^2LZc}^c%(jVF72SkSCSex@8oC`^QScBcWlb!!P1mcZFvp;
z8o5%V{CWol_tI}6Z7F?!ME}&u{FXih=_{x@McGxNajWb~d+Ra7+*h<v*_Ae15Tr)2
z2jW5|4{%A}hYNmH^*8vHAEQfhb0x9J`u?u8hjP$E4t6e{tYlSglDIcy33aky#CT*|
z)vu6Y*u5El#Vps*@kYsnTqgsX2iVoG+8@=Lb<bfcnR5$01NoOr|4wW?Udft#m*J;S
zyU=gv)r0sgI{#FE7dlT6C(7)jklEm2VkWxPV2Ovx5#j;!M)81Ilkp(t;qfpzLOhs$
znDHR`Gt+2yQ5x50MjG7#|DH6uXUgHH(S#PJ(buN`@-+Gr1L36SCUqm`;kr4TG`fj2
z)egN#8tp%=<!N-JVK+RDW*nzf+$fFiIg&J*F!G4f=)Xegu|AFd5HdURG%E36rY{Ml
zxi^TE6~8o%PBrqlw9Vy`J{&1Wli{~XqqQ@dOry<|pn86urF;wjS6_y9Vq*$kL4F<>
z%DWz{H&uq_VIE$F`Y~&&3@ydnT85fu$~9G1N*=w`2)}urUU(Vj{Hf_OE}{a$Qcg?C
zwjTOBL>KCNBIVs_^=3l}k}BIga8qTQsUOlpsBAO!6P|8N{g~;-svpy?wG1=UM;U!8
za#_>IJERZ49*^OlfC%c5(yL|Z<LTMIJbg4(ewpDn%P(vA&9crKelvZnmPtlj;prp(
z@X|-4lBFf-V`P0=2&Iqn>&=cheKb|BnEGjH`Y`7yX2|3#t|4S<l7(XcT+0vV92Jl1
z8!|E2xWXmjU!`0&`lsq!@=dSgQB&o@TFiU#4I$n_>Ao5>eQZj;PeE@fl_x1LH)6hA
zuUm~B!*B7o241S0jc4xU#G+iEGT(xEQ)Npn=GL-B{Me4!BHfR1jNvTiR@JrYU|x-E
zD(GX`SzNNI@_!d>$UP}D!2V@OFMjR8+yxlpDxT_P-mPzuGT$FE4|uan0>$iTuHGRY
z8va-|-<EU4^?Fb*<(K7=s_ce_rBofyjKA(3vCL(SzYmDN%DK(NAKCfe9e+=CRq@{_
z{+i1Bk>c+?!buwXKN)|cjqg_%>b!EjMm^|UcrE+~!WDmsiofxkF>kbTn$ClH<X7`@
znm^dGY#_g7FSA)Zm%Yro@ol;zOD~%zle^Lbi$}{rt>Q$|u!g;+@~Vt&gy&Vx&}%ZU
zuEIP#uU2B#R9;<+xr=v8-P4*kWNv$;{I`*3P31oi{^))+%zsix)&1fP(}El}pyzQZ
zQ%<9e$~<vH3zJlPSK44M^3!e<xfDBJU#j$_#@<W0e@8Db#*_pC-lAYA>8ku_x~*og
zcn$5if4OzHX8F)nrFXX44+N(L*%nUh@8Lb`v7e3oVIJMSSw|eH<jYqB>B?`~c5AWQ
z3A^QnUHJz3k*iS82YQ9y81$BB%Xwy&d(xD)j)%vg%cL$=9q78L#m%=WoO$}-x~>`}
zZwfM0Ap>K3jxQ`SXt?=axf!9l6h_9T#ABq&y0vh76_ycM-g)^&<}=YtUHvm}QI7sZ
z!dlCFDtXTs-ZMF~UXMxKU!Y_*WW&AKABNr4pd-((Htb9IrJOb5-wb{+Mh>YzHU*_;
z;@?T0d=z^R5ixkF!chT7Dzmr9Gr$~zu(K2zmf7-7GvBXAUvjPGJ1F`7Cip|*aZj##
zXXJcul-*lIFynHXKP>rP@{yVEXA~$uW1GtNb=Yev-|xaaJm2rZtf_DGe$2!3JqmU-
zRmRJn87|}v&-XI+s>fC1@2>QV9F2V64ms~`kml?2eOKaqC(k6`Kc1(@yUY)1Nxm1i
zYl%<E_b=z`ZY6!!;McMy^8GH}BlQ%?_xla|lJ6yry{Y7@&-Y!axK?6U^8MKPy5GMf
z-|y!gz3{KT?9<b?2i-*TuGFZ;`F<?st8pXw{vnGD8h*7`ZW`zNN}dhUpEb(&)%DLB
z<ohkyU&VVQ-=D-}0*L(093p;nR5CZr_wksm1d{JZ8}^SR-%GwU`+T+&UvkZ*uSfFb
zDEK4tWtvaPW677}eF6Tw`SXfGopOyo(W;&$IybMT^6D-gN?w()Itfct`LQeJ;rY>p
zSyTB@%J%U5C^~HFJ3I{Ypn8A9Z)8%vxs;s^>cPo83(t?DcMX3ceOIfAr)}uA4e5Br
z|6}iM;H;|3zW*}<ib^)4m}HnoMMXs&0Ra(pkQWE#WrRUdv6*4!z>E$v$9dsJ(N0E1
zMl}^BdQ*)`g+@9S6{Q&^6?#)~CmAKx)J;W2-I!FQSpV;Dz3jcuo;|}z`aJjN|FAxD
z&F}2B*IL)Lu63=~z4qE{5FrVZU)e%Z-#CD<+n_B3e8z?MbtK+5jw9SwXfa_=ye&+-
zlC<r7AZj;7MceRC>igR9PwM;PeTBD`zSxD_TxTm+f-m6L*8JLS#jg*}kz$-nvK5t!
zx0NivlWb)P{&8E$;g@79EAWroN*jJjZTD*YlWe6u^zULT>$sO>E1Sq;cWv=b%2Jcj
zBe9jOEn#`K;hof;jyakACeSnRI+{&KfSEhyz<7IFOSt`zbTr$ARlTbutet!0+luTn
zslD8be^PrHw-x`*rzf4Qs9&VJNWB98o%n5AY~(Fpn$1j;^6Z0-t__LiYZ}iaxM04W
z<z{^Tt9rQv|L(?tIqqriD)XpvGjZiwdGK<#48{YedMmjl|Id-Tj7?o+p=Y_>Sfw{|
z$LD>AD)&rxPW9%uOIY?GvtBLL&j)|WkIrRA?urV((lueplIXLfu9~;&Uh7P1UH%2S
zmz^Zl#f|vK>*6N-lIr3X{Nr_T8-DS2Te{hSzpaa1$4i~ui`O~X_-_2uP<-sQ0>AFs
z?Io1|e!gRKJ7JEw%hoONFXP(sXG+5!UY=i?`IT%(<7ma3N*TPHaF0gfRdQ|jFlT3F
zYJ*2^W{h3li!?h(Q#yHD&dQ=bA<K0qWs42ZZ{WB1ml19~l;iqV7gjo$!?pi5S#xW>
zvS938a%+$73ofkElb^Sz^l1u7+m0Ra?q6yN_-n#s?|x18q-NfX2~^ezE||A>aMQQ*
z%5Rcw$p+%K)rnt{ZK>?zwzU_(cssAM-H(5Fwxvp+WLy35PZKZ6wz_NQw@^OiM3QZ-
ze|PU~OYznbPqtOIJd9V#^`Y99(i}h;OV{6cPtUfsKFu>Q!sZD3ruW*gy|Jx3U082h
zzKz{OT5=nqLC}|=-w$LBXoX3e?FnPYmIkx&{0o8_dm5@AU0m9<PpTuu-1{YIGVZUf
zYqn#rG5G!3`ZX;L=K1z}1!r(?MnT=ess))VtD5b)Whs8vF8nL&EUGlMn0hkZwY!^6
zClGEjMACZSIQ2Wme(Cp{yu=>dNAnf^ZSzFb1Q+J1KX-SLb~I0g_}O(`)^;L!l3tVY
zl*Ydmno-a-PriIg6cI-=XwG(4TF1gSXY&*-AN7Y}0hz1bm(Nj=yhQupy^jBK_^J<n
zC-iQV+Y#aK*Yn6S{G(UB=fB9>LY{rxW&E<iVwdc^1paYdM%&8uLkNJA&9R(f=26G9
z22^=ZvJFI}%@bW|Xxt<0>hkU2IJ3qS+O{Ia`%TH7WCxPnzq_;iOv_0Nqtf+!=p4$W
z-O6stdiM2J%NDJSs!Ls6C}RmX&yJL@WKn%e(r+35as8@K>p-u1nST`bpR)3pIaHeK
zH0wt*3g)@pBw?R+wX2uuvj~J!T<rt72x?)?toQ?_OxWr)cI>>Wnu^SlY94uT8b$1q
z;61i8k8|I*GYd&KS|_EOCgWF8(NbI0qO_!QFWXutn;w$sUHp+yE8%l*uxygSp9?bP
zY?$KaK(g7H&~jwh7Lg&Mo8TwGj9$|E;hfqf>(V7rz2uAzLK~G{?lyiEGg|nDs^Uat
z+T~=Lg1_wfD(F3gFW~@{0**{jnFWGGeiE!py-AWuX~tz5gkOIv(=@ii(fr%KB8|Ta
zZbm^x#r(#mh1$^+EyFcKxrw^~lKwPCI-d2Mb}MVNjkJ|VOI%egjZI_6`d?jSCJE=l
zdZc_DO}gH`G+t3Y>^hX2yT#gl+rG2D(PSTaNbc)gy{J6LvWUw4GWE36%H3ms<pqyq
zq1SnMDbg1BJlHk#-si#hPXlzY2d)_M?d>(BpZ=h+le{+T-;sGzL}t}>W0S_uw1lQD
zlKt4WNcy&q=Aw4e=44ek)pfP8i?O##D{E3abXQ)xM0oWH&fK_)y8QYUZHJ=uYQT9m
zj>=pz$OJxs47rF5k$QDk@SAYG<sGe8;_b_--SM74S_7aGXf`_B)MHukHlwL5mvyl(
zm4S6(9g%M1WtGNnj47)|)6_^NKV};@%%-6BSAB!p-(l3T^oK(G$s2!$MidCfxidyK
z@$TwE+0xt`5~;tkBbDV@#xIoZMpr*~CCGL(eSOx-*30^tCuXnZ>=PMNcsctSzfjK0
zot!Od@NlJ&bg1(E4K}sO%GtuWu%eEQ3S-B1m1PWJySmVpOSt*prcDm}4)OVg@yqW!
ze3=%?xN#+r<hc|wW%}V>m+5J~OuLg$V+iS`1dNxd<m;|XHzvqt%GApC8q3s(Y09)W
za>mP4a>mQl>#*cPZsKHus;g=zPQ^|)^<IajwTq8oyQ{O&eogh$_fgxN9OIlEW-}3X
zm})a+`5N_gZm-*rXdfkce4VUOM}wOVNiWwx!;q(}8+r1^_g&kL*QBGtkvbV|SIvMH
zIhrBqw;sAy?W&cjn?BIjMXQsj{Unu98EHn_RrT9L@k^VrcVkoCf*JGYH=9r1o3W9%
zqZO(sxZ#lc8#NUtV@G8l>2+N^Pu)gOeUGn;Dw?<*`Ena90dShf_Jg#v`zktWvvRyf
zJ2E15u_cmpE^PDr<I|ljbtK4iHf6l28<`GbOM#xe6#1AhQ{0yPd}QPZ8*3Dx@{(?6
zpr^f&^73=QuI3!-C2CJLMg0$DDB&t<Pf>f`;$%n@<`{_2U8HV8hLVqlHq*Tf=l8l?
zt|v`DmiA-1?#2l<8W`ZB<AiSvq%V%h6e%CpA-ZZuZJ6wMkVz^2FVsz%TN_9_Dx2!s
zSB+oT|9aaVaIsA*D%)t;k(I5BZAawnPRw4*SsZDT{5WB_@eAb)#(z#u^~dU$Wn(u`
z28FyF&z$Zc?UdcO*Bjl%%T>CIm#eq;F%kk7m#MOMGHIC5YhCq5F5mBMiOBUPc<6E&
zW1bExSJGUevYCTAtD4d^nfgqNKJ;3X;l--fY9^Xz8yTgCt}YyFsr`)48~ihX^3gV?
z^yKAfL!Q(sQ+DzB`0FA|d>-M;Y_Mxwq!ZbL+NiI;g+9f~(#7868@&nMgFaFvN>6K4
z(nr#>2eI#C`n_-uZwY?!=Z~rnrTF{jk9zk+?VQiYu7rH-CPVE>`JhGlKb4R8^T_V<
z;rsXwGbpn*>dRvz<*_#@A0xWv!#?-@zgs3gFU!VKV7RDl{f11HeB9W1zHKFx$s3uM
z-j<8EuXXBha5H&st+DFW;PaGATT)&q7aj*s;N?s6P}OgcRe!bGq!RyEV(N+B`?&C4
zqZ_>oBDFCu>R0sQCj!4Q@>6|k2i-HONoJ{)Ywa@|2DU&m3d-3-*<8=VRQvv;yRQUX
zJ&f-<GU=*av+;S~&^^c(za0LjzE$a(r`%?*y!fe3y7XpMEy`F~SoXy`rSq05L0iA8
z*^Xb=&}z=v9$!=AUXWE9a|q*}1;#f%n&-J1FS}=v;t}lY*SNWadv7&zWkbR6Q@XXF
z<?YtOLbfKaOSqr3wy(A-{_IofrSW%pE$87zUS93I=FLR}N$t|ZS)As1G;Qd?x-$2!
zNWS4G8B6RXBBIN7(k>lA|KNA{j$~8#PKaqmWIH#6ex}!n+RpUIJCe$ux1H$+u^r;|
zXglT|$pqV(-i_^$UXQjjz2M-sqrAj6&F0yT<B@1P%8y<HH%5(KqqZ~M?_=!7b`&@I
z?ufS?`~zN5+rdB4cKlwj!Q*Yg-V4Zf+U#X&=^@xo!;p)5Wj9A3Fz>jj%^4|nvYWd@
zyD>9}!**leC5pB={~PSa_fLDYP>4ITkL{mM0sGJ{=2j>7wcYhkTWm71|6%|1()~eS
z6tpo92Y$mf+%s+KHZa~lsXtJgdp2X;8A)}TLj+V;REK)%!_;3KN*}hGc=0|=GWm9I
zMuA(Mo|UO;s;*^Ig5LB9+k>9^xiN%0SU*=rn4bE%Ecd(X=PJ3^T|c*idp-4Y>$v~?
zK+|{orplC2DgH_QoEibE|Je<Td2xt2Zk{gE-0!X*H19sphV8~4tCYUA4O6ZqT%Q2t
zm%Tl;QT=DM4{e)FK%5#MwSy`nxf0t}Rp$4h3?91}^r7{k^+8)We7N|jEu0ei$u#rq
zn>HXAe?{#(vCoRxcX$1)w{NvCv7O<D_fTX|`NaEKZ{N{=HfrC~dtu-3OzexjeJAD%
zSyXSmeM=`veX+N1$0O(;)uvXGhU{B;j`zjhzPsy-y?vAKMEfSqfS2U-_C39zXZt2z
zk9~FV6oke-1j$C%=mOV#2sYZ=zWU9t27R>|&&fWQ1@>v@4C<@5A&1&u@^IKb(Z&Bu
z_UYFMJDh#;8i84VZUFx}kagBIrVsDBmttb3np1>aCn%kD|9o5>z1A{{!RUTKwc(@O
zJE_^LxrzH1q;~&h=yz{pO!8^*FPXH&p785mbvFFe&LlW<cCqZbgqv4m*Lq)fNm)x%
zGuLWA)R(zFX-0ibVDhHDEaP4a6;yjlqjTDH7$=Az`N#S*G4wzRHx(KLY2VE6k$+Qr
zlKiNX`_kF#od>nyCJ&_F-55o>nZx~fKBb$q{7u}9-<36?u_j~sTR(n$Qkld}#730Y
zE5Q3%-$*}TY$d<DWy)$AY1e!<y3v91zQm*w{}+xQ`#faQW3CbQuYY?m@RJISUFASG
zRx<DQ%huEn#P=Sz;TNC7E6=O(w|Tbv%KZRF?LZ~>WREinTFv+-Jc-)&?P>1WxZ%4@
z8rM`}4;#@_6$|X2w0bf2rEQ8fe8Upn$_@6fN5?aTddP`84N_lmvMz9CwmpxHXA%|M
zWkA!LHGx}#{$jX!Vqn$;LcbA`LAuR>(l`A@7k%RwoSESDjbG5&M)f_tpnH8!KZw2=
zTLkY{%bvYnrx)bw^+s1er_PY{_8UFYshNC$w;hU3)dAyrqtgdN{S_;Ybb5Q>=g)BY
z-=|aAqp$DFu9f6Ge_)=dZ2>P)-@mVlzc!)1GraDuzVBBe&K3F}sgmIRgWdS){R8Rf
z+0O>`JQ!PlC-e*IzTRDo*Zo2G#p`|=zohpLhT@-8_hnOCkY@tzny>rQcw=8}g4&jz
z+5{DJyiHKODZ#(Oq{oPtJ?!$U4g7d5mEYz)5^Qw|I@kMR(>`PL5cW-kp+9TNEV7M<
z<lKng_!H$n`+9#ch3c7<)M~=l)HP?vn-9KmY0^@gXJt`ZQ-XK?H<uwhyq9zTXsd72
zXI64;=Z%f#a6Bz>;br;-*-EtinmbE(n7c!&YiUSsQ(|39G?>Kp%TyqnRN|UuXHc)g
z_UoC@FKEBK%|zQTZ!^*M%iB!6{qi;wZ@;28<J+&e&3ONKKjLjB+O9=yW_m$ao0(qV
zZ6@sVku}jan7<_2#`J>jZNsKzZ6jK~JIZY#i~*u;>F*Aud?Rh?!OC~gKmB}WxCyFu
zVsB8sVO#qDxAK+l{d2O-v#stQ2Gj<vh1zLTwtX(4EoNwNRi-6zp{o0_XWBhqvh7v8
zZ7qdgylpMRFFvkPJ2@2pGoY?#RCGUfisp6IbwtMHAm#NANbhrZtV_r%&B&qVRrR)n
zv~6C)z2>Ta-Q_plmne-iX~f%o<;U;$A9g(faLSAJ*BlQ$NZFM=oRA+|cGIes*mhp!
zMeqb?%S-(GbJvzlm<RbQV!V8!a_w_+u?%PShv<=%&Lqet$z}DNCzslRt}fq>;x;3_
zcGY2@qGDv(3(0QYZ~2@4D$RA8#wO`~6F&zlzJWlv6X`d#&qeLPUgluiY&uh#r-a8Q
z%*tk}6;^tkqaR&eupgn4dv3lM%>C5A*5dEZ=b1E1?_Eu;YgYN|OszC1Lf*-ZtqnEi
zMQb*PC>UbQ;+E-Gi^1;B(kbDd-^1V!lflcx8wxsG^S7FHPveLE=x-Rh_&wKuaXLH>
znT7;$>VkgTpXs&J>Fx=_91VR1dI{YXf8N;Ul;(=O9q|=BuWnqNsWJLfStdB6Kk2EA
zn@M_-tRvyO1NuB+F0s5QyJ%gC%34??KG_@f-?n`!=TAc=)T8uzBWvD%rkR<l8b2md
zSxawSU1+N+kLWv7l3(_HqZwc6{et}cmcDKexyh!gwP)3DjeQ<NroC3CE^}hpfw2j~
zbuU*cutCWc-{<0GOR^E)rX{^+?`7VRAhXUvDE>l1dqllI6q)0DCk|C+zvq3$Toi%R
za*@h@5~Q-vTAB08{`#u=Tdy=HTKBZp5|(`lX~oN4ww+Y=%14@ewoU4~57)1&^}m@w
zxQigwE7`|1<lUAaZ@6<Ylw7vaoAx!nr_<|ejpKhhe5Eh#!<D`YAMILK#Fd8#i>sP!
zy?(vx%2@yY(>o9Xr!7CKD;GltXlqK0OeGcC3^OgWa9*ZK%LaNe&_0{)P7i7n{8;%h
zE|?#gmlk~g?fe$%MSc0HJqp6{YM}4C|Ah?fg<0G<zG=Z^!s^}p+pL~ax~D$V=V4q0
ziQpzeRGHKj&=G@q2H$NShMRi+M&&{Inj<+({yF@cS+lp%{>VkXYMU|{mouBU|8#lN
zeVey8OO>guE^m@mHah}3jxc*|_=*a*3Trz<yMgCmZJ5S`YQwsF7ARex@|dy7RQ9b_
z9&f`FD~X6Z7m^L13H{GN?8S!fx;AZ2f9k1S4ePvQimyrgb&oBT+{8us{*k(qvwXX>
z>29FSl#dr#b?_W<yVpy;4AFPW^X#n3h+y8cQ{K;mE<lD&k-Ymo*{_vnw5=0QukQ_x
zr`CGJQ~8&^QypQO5$2VS!A?Vao!7X&eOozl9z1YSzS4Jz<=dmaCBmWV+V_VW9Dmhi
z*}dAQAF8~&;m;8ycHGCv>tOA)?~i*LhmSNPQoCPE?@Am6>BH#TlK7+cIDZB2>a3lK
ze}8V;F?TpWP`P{kZ*cra5l;EP2>KW0-q~HbBf!+E=9bqwzKWN>-|Jjb14G=Ykn+#*
z7^y#@|Ki6J#v{y+LK`%?h>Bv$gXjq^tas8!yxw_R*yLo<98I#QVf+rVRCXf^s+d-_
zpssp)>%xQb_GQtNEtF(nh&vV%|6`z6>1c9E{H-m#X8uXG;M=~<j=%Pti~j)V9&Dk_
z@;7a6<b4J!0h#xHREdM?L4B6WAbJLb?9uPVFQ3m%oOCZ43ZWBEN~PM9bbvj0-lhSj
zKw{$bTAt{+4wA>)#Lfi>fO{+RO2kMF1V>^Mn<6^#Z87YbxVwW_39I&@R*}27&>pkg
zi?+$q&l3Dvpc#?%zg)zRV_nVoWd(jZo6v<bi*~ZJwupaY)~@CGaX~TnID<sfQzI*v
z!JIU0=Gtb>F_`f9vAe(5m<?_Pb5eURf1V^cPLmu_e(pTlIh64Z^m+&PioR(3|L*3h
z-Ztmf5g2zl`loqJjRwb(_w<*-{wcp4S~8QH8W$?}di~$qrp8O&75X13TOP`57C-y`
z3Ughv3}f}D{HR>)Sj*qDy2}M|YU>u*ZDB!KsEll!;GWT2TM(zkJ|4Af%vd$ey`cQr
zVx~EBC;A$U4zA(emu;T0FFU@nYx-U$B{ZQiyVQ=SeB3$2y_UE~Y_R%P+!C&B+=vV|
zsu>$b#|Jx{{?$Jm4QWpEH2Uwb>2>L++5TMWbxsqO;KDvC&E2GS(T`2aZ?Vx&0MsU^
zeSU>R_a^bCRf_VqG2{P3-fD~DYf{nrzuobU=ezLB$^BDZ^Yli)V5ItgsCoD8Px-A@
z_ITdQlK7jv=kt%}++H6%|6cc79e+&^RPI`aIhu0MTK>^-xRwf#fQ|dSn%diO*-@tb
zGE+BWbADVhwcbj4vg6BAjM<yAw<}+oe$Uo_nZdTbLv0eV|2FSxXVo^v$0c6x{TJG3
za{%>+v!K7w7Z!dcY;VG`2>i*k=YFtpp?H^&UX-`|O7UxjI1kHw!&-H>3_bKk7LCU*
zvAh|d+jR&RHmIw9p1RD*K883dvk}mTs5ChnKmPvMVjY!pFk6*;Y0~*1>G*dgRZl$6
zk(&76MnST9)fe-97|XMwBH@Lq?rkKMw+0qphm|bKn|(HUXzzu2``()%x4sXS{;I3r
zak<?~NB=ivAMVyvRyCpooZ4cw4`)L<>oe<Rk1XExR^HcZz0upnAa$rX_1UsTs!(b$
z>k1uS#zoalEftd*s@ZVlPBHIw+u_%9nn+V?2~XKHQ>VDKjeYp*Th85m=ltaXdS39k
zW2daW_okg6IeARS$UfKIj{bJBa8_9GqdT5^=3jsP@V=!VIQ672t-Oh`Q8@$i!h#1L
z|MtY&r#x`epU!#TUw&|3BV(C%I+4PH+3)Q;s`{pdFWzwPfME+i|FcIq-w)n}1uxwG
z-$yQd^|4jOXZ*hD%)5U36ZW`WDgRT-JFmIx<<mZK?{_~sBlXR%G6DY88S+2=!jmRl
z|FxmVwKQC?b?okQsZcdX$^YAXZ~Ii?hj&k(_Lbwl@%!I?m-MTRoNvFk=IM9syLS1j
z<F0z-3!gpqAM8J(lPoNl{*lvGzWtm1UcL0XzJIR$LWvrXBjn%yz-=$S`p5K+(dYlq
zvU!sqUe8#gul&FDz$=?CzjM;wKV1ErOMd>tS12&P&5i#z%SK;1;pSsrJ>ue@U*2!?
zgNqq|U}%K}Kl@?Z9X~6(`jumA{yKKZc|ZGYD)n0$)WU*+OJ8a`s`l3nD@MKg*1}H}
z-AP+aV^CO7JaFo7e)_fYuU~rK7yfYk54L@Z^Ig$tVZkHwzIOkLKY#9qYtDav`OJl5
z#xq_ra;{mP8TrZI-aV*hMaMleUfg>vWoi7Mz4OQgM?SFn4>#P`vHX#aAJ9PGVA5|o
z<(eZW4*vL8-?9JI;Xk=?FOC04jQ{w|DMx=`_>a!{+2)%jU3SYCuj5<bsG_jol|Nnk
zg;_WJ<8Akh+fjLA=F(}5ElqiS@J+)$Kl}D`M-D&Yzuxn}xp!{mnaFVp|IGK_wRY*B
zKeYV2BR_oOJOA<RD>;kAl-K0x)hGY=oPEQN&JON;=f(R;yxRDGddYDg96ol&h>hPJ
zH0$YSuEHjpjoyyE_vAlpX}xRro{_ir>AURGtJy1N!uOqf#?zl(dq&xPm-_F+&!@r^
z7HqD3bw$z34_$Tk#7`aZ>aQPpiTQ^~=gv?4^c#iaTTb}UGxOeb^UJq3bGFcMg+Fh|
zp06!G<AV?G+tu*YmnKf3a{Tfb`EP&a`u{qw^W}mUYla+k{qyUlBfs(g-O{>Oe*Wx?
z&wO|M*Ka@Z*J~M+-);2s;<KOp<mNr|TPK`&!WB>crV9V`5T(=klh3^S+J=t~AN}Uj
zf8Fr$Isam<!sxl|zG3g%a@M2gv|oSyW0wr<{5kdA$aB+Q{@8!rZ9o0WZP$JLx|?s<
z`6bT1H}>|A>%acU-~Z9{n~mF64xPQ><L{>&P5O0bt?8^DxBI5Q@7jLr%9B?wqTfZH
zQrY4(J9gE#9NX|a3mS*N+}<Pk4m<cFm<Im}ZU+Aj{wMef_zUn=@Q>g>!9RgV9F@u)
zO&Z66mx>2?J$O9W0G<He0S*K|4W0<D1>XXG85|5g2c81{4tzU!EOvS-SO})UGr_aK
z3E<fv$Nr~=g6{#(0eM`PIuB&2HFW{F8@vcSl6(#a%fJ!fOmGzV2sj#i0vrQA4PFB3
zd-Y?%?}L|tKLks_AA=J>efx4ED1D|O_kBk5%_`{=@lE>-q%L>iq<8lnLi2sX-st^1
z#FyTwI!5oEp!6<%OYi>!O7F*zw)B1(D81hRO7B@vdcPBt-X8#^_s@dT`$kZDe;$<H
z{{Tww$Dudr{RB{Y9|}tElR@eIR#19h0ZQ*YrZakHDsS}uM^Jh{8a+wxvq0&6HYmM+
z0hHdK0;Tuwg3|jIP<r16O7A}crS~16^setYM)mH#IoPA#m!Ko}Z9Vf%HR+x1%A7X?
zq?VJe?ESr<#<?p%s$1&);7IU;AWci^e(-kili*Lm2f!D=hrkl_wjR6^d<;}sKMs2P
zaNo8|l=BNNoaA)hcsr<^=MYwMjsPX6o&mica=LG<^(bc<yxh0O%r~s0Pr6m}EC)z+
z_D$vJ`cr=ZrO!WuGr_-udYrZ&d?&~RG^cNu6@$`~(skd!dR^1)k1e`yGnsETN#4t$
z1Mrr^=5tyz-wUd|UjoO0e+4D)Kfw2bgwOpA{3m#X;vSL89R>CQwg0Uzcn;VPRKAV^
zuK<q$^&Jk{u-rGm<H7#~sav@n;7Q<%;9wBmsnbBxN}UI){+$nw1TO$bffs?7f@8qB
z;AP;~K-$FI55P%af9lCqU^!R{)`8c8?*@6VKKCAw&k5$f43b7}1pNq~Kg!JnE5R&S
z1%3>y0Y4Acf!n}az#oBGa1P_6JHff&J3)<?a^QUMZtzy{-QYs-1K^|JHt=}HD?bCz
z0(XL=!JmVr;4i>w;IF_|@DJd7z&+p>!9RhtP1;YJI}I!XX=73+fV8!#K_G2K>TTf1
z!BfF?U>cO2b)sYU%^veDAKAkt(02Ug4%@^3S$p_A<@pQjf~C0J|9~t-<(LkqSf0rB
z169sPfhy-gpvrj&sB%6BR5{-Ps+{#rCST5*C`<PZ81roym9y49Hb8RY39ov86?g?$
z3Qh#4f(lDtmHR!&cV%*a1}i~*w<ZIg4K4sRX1Wzz3O0b>0kh!Gz-I7eumx0GvlJXg
z{k#*r9J~vB8hj_X1*C4~#!(;JKx9j;24%0CAoqO|^WBpFjrrK@^6`wz$7L=b`o4<K
zM<w}i-_9`eC*^}-d8!<eYbU=afDeNAfDeJIz|VqT1lNI2f{%h3^!XTA4{ikYZ4Sl~
zMqibLao@Ty-@te+d>B$2KHqSB<~u$M9Ut2KfKLiP_iYOE%?j~31=<J6F-9}};NL;@
zgKW*ueGTjnJ`ElVY8=5nyIfz=dJA|icoH}RJPlj|o(|p*4gob@#`bbQ0O@OTFMz}`
z{l_ryWaK*^r0q`)2Wj(D7lRGp7;p)Q&F1a{Cxa=<XF7N(SO#K?scXRxfY*WjXy+MA
z=8gs50ak(4;CzrWF#47r+&2}>w-%E0a6b8z9`sCDdeA&VdiXIYJ!l>wJ)i@l2h}U-
zp$e29?g6ET^`P|d6;OImTP{8P36vh_i&N5r>Y4Pwr)`ZMszK?2zRBp}9#DFq?J;^d
z-sxeQ)5Axc9zN;xaFWx*DNYZ~P7nH~gx5nYd2r|do9_aYa?P|bH5Zaoz1Fzx!{7uE
z9yz9tsgHpR!ByaUz>kCXf}a2%0Ph7K0`CVO1=oOT7sf#DjDB-=zs9hL6TH7IeGlaN
zWsqrQ>Yrc<$TZW$FXp#958v3W<R!bQA&}ht+*bWu1FBwr(#5Ofw>!r^wVdCI7p=!?
zhZX)b@a^Ckp!(M#;I-gcU^RF)sC*9v8^QBHjjzuKmA^FP&Yw5WzLY<TIha?`CYW$@
z@N;Lqr*7r9<mnGhh2&<?k4PSke<aT=P~+uta56X>R2y_1$dX11o5@vye2z8Hvpd(^
zj1yKPL{!fW$f5j`ms}duwfYtE6vTIDlAE*2<MEN#$aNJsf_PKFX&`fsAig_4T=!D(
z_*W9{RQ$(-BSCB{hhJ)<i?4EaXL_5nzNMdNIjfz0Gk$7!hl0A6{uR%iscqs(|Iv7i
zeNDV0LB-RxkLS*@HfhB9%|ox^r}5>vpssy9cb>E1r+h~F-9UaM!;RoM;7u-nCH!`0
zF)Qz;{24}=Gm(K5ZC+0Ey``Ya|90?F@D8v9Tn2jn?)+p^&T+ZFhF*>%{MSM0`H6_0
z+}Xw^UR+Nnq8G(e`>uFu*E~OW*07Oz=n?t(ok{)_Zx*P0VWUC3^oQ;GO$q*SIn@s;
z-Zw$zb5m5#NW8e5Cp$Uc1}fg*sGKg|umpY^NMHJ8E@8^$D-nL~yxWxKQ*nN3?-j2I
zRQqszgr7T?)|^)xkM}L~pm<M%*MQ%1dXXO7*|FwKSzR+6G`s;bUnvA{b9T@KQfE@l
z;0&+@tOr{`l}`!e&U-cIz$(3{U1?mRdjC1_Euh9HL&1l^^Fh{@Ogdxu?apg8?X2<>
zZ9k47-%3~g;7Q;Ba4`5Lrw_$<XR9X0e}eog{*$2MGj=iYp8}N+#dqhRnrBMNN0h(j
zbIQl9;4rWrRDZG1=|Sy)JHs@U=C|TU>*a?Cr+y9-G3`)WB%V8GG_gKuye&JO0;*nI
z?eryn?hMex`t(EcrFh#w#rrRpPsMX*a+-57<8m%XF2!T5FgFT(Z$wUaZf0V<_q%wE
z8B9FQV}1Q~XEz$XwvlF3FW+NbMrFMPls=yUeLQzoVq&}>xp>dHc-tfK+}VVQ@#eaC
zH@kT6h{SW}04By;;NsP~cy%t`P}*O2=AJo=Px(6?qFpfV3D#{?51#~OuTOzzf=`1N
zfZqXC@4pMum!+NoGvKpe4*XB>KftZvSHSOslx6CN;0xe?fxicT1TvOMJqK!h_&j(a
z_yRZ@+zCzsUj#K?d<Con4}h)UtKc$_XPmheU|;Z~Aal#yD)2~9>(R%64}$~1zO=<}
z23fO76@hODS+g+X$`e7>SW+i}SA)z+O}VC#(VaVI&ZCpQNG=$!>_-ljzwFYTF_yZQ
z-wGFPr;a8))kn#raf{@s1tm`lD0%J%C6Cf;gNZwP%A851^e%*!i#e_YzAC5jpvq|i
zsB*drR5?unOTeo^jXS1-H-Xc@I<O2}4qgj>8k`Agel!c*0nP>wfY*U(c-{bB0^S79
z1aAiCf)(H`U?sQ&WUVN7FIWS1fOX(T@D}j9;BDZ4gLi@&-`@rP6{NAt9gW`K1r7q2
zgJ*;92hRc9z>C0-fUJ$BJ_=3&KL(b8_kmhByC0kn{s&kKehQ>7NIe9yrj_~(xC2}V
z?gAeH{{ns<R7GbkD>nfABFI`qY6Ex*_+?P#l7`$FN@m|c+#WvU!j%!uonw=Fh~Emw
za#d;~B=-Q}WDk-{_8_@r50XpvAi3@aC70q#F7e+Dx${TV#~Hgj8NZ#7++S&LmG0j_
z`TreMU$GyQ9lQ)yfUkf{z<+`(!GD3D0gvdL%6%Q|13m{H3GM;=gZ(I{V?f3dDdvv3
z@!$Y(0{AA7Ic4fN@SWhB!OwsL!AC&mTDeW&An-5XTfu$c$>1^M<89zLa4@KO?dhQM
zn}zIoC-xi^>Ec+Z29g^}eUbjo1=HYp;CbLM@Lk~fpz?Pi_%m<>_*-x!_#${QxF2M#
zGWRk#1{7b_XM0YGopXq9v_4-+xIy?$0E@wi;ArqFZ~}NW$k;!14XE@wAa@psIU_{r
zN$$0fTs`?!daTjrP6wHbnsj*fZ00SC!8`F^2Cf0$2|fuf2hT%~D?qiEtHEc%2SBZT
zJ_J4wJ`DZ>d<0beTMzyj<XK~G0Q&wicqaHHsOQVy03~-Ca%XI$PUE-aCR)(`ea3~8
z4&1pBW^AHxRGZWgNRG8;W0&Hq^*ZrY`s$C|nF;1B1;tbTeSakTRJ&I|_;H}@@@DWT
z@D5P+D1FEd9|dKHn?Tv$&%r{Fxs0*HY2aJ9t^j3^THli$z8jSNeE^jGeHA<v{3duB
z_zZXkD1Dv<{t`SF)cQVa?55os1)hN3MuQiCW58l?EU0yx%fJtU6G6sQsZx-wKdCZM
z>xHwx?|^f_XTh7mAA@tjm%u8}mxntu!0cy<mq)n^r}A*`o+p;a4TMuWAwDV(@lpC}
zgWP-5sfYQk^feBg3(0-4z}B}ffoF03W$+4+wVNDsxfHrH^MBg>+<UqH8n^=dI@k{K
ztRyF!e+m@8Eacu@PUZM5e$o0(pJD3v_dxNZEX=s;`=II>Yi8y-)DOXOuD5||-+lz%
z3i9kZw-}@j7<>5%D8AB<d&k(+L)E>gy<SVRqkPW<j|XRgil=tLy#t&Qf5kfzl5NV}
zO8Od))`M>a8$j`D1Qn(Uyc}!>m7enJ-o-WV=<52-&~ixbmyFw#UMF}8_$%;q@Xw&y
zmlwfm@Gsz9;7i~q!M}lD1YZW#t{njX1-=RvV7LDQRWDdn$uUPs9RV_TOZ5RIR~h8q
zb4@+LZ^;$yzs3?y_H!wy@y2D~=fNw$$H4L625<tXao|Ky>1HAKPO549q|a!1zrr|N
z`F#~kgZ~6afd2v~g9Wq)vc*1N1K1bLf&IX{!6U&Bg8jiygU5j4TMW7PPR&}H@)IrZ
z9}`aP@$=x>;7=m)+`FHN@qX#zb-H-Ja`8$?!@YlL-pf=z`#~ciIX(YSK92+61{Q+n
zf~;BQCV_e$;^lVlMW!_0P&!e$Gw4O-z?jF(^A><Uo_n9sw5RcSZy|m0KM9mwG1f8h
z#_-#|b4c5z-?Tk_!C{cx<J1G`>5HJ^eF@aM8)Y5Dx9|H==J?0sKS?;%nQwryW6fvP
zetgr#H|6xGT?dgY@p8JjpUv+mP<AmE^!at~zL~wC@%(Oa`F#dFlX%a%{EDA@cg@6;
zY*GCVp`J=lXM&1%maDgl=iWCnwiV~MnsQJ)*5u82gkwAdIo&&BW;`E{_kAbl4?x)i
zdsKpW?wv0aFD~afPR?^d#bZnm#B=XznfEc{`uslGm;L+zRC)g}QV#ANE3@tz=l3}2
z%bwLAs9jKhpmHdI+`Ca`UaI^loVWYmk{|K=9Vk264Gsl=56Zs(0Q&ND?>L!vpW^&4
zaQvAwn)Sb8$6w{*-bXU~;N$UV8;sl^0*eUy;Yfbndqk!^ipTrB<HxfK(=U7>!q2_`
zWA;JE%d?LBDF3&B13*1j^!an|?3j0X;{1N;<m?0siT5if=SF_JcWcZ$H{v%CS`W#s
z!_H0u9|on@M?kH^>3OXBi}m1C@C)FzAXP2b1a^SSz{f%L+g}7f0P1<|YLKx??m>_(
zq`A+5UkASiJ^`wKcnW+L{3f^+{1&(u{5Cj{euXiP$+zTp@1&S_RpRnLLpb%DjDd2e
zfj<PV1OE%G02veIJ`Vl_d>CXdm!nNe{S*}c7r^bH_8<HL)c%7`@E72(!C!;_0RJ28
zi(J12PXTv>XM?{7F9QDnjsUeUVKn$>(3hKgr^B?z@p5}N<s|#2|2FOMdtAB6F5UYW
ziQ|oSXI~G1#}oF!h<&+tDH8duaQxoy_}vrX=iY%x<j361*yU#(zt1^-bKvdXT}Vma
zDxdz4Y)0-Qj^9T?)t`@n>IYVV=YW)r=?^{uj^~=Sklc+RHWcX3y`#W;K3)5>7pNc7
zAA7>gxb)|)zLeqT-YqcCTO^m-9rZDC>?zB=349Jb72FO=9`)<8d-dzGclGPDz#X73
zPq**ijFaQfC*FbFk_TOw{-!dLk8M;6Oe1mq?Hi1*WE)R`7lGddJwLa1J~7@*7jKq}
zS00Jy_N^z5L$;D1wWsPo&IZ+gcz$j#x!GgBiF?uht(tOI{%SzABN=cb1F~8svn!zu
zP$!wxn%P8%^>no{+P9-;f7(Bh+DVu_&;dvXGYp01Kv`%7v>I9mJqc}x_CWn<luDqv
zPz$sQ+6L{12GJ3XgKD6a&<1E1RCp==Pz|&K>VS4YeHmB}gUX?0P&>34+5-)^j5ts&
zv;ykT_2pbcs~~lXb0G~v)<RpL!V+YIYN1uoCTI^d2!k$x>Y+BM1L}kduf!j!fmT7A
zpxw~G3GjmIp*7GZXeV?48jRtNgXTiZpf%8w&`#(8G<XvCp}Ej9Xbtovv=h>U;UQ2d
zR1d9&wm_ZG0Vs{Zmq9I18?+hP2Mwgs6hoEJa%cmz13CZ=n?ia}4YUke1+9m$tJF^L
z0F=I(d_t8_4r+%sL7mWkXwWs>hiae|&{}8{v<DhU12Pht11*ErLR+9cP~kM>7>aCQ
z8B`Cggw{h_piZdobnFT$g=!%^WM2(+KwF?r=m0c$27Dl$ZCMYsK^vg$&>pBi4arcb
z6smz%K<l9`&@Sizl%}DW3$2Dap`kMg3$;T}LI<FMG$LitYG@Z!T#mk>C!qt-xY_6!
z+6EQUflY;0LR+Ch*OLe6NvQuEbOJ4d+M!KQC)EE2(uAf$Ezlb1NoY4zcq8iz&|FB3
z>jr2Cq=%;?p*c_%S_5r`_CbYnkqIh?mO*QvjnH;zFI0FlHUO1FEl?ZO0d0f!K?7+B
zM?&RLJ+vHJ18s!1LwlgU73d!-hDxEiPz$sYS_?f1ZHM+ieJjy3G!80<vd{`>4YUE;
z2JM0RS0NWv0+mCx&<bchv=!P14V;H;(DD>{2RA@Fp#9LGYIs0%q2*8qv;#`jkS<gX
zErHfRo1xv%fDHPDIN~?899j=;gZ4p#=hF^CS!gx18QKLEE`SeI1GPb$pk0t&a4vze
z&{}94bO0J!hpf<YXg#F&NBiFbU#JFJ1#N}2`C$x{h1Nlx(7<|RfR;e(p`B3SLj0f>
zXdSc@8qff5C=0bi+aPUVD2C=jE1@T$-H_fxnhGt0I-ot!klP3ct%9~dsU~EBvd}tc
z7c{t;d_XIpjnEz_-GU#q650&ygNC%?2d#uQLkFOdizrX19oh*ET1<IBZO~fSZH2b+
zJGF$eg62TWp$@1M(sQ4|OGyWs3e`f(pf%8w(01qmH1KxfLsOwF)CR4GwnBTL{&yfB
zG!80*Y9Qt%sg+<mv;o=-4O@mjp>0s*oumaVhgLzGp)q%16VN_r^E(OqF8umZ7ob`w
zl_QVPNQiaX)I_ixs)g1<V?IXS@ZZSq1JE4eZ{oW41oX}CZMp~U1^f0x9;g)Bg5OU0
zLxb)nJbpYsNloPU8n7N*4=w{&LYw*B4sL|{Lfg6C0xpBkE`Bc|ujO3tg!ak*-RKPJ
zdnCGqHuHN2v~@82xh`9c9=R@r>bX7u_Fqmsey908hTkg{584IogG%x1e-z<$4_X7Q
zheqPZm?yQF-#oiatwg4Q?;$Uw!=C=s5Pq)$JD^JZ%D8?~zrn5GPN*IKEZ3}gr8e+;
zK!5B6>cDRpI1ZW$ZQ*)5G?(8?pjFUruJ=J}`Mn9+2JM3OlGncP<sQEWg2Rp`4^W!l
z#ZW0UhwIHJ!VB38PvIKBHOOBJF4KMdmqDutw+>o~Upuss-&^H}4Xr2q2K=<>S_tVK
zq)lA!8bDt8okF%H;0oRAiyfi+t=xZ-cx&<70PW^_|9Qy5?{S3R&-HeG_kSPu0Tn}g
zkaHt(_d}KUQJ&Dm`;iUW2@U)Y^a3r1HbZ-%VQVNaXg#zO8t_T-4K0T{pxw}*PvHmU
zptaC;sPCtV3zb7Fpe@jTXjnTsfmT49pwt8837QM7fwn<~4^oy;JG28D^bq`@4N%{;
z<PTZ~ZHM}PhCD#+(0*v>XUQA18XERF<b&3&BizG;gLXnAA3-jt9oi0!`8?sFJy7L(
z<bw7?<zFCA(4a@j7c}TG>Nm6++6?vWAT4MKv<BJ<4St+7pjFUzXg@UZi<CRG5!wxn
z`x5p6ZG`qfWg93@DD`E2Lrb9D(7>;d7PJ!Tg!+CJ8-`k-HmLtb$`v~74r}1B1`ccB
zum%omKpN-^%}*5+>37Z8xmCp%&8=A6*mUdMQFEK;PHEsQoQ0X1IzG8EcM%_FZme&f
zTVFSiGY4Av*yzH{1r2;|bWtYT)Obrp#psJKxn#u1F(WRT%W?NLbE_8Cj2bz&zOnk&
z<_qv3{jsTWMFo}g+pIXAlA76iM1a%ks+$^{8|SyAht51FJtIrnb+_xY&=dGxPF;Pb
zDRpFOND&8bq~4wyP;|=)r14g*Q&m)$;}687qNQqHeTH|M2Nbo!Yk&NHb46W4T}xe6
zeckPu8lI!2`WL;YkUn(w^|Q)nR!krYY4<OB7QgbciV5SVPQ7ycglj4$O}}o+%o)=w
zt{b7}xKoQhiKhJ77n=$ci~bps9;+dpI9>K5vj@Tn7qYD|$`GIK&L{Qfc5ucoX+H_w
zOq%63y;OJSmiY55v_D2}7{oBtJpbQ-t~&GNkq}mfp$gp9m0X0M&Il<6D~Ug&pkk^b
z>5Pbi=j{HDZ{Z(3=cm*0zL7Z6#cZX4F48u<(?x4TS8eo8A0?!}6`Dc1L!1mr`jCt_
z$7CGk&rt0{WL#W7Z7~_Gh7MgvkH`4$gJ&mY+1)uByG~~un{ZynH;^~!{EJ_mA^)!D
zT%0jM{@;D}vG%!-bpGvglSfRy;Cn}wVV5TTfB&3|nxm9{*K;(qAE>aP_vcM?cmBc<
zldm`KJczp~hr)v1pUc1=B*MS8a~3M$;p)F>7j%6zR1V3}Eag-`P6kf}2ZN>H+reod
ze&#s@MP{C7p^{t`{%3;K;91~bK-EoGuZ=xda@_|S0?CaeoZ5hk!Lz|pE*|FK>!dl0
zs*-DpHF!>P4&fx<x!`Fab;azXIUl^1>kGhHApCQx<FpllJgy!k%5w?fB+pn-@>~j*
zQYTa|dU|%C_2uP+@B1y}hDxBdTyKT6zO#wzPN*EgOA%b_Bby+tiNx1ImiJ@s1!=8g
zGt}{I=3U?}sPB<>JtDdeG3IHz7U9<%{Cb1d8MMZrbp^ksptS_Qj^Ni2I*ISs4WerW
zS|jl51Dfai`Mu`$(Rsb*^P0;?=kA)bYp&k8nKu4A%#WcQbl4r%z+nv>*1%y69M-^L
z4II`$Z#BSBiN|(t-29*Kn^$G)Dry=RH`HeqW$N8h!0WOWa6D@QSBx)SGNO3Y$V~OT
z`O5Rj%>P^7#`uWw;1Q{XjWw<HnTm$0g_&lJu?G|_<=$Qf-+lbO+Ny?{dfm16@8Eua
zs84FX`;JCMwy{p@AkBxoX3)yGZoZp?4rZ<-Hwa=FmpTdhDEvxJGJAz8Ds-Hq;ip+>
zrlumZq#6+yWV{&TN~cVpRX%?Dgh>?@!y>=a=Uz@yW^F;3;7T6H)1RZ>22ai*t!m=X
zZH3i*zYzRIk^K1<MyvgP?K_;@ntRJd<z7V^m4_tvqQ<%!E3no=Y|35!_ex%ShGi(P
zKL@=<lObGG-cKNJuGjKP#$kb=y_NGGqra|tjmzoJ@9(P$=;UN7z={~pjF7XvJ2{*9
zI8%}>Q2ITcQR>T{d0Q%8_FBjB=Y+3Jkmo+++0-j}q^`?*Ek|5ec0I{{Pi3EzLvuzs
zrdO%^k)zYfQP)6`*VR-6m9#m-f@DLcUSYd0tF*Bx@d>`6&D>8;YeHgqHuOpO?6rJa
znwC~jLn<cMH;?D*UDXH8o7$L96MqW{9+9f1ajC0e^|ZpaM9uhxy!SZX7dqbOf)5b4
zc#vreBD^Q_8JdHaujjqH2j2d>Z}rS~<)XYFf_JtH@2fH`*O}&^*Lm;HVnKI#_x$%H
z@c%6QJG$_n^_uw)?ScQ*?%T%8WKgmEe-8e8^Z8E+){G}Kv3guxRX;0ZzOFQBN$<;}
zv<G=6J9%21p=-VOIA{*^dD+5S^K4;$T~l*QMb)CJx_T{lJF_CJY<>)w;Ec_yeJ|nW
zI@09(1xm)W`K5thJzphJ|Inu>hi<aSqkETI{w8di>-8pno#`_awvcf3knYvEu<B!m
za&7w(+re^aY+v@DR|nMS;n-Jd`oc=^F?e*u^6ffflTYa;!3FuO<mMtPXN|%s@3mn6
z<CS*}2Ba_ht%8U?oH8rw6iN3fVy7?ZChxZCN7a_vcD*69xMF^mOQS!n`DoMZc&@(}
z(TU2(hOe%wuBC4$igY18D$WMtXdrS92Rfk!!=vONads1@kuYl_aZ0<16V-e1u>`{1
z1S44M+^5vz=q&rTJbSav7WZXez0vz^5xwhs5Ymyg1L-KV1?71!vae?lbQximSiX$k
z?Ahctj?<Hi=5?ibyNI`tc+W@Tl?1%Hk2jcn-%hxz7>G&7;wOD|$4}1_o^WBmMBXIB
zb*|118$d*y;;Y}D0DYM-#i!)ykf&qS6;*uuIn&%+F`sX0RCH5|yRXBx-|}@hZpY%^
zlO2}@_q*D$@}K6u&A%HjJAEtf3vFIfUv+t(?(%-X<z2Q%aing6zDAg~Fz@w^j8u49
z*i=O)YVzH@w7Dg-u%f1}iAJ=sX(@5K&vPoM&n1LwB5hxH)xM<hvoeP^C3!#V<b8th
zy58ijFK1k)>%Ectwm#VJV{U#E3F4+g%Fk8M-K3G`5D4tVJ--Tu0Y+}=J;9mhXOdBR
zzt+f2zfnKWd{t3)uNQ&ZA+-nR*z`?ZPjmgG2|vHS*?cXu+Sr@qzQKjleO*_%Yvn7N
zkCo~?aMPjw&=lxl!ssxIynNUpMX&SmOVXg<K(6rH3R}oSE&N8qV?`_<-w5(C-;7-(
zqvZao3#a?Ke%f72MuqX`-p_qAiQ=O9ct3IW#`6&lPyVgEw2_Z7@Kj#*JDGglcq+(?
zhJxW-L-L<}s%=LUM%N?UwPcOvXJVnrj(MIdQ&U^|Ucyw`@S%N$!<~O4KlZzZwy#l{
zF$Ar$eN!cQOe4!U_%C#_`h0#f$R{7;h~@JE7gk}E&o8=b<w5!M^M@?uD7OHjyG_l5
z-bt9wynOaJtU74E)i<kdZ8Gv!yMb9nvmKe)HeLF)Hrt%7YpAH^gH6Faw=%dlzrJcg
zv*~|J(aBU~AJ4tNxV&B9+L><|K9MKaah6QdiDvX5-JF-UHlcXB9_Ox~=32ViN7zm(
z;~V`v_)C;^VZp=W3u<3Dz5brlzx(0&7qm4FI{ZA?e;?p(%HfTE9$XBM5<8bPYY}Z+
zYiVK#BzGR~4KkET6@yv};tZSMd1~b$#>*XIy!IaAEkiE#i+6z<>)aiYbJHQl>vZwd
zPgO!uz09D?!b|52XgZR*7Swa^H00*y!E<J+QgGhLKO^DXJlf20D+$wGI5+1#XgD`F
zJ!m*LhwL$&+9x-+Gkt>OlO8nwkoynvL6>CC;T#Emit9-r+oH`rfd{~Ht{(!g13v>Q
z&Ci0;Q#<75P-bpb$+ep1Rgm1b2q$~n42}T53tj<k0Vjk1399e?KB#n`18)PjgBrIz
z58e;%03QT@2JQxb4(<VWfp0?LzX4AKe+O!=@kg){B#e<$^})?K%v_|BYnm<d%pWl4
zYDzCz!Vd$RK<T3eycApvN-uYU?*Q)t=Yu)^J_1t5bI7i3@wuOXD|HM09|9+X9|o@l
zKMHCN^f6HSD}~%R-u$lQ`bbFqrrcwMI|1wf&jud{F9g2?jsV$$ZT3xk6;yiCp&J{U
z`C28{%GXp#?s~$hei6>>ySM>7hwGcbVvv5+lye5G<r>Oq%v}d6{SwHHRZW_eT=#>d
zD>>d}HtF{R>4wa?o#Vk{xV{QJ7WC=3v7#A!RdO$y&T)j3+;0Y1MmOg;%5HdvJ2wTS
ztb=siSS>M~K`x!Qx^#5@q|$jisB}&Ry*zG=6x5TbJf{;*<Eb;iQ^7M`e9jFrcB^v_
zd^&CnV#X$wgpH=7^8t>>k9WIsLqOi`Hv3#gf#_b}OU!j*AEMsuS1JB6HVbt?JE1}<
z%rIy!v;x`)?S_V8lyjkF&|3Ixg|x4wxBFSfoY?c8mgU^ndp6qFvWd#N4cg4_UC_U~
zzh&w@=;P_vw#Q`<M$_Fsmri6$|CBlbErZrWJD~kg(jJ(>G&;3V2ecO&_5%F~v;tZO
zZGrYcg*(~b1hqh`pbgMIXc&#vRHz<mgEl~i-C+$J*1%y6{J)}szGSrF4SfEeZEead
zs^giqmLOio_W%xc|Ni3)g7=Z<E%dQ(^!)qqzU%8A`a6>b#^7)0Je#p(ug7KM#^jH)
zlJ*P_xrFgDgTrBv-k)9$MfVN&v}aiFE+6WC;iSF7|L#8F|5w_v!}&a{fx{X&tbxNC
zIIMxg8aS+h!x}iOfx{X&xCS);e<R=jZ*8d2hC4I!e?8v+Kb<}Q6|)=I1<kg2?SS+f
ze=BM-E$oU^j*n583E9SGexI!0rB%%p<0nq7XkJ{EjfB(t0~NDcni?AxR5Ui#aLR!8
zEZ|pG)ufXGyr<G@%5a%&=B#X`&8Y-cP4JGyt(YI|@yQEAz%Z>aP+pkDnW|eYvoHX%
z94B7a2lq_An)EIJ88i2$@LB@f5*KCi^K9~eWoAKLgY%!XFx#@!{hr172R>~RUrN#5
z5O~dQU|XVj>tLRZ?c+Dp5XI_smI-e46o$_zgyB2WMzz0<xAmWBwxAGiK+)!b%&Sk<
z^WNHwc<Y^wpW>%|DMzGQ8gI=sl$*mG;Q1Ery`X!n+Z>USDcM`{|2zI=Z;^jfOG};g
z*B<C2c;?Y={HL(}T6@jv8XKmYZJ&l$KkjR@=@F^2rp)}hCGHlo9om@?!%ooq)pj2l
z-<dFOKL7DfRY3)B<GIUo=K1qP@fthUz_^Pp?|J{*Ma1=c{+>Z*-q)zDGi7i0EUx5%
z)r<n|U$OgPZZlyjD&{vfEv%v@Xs=l*57ql4lb$8^*>0bKE6p_5t<a2u`V3}*F6_Qs
zf40SDmyg-p8w8a>dM~ETrje!gHBE1<AuqwtAU{J1o8a=!mFP!WK0lI&Wto)APm8UG
zcE559{$57qvy|(2J|(-?|4P<s<f8gN4qltA+<E#R{yOXb2iP=cW#s993wm6EOw#{L
zuR;IISx1ul3?%)xLnn}rk{_Eg43r+#|7*!lT>sK*T>mQbxc=whmy}Pwzm&=%vz|%c
zW@R+Co90^nGYaOls!UW?$EDs;^llTTpZVTHwEU)Ovj<LLef>F^eCzos%Y1p|SNuAc
z-=Y({mfs3wFGVJm-vlc|kgrz!yluwo58tyeE?RzXCm(G#jl}YME&2I($}cIOW#q9K
znN@z@isdt@{GKym!tz_>+rOi2z9$36LF1vb$af{rw<$l4@EJR{k@I~T8>;HZwKg=@
zEojKpq$~8w+o+M3_jIpI=wUtUD;=~qCCG3L?Y(brd^>Wk@vE3wx1d&LZfx@tJ|D-(
z2c1CL7jPbQKKa-b$w!3_DpE$+Uf94`ptZWCVqR5qri-NHtM_5M#)h@o6FF2ry0|c(
zl6874pK4cMqybU8#89MaA%T?t68v5Mtv{WOY&gh2`{d=uLdyTeP%-(}h96&!VV-I-
zJ!OB`MR^K1Xy7CbXrFj*@;~#f`Q;qVf7mZZ^FOX)eA9yF3XDnl_x;~`m;W!2W!dpM
zXcYM`v-x-JP*pa|5NDjZQg3MAeG|_FmuHXB{@mN+g{J-CJqc%#YA0I_zkaC^+>?Bh
zoqd)MupFZDjYYm<_DY29WK_OcEmbY8%~r}o8+Uj)7n^=AU(VTvZz!kN<Gutr$0KLq
z&l2SHgNj3J*S&m~kv{JV<mvHZ!!MNYN~g!w+B}4d>ampg+E3C&kJ(5;6Q`$l7rGm}
zc^M}r$avxl;u*^5bvQ-_h>OZNmH69Cc;6?wvJQHdf6o@LPLS`fG5P#n{e4cpN)$E_
zId25Zh~L2;n^1=}jb$odGfK3&)A+(Wx*qR>dQyo`w4P|3Sc_kLoRY;aI!;l&dByPV
zms(1_(RDL>d!*ZK*ski4m%T%q4RLYVv%g4^T_dbFUiK#p?@;y;zf6|BzEIM1mA$w#
zNp|&?Z@lbx7~Y}mFS%>4ci(>Pak8tKW$4Hpku&44nZ3U<vYT-N?e*fSrkbSgz|=jW
zB)IThDcRJ8wvVTY&oB2H=96+!{x`rs_3My-GgIYpve{u52f8zny8N>|Rky|SdeVu`
z1ETh}Gl6df;R_S_jxvnZ&U9gEJo5R@P2hXCZ|BsB<4%DzL>mN^p__DsZ`hx|p5qy7
zb3@_R)rDnM%+2W7MLK)0lYNdR0yvGqCHoNQI{NvtMA;8Iyoe6Q4jLF%J&wH|=f2t{
z$sZkiNd9?F{(VmVsP0cd_iYjR4{c1`d)cDnU&-eCzpNT;9O9UI_!jV6w2_;vY!#)f
z&`hgps9KO|8awt%ok`(<a6Q?j@BdUEo+3Rz_7-n{US%z9v)p&+B&4EE;IHuOw7jEp
zJ;STigzoY$=r78+74I+R;J1@B{kwyD*QpY}EQCxPZ^{8Byo<;sYeRNjL}fXnpsu-s
zA$>zNZ|~RGwUicgRYO`=Am^3;ZQ2R?mb|qKV+*p+Xn&+UNAtbQ<@-9qsq4HJ+KpfO
zH_>+6WWNX7vuA~R+l%Jg%OpNpABys>Q32zWN42@yv;HFC+PdM*?F1LjIaIz;-jb&f
zzdsw^O=!-xyS~gj9e*{b8hTv<{eiICy5XPPZX7)CwtVgTlb&~0Mvm)*r1uw~AHzHS
z+hn~Ts=eKB@}4z$*VtpWNxxre4gS%x*z4rcxK6rQ2mOpNCBI9S=e5o&R2Is^tJp1e
zAd}4FKUbXq?hHtM@afP?(#P&({@hM*-P=MmuS03C<pxl9)DFH3{SaPd-SASqO>pDY
zt{jsZYw|Utpup6(O8nwBSc{+96zYBJLQs8k8kF7h9_uW#?!a$ff9g!%Y1gRaH<WvJ
z-6MOY7OtXs+3E7~L&7L8-++EZUfO@3tha;ZrG)qg%Ztj$=f%rcRV2Sq<}_jAGW&6E
z8EvqfKxM5gJjg}IA3~Y!dTubs>9Ku(ocNNXKX^asMB8^iZ`tB_s>+KeDoX9fZ=2;g
zGn1|7L=76>v17yEgz0U+^79zqTim<p^^~QY@+iJC^G5vkTE3OD8zyF|8=EX=Ug>pL
znHnw5pFMVL<#7I$H}Ssq%uID_Q!{Hk@#|j8*kJ6+uG`Coyl#dKMkw6pAj$V2^dS^g
z_(xM7c_KzGdgu?rdMF#8Oj^E7R8C{?v-2jCOViht;CBLrGNT~NThu)CBK!1+rmmE7
zPwl~sf||N!_b^8C-{{6Po1Fa7@pCN-@3iup@q5Me#)g)rx<z`FR@1t0;nIqhrCFXB
zB>VSV?ooToz{lrJGI<*>Rb|9o2B|$&p5I0O_F9?z>cZHu{ulRUYpUyAUA{h-89mu@
z^!jvtOs(QZ%XYhy<97Vj&$L2oiC?nElx?_*z~X&a+pH{-Il%>EoDyz+GA4`4%Jn(s
zQC3tZEpNA}y#r8tcms3^@jIO?RdxO`j{C*^-s)sjOb*Fz*Rbj{^ZBrs+T4=BuSv_S
z6<iu!HMqJuSTAki=%P$rm5j~QnaV#IT^(9oy(_=+D*c|?l&EdR>#H9-Y;$tXB`wK#
zJ#;&A=B%8J*^FsV(yTfeUcD(t+om_mOoBSM*t8eXXGr$ho*hp%G}0N(*Mn;5R(9Lx
zNYw?77HO>y`gi{<tSqgRQ>kkp+2Lepuo~k(hi$%A+^y)B^-%5yA8$p+nx6mmG`w(X
zkNjBkB=}eMz~4mZ`Y*8m{@jcA^@aGw$D3Y;Ij7mgqT|iCBSU)+GDxpoU4DBImqFzn
zZx6f-dz=j4CXC8K<AsxvVQ&vI^u~VTGDO;eVC;GR|ER3Pv8R_QtHvGoVMuM|J<uS@
zWWxJ3#edH>d^;H*fBHUfzmwqu@K&9AFZ37s^p3s8KEp9VXrwpYOqlN5r+hp8Lu7oQ
zIZ+95Z9Q6I+Mw%PU$#OO5%*?D;{}z`rHsuhUo>*`;+d7J{PXxg2621a)|>{9Xg@a7
z$um$BNZdytt#_=1Mi4gl8s#~cc#<XAmO^_jAzXZYz_)vCPL@f8Q5h-h`)H#|{$h0F
z4dgt$4KLYXS7&*t4CZjtw-vIFO0MH|*Yh55rcG%ga6EJcv=ZL!{|0YYM}v7ocf40R
z-V+>ewI3gXcj~3ro^Rz-`Ht3u?(**IXZkE6;I4+Gcj<qi+D^;g3>(5~ab6GQ9M*{v
z()e4X&sKSq;TJ8BG}oiy!*lJ%YBrH*Ea7F^m>|>fgx&Ny$|Su=rf9jyuP3?6&L#pb
zs;eU8O7Ame^}6WF%jN8+R{Rbo*X{(l3Xv=K2FMj%b2yk>=ELvEKLwI)seT=YT%B)#
zTydLE!z*rIzCS2Dhnu((NNus|`(?;g@>f%i?9}6vKvV0OqEyw#ZJ(eCE^OoabN5ox
z^6jn0PlNEY{XygW`5bwq1fpZ-wN9R`_)DJeLK;7{S$X1irD=z$hb8*qocKByjA3No
z(Y`z0E^5u_&xS|W=T&pnsN=o@sh@fr(wM64Z;7@Z$dud%<hKn`nPfw1%cJ#B`^na!
zlR3zs=CRM;4bPw+M9W%wjOucqlY0&EG~T!u(l{(<)96;0hbnipo=TrTGJNcFsi<5l
zP0z&|G4e>CKY=thE8G9Z=rdYRCD*ftPdGmFbJ>Bz5Co@uNME-?8lPqV(X(7b376mk
z+biZ~yqu-uc-i?n+3Do?3Sqpx?PXl01w5AWlE!G~$>=ohko_dMKo-@5=o*e}ZVrBN
zn;V1-TcNwScY)<=Y)*3fc`ws0V{g*wWhP9&)V=g|(Xy^Rp9r}5kn&OmsqXBxX~t}D
z+3Q+&B!}-u_c%G!rz0Y3LcCwf*dqIi(WxI(rB6RST~W_H>2eV0U7`Px3fnj7BK};w
z1V1~+4EK2Y=RT`0u!+nB)V5s<Z5+tjoRuN}xz7Z@y~#c&>1lj>5$UKL)$V<f^rG#p
z<i3#(hxI0Vn6eA2yp6N|=2SxI%G=-I3%QBA13DU71U*H%B?pYI^5vZ9wjm*AZ^yk+
z8Fg0Mqc&Y5k1aEM9(B8uL*>;MLWER1W!7oKPif|i<hq(EH5@}dfhWd>KS7e5v46Gs
z(oq(gQBci%en8P@NH5D6i~Y=b^ZB4nD7MM11XO14fmUI^saK6IBFlth$IhO`3TLKk
zJq&FpZ2N0T;`_F&8r9Ay-~KuM$l-Y4US%GjvBFDW6+Al<cviD5zOgyOa%w$miP{=x
z`R`XooeTL}+co_#1#9bk^U{U$%oNJ3PYxxH9V^sClQe4|<BsrsH*uyk&z{IYUC-~v
z;D0*t&}nTpGb8BN#V3t_tGTCj$O-J%vd{Gfq1Q4DSKr(FAD$@yhDUK9&%dR%wc*xs
zB2li)Spt7X$n}g#s2_`T{x}(y?$l2z%{02xIjJ3e!Zgc}&*o_n3*Qs#nzL5!!XVA6
znp;|%TNaWYVi-A6!M#QE?CG1<e{Y!9yljh2O!@2#{Iy<b#5TI&j5*(4`Z6*V+C29R
zcr;~NTALbdtguaOIa+z>+NM6~?1Sdn)K3k02dGUw&*a&)sWtOhV7B8o?yGL9Y!h72
zH=w?}xr*K!c$oUpcCy|Zu+KcAb~<!~O-<do>ZhhEmB>*%%*c^fH)<NkS66cw@2qU5
zx^8}*KJ8#+ing&fHT}1CDqjAK%hisThKJ%sl`y=r$-H!Kyr~USd3U3gC+P(56+d4G
z`;Jr$yZ<4|uj3&6reWbp{fA9W|HHibHm1h$itBN2BCko+%~Ys(|CE%zZ_l@MlYa5}
zN#!(&>XmKQI}g3#;q^80Vk<$H@=4?|*&QuD)7U+%dd184qiee1)se_++N^6bOZmKN
zjo7><K7B{oJas9TWImaN^D<4U!@bRqFP~b+hi1#TWBG6D(FIB6qsI+18tRwYytpVa
z2yM)l&-QM3lqB<L40_cGdON9iy!=?JX0#ROgMh}-E1(gy3uTs<Z=dYmMDBGzZb$`f
zQwiasV`%l|rTEd5o4#CQ(8VVGuJet}PM&x<rY=m<Z&^#zsFA(06R+E14FqxV^h*-c
zpQ!;;oq0b>jUn-RQ_sAuta7|GwNtxvCL~+QCGskFeNl6-c=-Btpqu<`>V`*C<6>|2
zz2f8ZQh5o&<KlLo;$T3=1F`-?EP8MEJ}+Awk9fOOn8;&x18*d{QC#oJ#q%j0YxDAH
zfT30Den{`hl_l`u@%MOpH2n-si;T`>%L&fdzaK~0F-)eRy0L}<kR2y@{^gh2*!Q70
z@m~dsf11M;<GK|8rUk7U?o6#?i;C=TNdj}cg8HYif#qLi;%L61K3D@L|7{D6!KR{z
zGGyt*|3S;!jHl9E+pv88h*tzNFjV**gr7=ywGl77@JhRcYsXL9NKG0;K|9}StgpGs
zJa#o>KaCTj<C1+&7dJ4z(wuV!Xmr5=lRfAn&xYp^(7Qta!|6kE&w<BY=*NV+pASbX
zxXMXYCy?8y*zN_Be7>w&#@Pfn0xGL7LB>`%@G?=prmCfO^z{1JN}-u$GoON)_`ewx
z|B^A?^Pe&A7T)Q!{A-Dm-~w9>Z6&nT{C$268NS59)Ma6n(uwM3peE+HuTo|wfL{PL
z_i4YRd)ZWQiX%JTPhPwW%gy$ODjz;I<L5oCJcKn-Rh|RUNg=$aa{oJ)ml?mONzB@9
zL*qogzRufIOw6tAwh?ClakQ6m>e$c*WT)N+C_2ZZsHiRQ=ZUow+S_ha2dkV87Lu;)
zw;D9|ae1N+uH^Nnny3zBSKfs>uyt8F2<6k8Q#G2G<kg?S6K(AK=)6@1LX|<fq&xm~
z)q2%9PX={P&c$Uoj(LS{t(j(Z=C5<H>mjl0%~SKkm$~cXQ~io=n_}(_nL3@$8z;ZF
zgnlEu-xH-lI5Ue<xQL&YQcT>4UvXEzi%qYhxX)kZ)4Mp}+YtH%Jo<%x0grVYhD^~S
z^T;5*h@YAgBg?!noEgc8@8HmHln?j(q#!*rLRPr8&@Yhh>d-IHOW)8hkol>JL3)AA
zOG3XuFQMOvARohna3g|zMErt$?3v(sj0o}(@eA_t*)Uv?kBDE8kIFDykdKI8kdKqY
za6vxa6!;Af^6~hUUcTW$KH5XSARiIGARiIGARiIGARjk|=>_?CYv>o`<GJyHEI~d#
z82SbI2>mV!@^MuV?xG+c5x*cG1!1@#9}&MGA5Yk}0NcGN$VbF4$VbG_<U{Sx4%!B{
z_LSEKucqA_MBB5I3D6{)K5cqY(P<cX8k$j%S<=G0fAk&mYFhkSQc;n*(-w0-J7JOa
zj;&?U&PAFi$)NN^?B(=HneoWL3G|D|@EjF$`qf6?reDtz*0$-*lGzMClulXTU%kk;
zf9g+GlTIP&tmJ-cB%R72e3k8dxQ_M#`W=jqCvg*}b2Co>p9b%J3vyp;<jNZ#Gp3tR
zS~khZrG7BEkGB1w##hQubibnd=Oy^ry{wI`E!oy!@knKm<DS*=!m1_isbHpIL5uk4
zeld7ok@TrGz-d)Yw=$5n$6f^EqB97iu_ABpPSpVj`T7gjUnQUVC>!3cqx<p0=C|eZ
zAQ*k*JBrSkDV>DxM*FeW7N<jPCDT~vWJrB!<*Z~Kvbg9*r*=FcIl4NlN0pUdpK7_v
zhFa6d_Sr)5Y3rU({vsyPRc<<m+`B^mgQ1x!yzeJ>aA>}QseQlP{#HE<>UE#cFR0gB
zW}7$)7u4%}LcgG1PYwNodVO5z7u4(L%Y*cS_UTihU(i0y5B+2!<e^{D1%clsrp|4p
zjI!vj0G)MMeHq(G6TTI~rYII)-}@8|AZ$JKC}XwXM8d1AY#mj2TN|Tw%g@*MPaz=g
z<4inH0Y3oVs(QtsAHBxwm4-I{P!p4=%4rU5n0N7Vl3g$1e!Pv7UFYy$0IwMZx3a8k
z>%fX2Y_ttwyokT8b6QiL%y)CN#>(?Lgmi7u?Hr3!R^Qre<O|kT5zM!7QaWwil;*O!
z239tVzL%i8edwTwcDBmq+0@}m!rF8fHcwJZtFbP}wcu^i8v@$$sHt<!uZed${+3T&
z^Gr^6xwe((GFszx@xu0bKCAY8GL-M!`gYyNn;MI!`d&)>F7lW(`xGtXW|ln6=K6M*
z2jzK75GQO;WCLoG6=$uBbIV*?hZJYWLE`Ks&bdeOozk1bIJ=26-jriDXvdY-&>$^z
z<T`{T8?3pSfVeW~Xy_XKCcVxDy|=+y;&gRk+vNL^1CG~^up9Lw>QCmutE{$LUV)u&
zj4&t+f1CD5WhC9X=fQc;H>3+SNX|}!eqOrp^>FJ{o8VsTT=SgYg3>|zEy;4(7YOVt
z1B$77SV~^J3*{>`^2x^1-29&DGg|UqE>N7YoIRv_T`GK(5nJag>W6oE7eV%<LfZ#j
zM_S*uGMjo*$+gXQR~uBEE#&);v~|U|T6>ZnL%Xrh<Lv5&?OVh8v&b}TdN4LCV~!9q
z{G?~wPPEokyBm^kKfG4KOLe5#@lv^Ddyr3YHWQ}~y<Ssq<;!1>X|CpBdES_1rrTFO
zaT*EZ20>I8`X}q!{_!TYs|Vj#ei840)bNOINU<r~w2Lq3AO5~u9gghC_wjS5+nYzA
zQ`x}F^b2#bqixw_JMz<b#fsaIP09QZ)-%-J7UN~!Pqe3}1ZxA<zm~(!vgTYX#nf|U
zwGE~G?vsl8b2bz@nuENu+jNuFugWAx*egyFkI-gJ84|vn@MjQyk_(?dJ_^5$=i3=y
zzYaLPJWJYYW4;5K`qk2nUYfI2E!DN<tk9W_S<;PcE5SM4^eL)@$9|}eK!3978k-FJ
z3ch;l#^hc;Uv4!sY|8PmS$k`@^3_*WXUt<-$)-Bf)rIY!=d-cQhHAq;j^n3Ldf1lC
zXVQdOvxDUf@mY=Ty_0=8XLR7lWTi`OS!zsHy~O;^n;WG=zhDgYv&BKUU<|b?^b5vN
z(?dU*n;AnL7x-ObY*AUXZBB;ggMs*_ETkvfKFqg=uW>Egszv`Bh&Y7$^4KCPe}20i
z1P|)F?^6a}OCmUppJZFA^U`VA?IxXglPaACbCZLWo99t7lSFaLkx%6&6pvgtJb3Fc
z=(qNpnD$>-X4W=*neAF;^Q<ykcSleb7b{lGFBl8o8iotXaen9*l;c^UUr>$_zn~m{
zYx9DwTw=;KydGo9P65MmwY`Gs(R8<Oy=<1v<6E$4y0X-9;1YDyac6QlxCwOPn0AFt
zD*oTtx!Ro7+{u!5bnM!WU$gO>9~om76|KWRY3!=9cVmJc#;$#eCQ|lO$=kh@`SEx8
za<b1HT1kWVGG|sb+#1-WZ}SG1a})PpP!aSDq_xYocXg|eCg!6-g)#M=I9;8!9n}xz
zEk3r-AFt-`ozXp&W70TDbJq?dTe#1|=VgsLZrttY;0&+|d<S`HzdJE6llk~BgX;xl
zjU4Qyc*@IO{cx_o|H05zMyYptJ3+k%D;fLK&bcyUMZH3A;V;k^gVk1~(d%mDVY-!?
z`EFYt(#0I&C-qw$gkMGYk%Yf3626V_Tg`Zk{UqkCD%G{<eBbtG;@L?Wb4WuneafXF
zIZL=65AmL4W2??1wNZ>M_;_u^%Ms?x<yKb3Q=e1<>6^N!%0~-q$oEfvPQT$g0^^Dq
z%$xw81<IB-y(d}!Zc{^-xne2h=3SxxfhZ~i>9CgjaeI<~SXbr;a|!w9h-d3ixYtPj
zY5b)tt+Dt%*Xt|E_H?hE@HVadJxH?4(tDK8&@O#{I{11b;o|*v?t_VXxvG@|Wu~`k
zcZ9V`<*Ta;`)$83rrq&jx@!8EE5SbKzr*rz`v@4TOyyJYW(S~6e@xfJ@v-Uqv26Z3
z8J868v1z70&jOL`Ajqo>9LHlyBg4huU4$w8kjbl&Aw1=4?AWL@s(*tNxr+;BNptUZ
z((`*Z#oPCPs~m6bJM0Ik54`6@2GW+df1@^^DPhDHNN^!vwFU1btt7q!Zm?0MNA>L^
zphpRtvwXw%XJeejS8=+!kZ%b$AMS?lM#py%VZ`?~Xd+>^IljSrvr#1zMtn=bt}f(T
z#?31td}Rk|{IZbNECKX;Nznnz%h-Xghkw|Vb6^*~Y>IDG4Ew%>WR-n9PdR37_~1ma
zn2L<7y|IbsVm9IJakb;il9|y_38*pACd)TI?wXoe!t4I^ll7Xp;q6R{SW##76t(+7
zH`)7-0?OaRkoctA66^Rhv-!zAr0%{vQbC)SCOtQ<$=lE1+unVSKaV4f-H!vG7)Yd#
z82<Ttkg*2@psTvRuBFz$t=p4bSUF?^vWw_`Wcf))>Tfx}<95LGe}j>y6WYx6BrAhy
zyVG1hf?Vvco}O834(l=PhuY6N6Ruxs9rvYMpSLx0iG<Vghw8N2H|4GUqX)|y>+&vp
z-Pg4+ZzZG~&ztH=G;gx;Us=9ppLn$WF(3aVylmiD=yQ;4Aoa0C8<^ghSyG+J+WjQa
z`dCO5=S=xWb<uvay~DRhQ+@e)GFS<Z&Te>^Ze+&%=%e@^>Xf&)K1F@uvj$RLrmiyb
zn{kJ@w?H~`VIe5lM83YQU!V}YuSX-y^xWWe$XE99L><g<FLnoWoz;nbf7<B5&qEHZ
zwetAuHL>fyvFo)D<%jR@t~F;_|A4utx##eUkyn1dXb=6=mdo!4pAP)YL&CV9+Hv{4
zFA{Eag5RhFKhHNBcVt31FH1C>CQxy{8Yjj5io5z1>tSasoY|Tuzu{p%ihVw+KNaYp
z*voQu#LvqT_4Bg)^nM@r5_uWE+e1HzXZ%hM{KiP7#_u^cX<_D+(HMym_mfKFeo|@N
zPb!W3DI0M=Wh3qv$Q+R+kU8`l9Xvmd_$B0HbV5ExC*)&vLOw<(<YRO~K1L_xV{}43
zMhE%$aG>W=K|W3k{epb_m<1kN9;1SMMErt$+!uxm@)7Y1@)7Y1@)7Y1@)7Y1@)7Y1
z@)7!l`%dZtSuPIpaZ>0P<l}{Vecmn(@)7Y1@)7Y1@)7Y1@)7Y1@)7Y1@)7Y1@)7!l
z`&}Y_K|UgW3HcbAkPo~2T=hH>Hz6M*6Y^o-wu!|}$j8Wpe1!X5LcZaCmxy0NKEnMj
zk#Gs+F(M%!BNFm4A}EjNf-)Zw<m2AZFUUve7w&h7_yy$=@eA@1@e9f$;uqv2;uqv2
z;uqxOO`q^~dQp&G#4kwi=eFMs)>bu#-AEs+Ofm1B(p;Wdn5}2!f@?i1-K2ZW+ZmtD
zpP8wu@wfd3*k;o<+GkZQCJi3TvN=`h4&~a8QT^+IcKuCr?Xuur%fhVnHse8!>1;ar
z&tldx_82#x_s3{xT)r5$*gY3+F7E^nCDT}R9qHLUua=9(CR*cAdRfw|<GyRt4F689
z{d_)pK8=sFmN*j$<Jv|OXYWDc>>$n(!n|#bDI*gnO+I?!Gk|f^aKfyP#946=J|)DF
zY|q+0*zi%q+!LP`;v7pDH=Z$ZRv(1VI^t|4j2jo3IECHtk-q(UTyZUtaBR&o<Kas|
zjfaaLHhPKAz05isTTC16<jBrPq(|=x{g0F%r`kEG&2PAOHaZ^N>|{_yJONUre;+bz
zd!$Dh%nn)28HR>DBfso;RQ9GyZ`Y!#7b$>jy(I86d!Ni2dsHuTWrR3YaLIJx|Hs~a
z$461^@&BJtgA_wiIxY~APUu}jM{4L*NgzQ=0)d1MvLGN;LKBoCRk{X21O!|VrHC33
z0TCo9U8E=|2<Y$io|)YpLg4zl_j`Z8?;m#_e0c6oX6BqZbLPyMvb%)x<XZc$@>FLa
z&&Qhm_y0z|8uuk547zToe0i_m#Xcfm1AE6r3>@aW6l|R@vyHt&%I)Rtuh-gO?HAtn
zLH2tcQ&uOMf1|zfKR-CkKhD>lw(yUuqVzQHi1&T-R`iZ*=pW~6?|**JH=VD&@9G=p
ze=g|Gdhc}Qed&7q<9z8(^N%yzUDbi1ltXIQC{<sq`s#dkh5Lfki6F|q9e<BsXQpe`
zB~@Q*djE5D-ZoA1)Mp-@`rGSd&g0*oADqWo2ZN%SiQzK$Kk{HQj#VApXr}$pz8OET
zbyQFPrnb%@AG57h2Gvq21MM@RjJJ;+ao%Tanz0^P$kR;n(ZtFF+tj&#^V}i%)H*1<
z=bO<w31z6jajPH}$C0c@(3Z!nhy9$1_V0=2+}3|7>#Npb6@T*X-}Y=~87KP2`}c9>
zcMIcFKCje~arUz>@dNGat~$QtVtvz*|2O&jn^u0!WjE%%waxw4vAx?|^HgJ=K1@?~
zYijkRcfWr2bNbGCdNI#@=2>XZ<88aFbo3>{58oTg(~lV#Y7(j=s_-h?q;08|Efpkc
zAgyqex19b@wx7zc%Eei>T0ifxrgVS)$S{`euWLj@(Y*fl@gwq@;zMQ1>ppV{)_)Jz
zg|yiVP#(oeCnL)qZY|f`UM^-CMDQ$v@7}$(?>MFpW_m6+7#@3i@3Ws)x%2FT_p@z$
z5H^lwXueI%=VHF6n6L15Ya4s}S5`Xxc(Av%FD;dWGrapoqFpB4Sgy)MmqN|wn07v*
zOdKDoe)P7pj=joHHI|p!eG=uxd)?PPfQcAdXSDJlwOx`@&jX(&^M5wwBIWEIQf?3L
zvE$}vR{40}AGhD@c(84^`8OR)%ywDhn)t`*@M|77Htq6F=Q~C?#`%sBJ^a&!c<1ft
z@y=`Y!&NRW{-_D)U$@|cJ9YISl^zgL9WKszyFE8o)!g1}ry$B{27j~DHT%=azG?e$
zIhuz}dPJE$XO*vazLCr~mU?2Zt2tk&Z@#FZ`uf`5@m8^Fo?J{nl=zluzO~B2tiy@E
zdCcdPeCc@WmA6hA1DTNF7HO(Z{fye4dPt6!DUTaw!jX1=Uv*0NOua*p_eHAxxd-#%
z-Or=#^d~WICSn|+^xX$iPv86wW#83Lt52zVo67Lewbqk%S~{*MEwzD4E98sR)8a`i
zJ~{9Bq6MaZ^nPUZAyvNK&jF891HhnU)&J6=Egk8FTj}}l-&xO-o6A<4`0(KGpN8>A
z=e;}C!H$fxo?ExRqd?=redDa(L)3Ndy;i!$dhV?_^BJxKF~bHz`CLZ?lF#dp$!F?i
z?$2i^%Sf3|ty{``YJHS^%K)CMN7d<xlv^`KmgRkigXXp|>$LVYYyN>zF%iA{=|iAe
z58Z31X-@a>^Y7`@z%n!>v~G0>H|w8dEjP9Mm-g29*V|g<9K!OP_b)Y0Ws`C}Lw)0{
z?V)`8?(^Dt)W_bQBx(~=pQ2uVX|DSN_c^_pQ$1v|R0jVx2;{HMdz{LfW=fg2Jic-M
zym{OE(7{#`x@DvC>p&!uH@B6y6!${CxqIAx>Cay%%W~ceRsJ4TN31;i^XDzQTtiq0
z!+t{f+e0)Vf5um4*~L2VnR;`lvg^ep4-fvl#q!6L_e)hjQ<k0EH_pnN`j{@?IDb9W
z{@20Elez!t{fCbC&iasOuahp?YMm+($EmZ%*Va0vRw4dXyX38_&iktWZ|bVIy$)9)
zFtn!K&w<Tx3T;K0mA8kE7v}fpHSpcyG~2k;%ib{CYvoBvJjXV4K4;}-oYhV|_&vqN
z8Sm?RrSg5m!NZt<flD4{d*2<;=I6gdW?6FQ)T$MYqoTQW_0Q{V%6g!BYh9<Z>VeiH
z%r`F1_xqw98E37B^|>BzeX+*%h@ex@TfdvD`rtiAPqo+K8|Kw<>np-MMq2BTdYRiF
zSXRAI-clKS$475EH|=z0GO^N`Mkt+x!)94Ml#cnuNshjNw#CDPwNGh%y!U^Hj<BYx
z!MUOO9Qw{9r4#l|s_CS>Wa<0N{uW1KYS-++SC2v&Vbu-)XZ8y-E`-oCLiFy<<IQc>
zJDxnfPyckSl?StLr|InZeV@TE;+tQe;pWpPF%iCFleG=~pYPYXK~dlIy&?ujh0$|t
zFf=y8{A7ul_SE6DDWpA>{iyU2bN$Wb`Rk7Vv;I0Z1~P3lv5Dn&v!{Qsj~dsvcdYjs
zs{j02<?pOh=|-^t2AyZC>`J1Z84o}9*ll2LZPlq&<TsVUEPJgtr@!8Ewk|t6e)L9v
zPiE%dY18cQeC@0Sn;Vw#-gA*B%r+pl4F$&vS${3UysFQRzd7oMe;Qqra4i3!X_SWQ
ztF?XO?Q73gW!80b7k|_Cr=C3OvbmX0H`6%M@#RzN7|P!q`Fvm<wJp5Qu%6UH7|I25
zo@lH6!FA&C+oHeujamL}t?d%XcJvO~uJ+)2-tji&qURmG=U2DSSar_(eyaUm=T^n6
z*PL%vuAt>;-0@^{dW|dZ9k<gzPDN%;x7;_*f3It@e_S>1bg}+%zH4&r{o|^5r>o^3
zSJ^wRh<{uq@3;W}xQeNa^R35<)86&)-`5)B8|S~Twe_TTI{*D8$2eaZIL7(Pz(3A^
zf9Y-C^8D9Br+x2D!~c0@$2ebEImY?Q$}!GYR*rGLvWoMk;VY}nR{dgImiMj40{=L3
zJ-ls8EQQIlat}Qh8%R5Hb2R4*)GIq(v+Y!-t$iytUgtfk?`HeO^z+<&mX~^JmybEU
zG8JR)@A0v{d9CB(MV8saY$N>7%4+-;{%$RsXI89F>6y!z=o@d{!%}*;$=hr<zs17e
z(w{QR*_>8wNXq+4&OGj8o(@c7*AsJ|+q}2i3-f-0rdL0%l)YU2u8GEZk8{RYW?<;g
zy1K9(YQGLYYvv>6@zmQ!>2jNIr`A55hjQ=^LEaaRXP6ECu6<hTo9s4>D`V)BF)r;n
zYkgH_Va%7Z%rt#RroBk~!QYEJroYbnhs&OGGp0RDoaXPL_VnuOs4cb1)9UM}9K4}2
z>SIsqEhF#wMWkIu%AfiiO$n7z?1j|J$ou7jDwkeN`|#lJZ+QDP2Op6}@}tsle4&%l
z(YmEFJk)=>H^G`pzmv;lF++y4E@4#UfQPT8Xgm9Q#!6>ZDv3~Y%yhi%v-_sCO}+1P
zrFehww+H_|JH`8s_ItJED}FVnW&f|{YZqtu$NAcXQT}lu%A)4&;~VFHMy9=goUhHQ
z=O5>5v&P@>rt5!3=EQa1IA5C;;veU0vrhctovw;6&yI1vJUhnu^6Veye~!d4&X;G$
zIA5Me`O@_t3%mKp`O>ZC8|Odn<@As9rE&X;cReck(irI<=UZRLIN$NiG0s;85&n67
zd2x*Mm4Sbp{}|^O=gZ&kKYR1%e@^4Hf1Ga{?emZG<#~gDoG;IB`^Wk6{F;B9nP>00
z&>-rVb*%A!<~@mhxGVctU)s<O*8XI+$=WyL&FOoX->s@PN9~%X-^cV_({cW6rNg<W
z^%)2ihCa*K-u^b!w)#M6gQ4bp;mos#n8^-n*8?-1j;W;MOzSrDJjr>?$JfkqGv`_G
zh<Uu{(xDTXfZ;M}<w6b%=J#88{xFx3^7x=HXET37%=-yowHdMI60H9MeXp%HL+!Gg
zaVfv&Ldja^uMdCEMFM}b%JbpxxzP3r<?q&UWKciz;u-HBJia{m`Ay?>&TB~U2-EGO
z^T{guwwslQSoN>XWoWzD<2nrFEBAS89z%3}Z>c%&!`Jsbb{S@2!8(3qL>)gu{(M9k
z@{xY$cX<s}A`cH{o2&II&fl!{eeih%?=~zw$(nf$WG0poO5c4q)%4rf(>F8tzS-Bh
z-k`eW9fG_s>~>#u%zLa%veWvMX|%38iO!@IelPX3BBJ@C0S46*bH~=32M2RKy~l5z
ztF{dAfBq<h^bQiL$D^z?=<nFqx6Em+-?~&Dy~o<<$yNeSv7d7IGqR%D=ehsrJUX|>
zJZtup|37wnc>AcTKYT9kk>9O$#m?JvOsDG(MF@SKNwth>lX8D+-@UDVgwDGA`RIOt
zwXdnJsEkuSBj7BXiBpu8wcWIxKO&TV$RpC{SMc~9+*mUMO23z8wuhAUMCof+NSVI3
zY^*vw*j}V{p6kq8@KkHT3)o&cc{vl6H&;OFWz#c7*#v6GwujX6R-C{8i@Xgr7ine9
z-0!{h-t~sH;0d(lC3qQ)t;t(#x>WOKo@Z+gmD#*h^X32ipPRp{@2u+zTX=2Np`Ptx
zBYB3dUPO;xR%07yEsy8v{L|FoOO}T;h>49KX6IRD9n6GQ`#D@=`7E5i>Cw8cQJgZ)
z!n$1KIC0a;yV({hO>6s@^O(n>n@k(Xw12T3=B78-)4bl`Vp=PYz2h21@nk^n9%lVe
z+F|^y4&~A^;1$PTth8NR%uC1eYLWk+Gg!-0opCddmA3y}O2^MwUHoJELy(gj<jiKa
z(XqTp?Yv+y)88XDGhJDGdbKN!dH<;M0@Xi-&JQ};^LWn>yys8}<Uxbl5)Eo&!&NVz
zczE0E3Y+&N%J<8XY&q2fbLNNs^Pekt@7b9@PR4XP9;YX?FWi2LGPlyR@7eW^v!2}g
z*UMHJ1hNe0y)dn__x?rvbpFVYGQF@A>2ameo8-S-pGT$XUB|O_nx#os#}T!MTF2NF
zX_|GLzp4E4;KPHzpW)(<k6Oo$3D%sYK<O1Du5ezTXr<@;JrBO-XHaxBfB&axI)86X
z<?3C>eRi5D%k_GSb!^eUZ3B|~kIS^$3@zp1?HH8Vtf#(uV}A|Nf1KW`N2C{$GClJ_
zuYZ62yuXW<Yo@h+^+DV41wwTuEJb?yQ3P!}9Sa{G{PiW2KR&9yOngLIi4UdK*6d0t
zo&Pk=dv=;B>q}6U2e+TU1NZNjske?s&r;5<`+F+Wa)jB|q)byk^TFT#={}LNT)pXC
zvD0hFvXovOJ3aRU>2Y7m`dYhxt4!6Fe{3z!Sj|4JebRdzkDN_{4A}^^tyzhYOq1+L
z-}zZ$Z%(w{Oq$BzuTN@Yo%i9LZNU*cT^&1=?i0i$>aIGcI-K#_Db~+W+X?>D^qlwB
zoo#yKIV_u@2BC7UOsplnAS*rRJ#+6W{^PQC-Y<8q<8eDp^#PUUYeZer47bzt-3NE9
zqmIoF5B@R@<B!gJ;M%rtTFW!Ht=@m;c<(HOW^Y<cc5dq<Z0n$GW|=!aAM7gvvkV^2
zkH+}(r0wjyhpjZd_3OBurs_3aL?e_KMw%g3nr0j9tY0w^eWRG<AE)d6y{d?Kox^6y
zel9=9Fb<w+jDB2uu)gQodtTUeu9j?_+p7$csc1S6O0e?sz_~_j#6a^GZ1nTs&U5=!
z<`S&`96NyTT*$?rtiGH7oLlALJr_G}=RwDA)d}@ww7(hI{cW1FJO)M#>E_)U+6Rg=
z>BED6TZHh(l>3~wU(;-!HK#Le?Q<?GZT~*!Nc5kknR37LZvQ=Yn$G=P`(3D&rgOh@
zr25adf69H&yROyVvewmE*R}73+3EWBJx8klw2g7@f6ls|Xs78cU+rJ9cABXcFxmX4
zWt?&!^R8>~+t#|O8mTSKOWb2!6RdRYehxou_@b|i{Ezpq{Vd1%eGJ|-=RG3L#D~-L
zb(8;T`KC<Md#ntcpZa<xJ)EZ5h5UEZ^RDB_N2GWC;q<&+$bY+Bz3X_zPE-4_+6VQ|
zwJn2k_}hmXHOy^k{?^q$tve~p)VqI1>OvAj%DNNwaC**e)_=U7N9=T;A#K&!Ldpbf
zacs(T`S1b{z5mDQ)nBLt9y}MgOSvw7FunMQ_(5@+?w{73l>NF2_V*5^Tco8}->0B9
zz7g>=$0m=J-k^Sw-D09*dc^XWi<y?%j8q2SwLlktw64QO@`Q~4daZpPKd^^APW5IG
z!807@moe(PL1V2u`KbioSn1Q>%buOL_O!jtKB3w&Z~n*G`LE41s)yBxU&y~Jr&$k`
ze{L#TX{fCJN&cPJ9CSX+A|J@BGyOd8=&u~hh$jh^(+$#(eIWgQJz`=Xx2+6c`Kga$
zrEfiBr1XP)<D&Vp9;-~X9#;AF=s$?Btg`YHWac$+F@I!eO=!C2#4Yj^l*=rWZr%Ks
z-_32>n7^kon0fME8%ph(zw*|R8Lj;G)7PZ1JnQ*kZF}>%T<a0JX5JG6T{r5*-%|Ts
zMT+Qw-&IuFLm5}tTo#ufbxBoU<x9<XuJ6btOu(?6U^UI>oBrU1JH`5Po5oz<i<<bM
zA=F%7eaCWfE<n@e;@+n9{eah*_EGD9o4=)8f6e^3_1E>z)Yd<U@y_3s)cWUPoUUu}
z8Qexu@xCil*7ZF8R)qBR{Tt4*(Kc}T^32A5@YaucjWEk%p8a29eRgQ4RZiwILzr(q
z?OV$L|9p({?RPcob|Y!2##;3&1DX{N6Rqzn_0_QkLxcI!a=w(5LHnOeFYG~e-5P?%
zR^WxoewQ^rWna~Nzt#7?ikUy}wrCOX;Qc4nMenv~5#X<j-fhuB&xof|7ron}MT+0}
z^ll5ro4@ht+!l;`<hE$>m~GL*QKpghbzjwE?=jW0%qoq3kca3^{HeCYs*l|U$HnrC
z((ygJ#hE{|`j~y!>St?T3u74zY1mr^bn|_=kJhCl<E`(Ux5w8rn-TLmZ8(1m%wf*c
zu>ZgqowAtYwcp+*KP;=6er#PQKuRMPt^K2$?-@3Y*G7MViox`)y+07@+;3+uX99*!
zgx0q$@t1bsr_KG(x3-M=|9oAmk>;b;$=bIcTqkc|%(Ftd<-4*8t%|x2849p0Yn|+t
z*Sz|!n*{vqz~kB^>$srp<*oNEA5-tSf8}d~z4iW4ZLqiAr~GYOZ@p*y1NA<&c1GLS
z#rj$0q~9*EDz);fZU3lt<R*Xfa3AA17jc3DZeOakEmO?&I(5GNBdlfA%w7D(G7U;l
zz?$w`-=27NWv8ZPCbexHQ>~6+>|matfbWO@lp*H+`?EueUK;r9tLKjy#+jlTpQBvv
z1|7B*&lcaW?7<orOIG1tkGcFAFV!y8yne$?TV{Ox)U`qH_UEDvD-#q@Xl~@EV{Wz@
zcfVGnHS6Eae205h={3H^jKWh3eUkou&GzZ8_F5lWlFX*j_{B>G+_?X<>v+{N*G6`4
zxOyG;#<{T&6!3Y(u9?rAiMSTgap!1HhE1f~l#{ujfFZBe-x&E@T(b^8HkusSY;GH#
zd*b3zP{5J99S)UB{xjf4WN^j~M_0ArKx2--Fs%38QwLhE_`J@x;ZOazd<4&)aWWbd
zaBIMv{4a%^{At$p(g!bn=DN&h!^&%Xov4DDrc^jw;>4aV4QluKpgo`0;CK)e@JU$J
zn)P0K;(nUSr=Cy0XXy~b_>k)iK>;VeP8e|_tjXQXk+*6DmpXBtebZd81>>SBEj&Lq
zPvpeJ$t`bOZ^gDT#~&D#;gt+a=3VaeR^qrdiC@uRoM)p31>_p`TSCTOKlYng<$m6v
zMcH{KuaKFakX+5qeYdskwwiCPzntT%B=zIWbVn`vZbwj^_?&O-@1FIgKl^g*&S93%
ziB4bdDsueuQ1{V>ThqSV_6^Fx+>Q-f^vL&9$D5@y#TG~&UHSGWY%g>CJ43Tgt5Bn5
z#Vw!bY4hp+M(k5@=JGSo&3Ad<pjR(msWd!ox{)=T(B7HTr|Vku(|48^4STC*$<^(b
z{V{-c#?0ryf=x5jFEHn$mv7&%aIEw7;)X#Itk>ONTCH!>=}!L1wT_2(j;cwgDao8Z
z?5)zT?<@9RiNzf{yk9+6@+tb69IS!@y8QZc;Hm-NZ645mPWzWSo!rPVp9@Dp0lSvm
z-ShmY2G=h)IamGE*LU;snLKm(Hx4XZxaUgGLG_->`NH;d5o}*qu%=Hww&Jx`{bp9E
z`eczG`_1Y2H{Tg(*4xro*SAe7-ttV{ZsnqC)jh}s-u344?{wI<=8roA&uvMXTD;w+
zIg?l~b2+_>ElBQB>tdHb&K~JIHQ&6!h7p-j%in!{z@nh(7h5#noNdRY^Pj)RxdaE^
zpn!H0(pBlvCFVw_xmilbtUbZ_S>|#+`RQm-_HH{~_@h9J6|cW|=mnlFDWd5QkN9T)
z-?ygU95&^d+#9EMVITdK_0n-9=^OL+oXy`U_wZiF^=5>Ii2;T?Cr-j=kgvsb>s)af
zR>bMZuC1@8b2r9W*cJIo6StPHb~x;awfuIx_7D_<QJT=eZ$-G-OvdX-Rt<g+!rc_#
zLT~;&_WV5=?;-wA<}aM(g??-0Pffpv(0NE(LW4JdQ^`*U-cQ3Qd;_VHMgr=bVJ1$)
zSvVcv#QEr4kD#Ofy>bpGtpt1d|IPJqkxn>mHcgfJxw<@Qt=GADuVFjgc5OEo;jyRF
zvBbp;n#Vic*<AkVjN{hdYVh}z%WGsWPxUm+o^Cy_J%qC!{F26S(<~WR@oD7y@ZEhe
z9kMGK>5(SN$bbnLh^sIYdh1!pcUC_BTgwkR@!wtk_5bqnlfM7&<=@S=NIYpRKb(r<
z;XTc$c^(GFpKK@9o%^WvCxHE{7N*0gm;vWvMtmOwaT8|7f-Em97RPKDiaD?@=EBbS
zG^!rBiP#_h@5o0;^8f$&(7t>9jFpefydKK_&Od`gjX5k!Z@B4p8OxDwkg)<)j+)Q-
z(LW!L@I5eJaz<;uGpPA~MDKh-|HgbSmJw#pSAy3m+mU*Xb}7N0u3#$Dt#M4}v8T(;
zbT0DGKVSPr+i&JKiE+vHbe}PShxeL(521mt+%u1#3sA?;g{b=bF6wy5*C)BV<67*4
ziKzO^^GNQmk+1l0v)dWl@i*kF7TmYdgZGg%-PuW(kCVEU$0TfrhcO1f!C`n5M<5^Z
za&s&<j^h&Kqakj6r^PA!82K2Cxn4S!yUtnb++OJs83^rj8b&gm+S^f>4`0P%=tdpS
z$D;ZW<51hR8j)ZxPj$mXIQs#SOs9Gfg<4)uEQ$OikU4)SuaoTgpXarQP`#@}XkZ_9
ztG(!gblHrq_$-E_rino1Bb;!Zx7I6}*B-)oyzj$wTCcvSd{BnwdiBRR-pArb9Ecy{
zAUuHlgoK;JuR&S+(h0p_rQ<!GIMd0`aZ33ufXZ(n?26A|FD#7xu_(InS)78!a2fL5
zIKFaqU9{3E%6JdqEZ4T=N99DFaA(K%sCwVQ&gVQ{huQP%Ia&|zg9x>$8t&NB-$lCX
z#(h-3?=Mt;Ee-kL7;W%Ko4LJtT+Q8<_dL?&?u2|M&D|5ZRcs!2xdrN8&if!-hg>E$
z%aKc1W;y1@Ta4$oYR&aiSuDO}t)KP>521RZveNLQoj;zRHuHDh&L1D|F!RUb-)8=J
zG~4X2UB~gv$43*){u&>laBt!L@2L9WA`&lK>1q3W2#UqG-#4}Qd)472dph+uJVaU|
zn9%SH#}k#i3ss)M=xyJw+w*C=yI8n$zDo9dl`$uOuVT*^%j=+@t-P$X=gW+dgoa)m
z7pq`ztc!gx45Kj|V=x-~;b82KV=)#d;Q*Y4192h7qw-svNVd~edTPhhU;#oy=iJtM
zc17R%+0)nN?;gUrelJsg#TfSzsvgny`Q{6~Vy)kB#(N0oe9I^Y)xYJavRGx8ODM0C
z?fF=?IiJei+b(Ql`K5XP5!OJqwRxVh6;)4nqBq~+zxcOx%I#8>^t9Y+sO?hSPG9Ys
z+n!H#(nC1+zw`WA(_g^Wcnv$?byT{I3FE4jZc|=*hzvw6Lc`l^2en7@QT37ERy50R
z5!T`TQf!FJP|FJ?!tLdS@Y+K-%VPu6Y5(~EwY-g35<kRp$Zt>k^0nArj<>ya=IdRi
zQ~R|NRgYKUv$zIT_Uo`ZzK6<}w%K)idAoV-Ayl8d^>-W7X+1wi<!d_@!<|?bJ;*7y
zu^T7gr??0|!^OB4wI6?hJMc^NrAwh}AD&Kl2xq!UOsDlYgj$bpP-Xuu*280{dh#81
z!xK0JzsF(t1CGa^a5A1lr5i>hvXPbU6v9JfB<d3yob{+M?`u$>R9-bv^VUMOeb1xT
zHx#wp5F-4BwcICpt$vPkKhg16+grzDmFH-?T{G*cJ>Lv_K4(4EaZksmXnY;};Z)Rd
z&zo*2FSI@l2oK>*w<*)9o;Sl#Z0?wEu|1#G-9tF%tH*RX7*`*4JZa#V&-l$suO8z)
zgmb<|_I!;|_47r0zEEC=+w(QywTDo7c-w=IIj$(5+p!4l#PaAtt=BHp`i5%UW0vz3
z(`h+hqn2|BwVZEI%lQ_)%W>Vb)+4q2>|r`B=QGrD_M(<^0JWSi(7PP>W0rHA>9m~h
zP|NuqwVYF^<(x+Ea+2-kyvTSDk)H6D&yP%}<@|(N&N)<_yMWq$mr%>mxKIw%st=)r
zix<xAvy%2r^>Y<!yRNp|yN<k0u;)9-YY!1fG$S;)*nc!%Vbp$66qVMqsO?+~TVe^^
zh2`*b<a;E{d@bg6!tYkTHuKs;WG7}58Y(iK_KQmB!YZitr5b9#uYs+xCbq@ru?L1?
z6xP8wtcPQ;0ZznbsQtes&cjytHnzoe*cmrqS5*0_9Nd3c`CPzj58*6_EKH|%DJ$kj
zK40bz#_U)DbD;K%r*J0b$GKP#wftU0*llb1Cwc85o*=ps8oDu^${`#}V|T29J+K8v
zVqffu+wc|Kj_O|=M)fC-q52Wt^kVN=>BTbMLpak@ze4L1hgzROSQUq$>L=%wW<PBh
zDt$MG;cM6vC!+E*8I_*?X8if!c6PR}&(U6L{fc8*EQv$0EV{8AYP(cKZ5Q>owA@hQ
zy1iVb>mi)`$28K{aucu=&Onvv9E`xZsO6~6#@@B^r}ay@f2?N}pJM!bsCxZAde<w-
zp0Bk%pL4xNFrD^~kyrpnVM%-yRi2|!`>C6Mt&lqETW;t*D?cp5%#U-quQQ$6f9kTC
zuSr;u_Z+*-{?asz=lyh4|1kl*>zQmXSL@>;obA9-rc1}TA21i5w&x4wwQ=9d&s1Kj
ze4OR{4c7;?p2sl{eus7NdmN9aQ0WJ;@I-q#_k*qFPzJg#WDf5<VYO$Au^?lXU^QHd
zTHZ2jhpVs~u0}VmLG90LaU-t79k?D@2V)1`O2c_RreTFY!(8||*2R6uzHWSpFOZk7
zaS<NEwfGHg!f&xOD}Eef@B|LWlQ;)|z`J+`jSRHMm=(`sKD>a>;YF;3m#_|A!Qb#I
zj%Pz($EA1!Kfzz|B>sk6gE4Mm91YO#n1FY1J<?fnKgo_9fO#+tR>gGK7Bk>W_yqRE
z%(xu0;!ezq9?XxdoAC_(j4otZMqw<DMX?6*+T9RKU>hurFJW1nf+48;YUObwR=^Lj
zGCrAw_8co=Z9I=Jpc<Y~oXCz_2MbZL>f&2iA5S1@x+@0Jeq#e{g{`qYF2c^pgTF=>
z%z@o7KZavf?2fH43j1PjjK@BhfYG=HV{s1-#^X2?FXJ%0hodln1F#!&;&=?f3D_22
z#{oDI=insVhLf>BI~Zl;o{Cd35vSpHcFZ?0&C~3^m@PN^FSf-Q7|sqh6PMvE^x#}P
zjf=5CKCbIwPka}9;Tn7$H(=KMoJU|jWLvoP%)@33qk-CjX9{s03#&fEy*jLq9&GNS
zzlE!CH*PFUzaF#E@z{eoi?Ux~Z#;;uVD={*jEC_xJc8fhG5ig`!(XYk)rjk*0t}iJ
z^IntMmvr`PFm!xSdshNoSQ4MZQmFYgE~K<Ie<{6Ze*XEc19<HAN7KdH)0IeNx-E|B
z5+5_&M~>;PKPKG+j_E?mJUV{|9n;0y)1{Wb&5r33A2Z!1$8^^plkRTEbRlJ}{IMH8
zRDOFM(}g}}x-abM!dOO_Jsrm)!$Z()8TAPbeD}54zu>o}&HF#UAl29S6{GMb#^NpH
z7-#&B-tBCZdvrN|=*;J1ru*74o!g$SB<ZBAH=j7B^E_sGyByOQA&)M{eU9mZ?CDb5
z&KvFNdXc9vd%Ab*{Lviy`h~p$t^J}m(mWV_unhJ^ou5XdwnYqf!&p?g4!{Y>F~scm
z#-qyjBH=1;<^L^qAe9HrhH;Y6Q0z%7z2{K<^x{bKVU)r)SPna52u5NBRC-l$ELO)^
z_&hGbQ2YSv<G0ulPvDDq9$O&Y1)~i<OJ3Sy73_$ddm3G^4R*!u7><$H1LH6Xx#ny1
z!r>T=v#}p)eO0$y6|ME{#PMJ2tN!9hLc{%RR{!xYtjPNS=F7u0>FnhN;yB)C#WyuC
z?#AqR26N$M`W?A3H_Ok5oYNQuurhLNb8`-26hY-@C=piG%Fh;FD?i#FqX`YKvz^oq
zPDE|*Nf?5Yu?9}ThBy^p!fDtW-#{&U22R46sQNSqH{zS9^p$34H7osGq^<PT4_rrR
zsLFIozZxq2>ZtT<qWZ73uszns2z&wiU>#IHv_7gmXow525o-H4#!s;c9>!+)6E??l
z7>1Xz6<)(Oco*B@ljN~ID*wlc#nr9+e?++||9Kd9kkBwar`5kqz-M_s6U*Xktc)C^
z-L-Kps;!!bTKD<58F{wPy%*m>J=3)mYvVF}9akdvj*L~f9#`X0T#F&pgZHs6CSpt6
zfCF$74#p303T{TuS&c2Y9_cgq>TB5Z*80V;T&<t8zShiY)z?~BlYG{}=2#D>U>JUi
zt?)DKji<2>p1}dA{Vg8<#=)44G=?MBY>Zd22hw<(`Qbd=aD`g=c`K`xAMN+08L#1c
z>UB;$i7M|OQ29BHtuYzZUYtSAcOK{C&!{%%3MyaMu?Xqjz~}H5_QKy$<?tuIhj(!!
zrVBFk^-D&2<erETh&3qJtT+O*p&N7IRD23&U~c5u1S22nd?7#ni3O2s3`QXg#lkoS
zi{J!&7P+Qr6vKm90<)&0pMu=GHp*ZdEQ=knJo2oGQ2}+HQ3+3DWju>j@!9n3XIK(z
zU|+0>u~-{7;Pbc{>);<)7w=(xtet`D9at9|;cM6!Ct`Da3tQqwY=yh94JKoIJcpgI
z1qbe~*bQI8e)uxRVgzo$NZgFC;2+ov?_ghiB9P+`24jD$fU(HFYz)D!I0EP67`%aF
z@pl}L&1i5YU@M%6qcH)$#kcT0zKu_CV5INwE`f`&EH1-pxE!0{yVwp_VK-cjakw7G
z;QP26Hz4P5#%AOk%h-YGIdAy{b-uF;Ip;8TBYkn>Q`C9R9()Hs!(=>w0a@q=V_N(g
zpT$F{_Ubm_YGv&|`>3ZbqJZi>q2U7k9_>FDu^_77R0^+P1-ypZ&u?H|RDY=r{(<56
zC%%Gu4r2iRg>DR>-@F>rVj}8!j6IkUlQ0t=!z`%wLC;}a#UQ+edLH8sd<qMaXFZRh
z<8vOQJ8TrdhFB1LV<Fs$MetKBidugc5zYaeQRZ(nYyI_F#~ckm*zKN<xe4}k+*2{j
z$;IEZXkvzov`1<OFQE&6#wPeHw!@nki9FtJ{VW2<^F_Q*i-#~B9>t89iDd?&+P%zJ
z2eY8o=SdufLC7_GBPV`@xsZGQMsB=?dGJrnj}>V@3Sc#S2G!oXFb<32It<45@Hyn#
ztx*NjvYyp2J=Q?3u^P3oC_az1F%(sf+|Myw9j$VlL;Z4*_CUs~tTeos!>T_`uq5xB
zVmWM%b+9F>9p;?at-eni)N#5UzK@;oN9=;Cn_cmDd>Q}3ZkU!d!%@e@9@rRrqWWdM
zFcy1bGIGxC&dYknAotRZ{#XhJV09dbtC4eZH`ln0!KiW>iZ^jM>N?H{<XWXM3fJOj
z)bVl*>iGW}9>wv<Js@KOp2CU9zGX~C>b^cx;?9iIFe`Emz)jsYW}^$=#PT=~o8a51
z@3vWhqi_+vgG=!+F2_^&F8+)w@gA<jjI_`1VF)H-UHkxh<0c$}AL57j5q^qWFo5=W
zI|iW#bv<bpR>#k<5$?r>xF6Tz0lb6<F)Quym-r-pg$3~#R>hOp08e3i`~gSeX`GMe
za5-MUEqE7q<2}^%sK2lv?R6UV*Jm&-mcn${00WUeoRJCN#mu+?vtUNr?`#-^PhwBZ
zj{PwQeuhuuH<%kQVt!P6UjXxCK`e*QpxXDssOwopQP;DAk!yLzvv>=O<KI{k18JvA
zV-75j<*_1G#LCzjt6~SNhQpE14Y?O!ZRDDV@dB1*zpH~GSQndOJsf}ya0)g;?XT)H
zC%<CtuVK8_{z`Q;f(Z?~nU2*oKE<ZE$DVH@ufyp0Fu9%?GUs#l|Ju<W=y=f{pT#by
ze)-Ed2qSO;_Q2T~iCpV7dLox!jJ{Y4V{kC`!<iV1>R$~)9jAt()<drsb2Ac*>(p--
zFRJibZJ~y8wDZcJ?w968-5)K2b+H0A!soFuwm|kR^E{;~j^ceYOu#T)f>HPl_QF%h
zKIr}#`{6z8k7|zwU~%#gj}>qbhT>psfy1#Yj=%{x8rR|&{19Kmy*Lilf1iM-@O2EJ
z{h5e717l3avN#17<1}1~3Hm!5bT)FY$C!iM6Eo(b`o?<Bn0r|UeLr_=T#O@e394VY
z6qn+1OvDwq3s>T4T#NT`9Tub9*JE)^#MZbG+v11FIvO9L+Nmu_UX87|2|vc~aR+L9
zt|F3Xs99A*?W?wD4qh)HG%U_&Js-0KpW^*848|2$0^dcQhpxuPxCURrb*SUXdJJQk
z^cl_b@()qvPv6l!A3wsCxD{QL<2EdUJ8&NELiNXKd(8ZXv&_ZuR(=ogTKUy})0WV%
zhw}lw{|t5Bu@7Iy{n#JBz_;)qF2=7>=Xpo*GdzYW7Z<UZ3kfVf)qct;d;in~N%nNy
zb29Uze%nn#!_gpXfA|j7&-)(7;Scx*p23Cq6TXXQQQPDK9>L3~{@4|~gjbQ%LE{Fh
zU-B!eUvdjS!QXKY-a(%AGX6xqR>}Aao8sRXhH0`}=Raw27Vk5nj<cCj{g5oEeh8n=
zb(g|isB^!3sQOz7qtS&bFST!BTyP<2L+kJ21%LLnZ_DY2X}hdIou9vpnr{oC3pJW=
z9O-MmT)bXKXjsj3YERbK^R35{yx)L5@k3mKn^EPr4bR}mcpi76+KXLSjAidewG*GC
z&TIE#6du5Fn1uWBDDteIaSChVX{?QBumk>t%6~7WP2`~tFrHR<@Iv`hTchDR<&z(8
zpxWnKsP^&??2dOa8t>x-{2ON@JE8kc2*72S7B^r9+>IG=FJ?ydXS3jS%!YUINz6zd
zf>3?w?5KYGQ>b?TX;izP8`a;<hXas%Chi0*h;L&d+=?!|hJ{h>VNulg**}YF7mHy%
zEP>sz6sq4_3CCh()b_20%djSHz*@KmpGTg}FhY@MB8<9t2OD5E%C#Y?yw%1ejIqjF
z>#g$6fVBt>%X3-RDOX~9-mk(aT#xG4zK{EH18RAR#Nx5m@`jV1mZ#(Cazev#+MS~K
z9hS!v7>3-NbN9nj_yL|q<>yEI5znI9fb*#1(?xuOWnaSTco_%c&o~6H;CQ@>Gw>RI
zjn`58@lA}tTc~{Ve5T=H1|~6oLs<EKf!FC6ub~9>Nb6A&3u7r%*_A={3(BJES$W)v
z6;bV9Wz_MuD&EKHn3-kQz?@hMpTg%+^(Pe79@W8SSQp!3L*!XsqY<)u8_n=_Y>sbX
zD_n(b@MCO;*~xnc)PC0ydt+yuhFx$vc0(O^yQ9vZdf*O>#3byAH?S8zMZM{Rg|IK`
z{3!-`*29RyD2zv*xikjh794_yaRlo8VH9TPcsU+(;_FxjryzYBV;T;_nYa^YVG_>4
zr_*!%M_tdEhqZ7KHo$i<0+-+jd>3^;c@-|g)wm7U;t@>5lehtY!Ht-SivJPnw_~@U
z>V=DNPqXU9GkQ<i^3QjEecC>5g)%PDo~{wEJp_yOJ!dpAjn!UHLS6TrjB3ZYcIK{&
zY!fp*wfjMDSm~)B;2|hBU%P*heumopFR?OyW%oNYU${Nrlf3p2&iPs}o$}KX)&7S$
z=5yQgRb#w|aL%`x>6D)OKNV5^AC-&hev&=kU|xHO41~Ac_}!lG4^;bn8?`^(LAB3+
z;sCshTAuPBJKb7uP3Iw;`G{dU<zpbKT;lEdT)g(!^EKdg%I&km-afJV8x66x-Fx<Q
zoOT$IgoYu3*7Ap<w$CsugTt{Zj=*|261(9jRD0#d(KrU@;A^-V$D!6Mk<f<)m9CBp
z9(1;cv}NY@2ne9R#@{kvapYKIwvSv(F`pND62llDgdLDJ!@U2H7gzG0W083uq7WY8
zy$i2nFzUJj$7*+a<XCN9pDBrIhq%^cUUv#XwLj%i`Bq(6%!v!5%xBd+$ZlxfTL$&V
z%zXcWF5dGflw0-wPxRIgeK=C{d&}EdKgQB8RQbP#nr}RI!U;GJC!yABGHQ9Nh-7<t
z&#+L|?}2{x=ajedw-<BZJ}iX$QFZbFs@{Exad;TV;t@>1Z&Cf&qxcaX!zBC;kKy-t
z5l`V|JcDct<44SmXE7gMK;@U~jYilUYyHo%Ln^<+8Gllhn&E}?Ry_;F!o078rI2eG
z=6+TWbzQPCs^8xf7h!YUfiK}+?1su8ZJ)WFd!UXdQCJvzVHxa$+?Fz;u^z@_D;$im
zI1I<&XiUH{_&&adJ8?Xo!wJY&>Kao}{gi1~6cey6&ca5x5MM>wUiWLb1a)6#C+@~i
za4+u0yp+jjSQ7W*i<pFNJcQ%%DC)kzF+7CdV`et^Ddd`|aT+;CHqM})KRSnP@jOQ0
z1>~I6;M%_X0RD{uY7jF}f01iL=J6yAcHw<mq%4edI1V%5Bn(6ka;$J4$0zVUX2v{J
z@GMvod1lG|B0h=Hm>s{sr|<+mjrB5eof8{le$@Se0=NJRB7G#I5I!BqITLcP&Tt`Z
zl2HU{i}X9^?#0M6QSPN!0yiRga8t*PGDuxEDq=Po&}x_yYhe=%#V*J_4)<_uhSRY*
zF2EMJ6I<gcY>Pi)XVi01J@HlSi(Bwj+>35Ji{p@Iu8axDGgJomPTU!A3i1q;@dmzv
z3COcO#!Ted9pg>hhx73qa!t<tbQbCp=E24I94^IbxB@%lO6-cOaV)OE1-KSJ#`Smt
z-^Y{q0p7(A@jh<B0$Hi2SQJ0Oa_GU@$UPqSEc_HXcQQUh?e7zbkk!`yUYGqu`@4>_
zBMA-f(=M<YMk3}#uHBi><$ZwldCxX;cfn2Q#*c6YZo&Py70=-|R6lqJsy*L{+Rt}k
zP27#jPY98;#>!7sUMoNBHbyX^;ULFF9f!We3iy?MoYZ_SF61z|*>_1f-ywUx!&r`K
zzOm<<#|*LdeAG!ZJuPdh7Q`@$>s?CkRn+<H7;KB<a0I@NQ*jdR#mT7ko`&gI#w>gq
z=iqZV7dzn+RKI^IPR3=p5m(@0T#09KH5R13S%<pbv>tWdo`^aR*nsrSj1Tc`{0Mcu
zd@EkT?RXz|qR!htL7ts9cH;=#kGfv*1unraQP<56p{|o3#tgJO-=Ny9qsToT<2b7S
zdjcom_c#%M!0#{_f54yc8lJ^Wv^SS9A6~}l_zQAOFs>tQxp52M#M`L)pbhGxU_kf4
z%<ZG?pt_`?Dcdm*Hph|}hUx>f#-_-#c;<7z?J<V;9dQeGLG>fLVS9`~ox}G;T|eoC
zhp;#Ph<&jP<rt0Sus`a2HXdi-U|fnrQ0K8D@F<Q%ZI4&6D)}Fc)saf&Zh~WRF^<RW
zI01L!BuvIBsB$<?1Z}a(p#sZukteP9K|;fJ`u!@GomdY&*baB$1pE}$&-)zr;a)s}
z`|)QyfcNnr7GT+5B7HLBFgC^`I1#@^P8W>hxB$OLb|2#uZpR<+D@?}I_#<A&pYR@@
z!))aL67tzd;|lur`)$_xssEt$WA%Oe{ZYz6>w65<FF$UV%WX}|i6fI6+8&y(0I#nQ
z8s4BEruJ+)cE*|57iXi&<4s(Q^KcEmjp|1&z)x`@{*H?<fMqYn?6?F=;Bt(_71$G3
z;SyYp%Wxg;#`o|DzK`GI2IQ-XjE$HdH{o;m5$gKMR&0PDqxSP1*aJVop|}fGZea>K
zIxNyq|6c3Q;n%27XlTHGr1fuzsvnK9EH*(+(+nG83sm`pp_Z%b3ij{Co4+Hk<?8&#
zdtKow#}6&{8fv>-M=k#rs(rkTeeh45g!gbh{)IP?OuGMsG?<@dr$wca2`l0gsQSje
zE3+S$1Ha~dPSkbGr&0G2^I%ELho!LqzJc81GOuSA!R5R!ihQ=l2*$Hm5$|GUY(+)m
zUYI)qtK%T7g~PEfPC@!S=Kfe8&+(pnW^T1dFCxz@8ci`h?HtccxN~C|md4ho{#{$-
zn!M2tIVUwb;(qLmU*Jo40_jV+Ikz+-Q0-+8Y=V)f{#_KRz3hebiH*M44`Xl*@@$5C
z9S%fYABe|aaVX~I_%;Hc#gVA{hp*ySI2x01EFQ-3cm}89U3>#oFVtVKe|O&eJ$h|3
z)dO#TVSHArUQ9sMiz!$Mr{gP_fah>Fstuomx*ql>>iXnd<lN4fhc%FAi_H5r^HJ^b
zJNPp$LFFf$uz!c%P(3s25ULJpm`T1f;VjIJvr)(YIru!z#g;e^bzc7#>O6~kpYCx;
zpVmyr#cTUF=nd6#rNckp^^~1<dlbqz`?uqbfxPw*6u<9!%0{l2s6Vj@3*(1a96v%G
zpSGaZ%T3t7?QU$~wTGbF=KG$F1g6t+IQE#!nS&*GKNqVb_e{+5{Y9v9Uxw3g1*+X!
zg>#X6?dJLT8eGYHuBDmJy(OaZ5lYy<!)`R>wTE!7&mpd7C?AJW=dDLj=dDMv4jx1A
za_rwqH&pH(!nvF_OvmY_(Gl}wXRL-@u{OShT8{c=?k@w(vhT`k55ex|J5K1nmh!V5
zJD~UeR%2e<zc+5|=cR|pKq#*o{<7!$8@uy9J?B}f4;k<i48%S71bXvf|JJvm^7atU
zd@Qh+w-8nT7op~xN7%o^ZT>#D>QNBm)Q8ltkM=PK?#Ie_5XT_<sQJ7u`=)y>@4rPI
zr;g*N$hnz28Bd|w*B|gVOhz5Ie#9L36Bfq{sO!&{usL2v<xj^G`**hu)f*3yk*H5-
zs1#uB*UW2v9*up}JRZ}BH}|L7*qZ5{N0s9XsO5Gfv;&ir@eQH%4#Z}JhR*c=wV!rD
z?Wa5&=GM0EhB}T!;1cYP+b|Np!YI`8dlB|;U>h@et>r&~sv{b9Q~p~1r&t6(L-jNE
zVhh}dT6fxFcLaWkL-1=HhN|D%e^kGf-aeLZ{}#4Bi)f~&eu?@(8fs;-+QHhW`uIGm
z-FN|mu?}{@1{jWwus6Pl{g889^ZDuKIEeSHaRRo%1Z<1ik2~Tr?2Mc6Wju!AcoKWy
zMT|nO#Tl<)F6@Pku`g=-M`JgP!3g9T4D&haSRBOrIMj9fc+|PkAmlQtF%%ae=iu%{
z9DyI=SfpEGjKfcH5~|&vg6aoO#hht4Pr|1#0oAXbjk>Qk2YcaLsOMwn<7ixnx*oF_
zb-uF{Y1@qD_yfL+$+!lu;yQeS?ejkJ*-YaD)cv_l7=oKo+f((${#|YJ_qO%EFymEL
z8h)mp1>rTUi`Ov%f5kZb19d(1Hcr7iI2Z5YPP~s_;$Nuk@;9pAosRTxVR}@5h-YHV
z>ztWT*X1&!u771g9S@&Gov-9T^*eK6U(Ap3SP<P<2<M^;IlVWEptj4ixC@^{^+QYG
z6%4`KSRU2KtAOeQRzdZzs-eos;I;jm*Vb=gGmqNmo2cOnrgPz8RGZ7QJLYp`C-6<)
za}CD50?*=RJcnE}HqIm0j18XgF`w(dhB3VV1Bc-qd<*|VohSc|I!{ac1pOS$h#ARS
zAgW$vMV+r@Lp@iP1KZ$JI0$p2?(^lt*~qg*?zb=)-^F6M3rpf*ERE-oXG_idNFmsk
z`cnz{EUZx(S0LAx+{dscHc3Z2fGzQPqzy7&z&%(8YjXf>fL*Z>M&OI+MxI%9kH;1`
z6I<dkY=vBVH26%Pc^{}fa_!LQglRaSbwRGh8GP2yT?Kj8)g6Wr*av$c*S3r(<eHT6
z3Uckp=#3d@==)-Bj7Iv%MhwzNHu_^r9Ehq1s|foylC9rPW*g*S+yX+wAf|KSU{rr=
zD2C!N)c!FX)sBt8WjGes<2c-h6EPVlqwZHv#Wpw%+hGD~`_Dwx=Q&uG?K2lc@NH~|
z3sCtDA?)8PHji=Izu8PiFri^D{Wl#S_F+@p@959jzd`JqkK*?A=LT{frujyo`nw~s
z7QTvF&S+Hn^VsJ0Zw#BiIjr=x{!<yR;Z$boFaCh)2mOTVPjL;=ysmKpb-eloBk&r|
zz?--bZ=<%!9n^kx7kA^|sCI{Ekj?A<8L={HKY`l6GGl+thO3azX1cljX5>J%4>|D^
zat+hGj-DH@^1dMI`Arw9-7bukFc@{-%CpYyCRiNl+ZrWsE0)HOu^fJiJTvD$h<p~*
zeF!U~&d<0u>b`{4QJ<Tsg$=Ma>bglNcEviV^S1iPXV#4dI20S>WPA~)BhTcS*SDJC
zySxv>&Da|C{C+#k&bD|Ni(oe_jlHlo_QNh1kFVljd>x12EF6mT`HW#mU(Xnc@8W1&
zg|8vcUK!(%K8P_1>0=m^@dxA?LH9+Rj@K~(x#wuiLS65ljr2W@x%ec$jk$3?7DuiX
zyUXA^SOJ$H_hO8tsCH#J_Qw^d>uf7=46ee-xDn^$7F>y2@iK11-;it2?u@h(J1{Tq
z!eHEu6>twekNdC(et}#AHx8nnOZ^&;ViMA4HNHX4^^GH#8IK|7_QrAK9Nyp>x4RIY
z#$uR^<&e(`yF>9Jat>}>Le7DWpHa`NUd5I8D<<PD<g-M^?>HX+Kt3~N{D~a14X&ZP
zIrbU%urmIQ^bK^f<-Upm_#39fbaW`wV+IUFea<=)attxDU@6RsWiSY7>y7M4TW{pT
zHuw~_!#qgaYve`RUW04*?g3Z`X&a5gI1-EC6bwe%GNTwS$LH`}ERG*yN&Fm3;c+aD
zC$J3inRBBo@>y~t1pmZJ_!m~ucvkl|VgIJF`CG?op9(O}dmW8utKGSHukQ&`yYxO5
z#}Bb8vM;$qk!P>nJ&|W9%ywxTuH!w|G|lrB4<6wCF1&-EVIXO-51OCzIe_JO{{`y&
zgnMV^=a0TZ^?Q=A2XZgXJrsFH!#y64Ah&(Z?*p2RT*Ed$mv<c1SN{&b#1nWDd6v?=
zzJ3O^{u2rN_lV8U7HIvQ*EQavzou&OHs;3psQ&%}?0}0<>&-na_gGwlZy@)!%>K@D
z)Oq|0^x!HygsbrvT#M=ltwZG}jIe*7*jU4B<%jC*I}f|a@hLO!FJlS(1#93{)cMMF
zoQ}WZGVGkozn=DQ5gVT}KIM9T#`O-Z=U&W#`%vdC2e1@=fjXZ(hz;;dY>8iC6n>3L
zKMB?UJ&ddH8{CRVQ2pU=QR^APdWGK)Fu>4xfbvt6*TEXWaGU9};2q3|e`0mKhxPC;
zY=xXmn&(StaU^fk;~30<Q}t)m`4XQ=GS4Hk;t}2l;W^BX_b>+rkajNA`SMe!>%82{
zG@qBtgSB{{7u6rhhw6_Mzz$dl`ytQ5o6kGBa0c&#@f|FNA7cqTfIKU29%oCVj<aP^
z_Z!OL1uT!hVMWYJ`BXx)+{mjs<NV2Zj!?O!#b83ik8F3<-=DAuo<+?UPT0R?tnXAa
z=hOCXOK5nLdJ=?lQS;5i&iED%z_)P}E<ly*LR9}_5q^a4pwdYuTme@8^n1n1UtY$k
z%r(5sbUH8YhR<Smd=VpY7WTvy*bBE{AN&oYu_Vjthp{*iM`Ii&;1FDoL-8UGN1Y#x
z#Jl(^W+FeMF%OQxV4R2*aT3-?zMH|_5T{{Vd;@jeJppIpOw@WR5B6^y8xuHQYdy7}
zM52b{Trbf6$vrW1|KwP2o);x!C&r&eoj0Dxad-*UZv2c(@E6>H*YGE#Z(w~M5}zXt
zJ%^<0rT1_k-pA>v>sV?BxyWYLEBX-TbDL@K2IJFWHr69O>U>Gpxw>LT?1#F}H3G9B
z&wv@(Q0Lh>a3|(MT|ej9Hg|a{9(@tBpT@mCcRcS4;9z_P^?97axD|^aZME?%Ud3Yg
zH$H~}lwWCl7As;Mtc0zxDn?@sRJpqpPgwO!?Ssl)tDB3^u;1Q3>i37()9G&>g5-Sr
zNtZNSx92_UZq~<_P|MeRVUL-wzdc{9J>LMwe6jX?rCElDaHdzD>9oI5*WB7~=`;J%
zOSI=x{qYda`SP<pHD3WNh6T}^&+CuLXE&Cw^$SPsZxN34?BBgL%gn>yoawz{&&M?w
zbH3h=`Rw1XO?AFH_I!2i`RY05vww%ys83oc)8m}MTtD_X^Le{Qj`{50ludQM7WRBC
z?fJqS^Vz=(n`%CXFrCVUecD{VVUGDivRL)1QY!i6nu3{6&Na>RTF!mU?GVbe_HVSN
zdY#;D&o>6uf8buFd7XP4*5Unl^lnf4w^q&mhljs8x63ZJyYl@hX2m^@dSL%ns-b>?
zhj7kUpXoGT1Ekw$G<3{o|K_Qo{)2~b&bOB7RPWYdWn6F17s_k<cT3H_lZW?OzRFC)
zWqUrgW7_Yo;0RQE_8MMA@A}%mH=64Dc4s;*HxjkJQTBYHytaQc)KK|(2xt1-OLNm)
z7-ujC{)i><EQaDaRQid8{d=Fjey{eE<%EVI^bd6$<($$yzaNFgct09j<5-Nu*HGu(
z6Y*o5gcp!|hi)}Y(@>u~n2VKg9=5=@F%0M9d|ZS&|9%J8;Zpn@IcGILKe-aU<!1jz
zsG;i)9>TfZ_OgE3Zu?N{v)^7{wQKh8d!{<yi}rj??D?8H=CgmJGu8T)$aE_I4^Z`M
zqhr3X?AHFIa`X_+eBQ9<`xUi)e{;+iYtNV3`t@QutzU1{`t@<lmtfDQ{-TF)rpL8q
zGoKw%{gF=SEziWq%ok_R7jMtUHALThNspPYhdp1UJztb#zUz;fudh8{v^`&pJzq8Q
zZ2$J7d5qHfsh;atqv1uSQ@J!jwKIIy$LzN^v*$ODYkZkARm%K+7Y{nihhx53J|j`(
zGs>P%>Ds@=Xnqb#^EuP4WzSdJp6_|odEyK9{7TpUZN*gE<Er-j)ll2Bx;<YgukGJR
zH18F8c<<cL^Q5<?&x>XFTYhYS>VGuCf~f5qO4z?uXkM@O@ZPzctW2kJ3ql=#v!mL(
zoTznw3bmYY!v4)c^SM|L?=@drLW7Ixbp1~Kou^U#9o55NY>MjdbVT)cqL6Dh=Ka}{
zIE?qD&|4qv-w`xgGv37pb8e>`v;%n<pA(xSpK&nf8_H|@_xQ};>C=4bA4L-yc=pIV
z?$koHV|*6EEVma>=d*S3d2EF0_cukIPc_5&$g>jW`CJElpZ71}ChUgFx2_4;zfEVh
zFG`<oqIoR=%<tJ$d1-!4ud=m&cg^U>>m(+2)~mymht~5OY=(M{wm0$&t2uvTUfaK8
zX8yjJ=Fh;WS{l#r4CjZMU(bOQ!J?>o5sYE@ENa_vjmcbIFJ9ZfA!aP+weqj_tSh16
zJoPd^UO<)KMbvTSGFHSZsPo}pP-T7<r{Fcz`S1-~fWIQ=wq_a!d7s3}Pb975-8tta
z^7LRGh_1vqB9S;w7?JGjL|bAgv4Ge^TqLqkp{fy)#5iIdkwn}i3iRaK0TD~gBlZwM
zuaE{2NhA;+;w%wFA%qgK#Bw5uxJMMH;5!oIh;>9V`3<7Hb-qNqXdGu;U?1{8L=v-!
zgM`tS>mB@^vN3|wvJVl}7#FMYL^6?!!m3XsCNTXB){WQeh?7K641XiyiB-f&A`9ge
zO2iV238O##0ir80mDo;PB=W>kcZrciB5{QX=0vtDF`L*&=s}HYL@cq2I7<|WV_k`f
z#1`TT;fiM*F_qXu+$4erF^-r@>>=(El?HR(N-QQ$5_yKOy@&)NksVaegBO^|HELoW
zagvx_oqWzBeImLc;|W(I)~PY&P23~ay~wy$<eivDBooD3Q`W?GB3B#ES%`VWSt6t@
zWkzf#?h&=xu`D8q2x?Dy#8l!Sk*5QBCbkoS9hrX?^AJI^NrR|Gv?Zd6al`^*3z0;e
zCGHWq<}fW0N^~TK60?bQ#1Y~OVZ2FD26?bFb|gZ0Jr3(*B%vFH%ZY=;ZKA+j(kCK`
zdBivtaS(44!Sl#Bk<9$A*O+cR>5rjo)3NOsPrt<Q5IoOmeoj4Idh;AppHDEx5y#80
zE~saw_7LgDl2_!pP2()K<^4(GCXp@!=@#H`xQ@nfD()f95;uuT8JV6azz%+q<?@V{
z(QG=?v8-{t=Gh}7oIGwvuAk|%gSw7oWC>&*f@?tf9xdZG^YVEfV>aO-l8Cd!b<!@K
ziFG4_xG1-P<#wbnMiSgNH&zi_h=asB{-%a2h~S<k=dvu5*v@!eKi)(%D@*?I2obiF
zdbNynh;_@^1}jLHIQTBxd?nj;75OE`t!7>#%NmwP<XMZvK_X-wb)E=W&oYQ=?=hZ;
zexLFnx+bzdgdS+BPi!HIf53i6xHhs5MDa~5k0|~j`6Oy>W;&wyN2E)1-NN6AdBhgt
zIB}cEvz6^m=py5G;s|ktNVkpkC+ZWC#5iI(agew|WTCTOnrKEu6SIj;#1Y~i5xkvw
ziC)A!Vmon#D8NOTW<)G8kJv|CCkk*;tv(S?%qF%F7l|MqBC1A&6BCI<;v^C1q23VT
z#6%*II7#%{MSDTqBTDaPy@_$e5hCbQwmUJA*hJhTg7=UgVjQuF2>y)vLF^;05P3eQ
zEQv^BB9Ta(Bm(!6FCv<lP3$9X62beZ6NGNYCKAa+mi<gi^de>xTZpqnt^=$y5lM_A
z5{V<kZKA*zY!@PyNFcTo7l{G~smFwy*hHKp0>7jzh)5!V@DOK-ps&a~(TkW(Y$2`?
zS-z%hh-O4AF_l<H93(Chfl2(GXh!rR5{N|N2yv6hb%^yLdJ(gUEkrVr?lAR@XiP*C
zQ;9?(iMUPV`G$NFVMH`BkyuP@Cr%Q#iJ&7)Lxd6W#5`g<kxXRy*7)D>zY_Rg3H+}F
z{#OG3D}nzjOCTM&>TU#NSLPyXbnPG4wSV_MT_a*5t5oVaFsf@z?|yxw2KI}J?%HEu
zd|cN-{NFWhV2`d5v9Wp?KQN-7HF4LWG4YyJGnsRD?HSu6eqeN2#%b9#^i2}s99xZ?
zT#q^%o8C6iXx_WW!2WUld&awpw=Uso85`d_ruXpP{a$g^>mL)_J34Bhk%4cMSWt+2
zrbdvN&s+goBIoji@?V(vy$Z+X<yj5>)U8MKz@D*;D`eyds)nfyq2(Fr{k`o$ylxo~
z7atKnC{EMrH`Tpq>6u9l?-ALE)x;grO7f<~Iw~=x)tJ9MJcOEQ<uKA`ug90+u(;r6
zEy{;zI;9_mMG1auJZgvvjMq6B-_bX|TTDb;UvpeA<E*^)kB+Q2#2n}Hjbnbs<>Q-t
zwC+5&W27}ABZjvb6dT)rV0=`hwO&<>C(SZEnTClN8W9<YP(njerfgOjn(GzZvv+iS
zurjOlb7_KyhM=((7^n3MdcvGn>!;$SywYd?&RQPhsz0#4EgrGHEdm~1-xdK6udg}(
zKUm)icAW`NYh}DDWFnO3MU+IMwN1LkMa6eh4e)Nu$JHBcpHSwvwp-i~UjC!Hr0W41
zR9{tZ3lOTe`f?=I+kcw=<Ld2A7RP7TjEKqxzui+Pu35oi&tAy8yzTIQEhC3doaSy`
z`mbA8YmDDlK5yNE3vSR?Hm95SQ&rcUE7N~C9=LY)jqF=0zLa_C{UQxltY2GWZRzB8
zX}_cX=hyPepB(V_%7ufTA6a>Axp#N>ncIDItNpLOc<Ru8BXiicclCXLADGK?EgE+J
z<BgdH#AoaD!HF`_6Mh_-ZDCTWs|&Ulj_bc8xY&B`lbh2e8@n%DEio(awP$)Y_&nmP
zJ1xiLI&tya#XC!vd?z~MQoSV3dCciL&g_(R=jxb*+<lL3e`R*FId@)t<CS-F|Fr14
zyF(A&uY5Ku&p%O)uCxU<B@Hk9#-3WkDsL*kA)?{ECu^5DQuENv8znlWFW7z0v<|FC
zkfu9#JI$}fm!EzA#0P=1n_sHcw8pul);~Y9vdr}G6B&zs_RDduBeHQ^X>S*aFSa!O
zt<x1=zEUKv{^D5`L)yRd$?)*F4_E%;O8ltZ`&<Vw)6Ejt@P+N2i>{hbwnOhl<w8#7
z`m*+><(bl+y|=o0$quv2(0IINPS+>s()F+|lVU2z%!_%Yz^wVB6T@9O&h{wZ@{doF
z@|2wL44>aIr#sg-?%KK!)@<z5z0llM1;&1Kdcds?@9mko{{8BICC`sb;5_eZbGpq%
zK4`XMRox|Vy<h)r>cXGH2A|7!Jx`Cox=WthxnoAUjQu!AF{is&fA7HPx^Xdo)Nin{
zN2`+oKh8gRbySDTuIWR5&$oQ{h8e6cJBBOm8}I$`ao+K_#$60)+vCN0mF~4$^KHz$
zbBp2{K3D6?y4(3Wb6wb+Zrb3S-EIbietxt`rbBUOp6h>YYo9V(GuG_<LH}p7G^%*#
zEuOzHryKb~)I0Mw-iV)EzUk3A89LSuh@4e1xz7BaMN74e+<3bSZPaRWy732d{t{dK
z&CJK{jGS?2%9~@mG`zWGd$m5llq=b1{=uE0uW>$QPIsx`sH@G392oaT`Jm;Wb*pe@
z#<YD=jb_!G)aT0Eo7-IFJC2Q<?6|J9EzUmu!QmDSzW(f+uIDy3uDH2rrTcGJpEI)O
zv38k$|7Odbfm{z~-*=_m`pUZDO<rsDN|(={Su&wZ-ZysE=nz@CboHnqZymha_Qunf
zXeZ3&4eMK^n0szQ#!2J0=51SM%+w2Y5)Nn2oc*0yyH|cXvD8cF_`HTWU7iE2(>>i`
z#%tTFEO_FLcAav4-*wQCj9q4R%KgIU+Z%Lh7tS>tbGl!XXN)WG{9onrjJ}X|@vZI$
z&$m4=_WaaJRpur3`+W5L#npLk)0{5(&Z2Jh^49I~?5R(h#Iz_{;*DSC2WGhT;xEy2
z)-SwrA?sM48?B`E_`JomJN?s-{$YE%_#K10UafIv)K5)HJ+uGN+)i<Ye?4@TM*gU|
zJY!${)-g+h%bxvtccDI)`t&}wCbnmpv01L&UHkRr@$=K3<+%{jcBTD#)lc1Hwq@`2
z*4*Rwj&^zJ?#=DjrX?>tcJ|_!!3!H7idxD!uQ}boV?oWvjcb@LuFZw06?M+IOEn1E
zyYj{H7rvVtlI~`BxpiFcFsHlPzha&*jxJ1Gn)&W8;ny=}?KgizgKQ0Uo*A}nWy1M_
zl?U+odULvA<BU=L3mnKAwk&y9-m0~pT<~<C0oO-%xUgc#cURAxtkH$%RL$uEcPuE;
z_0r!b4&-T<W9h~`n_{0!EZkw!%%Hj<*Y*{@yR;_H*O=24*_<J9d8Y1jo-1|W{JqMx
zT0Zqomecz)cgy$ofKuiD4*T#0>Pro+?~1J1Zhd_zrbm-HSKpo+zaZCusM}G|r+<0r
zR?XebCV!uUdR5(=u6uzrtyiroKc@1`J*!{NQ={zgb1&cBF=F!Z3Ga`ZIN)CMFrKqF
zr;A;my_iw6ZG5dQhZcsMpSJnry{4x>DVjD{<tiI`p5OM&ES@tmr+X>+M8W}g*Z+sT
zFM+FZ>)YNbDr1o&30p!kg;Ej<rAUP+ipHIyxt&5$DKdu;N}*06gpPSALP#<mL+BWj
zq@0jb@m>G5?_FCb=bYz#pZEFR@B6iWU0wIR_8R`{zs7s5b+5bc@!rD<vfF4bR!CTK
zGqv}O@M}l+D<02(g8|NI<}PE3%%|{4T^EI<_RZ{Sw4vZdkXnUv)}h;KUt-T~wmRs7
z{a?&opBRf6c|Bo#`{bLijSk**?Yz=v*Ld~p$G1IiYpJO}MR*F(4PQE3?(1mzt&UQb
z!)_jaIA-S3h&T6#KhX|)+oB>|V_S<T%mGapO70>CK1p~rcafe!L3+MSekZ9?(-#SS
zr<_=-mN2+Ycu#5cGhWP{X;0@uxn|OSWv#m>dgvw9l=^2)(HMV3x5b!}6SY2HebHC)
zDZD#&7j!jSreAe=`5>?BmNPMtuAQ7^H;!CWG2z+XJ9@1U)(|G&rM4XwFR6-(_&m_+
zt1!mWCctWdT4Hcdi!}XHy`w)Bqdnco;(eT1m7JM+q>W|8jNwKfH!N`UoPYFz?OSuL
z(#wTOT@z)|KC|#bgzcYN4LVvfy!GZ^uT(YPwM)@)`=;ZynZo9VpI1D{$;VtHbN6j~
z+1i)K_J)^y-qvkj+l^<m=1UcajtEN~tsZ9)ze&{zb4o1UG=o8j?O*R{wdX;O>q}ns
zqSm^dPk%bvPJa2YX#XxJ^Py)dgM8^~{R8iZOq|8bZ#nn3PR$B0WIqx7(Nf{+-prx%
zw%p!dxe@D_to~k8St;0Uv^hpg{l@W(!2{lXI;*2#uMn<R^U2rWRA>B0?4M=fxm@a*
z)~BM`xye%7c78fGZvUO7*WKQ!2RC~&V%F)o3vre&PltuqZO^Xfnm!-m_AiieYJFKj
z<LaJ6{=>J~#P4a@zD*aEQn-81!t46xdiUQCy~y7aB5(*zckJYGvp7_B<B`b~UZW?M
zcJwI5eo_|RUT+nC$MZR(%e}rmT-RZD^Ax$*byw0igrDp+uUB~Av56Sd7*Kl0|Gq`D
zz2ftf^dX1V9Z-pwl(D=p^rG|4DR1)jZST9}Ksn~xn7h~kt-{`hDto`tsVQz@e*Joh
zzS)uOdD0)J$Q`?|SYyiq)Fb9D)bCi)<SQ2k=5Nk^z3%naQ#I1B5A(0BD2`qfva@YP
zG6qp`%$>39IkO}g-PT2&=Hw;bu8GQjK4`)9=$H)8yZhEOKQRvDlFQ895S#rgKN{G|
zpPe+T)4O)HtIUkMj_#9PD_m0hyeKuTBl?-o%$*>wz~ig7PUqCp7IAq8XZlD-R~%Gs
zwP|~VUrfI^gN&`155)5bU)sdn)OgJFA{E!QLC<f047!qXhBq~P;ZLXhZ>vRapAg`K
zwfB+a?o5j8P0N9X%|>dQpBQ`X!O9O_#mP%Xv~x)Jn8fepr-E^qHgoqT@>z@U+L5mf
zew&by5SU<Rc~JWEy}7}T19qiv&^|n=674B-w@&!XdWB=`?q~~-z*_YqW_l)*4F#2<
zz1^Npy<TE`yafF(bJxn`pkQ@LQQqB8Q`fqscU&^ytjloO;A^pa(v^n`+^sXQ?}g=W
zdD@ipv(^eTcWvu3Pkw2$ket%oO&|1?du(zttSwuS3^zZs@K)<24EVNUlC{sM{99jR
zU7jXKO#F5!_j0%E>&nUpE<S*P?N#Q^{Z`}}-hrVSgANO#+l9M*_@&VC`oi9i1nO2P
znUltqq3^9=?uOOMoYdWW!_fTrz;7pZFVp^|*;XIfZBjiBluTa#u~NMnW8_h!zbDU@
z^l5+Mb^p|rhNjv9Q>Aatd(<O$um0oo)JIp<+>HC;y?y2`GAvT*;fL_~4&5A<FS?x`
z)a;J((lv>@gw4BM{5g1g)EVq6V(u=_J)YvCGGtW7p@g!D4{u)lJnN9bfXZ!Z>x10B
z-nScVgr!O5PVVuysM4^CejVL)Pvu)~jt%>o^juT!;ggW;x%t=RHrzyi#M~{<c4>Jo
zH0Rxd;14;E(kqoeo&I8e!sJ=dHGiw1R(Hl=On$y2D=#Oe>wK;d)_M&eJkLMTr0ub0
z8E0DWo5<^2n=5ZMIC~NH#jx;ZITaiYuqa>JU#o>FuehMg==Qe~)N>D=kv&rS{FvrO
zEwtn4yZF*F&2<iKbL?&5@M=r<kV6LN)X#R>SGITM^&T%QXN7)UqlWf?xm#7M5}c=X
z^tM6t^G_<z(p}y2iyQ-{l&z7Um!fMo$xs#hYM8q{H{{Mn%I@5(V5EL`|1+(%e2ek7
zd-c1nd8<vk9=eeuov}Zdxf{N=vZ~L*ZjWqVsLqZUT3q;AXsmW}ZCpZ(#m22Fz0A>{
zUt#XvOfkAT$2scj`J4Ovs!Gnq9(<Y?xXSX*MU5vOb`iESjv~Fxo!KFcxXgYxroODI
z4t(`UW!C8Gg^9y0tey^?Tof^B!YU|G-H_5d_vHMNQ>D&}A3jRi*H>%OjzN`g6Ltz}
z!}rMBM|C%xiH9g_<}Uv8o8PYdVjrT@ZTYvEanGHPetR@ob*TKl_{w?C84vRj-eTr%
zYi;-!6C<mS9xfM79o)O=%ZQ~RYN}&&Up?QNHk((Hh%rPubGJHMsdTH|+m*8{+gZ5v
z9kOh9l$&o=VpMeepzy6#()sb&ufW{h9acSZMs`_`^{tg;v+R<lrW?G{dA%~`nSuP>
zAlr}C1w6dSMCs77ZhK_b-UXLauEjNv)p}~$cG)jx$Ksle*I1LbD@^5aSB%G*JH2nK
zPMi(-BVmD4|HI>JzUhXPBoDN4D~MVY7MP|Q7*~kr_RbXEi(seuniD7Qa*toRb-_xN
z#qL9=1r!-XEw-NQpRws;F6zf*7G8m$!t2j*+sZzd{Tk|EYdPvwyAS!cr&V+(`F2!M
z&iom31dEuv?cQgW96K`Tb;&$~*FGV=-^IE`sH!_v`}r<B|18#1)*j<_=5DF7tXoj^
zuK6!w-(A?YH@o|p?Uz({-JW-JRbk#O$I>@JSa0c0^2N4mW+{j{z4X$gUeo3zb{fO`
z8s_Gsml|@v?~KGu-yI0=HVbd%rC;}+{A#B^+xGX}zW#;}jy_zIEE{}!z0K9tNjK!M
zCzAJ#x!cmUv#iPRYr{HB%#@vfZBTf~)N2K^gsY~Qth4Dn<W!y+=7x~Rd}(9Zl%kx<
zuAS4`bR4^Mv`RuupG6nukL%JWIP#Rth-VX1u-?YpO>8qFTd!o_nk$bD&mEHg_%-?3
zt*Zw&+|xJz)N*ZMbz6+B)-ZQzMW1-8!4vf#e9bg>dN9xSVt`vtz|#I{hf8J^*#>1|
zoO6=7>)uW8#=?DNV@`dLK3mo*{>gB)u{_stXKuY4Kix~mdQ27eg`g;y0^FPxo6Dj#
z>=v*y0LY+=4uch)qrmpep{lSwE{0$f5gwun>j54Mrto3_ZeEJbS5bHvqOo;!5N{gX
zwFS=vcLLji(G1g`7q-W7HrO5aj$l+_o)b6#><V587J#F`Zs2ubxMlAqdVu3`kBL6E
zm){G#2lw7!l8X;;^Ga;KiR6-kof1ICnR91|Yi>S<hsQm(rr#Wl?uVIhxRb|KBp5>&
z-ZF4sa5Q)bcqN$PGX%If6*kvG@kxf$6YgL|I%j(A16Ia8!U|IbYl3sZv`?o9klg#y
zaDNNU=|G;k{XG;{IUs`wY43q8K>H48uL12dpuGjOuYmRxNbV<~eFL;tKyrV8xg6>b
zKzjosk#Nbie_HdWb$;<0zj%G$6l0Sl;5eYM4RHZYrbz=$8fel$lLneJ(4>JT4K!(>
zNdsaHG{eQWZ`_@N=pAExD}t>{*5KLg6F_T7wC4Q<*W2(Lt(*RV>t=8-1Bi_*uH_`|
zTj9D5ci$G=j=NR_ci^t^Jx-o7ca3j%(Dys)um{(BfqlUCZWu=cWUy?+)=ss+;{a>G
z6$l0*fmi@b4?H;}&JkD*!~?b%t7ig5Ksiu_ak@3e<gVP<yg$a|1^~{?;++O)e=VKO
zkOdR~g#ewgPzlh>QRP4pgeeDb-U81YkVaZ)O}7P@bS4ibeUYx%S}(jdnI;W1X`o31
zO&Vy@K$8ZVG|;4hCJi)cph*Kw8fenMe_8{01jagD-Tr?kt-<yVK|cQT?1$M0*qeC^
z1^!+FR}Uwlz<$1q(8tF!z~0ltdA^H(pf~pE3kG^S2|eZueEogqIymU+3?DvJTW{!K
zdJn*rdketdBLKVFz3Ja~?*d3U;+Y!n0CeR|!4Vr`{wMDOs4JS7YGZG?x+1+G;4cWE
zB}%NDsw)NvU9l{tuIMn<*M}@s=-SjNz`<yoxkEsZldprTK<MP*N$%UzZ&QW-KHhU2
zeEePUmH}sH<>W8)aPkyeQh5FX-1-La)L7Vv)X86f&D!;T9o(EeJ)NCg=3(7l(hVHe
zhgI+BJ2ycBr+K2t>K#B9N}q#G-ES;ic-dl(011;!BfFl8v@!YR6r(WDU^UHVs`V6y
zv9Q9veL2Oeu(P&u7;9v1KE`P5L<eJw>1I<bEgYr~CB2y|W@9n+6}L~`9P=V%YyfOo
z;aLH?*kcgWmz^a773=H!I(hgTAQSZUt^F5_@$_+-H_6EtcOED$PC_65{(te?sQ;$-
zzlxXN`>$fguUezndkh*#lh{BtoZ%ZD!j*V$zY`XOEv1C+9?&=0nc_E^kFu0<nC|2`
znAwqT>g|T`=)Dn5DbYJBI1i2)Nj(}tk37u=dUS9w@ptkPm^yj8;$4@a-|19BrT@&C
zSiAqsb^m|nY?Q%2a|Z?gV~5BI(K{voBrmG4S)pNG^kR13=S97pC@)O7cU@{Qzek4V
z1ZkZ=6);6!_=@skDt5x5Y6Y0!T^E6W!^A>RdiTW^ei|`#?-4oT#|bD*mQu#SRziPj
ze%L!9?qHnR3434TU>AX}5cgD`e8D|2*9iM57Mxp}zcgWC_>T2K(;E!O<TecU(LXV_
z<ET>8`ybKZ#UeYCKyMc_Z#N%i9|L=e!&1s6(0?jkXc36q$B{i3pCBO6liW~w73+wP
zy$57Y0i>g&fCY49)sL0eztoZT|6&~-LSmrf|CWv>aBbrqIVc5&_P%rhmIF4>kzs$P
zBZsl*1*RIavgAqaU?W9|l_ko%KO50|V)V|`1yOi-XKGkoo;Fs7C{G)fp(NNfR)*4G
z->?j2z^-8#QbE}|4tq7gQfjP|(8YZmO07F?nJiggF3w3#{&+VKrI*TMF6<jCcZPNL
z=&41;j=84*%`h)+DJ2MY@fA|{3wvoroY%wlyNttqs7Md!$3^XLKj<2HDXC&shTGz+
z)kiqD<c7-iOs?)b(p)`^6M*7Rd!Lvo_`=?~a{T*D>!YvlI2ixxUWH?MXvl>_Bv*GW
zdKZrJQ1cJ*yMDT&_uxeFAy0K!`l+5$o?0|$7sPoA`?_`^32rG*VfS6TkOq6oQ`pzF
z3*tP5U0s=%%u|cM$W!=fG*2xWv?Yd!m-5;|s_{IvkjPWY3vvBX!a4~V$@=4h{NmxT
zMQpSByR4vQ<{#CcrK0fuBlV|Y`y#39{~PtkmC8HxO!a4^NDu$0{seGt8`hsBtZ9*H
zSbwZU<@;~zkM^klTK(DEp#IFLyZ@iBKa{8co9fRLuK(#zn>S&w?8x>rQdaw+{$z>r
zj*ZRTeEfr){9XTgn9TLp6xN?j{WzG~HEw)s<UdE$uFmFU$!SEEg^;D75n2A}s8C$L
z|11;Pd@mO_)~l0i3@4W%ZFq%o1+aX}zLj`W3G1{Xx!9A5xM9R2OWh^;p>duDUHr-L
zxp%k~6}9l&4TL8ik4m<0Ib7Um)>;1Gv5L0?4^fUdL>BGacX68vobb?DFM#M?B*UMg
zXBPD`P`+$OxRNqhaOr1<dgJ$j0EsgI_!;ujM^nTyH2&09|F8isOc%s|Hs8yUB%upx
z`_N7Cc8TojpABJ0V+2$y?)`O)P5s$}BkQZDi}McS0Wy-Zt6`j<C6fK06(fmcP=1O+
zZ215CG^k2EUx?H2h>fj<-=%@Z;`M3p@OBjhGx^23FXZIsBRZ;^*doEpf-ZPCJoxW)
z@8c_acBcK<|5R>C-IHvT*kerhK0<fQXi(V{%N9(95oS0*RaYB01GifLf^0n?9LYvH
z__L|kDIY&(GCAs>pQ&E`NH$FWFw-CZX^7AlH~|0j!I^)mH%<6ysJHseua}Kvm(-i2
zj-oj^hQJNA9aMMHAxGA~AV<G`B02s^JJL`N6RsZkB2F?Z0P21t2`G;|EvAn@)dMz4
z7guUHBR%MW8!>gytA_Zo;n<(*s447)faLQdl`TH(0-3$2+;@YWdYzqjpqGP>n**wg
zgEP$s1+e-~ItXI*$k*5#zu}gZNqsJzdT7JQ;5`TS%sC94ggzuglup)OjuW_G!cE*v
z|5e&Vc}!_AL^yo*tm_=;=EkP>>c&7@5x%9AIJ|LqIu^A}R^Xn1rId%4(;UGVrvL%-
zV+%WxKHTt_E%fm5#zVEg@Vj)Vqx~Rr1BI2!7k%#`74h%}*O%YM(m`SW+0>`Q5kEGT
z4tLo9C>_4|t+8|j!@jX}P(Fs?H!Z+Y%HJu-%xVamHkdNq2v$r7hG0oK=%5OyfIY7n
zAP@OSKaJ@tMd@XJDDOq(1!ZHZU=9@k4@_QC`%2|TB#Wy@fUmU=ex5`Vn3Q*Vb#Vm<
z=8O?#A3YZupd3*<ZH?at4PkmkJN8|<Wb!1#oif~M!`&p#9feD6izrTnE0H!zcfBl-
z#M;T(6QzRM1xbjXVbZv~rUzDPBfNmkN|-0XLH~`nRid1isGh8Tl79Yd>f0%jYd*r2
z?Bm5U*i#{cu>z<qp9ri*x{E|I{Hc8~4i>lsQqeW@W=#d0|7{yVb>0x}8qOJ*!mhD)
zqdrgT=bcD@Vwr0=nW@TC--x8~j=|0fA4Y)QzLyyTvmeO}Z;hF{c1;eyiez?hz*yMJ
z$x~FW6kt!|ddayU$+llhMHK8t5Oo7<fgRAPZ)5UdmX=N0PV){zYiR9b?By$5AewBW
zwwH9&h^ZSxQoc#f+mNnpVb@UCj<9Q}Yc;s7*EK4lP+;Qk<3;lV{yv^oG(E`b7?mF`
z4r91-_Vfs#Apzcb64fzL8zJ!%OOTb12QB#oh;&9}w6XSEJf_f~NiY~n59y4`;Z5jR
zOQ-QX{VSd6!EYm`PG^Srv7ydL&kc1(vNX(RYIFGY{v{GE(g&sU@AM&AmUHMOF&O&(
z50cCC0B54CBsG?9l$G%Up+uZa3#|T8o;PCZ((H&I8>ZPEb`8_)3%iEpgwh;b?_VN*
zQQjKTZ-AwgSzUkEusx-6S>MNt`h5zQ^e*ztty&nly27fi&lk0)_3ePTU8lAg^^fyJ
zZIGy4uIncn8AE6x+=gY4=KI`+iTZ$ijJYNACWc;&gdu?_ZybP+xbVfn^NqDLKgt^_
z6OEX<ydk+7=8Ycg8s?25>>4YNOoyWR`0w&YvQ4t32M8E_>|Lg`pm_0~K!@dxrA1WE
zrqB|hr5k#i0BfJI?gCnpWMwUw0{XLI>7hK0#&3;1^HAQ!;J1c(N@XJs_6^gU1iOZ1
zk-|u;3*-BCnRF%!+rwAXf{Mz8A?&$)9~<b;x~;k~B*o3g@1k-eDwh<8E$l|2f5sRN
zjTl11Am#fqjFu2~<d*bb@7CCx$_u&Gs0&xX?Eb4|R5Bln`3Mw-zV|T*Oy93+iSc0;
zGWG{$@`w3&oP{L%r%-=wG#J+{dHRY;U`r_})(70j^^cy#i||{+JSDvp!(No9-{(^~
z>_z4Hd;6-oaK5+Kg8dbx@AHDfH~h|Cq<0$M*`ut#;NzSG{BAHpRJX<XTptd#G17{W
za90E@fZH(6ErlI}`<|?g!NZ1Vdf~e<ocJs_&mM3HBl(<{jr=IW$1RW_?73qK=4Y_|
zfz=&lk@E)s>&NMQ{4x^*8%wGB=M9pbJcx8W-^nvjz+@3W`<T)K3rsXX<H)5zE@a^2
z!y1w@O!E%#nBz^S_lfE;mCrvLkt|e?N$(<Ae4UNGU3^?|k|MdM-(<j|I^!wuo+ET0
z;~_*(FDmzPb-x9;d$@_}hyv_H?Yy^Ojydzf>JIr4g;PKOFWCmGtCI^+zewfX5(zqo
zd?^s6?fbDF+AYyA%0du;Qwmw{2&rfsMP*TJNEXi2mGuHxP+6zEC#7-iv8aQ^Z)7hA
z`-W?0WUoL<Mxf}A>ef_9N6Pi#eAh0MA3lDQW^Hy|7sleyfPKR@kJ=3_*o*St+R1;8
zKqyM5sFkDe=zHIy-@mUrhOig)mG$;io=joiu)U>k3h|j9{4vP)55R65=&rS*4N9Lc
zCeoVmM9a<?{aXvXe6cP`zl+KVxuNxHT9(G|Q}C$mPX&$o*UtE$3xej^Vqhnkw=%t9
z33CNMQr;c}zefd061o3AZ!wPl{~>Q1wtIh<w^WYm^Op5p;;xOA7s}si);9XqJ&*lY
z@;3t$RR7idH8c7?e@Ah1G9g_4(tH{{TlNC*%|u?2$USQt#m};MXh#k^3+8xuv-<j1
zZ4;$W3t=^UrWMCq$;C@$isGgCDPI1V`u6bqc*XtmKbx~}7_WG}Ai57Cf}zJhYKPGT
z^X}oFqeQ%HMrew_)7odu0-=DLlz_X2^Nq0LOnu)#?W(8^t)EvST~K=_s{1qtBC2EJ
zd2nS;k<{-r2WZOS0(223A=CG|5bwOg<hQqrzrai2Eu?7`?9s!~y?-kw$wP8BoR1Xi
z=sqV89;I2{P=|u=Wb%@JC=X6k<<#`!xybst4nu?|nLn&9z^-AxuL?Qt05nH_RTMWH
zv+?WPipF=;UJ-_g=TrN_0nA*0%9a554SB3JmX$4svHk+~7>#XMY#+^!W#-k5mkkj{
zXM{oX3ABHUd4wIc4W?jGKf&$!LE~!aJXhd?3@5q7V*qt3<S-!smAxRK7-42{a+zRg
zYvk=Z&D#^FFmt`ye@8YNI|-o+KH{B%xQayau(1Ij_gs1~-mXtlLtTb(GPj3&8c)#t
zbT9NHj`%nbnl%SJPt`wA;y03)D?YgU&M;j{>Z9lfVbh0Nxv;I>{e6NYBlsubi_3u{
z=H|)J<2&h_>J`14nZ$)Z^<R{o=3=N#6V>lJsjPjbU?}6`PsQxJ{4V-I`~~&#|I6tU
z_vIoPECfLfLXgyN98H443<Icb84P?vdE?=uoTOievBAMC=j(?zf17_ajv*a19Ai-(
z)`PuBF1D3L)c3)z;kZj&-zCR3l5$(2pCi*yZmS>2P2>8%D;NI>xot82B6AZUedhtB
z@1!5dJruu_+`-^R4683BcNl(bOyAM4Z>aAW*fpl_IM_?-o63=6oqvg;FW2r+yteqg
z;W(G<4PkGsKyBgo&jaFiE|@xXm{urcG-W6aCOu@}Be0E?J8ifjJy3cYF?D*Nv^Ay&
zN?SucB*CsRJ*2^2QV-&E^4U1Q{(0`7=*Jyl-9x`vzrIvI*VdSRD&ZdA8|7`p^OAzp
zx##y36dlft{;X<|vfS+EXgm+&8Bsy%)}q^2zI|L*xnNcIPDfVTL9RbqlYMF{v*ayy
zh3i%HGPI?qFN9*PTao?FL+8gWG}~$SuJ7^>`CEP5u%{E9o`RI&<#AChr<9*h8n3c%
zp4N@GD2H-nKW&-JFc&+oiWys4_xIZO@Br3@A(MjCqlM2~c-0<^)#~}izt`edzoO5C
zQWd1y59(xWb3&u7(0gE>ez7Jh<vDY*Hy;$DW%03Dv-3r9L4$4|#q+QWlfT;**9+m5
zlOt;l#_!$#bE_}dON2p<f|SMj9;>^ZYhF8Ix=fk-enV>en~{CePQQxUxBUCM1Kx)?
zo9s!)T%Ii1pD*{@p|GylV$#vJXWqQJ1UZH1fE1*%cUI?&3N<b-necM>;~Ui|SIbbS
zpie8^5o2eytZk<AcvSP8UFckY!B|g0>fw!;MGvheRJU^dsIT7d;VbNYM+2rHrL^Gp
z7+Lpc-qFKqJ1gu^3`H441F0aTrDXo{!3pb=Bew1@X`f%PgMI4~_VJMd?Sxkm%C6BF
zD=jO^C!^nH@?Q;YF{j1OxRM!LGa~n9<fGEeVBz?8o!DZW>ZW6}t7?b*I<s5@XG}7C
zBSBaBRYPv|eVAisJaX>g>Ch)sp&(WLZu0)AGrn|LX>i|hreMS*tZ6a%Lw7tlqhKWL
zu=a{`n^}Kgsg?IT%ik;4!;=@3t&O~-y>8}`FXzYL%tV%7CKfI#&uuIF%loPpEzzk$
z;4aKQF}UrTA^Mg>k6%)rdg01=bcz8i{8n33N^%1i7nf=;l$Hq@F#+FxXYOU}dtOLP
z?rF7kgyx><yFdH!cu!lBoOh~iZuTqsL#o16UDoDangza<%jB=PnvjrF>J~V*V~5eF
zUpg&<Jk0&;1s>IpuUe*DGCH}i<FjPg^I7>X`ZZ<gWbX|_bla&t^WJ3p4f6#|KUQ1&
zFVF3Lpl_0m&B5VHMUUCHi4pG?o0EG#fAN2LykND)w9HK_(5Iu}SCF#%@K!F(@4->O
z>6@m{no)QJ`e)&L^o}obF(|hC{Nm2M)hcoGMQ8BwAuIQ81AFJe5%(xQY<&vE%f_(#
z1DH=YqW$83>5ke+ZeKauZ=QvFR5SKXQxMNiN_5uTY;bSfJA#eDp5WzRAvhKs2;K#r
z4^9OKfk_TWfZLPJ_G)M0p2jlP0GS_!?+*XuhT_=_rg(OPDV{@MisvX;91o>~+t<w2
zcC&CVnT|-fr?z}K7{!CP4ou_njo^vkSnvYyCh$`5E-<BUH(0DsZVxWoTbPC4B=x?T
zb4PM;`$PZ7<ly!){-qpfBE<Xb*#5g<+)D!}TFmTjF8ZEsG8o02mjb4Al0R-w+`r_H
z(#`EzV`~|vxR=!b1C-03VD|{z4O|G;1fzPe@4G$$qY2<W1*1yxiomq@`8TjwE^c2M
zTf3w1CDU^m?$Av0u7GKbe^tUCx0j6V(`x8XTUzv8+@W9%_@jGqeslY{m_O2sWPTs#
z!q<a6w_l3YISL=meBF1CCm}r2uLYQ%*)74{!B$*66fU=?iS2c2DBoDPLvzU+2i67~
zOZemV8?m?=`Wppz=yrMZ{oKA_L(ZQeuDSg|Y(AO%k=`h5GP-a_^-~W_`9<I5)d1^*
zX;?b~O!{#IxcxnB-%l29CF}KGE+6)T(Z%sHz!V4SZrCjFVKCJ<G<RWP;9tPh4j%(Y
zg2nnJ{c!th*uI;F>70jprwljLP7DKkarKbqOS%0lY@ZAHBfZOzJq+eLnZLncHQWyY
zj{pw^lUp6IJ$M+{8$29L^67(P!6U(G;8Ea{U?cD)@L2GD@HjBaHV<>4VU^$s;AV(>
zBDf>i9NZI(`OvUI;K|@g;HhA=i9BmCt<z2e2Y_wBOTf0^a4^me4qFPQ_A?6X0Nw(2
z0jGgo!6(6Uz_h=I+EdCmN*lNLgFY|I?puHj05bHwc*@5}FzF=<OnO-cwgxW;dx7bD
z@)RDGe{LTKTUXD*y=3{nhWw=Rn+NUzz7D4LHXls>DSx>=73}@JEZj@h>+^6&_2&Xu
z37o_EqjYe49e5jYodrmy17U}CfZb;>x@BGscpSJEYy(Dj9kv#X>G-;IaQgrnO~(tk
zr|@2bDZDpeN=FHp(t+|VUQcK1>{+-c_sIYmAGo7(8UR)YV|W*)3l0X42cs^8xq%mg
zH-Hy`secOv-v)=_uM`{({sfLBE95K6WLO_C-S-7Yfpx*_!Lz^#V3ZAB5*THIw-Zd|
zY8RN~W_lE@&+=Sxp9M(jaU9%{+$LZRFx<26a8CnM`|J#M0K0%GJX(+7)_d7Ha2D+N
zKx^2O!5LR9Jb7>r+_wZ%8E6eQ1GfcJ{@@H-7A`(T&%Q(69*nf|I)F35O5g%;NAN9h
zC-5DxG8lafuQRv};_L#Z`lSjceRKm0z}>;o;2z+W;GW=pV0G|ea4#^`pFZI8V7yKm
zb{UM<cEWCgu{}HNJ{Vhl!-~Mzav4?(#ul!yZ(wX~3j3)UTLTZHb#N^IGyTLsHf|l2
zt*>U`z8!%4W2OY<ksd$af{nnX;Hltu;1KY8a2B`%OzHjrCcXa-?t*wL!J6PtV6<7h
zDlpn8-XCC7a1GcGTnml?e+83&Lx5XPY_wlMo5k9NpTN{FbOLLFk>9Le=nSTC906`k
zkgXL``I77xy1^aYcL#SNw_wWu9^kQHHSi3uI@lfD3mgVU8E4}%4KT$+cHH_L+s~4P
z`!;|OAafe}COuvSlML6uv%uHEsDr#4;1%GT;6(6kF!~_gT`<}#-ml=_zz@Km!H>Z5
z&{qZ668srVa!`J9Ye{U4DGT?K`8gNvNRD7I$*}-Tax4Oq9HC&6V+ok#2nUlKOTjO}
zQQ&Iua<C%eT>++kV=Wkc1uq#)_4#M;L2x>l<RYDNYal$zCyHAdPzT63p#7$H*%90e
z?8LR_<d0j!VC!WK{kd}f1Yio+O~N0y2Eo=Q8v5&pe4~8t52o?J04^UXK5m_WN9{~Q
zf71|tbJ$M@cLLjR@mb-To6qNYa{gq&;{Y;#a7XF$2lK%JV3Jn|wgb-x3&26(Ibh6d
zFuhUy+&nv*f6v0bWP6A$5G-6Qy|eO*C1Q3K`6#d>++tagg=+|=eDDRh`EfRHo`w5X
zfGa>|BHWQ)%)xxH1(<YV1*Z2)EWv1dc~ihsz*E8AU~4diJss>1o&gR5&jgF}pPS>x
znge72B=f&3)Gh-%jK$e_xjR_wkDI@4)ZYNk-$2eE%66SUZeE(rS2v7L4eltNJ;9WZ
zD2H|axcTHp{SD##4dwi4OZemFf!RE3!}unkd{KF#@fP*hG~N=YkDG^W)Sn^e&xrFk
zhVy5OFt~Y8Ha|-7$x*lfnRcAN_F$?{N?<CB)Ly!Pshx}fQ#+XpRsmy7#6z3S<Z{O~
zH^0c{9kX!X5}+|C8Ps`J-l$!q@Oy)y8y>ZXlfh{7S$UxPwGQ_K!6(2p&iw`+43<Xw
zK;v9GN77vvdvJkFpa}NpZ+YVYA<*#5_}JkXU!xGl0elQrv`|SRff^v)3}ZVKEIx#=
z2jYMtKw}EZIB*(JLI-9A!~rh=Eo;OBoCazD0}Li2fdW8bI&=!G2J!%98^{Wr2IP<l
zkx0vZXY^};G8Ah7*aMM325=vs%GDpR27-ZjAO|Q0TBFkI0j@wKkPZ|8m4K=nbO87Q
zaX=2BfX2Z9a0Oz3EZ_y8fDAJPe1T-30H^^pJTOKFB7t<^J|H(2aRRPDERYBA=D`l|
z1=4^bKnV@mI3O5E2MPfN47SGsLLdz&1X`m3Fa&&oB%lDG0j3sU53B}G1I2(c8VPeC
z1jqnN0d+sP17d+(fF1<&0AC;tcmb#eARRz7a2zNF_(IqLtAQM#5>O9>9k3e60crs4
z`N%UM2`B`VgOC?M43LcI@&Fq6_6KZ%NFW1<Mma137fT~t8T18!JHQJ=et@mP?mz~v
zZNrflVD}D4Ke!x_X^t=f`i_A+5DCz?4AOxdKqf-;U4sz#d4c=jMF<mig+L`h-#SnN
zv;k8<VJXTzn7)6&$2ENeAqNnD2SH92ZUJk+9axQU$H84Bu494I0DU8&5J-Z34LB3r
zS`PXJ`U3_4eK)}#2nOi;3CTbfPyoCDDuMp;kO{B_ayr6)B+`cX+?T-)*OK2_pmSi;
zLXmF#PK}5HKy#T^K&B?_q7WCZqk*_M$cQjb!)-GC4&(p^aB~M-in!9A!Tocj?*-fe
zr2zjW#tuL%a0gI$1v!8)AQLDCG+x6E5C;?ha>XcTfIScfWB^5g!W*Ow2m>;KVt`+Q
z@BkqY3*-VdfcjhL3lIXCKoP(zg*{*hxB~Q`lnmqm#X#$Ks2hMa&}5o4(4>JT4K!(>
zNdrw9_<v6WG7#B~C#6V|yXxCJ{kzZq6S!kfo=`9lM*?Esn}MQ~BgQV6$!$9KukLKW
z|7+*|(f(TTJLmL_N@hAh!`#V0(ogtj%I(pS+!!W$*9iLr{jtSVw6*!~_FK^&FD(Su
zvjy#s5uI%$-Xqp<|BWHsHQZ-J`@zKTl7>mc0n9{zWHkXuR^K1X%Dt&s_gV<sU!(_r
zjTpnhuq4?G!42g#g<V5=tzg$sUV6`xPyPYyu}3A~UcqE~tbfmv(k0$!+n*{Uj0VsS
z=mXqFx(a@fF6>tnDIe}g|DeW9U3%p3t7Lj;uM>G{C_C9J!yb>LklkAl#Kj_+2dd5S
zBaA0NZs!2oAgh8|<K+di{>Sq`yq8Oq4!j+~rQ=`88*!P-<I<~*bhZTs0WnB#(vQ;H
z@XcHoQ6BwOnIm}(5pKi$Xl#EZ+4134RKCo7amka+A9}_nBPs7$WK?-$@?sZ1Q;p=C
z#Q%c44c~A4SL79!{nfG}dCNgmr|B_tGxTdX;RoeOtY0LZ%KpDouU3d#Qm<lNV=4yq
zq5eHsb=-^Wyv?leGKBaAMcQW_2K`4PO{3xFtSAj^pEcF(PO7X8G_w-=FtyX+2b6b`
zZ9zI!Rv1hLFntt(FCzbZF~N;#oj<*2Q<s07K1|`h5yRR7Drc0&#`4V;_LA)zrQH#B
zlKLS3lnzn7!V$dlMHP$ewP4R@ZG8RS$sg&jKioF1Kgsuw>D&#xd|_tA^do*>#84id
zVfq1dsR?w3USlxvFVc_58*RpR^0ahw!z&4J@)zx7{rd={dPyD7`#cJ;6UoZS!v#rs
zCf?_o%gKanVls6Cw}MOsVwrI6gz(=W59yQS5$Ruam<7o(kUR6xv?YFoAvbhMeMuL{
zQ7)3h$#rgEfRHOE_^B~dS5E46@%_7K6t-lUp!h3c=P3O@zn?V;Lj61Tt!}ZPa3;=v
zK2yucv0O0u*)xm#^L3l{tv2mj{olWD)s$+jXk5s~>}j~AF5iIcVa{XPmio~PU}_t4
zz$3sH!6U(!!8FFd0{#G|{*xO&vvD<rN5fHSqsbhDI|>hLU~JzR_Gqzn)Kg&cuLW@9
zR5pGk|7Z$$)JKvjfIDi3Zi4%OZ*l$%am|ex*;tbN(NIepAhQ?ls69;wW7&+iA53x|
z0M7wufW`82V=?Bpq5QFMN8`3l;4a`TU>d{4N%-f+MveO4!THCY0_J}w=YJRHKN?|i
zV-;RGt|@+sF9aat2X~~u`Cv+aFnAbv0eB1;ODAEDU@S9)Ed~Q@f9?`6bj%CG-x+WO
z_#8MAd<nc9d>y<ROk<|CVA2Q0&y5w>7=rHG1MvVEQ@A5}%)um&1$YS93QT2aDi~nj
z40i(C;NAml3r1RaGr;S>cHk7SJ(%|G%>thWJA(7T@Eev7b^+f73&4e7gcVi<o(m><
zwE(W~W_>!{OO_u+xTEeBX<+3Uve)_J`d9WG($HUL&Yudn6Z|9Z>-=&3A?qheKa%l{
zf;;LvF@9s^))1_X3emLAi?WAIY+C0<;qY%-=M}H>{-@V>f3&vyqjlYXWldMSp8Hp8
zxQ6f1<^qL)K{?u6pb#*vKsyFh0eWcIgw(h-nI;W1X`o31O&Vy@K$8ZVG|;4hCJp>A
z(EuK4c@p3M^9i7j_ldsU=jJc4_rl3D0)HGLWbfiH46qNxfBOJ`7kgJhz&xRkFWm~f
z=i3K+3CSP%aPo2;rfrYY&K&TA2fmR<hY>lr;fz`bp8&QE;JbYQD!doIa=Z>$8zKJt
z@Bgvy_BqUVac~miKxyYdA<mTk3E#?d7kJ_XeMwuI4^vlk5_%$Rd`r&(veLoTLV<&q
zlQ)j|Cb>jz#NQ3H!P1UTPyps_@Qp#AKyO!k+|b8c<i==>8RpW}6@TQ0<Qi?H6+GD4
zO<Q-kmL6p<eOqt85|4M1o0oTOCd%}#AeviH1=?W3!cn=UXw8B|4D|N!3luoGv+uz<
z2n`&aynVbEc=-ed@V#-)P=K$KivXWgkyI`|MTk@W0&x7g6HfHQH{e8x{qKha`F^~v
z{QdVhnj;<Jv#RMFSq1nlKte60+}XN~SO>N=$pWJc(0mTfLA8V5n18np7XSN{@Z-G=
z^*TTjc#=Ax^^nC}zAI2AgON<LGCXAbyVETGhy>pmU+NU)orWmt2LHd8`zOdE&O4HO
zJ|}k;CpXQzQeM%VEag?fzgun>Pahn&&&t|Ak+-3qXN&7sb5Sxe$H(Nw@-eR)<mGo}
z_3K}*N&5OC!Tv7)sk|c^o*!HH^hNtITydZ%PM#WmAe~O(WTZXuWF`QlQ)8ef+*pa+
zyP*j}!|6&VA-nnn;wX9t??6va2b^b%rWlQvt3!YQ?Sr=qr!UsfAdCj)yKh<gLm`$@
zZXW&tqVsV1aJ*W9>^z-d#pDy`c_t@cTeu;0wgEapz6_Ck|E@}<ua6!ALI30SrC}MJ
z%jt8REQKPPyCtS3wmal4_%G)<bzL6bII-2k)j@P_>)*A3l)no(d8#;hsIE}{4g#pI
z7yY~S=Mg~CdAK5clCSY{P+!jt;jW<$#pk#ilAthncb7-v<6U2#I%L*T;rb<4>X=9`
z-cJ5Ff32~eo&1v=$LZqFhLuNJM>oW8T@g0E`&U0afF11}z?uXv4;_N!Il6Slnl0?N
zVgZ28m+}kr@JA)!1aUzxEh^K&a3d<`qB2eAHCe%KH1p@;<2@h8+M_pj;Et%GaNYkL
zZjgtoz(EwMXb+fUUAUt9Lv>qMq!(UEx9|7d7*MAUGY%UNsOcOH?nQa8+E9-y8VLo6
z$44R^Qd$}@bvoqZ#~<mC+Rqh`OHzllUx0KgsUNa~Xq=rWZKN|j*fr3#SRJfgdm&0o
zUD_+*UJmVxU@Y2M>314wdjyrUt2=4;eSCcP(h)_cR(DQYcw|~c>flk~hc*`AePknY
zr}u5uiL)VpBrI_1e|UV&H{Fnu<bgJB1yPH_0@G9j<FG&!!NTj&zU#3odM!RKx;>^X
z@8^vgE`vt2t<~{b*GjXGdeozpsdyiGB!%aGD{>9*z)+1rhXv8?!reanQs{VnVedx*
zb*q%jN#n{;29j8K($f}xlfKt|-|6JslmqH}-aDE1_~IQkVUGT?+he`-mmbAA228#!
zT|3K~48Jz4!^BM4`PT-8hfKXzFiW^<ipe^g&O=V+nPE(a1tPxm@@$uu=R$MdEeQUQ
z^C-Pi`P1ny<|j;^1zq#E3Tky{40K~^K<;7(v<iD0s_gwnr>3}t`St51`esMA=ShE@
zB6sY<VvQ|W1f0y`E$~x#{W)%1+2^ufLmg}_N4;wIA>a12itZ%ejw;HTKclkmVeXbH
z%en<s@0$N2_T7bTd$YTr*?viN*X?;nR~6>nax8rlg!NyR-lx(7f8EqCQc=%FW74wM
z!|Xb)zPM!5O#9|xFBfmV^we$_-sfTNUIaVM*PJ+cmwWumtqWGFEOs9{EuhFCYO(cX
z|BOu+bNga_lEu5-`^=JKM+UtvnP>3YC#3hgShomOb*E}S--YL&#d^xxV_Z9q(mN#~
z-!EtLuZt8WMlJUg+`sp#>%w;fc1(25mQq?@JKaYC>zlgdE@ZSIG44o(aOL2M_l#QD
zj+AoUIJC%UyIaqGmaa#t>{|19YoJ8FbXw6To@($!{Rdw&&7B_1v%MJLmJ_hFf7;=a
zSw*%%nZ9`c8H=fWY1Pbvg+12h7%b4q9DK;hq^8}-zIR64+)&YXM)R)DIcu<p*@wxe
z)-}QZOuCYV=eEAr(^{=NobvfzR`$xX6*D)^y4<60>r%LbjC|=070R_?u8+RiO*qre
z*yqyfE&k_RwoD!s;W8uZ_U06g8hm4hh1ct5eB#y(>vdjN99bRIDeh6F)Pco3t2K%G
zHrfxj==_Xw^)oA{t923vd|NTe+GkY$t*@~zPm?1ie!G-=x!d)1W#t1GALxPgVHRGM
zg5#~lUAH^B<&~R#>EG&0vj<D=PjWt66C$ma;PUd!1+>+yT#f&Ii)MSp=PBt!4y`+&
z5-}-bd12^9=bKaB<n7zucgcZrtZ%dMeAeuF<i68#{NjjK&E;=(sW3hn+Dor!(i+)r
z6PAy082mHdLu2j+4(v18?yHHq&PO%A+RKB5ktyxuM=#(1EcE!nt0nyY$8c5}a~FU1
z+S(Sc<}T2@bjW(J(c@Q+CocA!t#01>Qp>Bi(|M0vaQ@6t(qFZ3L5#fWYHy4CnKv@q
z-n7_%J8*o*VY0?M5}tfkb$#~@?~sikcOk;|Ppt+WEg9Z=^RHK`n(x}B=(v5;@!Cvb
zbHmRo9^_yFxsrvqc)k8m!?KM-XQb}9aWO3*cUblIsDx>~K8Kp#-*IbKHR5fB0To|*
z(|~K;qCfSSWLdKJl<9CquQrQU`b{;T9GbB9fu@Pfk`x~Axjwn;6Jrr0uP2OepM3MR
z(ZRc}omblI8n2%H__pV5Ej9J0y>YGwldoF;!22N+XYuk|&i$=Zv%(A6PXvFoRJgh~
zbLhM+xA#|W#QVW4-t?*q)4YZHZ_M6JFFQEK_He|Fv>~@o4AYu(XvS`vLpQhK91+%T
z$UXiRRT@^&ucN!}seH@Lv0-16o@>fId=ip9H~*U4hMPDS2n*JH>Fi#Qe@gT(KQ(at
zpoy1dOUjjQFH^qWJS1_G=I)rN4xiBOUS{QBh|T_$9}R5f&rX`v>0P_pRc6LrNB7CD
z6)vfLUX+^FaVhpnGx_$<IifOReg3(1?S9V44z(T~{pRDsoYd=WE==5d^2W<|>+squ
zb2of#WmTVr-5%M#P@Nqyw7BrK&{*x{+PH)mi;Y`VdYSuSuP<{KWIAo@h(m2+<8G|k
z7Jp!Xl7F?vGTpFyN>RlRFVE~h*A>qUczEDT`~Rw79vNvO6EO9)AjRmnuzto0ms8E6
zUO(8PB~$4*C>{F*bjV$|0Q0WBd%f<QY`xIi(sg0<ny^XzzkV#!kIEg~c}&;%3iPF{
z-FVYAv}}^v)yTDj6_PJH4Eb&Snq0y7jbm5LE!}o>YT0De-53^L+;d(2m(q1l?#u0q
ztx!BZbXKcfwQ43Q`}gVZ>t8fY`T@>OV($1m7Sx_PBJU?`JLB-f0iMgAg|tm5=vNkh
zx<`P|8TH=SbTWaJzlecP5?;++q-Ri&o-dQ%NvhQJMMB>xCzh%u3~m$NQ@R}*eAaH1
z8;nRF>|v)g^`g4m8`bx3ryPyCb6uv{(Qnm8`3al*4M2Tk`l}8Oz3uh6*JP_-WOUtv
zqn8+6EO@kEp{AFt@u)>5W8}kdeiw6Bvvg1B<DGk+FJ0L3WQXp(0u>gPzU%+^S^M-8
zRbNt4hA+Z7O-w%1p3a4G&7}RxT6a(M&`YW*_0O83G5&~di!mi9YJI-?qJLxIwYauV
z->O54+6SHH^3q1xofw$>>oS8{H<xKbojy0VzPp5ei>1SMnfCImRK=?;e{X-I`o*_P
zKmR<ZMNj(^J7;fvaBuSmUzEM>CX{bS543l+d20G?=<4~)ohpXB_OH^}{JOJL#vM)1
z6H42snPV)(-0f_2&ScJ!y$|(T&I@}QH9GN3p~0o~S8epRkC-!~qVvm+*k8fiDcupI
zeQNe$xViPTPfOZwnO-x+uJ`_Ut*y5|Js5kn+6sfzjV!&7Gpmv_Q;)Q<te7#}=;MY3
zj-K<6KCpdju2p)uFsW-I+^u5arT)fq9?MTFYOfb_k+<raT6lIJgVcPxL$|hkSzdc~
zK@$3N=I(}(peAeVnrQ<)2P~D@@k=X}u*z$T7v=gsTG{u_meM`gU{l20z5b)J)9(dO
zpVm$eA93AIz4YaysF8-zzg_!D_3)DZIZ7+>4lk20&0tVs``3F~?Rk*n`jS_@sI_kA
z)1QvElV3h8+P}-m{N5OEk0<>(hfSSqcB#wU>4z%h&kpOZen&g?=e+C{-4qKn=Zy?|
zF$Mdun7i5Q!&J*U9SYpNC2#sSxdpOI@6<fXy*udjDWOx|AH%jqVc!mOR~hTJTRHId
z1aJFhzf0ZkvM~6A{fY6v-+NW!r+H+0X8*M~kHwJUy*sRW<c#dH9_w2x$!6IlO-(m=
zrSp1a%rgV|yFs=es|&ENhxNY`+l<K8E7`Z^%45TGhvYwgO}=*P>cI{7^vyrDTw7S(
z7Hw%4Jn-<Puc@pQ>^9mQqosc1c*fuX?>?Q?QLtAC*Q@#D>u;(v{v-C#GWkNn^)g2_
zTdrPIt2E+Syx|kO=~laossg6FX$C#ouRNzc&iP^Cb=$M+xu(yDxcv)coLXO2(73wi
zkpJ*)Ht~B}wr|r#r4;VQvi3AGEK=#=hw%9h-5i!Lx}6@>?2hu%HHo`~&AVOvIe2^2
z8Jy$6!rSYu!tZ!KXLPyOw}<OG>~5YS7rX9C`iAh6z2@}_?>jaTb8)P_D)SkteC=LB
z#;#V??;Oiz+jwt3WZc&H>~9NBrpCPLs)P1V2OER<(yMA!g7dVF-ZqGS{z>Iox~qGB
zkz>G=vNiJaQgrPm8LFcHW$6{<6?lBr*6EyD+9EFR;7lLs=!%2Ntu}3s@QdjeXOOWK
z=U1@t!I>1<o0bC&n~l^qKQZ>&gOwk=ij$X&Xy=gbF^S*HPX+B?2i9+;v}ybC#v3n}
z2}Whxwg}^u`~+13&!_KZeH?M#eB~p06U32)w@&!XdWB=`?q~~-z*_YqW_l)*4F#2<
zz1^Npy<TE`yaeqPbck`zsmU7(byll}6eLKS4tL5i)jC_dWpCEv?4K9h-&MUQ1@ED-
z@!!fzzwSNx)lPr5?eDvN{S6-+eYhrBHu&^<o2#pnZpdZJU|h%IZDn#$u)3ru@9w9m
zYu(a2E*WsvWw>ncwb(uB%EJZj)|m)Tnc|&d803=rdFs8N1pLvT18;Or9AI_mWVdl&
z^3C;i=RI8f3(l@(`dg*DA=kO%=V4>NDo#qfvt;MZz|voDjT_jF*KgIv$X|yeFXpg*
zFx2l@(c~)^2j*|ie!cGX)>AdouMhLDttgIO6tc5zMKa|3ot2kaP6bB;EXtSm*J@$P
zD=z3Vy8W#L_1r^eWRH|SKc=}+3(YvoUzz4QhqgKPws3g0rF+OBgLCR<JMAmmyYhOE
z7nZX^zphck_n4S`uZJc3)hw?1dOp8!L(jajnVFwwe(hl5apd5H>e(+Nyr8=wY#ec^
zZHL86s-hx3548F!jIp!{uo|G27~In$P5)Hy=ugE5a4sIpUuV^3Q_|7~hwE&}*)v;N
zf8fHGv#ZZ6T6urj!O&>Gnn_k@uUNh8-c9eu!hL09PJNI*Th=Q6$#Au?JlAn&ZoL~n
z-Al)MOcnOmv2^UYA$K-XcIRdVBlWxcpJ}b-Ta3TmtKW6aTW#9)(2X4FjB~Ki_VT44
zye)7kS08y(t#oM2Pfj-vbecM2|0$`&HsKB@n!Wne=>_&JvUGggUbgn-vAy9XpSN|}
z*LLF>t@%>Lp(DalN2|wK#BWk{!oE@#@0%$`SLZlKeLa73pI=qUx!8kG^8!~{-nppp
z#KSJab_T}9v=Nanec|Jj@(=TQ`?spxIesKTP3EZGgqrg9Ix^*>f;*a&m!mw(vU+(V
z?YXnpNk#XqTkhA~vzt|2dHVgDqJ&>x6o=1GFuf_*h5TjlnjO-J%j|b!>dUI?z*mn{
zW{s|1m^j?R>gmwQMG=!Gtb*<|S-kpJ4F)Gl?N>_4ws^PZ_k*nu1g^EHtVz5v|6Zqo
zDsBG=#lA@9uH^L_#b+~`m8pD+Oq(&dSBhy{PkpVj>cjzN@_iK#MF(NNgte!0PtGqn
zRqDL>;iHs&eYGa-7*zQ-VW*%re2=_+RCmLfQW)<tck!R!{C4FR`w*RO%fHQxd+vPn
z+oQ><L*@6ySI%?Jc$g3Q0+43DblKe#0o8|$%5N5qKK<cMzE|$&#Tt1(^@x8UUv<*9
zX5T%OQ<fj$a$iTwZ*`Qi9Cq{Y!!a|LM!dN{{E2qZ+ZGk!8rxb#<)U7)c(>Mue=#w#
z`sm?u;ncyso4$-#8lt8;M)%e8t!cA)C5g~+Z^X@)HkM5(%Bk$yIjv2{u}ep*B*gSt
zbYcFuE`5R{PsxmUHWBT?NJVmYVov(P2}>u>vAfiL=Q6v_YtQQ2xa#yDE(qG1S7u%D
z(;J-Y$MQ|>Xp4+wdFM@i`dxihqhny%F|qa2E3F(<w)yoN^v&uQ<k<rq3a^NF{&iX3
zjh)|jcQ?M|l>fytT<Kx)-K4YqH4{CZ-i$54zC)Id)!9m=TkYPioMqY0!maO+WxJ!?
ze5(?pqT>gJZ>^HfkH@|%mT!TsWuIn!lY8I6L2Ihg>upKbqE{~1!wa<z>^bI2=<Foa
z%NiE1?S>g`&hGJw=``=&={d3Ho4zbwJLl(4&v!hi4$iC9d4WmL11vvYRyF&ek^JJ|
z!^3j1linCi)PGqp<!$%W0qYze%J#hY?mqOw+BMmWiaHOA&p5|e^D;l*9P9q}_Agxu
zrk&K8m=k1Ov$tRdzTeH{TY01C@^1Y}GoSSu?KkI3zqbBsN|sd(S&{$d?$R8)PIlfH
zCo*@R3N}QBMW`jr;a8j3>Tj}}u}WB}Ho-D^==54)RPVcZ3FakpH||WAUzA^KoorQP
zTsdL9&axeHpYKjMZr?Y;H%P91&9^Y@Nygj-Upn#hy|OiK`R~JmD}Fkfvommh%K233
z<VBx~6PwT3GBXV0mkxU5&f>*Shi_RJ-?(_&{^b$Vp+_fb*KQlWDa7s9Y4V?LAOGTy
z{*AS}#<J(kl4NvS7j>GGmw3A-D*ySQ1=pivGCc3@Thsi+I62INvUu<MukSeRm20OG
z;ZfNKsq@~yGE7`NZ+XS}kn3+v4x7a*;heT%6z^PxH|17#E4*~P;=JalZrr{k!;#<q
zh09>e&*uu1HJ5eAK4cbNZs9idEvFB(jEQ`!$p0|iF(vTwrUhHHR4t{J<e0~-v&LRk
z=I;E<^>bc&hbFyx_{o0are(oTO^kNzd$6<Z^3f@~*M)aSI#QUs?!P22bIs|zKGrW}
z{jR9Cn}t{PRhEu?=%Z7)=bM|>ki|Inj=7s0djGU;`+HlqUCn!YJpW+ki2in+TK+Ne
z@yIp3x-H6?gECsl+_jc78GU+Y&$ML&Z9H}i(t50PePm{`y!4BjJ;OC^Vh5nTSD8TR
zO-=OO-G6!FWt&LPF=o8T@F_>8PU~v=UUqsXy&kJ$4nDxXeOAw1F7-_7Q_<|)WT|aC
zKOGyl|IX6uZtv8Co4pw^>-5}(PiZ{F!izhqd9ixT`pv4HOFw2Ger1%Y`$dLtU6JB_
zrnb#nztWv}USRGb&g2E3+1GKDrctV<o+H1@(7i`rc=7#Wua<A@UAd?)o(GpPcg3sv
z{G{|W^J>@)-@t|6#@HDx>KoND!T-a=O%tE3IP6e~??5qk4%2<B<a~AB2WBmhk1%{Y
zDC=eaEJvq%5#NIL3>r2hBo1qytp9!TY)PN?CtmkYU1?~l9WYh;=DbHea`);#PEUPw
zRn5(~FU}2O_2|?=vpl<{`hB9TEV3Uvg*Dst?Bs8`3*M_do*a=gc*mh7c%Oj9+t*~h
zZTp3R2bbS!>t1V+TU^~fz_{qmo}dkBPQ5OkoO&MfX6(5!DzC#kUyaSJe*F@%{>!S(
z5q2h($4~3ceK$yR?)JR1hImf?#KJq=D!ZqjqWsFXzM&gWdGS^#E?e|KH@<UF%=4c2
zbr<+z9;Ew3%C~sO(|49fzJHVdw!lV^Gfm^kuDdFef*<?tFF5d$C)4o?hF2)lm<MTf
z-Tcx)etzM|!e(b4|N6%M$?PZg_7mQx@_jWm1E(#-{3+AR<+;aGTvUdP$~crzHu2%j
zi=Ss5G8j;~O>KRU+t>ScqtRa7VD;mu+F|oEX=8Q<cr5>Yb;4V#`7c$<m0je<?Cf*)
z%z7DFv>W4@eAzQ*ymisc_z>Ff+6ec6>ly)P?z+Wz7$$7={<5*~P&Vr2fi5K9;6lG|
zsR@CjLUi^G`uY6aEzV0OUs-JS_~sQ}E31<~AA-AktUci63QvUZR3G@_?fGtV-^}&+
zb+516fQZ)btM}a~iP|oW@qs6c_ie$)t!}bwO45hj-BdPVwbo^~Qv-WM|CYJiIo+pl
zaUKuvDX?+QtfGf8SHtZ49`8M@AiIs`VugeyH&c7h2)}l8zvA)yH+Vjp%<^r`{0<J4
zQihlAO_0AC@LM0B_b28KI3YV?=3$>+t;Y}jvK8Y$7M|~Z#ooLT)<T2hHxsm8tvOm)
zGx6!Up3+J>!w$K<I@x_Ao*T6(y_YQ3eDP_%<jH9n;hFjNW%|E`KA+I9`<0tpW(4&3
zaPtMmbZV;Pu1ZbVdsp+1PlwDdRSOuGv~j4`^u%)u9Rq$zeaFu@Htitx`Lg^d9(UQ_
zb4-BO=W)hITqYMvJ=>mF7HU(%Ul;UACHefJ^?2`u>1FMK&!;*^eT*#DvUV{Wt6ei~
z?_ICBmpcMX`WTd^SE<azIFadj!92CzVOwHkS45uZY&{@+^=qS;TZ*j|6E~huy%61R
z)=NC+F?Y&Wr^x(dvwrF6Veu{3PMe|h$UZPg)^6jBPNOfKHl8uf5$~TccOQz@N2-qc
zI!JlRYw4tq&Uvq_uSUFDtvxI*!~4>b?MdjP-?R3m>znJ{e?Rmhe@}?OAvE2wlgG{C
zP}Pk`CRccko?P0|qZs`W({siYnNQ)9x-JSy?VH)vXhXq^AhinTtV6fezQmr}Y;_Rx
zaHm*$gKO>ll9Te{RTXE?`w($dzuS=%Q(fhq<F}so(my!p1Nzn7On)!u1-wr`y!Xfq
z=WbilR3nZ(_4{aZAZPXdgTucTZ4baRJ1>akTY1`)^t09qGk0z4GEaVKvyhz9+)W?!
zm3wS*GOR6IkqkEvSiGmI^oQTNKXgp@Z`D;rhr`rT6r4(&KAY88RV{QYUY&|(lwF-E
ze~;w}o3GMawN_E~NQ}u7%jXe$4+oX^{<`vo_m&jDsGWOp&MOP={^uRMiw_3v(s93j
z#Wgy$LiU%4j{T3$(n@#hE!DZJ#w)zDk2wy^*D2c;^yV#l`Lk+y)&QNMZ%e%_E_E<a
z-W<AW_1B2Ol`)t{V(wns+dow|^nILvGIv9pJ9(QgjBMMZwmMhcBum%K>P_Tw)T3?`
zo{71s@tEmFDz0mTp5Oi$bS32sZ)*0!pHBJTR*T#|A;1UE0mwVPwA`8azV>gvJ-n(s
zt^KYe%9*}>GJ4o#ZcrGb^**;pHO*o2(01^pwXEA7nYDMp<&<l2&11Emnzmi`i`lWb
zX5%&1r0oh*dE6D>t!L$>=*td=v7N`b^m=@5f|o_lzH8rYmuvCf?49SP{RyS7+eF~p
zR`#4XtXAfv?%o@Q=EnzqJF$D2_Akx0`p9mR>T#fC^7@aJ>eV<?>?ex1<NVspwugH?
z{iwa-(V)8njV_;3uXxqt#UA_qOD6dL6pQg%Ak#~QxmSGjD`AbflY+sJi@w&!+8<6&
zU0<f@Ts+&zVR$NZvV*xB-F<P{AGdrrEH}&Drpb@ZyYPE--$VDaw|vSME-kr5d7;hZ
zdlUJrMR@JV*9N~$$VdoGu(LcU{rTS9V8;Qw(l=-yo>a->J!Iq95x-xvUOIOC$}=Ng
z_nB2xY<~1NC*x$TX|V>jgP$GQJ9in@Q`qy7$%*MYpDTp5Uc(2^^G`Hsd#qW;nb!Lz
z@;cY%%3BT2UL^Xagcj7z?diceCs>P?{r=seNiw2$i_F2D@Vf>01DO1A`(W5!k%s<k
z;7%THY{4DCGbH?Rdr2Dgx194A&G}ow`7=cr++GeIiV>5u1sFp*W)^V%7J`*wvk0sL
z4h8oCF9xH^@s@x|eiR+?UJH89if7gQ`*#Qt29qCEkDWb^u)<J0>fXsBdANNLY<~p#
zmy`#?0_I;6OzH0jMsvg)04A9SfsMh?W1T*^eGBYeyoUP3_hZ5k1uqbcrieG6O9$lx
zw|{^qjcbyFSREjPVi-n@VQ5%0Fkd1*Zk?a)m1!7X1j48MTMCA(yhtv-G+c9Q?Q9L6
z;=@p`?p-|;=P(o@_HG{Oe=_cocI+t;oq=o(w!!^0up1cH>>a`x;0w4%bIi_Qb_JK=
z9&W;L-ZY)r5r*?ldG27Gi%&;rvNO5^!P&T<55~FK>|I6L6R-gHl+R%Rx2Db3x=CKr
zpAaB}N2)LxFq(E&zR`uVv(8aISpJ|nVrSnY&)8Y682W^v>hKJ~XmY8kV(&bT0YAmP
zF_`2v0n?iLcyJ-&46%offaAa&pd3(`g}G9|8V~|8Kn73%SkK0|9P9~>1e5@6ARagl
z+yP1f83&A00WH83um^;|Y9JXn4cq}r0U1Z+KVSe@1HM2sKxeqdgEN5wpcIgEf^2{x
zU=6qf(Lg$o2UG$|&X5U+{}plrxxfo#SSeWfKElIqdSGi{HBb<QwD2G=GDjOQ2i$=W
zARagk+yQC;rG<zeFb8~r7$6<U14;ooWI~}Xu7MhWHkD`qwtz1X4a5Oyz-izPPzuNm
zN16b8KnNs5o;;uc*HwVBKJ){)0;_>c-~~W)7Y2YU5DjDi_W>CL$O%{jAwUw41C#=-
zN5T)_4nzYPbUzCBKrBEnY}x~1Kr)aEC>TOMz#WJMvVc-R*$DQ4ClCW<07Zbp7}x`@
zKrE026az|Q5f|VI!~<DCAy5OTj>B(&JrDxK1E+yPpaxJyAvOT)fe;`bI1Lm6RIt?n
zQy>?hHHI3%3I$yV!~i)!C7^^x(h<l6?gRbJ;16&GLV#GH5U2t86OazT5eNg4fGnU0
zr~;HH;&;Fmhz62@ET9xnqCOO`1ww#iAQvbF6ehvF6v6={&pFnDy%pdItOnA7T%ZV$
zu|Qb@OaXU*K1ve@WB|E95l{oDS|VP+9Pk8UfK1>HPzuOdAsoOIa0Q})bRZXa0n`9V
zXc%jNv}W)Fs7pf!fUPak0we)hKoKA}1N9s*2ZTU8a2hBE6lS8X0rmiWoFNmq570}`
z+JG(K3&aC?Kqa7Hk9-EKi5EdeU^P$>0vST#9;jT5{9J;tWe`pnbO5dar-j#_yGv*8
z(pkHA0P*>{#gC!K7I3>1c3{0ogbfy-pKFSHIzN}r%T<p;xL_+Votx_jrn7VD%v{N{
za;p%g_7lW|-`&A<UM`)LOXuXuEQ73IK3EF~rr+fuCvY5y#yxFhrt@%v0d=G!8BAy1
z7Q=lGn9jUaUJn029NZf`h28<vB7_5!1O0zPSU@3Q_zd{~G@1X522eeC-@b8iDd4*t
zQn&`wzP0vUG426-b;FnkO#3SNKo3A{WN=OUaa#bgfE*wXv;<lKtpVBx9*i((uX|g7
z_7E!ov;nO>&;g)0l)xPU+NVf+PHEqy1;*W-!74xo#_C<bssQbOBjW>qzJMR#4+H>0
zAP|@j1Oejs7vOp!um}hNLV?A=5+Do+2O@x_KqNqMM}e0C%YkTs_STVEp&;5jM|<UH
zA0X|QR75)0Vqm%+*a*Y|n}E&079bAT4kQ3cz-}NJNCox+biVXK;4p9$I0l>m&H(3t
z^FR)88Mp#m1!%t{8QSM4hxl6p@<3aF_V^y}BHCZv2KV+zk0US(m;<;03b4Nezw{h*
zA1DR{ux|zX0B{h{4%a2He+RV2HRToC*Q|uG9^#nI$v|?*z^(-#)(^$M67I($9GUiz
z5$FPRhMS8BZx#Hmmhc~g>#f{<B6ufv{WEwEcTMqR;QENf{YhM(<?b(nbGhql;OpFV
zTgciD5SyE@zr+3Z0Q`u%eg=NYT}!E=4gg})8rSV4?%N?9G{+}4pW*Kh&M(=uhuaPk
z?v-%eQR2QM{Qe~2pI)5kz{#ir`z{i{b;mWIyYGlNI!VMc6xTZ3eJA)==EBg0-Ehv{
z7;MU2n}H{A*Av0!+_eSRio0%xFl4xJC@r$MmgDZN;bt1=ZU)$%yLJW(xNA?aH+N0`
zg}4sl?pq<8He6UsU>C{RQ=Lmg8YQs@_j`eTKsrG0)Q~~f#GZFe!C62aPz=bR4Wm7{
zrvW)MaQKE1`!;7D_&)Fg_&@BO4_r;z`u}%MR3t@45{`r<gd&7Ogi?s2=zog-9CcDC
zPANhNArzq$LdgFzn9z_EA%un~BrzdV@%udcoJ@oH*>kV^y>st9>*ej)XYaN5TI*SB
z@Ah76J<qBHig+hb1N44i49tNoz?vpZG)M)<K>?@)viSQ(wjAWA(F|Av0f++RPd^>x
zfg(^1a+=^;_<Ku#k5%dKD9{Clz#2FLFHrBxAOYK{AREx%-%6l}zq8uF2#~LOA&3TX
zfc^#-fMQS!V3xt?gN$Y<iz4a-cmN@w#p|L$0w@5E&5<?;0^uM5q=Mrh3lxKLPz_X-
z@b?=S0b3vhksuMA0Y#t;$hJTkfi5ruu7Gu(g8MuQ#DNr$0q9v%4r&2C6I6i~um=JV
z1rk6S$O1*65-6gb@PQr}32cD?Q2R*)<g+0Ulz>V=3wc@tTR?562$X|rAd9x93^af?
z7zyYZ=>dd51mZwC$UsL$IZ$hZxF86mfa5?z4Y~xuAhs>a24vNdG{^(g!J!L`fHLlV
znipaP&VWilokZ3k9K--sJTL75{k@3=x*hQwc!4xf3@S<T5w{cc2JAr;$N)J&Q4{F^
zFAxl}y5Jn3)fH_7*n%jK0djzcHuMb&Knc+3j`TqeC;~w`$S<e_)bXO*3;F@kAg4FV
ztA{!P#-N(E`(PUs=%bE-t^vvqN`Nvt2KXQks187$0DXIvfGVIj0(k~ez-ScG29cl&
z=#9p8f&Eyd4d|Pu7T+t@=Ex6-2Idy18*m)Z_d_-)1d3KT7gzzciIBh%#DYQ~I|=y#
zBSA2T0x{MoGoa3u0$b<>-vzqB5R3#?z#e!2TYMXs*+GI>kPhe>O7BwPko5jE9+KV_
zmO|1y)f`BA*AYO{dyx+$y(a}gc7_avr2RB!n%;*NNF;J34N?tAH6Yc1R0C2C{KFc+
zYbrD2cmMxf?f;zwtnI&-Z=k2|m)8HnAfdOftJvv3uHVq_|9^|Uf4yzLAES&nSiJwr
z(Es>u28}^e@C)AE(rg>p_J8hvV9+4f04FbrSAv;dzRpfwMxH)GSn#_#`OI|lgV8^0
zb}2p&wwF%xa9P&QlH`}+cY9BH9K3+^8`^c(`%b3sAPSCv>L0Huj11l@&eZ4CiR?W+
zeLRJpurQtP=HO1XDNff6alaB+f5BwmiB}ZnJ)16jlDKUCWZ%hCDTj`-k@iT$xgkyq
z<8mr0eEbdo@U6|p^FW*|&<*=4CGqImcr9gae12{0Bm3KW`bz49zUe5m22@5AkMU@S
z_rIx<`VhdMvA9^QKIz(D32eFO+EqCCpJ3<sceh{UYKOTS-vNByx9uFc+VeHSw*a4K
zwDj((=S2_OsqD&77<uEtW2GxAF3ArbX6I(zt;3>b7tvUZ+fuy$A$v&N7+mZex!TqJ
z-R&W1Oped{ww+@iw!Qp)?Hsw<b^hJ$935Ca8x$Qoddo5{DRAf>gIBAQZaLW7h;*M=
z+Sk=|Txf9q^%?GVj+=&2{eIhi@!w^aNMpX35Bg2JKd$zgT<tLbUG|XQ+kTO&T_RUI
zOs?}Xx!M~>v+eoY_S;<Nho54v_x<b*pR?Edw!I-&yTrERsXhPa+a-=+%dzgr?K|C)
zo5b#T>3{wDj%yKfj*MKWcsB8_=HNTMo4@zfM;{*gAi3DPes4QRu6A%9Z2rD&Kl{Dy
zCb`<r{;%0res8<U?``ME+0KmpyZUW=NU5FUf2N(ImN7lozHPtA)!x;bz23L&9KW~y
z;&^mW@Oj_1*Zgm>bNpYkU*u}n`QKu{$kpD^n#NRl|M~WYT<uerVBD9_`?g);_qPB1
z-u8=sce_NccAZ@97rEMNa<y~xWZ&DRc8-4+J4a2-<>2$Ac8>pQJIC*BzsS{YQflWY
zwR3D}=O`K9WXC=8Ft3n?-LwFOEKJFwvC#97G#+{Z@-?I*kc>65+hjkcfPFO0iUOv@
ziD=9Y*P$tROczKRSHyUrXgDOs>S(GLqXTIJsSAneS6Kg)5z$yCrlWnb|C5aOvEzW0
zPQ(1QL_A7I6_UmWe}IfaoIkT4Bipfhn=$Jdm|F+Pj_mJlKPG&Exr?_jf2<I5?A$Rg
z%^CC8ur0MA!@R;F7^4UOYc^#67dB#l7ke<WRr|lT{VGP94Q=E8%qH#6Y*@dS?N|w(
zXa5SjF|rr?E4E^P#ZD{=&#MxkSb>MKG)Ofd)qqq3QVmEoAk~0W15yo0H6Yc%chdl-
zS^vTQKb@|O&Jda_eGVNlG%x%#B+cojxz|J%pt<GQ;Ae0N<bbPy?9lTduYp-O&kOi~
z>-c>O6oT8}4j|k4o2_79i0yme0T==M$6`pDJO2=rfG40n(79xjc@o#mN5@SL<Tc2K
zw&E1`zrkMo?_w+7&?cOV-S_8q;|=Y*8`_X_wGVITBOn^>rQSclKVmCR{fNfE6$n5u
zhy)D2*A;;p&;okE9C!dB5P>LA0O;GEY#GS5TniWjdmsW)AQq&9JkZeATpOK_hM)x4
zqvJ6eB!CP+cH?9-u7>Y*ZD0=4089@UU0?)k<#26~1qwj4Jo-^VIj9AB)QO6YR`SO}
z9j<BM3{Ztp%1B@h3V;UsY0ZEwC<hwNkp>U|vI9>esf4(o1ZcECen2pY0y%)55xT$#
zknMFEAe-wdpoaU=90Y?XppA}IM<4(xK(!6h1|C2bHq+*SY^S3D`HLVQ3mU){&w^->
z0dfHO<j4T@tZ~#ty@BH(8wfh%xd2juy%zEh(tuHK90TNVEkh4=2AgCxps$bgK@hO&
zk86QgkOP<jC>|&@gdE5)d=NYc`T)#e>;ol3QGU#cG6L1W+8AvL#DO9pZ-R7y84v;T
zFBLl+`T?>dP{xrs7np-MkOPW98K?r}^h^<`0r^o#1IUlY^?)nr4!zSelI}HnR+FCw
zdR9w=R0C2CNHrkUfK&rg4M;U0)qqq3|33}L;-LFqxBqu_^PesBWqkm6JB!z!|I!VB
zr@yze^E~0-+7CcWMoUG!sC9ig=o3my#Rdy;`v&^MK3z*?6jm8_brNFrVEP=>QZX4m
z<{NR$RmewKf61EA^o>a2Fu*4dvmdn6#dn1gYl|M_z$!{OPvGX@g+r`8x-D&d8Q3*|
zX{}^O96N{ieM=dEm#>SbkGn5?&0)U>_6Gpi{nOIk>^=b`ZClE?csu#eX7>es+Bcis
zS8uz22;WkcG7h+=Lx2E<c0)X}f3LTzkCv203;XfONj|U{J(PuMA-1b$i{j+v6W}c_
zhc*s<C9rn&^=l9}%rB+YUt+^gzS$_y<?%_%`U4n<A9`P;^}F8wYI>wgeCB<j%Z6nR
zm*nH~G7J8g4*~ge{`0lsS$9~h?)8w~pOsmWZb*dB%bf5<TL0QI2TAfV1bLx)CLK{d
z7dOm@vzL?4Y;l?C_*cTGdN#(vKPxlSSbQcvb=i8RxNJS6BSVH^#J2~V*6(HhtLfFR
zFaG&G)3BbsB>DKfo}(M)W2T>zz~i5<=PF5BpV#x5FVgzG%>RnE?TCIQ3Y`GeGrC>G
z_p?d^-Om=^(En`PE|a7McXDh!lb+dn{xU7L(Emt!T<&LU^qo;q15{>oS+Qjn{4pOs
zxSjvu`?>ykStUtpIj%*|un0h9j{ZC?l$gqEi{oDjpY9_^9Bg<WQF+lEzj%Jt`%C%O
z^W2dXfbe<!8@Fs&{{la_rTK?-QU5$Ilce=|{R_TK>t9>{)KB`AGN=799|1lt|9qK?
zBx!wK=Hf5Y`j?j34E?}gD>J`UgL?LIb8<zbf8@Sv_#DlVr1g23tv*jn(&n|rS^NC|
zPi_A5zn5I@aYOWTQ~2Up-Y^g1X8jMBx4vDUk)-v-v;2#+*ed>q(&JKQUB$1LnNe*}
z#{#xl|3i6b_->XiN$c}6>wS^dzqZVLdZ;3N{`?X&%!km=$<yl}Z`bwpoFYl<^LCx^
zMOy!wGFPFT<b&#auUX`V@d!Teg?7qrx2hR6ZS=d}JHB)A;NnwJZBynSo*b6kXK3ib
zb$RglZ9?%3Kdv}&I{3Hvc}}{AM%R8E5d18$myLT~!~#)3ibg<e5qzk#*Xz`>{jr}7
zo4i?YeYg^{Yn`@B@4-rS2HvZi>2%YIxVt<V<HmTo<nuhPg|B4x_tWlu$Stx(sQc?9
zMUGeIcfISTWtEg}F|q<<#9Vzw{oQ?EarJ3+V?60)j%%9@cTOk|o0%Sx-|hC6djtBn
zaB}`F%H`_1r9)5dUF3|v`K+EF@Os@^-y>Yb&_>&0Nojw()=}pdt)FJ!SoC<|h6@ku
zc3@12jrTv~(`qE?PqTfzUuLT6c(2XfucS0veJJVO%`<10pMEuM-Smr{x+|9Bds3O=
zt$n3dCvv^}(Qa&J3sc_<Q5*e!blEszXqd~?GuJmHY1cB$-`%GbS6@(EeP7A6CcP}3
zpSZQ7W~jvtm+?W<^(HD`znI#zrLb(WZpquFyVbKUV_pWU=fAIyEUrGw{_Z}qs@dm(
zrZ8OX*h0fC>b(aZyL3~x+U#bH`$)SE8*P6Peo(RPj`8Y?MpSQoZT2mHV`Qsv+G2W}
z7cJ^mj4^FLtlQZ-;i9@n#mOnH7c&f3-%`H#Am`#si>nW+f0xg#f0yqo?|!5|v(C;%
z@{M?NDik|z^E6DTE%!S!QG4{^0ZoQKJ5lHRLBKG5EGeGhMB&x+m~I!&P8fcE?HHM1
z18d@EUaxd9x@F^Jvox!GHU9Xs&#OwK!Kr;b?Nle7*OGs#@$&h^qY(vHWE&m*SYwhK
zzoAD@%yVGt?b|-axccVe>T`>$ZzQfhin#jR;_7>d*45(kzMn5Gu0FDKF<;}q!AI8j
z_G#tDw)@TNlZW3L7~`(;R;I6E(@WKle+@oARIT6i69<FFTrmwmr}_8xRrSB-gDQg6
z^X;+4u7mIO;j8zqYoj0f!|;tCXIHde)uAjiM1Q!etjAT%(PZE6mtVNG=i~>wK{ITB
z-6`-hzJ2u0%0#)Kj5Riwq7tskpOwX$N$h)jvrz}!qMjA!+;}@_m3wOIMLkcu43rDH
z9J4!BZJ?Wnbvo7nX50OW0c*3JTfgf+;)9AsO2MM-`2pp(u8r)~f$6bgUHGkmm^<~o
zeOf8wnta~3eN}PwWhC`!^`Gg}imNXuEn{jg-}Ze)bNu+cZ~L_3>{AW%2>HBF`47Vs
zHaW^z_Rl|bXZW<mVNVMO-q#O&-sDxN_U0xL*|^`>bT`$7z8_^`^~TfXr&9;^tbadv
zaj>Sw@BvRAZAzKJJllpjivKM>t+@Jl`d{;X#nm^`e~a&{@9n#Zt1m6CzFF1B(*2vf
zO|VmU>9&hD;a->*5FR@5@TAG@&0fk)X=B(aD*C`}_`hK9bC(O9Q@Xus^y37X&D-A|
z8@aDw@fG(MT0xDT4xXMdYyJZ`qZq+nFZQU;`I_NtHfXdhe{=TG6O;4-?`8ScuabN+
z>zY5GQ@$PR@3Ha1GIN45_qHCYW0I_6=*Vx^Z_m*ZZ~mN^OO@-oRxRj`?**<tvbg$q
z`rf{;^4W59AGOA|<@|sHORp(;)EQ-$)wJ|CEq=N?aBYfHm-8nlox{3+__pQqB63>2
z5NK~`cI$ocn)fR<gxQU%I-X%T>qT#!SzB^W8{@n7EqlE~&CYh7qoS}}Nf5H`lsB_X
zWyylu1LE2SMnCFYIAEUO80IXDW1r)W83jwjUp~!!o@e8hHCg-qjvMM0LH7jv^7cQ*
z(qKP}*Y$(1=4MySFC5_K77ZzClzH#gQ~Ucf?%UgseVNP`=;#DYo{#nJFc+N9yEyB3
zl8buZp=k%>E5_Z)KmTs}L8G2kn>E)2x_>CN8-{l)u0E|sv-y+ywEDaFwBqU`x-TXr
z@OkrQYjzcFjFwv#exj{)&(Nq+ljv(I%~ZCnJD2=ZWRK~O8D<h2Pwmn~*&l4yEY9d3
z*L2n7sj7GF0|Mpj)=h0Q>_Ud=)X9#pIbh?xE?yI^G4w-kwMC`8gg4GPPpmJ6J&Drq
zADiZLVbPWZ{M~=aK402Dz0&d5gC)7UgWViLQXSiP=9h(NtUEm6mG`g-<*hx-&@TY{
z1wJorqU_sHi}nkGle?$4H(8rk5~%sg`OLxVn(t$N++cOU1@G-_`wObGo0FK36Q`jv
zWA^K?qk}pe{#X07;_8Fyd;7kU`n3Ab^l3%Dr0{B7KaY-`Usu^!y#9_p_EUHO^BbCT
zR}9$|61N|j0x_kKG!O47Bwa@jNanDyW5#qH9(K|AF$HwfiD>$QA0*9r^KWpTWIh@@
zXY2FxW+NUA8+t=_gY;=|o@D;mSJT6v6*j$KNJ=lH!FiIoU|&rSb3@ql0wF2Apa$nj
z=58@Gr|a{4Vwi|cFA)-t9VV&4d3xeGNo11r#d-0FN9EfFX$+ar;5^B^sjrqV9Pvn>
zOCYIyOB<XgnFICJ@-0F<N-q?W$`{t)JVrdHh8+w3ynN^aVbhxcse$t*HaJgDavqKA
zetsTaDcJPPA*n4`G&oN(Ux=MY^!a)Dh)3nS4%rH_KyscLwk30anB~}}^O``S>z)l4
z5Rb~24N3XLYlvthWDcY+WG-X`<W<P}b}N~y^VM=sMLf!f9VA`PzQK8tc{j}0%59B!
zl#eNpRBoFF=Sk+td^J7%`C!v?gQWD_8=NPZ^YYd7W*{D==LkvZIW;&>GDqdB=^aEo
zDj&L=*z}GxI8QR)<g4lJMLbFm&j2>P0}alL7SG#YC?B8K>ng;f^r9iD-L7eH-Wkbx
zx?eeO8RAiTD<G-eMm0E3GC$+1>BS-*rMDT9(%aJDJjq;(uihu?5RcMZ4@v25XmFln
zZp2shnTdFm-Wf=$zq1X_lgxAYsy^{r&8Bw}lJs^8(hLpz&-`2cnU6j4t4DtJ>V50g
z``i1w``9DDdi6f`$iJR;1#CjW*Zk~-V}A<Jm<KylU=BP$Fo**gpa9eYRs12)1?E5i
zqCqOi0p&n`0qjNxU>no|WjwsKfh`b#NDvEBKn5rP<v@NQ{&oU;AOwl1GdyFMJZx73
zwLy3$0ap+O(m@Fz+gBst3L-%oC<L-b$S1G{!5{%-fpVaTKR8Cf1N^W0+jBI74nZN%
z9RoXF;0l644EVqB$47qfia|rabbl8geShX3@Bi9wU%lVGGQ9jnEx`Q{jK4`CxR*d=
zQ#_j%qFv)9#84LP8R&~}e?g{!T5P9;;%^4FW$}024CK)>0P`v0uw4M^{qYrJzbu}Q
z;W$>i80`SthT%vPvIJBCGyIm9LmGhQESs;!4f+!2U|TB!X+l~-W<WYZ=0Mg04Lrbg
zfe|RcetSsr)t3m)09spKb_vpe<U{I#p!<lUfcyhmR~`l~tRI0ONG+5n5i%W=A#N6A
z0Z?0tbAcA}BmifCY$dJ<1Rx41zd~Ms5M+QNpn(?`TMz|OK{hA@vcKY7U<7P|5JZDi
zAPrItNHrkUfK&rg4M;U0)qqq3QVmEo@Xu?Y5iarZqvSfu3^M`Who>PQgY6pVZ-mSP
z`QQeq4?A#d1TY2lArae2pb{Nbuc)(15|XjcQw84^kbA&9Fdqbig&-7!gQZ|OppXi=
z4;%n#;1Hltiab08tMPj+SPz!rcNEx&?M;9}IexzYF98Lz`yGIeIkLSx*ACZ2e#oBr
zEVh3J+2As`1WtluAOoBNXTXmjA6x}D!F6yNWP)6f18##`;3C+oi86p{Y|FMsS+Gs>
zclSdc0B4a;bC803>;Yr2y#>Sr3gaPZ-t81H6--8)DZmEQ2iiXp)Pc_6HFyIkXhV{Z
zF!IsX8}tPfK0-FaHDo~($+bpdpDDJ-NPdsSZv~(VtdWl?z!vC%zCZ``02KN`8h`;{
zpk&`v$T`4Y^4kv59!v)_fD>>9dvN_b;323Fsn|Bcv7vy%Oh`{KTk^XZbeRVI9Ry_C
zN+An6Zi~7kp9)8?o%934B!gX`C9bE8Z|t9NKKZ6p?!YiAU;&PiY=L79{R`6d8u}P)
z=vVT4`;^RYh3{xU;Wp%5$@W9Y$C7Os<eMicJH;d4cr6<IZlNlkr$EOjkWbBbIQKWn
z`LwSk;<u8V^LOznIR^O~E6L+HNOQ?{Ltm4PP<Q0lu0AyM9m&NHC0GBF4gFKnJw^8e
zwL`imNs^yQdVbLTKy5b#I&a8s{N4lhf>c1hKPZ@iNKgn$Kqauk^ECnFfFeM?L4v>;
zPz7Ys@1zQhKy_pEhctn1fIaX4LLdTJpa9hO70IICM-^y+JoM|Rq7O$4=m8^O4#+N7
zu^IYbfHn{S5r_r}AQc=3){5w_0;%9QC;{Xj(g>IVTi^l0K{QAJ8K4kU0c9n`2WG$#
z1cMlm2C@P9l&l46Es#Gzz9n6O2*iSPKt3kR03SN1XP6<NXPqPP0O2436aWphd2L__
zMuHen1j<1*FlvcBfJhJvMxw3N`>Z^J?Ho`G^igk)ARMHDGawHXgGykJXGRQ21nD3P
znB#d945C0R$OCkbX#sj(8UuRH3jqDS%LB#02+uKBa0cXoVo(XH@Juqp-%eX_1}O4T
z=O7$Jg9MNPazG)_>V&vJ01`nFC<oObTocy@#h@G<?*a*GfqYk-3$j2hQ0#`^zzCQF
z4-gDuKngexia;5t0<zjDCm0E=K{$x&j=X^~Pz}s<(6&J&C<jJ8aBbkBi)(@cPy!Nq
zBA=iZDE2~rfpTxuJ%|QpKpxQ2Lt4NUlmOj6xF*O0a8Sc218WctVo3HwzCku%^idzc
z5ePsUC;`d_NC$XeOe6+m1M>S>0%(lH2zY^Dpf(uyFK`60fW|z`fGwy3G{)ftf<cNg
z$^#Tl5N9~rHb?~-KsW;1AOl#9hK@iAI1Xr>APU3*^D!ttNC3LlI0ghDbu#n|<fq^q
zTcizSr{Wk$1sR~w9%)a<y#az|Ku4e!C_12wK+6#-0gBG3LtqUeK?cYHF|LrH2&lT@
zI1qtoa0XNZd3We<Cdv$gfz@p21*Cv<a0cXnLQn!KK`oH?!ZiUO=mJA966kv)Up|mP
z2%^DYWz?H4!wiR{cQ<+tkfi4_?H?-nZ7z}Y&P2z@OC<THrQary6n}_B4wJ|Oko4YQ
zA^AN*A}uA-3X;w@mPmRxqTlo^A~_C{u4^ihqa~95hS2dblHZIpNHrkUfK&s2GY!Zh
zKQsQi|34=I>-!ImHGJ%yyj}b2f5rQso14V*-yp_Fg>l5+Ab46*XG#Q(B~qTT@O1I>
z_4job^0g;+=UWPdp5C7GJ$+{KNBDXRJiXlfm?n(5N?Zr}^WH**R7bwqDVRaZLymx?
zdDVJ&8O5f96L}+aauGVX1hPI()Y#ac|HuF2TZWHA0RX=70x1^xq$4Tb$6k#Q`?e9M
zpD0Ox3*u1v8vv!B7x7v8{(m)noPh9W>GzWO#G|o$3Vc9y*AC<({e&gr^j+Y?$Io5B
zmL0D!Ukhy6$)5}#N5$pz7di<8{3&unKRz*%w4i=Q5wr!fHBr|3w0wPpe!gCYn0E3_
ze=?Mw9^#49^KlDw5&C)IH<g$2Dc;YzBK$)h>U{ueAr9pMuf%K~n5B~Pit~UHfB!tx
z>%89opE}YYowo+*XeD}*Jh%(|-2C0dzM}q7o%fQoZ#Ds3-xTeP+LtjTwJ$44S{{Ma
zvc+ZP-nPZ<_>XN%+}<1d^ogUwA>b90)wLz$Eu>u;Db_X0=-~31zQ0voV_f5Fb&l8D
zKh!zpjp|q&*VoH+MBpFVfnsAEM4<YoY*JlNyLVhB$s5~(*=E40?f;(EAKQMt&rXdd
zNB}_<`loi+0+QN(v^YH%UvF<;pL%WJ4)}B5ZH|&>O=A_;<!oNH%*Xe^*9omREB530
zHT`(txOl(#o}jq;pY}mNs8YHH>1|}g{m>ij`@_A4ed>&&3f&`TP#7NL>NI~+fI#5u
zCv<Za=i~Q#5cj6!+SE3NO4_BF9HquEqXDVL7*G%>DA9BGbA4#JdwL1AkO|TY<>kwu
z97alL$uw3;6JLY$LSJg^zIngzqp!O^=xV&oAD<ufx*9L@rLM-yd|g-U{?By9UiUBP
zijChuS5?R-^-b);_aC1ZWf0%<<1!0t-=VqJKE${@NDLeI@j~{+4p&xJRQ6i9zY}-=
zN3YoH^{<mXIbhFKWAo#^K7M_^K3DrJuJ-g??V8pMrSi((`xsF!dex(~$ADA0mK$P3
z9}*tv$ltjie0EmuW%;%F=vQasEj{bf^v95_7xRK%XWdP$QhS^6-u%R<hk=*<tOA=A
z42KS{;lab_4c?XYXsg18q7y%~+w|z<^MRM<3QnIeTIJHG_lq{xPsVISpImE-H|oR`
zgLkilb>0K}%=X(hO6gdmv`odl<CwN}*$P&DXszmB*>tBn<sJ1OU%6OUuZbB`me+1r
z%WLsk*#|S_4wpYVrn3%>l&jsi!7xg9MV)$3j^5GhMv;%+sy|G1^~f!D^q*L<Qek$|
z06Pon_nF1U+kI93bhzC14az23H}*Z$Tg4wg`g)fhS9Gp5Z_#N$_z-9G*|PBluBxi;
zHowDN+Y*f#Vg1UAN`<DHCs)PBM~`2(Nxh5t9E?-2@t#gJxir%`;={T8y>q^9m;Ean
zZ_GjM*z_J(Cq1sN33zf>efqGP`P&ALw|dZTLUEYI*cDK;mNAv%``JA&WUu#aJLOb1
zUesCD@=bQnmru8BG2Xp<-z7UE+y&L!A|m5@hi<Co<;LM}4;$}B|C%9F&sKC=qo^u(
z#x7w}s?igJ(&f<)jTCMK+P<mD!x#_S4sJisbE(uClCN3bFZu_k{QYevP2G1&W?S=6
zhZBvSylqp$;H8nu`_r3=m9OVA`!=Z;96ubdDSOmzY;9#r1KG-<L9ItsR^tBcY(?=d
zW;gTMwc69~$Yghm(GQe1X&=5ftNmI#zZ;P!$L$GMcEI&aD4w3R(&6cQ=3Pv>9NRcX
z?}3@pk|Se|#WotPy)tEoNc~=W?tasB*!&H;WYlMy%s$nmv*TZ^{Plq1{(x2Et7^Ah
zoqMxQFLkBgLh$Uxix{8xZGT=9*!<<qQ7(NKySd_B#jOwrTg#zOTD;D+%}^g;A!x0x
zmc9$m{{?KkEk2oxjvek@`fRpQsc&%C7cuT(8d^>@a|H9xJ&f^^Lw^!i|7BeLNO1Mn
z#?`Lf9&MV>8`pgBS;J?0SN?p@_{W0^Z$2bmzIN%r+M9#S-!@%URHKAB%q!V=DaCIY
zji7OZZhuHOce*{>_PoD)mj7bilta&^7uyD=3-G*R<8|y{cy<2Xis7eT^G;VZi@QHi
za|Gi$GV|Jt(Nnw)tcO=)Ou&HB?ci_TzH67#wu#pBeJow)N3IlE=ze%pF(@LtPut<`
z<6dFB1ApE4ys%#P<Dbl0U}%(=nk$>zMyA}XB)<E^6N@$D`!o;j%xeK#AvWH({RVOM
zYqTF934C6kqB$Rv;{%2U8|>}9>)fo3&Wk4eyl~9D{GXX-Rws8Ilt;VgQ@jGZp9bhO
zO}*su_;ybFjhWHmu5Fy<)(u(tYV5;31%}O#w?k}s`CI4JojR;AN2oOQ(4C%MOCAO*
z#pm^?h|B2Y@0+RBbsxiU_1{y#mN&(y_qLX$yPNI4o#pzNsac>npl!z6qb(Gc_K);y
zcQUst#>m)oi<xt!72Vghec92&^nz3Fd&^MOJ7qT#PV4Gy^KyDR0?&hXcv0f>E~_th
z+i9{PT2Jfh@w7fYU%WkSplq)kYFPVL;Adtq`VIOb+3VS^o!b2LZtv(evu|e1j4@yT
ze&MQ_yV^Y3db=hlr_P|HIm7hCdnTW!k)Aid)2b|^c?Riy4myphZ84;K!QlM0uewid
z+}=5Br47bG*>pSX-tkDs_jT;Pd9qH57nQXy?LO!?aI;O^?xro9w^J`~i7{Y2WB9zs
z)s0?jCzc$zb4WhM;;GTNL67q$KJS>^bG73gxz6Wb6ymvozae~HwWhG^j>c~u^qo<z
z=|3`IT|d1k+kTwy=zk>n1wZZB<O2*djZJrtk2=5gxvXK8-XHI*Znd*<l6=hSpHtU{
zp6oKaOKA5I+wfk`mP1i~)Ub?col}<dvhm#7TkoFgl_BYg3cQlq-2-)OVtVdpn8j?o
zS;|i<t?ZV08+gZh&(v7AWl@?Vzh#L_AIo<?=Beo{>BulU*?5m<`@c**wCC_t=MEcF
zG{TNOnDfSFe^%7K0|P%4Z}E>lFaCbv^NwmBGS5sIzTMw*>90}o&#mS@R<BfZksrRj
z+v&_TvU2F_t!A%RHu9pM*KmLDcOy*?yG$sOdAKE~BE;qye|6wn^~7@r*FZ1$;N<gG
z?SFTwZN!`KGCgaTF(dSAC-1r89s78z|EO+8<*C)`(=eBTjkj`cD~Bo>;|n*(D&+hB
z(#`kfiCH~Q$PJ!$$hV8)=zi}vVGaTtFL;>Sw%Eh3gv<MkyJ^zIc8HAYx_-qbTiiSM
zuyj3KZHM<}u6F3f?Dd|u52>)wycE8wk8<L9hrYk8S()uNdfkX+v&uIgom4RaZGfwv
zh9N3c-V-xZ=Z{@HVW!=Mj@y^mwOw_3kd3Q>?m)M|O*s|TuYP!n^##~=(Bj9XlXM#o
zcK0;iHOcX{*=oDlhn~o|^y-`NDkUMPu<i=_Qt-0>@32!&X45Txztv$x+u<%<?)^B{
zdwl2at6pr8Z}M`?3$OM2;>$~$hvB)wmgB<smG6BUFS?&0E6kj0Uoq&HkVj*Cbo@Dg
z<5d4nuk%arA##(w9+NFR5xQNgSIP5p9cDe9<#}t5z`bXf;>()7SD!^};o<MT+(0Vt
z)s#oh-X~Q&Hf=1dy=gbSrYhs*%HsH2C1s&=<IVEjc3|9rjpuhu**rXal&t@xQnw_N
zUqn4jl`kfbi736jQBStYv3DxIIoWs>zWvlL-;7V&(X8f$W2IbkpDhPXl}u0nGVf$^
z^po}mcwalo#*@#C>u&$_<DE-tlUwdMtd=h5me$E8eXa6vy_eaYYIY39d=@sI=Fui;
zi3-l^yY;yAq}IU5vh_B_2R}D+P~SYKNAHhTNAOP93V*x!yrkwzZ>~P|b{T6@v3a8~
zPIZo3wVT(27t`MiK4-rCF3oos$i{QlXf!b;rBA5A+N|9()CTpM|9D1C=7QygOAdrY
z&Z)Jq!rTfro?xF!S7xxa(CB!6yxx<QM~iAdx4U1(#+zPzC;F1ezWed6{qxQ?*IB3>
zzbHSs>(tQ8NB5~5&wYyLGgtd^uKpIu)`*LL9IpPEtl8@Y3tK+0>V5RtK*bHWey(o3
zV~2|4mi5Q$(uIwU-z~eHm5cE*Hr~fA6{{W}+Y|ci-R2H^mDXkI&6Oz&87xX3rWHFr
zZoP&R!%*G9Kg6K@FZ+(0&g3?o^-G&ZML(Ur@Ag|$<x6|g`_0~XeP7i&?*2cx+VOWX
zqI5_9x>2X4%A=&zz6V$DR}ZsDTUr!y-Z_8b)119qx-Z&aDIS~T^J0276Fm=6^Lc7e
zTh_$<%9Uq>#vI;~!+SGP{@70owKvY=?td$mP1jWJ$1w@A0~Cwf%*@$#y*48EQSW(I
zBBRs1ZtPvz_{2!OM{xB+8H2we$X|;_mTu7*i!WGonLKk_o8im{k-M*9a&TeysoT;8
zTk+ocj!oAsC(rYPzCqjM@+Pr42d4S*B3~U)Yqow%*qrDdu|{c|Fb;{1N_-ERo0$%u
zQmpQ}D)7<uH-SGVWipe_&i~<*-*wIKEo1$C(RajtPiH2{<y-bLZZt&S{KSaMx0k>6
zE=ycAxP?Qirv<;u9Cf^}>9g^khCgf)S~sNB=$El+@d5F6mIrw6Zq5pF?71U#t^Og4
zDm)L^c&mjEt(Q5*?2H`m8BnKnc#Pqw3C3<!Azj@cOuF*S^!PLUonhmB+izMR`~0g+
znV5RoT6x-z&Fy9@EN&E>Ri3^6^&quQ>z$12DwZW8&TD*v$jf}{`)2#Z&+w?v1@AV1
z!aYW8&v_pbua>O+y9VSF{O$r-3Q7GiWsqpjtUWwFLl|UNGy(EC<P6Ai$eEBYAcc?>
zkRgySA(um<xrt&R-$G_XRzu=eV%|gMLDoRtfkeJUMUWpLkq71@B+_PNWEjz}kc}bR
zqf985s2ijLWOvABko_PPAq^mvAdMkgLedyOD@f8u0+95@ldUX6`oN!0hVn*1h<Ngl
z0g$ARKuC4Sd61-!`H;OJ7eL~%%mhQ?Gk^(!w18X)IR$bNq!XkFau#GLWB_Cs<U+{B
zkjo&$A@K-cmO^fTgbf~>Ph)IL`s^7#wke;DAyKVtKplu=u{917ub_-MBwihv@sRBx
zEg`AAdO*@2&(=F#2mcr?Kw%Z);njs%4cQhly1{vpK6Ezj=jSC#&P#&CZOZJDoQFTT
z_5I##A1s|m`P2mzHluv>dkZ9`y92T{<UUBsFSS=mUpCvvP3L#O{`&TcI%n%g7n16y
zFC^6u>Rv=;(ueE~i8jF2Pk+df_&op;x?v0<r$P>dbb%ZM=>s_!G6>QLG6Hf4By>XK
zN1~q~(cdom8FCclWk@r~8<1llZ$XZO`~}h+@)6{C$O_0wknK>WDUe+uZ6LKFr$Y9D
zoCZnl)*cdRGBY5l-8w*$KCFPGf1T}jCw<6aAC-y13Fw{lm<ib)@+_nd<T*(ES!T{d
z8bKoOB1_0ikaS(DCrRHp+h_iHJwb;eswaGUiRk{orx2@Wyn?gmAICmPUpLzaPUov)
zUn-#Bf_RiKw0+SeNKESxIYN3vdP4d_&V`%<N$uVrG653%L}*LQJjlb43m{4Fc$SE+
zLE_#K6+nhU-i5^LAp4wH3|Wcas5>@)OCam;dnsfS=yN$F_0g}89OvVhq;Hz-v!?vx
zFk1!)W)b4ia|rk27dEjejqtn!S~$lM<bZI*O$0fBY&{#=c-l7pqkX4r6FfISLt9RL
zR4UnRl8t6V`%H5@jL0_g3<y`i+!;`Be@V8N^>&x_HkTT2P`AJuc!5Ze2r@tcr~-;_
zaX$iSkZRyt8bCAu!~B0d7nojnAkf&_V?6kafTyN-?CU<Z9{?H?EP<pk&|e^FE<KG=
z-o^G4a0fgD|G)XWl&@yWSQ80QP=ahB*;avUCE0ERsV3QOIOmqO8_v7kf<GcOPk;hF
zmoxzVEj0)Bzzfhl90yWCHYfy@pcdf0f}!U&p8Jd|2m%FAjxO$fTi^l64q60K0j=4d
zh5Me5`&<vCfoj0oYvaBpTk%+6)(p=95C>8~I-vDpazF+$nu<T}G<UWZs40o{K)P&#
zGShgYoJ5kYNZ&LspY%_<qT@VBsw>hNou@33q<h*g4N?tAH6Yc1R0C2CNHrkUfK&rg
z4M;U0)qqq3QVoy>@EOZE|8w*IeSC$U{S5nmX#wEk=IPbT*LfDD^F3?;bR=`&b@5$J
z;XJ<4@!8B|LLM-{yeK_(ek~=-&O41{V}0=-J0DjGb7Z4&$OKr*1TplR`b@>Y{n$CQ
zeEjar9uEkDVD}kAiuZ}<n$lcbGwf>xa2+4Fnc{eQpW-=vI@jvcz5qXLve)x~6rbzo
z79^l~t~?d$pE!duQGdOKxJ>N)S6lo(h;mxWI5>L>{n3Rgp08hjP8H6fv4M_#SUr52
zGfVSz{_GrW=<)}gbE?5P$Od!xE9cOB;3^ywpf7~$82zv4l;-n_o*Xvy*w9(?VfUMT
z%17t#H?5t1<Z73+$)!OtZt5WqyP;oJjpCg;Feb-t@t|%IR^!j!a}qV$@$lp?+4Eki
z-<uGY)o1I$Mcmgu_}*&)TtVLwpO@OY=yrMHg^VBWzfmY?J~uDn^6PkCpUv%Jih_y@
z_vX()UoQH+xQuCXovZP^=Zqz@^^tb(L2Tj9D_ZW0E)2DJ{$NC#(K#peL{k>FD%7g7
zXgqWp{3!IJa?}XtMJs4T`HU}2znZR;KYri!fYGh{%b9MCzyD6d^~Fc@H?#2;t{K$N
zxME$usmWWfo=@@5?q9PdB7Sn0cOhnlTd(b?arypp!MM)x;yNdb>l~^R6G$%=zqH%C
z-f{n~Zkl%s%$Kal=-#yIV29nmD%muS>Tf?lKOf^?cqs6B%dZw++&Rc%+QTlx=FEKG
zL&<ODvnADim*qaau{g`FjU5K29<%XAX0|(`R;qWhS+Qx=*wF?{w#vV|G4{B9_b@@A
ze9PL8BJo&nCGI`RGmd@s(QmrnO8^CBbWhUrur*{?NZi*VW5_m;^qj%-L_`k_^o_D(
zwrJ9#E%?oc+zr_Yaz7-x6-7TnYC&Fv#I@KlFx;l12l(9`@;68wNQ~DqJs{;EdqS#0
z_JV8+*$0xwywF5M7+0hISdj}P9xWn_uQKSK6s>{8bSY61q#@)1$ia~GOdkq~E>hMn
zC5?rcSL25?NHrkUfK&rg4M;U0)qqq3QVsl58lX?<hW`KPTW~*K(CB-58op)HAnBX4
zKG1Lao}@tA^qolIua3>@;T&@i4$go)P!6>4-iJ9}te-5Jn-dEXK^n*a+2A-boq})B
z<DeR-q7#G0yD87oAk~0W15yo0H6Yc1R0C2CNHrkUfK&rg4M;U0)qqq3UupoK&deyu
z_`kQO&ulk8A2%<17eArDeE|Nq_xE$LZ|LkV$XjTSA$@m0H;LarcY(j3WRRc6`0+W;
ze#?tfQi6>b`TP5$pFayHc>Uv>`1`wgJClz;3VsZ%++6})8IGA?+=AS&IHA3-zrE1c
z*UR62u8X~yufNb16A{D?3BA4g>-RFXHDyo)rdO|q*>&>wrZj(mPb@y9@`pxDBStI8
z)k)~&KhGQEU5YA!*sm8r`yCwo+?>3O_51a6Zy0dAKAvI2crIVY>noYJKz$h$FqFjx
zk~E*+YL~=^8T_k}I_V&dwb%Qf%aNQ1lLt1Cr1Pdp&U1J1@^i;NI;TD@S?bt9Ks1Kx
zm?WKJEIDW9pQL3jIS*YwY#>SJ`P8T7=i^ET$ZuDaWS^g#Fu)IEnf3Dn5^%hn9VbnD
zdoEyW?#)iyOg#E6FT8m@YuAcLbxw7+pDmnFXp-WD0mY6JX`FO^=C)Nj%36(P?Tc+R
zV}A9jYq?Pt)}pBoALZxkKkqslaje*QqkLNm9nN*T)kb!fpzYv$I?W#jYwaG|d!gv3
zep!=lHnoA>7#lBs^~$8S>&KfmYTd*;G;oCSt-ROE*4_<1*t71E?x?-9E5+lfg~+F#
zxD3p6Y*WBA1lGoj^ab+{5y>Wytj;0nIO>hH!GsA1Ya59%N)aFXTS_G6bBMI?8|R2H
zR?3dY>Of+wmbKlZ@mI35fjyr{ACksl4I!ax(GW;JB*s43@l}#EzB&q07ZSt8>^Q3x
zB#pD8xD2i(Lea?<RAdj?7ZPbOK^UBk2FF1$s0PX~meVGKIcbn;K&k<$2BaF0YCx(1
zsRpDPkZM4xf&V!Td_MjU_Y>^LB7O7GM<Xl$WS>0t)AtY`;M;@sIbsZH1#AJ$Ih6*f
z2BaF0YCx(1sRpDPkZM4x0jUP08jxy0ssX76q#F45Yk<av-Ty`Q|6ZQX-VSble!h|k
z0^h?2K>hk$$0b9UOOgLJAPiiCL8%}_JeKa_<mKhy?IiR-`Z&b;1E4;MuLQ~ZT;jF3
zgot1%Bb+C2``tcYypJsiYqKvv903M}EoFS1ye091u+M}&*U4`t3}4AFfT-a<49e0P
zUXh>nVbpxClNWxnaibwSgZgy{J0LC}znd!4KDQtjH!O~b6~}0f0(P@w?Smw1bJ<G9
z?1w@pWd94_w@d+a!CxrW#qVdk`8Z+51r6ZSx?F~Ip)bQHeHi0d0I-yC_i~!)&*qcH
zpBv_r%EZS$v5wey4g&n9xd8no^B&}>ks-iGGV3SU6Y?hVm$pcpKMyA#S1&hlOQCp_
zw=&xJGMGTM7=It6k_TxCr_rS6N^Fbk!=0@V%2PG=iSy(uaPf6TEs6EaAZ>B}q5J?h
z_I!El`@G(jKkfUy>}sF({oWS%*k^)kTgv=i@7fLbq2Af`*gl=>gNR~X8sogrbxHaa
zUk_^v26$1n&~A7t_Ne0mp4cZurC4uld$PjuLg?~q{vGHXS?HeTvUGrDII_Uz#S!v2
zdyb!*3%04Q8rIiwOnjgKAJ%Mr&4#>#_z9t3))&n?`A@4aW90es`ueo*|5IOIYx{Jb
z_}o9%mm>5Y4n5MdsaUMHPxV#wC-p_=q~jc_bj7f5*H`^qA8Pv)h6C!qr8y+`kVf?4
zKh&3x6XxhpU8&*tSHh?Jo{xhK?-9D6<gxE-?J@)T^+NipIDS~19$QZQWbS{ZoYc<h
z^Q|pMu~<I=>{^$Y-@-h=Ih9}J+nsa1#m_78y-oS1M~^YEl=)-*2$5$kq~8+9WW{U8
ze#&?8pX9p=apix2FKcByTX_{XPWaaxG^xxl8kX_;X|8wnyM@|0KXi(_tx$c^ws!AL
z?!G{VphEaOx$`OpcgixIqpg|rcljeco?k!GE^qQlgK=4b*0p=`ro#RW4Uo@!o3}Px
z6s8$JlV3B+cF=mesVjt4nqw^!`%S46Ms&S_$wJ?IeX!nRDBT-=Yg$i!;@ak!@TlDF
z<k>Hu7;jrRd+Dol!B?J-Iy5E@4Ip+j#ryU;4GYka_`L78-q>X}e-lCqGX}K0xpDKQ
zoae`L52O#)wQJM#w;}h2tnAWZLDoz(0<P;msE?)mC2te#)LpvmqD{Eh@G(qy=)}X5
zCbu_xDL18!VW+6*1GnKD95))D_w98byxHr8W#$BB?rl9($0S+D(2?J+-=3o--uyW+
zmnzqFty<81HN$XSH;wB$5=+>0%T{#zLG?lUCDBzu!2FNH?MxPQk7yn5_j=s=aSxXr
zazLa0$kxZk_HE@x4ZPgH)wp!IxtDu~22Z-2H(j`5;;7X&ZTp_efsVPZqsY~lPggv!
z_&ig&q~ffq_H9#|w;r*0n0kD4w*^1V9oep1Q1~g?!4JnJ!GALw@B6Lm#&w;?UZ#}4
z)asum`v?a;9rI#J#ew0rhr+I=^u2zfzuwG)Q+L`N%-@VPFIYVvYIe5s92JG-N`jDe
zr@WbEDoYmJ9uU_yF#1vF!U6LH$GEQt*>N1D8|Ro&ur&PT)7<BIHf~vyweRn^p>7d$
zPp~g<|6@kB_0Qbbr~BUPMmoXHmd|0mJ1yLEd=BeNa`h!;&0a6=-P2!wK4Kqi&|&Gv
zX|a!-kAA#6L8G6--ngpS&S`gY(N-3+@xHwd<tbLrL3MU>5)*RbG*o8HejRpnP=~`w
zW&_l=kKT07d(eU2ukk`1&6YRz(E$GY^40eX<@d(CQaRpldb1sMnxm5T?H#mNw|FuS
z&jYUO?CoevdO4OOY`ns7#VQrK!_lMeTRsZgb11N~>xbnfJ{yzfL~P%~eVx7E*m4xU
z+sd53-Ft_D$CaO5Ba>gr9SLi#dvv;9s(V+Nw(Yf_a9=;~d#{Vfb-lZE{B7m)TF<RZ
zS31<?!5jT$cYELHWpeS9)~hF-N_N}pE*k6iLrfgLNz5tUD|7F-$S1;Db0=k^zUKwj
z$66jrO<q%><6Jhw#9?4ECe?CXpKdFAy<r^}R{VBNuy*N~?9Dp-n4F(}jqHA~@a)F7
zxx&TIu4yCA2=+dYJ*soQX84*78g0wpoIUi!Bz?epS-$nFB%jQ>=FjJpZ~ynLJI8h1
zpl6t9%;y<Dw$bRf*!`w=#KOsEx}+``=%#dPX{C3@C>5iR(f3D3;N1v+)8PZG*%k8(
z2l%-~Ly8(@-n;eG{{D>n_V#06Ci4Y4IsudC<NbC3#rwZs?~dzwhFsU3vt{2SvWqrr
zZOqu;G&=mb3jg&K$E1LZ>*sCM)3B6Tlw}^h+WPOm?i|;3BWb;W@3}7HV)lC9UN@5K
z`i=jt_4By;+~c~=9@q6;&Die>+a>x-&m^l{YWi!-t2HGbFYMYivq@+B6WeF3yM1%R
zYk?8I#Z{=@2LF25dhv+S%QFX;cAH*YW`6V+C(}f|$uUN@eI6d(GiwRMxQ(EAFSJv3
zyH(AoX`|o$-tnD_2N$1;YMV0u@Z_-MK0`wfuFK=@n~&>yfn3*@3}f@xsb%|PKN~iA
zv*7x0C1%$;ZI|AImFf(<S2xq?rWJ8_c{2JvSRaGmULTh0I)#(a@x|w<U79HSgUy=7
z8U5p$u9`em^{#zDpq$;hscnW`$S|Ec*^&D?vcc^2UKg(k*BJVtx7wmoUcwvaoF~?o
z!k$Fw_m55Uxv*$U!a(lp!*X3mk*m)_>3WNAkB!_{u=tAm3$36=PX|xWm^J?aKK%dg
z>n(Ei)yZ{TMy~6mb6vlY>w4;3*EQ$5ek0d)8Jmuz`+Q=2?wqU*w-zXmi&*OAR(SJC
z`}r?=ZXM@(Rz`JA-4tIubGiDc-Nk<IM;XNT{J6}*+IMK~wGS~a4-&)1eY}u;vBQ<s
z6_vdf?(f8X9o|dq^*pYHuVnW3)9!u9EwV+Z`|Be`j#uV)z3ZlBm6UEVvI5Wg&U`Az
zx7X!<#a^#}o$Sd0d#)OrAMf??#Lgx9M;dMNmD?=SY5%hcYu;38)xiHJjLP`D`wtg&
zYk8tnH+i|SnZExdUjFR6owD}~x|f=K_mZZ&X?MKuvhl)2;i`9Dht75A;IMST_0+&d
z1!{{|ZrdSj+~NGLpe+%Z_&dYKyEyB3l8buZp=k%>E5_Z)KmTs}L8G2kn>E)2x_>CN
z8-_lHHEcZjdmkgpMX!3a_84#~*K$LQ=tIII9r-)=gU`;&y)3^rAK$fXyrpMdn*JD)
z^<rMo>#Vz}RcdcD-kYBo^)T?VpH*P90(|B%57_VX+Qqv=?rq=wXz~1}CtG#w5}-W4
z{Dtnlhb>c2RKHJ38n^&!<+Y~rjyf^L;N2@>o%g^#v;DS>QaaWsEmLvtIHqk~wt`ik
zvxsLfjN+}RQxD3~J9^zH^3hxMhpDa}xy6qD6Dw9K%uX6$XJHJ(x=n1nfvc*jyUp)#
z*S17sMp(bHqEex$=E+sD@zLYgZBp-IJ_r4x?04Doyf>TN<yJmR?SEr^#n>pli|(g-
zb&C8YeW!D(Z_&aWlq1!c(v3Q+TE5Bd`SR(OEylZd@4IAYgu9@6TSR1B@6b)vyj*<u
z++yS1=wCBr>e-4;YZO)G&e$bPN;P_7P`W(&p^?IkK-)Jp_<PRP_iP4xfAs3rZGzp0
zQCbFXH2Ip34-|zbwNMzgbl<~};|DH1<Ljc|f~${Ou0DgQBbm?BvsOAheb2m$Nta_A
z$LKvUQ(AIl%(2);qqSG2>=3EnYY#uPY&^q{D^8pa{w;o<lkTC>wI2rrKTGUo<DM6>
zKopRo5fEF%-3Kv!!|{1%)ok;+GD{xs(x^Ps)1cq;a_{jMS{bQr2w4&JA*@eTG{cN#
z<CWUmKhQE3+{-<gy|#Hl&W4|cD0Ql<$<`WmX22M$r{PP*Hlza7pJdFD)*@ur@oNU@
z3Mh1eEhdct=s@DLi?!v%t;O1MqFaHr<wP~Gww#k7$(GX%QV-G}vJYf1Bwm3;VUYTe
zuOU&*_2YXCjr-C1fs{@bpnz8r))z2dJ6N05!H~EHsh+hl#r?zDlHwJNUDp)166+%v
zMHl%Yo&{tG<ao$MkXDfB>SCrqCPLak9)PrkJP0`rlG?Hh<Sj^)pIt9=CS*B&Lr<)a
z;JJ`0$ZsH|1|&WoMKoTC+m9_*G~!Ce1=;aJDpw2a3kMX=Bc3kgB}ik)%aBtcuRvmW
zgSi741bG*786=vAC?4`2B<1%3<YUN(kTsBxAjvmz38Wb$j)|-xOCf2TvJ8^+P5F|H
zf3f3YpXUq5*?g^sG)CMFkkAnm3+V;90}^Ftc0y7+feuAD#w0<atA|O3EQZ9k=q==4
zNXkzt<XFgkkXU1sK^a6e9+w75`7#EQaUOR3hw{}J`_N9<a2W9vuyq8oGvrao0g%Ta
zhd>^OtiO(A+=bd4+nyR;XCdO@(u@fI&@I4(LUx4=gQWUc3|R$9^@OsqHq?>GXZEk?
zA0V);+z9KM0wMU?8k^OKCy$G$0a{~I8?xa#n}+z^aIH-<`VC5u(K1x<KeO&;43zY(
zwKqMGRyarjS(Gkd-T-NkYCx(1sRpDPkZM4x0jUP08jxy0ssX76q#BTF;BT%0e2V|U
z|3CFLrKyPLVbVN-yZ!O)4(h{gY|~ueQpquz%Sz!8<YABwj({xiGq?mUgB)-L<bwKe
z6x*l30gwhx016q9yFd!amh8)fOa=SEe#ySmlHVsKzkh_J>l~E)J_AYD*e&^e7V<he
z;`Tu9mFznQ`IBUu@_Zg#02d|ujzQ8~X$qU67n)c56lJHi4`_ZXg&UAGpZ$?!Kh4Lc
za2=B7;TL0n9wgZ(+{1PgW%0azaV&;W!S7a}KD5EMn&daFYarX;7|m%(1Qg`3UtV&o
z8Dw+Gwi09u$@X7em%$L%wFWVu5TO5yQAOVkt;=8x>_Gx(xE@0Re)G|gXkA7_Kz%$`
zfaag)0Sz9*m;qZ54QSnlY)}Xo^z$eKBVZ2fK_rL;XFwh(2J-0RQ3J-n3Iu^jK=Y-u
zKqX+Bpx+c21DX>p0;wPa<bY}*FNeNKbY#VVM34qDKrPTmAJ9lp3k;hg&%heEf?yB}
z3PBlAMJKNoFb4J@4y1w%kORtrvLf^Xj6e*?2Gu|wbISBlKan6EWC0=C)^U&xv|1rO
zkOGc_JXM_28s!HCK<@{n3(VS}3?LootKl3F1!6%WNCO!l74yyF)FDARkZ*@`ktVfe
zYF{+x+8UDDD*5}M``ZSR+Us~oYTMEv)qqq3QVmEoAk~0W15yo0H6Yc1R0IF{8o;L&
z<NVj{|6SeuXA5CjjTHjCo&AM=o<1|}zgQXoM_k=p#ES!v?Z1p8zGbl5J*^2K|4IIF
zZ2(J{xqExg$MyIle7yypv_3#fMoY!PVXljVlMpF62MFE#VXLX7;^F2caPw=pmp%ct
zRGfrfNQ2Hn{v7;;PC_@h0`PH~>E`X`BNWH+7rIKWOL6MUK(^&tDmI=zuD*f(j1sm-
z`3CsF<{qZ^;`2;k3;6$!W3I9f-)r^0`wQ`HOrZ-<0({U~AK$Aln=v><DMLqMyIgG?
z`$}N#a><re4+m2;$d*;Caf(a(4L|L73Gnk{i^w#zvsI?=Y=kBF7XJZqA!HlmfnV7$
z4-Q@whwOu6Y2(ZADIW<q_O*PZeA@qeJ}7@_*nbY+k(M$7FJBi=A9r7|9lG(S_(C^t
z0qipo*8}?wX;NGV#B~S|K>2RiM>g<9P*@@IPU-X)=bbG-io)7V;~di<fu94pRiN_M
zpQDKK(>eDWoMZGS=g@goI7Z*dT<6bgnn0JlZ_iWXI^Uh^ywHRZlrC@b{Exhw9rtD=
zW+&~}+WpeWywiK1h_N#VExA6zd(h&e-0eHL&bu^&^7y=%p3OwhL)3hp8q}6GF~4%<
z*`P6px8(5NOq4(N(?acy^I!+X>LqWEa_PI+%@yw|ZiP75S`K~E;&rZVhWY>tL2Grj
z^j)s#pJU@KR+DoNtl2TQB<96WoA;dUn7QSG#*XW=kFF@nx#n2@G!SiwE$;(fuUqST
zgsT|ZXj?2P?QhpQ>inYh)9f3I9xvQ*;ep)_^v|&IN`jo`>WrJP!y|6_rg_WN7kc!Y
z>|bmYvCw*gU)uWf+1=4^hskYx-W=C98}6J?9yT*QB){A3E%yfWZ{g(pTa?SybxVhy
z+`GsbbJN)TecN7{>wM#d11R0#VQ$-E55E#F?=$YENfX;4GOp|T6`O2v@7%-E^>DQv
z`iWK!r+6vFZyAlCaf5DuNH=%7J=^xYzk8PdV%?NO&!!jK2Bzb_>52XsK2IY(Z+@p$
zSw`~=()%2A8dck3NcV!l`D<TwpW3*+bJj{5hUqqv;%T;z_sdLG9q+Zd`<0Yts}Ci;
zyLsm9^3$)Tt($(aQ+LI3#KXPH=dFFERwr`3`_XP}W(!l_3sD>WestM5VQ84k)HByN
zBx%=Tjv#xzF8OiWHmzM_Q2Od{RA8IfyHzs#7cy2Ww+*t<zq8R`7up}!dDC;*>s2c|
zUR&6Hi=%r^<(T)n&E7Y<y{OQ_`E+eCPcz=-apq49(}`_=qkr9~(^BP8Qfl9WtM{vi
zS)?s33OVnbKk;eK-Ywl1?XN^X7<)b6mAmhHY_}Y}FsxZ)g=_6znVt;kVpwdkQm(_;
zrNbTi>_Q(I8}HlmV4tw@;!a;))#S;nc{&#kTK6%z_r&qU`OY)6%oQ&*y>va5x$A=d
z?|!7e8sWTX1&t`5@rCJE)0Oha@4Fr_x^;g!)2;FM-)XqM_{cCa=*#2tmd;Py+EFvq
z;)cukpy_%Om9Jk+ZQ4>;Hd(ji?b6-qS(ni_H<;oD3tK+0>V5RtK*bHWey(o3V~2|4
zmi5Q$(uIwU-z~eHmCJn|Y%^23-uj-GJ4C+iW?}hk&ndHkD&EZ(E}t{Wd_qY4s@poF
zWEUl&KYI|x>lQseTES2l*D^7`)a1Yo*S5=Tc8u0Kd+)l}bv;e32VF6@k<DMtp#3lV
zj+@TpHl6iLn?^-HoxSh&TT|srd(!*O-gtdq)jIr5WYhh&JvG;P;?`D_Kd;Ao-*>!a
zceuLw(t(xp970d1nx3t=P&nIg=iT-lw);IpUq0Jj`r7PU{>I2w;k3o{HZNM#tr%n4
zept7&b;3n;kBXC1S}$gpacutf%{;6=cunq)t6S_!I~!s>Eb{4_`B}+Vn*TIz)5)uk
zU#w;rUpC&i=YMZz;{}>c-Zc1N^O)GHD>ujO@2TonqrGH+=%#8!*`15ibZ5Du?-rAE
z`8>Z{%I4wWqh$RjmAWOF{37aMs(dkdOhoDJje4?Gj=fVEhO6B*S9?sZcFnZjGoQ!b
zI<M~3VTCzDrKyMR^z>TtFjy%*uSZ2(MkjyYOs%e%pvu*5j{HjVd6h<kQ~P+@sZKht
zCI3|8<@1S0BMPp_HahyT#w0g>Lyw-gFIoN71chApe%ED!)e+eN?m>}@OwQ-s-KSjJ
zMb32Sf@i}OMBMEFzPBA-$5B*{qx)OB+B`7(*e`1CQm0paOZ}=1Hk7uNNh{FtI-$B{
zvN`-<v+-05+)~~)dOgtGdh**vEjLc7ooLr}U!2~i>u+z5xKv|>afx;8bK_ombz*w*
z;pUdFrVccDvv!`N*W9DGZJ(R#m0v7MXul2dPO{g#YT{OVX2i<Ly}WuZmfd=!nYyUz
z^1=n#g1gJRKiycq`#Hu<*m$MCRkisw@4<t*3890p*lCqNz8f*bIP#avKWH3Uq?@I>
zoV$IU+-NGVvuM(UF&Em+nsV@!!s-4UwF>l;cjcU2)<GptXZ8?L$wZ6;vGHcC5ouJk
zIT)~WW6qS1^7G^t7u4R(zR|n%l+Y>XxBi<W7-kY1uPVlUr&_@Eu|D>Vew8U~H$UjL
z{fW`P-hA?Gj?UpJ>AI`9+dXjg6VZ;|eR-GFm%HsW*$}O#b@g~!pPnz?o;FanR}M9-
zeJk)YGZ_5_cIIsUf<q0{hc;TORa~b!_+gy!eY+`EJBzFRr?~3`-rc7*vn6-CKCbpO
zT<!YYEU6ru*C!9ZH893q<*iI#!={(2AO9MBeyCc%=_d{bjk#hPa2S3{*yl@yZ$Gum
zH{;WGG^=^xSSi=sXUjoTCDYTt%sZJJ{iMCY9PainT>ZRo^|#WB{X3J?T<Oi#r`|4O
zO)55T6vnB}ajSOodhlZUo5APIm)~uPX9ib)D}7kK7)}&kO^@kz;p~Lr=hu#r88)yc
ze&+Q`7o%G?PBu%k%JCfk-u_l1*mQ4?Ep{DzuMc0ncU>F(&>x0x{5ZR!{i+USnIZba
zU1dG4V$7RuS1Sgr&3116uK$P+Di$dPi?-(nl;65GvR4PD$BK2~w+0Sln3?R~t&lm#
ziYNShzE|#sv!$y`H=U~Gl^)_>URD;lAb7jdt3+Auep$HsJ-N^3ue5*SoZ5xeAI{|#
zt?issF)jVwv=6ODc^*D6wr0lTFmJpQ_htX?Ur=hba8Y$c*t=d<AB54CHvU#UHMa$I
z9-lJkRM*J2W&7cej;&v3jYbnwQu>4%tj*dzLv2v6`HyGRWG+}<xa2@c<eXXy{4GDp
zzVCMIV0d-@-iqO;Uh_^@G>f}GP;&(1Ix_Rxi_ufO4XlS(bN8dd)!s3PEyu?#6{{W}
z+Y|ci-R2H^mDXkI&6Oz&87xX3rWHFrZoP&R<};v9;OAhX$)%aj5g*Rw@10Zq?8le`
z4{`!lSQebuzVB%lW;+${yIk!e<=Ff3YRV&L?~^JXn>H5K-n5%uQ<d>@WpVtilCsdb
z@n-pM_@4QdO?S*e?b!4lS0_ELt_gT@SAF`hn)%xXj<<TyZ$fdH#n=_l9alTc@n%$x
zXQfY79!_mkq5d{JWon-;NoGo3gY+tDw)GsN&|T$VB)+$_j49r%lXIV)DtBIZ=Wf#8
z?s^tmdsjV=-|kiyx?90MqNDLN8N8pe@xJYsg{$8zWwt&-<v$El*yJc<*+2i#o#E3K
zhdnJEcway8d6QS6+MAn1WOMiP(v@vj-}W<v6(~{O6Ejoik6k=rrrm{(+n3n2U3Gep
zjjMs~K)1k6IThBget3%cA8fs89&M7AsNlT5TaQamY7LAmTW?c*@N+W<_04m7^!{jd
z1a)?seQzpe&XrblU)T0!M-S5rPPy+bLsjpT-AFjCtFz6^>FJ0(jLWn7`?md`kgc}>
z*NV5(Kgz#s<)Al7wRCgB<;dmpb~7Q?0iB2c95N#T_a#^VE&JK`u*cPnUTY_o9Jq5x
zKE~py(YQg6^Cmv;nA~%<;~lxq=U)`UpPU-$<=g(rINKev<@mNAGp=@rN@FO0+cIue
ztaQ(PDGGY^!_lnm0dteiCG!#&ye-?-c;?1wBE09cGNgFpOMW<XZM^B#^VjVkA2#cE
zbew+O=7H;j-EU1+czgZ$dp~?Pvd>*pxgW<Q$PQ2}ZZk7y+x6Or+(*6VU5SiN^SZHj
zW#bbg<zcJGru%KbXp7nJ^Kbjb;Oc)QoK5%K<25rM`-CJsx%1Y3-1;R!4@Q}6-Fthx
z($Zl`J6DHxL^+b!cpZ-<E^*CjyC!B%@R}VFN*jci2B|L|a>v)8YWGKXy}mH);_5%G
zioKqq{HS3W(>kXt>1E@&wYT0q)hk2N6BT$RwYvxE*u?b2^Pa2!wDatJ?sB1XO1D>y
zew-k)dHdJx^tt-o;p%6Nt6#JOW2wD3Oc7Me3k+TcoSCN(X8gSOna8?k9Gz~4eGJ^)
zyMN!{Snl@JT>YZuv*~spwZ^vP{D1>XuPJ%d8D*E%wDdPEe!4qwZHiNu^Cu^rL%$i@
zj}(#9>V-giL$h1&gV(%Yu_4TERMqhe!&xtS>&)7cbJ`f+wOsv^arHaK)h`fNyKt_4
zXhx5t`Zzmv>T?&JwAUd$E)VwbzoPA*dBZ*0(>Q*e&--;n2hZZZ<m!j(Ci^^KvV|u?
zw`=t(d48_Ltf#X)Z|xDd_Y6~fS+n=*vxqIc67F`~T>XzsVC!w=+*S@%GR7Bfj#bF_
z|D~Jn%M-JDo{$?n?T~L5#nJuVZ^HW@``#qjr_z-fY%Mf8o*%FGWaZJK+Hntl?95X&
z=zq}t$;poBSK;bEjjLavYW8_mHu9pM*KmLDcOy*?yG$sOdAKE~BE;qye|6wn^~7@r
z*D%a_wmw$ve|M^F#GCLkJ!_XSBlK%0@44X}`*^GWsBT8(snzP!@Se!(dERWzuA+_6
za?8R`w6*RT8dYi%eNE;6v3Dl$H688aza)q~G%7T>h&?KnSR#nEK@b`QAqfcyA(2D{
z!9|cN8cS=73XKX)D@fH6N*kJzYOF=I($*5h+LWl^|9#Fqmn*j0-|PQ-`@X+>KKbT3
z_nbL%W}cZdXJ*dKGbPKdTJ-h0Z(<q@K2Lj4arbh&ET-C9G1b0@srFV(wHGI2G_@Az
zM}=Qc+Pq=QfT2~FB-%~?^6c0@`+uG`_p^<y9%QWukKM-{Xr&!`Be74?ZcpohYnHz;
zs`!k;QE55pAKY@bt^R?Z>-}r*CgA3jqUW7?&aIA|Y}%pP!+UvIn{_qTTKir0yVEt_
zBX8pH?78ch%xkJ$IaBS$z3Tb$rrP%~)$Wt2b_7hd|7EKEj8|=^&Q$wzrrJF*)jpJ|
zb}??zq;UlGo2BwCGrovMW5F?dkZlyhZOb5oky_+vq+F*1^*f{T{ZXzf&9MlO%>gH`
zBk^Ci8`&5+oHhkrVY)~p*<Uvm$s?s(fTW1ftwmA=*PTLAh0t9>`XM_OmT%b_U1y{}
zQoeHrAal59ls98wVH+HS8(=+{`-3M$KrAFfCU_2^KOGs2j0PKM263<rjzJDs`tbe-
zM{omgh=93}0I6^ca=_9TU4RRCLMX&Q28xVBra&g-fE5vP09WvYK!|}P$bek1A+pUN
z?nlB6>2Pj1*CTCD;veVgUgLUb$!|}X3z_5f^Yo)Ro(Ogm@CV!>5TYOsQsEfngUv+3
z1MUzCv5*8AkONkeu(i;FeaHtfE?*bCAQWO?DI`KF9D^LNYDFBu8zLY<gP)MeejeC5
zqc8A>xsU?qK-!2d;14m73@5?Tg>Zr=L_s{HK@OB^!!-~HF_0|3+wvP0gQgwf039Si
zI#|0BJ_v-xum^I$wmruo7-AtAvcS3n$H5;K!yd>6n~vNIf*}s}z!}H~yH1<~Z-|08
zNQE<y4|bh758e<3agYjUKtms|J-9(SNS|*$c+iIv0kMz<xnM)P%NJ7MBsfr?cLRTj
zg2iwK@<B@-)D?U|2l226vLFv^c_+DoKg2)+?13Dxq0hS+ctI2-Ksw}rbr0MZ!XGfU
z2jR$Z4+w_2kOb+F1(rR@OW+29po6854C#;s`Cv!?TQhKnV2FhjI0iXj<$*uo2L2EO
zNstcbARprUAfcdr3NJ6>0`ag1vcPHp&po(91jIoqWP|lUo;mOa9i+fX&<rAs;02)&
z2N{qH*50Huc#51v7$MsNeIPTVNQ=o_12H9VKZSIi$~`R62{hB86QtP9$Y(!s8f6^&
zmPLp!WM0E9-y7rDKL!Sy8Ce_`yBX1(%b!6U*>4%mJ(1@i7u@(Q^Cp^sC%C^)Jg##M
z`}Q-rC(;9%iu6ThAoIb_iaZ7`aE#;LNW;7fu~TvmEN5{Kq!#H2k-y-kIN^tFz+fAV
zHAI3v@kv0YKsIjEkjKDwHrImZZPFdgn^^;94VX1x)__?9W(}A%VAg<H17;08TLXnT
z{P3ZA&RV~AToB(uWqkK;exHZc>>omA!eKZLhHVY!IzneKYzgeIg&Wm0nwwzQ)^ThD
zOn`|H1yf)eM8j;D1F|I{KZA{s44Xl=i`@GXywC52@BzHb@42vq{be9q4!^I$b&yTQ
zpTACLl8k%*xGMAiYj6+9dxJJe74F5pj7$3*xe@l_k2@ryiw)3~{S~khWb28PIn@1N
z0QAL8Kj;sJO^$bh`%n{Z!Ji;oU1U9QfJV>+WP6A#j31UzRQ0P1$2zm$RsG$K-^IZO
zJPAiX@B&9@0`;K*$kr6;1TCPIdTao4EQG7S2O+&-Fbn}d@P`ffe;R%R!<NLp3+LK`
zY$K3CFiQPh5?zY@h-7rQ31lq4Y&Pg!<~^)I_iJCr-X(kjGOov(w&yoo-;V37IbRMY
zaZY4e&b{{<=?jJ}mi=Yw?^Vdv>i#Fl_3FO3O=f?K(eEAX?^b{BL#C_y2a(^a`(+4^
z!FIx7jvZ5vpF;km?*E27ukIHj+!kuw<({S3FKhI>tc`vh4LK*<GU9lLYyVQOmt*B|
z|C)M@4YGpK^%c1ObuetkwjwHX{0*aX)!5gnzboK>MWcH(W#38tZERnn1;<*c$2%k4
z)cvl=Zt8w_q`SJ`6X~Jui|qho+Z4w3C_Hh~S9Lc4>8<V$MFyz*!N@V{zQiwr{qgE=
zV|x};ITo!RmuE_z2g!%>Op5GD9+Br;o(IXhFS2=&gnndxj%=mC7JMNdZa_X*(Ki(c
zvc~8+$OV_e^e2JLKau$)V$;F_Ji)pseJ0=!vaXyC(%={v`cN$C53vDz$fUo+hQ1AZ
za0C}{hYb2MN|nTKs0*Q>gII_Mu`jU=JPCLlB*8W~2M(q22i(9Lf`Mi2G^vmd#~=&x
z!Lkhb1Y95#wm}*kgDh|?OMeT*z+yNFVvocgnn4z5$;a;C4S}!}G9e$d<v9o55DZZ;
z7xG9$M|AHB9^ebvB!F!t;tS0n7?NQRWWX87hEkPr2f+{pCqYBm?G3>Y1#=;m^gjo=
z;7wVS2vVkK!2w*r3j!em_CPL_;yvXGkq`rmL94}Yh=LgKtcirBkO0Y$0m1hCh7?GH
zV~`E`U{i~@K}+z4K!|{7SPW@!3@mFChB|}~0wEI8ArGwTat}y_49KpBpY;h3_=C0q
z`h+N$3%(BM0ph{BA@KqaNPuH-4*cIF|3E5uG$NltEF1$%N5T!3jR`lnfew-(3vPg8
z6a0W!h=*(^u4#^2@B)8`0kP$i1Nk8R|Cx{lwyn?sq{B&waK<g<Kt9xMOMGB1NI$&B
zmGlD_$d&!}>_cWJbOd!f6IRHAQeAk4AOo!5LO+nyn{#jj9NtF15Cbjyac_u*8{p6%
zf5B@Y_l7vg8-$L$2@lK#x54NVQb4}*q=9_nvGV0wa0mG|;||`i7><D$$F>Gnh=dr3
z^(W4d51E1JC5X5{GjIiW@B)7bg(!%D#Sjlkunp26WhCJmg@jzN4kms)t5WA#f|U2K
zc{6LktO2tI%o;FjKr~<p1ONW~f4@*=?tgH|_@I!dC;kV8GgE(pGV%YPIPd?(^Y`t`
z{oOhKV*gGymZR5LA@kv{s?;qp1jivCy*l)B>)piR)0;B4Ue<~C;GDFBdlec^Z9qTo
z-33oF;WK`p*ZcXxdGCff?Adm-&3jV+F^`%2$BdaYb?rm*n8|-_%;c*c3u)>Y%=dVJ
zwH6P4b}N}yFLB_`^7V%9^*Xq3^UaFi>^U%W-sVN_pS=I(uX|~iD(=dxcG6zeMt=EI
zo2y9~G4(H0IbQLnqZ?<uG5?*v&S!j_?nu9s;_gn-FV4<7yz7?3gL$*gOn9%B_piI^
zR62gd=l!k~J}5S@!Pm4I+?D72rE42qRs6HMxb8~HQd4&Qc>b?d%L8uL{&QWetuY?;
z_eLHV(X?aTZA)n@&`#1?+znaXF8`f%i7BJ|R=4=9#I_C_uO78%vu$a3+gpPdJLWOY
z%ha`!UiH||CQA4&#LqeQ?U1`6$N$QI*woc6EyJ(uva+rA4k@<B`DPE_u}kP1R@_Br
zbY62gW4P|_v`N>TCQX^pxxo+PFD37oe&kx&hrPb=7)!z0UgG=mHL1*FNuRyesHtN~
zO|_|F>Rj>~O1ix|+bg4+N<MI_IrNNGVT-ZXN>y7G)G|IlCu~ojx^Hc1QMAM5?e{|-
zgwhvmE$(arwzQmEqffW-ah1;eSp3?<azTrZRMrGuXjQk|w4XPxBk!4N%cZOGo?i6D
zsnd1V6<xaKdic?!YmUqu`$eZIrS>NLRHOCjMy2nD(0+fY#CJ)RO2xXgI@tWR?kUCI
zIoN1g)Y}I$2S>cur_1~OD>d1f(e-c4C8vJ{8x${HYtPg*SlwL2zgK4)#?-mmrrN?W
z)z*v?y4G4$UBBk{`XRTLem23<uhh5Jbq}oH6xM2a|G4!f%9nnla!z^b&WgJYV=8Ma
ze4W<r#^{Hq-+%4nB5SP{zyDp*!f88djjA=RUdL6Y+g>T$L+<M``=|L=&iwX9xldAy
zcRGIde3|dxJ7Cqi-Jk%^I#s8Z{FeT1*Gl5<<u-2qYi!pj&)dsw(wJ)7<W<|Q!I&87
zv2bVag=d`R+C^oqv~X+Xm*(cU`~H#*d#3FDWWvcc_tvk~XkN9A8~FyQwRriO(K4P`
zYw>a$H;tA2_v&oiylUGurrPxRr`xVE)h3OpYmNT9Y{)#Mzg=rl^x&t?9<LR>f2!h0
zO=8<Y+uuz1ahA*d;luhyIMw-K+135@?JMqHZp+0~8$9jk+t*sGF8NiL5nDE#ZdqcK
z?(EEVt9G4n*}vdG|CTFSj~H;X(s{~BQ*H2=Y76H*<-Y5F)eP;ZP0T9al6hS39jq~J
zZylF)hX!prvgGdU`@1K^^WB^8AzBk`=9s#Mt*JJ1Or4V#t32l~x3y*JoZp>_e=oN+
zb479YavL(H+M21P)SLdfwq}mnN<Qf0I)2!?J8z$OJwV&;&bS{ct!n78X-CygcMrKc
zw-|ML$`=}qskVenwMk>DjS*9A6Paqe##Gxx|JQ8NylPuBui7?@$+kJ#Nq)90;<RbG
zZ|$Bw7nW3u+T`+;{qBmNUfVF|`|9U<4W9g9UJb?}wH9|~+c5uWwqfjDCEZ?b^Tkvf
zL7s|#FSiZzs%^fQYUAd=#Wu|UHJdM{+QRv7vH4=EjTX=5^8Ehi+h{S>rjMz%Twb-!
z96P1o?3drB)+xXJqQkm5u5Qi3-?lhB>Zj`I8=QYmTKCg|8pAu+V;qoD|J%8-YsR1%
z&UI#b^xXTipRVwl-*)_(KH+-hpL<VFYy8osssDUiE~eVTG1caasWxs*wGDHNE__}!
zhHtLQw^&UPjr@rX0c9)8FgE!<OP7hR7P1`j2=X<ge6zJd%6ek|+jD)h3K6El`gPMH
zkk6ZgEaT7Oz*HLsV!yy(x4?4<V+cWP8T`|27#Qpqh%E!LVel;51$GliS1{WwV2mMk
z^8Zwu1@?K2S-egE5FCR%FvX6+|Aw7{e~L{4v6o=52T;%!fY<@><UM1s1+Zr?&xMY$
zx(w{eM;5dLAoKr|zed+cS!2*(2f(r@?q_fe`K<Z>GWY*w^Ziq}zTlkyz+V`vN}>C_
z`Tkji_wUU4&uc(jOAvlA%=>Rf9x`uc4VX1x)__?9W(}A%VAg<H17;1FHSlr`(B1IF
z{QqQr%ba%^za9fJ7TtLMt@vm>&sTn%I*-?Q9`}FJ9B!GjU2q=vi{@~PPX3+qxUZ6K
z*TJwk*fFP+w%%x%4n-NOR1Atk36O0z$Cra_W0B)vg8I8A*V}_^wUAzPlnsD^P@CU%
zpssrUO=Kh3h|Y}XlN-+)H)U>k!MWuUCYk5`cjk6WkQ~7UtZ5H>K{PA|58A&;a1ydX
zOS{(>#O_@jWPoALwzO#@AqHZL)0Txy(9#C=0AG+csZB}r1g@p%j{%vVoeGhq2{*_b
z>~kRVt+OEy0_l`o3W<;pVh_RvQbBA$*nm8bCm|agNH4>@YME0n&rv*_1S`^`CAdKh
zq(V02fhD?gr!P7Zk{}hbz=m;zoxl@rR3;snLv5H-oxr{|N)#ItVh=)71-~H@VjxA!
zJ*(3W2hSSl4z@u$=xVYL>EO*A=4eQPG?2N>OCb@w=(~u6Bxu=;a}WhLpqUeMUO@*L
zAoGg@Ap#O11x`XK#-ZDRWlQ{nK!^Y_66*$DU_942o8P&hapqdE1DSK|#y4v(5SyYA
zpo3I0k5wDu2+dsa8zRA@13G}EkO7*G=n77DLUtx^KvWmf95ion4D6sTGy_*~2QP4Q
zBko<15CaJy`CrOl^Jdn7Sp#Mbm^EP5fLQ}(4VX1x*1)UO08JsykXJqbKRh5}bcla|
zVgLaD|C?<9bkJDSDx;lHNdD7KfZ{-NOmmtxl1DWQ4X1p3hJ{7=1dWLZ2xD3MQ33uw
zVF7;rE*xm9w+ld1=vkZVCXT+2T>wYq3H<9-D8esnL_mZ%mU;d|)cboDmLs$=K<-}=
zPSJh{HNJm%gkMB}&uG6fej@@#2aJhucJ?3V7wn@yJR&$`s9&%WBxmP${DQ{?;Dx3t
z7W$qYHmwpiu~{Ht+t0lSTVPPQK3q-IaOJAu%EXO?>mc00ZM+&TqT(}LG7HD$UNnWC
zwLM`U;jVJ8&>nKt>l%x4UfkmbtmVq}dVgPPAHfj5#TNS8ok3W^k09-?WUW5k$jW~^
ze0uv0`bbIm@(5cj_t}Zx+w}gvG<<KW`a3BPDBGJ{PgjDb9`YXH%dGw=e9DbPcV3Fi
zg8y7q-4!X9W3OCe@7}XXQ*k9}=ZiG9HzCIYA00Eqp<Fph7s+(J3WWuPj|*1vpTun`
z;Rz;;M>uyzAEp<^&2UXT*KFaMLp78zDc8`{R`21{IWjcNhfJvCal<voxaJUUrqz6W
zO{eEvBhN;2O<CpHlrayoRRX$oWU8LB?RijIc{bJJ%6@pz7<<XfqDzraZ`RYBaIn0l
zNVy~WYekoh#ho1c?(s3@a%27WRPA{f>$hj2r}f*@NWc0x=*t&R2{_ws@{;6(?MNjb
z)OsQx_>2jW@<ks9DT|)5J$jb3oGh63bsrtmhpjUCLHv;Zzg~qxg8h9W0wR^tU0*KA
zGo$xI&gri)+aLMouGwa`KXPmOR_Cf)*1EN@UH#UwuSYv?Y;=o0*;l=0o7w(IL#L)!
zaz^*u|C)>Khm+r%`(S$G+*oWfd(by(@qfquh*xik@1V2m{MW_4p{?Nj`7dwv9e$!u
z%e&U6hQ*I7RlNKUZ#aB^ltQ$<xHH=yvAA<$WTbDyHAxGbZSIjv9h$d~)}r+v2R&zW
zd~43G))(uT?T?u4kE}nH=6_yuZ&Ilil~QkSEn9qc^O&$Vb{wkBHxw$7X8R*%`y=x@
zNIpo+x~;K`?CyN(L5jQIsZn10!iT4Y&u~cGe0gw|*Z7oBjiw>r549F{DVY<i&rfri
z;FQvMlV6wovTf=eYkhd(&3XfhR2iB!uRq_ot;L<${>Yih`-UFwb1CD~74@cmeuL*t
z(Tmys$mCirvwF-cR<+yg4nB=P(P+%}N7lCgRo9@i^|$M~&b)YPiKAt%Z=)pa^Ya}a
zyGr5iRchC|SSi7C;+S6k6JzG-dN@4z^P2O_^v0DsREfLE*aW`kYb`ESnS8BBjRVp1
z8(Syr^J((yf_doyZ!PNh?#P_wTi?Fco4jYXKVr5&((rTo)_O>OG20(Ga$w`a6VC3p
zOUyrWuMA^a%=SktKl-9%WnJ#UDU;Gef0|S8(vqC@R~WO!_#dsswUDN^2T!a_UQ_bk
zRo@%MN{?BwsdJgmyMLXqV_ocpDo$frGexm?@!tK)kr|F#kGjPCe!KE-N&bO{vV6n)
zT$@*X)Y=w<dbrXzwv=%^T8n^;%%BI&oGPu$DY`Uc<G>J$n424IOMb9o`q<b8OI?ze
zX*87?N2ImbwYJ#dUT?Y<Zqv+td&h&P=G+>coiMd^S)Zh!9@<)CD^vcxM%rmD)|M{w
z=MR@g59`+c+VUk4aW-QE@&ba-ULE{r>#yDC{3L7V_$vOrAMu;#yS|G*j_DaR?!Nt&
zt}VOtb`8j#TzmN0x4*yKdD~_3fzrO5v;W5pJ01*j9^&=K$Dv`ar?#G+mryJ+bwU3F
zbK`%o+DrfH6ve-iT{Z^Hy_}VC{Px@PhbL8-+Hm)<R>dL@E?%Ex+bST?Glg}3lzR5$
zv0rBO{%+r!hd$hU@%@X-cII1L+^jwLZg$M1sMTd|Cg9&6Z6zLq{W7<P_q;K~!Lg{D
zCOh+ucIA((v`^o(tJs#D-@mNC$dR>(lzPOq<J-gUZEAnx@R@e0w=NwToqlIZ-Hg|(
z$DJykx5F#{(-VxNGTR?1vuKy&JB6|*x7Mv|XTP*(+y{1k8qIf#UM}@%e_+JWnGe1`
z{OQ=d%U><tc-CxxMDm~6{z$2_-<9;KynJkfMh`u{Ag`QK>S0-$uP<J!x2V$fYJr{i
z`yIO5YnsjJ?Bnsf9qO+N_Pf+ElX01@qQAL&ZE}_kx-w^Qud+Rd*K0EC<C()l^H$A_
ziEA`%S)RqAIL1#Z{&_7NP<r?J(Xkarok$(A*!_dMQ|6EOq~h-%ow^s9ao<VCzJ9Je
z=jZbZ->RE%ZsY0AR*QRFa_R1TKC{o2YU>)l?|Zsf&3#u-YBX*5c%ii@wy&Ji>FixY
zV?8w~cMf+9ymIu5H!}O~aO$2m-ZOtg<^a}Y<HMBJV$Kg)-+t`eW8iPK+KnA?w?Ub(
zd6#G9HF@{YrQ<Ww22~t1hVQeAyW5!yqjl43tQ?`e*Tu{EgFyq{i^#3ftye<Re)l70
z);`_<`|66jPP^Xt!uF!$j*?lObGyCeH0vX)JIA|i^R72Nbi7sh{D(TeQz`Do`Cq#|
z_@UMH*L)n`wz;@G{$R|U3F|eJJ;&AT@ZIDg@szn{`y(GUa{Srm`!*>F#VyX|uWwbq
z|6-}HRqiI~wr*AE#}2bsecL}exI<S>^t3)(-tJq)?Rv3(6<b!H8@ut8MzfDGxLS*0
z`)elFxmozD-i4O0zWrsV&yLObe)v`U$ikOe4^AC9@hl(oIx7Ax-CBR&y$%aLw5yc!
z=ibd1+NZR*YpM0TxpvI1`=zgp%~{PDc*WiHT^W(PKCRHUe*1OxTl#9>Xu4tRxzXCO
zix1pbR6BQ4z4tX5v;C2~?|nFZP?y|osVzrdZB&2cij3W^Gc=mpivBj2+*@;Ox#Dxm
zgic<xbF}8&a<e9#Y7tjyeC+QvPqvs4`X%=4x=Xsn`KBJ59ew@Mp(~mF1Je4|{bkMZ
z$~_`~4*e|i^YaWz|BmmbHsbDH$?x6wZ`2+-)8<U!T|fVL$@`Zfzj%9hyS`2vTEG6d
zz7v^GpxoD|Uud3HsMGavdnOd0?s}!sp7RcSeEm*Le>i@9qvlPbma?{-Qs4M?<hHfL
zDmQ7HylLgN?xzp$yEAx`OT*mdH5QB?{@~=Gc08B=KkScCjWLY(P{x6{^39gd;~IOA
zEv&FcCu1P6@u7PSISzRXDc7mvG?eihb<v6Ob@LdCF4xURRz#9LmFryDSI1FkD5@1>
zC-SMgne4MseO0atL-NRJ#vxI;CK7oNIRPp6cLjC4gXRqT8ay%f#~*iA91cK!gA7C-
zM~*`Nhzv%GKe3>WOHjruh$l>G&_si5L`$YcXeuCoK~injJwP(7MYpMte6!Z*rt)1|
zi;O{5N6MOe=uao#z3JZ7eTS@rERKTeB1<AEwso=|Un3-+!!?bOGESliQo@Bhjry%$
z83Q2U!W%``2#o{oM89&qxEEb!>c6Wi-`mB#=sgW&Yk@n7M@uBtV3}s18;+!?(tUv>
z3+hS`A6~P%vd9ide`H7Gd&o}6SR_pb-Fc)NvJ?U8iY$YqDXSZX?1`L%?1Nl@d>gqG
z*%$c{vOjVy(hIo`$?H(}8FCOZ1vvyM;{<$=V(-Ch*M?^gWyqRs36Ki1Zd(pm`jYR!
z1w0`XVjzQj6o*WKOvnK%Kk^K?f+qw*3?xAY<btgK)(ql)<k^CBh`7r2NZXUl10uti
zZQG!4+M9t81IggR!xIRLK^~z0WZO2;w}}Us?b}esc`&aEVjv09;T+_H*}e^BK?&yS
z&0?+|FSCO7ZS3z*uYkpn3>k0^Ec19q%$r#QW(}A%@ITZ5)x#&||6kzuek$fNwltoK
zx{U2yjWnJEF1Iq+2w26rfH(AGx>vF<W3!J#8pxRNbodSqKnDB(;%6rE2#n-j!7v7n
z^7}^+1C1w<GJgFu$o%^gG?>n?|1+G0j#c<Zi2N0PgL7~J44YgVM|h6oPR7lj1R0ON
zoMVS+h-7fTBglg1|KiyHb$bVY$JW6=#m>RMYUAKP#jXL5hDHmtJ*6F~@rAjN38f0r
zriHrD5<I{gf*~5D%^3$aJoH*{fR@k+d?5;?-Mtv%Ascc*IwPcg-4a~E8zLbN5+MaL
zAqO;;gahhAC-4MmKSzStTSx`5xsU^SAa)0>K?|M0A0l8WBtSBxg4koog>>pk)+K2t
zfIC>x5ch{zh=-G4TN=N>6QUs%GC<b1m$mI(LB_2_LJXV)E6NyKh=L3_19|0%Gv$sy
zM1ZVaFKgD%g*XVMERixY8MLpXZ}5c_I0v~9QIY#Y2Kd?%PKbwdAhs9m!KO0d0WXM!
zJs`FiWPN*Ah=6!VhCIqO`)as_K$r`A;09>4gsVF7gmYk5gZM!PoPo%ixP==aohlB}
zkpi(G>&jc!BaYw-d9q)heULTd^TFXw^bY61n$8j}WP+>}FB2z{ojC`&5ZIdZhE%X}
zK{t>9$#4#CfK40X4PM~dR^R4JKqiArJJJpoLjoj2D#%*!Ct;f_;cbr}pan;e_245r
z@a}<QaHBKf>OwmlO3}&E2|OVN<a<B{EbfMcGtkl<T|g>iz)3g<Hy|IZdT>9m>`5HK
zvKM}WFO(z?$-JQ!NO{kcLCQR*CP;Y~St8|~Ds~-2nm4ls%o;Fjz^nnY2Fw~TYvA9d
z0jZw<&*%S#M}!598Q~o{I>I|-=*Zz=0p5P2{hK%Q9zQI6Owh2=p?V7d|IPFNo2&D*
z{R`_;@DPHgg62DzRZHrvr8I?P{=Z-Nu%I9xgJP69#$NhM3jTjIKi8KtVbuA16$%av
zXWuY)Sbr?+(Xmj@NgqkCLc>DFjfqg^QoC|2le#AJwFAR_LL<WXZLlK{!M^^uewx1=
zrz)(GW`WG_9_<%2hGbRTYdNNOPZ(rIHf90DeM^q({g>m9{ij*+)I4#S4{Vrk?`wer
zwlye4^t2KwdfMZv*V7{fan4kG00ng<dM&6UUyePgBa3o@q*-0UlgPQ>_4ile){Ni!
zI6plPU9OS#?^@iv*Io&;at+OyXI^6*cWn_IvDtDx$*QqNR^euu9iEK4Pq04j>5A*8
z{yoYcnVc#Z_mhu~J<cCl9D6eE<;rDqEKkW>p-dPL8Z$gZpFc!*1@n!}0gvJM<{FYe
zd~okGF4P}W5*(Af;E&YnOY+*|JR<qBCKSw5ogTS=GEaGM{8@R*?UDN@Z4daPzibMy
zPdR@@ufs=q^Lgnf*VvH`a?OVwAE%$|qkBA==7zcKj_AtNwaaVJ4%J$`x;4p7T|?Z|
zwZV6^mGHfM&F@z|m+n=s(Orj(q_wC~Wo6i|B%7YW%j<ogSn~bNYww)cvv<z!n*$dO
z{<eC(QaQA_X|rq1Yij?;&1rkpYh|0)z;3_sxPPTN{nxx@zxU^(!ABiy*q^P<ySTMH
zANQO;zuu(#V9lWtBY&+}_{=wZe+l@jg!O?9DNRQ$Ir>@dB5crf7I#T`-}J?F(50?d
z`(4}E!E5vM9}=4!-QL`B#HIls_uq7Qxkj@<DPOF9emFBnce6o-z!p0X_4;tJ?m_(T
z^{r0-618{ap@UWn4{J2*7}%t>aK12Lu6yTqima?KJ@QE7-}Y55RV*s8$HhC2zr@^Z
zkuu&}qxqJXtJb1P|Ig<9>Ecy<caOmpua>?4Uf0f5+SS>6KVs_r-?P>wR+zy%j($O{
zMXUL_d37dM{mJW`-H_=`v(H?N=v-sR{G}^ndoEg5xt9A_`U4rTrL_qA(b_#ax{GD_
z+ZO}=cjl_S>NT*JE9o)bt?#ndn@TTU`op~Cai2G|3A<N!Rtwz;o0-|Cza8i>l9#io
zYg?PTW_7owqQB{H{<8AI$Vn|-GLsHj9;#R<$L-w8dVRLfsIjtfX)N@V<vX1czWf>M
zC;z;9{qHj-me}!HwOZq>C+1vr`1!Z;N!#=8u3g(|5@T`||J-U0J!4haV(hh2)m8<y
zjL**r+ta7+TU%Nb?QnVf{ScY+Zt7gqSG`vDA|-r3r{pE1tlLt$*UbT~+W)z5f^YCU
zTTgjiad*u5_Dp=0RmIS=@}BwMUsL;-623&2MytwSTwn6}bL0Q7t-bvQb!)A~!OC+2
zK5qYEtfT!8+mahMyn1`LleM??w3hj|L&Myh-ujdNdZiqiU|r~2UFdiF7tQE!`l?TC
z!-t)|t^Vcq=08n56g>O)R<0#p{Tkg)O8Ba-U-NtYkXuVXn_%fz>Rao&2i9*2Yqh+8
z-1-vbOTSS$hi_1Y<olAv?1>2<RjV<r$MIo3BL_S7u|E23Qi<{r*?k?(-JZR^a@s-W
zK)xmJ-fOWieQ1R{%{x9Q*CX-R)YXT_<@|W0)0<T_4c=Q6{bMW2$XC7Q_dq2c8^%=D
zR`@!t-Hp)?Prv`#$3>pDL111R+&nkWyf(ObZr;5i=ckXRjqFLIn>iwPF8%u57v51$
zRcAjOxb*j-TOa<^+pcNxPvde&4NX3Mr~~~ZO8s=2)q{4$m-!az)%@`0(;WuRn11PG
zt6!Rpzf$z(w7ScS&ZM(sisIk0`_t}rY47o8(6DcIZrt#}-PSXrYS?vXapCu6i9<A(
zS5fyfuMKXVn`fSzH|x#*LFT!6KDmrD=_=*W*XI|EI6r1`{DsrEy}N%fEAniY_8)zE
zYIT{}?bd$${<Lazps!WjRr?}gmVa8M1&hZ<Em$+N%!d&NoGZ_0b2`K+cm2cRj!mY}
zzo@i-&1-}IQ|9IcF;+)wv3J0LE5qt1-<sUuVC%r}@9T!|IzBu$$aUqSF?Sc8*|gV+
zxykhLYAqU{8T)YE%5iO@oIY*z$=4&744vBhyD43NKKz}gq{og=HsS6BA3wAfn)Hb6
z(^lKRdG5;BRYzVL8T8|Z(BTcIm%4uM(;qI+Tw!sJad+Lt-IdHgmklpA?{ZS};~!k>
zHrMgn;XB`~9`kF;$3v4s&P>Um-+4acrLd8ZbvpKd&b!{W+RZcfmaad=dgau^>uL{}
zc5v%w<+dHVL_baM7UFK+JFofV7INKxqFeF9;lI`ixxRg5!|lad58ND5tJGUf?=HhO
zgW{jr2I;u*#Re@JP_f<q)XoF?`ZBgpNw-^B3!?4XK4@e+^`b@mpF=Y)cpjL3VQ#bL
zOOwa!pSmKR`oVRjzES1U_tpN`bnejlr~seINxl_>4rfocTePM3&C%_8=Tr#FW}KL!
z=j1+?x2N@}GAU|Zy_72L7iOLtU*qP`J)4f!xV!kP4?Q*xqg|%tgUI`X#wNsP#MzY_
zGU~tE25DW!%JIC}dS%wu%sT&x-HkoZwguWvad*+%`>efd=+B3Cq%SOeEaSs(+LWn&
z|6aO%mpv`IdR&U0&2v;${OjWG*11E!tjhlL$Nzrx&+*@_-KBYZ@5I-4h8?XDy`oz<
z->-Hk{d!ir;_7){dU*PPZQt^1w%DeG)=943KV_kH2gmE_)$d7Pr$+fcW45*V|J&B)
zEmR!|>Njx3cDJm%R*GZ6ARFDg%3SEdNQz%&t}34yHADIBfaLMfHAe;_U6G@ZBamFL
zn~xlg{0K?%>-Hh(-c{x}^SV~%^2#?w_1m)Y%~|eGSDi9;8llXAehoPh_cf7|k#wbK
zc#Z2q`8KWNZx)j7Wu1Jhjz&tn;z9jxt9;KDfB6KjSq!o@!JWj1t`XgSq!V&1*HeV+
zqL5@&-3%mM+q$JlS7a)(1M&}KXQZaEM$-jZ8c7kNtBmATrW=Xuh1`QAe!5I#ALJdR
zCsMvE_eG`?CI=Mj2@wzr$&d-TU^9g9fhPn*G{nI+I0iXj=|g=69Kj8|;omuj)_DGG
z-D`v$4D)CMnRM-Wk}=VcIbKOCjok#|2<{LFQ4j~Ia18RnhQxOOcL;@8NP-N=0jo)j
z4<_MqARnxGkJJTOYc3RGU@0U*Djb6xuxdrRf;U7!0{I{VGTF}qTW8WA{9!JnfQ+A(
z_O1)aI&?9R3@5>o%;Er^5C!p&202iw4cEYb>s;D&9)v8&2M_u=BOn&iAQx=hNF(a!
z`BFz`EVnE8f)3(g4`e|e*zz#Bf<MGS0_=etuyH59fEPqT0;EF@Sku4n2p$j&b0G=R
zAq!+&cwKOVK+wTbNQQLCf_$*!;cW))5Dc-90>>Z+tazyFf*ZVO&g_5Me14Zn#0Rn|
zpXMSnqe!F4JVOvuf^?ihdQN2=z9ssDW;*nTOon{+6Q?m2pM6WpH8*HUzqqXJAhr$8
zLH5t+_!{Sn^6YaipF%r|{g%<(4|xt`4v8DTt%~74c!K-;Je1eDhJE{)+z;u2Ohx)4
zGm!Zp>wr3d3moIPH*zr~z#cdUmb17AQj2ti$X{?%oUp?-&=5~+hy;7$l7KYK{Vh1}
zSByx+!!|J{VcyIdFl)f90ka0o8Zc|Xtbtdg0h)|Y%>VB|RpVW2>PxU2&ckXu*4;wN
z*xbW#91PnU&UJ*&VAvAaUkfrP^(Gj$bsP(#k(`L!025#$M8Oo82GKAZ=74NT$j@LS
zB*SKq?IK~g1n={EA$$N!U>V4k!?~+)9c23&X-8vR##@Ws0U0+fW1?jY^rtnr4_H>=
zUPu`~^f_`P?8QHK5PJt3pey?;U?s@b6Di}8`oRF`i<^GX9}Jru?*#XuCftHQLAJWc
zdLZk*Hv*Y2D%(S3Vf>Ia;ESq$b>UcN_PeUTyYag?*nq6j-VeOM5t=}KXaKS`MLIzX
zXr&$-fE)|q>hD2FZx{?izz<~I_YL@e8h!)Amc+gb=h}j7BalHbO8s3DT_zLGWOTR*
zWbC+X(`)I+`-}aD!?2b)((B+87)jcUg6}ylHX_8vLnp4&ajrb~v!+h}4gOnmz8p;A
zxX7{`AKd^O5+F7vrgA)l{ZB~SRdnvGmJS|u`-J`VM!%EU-(vK82m8C#-}{j1>i$9G
z_v*gP?JcY7;xNaKsmD(te^U2<L!MXn3lU}uRWA~ZQtX#C`u%t8Ev(>q`ght~=uDj4
z)OhtodZ_!J$iC|S0Hn9NKNK0D?#tX~nFnpyjO}a`<G7W2E*SS?)N918%)KA4{+4;x
zrB!$Dacr)7JQlf3-IwQ0o)yWX^1O=dNgk0hK%N!J*NHYyvYy`?;8RF~&p@_PU<<ww
z4>uqmtSBb~VH=!-TyQB&TOLkADcZPVGr<8oL2Mkf1b-0w20D;7sn|I<138cnrKFt+
z4&VaWv?U#AH@biuc!EEillEgt+OXgXF|ZU8VH<c7@Hj|<ZEy}8O5+c>fiHwY3@nCt
zNCL6Zdjs;pwhZl9Z~-rv3t~ed3vNI@xR>R6NPuL>g=Xm36+9pxTzHlPArhh?1#-Z)
zJm(+~A|VErLL%6pe|PYPV2A?CO85<(zyo3+1I|D;<bh>n%2a3uF|ZVJ!H%*Z5@KK}
zB!awK#Q3B&L_!)kP=2_88+btkL_;iy{TXYXzq;TJiy;A$!9|PTuoMy?v?dZ#Kx{5#
zKsLnK^BXeZ9OQxxWugPPf)@ls6wHMr*am5E406G;HerBf&<Q*t8Wuwu9D{RURfjwR
z&A<y%p;TS+A-I8mJ;Df?kOgt|2`A)%RRiJ+r5w;5%!O3Q0Bu9`55ABEb>GBK$bft(
z)rj+;gIJM{=mF9o9~>H^KL~~-$bwQ$xDWU{aSf!wF~|dl=D3Gou%chp6+FNfq~F!D
z74ZQt$OY+B4TdO4Y{NaFR9oD%BP@^vVoM^zm3>GBk51$PNQ7<R+nG2+9JqHOOb`za
zy*US=kkp6pfz{jSxgYn3KydZKFNlFuxB+6EGkqX(5P1lKy@?~-0L@_H>P!6n@E@|F
z(@@eC=0XPKfz>ed456Td7=O|kav?u}Yljnem<y?p0VhFhP2PZfuo^*r11&f}OXvh1
z;0=M`6^O2akgya|V7ayay}eA8Es;`}GH+%Lm^EP5fLR0onHsPp*kPJN<s|g}&fX#6
zGLc_Di(jVmj}96$Dj;l3K(IIK*N1zL<G*)!*f4MZfbdZfA))d!V9YyD8vx*7P*}(q
zS!AA7?}H+O{DOlf`b7kVjM19}(EK;s1n8&Q1h_$)K(-oC2CBdu>X43i3u`##<AeIp
zP6P_}3-&?X0Y0H2!9l|&I6H@g288)VgoM?t=Q4g+pkJ6z1oao04^Or28JpI16Gz29
z0M#o^QR>RQ3Pl74h0A^QbM^J}#6vYQpShd5E_!rfy;oGRG?EYG+V=>buReUkLPn1c
z8RIh|;87C#7$vKV1gotQrj~kd3jSBZRD=6#Ia42hdlgc%g0VlGlQ8vE!z67c*^I+9
zmur(v3e%IiG9_HSUlOi<YPfRMa8V6YbVZd-(Us;eB`u9~6%t0e1~5C`IF{<V?5fhZ
zR?_lC;d>p6bYpQB5)l}Hhe{Th5E{UB<;qDO_>|1VdhE(sqf{ZU>GeHYIUf)i6dr*o
z2jigV^=*h(h9o?jalAy|y1y5%M~XKkUZLFYdGXSR`}y(G$NTy5>SM^;MU-eM_7EkC
z6?x$15iiX><Met|G`%pfBu-R`pS3A@T+&3+GK2mH(j@#zZA)6~pUV%FG?9niIK`e!
z57(ml+t?9a<8X)On;z~*iGf$9hW%aTIe329(_avFgU&U@^kJWhC=L^0KK^FiSHq5R
z63jz{1^EpP4hW~@GuDI8Q0z*Kdh~!uxZU*L75x85=N_C{sp#BDpL&0kvQW$UQ1nT;
z6Cs{R`6$m$O)%I>k+R3|ETpO7pT>C!e-ykg&%y)K!(UMMro<sr|EwClG8J7sio;kF
z;?P#j_x2KSwqlg+rH~KFN78rU_)s5*r%EQHay&-4@~MB1^c~Bo=jmH)ggA0upT~{T
zgJTB!GG8lcrMKbXLz2jI;l+8qZ4yJq@X;HwQLmHdN}q<|A>+b^1;}-;Yb?s8lU7>d
z+K~92)yGZoPx6G`zp#L@<ATBh{EhvyD3@YIJDcnN#9d*Hg}jHA@VO%O&#xgI`sY&e
zhtNUQuZ&ZXt%$1M`*^Sb{q8BG`1N$jU*P?1ijJR`9}GIyKa0=SvGj9_y_N8B!MwIj
z*Rej2J*nfm=qZ}`HXx26h4s3UG<%tjZMjAVqT_|?b&>~M`K>Q!o~>g;9&SnhrEI<+
z*_rMV%|dkSVX1^csVEu6{)sZ<MekJ6pDTW;@5aZ^8^<J1%_YpzpGp^!W|;n7kDft&
z-qn{Q1@lDCGs3%w@Mb<Iyame$Q^Ksi_nr!~*ul+K!~A=JFzfTelVKjH)=h(@aA1>q
zsk~=I&x=LJMHC(D>!$i@N0?twM7Unb&dyRBG}1k_){xOYA>p!Yhw`qei+p<1*H1-n
zLkxA}XWah-?jQQR`x}(@;vkq5219w@Ng~ho4*8p+Nizm1b%a=b7@ku(7&^gcSa66K
z$SPQ=lXuoq#m9pGtd%nKMRhtaE_q&^PV#0h`f??_V%IrMA3h~-O5QO}XK|ZQntnjs
z%CNDks#|&fq<q$waYM%qA07}Up_FGL6sa#W{f0%1qbZ`6z%P5&4bOqdfok~}S5|y|
zTBo7Klze5fP7TQ|ewm_IiNmw%l%m(?)hR_+Zs=(#VHUk6=)?F(ug1^3xRvi6@~uPk
z`n~GbpjUml_UiRIMtxp<twj^c+E>amTZ8>2^1QMT7QuP$^BT_cYA9_B*0{!mJgRbO
z>pRd8<slYbzvvk@#J4v0?p4UeFKk4(k0aN~amkD2jgB|wxa5s@)HpaOy$nyrVHxga
zF|TLF!H@}@olS^_>iAJiOpi-LqcFcLE@5h1N|l$?(6>{i?2u<G4u6uL7Z;_u?Ccyd
zEPPn#1Rs5QN?6B@2@e`ECct0oBRv7ln`wuIj0um>)^-s0+WOks=<r`nlV%kkr<J6M
zq?Ie-U2YWbCLEWvnyAJv_Zjh9g?mkjm!{RDC_YY+=f?7p6N#v)@qAu-JujXspApYK
zYCNMQ@!0qrsJsJTN3O=b$MfR(I30rn#wc$^HI+<HCu6-!eiOYL`iyMpyOGT}JRcJt
z-Sfip_!&X(5~L?oYO+p^bz}(Bd{sw|)G1|q2gph?$3~M#n39dd6doa69;5xn_>BmV
zZa-&de|eSY503~A8R{2o&{qAn&d%d_fvVkt0WR-^1o><0Qik~l3=6JZudbT+$^G@T
zV?qKVhXsTh$|g7N{q*LjykDh#=fTMegw44BOWpyWD945?^*lRtY)72rbKJN3I6SK7
z#VBpD$91MMnpWj1vB)6hlj4V@)rYEH#NNMb#(MdT`*`Tx>&s+Q^zt~#UaA@+rv<d5
z&wr-qr~NbZ^Qn=3nxPvP;wJhTp~hWwtL69C&(P0y)s6Te`Z4t7WvTjU%ym+~bbz(E
zxuJJ&oCTh!QyRKN4Hf(6mkSyt-3{#`eIKJy?UegTcntj$vKE7E#^KpOcpMq5LHfQt
zJceftKTHi%Z$+<9hiSQ*hrDc+ASr#rG(VIzDJO7Es6I^kJVeOGjtlS!4DbsTQ>%tY
z+(CcVpf2McWS+49@uf=K^r0&F|8YOF6{kX#xIOM?mMV(A?W*r*{>V^%RMPt+QI&ik
zMebCtjsKV9IOTsHNy6~_G<+OSd9NGCQ}UCcPImGc@rvg8*z=-z>C3hkC!L}9Upq7;
zB-r$DPFJ2yeR@bZ4Rw|1%0z<ASpQ$)HtR*<d{of<t)QB$(_IC^YS5{Jy!Z-)bq0Aw
zQ`)HB@jrSVo>Z!-X+Pa4kBd$X@9C3jI9p55pgC;Bt=2f4d=&^C$6N7HS5!op-<a^>
zAz`C^^eqKLOG}@|E%D>&O{>`ZHPqR*QiqnlOMku<@upSka#H47QD5s-NN<l@{4fry
zjH#8a2S`}O{U*X1`Y(j_+3%UhVU_prv%>1das9WbC&SuSEi3%V7qayPDXzQ17Q&io
z9M;EbeB_Cw=f4uBg8CDE`*Lr6dG=(xE|BB;_VSadDA!1NA!AqNTUUgdypk4%_;n&K
zviX9<ZxDRJG1oFi`TIHX6Wu+%J=VD|C!eKr32#B2OISlWuJ6x%GJcU9e_s4tIrpsi
z4Oi1IUyWaV+(}tq3${|=?=g;F!RJ@X#1|Jc{s9qw!z3P(&bG*>x5s6+mXiy(r=bog
zaTWLaxYFjOUMg{ybQ!6Jds{Ve!FNh9gj*+ZDQlE21;eeDktPP+<ggpRZwz7A=ffw%
zZqT`xmT<DsJ)x1$Uh<5~m_^rrIqdZI;g{$f@r>=U&aF6Gu&gwEXU@{<FO@Do>1&kk
z(k}_0uReUzrD)VvFsdu59c*&-^TVJ~`_{^plQ2lSVx!zg3Ryqios!0ea0FHtpY-|>
zJxO@B6OPdT58)V#-vz^A=--yLxnz^-gM?X{d@|Nl_c$ESRD$TBE^eQ(J<@?AC!eJQ
z!@Yf_<A_bF1d`9CY3I$o<6qIeUleaygG@H#d?4}O^Z4FsqtLiH@UNx4A>Ll{(T`1@
z4MW;Xyfa_Xy`L3t!}IBCuiRSJdsm*(4oD~Nou$9Gz7A_jJJHZCrgs0h^=x{XXxuKA
zaz*lzzHf9)!1zaY`z^|OqbnD}+>G<r^kG!m$Nbb3Y#$q!p)!V9Hsg2>CZ4Vsq@aCe
zdORQ1J+;yvHjb*vWvFo**AQ2I|N4`0?L<855^jlWPklHa#kF8t*Ep`3YFry~ojgaP
zOR4+E8^^Wa`@)pEe~_|*LXbcHnfk6PSnoH~r6X(O37c^km3se+!uUw{FMg{T1=Hkk
z7Oe9d-o18po(`wf`L*SY@=ZZqn)L2{97>aQ$$bs=21)Pc>URxUBT+W#7L_tv$`M!G
z`s%|N8pfCDM;%(6`&Y_p!#yq4!d`}iNSP%_{ZaRVd*b9-+oSh`g#B4%l_4z>)q6VN
zPV%)xTiWWe|8iP{1q289g$LlD=%yv|>FsfS!j+T8^&m-$p=w>NQ$78a(yWm%N<A9;
z#+ppyF#gT*RKIG;i_-0J*yJ5+T$W1M3}yYfXN0XEVbhd1%FCvN?a_0nl!1oey&zvb
z89w9kPr_$txB5y2mrd%5mLU4uL--sG;q#aANm3<yJdSOQUszbkc;k2S<BHjf@_A$Y
zmU|oe+D|^?-g~*X#|!Q~K8Tj?GipPo+_$HiU)&oI5H@))Nu1^VEAu8ppSUjt%%ca`
z_>SR^B5TS$o2d6pQ12=AE4e4P(|jX&)Ns#GAHz*vkfs`??JqiPuKKHVqT-jazu)5T
z4I_WYtNOy3Nq%=x{SKCgo~>ZsuzpRScO_S-I`VlsPyD@moqWc<BriBV<6Z^xfP~SM
zv@pc0le_@gjN?^^1o2SsWt8sEik3<D>Y(Z{={ffbefnNcMaz^p<q{7o`kqdg<NavS
z`j3O2GdjLCXIJZsbp~f;yKnu~uXBQ9-^DIojepy+VdO0O>&YnC&fDJ4>CVlF`=eVm
z9u>B#OPMbVC+{ltX?IPf`{~6!8t<L-&tKcf)U|{D>1!aZZ!hUF!?xJ)@%Preb8hj~
zZ<cS^TW!~h{dQ}Pj@tU(nT#X8IhV$hZXLzlS&KJ+{GdT}xt9Iw_Lz0C`Jf7O_f7p^
zpm!17`6(anKRaj*V}BHP=OX>yso%Z#n!va@%O=dJJSDJc-|#G#nNvJ_hb4coFP(SN
zB;~#<#_XE<<(5VlFOPD$7!p<c>f+(k?d<*TjSZdn^>2%Vi!m3iL?^j#pOuHkrhWM1
zB<t=oX9owIJaM7Q#H$TI>h8a{kj;Yo{X%$lrnC@uQSAa&E!}c6Vou}kC)yYFYE#I6
zQPZsUD~8u>(93^I-XI!!^C)b!7KvH6HFlBRoliYTarZkl%4=Wv@U-w54vCvD56<!$
zpAt$Pl@3&`g<VSK#Om|YTqZcBG~VRbCBN*`YZfWtd-<AAbqJ%@V&P5O`#S%h9uDfZ
zt8C|x{d1RueKl-J@3zy24cK$^!?ktu=@V7_t93YT)v|>PoG#wnGIxB%r9b5s`h1GU
zW8Ny~{>@G=ar$H{-~QT&e{-EyHhlPQ56_UchmJg0JnU@3^zIM$r+-`Z`}eQicyr3<
zwCi8>nng>M@P*7<|5M=VUT;mAUb0B>BX8X7ykl~$mRUXK6|359b_buvpD^D~arfq%
zb$Sna(8b>A&l=hq=Qo~-UR$<!yV;-pHhJ5|1DCZ9UurZL6nAmE56&-oVdRAR`!{(u
zZvXQI-|hQq4zYJHwZFuHqe+^dhS4Y4RN{LtVnS?jySZa}o=o{6rOe@;pB)|dR)yxp
zI)AkCmpgX;S06G*kq&V3K}7kp9*wqMZdK~TAHT~hvSv*=-xVKhyPpzK#P!a*r_v5F
zM^W)_$^z%6uGbbd9kA}BAND1Nr#HX1V&=-eweC!IJNeO(HTSr0$<E^62MrHajk#T?
zN3Y8pcDl7HH@ftcIb+{;?>%|t{8RP2SWaEbdVS8~u1;*v*y1fC;>sr+zWC2t+vq3_
z1+7JH|HP(t6Q(8R6q-2i8~>qmn%w%!A^WrGcMDy&y!msd`{zwx+o-#um(NCQsoZ+O
zp|9RA`$_WN$)4?EF8w(%ZQb{!zv;eg#}DVPzRwsa#of!-Kr(ghpnum|N&l`ji$*K?
z^yO<2NkfqGWoPe&XPoBRMP;tEaBJn4=H|Hj{*n!QrtJM>!pSxF){{>kD(O-5;HS<W
zuNA$2s^UmZV%tI6-%R*%mdpL&!}>-z)%juB)&0EGmGbI_OY5Y@L4$1G-e+%h$?p1<
zK3iuV``)tf)`$1nA6ofg1L_v0t|4XW+Dq-aNIX`T{Hn`{EgMd^EHO%Vc4oU(yUw`m
zUvQv*%N4Ch47ge8Jaq_D*Iufo__y`*^8WqLx;<<<_np~(H=A4x%X9khVx>aK$La@f
zw^`BGow+lLyLG>6hIZ5@W|eOlyHE4p!5Y){)^S;PXwar3OYY9Tzk5PF^N|&IHpc=I
zZx_DR%H6Z??WyIL^vmxvsP<=Zj?0eTKGpHSJ&$4<jj3xinYspz*qYQ@T>LAy;vbo3
z&))Ant@ZbV>~qflG_#Fs%&!Mux7$3`A<bqE^R|`z^76HpiqZJcS`5{_-Mj1lH%9i`
zbhG&G=GE+vHCy*d#@=_UmdmU^s*UbkAI3;1?uIPT*<Gu+Y23$4GWtEVnow-UvHYLX
zk2kuwGr}+9ujb2VYBX;v?s69o|JZii(QaeB3;$8*<Qo$sZ+UNj>yHx`E|0ChrC*A}
ze2wNuSGn);=J(nR*n6$|f>Jic_6&-DJIUpO)5STlzqu4YKHlrkdzthBEAQ#<rCaZ9
zdHK_M-~H_R)u!TqK1eut<iN&-C!F1HmzaO%UKz?<Q`b})r-UzRTFaESg=gDm-M4A|
zTb%1JgZg=VoRt^eZ+QLjKYeC9f@jFoHIO>Cm3Tz!qHRv!n)Z%QRiD|DjwX#Se9U&n
zyj5!=id5bAN#u%|yBM=VN1oQ=<!cf7wi0*OLYmqhJh3u)P04##eQy*iJ!ZwG&Sg69
z{&m8Rb+H$!IMGq!gq;A^RJva|GQ)A}QJ0wCZ&&^;$v^N=mT!2UYx9baTH9h!4_7)O
zmMZZL$jA(O(9EgQx}2g*Gd2zkv52|3(YE9VE2fW)ZLriOc^UogN<CuN+G2-$z3E!G
zO*8lH9S@$Gb8B>V!qnDfeUgHDXlsqFe3LN}%KL3?=`w%*aB1|gZtbrvUlI{#Gd3VE
zAo%Rn!GE^?+I`MX@>RxH@$dbJ-#p*-UHoxO&!BP7S!0NgX4LCk#}8X~=j{`(2WZ>f
z8TUh_RSi8h?Wo%6?jd*Q7Nbs2`9h;Ps?-zb?Ei7Yjt7IBhj{(*acG$9sja8yB@~NH
zUC{r)-1r}?_F7W^Q|?=`%f^7Ym$NdC-+p`k@T3Y;8}1&~s#xT~#p{!7TLlDqrkK7a
z)d&{}-{i4hX7&DV-<yX%+<Wo;i_3QATU^|%J@{^R%%rH*Wo{;L-#?UmFxW41Yk1Ea
zGaMX?x@odA-)L9<$V&V4O}mP1$@%@u`imSXPL*`CEaJ3jxo_>BJ{Oi$i`wM!mHqCD
zpI+NA=lkmCdJUfZK-MDqMM<}d%@fAvPsw}m^`SEhYi3*<m~v;}gV(wQZQ0n(uvSeI
zrJl3D%xhDo=FOab=S`0X5wX4chkG=vu`04=&qU{)wPS8)f6m+iCEbSF74DOm*m#=L
z!nE~6Y@Oencz(#eU6baVoV9Us%-H-M9@r{Zp0{dMTmCTd(`y}e-m=(ztz_IUt!i}C
z_;=cM<my}fMmu?S$ipU*5|8yiSnZB3w)#Ws_V&j=`^|B_w&z<%Yc=@3{*lsUtG9@5
zGZZ^lN;~h=mCRu`?Asi!k<&Exb-%-(SA2WGXFCh6Dm~3-d*KVWE1ttHg%Xd4E3VBy
z|K)~hm+vgE`e~U(yByysls&n%Ze2V3r9I<55IYp#Dfhk9r~QEuLuWqt&t0>~)U|%>
zm2z_Aj(0Ba%o#f6^iOL)t>@U|qei(`R;~`XKW%++@0rzH2Nt5ftGIjlnnmF}o0Kod
zw};=`)c(fdGwo7uT{<*6{mzuS8LwB5J5@YyhgbfmC&;Htdc3-|jcP0Ts&lcmS!uad
zDkYY#&~Zk)$}3~*O#0@XPH)tSjNWP4`nT@XOWG*?2ir#^P3$(K_lQCJtF4|jsM7r1
z&i(zJ99jj8UzTyr^XBW9u(76;lQp&$O-?92^n*GL4qV80a_LoJRjISzmGr5+d~Ab8
z4?Vshubgs{_-1LozId(PqDt4R1$N%=cj#`fX*Q>`kH_zJsJ|-M?^4H1y}cFMQG0E2
zmJPZxXK=5wJ%`t8GV9}+!$b2{&5Vg_G;LX)#i2NCv$%<W<NUAP9{kYi`fEOpZ`)j4
z9)B=q&V==v$)4kCcKB}c5Lv?~U%9W>!U3gsuOA&-any;_|L(Po%5)XItV%s`ZQk%h
z*L9IMU*DRxdfYo}zg}mNFzI&osv;wn4AfCCd5sQstwqmsuWvrmv-1!8j(VTp;?{I)
z_h$E(xB4Jz_>X;y-#)tSZW!+^rQGdY?5nQvmMuzURUDDA>S+GVL%%ng@O?~da`5p_
z=M~xBiH`=2l=~hJTTr3z1^<edBeoVhwQkh)3$ClCjGBG(>!|OqblKcB&IUXAN;`g}
z^`#pggWetOG<xai5q67KOilLHmOnSFaj!dHW!l!CRgLf6iht>6mfJ5${k%kM^p$ej
zTm5|3j{Ek52}>O9dKH?Q<{taLC*RZ*cdu@3o`Z^iy(gbcZBhQjlH~_7u53HBF{QP`
zpo%5_YV&iOd9|ueN*lp5o~yVkW!0r!>cE<b|G8@=&FUukAp5;KuiKnWIiUL?blk*;
z9R{_ZRBvX5m0`EKf6)E6cQ?x#NE;P*KK(-TtU{fxkJ~e$_;lARjrN>(*yHPWV*11J
z>l-z1619}^smlBJ)vaxGSh;V#E(^TMPaL;#_K`Ay_g&Jn@0AbloONma_=Smnwf60J
z`)h3WDg8||GhVwITKB_}Ki-X6aQD3rrw{6qyDhcl$g7R&k6e+l+jWLUb6fFmbIH9m
z$CfKTr%dSNMLS1p-Yqw4(y114mBz>ZUh`y&38D0ZRO>E!iStc8Haq(Ir9)RT`v;`;
zt^3QG<CS|v{v7&Q=I7@%mKDC^vkiHgevp#iyYJtqJ#?ncnZmn%{_&FcFGGIu_U?9l
zoi?<7{c(LK(toPx<=c_l)()%Oq;2x1mDjqTKD_VF;7u+KbC=gxFn;)hlY`n(Uj3jv
zA6si|cHfoQVRd-W>_6tNyyEfB`N}tJhgo%4U1#^M1(wCe@U21#pLxxq?q|QMX<_5k
zeADm?JE|?Bo!3m#V}H+icSDLy{Uy~hV%Iy~*PMTy{Cl?s)xJBtWI%ZJTZhk4r>jAo
zTx*e6Bck@2B7dH3G9;%)c&GS9O&$BK`f8$Y_!sN0YLmb0yAiuuN_u2>`Zg@ML-^=B
zojPwB*85DM-&SN?o814h_Wkj<D<^!tX#w+^mGqeZ`JJ7WX8swS?dUnIYsY5!eK#B*
zz4ZJ?;a%#u<Rs-)9*EsdrQDq`szz<ylGtMJMsKg=*>Kw2i|u2Nlq*?o)uON0eG}7Q
z@Oj#AiaXl_eJo$^zhFjc^SBc8`wp=A$@~BMnnkA+J@3qOZgu2j(+<@h-pk9{tgErs
z+V8U8ov!&Fc@u|c&s|5`V-16+v=(1xL=<_i<$LqX726Wq<(FQ+Pv5Y4{EgZV=A0X|
zWbN3Qt2byge<}W*yz`M}->F7xoC3f9&Oc_|&0=3nui&tCuw&Bj+J!1rse6I(8}vz-
z*DU&?@UoC%%L`Ti{BrLFf9BfX!}i<jqL&Kq+)pX9xz^b~o4xx}qvLP3|8}SS%?s7f
zt@n1A+AZw$#njivDf+wVJ~}SuLPWm1pS4SqeW9LTmfxJTZo#$sL$imp_i44Rsz&pX
z;;vn_DcAlw61s49*YxG}wTm;p`6H&@rjvV@+&&aB<MI(ni)Kpu@>29~MW@|wbJ6A3
zZpkahtsK;AW5G3xZfW#$?^K&Qime?EX)M5AcG%ntX>?_fJ&;w9J&|%9RZN4e8^zvC
zd=YHtaEvOEvbDt>O-@ZaB-MG1EAkB_Hj;HROrkT=5!nT4@K3c<^Gf`S#BbHUjAEZf
z!dHqz!E&6<mitQhsvuuORz*tqsv&D2Ya$yX?U7XDHMNkaRZ|B^_m-v}vKNy1{kpf2
zjgW(pj!21*++Vc=^KZF-4EI;<wJ3I6B>s|)QF5Fuk>E-EX?E*q&S)skb+*V&NUE5c
zEl7!f3X*1#hVBg|e!Tv5;>R}RJmhvH*J^emzelDb?;v*}#cs@Qr07G!quOElM}#Mk
z@Tj&`G*j6Z{ggm@gKVU^t~ipaiLN}-6={d08lvRij!2qMvKE%2A6}cfaDKZX$04ao
z>8RQ$Yfnl1<$kIy6wNgDU&a08K61bDNV%V+3q`h~?>+3Rc1sj{CUU<D93wrIjcSrk
zo`<nWiWUuF*Y!n4AcrIITSt{pgWtMXB>7pl3Q3%l^yXf=z5GUZx+6&9q_Zf*IA){`
zG8$PMITK0QA?dHI0roC(7r*BqzeSRVbZ3zBk-s7rAjR&=LZs+zkD#{?qSy`jC&%No
z8jrJTJnkFC!-IIJHaIlC>`Od~A;~|=Hi-C2ek1=W&m(1tQZD%*TXNhNNzpE4i4M2Q
z+HRsB@mIB#@k;&Gir=dJ11UFj1eWM1<E;_OT5@uKEvR-Ul=7vZJIOENE)i7Q5Q@zR
ziGO*H#er<NQQ~_WS%cq{A-ej=JS5dt&0k0<U-OaVS<QXq1mpvx<WmBtle}FBxer+w
znT51ON;y;nN!hL`ifn-_jvS1{9)T_xSqdpOEJ`B{;Z^M}{6~aWOI%fZ2Fkd@g6S{{
zJxRR8ooX}SneGhfCGOPu_{#hEMgFPt+Mnsp*gth%xH3QcMgFPtwV&zE;Ge66Po01K
z4*T(C^<z9GugI24G%F(IJ=7lg6*2_52PyeyFH-d33hJC=WiIl+;*UBvSJN0jC4cj$
zjEzQUe&Bxcd}ku7AdeucA&(;+kSCCa@ThZY|0RDM@l%}#tIUt(=M(ihKk|7Aj`<=*
zPeavwFW0GaOO-i~{Cwg%o)IM;A;{M_$2yNnxaB%^?&dSETclpMSiSB8qwCbUlz;m=
zbzbA&zD}KIsA)}@B_CQK?LoF194d{xiENG}O&-Nho%5&61uS@-lv8ruT_o>hrM!~#
zl(Ji$f2YjLlj|%wCTT7k?@UGiQcg*JkaDUkQpzdA_3HdKrF<`VeOdK-YxVkaNO?b$
zSFd+vU!6au%+KQI6Zvuy?j&DEA*FsW8Ce}U1z8I@6=}$q8g)K{l*_Ui=WkQ}k$mE+
z`XlcZ*^KqSl>3Rl%aEea<?8*l?E9+MNxdZ=M}?3!ARGQF;ncFP&Ph_nnHO}&v-!xK
zPW7)6*A#R|+#k7%SKU>9hP%2(?)JPOd<~4;sq<!@8NN4FcdpzkOZD$9xo?5;Z5{4J
zf4o<f_u~enT=OZi12PF|NH=v3i86-wf9j8<n>s&3nG?a!C(>;`=_L8+eIz>3#H#5g
z*JY`5LmIL#n{j%-=sI-{!{54}7XQ_G1xo#*V7jhU^&;-nxd57?>=$(Rk?KyKUv>Qc
zqi5Fm`HfNI{Vwti+|EJPLB3}ce|2oVVxK_tZyf)5+(+~_A1USV`|5o~Z|b=BzkQvf
zemt{MACq_)->)g*lJGY}%6*-T!s+pX>#*^pT-Qpy&RM-q%DPbXIwhZSKhdWP$aaeO
z$o)<uC4N64rTq9ADdp=gNXf5fk&<7vkg577<x#<Op{?@B-HjKxqbyb2i5}H4*w55Q
zS2bSU)OdAQ<0aRr<Efu{T~GD8Ug~uoM%Srhqn~-5)H_5UUn52T-x!5c9q0Va>-MYH
zeXCxVj?6&OQQp*{VH+F+Srfr}Fz*+5*4o9gUa_oSY*@3{hTqNLpT2gntixbfzu2&5
zv9G*z!MtuU?dvwwhry*SeGRY}H0@|lf~?z-0O?@u%KH}rVKMB19I$QAaR`Q3NQNx1
z=HYY&e^?BAARBBtaxVymIM@ScARp{HaSps83gRFY&Okocb>=*HLlne8Dx3jL7wTf*
z2BxfA>`MWZ0w=+tE7yTPM8RVC-&og}cYr1ftP9hghY0wmtaTjU2c1JAVafq}3*L|L
zzrFskVf|uRyEuh{-FW?C<F$+9d7hi;$PdWptzCSQbB48xqiBQ})-RT|i-Ym|MQaz!
zy2XEYt>VC6$V*n_aX1H-vnWH6FI%Tr){Qb{t>PQR$B~AEKg7XFu>Fg24Pqe!tnT3k
zydfHr;083yC%-`ol)BGz4QWvK0qG3!VEd5pLk3t;Yn}_%bd&@_8rT&sr165qkP7FZ
z84Z(YI0lw9PMU!?L_-oB1A7`PE;LkP;T*IqhCdJq8DPsoU;dB)Szt@2OEd5Q9VEdS
zu%Z*DC73s}2Fw~TYrw1lvj)r>Fl)f90ka0o8Zc|XtO2tI{)rl(J4N%5Hnp-@Yczd0
zAnP88oiCY_DmF`|&>x|!pUtsv`8}22g*Z0@84Y4fWioOP=O!Y>jz<)78cYZAPi!;4
z24Xj-B2<DmpbAt2u|uXs)_{?A^nt(_sKf6DAnP)VjUPu4+mt8pvkCi6p&5j5y%SQx
z-5l8hT0v_tY;t`h;gPtAUFJ5>9y&s2cni8hcMw})J&--Y1NuN;=m-5_01Sjd@EL9g
zBfmxtLHdFp3<KHZnhD%<-v49oT;OuN`^SG%BXcUt#2jvfoI_CwA%qY@h|UR7DufVn
znA0+ukZG2QWkR!@wpgqY3vF}Sv@L|3woE4c-=FKg@3~pj^E~_gpXd4gx?a8eT-SAf
zukZ159lqD~{eC`3C*(@<F7_!`Lkz5e_h2o=!UhmqmGST)B*0eK4oR>Rc7xc}{0#QN
zA@~BMuG8TwNT!~?Mji+8`=MLhC7<94-XJzt{UHD*LLf+cNS#iBPzZymFdb&VEReKj
zBj>_=5c_9~K-yp#tb}NI7sM}=EK>d;>OpKfO@R;y1@W^z6{f*-5PO&5$QdvbW<dnZ
zhB+WMsbtXCJP^B+3qWjMO4}|(E`r6d1jILoEV0D79yY*6*aRQIW=Mc-Anh*gxf7CM
zH>AK`_zd=eq_H1)0K}%5*i<_V(*Egi6pq1HkO8vjbZ#4Y5u4+qi9>f@B(N=Z(MPdQ
z?9^`sv9IsOw%Alp0<kMUl5JhPyvz0gZ5+BhuV$a5BS_rK*zV1`{4U4Ie(~+s2PxaK
zUl-1ieR7WK!t`QW&XLo6oX+GtJcE?q<=hvWjT4X#$S~wCe*Xw2K@jMcZLA;Q+OP~(
zfNmMe{$VfzMuBemnDtNew#6UOAmYzPkHy~2ImiRayYBpmCQN_ANIBj@j)ex$2IM{J
zUVi@!0$6VblR?VW1H}I0M7G7I+EnBT(q2paSIKLhHos}?^8ioq0e_I?2=b_QeGSLE
zaJ)Ns!Wb9_QolMqUPTyZ_DTJU?*R{J2yI~!r1JYd7|*%|1i@gCIOG^vmvT!vZ;;1Z
zpsRzG9M_lM#jiv>d;r7QZi*D27#omr;L5(YDc5r7P2T%JD(&jW{$Q|$P?!$7e2f3P
zer#_<ZiWwG1lz5V@53e-#<o9%fE|bpVzD=z%x}BEn|+ek6xKflU$(`Da1GYqgS9Y(
zeTFr7w+o-JEw;41*eChe&H5hjVLKMN4u-N`p1fOAma)XGTMXGJ{!evry+wSr**>bR
zuM@<V2`Axq_Dg+8UQ=Ny@%GfFd79tPLN+`k+%nQwu9r?U>+7`Jn~)!9*FQpT)2>UN
zl3CxQx4obB&$Zh}kr~?c6UdX=^=jm)I_Q?u?9bNzb{=_AyZ$rsigvvmZE2v@M>(zv
z>(%wPt5XJ<%cNT#aNHl-V`X0r!oHymZ;Gs`cWh0LdsFXN6Y}<kHh*>4|CZiw4Omxe
zw`&rAExj~4ux_p0uEp_Y+BiC~&sMv?7t%?)-WS<VyWSt^tX&_7bkVMtCk{hxJW`H|
ztQ%>!T?sQx8*U`hUAyj$^wX{fA}4Ft<@hkxr)#$>6HirbTyxo{^A#iKV<KhLXB*qw
z;bTaG9UzO0^DzT8Sb{USfiHwXG{i$D@Cil5CkB;0FlRxv1Q<)C$_5qBWv##l<ojF(
zWJ3<fH?cx6<(rr#*n<<eLL4MQ3S>b(7#Z>n4V=IgJRt&NAqi3;8*-oss=UUxEO6l4
zR2W1-JfuJx$TxgfzDapPAcSkbPsJk-g7|98h8!pYGrl`nfeVB|G$et1o63YdkZ)7Q
zm8dt!2KU#A8^r%&93(*w1Xd<Jh=OQHf>cO{ED+y(g<wcSsKFkbz!zljcnl;%Cgg$m
zSu<wPRx7XpR|tj(hy^poz9c{ah~C9OJS0IXWJ3<*Lm`-Q-BE-1zH$Oz2!`d52nRv#
zYq=nUed>Y*ID#hx!V*Y;G;l(%&Osi?eIyA|Asw<H9}2<nP09hSzy=(_6Cz*<BtRNu
z!(FJteZm6de&GUv5Dqbr44L3sn|wk6EUCk95D!U^0ojlP`5-pxOhFCy;0C@R1B~Jz
z88SiqC=`G(*PFUv1Fj(V+X#q-6p&|)Y{-SXPy|K|Xb*4#SMY>Dh=3#zo9^k514Uq@
zCQo1q&fo^V5C$<24@r;;8IT7BplV3|z!6-)9ReU6k{}h*Aq#S#N+a?G=3oV4b2|{0
zLmZ?*CY*yjsM46SgAGK%L2zh7{E!0aVAzznAQ0jp8*-rl44V;$1!aOLhylyy)B~h~
z*nbndq(&`B2W-F@+#vwMKn65LLoytMEXW5{OUe#b-~cWV2{DiasgMrYPzXk?C^v*b
z5?C@AFaW|K6*Ax)<g`UMEcqQWp>8{L6`UXtWa3U7Btsfx!a2x=0x)gQ@n8im;0s|8
z3ki?{xljnk9f%iP!4qO30g@pDE<qj?fT0!j1CHPVfgpnumqRQhK?dYNJ`{qPHRldE
zgC~T;a!7zwNQW%Q0n?7;8(M)AxI+L$KrAFfI$VOgPy|MuNCPau7lL64#KJ+yfNaPG
z8LVpw_TU6=5C92~3>k0^ilB-uae^BpK{6QHQK#StF5nIU5C)MD2Pu#SnQ#sYph{=*
z2<Bi3&fp8d5CKad0S-dCJ;#8$3t>SfrOCLTG%)W<S`Y>C-KaCD;(&g@IWX!@{=gB;
zdQe7igA6DHqn_j$mV=Dxsq08SAR6Mqsu$Z32C0w-g(7<swh!$Bz7PZHkPW6zqyu7;
zA__A5a}2a{rk=qQVjvx|A$TCyc1VT0;68}7AsL)q2n*?u4Juduz!&0&QARKvPMVMj
zh9g*q#8K!Fh{F(LNQGP|fCP8)4}}mlj^7{y49C-k;0eZoqz&$n0fv)^7c7HG8^R!K
z3i=R2e!v&hp|l+=2j8jGCnP}*m`<auAb&bCoO*>oNP=^a2WB%!A3PyoCS`_fNSs5x
zfK0rq0%l+imS7L9B58|xNC<=_(Ak8%*QdXPl=lqs{CSvdc}`A4Zezdn3p%ka?|CY-
zE%%JaY)e0QB-_$YmwWb?Y%gJ3`ZDE^(kGTapY*Y(ur2+kSfun-h9jl#=7*H`H=U5y
zNV$JY-)A#Y`YNw;yu1_h)`nZlx`ZF0l^*Pu{@rY(<X@hlCI4cFMf#tEkn#>=5>one
z@(lYG@(xn^^%3ls_dPe*mcD-_wxu8b8{1O8^GJEGAkVClkCpr`<sFEe!T$Ez@bWw>
z@9VtSmUmWzkx@u%r1X<rkn(ON1}S~FX-MfiimfTBXPMX~zegdZZ}<gL`b`^=(vSNH
zDSfq{2`}$38nZ3^czOPjzWOls%lj~QwxvDiBBk6vvR~eT$TO3)#|rjGA_pMXAj_7r
z8YruQvKlC>fwCGXtAVl_D64_88YruQf4v3_iDInM3!;x_=N=U59^^g2-D{F>M=Spj
zKle%FCr|VXnd}$nj$4>e_o@7M4-N5g_w@^%7#0*Pn>ZVB51$k!$H@`Oq3)r6VeD_i
zKH|4i*_)K}q<^V;1HW^*!A5_|0poo_f<lA*!_*c-nyUu|hmD^!e&+be<J3LzoH{<x
zFN9a3<|ZB<(|kO<!ootvd*e+t6rZQ&CINnd!G0n7du7g^xrtX;AZf@k;>YGiM?0D@
zp<%w*NijDWF@Cad(DYE|s+pVg4w^dI*DGv%&}2=R?mhaJ5XRYLhbes-t$(N(15I1Z
zF`}={>NMo!HqwWAT~&@xS3#2|1x@y#TJW<LGTzHOQ2a&dJiv&*bgh?}=X_psU@?os
zE_RAfGfRG#?`ng}1yOU7bMcE}V!}K}osZ5?4_e71&~KVwpofoFpwx}VN2&B%@lhIz
zZ`w&gco&jm<u?bUd}ka~PS5F%_BR`(j3Xeu>686@J#?wcai07(Q7<o)&exB30P-8J
zOtks*o1*xHA3sjX>zgVA69@8|UY_rogt^p6sVmw;<Hx-*`^ckGrc~DD+vlKi;=k?r
zyorAtU0iC~fq9*({KlHNq(0m@R^!i9?>Mb*R{1@c-!)}^b==X!{Sk3nHPOT^Z4kh*
znmT#rLsfjGr~R3x51JK*9-EjXvrp4rlf5SS$?JX-lZ-$2X<R%>S%gtqy}J7v0a%uz
zPoh`zku%UMb@P8vueAQ8x)O)tXNGbVvplC;^6mBS)-Cy-{W9H>aT@=OZfWxQSKW%G
zz0}m7=+=VPuhuR3ruQn{lDHy>OLS{>n}1BVG-ZCdZb{tv#QiaGUu^rlZfWYIbh@Rf
zhv#)mv+sG`()q-6uBg#~uSmBNt4EM?(XFfwTHOksp?{|7E=`L5aB3H~DEcGkR3yJ@
z&Z(e4U;S9vFXxR7^4a-3K8#JxHSN#+a-3$rTti&g-xx%9!a`>J={Q@`a$vuVFDkD6
z<hoEm-BzKjod{Q;DVuWcIkBzDgC-r_bwt8D5&jc?KWtT8TmR|MTXS*~PIun+(4M#Q
zJyRC_x?N1&8h0$dZuL&jQrE9WuU=li&vg3v`qk|J$Ld$cF}<vQ#s5Me<(2xi(v<Jd
z`qiZMeEmxJM8Zq`mh1G7)$ast{o0GdvN(f0!}NjsYTjSkDDnAC4xNfiMxUu6A#!ik
zzwUF-n;i7ak(vHalY?-uJn=a_7d<UzQS@Bee6lt_Sue>?^52l37j>hgJoVP*DfV?u
z&W|Cg!C{CI9kf;I$e&yED<4ASKJluw<o@MAoEqQhn(L07+j3rM?ze${lgEVxu&L;S
z8mWK2$$4$TzT%!Yq;7S7n|&)2h(*5~u~H7ZlFIR{=1N-@ji2<=l|^5-b!92;{w8J7
z`L2}l2(n0fh~A3YY?88cR?4DzY!yGT9yoy?9~P=nMmxLbJu()fwA|QV?mtfB8&dM2
z^HUjKg@jr3^YJ11uzXoQbX8fptduG*)3iSG9II;bBDx^?k?Z^}^5XKcyh#1v7+9XB
z^=m@+WUbVhx`o;&XmV(nx@jw|+hk?)&*vXak}v$%)RXdTEx(YVLFMedLdJ!9SaP85
zzV$JA)9r7^eyP_v+Ok+k0a%)YteQg_;iF$xmS^?)(&A`?=#}V&J*8-SU77ak<z2r_
z`}OuqnX0L5O+L}&S#^xxq>Q7qWjt4nLa|suE#OnW>J(wJURFkJdxiOg`UHd&*E(Gl
zeJTE0WBKPZsRQX0*CtNv{`!Ud>z{Mc)#X6Og@fd`9ehW4wf#%Zxo2&n&GHNNt<@>2
zsnq!{uHIjkZ{2wjCJ+29)<D-s89(+T`3`<rzV+&vM>oy21FdP=YU<=r`dog#Y7Z{>
zVI8erJT;n1QA#{#bvh*DOm+INuR}6+NVi{fNWwc1uYUOU?AJeEJn4tZqF=^qlrimP
zWqiJElwv+>omZ4pFOU?rq-&+FtTOIZSEkaGRX@D0tn;<!jY|!ssLz%4E@d_D@)A9K
zNqg$9YbCX+Hk=f<)a5Pi{F3wXWo@e;URU0w+Vbkgaq742eah?kvhu#NZA&cmvliAX
zcxl_YxbyQ><<<|cEBA11xi87d%JLS-{rycS&qXr%W#xX>&O9)^aDAlpN?Qi~wh&#F
z^K7g(PvN|)l0`pHM&v2yWqEq8EhJmTR&S~Ere9yWyy?yh8JjPQzMfPiZ^m6qJTE4X
z_X!FN)Kr<K)&FwafB7{*PK?sl?dMAW=daHK`qwu7Yo7l3qSFuEdEqGv!J=Q@T9nuG
zW#xUYEwn|}HOGsk*6n}QW&a=0sdbDmEbjWJf1N9-+&cf?Mso9IX$jSUs8x04ym(o;
zpPd(zpPd-3xPxh)7vy>Iugmk#a54v?xctl91Kobfzy9-0YBBk2Og`_vET7M}&vPe>
zCby;6GnrSR%a{KBrnvle)b{gQnQ3aFHo^$xRF|<qmfe)|N4gGrkIApfi|Ws3Elc7E
zhC$^#Jp6+~CdnIOsUuyQ@!B-&5Js+Xath0M9+!VH%_+sCse4~lR|?1?T^H#)NmokB
z8T>3woqO`Xl$W5zEq|6*>aDo)>e7zYrY&6+UJogGkn%?UO=-WX+@?~=Ec$ib1$~Tu
zmUd8B0AE9%D|PAH`BiC0Ytz=(tsZjD{!M8YSLbcC_bg+%S+S@=>RmSblXjLS?a;6g
zx)bbs)it~wzyJ9x$9)-n9?FNL$>Z2B?=R#YFLROD-!p)9(Q#e+(c1JIv0tuN+yYcC
zq_1*N&a3H4cZSW<raz@Z@#$;pzb8>C>Fb^&9P7%S=gU8Y^er{%dwBRN-?(1*ru0`A
z_S#QNugIs$;ji_i`?@3L)2}DqpS|!+N$O0O=fYz0Jd!+nzB13#$NT!}Yp*WHud3VU
z^IYt=3hGYNw#DbUfZt`Ff*&=nHn?SxxXrI%?4w#%&3{P!a6#vs1IueC&fGI>{?>L~
z=j~dZ#oXlX63*u7vVEUN{IPL{SF7E9ik^0gxRKCign!n;S&>r{>rRcm#5WoxzJ@jG
zefG6Yh5NJ4_Nb=%Xtjk;+s@S<TTgnYa*Jl>3okC+%Dmhz5?{cXs1>SDI#{&b?YE@*
zJpW%mz2tdvX48v)<}O=O1~}eEH{+G~42I2oYVciyj}InfZ281|+Z`|Gh7Tt%>^IJC
z(b=Ap>=x{09=DRewe@OO>}`9Z;~V``Do#7mc3#BL6Io-zmJR9s&WPIW4`lXb?rK*_
zckyAL*T0yZerrbfujv<)3e0{#_|SP@@1Lii2yvNSIlBjS<76-4Vp>;@ygA!!@^$N?
zyb8`IPu{TWyJthD!TljdpM5#UV(kpZkSghBO)<XqAa?!j2e-eU?cp}4>(%PNo^m@_
zr_+Gonsv-lKJsOZt`cs6Sw;Wpk2X)sjk)#Z`t64s9NKWK?&h--_b$7XdB!vU`gGnA
zD&@Uw(B}I!Eu&0qMpz73bgkp)n#+&QT{Fu4wa6=T-aB@A^k&8wE8%j(y{5J3KX`LM
z+|qS3me!dQ&|z3;j{U+pu7g98*Bq6(53`hXH%vY>_p?21uicnve=R7Y>8%+5`E|{`
z9!&|JdF1Dqz>4mS;dPYq4%v8WO8R@>&ob`6aB-mDx$myln|Z7C`~7_nmor`UczBR8
z^N%}8xQK3kn_~Ce3tQT*|99OhxOFM#yShV8_YMAyTMqKwQ#hKN)Cww5ZIGDryQ*$@
zf4lQfQk=ccPjovP>YpCEpjG1T8)I_Zrl)WLY|V=awL#sKteFj0rrXc3PHDHxt9McL
zF3qz$pMLjV^O3LB^G;teg88dT{u<TW7;-4dbYS56<|h*?zq5PGgYVJ~Fa7-9sMTY>
zYS_F=KH<nCzNzn-J&yFf_;hr?L)Ci)9b3LO<O`p*gS*c68JTwWy)70+jICATYjQen
z)4F$8Szo)iXZiG6u@?)<eKJSovSO3n2&)Tgtv^DqK2r2_x%I}@Pv0Kk8r1dFnI|zm
zmlNjqe|jwAtNJJ3xqY|IoKG6^&0C4D(Ae|LoO&BP{WI_Oeb}n<!}90no*Ur(c~OKx
zqm4dS4t>dV8bz=A{I<454U=ECB(>l5&L?%|4@h2oY4%a?(?hOje!QXi+)wT@23v_Q
zXvMaR0Ur$NGiQF~*D9TP>t3(@vzyrD3|LXIe!s;%JlcK4oB}0Wn>Nh`kABkI-1>ea
zb)zdgFGX#sUa8yS9Y4=b-Ff_my47cl@m9jceSTtPg{u>0v^ciQwO#igu6ph}+IXzF
zbCqMSA3vL<y6D5W?+#LbkHTg|SE{>w^1yQ`-=tJKJ#fd_seNj8tk~=QjXyr9>wD`d
z<K#O_xQMVCmtETKy<uDBz3;y+d~Ne)6VDB6QXi*;z2@-X?epoU<eQU(o3qNUgTw9B
z9Y$__|C^(Up&1<?ZCJQ*Sd#~{ozA^~X7eM`t=vn(t!aIt{*vFD4H$G|`vE6glSx(Q
zES)mcdGPFwE6=y+Z8&#}O7)AKgliT(FuIaWSX_;S)7QH1{MNVj(h-~cm>>S(Y~WeT
zM&_4!xZbSf?~&anciQ(KqdN8agr91azx3tdAN~G#-T3(SlnxWup50Nfn(^{Vx=Dp!
z4x1cicfIee;kS48aN9lqo5c2K_jR-!w`=5wBX*r$&p3GHx?%Lg(}nqw_gdBr=yc%J
zp!Z@TpTz&t!sx<}5r-$7I$`wgX~yIamHb^_ee!YW{vL}R_phpY`0>Iw7aMkLv-FH@
zEA`f-avM&5mCm;@MGxAK*s=7!y<4Tv2aKt8tNP<*eS6jG*6i@(u(^+a$=RA%a{>2!
zC4W1{?Wxmw)u}Juss2&&;n}X;mR!F-GkxpHs$ceBxBr_fx87mSv=YvCWkF%Hne{Ka
z<<=cLzeC=oYhk?_?Oz$YF?!(Yb#<CJbF*Eqgq!X(Y+dJFRbyhmS+PFulh&pok1Q5-
ziu}%WVcvzWMzxyY%R3KSDM!fn#?Dbuy$wT$Uh~`1{in#5y^O!w+IQi#^J^^)3q0E<
zF_xZ=oZ6s%sB^uhO|I2WaGg1MknhYTD<TK9dUF4^-NKA^wR_ZyyGLJJxo%vqH~aR0
zM#rO8wlhvR>e2qERVy<5`mFBx_JsWPdxzd0%()w_#25QZC-uYpcYZu)^l{8Rlhh7l
zDsO(=sP~o~AKQK0DrcC%dFDkc;neTXczj?_r72<6M()1QI&jg?5!E(kwY(j7uwiJ>
zA@im?m_w`R-~2W|ZoE2SmW_Q@(ka7JwaVo?<!)>~WZ!~D8{1W#*Vv#s7kuTq@&Dfk
z{UjxSPK~`U8I?Dfa=S`{P2+9ii}FL#hFJ93)2Tv_8~YvyJqhOirnFmy6Cc~Tyiwut
z`C1cHiCstUYm@N(BKybwKEuMSn|-tH)-mo|N;%vXSuIZ6YI6Mb-)emGDEH~Hk3Je#
zp|ShE55}%O|J{4P2BUkW^;O@kx3upEmA~jcZqN1$Hm^^Nyu7g6rbCzPkF7dB!e&F~
zaU<{5zCs5mKneHv`Kn*0#JBY)m3L2dVonX4=%cD-CmPK=+{}LKsnNU6tbMrn@#iz*
zxt}ZHzUl5)l-6^_ur`6M7Z|?(Y2`YR1t;dr$_T!=wE6Y5`P*)ye@eJApY~-w?M0ve
z`+eHefukJn9vJ-YCF|vNBeFIcIN5roJ6V4Ic<uJIIfp-*ac=XYZCn0+pY~^Y_rY_b
z!*rjm4~BmCrk}dogQ?%t-qhM<*Z%sB4^KJUb((l#&ZpQuVNe3~-09s6@0t%f_IzS8
zATfLH2dAgze}Bf2IchDJt&aNMwi~uWl>6Z9DWByG{`zQ}Q|}$V_Rh6+2Z{`??N*<7
zJ8#LXh!3jWOE6@vmva9d<CV2Hbl}|utt=}zsq(Vk>Q>{-M)Qnahbr#L|K+n5t1Y>V
z6Q|n1@HOjQ>phze^tigVLBuZmFU&u$_3`cPOHVe;9W-Y4lNEGoe^l~!tz*KJqB(_6
zj-0ymZsW|`qf#D>dh$l^@q2dmdo=dS{7F1Jw^yDcj#YbO&fLO<^B=Tvc@h>qXhf(>
z>qeWx8xKshJJ58=?|GkK!$Em2@vd8bNMd5UdDicyZyRf7*JkFGv5yYTT6%8L&e=<*
z6b*3UdZj!UH>hv(&CHK)_c-vY!RNOt$NgyAs3$Wu51qNyXZR#**B*t~m{H2H?Hi-d
zqbh#zo^f~cZ+HA`xl%o_&)Fs|PqsKywR*!&QC+;5BgeH@ZE*f(md{=DE~gvicZhz|
z>+~nJhK}5Epxmaa^E~#IzxsQvT;}B}<#@W`_R1@tZJ&4J!TS0iS6h9^a$32(*_|V|
zb~BG17`LXb7vB<<bgvKTeteww!Y4;ge>|n|#uqU=FK13&HYoe3#gF4h&vzTibFs=v
z(*5%Okh{N5Q|(w+Cp&e|#zuyFNB1kbTf^G$ZrAXdz3<-TUQ|(ej`$|=7w<{?O#;@f
zJy-PI=rNB94&GUjv+?`fym`|$I-U00O#3S7_T6O>o6_=|p;rnYO}%=t&X{hGW^S?_
z=yJKk;GFpb`YogGS}5t-9k*|{soW0JEr$o*TJhV?DxXYUIk2E;(>K$;tJS7XwLfMv
z_fH9T<JxtTpGTIzUFY|x#F6cqY;md<XlHr*(WcgYD>XOSwPZTqs2!vn6ZTKLaUkD&
z&V`FxK5lL~;Qh7*H#dIZ_jum6O706AIE*UC^R5yu?!on+zW&rb!n*$Ar=wzj@!tFN
z;^4X+Dt#PRFwr~t!YT3>s@#8Xf4eXA(XQ@yPhaYG@Yn07CS^RBW0Co0!?^R63irDe
zef%AIs<g*EqbJ=et@A85sN?C~7kZ3ZF#q~F+aIl_->h(Np2hkK3p40%De10zJnv!e
z?k@Mo`+Rv|=k_%ZJ1>Z6RJTW`tG}#E9ILvqi8^jd+G>Md6}RN17u2hrShZ%)1>Ndw
zjBYmT%V~~pH4BeAVA%QR{#*}a&ZXL5-?*fi{T2)!H~LtE4;GECz4CLr5x&-~Z2hLM
z%e?J+@6GEf)pe!a8ttu+oKVSoO|zEAuNGO`530GT%H^*sd(>G!rDfZvE}zn7=auKM
z9MzF)x0|o7eWyV{uVY@P9uAskdLi%I_|IFl*c9k>y=NA4W0i6&KWv)6ZuHHiV+K_p
z=-<5kq7N7P2N!NyxFoLaymf^Jr{Xm8jMWBHeQ*Ch=Bd%0H#{tdnqFHUe`3kf8QWB|
zU8gqg@%8Mn@tl`MO1f_Ej;#9mwn@>oCVqEtT#WOYhjUhr`>570@1K7Zp8421mltQB
zDD82ju>7wU3AsBj>^6!SaNWMY-Ic5%Hydni{f_5_ij9xnI!C=I*R_gAO{_2E9rBKL
zRi!*Q-810k*-zif8n)lMfBJOSqU~8Du_vVH)zWWrzWUH^z^I>_bel5nVasYED{d?*
zZ2$JD>)$R&A6;woWcp=FxZkthjf$M#XyZ8bquy?IYetV;7FN)x-=KsJ!ykt&Z2B!9
z1Fk6H91p$qso6El{grci74++4z36?T2jBKfb#FdDc)C%IqNkC(gX7(W+F;Yc?{2T~
zKXoTE{N9^;(?6IxZOf6Z1_`r%&)f9cxV57qm-4OLM#2rueRKDjfxW&tde;5Q9;Xg_
z`&&I;Z@VVK|NCK;em|S~kQaxs%5}F_#V`8C8+NLaQ)^u2rn5y0PyNz%#>pko$${T~
zyyCTejz)}cP}2Q2WL3>!SAA>U2-{on{MLzgt~zX*GjZ{~BM~QW_TJq$j+gEWI!d||
zjIZBy8U6Mo>q)Vb#?@WDVQ#Xgx<;-~yFm}W$TDlOr~&V+mH09)tv6qL@RQf0qi&k0
ze;w|*W$IUJW~{ZWJE+{;bm!=IT$y95ggbI&)wnB@XUAW?@Vk5eHH*S8_wN4w$LBw&
zwz%7t58s*BfO2e6!Zr9bVUcfo?Nu>TB35l)Sna*A<92lxbh!{@U9jz`zh(P5*tb%`
z4W51OV5b`2tzCaS^JeO)ohhALjjr|jA6<UvvZ6`-S?S}@(E=r06{FtW4vuP^xTwvD
z@$a{_{K52Omz0D`2DwGsY+H<oY0dS%PCqH{)=j}5wpzUDs}WIwJ^HGm<_+01bXYy7
zI~9l5vT3+Hdgpm;FDd7_&#}gd&F+=|VsN?jAN>BA<BseFC;e}khnK(JdCb8HGcR*5
z@2SKWySK&BM?F@(SGRWl{lmMjc2DW_&`|AqZ_DIEkE`CClK%nY#guUK4`qfQ`nYD-
z7TveDu<=yC)nWVI+)3&wF~{$&Zdx#_IsL&!O1Qjb&E7P<oN_$!o8YN4pY|BteOB{@
zH8+O*+J8;|pWoi?!AroMN;r?<!G%V_)_10+&8Rfr;bz;kE3MKzy}q0Obo#co9ot95
z@~uj_|Ni*%+-5cQU2C;<se_YM=um^x6E8N**lzbj($<T|8~OKY&i5DPJUXzmZ|3L)
zcFh*L3_SdUS7iCkKkxr3W5%62KMbCq-tPTfbFr<aq}#mrDz_Rlr|w*Qrdq&b`;5Ft
zH9~vkT;DeR-9)b@NB0js!h18N-?%XIja$JM?^XW(VZ^G3%ifzmx_3e9L7NG;+P0Xm
zA@g$w`pLg5@$IgBxbYN|N=vH+&t83ClIm@fMYGO#imN?6`j^J%I?V{?JxGK8(r$5{
z2eTJP-MN11X4VM5^kEi1ZvM8;fbbuJcVvBXMP*p?Yu=Be)4T_%eA4;YPW7ovT`rYB
z^uzbp-G3bWqq}>*J6qMkEm}++Hk0?KO1*qFA$5ySo%UUmcWu1g|HA2`560}WZ(Xpy
z(W>eGPtJ|*#`WqO<^0&&Xt(pB#2z1nj$i!S@{KoLrd_FX*UZPL#|O<mKeWoQBG-*R
zO8yRy9C_2HMe?t+Tb}3~5PH%g^w78d(c>L9uAcmG^`%{hIWIqXOY+z5(v+uLH%{#u
zVf}I2kB&@O>pgey*K_**aQbUiWtaUQ?IPTF%Jo2%5w>sM2j*>ZZyu>X;rfK}-)|50
zZ#}=tokt&kb7SEK1D+28m2_`r-CyTlam9_Kj^D1i-EX<&SN;duG+gpi%7@-bL6_!a
zs+e1^Jm-wbxe$Fk(!F_V(~en(tG1Y9ym9X7txZSHJF$0%N$RQVO?fY>wA+elZ+H}x
zb2#>0ze=Y=e`*$VXWxX@`zm%GwL7Rul|CIFuH*Sni7$AENmEs4*D(9k(;F?XuGo92
zsQ=|J8XK5eciiQFb$<ii)2z0V@*W$w;$hHhbALQ&7<Ooy`)#|QX8+Q!WrMFzuN@iM
z@YmD1JkvF*E8z+og*Dy$+WpJz$L2Q*b&Ox#!E*SfFJ^j%e!BIRI{C9<JDF>*v`3!f
zS0RBtLMJ_N?6t>d@TGD;Z^*nod&CX(JJWx!lW=6$D#lhT^|JDl2M1~|ydRZk>FU$B
zr&ZCg?cYv{z4Cr&?`HP-NriPr@tmmC^Nfj&nntdTuK0G;zS^#>=Pke1J^GAEWs^;-
zk8J&NNy{-;u-&GFGdn)S@XZmc798vt_xj3VBTX;5Pn}+I^y-ndx*a>%YveFb#@j35
ze$81GRk!Ptwq|p$8N}cB&b;b+eE!wtRvlxLCm)-;A)b5m9p(B`@A}CGzwOFBwJpNW
zV|J2ft?{SxX4hT4XYjpA-3I5^9G}PiNU7)KA%?%t8&Gdn#Mb61^}4^Cl{>xBJ@2$#
zXB$0?`Qkm7oxF!Tpp-ZK@#rZD@tJXTO~y|Ab^czv`g^uGbu#;)&$=U%>~^;OmHX<4
zO8s4#7<wmZ_x3#_z3Z<{tULd+%Tw-;_#}P#j-9qoayEq0XID*E+U;)QkfhIDjYn->
z|JKAx3(7~N=Vz?>)y}Np8ZU>(x8F`6%y}i<1BG_BXU=u#(ctN$!kpcajkXwj-SB$Q
zx5%Y%rhne@t-OofTwB`rv&^v9mf0*@X;N`dbnhPr{W5?1?&)`%K3SSOdF_@d3qRP7
zeK#e(a}VBE9X;Q6vvt79uYH$ny;t$m`88YZ9b=i~-?UuqdKOn1Qs*r39X4~zYN}dv
z<)gZH(^^}1xS2m`;ITLC&EA{6Z26P<?FyoKkEDdV=I(yk+#&dfQ~NXCt(u+r-j`jf
zHGKRi!@PG|r@k)NqZV@>)tC5sJ3IC2F+8V^@5<@FoV`E&>n(>=Ll4h<^FYYiMo}C3
zg$B_NpzYKKMu*~>yI+5L;kenb8k_f+r35!iZa5<4UE>~>cQP72l6ROYt{rLvOV?_9
z#%!PQ)s_>nuf<qicB;1M)4rd@mhWS+B5`wMogeC9H&fA<oQLmw^sL>(r^ydr^qVxW
zar2e8HW*d7)Av^3njIVSuT`CoUrgnFcE`tt`#Wv_#=$wY&C`7!F0%Tx{JNlu>&rF#
z<i_At_Y2G)Vdv&eNw?;-$0^lzH@SS@>g|hdzird~s{`iut~Siw=H6;<zmPX$cwU>T
z)XP2RNpVZAh7~z`8QZr%8tnR6jonFGSKV&moj10-hppK3d|wIIt-+kzf1C+^cX8j0
z^)1vfnP2|4r1`FMhu8joDr~`xGtw4TO8%}#{aj(*<1W|if9jXKaq7m=gLWD`_-;bD
zXY0*L?^^91P@u7isW#~R+X>eNJ^L&@)cIPoF*$k8dw=rkm0&q6#@?;n&wI8{Sj6`f
zrGM0W-*D>(_re}evTZjpWK-{IpOsHORORFTs@jh;D!H^fJWKHts&XmMH|_e$_f3_|
zWpjB=GqzrA&dHL<&pb}5c&!*|iR3XLvIjC5ITpDKxdFKsc^Ap;Cepne=M)luoH7?D
zase^}i62$faiq+9$wdByJcGQ7Jd3=EJclemUO?6)50{b6kUt^cL2}uS`~Zm>M;<|5
zM~Yp%n@F*PcN;knNnRp@kTh%L9Apu45%LN081gCd8WLAQk=5yI<N7Dk3W;l<$U#W)
zt?Z7hj`T+wBNrjXN9l*iH;`M9wUOnhvpPtzn^zZEA6XwMbCDV$ZII^3F39G{-pH27
zamZH4Kx8}Q3}k!c+ej<qb|ikEBaa|$k-s3Z6&TsG0?+Qq{>W~~Kx7Z3*y-zuT#M|5
z{0J#N|HN*e`1(7E9E>bi5&N6S8c0`U7vu=!Afy{|9g_ZE<YDA!<VoZhWIgo518ITu
zM2bB>Z{#SXFH+_}`XPTs4@9rDbJmo(Z2yX0{if9`(p2<nKJp0dw-}j$6q|{nS38lS
zS67gtS2vKNS9g%2SA|H?tJ>sE^r|KDC**2mE^-U<D)Jao^y(Z^^vVG}5xp9M6uk;X
zieAk}ie4>6ie4Q@ieBABie9~meu!RmMv7hyM~YtgAVsexAw{oNAVsgXBSo*oCZp(;
z5$!E{^#)S(stHo`su@!BsvA=D$`L7gH2^7kH5n;-6^azSibRTDMI%M8b|FQtzD9~(
z-9U<7^+P{IuZAE+uR@WcSIdy1SMMW5uXZ3suMQwZud<P%S4QZG=v8f`=#?W<^lCU#
z^eP@HdUXORdUYNtdet1g5xo){k)l`bNYN{Qr0A8*fz;_$8oHpJucpkk620Pbr%C}?
z8dCq2kmg8JWK-l@$QDTU$yl^VF1g~LHF6}f4RSQH9r9gdd*p{mZqJd4NFM1TKSgq@
ziA+aw3yZvm?2M$1#b;<Fb)n)C9yt=(4LKIs1Gx#=6PbYQg*<}njg<2v4YYH^{;SJD
zz3Ap(DRZ-=Jy732{m!~jUfCXul=>fv?1LPJlzNckwR5KaspG>rUOT@@nJ*;iS7Bcu
z$l^;n)sW+mJTj=pBhd-f1SF43s!2#6B#$SNe#lT{G;%6Z^kD{4^k61(J90MiFmeu3
z@~@<?nV0l$NncGKjJ5MNq?}?46*c?Q$Mi&PJ|&#xE5b?nq&yPNMH|k7^;g9gtqs?_
zm~i^>Wog54PQ5Zd?feX7-o}gR>c^*@521{weKDMVd9`y2iVde9pLRTcvElUN(~e^=
zHk^KZ+Hv2?__bH%PdgU7*l_ysX~#tuo9=V@(~MUwHk^KZ+VQu_xZGFePdom#*l_ys
zS!%}TscMVvaQ^A*pNYO+X~WeiCR`1@aKYMeavr}JUoE|G+Oe3*Siu*=ndya#enq<6
zJO0%B<X4n~dx;Xxl00Q;!>L(!B17En<$j|q_seN~!2gbv`_2QToL6$3b{wIq5v!hW
zJbzq`@|x?^8%ViMnId(^X~+L*&Q0o9KfQ_C^a8c%P0~wGI|i@V<3hE^g=vqQigd3)
zAKV@LfAD|VH?z*SXPJ*?>}K*{Beq)YyE5JZVn7~p%6v5Q?BAFBWj{`9@PtT+hcw86
zLNM#k@8AndAOX@KA53`=wE{PYfCR{Zd@vqBcrK(lQ0AkVYZ4FXnIQIWjk!MAgR96{
z)Ghp{`)H0|fWFY*sY_p`71%@eLe8llIj2|`Tlo5Znw{vx{9V49v++}GS{Xmb5DAIU
zN;;yD47p%gm2JoYr)v0HhI3#=M>P%%>8OT7DilG034V~ljE<{2L_i#*Lp~VOk+lM6
z@Pz~@TgqyntOm+zpsWV|eKo)<&FB38b!SHfzI(_#qg8b^_R3@qjT_rCkLO+X$y^(;
zV>XVLWn$y52m8dHoY-;sJAB*8IOKoDzn$2j6FW0vgGTZ?l{|{gw4UTs?6U;bXRaSi
zfe;9VFqjJelm6$#UX1uM`=9ccCiB0=4#o)(dmP@BSA5IJ99Wq@D!#U4zHKD?@2l|{
zhLn10!G4`zw<z{WJ_oZ;=J_pWTkO-g=!JcQ-)cfFs10vHJ!k-;18QU=D9MlGzv9F3
z-|53}3S|^ubK*}<e9h_Vs|#iB4n3h4^nt$6A4Km4AP0gA41r-Fw(v*5NEij9VFzKy
zAjO~HtNcm+JN+4oe?;*=B);kzf*~(##12$6x*|5F`fK$?^udqc#Yjwfn8AMW<tKjp
zWRCnT!io(H(UszS(}}H}PeAMeiO)dsvG>pV=@T0SXW%>VB`)#PC-bevr<~01p2t2p
zCwj0gb9)!FF7s@cA;mV5_$}1=i!<Q-5gSy4*eC5T?JGX;UL(BNRhY$oPqxJmU;*L8
z?uGa>6+1fzL2Lqz(Z(nK_{Q-POziB)HC5)guH?5{)RFiwlyg+-QT%a=eZF4&rtg<g
z{Pv08J+V<B_6RC*yx32eLpbpjIEZzbw;Ij1`1TWjgStG6u8Cbb@dYSz{Wo%aO~Q&j
zg1PJye}Mm}pFQ!x*ajpo@gV**#2?{B(h>VLe#9&Hj}xS=?~6~a)u%z<@1Cx{_5JgS
z??myND0$rsAA<NK%q4EI9W##j#h;=0BV0y0%R#r4`R&ux#Q#;leR8hp`|XqUm-+4^
zsPeAV6B!8dZD$F@LN??;J`@36W|bqjfIH+t0jPMMssa{Z1rFd00T2d}5C^Fsc5ri`
z2#k5DYX(-}0)Y??VrMuR4#GJo02Lq9>Ovgvf-QJw>kDBJ3CkfC5<tHDr$Z6Qx7k=o
zfMgIqediz-?t;!wpE>U#EWsH9;6;CZm)KVbrt*FQ#4e*7_=0?Rje}HhsLZn%<bYxW
zuL^NO6c|<GcZh)HkO@U#Rh@Vs4wB#?WP<qE6Tf=SAbw;D!I67Uq}+cX4iX_1vLO$O
zz=-RBDVT!;xPmW;kIsW2zBscX7vzIk6)*z}aE1Vgg#<_jE3PjNAbwrNSFiXrjf6Nz
zgcL{vBc7*CWh@ccgByfFG{_jEG`IwXAb$AFK<<qW;11%8uPz@j#O6je<br%$F@*$3
zhJ%m+;-Bv>6oC=<6mzfydvJp=h=e#ug-pnU0uXx(t-uCcAs8Yc7E&M!+_*mHK_QrO
z-L(LFkY^gXX9mDsC<5`%X9{Yt2RHDAV2FTNNP#TK2V*tqgA=$z07OAFB*8%lZb;f-
z)QGZy4d{I7<+6Sk#GjrSn1dxagB$olB*Z}?q(crAfH5Cz>Vgfpf+s{kEF?f0T!KP~
zYD)agC_6ZU8w5fmEQeS~gjC3Zd?*C*(Psu$-~_%929Y2>`;s98vLOe=h@df8fdjZe
zAjCi-6oO?7>aZngKoQutqP*Y^zOBhSq<~8s^aqkbo<A}n4~oFJEoFyR-~{fF2q};b
z;;Zj2m|Bt^ctRkA!xD&vG!Q?2=O7;n!L%K91diYe0T2aokO--e4Mkwop73A};?vI&
zTp<7=ARdw+71ALa3c$1j$AI|vbBADvfF%$IsgMQY->(pitSBp3f-87JAcVsbNQ4wf
zgKW49M%L&sgn{_>%LJKwQKcj83Fcr4_8>m}d_m{WFOl^WNCTZuKf_MM2R7gcF5nK~
z5DjsV2q};Sc~Af{IHC$zfCIQgAcR8{#6t>*kH1_HAAhE{v@2NIkuQjbc(@Dd&g2_n
zAQuY2xC{A#2v`nIU5OtOAO)6mqfQ|MY#eAG2!~84f-2oP4zfW8y%<9Rh(U>5u;|J8
z0s$f&2@7$M4TinQCpbbBq(UwffPG(%fjCHlEHLDIiWN9QPJi0MnfSpIGC{tXsNo<O
z4kRo%LhxX82(rO=C}o5&hyr_8)*%Ya+^A;=hDfj&iOzs8n2sX<5C8?f{N_h}K$t&m
z4OtL5p0ptoY$os<L_z!{(uQ1c2;%&KbjXJ2V9p;Xg6t6LGZcLV7l?uwaG#2V1h@os
zr%?uQgC&p#S#WMTWe%szU=~5WKrlqW5{Q9#NP<*IoK0TlAR!M7=c-f-jWzxM`6ik^
zK@X%{=PR;b-Us=xEjE}Ok<wS1ja=M@cMeGDv&|&jeKqd~*p_}?Z>034Lf9|wD3aN}
zh7>=0(nk`1bJAClcTRGg_;;3fQMK5X{$mxk<(*Skwx!P&fRsLw2~zr<;Yi6}N5aWF
zAMtM|{W0<9Cw&j`dnf&?1^h1WH$vE!zLG6c`h|1ZFXb7<w)D~ZBc-1g&VIQ@mMvv9
zP*wwFHBeRqWi?P%17$T(Rs&@<P*wwFHSphB1BPULl&T!P9C<%bYX5&;!HVy{z@X{l
zgZ}FM&nGY_)KBC5?|-xJzcX6<%gN<6t<Nh5l^OJbo*jAj;9pf$j;Tx<SA>269^<BZ
zh4|t)&j(L@_F~4`&MpWqhF)PoAr{T;?E}3gdHZ^Kw6pc|^7n6N<zwyd*U8(@+Pj^1
zJIjt<HXYmhv0~e<Yb#wyFaP$oHtnsvt!%wIcJl4e!P?r|%G%b(x1*1jZ+maQj$Lv6
zpbOi<$FD;te{1iK?b~^IcW7tX-j-yn{X5$Dc>DTy@b>Pi?kc4aTedc`@|VR^u@PHM
z^_s~@O}WgS2ihn$bR7sgx}Mm!4GS30`w6kD>%=}=>R?bg+?q@cR&4OPuutBR4Jzm5
zqw`lNwt3yy@1X4W3H0-tOlXbGUNtfd29*o(3!NG$t17WI`=hqr9YuLr>Oci}LpE5{
zm8wa-d;Zr{d^0;c&vyL7Ba^wMrVZ3eNnZSCJfByd*dl(-q=Tl6v_VH@yZN8n*3Y%c
zz+&2DU@>hn@Fi_Buw3zNGVp~q3DLGm>T8-jk3qZ%(zbnQ+eqEH;3YPTmFouoeI|PN
z2Y7hlhe|mmbh=uyUjM1968~QpW5uqw=%FV+YHR@e2S_;4H(7CfK@W$kj7;3v=i%{+
z4BFXwcm%e$v(x3X#4}a=gBqEP`$yv~@m$rM2Q#&G9x2Mt!fPvhmTK%&4<=33IOY0N
z>fHV#1(WLpDHOA)mFtAmy%E0-Q0n>FbwLiwBBR*2_m}wtaz5+IAwKtH(JzN5$6G#M
zjuLC<Svg7!s$B0hslNFC`Et1b1Lcr!rm}D<tEz*%Hk`omp3j$~L@j?-juL~Gx*P!|
zltbFhjQj@HRoW;x%(tu3Mq{<Qc2HY3x#m`an&3>F@z0m7#4|(x&PNnV{w-wXFUzxb
zkoxSemw(Y6UA|l;Gc5Y~8co===kryfLj1G&8ugNV<!keGg1pJ<F_=WyoaggZVgnbK
zFDK&q>+-C=T=+5Yg?#D!86?Stf+Yu}NiV|C7HkJ7*9_$e&Lb$)BY=xDzKS)T5ef71
z=L3!J2+<!0!s%ago3c;MK50M2=di|G0dAOe(eo5ES?+7LCR@iV>8p<LL@L{#YPaQm
zzqGf`Horw>B4e=!$-jIa`$H}q6Ex3UN&(oE{DvcoS^m6EMe?J5ex(eOS2N|AhEsrb
zNxP%gFM($jcChT_xz8B+2{MR!cF|8;9Btt_+bd9$hgju^zx?|%5Apo;VjdFNr#TNb
zdFaQzB%E|SG_9jc;KjRAiMk}Y5WlFcs6z|N@(0_WY4WbzAFbHdJa>8Y3J(s!V|AcX
ze%&$d9K)0j)vk$}wvv0Qv_o;n=+|4Ww%%TBv$RQiZT3vn{?@kZs%^WNs$`UfPjAXR
z(Ey~ho$=(q=0UFsU#a))h@&{YmwitBrr(B*wCBQQ^m!1^R&<o~PBXudkf0Eyt_wKM
z82uYRkmp&0GFw>xDYmd0aiLKgl-a`ipSFedciXrst!=GkF4DeFesHRs-aK*Cff~)d
z54)W>y8B+OFVl{Duh_lX`J;E*{B)Ra<Vv_|A6Tnzslz|J*yUDI=8_gy>wR16;@O=G
z-dZ{Bk1LrUW^fZZsf2q_;nT~DP9OTU)sq#AF3nih#Qmp3&1!#p#^as7HP=)e)$)jD
z+(Kz=aNSbkGrG3*X5}h#4t;;+k4@|Ses6kzYm>c8Tv{9sKR&KQPm5G;HZ=!JIUWXm
z(5-0N*2I)a!x|dwcs;ep&Rb^<x}?U2cKvlsjAbFZ{O_{q)n3Wp)%c~^UyXej^z9!-
zPdhj`rDu9oUsv7s@YsrJcJ~H&PFc${Ljx&?{~hOTZoQ+Y*9vfpGuRM6uzbJo{utr5
zCMxvm!Cduw2ETE!>@MNTY=r$!+XySIubk5Q9B8Dp+u!F?r?kEVE*guznELIpS>9+!
zzv*$cFMVI>_EVGbtIyO?1zfeYFq!wm?yczP@h%dsWFI|!mHYJSPtRXywzWd+<~yNh
z&u%`maLT8SbE+IpxY(%kg|<~62Jv9^R4H%CK6+MnkaT}YDNIP&x~J-(dn0YT-+y<8
zXW+EG=iP2PTjqatDZbt&`pf(2Lzl*vPqq?YqJ7&<HLh)|yzP9t?-kXfSyejKKKT3I
z>XjCEToUru{!>jEN5sRK`fv34^A=@R8=R=K)bGRY??qdhf0LTruJx_oKesk^H=bux
z^m}lKlXai_^dA`yrZy<q$I&*W{z~>CWUZuIf7|9?S_J(XyJLo-SCy}fEsk&76=J)7
zMBKL5YgB!!PJRvEeJkO%Pp+e`c_h8t-APX`yz|C~uWd1kdFSh-cjxVIGO@|L<~=u+
z-uF)V0a6b8#TQrJy!7*1CLbNF<oNC7E7eXeJ8smu+h{-6X7%S*{)$esLv0E7f5>-{
za=w-9lc+Ld{nVxKf%A9!F5&^6bW8Rn@OS$-Dy^@Q()u`Rr|92*u8*VA`gHnF_i<EO
z-$m;fC#yCn*(cGz%hyn8ed-)k&dW#Pv(HX?&}6X7r-q&U!<WqMel+Xi4&$OG6?=7^
zb)!e6NZ!vW;Y#+^R9c@prS;WRTAxX!^{G=@-%6L2@)j-FHv5MUw*9hT=Ii_4XwYP;
z@yz^Nt$z5qM$*2*hg-JT&XUf&=t0T8l}c-CIa)c-OZK%^T3hZ1l=w>a4Rlip=N&n8
zaNlEZO&GrGUZu}FHZae&+WJxE;kWCXWVM*sB{Fvi<AeDKsx~M&Ty5pKY3!=Vy0>fX
zn)>0|%;8UsW>j2|U34+y+qTyZgn4ED(Q*Ak-c2g;6~y>|Xg2k1zsc_9e=B$Ht(oD!
zy6@}r+jm!QOlh%acuK34D%JN6lJ2)1A9Wdd_;$lpRZJ_UjgB9hWPjEA+S2Hs?JIpd
z-R=IPEXD};kZ}F0c0O!#<Kq=y|KRY&u1fcxB%FBBH&A=!zL4iT=E{*TJB?e_WyHAf
z#``|YA7{DfQG-;wu!p<ywjH)w&74JEnyU>;_6bv3pHown@<z<FN$FaCv3bs8)6PG~
zIs7<!xXXt*g`va!TTH*W!)zRRJD`Ls*~d(2eN**Ro+qOsqf9USI&YdseUHVn&L&MS
zpKZ2a#iq?+uhl>LQTT?1hj{MnE#)oQ=ai?dgu5No!R*9$8<RIzess(8ZpEsTH|*+F
zt=H#2&Dg&+`f5GvDfq%xu9N@$K8emM&!<a|eZPJGlhJl#-G2KpIK<)n-U}-dDuy3i
zHRAa4_-~93^WA!m(yyr8d#B&>8#$TZ{yuc2e^Sl4tv~m%tr&hHW?Pb(tzUp^3ZL+l
z=kdSKH&Cg4vncIRvJas$-$4JJzJbh@>txA3e@g2k%2kQ4WZyu4x6hx_`Z)UE;v4Ay
zn$MpwKA@;e;S1@1i_f3Z`si`xo0Zz&zu!ksX?;4C)|b!U?K7#a@;vnS`TY4$_vKSs
zUr43(`BPdSN2T=*^ebH{7toHaRBVJhRG`1XK1Yxxo#AFYj;oF$)yS`qEs@8OJdUbP
zA$i@XI*sJ<S@8`Z@mhd(?4UA^MB?SszN#+B!Wa%QX`mc0;VnTsu1z(DbvH6$fHVhL
zF7xx7$Q+~_G8ZYwsX?U~|G{@<&2i<Brm~;qC%tgmu}{T@`$aFDr#3#xlj^nSZ7%bu
z{%5-J+Hf*XM)LczbkklDPM5BfDMuTQx>3?KLO9Dh3)6{}`r;8*sc%lDNU0|tEh9aU
zbipF$A!!T6hC1yRd5mpcegjz7jz^I?RN|LmEAFz+VoZ2R?+s)vB(GH?r9L5Y8L|=b
zGbHU1c>qcKM$+br?f-9)t=X1wFKv+0E;gVYKcb8)k$N;_S1Z}i(vNVGUVo&t73GZN
z6Pk)Hv2wf<>)J6O%GeM&9u?BWg|sFdd1f35zCMr~8|g&@kZxosie`tDu_S$vy8LLz
zMiiSLZ^B7_e2|hKU!>&6PkX#4>)LS*%6JFKkLa%}$TEa*RgpuHq7TE6jgiBVlvT!V
zM)C=S@!^{G8jbX4dn_^lNgGC*Q$RNYMnF8IK@J!(N7@pcAq?W+Amo8D5!!&eL<}i#
z4pbyy1#S=wFSGHQL!If{z>TLMMUY6{<%78aW9{G{wOw6+a+*>&D{zHCh=Mpsg>1+N
zLkeCOEWrufAq<v70vv>F$Ol7D&Udf}R|tkBkV*dHkSUM_`C#OQu7Lx%LI5m*B*=sU
zFs0G0AntqSPD2LdgV{N*FEozDZH|Q$!q~8{%w{!pNMAb{?7LE@5Ci}1Hmjq4N7vvW
zWJ4ij^yb`yB5>g%5(d$b4h3M!1?o~?eg`!txC3~~MGfL14RYXLwNq`$1<?fpVL2p0
z2IPR@Ky(zGAOIpE7Lp+Ya-az64noht83G|1QXm`h!N`SpzzKX|2_!)V<U$dMy=<L5
z=seChu?d|OL78WB9>S8>sh2sNBh9I!xtuRt>;oX}Flk4UFV>Txi1oyI*e_t+kZY(D
z*l@EEdrQej$P+Sxn@}z??+40on{XAlb`Yj$0l%?s6Gi&STqpo1w#5dM6}W=)JLu#c
zj$z$=A@L$zkYbm~6Pbw=n@lOh_oB^ccWweYyU_`(r$H_lE+Q?Y8fghRlq>v4^q-qR
zB8Xik88B`P;b2br5|Am7NBF{))C=p`V78bzAQ!vMai-XCu31iX5Y%s$Q$;}@w5nB3
z6$~kG2@1f}3|rDrwv^RCSq+rcKv@lx)j(Mdl+{344V2YDSq=RAYoI(?c=}YE4`b#l
zvO{cfKZYluTb{~#J>C~Wc`$&_34aAX;I~uAEI19{f^ON&Z(?^}Y*y=*1lG5}Rv2$W
zUj(@w#5VX$hybx&JrBel{bE=OvLqpQz)nbp-5|>~(!37uuq{3c*1+3ri@o2qtgi!E
z^4Y!xcR-fHx9BHPme-&H$V<hFNSU)^ggnA_CFJXHn0?NWNS?QY*b3hO8$p(VNEy#J
z97e)0!iZhF5ujUSzau<`#_%iL2U#qT&7l>vh4vuJQ)GGKFoX))xO%g%7wdhs+x^(C
z1g79hK8AxESVDVf0WCq64oGY01h(3JBau@eRJ%PI=?-F}d@Oi@*i7F}{1@P7&@D-<
z+w)sjkVWiokB5oc?aI_$6{rerp&fJpYp?-3=nP$;8%X_jmvv-Mq$BhOC+G*xFc1cT
zEY*<JLFP-<hC1*T)P;Ib9~yuf8p21!+XyLhuo@%Hp$RmFX3!j3LTix41X%;b9{PM(
z2unch!i$}D@skk)??EiA2eE4yhkPI6K^Fbv-XK0xs0nXEEs*(!vWV_Y?x>lUwy%Mv
z9_-kj2r{2j=8wueUYWxl3{xNkWM1`nq|7xA1+ldd22)`gOb3}is9R*dWGe9=1gVPy
z$R%}n*8+yTyQl<v*eB`q2ARjdm2DejKajb&GWS>Jc#EwEOcAICfeSRS#`Yp|2n+@J
zUO5bg!w8VM_PV7j>mxzt(8`=$nQJZfAjZI0@Bo<y?gif917c&<5Bx#q*UNI7m*BsF
z=#0!|{fxZ6N4aD!smveU&Gs%B#qZYW>~w9ri0ul=ztoqc+XKXY$A^TyL3}qsX1g0x
zA765eG4*Bw)!D8JuR{f>230_88t;WqK|V^9hdada6beA}Zy%Inzu56FPh1A9&*dFb
z6zCSQv1tUd1hRj!-fv;7PuFf&CQMarIDLEf|G#YApC%t-H(QqT$cx(bpOIIz>*c67
z18sdvxGJny*V`6fE!C-u8lYPqaO@x2<7HnB!oQ(C#uQmo@A#S=_om*lCe+6p+B*5W
zZQb9Zz3zZ4t;j<Fd7K3Ep+XJrA5aNi2U!-ge?7=D1vwRFXtx`4yt%d<O^|MsVI+)#
zrffF@3+?Z1kZoZnb=8aGowRWbM7n6##isc%?fOWhyLR0h>8D*6o2rJ|x{*A|JxT5-
zavhia$$d@M#YcqP|Ky$`*Z<Pm&37WsSSSSih^w3df8XM}TNMlu5DPh==6NF+B47#R
zfer6!eIX3Q&b=}3CEZ{-#DVxj&xRbxheELD-K#UWLm))Ja*%hlVpn20#6cpYKsq?`
z{xb^XeP}%7K_M8)`%W+iOUMM%%4~xrxI+S@KpJF19u$EgbDY)C3Y@?df?+wNfl*cB
z0&}ng`2d#z=O7m>s-aI122o&Ho#R1g13#7ZJW$gn&JYZ7AnkP!GT{<9p?i@a_VD8&
z8Ek41H-tkJ90V~~WDH_oz7^PjI|RT%$OMbp=och`*qP6SOOV5T!iwi7M@RyBmhwbT
zf<d0)mW$3nDx`zlpXFXIzI&n}1I|G%1am$egiJUG2@R2u2L)i<h%gWVOCSc4L2SS0
zKt2?LX=CaJ?7<0KAsCiJ5tx~iXD9&ICg>Ri!*VDD!=|JKb-@N)AppWa9EHb0BBVnW
zT!KO{ZAKg*cHh$>+Jf|;N^{Z#vEeRu+v6b#QXw63pa_gxQ2$^9uHXp~pl(UJ5DjsV
z2x9L&3vxj|PS=Hiw$ultK_*;+d@!;kZ;%KnkOr3^4+=olj^n`w96{`~2g7oRg#<{3
zOmJ>be!;8*IsrD|48b5a*JB|C(%};1gUX6J0I|8=3f!O&46P|Mv;rG&1Q!T|B@hG2
zAhy=eK`z{dD%_VNpl&DPf&ehGp^TsgdvF3*@Pr761+j~s1(zTX3c%Qwx&^fz=NUMH
z8;G6sFo=Z&NP%=X2l?R8nXnKGiI4(mkO}7?AB^mY7p%Yu+#mv$KrAG}Imid2E`$Xu
z5Zmhk5DBr60fkVdE9rtOctS9UP4;xihC;~fK|S;&9JoLgN8*BTNQS#mw-<E|?hpeB
zkkp$z^r2lr&BfaVJRuo!;4ZlKB`l;sRzK>lKXnbxVB}02f-i)D(*V+hB~S?Rz0U@g
z!$HUd`K}iO31H(wJ|P?qLO#g%yZpiAX9#Tr0T2rra1P9d5(k9C5{Q9I!^z7C@&(Qi
z3<;18xez&$^A0jV1~mjiGNgg~Xu?7^<btsW<pKGwpX`awfT<VPZMX#T9o`&L{iq`_
z_9w590R><<j=F+EFbW`lA^ZmCz&Vuj8R8)ytimV*#6SjQLm{-9N?E{s8s!AB?H&W_
z>C^{=LjvSMAsB^|FHl1(u!p)c2n*p51u+m0muAu~v#5J;okQFpw%>yz(M?E&d{ED$
z{-JO_asj#paZ!{J)C<`M_TU7rAm1tjAsnJ08sZ=kQXma7;T&WvBAvxZFj_)6p}mRb
z+5Hz|P5<W!Qu-+s*)RQ%BJF;$>n{DEPDtrz7$BwJ<ARhvNe`qv!*@hV-{Fxqo*`^Y
zAERt3tAVl_D64_88YruQvKlC>fwCGXtAVl_D64_88YruQ|4TJsNMXnR<M#i3{X!>(
z1t~rNe1awy=K~;kYS?t20L2Nw|7ITm7j$-!%WJfT*IkMa04JpQi*&eNMO9ABii_Fv
z&=-9GOr0D$e%xd~Uv+3eP{>Q%0a$jhv9htX_VR1z<<-&0$J^hpLq}V$4who&zrCM-
zr)TZ}Z2c^~J9>F{YVT$3-N6fU|6abfww-(}ZM?19+4@^s>bnEz<k!Bve<w?8ODo?_
z9emoix3sqLv$pBb-rLvD+P0mQzqkW<xvgJM#cr+Gp`W2C-*dhI<Q?vdz5pgG`=0j&
z5UlL`t1o~MW&dC8&Nrk^U-SiVLtFpuqR1?DpaQ%h8!S0E7pDGS<_q9Ix&dBr3!t=z
zS}E0w|DO2;_)SyZKm7t+|8x79UjS*J7ySZA`@HBEK-#A`zW~xc#rXx0_Ic4SfWNkV
zit`IFop|DP=ZDtpJ{|%7;trr>z1HZe+l$qrY-@Z0h>c=Tw&nZrpmK`mf$_d<>-+&s
zB`^AZDF$L|c@g{m^ar4qu@?<4mv}Cbj>Na7l<}2##uJ~|Ro2<fj}nDv;Wg=>_WxIs
zmimTr?a|r)FEQF@_U20rs_3GU=wJRlvp;UcZ%dVW)!6@+y5=>kswd+ju>Y@Z1dV-p
zU0GZzY9iDx%Ut4cdA=+qR{68Clo+(sWtsI4mc>jefTbS14yc|gmN+7xFH4E){j4k{
z1}$}2-qS0K*r}Fw3FLbt?c&pwb<r=KZT)0zIpo?}32MUI9H0DrIZ9NT;%wMk5Z7Oq
zXF6obkMccGcR$h3my=|MML%CN37hqNzDiVpe>Pt;UXrgIZN5Z@WwkbJAne`e^HpMF
z{<Ha7|3bcWHuGh^n=CZ5lCLJnS{=Af+|)dyXdc-#_UdgU;9nQ*ec!~yf#2RnX|Q3=
zJZ>YC1k&`-MDXI}vBYvpGWvGnjVsF@Wq!DlPd<Mt`Sg4)pU(`%zx+8xRcwCiXl<}J
zB3|+z;1v=&B4m76nD`)&eCTY&$7%B+=WjJIgDsRZt+;&X8H<<v6tCCM@*{e!t3SCe
zN`1??zd_|ZJp6+~CSh`4$x8wI)7UTLqSOYDDxY*dwo`rTQkP5R5B>1{b@v~~{^;)B
z@6J|raElgGhw)9Xw00RvYj2?s-*?OG&tEF~XYJ3I)_z<g+E{H+*eI;&=GX3DZa+4^
zQK)15>JFB}H+?bFGxXD~x75j>4cp0gSiW7V4e}hn3JL5HI_ZI9uRT74FO~awL+0(-
zBW|eQnf`m7gd@9FG5%R;w=z5R|I>ErOKVrYwD#<yhf4bfKK|zXPx+qZoCnTXysG`w
zQ}#(0R4WeJ&a7oQep=HBTlVrzTxs8P58hWDJ>Pb-b->B5eV1&#SMk&NHCyc+W0~aN
zv|R0a7FQXg+*{(?`jg7Lr#dmGhE4QQ)v^<f<{fTkzxCAUU1!!lT>SX+8S#wS<XWyS
zg+1)j+PPllBJurwcJ$YAGgTXy6>h!V&hW`MeQtdke00a8R;ME_N7d>$-XL<rvIFXe
z_1iI~f$=AQryc$Obo=;acJDV%-8g#C&KK?8m)8D#Y3;>dVBCn>p!07hTo?50v-D8s
zYt6>w<T>yC$*Wg_<**ogw{}18**;+r<7I0~xZeAQTR*rL_IQ$QyNMy2dRP0beDa|x
zANN<)ew<OsrQKo1-0V}%^HDeIj!usG#VCE?i37VTJRQ_-xz*!kF4s(IPnk7j=!nkC
zxSunQOKot=B5|8v!PrN&teXFj`r(4kIR}>4PMo=C*!->Sy3X6RI!mQ0t-bh0-6g)i
z&)$A%?aG(dj{e_mFTS*P;7e<lzqIz^OKX>3#s;eYMtl3EwU2*9(W}b_ZN6XAGRnke
zgvEeG*E)`_x%}wdHKW{Li@Y-Dy<?Y0Z)R+n67K(yoq9)Uk4FEGy|;m@A^rdVCnpq1
zk(Goaxl4#{R6-GoD1_+H?Mcy{Iw^!Bp(SL65JD6}2qCrzA%xtAmJpJg4cWr~^`3Jg
z)^4+(pZ|CFv!9vA<9XgQbFP`W<~`S3GjrX%t`=*9j-+S|^<CZZTyp&-dp5tlnwhoW
z=*zLo#+_>2QKba!^4aHQ&3g9#YdZB@_1(GZ**|2j$3Iukp6mENT*o!IZ%*m2eaz4p
zWm8Ffqr{7ktae@TY_?$Z#(}z7w=er%Hqg<%+m2y2_M~tX<~yHvA3TmZUvJ_sO=}e#
z&$=W2t)AMMZE1#+R$kswwhY>4{V7~Z`SFqd67$El&qkH*>g%*8;zDxw%Lh#iChQ)w
zY4q-kt5K#ijKbACUeHn$4haQHw?ED;k-qHI#Jk7g^Y$xZr5_UR>nYv56P`8k{8^=+
zE<$sU&DXk*-m&1dg_H8pA>*1pYxsVlZT}X1+Go9&%zA&nFe$kS+LChBiw|JWqh=j_
zu6pr*m)?F1$`6EsxcfbX?@E^3xvsQ5_N98d;kf!6-|Gz6ykoohcKyPUf*a_o#)cEF
zoBICnUggOW)iHZ+cJ`fjFI;tPUZ>LdjMl*cM|9imK%X+!FLlmtH+N`U=lzYQ6Pe`R
z&Ih|BUYlp}-pga8#JK&1RnJbM5P{9FYSy3Us`JlP_r4GN{js6`&jTjx-FDNo-X!VW
zxqa3jDX=)X^vr0}H9aScdD-j%-kDml;r8!r<T?7T%}2xNDf8W4c7GI9ZoJ}AGlkTA
zJ>P>GYewSTo~w>ISABBQ%MuD|*1hMdXRkky_V>@#v*)TS-;ce|BWu)w|DV%$M<E~=
zo&WEx1J70G|9k7jtM#Gttyu^D4x8>DnIulGoLT<i*!hB=+T@mwO?x}`L*oHHdv^`0
z82=!`58ocVUi^QjUOZQwbzMtJFE#7RJF?+w){EynUIF_)G+XIIALUi93ic)!_uT9|
zc230O>t=V1LZ8-oIlIH^I&*WNE5ROj)%)4+23R?~_VGA=c-OY&?|RM&*U|3V<Kg{P
z$>W(P>&?*jwlAGW|GJwCv&&jEOK#Al-<&>LYh&6^KR(5}dHb-)!-_rc4c-jR0=8V>
z;DnTEgXRpI;C!;xhI!7-79TYq?P;uUCJtSdTk81ohsV&Sz&`O^vA<4gqO$w)_MOf=
ztTeW;Z?azH?&<n2TB|2_>iW@PAMUjq>~p`6IrgZu<FaPYTY2|C>305|{cMe!#a9xJ
z>g%odb$i?o-}@=-c|>Pvl&o@ox?r4r!=YXsyU*J+*DJ7m{oJVduCrH_3(m)*4T=pN
zH^j5_&A5+B&l|fKjL>+rI^k^8f~i}X8IB=s`ktOKJ^}aT|C+8mSKaY{i?00l)<x&4
zQ_pq$A+14_PLtLLZqlE>{?zD5-@dj?<m};lM~rM?^Sth;rlzf<V|L-a_yl{Odz@^O
z-2P>)pNA=|-tgvt^^W{G=e(ZjhShr9b6m#6X?Gi;jRCvAxcz!3D*7&6q1~+Hb=IDT
zR%t!nDGD85ZuUR&zQNPUB^%I(j13oYBsc8H_9ngctdjIhU4_jJx9u<T6Hbmj^I}=M
zvgsX{Fbr4yd9M2D-&<FntIqo0r9c0QK^qPrZx2VB*^CrzJ*c?{KJnQp8>^^}^#m-M
zh_JftR9Afl%g8>z&}~Py_JwY{yqy=@7J&9k&GEDWO=qz^)x)2MrFa+sdAlQ4w_U1&
z{)1Sj3urngkm<Ichjqg8C0N={NXY8&*|s*codVXOYL=ZYR0}6>uky`s7psMnw*_I_
zh%mLk++SmPe1+J%ysd@o{Ql&)^0p7(3|DnrI)8av1U7zj-0J6#M;hxd+(y!72wN2o
z+D_h9fNewY^>z*A+o{2}MOgTS^_v6c<#qR@`OfONSHJE}<=f%flVkz4mtc>JdUt6z
zETig2Y6>farM3XAVXLmAye|He|Eiw{uBVjh?c2dpx@u3h4*I^@;&}&zxc4oAE0BT&
zkO>OG|EmTvX%82I>N@5B6kX&$(o6rp)^QIPp>Hrq2l?OyP#cH7%fJyxKnzF)d4M$8
zNu#|=mt6zPM&O^W&rZ7RRT}M8y6jHSMCP^G(YC7>t}pmEX|r?DVJCfsG;kg0BQLT6
zo**2=f+|gSF8bxwwabm9Xk(}dpMpxv|B-I__tGqvkhb@8^z}!Et~(dUh5eRp`G2Ze
z{#W$Mzt$>`MBHqeDKOev3XCtv14hjim^e@Xgxb(C2jL(d@DuL=-UGY`cn|O%;61>5
zfcF6J0p0_=2Y3(g9{9I<fXd0M>;GTCXK-H>xKh8cp(uo>K1u<olUxO;Um3L{qP}d@
ze~|jj#)GwB9iaY$D`BaR<9a~-hZDdCun}wm)K9Exa=`v4YX3XN8i<Bp{>nH5{1^k!
zVZ^oP#~6^^4S&ZN14G)#`ZEs0eK-hI*H<^iGTq-(0QJ-FkLAg*VSxI*Qa@Yj4^3JC
z;a~=s38-(kHK0D*QZO4tfH@!%%mvi1o+dxo`GETOQh#FVD^5BD3qdqk1gIbT5<u-H
zmx7<bGC=yk)SsRvTO7{@Ov17;?n7t!deS+d{ZT$d@eBr}$wBcO42A$ZP+dQr_V=|u
zdUYLsF8b<Rwfd{;{r|V>_J6I}Pdffz>-PVhTK&~^@@-L(IS9}+7}iccPkQ>*HSleb
zFOi=5f2x0v>RGn#*#Oo8<bZro2#SFs)e8bDa_#`Efh+I@VIUTyf((!Y^1%xr!o!;M
z@o9WxBj5ny0F7;GgYy0=ef(t1r-4k63yOgO>UaY|CddWXfhp=jqd*$S1}Z4KcLk)8
zUjRx#CD2vE_P_$zfM^g8Qa}dC1qGl4#MQ$*C;{a_u|Dd7K`fk-4~oDGVA=rt0#3ji
zNPrqDYn?!q{(S=Gi$OV1MCGy?&<B=41iV2chyf`e2UG$YU&jHs0$)J7_%wEo1`q;I
zkO*jumQ3J_O6L@C9TbBypo_FYV<$v`6mT6BgL0sRifv6m<GW^nTu=Z?fCOR$i69MR
zf^uNd9BB<W0dF7yaUc<pX1)^A8;z|)dilkm9MIT9G#-pL-o;28UkZwW5%Q~ekOFAz
zmK;z7$^aw8aex%Wfn1>28s`m!AO(~IB^|5-g}Sh9ajw7s*nt#~4zfWWC;>|C5D(A+
z7y$<$0%0H$#DEl#15Deao)!cGgAVu)B!Co<14swo64(JJAOSHT5u}0)a2*r@YGj}S
zG=ULt06CxtFr9FIz*HaU2sna3kOvAtF(?Bx$h$T$1$Mw2NI(pT2kAi61;+)s;5sM*
zFMvu{_zhS9Cy>}3{s5Ig$q?}Zq=Qcy_^zPR2=O#V`U4I?1n3z=&qsO>rg3v<EFBsj
zhsN;<1CbyGq<|cd4+=pg(CmS00}Ox#Aieus;EBc%5}<-cF`7UZSOPoX1UvyXn287J
zARiQh5>O5_%#p5vuqXBnNXy;{q=O8gZGrm?m;!6y07M`VM1w?-0rCN>UvG){0dEin
z@~yCaU+fcj1Koaz4~PNY{oxCc3W|W{0QeBR7zk^FV}d|H+VcgV1Zdmh`U0vS^&JF1
zf$Jb;D6TP3w1+Po5C>of;z2Gb0G7jWT#x`VhQqI*!w4J)lmT5woF8xnMk8?yAOS@{
zV-)@eVIUc#1Jlts7Z3w<oe(eJ36jBeP)v3V;xiWU296*S&=~jGK+zfd0G>bsGR9*Y
zK;y~l15-fb$;W_9kO!1p5f-F_9N_7Oa|fhDUjj76@CyhB>0a<9(4K((fg+&ojd_qc
z3C9AOzVHFa1C>C<5AgtuKk`@*ABO)xA<&+NYX-tVhZ#6Fkbpv<Jrnx{rob9F01@y8
z5+DW9fOO>(K`O`qIUpZUy>*%t7AVd}dIa?DMc<yJ^G;eDG)@|QPu500P4A&v^8Zb-
zOz(2~u=K8J4olyqonh&n(F~T}DSN`wyDC3@+XHwtz)%PZ@Di@AxhNo56yQEl<mTsT
zV&oMh7Ww)3PZ9_Di+x4VuL~B1;8zqJ<RNkkWVQc%146&0{pS(j=jS8&*K7Y>l53l#
z){^<w4n`9oD`PZ}=3*}Xnf9NL{~rkc_3-R&X3)*h)5O43Z06P7*v-Ju$Wv@;=waq=
zCN?uQ{4DrqC^qV5WYWExk!kntVgs?8sfmYC4=*n>gC1^TukKzD@oT4FrT*n^YGNif
zb~6%pGcYmp@^ClyF!XfmVdh}~jX<+*hK3~ghv|>CbX?_HI<?hL%g*Zy%|9ALtxBVb
z^rVn&Gpg``y~3B8e`@Ty-)sIgV%Ps(^G|~Pe69I+NA7oPO1zk~KpoJS7BIQWH1GaM
z^Y5SM_^*Wi=o$#wGx_@Gv(8`eCtW`iXcN^|_xZH^S?7<g$=5o6bWOh2`J-#{EuBBQ
zCg0NeqigcD&R@`<==?RseqL1F3v!)5<Qp!m0GyZi?*;#APS>B(s?*mlVwYu_f0Pbg
zu}tGg+ADbB3HVv>uL<H*UGHxcG_2ZV-6y@jZ$<EHWvd$RDU5fB{hIvM{nnTR$h4uV
zH1njC_%Y#ff6|#V#W4dfeWCwXqgOxc%+(l_%_rD{{_f|qcAFCZ>%sb2rvF!^Gndzr
zd~f09jjKp{TUF;l<FwI)zdz|1cE$DyU!F&e-uZkUH3sE;9-aQed8pBeW2$~0LTsP+
z<$2VYdOn{=jX^n|M{^G6QKkErBR`LGI2UD*1A1b6=JH=nR{??IAU8=sP=}7#nvJUs
z&HQfqoOT@WpLw;os^X1qr0lrtc%HQEAz!AkJ*(>ix>95@(Q|=jn*cqEHwqvW@R{K2
z=I8F|=2Bzg_)qosI#!E!^?1?Pf;3f+mlnbbzl>Ln7yCbrSF^9;Riz84QePIYD{u~7
z@;q1?bIDQ`FBjSCob0-J%YuIW%f1`X{T+yZs^_<)4M^X^@|}F0gVvnUV1GYgbf-%A
zF25eeqs6kfEMBa3s}YuE?+7ma!vcd`ra(B4d|tJU63*=`!Zg3aUVC;Me71gb8``c6
z|4|u?556mT-Mjx>_wIY^+3ED4>%r^U{r|0J$5p3}tNt8UeZ23j7spkX<$LSJan(`z
zr|ZgDApeKnnd8ZZ6Mxx%G~HLnd*{5Zn|qGC*e~fuj_t+x5AzdUCj=m~w4!hZj;edd
zZJT;(^VzuCu?BZ-ROjupJrGxGV24G?8>L#e@nV`}O5qCMt#j$utglDg+dmKT8``Gh
z;%94=>O8l7=DU2y+LA{NA{gdnFA8V!Uhz<mZ5J%<(z|>-xM`lzzFMmS>aJF3z4OVi
zrLW6$D^PCq1BGic<$ap!p0;;i8~u2z>y<86rw;4BeAv2Zt4M#=pr9XO<57o+k8+{l
zrJY}V)I&+7otv6P_Y;AR2O8~3Nm^Q}=UzPC%Ec@R=emv!*QeFY(%&ux{xsh<XSJR%
zHuw0iQ5|<*&szEBykyRkOO#e<j8388apb)^v)}i6Wbw<O)Nkw0eQ&)ut~zjBb?<c8
z>-PP0;JE7Oan+gRsu#yqkCLmt8&@4YuKI3V_3^&94&3+F(c`Ks$5n5StBziKYr5ZR
z)?=$Rgu+?OzqR;j!M*0{TQZcbuiSm0dT!wvrJjA9#g6S;&Z>W^3EpX&QMmshJv)?_
z3k5an)N$1(`(M+u<Em5FjZJ_5T%9_ux_p0^{@nN0m0Q(^(tXW(aetQ%99P{ou6k@-
zb@aIEv2oSWi=pxh4tjQ6b*T5S`>R>^j;sD0SKT|Vdg(FjeO|8SdTC~hHLhN{FKplG
z*MC>*#;of@+>cg<3v||cJUDV3b<4Ko7Zs%eeKN+jNuJkbw9mS(2DdfN^-4=r78F%(
zHPag%+j%F$9A@`dv;N#uHk`Y3#4y{F%_ol9{Zjd;Nh{raqogglSwFT^&(oXKOIn1w
zZLT_X&Dipd@k^!JrA>E-Y+9K+>Z8)sx^wa?Z{=L+`slF4E%!H*)pIcxH!8D)g0fhz
zO`0K>2l<O?{i<-i`LwWCqJsl}z54LUWWBwk()1TI%r#32cg3Wl*O;u*)=O11>Sj78
zj7YI~X#8kF%smU`E1^!WEAmi3jP?LR!QcixvrM0CUv&Dm<<Gm7Uw=qEd+E%spRStQ
zy{WgjphDFgMU1FO<D#?1RX32U?j2X1HLf~@Ty^xg>J_@8{f1Cb8eph-_UhWyjrA*@
zxxT2|z<<r|{;K_t{xbDYQq02^#*@(wlFk1XzSj!NHQ0aIBI^Ddt$Qh+-scNlgNK(c
zQl7NAhw~6ilyk+g*H@gI=kvkHxLHz3ow(dxV*><HFL!CyU%n<{a!jW<i_}#pvt++}
zj%==b(Y}jitzJfU2m779vEY?oapJ6=4P8=vh6vkE)_RFLI9xlSU~>c2*B2i9c?_~D
zUA<BguQ6F%F800qY~1Uf$Lto|YJ_(ZS9X6(B=;PDbdB8<HPk2Mz3yIH(*eUQ#bq<v
zdEFgx?n(djCrAhEcglj3*R~z{;A}qL>DNtxL6$f6-&~YfH!Nf6=rhp?7nHJ44>*(E
zU;P2Q#L-U*bFaJ^vDho6$*j&tJ<RHcosHd^qG=}fc1&ZK@2!u=S)Yu(9yROe@%niG
zo%(pXZ2niX?j2X1L`QaiHS6Q4^`!gl`{~{dMa7Iz@Z`~B^?PG#m1@0-Odiv%?PeQQ
zUvq=fiuIjsl{>2Mjtc$v=;Kwg?;B1(jcIUnt6xmhNmnx_#M&)?H*@iXEluyQyHOFA
z``);y0mJNMzoQ<M*Lu|<v1r%LJxZ}d9$O4He~>r)X{)5pOI&Z(ZFAz;b?5=I&#k&A
z)QxWzA90UyWYXSV?C1UT^1kMIBM%u5&JJ~~+?I#-VQW}FFSt;6YLoepvG>~cnLOcL
zC)J=uPv(_(|MC3eD|51)n>zcWy%ZbnP2NwD(g>Zk6ND85oXnRyk69=w(-~x+XgKP<
zWNy1Fofzf;8_xPj^L?6+3=Y*V>|Zu$pz*wQN^h?WN*8sE2n<zfRQXYgdJi^S&3b_U
z7Tr6pI(3dFl<sSOU;C%))N$1{<f>=)y>$b>x9;8FrDw-=JT9(!fLzDz;;Qq<b$qW^
z4BBl1d0RDx+OS!oJqb0%K+zjJWuqx4vNcwhPY8Po%gA!Rsmq7g$uD&I<ZZFoI&a!9
zHI>6_Cp)2DmerX%4@>bd0P=Q1tS+AuA|b#!T{bks+(kGP`!j{GPOwGt?Sz<@w{`iX
z1BWW?Pr7_<s)ducC1KlU(Eh83`=weqd0UNdhPy8h=Za&<+d?qsXuh_ry@4amV?tcn
z^J@y*56dWel)Av8{$J_=3qMH1U|Ye?fo%<Y999Q52eu6?`9%oiZ5LQS{#m@`Z3(^^
z?!J6~cm!0{?K4#8Pw}QEL>7Q1JnE!MuxM5x?Eu>d_7*JK*Gab^d=pq|BY^87rG6y;
z*Sc|qICgbiy+6{k`>XnLq%BvaDMwm!RXTJ3bbYxhZ8_4JtJ0U_wdK&q0pEoGHf_1c
zH)u-_GC-9^92dR0{|n8_e~P{(X>V5P=0#6Od!}%dH_X5@0+h`}pNx*Oz6Yj?43n9K
zI$bH!3Fa$dzt+o(NB)+248Dd9M+R5~TYMY+6_8<8BGV3sHH}0+2iPJ|25hiwgl9`l
zns{m0UK<&$KCl4!bJ4cx4*JSrJ`)rH#d+8#tPs`!6e7NVMH8<a59+UV@f2GqFc~1S
zC3NtBWh(_H5hw{2(0@#Ui2?b5pLh@O9^gH|dw}-<?*ZNeya#v>@E+hjz<YrA0Plf+
zhX<%UzPkQjEqwMTqu`hNf9axNn)-4zL>;Lap#FGNI81#2sb44cp|t?LKyN_(I$Oa~
z-_t&T`W0IOE6^A81JoC+YHEr7(>{Ix)JM2EmepZ30rgd*zH!uFk@_KPgBGAApuUu?
zfevT`bU|Ct4p1N7s;L3yI{@mBNB#e(4=441)(4$I7eM_>4L~>09T)=Aa4`ndZ<i(^
z;?)X_Z6VVa3zb)3Q2%P$ADt(~u`!^2|5^yE16qR>@ZT{&eH7bZxw_^T?Yp|R7%g+v
z4*PG_3nP87uQkKI)(fkyLq|UOJN3h!Ax%FAH0k5Id!r1{4@7`Es2HgWltDc}(|oL7
z4QQGS8v>@vm)l@_U3uDR3+to--7zp0w8L_H&_Vux7uc?Vw8^S#m{r%R<Dy0PwU!;l
ziFD19am?y$#qu_=9i)IAfF>0{QKGsz3y=fyK_Msx|EZRlD>9xEP^D#NBS5(<@B|W&
z04z}^YX_Ww1V{mCoYD9uq;Hl7N`Ml|WHo>g=mQ&&4xCUH8w(PFHOgZhfCz*EDw~Y~
z@gN=KgBL&rWv!Z^O7qMP^Q3VmLjO}=Koxqipcs?@OY})~03zTGBtQycK`O`rg`m0?
znr?mg5|Eym6Ce$<SU{R(q&s&V6a&&Ka|O{L9^?W=q%#emjq4Z&NS`bQ*D4d_0U@rf
z18@b|Km(PKy1<euAwder0AZ-mO$Pa(2&AKOvKW*DZ&Xmmfn-n#^qV8TAOk2OG0^>(
z46Xy}E31!uPy~F*;$DdX3E(<VLY_xjlBCZV1u{S}C<lr{T;Dc`3rGPOpb%*2;(7r`
z@S-j5iFVj8@CAuLtv&t&o`C6qeS<I%1=3L7t)!1@2pl`ZcYrj$a)7i8=0Oe+b%)<U
z8psB|hB#-C44jPMZ;%2^``|wi4qgBwOT-Ptfa^ft3SodR2m|pT4-|r&zPL{P5C)in
zY@lL|b-)HhgLsev(m^)J1BD>7Kf(?`SU~z%rob9V2O=GS0zhMw=?})W0UAT#OCSQ&
zMmZbggLr#bPy|Q|D-L9Xd{78VKsitx4!;6zpfUp29jG{BpTHZCrXD?ahr`nIzdtNJ
zJBPv2vz5{=J^Mz%(sR2dEIrdnuZi9VC?BGC3Vz}}z<YrA0Pg|b1H1?Reh(-j3giD{
z{l8#IkdOZaQJ9~EWCKYskW~&8g?a@0djw8(3I5k>0QQyZo-yP|Oxx?A%mQ{3?Cs8Y
z7mHG66c~mibOQWcBvpQ~2=(xG3v!Y4rfo>?Er(`)KUwa^IxXnx<iY0Q{n}o^QyeVu
z@pqH>1o&fJOZ;~omcFZ@wdXTU?Be6^BK8&giTx$PGQG1x{2zo!;s1b;AP+GX(WXyb
zy%<)uoku{3zl7DsF~zzz0NQ9%+<bi9+#xJV$FRh@$vCGkj_=|l!D@CpZ&=xOL1I5Q
zAAckZcD)VO)7S`A$EHn4o5vDPNyPWxe*Aw~<|8&dUNyg|%~Q2aA+~WxnA1P9er4kp
zhGp5Y{oKM_+(W#)#6i#-qElk3w1DV%+5%|ABkYs~pSO+TxGiaIZ%5c)<lFuLpNOzb
z4zO4Fz4j0tFIs-QmWw_gFOK8!GO_I*g#A&zEgjFZhT~OY8%i(I#h;ItT*L9mKiwHM
zq#k^8$kVV1<~2b#a2IL#MGU*YPd7DIvuU;i&HR31wV)`?8sNV_O0$&C{w&Q};{R`@
zSxQgU(`=PylL6BA-=(>sW5uBF!1vSA;HrJWRnvm2R>k+$ph)OPei4kE_EB)P)%J|U
zoXtCRw?22XYyHlD?w|?g^Dg)EGoOPDfUC9yuLa?DW0KQ}V6W`pIr_<ao{TGW3QY?{
zSvGE1p+Gw=Z(8fc*%nic)4J_;8&KJ>SI7LG7k_%$aZK$N?%9h*qkIwh@IP4#Vv04z
zujanhtt}|rz+YGDHB!I7Ii>sVB|EhuhNR9fm~q1W;_%10+t+lQwetnali2-r>C%3f
z^M?Vt#;<jRIuCXgL~d@V+-Lrddo$8^op~bEKY)A=<s?D@uiYU2t)AMMZE1#+R$ksw
zwhZ+nD1#CTQp%5y^p}`FwtY6LbXQ-eJrNg@yI($NVlZL%m`$U1UtG;FH&9k26zCtg
z6QBO}W_-SALTp&JsLh$S*9!8d)Q*__!F%XH^OtyN|F3C0d~fZB@2$zeRcnE(rW98V
zs0Mh+6ABKR?dkM5@4%|n&!?@wf9h@TETc0`mR-DX(<@1IeOHSl+?O{|7AX`=RZ}=6
z4Lp5v*_^&NpSi?z{%C!w^?`#Xx2B!<oqykq%HO$aLD;bQpVK^}`I$-TXX^dh=t4!&
z$CF#OOsLaFba2D?WjC&_ctv9zd~eMNu9{MRm$n2~jjI1O4GOLrTHjlPf~$ts-=$T-
zRlAGVwBR)@7U`f}MNi7dPpUSaIjekb#M>?oA0#pMqk|nf>#PrJGc?)!aJ#5C#XHf)
z#GJypYu6f{oZM};@lV-X$7`B*nf73O#gXX?uFu;wBWiNx5C?`i)R)4wYH505+V;}E
zhhGVfme!BIW2V!O@w7g2>Dj<he#VY{%Q3bj>g$AptrwJzM%LZ1Ld{C|%8q*mi-ki6
zUT)jzoZh7d4O{n!?1lG|=S?Wwji-4YFLZld)G0BH`N8et&ZZ;A>^Q8jzQJslgS8&M
zX<CH(J@!04t|?vo;J~)oPu{L>xm|VH5rZiT#WQ+Jllth!4UJ!}?S`@m_PCFSTb-HU
zKKH}1i`ysjnihWeMs~zUJ>Ik5KK|wOK2f-F%lRM2#@%<{|MAu^ZA0bl@nw_TQ*WNf
zwdFM}PP(0cXFprxX7QDTqxyR5ecc}S%R@ae>%ZtMjgnQ)PZx}{Z#dMeWA}NR=6VH|
zub&$g-*xt?a>4m{)ZL=KRVd&!Ef!4O%FJ*KY18-gjPVIbf4ru}w>8LkO^d<H=Y`!J
zV6|@hjSZ^v`)uB{WOl0{j6Y>d_fe~TiSs<On=Or<9KLkpT-6nlGv-=zdff~#F5CLi
z%b@#Alq;hYUnsb9Z&v$82OsGtEwHpP3LYW2IO$gFoNeZ}Q<83-(ediv5$z*Ts45g3
z-esHXJjcBKT!*1qx80<*Hr_k*OU~5iTDONqWOrM)dlt&WdQiBzxs9I%c34sW+Pm<j
z?-s6za2`;Wo?$xiSy#P@YjTfT&S980X#XJ;?5UsCX0p2S0@c77%MSZ7KdR50expZx
zv(T9PZLas28i?<xR%joBeAhK2e}3fi$LF8sjTUE*>~Lq}6|Es*w*z<N?R>x}HaU$t
z0SyXQQU9FX$z8(p1-%Mt9l3q&vFOhDJ0j7b=SjjqJ-v{T)6gc3J+8~Bz;dNP<L4on
zQ<WnupLWfBpr7gLb~WN-=+>?#-NWM;=I_$9;I;b=9xmF?Yxjqvl0hhVRk$=#yZ48#
znzJ4W5?;IKK6E@2@i5xRBrete<g7IbW_bT&-|JdDKG*8k-9_iOhKpThq_{TqxmY|y
zd)eM$Fa7!qD{10WjPgYG{WNvB;+xq+T1*d5>X_ET>ZiP-P@R|VnY%CRyo>#Lg~Kin
zXgad@TiAQ&$%zTM@!IO+C%uZ;Z{Bk6zg4@RtA_sHrFqY5)PGx}{uPS47==%D)NI`~
zjs1&iW_BDD`a1>HiKtp*cED26SSl>4b!Z$G={wjoSS9QOj~VG2*mT&9u!mqPYvG=O
zRTePJ5!fGKe}-)Xn+a<Gn+4kw_BiYc*b}fcrtwMGwXk?BNgJSE@+@pa*j(7Au;*c0
z!(M{z44V&2dJb1%?P0IMj)A=a`wsRd?DpDdHwn9e>gHjoj{XiT`N06l>p2-zr!Zj%
zi^G4?9%_Veczm-OI8-l+N2N3pVf4r0y9P)=3`hlefY*|NZ}6^Q2LeG1NCCN^1Sn0%
zwZMB$38(~W$g4X5ClCmtKpaR086Y2&043ztmOum~AQ9IBX@beaJdJIuX^!@=z!OA+
zG*ATSo6-V!f+&y*t^-9RY8va-5rl&TkPT>DTa{ke26%&iqm~S>8-q65C{HQ^m4I|(
z{@b*y{!HhF#@D4h(MXE)4qFNPEqxo(w)vjAHeYMn{F$E3U(vGpTE`|^TY)J7{KR{J
z_W<t!-UGY`cn|O%;61?I1NcP$qW}L&EdQt`YqNa^ZGWl#ud%kQ9WS-Jr8c?LrkBFd
zd;$KacJ4+9L+!lRH)fa(plaHJ`K{HKQ!&4{+VUaHAC)hkfX$K5pM^aqpI60x8-l9o
zBG%{2|GNQuOFn-O_JMp}0r3%ls!0X&4XZ8xH}ygPp8db8>km}d9{7LN9r&w#$~AFe
z41gtY0-hicgo7v$3lcy&$N?yRWy_?T@VcK2@<9>3`lFD>68M5}K;JvwAQmJ7D#u9%
z)E~S9%6q6!xHrfEC7=?7qs%KCQ2%cl0GYm5vOzx3R7PK2;6xT}&B8%6pl^{fKz+H5
zfCMCid{6}R(Vv_8c1MGFkO|6wF4D0P$iuy)ghC|?U<V?>3t)uwYYhrP2NW`qMu0bn
zZ3-WNa$wX9=L_OMGH}(xJfQyCG;XIShy{tjt`&R$sPDC@5b+1mK(iD610oQIzS2dY
z45;CvSOZ6(-yQn`5|9iEKnX}Qf(4bp358{;pa7JBOq8`Kp<G21<O2f>Tpthy(m@d@
z1G*?v5dmL7y<qY{At>&HZ7p%`APgjfbdU}5KmjNQWuV9k$3T05BB0w3#{muCTgs0V
zVJYw8C*A|R2Y3(g9^gH|dw}-<?*ZNeyazse0G~+cPpyEj5xnc0ivohFBfqQ{KXvE#
z^YNb~4)PcKiadfO!J-iSih_eYL~enBG%E>m^Z$MCe=k2bLzhq8$5{yg#+<QGXI$|P
zj~a9>rYNws+$u3cd^~~zf&;uH!Vbeb3he_WK7Kya(0yFkFTgL*$5$N0)M4z@<6A;Q
zPu@>CjK2FYB?C0wW|jjxoIz%218UCT;^Kz5p&Pu9#K+B-dc;$N5Qh5M<Fn>llT|mY
zt;d+F3t{aQ6xjap_=I4T@EvBa(9dC{tu?z2t5{7$dj&tY;7Qc?U7((VbrKwyJ~y<&
z*f_9#_VM}1)MK{~^9V9<36{7?#8|~ppJl>Cem?XqOA~#5(u7Y^_Iwg#`*N8embeTU
zVrA$e_Luj^rx7&2IkA1OtMA*I3V1NVeGFae7Jzh^Qsw&&{)_u2-2gf-39wi2@^zaa
zJD)NvTjFAH9S@W1IC)&hzvDWt`!FkN6P7nw?a|w~)unGsug!3AvhV${;j8mb8CpGt
z1UAvqOxxlKZ7W*}cO__PlaUWSn?8~3uX`hD(({Lw>t{}y|MFP)xu*m6*v4z%+j$^`
zt9ks?>FjaW_#c^dU~kt)PbOJB3J7oaEY>SRTi2~(a^SRM_hNnPin#ZM<~pt&*Ku39
zwgKikZmZuQ@=L^#+^{3toAlPRO42iR6*f2Aw!g?vI63yri)HP~rgvQO{l|Bm#~!zM
zVf!C6?xvlQUI+}C_OY+C)%1>Yo2(6bHF){pdq3`RL1N|FcmCJjbROf}^7aQ0eKAMh
zppFewoY%Zhqf2Xbb9Nu8ySL>20lj6&RJgY7ZHKZ7p`d@=&4t-zEt(}aXwq*^AFZ`9
z?WZ4~V%@xbSma^Fp7#cCM%f4(uI6!)7qQ`z3*Ru>VS~+Yd`PqVb{}yyl&c5@HIF~b
zwa+itw#Qui;BalD%(d?i*FHGEvVO7M-61Zm(}fWa$}2)1-qIS^r()WAv!M=m4Tlv*
z3>mZ#K6YdKRJ07XYtgRlqh^VY)BNo{r$sH24$=Scy3~AbPPb-#Tg1OaIg};&x#n?T
zml;vGlS3E13#dKoPKKi7$P`hj`7bl>59-wF^u?89f?L13ScJUAk=<X-eP(8|;a0t$
z{ceDj!)qUp<A--`TmG)+oNyiOzC9k^UzI$bd9vP&d)rj5<GSxe9e_~Ktzh!Uq_rWv
z!;QCh-EwT=O7~gAPS3QxeepC?-{H`f-FRSZL^-8Ua3EJwd!gyV#p-qU#tgV)e?MZ|
zp3oQVJ}fBmU%7em+zs2HdBXa+=JDTu8%+DV{&pR6;zrkv#@^>ndqyR_th+CwiT?g^
z1}R?c6q>c@@DT0)*!>kU#~zh-T-NM)EARf_?pwpP&kR?s1+L@8ru{(Y(PYZ|G}S$A
z@4hzr@mAL>U93(W)_wV~b<tLl{;WYkKg7mEN7jzQy|nX-k9sJnv~yFl=zb#5@j#<J
zDM?F9_1ufcTe+Ae;kmvEWw1iQgGs^9Q}%4zJI1}`%4F?`19vCC9=$U=ddDua4~1)j
zV@@#4I(C13TFor|?NZ=R^KElh>j`6XkN+CgargDCm2b{V<~+GX?RxvM`DxsKy%QCE
zm#)xmR`NP)&qJ%U9`6)|jxRU+A9>&4>Ex0P(1Gkh$6Yj~u}hhP<;kmqlrIMV(mvq%
z!HJy@*6lfVPe5Chfrjr^VVrI@TzDVx`nbI>B@4O@zG_v+sh5K1GQ&cvHC}Bx*?aCS
zcUIxv2O^Zck6t7XPdVzSHg@Cc=984?)C$io$yxr&T(k9ZH_P{>KPDnfs3XO1z=7vB
zWn1!=m$nRuZmSj4+Vj0bqY*<(-t>xctJml7k>lL^Koqj)@wml|(jhu$A{Td4OFZGy
z{g<VSa>N6d_4{#R$?E+hN=X}&YoDWDcz;Eo_z5Y~2F)2Z!TDsX4fC9vEk0^K+S6Fy
zOdPr@x76|F508-_u-CWdacYxHX@7<9*17a+*4Lx$?Vktv4Q<nL@v}8bb)MTk^Ig7U
zZONks5h%ZB-*a*bR_m_J*jX<o@~OJ;)hO4^A*Ys4U1^|guP`gyE@laQca_~AlOs7e
zdxLJ5qNm4NPJBGk=i0VFug(!F&nvcHcrtg5pa}1<$YX?p3(5E0{SK*nuUdJ%@~ZQ=
zin5I7iwf6XD=MBnWv$Ic@kZ2Pu;GHPso6zF4p0mp@kqSc>KAFJ{%WU^Z0A0@vC=@X
z%(ZI@>NePLHIH|%qfN&x*O9c_So`(e?&C{zf~^yl85)dQ|MN80;C)HYgsBHc?qV3O
z<D!<celE5?73AAD*zc`%|Ggf=3KZ_G$t|5R`iXE!=o_uXW4o6!%p5k{M775+9Grjj
zGxm$~o1ndH&8$>cVWT3CZuW0~&ePPJhq@OXHoYv~`Sx(LxvwLO4IDje`x#Y^+;+t;
z?!mg?0qreHQp&Z)qTMumzDh^pJBl8Eym>}*WTTCHHPZsyr?wuQ_LEv)gXcM|D>kBD
z<uMyhXMdg4L}mBo?K_=$SZQow-(<bY-P845v{p~<)b*poK0MnRo0DHQH&A_j;jy2`
zAgj{VD<$z7lf~s?-@DJoz3zF;Zow`3n&7JOz_pJqS1kyxnhadEoy4dE5(=JmNZu+g
z8(-1XsN?PQO>=q{9*%C7JZ<mDh@@`4XYXE?$1q$q878p)3*4dJj_K(ru}HtT_S=1H
zy0iDk)JZz+q$^|U{up_%nPcbK(T}WRE~(d7U%%{F(($NH;~qdaoQ+@WMlBAUHm&n|
z`sKc=%$8*xJi7K&eQ)fyq`qEz-MP0GB%xjlAFM(_vPIYRjUH{Szx778=L4o<x=N2`
z8E^JCRGx1V71aFD`F0Gmn2q1K!kaN?q@s@L?M(8r8tBbbTRZDwQoAv;&+gx$o__u@
z!i`|#r+H?$;t!*j&dD%|ueW&Q7>!$^kkGo$%f>YAb26j<n31l~u4D7lvsw$po2*vE
z80cO|Pwm$E*_)%rY9h7Srj>63gKUfkzD7MFyT6+I)^OD_;M%u_tM<Ts)-Ua2hQ=tH
zO5z(OUVLP=>xyTy1*10()Xlnm+4r)6j_zIfg==49u6@`Yac>F*;gUvo9lGv+Vy3d<
z+UfGz8#k)Eu34V`K21{F^6if|ve9{gYhQA@*U=}>eCPA-gU2!F>rMQnX|00eS$DqH
z>N&xN^ElZix&6ypKMzw_z2VIP>mB)X&Uro44XgFI=eUfC)9yCn-q(q%#u8V}un87)
z9y2B%C>(bBM3?g`vK}pYwCZrB;L#r8*&mCeriX7(eM$B8acsE$b$_-^Q0$>n*mOef
z`pcDb&)@Gl^;}d;s_&KUi)tUV#``4KKKrNG{dFI`W5H_+C*`9<#x;G`@clyD{w?~n
z&w4MJ_5OZgQgV|y3@Z02e#c)AfAMMxvtyN3e)`_EI*R+92UWgkWUTn2cUY4FFJ2&@
z)MLY$pRwq+USWsE=B%O57X7+QWoO9Zp=FipFHE`Gw2PMNZ!=J@jdwA;Z`j%N?>nkc
z%X4w){mZXIPj5cLjL4ey!{MOII+1Gz1qa|ci284#;Bn-=I<w#RdSvm-pww^o)v0Gq
z;fAk0KRJ8Fwdrbu=g#*PU%&dW#k6Og*A4c}QqWlXepCSBw}stbwDH=`AAcO;7|{Ft
zr4O+lcM~H9e>|CUs^z&Qr7yb7+}RpqceCNVFGVh5b{cl*x<?$<aJJX0eFd)PrnS2z
z)^*sNHpIFV?<6nTa3=2+5B1n~!O||h%g2M8<{9m)wJM<QYK7K2pA1|2x=go%dmq?-
z?Duq}G*aW{tJzarTDr`iemNzyR=(z(Me8?8YPUSGC2Y;yBi#Fra@CaLs)5H<OXye=
z_WB+iW&HM~<h`F+w@E?k2dEyXm3l;F`(UQo`y6G5ZdudOc8dMJT=-rqEZ1QFWs9i$
zZ?x{EczT~NbPXO}x=4A_<{r*NEb;ELiVbJBxU9VWw3fG=inPZ^7#0^ilJwU(v^Z{U
z%+O`4wA$KDM!I6Zd!FXKUgcGH(UTODE6Ym<MH`&*I^3mo)Guk9+*1MyX67O}bJYsC
z#(p<mF{$V^CabjdQWcH5na&9#QY;=CKUxrT&qDc1sMG5TJTKR<>3+e5!c&{fhm5_~
zw$J1V?>ealEqXGqy!(&mA77c1?cCJaAMI+`bXv3K+5>if)<>G}(|lxbsD5GpvOxol
z=dDwEdu33%sAEK6s8XZKk5Y!&$36!uBvWIQwWIxqUQfG_rh0Mcj>{nfo0!z?zi#cF
zx7wc1KH`Mg@-+iT)xG1kO+B^wY+UVFgS$4W^Y+;uh^sZQ!=mJkQmxx9@E*p7t68hD
zj6LqmrRIi~rOOP*B(1w}A~`t6q+-q7wIkcUondo*-KC8c9%!e6ZzQ20OVcT@9W(F2
z7VQ_AosA8jmiP@l+1NsJ#f*i~A0oPy#o+yl4fjYSx~pp$c>DaJoSz!x=dL*3OSSd;
ziX7bmnLTVB9!Jh+m{&NJKp-#6X3Mzalo+Ny)_DS&gy?&Q<VTvPQY0OwEi4{oG!z2c
zH?Je?SS)ve#U)|7!p?y028%;5#<0s^@#-pF4vSaQPkrFzWzK9_G#yuf|8)UP%@B^P
z7Hl2Z=JM?<F)uGqX3LpryV_WXR|$4%h;WLSL-r(X0E@>E4MoA=9Hh7;C_`tYlx8DA
zBA|Kdi&F@ykMo{f3vG-5jTzz!asl;gc>xr0KpOYM3DB6$U-xODahj`-(Ofk?b8cPa
zU5Ibh7|b-@M^%57NM+1}WRMO}LBNE8M34rk4Ol+N(@|i`fo2;8#uSJEKk**mJ-~Z_
z_W<vKf3gSgIQ^pie|s!fjsJJL72YB64M274Iha2Ms6L#=1f+Uxbv)1;gQ}@1<~8NZ
zUynOhy{&nDgrRo2G*xfgUwu3>ny)@4*&2LLQ5yi7Q~<sA;M0yi+t~KwVX*Na1*C&)
z@B;4#)_6Av1X5st_W}u^e*1-ZA27wU-xElH0iOHOARZ*jpY>{Zw#R_$pcqhlZ+a0^
z0h&Mw5h({sc&V`go}doSi~LnvZuxPK;4^;WJ-~Z__W<t!-UGY`cn|O%;61>5fcF6J
zfxq1Y_$+3|e&_c8Arc>7S*w5MyR`f7B5x<JDKAz>(-%e+Q2jz<R9>WRk+u7G^YnBP
zhXvL+Hkqn?Y%(isZ?6!>w(Cc826>xy+Jmf3d)0A^<;S&!MO_AC4ci3AWs+pa^%P@x
zKWs$(3#dHe8xz|upN{K*KdT?t3Cj|cMc69@vInO2^+H+)>=k5jp>+mWmTl+fMs+&W
z?|`JQs1JNHmR)3VVb7%lmSx-fizi^ds=q<i`M6S{52kK_iZt}W4>+HMWZC&pe}gJN
zYU00dOrOq2h(D{J4~0eX$EUc{v8%?HE0Z6$C;q4Fhx#Y>`W4ELOMMaCWv9&g@~<BI
z^LfkmLSyFP5c2p1i6v9qd}*2DROO2Vlo8QH*Nx)T4^Wyi*ede{#pyrw#pn3QPKx5A
zg#F9>^*KH?RvuQ%ubI1#Td-J`kg=|MTovhN#e`~QoB_j319aVDs^S_bnHngTr9=Gn
zt?AQs`y7uj_84Ud9fP!#;z;$G2Nw4&w48UQe#L_Z5i@(eRGz-N)r~qQ?)2<px+6c&
z-x`&PT-%FrZ3osyNXN~0KHfvGUdkDd2RCwCtUMAE>Dko1?y_EsUJkmqE#I_0>SVdL
z+v3`Oifel(uI-q(woi&hS*lPF+pw0sI3{Dx$suh=PFUZxFY`g_6=0eae!b(E^=X0Y
zM6&u|y7%RI97A~@O_XeP**W(9l~UU6jABkB*e<YCk6Z}kc@#r=7fq<cC9PC;8iR0@
zpN)fU4LcrI57q^?JFF`#Wpi$@SV#5GQp!(|#H7)%Ua)bn-mn{CePDONPJ}%KI|()$
z7B`*rJggsV9;`p?UDyEFhp>ULl>UNX>mr`Pu*$F@u$0G5fi;Ak3fmhN>0U~CFzy5P
zJT0-UJnv%jG%S8m|J(-QD4%N!i#ltj9W33O?O`eJ!~CcH$nzqG@+g{6RQ#zP8_AFL
zGu5AyAF2MF@=*9lN_m+nEcx9A$ny_&9*gY#O6AowAzx$ngSbdhmriBbZ2djz!lk{i
zjACxK9v?}B-5>l@b&s?6J{G@d4}kqjDL=rrY`uDKSSl*-1KSnW5|-j;1v?P7FYHiQ
z<aN@?u-33)u>D~vPZ<D9e$miVVDy1C5CI8@2Cf|xm_*nx*bLZwz)!pfcn|O%;61>5
zfcL<Ej|XZYsvkef<EzHD?PD6@g@(R?>I)fWCth~w8$%iMbwNF#0yMCWzJZl6Uy7HD
z=imjsWXLD3b@@0XBLsMNqW2I6pC9zT$hHNHhfM{UAP*D)dQYTs08`)!0zo*S_JXk>
z0mR^>q<BG&0ePSVP@4maFV)M_`A~ZVI!CIXCrkDAWR>Lq<1qZhdw}-<?*ZNeya#v>
z@E+hjz<YrA0Pg|b1H1?RH6BpJnN0iZ_5YsY;7O7IRs-;}&R$UP@3jCu0{nvme8nyS
zA(Ft5>Y{u>pLGEhT<QB>rVFU_$=0k3*oe_pcX65G;o>Hd1o^m!NW{UY7uQwy7W)Q@
zgQ~Bk`WIbwH;FI$F48un56H^#xu7=PZGzZO>@Sgp36^-GPFz=gw2!}MKxi=Pgmu*i
z1cdl|x=DNjP;o{3vFdAELl`^t9U8K-3QJV*aMh&Hu|iphpys}*5&bA!%^DJ1`*<g?
z`xA_u_EB)P)%J|UoXtCRw?22XYyHlD?w|?g^Dg)EGoQ1cyJi~KzSdl|1GsATZDsv8
zN3*V1XvM}UMX}G0uilo`>d2at+8ZxV+P|<M_mXSL<4}e<#-8t8L6>XGJ4LFSj_xpI
z-Xjy|CebHmEgvhYEqyR^#mT$Q8`0;34ObNAHbrmnu#MjF3sy~Cpf%ImaAa_y#oU>W
z!-7(mpUCNmdPw%THEa8E?ZeMiBZ;f_8&}P$_9%c83Upem4LXvdG1PZ;$8*W`m+aa6
z_G)I<f}=0TE*p2Mbw`yF)SIG=Oepy2rRIC7=dF*<gN`)pA8;~yWzf$aD~I)t@EDVM
zdBx@ql?*e4-Cx^_@#|OpwAA>~%e~Q|P2+BrDeRodI4oLkKHBK!O5-g^S6np<rm*`f
zS985Iv&9-$uiO{5@AT`xt94`6^&##@E5ijkYds#2hEr=)hzbP*e_g59Nd5lil<vEi
z?9_@Fk~+U&#tHX}!yo5vU(<2c&KJ;{VD}fWXzMNS4fX?PM%1sZe5v`%{)c9?H7y*n
zsBX(a^ZUAV+rqt1`$Kkr@kh@tuJdr>RK1hC9lKfGe&~AeM4R!tb}A?9ow=OC-16Yw
zr=6>o2-m*q^-;kq6fEz2wq?|t_CxHSY&&dYrta5Z=7Py1?1s%)yZDCQ0L59G8HTHN
z%0^U@bI~T@swv1-%fV^{9oP25q2_nD&TrW@b(ntBV($pAL-wM?o7;<yZSOmG-O~^U
z^jBlkLCxA9gIT}qn6Ou?=hE{(FKM_XHEV`rpQy*Lr)4LdYjAw<szVnZJX?bH3T(KV
zH5yj4;X-XjuIjnFL2TTGMXTd?cGd{0=rFH`^s2_(;+v<&>QD4Uy8<&hkD4{GxM~k_
z)g<Gp?Z;J%k84{X5&#eiURd-@>E`3CG2(=-(qrxCPlxZHn}1HR*8YzbR_E8Q=!8Zr
z8La;*!e(6dd)s!H!#>3xUSUzQtWM<J+M!n2wr>C4)1UNJmSTJlHeBVLtut<K*m{4?
zw0egcw`v=rHm&5D{_T5>QVy2C+q~IqI@+C};f7FP)5g6(sg_`JsY<K$KBftkB|(|P
zI}F_0qfXx^2j2&L2t>OLHhxa?jOJ%1sh_F$YoiMlMITRY*)pL{8_~fH<CopIy5dzJ
z(o`!nkPr&??`-5b`mW7K!{{mV-ClNo6jW}!;!!h&)O<bPgBoi_+M!(x8%`r%ocyNN
zD>FOCk#A--S~;q6xO2N5@dm3dzq!%xOoc;T?roY5vHQDVC9cfuw`gP+-_COs*X^sX
zB`rHUb9zqTtpyz)uPoX66zzW4aF2c~Yx-;6-MjCH&F*>5S-0fDt+~A{qkcL2gZ7?T
z`q>%_xNA(+MWYd+z+F0GnC;2t6G!cSseII=m2SRK(w5w;A6u&D=}qb-EgFt?NNl+A
zOQqVSO?QWETA4fQqtev6bMh;1<y`6d=&-~s_cxQ(bD>4WhAWHp+N2qBd62)T)~^cJ
zn@<aSB|13p*Q*boOxD{wDouYe#&EWz<JPQA!c{AkYg?}nHh$r=P1AbUny*{<UZdx|
zc*{G^qZ~FBmIsgW(hI${LvunS=x7*G{910^cwaBzRosrLif$^W)H<Bmx;w~h_2~Gm
z^%^y3u2q6?Ts3dFwjJZDiN{rYhO34#S1n<#nsZ#WgfFx2R|`&F+ji)Kv-x<ZUpEB?
zS>D)xb5Ua5u#Ban&qOC&P|8w-wj>%r2?g~B>=H*mDa^g{X2fEzlqRz}AN4S+8+JB!
zYl^0s*xNA;8mR2`UD)HN9QP(~P5OOMACjCuYs1Bml53Z&yR>9FEnF6P%?ypFxN25$
z)d=RQ!Fz{|-y@U6$(1w9KO8$>@Kc-I(y?i8$9`x$z-RBSK^5a4MEJocTs6tKYW8u}
z*5#_{%T=R`s}>qpO<!ts$3@GFt5zjfjbN_YU_;sXJ$dw4{oa^brCM(ylgD&xyV*w7
z*W94AVtr>@<&NsRqwt-g%jSPIYY98D;cC_h=BmxkRTFO}d)%5ehq-EAbJalQs(r~-
z`!|I>kLWCol2y)67mTxSIMl0S_j#M<dIgrRpBok5b@r-q!TET!&t|V%h-c}WaUYeQ
zH+C@?q48*S!r7<=Q@1iR97EdlJw0Q50`5z$TEbj4g1KttbJpl$&*M$rPm$6HowXB$
z6$6~imphMHC@Iq!WS?j_>b+!cyDObAmLeOjW{oaYTe{!YXIw2^<aPeJH0<RM`?EKM
zOxb)aNsu`GP4W8L6IPCu;(ddw7A{u}K&~47Ts2y`YT-t*=X>nI(g_dzXCyql`9?H&
z`Mj{Z1FY6<zp+7eexJ>omdtJy#4wxLaIN+w&hyM}wlsEf_|lDYRaZ#Pm}|}Hbu+-Y
zZ0koagYGjKhO3r;8N0ulwST#4`E%8b<f;M9Rr7z|AWAPaYxM78!?}zKELRFNejbuJ
zRXM`)Y1hmL`kAh7S0g@#ZtZH)Jv@%P_8?b{{)_B!I}TXt)M#4BuKAZ#z295p6jw9~
z?qB$LYv@nOZf#E-8gY!fMm1Nhe6AY!jZn6T@9z5N>`v|yo-gQCQ0vI;YmY^D#@`W%
z20c#_2I}dBj6_3jF&csk1*ayaZ}!mY-aB>o+S0){FP?ZiZns6}vei0EL%lv+ckYAy
zimN8_z`?Y?tTAJrdg!ITn$hWOPw(J!9fFTs@rv=WT)WKw-Lit+SxRU#hKB82G~u~w
zN^{jb<f?_sRjZt<_Agg0f36zUT(zf{v)7|$O=+&$#9TFkxoZDDXUm6LJU-Xz*WE?u
zw}y*dW~8__^|@F)LwniYVK4pq3@d5kQ;hF@b4o9%!xi7m9@1iZcv8o-7FIvy6@}`&
zbkE#<S?68s&np~uq1@~+d%j`sohK(I<i=~OkDv4^V!wIIy_;=%Xl@v|>X@JTuCA{d
zaM!@+svUoWJ?`OhbF)j=4g0qGSW#ZMN2;?~&FzWXTiZ&9@@Zbh(MkCB;5x<u*Rcz}
zx3(l#O<JxR<kX==D5zO;ldBdzSFPFaJ!S&eu@Jaw^>WoJ=c*w~;}?gEpiKqRK|Xi^
z)W)IA1vml;hyke}4>*oT{S&M&Y$VVCMj#%fgM3f|6kYKA1O~tch=2q{gG7)4@<9nu
zbj9@s7Qhh%f+#>bobj+}AP<xPB{#$kSOQ1j4Wd8_$OUCU!yRz~@z)S<kOPXmusy8i
zb?guSnZi1PXi!;SfyoP%wGGxrXD}mR2fRTzhzA)UA5;PjJOlNC9S8(5AO+-t5}<^#
z!Ga!`2bDn06n(*f69@!RAPyvh43G~>fRY)`3y6ROBr@11$isX&&@_jSfG3CsX`l$u
zca;V31W_OrTnCC4h$nCa;UEEIgA$<93)=v15Cu|cxi^+UETB$aA|M5cAP1;fB7VRd
z#DYvv0yM3#9{7S7kO~TcT3@UOo*))vf?}Z2561$&ARc6b0#FIGQP*JsL?9f*gA7mr
zDuFi2W-WjSgoAjH0SW+hFw+G#AO}!+WhHPxxrYSAfNW3(H1G}L3ev!JppSQ88{i4T
zK`bZ$l|YF1HcQ|Nq#yxgf<jOZG?9;60#6VH5<w;?0U9W;H3Ci`93+AqPy*D3AiM(h
z1FGxM8eqKx@CDHz1>}H2pg0t13D^K{KppPlKq|-qg`g5>+vB*v4)}r?kOuNW2~a{k
zMh9R6JV6vl0Xd)uRDy)zu;6QbTqh@-3rGN&pb#jH!MzUbfCR*Y3{VWz#^QbhB0vJd
zY2Z3woDoOh1Oh=k$OUCUO@!+V9LY{c96>b5(8T=^j%zUk+kmo}xTdqPe?{y|3O~SB
z!Y0o~UWWN9{oZeB_g2oqdDOwSk=QqE5hw#TSSB4`yCujIV0GtWzpxIl8L+Ofr0-h^
zs%!k_V||szZ;=v?JrDbX6~Y>Tusir)8F2$uy1%3aNZP-;h-)G&>HiiZY&I-u0Bg?2
zwt$~_5AYt~J-~Z__W<t!-UGY`cn|O%;61>5fcL;Z(F3&*sp|dzmtlEfV|-_WswoEZ
ztK`e;VK>O<x4>?d&r{e`%<rwXd<gSL<;y2vbL8`9Vb96utLy*MJ}zQ?zWl!%u(#y%
z_h28$=M}V}e+8;070frRw%ic)V^l|0HLZfW+FNY<n|ym(-w5FwSKCGd^G&KPQ(Hx4
zP=sxpU|&B}+h6r@545npdA0vqVO}U-Zi3@At#(X9%p1#>tB;k?1MAG>>-)pn$meZg
z2g&CL!`jK`hr&9@=l^V+1xJJ#DGxUWRwSQyhZW1`ePR9O^W+x^=0oMn)yHX=g>{kg
z^&0TY&?YD!!Fg7v`gjc~_>cNP(4>TNGtz7D1QL)9%77vgpEpPcIiN@&D_?Oy8H+2>
zu8ngBVIT^K>d4A};$c-#regu@Kmy1Eg}@c%ILRO%P}xpcwQ`(F%<H49#scWqM_3RD
zlEHOA<2h&oClC$NK@L#E`C5QLAO+DN6%+vtqz_$?*$8EfKp#G`0OZF)pbH-u0SjOU
zoIn{Z!+*XYocxHgvPz)R4A))@#{elH14x=<9%KNARyZG!4AOzC5OD$Vz^*mQ4nYFY
z*T;V#5TtZQyns>{Y-5091I2Fm52Sz$aNP*UHio}Jm<fCdDuD{h#B+eIDb4|?m_wrj
zID#lZ^>(=+)&dq301cE+I|33iivgLS94Mizn%cklf^gt~GUPar4AKCVE$4#kpa{GG
zh1Q5me^?+K0G|PV;yu87fcF6J0p0_=2Y3(g9^gH|d*DC!06w!m>Hqur_)iiC`HOu;
z=pP>}3c;@^ILJff7RYw=mjt=_|GtC2Z@`3Z1}@!=O<a7%Zk{d@Hy>a8xciDf_wN_r
z7<r$fsER)LMS-=MFZ=foaq|cY5LyKXi~X=|5F2_PgB}4Mp`HxKh%w?YF&f>70)j=7
zfB@fM(G(AnO+c{3$<##T=I3c*B=Yk$G3wIasXv3$V!CvZul?gwa0~WBOthHV>Zv1Y
zG5ADvarrVZ`(LK>@BSk<uv&#3u)X<6e7^`rJU(V|d~t__Rb5tvnfK4`_WI12UQZn@
zoIVr{G+J0PRpFC^_!-^<ya#v>@E+hjz<YrA0Pg|b1H1=#5AYt~J@DN<fN$C_>i?^M
zhNAkEpLh@O9^gH|dw}-<?*ZNeya#v>@E+hjz<YrA0Plf+fd{DmfBaw9|Ccuj2!`&y
z|AgN+3JCQG_6QF2mo))k%oz)H1y^bV@PDK6Pa6HC<6no7>F`&L^`0g#+=#<DtAb@9
z2koH?*Vkk4mpsz4@zc>9`&$z`emafgF2uh<Xp?QPAoBqQru9_cFI$h14<tbWzVh|-
zKeZdL3h&}0L3n|B5!R>T;E;M?)DqZupiO~noOoGy`F>~vOf()mQHFT~6y9*vaQoic
zPFyvwt~pZMhtwba=d|7ac#dHorP@wTE80A1uDtZ%fTHI&6%2E2^-TB3+L9w&jT%r~
zwWj?H>9{p(K6BN^`nQZb{|f2G8_3f<L-#@gK$i$c1ZesJ&G+g4XbKD1@yc<VAYC%j
zQLx&uKCmreXTS<!XTi3HoekRtmhLTGSR{E?>q8%fiKL&A)(MH7pLh@O9^gH|dw}-<
z?*ZNeya#v>@E-VEJn(h>e?!FLN4&Jtx90@B@YDCPO$*sKZS}t1H2+8ay;ZOe`hKQw
zVN+lSoPZ|?1mPeGgyB<w`hSN3>I0q+6meWSCO`2W;61>5fcF6J0p0_=2Y3(g9^gH|
zdw}-<?*ZNe-_HY7|3CIWuK)K92=xj0ef573lmPywx_>Ry{kyn8xxgh@;wBNh___JJ
zO%VHu{ZV^f)h?hO!i@Iu_Y4RPMmqpq^#K7P{+@0Up8$VZ7^}Xvs1N<KFtT<91DJ;D
zbR`l{Zb4IhI1>_ZOdVJewA5ZaRiSnTq?-`zOOcU?!z3<#0iI$P{{Y_rk4Y9D-fls?
zQIFb4jp}5-F<I`$%0_4pK;<TVa5Q@bFE%K(H3-AHwa}QeS8xyU@{)-rP*^F}ljfnl
zf(On_!nP-H_$sW6*q@4H*ftAPHnWQj9}w)~?dI?4D`wYI*-ap{_Usjc#K9rH5?PxC
zb#=>6>w^PAf;_}kZ5b?ZveEFxKA``MJ$E+lRGdTcw^s-hizmsBNo7JhpVqkq`%DwF
z?HW`WGxfq!*|y{1Lu%_VNbYA9O01Zc$o;$k))irxmo@o0lpO6Mfd(D<n*8>S>65Re
z`15ODQ+ZV$%E7+&bqv;j?Q8O9^{~}_?TY`t<!kcM<UjDWZ2gzMPK1xkA*`VUJYRkG
zHC?mGpt`Reu>429?p^k!uTA8>j+Xn{65A>PNcJ)A@O9=JHhi!oAV>@?jDSgQ-niLi
zenpUPO`rVA?x$KBRz+G>!xoCTX^>XgYh88x4$ym~sQ@$p*MKLEulDwjkFSX^-<Uof
zUx+`eUspPQ2dty=PC7odyP@rs*!Z|l#T^?M;Nvf$JB!j`)%{+K>qOI1_@3HFM8kR^
zZU*IS+&<s$xbJ;j0)kvZBwnWSTb{Q2Pwsb$8>L&>{Vq=n^4p&Nlj1*FI+Xt>yY<;~
z`kZ#<_i?rDVm@sr|4+VM7wppp|H=IIIpeB2Ib@bD@-5hVm+~V@dtc`lI#^Hlx@<pm
z8@hSGp}{UyI}&@c?V$8=z4PJM_sB!8%lrsGsjE}k-Or{OY~bU|UKDv0**wY;|Azp1
zUdLvFbgd{K(XNoC?cUhFdOlJFolu%YI2PsCqhTo@Nv-_q`r*2DGjZ_>3h;A5E3DuE
z->QsTb`2@*d}I2Q-VE?(_4HQdqw0ABZBKc&CG6Mv2&L!hVXNmONV4C|FO)v5|D0dY
zxmUG;vw;RGO}0q0bne!$-Z=Nb5A3<)n$q1YJ3l9y`Q2p6wt;H|O`If!2K0Q>wHw;q
zkb=>9xWayY&fZuj%kw@zrzp(^V!iCz%GS%C0<z}=r9C{dab0Dp46|%HDaN%cz)2p(
z@(x*?*>qrpWm$Na{$YVZE>qlm*=tU1>}VS`oc9fcne<VXCg@sN)Ub^;w%La;*2sZy
zp6qd~|6m*Pad&y%*?}5UVS=11*2?@$%Z#!r?T7WTu9uI$E)odk1(Z&HKdD7@$4c^Z
zBiVN3=WY~^)+v8p$8KKT_d~0_BUJf*Xtj5Q>b|d9|1IASt>$~#`Kht_qdqkb!*mcC
za}(Izu#|>kYO#J|&#x-Gqw_0gL;vnao{o^`!YS3$48@N$gJo&v%RGzn6E*xNOE+Kq
zS9J<(zF~>O$?_sL1NV3Hb@`O|+F>7*UP6Gq!dL$z_I_?Y{%F?9UhhnV`TBWH@yo+{
z*)z2&XQ1~wY9lAh2W4rIva8@v_Y|c$x>&ksKxeP;DNn_I)YWsaUiO?1^}+k$SCNwK
z7c#ocMm8_3o+VK{WO;Qi`z{y|>M!>E-45tJAnjvKRL)(+elE+d6?=}+SpK7Xhqkf9
zHg^$btKjo}KzYNTZ6n1t=?D|0_<0-G8n#KpHv17~Ztc(8Q2PC|;}m0?>j-nM&gX3?
z{GV;3jr95p!kkt5yp6PmZCtU<bcC7HK(-B~p*SpmnFgvo-{cu7-8WUfzm9#p!Zrd`
z**@sHMSj}H=d>bw;&}PsHJshn6Wis3bqH%M-<Hyu1D5Zy>A}}6SmGiM3JM6qDmLGv
z<I*$GP9EQP$f0R@k9>I|?pIpQkT26Sl9t=a_fPNMv|M$(s%K~!_Fs(j>ob%=`&xc1
z;K6r)ZX?hzHreg<@KCE|Xj5)PemOaG(Yt`!v+iUlN{&nsm74!D<NlydtxjKDIVQOE
ztBXYgk#68ap`ctx(r#nz*LS;*FVP9MPFQAWFlznJ(_Dl1B|Q_S9vHa`@AxJZuGsoi
zkZ<2$zqi)?_j(K~P`I}yw{*tnC&DG6Z?qDR?Ouxg^`LP4Sit{(j|Kd_$N1$sw(vsS
z>_WkZ+cx#HJ0_1k+^C~_mebi2dtNp@o_WT7(Vk^?Tb6YBB@24$Y&g{o#=>X9umiVx
zJxj@r(tFtAO4D1Hcg<<Oc*<`NayL=?igRqZw{`a2op<rbEBz0P<`qm`*jDt*k@n55
zTyj}r+hlp&v7L^g4Tl{aH%rqguN^b*!4~ZonVpRdpO*LyJ=xeobH$8>(H|nZmBld3
zGj@MUkCL9&SDAU_+JoQLuNJ>)_d2QV{wN2%tgtf^4EuFRM~2yC813&}z=l4RQ<9R?
z{6@AG?5LOCch|Gaf?nxy!M$INi!~@mS{}q6_mN0+SJyJ|_W46OKQ+kDU2(jZYU}qE
zIl2Qfd)PWWj+_rYc{D;73I^EO^zS>WP|I_1=>5yDLr-r$!i>n8_QT<z%Q}&31_cK&
z4A(J@yR-3on6M!K)cAJ+SAMJfXlQAZo$J<cRYS9^@pUuJUk-7dyb|xvj&$5w?N@Id
z(r5TN>&Rg9{Kkha43B8=z$Nhfbo+`4EgPFYpa-@Uh2zIa7QDSWG0e5|#+09o_6)&8
z<a>{iEbd2se%2v*tGH}@MN^}Wx6?Px=~;L<x>@qHy(1%%y7ivDds!aR6`q4aK}453
zYadRWZfcR2a$fO#Q-u<nqO~1|ADpAJwp)YQZ3JiprNdq~(~k=e9u5C(?Nm4YJp(I0
z_6UEH*k!a=-rVWZkYw$UxB`ZWV2|6nQHukoP3yd#ez~tIvt?NakFGsc-y8casjt^w
zckZnPNesiaKgumNil2sfuW7W-@Ij&R%?hq5mwr_DS$0W_@qTF5L4Ee^JxNHTXOOmp
z0`E(ai<q5;9lGujM>U-7^=e;%>$z#|Zi#grHm41-E>%Z5WuMc__T9MIKB-RJ#^=G8
zFK@gwck({#nJQU{w{&{m?AqX60G?SN+4Ei5qFLPmW@k+r4^FE)<!sm4;UmuGjgu@K
zK48h{X5A0x+T!`f`tNpHd16}9|Ht0Bz}2+1`+wGoilkCX!jgo9P;{emNpvSf(fy`-
ztrUt?N+E<0l|rc$O6`O~gpd@W2yLPyDLcuo^#6_7%5GoI*`0Iz&-<SDUGww#uHRg9
zjydNT&m8kM#xtLpJ;b<Wm731yeH*OZ*5_84zc)~7yj7hzDgn=17tz+nWP}&m4Z0Fk
z^kGB5r=n*Wtx|3IUkxtkzVg58W8y!!Vjd2U3VMC1n$r@*>e2?MRTbI4p*l7R%^s28
zmOE51d{%_d$cv@&@Ilig>x-T;nEgIT%Hy3%XZ=8fd-odD7iY(oFg`C8IDdWf#6ue>
z%9JignYT#YmzX0>Uz(l-S(zKpeLM71sd>KiY(p;zX{nr(c)}e?U#IU%?{GMwb1+It
z?tWh8^eG?OE~|)GiUg~6wt4yJsVw@8wq1JvGL~=bW;`B~o}W~ld`2$qqm9AXuO4Ab
zoYc2HobRr_6*sME^meyO@jLo=9A94>{o(qNQ-xy+VsFYEf9RUKv%2Jgb>lmKeE)^s
z?&!4RuN6E$#hl*2XCrh=Wa6E)EFZNaE924zi47Sk-6)1Oc{<%G4{4^vwIZ!%_wJ{A
zhMgFYED*itcE-Noi{o9#2Tz)xKv5I$K+0suj*9mw$PhPjJ2L5B>fk-+lD|B@TDaqK
z%j*4WZjGHJ)QEdRLy}H2{MqjJ)vrd1p3E0q@aW|m;d?vp2xw?oIG9Zsy=Cw%35wFj
zLo1U}8(_0uLErSabKH)@8+J%<cAmN1w?;E;vze(+=7Af<lW;Fgmp9g<V9WXJX>|>*
znsuIm@*kodLuBM^I=sC$UV9bo#&3!Dis<|;jW6{sI{0Lhh<;eOn?vQ}x1%<Gm~vF#
zzK}<JZ`TS>)cMWy{Y#*hLqbe;3v0)8{l_{3&FApg@1I$t6YDr`vax-3y9Ms`ccIcS
z8L2gGluUrWdeyfa1Dh&W^Bca7MZQ}VQ_nT5sWJD@@uH|H^nH^|PT9t>yNfh8sN_t~
zveE4vI%iUaM)|&$Nvj5ovMt)R6858yw|y;AU2OYj-4;s<hA#BH8F|R(irpd8xgmC|
zu0A}NJh2mP`wPi-4@|i`I-+fYp>e~hOL}Ue?n5^3@LpzM8Wg{~N<o)zOEN_n(&Zgr
z9+z-<-(Hovmh4D>$(U!YJZCmjCc6^US1La}q;eAV<s^OlMykY5>E3Q=<~g_Y!MA9;
zmq{V|-8YMGjlQ?1sd?(=Gh=appe`^O`!1R8t5%7W2`r0e=&9Kh=_y_AI&|vl=E9R3
zDvx)hVY}<;?Y4_pKiE7f*4nY8dGS}p!C!f+wp1G0UhWKJ$i~~fDY%YzwCLk#(JzM-
z#6({wXUxdjb4EJEFf+V5=!R|i(sw24v6Hr(X~ywJ+r@mFa`@F0(K~~F5xd_}+kNxo
zNvDD1EH4~eyT9u3!B1XT7y0HllQDJb1XGJ|x^gO?Wtp;X&Q^ye4;9o3Km95w@9doh
zrs8>unoifhxXX8U4}80BgTl=$v*|j|-&$X|F>bA#fzZuCcOGU?&+O3NLZ1&hSR0}Q
zWg<O{Ds%4V2$vh3e(1MIViy0xqwz1k$k>1A#y4g($aVu+VlPdm<u<4Z9ei@TeZcYK
zqSmno^15<Z1GK+vuPQ3V_ipI*ZQiRsQ@d&Z%vC8z@83xEEuPg88y3HO{FflT%A*gC
zcVN3QbU8eCr9E>#X1r)~$lw8j4@R~uycjfIwZ?E4|L7&*^Q@+yq^Q^U-VKv6A<8I9
zP?Z%YmQ-G+bM}$_h#f1BFOn;K{?P5AlC0cIoUe}4`Rh<W^Kpj$8me^Ax}PO^tFITn
zaQJnQ$emL;GhGioJl(pVqNdXIDx>}Sau1gJyTu<?G@YGielFyG>WqgMW+^#ktvazX
ztNaMsn(6bY!1L~~Ms~|&3Fq0DN{tUjv%e+2RuFjlBCv2>>0N<+<rH;`-oG<ep5F0U
z(_HYf;Tp*gL%Vh^UN}l?LSYwcOV{g~lvIhWXlq1+K9ixgyS077#?jBrYh~7k%&f1j
zV=a`uxH~33%4q*#>G1~M`0kGyN$2xK#2_?Om(O=uokOzD&+N$yMQ)`m4y&s=q{P>1
zJuQQxZ1B9uWQ_JT7$rZxZbXvVMh|2AjS;)phKk=lH>rmePaiRFR9p+*JEV{EccX%u
z3}x?x?w&4^bi-=K&wF<jJ1p8ifBU+|Be~0(Oi}l`X}b)(o33s$Y+zTF<T@&KuEm9^
zNl&(Eb~)NDXQ@oMfB3^q)IU01M?la+_b=m3O@88=?HCZTMdwD@v(qA-<M|iP-PABo
zkWEqgbh^_{+0q(&ORwx1dNQ*x$V@BZ-RF%(Dffn4*FSvm{+kbb&<>?b%5iM)6<w$7
zQ%_X~xw2n|X(bd?Yu?;@XQgVahSRE+5pQswJVLL}UvK$gjjSQjG52>Ji90hz+^1vW
zw%P2*;$ihqZ>?5bXOA{9+AcA#XEVPx?s-uukRIJ4nm2RJ;NxAgy2+>0)zcMgmNTmG
z%{6+vDL+%T^O>nNVyaO$sGWCZg9|5Urj%M_Jvj6=yzBCYM2b2`ua9|jL)WEjL2s7u
zs&h}LxNUnCC>&olxhXDxtgmN*ocw9D3()!N+?p2j{8-xSts4hj95!aWpUB3>4~oxU
ziDg`9|C*evMjABe<Gfi@BV)RYh4``?asuyUKE7X?8&+|Tk2klwL#H(U;N&S3bwHok
z<?o*_qv+%O@6SW6xR+ougamZ8@>h>b-8OZl%h72{&&BV}$w?Aq)OMz+DXfg1a)zQV
z(d(=GwN>($vX?KrOoKJ<S;#fMc@{QDJL2cN!)4BGQ7jVQK~eANbhhkeri*WmT(=^t
zMey>hF>)2kDJM$`w~rPrQ*fQbu3bt|{CM_eGX6f@2>QNh?OwJ_lVq0Pi9;nTx&=1y
zZ>{KjR{UsM-6fVy$*;4Hgi+KodVQ_Yjwhu29xm~)<o$)Ga^%K<PnH)J{qp#2gSSHV
ziX6q==)ck?+kG^vW6r9=rm=g4#QCpUBreO)e5+EoBkGl=;3I$Y&mCpxlc29}`a?7d
zRU6WG-F~ipB}?%0x1_rd?wsBCSlys)(C+FEVVr{=N|E&~)%Leb`LgWsa0jN=7r*->
z5~i4BT^zmOYpH?yY}coof1;={biK+wBWAzyrC#^U$o1hiEi>wT+EotLjo`_wP;k2-
z9=jaRT7Gmn0)tg^=JJNi)pUt#yo%F)VX?yGL`}Qz3P%P1XQ!o{a4ot-r`tJuU$L#k
zms#__i5jL>Y&ll$*ZAbYf~lja$vgLlK2gKD#hKo&c!fi18}BDI1GD9ATf`2n=v-<c
ze>zU-@WZyM`FA=@_$g{WeO?P?hl)S_6ujPQv{m?~hZ+976;fMwB^+lB7=7bpKx|k6
z?kDN>-PdvGygGl^@~Li9w(=eQX|OcA_3q|P#a_>LOnP^yG3`D2ap?0^ljlsSyN}~D
zj}PwnVBO3=#3MFqq42`XKX16067_bJ3eIaP^!aaRmvlghQtm^|h}Uh>uQKeNOKYrs
zmp1JZbWNUZVW=&G>jGU~hmtavZ^|koQW^)wl$>4d$%tq<D>e8)Y>0Q%<QUD&!)TwS
zujd8H{N=_|wRz_#8(f%ww`#{H_xhwQ8bhrzTnw4xy`^#f8%AG0l7|R?zW>hMZi!CQ
zkwdIFac_rq2e+3W)_m5uX0YR#7>-G6dVPCXugtbvN1uo=a`Eeu%U-OiYpU(g8YJ)d
za@oCxg?SCA2lRc|j+;+TUHoRDzSjJg6J9>rRk=@hCGiL3?_GH(GV#7ZAs_Cq==BZO
zJ?jwJP*d`#ZP{+e42dmMF59W`2i%QL%aBrYa5l@qJ0JA*Bgp%Fjp^+hQ%esP*6pb~
ze5sRBcaC{?dws;Fz+=KKNm$=6^nP1oQ<m#%)Vx(uX`mieUp7)p>_NO-aaI9;cH`^w
z3j38P%9lRBG(EcD+mWTyTwbk}|LI++d-0de6HA7VjjIxDzi8f>{urkrdVlZ@P{}%C
zEpKG?_RyHXEX^x&mnGAiPVKliw$^w}(6?Q(6g7jsuHF<Lws}i?Sjd;DCf`_5#w&eI
zrpP7)j5A7Aza$^gR*&<B8f|A=8Q!I-sndg1_7$bAl~SL&@y*(ff=xRrx19}&@a{A;
zLA|1nw=ttt?{7?Rns@0F<8ssBxEE@&^C|lU1rI(fTH&r@Hm{wc*3tP(yDxA#l>gX4
z5goZlr(Y@UW*RMeIDYayg$F~1j-4Gk$Cjc#N|58S>V27Av)r6=*~Xbs!)?mXNG@A-
z`VvpVkYK9|yl>kiYw^wtU5@V9rrmGOp9*gHa%6P6@csg&^*r@K8tfD;xfr9k12Q%g
zb(`MqyQMmJoNU9sT`N!bZg02}efDLE-%jI-8xvo+ScI6b!u=$rN49(Y^U~%|>#5U+
zr7QBX<7N4BEtYgPi>dH6&kc~!ZEnWC;HQs|`>C&O-7ktdA3jvs`PgDjM{EAaT{ZDf
zYU_j7$Lp0l9LN5px4SrNVoc8D`^(<6clf=1CcQ?hV`GAvk;%)MrZpjkOLoF`3iNi>
z?`Td>;5jXxTxj%R*Dq&<&iL&%YVAz8zy7i0RB7Q~gV5(epa0ffT;Fi1(RTCGXUXZ4
zlnjqfYkePo%%LkdP0%uIjP`0Cih4mGZ*{YhygN6yf4f#%y>DDe)9RcrtG^A?b;&-v
zq+{)y5O>shGkSe-U*7$E`zOmlmC@ndt7Bf<=5{|bm6<7+9@pw>oB6a9`4ge-94zon
zOYpEYkMXSXb5G~3-Wu|*QtgGZ|NDV0!4r=R3`6J3W_o>xyMn*!>X>|XvAcfh?5P7^
zHMR!I%FLVn_VwY^wNyg_Y-dE5x1sKx=&Mz{P10?lsjH@sPu3H5Q&(#0NSLx%aFS?N
zgg-^eW7|x|LjL5MqSjF(Qin*)->M}YA2ngq_4NxzP6!CS#HaB}Kbaz5I6=A#P8l1Q
zY&CVVxH;z7Hj5FvFRQP#S5Z`R@IPGAWY#kL9YwvP_nU0)z|15;+XE9O-+9}qqG>FV
zAoTL~U@Pe(-jk<woBV`*Rz=?*)KJ&znkMZZ@o|jv!kadwUyXyspVmK0ysW5@;AZn~
zei^>~NS8OVP`vT5#rqv=jE5RIPMWdpM3|#jdqP-5+_d1s?Tpemd<T+VpZUI3LoTPe
zM@hOq&UcD7IPi7zZl{xyua8!B1eA2C)DEGjGxTx(rk(fG#H8A@PtOTN8@|)jSASEs
z^!=EWDSND+@{hamp%Ue#uUq^#L{*;F7uZIbQ8{1A=R3cD_|wR;<rh`-i~P+xPnE5r
zs94(0JMP!qI-zd3`qg+XZ>O)5g?)B4Y-^vfz4YCqtwk1+79P0&qtmsO?F(gx$i_P{
zJ9N#}4_K_)$!e8dVw^N{MHeef{?TN7JC;tjpkU-rQguof2iGiYU9w1J+fjipkCx<F
zP73kz7ZB_0W~1MTPUmOe)V8Ku;NvhWrDfuEM-uNw?AVY-1)2Gcn|C{CZ6fO5FjcbO
zjB1CUdtkKi{*8y0Z?g4f=ISeV9Z@?F==fy0VB5pIuRgeb(C5>I{8tty^34{ik#s6a
zc-R?M`g+=idl6BYZjaJ;4Y;sCfTE_+_d}0-_DU>&YcJWr%H^+0asBvKJ7KeHc+0iG
zd+&A6EshgM|I;k8-E|`GnoTUWyQ{dzxI4-0kKK}K%@nJ(n{NE&N|}_xwlR3$j$U7J
z^%1#4`DX@2g}xVMep+Fj?04(HhC@m+#yne!45Id!p%08sXBt$QKU?hap(A%n-shE`
z&CyV_kR0^uoab|PjUT<K$O(1DjNb0w->*q8A^A&5@H(Lwo^Wers2hCgLW7rPFIzrJ
z?<4;TN!78DQD>|AAGc;cy}p=Sg&Q67_8ycO(fGOW+*_TT*<bmXW-ZAc1zkhldp90K
z`x>1tq@X0AAYEdvf=-Hpsx@=u%u~6w?o99KJI(v$TQ^O@{k<?<-h}+eO}iXRKe7W_
zhUXR?^IM;MErpS^sjWU?fYYJX>>U)fjb2~<&I!ZCU*_Cl-}my{*geleXVauGiFlt+
z`Umu1Z9iw#if`i5>$~=5uhSckpv1RN+bs1DYzug)t8+BH>X>l2R`Q8G!DCPllIe6~
zeoESAUo>KGw0Gd%<6*)FS$EW>x6XO$snVL(?Wi<kGh(aI*VPxVwoDMaP^Xx(Lt9VT
zcNwGH_1W0sQ|iw%Ql8zBbzC?J-&v)Pqf2KOmso67pAcqZRQTM6&3pXS#h;5ee3X7}
z8d5a<Xx0|AOVQ6;VI{*pcuhPw_{rD6y<c}846)E{&C6F^_hFjCy4aG-+ISvpqsx14
zaN#&_QNbO;UP1dWxl`Lkw{5DL9XG;1>h-wF*&Dp@96yGB4v4ePuLuwQ_^$MQ*-D3^
z<r7~Ve<W=f@Z9Tk*_k&KpTuo6TcEBo86AV~8QeU}EUlhX&0FyN$vevzYhPGeF8P?k
z^iojpTfPx}>-2W5R(Q1wc&U8!yShOzMEm`;t8WyqTH8Dh>Gn^XHfu&;48B)P+vV1}
zyktA+8FMqU;+yoJmf!fYCQEZl>k-+#{*K=&Ewpf4mecE-q`TK#Y@^@V@CU-qU7E%9
z9b&!<Yu=^#?@P5Af8*k^YZP^#uFtu$=L`x`=N<EP3I8QB{=LciH`2{gb^`N`O}JdJ
zmyaLkmroS>uz9}wa?(DY)BrrUV|pN_lfembZg6W%;_9%GP0AIz0_qMu1;uLEctj?C
zd29;H;PSwhf^LAyLSY8BA~X<6d?-VphR{&xCg?WkeP}qe9J&L_;6+;)Q~<gcDgi}v
z0(%iO8fpNIh2qmxR6NuLngI2OCPImy<}v7QXcF`)GzEGCioCKPKr^8{41CiYIvkn<
z9SOY%CH_N~q069Gq0Z1k=sM^v=oV-(bQkmvbPx0qG#UB?dJ$R)&4)gRK7hV}Rzqu`
zEl}JhvD=_^P~uZt5AEF_9G_3x7xX{d9}8f2vOlb#WPe<NlKp|a()(j9>`C^AI+W~>
zMNqOo%%Eg{kZ)FpK>eVh&@?F7AA+z?ICL<S><=9%*&n)4vOn;-FnWJ%hm!q4>`eB@
zQ7G9T8Bnr6E<zKbkD$k(PoPQAAt-kWR18Y?2NO#6hcT4w4`OGsKRlsif1H4l{c#$4
z6<Q1}gx-PPg1&*0{Xy(W_6PADCHq4Zb|w2m5lZ&QR4CaWi=bqGm_loyZqQn&H?$5)
zd~bXAhZ1bb@e8H2F;4aeR!`zT(Zd9!7r@v=s1_8bFM2=fVVvX7N&9({<pyFJE}8V8
zh;&0RHU&Byierww209Iz1jTmQ$U8M1O6r9k_6^4ellILd>yyWHa!iq-73n0QpP^WW
zYKN*qe}$5K@$sM@LkB{=p~BEGs2KDhR2+H&DgjM}j)Y>LP%==GkI~Rt=on}dlnHHy
zj)!91lst4WQ~^31icnZ=q@k3c<oKTf)rQW5E`-j3`a`v#x1c)EQs{i>Xw(y3=y)i~
z&Gv)hoWUmb%^129iaN|rhT^`O{RV0aZG_rGzd{|L4D2XpXeiVTN_<(}p~Rjsfa4QM
z`$`gfieOqKAcH#WM$UV4q2r<2Q0yDh<;hlq&WGZ%M=gSq^C8CR^WhTcS^PJFK7}rY
z)<c&;87Q9_Q~+uYCHrm_6lEvz$=JkK6LsKw{y2V%v_In?^S2S@Ao;^NlzfhyoUhp(
z&>(09*0UK(?8S!eg9by7KtrMAd-U6&524}E7tjdkXxL{vlpK$d(Am%^s5W#Tl=xHb
zhZ6fu1RS3~+82=I533>Z)97Ir(g|XWEKkyVVJ63ij`po1>2bNG?8!nH;*d@P8V{Wh
zJqjIxawI_8p^4B;q&)#`f+j&fLr+4}kuRLP*fr2oP;%U#hK_<}LFYhkLM5=xVyFqU
z1bPU14|)=cy2m~PErVWw;#$Nmf<A!0fj)xH!U6mkssVipmEp(v1Udow0;&vs37rLf
z4b_3xLXDvHPzz`S)DGGTCBB<qpeh15UZGmhuh7NNU!ft;Zs=1eFE6$OgW}rAo(|=M
zYCs1-Sx{Un*(Fe%v)LmC;d}PbanK>qDNtdkBUBvv3@Q!%1v(0<I2h+Ms2UW<9D6lX
z0qOyr4E2T1g62R~p_id*&>PUX&@!kN^chqe+6kQp{RW*69Uz3`7%C5444nuygiePV
zL6<_8LLH#y&{*gyXg<^mdL3#5mBb0t2}*q2T%qHk?obD)H`EEb9-0E(1ntCrGsl4z
z2ok|nPy+;T&?x}}zyfg~AJhYp)hHvd1Z<E4DgkAI{sLeQyg(c%0j)p;2d^eD12w3t
zBB+-O01G7I1kedmF;31;a;T%$AP{NeKpv<7%|HYPzalULED!}UK^bTT;%kuyU<TYk
zD2M}jpaL`kJ}Vr9KndspOTYq=APMAy3eX7ntSO2KG=UlL0ui7D`HO?*fHKes1Z<Eu
zpbgA`Gl&2gpair6aa-gM#NmRG35r1@kgCLS;E45Mo+`%8KqM&hr|&x`nGIMD7yxGw
z2;x9Kr~sWnd?U6G41gDi0vVtLGy;K5@SUEGanK1wRB?_1=D-U?fEbVp@<9b?1OjR(
z6R-p<kVIjfpbX>fKuR6<0rnsg<bYa0+Fmq)J%|9Apc3$DBA>tv1cF3R1R8<R94rHz
zK?KMo|L5XAhz67v@&U*NI|&p65pCoTID=?#6*K}V9ZUyqAPQuH8Xz(c(}6vR23J8n
z5TB220XGl_u7YaN31k*v9<T&~AP(e%YS0N}7GgfI1c4w9<b!H}7e^>Lpa(+RkT)g|
zI%0V!5g^x&JYZT9$Ojdm9TX#N4d?_Wi(q#U1&Tl`5ZA-H7h^tPE<t&KHDH58a23>m
zb|9sX`M@4TfFy7gGy-u0)GJ^P0znce28}?(5XT5G0d61?WPoB&1Ne+ke}Eov25b-m
zGC?t@0i8g`7~22_zzsx!98duofdFm<CIUTR4<bMYC<e8l6X4oQX>P)N5DCfxQQjcb
zThO{0b!if8vjxWvAIesU?Xi&$jCVp)gK_S_INtzl12AFtIB4cI<N+Eu4BLU$KS!E@
zSY|7xK~+PsEod!h1$y{Tu3s!XyoEyL!mtjg2{a#S4K0Cof*h<v2G=AK_f!*9V4m{}
z>}!l)1+{>08`cYDLX|)b@*P0Z;2M<*RFTg-sFXD7&>-v&Kw_xMp)5(z98izt+9#vz
z7_R_Q;aC^2#<EeM2-E^TSsqFW*n<EN4Ke|D;97ud0j>qO7WntH056K&-OVYx2%dRx
zNpMoZwF=A|gWE09p7)=~`&RSupS%k-P6pQ?&^wTKl6K=7x)<yR(cl0$2o8Z55DUn=
ztBK$QNCGL~6vzN)0cl(~2h9cN!39tNu7GQx2;2gh*xqgE9YEfB>K(|tFzqw(d<e{u
z{}o^*=p9yJ+y#(#U&#9`V^D^%fV_**J1{Z62J^}LFBM2r38Y5gItwNFC+}#IcQPF?
zpS<&{4Vzd&$@`-^7$@_3|Ifky51i#zV?K!qpn+*FnDz~M><0Tr_q=~>hk4}vW-ZJo
z??aP!ka@-7rvRI*#ddoKK1>@3dee+Vx)Jz)1M4I{SmYh;xmd>*EEC#iIex510Q3%S
znCH=FJ`3aiod1K7ZU`ssPE3pBOpk&d=8Pvmk8#FNLen_oWc`^K&+ha8BE~Os{@;KW
zbH?vN?{UV3vAv<3ZI)wN1!sB{^ciRT74!{foCo`f(PzI2VSH$x|3hID(g)Eye8F<R
za+W32#E^DapY-Awm+13f0?Q8XvpjiGeHbTy(wIK7&%7}hXL9~aU>lNswlfpsDxCk4
zSYC>=j@g)|#+m+pCh7_5!AC#_MdZU7^V~rQ7>Iq$4+Oy=K!$KkKLW_$4fO*XIRD3E
zd2{4v6<7`A@qYrC2*@xMIt?sDdOglEMo<&ZxEXXgXM7dZk~3}#b>NKiq8ubvXYW9c
z8<Gzr32Ya2u)ncFiP_`;9y6&0zyw%=0D#+V(&pXstqYu&w1EMr1ZXp&nn5R!!buEm
zGxYZ`G@)o8q1((zds-wQ?Fu=d43PE(ih*MRkah-bU<pY71!)6K1Q~#|pVxwBAcXtv
z$N|{SK;#ct12;gP5qh5w3~<k%1gb$JXb0lBx0eITz!@|GChq6Wfioa&Qc)lg<bYyO
z1DZi65WxMsI8XxGzzwiL6u1gXKn-XHQiD-%fGRKmmLL>FfjE!>NE=i&XauDFiM$Ic
z2b4f4hyc|<Xb7HNz(k-7w1ELI2P_Z?;y?x{CgV8w)B+LIO(v)Ys;CS0fSgyz`MnWH
zVP{VSq;5umM39R5!Z#e{1TvD?4zL6npc*s+6DgzxnV<ycVj(;asRBK~HxhXS*1!ua
zKs{uEP|ynGa6VQB5g-o~13esPQ6Ld0<6LPESRfD7gLa}!<Yz2w3hY5NC;}BgTo&s9
zED#Dx#$y?vD3517U=5-{5vTxO6H!i34H|*mBy1m4fLg#-K)ygb5SWZSO+|h|45*lf
z@+zUcKo5}44ppEBs+CcG9Bay80cZqLvtVOT31ns?PasbR^FSvMnuqOyB2WRC^HCQ;
zJ}3sHtwR6@q9U*cUch`I_6H#C8O6X%7yBG!fP6sODk=bJuV@Bki?D4ytOKY5JwW=&
z%Rmk2G(ep*M7;u1c>Xs5)*u=bgG!KS3I+9G!7^+Q6oX1o3z|VE5HQ3308F3=RKdjM
zSnmoba0a1Zr3mU3>|+Hb*I9iixqc6Xl6xI;J|k)bCD-z$9QA^dYbtl(T7YW-t_8Rj
z;9B5c$pU;R%zyv;e<X<0pTqw-dN~BxIe4)+Aprl^zyJ5Y5d%=HPn<y?mM3{!p?beJ
zs7v+4$uZ#VsVU=mNE{E`qd>pRg6^i{fAoeaB#W!7`#O92x!GI!kXVFPeqLlr5<3UC
zPJb~l=@?VJF+h4^!npWac{n&BjNy6*EJ0$;m_vK!x%t{!+0q{nB-5?GPw&|pnM2m)
z{C&E!4FYr_+!k5L7d|wiqPX4UtP9(52tW`ow+#qv<An%3h^=U2OJbFfm?OP$riwXb
z--P7^z<Qvhi2L3>J!MC*5<3zwhm;Yw^?x;dj}OGeTt9%=hi*1bz7&adL>B0ohBaZl
z@3t!$WG<e&Vecu>QP2+9T`7vQZMt?&r?*{9r~K284k_;-N?kM)YRtn!Z?g>JEc$;>
zK8P(Vzfbe@q6>uoB!4wf9bn93<KqM+Y3sjF`z@vwN!yI+<LI<@{t$Y3C1}sKSR1@x
zTM|R21U9We*>KxT1@)ALPOFXoc_<%=m1T!<VvD}^=p+X@hP51f=t8@Y{_5Vo_L%X%
zXAc;cl>0Y(z(zBAY(#9)W4GVis2$V$V<X}}*pBjgA^nhjbou^M8}-KQB7Q7nSOG|V
zH3i>bBli9t8#y_!tQ<XT+{v-^cXgKRYbMh5)X(4Q1&KF^$(;S_f@4KMl*03w)%TUF
zt6N#Q%}`g@^z$IwvY$eB{uC=R?mHKCKuDB<^ddgI*uOnf$@<8?p20ciM55h+3@=~<
z3Fu?!04&qYDMwFuPaMIhD5M+_bm~9-d_VT0FstveN6Hq1X*vT*eItiI0)yf|*`JBf
zzWa!zmBX|?$BY%(FQhIP!`>0d>u1!(%?E$mPs-oZ+qil9`qF7x*cRz;J%F@%oU~-!
zs^8OkIQTmRkX6(9F!??m6FqwB)kIADW4$8zNW{9?SobunTj)?vKFGO{9RErH-)rr2
zV(wYLHm3KK2`5~PlQ@M;Xis`N7L&b;lMCXd`dWE<IMC<TvES$a{@mJotoG_G&VFQ)
zN{9i?0kqGZJd~g8`y)N|k+UDYJ#0L1<otb|Bz2F8bUii*Ky0U;*q1&3H^9z4b+hOH
z_ucxty4B9f(^9NQ3Xt>AVC2b!lP3gd^mXW|T6Epg!~DM(zSk`i%oN1(bUi|SBz4Ff
z)5i7GE&60grdeZJpE^Y6)%p9h-;OVm)(g`)brUC*>2%tF-==*p7_oP+t$XA3k@#z*
zT%>Jp2=aCHkL5zyFq<wL$>(1T-^*r=nSU%B$@3q}M)Lc|vXPDSO#6M=*qF}fvCa3g
zMf^7Hd)dgojQYL~7hgv=PaCp6GMx#P1;#u$1t6*=iCIVNrj2Pm$F8qGM(NmJ2NHUY
z2QRd_^*zT>XgefB-+C|<_9{ExQ#ZfY1IHd){iEuE_8)9T?8=$;-BzSrb2-Nxn^Ud@
zNGAZaz$u)uwNLbv%NN%G+--Px_5^5iw_!QcHy`9Ys*1FKG0^paoKLhdvuB@j7VEjJ
z|IV&%XnQ3?F^~e+fhg>n$l1Q%_bv9n4)$!b_a36>9`BFWrSHcLwnyKu;N(Z95qtHV
z4}QBov%gRCabS@kn;1x1QV;u{`^hvWrVSF|)HRF~Tem_J(eB#ccs;Vn0F&|K;_&o0
zZcaD7-M^2A)89BZKRSL*;(TJ49~YNq0xCT>j?8~Qj?4@(V!wL(HE*t6pY61F&Pu0%
zaTm@vIw@`I7?Y>Y`kGarR;axHpFiHrkB%cld?cCN_%Q!8@nPoUq>TMB@0`Qw)+=dY
z6Ponr-wL=NV={Nq%H{Uv^Pe`!95X2iho6NeN%wz0jtuFuVlsYQe3%~{_oct_T>2Zg
zuD@|#+-DNI=#8_j7T{%gHwleNa8XU{Z1lOhbmF4y*#qY_T<G%r=7qjHT)&x&zmEg;
zqvOc*H_luX9zvLm|NVF~6}0{SK5pH=TU?s{#?@Ogob0z#0vGkXv<J3ttj-v!aZ_-V
z<v!s}^A@bPxKux->{M7dp38r9{F?s8-+KT*0Vcyx<K*Fd!JiJuZSNk`;eX9roZo(W
zY2dO0JM#zRSa~bp0q7qU52wHJ0kf4!Ifh;dU#2)f!_h_i<TC3|dV4Hf&%Ncbn>r)0
zB{eaivg_VIF22q^6OzBbk3-9i!}HG-hldA^i-_;JG3n?S*<iy*c18hfl$MG-yp=IX
zj8(r}v9>KdO}gkVH(n1nUJo~34>w*9H(t+=iq|8A_DCjU_5d4s$Dh&)qjgNTJXxEx
z#pP>)WP`J0+;n#txkw)u{r<=G>2JL0A07Xvzj3K=Xpr*S-5i%Xp@sK~DbJB(ZRZ!9
zuGo6d@q=6d?>mh(`Rg{mMBB@cjuX`1c>6y(o=_@%KlJzU`~TVF4t=1@@%P^Y_|fr+
zW|)%t^7rxke{>w9adf*%g~j#R3WGB4*uAML8Fi>2D%4)mmVf`8T`fyqovKhBjAzCl
z9q%X_zRFBS^iW=7hp7CmHx0)xcS?|)M}1>Eda9-bR!&-#kmGgK^2f(T;(q@{>FuuE
z>drrY|K*Vp*&p8ak_Vq&5YckV2`ZmZ75jYltf4lxzed{K-yc5rV)_<ayeCCJm;L*E
zC#JvO{Rl)y8k6y<W^bs>+;7vQw$w2aKiihPHM<k?Hd1+3Os2=pEwPD+Iq;FbE{uA2
zZ_F=QwWVo+4pu=K){-ve^+7WGvrSvvwM-i&T<YPUu1?mMxs<Oh*l^UQz?4ZjqjdI_
z)%we}*j~+gDEl?~%0ZK}c6g4*HIvB*=(6xmN-T+!5nb#0DI`~YboM{X_hkAT5BpcT
z9F<>=Qa7rm9anL_ciTQ9rG@{e5DCTHHA)$d@;oC(O?->KO<hvnzmId>-?-HM{f>=4
z-pODxEWgyuUOYoG_UIv<7w3*L!YdwS8;e|=JV|R>fpcAQkr{mV@s2=$zB}`e`c4e#
z7-jb3yDsP)MY_L_-=9L)`<kyut>%xIXE*-&l_l;*<0kF?5Gye7<Kho)2TsQ~)(r{4
zr*7wv_08(yyEyyQeQkrhsofV&Y*YS;_pm4b5uUMU8cg?oZk6l6J0X%J-R1i3)askw
z9^-zonzzn7VsSw6*tY|3CkrWsuRBl`$TPVAainwT_Bx66T{*(%#=rcmy#3j<M^klf
zU6N~gJGM5>QgO=?pW)GQ@D-x>TZ@5vT*O;er-6-#=8PL&X6MDuWu)wFQn0OGt7D~>
zg8tv5bULjuo11=p;I%J&aq$raW^~E*Um_-DRTds<D`jnMctGlaGF{$xp|1u8cg?BO
z{CP=cykES9@!9|1-;?=-ernSH&GFSFF}&y)3_=h$K!z~H&w*K}2q>~iA(j*yhZTj`
zTWsPR6AcZ59)xB=4?!P7W1vr=hoLW^anR9Ne>{{4MT|H)9#kggar`CeZ_fq5XKEOx
zB>^&YFnZ#ueS?ze-B7#|g_nX5{|CYYodD&9;#DGw0aYTip*Vd~1EBMuh^@yaJ`em*
zym~_kKvzHoq2|y*P@E!3>_hfCDBg!-6B{6g6x$a%47wgF4kdQ;0vumU+6R;58&!?6
z2W0pLm#ZmIxK+}25{9nD|Dn($P`rao#|aw)Ex>=+g#87IFc$2u&~Z>+*hwBrd^;yV
z$#&U*<I_m{I+E=U!88^i!!o2J+g$-A`^OGSwrdadfjU5gp-xb;U03Kms5`U<>H#JD
z#}g_G^@dJ{vY^DL(ho}Vfm`2Rzd_ockmLhR*%Yxc87^Tz5&x2(p}2jcUP0mJLA{2O
zeBr%AdOsj$9~-x`)LST7uM+QfKR(*OkE|DN0Q9?$5V}4QpT7jupK;J*P_oSwC~iy0
zdywo^&@?D1cRF+n^c-|MG#eTX#k-R1!_ZvlHE2Gx1X=)<Ksm2KZJ}48uoZO;nghKK
zy#T!d9f-W%gbG063(Q^)h5sts8hQ`v0KE_04XuRY7@?j*lc3L_8PK;-EK4;&YoYI<
zEzl3p4rmi}C<FHbP)TSrR0jG9ssn9@8bJ~3j%@+OGHh#TC)5G@4Y~>14JC0ZDcJb{
zln<H+9RN*+4uqb9@<YkHp@PsXC}K3Su`elM=uIf{LdUTbg%Uqh#BOB2fQm!0FDVHq
ziMuETRpEnQGITC<G*llt7P<y13$=pEL7kuzpdQeP&;aOU=vJsQGzqE>Jp<K%UVzSp
z62DI^D5*ENwDkH7(*A^`-e5MR2*^-{>M8=QfsTc~g33c*L+N^lagL84?ej&JM=>Zl
zK!y#lpA>W>l+<4mSBxx|hkeBHp`*WTN|wW=og({|499W2kmXK5nNSj!j^rsFO7ffm
zT>#C6lJnAe=t^iFl$?hyLWwWaB`7)1=0l^Pm!YxHE6@|rtI%BNHE1F9I`lTQ2wDxj
z39W<Pf_{XO_;<Xh$0W|39+bqn+YKdg?kb=Up(9WRjI%AF&!CRb7f=$<jKsGKhyDyb
z0DT3;u}8<b!!bp@!T;OPI_MK9iF=1SPRG4Nou%I6|6mySBb3BhZGo<aeu9#Bm0O`+
zQ25TWeV`;h-Zm(Sj~4;`6?zydjQvmm6@lJ@ib9`4#h@Rc!=MaQ1PSPH=y2#Hs3cSi
zDh1VnqO5E)D2a!+4muLbhLX5=`=O(uY0xpyE6|D1A}EQE_Y67<`T;r{%8NRn3KfT{
zK_@}gp&C#PD2Y3$3AKUFfv$&=_<3PaE$9*GLg-ECBIqlq9+bpyS_18c>O*-3_QcPV
zfg0ieXs8KP8A{^e&4qeE&7hvp6;LlI@%@B*_4j(u@oD_adLM#xr2cM&l6oJ?Sxyh*
z9G^jI0meza$7;XFH9dmklAQlzp%b9-&>7I9P-W;bDDgc^f|BDX25@`;Y2QGyK61Q9
z0y5Ym9m$6)R37RECD(g*=qxB=#M1XAs5A6+-5ctL>Auj-P(LVH*LvsyXaF=Gx&fL1
zWkbpROEB~zGz5Ab8U}4f!TJ-AFAx{)D3Ap5KnbV;tw2bQhnff$0BaBkqCgVJ2aVwW
zcRW8PZt#?W0Vu(-5oe9-ASeTkK)?p)g<o)v1olY71~DKL6oVSj4n%NMG7)G4bKnIc
zKqANkWq^s3lqyifI_vRY8%p8@k{cN*pak@QH3$HaAQ9w%5>OBLCL(qmSOA={Yy`*v
zC7^GdL2Jwp0Ni+ku(2j$Hh_Ppc!S(Hf;etXaP0-XaRmR-@lJbVJpNbXp7xD@n1dVr
zKgK}pjenTfj(bBk?uVcx2I9n4lpX*77zeQu^HnjA#6si?!Tk(W5C6@<A7diAVSAlh
zdt#n2p??({F$(7y5+CtDi;dWh^CyXqn1r<dQH(?ZY(E+o$gAM5;v|w7iE+b_Mi6BJ
zbc{qSgBSMb7>Tt)xQ1a|4rTwVIEk8JC@bdo#!AdXUTQ%n5TC?DDFQuU57;0M<bev%
z3Ah8-0$dAlE%2{k0X%O0F8-fBPHzLz7)9PS<YD4j5)TmM-RX`oXeWYZgB<V^C<3>^
z9dH+vfP0`6^bWZgZvmIUS&#`X05ar5Pl8lX%$ZgI%>bvt8P2rJoc|X&|F1yFda^kG
zuR_T>(m4MMp$`?%o&ZhfOuGhc<&2Yj-vFP$FPv%Tq2wKEGIT=8`_Ww}vjFTs-s2Mj
z<efkUvnK}N7)itt9D!#>FbLDhdyu@CCk!R;!tr684@%y>r7$i6CGT<##5jpLMBa<)
z9a2Sm-ZLA3d6^g|@5z%GR5K)d-nsvbypXs7Uoeflll%?Z4JGdm_YOQ5=LO{b;J&f>
z$o!MIR`!k0r-8=dIiPnSF&?w=KMR}$?!XiD4rv&_g#7LVyZYpN8Ky4>E5T~eJEUX$
zOrQTb8283D{6O#U6Q-R97r`ZP8IYkA>o3LlU2q8L-{OBgXPZ|s%?elpJKzY&a1DBc
zGhPNQ2M;*^{}_w#`gpYWfZm}$u?e-u;XOFeJM@iJNT!v;zP<4ZPhh_!k$r>V5HyA}
z-Zze6Bc^@eOz#`hunE&Xf@aP<vW~xtb4cP*4i!h64(J{JnPVOP$e4qDV_f!)Z%Ja5
zx?!LEPvTpWIEMX=VMwYc6KDc+;0)M+w5h~^B+v{xfdJ00;(!ShK_X}bXlo<wW)x{3
zM|(R(+Phl;9|P%tCLl2i(KbVoHohEC1R6mnATbJ+!2;k00zneU0X2ZcKbIMRbpcD@
z2FQJX2B-w}pdHAeJ%_ZBMd2Qu#4#lI>H@eAC$S7!AOqx+aol%jf~%l6W+91JxB!>{
z76=82AOqxqGC<-LlFlFzFcIhhbKnI?yuxTeVilGE605Kk7~p=M4Kl%1Py$GtLejY-
z1W2qx5~t7rkQjwtfP6TpH%4I*#v6f~F!m|P1FA!jS6~M60EvyN3>E-u)SpC90;)m1
z7|zM4Poz$f=b{Ku0~B%0*@Jr273Of*6}W*6Pz}T-u|5z8B0(I;069`97f{5tLlaa2
zIdt4v11}H<@<1(+8VNfA65~)CSb`+b2}sOSDL~>K7J*K{9*t!|F%ZCYLJCX-N=&R9
zumOo{=mr8o45$H`valZz7zf(`d%yyTpair6J~`wS2#m*iK?KMH#XtrPj|RXJWPoZQ
zH38cOsh}CiOhlQ%RnQE`hoGbsP+x#Gu$+mqgAC9Nn99gEhyyjCnWzfvIt%s!%D@~1
zfJ8v<3F?8=Y}6}Y4q`wFXa@qSSQc1nAnza_lz?U+r`gj!WDg}DG*Sg_AQ0pLrWR}h
zSU^M@>jn`Z1{BT5HW#3*z<wd}3rL*AN)V-saZm}|mY{xvB2WPW^<f*32b>L1ZjcZ3
zR$?BA1jXja^D5*IXj@|YAQV`x#kxQes02b*urH{!hT6c+Ai@^*0z!6}2AUmFE+?!X
z@HxZgzzYO|9MB4wF0eVU1~DKNWUj+HT(J%y=LS0gdyoTaK`S61R}%tKKn^GYrUz{0
z2?f?55ZK`OBKJ1~pya-i#9bu!nvPI%kK+s__c$aDBe|!V2POAnW>9i3wH8X=$tUp~
z$^Dcml-zGEf|C0)?!dJG*8*G%a4pb33-BS?50C$cm~boykM;kk_<sWto6nbJPxZ#*
z>y1h0%+q5NU&tVUOB7Xr`w1o7JYtq3C);#<AEln8fBgMjJeSK@mc(51_H*!MIoMmF
z$lqh^kY`L|9y@0TJ6C#oZ|oCoT&Lvc;hM<(Hu#^u4gRCQsomdqNBaBC<^H~_(BE$r
z_tz)79rr&>M*V_YK5p}T-M=hYm~CfT&GRa@q$y}+19Ojmn{?8(tiA9X!u=1EvHQ%I
zOC!QQht?~Z*)5*0+`0VJBlnm$M}2iCXf|fFORq-T%t(@MdbM|VO1$6PK$Y}qC$FtL
zWV^-m_U6UU%WqSIO)j3y66pCZ29wb)%aT7n;PcBFYa3;K7bNbVsk9>D%0_G7pHe<B
zGtVzSix_jbr)Dy!V%CM=V{%h#-(MTO?%g_<C#Sp|r-TT7>`1@g5Ejd*MSB*VZiB0=
zJo``-|Mt)eBh01*N7m^?JrEr%ny~*`%JqoJYu@z#8|TaD^-0}X$~S!F-mUqw;s)(r
zzDoR=rJp~)#r{>2S~v3-u3B#0|8G6-Rww0HQ}Z<H4%>24p8Tw`!XXNqMdG)Vr^v4g
zzMFemG_UlXJnm!Z?f$)wx+%RscC8;~)ykuN^YIeFa^IgPcz(RFZpsCIjn(Ho#|tf*
z`So!B-vw}@^XGM1RG!i>V`=7<$N%*^2>pHMTW~okudwGTi&x#77A#9we>Y?Jy7AKC
z9&MD^xGSlnrk=WU`Rmdj?`u!m$e4^buD%~L&Yj9$Wjp#%s!YiFm)@UOo+*kveOB#T
zO{{O!4fuI7NxHv(r>4K}!1OnUMt@^tc#k6a8&Iy69U0?%=aa_FqnAVzswW@2ye8dY
z@ZF!ahuRb>I9|bX-)NFf*FbOKycIRl_PhOGKm6=}JGp>bR=9EaC7*|~p|MMR@oaQa
zjieJOh?`{juKVd7spVqFv!!ypCS;CXnX^x1p3=wSu^q?ptlD4S?*7KmpmfM~mCS^*
z*PPmLEBS8BfM}(cdcxa&T6{i+chSUMsmIyU&r#O?#=Pin42U1?^WNXs4*iXt&|ly4
zYZCPSy|6;%OAD*ZU2VFnPlB%SdEU$dp>%y}L|3t($@IcaIG@sX{`**F|0*%c(&+MT
zmEw2w?>N4`Hu}T$Bc}?-6vW<?IsVW!cV~6U1M9|j{%F@2LF`u>V6$F9-}Jb1+>XN=
zc1Uk_p1It&Ml)=)nW<0afg8n>;8#koFV>@A%lYhSbq%hXb)JFpAEF&YWaMl*yuCJF
zdll`*kG7G`^m#W>%ON2qyM?u5y8dIGf#!2~?Dx;C(TQ~&H`&-eyWK(veHrw9SZYlh
zB@>{pUiB@<z^2O8{J$Rq?29HTheJu3%Qt0}5h;xWV@l4h_GCn~oRu1UAU4E1YI2Nb
zCeHUK=a6)fD)Cdgw;P&y&MkfLE!ys7Qiy){&Ei|5@9k-7p1S$WSomAg=?aqh%Z;aM
z^UhH=xG?{2)s9c@^+{VahFWE~7&6CuOSiypnBMN9Uk)jViM~$Gn31*TjC6=$W_Web
z4cqdi?@H2RCv7>?j5Zj0eS281%(h!cpNKGW@#~VyUaYEXs_oDkB=7ig*}aB^c@3~1
zoo=x1S%=7mnvzFt%XT|vNNkyM*-ni=;BItUhLoCvvsn(l7lrmXCZjoZX~tzUk=4hK
zjC2*;${SeJSbX4<y42VMHricH+mn#S4CgE+BakKb(qvk0gPPF6C%4-N96v5<9eW_J
zD~B~e`^)yKqEh%9)7Q5NQASaMs;oG%r1CnQvybdY{I_Fg?VU@uEAYHKtdZR^S;Bet
zrBdUA(d=)DuN4HIz6dN_S9(`qU-`dItg9$Ik1!cAuV*vAHtu;*DUcrBBAPdI&EVr*
zvbxEq)78@zYnC&r(2q-}V;<embtzlWn<c#J+|wy;+g=3<$CpiRipwAC>scTte;R$G
zwEfoDl;!#wHE&f^8mLFrmyOgCdk`;IoK?V|-T3;v!hSp`iJ(oC$>1BHl6Ayd-pK0h
zp)rA3npfm5OQtuS+Hr4et?`<mZ@XkE>WMZ<_h?qfoK=NQWA_S)^Ix?{T$Z8vR;6x7
z)GJNFNB-uYJIc_uNgtQ`Lo^Ci8`5{(ey)8bOYrlzq`MF9oZa_W-JosI?&=O<)RlGg
zcGK<)Tn^<wc2Gn|?$PO2O1qgxiyn@jd{5!QkfCE|ht9D@A2prs-BO)9PPSp+u9g2s
zF*)Yb<qc(ria-4nyxwZGRrscd8UDN#Qd@T=9A^y}edA<6Y*+#8La%Re*2I{c$@iDN
zY47lR`%HR`R>#H!H6xRkGfitk443Rg8La8+d6VZ%sk@KkGmj7M_+Z`4Kg1(8YoYMM
z%Rg_pm=g7Nl!`avl+)|m*(DuNqLlkkGvald^s5Ye=h7N$-=$5v1YMJ7TNrA~pk0-=
z-@1$I8!k24ZhrbKIen6n;n8WW@8gd-bOomgT853$Ud@B!jZPQ$<=xM>f3gfz86Doe
zI_9-)Zuc`&nVEv=ajmYlnNLfRzs+>I!(G8&b#+WWyVza7boSJNuNqqeWo72ge*5}x
z>RPHH0c99QAD78Pgg@VZ=We$|r|HNcR-CxEL%W09%MWWlYg{wf@k|WQwGZj@^NyQO
zPF?(Fp}yAqmlIw-+EuwvcO~%$<nLX1Co=KAKp`3&oapmakoWl-)7v+umL4pu`|H>?
zGwAciP2pjix3q_ae3@$UjTL3Q(${2)Y(l^|qg3@v@)2$IXW&Op=g(G#cWG+s^k9{J
zMQLlL)TeHIv$msP(~in*XM-ZVI}J^6e?`};F{4%QZ%l8Rcj*)3a?{|r7izNeDf<Nl
z4?Zkf;jUsfuO0mf^me;rn|8lBe=4})%aPIP!ut!9*7MW{X|PkY<YJ8C4v;o>etQ4j
zPkn9ceo@r<@S)1i#};ckTJt~ds)>J6TOYhWUa#EYIQ9p9zbho5tChccT<W%|D_xFG
zQ+h6bZ%$5<AfvW3O-*5C^c0kXd@q~H2p0IJC3x7H$9Puxxu^41Zw+}@srEwI|NX$0
z;E6{Dh84qafkHbu;Ivy%q&*`7b|q~ZmVgZW=;|T=@fb(Hqb3MN7Y>EX9_?d31PXId
zL!pbI=;C7AL&c$J=BFf~q<usRdKH=kN<akaR}H{B1>e8lPTp;31ab`2c|iQ9Ly@*o
z0shRB;iC+^0P#g6{g8YE&<6oX|0D4^B)<E61Myr1dcUXEit%1w!V(mw@3)i<P^e!2
zz+V49Qh4I?*X!?Bgz;WKzc_50J8&()wE))wTnlh5z_kF^0$dAlEx@$^*8>0U7QkcM
z@BIJannmqHo86!Mq|s({3FHIPXTEj}e72!|ziCcvN&LC^K=07kFSqY^<@@?jiz0pR
zx79<i?NHD=^w$TM<l7vO=gtg}5Adi=Re&1M40?TUi|{xofPyQ71t1a6tL;Dz&!)tO
zmOP^x;F*;8$=c&N^eQL=CU_2w0jYqzKSuml$@jL2pQ^bKeEmQo$N+hu2$X@Vc-YPq
zh63`yEdvBmW@1O~z_kF^0$dAlEx@$^*8*G%a4o>K0M`Os3veyKwZQ*|1@Nd#*-|{B
zWLx&?mY%+rp0?{OZQSi=DLeW&Sh~A-xH|ZFIJjBb`LKK~{qSq)>tknW<K;z0Sw1!%
zmI3Z8vJgp5FK6lK;OyyUkMGMmc(MAv13+2hc^DB)rKwu40UQ;e3|;JeJbgVKS<Hz`
zCozq^ST61^8(ln{nDaf|y<FTJd?@0_9|s@G-fvt_<aFmcA<yX7M*i`<jc4hry?*?^
zZJze!hr8}y4YV&m`A(@e=H_B~e2190@YCNjWnx;74?jJL>h<4`!nU6+r~B!Jb}uPE
zeX3ZN^~iWqv(4s$SpkRq<M!2yX7Ap#W6`O%h(|}>VPu3%eG&h5-6mDdvW!x`Qc0dh
zz1sLmOD}Adjh{XwcpL+50sZwi{n37(KiZ%3NBdv)*N>U_LwEts{-;R2AOo6ZD0_O0
zj=#qybp=f~>=97n4>19XG<2*y;s*iu3)&At7dj08&7cxc3n-RhTSG@eNqv)n!VRG(
z&d^k@e*sLv9k>?YT7YW-t_8Rj;97ud0j>qO7T{XopWFiI{{CJ6Km5S|vj3kvAD;*0
zIok?-|NmLPd@P>T$@4lH6v2PgFJDU%;L%A4NCAZTrj!5^nG!*NJQEOq@<2f1Gm&j`
z2d)LU7T{WdYXPnWxEA1AfNKG+1-KUAT7YW-t_8Rj_^(@l^#3p6^#A`&XTLAY2i@|2
z?(WBQ4?B0So}PYnN)w+yB>nuogD|JR|M&g;hBoN+XX^O+I=I`CK7KN+r{;)KcK-HM
zzcWHP1UPWq7FeF1ZoZc5?JV^?eOczJvpBv8?ryV`r!F*KNWp7?nmUy;wKvN)zT_SE
z;gpal6RP)!7ybNl0roa58{ZA?RBznCO0-FkA*e@aCI0)`8iJ(xg0nJw2ag&cYSJ^!
z4!#Rk&JH&AR&Ji2URJgaPA(p>!vInDp84MXo<5v;4jwF&pUeyX)4ZPLhGX8jo_RhF
zEI%I)D})@haif>{>37pTJXxH1z5WV`$aCrn(w0({D7g5svSR9W=MO(SpLjpj!2XOA
zW8}JsFUy^r1P-3;#`pV{l5`sj5_T(y$nmZ_9mBhJWBcw0rICha>{YK`mzOKQmv==P
z6FQx)rx?rX+Jq;PeCxbMXgpUK@+wd+ZSJ(q?CUd&mOUP{65orX)5Y)El|15r(L!E{
zf$qWn^F^MNecHb7Szy+bt~-jl>8{N^@eK4x+fPqfs9hX8%R@CW9i}FqI-tK%iBK7A
z^v#oyRdif~c~HbCAm7;|p|7chP$pClIu4512J|=amOv-szX5bI)Cf8iY7A9^nnGtl
zk!3nQ0{Z@Ge}Lssgu@|iSnNg6RZyfQaTaL*fHhD|Lk!KHZ>m~Bt?}OmY6pd{0Gs$D
zV4Up&b%2sOhiPnt{vdH2=x^w*gZksYD|92&4NB@8(z4l5PiP3#2O0|Xg@!=`pb^jw
z&`2njrTr4((2$lx8q>G~*8*G%a4o>K0M`Os3veyKwE))wTnlh5z_9?j+JD#o&*-%b
z9=gagE*S&>8D#?Qz_kF^0$dAlEx@$^*8*G%a4o>K0M`Os3veyKwE))w|Mx8LWBUKy
z96UHL`v0Hl|0h}Q>Hh!T|DSm7ulxVwNFxb`)E=Rgw2fGQW^nrdu`<jfefVBI(`+}e
z9Qt<s)ANFQ=DFLrc=XIe*S`-sZpm_c|2VIw>z|&N_Q!b+9`+<FWVy<oc^tn0db8*%
z@0s`F&-3slf}VM`f1XFbT|w5_@aK7SL`E{N`OotZ<)CMsZGWCey42}>cK&(Z^xk>A
zZL}TxmO+Wk>+8cH27dx3W5-JVufGgfmfSMpQ1;pb5484{PFcLiy5d}TRn^EWe&2Wh
zSRaNObhn%Il#|LM1;C&NDlnb2pTXaN_F;fgXdea`j`m@IaoLC`Kw$^4nNWPrf-MV0
zJOcK3s3w%eDu5pXdlGaml=v_ZUx+Etc~G*`=R<X%h+n{70M&yMp9SIrp${cK5b%4T
zFi!h05MKxq<G>IK^U^*M#Fv5iK)|noB0doCXP}4=gbfsKB(zTh(z4;lK>I`xp9U;L
ze=}k=l=wCvUIH8b3bc;|@o^wN5`IwPBjFDvJ`$+*lr?k{6zisa9c-a&{3pH=Ay8Cu
z+Sh^jOl-q{M=0@iz&6>tpu}flH<b8F?1y68>}V+Ql{gIbf*yeqpNRx0@tH`3A}{P@
zC_;U(PeO?gMLHCDVrM{+Cw3Mz5PA-}8G0VN1xngNYvEVX$@Q&(CAb6E0$dAlEx@$^
z*8*G%a4o>K!2dN1@FK(A-JD$GA%)xj|9@={a`Vfz0M`Os3veyKwE))wTnlh5z_kF^
z0$dAlEx@(F-&=qWN!I?i<NyChAp!jDe18iGfc{KPQ6B5xV*d;L7h?a5QF5YIR_pDo
zY*+|CVC%<n@I`;UoT#&do0o%6->D?VyPT*E%Z*lFmOa!!^t3qXcNGyOmT=}Fzj!Yl
z3<YekZ9KjY*z?{wC)4CTelgNr`&R?~%>ZG1Gl291Mk19lj}1lslLdPI+tS|;ki!3Q
zz?jF*)6awTy)Rn{4K6p(vCCxG-5i%Xp@sK~DbJB(ZRZ!9uGo6d@q=6d?>mh(`Rg{m
z6r-qRswAD%ouz!kSMJ@KKPzs~?&Yh*pIQ3(^IPm+C8>2Yf8na-*663C(|xMh8!9vR
z+cc>yb&SN%wk2=P?u5LJRGt-+>2Y&QY@!-P?N=u2yJ@uRtLK0%FY@_V1?w%F)PD|o
zy=3y3+vSH=`HuZmUW*Rn8g%qB89&P`SubBHCRBPvoSCw2<fo9VeZd<KT$}MrxoKdC
z#29p5=cA*V$;e#F*A{FzYExj!q?}PY`^swlWm{~oW<8Ys8hz!U$ys#f{^;)@%%ID=
z!BtkCeJF~5d+3D`W>bPA>vW<Xhz=G_*nchMdc@>4Z%|(3k;!<T)1H)*l0C$@WtE!F
z=Y1Qj-PY$;nZGwsYP?mQI4Xf3{quCXRLyA#Vs&YQ)2fQ>-%uT!gl3P(Z_6Dj7(Oe)
zXXM3FdBpyw?RQsthr<b-gHcLy_wzERPx;VxSw+NBBv`ex&C5qmWzlE!<J0LzryYN-
z;Q1-$^aef~p<5yo@1$k<s2y1umo`Xj$Vll%?BCUNx>Fv~Oo?knTFvg=PxlNvF(6qW
zde7~QeZd#UyN(Z@G#?$;pHPpmn|tdiU4IktUl5o9GK@uaCUsgCDhWm1V~>QQdb3TS
z@E>5K|DBo$MSnRp2}*oc;736Bxhq0R9nQoFK@pWZU=T%>aQnDn5$?dX0M`Os3veyK
zwE))wTnlh5z_q}?js^bM|1XT9ZO4NEd6o^q!vlFfmcj$Ye-`gQL!6?>b2b@-0D1Ps
z^91o*rpU90C2$5Tzy@A;4!6dJy+9@?0esjV*%o);T7YW-t_8Rj;97ud0j>qO7T{Wd
zYXPnWxEA1AfNOytZvk}o{SW&8Sw1!%fBqnVohROFcXQ-?5rDkUtSL%5Fv~do{saCC
z{r{v7pL|Pj2B!}{fYXOB2SpbuH3s^V3fdKB452V;MQ_^^8@KYM`|<Vu+GKP;zBKyn
zN&AG~K+;cdHQ&$22XEvrW7)7A;A0>vYEI?>V;&C&e>)Tj<6@X@{e8N-jjt>DegH!>
z71LPAzzOL6p1jcOP$ts>*1s^o%g1Ux;`WpG+I!z^&y&D=$!PmvGMXM;@a@RbX)dqU
z%K!AP)V=u2=7}Z4$Hr9&wqG>wOn*#K*;pBqG4x9KGQ|NJjxO3Kmsx+(+hgH+?k$hq
z)ES8_sfhuVUH9;wI2vG>4E`IUDo^VRY@^JmoG<0`o!>wFX=K^*iz@m>{$`!0%2uKO
z9>!rZ+RFBYvO{F!otPcE=IRG5R_$c9$}TZZnz^Ej6(;`(9mLurNV?hpoAnC%rpKM*
zb{yWYLwd9G%;ml{nqiyGOnovB+$ctevZ)S9SLQ8J_a){?)0d_vL00C*bKegARBE0t
zJ=@SrLRu>4q&-DVTTIeD^4Tk~{H?uY11p!mD#i8VTkV9+uHh}$0`I-oJ-0YcoT6gj
zi@;<!l$5!AQ&t&~(l{`t<m_rsMnub5slf+gL%gFV$7p6A#{1gzc4IvXww%wNR@dOF
zS?3uj{~_8jL`Kf0!`o})wO7$@{Ah$qqtk7b;&=4#IKI9%`or}jrwYdu#NL!S{?Ijd
zXLZQ~>&AC@LH#bBKhvPf{MllU4;{Hv@;<NhY>tMah2)@L=RBXYYy9X<MNZm?Yk(K>
znT&#D{&M4~+Prg=4KB>TTeahpdwtRtjiFW<E{4qU-qI~dhZpaejFbeg6N=#pw^oL_
z&09=`1~1KCwtSS{NB$L(s$(Og&Q_sKj9%X!)+@8^*3l;-j9mP><gyp5>Y8dhv<AsL
zzFc;%VPRea-gBqd7gA6XP>?P$S3xI5LDiZ$a^|VrT6d;*^quDY@~xXD?V+fLba{8&
zd~)jIHw*Q(=D(cq^3kr!eYz`&KOlea$~%#X_XP@Z0@zG%cd+hRhscJSl1FXJb~|QB
zY?*S|PK`g{Zgg6Pl$wLHSq|Fg=<U|;oG@JcWzHS;eJ{U_-SaGTHcbkXi1+!Ve?b4$
z_H$OPc%O*g?x9g5_;uCp&Kjnl!@vISwBW#HcgxnWb}rT3vvS0YOC_-JFLQ}q*4UKg
z`WiKFRa6?NN7a{&)Dn9TFISvZz@Odt`n<w^C5jTK>+_|vi%TrFs!s?rF)Dm+!{$By
z>f+DE8$L=uHw`J8el!a&=gZF{>s!d5TvOCKYDDS~iTPW#q~oI|Y`VUF!N>^#p_lkH
zUg;;JJ(5nRKSZNYwIO}i?dRH8vIIYWOS=2u&e?sB)eYJP?XK<+hHuL*I$df_8zmE<
zuU_>n$H1n_)%=F9W0CJx#nf{RYii8>bG#7SL5pmcZ-7eH5o>uPtG9>71ZHVok-IFJ
z-gIimy|J~%Yl6P*l7%1ALXs|{{rYkbmioKJA67J-oo9Y7<bLXmhZklkIc2Rnu`;V1
z0Snq_JD(d|IL=#CaEGv0(EdyA)OOKro2q8Vjqs0pJ+5;01}_98SVwO+?Y_X}Q2t{F
zMRepIoqnaXn`yM@;rPk-6dnv2I(ByG99x_t^~rYQtn(|vLqEPNeP6cHp=kNU7snq-
z8wNc0I$d_=4aFyMo1!k#<^6x`oeNw}+5Z1`3Lz93G2xLALMTGWJ%o^ZRJtglR0!cg
zXb2f0<T_CZp)t7*BQ%7J7<Y{cA;g4?@PDt}^UO4kIrjPg=YP)p&aeII-Df|0uf6tK
z-@W$Qx3#{jR!!UUQ@20qbnv<EktgM1ZnZY+EO~Z0{KMn!gT~o7cgmNf@8$hI=-=`5
z=uvaueRpB|g#3r!M(w(tHgRF!j1v~Oe232-GISruR}R->w?%YPqw@pq=D(SE?|StS
z9o|e`-@1>}?H2tqXZP;8kbSySf2(wB207NKSNDFkSm&wZ`+80dU!?AB`R>J&Hgi*(
zRqIqEhV#grb55l@=D?(f2XjWvxORQ>_6AnH*EP+1w05J{+gV%7xXi6(KTJn?J11v3
zzL-}Je)|4vmr$FU^WP7P{(02C_t*QGwkWebCU5Mh#B1kB-wZk2s<*RVckAf%!q?;Y
z!Cl*yzivAx)XcO~t9w7MiXSOGT;E!f4$5{8c{_YU?1r=$Q=^e%pU>Xcrsm$w4y{Z!
zc3<_~xHh|*J})mxk#c^ce{Q9EowMZD75(i|&y12=j3~G1ty#CtJGQskZkahym-=8Q
z4R}<#&2CJ1AGda5`%s(hO}BhEX62}v{l1^k<K~6$rE*ROw(QoIq)pXCxNp*eOD?os
zxY(%l-pFpZ`u;q7+n&j}_1-PW8ozS$gt;5HNzxv9zp8ap-X7drW<qd<p?j`1_M3Mn
zw8Gl-Mo(f6)eiDMY+i4NB>gJq<I1ab(uu20H`(}{{oXS??pf)tXIHV@H^M5xyPi(9
z8W#5?>8c!Gru5zYCk>WWds@q<>q+->ulvq2zLtGy!x77d>;2pxbWWF~0y*4}FNc;t
zvUOZ!)v=ckjgE3${(8pZ(Oatiyzc6okhHfpS=gm<OOX%Lr1Yt^7pK@wu}NyS+r3*s
z#dZxc+FtnbS%aY^Ym7=+G#I<c*UP*4C7xTvX6?GRM?b3f1G`>r?xy#DR4cCW61Qum
z>zsIeMUs*}6Y*7<^fsx&p1QYRSbuT7>7^zePaQOWcCU8URu{{eJp(_Bis2gXD8fB+
z92XOQFSx+b-O#T2i2&zsD(y*#Tl%EosO*s)U0cU-5Av0qzPn?Co+j+sws+{Lnk(Z?
zXMb~h!i&K>QzCZkYW*&AO;F?sNm?hz*P+&oC%^s>@a6m-sjC~RqSB8465e3<m18Sk
zo(rDy@COURbe7Na=zR@Oyy>)bg=w{%7svM8>zLH)wVulP+2-+w-<E$gA!j4k)m9>X
zizZce&C{_zdAVnq3qe2C_kX&7Oym8f+YZ~~U)P{}i`T0tr*gQ^4qoe{_dW|=(5%<x
zj-`gQ)A3x^BD3Qf?>de8dhX31ZoqX=4mUTg^5X!D73F?>9lG@O!WFZJcgssYWIN_@
z(}rW#q#d!JBT19x`;FZA{s~8%4To)7{rT83b4rA!<fJZt-o~W%a(DZ;PrisH%<O?8
zeRVt!dxsn`{;p?}aZj_RJ+U@<fA`t`i_;Hvs{1G)tnV$#K_z1m?oGL~jwg4i&fREt
zqr~BxKR$4|HS(5=OV6iqs(^+KCk~uSJ2yFf4{A(*(%bBG*y3h}u_s)c|Fm>bs#o`A
zoxd29vwGivC;cb`m2E|QeX>5=^FyDm=TBU8xx3e)#lBwFZ&$Zo9_sz$z%nl{Cch5k
zeu&neD&75~6Q=f@({J?fleIR^8(wYkkv4-pZ7f@RO<tAu#QE804`@p#A72CgZXFH{
zs}n!3$zb1gO|5PkpKX^ETShmlU~B7!gQFVnl%zO$znQPsxpuDB$)oPgZ+njGQ>Ve=
z$7}RUJ?-(>Z~2b3Irq!Y#y^gHACY=vwfV|JJIh9fJu*@~ALO=q;;H3RR$7_%)tQ;%
z7`en*k}k{fNvXm6XKgfZlJ)4jnqwY}@%?dIfOq5B22bB?KmTy<8r>{ODoq`u(mfyl
z^QdtLjC@wDyi#y^_=q=ohn_CVT>E2I_N+;39WHonk|b+6T;Pv}j$vWl^nwQ5_uAa?
zCv~H)hNt3s%)NhgrIlWuThj#YH{@_n{9Bluxx6-UQ@J;f-EvEpAHQaI*9u*a{50i2
zT;#nPHWO%5Xe#!bZx&o{Q^^;%n~%&f3+l3ASqrN{>%X1q7W8%8V^!ie19x%XE8B0M
z*&fHk@trmX`Og0(V(lZRNq4K~nt14U+F1X{;iY<|X>^z`hs*AAD$uV}(70D!y6*Mp
zcSGmSnzSd=2R~FTnf$VP?037DO41xT+!(_LxlY5s7-ussdfaH!Wou?8x~VE<c{J<$
z>f3aahVyEXKDoRs-udcawYe|CvaOswdUUof7`W}yxahm<g1XhW%Sp(uK8)*|oL~LJ
zF%4WEyuWtZWMHLDdrgu8>L=D7ob;t(C#$Eawcl)_ZSDg(oY}roiLqryEwA6`^t}Qb
zyS`P{8{GcBoNM*f6B;#r@ANg-w#wWisB|}%ukhmhgK-``J3d*xGC0O~f>*wm-|fdE
zUbOwralv)bl2~c`*Vb};qfATmkB@IQ%jV0Jts_m^G?{vL<eS6O7F?OPYkK&Eg5FNt
z|H<uD9qNp_p<hCG!V`m9>wRrE6yyXR?QhY2Z>v(B9`1kZ|1JRkPwZQzJ7k{q{G)M3
zr_26Q>HM3l_b0b(8C|N5%l?fcmtDQQ;(36bBwdrwkG8*@ah}t;`+~!5@7EuZneDjm
zC-<(gRs*B#hBUjgciWhGj9t}P#P`@DeydmB$TwB38{AC(YEIkCgAvu@r|um%JFZ##
zS-Y2|D{pr@TF!644x@TfTjyZA<O^%9?k(DPqoCLAZ|mq9+qB&6eeXc6Wjy=I=f|hp
z`_7irSG!V;Z@#xJ^<vt^P8Fmr%Pc&awyp5iX55l;4eOiFy}lq$d3)c*a{5MOUW+`f
zc4?4YuVwnN@(pJguAO-yuHMjDXZGzdN<R0Xp7M6uO4|=BZO^T=ow3q(+Dh9a|18_3
zeq^7>GPc1nm0~a4@3`xdXSD@`H+45ZcJrd&MJqG&+t|fWZs$Hr|6PYNtK4+@w!E<C
zTBl)iW<R*n`j++NN2Q+4vRGYeZYsxD4tKIb<ry>c=gxlB#OYmdWZ%I-PL0jhht%m4
z-{xSw@R!-tyUudB(BMk9oto}@*xF#lkKgB)+_cHaZO!uJw@JYz?O%OyHRT*_m*sHp
z*F0H#_nU3A9==*#b9;qlhpi^*WKVCaj_Y6^-6v+bsXO;ga=15bc0O(1YlL*J?3kab
zmbh{J*e$PL%Nm~EmegYG%8NVlD1UWSqTFW;Ki;Zg*@V*`cdw?^Sa~=y%(LpK(#zT{
zde-yKwhY^HoRdo1^+!=>sdS?%mgwshd1%hb-gO6#USGA7^iJ*VZyOhSrNPkkNdfCz
zB<ZP~z8VkC*7{|4*14^rUar#<+^YIs$ewPxY;V73<2v-qsp6YW+i%Wcm2UT6RyM3;
z^z-I~=DU~dtUkMU;`|%aPmH?I|3TXJH4SF&%%wh%!$mbNr+zfuWc&l0g6vX`XU{%t
z(_`<NG~E~d^}jhj!(!zW#-@|QO`q^hX20)GG&#58*!?B<R~;<Sy}w6w=8Np`X`ve{
zJd5SIF<K7Swe+_=Ht4l7$gDa#ZT-c9x#xavI^}G5WTM}t?Tbq8@524*(<&l;S0AN&
z<eIm;V3yM&@-z1fJF5;Dy5peE`tq|}_m{Z$vMSfNQ*wOG2k%($!fr^JBfUpdeO&SF
z!X8~~bf|yqZSc&uKWE0pSK+=yIJQ&i9)Hn4_xU7g$ExZX$$QtD>Fpcdvmm#Ujb3j1
zkSg7BbE*3p%Hi6awrjRtXNU3TV|^Yk`em2F&WVfr<Q1$xKk0JSCe<taIvxLU+}o*i
zyE!^^?KCK}y657_KVN(?`TNa>r2)sLes(bMqFLCQo<aUxSLNsA2Vr+g&3fDJzTHnf
z6W2~$JG}2M-B*{#gt#@{l<=kXp5A$qRJMzVum9R}6H-?EIL)xv-1&Z9S1#YHG4*ld
zb-g@~=@>74JIJ5(ZIR=Puvy#q{TIER{o9}W;a!x+?bzA9-k(f8RrBnUC%H{#?5r(G
zr{!=yKZGrkcDAr+y2mTL;w<myU*B*$JGI_*FLS5ONxi!~p$>m0himy(??9_<=j|Pn
zo4nuu)jaF3ORVxQy;`UC&WHV$zQ{9wBT1(6bN8(~GwWB{f8R20fxUxu&;Z>FW3Sgv
z-PY!2LfrM!X5L*JaDOU?3sZ*~Uwb}ll50)Z`O_{YOfHdOGH22HO~EB=p4bwyX6|9G
z3v#$qW0E&}RBzrsarfFMy{=t2@oL0wyT*B|&6ZB~es^VfhmMl8R1T+q^Znc$^|MA*
zd|Dkm*LOvf`rU?~8|q)X6?$yUxik7-Uf?<{hns)QqwKfSQyxzVd7g4TA<yLHq1TT4
zyWN?5CeUeexeOl5q}%fIbitgh({FCv`tzKrWe-%YRd=G{)SSnbH}6zR*q{G;^XAsm
zB<VZ3{B_$u$mZ3v;J4#iHyazczFUQFN+cdO*xpO3_BOSQQ?p})vyq=y7rw0?l4iB<
zqFwmUFRR~4@bo#C=@!)g$)Yl2H@6zz+ul@?R>|R7FV4%aKegudAz7v)XSc|{aX+}L
z*@4B;Ya{zCTUEWT;{?i;{2cWt{lzNp(u*D@w7j(ZNzVwYQ{D%g)DHhC>8nu*{x@c%
zk&gs>QC=dB8Rx7T{%FC7z7_j;H)uZZtGV6*`RnI~$26U_Dqr_pj3oUihr87BO}nAT
zp447yU|jm>@C^eJ?C#mzUl4i6uFR#$Lteb$`nyIh_Y2Nvp8Bdy?_qc9c9<~wb)yP_
ziyqF)Z~n!(2bbog46izz`>;cDIc?IUe!t=Gx|!R&FjJY`-E|{ubHy?p=I^*OJ$cvZ
zhbqf&B<ZdkUzfw5e{FK#>Oi^7u6aGX+ss?1|LRiDWS0iB119TNDtNEvJ*<3R@+Npn
zWEs<l@qMl&olmN8q0f$s6T4SwS-R`GwYOfGdOm(nhA9gwT`T7bdq-@Wa%%IL=#o)Z
zw;d|X`?|+B(IvWDEQ;Txu70xy_jPhO+xH9i9|`?+?G$&*J>3i5w+ek2+hnkJ`rK*i
ziSecrqi;x3p1j`~OWU-tf3mE_(71KyPs9hMwtTZ@?%IKMUrl$ovhIgXZ#?Mx!ZVjj
z_n66$^m@{~yIV|ik2bbx@hE3ppOcmCOjb-^81Zg)v%E;|*W_^bU0iOP+Xvh{cOdo4
z@)>C>j<>5&`|X=l^KM65^>BI+Hovf6P6*l2ynB|!JL#kPg>B&cSS}_rR*U!4b<moq
zIm+#-#N|;<F_Qb^^hF!;`#IVe{S|GBRv<nr)DR_$>KZ7w#A@-*n>f^m2p0yiAj(lV
z%QL~S1mmGXFvLR+nCo)C4{0F!_~e3KNvcv90x^&QS&)5`b*1Q61`&`2d0<_d{XrU-
zl26f3$POGK3Pj$+$}kV{kPK4U!oEbYXcDAA2BbA2p~X|N1&S?DY=L466kDL!0{;;U
zaBJ`f|9>ieC)pH!Q+KH)NupzWWzbGlnK#k=E`f@6``W2A^ZJ_K<<Rn)`3h)7&HO*>
zN3ez)B=N0ZOuQ-<_ezpI_;Js26mp;d5;XTO689=D+?OOlCgef__a^$>hnRqh`;SnF
z00ZthoWT<UAQZwO3c|{9uVjEi3S@%Fn`l>1JQZ7@*aF2CD7HYc1&S?DY=L466kDL!
z0>u_6wm`83{u?a7qxAnn`~N@l|Htz2z8?O5g@XeAyZ!%Fmwg6$1O~eXiMIT%<J`x)
zkM<fz+x|iyfx<UnS;7qV9q;KsISBuK=0@G{(&y<O?CZ~WG2utBBW<+*d6+`qg4%uw
zS2Uk924K(1&<Cnn^ZiEGKw=dsDYS?m%Y}bI3-lwC+%G}&J+NYB1Rsv*H&AHgW}=^g
zkr7Q{{<yq(VV?whme+xz{sy&a8^SviF^P94pQCv~N!x}G)8^_Yr!83y{SW_sOWRRa
zeJpLMA1>FVEuG~>(<bt9g=OFIj-{_ofS<pI?|5&%uZzAFLs-sXVmZSBqN0z68r@?i
z+k&vJ69YI<UMv&+E^c64@qO!Ce!nivk8Gzd{4R{=kNqyR+o-UC*d|#|K0fj`j-S}Z
znQgu!%;b{4Z{z$Y+i3fD=wooD?WW8+^3F>4)89L1cNXD3-OfpAy8)%`^_6~?SK7`*
zX@8Loa(;COPJOR?xz_eWv8kJPns0sT?pXWv__;ktx0!db^SCy1_9^e*QJ=!0(lx8G
zHt=wQaUZ|c4bH}wTe4^KtIJ1^EjaRQ*s>9)YBw;*;T>Ra5zcP@^~H~F-1*#S%b_w|
zF5SLc;q1cG`fWQ5_j0aZb7r|yRh0LSQQA*MY5NhS?R}N@V^G@ux<2QvO83iWCU4cA
z*WVBCdAMR%|C13b1HbiH*{}U<kD*5|uGnl*AW7xAig3#tpQ#!CvVQNr54Rn3Xl*pE
z{EP(?1~~SczIO4|hTZgLZf5*R`FPa55VL;OmrHH#KieBIxoY(FJe{30B&S8|+YGk8
zw$f$`$5&~4nMrbd`G#&k%&4)(%{wi($7{=SuS;B=d8PNLBL$(lW@|m}9zL$T-IUUH
z63yiD5_9Ct;!^j<Olf#>w{x?OH}ARaKT&6-xue0!vZpU5NY_1-x06uX-c4!yhiKU@
z{)@I=_u1ID`;6J;N|yQI^JiTTOs{L3*?Upxnmy-ta&5Lnl9aaZQ`&w`X}=ex?Sq;O
z66GqlT>Xs|8)mkCsjBYz;|o*Ejol;f2PE|C^zhY{uh))S+fR9WGNtW#l(wr@+Mh*f
zJNHBKdGsb^`o(dt>h^Q`TCbINNchZ-C(^I)Ff6EBx@-Gs4?C4nGp?%~ZpY}o)!QyT
z_wAC3TM~~=ckU4W;KkIGxU=Pt_gZz}{N2Y(Bx$uAZnDF`Rc&{dkBUCOXm!la#>Rnf
zEatURUpAhbeeKjR%Q2qH`>81HSE95Xw9<B6e|0-(F-R}v%C2ofGvDFH15TLhKQMjz
zsQ<pX8E5rM?0f&F<GHmf8qq*!x!kVn)9uZb`X7#z>y1y>S9v`|`aa!1;h-Gf{a^E{
z{*r$C_S=55+MXS5o^$v5+;;ZiKb`r^bk9u76ypWT+d)5);~S+O(67hI&&Lef{jAK9
zmbJ_?tmC$%9s8oDQF_C%?bKQQ>7USDr0>(=s&R9y(jB=}ZTh6@?ulQmOdIrGe@f{&
z83or<FEzb?FxWlq*Osg2(ym&LFE7gbE0c*AdyaQ0@r%xt&!>hwciG?lm&^AaPH4Dy
zP?F_h<?Z5>_WM)XPFsg-ze;!h)Yx^k%x3kz<k2T&gjIjTi>DIGRtnA@XqokL{?_U#
zXXt;|O@!OGvy$iF+YawrL`<6R{;c`^z<iq(_p9k7W;FEMZ@gw8H=h&b{D#i5O=@3a
zzIo<b<F<EV>~9Sp<n&c$e$XKAhLf-FFd5A=fzo#02j%z{w)!%4RFzjPJHIpP9iK6C
z<AsSiKmO3ANlmHI!ewDUwx$u9kDNZ^46pc?C7!o-bRPI}W~G&b3i=PPw<E@C)y0=r
zJD+~zR9bm^P^In256JsH-_fh!Xy-)(oA@=Jqqpwsa@Ey&XJ$-G4Y<Cb!Go1KTOUb^
z`>7~xzp1oevC{s%O8bE*?ce)X_uEz4o?B^uT&4ZhmG+BO+Wuc@{}`qHSe5plRoZ@C
zX}<%d{b!Z7b646gOlf~yrS0a;?M1!z>HfI4<a+3S%h(A8GxFbkckafQb<&;;OL{fz
zUFB}Rdw2DGGxF~2aXkAv%kh1>Kd#b#B{SssKHYD(kAuj^!}|}6?hGyQr25OS_@T|}
zZg!~P*T(9}oAr%*lxbkJJAAV8{^d&h8!GK*rnH}Jf}Gz^w<A~DA6IEVTc!Rc6t_#4
zkH@F|QYdYg9xTT<(eug65%2Y%R(7=-V0?e|hBM&{rfij_J5Q|B>HFy;H&FhR_9s=^
z??tJf3#I)WmG&o9>c2v1e^;gcE0p$sQrhoXsh^7q@_q68LzkZ{@;>)e9rEn6eJL9!
zPTKrkoNny2m)Yw}j$S!T&He7Yp5i?JwEv1QIlk}iE**V${PYd?uDx{WwR~R4?QR{{
zZNIv)!u$@KzgjY@R-hzpmc!NhI(D9CO0}g?6GE46np<H-@aZ<y=d`=#Z<Dw6y|-2K
z8Or<HDD`upwEy-?IlrIwBcaqkgwp=oyX5`44hqQE53qSU@#vH?v+W->J$l#jsGIxc
z+3zQBZQ8PVXteTvLl@-u8gyGaq|(%hyXOB;!RM`AYWAB-L0vN+Y@PgNynEdf2L|wB
zR%!oZU-|jt*wCSmJQ^lGpWf(9Tc4n_7D0zEc}M!%uU$6&^|BkgkLfG-zo4}Lw$lDU
zO8cEE^$Vc1pY1YhaejPyd?2O$!Ik#&R@#4CX+Pk<dfX(X{V<jGvsLORM5(_CrG6Te
z`Uz3&|3iKcaxlM5>mRPP=v3?doBYf@YO~FT?hoBx^(b)4pX!|*5l5fIzq;R*(*BxC
z`}-^HkEYb`gVKJOf3<%SrG7`0_G4A*7eHzM%IA{YbyxdMR1)7xol1)Dt%bhg5iy>X
zT6{kpDEhgfgHaol?}Bo_x#1|)w=@D3@r8rtJEr`7Q^Z$+WuYJ@(T`4i^W^iX+6rxf
zwneGx)I(9xkIsZ|h_>jDD6SvWtN5Ns81-S)4%O3@r1t0@lv_#lVU$b1`U=Wx8@2eJ
z$}2MUQTA;~!ki%(A|VmdArFj4vR`lpKL~>uNQMl^0X<jl7r+V}zy*RK0%GA1WIzt+
zxlvz(9XLY(goEhg7lS52I^=-9J81)Za0VX;hXhE2JTM+b`XJ^<(haGQ114AK1L)0p
z{Df^Gi7>V-bA|{=pG;mP(oNrSYj6Y~2!$9p1Q}2O##2cLI6?qKLIR{g4(Lylq#Lc6
zhXOFPWxp^40w5fsAs!Av2IPQ#Yw`vz5Dc-TCk@h>&j*t>*a<u#0+JvL#IvLwctSWN
z!WGctz*~Ydgu(_$fgCVs$2Q;t;gBePx92xRfz*L?fau^E3#njePx`<IqTndxfJsM|
zgC9gfB4mPLCzgXJM8Q$W2IJ1`3;ZAkj=~Kn08_s2*nta#LJS;&8&CkIU0Dw<5DGDH
z2yTGHyEt=jfK<qY0&wElJs2V(1@gd{li&s?K!Ldb<=)I5+&~Q*;3#B5KA3Qgum?{F
zhgdiYIbh7mV+}(f6k;J2a=?%i$_kvo4<aA|QXv!c`cN*w0enDI3ek`VsgMZ;VA_{`
zfFt-pBqTuw<bb{t@qhz(LO3KqDr7+ch<>$0hLA?s07oGc^oNp0aD-rpfkTiDhQl~V
zzy;Kh1Xn;BPI_Pn1V9X=K^_>oaD2cSGTCR*e!Ls{lNR`}KW`{uV;~taAQucr5YII7
z1KGOR4owf`7)@uNAo{)J&ER;>B#nC553JSL4;6ib3z(0e^~XNKw!G{9u#a%&6OKbE
z&VAMu%)vg)+lH|}RNH6Rf#3S2i65N7aS1kf$~MfK&t-q86M6`BLq*@>0w~(QID_Rb
z+>eVs#<3v!8E1jsJo166P%8+zMVK;w?0alTUd333=Hx3DO@eH~rl1*MGM{b1zKM?H
z0>x9Y1&S?DY=L466kDL!0>u_6wm`83{+lgOg3P^tugReyZA-WX)~m!lJRIToUD#+U
zN$1dXxB!<xJ8fcJXXpyrDVF)okXs9%WT2hmSmtZQ{W-b~rodDPg&8ml!eBlu05K(?
zJ75<i!X6OQebVp%mhk&aSPt583s*9~3dEE{n8)xG#3b6BSLfxAXydb`rX+1QV;_+J
zIr*-^zL*#7z;>d$;27~ZLOki-20fTx18YG{eNf?Na}W%LfrJ?ZgF!oq<z3({)Pd*l
z0>os2HULX#3e7=G@6i&(p$DZjadl%^SLS<Ye)r^e888NC(lH2zfE6@{hR_Ja)B?4E
zR?u3rY$!Sbf;7K}qb@K4MuIzd!ZzZ+26sR^B`|Nty7nNZ(Wozs)%-4pEfYy+A~xI&
zqW!*@Ot8D?7qJ=JZ~ly90C6Dvq#E)Zd7SM#u$>|6jbIw<gjQtTdR`1}1nsni`K?8M
zCo;dc$nOKpAJP0ifu?Ha&!A^D^F@7ATwqy-X8Be0x@P_kdRH^AL;7?zc@*g|V7_9J
z->XP_MdLzW$J%thV%uLe+lytD2wz#VjWJrK$o5s(_A}5<Mg4D7XZhzv*41KOrTJZj
z_^TG#M+@d{G{1}b>}bWZ)|%yAQ3uU@AJj=R?~D%A%nwCfH1nfSFU`F0k5Sb3$4r)o
zY1S3>1LDWB@tWl#Pr=Mj*8DE&BV-}VA~ee*(N&sxaqft6FUp%Z_k{MLEQs@1lzUM|
z|CvvbkBv?0Mmjb?E);-1b)F9-Ll)$LT?yV5!4)vz9f~Pfg6IQcSc>-?;0eK?2Jy}#
z8g4)i6o7$vj{%lo2id%<u;l%O9XNn9ctRHMA<WD1js)x>9HJo}k|71s!OwvA7a)9;
zq(cF8DNj7$1|bj*v2X*jArHh0aZ@k{dvJkBxB^*_2U10jKSV=3BtbsdVq;NvIfF#m
zwg*25g>XoQTrlN&VGn)~3gY?^0|{V48Fd0T2mm$cS0iq40B4ARbjXApC;<KH*b8hS
z0%9N^RMgd>5CJie0OHyp>ThERg;cPj-mnKpaDfmAhbYJdW3Ek>;0DnU4@qFJB5sI*
zcnGe8LNcU4I^;lvIlmzTvLPP~>tbiH1t)NWFo=X0NPt6-0|j7Nk9Cj<2KBKc*jkWQ
zh=n8wXh3;|G`InY4G9mq;MR!kVFToWxh3TYlAr(#8nX`4Ars7-U~ljg+7x?0G^B%Y
zHfRO*AU>8PK_=uv0d%n@Eg*cpC&3jku%SGIBV@Pa*znHY3Va{~Ol%9^->0AktqBW`
z5MoDu;0Bnq$5s#u5zwUr^AG{5&Xf@dfpD<u!m$KDFzrhIApi>cvd)RLLufyaKU{%4
zXZAl3n}XqB;({R%0Y@PnqKBf833kINA8-`XL40!&-&zVF*^M&ejt#*DVjvZ+fc_}<
z4Nfq`1N%S<q<OL}7<jP_L_iG0LlPW?G`Ip;kP8K%@6EnI1(sk77NfD14+=gI25k%r
z?`2k@;<{Qq6<eU#0>u_6wm`83lvqHIKqDm`?%=p5Xyf7^<l;YSjEnm?&z9ESfnF}-
ze8-RV3LNj{=R$Y-AeV{!cL@sgaB&X^kY|GfeaDaf#}NQ0djtiH3LIP5{a+scPsfex
z>2KryRi<BeR)D_L+t(w|Kgi!ZSY^?_fvRsnu<tnEsl=%2>_0BR*Uu}EKH=s@uC9|j
zT-}4&*QklXUP1KLHaGI|@(b_^EV{I?-@bdWpCtP4i$4Bh?7$tyjJu^7J1|{G<dSy|
zAZ~dl!uM9(A8jZru}YKZ!v6Uttoz9HTOW88D+50lebNiN=ZmnSU%SO`%QYhr%FA_)
zvd}bk!lhl>S-3wrJU^ufuHD*rTz!LCu508;*i`7q`gBcr(HCC-xA2<y#Rg2;F$J~#
z&aFx)ACKU#ZZD^_9pO~&y;QnK{48Cj{rc*X&k4g<&sSGe>DlP}%pKT&&a?RWE>kWa
z-opKI8xbzCzuwDPy=zPhjcbrpqvMz9S(DA4jXJvfqS@=HZ&x_&;$BN>|3anx29>rq
zRNBukqlL&vyj|1vmF{mXxAkg@=UwT|G=o;v4!zu0vCRCI;enqYI9IRmeom!(ruqV}
zuR5-Xv@$=RoY<`K<CjNl3|$Oo*%rJE2z0RN{z7>_Fs1#mo>Pw8KyyCG=g9_smjQ00
z<%x<yEzTVt>%=31@YAUtgz}n3?Td2WsQpnM)6^4CP7!qw%Hx<?oNqNzio4v-K==<A
z-{#$#QP7L0Vha>opx6S%7AUqru?31PP;7x>3lv-6|GNcvO#H+5|BC$9en%h8O}uzM
z?!nEwc-H+_zq5&FVP5--J`$q;hQw=dDF8wt974G5_aOlxkPI0hzA1`*7Ei?%D7HYc
z1&S?DY=L466kDL!0>u_6wm`83iY-uVfnp2%brulc|404n-~T<mg2o2>%WVMo4(;pz
zk4*r4$NL7eO49`3-`)n`-#G?Apj1(AKVi)K3o#7<zK_ad0L-FIq&m2~XkUOeg8cow
zT>U2o2TTlh4fOI4@EY&xKHihr;J_(%c7E>TMtQoswru9nY?Q5g3tJB_PY-u%Pj4G<
zPY)aG=3Xs5JlwrndbU^5MpBF+Al|L~<78;Rn}x!czCAjV{rA=J7O!38_690cG#C*6
z^@Aq*$!!NJNUe?H3ezaHCnur}!BkD2taS;@)D!sDEBsza^N2IIFudY4w`rp|sGK);
z^N~p<x4#g16YU^o%Xtg-@#O=vXdA(+BWXSDWBcmZ`2}>E=<V$lh^53>+eSuwmzIQ|
zHP(&qGjZG~ufV?EoqgN`gPi>b2l@t!A?)RFDm1JxoL|5n0*YY4UgHTU>@!khpBozc
zi0#F9a+<bE;cV|TQ9kC1Gu@^Qr6JHg*gw#M9Q?E6`@0S72{*rp4a9MrQ@CHLUW>wX
z_R*x%O`PaVT|mszv{vprvY{}%tE;CNFT>A&vai3ZICXv9{d}i-x&E=tvW+Nr4(LZF
z`Phgw{Gdt00@5aIHAvI`=7uH>G*gz-KvM@vM;x?CvaSA*2Cwl!69Yfof02}Vve~D`
z(GdIYrrEa`<6KNMnU?om7ZrVH?EkRuV6Q-0Jc%(wKFs*1_9gP|S{Rq~o#q^BquIA#
zDY56mccG$Q;Lu15v5oo<`<^U{p?1HYw6kby<U~9L<e{&Qwz!M&<_pKrFk@X`osSlE
zxtzPP-i&mKZ9i7bSxx<=Z?uARY7WdF64<7VtE*r0f90$$EDOyg10!Abn`l5k8g0yl
z#qN(LclDuW^b^gcq&#pim89;yMEjXyziqv4e_Kb_*rw%f?|TPoEt4dr?XCW5zimqW
zpet=h^;fq;`)~2vc2zF-pZ2r%SNnHcNCl(PeRtELTuOuZVFxQU7<FvOnG<`SRXu+6
z^r%I9mN{-&(&VROd>4|#RoG~wdaMfh=6buw32EUC@71_e_4>tKb3R`@>DRkyU!_{n
zZ-Ea%oWCYR((6g{?rt&7J=)l&#iN{YeNI-kGg&cxVZ^)H&GI7YuPMi;e?RU~IfEI8
zf4uwa`qf@9>%EApyD!|S;jxg@qg!;gNRH;7M2_#ii_2|u`+%G04y1lrJ|k_#@pctz
zzkQQx-tB0s9!?L!=F?ZCrr2*cM~AMR24z<FTs-;bi!UaBzxl8<;Mmm94hCK{3tQ7O
zh(>El{lzu!C*r%eVL`^Jk+1zP{aWz8g}p;cntR1n6<Z%0S^8+3XT9AftfbzoCBpr<
zICz?S)Pt$3-+bG1+S^*yzS@^^C-<Pk_@5>XD*OG-My09TI*M>s&K35K*f!<V<}=YH
zqpWT_RG9a5k8h$&bhlU(ze!#FCg0%xYX5U*Wjntr_4Vy}7Y;wSe79)cjVTN3y8Lvw
zezi+KxGw2YWqIjgjlQFQqMYB?{u?_KOp1$78aJ@E?vAp_opwFGsM{_%I;j2g5m8q8
zt?1A4naD?#NpF)X?5TVEh4mNLn_g<t@zg={XZLDnZFRAn*)#C7s2JMa%E#@Q<G7gc
zd%*>c?uK^FPXsuBQ)y2^+|nlvM`e%f=-N7tWA=CVXQy;rC#CID&E#_M*Ny+Aw4Lj9
zLvh@Uz4qEhnDy^DIi}i;AIm&>Z{)k|hw75gz19{+vu^H*qYNk=PfF={O+EUE{Vx0Z
z>b3fDrJ^@I4Z3)7(+_heeBEV+!LiuuW^J!EE&tlzn(x!HT~^kpR=Qj3Gc7CkN-90+
zOw(DR1J0z62wvE~+mgZ6njcK#!9;00T&3e!DQ&O&SC4n4bo_~}vR&qwl=hzdX49ms
zsK>`wZ#!1&@S2mRn=X#sx9~>V4{kXRCja&Agum-7j@xbBCO<B36lP>Q*rNBm`z?o8
zi8wKH`7oD~>bo;moV-1J6a4|@a9JVllN$Ewx5+1F!Kx_>s?YFgF)%38Zte`{eu0V0
zPo(m+^ItPA77tfS#uZaKe%4<-E|z#H!MI%q`+a%CCc-o{eXXuTYxfift0Qk$ZaX^T
z*p?|*Hoe)pna43XAD<qNrZ#;yRl41OS=q3X(a)O`n(tn+v-<4biSutvKQZb;{|9N?
z*EE>9GnadJxqcZk&wBpRIHS{Lf2nl-P1gI9TegfYRmWxj#*xdeUS9D$fVh;7PbGXB
zs&tz)so!t-yKd$-FU(YCcX!<g+g!0shxt41Oi$i*`k~758%eq+hx_}E$E9?9w7>g!
zT&Lu6(0uTY1uyJ|lsVFSMAgR?-!AOYwMK{f$KD3deEV}|Tzr)|%Ezbj?<$UO>&1Eb
z^{3XnJ|xR@<m?vNH|_^_H9N34dTnH%Wvi;!b)2Al9IOA-xLuJpA|KH|w^F^%S#s-&
z{`RP6M#(Kkl-u;ytlQ=t+uLln%p9nD72g<gIMuo-Zx8M*Ga<Ob&^^~0`^~!(T48N^
zqbD(kY6tlrHm|pX>!56xQfIceajIPE?bWJdr1<v3_cw|Cah}~<Z;ye&HucZ1dVG@m
zN%?&H^f*?+_oqtt)8mTWmctdy**g8^#;rfknOgQh<yv(o8cxl5Y<crerG)+YuQzXQ
zJ&kut-9&sF%YEBz^xkdPY|D;S-=5oH{oxySCzqZcY`doI=%LT5-L0a0Jfwwkd~rWX
zqdKeNGb`Cfo{$!vF`IR)zFpk8;k$oW`Fj4_BU3iehD;9k>G6w{jyEKHpQ>~}J${zb
z@vbbpi}?P&<6S8ocd9clIaRu0>M-ML&u2|?t?4>{+Qo#)B{EFrELy)QxMa-}TSC^%
zJxqTdUV^H0pZK>hIdge!;-+$M9=qk1E<b+F?yeQO9{Fj?fw;(fHEcM4|7*r;;^neR
zx4->lkGNL@E`R2w>hNmf`D*JMJMBJDv&-vqj%`|vy*A@(N&2hDby7OM*IzyUlhSdW
zZpr2T)8qaWkN=ea@Y|?ex6>vr?3;1I;+F65*+Yiz6E8hQxjO!$f9~^1(vDTtGm`hN
zHPhQSyk|jfB^$lm_90ce<>pe?|EI=(QaWyuxxL88r^ktMmcxB|{3pfZkF^#1ou&V-
zLzz`>I(=JS*mJGZusO3ITxosFdh(-E&t_SyE;Tn5-(&KAKRr%Vy-p&&uBA6;rsUPA
z7GJ(f=Q$m!uZ^rf?f9fFpVtowJE+(8POr_9^miZsN$Ge<|J%liQaX-MWj?&Bbo*p|
zw&#aFUC*Dm=yG?jLyLXAtlzF~y*$+W$AM*DUQB)+$n%VRU);6yw>>uKwKB-8Iy!Cr
z#e%u#er`JDY<Og%-=*z~O78E%hs^)fI8lG~I7dpyol-iE>EC_asd;=9S1A}zO6hn=
zrt<yOtvfU8SK5EyGH!vrgLTjV-3w!{*G}Em=4L|N_0wkFU3p)kbet%q<0k#x$CDBt
z=T*9=#w2g{sNTGN;_kIidR@D4;?;=Vc8&8^n=PH}{qD-}4!jFfI{wphF0DgA(=J19
zuOa;2b1KSxRS<a`5b>=R*8^%5%B4iz9Oaaj$02ElGB1w{BHBjS^PAV1;#IypE{TeH
zO&bZh?SzP5hh?G-g_!zl!dWq|X)7S&lKaJrCI#joCO-YB%b>h6SBtg<MYq#@yO+P|
zi};If$9~i-l6c$_!%)cm@1LVip!wb|iSO`YJMjski&)O2(ri~775)6{pq0^jD4!rC
z3zT)@JGz=>A`UsfREgSe>GC&r5wF<4C5Wjh;l%G|D7VY<I4pHh9)0EQg&j2C!{t6h
zALhq_)s+atYhJbZem(%rEQ!x9j9PS@guly}5q~yb!@qkRiBK2(jlqZGL;Tq|HDYWU
zF;<Osd>UhZTf^UdoEkAcjdrY>;_+#yr>LO*H;+%_Mum|CSHO}=!vQ=Y6rv#GCH@-W
z-!YDj7(Yfk9?OSgu@oJL#adlh9~Yn>j=!QEdnJ_0IE#8O`zG~kDf&(_X30Mrdqs@9
zBF0<^W{|6Yb<7o?Ti8lp`iJpWgzwTn8*{~kKBH1u>SRzd?n*T2&x0XNb)*=`0Anj1
zsSEf(@l<SqVha>opx6Tce=JafXp8#)KQDG;SlBN2JK8UaHnPXj6-M~nhJ1dDHmC7C
zSco>PDXg20&H&LCS+so??Xn|a5iEu!P{6jLZT4+cw8M7b!9ldMo(rNqc_b_a(Oz8*
z%V0T(_NUrOq~#d<`vMg{^QN$F8iW=JGnM%-K(synmarmS+Bij9{39$AZQPHdb$O5w
z?WBwPD;N7J>i=B){xcuwN`0Fb^^N{#e$I>fw*Nc&wg1qkz3_AY&-~g8yZv2!+xOs}
zsV9i37wV{)-$fpZ`n~_qr@bgk!q>d;GcU@UQvVm+G6_F;vd=tEG!kMU0g@pFu0S>z
zaElWQiEs$6fbc<|3k6`p32F`Y;0Qy&69OO<gpc|JNCn|PBNK8!pO*ngVF(Z1VqCv?
zNQNB92R-f~9btpGmjo5}l2%{`ZV&)r5D76556O@Pc_4h-TYxR(ffJbyg$VHE-Y*7H
z;R+a(BmLk6Cgo8O{_3OQ3h42o!5F$gC`3S1MQi|~E)ruhnDRoy60A8Mo)8QvkOz97
z@vH;MkP2B<d4IwIZ~`|ltwvrU1j50EdsMAIc?0~K*nuN#fON<NH&gNq$>7L~58+cj
z0@8uT`SSP_5_O0*bb(MvfE$nlmMY?a2#A3!UZfbB6BeAo4Z<K9w7%n`>fs|4r22#f
z2S|c^(6=b`2cLtQQjc1~5MHh%z#+(Q%<*eN-oOvcn=%i6AYQguz!2~OLu>L3j!*#h
zHrNVobYPu5WdU3|l7C1BpDyehl0em!b>Igf5aoc)K|E(!_awiN45^R-VjR#M5MzPr
z^&);S1q(27BwxKz7y`l2isLQnX)z9pxGuCt#Wh8=nG*HCI7daF5#c9B{1#(Ki0e@C
zRBVA_3lv+R*aF2CD7HYc1&S@8%mR7@8}_gF|JV5cmpg9$W8Z(dr)Xi%|2C4Hk&YYp
z&HpCf|4RD(7mg_)`a6#srS;xlmN5ec`;PbYpB%*40Om&B{3nk0bPx9RA741GK*vr!
zc&+{CVMLrAI$DJ^Yt_7^ZHtyx!us0r2ij=*V2kHAF?|o*#!FwrGjTt@v7DsC_yckW
z;8FBH4xHjT-rvvPV{Bm`=OKjq$kcH+3(HDvjJWltAFqzw=RbsbF@7F>{(ZzYqMxuD
z)#u}BU!75Mr+Bek^p_7u_sL-km%9eh<(p+<8<7F=eB4*ZKS<jZS1h+>`4iIoq5pvB
z!aPW}JTHm9(3>>Bwf+QpYHXmdPXtT@%FEx@rPk;#!Umg)*uc|&;wT&?1P8j05Avfo
zwkKW^f_(pA6AKLXkCWkVHZf$q)+P?je`pgYmVL}7Ls<SXn+Tr+Zmjboe|>cV7+vCb
z8y1bn)oZ+1CEG9_72`_M$J*b+y|6E{uwf$0KW5v0EZ-#C+&9Q|Vz9TcwFsY$erR)X
z{GwT2m{x7qX^#LFv5l^g@T-|rn&(6VNqSRgTRAQV){C*(7;nOVVxWhYcD#uU-W4Pg
zzBJ)K|4Kd<a(I36Tu;vPxKXZ};v>=&Mm%QFS4R|E{30+fY@|lTJ3iu<3sVJ_^=FwF
zQ?##+haAS4-#r`3+j=l7@5cuX2IBK@ofzaLj41M<r^j<J>FUBehu)fWiM-qY7QQfD
z+HJ(TWY!fPZ_T>j%C)Xh4DqRnYYzFfjQu^I!f?NB<0of_$9yBBkl&UEdX00(Gs5`M
zuA`=iQAi5YC*G%+5Z^}Z^t4EP`K<rYZo)pPEZ5jSIFNa<>?pdzM7CKlrCrXqT}htn
z!JT#5c!e#8@Vn4XzLM~7AZ#SUig!3&Sm(64Fi#?^%b$cbCcOh$7gZ#z-v?o}af|$g
z623b5TfU_*ZeimMgdba3q*=CxYp}noyQgQNO-u<N0wRBJHQR{vxbeGa+QmM!`w_>b
z3&;5;`$>xX{kVj(&Bu;QB+Co;?>@=h*Uw$l7e$YYcz0z?e6fUkqlr)0`U<~4w0}Cw
zirQbBCJ~1{afq_{fWa6^8g-kI5!w9He2DTI$~KV%zPR=Ge29%dEDzfKh;0(shAvCe
z*qw#jh_nh@iFe(cH^P*%t+X~1b!?30yw0>NtaFd=DBM<C2cOma7Im-)ze*FgcKuhH
z-`YA_>np^sjMy9RsYtUqYLC94jy}3aj=%6a^^bM*#PPl!{+?dHRnxK$3sGJ_GW}Lh
zi~2~^)1poZVZLZxDz+14O^tr6P8RE|SXXqLqV=yW>prYE#ra~OPn|*@ue07@@9*}u
z;CEr!2=EZcT!hUfY!|{N@VliZtSAF2ert}+Z^uR0*jE!qYxAu|ev4zLwXs84B4DbB
zZMg(WWzkpII3THrjRU<VO!UQ1kLw4<=B`9*<v;fWB>lk;P~kaLcuye8mIM3z@LE=z
zWxrj2Ja7i1xoC;-q8t>~_v1Lmh2?3?*M+uwO}a(i+G~Bya19YtBd$T#s1YjebJ7dL
z7nYx3uaMwBUe@LE5^XGR`r*Id%8Q!y+Ut5U^F{L|%Ft1k6)g`UB2i9KS^j5b$cZpT
zw<%hN+*tRqYqcmJA1hmq99KK?@6Pdb-&bfKkuG8Hk6m{i%kd7K@Er(0qe%EJg#YmR
zD&i4kTD+U*p2C~Uu{`>dST4@9wUvKgE^b3azU^6lTfQC_hUd~YI+(<ZW2$D|uN)Um
zTyl92B|X-p$CGu5n)HbBF3vOUHC$T<2^D3&_cw+4)YdD5HNUm>N+)f(s6Zr4-8ALG
zQd2G>8RVAi7bzFq{4{Gxjjp{5F1!!^Pm~Q|*TQkWH226w?(aky_*mHx<w-N9SCM-x
zBclM8f2_=SVsATaGYliN-~Y!l^JisX!bi%0+i&|VJl5JWAj;A|D+6ynC<AILBwNxW
z(i^NvkG2eatj@DI@W<odT=QFd{I&Ih9pz9=Pc+A0e6JGqLcqa~9Dm#255B15#QFP?
z>9=|zk@eboA)EOR>xEpF6+OpAT;lx5XZfGi3nKr2cI?Ah_pxIy%FD-&eI(02dhD^Y
zK6ZJ{u{S?dXh(71=}h>-V^(;7#U1`6uRtD!ST5GP{kC2{SH!KktM=R$^??)j69w{d
z6%P_(bzy!(*sd^rzi+24C!&rjELXp;6Qj$C_%^Watv0@9E#(Ns^)Zxhbe@KV<Jt|<
zq+gU3d%_njE84Jn<aGz@1|2TUt2hR~*L8(?)jm;(ZG4DZj63}$;-}e0q(_{4AD$Z`
zE@7WSyLn6u4D=cwta+#v+o)MrSOzrf`2AsBW~SMP_WHe7^IKcD9WJuI@S0~RmufNA
zy_l+i9#E{L_t;DIt(;H!agGx0>hCQcYkmE+_o||76Z9ifp`SNlOMTY*62EwU68qGS
zXE>x%;bwynG20JxtR=}_vroA~WtrHAIPM>re)FfNX61+Hj40!x-A2*(2I9IQ%5vd3
zQ}|#dmRYgPgm0tTXJe7hmKy(OF_l@#w2Wsi(L8V=T9R}o7ELF<-SECP-rY}A*UMXc
z_|IOG-jYU*j>~p6ckI)wwFo8BumSxr5AiJfSRN8t{$U=HSyuF(NR%0SmIXu6_Z^~K
zx?pfm^7Sk0Y9B2u%OX74(u8;I8WIrbI*AMkTWGh5W}7OU>z^O{eH*(!*`~03Rg_Cs
zlre#rcoZkL!g3~lXO^xYuAQ!h7f-DX&Aolcn~OstAA5O5{P@FUIJ-H&D@i4dUKGY5
zY}rZ#5z8L@zD)kQTGYOMio9FW+P6=UcS|Cy*1ml-?*YUzt$q7w-k%h;Z=WLmD2tXI
z!_Nv6ok6CXFna(MWydO|@VqL__aE;Q#JD0KnL0LOp?F{B!+PztLOiE^SZ1PG_F<V3
zb;|~pf9zTz@)pm!56ezI`}?rY7x9SWVa|aR@912`eQ@C|^>6oUnmP*al-f5gh0h}5
z{^tr6Ob*-o7v^8Cn;rQb41IO}vCN5W46xxV)~`G9dzo|olWm0U^H`Tk8wcM$)L+H^
z_6q)Q{q5}@DD0Qqed4m{c6A>2d2QFeV0&_%WfQ+PIWT0kSBph^)+F9A<Ba>O{ql)8
zRl19JzB*WK?u)Q&D`$@$ovjN7Zo4!t`tG`*ZuRYQ67s7Lqm6~F2sdS{Sv~d2$kJbg
z?XTwCcvi&yj*&kYl`~qu?7O(*;f+Sz<z1~D&g67|z0U?OopY#VOxeW)hZ<jZnK-%h
z@MS}*b~t&c>(GI2y!Vj9J<nVkX4?K;Q<ItZbvL{im3Ghh^z3^P)-9tG$Df?JW&^eL
ze~Vu}rT+G|bFQm&AFlnrO%(&j$vck?I@7Lu{XrM}zv*#*N8{<!Z+Qd{zxaaV@hfd&
zRJvDQt&>h%ZMw<E=j`{M;c?GOe?7a3<-QSC3EuT|s@1T#CrL{E0WNeB@%?rF`;_{N
z`>Xx@DfK`1clQUV%l(l`cU9ZbHlKfazw+*}Ey}rimnyJ0T<uI;zql!<=N~=w)#=E#
zRK6WWxPQMtz+(S>$zRQBn|UyzTKv?#182uIYd>rEvUI*xv=GN*c9UCc?~R#eYnPsI
zPVZb*og9a(wGI03pJTSRS@~IYba@UklaJf~eE)sLe)(L7^lg8y;`4Ju4pnc}JD^H+
zlcX&?SSt0)cS*i)n&4S=#kKv09Y!Zjzfk|`nwza!R&*crYlO%7W%Jt~*gkU<?M*w2
za-}<P>U-VGwYDFMP2IfHeCtzp$J(#Q&+R$7&Af}9$F-TWPm=yqe*T*Cj6?r+&k=XO
zJKk#a(sqMKht%2sP0nbmd2ebZw+Vi|JA3Of>t(df<N;oZ-@6jMML4_p*B3v!ap!ZR
zEr-f<xpez(g|iD!>$mMN+{?Ls&6(v+aer%18(o#||02JEh9bXTJ~Mf%_PqXnc+bNX
zyZWDuSQ+@O$I5=~XL}4idU3^OivrrZb`{~4H$GD{{AK;#eIIT+=+N3|T=^LbCJb=w
zH+}8ms|~y9&D_j)Qu%n)y%4j0)t5_c?mycbF}Z5=^*o)OGbE=)>)Q;rzP8e43*~A{
zI}u-m&DzHAzv%7k-~QYW@1i_z$IkBc{$%Q@nrD|h$!#)YXKk)Wayj_>`VFiwNaUl6
zYu|63hC2*w{PVoiCIxGfU(c#i?d9b&V~!r!QF+YkY8UyQD%<7Legh*1i1_^8p1=B2
zj+>5SpBeL)HlKLTF5#NA=uqpaRjqs{)f=-J`!$ox^WWFMpi+N|e|P_aUVX*!SiL;1
z(~qsAyp3M!G`B5#I{)r3p(om#v>35}cSw)3T_^69q*Hbx+^78zuA-g0690n#DZhd4
za(V9As>Qu^=NF%TH&nGMdyIq8(u<8-Z0o4McW3Ph-fO2GJfYklpi)17z2y33$LPJ)
z+b%u#?UIUH5|2%H?hyXq#nhCzv*nNXT6N(3-N#Glw;-qQ_WnnwF4aF?e!{bo<8IFV
zxx@Zuw+FZF*s0g<>#H5QPJ8qt?^U`9JAc|A;A(lllN|=GYP-99RP^~pt7CRHHV%Aa
zF|U>Svhm#PYo~@;j^X+nX(QtMv_D0qegl>IT~zA-P^sTVrGE1x<@)8*epr?I(>W-|
z_i4X|kK}Np)C2nUIQjXQLA#%oInuJ0d4_e|mb7DE)HF(OIJTWSt3Pdpx{KrS>2THL
z`=P(D|HEc-{bJic_<T}S{gcP~bvp5751kIJ->e;dG1tTH$HDG{=cnXQ?k}2%{C?Wc
zUoE-Z@7r0)bMS44_bnnO&3Av+{C;4*&5HZgbP_Wf`t3JfGmw{dO8qX*mD6{%XQpS{
zo6S_!o4&1TJ?pbhE8mZOQe$z=?8DQoJ9+B)oR=h}{s5Kw%T(&`QK?_e|8;&L<>$c#
zCx6^_;N9>xBZvI*RY0Kq)qU3%#g+~^v~=+4hz;lUkLmH<U%n43*KL<q#KX+AOD_j3
z_D-lWv+)s+)}=$vL~TtlY3=3XoFqx3<?Gw@3EyP)`~F0eb1RPBUvhud!2;d;dsJt>
z$PS+ty0OBuSmOJoy(p(6+|&03^~s%MX;sQW%1-~hL!}?qny2nQTzYTL&)+m$#!G0$
ze)Qz)rCv#!-K*W|^>MwovR3GByKl{pRNek$+k&&Tv-*yh{%#Q;<BI(_{?GK|sKYat
zN_YO$*mbqcX7#@0(I;etRe!^arxMCm3eFyAne}r1*6Jx|_-0`*!hPD0qf)=0&T@R8
z_V;MWJF&mgkE2q*mH#dN9{;!baa8Kx^1sE8qf)<%&Mn1xWT4-z!=Yhy;^#FP?7Ob1
z)lK8G?UG{4=w=mcZQXEiRO6j|qo=Q~N;htOz*m;@*Pj|3=11R$uvz{04j5R&;c4kX
zRc&iWMDDsONhjp<(&J>E`1;REeA`cF^~RUqblH(H=dAZ*^N<n`+KxChX6kL;9dwrC
zi{97p#G6h_SD04Id2wvdy^cw(UhAoxpKTt0_-*+|6LL06(l|NX?89jxhqqU0->_p`
zLt8i1=PkDF%NnPe5Oq3tS-rez4Y&_e>Zenwf5yMs59VL($MNs(pHZoQOQn7smHMsx
zSNuKlDNNhXM(%&(RPv904}(icY74?lM8&u95Y!8uf_{lkLu1ex=-22>^f?+pTNX{<
z6}eA~h<7Z@Jy|ZMX>>PegNCC1=yWs!oq?`GXQG^PlA1prnWfq2BQy*xr$Zljv?>~j
zTA)i&E0i>;+o4ftBDx$sh^|B{mcX|HD%#zyMom%DuJ%CJqC3%b=n-^1dK-;J-=bU4
z_M|-ywMS{+p&p5DLuaGg(J+)Wt2d#E=#S`b^eW1081-Y6+g0^j6kDl9`}S{819U&y
z5j}|dpodX4dIX(|eur*AkE4&#6x0x#o<v8Wr%+dvK2+)u^fbC2O+#Z*9)r|}(RB0*
zdI5ceW}xrUOQ=C9NxF<yMz5fsqt{R;^aeT^y@f78Z=+G@&*)V&3oStJp&e*rcOUJD
zK0t?|57AlZV{{(+1U-&YR@6Q9X-AJPLtmoX(R{Qt?aO~fEztsW0QwFcg3>fzJq^`G
z7onxlT`2u>)R$5Ghp2x>%cI$-5o%GESGH&v`WYI9QijwA(Q4>nv<7+`t%a5<$Gsg|
z8Et?LMJ-Vev@yB>rOc^m`X)6;Popi+XJ~u$GXp+ZqV>?uXm8X39gg-yz0h9hGPF0k
z0qujPp#9Ku=m7LNItVRMUXli*mC&JRRdhHi`ii-r;=H5WY5OC{{S?G`SD9t8ASO@3
znWJM-8`K|lL<7)CXdpTdorrR7NR!bxl(s|at>`qAvMhz7=g?UwWkm`@AE5KlU(oqz
z1<tz#s0q3dHA5Gn_0c7$JsOFMbccYZjlbOXU!<FCOMW1xejInQDGf%eqeIc!s0+$E
zX#_e19fdANJ<y}57s|OJjY0L;AMvRvBcctjTJ$ZLfQtQ#JZReC%kA^U{!Lhx24Y%8
zI<3*ws5iO>RikUsrRaK;b6?tmat=$|&{T9gnu+c}OR&FPsPJvG8>I|Nd(cMc*Ju}X
zAKDE~Mn|C3U21G89Y&X;M^Ltrj-lV7piV<m(8uUW^f{V}ihAyQ@tggNG-%qB%k9iX
z{;IKz^Ix8RAe_kGMO5T3168A!QIWqZD0QQB6&3l+L`6QcP?68OXcl@OEyMmFpq0@_
zXiYQ+ZH+!fMgN&xlrk*kp_DDr&R4w&eS;>T`1nzuMc<=0Q5p-XiCZdx>XR=$v^-i0
z7479qqavS%gweE{mfKT{eAZ&QIQC+~C$5}NY@_z&cO`TVYK(G?kUm3W(W+<?S_eIb
z)<;Eow?OZq4bgJM$-dR1-C}dp3bjFdp)JwgXlryd+5z2;_CUq)>xF)cI->W`!Km<S
zG!zwndxxPabOhQPbwybwxuINZC9YZO#i%E`3>}T`K<VG8-h+-oMLY7bsIZF_XxiM$
zZE@qNdv#f64q|E|&JVOHYK#(I-p-bJO}kmfE2bYE_7vePK}@{}R|$1QYofhTaX$7z
z#eO3})1Fms=PI_Z$g(gHlh}_qpPQi*(B|k^?9c*LlYZ(bbp+ZHjY3<aX=q#YF=~ez
zk&$+2KeRnM0PToQL%X8$(e9{dU+aL1bXkC=ji}sqRHTdO<atEuL^v)R^7bOU8)?$C
zt&~KYOA)>S%SBlhQy6x}hSEG#*eo3FfRc9k{N`AxsiUQ(=y;T4ruJfo(da64HTpHW
z7X1$0f?h`B&==@d)RgomprI(oT0H~hSgTK?Y^y$x?nBFPfRa%w^dLG1J%om%-=f#i
zqv%caIBG>+PNL1x@6oyFIdmC%0bPrd7IhqY1x-b-qR-H4=r8C^v@~|fM2*n9Xn*uR
zItYD)PDgXljVQ-XEqrG^Lq*%w=cu^P_;>q(rXKr)pX@*LPyNsQMQ1nCk({{z1w$kx
zLOKY4(ON&z!hf{Zcl6)gXSCK|be1>g$rH*r6#I^*u4za83gM6lc2qV#5Csw^y9<bu
zJ{D5J&|Z@4!3Uz?DCB@iN0x&hL_#8Df?+3?gC|76QOE}4&g={PAO?=Y4JZK9F02C=
z2!$9p1UH}nOuMokgm1D?h=D_pXr?3GKp6;LG6x3;d&xGGW%GRY&wMN#0<BNzRKkcc
zzzV>L3N;uaAqDcln9B9v;Wzs4;>$ja^CBL?b+GX?jvHj_Qs<-Tp<FYjb1wqnJWmLJ
z*3MioQfAVJOph`FM~~5`P+jPUQ26yPU_O2p_eRVMKZFjTs;wiXvk%)U96Np|e#h}Z
zi~76HWW8P~jvrzEna^we((DhMLF@ZkddhbEHlIt}s1te!bwkt80!W%eInw8v4|b5j
zIu}&y2RoMeqmTu9^T;czLaiW^Jcit&UJs*8aY2oTWcZjbY(q;ODG6Jt&}_ENZ-l-0
zodG8Ei4VH4&Ie*30}LALNY>y2VUPeRkOlfpI55Riu?31PP;7x>3lv+R*aF2CD7HYc
z1r%7I1YwH$|1Zq~t&jgPru6xTcc7i#i}@OSmw*x=`ZOIe<UI&%WZgM59WKBn&`z6J
z*BQEs?KM*@^P3^J7Vk$uJH@d~^miBjx3|F*m<pjV17<-O%!dUarUY~c?1Dtt17f;Q
z8XmwBet!weLHH#QJ`h$izY4^Z!|%uN6vQO_w&{_#l28gn+s@Lc=;N!8e#h@JXjwSM
zGDnCf&D)>{^J`!&h^Y_iK=?s06b2Gz5DW(GB$ju9w@?S3!wV3T1=;{Cp(!*6F}+7i
z5Qp%oP)ZY5H<oo}zK7;_PkxsH;ltjUbd=_WqdsV-K`a{rR?r+8LL(4U3)BW$L2J#j
zq38q%()=Edy1)n+3GUzt+t}YVxC7cLfq6UDwFfbcMtxzd=65-4X#nM+DKvu?U<0<$
z2HHY9=m5gr9mPD_8SMhyzyW%K@Y~)8`hu7$pcTOoszG)59894G)P!1~g4(c!c+Jq;
zXdToX>OwuJ4-KFZGzKvlp_O1J`I!xKAsiOMVps}MumYlCH3+{EG3Ywj0Aeb-U1j1k
zhAQwGR0ZK@K}@17>hUo{^oL(wv(OHr-@53dE*vijUl7Y!z5*U|%tc>x?No<t%{BWI
z%Y<(q(eFH*m(-D<$1`>rcw$U@LU_rx!avnw;@U*~`OFKyPfy`F2p^6StP?&_#Que^
zBjN8%*iQKRTV_(|V@>Q!_-zwD%fvV$wFpxi%!;H%#e7Q;J~xCPjy&QP{>K&(e=aI~
z#w=l8_&XB*iz1m9ep-Ydo2ASPzbC?1$wKBIlJ-X+ylfbfpX0=7$Z{j7$nWw{7D_<{
zFaY1G)Ol<#{C9jwxN$t6j|V4Vch-loek{NJAeQ}>VA(vDJ!L=dArC~^*$-kr(>~)^
z5at5QOYmEl`J!Wj2%8iggGA}LA`2^HXAn~)x=J%&bSx1uPRIX*@kIXFSR(()aYP=q
z;N0PuJq0mYQht1}^Ej9dr6}j6p$wD-G0kWBY7o-|bRtaA{I1LPLnsGBVHnisw*`o)
z3EC9864pTzzUcTQ&MX_KSw0kX(aeuRy)^S5j$tCME8?0U&M8s<iu8!<lb9D{n~3X}
zxHgD-Tj}^F2BekKS#pC!5Z@xj_aRRR0KS>a?+T;PM92qQ?ko6KB#CcZ8$jayp%aL2
zJP{!Lk6Q3PFaTm92~t4#pA_Hl(m}kV6TbUQz#Oa~7{Wk|QzzcfB|!>gfSUJd+V^Ui
z%;!J>gpz?nkOo&k#RqpQum>?Vi3|9E7?;EmT)+pS;0EMCKIrj*PX*Rs2SdOU)DQvj
zkOKK&kBuF{1%ywdWDtIhg!dp*aDxqy0EfVbvJ?*)kOjG*;@Ay=Fo=f?$bvl3qbwPN
znq!&_sUUoXWJ3V;`36XYLy!ly)LRbV44x1GQ6TPP0zh1g#C_Bu5Z6m_O%!9G#ELqQ
zb3xRhDzE}E21+<Yi+eZ~aX=EJKssbX0T|Tg*nuZRLn35>sTt=L*g^^z)*%|Og#5Z_
zJ?sk(;0Y;^4mThh^y(8Htic`}!3TmN5@H}8QXmtYEU3F792|I89S_Nn0-5005Ich>
z1V9AD!y!n849JB7FyR_t4p!g@K9C6oU}8!Bz^O6E7yKX`vLO$|$7lmE0c&sqPY@qi
zBOo4<ARU66vR}x8Tqpp2EA|bx;0yt9s0H@0rYwL8Y{3CMApk-l9AY2=j=~Kvw_(4K
z45^R@wk_E&h;h2a_*^lN45^R_xuDmI^n(T1LI8w91jIl-7}}B+Z~_<bfnW%ONZ0^3
zz<`h5reFcK&;>%E0Ib@u9fUv_Y=A^K3h9su#%<XaY{3P5AOto*0vv)&$OXxcG=ViZ
zzz_(9aEOL@xB@w#-;S_g4Nl+#!4L-VkPNAi3##@+4Nl+&;gAehAO}<(hzIP!3EUtO
zQXmWRz{H-goe9^4^$-A-U5N{#Asr06u^(`RP)LFlNb8Ob9Iye{_h4I4Lpq3os0|?)
zQb0RCPeCu@awK060@l4LFChA#ZGhlDocE9f=6xw^;0ei)4fzn_#Ib;M@a#uj0<n+{
zCjChhm<%Aj-~v&Q0(qe4%&~?Lh=n957|b?92n&7?2`P{VdP7OqFl-9hpc+njgLKG*
zP#3~N9_Wpr?700O_Ra*Zrmg?~CnqYBBDdj&BcU>7NJ^-X5QPv$<4MunNl9rY6j2nF
zl2Q?xBosvmNhxy(X;KkMZpHtz_GvQr-242d=YRIAcb{|i*?SG&wf403THl4T0>Plr
z2<2&vJc2o(m3%hAXYjxbHd=@6feNSs!sf^`C;_4tNE1kNz;B=#@Ujpe$OeT#!V&og
z86X!l1MZF359k9+pyPyk12RA^&~`?-f_RVtazP;|1(}-=hYR8cQeX<O-Hi1hA5?8Y
zobIR}fZG%02sD8QNCUaR-x~@_fSfPt5l92Mpb(UTD$odMTX7r$Q6L4#yDep)0d#;N
zumsM)d>f7%KPZR?xqwHA{hS~JCHLvGq2xY#Li_hg?J58z&kUoW<lg?hAp3cRJcE<x
znX&ELHMW08$~X(h0vro)EWoh<#{wJ+a4f*F0LKCx3vevJu>i*c91HwS3!r(Ow)St&
z|Hqy^@B0Y=vEJ6$egk_7KpL3?kY<RshW0rCdw0$SxX8l9-p0YkjKz>%D#OsSWm#BR
zxL}Gc#%voaTMJ93J&nwv7e17Xi(&gg_vd0~lyrF=f{zkV;&ff*CGl;oVrFD%X>4S&
zVG)yMZexnyf8qPS(;qmJM)?Epm?NNbekh~_KT$rm(X`P%e+y<}VA<PP;ydyCEe9q2
z6foae=X_q$o$E|k_SleY$G|!?4`DkK%q+;F)~Vn-X+PHDvNE#8XX1Oi!?(X64_06y
z^ADjZgssSDb~)w4yWPO-{N+(we)o^^l`lZ!C%e;Z>)5`(JHE?(^S!Z_{X6mf{^>RK
z8UEm>%9DM`x{9uKNCkUcao0Mu;IP+acdeV$vF=3Ix``d@4tA|0CZyun*11j|Exzn^
zc3tbHb*$6tTBp#lZf@7QsU7Pkbgk>mhgjFT&V10j)^+BiuBO8V@}2p(-?gqYA30s?
zI`a`&-LdbK&hRX|)^&!b(Y3BKJgKgAo#D|s*G=xU%fqUUI3{=6C8cX!r(Je-t?RUl
zY1g_=yUgfX*J+nOy4H2(<4t8}yq)>T>sr^DkHcN-I`iSuxo%QtK9+T@>&(aYijFuY
zb*5!w*SgNMm~^e{OpA8cy3VxB=vvpA7TL~q9rH)@782=N*O?Zsu63O@ef_E<eG@xv
zdbev`r%f+*t?SH3Lf5*^d<1o^>&%B+*SgMptm|4w<%68B3Q^gAbiR7fxxVXsMdlvx
z!20{L)cMMaX=KkdosDS*u#U_rV-97{EoEeBvCbO5b)M>|^Ho&mzAj9A8*+TI&wuRj
zSWGKh_Bvf`Hv-_CXl`M~qQX|ecSmX+X8Ewf9H%TB`(;e_Jc}eBN%*ZRoJB?s8`$Sv
zy!vRL=f&89HJdthQt@hchG*5eEu%9G2V{+!!i}1DBM{dJew<G;@cX#V^Bj8~6BgDX
zox~Q@`L|>K16psi{fpw=0{#4{`T2U@N~3+X7w0@N^5_-);@tDRO>e}XEb+>ncqkd|
z?mhKe(u8*|40=kxoDp_Hd^-ee-Ga_r(Y6b1-TY7?T+Au(<%kCgn{3aZPYmA2FzDfi
znI+qN-c%R7E?mjXT`v7J`mXpQ=O?x&3QxX5_nhl^2cSf@OIpg^<hf|bX4g2Gv>~c{
z3(K7(8;rA)izPn=U)-;K%B1IhT7*$>47yX<Mpc2d6=QAs>+6JT@(JqtzS_U<8u#1N
z9w*}uJCxvE4|6uzu1-2Wf!VmWMP!Q1lOOxd_M)~MK5)pH>(lyt*j%h8Ksy>FZ8BlH
zK%2bP?tZePrF<Xnh{J0s90@(~uiaBWj8;^58Y7HLd3(|A>iLI7T1<;-t+mfyDm^b%
zp^sY4**2TcsH+R8{61+uopa8&Hq0?={)1<4CS@1Vhs6fJ8(7g0otrFRohpoeannfp
zem_q_5Ebu}wC0$!xYYhy4XYGYKkVIPXt^={q3&x<x!P-`Q9~k84@;=+;*}>v4y;V*
zm+&yx^cAgTGrxjZW>fkAzHL+e?EgGhFskSNrsZ*VVbF&rM8A}^c^7(O6SoonH9_ec
z3CZ?~2UmtC^c~p$Px0D;=x;)8cg$LxG5AvMthZKQ9_=1<q<1WD@b2r0dp*yM+%VEp
zW_Bdr?@;ycb>W8tW;_8kiBs?Ht6$(Rcg^hl_~Cxf(~cM?+LUg|$8pma2PcERG@`&R
zcmMs(f(w1OSu!8os~F-^H}23v(;P10J#8y&1kqoQI*xd*2+2RH$}$erp{0E+nr;5N
z`1GHJ%g@O#%yrUfJyy61^;v_2*HpOI$HPl9VjZJJT~}$J-m0CfM#%+QF_Txcv3y6}
z#r@I*yvt<J@7nJfyu89xq=uEw^Du71n+lc4EgQBqTynkjT0LccILfW3evx|W?<kB)
z-;Ud5*N!MHTK!_=EW34|#t7I4)NE~@w7sDEu6M4Uh@LfGp;5<q)y~m>2tP}^;c?s6
z(dCPpp6X^9-@y^~?-uS`_+opCK_mLiQsK?X`t!7CrQErGWpf)B%#+`Gi1*{&1sVD>
zUbarW16#j%{QKwM2%_r2)x`myY<jyt&E#ffZPc$<dhYge!I)v!i$Yd841ZTtJ`er+
zP{yHveQ%BK3OJ9J0Te0CACScZf8;*g6N<|U%?nB{lzz~q(CttsD7L5k5A1?w;rnjr
z4QL>g)TJco1854A8*!vU`$5y7qR`V&G6!usl-%>5gOc<Wa(CVnQ}@UueIZy+`VNr=
zVS5NcZ$TxYg;1O}X~j@fBjOjr!xVZCY6*P|#VLvM|B?ZHhVLZ3&!Gj-7f|d=`GF~i
zzQXrvXeIP7XchDev<51Ow7iBAzX^5FQP6rQhMv;iLY1KnP*v!A=u#-Eg$I0}Q2t@e
zp&#*mJ@gY4K1nD)F>cUSeBT9agOckT;`BHSrNNKH5oj-H8kG2rfv*i(Z|F5>A1Hif
zQ2t{cL6Jre_^P1%#<W4<%YyPd0iPWngL>il1WNod!1k2?g(1)we21?KY8*fDA9D`h
zF?`eGCKSVMJxZY?pwFQrp&0W{L*6~;bo6(F@<L^xVo+JAEEG2Jm;l9aM#}FH>Kf(e
zU;=an)=z}4gHD1vLnlMspz_dN(5cW!r~)(wst7#|Rf1lHPKVxv&VZIeiQgLHr)U=R
z9Ta8YK}VfYg9<~59~&{~T&OHm9XcI452^y44_yLX05yg#gqlJZK^>usp<AI^P(SDr
z=m99o*y9*<88i{P9GV4P0WE+Mzc-{#uYx{<>O-GH*FdYG#?U4x`r3JXhBBe#UIlf;
zLmX-c9SLPYCqo^fYEa_eW;N6qx&i6}wTHSw{h{vA5U3~gB-9&9{2y$Ca`j>Rw;2fC
ziSHuN0H`z+b<krR6m`&JCUg&UHZ%yT14SP|k5$n9(Dl#|s15W0)B}1D>I)5r?uSM|
z!=RDSL}(N=85#|}1U&-1291S2fF6ZDg2qE%LldBN(Bsh0&_pN=*W8m(A?PXSAZRjF
z3Yr2P1;w%Ap#VJ%RfL{_l6l9opv13JF4PKo73vPngYJRegp#?N^P$(Ex1dj<h0yoV
zA}ALx+g}VXv>M+BLTjNTq4iK%=zHi`=m#h+m$W35tuE|O);ae@Kaz=DG*MK3&cd+(
z#{wJ+a4f*F0LKCx3vevJu>i*c91CzPz_GyJu>hK8z8e3JSMAhTVDe5$5bcEI-TEP{
zG!e(MEE@QD2chi@+KfguG7d`Y4}f*|@R_{7=~yDLPsbR3@{apgV++HuEqTXJ7JfjU
zf2F}Rpb0RHgYu8-3iSu!AQ5DOd|->mVze`mXL91dmH1jEFVkuKfcU<KFH_nSpaL|3
zGTM8_;`v$`xPnk1B*@Myce^44&cd+(#{wJ+a4f*F0LKCx3vevJu>i*c91CzPz_Gx8
zj0N!M`;Yqnn_Ad>-~HcU9g}73Xx85SpX&e5Wk~wo45EqC%58Z&_4ob%2hya33=B4!
z7#Oiw_7=vDET#kcbV>=CGc9eI_TAT_ZwuBNu`Ce>*~i45W#GUvVlfS@jI52;F|C;B
zc28~Nz%qqfZYiOa7S^UVP7X8yd{#%-Qd1+Ag$?>|k#JNo=iRTj(G)r%Ok8RZ4?gUE
zQAE+tg2o56haMgce+iZR=#oP-Ffd}L2lg_+7zG;>k}%lF44JUD!S@a9zWnASknb0&
zFF)zOYm47bOOSpgwvNV@7ADA|J=4gF8lxbG-|DH~+E?OxM}Jo0KkpGz%Aikwe^bYM
z_PiZg(<?`>DXY><e{M84Ms9hqvhKtesmIoDg-@u#WIOe<E95^mu-dE?CvLEhR2MkY
zD=CZr_(GakTOObG#2omZ=xIMtNmUZwv@bi)UU2;@Vw2I>lzFXR6kKa!#;-Ih^xf>?
z7%$-%T8h47v&nY9?=N~|2HDR1j!yvX<YegyDNMfso@Vb(mm1!38TFVcr5&5LXih!y
z`h|)&WQZ7#y5h~LgBGUoY`i(a({<U+!Zoa&OVxL;6q|HDADzI?%_QM%%Q5MD(Ji-b
zlk>aW$BB)iO_`rG&#J$0x@oWN)UQMhwj_RH81&$A{XAZ~iCS07w^sGhymhNaX?|*0
zKK;W|-ZPiCNQZ1fUmq&oLOa3AkD&+aKi1!OGtkwVSux;Ufo`U_!Xn$j;-YCsP0_c7
z$}fGn%NP2+VaGFL@?uX)CA=}x9RA7LcfmTPt;Msgl)Ta5ErANpTa?GlsU>=2d2rq3
zgU51)Wrbaph%VlczOyv{j$v&zI@yh$L((TXB*H!`QFyWCL77|e{dT9se!Q2Rv*SX;
z>Yz2(hRg8RqE5i43xlq_?eVVHr7!*zI-1Eh=kBvt0=IVF;GI58kEt_ysC&O_r~@iu
zWV>=_qm8l)mqeR~?>Mk&hxiur$;%zelzq48EU{18cO_2-{_Uvrg;{60pGloiS+ha8
z(#CaEU9g##gp^T>ovq8I7r~Z1`aSP2x<!G+>pF`W8JgO_+A(qAJ=H$CGq_BHCYPy(
znT;5uWt!Sd<`xS;p)lz2Wlb~*=Y>iSKc{ILJ=~ys#lbAs!Fz0cO3j)wU8gi0Fyp3@
z?Ih9)U54+<Ro*0@HZj>qy>-A0nUd*6dmCg{^&VoJ8?X}gL)#yNzPCZN&BOHZ7rg~p
z1LoRX^$)SXXcDqyrkBa8?Be~g(ycUFzqw?)edBHp^=lfvNUP@9c@0G&tNvSd*e%ms
z;uf*%p{zQ$do22bQROkRC_M7O-aYb_4XOT4BB75PxlV4OX$M3qt(@{GME)qs_b64L
z{pBOZec8T9$7W{1ozKB0&tkk5ez}@=ZRoAt^>4>-IXRq0+en4?`}yF9Q}uM-`w-cI
zLN8+zCnfJbDeko>X<Mn=72~3%)%nN6WZX}_Mf)ig-uUsOm*{;~my-V=$&h??s?;ZT
z0N<=_CtkQ^oVroN7<&eN@2L6`e&Ob>J{9XX$zDy?nW*}t!tm^s5o@J1`LFi9QJhG7
zY=ZOBWMY>V)}}x{34iOw57KU@2^1|pQS3Nx@Km0;ha#SSlrXJBM@60KWII>Zz-QVM
z(rXm?_us$X+&em2$S`bQMq3)Ix5~%u4|CDkvXKgJ%O0i4D)m8=SH&H=eI?!@Z)!`J
zZ^ZJEAKf$_9J&+Tf_QIflkh(FIsI&FQP#V$p98j*ZrV9g|9RGEvAcH+cF!NYk7xCm
zOK9h%@@o^2@YwvY*1RoV{d)7=`Lki}Ik%D1$`%Fi3|+8I&0ykD%=L#3q73@zz{P=l
z(^%mHV~Q$OPu(>Y+p#iwo>b10V#{JVNvUU}&?k+`M~l+QH<K2wp%wI9|6HV3>E)cK
z%)j~y-Z+*vc|%C?iN+xGo2BYYV)NzY)-0v!`E@JmPpRpqc-@YlRD5=-+`8mdM^+{m
z9fWJiB_!TYHiu`mZj6ghvsyl!exh%N+Nru?`izWFhnerz1j`YBT6?JT74MTTzO^0=
zV+NZmoG;MYAMEit>ZL62qo=Mp>kDr3?kz$eMbv5ZTQ6BP`s~cx+57Ad#vL$SWqu-m
zeoEx2_xl5Ux17zTPw~f`id21>wDQD`56ZfH7Z$A%sT<I?bN<{RvqtB%vE18Umc_*n
z_C}w*StLBgU5(A7U4}l^Etgp9HMy#^k~LTI+^*1wz{Noa#7An{p{-q!Y-fL8P}9dp
zo!enqB{Np_xyP8fg4g2a`&K>-k>hSOoRA2ggYsm%p$?iuMvbf#i_vkh)-rYR3-DMp
z_Vb5&CEvV>VroOe8*pt!o*DG&A#U}HByafankX1^#bDC&Jpp;lc|o(cudh9rzN~%;
zj$Ja}3+kV<Td~#0kxR5sb1RrR`?;%LDSUiFuyrKQ+?kte)c8EmSCiWA#JW`R>3a$;
z?jCS7DaTD`mS6P;m)y8p{Vy*(aPIc2I&@GzNNwk&vHZaF<o>~-w*wA_pByJ_-y*$L
z!Q-B=Z`Gq~tH-W4Mc+p%AE7T57@ul)KYhS^Jh(w9WAd7Q(QT6Iu_ulz9Uoh^oc<7f
z4XN!Ihc>mHPvx^?39L$aG|qDC3s-@N!ZG#XnZq4yvZO|x==pevo{n=MBLEq6h2BP^
z%uXld1gkD_zrQxd-QrWENR7Ej_(UrSDSvy5h3M-{<+s&4!R^W6gqPkfea{UVHqueh
zrM7PDlNSRM&o+OGja9^TpZGFn&~>*?*_ItAbffS4fwx=Azg#_fbX}hj`ezTX4SINQ
z|2tdMDbi7#L4T_}J#nIip763OQoPj?Z(c7=_bs`_-7Eb|i)ul{{xRd=yB2XX=(|pS
zJTK<^!KX@2$7KHODXq(o-L(pRb;v<|v~q1?v-oQCDW%Q_zaL*g{FX83zduhl;@Z#X
z!F<T)sqiZQY7}{2`0QER63^+k^rUKEJ@%cU;`jXK9}+3<V{?Uf^n6^$Ybrcrk7Y~d
zU;T6aisS~q3sZ+ll}w2{nxC_Ms8FHoh8Z5^=seFekEHMS+lehE+pXQ>AyF@q?06(3
zf5jKxO+4Nut&j8WPN+Q3GRpsJ>Oo)hIi|vE3^qF=>R7zMTEEwOt_Od*IKR_BJMaCy
ziW)oF)D>xCci}yr3JLG-)Rq~ma_Wcg;TPt~){9z}s9Ygmxg+p}GT&V%-488=crQm?
ze;4+jo-?iHc);~1Di@RaK75Y3dFRHdz4w$foBHl5Z4tn^^iRA)WYBMl?_eHL-5)3?
zbvq+z;<&n|3-W^cf}Yb_n{4eh<mY`r-+QXQ2s2Zs`AaTc;1n)adY`ZUi;zXo9dVj@
zg`%{O=aZDUB^V#2PQpt+InZ?FGmS5k{WoqiYM4}M-z>ksQj9C9MAq`GaM*H9^nIrC
z>*_fzZDy}+Qe|zz(_e(EJk?vFeWa|}VTGBj)8iAO>+qhlr{iblQ+5tI{qWJ~xIUrL
zZybt?qwo0Iou0FWKPTp~<n%`q`hT)PUe8nU?o`;DXFT}h)Y+ef7R8siA1-pNy?<xU
z_@T5hJA-`gE8<*gPUS<mgc;w|>z$&e&hjSrfgvkem+Fl=5iWP2xar~S8!g&A=!;IB
z?|nRcgde^0+-NY=VB6;6M5kUQqTT_K(X8G>uN-v_^Udn{_@15G#D1TjX!OgKiC=ww
zpp0>j?#(MH4I-DbZx{!p1Zf`KJ^pzP?u)7P-Bx9`X3q{-KHhSiH}|2_{lq;QZ*JL~
zXZv`EOm#?Y!fQO^Q0M!4o5`X#??og<_iL#$e9P0{IxKmvz}ySZH=T<MtQaDX>w-LW
z{n*(i?wl`|Uaai*vPt|!qN#a7nW4kd`T)KSu?l*NR3z}Om`b0(VR=R!!}-kP8Fh*I
zezFxq?utAvKIQ%Au8n`a%0H4PhwC|IXJ&q(#pfyVVsW*7Li10pwxRnqoD%J~FU-p>
za7?Ij(gBRUpu*#=jC<XWe@oW=SARtwWHycZ5H~X2Pg^#}`Nq1*v!ydaF~)(q56g<>
zDbgCR(rd;P&9k#_KHTxnsw&2P`T&DOi$#o)cH+1mO+p=H&?};Llw4c;$>#1~tzRaq
zXyoP_4LC4BF=s7Lwo=0)L%R@+rJ(L3V*3kxxLs{!vOu-|U<fN**pAuEw0u^#=EL+$
znmZm7zto0Qyt`R1bhaA?AMsmk;n*gXI)9q_5*22n+bFYV%Wl=o&8We9cj`WS$JP7C
z&VANXTC4m1h^@WK!}Lc1F+9$hdsg1?kGjp9!wnz#RCxW=Pci*#%JT0vE!$<5IM{vM
z1rtRc=bOO^iK2>3bDcD}I;5`qZgywNmR!FwzF>b&<?hM@=UeHODU6%jtNb>*9u{bb
zL3r<}`nSfYFx_GCTko-QeKcrQg@4W(cqc+CFFA`Rwf5y1*&vjM1M<S4*WW$s(2}hB
zwy1Pg=DX?wtGtg}r1Sq69{!N8`J8U+@q4%|Q1yVjw|w$J!%>S3Dnf?2CM#c*x*&4A
z{@9LN!^^eSxP1<ggq^ATtE&QowzxO@dVL(P{h1Z0wbDU*oMfc)h{f?r=STT9Rh`6G
z56aHQ61|qj$4~T>-<zATR#a)c%d535S(|q}*m}y%&#rY5>cBbbd^K$7wA(Jn>($P`
zqhF}+7yeXHayHF$PS%~ec`K~sb<~<MmV!!O!foCQK0Jr_3#v-pJ@G<r7i00f;*n!+
z$=>NdV7P+M3}g6&9!&E4@O7cdTd5gElC_fq|1c^#DY9(UiSt~M{XGrN_Nr(SDM$Z(
zDj#3M>UX_5bIh~m<H4cF1%k5VHgZ+DP4|eKB^A0je4m67=A@+JtzN2nW1X?@=SxM$
z?V4*Y2A_JC@3>Q|<cjoD3q3F0Rd`+?lY27gmp?3h`)(uc!~yY=jMNB8?sUBct#1d)
zbHAPGJXrnhTa*P4bzI(#e`#!WPRRT~$b;5<dTUx5Gv5T1Mcgm1^4u7qQN)Z!`BL%D
zPnHf%8*_WvtL7HRipSz>X0^CPDlXQ3HhD>z*P;bGVLMqWUZoq#6C=4!2*>6ut_yg7
zivOhJuEmY5k+(PA6B#cq@Ru9>MpD<0_2)L$oUb+B^5}8waT&QqhbA<>jyTM0^Gx8=
z_Z_CPnhRsBsN=VCYK&d$mgdiw3QG5m$gf|W_Hp&+LFyK%rxvuVedT3^I<G^87yhyO
z`SsKKuJS{-eOVp)(m4Ig<0TT4`HqJ-ZZJ-IRDkpeQg-&_{XC2BfFYOG)S{F}YOB4y
zsvjsmo#OPmPlKoQ!9KouI6kQG4zziGQdiafU}19k{HbI6K27&_m6T9ZsCaoGel4vg
z61H1R<+rA?TIj{9UiIQlKJlw2j*Qh1uvC((Z;2c?pHD_8+0O}Mn-DjHK9?u9EVprp
zSbYD%v%P1DM+A=Ee0k%XKSw+JoadhYVqq-C9tn}{&aO*zS>U~7o!-@9hqvm9?Yf|}
z(o}w|BGc(We!Wh^AJrHmLY13jdY_~iKI46($K0rBl~>jp9LfLedOrj4gLY#ke9=CQ
zGJ8nfPnOXxRo2S{iM<(SKKH6o!6z+G;YU?>qb`h<jkGkXo?VE(GE{#3bA)RT=)K;t
zMr*)gGnq+SkNBF|Hb?sUg-`H2&`d7~$CxrIJl(yk`d>(}3KZFJFLPb6=Dtr`cC9-q
z^77Eb7U%pn`SSi4OG6#!ubO+kla47r^(cimcu}?TLZw%QOJ5I*8@Jo=5zmM#bq{(z
z?z5-kDtkIUw5Q`LSycHtn$|b1`NI2Vkb&GX;mU(iH~n^ON}##vIF3-e?zT1x^=}Y5
zA~EQT%l}BZvv}_9E5-V+QZ**0FPzeLP;sBD+5P2wO~o0X>~TG!&Zl#EF3ykQR^Tra
zS(hJK-0EBKa>Axtet}7rcaI13K0AlE=i^tsr;>Qr3s%3?*4u6+Zxw2_P9iAGJ;{(U
zu-s&#*2jy5qOx0uVVn?kADdTtP%0$zWZyua*FubUD-2^DukG6uA}686<({h<xLc>^
z<6(8Ec=>tNXJxJ)5x;f(N{d4i<emuMnvoX6M=x(pP?TL6JPzmGo{pQnLLHYTS4YH;
zZs>J!3D?2HO=squDDl2!Rww1$t9tsH%=IqMa33~%0m*M@y6lw}wLSYK#A-j}q*SP;
zDSYB)=rqJyXSMZzZC87^=i}`KD7!>v-m4EVD|qAK-0(+w?qSD`v6tfLF`JvJB73h3
zS?z)Q_MVQ{^`XMM^lHz#SJrM(6_1+q7w+5Y{7hZ-(D8?d1-8wKJ+j+#80tYRwcW7O
zF<VV@#r6c-x$cSf71+<Zp(O4-<B^SgW5O3Rxk+2lH;uZkK7HXndf?g0v2i<8G^RK#
zqZe&>JUs81(v!rv$2TO+=F0Tk4?zO;oa~!FsLob;f4}>mT=#t1x!+4qy)h$m+WNW)
zvg^b0FR0)-{@?9~V4yH5x0ZglG_Rgw6qL>=?UnW9ezpG7wNLf+7rcpM*viT}E_cD$
zJF0vQR@gT4+RDFi%-+Q3rSf`0_N%ekhDP_izBnaJm^#T7_hC%RF4xv)#F~gtnwgXw
zQNQp}(Up&Dl9k6b9+ceUWcK-i-YguKMO1h)>U(qtx;UQNc1OUxO*yZsWuU{{vg!n<
zz41mPubf+UiAK9k)#r4{6wR!7wZje;+ur*}yw=|MO8l*;39s7W(HFAzaPwHBy_kCb
z?Q`?ElJ=lJZ4X7()8c39ogE)@f2(qvnaOgN{OH>U>aL<+<6@HEoK>q{o5&`;a~pGW
zy1BzGX@{)4W`Pze5kc0Uf=ZKfaGcMg?w=3$yQsb{_1L3neK&YK^PLr$RjPb-&yAJS
z!ltiV)gbl?_Yf!lB;idgwfhnm;W*P({`iEWm)3_EyDz!EW&V?*>$HB_=Z+>Lyq#2d
zanEVSvl;Pa1E&REq3ygW>6tTHIj%r2`A*2EZEY7eMWHVyb-tqIvCeuPmKtCF`qI$#
z)$1+pAG0+Z=f(e~<@oIy-!MAvOL{uae;0LswWjP*;0+IbnT%0W3v>F*ZV`-dFNzzr
z%JXLW389RF>QQL-rs`k7#z6*+Tq;-ZE#ND1cs|<Z&Dr(i&hkuOonkYRf8OLzxF26f
zg=c$0XcTR_4of+sC_=6xAicD8;j@b)=)&?-lg%p54MV$GPsgdlAqecZ_xzH*rSkp~
zu7weF4Mn3|4Y><#A;+?}<Q(1fAi5<1*WbHTx!IYD?0<AtaMrpsx1!Mx!=5Ni9bjbq
zm%qvFplvhH9d|dzeYPkGZ>frtN!-U}_x@lqW_@(LEfzUWJNewuIiCtNl@vBS+H#sb
zXARmJBw3@Pdw+N~X>F~f!<?v~$#N?qFS-~yoQ|twB%N7)3Vmg%`d2mQn!Tl(gVo15
zb5l*0lybcY%ddA^S;N@v)Fd8rDR~dVqwM$lc95R>qgY1O1JN5xx&K(X$2)Usc;8*i
zR|!AXcXZ;>3tA;I>uToQRm%<02bS9IUD+NViJ6}#h`LwOqdpktSLodEs_>sOH8jck
zs(V-z?n&NI=kX!cw}!n>E-y%MWg5688j4sHRk=w7r7mf(nzf{MutgQx;i&Tcy<d{^
zRJ)IJo1R@vRDQUG(Ao{}ywa71rp9V0h#sDI;F6WnsR{3Jzj1`J->VG{ZxU0ErLHm_
z8WJzzb>^Afhm|LD{ZE`y{9G31fMbE?glBKGH^nbayr3hvI{M(B8~D6?x#rg9?R%#r
zI((mzN?ZN*7;F<QMz%YX&+5H%+Rj}<JgI@|Pqkip9ZPX~JL>a}a_f*-JKw{{FxH+*
z--C~bXjdLih?Y0Mb=}l2u7T&Y*Wj_~YvdBmMsbM^k*>gf7`5H`W+lZt4<@S(`_j@}
zmf|59D`-?>^l^TxcC(9Fm46(b$)wRHf%Ar_E+((o`s%2}+w5`jlV8_bExtNPS#-bK
zPXEtd6B`53{zq+BsjvS`O2zg`!MVJ>{Y&!qU!EZ_ysafqN<CX)zIL_GHXOf0NqFj-
z8gtcFl!=?}a(Y?(!RdNz7HwIM%OB_MizR)+7C6}8xre%+<jo3~(XamU=!WR>fzhd=
zX||)2hObQ9E2t*-CU1BPY0IYJoXVif=?J8*IkxFq?9I^L!E(<u1h$@@e<rloJn4Y=
zXb<rxLuj-(s=kzcI%F_gOwDBElZy+i7LSnGRTswF=gs^&%Y7#zYAgGD!M6eR96Gg)
z`<%kD+bWtF<G-9evUSSoUI%P=4ss1YS+iu%heoLujJ^JY#5;InTbe-1$Y&p>Y=1oA
z?s(N}=cO7dhL<Pkk9A*Q|3@(HPaP?{G-z6d`&F=7HH`$7Ctb1CIWsUNF>X)2tZ~&^
zRRhI1*yIqk-K=3->i@c9yLa3Cyo0ig;QY(){bZ6K<b*U8u)J&Tkg_22IiOwH=S3gS
zwi%Vm&le;`I7aAcouYrdx8B)sTy)~zDJhE@*?urkEFJH1sdv0@dt?46tn&e6!L7Xq
z9~7q|4^#&lE{Ptip(0RoC{FPnm!T5S5-5`C@e+#LHxEQXV?djrQqbO9@S6Y~1I1~T
z@)LpE01qR4mxYpd%VVIteGm`Eg=b1}(Q3iiHF#D6ED#8iKp|)Z!fTOVpaU#{4+sYt
zpaj$cZUdwb$N>$Y4_Lq-#DGjt0%`%bA<_(#fex?*ejuNYaG`0S5Yz%*BlNciDnJLA
z13!=m@<AgI#(9^_$q;@Y=>~bA7KlE8uMIPVhu@~*vkveFg-&eSOKie^Kogh)R}c;|
zK?!ID!Y+s(XaZXh2oga)s0F;6F$aPIK7&?3<|~l~y1*9rflv?+GC>Kb1-y#L6VL}N
z5JO{+M<~SSW+18r`v6nm57Iz6AkV4Fz!dm_B=7)m<N0AM&;evFk|>Z1$Q&g6Gq4XJ
zbC39eB=UVGzJp*un}u`$4-f<LfS?M}2h2e*$Og4QR2A!iB?tsbpbQAAVLdPf!5|w{
z0pZz*3s{11kPS*fE0CCj-+(@F1>qnQl!8_uF&DoBec%ehK_(~#G<DQ>paJqg8E6IC
zXcu6CK#&U>fv^Vbjsv6_l;Zxn6)<rBrveOt2Z#dMpbRtvQ5=XWz!dm_7?2HWfiOA#
zfi7?bF(41r0ztIT%K>d*3H(7K$OC178}|{?Km(Wq4-g8HKprRqtw2HxaR5zV2?9YH
zAU?Ee0k1Z~0UE#*_<=-_2g*S!@Z&-nb&*C81+qaI;9Z3@0!_dI;UE)K0m0QcR)9Vr
zC!sVz=1QUIAw57B*n)774;q1>KFSH`fHK4>*b8%_02Xi^!9@!MF(3ovgEG(v_;KEm
z26KQRa0P)N21G4I9zZ<8s0C7VlocTJvxI{TPy*fp!8M3~GwcBTK^pFh3th3j8`26I
zw;*je3Ff*ZZ``m&Gi;HA{CFVW_)Pp|wBmETC&I&L?%uE~c!1x+p-Gnz7u0nSYzwV=
zf^GVsTo6yIH`e3xG#|tbEeDN21K+3c;5-AQd=Umz8=46<gyuuZoMdU(Ujp~%#8-zh
zD8X;$PjL+4b2cak+*=VQlmR7ks+1w^&e$d#=?UgTx<Lj&rz4smDCcMU{g6UlV(>i;
zRAIm7F|YwXmjKai2n&qGHGs2lEWoh<#{wJ+a4f*F0LKCx3vevZ6AR$B{HyW*q|G5s
z0)7P1py3EQmKRtTJeu97U3M6|4|*}ym4Lh8cXJ|>aDFu}@`@pNE&(0OeT4Y{JOpPz
zDIopHo<N_1XP^u`2QNW6cm*l|nLoD@S_P^>4R{S|K^-7{<jL|DjWoM(|GftUk^6A4
z59|jaAQXfFGS7GvI09lo95@CN!6}de(!m*U7G!~o;1b9M*8rL4{W|mp$Ojz@39|&h
zG4UJ{CxSfV^LuC=v=`DRk36sKwmq5Ww-4x;ul-LnIEmr=6>L8Xq#|$0;3%*HHlSlk
zz~}P_Zzl)<9m_JTUk+A+)u3ZJj?X8%eLsiK=fQ>cbp;5c0H1Gy5X4=9?^W&LW@DWJ
zFa##R43Om#^h*2ZLTC}V)Be5tyyaxuqsVtcx4b9eb85Hm=kWPL`}Zr*y!OvGp|{#U
z3m`oM+S62obtUcVA3`6ue|`ad)&7|aX`#2LhopfYp9ggNPUce|0DF^nULDJ?<}N4O
z{7=qbJ{S4YXwTazr2U`HC*FPD`tEbqPlt_WwA;xN@maUWN%GIaXQ%e>{ZJPD+sor;
z^VgF(%E{d1zw#N92>X-qH)I(LGyn_4gA9-h3PBkV#5qj@7y?U>0cbe!=>S8}F(-L0
zJ~so>PB8^Y;Mv<2cmRJO+8f&gTQIf{p3gxV$OVO<6f^^F9z5p*X)p&E0!!cwf&pnq
zAZ-U#fE#TBf`GIiOanT=5V(R+kca1d{(kr!$bn3d2TDL0Xa&4zD-Z?@pbRvC4zLCO
zAQYs5LO|LTX#Ei$m<HwmL*NShKn%zR`Jf7z4?w#GkVBcN05X5ME${*1APMAwQXq%=
zH3j&A43G!NxvdP;0^&1<oVOTY8khsZK^0)2%wtfVr9c#AFAdB=C@2IN;6$4SG=MHJ
z2evp*CV?u@41z@w7myG``2Y<N2&zCc;1)+-0htHA3Rt4P#sG4?YXsc5{s;q!p~xp7
z?^k$nt<weOzz5_5X$H~)!a*$%9gcNijwH4LNgx}zj=(hnJOEW7QwrOIR$w_2`-4P4
z8u{gb3djb$qY)-Z1f`%B$VnsZz?P^C@(N-=Dd3kyxdSq9Ihm_G8`J_aKRNFhv{{Wu
zT0j!W2IW9>0_+2HL8BaLLqfQ~7Q_SLN%#$z1MbNP8@K|0K;{7FSAd-WX(K0dc$0SV
zeBh&q&mbR=evPE9x?_H9+nLBSNCc#<ItnBK<pqcrkT%@Rg-Ej|(g&n~iWZJ*-~;rR
zAm4z@EByfQFGU(a`7)>u@&NpnqYeQ66<7z}u0mO@MqU9o+BppYY5OE?khy@gKk~0Z
z{(v*^0~z2gz`#fvuL0U50eKJNYKXLhOu%o1bOTMG3rvA6a0TSuMlkR(#(pMHkPFHH
zFOHMLC{ND9u>i*c91CzPz_Gypqy=zW`;W%|+hdNr?;QX*nK)RR7-9T9<pO}r|HoxW
z?#KW0#{a9e&r3Lk7!peq57pO$77Beb4)<;Q`qH@Y2yA0zWn*o?>adHllL_YCGGO6O
zh&}E<k9_!kQAx%+GVZ?+S~!G^`!{7eu*m#bl&b=2ZmkFSjXalP9xDqMrh$dE0n?Il
zci_ODL#qtG+y6=ZZsTZg!o*kfQxOuXg0lBx&q+w;;liz8``led8;vY1jf^dso%46u
z_4y`#0}B=ji|l9Hxt~4L%E-c+Or1#9Yhb-U?s<?lDsHmNA2hm<3XBrdi<-}c=D@ZQ
zwLNa(+UH3$nCon7Z?MtGl16+ObnH`xeKuel*Zq`TskC|E`v^ehQFQKbs=&_DSNjUn
zF)swRt8Cwwqz|`$zl={C`;hp?gm%Rji0?g#&j<UaVB7ue`;z!fe-mGJdwi(}yW)%L
zVSJ74@eK`Q?@Qvd{7rmvsJEn!4G!;$FX=b&k@A?-?)Rdxz24)Ifb!cp5&8`EKKl?A
zUgwDbt5H@11@ZXuqovcog&cnUSv|+&#V_l*3V#1lJtuXrdp+;)i6Mt$g5wi|;}e79
z6NBRu<3G(O#{YI-7l|v;=0^{>Jfz&8F~4BNJ#()D!$E5{RLyS=an6cfcu?`7nY9zH
zEj{&haZQ<o$MIqDpX$S+KW+>$c2Y5AOm*Rz0|(!@M83TCac0hx8-s(2Za*@M(|>Sk
zNZc7*&(R(TpC^J`*F0>mUk&nBdsJr-IPS}wYs1f+o%-0Nz;fG5MU}oBUl%_c)5r03
z@!#X?;(yAA#s7BS6#r8`Cwl5jqNhG0IKCe^z8^%&@lI(vxgK$RKX80MQ1>q!-w)r+
z`OWeD@Z-75Ildn_z8^TgAO8D%KlIe6Lr;A*{Qu^IK~jQT-#ESyIKB`_J>d94_)qqQ
zAcuFi?eDdz_ucV$*G=AsV#qJGpxc`VUaiqgplFt*nL%emEuf#E>!G~Z7VjoKjPX9#
z25JMfgStZPq1&N&eeDqeb%Y*=ZiHq)ouKESo1j;ro1tcS_vs21MVqlZbR^URf8_n9
z7j!4o2O0qNh3<v=K|eruKzsE@zj!DaHyi-vhwg^{0S$smLia((K|`Q(prO#k(1Xx=
zXc#mK@5m#d`(cwqP|^<|68aALChs=e-;2`7`%-7@gJct*57aUc+lk`SASii{Dh&0(
zHXOeWC|eXZ$FBqWRL??xaTWB71?C_aWP@7pf7P!8$DafG1*4zxf0sXpf8v*+5GUF0
zJ{davF--A5Uv8XBTcO|jU?Bb%i0_4R(BXICpZZ+**5AUfd@T?^3qSI);EeY`-}+bh
z*0+K)d@Dq8{43Bn3&#Q+3vevJu>i*c91HyCSOAaDUyc9Avn_4AAiK}@Q}p8{eR&t6
z-#O`%OZw1~{<Y*Y*@k>B#qXq_`vR;Z{k;FH$8ZzN|2xKU|6d)${a-bH`=5^4{#V9p
z^P>z&JBJ)l0lL5x*aAFWkaihbFo*&fAP-c5Mxcv!qj*pP$^mIWQ2~~u{Ra@=aONNw
z!~oL95)U$fG}>l#fjP(owV)NaqKzgOyahB~><e;12@vJO*ioQM6weE;z#ow3ghn9M
z4`ZGI3&aC5F1s9z9e{m+KL`iefQ+M-!Z9)h6yjLoMT3tr&;&l<EtrDFpE;lmNTUHr
z7np-!5!e8ban4i3kY5lA;sF`c917xr@=(|k1cMl$ISe)ceqb5{=?DHmbPRq2`XF>H
z(hM4bAPQv;&;es7AuPZG@t_pcg0v}6&<b?Xkd*{VK`qEuLcXRWd{6@9&;Y0coIwUC
z2aP~#2I2;mfQ*7E1ZAKK?Hi&h$UATb@gM`_f<jOVsz4(sS4A9ZP#`rM@c`mmfSixG
zq2%1fSvVHpSb$>zjs-Xt;8=iT0geSY7T{Q*%K~^r`Y#y&kNM}VO>8&)e=z=kX8ZX6
zRy=!>h4>Fgvk1)x+8@tH*^m0s@R-_t{6DdaG8z7l#~o@+bROC9`{k>#|HKF3-yQo;
zo-;ef-;-#5HuirSej5R_xV|6zZ;SkV6@Ry}|K^?h{b1~Wx465H{f|P!Q#$seKc?){
zqp|;`*k>*F`PjbCP>gSP?u`4_WB)}_KI^dUp;C5yWM97??yHG?k7L{3PrA~okMAs?
z#r0!91%B=EO?}oCUuX~G%f!AZ*fyel-=6plXvRJ#u}?6Z!jWbXlE3)h#MgZse<nE*
zV8J7N=Q#cWsK0MtP~mkR&}5sQj^qDXoh9|`SN<wg@cWPItVZX4Z08P~ar_}e#CX&d
zZ%!SwFpY;Zj-NA*pEHi1Gmf8c8Y_HYOi`uksk^3PJ61-|lgfEgY*{QPDfMg=<~~E4
zEaqxdI{9YO!ZoylzU!Zh^eVla^OX5lU%?y4(k5>RDL&B{M5B$LOSVgFzP#L;rBpq?
zZbkhmHQf}i+wqf%&rX$Fm%Qr8%H*PhXtP~Ow)4z86ME2ez~bUzE3H&#m<9(+O_5)d
zb^qAyVS{PIKgrZ{#_@A2m^u5ot6nL5d_u5wB+uNLn`_kgJn(Lfvh#^`sp8Z36kOar
z;Am2go6ao1YR))*Qm;7U_}w2YGQQC2N|%f<d6jh;?>*)dyZnA`Ud}jv&NzNWyh}4z
zC-p_Rgc;w|>z$&e&hjSrfgvkem+Fl=5iWP2xar~S8!g&+?>QR}qYS!_hmY{1cb*#!
zh8k?!T%73Ct3=d0ATpZOd+3#;&SAb;@DGn?0tWq<wK!w&rQBI>t-d_kJ?Kd9Sl-~>
z*Aw@8o*TJgq^Hd6NX$7&#d}+o*_u5&VEK5<ao*gAPWKb{XuP>)bDr(v9WvD+wF$5B
z?oyG2S8p>}^ya;Yr09Mvb%t+w`df!3&lQ+^;rXU>ae);><S{Tn9(iHVceaT;=gXxR
zEBn1{5`U3sYF<!g=&-atfNw*rg5Dw(3B1dkN48_;7g~ItA}<zK+b1;t)M^{LU&ATU
ze*40_>;lJxDkmL)Pd&VMWYDu>d5W~gtMr;NMf2?Jn-6!qv#N@5pFY4K(P9x}q@8#J
z`r<2*?PB{2e7Ie0WwJoE{$L0zT-c7;%(Q$~x8}q2OPV_#55&7h;_H|}-_3fVv)wTG
zh~Huh$2O_d`P0;ws4yGdMwvZZcB^J?Mh)hc#XCy|eaF@N$IgA$Q(CM0{)nx;%ER<W
z0WmzznR`~=@Q=F9n}cVuEmU~@)K4+}Ys&KPHZ9v_mN?jb+yxUw9_O3E35lYLOmm$y
zJk#P`DueE3ccyH~^(*5G_UBaYt~_wQm0p>`xVgQ`Z?o%Rfd=v({5@5^Ym5rh9Tva!
z9xK;JgH~1e=d6KuBBb(?vv^W#U!IW-!aH9F<OSt%_pC!pvg+HS(pj0Dar~Td{Er^T
z9+#0@bZ9~&XB<B{KF)H+@pH!UqaNI~-!pi5g{eplE1ickj{h0jdS@>n$46+o?3EU^
zJ^LlZYCmws@pH!UbH?!}+LUg|NBi|I>V9%f*`vT49{MsFqox+-^q1Wt7~x(NH)@sV
z&GZvO83om7r&*#vj-!B$gA5wERIc7zz*pq(e6-D*v+Kv5<(a-Z#bzY`yvd(%AG?kU
z&-R4SDB5%#mU2c>gj_{HdTHyzXBS7%h2^Ivn^l|}hW4Bw>c0Kz;($*!z1^Q?a<j5F
z>enkhcYC>D%&_Z4A*&pQzbh)oy)$PVzgwcAh(!@+96zaloN@gB$>aEGcv0B?ewuo3
zO~&yL!8xiCkR=i0&&j*&6Hq*6(vqOFp{dYMP&|H8<M_`&_aUqdXgKs7^ex`iW<uMb
zS<t?CKY0-<0?me!Iks}36QGx&TcKB=<h|)t=nm+0XcP1%l)T@>`O|}jXW0TMFZ2#n
z7+L}y2E7MWgx-hFhCYNofj)xnM*r_ps8=8K4~CNW^G~7gkPkfecD(2O;kbNZY$u9s
z216%8{~-G#JkGd$^e5lM8J8b}wkgiIe2f)Xh;arW24sU;Agqb;3P2aQf*6noYJuP)
z9D6_;SOR~L2=YJ~;9iVz06+tn0}l`il0Y6P1Fb+p3vmEVU<m?28Yls^fL9yg01aRY
z{6Hee1LdF<_~E>ztBW*(D3A@x0B2l2t_L_*YWTp$xIXv*DPNQUR2!NJHH4D+3|ql}
z*SP!)jL9$KjLXN>h_i4kz_9?w0vro)EWoh<#{&PF1@L(O-S~epN3%Z=n1Z>^!NH;E
zi;Vu~q|YwtmrFjAZOCVS{7(A0AHX(bAI|uH^eqs^7y!_*48vze`}e`Hoe1byCgZbw
z`*#sR^t}dTQNTLI_VwN8aOaHw$Cz+Dt8vEv<5^e?wg8;*|6h;)C+8zF{-2z?I19%D
z91CzPz_9?w0vro)EWoh<#{wJ+bXfqe$N#Iw|68-h+ZeA$_)0WoAudDs?}BH0aay@8
zZ>KJ@FtN9BurXsXq?gJtv}{=xRu(RpI-W7x#>&>hl4*~z>QX`m1{+Nbj94st3u8wX
z(*f__rG(6xmbOg$?rUkZK3H$WvZU03WeU|4I)Ufzj=9RoJ3g}L0|9`cYc%;Wc-J?m
zKj{i#U_gy>wq{{9HO5(#eE5E$<|-#+vKjcTeVj7Vh6(Snkg@gB(C+h%lXbjUN7_fU
zxGbpf1+b26KLTiRS<^blGNVD}3N=R0<m!m{(G9&WF5x<OxarKC6D8ia%<80^dsR<g
zleyl7^tD_zjr7qGy|I-0kCl78GpC04-L-s`@MC>PCmy|^RU)&lX3kx;+z{_HsqNmC
z?eUSA`FVn<dnG;UgK>U^&JC{$|0z>LldP}0heav&ypPyJyccEAk0_|D-R<6bDCr5;
zR!gt>=Av)tp9G(O5u8~=f37yta~0kVQhn2smU1_FE*i4gHBKgNi0a<Lawo|K<Lu;O
z$xp!-_iLXrf$zx4Bs{P2Pa`VUZ=R-Hm{`DFAi`CvQ63?)^sKjJ#KiudBj^KYG%IR5
zjS<GByuIjl_58ykEv7}a*4k$;m7bTX&_}K2Y@5wzTa-7I-%T4NM|p$<@@)4xE2cBf
z)4x(R@QzSFp~#?1ahLtZta*j}QsF&GYmP~aOYN`Kuu4(&!`@AXmK)O_>b};LtG!kl
zH6#-6G)t)M;*}>v4y;V*m+&yx^cAgTGrxjZW>fkAzHL+e?EgGhFbZuxc-~~tZ;J0=
z9#P#NC?|D0BWdEex~2>Ag8G7<(^{Ks?KR}*eL$U~wi}ud{ZiKEUFeBT+(!J@1f_2z
zB-<+<Tp6CwcVPcN#cNT%JsoTF4t0o(jc>2VRQ-;^cf7Wxk$yX5L1ptGbsoWX&M_g0
z@1#%5GN=fY91o&U(ga0(xsOGqB|g$?)!GjntmiBo3vevJu>i*c91CzPz_9?w0vro)
zEbxEV0^h#>C-?px@BhQl`JX%=D-L5n=aOgIc;T-}!1rU|I7kHKd7CW!0M8OM@+^$U
zF`70Y&)w#L1w4R12nFQ1+!+b+19_kvkoR{aZqCB70LKCx3vevJu>i*c91CzPz_9?w
z0vro)EWoh<#{&P{0{`s&Kg-_8THo1<rH>c=X7)^dBP-LXQ}hkYnARH|Sr(QK><$3`
z)9?R{X@b<dcG7R0EHZ$skOJ4`F>jcB`}=<*6MGhwcmoG>3p191u?5RPnQ854#V|1F
z`pw7~{RE6mSOz9G)+~D)OL*4%l}~gA<;S1&7m&ktR}r5U7Xmi3U|O28`wNiv5%zj3
zBZm#_bt+hwjzq$5KS>JJKVWTpJ}l8bLYD6N$Va#ye={ErEF+eq!^~g!b^kgK*+0nx
zd;PETu%kT>QSj$LmZgBS6JfYF?KZ;A{yq<+k~vr!v6!SheqS78zbh~+BNKBAYo>vN
z1M|BwBews+(mD5n3VzI`^6OyZXm5f*U@Ruac%VGVJNK`CGqW@zoj@e<8)@%imnqB0
zejO9l3cndRnKP{o9GGYT8-;Cjf4+^QHMJFuD)+7JHY+3tD;8oa_@JQP`QJg><feXC
ze|u^(cG3UZWF6ImsvkYE*QH<B>#N_su@}4k{MueW+2$*Ib<{C#(g6a?5<u!0Tn^Am
zkhZ{o*<L@WLEqc#r{{&9*o<9Qeq6`C`t2K=vFqQjZT6FGzOq?I9V27>$<n=!-Gj|&
z3jb;y>u$53RkKc${mXTXT@QY2udjal#$N3D_iKCoWSg(-)p1QBJ`cz;9*}DaIVY2A
zisAS6!v6o-RpsaNY<zt_X4j9ucTMTY2bu4bEZy@#t|?J}J0G1z`rmS0S=&Ajk2xPZ
zALRT<vP8<{0rFAC&IilJ;F~)4{RQRwii<1!&&z^FT`S0ZE9Cmlt~;GUP*+y0rq1KL
z+S90yK2>C?1thtZ;1M~-rcuXO*SWj>2E%~qY{Ep}NE>Sda&i4W#hqDd-{JdnQ)hy@
zUjj*<esyjlc~U{LzPiS>M}gI_3A+y@yZ+fT9ULt?Z;Ht8q)%f<p0)dtH8k35K+2^8
zlp@b^ihncDKgiMd+5Xlr?0cM^<oT;}?ho?Jw#kq4ytloarO8V$EVx~u%GnS~%Gprq
zCwaEFakMr?N79bFlz&@Ev+Hk9^8K^2CS}=?FIs<O1d9<MWl7%ak+LlN`}z8trP=d*
z{j5AmzP7ZNS802`y4O*1?l7GGO?k0TZNDg;pIz^|XY=dx<FCqw+-s`9#$Vk#v3IBL
zLmBvuea&mHkL|y8&szrR{E4M|-ku_FfyzD1+xJQT#o_j^=k2R&_BVNB=llD-b@c0&
zL*HPs3<jh=l2_1W$XoUdDsMLEC~m~Eu}2SGc6}lG{ldPcl787F40e4nLO*dKA-sz2
zcy6Q4X&v##{~+EMh_~z?#LKorSG?@+#$UzDAPK^PKD#t>DIwRoa>PrU`S<h7KJL5X
zWq<!V-q7}VyW6<}@iP8FyzH{=ikJQU>v-8u@86fN%GdF_!UEKFn&|h-zh1t6<mLfO
z_xzIbHT(zh_N07CCvCEPTfQFuAl{youXB66WK06NFOdY*$Zym)@nUL%9^1JR`(r-A
zUmizf-g~likGB^475;;GYrcv1N5_%*Aa=auo}C;=(%=pDqs{v2ICA}0@>};!ygxdQ
z%G%@Yp5J%aPvsxP`}Ui7yB|l3JKBxf`{pb_7RfnoE_jdqY}xU4Z{uP=sdU~xb!$1n
zK0m*2?0POy!FKF(XxGgXxgK?-rMW#V!?7Jniv(yyS_*rVmi7w-_WAjJc~@G<eL1`Q
zyY}mz7N5b`0L!;_p{Y>ypu1f<p5cCInSX~}1j)%9%eQth>|t6ua`;c|(lMtgt354n
z?Ls3>PjEFs`+zbEWT%C+YIVOW=q%`;+kr+sD-qjw#PQ$<aWo;0>>tO`k-cBk!SCa+
zB_~oWq^*&h*GSvON5t`#9S2(4{$4&vo30ANVjtt3+3&n3bHs02Txbiou(z?cVp0Rk
zy62r&6dPb6?Na0zm<O7XE<;tS-hG>{9_PIyUF>r}=Wf4Ems0zEuwQ$+Rv<mZUZnku
zJhx=C)7AYMx--+iEAy|PB|EB3=kC<~O-G%WMk*SXb%5B#7*NlOYLs0Nf5-kkJuk8A
zL`NFh@9n;6#;4I_QJ&I>i~W21q0ThzYBA_a?pNu}Y)|iy_Vg0-k$dZ;AEvjfJbr$R
zcBQxL+|_l;>1b3Sb!lmPnfZ$&QY`j>l$jMEWmeXnhR!zh_B<GvGOcawt&A)?o;3~3
z>}{+_6Zx;s?_KFqLHO)?-`)n-%{CqF0_@+vjfmW@@(PjPmQgM0v)OM^5MKBEND;@=
zSk?kk2QZwFsspyO*>&Le`9U?Ia?|ttu*?1X{E&31w_igO+tbzk{M?GXyk)1W`?Z4U
zY-?m~YCt{IcUbus*DD$|u9Q6Mkuqne<?DS(Iu^92V;Z?&Vj;;P_93UyHl%|w=euhb
zIZwCGKmB!hzp8%|5#I08GP6A`+3jf|ZHMGKLGGuBBW>-UrG<KJ_Um#X@ssx`4Cpt<
z>sJRovB~Q8bQqEY5KH&6>4kIz{x}_Gw$#fUM+XBZ8+%iB{r|e94PpJxMx?HH9i!jv
z-hQ57KfzSBr*9m>C3Yg`8amRK{p0j?o+y5GZtZTT_GgQZ^BS>JXBfmz9pz<7F6dZ@
zkh()oU))FsZSHq<hg^d?kL;e>;+yj7+`oGo-nOTq`#G~W(jfQaG<4>pr)l`s7TwR8
zjmWAX?!m2a!-sLlS^3Uc#|O`pRgIIKX2|$+^0D-CD~4V0jkiIg8aK=A#=AN-vfW&s
z*s|QlA!70U2haANB_0ttdh_LtbN(Fd>~o%b`iq6JG};UyvfaOLZm6wP`l@!0{zLd#
z+6|A}wvH}e)bvz0%lHnCuz$C3-@+H$Qw)%qhvc}Ym(ea&*2@Hmy%}ac_o`9BCoNCm
zM^$&DE{v6pv^1)oU5NhqDr7tV9O2pndark^(HgMWOlH#7Bfe&~&5^!-;S)R$G}8;h
z(SCvp80LOBH9ud^TWPef_Tro;MjpMQUz~fMx9N@elO<lc6AvZ3!{0L%ukPMe{Vya~
z1&VCAm$@!jbKj>eyVe~Qd3oqzi*tUPd^y_GEEkgSUKf5iV8#<rlQ{M6zWN3Ja@Wkx
zk00*$Jne{a$J{7QRDM(X<&3Zs;@cr$>lSq0ind*7>*j|F;bKmKFGoC3*kpSK^PCHk
z@Lo0ddM6!Ie(F&QZ}6gO<%LSG3YWef7B_CU;Uk_ASLz<nXv3&@!woY_w)woNE_hwI
zl9{_)`f2oC@kP#0Y)=%Pd`06Pd>wQAO(WqgF8?Ft&f>YZuN3RQO4XR0zHmz0LB)Np
zX7`u#H5F%k!i6<dnQS+g=i>Y*ZUz1_k#+fz#jU;tFDGoe<rkP_dG~lg@3V7oK=pL|
zzQjxt-qRQEqX(X?92>VoMPrJ?GJ4U5$HViEDLqMydwfIEjLaRBpg^|s%^y@}E4{zp
z{ZFoYKJDD^rKjGQkvVOB-2~b7VfhzSywT1~g?DXzMy!eWq?tdTb7$}p65c19!?Rj9
z#>J;uEgw!l(KkcwR9!KBMn<T^%y(;o<(d&^Gmb|Fy=u-idrLJ3tB-T$rkX4%<$4j8
zU+=cEhOyhJNj&CK@*bS0sr2nS`SHA%?+2eMIUSSvv!}E!KX%tD^wl8;_0h_;iOu4x
zQEs?cG3XOZ?Y_iCIL>sHKR)5;rS&1k?n|z3ng68dI<24fxueOjpCqm)40^L9YgBaa
z56>p8t(A0`6BRUBZbjrp7ej~BadnKOGs{n5z6Yw@XnCx&o`<Ezm%qL=bba-Di~GlH
z&Bl50ziBysyT&(+Ufy$m0Nzx7*9%s^)z;f?C2tjKwN4@^%st7FF|gcZqSnWYg`%=s
zF&3t$eiv?2;iXHaXlBK$9d@wT_TE3@wf4qW;%`Mwc-0P%zL2$to5#B6a{~3$k3&!A
z4(jQgKs}vfD0K=cw*eQoEgRc=x|xN_(Pf73G<NH4NU7j589yniAwJ6aLE9}F&0Uvl
zH}<N-iPaUeF3udKpH#d^i?_+I?PE^Fuo(scb>|PQ7qUcK%yhEdkm_5*-Y1tAB)BpS
z{@L6-DO9{%Rtq+Tm|lsUq$jEJ*Ydo)3ENVerK%<@HD5WlVQa&INi^CKs@z^}aCnoL
zax8U~@z9WX39mEH>^`hKnd^Vzl;Y>IFo(b^Xs=?B^p)scR*>zRc*Eq?!~7v3S%E&L
zBE~#HGXfeGyf{`et>0uCEf{r%K@T3#ON$wp>3wz4$mQ!IMbv1YJ<M#T#koF^SrwUP
zdr1G^?+3#U7gq+ocadVMf2jG5che^yIxiGiI_B_&HOHC#Za!BTV3Z?kb`j@iT#FfW
zbxn=AYAedbO?NrHEdJnhJvNKBEXU=K^Y+D(K4A+SY%s5jBH4~ND_lmu`pcsmqRR(H
zr;4W8j!qiBGHtJ*n%tYb;Voo-@hKu?y9-rc;!CgES&w*cptj!5Z@zQh@QOayWBKK_
zt>5?1m8)OR{cq4zNqBNP0;y|`ZMqhFGqiWG+%pY<t*7Uo3GFpcIv_sUL;MNy`tSDB
z5l5Y0%03-3m@TGeGV;mA1y+kk$n2{7yK@5d)b9s#Hpy?DbbJD{aczsp6qzR(N4%$(
zo%a`ucS&9D6*qCFXL1m(=RNfg;zflweBh8X*QfRQu(?=GfOa%U+GN6Xfi`)o-Th=o
zOZh(D5r=Y{LE^3UdC|wSZAPW?^94x}juCoVr|2K=t#>vY7oE6wO3EVKZ(JHowo^a5
zLjGd|tIbMr;s*Ojb%8UzlCt=ZFQkdJ<?(4x%-M|dI8|=bzU(}E!S%0*O-5r==CyuN
zaIJ|MztXJGce96Myo6(DDUEi6ir4&(PXO)YWa$YhOuqr1X75gy8s2gl^_VH89h<gj
zPCf3ezEI(X3=!i|SG+lO(84sHjW;KFx-Pp}xQ4ZJsrv4fVw2A2&qrJC9Fo4J5e0U+
z`|ocST<E*alKJ3X#SoXeafcR~=5Pt`X<K1~dx&$?^>SN|N#BcZxpkYI-{n3|Y!q$E
z{G@qS{e{y_du^wFCAjsYX;9bw;BoytUb~4}SIf6n_0ha_t43*lYFIw~!&2Tem$yiV
zY(hH;mA*nd!OD-J2kSr9-*+?6)tXr`;9Y@krntf)+ri?ZX-7?QJ*T$w7UeN>YKh)h
z9$a_%;IW)xSz%WtqKh}A?<~!~V^~}5M5C$T#+*SfcQ)E6yKqUgdH9Y4n|6qAF`vBL
zp-kC#i_Q}Jq<vTNaDT9w3NOq$%l%C1gvy!?%9S>*qw0dqyd<QITI_6HF1-l0<iYu6
z3w51#oyCj{O>JQ9n7HtsY9HMhT&6*j%T&Y6MvT!iO>Nf0JL>@IemB0Xi6-H^Q0d|4
zG)<$28+5NYnB_WnkBv{MSyQI#lx9n#jib(!5^04l!*}H>Z<0@&m~5opI$(xO$@HSV
z4Kk~G4>8USSc$ea%6`9}lldrB5B%jL#(mkoNXKSo!JW^+CeLEL7Jj*!cWvmc-SuzB
zZ#g-<=W{m?r{bOWK16n)(977wNy)oUihC_e+E(gz#kgo`b^h@%8TXTK(cVVI`}?_@
zdpakx6LlSY8^1L1f{x(o=!1W5;PdX~np>N<@12t9@O?%qZS~t@u#FCNeRE|Ee5O4i
zy+)CL|NZODy`!Ur48!(iw573nt9;!4Ft>n4dxnO32EElg!R^W6gqPkfea{UVHqueh
zrM7PDlNSRM&o+OGja9_)_LB0qG&*o`Am21r_`sN=O4U<$O~rPsjGiZz^Q73aSWZ&v
z8Qy}Db2NkAqIB}jq=jo}1%1~)7wJ`cIp-<!ufBpej-^fB5K?@iF^ERnLmeNyPrmrp
zdNhm~Y_4#=Kx==n$LFY*vb>L;y5_7exXHV>h(^0c*?H2+6FWXA>+)S#v__<EK-<pw
zbBD|tozup0Z+lr57e5&Hrw3+{colawHjj20`dGJIVy)NYs?ti<T*-60LL&kf2OSU}
zscDDv5Otlgzb~li<D<^)u&k09tNPqy%v`~1ar1pEABM<rHyTbzME?Wo`D3Vq=8#b%
zE5%}TT&%TBUHk$(7LEP<p<c;1Z=#smknjeyfl>9odWc*7BFP&*yCw?8TrrsRd{00g
zb6(Kw?dxj~rZ1~sg7ZNj6<+8|1;(e^-A^Cz9uIC1%9y;SUv!(KdhChgO2@~REvG-E
z(Nd`G7>72soloVnV+pKEc{I*)>kC(bh{7@T;hDo7Y_g<Ao#^?T+k%u`xO>YdA2b}b
z*q|b0m}|1~MX3uS$Lo*nxHY_7YmM9I07=YiMm@jXo!T;ERZjizJ^aEv|7?!?^;EnG
zw|Ou4@EqPRs48{$#0$AyjK%YcM~=BAd#C?^;R-%8jM1Ns+OB%3>Wy{AzMn4@9k*+)
zxfp!vS-#^=t&%I!Pc8JkbXTSKd=B~dRCx1~r9;!k++Oyoxy7;KvG|%<EiRFYi?yFk
zUQ*_@Xu(dLgZ|xf!%I>2TYqk2&G}m6EkB>rT8G*${A2a=>!<Zy<%e$jvO4soar&3X
zOC%=q9S?8ZV4U=*0O{L8ZFiu}^OL%&_6G}-%jZuW+xKa@x2vRtn!^8M?_A(|zW&Gm
zNg;%?Oe}m5au2!Xmg{067D7|$qP8eqh=q@PBU_`*Ez>MyYjcaaWXssr2)S*!Y}yt=
zuFGvQ|L5!dd4KpUjrRTeUVi^?=h3s*=ly=4`#JA(-tY51=XK8ix-5CL=F%$aa!L1)
zFX`U!CEfGAjdGuVQ{{ze)9=oid8eh@9}#hbhKIYgsJ|+z!N6pvU5#RH=Y7Wdex=<Q
zV_RlOa&qe#?H27@KibBr<&<-y@9%zde)ilAQ)4C+4sfHtB+XjWx^+4pp7P1np1W?E
zesQ%@!cU#*_tN<F-hK4S%frUCbMJYVwfsuB4_91$``qUr&$x7Fd7V$HEZ*%f(Ijtb
zXWhE)c1s5)yl3mfc!`bpSN?0OcBk@okBM{Fq~1BwEAaBMt^eTO(&d$Q<8bn?W5(^Y
z3S71%yYTx_uiY<5yS6ZA<qx@eGbXNdIpV*Xc30`QEX@0MPaD}Fd2Y+$K_9eo_|f`c
z*VLp6rn!adJ2f31--3KebCLMn&RR5EH?#iAvD*86J)GVfHDW<TLH+)NlG+Y?5HY9G
ziDnwjImKS@-7jsmx!|y~Qcj<O{x7$i`+@nL6aBY)HklbZ$-G+OL!Cy`if5CO>=}JP
zu{U^Xc3OvO-!ECdKlAeTLmN^%Hy>4_;_qF5?7FaFoj3Q5rS4fO`8>n?kM0$gd7BJs
ze`NEio+D??yqMkTC&x*b%iWk^zr5U>4EjrDTxH#=(2ttWTlMYm*}*;gX=cwDvgOsG
zwOy{2A6BDdz1X-7v}-ptjK6`p9zq$%%_+wiCFkrw3|*y;M={0{*~1aZt^8;YMRonb
z-*QLR8Rq;e-{&Me{vPSAdlCPsCW?MK9&==@QYYWZY9Yxc*{@PJ09h9)@fZKp`S2P!
zUz~sVsrW~?rT9m+R{Z0!QSndwF!oQKFRpwCE6zVd{Kyl<Ke}thKZ&QrPrmON`=`#O
zelGEo@>1s-D|2@xe#Yg+qrXyKq)o@8qI~mzR9@=b-oNcmolC2HbBHSY=kTZ#I&;El
zsD|4}4KI*$>ikw^-mAE)$SF@bkKxwURY1}dDe<Lh>v%+xdZ6eflzKOXW2tv5ky7u{
zk<Q3pk<<;{1tevuq))<A=awpS-iixP;wj<DG%g8`SAQkEp-2fY3Mt{OKuUODAf1sv
zBPG1^NJDrY{8s06D)T)hJn>)3UQA!?OZuo2x;{wiu2O%wHFY$t8ip#BbYfpOn&Ux8
zZzR{0^oalJ{7PlsWpVyXc;dg@C*r?^BmPSq#Q#^3;{Qmb_%C^H@L%#vo#$9=e$~Lf
z_)lF|^h3&h$k2vT&xavj;&?LB7MXyQdjBP|4)PbI)PKn@EmH1N2~VAS_-_f1a1HYT
zmHAw9pO|pY8pQmj#!Jg@b^czl_Q*3O{$fv~pP!`6(<<tpyUAmFTGd{4@w-U4OO5<<
zeu_Qg_<29Yo^kwiC5&I9YOg^t@iPurosXr=(<+({<8amaQ;+%q<9s&G7j?c<vHltI
zMcOxYev&djN5VDbob)|nDv{4pFD;N#->azkF7DL1M9TNTqVB@TcX1bvv_(d!<sk0V
zc|XO5XRU@;T@9~>QF!VconphI?NY*fQw=ZLC_HsOjq*KC?rY=pwZnfiqSO`1J*Vkr
z6rMUqrdW5iRCo1NcMVi`F8HC&dr|sZ36Cs&)Zg~Np0rc_kkU`~M@qeT1?h}*MM}Rq
z0BPuN)%hw)TUXS-M%a^lZi$ro-wLTkIv{C#HEiLj^yh7m;-BQdI?qHS?Ml)7*h;=h
z{I($nBX_9z*pc53J(cg5%DfSAC;8SK#2mz)#DmvqB_3JGF&rO58p2iQYe?JmM7S+g
z_pOk$ff7%}osQq?91CUcg@jv~bJQor#9&Y2y8vmAj73Vn_BN6}NAnJnzD5&=?1Nl{
zl=gZtav(AuDe-(C8H8Mdd;_^0IS!eCl=!=WIyXX@Ga>OP&$-?pCK!8?{t%?(JFnSF
z{}YB3w{jmaRHK=Q9D$sKG~|mqw?V1bMa$zR<tF~#Maq5jz^EM6xd_S}g`(~>W%TZ<
zB45Ov6;i^Ja#ZIHD9<J0&bS=Y@n4SjAf-Nig=~V{YZR{fy}#J_=3-CcdkHD=y{5X8
zaMkbdnil*n8tzu?Nx0jP*2vG1Ql8sY_tXc&_w!=!$8WGF;eLyh`#8hMo%+qY*m}21
zb(e;edbb-HL4%sa?@SQgX*pn7hO&kTNQQinJ=VP;6J}#Kzp07FrkRPRH-v)dc)kv1
z<gp7Rz;Vb0SvwgGv5*V02e4uPU)k%|c%NTa5*82XkW6LYE)|}KJJB7T1gWqOy3E0U
zqysm56r_VgTN6zpSUQq0$OIc2J#WYcxAvR^mkz`iY&zlwT)-QmAP$lt9nQdAu<nFC
z2!sSU4i-)(8b|Pi*^mNRa2ISln`k^B4$`3jY`YK!#K1=Q|ItuQ{<QyJI>%qOqb%W(
zv7}FG&v+mYaVAKar?HsdUt>q+dMJi-?{MySj%6;%B7Q4#Z;&!iAQma}lNKWPAZ2c%
z7@6xii*s4XA3)aI1arI}`6I}j;OQLyjFh?eQT&#<bumV6WX|Lqj`t#EUYQt~r#h2!
z2az&ALgvEBx7%-#r$OdDPviJ3G6yE{Tjm(fL(1IH*~oA>$M5qnk>AE~oWQZfQP$`m
zK+0N4f6mQN&r94To?#sSip+&be!m6AaSADNJdR_DV+P1NQa_G$Fkd|{ahG_87C9cz
z@nn!VO1zGMtPLN_IhhN88DviVn;b`g*fGTW4fR;uo&Z_z8^pQm$QvMY)2DJQ@s_w9
z0$Hmcz_|;^Jdkw)Q#dw``|IklxH|^2_BxPrSCCgh=GsSdY`pKGlwBF>o9KTunDYEK
zSC1<pE33cvHl+T6!BpXVRrQ)I+Id0!J(CW1wsg9flIpM2VK)oRx$SL03p}%E+`$_{
zAs*srE2X_G0BJMrrJaP{5C~DQ9Wvl9nA3K40oga*n)cET9Ki$pfXy+Kjv^760^1=2
z3c-SQ)fOC~H^^Go2#^PiI7o#|+E=?u*n!><2oa!zIM@hjkOA3XVS%5}9D0L0L_rLs
zz&<z*xljn^Jlt4=9WZT8;|87(3OY!FY>;_B*FiSg(1HUvg9pSx0wja1OUr`-&{U-#
z17~mrZwQ5W$ONeqmS79b!4m=@0%k)hWI{INLLpdie>#FQxPdoBK^!E&Mo5P|C;(Y|
zV*~c!2A&WM(GU-bkOKSQI23~U3%CJ$a0XZKhEP}vNw5(zARFYR(*kUvIrN4C=vbXP
z01=S&BL4Bx?GApRrSp%5ScvBV;<`LU)WSV@fDYook{59g2!wcEzVqNNBygYEXz>#q
z!5Lh^16=A6c6}toKoTq=@8o_Rj+C}@5>na^xmTqfpM#Wkp$}5pM}MTWOO27zPCFr`
zjg@;+=7P$-DE)!lmrDPDl=f`~Qrep~NNKaBY^6`=fs}SQ8YyjSPo%WdE0EG|G(k%H
zItnTAtALb#$qy;v${IQ8OYD%+hXf%de*M(*?UCZH98&r=U!=rm7*g8m7D(w=1|h}$
zIHb7uLW;XrkrIA5Qrg+BNQvKkq_mB1Bc)9oh?Mw`M~c7Qk>XDjQu3)fvJhEnN^_tz
z2TF6GGzUs^pfm?cbKu{V0}TH#UT7juz8XI#&ya9Y<)_!<Ckp+>1&x2hKWw~zuqUeV
z!aXDT?-?HE>**63s{B;;y?asv;3VI0U!MrC|B(K_TFRb*#80oRjn#tVea8Ch7huXB
zfwDJXMda|H@qQtb!g)opv+66VSA0arj*N%fS@r1I?-_RVdkY%YESgD1V&?OX_abs8
zGQKI#{gW$bcuiE-Uqz_-(q)owpih`rgkB#_hT`&xe~)y~WpOEsLFqvze*WPRLF3hE
zGR|mamCZH%UW4I5Q~bSx#(Vh(D@hHPcvxBGa6OE70rUtetL->c&O0DwT%Wc16Mce$
zeZ~a)EB-liZUS-tQ&?X5JqyLZP_D=F%xdsYF1@HRwQ?qrGWNKQ>)+_ptc2sraRdx9
z@#+&58s;_8Cs-rvfDCRn;${rj)21l-q{JbLV}0Dl`9yh*i3|u}r$=832#<{2%03aF
zV7JbjdbbikcaEPHo|duDH?T7_`f+$MB@E9Ux0|t>uDX@*Jf9I>oEl#3X^+EOTEg)5
zso}+_ZY4awXN0Gr9&W<U^y!boOMXUplBX>V>l@X2+#EOZs@fQqQjc?HDE=94Y|5#c
zr9Ib*F@IXe_*eC|BMzTdZ=JbbwBAZQ3pnpUeLh8tr8VvR+X44ky<VQbyYq#{ujS;q
zZu{A%Pm;sX_%0r;f7$Z!>vKy!SGlBfuIu-ZaGyP=d1f!M_v|^>&wK9ke`-#1qLN<I
zp;I23eqZ;Kw4{tRpV_Uy=HpuL-uOBF$2!eD)@z*8EE<RPO8z~2?sMbbl7IDUuMFFr
zVm&Z;d6R?5mEPIB=Fa!&d***}W8~u3zOC29BA@nPfY|FY@ATW3&;0U|)!MWQy-%Dy
zSLNV>{pOv!kMehKTxWWvZ>uxj!FY-GInJdn=^XR_)SPP>htZlYx?%G`=Xd(ysQ$aF
z_6hkWc1hTmzDovoo9R0u{n-0!><jsR-bd`c*Wy5(nA?p947&93E|*SL<0?;^KjBr^
z!BbbheX?m^v*~O2-m8>H!y^f+mMwa>-Gv)lVkgyDdb+^mvuPT)g{z!~JDyt7ZY||o
z(mC7{760y9dLNxudxdvE=JkH}npe74=H&G30b{->j5e*m()Zl%y{zT!BJq3n9PTv5
zzm_c<4<7YLU%Pg<>TBzt+i+&~nyMAL&-?V3soOW~zoc#cIp3R=`jYU)fw#+@e|>V(
zZ#KEN?(yS!?;T$^7;Wcj@lD13$5J$>eKne`Z6)0M5tHL8*v5_@n4Nk!waSr!pB{^R
zxqAEZeLh(E(;ZvCD-Ri;>n!%3J%_tM@o(C@PHmm9E^a$w-3N!iP7cp#e}BcCl|vie
znd*}L!O_+C33sWIj*x}xPX~TD=;diME0wKq^rahpc1~^BF=xQS@^$*p>*>{c?em}O
z-BPIsDR=h{9UtLzvEP+pS2y(Z*gW%aa+_m2+B=NhG~%P-n~p4}zKoFc_V`e@w04h*
zZ&;p8@BeL+oQE&i4UFlht!7nY(voJIPhDR0zc+V0P07FeQB#kNyVG#6+g7s<0Z}p2
zdwiXB`cuoohUNQod-GDy3OeRdDE2-byQNm=cMpB}PSv#=_e^!~9&_>5lzr<CR^I!{
zvYm&|U3rJ^`-;6uE<=}f-c&h$>EVUT6FzHU9d_S-ZU^1>)^qYseLJ%G>wb*+GIppn
zeSUM+pZ8wOm3bgzO?0Qt%`RqrzHIrmDXV_{_D;7wj{B=GK63a}z&g+D4Yk*CU!EEw
z_9k1Je5(un?wiH4dY-!C71!cn?{DjUzN7u=DTjjR{o2WyZyP0D3*n-)e;#uk=cTW+
z+F$XvYKQOVKKy3w+Og#tc<%Uc^x~7>zkf57wnd}ZyWXX9O6#Ce)~|kTXMWN4+T|hJ
z<{Uq0R%YA7`#lb=e7{)>jpn^qB!16c<66=^rQ?)#=-KUGK|cxi*>jb5DgIsfy`aW#
zS!d5a7(Ao%!BKYk=T6V*>Kya)ffsEzPj9}@dOl<NN;~xIy{s=Q{*BSSI=J6AFTFl&
z(~SyWw6AM-+;QF7%sp?_vC3-tMps=fWmf)WiQlvB)f_1HM!&1Gy;@^a<VQ;~hdnf(
zTz=N^!qXWiT3y%`;gk7$`{i>OS6BQih!6P4Ch}PS@t$RVGs%8wO4Loy9WVd({rO81
znr<1E+WhV3zZRmTdw19EE9uzwSv9}mXI&n)jh#5p=SG_gVRzfTf1#$y#^X(ccUZ3&
z%1ckAl8)#Z9aFoNnP->tz`FA<3C=%_8s_#<&fV}~0Zk{J{?uk{wUX}zzDx0ML5D>d
zW2)b2-|G*n0m;Xwe|RJ^|A(W!Th`GuTd;Wc51qR6-A9R^^>P2?+huNca&;eidwR7c
z!wQFtYV>J>!?I(yPxjh>->rPf*J_k>jp0ru+`~Qm3)6co9NIFt#VoTAwpOa8D>yLi
z&5Y2~^P5~;lE3~k-^Dsf{#^}eYjfcHl^a)Ax_`y{dil!ZS8VE2rOy{XPu{sM?tJZb
z6UZ0RqBULcpjK3-!?t5xVt&0{>z5S2z(YCS;X|%2tnkK~4x<J*+tObu`SR?wWwn@O
zr8V8Xru>mXEuG7Bb#&d)>%htRH^=2AP48UQD<x=vw&8?YH%h)%qoixbO1h?_q-)Dc
zy7uF@Zj#>De6qHM54=9BxkEV@O<vYZ-K!m4X_v8Sclj;(zkc3yv4j5m73FbaNBI3s
zJ+2=)(>?9x#Y5vV?o6}Ke6e1_$qILOdK7;0J<X(29?xE*^q*RDQqr|d*LWAunx4Fz
z<$K+(>yi5TZR1|_Ir3SJS4Vuh%VbsM8D2ZeoWETom+y1RbKSGou#|Ldlq^ipn(n<d
z<oeBtnopP2I=+3&%KB#8M)fbeUag(k^=?ts`(D3JUsTdHEG1n-)l>=BX@8g2t4uz%
zUbAQ5m4&};u=p(U?STb_s}4{6zDCPhReqn!cT#7G-?P_7{iNJ)7uqLHD4cfpkFO4$
zS=1o&>d4ePBma1zZ_t(v{qK)HH**~Cc<zdS&t5}S(lsp86#t&R)@q=V-b)uQTKzJj
z%+*@AXD5$n-EfUdm0%}_tM^y6=vSeM)uxz9|2ds5&s$fEd^^^fK3fONXUcQVvvsCC
z?=@M^dks~DQofOXS8u=e(EQp9UJkEXUs#@aAZGsL^_r>fkqvr&H+6I(_3wG>bSdfD
zty%4r`{<cEL_Cz|x{Nc+?Utl{Rxxh&Wh?E?Vcu&ZzkP4=5(nEsCe!!1#=XO{b4k~N
zm2^#8N!NmvREJHk{*vCM+nRoTzvsK}+t$p#wP*AB9;qGfnQ7f`tQo)iLFLO6@;@xO
zuB9qUzN||7{_4VjL)UasH(uPf@59K6Yra}%n)K%Fyj5k#E*YugIku#_k!CCYeRb~L
zvFFB5O+0_<w&yGF&5b(Sx5o#cocyrLyzXm0dS^!6FpXx7Vz2Jjq`7|kYQ7skA^P3b
zbE>=_vEQlItgfd*+7+yS7~s%m8uL?>e)ZWpdrGQ9sieAnN~#;Fq&knPSxdRyuXND$
zn+@7SXS$v#v-`&%E_(hn`X^7%{@2!NLz^~@96Cj#*`SoK*RasL=ArGbMW#=#Fw^;R
ztMqft)4hGZpZRdo`d01RL^GgWQr$yG6#ts^eb=Mfl*kS9j#deL&?O`9ezovEITzPY
zT9oY5@avtge#IOb<vx10?wlayy<*RZ5tn_NZoE0Q*@4c1;Ro%*cb^D|3vyn$c>KM^
zXEyCIFS+ialIj#HsZOi6og|-M%Q+RdU+39md!zPQdnz}bX1Q|uk#&tm%s8;^Q>*QV
zE;d4UL<h0AaN-MI1t!kleBZyqk?@}zhg{q7dW#+9JCEEP($M1Nw)d7XpHuNK^i!)w
zn$GSKUA7-t>2QAGwljsVoc*$asdc;dn*z@7th<=`xsKxBHv<>m3n@GOr!=#O-4i{p
zI{iHL*Z$4wes^Tai12zhkL1#qmsHo%^VS8`h7SO|@4r#Mk#0#``L|~8sOjEfM(l+i
zaYwBxS*=?9)w;bg&0afKa$QR$)s6JLbqeiL#s#7tjGB;?n3-T}HTsR4Gq*X_*|Nr^
zgUyF8FZ*ho(}q?zE0<iSP)T)1tX9UeKhKOPyP)HOx2?)=iR=5*pkHTxym`{~Mt{uD
z9lvDFggGC6%zSJme%W_E(0qNe)#`SE2fy=+S$CuS)|u6tZ+p!lC7_W>&D!?onIo;(
z+jZBe)6wj<J?lQae>Z2duKpTJpG!V>`W3p}of422yN-7#d){rerh9BWvKndTo?B~s
zJ-tP{wwLqA4gBVXE;jE^T@d@n%+>{QtQ%77UGVfgYv&yL<Ds1yiz*+_e1C7(D)k=R
z&#>#8-l3n{#o6<iTglwS=c#*0qkLa@wyvP(t=lK{MM+2Xi4Rh%Y;Jh=mg8HeTb*dx
z<J(<!H_q3~UGLd^djGH&;}aMcQ1a!5>$rrN^AUxvK9*hDd>!ikd9}?c>)yTEbWGmp
z9$uZ+ktZK0_PW=dcJ=q8p^N7A%UIr28=txNx0oiIviB^xeJEnqrK3_7CDqw;lcBD3
zP`^hj->H+!>vh|wa$bxL(@05%hN`8@MAkyq<Qprm*}6tZK0)i+B8i^vWuz846j={B
z23a5JhqOb6B5BrimZr)#MBP`&rW_weHbXWwV~!=VIkFY9BeFFz8`%aqzbt7(>dG+|
zfRyj)bP12vB&pvcmGxb+RtIk-T*bVAJ&<X(y2eOe`E;|f)BH8wOCSQ`U?XHf0a%YF
zJaC6#m<<WA9gagjn0b*G-~cY*2@wzrNstD|As@`V$sgzf?hpzwAZu|Fkg1Rb`C#rt
z+`t*!ArN991u~%ktj7>PNce$xLk8r7O*ZpN1MrV)9r^7Jv5+;1G-!zLWZZ!(1VS_<
zKpGr}La?TvZw{^y3UQDEnUD|WZ!%}K1HYjVWYZvf@PJT=fu)cPX>c6!!Mqb`0#As5
zB;q6WDvRHD!N!UF0Y8X^RLBK+C+q@#5Ca<_8_c>8PjH85NQ8Zm4;Ec<1A!0&8|Ang
z#}E&)fZG#vkOUcE=}i0}5aJ;n^1-GD=OGy4U?b#!Wlzq7AH+jC<bicB!h&E(fOI$m
zg<#v8Yv2jdkN|0L1`5Hp57)sHq9Fm&;0(y3aXWB<49I~(aC@2jggDp-1z^p4(HWj$
z3*|YMXDny%1|1|qI^@7zu%WGY20w^_BuIyRu$DFjJRlm9AOrHjk}+WiaD!log%rqu
z95CZq%pP1I5M%-4QrHL?kOPHaJBTpA6@noSQsFq{gSi|2fD8CR45UB?<U%3Hx;GCG
z;s}Y54mn^xf;fUJL_h+hK^|C+<Q@S}kVWvRkPVtq#0NYe6cQj43c%8n@&R|qAxz_S
zc8NoX3lv>%7meKn*bc|xI#|AjKW~yAh=r_Z%4aI!LBTZ2aXN7`BOW^P3t5Ovo`G9_
zo0TOmz<7OL-jAFwhrL<k0kY$4{6!kp>bY=iSg&U{2S3YGZb(^o;*FFwe1%}Vj_)|<
z4eR)Fd1f}7OWcrJqyt3##Ptfq3k+-gEGu#z?1*O)Qr7zAVRs)=*817Z!!4NgV$B|u
zn$jF7&4JP!D9wS=94O6!(i|wwf&Xj{lp*+s57jtWD*8n<Zy{xl_mZYOzrzL_o>yz@
z=j+OxT=^|_<o9B(%RKkbup@3(@#6iVynL%>Ex*?r9m_h{Ek?&X`Td1@{54Y6$cj0D
zJgEMzg1?4!-E!>+=Z~w`P9jgMzkflVQ-7P-G9~~9W5MsLM#ohd9FQ?^gSmsd-&MDA
zt{Qe<FtTsW@9IX!)p7fxk$dCy=CwHglF_xg{MM?+)d{19Q8;b+-A+B0wY4@NrUU0X
zsptD3UDV$Lk#6d5cjQp@_Xwn?`g;u0U;SNlE&X)P&sMJ)ud5H{+<5i8gdf50N$Roj
zn)?Nui&f9ZA(yGY2QtV~(zW##_)m3F#%{VG-N74zAqseP(ZoRlY=m?;19^b{Ax#3H
zKSh%b1yo>1Q`|!+$as<`#K2MrE~|fUN<rF|!##MyM#zEd5XyVdcF2VSh~b^bu<l;g
z+;;(2krlBEI@k_*U{i^ARgiV|31C=PudRw3&_NueLLNx@+QUBPuNQ(tHQvQR_Fl{d
zSwr3tq<+i#a98kzm>T2(<b!=p(hISW0PeN;4GG{-hxb^Bfu-PFmplN`v(Q{i{6Pm6
z&A0|`5Zj!*ggh{FAbfBEZ5#Z8KuCZr$bn=>BwPnq2IZ0<3vxila0<bqGkF1a6tE)%
zLkeU=9@umxY>;_0GDfoxj>DPmxOFD&5DW>B0^4C9WWgE8gX|uJ!T3uy*z_VC5Zw^c
z9+@Gf?J6~;IZ&Ddr8!WV1Eo1onggXdP?`g!IZ&Ddk8^-mB+bZwV*S5gP{@<Z{{uoJ
zBYaz;NI>*!cd;_@=DD5K#I-cJs5djn0YScDA>knb5nB5pO|*kTBZ9^SO$i!5R@*CN
zTxd|Re;BH`?5w=JCi;5$M4)G2Ok{+AIP1pktOEUmLs=1SbXLD+-zOrNFvQKjXYGG`
zb?@D5-a*COLh>4{xq=*O&$|{%+IU6vQnG`k`4MPRVEMbUb~;9JQS_g)vUa+frmWR#
zFDq{CTnD!1i@T^LD{D34(YZFfh3U`reSD7T6QXX-$|?@oop;MYCcerV{G}XkwN=*a
zM}+zNj1zm+u$PDoR?df_5kcmASXuQ(M!+DGF#m|iu<^2BKhj@x2AEoj3QP~uc8Kfq
z^=VW5@A$~glWY9N&2ijpM~?5KUz0BD*xhh*RSDbcRYRmCP7aU!3K-8%C0tM3XTe(h
z&>8vR{K)Q~!<BX7LSMCfWF5U2hOIa&e(H^-X%#6S?;-`%*vZMeHU9#F#@k7Bl=4!3
zsO}yM%b8LTQZ|kBeo1+ClIwD==HqjcMSm)rfknz@ph>tP8~#)_15KVRn}J2jM$+2e
zum`T((3pNu8KgXYsf!LS#&vOgNN|Yn8(dP-CSxwe7^N;sebRB!P@klZNZr-fr_jhT
z!9l*L*-)yLq5N#f=s{|{C2od&XFD<mBW5R5gRKxq+~SIfo6+r}#L)%2#h6ENl=@^G
zM-PtwDvsV<D_ZZhoHHX*+%uw?L#_2vSM+;=>+9;{GLm$)QS&@eO;-c_Fo!zuJO6b3
zjPe{`Ijy9HBo}8MrA6wRAuYz?Xr=OEv>;{6@T*d`8`W^6)%8+~_F4KFq+E@|k#tHW
zE!s{<_y*k&GG->GXx+-uhp#kqa$UmyJ9SFJj=^2gu>Yz)HC6N7p0PSHS}@KJ=l)8*
zOLqM2{4Pm8#H!&+J0j&xQ>&DB=;Lse(*C<;AbDMYU*6n5rTQ(3-`lTLzeTBj3)xe!
zRKLalP5l-J>8Q1)cgk%&JNL-$o6Y}NIQPut1r0ra-rcz7iKAZc^sD|}`H{`OV(gv=
z7p>`kuO5t&?x9`MJrui*ko1OLIdt~D7x(P-{e8)aHap6>H9pX;TRWF!{v%rS9o=s2
zXBE+}&9@V+>Hqz`7G;hr>yJwHWel-@c}s_KJumHe5b{ST-@bU5(3*BA>(eM;>-s(M
zJqAzzVRX{;pnI!oTnem_(0ZJ$U2Is;E2Vlc{%X&@Qau>|+@7E%)q`=`QtGL-|CWxi
z^@sGIlu+}`4;8LHv<g~$w3a6Dd?$OW89#1bH<*3D`ii}OzrKuq10~$WTTh;9ysq5R
z)z`w09b0{L&V;SKr&;VtI$gi>saBQmh4B6Qzg@4!0;RwF<42cD`<f(=+*Pf~m^~f`
zzTSMJ#@_V(V-{{+?7H@ymOt;|om$D~f4}~XWF>x8K5VDGqK*3ebk{2>nK4bz*FI6>
z^sx=IUV3}t@8>c<%5b1Re_6`o*?KyzDE^sWSa-RS#kAc&ocn#%a{t?nZmny$Eyk_s
zo~Zp}+xD{GzLc>l<_(lYpGO<&pw{$!;{4;^j=mRi;`hRbZJk~AW%^WIR<+Zf(dE;f
zZVd3Au%uM)N2%VAQoSEf+Y`A|@5kIxHQ)ZiX}Djz=AHZ}Ez7*>e&fZ9?D4>8FM2As
zmD`w9Va$7to9#be*sjZ<>Z>fyepkt>*76C>T0L~z%ABTBy&wPF-pQqUKZ@T2x>WDS
zl!rY>^?0+%oa!sXZocx~E5E$8*^5EcQoSGk`-a;8wE9G?0Z~7Oewy{!IgMHM@A&Rw
zE$!9+eZ3zKmGOge2R?Cfd!gKelQmw~BzGINqh-<$bGtkU@Esb_uJPezSH5B2ALTvZ
z+4@1cE6>j#R{FB<*exHQ>R9m&-Pt+aSM5I2<(qf+5AV35^VktLYM$fc?q_^-(VDhC
zGvVR7m66?|+kMh%?N_fa88dzGchma)c;q`xCAXbxH}O$mf#Tn~pEYB8X_IrRb&UI3
zv*1Ae8G9OcS$AmErlU*l&3o|0<V5y9;-ib!RFe_0W5$PeEpsn_Rp<4KuLu3`acDq`
znHJaXe{%TJoE4_Ie6Ql2Uu$|f>(;V>@(VAev_J9Q)&8*#-v;bzSuf`2)Q`rbgq)d{
z$+v^InS1-+tZzg<{Gpe4*Wg8G+Qr&NXRS1K>EyG|#o>zwOFmAYwrB0+?A7<zuVEiL
zrQ9a?)p-BZ4$JOiQ>Pwjd~(H)9okp*8S{Ir@8QMsy6yaA`WW_=vl0J>I8X9jcjwjb
zU-Z{@zY}@5=BgHMn|9XeeeaN~Q-?QBP2)pjsh*RmDc&`Lj^s_XUA$%Rjd9%v=T{HP
zV?D4^Up5XgyFFt-?Kh*>HA$`AV^LP_r203;q;EP_|6cr;@4IdA<vm%cf2Dd(O7)z`
z{q}4<CvBAbJkRg7b6@T4F!tT9!^cK7*ztM(Sckdy>uz_7xVI^9{T|1~|5<$~fwY(E
z935ru&UL=yGsLd(1Tn4ngkKBE@P&?BMbS%g9m%kf?hhmrb9CF7m%=N6?t3Id61rcJ
z&d7^Mxh`{odLVCN-yYOCC(2wD36IO7Uqvz8ippNm;*Z#;YcR~)P`<f~eVN|DG7ZIO
zu_xcX>mh3*>my~p2lEgV_ul+g=T<0lF2sEW&bfma-0CPM=A~$K_#vv0756+M=)?}+
zw{;Vc<biGqlCDqp36l8gWbOu^sUPWMQRg}+`*uh;GUdh&#PGRJXO8qh%G?M(bv$yX
z&Rx)GIbYOWBkW1~8Y5+{1NrwTU(`7V#pVlLui}m&CnaB8kdiOVTX+<%I!B<`a0jXG
z8H!TEWeDk!JM|mCGKZ*We7&$I>GVcgA$^dt2WXm|i6$TZf7U-^f0cR#rFv*sC&mr@
zzpRI*IeI>lZZq!>?n0?vnt!ien&<}XV-88M9Wo&Y3c!MP$R2uwH$+1mB*8zb&nAz?
zUUb@|@_uBj*CvL}RCL?8H(~AGbow(ouRut=tI?$Ip&!-JHu786Y5tYYn{2MjzPO_M
zX5&}XDP%NjBXg0W11E<zNA%zXV`nxzO&^Zzy(~I$+`;u78t7}d;rG+@<D|}_zoSua
z4qf2*9G(x5fj{YW<s|Vt9g5SJlS3LsXHEj~ElzKa?5SLw?wq^L$S?BFSbvU1Kl%^w
zfCxx{RLFu{xC^DGGzb1}4#@MT@%sOUoJi#XZvqc6k@66unqN5gIy`_sz+fKAZyp3q
zpbVJ87d%LwgAciO2$=;(-~<@VYOeKyKH^?AN&H>|>mZ1*laU|8WS9ccFb!tFY?uf0
zK}-trQ`i6-VKa!iK$sWd9gY{ld+-*=ihcurF9R|8oVx<oK+IhpIL$~)Sttkca9kcK
z^M=ilUvXRkSrPVd&J~i0^T*JS-z#7xh#82K{YYeQ=@Bp#JHuc&7>u0n4G*9J+=N>o
zM%Ifrf#%Q(WUp*750Pc?!wkx)e)Z*CAAa{!kNb060j$BDcnkv%aDX<@6q<pUw#atS
z0XnJYMj$6ZxOzMa=?SmFXz&3)_!$3B!7pGiDg5rjwQeA0EHVh*P>(B-cNS0?T0v`Q
z3+<pII6-IV3f)2Sw}<>j_CofCzTg7=!4(F=AP`dpSrsgyCe(tLz!qvl9jFUhs0VBD
zw?6VLvH{W#8bTvz3{9XJv;Z+y$Z9a1^vr}g5CaR~ZFm>r;eA*N%R%;=Pe6VEi6F+<
z-3$0<4b|aAr~xvcUX0Ye0DJwM`K%iHe2_WQGH?AD@;ID;K>C|;FcZpgtvpnKiXdhl
z=a+++3CKv8tR4>|EDtq2x&8zGWy4AM9L~Ux@DrSc9QYZ2g<LoX=OK-BUO?u-MYsf)
zAs?=Q%%>OQO?qT~!XeUg435JIkoogRkl({~UP#v=&FSB-^7}V<6*scR<{;-UaeNu7
zQQs`FvlqWDac>1xIj#&9p&V2J3owHUP#$E_PFW}en@IZ>*b3X>JpNvTZlvcSvH+x>
z?0^$o{~og86#ULL6Z|-WEJN6){Fb`9h4^fOwJ;7sz+l$%dl&Iu01H9PtDGAO!(k*C
z%qRT*%;<P0zjwhG>N#m^5Api|EFs+U9OtQirgP2<yulX&K+IRjuhrjK$Rlu6J^okg
za(NzlTx1W)zoW~=nzU6{(<kZwPw8=KKpgCh;?a=b9@Lu=FcKPZ+!*XtJI#?Tp%rW(
z&HpMrFrD$gD~S1Lb;3xWCjF801Jce&zbL;&SB&(Z(kDs(QBu7zGVbL95s(bqVINrV
z=<5k-@(9fHi|FXI1$%G=XOJ~yNg#X1ioO_UaD@~o1bf~=<o!ek$HA8O3penFP*@5{
zuo2RLr5YMb(1HUvgBy5*g*m^$8-gJUM5l~7&-5<f0e+AIX^;tLK=jEJKwKr-6v%@D
z(DI%TDDMg|8{!}Z(jf!nJ>oi8Fj!^-j^GBfArrD84+@|+gMG1(0LhRK&8w1jaDf7F
zq+Glq6rw@OEEg=PcaGo<p&)}?agYcWly7ekokV^h`hyB-o15G43;-^mgMDxua^N}?
zf|kL{<{*Q0agYzz3_6C&z$3&#A|&xlCeLN&)R|C71L>n3!5Q2j7@{Etj)OVvuom1Q
z77`#C9P8pY#6bcC)<;4LY=`6E*Z_aQ6+9pU;vfk&LK<X4F34b~1=xTixIsFcfxEE1
zA=esF&%hDfAPq9$IOISf*fb_Dpd<7KZwQ7Mh=)W-gKTiK=NiO-ykn<B7My{*;L((_
zfKZ5r7)XM2I1bmL5Nw(eeGq*>xzM{g{((0HLlneAGVFsKXzoCMz-)+vBuIs9$c5`r
z2(qZn6_!E{IJV&&M1T&GARF=^t1a<x#11$^CRn%Q9OOXr_LLJu!EA_w6xa^O;W}7!
zAU$9Q&fp1A5Dyz64Kg4XWPsfQM3;4Mh;YI$$bf9f1GCQ5A8-U0@PJU54NF0EQ)faB
z6o7db!Usoi0Z#~qI7omLNP~Qk4+gg22rl3U(GUwMa0Uv%t{ZI(h(2o<@PKHDgG3O$
zNqJBJX5G0@!4~YHBX~nRq{2SPg931MCJm4U?mY<?jP)tG^rDPlBZyAxEXaYp-uT@I
ze<2hs`VuFIha^Y`^Ov~}p%4w(VDG{?$n8h``cs||4ABq^@vo2;$OWA%;Xw`*Lhk{j
z6*hwPK=KOWAQ93AVF&EpNG}wC-C*ty@CL^r*oO$n1?yM24pEQ{+o7X7VL}|(4JALo
z50W7p@<a|Jt;2~sxWjBng?(V=fgj)p5uk&NQN#u8J-G&+5C`dy1)^s@2~t7y%X@fH
zM<4}Uys-=EkOhUlq{ol+K!QK{1eyTK8ZtmLmfw){I`t6>!Qu`4h8(yKiNT~F3P3lB
zYp@SAlc@{f2{Dif=2NK0U=NPq46fh_qQ^Q0mO?IE2Te5Lf&FysKrr;4!D)zvbSMC`
znfN~oIh%5T&^g2(3czeGdHfdl+kEOf<b%rs@&){2$rnh20&rYNUO*@$LN?^V^|y)V
zJH!F};;2)Q1O;ICF7Ch?T)_kUAQYk@2I3(RQeZpmgDf}$nTrU2F%m4|Nh{Q~(!amd
zR%J7!yq9RzV;OspHO>t<mUo&u>iPQWF*#RiN^_tz2TF6GGzUs^pfm?cbD%T_N^_tz
z2TF6GGzUs^;9s5tW`r>MpV0pohQ_`p6#$|qYkaW(c)be1e_97%_Z|*W?OS*1&~}VN
z8_AIWcD;ZGy>r)1^u@<ekj$~wyb3Lw$@qh!pUO96+_;eOqC8FVs!QwUk>kUI#*X**
z(}o9zghh0FitZ|{^CtWfT~!Xq=J+{C^v6*a95P>5uggomjSVsx=Mxn)E^?fgZ%E|$
z2#x5NGQ=;gjM!!z1Pt+Wz^{$P#?Rq#{6s}sx2Nec`*ZyMP~!3T<L6+iMDI`Wll;>z
zDlY$w;`cAkzy7LTLHTYZMuyNN|H44x7gt>TynKr(VSOHU#NCtTaUMEzvA8m3C{<Hj
z8H?UDE!VObdm3aC6v0pK8ND7my+6S|;hdGaU`R`bGz6GPkhFw?)CGsd#pE?<G0JVV
zHk3Rq#np#rr6t++$+YPGc`_~WWr;kdXt`uPJ1uI>DS2A{Rpl~Jtz$Ok`n0UzUVVw5
zi;z;sLYYuV^YZ65#49{#oFCQf$)-eUOA^)gNbjTJzgA~xOEz-7xb%qb&cCW>5<RJB
z1J!yaZI84kVjrEBkpTfgQEJn}ez1DIpZaU#g8ck~{k?p~`+5D@n$mvRJn|zn%wPNn
z^AC><j!^1xI@fBG2Lnx}_=kl^S?TMx8m7_?D*7YG`pYe;_!o$jv<);-!_`+C<(fCw
z{uC#DQ>k3jKDwsH!{{2x*4%8Wq?3I2@(uR)86U}wBY6<THGOz$;?(f!bIqZsp8+9Z
zlYGMbyg~v3!u=yy$6;mVT+~jO|3v?=aDRgx(Z?#^q^&6chRK;^q|^r`kENJbEBWsq
z>_5(be1un^Pq-J_XU7GN_lXF3lqW=0(^|<BgFSs)A?<=-sDlX=B>?8wQ1|dwBWqlw
z4yG@8N*y$6APhH^=tHzAz79U>&$NG02koCy2knWIaa(7|e<{;J#neGbxBlAG>!7sD
zdV9s!!5=95K}L1Z<&k}TUstpa#&BJKe?3_Tb&uSt*Np0!^P_7|)<LODFHjbw^NBjR
zlxyn!tiKP9>Y!UuKZ~h@-bL*cQwL>k^it}_N7#*8_P7q#<5=q8AQMB~D!vZJVXuu6
ze}lc^>!7wW7BN%Qc5nhx`lrwpe_00|jN3s&Cna^TB<)~veblqsLFuDP+724(%A@w^
zIkkg^a#i#R^E_Cz4hE8klD0?Ts&zu{8E>xrE80PQcu%&2_K(6->vb`8&~Oi;2iedM
zJkbs&QvYnJAM^3==Y+>~P@0<O*$yUE#Y0TdzBulKlGQ=ucCaLMP`!8m^j!a}I#}8l
zKiLlcJNjZf>R%%DL+YS5@n2U5?W-wOQ1hMI7w=Kq!JH4DQU{ItV&itOBz<vl?clTe
zV&iA^XZ6L>9{nr&;?PI_{&iohPust*FIMyNiN4s-7oam;-^LZw4thLF&tJEL$<#kP
z>W9)7fAqKxKJUIb#adqni#`u}uPIp_G;Rk=QU{A`2cK03OP>dyYzO}x&x6gWe=?s}
z>Y&ZK=U)d6du}*X*VjRLETsF_Sb!tXgO=-+Fy*O+S4JP-K!09{)v+qQi=zMa<18{h
zV$LPmlhJt0#PZQO{ezOc7a8Ip>m9|k1sOAG2@(fwF>#Rjd&>I{cAhkk<DlhY(KyI+
zlK$M|IE+zs;Jdx3_pJg#hCL(=`AwM{rH_NU6^hZTf!EkbUNy-RC#PvoxhlR&d__KK
z9>-V0yGVG0Od<k<!u4ZHhPdUcaVv)%iJM?4&+N~Lo5NG%COKL1xK$-Q<G77f^DVZ9
z_#*q$P*1@TwAj@>5x0mipP-0v<H0+n4|Q^4>?PDE%-_p@LZnYHNmugA8Tq8qkFm&}
z3-Wv}V;6%=qNp?au@e39WaXXP5I>nWEyg&08r)@-Ab$Gx^~nfIc{(e;7XA14<Cm$%
zuN7WN-KPp@8WKP4$IAU@RI}9lEBXxbWb~eSe@K352}l3lt<OKXH}uDU&cEQAT)-H|
z?`OF$N)W%N<)4~tz2}eq>+gq>#BYdN{|eOjy?`HbU&v$KLE@MAMEpX1eBbagR6_0y
zsdj9I<TYk8|Hk=*zwylbRN^J~siEFU8)k?{bS*AmjN?(Ba!h|}Jme1j$KzorKm8b!
zB`q%VHr04E;5UykvZPeApZv&qYCNPB8|xq8CF6izl2OmR2aUt@lL1wXGzBvJEoD%a
zv|D~sv<@4Wfu#M(FrQX0Buv8|D*0-d^$APv8%bw7!gSDw$-}CA4AQqHQn!mS%04lM
zZ$IWldeGna_G5^LtN|5M7o_iy>~Bvzy!G*z<QuL;L&?vQ#6$K1H;#vKnq`fk7~?c|
zB&@hcVg0={7Y$3^F*@SE`X2Gb_pSo2c@RJUUbIi9SL~D5`xlJ9U&FD<kJ~?*)j4NZ
zY|Z2;TZYbD*Sgz`O^dULXAiO0@!^6UUqt`Da<WhJ%`X=|>=1n^spas1tT}J$B9m<+
zm!4sLrQ%<`YPCQAu4B1dZyxJeMYDFXy>F||RUWh(_fDmzjqT=~p1+QI%p88LY2eY>
z3pJm$wQsfAKc?!8fSX&-cpse7=(N9`+nUq?y{~c?JXFG6QoCmPzMT%Vf8mwX@}+yA
zSmg6eF+lRK%e>QXUq188OIB;sDwOVlQo099yIb|O|2OwQ`ETFbq@;V6Y^LMXnqKQ%
zVOF&tf1W&XVeK=CTR)rm=Em_2F2%>*cR0Io<LZ-JcbD#2vUcO1sqWolF5a55Z{5Ml
zdtX_$^YFPV@302HkL2GZm!Zo#Z>k)>^zg#v37@sF4!dtZw}b9`>p6L+z8%^8bwB#a
zc4BYouN}1a^56L>+x(OG8&=!fzE)}VgZh2feENygC(Uz)nw~`Gg<?<p!Q=<Kwp5r9
zQDwyDQ!Rq${t{hfWmdDR32F7hLw4IW`V?IWZN<NtEq_{h{`EIIcF9UPWOk^ANxn<&
z$|gg0%&Nb#b>$fiOnC@9tHiHx*7~VGez^YESyL+Re4%c`NXsetSDOF$OSP08ckiuP
z)9Fptv@8C(G#GQnyo~9Ds}^-v1$9g;%nwU1vbTxoz|fj{%ypcXzRqfY#owwOzMuQ>
zo3(4lmTTa-<HOO5Pk#UY&Co7%){4FBT{@?<4jN_s>eqJW7j3Uy9<puD@q=b%wmrPx
z<Iu|Yo3%if$1CFB+n?RpRddd**?A7`zWsVR77qRR#JHvBJ_zsIxJ!P@-C83xn#D@|
zeoVcal)7$9<v}+_bn0<y(PZ!7iQ7(kTy}NH|MpB`?N#N;XQiLHYw3M-TJ06y0h!nP
z-D_UyUYV2Avj>d%qA=RD{z~6-yZ5q|i1lk)Qw#IH-P1-kNS@oWbT5)&sm<T!J<M71
z<wX1YT}SM>TJK#8>+=7ey-0GEc4$^wdAoL|A1}+c{kWE+)A^uS&9V7YK04?;MSG^E
zUx%SQZ2zbBBH8RA`C>Az|KufpU$1F1s=o8@Lo+g3&D(O<F0a*)z~Rkr%)PO!4Z0j&
z7JCaiEXo*D{Z9K{e^?DjK0f`!Ba!((9PQn*j;7gy#j}6t)SdNYeZ`*jasTAoWo~wI
zbsu_rdbK6P3Wtnp^l5^_vSYVT_S%2njr!b+krJ)xY~5_@Q#WT!^s3`E@6BT=lgb>o
znYD1$>WH#+zFr%(Vh-)|NCrQ&rXP>5rLF$ezV6q@Jv{Z!3m=tTV;=v`cPWcz>}>c(
z!x>F_t@_XHF;ddKLrS_Q$O}%A-Zho0+&X-5oNxagSC=n|NU)yZf7d_w?3LGUb^gkA
z{%INc@>ZVP---Ce{VnhKk75P}MLw|G(ywFR!Os2#QyT@Gef8j_KHD#$w?uhvpa0Dd
zAMgBQl+$RB-#!Wrb3VE4)WW3lQEBfE-yfTJ*nAH!n9~&hD)rsqAA2b$^Th2}-wsHr
zKE1^kzMaZP9f)6_V$;b#&^?u<oV0;j)2S0a&l&vP*DVjdzvsd`7nbcRG`+A{d*H3S
zm^Y(8ta2j>|9(@-_cfoaZQ%p2&uZ>a&P9`#^-}k0M_1ZqY}#FZOa8B)H(l(2?jEH*
zy?SCt`29^it{*v5y4OePULQ}}>!YN5+m-GKQo1Kd)(GZ9xJY|7|8UN?A2|&e`Afs@
z6UN?aRwZoVrMY+8ymjc}iCOzb)fmN?R+?h(cGjZVx|#J?j@91pTe>I6Tn6Agl;_Ee
zGt2Fkq<vN~ZuVs>?ag7{Ya+jWZ}Jic+d(GN_qoQs<Bnb@#opkl*=ZfBeZOS+{>;mz
zdxGfZYczBFOa04R(D+5`v#I-aheIPv_XG+3oabHT{V2gZ?fAUe*DfBqoHhLa?>#|E
zy4OcZ_we{%+nb|4<Mdk7yY(X)tuA}(Y@5;f^}~B7E^g~EY}J=jyu-JyyQ1Cr`OppM
z7HY5DZ@s?_3+@>{?oRJMTYLwfG5KXh=GCdgFKOSIbh}p4SDW5t9KD0sd-nTz8wT&S
zrjy^O-$=J4uKZiGchq!mF(dXukGP{&m8@1R{%YOcm}ak?WBrU`&u0G+vloZIJ1eby
zLdCa-j<7!M89Ax^sKp~{bpIx;&xoPk=<-nP-OPD+wr#gRTG>p$V48SqOy+s_{WH(U
zI<{ZBar`&aS0r{quU}^gxAw(@b${EGduV;MzgOuV8TRMV^{BKPyY4!5I-1?KXWfVQ
z@8)dQ)n8-jbIIpUze2aWQv&j0*YPf6?<)DX$HpV8k!J3>wYJyOTeNF?Ie%Q~9vPA^
z&)y>=Qpvv?uHzD7&PNow`dD^p^L42E=hZf+tb6xr(=mCYdw6wPR|j38ioNc2r(OO1
zXy~GO{W6v})y8M;{Vk@+rtCdSZXb%6b?K;-h3JvenqHj!OSu^jx?bq=bN`JiBUg?Z
zw88Yw_pe8Jw^*IB$Z_)kK8Bs*Ta(tb^KS>-XZ3n{{_f5f8o!p4=eq4@pFT+rL*u)6
zwEktw$FHM{=PTy7XifX>7}oC2jfe;1I<<ZyY*pVXpO@LV+v1Z~G&LV&RB&s(hw;Cg
z@_h}|b#2OT(Vb_`IijVQtxT<82u4G<q+_^7vjZvL6?Y=}%&XajWSCB~8`&GV2l*=U
zE2P1HbzR!O%zt%V*}uepH`1c63scr5N&YZIqmi_VK`QyfkgKv62SYqMK9P#PL)~jg
z9&vPDNb*w`hGeKx$rtfgU8AL}-Flk8@@-xGW$0A#cQjJ`^+t-np-5wY)%8-(HNJNV
zLtVS1%%hh0((P#SK@6`G%AOmfQP-H`a3s}Q6NMa(j7A0{ry>_2XCRLvXCf~kXCZGO
z=OBMa#vrShpj#E$49T#&t_Ly>ISffRr3*wZMn)myk#WfPkxP+Fk!EH1wv4nuu0U2n
zet@inWLQjB7r7eQ0r?Tq54i>zfJ{cpnyvN7o5V-budbU>*3%T1er``$OQ_@4SJKb0
zzLNeyNJ)PH(m4Iu9M9zZHKe5fK2p+OmiSBhUqVXyJ0m6iuOcP=uOlV>Gm(=16-Y_{
zcBG{LYow&VC-Il`zk-zX4?s%#M<FHs-pJL+Xr!cn6H?N@1u5y5^+Lw!SJ!MPYdMNb
z|4YPQ(r+mLmK;ZM?1Gf^%l#nfC#_2PZ$QrEcpp;Ie+Vh*{{boKzk-zXS0p`>el1ec
z-wrA1e;Fz1AAywgPe4lgCnF{O=a7>AD@aNIHKe5fK2p-p#4RQLQXeG!eUXxW7o?<L
z)~Xn%UtKToKU@FRx$4Rs_TtLFX#H<U`APYAM@sn*LrVG2M9x5_BKfU5fRyr=a+mV|
z87bv|4=Lqelk$@CZ;h1lcR@<|dn2X%-$Y9J%Y859zXmDgU!U@m@^6Ne@^68Z^6!k4
z@^?nAMvg{G`OEz-<sXlf@|QXK#^tZhlm4H){~ag`b&js4GQXw#O_6pWrVaU35!oJT
zf$V^kc2nG`^J<m(wng1F!Ja%{@GPN|_JY3ikvnxRtTN9jyTYHt8;?DrptQ5*$OzS)
zJ-^j?s?6R(zaZ`?My0PpXu7HHsFRPvQRj{-b2f{H^EUQua3}T85h?Z0kS=vjXR+?2
z{)s!Of8uVrkvpw^Zk#g5v1oWBuqXL35=owDMj5&Deu_I^)t#T}&fmygqU!Di{3{yX
zZ0t!s&Ouf~&NXtE{uFnERCjKwyTL~8a#VK>iV1Hz_NsDT$6sya3?p~y{5@q}U(tBV
z^NtzzdBsuUDbGEIa!}{sDf85d*0258ll-KOQNqhKa;MIjQ|8hYb$1$jR2|J3WG&>6
zM())4Z^edp6nhfhF{GsLIMSSo`2X`BVnz23^P_>-2j*l%d`}ZiI%G{k?<)CWJDK+#
z5WS^=5Df{C2FIZgtf!D)AbLwfAr4X?6Y|0QP0ED^CLapHvLo-b-~pi!14|(p(%?Ac
zgLx;7#u+>z0+NUi^+A)x@4H~*gpO43gIGv~T(IoSdGLc65Z%GqVAh3rf;&V*BJ2av
z5p2;FH}Jo_pIGVsVbr-1^nu_C5s(0BkO!6{(Ju_1po3J%25Iyi!2?1e0Wv{!5?gvw
zufQF0c+L@>`Mn_m{?UEFWDl^cXug|IB|MP5zYP0+IqInIG`!xuOf-f3PNu=W&aoMt
zh6~94Ub44WF37%KvZvS6_VS8j0hsLN^^fe|6;DV1S9^BJeqF`w)m7X+UHd8$XRw(^
z*}!blmI}FG-P=Ut0#T3xxnSGJMB@&zun!8swy%k%3(SU0u;gXL9hSlwu;C%q9b#c0
zoPh!;HKjRFnggXdP?`g!Iq=WqfV|Th@BbG@*CP9g#lni0^lOva*5dhtV_9Eg*gLNS
zFW9n%rz_WFJ<cVr$@-y=9LwH)vevy7$D*U<eog&8fU=Ie1&HpT+kbJcs9OvC6MX{K
zxTy{=LJg2TOKL(bcnNGl*0&jq#5J#}er>AECzds_8##9sDf^y?-X?<)9U*%;J^-Q*
z>96A8OI(g%$D9}7W5~O>lYLZbz6hNAp5L;z&0wnFm#jaPHLq4s4MbOunA6z%5k&V*
z(eO;vG|PTo#(8GSd0E$9((`|i$A8EEU-@tF=R4y2HGB(VWPM&H$hyTta2O2dTN2m1
z#8uWUw<V3TF1kAB>LTlaJv0F^O_9yi-w*La*5THJ`sz73u8Z5IP!o1z$CPts>UCMO
zR}N&|qB&FmF>>Ak`?9x91E>g<K#T>lvids*|77iIBWSFilVdyFHV0ey13M4k7Tf_b
zcaguVzh%J51j?xH<+uUv&T#!Cd;wpocGHo2)Zelu^;bA&blezsl2`xg{nsQ7&tng^
zzq9|EgjsYCwsPD%<-uTfkr!!de#p81)E;gBsy){J*?rYy|Fn|snI>bXHX!4f3|%PS
zV?B_55DL7mX<{J(HbNR?KsMyVT`;3hum(GD23PQaK!}2PNQ4xSJ=iiK4+=mAP37HE
z3(nvQvKL!0$oHaHNPrYbgG>lzKsX-KAQQ5|fp^6&&>OrV7-Aq3?09GNgkXpQd6!Iv
zR7i(RI0N}$!F#0**h5Ef0S^d-D2Rcj(1mwPZ-|E^C<Jrf8|}auX2TiC2TKO{Y{4EJ
z!5Q4Z8)Wb=7M4O1q{2SPh3ilV<`sz(*n<nWgEs_2G{iy*YzKMg%z_-a4wjV&8|=Xm
zdV@PefDU3|DI~*okbUKHp(7Q;6|x`)3c;MQHamz1*)Q%cSTpwK0A0WZJRlHe!x`w!
zAZ!F!($;Gs7>+|O6o9Pm?g(*^2x*WF(sx?$OyLa?a2KRswF3umg*33V#$V_HvOi*~
z98>?@;5wiLSK|uXAp^3Z0Bmbeo)7~`kPbOe0B$z;4fzmDADIAo;7*(C2QpBb3}!sn
zSc3z&Lb4q5EYcffuhRl>u1(oM8puANEST1KLNLTY5~PD&UD64Oun{t~q`w|{11?}z
zpYj852!-Aaun)7L0PO6z4l%GDGQg!F`3h-}3Equ3hD68(>&CbPYkTa12gE@-Tn9}P
z;tvs!2pi#UbKJDRE(Ag>q{DR(1t$ruC|@vlpw5CDq=BY2Wd&W@knfNT+u;m2wk1s<
z6Fh7k$zzCzB*^MOcpb3=p`CCC#~~LIocIkgb{f@<I6@ZWKumY)0?2-55zd4K8Q}g3
z*I+3eccrcjp!~qqjqo830*BxiYy{a4%;r_@AGq$097>r${4nYV*bL_!6po}!M&Uom
z*jX?{Ln;)2_BFx*Z&(V+uyHhH>_wWv&KtMj2dR(?1)%Z44%mPlIDmExVfZ4!8=|46
zrT)1&N|n=8DfgQ^PuEeU?5ioyE@A5N&q#Up+JY>L+>4awq<4|>{Pw<jy(&_k-y0z1
znf)kIo?)!j<9$eZj-8E^@N$sy?BcCn4^YqdR*%;q<(Yd8Ql8(|BIP;J4B3w3N=SKs
zC^e-yP?`h(xg0Pf=zm=Qe{jg8ppYlk|A&MJ1dR^}QPuzRUAv2wi8pOGT4ri#azo7@
z$pJyWVIkom0TEjJAx*S{LL-941x-O~skRqNZi0eQ-~8XM>pwu%=aX-uFGIR+4Ua{d
z+K^2@se8GihD&;VNI~OK!aUw5*ef8+-`^`VBsj=-vXfItsDGHKWwvk9MQ=^XRdhCw
z7ya0NJ`q0jccQyVy6h*-V_jShTr6k(Sl^ZC{h?b``fGFxYD6c?PBp&Q%jkWQcvb{k
z*g$+Y8pk(se9(kQf3HA)pHQ#Rh_JtkUh}_B9lCP#7oUSyN*?HAUG)FsJTT|dD$-%l
z`6YQkSECt8-($#wFVsB9Gu8XUW1yx2yZ}3JoAccBK-IMNJTieemb5My=Yy2}G&S9c
za?@js)16Mb<>lj1U40I5eO$G*V?siLOC0YnjLJ{qJw=VTyx)nTD3$W!kyo<|yV~a-
zZ$JMCR0m2}lGl<?PnySdPRm8(ycXR|Vqah9f<t_{<3l-?v`kdfVp~pZ=-UcOR%O^r
zTD+foTF_O6-;xeQG3IeP<lgzKyw6hOE3W}^uSi=Ybw>Bx;~Nz2HPI(H$gkvi|5tIA
zZ^L4ErBUMC7%BI6`g4zS7|P3i!u|1I@>$y4C(Yx0cIKjSeUW<6SFIPaPrR7Vxe?_y
z-Hg0IoHhN_d(+1^EW%6QL-?ZL5*=`AN8u9|<}+CdKT14!(kObvM9-xM*VMYH>;od_
zoH=)pa0Z#^{gHDnkL(2mg|T6X>^Trap32xqHR3f>A1C@~eLvHZPQ;))Q|va!o(`m6
z^6Ia|pT1GQ|AEv=>?-$!q+jT-=0Sv1Fw7*7pJ8x?xH-J?WFGkWqcSaI@}DyS`%(@P
z|6<Ied~oBUJ|7;ZS>jqWZ|onPdz=rkq|2MgwddMv`gke%pyk*&A0%B>G@Yy#sCM?y
z$rzWnPC8$VJNb#1<cWTt;H+ZO>OVd_5`B{afnNSmLE#bM;!e^j<@uy>R?}J5%4&d;
zZ+5N&TXzt9QeNK3?zB>aOacPsoU~a|Z}sI89^n%asrWDD7)3hWi08*#&sNhR_8lMD
z_v#ZB8YZ``k~V`I8M}(c&U>zp%ifve24GzFhCOIx>`Dy7EaV#Ro^pWkHmjoVmyGIu
z(Y&zZiPMh4ll+h}e9~CXY{SWFnzB|AdjBLp+KD|m7xeg?B<oLkG_aUF68-vyJd*Ns
zQtNJpnugB!A>}Fc<74t!r!NC9FQYWjGrU1*Dsi^QUNPoTU6nK$mzUJ3je0*dhC0<#
zjYB$Pd19(km!w~jdGEKlf3k{+1N)75g@miO4|e~${n9*&i!=6&<6>wl-k@#|GNBek
z`YUZkCV3G{To?+`I1JR+0nybbY2BdIJ+<l5J5lP6q{~;eJC}+e$B{*j=NTPK-gi^e
z?IMZA6wP~wK~J_Dk>d@yuTS$olK<X%e;?(4do>={<pls!iDztS!^<H}EU5!(JbZ!)
zn_LeF98WJ-vU@mc@S}TJZd2ucm3~cszp9(#DCbSBT*-$_;_wUQ{=OPVX?L}c><203
zlZCwu?CrwdcGaGtEQ_{*&bZZ|d)x-f_^==DXL9YZk$cHY<N6_GByED&--rDNT%SmT
zLa@qxCJEBFnV~@;{1&@1#+(j^I8HROYsYa>zr}w8QeSqe_T|2i<7}g2vFD`jtrS-k
z&oD*Xn>c-2;ALD+#_fw%aaHu+<Mt)#aa$s{ztX-edwfo5bEN$=l;1#;$K@ySYopeq
z=F}N6_GFYfvH?=|khdJ7ug}U`q*{&sk^5HiX0P5ajp1H9TIBd=qhpDip^lp=Pq-S*
zJvDCft>-RnOx&ybxQT{TiJI~fOWY-XE|Qoh&7*e3jcdkbEA_yEJjjG}u6?cdTdDg`
z>wCnFY*dtun8U{uqNcd%g4EwHf9|i0(`DFSp(gh%)m3ASEF@i)!}RImWqrJH!u~qn
zANRjIhbwNSzj<`;I^(y#y?mTY(l$yS>GL2wBr?pG-ago8EIqN*7rC#_D(z+fV<TP>
zlSBO(Pto7kTCUNT%X!s>-c3EuJ1Ez}BYl1S!=+P~d%Wm<Bz0keK8>0$2t$r%s>j_p
zmOSdF-Zw7XS7IiB^wY1)0VZ9&Z~mM|hC4@J2egXKqW>P>J59?feZAz>qkHGOV(uMh
zypa4GXi|Ls(LeuX{?VTon}6#0V)GCGip@X6vw`GK0ddOX8Mssrfy4QQ+s+iea`wvx
zrq=D+ZwffSv+iQnSaH*8O}`nq@LovS=|82JMeLsFdDZFXslWDbR`<IjOGbp(yLlw{
zW#)a5huTs-1V{3w+AiKQ_{O;IgY&Bg<?)@3?_gTfjYG_C&lphq&FFPaQfv2El$ATF
z{*5u|n~v4L7ysq^ZX5VkwCfeI7xiG&grvmG1Y4`oZ`_=@&8g0oH7*@&K74uESL2*E
zw7N;-_7QiO*7V#P;nz|&f4pVHm^w?6ZD)RdcEYXUpY4nNbVH{<a#n=Lea(BAQf}9i
zhopSrZaH%G@|WJIFsn@TzWj{$ZaUf2d(X%D!PU3qTi)uL;@{_)5oH&2T=2G4`7LpM
ze;V}b%#Sxuy58uI`MKklteG(9LtY|&SK^m_=L5~xCtIy<7kKbHznFD5%5R-nz4^A+
z98v-rnbfTPck~b}aFcNV_|c`(z9z{dcU5aLW{<~#uQ%VQu{VAHn1!1cyRLnw<<EQg
zCa2h|@?kse6>Ze#r@LNB$&6`wzV?Y4r;lxz_0roDe?OP`Q3j3WLB-yka$C>NJ+k{|
z^FJ2OJu`VhL(iXgH?Dc&sMkCFs=rr$WV5g6mt7^?XX`(>qWEWiVcq3Q7SneBaPIe2
z%l&URy0xz1wivgjd!qJ_ZQIL!`%>n)3>N?Hg?!k(aN@e;)Nw=WnSNSvd(RD5j+u7d
zzBIhs&DY``?(zoLUkUeur{`Ha=g=Py?aWwI`FQ60d%ISt_uzhpUElN${oF3jo~Qo?
z&H8;;mp(m*<<#<fd(yARZcX}b&2G)Bd#1d&E9_YP*(>^o^T4%}Z>?HW^W6zeJTE>x
zwcloFwbff}QbQYWtT#M$k!4SZYZ>+KujZk;jS|1}iSv(tJNjP8iQfw!wsm&dm+4b=
zS=CN^Mwd@_x-r0e!V=~bDfOVh?uT0I5B#ASec5#O{uM8MFn#pO-!><H`diemH`*PU
zIqnx4%N`Q0gL{=NuYElE+cgK4mW_8f>r!Rz)_$KaE%UPd!sOMuT0b&Cy^dZ}YnpTK
z1Fv2+d-^u~@yq_>1~zE&_LUXp<*xO+68zq$EAuZ@o~hB?=qmQwKQP<b;p4;3uG?Ea
z-0{&|$E{_Sg_K`zQtz`%gWtVXV0WMIuP=(d{~i4dCDnUgQoXSCm2!K2`q4|OKlZex
zl$*8xmX5LYhxDJ6Q1i?W6|O$C3R--$mL~9gCwr?IKW<(}9WAN8^?n1zzr|Zmo@%_V
z+|t$8!jBzWeRR%*t-YsN>`6LZzw@b9mG6bnu9Z|Tdr9@o?&N!p)^y$;--=&O-FIbj
z)XjaTQwnTur`>bi(f5~02g2MYRXX02+v9j!v6tMX)v9V2)>m48a-ZKh&HXnmI@C<N
zy{&46dF^AuUfOx65ySR8*lJDVTU63ro@z7xV!Oh;a;^stUUKTUWksgxts&;0@1179
zWU@vxSSh!x36>Y`EM0!}&eb2LdU*`$cE0M(Lmp|hIt&P{UdtwREpMbRDee7%TJ!xs
z>hXS@gWcin8(X)ya{G&RmY$X~Iu_mz4RdMt@-5!WdP%sZL#I46{l4xeX-OGtKC@eY
z&BwLgz43GUk9C@Rtk*cFS=(6qtb{wurhLGp`>QAB#$VaH{Np`!cdz)ycJ;A0wk<f5
zdDJ`qB7=SHlyK{;U;S&-kef?Coowb~@vWu({`H%}IxQcbu)boo$}iQ*uf}_*V(;1d
zN*ni<_|>nyGHiE>^}yieO%5hkdS~;RJKv}8ng7L&|Hs~$z~z+o|Nn4@j8KF$mK!0)
zk|j$*_7FnG7L^u7n~FlX?F}I`gbYInA;e@IOlSz9A=?Nc#KeS*@PA*YJF?77zyCAO
zGtY9)>-D}r=RW5;=eo}KTxY+&-)qR?VaIFKQ{u~yH;-$w-KlGC*|zmk+MHeVxZdDm
zRYxTJC&ZWML5BUiXkXt&SItAK1ShXlS+{mdur@pRYU!p!lMk;SpStGd#&x`Fkn6#p
z$91kDA4lDOU0T1K!L4;MO}8)DYCNr1?Ch(Pj*d9n?_Sd874@cU&Ej~I&qIG6$9lh<
zZ=*(a`wo5G)kKL`f8MO7$#u?G;$A|ndTFusm!>_3NvA&>b)!<zt3Mq6+4Z;2^iOPx
zYc_i6`7PNzFEr{R(#7QbFu*&&;$HWMUq0H_anO!wXQG>)-_ycu<o3a92W~&RoVHBz
z`BeAXo0*xK$6r)%Z@KSupC#d%*Q;;U*S-96@ZnLXPwFl@``;6X{*7#x;wLv-*p@H;
z>QbdqQgpkadm2SuoMrjS&3Qn8dEGP19v<U)K~DEFXwrGF=e7IV?$T-L78Ek2!_nj`
zTl8~lm*~=N;{A>#HTc5I>9&mAY20Sv>F*bm{k?eg?YoNo@olN^yN=ws>2j;jMr*Fm
zY`^NjRm)=wPYi6eqRq&`k1OA<@Ylz+pDX9P;f6G#lR7%BTq~YQ=ANuM^>AIw4X1~0
zKezP7>{kcJuP%K2`@+Vx7k(pZ)n6Bf{_lz}|Dc!HjuD#veY+p~eAJiQAD2AXqPj^+
z^9}2h4u4h6Ai4hNwi?k6vINiGg-KUgzHb`7P*demrR`(aE=~IKjqdmo(^GP<B>vR+
z?!Ex0q~BUBpGmwvd41X8ZflLkp6}spU-Z`^sh>{>dSbt)+piby+#gea=RYTI{COj>
z9sR5Voi{x1f1#qQy8ZL9XDY91XuExHwazb2+gP+5eR=Y(zdj!P-xa@ouY7!*>EN1s
zsMEXwjXWDp*ZF2wDPv9c$;lHFeXq=^cW-It#s_>ylb`b*`7|>+d0}Pjno=(xI%bt9
z?Y&}qmoi-r-Wb1kL)e|F=3}@IqfISw=wBHJC7JC$Zy9pyneojS7x&X?j{f}~%_}*2
zUCW`ptawMG#AR3FvUkkk{jXeKHlEQvIHSb3OY}RK{Iun!*?e{HZs%)%ajO2g(q(J3
zoY8g!@iw_Os8yF9Bs*uBv^`rhvsqY0r?Xot^&h-tUy)U%r#kE@s>Eggqqyu!ymcks
zx)N{we!%V$mo|+4<&M>=$)jgKJ`#NDLDwDKBMpiDCcn=frGGEWcIa1L=3WtABdaW4
zF(uYfT`t|ZNuTH6CmYpQ;;q;3u%Uh{NA>5;HtkOLQjZBgk+rx^_QZM%_~zGLoS#?i
zzwl_D+v#64L60l$PWX20xOGQ1sG=r5%UD%x<kBIUIZC|sNsIS+NnaVvns}*YWaYrH
zTeVVKj{jebxBi58lxCo9<1WWBvnu|6d_8<cH8kUpdZE0^=X>qDcx&3W=5ky450`Ty
z9nHriN3;?;qQG+6_Stg#<qwzhCY@+A=!5ckSn@5foRrt@^OMUh)-D&WUG8h`a#pNE
ztzE7@<08LeD6b&pftZnUe!(cWH_{}u209t7jZQ)H?c}IkkFdvw<tFB&Myz)kD%u?^
zFR+|OyIjLhEH|HYVtW^$qJ03dYvug-WRl;`Rc`+(^3!3OXmcWl5bbhbp`!iE9JDSv
zSG#<wNThAwDcYinjpngRj&mkvu?-rrzOtw}imf#~hKM$M8a_eNULh||G5b!#rx~%V
zCI&S|52NHM$7$s;LUV=x)D2BKO7j*uUTbw!B40IH9<71aL2II|QQ8n{s9TZ=>VRTv
z4K|n92F*MaTWGL}aB<YIPlYR+Mzp16`(^vMlb5zVsoc&~Y@eua_8<nDe8_gCerpW)
z-vkx)sTnHjG5cSRqs+F;ajILQPE5z{^7iwoR^!KiUUkX&MKG>y(<!(06#4ObLH4~y
zBwnS9rm}Jz=p87w)a*sA(W5AzOf~mV9_2N;Xdm=7+7A`>>5mHg3_u&9U!rE{V6;6t
z1Ql_Qhoe1FC$taBZMj@N?3LfnQf?0=%2$+W>>qg;N;*-`#Pa#|S=**jZf_^jtC-LJ
zkcWQMBe6aGQ7+43o8{%g7}vH#l-nnY<)}k)Og}`9_buvw0{O5F(s9%g{Sh67o<P4s
zlh76DDRc{Z8a;rXLxr8rqYu#(^cVCZ`Wu>x7Gt|Fp`u+Rb?@!=Xxj;Xa(jkow`Zt!
zd+fE_qh=l2c71YtKe0VE$j6ZBVhCWi4muVU$Nf08B02@7u86jC8uq2wevJz{6AeUX
zp}}YfIv1UXhNBD6l_++U;~g(Vv4yk<J&P_y@1WE-%`<cvD$0nh<oXbaHs$|X)C!G4
zZPE4UaC8Ieh;poI7NOWyvj^RZrlZ?X;p-HOK0>#nzoI+P95fy+O2wh>YDBxoeW<7}
zqJC-H)qS#l?INA1Ut)QYp6$+W=O(v*6LuB$6E+dUP11?_bsL?IW}w(ex{p$J5xYP`
z-V${{L!FTxq0|A1b!&=J&R@~uXf~>gK1aoIl!I17U!bDB-Ah!I#~QS4+vGNHqCCZ!
zW(i_oopO0pDCYzbGePqdrLJjCv7QoWHcDRd`ouobwkeZDTeA=AjXvp0Gr1gE4y8WH
z=bZ{@J^oihTcAd0C)60VML$RFQMN%d8m*4{p*2wIoKzDP$4_lk9E+SYG~b}KG1RO>
z>!IvZsR1g^KMm2tXk%2=GtMcp9f_f=xxxSDsHktPP;4n#pc30=iHdmZZBfnzQaf}V
zN}bbeLOY{7(XMC-w!b?n;zV$6(ug*9;=V!Hy%lKNmC5bRgq?Jl)&Ru7IZduNVtoeu
z7wdCE#ri~yhe3m=Gq4&CK^pu!$5Q-Xi0_(8<*-ZT+6T=mb3NdMH-mjvWjy~uiRsFH
z2=CNH!1E|b1br)x9dL(mI0Tts)Pd>X31JWmX`tVc>EHt4a0oKMkduWactRu`f~$}V
zRXQ^d>>(H;VLx1jT&U88`Ct#h5DEL?Du^2v6R?IETzK?3;pDQPb2$l^<WL5tMZtbZ
zfgDIAZ5rf)Z8xr!5C#d54ThX_|JP!_T25r2!KY%W+HvB~kEeR*Fvp69{jG!j(CDee
zuVB1jJk{7E*t!_|syy)~&_9Z++Uf^vUYz|mgY}kRAA-qD){okv`%y<U2^Fz$;-*s{
zxBv?uFH1;c`4r~6|IEJT{~<^Roms3GRikE*M!EklF;;W9aThUfQov|7>i|P8DlVYQ
zMI{Cdxxo#96llc-CK8e$7fiW8*o%t<#6SvUfnmoYk{Q^7FZ{0#McMFz@&8I<iUw8K
zkJK42m<GkU0Vx3`;WNk|W;1U&h+zym7RGD;*J2$ekU!LBT*U7g3`3v}|LcOOHjVKA
z5D!Gc*YQ5%!q?;*#)Y5cx3Cu0!Ft#Pn;`~7x-F>iUEdBnU?=Q???Cu_iggP=;r$?d
zMTOt0@U=~VV~_|UHsFuwNf3UJ`NMt2h40}*)*);mViF0zl4#NkUyNUvF52rCq3kai
z|CO}D*XkMLqJ6sXbDHrv_wyjqzh=7dlMoNQFHzxJP?T}eu73%Lw)djFz3>@(LfRK_
z71H1u+y)VQ=njas=0&lkIe8B!ulzxWX(A55Io2&=^;`fEi{KLJr;u(&fwU!9Ru{zZ
zkH#e{7_V+Ud2B3@Pb}j*3;f^9_(AReqiCXb{3LoxJ6?uziMTXk_$%VniI|Z8Xso&l
zl&7M$Orl)>%Gh)dMSTM?G-h9R!A|+U82@OjI&u7pxN@S77dEz>4dn=j49EtaA;j~5
z92+hajfX^t<s_q{;=B!Nh=FX-;d&+Fx&?r^jvazzxC$AN4dQwxu3ctao2<YF?7#)W
zVKofmdgKDW5DXC@Vz!BEm$+`FLONuD9@ipMXb!gE3F5&m5~3ji(jXIbc_1|bGq3@7
z5WdM_(5e*cg9dtB|G*jsK?sDyYKVpXkOVoP!vmcmn1L18LJ-V=Fjx(-a0sqKCg}3e
zYXqjy8EnBGJRulDAr?{~19Zxg9!$X!?7$uN!yypyoJ5Q!I}ov(MEocbQ)&i;K@227
z1m}-5(4$UNfmCQ-k!2wm_Cp5bfN3Sx1-=kuL|GsmGP$=Gu`@*s&0vUu{h;Pt=nEQ%
zq#ld&n=a=-BS--q>bMzLfnjy>1UpE8Y|v3-YY2e|FsecR;0yV2)H>H>KEy+!&{~uS
zazVsVbAfP(f^;ydO+H`;ju351SwOcQ^S}~(AwN!<4fiE8ARZDyJdk=qEF1#ehAacV
zAYK$!X+)k74pETYgu2y~vVd<h@&nP{Hyt9IGY;tx)QUVI8PXu6HTPbS009={4~byc
zg?SJGdR?g};0V4D(~bQEy4K{`6Wf71SoLE45CZ!l3#8txuMcX=<rqBsk{4uwc-g22
zMqmPFU<uY>2c7$~J$5L}fYmU9x+Jb;15t7P8;pwUp9?Ck*=kf=^GBlMn(Tp!>vI=W
zTz7k-V!2VMxR#4JV?v!#v0hhHq#uWhYg}JcTz`9`;+pIZ;@WSIifgShC>BsGpjbe$
zfMNl~0^BcQgdtK9uB2R(E$n^#?R`d!vUl=wY0;eU0`^`W-lGXw=jv%s*dc%WvHaTm
z`#IY?`TB~{06!=1kHi0YIR&`8`uWM>|Na|e{~1eq28+3875A1ZX{^7ipM!Rj#Wx`v
zgDr;QJE@3#%sn#CKVoPDC7}g;&$5oGMI~nC1;=wE43mS4tFw=bhzcl23AE%_ZOUvW
zd)BXKO2{8)SK=f3c&qEzYnSIs&+X}_2CMB%&5yG*g1qwM-sP7`#N8Hy6^Js4vWYUq
zepDt`?|*ig@?+NM@jNJo${@;Q1V2(H=~4kZ`S}oY=dFoEydfgZ<k<rG#PBZWmM(L}
z^M8JP8W975Tf+QU3+^6n0g~|H|5Cf(LbT=43iEi5qde+@<q;u(T-o>DP9t5tTyavd
z5MeKz$NKs4$02X7hqsGs(4Uu4<eeYqZiYB08MtMazj<~<XOXwrALs2dmN;{HnU3`I
z8R6vl$92fU!o%Amz=Ke06ELEPV<Bw*@$k-uYG!t%9Qm;o^J7xv)iH0^K<yq8aXUgW
zoQCaa&NA)t$}Pv85bOU+UWZ437#G_u$d8NHyqK8E^Ad=9z$2wJjz3|4@wOMNJD)y|
z-fg!TWhl7aqP+Prha$A)<#9|tmx}Ebk@gPdmsgJW<nH9}@cwz?_v41-#aR-0<i~_l
z7iXmmJo?Hu;SpL|L0#6rtUWg5Jl^fi53-W??WeafFE0^8L~LVTOs2eJ-o?Rttfyz*
z{>eW^Q?%u9(w4&>ZN#=(eNc{ZKBHYfRR(L)e`1j1zf_|Pw#>XB*9~zxeRswa%jCy7
z$*XI5F%|Pqx*}G|lDslVV!p6lew>=lyz>!56A<-@M|0^4X%6L=nE+T~&*ZP`&-RNr
zZ&<O8ymI)uF)HVmji#|<3hQfKvjgW6)nDgBU09#zH*&s9t5z=2we`ss<$K1J7<aPq
z)ZqRnlZOS&?bmg|z{*YcC3UC$2G^Lv_$dF?zQ=#HPjTJOVmlNcV7CPS=?$WH+#i-U
zC@{{Kb{*V^s8v<sk|)%dpJ4f)>jV5(`}T_O-D;KMvpaB2H<QEH&U^mdKD%SM&Z$*b
zHtEzkW!vS9M@jFl#nw$4ll)uu=Kbqz+D=(qbNH4KM<)IE`1XqS6!=E}Wj?#h<@E(x
z4_MY_d+G3qGxL^5Zf$7j_tJD$OU(ttnHiUl4{0#Uh5IXWk#EGUmg*Oo3w}=3-5mbd
zAimkKQfpq-?7D8tW{b@Y(gvt572e0Tu(3o6>x*017$JrA%@^OA)qkOHZ((D9{9Qi4
zg^eZhzve4k*jOjk`HrGi?cQ3>W#Dz|H_bxF&31a+^sZly`I5Vpi^QhX_uON+Vt@^8
zAb4m~tAeMtifdPNwn^G6!!|b~t$rT*rS00Z9RDxf>IYugVl=W`;bWcrT|UKyjj^Km
z9=|f#*}YZQzE-Z;lj^u#?|<rkm-zd%KbP;b=N!AZY47Wy7Q+Yqy4Kgv>eBAZ^P)-w
z?O!<XMCj@>x`%l_p4?W{mr`A~xrW|POZw?q|M_k)6{a*i=-j$Q(8=(PF-EOj-R<J|
zK4vM>O&arETHha!HaflJ@Lk3CSn)l+o%3?+oh!z}+P|Ezs&#MM>&^P6P3zTTE-#Gg
z^RTT}S)8zJvZ}}y!*z#yKb-gLHodK5=l9OeU3F&Mg-VT#%lyWDlZll`H)`*=`};B#
z-{YVe`*hme?75D1>+*f)o{=#VdQ9&-a_F(@-zvVxitn-FdpvCas0r7(f9cdioHrtN
z*FXBQ<H99XDrY`DyyH%XxRx(;)OL^8c^`OH`oWmYZ)rm+r<-;lDd@oF3hfl%<7o*^
zzS%y7wvjD`{bnYWf9Pwvq}0V1!3$r^T{3NG*X;QHtwud;Tz}Mxq=Qz|X-6vCZ%3)a
zwZ<5foKwbE@jYIsQ^H$`v3z!=5@UIQBkc-l6Q@=^Nn1FhO1syMji%gHt$sQp>5kor
zX?H@Kw}^=KJ~m~=YCg{V!beWEs_MN{)qmZdetKiDtHY!i$4VYbjAhyZs#W`PELxvS
zZPu~+o0mChJ2W-d={wzbdfq+PHfMrcM(75fQ3@OD`0t8MEXmJXN-Sa3^9!Sb92>5Q
zS=4+-FFs0LmhWTR{Cd)EdZ%u44z#&jcUW46&F&jcU82kegj)`3a&zaVQM2&7rhPB5
zqW64h{`_&kE3ei~M*FSmTIRc=u?O@v_mnEXN-SyH<nTn<e^!q9pl!b(w;c%MyO;P*
zZUSO>j=PQc)`mZ@?4$Y`eZqe;(6%v<+a7$l9Dc*{aw=4AFM;MSr)>uyw-5MmxnH#T
zWuf95_TvKiX}{OY<%`yPznl(yq9(cM3tc0=@AENF&d-W*?YDOM8@yOfeC8G3cEzxP
zbY;+JR7~51TA`a!9=&AW>HKnQzgx@Svp>v#9_fXh=A+^}_X0G3IqmmjNqkqfCG&#z
ztwB0o9muf|ME<o3ET{b@EPpHha5+AE%K24A#W!S{)ynya@3Pu&xFRlqoL_O2R}S(}
zN4s1-v?f#PqaeprXoNQ8zdg$MyYg$l$BOT+AC`k{mCM1t(unV|mC<;%@xRsg^-vMo
za#OkDM&LJ)N?U0VzOVW{iu_ypzBZs-QS6r_NTvejfRP3D0bC#y;vgOLIZ!RZ1wtSe
zQbC8x(*W!s7*<09WP%>o6H9Q15Qr83`QGdf;UKlAy*B)(`oAiEt@seom?Ir>A%yz>
zpXP`EM}D~ZKDf;_)Ll-*x#*|-Z-wvepZVR|aja!?vMsFNZ9$(~;cxp#zP2Cw*_s-2
zY<<Qt3qfE)*`v@n$e6|Pi5B#;^`&g_Ac8V908dB;GlDY=f)I!UWl$`jSU|CWVuAlW
z3lycu1^xf8@V}Zq?bzWn$RBDmULQnz&$&EPUapeYj`EUWURy}vyDr+KUgW=MM=IJ^
zh<30S_%D`8MMc|Av8-r2IUPis^V3Wh)BG5>f{tJfJ)jr#fqo#CaRql61)ksyz7POo
zL9`PN0@2R<LU~D=$oM4CfXGj@p%!hALt!3-foR8{KZxa1D9?FqnF^Nk6w}0dg|Gi{
z()|d@OgjsrUHCb)p#QsA=U?puFV^{2_`(0fKJaX7MaUmSL;CU{24kjwUSM8z#?{*Y
z71$@0Ab)7axViTKDr~qG@`p;S&q%w@mZWK|P4`#&ycdjx@K?q`5PtNcP8ZgXzBwBm
z3Wp#IByOqnfY@Gded?_k7jfErAsECxbp#|pGNgj=HPPdMt^%FG7VN<t0$>KjKs+RX
zCodI(U<QOiB*a4sq(LU+fED+NHZTZ;uYMTBKq6#94hTPeHCTdp-nWM!m;tLH76Q1>
ztwMWjI}rZ*8VH9Nh=&A7hBVOC#rGT3U<Ov;4j~W$`$5gi6JLmg7)a#)RksxHX+Z8v
zn)fzlU=N-keC~Zg16iQvC5{=)fH+8i&Slvb5D$qU{Dwmz64F3;^{7F=9BIK0LSa9M
zzKL?dlDg^(kq`sf_{ghy>0t*h5CZ!l6LKMf7a+-?!~MA-*g!nwg5KxUBgg_Z$A=l%
zSI3@k2y)eIZw=|K|GQ~T#=#eK>hKH>_TUMIb+G~1LJ(wtktuZyQlUyc(nEYR$_Ba6
zigtlBARJ;_@jL_BkYvI7+ptcshF}N<JD%l3Arf+Umbc|OJ{Us5u@l<@@et6NZH6>3
z>O$Ru84wN$kPE_(-LM<m0vZUhW?4uCqweGjgTMuRAs9j+99BbE50>Nob{Hf>CiG$-
ziu1LID<ZB}!p~e>huWj!{4dU9;<{A|gr9&FDy|znP;t)x92MzB91w9`QwGHXiUkx4
zC>BsGpjbe$z<-(rxOK<RG|&J4|I69m(`RH8GuhQ&62AUCE=b95jZg-^&2-;lQZEl@
zKOcV|H(c8L)l>JvU)4w5!QbE2YlNq(pPbrHw77H*bdd^K2+1|bRU5D%z{kha-+r94
zy|s^jz@Szw@}d{mdwI5K-lz-rmBcHM8a2{R%`2{xzZbby!;e1@)$dtUDvB$<pDPa3
z<nQ3^<0s}<WWE}W&JpuXf?S*eoczaou}yjg++Ir|+T}!t@eV-_-cH`)o2+)7JqoN-
z&eWl)Lx7WqC(DWDMZU?}G+s{rqaB)>HRl%l?ebE=GI_f?`8oJ_yE=>vAj#V_Sq1ZW
zo5u6KG-=&GDu=6sr>m0->&Y+2A#EDD9C)(_@Vzg8o>{?iI6E~F`RC8GEm;00W@ZKF
zS-rnp(}MHD3g%~K_TD;I7n~=`QZT>w*U8h#yM5?e&=yS`e8v%!L1da=R&~Mo0f9d6
zEnCn=W7v%&@_f@9X=4Ed7Za)ZzK`;VDQijY{nhnKOFVMRdsob_C>1kknK#WQZ<kZW
zDMTHnuli`ZgR_r!fQR>3S4O<Ne5gCsNEcgQUT1;j9rE|Ayq>@>KAP|1D(Wj$*U4qn
zSbq#A@{9dAU66x^zrzGqKOYAlKUO+Y&M*0Q(uw(EJz2jq-^1HYUX7^pqTKooJ}Q?R
z9_jw>TDz#<oA2i3#NHF@pZL-APus<@VZrr_<=?kU$wnW||D;{4K2G;ZyZHW2x_rBY
z{m%Rk?Q-bjbZ_k<{M7U7r{nu|ySb=O`R6B1!Mdxh+oJO4FKbnBzPppBTY+W63eM9m
zD^@O+73VOGHec;IOjM7z>(ywF3qp}NG%;)X-tl&*;CeAieuDfmI~JU;&DXq1)3@8S
z`cv}@Zd1Wy(i^K5*rwP|EGy!w<ez)93ND*>Ai92d?zJtLCU5m`Z8GD1n}}Wh)+S~J
z^X8OHwr{t|vEVv|O~kpR!2INb^R?v?%jcI{D!A^v`AzfB)%kW+7py1VJ^}t7BSjW(
z%aB%Z9RcosuKw;mo}BFSmygw!;qAHJA;8C%_c{4>$yd96dA_Glptw9|vwmA>K7@0g
zYEJzkfq|ZbqJQo=YvYLpBhFWww`xiG2fy5N2yUnQ{K2#Gyr+}XJ@2(K{oI>f!^`_W
zPkLJR=AeCztt}USedWz{o21&SC;Swd*Op9Q_w9L9KCg;xc>_937ef+NROl&G+^d{M
z#X0ya%Ih2H9Lg&+xqpw((Nz9dM=zl!=w-AXdIc31nx9c|oxP6oib_gDdDSG{KzThR
z-9r1I>1coSE;<m+K!>9DP$%>O>VamWW6($Fc=Q)^3i>NL8-0q-L7$-u(dTFcnuD%D
zU!dQhzoBc<SLkN+HM$)wLR+?7Xi@Y4D*Bf=ii-Xvu#McGL^4X;X3Yh(6v{S>_s1Hx
zRVt0%M)lE$r~yiu<bEZ{TcXbk4SCA_OOTf&`j-&>qf|s$R_<qlX>vakl~K@CMMZxT
zHBiytL_M?$N?#EY^E6G+YN$D?MhVp|_dn4EHQ|4ERP;a53$2UxM@`WoDC?5@^Z5cD
z$^QoEXq0tpd{Fwf(fFfgXdv1YorE?+r=p@iiZE34Lm}Rew?S8<ltB}P5-wa5jS?zc
z6N7d@<4{6?Yxbj^(L*R@)g++Z&_vW4O+sl7p%L%fZO{~yZP18!@ARdkNkeVX43s`E
z<bG1vHcb})2cX&LmuL<;5Y0sgqdG;2!G-FgqJJ6j4&NRX{a_47jZg<vjXI(xs1s_6
zI-?Cx7t{=OLz|=6PSXl?M=eng)C$Fxn$D;vYK?lKHYm2$^h15oFVQjRKr{e#K*ypZ
z(Q)W#6x(b3(I7Mk9gj{zC!jOYiRf2oFdBwx&_(DpbU8X5{T7{pu19C0vFIE$9-WJR
zkA|WN=sYwTU4&jl7o&vOk-kRL&?V?ilzpzbhb}|2(3R*j^c(aybQLP`kP?Ne&~>OT
zx*jc!Za^!b(P(9KGg<?ULF=Jg(8g#i+6>)}wnTTJZBgoyrVF|Y?S;mp1JFI_Q1k%m
zj2=Wsqu-;xD0NN~fF4H2qY3C#^eFljdJJ8F{)jF{PoOK%ljvGB3EhOALARpGXdHSD
z-G}~!eve*2kE0jSGiWNBie5r*pqJ6x=oR!4dJTPo{)|3HucNu>4OGN$zJ=<c>8JsE
z2d#wOMXRA43z}N!J+v<R05wA&qRmnI5Ykwnzo6|<junj+`V6&3pQE<u3)Bw%4He&^
zICeCS=quD6eS><UJg8}WQPGxIe5(>|i6@~t=q!{zi8OOi`kc|sM@yoM(9h5%D94^=
zIa(V11}%fGLCd0>P<?bOYJl!Q%cFZyj#bSOv;ukpt%#mOId(M{(8}m#)ENC4<r|$Q
z9j%IrSl89iduUDcF<J|KftsMN(b{P7V%#&MpP_Zpawz8jO+~aGD!#upL~Ejr(E4a&
zv<Yg4wm_Sr;u~Ev)C%QXp%LHfEYLw{8`J^ioS|_++o7Y-_NX_?IYh$)z0?&AM7yEm
z(e9`Q<@Q4}4dtAo`3miY&PRKrU!#4{<)|&X8XbVHM>*$cHldtzG*RrvSX<hfK?dmb
zr5^|A4DJvLv5*8Apu@>l4VEwn0w5e>AsNy^bVQ~GOR$F^2!}XGfo#yXqiq}5fiHwY
zG$cX>=nbG99N2&-D1%}F#R7^26bmR8P%NNWK(T;g0mTA}1r!S?7WhxG0I$T}YyZ!y
zoxFkXo8lX%7{sf1F{%b-P%NNWK(T;g0mTA}1r!S?7EmmpSU|CWVgbbhiUt1jEI`u&
z`l`!o|NnpQ|Ia_b&%=A<$2|Zt-PwsA(BAn46mb-O0p)3DnC`3lR^Rsv=tKW@ULF%z
zqq>uim#>HL4Jap>7&thLb9QhFAg>W)16=)SXKiBO?&|4F6Ym03Mc;cS22KH<<RO-!
ze?o0<Xzw~`%S+=Q;6giY6N7>D&E^y6PakV023>u|degq2{`K<Gbm-XqPtxS|^Vd!)
zYasTzXbU3--{PVjIPI=b)0+HG(35B>kk`c9A;8&Rwu_~+yOUo#kzVvSl_*9&9^`)f
zM88*}ecwvjRrV?3;_6S6acwbK*1&-Fj@o|h{OQNd0p|r*Pq{BTe^CwtgEZ#rmJ`eR
z`;7H-cIB@;y%kyu`V?^*hgX6Vju`U#te7UY;k~>Z^4i0T_4zVi_&evXPs|eiy;-r5
z0lZAw&HPz;+bri}!+)Bjlis0AkguQUA&w?G#osOy%QC~6KjElsC%Ftk{Ld?!ms60#
zh_P;N>}h9q5GyLUY&y$|wvwsZWkvby`2R=wsd>Rgb6!dB_`Cc<3YniB%kChpzjj%X
zpZ%ZYC;aL~ekT&&<rh)N{1UYJHTf}bS&^U1pX4V|54V!W^u)XTqW>g6VbgqH2jSN*
zh6X^Dlj=fa>am7S?AgWn2ew>qO_}$J!Kw)p^ZS(hy?QI^UtWKVpRTu7%>S_7igIQ%
z-He95e|20-rQf#VHm6SAx9GleMUv`iKi%(sm~6U~2F-mt@ZMLIJVyWS^N8h-o<F)c
z$zf2Rc6Z7?IX!5<am!x56^xDI)>A2!e%m}<Q!m`9I^ki%Z+f~ME@HUw)t5fJG@sm3
z*e|%f>#B&Ij|1j3>3N|;@j-2ixGZj#)?tNPtuOkx?93UeNBh=}B3*RaGpR~YPm4>h
z<7}KRjUIH=U+K3^*rnUAOY4_2xV0{(>GlO%ji>dBoqcuE(Gh3+-AmfMqTZCPS;W)m
zEYd0cw*9mFZSxu|?A&D4@#Lselg&%zsE;0BQ|*@C*@-`Id*IRU*V^^g9Wye-0bwC`
zH)@scwKp>}HIKij;NEiI={`%sHLq9Ss;_(b=itMmPM_3WbXMuNZGG(FNp|f+?meB5
zu;EncA9^m^d*=4T1(Njd-fvrB`(rE34VhZCr}d66?j?V>Z22z}R^2-OyxrmECn_vH
zd*-s+2K&@)RX2Rc^}L@*H(tNUagFbf#}-fTc=@42Si?7+kJtEaPm3!PPJ7P2)!GWj
zpThPRr}P7NYN$!(?JG0eT7}#=S+UBFDGd?~aYR!3f!kj4>FcPI=T2-}biu;r*=O^w
zzAR&bA5(Kt|4tguab4SCNtl_*nfTZy4Ie%`Xs&OsKebivGhaVz^KLj!DgD4LD8IJY
zI^FOEKgKMYy0`Y|+EeRwT19`sU4{M5ba2f*)M?&;MxG6)>wL4Tl(8oJ<m8EozE|ed
zySFrRBTjRUtwp*=KFy3yURW8srqs)aj#(v2d#~8urA(KDH^%SX5O$}k`55BDwHN8;
zzA_F<GTVLLGUV1X<C`%q?x)in{rf$dS90{amP31qc!3e!L^{``WRKU)%`0!nEFO`x
zZHSL5<ncD6QeUr_HYV(g2+P=IJdfb)r&b+USK@4+Mpi}JHn-W+>Exw3PrNdsrnD*R
z5aZEHU3-l2W1e}a3u@K6(q*2Wx##8Fqr;=+O9LVe$GGOWdR~7x>}i`LHgm3s_)w1W
z`W6J-wEN02d~HZ?kFiQWaPxRhY}!WH?^v1glc(g&oc6qt?dyQBJ_G%28`fMERI7Ki
z#lAWr&oX#GZ7th*M3tibqNAHkHD8plak!C1qY1Z%zdSH;PU@^}lS0Pi_Ohj3$@j(8
ztF<~aVe_Mo`<|!{J}MRYbL*O&B$v(y&OPk*rI)##(hr={4_x$c>HaFtExoNp{kwnn
zp25w*MIRYIn-M*@N$qvkWjrm+9=%-EuzSgR2HQgd@uQOKRhJU$(h{<(R*o)Rq0{vC
z#w)|>PW)k9=g;dZ{lFQRU(Pr%BFs*Tdw#Z)`-AhlK2IL7*Su#!pk3}Jr5`w@A2_8S
zxN>{$HrO!7%DTCKf7RL1S860~vbYwr;mV1cZe0jCU}z-HL;JRMPZ~PiqV7!F-iNO_
zX^O77x%Wom_+N~#^;P<TD>q^6w%O;(xWBSY%y?POzf0P^je(1zooXN5+y4lD%q@id
zcGuitb0E6oxBecpe+^yvz;@hi<18a*-HzYZJ$OLr2hJ|QGG6HiuFK#7j>H+@gM!iz
z+_X(Q0<-G8o|EpqblsSl-)_QRzNfHD>ho`;qn8@5F?T=pqf5w!$0c@6tI%NgFtZr9
zIz=j1HNAuXzno6#2X2LK@n5<>^!$3u%FMf^r_q;~{G8X~mCoLlo6cC-#5a1gXYH)!
zyNWLJDY3jrjji|lE_|A8@{+g@6@{HEjC&PVW=HMoPn&;rrSVUVIvn3;^7u}T^o{ln
zru6Wu7*5Qav3w9!s~+2UMTXo7$hC3Ow`_XU*Y3M=J7P90d{lo##_$dftv6I7UWJ^l
zef7zYemm#8Xm<C+<@MF!Nk9A=Qg3_e;ib<`2TZ?zPV~vwTrS_e88?ehebx4^<&7S(
zE61)J+GpE`{lGopyV)Voevg*F@kW;*UIEkMKnz^6G;D_4A6F7;%zxq=NIYiCu}7++
z#24V(pQP!4s!{y<r5fl^v?e+XH9<YlI;e=T!8b(BF0?*+1pNZ7%y-6y=;vr-RK$kh
zyP@VV+7$IC767kgG;YOt7l4ZI>0A=t_AjRW9w~pP6miB`t;km%_-?5Y-!2VN@%@r*
z)QC9b|E>LteX4J<WS((mu<cdGV@I$7cL;_^*bga?3x*T04cLG$gh31>K_=)<l%%VC
z$I66U(C1uh3WGqzjtYSYh=%=;0-2!Ons^al4<e>u6y*{1O6gM!dv?Z_P^Am8HozW&
zArkh(RUj~@WCGTp^eKi7cps$nDTWP-5m)CLZH_o6=1!;HpshIAL(z2jSM?`G1F1sy
zC6;1SM9KkWP%NNWK(T;g0mTA}1r!S?7WjKDz+?J*{{Kt)uTw6sjdw#H=tbLKqw0C>
z&qaG((I!{4=@n_jcpc`8cJ7r(Bie;4ec<ulgclG0KYif+r}ueR*#7SHsAERZ04%`{
z9KjQUfJYfA40v58#lj)D3K<|CAtE6Wh+QgW7v=p1FMk|C#8GXa!?QGmKm>U5tP}|`
zP=#kB8?c91NP{f!<vp0_e=Z%eLG&>f4~d{xk}`sgP@Z>uK?CuS0Y;^$|KJXhkO--u
zF3U2YfiQ@J3=n-9nnD7{QZATr%veDXq=PBPRx3z>D%2wzum{m++*J^L#+g=Tdm$7e
z!Ooa*hy*iU&JBVPhyW{&OHT-f25QO=8qoWKd0-2n?1)sz039>(2WwC_WnJJ7k&p~&
z5ZxSwEU@9FTofcj8i;=3b3u=GAc<hY4sH&f5Cf@@0Y<#Hv<1<QM)doh04Z>_J<D3L
z?cfQK5Cid$0LgF_G9a}Bd2~d<s1x}>X>2RbM>?oDcPWEn0mTA}1r!S?7EmmpSU|CW
zVgbbh?<~M0(m%=n-*^1~lK+1=&z@qqjzKG;7g6yXVoN6)Jf;@#{}*<7-~T^aUh<=#
zxBmaJ%=$e)>Uie;kstLT=6~o%E&Ry&JpW1me|M(;k^jFV^Z(5M-z{&OW&i)qqz`~U
z^8X*e{2{-{c9Q-7efeKYUZ!yV|J$_7itVytxj)KJ&3+n5n#zyg<)`6)Ve-rO|JP`j
z75UlyNq)lrA9n{SkWN&n2lDoX{YicW{qZfu0m{Im`FsBOzS;8ngg?HhP^`C{zNwt@
zqaVc||0?|sb>e-7sz$l0-~HIC_|u8!JC>2wFE({<+@{PcbFT%Z>en@yd1cN9;xzC+
zLalN?H)Ec(wV7$-9j+l|r@B4ab=C3IggRGTO>Ec2_3HeH_cm{M_n=lSty;N6*VZRn
zl<yf=V%*8bQ-k}TOdb|6w_n!<11mS(m((5q72av6RkIH}fA;;PgoopUo+Mm}$u@en
z|Aoz-t~Ucu`q>7SO5yc|WX(GfwJN+}Db0gPM&9?#b2Aiw{KR_nBPH8;h4+Ce-|cLC
z_x@<hyFS5n9)`P3t778xa*XeUBR9i6OW4zY4<{P6s^7}fV-l8JoT%S(=4{0ufBkOy
zwUX;|sQJo<Z@%hf=hN==x!2*&*Q2KOd~+=Ec(qdt9%VI}ytM}Xddc?7(RVyIx#|i>
zx1_A@FB+73QS{Q3)LtVF<_4>3u5`YA;0N0J$@Nt6$DdTYRa&okC93t9-O-`RdiufQ
zou^t=H>`J9$yNc8<)Y5s?Xc}9m&$Yg+5Y&e2a9}b^zXR&>gI2Y+3FYBwY;X^-acKQ
z^_;dUxx$Xy#sht7uKil^$Jc4;78Ek2!_nj`Tl8~lm*~=N;{A>#HIme`i?H98kvoms
zEIj@Fg0hM~zT%JnN9Vt6uIXx(o^IFn`-jwup4Die$2X15t{I+c8y8hlm7cq?b^U?i
z4Y}dl*Gr_k`&)LUUz4w2f7N$t8^s_0WisEgxY<#wdX{c;xYhm5^M1T$^}XVcZ_78w
zPV#-?49yI~%TK0`bExJpd*b<+z@jNe)90;P6Hu($(e*(qW**=<iEnOd)h2Iab%i4d
z?X$ezTvq(?6@Pq(J4>qvZ@2v3<Y1-Ek2cLYRU^I6ut~2KfBYk7H;>7=|9$wj>q%qh
z_DMNv`m@K-X@drHUo2UR<LHN{{j#2nleR1~PKn>SvZl`Np*?c5%9-nAwF|1yH7iS>
zenMM|bZ4S(jquuQ;J$2WYVL)h!(L|Z|7Bj<%8Th4Q^&2eKI^)M{+{`6tyXp4ZW<By
z#hLz!KfdCRe{iE$Sf$Yy_Kys=`TE7=`6Jg?y7kSamqAId%+pKrPKdgtR^84i`ouIU
zecR<7y5YU<S@yKJo!sw1^$iUdI9@JM>*&K&`mHt+=}H_`{P9nPgvEOPw0T~!J)L!F
z+aceF{p7c>!hkz2l@xz`#UEes$G<S`P2k4HEt&>LNRq33KY4sq{5ogjrtM<4uYA<=
z^4X)$hi$iPn7zE_!a%pzsYBcIZtZLjaek@Sb>SezAAj)Fle@PV#Gk%bhq$LLg<a;2
zEANn9#Om0E9wpEE->B>J%brmU_mpTeWQR{}y>883EaO{({NBfRi$NW!jpC1Asr|A2
zia-9``35C+hIRe9&n?9tUy|S7o7t7wIc(GT<LgdF6bm=IZe3>9uI}GO6zyg@FM5r}
z_*zv-+Q0`%wJPn!Hx8XDcXY0O?fV{Hy=&E*|M0)rA3uc05bgJ2`Ma_3$1lUQU=RbZ
zN@Rb0K3!>&_|GeP&1Xerw_r^rv>X3TP;P}ZO;Aqdnh=z4pqe>oZ*&Q2i<<ErvM+iQ
z?T`M%cSXKkYQ%SHzQ4ZptJi*4{G?xfInvQAS$v0-{pt--#jjrRtGDObR|8Ry2>MpE
zEeCf9heMDFMw|<*z!SnC7Sce!Bh$eJ!r>5PfFTv%5<DRi4#8E(g(@5jmS7LT5DEL?
zD&#^H-s@X}Jp@A}?1!tM_|;=;P6{Cq1Bzcgz6ZtrGyUpadKHmEKp7MZC>BsGpjbe$
zfMNl~0*VC`3lzozMM?DLjW(seBrRq1L;rtA8nlb{=YQn???4*G|3A-;ivK@8;=CN%
z2%BIt#K0C1gC6i%Q}O>-{QnjIe{n!4gJJ>20*VC`3n&&)ETC9Gv4CQMe~|@r$Y;1z
zgeMWc30m0u_}lx87-jF|<<g?Lo1d$_mxuRgS3hr8PkU#-0Dt?j{M!5bIomt=`pTmL
zE*?JiL0$o3DUn`Y(B9e8$KTb-)3Xs%S+9j;X;8$G*j=<7FqYDNb>C_)4`)9ge;>C1
zwQ0Y4>OQ^!9$p?3JiJG$JNbC|dU(3}N#!IH0|$q3&JIoi0e&7M#s;|h<5zBC;O^?_
zORw++rb<$AraJ|Al80D^@;UeiI0d*mcsY4Hjdb;L75&GHH2wiDgswI*80g{c;uGjk
zn+p?zu5>T&;uPTF<DHkLL&xralE%hBJkR!)^kv&!)qaAbDT@e;E&5E5F7b0{YAK0X
z`NhFp6w1%l$;-mx<7q4-{J4=%3~D(ZKskKQY5ppuu<kxZ0^B|PMZ5t61F_IWd0O7;
z#R`NUc~@=u?8S>72AbJOC7~JIAbr;Fm(RoB!Nc2OtiLNs<#LH-KOWwd%Ziz41<EDz
zZ>r7TNR_vw3S)>m_Zo^&Xsc;?_HoOvGfWpY_;g-YvM+l%shEM;ba^=wo8C>trch4|
z3`|gVF?MlgZw6o&m4PGMtwY|Im_9HsFZQ>Af%<J)57|y-q}B${wet`2u1l1?g;ZAF
zx3Su?f6g+53l#lI$b)T(GV;ECTXqvS4{sAQx%_Hvn)gM28sYOOYcT_tyk$lCn}{@G
z+TeH7%<`ta+os;yZ4%|mW@alY+GR?oR<-%{q}}vR-R2x<bGPoWv<#cwH=MdenGFcH
z9Mt6I&P}6cNzxHIz)-8Y?)lRE`Qw0BUagyq_FL7p%y&g&59n>~DOG-zSkku1VfuJ*
zrCo(u_0TkWqigo?mzA2=yB5E8dYiO;p_QX2>>My{Lz8w>w=YhnpN|eAU8^^9_Z$rV
zZRL2U20OatzG)eJKdR9{x8#`<HDjZzjE%Ue_}nM1+iJ4$7blw<FT7{=7-=!<d?zo9
z>G+;(l<ha&sDxYK%QfTD!yo>zeAD6T2UZ-bvgZ8g-E*%dopa2*7f8P;v|~}LYF1t8
zcOb^Fx99SDr=m+O*s<>Ug+qtu9DF=v@v!4H>gi=tS7l#A%h^}vKe&4HbA$E!OLqS0
z`t35O=AO`P(|)L{UEOL^N*$*TSXCD5OAm4ySHEZ9HSUpfmW`idJlVb30RJ@0nUn4M
z`o(^IRPnj*bAQu5>(&Ndr6<oB)8D4=q?Pk8)$gh^Wt}ATlJ`gLvyrQoEm~-P_wmlq
zz)BHUvWsk;EZNRmWihb%<)!9|&wXpXB^Q6pDYj;ff#Zs=<6p%E6tjB%)un{f#8%}@
ztyWE5Xwl5-(c)%<H+*yEXtaM~i<c{At{hPN`6TPqZ_cfG=`2a7Y(=`~#dlqwb@srM
z2CwJMx;lPtZTlMs>Q?^goWp|d6}~Pp<clN3H<kB?&%BLS+`sM9ZSu5I#Y&$0{Bf7P
z|1Q4y75a+pc;WMH``mFGqT{><)KG2tEWYEmhv!vo<0JgrJsB2mmP0%9g>qYc-D_`V
zW@;XPQNg|CzSDh{glk@}zExlM^3TDCN1Z;YyXdSWogXaLH@aS>YE9Z4S%2U~kI(Km
zXf?5@s$=iy?1A?U9+`YU)7?r(l8#%7bWI0tne)_gP|1V6hE;l4_SM|(U8=UPd-zqr
zlvlUXHbhsL&i5SJ>Zw(&=V#~Colxz{p!6!kr!~vCdN-g;&Asy@R)+Onyv(?^%^2dU
zwifC9F6!INn9)_ozyDp=bscVKzUZQVd_(t{cP}k9)5&&h93x3i<|17+f19dxYTvCK
zWjDdQkIRIRd754gUO#<gF*C7A<&IS&A9If&x2?Zdb<(3=HBZc#-$Xy^s6*2m3+E-e
zc3a%(t5KQDclUqPS3j@4o?7)XXwrGF=e7IV?oxdCU-`WD<@<?&uye~|PIcUNZ9E*_
zq3@K7!=t8nyjWG~zI&y}CSFxcLj62?5{rtqj%roz^o^6QeY^42^a-EsEnmI%Sp5l^
z4;x&&SuSQz&Wm;HT65jE#@1@ppjpjlAKGAW;<I1Noq3u5=Ggl6Ba7Fv-}CM8#g{HD
zdE!f*lH_z*mTh91cnme{f7C?xUX@=S^xHi%<&;j*-EUrYIK6Vo7Y!xpYw}jB=5Kwz
zuky^NGcwHVoV#~wo;zUEPhJtXzwz%{*D^CE$9RY&Etby**Wz-b;x_Co-RJS()*YTM
z8t>>iZug}@4{Xdbk6&F~bro%*!{qDRpT{OqeDjN>em)`SiT$2#zh1a=e@y+IU&b|<
z&vSv5*dIT&c-eOF;YT$V>KT?eG<0?U7|T26cjtuNv@H2k;Gn1f4Bz}Ka(yv$-PtO%
zX1^YRk(IArEcxh-fyd%=#*+J;)}{tiukF~-SCXoC73JH#wVcbq>(+0Yg^ru;^tkC=
zzZ~-=cPkf(O{wp>$8f~}8nut5!Mj=&JhfF^yP~sA(q0+1xfyBo^UyDC*QVw8f9X~~
z@X8jWku*{_Z!XeR+qmXdeV->0TgK}+=^fWMJ+X1SU+d)qBR76luJq@|nWXF9TclgO
z>(b@A8;VD)`NjYI`8DTej@i|DvfkmSD>d6(Ze03>59`_|=R3FMqQnsup10`q+Mri-
z%9L-<j?KJyu5+Vm(id|V&$!r{bE&($9fm2c(a(xLX>DUS;MtUNOTWzRH?+={NV8?<
zpIz#7;^jZX*MF|9*pAoNtV<=-iypGCT)h#82c0~+<8h@Q4xJb=Z^vSr^$Qx^I7}=m
zxqN3jxaJ<}G;cs7&xX@=zS&jESd)En^29{nD|71ITbjA?0WrDd^Zg^AW=1D3tc+b#
z>g7YntP-WYS8VT6rpv(_<M(a|yHnMi>w>v_{h0g8I4H?%_j${ZThEMd#<;kjPIL6{
z_h??p(d$|c?PbODV6<GmGT)l3AF6}CyVCYyOj1bwJ5_(GbmjcE>7UOZ_uK8HwTWh2
z&t*HiCMA2kZf;(ALuT=aq-{fdR3VSI8I}5a#k4VDUqo2OE|a8(^7?e|Zg@~iZ}NeQ
zw|`r;-1S+VryFYT4zaC&IOxR4W}QsqBZ$M_R@mjhx)NvmG_oq%wz<uoPA4zTdE%83
zHKk2ihZv7u>e^$BxgIs84ysjmR?kT}KKzBxPrv29X=Y`ekmOW$S=rWyhnF~H@wk`c
z7#c>Dmwmm~l`ix2%snsX9vvPnUm6f;IL0-{)${tpVNcr}v6*v4iAA8qB8cc6`E?a1
zN%~PfKJNAFaAM?$nXi>t1TTl*p611~ubq57ihO?W#*e$~gUzeWelsNE)`;D2uJo<a
ztmNj%?9n4)FQ4wn?FRh^s8v&SU$-y0%&|zH7H4-{?l@%nw0o(oe{LT5p!nmdrpt@Z
zOq8U_^7@v&n);$^2ivC}&Ohwiw(08^ZKem;tkSXNom<P4SOiKef=PB`Yjyl_((u*P
zzw*3XRI7TYSKM)~cb79q&)eVLY29ph&*ra|xBfcV?c#uv&(6oc@Z)+UKSy;b@qPEz
zIxY3mDveB9bv}3I>06D*E3pXFD(7RhqU$~``hDLb%fEg0UFR(+(@(iQGzlttuZ<Fm
zK#4{0?+}aNjr{yu{N!c}+w#R<U8*!nif%V_Pot=dvn*e^IS&XhuX|?M!()=<AwLHk
z9z6JgbN$#SlfF3F#@+vvssDkW+`>GpRxb8_vH0rt!+dmUFW*0ZTk89+BX@4P-0HK@
zn(H&$uR3tm^4P)?16!?VGjj0b%C~vXx|I(FYE_e~W8Q37IksJ}`R2y!kBnM6VoKj1
zCwISg_D89d?cVj<S>IfFeH(5_BRZ+0)5^69J1WgRS##>)x|SPG58Zxl>5JK~4vt?f
zNf+evm6RB;XX>{mjnW?+sW$4~D36PqeBByO)BEM+<}>$au27}pCn-O7KS+MM%&o+{
z`!Owk`ub6iP_yH1`x?~<xe>Q^M2yeX$w`tV&6n?EhoxN(JE5_!7hk7E^5N3;C+n}A
za&|+Ve}@<dd<?;Ui}v+hbk#hxN^tT@m33>U1Z%T{ua<5)H2LuQ@u_QGZsdLJPx5{n
z<5FqK<vsfCN5)M$Tldn6Yb{%pbsF(osPmb{v)k?6JY@v$&5XqQ`dI}!Z+PDSLPb|~
z`{!fNR9@B4cKhCHonM@`v1mE^^5k87*Wg)2t;(qxP-jiCr`MYf&#dX+dG+FEW?!!Q
zeuAU_t_=^>vEL2YCP_IhM7oU5$NfAz`g=X^+-0Y8->XG#u1I<`Y2bbJg1~3SQAf5f
zWPS2`u0MYd(p28R<44!5qgfhO;;R{ZD%&-j8hW=w*g1nz2CEhy+3-Wi7sGDjw=JhL
zI?+$3;=qN|_qT}rZ2o}3hF9#z29_AQc(4+CA)wgYR!Z!Jj%L3k)_A#wduJu~!pgBL
zhxXZ~dVXP4kYmF&F^ih-=*7p=CzyuU4f)^ZCGpKZhxd%)Gp`AVAqAIq@g4s>S_%CL
z&0kLY&0PML{^4@hNhiLqr=h&wlx}F33u9dSty>b`z_W@;65YYcecd7A)vAV9_mTms
zhn7c0zPMFr#IEENrr~raRYrOJA=(#cmY~(p)o2a$09q5hh}J@Rl_R!ClZBe1zoB2C
z;@f)zRBR8^CGB@?iOZH;uA(UGmxtP<6Wb$}H!03Ld6ObiCNvnva~uRf7{o#{WP{;w
zz8QcWc)|>bgm_4SOwe&44=@93u!jH$g(%n$DUb;|j+}47670YiLLiA97Kz3|GGv0T
z6Waz>U<d9H0x^&T*<i>up*ciis8~pZOfX8t2i%SIF|QTl`uJ7bp`nl*n76O0jAvP}
z0e1+7NZ1c4kPC(rC<EAlFN8r1Bta(VP9zRNOU5A=L}Le27zDl$0uc}m`ymA~LAN#A
z1@;gCQ4;HfWX5yA$O0RI3xtB`i!U9-bF?M6KnTP_D(F~JPOyVuSPcn~33_c=2HYV8
zV#WV<{D*Lm+EWhrZ;tzr@(jDeRRXN!g1QIx2S?DrYB&UGkOM~Ce_4SGgg_J=f=n>9
zq29nC2!<#~giO%q`-U0Vf+vJR3?xDt=y2ehf;G5<I1xlZEF?l2<U*A`<N-F|31JWi
zDUb=eoH$Iu8vdQ*KLpn*B85Q|#6uFKK{n`d?lFbV;0VDG22rrOA9jFfPGFf}!ui1w
zg6%m*As$j73-pI!D~@j)u$+iJAQa-be@_l(xk((0kUg2>qaMe_6wV2ppjYRxPY<)K
zhGUcQSf=GN9zB)yGOojU-5OGvC;A<YJwl#nFemhMG~*g+IFEXgPwsT4Gu~<jd86rK
z{0H(xt(n%GYtjrbnaO%kTXa9_h$f-A5XU;I@GQ{)EFq2MQ<(4mGsh|a4?#NU%woN$
z8a0D7wjqc#k(4W(6MQtpgJ`^_59xZ$M@`tKC^QZ-ST5%aY{7U67|mu~uo@etf==%u
zk{Xmjv4CO$#R7^26bmR8`1iH|w@L5$|9>Vf-}-rNv-?%!K7#uLFPH|!%MlM9O2TK5
zKg?#{auCB9bS#Y5{uj&b2hpbbd=>5+;3tTKF+A*!h5X^ms@xw#{vg`3r-EolzYD&D
zt8fi|hU*~On~QerH{lkf!)>?&`&sv0Gz0FzeRu$w@DLt>7{vN*+19>LjQg_flwl|A
zf_S)NNSV<KkP4UKH>R~`{eqn=za7?t7x+N_u#xe7*mEw-gZ!aC(+9vn7y|jjX2!P`
z_`jF&eQ;1a?KJB+&G<=JO5S()pP^mvA*MNiBRGQ_h~Wr&R6CxGo`rMT|Et(9-$MSd
zp7D(Z{>L)Dv%vqoj33ngKZ+)5$4{cCwBuzcPg!l5&N5B(WiN(H=oRhwP4u>Qya;7c
zY0D$h=`mimz<&{UqAd0<2l>Numi<k;yqH#w^yLdIW5{@g0{<(pY{df03x|pF+A{t#
z<27uf?7b<ct+uRo=m72bVANhaJ_2>sju)j|qW}8*VG7e{Xy=t+x~_I!8@8{lb{jpJ
z@2yQEmJ47!Q2W0W=}T*unai|L?es8onRdKo-MnMBH}zi}vm$;&L4Gfm1CJDPEC(|*
z2$CQb^f-?gfhG7tB*Z{CC!7q(0pXV+`bSKK44_LxCUW`#J8*;;NQG=r7h^iOfVw!(
zP!J9AkO0Y$2|1v{vymDsVGy{0FN8t_#6dD-f-W0jD4vZ#JVOlv7tlZ?B=M}HUyAu)
z3AW%48VH35h=Mpsg>=Y*T+rh=sySGJ4Maf}n3iVS%8(Y+WqFPQUsw&PAoj5p*n%VY
zLJ)N+9<o4uBZ-6zFkyc+2T{i&APa<(iXON_JY+!tFB4;6Kjea5C7vC@#E9*M0MM^Y
ze&7qCkOF4Llm((78`PgO4Q!};p%4#=FoW}A9Hc=OByc{>2A%4x8=@c%bk#iPf;A+9
zeht<MagYw#(5fb7hajP~*j9*vbTBj_7B1L9I3z+g=+tIiFvyg$Ks+QuCaCLSA8>@+
z`q=9W)(b%p3so904}3wdA?t=25DtgT$g>G{0>`G<7!n`_LYpxTDd5h#yf8Qf$q>|v
zZH72-X-!>)c<9`jc@P2#T_|%`$_EX=x;yU#AQZ%Vq)3Q?G!XBQOdzut%KM(?Al~t0
zfT1nZAg4e3%8qRXy#bU7f?&p%)MK~`h6C9?&_Ea*f*jBtL|F!NTtP6*7(&@00St#y
zZm<JK@Pr_k0bvjc(GUkw_SkJ03h97@q12Z8E3UKcP;tE$=eQ!E42lI53n&&)ETC9G
zvB1CH0y<<l<p10M-_s}XQ~v*+{;sa0^PK<x8-4#PO1cJJDslhYp<lNy4&8g(b?Mfn
zA9gG*<;4WB(E5!>@{A*fg(~^Gz4R5@)tvjK3wlx!9?^ZgynMVJWMf%+`go6QM_S?g
z9w9IF;g6Np|G$_)$;<Nc!grjzN%1IPV6Yk$?;`pXadQ{bL`;BaRJ;S}Q^d#3&EGX3
ze|jt<d1-z8JVttWi|Jw=@u(;FW_^nI5+NaP9ai!@G0o4_f2^l=9V!DmHo%4L`;Gb1
zMY%k3p3V6y67?zK&?U&%&taUCrzCvVg)hEXCW2)upuZJZ#`1TT5zBSe+Hy6v69dI#
zD(et`7&N-F55D8a#;j{$;n;+qcRu-Md5e7T`_3o->%4UdyS5aGgirog@20iLoA%Du
zy+2{=-oImOrhn4by+2{=-UVzeY|u_?1Mz)P3{lv^7>z`&sZaV>KCVv=#BK;^(Ogui
zLe;4iKNr4EjV}L>*C|%<QJoUo6)(1t`Y}CkoBp&;iDfcb=5w*k)pzyqkLpwptvz#i
zk06E*>s0Kg>Quf#->+7(ZU3xZ9er1a-qx!<@234}y%P5RN9&ca_lNbWqt*`MorxHP
z4J)D*QE{GHef^_)<>2k(>Ek^5?deM1ejXb?HN1^i;>g?&&rRYa^{I1{@7uKRA1^^n
zFL-V;=6ogWp0^Hf*FXnfAAgU$_$}hx*NS=K-5cjVe+PFbZx>Hj`8<@r&1t;%5d+Nz
zBu?d0byPl<Zv5^x=huLLXq!KE?EGK0S!`F{IzHZJVUIuB=0PP%z|fd&HA3s5J=o8h
zn;&np3vp_=h->$E-Z{ipUizaSc|QxAJ2LCT{KfRYYF~?MF8fnHkBZ$bN+Q;8issFe
zi!9F()75XMYi*@XFKnny?=;TUMP8MN|8gwP4pK%l(GOE=gJkXhcGM&B-||-8`6YjT
zSMC4&`4bAv7w7H#x@O1wLox7bM7BGxU?dytE*e>|3kqJk96n`tQQl7sZ|!cy%um_f
zn(3daZ(=`w>iR#3=>?Cm-?O2xMT5MuzqM5h?SEklvF(ktaet&ztdzkHm?iP5O6o1@
zTweOTyC0^B`<@{56N5J9kAZ=PnIE1<LYVfc^GMj+wC|rs%$RP(yUF}}98uO5+OmrG
zw_@P6o_rqU)t_WbS+fe3Ra{qzh{bJ<TxL=CJ~6y4v&iqmGK>BBsWMx=P5XYC#eOWf
zUkaAlU5}XzAKKUKwp_RJ?ECg8{(J4*PHShA(s^YrXy?AzdG#mCT)^CatG)B%Sfyyo
zE{>IQ&|g5=(+ZZ|qlLH){)g)Hr;gkIOP#jR+B%f)3t|uj64$xLFo5#f-YHN&DDPio
z=TDW}iabAczWJkiZB>?q7(TS~>JQ7EcSG{G+PY)@xlTW?%pclX|LzC2&MR|4lmA0?
z`yaJ=HpSNGoLE>tsKWX;{jd2gDgHx~VjL@ZoXwb2W%16wkG<OW&8*;&!L`nU?^~+a
zemc*l_NqEDctgFosvQ<3rw7)2JmS#y^EF?Df4{_bn=|bk_{ODH1-%+NCTew3WEF$q
zqn}LMZBcFKI_s83-*#Je#LHq^<0qVd*Yd<f-|3_Me~H<#Y3JY()s{wAnfBfFF;53>
zO$gnxt@Z1)75@0rNr4=QYE@QrznFt|`a{+%|9o`G=|zJRG84akVqsL{YbUE$kG_f`
z&6>(0-FHd<YX70a#_cF<{EWiJ%`)X1qFQy>Xi#z;Y1ZxaRk98>G;j7G)2sKf@|H$R
zCe00fJ*`PL7n{Py*(hwBs~&Q`ckS)3n^^f?JH0n?QR$SVB|o$+Q{&akM3b(ET6VX+
zH)A&UI(#!GUZIV3myTbi8N196ymkI*;E(GLNc|5_sJPGXe9ajvdieVg&xE&MYL)JR
z$a?no-dsLmG@#s?oknrKbz^G`j9aAt&JU`v@jZ(1ol~va;No8K+||a@yt}zB+&VmE
z=77HDW%kdz)2ip~*jE>?9UH;PvV%yc^lAH{U)A3gkFp2PYiiZBMnA8-GiqWh%jB5T
zI;SfY$+S*iS+C!o=`~k2DLu88iu;M0@_zg4;#PXe`C8W+aaFgdYRn_O>Z?3jt<KH#
zJJip#+s>B7JKo=u7q6?Zaga{572Dx{ZpJ)mYctcvJ6uD`PIY^->#F0a33aZxn%J(3
z>(%)Y4^f4UTl7ZW-lbJ5m+0F1WQ+1W<4TM>*?4Mj|C7nX0_OJXx?o`Cru&j;XHeKU
zTzh$&s8-EB?EKmHlM)_|4|<YtB_`YG+5Q(cd%E5XJn3f}SSqC>hlgkjp;kp(HeOZk
z?#5CZFD1C#mR?TOYgu{!v)yG&&TbLn_xaw_b$H*xOFFeGykRNLgGol-_snxMirbtz
zb>E`<&J{_jr~P!l`(d)_(($y*leZ&zjQ-u{5z8Mve{^w@!=OIx?v#CUdeDC3mc4u{
z7#qc{=Y{p>^7;Ox@f_E+9hQWdnVgA_ZPM`JvxDaP_WDy><v#QEvo`Pcl;@02B45>j
z32#&vs&C#O^^eBsENr}~A#(XPc^j)M97$-O<@M(Bg7RyNt<w!(@MFxPse5aWu06G0
zr&UVa&o~>WOQQ!J^><6~pWYyP$Ngbxg977xC8?o&-LDdtJfX(?1k3T}aZR>6b<Hi?
zwq8n`vx^?r8(ggFh=h3qu^;#0_>Vs}dZlr>@@8m{17*AT91C6Q_r3GdzU`(t4?c8$
z$vV?qNh(F#8@1}|h9|3qJgeL5Ul;dNJUAA{zkOV1k?zmq-qnzgqi(-0tzXXI*1DLc
z+ZSv#p4KaN_SH#8N1W|<FKP3NdQ-M$alFZP`SUn`q90|os!^l5eTTm8YGVGhrn=_s
zZC7WkD_gSt>@7DZ#cw-tU)|t4Novwdq>DUwa(?kUqsG@iw%x8thii8n_Z+P?+{8xj
z*k>os$4FPWuiGV`4_*e04=Y(E)Vp_T+?lvCXM1lsKek(i7A3lTv-0QXRa_pv;T=XB
zvA*Dda@TDe@4o+!#}WN^j}KbdxSz-6{rjIE&$F=cI7C0)e`Vay!p7}bF6SF)Jz!az
z?WMyb&dggLxwWC8-%Hb3Ej1SmXJ%YJKBU1Yt}|i0KT)e9Znadu$XxJqs_y3S#|H7u
zhLu|Ls%F=9TQ*y4Zjd%Wb*b?2J$A_JQ-3r5)xMo2#{`rayyJ31&sjHv%dAZP;!))O
z8vZ^9OzLbYd^}IlexK)_zbsB?n0%c7`FZHCj=%Xp&Ub{Sf8XxMJ|Fev_Qxd;wy18B
z(tN}Eq{ClTGf1vKx~(R?A3h1)#P<Gqy2`YdRI7$B)Kqy?Y5Ul<OOw8QqdUID^pxBy
zi9a>IyDz{g>9-ckXYxKzUSD>&+ghWs=X-eD7yb2L6IZjTd|k+J8Fu@~4=qP7Y&&pd
zP^~@RWsWqP^|E@rMZk;g85<8bUtIWjCVzEY&A%%S=HC^!vas<e3ma!ri68mo-f6GI
z=aWs7D%Oa+R5EAppxn(Dc=y;|9G5!9%(pLhtkYYGAF0HT%$=O``pD_4i)tl38WQ(>
z$p2&SUEpfU{{R0&A%vKW5Dr4_p-4jRA%qa3qEeJn2O%7UhLF*?W`q!v5n|k@W{hbF
zxy=}t(HNHyVnRmvKi|8PX?)CQ`g}hAzt8tO-?JW%=XveD&)RFR_1<gW*Lts4A9VNI
zy`z`je`H+gQJ*wueEe3PjeWn$>x{2`SJu7S>IsdTzjofkG4!KyACaN@>h^<%%c?%C
z<=gF;=c(uYW|>~fybyb&NuzcCo_D&W)1SaWj<?7Z)2vm)?=2Y7uR>p+hAro9oa+;m
zyKZhoO!HZ*at%(!&`&~1&-LS><@Ej|_5LG`jk<R{G^}p?yk<lEK5cGw)%0Zhq`1-s
zH}bZ&Z8Rjh>F2ab>m~JS%etVAP3Eurc1XB?=bozYSp#+t98|;cVX47YY->kG?cl!n
z8|67q??2M6+MM>60&Q}(zV@+dIfHg+%KNpSuFq_s_aFH`!GGjq-epD!`R#R;cD$+*
zfArfmhNdi4iQ|g~p?>JtVk*^GbS7<GX(pmwhz6j`P~vD$puwp4s0l$$Xv3&MozaQt
z0F<^c+9_xlIv1sSXr=w|OjPn^3A(ngO8Z607s=&Mqr5g%{C3Iu1?AAS6II%ezN;M4
zrc}y7o|JNg=*qE}gryv-Q7OkpRLXG~m2%{vQVuowlX7^VQjSrmlw%<(`B;HUIi%fc
z;d1EOTNbGtq*u@`QE9Iz<uGO$`BOr7(*KYt9^teWs3Y10<<z7F6`vTj3s5IC8tsQB
zqRuF<v{VDoBj{kX66NQ0qE^~N(hfnfqio+Kzm1^McJN)>uR<KzemzvS-xQVYvu$Pj
z3sKqr3RJeg2bJv~MrHfQP}zPp-S(wzV!`%f`A^qgPie;|+n07#QWgo6U2BGt2W<<K
zeX1pGv8{F#%4dG9*h-DgMQfu=(7I?mip`Ym^Lk!;k@*JbHIy=F@1o6775TA3YocsJ
zTMxBHr9C0H42qp7cR~9$rQMt4vm}e`WjVo?c#=;(4QpGYEZ539d;-z-M;%aXAfMWl
z^oU>3W=v`8B<UHlO!lpW<@_ynz@}Qts9K3)Th%I5>Oc7{Xvd|r?~?VYhHw1+%_bhU
zQ_VqTe}(JTlkMu-QoVD#8;B>{-H6I|<51b|Cf)k7U0u7TcWyV5c(UC^sBCw!Zavwq
zu1%5B2IlSZ#t^R(an_<W(NEEV=sMl{vRz#pAEoWj+vS~4JgKJ<DEn0Pk#0TNuC9&E
zJGV<6QMS7kmF;drWxJp0)|c(-+Pl1SyGw~D+x-}o?Jh&DsTi)VoFgC>k|6_(hGKhg
z0u98#A;<(1zSY`-8)!lLsa^!BY}VikK_LB7(;x>-+^A>Z0vXg*lj8Jg1r7YGzQg{`
z{tqo5U?V8-gQ)j``1kaI82*&L6KZ_tp@*Qr-(hNZjt|HKXD(zKh=QY#1E!p)|F8K(
zEbtL1ek#OIV0xJ9jgP>HGT3DX$4o<P#Ep&k3G{^mKY=Tm{xd&;wv{<YaV>h6pTG=`
zLGcynfKR<};=RjXV1chdqf(srzy+L^a2|ZfHH>MCxkdLKD1HOojL7>>+)to!@K^o=
z-{m{7sD1-oDOVUIKsp%q!>=s3LO3KsDrAD8Gyg$X@P!D_2fYRK7SLNjZvnjp^cMK{
zEWo4BAN>E_;j%i`T%~#mub?2jmT4Yvi$QTPfFmaOaD(;yCw}SD;S5}Wg0O-Ax<EHs
zUl-z--UM5~kB8@YbQ?^8sSpM;U>1bKd{_Vy6433i0}^2uNVv^5@4yn~KZZ}>BjzJv
z1=FiQLKgG);UP%Kt<F6bWhntALE27~LZ!cz5&9MLrO`5w!ZIg_C(qlUC(~<SElB8#
zN*k-eFcbz6XD|$bf*{Mg!b_+NkKqYOutXa|6KD=CLBeaaIB6I{NnKjqS=No|p1S#7
z%$EjJa3LRq!4<5aB{YJ@AfXj%18tzKZrM<D0)*)1hof#V0!D%-c)>Q(zXaEzAS5tt
z&wm|2!Wh&K#_8tEVmo6f2hE`cv;rHj1v_X5?V%%xeLKlC+6C<j-N6xhffMwFejuSd
zS^=aFOI4@_)xjKUKuxFxYN!pHNw*Gq4Xuk>Ks~4r4WJ=3hNd8)B3cP%Ql8l`7b0LG
zEQX~J4a;FAtcFC=jzK?#SddV7y$?vw6e`1qPz9u4q6DR{A1~6R?_tYY`F4>0f-cNU
z->udxlRiJ)n3jHX*38>NAEu>mWecVUpwchRhUr$&1|$txNBVX*W?s_h!L;;yZt~Xu
zO_`TIrG?`(W7z{!mFicBsKzrP7*?j<K~K_<zQoOm<G>4^7SxHJ@}h^(8I}IF61tP7
zBiwGqdmNDdqP<y9`omhW?p@Np2QrSPNoAGlYiwu2i>8WDf%$S!21-JCFa~i3Q5+t!
z-fPGK*~j~#7|YKvU!3&~m@e!~QSwvRpW=V&L$R<g&A)>m&Httk&HL=HhfoljP!Imf
z7wtduLtB^iEp*3WJ=B#tF%*VDedZg0rSAV`XmjYs@!<#({!<^Ga^9D7wwx=)N3L8u
z<T#Ld@wqA2898^$dA6|MO_}~P-<!OKk@wuHTo6B-PT&e&5Cmbc669T{nhSjpgh2#|
z4^CU&Wq5%G4uSaHbcINW0r9<g9x_0DY~+GH?<$<Y4g4VtB0=6^IP$(h{A<QQJcy6Y
zqtLZ9*Kv?{1+kC`xnRV56Em;?D-b`Mre&E2D{zAXznaNRr$Hu&Urj?}$^=co5nLb$
zA|V-!%8?dGUt=rKLMmK@8(>+U`UDyXhXVhbF%>8`?1M~Dvrn8r{BOp9?5{(R23Nq5
zm+<mJJPKkV5o|fv`9dg!!y%B4|0ZA#O~4l1z!wfd8dz54oDT_b2-4sRWN@Cf=02q>
zB!Jwrcu-G*K<<?yrOtr(;XDd*9h7UP8$>}Wh~MHH5X3Qc2-4sp#MMS26U6VPNgd)q
z7(_rcBtjZwKo;bJX<cjs_TUIE5CoBs2WA%J8N@HAOFilt1VJR^f?<8O1?FH2F5n9q
z&_WEv!%?7{n(7MVf@uTNfOt3xQI>2Ej2p5|u!d-eg#_3KM<E09z@!oO2U~Cf4+sNw
zW3~%X5Cid$1nF=C<U^DA2=#4_Js=s<;0EM?i535YB{+aH1VI=?LmZ?+HW;>`9AF9d
z-~?VEAM9cw0gl3X$c8*HZAo1Q2XF!}&_FcALIM={B+X&kh-<4k*n%T?KoCU0N=OE^
zHEBTt90Cg)j(_ll7>I{tNQVr_1*6s+E6^2O!51Q7CB(x%$b>vFYeQV<3La448}&TX
zMz-V+WZWZL@P|l<fn<obXP<*nd(wgPVAX;0Ln!Qn8;}DQ9jWW!4;lyZ3mK5viFG@(
z4G4vJ*azlahznsLeFQFoVK;0H>44KI#TTnRYSM#kg1iS$hHQ|Jx-Jk7(O}w>?Snta
zhh8gifN)5HqoTdZ59ETC6ZU{8h=mL=?ZY}CV*t59oHKa=!~XmSw%`vjkN}PYsV@)(
zsbK9w86g5J1`!uxAOSAAQl6pIH3;P!St4A4EQlM<G-QF+9UH+#$b={l>II}hm?!0j
zba3<MKZpg>0O|omLmXs-?RfSjtb{bU2zg)?NEyL0i1Z*5R)WO@@(W=Q4_S~0#=-1A
zumCG?0Cfm)Aq*m5C7jo=d?IncDU@<R6!=ahkB|sAz-$`ZhU_qOI{Ad?8Eg;CX0i;d
z!2z7W6}%t_!XN^oAr=x~AISUubhrX(TI@9o1>@PI2Q@2_mQDUMr`)^CbD!LAS75o^
zFaOHC+^3ghUX~X_<^KFR%SC@d6(1z1+}r2qGz*n`|4dZUm1jsv=U)wmtT0m9DrL2E
z3k-1!95vR>Gr+60wNJ3OTY%sAad<oN_IDc{tO;?O$gf*S@Mt&Bpdgvl1bdEm3k}f7
zN)laJ&&|hsjJGB@aN>Bc|Bes9k}8XeA$YJW@W)r+-$m|`Bn$y5_W%$d#EIH`{|xRv
zLEi2@{u*~B?;(m$23z91BRI5Rq4;4b@Cy>HOS>}5C2f*b(pJw>(*E5fEEiulmgqae
zn{;#d(}6_lbG}j=bSt$f<7iHes`2G2cbU_%+S;fF)4rb6wR(fl@Pmf!uJ_)=vorNZ
zZLoh#!qi@K`i~iYtk(K@!>cYnVmHLgrb%1x$*a;HxIFss4(~|XO1wIIOD6vBZcF;U
z$M7y{o5Z5F(c8*3PHiwZ?SuP4mdnfj@H}kk^M%W25AU9{?~v`-`^_7TU6XdiVGch3
zxqhh)z8$-7)97j~J0$L0`=IxwGv7QLvD3b3&gwc#C;Pm*IJ{#g9&!6iyyt=IJLXN=
z5}y<>sJ6lOGW$C3xPQ)|{l1kU9UhN}w#sFj?|W?8qWbzMs_%=U`UENJn7DJe&rlnT
zHMx`RJp7{on}C%8W6YPWnVIOJu5@E`i+<0(OgC#ZuNLP<4rH~#Uyq%8T1jtjon20c
z<2$bp@tgl^<l1}AlWtbaHXCi!d3}Q;hnE_b;##)YPSX49F_goU?LN*}8gAa<RdchM
zw+&*Sj7q!Za(wo!NbA-s6UQH$xh9rlvcFPa7ESuVJ*Sw%vG048J`?hDgTROT$2Q$x
zs@<?%f%S}gw0gdZ_A=J8-D7<hJr67~^QS|Gn!}Ua9@zan{g+;iYkhZS#n6!2kI&rT
z9%YP@zo6|E>#N$iXzcf$S!;D`(cUY0y{~;)*TB@K^-iB#2Wl;2Y!4;93SZ72*rY@|
zA3ul913ex)E*U;<*R5iso3)I66dxOU@#RV0pAM7l?y1+-bKJ;|L(V-PIJMf!uYwL{
z#(W&|>DLw)A6rz&nYr&np4r<;yc%~-*7|kljZ<60yxspZpCB8R{qfhnKI*DvyXS|0
z-KJ5QgyW-c{+L!{#o?%MuPUQTEo;B%QLpRU&fAu4#r2!Ipf-rEP`saa)S)@Y`qUdV
zW?hxes#jW{K-(>07aI;;mlX7=8`oyy7R9GPQGEbRs3GZ<IMa4_<VxS;kK48S^kBtx
zR~oNBGU7AuvL}9asNk8>$mdJ$ZE8xq_vib<x{9QCB=dFrm17ge*ZtMK^VkUyJwsD#
z-zxdtCS$AlV?X&ZtXSEi`v54a?~9`P04Qpo{VmFIl=1vi_bydCkFIz1%U%I}>o#0`
ze~nSehduB6f3kgT*6niKZ$08UL2c0brQv}#+fF+;?Q8aW|HgUNdy20LEVa5=?a%M_
zU-~4+;sx(Tm3m)u>xN$%1wLN6eTt!{@wX<H$G7ebZo7I&%+@lM%2ltHRf+dQO1!`B
zvu~|z_fGirlCxg6zit0>uf%tcJ^U3n2<+eegKeHY(!304+hSbsy6)w_D4uxO__N-s
zsxMPZJGV&T9<>hVe6_(}`>H6a&xoS>f+(tw2S=XGIF8<%?}n{PdFPmw@|pZ%!=xM0
z_rG4fEv44sHOI_1oEx`y;gz(r9$9xLb5B%NwtFMgb5f(;{Wti=ELb&VLA4patp<f;
z*w3Be(my!ylW$TRs#MdI^wx|&JoAg)&2QfwXMZ~|tp5FIpV{UXo-ZZ@P5tV6w0|j%
z^BKx{H>{)gx|O>hX%@8T{e7pBuI-C?Eo+t0X^l_a#{Il@=MFcfeWr3B7N7A{Wggnw
z?#EaEsgHtZiv7IP(*0gp+f?0>RdQw8j$wfY5s!A5mHlMR><LkgSK23XzTd3Wt4N!*
zO<#Z1$0e}Csk5)5M_-GZ-TU>i)NgB^T=F2h*^JL?^UXtvcX(5&GyR%56mM_sw7<)V
z9~V3h$c&rWu7Z1lUmtb73Dq9){X^OAU;7I1P|{nXx$g3jNA$*szJ3#5TI}v=+r7Vo
zch2<sKGz1GyxVQxUF@gCE8BgCcjVoSv<puMF7`>NJhSPM(QQkGo`~L>VAj^#*Cnaw
zzL<*Y1K=0s`qm(-Z&YbpO-!Y@Gq*eKxZqWF!H^9-EK;tX^FL=*$Ko3Ai)0*h`jXpy
z{;*~55vo&V#{OKT_?53ye)9gUjLGqBNv+1MIJZ5A>)`*jzW7D$!(P<B>Ax!Xu_HXw
z_lES%p3}stq@yY`y?Vz=XV+S!?mS#-ch)aoG+JiGb5TdxAAjA~^9KisccJx*_Cr%1
z)Lv?AS}J*X?7#&3TQ;{BL|wNpePOcelNaf{i%^cs-sRe**xvnY(RWuJzT8>*$*Z^%
zXOHjr_<K92r)3sjc~PFaGFI8{*3(8u!b`1RZqmu(!uIP{i`9L5oU7OPWTUg?D%5Th
z-hPxy^_>#$&VWwG$Bdf$>Z>!KO~}3bW%Q0~X%iRrJO7R4PkzH^yAIvUcS)tZ;o5N1
zOOIzwa<Az=f7-c($;Ho`%~`Z=gQi5yZ#IXnnR}S$dnLV|J1tixH9kG?X6}oLw=P#3
z(ecI9b#41PUu)GrV|Jfj3n_yK_ke1H2Z623PJF*MaYNY`_dT*pl^efiXSed*j{H33
zz?P_6HEbqu-BQw9__A7Pn$_NO_7T54t#&=Z%lA}<N63H&i%O5%)Mj`e2Xo$;DE1qB
zVA9=#S)*oLy1ePLhE{z(ZJu*)?RxK*v$mFYn_J6aSTWvXDe+>S-TC>uJ#Jw(HRrz`
zw(^%zdtYDfZ{Di(XE8bBMkQW4MgC?e@m9T@^}Ks0=O=!nzdpEQ+b7T4%?Ybx-nq@K
zUslDBRNY-i8H(D+`J8foUU2M(Z3kWrw;SpD>&Bp9hadM|S`=3*^w82F$0K7;8>R3d
zJw`cSO`q^ZM*r`=X?ALP%Izh$R~^hVxV=k#;-k!nX<_TjKZ+w>OXWB}R{nz-Gjr$8
ze%8$Sl_sj+kPzplb=HN}?Hg}*uztkT%+LAWt(-STnHL`rAKzk@&BsT#jx@7tHudJn
z7l)@UxHxae^oR+0eVp+vrqruiHEmB%{p>;KgO3f4JSZFUQ`<USR9;;VpS|B>aDa_V
z=Um>WDcgO$=E35dUu>Io_u1;2pOs&B*lJR-%<1j4TRK`4^yMw3?BCPzzl;hvP|<hQ
zii>&Q4<GR&=g`AN8Eb#IkvVJ9TE{cq8`vMp{qA4)wUaU3)dsVSUUe+J%A;7n)@OEI
z>O5@D>^m3R{$xG*UdczZELWGDn@alv74NY?_l`q(_Yr};j9BIb63X++Ox{^kK)KzK
z{v=v%w^ZEz$nfr}4^Uo(%8+8(J}9>^T6uTEt>v4(6}tBvieG+7-+=!uKtd_vN&0M4
z%PS34Y4j)>2Wb#NJ<Nc@?eXJ_^Ii@tNXP@yAe^{ajf$zv8q*FGf<W5UieG%g61+bH
z`3@!HZQlTCJ1gUBN5Tz|wzASjR@%kN_}S)Us9@Y|C#I#%tF(75JQlXJWi1&0TE@M$
zpG*2^#GqoTc+dyE1@sosTR?9Cy#@3Z&|5%n0lfwE7SLPZe~Sfp#QH<~e_ov`AFt)R
z_%*&o`~+2)Hj@W8T`10U;ql1}x1lXO*7(=;RH|c85DJeAUy(El#$TV!Lua@=c<Mq?
z+duNCri`a!g*wZ+JdSk*Y5S;!D-_OJ_xu=yHsLu@o=v4cW-QN#d0@;lp)GiUJSWD0
zInRbNUbqHgdDhDTL%xy3g9Yz`-M}A0AsnJ01|rMxyvf6~jJc5pnP5OU#g<|-QGL)`
zKyLxP1@sosTR?9Cy#@3Z&|5%n0lfwE7SLPZzhMC$g;m4;?e_n)viA%8#|{7?nqY6w
z0HyK2oyxvqF%SAk@D;h5>PC>!8|~vaIyf*S&_|=T9MDkRFG%AT;5XH8{1|nYz<?k>
zfA3(vKU-9Ecb_!c-BY6p_8T=(;~j#3LyL;O-u^+}!G)L7e}d(n8h^GS>(DpBJw)TF
z@pcdJ9Pc^CJHUIqCO?k!3n)XJA%5e%0w;&??c1Vacj>C&nLl>4q|*t%wf{VhQ^oCk
z4ENEE`<ThQ1_^b5M}BdWpz6eT{Mhm3<dsBzb_#}#b*G<%H$x8l`;DGrXBS98JT-yA
zmJRI-a*ajFyBN@&OnK7I<j?yHs2z5)txAk_Y=xF2PyLE%eEmWsANgZow<jNrb*uDM
zIH1d~d{>ts`Q+7xismA!2E<D*oZpG#{U%KGcK7x63~~?B1pis~n*4d`I@sCe|M?!0
zQfxpr-w}SdfxHi@rIhz~8^|k{A1Gjf4f^VAAbnmX(1t<9Yar^CN_ABX5m;!SDb-uI
zGYSe*cp1@U-yrV@f6Ui;B@g-el71scboua?1CU?_w2P3o7Wv~G70$<dFrb~?jQ6)Q
z$YW9KWa0fG<t`X2HBVRWgSv9>MZ2-@916<qnSTt+(ctONnDcTl=N}fzwxxZ_KL!Wo
zcqp$bQSnlKIu=fS+p=#fR#X%DfwB*Di7+qu8KCsUqCb~Z0z!4*6`-_rQG!G1@^TD&
zxV!&(h8oz}d9>ii$8Wra9EV~Xb^hva{hG{f$r8z*OMbfKuZ=R_^UZwgKjgP>u|MXw
zU<_qT$s}PZNWF=Kp4iVSNLPOgWmh@l6tbNqao-UX+lj5D4DYg4cU_&0*KJ#l88Msm
zdAf;hvkSKU`>xC1s-2yecfn31?!SA?Of5Kec`qxW5lGqVK{Lv3GNI71`(BP2FK><K
zXkU_7@+`;bKZf6rb2Wb!uJ2+?iJyP|kvi<}9>l!VyS}=5w@*%5gpE`(Da)s*90$(%
zWuZ!Wxd(EsD>wuuj-MF9koEa?eQR8AC8J7efA~@MYc=xX%;Mn<<Xq_Q86p=*xyZ0g
z{&RfupO0T~p+7%V8B`3#-bv)sgS^em&)1u4P8%gXKd!EF4mGH#CSDlGf~~r^Vh1^1
z-&Lmy)=6X?noFu`1S|VcIR+g5WF4`eP;e|*iQx!pkV!d)Z&4pTLJHM~!sl%}J9fr6
zWuICS_aDRW`&5pFjJM9+1@-WTZo5s0Ba@gyId?}D-tK#;hr!<d-ku@eq%X(LyU%^U
z=h=aHh3lc%s^Hl5k_$e;6C}@WaD(!t7tZq^ZKVmG@}~Y3`8as{dRK7X&(LjOt=oRV
zzH-+5>AspcUfEmuW&d~fR}R|}KSTem@k#4+qHY$UFURaI60dfp8ee>8Tk^@YbDhhp
zHZQXr-Mn4-mo@=Q$~J0XG57L<Eh^RDrO(Iv9*46*SFvB68f$|OCz$s2U)}IzeAy+t
zHa+`3Ic33-N5htl__lUK<1Eg<G-6d7*w4Sb_}-Q4)hlj3RJ!YhYd6cETzK55UB}_x
zE)8nVEc-1NwfEiEq>Pfk0c%f9IJ*3YX(qkr&iD7e`2DRKQ|~wZw6|AEG1H|l2M3z`
z_xhy#Paik)eUFFvcNypMBo}tI!LyQkuFX4h_;Hh0i{@RKvap`p&xadSy>QljNzclk
zlp5CfE53Ux^)GPI*2})@`}LSHyKITlXRANzc3^rv+l)SoO4aN&zq5Ob&G;O6&wXo}
zb(8!h<bFM9yvFWM&-;TP?C9*eYxe2*mgn}jwi>f@=*A&C&#W$bALpX>)lt=w?N%S^
zeChZzzn%>%W_&Pjw&jPTKd=Al;QEGV1D=oR{L8BjJPZF_#@Bq`<7U3^@i2?pm*{=>
zy*1`8Ty4;%glB!9JzG<vJN2LW!^pUqe$Urcx$9dcrbU3cMP#raep#+5^)zqJ*6CN*
zZ~bM?)G`M?s8w&G$<(a-O|D+Al(0Yd`KC>6r_s-VbF|vvugB39ClKoQI1Xn~$LaoW
zjn`S!KEMCh#`P>}ALpWu6aT))^(<;%=%S80|KA!Xw5WZx7b@4wS63a&9&H#u>|mva
zqf%T?e6#COm9LYJk6N^AnbYPa&3;ay4_J3OeouGu&P(pHXizi%rgIEG-BY%jHs{2Q
zX{kY%7c{)HB5UhCo-^Nb-@SMxf92QPsPC&ozqs7~enMJAqgypDRJnX^$DHbmC;fIa
zZKL=SE9&^9_m%XFZg06))_BI@A8!7(ZngK*`cJmh+Z*BBC?)jxm{wgZ_pK~?AL5q%
z#V)sE7o7ig<nzD_zvaDd<=}WU&9lO)3T;zHmP)pJ)W>7OilX-gENWllqV^dqYM<ny
z_AM-G-_{TlvCD%C`$Jyr?38`xO2<R`@lLDUD0&~sqV~NN|7&W4ub&LaemqIFeO0yd
z`*yFbW4L#Cue|I^Hip?9LMwOA&SqZ}wa;Zy`{*`Owrh9XzQwv?+f6s6^u536*B!>6
zPh8wLCvV;9N#9p#R;~PR(~I8s_NN|Fj@zx{Cg{gI{X6=oYR?N}wLz(GD%xDiJUlAO
zMV0jIOc&pK=k`=jA9TQ`_tD8NdE3&5;zL}iR|`&Oe7n)E&#>$DI!+k#ym9&9MR(`r
zw*2VSoeOi04zDtNJig_Wcu&(m4%g1Evv!R7MR!-bPlgX&sL83*t6yBJ!7nv)>tATh
zyLcsD*TdEKnBBHIP&T7mPOly|^FB3tcA?ikw}!KWCL2}Cd#&XitrBmd*Mp}cUK>69
zz};$~>Fw3ACn6S1*{afycly_Tu=V4e_WopE=(X;hKK<;+_2uVx+_Z7YtXjeN_U|e6
zzSf?&d0t1WE{&cLwsgbX^2;^H_2Zq2UEBu;<r)RqJe-(3rSxovd(D$?Hc9sI{GTx1
z>1*Zrx8#Y>?3_O+`SQmqV^#4ThVO3{_rpB<mp-EhX>1ytUUmN%zWw`3IZ}oWy*Ij1
z;^XO!Pqgz5IcXVk_<~QApTpW^<DW0PvNOd9zxB%f^ZK%1b|15Q+a=pF<Fwc2c3gM(
ziv6*r$A{RiX*Xu*qpCM~&stO;a|@O9w*0Ib)kPhjQOP#y8`Z)Sb!MeBu-|fO_|CH{
zp3i@IWJ;_`Ra75y{yg)m4eq5sS>;n|(cOgB7e0B=E7Iy)pM%Y6NBo?$aa2O!l^JP#
zJ1DBJx1#!RE2?j{qWXFhM-6I&j}P|$_=-)Wd06^d1IM<WM;)z>yj-y@c}B|SDHk`q
z*t&^vIh6f2!K=#hOZ!baj!Bw+rooSEuC{4i!E@Aak)uy9o8RHUXER5sROgiI)&Pge
zqqjU8`2C08>W<GQp02vCsq@YQHM>4P<z&}p+@%?NXz#*zBeg+p9ZmfWC7xVsIWntG
zNY~h9t*i#G`*NyB$eu0t)rnsW+VTE<5*F1rU{QVk71c-I`}S>jP^o{RFNaTvi%p9$
zuQ+nt<Jo)dYVO|T*v4#qk5yj<*zIWkm_9{C^?^6pTJ}eF{D6cbE+)e^tgb$;^qk^h
zN3&8td2DA^`x8%xmk&OQBhH4Z67P#NO^JoJ3l~=`wL7Z&PyK$Gy=~Xz?E0@3+!()N
z(}cO}x2aUWDfzqj>{Hb@KQ`ZB<9qTuuZS&=O6{3lxyjxURtY}!i&d>*d5dx9m3Rkp
z?b@Eb*s61_*DrE2c4_NuGV#3Y`K)K2bM921%*ZY6@rUaq+f6ZZ#i94So14wElbhPK
zx|bEu_t*#aX3M89jC?h_MNSmH_mp_I-Q2EOI0Riibs+WQa_7^Qf8D-(?Uyf7ExISS
z>FInYeE$3Ql~+{XcJJF4T@no`)CQF&y-X^<tKPLI)*oGNexX^XZx32Lx>fteR<|ZI
zdj)?O9mAN)id`N#1;j+$(&RaLn%KAeCdlQBO1l!aEPc>uROZM|?rpcwU++^TUdLK9
z9{hGT=;Qf4Q&%@qN2h)LYed7H7gJU|J*Am*_pI!TqWY|R%sJ2sbnV%cc5ck7qzRRU
zOb{4*Kr3zE`k;JjRWY338{aUxc4bO?Gl^SxJx}7vCt(j%+G33=w4SalmeNKmx6~ik
zJ5CqB62$)wl|~jP(1Lub^V|L?ZL0X|58E40`tsd75S6x8^c7Uri(p#U_DFS*>1-00
z@`Ql|Zk3hwxV2H%qsnVBHSIW5TCq((l+V1<4^hi!T=6ZebwLNBJ}A@L$><>TBXlsz
zClA_Qs<d(F2y`zx5|wgTg0Ah6(w;%`BhB_W<tkwa@uVEGzQp$hUE3d}O_0PFySjk{
zzV|EfIlXJEF+Un@f_kAGnksLUve2ecaRaUzg9b5Ay4u;O9~y~{MGNe#Ywtr_4bJgz
z?VoJokp<PSD3^Fuj&3~%rgiOfl=eH!Ds6~3Eh%A|ZvQZLg|gmsv^M|DK<lA1QQ3Y5
z=-S9AZD*vsoYqw5K?0{urM&DzWqfw=ZPc9Q)D<m{T+(JqI}Ro9TG_{3^0bRk(on|3
zrd@(|74z6zyA5SuYm-nuDJlD@4tkRLhNxLFr7e=SF4~xR84sInX{}M}hE|5EY>860
zRjpBfv<*55ZHq2I+o4NP_Jvm30Chm6oNCauV^OBX&iwtReOj(Ao-NCC?M~i|iEYR-
z*~b#_v834JBb2hK*rv7tx=?3N@>$RZL}?rH_Wr!XcBH=DMWs&NE0jN7+l_bT?>X_D
zO7iS#QB0Kuf9G+N3&u+};UuUZGnqO^WljWpDzh&{g9?XYGFF2)7K?*aFmd2q2fh#u
z$&dwRomdY35Cw^l0VbVU4qgxq$&d-AoOta)#&(E-WVix(VBVGgzzxD61`fd$$OH3k
z{10vr1~G65u7HdOVF8X%l(CTu#!>#iHb(M)dkpt5PQXzR2m2rmG9U+xIrmsXSMY!^
zh=MqX9Y7s`w|&lqaiWWXeQ+MK!DIyYO&s4&P%tL6j0c^>1*Pzq&~J|i9m|QjU_9tU
zOpD*TJT2Rt^+*487x_<o*u85!Xz^#~&vxE54z%sp`Tp%3!+-a2XEB#_xL!D;hfohx
z{NCk3(j4l%(eM86GFbmS{}+t?EPn8AfZ;sSMb)SkWTfyu|0nXu&C|Qae!gMM|7AE{
zC|?|!1evUt%Z2eM)8aeNY(8m$>p1oW7sIpw#&_n%%!8Y<NN}7`Ol2EfjIlnrI6;`E
zm?{rECbG{!AM_T`TR?9Cy#@3Z&|5%n0lfwE7SLNjZvnjp{&fo!XO-8lb?ceX_mIb{
zbLKp!!39Wy3A{9&C@<M{;jhMFmT3QMEat&Ac=m&WApIjR!jG^AzJMzr?Wd(r_D^sP
zq#xeTa2<XD>9;2RPNlD(jBS1!&4fE}7w$n8+z07<C_(yGZmPw*98~(tZf1G|Yy;^V
zDg7Bg<3q$2h-aB|O~&Se&zRm0pF>U7lm2yTs10?XE?7W4s1F5Yl797;&=49yV`u_R
zLGmd5R-1#2soDZsg5;qUY7H`uyban~mP0|1bk~!Ytq=z#crRcC2~6+Aw!2{u?1NjT
zd^-Re>^V|Cdgy{7%fx3uJJJ$A0Ue<e#FEAZ*83i0+~7;_8}T}l7hyN~-U*u_00N;P
zY-Rc&+gS*Updbun`5+hq!=NC1#`Ncf<_|D^5RT}Uog$4>OrL-iZ2K1TGUla(WR|&u
z2aE<Eknk1yjcz&}Jp*TT^M%J~m$-k2aoVLErj)O;u8cBYnf>)46okV5Hmk9`dZGVn
zF|F3kSEhbcDO5*VF>RxpFYE`j4a?f<mKPo;eFyvKKOHN5Ch3Oj(k|><v>oMZuPdWJ
z|Bu(jkuqwSo~)ZM?1OY6%OZ8lqtI2lX&HlE#$BI{7S-P<uZa~uqcLbI+yE2KmtDaH
zVjvsxz={*AJ$OJgBttsvGr;F4@5ao*5|TiCAsCk+O)xFVHoyb?Arzt^77`#8(jg0s
zN)aE_U=K3>y7(>CLJaH!8Gk(;vcQP<c&1<lGTucP@8Xgn9i(5baarEYfh9PD7pw#s
zgFO+B!WGB?Bi{4L`0Li-3|?T)M>k8b1_y8hU!ZHRGX8oD8V^a34q1>3rhKHcg0A2J
z{ty9ikO&37RCAa%;X_^%umu;$<6MwLoy&qeFssD>-~cY*4-pUp@sI?`kPbQE$o_YN
zSV)Hq$bwvu^P>rvgDp6N8~B0-!XW|n!BH@$KKVi{SaAJtgOzd}flM$nBMs2PK1hX&
zkO|p*c(mfftS^LuDIe)PAO>X2_f#;U?)yS0go9iUtvEOPLKfF33(nitpn-6Zu?}O@
z>@&!Mh}vuqWUP0?I+PpYVIP>+#a6Hq;^C+Taq5viI6xjWsn2yAWSn;U2E>Oj$O3aq
z{s%22LNYk;aWn!}f{eND2L6x;8IUd7n6fq@@8AZJa0t@CxG8CXKZHR9q+5{}uxi17
z-~}ro6)u9N750J*$OcPm>;M-b6T)ps8}h)IYn?40U?U+0F4|$^c9adAz|fv)aDt4E
z)OiQugCk^vc_+#RS3upFJi#F+{sUDX*6mB4VI{;ta)0U^7!F{aft1^Ya)T>GLJW8f
zMj-)=T&V*P2{91l#=e472p>V7ARF>Va_qQM-yssxAQy~0$S(we79u=3XF(3+jUw-(
z$s<I<AxMLZa09X-4~)FXC#b>1TctD*F!7-tgFncCK61~{9+i8mZm8Ukbw}m?tcPyC
z9V+)*ol&`G^GD?#$QG6Lq~Ej5k45F)#vYY>zj3JCBk6<Q0(uMREugo+`?Y`}$&Gy9
z{{P&4{6j`f^idoDlK$V(2jGV)ql(?Qr*rBwphq|No_$@q_2|ZBT~$(*?;Eg}&cBnU
zc>ewxigLTDazU?hUlRLqSyeF}TLS|E0>@*oi6Or3p7?s29PEdqv+;rA^2UC&uV-+F
ze7`ro`N_QftMhkOv0@Pa$g_FBVxwu(R<U9z^KbiG5<h`jmiu#E#UCD?5c7Qp+M@aE
z`Y4;JNjz(o?afb*On8pg;BYa(Gh`f#N#CHNE13_XER&f(wM;1s?LzZ?hiy>S3z_Vv
z8SU$?3DlJ-Akd5ZhXUVC1^%yA8c2#N)!X)o`lJZ<nJfl!*I**WFVX)r8--$@Xv!xx
zI<ov<w^3(Z9g3HOln_UHmC+dV26afw!x_6FzshjD`LK`vSab625}~a94?l0}P85F`
zQaKCi&PwLrRd-@p{&wAwdQ!OVNZp8`%rYkDhvf5EejXJcWA?<=0NY`|g(&qx<2{~z
zm+v1;SAUiN3aSm!-_)4`d+aMAOL_N2`X8d}(VN&Kea)ZR<4sKw|5-(`$4A_E{yX-t
zB0q22BLQ0^k>_gUvr0^UJrJL3|EWE?>*_~hNwJ1X^%Ba!Gq{C4tkx;p()o(>3&CTm
zySMn0^KtjV!Rj0Dabgo^)_F%z>WG|AJoxkNIw8v~SuXE<`V|Wdarfm6=I^cSPe+!^
z`4JmV3=YQqDlSh${PKOQO4%LW{O?V6e*dq$s%^!e^7F0Aqzp3uR5yQ@c{zU!(D?zB
zcO4SifSg-ff-e~gidD+}2bYciaEA2^4i23B#stdwL(YTm2=bUoKJxRdtE0*}R>~;v
ztNRu5(J1Fwv1Q@oMDkqVcU0cLNO(KX$wkQXWIwMrJMGW?z$uT#|8ahE$fHLMz0b6y
zQj<<JpA|OnMEVHL!U5fv45`}kU|LUnLvYbi8_Z7`UFOT_NAFJweSGwCLXO$fL(iS|
zcfUUQM6mPZvgbQvLq`sBwLx^#vf6vo&Bouc$;&M1bn@g~yPmt(q!~OJVD!b;Gb~q3
z;TuCIiI+aX<o2_bs~<dj@WXU>*M1#tRd{^L^-#4oeS#`iGfUdc1zYbkP46>p^IpDN
zw3qr4X|uNJ>yP@l1a>%e_Eq%gYjLxCzdn}wZOxNQ9%MJ0@p)~PO7Ao6oA{8_)-Tq~
zT|21Wv+0f(KRvtQ1@E==KGRP1TOO@_75hsgqf0-9rHnmw!sz2OyaOC2^=f=(@nZIs
zKS;^A*~0yYaStYKnb&2&jNy-FoS&Do)wTLQ?v1`x&TB1)Y+vxi-nI0RJ|n8!ukdnV
z&u%q3Hb{A?nfdaUj4kn%=kUFyqomh%aZYZ7sWmUV-Y_3IyH)0u+nR254lG`|HmdKk
zRn_V_P2jyX?_bph!9SQdg@<=H3>kRadsC;MwT-)(e7mLR+}l5{urkc?Xr4enCf?hs
z4Qhrs)u><ZcGWnSspI>3O^sNj?bGDdlLvNlQ(IK+TqEWY??$=6stxYcnEs$oo#Ww)
zTbRUs<KFV;rHfL%do1hn(b%ljdj~$~PdTKGzuMqM==5^|&+7Ge-ecItCp2Par*G0P
zZ#T)SSE^fwX?Hu9)~Zy!m3Z67?5@^s>8UT5RM?!DGTo(P#GNNok8U|x?(5#G4xGMu
ze~C(^_nD^mnb!1kzG3tJAKxy&<y84K{o1vc{b#j1Iou-a=H<EV9U^`{@uB&ynN5zG
zE})$S_q1w*c>Ct-D&5{%cI%Hvy>6;rOfzm%_0ZG36-v)<9T8mpz^VGQWl+)^r5)J6
z=dtQz2k(4T`bg_q7U!+EY)(u0sAk3VM&sIRZw$caO%F-$uj5tadxY9x<WjBqgDN{G
zZd{Qz__fiLQghDdT~58w{PsbOXWDPASI?#YqLN-tw9iJfiRXHacPsvDv5VEGhCX)N
z-{aTsZ{3~HX!qcxCW~qB;2`N;X#Jx7(3A(Yml~UvN**3NFv0$o&FuwI*X>JRnC$xG
zMLOSjxG7Q_^e)#f#rE!Ji@v++@a4|ZPhQ2HID34@$KTsIJuS2N%8T-Rhtc~?i$6be
z{h5hbKb-B_tfs2*!e!w<wB=mt+g<Eudfq$!Y4OKxom>Vzompwc;Jg9D>u-;-T6ON}
zk6n(xaOSzFi*kP&t_?T6^mx`J_nPkWr=3ffT>QM*oJH$4XiC)lW^?G8xrb?s!2`V7
zVB7d=>dIdo?U)_#`qGjQHkR0A6usoTgpX$(s5h?OtcG3I(Vl~c8nuDmXPVw;n$&~o
z6TZmk|J^suPAyNlz2x?)gLwwGcd1W&lo>HCY<>Ah^6p3PGj02ItHtWRJ<io@e6rEm
zausT~32#42rFzH<Jhj1(_tHmaTeLq@C#zM|hn{CXuQG7x_JhUNm7C?hzxb`EdY@^R
zE^qp*p;ezxo9EnHyWacdtgWTp=GJl;#>>v1l<Se+XW9@in<jdnX?mY&>t>9b|LCi*
zllQvs>KS9IQq7^QgxX-N$(?NH;U5Lq1gs1gW4>(7%tQ}$r5mGL^n3PYx>=)nwP<s~
zJ1n(9>Xp?ND-L~LCMx`1MfKys9-Ah9`^l6QR_6VR%{=N9wZw&XmrA_;(=Q%sQ|bE^
ztB<GM+jnY5QoAO@tCabz{nhr1>eZZfbPV@?F3NWGKGPb`t-Ln)aqmxhU;k*AJ1<eg
z75ja4bLp6y<EO{oy7bgd?=!9Pcf7BsuJYVn_N3FX9qLn8+FvPt`05XL+<qGQlbc(w
zhg;M^jT%iHG?i})y(FIAXPVw;n$&}!?G@{*+PP@#_nld5b!*YyD|x-IeOcGQ)TZ@L
zpIZlNEmNuVKGS-3vCbQ`?LxrHo1cbsZ(yI5kXwy+dU~H}@#eF?xHjR*kk5}sZr{=N
zRmPeS{0FM^KGV)Unf%?R!>WNPQ$IWye6CLTnqDD+eBV;u#~K}uY3O$6^`+xxgDP#<
zZI%?&AhGt4q>oKHTRlvz{bB=cWL3&{D=U}syGLxB^6jP*D@#OMU2`lyZ%@xJRu=DJ
zxhQ^vw%S#`BmTF1rnTh5u-YKgYsAg3zHT#SY5O5#LhJ7TB5RD*ycf0h*=e5d%-ot{
z&3WU$>03?BbB(S&kkSrDd|C17MrF!!36p5*A>X(8OsM$onudBaKOJRSH4|Nm&O&#g
zv(Xfk*YDaBXgGQjos0g2&PQLP5omd~@ewLMtfJ9o=yKE^U4i1}M70VXjIKfP&!vh%
z#b?!8G!l(P*P!dsP3R^x3Ehl-jmD$r(a+GE=uY$%x*IhqPMc=b20egwMGvCA(Icp|
zm--TYOn${qx^_W&JN*+oVb6lLK}wq;sZZQ)srY=NgpT|z?T9*~%}`z`YC-XFw-@D>
zOM4IPjaJ3xG-ua#L3w4Y?Tz+B2cZ2?{Ie;(?q;Kdn7@b)K_8++(PHG2%a7Iwbw}Hx
z9;h4YiH<~lP-)ZTi^_hM{Oj8CC~bV+mH!Wk)0z0qQOQ5A1(f`MflB_fP|1IF@*(-}
zj!ORfqLTkXsN`RZ4nXIklK;!7<o_`$`8OnAlK--(<X^@M@<2UNPjoaY`Ik0G1^MT=
zDrkG7w8@eDmuFcRNMKr92Caaq(TZpTlzpOQ8{+R!@flbRm33;O9K$L#Drq-H#YRoh
zLud<>SL-T1C1}s1t<h&_8&vFR1-dpdO1l%uj{(apKtd|<Dxut#Yg?kn3$3SXm-5c_
z&gs@;o633@P>+&)Q^Tjy{}o?vdOvSmN7~b;2mY`5dCO~zKSNH8aZmY<2f3j4`9_~1
zPMlWY1R98eLy!q3oJ?)OO-`zi1Q$UyoHhX93PBJ9X^;aZZqzMsfeg;ea?c?53DUOu
z|CP_T0$*>LoH*a*?=6B8`rAI=eEAOYw%@mvEc<7^-)y-E{F(o^j0d#S<^1ZvMNIs_
zg~Pji!Q~J~{J=^7P-}1jrzP0<A?q-0F_%1`Mez%Fp15vCT-&&Dj7H<&|AlY3=t{*^
z2_F<!rI{92rB^Pl%AhfEZk6IHYcqDbKIko=w}9RPdJE_+ptpeD0(uMREugo6-U50H
z=q;ePz`tYxd73Wl|Id;I@ACO4KKI7LOLzqZ;k8WHU`!Gy4hC?<g#Ng&p8v#uTRNP9
z3s4X?@Lw0`ChO}$9MhX%3;6L;JRaQ!Q(!8D!3>xM;{RwqEC2}!=yuoviLeVK+-941
zU<vad!zUnpdm~{5)2l#27W4PvAxOxr&bt=MQUXeX_#!NYO21Ac^eg5|qh%n4Wlj)J
zp0`0yrq{q)kkA*EG2;irP#8p<!7v00f-LU}FQG0xh9@Aw5^V@gpgFVz39r%Oq+tjp
zb!my;oo-C`)Xn!|zBHJE3;7rfu3!Z%p%F9&39V2YXaj9^%Z8#8AVfDm9Cd>cFcLh$
z3$~H|CAba+A%SUo{_6k|#-M&MPB&i`+ZjVSXbvr)71)3+*g-pJ4;?}5+exO;E@)Ti
z4vx?ZoS-lC0}18P3Sa_Np&C>NbEp9|p%$p2Hf$!{I_NdDE@}bwpguH!hR_(Af`p1_
zC74NhX2V>FfQ7IamO?Zvhn27z#Ghjf`YFVMgu?56KzgQ789sz6U<MMT?)g~qE)M4L
zQAq3{{g3A}eGWYj7vQh_bN;)&Ilmz7D<FQEeuBb2Ie%gP2HXVk|5Q|eoRVHPA15#K
z@k;z+%%UvfcS3wf$h7$46u*{_P(!pd{K|AG^ceA_pZi?mNgs3vmbakJ^+Y9fMx_tB
zgzo(B2)BtZ{mSov^d}cTpE-~X;sfCqmWgkLIixA)iHb~%Z-H>;#m8n@GyDz^_gy|V
z|IBCRZp!$t_{$tf{6V1imC1DlI~YJgFlM?!q4`zp(+bodX-`-Xo_&D7QYZ+Oi2s3Z
z9aFS&q4ob;elqV<pB_R%s7szKbor`>x>BB@FbwK5-vBIi|2ILKL38-u;A>N^ZE{_b
z>w);)l<T7$i!v`hIOSR@*C)A_6xA1J6Ab4F8i)t^9)1*z`99<ZhX7|0%C{nORPJl6
z!2zW0K^)uwYrf|=fD<G@9*AE~ThPLJFz0)@Gk8D{tb{m7ghPOP2bBq^!3rF}89cz)
zh-vTue+Y#LFyecWBe;SWB)}m^gDa2;IS^Hr?_-b&;&)SgZu&wfghLc0Kr*C)jK7l&
z#^tzffcWBchHyxOi;xL9ApSNZAqL_h3krN|I?^~H2dvpI9uNd!Ap7hFn6Uq>!2^Oo
z24ReXSTJTEcLf*l0`bk7$2qeJ=T3WY1o44+6wX5iWJ4aPs}c`n(7q_h0@G@21Eld&
z6vRRt_h)jCW<;F{f<qwJYin=-XYhwGh=B88#POyE7l?!yhzIeRsf8$r0pB_(B!KwF
zJP+1&Nf(^J6*Le9agYdy;3C`rX;@(lW?&7@kPKHK7xvZTzxvcOum)#11gUTyG9VAk
z8ej{sg|6TM;&U?sq9GOz!9{Sk<Ufc2mxgQ)(%}l^f@>r81q4ADL_i!Q!+8*2oOxi@
znCycC+<>l4NDn-~A3`A-;^8P{KocwM0pSn@agYRAkPC(_*zcf)NDx1rY8skoKpKuD
zK{DI`vsTyzOsvT-Xg~|bHsk}mK>Tj|Lp<z*qmT|+kPD`5I1a%HT)_*p5Ci+*JY+*2
z7}-)@Z~!Opg>Xo+BP}p$$Nyjp;uF*jA|M)KAq_Gh4@~W`1=xcNXg~{5a0pVtvOWJn
z5*&pl9k49~K^!DPDqMt2$OV&*tOs4e8N5IP(GUwsa1?Gp9+){$ufPGEz!iKU5>`SS
zBtkM|LJl}};y*|SmoCJGRJaIcT{&h!3yF{n>5u`L-N;*a$^b!N+=J~wG{iwN7&-Dk
z1VI>F1k0W*gB!g#zxKusAmed|K_o;wv7g`uX#21|$bdZP+Lv-eBAE8W9uNhwaLAcB
zVA-F22I6nkVgPmn53n9ce9*uRDDc4=>Oy^jePBC?Z9)`S48|THep%z;B4mmVp{%at
z9b6zBlHe#94kZon0%`vs1CFM;kr%KW!GGWeQIHJj;O~yTAPKU-)r0y93E=2STu6p=
z$n&B+-joMoe6SP9fUPEw3ephG1mea~KOql{{Ye`#ARA%>C_m(YHkAM1D5$1V7r+hD
z!E_qi0uPXO59yEr*^mcDVZ;FoFq}?Y@PGu^2dQvFOC6d;*+Ckm+JYm5K_VnW#9S28
zp~-yg35k#l(F-|`K^DYEvYkb26V!_-DuhBJWP|w<)(1C;hB!!wBA-ji1E@bHkKh4`
zkOA3{2S&?C7u3)MY@sVSgB$pQ2DA_fD<KY|qsi|lD4d6EkZ16ltw;xzXOudqJm1_g
zAstJ~qSH<+m*<UIy8p3|KIko=w}9RPdJE_+ptpeD0(uMREugo6-U50H=q>QxEnrBB
z!~Sjm|NeoK{Q})W12k@dqsICKd%JlCc(t~6^9%GF@264R|Nk9*{}=f9x6}FGPAHbY
zTRI~~&>jZzF4ZKYw2HsRcx&84G+sLI*zSJ3y~+2>ZYC4|7#w!8O#DczQTfK(uUNic
z{(L{u6<ESM2m|@$n>8CKg?@@YQS**1f16@|KTm(Zsow5><9)qlPyw%er{DQLx<d*)
zUyC2<i;~bk1|=WjtJ{PBWXwJBbL|<dnHWTxK7o8s=Ra5e8$wyhqhD}{roaWb;vd_V
z|I{VrKR=DKapq+mUVrGym7f{+(SZ}kYj{V(e-`}5B<mDp6i@KFBCuFl-vRw3-!95F
z#hJPMC;rH-P<hv_Y*XitTzt|eVjnkbc9Z`bYLxx*#>V;E%eS$_mG45X#N9|-pF(k+
znIER49pp#xmAp8j`Toy?y*>Tk6kjF#N)Z3$Vfp(+b(K8J{0?23N0^s51%BL<<zOT%
zBd;>KShr8L6P5fH+NV?}zd+r_-t0=nhq>hE9YNWbQnql)6+`0Ee>*%sUBwQ++x>St
zWD!^TEBO$2qb{!a>aWcP<oi4}4soAEEi0(oEHBu<(uSg7AG&L%1j!DPIxYLBunlFO
zNj(|&fyDpahkRlCnM}&xUmsP^w_jh~e1ZKs=={Mul^`KP7ZCgL>YUomu`*d%U*`|L
zkQtTJSN^dmdHBcRp!5A+qT-JHG%TF@wpHqxn#fX?e#L^lLniu575c-z%+}?FEVGAs
zuP6}+83yI$obV@kvGDO5Zz0Jl`%*0v{}4=Ow`5s)Rf&o@`Du}-Hp={+H}kFkkjK7n
z<*~EQUNMp}LNLgAi&w#_f$WEjKiF&H_<yw6KeJiB|9RQ34y2b~Pu$&o0)qoQdG9QB
zFbCVLWZR?pKQn(@<Ujv>SC?hft2f6_4)f9$$geNw5`&bXL+_1ll=ygh;}h+CLrz+T
z9KPTa<>#<=+4$$nuIx;q5T9dkwLyz36JBpwJF!EU&1cOwe>HZ+sG0r0o6+;?neS9(
zoeyl@Nxbjb;c5d_s%HPJ^%l);-21BL*gIqWe%Kb|({#4+!xx{OzB_k~!HxWH5^95c
z=}%Vqlv;E*q4kAN9`uT|`qt-Qv)U0qCv6;+5O`%q8hKo7C+UsIxD<6<>(+2z{nqIz
z<r>W}Sv&L0mij|yo!Gm*;=WUN>eJ_(Z%%51MUy^o&nf0`?E7A&&xHKkAn@V-u}$}v
zYBy|GU_Ij=t)8#qqM@Ys{`}q4F_-P;*3s18P~yq8mLs$3gmjHv*2-$|x-X}CgzVXJ
zU!C~HpdI<&&(sE)UB3<X?;H~FtZTR3qx)Yec709SgXu%=s+UZDS}pFYol7}aE9F@H
z`Llyn=ROI~v~n4(_dD~r9Ouc_V&|LVLLMgU+O~V>sG2MOclw=K=q%;<Yk#ltO1$#x
zZPfSGp<i5Xe?K8DqS37y7ph!7w_{HA#gl%!nYJ;NGg?voty?<Dc2mq;)9b6|-P~-R
zo!r!>)xE5MzQ;bWH(Ne^VdSgXEpno0tEp_)==PR-WsPSX{^90t>sEU|t^Z`p+x}TA
z_m}jZ2d?j!H)%_JQox|v2HVT*>%8OsIfM55R)%zVJR;gEm%7|b+3syOw`&#-L03;5
zNd36n`LyL<w=ZA&<%?8{?#XR>I^PNBTa<rINw2$;W4F$OGpczlp8U&y=0B&UlD}KA
z3(kK#@_FEe-|}9!a&SDF=2>A?g|;apOC{Sq>f<qC1?@tI$#!GDcAq<=)S{uMCiNYX
zo;z#fFI5bi8fR^9X6tQW^~v<Bk2w)_l6e1f{qg*_{Onxfenf51?$;A8bGr0caJb#=
z1|u>uo%a6h*)7g$P_(^ki|f0$jh#nZq{_<v-9Omo*(1%%fVM5h1+VK~{)^&?hmAk$
zt*ZJmwX}1K6ux_UbCaPqxNjN1)jMb8iz?O)ukPD8r(MRu$g1&EcMqDqrA3EXJC~(X
zulTm7HkjS)r?t1nPP4U7PdH_Gs!Fje#~W)K4%k1Z&e|5`X4N&Q!1+|!Z?>-&?mrUt
z+uA9fO?LIjd)+4NZd|h=KIwC(X(z^;Ph5G0cBaa9YgelA#do$PpG-T~xx8xgGRx7;
z+m(N56R@OgqXrgpFE7}_wOrY*W8G0#jEWmfcwk&>ou6%NURH4O0Lvb`+m!5lcmK=4
zS3$J9G?Dz7dhfQ4tTUk3<d~{geklFmbw$5rXRE1vZ?(0oIP2=JE!5HDJk+QSe9wk2
zQhnaaviUCWhzhfO9`Cv0adK+?%ib2wo09r;eSnR7D%a^{dw#ssU`xrB8y<$7JGbHN
z+zETS&M;1iyIiN;rRL?H2U^p1St;*|8dXbmZ+oKk2fhDnoRwutIj$z<#wBgpU9R7w
zp=~=o`FM(l|D?S?y54iL%KG+7Y>jn102OsSmZJJwceI!CzQ1u>it5k&eUI;AgRL1a
zVe5up8U;RHxqXVEr}4KYmdCg53~sx6NX*tUmC9AGmQ{&+awXnh`vGszRnn_dV{P!^
z1k=9$s~et-FS}&drf1(Lrz|+~XxOq5-_~wuoW;FxABkr_|MKE{SFTsDxcN}&t{1M|
zEPrz0aiew}hkLs;s5!Ijw;XE@RVChyP|rz?diUSp8?#{5lm*ph__i7pl3_o0hD-n8
z#819SrTx-0rM|2ge|Y8>yPMy>JI?-gU|9Y8(LS@yEj(XL2%7rU^=SW6ZnVc&@;6}Z
zsR>7y|1iy@_uTpV@nZg!@nU#LV}E>nu>Z$bY$DCW($^X|w)H&fXm#Y}ifzd=QZ`Sy
zxZ%atP49nP8R;LPHgKJ1JwJI%#p7jut#taujn~IEZyr;!uG{|gBbWX7{qn~_9FvEX
z{oAZrgZ{%`b+@p2Qb%3q=8h}jn<|v<IDh-~>HBsZzpHNY1?|9<`WJKL#Nv{-#!hK;
zY^O_$PFHVv?Ej|jNDC+9V`Yw?OHf_r0c4MIetDsp5>?tfa(v&5NvD&_pXs~(+{7N0
zTbJtg>Dr&3nS0%TO&gzflD{xbrEAX3_ug%5y!?mna!YL3P|;(}C;MI|X-YUe`{>7`
zr)W>3q&H)!T`PwN%UTWH^6BY!k3X|gDM#R<t(Se*_v<lZcG(i8&sKlb?ZEVUwi$gE
zm8#imerNX<n`w`(JO?z0>Kj$sRufYx?#%5@J1%%tT`*)r4~vwm=lsuE)v>t7bA|Zg
z!=I|%=MP)<9-%r_X6(;ZieLFU<tOjo%9tGAmegw8igVj@meFpwo5V}V{d&-NjoqD|
z_Xj`N(b;v^?9=fr&+Tt*HD>3~jYD>xSxw&s9-h?(Mps|Y&C)(<T-mqH!FP`r^LH5s
z=Cxv%k|#d1bN-;@%O9(ZRmFE0zQ0-A5A*C_`ivf=v1xF6)%|1CKPBG#8!x6~cd_&O
zvR`%|vwPbm+cM*{*XDLyclgTN{$AhrxH1cs?QZ#5HL8m`KBJN?zAzV_s52|2f&G?K
z!*`xt@qGTvBU57OM`a`VQ-3<;<-y&hCuqtK-F2y{|GevA<=3V+eh_o0c1Yl1i~8H?
z3!>O1Z_d`~SJ!X-WzN(x2i`pnjP#>Y8)VzJOK9OY+;reK7Dji>AKn|VckcO<hQ;^3
ze$naF+U1R#@_w(k#QW>#%P8eI&o%KlJEO)L51+K`p3j?<eO~;>nHT$vI+7P=P-pGv
zn}@&VxTLM2+TgGKQx|pImj7$xu^21&&uvP0*7w=7H6^-J|Cv9GjGO8Ad|j2hzExsc
z1ejYy2K%wk&Y6jw2RKX~z2(`!??3cbcYHSSbk%iDop&Cn+4cD;C%ZP|F3s3OdpD*2
z?ftxx*N|(DuUkb<n(z6j<?Y~Ho8`Bw7E3(e$bY}-nn661P3$4*h0U@}>QH>XMaE0h
zcGqJZei}a5d1FRy$Y7sFlP_;K8^bm0f^y$E!K=#hOZ!baj!Bw+rooSEuC{4i!E@Aa
zk)uy9o8RHUXER6PTT)4HVVjRrM^%2-y34DIeg5B!vvNQw@99q7dC6TC4Ql4!bdKSt
zd&*YR=A4)@Ej8%!f`)fiWNp1iyTrCq-UorL%uam2HgQAQ7xz7~OO+eHW@oqZ-H!Y`
z<-nGxTQzJZ&_}ML#9R2XT4<Wp-gEX5zdWsWJ;BTORE9^$fCr08kK5E{cpnFI-m@v?
z^-fFodu44?bxT&sm1#SM1sX&=+F@4qlQpv^L^WP%pUC^BYRdin;Z3E^^lRo&yuG#4
z{w^neT<|y`Gj3+P3hoJhebn_PRC`1}8s&Plsa*Ldr|$%e?$znR>J^$8(+S?W-u~C_
zk9gAVE2jmQ<(;dClHL-{b(fDkqBlnL^_%$8Vs}s5?)@FSbEen#xi;|R-ERBtQeTw&
zx&_C6*mmI6aJ!MNzitc)cKC7crA2Y2LJut+ay&Bjv{8y7{XUiS%68x39eFn+?ZVT6
zi+vI*&un^RblXy)C!)6|n6>rxbxGpA8TSbK@k!d&>7w%Ldid=99)kmHTsr5{cUP$|
zTTdGu2`{yNxk)FB3;OX%7V^Qa5g$y{26o5oTdXU#-E>n*-}{Sx-C_Ls#KnDc^46W6
z^nI0P)yn@io%YQR5^wB*Np}xsjhdk!pX8unyX(C-@vT$2F6<wZFtyj5{$qw8tF?aK
z@T!ZC*y+b7k@}(^pF}@CiPVFYdmDZ8qVv+_=2f$vr0lxYDXGnKL$%AJP2&&0EO&20
z)_UI8^^$nA52uA5{;YC`MxC}avh`3`Z?$djjR5t8=;PVT>gP;rxP<S1%6;s*L*GAG
z<a6qwHuTYldylT4IBC;YTMXi+J<VKKV$6zR+6D9vSJKN|*x*CcYe~nor-LR=ecgF@
zr)m1}NyN@E9*54)4}W;))V=f}-bV*n{<PsjwLYO&gSMxCev@wI-{tow{yU6MBA*1D
zLDv>Vd}h;;J-^KeuOO7rgiqx1{kJ(<7j1zyLR+FtD}JTr`#7JrwA_Zh@hi=3ML~NL
zr5%c-%Ppsh*MCajR!qyQS@{mH<rZD>*UhUu`9A-~?>KQ(RB7qrrTFRQ7G3hIorluR
zN=ubj{Bf^AU76>SBd%h#J5V=tKROb9ih7_1#prj1mPNhMa_AUT{M-AY)zGnMLv$R9
z3tv?r+7k^z#Xoom8j5PrkI;$eDs&Pm?QABaV%K!gwarl4Y)JX5u<R&E2;*;VT~*vZ
zD0ZERN;&7C<V{5xwNuggC~;Mh=v*`kmGXX!CZo&IyC}=F+=459_IV{G?NgNU#i4b{
z*JiW@x&`fq#-lyZo#=3M7wU`dMT1dZlPTrHhFWQBasZWbVTXb?6G~eODOXvRVOJ&m
z%->S3>u7oO7xV-4Hp=HQRVJ!Nd7RPKLm!}0pB|#k(O*#>b5!gzEp<cn43+I#g06jp
zsyfrM-QtM3OcSz+R~nV|CB6sf+A1h*7$m;@?*bBD5zh$4R@%mBv10k#D~>uaZ-@>;
zOQ3#eNt8OFGC~8;(x^j8>Kzp?3}PV}#J_n4`v0e&WAUG!!9FSM>o|4*{nQ{Hqhx`F
z0XBdz4ulxk2j?LhOh(Z63|v41($_E%q_1HPm~zlqgA4dWIK;p{I1gE1=#K5d3LL==
zG!O~WSMd;>2kEb9=)rjv?7;<sAOh0JUksWA>5v6Rp5zT2zy*9E0umq%a=>&H`Gc4r
z$Ty@y7MNY6znl;0@t-Zz7a6ER?}HutwZ~5Ick;m=&I!V#b}^MjE`2MRF7UCQ+MVMb
z^1!(VbrPcBDCB^tBmG6WsN{jV7xfH0Knt;u3>lCMX1)0zydVPNAQ`g2l=n~8;0j?7
z2dR(+CY;FsUEkwYtm_Q^5D5v83evyXkoQ=Y;0V5;g_R(Eol_wL^1!?wc>^c#2kHNu
z1m__OjGRda9Kj1BAOTY021p<2h+?eI051i;&6WPWVc2Rq$1l9?&-`s)=Ksu(`JeeP
z7ysqryZoQ|Ef=5V1%Aqti2JYjDlhO;p3I5=1{ltx9H<(#f{YaU3;)D<<pb&z7mIk<
z2dXmcQxN|dp{NBHxHvQkGFdOTG4+e-^W^6|YBrzrAi95XRT5-@`GEhAy>o%<`T8IK
zr!q3PGA0&22(ge$N<yxSg^&r+Jw+<@aSypovsjxpw@fS(GPh<fF)Y?-7P7fyYZhWL
zEM&s}`FejoA42<T-}(K&`+a|(^XS>@{W<URe!tIoo%25L^FHr$UdLF~1HwVSE<hUP
z*5C{p_@`=sX2cWr|6Zm}kZ&~7hda@N_E&Z7n9#{=%UI4^YL#jn+ZWj{W5V_Bt>)Ts
z;4)ra#%9YHY_U`HJX>UP{5<Z(Wgt%M1C58ty5A-3BFX;e*+!DF#WEgyF(g0^$hhl|
zK*kG?C+;#fS;iZSy*C+C+`X=LynZ<QX5c?ZcWt?zr037<cda9RyV1eBu%Lu4%4)wW
zmE*@roIvkB$4~66?UHlDUeG(SrFfLzM_?a#fj9U;Ac#AFJgD2wLLP(Ty5AKz-c%RQ
z5YiZ0BAsHRXQJ+RCBjtEg?ksjSe<_ya;a{6C32N+`%~mP-L}MGGuzur{NBa(Ufu75
z$PC@~5#+bJ?W$a_n(ms%@XOZupGKb5ZJ$S8&~3kHyI>OU|D<iOlJ>y#w!M0iRu^4*
zOWOJBNPc$G<*7US2kXKNMSAMCeUSmWZDaIWPN!Q*=Shxzi!$#4;;!)9zNz-!6MI~8
z-;~u37mrpIw~fjPT)+dOAr=xK8$76F;vf@pARh`r#k)aeumFEZ0Ts{P%HRyH5DrO@
z1-X#HJDz2E>K1T-bf`>w!4g~`7Bb)z<U=9I;C8XYWeLUL!t>q({2?5q4Uh`^APaJ!
z04#XUTY)V&fh&l;t{{j3&#J@?vLF}4epZiaq!lv26+O;@c*urw)TK@k0!fex>5vUM
z<dtO&-iN>+WHB&Th=C=L4!KbIRdfSx;0Zx62QtB`7WDyyLlm3>YceMYCP55{O|2}*
zg{V3l2RTp#&eVkokOD!JiF6Q~l47G%Y->&ev8A;Gt^<=4RHpTbFK8f2&9RUMl^c*&
zaD~ml<Q|n7*fb*jumqC9-wOS}KFES3It;QQ58RuOHi(CO5PMkGkPO#BIt=0=9kRiq
z8F>pHBAXK*h=p`01hH$?4m6Mq*&sHqu7g7>;sQ$`88Sg8c-Vq7<g})KXv2BI1LB|<
zoZFHYPyp@PaSjlhRf+ao6UsRdhR%*jkOZj^;>b3LjVYJT<QF7@*naZpLYhHrJN0lz
z->?L%-eeyHK@O;S2eAbwaD^D&9kL-0R0D_$^Z>DYv;>kN+MT?E3@8TM!Nd(rhakZX
zQap(BQ1*c{#DdE(;sZ&r8PXsFvLP1=pa{whCyzlo=A;ioHG*@1*gEP={UdYYq%M-S
z#Y^&=GH;K(rPe-|L>iny0|pHkG+@wxK?4R2{LgEk9G4jRZ_oeN%?E$h0zg=3z$Bdo
z0PMJ{oXm~9Y2T?{VSaF4xalL=H`p&CEHW%mqqZK{Ox-_R6FfF}N^s~Xb@#Bb;mqoe
zU^u#!xtG@jKQAARCL-8(ye1%$IiyzRK>;D*0TCsAWuC2-xsN7<YsfKv5i;%GM-$*R
z)+f|wRKVB(nPV<tm_1E*pOyKL;86dtiIL1bwKDI;6m)+dO>kJKHcZ!Uy`K}t)qG<O
z`6eiqaA^Y>$$zEUu6%={S)*E}rad&nM8z&`bOL>tAs-Ox7v|4w{Lt|sA>o<`FO8#P
z7)kNbghe<_2n+UC6V^Y#FT`4YH0!KZ{H%4J&6{bxmHELmc}sC>Wv;h=uC)#A^8QAe
zpx{XPmR26~j@tMp%KI0NSBgjRU8$zs_t)e5bljef^52egpf1jCCK6-iRf0TImYq<2
zrl#FmGS0!Fnt+H<rs89cBETy=EF{=(@?#BKH`D6)nK;XN#TG(YbXuN#*XvZ~Ez`tT
zeM&s~8-*)6KCZJ1ks&u1j^?@Yj{FAlu$p#w$@oSF1bK}b?-L<K!p|op#EArSej>t7
zAwFY${e8UJ`?RwUZ0F|?=x^KFu8qCDt&hEfZJ=Lke|y_Dw(SCZJKN|(`nPV=+TYj5
z!Ka;%e}GS5Tb~XNtvdv?b7<eXb!$62|G>`bCXd3l_wn&*)26*$pq+1fABPU@+uH}&
z``fo~YirxOO+W{GpU!IDO8(V+Z|_HQ<acV*#e8%JWv;(7#|^LhSXWXeUGUqb7Qe^<
zEJ-Ny)ZOsgr}+8!Y41R-EeBpjR0kD*zmNc*P(o|{@zU9dcyjLjk2<}3mL~wN4#+02
z8H&q#SVitdZ(ZH+&sTg?M@R40{L@(lkn*Y4rR7QS*e1X)+BA{}?YT!@GC%$3x7`zY
z(oa_>l+2TUrQ}IJqtf%FpHb;~^0ci1{k@P~K^x<e_rgykCimaF7aVMD+uH`VvGwt5
z+o6N4UF-I~_I7Q3+SmuSY2CU*+jf4B?}awD4t@b`3Fz-{-^SL~$H%Ti`@lB#{A=fL
z*V?XK$$KHtze8)^4jue#+dJ3?ICN;+K2UBhe|!H9zV;3Q?K}L1d!cr;Qtv<aUdTcR
zPu~kC6~AZoen#;xUGGoZq0rw8LG)vZd-`6u{%_t3|1rh?8~1_<cL4YMqkG|Q8Se$j
zlc(<m$&=FV1<8}L-V1@c`boYcilbYE`j37cxT>bFL|bNbwn0L|{Kk0sgzBCO`l|i;
z#ksTc9FucC>&$d^V6--UWKE3zM#^;*qeNn}BZ!0Y)#CrS{Pk0rn%8dd$Y{wE5p#6(
z@(O9==%|n1bIS+km-F>5<N2O@OL9JG*XVUC>m!IOsoOzZYhM|3`~1h|-`8z_;_|d^
zXOvMF&usvZZqaRWna}r}M?dEi-M*!3f5|!%;yQv<EA3$;*K(fubQ_oUD{Wj_UrKB2
z&zf9+-riCv<y6{Mwp=5R7Ph`^HB1*5rz-5gm5j?4;u81Q;-YVxK5FBX-u`<sKEIWS
zk6t$!y7)K~C((_>Yd7)9eI`EI_WvW@pdocBt<kdT#-jRT-RR@uE{$WHGw9<Y`D8om
z>3n)BE~UO|Xv=(A^io<r<&_c_$*1VQ7MH)BPg8VtZ)P>o47vc>ly3e^;*+I~kG>jv
zZZ-S3#(Qp1r9S2|r8u?Hc9u4nDSHnP5B+<E)Wv4_eWUm}X?%P`0;G_NeJu;*VXc4Q
z_)w+Etdw8v`<>Q4+!8q$R}bWILo-}8hGWcTD`h~R&gWJskJI_wpk+>{cPZ)YuDqu@
z=^jR%m3l{?Xa3x8;!37v8Ru|*IxWws&Pt}`IYG;ume{|T7F+Jur_)k_bA&&cmghc3
zAE)KHLCc($2kK|b-@nS2VqIFKY)KiTIiWg9S`wd3%X1&AkJIwppk+?W@lx{T>3gZ<
z{h}X}P_m45<{Vj1rscWKk;iFyZqPEPrA;YmDJ@^N>z<7n^iPN@nJ=T&cwqd`NZ%KQ
zS+{ZH1H6I)e8RoxhARCTZKHivF0D_6J__y5zkQ;AsfR5@TVFp8BMticQQ8Jl#g%*(
z@6x3|O**x3QcueBPu~AEYU=zKoc`%AN&&?0&!6{C_UDz<ft23~x-^H#iv&*kI~XFN
z;Hsu?tYn&>?hbWyjP#@L(cf!SNSH5OX4?I9sszv}IsH%far!dnSy$qq&ohbdNZoU|
zvSbd<fj&KHR@x$SDCgeV`0Afe&waR->?xD;i5@d#;~Dq(S)0YaGbQdReIJM;1&a3}
zI%&0KPTrxkeu`~Vr5t)c@(T#{XItzUhNF8^(sPHK>xwr1O23xFqp+a?6ET2_eN@HY
z8GnX8a4qrI8b6ii{UrQkJwxmthWbTlJFLatW+MLDw$)R8$N0-}ZjX)&3*mK9F{Uc<
zlJzjl5ig0yy0?{kUr9p{zqRQKCZ*aozT{2G{7K?Canf%f_mJFDBhXoR%wKIk=sUNq
zn{kSNS<YLtU-H5hIjltfl#G{CZ8^)6@p^}_aZktVIS=^K%1!BQ+{fic;`R2Q#4Ed$
zconM|FY#o&p8K%=cjHyWwMx6scDzQUaV_cZmn?09{FyXlJsGd(K6p!u*AnH-Pye%h
z)TT{jS8fS?N#2T%pT5sTuO;s@Df3dMwRL-GW!}X66#AAm09zU{+~pl@*_O7k%cFBe
z`b?l^)85V6cC*|EgVmxZ?LMWt!%vQLMrz}r-KV`<rMzlw9RK<KXJVepO_E4lZg7qn
zy13~3QnYE1`&=6n@%JX&WB<qXLOA}~>*$;HkMB*f8~nTO+!99aiP5^c)I}OzILTkB
z|8>nWhVd%>U*7u4^e<(yzQ4_%?^2kgm3mdpxl3`1J=&7@Xs#|kCF>4b%0b+_Pt+aH
zZ6K9a=E`!9wk%QRBwqSwWU@4fa129I>NJL!sV1noN44>KK~Hl>NB;ngk6)0su9G}@
z);)fvtJzudnJ(o+!fVS1uR}bRrCgLuhley$aW)`zvkZlk_RaMdoQ{Y9KD$H)D0wgU
z&a>`uI-J>AG940MM_t<_OBY{W@s#*Vxv->=+Qus7LHSbaqwyLyKA0X)`EJbqKW`7I
zl=?;VB=tsV_e&eyb)DscxTmk{{ls;(7yLWd)7zgmRV$ZMbwEhIw1dl1?seA-m=xg0
z2W&6x$8j&^onDTRYfHUVihER-N`3gXwp>eBfYQ%b$Zz!Z>`9;Qlzr}vuPtBtbR?>^
zF`0~zbVz<kI&yXCC}9u!iKIw6N-rncJd^t0nRAs)ht#ifPybn6FXc#YuR4Y}i0cm0
zt<)KA;}^X^TaF?EMg>Rm^;fUp$F=Ccr(-E&9$Z7)$M*Pa1L<RZsUf=mvkN}0|L3-1
zwfZmQTDjaDWwkBZu&au>>@Ut{XjyH1meqD=S#5H@Xj_|!6cDwE$>1puO}?+cAuTCm
z&1Y8Ye)Dl{a5r>rpHYr)pXff;arSoF#ESlATT}>~cyINDy!fkMEnC08{+{KBELWcx
zv;Ezi%;Vk#mnTxc_K@=#Y+eSYN6xlM-g;$3uE)ew9!f3v0H8LpOwF3oU}3t`WV_VX
zTYP#ISL@U)yW_DBZZsSEQeEHl1&k?fY9`@6xM6WW+W+js;eGa0>lt<^c5%d)ev1cm
zp5-@m--(abSQj(Lyr+cwu*H#jF}Iuc?SEzcZkG<`W2;P`KW>ogfN3iho^IZ&+>A9U
zRbM4P8Xrqox%7kg?JnKe7CW)llCy<IpG{Y}Em-L|q}`dtcAt{JpLUY-#oDcC@$j9#
z?qQve9)A$;_fyiWHy<9#_`2S=?_Imza{6b~9}|@GJ>Q0011CA(8^14ZUfukcH7RYj
zy!Tn1S$#Lp%b9l2_t?P8nH!cjoAKFo#z!mXGuWv7r`V`$$jhtR<kg4GwpYHnba~S4
zjqRrV(RAf^uTB2t+SL2Mjd)-bIB9*Qt2~#K{B1L2<NRAr9u@cY9Z~CQwfpb(?pe1>
z)BX1~Gw%PAyEeJzY~Ink$oV=fEG%j|rQTVOJj;=@+UDn6()4V&YvGa=as3u8t<%_b
z9M69m0&0_pAIx0m%;{Awa?quKHC=y>e!ZvJ*K2#vy>xo9ZMj14Rw=A|ZztjEMY`5)
z()d#CB=;$y{r#uJEQs!F^WfGs$GI7;Yj>-gaD!)qy@b15ciOeS4G+&**xD@VpjVrp
z-(Qds@W!I<?~E>3wtdjG0o-dZ+D7Gzwmn%^o04U<on2PjlV!DuT~=GPFWQ!6S#4ea
zr)*x9)pqv(HQShFwe9_)ZC;kuw)cO^=4DxJiW_WW8f;@O;C-r1M|r*-s`|?G8AWqv
z-D&CeKoi%0NTgefhASsE>X+=eyGhLL{LfUX4vrGe*V1@ka&qgLb|0j#8)@O#a>|8~
z_x4Pkf9mZ`(_+RI_jO~OX*UU1zn;T)Q#M@dw)>{Z-fNW-el*y|{9S3k^xk5<B=z<0
z23;t+H~!+;IwQK=o3gS)KewOS4#=I=w~xU#W}Vw}l83f#yvC(!h@<Vbdn;S?uGq|c
zOAPOWO_Xxgv%;F(^uoHeldIJ1KD$eu6>&|cel?-TYfUH3G1$gDlfTC|&Rvyy=UDfk
zUr&7gTGrrQc5kLnbT3|?H55B$baokRV_tMN*v6D{V6csOwn4^v$8#xb&mL|V*s~e)
z%=u`bHrc(YcjoZfj!oyf_1k~WC)#-R`CUI}O#ZFTxdF4%TYtP|2K`sc`{3NnSFVOz
ze^lv*yHW4oefOhT!+RC(NOKr{wN>-c%QN>n^S*k!kDPC7rTvY@nOB@&HGJBl-D6en
zn7=*sw0%PDiE+O)I%PjO{0sWYWnTIJA={XSH3e-iF4&$^{N_(zHZrMU*M3Xj#a;Cm
zvHmC@E@+4KTW~k*r5Qh_mDB8*;CapQ=V`z6dA<HO#}*HbY;f~f9+R0G@|{m@SX1y=
z{xr))+Xmbi+hssO&ES0cUzGOg=7HsI&+J=wYSh|hsdc-4kd-&F;SJw?TTV2*8~^1;
zZkzlVAFSMOlkN{6mz0>9U}-*b%*|Qb9qVmd<6>{I>W!rb#yW0lb(3+$|1E0@mUV5v
z|I}K1hPCrnj9)Rl|0a_=-;bW;-C}jh2ko}@<)hS#UOVq5-??l-H#b%pTNKB4FBAN%
zKwM2@t*zHrk#uRQY9aN<>E@{Z<>PeoM8y=1>gnsbV(V4DDfUImFahiUE7#*SQa@i)
zna3%|$y7GF_!XDVZXVaFgGe><Yvk+5!$|oKd=%Loc??OFsXC67bjUYP-F!r4jFp_%
z7(c31#T_A>e0!DSCA`E#H&^b3$3r(4tW5EceACTSQs&r1ql}XI_N|F3n&EJ&qe%I7
zdK{_GH{BeZzkHl-eu*-t;^};2%$=gAA|#)qR1b9dCh^qG1^LUz>E>*xoaG!(l}lsF
zq2!ARlI{vsMWjA`y7?7<`8eHNh`)54nrrLkEGYMq+e_Ft#;*p5i`SJKHQTx||BN%h
zll&?f?mJ!nNI2bi`clIkD-ljNR=w14CC{fD2d<1memZ^^OT<q%#=6w=>8~sKsT;qn
zobTy;@gd)347xY67SgvwIna&!RmMj>eOxHvBtOHDGEO*LcbuAS-Pl=WOjR<2R7>j3
zQ6COZ-I!HnEUTom0ms&mz_`JrQ^vQxg_L@Qdm_3iayYUZ(i1rnIRZHa>5ZI^^hJJx
z^hbV+9ECiO3_@N(jz<2D9E&VQh9XV5W;l{GDYnZeASdv94w7z*=qpIB5q%RGg)Bz$
z8WCOIn1B4$M$SaqAm2vzM$SWqA>TpHKoYm;naBmm4aoP9-y`FY##99FBU>VAMn=n+
z-jd}|H+EF1XZ}?=)Q#mVHJrXYs7bSKY-Oq8^yN_OzU#(1Dq|oef8^N8_={UbJf;3#
zjckTYLbgS&MfO7`Bhj^L9a8dV19B#EJ90U42XYN^Cvp>V5AqapAMy<H0Ftt<JRg2V
ze#7tk$iqmnwV8=*hLn1~2l6{4WmtJmhz<H|e#atDA`_86AlD$dM)W2m*NFZCnS(rp
z{0W(h{26&0c^+AX{P_iGg}i{2F`y;yKi#;zQuV0Uw=;3pjgwQx&&hp+DwQ!#2-Q^G
zeH4Y{bE|3^vH@~BvN3W7QtC+u(2Y}5#;?hF%Hd}N;$jF_5%~`CHRODx+%NCyj+c5s
zH*QQB*CqK$F;iKAIOcOH#}h7^Q>$7d_4TuE+*hf`HP;=-vs*ci_&hpJH-1YQ*Y))E
zR_cyRM7HC4mvqN*AL_?TsV1{6$5lf5gE*d5N<8h6=KQ9upp?TdNa7$(QN>n%4`gqC
z_d-&KsNO)zIb4tt$UaC7@=c^Zox1T*$~dW~<2#6ORSEBol<`v^BE^p4f2*zdecS^j
z?ZxYD#V1qgovL80Duyg7$2sW2l8kBxt`G!KkN|0r4aHDn3c3PU2!}XGflMd>)2ZBx
zWNHBvgA9nX1`h~_7+3<ykOtXM0Hz&y{(>iHz^0Fp)J0N1sIvH71Qw3i`vZT71+gEP
z2WB1d2Y-lx&2S3JIdL9vhbTydbSQwzoj3-9;J?v!{6ED;{6ERo`_t=K<a$u<hEkt`
zD`+4A(jXtqhEZRGCqzRkoC0aQv;z+ahXlxkLNN2BT!A~tbLj7^U-7T((x=mKaVSST
zqABmlVr246o-J&bqpo!Uu|b~=d60h&f9kpC*`0T#L8G@lUz*+dGz-pAfx5z!dkdT(
zdoJx9<e%A`PqD)O=Z}Qp!S=Mh`O<97i+zZaHs*_YV0$(-R&BO6R$XsqtcrWxSmi+@
zt+0i$DvgO9g{_QL>ej|8Z<y1@Sd|V1ZLvY$j<68zXiPm}tg>}7R>eaRBy=`bIdw5s
zErDETY}a?=cu0bR?#3$T9-IsEd$Rq8vC1FfTsSw4!UCw#$5`b624~QKK?DDLH6VBJ
z!-u-~o3S1`b+(Las|YoqPIc{Ejc%`M=UO-;4>r)wm2zhP8=!ZW@XrUCE6|^CGR|Md
z^&1h!3~upT#_JDapNy$LuI72dZ<&iJb3euYK|X$WkVSA8z5%gya0J9o!yj;xFvZA+
zAf0(8@Dk`<FV6p^ns*`g%lxySL75MZEP$(U4YEPztN#Z32!9=U18&0aAoDB4HLuTl
zyTsp38tOXNk>@}N{=0eE5k1M=vDf)6_V!k)IY0hQh(~ox<{yLJjbZ;T_BkLWtykbG
z+{N!G@^>hLVt4>qARP+EP!43?cMqt*wkcGCDqse$z^hOj#GO(TC$?LH%)gR(<Y(}+
zLpnf5kU8$o&<(mn59kSRKyMKDI_c=owi}2ootpgqLakB_Wn1QH%Dhl-*oB`zG7y4c
z41_`iXkY?NhA5Z;;tr@)s#$Eyyvlb#>?s_??>*!q_z0Fk0<45YSOu%$Q%DAJqJJrC
z!D`k!!_SI1+CXy{R#%&U6Lt9@Ht9sKQjSC)Iq(w{k_Xm=Zwiu@eIRl98V<wn?3eku
zvL?jWoa-CNs(}q_!nXz4=Y(trj?jf;x<U`=1uoDBT%jLqCj0>8AQ%jKXD7!$m7WIp
zc@Sn8c)|$q1|RT)KnMaUi+Vkb=JyyF3t=!0B0vLj{t3uQFa@Gu8cc^-FdOE=JMb=u
zlk>GC9-W{S=<A4O_+Ldga*xY>y&e6F?VE;#k@(0QtrUK5g!=fkhR&tzYlNRM`jmTZ
z<STMT$~?ct-lCl2Q#JiC@EQEZ^-8WmK~U9;UWY=?`6AY$s7Cy&gWlaCZGY&}Cw?W@
zov=}JuY$Om9P?_4<HX>>D<G~8{;!qTSD$UQ?srYjU8}_T+p=w^`@NDf`w57v#knkW
z=d)*j2VIyyTX*8$S!<%?dMYn+{SjHGLduquxxczr1<i4#&)gZwE0EGBGY7d3<bAuG
z5p^PHU=GAV0;E7T<U#>R|EZ}lIs}^LDmU<iA}B|vlo{B7*f{6`V!t#5n0l>>heX&6
znUD{Kpeo0^Iaosq$a~Bjh=(2E#ygDIw+w<g5C;j646+tRE);+%?<iJa3r-+wWB7yE
zVGQA2B?_|P6xddzE&*8!BMM?czaB;=+ovE8#K?=Rh0z0YE0ONX)MelaArJ=%AbsUK
zAOi|uP8Ie+0_=cv$buXwf*N#4slf(Zz#qaP3SvOk*s!REu3#T{kmvpo4zVD%j*?(A
zWP+?qRF3*W4L0BaJ-{1e9S&K4BMRam0a73ha$yqpfUN%`Yu%*44oHVAC;(ILF)MHe
zSMUITh=xLlrCcU}JOiYy<O;GzhX&-sSS%z%I^;qznASoEpav({3@)@UJis4hU7{$6
zg;dCZ9I&m;bsz?oKoV?*G{}G)C<3!O#2Fl*2e^SJghMPO!DdJU{dyqfUZdRy?LgKA
z@qloM0aNM^sk77|YdkrCJA^|lEP+(8;W?WE`n5tV>JbmH1t)L?4b-4LqXua^NxR4$
zyg}MmlOP@vAq93oHe82duuv06Z~=b^hge94RLFt?D1sUdxHh=L^@ikeBhCwHkOg^A
z1g2Jm1zYfhAkaWG#K8_o2U)Kq2MVA@WA0gS0vB)xZwQAaPypAVM-%peH-x|>kTp)?
zAO+Gv);O62NstOz*5qL`&JC_$+8jNBKWM<^b;3go$U1e_HtdI3NP|ppZGj$PA7p`l
zOMXKV<by>kjspu@!h$EnLpl^fxz@xTCP5OULUB8eu_G*mKpdn)A(U%Rd?6WjfQ3EB
zLJU|r5FQdB1*ET1`YD}YQYXqH<Uj!=b!Hn1Ai5jpgHw<XaotHDWI`eM_dp+D)ssAf
zNl?xWU4X2EIA;K9hg>MR{)xp9?g{XQc*uZLkT?_x(ihfaIPrxHI0Y$QTocN9qf@Z-
zAr0UUNstA(VCKuU!2`Vgh%aP9wm-)PP;S5<;voq(LmFg2HsnG96hVF<*B*rg>mcF;
z&CIp!p%^o5+gzTpGPnLqq_ms&B7dUn%X%x~FVFki_*djO4gOjDmiGHLq`Xs%KwicF
zJEYtz-y-GRtODUj<3ESr^3Iftl=gaU-Fd1brOkH;|HFjahm`ieE%Gu_>g8hm>k&@c
zffh(te%I3d9?1So{7v~i0spQ1mUojaNNLZ@ytbA2A4C4k?<#~_#_tQd{n9p)>loZ$
z(?B_bzooPPKQ=gY47Sq)LOijZAL%)s|DKT%ex5$z;j*cT@Ckj^(tk+UD6c@T;Lr(P
z<0ghh_-m~iv<&kd%{vBm|4lf5)}ts@<r`yO_)DrM?f&=mVHE&%*T~3#v6wc9P(sgA
zbuw4^P4rilF;Xh*An;+tGc3|m6BZT{={dpA(<LlY<KfWW(`T%I`*xmVL)y1%+0&z^
ziX^F8w$%BS9(|w4vBaVfsCrf2-0y0W)}5QT$+{ck);%+=#hCU}lT;a>o!WV~_fMB&
z`{mCc^37`QXTqviNQw>4paFvh3>q+Kz@Pzx1`HZ7XuzNWg9Z#5FlfM_fq#|;<el~J
ztp69mYJJak3QY8i3=Q@R3whiRVB{_R0RMgK|LJW_YK*n{+8@bh0+kGndb=_GU&WPF
zMwklJYb1nyVkgl<8~o}2k8E3dvq!#d^f$sPw<x)_*48s!eoy+h5qq!Z=Hd7^g8oJ&
z>_2m1`9775{~&EVRASSRZd={@X<j`ig-3Wz@Ci|gokhiFG{-PJOgZLWiDT%R{g=mt
z>yG*4zLH+$Iz9g67`c{SZ^}0>!r9Yp@*1)gvMv!+KYU7WULlI!VhB@;d!)BGc9y2M
zB~Sb7^p=SKlX^2Z7kwR2bRUiZ*5J^<Fs+VV@YjH>wIx#Q21`C}ZK&iEVZFwOvxp>J
zwTdn$p%eMmw}Ib%wdr}T{^gi7-7!Taj`>&mmt(GT%x7HZ6RfF|h0oQ0Az@5WxWU$B
zdDm~hz2ew=+wx44TLVqM_-eZK;>q+kccl!PWQ{YsbZ5!3Yj>{wFwM)Of9H$UZXWeW
zt7G3cyk;GX)KC5SM$lct8Ej2Xx!U66H~se;)p-B@TVdQg)9pnsQC$L7F4=ZNGr#ql
z-*+wV(aFevQQO?E%L5y|-rs*)(eTR5BkCsMl5=mXEGNC`c=|!AtIz2%9tR^0wkAa{
z23wQU8aw3nT~MK3pLyN9T7SwsCP&dr)3|<d6&*AQ)sv20>bmKqf9?7I6kC%mly3!x
zXTSOJ!VeeLn{@H_+nanhPLCfOyC*28Xvo4>r+wb{kNZC|evArTZDO!Bd234g+Hb3T
z_2$xD-(9%+9^dqOie4tV3|`uCOO^N~-z`{{@L7u*5%;X$wvYb4#@zffUk|exO}#7M
zn$;#tez8~IEqL$8Q>Gi@Z<z0BJEGF+`we@o*|@=RgH7&WlhZt#m2m2hC*R+_t>QRM
z)uCI@v<P|od{osHS+8G9NNW%ow#TZ;M%rs_<$SYR{<z}e=&24)St&=$9j#?l;F7nZ
z*}$E%8?I<wWo9FjYJ5vo;#WL--L!M7*8MVj%FDZ6so!|K*_48-Hs{V)PuW>?cg>m(
zQyFuooX@3^Z;q+4$+&Bk>#q!UNGvXh*f-GnjcxYjyIt9NKkNaGHiNCnZ--kITsS+o
zlXJ|^M_#quI>RQt#(chgEBZ@zYPGWZrFE6oolf_^pt?7;vVHBe+uN&EoYy`k;<a5z
z87pD1HMzNUi>tTy+L?Kp&2%Wf9UkFg_r@*8T-TKHJa0<U$MqY|?0eF$-=q<?1I<o+
zo$_*ZP5xk;yxa5E)k#0Xc+6fBZu@7|{fGSI@~~~}gn2$U+FXh#vis;#ZKKWE%|mw9
zSU%WQr5gW+go~Q#klNXJo>lJs8XeCkIR7~OEw@i{iz43&Y(DYqMvGC5FEH4o^uAu9
zO6c+}J*)QI`}5>oYvV4~wHt?Cx`_VXy<cZirtS6<PBFjSu5&)cKj>(#cjUlp3o4FT
zV?VsFvn6AN6g>xIW(7ZJXIFb|LHQ+_n}&s%#N60qQR&0wv&O}}zQk$sQr<ln8>2Sa
zv!=qa{w<x2JGFD&+5O1r`8UVrC(Y<s%_}9iue$NLIyZP1Ri2k?s#Lx8-Q}@<eY##-
zwpf!;V_ZN{K*&#5N8IXoz;*uF>a^FqmGix)Iq&|Ccl;+Y{es6EY*HF*QXV+AVO-Ib
zFXK1;lsW$0{@Dkue+(Wz%VX$vULJWFR-1fvYvA>p6I2_Q*2&(nZAHU!+lTilzFys~
z-1W|rYWBK*opM#7gM|Ao`4``@yUc@@E<RQK{qPa@3e$dDkh|iCy!@FHR=6AsSk2ga
z<^C|(q>O54+0FjqFH4h0s;;a=cl{JSU%7PI{QOYkYX+N?lQQqy<yE1tgR-SIxlm+$
z(>f_{)0wTN@qI5lz3F%%Yv8Z-*S2`i`%HyK2d|!Du7ZVxt8mcV&R~-=Zga@V4GUh{
z*~656w%($blM(ON9DLEg))me63a8hO`ORRHvU?xVi@_$P!6v1YgRe*LSmRfxP3O&9
zR$P1Y%&~)aMr?6vQMjz(`x65noEqMRKEh*4d1=<`eUIu>#&4Q;ylT*Wr;Pl2)gyc6
zUS2oxgJhq^2X_rRz<655K-11{xYcz}a<^5H!SjBPUGb~igbQ`9TlkrFTh(;$p7+aD
z2xb0SKMA*g=+IyNns2^2?e!xagCf7Rj@)xHFfQ16#iG!=i*mN?=l=bSzFWp5=8Su|
zcE$M4QFa?zeR^Q@V&549zM0<p+_7&|mE3lHx`lAxJ4iTHhGyr?RaPzYemzic^ySgP
zKdcWAY%#0yZ}&EQcV+H!lRU;_zbWB<&APQTu)=~XDeX^wc&$&Y?bm_3TQ-RKIrS6Y
zl(3xXnLPFvD(%S;xo6@IM|(Eg(WHIW{wmF<o2{5}Y;BXFGmmWFXujj<W!}pMDE)s6
zCcNTRXykn8`#u$qMgH70?6;kxTkNdRaoE<d#+Bb_dzW_XDCK<N8_k=jI=X9|b{tz_
zut_=CoB19}zTM1ye~xA62dyk-Trx?#<(qlY{qU@dvF+L~*&KRk#_~kk2fuZce5-r;
z+xow6$ve6(D!^-6ig&GGgH1}MJnt@Y>~Q>4+ivwA-Yd%88r^V>na>rUJH3nDilzkS
z$FAj_$6%9k=O=Hs``mbGScPRq4L-Xv;Qd>LR`;0S@v4-oniKA)R^8h8r(5mbIos-F
z%dTJVwz_e#LEbt~n;Cr~UX4$nUx2;=waE?Fu?aC3HN~zzW=?GmhP!`JeQV0v_pdeg
z%^%s-tHauQD%HnIxGwdlU;E>D_y_ZPXDn;3j?et+_n2l|PVHZO`>1C2mE)2Z?UeV>
z%X7|`pLxI2C8wYJZ2tdelakv`|Gicv-*LruQbqjSLEKQLpvbq~VaP_v5lFgF_<pX6
zj^v{o(?OzN<2WBArZ^NEZkXXv@jWnFz6UdHL$T2m!!f$=o62`jxlUF5qCgy<dKKGO
z?T}QZimj*?NUBQ3wivg3^lYw27qW7l&PYslsGO1h$Zp6bNV+Pce@FI3K0xwliGG#u
zgaeTBopm5`AJ_hGwf!V^pRBKue~{|SJRsf&^!A_ri8h~-$YXiN8tgqW=cotsg}{<R
z>;#?=1qqM_IUq*StiS~f_MXsz8*><;7-Fa&{<qqDlDW{aQ@IbQ5WS}{hZ165W<Jhz
z<`>T3J}$@nK4=$Be<||M>_0is2mZ7Ts9fp-u>&=SegDc9l+2%Q2ksy?p;W(d4BJ+7
zxgOFDnTGU6W+F?o3FS%qTkJw5!JpZN`a5=^JVqI-qJpT{4bGqeg9Z#5FlfM_0fPn%
z8Zc<Upn)=KKw6IvAL;^|VaJU3hIf!MhFWY#h<$}sme{64imeE-zi<-tZZ-S5Lr>7V
zB(~Rp*l4){dbbw8U~|TnBiF-Zm;zBS9cIEDm<RJgTncg{Y=X_O6~tX44wvCQet!TT
z!eUqo;tJSz6@CM8GM?L#4iy<&o=kt#hK8IQieBS=pf1;7TkIZwhTH`EIgcwO6W{gF
zo9*SW0>t%0%Gj;9U?>bG%v&%7^iKSHz<p>0H{lkDvqm-p8)yY>K-@#5G3OBbMdfwp
z>V;oVwtMS-_u;qR_L|t;c?&$i7TQ2_cpb#GMcRQqbkO+?MUI0=-S6Q@PZ$9s!3X?d
zJ=Zw{=RxmM*mh!HXAn0E84P1|zbm0jv1_*(9c}>`8!v8FW9@th=?h##-{M;M6lCm)
z8Si3WalF{oGh@FwOl6<QYV7-;w)6HPY`lr>zvtO`D`^W->?hUK=}h$VKVj?bf3tlz
zxp$=8OL>!fPo&s<llxfgzDXG^tKGNC=$BytDsM=H>rf1))OA6y1M;8{WbR8GoPx^q
zLs){?aB~MU`VGWZzCUOn8e(Ay<bc>+D~8JS2Uvm)i0!p}-v4drNOl4ja0h?Lqff)C
z68#L|3^A|-l3@q96LGPpmI7i=Ee~uM```pF;0@sr3ngu;<@38-RpJ5G&;usHKFEX|
z$Oi|;vqnQ4BtR~x(XG@;PLL1QlxuhJhj2)QQ&5hve%9a){-A+55D&5ljRUxV*hdS3
z>tuksHgyy@fd+Pf*eT0~Jh%=u>JSbzFb8r$=BfCD2IfFKh>fuVC<cG2b3p8iSwlPM
z0p1V}QIG+}P=n`@3q(U4B!IP=bHf~n1J6cC5ZhoWumiF|Y=DU^?=%qGU%5~Om8sjT
zzyZYeR|rgkIS>y?kPUfIqY3*U0}7#BQ_^cqTp<<`z@r&u0a76ymNX|koPv_JzH(mY
z+BTFmNPs*jgqRk@88V=9OY{w{B3q#kkcB07Kt71QFKY;b1jv9>kOwyHhzrC*0_=lA
zu(CtPkky{N;XAL`_Hu(XkOe+u%>%LPRR~rc2n*g$qz7dE0aa&$fj?-#rVHDk0n_f3
z5%7j^u;@Wvf;*J!N%{dBKB~O_>~kaT;6H%;hkcOa&h-bQQz&|ia}D9%0u3a?4u~F#
zgbc76PWgaj*a5L#<Q3#WqBms*D*F%zm;;+(A6y4(U(x~2e&`2MAl08^p%8ima9x-K
zagYGXkP7=C6HY-MT!&&X4Wx{K8q7was~{w}K?p21(>_NXkkXbhID-ZZ8Zc<UpaFvh
z{v8dJ<Dh?k{(tEv0Rsa@1!w|7CunE?YwZ9UdDC9_|1|%<yvoWvQsb{GuW~itSOc5o
zDl>D@jjNIT=e-*$f)(tb9do^H6&1Vm(N^Y}TeGhe_h_EEEjxE|tjq<E93P^QurjZ`
z5b4abxk)#k;U+yRtjSF;tXn&|O3m)GyVO|`*L3Pv6MDSXbkdyN<vN~!a}DE@iJ97D
z=ctq^eP$0BHT+QhRc{Zky>PGN5Pv(H4gnLFW?pl@@#<yzI%q?wO&V@5zd5O*?}tra
zKYX#+&Z&RRm6d<`rjl2kW#e9N_0a9}E-KY&;-ogoRUNo=t=Xd5zts=wdC2GJ-TpIc
zoXJ0#xYwrn$`GH+-Lq(`I7_(L{WS`f4*zxji2l|31vYE*_9t@#!;4nVjY()Vb7_&u
z(FEEg%K1D#7+PiTy0LM!#(bYPD&F<OyVDnr`n1+BAD_PWSI1+&LYq)+(l77Tt;hTI
z{O;fh&kNgJ+HQZd-Th@9K8y<dVQ|IUCwAP8pv_A=QS|p^@5FNUm2+#2%3OJ(c<#|(
zT21~orsO#0gB>ND-=RjyO>Y=~IlySys@q@m*qA;0+rX<<lZ-ES9FaD9%1^wLSklf^
zoBViwM$_s$FWIb}@9fepa*)ZfF;9<kE$f=<0m}KFKR&c3ZBn(#-LO?%iYKg1P8~bA
zfyu^~cXZoy^@K^M9ZMoR-y9KdTVzjLmA16nB)`Yk5h2|o$KL7DbDQ6Q9HaBgGp|h>
zaz*{##M^a}4s3ZJoBD)Rn=Jh7&hFZCZ_UZKb@%Jty<PF(^(V(Jx$tphucl4~DMfXL
zm3@3@S=aC`>p0RjO8!nB)38bO;<yU$%-LDny~WJfOI_oRn^!Vlx#+;!uVP*wae?&(
zl=O}^yL{bk_&a0m#x5B<%5u^28JoS;)${yX_rLRHmPPZo>tnY<IiJPhf#qHu^8W0!
z_6aX996YqfS<mqkD-2&Wv{sixX+4Jy_AdMQ+Om#cE$jHpvW{~t>ze9i9S^&Ww!hk>
z+L!YN*}T*-FxdIiLEblA-Wxt<>qR5KmTeMmBqvTfb^lx5J$a{5o3ya+Hf?{?X>AvN
zKk}>T=RZBRVQ%Yy9%~aPjJba@b9z88?(-Ktj`R~He=m%Q{4Hhc`fWpf>n%>Uob|;|
z<8BT4EIoGPrVbBsmq*4Oq+e7m@yj0mm3{M<Qx5xGIGtH{@t(Lj{<VB7Eb6r2MxXQR
zvmGii7c`!-pf-uGX52p@E^YRqzKsWuT3M@`>Opj1n8VtrQ_Y61Ob!3ov+VPD%Q`=I
z9Q_Jvlb4Ql*cQ7a=<v;sZ9m>^zB1?aReMKl2&i=AXXk1@`<n-T$-7xS3D?WjrDwOd
za_jgnocPO$TNA%ovqv>(|CCpEN1SLlXL+B<FxC}O>T%OO3C%n&KRk2TVsQ1<+bmMU
zn{I9}B=rNcZnnQ=G`P2#I;~wTIp5y=hsimI#)UTe-K*Q^aWTCoWi+^0{+l(GZRd^t
z@N|?BeMF0td9vqHi;_~;ZmZJ&#?TI3Z+$S?J7mK4(;mON+7^7BlUR2peNeKXq}s&R
zz3R3R>nDG`=E#zl;%$F&srvTky}wvu{D$>{<kiu2&XLx#&bxh0DSt=m%n$ga>ql|6
zR^RO?eIDvs<^IjR`>|K|+THvbpZl`U*nW+gExfwiwES<quZDcMaYezUDzo@b&`ILg
z{(iY#_UpfMcHPnPVd>*i%R0Ywm=eGBp>@<X52SawKK9|6_g?wrr8TDU?|qZ<!OUHa
z$26YVtousztX%i`<4q6LRPuM{TXuJDXzq{g(0WY7%3f8!Fy6eU@`g86weM$CbZfnT
zD)qCXXNQOH?%W&o$BM~5He25)erO+cC8_0*z^u7bqsJ#(j$e|4jcnz*LC5DTP<__c
zy4BWzm})ZvZ+@QR{q2+{X9KL<)};3BagDaYL*;yn>(;K&tHY7@ue_OBVZxDCGouC_
z$r_<~cVMsghSYAeJF_?CN_ig5+wb@Cm($X(PM&l#{cK91#qG4at~-03pLis~ZDOTt
znj|V0<+&Q)qEhs)(=0+S+ZE^kJ^Lr?l=#iIs1P{u-s%Z?@mIfEwtj#8J<AVSu0Anl
z`@1=r$Gr<KPozy$TlAMV$!9|IHwUZ^N|?WN^87l}gW3*`%ypVO-F-mB<_`~M&@h{-
zoNsyPo*7?kYjx?$7^h2NQBAJK2hOsz^0_xIe9D3I@gWts&;L{QMeZp2d;a{~PnG<Q
zwOi5R;X8fZ!#W>5{vh7(r=(eLK0K81b-i!jyLP?h^v@cUeI9QE<+{(e2U6B~ywjEV
zRqC}VAofab=E>WG76zu&oY7*hUxx~lj>NA^vFH#G<etj9(aL>vJ$YctUU#!$tCzht
zrs8blsPux24{thJH2BcR`Tn(ck_h9jw8Nq_)qiqpwf#zm${+pkP0>rMSDSk;|8U3s
zRLx7yciuUje)PrL?|5G+_on9_&Mk<(@p{c5``t(Te-t16An}*xre}VP+CTc}5z`Nj
z{rA}0c+qw*epmE2!Y6BcWWVdPZEVZCsPeO3>r(yr3agAQdn#-z_~nb{i+I^F>mv7W
zxtHv=Ec0&C&+Fpi`cYe)zO>p~Ys0nm^S^D7*MG#c2Qpv!2WJU)vi-eIL-${6@P6eQ
z74{8J9F*d8(eBdxxbsdGPfql>b&vNCPbwp|$(vO=?svGdVZk@&oWI;s@z#T+BgYSK
z`rvy<*V`{I%(++9ku?XD>#qCGbnl!Bt3ER8YISnsdE15Res7#;{Q9@ek5{SIz<y3A
zU)JJM!d)KN_3$X)xexw)-g0*(y>p`H)Hri<<^->LUh}4&NSSDyZ83Yn%GH{e>K*)a
z((<``%03_2TX~*e3u|j}<ogwyS68}s_3zF9w^H;sde?+2y9<1$pE<i`Lo?gHAGa#}
zb;YWH`!m;7^qgDYd6*IRn-VVJ&gGxK`P?(guHL+d!<PKwyZzzW0hVnmZb&E`<GcCH
zQFJ_A3AgnA%)7n1y4?!)`)c>5^&j5tIQ!{&#$~k=a6+k{=O6lE{jLYY9Y=cn{z-U*
z^Xctp79>@el=l9R!?B6qneL}kVU$u|O&j+`?tpI&wmkaL{!8y&TDrT~<kD94k$3WA
zrbex*dLxN&ZIpWBP}Nta&nTKZ>rP9z2b#G4Ln7T;G+a5UQNLuz-A!U{=YPhxYs!M!
z#MjbzU~+QnnRXwfuN!IM*mBB+k@xmYoqy`>P19n=758=HIjEGY`t=;Xo3i0rx7{~Q
z_Fk)$@MDLD-B}%E&+)5oyfxO&y;~9AV3g}VTz+lgg)i36ymDt*y$w|t?XjI;ls~Ow
z^x7^~OZp{zC~JC@b^f}$(%!9X+N(?2utv#mw;U4uaVy(%HNNeXnpDvwuXtUD=0oCJ
zkPca^S#2`Y^g)-3OTCTyw?DS^Ot)dPXI(zk;m39pe=UDwruDM&b2At#pyHVcy1oge
z&msnWy@Vgtt>S3bDQk$EB59sTpGI^;B%c*!sTx^tJbE882{J*(gy({pG2bRYY!)U%
z0a%&v%>`sFsyT!$Xl|skc-=_V1HwVZSpV7Dx-y<R3gla89u$I%otE*^GB&#8TDh)7
zR=-wm$+d809o!^Hg>-P5OIs8fFUIf;&Y%H<1`HZ7XuzNWg9Z#5FlfM_0fPn%8Zc<!
zZ)<>8zbD53Go(=U0WX+eHD)bG(7Ww?2mS)&d-;g^+Hc<_#}`XDV>8C+f!>u|@3|8G
zRdoBRBCF}PW!*;on%1+p?i~HgEhj1K_+ExQD(g7Qdus}$0k6=iY{-LRkg>ip&R5oK
zmbIE4Af8vt0<hrSR@Ph217}{a#U6tP@35(m4n25>jfDir;GNWx7i$~H0$Klf4#Yzu
z=*Q}&vz=OnciO5*C<L==#DnyT4h_zr0fPn%8Zc<UpaFvh3>q+Kz@Pzx1`HZ7XuzO>
z|DPJ*l^1)4MvOFL9-X6SSfpo|?`Th-vHtDb1x5sTjtveS6A%#^5aQ_<p^5Yy&wtOz
z2tQAs@Ni{Q;~yOM?DBtJfx#gG|NU$Kjn>U8D4<V4TtnbBUsV_8H|1ZaiYj(_d7&z=
z;7|>U^a=4otpQ%)VIjeOlN}wy!UH0FG+`0e&78Esn70rdCQJSW_>A>pEjb@`b4ILa
z*9^3ljc1(Nc?*8B2B0mnd<~hCpa}|&l(?9iGyGCDm$>vd3RlVeguS{r7fQzuPU1?J
zhRPDW31?d}&f`Oa$Bhs03JUNE_X^iU{CN~@{ydGH9UZkhU&zUnxfw*Y6!%yU3^7o-
zDrtVK2kCAaUP2ECbb63=^Tb&I<0q808$$@^{Xd|G=`T_d#8uXjEK8XvsS7CsQ*>!h
zlbavc93<`1-8YuBNB<9`-9JF%;}@ijv*`L+_c;I5>?|2)S+i2YYx9p~7P*VU`CT$C
z;q=*wvjIs9$xul??)x7|OGH3OfKOzAqJO!+o^_AY;>^yHX^}X0*6H7!zD058sU##T
z&LNGYpmx^P8$Q~KBUlsc6B0ZnfNFutp)Bi%nwV>(ACvQ6=5#l;=Tqtf>0Z@9f1_Y!
zjmm7oxf1Rme&$`2>ndwUO1j2i?6$vASfp2wPpE&0q}SZMHU6u~js8YKK9OFbVP1Y=
zp^;(i#7WxpwAZCk`cK6%jbBM4!+=$b<^FPhB8_3bUV-C7{j_P5@TE9q?v>PYa({1E
z;t=dF;pCd#bk_^2pgnRXLUbAhVk;&3iR)1pg+8rS?X^qKPnB-omx*}>=@FZd13B+P
z?Ku^_s`;(gtHh_Os)P9{-TwXPv1A-Ik^o#Y@>}i&E944vV%t@#6K2opp8&q&0|Nsh
zcw8ut59)Ne=UtSepZTZ6QPw1NW7p?Y=+yb+eR<C4PNqB~JlN+_Pxkpr5mx-XANf(q
zvn@L2R#mMePLJ1<)jmtEDd*Kbp9rFqp%C;DPMX&6+eMoOr3^hTYfr8-E4p~J{;N(G
zZ8%o$TTB+HR&m|U-L$&kZXcsGC-9fF|LgoQH+LqSHtmn&D0%UN_IxURUg)o{k&EJ<
zzW#OH^~Z-kj=|r#ey#4>drN=)Layn+!}kp3SZ&hr_apAJyT37iPsdA5N95+aZvWY*
zXOivUcqfn6=eMmN{Wf+_YD&0X&z*l@SkLwE&1W#I=Nb}l>idgz4ePne{r3F%8xwj+
zxFR#}<J0Rd_YTaw-utdirMt$bXPoNmySF&Xq~Qv`3wyp&smeNkBTYG9%a%<C41dte
z%I;P}b;Apra^|e5R<X;xjpwKB*mU@c+U5&v#P^l!ChR@3u>8f*lbavf;@-OJxr^RA
z4>lTU<y!gB%ZE>-sLt{{{k*M&yQi5PSJ5&ywBM=J?^3HC>$ma5_%~{{uh8@36+hmw
z^uPMB?DIDYmGe!1-?6RpwMA`*uKoDCgUOK@?e8t0yJB$TJJVcFeSCcNJ+AvL4<WV5
zo${am^!BkmH*Fp)cspnEyNx}6-qW=9$>Uz{^{)A0g<-EBV4km%-mnGh&IYaO|HkxL
zm0qfN{IwfBcl}e=eJ$(!-LlR@8KlhXyS^`Jf6U&>pR``qvBgO5&)!@=_oU6$@kSSS
zt<Q73Uw1qW3B&rZ`=_~giMjm0ZGG6X&MU2~JooKi@@W$I`MUk_T?fqgVPw*b;JYhp
zT?wj{(0Z(;Rcu7?n`K{bR%{WfO+4OiH*eos^TRLyUj4g!c@GbL`st|hjXZa*8oB87
z_aEI1ccRguguCw4F{O3z@EU^-TA5z9{O#9)+vjF~Th4g<!+TwiuK4J68et!D?Xt`>
zFYEl%IHkUNemz;(Tdw>3c@(>q^IiI*u-5NcKmBxnz|4+@b!7j_ysEO!-#x38ml^@v
z9AX;|>@zW;cFqqKuRSymUUa;UD(GSdYx9}swyquUpIb+^cRwjFi#|Vnrs>-9OIH6D
zdE&(C<8#M--eY>@{YhsVc0ALn%H1$tM0UR+;oi0XAj7xjo%Y=ynD<T2p0VoK_<|pf
z_h?y9_4>Pu=KRosIb=b-BwUT`faKf8H#@kx557I4`r@~W2M%wtF~N4}iQA{UAHL_t
z`%YQsk(G5G^1I6O^1(TmO6kp#hwZN3%y+-Xk%L=r)cR`QVc!K?7rB1=Udx~NGrviR
z-*;UDiuZM2Ft}w%i`nHq{=8D1=)xn@r)Gqoo!{*8;(~R*@_zk-=cOep@vFMZPJLB9
z>5H?SuBK$hG{0E)WUaF&HqCx*;e<afWPT#H<I1{z?N#M`rkB?KTB-8%JwIIdW971d
z+f8n*ZM;3kt@-{*hex&TZoOkk+2_Z$p$w``E+)>;{(9uyu#<ljKWyvllAh^PZE3X*
z`$tyT=Xj&9_qfG|^>DkS-MoBsY{s4G)|sz1NH|@wXqQLvhVOYSDDx+uKfm)oHD9l+
z^FV)7-jh%Nn&o%hs?)KC1#RPA^*Q!gtwBRK?lxLkWv16o<BPXz<&}N@Us>ms8rH)t
zeg0`#=Q~b!mizbl^HdG%;r>1QONRAuOSdCsSP!>!yIF?ya7(unR)davwaM;Hy)%c;
zc5FJ=t>6B0KGDXj&+qy<WAblx&JCEA-umM$GgPXw+7r9oN6xpk(*8!{%qz~X8a{2&
z?y;(O%-^1R+CHK7#JFD?owA=CPQOom<-IJyJ1u+OoZl`V{WWVyK>A?oA6K8O(|6Lj
z@QqoYT~L*)`3-&eHROEvDt+sEXp{PAPNy8>J?DP7?D^x!A3Z(${I*sd-n{wv!Benx
zuUyybt?(k#aJ%2e@0(n4mh-Qz_Fb^q=k4?TtcMfVwQAocigs98?VY{o^>82dlysCo
zvcb{qmGbvb*BY%#?mT>F%cLLPcDf(vH&|oW^t+{350!o0+%8J{c~zw^dyU$*{*1%R
zW1@eW+hygR9H&F?A0FbcyyK{$H)>y?4N=zhb>CIaxAte1Z+CTaZgmH2TD^Ou;mrL_
zoz@;5zUBDhyYuevot*f8ZyjDfB9U(&>>ltzj$N!}RMrX;mkvJZF1CB`FJ8ZI`u<NR
zpIUuy9UqKND(`RO{A+!5W~W(~QK{38H9fujoPGOhKE8j%`hB-(UgupKX85X9CzShb
zpz}n(wRZ-6|7w7`%boGx)n3`cZOg8DJ?<WLb+jLIX8Pxh!QlH8{jm)-O;*2j>!&s&
z3mQiDNL<v`_N|p)PVtWXeC<{B<}U_sdhz!5%4+wntoH26YJcuU+ilye)Gw3n4<DD5
zn3-T{K61>>S=$}!ZCm4FZ?Wo)r3c13ZfbS2ib_>h`)*~mAGBJr5A{W+=B0NX-d$*3
zVOw0UAN&6@YyH-V*PA?;pBK7#&A7R%)~i&1DDgXW=VR5u)2&w91%3OCf6Uq&6+WL;
z(`Ne!+myg2Mz!l&U&Ick63(#x@4stj?VrB>?@hWg>2A=Eu~Nof$xjook_{a8UZZ6^
zR$ruybLxlGAEz7Vq>O)(uqBW4A>7OOc_ZnrSNWDWPB$({`ELL8aiN5h&&grPSCHYl
z<DA*njj2(_+VJxUJ1$do$3-D|^r)sG8z8468zW~RCEgC88_%MQbK$2l#zDrsh{L{%
za{YIZukm|6l27TXcXh{SNFd!<5E*lF{U!N+ubnR^yXYQ{E{E)j<Q7+TM@stnL=!FJ
zHh2^(_GRcwi<WCrbw^J{_D9Y|(ghR!9&!-!N2EJ4ANdwi;_rzx=ei@2?U7zcPozIm
zY|{iFKSz#6?nQ<mzek25&mzN-GDc<`QlF2yaU{z45=l?Vd?fDCk{%u%O8iNKa$FF8
zy73^YnQY5(lHbHnag*6C$I(1e^hp|(ax@Lu41bz+(Or?z{E-$pN3=I`Hj=oB{ha71
zBsx*9N4)i8JCrdWa=l9U`GdHXgd>isMC2aiYGfwz6J$1W4e|;y87b*rk1U5CHX<t{
zd7MQzL~cdOSdwi>y?%7#D3tLHPwVGh!by3JMYcdLC~=%_{6ne7Ez%tquRHETq)T~O
z7sE(Z0RPSFNgLLYrk?0TKRLv}W^n4vZ-@s~7w#j7h9t-UGiQ~`8G;}l_CWzybj2S+
zAPzP|E|_)0AN(O6_CY?>=+3nu1QK8$<Ulc4_Fx})LKGxG8stDRSoUN;ctR8;KpN!0
zUtLE!={9qVp$Kw%bAC|wA<p0p(U1uHAQy_jg7%0r_(KdN!9FN}8m`#O0uP9SB*=gQ
zFzZX*0d5civ5*28kPGFggss5^f*=}}z-GvRTqp)hD(QCM3Ly{&sgMl?U`l_ytfk@t
z{tyExkO6t{Pgzqss*w?E^BAd;U<YJEE)+s#>K<$80p1V=agYRw14#osZSO3KN<RU1
zKsH<lvk~ZuMuRIjQTh9WtVf;7!@1;|)UqD6I}Zf?n$(F!<mrBnjizj|{b%b^pJJb^
zOTGC3*F;9qSja=>pCdo1M?<(yX=_tEe5JLm<}!zC@D1vD>rto9Cf`jN6AMm|%kkNB
zDJMU2U-A3T)}+oQ4YDqE0`ZFH0a4OUo7v06wKDsWR^=$GNU_<L|2F0Pb*=3-vD;=b
zk8%q^lTB19Q%qFuQ%zLYqfAsz(@j)~kT%0al@)EGDuRMpCMwg}CaM~(jZ~&{Ot>Kp
z&Y%H<1`HZ7XuzNWg9Z#5FlfM_0fPn%8Zc<UpaFvhUZe($IoZR9x-**5cW=b|yd{0?
z<|@^A(7W^aZRWSk-P}mWy3D_nvE(veHHF_YS5)SO%3RA${0`#xSeOOnt7AtWD#FX4
zck|e{48)B?j)%#*-*Q|U$b7kYuDJ@fa9)|)w+(p!|CqWQkADKl{K?Ju%iKnpw|IhZ
z*>DoxBAf^4-4FPkg46H?<iI)j5q^SP_!)kIJh%WCA&vB1LgvF|xB|a|tV4YjWNxIm
zK3res{PqJk7zl%4FbsjAAjisl=8+)t?tQ@@0wD;3LFO;pgUrbeg>Z-f4NQPZFd3#o
z6if%blXE7ak7QT_*BKA87P%gb*|sB}MxsN#D~F%h4iMdly?_`H8wQ^cz6<HzhW{4$
z6vjdr=-oQDcXPgXVFBpfAp8fz5Euq}w}I`?O8nl%_HNj#^E=8pj<S6O7IW>3{Fb%I
z#qGn-3%tP(0zupX<U!qb7V;Pz*Zuy4bgU$;t4gHzQ?}QY_`R9!Z6$v1VtcRd_d#Ta
zZu<!GTitd^JC?`r%hvgyMxNDepGRKMZ5t6E6J4An&Xw7&R^s<k(prr?kg+>@cZXyD
z&>b&+)d~MfiDPQ8U9-gRnjHITiQ`M!*Q|s8YbEy8XIriNU6X6nDsi2*Y}@I6m$dU~
zk6#C!e@~=~Zrg@9Gy<y<acRu9tp7d~hCvg4Hw9~5n3l*^u!(f{<2-J<bGai2>$Zm?
zJ$2i@$N=5;)3!!u;6F#VucY14j-0=f?s_5Y57mVcU252#sQX>gKIyyo#p?XykV|#j
zaxY3f)sOyJsh|FeeNq>>9wfsKNQW%Qg<=r<q-LOo9^eM@Z8QYpAqQ-!teqenq975n
zK}DCT85DsleX^bq1cl&4zp^WMfIo;`fM|$=WJrZ9$boz)gv#_mTS5;I8v>q?2q{nm
zsTCx`+CF7j&%*=!AsS*K8PXva3ZMvT(2r~jt`G!sAPy2>2V_Go6oUo*$1e0S$3g;l
zRN?#(4pFcKl3+8W!70dt>rf09Rp}oGXYhnc5DUp5wpg>E0E(bSHR1(M-~k$lli!rd
zBCzFo<qVz>4s&1$q(C~H0vpPLElBxGg>=Y*9LR@4P*MIZp&dBG637Ef%2ML1oCj)9
z*II!;#6u<&Lpuxd0^GqLLimuK0(npfaTr&~0gKnTx1a~aLLL-?it_IXDIm|YAfAzl
zuo<p{sy^ihEY#=#f}mUjt_S`ggAp>osv&WK9*_)0VATjeaI+#FkOr9$)0ljPJSc>W
zCWHr5?jd<@CBqJ=Y>lqL6*8elGtLP+ARmgrsX1weD3N?)NQBLh4;D6*74U#1kO@U#
z+JbX|r!8@TG{}VOVAYzmfj_9)GOhwbAPQ1J-Hv^r0W&+!4Kc6;(jB;F2lNd7j+9Tx
zfKw3Hk!?5yA$<3Yhjhq>C}+|PJ0Pelc>!tQ;>tdV1^K2|qaX2ua7Y08ekb4VY`_Uz
zz#Y6H9NgRp2lB0M2gvujY`8v%^SF~YQ28zL4BR0G(jXJ!J&=$C4#S8)q(LSmjzqsu
z1gT!=!5h7RjSqT(Igkd$VC~EC5Cn;^8Fu)Q7JuRZHUZ=Vh?S5uD1c%x4I~Vx!3G?l
z2e^SJxQ-&tK}d*&WQZ`+wwJ_?vb04bk<vbDiIg^A6XYu7Y^1bbCL*OBWv%nq=zdp5
zO54>8q|It@1`QZAV9>z-H4U`X1WeM9=%PARsSMe$M3#F}3u>y|mJwo%j<#<l6B;{&
zsf<)3OE_nmHZ8TmROUQKRn9b^XdkI;kR_ZmuW>EIwE;Envm=`QA0RtF6VAD1ur^$A
zHTJ7HnZz-xlyJ7Teu1MHgJ{HlX|x$5bDs_8HLyol_pXc+m;KVPleC_HHe5@Le1-80
zTUe9*ZiIUkdGVQW-S9Oyg9Z#5FlfM_0fPn%8Zc<UpaFvh3>q+Kz@Pzx2LACHkk{Xl
zf5ZNNL~!V+XBPmN=ocC6H#S_m1c1tsuPH{}ytZRqy^bmmQ^9)KH`p&CEHW%mqqZK{
zOx-_R6FfF}3TISz4;vfK8Uhh?A6S`tc}?*1^3iA_f_=wp0wQ@8w=xe32*GrINngHS
z<L{#h;Tm#`*v^jB_-F#W#`=W%j0zYV5K2dfgu#q9^Zl&MhXjZEhfR!BRb{(Z*!WO-
z8iK<@wPCt;>;0TCuI3wSs8o78*Rr0VxWyp7A|Jq^mh^=?R94X?;pOEM=@%UArBjU7
zmNDJ#rMX9TuD#hC!S|c~Mj=6wZ0qeZYyBb=Ke3JO%)Tu8Mfw}zCx-g@E&jGh>D$rz
zPw)vDAE5ZFANg}$ugCrl_-oH2{*TXN^(cHqK;-xkIVIgIkL{SJ>(br}e?Gsd=w4BU
z@@*!(gEsA&u!$jI6UnVWpUB4xA!v1AP1t9hTG4^5Um$4+rrQNO)JohXjzwCXh#h#o
zB532{sI&j=O1G3aKDj9Q;D{X4j&wa87yWt+?EhDG^jj<E(Z)l@B|I-4Ep_p*)%Bq*
zBJ-s@EJR9qP&;aMqAv)~v*#^&?#A&?mjfv~PnH7{b2rj1-++_Z*I9cVMQ0>mR}P-E
z!~LpCdyEZnT|=0QC600WlVeKS?oNM+K)7S%zjTj%gB;7n)J{*N(JO>~lFl6x_*wU;
zyzgV*)9K83<oCF|XW^$U1L5@11&0QPY0JCl<mvlB?4d{FzqO&{ofqM~#!J_u6dbun
z{E<?ipT0+WJo10?9+A8#?H+M?6#nr&BKmEIZe!8Y2KKkt>g7>6)?WA7JdtDe>5loi
z#4*l~uJPnCk|%}iGv&T8*#9=z|IXl>`BW-lwaN0(Ju|-8*6PxgF;17lqMBTd51eIb
z<#TUb_>=?Z<3lQVG9HhDt~MFC;^?^akA9eH_U7Dq2K(QiZfBfZC((<+{<rt?4|m*8
z)x6|<=bh8(M;Xh(cOA9K^X-5C)9ref)n51S-jd#78v<WG(QLu`=Epkwb(z0#saZ_H
zt>~hH#XI6^@9fp-!T^K4?oT)W@3hzbQ%}j?;@Rt_om;i;m)TQZ-t|iT#^cSV6kN4A
zcfNYc&Z4_()^wOkyGAMZE{%M1OpQ&(U8`JwWw1kHaY4ksf!1$qvoGK6%Fg>?55gIr
zV<zV_*x{br$vNidBd=O+onez+V?JY&6#XSTwOU#I(z;6PPN(}{P~Dqa*}it#?d{bn
z&TAhN@!GDVO&Cwj7$~)gZ}gx6y$`)M`mHTDD(-Dx-zvM^+D|k0zf;dVtNEBt(Rl+I
zPyR;P!qx64;YPk6ZF#NMmhqn~&V1{k>EsHtvy0DWoNRSzx5g*)kM_&vGCo^5UtxUU
zCl=#R^a=Ge{@v)*Yf~oO^xXNz@84g%GOqcyw^D5uGCrC{nA+rI`+J>+?!VUH{mL~e
z>>HjqD8=cb-KF_)=bb8^oak}uf5Hy85#OQJCiA8weO$lc%)Tf6`b`>PJJ9UJ*C{Vo
z*W?ej$-6yoU7hqJ|2aF{|8)D>|0%oKWwnQ0M`>^DSySOy|CY|io!YtX?0)3*{F`I*
zlV)_R=9LoMSKWAAof`)G)du_32K&{%)6bk;v!R)7-;Y}r{<>mS!2Ox)DtgYX?>vk?
zmLHXR{8Ia*amCY%9vnED^FgD`Yr|6S414fOui$N)`rI3NVb)mQjog)bJmJpepTGIs
zGs>>syoUz+)t}R8cG^y!Gr6h*m##HiRQtF3K|K%o9KG9rW{orXClmMDG+!CwbGdsK
z<Bb*l#qO_BuypvZ^GEcr)-SMGo3}ri8yNoo*gF%rnzr}<pPZ;jijagOA&F)xNvI@g
zAe5qcqDccGbxIM65JC~65K1A0B7{&fgb+eVLZ~bGf1Z6#bi3}&{SLq1|NH&5Uaxmg
zXYaMw@T_64z4uzrs@onJm7o;1xsH7;0rPyB@T}HZcRsz>E4Js{+c|CatCLXwy5U78
zhizKX<M0hrgX`x@Y@cNssU4l9{&kDihG5q_(?mX%WY^<GZaiMZao7ezXC@{Ijub8L
z=~mcgzxvQ!to0g2dU3iiAa(G&c4sUEw(MxLU#%K~>6^NwmxoV62X{UGLNR5fo>80q
z>i<pq)gH|AN1nCyYbS;D_e+Le8RhPORo?&9E!S8Ny~Oq2_3O(r@`Qig-t=vz-(VF4
z91q(eH@xEY*}ijL&hfaj&)0QWxaiw2`>(%>+{&)NnukeL4_+62-0Uh8^D1q`tqs-2
z(aINHPY&-N^*C#nW13G{NFfW~CGdfS!=6=sFZMFmc1ZT15k+~O6+*-lLyJ=eS%+OY
zdO#xk+Dkl_S&SrqG4s3G)e7icxNR&_?EiSM&)eg3h8-6gHS@5~K+y?m^_y8NHzqva
z0}_K+qbvh-vWpXypT`_6Ynb%t%mB8e#)u5p=O_BDXR+4PcLMeW)0ldn_Ms1R1OraZ
zx2@KGyyU6z(0-SSH(C4le_vdId%3I(`D?T1T)9MMeWt}buQ3)?-90L?j)u{5`V_%W
zVUznT4o(@8)o1LwqKXBw?;LY8N@VNf&TKS4g!#*D_MC@lsJ*W8GQH4EM{47eRnd*%
zDz&j#qmA`e9QF%a+edPGz7MXQC|K9|X5q$jqs97v{Zb%jm^*T!`OApqXh(g?pP`A7
z!MN$=($1?FJT3XS;L`3>tf_g6dYtqtk&W1D?2qqHC$Juj!xlc3FvRxdw|keRrghz!
zDV60rIKBUjtaak!l;0Ng|FRSJEc!UgVJlmTWzO2S@Z#<(@$KW39~p@)J2LTDe7gzq
zF{wMb(hsm!J%wrK<@MX_#`hZMH1NS0V=vPILsq}}Z?)(AuigjuJydNE_}|}|@ABsO
zrY3@8mVg|V&vC^d%^{^A@fw%0Z)^oQ5x=b=eIaK;av|}#go{@|m@mQNu7kv~IL6Md
z9{%Tl>n2m8EUwV+?K{`B=h;*K2q};ApCK`<WBmq+>cIK}N$J%C{O{Dv_v@D72z213
zw;iN3{K8fw7oXW#LXhYVSi+DL4)W9VotZ`7pDEu+64`NPoC}gj`F4dw^=5fMUVxkf
zIT!x%y_O4G)GSnME`7I#4w!JG;D`Thm-*&P;ZiukfSe-y(RbkCka>_wkhFdo-_W^X
zka!f}?uNvzgnJVbY34qLM6=*lLym*g#W&>fkgFk)UhXzX=#-ldX#`2%m{B&|BE<dQ
zY-d=$8ub)3*&BB6D8RBT#kXWov;gZbp<kJWSl<aufIA2V2_OgD1PwrP5%dI1fG>yz
zX`m2P0b#t`E<=G-fd)VuY|8^H;0vNaJV*sO;3lX7!dj@Wz!n66WTc126GiyH4oGQZ
z?Ixf#ve6(5Q~=r!N(VTDD3A_ly{sS_gd(s6!5|6bgDN13cVqw8Z4S5D8AhG6#?mfe
z0s=q+$N`l=d?s%Vvn?bSWPwt^vOyaGR=^h|fI?6U#BEWpfF&qL|07O)4hR5$*Isaw
zo#0B$zad+}MZviLEJ2(gsw3hHL46KI8U@i-fjSrM3i8iv1Z(1bKiLQ-`@l`Mfy>b!
zkbU3?oco!5;98s`+rYx;?A3uKFj)f~yu~&6UoH~yL7GG6K-xnVLN<Wrc7ku>xUDeO
zhl6DBXLf?gM)1$<1OLo6a6WX<+%9nX1VL8*L_t=qu^?<?3$hf+a7CMI(?FXB+BDFn
zfi?}aY2bfE0~qT3&i>yxjDuE)V+;dMgJ)oe4D7K%(!AGVa0@iKoj5lh7=R|1jQ@9o
zntm+SJJ94(aE#`1r$X)n3&A1~3_?H{hycsMN<fZm799YGKsq=K$h|-sUV=6Fy$);u
zo4{s3t_tVgfVY6$Sx8U3bENsn*YVIx^NeW@@qSsv0R-{R<p3nv7dQxc2;?Cw6Of8D
z?*kL@|5lI)$eBXYe4pvS8cc(q>0kzEa&%lDd<6r*d+-sEBbzisfFe)=s({=#$aV-r
z5Om;&Wr$-2_<th*w=sT`-5N<?iF8Z{RzMl30tGM>kW+)y03(4G|Clx8JmAm&Z39U*
zqGo~FzyUaeeF*;^cmkSS8vfV8IbA@`4blV5<^S#kU6QTHbm%Yx(A;arpEPd{{1xc`
z8rY4O1u0+;n1gbmdHPpzoa_ybM;K&hie4ymMSS8I^PWTa;y5n>7UMX{E;#Ommmsv>
zpb)=9aoh+0??KuAH`@H$iuUyXi_O1(m(9L^)=nR_IchIdPpQq4B%6KI2T*&Vy8WxR
z`$SQ3rGPz10yUrkki9;4kPRw8Eg;)`v7i)?c@!C-2rPj(p3O9YGY9}&5Dnr%8K?pc
zK$M=vfFjTVm3aPA#7j#ZU<53IGpNAxlw2n~=K(zs1>!*}$Oe{3cmhZR*?{(JQN-dL
z9bg1(fhULnu^<851m&O#2#X=jKoJ;$V2}^Uc3wFk`*~zDF9O7YBv1k5pkHO62dV&>
zez5}XAOIwTG9cU)=YSP(2SFeTkZnD(MXCc#fGzL@wI~F+UdS)d13@4M6oOJv3CI?n
z6#5uB5Coz?1rSAF;0}U76o>~2r~@^CHUM-7SwIH;ha%7fWJlH+1OR$TN_`92$&&&m
zAOggJB%sJa*dPkT0s8@vAQ_~C98d~^<nSBhf+A238i3?L+zWsnumsK^0K|bLkOp!<
z8K?r{gOFCB2y}oa2nJ~&2NZ%DAUYWSfF4K&wSXg!@&P78Q2zkg*`xIW5em=&C<iql
ze<=I|K}DnmB!etKcJ(xY5hwuS!x1LP0u`VZXevRcAc&+gbPdu#1&~xhzYfU$UK}U@
zwLnl6VF9wW7Xh+C0jL6;5qM_->;b)_RLA>AeP9WqK^@T1LY_b+P}YWD;0qE)BR_zp
z3qNC!7mx(ffx9052kAgxA9@6|Z&(_zG(fq7SfFQ!G=Vt4vA{Xt4CozE6`*~kq^2W&
zU<=f(5Ecjq>7WAC0<x`F3j}SDK3n7wRDfDgV2}JeAbd~;$ex}N;DTIG1sZ^&6XFH|
zAlMo83RHp`7hLO#yaO&s2f3gSl!6LS0~&y^8_EH2fFjTY`oJ960<yQK;{gexK`MwB
z=iR%vL(+X(6OzVKoB78NLef3B&9!NuO#^KjXw$%dh6V(Y%$fhh`hRB+pFb}DcU|D;
z5#YkC{{L@Y`~Q&DMS@B>ryZ}X%^;+JF_=08V+Ugq79I=urU+cz?c4$#{G45!?VKDu
zJ#_-T{XN{gU7R^~c36u(LS0u|+Xp5M90Gj&<cH|!csh7FIy=}osA_0xxvFS6X{cy8
zIXEe+IXSqFaCX#kQqxq^&~VYxRc!L9Iznrtx{ITRii+z<Wfi9p%F3=zPOc8B4q77}
zG+k62bvc8+`*m>Ea&l31Rnt@*q2i*Z?xN|SuBwVaozyg(U0pPtbvYO=F>AIpA^+&?
z`RnuBOI+dQQO?9vld(^r2hZb?cQb(icMpG_%>pAFGh~kWy95OKGV7nsacmNE%)yCg
zb>YVvZZqb%lc$S=H+=Jsb09H<rghrCvqA8RUj}6JoSZc10J_l+I6bx)m4W?#W+4pL
z*0xu{A6E}=Ic26iI83fu{t*vX#UU|Pdx@#M{GvQYFux~$|E=-6@-h8M`Irj)v3yJg
zeqKJN0zWSw(-!69%`YFCuR(4$=n1UBOq4Tg62FZ&ki8Bp&z}pU9eyqjUUm-N{D$)D
z6&#h8><nP2{Szmymw}_S=HDLjhz!*wUR30nj$_!%n%<&LPG<>AEW$Au@c6R?YHQos
zd8%q_H>I=HCQI>AxSRiGxUDr>3YTmFEaK~&Z1t0~19*gHbiWgEa(Oy$N^h$j$B(SF
z>Xp$y#ra3av*|(hEQE0~fzdOsk09OS@qx7z&){YPI=n(bS(0DsPd%Bk((w&&)@90x
zgJav7>vbFhU0q%L;FrRX$8mL3E(*hAkqeIUjw}B-?gTS00d%6dp7MprC!U8uN6-&=
zAbi@a0DVW3o?0!}A9`xl>o4oc;TQDOJTI}NTsRJB%F9ZGq1+-bt<|Mwd1=k-FXtuf
z7xOZkUw`#PC?|LZ1@!N7un%F_|2{9RR?6l#Rs_MMm)iOt-H$p-_nnj$>D9xr2Bt3Z
zsvQg!G4-e^y`}v0;`I`f-X4(l2t$1G->pYK1_B6zNiWsyKe`|3r8+*lS$e5XG^NXz
zDgs>dbcMpNUW;_KR?t7w<FBMEq(!=n`8IND`RPKlXY@sF{W0|G%S%_22`3CO`S%2E
zZFdKM+!z+x@d^O`|H^g`_4m|=kZx#Cr=~Fp>Bf+s26}HwZWQPYMgZF1DXH}|_~2Cv
z6aUZ0NF3&VL-FguU-S6sm=TWAeo|%vuAUBV{!Be;(u=4lPQta+OU+-W$<f2@U#FKO
zej4y<iO~z)Lr5<i)8=E^faYa`!Gj$yGw@60Lgo2K_d_onoNTEVs!uKT(qv<+k_rgU
z1)Vb0<ynwfs9Q<=H1QrgXf*BO=k4Ihq#=sA;tzkA@hjakVsWa0DTnV>im5a4I8OU9
zVT^!V39lX{eLu$BMwoj}Dvq@rOHlcy<2diWh1(YXH^%+`EYfP%B9Scz53P1)2#f3r
zC8K<3&zl1LF6HH)Ne^Dh{nXYI)%hkp(tCVzet`5i2b@RR?9F*)%TJ=W4-Lm~j>_^M
z(IeSj`k_Y`PsRkB9Z#QhE(u}tblh}~r&l`nL$AJpj-DP){2t)@7*>iIEAVtndDG>$
zXZr3)Zjdl9Z+#)@{dUdI^7f;uFnO%wUE1>R_qsxZftGcJ(n{ZgexHvYd89p^et+&q
z9;I-OS9kuHM-I+4uRm0$%#pI_u2d&^Ht{KLD;(p6AK(+<;A!W$kSyf=823~&{oapp
zt}L!G!udeZH2&rH8vK%>@|KX$#QCP@EiVTTZ`|veh0T^IKpk=xhdl)N)3#vh4O9Q9
zt_Lt-|K3Iw)mgfR-Xj;|yu_3r*Lb#aO(Cv%3_nkrT|;sFRXoC|2O@Ybx5fuEsFKN3
z6eLeqjF#*IeC(JP6*$cFzfEaO!?ibX(fsMWYe{F>->>y@2;yntch^%{aN&pcMKlxO
zg-?M8xOlS$;hcVpb9kx>#9M%cObW;o9O+%Jg};_*q`KZ@V~+NtBG<AVb8MJ&^O`Zv
z|D)}f>Rddo=jrSp>j(94eap65i(~d^zyInrA8oeJ+H9Y-**-ISweO^nmV{U5kd^bM
znpiAJTzyx;P%v~ii!~XY5QjamIAQzdb!#<VyvvMU&@=vit-!$$mU+x}?HTI#Hfglk
zKGPE2c;`}G`<*)_{!!a!S8=1}us?S=@@QG{srQPFG0Vypt{Q0j_|)KDw{F<2nb>`U
z(9EG{aW7=b!zX6%efJ$^6GFl}wHLY3`<=mwB?C3fC&vi&HC{f>PGt}Fp~ZJ>4tsE{
zX{?B5Ktk8#;um8N-E!`=a>mXHa(NF*JWG^i<sJ>f{=0aH;jq7GAAGAiX%_2R$2pIC
zwktcA_t53Hj^da1WvR{GRC1tpJ=SL#kiWFLbJM&7v|mnqGrjuIIIF|q*HcwXj*n1w
z%dp-xBcpf=_7$}tfAu~)#x%@NNzL+_)}MW#WA?a1Z%Wvsv*Z1B-_MFuuEY2EU$vzc
zj(0O0_KKCA%ck5t<1!}c(6_r159%J=)z;Zja`eT#?vZ^&<F0>gv!(W*YD?``ZKR1}
zjKpD&Z0|70^~m15xUm+YcV;Jtdem?4`O3X#f{K@nT(qCZB<#h^)YH~&v$fe=yJ{m>
z_3VC|%{8i5lRA&e(|ol*=F$VbGZ`Wu8<VfxxO`~cZEcfJ9aooq5kp_vTb=w}kzVPt
zYwX5YWx4Cw=_<qCd^)WmZYv(9+3?BN&q!m!N9^H@=MD~A(j`+fT6T)@f`ndWcSNec
zNqDTkA<c4st|c!K_TX>|`pABU<nQRguFf+a8GTcWp1<7To$3p}I*pAldI_Z8RPa15
zxpkTep1CHFzu+*<EZug?<;uTGj(U=y_t0j#`L6Oh|LLv@3+^9~a>JNjgGpcCy*r;O
z_`Huluu#xJ^rE=@<-HkxT3co$?CsdKb8qP?_?u`-;jKS%_uk-?4)HtR`j?dKyb(F?
zh<=D@Uh;j}QTLQO*ZUx>|KDx1tzzz%jSq}E<qt`nd9v#e$2_Ym=MTT@c`o;|W6a_8
zCVSQlf1HOk_Kcpdk9BFt9Un7oxaY8?g4>RClIGT430Yj=dw=DSmz%2gzQ(f!=74e7
z)jn!cS8gY!@9gyDjeU(!XYZ{U24V)MA1^$S68pT5#ysd5bHF(4RbQop3YCwR=tMpJ
zB>g1K+5K9%z5kTz7?HWVN7_u*!}D`0lRmK>8k{$rpkwz(zey{MQh46yR?qt-hnDtU
zJ^#07g}VxraX)9u*QKz?qfuR>S4vff_`*Xoeb`a&4oP*|ur+*M?9h0f^v#%;&V(oY
zBIR`_(U4Pjp8d9ci_51$A5#V%jWSor3%cy4HeNm(4_?1&6Hb-6Pd`sudGq4zdY@ar
zHGEUkGs-V?=(4$sR^Du(T<v$0?dNT3vmMuFJFd-kT$}B<poo)#qn=E{^WbP^9Cq9-
zZISU(3pbk!{dO#~>9zW__6%nYMJ<;Fn+vNg-}QKjbv8_YDtoj;da{V)hQUKGKX1^`
zG3&lv^wFhGcG6qs4ORMP-ex<_jq}CON_&Hi^{RkcS!1(gwdr32A_v_XiZxVt;mTp_
zpXz-?>V@)&PUQx*#uGG_Z4>@{%Q)M1NVx9;;jRtexOkt*_zQHd{xs{G@Y`;7%2Op@
zY)QHjwQ}KJ))LFW0pl($ncZePZrSh|9@~_ZA4pyuos}%Yu4ve+r7$CI*g@PcjY-cb
z+kJN_F5iA}Mug|MiL8jQDVbBJ^)Y%YG`**0|LE8@+i`L8g4gbh6x$eZSzCJP=zBgI
zwR^w0D!18=3(Q?860Y}JDfgLTuD!$U@NWzDDveP6-?Sa~jd}j<aAm)?dAAN<@AjO-
zO4YSFK0Nu(GM%rkPSXN324CO&<^txbFwX(4+n5`}jGuROI%DXTx$mB4$GO}`kz=->
zD$}{J_VNtPt)twm-}QRd{nu^LtzyDUdCYPg&q*!ssu_Epwd#s&Sl(crlxsE_H#XHT
z|9X015{vbJ&1M}wQlcMPchX{AnMSlsa8V-LNXsGLNcr^FP5W{~^7bq&-T7rN?!UK~
za+~MebK||^;$z&hmJ|=ZyY<1y5nUV{e~WgyzJ9sxiT$Bi^HCy2;Z4z7;FR)t>g^sb
zoH3sRulL$M%sk^nU;X-PCfXzC-U~U>W-HIdZb_PbPmkg@TX|GpPS$B_-6&NX*YDex
zy7I$Z+1=s}uN*#4Y%s4|<XRb>G8${n@J@om&Xck#8pK-mY>!M$Zkw$<xi6Sgf{9xk
zcK7*Tv&0S$eDqO$#eJn)!^d7cDfjMq|BAh~ilN4SJ>n9u&YEfGmCm!Cojo_wZSCk8
zZb1W%AFFaxUiPJ5wst^$M&;f-b-Zs6Wc2*b#491{c|e1SgSd|Bd0)$8T@R<FtgTjX
zteid8PAjD^i?xmMH>O`m^=~(P*Daq|utk9rS9tD2)R2tQyiK331uT7agUU=DWyfK^
zjCj%^?Ca<kI**Oh69W@%%nq?X-<}g>KWt~(I`zYo@sagCzO&+0L(@ETvUkTgn(j#7
zqsirCIw-mq)_KVOkQX5pAumJXa{}ucByL0W&7O<l73&5hg)0yEbE}y-*Z7HV=vZ$^
z|G-^=KM_c}p8VtWNYh+jW*%xC62ZnHIXVs}FTmpB^8jlIB+U&T21(a(0DrzJGmo{V
zJ&T1;^UQo!2$ljrd=CBK%?o6%q40m_uUUBfxsX5gr^xrGiQxG244L_d6t5tTk#5Kh
zLcEl}!H|H3DJI<Ikj>M>pZCYivH7d?@aN(E)L&D2I0&0RFOHcP)-pVphx@KC{@gWY
zPFqWVsNUcG@#mBMG(3@J;qm8uv7C{Hmf<z>!^5LX(>yF@eirGg1CHqca;O*F-jMk0
z&sBlM99u5w7;{XxR8RvUX+9SomzeZ1`sdBrVdgiq)PFAgQFwWfq<?%)<IaIR$G<)u
zVe#kuFmr+EdNrI+#&L3Z^~YSV2TAD}2T5@nKvF%Q0NEdYkuUCh$cd08sNj<!g-~&)
zK=y&Ogj9f>0jUmY1*r#V1L*-d3vwYO=Ff4@LE1y!fOLR-2ML{Wg;23vA!k6kLC%Ln
zUbwlCo{*0qy&*qC`amimFTRj7A?HE*LHa>1fDD9O2Du3G2xKrM*$@kd9F7862I&SF
z1-TJ&1!N-RD#$d*Xviy&=(f1;A>$!MgfIsLk^{LFQUNj%QVVh$q!nZm<SfWk$nB8(
zAWuRbge-tO1bGWG1Cl0yW4OZY0eK9P=4fR@QhTQ|;Ll(AX}O~enR3HxZKm8cAgSCj
zZ<EVKdUNCiSXJQvl5NN~yO5~QxF@Cq9Zc?b2XTNJxh*wxkPHfdxE}6Xz#YVaTu=q1
z#^N~e1hF6;lmqc`I1Zda9LNQgKyp0d0-hiN<bpEL0A%!W4%mWVkN|Q(8E6191~?CF
zK`=-FIiL)Xu~Ru<1PVYoXaMFD@O}uyf_zX5B#mIR;S>5~&}JVJ>)J7J_@A;589YFM
z6$_F<HYfz;pcaUt|B(m!z#asHSda|<S-X;1-G6Rd(h>uZ=Jq9%>QE>1FjnNEZsGsG
zvNc(X^G)_9)6ep3P6l_w{Nnbg>km)|t1<TJfVz&j{~fj`vzDSw;2xj|bimC>v<*o2
zhiG$<e`SNR9C;)=lnF@h&umdvh~j)lv?)P^1DORXm!ZvIpwZGMrMVewQJM>~s(`+Q
zAS)G!P7!4Jf-F!6bf)4rNCGzj%Tkcl0A!{KvTCN|cbjX|K$`~IH1Hpyfp$pew{QH!
zieo&219gzJ&VlBAXW_wZ9%LYBa<pb)4)_WhL6iGN|M$UjH)sdg;GeZ2`0utExB_{N
z27hHckn9AKeZcmh10WlLLXfmRLl~0miitpW1bH}S0@`c_{(YN)qR?MwpafKa8qffm
zKpTt#qrn(J`W;LELo&7k@xLK30>;1um;y6EP7JaO5C^@0H0TXvKp)T-^aC8wAM8Q6
zvXGA;2SCb!fnX3A42FQAU>G1L0ofIVqU^&#B!~j5z-q7-#DR?<9&7=$R*CG8Z39Vw
zT=VO?Av{UY9rOS_0j;GVM|Cd~V?J8{CMJdV6OelVty!ftvb4UM*0LW3WaH~Np!L<X
zZkpCe?|`JW;3omuVaNfez!{JWXsue4Ye4;eg80ti7_AfQh4?N&(p-Bf{4dy*w=Ss!
zer|$Wz#Zc;FAxqo;JgqJ0UZIk<v6|tkede?2o~~xPe(ef`1z#scMx7FxC@SfGVlOA
z1dl*Dpmn29K?QgQo&#D(_yUsFExrV=z-v$i-T+z~MUK|&bf<h^d@BMPp&!zn6(Ac0
z)%dLsISbGlTUyiW0LZ3=GjIj&AQEY&b>nk^H}D01AP~$4WJiG9WXQ#U*2U5~+%RAU
zmV!tS1!&E7G*|=Hg7shn*aXOK0J&;O7V8730sE208ju1yAuk^w-vMFdM*zRcFv(b4
zr-8Cm<zG*BIw%i}9S%qfFcrMPb*~WSYtY>GCbhLD`<rBUvoq)jIsh>s3fco9#MK_W
zg?`D#-aGIfd;qoJBlrY9gE~+Tegj_st*<60Old|~8PI7aI0CZ4bEN4Fcn8|y{4E^2
z4NAd1@EeZ51-eM<H^^E*ZTUE$J#>rlyIo)0oA5v7Clm2yfIYwq_<$z27yqAxzE*)4
zKyE6IO#?H)Owi=^<Nt%rexJbqC&6j{F|wa~4gX&On-K4F{I2AOnTum~z#cdOS3vG8
z<az%8MUchd2LJbef^E|-&~;bP<UXT)|Hg0QbgV1#(v6=VNyzT}|LI(JT-T%7wPYZo
z8(&}2INrP2xqkSc!~fkK;rDD7hZ_FZ;Q#K4>!tW%jKnc5{&53HBmVz~P&WTAyQZU%
zztQ|W{wr;qQvdm{vU4g2-J1ivccyp0%$_b~kd;7L0PoU3IgrCRQ61<36JQ0L0T&bi
zVK$BdXW$Ep00)o9w9NzA>PZH5Ko9R20zd?a1391o&^zmLAcyx3>Odb@0%t(>QzL*f
z-VFqR2tal(5<nVI#52Ap2nMwGMiD3nHGtI#{S=S_S)hS_;~jw%&<D|g?53uIEKmgK
z9YPfl#(HZ>pbW^4suc(Tsh|cl08uf71>8Y8$OVN!ybJUSY=I}BdT0eAKpaQ{WM7-s
zt*QgEnHmA&0NG5<0{K80Wli_iAP@!O0SA4hIj{$wAQ@DGIw05!X$Bmi56nR_$O7Wh
z7+ZljkPNawJ}AI=R|fS|5zv^0?yoeiqI<G42mrAl38aBKKz390K@dm>xqxh@TJ=NN
zAPeMzXjw>51j;}iuo{4HfiDOK@gNHnfSaHkGyq{a)CZspbbu8I02P2fAjtr-k*YHY
z^$b{n08kF9KphYq3|#;nU=D17JBR?WAPr=Ld{7P=K!7~Xfiw_=`(p*D1@y5`1_XmB
z5C@V#8Ylo2pbkh5MVvqf7y)M>tcZ9)5QqS=AOU29LQn|=harv1&<98bS)d4%1C|Qn
z14$qakR8>Vpd3^IVO8h~C<7f}1e^gEB!E<q1#&?dh*QHiSasAP;0uC56i5Q;ARm;2
z8X&2G`~XGZ3xWaJY8A&v7-!%Ml0iDS34}+Yz61KWLpEET0qrf-0Q9wR42Wx^EI>R+
z1+-sOE+_+)KyVb|1hjXQ5wHZlAR45Cd{7RmKpl|OLEeE5umS-fSr=h}Iv_X(;Q>ux
z1n4_~I|u?%fb7GX>)|+X2N56^B!E<q56VFm5FQI%17)BCjDRyJ1wrEw9*`f8b`A7^
zEpP_`fD7pRK{mJvY5;vh5Y|T?fHFu1`Uc1|a0m3wfb7yHgIrJwYJsRB(gDa`ttD^=
zg`fziPe2%ez9ZNIcR=40qChgp0Y#t!(6<FCBZLK%fgUgiTo4D+K>;WObwGR~@(1)l
z8psCupa{@+i8>%`jPQUaumrv!8kkQ)+@KIt07(;+3s3}_zzBE(E{Fs9pa_(KN>B$l
zlaW854}w56hzF^l3^V{yQ{)BcfH+VNq|BgubLbt2TOb@@4`M+9r~|@N;19?H<*7(F
zNCnxz(h}_hlz}QBJPr8)sUREV1I~0@15$ya73u{D09ha(+yrIT=tpMaJSYHCHi!@C
zgJ@6*>VT~+^b1NsB@mnqKfo7ofsP$?1>!*}2)2iRkOLGQa6Rw@xu6EH9B~~e0Hwgw
z3HktOpayW9k!QehL0*9~NC1VP0f@Syp9N%ZI1S_g!8y1FID-HX4+=p85S@#3c|!M~
z2FQD%EI=u!1QFiw3mSl^56a&U`3DK0)E{LOfII>dAQ*`Mfe9!Ng6<c>KQIC{KxPs0
z49Wm!G13HbB5@9|mf_mvsQVxuB!k?QsP{l{6|RX!J&Zwp1y&#$Bmn0%kRS~RuSHz}
z(I5f%Za|rX0uZqgX#zE%VH3(I9{K~(pb*pn;mt@d@C95DwFUJb)PjbsNP7a(2%<p_
zC<LXT0@Q#8Ae@MF0uE3Fnm`|z16$w@0)X>2#J?R9B!gVALxT70sRv2#0sJ88IhhMd
z&w##=^h`}Q+v!;}7LuNO={+Dl<933i=YMZV@<-zqdN)8e-|3wMy)&fn)<V+z2wH1E
z=k+1!nYzujX`oF5Z5n9PK$`~IG|;AjHVw3CpiKk+^BNFDl>dzVe+NHUbpPWH04_lu
z0spo3|A(_gB`)GQCwCC7VF+-CxpHSRT@Le$lyAnozoP>znY#vh<1w1mfn_3bKoZ}W
z_%<qy+VRS{JA?>8P^@A75S}EPC4f&sc4TSX)xkf&&c)lwhc*oG4)pZ&4e+xI_+f%q
zXTFaI?H%Cc?Be7p&-_qO{Jy7vr;oRrBJbc3T@Le)Jm0UvkiYbewEU_~T}7n1xlP?0
ze7nu5Yy<)~8b|?6FcN;to9EBJ<$eg1$e-_l;H;_a;^N{o!qwGPO+~}e)kVWeMMXnZ
z4I3D!sw=yw{n!Ixgp0bPvX+y&rZToOP*u}V*3eW@R#$P>a2?^O?4<70d=CVi)^t%D
zIZ{JIL(56a*%8-_R2zXU5j54EHC)s+e(ZrDkM#f1{n!IRtUFU~-}gXJhG(T_x*<D?
zqyrV^*bf`~dN`)W9Q(bEeY{d*X)wos*w`n#k4^hc$hC(DIBC!UbfX_|_KlsX{@C*k
zC;ta1`0wv;;LpqB_x%k#zW?U!Z_uRs=KC8o>Av~?271sJ>AvOu22HwezP|zK-j!ds
zxukHoS)d270;3R)GOrFa-zMM>8yK`+J9U}1M`8Za{eJ%f`fh3_!0eacfmd{l?NxV3
ztrqpk6mMo|zq+3#tflSYR@)iEr|@ikF}zk=7{Vjndh`25IUyW?8wIFe906t_uJk6|
ze(x92=b>M;^YvkDJ@dN4U+mv>|EhmuF*du!&|aw?(LRP|0=~aXBduj2rw1sFlvYY3
ztH;m#?*GX&&gSbeSQzPn8vw*WUto_knm13Q8?1Hv`uRB7IXF9GOBMe=DDnHf1Ueo9
zt^K;*9^xIJnSdAK=Jk8D*CXtl<F}TCJ1-5aW4(E0-?UeS5h;_2gST%%AN+5LG;?|W
zoAzL6wMzZix1d$8Oj~0j{llLhcJ)b>=151=eXeP*it)@b9exAUW$H*%UfetK0vr#4
z+di!=W4Xb9`tS47YIpD>FRgn0<-9mF%L~~XMipl{@$$mI+1PoZX))zZHjSll-i3GG
z51aS+dGk*X$2ktp`J)rWejC&>17RfEBf!JK(_@hXZRum@=Q1zQ!_Nh~cKp7qY0pw}
zR4++YRMrNFL%b)`hMLN{)$Ztrep>bV%laA9Oh12B)*<}1M)L>AQ64BS=$4s1LiKog
z;oXX%nR$UOcJ8<%c)HjH=<trZL(zfs+t0xxz#l`Ozv1~W^OJ!z(3pejZkJ~Hq4r4S
z&1;|TOq~tq=Y#f$B}e5=O_9bF(zw?5AIL|@-^mE#`PK1e^Ssb~qiKH&^Ueqaj>bcj
zb{bckA?>lhuTQOZ2tNkb@<R~BU#3e1=Sj!PkfzOa+&o>hcP=>z49X~7qL6doH~shN
zYPE6yEL}!S$Swcy#-v@b50s-+)0k96jeJpB%^^LSrL`}fV<`QXnCBQL{=<upm#?Qw
z06y<A{k0k|92PzAP~PV7$3aqE-~nzZpdpbQ{ea{0$DmD(_-|$I$8gXy;1~A0qI@QQ
zAOESSQ~Y#n#gAjEykkG|-ZU<3E$_|CF`b{+=JiV#dKB;Vcl)b<Y+skr&B~0@)wI_E
z?PX1lKO|+*W5HbbRpzCOKjibr<_b=Dl%yw9-i8j;-k1yj@Q1fI2gNat-!IVIByzZg
zGj*7nnkVAWYl`Fhn2h(V+BDvwYbYM-PyXn5@lgND!AUmSg_(ezovV+Z7q;zS>X~j+
zJ;PXn9EC&gDlj#b<%Rg|dGR|0F!^!`a&qxy?m4a=p4k0^7dO2A%rRp;y7y84Nb|c9
z_m2Q*V2R_TgPD9C(0%~qv;ehZs%X?Va+~Ym7yEc8Pal5@{~zu1n#x6o3IvYQLTOS0
z9g(J@=4tx<9Y$N5A34RX3IBg|KgvZ9C(}^&W&*ss7Wt*|+e2RXtW5s+O_g6xw)}_C
zc=)4svL5&#JsfGKjX3#ud0|9Ag~iLe70&<B@t$#L++mNCG(VU2`(uV3{Bogl?l>oa
zu+5tGpku})6t9GYFV20#z~cLLG@8LN1)SqRDg#{iSHl%7!4;MWLio)R-SSbX)ou;Z
zFm-4gUq9lKbOd<<RPVIGBE(V7(+^XNeei<E#m~#b8?~Aln`2lGZ+}r&c+V@8Z^{>M
z?}^{*i^{B)7Y8dE`lR0iy_qs$t>^!i<p0jZZ>smx`Sm`DpJuv^QQtysUlwUr=K22{
zcX@4XJZ>=gKoCE1yn5F(X6cVOn#S9d9!Gw9bm+zoM?)@34~@45!ms&1mY$|3A3NH}
zskJ__DQzvsAg27ZrSsFqfAs}DBArN^ee<-nY>)H|=HWdbBW7ni{0&4!Z7m(7j}iPj
zWlk?3;PwFO8+U+V7=Zfn;`H#h^K$TZaKrmU2VZIzf8OqY)FTf3r7-Qz*~j0`9d9<N
zH|4!wkcT|Lob$zCmUoKk(|lfhtSWx}G32MOlApe*xQ^0i3MhSgGEDvRclQbO<n8hJ
z=k@;Q{S+^~)Ta9*%$-b{kVotj#C!6X@8aj->fz#t7pM-7o-WS3dacb*R}S4o;7$Wv
z$~q3HEvEC*72vnf&IxUiX_NGbOwEvV_bYwY&)Q(qeQpR-uf6;cxC`}3bPpn(E@qDZ
zAxfsLzT~BewFG`h*H$n(g4-o?4b_FFy<ilja1f53si=SH1@<9xNsNDCY{o-9FRu<z
zoIi1TDmd8Gm;9{nrTC`s>w7LgKDrH2TO>Vh#h)Tx`uJmy?+=7{%K6jR<cw}{`On<<
zG*O<|80eS@G=C?~E7v9+&^%{yxHU2LjjErBIOa?7)5II$wyuNbdUfZAN!g`3Ot(1-
zlhc<e2RkR;Ese>;U+J}Zn5FzMTb7j`6Q(f#F4=lITPv%kv4S4mkm0C{qC6n^ECKxS
z<>vt%h12&INDuC~@ijdIP`z(0UrlwQh#wEV@1QZsXb_5e8_SQ!&&AEdA9uKxb-~4s
zKa9f{6i@nag6saOucCTNZAuT4_m0kPeAAVrXN9Kw1yuw%5>$VvK2V#e;pv$vxz_U6
znvPYQ`hR|0Ez6YCkLrmqUWDL#&@a}N*5Vw5=Qe70IfLl?)1MX{s}_FT<*-J|2KAM_
zRe8Es+4?s<f}Wk|EwOCQw%%8sJrn8S+g(@kvTmHB{AJ!8Qx1FcmVv<;1G@NVID|^P
zQ1;k7d;Q|GJumE7WW({?82-*^%CGOspo_-BVe9$2c3WQ?GcroVdX3B2IYJi`gofVO
zlm24B_$iiJlS8gxY-UUTe7x(IeXOm|RqiKXW9B!hF2FPKN@)7l5%Q^HPOsS#h74OU
z{#+u>CeNGKXOGO&6<%kgtqe>2jP6w>ln#2~|N3;?jx6*M^BI2+c6wcRxHTYj)NtEO
z)um#aySaRp&e~PC(|UKL=h?9jaHHPL_&btx;@Y#rQ@4mDe;7X0svyEp_QW=?n~&e$
zx#fHAO18jG^r3i>$6>RlE&9g3-EV(Ra>4F{a(mx8nDnprjx=`DURE;ROMB^2%stg1
ze{sV)abGWy@_wn&Q2F!ym{K&!UwQpDyYaooISqVp#@Nerz>w8%whDK6JMoR@h69OJ
zFFJ=~jT;&ehdtt};E9p@uIrg(5C3+2*E01Z?Kb-eZ4u~y@Rh~dkF{j4?lhB+#$YFQ
zXxfz<SI)ljx)hcib|ZFD-pYsOq1*d!HuM-AG8=0k8GqgiyKF7R@&hNY?&dnTQ_nh`
zjDY+{B_{PkE-s%3IDCAH^{x68uWX-0zf)<Frk-1dTutq?=J4*%w{!DWo_;rT{j7`q
zhlp0;-R3Ov=hoO~PwoKiIqxmzS*a^I9&OkeWmMaJMyBKIcg5)nLYQ0IZZi4PS$==@
z>#`@kCHCZq=-+zuOzi5a%fh3^*tl2@?i<?aB048M^otyJMUcaMg-I4W-4j-BUbs>^
z#9eKgf4NR%h^2*J`iAo~=XCK{^0(FdROqoxr5CT}>b&p?9`q*8HC#r{;mbVVMQ5MH
zc?uz~zq&8TuiEWDi!^fBhR3ICe0~@3)k{lduHSY;v19GhPl@iI#On36K*U@nZ!y{>
zqrc(92V2-Q8p>&Wl;y}iJ5(02yNk$}<p-WD$v$-X6-V(H`r$DYo?v^8j4k$qOzoa;
z>KB}$b4KoT&;8Z=R$lF2VK!??V~i};KB|$wF98c<MP#DAO-r+`XNeV?9w-T%(0zoE
z!M4PQpJklie8YEEraUY!=q>BqSM|;NX-lvA)&|FKS<xx`(cI^?Jtf!Pv+-3xpCQZW
zPxITV<EMjvOI+xncz8m?w~@iGl84W5Es9*s4NR2@j4#8xDkgn<uM3}!5ZbX(e5~B9
z15cD!b4(|c3><n@;YQ~!{YOTOcEp@zCVe4mwbk^h*Q;5lY`cCw)xTiGm#vYB(*}NC
zVpO{A#?CKJSntZz=T3%)T%uo<7vB0bb+v0+_t0UdowS64uEgz4lhSf=x6DHQqx&m+
z-8-qTT<81WY>ZEJG4Qz%y~*#4(<Teua3|~Bl8w9N8!)~$Ab%T%UFjS3Y4GGf-}mZ-
zF8N!Y=hX4clKeLdgWl)gPpg&slv8hV-0;bQD}Lq+I^7(HzVcW1$FgAbS2R!j#pn1f
z)t{^HEU~jP(|z9M{WYr`>5-FtyGu)D?Qupw#MFa2ar+w~eYV=W7S>FxSL{^Z?rv!5
zWXIDD!ED(?r)Q_mVf@bMC0ZkK*tZpvEq!#a-Dr$+dXyYK>Dz^Zi+!)Isje9wa<D&(
zwU>!^sg#iGf-gJgSH!(Jw`E^mzf)T;$m}ecdvsM<;SKw$mkY2qnW+cg5<Vq9TX@uB
z=*Q*Vt}T|GaW4A#ln}AP?Z@9&8lAj%7G=AR@pp_pK`dV>xo0=8<wfq}hV4Fj<@4TQ
z^R_uIx$xS0Ylt<zcO7B;wTr(|cC~Q-Dxu$0{m#y?*!5)Tq{>>$iMOZurdF?1dc6qm
zz8O6~d=fgi>+u(gDJ%7i)cvQji|5|&U$9U6L0ZcF%d)NpXulE6eZlT#@|fwx2Nqot
z-(dc!OR?PhQ@W$mZn@XIGI_jt!DSl^I#if`BjNOw)g7MCS*UO!!%}7JgXi|g&kvX_
zXCiu`<K>bx)_v5gdrbP?`wn|@cl^-OQ|}GyXG<=xmI{yWW47T&B>P}vmD0&H)carE
zZ)-FLdmOgVc?pesm8TqIEm>Kgi^sdaE;-V>Xxa&lN%;#b8}=1hW4vob{#ITuzqm_#
z^2{d#$INr9A1dY-^J-b0>WXVGZ!OKY>1pGQcXD`+=CFtBe|zZ~dF;MkW8d-h+9GOi
z!zR8twp4L>ZRThN-{-5)kJFka4m&uY>mzfeqp$vaAF>=K-cLpABDmqQiT}La`EQK=
ztS+Rblvj6Bk!W-pzffuWh~I>zy+ieP44&?!KTbGk>c@ZmK4eN0DZjV;)^?xv+_~qg
zfTKcpQ|7*XuD3m8?(%nMgRj0eJUlT0y1T;ovshA^GqUULO<OJ(zRtdOC~K6WP0x<M
zjeamXW?<jN`EGi6b}^>#TDSkMgnJ=}eRzX;rIm=|>L;!y79C9oZ*x>Twb3a}yuN?;
zCFdt?T95J#8OfB#7?<twnePHts!X~)wu9AZ0q6B<<zu(H4j5|YoLOgs?<O(mJUHys
z@=q+8ph?<y8?#It?#{J3@9&!Lzf>{x@T*znRtvIxVW)ygU;I&p^IyiT-6+$m>SNyF
z=VP-*)(dhh-|hB3^|kZsc~v{`ev|PReyT9&)c)?e3S(0gH0?RP)%G2&@Z!viyIiw=
zQ0?L&Sc9^R@mINOa1Y5xS(mxjeFGPL8)q|i@sP;wiGJ@VZJ6|A#bG-P0wtOHeDcu5
zLYt-9gCosN^By>G+wFXE;&H*kx6%(R!t+(OWrSi)J`>*IPI&|7Nr<cz^Ifw3q!(+2
z#InVAM<(=I5c_mM>Bxn?xNr5FMEOmy&$+og;_b_8uZw25<WG}-xbv3u<e&$>2Z|0p
zgDHhexDPV@^Ov9{C0?HgT9_XZ9O)Vq6*~5O(ftGB4FiP?bQixGC&GpO0mk0}w@m3#
zYp<PI)8)_hKXcHac>DUB^cghpMXzMbMc!u4i=tw<lNB33R%=HVsPr1wC*d9JN-*Iq
zFq*b`R7U5x`0FuS5)KZN^!p;eY$W%#WMt*Ni!&AHpntYt>Oto?XV%pLW#av8`!9Wd
zdd%5rqjT=>$O<@qX|&G1&fWL!!WtOHU%1Z~Z`QIS`Q8Q3IKf4Yr9F;W+s(PV%SUB`
z?Ugmv@rW~)NniZak(~OfH4jUL_s6}H$X1)xY3Em2!`%n=YwuSqpT@om`y|Z$GJN>M
z#OHGsYw8rGT@$?4Q=rPIB5}x+<4a`|RXT?aVB?#^VJ1AzwuN6$W{S)U5VJmfZ<yz@
zC&6NgMMJ9-a{BxGoRS-K0QH3l&uD;SnQ%MyylT;Y+dVXs8mjzqr^rvp9NA&qtK(mN
z8d3i|nR0tw^l`JRP|T~e5w|u}8%HZ&bUit|f7IiwU5;r!Wg&&Q4{m1iyLH(0lXCSd
zxd!LGlvNi>ZkSRu;D*`do@<WEJ+?3y8<qrnAdJ7Ib;~XG#K(t9)GuBaIcZMC&WK@4
z?M=_G)?EHbi7k8|`A{EC<<`2r;sxsDuO@X$+G$JinLD@io-4AnU2uL?!G`zRQvEkL
z=zXnTkqkc{n0RLdkL|eNzS;FLMZVL-W`zuUo}zlRe~zu$oBFh*)MFawu||r~pVd0+
z&ZqZ!#rB+gJI5`~WJ7((YPUT-pKiPRC8+SL2JNAJlhI$Qj?(t7FZOoYdpF<t8SBep
z(UHA!J{|2MvV268U+)vwaQ~nOXQWSORGNy1jpWqxa>6fV-oBo4H1g(E!FET#eHnW#
zapTZo=!fjc-~NMF7ax|3SZ2DmdzR?#w;{e?&-#oEkFm^DQAn+MG#qVGm+@yhUS&$V
zUgPFi_HtJZKl@Betn$<S;CHp-bJZ)?WrtnBgX^#ER~9>&;%$Arv4N=vs}FuY*(>s6
zM5VH&)5P)W4b%4B@```9&EIgaPE}f+^vqx1*YWxYiub7OVUts-<97IaEdLOl_}YB_
zGwB*BC*g5B2A@8)R!|7{!C&3i>@|}QNA6UMi5Gg$nV#`Z<n)MsayQje_7vu==qpjA
zFn2V!0?(nf%zZ&r*l<kF%mJx?zAwm0CcGEF)%N^Q^ytx7i?C5Y-!G5WPIB0dzBYz+
zSr;xydV2n*6B@I0?8edM;dj}dOV&<0u;byBSlp+X{I(wNOr}2X^OojxKbt?M#_QX?
zHQjc#-z^-s=2F_auoDC44h$PIemiWuF!3%P+*Mk!tNpPFCih=R+4em%{M4q0I(GZ*
zDwGdwIp`N7@ay}`2~D7Uw64Eicp=MS&tA)wsqUE(xNB44^l!oog_hoIxL<Hf>BY$a
zhr-`RY>C8rKqkD}IM-cLfhES?w(UL$l=fZ}^xpRPgb%l$znZ6zIXz2pHEf16?cDuF
zL=5Yon!M6sm#8jbuJ4bO*<W2W=)Q}b`R=UA`qg;<LTghwY;~WL@ovM0c2X_dSGL8+
z-)q0YzLnpWIb@d4ZeKd({OAv`pTfkuYUH{C$L^m;jBk{foO&~KM{!`)og4bY`?7|v
zS|4#oYYcClGlwmC(<Sv&yZ2fqmeW3kcHK0+VT#S50}0BTOFrElfBB0!#<9P;|K1%v
zO5d#!Uq)N!Rrg;jDk+p}lQcC==efp<m9bBBL~bpx`uL^j*Y_#?)qU&6>r%WC+z82g
z@5AQX^|f2RxFl^syPHx=W47-MXy5nzo}jIfr_etm&m6Ya>e{-&i~8QTs*sr-u2xz0
zBEUfQ#OnCOSkv{Jr3aeKL%*v<{`~HUn?yty3i?ld;j(+|WA0D`@rx-FBVXLzq%2r#
zuapLxEKGk;`gt4c{9UD;8tzvwIY*_u6FL&!UGeBF<uunp0=@dkKgYK!W<2z=&ywoN
zvX>)PtB5C`w^Mz*Hm1O3!us(m=2UGtI<?vYeWX9rPgdVL?*AoYY)x_5pY6M*%8Yj}
zh;<7It&0r*Jlwo7Al7V#zxgoP?Lh-fQ?*YHiuzP}kj1*r)E8&j$NkH1zIa@`>cCoI
zrP8zejvPC8NQwP+`1s?QJzOS~V(m8*-nXsQtDha)7xwD&mcIMN)}K<IFHpH;6gOpz
zT)b(*1{nv;*<|{Sg0d}gn{p0zjE#6L!FfO3es|!-4GT9Z%a{p-=9|Q>v4mYBCf?GB
ze&xmOJ4>J5VAM}-+QE*#D?3;ox$)7sc%Prd*hR*lF`tI1r!Ph%&ua*&Ydm|cY~6su
z>X})eXEt^-^vFD9{AKpDa4&jxv#0Xdek5nx{Q*<Dt8GyVHb1<{=i|-sJ6Bh?U)WV&
z;p4ld`JJ#%mdS_Hg#oF9-?ckqA+Tk~r(^mDZZ5s*`bI9O-OEw4a^@_0g!f^l%yYo2
z7cV8AShuT|{uGgFtuk=8k(j5pa`l((!zPLhk;sTzfZG-mUYKy>7?I8P0%jwM58oR%
zb7}a?Qmu#T3to447bd@@Lu3KgQZwo6xoPYjOKtJz(?ry+TFlIo?ALqFFu#!_7UuMH
z3aLN2;})JTyHP&IUyM=8%U->0ncUkV?NGfzb>~H|^_YIAFfyoP{g^pYXm7U6xVZKG
zID0YS+2vm7)7Z)R&8af?8xyy_D4AmJv#!%ehmY5K-%Ckbrj2pkzj|LsvQ32dDxI#H
zTsXwJRyMk<-Kht6UfMpK{m|Cd_-zWuS3x0g8lGzxFnaki|J{fSZY!_siI_V>chDtU
zn~$f(lfu^33>^4vqJ@ip2F8g@d9=QN*W2zC@7>o$PBn6)i)E|SVtY6gAM82R`oKwn
z?VZEyj<@6O)AyFqi`6JjSz@DdqfW8v=)%38pAT<8pZHDs;KgmnGmj27yl|F<7hM$I
zxsOw7-p^+p*ercBJ2O#M@TiS(Lrqr=!5ZD5?uIorXp@(j@Sdiv+PC`h`Vys%I^L5X
zD}0Xqu+H<UTKulzA%bUT?3wZr_Q5nMyoGaR2XQyW3ayAZ-pg`WSoDjru{R_-No-$#
zHsxH@&{@y$ErjuBTG8Y14O4^b=Sys#Wg4j+ouvMCi`Ir<*E`chK9ywG`{B7;hr%-u
zIx{gzaHME?Pq)JDB@L0+o+>T88Wo%Fd24@6`{Vk;*yo1Y2z%v)JNr&F+Gx+V`moE_
zPw(#0dojsEK{;z@T#in<E}SQb_r*+pwJ+<aY!^5nxjWDFP0WWwq6Y(4o7OgLzdrwV
z&*9Qyzb(O9cc$F>@7Q%Tqto+F6M{E3=${p<7QT5x)o1$noB0}HeY8~#FgBRV<U{K6
z6u}-d)-KH%k<fAVG;7KGwt)+TY}Q-%9CIPZz<L_Oa%1wbWZtoIi%aK+U)z}XV$F-q
zCmYx=4s))osEk@1yhH3A*)=L+;{7a{bXxmxLgv`MI}d!>ySLAP^{2{h3^!}Je&m!!
zhWIAJJ_8f)`|`CBGP;dQQlT%{Ngo{xpIcrIe;%zqB0k;wLg>~c^x<Mmf3-d5c6E&F
zwYS`$cRh~g?+Bc~`)mq3dGV*p?d{z*&E&4cw{Y}r9QGmuvAV!#E06DSj1Ki&w=15T
z(1*3m=M>AWOXSlJL!*K*H-j0MTriEP_h}#cFh?-p)O_1&?Z-==8V~Jvsd$sMfB*Nz
zWCtXIiTCWYwQkS6mn1#E_sMqBhGjvI499NUe|Lx2@-e%2tqJRg^4-n&>vtr1nR9-x
zwST_9n3guB&rzn`l+;v}FpYKjduK~&4`1|b_LozOSC%e2v?OX?!(?;p^UCxa{rYNN
zU$nn^+{yRs)77049%{*sXF2Piy76YhbT19dadmi(V)A?LY{NbwKV6~PcD=+!)<5*p
zS9yPLdX_>-WlnXMmHp}$;`xa2x3uT9756Rj17#mvTX4C5ip+A?ak7sJpV$lg1<u}b
zYzOo_j2YL-WECyyzdB!Mp+=TUhJ#^4m(fFRjw)XFZisdJK92b@GhpA2xvySNed_3S
zLc)FXrqYJnHnYCe=Ddw5PrOr688$!BsMuvE>>%`@{I<T2OmT1W*Qa~q$HG-pR8lqe
zZDODITQN|po2af@`ALVFQ5WBD-ntd@TA22+sZTE<L#-<#x=qRwntw$pEO_dbqFDi}
zrWmf7(M$DYA<E)c_nX<o=w+gaS&>~qM!d$jteZWATvy+2e6^#COw`92U3!V$$=kjG
zb{-giM|CgB%;~Z}Kzi+<5Y5^5$2C?P_wJ?oN@<Falvto}ZV2{xVBR0tP4}%6_SJa%
z=liMs>OMEcOn5^K*IIR56nJR)4KeqxIt7(qy80WGzudcEU8=*t^CzaF|9j1(@8f`w
z-j~BaNUe72e~0zn;hbEb!OGnd*~_nJ*p6~M7J35h$dU9sL2!Ks1M33UgQpX;JFI=R
zVW!QClG7`4($0i()$4|@o&M|lsSRT4se#b$^8DI9y;3`OAHQ^rbYkq_#pmYh_a6N3
z+h<dS$;Yh8&qFh>?-9SgP1n3(=m>-I8Dc90<?piE<u)2=+|WWhx`(kghdt`U70adL
zC#*a*>c!w$<&`E!A3GQ%D^H8lu~K=Gxo^%g%=6MCf6;l8Rhw;IubgGp#ng3(>atyt
zuD*5KBcl?O!Zz2juO+}HCKK<S&%M>HPnP)mB~+U~dwya`r^VHuy`P1I$9kM|>D=x$
zo*NG`^;xBC-nW#*K;2-C{Yrbz&e`M`YH=xK;)CK#tWM@9_GF;HzpFv<mb1>js2;Mu
z*V}&X1{WNz)tiM$-mAQobXrkiyQjm;@kN+_KA!x&kx$+0Qak%gPxT=WvUe>VRemzM
zSL&k7Y2hg<x?vgX;qRb0`FmE^?!A0+#i4tLh2ti_)S0CHtZ2&XeksG&*xwTxaQ;mx
zY?3nJ_3zr}*d@&l9~YO56JzaJFYlx@O6;qK*P2cWgXJRcuS~)FE2h6npCb4vY;vE)
z!6`$s`ixyyRIxzzonvlBiEMq`nT_U$oG_P*8As&k57K$3H>76fnDX8S9Q-Rqg%)jy
z*u447*!5yN$Mo^V`v^BCJl_KngIJ?119Y;B6P2IG94%{@^yth0wxq_04A<u;`mM)(
zmGQT`v)IS$FTI?M$5wCI6p$b}&!x`A^U<4GA4i=vS$UskaPDQs<B^5k-uTLI>~yC-
zcy0Zvjo~(iwb?nEbKWQ^%-LFaT5l=l^Dy`Q@jI_SE8F>C@|=kcdxD-{tdSoxPw2R=
z)@#+(H(33Ol)Rv4=K15|ob26B(yF@Y8Hv@C?iHW^JS#(ISnU?swF_JuOKrxW4_e05
z1FZw<Wnq(J`wR)`rhI(ljGUZauh<j2&Dffw_H?FV#S=rkr(wdI<xq6g-?V0_qH+f#
zR%KD|F<oyY$`xds63VQ4dQ4%xGUjpVQ@Kq^yf!a?<DJFglOmUUx|H62-e=L9VcRA-
z=Ltxz{W{$T`R&i#e<ys{q|jC3>FzYuj5P<P!zZUNFI#fnv3SbM!u?x^gdVJcEmS6b
zvd>b*UY_4Q>0{)>8NGVVJ~dU{c&*t!k+;jPWOLp*M`Xd?D%0Q35r0`@ZnMHm!z<p)
zO=kVp&~$rF*9s>Uv(IOWq!gC*gMCpZyc457$Zj;axn{#s3)^GSMTggTTwX2Zu-g2f
zesYkK!|Uz1uc}c#9%R)eXQgCzHhX8SHTL7Wh4!BFkKVO<ZK7Otu`H<%?Tz!R`ysMX
zw>a!I51eA=jGVZ-_a1Y@XP;Nxx*KO2&^>m=`aT-g(>K`}e8G5)@z<lVU+9-}r_@Z%
zlSK1NTpYJ}PiEOq%xiaQ)lHoay<$)vtC@N=tNdQ<Wv=az>_H=n@;WPoh$n^?rwp<V
zyK?k^ME13pgYaIIsaG-cyV=zW=v}yNEK=<Mc(Bjg<8y``7aBG5u+Koz32OD5@qEra
zHwJyRnU|bYm>?rDd+z)2quPBlcN>kA+A(4CSugEFO7A;kepWBa$FahI_Nz2kt(FkV
zj5T~{_B4Fo;RQ8=8dp|$Z`wUCa>qW*w`B5hZvT}=w^0R$9tru>^wl$D4_j9de)wp>
z?aiHbOTAKFaunkd#-HHx`$=zaZ0z%4@eZjMuWDqre~?V}mhC?4Rf?jVam5p~-@8ou
zTHgmRmkG~df%gZ^OeLYq%1$Rn-WoQ4@V<_9JqBHSeox%(L+LF0zPQgY{`3pHw>+G8
zFrrZ_|Ea@qyX6x;*Pk>>H8`{;YuJqFPeC(rpK+%AYF_M<eExFIlt*KdVk)i1&$2nP
zzvA_J;oZV@A0#fz(4N5RjK8}!(ZdGXtN*tC#Jh(+s;_mE24BpbH+-Jkz6svFi$clH
zAnp0~EBo~Q>VEOYOn5JBZ6C?$`98RIqF`O;n}r+CjTY<w^-F=AVeZI@<}V|b<9#vm
zjPKnhMh4@imrFaZUhuT!<AO`OPqC)vE$VU7uS7OttFgZi#%s)YNcdF35ZjmE?p>Ce
z)^%s5RF?1H^!_ul)`^c(ep}H0%g#|O)^Gy~FRkv}H17cImlNMiuRb)+>Tvk=RMnE>
zBb41Ttar`GDBi+i*)#8v)&xAUTwx!#E6UU(@T*+rL`_2rJ(t=ggIpg?z52=^`xVwL
zjG^#eP8oaI%`vj^Z1Mhib+69E9ePw4xXSG2dHIJPHsMy*s4pz^Ssb>qrC8>yeG4z{
zz7pR)PWh3M*s>!NkHxo}ARm*ulPmq85Be)6yonj|@mWK!PkmPRCGh!u=~-jGEZVMR
zYW_&gqC9-E@v3oH>%iPE=bV`T>SWbl?I->gdB(Wz<<)*4GAgd^4gRzJDJ_}s5<b6t
zeCdd7utwkI-)6=?bv*j*zJ-jM$o_=dxsK`gt|8tK#^2_zVfBV%%|CiLojZAG--h~8
zOM_))#*KXbbaU!#)~oF(i#n!XtJJ^f=Q+;b>$AQ=rjtdPz>}?o)k|i);;dQlNjmv#
z##+n+VA^@>?}2wQ;XRw{|2FOLzD#S!zME2I!jC<g_i@I-{OALRv>MB|`p4q__8zK6
zciyy)otbY&w)5FICI`rMZ^zp=uLmT$bXHGDx=s)9*M~Fn#^}2CIEF_R#@%D__9?s%
zIRHl<LJo&~0*S{cRs|%5BM<oNpqY8-6iz!FlL6!&!Jh~uUDuRe{@Pt;O>Z4MH&5?X
zHkKg5|20S}NbKGA{W|`-RAvom%Y1&u{&^Hn9VFDpYJ_ZxkH1!wrAOym=%*cDKWxZR
zI4{E259yV^ev?_(+48yp@Fxa8u*=Iuvt<qBU&q1!{56!AQ-}DFKLJP#Sr}K$&kqN`
z`0Eo{<MBTi_o?Ro@PkP|`QxwC`)PRBo9TzY298-9*HW*O1zFsV2n+UrnSCEkA)EBW
zUvtK+`Dl3^_Q+%OY6Xd54a=H;9i@xE-iuf6f0EB^_~Wm?V%B9*K1mmN4a&I7{Q6M{
zNyo22;`YVte>oWP7JgHmd;mEGlIqh6$S06^RAN1a+yqJWF&XkXWIALe<YCCykd%fG
zkZ3ZjkC3I1b&xp6`T|)G`4y51pb?VRjWyRle~lHh_Nrw$y@Y?#BM0!;C;e0(&C7|u
zUWnBJ*Z6k*ef`fzx#KXa0Fv6{<!1GmzXpg|8`QEs_D21q`Y!{CApolnzdq{WfBxDX
zrhF;=&D;4#q+bwzphKoUZ-(rS-+26B>PaFb<qx;dru8?>x*Vz}lzt2m8MlyMPZmK+
z;mBf0X~-pzRE{B#RF0vL6dtuN{@NL)&uLlj<l&F<GXzozQh|S+JO1adabfIbQ+}vk
z+X8YYkW7j<4{{jfIY{acE<#fKz69wDi8WB%g^*n#!y$V>u7H$+Tn{M?*_3bonh|C#
z3B}hu-;oGU82*<*QvHpBr2MXeq&%*H)P{_OY|6JXfBru8A1(78fP7N<1VU0dVsFat
z*O~LL>-3ZBqWRawK$1RIH@l9%CW7f_TgEpG{@|T891=y!QsQ5ig#Uf{@$JF?ly5xV
zvf=<a+{(CAZ!{t4xE5qDNaU5vfkeGv%55|xhUug`GAT=Ivzh&7(dThz;kN;#7o;KN
zJV^NAhC)t;TncFcxfOB><aS6)$Q_W=AW5HAfWN+hH5LC;I;lJ;E^-(yaVecBbEba#
zL3YLOAV{Q%g*rfHc3F!d>6#EoQ%IzN3Ev+7^Vcab>lY||s+ULy;}AcSe{0AAI5HCw
zd1Lk?HG@PRnf%R$48(6c$S_C;$b*oMkdzOqE4;M>G#48O5f2+u4v-s;`bhawf+Rh|
zHvISN_-g=|exc=cI}sGsr(KX#PRY&U<ImG)=4-dSZZyItz3D>I{di2X`1o`2zxOB2
z)2Ye7P7AUduG4OI9dEw<&+|w75L5mXASr)Cn_b7BH_wc3TBfrP{82jlLW)E7<6ozT
z|M~Oasm?L_Bt57Da(i)z%5gvBV8{cIije7$sI$zzsZHg=o4?MR*WNOIY%$2Bdmtp~
zX%IhtDo@^A^q=QfjengwB;{8FQXC3M-^*r|f~tLNmiT@)O9%LZWKaZZfJ_>jWd!UG
z;N}mKKq06FatGNga}We#53yNUpaO`dvsubOGlR|Y1aTk-Q~=S#Y?fpuo0V_}?_iGN
z_%Svs9sd_)vssnLaqa}dJ&ACEdk&kG1`19gKEOH6W|;unGi;V{F5&~_Kr|0=fdYh6
z1*A%GPsZ;GSG=c1rPsu7sk3ZW(_X5Q#_eFMx*ba&$BGu9Uxbvz2EOVbA5;LreCPqX
zDg?O#_|AdfG7C|rzy!F1V2}WEz)jEqBp2~)6PrN#f>@9S3PBYRM&nn%0Nn!4MdTBR
z7qD6SAQ;GBVzbId!Y^n5w3ss=$K)Zc0NGZL0`VXf<ba!?3J7bVe*(53090N^Yq`Q^
zNdaY`XpFrqai|FA>VT9s`cB{sq5;`uuK@H-k!-O$gD8*=N`W9cT18+9f<Y3<2US26
z6<G(kga51hwb~Y=>?Wez0LK_*0qg;7I-LY^K{==cQj>5VID;sV401sgAUo;mzzPKa
zKlZ){KCUT!f1*K9l~fTG45HEsCX>lzQc+PsO105%QM*}_`P+m^GLorA6`?^;HcNlh
zDzelnim*jh5no*!RK;$0zuna(yRx=cb;B05ir@3zbMNHN+&gp6+}vcQyEC89lbgA7
z|D5wY?|ILA&bjv-U?tECYzMMYSy_N;AOO&O=&ONVpdZLYg;D@i0d)XXFw22%pcm)|
zb_02+Fl@j~AOLg%Yk<wbb|9-7*8!>kFVF$326}-3U^mc#a<TCbV@&hrA)P=M&;#@X
zBe`B{*Bsm*SX_hh2do7)1A{>JPhg|KTp$E=0^L9#uoIYo%FzZ`-bcEDHee;t3(Up-
z0MHJs0M-JVf$cyhD$@;H;RCR>098N@5CWD0D}nXEW?(yzSqmEg%7M8+5a<9_0Be9g
zU^|e7%DLTyG-F!<%munXfbYY$16U1g1a<-w;LB`4e+Kfo7v|drLO{=lV@#{C-45iV
zeAfcyS3@^oDX?k+?zb5GuR%J1o!25S*TFBMGTYD(pNHRVZMZJBEB^{#dKdV`|K0d~
zH}<c(9`=GjeGuPijf_lGZdHJ^uI%mt<Qv~7d<@@-?M{H!mYs=nGWS9Lunl0ldkHkd
z)`1N7{~bOMSc>naZDUM5TaZS8)+!sozMVin_E+K9EuX+QBSzVV?aZGdk2m64ha-L1
zSB?MIV_S>uMr_yT;x}ybP`^oQ&My6IjIi!3tvB1g1NXvq0LZ)v_rW&wPuyoe=!NeV
zfYzLquQzM?9E9!<&Vfq&zh(-K!T(<TpASw};(uxF*$w!=75g`1n|m{^2Xx?j?ibhx
zwC;qxeTh2sE1diF7}M^5k1^GLi+XN1>VfZIgWsc01p0r#@1{&sO-81vi?CNF*51K7
zw7`VSOj89=1Jvz}wQPZn`(&CjvDkb*P@a`(ss+6J;XGi){#fG{=mq)@z<Rc0Gffs?
zCg43V)6@xU0Mef{18D}*45S%IGmvH=%|M!gGy`b{(hQ^-*fSYGcYx`KAH=k0<6RK+
z8{CbKd78`TO|;36!M>9Kn*Z_IquG2eo3NkeU7`2kGJtpRoz`QgxmDi9|1@{dMr?b5
zK7i)Sc^liefGM~JtwCLlW2DciXphsJf-m8B>0T$|JIyao^Wr~_{d9l2XAQoyIib-f
zex!13XcK<V0Hlu_|9^iJn-h-qdGWmwpt<Q@#dWRN)&Vpx=4F5jpgFXIz!g9<K=b3$
z9Jn;stsh&O%eMuf`NKoN0^mwuA<zm)pL>zV-{gTupbvc|YHL-~d|1CmI?hAh4hN0|
zjt24p=|l5zordorpcZh8zg>y#&jBAWU);9>+XsPPh~HbWy-NI_=I(kN|Nja2tGJKu
zLG%3G0xSjofn#VMFPg{dD&&Rc#iF@6_QRHrd-e!)bKrlP+iWawARv9l;eVPREgQ%I
z#sdcf6M#d2Ljjt5_AqR7fx`isNAU<C4>%Gy3Xtw|H2yaO#{e|%+;KoYKy$uL0=jXn
z6R<4+Xl^a~&_0^Sj^@;&V;2K7ch;|v2l;x_mt)^L>~mmCdQSyT1y*C91>17qG+-J)
za{|-c{T09&z;xhDpc0^Yi_Zqm0jhu*z`4MAz)XNXHf+xaW&yJSnopYM_rCy`1N;v_
zb6sBuTm)PU%mXd~egym&pwDYa8_nT&CqQ%eQ9d_d-*dq0!1DmjQF1AcC!RCMqwf%K
z;yca%{S1Cv4E?SF=(nZ7^Z1|U;(ivttpQHPaa2CDu%*u_*izof)+x<)fYx$&0>{1q
z(A;Y;WBVeo7NBza0=BOJWGggJq`cfdjr}y|=5Z*y4Y<yFd|!w1`4S*~GEgSQ0MchH
z{y#|eoyygE9RITH9Ids+x8a;m0qOG!&V5xpKYHzP@>evs>QtZtI0ukE(d&}`FRt-x
zSvuav|L=(3H(~pp`2S{X{~-SVKDHl-|I61Tr+a*a{eKgGi?`1C-*L<*;&F7|r}%%n
z_<aYqgR<Wa!N8|{P4v(4+ZW>R^7YY=MLr({&ku`SkHhzaWO<jbnNIhVubciAuD45e
z&*842z8ly2PIkTPkO!JKgg)`sPQMMuEESLI#P(kC{|B-Ch4}w3v3*SZpRU)9|9>U>
zz8CCr3?O~h;kQ@B-+zs5ulWDl*uEqF{~orR#s71_*})=jf5g7`#r>JM=HB9U|B8Ko
z6Zh|nW3$BL_rdS`ipLy)eFuvB&%pLI*zYWC>3{N(<gaNv3uTDPGL>txTPlOppD)K_
z`2INX1h5*Q^=Rlb79hFj0Rdn!&;cw1RsvgrZNMO4LTpd~V2s#Q3Csh$Kr65mSP85F
z@T`z&D?sbRJAh802j~N~0yGAJrC@|{2n&rv09Ak&SOu&BdH@=S#BhoUUD&2<AP>NE
zIKr3&ts%c2$iz5;4X6aFffYbMFbM1hvN1+r1{^>yuo>tFb^}=$1DF7qfpTCT;01!f
zVxSXP4bYkon}L2{JCKF(02&{t#&|#nupC$ktN}Iv+kss`Ci?ejJirW80rP+mK;r;3
z20;D)wB~#}&<*qe8-eTtQ6B)bj(iOe0M-MU2O+P(Vqht-0@x1S%V9?|0a^=wE3h5d
z1r$Q#N}v_!26}*vz!qQt7zF4chOs~{Pyo<)%rc-0pt_J^xB(y^u}=W#0=j{M!;luB
z0+<QR13~~jq_q@S1*`#jfUUqTK$wRFv0gbak77Qc6=(;#02-I+1qJ{U#%{&}1%R|}
zeE|Pw!p5l%TM8@(Rsm~(9$+&t0MN5&%TT{;1hxX(fo%AaJfHw@0961z-%Mqa;uVTN
zC>EePo$BWrpcPmKbOEb@USI$i1a<>iX7B<m2Q0^c3t$T{01N_Sj|HzlK41Z60(C$;
z&;_gp)&d)Veqio#NGq@#$j=AAKqW92@B;0?a$pV63v2-ffI(n4kaaxn2NVD^ff}F=
z2mx(CC(s3~0eXSFNw7^I1hfO4zzSd$um<P_27ui_!3jtYPzBTitw1}l0_X<T0~>)Y
zzyPol$Sc5kfDNbw>VU<?I2PCr>;`N$<PBH`(A*vaKyC?+2j&8`K)?=;fI)yB^s2)1
z2O)sgiC+uQ8u9czLIqF_ECc!gdKQ7!fe!$yf%U*nfSxa339JD&0DZt#V8S$<53~cz
z0L$sfC$I`w3v4_S99JUEKqcTf3%&wq1GWQ}vyld%?HpVe*bL0A!nJ^vz}y+o51_Tt
zHxtf<jbJQ451?`UPGCK-5opIa{d!;{ux1wWG8@+iDuCQ-_#I$5P<R3O18B|iF2Hsn
zbO)9KD}VvOb`jDGYzJ~Lh9-ams0I3fe)@kN@(Iv-<O4v^gERwuKtGV@gML6OQ0d3L
zfnHz>u(KZ5ybRX_vIEcum<KEcdVoG)c_X$!KTsY7CqNI-2ZXKw|3FqV(g$o`fHYr;
z`v8l9^}se@7f`SeX$68nYb(+WtOexjf3Lm@wgrq`gyXM9x`AcDN}zTzxB}J#8-dJg
z!5`2CbOY_zfp1^~U~9u~KnUmsb^%$}gI8c9uocL<5qtvypd08127#KJaU8IkwjIbP
z&=0J*1=j(xZpD3`G~uN+a0cW)jr#!YKqs&QSOu&BdVr0<7GMAv1a<>i-LP4}3={$m
zpc1e>1OM?Xwm=Bz1a@Szw$^vpQd{FyY^l9-L=KC?55aeed-ub4itmrY{{d`2!<O1x
zUtvpa2#Ql^PFIQxslESCY^iPbF}BoJY!|l_|IqKBVoPnsL$RgnPX?&{z8%|KY;$l7
zwI`{)OKttVu%*6-!vH$2hW6*-7<{MgIBcn%J{J2k0D2FO?vo8r+lpfLCTtJHcWS#)
zEJnYt!<O27WAQ(=IiJJ#`PhDsEw$m&pELt$2GR_q8AvmbW+2T#nt?O}X$H~^q!~yv
z@Sn^;CNg)aDFdxy^mR<FX=<rya$i>CYVg`^{$^hd79+dd*WBm})L_Z9mYN0lThr3)
zslj4P!oQ*B`o{S+tqmbMjZP5GtXb%3@dU4Oww#Q;Xp@`Db24ht2ZGgeCYlC<S>f&Z
z^`7RYmL`A5Trg*{c{Y~tYp7p@E1J*53N-ZrEIl>el%L~tUWsLjL%5fFLCDu)Iu!fr
ze1RZVl9BDD_h9pLT%iE&LFdpKZ!IBON{y|8)!=Ikv13|7UOcLwpL212qqk{ci)kGG
zKf7r`qgPlwiXC&t^cfn*%*>%N6ltBpWn+jzjH`jrL$Un_w#%lVZ{~*mOc{8DfUSQQ
z5_u_K=&5sI9UQja_bTB`#UEjvLRt%^8$b0ONoyZ@eJvqc9uAB2U>~g?wH8|%51pOS
zQoqQD)x?}w?vb+ELg~oK>A~;KM+m<+Eok=m@KxCF!1g#`c82RpSABq1$r7$thkaM<
z6Ll{qTRV!bSBu|i+zIy+u17x|Y8sPMflShSCePz{JIk|hA9RzNKs%1d5>&xvTIS3|
zYxGFxbmN>$@O$ABfhQpiL40RvYjCwX-3$DFDD8njxRCtZ0i62;j=fPlm(n*A-{alS
z44p2=F<-V1-LDPbdG0qC=b|eO?~$-`>3(zZJ>LB~an3V1=Hi=%?$@btKlxfw<y1iN
zDFhA%P5_p}uBtKc1j?m?2HxVY(<H4a6w8jt9^%<i1%8jVBTDB^?6<(ac;_19T|>op
zCdv-SoL|SDLC0yYWpaaXJ?%Nac;_(Yor`bXG)kZL+9SMc2l1{w(k0|qd(EQ91pc(w
z6gdF}nP*L)WUckHzmPudImC=!(}8!+$P?f*ja<`)cdZ)UwPkqMs^Oi3jdu+s-Zfr$
z*FfT3Lxp$EBHlG)KEfEJdCUo&vpV;4gjS4S`QG2pc>4F=!*9L#p>y(I`}6Mtzq1^h
z|KTJ&FLf#%_wCfD{%Jk$C#FsNU-p;7_S*XTYajUjy?^#wkFP1d{GQ)Ex$`dmxw3Ba
z()IqlyZXf2R-NwuVBd8={nwc5uGshEGrA`~Q~1&=S3P;|Y43h>7XMuSzbU8dSucL_
z)-TKF?f1(0KRN8PgTA|M##u+6e!^?tg|7SVqy9%%9kK*<#p!gMadVKnO6YppYkTm{
zL2mTgBfM*h@U8*EyS4}KS|JS>OE-_vUIXMn1T5w;FP1%f;wODC-23x?E_(2z-+Vpo
zHQQT<-1XkOfAT+Cv*qa{AAJG!`5Zd#s_cy4v<2UM<E|ys|MZ!&^Q0dte{;+WFWTQ<
zv?*}&M`acJ<5@n~mU+zXC68V6=U+Vb(UL{`uRHkY;}>Kv+WuMLpZ_|3^^3c{dE}8Y
zjJxu##YWE*n>p6l;9bLlcTUDmjI*0L*3K|`%?aMMM|ju7NY>g9|AzpPXUzoOIpKNN
zJURMoy6^K(jrU&sVbu@CORv1y^||%$&AUqO{`=t>-J7QbUYu~>g=iG;uKmEfMv2jD
zQ}C|+z`Ldh@0t^}WyIf(rsCYU|8RfzLkE2OS?%Dy2R7dK%vs~kdgU)yt$Vcd<0DJ1
zz_Y)CzrXFfiLDzg&;PEx<D;)8{&lstZc~44%bXpz?|1nlr9VEu0^{?%Ybo;1RmnRS
zF7KR?ymQR+u2sl8Cp_<5xGjSJ(_T9xThK#$?MU7=HjJK|{W2ka+G|Jhu7$w6w#S>o
zeL3a?ts=YEUNeDruJ?Zl_tl;|ly~ide8Hb;&oTPJIg}6WwMXU(*VCS3l%AtAkI`N$
z<XYi++H;Zeu2C{+I^B2l=ThgLgM77+U+p>4dDk3!N+{>rbCnyt7NyZ^NAj+DV)R-e
zylY4D&hgE=CJ^shl)P(%@vd3PyC#s)YfSR4J#y2zRDQMBqBMF<5#BXtdDp<?om2lS
zA-~40mC3sn5$_rsymR^UuCc+p#$Wv`vV+$yx#UyNl<qICIq~gN>ssC^XnFbf{?7V}
z`|oP}=B};Jyq3kkMg;F%`Mhge-XZkU7&iw#@0t$0YwjG27#i)+V?&c3+WX57t(R^;
zwxzP`u42nY55Bsnw&l4;KQni~a3P-kHF}P3-Zh_i*Gl4D+lY6Lbl$Z%c-JK0ozt9m
zO;X-94tUqv<6XOecWr=V&H2we_x__8fHIHi|K<VbnTJpJ9RKH6&uy4>+~hkxyDw{>
zf6n+U@c*8?fBWALyuoDp9PeqE$JoEiTvz(|yA?Cnp8Ug$58q^aZm)Zr_WgOrF;D&D
zf}ef4GyhvWH;+MBGsoIXylW-#u35yp*6kN2_MV+MJ}itIui6*Sw`2cefIbL`+h{Bq
zLpg05vBeNa8_ns5E{`_Mr)@&$-!=tXyh_qmiY=<7wmY#!cSqYYY~hOAy0ERrwqgvM
zyBO2U(Y(ZM+cNPU0JbzvjaNj%bN7nlio$qf>)w%b{vu=*=Fr7(voJ^Pcx>Bo49{GO
zTJt96IWdk1Q~@<W2v`cN1l9waf$czMEp!FSfw@2s=m6+l!4=r90s4UL0L_~ypEEJu
ze2FyIEX^@1pC48}H>@--EX@VmZo>O8c)!Gmd0wOEan&=2>q?}D>?1vAE8fYe#Je#-
z9{Q!rff`^jumV^QYz3$Q<pWhfFVGL{2C7k@LO>@#?{Dn{CZM0-ziqzO(VnZd9}hB+
zU#kS@84_vk*68_4W6k9%pT{)T9HzE5l<!RFj4jPoO7oOv?hP9N=$+xszyLsVlG1#n
z@_9&U{!wYZQJQO%<{51V@^8d7v8~2-J+`&j()^;k0r}jbo3Wqf6^))#G}c_Ac<@Mg
zZ<yu}%||*{VoUD~Z@US0i7mZ1oO?6;CD8X$rfC<D{-ha5GmvH=%|M!gGy`b{(hQ^-
z;9&sacEtRD_u%_2Xz0^3-uFyl&l+#bWzV0}^TG5CFg-&|$I$<G;TU?({bL+M=g8+-
zqWf#jwZt>GQuI7j^0}7e^DD{cRMMJ5Ol!U{`CM_7kLWqVqUQmV&-oN@-md7mxa9M1
z$>#!-&$T6=XKT3gYRTu(lFvI8I2iLH0@5dh{}+ni<?~R*nqQ0NppwrwMgPZ}a|-4n
z^f8rVi+(6mEf4@&0W`5_eKK0}jn+Rh^#EIeZNN;l6;}W>$J7>JCk)tzzMonk2o$0z
zL~}!R0Ly{E-mHDM8rwXy<7NUiKsV423<5OY(^_Bv*a>u?t+p2E1;*}&egt49ZPD%u
z0&T!rU>lHo0OlA0>VOqMFR%qLAB1y&HlPz&18f6wQAP@Y4Jb>y0Sh|ODu7mC04M<G
z4uIwo%L9iqff}IWFmM2D2WU>DT3{)#0+>4y{{t%k%Tbtn1?T{l12ktL&Ev5cC^RGe
zKpQajMEnL+14|2$W?&nTX~F%0D!^>TwSYQc1<(id1FLM<0)xOzJKCo}AJ7lb`arvZ
zv3QQ47s!XeHb9z#XAAz{2IQh2w;G`5cIu{q4`4H}^>mzDfxH6&U<I%mSPN_b`hcy#
zHekycxW{yCf!s53AAsgdBY%{MExjj^{-ha5GmvH=%|M!gGy`b{(hQ^-NHZ|R0Gdc6
z^!|TCkiGps`tSeKJOK2L|2`)6j{eEQ?0{%bpuI?+2Y_+Fy}%nMW327L{Z06Z-lc8`
zVjsOrP3=>aPel=Sj>CK3W^CDe@GjwdLHN5{c<&uw#rMLSeJu+DA^IMEUm9&z-sd@u
ze%^}rIkYdmX#b5lvh4UnzS*|cd;O=E-_x_}@^@cw?s|2`^5Wtrzx{mvjsBM|$G9ij
zdgd|Rb27iW{`@1aUi|3fHAkLtXWziWV?THIJoCF_zghO`-PKQf@N7yk9e2aYAKd@(
zWmh}O`&Mtt+;mvR_NsyVC(n6t$+7nr9eDk5W6(b4eUFXzc{Semzj)un;(afP_dO!s
z_j$g6{mcVITNP}$3*XU25nfyTC^YTKuF=$QLwAhn7;MqhrnwE;&c!w#Te`;a*!~FH
z6R@Q+0NZUtb6FT4r}Z#t+<EDn<QdYRGy`b{(hQ^-NHdUTAk9FUfiweY2L6*6KvOhg
z{GZwn()j=UiL8Bm4#xWv9owb$umhM0P@4nINfWiL7X#D|ufdH2z-piupz%6ti>E(n
z2GR_q8AvmbW+2T#nt?O}X$H~^q!~yvkY*swfbk5_D4$#R{QnL0Egt3U|1G|d)7RYG
z)a-0%^7{Vs*8s4K&leP;AA>&M05mSU6Zkg<WrMB4T<y+CUf6R6RX9fFBRpq7^ZQrh
z$J6ng`0R{E-$EIybPmm-PwO!61kgoex`*9Im_wh&ec5?U0dLfK(j5A9ZUNH#Fphmy
zJeTIQr+yoHU?F<Wemd_cte{B0WuHWILpYr-T4rHLY$4D6=r>Bw-@ebxci#EO)EU3J
zZ{wIR=VZO``n3i3T!lF}&Y<TY`mV_S``62VzT@j1|96dZ-t1`~AN0khdFv;Zo*z79
zV(yw>qO&YLe|x~U<qsbpx#+W#9yrhYTE>K*eRok4`UunWw|~FP^Wn-H&imnw-rpSc
z&QEs?o_y_7$Cym%`P+ZJs-@Td?R_`if8p_8UsJW^f!{v#EuK3{_4(U>HjVs2)}Md4
zaeLe6CmvE)`qHM^cQ0%EzU!kYS%3Oq@oSfDdOPdR_e`c&;1kSa>h86EZ@VMYdBZ{P
z9e=^3$KIY;QNGU&|2(>4-Ht<V_<dvldXp(VfBS3K%ssv1lP?!-c=VkEUqA2Ob?^S|
zv!9wwsXl)@?>y?f&&Q?bTYu-r`P={Y{*9+qbo}M*L-U@!u5iPITk(#W@Eqc*@>3oh
z|M$lZc<hfGyni!&d-d4T!`FZH{6YKOZ0~43V%?@mShrf358mDOKNrk+<A}>Hdgk-}
zUa=pYzuETaFE_q+%TYOfQ!YQPZD5Ycl%8)rJ>UA74`O}sv&lcddxmd!&zZMhcyi#R
zC7BOAcfiE9oo`=zb#L(fTPJ^V&-TYY#ruwBbX<DA_1jnO+q(W|7r(W%>)ou^&<IV>
zw|;5v)RPze?b2^wzWUZJH$8n##}&KJN8@kZbh4MDk8-@b=!qTEU;1LqD?1KY@j=<K
zXPUf~FaP$lb1rHqnLB-#$&{XN{p0s1{^ay;7d==utNO#@3;J(3|J>WaU3$LtONx$v
zq-tDXs%6Kw51uq*zsWhzbSyNP((|pK|4I3IQ~%aC=hLGfJ?W>lf7<uBUw^j6WJ=Gs
z{^0L+-?-_cQ?7caqq95k`zLPS`^8FhW~Jv_|LTRxCpRy7$NyP=>t3In`jhpSE&6ag
z=4Qo<73ML^pP%yUZ>Rt4?!3ddfBD+8AD^+N^qWlc+|M6reEGWrKfPl6FYsQAaNG?q
zZ)|<}i9@DMIpfhOj#~2(#g9Kf&|tn|*;|8mP1<?&WVBP#^R0h#+ub+(`0Sl)*E=rz
z?35{&-M8_TiX|pfdcO6g_kUV_<=-X_=6bTG|KfyKUjA9;zKteRdcJkb$G1Pfb@zE6
zzIxo42_^Pt{2#A7`Yy~%WTSHV#;n`FY1;d`57uXfUcRzs$JD=E^U=8{9{uKf_gvC)
z%opzsoMSSj=UcyKb?ssG?`^v#@2+26@Oi`O7i>SIejERLed+nuPbw+?bbG_BHx4e(
zz5ANmmVSRj(aui1?}!Iqu`W+d&4>9F!9Q<W*L&xIn>XJ5`f1~i`R?1^{Ih#XXH<XE
zelwnd#rTkU%-J)m&YFHv|3vQ{3qShZmkZx~<Ym+Uyte4jmzsZfZ2NuZwltv~Aha8^
zUS2V|=93@(^j7YL;~)A}?wa5U-N#(K=FaTtmVfph^DV6{nVxU`{ss5{c=pp{zW&2y
zt+gjTwE9llv*%+V&gk`t>3z&vKpfi>#{8-=#}uZC66UkQ#$?5Nl{5~BE+=8WbV%4n
z?+@dZ**202Xsg7w0^8Zxo`o%4cLugdvM`@}dVY1x4~22F#lQ++J+K+r4NO>sIjw-1
zKoIBzRs$P>?LgMmm@BFj{{y>$Yz%Cs=U2ykYG@a4116k_In96oumb1-wgS6>JQ!v<
zPy;LmRsidPt-x*|55`&!)BuZt6~KC6E0CUF9q&7!@1_G-4fFy7z;2)eWA5qs)xpIQ
z*v&q8N2DF^nq!-)^Q&jC&oo(p^e4?gnt?O}X$H~^q!~yvkY*swK$?Lx1A96Hdm#fq
z{2=Bc+hn>O|E|LG=Jee9>Rk2=`JOVTKdn!Yp4T7Gq(R3lfIg!=uYVryiEcJptJ1Uz
z*ahUH&%*{(!`M23^}t4;V+`hX2L^zhKrfovyMU~{F$W#63Rnw_MgKrKKy&wR1SVjP
z{tBQPpgH>|pp!Kpr~{S*t7wak*p0weU;^f|s{}$oJ3wow?E>--K)QempaT<MtO2$G
zyMVldaD70UzrPT+<pq`lR6hEFnHc}=1iFCogK=$O4X^<iJQVjl41K{sC(2PTuoK8U
z9Qg-!0+|zWJ-oQl0}Rp&94K?EfX%=FunZIVZ2`6cp(*$cSPSet5oyL;{nbF=6x<)^
z20DsxEuas`v_c1<3dqJ-SQRi2SW^N%F;Bk(r~>k)B40oVu%JVFDX;?A3{1dFBo#n4
zKobeB1$u$L)6nla4S5DCPsh1HJFpqZtiXAI87KrCKqXKORGfi(Ove^z16BZg!A{B7
zq(5l}(hQ^-NHdUTAk9FUfiweY2GR_SJOebc`6J!$|6`W@`X=QB08I-*!381V#s8_M
z@|=uXv>8kXn<knDf?471`SqUWrj{mu$XqaIvUzqeRNqj)sJ?N&`OKz<V12;XY#NVw
z{GHA#Jx*6B)Lidg5c0L)o%j5lI$t2@YnJadnP|>`S15pc&^h!{dP~R^@;Mt^jjs8=
z247={9YgB^u<Oz>4el0Pxp6+dOFwiT^5kS$Fkva~{G5yH8@){nTQJXme$LrV3mUzy
zP<>M)yWSboXT&{b=w7%}sHv3{mDVNjXJn%liS^Ua_NC8k08K=C?#HxO0oskGOcR>T
zQg()tHFc`Lsky-wa$e~Q)U(t$-L4j2xu?$6T&Q+DZtin6h`DmQyslu#*DM@9%{<NE
z%atdZ08dk6OUOK_a6w~B{rpCs*X(rGH-_vsv-AUHOZ+k=yp!F<<MPz`yv|_A>#S=M
zt|A;9J`7D%VLb;2w#tvW;u-85k2w!2uw6Wf<~#`1)wh^nM>#oF*tg&~+E?ysp1**M
zsKsfSCj3^7-)v~xNBmaAew&BiUO{_4;x{Y%troup@}hn#X1~?pH=2w;;yl|l6V1DD
znP@AtPCb3P0J4?)fH647lo8Wbf=w;;WU#J)Gw5n|HTWR?@XW>NE2fym(E1-d_VVcQ
zq*ZF#%N)^OwxfTHK5%h@y|}T>guV2|wih@~xVUET@NC40tL&k6@zDvXYZq6Fc2TfD
zSq0JwkRPEsXCK%_^<FXkNQ^pXAvs)UD1mB6JR@GsGn|ViU^U^CNHtB&Do8w1cP+&0
zQ=U+%gEI1?>IBX@=w9Jkvbt-Sb<nk<?F7ccSn%lrq&jF{*iKJu+lgIc3`gmyQ%B~y
zDQQ9cam;cdW{IqqQpJX(n0GnGSm-0Km$G0(onvD9pU4_zcy?plwf1mZIYRI)sckD8
z#Ia0yU9~@KB|9^wt;DFS;<b;^3^cNR6#H_qEGFg|nw8TiwT~`Vv6a(w)=eYTKH52+
z`IRngq`K(<*h*V$TZvtV=rtFkub5&M!yC&yq!I_GioHnfqp`G59zODVXe{iddheLN
zC9>|&Ya>QnWe>HBUX}PHRqR4)A621mhd%N;XB_OJFScF8sB<&|6&0^9o-vH}QQV6r
zU^U^CXjVbukt5zdvZ}O?{-U#wZlu~rOYv+EeYyat4mt?7Q?XA>pAx&q7@qlz%ym=J
zg817<nJWEusbWJ?`)KVEWI>VjQZ{TTd*7Hg6j`GT&u)yn)*fyv9+j9kRcz(Arh|m>
zBMUt{h!3V55d6(Kw1us7M%aq4&N+Vpx^*#H;&BB6<rreY$WIeS(p;gY=7P!P<pEcN
z+v{>#i!AOEhpp7@@wt7DVw=xlvsrvDtKVN{vzB^_rxi*^mK6Kl#a55E)KOGwvAIk9
z-V%$Y)bDc@c`O!>zhoK)b);iUtzK`b)ot~c+Dm;li?z&cclkUeWo0f$vEAn{MQulU
zh#gzjifeE0o%1HkSN_adj_}yckA?9T){dp|oGM&vJUE!0fmyc~1TntH=F*-Z>~ne8
z2p*05<>bu6v4;x#JprGq5l6HAW^6HRh-*Zy;r)Tg`v&p3#fdm(9{`Vi3ZLw~#?iQ4
ztvC*r`oy0wb!u%9{`l(~^DRsRvzV92P4*3VoD}1rd*>X-@(2y=!uP|&-%BDinI(>o
z$TgXzqRFfbbxmevsB1DSN)xFpl#2<MmjyGl9n@DAimjz~tIbhrcNO_vUboj%YAdsq
zd0_KCPjRueWT-4SY`(Hmdx_UmR^lsmdy6bym)}xqv3o3Tuf5DyBrgjtpUdyEdrMrU
zK3A!&$X4X`7dgDRN2$H6)N4bz;Vui4vxNFUvn)(hDGPZq%ED1P%0k~U%u=Guf<<Rp
zNE-1v%EFmp+h=8=Ec`uwSs+cK%K~YlRu)K;M9V@I;$r&9%R&LJQ_XB9QTJpoD)#x|
zzDxWi9&1Ud%j>s0e8r9;uixje_${)s;B))!_F}iM%<u7*`7G|DQlGb^)a`YbmAEaX
zC1vum;3&1a+&;J0VJ~u*dfg>uZkyF-EAzSRC3b7E+mb+8xP`MU919Mj>xFz_pV9|S
z685Y6pjh?7R>TbSi7pG(I?F=Rh}TgTJYm~sW#N+W_xNRjG>I+?q={NtAWaf23v<zK
zq>sETSa6+gePyB42CKIFi;BF({vxl%S6otzfX45zTI{8MOL5syy-;K=vX*&Vwz48i
zsl!v|v!Z(N6?tqHkFC_=DE7(ALaEj6^7xDW6c5?mC|6}3pVewDbyysBONl*^80izv
zvM>c4M3;p^VV|-roGk25tSoFpA0U0A%R*3RSx6f3I?BS5u<f(5a8>ww{IWorM3)89
zM6E24CW)4X+R024d0BAaI@$Zl+m_s6tHbB8+Z`@{S((F9=Jk~n6%|=5uw9$iRpf#h
z50!-ypR2@EW^?%Ms7Z?8?Co~H*IMdARZ{G66-CBKZflvf$mc7vTFPv$5*G@X-DmX{
zdy7l`ezZ>#s266id}+o=R&Wqq7Hq;kWm&Kb`x7e*JMr!oeWJ@kr_QpFG~#uXg@?no
z&&tBR;qURw0%;Om7DyAdvOt<7S{4F@OcQxosK9lC`pSaWQDXDht!OnDJM6Avx3##e
z$nNsmy)GZzxK&mbiY>*Zc8ePofyLpnx{H0N4^WDVEpCh5<*<0<^@0sG0JRlteuu~H
zwU(4w&~z@gp_O6tS>0}b0%hSb&ayBS97LCea$%pcEKC#jCsr0rCo|ro%R;x#vXC_5
zb(DqI!?w@L!i(YW@yh~f5?vNZ6ScBHn(&r|MzKF5bPChtQfz4W;}YOZT&GVe3&LVw
zfhN!8c(_`4o)`}bvd$!_mq$C=LCco<c&N`s`N<ZZ$E7}*TKxE&@SH5W6&*|a>##io
zX__tTFSy8*l`{wX#MQ{u5;%3L(;2W%ohqeMGt#2_(RF<ZURNtFr0df2yb|Zz(BDEI
zIp>$*p4Iz{b+I<*+MdJ!&gZLeepO=JXckf8fjI9-?7EuXk*+J}yoNfl@R4(V8}8Z1
z&$)KbrvaSbqQd#l6XQm+FPC^A&L2zcx|+SYbX_^;eZ{mVlJnKLXY~QxcCH;g8o>GE
zDxANR7&k7h$dz~?&fiMxx|-o0U02R|CEoR?kKE4R!9Dx<IoIyhG=THBRXE?87&n^T
zg~S7K{%K;@)$FOI>&iJ_i#ZkOBj<bv?pZyS+s?In&kW#vy9(#uCB}_r&mHkVoR39&
zGl9BUv%8C~OPrr8uDiOpl=gsQfX3U;1IFQ=eIn-}PfMsNK<^a!n(-D4drL}qW^Rgk
zN+BMm#)o2(D*8w98G1*EuFu}x!Rto&Um82g!ZT-xmBly7*!x7a_`N|Glkzpvu{8cs
zhb>!^m0s3jd6*^Uq0)gL@sZ~t8+oWWkl9Ui9;D%2>A4FjC&S4{Gsc|N^6>;mKKx<~
znLU-|<G8&rzY6|60^9M(M>ordr>UW#snL0*KZw`vLVnf3VfE)|3Q4eOf=<iXEu#Jo
z#g1M0h2{d9ozaB13h{CozLQp~uvLpGyRn~X$Zn0Vf?jK}jn=yd`|ig;AL7sE`GNWt
z8Xr6qHva$6*B)$c^7vX>u<mi_svz_|7yFMv-lH-d9gAw#Yq$mOF(#)9HnOG6WZH!9
zn;D-%zA&we>UzD>Ib)&8+c@T-ae^%g=U^Ha)pMv^T_$STk2zrIBiHgc<fk@UxK32I
z646q$TG5Y<gr3Zn_325v6>ICJ+14TM$ToJPAVk{+X)^)3tOCcRXFKCmQ%^c)E6yQ3
z=j0@&XZLB8qDVcdY-S(Kt!K>ViNxZWvgLCbp81K^fOMX&t+QqfM4XbI1JI=v9Fv|l
z#;K;Bbk1s=LwfEtflp7V?MQPj(I>im_8ek>o<l`+#55gF8KrVH17iznn$~D*s@Z-c
zUP;q6&}JrhCQSzzubP_DIc+$HG=26^K20wbeQp)z$fA#2Q!1muTy9Mxp5032a!KXy
zDs8Pa`!|R$vWLH_*aK<U0WGq@D`~il@u;aGol}W(NJIDGd>Xo?80bt&QKW`cZ<>$L
zsbPwjMbdG(wvL+Z8sdy}JUm8yITLzpna*^qWL#?MNau`&9;D;=JU$(#i8^jLi&A7V
z{U09gIs)5wvAqxZ>^m|-$CgGG%sN}xgbISc+#;N*_!I8m?8i@PG3qw#XYr+bf!~iw
zFz}(d2nNH)v;9sFCZa&_NpbD2@NW&SR`CbgPY<D~#kE=3A05|bW1ljv&B?Lg+R@Lz
z39$<}^;RMd#qXaoK7_O&L{*I|rE_RK_78E)-;Wy7qC(@G3DDt2v?Deh&CWR%dF#MA
zKcKwN&hRxiH#Rx(gdUz^^f`k~XjkAjy59=iD;wutjqi_`*||sI+<Ewpa2@9oUy*!L
z{7aD1TaEKC#Ig4rJ9Iv^<Kmq!o!gFc-^H<Ci|3LiRrt>Mbe`23Y^E7JBJS6NbFRZN
zWAcaY*Q#+pO7C>hW*5^9@cBrz+4r%105)4YNw}UAv&(FD$hlD4aSJ;=`Y)H=_8m!_
z8e_L=v4IhG+Y5g4&S7?YHRD9nZt0wAoI`fI@C2p{X<32qv9zRfHsTzz+e-`BIlOi|
z7w7c?*W&smlZWhp*KX<FS+D~dznOgE(D^)eOXrs3T(aBS#dEdnmd<I#IoIQy`wNHe
z$78orzd?W|Ai(FDOp`D)xE$MuVYjAJgzJUvb~yb8=DmemME^O1=78DXG&Lt1zt7Id
z5bVK%|JD4n1N+tdb4B?0NPi-5hu_rvFs&CB?T6=uuOHdJ@I<~c)}?FLBJCR|QM&Pp
zPRQ5Fd|ysZ7xvRRvopdGGRqhCvp%SyXPU`hwLw1{G}w&aPiCBJmJ2$k4(Cw0*vrCn
zk5?|_eG9cT;EvBPM7=w(eFS><+lH%mq(3uCb2Z<lrMa39OGI<?39&W5TF_RhIi16+
zc@WwaKnK!%T*;7r4tys&nw_Dnqv)I(oI{%bRd!BAjC16g&z*&X@QE(t-BY<W=jwmx
z8prMv^*3D3JMp_z&b#ryS~*{f{c7dBCw#oJocH24wQ}Bv{n6!oOZfVc<@`eE8ZNP7
zKcZGSr*n8U_d>h8SxoZ}81I_poX)AnIi&fsrw-Xk1-`4<3283%QOu+cZG583d1r+I
znhzCqA?7wpceS#vrMp^LPek``;lpF;9;>X=IlQ{hgMJgB1(o$z826gG(>YZ*hjhR5
z3_jhZehk|jQe9crYtQD^J!U_KQ9fO*d~5l1wep>aPhS$pr^l+t=^S32tD)EK3z*J#
zFs?OqrgJRNi*$CM!>6;<*I}M3$gC*e6*G0}995=`(ps%dYiX@krW4Wn-)JNzTBhk7
zUacL_Y}@}Zts5ENnp)F2dC-iso_;=`)>3~+#YIf((-5mse+a67Ax6)hqo#GZJ0wp3
zu_@fH?85cb>fu$`uU1aG!^bP@;kEcpt(^8?e{?<Ei+$|+@_Lx{d#J_9`QWYw9Rizh
z-ia*Vnw--)ojB)@IOiMLITiRG0@UIxI%gx!p}vPp<}#hA?*c_tv+se<#lXAJhI>&w
zS7?V|cf9+R<D4sT%-a_Z-LDqk<MnmO`yRa1K*i@Q(LTsdD5kHyIEH;hmG$N9^yt4_
zHlkL(wQNMKeD~n)!?lr0@Yr@SvyrP=-ZgE6&RK(V$VO(&WBkW!OHrGR&Kblx)Xsn6
zk|E7_Y=q9uhhEgqKj=q8_d}B|rj5`!wK%60#~kzHq5IY1yOxdoNPNy=7tW{8S-^fk
z1@HuHq^Cx>p4!y0Y!Ej@b6T*nK6R?l`6>3cvS&96a2@4m=-CYmetZn~k>=|pyS-FQ
zQzsFK&uoCwgeH!VCi71cPm|1~1;3{!T@qLMKSDzAL6^6XE(|M~RwECc38f431G~ah
zai^(PsE645)WnsPrnM?*dJ<_GOgv3ts;J+Qho|T?HH!Le`7yC%GM$D#Y&@D_a$x&3
z(o}tEBKr9nTNa=LS*%X#Tb%Ct`A%PB(}MYRvVMKhe1-cB{TZ^eTI`gkQ+n=))orZP
zp7sTCT(qC5z&>`|P(MEP{S!BAf3xq31@+B%gTJMIkxv*GAiLfuJde`oTPP+TyM#XF
zW|5!WHM9q1P2}fPk)M92QT&9Z6zpqH;^-BTql!xzM=yh$ark#Fw$H+bg07ex#q5g^
z%q4;OP=zO(Xc}&G-!<d)3MWDlVYX?fzqzRaLj+EG(5PIT99x`l3d0<B%neOtr;a5(
z>hF+ElC8<-DyDjce0VqVCx3^P>J-yY(EkfAKEUr?EbnpaF7gc$hwV<51UZM#;T~Nc
zgE>^0-e@#9l+R}tkHbpv*9I<#!#<XGO%C4>?Xa(warla8hc9CL0yymR>EKW-mI;`m
zRFHLABdd#f>`^{PX*@1Fz~e@6LR^~s0teh&=DC$zt^=2*I^(%iG09QmQa+ziJT5oa
z;`vx`LR?xH2bx?yE83;m!??6!L;mq3;1zIbxhy7^5&bu#?Gt(83HdzT#G3<oiuQ@*
z-y{z5y*L0LIR~$SgP;){s2I?2eHsr3^11lpaj;Ib1B*||!3J>9&C5ZOd=d{AN8}H+
z4|upJ_ba*h4Y(LIhzk{yFvO?ua3P=fDjpaAE80c-e8$CkvEF(?jGru*$Mg@Q9Y2NV
zc8`pp`0Fg*7^(tx(FQ)q&(^a1Yx-G<$BlJL9w~;ZZ7`Te731RcH^b(UH;(E6hrQr~
zc<f~P*W^)(qjE1}Jj!EHilaK4bnrNmJ}U;Bym38m9MuONCx8>;vWIcN&87EpC6^RO
z^;}^*mnvq-@AHPqC2t&+2Oev|32`~dIMC$sdC^Y>0*uQdY$%Q@1SpOgY>CO`Xv9%5
znB(tT<Bg>x9zqRD9w?Twgbd(8#fXgXZ9Mg6qVZH)qml=Tr-HmZB*{1NaFJ*{wX{je
z1;ta{263Tc7KZp19xiy}DJjn0NS!wL$m=iaj~a~4#c0P<Ep<)JwCs=A6J>lH)d_p(
z1rOwB%?kv-py_8N{>C;7^hNMTag=#sO#h;fKNX|m^fkKq<BgyCz+D!2ApWXZzBT!i
z`tqt<7=O|IP}NuI;BO>-R1}Lw$4%MbZzi}P4%=AXxj9@$gRS_;Ii$F$?P}vWR53$-
z-=>p8-gs#)`0E50#9=qfyC#QEiSg311p<W;eJ&I)bzc*c!_kPBq8KwiP73G$N@e~j
zP8u{K|0+f^9N)!L5Aw!GQlH!Mh06R>d}O(nQ~y!+Jv<!n#zhhbD`>C=A9=qc#YI7b
zI8ZTzVfhXo4tV1ssXpqzig7^Wa@2166}E4aABfF?zWO}gGP&``=fZ6$<{X5QG_3Kt
zH<7>S@wqP8!d7rWzO<j^UDKCJ9Ol!DQ259>+=zShx5X?=`Z!cEC{DjJEDqJ;A~g;N
zz@Hgh5Qo{<3whV%P%4WBiv<dW@ei^?vh{bsVfK=k9F9hP6q7fevZ&T}kLFE24pMlH
zl7mg)pxOuyM!<G>I8dvX)Hsm(X+zgC4x;<JJ7aU8uPhnnkA@m*yfHFwf42qp5Ck7o
zo_bjRHOrI4<NE8AJW@NY=f;@jNgt1f*;V2^s`;hpaYlOfq7@vj1s}xYAj`idk8g=_
z^4RMckMjNk>hB)BSqG0J88bzBsv$P{`ww{gynDc97I+~(&3M5KAp<v`H8&{vq_&&+
zR^$0pF-`vX%K$!k+i}_8avpdgKC2lIntV$Az1}5^&**;d>ZLLHOhUamWR2t_dFl<d
zx-+_LQ{5@?5NKEOK<&9sBY03TBz<vL;ykF;pK3fvvFPF(l{`?pu8)_8B>E^GyWnl(
zNqj85Ny!Jb@v?8{EFT(tsF;RfK8A-6-u9kUPI_-<e7ppwO>y?~*i!#@b!<NL#RdA~
zEA)F0^?n;2Q+2`~Hh=^2wQVfV+`cyR7A1ESQ?>mxrY-5?PQ|D={f#c}c;l#zWIN!1
zxa($l*5pnqhgG*S?&NVj#Zlcq)4`oanN%@7{xTWCpz*O&7Wk_K7sO#d%R4uROK($h
zNU>A@UB+{$VuB;iA#c1i6a0063*s<)nUHr)4j&ie`HrQGLkl+K|4sy`-#h#6m>iBq
zycA(|M#o4}-rH|i=AB}sY9sQlVlaAr7Eis$8y89aOC5J8^G<P5CvV<I+2`<Zz#9um
z94!5*k^_o``V8Vg#RP`sGk7@Qjen$mk<FcqgXs7t`<|HPUtb-rQVDUEhj7a?!YLrx
zhQ~s%hd%H@ezbz+U(=6DJm%f0<dI^bihB*_QN^f6i$~tLXbU*Z1s}v?kmX;KN9lRW
zy1N*U(Q#4mJ{>%cq>qYWmAp2|+qYx}k6v&>Ty`-IxVc=jOvxq1M_u<D&!vi4^831B
za>*Mf1;ArBI3X_k7zdhMO6|n;|BrDQ9VhiY7?aD<h?8P4XZ&*l5)T{hR`NhGQ+AgD
zJg69v5x$M5-sFv+r02f+?oskU@l!P~4@vS(JY4X`Q4$whmn*rTII7biE>z6I5Z}VX
z1#dhhagq0P#s$4kN$sgM*uD!c`eJi2+VK<>DXd4qHq($s-a1QdobKmGDW4tahdtzi
z2lBHtVGk(K^s^FwHTTg;CX<}MKJaIHIHrHm$DfK(arzqF{HeuHYW$hO-8}F>{8?DO
zHTjeJmAY0CdnVI5(f*#p_C4@tc|-?)Bk7}}Smd=qwYW)*!&>mS0$dP>wJh)491h$s
zP#D4CZ^2>hqsDWnVut*_O(%zH@sb*cE5TnsxF8NYS>81{l%6LXcz|(uGB)G~sR;iL
ze>xwF$>C_kOHqssFHVZ)jK<%>`F~KE|INsMpAq?2F&fGkmgm%(+d+5!)#4+y{7Zc+
z+q#tb|2^`b{Wz!oqwITlVga?dC>{sff1%{y58$BMAP!W_U|7C`hXb{ENR0#cUfDU6
z`>vHr4&Em}z{>$yYyuNYaF&BwwF#h_7KDNeLeB71db;KkP))1)Qd7FFZx%{9E&PNP
zQCob@AJM|FR{U`_w$#&lsjvz}cmL@boCdR^n1RP;)t;UBBWzIq%q#isX3=JsKgw)Y
z9)tGd_`cXSt1kxC-zPfC@*15zs;E-Ugp-lS;mxb`L6i;CvwbV!Z<oP-DP}W0A=I^+
zF`Hks`|8J;-OFRPzu+FGCpqiv{|H~53_BQYcb$wpGF#W{ucK|9{Pir+ZU<K@?e=5X
zZN-0;-5Sw+N=3gsTKO8DeGWwVVzN&u244BJ(mp@M@oh%fr%EGW)MDUR_ckg9j&=P}
zi-BV$AT=_WNDQpje*Z+pW~CT-#k0(2<uULej_-+Wv-&EPSQKmbWeh(Cj&*NUd5zBA
zDEZoy&m(^ftk!?NBg%#;23`e!yBzjQG4LR>SMC^i?sH0C{W<P2__P5ra4ap-wr)(9
zMJ#?(rabe<7;64H+ScVU@Xi;McKa3V*3$joWVigWVk}ch&Cp`B@-;mB+!^JI$v&?Y
z+h`lsDed!H93SMh&ygGt;EN>mr$E*J#OM>&e-}edSAQ~6DYN|ctTwjujfy?rDcbYa
zmzh1w$JtF&@O)WpdyXAI>L=T%$U%P!ROKF-tQr_G|HtH4Y6I3WbBy{MIXA!BvlHJ(
z**L||z3|mrVBZu!_cMFejGu23%f*@=mIQepat6vp|FfKNh<;_#WkKH{pnk?vtn5o=
zfv1mI&EH3t1&Uu9MY|5YuC(iYVAtkf{kPh6WK62xh*CLh8QnY%*M2i$kI`e=Qv6-{
zhSGiy!11*P*{@1_N;C<Mr;-ebzvHAp)lcb*zvJ9xGz~dUGEynC{PDNib4B~9*s~OW
z*SyK>Sss69<M^)F_N+T7jYIY*#T;=`pepysWOel7?>#5KlF#Oeztx_*9T#Qe6n|I2
zSI>ieQ~ce>?3p|Mwry1U`5fG%?>S@QlsL+y%fg7n-*FgEv9d3f1)lg@&EH3t1$q3v
zbCc4p4~1Q4KmXrq*9pa@af~RH!<Ny_<8bYFLX<Bj`<32nvh^|hm5-+%j^nFi+i&bj
zd}N-pyRxa?izkQKM&g2}UQ>H7?64><s9xKJGHd}4RIjzMd~4Qg5`Urhl>AM^J=)gB
zEdToWQz<E&&(rAUPi<UVjXwvt3xWsYubbstlRxRbu(iKs{K@0xBfwwxIvxBCr?Ic~
zhDsER!+9@Ejl)*(w+37ghy5(?+#K%yosz>maM-`zcn(#}kiR{xlS8%mRE@*+;BObW
zAP%!%7V@siq4ZwV?#+xtdH?W{;4u5um>fn{0;A~rc;XnfcMGC9qk15m|KBU~e-!dx
zZAAW6jAl5#izokT&nc+oUwSXh^nc3yAC3HX^5%b(eGd-@YJJJ^ILO?h<iHFL`V8Vg
z#SDh!J9s!yi|5rikmk#o`A5dVVSAZO2jSlwY>y*9&=b=S=&R55zhmP(bIx36<?IWm
z&pfM8_CM>>3bN!!{T&)_Yr`+maZv~M9fLf|`)DaH%7Q&qfscRS_j6hPHT|i?<FY^D
zBz)vN=HnjS|7$RhDn`ZWTV&kn<1souip66!IP3%;#N$6${xx}&=CvMpU!c*HE863D
zY>x+z)xXxk<4F3bm~685;dtyadK@?wpUc5zKX@TNZ)H4i^J)9DlFv!tbMQCD^QmH*
z{Qk}WKBMENSbS~+mlp6sd`{^Vc+liins=w1f-QWe1LJ_xfD^!H=UXxP9F4dsCVLdO
zJCH`@XUIoZ;K%6rsS5j|eI&(C5)YLhvMb7YC?LBsf(I2tGQ!94@DLqG#o|F~&&};u
z@-P`ZRKLw>4@vY<JbXmQR9bv^|Dxn$3i#+Yhz}LhFwDpB@DUwf#o|NiFIo9l#)rJW
ziRQJ=-Wbz9Mm@e_D>|YR8xuR)Z7i;;W66&CJLEH{ev6K)TCp#B4tR>I>R=OH;DKCc
z1<SXlzm@nK_=qJz&Yv)!<0gaoQ!y-FpQD$*=y)m?f2+V<KX@Sif-K*f{7G?X;olg4
z^8O~8-#XZ*gTE2=RnaW+&xaKqN5$fC8#pWgAH-u9%Re`dp^ue33UfIA)_5LOOfdl;
zr=Q2@_$d~T7H}8@AH-uH%fBX%Qol>+?~F%zztbzQ$G*)mc^sAaDVnw6%xMwr1Lgfr
zp>4|i3-dPq-hlk87|w8fSOH6F)Zd{xz=B_*<0S|7spVga8yA1VE+^Mtn6HsH|4Hyc
zJUm3lNm@L#|3k@xFju2NJgAt$uzd&*57F^aEFPqJhWkEcJjm;JijVqY^Dx@+QFv}w
zF+ds$l#q1ZaS`5FsRMSg5uA{3HT^;G37WoD;xg|uC6^Q{nYP6AE&8}rF)mI&V+fbL
zanok-m<vvbOAF&blS`=|DzJlb867uS{-lG;k@Q({80EE1-uTH3F6+Px@mb4w;O2Av
zKb3q^{8YQucs^Ckli&9lz$b4U6$F=S!3*)($#~G@Q)(CW4l+LF^(e(rogc*Hb2Q?p
zIP48?o-nnTLgHfc=SnUprs^|-3l(EB%GdGKr@Zl%)E_nQg^~-3ud+Ynw2LJADjq&~
z<1C4fo&QquL2*{KL42r~hhe^khY#L(ODZe2FBu>5c<Ute&vnM;Ltl)bf4on!K#9j;
z#aJgIZ_(p?yI>O*@IZdIhvl2w?}olo@^>=s(esy><x3xbDu%`BcXaco7FVh9=Kyy>
z@Id?xvV3duC-q0I|C;e9kE>1re}f<C;7`h_+9aZwfm6i<C7aTIMq0YIbOw?=oOnu&
z$5wE-7JLwo<^du9+&pG}qvX*79?c&c&!dVdO00}1k7{w08jn3>Q{aPmtY-Pw<WcI6
z%KSIuQ65JXfye4?F?k$~I7(rC!|9KT=1krnmHDkQ|5oI`(}?`57|w8f7*Bnu7B8vg
zU+Rw<yIYz6V&uP%H~*4Sqv(Tpcu<Rz;_)!yJ0%Y`@R0opXF1T|LB$k??L&BYP>YY$
zc=)Bb4&yG7hXX*z-oXAq33#ZE&4a%BU8QmgmyP*8%zo`^b~X4yzGf#)&?`()Jq>9g
zKY)$OhxN-IYRbvU!mq)7DDH7Og|{mMCKHu;DUVyfXQ#{aXh$Avjn1Qr=p&s+X-&xu
zKPdB9iaZAO<Wa-6Riu>Lc1$&gqotJ3)xxSSCX-xC2lClA0{K*tbHwv`Lk63_KCl-S
zP{Bu@&r^}lPCfY~BUF87OFd|eXR~~-OzXL!Y66Y+HQKL|!s+nZ>7UWAj`lf{eubGz
z{Z4~^T}JDtVx%LhU#uG%s9&sG@VqjXfPSB;=y$hR{!IHQ^*bH<b?ed3aDU2I3iaPM
zK`r&)h*MGiGWlH`O*ikW)btE!+A{*0s+h1w-C>BPac*m@rg3g$xTXg}qi8=X#dd46
zl$uV*@qKzU)l+RzjiM6q(5q01#IIxG#IGy%Q|9qZ<gwrAJgSHquP!knk5XLMzP~b$
zmB{0uo;(i6AH`9VH!e`qQp#uG0A)VULOxCZh}rIp9Rq3PQ$<b<AH)<jBA;`|vV4{x
zYt%lYXJ^hvKC|`YQ*XJfZ*kJ8E)O*;TY^4My}#bq9MQJSMY@!qp|+(NKW2_6{}Vo6
zXj@8pmLI6h=Q+q{t<m{Z5i?viM=+n#`*VfkSU&CGV?Uq>s6sxw_2g5-ZZ+DMF>))J
zHj5Q_biD;V3(>kt`OP~>nco>yPCp&>ayp{<mFze(o8@;tvPk9C4N!Tl)|201lvg~G
z?VI213aAuUp<TwKYrOKhT_vAXUi*yBr$%`lseDTIyETXDSqB}dym|mCuhrX)w_ok@
zs*>BG;>xXSyz;tnyfVL3Ui(KNzbev7xuIwf<#pup`y;X6w)Nnl@;VmUQh8l63H^Pa
zMd;fcYHAfy)O4k<*&k?H==3x-dh0{=O^xN@XIBDEjq{~gwE)*q`BXfEo#WBhO7-~j
zIpjC}0oVMN@VL{5!oJ1@4Q^jEoiFcyt(m~mdLs6dZ$UBz-!d4PR&RZilP!ffb!zOG
zXBfUE*hIQ0BLRwc^!gR49a3?KGLPg}EIT6f7=9jAj87g1j6@zKpJF+b<*^X@kxw}R
zAfFP{lgDAl0Lq+7g%HUy#HW}KQ|6a^O7{rlS4CDSJEBh+x%^5toSDn=8y&L`>dEgg
z$|+k+R2cynQBJq1<dMp0#Xm>4oQ^~ur7`}^hcg|cWA#owc^q~*RpeB%>tU5qDX%>f
zm3bBF{SnBkb{QR+yk08S`F%&Qye@}-LzC2W7ci6Rn8BE~i&$h~y%$UN#%Tt}(ZM9t
z`!vRC#=Y(p>iDK0MGr0bJ`wvVUSRRIIIk^@-eMn}L$Siz<0w`L_!{SjC=|uLa%jp8
z(?i0wki14$XaVB=z*Ry*h2JTc(ZAELbOnklBtH7{7#}qC<iWsifLY*UP#+&0cFD&F
zi&Kr`V~hqLZqYuL9m)7868WHdx|;a-Ji<O$OxWPM9A+Ud+$^_`rUlI&HvV2nR%4!G
zo+6H^kk%@nu#GtIV;1Wx5tf6dV<~2=z_#H?vIAeE7ypxnmx*bvK1!M9Ib_pcB%Wr;
zRf$_M<t!H9Nqh4VLVtiF?N3Cd{RT1Zy=Ip7P^QU*Q%wPEe?c+0TH5h^16Iuz8V2Zs
ziio|#J@ZVN_@YcJv`Dc!`2m$rI9Bh%kAXbOQ!qrlQ<+?a?ITDd`aJ}p@m0{M8`}^t
zJHw6Dy;(V3i|^rb*z9Xr5C}P2>gPB5a52)=hTj(m=diW_`GYomXEspZh-L;g<U_8I
z4|7K_e-IRo_k`OG#|qzv+6|L%9Ho`DCmLL>SQg#qY{0GSgYXeox&jNxz2N>?Idm;D
zQQ?UZ{7>&*&xJkZL6<M_{bi<uaIXq{XZdrU)f#N33kh~8ol}i-==W=O3U())L*<D1
zwnkrT$VpA;h;ugJoENZf%$Mw(W0Cfm_%3e?IbD8ga!45vc&oxOtPSO@pI;vmeBM0u
z^ITq#LFI*TlW2F9$1%IRE|b~aLTn$0rrEnx%8U_qCwWF@dP03ccBJwN+aB3dwC#~S
ztyZzU9_){{y<Y4~)b=`X4lBdzws!@7pPdok_Udp9kL}U5qHS*@>|yz_876wf@Fz?Q
z!Hz2NJ(lg!IU8}#l{n`3e-GJSIli-cL}`0;P6cd$_<T}4hitDJ-?eOy>@(W-YShn*
zu)R5=?QIrq?*g1dZ9ux-T=?tm?;>n3qMhsWU5@hRbT!W}XYRvH%&~bFa&f-OCtRnP
z@gsY-3#SL_TZl(03m1v$smo_&L7tuqkskB+T<Hn>VV0tJ?Z(KuUoB0u#5C;`)AT<`
zD{(XnxCCkH<V#aaT~l*N^6|svr{j3Wk320uMp{fiB*u@FsMu{VZGO%b`N^Kd(nP!v
zKQn+Dq$$XkCe)$E*v?9obo>PA=;upE*mi^jArHghMzS5t2}->#MVhMdbS8dLd+IhQ
zD_>;B;do82?MxA$fmvRlOp6m~>ETNY-vbSl;&1>YcN=I+sdOw0<y7@}qq_{X9~C2_
zhoiZ~vuTQw=UVV=$>7p__&lpLY>nnQ)-8A*78x$jcF~?gCn|Y%f#)tGd6pU>Y9&?O
zq{Gpb+9|QETK|nklk;tbO3vNjJbNz#ZCis1726vb&g0x@G&q;)kkCm=&OP9~jgNCS
zi?i6~*IS23@nYu5%CvZqmO;L>$maPQp0Aa-=~PLN59z5L!)1>VbB5{VMjFE_I7P{g
zA8G01OG`NZ2q(&*7-Wq~y5=KY6`5QdNo8wTb)(eQU1eb$*^oEt<2wbo9BJv6r-dpj
zXQ<g#A8KI__h0~VK`7*LHZ}#CJeLc-F3pXufbgRkBcLrI^Q1y&eUp2EA1e<qzw2>%
z>U>@&x=NgNO>_W-;6fe>=pV($9B!jn@LL_yG&`dljg%HAb<j{>iv#=XW&4Z7{T0~H
z+Q#g7EA~^H=2kI2?kZw=w&FO-^GQG>u4CF;#=ktz663M5E&iTJ&MB_p$#+1OKfU>u
ze1*lz@=YBr)GoLbXu|a?<oRw1$%90Mh~8nfEq{I#>89Sc+@O-4Akx#rm!5F>6k;jl
zg*R4IOOxcks*4#%)Coo$)dE)#NBhWZBMwK2wk_4tBDK8-RMOH+{P3kE%uk|iOSLpf
zZOed-@k6{2KR*Uqh@XAA_(`a3sg@3j8&iog9U<a|FCAfS5^Y<mrAe}#rDB@owzGh^
z$>QRM%s8R8rCM5~HqTDG(vGhre)!Td{5DTQZOa&IHWDMMZBg|=U+@FGfgtR5IQ~N7
zxyGU7c_C@OAD8B%%yaD4&PY-{9G;I7+m>s~lsvbRJ*OnkM!eE*Z2w3+UtvB~$?a8S
z!~2ht4Xd>4gtDw!_I3D*Sl1tAU(r#n<arU<a7yy5&sPkWY9oBbz-daJuO@pwAQkPI
z-&Z7)Td9w4-swti7n2Pe$*tI)QZ4@KRln3iQ#~by$IyS5QSuuS=Nl`OoL@usJk~&a
z*3X72=drzq{u}YqJ{%t+#dWsnO3tq(J5OQGBRxrK^DNo+sxy^5Uq`lm;ON=5ieDAU
zo2F{p`us_pyYL$JFxxB==Xqx-Id3D|PGQb<`x66bH^QH^pRMHldb0CzscYv6`I98`
zEcL-;pQGgY2C{8Fo)aFMQEOL8{jFUpX<0&=AH=1(uCW=l^hn$kRw=n@CvG^?!`3w5
zA16{vi!?T~K_x9W5;xgg+=Tn@^o-4@rAy+ddWMptn}{R6bV>Ebu=<vy=Z&|EX`yj2
z>T9L3iYF$6qnwx=v8pLVg%M*feqZy{sV$ynSIAR`7t<Crh9ch0jyL`wy^Ho3?l(Il
zR9D}^#!#fRb)3t13W#Z=_gYuu*jim_^SVN=aMA?sXlzIMVPitlGtafhMW*fF;`mPc
zOqRA5Jhz#Ri(HQF&CqZ#cG}o`ad;NC$>VEjX=3lNt5*K%?GHn{D`It>Mu!RLyY|h;
z!_E$jZ&4l9p(G4@hB)iQw<Z~9^sc~i>|@V?dR)Q!5S}Nl^R;4}k1j>OlMZBevoo5S
z@h~k0`JCa0iRpRdTKvY|TM$!&CzuzB&o|S!9Rbg!w_^0rL+>>>*>ldq_+1r#LvrwY
z_>$N^CTA&Zs|^}%!f#I<EZBP7=R9d_?|Vu6SxW6Ypncn6G0V)zX&*aiF`~OwE<d;a
zuH%QwOseYN0qxtMBk4cwa6bLN5cO}ZR_cEX^v^yr3HnC{P)XCg7cY`ZK0IYLhu$G*
zN1AUsicfRN--qTXHNO>_cO7et<|?7Bq5eMB^^NfN*W{<Z_KTr=5E_#9m*(?nFZuh>
zT&4E6L3>L<613On@Ab&f?e9zX0R3B`eGod5{yQe~=`Z>Fx{H+hFNOX+CnZ6Det$or
zn$O+?{Cz9*_Ch<-{Mu9aG~Y)Y3l7d>nqMWx_g7$hJ2bB@=GR<*@2G04Kwp=jN}w+_
zAdT?-Z|wnPKL8sDKu@xRaV30qu)k;ri+`lFgF9dcgN~%xLF^hpzrn>b1@3y_xIMrp
zgkT4)(3EW9si}OnAjJWTYm~O|Q`kc1w4~WWWNnaS{lD7-+Wl?Nz7;x>{<A9h^q1;{
z_DhxecS3(lrD6K3)Y+1^Hn2{JbC-CIfVcnW2jTr-)}NQEZNWC!KpXTVJJ@j+pB+eb
zLT9bg4t@qZ=$nx=JJ4Mx=rjfHI$_fuU<)0vgQd`vY~hac_-sL{6FS{WTeuUp5S*Pf
zTS%x*7-{|A-vjD|Wzc>pbR_*xzJO1Esb6TRm+2op4v>8zzy5kU?GmXC^jtqyJy3)f
zM0o3gJz*SR8FcS}hNS(bi}<vc%KlQnQhOQ)==xC-w2xf_7%e}y{(HhWKqs{CfR3d9
zr8Ru|OZ`G^bxQqd9KceW1pOnue$q7G6UG5Lq4#2FN1E?&@o6sk`^A?jHK%ca9-lFq
ztJKG&WkL^$#S=f)^^NfNd%`$CJ9KY_hNS(q^ZB%w{Qcs9QhOQ)sJ=W2+UxW8dgSN!
z_j|%PKpV7gg^r~ExCTD`C4V1mRO(OT0R6!v=+E!(M^y7YVH}_hdIz8#Y5qVnpXO4Z
zPiv5A9z6~aypmsY{oQhjMEUyfVubJC6UG5Tuz?WtBs(~{mCp{OKA-kxr5(^XK=$IK
z*+J|YU}Q{zyB^pR#sL<?4%(n8*}|r4_-sLn1KLAMTcB}(?(36g3z4-!lJ(yc#sNB@
zeH(Nn{Tr9?=`Ym@ORrSwPvZd9HyftEN}Vl=novtX!w}-!#fUm#PZ$U2fDLp&PqKq?
zxA574R3|KNRoVfK0}L)rnjPq_6Lgvacb%{&j01GS4wgYvvW2Ja;Ijp(PFTK3X$v$C
z(0OOlY$2gKVWjon6UG5nK>KCTk@TOnj8A{5UufB4rhoJ}fMq$q{_*;4R376ov|lLJ
z^<&lp_W!JLfECca6B?5CJMQJvUMl;`u2pJJ;{ZMPCqetzHGm%TiYGs}@81)~0hUAi
zPUuMbU;7}R{!+hCN1IZA8V9I;I0^bkdi|tnz9)<WEQj9h(2g`8_XwZnlD}`iL8&>7
z1N5&lMst<=*ie5T>-zBuJny*go-huu6uP%TL(=|%$N99E{C#`7QhOQ)2tJhr?e+P4
zJ@Rw=`#oVCpaa^sK}XX6<ZeFwC4b*~lTv>g2QaNkg8uyeend6j6UG5Lpmzw`k>;;F
z$EUf}=hN1~G>;w!=zNi1bB*2@l@NRc`h4Qt#R%WOCyWCuh7Bx+o@58JUgEO@sn2KW
ztx7wfaRAG!Nwb64HGqDDi)RYl^}wDm4$uxe=zykV3p;xFY(a_xmM&G=0*wRoZAh9e
zMAimL)_+eJ2k3<M9ng{VzvB%){iQl#*&Ry#X&fN<mSOs<)Y&6YC&al+JV(IW9@rDc
z0Xks=ozRo);N*>bb|BRWU7bohpmBigzNFcK?m9uIDR9>bd%`%ta@fHNXiB!Q={-JM
zkm`i4JC(LT;{e^iPns<xR40tI{(HhWz)EPp0y>iZjsM4||3vY9(dEmS{<LHpt?z5b
z_HO83{XW0`dOGbAc~VHv^<&fn&hXNdP2yxwL(8IK?wCTFHc0RdG!KvRGc<2dHGY)8
zFF<Q=%)>smHtEpZJ@h_VE%wKoPl)E6V)JidA|*0taoKh37S=na`GW4pghN=<*wqqp
zvIRV`kLCqh3Eh`L!$tW1I@3&8@6(L$L11<UJDlbNB1m(GFS}c*`@PV;XKNC4kL~?O
zTY7Ho<zocN(tZVW?}Uz|ees`Jxu<!+Vrf5KEc5NlmD>Lt+FL$Ig7%T#K4tZmj}IhE
z@8!_C4cd|34>PUemUYR;FaEhw@B5&4*N4XFtx^Y*jtM>a6HoY9*B=cZFCQC7mhK(U
zycHUf?g#g4mvhO-x2{m?z5=>u|0M~!>+|s=Aw9Q`myZi1OZztH9)gaf{Su~I+%hlu
z___y_+TRcD+y0sa?fHFtQuUUP2_#GJ#n9Rd?MUx`F|Fe2JxQ$716@pSJ2n)@({gSP
zK<~ki`1RJ`{gy~Hum3Ki;qT?+0mHR{`-OGhV#oA-N2<s40q9=`J(obo`2&&uo~<Vz
z8PiV@Z6NfJ(gq%+GXJ-v*+6WspByvb_Wkm)fMnT05H=8mrep_SGY!MOK+O)MdOx^Q
zX$M_Y@Bck%b`V(uq`3C-ae!oL-wNFW(2=yinduf+d#N4>{Zgs@FQ9$bHp8@6siQ?f
z6N>mXj3CZkMx!2(j{zjh213w32tCOL4*P_^9$36eX#)?z1}y(bnhof#2S&&Yxa$FV
z|9`UVpcOXI3Qfrl9%UNF^#xKr(E7O24jzUb^n98$J4mP=NVfL!zW-!t-v-@7(2=w+
z-LCBeq&}bEYNoxSU;i_H?c?>ys63WqXrE84>+AIWGz}1UnNNj&{l(Bc01c@f_&U=p
zT;}8T>j$1v>Mr!_??{5~vAw<?(;ANS+}fu?zkUe1*Fi_pzWAS!WnN8tsn4gTTdBR!
zuRoXs?IS&X%Icj8{rW*@JrCNE-VZaa;+A#E$IpFMskhLt|G6=GtJJ@S`uJGaA5KB1
zXMA|ZZd0LOzZRNTLqpR2;4iexxfIt`uTknQ^y~jC3A*d^@gpHUw~tSSe*JmSeI|4y
z?Uyj!;+A>I$5%YB)L!V<-<bsM`F(s+^-hI;{khP(9NLlI|6*Fj)m!S%sa(tSR`lzC
z$*;FYPm4;ZJp%nXaqco2{yr7@^(&!&1@xr0-2AU1{k>X$uGFtTbDh!#gns?6lV$_4
zy}o{98;%)p`~Fnu*RO&NR6$d+gRhx}VPBwT2U5LXwO(llLcjhuNwb5<8X(2BPlbN{
zYUo}G9ZCC}nQn2lm+FC;uPC(_`t|>9nD#1l^a#`gaqco42f!Qmr$WE}Oz2+)J;??R
z`<A~RnA@YY0ij=ichYP?cResdX24w!q(Z-bHEf_7nvxwn$~27Y3#59W`hS&nAoS~h
zmoz&_s2)hR_NmaXKM%UkgpQ<r>G#?`K<e|U+Q76|^y~k?uf3kmxI~`t(Q|#hz8};2
zaF_X1=+~bM%`2fHwF6&gnuW`}THmfz<}2S&>Mr!_<C%W^;&ghNL(Z0vx4y~A*6y7;
zbq`;|SL;=cB9fk4`&8)Hp9$S7pd)EtoFV8IS9__?$JVRVUg+1~D+$_1div2W>fCy#
zLce|$w6;Jy()(eiRb0I#A7A*EQg5MOe~dADtJJ?K-LIdBk57eueFrozfQF>|!I|3S
zT=MY+8<n~X{rY<+LHF2^eY`Rs%e015y>plOROr{YK=*v;NZK!9y2UN?l8?{bq|{#M
z*WV`z+VlJPr0Sgt{rZK_dIGc~z5m6uimSKOpOe?e^j7ri@5`^Z{_eI!qIvyy8BU?+
z?axVte*HY?p9?*yEjK?a(%-A~=Suzh`M*`#fY7hMU(#$Kw%1RN8F2glROr_?!v@UI
zl<eSZreW9@sM&#3@0&L(?Lg?)KOkv#5LpAHxb~^guU`P&^PnSXe>2l9uJ%$rkpBmz
z_Cmk@Si`hesiQ?fQ~P;+p@Gj^52QlBem?X!Lr=1S!w%%H2MV_+Z9wSPAD1*6&|MG2
zF}C4^1KjmMD)j3Yzy=DSDcQlJOvAXoK&l4{{-m@6p<n-?q}f42^+2+<PlbMc3v|zi
zj--8QwzdzDw9ntlw6|h|sa{McVfzT))u_(l*FIjuT;=f_L;HMUU0+9`cRDc>kKH!>
zxp<BPkFzsIZ!Vrf=x&CN*W<o#GTp-EUafEcSn<8x{124c{}S5wjZcF1u|2;Y^BS)F
z+<srJe}A;~FM#%DXi56dI5@KGtLcBJsDEz1QvXM(>`zF7{*fL(r8QUU;~#a+q4xyn
zCzN@nSKKl$`TGffRcgM9%KRb5Xs%Kh8|v?4U4OU*o;TiC>*pVB?em~}Hgpuq`=Q$9
zUGn!629(-AM&<pmBxtYC-;b31-2PszuYa`l&xQ8c&{8P-OuM*cU-I`^A1n2LoXUP~
z67=Wy_es}Wt-pWNHHY4r&`&7yhijL4sjoMC8`J!BY$(2;itQ6r<|p!NuD=^DW&8Ve
z#rkS}{(9{|?;Jg2VFP2K>8%v&GY!LKU#+kAWHHvu`-jpFR>KbZk4Tyw#I6DK8{BZi
z0PcD~t>1sNZD9iJAQ!rlEnJcp=@Zm!L5c(NwkvJnN!UX0$fVgqWNokq=&#oIKic}6
zp?xm2B>g{O+Qsz+Qk{^$L#h8$(BE{lVfw4o*(u-mud7Z_>;E5hJAe(Cp()wHRZPRU
zb|BRWmO-T*JPkYOG$+jtbk_-S3~tow1hp}M(YA#G*g+w5C0p3<82&oJ@`chCx?v0E
zW0PhJ3DpUypugHUz-a4lgZ72clJviqX&2WQNc}>EJDL8`;{e^q@$0Xr(=L$~f}ZOS
zqwo)V?jF6`>z$L|2Hgvw<Mq&fa(-mlSL+9s;=#hNl-kocfaUlkXdk-<NQV5}?SWJn
z2e3f<0%%G4KgP5Rmwh$;rG6pvE~Wl74$wU*3HnER{gl=`6~+N9&^r(M31$8S?J_U<
z`@DZEHK%a^OMx+(tJKG&WkOH>#1lW(^+(I!r@}ZuK6KB8jzW27y2UN;lE2T}t<;{z
z0lFtAL3@4vex&5*_V=kU4q%4%xzJK5`%|>bzU1$-zgOx{;{cWulb}DpzfZd6sW1*;
zhTdbLpHSwRUUAF3)aR3nRhZ}#Jr2-a$gjEnZn;FFeEoMBE#IFC;{X$20~4U>t<ZGx
zNs(n=t?yUr^U2>!X$Le8P;qk7>>zdxkUUf1t_M<K93T&NV1}+_3okMq!#+XH7Nj^J
zKT~N7G!D>rO44j0vNqTQ^iPFxfC6Z5hL)uN42!lekm`iOeU$psI6!TYVfw4o*`lZk
zwFEQ_A<kV!t4>ITaexBYKmjx*JNP5hFs>hv>I6rY(hg`GV9=U0JJ4MxjG!rS*9oaG
z4q$;D*q|%fLVdBePmt;a$NoxNpmBgUTheSHp*kTI^iPFxfO2SWgO;TKH%z;@zCh|1
zvW;c>M~?$!+xhj6*KZT+dHqCM2zstRoO&RUc_7s0`WfwUfO6<=fsWKhyoKo&)?Te2
zSStIraZ2rJ9H6r_3EIc50g@p<x9?AdaR3Ljw?IqMe?Ld0?^n}b>K7`=R_agV0NG_p
z&_B}ar?lp&Fb?2=-uci^DDzCOxMg1Q_xa<Mn$tKy=Tu`fSE-Ll%Y>r;c;d&p{%HC8
zR2T;+gzjeOD3te8wadHY@AD@pwWo1_?D8aNug~9)l>FTOJ{86R3ZT6iS_);KX&1Nb
zOa4ChP^JDf4$yg867=Wy_es}06~+Myp!WpmCzSbV+GSqq^D*Z#&7;QwvQOvNT%$Ke
zCBz?rKA$*u87<$R3gZBIuz@^idMm~HOv7;5SL^$g`g{r}D(!&A0lF%ZW(Tor0R09x
zTvOn#2U1}iARl&60A0xz4nHH(C#czi6bBUMDQ$tq0W8y#W($$E!5*N0DvSeIpnU<f
zB>f*_+Qsz+Qk`HsN~u4M1N59}nEont_6XDoaqco)N5K1ja4L)gSYQJdXi9caR;ld=
zq&lI(th56f2dF+PX?CEyP8dN`;I0!=VI05#J1B>)WD9RH9pm~0sZOXkR%r_~4$yyg
z(rh82Iw2MGPla)SN@!mWElK}N&e8S-x0<qZaHy%{IHtb~{~rd_0MA1IU{y^07dF?2
ze9ndiflz%g;B!*1jms1AHMf+j%@W@dYE}v1S>KTGm(8*6z<re;bHy{*NoyllV7mYv
z?6WgmURMxz!}oF6Pirw|j;H+|!QQL!{dD9E-<uXRhD;N2%slM-=BV&KCuJbyYZQ*J
z#czQ;`Yjmp;{QWUV{$6NV>@^`3*T>MJP7wP<9i60ol%b`G4>H~hsfjRe8!^>zY~wO
zz#8y4II=v3D_4<9!DsPsnUPQV7<n$2g2z5^GXs3=JA>IJ>1M|FXf7q2%$uaN$>+%?
z+4*W#mat8#_zhh)dD<xPxCI>Mf)~LiHF%V4vhD<>O|B)I99bT9+vHzHseGHkqZix=
zHhFG*n_Of%Nbr-L1&m84>~;chDNr~WHp$K}54alKUYE1TT4XKrxNK!bmQshO%x5j}
z75j=jHjBqrYH<|%rcIs7eW*~DaT}G7xuOVr$D<r&VS577F*_qvSKq>XWj6LLIg<93
zGw+LqEa=!=>}S5N9L{c<;8)GqXM@ASu}#5HeN$r#+h2hF_f8V_`<t2@Tp?V8{ICW4
zP52SVyPD?*>Ra#w`9g`On#qhOGY;DyI2yPM#}7vGWG%9|OB}XRx5wx9If`vQhs|d3
zxvYMFnax`2DVFi1c_=qeKNZp)pC@@<+NUTrZvfZk^8}lbge<lcm)b3Eh-`7VtnOkT
zw6;53#TK{4?s8Z>vb<;>%AFVA2x<Nbvzvr8uRc+!`R~DXR}@dyQoGgWD7Cwa{4THC
z>nXLB*~&atkJslZF1D7)dD1$Ro2T~@)I6_HnV0KvjlRgd*h(E1SE<is^E*6lueGGi
z;zA~DZf}vzXLY;%vb<;>%AJ>M63k2GNlN>j1G_QJjIiI5V!yi>DwH~kN-Z{biQijd
zv6T9Kt|E`c;_=IM(L9tpFXxVs{p#^qfs>Uy9f9<<Me*cwm3Yc*4!^zF=P&ZQOYC;P
z*IMdwdHuy6S5c8n^AfE?xp_Ktgm}_Z&K;*H%f{YhPv=M2lf4N1_)G02{t}P1q!jen
z9ll~mk=O5YSo{{bJ!u}w%~J*kPjcU$X;J3oJd`g>WL`?Gc9+Lr?6>=nAvbbR=J8pr
zR+N5+-BMyNm1(YdD0g1YNwA#vspRD$T%$HRFJ5n{)on#iN_{qqwajgY(<&(|b2*AB
ze-U}nIFvgt4<wkE6-7#2YH*FtsJz%L?jpOtsK{H4qG<6ImlPvAeuvd!FZElB%j9{{
zI+Qyv^AgO<2CLGqoC-VbiOh?`<|{*K@p{S-ETRUncwK%=sm1QGxV`o=pWLr#9?G4U
zQjYSXCuY>+S2~N8ntuhZD`rLb6-TMn<@UL~4ttTi6z;doZL|7pWj>d^#BMEiTV$GR
z9?H$r7YS-!V^ikkbzCDDl^37Gju_EjR_3sjd3_~CMMV}1yo=52DssWm$n&CgD0g07
zO)xJ7CCa?4!8N)f^Wt(_%dAB{Uy;>PW^<LeP!#PxtGC!&T<Z5D%9rIu^HA=*bSIdX
zoho@5z%}}!^5S#(U3PB?#df8(B3qH$U*zy2VlB0om3nRRy33_?D0g1^6U<AGU8zem
zu3?%TQC_@`5}U_vMeC~AVRsd~t;J<Uc9+-gb@@<%S>-mSc_?>Y8WYURwo;ZCdAs^{
z_$EtaUVLu9-CpeWmH9p1G9P?@sn1(d>h`+JO5B#x61l(EJd`^xH;s^wOe99VQtV&c
z;9xva|Ia}{B~XR-c{k%p>Jw`YHMLHi>cL8#&D6t1U0Oolth1$QL9@qKF7$C}9)N4p
zI2bl6AJ!);^*s~{eFTwh>MWr@mL-8MAk`z&g=2k<)X&OdG1dpYvP_w`&yUCRY1M)~
z^X5(JcZ!!i=@{<(y^nN6_pLM^LHm^X+aVk~l)p<w?W(7;{Jo5Pj|0{MwcsKcnLqj3
zs-C8XhNecR*A;SwHH+RQ<bjI4@-x&wMEx}v$}}P^sDD`A=S^Dp#k6Lg%F_BOj-j-!
z1I|UhYA=Y;B34=@exZRZxzb)-i|mRg&1cGZkCo=%ifLY2&eFUP*FOfJu>mvkTs<dd
zn#Hwi#s2Rho>gB@`2XyE51bv-`Tk9l5EZ&h5JYX+Xb`nD*ha7jf{>*_O1Qh(y~!?{
z-D~%*EP^dTO0Xp~G&I#9G*~306}pHvCD;-b6}r_R{x1zpHR|`g=ggToGv~~`XJ+T_
zWWS%^{d{Kc&bjmFywCf*?>X;#&Ya;%H0!;$N$VW0mLfE6(Ot{JN1wkhVPheLMH!CU
zLDK1WQ8o@`e0;=R9Tc;?T{*sQW#b}Nn$Ieqgl}%IJmrI3pK+1G!W#T`I~JG4xB*Z7
zVV}4o^f2UbRS(agp54*u!7pteMi2hif?UK?6Foex(E}e7=zTrBW!b}`BUC-?k8z5&
z9|y7r%W4Cdgs^izZS>@d0d%r28<XK}lCTXv-W6OY+}DS<4WW}UN2)rx<@@O8OpH<|
z8cO$2Ct0r;KqqaGRkWi*Cw#o8_jPi;wN`TL(Of4JAjeQ_Ct#a_F{sX*I!QM+RHd4l
z8X8$E5WqtC7^CRX$gL=+Sn`6(x>~gQ7>G$uschmMwxHMNbD%6-H~*?;@wHB0vkbbC
zpScqpimT1L#p2MaV^j{+qVH06S}wcJgJS$=Q4#MpHyTA>TX4j`-F9<Hets`*E?sJI
zDKSpv(kl4P_BgoYo`tnJ@+X=a2H=eR{9oLh5pCGm6I9Op6#bu~)1&b}n)W}^Hq7t(
zA=)s%OKJUHi00Ps`cze8zau|KC^!^Xydc`Jw(%;5j-YrU4i1HD6|(8Zj?m3oT)#_c
zX%u~J1NbBPnZ&rcB-*eQC#zhVgf=X3MhyPQyoK;ndcNIIG&Kys8TpyUxH)sT)$b`f
zMdi$2;D6EqI1@g#ptWnC<{|uDe25hOg1uL5<F-wHPEv3yuDr_w7Pn^oSmo9}@JC(o
zam&BW2+xMzp;x|Y9>9Oe&tJyPG0}hOJWb_TfB3KRN#<={c-3nifxBG^fAQYoRg|?2
zz$N)v&bYZG+QN~OR4xsGzv_sNOPaopMUX(Nwd5dGmb-)_RhA2CO(0wop5-o7ZR563
zem+!iE3SOEXbaoURJpYp<5wj=iOf%BflsTX&@D=q8}$yo@>TNy{!4!DG;WTGws7ra
zm1F<Jn973qI2NdNiJezb);0i_<Y!pp=2D|Ij=k_~&Lw)*iRPk=#C8?h!h$n>{Z*E!
z8ly*N`O(;~&%*u1I3_(?O7kw3^5;jJr_|N5nOAt;)iu8<bB-#<@vw>VpmK<2+D{bm
zJL+UQ4l<5CbH~TZbIBw0QkvxQ;87v=j2FaD+>UmnEvq~l%VL>iCXC;YOb%RL^Kr&=
z2I1G6rFj_ioElAD`vohjYN*eoTIg9*dCu8@3RQ+>=(BeOl|f+cCx-YP_a~j;OY?Ed
z@(Ai7I3{FS%F5ibi1}snEm@AhmAAq+8e28=+U+k3?;K?a_9@L%r=}W5k5-C|IaDEW
zh%i3gvfr_l9OFY!A9@z>U~C&<KV@f0_FGk1Rg<bt;(^3uO+!-#6USJ=nA-Xb=2lH>
zu57HfzKrqvT(VJt-?r?zwsd7<3J-<jL-iDMD>qp61YHsXv0?Z&aVGIut|y#_+1$!Y
zbIiUp=Yc%8lInY@h3n!e99Ox%-@;Buu=)ySjvk$*%HkkEVvN5$XOikY#j5wXDqe4T
zCX{%(3${koyW3rFc~*oxi_r2Gmnvnr46EA+`bYUVw&k4*Np%zR9@lH?HW5T9nk;d(
zDdSf+0TW@Vo%l$$Z&E*b-XqoTZx(i&syTKvPld3<G`z$$z^>fCem((ExS?DK7U}g!
zO{SR4gq*@3%9s>PRWUgSeli^?CVov5O>zr^iU0M2U~-1kMi3_NT0AM4red-b__YPb
z#G<q|Y}5Cogb`#zrYBbog3oU~oDukx*Qod$hhy8L#z&*(2=K{z)gbsB=)p(K;hkKo
z;xin_cKYMvp1{|$xzv|NcQJGSvV#v6HRq~WJd0zyqr*a@Pu9#a6AFrj|HaI)c-(`9
zn7`V3o{Gf*@IeJ<`?im|>i5L_;clb8q&Y6~oMQ5~0+)GpDlWI8|5*|#E*j0coJj~=
zvR=|07kOSU;c}xj?p9r|;&LO!yg6|(o2B8qrc|%YtrbMv{OcN|O_1l;k}gF~Z&X^<
z<qhZ?r{mD2f8I4*$5!^Vc~EEc)it+Gd5$aTQ_Ru%=zLY5e}~U%i$kC8eCKAV!)U5#
zt~Ys}sq9miHK}^L3vF<FM0(RS39K`s4FN(#gMQcN12(~Ys^7JGqpm@GsyyFQ_NlX*
zRb8G6U3SKy%WzK0PX&2bXY|!Iw@rD@rR-D7W~lmXg-`8{L!agjD>fZQQ$=&V$@3mb
zZ}(aK)Zz<Oz5Scwnsai+HBM(Cd{7g_TZO-ipFxJdV(-;Eh_99BACiv6yobRTt2#c0
zVzl^l?C-+DE2WpzoUf{z+p;_dP;OJ#&Q$fhBW$@mK0UkL+-9%aD64C(PkA1m?3+6-
zRrR?W>^2>pJ~i#1rKDb+3#aydb5LcosCN+G{Ea8CD17sxR#nFvaBN$AIu7mNvM42_
zZ_aW>Z4;cYs+-%gJSR=|%`KO!dj2=^f$j0>Igqo<qKRJ8ZIsnD*QY!$jPxn;-fdT?
z`g{jD!A^gD`jazU)(7JOQD4#=mwO<qJSHu0Su{(<<td5-qsB!;NS3T&`OI**_+Qc-
zmpdV=jLQesxb&(kRa`n?{{>0kILlv%9F3!9Y(O;XIne3Jh0QUV=b0}hFzUWa#b^|G
zR+0ydG`fxkqpTM;$7q1ZzW!+OsQYRaqffxOa(|56jx)5ciQ+Qm^8eFgN4EU4Rry~9
zpVCptuhE_3Q_SV}zl^#3D?K(M<|l0WnJWKYi1FG?<?o4!qs4Kf(36XqW3emblYOed
zV$iiJ7WFu`Jt8bLdUW}SKv-nGm^l_z9xTM%!i5$VwEiE>kE1!s)4-ule=L*<ul9T{
zX<lrQ7{@yg_DsuXmCoUMf=RRar3h~lU(rs5)b<(8gT0i^hZS|AZ}sEMccgjI@?2Qz
zznv@ms8uJt)`QKh{}I0L!=%CzxlYaXwdXgdk~OKyG$!b}7Q4dq+*D(IWnFS=V=9$Q
zH(=`fg|rr8I@MU2X=pr*>Sa2=@8@hyK|Tjvto3*kD{IKq;7v~~j<D*z`Z|uKJoo%3
z&~vL?Z}&XSrgW+bFQH0Kug%m>tIS}saa}{hdClo$rgBPM%IBq3I4+rKtgLUsNmz?3
zU0K^W@_++rEn^|#S!W9w>0A9cYjBbtCQ1H`WTc7Ud_Bh6`s!2*lkr$f#);Q+8R?ma
zf!Mae_8|z}uFA+K;yIPtkMwCe&%BF0x4>~HjL)&&bu;1ye*dC=bS<n8iSNDkhAr{?
zi}#)wyz53_H3DbzdJQ6hluyx-^o+;16Qc{e2avDp$JU@Mz_G(|rtp0<m%9eXZDRH2
z^VZ>3*!q^ORL*>ZotI~r3Yj`AnXq&#^A9`X`+7{sEt|q@P{@??Wit-cj!d|W=Huv}
z<{e*$gM=J1)^pobtg9e%+Fh@lFOJdGD=5}e0$}|%>!0Yc9{F=FlZ<sI<nO9-Vg18g
zFL}|)WP<feK3K2N)N3Y=EvR<YE9VPa!q)3zpL)%^QRTom=%UPBubeMm(ba1<IT7XK
z*jpOE3wvwB|HlR3!0}l)P<N9m(+;?Hd&-4%&KITVWD3gbApvB%nfYlwuLsOkd7Z$u
zi>A3`%K1_golGXY{>Fzt^ELH47RQ#m>y`5bC1LAzj8DBr-K^quJC1Gj)+@)$M#9!>
zzE8bYY3g+bj&1kUE7yxd!q)3_pL#90MYWlO!LKfNy>h+;L|3n%e&C=0HZzyS>Ux_g
z{e{Yb&mez!t;=R|zOX|l6E36qxZB-sAFMky^?DM=wtDK7>*X6^>-B_By=vyEcs+<?
z+uilb`67+5^?JakUWr@Pdi@>8c6sWR>!lcB>-CmTz2<4^H66zmoa^FO&KF#Styi5-
zz3OgLZFv@Ks?1%loG+`;)hlTGcX<F?-dWR!{@jX7x_-%JIvQ3t7#qbJH=w<2KaXLp
zn|W<bOt*c*X1rc<W%aquO&J8cEwy+;lwv4))=vF6@pTb?<nJ2Bs?E(Q_O4;jA#o>L
zXTPd4U7Nvb&KITV8Wi&(w6Tt-rJeb@{DbVWhN)AVQuec{Us{+?x?RQmXYjWLbunP>
zpOFujRi$ja8}`_77rFQqcc{3pMSnLP2k!1f+y5D?g<mOMpkjRo{7`2^SZh*`EUm2_
zLXUi2vzy?Xi(hH~wTk%!U|upk8ov?<^KgE}?-qPK-VOU^<5!0LM#cRi_?5Oea5wiW
zeG2RUS#9V1g(}vcgX7%+uns@M6U4iOzl)CSar>BWiFIA?R`EX)TraOT_c7s-(c<s#
zX~N$~r-Io1jp#qlyGPZ*_OOBW_;ld*I{(LT7rtlcy(;dzfcpgvk#S$+lPxfNb?&OW
zq1{}3&;0vT{6EFOYdSvsL;IdAir%b!&ydBc4mKcP&>5c&0{Nc4hWnjXzo*;6eKB$i
z1F`)U+x^HHl%#!qk3ToVMVl1YUr<?Jg+cU&WIdK&!w7m)6Y4?!0biPrlUJdfh<ARa
zkZsldoKv!F_mE#bKVsQ5%4b0%&sp?HHt!tCyDhyfen6FNKJ2ACjBGt=SADc+sypxe
zMj_vv2UYpD1}{4sL+CDtd>ZwM#?e=Urt*2`Cf;J{Z*n`AZyfl$6*kI~z6Wl$H~Grv
z_D6ZJHIp2scdnt3XXHbwJgdORf=mSRXcS~(UncT+=MLUx=_m29D$nld3#U!x$-%iC
z^NzJ1(X_whodYOjTCI_38f5B>NG6S%jO@rnPu{tFr&@Z-Ji_%<2K%A8PlsYV78AZo
znkC+4pD%|sC9BTEX~uEbVYt4SpF_EN%HzwqeVVg#x>dgcOL+ZY+HCIJ9{4^1=eGu^
zUt@}9nDOa+!~wdW`f=JsnnSd|R7a|hm@oE`Ri9%qPm88|9EtDW?*qRh*T+34uBx#i
zoxCX3*pNb_oa_EH?~3k^?gKF5^RB3_R9=ejjqH8cbq!UObtx*Rb!6##0DBL3b*id%
zIwlIH8!%@O=kzZeg!-<>whG4#zkunKjgL^f&+pNcX-M-mI!R73kFs?s$DQ7PPW>8^
zmF7{F&oJhNwVr5oZ4=G?!}+E@-#d>|)M?10`Z}cp*C|zRRVj3xM9kmu7_ZZ<kdNkI
z&Bb;d{C1mMCpRDZ&^X;xOqk?dN;IAsp+jnO)sOSe>~j2g6)+GszAZR931yt4RlvNk
zumbznuw&AVsS9cwnwyg17L3zm1Ak$^%M(cX*dE#Mqio!d&*vl?fE%{Ts+t>V;n`$W
z9rc2V(_dM>B>g*8SF?wM(=8IGdrMbQM*-B+Qq{%yZKAKA0*B2-U!Pd|8uGZRuQw?E
zxG)BNMbUfgp^nx-_RU2{w*OnM>S#Xoi6YXGrccDWuG)-q<l~8|K~WoKVo$dKgUv-(
zw*Pxl)z!(UXWK>5*i#@~h4X)Yx8S)sRb9sZ@5IeWU$+12Q1vx~`d}Bwpf7X(mp2`q
zzZv;IG48hNDXyd2(Ep(4pl-(24K5YTG}lr1P&bGd41X6t<1+PyA8KstX9eURd%rKZ
zg*9F}`x#YlM}S|Q@#)RqBSx<}W4}0BV{>uoPPAjC&#JoHj@q$HVzW87cZ^YA-`R|8
zP58*}KdSoLncA^SBh#0r&9RiwtK+k32gKAz?zkD*nedT|SE_pZ1mn5|m&K;H&^|H?
zLHwFGV;}h*F!A>F<Mxr0pHp@BFXU4?<I`OrADK^meX7Y##ig&4tz5_W=efQ<L;sO-
ztsh~dymDKsudN~4#h9-<<;yrrd1Cd$^V^h1F2j$y{4&M0-uyBhUqr`ao6xVOp{|<3
zZ^}paFRTE^#-ZNd!*7TFl+}~vscE0*`e-zoA5VEWIltUx$@@bbOXGJxz?Os^b@1zm
z=Nk;)12v6J<|kikG8W=}*V8$c4q8@m9UNrUiE@yGQK!V^E*<2mlW2JGDlPtufoZ+G
z?{Yf9s@Eo~UW6-QMRCSf7@sJY>!pm*;O2PvUW^k^9Vl<Ae%#|8-*}!=zr(7-nin`W
zTjK%)vC%umRv~BDD%ZiCJN5U~L<w!^qJP&7OZZUkj6}j~#VV(#upmM*b74Bg_^!%C
zB@W*QVUGq$CiF`tS&FERk9P>!mb|FS_B>>3>m#xeFZ^U{dx^_N`Wk?Z`12>owxEy5
zMi1%u$yV2?%C-Wswf7O(nzP6@?k_4QpM-23eMGinSR1Rix8j#o*`9`Moqa^M?X&1D
z@ro*22W0E&BeFqlzV^0OBio-LTX!Fk?ffjVEnBVX?NP*Ji7Q-fzx+<ZaP6C>W1H{x
zZSJe8Y)c_qK_8JVTl<#&E0;}f-yVT%MSVoJZ0+0l*HqaahHNE$M7C`0+lVzPCm)1t
zWqm}pZ0*~C*Hzgbf^6k|M7C`0TbD+*cF0!IM`X*^zAgWos<$POE!{_C)3tA6KJbD!
zRM{Q|7_DJs>q&lF8^z_G8%B8uzc^0FIBTscV>@JQ>tizN+B+d*&6`|CxxKp|GA`(2
zGV0nrA>;VBR2dgT#`ZoYqptlEGM4;Z<?6kVv7?X4sA~s>j6=Fq8Gj2IJNuZ7y7o}W
zxKShHeUP!MkI9HCD{-HYaqT};JwAXFy8D=n+1kgBw^bR75ZfkZg^2%hw2zt)P~?n#
zvYgShj|=~)%D5Y3Ea+o0W@{g3uj4Yx?c=VHv8a#9n5})Rdq<UVXUJI6$7IabK9;|$
za&-t~EbC)3W@{fuy{F1J6f&0gF&VS9k3-k1GVTZ&EBcs>+1kfV8X1Q{#&jQ(QP)0-
zxu~N);CiI7WqMBRhuE$LD6Rf7_MzuoYATzOQ|l_H@pjf^4B7j93yrPvXHupnXq;QD
zx0U`-#cdY2(HRGB;WE~mM=h<4HT6~;=-61S33lFRO}yB>YmGTC_(;X>b>w4;uJrAb
z<&Sgj*(>2jutVbIeeT1Hm$1<_AFFuH!+gMWM0jcXt&9lTq5R07#c+sbI-kP(42Bms
zVWUGnRdE{++&bdGEu4+|sfN#ObD%S}QSb8*UhIU8j_p>lYl4jyTosLt`U$4xoVktq
zT{bjc-e(iMc!{~ovp-Yu`WRfR2!L0P@KWQiMR=)2&Bs#1-^B}}sl9ri6Yydv)_dyw
zT*Yt<IM*H@hW=I?9gN1d>z%Xj#ZmaZ!5dT@3&6$1)#kPvUOX)q-4-1F;$8|GW9OYe
z@5N5oarqZ2b~}NC<<ViM@lh5ay*j7eX*^8r*gKcqi=nXNd0(m+uE%`K1@U1R+K#g*
zD>N6q^UA$A3Oio?ZxzRG%Fo7!V<0=u2X@{$-d^mUv|^0buQ+y-@I|r9kMaE);<K{Z
zzCO^OBjKWg(W7gduwn;)`xPzTVb5^I!X@c+3cIwpS5*UEkkypI(gvs|^JkOjALZlB
z=dHkR^4eZBhFXKNS0LYne)etHdJ8na`}eH8vMSSzTCmx*e0`A?{Kn^VTU`a~H@aRc
zep?2vP3Tvbs-Kpj%cE|5JqEruJEn{$As}IcOXC$|?DrxZ=lY#3Swg?^ds4oI|6ZS(
zLFZ#?FnGewr7792bLj<X(;6!=t(VENhxd2sT!`qtuBTp<TXx-7su#%x7w`UEx;M><
zUjtj52~M@*xM4qI9Ab4M{<-QrqqaJQGFrQ0Z~He(R_ix0XI^l1<ku=!m!m=@*G9}$
zjX|<NkK)%na#dcdO>p&hkWa_e`&s$_=W0*5Itx4<0Zz4oe}m^l!_}uPzq<At&efmb
zYiC@4BEBDoQ5Rhwf~!602ZmrQ^>a*otGxD};OkQ63sv8G7c1BEl|Os*|9xvN-&z8$
zt^u!zuU~T>_1L!xzRvkpe_S<@komeV8jFITN6%M{dlen~P#)Hluku=og0I6_o3HY<
zkd^;`zV^hwc7dz2!K+sA>SNBM9`jW^6E>tj=c_!<{XTV!=DPUGpH-V)*-|^bd3v&`
zc3M4N$;#iL!~2jpL-TPzJGBRn@IHeh>M`G^9tGNZ)YeB`4-t<qAHeY#WJ$9nzT4n)
zi`?~)=kMoltiUIu7A`y>mr!5X*w`>5S>Ie&CpyBAkL=zO*Ym~oNBu{E&)R`1KG(v=
zOX9#s8|=_~nnJy@ipSR)h)nPiV<+8PsQA2z2B|C#eB9A<q_i=?L~y2Hkc!EIV&u3Y
z!bH;!vM@uN84O`le%JRUOhB6|*-FKy9QahkfloM_3Jj46e}qkq{kDqFC9tV<9Qc^q
zR9-L<YigvoRx#NC&a?)=Bz!m&#InNQrKk2Ku$n(u#p)>Vr!79L{H-hxaGBVe@YTz=
zQL!2VUM+|ZE4RhPgpc6T`fXKwb_JK(qr*qzH!Puhb-YH?5i)Go1Xe=|RIIuYTXe*S
zRcO1*q7+{@6~yjF6{=W$u_xwt#fMcOyUQ0oM_GBm#TGu*;NSpkRoK1+m%7~e@HiD|
zh$gIPQ#*~`3Y$B=p>?Gx-V^IeQ@kVYTe=<B%LM#RYhIjy?JL~3;$}^JthsL~j#ocC
zuA=*v;YYD%5UpWfgnjQC_G10B<=gYRY``(Jw$G>7E+dY(>(WPKQw|=6L6TD&8>aIG
zRx);!O18uXg&?#0<BU_$*i!@W5Nl{rZi>d7{_|ZbYfLpY*D*fOSV<Ymzk%Oo<ya0T
z)!10yfHLtO0luzLs-E~pd=Nfu><+39W>9|b7cM^Zjt>02S@>8lyBb)oz(fy~Ebo`8
zscqu#9EeH}qMy>SqpF8jpwIGoG3deVDPzZeCF6DU*b6^2cBqQ|wdf<Z-5L${nzp1D
z<N53cVCsi10Ur7EL#uXHb#N^1*?C(GItb^7{M5|*Q`yyE?1v7?lOBX08n>&ehZO9u
zV15jGF!w{fg8hU%`JrvCwU^fn<Jf<JHk$fF-PpRI@ABKtu@4_k_GS(wyD^yhq~{{C
z1-#l0zRl?yZD;AD?z^f!4g?3<?ubnv{+=nk;v@A>dq!j<UY&^k>W1A_oqU_xiC@L0
z6StSzO!V;ep3$_|UOfn3HS2q-9tKl8@$1O+pz-N(<c*^7Ro@`Sj-vnM)ras^L-$nm
z@fPk`erIg@2<@w~C_YkO^<tiMB7D_?VpS&}z%JW<6Pr!~`KsR1!yCXPAGRUJ+lG9f
z>tPALDCb4r7vi3s3(fTqCI}AFqY86<%NQCPs#5lQjkD!4woME!g!qZ-MNDqwh6Wby
z!2d5EfAWDP^c$58w95|oktqA(9(E3nJAkDC>9}{CvO~miuR3K1i?U~(vV%m~Qm1T`
zD7(ukqsORO?n=#p^)FlqyIQnY|HNN#%r<v%StvI~6{Cb0=HwjHl5V8=JS^8m^N;DA
z0`TC?eu>2CcRS~h(6q_<G&+7Uu0I&ZKabz;l8!IKzV04kPO^CRV9wqu=cXfv)Os(w
zw^+x!59ifv+U1O01@DI3&v7U2JiD0v@8aE3yUgL;T~3+JyPKUdn|D__Wj61coidwu
zDW}Zl-Dysli+ApvU;o0P;6oAgO1yi5>(PGysE!lFBRXd`&LQ4y@!Q<IE5@<2uo3T0
zla9~DJMrA<#(h=Zy@-BU$pbO)&fVHX;o^+Bw&Ed&Yt8(B7uQmDnZvcyoHCnh$2es+
z*A8;ZY_1J=%51Lf;FQ^18|aj|xaQ7r_AhJ$2j)PR#I@;McR9I6=WM_^#I;8s%+0kn
z9NUeJxHhoeIX)NHM7vt|1C?u6AQtO-I2x{L`X9ZSH?<vHu6%^>Z<$9O&JE}PyEwOl
zUFL9Zpi^dZ?u(`DI@H$MoO{P9vpM&wQ)YASS*OhA+)}5^#W{CQw}0U#a3KMm66bb%
z#Nk7>c9qVl!8ydasY{%5{Myw4IJO!aac-$}d@jz3c6D8e%DE%KxwgmHy?flQ2I8E5
zgp<wJ`Q5_Xoip}z#gB8`sa<{b_w0Wc@1C{G9NsN;%52`<<&@dHyV)tTd3U8#X7jGu
zDYJQ(a>`u1bLX)87pB377U-3D_X5{rPG3jobm1K0-HyM@&AXX6b}csIT}nDW7w<&7
zTK+?ocazbsmMxEgcjoPC<Xl_*2Zw7{^8a02YqrZAuBDtZn`@^zWj5E2amsA29pseR
zTpR9`*<9PfDRXhnowM&>xE>r>cOd85C0utoxkl%VhyICce|#c0*Vg0u<8VB2ZHFhF
z<8yIMjKOps#JRQ%Ulgy>_iFgK?hbRVg-=5UiCV+o#p~=$+t}GF9R8K^|6TkWVV61l
z8|swV{2Szy+5Fr147)b9yEgyUJ7qTi);MK0|5iF>F8;a4DEb#p1TU(gU-EVPJ>_sC
zTN_K~tin0OzYCvs&hcwwYjEsJY{b8n(($?YC)OXBSgP`GBz)b1XW6}t+Su^S(DKi}
zr44^0F9nU;+tNRC9Z-9_ekJ?g#lbapnZv=APMOWYWlovR!9`A)&B1w2na#o3PMOWY
z7N^X`LHC$U|H9Sa#`;4z2jAp6&FKT_oO1AjIJozpa&zz_Tz@={Cl0nq$LHdp=;y5(
zt#WW6d|>%=v2oDd>c+sk^)EQQo5%lm@ou(V=J2k?DYJQ3<CNLFo8*+)yc_3~*}N-t
z%52_^aLQb~bB{swFPsEER6wuf`>x}9%*i`CXC=-d-o5^OZr)Yn*cI4_cOzCg$LHdm
zXnV&Wrt)qJ_`bwTk?~H`C$q@ZtMj4Lf#chGFFX7j$NzWnuhcGc_&35Sv-vmFDYN-E
z$SJe=xA8CRe$*b@{9Eso+5B7Ml)3ol9&_to*a=>Ajp6(|jO#Ne|LB}?-~{pSXPpk8
z{Mz1ixc*oiPyAaW9iNMTqV4TGLgn9U7^iA~B{u$rZhNy3J#^bU?lp&l8~-Z!;f!6Z
zx62$3u5rq24z6^{Yz{7S%4`lUa>{HD&U4Ca4$gMUTpV<dG4?Mk2REvrWAcF?bDieo
zAf2-c=MV>f^lEMn*5KHc*ocF(rQ>sPP_(_{j#4@J&YqYfz9u#f25Nir!MlxbIJ{fL
z|9APmd3Kq@yV*{e&AS$-%;sH<Q)csSl2c~$Zk$tQ^RCn>bMfvC=*t;XMV}9RSbHSr
z-R)eDIeACtj0G2nckjQRn|EEfei@D@-j)8%IX)NfrdZEJY_xc{3(lwK_i25U6ntO7
zn=anvde1D&5sw~?`SF>C#uR4US7vg*50&Q0(=!tzr8xmqR)DfW+Yy%hIyBBVRXoFS
zG`ADEzC&<+NwE5g#@}0I7LVZenve600M%K3Kdz{A<F4*H3yjB&<#nd{g#)qCn$=TK
z=kj26wlHq0yg&eq>rf1jFU`kY-^mijgr}(6I!)aQacnwR-5fln>Y3JUpr>wPtYg@*
z9JeA!M>(0@vCW2!wYlroJL9<_p83`+e#&&n8{#HBG2*QA4be0ow+<U1yYMgc+z%;U
zx6b#Z<5b+P#5j0I9Ju-SWU}S!O`$X9zdWw2!%pO!XOB~{`x|1B?l`b>x4^xMmpnGA
z!%Ns`$MGs&w;^Xx^p>mr2yLU9eg(53ZN@5ujrv_btc}X!dpg`ie{a(XDsCrHt|boK
z!r7=PbjCI+k5TEc6E-?>yoy~jY_v5F?96R6a=hem79Cz9zmh&l#p_dWtvvu<;Ztux
zEH(UH!rH4mR-nUB<Or6XtYUaLIM)>)hW=I?9gN1dE9bj)I10bFVS<WdA-GuZck}il
zym(qJx-B^T#k~|X#!k-J>aY`bTzZO%-B56_EIRBoKFR{5SM#L7`^Mi$F@z37VaKhf
zsu+Gq@lJdghPLA@$_mXzId`VRQP}bFAFDWiwkO6b<HIqK9p?i(Isc=>?lvoj(KeA|
zcR1oVifd`Y_x*^^I{mTp=SaAyVD#vwnucbqhRwUoJdZFG^-w=f3|fRA<u$x1k04~K
zK24SB9{8rBE?>VMP9}}wSU^Ba6NZ#YUhA1;y3^8A+3BiG^TF|S7@2y~t|*e3>q}l2
zSe9+r8LDhsQ;r}HvT0N%8WoM!%w?0;kR{o!xAeBol8y3olyBP-+k4<*!9RSt==L2E
z+7xcB`8YO3b^IslCh|J69E&G$9m#U60{@DlkVB)CY<8p(0!3~)R-$gQ9Jg5dnE4Y`
zj@{AcD>0QL54K|>&#tJWPM+~+s`5<3v1Jj-qft#xdohux$|KLimVQdl;_{5cMaW)`
z!$$2<xxYN&e7ApA&-QRl=hdc@^$m^F@!AI%WhRxh#>@c<$!MBW_O??(*5b*ktkh1m
zM=h&HiC+7PN>*?C^{A!SA!n<yQu|f#wyz)b*J~s;m|bF1-Fn+JA@6{5RC%dQOXope
zje0dU8jZZ(cJ6M`&RO!x?E|%Qo&NGh+RkN{&fHeL?VpfuMUv}NmXF%Mt|;WwC@^34
z>1`M9v-G#9LY0r&#cosiHY1z#wv|H0IhCr6)K(_`>Fa~s9L*u4MvZy1LvQ;jWK2)t
zGRpDXBk(%~{xbUe*&g;inN89=k*wB}FD!4~r+x_amis(H#)(y`jQ7FUR75SKMxk1}
z?17B;qTaHMqHj=Et;+bTJ<&G^BV!KUYPv#xywyl*uFpGAf1Ru&Q>v`nLidSvzIN%)
z*&MQJRGJrAxAAcI4$IFDn9609+mR2zfpULY-99LfHc5S2_2Z7K-uLiT$hB4@*GtfM
zMHF&rlorGeRhg*7E!T@4Zi;q)`7~8ud!Wroo641gk5Sm3iG1Jl#9KnX`8BG1=i=Db
zh~(3#F0j3s$XDx;?@P<xR@HL(hTtLtv2Bm-BIvr!U%o!{{u3URR^bgH$?Ap-;ba=O
z$n$q7&m-{Kbgqh51AJL~9C-PA`EXv4W%yViZ$oB^SEa|Fe_-*es7}S}CHTnBIPi+1
zrRV`h@;n`xQ{~fDjAp@JyCcF#<6~I!pdDe2eqN57PyuXEo}VM*)mpFObrkR_c*nOt
z6v$@<!YiB&`rX1B3v@$fYJ>8e9KuW3;KBwKud`u;C2`<oZi9KjNS=p77>PBGyV5E~
zuYptL0Wb>Rl?h^r;qRg)R{(pI=ikWK4Qo`f+YkIo$A_K2RYnY-scp)0Ze(9JzDdPy
z3-GQjKJ45U8WUdfJR6y7vok7QgTS@+=<w3`9Selsomb;-1OnKpJikW9Zbh?--5SiN
z>5LD%&~}<dNm@5&YNzs?8re=aT%cn2?w;tQ#fM!WJIxnf@;n+Dui_St*UjK9&6{b%
zMsa1qyV3N~G<ktY`?P-7SIEU53t@33dx#Bkx<5`Hr3^oK<4Q4KaMFb;UKCe$#(|f=
zRYnq5T96rI=8Y}I^9-#QshCl0+4f!x9CKS^EI9eam+cp;I8l6AzCIe9G`=NLTlBkr
zPi@f~UkY1XH&exn#h35LfLAzM3<{aCEqY^2VT*$=RWYL&voj9N%xy7mIQhky<1SNi
zqByhd19NVL?~=z9X9jE|y>X^kFMM{ZiXFw7<sZg|oxgR4SCXGwGqzE0tSS83@}H{s
zQLI_;QEd3REj32W{Nl}xm#dgjyxAEYW*Q$9bG#YQUcK?Au-DRADs~iawtXBK--2Qn
z+FrBVsK@r|jX8zA)?KOMM=@vlC$Zrd$X@e_nP1%5c@@WOBVsLzJO71^#hss;V-}|K
z9;9UrbA5$meBLc<6KF25`f=jUa{MUAowV+H8r)h1tUB@A0UR5)-U%(7LIb7VcLY#u
zFL+rxTg8}S)$;BbF!s0TC}B3nS&mf+=heV?6!0RP&*%8$#98#I=l)E^nZ>uC#elQh
z@?*hPj&BLuF~GGA7!kG)aZGYzE5`9RUZY}5F>&YT(O|3beS}${401M*{jT3rKOx7&
zgz-G!y8&1c#-DL)a$+p}M8zBxV-`nmhymkpej+H$#(qMMqY39tz<4t7V*Z%plM`p*
zCzfBQ;!Lr3`4=(ZZ0;xWhOHcX6SmdBbr~>XKA2;Y6I(GZJn{w=TNbZ>X^w69uqH^a
zBK%!?>NDhco$&4e)+2x$^UEBkoOp|vVL_XUH^um!|BelBf6oy;<i`F(j`0ce65u@_
z*fBrNvC4_L@Y92CR553Hf&avYx!a4xh_jp*Ae<Kh;{m{n`Du<%PMn1=X}L+onQ{r`
zUqyzq#;01~1?qX^06fcGdg@E$Tms=e7+7b38}r>9r<`~TU-Hph6>pY*_-|}@hxR2Q
zAUF0Ua{hrZp9#Fz13TuwIaWC_7rtcTEh^@ev*_Fu8|Hz0Nj`Cwa~6biH!v;-Ud(56
zd~)I})<&803yyOV{c_54oQaL)IsRvkbGG=xZ~Qw*k0i|Xef&qVs$u%{hI&4KJIpw{
z@WCtRskl+@qAd>G{JlXwpkw~P1Uos0A<ya9c&myX<s%BdiGg!&tBw^fIWIwY2^%f>
zrHU8j7}_GjOXI5uhd?cTHsJiOAC-;Dxdy^b*l68+6*rbQ!0I4aYT4-hDq-Z(`nGU3
z8WuWZ8<q11vW?EaUB!-a0c~+$XKtf;$4kx$5MJNzS5Sy1GtqU2iWkNA1^vvqmZP_<
zX-f0ZC(m-1sO(ja^9e)ouKN)SR17I*Z;KB@f2$3ztXwb}+pZkD%YLu=*D8)I4*ync
zTy$ITW`La>kIQzv=uQ<oimltC!%pL)@?ghV?vjguG{@Pbe<#P-vK@E-M#Yfg<%0f^
z@h^*X0bAc3T+DK#Tre8ju^czcc0BSf6-SDJ+v3A9kRA61c5*CC*oi)K``sM7pP{2i
z?_QXN@0q}^V1PLXv-SNn&19r~X20wEkuF1bhn!@)HPj(dKF&CP8o#;6@e2!EP)6k#
zujlJS*5Q4x$SstBgNuRXD*X0GjvdP_kbm$S-xvMw(nYEcnh+x=wunIo{w;YJHRn=;
zu^!|Yc}Kk8!A}oMpo3Asll1T?$1kTI#2EFGdsRLB1#MdQmNDqT?LlJ2UXHi3VLt}A
zw*y1M{_a5xvz*uqKUDf#75l3Z7j$hE4fYxz8>t`iyM8VMF!e)n?4C^r%YgqVU`aZ-
z<=bXD5Pqm*v8scyG)H6W7<3TM4~12Ou^*E20NL~~20B;{JV_5%4K~w*@IzxBQ1ws=
zKh&{J40<s4LwUzu&M9QWeg$wZ1%`zE1>2foFY*)f9^}~Xh;!+kUpruX9X8PZ9dqn+
zbd@z-mOR8YS?*%ulOVR{<MfSay(l?9LHZ~_+4<PyzL6a7Y;0Gt-5<Q}j1OCXFB4vg
zx!`5KMguO2-1y3Qi){D`|2_U;72hqv-R}7Cb$gG^08=@ikquMf4;DS5V!9PLTTl?0
zKhXHiJotkwcgaOq(`UKmJV!QcMILj|QWe|Rk^d-(58KfGpa<|8`vW=ukquwr4<<jV
z;``p7nEw(VzJdHfZ(u6tMY3Tk=3BHq#xXqs-g+Rm<FU~^fOG&%!vu5MY+Z=8qcq(D
z76&OlAf0NgO4avh4L5<=ie)Nh>{<IbF!Q(YFlzCI&D3Ygc@63-i8;m}{Z7T~CA2#w
zh34%}7=g4rb6ahg%k~&2IR`;F32qfVuHwYT{3F6i<Aa#JXmJW*kABzp1q}Yilv{Gn
zK*nt1auqWg@9&NSvvBqp7&cSP<oI5;$C*#4n6Wwk+eKrKegbKEW^Rvum-VHWDNb@M
zPB@7<pv#|Baia14_5e7A4->R#`B-K6yZC|^z&7RBS;lYEA5{EkY`<W8bDo8lOpBkt
zg@(V8FNCK2lVfAqx0O7l;zwip>G<$-TWgG%$+54@x%AU2W;B-H869RCKV$(BX!cwV
z@Uq;+mv8}WR*r9F{Mw&U@uPA4k|B}VY!=C)wb?8;@`cdUX65)*w%K(nRQ%ZZeSG)@
zve|rMCda2TW<&qTF`EJY(tLCp)22AII{;>3I`Ue!`LwWMuCJ1;F;!LDR4eA9kAR%&
z$H|+P;757Po-h+*jOBk)F=KPlcQCipFfwT|^KVtd+#(xnEM73d%^Qn~_nFRIsp7_B
z(H&#J&25>nVdWQ(w*OhhiaqBZ5mp*sLl^{VMYDnCcl~SxBmZy0FK;|5>~j5cDrOXq
zrgw^lUw$%0XqSGs$OfCSU3z0uVV6Tzskl*0S}-&Q+|2DVuUPrTr4wIJv0`y)0IYKK
zJ~gS;JoIt1+$9^?Ol{N~mx^()c`vH?QCwQSvpLry#?QY64S%C-5E|R7H#QZ1uJa`o
zLyAqi<HOKxwK3!77oQgVMa7Nc)3#kA<DSMR<-vBd+$9_FOl{X2p9<TZ__B&0i%)lr
z4ZqN~8xlfe+x5n%!glApqGHINvyKnLK(?E2+`MtBn9H{DRgT-E19+TD-)y{em^t^d
z^;b2`VWj<Gzw0aZ+EjZ{3b7~IYK<D8qJ+n&+a?CH=ioLJG5Hf>f0ebrU1DJ2!~Fl^
z@h2b19xtJ?JDsva=<-x{qf>UUD7)M#J4lo@I%Txn96NW4Q}#nq_Fbop!f1Bfklk55
zQI`Yk<6ii#U1l9uSeVA~a@<XG;@e;|9nk+u{PrH#ch>p9;+zdQ=LMYe#BLlT8kaA_
zzTZ50F&0>}M&%mC_Z54v>-6|JRzEI87)SWs!jEpod|S5{$5QZZxwX%@#s7El?MA1}
z=G)~?na#IGr_AQt6sOGQ+o?{O&7*CdGMjG$hTGh-k9(rnE_3ls&Q}n3Hi0)K-~jRM
zHLmlVe4}%!aSrkA{yjNHx%ei==vVzs<s0Qi%15y4^e*4rtw9)<*<+5a9?9_&99wMd
zGhfC3cX8};r_AP9qf=&cY>HE6bL>>7%;wlpPMOV}|LrTdbD+(!4f}{P$EV%zl({%2
z=Xr=@b>PZe=$$zBC$8t59HVnq;vC}G?R#^Ka&b(wpQUfA9HV?v*$>!tddx9RzaY}~
z)9?CzWHW6)R~*Q36kMBc?Gx87=l{F7*65VkT$|#Q*<3r-DYLnDlv8GN?Leo@=GrF*
z2wpi{TUR2=9IoB&l)1Pj=f{X^o#bDjf8yF>T;DmlM(2#eImET=_U9Po;+kkb7yVu3
z8s*_iMzQPkF4z1cglxVoDBX<P&n2ZCOTo7});{sAk^k@F+Z3nF=G&=Gna#JOoHCnl
z2Rdao-}Z3IY`(p9h~SpPx77!WGKX*1Ib|-s$$3TM+ZgaB4Gs|B?%_Jm$u~M@A<iMb
zU2+h|C>P&E`#Jb+m2Z^4EE>(O)4O~#Z$I<Kv4w|o`~=5lTKmMYDg1vI$4+(1Y>pk}
zl-V3R&?&Pywue(@b8I`O%;wmOhY3D899uC)lsO!`#3^%eOwPv=#}<PttN+0{_6x4(
zoE)Qb27xQYvFV3$jB;^I%z>V@PURToeGAIib&NO`J}st=417jQ!{4Q+ZRy;x98<x&
zI%}VJH<ADE;@w!M%;w!Fr_APEu~TOAZirK6^KO7sX7lb3M+=TQyjyydD06r>-6?bN
zPR?T!?+U=5@!$gawyU}BbMlVPX~j9jyR(nv80F%fm<N}5PvzZy@NJ1>*>&RJoqvlO
zJ@t&+)mbNSTm|<gTl>VlvHX7*_eMEoHus91GMjrtoHCnx1DrCOdmD}yoI23v-h)n=
z#i@aXca0OrIovzjDRXgePw06<zf4VS6JHx(Hu3IV&b=92|2erw=WN0`#J!V_;~3@Q
zp6JJ=-&eWE#u-jz*NKCB?$$L%zGccemV$5Nt$pI#DE_~TZ^cfT&9@;=na#HWPMOWO
z4HE=s4z&5U&MC9`_A95%=G)CDi*p^mo#d3c_$H5=kgpp6-%|<>kguCIp36(z@mq^R
zoKuH$h;N6T<eXE6{R}qU`zb^lyZ%F!Z-Zb1U8k_?M8P*rpUWaqpqURjh?nIqJ#AyF
zPv@8l-i@*LiFd{Pe;4nDIAu2P1~_Fl?>3yqu1n|Iyj$m#*}Plrl-azy!6~zOcjZKJ
zJ%@LPIb|;1$>UALp$z!b4lWSy&N!9Jn~QgJ&N`e!yxZ@`&N*e+_v4*tW2-+=c}L?~
zooBG?#KF7JZEOhY8Mm<$Cv#i{_eNU##JwT>e;4-#IAu2XHk`$-LC4wLTj!M7+*|FG
z+1y*<l-b<7%qg?E*L<e9hr_-7oH7^p<Z(LU-bdijNbrHUcibc{Z!Yf9ITbjExVPI+
zoO7~qPqeYCyH)Pdcwoob>^gC9FHjqsPri+v!m$*58)oej-v;piU3}Y6$&RNon{Vr!
zGMjI!oidwmE1WW$Z%dpqn{N$Hna#IUg}AT7x80mF7vJ81Zsk5*4R|vj93Z|Oat@a_
z7vJcdPMkx0+a~FplZ|g84?Oo@oNpZ%Kc#gk=$pn-+pE}hjQEx<appJh6eNNTbA6><
z&0Lrk<ERyoQ~kKdQA=w$j)H50tbO9zqH6XVcy)lyjd@O)&5hYk*@1LFI=96sJ3y4x
zIAx3*+v2!McG-_GmOHR;oV{Pl_Dk*kL)iWZd;egzzk|Jh5ZnKjy*~=|P{&ojYmJ58
ziBaSU{nCxK^_e8L)U;G%vIL7_?PB%wKn?bLYHDpuvMyCWEmOl{j&UeIf}dMiT@5dQ
z{k?F`k@%LcIkm2#GDA)x-9WdXOSAI{$l=4BYh#y{6Ckur=+~HPYOc#rxjbKe(w8cK
zX>4{uZ4CVNZ>6K8Fl(PH2ngll=J1GmH-|S)=ljINdFQGep6!&`9By&SY!25rWj2Q=
zIb}A7$Ju3^!=?5<=kN%7pL2Mqz0Wy3(B9`9{+#O+cIR+d9;@wZ92WWNg8!%-ehG0-
zTSE*ScDMGi@OEg%&D-@&4sU0tRo=EZWj1eXoHCoYlbkY}x8s~Lo42KQ8RzW?d!O@m
zsJ+j5JILPWy#0df4Ls$%ecRr5c)L={<@7b)ioQeVe^uVn7;<ZKG`!XHC5exLBJ*qn
z_Pc&h`woLHa`Si1g${pPE>QVf<CNL_o#d3+{2k|%+59ba%546Qu**1qhuZs`zk}?3
z&fkq(U*Id}?>qKB=kLq*zQbR6Ou4V|SHxO#|EKboJs)y$4Ezn(cL+*h<G#bj%iJ7Z
zY3)<rp=PGa;Ym)J&EauQna$x+r_AQ?2&c^E@KC#qb9j)w&pEu2>j<3X9A0nla}K|1
z?{f}6ZSOlAmdC048iz&SVSGOXZ1~9W+u3MaDt;ORht2yAdE@Q+E8V<ZX6+MiCta@c
zcAQgY^S0C}vw1thDYJPy)G4!hJIF5Myxqw40G@K*uDAC&Z`auSoVU-~`<%BA+xrf0
zC-mXIgUIa{58%9=H87Fb8T_Sh8b2?;+MKsJvhJGHLmqPbS?-dpACYEO>-|%7<U=U>
zc4Bm41->Wr>xbB#&+DE)$Ia_HYoB<1>1>tP=Q(9IuO~TWHm{Fy%4}XA=#<&K-rX+a
zydG@tb6$VR^=A9yE_<Kz`Z;@_^LmNB&w1SndF8S7xc%`Y)aOV0n&%_L*g;}TmDe;r
zUv_<Ly!P)|gf}2RYP0@DP;Sq;$<6J_);@8&{sxuXXE|jyx5qhUHn$IQ%4}}$;gs3j
z{*GP7xxI<&%J$js+WXvRciQ`$+rPK>Iky+u`wqAF+>Cs7P;QI<a_3emw`u&p<mTA8
z?e1}GCVZZGo14$$t$pJ2Ik%{MKG7+&`CRIh*?b=El-YdV&MC9`{0-L!_{;hHk-g7-
z^<V9M&gTw$pY!=Xd!O@puD$Q@S)Lov*L=0;gDe`X@|orr6wQx}&zgR29{M0z?&9aD
zX+C^VKVA20H?PN7`^4*$Z&!JJs8eS1dW2JE^LhuT%;xpCoHCo&pK`s}yk2YXb6)?^
z-sik-xA!@(Z?pF~uV>l&4zK082Yrp#q7O3bJ1Vc)`=5Rj8?Qt6K|)YFR3BvWA~&~3
zTKmN9!xyUD-q$I!xjob=v$;LcDYLo#IoAVte1OgEzuRTpXRosNIkz9R_c^y0*!!H@
z*Vy}<+ZlV`;kG=tp|5dU^g$+Wr*fO-M<nixjoX3xAic%s@ejKBJj~iBKL6miDxY_C
z%4|Lla>{Hzf5CAk?%I5Q+bOg8{E}V9`MliT=X}1~-sgO7v-dflFS7SJpR4VChtKld
ziN3~XF@`d0d(P)MpfIhsb~QG(-dejkpR<i|Xwnmrj-mKnU+H(usIA6S0p^=WKt}bG
zeXTWN|I3D`c(L*Rhho6Xzf}vP5<kd{F_Xu_X^w=*5qIsNV)hdHx#bVXfSKD{#)6YP
z_DVPjTP)Z~#fio<6OTlLlg9T)YKwl?_am0+`Y-ZWpFH<w>`)ai8b51~1Fvwl7!)#N
zTa?F^WLvD;S;g#Z*kZ+!7&vBbi+RIo0%RBS9|<QrHs3|Xi9KJp)EuYq>7XF96T{!7
zr*<jl%LzLX|E=Fu#g1~&9r0o3Z=KP@XKbT#PFD77!*)~gqdaH&(b%}>w$vCglk<ME
zy-xbBiW$qLJr)^e8Xsf<5oktG4)C(vrKk2P=ayu9owvJ+9eds+KI}r<YY6y^?N!cS
z$o9IbNX3tG0<Ftp<6a<p%_nAZj7*r_k|-#o*lYIpIA&W|ff$D06IapN^1t)N%;)*?
za9#M(qXAJSm8@!LW-o)HzNl3d&lisi<+_jEL#_MdVvMmyT6c|BSZ}@P@Gy11&BA@a
zo@(762JYp7>z>1pX##WMExi($U@z*wLR0@EQU8jl>#u>oC-uMH!oQ_h#s5R}jne-0
zciVC_bZ0)#Lv(A`;k&5w$l+?8JITLAQD+U#J~TI~^NkkH>oj%V6E@mrTIcBK9jM;(
z_foMw5A|LUQN1;A`_bB{-gjDfSAU<^dyvJVE%7}YcG>P<@4Wc)Ok-tzQ*8$CRY+zk
zr_`mWIwt-_$T4z+D#zKtzavsPG+OYGKCB#fTl(0jkz)z;(HU5dC=5ZB#zZGVmKA%e
zIvERDx}ugvqZZXT!pS1~J+1qwvU~*p-|a6;l>T3-yonw}-N)>!*8OD~`})0apUu4P
z8tikKgh}1+u<Ri*QmuP&G1f~mt$TjVz{ocV8CGaysDlhe5y_xYfeHPMWH{5(LwY~1
zhwVWd8gJSTTODk<#9xN0hUwGc&Z{dkm17tsMvu<Wcd{vi$3&;)_V4t(DYZ+d;XWeQ
zN6$1<hd+(Y`(AfZ*8xA^b=?KWP+fPxHVxM(?_pg{#-HT6QtWY#h2MNloyHG`9A<SA
z`t(A`bZAnqqj4{Rp<J)=`*W;@03&*ioAi4!j%|yeUbvLz<BZplZsmFj-JXwfuWnDU
za9mWv>)VcF=zRJ<6!UG{{p*`)u%Afgi(-@i8H)4N53ie;J6-ZP^N;NL>pl4YG=6PA
zyS=MZW{-Ujamwtm?`@nid+d7)r>unPLC<P`!)37NDQ&d(`Plbo_C6o`{=nYnW8eR@
z_xafOT6=#KdnURF_gMzNKcS!X05<lC3*!APs}E4^hQ^fJcwPJWGyU`+f3m8wDV3yo
zti%BmyJ=u}@wKxED>3Fb;D;(!G@jfZ2Uh-BH}bdIK?(R^O{8zN+!W}$;WEa{JC^)`
zWw#?nsd&*?a%UWPnfGq;f{}L|S=isigH()Y9JxCpj5PfOrf@AmLPU9f*XQ|fH=#`J
z&pU=J>~Ge=DpoXxT(I1?PutL(NjGPb>BfetR8vz!BkPoCW#=7~q;*1Nb!9q};)m-;
z48qx85V(x(&pUoB>~GN_Dqb{xToMOf=JuBtjJ#vV;+-m8r7A`=c3d6+qwwK|mWe)A
z82&Cju|@B=u^4k7Hd@7v#*NeQ;pT6V(L!fzm)<dB;m5`ws$xfD#%=Lo=eEw6@bZoq
z3mcs^M#YQ9i`%2aOXG7a5cJ+ZoQ-C=OHXXnJ60@gwBs-pH#SxrA8w&-G$3@wHtHQG
z7B<>_xQZQ(6L-glT_79H7hc{mV$qKsb|lAZr+!wh2;US(7CaG6-^{O59;5}0A}~7B
ziX%($t$v(5M;U&U<H&atg9;Br&f@<}Kz-)u(aB`pful#$7>=FZvvUq>_NJVJ$olb|
zgRrggqgAd@9G!kL2Cn#fq^Rh^e31!X<T&~R@TIKR`I2Wa^pvqV^QML~B9^H;M&%64
zCHx@<&bU2suk%FCCA<Zm9NFtU$pZj6xbaU7H$>Yr?>LnkltU?bDjIHR+R|8ZC_&mD
zIfp`R&(TqEWU~Q6PZk<WC_=ltUc(j9_N+Qy<qGAH+MbSqE8*O&pBB6!1kuH~?U8dx
z)b@<+b-v^o3_WG+w&!CFXGGhx{zR2CXCwaXekKOan7iJ*@I=m|QQLD&uk$1i0Oa7t
zzckzsxrvb{tK4Au!)ML85kB1#B>D+|7oB6FT)s)4R?Z)O4!#^`%9rrfjR_PziA0;U
zQNtmTr)eoyIYhbC_CLnPA%ABaUN1Tt8MjYzF7-?B==hj;)GNT~sbsfRUu(D|`ZtSD
zRk=jD<${&5amnqlW8#mTTc-Za2{G{}Z(!u$O#gk<e2i$rx+kifq5OLK&yjIP(-*Ob
z5L13VNGv7i*QpIVF(U44exT?{B-*e+8V-pzY|I%dhuB!dbFpzKw5!gdmmalY@>m14
zVdG=sQLg}_r;^=<ZKL6mXv5M!QMp88FD0vD<5D2EoiF~#V=vT(ofH#)@&-l@&TOyY
zjK~4DpUF8>fv;_l_aJw~<}tot&Y3WY+#tb5nCp8TPNkL8>A<)8amJrI@uNKcMDwa?
z4&*U>ZsYVc{+H)AZa7QDkH%yQUWoxee+Ly6ge>mp00!#EjiEdy<A<Th6OBAu#gN7*
z+SbH?q1#A%9XEN5!VfoLyLIQNxKaMT;H_wI)A(b;BT&yX8-RY-?}_co`FlV7M0?qu
zRPkdu?SICAUpU(h0->?($~kR642A8kr-lO`x&5FVZ^8R9U}$c;dBIK2@%rH=V#iTa
zIBqF?QM)@C-<1Ds`@|f#@F{^Ht#A0d^u&(k{HGt5B8Hk(rD92Wz=932Vd-zp(ZXqL
z({dir4^QD2S5~WdvU!&Oi49M;Wyge}oD1{AP}uj7sVat)8!GrFG7L37%mOA*3!MYZ
zEO+UNeapEaKP-iPS5H&1q#Q}xfI$gNmou6g7G6rNuMBP90pT>ZZ#hTeho`XbMKvm(
zlqV?oc5HYCvhRFhDCY_MFcf|7)wLYMUC?%Kg^iw@WpVR&%rVT?H{M+4ZB{`p)8~)m
zxLJ;o2b`y3#h(9*11o>a4WkaP3naLV@seX?!b|k2N7Si!Q9Rrk2VQQ=>~)Ofc$hE}
z_BV05iV?-W-4S7=@i8QOpq4coSbo>n5z5s5<k(lXzghJvRutzJ6hz~z{A3B(az+K0
zvHi($u55pc8dSU}rY(sBFLV3zQ-h9D#u&*lEny`3w_Rx!BQ}3007g0bWSS;05B=LL
zchLc7YKwCGO1O!>?65`^H}?Ere7O0yh~X8agU*<9a;z%*vGGkRb}TN94?DMY#)Ov~
zm&!IeE2H8?F=%^qcxil29&9wrU35e<wNW_+m2I@6S;dWw$;XFVXd4X(ow1F|@uqB}
z-503XvFHEd!!D4G<_j-5wv_Rj)57s;Kq7<kz~|z7CdJ}d&B-*kk*(vTY2G63$NF7g
zvCAY|&x-M@hJqyJ<BT8D7^@sh(ma|Llu^07*3piM{)HRBx7on(5BTjkjv4MzSXhF6
zzBUqGih{Ll(08w_!pamVW^*ZM4(<_HrI((ytIRYvQ91JgXsf@n)?pcWk*b>}jO})9
z7lUs6JwO=s`>DrRKXUAvO+RhW%?RK~`q^oFhFg#IBi^~vaj~kOzfk)&BnJJsy-X}R
zkz?g-Iw^rZmIFJ|$$K2D9_vKp7AIe#>g4KTtfRYQG&<4v=ScmT-}U_rhWZ*N{!EU|
zv*~69^fCz;l5QU3nDtmU!k=xrRMpK`=%##V47v&D&w{GQ*q_O{fNc7yfNnMdN7B#L
z9Je0pNBFb0R#iWh@MlH4#GoH@f0j3$$hn7XI!RnMATbBnkxtIwSoK&ZB3_?#IoHV<
z=!|WP>z|76*I_f=yPE4Hd|0T>poLpQMbl9eky<w2MswfPkJDGHz>jjSgY-oH(7P@r
z^~s9ta$TRSf8ku{a3b)&6vs^;#_&z-g7W}(;uOr;#9E9ERh4zgDa})-QcsS48;Rd|
zKW_Szs-%0ZM(WRr_w^LdQuVk$Y-_=8vFXv@1BNGzpDLLjG|{D;d+CWTCqs`#z?^is
z+jpbUrD(_2U8(AFOOT{|_t<pl_Lec~PtFDPM1LcoyDs2N`g?)n+GAT3K6UZcs{Xcu
zEhfGfnf^3wlJIsB`qV6U@iRo~FPhk)oSW*29@j&Mi-0%j@e+=2kM$^gYRk`5J-&{4
z8SQ(-rpM4eHH0dSeX5)*>xnMgp~nm`CtdEhXS6=G^jcMy?;#IWQ5>5t1Nqc^>QBzy
z^+bO&p}SGQne_K2$F;|{D8|F9=WzYu5mz=Jr5N9A9kIR4^%o{-5yYE@xxUwrRzoh+
z{Jxw+lyk0guT!z2`6%UaVCC<zqJqm9FFB`2c!~Ka%dS`PqWLIoap2|l3cZezoMR)5
zg#E3%LB(iRG3M+<gptO-k?g%bAEi2g{mD5m+5U$7T*ZpbNBMp<zA6w_;q1@v7CLuj
zY=3eNO18h!8&$k$K1z8Uc$wQ@UNDk#LWGf+kCMJg#ptzS_^1FFg%8_;w1VO9q9d1S
zTPWvf2sb+xo2%kR^HDnE!_D6!qlM1cF6Eqv?8nyLtYSy=Q3^(w`?2sMX*uV%&hQu4
zQOy`HIR_!z=#XEic+q^6^62o=_#6v_KrLks;IiCB2b`&m$}zueqvi8d+}QIE@!=NQ
zMgu};%sDy6mTk24Ruwy%kJ1?*c7bd(UwFweE#W2lvBkgSc>VNSJdT`+Zx%=HZSK>;
zbjr2f%x9z{%=Nu?S#R}YO~!8JIC5KzIh5ht{#(#^L>hBR`WMau$3D7kKw>4zt2s_=
zjtRZ|DuWGkR*q>&HzqHrtYdRb#5qO4`dR$Gd>@7_J7<i~IWnhL%~y3q@oU-07<A<C
z38GRH^8qG$lH*sMo<;!gxxkL}G?!zQQ%`ixN}NM_`e;8hJ&Cxv<_=X)6gQ{$k3mmv
zuhZ+gk>h5aZaRT+3GgD_tl;?M)D4|ejdMsh!wxXhjqr1W7pS_SczwZv(db6ww+Zt=
zy^w55^1FUd{M;pwU%dBFr=vPxz4}*NM;ka!Idw$m3<B1qqw%B6bR^~yE%~*oBgzwW
z9u$L)!uh!%YBKh7a-Kk^rvl(T6WEb06(8(io~=EibJ}qZ>1pO6&N<oIBjM-Df1~P&
z@)L<4#h@p1KbIHX$oUDKZk7S#p}>oDGm+zy(}w7r@i>Qcvv{<bZbV)rahIwa%8QhY
zG1pCwXei6fk|4dh@OSBn&y({aI(<zfT`lDLn#D28sV_Qb6V4%htv$?4Um_o~<Ze}8
zl#i)6A~t>bd%kE@X6*mue2h+K1Hk#2z>#ch3CAs`&gh(WoI^Sre59GqL_0Nkk*YJw
z1GOC$o6g)`FeW|8c_5vhmI3c#U`Kjd$Fa((Cpu>m&LKUG8Ed8|;R^@fr|OCFPaVfZ
zrYB9CVu2s1=a)laS?<ykUnu9Fbo#0Q?yK+R`WkYqgMGGs1)VbpxRbu>j&sh*)~^u0
zu;aI?z9{e2JuWtVh4zI3Rc7o9<-C_pX9d81HgF^x8+*Kie>R=bIm>Yl>1_T9&N<n1
zCVXMd{i@C=-&Qm}Hk}3Xh56ExoNv?VX$9~u0d}OP496;`FQjv-aSrKe)k$W067lcc
z2e_V&z`3-3$!Khp=PRFJuBUAAsispHY5ePVeXsv(fLx~ecR9}|=i631sA5I=wgquu
z<?n&Qs6z*rF<x@Mjqnoj;QDqIFUos$$AOpI`g<KCIqxOs*@rx=Vnq3;vhrx`PvgfT
zwLib>>j-6Pe{%jww!g8Ds8}5ZtlHwhDxCcVfy>zb<UEjUe>F=~yeJ>j6$f7C_Lmoo
z<a`WaBw~RDOI3_mUgQ*W`^(Ww*ECUihy}9Tr6;!d9PCTvf(bX#Ctv%hiW}u8TI0jb
z-y*{+NC%y<UCQ|h*^dogrea5Vg3kD`b6aOjc*%JJ*+$3yPQ{Dj^`cWFvr&!D$%Bn%
zxr>fyrtPI1ugf;t`g;{Oiks8%;TGCP143tPqjKCV+i3gaDs~jVcEpEWAREmWUUK|O
zc!@Z2?Q)LSfmR&3pA|<I{Mg(^!*t4nj4Xt?zSk~k?GaPE^ot`0KdEBHo;!#GD}RfO
z3NB;3{Nl)xKd5+79N88JUT!Pwb&UMt$jKclMifVOMud^ZpOEZ<vf0_d^1FUd?9VTb
zob!~56~&PS6Ql7}ezItNRXF?eyM+!eWBc=qBio-=@nX*%#DSN&{pAHCzc_OJGb%<D
zN45pPD15hD%PgN+li}~8BbRAg=od#8Kda)#o;!#SH-C$a7CK|Q^ot`W{!zt_J$G=L
zxgQHJl9qFB>kNN!9o3BS@{1$q{7J=&;>hyo@Y47k3xq%|We(u7+(ieRsg3%@kt<iK
zxUuIB;=?VpjRu6ym~(z{<i<a%*s<ph;=?YGjphq4zc_O2^Bk{2tgl4lk%RHgo;x_*
z+^1#hXKK=<k@jQ#uJ5%=T4<8&lGdM8KhC;JW%yB!BWeAlVw72H9aXl}PH&#>S?@@U
z!OvZ#Vo7mk`ivN`^taeB>e9h!jHeuDn&2tMGuOPJ;z@C6=cE|$bX#$+V<^X=CK!r5
zQSnPEh7_lkoEZ&<8h;h3efwQsM@Uoqmg7_tEQNh%I#n#$c<5O%U>VN7gTQHQ-*Oyl
zf~T<WWq(oeq&T;GatwHy+jm|tl;d0z48?eA!7D0;6bF}|V~$~t-mj*K%|jnM%Uyb6
z>v9}yf~y#Bty`_)N^x>~GB#ZOEk3*gb<i5yy&NZ-U@QFS@>f-CSsYy%8@6uij|opX
zjyAzl_<$j=sd!SHot_dIo*JK*2Op5-E;^!`w)b+JZGx-t0qHd=t`vuNR>g*EXde&|
zT4Ns|$KfW}3Lnt%x{58u=_RSyunpt`@`a}yr<>rpZNCD%O#$;4-{5%CIPiAZMqs-F
zc(zS7$1_Y&qs>bCWWvK-U$OgSRm1djb0(FnuWW2=n2~JCG?FgF3dE+lH*btjc>%u|
zpVl5M!|&erV9<E{b{76C)~fhljM%?34*dPSL~p2o`3~Zr`f>6s^qvrJULdRv#JZ?s
z-coh&D%!z<X))M<+na1wxO;O6VR09}XZhb%+}nx~gG7Y8#@7;_finEr6ySILeEA-4
z{vj;>!uOQ@L&bj_@NbI)|8Tx1Dis*}9&gSftPX_lS@yQ7gLC0~I^)oRx$o(9+`V~@
zu(<DHwYv+~aom52_GEi(w_tl4+%Kpx_xa(&y&%1x@OKI0hsFU1_2aa^<@nK?8<~W%
zY<-{#{O*0f1oe%mEq}Uz=B=~$M5M6G)>kgVH(!Uz-ASW$n3ls{7C?8^IOcG!E4=5U
zu#ox<bI^gMHJ;eqTJ*8LYw3FKyQ;2#2pj8)PuKq5uJ_c<e4dHEz4@Bn)b}Fjx()gx
zeQ#UKY|~fYqFrlQuj+g2V&vfX`N?EeV+Q^I>e_~6Lvsc}!RXQaJDF~5s7f_8H8hS1
zuLiAcyFF|8iw8AnV;y^QNWH1!dC+eLIwKvwl|#qEe^-B?>Udk&bnCg1`EN}dXDKdF
z4>E_cv)m=9vMGi&v1e~yt2cE$6MC+I?nu`Ua9#P@v+&;&KT>u559HIz&x=jhq5XG+
z>Nd7*Z?3I3^<4v9mqUM~?@PJ9eDy8-cj+gpzCT1xs;DkDeFyU2ap>5a|LaX1PlA3&
zL1(1nlevz3bu8u=RDa5KybI2u`9nKkqxnPK0d$-#HrEUbMjHG3UEk}on;}=2+@k!9
z)7)+qE1DlvFx}i9BE!nx^M$#E4lZN7<UAnZWzP@zOvQ`l|CGdmm)mpnI!1ENjxZAT
zx9)QlBbwh+9uY<w9~i0q`CVT}C{z2B^J}vG4cVY#bri5l$AMKi`wIe>vHi)pFxmb}
zzfkd_`8jQI;AL)qdBI4|TM<TL>^=RZiV@AfX%B!=j>tmOMCBoV$#R#T*rJ?cBHYB-
z`r?19xUuI@;=|3~BEu_42c5B9%J~}EkFDLPVn_35y5qynZJjaUCFee58y)hMiWkj~
zDX2H^cjXXC<8$(0qgn2vBbsS@Dd!Pn8!i8@iW|*;DTxoa&^8(nI%6A^V{+L>TQ{lL
z(fpS3_^=CPqxr&1j&BJs(T`pHwTc(Tk?8<<h3S-Qv%GnnztR#x9J%&?DpnLnw#9*!
zzeR>ohu4h}T*kKO7e^)%1L-mtlX7wt6i2qlftT9~dmSUcIC5k^6(hEuK|~m7{7Ecv
zWDxuFiz6q0OT~)f$nH3>3TJ<Q>gbXE`Nff~{Z+gujx1;}?|)@86hC3KzTMpZ{4U!g
zjQrxrWdl@<D2^-%fKiS<YL*C3i<D0*82&Cg;7t3desSc6fhukkN0!Hjo4-Xy3!QPh
z=od#8Z>eHOab!9^?A+EF6JCCC<m5prUKB^RMTeKh=U5=bG*%s?z4VJC=WV6pMsZ|&
ze7J?S(JTtmxi@1Q^@}4{ep|(kt!EG)c7bd(UwC=r$TJiCIfw;YbG+7|ufGkpSFlxr
zYu#?V8Z!+oqeoYXrw6EaQCXEqH71)Hnj5Q9V_4sG^yudLX{ij;p~-xVk+_doyOrj$
zO~Sngu(@niSW~`#;VS5IKI-=f$_vu0?~`?{d5VwEvE-ULn9KDyoVzWySLqtKU*ddM
zA1aqz!kGxsjAeUcxGLMv*qlEu+d|0If;y6Hd+<8tlug9`%eLXNq3K~`$O!urv+<{(
z(Is2fd0yH2hnkKL({GSoPnhd-htOQ#l*%Nh)>Te}SPXCaRzJ?%%t823em;e`1gH~_
z;z^$g{id>ckpjC7+p5@I30;-Nft|lsjRZdGE2_9ri5ojP51_;DUCXA53smg>hW0!i
z2X=0++N*fUIRPDBf@>9pDqgq2Xct6;m!_?V)K2}b-xE8Pa|GG2o4=ik-ATZ%GY;&+
z*{Lynrgkdl3v}2CJ6*NCid{48G|?1I``{;-wtX<SQ@_h9bTh?E&K>CR5@XUsc2M#9
z6kIC_fLHj?ON&~batYzuRymiD4adnlsyH4F-c`hhqrc^bS6FC1%6SDHj-uU|x08w^
zEvnTPAC7J-jsZJ4$DqSb*mBoU6}zF}U`KS=Y5bH36C$+bEO$`|2-j}v6Xl#kHXKLn
zqT=`=#f9<V7}}PDKxvAjoPW^aC~UcUR~5(45UUks%-iA|=9Wb~Egu8fa+ZrLG&IFd
z&PC|3yTgh%77gRreQm9^xDns?4@a)rA3J}Jgo_Xm_ou5Xv3kPP+EiV2az<@+riR%X
z<to&V6IWH>$9qs$k>A(_F=-jf(pykjs=hjzZm6wC1_fpGTM54TvxMv($=dqr6y*{r
z4^jgTEd&;CV*fcVJIfW6VxK=Rm^`K>-I%<fvd(@6P+<7cZYqZNz#n#A;LE>o7;1>Z
zf{~)bdxYVgsB07$E(U(<fdyfB!VD&RP7Lq1cv!kS$MAm^5C4Pj`LN;g3qxR-!<aR>
z7ty%*Ajy5d2_NU7&R#6f55dQ7;5Z7H5SGt#42-dyRit9MHSDDG;^?u|P%<(s2cXVT
zU^xajwgMBv^2C{Dyu8ukW%>6wmV4t|dX@xT#Ke2Bm-0(}v2^?Xh<)M+++Y1TK9PLf
zKP7vne65gW*dD4ZtH9T`C}hzPA(wA5k!7W1PbAB2mR`Cwvg}T|3sYJ0<ReUE+7<N_
zyq0BJv8Sq^X*jmvGDEKAkV&H=BU?3*smdeM36`G56?2)OMrJ?X#rKxG!G2_!sw%5$
zQfRF+)ybNMCOk52bqK6S_o>fgQipGbxp6(!s>4TC9UipmaGzC&R`WU}o9Y^7;561R
zp+157acr;*KgxBX^$3bk_6(~ZNtw=2pM-QT`Vgb`;y8KxVHK^ux)0Zf&@_HtJ54vH
zs%o2R8|qO<!rr9aGwp}b`e9B#%)XPWFV+oxl>iU&*MH;k=WP1~jx)cn;z)h5uFE6F
zQDaO|;Aq+xGr_SG7`6Zp!tu;2nEW|$ywkFol_NNg-u_s{l_7A<;g>X&)c7TvE5@8O
z?TeXU*$Nz2029LU4UT~^mP7VYv84W3*VWNusi9>gSeo|5Ot4%991DO6VR_bUGhT{5
zOqYeFw?9^KjW3pw_QxC+a^GmuF8TGx7Vpb>A<IJju?11cq9H;q|70SIw?B4^<u7KA
zRAr(5SeL0RdGHY?@_74VLZ0#asq#=?tms-pp5>57qn@00Y9f!fA9j@R=axLQ7AM6q
zbgh4&KT@H}gN2dckw=e4s-w0VhcSOUl>SjZPM@a;zjb-~U*}l&p8Eri<x(6&_io2_
z4)UA}-1p8kPlVCesut2kyk6sQE%oEns~kU0#=S&;o6UIv7Hz20UHI)@UI*sOM`7PD
z*E7YErFwr=maTC8wmB|d<dQ|`S{8@lY$DG<k391rO9kph^4!YnVJy$M5-!iba4yZ^
z`2^d~&|hl3&LxjL&xP~DTHYvGSzVb%icQQ;Vx(c(G1t%4QoOny`iIottP_1@{Lk`p
zkZ&yN`aJfp=XEodapVE2jN{>F+piBOqeg4gKQ__XiBcTvC*yd?Hv)Af8K2~JGnTR7
zKrZ8JIG6PJGPXOxldc=G$*A!{ij|q`ae>53KN(9P-(b}BY1Ho%UN>VIH)v#h96q_b
zEuf4&(BtoMKjBOKWE_Hec3U$3kJl}yj1O4;rDYV?<7nhR$>$z~@2=ta=SE){qmKiH
z5hp8=LvPA7G^UbiOh%lZqS=T@)mNHxLXHb54kp`P19`BPp12~*%~zoO_pBUq9-Axc
zl9>zBDU?y(z6RfX&Z0GBZ~aEsOXIg?%(ld8%iLdV1pXOdxgNit$gwll!KQ--;;ckM
z*1;d(quOqYSO<RQM_K3ybs)!-LI+PUpR4NNepVih4rT)Xjlhz0@CL^&rw$&q>|pjG
zTnA&o|DAFEA^3h0dM>&-gbplw_Zg|9-j2656CT1)6Xy0H$D~3R%Nc)FUEIaW^}68m
zT+Qtvaqz&zEMQ8yn9eaY*2Rz?sk$f`j`s7G=yjnniM;7Tj%kH1MnW!~Zz^Qv(dc3h
z^iTjyNf%#p40Gz@kCt7`AI){~t8ekX^lkX2@!GO^A#_1)eE_4d<42covU0VEvN42P
znMqDbO{=Z1XL_8Pv<OOP0y~VvQh%uia;qPw&rUvFZa1=x>r&rvD6p&sF3WJ<r5p#=
zZj8geZY-GcuHw9TIFIyj@2w0!V?7j)QT0H1#<pKZtOt!j^rjx<wj-Aw768kS4&{1y
zk>g;b2Rg3^c#<CeGv7=PFIx7n<S?#>1(rSh65lj#+;v9?Jw(_}1hWd>ewf&W+<pjs
z=*E|c-y?wOOyEOy@!el>T<ILL3*9-wF6g{=oJaaNVL>o`j6Fit2jx0T?u=d^8q@G?
zEApiexedvsk7dAgFz_LL)N?#+`^csbI<E}pkv?wwjhQ}vZ`ns_8P~@koJ;?0iH*ju
zTkrDKM>P4;9<~vvrsm_c5hRZ{uPS67d88^c8|RKfW)110^2Zv1QRJ4{n}2=U(({O;
zRGBINy1-QCn0=p#?A~0hkiGb5Rd&kNwnrqpM&*(E857yPd0oNv@ngB{@8BYoTkXPj
zCGs#G{<8bbdnXo0-WjAxcnx+pkT1D!oadY=<&#)@20f31y!4#mpSgTF`)dNH%rPoX
zXMrPKcl-Lm5IAX=V&)urgwq*PPKt0U2S#bgOE|sH<;#hau%(5^syICaJtP(d#VL;t
zMT?es4E|dWuUdfB0?18xZN=p@#%uL)Dqe@<`bGCfjF*O5#!je*cpd1$YZ0*OgxrMJ
z-dxU{cs*&gQ<IM8c$HZF^?gPBdY>;|dCqTodxm<jC~j?myz0kkpIh;x9Jf+_n8u$@
z-IsC-b(KvRT%xjZcG=Y0Mii3Gt^uACfz7Xx=UU0JV8@o>*dMd=YiVeT9lK%Nz(hHY
zrE!8=f6H)V_?KeeZ~Th-_Cg11Pf&G0v1{V~h;^XhY!BQaYd1`EAjhmi2NN|q;AM^u
zCIizoz=m`%n`2??;53g8T5#NIY@~yqJYcQ^k;kbSuj+u}){X~5=%Dvqt+6iTcva})
zbd4@}nWKv?U|S80NEhSUIlgp$8Sp;Cql*DJt^ynBV&{i~>te%6sxG!3ju`3T=yjnn
ziJrP~V_gh@O!C+j`KC!4UGOqT7j?k48yJx;20h}|#ZNrCXv1+IVIy6<ZXHXx)m*;m
zVXJ-UI+^Q2j#oc`Zz@~rtBYQUSN+=rh^hHFZ34;hKI$)UCqFD?T{S_K^(FX#@+f50
z5Ur=aS0gBj+_JvN#w;>5wM~3}tLT4sl&iAtfqrX+sjM;iI1`z_C-uKcze46Er>HWY
zi(}If$*fUvB)-H%=30-;_gVJ4>QpZC8SoVpkDiL}`-j7q`pcZh{v98bKp@A4lap1I
zO&Fpujz8tT9QDzbL7yuj-y4wYelAbWey_k~-H%mVsLxgMn6F<8hl_?3s@?Yt7rB2$
zxO4)OF33l?oXzFQiHq=o15Q(MVfp)IA#jPvN9fTpk1ypu58<<(bPqWRpKX4}+fQl}
zM`7Quzb^18K3&C!`X+6^j~*Wlb+rDZr})VI5W;5=uqlF^gwGRPuAKZ4^Zhqj_$d8_
z<-Yi!`t{Y7jn&C1a0hJOT949RdNe3rggBayyS?=G4TM~)&)|BO<zjt<DCE*8I*5<Z
z2!$fIT;6_wc+PXlBvmff4=|Oh7i`=_K5v^Z<eU2wRX*0{M<ky{b%AZvL_Tl(ey-KN
zFFTXVcb(O~&&K!fF;}xy$XDsS0FyYC%rsWkW}3XyLurvans!s$ggItSwaMD4$;Q<A
z&9#lG>fB?Y<U47Oz*06xlwXNtB408O_%A^nFG0P2#_Pm<Ng00sgdLy!F}pSPDV{9B
zH}}C)>2W7^jWIaC9a}xFF;BWit{A4?!l?Qzl>?o)clt@oC;4C`6e&&q$_5kb$55Ts
z54T0aiTsBbC+ee~Y}IwWRoAKg`S@T8-$T$ZX%%(l>g4m8@z{JSNm^xdIg*)%WOeN{
zo|nqy?`RDIs*6~kkLvKHRfhp*J9v>STVne;;)sr?eSNs{PF1Q^P&ckUK19}EGk?r-
zr!;+xfmYvKS7$Bk$oWljsvoX5!saUro8og+Y~~EdbFOh<6Rt-Z6rP;CCVW1z@F`8I
z_`C)FcEy2D6g>+)WsEQp_B63V#pF)JYuyoHqG^K|-=nf8zw7hGP<m!hnMxI#Q-Dq4
znP_~CU){CXgtI5VTlm3a#2sNzv!|%|Tn2k8hyx#Ud&&zY;=N$)RVpT5f-^+{FbUsn
z)iTGYl?s0sKl0>i*U1-e(T}flytZ1!X)L%?5+6?f78X5JMs_CJ^-U=is~y0pviPua
zTU$){2%9UOrs6XUTq=(aAC1qjgznXK?ZdTa!sg0rRGdD?czs2DIEA*kEDG^+Pl0SM
zU8`dCCE|>9d{_mtxqRVso7I<|buPzeBDzC6VVi*Mj^T&}bK+w?1e&aBm_EIsK6FlP
zMq@3WA+Q5X+@9%o1pT9YoO~0-@VB9!VvLPqO^VgUI`?8;?tifO%!Gbb4bAnLB;6{L
zs<-E3$j_Tnn<nyb^Uvd$oQCTS#a52(8{DfqC?-AerwAgw$WXg%g3H$$Tto~W2A8Q8
zS6b^hE>8iE?Xh)W`wjV>6~6sw<T5l2W|4y`V6J`#<!&gSAU|^|);W~*PCC=+opK{Z
z_>Jp5$sbgy<71X0*Htr}%eVr^4Z-#dwm+bau6Q<}jG|dl#mwoygq-qor$SCyk74Az
z)Y9eHdM@XckPokhNVH;`gSNKfkJ;q(3+ojjv7%$91_>K@2eLdq-wL;2vXh;vAIG-K
z@Z;5}i)`EDP$qOt_>fI{?N`WF)WBuC7RL}zufldRe15^70?OvAL%n#!UlZBn=fX*^
zB%9EypKSlL^j3C0m+emEDUn`GwBdUu<<0zM>q~hv=JMFn$Mg^~^Bo!T7K}G7kXQW_
z9r+LnznvIeSb^^e{rWNg-irU_cUO?@&qi6A9pl(O<&TTOmodQgEBrQbCF2O5r|0vI
z_%j-5mLr~-9+)V_aqr`}lyuxE?DKqbEjw-@jvIyJ9!L50)^X%_Ct?3gKKG`f3XeNa
zX`VWj7AmE>jlpkxol<lUGR>Gt!JmUBKJjZ$pHh`{o_D79%C%YXSap-ikEY?s9sb#u
z`}yOCf3J{qstt0j<hNBP*FqCkf6$jAp*T_rY=oc5#*wkmX9ch&j#NMA&yfX<0~3>R
z9C4&sI?l_Hl{jt^jw6oTVI7xmj)+|0%x0A%e}TX4dOik@xO>B!4KL((k!0gV4RqK7
zJc$>XRsOtKmciNtIF5L6rF5K^7hO0mjpK+H4_L?Ln-`*OnLk72#ntHhbiWV{FZ_Cf
zT1ViM?aD?Fzw7669Mo<HZCm8`tz_dzD|9&zxDr2Rz39)6H5Uv_%*AoUkDI0Ay!=Su
zm^N(0k0-6;^34yCpXs<z<;Pg?BheWHKf<*wVJQ--ZIRzAlZ_(_pwH#NmN+t(W2x<b
zY-+)Cq&SW^a+h?Rmm|eEW(hXp$cxr-`R0gdTh?5xa-<S%OTo)AaKyZA=~Z6H@6XA`
zixtq}YT!w{Sjh3y@?r>%>BL67SSlUo<;55rvkDvW;w|gAeDmVlR=+fHDd)xMh*xN>
zs#Ea&I($dbYI9zMPp1TFVZz_Vq@AgO?CQsfeJMVX-wQ<iptk9JY!mvq<CeA1<)%vp
zCf>qtKj%2w{NQU~q}j9P6e~YnK<D$tm93?SS*$V&=WoRJ1de%Fx`vlKEjVTawi|KW
z8tXW*?kBICd!h&qWA`?VU$(V)GO|_W$^P&kov+5m6aSVbe^g=ZjR{xecOPZr$^h8k
z2w+QGIr6Uz%fMWzxNKme7}p@KOp&hP<;p@FSA^q;E3>WRqU4I`kBq-u<;s@uDXp)?
z#uayqvl;M1e!o*Tew098<A5je<1>z5V1Bgz6zetO8pMz7);JvV@?!;#E5mWbk5cQn
zDET4UoXjkhA6vnfl)N4pKQ#RYOX<Bkp6Httq1eX6kI3(@%Eps&=q(Lgi6_72I0oj)
zqALa_>TnI>$<xv`ygc~`$JO9C;>mjJxF~rd+MESfsXTcd;~HImi;X9t+ng+f%+)<H
zZgb>!bY<g83v@Rh*b-MxdBgDsW!N|EpRB$T@iVSLTxpc9;pNIu95WXiab=!$T$Ef9
zZBEB*l`HQd|K7GXHm(F}b9#dx@_Wd#@na$MwH$a7Kl;5HjvpJYMof%r5I^>iuHofJ
zDUMl!jrcLnIxb3nh%wTRpK*T7#C?WhqZf!=hc>6|Enj|QNqLKLH9i!AOEDXzKDGLB
zVu&*QD370!4#uHu&~_99IM<?biVgU<gEO`uVnW>*DveK7;2iJRn=St}s{G}!kFKEd
zi)PdVL6|W%A%Ekp`IkR2hs$4$_?Gma#P>q9C9QwYrhko9QlgV)l3Oi14Ta%yO#h@y
z_2cNDbSjULll+rVrqh1~%60muK7*hB)A&u+KiSa;l-<hS3*VHktiltQ7gW~PRZgi(
zp`3m%vVTw2rKYFqGfng;K~+QgLO%X3_)~Tr$B&-FApC0a{S^B2W&a3>Ul#tD;3tp0
z3;cBasX!e!2mHi*p0(F={C2hQ+Y#Tt9*+FmKYj6YkF`ZJpNBh{WbO1c=2w{ZL2pAn
z<*~RHV5{S7s}JV0QSQgtHvA@YmV8_p%D#bbp3tu`)s)I4Q;m)F4Jf1EO7Jb;JIR-F
zVL6kr;OH9QOnJ0Qjw>5;F2epC=41KuF=Bl7PBDL`jq7HZrJJ4b-Jg8Jx`4XrNnGi6
zDVB!JbtKO%BD)|R>FlBv<vP2FT1WD|WgT@vKQn>%lc>i_9A8IA1*CJgj*hZ)RPb}I
zqmejo8*HFQVlu|;yWg>N#Gd1-ZK_LER!_MQGuP^p^$pha7UDViLG@Eqb^r=#P66?X
z<5I=O{Y$aGk+n<Ki_fr6yg9+D&uXha2eb3BHax!1L48WzmFr{W^`?QuRkTogva+$U
z@<MuXX>*F}7N==Gyk2{tUW4%KNH#YiIi4mbVD)$DO57#@n^pJZ(P*8-<r%KztGQgs
zlPa6eV=^3U$uRatjw#J?p!*zxZR{T4y)8piRV|(eY?@J7m#*Q@>eKbq53euvL5lFB
zb-$zOIKoWaZ;5q3I%WX2-LcXAI^FlnKyPW9e?fY~A)1eKKdQIi{fckm^6iLY=r}Zk
z?0$*&gpQbenT8qshPik`@;N+7+VUN4;W=b3zuyJ852%x%hZrlMyCQMFrVPEigHOy%
zUNAL{&O>G@mvc6b)qEH~$)4NrBX7qW(iyxCjwYf|`8<4kpDCpB1t{l!k`LHommR+d
z-(FtR@$D$T9h0&q^s8)~R#!{QV=?}e;d|(ARE~G$;eXPnu*pF;>*ejpDsM84%P`&c
zMVUAG$Xv1B;*?g$Nj7hY_|=zW7QFuG7FEwv!0W{OdYNZf#Lkzzylu%Jue*Msmv=#S
zc^R?$s?4kB>18haAghiUvHPmbn{MSYlW!$|O}1GLUU%tbZmQ?Jwq+*YtNGYIdjWpb
z`E2sR+}DbkhP)joAIy*E<$RJZ_uI?t-=<f#SU-^8?m)TD&#y$e&d+zET<7P@QSRsG
zi+`!&G!-~4_)yD@rh3Z(5KzR8p5WBU+MZ}|()o=ja1ws9WIo5~3Sdcmx)@sxaH{x7
zk5g3bzm7`_aBn{@5&v|YA^zz&L)_DGrVQnNoGH6qk43@9*|3PFZ?HMyQGSOWkB;nk
zMAC2AobV8~GWl039_PYV(x2%05mlc;=T8=Z$JuN}=QpCXmAVCbEQ&tOibW*-jm;5{
znZMTK(U}7eGM1k9MK(t~itgliASK0eAH(ro2U}_F=KSCZfvH&27|-jas?Ng;yzzRU
z`bwnua>me<`xu1dYFUoBip6{d*q3t#)Xx}-GH=^Jv7oT$#hyBT569P|j_p<*Yn#~e
zG)Y!VPyI&VSoP!1&4~I@T}p9qwz`!5hU10Q0$cZx>e7I^bXj%DG~fmDczd3%E^0lf
z#Hovn71f2X($!@H%FB@8xMMud?tjGYmwxiq%jp}hK7QqG`xMPx^~}F!@BPr4r+)F}
zi<v7vczFbl8Fd&P_x`N6xA^JThrKuEA1Acm-hBI66CUjU@4uegQnBBii*FqD@JYDn
z-=L?W{)hhS`H5E?ecUxq9Qxk(&+b}3{?UI_9<#9Iw7Fv@9q{%e_nmtc#_xBa<Bt8^
z=?DG$v&`4ie{{fkjlVi}+sD4u{>0$lo|xGA>y=xTAMg}9C@Ewyiu!*%V$r>+4d?uK
zr%`*qx$HMr9NP8xoShe4^vG$K-*dp>KYi$?PK@ClNyn9bbM5b*ocY!57gmmZ__$5q
z95VBRg+DlBYUh;~w>B>t);w=*B5^sp-uJfK?Xf?XZt=y%uN<{);_jP9RPBH0wqGAK
z{f4dg`F`=0Z(MT^=F%~FYhIppUE+Zsj@bX<)a>v4bn53z*H*l6(Oz$)ip%d>a?;pO
zAnP~mzQ5RQ=Pi%@(enpyf8vrYFL-|cpU(X8^POjBu08eG8_wAIz{gh|pGXX5xEwOD
za<8dN?|o|Sk*8et+Bpj^tNqWfcKV=Zr}+m=A67i4vGzo)k99c7arIMG-~PiTD?Yxk
z<?|J9EZ#8m%jN$W|GQ(~p7DHR`HZbs9|hgL0mT;eACh{cbj}{9o-kwn&TC)W>XUB@
zYj1jamqg9GKN?Z^(>EW!=M;=tB6(KSf9`%;w|;oZ(E9fe+O&R)@h`ma!RX^3`Q@tq
zUz|GVv1cwF@e7QloWkVjJip+*f6u$^lYf8m+9k<J6Apj(JD<NeY56XPoRr>Sm!V7U
zMuO$|lj(XlEq(oO-@j*zd3S!=^vWxDzI^5ROUGV1_^E|&>~ZMd_TT0|4WrQaW;pjh
z?V@k`|8@7@E?>Cvt_O<m{j_rY_x@9V<q6Y9U-in-(??(NDBh*T?t8`1EvL@-@0}N{
zoBQ!Ix83*D?oa&kkHhYK<-A9)UAyY#ijUsMVCc2wbl?BIId1C}doMck@$L4W^3<f~
zpMChVou27<Zpw8J-!%U28-DPQr|{|lcHFkVKB(y9qL#<rIPBxat7h->?ryK{^u{X>
zUa{--7ku^3s^6?ENhDri$NhVYrGLNbFHd|v@_*M|wf4emhfn^;6W`zY)t8eu9KXZO
zTb{Y^(}~2#?6^Vi-SgqrgD-vJwRgVy)orOS_xj?V;g8NP-{+~8=cfJe=n=~hKpY6H
zi~7I2;F{HcI_EzPuYR@Zn;({qTd}J0JGXx4M^BxzWyk2xPO3Qn7sv~brQ`P4?e@ke
z77sbO?zX*OShV#G58w6gzji!z&6A&<dDGc{`rh7yKSCbsBsy-))o)z?;o7%%ExddA
zR%2iN`#amdaP4!04n5+m)Wq+9_p+`31RE;D3lEF>uWPBiV4o9DxwB^eHMd@P%`TVL
z{P47<t}$0$I`Ndo_M4wwxi|Xy4Ci0gKXKV(kL>^62j`7>uVLn1AJ3h7`LN>3|DK<|
z=;^oT)@?Z%&%?3$oqGF==dZZswTlZ*yz=V0)SAD(yW2${?{~+E)lc;s^7F4xZz#aK
z(~yiU>Ob>{)UW0}@>%AZ15W(wky}hUtY7s_KkPd4ms9uLcS7|e8_ybyF>H{vsQ;p_
zFB8LBP8|LE|CWreeEqyh&o)h6(R9VgMGt>)cGsjCOVa<3y|;jG>ii!6Z=tva21AB~
z;vU=~xI=*AR@@=DLvV&IxI?kw5M&IeFl@je*oISvdvF-`f1jJ%eKY>7l%y-|=hwVA
zyl<1|Jm);;(d&wmg9Fw2s3|wu`=_0_uUNnQn{uyjUjA)@;#p1?Ju&%lmIl#Mwb(bI
z9`VDrKI-Jh$=+F7UHH(b^3DY1x*ixmqx<fbGisI?*0Mpssp(5Izva4$+LEr*yW{7s
z-uLsWT7B^7NqKr5E4KQ)GGRyI{z(n(duQyhl=c^=oTQtU<4Ec;FEUlDad+kRiiHz)
zjyHI0x7t-}4w^UdT-Ng5LzXH^H8n07PRv~}Yx1Q0w;pdC-zVwJ3(vgP4pvMP78I$M
z@BEDXKa$^%>bNmJ|GXR@zOUxnwZyTL@29rBvSe754+jn%O#Ryr4;?uNuT4vPE-!YM
zT~%6?(Jv27RLHtt8F$2I=$=f)mK|%f{^X3;qu=f7=g)NjDJ5Owmw^Q<<w-hc{)|$W
zH_VSZ`t+HNHFVpuWht3!XS-WV_xUPHZ`Hq7I=_>HQ_b;fbJS7kb@n)~qnsOZwpxo_
zZwE&8nb-2h&R-NIZ86EO!qXX96D7R1bakHfKdenLteS1~#X<X9oTzo@=&CtchOBik
zZm4mtKPunofMp2}$9|gV_?zn=4*d9I+vw>UZ(Z1Q%DLaCKQWWn4%KeXoSAAidS5<$
z{^ve=pBw8gj#!!?R>{$8{v5Pr-Qm0X>_02YnQz5zlO1J>Oz|IS?0LQG>)%ITowEDU
ztZIL4zxldWzotHWdS1S%D7n>kKX=!WiP3L%=$G}tdf(ioF5UFox<6gh^i|^?h<*6f
zYUM&pjw$Dr{ND8JXN{F|e3$BHHyz&;|3vjQr+QULQXodT`SUKnOxfze2ky%(D(MFH
zOmxMRYxCX0ai{<B>#Jys7A5qXGi}SeO+BL-Uw(gX-!Vmbrsg+zQjxsIhg0%4ST_Io
z{^dOm6?ije<h(i=UJj~wcK*plZ?Nm7&Re7VFPWdlXK1xEEvxr!VyLA%b#Qg;L_KfU
z$$tIC=oKmU9bw+$fe8Ajv!^X9{YT-cZ4$ol%2O!z;a4}F4%}ZNS>7gF*Y~aTTe)5v
zx#mcXU)KpMF0@-%qr%`}aiYaK`Q77k+XiJQ6j*ISjMSA!mu{B(N8VpmMDojIt!|A~
zsOQ{7OHSM>weC!-<YVhCs*rxqrBj_w8GO=T$;f-0)$+b6vi4D)DovDQu{&H%8s*|I
zdoH*BE4J?N%1wDY&N#K^*%U>|skZyouYRf1rDu^ll^)c6xUO{l4a1Hv&vR;P0YlsM
z4Hnm1e_}S*hpY2Z%u63e-nTr?mZV+5?Z;|NpK5vUe=Tdw^Opzi>2T~w%*iLHH?_Ql
zYV|z6X=<heduo>6Ke>`u$--~uwLRr%S?rH`&FhWccmD@PIjFY3JoVO$eO|17tX<Wb
zBz=(J-MC8SQkBfK=UvYs@2&+dTb^V%_qwV1ovR$!s_3QM`V_g|CCxYV+tM>WbbOd<
zV(QyF2jwf>%Ddfh#$C>v>Z9In)#S$BUkbLJRJ>l>zUj99e7~(>)SEP0iu8QF{`QJJ
z`6%zKl9I0Q#AmNE^-q1F{`HhihvmI}@m9}rKHDbFoM){*Wmbv|RlBjyDJ<!_|Dmfo
zVnliG9<^_^URvs^C0jY&!DW?3-a0qK;Qh=m*J{q+azafXHFb}wsWN7`m3)bB|1LFJ
z^&d0AQZ4)Y=MRgFJd`_m=~Qzcv!+wW$vdeAJ*?()c*Mlqx+VLY<+(a(!lBj`rj+@<
z!~NNtYd@?>U;CieNAx4BikQBM{_b4T4$ATpjke}o^2exR@7lDi(=&gj<Fg(dpuef<
z-t--Gs`JYXHBCQx7i`ma%#c$1?HAVQ-e!nVuEc=5rDIumkFlC=P1}tricUJV`-cQS
z+V%|cEji}S^Zxsm{TA<+Dzmm7zwv<jsI0d8VL30)yV+qtp<?#c$Gndv^}1j2`n)W)
zwhs51mpk6jbWszq-YzfYT^MI~`L-KZo-Y);qvguTk_&cTEOubh;d+JU6m8q!aq=7V
zjoGT*J{9ZCD!M-2)S1U8%$~b8N8;{pGLI@~`91N-+vg89%-*3D<FgvSnb!*HU*G@X
z^4XZHran%%C2x~Bi{AN^U%F;hkyY6P>qI@r`)5`EDyD03F=mvg-5$nGv!Hz;|F`$M
z2h_@3VPnDQrSEQi*Y&-bd)d|TrO)~l9eWI1TdQRCWy-=-r%f;F_Z-%zVV_$~Pt>2`
zQ>oQT?p09j>gV@+w|!%*Zaw2S*l<2ar%`_nj6ctw?cv-VX?t|tnLgthMcG<g%G>a6
z%0{-S*JAFgeq{Ul=pSn29-r^sIMc0!$-51xRl8o%af&iU_3zTAS4%c6+ZeCL;|7IG
zJ)hjquT$^M=jz|9YPf&!qJOFdF%;#rnr?ZqTniH2S`lZ(xqYo}C~pSDEtq`Ai_HmQ
zjV>^z`*+*q`p7G4{N4^<G3e6571xIMkG<`iG#Ps7`rm(${nDR_R&Ravdg;=_tc$;6
zjirxzB*oa)i%U(n8qy!%V#}T5!HZq_b&YjH3%z||?p`r}h3B02Rnw(jvFKXXu1{vJ
z>F3=%?m=DV!z<QzFFd>6+!e7C#rrPBefp51j`xmYMOWu;-zahI{pn-gN%`nrt<57(
z|K=TK^M^O3j?J5%EeH1)vPRWMow)Yp_T(d<kGO5{ZCR;IzPEK&p6NXE#{3@TGZnkP
z`c;aC+^??MUD+jtKFQvFB^{kVod4mQ#nG0=ochDBt0xcLmZ4*Yp;^i-pdF~={paVc
zXRM+1QRBueUvfvobjwHOtk-^iF2kk7zZKuKBv#bxZ&wt~T5oEOwTiM`&F|J<&yqg1
zU%B$G=Fp<QHA;W~#)Xl^jbpAJ`8MT-A=&pO9!tAd+sn$B+bWuk(O>nyxH>`61F=#y
zo*aKb>9V~WZNHtvzH;Pf>Wv*v>`vZZbMnRf<5Lc_&x=~IaPxf?4ZGgWSQ#*Q&yW4i
zE_$<KsiNFd?Y6Mgu3728cOB}ke;jL9fi&q)=UevU(LLX%PH4~CvAE@WEuL3eLGt^2
zy5#CQyXhoL%7;nU_gXyTXx$Gn`^6Z3`t5~7XL8-z-n049zY5GA$@_lP{GLs1vp89=
zQ<b|kj`Gy&?05b9K54wQ!qeYx-tCrkW8F>JCo0MxMzMRQz?<R?_B>2GDQ@Bz0ge1?
zuP$~o|E;msKa0gW)2IIPH+HUBP}gf!;uYOf=<ccszg{x#ULWiE`z1$C9$q*3_aaqa
z#GZKZO?>8}lN|TfN3B-$$5}gK{WLB8_a9=v>9e<6;ux)R9~)SE+PEFjHZ|*(mGYiq
z$6Oz^ma$LEWiM<0{%vc0$(Oy3Ctr}mw0>LavagR-EmE-K`N2Oa%0{)lB-lN=cJ^pR
z+q5_SSljPO#UC1V+;G#YWzIbQkC*%RJ^SuA&dICe(B`#?TGhK!@k8G6y+=2Hoaa{e
zSNW&kO73Mlowd`}#B=JfzuHTU%fO+9HkF7nI(^`~#6|y{YrNd3u4!@Ls~&aRWbJcd
zO|rJs?RGWYxPp@pwMg=^K$-Umt1Ul0WZ{Wk_y0IqHfL%j+qfws{wU1c(N49S_;l;#
zFQPmtT-CSEiy?_-)O}m4QN}fM4YN+YI9KNI8&eELDWlGpBP=5lpMNs6ceB*ZMh`f(
zx=)nT$%ao@u&8IW)cb$zJ7?rh_Vd*Ij+bivHlWOeIypP#816m)r#LAr&yEZpaL9aN
zY?eDS?ytDVv3Yeqde}8@vLnCGvn`7A=7FChM!YU_)|ZQ4Zr9a*+m=~xrpnK}m0z9T
z#=T3?_o!j>sbXWUy-4xr>Q?QJ1^V@<^>9M0j!O$Rs%B&@Ia4if>!bGe@AKtPzU+SV
znMc<(>>72<<8{g6Oq(;Tn>E|aVzybF?@`yWJD0{dQ6r}@O7VPEx0X3_ZtRoJx0ehl
znxNV0_SN(mx}{)#`$k=tER7fc`SClQTUIXhaQ2Lza}#%K{i=1RD-W7HFS@tt*b8!%
zgrAz<4?X|%{oZft;xX0R_j;FpW2HjnYZ_ZW8<erlmD<1EEw|+^?M2;B8GGQ5mD}Do
zD$=z6)5YfQ#&es`PgoM8?~Y0J4v+Ug9&?X3`yXn4amuf2J^pUs(K9b<Pi(U~$&eho
zS{9Dc_sG;0tCJOO-OhKDqO?`l8-u$299Z+${W*_K-*fASTeG&mje2W?{>b;Y#|#*_
zF#h8u<o8sqw<gW)n|oAu49{+eUQxMi|E^@Blk?IaTE8>K#{1WP&N{`QC_U71^5L1S
zJ>IM@<v4M%<c=qIj&(lta&YFO-=>{=F4n7U_1~`go#9li5ASIC*U$FLSiRZJ8EFQt
zFSa}VuB59Tt{nSY+Uqr%40=DohxLoPUON!~o54d~jU4ter|Er9YmIt6OgVfO^i5ZN
zd6DfI$Go`BxK>z=bBmNwYAs)$duaa2`&KkfRwQTt8%^Kr95D9msC9$JbbDLPM7vV^
zZ<^GFj`v^nu=MsPQFlFzGxu^~pE63TvO7;cs8F|ae&5os6s3de--_cgca4a#aJsHk
z`ZH_(G)&Z2uW%|uw%@XzjF%v7!4bt<D9WQG(tpq0v$u4lFMh)3eqQUh%}=aNTD!rT
z?OqGw4Q;kH%FP!^uPaJlwHzPjJe+vr=aob6zMP$URs1PC4ZXc?4=QR|Rx<s}>T{>1
zY|gtFRl9d;l{(zE#mM)2Pps<p>hA8T>#iK_HLk|#{h2SfZ#1lagUyV)6~*o^&uclJ
z^j6l)N^yG2#(6&8n;TVr>qwN}+fkx#lJX7*brD1DAIFzpYteaI!gjM}oPGOyqb6^j
z?RYdHaNZx+Zx8J~ui}Z;i>P1KZl(2^XKu=Ny!MS(Z+hLlkfKS+H~kkBu5P-Lw`Sn5
zYL&+kyR53+B8Q9RUf{JR@zOojA53_<F7Dc16RSUayWn{5-;?G{5&y42ijrO(PdjYu
zeRuo)7K6`USh^~Uq1yah&+g4z*!tbj6|owROk-^5#r?8sf4fy+Nw>FyU%lUZ?Be8f
zM;|ua^s?dmZ_2mdxUTY>rZ<Llrp^1R`OSTK=jyLNH6EBh_2>@`XI^Wu`NM^pDf7l!
zHTPM^7Pj-p@K2}4d1%b{C1cI<^Quwc#D?>w8x9|K=WOB2`TE?8{&;BS+0jQHqJOCQ
z&3ZTVb@@`J=j~hmvVGmkX|Ib8ALx^^bitd~W-V{3++9HIs;lL_d+ScZKO01OnBv8V
z<qdLYSXwcDry_=jZx-aJ6e~-@^<(-dN=9t!qn3-YG;rUuRLPgeOHyWd$rSUfnFjpQ
zyX<$F`i|J{UG&c?%!9=fO1iCWSNE?xyk^@*2huDY)hPMIT}A4(%AdV(>pruNKJ<P3
zEjJwBQR~fTb9CF1SS_Yy%69nX+x*39Bv}ym%CB*nrI_6<TdohLpQy8Q`6a(VW$&$r
zS*9d^l%`#|1I>@Ut}!(6`P*mwcV*AIpi}cZW$cQwS}pJRJ&EtnYIJXGlNt%Cx5<)c
z)Z&qC%&!)V95Xl9&{?md9-FHuZ`J(jPi_!z*NV>8q#b|X(ROOpX|D%QZ2M!<YxB>&
z>3j5D{_F90hKAbDZ@h}~B=eH%>&|b8IknoIVpWRVu-CemW?7CO{LaTnxBtOe%B#+A
zG4?0SfByE)7FJ(n)5{ZO+TA<#(|7hd+wxc0*T?tmN_zuEnWM&e?D4>Zi;Gli_-BTa
z-P*p+7Qg$1yQ5y^`Tp3QGsE{aO4_Ik>w7ib3;W~|mSH~g+UnnwuU}+ZqXy%8KJ%$u
zV@ck+?|P2RcqW^o+)&e%-TB>5$!;08#R)9;ta63?qvpqad8YD~##x4$`@~H2_Jf6I
zi>T>(wR-rX$%mMazG-Hto%q&l|083@_FJJ0^6izb^sj@O`qTctDI{^Oe*N1GC##n`
zzW-F?8yhR;-CQN#yV-@O4Q%sAomekUZF$|D`9mE~%f;AT$=|zR+`y!5k1ja%cI2^Z
zx%&M!#%k+yX4QmfTg%2&lw9h1?M(McN$T8emGo}U%`wg`>-gxValzn@qaW`b_}jhm
z8!F9BtSG|^h}{mlI}TH$?>p!3JhOA#lvCymvH9r}U2mDY#>?IIWLZb0;oW0ueupm3
zPCsME+St|+_Y&%#)b(51>)^D0GYlzfcn#TC)%t_4q8w4v)f{woN5MqD&zODq=)En+
z)@>@9y;0KGe-*z}d_soQ1NOD0t@x^TKfj(#QCa+3w!pkN`{)G+>y7ACx{@+tXswO4
z>!hmqC`R3+h0>0<t~;kF`_+Eg@<6)fnI1>kUDIp!!WTc6U2}T)Z*3l=?;GV#(Iz`O
z^uNM-ql}v0%*|Q%zbQRwddlSYpYPdlv(%=7uf6rYkC%4Y`7YkQZub|m-=n4*w)1G;
zovV_R$XaSy)<S;z@A9tPe7&>2+tkC3DH)#)$in_xe6_p_cKrTuLYrfcEPWq;yLsQj
zUcHy@T^4o8fETwHL~A>vp=B)3GE?)rJucI?iLY!rY&mZ3)&E23Mx_R18JT2W_a{}R
zRr&M#4b7hMtPwT8y*DPcz0qZm|IPC+8dsS%s_&KZrRJ|Xw=n+bl1mr=Ff<MAV5yoe
z%}+~4wc3|_($sDPCoLKoe|pcuMN$kee!gq|XDdFmG2|J{v&PhU_41!XG9}u2EBmss
z#)|oR)Q)<h<At<`Ru;LmdfA1;K5fcn;hA}AKia;o($Pl4i)0#Us=nt^b4!#(e{Q>a
zsNbU$mue2%mwW#DAsjDO_oqi5{pNu=^Yl1>ydF5|^|<N78kK*xWk;b74{~MgFz4tl
zBgYS3sO8-dXHU9r31f|oZyq#dduQeQgrf$WD>yfKAM3SrXAAZ-b6hHox<515Z^!A;
zBOcv3cF$g~^}afpFE2WiqFUce<~8=UHx%zAzp@)ZTjh9DoZqS*Sf@XBvG~O(J1_ll
zr}5>cmm4>({AiipoHc8&I{g)8oocsPUGuA$=KPO(1@wzG%y=(Xz>Vwye$9U$_My*;
zTm|wBoXPPaH7*A`Y+2eeMV=D2_46K9Ie%jR%O>lK<#;yRXHuUw@6R?WNxwXy=9i`X
zr22{a_gXjlWc+sTiXFQBCQ*-afp=E)nY_GthW*=W@8w!$wLNe4*-&-o^3n@?v>*L+
z{JeXn-ZxS>lC_LkdSRwrJ12R^V0>v`UCObiL4$iOv)Y~v%66n^yB@z~?y>Vs8*6*x
zyeVB?Pr0~$5B+!Tcakpm#cm&#&FfWSVE$FPe%#w(MvEaee;r)u(urS{IHqkst|#5^
z>bRjC>bZ63!t^<>-`ktI!<`Q8|5#~mlVe!iM{iagzdLeHRMrQb)HvU>KcCem#)P}8
z3!Ituu=04r!8Y4-rX6#2)8ZDZyIvf8RN=X2>N=-M;Cbs|OXDnCG8VA!iI;V-Zr+d+
z%Q7|?dSvsOgj<f?$;fe<q~hPM+aH!+JkYI6x~I)bcjz{zQr|;qZ$|%hX<WnT4%5yJ
z^oqlI4Yj>Y=>1KzXI{nwzgLcRqQ})tT_0`jkYj6%q7656%@DUj-q*8OC#rVMYZ7Ku
ziu(2}w&lb;!_5hsFTSmEWp}!$iSrj&-{$7FG*j5$&nI>dRG;v=YqTMkcX;>Q*}L(>
zB3B1ptDG&(uP0_S=#loxiR;YyJ}D*LE1#Yj7e#x1B~R1)K0V6%PswYjyI^;JzaBp=
zd!V=dTxT8U=G1z-UG`x2PNjQvep$BM#+EfNdi^=)=)*zv?&^Q&^CHEPz3V5DpIVO3
z?{_DuDRy6XU0CvM?`6w3b*_^(>YCVFO0RoxDr)g9GkcVH(qyXP6?x@R>#bi$pNy6n
z))?Q9*qYoo$I$V&N?A`PjFWJ|l)cM-8I!Ha4fZe9bjc3a^8U8oq~SXX%#A&<PJ_f3
z8u#iGqtTQGNlPBsQLaH9KaRhs>7E2m8j-TZ`&`L}+=}Y|yv5O*zK4h19G|biOk0-&
zL+1E1=RZ=%$y9fKOY?O7^<ygrwr)0PwO`WqCvFc)Ib~zb$DK>oyq~1~ZRSC>K5VtT
zUkt65YQVr{SvI9AHQ9c>kI&;40qalsyq>yyx@jH9W4EjAs_(l--In+totrXY(~eJu
zZ7z~}<I;)+lP#<;Yj5Ww>vBC|K3}ZH`9{Yck5+G3xv@cu)H9Z+9QN~-ZqMtj-8X*C
zy29@R=k(whywXRlU&r!Vt9SY88ZMgsUB_6%qYT`4|IoB2MUthR*4+5+;rB~OvnaX5
z`RAiOqm3&xZeqe18?EIp*SI!p<%T|vjPJ)@?=oX)w~-51D#~A~e`jCLSN5OFwJ3kP
z-+pa1X4&HyKMhNgeRC7T>NXj@lBddilXZ@oZu_eug-@Q%TRP2$H?IOWSbUc1n%`~y
zveH}AtNv|nk6*?<kDQC8|0b(%&!~*L@ncFyK#u%*@7?cQ{lGWHl1(2pZv6XUxu01%
zzM-bO)wuDM^hWcgW7`f*j(7U#^k0g{Py6o8q4ebg3RW`R88MoEnOgEIU$tVn(sct<
zw3^uG+NtM#eqFj#slBKFx7)j)@)<Fwa*wX;S5SBQs4;iW&C>YJhx3P%)k(ByW3o-=
zOt!T3Hci%*Hat3%_Kh5SRv5GNQ4PNFH#S+>@8HrSGowv4T&Wm;)K8Uuo*AV=<_XIe
zSyEg|#rXhr9O~98>GbnkbtT(w8gwGlxjB~#7D&*%#b4uF9-lJ0#I{vKTJVl!wOs|i
zp5LrY^3p9cT-sf^bM<stCO()GGy0=S4?0a-Gw=Sbc*A)1fVw|e;GOrjf-8?3t8U5p
zVe8^i`F@Hrt80weUTN3ftvTuWv-EEiWz)CfUy|PMHpSnN;mY%T-(SdeCTFRG+tWY3
znfCgM#@UBd?*8pm)``8;_&u)LdG45-J>OPst}B*jzuEWaL>pEwoAfYii`z|0H7mS~
z*gc`hnGq{@40ypB$f4MB9lG;5n?R}Otys#z22j$Q<V!DSdVe-0eGFI@k<S<{{rAw9
zzsEwFx-t&-g%coEr;LZw;Up;e8W6jdZ(Ft{->5J>A|FRo#X{JX$FK=}3WNMNMfo!S
z1GM!1<P)0yTcbMt_)`CM-e2awMN1#r{+pt?=f7Rk3u*f?Mt9l?ZU1#KzTAIl&sI&3
zZlktu*Y>=ROM#N{J;SR-4-dj@@GxXpQI5ef@C2*?Pr{&fsf!X{?N=%IUhKH`t0Sa~
z#do4F>E(CFf8>YZ3;i&~bjC5X<6-(jKWzVzALcLgLl^76iHG$I{V@MWe%QXi4|SZ@
z{Afy>ZO6pnI!<TyQY<WQl`OCU%mJl+i=HXAGmc-XXLnQ26vs__Zt9uhx@k|-lQG~`
z+<(UNNet)s^AxhoQeMNLcpBq5?R|-!kvwdgUOEP(cF~>h!(&;fe%N)g$ein=jZ5j^
zPU<)V{EqZ_wC|0i@zXi&dzz2#o6yN8AW7)tV@?)2`RKp%JfCF5-k!>t&mYv4)R&&v
z$K`wZRHA=TXG&%G2v&tUeyaxMUh5k01?1U-miMqW%uGG{!u*hD6I!ak`fw`bxUXda
zYywSm?51!q^n>GIOSl5IhHD}H-@=+qo>^d_+bEqN?#eqQEmfcy)`vY{Z`d0ShkfBh
z*dH#217ON%?2Exna4>uUhe9reRYt%Ka1=ZaM?>ic5+A>e&iGv8`>>2pZOSe2844vn
z6QRUsHI(?QhZ3J>(3AKq)#Br$#V3arpSN0kqHFQlrN!rhOMHkw2Q;1WSx-I^A6dW1
zvpVGSJ^eW+oD8Gz9ft`lSK&12=a4nJ<pZ1n<I*l>!X$73tO^&ynQ$ds0awFKa4kFu
zH^5tP6MPLf!=%LHXP6vrftlepSORW`Mz{mkg}Y!+7y$dhJ#Z}i1x|wp;0!41viXq1
zU6zed)@MIKS!eBooPM=jhO*uYgtA_H0Z+j<@OQ|vR5=UN!gDYkJP-50i?AxZ1lz*P
zusysAhrpX~CcFiuT}s>o^Eu<bknh8D+>26viF<J<ahG;2aqk8t?!BSJeKh<9PKFZq
zsZioR2TI&GK#BV%C~^M<O5D#wiTgz;aeo9Q?lNvj+}}cpds5;gaZe5<?wO&)y(E;l
zH-r-R#!%wk6-wOM=ln<9ZABv6``2jiR%2v){~GPxuY6>C{~GPx$b`T!uSAaTVK=^y
zA>O)L&bSw6+?RPZKHm*Q<P(qemaK>4!#gkm+)E`Tgwa@kB!W7a7-oP;;C#qBQeD5K
zfPI;dc$So95ahW<mN76j%#FRYFhBHxGS7=YejFr~c2Leke==$QEYbW~2gM&*e~UlE
zHGgECDgG4J{E;{W`D4V7047M)AGYQACd))6X#eg9^kVV16{dreU{*K<8sStZ<&tfE
z6K6g_$Mr&*PvwvDv1<90=KGKR8H7FYN7nn|&k!j7$hx1y;>s`><c}j1^0AVqsj1d}
z2$J}dfbT{i@@av+Z=kH>eIV;(OMTb|wuZ8f9}7FcNw70q0%d<^73>C2!|w0~l>MGJ
zQ1*Mi!CoJj9?JetA=nQ}`NXflW=_A1U+7mmbj7a;Q2d$-#jj;h{9-Mx`t=7CzivbE
z>pc{|zSaE7r1@3U#V^U*+}!Dx90!ni@lR=t$mb7^-%I~H3sb`L&;T#V_oTlf-@~hr
zeK+M690Tvd&F~)F0v|w$gV^(L8MgN9t)2FE;fE*XW1mzl-}g|;_cN68ZH2DoQ`&`{
zy+Xv((7|ah58F~ch6^P-A|DR1s`bYqJ@vRY`|y?=e9s{%wLV1O?4iERLw$z_`qG{Z
z9i8RhK|Od<zaO{XpS1dwdUmZ}zs_N6&&rMvE-0S%&yU;hzxB_6ZeeFn+MlC`(_U`2
zgKNK8`CZztv~Ab+Yv}2jzS%>4n+N*RejS>=r}g`B`~A22)%OXV`VFZ)Q$MG@uo{0Y
z1H#Upv|rmGr#*MaUx$bKhQXfMH+!Hj?boL1%RC>N<L`QH{N4D`_#0?(mNzWyN&V_L
zpe^IC%$vcDPZ{}L#;45Cb$l{;pfB;YYWiU{zXgnRmN%^IIYv9}c{=`ubbiy14Lf_%
zeoW(?_S~J{tRCvyJ=E7taNmDvza~w8dnk_&o3!yk<~i5(ndJwkzhPz1#zjstK6u(+
zK5oDNw*Cy95_a~~@o&1*p6vGpH~wYecNzcW{L??iKM(b-9_rgY(3keBn-R9{$v7))
z?V0C<U3-#v`p*kHd(wXG3!L`cZNEBy&-6_m>RUa~mw4MXeK}4Mn(MO-+W0Huu<Q7%
zEOy2#tn3+<I_+)quzVknzq0PU$9N{=uxt7JmW7=?X}{JLPJ21o4sQI-#P2fx$~f#g
z{@Oj%*RAx-zR5#<s|WgO``7ftqCHA|DQi57m(fFgiwF7=uK-Oytm5TZ=UKcAHqZ3U
z9_UNFY?^*pj6c%80ylV8Uj0VT^!+^0mw5SW`e79>`%j*gSGU=HeJQU=(+`XOB=#&@
zoc@NDJ=->?y|AcHDPQ1@u(K!qO}E?q`WJnZhx%3z_3a+$OT2Xf&hjUX^6B-XoL`mm
zgL)|E2a7;CKPcxxufW1k&JP}da(?g-ybBYMpRBJE!Ur(u{Ge@b*xEDgciKzlVfhYf
z<@;4DpInC^<xBKY`5Xts&YrYC>tUz8(rgE}ek{uGvVN5F@~-Pghll#6Bc9o}d7!Vh
z-=j|ZVKp8akA<y0v)ySgtj1selVN91+OPez)1JHgKe{uX>6<*%w|by2?boj9hgJKP
z!JHvX2`hUBCJnI{R_)jCV%XVJ$KT7IwLiOu`Z^|IiLbl;$K-*&v|p>HA6D%tfW<~w
zwqM7!uxn2ePyNlXv!||KZ+q5$tRCvyJ=E9Tao>ME@iuAtaoCpileDeGh<uJjbFN$U
zZ2N^UojHW*EFny14PiR}5T>(*FkL_h)7e9qE--}Y93f06I~h_}!PT3b6VPetc>I=H
zzg&K+q(|gaJi20u2}?jpTN28CifsG2sb|yl3Xq4ir;qK)^|E45&KJAdlbs1E&zI_%
zG`+T;uvbPaUs>3K-z&J3&+ew4>AurX8LK`npV*V~iM^H|*$Z?-Pi&akd6c+F`Q-ju
zLi+dhtH(GT!dJ?1DEBSfp<F+H63X=&T+3@Q!ZWZe<QiIwT>E+!`oRlO;&KrN)w@Hp
zC+9goE?;iSCG8~-l>GC;AU(rFr=MS{XV&!Oy0=f+lX!|fIsWfz&*r9{L(}_Ie<-Mx
zuMm_zP}rq>#z)TbeW{*R)B9Ar7JE`Yu_yh()n1?*dS>!4IGldYWLx4X<3lS%KKY`u
zzYYsQu~!62dANs8eI7(HDEr4Hp|qD$up%r6tHH{!2doaKz#35MU+g+GyGPmnlwG+l
zUF_z8VppC&A$E;W>{ftcw>lKNwV>GT2gU9pD0UCRAiGjWj>pdON_jrM|D5N-s@KEU
zgwnohLGf4g3{SpX&rU})YkFMPsM;$?Ui+kj^5L3!wg26Px%m4Yl(;>BrAhM;a<8-E
zfbyRCr%>*-<XU#ibm--!So~pBxC%yxyJ1Wywz+TGavRG1Aupf~%7Z!NzK}Rj?hA<r
zxp&%<8YY8zU<z0ari2xs+<#FYrhyHi+<(yua!kw86=sA(VKz7g=7I~M0j`Dl;6_*w
z?t+EkF<1m%hQ(oS2L6(;Ff0YBLxmVvs5_-BYz`~HPOuUj3gtfV1yJt){u#>s-*Vq;
zO?U^^hH~GfFXS0IN*(wf)`KajkNPk*Yy^wJCa?r-3M)ZBSR2ay5uIQwDD6RFt9#{a
z4@3A~+EGaBwIaGwuO=w<%DvNSz4n1puk)bP>oO?yD(97@Ugdb9)azL&_3D69ukWD_
z#w3nXuirqaSGjLl>Q(Nuk$No(rC!THsaF$}dTjxvUZp;zUb{f4*M3mybsUs>od=~}
zS3v{Z0;OJeLaEn7Q0nz8lzP1lrC#NJTdCJFQ0lb~lzMFlrCy~zrC$3$sn_vP>UAZQ
zdff}9UZp;zUY|j!SGkW?>Q(Af>NOViAoZFFO1)-*Qm+-D)T`8|)T=L)dTk1&Ub+1D
z?|PMfZhPmf*P3j9Jilb2eq{X33adiquD{0z{d@QHteRf!&)Ac3&efjs!D;VH^~{={
z<QH7|Dt%-x&`muPcVy8-l`r)(z)d}amwWd7-PF@XanGK`O+AO3dVW#e^V9C8p3(cu
z?dfSJHcc-d+xmF_+`sIo^*2eUM04gZ>w}Ne^>^u)MlD@S(tX_C(~(a4b9&emW^mC9
za8u71-RYOyKNp-mzmM&?sb`Ggv?uumXRp!6_T1Dn#&olMZt59hxoOW$J!5P)?YXIE
zjN_&~H}#Bh-L&VXo-v-A_T1Dn#&^@6n|j6sZrXEG&!}_Lo|}5cgid?OJ~6(`Wc?)L
z=PdXQoDF4tY()Gty-sY)xD*Y_m@c1Dn%-#07_5wea-MuFl;alTpyb0kO>t=X^kAJP
z`DEdH)_v;dVJz-%XX_DU>{gz@obV~k3!lLb@Fm;^|AM>WTbO`6K0wyWidSsbzt9`D
zhtZ)NpN|E1!8mX{>)8Zw8q~qLFfp{jB=BdL0tUd8@G49VAHp<HVV$anQD8b47iNJe
zU^bWqW{25eE-25ZF~A-$KO6uH!U?bloCS-)g|GzN0ZYPNurxdiE5NkGtrDyWE5r7%
z8te$G!=N}@k~-@-GS2^PoOP)p;~W<4*`Ei9(RG!`_Wa+rXG7-5IEO`h4&Xs}k?r}v
zp9f8OopI(i?a1{8>jQV!8}+pHMptdU!DAHuvEFbLii~q;j2oYev$aHIoWml{hO&`y
z4vRS3D@DdREaGgg5gF&Oh_kMaGtQCwDgW($ihsk%IEO}i{@igSgI{Ev!y?WBts~<c
z7I8LpjEr+w#5vF$8RxKwv$?l3&XLDAJX>#kZogYMFfz`e(VjmSXWP)oIEO`?O`{{@
z92RkQjE{_SSj5>nIWo>+5og0pXPhICZ+N!e_}qSXz`V#fhemt;T%1jdBjX$vaSmJ_
z8RxKwvw3Y~oWml{%BILThee#NTb*%^Jig)CdgF8Z-G<$faSo04{JA*W_eI7zEaGfF
z92w`Zh_lWf8RxKwv+Yb|od4@MTe-g6bio<t3|yQm_oukNU#|hzPbMNwQ&<lAL0{Mc
zHis=?57-)xgl*v**bc6So#1BJ1s;LjAkPL+x<k2dqbH1q-Cj@+du!i|UjY}xr(cH4
z;nOewE8){G-PQ2vm*vm!>6hc0)2{+<_QyW-9qEtXL+OwHQ2OI~DE)Cel>W#wa@79#
z7nJ_^0ZM;NrS-?$AN5DejqvH0?pFBp%l~%x^viHJeEJn|FMRrCdf@ac+|7><!>3;c
zNBH#1|8e;AOZPN<`ek_*KK*h$cls6X=Es-e(=XlY@adQTU*Xd)!`txbSHQdQ>6ht)
z)30zhKPu7H`%S}}Uxp~*(=Y$1;nOc&wD9SdC3^Vu%MrurSGb!WV}(z@baBF`U;c5!
zr(cHn;nS~x1mV*!Q$nX-dH&^ijy!irj<1%7a(uN8l;f){pd4S7=fTSHoN-W&=PZSC
zJZCGE<2k=TIiABajz4)khi7K0$5(TFbUeqND17>5N*q4@vL^|jewmVnPrvNR!lz%R
z6i&Z*rt2rqcYJAo{88(V@_a7okNdR#cv<U@JOfufzRI(2)#Ix?lUD7IJY)7B=Q{$w
z3!i?OQ-x2zlr-VfFRMO$`la^?pMKfWIsFQ6^P?d{`1H$`F?{-E$Q(ZXvSkUMei^cb
zPrq#0oqmP4`O%m&eEMb26+Zp)<K-nRG343x;cA`Z;N>Ra(JxEB@adPXfYYz=Ha}W<
znTyn8c=JogOJ%~NU)Cbw(=T1I@adP8mvx25derd}ukbj2`5VKhUxw1*)2{$tUKSqf
z(Nr#c`W09{{P|^K{xMf{`qi9mxqdYUEQ`pe7|&r(3gtaM^4>3bkB_`J#t7>}d7n>1
zDDU%;_r#Tfa$TzA>(KIT&2~ugtwlP?SMrg3<$WBIuOD>H*Iem8@>k0@H2u}%yScK{
z-)3yLi~i5|neYxWHC~d=p{0}Uc62Q1TZs|*WYyxTXIoz-Wcm4P=|m^E{OrM`%kE-V
zsTwl7mJp^>syXxfoPUO3(z*KQ7s7PbVA8q9IY3MIxq35J|MzmZ`ezO%ovU5{VA8qf
zXAfaIrN+Pe=W5rWr3<dSM%t21OIMC<dGA>?81!C;=)5mau78gPv%(lK4~zv%!Z=XI
z2P2|0IsNh^A9-h?S<7c9+cM7R;CMtnqj>*ceAo}Bfc;@+$h#EO@oXS0&EJEdjBA5o
zJvaomgcjHp@~%0{05}YefWzSgI0DXsBjF+__BO)NP|7L(`PFomb2r;z>E9376aVCX
z0`YGN6#ssLLH@}&ZK~z;Pp*6Zc$_{%`m}t13L4;PD02hvmaxeC(au3>FXv%rcmYbe
z)$#v7%GX-^zwy`L8~XW5%<NjeHQ1K;@>&ihJtChzyvH*c><y(K^o0^X(KFU@`tzlF
zHaGS3b=|XPbyH8N=bk;Yn|gt6>Y3`h=VySMdWHt>+4FZ(PuI|CkG07EuYFEq2$b=2
zD$E3@YwHzhpC&i;teRe`PuM#}{&W%beZ;cvJndpHzzw}Z<l)ftWd4!<=MA$X@{#vK
z%KM8N!{plEvd)$FME>0m8#&`sknaO{nXzmC<r)Ij-z`w$$2m+@PwZMXJ$di3%#*Hm
z(=ZRpys3u?p%2Ue(`)mi=m&VHulPCrmU<JvUF|bhs`humMDjZnKlef@x4gsGpy`)j
zTgG#iu1YaPK0Sz!w2PiF8SDjRUhNHKEx@}>)%W%Gg+Xz&X!(7r-m^t<#xXlgiGB_!
zdV0jB>509M*RhGT{Ehr(*V5@(ILkU);v2Lsp=_4a{7o#>`JQ)3SuXN7?bsscm8rYG
z?HOA*<MtiDe{3&ky=3G!vzE?Ndx0%KZ%>asU8{dj7ql)Ezl>TsPyCX6Y^|O4Jjq8-
zKKi!*?srf;C7mglbV22lbe0gNvjvkb$gYw60=0CWmebV!-^=+A|AR>v<d>Aw7EC(V
z`~pLmPS@ez{R^@y@i1!XJc)<oW9#U&SB7mFcU}AAJ+AX$NL21a8J`}&Jn#{e@x}qA
z{~Hlqr_jmA97_4vLn$9a=g=vaHI(vkgi=1HE}>H{TPWqD>l!-#m_sQadnn{HhJIl%
zJIl42ZRuY!KMq9XGu7KUzfXfQ-%f|TJ6f3mbHO>V3Y-gN|6(C*3Kv7!k6QvIuOFe<
zS_WAID$C&txDu{{tDy8#Nu%o)zWi~7Gk@&e!%uu<eQE3A^rs@*AFqpFupck$;+IhN
z|6f5F$6rIKZ_(HF^i1FEp}yS%ec698^m6)dWc%ZFy^Uo?JicEKi^2`s`cU*NnqJVl
z+I4^6EI&&>JO_Q?c}-9HhfUKf&wBIY{(6>mtf~iP9ex3ph8JN?cp3JBfl!X;T!ky)
zHFyNxfY?@U!dvh*d<pMBZ|vQJ98*^wK&d||hlzs^e5F3G;^Xok!f%<cf7Qx!SSyF<
znS;^$P18H3=^fYfq>WiMJvm+`<#*kmIL~}9>+K6r_Jc0LcJL}33jc&M{#=9NzvO4)
zV2Su2TKVbvg>HWKP|nZVKXm;w4G7)*bOW9F&8AL1Rll-dC-p1sTk5wxl=>Y8rG7cq
z@Q?bnhjM<_L80rPX>jP~ryCNw`PoA;KMQqZwK)BI%(m38jE_AL`K)4Gk@0Ia%nWT%
zj-zaV)!}9+{dpVg4R=DR_uWv|5x>Bn;Xe2a+z*e!gYZ5)1cSz{fT2!5^76eLS8*MG
zb8!4b=B=DCC(NZCPmys;8Rpazzk<_~v_X0@&zUs6v}}KT9Az-$o7fuy<+^tZ|D>HW
zW~u(_<vUG34%-qp8M6{2@;Msq|I%55N%xyeI)5!4S^fX=JMNOs7EC%G!S%O)0m0Zk
z<&w@GOu7>;=>mgEchV)DBbao@T+%7So%Qy)`00X4=Ndn~mhN-$GX#^)HGalm?7GI!
z6ihnT`1u8s&NY7KVA8q9&k{_!f3&|~(z(XZUrYD7_}PL<=Ni9&VC=fa&mK%V*Z2hn
zlg>4Mj$qQc#!nd$!uA(TI@kE=wRE40pCOoZuJJPlW7jo)reM;!#?LR9bguC;2b0b<
zeikjAjHMrse`lEYWn9-I_7JAik95|@=kha$FkL_h)9FTq%&uPu)7e6pP8l6CyQUDP
z^ABM<M+nk6s5j#nr+@XMIO|u|@z)XgTxT3l26>c|dOg4$DD}o8lq{9ueJE>)CvX&e
z3T2(oBT6hk!WVE8<k2AN@p>M`VR^;hJo-X?-WHFVu=p^c@@NN(5x$4jA&*qB)PY`{
zPvzW>5)*cTvEV=$8%~CCp+AfVm%#+^F4Vz?FcHi}xst%z@LMSDRmyD`_y1<O^%I@t
zZtySlot)T6eP@GG--V&ncNHl0E&H)j-=m?_x2*f6zL!C%@1LO5_a!Lx{TfPr%fd<O
zI~|nzmi<|&?;23*yDpUa=A52d-(8{9_aG?sJq1dAFN9Lx%c0aa`^IX0KY~)<2Ccq*
zKdNutr2qHItta-%RA;$mzLIq_VfuUh$~7&2kKejr((Q6dr`OWOB%hDxgQqU@fgyzH
zj3G>C3Sm0G5T-MSFr6iY>8v44=O4m!wh*QZ2w^&V2-5jcr-53!R%}aqk^LiIL_R}l
z2i|ZPlzCwU^nr{8mICm5XoTaT=uCuiTzV302`57tf9oTD)12*6j$ex%X-`!V`7oxa
z`(<*yf?P*11Ez*EVS30h3iUiS$I{g6ZstLmkLE+k-;CI`{GYKc?Ns(Zq)hVphW$#}
z-%Si<fAL!=<6KfG`?)D0J}arAjB9D3?BAw?93xXQ!V54Hd;~MYAiKI5&T@sdUDM33
zW7j(C>)5r={yKJbbH9#V(>$l$=d`ykY0vFRFYTGWr?%(iP}=hrDDC+el=gfPN_&>I
zk!yRl&i^`g?F+t+UERX3W7o9k>)5p}4tu*g79sW}PP>~p04VJ_4eicb7AJf-H0wMr
z2jw^+hYT&nA-kBC_@rUiOI=5fg}L~frM#sO`~i-FEcGlL(^RIw9gwNOasV<!TFyX*
z4vRnQL%Nh@DWs`c&OoZ(asyHomgkVrSfb${u3D17r7#2h5$1=>U^%!P)`sg~V`zgd
z;d<B(ZiHOJtZaf7_!H!sUgc*v0d9dZe@I*`D<b3askj){M#kk+aS7ZI8JADR#mbj-
zCna)x`RDjz+z}a<Pqi0EfHN*z7>`49KKh<UDD%-;DDx5L%+&elS19ul*AA%j(PHKs
znU9u3nUBswnU8KmnU7vUnU7-PpUg+epv*^^q0C2xpv*@Vq0C2hq0C3kpv*^Ypv*@d
zq0C3zJEP7=+zX@5M`NJG#R^^LBme!8arsnSOot=m@~OBe$0OtNskqoqMaJb*aq&AF
z8JCaaQb_g%E;-|pf^9iICdb{fBl0QEe!3jbEdk~DSV<_y?Tt|OBShcefxa9QGimyA
zoJ{O9EhuvAO+JONBiEM|hH@QA5zVgXncdLSqi5ChWLxH6rp3RHQ~&OATsa_w=^P<U
zr@!os^XKfELYU4H!gRI}rV9*VI^C6!mBSdqbmkDI^AABfX%}`aT?wszUE9+Mu0xjN
z%qO87hdl+Q9gChm&{?i8)ib-P7vQFz?yA$zpz|WG<%>djq`yRkF`&0=`P|eqxT$A!
zL(hcICQYv*+tNR!9Ay#tl;!-Ll&>623(G^f4zwaH1uMaF&;%>Mno#Oj^0oa(`Re|3
z)<<ajYyJ=NRr`mQ@2A?2UTZ&Twf5uV(tZNn)N{D0r(FB@b{?FcI!*6W{dhd>LHhp$
zDE)t;);=UIes1d7+|*O9|ND3ooS!C5?^E@cRja>jTK#2rsXsqA^~`SSS=`W*^@LT^
zOU$<Pf7kU$Wo<oB119A6nozE%tfj3BMBnD2zTHE8hll#Q8_ss&Zut!!>YF^&H+!gW
z^-$mDp}yTieTN77ezafRO=tbf^)Ax>WxVo5<nw{!Ci1rz?Y$_B3guk3H*5msc`99?
zJYR)tjn(I>OoXxd+X{o8tK!GDJ&f#FZ-q^HOt-_vj_yv_*s+I^9qZk&DUa!1*x1qC
z4;wr7FtTHP5H{s8J^b(O$QoJq$Z6*l+cLhn-ru!P8{hUrIUaEU$~ylLl>13I6l!@2
zk3d=1OMWIt=;mjA9J=}0pM-9Hx@V!ApXqt%=4X8oy7}2(hHiek*P)xA>95eu&-x~G
z^RvGV-TZX#o%uDR?|s~VkI^q>eZrx6_5LP1)bsaASRZm|T73@WX&BUht)ZNsjzy9e
zwnELnP|i=s5sgswFO>7svA7IX|3W!GU6fGvFO>7su_zDK_=RGA(g$_yEQo({zF7LN
z97m9S2>JX$zm((boGP(=3(rIO?IIijIn-_03^{aZ8HPTGJ}e_3yS!?Dmi%Ss<G;+`
z!NVf|%lrd*2<3m7znz`1|1$r8c>i7gg{WRz0%!ixKBWD)9-m=XPd#76u9$jUhFus-
z64J4Yp|%gvw|l7X@K9f;^UQyPhx#TD^!<pRS<|n~w#47{_y9{`_4qhTSoQcAOHXwj
z{S?am^ei3K=O?k`Q=gy2QcXQh{t8y&ca}zKJ^8V14<kE<gwFc-ughZ%BRh^TvSUgV
zHgU6sksTd3OUStRU$+Bu7}>FhksSj!mxM*!tYKisO#M4FJAK%e@y+#qn))2al<}?s
zl<N^1!CbI8G{P28&K0(Tbzp1Q0Jep#U^^%_I>7F*Bb5CR`Occe8ON};Yv86JslTwc
zYyV1i&D{L-HOi|?_I2#qzLH&2@~=}~$5*mzP4RWgYxwT#*tLHJyF9N)F>{lb^xw@a
z{AGNW`(~EN7ktc&r!qcwgEBt%gPGv~m>Uj+MmPk@^%=vUjL&1BoVOYaWgHw2<$Y=s
zpgaf73ah~>Fa_5qPlrw5Y}f_Pg~Q=I_ye2|C&7hq9$W&Kz*X=dTmvt`weSvH2OmNk
zOvnW_8(=255$1)PpxlSE70!XX;4-)eu7wBSZg>dt?0e-`7zhu;KjCliA+*CM@C<wp
ze}`PNqg;UT;YFATUWKXQpO9-Xlv^+-ybbff2e1Tu2us7KusVDOYr$907rurvze&CM
z`9#)RM65Sc=E!=Bi1lXV;bL^V$Z?W!E+UPShJ2Cr77_cKo{PgH`&-0Ym*|Y)v))Fq
z9+dT@70!o~p{yt8Ls?JC{oJyiJOpJuc^S%j@-CG1<Rd8S$wZ8QvYwRt=VU#Z56XJ7
z0F?FQTqyl*Ih1j79hCKC0F?FQ?@-p0vW}GX<aH?PNe7hm<TEJiNjVTN>q&1Y>q#Ay
z^<-iw>q)MeRo9d0p{yqjP}Y<ApsXj2P}Y-Wp{yrOP}Y;Oj+FIeUFf==RLV!zTSTlk
zN0rEWi-`3WSTnNTB4WMS>qXXEM69=fCXw|P(dy004uGwtv)%$&ugLL9IX@)VsHmTq
z&g&Cm!UTK~3)X`1U~8y@ePJRv2Bw5Fp&l-WY2g;=0}sJ;@GMLZZ^I1m70e8yV>2gA
z0CT}_VLq4%=7%|9QCJifgS^97DG6&sBb4WnmWI45O(_e<!}4%3tN@q7if}uu3{S!;
z@HDIn<@u!5p%?4WTCgIl4g0}5a2%`$7s2{a)~iinT-K9*&<D1JzOXHv4BNw9uoIN^
zry0J5-C-)?-3!)$ePK=556baJsTcqDk@XTD>&4nNvR=Yty;yoh)=PM-7c(cb7|xW)
z`6YbKFMdNK>m@w)7t?5Gy^P?-{ZFmOlGB%DJ(e2EdaM<c^;mx>>oK`+QPyMfoOfA|
z?SQf#I}T+%_9v9}m^`mk)?+d0oU$JK4$68=)>*P1lk>^49;*mtJyrwCdaNas^;ice
z>#_b&)?-7VtjFZ}@3J1717$t71<HEt1eEm{@5)lwWAa>ZS&zkJ9VP3r^ibAg8KKlm
zNhs^FMo`vctDvmM{)Dm~dj@4arei%N>#=rF)??$KtjCr>S&v<TvL4IG`bySg^<gJC
z1<HDC5tQ}VuTa)w-o#zjW6`1OddxU6vR=Yty%?rN)=PM-7d;o5(8ZO=aV&g|W4gtW
z^%5TYi?TAZUcy_w^kw{Va8gpnvGItk$Kt|Hh<tK!o=>jdGeEh1FAtRCXN8~<7KUYE
zQ7G3}7lU&BUJ2L=aw^x-1D1j#VOcmDmV<H}NbLKs|GM@~oQ(aN<(HGdU(>$rE8F+u
z<oDMszwW26Yd_#C+c$6iy5-mZ{B`Zyzp{PHmakWS1LLoOi%z8f$#XYk{AYLa@8@l{
z^;RtWskDRaE-LMzjN77TbW_jdrk<ahdgfsCa%tt`+84Eaxn0U<aZ}Igrk=l>dNxfj
zCUx?0{dLmH*BQ!l6T7&SFThPbyPJA}Zt6LL(c@Yr3&m3MYvn88Qa)vyvt55GF2U*P
z+|<*%p{K`pgQh3Xt&{qbz9`Rnlh4mlo&8PEwn<AT&%yaP-8PqW<`AZ{YUzTWE9YvL
zXVE*)(_zb|rL$>v<vi&KL_R4=C-F@Mv%@q{?*GukA}}p11vz(UsR+}-8ZbSq3wfuB
z`kb<iP}YmwV`1qCxi(I{A1@2+$KP4u0GJ&HjX&1y&iW0ChwHd?ESC1%5h(YY+hLHN
z%}qVKn|cm6^>jPjE1$tlJ(HVyW;gY$ZtB_G)U&&(=Ws(WfHtSw>8!t`bS&ww(hfHv
z^0~_KSJ|(+2NS{jFf)7rW&i3CG(rcI`=Xw}M(`PI51&JMp5F^N2EK$7;48Qh{ss5L
zH}E`s3$MX<@CH=q4=;fijDdeqpbkcZiC}an{Urb~bI}K1DG|LK_TB#*<uGtj@c%-6
zSoi*Kl*94M|3*1X`~Nq}VdG-?|Aqdc<6{5+g>sm=S>b=79CmKD_+Kc8;b_D!M`kL*
z%1tj)AAa7>^_36XDdh`3Ran2sbIYp1G_VGg{Sp(D{gPU+I;;)lxOIKl61IYJoVpF1
z3fsczumfBQJHchJGyDT~g*Rb$m<8LtVRhIKc7X%o5I6|VghSv0I2<nF{Qe|(1WtkR
z*nyb|E5g}uEcA!-;UZ{*i{TNt0)9uiSHT=`H7pF*!8&j~tOqwhS;tAdbf+TY^(FDL
zo{fyxm&8kVIWk^f5-;nu$asB8ymWUW<Mk!+vU2k#!@km*c|eXo{J%aw%JWfVer%}C
zkBvW`AGx_TGG70;p7>n6tgj>E<=P)V7cbq1$asB8ysX|aBl{!cRnYqWv+XN(WV}M!
zzU2J1HGwl;pE`fUNiFsG{7@*z?T5j?&mXy|XLnQ2;ijIBi{)iL`_l3m+|)C<sb_Xm
z&+4Y0%}qVKn|cm6^yFNtE}^sjx>AX<ev|XVOAz^tq&>><jWMtw91G?BcH^KgoB-u~
zkrm3de3M}hI0MS@ika{MoDE;Vxlry?T?pkk#$uQQ{s>FJ<xuWNT?OU%##-18u7h%)
zgbhmn5WfQxMNGeKi6f@pmTx1b-=<^{({Fu>i0Aim`laJLr{DGHuQHw_;=8$sd^Xa5
z<HOBRuJhdj<^HR!Fdy6o<^6IyU{$yi)`q*`Ah;h|;Q@FL9)&U<9D{G59lnF7U{>t^
z4$Hznpb4IZwct4@dg8Bts)*&UDNV%kS8kRg<Vr+o4>oS<i%9<ZanoT$@wX7|K$p?!
zZx*&?eBkiN-|v0j%6^Dkud)p$gF9e)xD!f$6@8P3`c@D1?H=muGI>~j5B04c>f1fk
z*Kt#<v{$$5-$Q+?hx&F8^ku%$WpS2&DCgroo*xIscDDaPQ0C3SFf$wi<$A55&<KY?
zxn64oly&$hDCZ<c!*p;gl<{^v>;xx3d2iB0I34}~S3@i8h96U5e>e>egwtWr{AkP`
zvHUgXidg>o=ZRSU+PP_+rlUlZ_Nx?*SpFJ#2tY)NuOAO9h)Digd6+^(@;9Jd#PZis
zF=F|v=VsZ6(jJVAyQUgWe@n70>xXDi_MPRkUt2#PgmOL7A(#^$hH^d95h(Mz5%CYD
zd>o;akI@u5<+6rSK7pZ>kD+Ghl*<xI`Pf4#AAPORDVI5v@(Bo~d~`e<N5+FZ$jANb
zJpD)ZPcK6`U-KtS3va?4@D>c}U#3vX#~Moc*h48Foo^_`CzSHBhEhKEP|8QgLzP0M
z{e)6J)=<jF9t!#R(?@i5o$*OXkfeVl<h!Yed}7gmq<<xV8KF+=SBapUclrjFgGr#g
zw<#$U-Q>_8rhsc<O87HO1<%0LP_Cm*3$H;R_!y>#vGF4lj0-bE>A(JnnTKLYJ%)Eb
z?e!yupN57J!%u6Yh~cNBam4V`#KYtwLO-%Kix__Dnnw&j%`GB^pLQN@7!lg1p>_E8
zQ@!4)jnhwA56k?{Z6tp`=flAKnux!1LpiRUN1Ja&&+ew4uC06aOm6B~-PE(Yq1TSM
z=-N5UH-~MBC;ybjh<x%BKe=9~0F?DoK`8tCg<(@z6!wP2;c#e#a{jy&oD9oAx$mef
zly#5T3k+j>HXbG_{V%M_XXy~O_Dmha)}Fpo*x8eQ>(K0d>iWL`+Lf&5_dwZS-mA4U
z(bIKy`uU}L1~>IgZt9uc)U&#&XLD1}?xvo@O+8%~H|x($J(HVy=3w+rY3=j0);`a;
zv`?#>dNw!p>~88g+|<)`{rCC{E-nT)^-ON+ncdX0x~XS#Q_t>(o?Or3(Dcr-{VMK1
zuZNN6V9NEkd7&QWgQsAADD$=GE8U#+c%IEq>Br}L(f5I(FULcI^!04(x;ypdIvZJE
z$XuKlk<TC6bpU#{jUh~D4q-a~5T>(-FrCsPWaTh~Fr8lr(^*59E+B;I93f1n@A>)i
zj-lR6TDo^stkkcxhk=NE96ZNN=I6&yuE%@|WgYnf%Jn8MVLkW?%G&TR*dM-?@5%2y
zly~eziROGReN1?YzvI9cFg|<*6F_ON;*Y(z)9>)&kBNuV<D&AO|2&CLd-9O@41f}!
z`s63^nFJ+1@}4A#kGv;I;`0(pd|tzU#AiVG@khPhZm`pzER;*)<9fYb0?H@tM+aqm
zNeE>e;a&27k55()_3a+&>xOvdze&?iN4WxG{<HkA6=(VXf-+{lg>pUfdl<AoWzqE4
zY5K1FZ(d$b{U|UQzk5U3Z;l2_!<eu+<k+;u0(o|py5E)<F68eda3xF%gZh^rHx<#O
zluz}qM6@@luWz9A_aspIdon2fJvo&Ao&rjLPYI>Jr<U)@R1c-Ur-$+$imXujdk!f5
z-2kP(=Y~Q41aeaoUxgcg{6;$c`BZ=ZlK4n}m-tA3m-tA3m-tA3m-tA3m-tA3m-tA3
zm-tA3|3`dAhaZ2Wzx#2M4=#T4`phKsYiU2<Lh0{Gq4f7;Q0iOs{XNtV^iW^V%}MV1
zug8BsO<($<+<PQ>{k<O2`n6h4E!|K2{_(mi6YDIAQ)VdVqq0C7%nF0zWF7DH(_MYb
z1gHK}^8I*Ro`s(>&(DVEAopKb9>RGp{@W&crXTo&Q~!@o*ylUd{#j_}cYLs%gy&uC
zJFM>O`;nL2Y$kP6g#V=c5^rDmo=@uN&ha!2ly;gHN`3mkA}}2+57WacFcZv6KG|V@
zm;*{Z`61RRVPi)>&1t9Dzmz9AzDRjw9+L9pgi@YjP|8ygN_nb5DUXyx%2V*8^4O;T
z_jUsD!8p@tXF(Ka{fPgk5&8Hs4oZF1gBf6bD9?3m0_8k!Gbq<Lw}9<oE7%vdhB6<u
zfootpxE*$Yzr)V(2J8ZF!ER9QJM0CSTa`XA4(tz^LzMxr3>*l3;b7PT4uS3AFjy1+
zN5GkI44e(WhtfU*5$l})H_90}-&s!o2vVPQwEC3yY)O5}{i9N!wY2)2rPb%0kLuH~
z=zqVQa{Se@)LBlJwCea770O&LpA5|B(O^ax17_0ZchR%Dsps#ep3MzCnV$nRJsA%^
zo*#K8i#q-^hnM-iB@BeEV9@*=_@gsE?&{0U%rrU0U48uu_w|=!*SONDZ_xT{BEDlC
zpnld;P8omK!Bo%&rS3OCnHM)gnMbxlKe!E!f!pB*xDy_PyP*T_fw3s;Ug!gVf%1Og
zeXs#M1k>Zk5ts%32D8CqP~t8ADr+K^zX9tamcNz_5yxK{XN*5N{r%MV#Jiu>@##I3
z@#zDUb|iWxH}(A7)HA!GR}nugnx5=e%lH(X?_@0}pM1<y(m(S<S+^F191BniLAj6F
z2<1NJQc%h*`5At8#w)b)3*_c(O#FS{uBZN4xw$*E@>AOfH;GGrpK2dGvr=szDWS9v
z-Vy$P?ZZtyKR5NvZs^JUWzqB|P)OMi_2xTSBg^NZm$QBF?oZ1oesjPv@G%VP2j*S>
z7a!4go!|c=oy_kXBU0nTu@F^{{WV^+?$m38g6!8O<GZ7Xd>Zhx=rxB@2Q8oxwu0SY
zYq$uufpVUrEtGY4J1F}jtmQ3jU<Wt@@(u>eA=nAZagok2EAv7ZDDNxn3dch;+zGK^
zxd*$$Z}G1OECqW(d7dfz2I_m`IVNNA<8PiBU}+5pLy3zX3E2C8aglz9*}wPipShgx
zu!k^RU<lJWLYPkZC1n2TLYPh;!gPiZrZa{xohgLr{6d({9D;P}xT>X-V*wwJtL$5<
z$33}s#*&BMOTp3*QQt3D4%XoB3Q*dM<mb@xtHbuE@{|4{`Q?R@Ul}O*k(VO*nP5<U
zecATg=d9m7Y)gK0vA^GgcZu}h@HcBxb=(hx#rgYBDC@CnQ2e_I8^Sw~zNOrUlJ^5R
z1#+y%vI{<f0nh=ZJgWWuPW$`#`&0JiSeMwB;|qb1n5p)wL$NRA5&Mmx*r!jc_WMDx
zKNX67DWBN?1qRtSvh8=kX@4Z!Vm}(phsejD^oig?D933QL$UuOw7_Lh%3(xw2c7wh
zWBXJ2NE{`fqEPaY`=unGQ7|YUE878DK8w7Z`6S@G5r}-|Fdn3YbD{V%AN~LrKq==U
zxD+mi$KWz3$03%(wB)w}=7OuBJl|+FEDhJe@1YG&gd3q8SKkDseBzh=S7-Ucn_q!P
z!lz%3-@>O~@=zM8RtazQs5=?{{PHJG`qNIo>Jl{R*RJ=6{7nCdPns<-BisgAJ1E<s
ztUq=^>ASn(WEcRqz`bxc`~}{H`{84F5Wa)hv2ZR<IRa&!auimEzrh;N4r{^_Q2M7o
zVm}ix{Iu}!BV1R)dpr$1lqn+k8F)To_-VZu{{58omGQFE&w*@9e~%7>_Jh|kUnk>l
z8#KZVuom11ec@)<2mTDDUrK&~p_tzx^0QoV`qzraDgJ%ScRLXIyy9o^?>$T-U$7sQ
z9z=z*Zjtl&vTowtR~A1Q6SjbygRro#qr`{ZVL~_=CW5<QQg{~fOc%>jm<sB!p9bn7
zYYR&r=mYb?bkGPhz$!2!tOj|;qNN$k1|>dH9^+MKdAjg@SeECqRvsB|r93IHFXfTv
zv`Km7yqA<m)=5$x8GofbavWdEBgZwQJndmnc`W3myXGv<cYH79iN|+65&4+3`l$&E
z^LK5?wwxza&m+}^bNIVHTn}acmbRt%!3(ezWR0ut*UIze+VQu%$E*XC`vqnHRpM$9
zx$g8sp2HIoKWd;Oe#p96{Fn{J58Arw#|G%f-{+zDaT~UVccJ(}TT=aq=i-Nf-yAob
zeq?7m8J#IAlr||Jd9R_wCkM;~b3*aoh!}1<^$M_Up^-;}`4IUu<SUtX{h+jS+OWF6
zBmU&)?>12K5&IS`AL+xAkE{Jvd=-=LSHpsE4Ggkx*Yxz7o~!*ur1R$c#V`?E3crK0
zju(HH!yx<0EoV6}{r|JSjjzQ1c9;;-k5#=wZ0j|>-fXucZemYjD4(LF6MK|N-7jOG
zOuhe<KK{3UKrs5!PDG!zimFfFSM|HN==<Gv`u!>U(r!gx+Di_|zNo5S*F|5s^Y8i<
zH2sR2ekD!6vWvcdF#3$Ks{Ov2K5bUD-`_>wc=zA!H`Da}H2vn9zO*B$H;I3srf+5Y
z<M>ae-%I(YKq>!JI0jCGLHhppoc2GZ@2}}E)bv@4tNM#w^!@HT^@o4L{$tI5Y^nAc
zlhx~fp1Jt1d+_i2Yc%_7HT&z}0PNUY><0v+pIy_>q3P$;^x3!kyZq*d|8D=i=KlxH
ze?`-0&HJ~${?WhdZzG+=e>;@;@6hyjy6D@3(J!p&bFGG|&$%JB{EYdkeRbS$IPGU7
z|BuJ51YE}ukMDIb155~m`nxR{y`-8R`B~DUm)u1!P}B4IguP!mt{#i;4@1#A0xKqE
ze5=Nsf^<U0Bdd`^NFd_PM4uU{h_pjw;-87wkV8ly@)k+Sz@HDPigZG($R^}8avzCl
zA|Iq8(h3=atVRwY*O9l#7{>hiOcnzXe<T12L}D_58IY<-Ph>8#1G$ap7{m)9jS)F`
zv<W$jD2?z3sgIbExyVuE8KP^<n1}cxf!NeV;a)MMC*ofVUy$W&-$&9j(EA|+Njn$W
zf}BPih^`4^X&EnN$qT+iULgaS<gLgOWD9Z>2}GVDanpM#nUS)HA2JZJB1@3$<h29d
zM||1tiC7UEVn?1KiJMX;#24v=j6mihTaeSpeZ-qVDJ5b+Dk6=Mp2&D)39<t@joe4P
z{g@w+Vu&wdM#dmVDepcOD7TTg>|hxXJ&TrnNL6GmX*MBt<USI!IdMRYh%eF(8H21w
zjv~*H#4Ye0sZU-<k!MIs7C&VXGcps|hd7YAe^74Z5ON<$c9u56WSsdS`6HXirx4%y
zBI6NzALp^H5&X6sN!bruNL8dAG7y=I>_AQ<Z;{0P@foR#m=P<o8aayGM`8|8l#2z~
zM&2U2LfA*@BW7d_G80*j>_AQ<_mP-|i38FY>4_{+$P=-%{R&A|gm@#ZknzYS<T|1&
z%J)bsWDH_M&LZB$@DuSx1|t5*KIA?Uw>UaTJ7f%ElfO&wH!>BG1GtS5IY_t!IfUqp
z_=mJZrXm5zeI!{azDGJCR>Xz`BD&IikF-LjA_2&4BykyRA)S!9NC0vXd5feh%Wp_y
zWFRsZ*@0X{-XbZ>@jKEO8Hmh9b|4oKr96EOsfZjx0+F|fiOIevVny~L&yd7S{1=(@
z-y(V@eIw#0lRx5*1R#OPD<oMJen(m%V~{0C0CFEmT$T2M)JFy)OOQjzeMH9?SZn}#
z$nB`q8QheF`W%R@L9_*AOl<raOdVyxw;{AmZ{myizrw~I^0rVuwrBEPN-n4!Gn4qT
z{g&^S4`nQ2+dCR%M$VGXP8%+Sjk)}7+skjmXkTm({D!syZ(pKZr16eU{7E+g(G4d*
zWFX&V$A+HmLL=~(zpo?Dkc#|m&FrPbjDb&xFH-dfV*ZFc*iJtZd(Z@VZL{JBdEKG%
z7FmMcCh|<lLNhy33^~p3jbXdXv<<if2|(CoP`pQB6Y8M>2_z1ENjH}=Ol1;Uj%-2X
z#$O$BJubh)^u%Hb<e0H?8@*TAh$-8}uyq<H8%=&lJIc6)i!kCg@=_``_EMHN@ltf`
z6#DsjDYoWbig!yd#n{SA@o!Ce+j=SW+wnU)S!WR|7fmhiNSe-&9mYdl`OeHZ)Xht2
z*PU|qU`+1mrR?bCr6lg{rF25}Au0QKDLs)T$i@GUy?cSH;rkzdKkdD#2t`Ojl6%M{
z*N}S%Aw*G85k<NXib|1t2%!k25JK*`hmeHaLx@6h3;77=wf1NC{r2<sJD+oY=bYc~
zJpK>!_&h)FHEY(aS+nM{XHT;SO#JwuM;1(GF%74Y58c^nk~5A#YYu57q8Nt$oJSFk
zEa(Q%J|sbFF3X4gJko)*0k%P$FA*86CYjHtenf<D?hGX#5eqmsFJ#@|&xfetBH9c0
z#nioo<)ZgeK8N7HOieOg&N&#9R?r9BpihGRN|wh3X$tJQAT2=*7o@$p7|lh<TGnwL
z?Zu=>rXzAa%iTa<AY>!yD9R!*n!egZU%+`Y{U1XcV6%n!5W$72$u{~O&ao_iJImg|
za(6L}i^`n6tml3;X=yU+afq@<*-ppRB)yYtqtmSCS?W5^w2Lg~GRuMU73xT*?_hP6
zb|5f=>DO2ed@}j$y-r)<e}nv+%n$c0_KRE02glpgafj^-^ShLV|2^ir&w3;50r}bF
z!~Y@u_=tXl=VSUghjzgI34QvM&oG!jqb%HWS#N|tXPy_tJjV0YB)?Z|zt{9#0rS6M
z9bsOm#_`YkyjA1GKs_*d&vt?B2g;-4N7f0pMSNZ&>=S+SnfYPyh5ms-F?Apb(pTDm
zyU_iMzQa<aL;A)t;e)UemiL`y{h-}HDJ#ji*C3O^kOoOjCb=UA1~Qpsj|gNzLoSng
z!yii(GAX7U^OToKh8i-dou*7OuOO3bE6OB4Ev8qJNePviUPUHlbMd9C!*URYG)Prt
zk`>aBTTLbv>B^*%>M}{YCd=28NtU%_Qb&E6WKx@X4P=s{j!Y^>PF<OlT2Ce=8d6t%
z${NWen+7t;)R=ZOq--OZbh<HhHDUSuL0-FsOwwvayLp%_rZx4nWm)ZHQl=T@+RLQm
z4l*gKBkk?PGP}s6$gZ@vyG%0fA>%WUwsFyD*;mFxy_B_-NzMag(xic`qZP{^#C(Hg
zTn96sHHJ~waG4Zq!?H%mq@<Cwb(Bm>x24X}GU?qI)`5ouO6+OJIQqbW=t%pV=-cr!
zNpAw{>r7v|&|X)W<TH^vCsCIh>oS>or?B4cw8MkCr&9McnRM5aKAFxsc~J)!x7xnc
zGlTZegdg?Iq91uda>qIJH!nzb4v<Nnb7fM<JlYyay+PC!ER#~^BZN9b>6-;u$hwEo
z)<x92gneNt?OG<2ES9r;n5>{(&<kgOKn{AZq&{e^Vj0Ln$JHzc>_n0?(qOWNK0^^~
z*Ros~uA`5U3zJCdM91}%K?)Bphis%RQRHu;%x3n>E%fPDmKn=(;@A)3Wl})`(|58D
zB(l%$roUmchxLQ*Ugkj*O5m78TTzT7``DiQsp|m!m(2D;*g^K!L#*Fn+IociW0W~g
zohhu_N&5X1`@tF3>m2P)W%>o`yC{>IT%rt)TxQ?6!gA7?c9ne%{u!*(HOk{Ov@<D#
z6iC-uKEjX=?HjZmk;sPOP5KWBD1d1e`v;Do1QxgGBRJkBeTVhEOFNKxkNxI8%XvWi
zv+3`LOn*clKW01SP(O^HuuakXDcc{tpRt`_l}nvSMG-narw-V@Af3nj`LqS;FWDDf
zv5ePDFJSr`>L{d*Z&{Cb96wl!Oi1rpM`(Xw*)aUbI>EGvb%DhvmJRFA^f4U2a2&$3
zm~Dl?ugv=w%Y*4R`VrP8?0@k5PW?aFUNHR0c87%|monj~Cg)VkO+%SnvX#rFb_zMy
zV{$1QN6O2kFm<`)t|6CfH06?M1-YbKQ7)C>u9jT#=N}$6tSpz(;a5d2B_ao>wdGQ*
z4%4g3CHrb}$wF5y=~bs*9`Gr`-I{VKRZlJ@*OE(-`jkgLvTBoWAeR#A$fbz7aw(*q
zT$*G^8|zb#kzBHBAm{rd^);j|jpUL>W0r@+CX{VTnPzgSNprcR#ZA$7NaLnxA~!_C
zTTzcG%Y&jd^&k?SZAiD3O9t&|7c$M{QcQd5>cBd8luMSK<dR8e*0~Gy!N*)K6(g`K
z%kD-*F?_l+9bp#qM-SEqjy>g40sMN=p5D}pc713Q9Q!gK0{c-94>?7^us{8Z>;ZBq
zX`ozMYDF6cv95zzry;b#nl>VPD0K{@kA|~68`f)tTrwZYI*ej|WZKHPKfv@cOt+(L
z_AGBK^^9W~4y?Z;bs)uwHjSr!6XcS!GuziiE_HO3OU4sf)+E}895=S@WcqLlZFHx-
z9@I6JveW1{Ps&fHf4rE-TP|t)Fb{Hkse1<7e<thT$38TRcFkd)0NOp5WzVC05PcF%
zoKL$$STAISQg#8`Y9aeg80)@BE?F;T-IlP7rPRNSa>!mzxfOCLDxB@KlJ=~k+-mlV
z2+FOYzO|HHM_X_=lCtY*#|G-#NSmYRhiJ-eVt?FB8RW*$XItp=tt@*R`$Q~t#nHCy
z^i@1{AT@#Z?xZghS+6}DCrNC}{j}`>eVR-?xO<Sg4&gB4M_A4=*5f$&DfID4w#6yt
zIZa=mp`Np}`5engWuJuUdHNWWF3`sp**DW@!zKC>j+faFuh2&5rn79sARh)-Sr)P~
zXxBC7&BS%;zQMM+N!zmMd*t3?|Gdq%yu*HRmwvm)_P9?S512oj?edUzK4Sbab>*=A
zp3omp>9=RJDVMf9XCHh)f8^1(`P7Btm$dH{WnZ)G0_uH3y9=rNEp2|s_W4M?MJ)dl
zb$p>s#kA=w>+l!-`HepLE>}L}>nACsG&P0PPOgwb6bh-RoI<izS4ch@3ce#TUV*fh
zLMo`FkTNSPIL9cYFn*kD%MX*=@uOtzY6>X_X}St2i61jA<%f(u{D{$>A24>TrI2*>
z71BGL<^j?u9v=1M!BNY)3dyvdLeev&eq`5INU25&DW-vf`%={1P$4yGq>vQ+NFoPG
zO%zgOQw4w6qTc2TskezjGT|Rr)M%-Ya&fwqLJBukNbaqvyAAcW<%?W9g_Ms}Guqr<
zAw_ghaPLGRS@DmpH|ea9ijmcYy3MJ#tAhI$tao?nwV=&C6jBN9_GF!VDWvq?3hogo
zq~yMg_hWgM^hbZzVIa%1qRv4I$!4%ZGPI#>{3Gs$BWc?x+J@7%v~4u&Jw_op+9|mA
zr;v=tDkQCOv=6BcthXa=bE2N{v~2=yLyj|j>Y|WhUFp+_^eJEJt=(7;WFvVp^-iHq
zclz0bHcw@FNSnqwc{0y*>hz*7z1dDav>&~FS!X!UpnllTB*NK`{zWEiXORc@*|Y;b
zbJ%|H^d~|ufMp^PMX;F5{(vmF&tsbfvOX{mqK^<2OyA6BeM4v$Y(m*K3z#3)3#kJ!
zVXXTi(ui72pDrPd@TF{zW%NJXmowiA)*q(f<iTboeF67XY%f@^R!9lRMoI+ruA$%8
zvQF!0Pb7V`o;o(L9?06rwuz!m(bTz#X`5L#3SbdKze8&a?Lf{}%5J0XSjxuHC)?Ry
z;^~J3+P#DFJJ|-i*sh866HY^GH~otoOxnYINJBm}_OhK}4L`&n4Mi|aqE7fB25EQ)
zy?tyycp?g^D1c%=`S>&Z>485z@TUj<^uV7U_|pS_df<P$2gDW0I7v-B62#vd?WcL$
zPa8kk-pRwceLGh#7kdx4sZ(6Mrn<P>Pw?{bw)f@#_TF9-?43M4l}R5jx2Y5D{XBfc
zY+?rGoc7*6UQ^vBczCuXm-kdi<~nMQ{LPAgVOd|w_0;%R9OO2^Ynt~oS0BSB!<rfn
z@$_-?aGOnyhP|eFc)Gc}cu7?yV;u*F8510wd|1|aUmq85o<lU&ndIW`>Ecy3S3Eyy
ztmEY4&N9S2w9moY$H~XV!NX~)(?k~!m#IE~m+|&-=1)q-I-}gCI!~MFEmbDncbe~1
zXD1)GX;c3$)1znqe<)+6vs;(<&+@NGEBlUHM`B0=f4-8=p;kNo)>XZd#2s`82Pf|d
zZf-Q_?~ak`N>#OODf64bqBWUSB^@0{qDECo8lvVt$y=2->0fzX|H|_uZ#}ITqBeoG
z@S%TnbS%hAFc5i^bMW->VqD~#66pq2{tPE~Ul(P*C3y}0&Uf)}a+}IVQ05zw_jh^P
z;PCJA9m)T@ev$w0`i=ip-pj??*Impi$=EV&RQ(je*I6+PqQ68xSrV1~RO9b{`d0@r
z?f=_8lIu)j*-dCq0?T^#_wtqN%w|)qvqK+0PcO07%5|tA{XGx2ij?y#si|zUavuKF
z{(m|Tw_%j?wAK6fJiY&udCK+|@7+)i6Pdp@DF+d0U`(z5*k2CrfA^Qz|9&(4YoE$w
z;;;ME-GAl%d!Nc7@7H}QpS)rkF+|PNecA-Ksjk!h-lrVN|8-x}XJ3mXf4`9^??8D6
zUr!D&7xKh@IEnc8ekJzLfA3dfUv2>Q+yAg1@@Mwn?uX(S`rUqL{jc)>-Veq0<5rh=
zca^k@>Bs->LuGr!{`_}){?~0T=CM}I<EsDf?Pu{1^Mo+Z9?Iy{{`WkV|H(XJn-?)n
zgZ_2tB}s<zH%$_DxD<{1R<m8xhex)}?~-$TX|06W2Sx<Px9%3SZ#5gzsD~)m@#m7G
zC;k75p5<h+zhBAE4*suVTaI$g44o6`n_%D@na#UDl=aoGTIcYkj^#hix!JR_w0(7x
z39Y(R{%+>6qGGeg#-R@u$Meh=&xRPvC*25HChck4q}6_xuqr{W9}Z?aUY*_Ofs3(q
zT=Jmag`8)8Dwn&iPA&DmovyU6HZWOz#+6n<{==_ij`dkGtnZ3Zwb~p{@6T^kc)r9?
zzVOV13a0{6-^}v+koq98NbhsXSF59apU%AEWj(WER!`R1l7q)k9?_y=;OhXrsV~h+
z^2=LYz51$i{{tJ-<)4OW96mR<$+}sRG*r3V%<0;BUm`aYekr^Y;9xtX+lwk6GHg@y
zI}GxyuCJH8-I-%UxxVrdvwzBO*V~m6n-;gnc*k2OtNLH3h7Oq6dBM$I9-ZeO;x}r_
z`sVAYyUzT!bw+N)n{yj>o~d_Y;{}7QH>Vt0lAV6TvEU`o4K?OKHIy6GiS{~?s5{tw
zL({7X6<6$!`*QpAnZ+mHk6AtTV*RFC1)S%24#ZGyzVN~F*V#{N>ugWa?0xI;^U7D3
zT-NB)-Ok0Paou?pFY+9QMJ-V-*UxE2vw=gmPKsK*e%50Bxs%$C@Xj$0ooh4HD{0O7
zw5GhHN7=rOQ%}r0e4tg{t10Gr)BGE~iEs@zFn0Pj-E;QYrxEVz_B<Y;Y~QfxjOnRs
z@66F27`o8i<?ihlb!NY5v1y?588zLN-$zc<=C{B+qhu)e@9wfW^1yqa#jOY4?or;h
ztD5ubwmCgEx;AJ&#Q8w69nV-SW1|?#6LLOF27UuO-}{kl<#ca~?Rjt4RPXsF3Hx7-
z&9R-C%z@gXy(njpoH@Jx@>KI#X34GhIrS~6(zR(;m+PzEHyvHB&iK@2qv$`DZ75&$
zUhjLL^Mjvu15Q-wGws6CbzY|?tQ*=bc*5w@H`m5BDdD#PeMGr6Ew0oJ``mcYkXJj8
zTXxd%s5E!+^x;-R1EQDTYt~mWFOJU+<@z?f9<_P>s+DGW?++}USu^rMk=mZQlJ&C9
zokz91zs_ts+jqNie_m=9-Qwq>K{nI6W!(4?G2wA+@W7uJ(k|A$x}xx1%ei~%OVSKw
zeZ|_2H|Eya=;)gMuK!n)ieF{-=G`4M{$z>2+$eg&^AqQIR$sZF_WQW5Syi29afxmA
zt=OX<JSb^lcEI`Z*N44K-?g#nygl#!evZjd-m+!mp>{v|8k>DGGBkR=H#;P*ie~qP
zyPpOe*?akwp~+$1g{RzKqE22}UjD`8S<No&vuWMq;S0y3=NpVOw$i##;quKy>A?g^
zI@nh9%Qv4{;hF|Zrw+cGd@Z^1^})Mu`u3~dUcJwz=to}+oZtN9S)DGToWD=i$JVV5
zz3Qa3_Rgi^a$C3RIBr~X<a@GDIg2lg?xkk%%#E_Xxhp%jwJ2QOc69uvYv&WZ)7pRA
z7#cmI;g<l*yPIxo{l;=5mHjep*^UR3whZYvH@IRs%^S7f_c<2Ouw%}kW$JYYEbQsf
zdOM$;Jey`HZyY{2T(hH3RMpt)c|G>ta;~*_)Yg8+XCB^kziDb@{J0Un15~!}TjxD*
z+YB5lWmK5_q^2zU+?hu%e^t=FyfeA&lyx_E7p>;meC2+SSbT28RG-c-`@b1kxVNY6
z{@`l~ZEhZIZ#r?`=xw9+UEd%{E0yOLjfX!&3j*IauRf{6@r)sBBLaWKJZq+L|B?Th
z$r)EPR$b?rEoafbNqI;6&;HS?q0SVW@Q9{vAFo!)$vD4t<N>E0UoS6it;aJ&7nR$$
z&8XdrKbhNVo*Xo`=9?<tm-O#br+ecw-+ktNf0h%UP<=k1i##J|DDSkqsJQX$x({q~
z4aNnx&CkyB>0@+kd1Q3>;MME(8(K~0);7=b8OpuxXj_GZ^i_Bd&vS|E@g%T$AMK0r
z{X_Hatus{=IkrmVodRZ}TwQOgI*l6U)rz&5J#~ol?675lgG_#WD(oDZ*1A^DI#KU=
zK1zA~zN`~aILPR7$nw_OvF9DyJXyIc&86S!UW+CdY&bN$a45%`cutP}#V_Ed$Crjf
ztq&?XxcY_7>v2Bw!EWu6hU$H~&3V;RGf<KSD$DJjctF3)%8XMhs%%d>6JXOl?B%D~
zsqt4Uog29R*tO?xc=l_9vfNC|5$n6`s}vD=ZP|vXJuP&-zBO6UA@H_tX#V|+V@xK~
z$KlHLh<w(;@N2<}M|U-LMZDKJ(spdct>2CM#_itKd6!Af2>Cs(36$jwH_iHf{D9_k
zpUR{6-*4f*;HiJ*=*;GYQ7QGkr=2ivv|Ew}DEHIgmXD%eOrF!xJToyvkx^5vz%n<w
z>9C{ojiOsu3Thy)B1w;x?JJqTBjDkd9na>^u5hecy@tNpvkTssJbYR;@o4eaxVTPp
zc*laWKFbE<vo&P$>4jSLHoJ9<DJk$eJ*-K;10Blue0B8uv>%+;ES2Xg+Xd|wo{rbK
zT;XHYYu|EzUf8~UV)+L4N4Jbyeed?#51#BRlCs=8^Dc?4-RyLSpEuTcY4G;-utT9)
zR~52DKfm?Jh+f;g1<&g9{Gg$H`JOMwYlVIa$v3r`(7#u^k`X&^c|<<n<lVQic|l^a
z{urL|SGMnAa&c^O{DDeC-jD9o<I}2Hj_xxK-LrjdWm<4CJEqQNp0f*Ao;Uvad{x9}
zu%TQ_qi^?=F%1$Hv>fHOsg>zN-K$-bV>RWuB|ADb8x_%l3zXx^`ttrNs`)YV@#F79
zgSuR`GcI`kAhfGR*pn+Y4EE16N!4A<vvtb$C78F`Ts3b;#U1xjou5nJ=4f@OmGb#e
z70re1!@O!A%iuVFt*mc+;P9dSFVvnqa^HK+lkMvnXSIvpo_=OgU7gHkQ@RG`4&%3B
z{Y3lzxm>NmqTINZfd+*&_xWyHmp<~R#w_*uStSqBZnerg?&FmHSNjd2{KiRHUr~hX
zHa*{)1E$)`KC0cVJ=^bt{n36OZ@+joz1e}0$tKHrx3`6;?^gS7T}PiOtiMuASN*hI
z%<x3>7iM{j!=IXK-kNFq>02hxEh;|;2UhBGrsJz!%Pu{%IJHmn(~sCIH!km8b-T0G
z=L*ZSzg6bkC$7g0<yZ6<yKL*RHr&+s+L5HzE#7=SX{K$j9n`Vpv!|D(S-(#_8dY7C
zTR1y*Q$3@gLANFh_8V(DO#9}=#0ph?@<*8DeqOjkKlKW~4eKk)9okdXdDLUepKX`U
zSm^Y=O`cb=+1k8XYDrnm+>h#R9Ki*#uX26;gE}U6lPxsP`L5gLX_UnyyOGx0a*Dl2
zx;C5nV7J~xzCW5N+gEqT)@RM8eTdvWOW~w-QM<|I9s9gGZ5S1`qe9h6we<@qcU)QD
zk`AlV##jH+zSj?(K?zy&wp{luxO1a-%eqqYC96a3bmH7MN!dQ#ESH4OvJaiCY({*Z
zS9RUUl3{j@c1M}6zxnxIugl-8)%iD8l;`J=z!2U0AA)8$)OA=m=VszeS(e`XWt+G9
zl&gDwyWhsp6a2<X*}k1q^$n|^P3`{9<LCVq)wY$3(}-AcDREWMv4&F`1~u)qnd?dA
za<BDpDLLJ1*@%|zE#@mW9jvGySafCXoHWk|i<`b&SFq!?BsnV2yM@!*>Rq`VowT*$
zw>OUO)GJNhxUWy;J|~~dIu;-PqK+BoXEWt_e93oxzjV_>H_gMIeb#@P=sYPS$I*LO
z;WEuBaUJXiSs3s+sO%S)^h~!O?aXS$7nF}o-#ccSJna2my^3o#22T%f9%-Jmo_7Z;
zuQyJ_sb3$`(n8j?oz>A^SMDwT;E^9YuS*q&M7KeP4X5jK9<QeSyo{?<`O~$R9uo%i
zDBQ5lCrWp^OR<al<2PeJbvbLb_(4_9Eso0iR`@)%S>zb8Eo`ux?|0(^{X6y@YT;58
z(8%@i@T;%-9C;;4H<j0ki!a>SdF+Q>=W(_lw|RP5+&grCS**HW%F0ofm&RPvIHTbD
zPg!5ZzI$DkzRF3z^?CSm*Tm}cTAZBFN!{;C#EwM0PA-#dl6iNH@^dg?`r(|Rm(I7$
zSbHXKMc(@3CGx!ehF2Elht2WdQu#f9Vv{~9x9?b|%tPLT-_18MEpI91XV&gs^+vRD
z+P)L&2MV4YZnoN#chxA*lZCgAdVky3<K6Y_?kOK$W_YB1ncF12M*XOJn#IR#OLpDn
zbgJAQigITAHaIpK?C@e;J^y{?r;Jb5+*P=9@zwgdL&gUDSjP9sHp=UW3ze(QomU(h
z{H3M!51;TMqr9zK7;W}zFgT&}@kU{v^Et0|QugzB1KF^Igw{c3t5SE2)9c)F_VaPy
zPRv<+cfsC(u<0d(tl6)W$9cWF9k0#aRoL_R2l>guicya`8TFE!d!M-Rrr$^pGn<~p
z{N_;Ez8%*zPKKy&S*zW{_}1>HrppZn_q*A!`PF7ODpjf9A*Abg9+g%e=l5P`PIzbB
z^}10(+wdAr*Z0&MK6>|Ywat}+9FEFfe6E?xv&_o%__?ug`SZg&gI;~vP<L15)hA46
zsO1NA35@S<962~@je(OST~aRh<**)?Cyo#OarXMI>BX;3MeKc??z?12*7+un-0XsF
zM{~U^egteNKlf?ayALy@-Rt$UjvR<KQXH}yQ1Y&-nc`hHzv_M8y<=ObE02$B3D3rR
z9MhS!e%;-Y+je8W6{WmgmJ@v^H$P}bwB>b|t!!WAa{KRV5}Dlm+VJPa-+W&@&>!3V
z+w9Gq23tRFJ2WSF(10cMT{Go!J6|?$y;*IyZrqu{Z<c-BtF^~>`QW0G&DUn!uGvz*
z@?QZwx2-(yPCho{)$xMybMHTh+tt)`(56;JucNoPd=J{8X&+k8VvHK^U{M}#dF^AT
zm&`5xaW*4+RfF`xG09)X{HWH~?ZDmv-^M);_F$j4QPvmr<>ix02krgM>Mr~_Ci2<%
zLq8u3HE653E2?P9_@w(8v`_qQ!cZQh@uR!udPlV(?XT~@-*e3T;FothJ!&`eb@}%}
zO*WJdP2>1b*0=t9(AT~_tUtL;ICp&S&NW}V%=b4k=-J`Lv-Jt%q*t5iyTQu!eU<l8
z=jmu!q5kKPgwd@V##vT&?`&H5ZF7tMnoV`~h0Wx*yDZyK-bXzyC$*?ft%OR|d(H2z
zA06I!&bb-AYd7`_Ij-pPbYL9+MwN~zcXVRn>;dzKPPDsFZ_5I^TFXy%9_4Ii(#d7!
z`t(AZ_cdPf&Kc!)Gdfg0DOPj*n#Rp9zbG*?A5wj@*5gYR9rQO$Z{F&s^+C4TJu^{X
zj&wG!u<7brZ|hC!bHOR&>yRMb`}wzGPMS2^?C$ikS0=w@QLgXOGr9%q?Orb)JEY2B
z*QRY2YzuYuEZ!U%7S$?feX%?vif8+k_1Uf(UFqZwkMNpPZl_F)uv+tV?(&J-Yd+g_
z@0(xxceC6|-0M&t=g*5}ADYDG?!CWXBVy1?^MRe8XAXN^FTTYJ$NTCH&cC_K`s#`H
zsh`&|yPtnze7KF2{N;MDNw04nterXHnAyP8nKmUmGe`3d8f8B(zLs-wTjxPzo;K`0
zed5>VmA#g|T2S0(QO3(#^Hc3=+D+wpS6S|J=BkjuV58`XhTr<yc3xvQdWlbw(SRYb
zZAX6h32k(X>-*=*a=lN~KB$*xdaPnjpP~W%%oc3Y_;PE&5&NdWo-;M7mi!FlK9I7U
zuXEw&u|GB5R&y{NuA8?Z=1SP&Sv#Zv8{Y;!F9nQ?VgIYfO(R43;M^MfZw&5p?fgyq
z=Lam?9vay0`-V<y{9W&i(ENP!$X9N>Mk>#zebi6&k5P2c%BeXqee=zd(2QrTW?c;n
zPjbJtYgxIYy)`7MmGXM+me<PaBVIVyeC2aU{a*Z(w=XO<&z-XH{aOF3ulw%rAEhfv
z^V^H%PS$?;&f0E~hnYvD$3%nG8|NiC8dlAn(0a(1Q<-|r7S!W=kFvhB><z~2Qub5`
z4|%O)_+g}DobSaov(}j!3{jhxY8Af1hTr%p%MA^<o6@1`?R6V2r@uauu{XJkiCxVK
ze|3G>by>r@b5bX=uh=M;`_I>t`U6D!;x~J4Gg-L#;;0aJ?xlwW4LdM=L><ew>LY7*
ztiLpT?>*i{qC74qTxgKc_`U4ZP_+$PJ|FJAJ8S+`*Ec+R{Ibi~l*zLnb6wI)SzqL#
zX6L{4T)EbuR>7w;`(N}(?(kJ%X!Aa9>WS}_UQaLB!u7qfT=0o>zZ1KvcWc%ozF9{{
z!`f|k9?JDFoE~xc-Red~bDHvfrm}K<H>cb#T;`hbHqh^VjYFwhd}qX+jhDyH`JBJG
z+{ATb0vGf6i?Y7_C5>z7K2E+Ic+Jyy_RpSnJ?1nGtsd?5Vc?p9PZ#ZXDB^c9%KFYe
zUpevl)PR^5_dnYYT(iLMao--BcHP@jd13dsZ7YK6u^+@K%hfv=yTCcM*2;+K{wueJ
zR$l9KxwHQKuJ@;z747)xYT9Nl_a~K~tB;<}Yh3kco=N;-3(I!i!{yhfJgA?xv-88m
z_y?DbT>CWTH%ZFl==k3L>2~uwHx9KPeCDB3pls{YV^7j%z14p>G&r^OrhW6c&!zm{
z7@A(~jc1d!74LlYU-@;(+F-lBMMqLPPJYv>+2oDsCoTA1`&qfZ`zxMlFkMG;ab?ed
z)yF-gMLG-S-0KikYi9Vf26sEm^5ninJ>~bAD94nng&}WWX1vZE<&rw0$)l~e^auGp
z^xU1f=eeY)eu=+fu&?qxwBl8(3wsSSvb$!>PCUHx(*Du7NA~su-o_hxHf!cPVm9xD
zQZCnFq-U{)r`cQI)3Y>#Enc@e{oLfVqtor+pEGx~YTw2`lKY~{ez`dLNZbVdHr<l;
zMHdddfBpQIvHQ$h6m2kCIn(vWUAyiam)Di`HSN37w(4x(y$f$tp7h;3E&p3p?>;#%
zcg$Rs;MDN^vEgSW>6&tXK4i4t>O?}%E#7VmKQ4`aZ9U_;{yV)18a=l(K6zrLLY?!A
z+hDOCXGV{HJ)v3Bhk)i+x=ixE+Qj?BE!S{2i|Ex;zpl>ScZTD4Pi;}Ib@ue1@zK8B
z{LOZ?+J1KOy7BXdUYgtg;q^;WMeAeR_fhV)^1LCX`5X<}V%#$K_1U_UUru(rv(wYH
zMX=V}Z@aF&3f(B@`oLY;&#yB-t#?&l_A0Uctu=)MmYQC4J>If@*puXK;}fT4&rO#k
zX}R(`XKc>>@XLYrO^-BcpLwQIv$@*Q^RCA?8Xa`y&~BY087~`g|5UjjESpiyp-9c*
z!tDW?*S()Kp7!?W<Q7NOyNuaCt)W)GwqMtC{im$YbGJ?-sf&$|`H}0<rZ1Kq$}SoB
z_*4VAu37tit}l+&Tg~^?c4B=m3|{tiTDf_TQWQQXX4n^YeiHC(K=XQ+uCE*IUH`-N
zTt3T<3`DtNBcDcF%YAy>W?X@hckh_hZB0jRJ~i9X`(XSV!=%F__VTv{<@U($ebLLk
zr?<zK-hB>C7@Dp2bYps9z^GS-D`tMyk3G9@CG{!S<Db7zw^8=<tSLr~0@sDBFA6zY
z%ce!p(!3twH*_lMY+ijf{#;n|vCsM5s4S;<d6=TcsFm|m+DBDbK4P@)1AE_@>UOI~
z*X({FrO)UQj{I&;S?)v5$`FHYKU(R{%ag}^8lV2c=5p|hrR~~BCQZFCZ(|If(QlRK
zwK^}a*88|GH)Dsti$g%7V@<c~`2hy24-9?p(S2w^b+>#zx0L;yG)(b1Xi%Lw{_#zd
z>-1QanLE?y{rJ=SZW?`!IJMS#FZbb&EB6Dx?{?E;W74AxbjD5j5PYa}-2-u!9rU*J
zTYuK0^WIh;`25|b?7!zzyx%77-+5s4_`2&741y0op8jdnp46qg_jdY`v(Y>JJnw>6
zZnt*{!xB&0Xph;tq4pHb`7;01g0wXsI_uS6<7Dx@a8WE}w$>8c?QptJxg{N!EZ0##
z5Z?FEkY~X=_s@LS=*QyRsq5mVhi=))zx|_Z-`y{pr1SS$Z8e*8^^$W~{Co9-!PQL;
zjWtblZKPJKPLmg0mnh2}FYesw#@)6(>;3#zoU=dBC{EkymD890CDz5WUGta5^BtuL
z-)%YG^lUR5NeiBDH+Xltg<0Fz1s;PhR5RCG8?a>QkKoot;oKimmdmrZe{5{w`7q;H
z+Nw%f>1)q*tz7^6w>0Cvr#tkwei^cm<EXBvudkJ5pPnOg^qrT_e0KBG%u8`6q~T{~
z*EsHV(<o%)0Pksh4`ACF$~8_zHMM{F^ZsSM5mmPy&`b7goK$~Q@+$3~rf<{ge-rmG
zCC)L1a#Nei2gdH4busQrWVr~_$Ci~B9PEEMQr54@vV^UH`VZ^yjt=GilJj+wL$6vr
zCp3I`YJkV!22Gd0*{D(eZT~m!Yj#H$<W&mhCk@K)W$nK!j&<01&BE$P%b!QLEogU8
zwtkxW2DSQoUJYIOsmS;nzjv%5mRo(s_vFg^8$SNjZqb8Qw_5hNc-;8?i~6}c>`mqk
z@Tw8P^_s7;U*21JM1{TZDY0_WHg9v@)8=s1{fY4_3!9D4AJ@a7Q#^gLNm;IYy}5;d
z-SAwsuz%WyW`+^z=RSrt-FNrQy3ZLt^IzQ%+oGMaeJ?|vmJj;gHP8IXfTU>OXuBbM
z<zH@3_H%5pHE~tD{ez15H!hUdv0Xl1v6<hi-{KQp@*0oL$+tT6#HmlL>4*q(+tyDH
z?3}!ScakZ;AN4&t((KE7pYI->T2JxX+_&;!S<(ruT?3_B-_ta$Tc4RDNgwEHKdAnO
zuKe4&_&b~ydF~LyNa^qQMvfxZW_&c!h-gnVA&w<-SV-fE7DN}KD-nT9i4%!*nezRt
zr-)M+KS!i~<$D%vNuO5zZCL!xS}dPaxMT$}_)@MKaR#vgaTf6kk&m@NZ#DjgL#)kw
z0mRnCK>ibd^9~}4^^1h+Z@H5A8?UIJ%V<foO$@ClC)TSq@dB|8aXR&KD=x4e^>Asf
zd~YnLL}mS)QUbe?--S4k$fgT)B=#hF5c?316Z;aYuslxBf%S-7ngsSGa)<_szcI6Z
zfvL1bymR3H5APa?a%BHUCJLb8MB88i8%#nN5|NG~=#FRK#eel(0S0W$Kko>T{=6fA
z>&gE&-VtEReQ|62d4~$;ykXo|Kmz9?e)9K^?@;;m{R+Q(w?f(XDzppa+^YD`-=R?Y
z?ga79gj|$;UxIj7LdpEU-;>ZW<bQoX!hhx62)}zL!auzaLA(p$cke;?-8&FcEBwcI
zALu6YdlFdT&+w-Q{`A0~9{AG(e|q3g5B%wYvOU11m-O?eDu*wgUDbFmQ&p~caFX%o
z*uwq03}Pm(;}%MXtxW5MJ}4bxNyp(`J??FwbciR<je7**dEK3uh1u}OTm&Hm3$Ykt
zNF?sYUL;{Z#E?fDUSb8~tFQ)(7+;EYq}M|X1&qJJTZrK-QJ;HT;+c&Rv`st<EuM20
z&o%EdVtG*1VVOknMSKr&FV0Y(6%r`B6a7hVL^Q-Om?)kb8i~;uL79;lh0;Of_r`ZL
zzz2MS7@829!UV0*24eV0lu?HQ<yCd{C9e<Z{;Kf-jB7#{Hnd|TY+;HvXoltxLtCO5
zI-rv(Z!~c_yjA0NM0<?II5@!>JE{LZo}zR}ByG;LZV<ynq8p~D#w*g7NwhPGKHLZK
zJh&M2=zsCt|8TZ}4dS@B6%UW*{M$F!&i2^Ocz5RQMIF7FZyw{~xd?5p&(Bf6Hutb}
zFo%2*tB}8$n=xC&4H?z2o%D_}<4L3slo>xp`lM?7JTXm`zCygJN>^r?RaEPIoxChn
z{ypLYRr)FMxhkzj+vKYC7tPQjU8T%;72Uu8Hd5NgFU<FsYF?37m9o`T<#mbG%gkGy
zd266_(4k$`RBh8Izjm2v^++44#;a3*%`(eqOWI5|UX%ItRCRP9uahdj57APU9!#`W
zrEQ2KRO!(~dsTWo(M6S(QJ+Fpr)cXu@<UY9)XCRSO>-x2sw!WU^C3M`HC~Z2l~m=H
zkhfHoA5L7aN{eGk91mhY6vw29gV_(naW0MrvF|3(2W9PGd?$7x5#o0|V$gyf91(+e
zD1ip&L|zRi9YHR5ot9)S<2gL=iX2Ic`(*|&fem<9tJD$B@IfHNJN6=xjRKTFOP%>(
z0(0;hWXVL6G%R5QXXNtT&bT7?qF{kAL?Qu4kcv#WvjWLTMJ7tno4*U#z!823Lktpe
z1gR*2MrHa7rsxP8cp?@BD27HA%D@?kNI@F3=w~a~ViI&YW^Eu|G#!p8q(gkJn8F6)
zW!B+{K@v{GgzexAAA}$R2DPXg_Lzhi<e~`t&`Z*W0W4sJ7$iZ9^G7>`BL+!0ja2pr
zJ<cah5RPndZsFWv14npbDWZ^oA~fOrWC0%}A_Zx%F{ExJAq8O#h)Bm><U%s04DKQy
zCD3Zfx}rC1;R*3_-*6-&4Oz&+J7_gx9bo}0*ux!BNJKU)8Z$pqkdFK&w7V&7gfk4A
zas0v`OX1j@@`!=93G>4mvB*L$oLf*oQefSZHX<BZP_$w@Lt)DP0!xU07%d4ocn8zg
z)PZosAio{+m{AtC@JAAI@D5A4iJgipXmw<Ng?MjjIwp0ZEOPJ;23_elh<_w1r5oD`
zhTT~v@?mH}8mYb5e__y@K1UYBO>k|ThN3TRLX0)jkPE|M^e_AoIfCUQ8_A=n3nehM
zW!>Nd^D#t(AjgjWuxA>4VCl&EBL?<P9CJv6_=AK6+~JQz<e~^A6X+jj))}5I%!?$5
zKU$c=0#>kvGd$ssFhn2*i8z8(WFi~s6X~l-L}<COe;`Wx@6X}RL~%{DQ8mue{tSP5
z;7<?y>485z@V{{n$XK_s-~XdI|0i>eG+l?kZKHH}O5XqO_XQld782J*Yq?Go_XG~I
z&f@-nxHk~Z_l@t2|3K+5ne<OFUWeayKn6L){eyBS4{;Aco#;+E4WcG0;LrVp|N8v|
zE&8t#TA?-C!VDeJ8C}p7-68JR^bl#H@;(CTzOcjxu9H8a2%qp7mC64?EXG&-g>NW<
zxR3Fj_ya#7h5?kf!e9)67(^Xapp9D4M{O9O4(g&F3{fB3sn>}3nAm`5jD~20#%PM>
zXaO<k5UXMy`&2MO5r!pLj+KbOT0~+4qOb`u5JTB{s!^9Ns-p&KLVQOOgA>QYc&z6b
z@IoXuVjVVMBGV>e6KQdbh~vhM@yXaiUMBU3?_b+6fjnnKk#-@vBAWDOY(*j8_ry6y
z9CJE+XQ_(3nru(L%Q%o8j|p(WMDivQC&L}{Sx!63o)qn7nm&0Rm<DskrxU&513%0{
z=`gzy%R*(0z(|b7SWKnA9Er{-J^w9g!2L;-4u?q}QH^il`{G2(MiYC&jkL&{SDki}
zo(2cXj>S0DJdQ*sjK>5x!v(HbPM@yCYD8cS)?ytZu@R!*W3Uaeh{sMOVlVdN5Dw!g
zPT&;IA{7^L373%$F-&CHli-HQm;!f*!Hae9!3_984AqHxsEs=CrtG?g><`!g(RW|z
zhbYpUAhxkMCO4Dbf^CR}7!J_q`>-7zn1<3}2kGOSQ<q>F#4wz^5g3IrC>?f@-cx2=
zEblPm$8a1c%S;R5cwPV>+P#pt2%^nPh)W^bE84n@^iAf=!YxdqzdR6(@|01BCMrM-
z3(4OAF-#}=VwP%rB>SqZ*k2j$P}g1DLpC1b5gsE4Pw))6c#aoHVSVz5`FM#}c#Q(Q
zK_SGjoHnn37{vPdLL8^1$Jz|W4cTT5&=8H$3@sprXUv<6=XilU<l`k?;Wb85$8dNV
zv+W@UU*b$v+J<Q(FbcM~O&^RVj)5KQAqFx1Itr-sCh-kX428tEc!&3@yo<y%T*75s
zLFxLHT{m$*<SH_74Vk!(8<@*7ZmQDa0lqBK!Ngm{+p7FK#Je~|pUvXF&pp!jv4nC<
z@qqMJrY$F(P5L1o;W2XX1WzG`kDTMg-zmho)QEFX1H9zC)qrzUAn9O)U;zrqTS#1l
zC0Nh)Xii*)<uGP?IB^vsuojUJ!#CQZPv18~FZSEMuta|hz(9z0EQL5%Sus8s)))pG
zjD)y9H3nj6PF*HwftKjUGWy~#rhkX1FNOS{q{aFTVVayaYoLN^U&>&gyn=P~*9*$$
zLky?MbATfzz!hRROFXYiEB^*X`Z{i?@+?_Ke+<AtSV6R75OFX{+hI+5D271{qP!Yy
zE!`F}(yd^M)@XyaXa_OWCK{j)>Y^SDQ6ENV0Aq-KwjogrjfjoW1Wi?WB~1U0ANUDz
zfADv0k&~}LIh2PwG@ywJs#uYzg-WXN%ET(rh7LYZe^p{N=%PAmpeFQC3t}ieR?2?n
zdN8j)+bjTq2u3ItAPkGK3@Z>0F-&EiY4F5!c;R=)<4p4XFblIW2mT1aJXH)L&PRx9
zJe0Tq3nA{aisNn>Rv;WJu?njZfi)0ATaJ-x922^zjvClWUQMDNYC&8xi0g&gFhDz|
z*CEzLJs6@s#8A4wls$HvQ{I^A4bcdV(Stm3|FtQaq4d}_A>9HdOm9hS1yi&}TZmyT
zZQn(o?#3P@VITG*83%C)M{o>cNMl=GMmjQ(iQny4*U7($EZo68WaANXRPiY>7cW%f
zFNv@525%wut9K%z2%qr<#rO(wk6R4C+porQZiq($c3>BFV=wmM0Ai?L+y@uKR?<gQ
z=~&XoROuAr2YgbE$1|-r`k-`3AbpbQ8#vdTCZ=-@c9ximi@1cnl(|COM@%PXAQLxn
z3t}CPGVM0$JGhH%h<o$mZ{*L2&yj~$cmpvw5}n`-S4_h1js-XJr@#Z#Fdg3T#Y|P4
zMVx~G)%aXu5JC_NaV&%p7h#DQ#|ntQC#*sQ#88`kt{wZB8QP-*u8`M}*a@9cdMtDy
zZ4LvbcO`a1cUYh&#PGXgVI6IW#CmMNMnoYRo3I&T`)+|4#P;2$N{j6qr%G=prsBM6
zd<StSb|DeFu?I=mj{``?K^%f;+cDyCq~HWjLVVtxBA&(>oW(ha!HCc31~5h=G{NtV
zp=RVahY4Ds6-?0@ZB(%>(G2ZX<DH0|VUBJP$53}-5A;ND^g%yZqCdn?js6$E_3H;q
z48S7ttcZhQjnZ?=Fw!>AW%>x>D2#?3>>&p6U7_^2j3I9uescYBk@j4`an2_va0+M8
zg=0B_cm?SY!y4i`Y(zB7DHB873Q@PX#@|M|^qM)A^mfD}0b&sIbVX@fx{*G|v{anO
zMO?yVh#`%(UBYEtK{~D?1J{s=8xWtrSrEf5;%(f)T~*#7`gI6~!UiMpySCVpKL+*~
z3kNu10$fyaB5^XNsK%!er^6e*5Xa?A;%o$99s&`BV9bXY#CPP<V=0#H5eJzb=Vs;~
zPrr!2>#f8ptj1&VlgOWiIS|7E;z1n35#&(j81Xnn-6_OVD7_v!L;4(2aRFiw^E^Rm
zTb`0$%km<z9viU<F%ZK9=5vM%Trm-o;D*VV0(XdQ;z1O{RN^#vV!A5tKGPo{8xQda
zziZ1g@^kSVFOY|Pyu>S2d`&FC8`XFr@h#rrJ;ZVM5k>ff&-j93e8pc7!|#q0IosrS
z+e$%x+439Mej8E3aaFc_G<lowo&2)p%N~bj^vOt!f-Od44D4W!u^0yjIKl~H*vdAE
zMI5#x9tqfiorqz*b`h0jNhhk(;+(r%mEJ=<j|-~ty~HH!!+sn<G7jPp4&w-p;uyrS
ze4Lnq6F7-e5TBE$iDz&Y=a339w5R<Y&=H-`8NWLoyOVE$9_Wc)=#4(;tBU=Imguh<
zA3z)kD-41-9tRVLz#2m_48viA5fDS!ZC3VplyP2DLmSRX?a>ik&<#D%8~xB9gJ2CY
zD43@_)S-!r&_X3thS)Y$h++_*huW&N*fu(<bX8(kbXSe*5^F#YwNM)dr~^Y7!59tE
z7~+_2N^A}jw1g?d=V2RSJG4g!bb=VJ(*6uw!*$%i?~cnX@^9e|?&2QqLp+!8NEM$D
zpCVT^{(_i?e7uG@E(?io@lK4R2%k`lZxF*PzCXW4>2qKTuIV(9!7(WA3A$l2Zg7ls
zB2IxjJTMiVF%6!Wj!@3MUPN#Bz!x(x6MmQlF?1!)#vJ$~0NpSb^ALz21Y<rz5Q+s@
zh%ktu>~m}4d9_NYfbyseEj(mh#CQKUD8y6Nr6KVx-r+qypb<Wz2%qp7Ur>y%_zT}q
zg6|MRec})N6yuzW)L=wfMwCN=awrdVXh0JcP!U=X!wuRfzDMmsBC=_t8F4rEU@wx;
z9{aE#2at?|IE2GEf}=Qw;}An@VhT>+Bu=3XPU8&D;v7<O9v5&CX}E;T5JNg`6yL*o
zq8F~v#umih=!3rKhnBEJe+<AtSYZ$bV+gD<6vH5frbHWz#3<OJ8Af9a>|l?v7zYP9
zVLY7S0x{g7jp7<S9ar&~Hr66$;2JV<9s0O|o5;c~+{PW;#Xa1|17t%Cb%+n~2#=A2
zx_E-8c!pd&#|z{^JU8?bukadTxK0}vkzR}?xJMgxh)b~y%drAg5ssBuh1H0_8mz@S
zL}EQQKn&H18xe(QY(foeMhv!KE4CpPaoCP{Bwz=`P(&MFV}C97TYMt@9!E)6!hiO8
z>(4nq0CO=9f%x6$PZ0URn2!*IVj&h`i7GB9hGUg#Jc76uk=Ow7`4dIlgcxi^9OAJ9
zyC8=D?DOY4=fI!hJjiFK8f5t0`B*`IIh2P6G*JN+p{0tIiQ3RnjaMhuKuzdDoR4b}
z^-&uJsDrww2SbRV2YuTM;+?j=Q4_D|_atI@yd!;tsD(_@*%-q)*No4dnW}quc8qss
zJDQ^#y2ApO+0P`-hj*FhCXC24Mk6#v6I`UseWu+*8^+tAJvyKxE-^ieX}2McPZNma
zy%kK6#`FhFy9RNL89*E(^<an#Ouxmns}TFQF2w#>6M8t$^wPgOX)>;bGvrxu|FbLW
zJOHCetMg1^CwyUiGVvv`FL4;gp&@-SfpXQz7vJY9QI9rKscR7V-O0DcXwsD_FP?Y&
z$+#!+Em1uCXbWd_;_qrMl&enuOWM7cSPpMVA0k%77t-RpzG!nroMt(l$nTHg%v+v%
zI^YxIZp1udAL3Aqg=nt><!o5i2vlKuX}haX-#O~*Lf#OJpj;*9>5lJ=Pa_r*2NFkN
z0z{jgC}&F?4IQR8gLwY)Ez5d`_xOO1D8eUv#upUhEB?Yalt2u1nP0{}RG-)!jnEi|
zXaZyC!w7ZI5KU1V_0RxM=&QN3u@>nW#M?w&;%VY0bf?`{iT#Mj$=?if)}ar?@PW_F
zkB~EcFVk+KHtE;IrD#n03-Pf)J#)|+Q&?`<bJ0Pb+dPEJ<csH87h(*{5P#SDN!~LA
zQimVzGJhT7MPdSaQ1%+JKk*FtJ0RLPNY%!w)LRXjOh3r9d#F$PJuw0;NPj0j#}n!a
zLI;R8mY##e_5We&ID#wWuVkKOP@`N0_K8#M6PBdQQAc}-XLu(OUl4l}tzi$bZ`m>5
zH|nU&d}o<&Fl8z-ts6>6PbIz~4j_)ic!+&ytY|0m&1T#SrS}&+*w-tu4JzX~^<8J)
zYD_;xj7AscyF~0oJVt&rME~?w^-lrwy@8DBdzf|u`lMeGm!J{p&%{T#Pd&3?iUs70
zJ`#Tej)6CQvxISx7eYEpl@2DoL6x3QdLwCn>heM9_wik<LlxSfjTfv#7WLO=`UPSf
zy0WY*#6HB+<i|s-gOzF>w5Ycd#5?AbnRXY3q~8%&!Gv@PF&Ej?6NvU$O8y(Jxj)dR
zJnSY<f%oLSMK`hk5sM(6WjKnDlq<wR%2hxv=^aEF3P>LyYT!BPT|_zFkWMCQ;t}aa
zv|}#IzDN|uPZ2)hGg>fxDdj{zifufQ^|FFH<E4F_MY#ry`%*_0Ou-)V_CkyN1mX_t
zLV3m$iJHXv)MJDu=*9SE)wCF*8~rYpd6a3#FjUosp2W7)Kd?USB7Zw&evLKB*F#-&
zVY;ZNGux&MLRrUR#vh|K>3P(3l{l1X;<(gBb<}_vWg=9|75l~@@&?0${L*#5&AK#X
zd=B+ghX+d6s~KhcFs&1Lt4QxA{c9|3t9Wj_E7QNCD(yMRayQ~A>5UNkS1*Vmk7edV
zje2)8?K*0aeo0)6hNM3cA7U1Dv_dF(`i!3^y$z>G$3fIPP*txwZP0)^We+gz4(gG9
zOI(TOq`wiLVIFmuVF`I{*j7#XEHyz(v_?C0KxcGCca)wZ#C?jMjQ4>h24XOVVmL-&
z4D2xu4shm}b|Q{PZRU3&PQnyS#dMSorOOfLq9Lr0cpiT${VLkIiE>-em2@0YJPRbs
zH)NfLur6X>nZmN{na7Xx1@guDs1R@Q4$aA5!n&941DWL2BhQEVD`O%`_W@(->CUt^
z<Sii`C+7VnmhJ=k<aZEdY1@774LrajJjN5`;sx^Y8l~qeac`lJ@wa%7B78wHzTpRC
ztZO-FLJNzGIKL5faD=w$5^F*qbx|K;C|!m)Ck~~3!!S+N#vPQ|iC(lfktq67ly60!
z4W-U>qBsv$MipqIE%UA}(|0%MyZYqK7HxnVO8c%6<$Ex#BY7)H?;`zcEbTi3rgvic
zJI;;bdP|MZGX;**wgJp<&NBO9BxwchGQ&s4Cla3%dl84g4&rlhJmspAFWx0BuD8lj
zmj+H!-$15yW7;6tlCHo!=J<<o4`KnaKXC+{AU-dhDW^+*Y1?Gfb(FgLkS9^54c?P>
zAwDJcAP&N4i1v(O{=Zni(zcXm{uI#`%4$%iGm1%1A-*E^BMyfH#PaQ#zl8ZqmoI1j
zW6a-?vVAd(=`zZ;!w1G)iO+~ViGwi)q8;NXH;np*qcYP=+oMi>C#bJ8dE$3OHk8w3
zo-X*xxI6JR(UNEbM~HSgQf?%16ttQCnKs&ywnqfhnzLO^&;|pUc8UGvGBQwyadEtg
z&#XC2U#%MVCB2Nacu!Uq?m~~c^NAs}vFvXjr?Q+lmXkys`)~&0eUJa$<FT}PC(f{J
zab6MMqt`GVjf3O`(_dxFl%4jU<=0@HOZ%@K^$en(-K<{)qUbmAc^8EBq)XTLBGYUB
z4~&cJ1hF1TxJX(&D<i(2i}l=w<K)d(^+9QwveU}WTQ=W_dCo(8UcSUDyhbzXTTK6W
zv+XOPH5Rj+SdsrrY{C3jAU+#4Q2`avhO(=uV;1vPLkEPDzmxo5qaFL*LO5YATp-T#
z;&bgY=NCWHL71b;7w6I-^5;W*?-gamHQ!6deO2RL#Q9~maZ8rnk7bu0Bk8PXZN|%f
ze!VBpM3rYw`K}nwxY!>=IY-6=#5nD0PkM-I+Bnj4NIS4RQP!F9AY$o$bC7wf{11$a
z?Y;x2S$5guCW^dd^2$yZ`^7)yuceQBQEn9TiuIg8I*>S)z7E3#1Y#n@HW8nrf3Zzw
zk)DqLgqGPRrp(`;`OAI|>X6q?m1jY^2SzY1mM6-M$2>94Ht0xtDCud`S=!gf=xZJF
z{=3ITU+%>PmR<Jv+)Cat^2$yZef>}QqObc<ZZz}eU>AL-!RPH%j-vpMH(%Uhy>*Bw
z#7J~wS~{^W@d)`FAg*D1Knzdmn`e-ip2)OJ=#kDRE`l-XB4RckQqN4Zgy{RS&yDP(
zUHg$n{&MCC!4J~cxxSFGUF5X$DdW?~pGRFYaff>Ji06n~VZpQvq9ySp`LPgf9iVEf
zjQZs$&-DFFyN$Y}3yCYxjPzf`r^un6xo8K`*3#!C#I@@I>PW^V@>ej=Vn~#m#eCCI
z1;-d)i$kQ>K(wQ)svUReue<m`{!V0|26en3E`Sl~55)WMr4ADWlQ)NPZ`8mU@-`!d
z^cINv`>E>xLfyqsFi#TGvS2{EfVd1zNEZ`x;7=WG5Jp}mQJcKu#C7OQUK+6{@i6(3
z5X-SpEhn30Jj74(ci|dpQZ|pc5DiFwBtF1B>Y0HSm{0yqVombT5@TRa-eqEM;tBG%
zLM*GlYFQ;L=R3+VeIL_qp$_Rc#N}v8`YZ7X9#BsJ+F}v;Ce$$&<FJNtu{{^C{WcLr
z+KcpJ;wz4iH(0=NF@>`3h*g!JMwx}G@}8u_RO#uY7pc-dq?fAFp`@cp2hkq!9Xy06
zmL)zHXEALhX>t4};1uby=hBVj9r$IsIKKZWU(_!?Gv{HQYW_W>&yy~D{@6m^(O;&E
z`u{0k?EB*Lvma%hnZNA#q+iDEei?UUd_3Djv~eQyhY;;m<93YCU|dWSpNX>>UqyPX
zYPt>MUaILMNPCmEQ%xJqxDVswRO4eApUt?VYTSkKV8)$P<F1U)XIy-i=yI=r2~qj`
z89rB*l3ot+ol1Pp^rx&VWy_9F{$+gZFXQ7G_f{=Se6|E4k~|NQ2X{<`C%m98?%}d;
z__Lp-62-YR7tiqmO-22bEB)?!lRP8x#PcrVT>z6&pJf=KF?ur1l)Ocxw~2XwiKXA)
z>X6@=>G7=ZD$0v{1kG7~0O`v_ah_D59Ll3LWy8y~;}-2OCeM%ZRpE}(b~L4YZ>F^;
zZw2Wcq<@X2?Wo6ebEdDRtoUACmt~)YI6vOQeLO%T$}C{{o|LPAmRQKVTgd-4HevoW
zh;!gq{Dp65N!ex8F@t%v(GJU~BVOeH5)GMuFw@Tw#X0T~9wP^h#WKtE#WnKkk~f|5
z72%4~zGy(b-I&&jyfD&RN&gy4`=S=p+cUi>%e1EaC89Xz{lHI1OmD^X6=jxvoqR*`
zW>Q`UlTf<shLpEpni+Y^Nhgs0HI^>BHq$#YUB>6F_#4(Z)o(dis-z&VJjC%Xo_!Pd
zgK9B;o^xgCduo=kAC+TY4rE!S-+@|F=K$&~y*|E5TMZZ&$GO<g{g@t3y7ap0BzaZ;
z2gb#DI36cicG>gr2J-fkS9ZEMPySPWP?<hxOL;5m5bG?CskvB7x^$gWS?3!61LI<y
zb|aN#m;G#rA@2xzWv7dE{-=Dge&U#&LD}W1`Qu2ZkS^P&YspLcWxA;UpYlch;&}F_
zY=mn5U8K*FF5CW1<Q@8Dx~Tu3@`E|1O846ql<!L&rTgs_maETr+4H~?@|vjfI#a$2
zhA}SMDatu8?k~pqyfh;{nDi)?QM%ptQ>GGm|J~zayKct`mR)wctS4_Dd1a@Ie*33<
z@tvY4<wi1ZNSQutMV=*jWzSz~<e94Sx{>Y<8^%SSiE>Vi&lThJSqIYAq$if?v%{3p
zCa<*5{=3FSpCsZO%PzaGZ6@z9d1a@IKKrM9(PzCWXUn|%xaV>J2XO>1IIm7(nj0o#
z3PLI8PV~T3EMUC!+N&?)6Mh+=_{;d1U&b96A49(mN9q1LlX_N=KZ3kr7zta9M(OpB
zC1qSFQ+C|#mvQ@F#+?|SOdX}$IDk6Vkmo|)1USPLli-G1^ucZ1#eMumf0TVMm-syT
zpME!21MbTjqjV7WX>DoeXpBK4#v7xFs*DM-C0b!G+rA62E5uOty>9>XPPcRXUEu;s
zhyT0pc<aWqFWn&q3t|sd`v1zi-+EHEm#X~#?(cys`|dUI+t&Z5?_cAUQ<5co5Q8M7
zAPreCP~*E05+UBjmI`AT<q?A<6vIl+XCKmV7x~auaDS#e_gG-4&iNJQu!IdFk$@ve
z!(HT~7_pk9Q4B=|>VhF+Dsr8RcPK$`E$V_Zd=QAGXu|u|JQ0Yc5bs@+DpL;(Al|oT
z33vD*1mTE60>r!5Y<bUG6vTViiXh%Ap#|~YK4VzG3gZ21{s=(~5|M^nNE}n`;Eymw
zA{Iq3=UUYYwunMD@=*-&oAO*}bIgkO35xf$*+aaa?KE;B-pObPQ&_+nDZH1l2nw!w
zbzzJ|uKBW2fMSSuRQezU;Sld9NJJ*Y@1RXNw^<+xsW9X-&lDE0hIn^m0*=7YkUm5f
za`6sQefk(C=!g&;K_(PNtT(Lw5BBZ{tjVf>{P+;csbpwWSY%77$VfpEr!GSyrJRaI
zIg4VzK+Gu<W}=a<#3GwUNwo@#Y}G6@%+*6hHJ_-cR;^q~NwtiUjEo9vCFbw_8Mmco
zUwWSFcU`~V_qyD5y*l0JKKD7FbMCWyf0*Zn0j)?JO5M;ShVM`HkiYlJ-*n3%zh9Q$
zCwD=9TNj5^$iF2q!i)-3L4G?gzlCo?D^&a~%7QXfKz<u3zj16p6a46a{03Kp1f)a$
zO^*fg+X4AZ<bZsy=7X%^)&W%l^8xXwLJewB4_VKx0}&T+o)8Ny(qM!crKmz3;)k;j
zMkI`&J-Fb84~dD48`6;pBg)`FEt=qmtN|C9M4gBlNuQ7aEz)3w6_uz(a5Q6?!g+-m
zWpJVn%}|XYHe|p88=R;^16t6IXf16a9Trr<2`@UJ8cRLMKq>5SzzGk0Xoqba``~~Z
z9(d7=PDG7oED?`nq#_HYs6q{DQ4c?=bd<f2enZx-(@h}Oi|8jRP=y*apb4!AA|jQx
zP>B}APGlV6m2?vIARQ)HPzDE_sDl@6$hesOh)E+3BqJ4i6rvmsxR87a`=EybR@h*N
z18#WWMH?a}6C)Ckjx3a-3Uz2eGdiJ~LLZ<-Cj9A)$)&^wI~;Jshla~|j!h*VWI*nT
zCil<qqZJ+Kf_ggTP=m4=j3=s4gIajdf;My_GJ`RI5xSZ56Has>{&J4Fg8HG!WWK|K
z8Z<+FC1Z$qXpwpqV}p7$!8D6L<KS9>Y6IsPi715+k+T^C#3KzE$U-T~QH44*z>f|j
zUrk%E!;koD$U`BlaKMWeG-eUwwUj|JJWyXp9{kW`6AyGqhY2=RqaKa$p&e=?V~bQ|
zp%7M7q89b=qXU{e>Vg#sCgu|A(Fh+}(1uP#<x>W!$U-Sh1;jLm^8o`)u)q!%-0+|U
zK}icKJC{7fUQc~6!iNCb5k$m1+Cwa~NJlve&9sYhRH7EGaL*@Z1keS$g?JWH9{ytT
z(T*UZOXxQephX&tC_^P`(S%mWo1188phE_XD1#j?G{A=zw4oDnqp4VEk%mlIPzF0(
zXhZ;Ah`E9Dv6OKw<M{#`>~O%1Mg(BJiG8rc1vfnKq74zt7&jy!9VS>%h6*@gTFy8?
zZ6jth+|0bYg?Wcm=uwDrIN(Gb8qkbRM6I9=q{9UBO7@`*olxD%a|ZEn!G0Tc!HGIF
zB7k;8R4~3UKzBRs!-XIcSJB5iD2FcS?CeJtOslC6Ze*<C`Hng?pc$Gw={M|fzzq+)
zXhSC=Dk+Bqq``>TyLeuq7WHU^4=o5H`fmD#G#HV!mbj{j3kH~AfgLWm;Xw<6h`xui
zh`X0DM+VG@xSzPu2GfJofihIUi8?f(34U}SvYPmzg8^1l!U+%j=s@H;${`u4(4!FL
zs6rjQXhXz9l!XonkJ1Mx<A6r^(2g#|JjNJ8^*Hq-2Fb{P85MBC1GS6i6FOmik~s`J
z9B{(}FPhN`)l-}YBtnlul%oc2_|OVfE#;7iG-MzPrKo}v9<(5c=#7+x9?8#8*B1H(
zgPSpj1$H>#L>;_nLnor1WlWHcOc-HC1=63R9ke5eh<`DTNQ52%v?GY<diEg!T4ch4
zGC1Id4=rdzC!(Gw52hCwLl|D<|6xHH9B{*jcBmVeV<>%zF?pFd(e(=X9@>WnI;0~L
zMwn3nC+gux2O_sJ=b?iEW>mn5dU(-{R;d2XIY9!_VS)|SsE1#?LH?Wc12)*<LOuMF
zzQuWg4=o5H`fXxH0@6{1GB3xX33cyqt`YezeSDAkD17u^yidGnfETI{s0TWv!vqWL
zaKH^8+M(V?+em~C22{fZH$3p786Al9(=HOBhXI8sM-3{P8NZK-9jYCaM-1YS3Ox)k
z!2&y6Xh1VM5!FKcNJSPbu)~E0_|SqjM10D)ArX2Mq8v47Kr@<lvagl8(19+fzal0i
zLWgviV1pelG$Md@1QGEyZ6N^bF4{pQs!@+7w8Ga$d}u=_qQ0R&&>{^+)S`MfDcaEd
zEh&=QDfb=mAY%{b9rfQ+H(DVJ!N)?2Ojuxt3+)IZ;s@G9ERvCdELc&AYSf|$t?=*V
zJpWAGFa@a-WvGA?b!b2n{OCaBuZ#tBFu;mRIN^aG9f<sma!5uh^e99*s!#_n+7Pji
zvd|$-6{czq3sbeBtXG(-0#&F(1DfDR2O`76R53_K2Fxf$IVw>Lb3_<_><UvwAr|pS
zMkY+KL4SOhDz0}J-^YaUeM}hN$FL6pm|1w=hpayQKT1)KO4OnrjR>F}s=l;?c%&i=
zg^2FQF{nW;>d^=v+M$l*IB1cH)D!4if9gRpQlUp7%2A1G)WeSs#Ge?Z3PK%4e~=2_
zK+2s&n}|7?d?Z2#15B`>3>9#~13x+tc?$I+4F*_I0Vh20qYa%<ok|~|MLJBdp&Iq@
zqXSKRiIzN=I+1}a6rutSxaI%PBu_(ou)z)&;?JTk#15fPXh0ME2%rn<p^P^Yp+g4D
zC`Bb|QIEnnVn+}WXER3-i+H5L2rDX43)eZsbuKZ&i8?f(8J$qYGhT>C8jNtjavps^
zHR_R(z<IcUF+kmL>Od3x=s*|LBj^J((7^yRD&T|%E$BdGBITfi0cO}>hXZc-5I`4V
zl4u(lFrxycDfD3s<Dg|65Q})E!+=thqY~9<fEVouB4RAZAsJ~f!GbbWpcV~iK^r=u
z8b{nngkI9|^hHN}h(jXuC`37G(12!WCeRl|UPO7sArX2M!U`Lz(FR{C{YUIXVx7d;
z!icPk83U0<f5aukh#;aTQz!H&L^*2E0M!)QMhxPRh;*1>K?R(sg9j}LA~2Qby`FOo
z!*t5Sf-*SZL>(H?gjT3#5DOBaM<L4LfE!I{g(`z`h(|I~k%dxJzzGjp5JdD$>V)Ph
z_RXR$c;H1df>0aiAEIV+&Y-%Qej^6S$bcCYaKeM=ERKcxTK*pzBp@9oSWpHBTH(Kr
z6q;<>F_OXzOAhA{6}g;4bmY;#iE{`oGGT!oE;J&5xP1Br9nz5rGb&JpS~S6rR;UW7
z6Oq>wH`Mc(H)iUD8y>Wv4V_TUr!3-;1_P|9L@k=of*>LnP!4G@z>HFqqXrG|q74y6
z^c^}FU`3ggF}Z<!BqJRLl%Wbv)T0r8v?6jbaiAWJ2%sH7M3hn&bV!E@HrU~S6CNZl
zp+2;td?|fHHR{m_A6gJZ^o@)+^f15#3+zyp(NEN&0baBq@+RVd4w)!KIUI1pjYhP?
zzKnc0;ei*;XoYGy=MGwA!U!`;Q3bV)^N4yFZYDNZV21-v)WM53MBEal(jWm^q`?S3
ztSg8S4mjaPBidmvCm&9D;6*c9p;}3d&>|B?m{E!<sBa}k)WdKaF~R~n9B`rzUbG>i
zf*6qiEz)3wAJ*H65e_)vMkCr`UqwEg@W6{^v_f?UF+z(>7-2>!s-U(LBkEyTO^mR>
z4hNj5gBNXxSVN3RfEH;m!Vl}6#0UqRaHA3Juvd}~Cp_??8Ld#=MU2oQ6GoU(iYln@
zCPvi5u$CBMfgKJwQ3o&D5K%>pNPre;Fv1V(J;VqHoN%KN?XcfVKAiBti)OS!bssT8
zi%b|{Mk%VGb`T@#VYr_dVSybEI8g^L+7R&oF(Lt4q`?S3tPc_+9H@l{ezc(rQPo@v
zkq8~qQHWAhA^IWeMgp|Rgb`+xq8v47fDi3ZKTMrSMJ6mLM-3X_Ln}Jag_s(yB}ju2
zWpKa^AKKx6jJlp+EMP$yD&Rsr{4i}`AIeYxC+g6ECiu~T$S3I&bTGh*N;u(xA03E%
zigHLsD)cBsIjT?xFWL}MOIhf|X7Zom8ipVux3CY%NJkbdD2D^J@W78Y=-jl2DmYPx
z1~kEsHbgwj9D*K3SYd-54%DIv0dzwB9On`mBp?-8u%ZIhaKQ}^{OExCU$lcn=#Y*~
z6rvo}s6!)sXh9pg5L3@_&><Zr*ieO9_|T5z=cyA`RH6=EbRhBtUK^oBDeQ2-4If(3
z1<i}JgK{|0hyYX##E(>Dp%fKpLJK+&@e;8j0jbDDA*`rGEj(z2>Sg+ZLR7$sMg$P?
z3UNROJ?wD6iF!05fG$LN=r=OpKs}n#iRi728!};m9o1+-8#<x>cbG~8Eu5%B1DfDR
z2UM@pcO*iOLX;!Dk?}(#S`hgf&sXS>2{X!34L7`KMHix9XPl6RELc&2S~Q{sk#Ep9
z=urv>-0-6v5l!ra`YpyC{<j$y1QF%sd?OVGSWtl))T0$$h<S%LkP1Bvu%aBbXhH{6
z?-CC*NQMCx)Sw9gM7~F#kd8vw;6MPi?=!Bb*v7m?EgI2+PDJ_{JLr%JGaRUc7j5W-
z>O;yR9$FYt1}Ey_M;jtOqCTX-2pg*5K?{OVZzon{p%iww(1bQbG*bssVS)|Ss6{(e
zAG04iq$3kXl%fJIG(+_X<BT+zU_%Y+;X}+0>TBVA!1o#Pp%amxQ$KXbgc;?ih8qC{
z5gnim3^2h08ys+>5iJNp{RQU`I_P0S1!_=>dNiU1?TFk-S(s1;7n;zDh%b3wAQ@#a
zens2J+{OQ+6qRtngJyI<-4>?OKnoMf;D85yw4n=8-_U<(p+^=f;Y1xg@S_b~h}ung
zXrYG@R#c!Gb!bF0+M)WEv4a+wu)+pA9B?B5RXhDeJao{*3LETj!H-TPe8+h}A<9vU
zdNd+{PDJe?P9#DH1Ikf@1~j7sk>ArU5}-#RY;eE{4+7{yYzO^-0VY^rM?L%qpaYRV
zF!o4>0ajGOi8?f(39X3wkr<(e0cMoJi8?f(84*9xA7r5dRj5G&+8{U3jD-#cl%fi5
zc;H1FqW3b!$Uq^gP>V)H{>+^Gh4Y4nUx^U`1QGQc#~~F4SWtl))WeT1#O)&n6v74v
z0`TnTd55|K)D1t{5uxg(ibXQ?Frf@ps6`VxpbqP$vcV1qoT!5r&1i+HS1(m0Vi1Q!
zq#_HYC`Sz%;6pothz_SLbTGgQ8>-<#Bbp<6sWOhEeN@8*H$3nmfXL%%7dq%s2rF!`
zqYeRdLEW1;k%$arp%7M7q5&;vLnort)Qc=s!2>Uv(FskTUMejzVMQhC;6*!vi0Df>
z=wU(t?Fb^GA8jB3TBN}UGfGj8O4OhM&1eM!&iB0Z19})>MJ1|H4?hCvg8Br;2)h34
zLlgW6pdDR^JdqfXfkKp`3N@%jJz5YMMZC}=4H+=QfqFE;hjzpapd2iyh6`@^(1qxM
z^Z^+#!wwgk;70&mh(C$gkq#4Vs6s7#Xh(81=K)q!q7GhkAo67DfEJ~&!vinc5OE5z
zA`zLepdQT#BKlP7M+U5@L@gT7g{T<L2eimUA<E%IBLYwjq6|`zg;G?Y2`y+t#A(bG
zBqIYBRH7DMv?20z`hqlMq6#j!;X^xAv7B$Dq5>{7p%oEl&<4_AL>cVxq8Y6SB4RM*
zphE_%s6;b@h&huukqHZ`PzNts5UU|hBqJSJFry4ExZyzy)Mqiq&_IVml%o<gsD~e|
z=t9g8<{(mGKq1Oe1t*%&j4r5$Qa2Kjg+f?Si3T*mj}FB0Biwi-BLiiqKo#oHf;My_
z>TF^~Ix=BFHC%ARhb}~(L!B_d1Pg4ah8JxJBKlm;2{K_p4eH=U7b4@S2L_l?igMJz
zi#Bv2<~+_llA(tICfHDmdNd+{$YGR698zIMDaug;FPhN`)%lD$v`B*yb~xaK2ki(V
zB7t)WJ*+544SZ-p8-j?wfVyCW1$H#Ri#Egzr_V@(73HXb51oh}K|4r*7MZZ21|9?v
zmB@bRQHTmS(TFyvlc)z8Bp@ADRKbmQM2uuVQjvu+I8YBSS`kFlD9S;LG-SdI8>-=k
z2R;N4k<6S!JhaGy6%P0jKs(f<IiE;{9)+kv4Qf#jKU684Q^X({nXsS?b~sT7FWR9V
zLs=vu17?(=3N@%j6FQ;NQa9p}2_wv?fEylo(T3=;i~|yo4l8W1!v#MAXoq?nu_6_E
z6ru`Fc+i0^sK*m4l3{`smGHoacEsvv6X_^L1)T6BfG)&d$XFvCMp$7-4eHT^0NT-o
z=n3>0X|TZ#2iypt9YI7~M4zFD0Vdc`g9bFA86D_COe%4}023^*qaKa$p&c<3d43`h
zdX%CZm8eBCTG4^XNz{onWWWpuoT!5rK}1~4Ttxy5C`38j@W6`}1QDM`oybHvs!)dj
zIuLmY*Foq}2nU?-Ab?J&C({RHq7;?zpbe@i!~s1DQGpuNLzT|hT}nKtm`dBIMI&0!
ziAX(lLx)V5;Xoa{XhSDd(<qC0XkkPdoTx`L+7LON^N0*sVMha6(S`UK%pI6ej%v8k
zg{GO*1LqaAk0t~VL{uinA{7Q$Pysi*XhX!6ltV1yk%ml^!2u8a2qNk#`hg6Tp$fI=
zM5BRna9&LuXhHx%L|sGONQD6wRG<b8XoWh9F+e(uu)~Q4L|jXm>u3jlBlRMPs2u7=
zDh#lo0yU_I5ABG~rC%_k9Ch%a9g%sQOXyGzLq2l?x;exGBT7*T7d&W22h@ec3_VP+
z!G&h1=JGs38ceXE2KDeE=6cTGJlZ!?*L?mT(F>TDNJAE^u)~Q4_@OG|SR^A0g(!m^
z4QNIiR2I%D5|D;0SWpQk+-N}%>V@<JI_P174V7@A5q`8oT}=B(gdRqe!2u`S@S+7l
z#Fr2&Qjq~Os!@w31fjNa4v+~GY^Z|=Er?u1JxE3xvS3C9>d^=v0_Z}*4fF*DRKNi@
zTG5H9#l(XQm{AQE-0-0je2`Q{A|C0;gb`(^K`rXxM-VYfh!1JVLKz%z!GjjGA&97@
zj34yKf)$mhK|Pw$iHI9HhtR=*LfBA)26)kmh%(L}5|IugET}>a>fl2Mx}d&^@kTl_
zVMH0K;es1JbV9X^aX>uuFrxxhaH0V%=tAsrVnr6pPz?`S&;_-PISvhUC`1LSP=f}v
zL47ml2WFI_95wKw6{=gP13F}(6b?912QPw%TEUn=2P4W*4Hw+-patr3`iEqsA`2C8
zA%Mu0oL|Ht6=sy91|GDa3o*BHeMA~EV1@(rXha*-w=o9LAOY#Hq6%)bBcg)+NJSRP
z;6OcE&;|AF)B_E4C`1KZ2q1{)RrCoNu)vO5_@KIjW03$Y(qM!gwWvoU0*JIz4klEh
z8ZI=V1M1a`4botQ4b^Bs6a45v>>Bz63o20!7u@in3$b@{E|822l%X1as49sCF-V3H
zrKo}%K6D`RF5-n2X)wZ$09v8FoAE*^%2A1GxZs8lZ3rTMEp;FZm8gabjp#rZ)K&B!
z88D+16{tZi>fwj#9%4fbl3|1yrKo}jUNoZ<ntSO7w8(@Fb~xZh0PP4O`aZ@MdKh3u
z4eH=U7t{{QAr7gqz=mpg(Sji2@25><q8wGILjcha5El}V4l62AjaoFqhZY18_aM(f
z=wLuODp8Gkw4wuDh^c0*k%26f!ihRGpcxVCcwQqGT9{x#860SYA05y<M4Zqf9VS%4
z2@g7;dYHPPM;1!qLOuM5sG%MtK!;42U_%`m(1d1mBJL5+Eizz3C2G-vcBt1A57J>m
z73$CcFIv%ws7HILQlW<dg(!y`jR+vhNo>%;j50XTgl2Ri?lI;W%qT?_Jn*6!ozOf^
z|DZ)0jIhH2Cp-wC3+g90Pe_Cg29&}9C+gru5D_k7L;?&j!2&z#(Fh;f5wn3<kqA9X
zQI1N~q8Y8|K;)CeiZo=v3<q3jL?={FQ4X=tq7bF1LL>a>fTor<p+_0)aG@EkP;I0P
zvQP*sD$#%@_z^%C;x}>bk%}yo!2u`S@S+)=h<=)~NQEASs6q{D(S%OOKg^CqJThT~
z85MBD125VTy_r~%fOJ@4gB>pT5kNcC&(J>7U_>RV;X*z9h}c4%NQ4m<*wFwl+7RO=
zHl)D{8>-QOCioFR2cn-PJ|rL&S+K#58Z;n)b_5aq9On*c$bcDkIN*c_t>{1(V*bUP
zL>9{6fD>+b(T>P^+J_!yl%gCpXoL?f2qNZr<|GoKhXrM*fD=t<L&OWrb7-K20i|%D
z9?b|M;zi0K7756d^d+7bs6-9?P`^yu2)sh-VSG`(mAIh(H+g7(jq~?9V*}M2^ciM2
z(Tb=h;z0%~;6Tlrj1wZ?Vr<{$SY*NpKUxvxB@dOTK^+><1V38Q_zvaXrGA)EiV9Sr
z<~_y)L1g)u%V<FJ`^5bLZ6Xs<+n56|qYN(i(S=AqeMi)Xw1G-^;6vO;91jy(k+7X}
z4m&!aYNpSyp%QT)QywO`(2O=oKcSr+oD0+;2z3iF!Gappp#yQBQYVaX1&9;sFX#_+
zu%HHY(0|FfLKVEww$eY?5&sosQG+_Pv@y57p-q(SW}YH|4!FMM|IvZ+?-@t5pdD2m
zj0b$M{lNKvAI2{B!HK|r#^!h8gCQ)Ozo&((s^Nkg9(d7=R&<~X>R#chXlRfCEz*!2
z9<GXuAcYl`sEy&@rJT!}I;X2b_v4ZERZbbkx{_zG{@u{-^&I8?r4NuV_wA82<>trp
z?`_WPUVG=M)A%@hHtQf!eiO$%L^-*~P6qjRu`TPH$hxTi9?ZXOAq}mEMm_h_o~(oW
zq|*La_DefIP><Zp_=8i~Px>3%A5&h|#g}`HhEY!Lx%)WnNZhhEd>!q`8adapy^8jZ
zXa6pa3qOaoNZ9{0?L=^#+`D%k`AaD;>up{{`AteaFDUiv=$EXyBx`66q5NyaA@^}A
z;W)YH-$tpARMriZcx1io_ek%e{d($^H5z2iJd=_y>wv$&c02XRJsal|pR8Z%W_v32
z4q<-|$9HkO+&fOzJC}RE&7<7=<jXn_Ybakx{vNhv{lw?kmi2z+KIXDE({$=Ri)|yv
zji>$P?3Xor<o*k?UeIoi`#1fPHGpJoN{Qo1_RIL)Prcjer`%gc`m>Y$Y1DHW`Ep;n
zsch$y{}J)Z_@>jItN~{se;&t$QNOI0`9(DAbu(_V_PN|s>vZa$OMKI*N9Msj<jei+
zWDQ2SSLIi<H-Y+gk;-|`AeC`^lKN$y$bHWxuCb)+IsSg?llw@?y-MW%Oe^V+tn2g(
z^~!yoW>K%iS3>!rl-o$V8)@Ij`Kn?2Ys$%eFRxSDQBhv*5jlhSAEEwT)F=1WH7NVv
zWd9_Ni%`;3WnRddNOHf`vq<HhfnLf>JCl`p_$=*8f1V{@;+Hk)AEo|C`W2wuYbSS)
zldK^p?Qc}hgWUIB&eJQ(agDV1Hs!<Fp2+b*;y;7^FDd)e*)MBu$+~k{wDT+dko66}
zpuG*Gr;{)9X&?FW{ISxG+#B>cj+1#H>!UtN`Xh14T4@6Zu>KO~(M`Ur868WxZ1S(6
zKf7r63hJ4{b}aSGCoWmf$w~dW#M8q5AC&gSvR|HWX&m<j`_1e>oAfEApN}f%Wh(if
zaNKL8a$jv(11$7>CmvaYEs0dtG3>>0Z5)3WamiXDvR2BOlz*Ih<hpYY`NJu95Aj_}
zTE#eRr@XAiBXQTU-$cHwtta)XPNJ{G*PH%r=lE6BFZVMW#PPB&tDbsgzJ`(CpZ&7#
zuCz0j<4@)|Gv(wypii+a&z}oPCo|vACSF;a<YD%oPI+0AOy=WOj+gnMBc7+(pU3_=
zq<e`|?tNBC9I|HEZt}}0_Xg$UeASV<>BlbOznJ|_%KuC|7ZX=J+xtoHAbpN<GS7~q
zJ(;h^(cWp~e?`4=Z|LnDCvnVWTh>i`i27u$afj0GM%tD2LtiF-dEUwTt0k0|HJs&o
za2II@^~&1HKa<|eez}*?RF0SR;a*nSzmGJD{jx@_%<ClTeUSZO94~Q(De>uPU(fiQ
zPI-A<c${q``=?W%%;$S3Fa7zQxTT(ZD3?J$9^!a8Pm|?1G%NjD$Nw*7|K050%KjX-
zKjyd{v@h$6o~+F4$JsCEYdZU7UfiRc_Zj5N`1Gcnk@^2C+w#1L;P_iP{$jS}zI?LY
z>u;2kdnn3%&-N?jzG7Tt{X)4fmyFi~<V&1$$(MC1Wj*C&_TR0vH-zn**_QirO{Dx*
z%FB8Cm~EM7au0@B_U}-(<^DD4#Iu%m{iJelpwBr@$8qP#c_Yr-DgQF#C(mnHQ{TjR
z)N`CXk2g}!ZEWAAwBJTOa{ZTeZ{_~MjqI24ewtL~-%gH~doSFplusxBTiW}LRPJ5A
zl6v!rqlk88z1>pE%j<0^`{j9A&2ci$-w<CE?aP|ZPx74WM|`qgqOAWX<2{S=a=o9$
zIHe8YoGS4zXTQW(#_P$W9G^@(E{>D6eC7VdZ*$yY#wmg0MsWNz+LPDUdBoL+?dz2K
z7g3+QK4dHHT(9hZlWiI2R`x$beM8xnd3dc-PS%6XqW?|QBj@FQ+L!B!m;8~ED*1BH
zkW<({p6yx8hel<*pJ!X<Z721~e31JX^e6R^|0L;7>XS8YpP)X8<2?E?i0uZ-%X!#G
zy>hSKaHX9aC_kJ1vi|U8{QpZz{m&@nWz9Yr&->ZFmGg2l+cJJ$C7zpUXEoaovcH0K
z8Fl1S-%9f3d9zX}UrPB(@-?)73H8k+mG=+TlzWzX*OOKduiP(A-ml1dRdU|@5q}B!
zvL2w6zmj_7{n$;)_<NK%<bF<azo7l}L+-ct3~_8@++}@sspkvoyPbLx<h+poHfbZ<
z*HLdV$DKqwcd#w@%8={$BDUrEHHH0ssA~lEW)YXHyDag|raieo<pQ?vWxGj<<0j=e
z5ADf#-_3Dy59DGcj%20%*V+Fg`6WvJWo*lQjiEldK0HC24-roTsXYH=4SN~SeaikX
zDKFRk^Vu)g!5fr%vIa8ei2Fg>d6;}z<9RyiP~wu;k7(kQ*X4IPUfx$+%W-nOdXIW#
zKAuYXyQ%kPj+gmeOZ;xeQ|@h$N%=&!ZIqY$sLK7{U!Z+?on2487gBE@<vO>JZMm<d
ztoeQ;`3=-Rnfkw^-i;h5Ye~y>?0n*o=ZCC?Ec4?d;*>RBRiv_3@-Et$L%B1Q>+G*=
z2dQ^4?aDo~&!nCN(pJ(}NKYa?j`Fe&uzY4{Qu?`>^clu=3UT;oe>QQ+eS&0t)!A$p
zk;=W)WxaSA=lj`~_;yfV2JuvL{BrWwDf!=0zdR3CD(73)@&1zS7uYZ3DECT~=jRt}
zui*GC?3epx`iV)_tUix=<vwfsD5s;Gm3C#GPGeinhl>3&4-AZpyuX{F<lmyi_a@``
z2Ipfl<>b25s<aou_QxD|0qw0L&E|Ny@5uw~mwp*(U+yvPQR0+)#J$V*R`$z$mHQ?o
z66Z$t%XQX5djrY8i{s=vwUhqJ8o9Eb@*?&>!SPZqoOqrhU)GnE=g+m2OJe(iQ+Pi|
z`#(~z+?)OZ>XG|s%l(ODzMn<8(7fb$S<7}Z^~rtW=Ci#)#+UN4K6)wj%6LDi^kWCx
z<<#God6CQY^i?JPJo+p5f(@tMout#LPvVrd{N;RnM;ubmGwhf5BUh7uJNZ_QllT26
z(Vm5Rk7xgC(yu5l^Y1z(-p#Zt_lTD@+U50n2ghxoT(!hQejIVj_2pI4H|b}da$G;+
zi)Q;9;z^_2EcQ?0xLLF(?|bE*zjB>@L5WLEeKL<qDE~9@T4<*q<#uwMtX=v9`(@ls
zjPD-K*YisMvX%O7VZZeAO|}ov?oiSt9QQ2kWKn(r<@N0UnQghB?d8-j^Xz`we}L3W
zJOAdmXzJ-lI-h*G9<HPxGEa**US5xHQ?`B7Bll*tuswqOouqQzmbK(Pv=dH0<lf^q
zkUxO^_ffu>@&?*@k^Lud9t$~-i)l~B`x){V5Qp6VO0KgfahzNyjwfH<zaOWZ_if7f
ze@cEj`6rUfI?3NFamNt1oj4vLU#^F;rfWaydyMwwKHPGzp=h=bur2qlZ=gPTUo(kR
z?uq1NzuX6Yp%T|c^h4(7muyd@KLaSYj(RtcFXtnRd^wNrlFIpepL*9*&c^<`Dfb@z
zkk{pMwl!=oVSHpfza>t2pErtpxv%19v@5UUpAq*a#^)W5lk4?H>U))OYhzok|7v9%
zX0k2Mr|s0Yh~v)W_~{Zi$IEqm67k4dhqse2?}xr7J(F_7DStU>Kxyv`QZw;Z5XT+F
zbtmn~JfA}S?WAuh{hBS~%Jw++%loK&+PR2&D%rk><K$j=tJv;KIe8wXaJ+mzxmWpo
z^r_O{7>*lH{`ZuRq}?F(%XM!I=@0aCF!>v)-$!|QT{uPAKY?xee18$!DeTXpo)PTd
zz_y%+PL7lN+&xJDHj`@D|1#rYV_WXQb}I46d^(kS-XndLxaEGtOX&A7>M5t3TrXv<
zOi9n7KA8`rs9)BXbW&d$<?dkr5c)fqe0iS4lP}Nz3bwB&|4gNw12UeJuTbh8rqs8P
z_T_nXJLO~^$h}wOUSvN}-bX6;7m#-49?o)|a8oWoIY05rb#^=X(!Q)$d@`w)<K_B4
zP>ILR_A0iQur1eva_Y-r`&+hUoIhi`ntJnzL)O7>BbDp>ZY7TO)H{fN&0$-<KS-k8
zdfJh-&+lhj?n^K8eUDQ9QOd_qzD(&)F=-s-A0ht?@=sIReT#PFd=8|a;q0GHIhnr`
z*}sPIZKd89$v=htONjet_RIBq0`+X-xJxMa0r{8Eu8jLq_RIBX0Oc<wKa2bwl+PuV
zdehi1?*XHg>&(fNTTHpnxqixh;g?gdtS35?^CzD>*Hiy>)b|bf^0~!BD(}PYC9az(
z-^TG-Y^&*q%<p2xF_z=EvAvP)*D3!9ah<@nTn8VcZJ9?t;*opU$$jbGr~cKnUrT*W
zl<&><_tY=v=?SI0+{05(eYdbJ^J6I6k8<ARo+NT#(`Mo<VgIS5az1aSJ(*8SiAUZ~
z&8I!Nf8jgy%R?Nas7Jo<TE_ld%IlTyi*Dd}x$X|;_@V4Sfq3M;Gd{}6^-%67B;$KK
z<vNIOkrK}$@+B@6^~-fRz;=;b$JyVP{Mp1gn0#5I_Hyd6lOIL?Nz}84_J5)s`P?A)
ztC+*~x9pem{Ejk?pL6^p<o9L2TxY*wzg+kBuwUkBfAZ!1?DN!fE@?6K%J{XD%J+*^
zl$W(!<^D;_skfE#GT&#jU*_%Gq;j49n)quu?s#Qe?tv|FL{V=M<vYlid3Foi1#G8A
zb$_1UKz%7}XHj0}*-*;m(a#5IPhPj4qTlh1|0x`|kaE|uU)pU};*k3kNxwd!oaCQK
zJ#t-&A%70>d`~?Y)Kg3<_nd8{+<NM3XTRLj^AW~dUKbvr-fJj#zMOxK`-pnvb!IT_
zKE-j5v40TtKPKmge4n!aY9;PT<bOc9+ZhLWy^#AkN&mm3U3tIaq@2v(;iPgMUqrrK
z-=1Oq$~w9>>X&hER_c9^c8{mrQp(Ba>T+fOXUhI%<jd>fIh2#n-}Bl38vR*M{L9$h
zO+Tf+zU0g2-EE{2M+*DpUL!Zrf4NueaOL<9iCbR(7g0{;@pHs=G2>)lem_L{0PU93
z@9Wr>*Q?`c|5ob#n*5QZO&l+4&ucmUWsbX^{MF=dP{!*)^2@1r1^F`HJ2`$P>HA8%
zgV-<6KRxlt^{Ik5pCGLxe+v2INS~(Oxx_86ix*Q)z8C&bIq$<s4Yc<b`EnhQd!9*q
z>&Z{$xTo1ZmHkU-U!I4x)N>uj=TPrb@^gq&=HFCaU*+>(E#>8PFojgUPgYaU9n_Pr
zl)IODq@DXXzMAwm>Pw`)GWMUt_7?Wb-!n#Y{Pon6O1aNDUhcgmpA#JHub^K)k}v(1
z`|P|*`Vjq=dyTB7AM$zOA<D_T`Gr*G)5DaLevKlYugJfVd>PM8jN?4Y?^Viu#(s%=
zE#>8Vq{o$deplMNhw}1%ZZz8}`n!twSI~ZM+ASu3KjlZzULEnDMjA{0O7gFvygbh?
zX1|8=YdB8st(Zf7VeG$^{W9-1vHwoey&RuTd{2`<fpR11-z1JVQQxzqdx%rY=ab6c
zCthQ}T>pQgyo`(7Pf6}&+>2CR*YBd-MCxmyet90c8Be)~>QCg~O#WQj+e>{H6OX(O
z#VYkY#I}5oo5p^5KL1QA&x?nM!$$sU>N|<!FQmRGwq0z?xPPLwbDwhFe&e_}_Fu|z
zGXHu}zg+)X*p~O@-?9A}@jlMB{C%i~R70G-sVA56xAVL@UB;Voozy>w{@%#`JE(sp
z$34fke6Ffv`z!J<RN{3h_2sZ%?!P1Jip%%0x3XX6!&)W2O_ckTb}K0-&mSZ0t)_fE
z?e!<!O&l_hKIV9NzTd4JcdwGZ#_{qR@;&Je%D=?8e#rO+mE(%ZzmnrVpuQQjJBH&D
ziPI_dQ!a-02PR&>1{2pX+Bt#zt)$yIUe4E<v^$#P50EeCcM@@~VY@fwy_CC#a`HTM
z)6R#avC8|6&nSNj<!)ua%=eR(<1gg+v&rvEzLs<j$6Z6Zgm&aQJd*h2Udy|gKY8ST
zODgwz{)T?Zyh~xfyx;p&iLZ_0o+STswzp7D?v*9udm8C4q)CkD_4M;njys3?`tv=g
zTrc)euiO**MdFh02dk9hej;D)bEzfHQS|36>i1IbK(+%MH(9x!PM|(nx4nb-D`|fz
z>9y29fcj3Py<F<4q~0HhTV6L-kT3C{Mm_TSl}!FGY;Pl7OgmN7C)b%hl#|!p8sd@b
z*%<1T@4G6LaXcV#vwbG@tfbs9%H2e{-W(_M+NB(~kn-}Hx0Z79`F02G$aUZyrQBZf
z<@<}i)GybN-AcP7sbAiIFJZsDuS!w2?`2!&XC-mUJ(&|37kS^mU#X{pI^=WKB-*@$
za_>{0o_L0_U#?4M5Z9f=t5uGBi*gdbgK~1d<i3k?y%?vom&S22&*Ywka^KjWmHiWx
z{i~@*=1YnkPx>kQr62k1m)Dz0Qn}8_eI=#dGTN8d-%BYk<M1N+^1RwZeh2$&*p_=m
z-^aGZGlurl*#9Nt7DfIb^8MsHDJRbhJ@Id2|KpUC=l}0YJ42cO1KD1|wp@>%qMW2Z
z6VLe^_Z?|3;#$pda$Y77kB|Dd5c_A;cRBOxL5}~0?c3OY5y#8>*H0*a1F1`CzmvFD
z5RZ%FWu9zM+S$Q;AJ6eOa{OlU<-V5E{w5{Py-K}%i6fdg9;RP%yxb#DUU$|i{eOdc
zWj>uwe+sxh<dFXg+s7WqM&Q^892<dSBXDd4j*Y;v5jZvi$421L5r|;pGF2Gw8u^ZE
z?t*#w#S8MyS$W0QlB`AiH>;#LFDu7l3H`6Nc<zEZS*7!>Sw*?m7Zm4b<;*vwBxjXa
zi}U7NhLcAf<5ao<;iNvPF!boJI!)DTIZicgZeDRwNl}4S6My-6nrS&~X(pDG<j>DF
z=NE@c-k`d0fGTgX>7NIp%IBUjrg2$CC0W*@B6CUB4S8AVMI}~)Hbn_;zBwg%_$A!I
zh>oa+4?jHQoRay{@F}Xu0UA;V|6YJ!N|%~)tT`o1=BtLQqC(>$OMA&<PInSY`|$m$
zr!!o|uI~P`Z!mxLYwFI+E1GY~F3is{Wt)qNEZMpFbLK8!9F7~%(!GD-;-X?@U;Y9s
z{g-_mf7#c4+$rpf-5YAFIN!RcctLjl!bLge&@pEomcO9Ls_g5fI$qUDOf^`X&vzu@
z(|7cnu{~j0%u}ZiO}L}afRoPrNZUVu<yq||XD-~c{YLMJd`7)o$}N5A;Wfje;(A@b
z(b4O=rNK2HylbD9X`8+C%lF?;{`Q=Cl*tH{n_M)|n*Hx{x1Snuy=Bn&Pluhbvn+1I
zgb~YZua0WG;-kK^_`WDqZrz=$9~*Sf^h<i3eEj^I7hfE;-S^||ckd|Me8K*=5+*-2
zuY=E$#2CXs)^+z^wU}*rXb?$0L#>+3*GQ61BjqbZ)pSxmI;m!m^3g{{Q#L*#sjeX9
zqmwF=R6}|dDIb$m22wuGsb-V%@kw<JDId>NS)>W1M$#109MV)$6KNVLLub2`w1AX0
z<=opcNavE$mWnxVqpK<=l8w4m7Sd};7m^xDi%F?VRYEHBXA!A9Pi`PJlP)1$K)RH)
zi1a2>j!`WmrHpDhshTwPtq7F?#~#N<;MfQp8-ZgZaBKvQjli)HI5q;uM&Q^892<fE
zb_9BH;DH0m(R{#?&+efI|1Y0$<sqLx<bO3d_Bb{I$421T2pk)MV<T{E1dffsu@N{n
z0>?(+*a#dOfny_ZYy|%Ijez_`@oMGo|J{E`=kNI4e<hc{@b~zW0Mp!}zy2bipuoJS
zq%ic00Qo&Ym{EQYa8l@Z0O~)|!+#Gj!(yE~f9_I#V4%5}zn#yO-vkU)#SO^Lz9BC=
z$I4F+au-?iOZZ!T+<?M-vn9Xy&|H4wOn#14{w6NR@N<Ri5^Ih%KYM=8f}A<|^Z6rt
zcbO8aN!6D!v*s=^6)i4N_2>U57cE-A-~8tm@rPKcXX2zwdnltHu#w-Tf1o-s^!osZ
ze2K#2Ldf5uwHQ5$-!!l2r{d4oN;vt2*>e`<6r1u**?Bo;v+jnXxuyx@#ud?(9BWZ=
z{CPT^IcI*ZDJNT-Jkm6_pditdH#WZ@DJd@{X;kv4+}xb}-25>GTJ7iw2?tB&jn<|l
zjvYICq&6vkbY5~^eq!S2+)<`{ZNX^mnB@HY37T{MC~F#<m^5;1UeYL2fp%1KfhjMy
zKx-PAtJRuv3i1j@nkHx_5cgo!K>7LfQ69$BBy#)nTZEUp`xU33uH_sJ7?4Q*2!7u^
zBg|Sjmp^n%o{Yf=#$ZNR2|rn|aNY(CNF^^Rl$Vp&J=*fyiva`D$sZNU&ok%eETA;M
zx#moKri^d2@@H>;8ci<$js)_s_3kg@Yy96cz~_z|XH4Qh1#=g~C5FaY6Y9y4|B1R~
zBv~@nYrFf%Sf_-xZ~tR^^kHK^{U~EU{U~EUJ?!XXKRxX5u|GJst;co8cIe!`kaHFI
zZ|Al)#gxLd9XT>3N1L3SoK%pa%^h37JRF%cCRaP^&$*qGo03G4(K!XC{DRTBWAa8Z
zrN<`b=M;=eNlH0<ZWoLx7&$U0cXYlfFEM4T)-<{xWh~ExMAN8(<m54<NB;A<-M>8a
zob7RLj|t7!!{_$cP~Kn1cYG-S@bNu3w>xA)^Eh&D*ZkLW`~TGd|L1di%O7*Odv0&|
zWBY%e+cNe?&TSd{qs?s@`@fsph4RHV4?X0%Jq4FgKCyca{LN)$?gH!4FWY&e#-!wo
zOc|3`kUM%*ZpzrvV{;`LnV&Z%B{ykg;-6D{Y|f~W1^K4Yxdkanxhc7$6UXL`WU8hl
zCXPzfj?76q^s+sA%*cXVo*_AjIk}@oY4c45$w~ajl$<-dATLj=T((2k61nF7_3`I*
zd+rf)JC(xn@AeP9Zp*d!BF5m*>vjft6GM52&us(w7l-oyoZE6e*O1T4Ep-&<mn<^N
z{~mTd@9HBtf1UH5|9Q^;|2Oc5Px*gzJ>T}n9Pgg<Z~n2}J?B#y7da<~Ue6DnlSAkH
z!E<utoIiL@4xRIdo|EZEoRb3OHP+Bi&Ite33a3EoN$1>F9(*qFdrd1pX3U$HowGoB
z2XpXUNY7X538Ar(I{*5JO5IGR#AqaybyQ}Ah1!`bznhc%Lej}c%)jZZEHaC{?Cie=
zHf~&Ywt3{ZaR=km_H;?4eyOkEAJ*67s}1$Z`<DgE*m@($;Bg)JXJGOhMAcl{idw0>
zKm4-`{FXF7XZ~M@xaTVdZ{Fm++dmm&S(}sRcc>{s`D2Xd95KdMF(#!)jL8uJ9y!!K
zUah1(srR=3tll24ty1ryW1iYyat<H!RkT_8&&RyyH`o6c#=PPvV}AdCHa0!Jv6pd>
zF?aoE_4fENMCz3>U#iUWNPa^s4-NW)j|8fPv>A14Xr3Q@I`%k6{(R>4STr=}Y33*o
zP3ZHAd=`<H`T3!7?*4ot*OVyoR)k*rblp>$b9rcAnvc?#N2nw9@V@joMt}CD$D;qZ
zFYErpzBr|`JO)F~3*A;_P>1D+zVvjNJftr@75&G3(I2HRvbMmCFrD%uFyXNCVhMfX
z?(T#1g-e;LmO5$<?@N!@%Rl?lW6^)ymkmeh%aftJqtCIjfdtRvV(@i>Y7*)w?>oFN
zJ-)pD*_R%R{^P!EJW5|aWCC$s^7y*M%F{)44$q?)(oNlc41MX7&Fhybdw!8ApD$qK
zwX9@9==DWIIpz5L;^LxWIsVY+Tlz_4@X+AkwZlfeiMJhg?db7!;Low>vFJY@i?XAP
z#s75eFw4p0F%$B?@?LEVbr_H6OHW_k9MYGbivHuiY(7d~j+~=%eU$ThwDYYY|DT-i
z_&<+7>iO34@8;#9!NK!=H?jE+AEO>$+x{G*9*h3tF<Nt!G5Vj*cZ9rQ=5grtHJdtA
z6^G5;9^W?p*_R%R{^Pz}bCkXu?fQD1@)};P^hN$HjeJa#O*3^Q9^RK8UziX5Vv{OD
z@yeX|>*LSY=|pzUJ0xDYJ{*io*58oFp>b7H)_8baJ-*2Pw{boAH*tBDxa9jA884aE
zQz=_{L|i?+VE(spUG_I|ndAw~V<;ppnVZj1w(jt_dVKNwZ{vFQZ{muUf#R_T^0DY^
zJWtuc;c@l&LUy#cDyZwPk3Z*EB|Ga6iA%0?>EvC*KM3P9XHJPVyMRAD@LgQ@ch%kb
z1#^oJ?x5@`s_+4YjBOPCc%JPOZVx@j|M)I;OsKB8q3=ATY~mpLN!eAD9ix<8#(VMC
zh=YG5IKOB?cK7Qhe-b$I!_+?*g!uD92POY`>FDuOOZVqJE%EF*;&Y%p-wrzXysK5t
z*P+k58;Lz?)nV7R9$##acE0|}^<e2C=j+hxL7D`_!v&e&kD`IHsYk@s(+lU(;*zoX
z>*LRPl*-N*|0b>$C9XrqYc*vxcN{ieJ-%2SEv|nuUiQC<OYR#X4>_F&uTxi3HskQP
zdVJyeZ{wPML|l`Ue_Jc-#LFWM64ym|gR++HxRkGV_^aLABHmi^eS3E9qJo0%e=scH
zcl_PCI{2MZD)k+0o=;F-?_~WjdE5>8%3w8`Xy2!_-~Fe|>;*;LpGM^0>Mr1)-iBV!
zj^4H^^ttokHKhBy7R#bs^V~e;9dYPdA=e$bH^_`I3xAR9eoksgj}~i+601Wl;ymU-
zJ_hk`QdMsfYo$Fjw~oA=gkm&M=C6<L@7(15yOEviscc5r-@JWizkG()kjh1EMp)?W
zKmTT2J>Ub{KC;pO_!_3vANNQ7p|^{n>(J#&zYFDy1RfU1Ig<YSX<M`UsQu0^DJ)uK
zHf39jmt<Rul*{YEZ@d0}&Zz$Q9x|2sk30`Ul-G)1IS0yE@rPXH+pz8-3B7J;IJO})
zp31%gbIzQS?$0`tl{w#~^yfm#o&cFgvR-mscYhB4`C6uYcO~P-73P#=^9qq&B<K9^
z`=AN+LC#ky<z!9CBfs14j;%W=xt@+w#<*0&0X&97jq~s!W2{;e8soVo2m4ACMS1*X
zok=Tk#8BiYk5C-)9MG`y@5bX`+nrK~hg{zxz)NVT?bIXN4o%S<)(hxvn_@?M{L!}b
z<L}zOOzF4ntnMn3Nu>M;NWX1=+je$Qakk9*xz_GTx?_>pkMj5<mPB^`T`UK$h2|mM
zHAIJX&+`*Ww-bx6JC?()h278A?#q%KCFkPk&-FjAM@Gv1-Sw!DeTQC;<lIT0E(*=%
z+$H?>B71T1T&p#ILFn_m^ykRu$YAAsA9@T=Ksk&v*8LnvQJw=qrLPmnm+Ssm+{1}a
ztPIV!?8C0R?34bLk{;#p$Mx36&cExQ#2XX(zOVawD|3IO5=(}>N#+p+nSb)9kT5oE
z2V;?6voP<;4#n|z=Q@e~Qt!caBVy#D#$zR<k2XjjYr5<0?jm{8w{+5@JpSlg20M?|
zw+UQ_cQQx1D?9S)+vD5&Kfaqe@?1(kI%(6$n0>+=(1efw>FvxF7f)IB()eBHUK?oB
zKleq>CC<bvt8|8>om-x~{#MrG=fjUCeDd>GjsE2a>;Cy;ljapaJh}hBdeyxY`P5X^
zp#4pKGLp95$eId#;iU=xF5a~vzw^3%rzW5GY5k)s#s^-s4{|Nta^)>gBu%(^^I9M4
zhEJ4o+5>ky|8m)H>z3psJTs;1z?ib#&f&8Pd@FCXEpo*!a<s5+WvITh2A=V+H?_y_
zy>Z*5{;J2<#^;R~-+%w;`FHjkc5d9t9jl&TZAdP-n()F8%2)FhM*N6p@+(ffx!}iV
zTa524J!eOLT*hPWX=!`t>w!?a_nk4Q_vEo}r<^p^-TQ{ON8DU?#oNAXt#@2L`OaB`
zM!x91ly#7qyqfUaw&wMH<)+5(mX!Y3xTCf+=I4fA_0Lb<x%lnkjK%%@@||9~PRdnX
z(9ibmO)(3;8Qs-(y#Aecc8|Ms%Y)wVy_c*1_3E<t`<C#1QK((t!l+%pI3C#Z%bx8w
zWgBKp`1-^j-!(LxHfEaT<kMo@kDHi3q5g(nx%5EzM`u3O;B0zqQ{0B{bM$BZx?tsH
zbH?4e?c(|4Ry@ZVgQ5CX#Plv$yl?#ttySN>`oNQ0&wS~@*JIajoA=xuE#41|?cXfs
zdYdNk4LM_7@k_PQ)6EZ@_l~RIozFb>%SWEAt6u)$>b2Ltan^Z}?aXZ!-_V5XZricu
z+m@ZD4|u$xPuho{f7Sn;JKj={zv!C$%yS1X@An3CAeGNNn()@roEwHsow>fSde!|)
zR-Lx2aMYD00o}@FnKO&)?s=_=7nmDE@jbZUrRD$HGGf>6dAeOiW#@cXRd7peT+Y6Q
zmZksRS!M2>#rH#@_%2`f?!v}<x8E2wb>(g5{N|6oK4a;37d$l8v^6aHuKiaP@qAr2
zM%pdADF0!{mLIIElBRw%@p!|9VWzdC0uvuB7<&E;)0W^heCS-wNzsJ60za!_OQ(+e
z_;<HH=i_;X*GdW+OI9Sfp4okEz_8eDVZF%|DHrSZEj?>Zqi)G)chcsZ$z3O2c%Fa!
z`*;6v-t6Pf$ZcFbi}9mvP59kE#O$}3b{x3ovX@T0r08|~eZ{Zj-8XZ>EqSv&+wOfV
zzKiS1B~tF53*H`F@$<RUX6%0Q#q_ZQ=AW=^)xs<EGjCeA=Hp?LBbGnL8YiLtp8bCH
z!}s5P*XUh8Y_Tss)v=>9Y|}DT#_EU1%}V~{zR{0!ejg9bXZz@N7aX{KT4vFNcR%>O
zD(`dWEmIG?-t@-cckbNNF?`vkvsh~+R9`U4_`$L>9yAtsJ1+e-q2I5)K3?8DE%)WF
zvhX46^1gcMRqk~Xnx|8Kx^LLP0bf2=J96`#n@+oBTHS3eH@%ko{^j3zpL+1T<(oQq
z9ShYreE7LDulap)+~~bSG(*06x~2TF6Z>3r+s2(Y)j$2#ZcW0!_^nrHzEr>b_L}3r
zzJAHD*EeS-P5kt0<MXc#y)I54`Fh{Cw$-Y3<Z)f&`lSiqXI)a+C)U1Tdb9gIcmMaN
zZ``(M%E>9cFL`L)XTQXnzB|C0F5{(KnRVdj86%$CJvQ>*?QaH;TfcsQ@xgoQ_q(mf
zrT%jJ$Bpl@?r*5RWp|AmmAYr`sM$|E^xkW(lBSe>53XEy<=Ma7l-~T%2kZCI?mHP$
z-!I2M`}wW!zw~3m@2hWZS#rnOSzo+#?w}7p$iDN^lke$$_4)s1U7%2Zi&k&gQTWJ=
zDa&r@cU+$jPXFPO7j8OR8<@7b_u$KJo0OgOIBSoNllsoBoL<>SYpovWe1F%(r$00e
zS~Y9^l(?;*ZZmI791{2WIlSKv^<&?-P2Z24dadf+zSn<oYOj`8w|<uYTi>X+o^+3z
zci*;+oojh77Md@$!B?+bU>*0(rQcn(=jlm?XKs1VHFDeYDT#A7&wg~)=Jy}qJExh_
z?yp6UT-0^L6E64sE6)nw*tdSt)8B0izp&m>GU3N-s}h4eH|`2uuhgF&SlMp-;rx>e
z$GrINjC-qWzt?;@O#R7cWm~U*_igpv@3T&7tkk#WkqN67otH80s=*^qo_6jVyKYU5
z`F!5MlSZEMSoENK2fN&SP7BSKk+U|g+N(44d3oBkr+#<h{yQ$c<cy2X-MZhpeE*k$
zCtN45U>#*X)M>)UuIUV(yL9jlLu>4Hw~T6Q*=4<C$O~&6>nf+Oz5lec^$S^Jmp1{L
z@Z#-J`ttJ05hYjb%71L)7q;^+iF)ISOIPmt_`bx5PUDDL*60~6<p!7N&p7AoU4xvN
zOBc*AEv;B>o0jnV-aX@1HYE+3bVl_Ly#Ebd5576$rajY!yj8v?Da!d;_Q)^pTHTaC
zW$necU*G<~b64z{$#b_MG|u}<Z`wBhm$PSPJR32lptNH7#MgW~Hb!-w-TRUWH}0O)
z$Hw=1p>iANY&mWGUGKhf=ZTNkZM`Y;qKa?!E^U0`ofBT2djAXWef8a)tP>k5w>bUE
z`^RrSp~~^z>IbSfT@YQoFaFjswvVD$wte!()d|;|_}muihvUmJnqS-R{H$61RMigy
z>PKDMZ~guulONmo)VQY-0#}BA%(}gya+-&h?0<1fpM}=`v!D6o0`sjq%lfbLoxi8L
z;jEIPm*URZ$U0u3d4J3B&(?i?{f%0kulC)DcTWv#Pj6j!-sR7)7_u(ugqw$k^LI`8
zTc{>HeQ0hAcgkJ3C-TgP=W1)Z+KWAx$4}WZ=J-jwpWk2fyM^zq21vOv$K{+;@a%@I
zRTF0}-+rBQ`P^S0K6Q8DsntpIW8>__bEmSFbEv;vD>mHp=_4DyT(Pw83n!g<_M)hz
z?cXJQx^rOd^TA&qdu%MP`{|6eCfsmq@@<|c2E5hxr-AS7Yd!G#<B!iderVS7k6gF*
z<B#tB(ZZaPH)5Lb4&C_Lq`B8bU-4R;`kUDAzrFmqmHu}kdOdew-^6#<-FyB8yqBVF
z=IN$iUL3S?Z+Tl{X5OV2CwE=><cISeUp-VZ`CMIlZSb_KStB>p-%s5^r~8R5C(QU^
z_SlJg?_Odw-|*bWhHv$W?QgWyobhmP&PV8a)$?_-lh=Mtc%*vrMGaREb=^9A*4&3i
zBz_wG&V_DgpYYbM4P%GRs=8nk-w}oC+x1)LsXzHX|9t<<o5#O%O<em|J62wpTJgo(
zr^G(9JfSg~F9t)OWy4*%5f2aCwV~gJj~h*2srKC%Ic8A9&(EFM=eCrJ;?rMvm+Qv2
zq55)dSIoTh_0zAvYV!|$UQRhP&Y%3m<KC^e4<6tfHt#}P>*cJgJVoN`x!j=XQtrCD
zY_WSz-Mr}0`@B~jP%r7d!r!%{>BAAbUbN<Te@l5_C2MMh>g%j3cr<3ww#yb|_4+BS
z`ShiwKW05Y<)@Fn-o0?xmaE(eYxt~^D)oJsvhTv#TlbuGS7dZ=&owny)at$-y=ztF
zPF<f57aR8O^Rebu==FE%3FEhFcR#iI%}-Nb+1zLE@6NYBc<brAKN_e1x$l~mef_zX
zp3a9dP59fVt;&CN;=PrLaqrdFC0+2{&o7UT%8I&K+x4@hIDPb#y{wfTnlI7$TeS8e
zmtVHHdQi*uK6?%fn7j6a(^Q3DkBuL2^QX@|F_YgTOqTkd+ceNL>+|#jqwF`_mh;2N
zUB$uC_wE`LR_7mPem?raEA_0=73y!<&06<_Ubn>s_D7H3S)KaXHCJUk8VHtLRWNMv
zj*T&M_}lI1P<(?otp9RY(T|ReOCoY2--wETYs2Q^u@B6u-q3g838$adPPt1%<Gl9S
zk3Tv0iQ^sXzc1OgZT$x;7e1S|EOM)J$B^-#j5y)fBI<fE)b1T)?rzFG`InT7e;+W-
z<zN2D`-|GQe~>nOu<HCf)|PJ{%eAyH)Q@O?zU${+KaSOBUitI#f%je2b@?^tY^+Ya
zf7{O=U;Ng-jNbfRIdr`*x0U}N_Ra>br}O{+pA<58<z`|wA;dx`LMFswA%qaRr6_$U
z#KH%eW+6A5Y?*AC&?Yw{#A3}tBgWROO|uX}EMzkO=lgulhcvtS{(s-!@B97!exLK`
z+3TF^bDis4cjuhzoO4~*yWY9m^Jk2IY5d~XzfPH1>5SFFrRzV4sQl6wA4R^m=m7oy
zm2_;G(#X30;mn@Jp^wfjulr%;jpnPDA5B>~e_xBqE#|lGvz|HhJtY5r`@yYxX6xk9
z`|Gs!JLGlziygNbe4cU4Z|ROz?jJ30_tPQT#Y+56_6jV^=(BWqyO6dE&EEgCdLv!Q
z@wu;OX}@36`pTN3&DVIgP_Fkk!a7+U|7Kn42h|^3_bIMgbIN<$`_}4v@TXb(HpN|f
z(UJRtqjLXv>tUnFZ2R3`JIDNdx6y@^fS?okKH)=eEUh+qW0x@lUASi@EAgwf!O{A<
zb>yD!dt6V+j%jo0#j_2*|9acP7naTV^<wsiS@zt|m3$7&&I$g_!Li|{qAKy(+eU|(
z#@yOwRsHSv7EFzMIo>&SEpvY>;hA6Fbgg=gxd*<z`0M(21MjxHv#G`I7>_oGB9Be%
z)W<e0o_DHBJM6&5s;36GbE(wB!F_L^<KHd09a@+)uY2wBDZvA+TTE@l{iq{#(AxA;
z;*v98j=LXr_SdpUom|{9vwdr?t=;v|xT+c5ZVmLAx`sY*N;_g>&02R(UJ3Od(Cfy#
zYa$ZrO${s!3^{*&?49n1-Ish{$AbJ*j=MbKg6Eq)t3Qkx6g>T*&CdQ#{f4*%mdt56
z;ry_#uJ%p4%KcnvXD>PO?UsGNjp;Vd>z5C;(_FsWeQs$|)yVV}Bag)<o-{vXM*CR_
zuX?|2fw5Qfv(MfgwroO5{dsK<`gg4wd3^Qe6sxX*L7uyq15df{&zZU>f5_1<+MRgk
z(B<Wq*X}Pfy}ZNv_?v|>uSadDbt{SReo^Y*Sl^u8;e(17+Syle(-h{s(6i3zbv9Ys
z4^-V*^z)uJt0<3f(qe6T<Lut>2itoUpUUf*e*4Oa(5!oNZL^<mn($q<(tTcKTfgD9
zpwt7i%8uLL^=Ub1{G~NbqP9DKW^=H?)*D-veATpI@Yp%OEp0|VEA6Wzwd&5DSGs7y
zy>=eIMZ^sr8Sc@x+4{)lgOa=LZy9s9kn3|-C7=BoR~nj}++n`s%FNB<th%+EeR14_
z1FtX1ePi34n5kt0sRR3z>s6DNoKDW(dZYLL+olI^R8RP^YqLI@0M`SjufIAX)X}qd
zDRTiT@!NdT{9ts|4ewa=vN`+l1^Z>zgI@i*#mir{IbE}M(=O3H{ILB{U();CwH*Iq
zn;xf{6?KYx-uKie4Tg>Sc)!W|n)Ao+t#s*bg97YbDd~9h-i>7!_iUMe_1?QLZLPKH
zfc*@U!a3b_n|j*B4@!8uu`lm{mE&F++UwXvzeT?tKDBjf>DA9xZ#$no{jI@gzOel<
zc+3K?Q9Lhbc*$UG`uUxq#kXf@K3?1COxn(M&CGU>8BkVS$I-0#mB{-2ii;_Ws>*qJ
zGWln}(0!IcYuDtKeKTh4gOc={OY_%#TTnQE#yYoCfge!5%5nQ|w~gQR^2uQrOCL<X
z^nIhTJs-?o-*u43`A$Rf7YrQm7J1i3Ic~RO&K=g9d|Yqip+VP|{<5vcC)1Y=Dk)ok
za>h3e+BK^6>m2NUDEE&^`(|9-U*tFU-1i%|wzePme*2PZ>ox>FoWHr6_o5~)qfMB1
zUpap-cTSpGHn;S*!zc1qHqX8>de^<tzt!y*ymQ-t2jea-2&K+@D&ZyEyYkb~PraiY
zUt0WVbo|eLyB~c&q;aQeTN6qq`=y>cLHsO~e4cOqThD51eM|;-KDFaq@6ihvT*>YF
zqr=Q=Rc_6<eYeV@EY1%lytNPK-|yGU<4&;u=li#9dHa6%g;C8K_wI7(=e5b>G*{P?
zcY~DlUcG$9^1`S}HyYiIP9D{v#YVSUA>Hh6JXqhhf3?<@+hb<Ze}-dQoA#}`F+a29
z#fHf>>-SmMv(dV^R<D0P!}Wz$k<t6jx?gy0BjbuJ#oykEDYFMG95QjtktQ477}Ids
z!EPf19PPRW&Rm;)!}HejSFoR;lv}giRZ^3x`Murh<ztu19GwT(Uti<=(dy$Hy*u^g
z_K!S1rOdul+LQU3!<TQgUe)kslc2swd{5jTJip$#!n277?b@sl@x9U~hkjK`dSegO
zD_T3|+LEz@YY&>xy5k!kE}Eb%UB4(Mq5b@|rKTqmu;r|T=e2TF&4Zgm;~Gr<CVk>+
z_qXrQT{iKf20y?5-Gj*NhmHj`={KUB=NC&W-L_3C*miD*`RajJoL}p9F=yztCY#zW
z_c>R!`4`u7Nw1Zpx9S&`j^_#w_{Di@cHKMGC+OPOpT3YYe4pcMnKM1hw&aY$?t+rf
zOHSs0`C+$#qc61RId$UwmupR1di9Ocj&Gj0a&}?nm<D5}(7spv-OX7Uty|D+-9+mL
z{k*!pJ!aHf5hcwA3{L7a;$g(1mS<na9*pA8^}q|CT3xo^S3SRP$$(cK-+15r-q`_Z
z-mMpCXPVb3d!*w#h~jU0z>T|OADQ2*JKla+z02<=9*<cvYqMsK=k(^ikIosFNd2qp
zB<UDb@cfR`gZiHQ;%o1VJKZ|%e$C<GyItRon(*!LYIna*yFZQlk#arlTlKU4iDq4D
z<Tsd@z5eU6MJIl4KkKWQxYUrdTbEYe>uS!sX{FtHcG`;i!!HFixEis$>UWza-@N3q
ze(vPOw+=^rb*<ly{t5Ny*VtK(JIUfovB#J<LmfloLnk&~_1?TxAL}{={v8J2`z*(*
z%^OYV<E@03mG`dAn)FYei;KQyX?=Ty&&KIrzCCM=edEC<^D^DzmV07@Oz}5lPHuXa
zI^V2$_gMC|v=iHQb+;SS;JIIW{Lo`*i<e%{oJd{qRF3=C?czoQBz~LLYd^GGy#C9P
z(ILJ2Yog~5-8pRdi*7foj%eW2G&XMAci1XY&P)Fz&68W*s`S|qlXo}V-Q)W4nT20X
zxNZ|!=}Pyp>62!kr+w8&2`_$kn=c;pUhz)jhDCP{?YPuySC{){)}FUEPC4+f=C!Fs
z8+h(f{4F?;9eH4D{a4!b+SJC$$NGg%TXq+OT2Ebltaw$+lGj`F{8mdz@A~v_ZY-T}
z;-)V0*7LhFH%y<g@$e?oq}T5juCF|C&1l^cY;`E%6~5K#`FiJf9n+oEPM`g#_n2O<
zw_a3#-L%`Uz5UvSH+PIL!9Ix+-r<WYCSIH}C-Ks`yWX$8{YK>Ze!bq``rU?Fi+gVT
zaQXZu)Ps$Rzb2n1y%CVvaK-AWQ7b-JRO_9HW8E4p>~Sv4v1Ie33HBZ5(&tgRul{&p
zUaLBLFWYTe;^O8IKFsvg<nNniZRz$y%BJs+HJi}4HGR*N^JxFJ{@G&|c5AiBW6+@=
ze07yRxUlc1tXVf3{V-%fW{3B;&*MFz@|?UVyY6+Z?K{=Ky&tvW{#)-X7}KvLE!}C-
z_4aKhy_bE^h3ELYN_uxxKh%7xWwj->v~yPN57oSB`Nr$tbxCMAGw$c+xm{*y_t4H(
zp34$^($6f8zIo-uwVaWGnZs>={NQY(fssFGKhF8&qQ<QLQNAluS9$MK{VVq)+pJII
z^~kGq;D>Loc>g%=M{n-|H#b>p+q9WJd^WbNl;e&cp)EDnI^LX~F{|1Fmuu}aF4|@I
z_<pnC(ag>5J9mtV=e@F$FJDed+vwk@<14A#*WGyS+^H|_jot3tw&dMrD`rmkEq6>$
z&dXCuc&+=b@TxO=`nJWVYXv=Y&MJIRC%kX|mCZ9(Ci}MdV&AaC*hy0A^X_Il+z%x8
z-Vh$V_?Osq*F0uiY*cLJZ{B-DtAhttm{sNa@<@69t#W*8H;=ki9)8zgk|z0;F?-u3
zefx&<!wLSwBOF_uTzmZpef|eYdJl~nb<Mv`>g_o%AMYL%{*`U`fwL3hf?d|FnsR?t
z-u6SB=RKA7^M>l5^_#eJ%Q>g#ChN{G>bd?vp7W6v$3{B6*L~usTMaMLhWO+K39m!m
z)JL1vO@AfIacldJ4o_O+H*d(%x&41QbyQQ`W8X*H3GXc>yiGr8{Q6iY=htzH`$F^9
z@n-W6wQ}BcV$Al_Ywj<8cyLxCHu;q6l_o1<@B9rm?Fz0PereK`Nx|Q4(N1W)pvKJy
zTTfnH^qwj0k`SeQujSlXJE7{*t0|q&zI|grto@f0_P1*q^V6;m{Zhj6=4Na7bf~ni
z#^#@kJErq)oz}8*&Y_xZ=31<qcWP71QS*=Q{@60@gxLHUqSU{oGwO~nF>yKa&46mB
z!hdQNc60BfwtK5~AH5^2MU7WG-Cs+)QwdM|F?OK3dqy~?omyvqY3c5~ve(Xk*4(t7
zW9RJ?F70c=d$Uyzk}pRFExjLBdESrdW)TNwc;D#u)103NyxipIsWqd*o8CTEKpTP&
z+xT0#f5^%_$JoYEIqOW_y833i*&lqkW=qE0Lm$n`{oui7?!RZ1a+?~^;GJ`OEqYGe
zHRn{T@80{NOXu3Ye!s^0pIo*0m3>?1`O(f+&bOg1GyON+8}`lff!00mO+VRieOr(1
z`(ARrf5N?6m&xbme#&=^#&X=!W)UqvsC?&q$8kl?!d(+rb+R9^{<GOW;h%20Zk@Vk
z_%>{UDfO?=^~-4?y~9KAx%S=ZKP1oO!h6{_=8U{*y?o}~MoEXauOK`n|Ni<tNJpi7
zXH9O_Qnx0q>YLGf8+x{#AA7l1+-b||mg`p?-t>9Q%VRI{ys!APIyTho`H?FYrgu(w
zZrSir^}hF>KC|kWRihg8Jd)mb)NmhcG%5aW=dXxv{K{|bt>#@eO}yimeaZ9Kf=jUu
zo#Rud9GUlCB5jhJ%60t3D_=GFWqZMi%~65l=cM>F2tHLfr}3(tLvDrk98y$2xRCp_
zQogA}&F;=0_~PqPn_BOBvDeC+f|<>3`DJYXy4n5JpS|O;jrX?umHHR?aLm-C#O#E|
zmg6ShUa-5{OFK8Zb+Ov;>e|Dh-L|#AO?%@*CI2o?4!@bQW6RD_elM*_ZoFX6`KfnC
zev%pc@wTqN<-ZrsxuBV;)R*Gqp(zJFEk=Lv?hBKvEvyukS(Nqm?QT|0-}ZHRc;n3^
z{Cv<*%56_}MCG@f-dbi^b!S|^9|!-uV9Sn~#VvnZQZQxB#;J=oY{7<=62IJg?`yvJ
zuKfp&L0=sWh}m?j>Zc3p+wC4}pE9APNy8UyFVPND{OvF8*7bC5r`}B-Jt)oJp=-9$
z!uP80z5Zn$rL!j##%|)7%$9c&TsN$|a$0KMxcE`y;*7SAovsyy4mwiT+3KA+Z^iz$
zphHO<@Bb8km%Y8u+qh_dII%BlWz93$?|j~)R?~+MvTXWgbm{MLC3-RE?@JP1KX<pj
zy+`CX3RpJt=dbU~Ji76KX4s+G&+ni1b+hRA284(4+(X$}o0=a;XzhLF(Ya$*!|Qyo
z(`uKtRch0byH;BCw!fLx^ntv~)^JU=HnsPxwR7y2Szm5E9$$I2{du=qZ+zN+Pkg0U
zZI>p0plkHQi`XMm>P!Cp_s92X*xSFw51$PP9n`$_vg_}eSGn2$ddS-!uPeG-a{)Hk
zl;_aS56$*<*>cjwJ+0lNy&t~e@M)#BVO8HXY5K|4AuH~b*gU|7-ScwX`ZFHxs<orV
z`8y78e&7CVyIx=Jx4CtxX~AZ1yLkhqJ-?dvX-DNeFANxa@$lzeCa&l)a$;ojy?cr#
z+Q0FjNm{pv``ZgQA9CQjF<r^OTkfF=F_$9B+<h&aJAR?{+*4;q%BB@J+V~ZY>ovaX
zCi3om#b3`Rb8q~5TDx*_|Ezc0Sg+3h{Fj*4+j9@CxqBjF;nmYpW)4a^u0&s`GXG(Z
z%g#RyNL@F5-I&4KOz(X&DblCy2PrEZb_^`h&wuYiHmdUlDDw!gsi_Q9J7qb?=VL3@
zzDJv*Kcel>3n<yD;j*l|joN}vKc-OW>%}JDr1j$@Wc@rpS3_k#@$UlaSnmJwaTEW6
z<9cvhb)2m-{+3NmRdAIRmQ3O&>E-m)S)*T~FQdm$s-@-x+6O&_%BB1?YDj;^pTy%h
z{v`dfzxcNYb&R7j_R)>|r73PUAj?;#dOHIrP%pMmqlW#|@q5a+zEUDzem`3ijjjRy
zTce}Uwy0r0bqv}+w4XI$sN<+KvM$FnLF<7mc53+6tgB;`p6RbmIe+T-ANn8gYJhZ?
z5AUR!P6<yPTchC=))Z4I%lq4<=A-yi$E_&iSt|NlUCy66rsFT;r;e9U#!*xZZ)Lgg
z)G-6k46l5?sQvMunch?7(yR7$SNfX&Sw5?M&!6e9d_Jpv!IkszkMddSq1rcF>9Z~A
zEnlB@kY1^`J5ebwL%s*GuJ)Z)`c%t)&*A0`vP{N*4KxIm^C=W<i*k8a>{d)ggV~;r
zE<$Ibi_zKWPbil~9k(h?`SMfy{{CsYC0=S@T&0h0#dy6=xRM?nf3494sGQ%#K{pO1
z4muxn2})cvu_$FO{WEpMMZ@h*_aR!o9;kh6pBb<6^+4_O`poh$)C0Mus(nzEYm(Fh
zGu-SzmQmCfiT`L+uES$cUae@n)q135UF}1v^evV2SH~>?WZ6gjYoYs5Ij;_)5>5t6
zb58R)Iut#E%JoC8dz6_b8;wTg`t=ri8YNFOU!%8CH&FY7D*YtoxK(g-23aQHkJm|x
z9g~JA<)n0hn}oi~_B$wkG;2@^Ptu|GvsBhArh{;mba1QF@k&AZ?<)7F-e?E5`=Gth
zz9>libi>gBXdwC;D)ny=IvE{|%5kkh?GLHkmnxozWvV|pZ`3}D^t;kupG;93ac8N8
zKXbG;D)r1l-Oqz{wSS><&y;jg#E<Vkb@3<VT@Pg+83&_dT|=HJ`Sk+Yf^E)4#hwgl
zSK=+<s(lBQdw0cfoAI;6r#UL;BVp(oqqeBTuMH~aC+OOvq)7=ko^`b!pho%!O1Kg)
z&I@HZk3Z6?$w#F=T|gbt0#wTWGAj9d1?61VTtlPK>*zwX7|lX&q0}kOFQ}aVC1@df
zAN>t|fY#*rtm~wI;v-bbOU@Uy@1Eur)+K(De}?nr8~jyc`&+a=nu~Ttze8nzdr<q^
zDe02^%a>yn?pqRGRkS*4uHMJISXcYgDgEqZKgnNrkYzo=%5f7>EA&HD@_8fL5lum<
zi<(c+LFjf=hkl9{aN?xfm}rW?ZY=M&AOhkb6>^{i>W!nF2A&WC(U1UXa0ZINY&>l+
zum?Brh6sp-BuIxdPy}W^)PHaWPtZaPWRoEY=q|{CA~5$QkHG~zAqZk11+t+8>iH2r
zNFei5Aq$GYib5#hWVgM+zOV~FPPkbNG|_mXv5+&9^k|6tEW!YH2!bd`fOI$mWl)a`
zwH>&F7UCcUvY`mfx#;J0VI9gqI`7+p7ib{{;vpH*;S3akc~{a0-Vgyv#3vhaST6;u
zZsZjNKrHNn0+9Fm&JX}GkP5kA#tC5uo)86zkO@UlqX+vy5X3;LY`?-btOmKjd4pW+
zlOPK$T!<e8!D`5WBCzU(JA^<Sq(VMe^u`?mU^QewA=K-`u^<EzAOrHC3>v%g8+bz$
zBtSakK^Zje%kSU~QIG)XkOyKs%Ld#a3-X~1JYFR~Ar3O31nRkw?{~>p$m@?ku;v7D
z0UwZ)B@r?pA4<XMHGYQxh=C-?fFh{JiRb`c5Cut)1w~*nkn;gNAOvC|1+pL?%s3%!
z!3}~yPSAKrg)GR2GHA?A!vWkO1ma*9oPi=R=b~&2ZV&)5kOEmy0A&zkLL9w_BP2ow
z<b(Mr;t1{#0SS-}g<vt7^98&?2fH8_#JHFPc!3rYAR9`+!kcmePsrz(7L~Z?Km<fJ
zH^DZ!i6#lsARF?b1Zr>%vIST0fhdTBBuE@e8X%c4ionK{vVtg%kpO9M28zLAEOF!f
zb_eIz$qy*RZ!Eft3v*5s`_3WW5c3>yo=aT0U}nxEt!9)1B$kpthX_YUUa%gITPl>X
zojjl8ux?hF{Dxe9m$AMHtfw9(9%vLd*8;Tg2lC(seydP!_=$$Hh5XL8Q#5fx<r-W9
zZfu)Z<(S|J?#s#No9x57%_71^J<xR22hB#yU>D&v=7wMg&Txj`ywRW^Irq>c$bbSc
zdxK-4)~G$?lg3E=B@o}$)kqtpfi$o!pr8i7qc)^B3Ec&S>{t3S`NjGfuv$!5;E`^o
zsd2zea|YrLV$1C_GmS-tnI;!(51DCnkPFU-%`}N%_PLoR2(rOG(@e7(O2PXJeuo0E
zJz}N_fmA2~r!UPkQIG+JV3EbX5CRF10R>R+D8~VBhydea%mHH#7<0gw1I8RM=72E=
zj5%P;0b>prbHJDb|NC=**9A}6|EtBjfL)E5w~>zo)4{M@z-@Ia{rF}103~CQT{__x
zWc;4Iw3YdVWDdNEkPF|zIgs&WXW%RZ)#V!$EPyI?c%KW^;5jfXi}~$ckYy@59cHQ9
zBVOda3K*7e2{RYIgFTQ3KfsT09%K%LpWtUGfQxVmWGwz=ROVf{0$1T06v1_n@zAnJ
z7&1TFR*-oH^FZc8{t?bYKKukS2HUXAC4U~W-*0Ld;y#J>N3u=aO`sB(!a?%wB5dHd
z6KD>cg0o;)KH#@L&{y_Xmn7CV!X^kNEy?H>m<6*T3g*Imh=#?m1Y}7;KZb3P3OhiS
z%N+9xEN6QqybW)%9Sdt%UkkDnv3(tGf-I#k@a}}PRE8>06=W^}bM!ENs-e%pA>7;{
znfPvj{;a<T>p+%4sEiRC0i$3zen!AZkVV{F;UP4K+i(YDu|->h9khpzAj>1P68oD$
z6*ZiGxb<bdzq&nu?P^dDJc+{y@B(}22yNhHkfjsq2wkA7>NX0U3gPPZ7}Oia!Z`4S
z0N6tK=imYumK4^V`Rx^uWg;33lhy6&<Xa7>3GJZ+bOJ|kf^N_qdO%N*yzM3HXdl!S
z`hgn^0CyM!gF%*BXl<~7hR_IJfX475yaY|a8k)jKgxd@~k2XhbparyqR?r$=hPEJ!
zC0YmOk)8#x2x8zZSOzO#HM|4y@Ghhhb^`i7B!VpE_p3{I^`JgH4-G)(c97*8&O@0q
zV-Dw_<bllNFpu?OKHhC@pr7mJwWj)cb7tV~gx@_N^MdUKnfJ0E9E0PK4Kfd+%z3yC
zWPZ-Cpevk!laK?aK<2}dr84g^We$-j_6q=Ww&j`_1i>%{x8CR^kooRHK*nUsT<TLG
z479M2G%bRutWSe*h=A!Z17<=b$npw03uL}5nV(DMtdx1&=fGT;2Qr`Ld{_VrAsQCJ
z8?YE;xj{bNA<tzFr0K--7q(wVH<5QoaQhM>#GUO~XbBpK)?uHzYFRlo(dXf-_;mv>
ze(#L-2N|O(^W(Wg7Z?bGU@*wMgs$Mh`Vbfj!@v`U!w47&vUEeeU=)moG0+{nVJwUT
znS;>>e8CU=Apinl0?4wR{M`wkLK<8my}rbE0*q$ck@_=JO_$8eE_o`~e<>?h=nEt9
zdzJmJfsD(tpu9h49}C<qp*Gt!;W?-RwV(zB^P4}kBh7LgbJVbiJr&6xsb`WdXXpVV
z@PC$gd;_^~4u0jhTHHfn638Tk(#LNK$Q*VuC!Ia}?t}f14%;CH4!}Y940eFbQ<?!C
z;1C>!&mj}O09nEbw-U$jKxICpuW>&Ek*rSy3HMD{0^`{3h`t4}uoRX-Cs+<~umV=X
zDp(C~!#l7B;$bbw(hhwW-h%{K2kqf~SPzM?0X~2aAqh6ZN3aQ!L6)23*DG8b9-$>5
z*R;Jbo45vnA4s^82NF*QaD?Hwn~?6w=v0^nr`W#|YKpsDZ+24d+u<V!g)lHIn_1sa
zIll!<L6%{-4Tq618Vt););}q?y^r<%a8PxVw!#V4kHZ>{dx`BrHOvg$#)A*|!vv7!
zF#3hMo`ar()9Uv6y5t=gmXBE9Ty8s+^_}Im_pyFZ-Tng2QrC~8U#aW0h)-=bPN#4?
zqq={Gey^@yKrgE6Cd9>5jgQ2m2J5xUZLcMrwaIT8H(*%qvG1?y{^C{-|Mko5Qy;(2
zm-BB)eCn!kYJ~d><$i0zy0yAppD-Jg3%3*Nj_P&;_P0{Q=z?2U)x9t3rmk-zu7g<j
zP`5qN;p+M*)LUKmLj%?IN`z^qhAU~AhkLa8TUFf6)!(|4z8-2CL->7)>PPm8V11^#
zT^;{5)qUQ=Emn1pL)WV7(x#I3khDXl;wEh}Ssz4wmbRO;iKP9KOum$7GuvBWE2Mzf
z!;-}g+#mvyAq_Gi2lAl=G$vdlU^OH{GGsyy<Ut{r@nB*N0icC+Fyq<83j!b>k{}Dp
zz?RQg@_o{}GRKB!h=aye@DCASUzPhJq(K&(fqanfgywwrvjG=Sz7L`i5C<uc1@eth
z!}q@$U<D4~0p1V^@{KUFI$`l$&<bq89-P4oB0xIh#X>yn0^6FjDWDKap<XTG3z=YE
zn{dDfLLd^NAr4ZY1RN-zXo!OZC<AxuUL?do4%qN)6#|Kn3K>ucC7_|qYk<^KAJBph
zq>dy)DtJ>D5+N1RAq#TBi+g`OB*QK!gBn)kIoN>{xI#YIHe?%IK?`Y+1!o{1%0T8+
zwF4*c1Rsckc*ur&JZD&gJvc)woPh!;1_$bC1n3|RoVhnfK`g{W7D$IJJCJ*qw9jH8
z0a73xY^^yiXh8>YVAX;;4PFoc36KxPPzE(x;s>0;4H6&)%v%vxh=l}5fpo~QB`vKf
z7l?&iaA`xFz#Bp!2I3(Jiou3&%FdvLWJrTd@USCnNP#qnZjVA1oPlESuqRvyf(VF%
z6v%*V$b}NnbfE0O7979>LLd)Hp<YMA1i2r&f(J<3H5Uq?7|OuP0YBgdp5Oyf5Cbxf
zA{Ejh7fK++k>4N*w4FH~6oHI?sn>-#gLI0Fg?LDU43NG=#ZbeEV}b*?fH!Ema$L|t
z6vV)4NQF$uhca;ML4H6Yq(TN1LJ63?LVkcfxPk|GLkPrzbx-ONIDselKnO&_YDk52
zkUm0rPzv>2*bnT$2|S?`VtY}JunRJw1k8I=?qCnnU&sR@!Kx4LU=Qx#1p%OiSV)Fl
zVCX+o%DR~==NB{vCrAPJzN81rz`P%E1AA}==_}+3T8M>Y$b=logF-NSmH2>_8+8Vp
z!5zFo2diNhWJ4|#f<=G)f(yv_(-1I!jcxD%ZwP`&kiJAI;OfqA;0=)w4RMeFX>bPe
zLHZP#4<v6u`V~2Y8w5ZuXa^B5uo{dXum|Zg<OKnsg;+?2Ovnf6KU4~49+Vrb2D>4I
z4Q}8GKA?rwkPPWyF_ip-Ac%x$h=T-3hIGh<VlW#<oWK^`!3%;Q5|SYua-kT^Jc$Q5
zfEy%0B9ws5aNNNK+`$V1AQDzX3Zy|M<Ul@{k03m70uRtZJfuQ8WI^0WjswY%2|17l
zg<$5z{@?_jpatne6$7gw6@o^Q*Q1FSctH##Kr*C37D%6|dSDIq-~vHl?u|QGgEP2+
zC-^`V#KSJgfjlUL5|DmQ(O@%<JOSy4nGezz(|kN(f;HHI^v4VU9V9?9?1Bu)0}mha
z9yGq}2R7gZArJ}D-!d7}AqVoH5Tx&=xgY+)8MF`siI4`lPzW{rDSyyHI+Q?UAbAHx
zPzKHuI36Uy8IXRPC15s@{eviPh=$c*A57jr8e~BM*iGVhSPh9#2JVw_1M^Vw8$2Km
z5+N1Rrcn36JdEQ)37BcgHwc1EI0H^oNf+#bOvs;xpK!tlZ?K9Wk0Ao0!D~AHAs)<U
zus^s#0%SuTc+cdRunXKG$q$HuY$$^ovrw>~P23?8k|7rg!S;2+fEb8}Bq*9oT;>rk
z@CF_1f&wT3I~{%@4~igWKII8AIKcv(7m+`Z2zhT%7Z!7D@Bs4|*1-b`-Xean_y>0=
z0qdp274pGm8Fdme;`t5C*0S%rTzen^k|A>)c@O6Av(I|sok*I%8{!}lf<8bY6>20=
zhanCUAtIT&1lbU?nK(fSXtt7{;01Az17%Pnh4?}QL__Sy<Rg@VW*cz_7l?xl$bmd4
zgc8uC5(Zd-4cLP-xPd45KnO%a&~}c$1BGPBghQ5;M<?FvphwZ6=vnkOx)+sapSN2P
zhdTOae3_GUJnjS7mUjx@vn}nB+HCJcFS9N0OJqLJ-KeyMzeJay^3LB24Q9Io`Yl?E
z{m!7b*nSOtg>5;$hkD#-+-2JVm3N96=v1~>qi$$_{L6cleyAf_7nS!PJyChLu>gNr
zXe^qFW~1`%$c^9SU4}U-@3F4q{yKUSmA2I|GzB#-#vCx_fH4P*Ibh6ze`XGt5!h&r
z33nOV58b@O!o9=%CVBgY26T3qFfGtKG<eEnEM5eLcw_!G+<Q9zy~C&Zd;4m&vKks3
z?(ZEL8X-H0cV$2C@ZgEq$Y_Tf_j8T2rHK#i1zt2Y(iCXTAM3zi|7l_2VG|;(ZHKnD
z9;}TB4h^0iJY}MFpRiCZW_YG)>S$~%$B&=kKi)SYVp_1@bmpLE9G;D3P+*8Qa9Vj+
zzN_Hw8xg`WWFN6r8y<m`g7KlgQ+y`|h6YZd-6?*sBtrLn8_SWwQv$+fhBH3U#<Cv<
z?E-xD7U{)LuipLt)K4R3My=eDHX)d5{3E7?5JlCZ{Y&a^R*!%4!wMcobJgDs`&ui%
z`}&0u(~7^@D!*ZA1VgauZp7W)Qr@x7Q0J`ot|TR<eCm-`lFFF5hU}M7RX=~ek_8jQ
zq*34$f2{EZjGr<+Bt#oAZG6NN6E4m(!h!>=$*zDv{}5a3E4O~dT5+;f-P*KPTnS(1
zsJE2^{%(0<bHbkA?3z5WIU#e%Ur_BV6qxFF9E@1O0BA#e^UKFKJTPed#Oc1%B)a}g
zxUY|2g~&YH__l+ieL$DajsXsxx;i;@32^Z5(#g@cQz!pUn3u;;b~)qQ7=-WC!M96*
zePHJRrw;y|0z3QqI&}=_;?Tj~sY4g1&gG47ced}~+Y!IMo&37^cI_P4)zQ(x*S|~0
z4vzi~e)e7bpV*am(kHLNe;=0)xYW{AwtT@{DVN7~<y~-pk@Q!z&mr}qqU~)P#qDub
z;2f~D^kV;3iu><vZ_7LUinh0JsO1n-nH^agK^3Sg8!Y*iYiUeqrmN@9e_%m8ZH!y$
ztF@A{ivKJYkZnqt{Gv}YWumvmedY1?6I<L;Mip&wOBq$P#Vuv@EL+@CM$fXvEoJma
zwzvzVU|4v4L0R*x0__RMLtlrUW%AnDU|jdFYxjTM7PlR78Eo>TK8o$^0k}OYVihe?
z{N))%S|z;ke>1$lJnsolu0tc#>!!9U4lLb4uA7~~mt*A^@>Xsg%5{@#qF6E2hH+gC
zoc8QX(Vtxx_4b5najwdBF;h7wwNJ%GzB|d{0umRAlf=ck+Ox0W{~d8L*lw2ZTe7?a
z&%ui@jJRm^ad}+5{^~OO#1P$ImyDdF9OfCz6I*K%twF@YaGf;RZhn>xOG8@ZJDe=#
z)A9;oBtD&%zpRQ+((;#HmHVUqs1^S|otDmjGc5-Ddv;P7EX_cYCFK%C7&%X;<u6bB
zCpUfD)&%jV_j9>ti47^Kw-d|7SI#3tykvZ%EOH-_c-4o2_|-h8)ZKrezJ$@1^Nk3b
z_K(HO{SV^hU7a|vl#iDKeyyL5*IyRs|8IVEst_-OjjNy<`gm35CaaukXeezZ7k#{>
z5g9mxRx0ftZN&6xf#O@v54raLesNLkO4XrVQLNvedsqkMEs>lbKI|a<^RU%Mu;U|U
zY4tWOrTwOF8z}CNFW_S9$%fx(BD0Ua^^S?F0EvXyu=F8MJ&AuT+X4FHk-z%-@sP@b
z4ZEiTlzLK2)78?kx>6UEV~SfpwGHB4lYm%W0J+uCtko}7^lgyeWyaIDb|qh|4f{N$
z`g^<NOFey9k}p!7sn3-yt37d(s;#u6d{D_N?$OW8E7kp(c|{vQdD1cDm88*NS1?OW
z;{w8$@}2`>)QvcOo=n7$;lz+IKi?3wiLY81RMPhBwxs@kBIWBsSkl)>UslsY*;MW;
z)6{!hdM$C$XkG<b?G0t*f=i8Z_mzr|N8P#wOeZ#aXMNP3eb4LGEqF?BM6hp2@N6oG
z)KM$K|NZjhxxktqFLM0y*Knze`g`J(z?tJ`_=ZdmRO(tb`Ibhc9r%5aKEBGeh)s>Y
zt_4dqRnjZ@Z8*OiYKyBfUy737a*=c8qM4`<1N(LUVN=4xLNH6Nl$rSbv$zvorG8kW
z&&un^<*Xjp5r0zTQn4Z^=lsXVojxUex>n0`p4bcg|2+2i@e{(Pg^JxtDgP&VM|jjs
z4yoivNA>*Dsdv>;xJ#ToVJ301uc?$jJB5UWO`fjB`A_oTNqw`%U&TBy*oWJ#v}^RI
z$9UBuo?J7s$(JbN(U*OD=#NWXw4~NjuI1W7QicZmmL+PuhvP@i84s96yb~YCo7W07
z&UiTxz)%0Bb7hKpt|TZi;=4HE$$hK=lu-B<wf;HhioRy+<0|F$`{l`bV$YA|&lAZT
zgKa>sI{H2B5V>ZygxTbciy@xA(r}f_iqr`|)`NVf1jt(y{jnwNXDrI|=}_9+?+}*S
zet$+F6<hIt+1ya-;{Y{}rLU1JLqYO*AiPJu>z<1HldFn)nix_Lj(4T3pPhet`-WnB
zP|_&<?gpDwc;|t;<fXyhpNsm?E76koUviEFaWg75#Akw5Y5U{+m&euDUkjxcB|IbC
ziG*uWTdhmlNPk{)O_>nJdl*tB*PlO2lZ0)sCFm{>f-Dz_urzT*f2DzIuMc~gZ*chI
zHba);v*JG&^<9Km^<k-}#EElKzg<#Szb*I4`*oCc?wt<uc!ZzImfQ8m!Ocn8e(&*i
z7v-9igTH58Bjnm67pTD|VVGonlCg$%ioQMa`1VSkSX##5U&dtU_jx+g4CO3kZFmM9
z&(&Rj$I`c3<^Cz-CJeT9Wglrr>F*!vwMu=i!&!-c2UH*Cv_RTlQ)FGPV~Lch%u8~I
zZ8Z;+wvU!={k2cbp&IVu`h6PXUnaRq#?K{vJ}Jj=Wm}&Y<NHQxr^#JUsh3jDhGV6%
z-$(fS$U<Kpl27h`u%BTcTk6JC`~>UEO}Ssjv8~3Bmw@_w(LHukY?>>_l>U4+>@Uxr
z>(%|`IvvDz#p|@R>3r3Ca*PY6Y_C_hr5yF=SZ$?#Wy*z=r8&s;O0KW6*z4P1N`1AN
z5In_(jF$62^85G8llGkZ<F=dhEYr8=x;}C1ByNVf{6}?L@-hd1Qcv}5H+|bl?q#01
zOW6$ilX_bI{Z9FMs^902>#1SCKdPsLR2$Ic>*?ct{-B=9yCXwAEq|TJXh<ShKCh&|
zt{p_zac%dguhgf<4G_umNWIqz|Mk}ixei1;Z@3P0RIUS(e>!|iK9z5Kio2Y%`g8e7
zn?&-}2X}otPtN}*=ehjm#&7yMD%Zs)KgzSGEx*Ya3d1=pbv=tZ<wE){@msn+J=_N^
zEv?y>`lGxzecaAd+Vgs2()=dJ^FZ}+d^#=?b~24vXTqkdh32dpwv>kp+sWkL<7-X1
z@{oKtoVyaY1oj_~|1Ayl=dPqft~=$=Lphf8fsF@w2mYDr*YKX`S?64t8lM#6A?I9e
zeYq%O7|Ne>$^#W)R(!7V(Vr*!vR6+!DSvDH{(gCK&P6;vzdAlX=YpTODd$}II#K?d
zDqklQcZyz)RlZK>&zoo0i9sfRTqg|YOZl?r7_@y1ZTvqj`-;cZpF1^_wnH`Ym+v|1
zbAl3v+K3t-JcS3N5VhS|LOP@mveAyM(T=Urj;+y-?Z4WN?Z3Ny+7++x{?+ua?auzf
zHPzbGKkJi2FMZ~>%Gahwm(6w)9m-r?J-p8^sBT%@;??y{!spSC&sqE#?auzE*`58n
zc49+mSy=xK`?PKr;?HPLc9GGZEcM`@XHRw~tzB!=+Mg{RW>>lUgkYDChWXrfTRvv;
zj!P!~?K&pjN=}T-efZVC&YtYQyPep7mHpShYuEMf+G{o1VKv%eHQHe{+F>=?VKv%e
zHQHe{+F>=?VU>3AzpowEziVIh@7hiMzh)1$8Q)v1{{?nQPctaM+O+#enLoc@?VY^6
z&%dzt=Y7|@9-E;(xYv1^e~0$h8+cyozlM3FoW!5eeyP!Zsnmo2JN8TeRdz{bj5X)w
zFULI>_IY*5f$o=Ejm<A~-~E$s-z59ttDU_%T-do~(i_YZMIQpnWA6yZd$%GUhIZ{R
zdD{AZwf0m>Jy2uoYnp}+v#NP?IP|*S&Z&H-RmUhPeTMVts4GK*Y(SR!mGt(yo=17T
zr)hxRM&;YBI#x(*#A#$d={_%gDrCu|%LSis6?>sg(J$GSzEa1~?&t|r`l6je<-6-?
zRKk_-%<9+|zD?@G<&*j2{tCzOCw-P=fAKHzSI1!}<1=(bqI~@S%wDKE#z5(7Q8C^3
zO!UVoMdf4rZ>ZsT>UaQ+3+@&7tEA?aDJto#rskJ5>uTS9`d1Kn;z^g|$9-*|vhS(y
zOa4rM278E-Zne+3(ih#M^3&;dP~+i<N+0#k<>I0C30Ly>&*Gu>(SD{sLp(AFTkSKg
zk-pRt52~No!&H_el4{P{MwIF+eQ9)jYL~t^I;msZ(3jEeD4!8DJJ3PsPILrHI6C=e
zzXuIQ(@?6eW-q!BO-EOupP{L!)VqD?QS>k>_3a4C>p>lLMyWRs(9>*70ep>0xk|m$
zR8jgnE8puS9p&rYA^b_blkmmA52$^IWjYEa-SWF9$U@mG=_XBz-M^k_AKYEgA!sjD
z`X=;7Ls5QH($x=@zR9nmavT>y?RSftCa1>Jc8E9OuNLl-pS&j3Y(ZVntteqD_Vgqi
zsV{2ZTg5J8#rm=s|58pdXlwLM)Uco0cUI$wd&T`0;7|JNQ5HHmMzp%08|!NSR?R4N
zzbdGdu`EN?{U~Ey54K05avh+o6+4?_P{~VgRN^7wsr^nh!&#Sjln>7je-eLxRN^@a
z<ujLJU$s9vg>4U1iyG3U_9<1aEt0RM{B8rXEXALc=Q5P8B%0;r_EY<KDs$^q%#V(o
zXA-YYXiKz<dfrL=)&7-Azsrj8Z>t`!Ju25d@=`f3I-rtg9npa(pJE=zU+o`B|FYkg
zOLvZIhPyK=<<morhm?`p|M8jo^-}lit?t)H-B0EKRQon6eH|tK-3UwO2b6_50~I@v
zo6&k~Z$TTQDQFAyW3&zW2|5}56pcc6qw~>p^eyxND(CY-bRC+3?nV!x<2cq~Gz9$|
zor*F~p>776g*L9lJRYbmdJ^q`GKZm#ywIFRUD2=6{^+;p9P}KTh<=Z5MoEwE6Z9u^
zH+m8M484RNMac)<*XVWh7J3t{M8zpaYoouQ4beNO4SE-CkCvfbQMr!{K_8)Es0sP|
z9xC^XWYi4Zf>uUTP;>MsS`)?AwWb!DhgzZ+(K=`mD);5PXhXCM1>XqmioS?WN1LOo
z&=zPCN*?JxL0hAHQ9E=$+7>mOA8Ow~rO#l+dj1^#<ou9$$#q@gCHrY93$<^X(&tU~
zlk0l`?y@u?-BKT$p;9j}rKj9q#XfTg+ilUQXghQ^YL6~LyP%0^S5)dlck}@2jB@SQ
z^hD2~F6eitD|!{}i%Ps+Ma_tV8(JIfkJ_MvP>!V;f^rPaP!vBJPn31d7*x{ajm}4@
zgSxlS@#rel2Tei)Q0la1B1&D-1fkR!O)yGZLPMR^QC6C8^kp;x<r<-xj&javUPlL`
zI&?I;01ZRmKtDob&^_pz=w37ymA-^aQAwXI`25NJ>oxpIc}aS`xj_AIwV%rMLYa$e
zmml+3<#LbSfjvIRgBm-rvj<u**i%hpJst9(6#gCUtJ)2~t|Vob4MrQQT%%pNo<ifk
zoc|zmCPqO5q(dJ3qc&EJwpF>;&`|rIvaOmplrn_BYa_LyZPXkZ4?Z-M#V)GYL@jR*
z)j>ypUhZXoWCPV;|5R+B7C?Esr!ux6XqVaFvU~b>ZJs{M-sxZ2It}7tEw)Z|#N}DG
zPQ}it*n_npo#kzvR<v`PAZdZDPt7!myUjGkV84fJAe;fGG;EYY2AI(humMkqf?Ozt
z#{0}P4&VXFa0bk1EHnmZ@PH7AhD0zf#vCx_fH4P*Ibh5IV-6T|z?cJnKL>cEf6D$}
zKF_o7@Pb9gXPfZhK*m#-x7YS=NBwxh%KRo{>11r5*mNsz$4!ndW8MydjAxU6+J9uz
zP5l0M+I5qO@haMOyMo)_v2k}1e;bJZ-?ht^gx`(u&$h|;?_!Hi#$(D@NU@i+8B$;i
z+cGXu>?z53bTg3gwK9HN#$d~s>m%%!1u|w><}A32yVRX#tWN-$V@T#Sngd&!@+|?x
z-&~jnI!MKB2gu}Yi(oOtfXqd<1Y%)1#DUDkwgOhdDtH@YegnfIWBtWu(;?z1<MT~f
zFCd;W_rhf;ge!0ju7lL^8|Y1##JbovoC3vcOFC|$x8WC%xg+j?*ed#_u10f@b+Mgs
zA0B|r!y<X|2uz4mC6Ku!Ws%>mk~ilq^|tk7exOTgUQNS~%qwz(?LHv$V%$Pyj*}u(
z=9Vc$4d<jB%NIAX5mwPnY=+I?H<=TpnDsUsN9>Pza9qRE-HLSLzMtpQEx1b<FS9N4
zJIXwhne125=9`p7TadZxj`Mp9v;)YTNHPbL%zf1goS-W>gTdyT%+J+JwxKWd12^ao
zGPj&8P0-iC9b~R4nHNmv;u{PeFcf6Yvf(fiM!{(ChOr=X%E|Hzag*}-k~AHK96liY
zfLk6k#*gGhZPl;L|0l<gIwf&$4Q=2ke#Q1zHv6AOe`fn9D1iS2TUvi*N9!xnCAMb%
zC+umh=U5+tEPuzg)_<2>tq{)F|B5XwgB>k{{Vap+EV&lSwNmbL<!xxm`XAZR;`5;L
zozNZS8>J=yB0vXmkO;dV1LQqzJrn&mj}%ny;d~#GZ$KJ*Zt#4Q<D(INAsg}_hHp1w
zJF5iDc!gpCE)WUwy(SAvz>N1*^}q%kAdz?ZxljnDU|v<eOA|KaKpxa1@?!5w<~$Rd
zS5aWFd6mw37Fh66#v1Iw1!PVzFDL<LJ}|q37sNv$lz^r-@8BR6@}LOB{#6X*Kt2?M
z6?ts~_TUWi!6*(AAr&$p2l647GS7j0D1uTjr(9yV?iuV{6|nB~Jl7*gf^4wmBdrs-
zf!M+F=6ab586dW<A|MZnpcKsc$Z7))-~zFb0l83vdyp%5f)5md6X$~)c!D+8Tu%r9
zEkr>K#6uG7f=oCA1yBlR*5olX23v3fH}Hf2h=q7?Xi9v*9fBYlRzo7lJvSY4p#;pD
z5hhrJ9k_uf_&^B6KoX=uCgeaKl!BKHVSrr=$^_g&Y-wphKFo<tExVS)6I{Uqyde@+
zLn4Sxtu)ZIBG14I9KZ$KAqb)&5i%hM@}Lyz@xjU#9KZv-ArfN1wKaJM1)$-hu@%^W
zJ&0W{9}t^dQ4kBMkPg{U2&G{4GU0;<cta3GKs2O)!CqGm>-k`A$39>SE)Wl5$EyTv
z+7eH20S}0T7+4L7kOEmy0&(qGhg>KCvG*k(^JPL62Qb+8DqvmHfqVliumPD6$Qyzn
z0^%SA(jXIZpa^`p-<5)SCyozdk0K4kUPe9?K`GR8;LzX>K@b7bNhB7Mp|K-%6*3_g
z3ZMkcI#c%G0-lfonPA@qH*g0p2mmcaLn5R>E);^;0J8yS@Psrl?@AtkEBJI{AIOG0
zi0@9mK?#^S6Aqa7Aa5WB(jW`O{+Bz5-LE{b=}DL%Hoe52m$?hSLlne{_M(1329$zr
zZ{iL?kPLZX-iPCWPe1m73=q3oC1Cq1{vik=AR5v^>}!QU6j=3VUx<T5$ad$P97uja
z$RN%^$bo!_AIv(4EvtxO)G^40Jc#xru8;wRAoikyz-k2Pg%Bw9p=^A~SBUhZT;L28
z2a*>P$O{nrL$2TnF^~?~Ahw3GArG8Fh%cl=HY92}CX|BM4YHU<8o&$UArsDkSvbcA
zu_fdgL3|+tvZk{yi2Wchh=F)Wf>cO{EI0%CPz0r5Hj`sPW3UAWu!*GZ&O#vobTG)0
zyy(b&7No5i?NGL*-B%5j_U{ecrOkaFRod<7EVh3^rQPj>KY132XIq|SDxvaBy%&||
zkDpO#->0MU46+=R=O=kqmHB#l;8)tj15s(~4o0O7EjHTaIY4I8lXkW|cS)P~0q)YC
zFGc0}e|O;)|6iE@pV{<7g8hDP0bpu4^BpP%0RA`5|8JO!-!R`|P$hkC|AI7y8(`|d
zzmxhomx9O)$q-zWxvsoq<#&sPGC!Nl8RWxn+A1>VP)L|~6E{vL)h#I4;HG6oo?`}^
z%nS~Q2vYn}l{GEfiJL!W6!i1$SmQRFf6R~MJ40rn6w3&>$y`MAXVG{P|4-QNppUN-
zjy>D@IE4C2nBrI3lOFheo$c<bUzxYa_OW06{MIt3j?7b(sQQukh?`-~OlgD4Vg)3V
z<LMU*bN&3U;f4$|%=;R^^uSCM_Q!J;DX#^TW3(~Mfl0eomT0I8^PnnaVoxKLWQ5Q3
z)hgjh9G<Z#Wg%&^=0|-#_>!jbY4v-YPtEaTC<Do-9MTuX@wq){rs$8S_+?XLMq-%<
zRf<N5uYUd^3rdmmTQY;?hpIeBqhFxah;zO^4CSPf-z6VP<;4B{(yIe*&tXL?pWg?Y
zm~h<6mfm0M=kb~r=s$g0c%VKml?`(x`uXCdxS8XouTN8yiP5CqSv+=oQpc=tdyaS+
z>X`VGOs%fCg@lDiOs2l*=VOc@KGeI2$xL}D(G|a5s6J1h)Mcq-`eTPH^U8`pkH`L=
zoCn3^t^PPc!TRHvT1J!C#iVyT{%fAn&%Gtb4`5q={HN#JlQNQh<eBCp{2VN|54Wa2
z-N#GaC*bsx<H#}o>^Q0HbCCFL(U*gg2Ttr`$b*T~XDMzjkKICpCGL_3ZjaqU!o;89
z+^Tg(e|#wiIoBpv*v_i39enm_|K}@g_y6YU-y3}U^!Czn+Y*No;$_Z#%Qy#?aSklw
z99YIVu#9tHO^N7srT_I2H@5Zm+Ognda>uXtcDA3mebk2|x1V~K?-4vZTK|nXuv!L+
zzoa>xC%!hI#5-tI?*^M%p5L>|<D=7eW^6f@eX45nW^p%ojxo-Gb!d)f&zLL5Ik2R@
z80WxRWSj$wdhpMi18anG9lAGooM~jc;*%-ED>dBk)~1A2cRG1pcB$IF`fvTKH1eBk
zZJYz^(YfVyKdijbeD(69DJ$piYcaXS{MLQeYc$3=upZj%?C;cXh)ZC}oR$;L5ButB
z-?XcYhw3HQt0hOi-LmhuG2O;_{qmu9n#*^)&n-==8kxRg<gwVqljetbR+`JZS8LPi
z{k8?hUd_)wdw1Bf2`TmGwLR$HwQA(?)tghSx&{V$?&94U?`^G3=S<y`Kji2a?M}RN
z=<@Q*YxkF#UfyAS{LR9c*P}Mnx+UMUeo^kfV|{aWhYu=VXlGx=O;ecjLeDy<*V$xk
zKTvgN(a(F@tm36dxP^pw<Lut>2itoUpUUf*Zkz+lI0u$-4lLswSjIW9jB{Wa=fE<~
zfhFw&;~ZGp32hhDxcOk~$*YUrGcDj-@oSPV*K+Qxolte@)s)U>-@Y***8a;0``a~*
z`DxdOekoyjbF+D8yo_(})}~|g&&3_ndACk$**WJ>%{Fr_*3CP$spY8o$9I2hnRenz
zOU6fc5r0c()E!@9;&SAh0o6{0|I{k%=H5wd_g3vbdPi7`8n1S`zn1o&5}x*B%a)q%
zo)OMzr`FkDTDm*0?6vcsH8-v2*m?VeOZ%Fvq8}*l$*oO~3|e|Wtn$1c)6F6d%<#U^
z?WZ|E4|uuB(Nk+ig*Ux@s(|n8|Ef8#jB{HhH(s#k{8Z!IR#H!mb6f35*|g$D8^6MF
zy~cOlM8Aml-6daoHko_l*VEdSi~DE2+s1lz_UFIEwBDY3XwBUd5eu)Lw#AQw^4xeO
z`a+fY4|`m8{%Jt!y6Nl24BlpX@0&@HK5aipS?RE2ARn*(JLa~MZ@TI?e~t77@Zh^&
zbyU9P$ugR*B~4LZRKC;VuFToQs}@~2+kE5KZ9(ZSqvO$5nM-CjI+g8XDBWFj=TW|u
z>bT@;qR`u@d{0%sYb)Qo<+$d!ksZp?34e82;}WQAg7WQAnX86Nr;hGJ%G^Q3LFUR)
z<^m!Mb@SNniAwm^d~;R5K`Y;;C43&^HTBf*_*?NO->Xy5AJLD|XcMJRfvydHcCyVp
zHJVRR=7rIaCLQy=X!fBp2gQCg3jG{?A3cJ~928mT7wA#+82Sx*8~qM-;`{A6bTFES
zzK#BX${Z%-k?uB{k5)6I&kR}@Eks{L@1d>H2WT(!A-W2Egsw+TnX`hS$}+!{t{Q2r
zi8e)<$3qv6($`iu53P^RM_)kW(WYn;Dszo|g0@6=qK@csv@`lG+6}#l()U8wi*Np~
zpaap~Xdvo}?m=ZvkUVq*D*bIop}(S|(His(khwyhM`ezXW~eV}hx(x%P?;m76Do6r
z^h772L(s{nKPq#CgrZ^SEOZ*W5S2MYV$j*>N>t_wS&Pm^KSAfA8K@4GJ_?J`IMVaK
zb&ijM3G`9(<GjhGOduBi9p~*x;@ryy<D4B_6I|(+2aWr3o`E++K?0;h9vJ8B;2J?E
zn;1xeEGU37VE!MCmlt^kiI4&L@SiYeM=TxG{%F1q2Oa%Gxwe;~$@BI7hGdL`8zeya
zIXcX^)|M?K4^XFQ&U>@~O2Cb62d;h5V6%uYQ4cg7^+B`IGN?Eghs?u~0R>?824SJr
zs6EL18x`l?NIGh!v3QQ(z=nAL+1wks_$>yjV`dsVFfPU%Fy??U2aGvj%z;130UoEG
z8voC;oHB->%z`n<^xJL$(tq2Whezp)9M7}3%n2ZUb*1mA^u<;BccaqheKo)LwC4E`
zT%jMh!2po4`0nT+ka2iJ&|xqf3`-Tlkbc^02uJ!#cX<B4e>|-m`xFnzXXGK7<va9y
zb^QW*QC&A_Od7$k)L^}Kx$VCiQ(Jz#w1iQ9Y;FB|^sxuSVo6@r1z8&5{zAFmny_xI
zZr3Mn4b=FF-%hMMs@wm`V`&G~r+r2m%kyVrWvxiNEjWQIctZ&2AQs{w33fpS<U%26
zXy@`AEAv}w;vorAAsfzsjH9i=Nn!=eaji)KJKim5K?kcL3DO`Fa>1FVS1d5anKF*H
zpfYW@Dzp#52O85ZbcaZg=WK7<fU%GOHL9^cxI-f3KtA};{!4~4Pyms<SW1R8C<D71
z><4x=@e5i=hFoA+g~keGJZ&tbK^9nWemR2{bdUtOU{3w9f?ec)5m-|e_7DVTK*q!B
zI4`rH6wDitH;qUO#KRf-h0D2N7{jW0k#%r`JZsMDruYX}C<3cylpW+k<L0CR(%SMH
zlz~%w+S#xgQaf^dD1mGT!gAz10yl_)Sn%ZAK`bOdDHXz_E5AW3`1BxOK*sk)yh8p$
zK3MUx%L}4mHDp2=)NmpEUgQzzAf`9_LKesvJ~!}!0MJ4d#K3BZcI6m-QOJaRsLeSo
z*U6@+T<5Bya$Pkp#vCx_fH4P*Ibh5IV-6T|z?cKZ9QdEe0Ul8_6Er3~jnjth<{cL9
z9p*R5+cz|zv%`dGf!?9PQzi#an-Un}?avr?@9F&a4xi@l?W@(wYG`n{|L;ft2S)k_
zY9oTfri`Bu91;;YO_>OQ@c%E&1%RCkWeMOvk6xPbu$N~cmlKubQ8UtC8xax~HhH=h
zcNxcRi#}s<*^Z-O47JP$H`qjW)sM?=#JFI2&XqY92b=i%D_I@k>lYHJA2ZA&h5B2F
zZ+L_{w)?T$gy3m7${1*|J7Gh7JM-H_ef*R$$80L|HV!rkX74BC)H`eR<J8mCG`8b6
zNn>j`KwL8PVT=zC3{p#ed_V{f;eVFS4($6^>71gZUn?09JY_-{Bgw;+anOeN7{<b9
z5id!*sKiHeQpxl3@d=D1k0d_wKHwRPI_|#)N90-ml(Ij0QrWVALH&|l?t?no%WvZL
z&11I?JXz}9vYxm}5h?!mJ#piSRPUDZ#7(ka@%R1{H=bhkZgEfCl&3_=t3-Z#R-H)3
z{aJZs$X|VZQSy;WBl%!yse8OnSV+M5r}J3GpIh_0%=<XlL>nP>TEdcq$()F|1^G@1
z2nn1f?xvRM<og*eDD)H1<mmGrTVDDx>@p|hU=umU1Z|*ySOCR9n)P!5=;QUIu6ppB
z-mP3+CEOg4jJc(TE&IE$Epv=ktgA96-dQa_nRimQW7KVlyI~BwJ?|=vW7v&j*o|Y@
zjbqr2W7z*WW7s!vt+zJ4oOZldH*e2VNvmod9bas}>{gZMdMtl#cJH!+6wen1c3x;4
z!~RjKaSZ!!THc{sNPRJmVK<IpmwNEe8^gYn7PGZ!?avkuv#Z>FLa@t6!+dVLEgv&^
z$0Za0b{!LMB_~GaKK#l!hTS-ZeaZKAxCY6$L2J|H5f?n)^jZC3%%I@u#xd+mn_&yK
zyX4D}T6O2nD_ykUUOSK9BH{**4EJc;Y<*<&LCM|rw~V=4_z82mcN2epjVldJPVO+@
zab@P_aaP^h&AvG9!GYJ8<i4?OPR!J@fjr#p>n;A8yySFp_SPG{_un=>c%yp4k6oMf
z(FC|2IDP%q5uuKry-Vq@&i7Yq)6FN%4@Otr@Qy_<o3kHZuwQ09=+&=Vy!=(0(=}^1
z?GoL?k9qm)i@)!#<@gud^f=Y5s8ihYzNbEEFl^Mv`%Tu@oIieVrAv2>W7v&j*o|Y@
zjbqr2W7v&j*o|Y@<$h@#!)_eIF7=?$^~-4?y~9KAx%S=ZKP1oO!h6{_=8U{*y?o}~
zMoEXauV6eQUoEUnmwj??f5Sz0q6_Uk{rmTEC>y@zY-s$&_rv?OaxO|KZ8RD?ID^Gs
z_m47ve!to~d3&FKVeQZRu5~>&Lwj(q^D_Sq?XNfRywraU?MXf$Sewq8+^nT;O<dJC
zqxUxSY&$>pa<914menoSuR6Tx^O%>%UZiiZ;?L^XP_ySpu2`7fIpMiw!$;No-h2AY
zs$*7-YS8mYdf!pQedu$i_`99IBD(P_zqPlTciA-Yj$igA&tnTN#X5A3Pn~jP-g}9B
zp}DEFV_&@TRg+(~7o6A}6*zuQicf>!Q-yOHui81}R%p*5MfHOV8N;KrV^fEk-JL)1
z#n+=Ywchn&ua!9kGn?J=%h>*Pv-_(*d&gs&KjT(klXOHr95Xd3F*~8L<+#bW7wqo#
z($0-;U92{|y7q8rw{7ij^MUL`zVKL^UYs0$GiAq?oum9-T4NmR9=(|Ux%BZij&<Kt
z=Ra|*yBFWx)Nk6#`1Xop&N<a|@@?1|ZGiG<t!pLwp#9Na=x~%rLETuiFDl>4`=Pf{
z7f`<^Yven#gwLOhVOJI|HA?tAPAcIKLHU%Y8HURDXirqa@!?yf`W;yLE-c|Fzl%Fd
z6#jVhm-*p!bY0fy_-lsFN5vnnsddCr#?|Wvpo>tBrJ?#N@m+#WWcw|23c3uPfpXc@
zv9D$&x)gl}eH-QSr(2IEqN(Tx^booU%|W-IKcQRETj<AV0~7sNdd8FM$I_$waF0XN
z(f82<XbO4|-G_dLW}zAAH|Qa>06mP}Mn6aS2&&0MrGNWZsEo-c4!S|;Dbxe~1|5rj
zi!MXIN7ti2ph@VDXbyR59Q#dOnnj;;NQW~}2K8o>H{cFhh=UZ!h9WS3oj&nhScfvO
z;9h16UZ8~-h=*iIhci$FV%x?AydeUTs4LlE9Q$n?`|ZHR(H%k{4tBvAC<1d2>KC}d
z|HiT3g{F-2;GFuS@!vsa+(UGnQ|KR!19#$mV#TrG`8ODA!q}Z?e*3dA;bIR@#)Z2t
z=VZKzf7btz@!>KSNXCdK!5@ti52{8-GA_Io$BG-qiN`QL=&#0#Cm%P{WI_R$Wt(a8
zc9>~u>@?FjgBFa7F$at}V9Wty4j6O5m;?WNbAU&<r^f%k#IvFF#~A@)uXwm6>o5`w
zi@3YOLud}S;SR`Ri?#+kXb&AhmPcqM!Z3p>YFPbn>&v>>R+MD`+v)VpmA>1@>goG9
zOMm9$th?iu%(}rA`Fm`y1H&Tyg%5%B1(tB6Be>X76dTN9Lw5vRVSPEe65fV4*^Y%Z
ztgi*bA~qi{!Uo(<pkiD26r2Ua@&Ui~fxhZ~N$5t{1i{2J8QlW2U^Ya-T$m5huo#wr
zEGg*6unkgS2go9}9=%w%hmOz&UItk@p^nf6x~guY(5VovZjV8|VJwUTUkHFLgnJGy
zluJ(v>(2c43dk}M4Tj0;w)6p)e$&#A`v{r^(yuxV_QFxh=s&^kxy)PfkId5`cF<2k
z`MDY-e~j}r@NCH(0c$}PIhUml^(U`HW&Q?({qujs?zt;rMME4Uf;-nEnVTUE<b9UR
z$zaAsOKh5p-OX5#@hCFpBNqyx6asjJNq`hc2Oe=Wo;){2gFH9M+zPqSm}ezBZ~`~*
zf(Xz-EXbS-#ZU${m}kKXf*=)2z>GN;EWi~!z#9TU?4Ii&2~wdH%y}Vd1-9S-E|3Q{
zwKy&WK?Ljqv)Y6UjUfuMp%l!?TMtMAxlYMEEizig0bIZxydVL@=6pJ2Lmm`C86;C?
zV(YvN%sFrCfej>4W-_-!2{52T;|T$f0fpe&05=GL2#B;IY{&!GhLjl?Y@OF@M3^A9
z&ON{zk|7UDz?PS_V(VNBQD9EJk?XWvpS0lI1O=I}G!`n_I?ur^ABw@;ns*(L4uwz(
z^_meL$jjU~aBt3WAQ{pi)&~EO4PuWx1fn1ZG%d+{h=W`xgs4{JC!~W+G-3}fqOFND
zL_o^_WA9x6V%pmO@u4UrMM%eGBqX6!x(K<4D1-<#)uia&q!0$7;~H|WQ;0$+LdYfJ
zbO<5$kb6ktgq({1=UKC-rc^HP`+mRg@B6p;^qJXvU7q!<XI=K1wVw@S14=rmH((+V
z21wr(ehZ)ZT_Fn~2Eu?OAQw>YhGc;>J=6;zeNVTxKJ)}+04m)PA4mb@4N&L60KlgQ
z;sIFztshzfA|M1X$J!vR4~78rZfgs`2M`0=y`dw(1yJh)y8+yQ!Xdae6m0?!4MY6{
znLyqM<Zq2K1BxS&7GMK}0Lef)5H=bN+yV^8K+ixjkPbwQhkXHsK*9u+(H?pNY=Lm#
z6p#s!^A;1p60n&By#gsf+GNB9<Q)(P2m!)@XdoU)2GW2`AREX93IU!Y@&eQWEkI3x
zG@QVIE#L!ap&ik@V>y_{GxE<t-+vvyH1JCUzclbm1HUxze^CRN7Q-+7&p!X}FLH7B
z{@MY6t51L^(3w5<|KIq`e`B7Os)Gak7dUu2`HTGAy{6DR)3sE`xqG>I2m0e#VJ+1`
z-T_`N0(!EZ-chfm+PB}3Z-lW@-Ge!F5AOZ*mbE3;LciTN!N<m66$8v??AUv?@f0+v
z$idwU{t>(c9_*QPyDAOLf<2Q?&zp}P&*I`4bbZVK>6vC#RYx$bW8huv?AdHLd_RbJ
z3%zsQPbl!jSN5E>57>j9mpsQ!&t>c3TwB1pmY+}*;OFHqUEmQQlswCA19=Ca45xA3
zSt2t_A5+RI-*ryUQxD?Gt|x~;I55q}SxNcndstm%9+GveT=<S=W{&#!<Ld6EMKaOz
z`NUrzD)Xt}q>F8mv`7~$s4~uNEIVgfK{q2R>1ISVx*5Se<1VY45tVd9<uv2Una7ng
z1~O3{N0Dr(;{-`PaaHW(?j`V>;o#-%;q5$)m5p>*#ld_&P@P)fqHLX7;(LA-b!vn2
zvUN(&^Yd{ovNhFdpu3CEL1F|BaG8MfB)imSLMSzS9K!)+fbvj-?BWR(?30sPQYS$O
zQ^mpTljIiTqEv3uVJN;!Y|$sc$-~{5lZM$NRhoJ$l2c-jBwKIJzeGwMT*Pr4_NNWr
z4sHh7a;lQ8ya_Sg#<7@R{pqWZQ}uafs$pR3TD6#cB;d2Gyvg`poxG=TO;*?Bdtd<0
zi2$@U_nEBSNPHtyt}Chk1ua&GB4H3Z9`b-dX^@UOu=Acy&iG7z6qxTw=wKSYH=e}m
zgUM@w?~?r7SzVIOx^p@s|B`gH2kHTQpgDAAGg-Di-2`L@-}1*nbxHLj)s3v(#Bup(
z;yT$4s!(D#Tt1R+t;}qGI4`MxiOPK#$<UQ6tBC?K#ZlRI6C^T7+8wS_Ie)}vDerQd
zt=NB7Wv^0sk~n!P>qNzY>7J>C<o!{-e~&KI6)9!3C4lO^2|)F3A(J=N`j6&K`YuFT
zw@|_V?sw(<^0)EJ-^MS08^8Q*{BQf)xM+iMQto5jgAW#6IsQ)f^YTU6GnTfW`0#kg
z7T2#jtQ^vGt-^%Pr?K{ofu1kty?p0gw=LF#=ge<Vr{2}y-VQuEyS+)y@Z}1vhc52t
zpudC1du&GGI);r1t7jsLXdH9pdEb54U0N&|w{@^q>b+|o*Yq^C9(3UGw)UiO#b$fo
zbRRZ}cd7o=hs|qepGmzh{HMOk`CUl{)7D?xQ@Do5>pGCa#TT6!Q?p-=rdW67%YE|R
z(x+s4Y+RD(n6`3z>L>Tx_xhS#ujCE>z28j=*DEr{o@A`^^5qooeOZ_%e%raJoAI$r
z*6YH>pQ9h^DBigroI3T=1;y1@u-6!K8N8!0*?QNpOqE0TE*x6^G-~5-CZpm`oN3lC
zLshAP?YUsZmB0LV{J-kI!xQrZzMN${r)<UAa=!UWZKB*wqD%7pPL0wYe89MFzn4c!
zy~!_!k}8EWt|RE+dT?iIc;At8Z%&Sx>;5UK`AfIv5&E7jwU+t0<9C4v%uY)d?3{gX
z%g)COX4XI2q)qz(m6>_3b?-fD9Dk(f)AsGAvv7~0Lh1eT^YP2i2id{D&(FtQW>;#$
z118HfM-2^(Xpw!hUj7$V_cd2Fcy7;3wN>Zc+aHTQvdtjM_t4(PF5@0pelb`!eX-ze
z_vd~^M(dupsFjeV<8ef7^B60<XK^rv3!Z0^)Vua#t(;P|o{u6d?%R*G*_Kn}Kh{+z
z@a`V<DUGrJ!jQtX-nsR$j`zC_duGTBl>SuFKEE^3&vetch@JHtH~dW_58;N;?`Cpq
z4&J`gF}Ci8t#ACVUE6wfq3^)~bCgnJ?rQeD)2-nrZ=`jM<-62)b-Gj2k3IT-RvjLf
zHFwLEfV`Vm2Xt-C>%4SL$W7Be_>GR0LoG`f_o4PXQ!CpsALce*Kel9)eTO{}dK<5O
zxZVGJu?_A?`m_E%L>!`a=iR*N4y_#)&$<>LSUXF7!SblBqB^b5?g-kv@Hp20SUGli
zY4Dq#PU}<PS)D(SrEI+Xe9y8$TBo=P#~OEXO0~OicK_SvXHK1WTE2gc)sB^2AEx5j
z6ei#0zQU4I{g;pF>d|F^{2vD!Xow3h%$b$$b9YIn7whwOzQRHfev{<O<$D{bU$_yO
zu(d()YsUhGhF+T!2PzLd@o>h`*sy1<jC`SIl$kHLv{WM~L+{Wv^U%j1G#<sfxLwL|
z^dFVKyxz3!#`eQ4a1R~F<Wt^a#DC2XI()a+>-daNooB7CH@|yr--6#(O#kO;#<p}l
zjOR?x!i-G!&xS@VV)N>5$k;c*TQ2nNKJ^A`H_!JC>%74{VI%h3pziQ|q|2nIr_UHq
zS=DRYl%RG;4(CnLTU6X8*-Z2)F?VOGA;#&~EMLXvv9B5^%{hMa=|54MgdaM*k8OV_
z)J7*Y==>Ce{@TeKupZWn(mTFg;fi%vi`u;mt&a4+aC^x+&)k@~JsUa1yAS8L_tkid
zd||76xo6Q!vi_X>$@}_0C0`6IEYmUsjW#wiO`WW8%IxiMN8k0h*JJaI?G2URUw+}~
zJhX5AruCu-HD6(o(Br}DN$-1}w)*AQq{9e@XY1PpCz_wsI?;T0{;nk#+di?LH2d=}
zzb2=z?Dj2sc`|(8gN%Ts)>&t@@4MU2w;O*5H~p4me`ns0DtI@Yw`Ze9R`P*JP5DFi
zLrV%88_5^+4r)56pg;xhu3+u=a@=Dl&!eht8`s||xnV!4xG?3-@|?(<Pjcr?kF>lZ
z+{)wq&D!sfMC}bpoiC4mT2vhH?5@V7KE*SmOh?!}Fc_ILfB4X){jk4{<!g4{TtBMT
z9<}YMBVI56d!N$YfE6POOQJ4MztOy_hVnnN@mswG$v5@r^q0r-oaX%UYx2vl$uGYq
zzx<l~@@w*+_G==<zAwJqrnRyCZkmR>s(z@|-K75cqNjfcpY5$~FzHBQ(2$D*0}k+b
zJF(Wlms^<8<h76Xx&}8t1+V(FblrUWL50aFCR1N`)0w(C<AlWm9`6J8m+|HHH%M*g
zt6Fb~vd`=_$2@tzt1g;#+c=^{VA$h!w~S}_9LBsI_n3US2*;GH#UXEATzZu`PM9`E
z`~KGJ8pDI``RvKu`;;f&^e_BYqDJA08(g$Hw~v1*yH|GY<M(d9n0SBk{fQHYzKP}g
z=;#EDnTdVYEZ_fL|0iGA{dC<6yUlEx)GfW;d@3)lxBZc>F*g^Pm%2KS5gB#7yz%up
z?9XQR6{+LLzjD?|csINAg`RHy7q$J5Uv~|2w}@Qh^=VCZVk&+g=)>mYTN<1kH08jq
zJ0|s~i61QN6Lmb>{M@SZ<4iX9oHG7xi>FPo?(-YzPe0rDOKfC7?_i_d-FBRwy54E-
z$iL<cxp(C+UIUw>I}(xJQkGuqL!MKAeq2stld!YAr57~krFJxry=0$wb^WKsr6*=Y
z<JoZ&N{^Q=Ix=sIR@W!5PPd-=VygSiUH@18uHXkfly~*9k*l+fmbDDdjFhu96{K0}
zohV(u>(rdo9W!oiE#A2u&k?YC^L1&y?#>aFK2wrrU+H*z^F8ApjRa2rEOWlRW^wPM
zyXQLbc-Qcw4qtARMWA!+$I&;M3Hg0K23&3t)x{?9XzKx=E?JowPrEbcApEo7-iI$&
zq$%pKwa)to-6!X1`VWX+W1u%S>f}sE|AVow`3Z-|?8ClT><|5S`g{51$K{tFm;XQd
zanWbvpvfrF<)rYA=Tb-ZJG**Ftv;s3kyEY}IGf)bCm6RlEf4GC0a#1o%e}Soj0k-u
zDzOr%n0G(xWBawgmxV07+e33)dfwCLYji7ZZaA-5zx7|H<+obVI`{Z&!+tLEZkKty
zKUjKw+RVxS=c>=@#Y56J>F~od&iozPDe+e7`VW^x3tnE;Mi@i3&hR4SQQdi^y`Gyt
z9GVar5NU6{PwwN5sX>liw#KhE+&{b!&u!sW&ko@BB=KmkQb8T;?Z!DI!w&385I4am
z7w~nkEBFD}4g3;}Jqltu#PbF>1p9$$uaiHR($@yKeLrkJ5T#!m=g?)b!vo>ycWa6-
zm519u!+cs)mZuTIkvzEl6yx@jhasQ&lW7K?g74UK#Qd*dC=+kO_g3I2Ft)_7^f4q!
z_qeeA1C%~(h0z7*u*GHC*DwZ*w0L8|mf&$<k}n$I_Mx!-DHLB7=fVLx+94d3Sqp3i
z?g+;8g?!G4r-G4>xE}O_Whmy?r8~F>zGKQHz5_;?#Gk-@!JVNf{PZO54u%ZO9}A`~
z;&6ON{fIY%F_efS!B~P4(>@t29WgnPzI5*g+Y>@^%HbU3V#i{HBfW=$`QYDW;)x~u
zD0rGUUpd|cgd_dfgP~j6s$Zs8ZvRD<dY#V23j~v1gTSQM8C-mlm)kE<WxjK{_+l{S
zJ5MGax7UH~fv7C+N`#|whJnd$R)K@-;&}qCTD&}f{MLlzW9<;I#b*%^1|$HPKp~(u
z8Ep!%1w4QdAOc7RvVc5*o=Ip4=mD0%L_h>A17d&_APdL?<Q>s30Oo)#-~)sL8K|HL
za1xLS<N=BT*bHC+*aB`qC=d^10EGZO$6yFV+=SdfI*<pb-@@}2Xt3H;HXsRMOmNN?
zSO#PUqAWbfjY=>CtN=G47>EE;fM0%WpnD7G1qcUD0eOIWUz`U#fG{8d$N^OP;XL31
zgafC5TtKZq>KpI?B7jpsHc$ezL?br`CIZ1g1dsw`10_Jqfw&G#1cHGGAO*+<$YGWi
zU<srHIY0?uGZ^*<gaK(lA)tl^7ybeE)V~%l2Al;H0og+k2jHV~u>c&YlL4ZEQ$P+-
z1gN7UvjALxP#^}NXM^$pHFQXZfE^GF!~p3)9-xAaT6%yD-~lWH;(>G^2aq2D8wD%@
zH$V(*01|+7AO|P`T3RCy;Qw{sHo@&`@xp)@AQ{L2a)3fW34M|_FaU4_f`Kp~28bR7
zJpggFp;tgl4s`_tqZ5t*l7TFs08l}{WscumT>z<1oFv@i$@;}1KQV=K&>wVyjm$;g
zAP@Zm(M71&ROng^JHzLieC6E2^~`+4McU*uC*d??00*P9rT1Rv-b4N2I{D7=K$!3K
zpJS_ldPe8{Jw9}j7Qi+XVb_2;khKtP1?+Yo_71Memrf4KNxpO<Aa7Ovbe<^TI`mZ8
zpH5L{=nUuSecbAcVc&qyd3jzKa0++=$iugeE?^0`0Kq^Q@ZWU6j4C|;uZt5&E%6*V
zCN%*xvEhzKI5!n21wI4P;|qOmh1aM9wE;QcgvyUUKTqk!Ag%wzGxRSY&$piYr)Ozj
z18)F2iZFqcM_K9sbpe`iDu8JZup;<0zSjfS2gvV$6;Pdj0`f`lzv)w<9%PmEgYe(t
zQ=kEKrvx+vx&iut0bm5s`{K=jo<J|44?z0uOP|60!2^In0KHd!C}0JQ0IUHzl);Sv
z6`%#60sIEE1X=;Dfi?giXbbE>x|(2mw_ZE27SJB(0CWU80iA&^03E8}#=u<E?|fh(
z5DF{>RsgGja9|y<0oVj2Ange7A3!ufhitqiNKXxD3N!<n1GG<`4zj(b29mw-eOgQQ
zs$avoEZ{oehCa*_m=Dx#40{FY0rdeo7UTRTfDT`905F65J{Eb{arw~on@H~#a2q%b
zWCQnr`@jPr2Y3iP2A%*<foA|cZ~h#d3%mec0<VBP;59&d<LPJzrv32JgZ98TF+kaY
z-Y8pNpdZkmW45Omp9cU1xam{CSfYxs^t?qcoTFzR6mc#e*Zu|?;XFNWV~+E6a6Yy<
zWWo7Y0KMx&1?R}81=*4c!l(j`aIPUxAE*l`14@8AP!C9iehvT!fn?wr(&FL#b$q@7
z+yd?Z|KNOWoPPuEjr6~O3jwmPBS0-&yFy`*ryM?$3<n@fBCrGS1iS(1u@j$<LFT0Z
zJ)ca+Xq+1Zi~}YB(qlJ1@0Iy}6rYa)C%ALu&*Tz5UjWu4-)H!q%cXe==Nte>z!`7_
z=r|2N%YDuSUjeRi-z)q4ApaUWn&3A8KzbzL^8uOfNAdXt_x&t5o%?(Ne3ARC44E2n
za$Ui>Ebjbm@LlfnBk)u1b1ldt$H_$bD&cb@neRX1^Fs~sn##oe-}3eG8usx9prbwH
zv4hQw2POa=@m-sfQ5W15=mzYA{zpJ3Hk@8;!DG13<G~ZT&rV<=_qjIoEYInh@|uhD
zA>1_uoF|_Xbo4~}y#P8qaNUawL*GUC9LRldfbb2uI7@ME8FxMmEcF*cK0%~DL#Qv3
z^&3KCtJHT$9Lg$-o%p^B*bT%3^voR{x_~7h0^)#VAPrEeg)##v01tB;6`&=c4HyCz
zz(jz2***abF`u>otbll+1klEmjpoK;fZlJ~67yOcz!C5PHUKd|0>GYK!dzDc-~)Pq
z1z-a>0!o;V+5nD#2M`2=0*aVNO8t+x;B!2X0%QQ$KrT=Sgf&1v1LOkae}s?usT<8v
zfe;`JhzCvq=>W}N3jn2t7)Jo|J7NQb02#n7AQvbE1}LMhfCwNC$OCj6q3nPqPzV^J
zZX5w0AQ&KDFHZn^GcfreaRht-F%Sks14^jh0RY*e3qZC~g8o=n9sM(435bC-APdL=
z3V;%T-vZ$PF+l!B@&NKJ;sek^QWy{o#9+Qgb2joLLjFTi02;py0Smwe@Bo5=P#_CX
zMBCy6w!ktV0*C_)+aPTq42S^SG{HbTkPKu2hV76pKz>E+01*%d!~h9E3UCW}0??wH
z5}*zk0ye-YAR8zGlH2222iO^42-pBAKst~G<NzgrdPnF2FaZVtj(`Uc3WNjE0Qo1m
z1=wig8W0N5{oN@b6CnR2MSz_S>H_cqf`L#V1~>&|0R=z_pxznc0~Wv&V1O>t0~`Sl
zAP5Kt;(#<D2hi1nK7bG)42S`efLp*5fP9)50%9N?XxSa-fQf(`unaf_WCF<s(48T|
z0NOwjPy#3!AugcS17!sq0S_Pu2nV8p6yO$62+#tn5}*wX033l}U;_{XBmfyeE>H-N
z9~E6-q8ZWx5`b)g-xKEm4<Hy=21EeKKo*b-lmLq6&>f%$SOOD)U?2>L2GW2`AP?a6
zLOB3!zyz=Z$VW>k5CJ3rr+_Cw0Z;-c^@dIWE5H#52Eu_jAPvX{@_-^hz7NU+@PPq<
z2oM9yfDJ$#kO}ZCAP1lY*a03u5D*Ha0NFqupwbt410vuQPy__`N8JDg04-Wu06st*
za0|!<iU7rdh(8E*2803|0K>tM2S@=jfLuV&64!wZKn%bef;d1Zpfn6w0JcClK<iLR
zK#CP~11JqgzCaP6I0EGXJOEltx&@e9qwGL3kPeV<<N_PyITG~*cmUd?paUQT2nXCo
zLlz(oP`5>$0(L+=kPYMk9%CQ}kOtU|g{;5^ARAB`2b}>*cF+xA1B3#}KrT=On2bjn
zzy=@=pmm&<lMohg1VVshAQvbC$oEYKK)!C&9HB!X4afp~1PBY{0!4t95OoQJ0%@+$
z6QDf>c>)E1wi`YJ8Pj0@fR+d91;_>zJyB*L9Z>RuOh8-^t^s*~_Dt9U5CRkdwC-dD
zOa$Bj5g-N}gP|`V1yGy~nE@?853mv=3=jsm%|{yn5`ZUw`U2zu6oh~mLQWuj5%LCT
z?L`|XSpu6_3Y!2_mO+m|Fc7*NwhiO}>MKw$KnM^HqyZ&>(n`n@2Au(7AaoUU2c!e)
zt5Mg09pD1^0Kq^g5Dr8G@jx<=24n)+KrT=S@YX<XASWCQ=&eOrfsU$@=QP`a>7GZE
zV_h)a({$jj8-VFPhR<E6wG4U|x-It|Is7_)Y2cRzere#B27YPamj-@m;Fkt|Y2cRz
zere#B27YPan;MWu2-knX|DV856yWo<2S9<}l<5wE?jA1A0zVgj<_QqL=km-|YdPW`
z8D5Gscu#y3%XqlEv!A!Wx2uS+J*pGm+DGK>={^&F`S|_4J$>9ggnrmsucg|juU?Rm
ztC6#biK#vnOyb9Hy0e2o1TTJ00V1J4{AX#Yx(PjegnqJT$q${DszBs{e5Jns{6zwh
z(7{vSC72@g6ncrspOuzsnIuS`;*1+*#m<lO6Zjxee`&s!0xuU2p{<|5UBu3j|G)u4
zk-*)<pZN)tex@|wCGi`+1Ha$D;8f1{oJ(zz1nVb&GSCKa=?dK*tjDW`B^VEZr<04o
z!K8=2z!mB;aqZDV-`T{thpUN+i@?O#(Ad<-#98Rl+ssTF)ZJ^k_cW-@*+uB=fmOqr
z{8jNepM(-WVdR6{x|W9<DS~{OnSdqd{Mb42B_)-+r5vSPQSNDwn|G*!+yZ@Pp`o*h
zKxo+AP+#BG#n4#K+1OaWhk>cSp{tRe@PAD19h}cG`n`vaJy5PXI1Wrcy!9k<J2(i)
zpQN+5*K{E`(Al4SOFB6Fm^;J!mTn;Zbr9)Fb#3fy>LL^vI~h6)jJul{xpa4SaWXR0
z7Z{*&dUQ87>a8pBPZ{X$WzgNhDZteg6(jW(>EJTMOW+B2dVWIqokJ_3$|C<>SiY<3
zV0EQ~dhx+k#l}=uUI88+4)8qb3EzYwp$n3RlQMG8$9!Ru?>;Q+@p_?r<VUbv2J%lQ
z@$)x}U2~o;a&Qgsa+aJAMVv!emx3=!xVLlgLBoQ7I*C2d@51C~(l@}}4;hlfJO>|-
z0Dp%HqImmJ0Vs|ISQ3X+2Te*ei>Ot{BENZj*j5obw04NQNK!9MUOjwA^G5yx4>)0T
z5c>J?$R?$6bWyhy$KWutK^DibnmEclQ`LH0IQng$zVDX#PU%W*hTi=~$8OGMc7Rtv
zZ#Ky+pXzN!YA(!nq&DMXVq|I{=x*$yFA$hG>veY$8lWreA<#E=G3ajSZ1|tE8Nc61
zcNHqCTAQg`gUu}cFSHq3)V(h1iRyocq+Y&hGZe>>i!<`b_t{KGE}Yb6{*w7F=^yDA
zRIC##(qHxy3O(BZpO|=84fN)7RMuvwZxMO3ZU$Y<&-4}4CaO5f`U(qN{NBF85@D<B
zD{OGBa-Tr`3m@lCGkYj63r^vA21Qjm&oz$ni|9+u%p4p%x|few-|R(^o~&-o>r)OD
zb^9ms%B-MU>bs#^uKWH^>Gpfu6zR6QHdT{u|7N-^FAJ5MbW7(s-IiahLbu=SZIB-6
zb|^O=32jI@U_3<sONLB)CahZH`!Qy>&fcD$-d+yEARo+|94gKZ*$^om!*W?FU;Sae
zacOQ*fJ>gOSYM7QrexeH!Z}OiMdOQqfCqK;nCD4+d7f^<g$<xNo`XAGq-%~~pSpC7
zI$41;219m{eCQ_Nnq=&Opptmba0kuOrR&MK9?8-zkL&90=Pym$0@ueg871XKXGtZ-
z7%drtsjrdESDH9oPsg>g@=5ZRCe7l9;d*0TiqF#ahl6Tven7gAQ?-DNmo#ASkLLB2
z=$`dwR)|OPS=VwH806zeuAa-rK#EhSg#CHAu9za}&!qD>iT;?{So%DKqx~c)2y4iN
zr8z+yzDsl>o%Q24Eu7cG`67uea(4p`WlE#@BFU_a^pb%7_%7tqq&l*}ciJ0=aT{}Q
z*bPnD1N_V6rg(Y4AcWf`6VJ9R9%pYd@yKQgQeA1mZbu?~v*YFEcEfksa?6INeKWOb
zJU>w$-mX%3N}JyCLoX;lgKMK?!k)r+ZeGJoN-7WW2(B&Bei}L)xVg+=Fzr$CIrZ(f
z#7!NjIk7omHSMWyBCeA^<Xd3!hb(PdyQ^qh)>X7EG2+oXo=`W^Hd5BMNFTn{v@Noe
zn%Y(Zu4ghC%FM(;+5pHVOmMxrwng<;Q`<U)>t*GuqHTrZ`kl^HrmEZ4GSsJCBT3s@
zBdH74wgw<xb#05{*q}b^z-A_-mfMUT;z;yY-nJ$pZ7YP$!nH+QSZZ6*_%6{&#kQ4+
z^Z$IKZG|FD6{JaR>oS)n>CqD3Yie5*kM^un+fq9%k(=UKmBp*MZBe<!h)-=x%*7`g
zbHsPqa!cD5h0j5FIp`_)Ou3$HDut)E6@qZtKpL(ck_nrP@84=$eBA%g5kqYl90e|c
z4hzn5ZOdnd0~?}TSf?$q5=;jq_h4m16>D2TETymhu(3*dpCp+>xnd2&0XJ<zW-nxC
zlJhRO8FChR`^_lp+a>asop<mMdQB0*uqnL_h*wva>{B8Q<xFD+)ukj}Sw6U5k_=dM
z-2~S&DvpC?3D9+mviN29XVU1buax#n(!HZ}?@PMd2Cmf&AJV@|cV%5uO@6tlUy|xh
zGDj*aQ<?50=gV~T-MYKP+ICsdzgu^|v;MEFpDRn?dvqs#CxT5g6by$7`f?-iM>*_a
zhwk|2neMp8RF;Rdq5DfMj&$aTIA0$sWqr8~u2Wx5`t!kO$#^VHQ=-?Pvh&g`IDO-M
zW!vh2bo7v6H^^yS%iZ6hOyv&#LLbbUV7VlZbgm$oPf7YS(oH6=P2~C~tOt}=B+gS`
zLJL*2$K1LW-u&P)2yJA5KqMH)u8~dO?IOMA;Kr8QaBdXluq02l3afmR;Or_88VU4-
zJ%p|TQxl;c-9GCXI2$?(olRVg4TTsfDb2w@lIAy8rzCS9G+VA+dV9$9CS`4l=10_r
zNZPKKFp#E+Rm?ZVWns!IpuAs@Q*}h!)`fj(L!X5gBz-5@fCb`7Y@l5AR4>suufgi2
ze2kSEHPwp^u5)7pdO>dTgmcta(|X4|E{`G58GYBkD9O_b-zkjrp1`sNBH>WuY`z#a
zHUeQRE`P)3%X$jQ9Og&uUNTlnby;rrmB&!l&p@Wi{esl)y&>!O*u7+~^L=(twnpiG
zzx_HJ8VXE%xat`S^$bi6jP&$+bjLqa13l9odZtc>u-|{BEzSE8S-!cN{6A~=^nOY$
z*cjQp`jv`yFRAOV?OxI!{hZxz&y?gLwfiwwE86`cZmrl>Lt^*+Kr~MF0v15ej#(_c
zWJ!TUa1gQI4<voOnVHDh-^&^E4@sxb*Wq{24e;`JpW-ES;XBasZx2IVidN+nK2}Km
zMf?u1hw9(;z%QGdP`|#3jcev;DE<z5h)3;#<_bE^$?hfR^||vFmBM%D&Qm{aC==cQ
z=cx}^!Rf*cYln2m>S7UeajH69NZY=wI=FLHmRq{EUggDdrF^eW=s7ZJ*}q38vf;m_
zlTDmX=o!JvI{6(s;a~qT`}oQ_q{Wq3iNqju%1&0cCFup!*!SB^hiddAYXh=2bAsK=
zNo?s``dQ8CCmM0+khPhm(2w|E)zANeUaD(LKcbhdoL<tQ`^tJ*4!z`5r<WSrQuWp&
zZEineK;PTGy8NL1Z0u0p9=~Nj()N{0KZfFvwV##Hlf{i{+SiZisjSEOpVUuvcJw3q
zagw$#K2r}5D&e8)=IH>d@g=%C{m`I;UtBRh`8fGaW5X5eZrNZY(Smk|PWA?qdb6>I
z#*nWMy|S^#0vD?qduS{PgB;TSm--PJOT0L_UD`@gm6dxPzT{LVcZGUoqDxJi##ZU)
ziUmLxWXs=E2HCz}I#y5_)>Ki3`CJ+FG$m!AE{=YVprPOb?sNDzWo$FR%iT9X$ldff
zh`1kk=q8CxXe6@+RET6I@qM9@50wj4#UYs&(0!aDuBNj4E|HtNKh5t|RVflZS883$
zjn&6~t}HFvNs_V!(a+<ffm*n)u#qi`?9a!{a(?WmZD}F@#bjzMyFTQWmi@U**~#{f
za%EM~LLeNnWi>-tPgPr1&b<B&#r>(2AZtzaEnDW!>|Rh(-&AH-ZXG&-D>H?q`lUHz
zKGsn5ZZTVR6nJ@i&G7UN@aNOgmcNg{S%|kdO7FWIJly?7(y46~Cu^235qU}L<RM$P
zDVNWSlh3X_0^yLA?;yhZ{D6F%Zqb-3iYPr#>DQ!3SvhxBl2h8|)i8$9LH7dn0Nk$g
zF2c?dBy#>pD>gHm^CQ6}vTGy1uaELJPxUI>=E(*Qadt1?Q4*87Em}IIeya}bB~w=R
zf3b0v73yD1ha~-0-%U1UfpFEe^P(!sYmV~rZp-w~73BP>)>(Cte=4c(FLQP6Je@NT
z0g6fXIT4V<I<uan%s<l3=TvM(Y~oNuos`?41@e?_=d{jWg1Sh9Y<+RfR3Z!O6ZrUE
z`S&@=JfV>)F7cu}(O(`<wmcbVn+ZQq9%=hWMO7@4^a9ea-qtFXOSWI2a%G@Q5s;C}
zb)-_cD*rY@<yyq`caAhs!_g3+{un=f^87K^(7VHIQ@T;;o2xWtX5QG!NUOJeEGqD|
z(WB6wKb=n6)4knYxZ6S<UD+>8qu<*P`m*^?d4DaHpN~4ALsotxgte$B|2J1x|I_m8
zSCW6Sbnb>WLC0W#=FN0}u@QZPO-1>?xh<t!e(f^7Rz2S=-)Cuoyw=N%)3jD&iF1|r
z*3dpb8=U{1y*reK9l}c1%A_m6<@+Nf>(Y|*Y{wqLl08o5?6H8;2g%+DFb4dfyM&7R
z_yKz?*9VfS;waaLBCg8X8TIQlPp!NcmB!r4dr_tGCtwVwLstIoke_$ALVNlFd;Br^
zW$o-|<hP@73CBP{8L$AxKz^Hw@;iTP1-UAFB)xrol<S|5i?+zix>osp0=l&d?+lje
zncZmO+5mvsejlJQ*-0fizx7Ma&&sJ<g`D!3%+Nd2CH5@Yd#6GZAsk}?YTqM)E6}k@
zb_IL*=GLgH<fOLx^--=*YO@)Y+P59fRn@*7asGSuk5T(}Ls-dgKo#4!56)NDzDIHW
z9r@~@BO1U@IK0gO`S%b@^ucW-n<5lB1c+Qsumjo$KRbK+2t@8q?jG)<8TjUc-wCk`
zSTa_UEMFfI9nfzW)DHJ!qKUoa-p&I2Vjke*g6+u|XH`|{R)o_<fS(_2<tpD}OxN4u
z`c{no*0losg$~|APnqjf$1}MyZP1rUK>Dr+3<H`%?>6_Uo8QqK=7(?Mu)CYK8k6)j
z&l5<T>gJ?#IGJs_BM=T*nMXn9Q`O4+Qxi$tYF7}u#`%q`+?D5*(>b{f4J2~U1}OtU
zKy%2gcmLn1>vBccG#`_dS9b1CwnJ@`mNF#!(}n)DBVO`GcS+swaZSXo)6Q|p7$~(T
z@=HTU7(iuQ3XDM+GpjA*Pu5L&F@LIFezu&_xla*S&T%Lo-M@|kTB4j`52~rl>K|9Y
zt@ih~4eG-zke3$v9qcu8alsZ(e|)DlL-i)<!z8suVX2Lr#yk`I935P}{XDVFvFx5f
zvWDd+q`IU&VFEXgIYk>XaJT|ghjiaiN^{j5R<<9x|B-A|MAVvWF%j3LZNB0?kEBeJ
z{#xk4J(k3N-{m8Y<Tv@R_gzWH*=0Qt2#0Jr&Y~RRA1H_P_6C*2_FPhW-&>Z7_c@ZX
zNamK`UlwVd@M$uMgX*IWK=X!ws7@aKaGf{_r?`6|CMyT=*GKvNnj$W~XZBNm|00zs
zsS26W5SIS~GL`FBBG&ibQyr@$leCX@p+OTzBY^Zo`fAb@b3utrlEtD5>lHsUo;eG!
zxQ7wFW*tiVSkj>~WRT7cWyfE2Q(VL$EAI$|b*xt2pX@KoMXs^lWn~^zN#+UMI2O;z
zOhj`A>I!N7PAn_)_pQR4nK^rS`(si-^{$O{zCOxrQ4beWk&mn%`*AXvn@M7lEF=@A
zxV#*M&6Jg?(k}+m%)iy1rG2hkUCO&`>lJLvRQ0|jecowRNgwLR$&<^;BU`U3&?o;<
zHRHoi{T6`fAUfxo+Kg;{%8v77gVHv$p{GQ5va$|^tQOVE`ja*&5%;_0tvrvCj=khR
zjt*LbRR(AcwiV=ctWMsV#$K5zUQISA)g#%UWZd)-(cFh@gSwo`W2|f&FX7~EfN<0&
z(eGT%Aa7W8^8TDH2%Q3^pro$eNdCKZTwT9JKKAI4m3cH|j;>bbpS6i{vA@@jEB8xd
zxp|8PejlYn){be6OpwU@Bl8wKT~V_R6Oj+iS!x;|v#OAX#>dPbkf(fnWFpmAud*^#
z9v`K@VX0V<hOl3}mZYD&39gU1WWf)}#8$D*%(#h{yQ_nj&>6E(0k&;3`P?K~RQg-q
zkNe<C#d)5b>MiJs{4TD;wRVqLAIau<cK9xt)4F@Pi`)esxR0fs+|<5k?U>>zS)eQ^
z#|bVTwMomec(jjH5=Yur*P_F~^P6mcsh?m5Yr{x_%ZK)+mghnFNT1cV>5D)(WOa89
z^=b3;`{!UX^(lGwtD^e8TYnYjmU60U7VxnLkp31(<oPcBQ9LV@i}cs}nMCj3(qH-y
z>Q6dvc*5yV88S-eu-7q0Cp?!K6Tf%ffMpgW^WE(stJ1uo2iIqaY0(--e}LqoCVRUZ
z+NeY(TFfcmG>L1~&lPxOJ^(BbPBPZI;O1E}Mvy&9=KlWP0e;Sy@s!_(N$z9t>^RPm
zy-8(LBB5}o05oP$zxDvK>E$wgRVf>SRCO@fs9veRx`#Am?+58T<xyEal4S%ppAmDi
zP<%QRfQQhjjYJm7y!xy86^RHx3IY#z7ka`jfYz>R-g7~DcIE0uo)$=PR4%_`dHDm~
zU1~~GQYSxCZmA3#I2mN^<0<qfu0jUx)<Yt6`QHk5A(_)uv<u1oZ4GvT$p`7hjMIzO
zKuO}V^PfD(lp~SJ$4@xj9lH?9A1p-h>gP7RvS&&45Kg*3o}S($y-}GY=bR<$jQB1q
zOA;rG8qSlA(ppFXWKns+Y_wWg5Ui@BY)=%~nPeY%`MO0#JFO^>bZyXMkR(}JQ>Xg?
znugPQrk+Hef7AV+KkOP0L6Hjp$uzJA{g$t3lYT4D!KHF*(T`|2WaXwcO>wny|KxnD
zlIYdjMMb$Q&&A8`b2zzMKz6Esb)Yfi&a77MpSj<btY_8KcSz^wWH+)pmfB1^oR^IG
zlC;Q%rT0Gxmbi#RwhY5jhJtF#@Uyyymk;Fgz2%VAc}?XgoBs}B#X$O!@s;k2K45;L
z@{+a1ADRC$CDkOS>|C?D^`WdP<T(j>EPg<q^7+!YZ9rD0%Jbi@+&E@8RH7r<zVjdS
zS3VM%;PQp`Mb^|`O4<e0M|pqgFq(4}Q`Tones6Z@@9ib>^TwL1WL%T{u9jVe44)xG
zv_uB@A^0&FxPJ008J1z-#5i9;hM}Auf`)yq2ink<DUpHuEsLAtdkOsfyxG%OGES^&
z(vf7`rTZh&QQ7nR)64IdEBhxP{YYh_cjwU|TSv7ip;z2Ik@*(lWTP2CB?k%=xB7mq
zqHJZ)Kg-Bg`T1^=tq^I_JA8zg2=L`zYsc*r7EUg1ZrJHw^0oy%bB--*5jXR|nEA2#
zz2_ya$%O2f>+<DHzAQa*BKV)k83Nt?gG;^`2fvKzI?gq7;Vf}LT+4tB*?2b*ORsI?
zR)_yGsr!D`wSLOH9c#3myY*BqHS%29K&PYD!n;didA#$uALq-tT@6{z+iRfRZND(I
z(LC382eTb7&g^hksAaP~Y50JARlHk=<-5LB3xz?Z7kV@qmZUKKLbrLrqc3Dm5-lAy
zXyv#T-H&CUT^_|mmoK+C)w%x3*=et51ieeU8(*mYA?1_RkwK3FFZkI6Hprr>F|D=m
z<-)r(5WkwO?)Ac`B)6{B#fvY^h8)<OA@_ci;^8xMwAbUlZzRh%(^uvB#|@kEKjz<@
z?O<o!`&pxRm+VqBjEDO))lg5`fqUv`R$jR=Gr!2)XtO&dCVl%}t(|WKR&76dEgU+<
zY|*v;o@NUU;e9zQy#?wDu7Sl{r#}gQeP+|H)HcUApKH1G+O$JUvoo$b=Di4n-*C*&
z_;Q-9BK?lXtBvs3)ahbegO&TYf4p%jb;*gh6V^=nvu!7(Jgj4&bLY!-dAxj8s-}y#
za_9Dfkc8{@$+rg@8y#P6ro3{MyJx`#wENn_DV+J@yDMI0Kl)8|M@qc`*B?ApzPR+f
zV$VMILfek5=Qj8g&-q)h^qvF>rt1tFxz#OV$;KH=H0HP&jPcJgUpU8hq+i0?v+131
zZ-pNp_;N9wF5lQRVC1WW(fzD<KkGV6{nm=0O=hR8Pp!IYFwi9s_A-l=ceB^=xrYyQ
zd;W5o`E&2!4zI&q=eN`n6#M$jJpCx#Lt!GuSXSOqk(Yea*4><?GHl^u58<sF&sxoV
z-Q|yAE~&NDR+WzRR^jpHU~Qf+7u-h}wc)^9(GvY(H~QAK>s8BTjX_S|&93b_Te}=6
zvRA_UlTgWgxwxDUyp}=3%x-^9vJ%{$W_Q-#HO+s4ZruKtlXC0=lYH=wuO1YxWm4wM
zwky)iXBZ{vCkh6YH0sqUtLK%~Z##{z)5<Ar`8d=E^2R&g->R32UG9FdA9}peK<{(Q
z*881wUO%$;eCP3}uC3dyU4r_+ypb=rw#$Xqp&vR9w|=?nn5C(zXTv#5d`DZ2oE^F1
zw$32=x!ZZX;jFyvuS7&`T)oQZ`P&1_0-JBRTUcxF9G=bcD6?^fch(#2fW7Qs?PHly
zWS1|$54ZL1ed+4waOVdx^M`#om;Pt#i!1XBy3X0#mdBgU(koJNygH}VW=GeIf+3%D
z8+@vLd+x2_PA5u&<uoImpB_I0fAY-k2mifZr?Kke?eX0cSMJrAKRjV^_UyAxS4O?a
z*uA;a+`R?x`@z!d+O^|I`_F^4jNWVVHJ|Rw4%yzQUZ2H#9?eePcm5?`_b~S4GP{a6
zabZQ>XH#eBoJ+LT?|bi=<B_xNCTm$KovVNTT0HNrGv1|TKzb<_%?PX4a+%kNTS=Fb
zl&_4~b1h(S(;f-~|A@T*v8BuFFW75>HCxoLsPO}vZiil)Dy_TuS5cj<TU8x5uT3sZ
z64kNz`1|d&OL+d3r8j4lnSn+A8iVn%e_TEr=bzrAc=N)@G3`Ijw!HPn)vd+Im+o`;
za^A~#-gVnzJ$TOi26gIP{q60*qqEza<P2Y~(0b_Neh&IO@P0E)sQGdo!$ySFGZ95J
zj=A!@@4o9UEtZViI#?_9-ZhVFdYW1fI$-Ysldsrp@0;$!Ch;!SpZc(Q?d&tD_l5t|
zS2@2c$za<0YkLaU;5|*u4&sZ>jPVkgy%_R(Z2rD}cKhdFj_ZEyNDsX!iQ~78OT4lP
z?~Y^rmEyfG3-iQpJ2!PRK6c4^UAXvj^kW^xJNJWAr(U|CxcUm#a4-So%SAXvN4UQ}
z^JYnHzuzsJFB-S2#h<$l+bd|tyU!f&xkQk_<Ne9%xBIv~OWvE?)jKhKQuEi1N|z29
z*s4#*)Kbyh(#JWmaZMK>Jxs{?a;7T^i#pD1eb??u%gOT%a<iX{25KH%u^}>S#F~v7
z?X7(A8;B`|^Sh~H6%sN?-hcFS;r6}{#hnML{24oB;q%+;_2dg3yT#+TRQ$Hemuu~B
z)v81L=PhDvXL?z?%nV&F9<KZOeZJYkbp00nT1C9Yy&P-5FIvscAFg>mWQD#;%vp!-
z4_7Tu7Y<(2|M#hRn+}c6ABna`@4bb+1kJwY`LX>-n}hPku0f%5`<~6byGNy@y~4oW
zvtIVAC&s=G7H-d!0~$S7T{^k4(T;@F*|vQ`U%a207JISbnPD4`UVi#|CB_dHuI`21
zW;RXgmfmhY6>m_nKhibk<|6Y_SLZPzqmGw1zCMTNRam${%P|{!CN>P;aC!Nrh`n9Z
z{ED>~8H;bIEzG_1=LFrUE?DDc<=ybunExqn<^5ZVyTjkACL2s@u(eck(DpsM&35bN
zjFG#I`<_8mjx7yN4w`ac*Bz7k)5H%J_K7;4ZGLXm`Ee$jdrleuw#8HQyZc#s{6A)t
z9y?IaSEM|C|D7%#iyj3lM`m`;k4S0j?|odW!yfEAVCls^<T>@{$K^CO2|LSMdO>qu
zYDe?fOZJIZ*MC}EdSXU2-jm4M$NaAMBcDy3Wn!Kge@XsQ^ICb9Pa->wI<i1BQorH6
zc5;od?!wAjvS8=zds}usUNE!%(I#!$2dK=<d#!u#QRDa{MW42BH=TvK4olCnol~}A
zZ8_h3r8ZISCebB%ey2uh4?bXAx8KVnrQV-?B)&xWa(0Uh7oUn%JzxLt#+Qqqd^xvc
z$CSG5CLY-`dClz`>)!dmMrrYbFIQmRGhW}_UTySQEyWit-@F=iXkpex`PzrR6!*Op
zxvp~;_(a2ejxV=j@5f^;7QPS3)w6XT(%-OT%&zO68=n5*Kd7U5UVM?p1U!qw<hz$t
z6q6KtprQ5K@uq#>ub$!PG5yeOyH{3vd4Fa{w~E5zP8jR2zTHn2VlKg#Q&Jq%CuKsr
zxJ6yZx&P5k@1EMlUP&?a<err5G}Rdw-eoV|xyRCb{!d}^zcU{^C>=Sk=S6$1yr*{;
z_Ob|lc%fO#{d0BG)Rw^43zIL-yjxV`=Q|thyq)Iqlvg}U$+$(zheM6(E$$KO_uJ7+
z=wDv3^qj<_M-Dmn+tjg%Z|j}t(MBuFFm^{q>hG;pGj*o*5<kJF3<cbu^5woAuEhun
zH+hw~Wq$L-fNkqD#(q(pp|BvU<Zk-)ZqJX21R4MI*t8JO^sw{_!(F$j2V5KKHL>>J
zwQl`3Gw9vKBZL3G@$99q&VjK>x-0O$NDE5udXM5><5Tn7u2ND{IAtF_I^O)5(eou?
zkId^`543w<oQb{VZ2TS8uxF~t%iYWWx@U1RvEKX7F&D0$-?#dPnbn8-E3%7~(dYhV
zNa<bBSR&lkcU_pC*5%{`{VuORoG?<Es4~x_<b#i&rP1K`u$RUZZuPN|tFw)kwG7UT
zl(RGyq*>~nC|$qn)ST2EGj44y-nkwAQCa&qw70R#xCfSB43<q_EO^`fxnGgdy5}uw
zC1mM%98udm2J`R$R^H%wCP}?(FV@N_RqOdE!s5RDSetD*MgC)5bpr41QJ;c5jhK9`
zcW!;G<Na>Ko*D82r9V})&+kn1Gu<>UVrTuv4S&<fL%3_Ke;#EK=p6fT^o?dhexHv4
zms>=2u}M7IdcdbkR%XW2?#wv|dtv!5HC~<W)bwMI{-0Hc$7RjkawQ<|=G6gRTk|?E
zT@!NC6n(QBD~DQ^Fz!R`ccxahV?NAnynbxSDEkh3BJ?(1`*6Ge`C=Odtnae%BSajc
zcIVx^=?<+O7SFmCA6Pp}eZlgmt)e=u&+Z7?yzn@D60vgZ^3vcpJ)PF4!1K$Ul})zQ
z*{&GA@~`;S^NzNk)_z{6{!y4evwSc26_%XpzkEzrk1h-3|2Wt{LtJ=a&a8BwyGuH~
zSf97^6@HUs<3hf-f%=6TkqKKH6u)*XP-y72IdP!!z!MK=9E}Zo*2)OuhY=fRmX>M+
zW#}EcW*++ZgT|wH7q?3}j{c+am)D!N-PnG(MN5p+OfSNWO!v=*MlE9V>Tbx`H^Eyj
z^zA<N25UFZ_YLd3!8~Cj_AImc(DCgGSFF2Q)b3?yb)^4=+e_Yg=EltJ*~lT@eK^0p
zuLj1MCTu+4-cb4d<rkjLL;L1$S}%%F^A#2eJs!NC^uFh5t0i}7#nzFfw^H=T_IJnd
zZJ{IF14^|H3^5rr(n44`yMyb4(HCD1On!;_W%Jl2=Wgyg`q|!Wvfba?eEckKAG)(V
zMj<F=)wuJ^qAx3^%42@Y(rYkipK#gBoQ&%qMz3&<Z#uWj31?G<pbOzU<JC=tZnjB0
z-V`=Y&-Oi>GxD#qT`#RmeZKPf#$zRN&-e2${GJ;+D|n0Y+Zd$xH>=-Cg3LqyBMKJi
z>eaR6<!1iYr}5QDt@Om>3J3BYAJ$o;hvx%Wf0}>&h<|Zn--0XIeNx`Nxa67sagKII
zv$hep>lGcfE7^Sm-7c#S`8r04n;bigaCo-9O>m<5Nv#vjcjxa~a<T0b>q)aeFUJjP
zcQ(&Cr`%-D+@gi^KX$eGEDEz8=Wo+RGb*Uvh&Z!j9YR0kqW?2xdUk4AdsJMU{yd}A
zX*(yYn{}P}baL_WSxas$+BZAYw`8~t?27dVZCaaLp1C`}-?4XcC-NIa+&9(i&vO}Y
z{Oaq$V?B**`xW8c(@egdmlaQhC~R4$(pT&Ho=18s_#*~iYv1{z&eevE+8T%Sa>DyE
zn^J#p`&FiMfmW|8nt29c%>-BWHXl8H&#_uj4d*!=sr~Fj^C#Gg$jb3$bN-5_hj-0;
z`EgV0-O6i@>rJnfJG-YiwvX0^5fN)!3V6J~SiUbt^*ukuY2oM7S9bdry*wGd??Fbu
zQtPa<+V|b<=i80Pe4JiB$(K9xepJD`>AXD~HL{WqL~6<(vL9Mf(AY@6pm$KyK?Mb<
z3kB9bF2_A~@;s{QwsHNfk{kAuiVIWTEYFF&`6PGV^hnDq!mX%ZmhX^6?F~ttFOPm&
zR2=Z^uEwN3#WSN!N7y_t7@0GF_|T=$oes;_?7X>tRINQ~+fzrpUjFw!rM&?wMiiDr
zU7miUc~=ePe`aI9uq(+oC+_xUr7>&IUQ8VCGJaN^gYzR{z@78YT?fuz>?_nBWQ~1x
ztRJ6xbo$F<c}{cg+}*yrliu(@x)r{P+#)QUx3k{Fg>5V*)WUm!S-X7RBgVI6PSNMn
zm$Fy4%gCRQ^l`%HCWG7$>>FA<`RRO5v<+L9Uc|>25C1wiG1#c};x7|6Ja#(t<?hIq
z2K9DF6i#zWxN`~RP+|2kPw{h~dK(>US@*cI|4zRN3+BJLWqRK*@KxQn^RzeBU6_t`
z#M0YXI`7k<zBcdOozEQGw`=XEo(qCCTlO=4_IP95WZugt=y(Lv%gg64R3DA6ov-mB
zByPNZ`|Xy>9%g#^#Zg^`)a#_07#fK8Y$0#H+(3oxIcbHhTEsPM+J8YGjmWT$v(8K(
z@LR{AkYn;a9}UC!(My%W9hnk8bLfJRQ|!;R*|NyK#flSV<6Mk%O@)CQGxBZUHhY10
z9<%z@JXAL!rk>N<j-AgxD={*+ZW^WZ;I9S_8k>AOcl%;<5OsUoh|<g9oqnF*X-$ha
zZQKT)6I}XaJx}dU?)B&sx;jxFf*1WW@oq6z-esw3c^mCtEtzE9XoPF0?u)i9boD8U
zS{NG9ZQjNrxl0jv#(|}0w|acT6FWV_noqltG9}z<?WZ{_rtE0`_>bGgK^dh+Pa5Lg
zz^p%bT2%X;cFdD~clIlW4}W1k%<O6As8?-byR3A)qtNc`>su%<8@CkBsv6zNJ?<1{
z%S-xrrN7&&YX^VJ9COrYSX!WM$*#=t*b~n5yySAupWDoaPk7Y6kMEREot6ETzg$$*
z{r5{Rt}jTlZ*K2}c^I?5*8T7FdcW`G`qkbi^F3DBDL-E7J?r<|*QRA&-C@=^=pXcb
zDJ;DYnX5y@^ED%<@QVl8nXR=Szf@GHIn+AFU~H*qVTbFT@!nq+Zou*14yr%bJK7*;
zVByfgMvMMX{CIt6^2AQ_eF7C5mwXXp-!2Om;FAAg(ig=yO&s(_t3BToeIazojGesM
zwgK(>{WW`XH0-pA3Dw7lC(ZU>9Wn6o*=rM@9<VexG|aGclj+)E*PCPNeYlqV$q(ZZ
z>z@ZIoE#D@Z>*Hld`d>twUULG9(S8@F*Gc}<NEI9b&d>B#C|L`PrUB8s_B?#F3n$x
z4k_G@o%ZILMbw;Wi{G9OzW8d;{vi=+`0cs}<vUg7MS+d|@191U8$749T(fy@f+N52
z6K8$vk0&$Lbr!XO-$9mMdiEx*^(lMnhlRXS<-Z&2xIN&{wKLZ1wY07^H_a++r7fN%
zXW>T9zLjF!_{RE8=QCa<U)q<{Q`f$E{eODh>$SXn>se`2U{kg%-*3-jHL!Nemy3<^
z*`~WV>d$c@9{q;!LgtM+FnUZY%Qp&Ro13&<7Pjv;-Ve>%uk*QfaUI{*J~^`1rY#>1
z57?8n;G*kmt)SX3dQM82I`aYML;YEL8xHB5E$+8!UCS1E?^E|b>zic!NuF=}cDvW{
z(uS{m^S0o=f`yxZJR|7%?xwwU`o`**IP!lp*mdZMC*L>xe8HLyg|j;0{!N*cH!9^u
z{&Lq#Z^S`wn;lBq5-@%H=~%g#Ss!wv>P%TbLA(V16j^$?OFK4GdysTqeAy>p=9hl<
zeP?xA*fi4b-LSR89{s-Gp%Cu|Wa*uLx@yW(ui4Sh?tGXyZ0(|;2ZQ?lvHSKG<;8ur
zZ(BL94eVe$3)kjg%p#Yx7OTR2gI8@`sJu>e-b`abuRGpGg*(5v>UE!kJ<@EPzW-=$
z$HqsV>&7mzur%}^Eq7(w-L~nw%<jd<-aW7BI<OObWU=;kY~PR!`vqnl7ut+Sy(bXY
z-ume1!}J+%H13U@pQisu;#{l~viszP8BJdMXs>H<^HcDuPfOR$w;xoPoMJNdbvK=<
zn=?*W;6DBXEARdWsqK7K>n&0CnZ4$iC+~OFMYC=jN3;kGd))4p@eCiV)3jmtQ4x+Q
zS&Kv7ytwo#bDS`3jQ0Jl*ENO*-SgR#x%VkvfBqMy*|1gIcQ?3bb#5R3Qg*NG+Q;wR
zd@=F<<ogpR4t*2L_tDV_7&8-l#aO-$V||JgeT?1&oSIQ@zQwC<r=IGbaunQ{|0Qr|
zw;tVtH(*_v>E+L<$=jVZy7x{<jLaW)=gQfSlM>Cl6mHU773li;mVF<z%PTCsPJ>q2
zHJ%x;Z}C-Sw^H-;+~UUm19M*N3|t*2Xn*$T=+p3R$?W-%=6<W=as9UVyD$EGS>!95
z=}$EZ)SVUkZRvR8_$qk?^h53=s2r)|$G>vcNq9HA^M#&n{uj0Vk6(8UbGL|G<MnAx
zc48{p@7~`ioPM_Nm)OXF-oZw@yX`nVb-mNvk$=q@a_`DtyaqN$cO)X*4c2e)(nUw+
zZPDub<kjicQ(sJVzq!lDwaa{^H^sXzzg)Ok4)YBUrsr3g?>D+CEPol_<NDhCq099C
zbUoI!ZRo?KZBFst*>f^@@DI=CO_Or&gq;^p?3CQ0M`mh6ojEFzbFaj97(egAp*^a}
zmtJ(h`ZKeG<<pxu6xOmhcVlS1EB+5VdcQd`waXEOo)h+aw^tf$@M$CFlPo=-J*pje
zJ#9ti$yXxvo-IF=T{7&!$#!yTMm-W;pB-(p2K}=kmG|6;<)6Ik%)Or?FFHPbV!qkK
z*^h^IZu8fb_2d29zPs`SW4>lf3Rk2l>aexW`v=`8=V|&6h+bo$H#X|zOh^BNv9I|F
zhsW%L&tFy_xdZ<6^XTXA`EkI&1I{C}YdzYWkw1IfOa98h4;nG26IUTUR*rAq$9HFX
zo-s|cgLr+I!tWtRTG)1(x9oY}u&b&KRHN3Mjy)6FdD2tdud;CJ=SRsm8@FmfN{@*8
zE5?jhyE`!;P{Dr9_~w1ir3@TD#t}Y7S-5vOt3q1#{@hJ{?sK{5_f8qlY|qbsw#=}{
zh6Jy3b2mq0EPuoLwN@`Kw)s2p$)%maLWkM$j?LY#<j!un=D^6eo_$8<HFeL$xW)9G
zFiQTzyy2~81;=(uYSnjj=956pw@#-LuW5b?Ke^6kAJ!d@F*^t<wfBvQ&WLEKI(gc=
z`G?F}AJ}ebtiEON#?zi=`?|fuIK7SO@98xEH}U&-9T@M_dVO5W`G+6)z8|+YZP}iE
zrk`^*`(urV7s%?ZAZ}Fr30sv3TQ~hSt=@v#!D)HvYu}lvw_Pi+D9!&p24S|gpn5x;
zA*!>~Wa$c3g#%%O?pr^eziWSBL5I&vo_MX_?z?cyF6^;q^4<FQ2k-3dZd;AqF8<{b
z8v9n^;QXe#hbHO8yLPD6qLubD%wJfzV?}1BS8o~gYxAYJC}+P|bGwS*rQqX`5}Tr#
zuDQ!%anGZTdup^db-T<CyhTrUv@AH)#mL}Qp67^jP0ZET&0f0f^L+inFdpwZYnQ$*
z&DY&IqS9wd((Ef8Z*RV5+@q1e>7QlJm)9)reRTI+C#+ww^qx<g_(03T=ia5G>8l%N
zWvn~XOSx@nak|!^Q^rGVUW6=0duvVk4zjWw*l%o(hRce;$JgEm{<Zx$Z*=O+X2<-l
zX@+bb>hF#F57aSVPVsm|r-?7V+&Qm4rt#JT>PbEw6WWeTTCLJg?@fB!Vp`ixX7iVz
z$gXu8E06Ymw8hhR!fLCci;wKvT3zcfWQF!vepKsvv3PWpg$rw{Kfv_$?WI|#x98p5
z@MK}}?q|Y#JssSR`#1OOJFa6M8anzmzMP(|@_|XaX8gJR!iGBGdJim>7abgOcth>M
z+RNj%iZ$-F!usSS3TJmNJ~k)6fxhZz=l(OgMfLbcQNwHQfGr)zIuGcl7&Q7lj~C1A
zIp@<K4*gs7b8dg{<WSEM?K-V^y;-sDn<1|~*6xYSd){z9kM|aJ!k6n&Du2{?*JTT<
z<gQ<iY+Gb_u=Yl8g-x~E?tM9O)%!xNV))~3M&X)HFHKV3-~PdS!{6_AyWX|$pU1S`
zK5P4A=S1DPL;aeCW8N9S>f^1IXGG{TQHhm6#k~7jAKSx?_s7Ss%GYtqo!r;KG!}L7
z2MgDy&7AyyuKKKAJS2US4nI8O%-^A%5^trh|8PmP;N?}a6+<T9i;zck=au$)ZvJp+
zLS#Usz4bo1k2j_UId<6^zuIvB@Iv@$X7ll$e_ya&(0}lf<2|2uoRpJmb?BjBV2s|F
zaC1BTM+bIIU4(tg?0#_2k+DV}--=2-P4%bwMGaCuTsz^o((Ylr7NzO+Z1huS@p$i0
zC47K;e-3-EPIMjkv%xtvfQ~M;cw%Wd?tL{ihATiE?)@<Ay)hOIu&#x37!KHxkMz{>
zsQ}CezXj`n-+}ePAHe8xc^|=J!9`$q@F%bj_#f~L@MrL9@E7nOVEp(l-VTxjUjf$#
z-v&1TKLaa)sT_^K<ZoF8+zhM=ZUt@(?f`BE_6N5D&jPmwhl1OHSAjLb^iGp@VDbs9
z1*UYV+}t}(*t<{uljTO&!O9I&WaZulqH<pbQ@L+~sobP<DmTeS<%XMFR&F&gmHRg^
zm0Jr;<@N<rxo3c>+>5|e?v-FFH~EjIa#Q)G<wg^fzNdpX0H3Mc@?c$n4j+UkTk-|B
z2hRs%8pI0)linyk_bv)vRq=Zv9L4VqruZYl6n`9;#fL21`xe-H7|4FLa9tPY=`ezQ
zpxN+Dz$su;@C9&B@GY=8SRP?}gPVZ+fOWwA!HCNn2p$a{2BtLtD{v5aICv)52D}+O
z61){W3VaG|3qA`T555ORT=6roJ-B6UtO<jS!IQxg!Omb$unTxI*cH47JOz9KJPmvo
z>;cXNdxACPcsy^gF&K3x-U$u_Uj#!&@l!DBQv4D;3;YEf45s%~%mz#K$NAW2zW1xr
zUpr2JmpJ|1<Mj8E(;u}X(w`Za^oO!D{W*Y1f5?mJF9b~bBR!G+$eu`lq$ko}2AK5s
z5={Dg119|`puD6%v{|OVL15CK08IK@1Sb8h2b2Czf=Pc@z@)!7VA9_gFzHVTdLaD`
z0+asi!KA-TFzK%lO!})2J(2zzfk}T_VA3DGn?R~R>XSG>>de17=?_hS=K|1yw#xcD
zOgF_{@I4&dAG{Vk9K0S(VK;zrj<*RM4My7*V@TpffvG>*4vqrv08_nDzMKzo_Fk_4
zM841k%XgbhzAE_4`R`_ay(wSZs`KP=o(}Z6Vk0nYL_7$b10D^22*!}ZdkkI;egcLr
zc$h|t4}f7y;;Z1-;MPd%Z*XVud$0)n8BF$r!AX1?EC<d4D}Wz@6~V>e`e1F;vl7@0
z+z31etO{NZRs$aZHw7OBHwTk_v;dcYHNb69|E<9KV8|lw1?Gc=U@dSKxEq-Knd^b6
zK1eT|k7wrl`QM?JBu+2aIK5~h57G<rW_qE1i1b3^6Y1p~nDlZBOnP|=CcS(ClU{UD
zKGF;NQl=O5#Y``&z@(SMVA9J8FzMxQFzJPda*|%!fk`h$VA4xpFzLk|OnSKmCcTi)
zYpGuN5RLNz%<G5G(e*3NFQ!3$(jSH6{Nq*`Zl+8)zQp%umEmO56Mtv8oEpN(=F9og
ztTJEOaGXy`_IzSZ<>h=hRvAv3o*wB&;%|>V180f*Z>X221<)~E9{m*93fvq#0!;d}
z12~_A%zqz^%ZSRubdw#Jwu{kpdC_1RAGd&8gSUb^gSUZcY>ojB1aAl9c7+!QmZs17
z0sN1o&qrRI&pjT^3!@<{%(!e`+Ln`p!g0RuY79qu<b2Pu{mYg0I1YNNhcI^FCgAa$
z9w{E@_l@mUBt6RNKM!&=Mi}b1T7mO9xhNjzKkbL&Ss)tcgN!G@XDT=Tv*&L?w0E4z
zX#vLVGOsUqD7Zg(B6t9p>c;}$e1H8*>F|*b=WC1C5T8jN*?Q=L_D=axIL@b4jp0Zy
zobM>+Q>wB)r(<46b{qtz{zA;n^DOY0^RdL{jFt7$334<-7|h+onqZ6_Y#h=B8{@lF
zP78eId>#Eu>F|*Z=W~epBC4zx8vmqv;e7s3-F&4#X*kjg=W~Zg_dS*M(x21IK=4Rh
zx90TXhR>XD8eTLPkNN|$1v+9;et9tNRm3XbonS5SZg5v{JebDmeP9=GBG?nWAG{EJ
z5WE?D2rRWL&TkC!%|dd@+UHz^qjn?)<93=i4@~tqA3O|<F}y4t&X>!-l#UP5<b12}
zX5%x-ga2joFPc9p<2%hC)xk7xGzU9@(Pr4Zk@`dzd>;=Mf*rtaVA8EScsh70I0#Jh
zNYVr4%lSKDeo($AUu(pne5rn&!ITf>>j9>G{lJtj&66nK-@%mcQm`~%8+_*ckMPFf
zGv%uQCflN86jV?B*J!XI*cOaFf;R>{1dP1Jlm^BJF~agtW>y}2$7GG|y=J~N$ev}#
z3vGlWJ$3@O1nYp?fpx*%!Ck;6U_CIE3w^d&0LHbl^f{j#|B>|h$cx84r%!T{{IdNN
zY@W$M;rQPX4&{*glVH!}k)CDy{RXHPvU{3OQGN}<@4ys~^Xu?K@hlOK^R2)$#b+9y
z>VnBu>6pQdPcy;l_&y7)0iF%+2%ZC``ko7x%E9?XU}Hz+@y;0GsGXXCyMaw*;&J{9
zs+9jD#H4Z;fvMb|IK47`NuDqM;dtCL{Z)>W=*L(-lfbQz-(;EmxM%BGd#_wSwp{&;
z0aJfCR;GTq=i7fM9v^9N&zQ6FRkpA8oLm%+d-l7=aJLYSdmfuTYfR};y=DM(pig4;
zGlDC(4Ve0EYS#u}YR_aF=mW%y!FJ%)U~111V0-W$FzN3!nDqA-nDloE>;!%Vb_SP#
z(f5n%qQSU=X&qz=8292lH!%7to;w)#z`SYT<zVz#VvH?3j1}Tkuow6y*auAZN9E(5
znf^anKC*Z2nPwifgUanog!V-3BmmqHJe_M_)Xur*j%m)u`YG9VeiHhl^iF}%*YeJR
zDX(-eweJhy-eA~CSv%*R6=u)Sk{!wRQ&<yZ_MZu+`Oy`bc-(Wnte>wezd7VZa9%Gk
zjW4}9`AHV;+1x7gJIdvEjLR>D%a6*<Jx^O@xp(0*m3uds%AE+Nybge=+=swa?!#bd
z|HeHF%leJV<qk$TN)K}a)^CVq;;BfU`D6DImE$cyIO;D#z)iplxp*YM9v80<K2v`q
zTW?<IU+Uq!H<;qldJ-S(2gcaQ!y1m*3@ieZ{7fJJ#`H*6nOu4;@VRn-h_=njMe738
z&(OMnRF4He5s!~FxMvR8vxuZeH2<>uvv!=`C>-}JV2$BOe(w1^R-d5|Qr3>Kw!`YP
z1We;Vsf_&GGj%MUwpzt_>X;{!9kc*bJPmH%%=9IB4z5c3q4_Jtqxmbvqxq{;U)(cl
zRmNM$#aqP1TMYI=1Ja#@xfmb<!hi%I6DS1K&?y@N(KqFJX@D(0djKIo1dt450eOHt
zCRZ&1J-`x}2#A1XKn#!qWC3}Ayd&m1fH`0b_yD0m1{50sP69H4JU~$Z837Bx7H|VX
zfp{PTC<N3nX#9Wd-49$&_y73+D>X8)SSDt3u|^0XBq79NA!I`I?<%$RPhH5?h=oQh
zlgX9|jab`4EL+=R*&5Aa*&1!y77MXhwrt_|c%JLJxYlgE_uJ?F{k%W#>)hPE&UMb~
zobx)b^QZIYbzUzgq<=~JQG_beTTN)o3BNLgcb^xT9=XJGW|%jUQ8G_Crc~|cGY@zo
z6!Az$K1xv!8y<c*z!T9(K{kp}4NESN%LmYpdPu_+_V7V8l8}Zh<f9bTupG$x!53O&
zs+9Ans)YVJ*t(Ec&>$JPsDzZ$bA<*;$Uzw_TuCRq5swTMq8e6%nFgUqg4DI+I)vXy
zh1|&dA_18wg0&mzLnu;FfNIzdV>rT*f*e%9dN{+OK`IJR1)C8p3*ksd0m@O2_U?>>
zFXEAoe3YXe?ME^mzKBOU@=*?H7}X9QC_)A5;q@5#i4+u~7B-yVEXyoZ_9!1sJgCQz
zUid>ET4bOA6{v&l<BW#}NytP2sv+NtI>86=$V3sUVLg`P0bU44GO|&G3RsL||9}TV
zArG?Bkb@#rpdRhVvkZ7594W{}DXL-V#eCoa4U&+JB2=OtNoJ(chcqGs1*m}KRMH4f
zXpxS5RKa>0#|nIrfLxS8F5;ZvgJ`6q7`3qWWjnze6)aQUjkrULjESTLS@c)K&YV0)
zJaN;Jhf>tQdIs}(hV?-eagqshTXVd|GtILs7fJWB%mr-Qh06VcD%65y)RDFX()*Q#
zsucPBPGfiuR3|J{o@&y-_^d@NhhY}?kiQJ~AS@%UGs{S)zZCKO!K@^#Mb+1=&qd-l
zW*ZPE5%tdzhu_YLq>s>n`BW0t!d2$UaLXp72j1{}fi(QcwDj98Ax(r{g!zR2gvEsQ
zXm829;EGa)`x1tJ!?8q|2~Xx-Kv)Tjr7VxogFo_W`W+D`arvEvJlM7)%}kR76?v9M
znE8o?%9{Qx`YWx-L&7+I+Yu#`Fc($KtB|l1w#%3|N+mv=PFkoEVN=e$PzTSixfnw(
zs-XVHLgj@-)FS*8=VWLqEL1hne#?5m<~ycC`|tS;>q_FF1mUOoea1rNk387@V4+Gu
zDQv4ORKCbSCG5{K9g5&^&O()p8aSV~P{pGFs%i_BJ2GK;fixoyrEt1PJe0%jN795s
z*s!C7A`6A6fbAs<l_NY5juh0w_cG~(?N1geAEYA}#ZcA4)R}U?lmn(5Fy(+L2O8u6
zmqe-?H}nIo`8$6Pf72a!UDt|B7o^btBG%z$Y{VA4h8=jRCC@1cbC8R-k%xT9Ly->%
zKSUu8q6nX0Khqr|oQdgJfCMbT^DuOQ^v}YR`eBC&KSK`FA0;e>r1c9z=^T38O8ZOn
zugA+s#|C6z3tq!kY(o~dV+USGHr~WrkTybgAs2hF7js$GeEss?=64?6K|Ulc?-5GZ
zgRm!h!4Z8R`Q=2|9|JHDE^x&V428^N7@>5XS<WLUgDXy;9AD!*RN^##Ko!p80xm+@
zXSs}8{ERyMiffRrD`9sypeOpEA6zg9vb@3AN}AmWhr=DCFdDKAJqgEQ0wzMzKABKD
zcm2A^el(K)QFsg<7=y<#4&yNali&>>OvQA}fFA;&K?p(-hH#b>h1rPJFY`%;KPBTZ
z8<L(mgwo9=yg|H1g!iKj+M*pE#6x%(9iT=>bb=i^qYLcO72VJs(#<2BkEihrp2Y$z
zggo$Cj6^I&5}wBjti&p$U=1X#sf5xU;65PfA=2B6AC6pe(=YW3Nj*Z+M$`fN%^2PY
z_t3A@>%%ySBhyN}G4MomdyWIPmDFoz&-iX|Ku<WL51h~+1F)930|{L*1a26Pk$4QF
z@i@l93llIA(@57OLT^mQ6ikJoJJp@nQurRHQHAr6HU%$3>eZ6^yCnTmkFBIP15y{i
z8QaYqjbVv<(Ht$%3eriNE_FRQhDg8Uhtif7>puzJh#?=O&c|)cPwEqW13B1@T<k#}
zq%JL~w@ap1>aS&*IHs4n^bbMW5|cLLKZDeVD&M1(;RK|6p7Y+Xq$88%?Zj3@APR<V
zJN@qxZv|Gu&`o0aWK6*{7`oT#f79r<w4W+%rLKmw-I~rgS%0aA>o=BNk9iDRMgFbE
z8l++^Ucx%0;T0J2c?<oS*oGa*##`8hy?7h@@E$&ZY^Oqej8AX~#gJ|X%a-{zCT&gd
zEWeu(-Un%qN7AZc9i$zg`(c9zV2ieBhX?TxIzWw%=ma}Fiq7Z)dvrxNbcX|apeK4k
zy3K5xe&q8M{k|f@x{*iS;ea0KiC%C-Z}freF9l31^<DSnw-frIKaMiYnNZpR9Rz77
za4?3#4Z|S&g49bUbvS!K>KXUM%j~04=bqGkKOR!|q0~36v>n1Sr_etQzL3t3{PRZ;
zLLl7-oGaw-Nd@7z_zvI0&=t_X9|v#{AK_yZ;S(H!)a|_shv_ed)N6kPpP>XtA<H;M
z_&G`;b=ZCZIsbo2Scb1~0w*C|80mH-?|Y+;^_Mod9$}cYuk{q+qv)(BZNT-%066On
zBy_<bxMB!~!VSYP0`3@zQFsi}oo4wz;2h4Q8W&N6%eVsBFAdxDW42)(!wwVvN+{d(
zI-wb9Gl#Tw*%+2+1}n(En+&N-{60uM_bnmyK;91<NFAI~=ee|ZBg?ZTY>Re~&ahvs
zVR<h>x-`P|`hE}AXEX}f)@r61L%%1k@mq#{1~~_0U=yC;T-6Sp@DO@H+KiTV*%ve2
zb6CqXhUJc;|1sq8j-WGf<s5Yw>)57e*j81L?f}CMLON;hSlTvT3u$+G1H)y0(iYWq
z(rCu8rx_MSylBiu3}T_h9L&W$$Z;j-)cJTC&mbPpVgVLH3gIonVmyaL$T@il;ZiI^
z5}t>2a*mYwjwK!A@B+Ul5Ke-$RVHbDz7xk7{ZC*DreQjKF#|K<2Y&=05JAu&7$KO2
zP=w)0JcV#XAQDlKE{HsdrhhhKpy9Xd^Re`6A^Z9q%*8y!VLqP5Gl<8tSb&9)!U>BY
z-3``lKaN7S%VuoB6!IsLI7{)8jAP$3{9U-puwP+D9!dN2FLovlT-ZlS+3r>7%si5a
z^E}d+emUU^tfxPidA~<kM!a2wXBl2C=-&c4mwwOh(>TlTjraoFAb;;RL5@w?Mqd)=
zE1Y0h7T&-B<}c4euQ6QehcqXiv~Qk{jc_HMzKov*X-7VpI4kio)2<?X0k6;>!uSse
zXAsKY-yaz+b@X1M|7*f;a0=h^`x|8A7<^gYO!y-Z8iXJePazy~eHDe-h=mq&Fc0(b
z4CL?PvxEz=7>QU4xt?2rRY<{$kh<BWyFi{+@VBXoW9fDF(QLfW{(2gcZ$}7Aa1_U3
z=r%KM1V%zSx#oBclILN}Q}R~+7SD$qoAFqHMM%UlEQfTG53(KJLJnjbOZNlII}16U
zUWA-S)<O0O>8crb0Y5^zI@Uq1SKnYA-oychzeOnft0%HZ*A9%PU$&Q=N2D7^=t0~k
zFcp)D^8}{A(8+LjT*D){j4P1Np0Fz%&<lMa-3`J<%)<hW_469Vu#xnS*8d*E@20SU
zH|cl+K5#@IbVGMY*O#y#24J9m*i^#Vh}Hj|PUwpnn27*ru!H%Zz;}=?o6wcvLm=HO
z!Z19g|J{sy%pvb~LfXcYZZBz;w(ef!cw39H#GOa@G}d7k$A+{^nvM;~z-DA(E4CpE
z+pz=Lcmp}ujXii9`|vK_!!vjvA7DQYK)ORL`y=dy{2e&R@Q)$uyM*w06eE{3Nn47a
z<2m;8L@dK{lriiptffC48Q6@k8TKu{!)a9E9I9~<EAS&O;WB=Lbf2*7J#a%K{=Ug|
z-%O54LubLT#*pLVIzAzf58*PyN|`2&{+ICzHee$*VKXwZ9ddv12Hrvrb|Dvg@iz8B
z{#Lz1_%7bV2iT7TD8xa0gpW}K>E<!bP}1-qVHb43Oc>7L4|3hnmUJE@-LE~sw!~H#
z#>+k++iC%%P^&xh8baJ}2|tFk+jB(b&p12s*l-=xh5q&olk34A^gl%Z!{`9%<hNWO
z$lp-e&az!4|5sua#xU+v$a$kZ>9t2k_`xtu9@8ynKN!I<ImZknjE2;=WKH-X!{px0
znm8@-4C^J~eT@5sadI895A~3Hp(`lF+xQi`;X>RP$ltxg<Y_TJ#n0r~yNs8=JxB35
zN^zCp8;QHgX#dzs|8}F_R!nyv3|$W6b{ma<hyM5VzYh`?>H7~8eyZ<p!8+at>5ek2
zR6qPH!jt;`?+8!p`^{LMxzRH3Bb`zQgQ5F{c)#l7%CJ_%y<Z>ShOo8Kw5^%$0i$VK
zl8*cJX=%ss2aU#cpkJ;3-J1EgF<M4n`upjBw_$o){X7ORY@mMlNJ0;N|2RS~eZM#1
zWPSfsLSKD<AYrh+zY+7Z(9cuWX(7WC_2Zf_+)_U-oMDmr;Sx_v|2+NgX2fZ(kGFzh
z$@<|bgzNSF@;5}z|8nk4hWs6pemP#{Z<YKFkn@*ZcW03o#<uf&2VO@u-hgx^C_^P`
zP!Gx#$+txE{f~TGsqz42oK?|CMiz2Wf@-K5F%9^hROJTw7BUox$UruV;KjS?a@4_w
z*Lz;zRj8^x&u$$c@0CMQ165;&!x`@Ihc)kRZBd0f6!5;b2&Je%HR@o&J6JUw;0$j>
zBN=Is_q8RcgcKlc4`;Z;AMr?otrh13WFZfwsDV{;=Fx)ZrbxVx=M$(wJ!D(Uc5s9%
ze4s@N(vgQ!)WDN-hBxGyZ~^Q%N495M+rt^M@A*Uan>eIGo-1WTj@3%kz=~}tWu~0q
zg>WRHoc*Gdb5SK~P!CJ4MeX1QZ}=k~$;d)3N>B+Y%-SB#aECwQk%pwUtP^Ts!8`L}
zl%fLFsDlOPO=~#78Sd~$JkpSf0+gc$a=x;Mocp~HjwEElj&q(o&y#E13e>=gbF4kw
zQQd*GAYV;dVBeACcVarY!4p2vAOXopLoP~Cjyl*p!oCAn_&|#SJGRlIgeXQCDxvC3
z{=gBg@PQU7$V36kQ3snY#DgcC?1_&wWFZ#?C_x3RyE0$c!wGKif<ID_jx6M&0L3Ur
zHEg@F&TvE_N>Gj}SafIJXb*e1!wbHMLn<<m4|y(F4S8lMe{bbEx;!%vg<J#4`;}}I
zp%QVNbF6wXKgd035lT@3x!0<LjU(xTJG>B%IHV#2*(ie2esgc;2Ya}~AEA9%A5@?k
z^|0*Ae4&N|T;Yj0B%%iOuyi6G)Nq9l!V!m5WFQ|!C`Apd`muaC!3*I?LTZ1u{Q&Y3
z?co47B%=@>1KG!rk78K4uuN!?iE>n<9#(@$mn+92l93MQ!K57pC_y=@PzReKqzO)N
zgAWYl(bPjp3!LE&e}p3riO4`U@=%Hz)Wg<|`N0DkBp@AGC`1LSVL6O_0aA`l%Bgvd
zVBbMB;*o+36hY(8aKs}CsmMVw%29<nSd3(wz!jeGK`69Hfs|d#g0x>#f@(+^HY?ad
z%Cfm3`7!dvgLOwbGGH;9e1JDpW0(fEu!9>sA?-|Pkbq>QArpBhMI}^^GcD}l4r!Ai
z6&c7!8Kit$9V|TAFW>+V_#zaE$UrViAZ6Yx$Fe=)h~)94-HU19gHS|IAkR<$%ZbE=
zBRr9eQdmx6osfzQWFrrSs6aL9VB<|b!vP-9AOXq9LLtgf3HdOgJ?!BQe}p3mnJ9qo
z6yl=_i9T#Aq$3NtD1?-mtB2K8(g-`a!586(Ln1PejXV^h0`-tGb?spfCwL)mI@{Bi
z^uuZf^MxH8;RzpT5RGJ{Arm<$L<MSKHIr!}Wp=$F<#aQUjUrT{4pLUv8d6@@8Qus*
zA~KMR5=dEHOMmhijz|n7uY=gH;Q?=CqZ;){(y$zqp$?Y8#Dh0zDoZ5|uqPoM*~mj7
zDo_i{5Y`*c@PIe`5r<S{L+bu1gp}#6h3zcT1UICh2%cf26{&E1l6?XxNJkd(P>L$l
zLOvd`g+07ci5k?yGMqHQ5w7rn2GNK|8gfy9a@4^pf_cFm{s>1BGLeH~RKX&W?HR>(
zh-Mw&22c1S8fkEv&2UIP?>^8V0qMv_9*R(k8d$|JKiI<=?(j!A;*f|8<f8=Ts6s8Q
zW0}8}{Fp;OvXO^ERG=P~bIA|5!4sj-LOw=JMivTDhDy|+9=7v{6Gz(Sv#xN1H#CSw
zJkpSjLR6p*7EhBFw1)#+;RRoWA`xkja@hGOLIvt!^9<9#1OCt=3F*j1AxcpT%Xs3$
z4o>idKcbO{G-M+Wg(yWO<U<Y{cq1GMNI?d2QGjApp&r%?IA_5D?(jz(Qjm>8l%X1`
zh2$IT;S3*WphY6mk%v0iCXn~YMFEOYg<7Z<v0uO*PH=-S;*f|8<f8=DsDsU7_IbF%
z2U;W`9eF5)ZzAzg59=kY7krR{bX3A_DbpeW$*6|wGPWJ!Pym}G=7n&?BNI8uM-i-^
zXZyneuJD8}!eP6DeuN_qiAaUbO123!h(;cYP=+cbt|E_6jw;x^z<dynI3ywi`6xmq
zY*W}?2uD1UPzLpC@(Qj<Kmm$Tj-(fv9<{JoLq5R`amYjwYGIK|8ej(}WUOW0s6rhq
zUm{;$X5J`4Ic#1bzYz*85|M&j6u>5(`5^&Wu-L#b*ue?Tud+>$4vUQ(SI9#VN>K?_
z25Clngd!ces6rhqHnB{UqZ)N6%p`>6Yb+0rD1qfx@(^}#ggd+u2kUJt1NLx(FXE7d
zRAeFt#i&9ZEV7tC)Nq9dyy1^{q#+x5C`1XW<@XNO^>yMwizH+q8wDsqEt0dD2Qrb5
zGStH24blrW9N+;Bv`9b-(vgQkl%O1Suz8bpgcIE0iBS2S!@8jyHL%>type!Jl)-Wr
z`3E~V!WACyMl_O;1=rmShd2BYk0hib1NkUIDQaMq%Y5MkFKCc}WMrWbC8&nw9@YVl
z@I)wT_cH&t$tz@|1eK_RRUYdLC%C~Ap-4a~vQdCyl%Wzeu-r$Q;07;5BN3^{hTS`)
z0j}_XFXE7hROFx*;qS8kNJ9?tQG`-dpbnP#%nKgyhZadlM;;1Mf^yWs`aRYOuJDEi
zNk~Noa!`O8sNQGZ@Pr2ONI@0~QI1+ze!%_&CwRgK8bl)*naD>GN>PD&*c7ndC_*hP
z_A{RYtOt^jj&fLkNP6K3%R-KQXrP71LFR!Z)WQBE#v>W|D2C_9tRFJrT*Nj+9P&|(
zdI>*a*@swPgdz<^D1-V4^FRVpkc%qVe#Y`pSi(GDb(Hf0a!?D4W8^8SVEZ|7;r#{q
zhdk7N$#GIfejya<ujof8>dV<rz9v32u=<9y!vl42Jw=*Oc9wDHIRC)sJnM*Dlw4%_
zKa$6&u3=u6*ggn_w3Cw!?N5ZrhwT-%7t)c9gsZGS%8>di`vX+Jkp{#e6S=5F`+C*`
zPS?mEWFYH0)1nH_H&`y>kcbqdBMZ4GKrzZti5k?yQf0=sk7g=09MIm(jJo#-;fpw|
zZmBEJ)!Rl_RwAqw&$GMho~KGViaPn-i?T!a>&k!4A)b_Rd6wZ)POA^UpCVp!#=8(c
zMA(n`=NMne_*!f7`C;A#u$+3vpVtp>L_B%7y^G&cMxZsnT^TR$S*4uaQsyh~I$Rkp
z@98fSPu`_BW4M&vd641q-ueMTDI*fc@JWRC^IOWr#PVC-yY%L_loy-J^iuYsCBx;t
z*qem%9;`p<k}_${`8|=}e#EbE;2kT!rHqUfzvX$4JbRXMLMsX7J<BZSCuQW`B$RS!
zuj!|6MSLm4)0D6k)7cP8S)OXvOUejtBi>}DU(R$=cEg47@(x^{c}l#&{FX9xoe1UK
z`$W<w<?_}uUdk@W^X~hZ-jPtsyF@VlMTXx)d?_Cw&s(Le%vQ#aBiv3X?;u}bd1j24
zXXS199m;Rn&Vz_A%lBuvl#A%kZ+S;AWe=sin7nI{avCiOr96Q=b8k(&vrI2#^H%X&
z%Gc~Al=oH+#FMfBbNOAt`V1wMvU$}EU(5Jjgi=1h)R}U?lmoYNz=GbHDl?8cjzbsU
zs94{qz$bkJA~gM-LSlk_Bf=t|3XX{k4)+a;(Z>4D;eX%Qm>}PP=xC)^s|kzpjf>FA
zR1#mA(AO_EL>o9Kq$dMqzAh@)mS+C^ZByN^YNx7<w!9gR4GW5iij4}<s_iFsRgaI>
zhDC%u9TquDJt8V1IxIXmhUT5@TKf6T4e|@n(&TL59BptcZO+=Y3=IyC4vsM%DzCci
zS_WvtS%yqQ`ut+G0oq`{h=9m|S-}y(ky>4xSgnRn675<}35(Q3&5KpFpnp`<oJdW8
zHY_Sq7iZY;(RYaB+42p}F^2Zy3(aIr`P+e}u!X#H&zY`o!&R3YvWrB;1P4U8xP%78
z`e}nBqN8F0V&?miUm>jTpSR<xcH7B34Q<R;Fz@kZ+R(6Ad2QI3N4dJTc6}NViEb*I
z!y8q^t@!hF%!!mXvO~fHW-%{WzNGz+-L2)T8EL$HNs~Rp^4W{Vo9Sj`+`esvK276^
zBY86h^SW}4?Q7h=ZER@NoN$fboY>$$=87&|vW(kwZoL_3XrFkGk}tX}mbj9RC-ixf
zWv-k03DRRl?>It9N5SvYA^WsnVDPN4$Uh{6UDGczDm*IaDVdYxRg!L&4gXit)Q)^f
zVT>+K(Q^XB!-Di%|7N?%`;|P?Z+zk!*5l%B)?=c6J>un{rAr5Y4yE2y)w8Tej^FR{
zQ(2GTNX=iag{*@!)8D33)<L$d8zZH>k#5^k&Xi#u47=TWNqjHH$vemKX3-pJx^+?$
z-fo?08Sc+P^H103ZECmpKeOH9Mq^dfJO9tMNBqn%nV+ehVN*N9vLF2W+Zq0plcC!D
zm&SWeEj{|)Wryo4mzK|8@u=^&?{#T={FvVhqg$_SGOhaoo?Ey}y#KxJ5x1To>AM=W
zX=wf2ZCSYylRKKfac|!6w=R5cJ~%HecF5%!sg896?!MjP2Sa3jO*%%;O8)$M)x1Sj
z8@l;sRcE_DS+^%<)#3OI>%BWR+3-jDV^@i1YPYyyyT$)>d&GC!&hXu~9~{wFw%eWC
z1-9b4LTx_ao`B9Fd$#XS9X4U%moqaLhF#s*=3Ho-^xhHe?UG}{9_LxXNQrmn_J}>K
zC7!9BVN*N9vLF0&?F^q(_A8s<-OkCKCXShx-nRV9rWbFt3|n)oohtOqK>L=9zTUNs
zb7Y56vfO`vJHw;L$#U21`RYWMZH?15{}}uE=bMi$nZ3t-fz|%Zlbr^g=+*pcloMs3
zACq|hd)paaq5QqP{<TN5!me4<-fh)2aKF#tgS#%Z`LN(n;L2TVJh#5k^IP6Gyrbmv
zzrQ`=EG2y{HuY0qP{+M}a`1)h;-qe89y;FU<mYca_u#6zzn(7MB4zLHw%y_j%KR*U
z*mk~|)q?lFJpJp&mxF)qd}Z6Cdy~An?T<S&tM3T=yfp5)2FrH4bNj}9l)uwwGM1Nq
zJo9SQ@n7q2^mX$nEDpGD{e1)X&umiQa%rspY;G9ucaiy-+Cet8gDm^Oe@{Eec5br1
zruL0Z?HkK}@XxhxY-+dI)NZkqMKZNp{I#jwVxBqv)9n`DQ0{*lAAa4%>;A^qzH0NN
zDr?B}eLXY3T<Ur)Bxtg>Uzg9;U-*b`T9x~NJGXB<RJnfM)a-*%vv%(|;e78?38$6}
z-S}R)>qn~(O>ur@(5$JK+MaGrIfDn~JbCAKkXI=4+xD$0aD+OmqLnjk)2=w&Y0>^J
zuG@}G-+64^)n(V-pPxZ}0K9BaoB#K;mn<)6)aEa~JK@Fhe#!0QOE#E$3=AmraD4yT
zx*Y`z_HUhEw)wa1uTgeH*=~1k|MqiU&Z*5Oy3GsP_RFL%9tc(s{bkN)Z8!Gt+WF4I
z?pKd^x(s;g#DYDP<KX>^+SE?7shwt?ovF?Lxptbzc*^|#{p~NSl=nDyZZCP8a(?;u
zw}aeAInJvzGfp4)aKNn9gQv`jdt~3+)w3Lz{?;MSMSFE;)%N{PYxvAT$-jSpd&!r1
z&#H#LJc3eAp{@yKvlvD(2Bnks5DfA3<pq>-1P$X+#7~LGqYJ}3e3iW0m+y_4rHWS>
zO7{ry<bA&#VLQUkgcNyG@v1sO;!r#*LEa<xB$P4%6wgxTYe}N?@8nhTu3qLV)73+|
zfy9&d_dLQ#;BkkFR|E+`ghL493Ec>vBV-u~TM7Bol(37CM_*FJSlXLV+688r3E%UZ
zLnPreA*bMkYQl+xQf%@GLfSS``4F}uoKD!0(3jAGa3&#bT&MyFpC;50W)KDw9wZDQ
z{DN>6;SYqNgy#vv32Bp96+zgIFp_W(VHBY!VKkwXO_)t6+k@YRcl*jaf60$#3}bmp
z_bl;R(YJuGBVhvnx)ClSbRZ-z5_o*1T1x0mxQtNpD~V7`_&g!wRLcpaEWwL}-i_HW
zdYh^8?aWlwaF{_^5@?YE`3|fEwXh*0<ohpgghRdoOGh3`QH}p?Z8aFT(_m_!fn#Ve
z`zMl+ga5Yn8A^Yq%rQ*uGf;k;!ejrg_8H<IF;k@=6L}~`1!`f%dB+~^@JBpSkct1P
zb{)L=<J7Qihl2f_-x4U_R>yOF3yu%e^E-<ZEY<QW?Kw1T%OU3g=RVHU@%K|Up0Mg`
z%FJCPF6Y%hYs;aMang>%-)+MomlOS++Hq*uhJ$)3+Zq+DW862Kw@I&YI}XxzgS6RD
z$sgR?wbf9^AMu9mHF%WKjsbE|2{mnE_#y|U&XfbD95Cg8DF^;{<N&uBzpMYhGXrwl
zbMMiTdsP^^?--WaMOR+>N*i6--(Lu&{PO3FlX~-xBb2`%5m=1I+>|syQ``$fw~TQw
zL%P|7b1+~3`-z9R--4n0l6jWlE4+<zNV@`G6H48kryym~rL6t;sKjZUfs{x8fl$i7
zpT#+xM>Q@$$|FnnB;hq&*Z-DbH>96*n4uBO@ptOulzC+`uYX6KoX?XlQlHs6mbYHN
zF7o}??ds;dhxKWUCXlk)mV{FGSyRG$v7cd{_`7v={$H!7Q?_F^`E#ebI<3gN=IDjq
z=!<@Eh6@H^For_%c9`@Njv#c$D0pBDJTVUAAzcf?`(TZ>Xom;U9uMJRbbuNiA?-GF
zB0NR-2%*&d^(Z={3%a5^dO*6CgsrfU?Y<aGAoYf=z$&apDqe!r4J`HUN}X%zgs&n4
z(iu;8Kl8IeYdnB9u!VH8-^FviE#EF&<y<1)7}W4E%98gEHT?bwt2i&L#u`YyZENuo
z*5QA${(4ED)Q2ziB1^r;Qs?nD(sLQLxCE)Q_a4SIBF+8SH*QzQsG(j?<9a)Hvi`fV
z2YEQd^v4OmKp9TpSBA-cA*5c*o!E*9M8VK)r@vu40+Sdv8B;I~hVFIx-!%ID4*gOm
z=KK0#QpfNS`VV6r%RR&IDo9trFhBSs2qBQ}0O3J>e+l7H9Mk{4Q@xrw<nL}6x_9XR
zpRPyKinJNm<tgoA{3q6}DfP6DBfq@#`R7eIS>HdE&{y9dNEoc|zuWpX2a!jE_1iF<
zX(RR1%XZSz|99)!l)v?VR@bI+9h=fG-w)reo=th4DbI|x$U+_pQGyCsn{hsb4>T~;
zvB`&EDi5S13+1SSl{wFg5sr9hxJAuF5lZ3Dy?Yk&pyl4Y0QInH!g&mKaDyj8A?@2H
zBMZ4GKsn?Yx{W3G+VF%AG)O=?vQUT$So3h#8yaMz9=_avXCMdpD1y|ZS%G@E^RZtd
zN>PDoc(!2PC_)+3_puJhht#tv*HPARhSaI;1z%(!2L&iW1!|yTpUdVtu12oq*p^nX
zh19bt+pG$8u;85N317&wj(8*?6^;+^905s4MFFHPO<PEPnvU><p+3zd`ZJM(VpKuu
z($pXt(tvX^%3;@*=QMCbA_`H03MBIaLh9BmM-^;&uk8h?Lo)-#koq&LQ4cv!#Bm<Z
zK><oofzVF;-9Z+l&dX{zKEg8L315UF8EL3SJ$&p)E6P!gdRRS5{&!|wAoX3A!@dj8
z*O7s2<f9B#sD+z7agmGy)WMR!pEk&V)LmH*OI`p-+gO%8SXW3JMsCPJHu6vi`BuIj
z@=d>dM{f^zcp)58A7vskkPnAm97mA$5bPWo2SdG+`SeRYlTMJ22R#vrM5G}TIVeUM
zYN6^wKENLC$VVA!QP7v=IdRPe4`@(`5|pC~wXp6-Jh;IZp-4muvf<UA<)Q$^C_^Qr
z?nxUs!V_sO<OgaXbxKNG$7=XM+B=RzDx}ThB6z#9pCTM_NJR#+k%v-Lpc<Bg$uBs<
z6QPJl8gfyBav18SR1eWTgO_?KwWuA+{^LgepcqxChxIV#3s?9f4$>}iCh{TeBHJJo
zX~;q@q~6J5l%W#R5WOwz;0RYpy_AMJDU;|=MJ9?-hDx})b1b6(?xR>I<U!g*wtS3p
z3!;&M92B4gWgaYVG}{LLkT#J$#<1OxiX7Cz>v6^-97VA8WEe`vvfqqjpM@{N5s$?2
z>?0^ev=_@m398{VfxJNmEGDx3kbo3qPa+O%z1bHb^*7o~W}ku=?4BS#G$@6|6viVI
zX~=@T56eUXY^IVQ@J1SnP$uCt))iLM84oQokqc?d*xr|Epg}b9{74II{TT;OBp?R`
z@C_utkco0g9f`?EhqH#b$Uy<BXR$t^tPhgI$S2f5^(4zd4WwSe)JXOnRHGi5QRE>i
zkP^-MqY}~2Fb-0$T}?du!n33gKF}tRC&)v}V%8gFuzHR(zzeoZ2;q<XrR3Q%#=#4A
zE7+!phjTJ%LMC!nvR}Y*6>*V(Y~-UFb}z7<;hI9eBMUjJNjqxb_9E#<0+Nx2OynRR
zQg2!*Do~9&SgheVLVMW5HkIYCC4>*Oc&w%F8H5L+Ja3TttL5ABd-dT%443;HQ)kKn
zQx2GNz?1`~95Cg8DF;kBV9Ehg4w!Pllmn(5_<xZD7A$nyKVAP{^c-!hzVg5S%XR-9
zQ{Bg1J<kpr>9(9F0gs`joVn`Bhj@-w&`4#*YcpL{gu$VHv*rZEXo59<K>^|6u3?ed
zAucXa)M6N*jf%1F>gpOE5D};e@EZ^u;Mk{cKc@gqKv4hQfdl&n_YLS5)F;TPx1*!R
zxnJNA2SZHffIv-e=YRnN0{iw2?yb={1!{r=gM<6@9}pB0Fu-xZ5OwF9af1T`oci?%
zat?G32+<4-2?-q7+p$kTKgR*V!A`;b`t=<mPaJi1+Br+lA3A@fKDZXDds>F+*2~Uw
zoHL&{>FS4@&iWeaBa~r0-c$K0!>C+vPP9_5ofpG`lwkoux|$Ysb;I$vOf^dx9uyuN
z5J~J?b;fDwA8!^D96KjmdR0=N-#7YvcbA=)t{ocVe)&P?cD=deyZ?Vo#&>aX@$b!l
zAz_j7OkL{aQ!8uI@IULteHbL$V3KYf*#`ZU-=lB-?)STGGEQGdr13TxXZFW!GS2Mw
z+hm;C?YGIe2HPZ3zfI&lnRGMJ20Zdq#jtHt497x%RD>xtDC%oM^b4SdLgj$C`@Nby
zRq{yon?H8eN<EoUkD@;#_wX!kyxFb#AZ0j@KUI+p_QNMsmMzyX%+K#n6X@dN=NI0`
z#l?`$J04MzHkt36|Jr=-c>K$J<v19wuMbk%_LEM|Jxw9Ufs`w--fwjN;dB!mBl*tx
zhx$h~uHjLUvxX@7XixmxbT{*nT~aBp!0{arGb{M!arm@;n_D!|O|2%l7ag#L<vZ$@
zZ^*AZuGg)sy<=1*-7Mxdo%&|Im6nWMPdW_eCE51Y40}!)=BnE%*q0<P4eKKBXr-F~
z8+hSE;`{%8UG8}1y|pfPjC$AWl7AQLBFDMx2U50XyqPN%a1K$<y=sO@o8Js$y{X5P
z^_KjQZ7*%aGdw&va+X%wKr_w{c^@sE8isAVjQN!OK0oewEZoYEJ4U_h{D{Ac{E&4q
z)c+bS2M3*OS2<0|apKH8R0oWXlc0d0P!16?&M!17R_o%T8=(JlZS+HT4r1!tbhqlt
zmF$zUV1|8A((|PLxV4cCr87>Cl;cw0O?s%cH*8j9utu#M$2XJt`@wggMk!BboW{BO
zG}h?TIEHjeevQP>>|1VzG%BY{YE-7q+=i7IOKrKzC6Amr?<OAemh-yolYi`P<*A&H
zYLxw3SO2l>$Ic9Ec&;~Go9K=OU0t-2|Au;WQ=93QvYSB83)zrzkr{?{lRs5|*dKIP
z6%7X8Rl41nzmzLA<g=vPgJE?K$}rB&0pY>?RE|HxKH^~|Lv+WV?7l=*%Hbt^XtdA9
z25}jw@#EC&7akC+^$U)PiHhMY&!2h8dZp^=KaX-(X_q{gGJ%G)w@?ji`MfR-O8e51
zuZFs?tMq9mE0uEwlPTqPbAFd*WtY*NgKs9%Xc*JTzCduB?$*8_$Cs2nHl)jNj&Hax
zNcs%>bXs%WEPD`0p344qm3dSc(swues*B5lyWOe(&OR;aHJrEXTj<ieO`qP)gi>x-
zU1+oqG}s}P<lScfl{raz<aqgGcPn4r7-_t(N_ryo=Y$G<dSqXe{CfaWCbY&lJ%71R
zl6805DVgWp=3B%4Qgu+t7u7!Q&LrJ4_17tJ_c2pC<8-f+eALDN7p_xo-L=X5{wkfl
z887D{IeuPZS%&@8I9*cqO1cw}{5+0h#P#}py6$)(VSG2qER=MGO3xp<Th~a@jQh+e
zU50a#w6Q+kOjj>C=W(UZZ#Uvfc}a%PryhR4c`;#HZE)o8^0-{TF2;HMH1qfWNZBTa
zJig;a!0pyWj?+JOx7J1SSjub}=ds}$SxdU5GftP3vrW;ZOSeBZyhirxE4N!pKFT%K
zA3NRgB6+4}q?F%f**C9|Ww=ZuWq2Fj!}izjlXmh)mCnpuDPE_#%Cm%Tm`{N|UGgZ!
zPf1r~KsfPaU&~Xb_``q7b+0V5fKisMWSP24J&7s%U=gA5-$IES$1vSC)m{Ec+)>=K
z)R6|i-z~i1?av)|N9Fp`gZVW)7eAmfZy86PWRk`sj6bSdS0%ojm*fUxyqVv~xab(a
zxvaGuD~4&*<kuE%?%(`acZ|zAcoAQ|<zSjgO4|zjHXL)hd4)tWNSQ|#%apciQklnl
zM)PoE{Oy)2%NBu#bDw^Dxe#AYgZ&_7+*1zy)w!5UO1a^k9~l%H6BQZubg<v7@TkCm
zaD4+6v_lchhWM-V$WE4HSSRE2^24mZ<e8My=Nh8HUw^~-PuDhtv{fXXq*=~0a=gg*
z3Kjoi+NI$QZK&Kt`q5-Yz~4%@ah^K0CLwgP9+IbhA$jU}_^<LbBq}B-`2TsHR_oJF
z5iKQ8DcYsvX~Msl_S@yD96NvPZvBmx{l4M8pk|nShw*3og5jDXLH=mdSwilG<QBfs
z!~9oll;;hbPjPXPOU$4-F)_5I^2dFbsc+NWI!DT~bo;5FA6qX%PH3_p7}_pT9vBfv
z{!B}nWM5FecQH=WAFgvGNnG$oMk)Itlia4em1mL$<2*B7eu6x(qU!`XKG+47Z^ayq
zm#@3kF<iIG!u2hu-2L%ep=_U9ZMTfkpIa<!Ss<MRvV1w!$noiKy!_j)e@wtUxnm{%
z-#Ld!9vIS)q)&q!i;@O87QZFE3C3yoeIA6x%A-8F*$WJi$4g2YWcojLx3+^DBmXQP
ztlH|Pl<hD3fn2W3w|ymlo`&Byu0njt2ZGylx6&Z{Lc=r|?qRa^X)x>y9f>R7YSkF0
z;SbwFH$eZafV;1|Plxd{0{NRJiP!x-iVU77e+B0RE60lA_;r<s-gJ^Tl1FmOCEtsw
zKQ%gj|2lm<DhLP(*3bKH^UFA$#^>;|+oVUnFLS(`^!)yzg^SDYQg-)w*zg&K;XYp@
z7kzZb=N0+>&h2i}rh84p1_+bG>#p~!!OY+II&_-;7?*o}>5S7N-|G3_O<Ee}lRi~<
zyY1w=K;twS&buibTheud9P?e#lD`EBhBPVn!@-dOf#EkVTy#$>ls~_JnJ2xOmt42V
zvG$>I-qW3@4Ewn5+Bh&wYqXCK(dSjIK3$!eR$leUF(^lM!SB+gPf1W{K;$e=K6H{F
z`qP;FH0pHs3bNmJ(=Q{MJduvap31rpB(!DSYjn$yD_~`QaT4i|-OX$61jgO&n%j}#
zwo1O=dj3?)Fn@-b+B}+jxYwfiNry{jXje=e^}>|4ecmk|P2KKn47K^P{XzGB@ND6Q
z`Ei#EPiEKJ{+xf+bKj`%<{ggln%As!IC<#dD)CZ#G)p-DtZn4ke)UzRHjj!pcuj2{
zc?@hB(R_ia%_BKJOl=+o|9Y?Wp&hw>pIZ0%8`AE5&ykWZ*>xXIj?}uG9ev@6i*F70
z*|qqytUjOb>+d*g=hQ7zb{>71Z`LPBynn9Eqt|%$pf(>DFvhIuy=sSFUT)TD+U2V~
zhu7IUKd>$>!^y?{=WUNk`_LaN=QUHCN2WH9WPdTWc{DgTv#EJy{q}*~rlj_GlR68=
zO1}K?Yi*mKN=}`+Heu1APp8{epFU}7^GNc=)aH??%_G?lE=KjWJ^aOnoXyRCyWn5b
zq<Q2kJ4dz{`Tn=_-`SRO=AnMGc@8{O;;p#WF0R;d@8_;b-~Zh1yKGJ9kqZCVi5FKk
zed@IV)5p4T4`yof=$hT`(axhLxCPff+d1Uaq)*R{%sWTDSHmR#mVfl+j(4t4cbVz)
z)0XHMx3Bh|See-*E`RluL&+JRS?=e?b-`eX*KE{V!O7<;ijV(1X;nye>xDhu4;t7c
z?r`e%Y}<jsq29TafmHtPKRf&FiV2?_?0Mv+{Xe|$!}@pY&41XXKKy)D(lha!T3pIx
zem^PqM>7IS_QsB@dCtMHv4^Uv<iVk>j%~0j+WB6S-PPZ}-E9pwp0V63vmYGa7yH}J
zVKqm~hvr{CdnBUh7gL)@k}sw<kIrw{6nt&b_NKl|I=D^aeb_e?T;}g;|IFF-3+k>P
zI8y%NBgGe|<^D45`u(HAcE2^|x0$CGN3hR(yGgwCU(SB}$sXVMeh)9ZF)i);z`Zw4
zPH5k^>FepWPX*?jIKmCOQh$Q^BFpPTo38ga8{hxvt`ozjJ-7I5*}!j{=ACbRX_5WQ
zjh7U0d?@o<e{Ip#QNz5hgav*0?pr(7ULEvYe5dxq2b}qSeb!9Xxs5!S8RsF(J@>=e
zmfuZnbg|vfiCI&7Kl++Si*Ogmi@$B`F}i8jmOGQ?QNI<-R-2D(@>)e<?L%#|nztVD
z+|YI#Qo5MhJd%7dwRzNQ{-;SPIpN1&UwO|ycOFdk;+d1${CLdj)|1a@+MLtwZSvK&
zr+z%+wsFBz%Pt*=|MdK*U8B=&C^y<);yr17w#IAv^AY_b(jrW49+}!aTH-Zszp2fm
zq5NGiwRvP}^Qe+*2wwPbo;0<2lya<Pvz8mz9N6|@Qui6BRjNt66jz(u9-3(Jz?9X`
z<@Zm&ch%&nHYa`O%xf}z&D1tSKgu6Db+SKo-YD@dSFBEKKjeBZ+l4=vXIu#^KI468
z@tI_&{%JXpA1!<(gX^Im2g&>%I{RsdpLSLr*&ZM4_iVO*n=n(GM~_RsnA$vg#j^2_
zqc4Q7ePcuQ56u@-XQ^@@+W(rxI|Fun=H{8#^Txg{OP%&KS|8QqWwVZNo|~}xO0C^*
z)aOLmAhmhxxz}=A?0WRn6{qJ<_B!5k*vIeMT{_dTa=Wj?!Z9%qq^47Kn{u50?{4$R
zi_?+*J4}@){nANUCwHZfI<R=nE$@mC5~>M5ChSglh)~`IA0Zq;c$831ZN~^N6WT-n
zouTsmAwMafLD@p-p*u{xri3!R#FzKL`fuQrZ{wssNQ!()+ek`hZ>Ca;A9W?1%8(v}
zhUxU*aVh13B(m{zF^zP~(Gp5|p*e&yof`V@uay3VZ8&w)&tKx{zim>!d6Kq;%oxVy
zuF~=D{pS4i-~8Nmezb>lGrjunX_R>skRitDO=Es6LbZ-i%J;}`!+Pq!d-<29<5X$*
z7KJiQd`m&T@`yy`0O^WJm*mS~!k&bm61ou{(Wf_>e*O0zs@?QUdgZea4WwgRB=8tT
zX#+~8m*28aQO-}Qc~kikMi9;*oJ%;9FpiM&fC-6&0fes-1`=)~WWG1oSN{!%lAj*j
zhZyJ6uT6B@wVsf}QFV>bkWc#WD3tPP4fmtZnE$=Rm;FwPvy~VvPyc;`st3axPFG5P
z$o_hqQ1)%wtx}dJ>!|<EKqcvy{2{3~kEL16U#1HslzoOGeF;)tBZ`p6R7x9Gl9yV3
z#}krA37ZMYqnqoa|877jo82%USeP<@GeXISMudj_TVHNpneNZ_Z`oG*a`a01`i5<k
zwIv;reu^(8bRlH*5_mK!+eF!3od`eR_oIZz35|~jeVO*#F5hrGI5UmDjJXnzpDGI&
z_Rk6W<9Cw&_?=8B>p4Sz983E3Wx<s);tkVpO}bhV2MN47lrn<}7YW%G39B0^-)1Ci
zA++VUlr3i+mHcxfj=s#Yw4<hMS2-@7Al)doe+$CL2&Kr<XhKP|C!v%d9!n_O!2|m8
z!%Deg**_XH%oWnLBc9~%gM_kwJVf{iVFyCl&pHu064Kny&2;I@{VL^wWq!u#@*<w3
zYXV_M!ij|42)zmW5>6(RbV<JJ%izkfsH~rHzB>|6($$Ah&JRw69MdXi{q&M1eOXv#
zfA?ph#>XeeymB66UrA^})L4DK%5>JcGJ;AOFG;`gbZi@Cx*rK;J!*`m)0Z<<%AYno
zK3nV4`v4(Dhg5Bh(y1>Ws{DOuxV-0?zpUqSLRrrh`sJzV*O%#3@~YwSLp{n$K1w`&
zxl5I#w_&_8{rub*r!O0+q`%>I%OIYlV-sO3!p(%T9$N@yJ7yBfc9Z;5>&jj!Wg8o=
z&)3A0{egWw!HTfLXgYma!+&`?H~sRYOkTs~y`o=UI-#up2BYQq|IO(V^wY_H+wgoB
zp+E0O5_V;Ll+k&=KtG+FUmH$$mh*+|-xmlaKQHRfA95V%%d#nD+~oXWd>oJlWxH_A
zlORReImVUi9{xroRB#~wH?;p}&q3)8Q#*j1w+HL$CQc&E!GBvjfDR*QU+!nVDTS#$
zK+dl|T<>wwYibXW<AM`sMjd}6_H(_Ez`2qBG=`bl1LWL!FZCWT<(T0QNyGL49g8hg
zRml0&LS=cxLgj=s)WiQX3snYc;ay^(N<k&sAGJ`$BM(-`EL2`dMHy6|)21N8kqc?4
z!2?OiLnUmFTc|t{k6hHk?F$Q49P&{O>o1ws)R}U?lmn(5_%F=?9tr%e{l5hau;2zQ
z8PXPtd<)Zx8w2^arC}R+(r%u7ODPYc%<zA?ojj=^M(W&<@8|#Nw(?}xGqsmzYA;XP
z*^}?y|E#^di#$LpXS~!8QBS|r+Ymti5l9^#QfG+N5hiupeT(mL8oA83VSAoZCxg_3
zCUt^I{a*!yQqS211fd3(aRt9X>Vq(J|4MtG|9{*1yj?q=-;s9t9{BIH_4yO|b`Iwu
z-x6ALZj<(^nnKzhY$E46NLyBtkMez>)L-}=zk><qLh2ZiI!&bhF{!t50pwxUA}oQ_
zkM=y4BN;340#;)Uq?<vQ3aJxD>Y$N&>ZHERbi9fTY{6^Tifzck4rD{>6qHWBsg!Rh
ztvOH2H=Fm7_U5=3jnM*Dkah~svJO9B8q-R9h4YwJI;p!;mMz;|)+Y>7f9bcxRWaR8
z`gg;)y}~Pu`vpHT52=gm5-#H>$akApAoYa(f;ve3O26VaNZm5hNn2r!nE&nCKD@xV
zOEP~9Vf}6p)<W8}lzM&4nC>XQrOpC#`c3U5@{WrKyr0TLUb+@+-}@llQHGW3hkr$Q
zQs4g_;c0!p8Qa8Mzg=V+EBcMwN&HW2Bk>W|!Om!%9;M%heP$}Ap)<d`z+NB6fv_if
z;lH(gMR}%f3p+SL-tTxL6BcIthP17ifo$ZV5GAOF6W5Qti&jw;n5qQQ&Y~+XK$4M%
zB3N_VE$u93qXIQh@m$&-PH=-KQjmch6rcnZkZ0KGymYBR4R}YYva}@KNaH0#8LChV
zSDs6F!WZF)Ln73?<PAj}5|M*CSdsxYP{S2o@PQWc!XX`5C`1Kpnlo>NA`XT&7~Au*
zzyZ#PM?Q)m?Jy?tqM;CmHW;lqPF<lz1`1(lZ&7OQQNt1GT!WXQ61A}4*iGhdcRr+T
z#4^Z-@7`$GK4K2T@?p&jPc`C^33>5p4K*C$#5I2s(xBov@Pu4H6ruzbkn^|HOCsO3
zYmkN<RH8lSV+S~+5Y`=-Hylvck+2i%3J+*dh!T{e3KowLA5Ji|sVMC!YLS9;WT6lh
z@UmmOA_*RkG7fntL<Kx~S>gj}V=)@Z$U;7fP>LGV!?p|iJsjbQP*k8Ew!EyYgjZLU
z${*oKLKSKul_yxi7EbVj2J&(;8Cl3h3AEi=E-F!jdRRKJY&gRk(a7&bemJs^!5+@=
zfCkY}^=6r{g>jpUKK#}q1^Fn0MIWYz2fX2raKs@6*(gFODo_o}zN8uMoCxBP3`5(C
z_Wei$3Q+=!{%mVFArx`&AHeh|L<xMI+2@dp=z*jSb+B|{9ifIRJfJ}W(vgK+l%O1S
zuo=X5f+q~^GbYfVjw}?S0@g!VUr-IMDh|oWKn_Y#je1xQWq$C4Kf)1@WaPrzjo}DK
z5>k<YY!smqHLx1Swt^Gf;E7O_BYrsZgTn~61>E6}aKs@I8OVpUuUHF}JM)AsoR9^N
zk*qT`h(-cZP=Hd@z;YDFBAnp`4dPIY64*V){NM&p_&|d=q#_&Ts6s8|4}mqD;0X;%
zP>w3pLN%IY!T}!eMI2I*1ML{L32I>ZIBA1Bq>V>kNE?r-$U;6!PyriH@)S;RM;y|S
zg<_P!aV+_ZTsV&>UyzM_)WgAxG$R$6$VDNFCy>7rnJ=V0$Qrm#Vi`z6CZt_Rcm4=^
z!yoyun#?d1J;8cUA#dOXe?%kBhw~7Mpqa|@P>2fHPh(pn6?O2KPTn998NS4U)eQ0y
zWw4ydy2Bl|e#D0lickkjfASB>NJsksmI<n6Q&|R*AMijj@=+{d5bFvlkR<Iyh9V7F
zs6zW-rhyMKLYW4tFxC@J2t^vQ;QkbOk7N|WF`Q*15$XuyA`MxPwj=FlvrK4X*hVNr
z6*6M!M-}4dk@qM?C6eRFPZS|;KIum>d=eRlbd)V&zg|lE;EzmHpa!aC<SA@n2PfDh
z5f9PGM-j?U2~{$2;EwjI*!IvM4aF!&W(pyy;qfBrM={Eg^Ag(zmg~q9sME+7xUMH(
zkcwhhy-Z%f198Yf0g7HBo#~_jt{XTu5RYQi!|GMm1$J<RD?H#0e}p3riAX^@vXG0+
zjVwQd5S5TZ8QCp$_foGA%HQ_wgz_xnc|y5AbtSxyFh)OqAfeP%{W7843lAcc`{^^d
zhu>!jzaf<84xWU=2<7?0CPKL{bS8A>cM@S9q1@w@GkiIrJjbwLdU^IJ_jOYL*c`%Y
z!g+*pUp#=Y3E@aWxj%o6P|_>+hf)`92H^>QyAjH>f@ngi^Jy-j+@C*3DC@a}a5dwl
zeo(2eDvD6<qhkp>@_R7hFv7)za!<UOQ0`?-ohb)QIbg~GQx2GNz?1`~95Cg8DF^-&
zbHIW`|NZv=BEn*WeB&atzEOcshQtK>21IE3JNYWLG5;TK|F4zGuI12Sj&Xf^hiC!^
z2FqQvs<Fzm<r_AtoAoHm^Kj|z!#!w$R@^_h?QE)I)NLD)(N(XliHg-#XRXvb%4E0c
zeqV=i!}_cZb<M^%(oNclpeZ_{6KU}O%QWcgFm71atWult-PeC>To<pQu2)INc(dQv
zXKZMn!QPyablk!#-&-UQ$~|a`A+5SPXr-QSzmS-y2*0RUT{Abt`}6u<RX6KrRTJ+N
z^BZq=GkaCira%IDWXH0HGCobWEVh-d-G(^~8*dh-lKNtWA+1^Zv^p~065X+ndAse>
zZ(F0ZMg&9~Csj$SGx2ZJ-At<+BO9hwmT#!9*G&#ux~XUm9!IH$l8A&mEMH$mxRM4B
zrnyabGYwvhY?ubA$JdA9;oSd@H@j7zZ6AGIy7E3px*m{TdkiOCHHLKE+O_YP53(#Z
z)64s9<7M^KFUv*_Dmvq3g+9o$klng%pg)BE_Hz2`my@qwP9DpWV`w)<u};zY<wyna
zMyqw#dF#PEjN1f}ebJU>N&AUB{!z`>&7Xa=WlJZ1YtgVx4B00PdGFtt2z18j{DtQj
z{<*sRxK&HO?s&PI?SGZ&8>X><^!c(ZNn@C9-giu+AulWSY3$3ia@_QU9OGVlbZO)i
z^M}0rt7Ap>5jW<c+fQ|Mr2pA|W5_2>6DFWDPQ$OPXNpl8{*`^ljd=}K&MSYt{0CH4
zExp+0>e*(TOIU(dYSWf&VbxN$Z58Jfa~aP0jeilr5m7Po8QzKUa^9>~#vAsu-$hZ?
zGTxGXKX?T5H@{$?wLQ3Y=5KABx_+Iv<+(u>?<Tj+dV2Td#oKxhS+sLa3G*B#@tkk0
z*!O<?uN&qEIP7|?{>Fg#bD2G-gp@3KCSgui`#EXlJo8fK*Rj<@Z-3(4_{uY%4{xE`
zy2d`J*Ps^H`bE6ZtXmhmB`23}<6G&$GQZGci7Qoa_O<V|D>&)CMIo2>l>2}Bbmx=7
zc3!XLj&;9C9^FuuyY8X3O-2no-2eW^bDNmzf3~XTx$9WTKi6d^SDi2a?!lH@^P9RK
zKXtmrrz;Lw4jMW=*t^Ta3!8o1n!hh?C0=D*z}#++PuLuqzI^@s<?R-P_MIGC;ksmj
z_k@_7wFgc0KaW4R<6Tqz&nJT@uf<93|3&@JY3{PzsFmAKhHe`F*n-8)?rD1L!Am3G
zdG=A~im@x3JUnLEaKGMLc`olF@w%jpOKIw?O>dQX^oL<@9oMv7K4tS`cKg5nJp6OV
zPIjj{^UQsavK}sP{@Ca78LA`qKKX5%M&%#w|K{)3>%4l1%+K=c8%wGaE_H7mI^f+S
z<6lZmxSsKSH_H>>#P5Id$YIMDk8(bqCGi$rYSZib2K&6ix2gvEo?E{D@!tXxE}Tr;
z-&6fb>GIt_o-)<fyftV4v))6K&i<#>*L-TEY~MTAuN<KqM;?y^mRmM5pMBA)!^SY@
zjQZ-Bf{FHz?H<s0__=-8qOM2t{>@tE=d;vlS;4lJhwlBU)n~s|-uP(i)>(}o@!hv+
z=9;g*c<FMqD}St&cr~trvU`V3x0!U%&hl*gAJ0$RyQK6}i$;5I{5I^!hL^f?VY~Km
zncu26e|fj<k}HW-j^06|M>y3_-f=u4?ewd$qq?|OXV<lxMwwD2eP8F+W#(?%-F*C|
zsRM^yd2zmf_}sl;`JDH3tp2z><DrdQ_oOI)XX>o|k1crU75|Xpn$cGsnq6)5)xxr|
zf$!JHn|Im}bo#vyd6z$0mTP4>YH0qnN3xdooD%kGFUPNKJ~h?DEctT0|8Ik*?!VY^
zwUteig6SEPvR%*g`(b&?cdkv3&-1zR8`oF9!zJE7R}b^u*0a-Llq`4eo2@icPI=tu
zn>=?}z@<Jv#MJeB>4&yvIi=mg_u0HM*^_svk4e1vMb5cH8ZEP{xMnlxyL7j2ra$4e
zrJ^qOiI8sdPQGC~s}*I0x$#h&KfHbO_uZl{r@b-XBEafnYx_gncg75Sc}n{Bds{Vs
zuw6Cr-c{zeV!(?<fvtb(KjM1Jv00@HHyxc*{pB(Do)4?KuUM1#<v?z*LzVQ|lm=)0
z-01Q^Pw&Y;FKo5$iTa7tJHL_cxc>8>zZ!AqH!t?n5z6^FF(J|B#N|bE{T}vP_RQzm
z^BR@fKDTn?X6-!>AKV)E%98hZZl$DeM`Sy7>jQ;DYa(u(c;Wsn_q=AA`obsKFD`oL
z(Wf3=)O7^!y5CWj``NJI`hpQFC-)5R@tno0dz!UNs6D*knWE^E%e$UkSH1l__euk0
zegC<7lhc%Z2`(-PyYAGl?Y8R1X~l0%i!x8T^p<V2wXZCmozgwcHD^6V@RaN4_g-sq
zbbL>@MuVL^_l-FG)$+>`RhbJ1-RGAbHdg)U>~@!Uzpebee64wlE1#W>2pTi&;>+u_
z={B>2>w?2iU6^rY&;ifoC*>WyzcRlUwBLC@@1MFQX<XPGQ~kv&xryqdTt|G=;{F8-
z>y|A3rKi_*ZOZs5v0gnoZH#+lT$anbos)j9dQ+tusN{2C`$iM9vU)G-_hRApnYJ!H
zpFTbFxA&e|UbghDXOm{vkM&}|QjYTu4?BPM^y?RgzkAvI{fo`gzZuwRgi7Q7-mwdh
zJrU8*dw3n?2H5x2=G#BBd_S?trkAXT*&To5JI7V(agTleX!lRM9czAH#{r3h11amy
zHNM*XtMes6HFkrKcB<~1@<71RH``2_`o_Cv8=Eik+t=vK&uuCx*P*P3ss3V9{l&7s
z?3<PS^qA)+%$ojDhfPbTw_WwV%M?vNhk?QK))!y&zVyIZ%Hk;JwN85*=VUewT-&Al
zp)>XUT*tTGXm#q7W`6Bnp549I4X-`yqhIxt`BkV6{BW`Bnzlc72p#!Rz>%xt7ulSs
zI-c>qL${6L0cS_>_buB^;wA65sa`+*{PG#&?;97=wa?NmOG2XSHZDm@@3m-so%xY;
z$|))H^LcS<^Y^z$q_lbJi~L!so@=izST$>Fo9|!!>bJP!YyB#l^DPVKEVcRRx<;4n
zGb`UZvCA@b>{-{xT~3!wJl|nkj~Dz;G<oFUg)++G*h)N8{l%vGi)B9u`sk6YE|(g8
zFv0BQO+UZw{zmC@pN3qpi)(at(2V>ipFYKP$q34ss?F2(c02gn@YOH1Z(Dt3|E@E`
zatB<sP<vl`E%Lo<&Cky^)n9C?zc}Q2+4TR3`isNH$^N&0>eTZ=-EuBJ+x_sM(AZDy
zW8XU-k`m^&VNK-KHRU_^^C0|9p53a=dza6?v2DYgA@TiQ@3r;7lj{N(PWWWO=&z4{
zqH5;#&eom8`+|qzYI9YQcHg2+c0DW4A9(o5vrmS7xg$EH$6~7=e|!D2b4y+^=lVd(
zQLD|*mt0vN(q!ei?Ec5sUL2F`_;JX)Jv%0So4X}2JF0v^F}I<sl<S-s6(>>-CHQvD
z>)gL&fAek&tT!w?x~=onMThsk(K7GIS)RX47$EaoIro0QS~Itgz8KT=XzaILqJG@>
zWRHDK22I-)^{CZjeXnvIJ4=~g^cyWZs|I;%UGt7^a6GeeZ+ZRWr#^VZ+@@duogru5
z>9B_TRpq+<qj4**M%}aUn|urHdvkp+x_tZW_hY(u_~huisj(d|AC-E9JMr#EZC=+&
z+j;XnS5EbrS=}ktJ!4H@$0s&^@U(yIo^2P@Id4yXi*mO8C0>>L$1&l<V<UcXAGted
zLb=&@uM}T=cFH;R3-f+%mw904YUZb`$DQw|`zZN5|EW%$6V|0Pc|LJpTkjr=l7ARx
zs?S&Qxh893_WRz}(>A~S;8RVXYZPBtU9|SHi*3iX0dChWKA*|9-P~5<y<M!mXNB{M
zRV|zBP8s#h`0p3**fp=F^Y!JGk?UTYy=2o4z6VwI)3RS)RUQ1Q*XDkqpMIiA+IFeQ
zp2e*l_Ret34(V*x_96Q-T$d>EO!fKxPuJ%=hi3z7^Glu)=}Bj_^_~INu6+(hd%xXk
zSN68m7rO;k%^c=8a2xN+URB}^?XckDug9WaTsFGs<!<WK;tzjH>bkRR|GJ-#XrDWG
zO!;0zxeq;?_+8^g*9QN8?A;Gs4f+1~@u5(JA`0Okgb<1(gb+dqA^M-9lsXZ@L1+nC
zSs^P#AuGg&*s|Ge2_gSOYzQGX|5n!T^*J5)`tIF(?|#4c-tXP-{mnc)edf%WGiT;A
zbEf(8dB5j@?VZ7?o5D6t7`|8Q_2nty?(Mgxd~UgaXxTsiIjAq#w^=~b)<WF|L&OAX
zG0YUA`-$7-+{zU9&eVDRUQ&wB*+J7jLY>D@d`^tVX07fL7>_}JH;<u;aWrig)NLA^
zm<Wfu>if79>U^o<9_SRN$Em40Zz_k&QXsFnEGbQ+WEZH;D><4njMuJ|Gbkrf&ZG>X
zoJ9#~Hsu`3xs)o(`IKUL*p+>3m!Pf_F(29tGl%Gyrb^7mM9R99Ok17**p2ez=QZsL
z)a?y^{drDXRbsig-Js6H=}qa(Yah+$9q8BG|5x9u7oV@nFk6T&lkvp-WKq_lJV9BX
zGMlm~<@c0klsS}Qe#G=N_xOKvdIuR#Oz#k-nBLcvVtR)u#q=^L#q^F*is{)wb1z?g
z?_A6u|NgYTw=<qt-#aL`QSPMNN6GF>b%1g=<;Ur0?zR8sbXGB*m`)6(m=1pi)zgWk
z6w_HtDW>BjRNRYJ-=h}uQ;lKv5Zy+`)1i!~tV6kpvLWS{l%jo40;O2DTPQnFZl(M<
zUCll2-<<AZ#uL+BLMf)Zlu}GLic(B>8Ks!+a!N7XXv$*d&72L#8A`+;6?rIwAsds3
zTXIGKA`y>t<f8=IY-lF1fQV~yg%Z(7L<aIv0&REpPq2kEf)RyWEv8GEhCGx&$Afu;
z9h~8ZD5M}4WiVvpwM6_C<{LREf$>%1Vtkn%?^)CDjA-P|WEmvpmmi!Z9N~uu#6!d+
z<)a*i{2<NYh+xDZ1-U4J4nNj{ZuFxZ`qs3UfeV5Wg*YT51NkU{PIs0Gu23S8`N>5d
z{UVmq*oOLnh@Xsxh?^{ecovf_yb*;|T!l72L~}SJ0tv`Q3G{mM8TcUz|3Bt~EEvT4
zfnqTA4tJ=KfJ_wP4U9QPv4c0Fkcdo_K*TSK*hLpaAQ3qzf&NgoeK;Wi(MUlK3ZXrW
z?E(()g9>p-MGgv44wK=02OJTA7^EQ|CD38VVg?6@ILIiZAO}S#M^q)|(S><L0y6Qx
zo&PamB=dsg%FH)J+dOwfxbhoAI`UBp{fTU!b66gT_A}9xc@d01m){Vgs`ERa$M!s*
z-!Xp_ME*ug74=7%igNms7cedQwb_?Bz`7paLz#~v6yKx{p7MTGe*3&vzKD6D-#U`-
zqZDnL%HY6j9d^`~aE9Y5ew5Gn4E?5y`94Y~$_z?(%3Mm3x4?v*t~qRx&u~}DSR^77
zMbKWtcTg%QEf9W-ark4BjC4pWr#?h(15=hIk@90c#%%iYA>tk_gfeZ(8;Qun8<@T%
zHzHi1L<~}pgF;BJAa`;N$TjdER|D)~|4aVAFZdhqF~`yu4J+DKiadY6&iyCn{o|a4
zdJ*|ik_|W?z##fJViQC+j8e1-83U2uZ#3hK!B~9k<h*}!-oL+>_fNF9@71oNjsJRn
zlcLS^8cNY_Ihj(lKNjueeHxK(jbYmuCfaU`@pjN(kKv-tdIJ5T-MMHd|0VsRZGJpu
z6k_l(58mdwoIm1Yw}bwjpS(_`|G+1&kI;Wy^ZF!Zj;8-#nU8Ee%l41tBpb%E|GFE_
zFwsW4o*~ao!N<;k-)>!qt|7x4eezyY`W2ej^;m8r&9aMeyU=f?d2Ph!jWyHg#<1?1
z;r%HcH2uRUoizQ<l%qBM<0xG<{hpLQn*Pd6PvlAX*v)5nq~^V94A;@T7r?M-n&Dzx
zCH*rsuWK+)P0e`A85XS>9z(fa(=YZ>1CRo-j}zrEj)hN98p4BN$<)E8cJg``b|VEM
zHcE7QV088M3@6Gs6hq_{i$*+>k%mm<q8JwZp$bMOc)W^q71kW{M<ET_(Bm-G9myy_
z3Cdwwh0ntl;ut>~;ut>#BEBOR1t>ur$K(Ylfq2%5HpktD5Xam3C_*W$Ii_}i3;dvj
zc<_=*4bDfPgbFDrgEkAU4-;6!5zYuk1mcj0OcX%BCewyDln@u$@?czx^Eg-{9O=kL
zK2){&JW5awvHq<QjCf?C1m)1<_hSNc#BsqV4}~a&c!*Gx5z|Hv@}XzUwh4CxAOcZH
zK|1srFg=7L0p-wRpJD=YSg_BDL@dhTz($aYOyol3{t$U0bsAIOaEHi`nSw%yTp(t!
zL?-l_GHsZltQlo<mKFAJM<#M{6-AI*Fg`3`3kP^37}1DBA~I0`M^n}-B4OW>_mGB6
z6u_Ys>ksY-Kok;@j%?(i1aDy2ntcS!;Q((G;0+ATSUxzm;WrLHM4||#D2Gm4#)AbM
z;f@GIArYy_MQ}U57lkN+$i=U1&UeESP6$AHN9x0ZZ44$bhb{aNjs&D42l*&O3CdyE
ziRr-tj&Ok=A|djPB_IviD8L)&bmlX#KrD)&--ThYwPab4jC3fiSSE;^VueWS%J?XQ
zcQ-zdM7)8xUS^GSNZpwx5|NK0nAtFY@DpVZ)-yzYuzZN?UY4*&B+^lYGDtmHPj<`;
zl97%A==b3o51dfam;FjVrU8+^OXTY^v8OJfLJFk*%pXL)E@y~*T?Fw-4iLGxqL4O-
z`Wejj4d)@uBhrxrl_UKS*NR-7m`{AnTNN;ZZ5GLJ8Od@X1=bUpA4EW0XBF314PoKQ
z_d^LsZ>EJ<<e(gSKGcgZ<z$uv;eM<Glta&-brC>)1~Pq=!D$-XA>wcq+Ch8|>=A)z
z#0IksLp%gdCxp+!0ddHI$oo`;Qj|j{lxaW#b6CS3PH=@El<-zkS7DS$L?&M8R~+Mr
zeOsNz#MDrVn9K*1A~sUwBNE3$?<qwL>`$84k154*)H_OXJoJ`Q93P4Ni{e;H?&KQy
zPp$!N7H*PMiC+f4CmYwGP!Y;s5yvkA`UCx^P4x+x<`dxR6`~Av4dZ{;&=4<IkKkZ+
zuhQE;=r0oh5TWhk;~D1rADjc=*YW<Dl`6Ipb}i~SVGfDZdCQzu*N}LtBHlk#RF_+*
zGQ`It(8k8kBh-ybbfcntec1h}V~05u_>Jz*@%|RPD{`<7ucY+zXJ7bfT)2DXijNjj
z=;8*paEzh)I1lQ$^op4fYe@6W1d|2?c}@NMals9Vw{>Eg2i4yn9OfC|@1<E9bquhW
zx2Nj&Di)EK>iH|96uI86vy~~ddi-?Sc~QTC%Z~MU(0XEFvE!jT9{m$7M#tK^bh>+B
z*OVokSJV^Z4LCf;>h*Kw`@rs<riN@DQ0wc;smJto50M(Y&(U@2lr=|=cP%fj>UieN
zBbz}7Hs)%*9I5m5xAV-_&7!>)$0rJ{yy^N6UdL^C`ugdWxo$4Qd)=@7;;c(X!)`-^
z>oqh^+ri&_k!w_;r8Ro?2d&FZcV{H#Z2!u1=Q9t-W^bo09z5A*$;EzwHj57NcT+vR
zMaI>9XTIAyqbT;tw;Oh4H9fZRJCm&!ryg2fkbA+s<l#(mY1@nGHE+Br<XDQ~uz(G1
z&Lr1ZwSW8T%b8irjz1s2X5#nF+Q{*)v#ioO?eiE=Ub|<T{2u2&f8J(XmByagE5=fP
z9CIkNK7VffUgdq`!-T=dYWENNE_z+aH(u*T^jhdOF7x6S+s(>(J~79U3az#6PdABr
z)q1EL?|SNDiuCV{cRj;SQK9v^>cQJf&L4YW{>zFb1+$j7biH$|b%RS6+*S>$x3=2&
zb|*OQRsTNzxN))dMu_Ej8?>c&`HZCGw7}8LwDwd_@4NTOMXjFcaiP6lOpLV<=Uu-y
zezp_m5eh9u@7Y%kX9e!*efP-iv0ID>E?d1N^T0);CD)u=Huhiiu9qA?`+qfl_V>oc
zifc^@t!`C3TKOK_nHAe-#QZCh66gEB-E8#8&nUiApowX8h(G7Mzc(INj<Y>8!L;Pw
zjm16fqVAloZ?b>BdA8v)&fmL;dQP_OxVg@Qoi%n|%l5t}y_=)gtwF}CL$!66c8v;Y
zbmVL+o_#Y^jOVEuHDb_rji!v*_gwdQ*QTcVmPtEuvp#ELkk@u<PgT)K+MNyjed9G4
zCdQkzT4nOoXkXa2b-80c=*+6ND8Kwh&ZUkIjw(HJf9|?ru_TRBPp>T2cbjq8#lh2D
zEB{pKYNOfVFI*1~{OR)jN7LIL7?WncQj)INiRu0C$JyRc|NS-eIba>#eB|Jn@eK;D
z=sx{m;J@ZVL&@)ccQb<pH}@y8kNkJV*$z_I^O}R#uD4FA8n^XX=*5d$FD#yZ(0-m?
zR^pB3J+61G`8J4aXn*v0+~w-Om%rR}sFB?!dHm5jZ9KDFPM_TW-00iPQ=TjKuW{V5
zs>7YEe_z~gvU>h%ZLv~3QG|beqvw;9+^Dwq8(%WIadGdWMk{Chd@pyKxHkHG<9nZ|
zr>FBE>2VFcdB?8Y`+4&QpI5D3Cbc{i<<vGS{M6(w{mjziet#TrXZ7Fd`w7ePzn}Cr
z=+e*SAG+8%WaoO+USGR=)}(5gHqVE;PhTg;3-``=@$hV5&g*$*x%HdHU(<ba#HD=q
zWv=7)7W)_NDpvb8xVIYSc7I*dh<&!-m>xIU{dCu|GtG*IPn`RU94~z0{O;**9(@zL
z_jYdB^5OX>&2ITmSm-j2^Fh%FTcP#s%aNroW=MP1H_T5zu&KHBp$UV_OY2x^m-Y&;
zH=tBpKdr_!c!k!v<R3i)j~Mu^Uw5_q@`Q=+$}*m<DBN_VsCdDQO%CUMwsI|2y*>u*
zGmA@WcW%_ZH}Ask-)K0o_q*AfyAN}^-DO1K!l8qg_vH~Q>hHBVW!q_Ur9Fn*vxYrc
z@zY+tufkRiD=Xi8ZpLM!4h?JlJeTY8>c1aTj?8#;w8V4X^&8uFx3L)dWydl(URbOT
zIbQf+qrA~atcGOIbS~eOH;y(t>g{UTxx(+a*$f?jw`K3?li#+h6|&;dk~f_{JNxj`
zqU;Gq6S&8bp&sv5-sh33h0QljR=gYFVzYL_xaG>S=7WbPb{X?txwzFO?jhV$k7s|Z
z(Lv(}7Ds9n_AeVe&}zw-I<GGcPIqmyFnFd;o$?PV?q#UQ3-f;ZYT^f-XLa2yMj1ZX
zkZ?L`*{q$?T<5SBeSercDS>M*b-BN#&>B`$fB%JH{m-4e=z8yfLzhECEZ=YFzBa=5
z%4pqJ7t`Nz0Wr>2jMu-~H-i$iyXh4gP0rnXv3&8_ALV#qQ7>}5uua27J+B8@mF@iC
zYteZg_xU*YR%qS2JHK_E!w<}pmf1O2hK|xYKlMhloLx3IQ<83+YVO;g`_G14%vNX}
z-8(3E!Xlg2a=h@rDqi@5`nq1#)4Oe)>Q;S!&1j00+-t(&4vANm*uMAm8m+WyeQy1e
z@5sBUJ`ec&amBp{i1oIm#y0~dAJ}!>y82Yr?Zv$}A1ko^ZuP0L)*E|F9{0S#J+8I?
z-uUC?>ggrjkv#h;k_+ot$DEXwpKiV&tF>*?*$MkDtb4ok{qb1||Nq4)OLas&e|~ht
z=LJ^LCJ}j?v>dv7WII?Kf4^>5=De&Ov#xG^w{ttsIaRN>>E1?PTtBSedve;`^R2IK
zyxFa5Z4b|%qrJ|pS=#H!?)jdQbW#0#8)-MwE9v#9%k_N}y<dl&Yp}V!)4n53?BAYs
zwCOhW`n-d3e6)|-+!S{s|MSIjP1YP3@jS5ih?08##r&P7y@x_8b)@#I1w$LpiAZXb
z*0|5-c||juKljYscd_}~*l)gY+Uv!6GS{3GTH)^}OixV6jW;ovH1);8LpDtgY<K8p
zyk+3}6M;5+JHDt%d&;h2yn9napQY^Ibzq!llXb}^3%|ZS{pHxNvZMFx?fy&Q#!!9>
z(oD|16>@y^F=<rR?D|JTE;f(cI5?DcAV<{a0XoOx+qgdbaQ&3==sH^u7^eldPHi?e
z?Q{LU7SD2;y%RYeCG~wK3+Gw~ChnT`{r1ywRbnk}JJecoaM0Irl?R%wNZzVyc$52x
zN$TUF!na?#^=r`AtL4pa1_usn(Prh7|J3;C7gUV`ntRETxW_EoCRU;}gy^bNs)+Mc
z(XYARD;3gTTIIjS9dlZyjzi^=tcuNFH1$)Br{vFoYAR)YN}BhGXTYjBM35R#swf*#
z#!>R!swB!Ll!qysQl6qzP~M<yMyXSk-=JwFsRVL-DD9zU(LM_qkmExo$<B^8R)|F=
zN?_cF;RrwsQc(zf&in1)jaX!&7>3-twuNYW7mrL7pd6wdo-JGvfp}z~0Oc^@ILj8U
zh(J6tPyo?B&lIAKUJeRT4kxZ%D-nZih-YFNa{iY8ir*sSI8oZ~jia3*9HB%!GEfYC
zb~4s*h1lVw;VPsFw4sCxf)S5gltJH>^#o@WR^oMK+5<v7Upk^iC7uUdi8i~Hq;%w>
z5M|I~zhee_xFZ5FNW}j%zEs4Prm>U!G`>{CmO68O^fA6P;SJki7R#ezx#|CFF{W2}
zPqaTzJ;C-v8Np8YW2~u&GY#N-{#Kl+h%x<paiwXC*v@rmM~RQIrGB^g4e|P~#g!H^
z?;^G|p85H$_|hUh-mlK@Lz{M&lpkYEMLXkP$C;WEGwLG8jk1Buom>NQ4ahYh*MM9D
zat+8e@W-kF4yFG~{J$>8*=Z&f&+QK5BEiS*F2iD5SF|U0=Hy?r0l$cRT!J6RjDc8)
zs$37P23=Ig$8IU_ZGh;eQ-)!d=JgmZEVzgZ8=CG4)4Ymn_!=TUP&_x`Cgm;MhG++W
z2jcnOMYxCi$Y8!7P!{7M9^o-c@C2fby68%|crt=z8HFSx&N)zpWAEpb`<RylI0*54
z^81W?iSjb8LOfgiXNHN`YvBOX+=m?qL=Zl9JLx~lyf4QJeC$Rsd^E;lJU({2>Hq4J
z*GK3-isPDLXPL%X`cGpW-+iCg#hU4gcuF_8!wbF;-3iK*n*Kb>^SGdS{ht``Etc7k
z<*TPzM)CUJ71zC&b@Z=_?e4+y_0%lmKN{yPev=}u`_njX(f`+Cxy`9lE`g|X8YWYw
zBO7@rgdY16W4OXk>{n0@Cw4lnh(SCuQ3iz;*AHOK`DFki5C!q9KUW06jPqk9Qjv*V
zT!qNNBynDB0#n$*6@E}61}Vrv5hTuo^<WH3I6>rI3WqpH7U#1%HFzK9u!lRs5rbr8
zA{SRt1QF+L%sH|tEMN-}=dFYa(Gcg*7Ti<tLrE>ht<7{1j8qgt<OvXMTvdoc0#cFA
zcJu}o>{IPf05jH^H$+Uoh}pji3)Yz(93j@<8(6Sj)3~@>f^yihk8^}8yp1`ZM;e?O
z@O?-{E({woZxG1<i(uJ^`9(0I+3rN__Q$yGZ1#y|P_RF>fHoJ0En$x|6rl_b3hEJ2
z&}qhZ!W|-x+q5~KK{%3;F3J`xD@tH$$~6~=xa?TuL#HL5fr!&~LYx`v4{xBu^%--x
zBL)euZAX0}8R;m6t2yr>6^`whHnNcqsT1D`ZzOc4j-lO!x<M|qE$K&cH@1C<q?;n2
zpNLB?LK#F{axp}XzDRrCLk_eDFwbyD0HOx*_Y1iYIphi;a>ywhnFn~oocoC0P$F+Q
z+kg}A!5h}jtSiL8aWwOUbYzcVdmqd11I~y=Ch{P;@HsfZX&k>3i0gLQ<C%A8PvA3%
zL@W}Jf^=jf4+Y3|<#Q7$p*M;7g2+Lzr8RX<DgIW=om>NQ4ahYh*MM9Dat-|ZYe1V>
znDRf4{}1#J_4>>3e{W*{C%gIj2L!k&{X%>~{el9#HK_n38_Cw7k~_x?v^;1i6$R`3
zsT}I>6%rI0<f~MejclVB9<1~a^q=iNZL*?YP++is01@(aBvS)7w;5h;9!h11zh{`z
zCzSRIrUrgK0l_{YpAHo{#!U@8lmUE)_>2g%4^?_7ecS>)rg=>E3G|t!tQd!Ac+#hu
z8jSUy<{dOMlxM%28Vm>uo96AI^beX=F;1VpgZ|Dqjs_yX)yL<<r&g+1ubf7xJ8`<v
zlH>N$CKb5=`h_S5`Y7#1Ee)WOoIlo)7+E~aUj3oJ{LhZVPwCU=(2MgZ(Q!ztj`ugE
zd}_geP5<;gqyE<S7&Gc`bn5RBvHl9)6nWN$SDNNC^Utf2IyGSE$M;ydpS&mLuPxc7
zI8>J`YKWZsZf@$d1HZLVFisidXIDS8l4JShXIIOy{NGjocgOPo(PQ*~Z|waoA8|cR
zZ`lP))A7%{bnE+L?0~!HN2c1et9LjwV)pFs-!*GB_w5on_Wu8B?EUYJmH)jl`f^OY
z98>=;kL#d)#eU<T_w4H5n^WZ96;uC5kCm67T`fPmT8>4RW6|GDy0<W}5BFj0#Qr({
z^}{<q9CVGaYO?gh__!ZE4}G{X!laAt?)b8)o~hT*vJV%}ds1jE(D|je?t1r1!@Hi}
zf4%ScMGGHZ?S9L0=Hsf*7np6Rx;RIY=BcN*{{4ct1Nu0<^!NJq=-ypx-}YD((cGkO
zxBEY?Po5+_+RQzxVGd$?j~+ZUxI3=$(}u4ilgD*xx!s{wfQ`k|cbnS}(rsg~FKVVF
zwNn56=wEGnVRl*L2FW$+^;^`t;ij0@bH1Hn->7wX<WcP&cZY1}o;6nx<XH5_7v)%V
zu^n6rSzT}ReQ%>j%0tzzB~5*H-){4~sY{=qh&c0j!2Ut;Tw7bzRg5=9|6!@qgwF!4
z0^<TFo2=P5Kh<4Pr^u_*@Ymnu8Mj@+y=52fn<}(&3O1Oo%lN8#Oypw&#fvfS+rz$J
zJ8PYV$?!_^vmIkrIn#DVJ>H19S2McRxx8+}socluXZNP{FrQ#l{pX%Hd#-5NWKQ;E
zejCo}@72>8&^u#%i{vF8#`=HR(c-4znVxBhx>`l$JG-|X8{7UXa<>c?-<z~Kc$@js
z&EJoW4B(n!<bsh0MvZRl@T}SxBkN|-F?+Ak21ot7lw;B5Sah+yxQz*ZqZ4fPEG%=D
z?n1lA9W(ElXS#b_Uie|=&W>F>N5qliw3is~`zh($y&87zmAY@!(;?T-pL{)WpKbfH
z4b4~2{8z=I|K1q$-y1tFKf79fcC{Rv-Soq|H--CE&A01&Jo0!wsNCtzY~SMOq@J{u
zp<RzcE6do02S+Tqx5K0~v%OW9$0dQozN>3%{Keem(Z4M0R2CyigVp0baCN<HY8QO-
z?2(+$Yv$*E@ompq&ECJuF&&WEZIIK$$fdL;qWu*)lpP)V_Z?H%(0k>~A1}U~`NMWO
zHd|ePfBa`xYwi__W{Q${2Cx>TxW6a5Ml|sfCC#Z+;@%=n?$potwG#s??)|Cn35w70
z?@!M%<}gYf`%P0o75(a1Zv~|huf?>vAE=7r19HqZZBJ*>HWhNrHs_Ldv?qlhVv&gw
z{9ldPmSeTK=RS`6^Z4J0)&56fu74eG{V~?sQbk)`ZQ3$Z{`widBDVU|=l6=3>VGtz
z`q#14e=CmqA9+5n=@o6s5lYCNTmy0q$Tc9>fLsG|4ahYh*MM9Dat+8e@XxG)%1rFT
z2h9}qC21AC8@M+s+L4=Z4N<iJ7IF8Y{dyx_|Epug#hjcchBY6eyGD6K(|?!po~FMN
z7r(SVi6_*fzxF4u|2xkH7vJ+oi534>#fkr;vEl!nxNtq{Q>+SmIKc&eh(Q_biH`_|
z3L^fy06JXYG)6wOIrX)G9YpN6J)Dt^GKlke7epZr##{t-M>OJL!9`Pd5L_aqp$KK7
z)MZ@ay3OE@7-S+3`ot=T81G<+=XU4R;xjNK9@`qOh=F*%b{+!wJtX2PilHDDI~pIK
zqb+i}Wupw*Tx_-AB5NdKk;jErod#T&g+0WxvMq_Nwui_qA(Cr~_-Q*7!;t&hrpSk}
zf_Xw(Ti(MPh-W*i5QCJCl2nLN<aA<M#478<9^r_BlO-kMP-ew7AntL8BMPoIEEm!c
z%)RPd6u{7ybpRD&kcl_Y;ogOQFX{ski0sX0kqtvTz8B7LM*zYRi5RG8&l2315}7DK
zRn5LeJik{R%Oc60Tmy0q$Tc9>fLsG|4ahYh*MM9Dat-{mYJgKLY102V{-2oo5M@~K
zU#0-?@C*u3{{Im3ZzJh*_Q$yk=dz;X6i5>1zuhslIp=V%v?Shg3-wXDsVl|J)5p(a
zhJR2<MXW!kg1^<NWAN)}V(`NlV|XRs0FTL`<UlYmFynQ_ut1N{siGZEMLd4RFyiqm
zMwLV?eh1C`xmT|E8Wn|D=X0RTIaZ8%{&du{#vpb60c+9omz{c^nrP-J+eFM$sQ+XS
zPjV}GcvWOekjS6V-QY&WGD|zD88HuKOiPaOmt*`xQso$bImTa(@&9)8G^NeMK~Kg!
z-P_k?|H5<0oi85lYB71=xNT$io!=lyzc<Ez&1BKW_v9Os58VRiUNZdbv*3N9k9#Qf
zPPJWkYiOhO4MyfjPlt1@@_Vk+DYQC|-Lveat&8sQp%aas)PBEwQ2)lgTW7sj&VT=7
zVN!CvMO^FWnw>(c`^vI6t!Fp6;ZkHWX<?V*f(Od}&5x{%+Y~cw&H9Ed9j9}>kw0z<
zt&l7Fj**cAv_nTd@Y&wyj;dXM{qK_oEq-uqorQLpd&d+>^5EK{LaRxrW8+pWA2djG
zo;_{2_w1+@s-fn;ynJf2IHyyCzK!FbbG@>g81G@@xle~SKNY#MlYZh!x6XG~ugLKk
zxTfD{Q%W`*8ufGpf2+hZS`=FE!slKLeBE+{(?RWSzTr{x`<%?Xu}8nWWwrjj<~-`F
ztCFN4>hbnWKG3ko>a*Xhsx8O(zYqE)xFV;hLd#`|<<iU~gHzRis&npL(TDGL?3i4&
zh3nxhlh$0j{Kbo4wiR)|N1;_}+aslu{{+KPCrx!8nml_v^3dY^Guo98eR$XB?4~c;
zkr#9A5Ha4$uU;Q*u=r(Uv4ykOpnjI+qjy~jjJx+`=z!L?B`I$jj+dl0UBq}d)7~Ve
zB^{_a{Q0=<eO`V(%ROMmp=&OW9W6?}FGy&-nd|m3L&bP+^xZGaYrN6jH@9@qTk{%k
zD_@&`b*Sg@@(8Wwo4oEF`<83g>e#KnACq-dJ-r7%ml^$(cl-AH5es_AG5-IG82<~y
z#d_<pBm2iMb-yS$T))x!ACElleriVW@x!(&y*hP#V&r^(&^nr?4-n%W`l^oi*xL>t
zx<t=d>hZkugOE2?Up#0~DK)=sz+uCUqa8W69Vo_&SYVyjtMXFQ!uN(f?#A2QnlQ#`
zTj86~F}`hQ-q>S2xsD`RasPt-%g(Jowhej_w`Z2Nhu-)4W~X-U3+cXLZ2ZpZb!s+h
zSi*R6jDN$sDc*i(3*AFUK3$<Zb$ho7L+v<z|Gm$zZ^%6!h1Rj{)y@y^U{|@PrQ_j#
zr>`x05m=l!zejDi6#t=$meU)uAFs<jBZb!Xnzde@dl=|7xX;rK>y+_^(|z9f1l)cy
z@nw$_j>~R{>}Kxj>8(=Ub^gpfc3adi|1demUykvYWBlb9|3qESwXNHox?gT(JG|az
zz1u(3aBH|>db^GvoDOnqdQE*iSty-&@U+dE2G5%M_5aS}?AzfB46heoN;q!bc5{Ho
z!+v?(1Gf|Vq3A5blJyfFFPk{L_AuWzotJD|>>K=M^Wv!Zjtkbm(K;K?eRuWrTs|LH
z^Z3rd7^A6|GbYD6u6;Xi<>VbkKYn@bU3l($tD>4bi$Q%nbni{&7iNh?d#~@;i5>dT
zc8JZrypfNaCbeJXe!W_YlTWUa(}0UP3ax4<4XmygAM+#wciQXo{ruz@|BmY8H95xr
zjPDcE@X8N+Ow5=v`!>fV{RWHeCGJq$lkfVj{=%d|$;+($_xq%Ed#kN*e!hL$vG+9}
zPcPZR^F-9+Ej*SRer$KWUTym%wY7FvH0rYJP*I>_dhDsvHLc3#v{}WqH+4O4&ba(^
zh40yCs_^Ia4`pu&o3Z^wl2+oJSH+vFOkOu$wM>$hsHa!FymfuU+i9m%=Yqp#f9N}*
z&zv@k>um~oF=XwKyPxfM<Dy-pdU_}Bt)6^u+T4Wu*I&5~S-T|s_JBTL?!LCA*3#bF
zx2;;xl<Sz=)#Eiin7G6{yTR(%=@F~9F0S>3@{}CoFV?Rd;~(tXexcs8ce~F$TD(!K
zh;~5g^Tx+{FW384Tk$BR>!r0%2S;0c?|ZaEv#2|1+dNZ(3g+c<8oE+_JUOxOddw-6
zYn${|UGuVPww<THY5w`7R^t|&KD5Um{p`b5Ji|wQ{b0q6x^88a?7q7^SoeJBoz_9m
z4o_)+xLS|#`-58Q4eauEy(CRmPcL|nK`W_;v(h&G{3eV0D-IQu54rtK3oS#duKRrN
zA8ERV^HueE#dpJ2ybY={|5k>!^4JX5r#5%y{y4Z@(;v>S8yDK_#rY!6QJQlM&G~9`
zWvi`KUf%9Jsie6a<1fef%Q60YHkCZ6xsc~*sn7GezSlm|ZPz(F$Mg;#4sTmxd9d>O
zplTZ`HT&w(h}AF4OyAL7u)g>m)tm7?t=9gQw_jR*cBA8^4t>5qYWn<sv!b1@=JN-K
z)Q{zOEsSde3a#gkf$>rImF12e`nH`<20MRUXMal4>ZffzizoGQ>z>p^lD<@r_s5R$
z=MeSdy+QRo!(YehPor6+9^(X2)}sujq<N;q<yV!sx5%Geb<BS_{T27{7(l<6j`&;v
zMAwnQ;(lKzN&`wR#i<%ovT9VVDY;*%VjRhiQcRcKnu^Ob5>==gP01xRl`G|NO1@hf
zM=9<da#>Fm&3DPU0_0o)D$dOkkpq1@wk7x>7MUo4oGXAf>-?x9kcb?VK%XC&1)LCo
zXrv$qh0q>Gdv7?v4=ThV6*(wGIZXJ0TEY<lh(Q|iQ34$&rUM6v=R`#z1vw}}IihH&
z;NrqOA_18w#Q#sZ0t%m2#25Tu$rljtT3d=iBIHi40l5a`8jx#1t^v6Q<QkA`K&}C~
z2ILy}TQyLbH$RR4Un@q|uV@>-g6ne0Tr}DR(cXIprD)Ub-@Kx2`*Pm@zmg9?<S~$Q
z0`Q1*)~$FZv*`ZOoB)H^CjL8l0SLhtIYuROSi=F%a7Qpyh(Rh0xfbD#7$hKr4YeF*
z<Oi@u8B96lb%HxAxfbaSC5m8JmG=>jWTeBo8s7o&9QX`4F+(cEARpSgd=A>x85a&v
zAr*xvg?Of+H)4>06o@<lirOp-yb*;Al%O1OY<qdo=AN%19FdN4=#d{F8KqDdGJS|=
zvZo>w<y4r+6X1?um^Gvy;+gE)T<bQ6D@49ukte_oPLLGD-oqJ%ZF#R9^#OM(KLr`M
z+L7<K;Mx(&Ix(%zJf|DMNJJVUxEGd&Y$&(@E%F2;A`MYCEEft9PmX{$(6MD6Ao2vH
zAOj^Z<$|*%Y<p23NJc8x3ky*SJ3GD?Dnug=iAY5Ta**DK&-JCm8yNN@zC^!bUsat_
z#M{W7Tmy0q$Tc9>fLsG|4ahYh*MM9Dat-|T8sOB4wj7l>JK@~L#x*F^HOO;{t4E-B
zS4-azAJ;(tX;XbdruhW8dW9%MUBmd_H8jM_)gw4q-K+HW5BkgKe_yYFpim!m_`i*0
zYf#CZ^8~3b&y6o4CELexsJ~Z8P-u{^Qeif-jbeDP(m&9Dw*R!rihe<X!Tte0A;h|y
z8o0U5@N)A|DntA|!<0Uu#JZar`1u3``-FTtl)PaK_fQ7#9pW?0n;W?als;~O9@9J~
z`vm$-Q&x-<s`QqsGtOB5Y2HCILy1>6H5d>SHqG0kB7$8^rw`BW`rG3;8tgHYq^?qJ
zb-meD7PTiy6F5)hR8Sg2nL|Sx{WE$Jy>1oN;pRV0NmY6TsAKH8t^OOGohI(Tih<Kv
z^=C~Thjn5~JYS5sdw0r%CL-=WILtG^--|^I@$m>$=LGQMy?~1MSi*|&#W^;M&G;cc
z%CL}WZZkXr!h9<71=unCsd{|PM0j0a(lW4RhHY7%)4Xn9G5_lP0-XM7rsdW@JUB#5
zN)oaC!T?P@i1TvMwE(Bv>KuULwS`VCQ4j9Fu87t)HtwDH&)0vNDW{<7dJ*MccKQoB
z6=gZA7&ul;OVkTztQEt$|9P1D<Db^mu)k4Py!RJ%HSBNH)v!u`t}C(Jy)?@$auteh
zFAFKw|1L_g{_`r<;m5_E78DTVHTBP%!Qa>pB=vUi>2my@buRKi*zx^;xn2znM8$mE
z7DB@UL~q6VW}TTc|7Usqq+)*6>-*2!&R?$Yu9}<@8JgwhR9@n;i8|-S+SZ)U=lz%M
zzGAs~zll^wKb-P6x<4(iiZ}n-HZGRIn8s_=g?hb-b?`C2g&o&?MEC1?u{*Dxmx`Yt
z@Bb_2p^WLeGhf%)8xRNi(`n~L{RS>O*5g6ziG{_EhwgavPqY{vYwObK?txuXmPpbG
z8uamOro&^bUO!j95A5D)YRKjRwZ5*LdQ5Nk5UIiY99^eQSv0cq;rfO`>xo(NPM@+#
z?~E+l+)UrLs7K+^=myEN4~$-z)T!5keQWY)hulYuXZ>OM;o}iMZ<^&{zJFl(hi(y%
z5<86b&09Q26_#ug7FQri3)RzWR;TgTKUi0NIp<>ETGEa+W?mh8)Ov3fxT;3m)~1VZ
zEK8E4Q(UJ}X!%`;Tp@kc#jN9gpQzdkd|w<aa6dD<)eRq0r|oG&?Vqx&AJpHwu5p8E
z1G=B?T6aiVwHc>7E{GU)I&Y$K`N#pQ#y04DG?&<bBdipK*3vAm>fg-GeljckMfQ!9
zGUHbnZygU0xI6Q7h||m(`F*KF2U{^-Z2KCj$8(LR$@wzmd>K)%<a`<b{(Ko{oW$?)
zb=8Bnmz+QL!u*#NOA2N!Z|QpHSnCFtF1W24RBvsy@$F7<&DLIw7qnvM4ZkhJ2hLkq
zql)f@M$h{nncLF3aOjF^O$IOR>(*(9B>l+sVue=gm|-!x*2?%giRT~m*?Y;m!LqSi
z2byNxyclrNqPgkqR+6-p>&fJMu=(m)=OGiNv(=~EF{)hfZPqQHpR4Pi+LhL2>bi@2
z%GO9yhyG%`lsA7bug33v7X9zdzu`4md~fp&0Y<9lQCA{M^E*tOJNDeceP<ucIj}zO
z*z3##_LX;1CvyIcthvs;qaMDTot<>1=C?!EA31mL$tv=UtJm91htcbM?5i0YcW%Xo
z_^;X<hP*Rd(oJ>QaB=bV@5h@@@#bEOm8j>qAG;~umaMvURcCkXbA$9Q6KiaJ-+aLK
zJ-cmon-`AOx+Y2c)#E9?ob~?b0p01!TI2R#Zy&JaZbYq3dF`IYXEX~9I%e8x56@8K
z*i50du*0oQ_ovLUw#`d9t9{m}Qi(&+rZyuFFKWK2Q_Te}w772*s2<Oug=c|IWv%H?
z^_p(>w@xT83CSF3Ht;~Vs(l|FuE?vQr~bR&t%^r0--A1|V*8Ake`QkQeE+wbjUM?K
z#diucF^vxKA0kP&)yrGHXy@FUTXz1qXm<4@b(^*f)1O`P#Qf&nIw^<WyxqRNJAd~b
z^u_$ic{&#Nw2QiPy1vQ&`R3V%%eY6UULVP}9XHo`u(QU_YuVoSq<3@lx;4mnb*Q%P
z(ymb<jgFjUzwwxM(+Vw5)u<7JzH2mP%)aNk$GbK)&9_Y2k(>2d6N9|AQ+uk4MshE7
z;O`r+!7wr2q}3{ur$+n2wynz@^Fe1;wMF^mH*zj@d~j6hk^6Jk4T~jdlzMt)vA)}k
z!!8b<=34ouN>>}r4u9c#c;HW$??0N}_Q04l^Ocfx#ZFA`QrCAq$7MZjwp!1yTIPg=
zQ7N|ftsX3kxofL?X{O7|e?^{-8|v-K(C2`4bn}seXT~=uxT5>?gMt5=3k@Z|``yh9
z7TnyQG~(Zvr(=-1p4S|_cD;2{)wr$CLN8w2dSUVOgZA_EvJ!7J?{U3j&9_0Ei2l*@
zc`R4|z5L~-Lyhb<$>WdKY2%sYa{A={=SJUVp7LC=e~sggRUPhRaa=q=YzOE1_>^b%
zTQRyrK>J17UmmQ{P*rw%-khA^8_U`}TvxL5G3OTD#duGHx)`6nyeV~SjdxGnORLqK
zwsBwoTK$jTnRO&7=6++V>EuJ<KB_`%`TK_9xfX{m+D85O>bLWLB&+AI))p(p6Giyf
zH+nuv$&G4zzwsrb8yEL3YP533&-Ze-<yi3dT)jQ}<mUPRVrkVNsibOL?%wf1T2asU
z8rN96apClsc5$|;>p5>!PfzDT(&HL>^NwA)_w(irKCfE6Olo;3%BgKu_^HWV`kAH2
zaZN&fUh((yh;(KfRA}8#SeF0&q_;trelGve#m*r+*Q56O+TF7zRm-$_KGc2sIyv7+
z?~E4@&j#kao@bU@zghe>-8V;E%6DJpx|4c4(5_;&Z-aZQVQ%-=HI3M3`;F;wquoz;
zEj!b!X!yjrzsUJU<a{G?z7aX!$Y*CCURsnr!DzxX+SxdW{qC#0&m&a}n{S$|csIbs
zX6=M=%avu#2M<r|GUmN<ajQ$TA-bm?&;D4WgT@amj?^gZUp9E4)sioDUSArV?%HNy
z@JyXL<sVdBZ&Z&L=Kb{5#1A^p>bhBsGJLQh;dIopSv#e<&S5S3{xEk^0@sl0a<NgN
zHLR%q{tLtUpF4Tc_1*!8E{BF#zTeP&ZG`WY(YmiLroRp0?~(fYQ2%P*3`)@MrdMb*
zId}8L^2KL=>^SR8R7`5XrQIv49JbdX=9Ozs9AAa3t~dI=x6vczp=#HXrarrGw|U;w
zrO!`9oOwK8|Dbq7Nm@i3CWY1%{fDJa6Fv*H3XBV!Y_ewK{8V>Eog%MJ!(V@sXWVv4
zQ)1%O)5|H?V7e~jtLib4j|~(r#<*_}`+n`LbrvSWE6vY#j9KN(HFNcNBj#Ss=vL?Q
zx(%mtAE%$)o7Tg8f>HIKd*1B1qGgjg*^@c;b5?)v-_KvyaIl!aq|L$G%$IKder#j_
z_a!11j65)EbYq8S)y5cEH;azh%X!a9^?9<_cP)}zKd=1Fh)Nr_y!zUHPyQk~--xKc
zTX*NTu5<W-dD1dF2g}e=TIZ+UXqL0f=4MLLjZ@8i`?sMTnXwq}=-xrO6BgODUhFh1
z>!ydQ^47aY?&QpR*6`+th1s3H+&7=LuieCWi*xHf2{!wp#+A1btKTmFV&Q}VW$78#
zQ=W8eJ7r_;al1v5^h&+n_SeX2G2K9SS*_r?YmNp=pBXHfbFEu^gPAcuwz%4DR`Ayx
zXLC-d(294@$X^=y?BUtRd1HODN1NT+da2>i@SDMV^1iw!Y1jLKdmL=5TnDLf#__wo
zin9eh3o0MGdF7$&tx30BT?ao)QUtec8#a12_aD^X`^U{U@<Dz6TlMsA8>hNe-(NGD
zLMy-thdU%*Sz`O%*K4%Ws`a_`PrjplvHCn9YuvcUUTsrf%x!nNhhOL!v(RIgd}I9W
zHm#ZVc1^*)EPm&`)yL0UYJ4+b@_}8~t*cK}-Co>#^RWWk?^d50YrV0@<Z;g%+~ZpN
zSB*sdbt;(tA!$=suL!H%9e13Vvd(k<h#%$+x_SNwsfN>$9s8Kxa`p6*?ns{f6v>5k
ztYc0}%TG67kk#5Y>Fk7k7uLO9`u_N=1WCHA-d{;M%EJq`n06?7e4@#ehg1Bo?D|j5
zbHa@`>hJTTBR(&%iZ+SJ+oa{t-6Pw<;`sY@yE5lx?U;3S>${!XCFzoSy-oKv`r`Uw
z{oa$)=ALhTZR5>uU2A)I{v7RfZq3qOM|RKml%$L5-`hyLnO;e+M_sP(qv-uQ>|BG*
z?Va`=X=4BOtfNi0sn_Qnl=G|jxXn#*H}XGUJlAB+ff3IGdygooC+Am@^Q-);@~d=K
z|IUlOC*C{pZMVs*dybtP-s14rC6g_dyla|nqkOxscxRR+*W3SHd01XZv_FTYU4^>6
zMQN4)n(u^5z^Yn|!y%SB&k4I~RWYx*^q_i6$*HkQtCA$yQC6qqmZ+)@C4ZV!Eh!x+
z?I;~7M^X-_6zw^<#G%f&V#YKy?HSbV9K`omW|#>?$049fmr{IQ%x@et?Euv61H}0H
z42y>7sB-oE)}`bYvc#V&6_<P@n*OVPqHI8^!}s$iOx1#t?@?J%HlZ9#si1VDY)0up
z*_<+j(v)%;WlPF<N)B^WJ19APSBdrsH2+u6ANBL`e!cqMxtKp~hVj0-BSb*GJX{V^
z=b`CD*`0SfQ;OvipV!=D|IN>j(tMu7WA*1pYd$}Q(y1!v9Hy0|68tCUkuiJ9F+bAy
z+h={1enca0COP(~Ka*L+M!*q%h(J6tkdJa0a(rhFM+74VDab_$bms635{^$xP!4@o
zj2T=Ij3~q*85zh&33R%%{@@BF5}BV|<k9~I#x}GEf;XZeo(ow7ea<;-;f*My;wrQ`
zM>B_bR%8SckPQ(7qQ{TW7Ji6As(4M?06)Y+{5W034;25Y`DF56QLiXqM^O$1$Lw}+
zhYAVEL?Pb5m~#X>cq0ml$V3SY9ocRm=anITX#(4%E87#CQOG_{pB=M3l!##G8G}Tm
zBNv4zgC6@IGuXo&5r{z|5=OF~kjyknV5-HsLImFtk96dt6#5hS{yD5G6f;gVWg0v5
zya+xsm){|xsxz<im`8TV+4I>Su(S0;!W-6W7VA^R@00#GhNYsM*U1Z*KK<J4n;meK
z_pO<3JpHLB_<l<9yjc<VR(z9XXI~?pksH7`k@#D=Y;>yeop6RD_hhAKe1?A0#Y~&h
ziBiPMxl`s+mLqKu`z+3v%wdas-gBk&yT$LAG7*^&&)wBt!tzooC@oOPGKMo=Jo6i?
z%d#OIG`N)XQKZNFlp?k-kunX%eC|y<>Wlt-7%yd7h<c?hCF3fj*V>W-awpe-Tmy0q
z$Tjf$YJfj!|0VvvHUrX3$TMlcc^*D?cNrGjnrFVitZ79X-S-Up1s}U9^nVbq8%t6p
zRE8FgbHZ~ETX^p*WggDs5<YfYd9NS(i_dGiMEbWQ3I5DWGUYDJ!fZrf9u^=HOR)^1
zOQGC@y-3A=i0%R3`4Fpk{W;d+GhRny9sTPex)NSL!83^NO(Xu6u`E?k72+hW8l`A+
zuS0o)*SeI|k;O1ae9WC7;^a4C6GS(RQnc|IgK-$mvW>ymPwHC?x5s<5zze*D=*%eF
zz#JXX8KV0@S(#~QqpD_F0~pqy{z018gL$nBLpU=ZW8eY{bVggWgXp?YTA>@dYle-Z
zoQ_b<>j{*un21U6fH!tA{p+}kk6jA=w!GI1qMJ<VkExp1HK;p1)I>*gLKj%U8aC*G
zp6CrxzkNhMWj{)L41fa$!x6(U9HOg5SsVIjfQD!U6EsE>G=&1qAo5)_r@T$sg3=T%
z(F(262JO%uqBEeZgZV7aLM%oUmSZJWBNksE4jYilwBsqiL;^(j>F4S)Jwwz(eHcNs
zffrpHeuq!FH}I0riFkunyuL_(J}$wJW2`_dMAbTMuh2zxh;AvvH$ZgLDZ?;J^Lh;5
z;iCB-@%|O2cNN$0H41POw{RPUxPu>2gnPJ;43_T!WicM&5gwxiPat9yME4WR(USRp
zMEMxvIWhViyOz?w+lXzNeqD@c!taeTiDBRJS+VZ*8D@am46ljmsES(9Lp4-^xVW;9
zWjcU^NXLDqUzy>T=)a7sxQ?G0{tUgC{s+o3i0$DpDlz_fURUNjwdfb~aDaK)haCt+
z5I%N0=|9TyEXN9nZWO~tV=TtwW4D|BuReKwg#M#At{EowpJ(YmjdgtQeO?!9rkTkw
zH@L$Kz7X9B%9EP@Jj(O9pn3hT&fjvL?I~ZgO<kkBq3OR%c~8?{iFwh|%#WB~J^E{Z
z^7_A<yTy>t*8Al1^;lQ+@v$?YzUpe~tRcf2eezyY`b8cN(bZ%Aj5PBoUU#A2O7q%?
z&l_u|(T!o<HN*Q;I%xX$vVMlq@1%L{OgUQ9KaSE>)9*>?qv;p<EVMP#72i3Z;gOp6
zKF!_IgXQa~S;l`fkBj(QBmPc^{j=B)h`(2&U*vWXf7is{3b9{Lrd~d^lh?bj8z~Sm
zaiTMa1C&TcI<k?6LX<;X({w>P%Av<`hcny}fN(@20mTq`U&0ZI7?i?})4c#hARES2
z_&j2fh%^+S7-f*E@;3s`@P-nRh(#hqKA4Z^uc`EBAQz6Db4DW`$q;#9q#EpZpny57
zkq;BjU(I0+Z=@gtImkyTv}>}wFoPwW;EHg>A_w|h#5RFBtPzDg6ruzcwYi>v2t>o0
zbrg<7q#+ZfFk>5ZMmQ3YhHT`c2x8leLL5XMnsnG1Gi|64jcn*NpnhQrk&ng>-Vixy
zvXKvqhOAShAshK9LNUiq;_tpVCQ5@iKJ-I4A`y#JWFi;F>{lJ(jX30?5G4rbZ$vio
zQHYf0lqf|xj9V}cA`ydlq$3~2D1*2-ZUQsd!wIekM=Z2kvR+|}a=5l)J3}~PA#n_>
z2V<DR4z37B1fr0LROI3+iXfTsy@*9BauLUMAnmsN#-M;L;*pFrWFi;E&~C?f!V-3H
zg&!heX3qB_4v9#GI>!%X33S>suL!oFK9GX~ltSvn_6AFYBNBNq?#yx{94Sag0ra~t
zuh6k%9uR<VXj`$~;0j}Iz<478smMSMicktYu2Gx89!_vYIAW2CToj`W;wFO$tYHs#
zL?Fe6X+i2i{lO9ra76%Okcf2Tp%5ZRk)bWWD_FxG&hSPol97!9ltNsyHitcwP$3#|
zNJcKoq0@`$LIDf7AOI0aMK<zK2*cjYE9~J1C30bGM_nMl58vCDWq}LgkOOhE$^v$9
zf;;@|nGY1A6w&?J-e5R@^$j~jp%A4ghs!`dgF<)@VtYdhN+7OD>ka1fL#P*s>(1h4
zmJ{3|@|R~rF_d{hEQ+8%jA5`H&NxU$I+RYV1LUC)X(JdPW$+%!=aGmvFdM}>K{`ZY
zFnuH<A4M=5&Ah`;lw(*{#3LWtW2sZvBNFK-LK!3%>T&|}f@Gwl0Q#=f51ddkk@}j%
zG!THRFmYquBM18Kj0-13c(FVvgozKc3Ke4D;7dPZU^<1WLj<B>Ih8s@FcbkSKL}Zu
zq?x=2d#J+M7Epj<Xh%>daDZYSivmByBM*g0R#Bo9jti+X<e?C0OIWASTgr04G>Y$n
z-DhkUh(jLqm$B~PhzO)18@bD=_h{w;b}N{7sE`L~C7*){%wP#SIKl<q2u1{=5Q_w)
zARWo8`2HA56hnJ8za#yMYYa^cnBOj(4`^OLr4+B_PObsD2ILx$Ye236xd!AKkZVA$
z0l5a`8jx#1t^v6Q{`)nc%}1vEv-AH2hmh;e*UgK(dP=vTFlBI<Qk@Kt@A^;92iQxK
z7cGVR8KSd*sNZ&|#Pti+*cuXVxlQ&_y8T8KsdJMVGwyG6>ilRGIp_4bGQ#zk$`xZx
zq0j-Bo}{0faJ^Xb9ijij@2Eo#IR(=a_cVuBsz?|phKc2<7#0-ZO~06zCX${(3;G>8
zbN^2Andadc;NwPSMlZ50x=rKS8}C^+mh+;?dC{7+(JNt_8Ok+GE!(9xRz5Dc+sI%?
zhOYgk+xKdnS$;~VNAC$f&aIowukn37t|4+SNugB~?lGh7kP%z`;+L(TwXEShzb>Og
z3vCzAa~>h*MU(TQIqJ!I(f+7;(JcMM@3&Iw&!aDS*{!_mTxFrP;|yuq^;&ak4LRxY
zw8;vE!|4v(f06T|$$8P_yl6{0jP?Jrqs2|bGd<H1b+wAhcXn?(Hn#m&wEI&3y?pR<
znbA*qw{O26v7pD938p3YZpeAj#QtSS%^q3Sk9M#4;ila;`*dIal6d;UslA_HwsCw_
zePzMBTC@vjWGTiw-Ef)Dwmx6PSeTwmPwmwH$*bd5`mXv5tjk{ohd5Xbd`X)$j?EQX
za$d9vt@gxQtiSl`TEA28oT|~>pqHqZNL8fa^%o0fxHWNGI_F}_%*y%3i&kvjs;tuF
z<c{!-i;vNMQC-iwrZrU5JCWVHH1NaqRdu&j*{&12>W7ri7aVChwdH~~{WjD7(Me2C
z&Wk4JMHAb>-05Ezj`-nZhqGT~Jy`W%{n2u*2m2MLKP!%!6S1Y%^F&TKe^PIM6Fu?{
zg$^rSWNuN_K`PE`)Vt1wO{O{fj#WEQ^5fTS*I3XNUH$ugdg*ZJyM291&lkvf(eA%8
zDxy7A4^ht_Ha=Z>@9SL)9=+bsWOuDK$1G-4DxTXzmDJlbZdm+U6AwxHp|=?C;mAIx
zCVMXaMb3*R=S7qAqRDyD<h*EawH40Kw@*9vzUJfUC0mH=7%cXa3y<Z7AKP88SKB^G
zZLQrEjk@eQR1~O~9($^EO{=mwZD`Y0YmgXkbH?STD}2vBQ-wdTe<*uP*o^HblC%=%
zyei&YW%9c5D%#d9QBSXUdF%Ryx6@9k&IO0f{?K<qpE+$7*V`2GV#wMdcR$<j#zoXf
z_4H2MTRr*Sw7CiQufK8~vUW-M?E!th+<k3Jt);!UZ(FsXX$Y}$>hYQ$OkCof-C%X>
z^oZ447uWhidCI2YqMp}-tjczN@U`endqETR-&Hv;nt7(X$K{0|X723RwR1!q*U;7V
z^8J+b?OqK#_e$Nj>FJQ`=TE+#xX-qI*@ot;XZrqfbwckx#LuYLTblu^UFysZ+q?8a
zEx-4+ImPelg!V6dxO3*`$sR3F9vO8)lFoG%+rgpc`yG!Z_uUfezx1c*O^=;s+-q2B
z?4{FpOY7suR%=(|I=P$|?djlXi|>7pc4!uLCvBT&N>IVPT<#sL<Qz_+HL>t|%qf*?
zoAg#)^RjBTou|KP{`sU<;})Dgw8tR*?88>Xgmn|+t(Z~Qt*nyWcb5n2o)5j#I_TNq
zDeVte>oI<RP)ogmUEZ!I-cUWg;5`Pdq#n*n+w}9BEbgy3R8T(T_BSoG46VBE^Syth
z=^9B|qduScZrF;qK~?78%FtFGo8kJ@=FZ$72e)hb!})dNLYuufUo?;ztRucx&Wjdv
z!Jvl0<~1jhzKv=(@gA{l)}mgFPmR>BKX&z^jIQz3SB@TMc*8YpX0-`x#u@egE~Edr
z(eAVhR*(0haCM|fuU|SE&wrqm@X|B)zVoSt_oFSl#-&dCZvMuE?!@7#k7FA@Jk#{2
zeMM(?M#y>58Z<V$Pb}sTQO`%;*mS>ewM$<)FWSE<FWSE|-x;U3AMYEh?<b4=Tv`k>
zh3J~`HmAz!ykFuzGxuZFdAaQ9*W3%{{ywn*e2#w-yEb)KpYg<fV<Sq@te*SMDozE}
z`Nn)G8}gc4y#Mj}xiTveC*n)IgD3Z@uM*1vIX4$EOT;wExw*I(&9R<4R7gN33L)p_
zBF=6+^@229g~UBQOSm8y@yNv=EjQP1<>eANxjyFO61li6RqXpH|5gqzk$)>6pXT1u
zW}hkYZvCyCTO!}q|0KuO$NXA<Ew|P`E3a1S8**wvdMp02$emmRat+8eAlHCg19A<>
zH6Yi(e^L#IX5=3}XqJfk=;FGo$g3vWl3PQx`4+kEMEmuwn%Do`TvuZ1zc=5N$Pe@D
z+=B-hCUTDbIv19h?*FxXSYn?49XYYY_sV&(NVQQ{)CB39*q&=bbjukQtr;Fexn9#R
z@?U+L?@ILlwVYRaOovTWvWF8~Kr>h=2JzrFo@B?hrf`(=qqF29UNBV1gve)Q#_5&|
zVvqoF?wN@k&M|d3ue5{6nO_2H&LNeW^GK1WS>$GZgO53x9k{sXj9{cgUzfZbaD^YT
zVOX7E$g9EhSpZ|Wzz^Y2)#Uq;hk#m~4<i@F5c#J>-l=$q{eu%C5Dl^aD25^TM@&%&
zed^Q}ju83PoZyZ;h`f9v*Pl0HkqA>RPzE3l$*|=@WdI_OiBgD*mZkWZlPZ9?fq3Mi
z045Fj9z-A-aVR7nMUVZM9h{&<GOnT+kqVX*r4Scat&xagyg_VprVYIoOdk%d_)est
zxHZdW#xlYchHdDFD@x6o-S&(R7f2mgSFlA1EIKkz$nDO1Hq-|kdoa&PMjAx^AZ^;}
zi2Ok%b}V-vwj=l<9w|`vqeKRb`?LNLj})i|u`S^$V!4J@3W<9NdX8)>@J2iepfi-u
z!vQM9AZ{4jF|>#C87Jl)j)+Gt3Q&wPNFx{r#?TpAk>5vW6w`w@s_Iw#O%eI-#NQgZ
zlWRb(0l5a`8jx#1t^v6Q<Qn+jsR2$eq)Gqm`2T5ML4kom-aeY3|NrEe|IV72|JX_u
z>x)w@b;qfg<kyJ*=4(m3<>nUbMm_{}t*GPtE5`bZ|Nj){U&dQ<?0nrJa_qbuJD+Vk
z%POtYK92$AwR^V7?{WU~=WWJSY3!N3Vl1hcIe(-L=5yosD(@Q~CJa7SyMNGk(d$CK
z@me>c*FvvxnHRs<ZdT6q9?pLiT5H>%ZX(Cd%dzwCZ2qXR^VyTdb{e=%d%SbDV}t0{
z;nlZYI}^}(_?b2-ahp7!Y|x9>x^%0p96P@wRgRsPW9Q}A`L+kfq?xbe`8;-Fzj3MS
zyPo5+o;F*pXIL$BLc*vN+xu1zmc`t))x9*+<>k9Pu0{71<H@n}_Ve_z5^pr`alK>B
zw?UTVS{NwmWqG&Hb3E(4?%MAcgQ3a!^S7K2E4gyPzC#nK-SRb&SGsfE-EV*x&oJL7
z`Bmi?-5s4rznWiX-I(%`a_qdQms(q_6i*c4U*G8YBqcYh?fu4=jBZ@qyQtC189(34
z-6ozn5vQ(apWHnEUo5Q}B$ZT+%iTLZNGt03UgH{TH!hqW(=N_7bv@69auU<id64wD
zhTgnmSML41d4tcZRxgv}*m+Sea_oFR$=m+eg(m~Y1X?-wrJe2+ewzxdo#%9pM^@YN
zg?=B?OMC8GtW*pec(G->Gi@)_tlg|zWKU0GiMY3@(7N_G&#Tn5=lSL(U1I8cod3#b
z)VMuID{Zd1!0m8lId<N2-t`;Xcek+^`enzm$D6kJykD?W*L87IyYXDexTXI6KIob_
zy?oxAUrwAY_`F5#)A4Dq$Ny4yfd7HLgXP$HId)!-otI<h<=A=gcjoBcLAeta*|c8l
zG%V|;hpO_{yGQQi%zD=F=7@#aoxa>RpY}xE#CVHy>plrK`=Z8`w-Kw~F8^ZTgaKvg
z8P-#tbZk3iWA1UgMUwQ2wi*hp{WY>$OgGS7Rx5b!nxlczX9i2=T<aF!U}nsZEv|N(
z75p{NFIC5c#=B?aFO7Wm@a*Hfu|C<O&2DYI)Np9{&EP$GU)|$Tnm-V_OuHL}*1H;K
z9KYMEI9t%Opz^VsS01|Fnsm$6b?~z!MR41;VWVgB{9N_-x{V2bqZ4fPEG%=D?n1lA
z9W(FAvGbz-Iu%U+khCeRSA^B>jyq0FS?4)_#1HcZ-8}z;RKw}Wj(yw=Sgt-_NV+3=
z_ERJm*0GK`DJ?(Ud_h)g+oZD-_FY)_cIo@$vl4jrsI{1$l%qVnV2f#oqQ@tiOnErP
z|H`gl-}Vdjp1s?B?$P3nT1B*hQm@~~c`w)dR$K8XrR$}&a_szkj_WSc4osmn(r%_#
z((6%|>-#8rzYaUsU~_w?eMg$uzdh?{({1YYc?XG;rIDUO>rHcItF2XD-tIi9q<N@)
z!kR7?V>W*?+dcGP(i27M*Q58+Ua6}Xuh{<kkbu6Sfv@fRAMhGcQ0eZ*+^2KLK2ofj
z`Kn>!iG8b?p8EH@@~hWJ8!UbqS#06#HK?Cu`RHAj0^{y|89Jb~ZAr?ThU0m*vU>f_
zn%caTYF$jV&ms>uaBjaK`avH#c3#wTY4XUF<Ieiyw{B=ORd-S4i0qP_wJ&Upo2~tS
z?41u>PUrvsPYT(vGMiYq5n>^Pq>=yGQX!LxN`KV!=T>*b!tLKQi?y*~GG>`rCVxJL
zVcFQ)*p_Kq#-?rluURbQBmAE4bKiH}$iIC)pWk=i&-Xr$p1tmK&ULPH{X5sW&ULQq
zeL}sioqH*h=kryJ=hIk!a6ni6W%rjC*w@^gKHw+6UuUk{G^wQ3^?AqR7O$Q#=k0Zj
zB~!1D!pm<d`wn+l)g|i7&%;yKoUi$hnUA?_9qpPO*~-c?cfL<p%O5{_I@Y&En+3lw
zv#s&Rpx<L&|8Jc;Z+!o%+DN~3?mWX%^}J?P7?P^5iE>NSmsMx%q?46W3@)P?7YRB@
zhaAX<Qm8+Mv6m14^1Z;>kOAAE0E)pTm@%T@3f>R|I!J>|*a-zt3^pN@Z}5Zw&_XI4
zu*P3>3*<vF*oHE86uck+q97Hr;Q*9Eed<Iv$oQUcLmm`^L!o89d$A{DQ=cNOAqrB#
zGT)u@M_bPeLO>5IAs33kGT)u+m;1P7zWaaQe0TTDHc9|k7E20PQoxb|mK3n0fF%Vi
zDPTzfOA7qAr$99#Xg>cxPa@2iS{b|k4e!cj{=a3ue`P7yL1)o!kYyj5XZ*b%{nGfm
zF6s9Om=?=?e?{>nZTyYt6Mzmk{vL@28GnyOBaFXgUa*Z>8ct{XY~#L~Y_~P;>p_41
zQy@zW`{RsmWL?Ma|I~bcndiYP2i2aY7rF#^J)<~U(Qm><RS5OzyK{nYSOn6SR}OAG
zYW9Nw2!|N@9JAp#ltOw9=2C+Los!NF09wd^d?<oqkoo@g2}lrZff5N+E&8@V=J;=e
z63{)2|F9Fvp>}P;2~Kr5Kj^@&F8w~Bg)}Gtnd9#TnNSKE(%cn%s1wp)8|1-kI#RcQ
z%=0gSy`+07*wCS>gG|^0w$vx?;0<|TC-eHj2a3S10q1~lSOl4(Byt`Uf*tPw<lBH+
z&_gbif~FDS0#BITn7%wX4yEAG1pgrg(!g0mJYf-J!cp*U#y-dZ_vZKwIgks*Ejec^
z$}Xg}CT>syiZk(t5>VRUp9|>=#ZV5J?Z_)Ag7o&JCmaWDclN;+DDfc7%<GqV{(+$D
z$y|Tf2I*eJ8w#OzZ^8in;LsO^5ZKv|{O`{`@CT<slqE<3clzvPj(;ZPJVRLlTOZtl
z9<pI46ob=X$|QLD8s_+Cp*enp9ZJB<pKya7(qIW>LJsVN>>;GxP!x(m=K0I@tImHS
zc`S=11uQ9GNdZd=SW>`}0+tl8q`==N1$g}6`v6w7;%Rq#1jQ!?#gBbHC^R;_t6OA3
zL{MyW-1vxuxQLjbumoLVP!j)x5);CLLbY1?8518C8WRze9IKPV<N)=^ph?l;5n)lG
z3A*^$q!?ZF*vY#83$_3}lt<KbJZfdg-`A1akPc}sJf}SVkixFW=ono@Lhz)pM3QH0
zaAZvAxJ1<^0FO9TEvij`#}#{f4STn820yDXj4K3dL&rt%od$b*c?3D8ZjX+O)<uWL
z82zlK)KK~u?GqI7+$l?Y0>Gn|(gxj4n2HQx3Jwk>KZ8e*Z+*$PfcU|ZZ+*x&+%{3_
z*(J-tw=Wf8)3YxL{H*#CHh&2k=drg>WgCxCY!9C_K#i$<Tf*L6O%t9G{H$WMrn3&y
zC8+zB;9jR56BZU_+R1toj$4Upc{Y~gD#9oSvWUM~sPWjb75k0*a?rGThGY9hM1~SY
ziLC1HHaX7d@9@NkaP$4m@i&V7w(7Bl?28Bw4mWraECpTlgU2yrK2*3dWG>s=;ztO2
zg=bJdtBU<eoa$zea3kmQLRT5`G%+|SE?UiT`KRW(A#J^JBmHxJRtXV_M21zRuF~E9
zY6G>Lsrf5qpp@;l^yfwJ%&4*c-8pM*MCq8T4cyxNxb2-;J&Ha|YnU}<^YEE#I`*8g
zabZ5^?=9}!Z@j#HcgjDPPY!k2G_d?ex0JJ)?MFoB&v`+gl;xPT<fx*|RQ+pKuki<;
zyVtn*!l6EOm3J39hjr*t_ga_OR~~NL+G);_d21Bqi>JiDsBdP^SKjaJ++kBh>LW8E
zFZ|<Z$d^-E9f@%AU%h2;zjMUnhI-z`jT_b+(0zYbi|vQepIK}_SZqI>Iq=@HHq+lP
zG4%IntlPJ5J!I7N0Zv^mHrF&ivEk_K)sNKbHFy0lQ@3sS;;hEy14ZdbUyjB)WB2|A
zHBLT1x$UPL13LEp@np#MeJ#c~{T*ySETN**SjW#_dnD>@zk$<cK3u)lH&2}Jzhi1k
z_oBh`Yc_d$ZlB<e?<&f#^p9z*Tc`V`*K*fo)XO}0s`rL(!yC>Uv1*{xo*xgz9CB^$
zbc}wvRrH-Pm*L-L)8SS6-!#^?Ki-&AtUv$cV^Q5c{L1f*Mf&S2e{E~~!%r!Dp8smU
z?P~{_lQB-*t?awEo<}{;i6@>J|Lsf3qkGqBSEt$j1&#Vy)jBsirO8i07F!MfTWvKQ
zqfb?1T|R5=)F0no`|GSJ5AArgY0D(LDaF6L{P;_~?CoV&R<G{<0^bGgEbhEpj6G^w
z&3eMQ+D%tPyRR%SPRJeVJaBWj8hy@gzZQR8OFy%nxC?yIZEo%w`!62)v)<QNkKg$8
z-FL^;Xc4si?J)}vfA_`(ttU5Y)m@2akL-@oqv{Xa=VW`v@sHnzZk<!`rA@W1H?H>n
zYWW*a(y#nFeYzU!d(S;ssD|&yEoGTo)@-ihcYb8|-WOk+91=5e>*2uPd|Zn^JG!#*
zikh@j)q11MF65hOjhBT)9w-@f#pU5E)ecWD96WY+d5U%O<zXjweL}xF{mUBb+O`9F
z?R>69mc<6c|FjJTE8eAOtmjV2e5+~m8H2wK^GzP@I@IpaXW0+c)14mfa{SWVwT<@f
zXKvU4akusTdf_9EdEe-qHgRs~`A(-2%DTL9s-aa*LED(^^_LCjeL&JcahEc~eM`@3
zbDfH=)$j33hSyJ{p7npHs4Vf>$hMP?talhkTeypxxNEX@)vs;iFDzL<*(S91XLinC
ztlgN<{ml^>Yagmt=ZQwexcj@?R@kAY%h$al%5(e9AKpHu-7K58{_$`led+#bFXU;D
z%xiOIaq-&Uc;~`98;$k3_|6XdzgwQO>fx)uhm_Q;6Sr(*|GNEm|2%oen)H*6yG$Tm
zdWpN2uQf_O;JWpYXX>w)8vT+T9`#jGNaE0Q^J|S?-EGuhFWy<+uPuZ|YWsQD>Y4}r
z+Iv-d%FSnc-~ET@U5GuMIladt!P(J+H7zGJI?p@?^?td!PTh-NpNS27y7##^7wa<W
zPlzash&lHA=!-o*_L+C29(7BI>fbB6UjkkVS@ce-Z*<Z%r_F=h2MqCwD4p6W^4PF1
z&-UMTmN`{wdwkxf->=(oeU!(Tz(3#7CU_m*`osLpn#ns~9q~ol%CBwr(19>b_3z;U
z8zR!q79IHZ(y#@Q*^f<cw>zwR&E)-y)@D0&kBAD`!uMCH+bp&Vx;MAjE|79CXruFz
zEl++u>_pksq?1P)jqY`I%8Ks3{>M5GDVjO>>6iQP%*+F>#@gcx&yFjs*4JOX$M^U7
ze{QJ#e$oQp(()BwPyDVy`$l#DIhFU9UgGZg9TU%fSZuLfkUaZCn;ySBvzl=cJX33|
zw~x!7^7O1B<3@ej^z9c%HC(XUV?=ltm+ldhmL514aQ^W#igHG+*P3swkz=u4V6k0b
zv0Y%XT_E*_#dg6)&vvD6Hh*<e<n_W)y=V&^WGs!wy3K%B1M5vm+A#N<x>46W^G;u_
zm)O7P%-Tt>Wreofw`17Hit=?=aksVkCZAndecn!tp8IFo^56U?o@i9!5N6xw?bf?@
zy=qf4PEn#6XQQ#+Gjil_VQq6ROnq{HkEp~iofCI`8<`&MwR~aRm4!z)?y*&r_vyR6
zA6o<e*K7z_=JHR?4rvg5@bpy2g`0<*kL@+2__65I^b@Mj0Xai$F3lL+_=S`;ZMHP-
z{aXI<NzKoX&E0sY`ISW<z2UzhjOQ}7{~-C=s0o=X4`evnj~Rbq=2nj;n^${xb9j5;
z(vM?3Hgvd9M^WBU%kzoxiGO5oTDN)R*d~j!9A|!TY{JD6@9#}pzoGl}qGgHLwNNIh
z&x4k^{K~LBQy%{?;ZXD0%bre*=euQU`^t7#Mw_5BH-7lSVR*e&n;o`jTjw+zvE?<p
zKCXY{HM=T(n2P$m<r+|T^XPSxKU=+jN%cjp$Gq#l_>Vy!EU7lod4AR^eWM>6E6N&o
zsSk>-ycOKH;s1rX{6DDe*dBlG517?=;JjTuPPHCgblPX@&!PP@U57974D9&J=5^1%
zs3;$+{U8IjKilQ<dEK?x?j6S`tQb)DgK9auYQOi4((qbdE&q;t=&!p#Qp>wD<NH`e
z-qZS5=bJ>Rbic{Mt5JPzlx{Y?9_3Qe&qf2#RCENIj*djdzbG)iOI6>oihmEWEeK?Z
zz@5BzjYRvSbRFwu-}C5PbUeBVjYU62DK`27Gy!dCr6@e+=;fX5G;|4mTWk|B&UG^5
zPGKh$KsnT(LfU{2XdxZ4;Q$naE%|@68^56(?6{VkArQ2X3QHghc0vIZgKc-l!9oz|
zAd|c~0Qvkb0|yVv4unG*Y=Pro$8{}Ze8V9Xa-a}wC}=Ja04cB%_JYMW0eQ&9d6Yip
za_MKL&E*9lpof)^3q@eDNkDmgj&y-7PzcH>#&Sa-Xdwd*Kq=S-Q5GQpil|HMsxc1%
zbg*(L=?z)@E(V#m5CSQ<&46uC03~2I8h>7(OhX#vr{I<fN(-e_P<y8{{+xb6H$CMY
zEl0Cva4f%VsJpx&0}4RqJe>ZK?Nq+yvp65>J{y10+(P!FrQprBz0A=s05{%M%m$}9
z_>cOdJJAqSzJpi}j<#H1;0Xn6kNS!6@chn&<6!e5{-WNsC}aF~g=BHVdKSps38}#C
zAQ_wpdnURCPUChjS^y4nITnr+F55C3Sr$tQSW>`}0+tl8q<|#_EGb|~0ZR(}jZ=W8
z{!R1$SFrvPV+7<o-Zu46*g<EAI#&D%o`YGJvF0+4S;i;J_+xQv?oP(2&uGOqjyuLN
zD;`ypx52c$%kQ;j>pA@1Y_@KhW3MQkNslhZG-*KkI)E(Q*w)>+y+7)0{QaMrU;poz
zQ!iyh{Vsfco~_JS%kOpY9%RFMkVX349KZ=&ArPV<9Wo#bwm>dO9}JI)>fHO<Jk!ej
zduMP5Z-{|>&`{8QAPACquH6R5p%mm9wFqig=Xel1p_&?;8&*O-6oEW<hJy}DL7pw6
zAQ@!Ny(joUI^;sWD9?zcVDm8hAqFx)=HnNGhRFIr5JW-FBlLZM9r-Qu?fXG8WWhEF
zFkX|nXg=7I|6=E08;C86aAR5?MT^0Kgp7d{*w&D^fny_{jo~;ra(%i$F4yyEaA->U
zK|Yj2Z4J-Xpfn>)kntq@pa>l49F2lxSmet2p%8L9;TM#FOJ|<TK@09(P|(9s-YK}z
z{}uvT=+}cX0vQnKN&bTLhn0iLPG|B{qyrQ|36%9DJ$eymi1FfB$cA!o>CJKA4FM1W
zF^~+iAszI6ICozZa^WaEN*YVOCEur)I?u9LQoxb|mK3n0fF%ViDPTzfOA1(0;J+ya
z<c-yHe|i3YY;<DS?X&;G$Bs+T>U8Zf37~i=p7vHDJTvf>g+|J8t!;%4jt)zRPmGV$
zX`F|)(fDa~(Xr7}qT|MC`o_m<qhlfxlzNJjeQ@x^u;5UgE+Kksk}e{VIpt3FQ4uj(
zCeWL0m9ZO6_My5M&LPLhT=qm=s4gNnHZ+d8=&=!TI)j@;T{y4xoa{$L$A!mFN@TvY
zll_4Bq`2@<U35HS^2DFseFojbjgP%Nt9lsc)-SO#ln5RJ)rChx#ZjJnf*)4c72G#L
zH!wmsG(sDnp!1H8A1{t%PQB{*_J8V}dYQLv@;{wtR#}GQSsm0LZ6eQ9mHrPi`9FY^
z6Sv~OxBR$$shG3x&pwic`QvdzwYq@GT8^y8-19)TS@XQ>XBDM-C-eB-E4IbQgd0!t
zxMFReL0Do4Uk>}H8p5N_`*&mA;CFEUWNkw5#LyT;;w1CaqeIkmQC{M?Q`Q%lt((W&
z*&0t++5nHzYJY%+cxyr{(zPPq=IP3#ZdHpKZ?O@ek-aS?e%i=5--t=3V`ZOuplP39
zOt@*EdAP)WpDa1Vokw=%J@hKi&LLHVYcNyx#jWIrq-zyRMSg^^v#R`vs@NW>dMEke
zRk4lyFrGy6!-X^x8-wq&KgJNAyXJ@K7+2!7fnyqtHRO$)gGcWw^H9>FtFi3QHWvDx
z^l^|iN=vjkKlEXSJbISG-*4<VL*egjEcZijc-!LDyCd5kQatQSD42d$R+Po+_VZ&^
zf1G@LyU1>JTj%i=+vrI!*g~+w&s)<@^3#FshO(Rxp-W1L>m44Bu>`3{C<pA5z9~Pe
z#3`ohM#{f)rC&bLaS^IpS2MRHcamIX>UCkZeL#FdY$$<H^M~yQI~Ab`<6@!{C2Z<;
z)DTX>BNv5nd*!tl6&e>F6A{jK34aN?lYSZrqXcF!fj8OxDA82z!)8UoP5bOB_xUC1
zOuGzzx+=;qY8g+QQn{}a;j^}vaT^lui=4MZgrO`*n)GAc5bne&F%fa9+uFE`ftBp*
zW^^lI)>gO;9u_(=qJKg{9K+eL2}rpSOy?=&Sn0D{JFfCPQfJ+I9<j?&03Wb#qtUIL
zN8B0Q-u*mcNAp|UUXQ9g&q~%?fY{CuKkDM24{Go);-+wl&CQ{N^S5Zj@sf{nO-^x=
z<F#>I;v-m9>&_5#V&!%<u8thP2)Ml{F3%hMknjhvZa7~QcZJ}J0%1xcIZnp2$PMEY
zv*V;5xzll`V<jJLxi-UbJIrvssCgfBmt#%&;>B^Jad*<}xMbFwgP)Zc^GOVzln|}c
zQ4ZvMQis1_44>4ivR==4>^0It)>j(WP5YmsBa|dn+#L<&qNmYz&TQ%rS-3UeGh@MI
zg(as(UG-jibA93z86D?DX*Sd=Uh?C%#cn3ukZQfL*WicLB~n$X+qPG36KCX?y}hX}
z@in_IN`9H@5??7Zcc@Ez?@*WE*KKu)xUH%#QT?c*F7dUhx-L<}Q$=0kYgKh!BL3g0
zE|GnAs!L>FWqo0+pNw_M&HJP-sk}yf?{JM6x2t8yl>dQpLuHX`Q}UnUp)ULHoc|rg
zf!trcRF}8@tIYpX6?yH(h)qNO7gTO@mu;5(|M%p-)C;CILLm28S*nq@a^anMn6?~0
z{IzNw5PZ`$O-(9!={iF_<d%PxZ3GSbO>Kl`DXKqmU0395lVsDjuIjZe`Rc_nhI+HI
zy(`zXH{0*jM(}5!yt}%!jSyJrSH*Q5V&>NTx{fm2Zr(=Fvi(8Y2$lDzo3CpPSAgk$
ze(QCu39a0B>vgTMuiSU*b*-_gs{LSSBgng|<8^r@gd3X#Lp|P#bhKlADSrA{#fBya
zW7;YqIM&cy2@c~COOjp@ceXdV3r)nKE;u?)mk?j+?oMqESI%1mTky-tcy7r<xjz~5
z_Rehq3AYdL)}+m`4x`wJde5$^&2gG@c;i;u9Gi@8<vc0(d7fmB{Rp==k__jO_JzLU
z*vj^Wgh^~_OZ(!xi3Ydkb?5!GFH$&{*yoPJ{|1u`en?pTE6!JS`$CR$;oQ=`c;D=}
zfV&)LYG0`DD>+u$7d;Kvn%cg&TiZn17jm4u%bdw^wv!EE6?<o?tQ*=FVoohI3=4Uc
zjSTjgpI1j2dz$o`XFOiYiWWEK?Kz3RwC_!A=TNf(E_qSe4wCl0wS6{Wa>rju3%e<m
zX_#ISuG`x^rsK36Ck?=<X2&hL%W<YQ)AR|3^LTKRlQz=!Th>3lWxe2*^`CE9k2L0?
zsf~5bxNd5Ly==@U)Ba-P`fkE6=O1rO&sNl!vOdMQ-qW~0$rwLrv&sIiZdt!*T$lJr
z94qeW^+^ntTibL>%_`b-BOa_xSKr_Vb${26at?WBtW~+qRkoSe{kOL1Om%-%Z8}rk
zFKrw1=R;H7Z{DUe)&1hOs=8nG!>mnbs{8M^P3J>Aq<*`#O=qh6#s53i{j%>)b-(O0
zyEN2m*i`r5yzj5K>0D&u6U(h_x+m_O|7u>|Pn)h=MP7I5Cg+g+cdFdRC<9CW|GV;E
zuIWz3ejkShlCp;S-vJE<XX=fR>1v%8oEWD~;Fca4oM>pz$vyV=MN`rD<<HLLk4oDi
zxKC1KB)z|e=L@-?7}^xZ?R^a`3Av_2D)$WzO*ZT>-8&7oI)hEkEwv7C$GxGw72G>v
zoR8WmBkrY=Ft#0rnha^0$F<lP*Fm_Gxb}m##I?v6*NJA4l`<>mxqYdOs~0<~imRm2
zo#HC#W88OBTqS*~ifahlZ;h+O$<!t<m58uR1Nk`_WUP*t-jIK0aSD!MpTtYfb^B5o
zuMl=t6|X3^-zi?&%6&J*E1B(8#Y@ljGHxW46Cc(1Fzb?s(tfx#zOvnm?FJjE!8he?
zDckk<W3h=^!{^H{&w32nyzGGW#i6zzd@{{>F@<4BZ-qI=`4j9;U0(9$xy$FipBfzK
z*Yo5f7rqMI*{IuK?PHA`w!BN@Z)IO`XFYt%4eRfkzPB?oZ}t05YySxKX?7)U&eP*O
zUOdz{)??OI`uJ4;W;xW1oOE^7#N&&8|K!bedz$WA_Nn8lL*uu;eDuIKA;o7VDN1WD
zE{%2b#>*3SW!LwOd9%%zSr5OmY4zpra`(*Jeg3(H7MrNe7FcYeT5O{JU2URHpt9Fk
zFTQAdy7xo*Q@_(?|Mta|*G~Mf{)@81M>A5hKL16#@uvyAT=>jW+;tkUe%?jTz*@Tp
zk8be$BiCLY)W31B)_bn$reFKDXie5*v$$_Cwo_x>eL-ni>nTl+1Ri%BGqdyQqo;KJ
zo9|e#WO=&p!ljK``b=OfDLp?L>xA#^d}hxcV3RoPRK)7uKkJ|DZ}-`nL32(WUhHa9
z8qy(KQ9`?jyC#V~ja#)m)i5()N}ON#l+^k9!7kS?p7WTK*Rf%r#u?|ix6_)`Sf6P;
z_1xg*U(8<6(JpgeaHpSNou3ymaADt<o-clL>#%b}?0CNHFYc};PdyZSx#bZ5f7o=3
zOirENdtd&M^>*bgYxeK?!r4Bx^w<wj-K`(DxlxZ-zxwEvM=Ul`EjCe)9lJJUMvpH?
zITfEcGUq9;)Svf1?zm~X%ij9)c;7`^Ok<tp*<nS!Q)?eydw6g73FYbwwYxRkd1>n-
zwdQtBO?YC*SFLy_HCWt@)ejpo=+h^je|F>fTD!Y8bt-UM^X`E?FEz2xZ#(`e{qdoS
zQgh(_xohYv?#8^TcRbf%W70c|4?KIrc5=;G1?5NbzU^@8LtW^Be|CLy4)2sy|4J7{
zzT=Q|=;^qiYJXZ4J~1WvLeTbse|~rJ?1cYmo2YNA_0UTn<j%daZ+oXLbq~GuY0V=I
zT}Pd4`qBD*PyBX$m3!=%QPe^IQ#Mg=sP#dO{qK4BKU(A3;Ret1<+oAW+h>0NqUW{9
zu;IEct-oIS`=@_@+o`<<NO^ht;g1H4+q~`v_lL&okIm_|V%Jg6Phb6Fg!{4{<3^ru
zc;YeU5UK9||Jzu7Sv~KXpOvwFHCaXV+_6*i^8V&C_O$j~^VO)0-z>f|_uB5sD=oHI
z_ndm=)Y1>jtxs*z?0@NW>I*4v*FB$UqbPs&l>8kXn!h#Cw`7)!YYlJZbp8{)>V31^
zDR1MhnwyJ%{h;ka9-tGs7h)Ut+wF;0H})<$c(m8f3unHH&AU9!`M~4NG7i@&+Ywm)
z-goq^s`qo7>RmRz8Pdu(_~hcIDH}aMa@yVCy>sj4ec9}|-{`5==hG3~sfYOYY28Ps
zO)r}>^KyIt>$-Hm5sCiony*N1;hW|0VXM?jr{8BTl!v$*>sW1QR#wLuU0&O}c8r5Z
z`za^JT;27;yuueZOii6oKG>h~*GJqnZQ}m*l=sf{`S61E?sE@k{A97k`lp&77F(<-
z%^mx6JNfI<tTD>j6|^ONy`{XIJ$1(Zmyy-ZHM%rAYh=fktG(;Sc(|Usx}x2nT5aq%
zrt-YnN-bCYYpyQZTiUo`R-MQC&g#`@d3x&?KAG6>iPjcdtoB`gIK69ZdVsR!^1;4Q
zza9F=6Zyk;ba`g)q=52u`6Cr&nVQb?zApOg9go4!{nE16gmG7%teY_Z?2BccEVfuJ
zwpcB;Sfw7a*kZNVVwG|*y6A`WFZ4lewzcY-zo$;yX?Dw}A6(OF<c$4W*V}LV>P##8
zZPk8@`4b-vF17Od^t-2P9ZdYWb^IUOpKrIlW{>AK#kZ_Iu=ACr*dJ8eP1^PLt&|=C
zI?rtfm%E;vzx8POGsiw^VO_sV*Nu@UcQjq7C=1=>yr25czY<@4`cFG;bh{=7o%8s4
z>aR~f+4S>+i$^9lyKwM0&w>_PtQK3W&L<V+@H1+CRp!zCo5Ie0n%=ltR<udqe6?NZ
z+0e^_%KgixM4nDt!`y9WUT9<c*dZ{#mGa_=cO6S|+jZ&uTXC%Kr;mC%yfO9VwCgiF
zmZme#Lv?p5DCn4zm-ff6cI3TQr{KUFpFCB!*|n>AP6Kkg4e~!TdoJUU8Go;_9^m8M
zzt6Kpjlvg9`t{JoNuRIYWwFI7>C&s|v~&ObM*G^_L3wYs)hs&j$)BlhHWuz#eCaFQ
zth3)pUbvAb^moqwrN)eFPo47o`RSbHNy|t1ZLq%l-Sf#I?N(*K=C)}tFU|fFwpe+5
zG|iP!Z22v=Q>{@akmVa*)rlTLYoZ0{1ytS<8t1^Mb7SPV+H8vfS*X7BGGAsfx(lV+
z)9*vyM88Kf&|>s0RNe=!K<yb<v=VKIzKwQ8-$9>2SEDlb=3P|I?*+!WDC!&)IX{02
zRi?V^#GTAr;oSQA=x$VleuPTga#8UoL@>_PkU1sdj~o{OvP9!f;uVYTKpE$ykH(!2
z)uKu043x(a{UUTSx(0m#mANS?sGMh8HGUZ8WhgRVL(U`T$Y#4N|717aj>=V($8V(^
z?TcPVN1!)Q86TxsDf;OmC~2%%qiawbbR)_*K>ZQ4J}S029!K5K252nmfKEn9WBrS0
zBlI;C+a3CaXk&C4+5}yRHb*z0PUr_H_Hgwh2s3``$DnP|Oq6e%>fc9QQ4IyCGdd3K
zf+nHe&;@9Bv;g%)8_~zn3vGk;MmwT?(9>u?^bd3Z+J&^jo`}91N?FiPL;cWss6YA|
zIs~mzLmkVfuY(4#J`5d=jz@!0nadD@PDRI}sb~b6jgCXNpiyXb3i|VC9dtbU7#f2%
zLgUb;D0#2%izcAYpowS(nuKPe6VYsR68b($n(H^CQ_)>0Wk$ajor!*q&PETR<ca<W
zIu~ur1^E)%37v;_Ll>a_XgV5+l6U$zl)Te_f-XjnqD#>;Xa-t?0{s>$Hd0og1JJk8
zg=i*Phw``<<<q4ypGw~hCC~LTpC|{F^6L!7c>wBIGAX}gcf}a-DY(NsHGbk=>J{U-
zadqsGxF_2cCy?b`qkB1TJ=W#Ca-5VM<Je?%%(5I8%J%wlFw3{Nlk4O=RIZcn(Y|OQ
zD%Z(jRIZaBP`OTypmLr3h^|3@LghL+i^_F!4wdVq1f{Gh=h1ld0-A#UiIVn8DN5QZ
zmr$8=co~)JqYPb*UPZT{*U?<`26_OkUXAjO)<9E9u)63gDE43V-=g)=W9Vb(5aQSX
zU4k}5-$kE5KSCYR>Rb;^&}Y!*=yRwOIu>n-HYBZDqZ-s1jYQj^QK$>L0qux3p`3R@
zozc!{9NGhY5q%1M1?`D0LA}s-(7xzrXn*u;bO5TMoO+|q=pfV;eH!h8`k)@DFFFSG
zM<dZ8=m+R9^dmF?{R|zB%5^~9qW=mVg%+a0=rJ?|J&uk=&!OSyB{Tx<PdOil4o0KU
zp=b>H5*m+gLlaTCKCri|Z%IK-LffLrXcu%c>VZx}`=Zm)P3R0X7oCOfM`xo?a$U?p
z+o3O^UC@`&KIj5;FiIZlWj@X8=yG&1`X2fwnulhf%EOG=K_5a_pd-+?(Szu_=n*sv
zJ%Mtc(978U^{DB3G>+k{@_G!!9l=%8(R4i;$NW`!J-%afFXxr(QO+yJd4q9WnL6HB
z?D3NQ6}H;TYASje!*msGj+UcC(QD`^^g0@h-at*^Fpk|)2C-fIqj)P$AWP302LF1Y
z{aE)x<v4fwZ5SV=j+>I>DE4A2UR~N4k86ttv86rAy;$jhmPq*@O<4mSq(ctmLn+iB
zL%RV2AO>bb25f@@C<YrM;Rvqa4MCuTG{}UVPyoeX6GA-(o)7?9NQDDLGy~lN`A`hD
zp@a>*AONBu6|&&~ltTTngby;lC)|(+#o$oLT!2XYll|B~c4s{R(jb2l@lXgeiQoo4
z5Ctia0XyN}Ww+g*bBpbEEh_fg(@~2Jchb2p?Mx8cR^{MGf%b$TNP!I42}hwE9Q(5$
zf*=JlU?&^}WdPR*ctai(K{@yjq#Qyz?1fUW*l;I(0=c$Ea=n5N=pX}j!fCL3jyeVY
zx7u*mG_$I(<DT*;^+0vv^&@pp4a&tV$`5L?<$j#sr66|P#g1M8Xs*~OIvxgQ^V?|-
z^$L0?Tkf8?HMi&fptjr{8c}|!uWz;IZs%fkN1N_GoHGW}AR7)qG1&bR8}twW$&dlt
zpa4pt{#6^r6)cM-1uQ9GNdZd=SW>`}0+tl8q<|#_EGb|~fxlA<R3k7qZWu#k$1|Cg
zqI~LTuxIvk6W+yiroR`w`TedveT`4hpXS6dAoIwZvQGnp*spNB*u5LbZ_~E}nz1hS
zz@A~7%*7Ww70Dd?Pq+#)H(l%~iQ2O7AuuhnT?gjp6WdC1UTdgsbSvA+ICnWTCG5>W
z#v_;(4ZpjB%v(2o+n@zu5*s8wgiGconzo<ix6EIE1C@F4;%7_T$((qZ2S0#)17RC4
z^klB1%u#H^KA8{di(egD@VpN{G3U88+hk7cV7BKs<~<E*SEse2JOVE@z<>Nc0dM2q
zS7<&Qgm1yLtYTkZ=ntkPli#ah4MY>BEOZ@AhAEH&(_jY7hPf~gWXVR?!v@HKO(4rD
z&Upr2Vf{6D9Tvk<kfoS?zr!COi_F1%lDNs7Q9t4*b1dr-uSa1XaqC37G-KQUmTx~i
zLVnf*({lMy$|#tYdZfdn#<Zx9K4$za`yb=D$IXtlCym68yey5_{)E}Sru^0z*B`_G
z24?4I*O~H5y8X9&`$4WdU&j7_ENQ{DDt2_tzyBb=@AM4_IYa|q;1407hcw859LR+O
zKv%PJ8f>Y%>_7uv-~)jm@6gg93${TXXsGzypdavFNc}DZ?`@R5;Al<%6oi8o_Cg_?
zhEkAD|Jo1*JK+En!f}vq96D9!TyPZX)92*`uHXYf5C!rcSl(@A!CuIRqi`CepUkEv
zaRGV1<pSOi2vLv<OJFDDK>?J244#nh9`=I(knd7RKUpU1gghvK5|9A~jt~x+PzusN
zRvThqC!B^d@Zz1%A~*_m3`CG`R=9%L>Iw%fq(Cm@LlKmK7%Q~{4IHS;Z|u!z#O4gR
zgV@)}BcpApCmg^DVju<5AOqaF9^_?EI%Gf|*m2Ehzy*9D2$EqoWWpB6ha#v=8Ph^8
z$oDYH!GXFt5N5+7@Tb1gLpJP$bO+o+K6o|cc+f)u*l-W44~yU^*isKVKsFqOVsNG0
zhk#a;dVdjQ!cnMAUFivO-${d9D28(A*PLS@6ShDh)NX-$@PX4##GC8L6{4U399nUY
zfxS?>HEzKNlG~Eza1<O|h$EzceA}X5JAOkNi2V?6NQP8c0$JeS2{(`io}Gz5q=REm
z_CW|_^dd}92KD>m4+Mg1f5HdJkPSsp0^0_nATRWS1`$Unf)dy}nD8_A%n=H~&5v+G
z3hac_PzKIa1|gt@<RPR19Eake96O9M0V$9TJ0TAWpa_bg3~T}@L*NL`;4qwgd=`a3
z(1Fxda&N1SO8ch{D(##esI(gbP`S51hD!UU8Y(tm?NDh0`J&P$uq>7ou%v(`1uQ9G
zNrAs(3ea3t#{Omd|Jc}1&?RYa{{#SrY9|I`Q$JMw2mt5!Z~hLz0HaMT8EYp?OOSNc
zKt0+4UTv%ub_EBA%6AE(<DzxZp)t`@BCvKD8;iB?;25zoPCEnF&S({jY9~u<?)5YH
zrGBeT)`u9^&(ih~`%b2?$TN*BH9^9{BZV^TQQA#6g(WHOPN9*oa7a~4h0QK`jF4|Y
zVv8v_Qf%AB7{Xw(5yto}brE;6NLZq1AL~tF&<2wx3FE@pey{VH+v8HK#W(eFM^*9n
z6XKtKi@y`u{viGaR^jhw_`A~F-$_!mAI#sJD*Tmpe~y{Ip<%J%F>w#(udQS(i+TEr
zzqw}qYRAQDbqNpVZ%7sX?!n)DGk+)jh45~>gTF=Q{u%@PAo-SF-H;B9i<ZY)MaIUL
z65bM{zvCiw!RG1UZE$|;|B7<$&z@MG)x<V@Vp5Dw9Ez<^dDai)Tv@DNG5D?89&=+|
z9C01o^sNiiF=-sLhW&51RqFxu7|%N#V_wdspFkG#cwLnIebP{$NW3PQrPuw$>%A)C
zwTSRZ|AfTrbA#XajF%h}&M^|N34C;dB)@08N^w)fGqc6!n#JZ?UK{48^yVIEy)16m
z^ba<7ICXZs=c)LVR=+QboayKkdUb+!%E!Mfim4eyw^ToIH+1<|6ZXFG{R?)_%$XY#
zQTW}-##4T8_trDvd#viedhOYG?pD*fiMy0u5i6E#KCheC@tN;>*9d&dDtuw*qTb6Q
zTRiC(zPW5vZAF>iN8Du<T~ZvApYb?+eTz@%;qig{5+nB}&T`4xbar%6;G`{DMQPVn
z+&ON^pJK7Oc5tZ0=Gx!Y=Gw<mQck~{-O}bviz63jyu0YFCa-_LutkIPX)C|&{m;?u
zKAzlQ!JG~jn`;)EYZjYp7Mp9HwZ5Gcc=2jJeemji@R>S2_PC#YZ~o^$dVRF9*2U|Y
z`@i{O!)xDp_*{Bu!O^RAJ$Qdf16O0cztOyicY42(?&|dQww#Xbe!sN4i(Qc24EOR&
z+63<|126v1*;4y(poH(`Zm;Eyee81AzSr#sXBA9;`(RS>_uuqu-$Z%x<%P4q@6J1l
zr~%@xenCXmrD_+t`veTXG`-&9XUm6<YPCMYb?Ko?hx>kU)t`sSzCFd=Z2j!|KU|nG
zF}O+a+!qdIPpVenFl+vbRl4d;_Pv|DY|bveo2aJCy0}J~$3EWMt0eZu53fA>PW9Ec
zi(dIW`?VQ6T8?iyqfOrx|8us_mZ<3xaUehXx?7iqYl>?uIk4fmc<a>j8yp^fec8+j
z=}#{4%vs7i>Zc^WyH?jc=-1w>+EZ>m+xzZ6Jnus6>CEXp9tqBl9;|6Oq0xEXX;T(7
z)~oB(z4-N+*s!O2pL=t$E~Ea0h_Z;7W518S*yCfLc}JwzAVl@=72PiZFNG|6C)GDP
z>6+8#LGA;Fctw;>Z54TJ*q3MfZ#&C;Zngb4@6+$s?YKV5V@%+m?`RXe4sZQoerC<&
zov)7gB5mc@wtINynx^{q@PG{wX=jTLe0yowg2?R0rnlQ2*1cx({zYrE9lA$E1#Dsd
z9S>C+>!}kyC>rwlzV=_eVX<k}C7@3k^N1<?8tb)R+wPuS^X)h6dOLl){ukE;8sCA3
zT0Z$@+i&VT(yZI;r^Yh2gLm~B>%+h0hm|-zb+CDH=k&)z55C`E*vR!CTCJ!vBY1nY
zlb0GC=e=7Gad%_cxdkUaSU2PB<u{wWS9jqq*NIlAr}ogV>E*P<H{*53P@W~#^PU;n
z`-^d7=Uo5z;CmCw&VICL!?6QNFZ&hjbN(rM)Xcz<TX`tt!Bu1Z$;F{17bYs}mo_Tc
zwt0DTo2{dsE-$Iq#ipcZ@?!%^N+?$~yNkQ8vwj^LyTd+e>Egoj??#QjTDtR(`9;gW
zKYn_~#O2-xBUUkARz0u9rkTa2nUt5n*GAUay*4(z!T9fXj$7pO`ju%5#=YC%*S8K|
zO+Ij~%kesV`-ZZmu|82&?SgaW@eMz0vRyRzjOQ~RC-R5>)^ts~S3-WM*<#=Ch0IH4
zJb=c!=01x}voBNAb7H=IZ+`XdGS;L6@9#C%-zL2J*zl9#4bJMe);zps{2wR1R!kc|
z_x#5xU;Z{=)1Zv{%wJZYr!6+kEH=%gyjX0SS!|j~Ik4C?`!;sTiMJ95wDv5{E^G80
zV`tqZT_%rj-b%kXz2-}^w>J!EHzVy-@APl%AGTky@Z&X~q&_+N1n=`ycMe|+wRwER
ztFv}?&3I_R@R9Y81SL(XIcnj^2E9Jr*?;8l5XM8P?k*I)I@_`5^$rfxPg$?LIQGEF
zfG=jAOmpkHBq#3E>C0Bqw)#VD*EK%#Wz#=59{*}>N<^^5rkTa2S<4?kdOFs(MVke`
zFSD)j$DrS1USGew_*9*l*r`#U%er2(+0kv?*Iqu`+TYmz&WmpUsJ1k|=9^Z{-ak9!
z)r+N0R~hH`xRmF|CSKc8cT>w_7u{Yu(&5|oy+8ZV>HNuN$JYkAOn*Az@kJTfL-7%J
z=Y3)`Qcvp2eM0R#JMGg3d{A#w_L^7EwH<qUOz+_CYk2?lmg?^BZPUz)#~Lr=JHnRy
z78^qRRoDiji$Tw$t-_;<o>%CK7fRF=9*OlDv=4d#bp@@_AG#)PvyIjtcj6CS8+u;H
zDLnG4$7%SjHy%e5O+C&Er5UC!8Z&q4cX8Lu%-zbnxNC0aF6S=pNQ;W_<=(|z3p025
zcX8Ls%w5r4+&LND@u+EfFRZ>-m3)zOllQT*Fx*wOS;Npx)kYItJbD>J-UY=z7vIk^
z*k0pRlNt~4&-gyJO8<DxrTWJ(T-CoPQSpzVx2k{bQF&iY_q={DVfk;j5%WJ~A4Y7$
zh+P<qO&G>)_od8&#U>0F9b?UxKn~<V5tM@?W6fm@x(~!aI&6UgC<a@9!&r20G#pYP
z8}i^dltU`lbzmUvFIWk=@ZW9|CWAVx03O5^%>CGZxtHx1&5PVCA^9ifTQCSH3${U3
zHea?p#C!tW?nMj0VJ^pl4>ns;ARF@FI4I>diX*r~0B9i%vLF`<p#*HN*(e%t2g_nf
z0ZR&4Qoxb|mK6BAr$99VXg>dcodnp<Fiv{`?*l((%y?>J!}#h~SXbxsvM%GIUu9j!
z8^4aq_~6CpLU;q}G0t1YsxITVj5+<2-!dk5DeE$}R^Ai8%<t1|Q^&5?GmKB4&o&uT
z{=a43xY!POkh$ZMy#J~B<Nq!5#-)ti?>uqo+i(C^kY{*#9;cbDXdwksVF~0wE)>FP
zu%T`42yWm7{tyGnFdG&@Hkjs%m-5?&iv?TB>fCWxGz75mtK`cz#`ya{5G2zCl(FtI
zAG{QDXb%@b?HZgDN<c$rjw`H$d?*4pA`=ceC<U>V9R<lC^Rhj`2ht%I@<o}GT?#gg
zYxRT}$bf7p2AO;913?f4Ib3%~!H#mPfqsw-S+ETPxZcws7i12#EgeQW5PKJS5Ki7?
z!%-*(2j)b_KniSQY<CGba_zgoad33xH{>=Y-N8Y_a}(r4In-{(JY7(l6DG)TVILHM
zV|&63$*`y+=Z8Yb>5N}c1}<*o18BjW&Ka$A(7;hTXx!Y{2U_Sy;YfoF2z-iXIoJ#3
z;MtS&Kr&=O5tM+;YYy-t&Jfd^V<8*L!KDw!fj0y|2*f}#MDc7L*bjv)*b9wFbE)%c
zgVdRi7_|l}b5|ZhrA}>%$~>LAsMM)4uUO{HG(e^P6uS~qugW}Q*>71aDPTzfOA1(0
zz>)%%6tJX#B?T-g@E|E*gX1xOdH#P)d{}5q#O>4nWmb8ZZn8E)o&NvdJokT$aqj<d
zD?_R`N9sajnC8lJ!N`Xcb_E9;rvB?965>K*f+G_mB7(K?G0|a@Jv`#I5ecEX_yp%R
zo=I_u(c|JG!ZnFe@d>(~_#yM4ozdGDjn_st)>G{5IgL_-XEQ%5T~u_UoZsG_M;^t6
zm(6}wT1Dm*4>g8UU(Mi?c{ufWkp4j7jERpM*YjTr+f>eJ3fnqk*mOKQ%OYvVqpkW~
zr{1{BH4hsm3nnB*1V=@LYJ-{CeoK<M+&Q6pdUzOi{&gP+)1Bv~SLO$g?n-+#ewF!Q
z$2L#1IKN?xbAVicEaq{39(N^oi?byEUy13xjw2lR8^4e$;`b+o>ef7Ur{6;s2cR26
z;n7y{<5<meX4l1E&k+xgY5#hr-tRSLo~Lq6nexz<{v27%<ESN$UU!S*z4GFYF}v4+
z_g`n2=b^+W&R8b%jPYqpoFva$!VuyUa<};0Ty@>ObcRRhLc^levL<PE`%-x=Y1nC=
z?vGQqiF?Dfq~3pmwX93{BTaQ2eQC0ohkpX$UwOCi-z!-?JdB|>r0@NN+dO?u;Wk_&
zH-|gH7;bsTEel;=YPz>Z<ytAaTeu%2-4h~WB0>`*<Q!7w-Q~w^OJ&-7vClm1&C~cm
z6=9V!uNifh>-yelToJ<i4WD@$OZYsDX&ER5m!$_t6-$?(+NT&|3SV$c81{F<BebF8
zB7!56;==BhCQ5~E5V;qNtz7Ck9l03Is(KIBpr6psDci&OEn(?t49n>|geB+Zu*AfK
z>aYo<HHPLt7asX;nJm)2khJLzYF}cIG4CX83{AV>xX@Tr^4z7&{I&Ek<&_Qn*Rq)B
zl@)31UlE?zvB6<U3Bj?U$)?1)bNTq!!jfVP3*E`;HP`{2OSxWIRaj`qNx`|Fuz2Cm
z$7;DTBrL0H88O*wa;I-zmiNgU>DGM%eV6|764QBA+fl|$F*n*It!&&&7|O(h+n3&S
znbV%~urEUWtgMtqN_BguNHwpWA`%kf6N1C27vhq%?3ebWG+2#gTrJ{Kcga2t_XR(z
zxQIz%NwJ}9knPD8+r!2tMMg$oYDnE4f;OvgFM;f+Zr{fCKTPQm9TyqTy0lmQQ62bM
zMXT=e`0Yf$zn@i@c96jt;kLKeSGcPz6KqnCi9##G7^8+!;uBc0Jxrp3TWfnh<EJ>0
z=5@I?<3_7#q56@^{(5S-6CxtR;*;VClw8YVYwK9B!QGdHOSYBbR_wo8?AciC*;wq^
z_?=z%p?7!t*gDhZO&I1gWa{z-huaRYnZ6qP_x-poty><<Sh4iASG$}#zd3DEgC$2w
zt=^xe_|ISAF~aSK#a-UrN`1$>IE{5$m*wqlyfio<zUNopTwfG+EOX{FH$Kh#tjU+J
zoGWQR?fqta*I4zh%r4}cX^oeKL>?#^bj9W2E7cB9FC08}cX^6+^W|YDc6~zq!@E9>
z^}s(Dx2<RY>+0-I8((?9(aga)bB|8lH`Zd$rgi$?)t*fb?~pat?R&Ly`*~UYpgh-<
z9vL5$KK1d|Ige-N_d0WR{IFMYTerVtv1enkXJfHvW3gxRpR;FU#rPJD_1r0$Z#8W`
zWAL|OzR9CqhuR(bEc>B)y3@m5j$fL)w$a}G7P~hVyEhiQH?4ewPcCknveEM+r`-+S
zJGXA$m(7m*jh=daK7GQSc(B)4e_Hp^Y17N*%)H#*|GF;SZ$zShyXGsBTli*qeAp`W
z(&_i<hwu=0V;!pv&C2RHqswc1*N$=UXg}q|n5(;9m{<7XhN-C&$_MkHxTBA_Yud#9
z>nZP@>+|6S>)q!b&iJW&^S(-Wzg^$_KJeLCi`|>Ahn*<9nso9=qtU&tPFd02*Z)}O
zAw@F>Km9Uk*VbFo&*KZvjw`Iz*I&KI_xJgKZm9i!(gNSo@)ciC{H{U!Ms@!=mFHtG
zargX=iDy479y{%aBdgzQ<2v}Q4yC^>e>>vZjJ36b<}~$sj=qAQ28z2=T{9<?Pb<6r
z@mEJ*YjNP*b6YMycm2@;(VI6seRa%<nX$bMW9c;38JExe{P{nEQo1ymd*it!zmDB{
z<H!)l&b8jlC>=jG=ZCKdpPgD>X4qcuRcmR8m0#C`n||o?+^m^r3cLU0HtDw-=Vv&-
zSz`_z1k=>;Exk75%7EVf7o)>I`EbL!*RS-LWwCoB`C+kpGjH-*WokfDi$0%E9kY`1
z_o%z1i|_HrH+|#V|Lc8+f=+Dq?!5IGw`*^9e?2Ag`{A`N9olw<4y+~Wb7TLS9}QY*
z)2((<gK-B|94epl)vp~UTkPIwtiwKSk=6QqwU35az4`W~5BjYynDu4k?@r0p&h!|)
z^Z6;q7{}lDX-VfLTifot+UM0b92*v2+_ULq?=9Udc5ftIEOu`!c5kE{SnS?d?A}N@
zI59r)kL*qBHjf<JWO0_`%ny!DxH#hdy=m(=biZD-EHQnbqD<mtl*YOwYiRcF0K4Z_
zz4^rWTC=L9>@CiF{ep)>v)4ntuAO@+6E~}vgQ2nh;DE0B%kD2Pu&=o}eZWtCzs_8@
zX;Mk6>+_DsEnYog&fDwwuH`f0uJH0(%D%%LR&|N`^7HW2HRo&oW9DNnTSvQQN4BzR
z*w|wC#$xxT<1d@nJ^v!_E!BRI0o$MLa{0XOT5R`@;}cd4sQW>+oL#lwdq!z^Ew7e;
z$2~77$_3tsxq@-bn@s6Z=LE^HE+>%1$4b%5__)ESjCt}!O~)C>pgr($#_?h57%G{A
zWPZL-{O47w5`yw+M`f(p`HW+%9{4zoVLXO9-sjfy@vRQMyzY-jWvr9d?0jB-;W#h+
z2r(Ylmfv!|>L{1Hy1ZaKAKy6DlTFH0lvgCmG_)l;9hLO;f|dUUe`rFR#-pg?R3tny
zhCs%w$b!uaHU2N5yc$*Jp)!u;Wn(zxc;gt6zjQp0u8MIChdN&1R{K3|IFE#<11jar
z73DR$(h23Yt<3k6>0wG2RMJKKGmgWk(m!|HiGMv&@vj#u{`E%1zrLvW*AF%Mrx@PZ
ztK%zf4c|cAiGNc5#Xl+k;ve%5RsV*fG9F_XYVyxG4x-BNJ&HT=uOTY_HA2Nd<~FMS
zH9;kOO;Pbru217w2DJ=H_{^`D=D3sc+X9ub53P*HX>ep5i=d8CkmEwxUtbPp;T(Dy
zw?O`?`Ar=3axS`b)c7#gM9-tWYNu)_N|%9t4C;eULw(VCDBU~yB`9w6N6=@{BJ?@5
zqm`nJMk&*bSyuF4qQU4B)hH8aG&&YtgodF@(MWU;Iu1RGMx$5I=h5qE3~EapV$nJ%
z;}P`o{a=RB>iJxcl7#j^C!-_L6m%R)_lQ0kCG7e*bSC-%IvYKY&Oxon7^+Ww4fG9E
zhb~4Zqi>_9&{b$Lx(;nmn!bm2M%SYQ(f84j=mvB=nuF?5#{TMGM?XN{LARsZ(2vmX
z&^>6A8r0orSM(Fq7u|~vL-(P9DBURfwdfb<ujm1^9Q_ilUz6{Wqw@XXuhI5sKH3@m
z4jqDikH({g=zNqs(|?Bkgxc6D$}zMRN*?OH(Vx-h(O=M6=yCK_^aPrPo<et{r_n<6
z40-`Qi`J%K{)RR|&!O$mKTtQ6vaKJ0{)rAp8JnS(ZyR4k6VXfPO!P9EhF(EmMX#ct
zpx4ny9-^R8-kYNglhJoUtD%EYYcv{V-mrcSS{+@4)<k8jPA$}qbo+0%-{oJsI`fOG
zE2*$$EY~`j9sp^OKS?e7iX#__8~8vJq(BDjgaRms`cp_J@BuBPLpB_MVz7O|Fn_nW
z8}2~{Dmp_T$Xs5FEicBu_NDFui!Cqi;oLl;z+%gbYb;3a(_Ay$C_TB3!a=@UpN8gh
z^9td{rG-@LtWs`Xd#7_9bN`WV*}LiK`$RK;u~u@>a@MnE;2*zjxTknSJ{7M!4b5Ba
zd=;_XhWc+d`^sl=-SgXhHs?i;gM8E8n{`|64Q>zsKCe*UQh`6H{jVVI2aD=fulTlo
zF6+m^=0(nfYS8<#1%@A)q=U&G*cR4rwF#ETHoHfvD?U&JA$HZ3Qqb8~R}O$<J$}Pp
zI1RNQt**F1Af$k0v7~?{1uQ9GNdZd=SW>`}0+tl8q`==P1*#DkbNhcAt>}xfqkqbg
zz8^Fn4#Kx!T2`^IFZ2h~lF9GYP|}p|0)S~*!?tK<Y-XYBU@}aB6qp7xU^dK!c_2$R
zx*j$_4r~HhWKPm*{FZr9?HkiK#QH1jdktQPmsn4O#r$3hvJ|uaJII_PS)A%IFQ7f<
z#z5v5nU-$+?hapo%<mB!h*t0<=h=f_J|H&I*1;ftFN5VEi!bVp+h<`U49Cs0Fak`A
zZ0`rxpaoojiy(_L+6G*p19SpeZlKlh!v<;?{Tjfw{`?+fTz{JNT2LPX2*<M!2(Hix
z+QO3{OJ}qTbc623Z6nbMkZ4>Vg$BWB7z3dY4(ss$2lxd{OE$kf+1C?f8HYy0c;mXv
zhun=DnfErlxnUk%JJPd=mj$iR)*!b2WbR=bevfhG`4q-N7=%LvM8Y_T0+~M>jmjMP
z@el*C5C`!fb5LcjZvrHO4w7IZOoC*{A?+rkQ{V+KE#hY*!l8jC@FeT)!4*1z8+3tg
z;0_)j^N@Rj*eU1-17ILL13n=0cV+JMFbIHWVFZkXQ4j>9As9kI7V)bg=Whm%;0$fS
z1*F`&LML#8uFwr$Cr;f_Pv{9=&<Fa%Ko|tiz+mu)Autr4BmIY=0Wcg!z(|lq{A$Gh
zR?rxnSZ@LH{9mm;X<<j6$xANdV#7AEL$Q;vh<%6YATI$NI7aFcu}6`@y4b~Nz&5ED
zuEXd2{sJy=?0?$s=Rv|-U<~tN^oa5IFX##5Z!5~JwXqCK)N1ql5wrEGY<@1IPU_y4
z{$>35r_modwjRelYCP6r_ft}YcY&mj*qD?h9bIbtEp?>SZ&I&F9V@EZn?<F5le$Ri
z==-$|>Lva|24sOP_cr<VhRMF?QGSaZ&t%Akop1n3A&0J;LXbYK`XKX4UBDfrZ%g{M
zG9Vjv!T~r6sq{a|-1wt#8l*qUhW87z>1Q(aEfw**7|Ox<Vd^Z9`Kalz60%_%1k~mn
zAhtZW!Etb5&Z;MvY<gz$J0EQ8a-Bgx@P`o4LNcU6790hqM~E|cfe&QBaVQ13=gB>4
zHl)K!@ZtJQ1F;R72L)imJ=7DTAPu%b9u&f9D1&gWW%=e`w$ul300J7~H!OmcPza8V
zh!ePjHv~X3%!WcZ4gH>=o`*argws$4<&+1h%R(Rz>T@4SfizeGS+Exhpa@*JMnfPO
zvf((Cf}-IVD1_5c3b`#%uyG<;AP~Yq3wp?eEl>buVAGQGgFEbnd^ifH!KM{{fFn3V
zKk$bjNQOnQ5_Uo%6oYMR@(R4b2clp$q(e63K>?J2whd_k?rlj!2!~`ygO%X+B>sR8
z1cDCqkOoU&3*^E9I1M%~gcn@E8-gGi7C{c|ghD6<`H+nxxI+LGx5w`egcGtM7Yg7s
zNZp?bi(n<}gghvKA}9yjj-(^Ff)50O4$>hLa^WbHflVi}4m`md!a)xi;Oa&`KmnA1
zO&6{YZ~-p}fGF4rxlq3=`2qnD0x^&bvmqU_VK3yvQ8*1Yyqj_aXK({A2m&1xg1oZ|
zfN+qP;JHu?<*>~IKcIdO@)^p&*^_jHEGUH2;Q16`ffNv1wf%bHC!7X{UK|54kOA4E
zUW5^fz@azk0?CjHc_6lHo%?Ve=m%;22@4cMIn*9NoWKiokO^DB-y1(*3FL$4AmRk+
z;PNzXArrPh(O}ZU7ym);hyQRKN+H{y-%tvv0hA{wf)ZFVoHT|4nEfo_g+d4qWgle0
z@v-D>7~zAUNX`!{Avp@aAQwu(Ihr_vG9CqQ$c!P5;2g^~s6BzSgmBO#kj9V(d%-4=
z^MDs<Aq%!au8#CcBF^A8kz+vzd!ZC;CUNb6BRGQ_c!3WDLO5t41yW%Vtb}aHNap;L
zQ8)@^Ankr>)AqG9Jdf08UD{N?vMz1QpHa2F$aZO0eZ;!7WA~tP+;UXf*V1m6cIaYs
zF1i$zc6b|9o~LSZy!e;Py0o9)L}kBa`R`5v8=^P%FWdi1)P*MKlC-xQ01QnSH!)Zn
znvfVBH}3z84Zzb@hO*Kep{b>gE0pIN<w!M!U3WH3SG5hmu&B@kYI%cg7ial#+fr$(
ziAz?g$_Ai3Uzu#OJ!`Z_lv>T;k$E`3B%H1f6ix}ArmX}}Y|s4F@a^Zkrtm#yvV&!P
zd-w`)7xF;in<N1Y))|8MFNN`-Ss42$kC39&<<$*gTtHYG@bg9V2=3AiVGN6pjg61P
zz*Jmh^thyih+w%OJdHUj=~ZYr{FeWA6*e7<*i)T4*v~2!BUJ|bHj>BkZ0=`OVQNRU
ziIc_l<&Vnt$moPbU2vi<fy++v#opeVeJ#MxiV!5lM#Sj|lxo#R#@yN3U&6mC11r`N
zV>)?wc*carjtvhD4v*~ErAz0IojQ(<4DH<AHL_#JE^cGP-QBu(?i$&tTW41ag4pLt
ztq6<w8X6ZK91|T!_+_6z`(9VWACatOS46m)ER6THxA$USFSV?yRfp;zF`6W#iqRz{
za(r$3D;%3op|w`D3Gw3+LSt3yREBtR>omqw5;-&sLz@*5m2}Xu-;hQLp_ABS9yZyZ
z&i+_6Y=$&6r52l2dqJ+`Zvc6|h4pQQJXY-m(L^)aEeh_RtW5}>7#gF9Z6INQv8<%l
z6kinO*0N$(q}B^nCcme#_?oV-e|LGwH;b#OyhwSd-Q+&YLulu&p`npsZXG+icNrTI
z+Nrx+C`)Je?p?#Wb&m)OBjEQcf2Q(c2+PfRVk$54T<2%?*UC#B;v&y(f3>_A!gc5J
zBHy(!U30gVmmtcDjBAnd;%><2dzP1p#`-VDRxK{_EmGB9CXZFh<HRNXxY>QgP`f3B
zM(Yv{^@@kbxCmV^wM9}47TcovC$`%>6LsMp9&t%AF&Ik?*15=G8s}DRMs@1iakNWx
zoEVwCSN$z^zNGG{OBnpDJc(*zuw3u5-JR`^m~HQ9-0sEpdS=@@v0bi-X~sCpcTHsJ
z3{+hTkBv$b+~?mZj;8D3{-SBB{BMcrzaG~{W^uY(T*Y2knISGpKSx8{dm8J5oevRN
zmQQGWIiS1I7Wiv-Ld{=kHem<Qtco(;I3%9})gy2Fr`|UtKSJ20ts(go78|ZM&kQ!*
zqS!9qa#HUDJg10VG^rB}ZY4_%*K0D{TBygHN_0gvs$S3fiv73OvvPh7`=zX4$1N^+
zLQ=dgB2g_TvW-V3w#OyKCdPy&5+Jer){Jcu4#KOhJIlIyeyw^wFV=bFlKt`8$-xyT
zWs_Q-O!wpZwPg$Mh>U6a3))iB^tU^usi{C2%EbMo>x4U`tMpOcnyv=7|M_%vBhFQ&
ztEBe?Fi%%Qm<;LKk9~JbS5sR|`W|JWyG^x+_&C~zbag#{_qr&Ny2$)4trp??Y>S!d
zn^tDmn$$N^f0*oTd)JXr-5jotxDUBgxJ=pY;c;8gOqGQ+X79HyY*$6trWmhpM``@C
zaC@k*V_hBh>4vbGT2%MEgH|@a?&(www|dgs{%KU(rE<N?ZRNUp&obDhmix0E+cv4&
zJa4+mk`!uso8nYbMVx-)xZIoLbk9~|Wt{Hm^uFVCyoxyK?h>bWjrX9UM+}LD(~5kO
zcU~ptW$2E!sii8qyP4yASf;+02X~GCM#5~$Q+YRNZu?#GRNe=go~zz8#&@smU@?#H
z1XeT`%&z5I<13-mwEZg)z4wuXMXonBP`CZ7e72QxJEn>_8rtgy`}S`c<CsmnWigNA
z23Gv<7RQPT;IBmUz7D?cc)nRhJPqwkLp)8k^3&@X;wkM1X-Y{OO5XA6?-tJrThaF_
zdUrHFe&0Sw=<ZdQO8Irgoq73{I^I-X!zEHI=5c(1IIg@~9PeG~?ijgyAA0|BGB2+Z
zr&Y%C=~e&sIBh3Rxp#}xeHF1gM(e(gmQdYqewmk1iJR%UrKF0u$vA_eyT$FkOH^ei
znPzN!e9QxcSKbkt>PJHx!qA74N4rgy5g^ylP`HL$<xjOfe1Q9O<tIEiT1`iH`ElD)
zc`x>2U%6Shq%ACMUqfF_9BpQ6`%=<#FJY8EhI)oDRoEIgv^k@t38&tt&EvIF8fh%%
z@%n{xX>X3#J#WC3Del}x{FCx=Kk+KMN4yRYrwqa<@tS!{ybRAMH^<BLU4jtlXk%#$
zl3y+18O~K?@Z(>+-Bud-mv~B@bNf<xPtvf{yxx*FtGGAZcU3#xw|$qu!RV=Z_@@$n
z4Fe7;`iK9@{r3UCr(j+;nZj+jm);!i=Z$q%K^5WNLAXQi7Vi71bsjv;&Fdah*bVo`
zo5OB;*7k2Gxgu>P-YtVXHh9q%Uug(?c)ZEbeT7Z+P#xWlcc}}Nif3)PcWJ@TDmXYY
zJ|UK_KlNHPo%?|C+&nfabO)*Q<J`ITac-PfwN#v2;xYm5bnXzwO~_*2$M3_r^9|=V
zwDr~Q*WgLfG2vmM3E}hr-0dD<h_~sUZ7451-_n;LeRWbVc;o-AeRWbVnbM=QiZBIm
zjB-&e|NnBB4CUbFF!|jfOs2BEL>_Ee<nc!GNXmzdi*q%E>0ho>=#x{+65dv^RMsbw
zpSRwpOy4tcr~gP6^Dw?h82#@S#(Otr)Sfi)SL!>_+n1ZeH<NRk-$za1E36`XdvL40
zTlns?et3}d+jUF$O!o~v+huteB#)*0?Pa#5-z|LinSQ~c;o%7piHX7Sk@uaB=Jl^!
z9~Iw!k!yj)Je+$8=gPZ<^ZwJ(JgD~_R`dE+!rI>0$06gZWRdP6y4ut*2eK{45LW4m
zRxiXmm#xZrRLXu;^{DAwHjGb@MXpWBKRIU*=gR$y=c=mS>}rgcj17~;JYK<^E5Gtw
z<~_4_NymG~&vee>D&jYma~A!J=d3E8rn0s~qefGPZ>eo5XH?qiC5ChU%k^G#qPz-=
z4wtjsZ+q(2`p<OzdPyfSiwj7*k0EdBv##r<yR@4g;JL!|(IE+^+{bQTD(gWncAB^Q
z<eD(uOO96&PI+F{-YuN>Q_q+J$hq$~jJMV?rZA>TgMh_6E#>($=Wb!V&pO5w%=-=F
zt#ym(eW{H+1hKe*)D0aVg6pBg5JtX@m=qJvYYE;5gvQ0|qU2St>7_4D?~+D_Yf_%I
zyl^MuSfzhl^3ZhdRO7kjyi(W5tJ_G<?R8l#Yxi|-4ykInXWMOnvAvz|WH=m~K5D;C
zeKd+N_#46y9ISo|C^SY|ynHdrFc?5upoS_}jek^CAs`wZ*=~9tF5}p%8W$k@lW}L*
zUy-yGFM?#hzKZ>c(NiMWT=BlAs<8^*702n~b$kiabc|^Xz%5}4O-KlxY;q)S<odid
zT;`4>FHPUw@@^@ik?<JG5z$qiCmnOj4E09k=!`hLh@WIkJ~jQE<-psQioSGd`<su?
zkn?&N^Ka)J&YOSRc_&4O8-|Ab<#Tp2o>RsZ%OcM?Qf?)#F>=iq&#Auj7#GV+V8ivn
z?kbkb{s}4nhWBt(<4F<fHDWrKj8~S${9JLI%MQaz6xCok*CegsWKtIxT;KZt=5ra|
zO;w(&6zBQ0%`M+nvV2>~@@*x{x0Sv)l&u^IQ<Q&nroYVks%~<6EyuJt-@+|lZ>f9G
zcm1KHfsb{q+5fHOKV5bV|NRDIwHQyYu};y|JLcbE>)GzL-}wIXvg)f=*@rB9ecQDy
zy6Rq+Upl<^E5>ZA{!M$;qqEn!g`G#PdF$(aS&4aFuP&Rje0a;tQ@sn{`exNt&bx#c
z<{Inx`D>3vz3n$}+RTTm*ZSs(^Zj>BZRuV#cz(?$PtWZW-0@w;WizH<WBvF2wo)vW
zw#NFYg_GKz%t?Hxt5wtZ8ZG83b820QDEPcpi*A~w6ZAdW(BS%v&RLChrxEMtUGxmB
zwR`aB2ERXY?d3uJ8~19x=bCQ%wO@<YWIZ;EdvPyu*L^{0S?eiHjszZe95b`?>7%D~
z{hRMtuw;3<@4}^xTKY_&E!SP#C46t^Gkf*`o5W$KB3AeQS^s2zyU*4Pnse&#Vpp5e
zkPg|*@#-S(nk4!(Zq@Qs!_0swaem=bQs?UjyIj9`&SOqq$A*0xXPoERsGGPu(|GE+
z!Og#zy`ZCA=Dy%gKfgLZFJj=rzArsr{N~nS=l&miX9L&M`Tze96}eq36SM7u5JD)D
zklTe2ayQX^LU$??!Uv&QwvhXbStgUsP0UTUST>`P$%Zj)GeQhAGMWGLeLm+y5}NP6
z|L^zr`+d&C)2nkn*SXGhy|0^dopY|6{@i)eyNkQK(Nm6v+-}g{eVb|9!05PXo%d(|
zu+gHhLHX_-CtvDPLC1S!#ofkHTWhzUfB5rvUwG2mO7|6a<qmCda(}Vhy^}S^Xi_>3
z-`PC*``OO-0{sR>IW#)5?8=w)pI6*Xa2>R){pKo(OOMQ3p7e1u%ZR%+v)k&vvz(Q8
z>Z><w$MAHNpu~6SFKxAV^56aOg!zWV>(zF&9#Lt{y?Q;?ZrtFs!8Ui0$w~S~_K<kI
zU+ME6qqcr@%CX{D-Pu{4R_!_M{N?<ELmXGMA2sZHtzUVszD4m*``*NRySG*t7gcrG
zmQ&4wXa5{ib!B$bt4Zl~Bg6JsH{8hk55>QAKWTisYEyEnJ2KDk+lT5+-`mJ}-QnSz
zzg==?&b`kjuGVOJDdl5E^B-59A2Zp}IXm^R>EW7X@?FoZY&>A+%z7(ZR+(PkgzxBQ
zmG~CUTtDT^`|E$1IjQ2V7hh{I-eOYz727jES5MtpaA)n>c9ZF2srctw-}kh6S(9;B
zE5EjCwBzc+{D_PJHm`4OTdvEcoyIktjB7gm`_^=lMyu9j!S4PGPCLZciOF7R;@Zw9
z)79>?drLmbn7a4Fi6_?FUBC7}x2DrED+%8KmkECBZV&wKr2uWG+vAVaTGh;b^R8FB
z-8t;$)OPHtsoOM~-LH$gx7#i_;9KK%o34LV>ywf*?fs+U^S}SLTk}^nP2XM^`+Ym=
z<{+h<Tjm6$+$wvcotwv?Thpp98C*DEc*BiJcFT_4I@$H$U3VUGyLJ@+Vs){Wr*2Gt
z)9Y2QIg^j2PAHpWHFMsoHBn}-?*A})#jHJy7w4f|Yw}TOZEcNxnVqhM7}tI>uKi?O
z`>B)l(!NQH>i961fzlqjIH2>vQNFYO+IMurxPnWcCw_7^Yy8{&a`xN&IC}Vup~JTG
zaLbDjt;rXE47hgVP0hw-wR3iCU0Kg``|w_c*Qz_1Uh5cLqsO&tv|q|A?WQ9szxami
zsur|t$%(@6hL5;=GyS)DxhuavmpA>*m99qv*3e}^xo*$RHcQi*8rOdMWm(Ed&81b?
zuCHR}OBXIy`*~Q|tF>>%rVMM@V6AJ_U?;n)cULv*S)p;Y%`y(NVHZh{?&a6!X5M_I
zR!Wr`U1xTxy)vQE<S*Xr_Hv`>*xjb>f9}nFp#v{gv?e=8rB3QKv;U~!U%vMK?BTWE
z`OImEzk_YNfC<a8u6kU5=^}H}DCt&jd$~=?6?_*pYI^W|p@Vb38mlUw{koD@?d9W|
zwz%)UjWj!{wAXSq`z~B<ys*}9uLX7g(&zA<e$y>a<sD!BnQfC*!9EweW-~t2MXnpa
z*D`<E@XK>Y^n0OiVB=P^KbRF5Ua)FbTvCha%L+^mC()-w@z1#SlX2}Q$uE`7dvr>F
zqkhWl=0irm*TU|M<u@JDk}H^;D_q~M$&kcmAM@?Lm$+NED*OZ6Ijg=J5*ys5rzUp#
zfUN@uz2f>?`N1_E>&7R1!t=*|<$2n;_LEcXnH^4rIow=-KhUn#RK|HL?WP}pp4O=P
z&I`8d=DN7rM-DVOI`)UU2R?E-le+GQgY^Qt(|gKNY1bLoelo88B<0Px_LFh#C&>r@
zch-J7-dEx~&cEj3Q#&m>jY^wxw9&~GXWF)T!N>Q{c)ueH=XBh)VVW=Ro7}|R1y9ej
z)-K^^4(~d!ph`~G;x9T>t$Xk80qY(aZF{<3jGd$Zwxu=c;pW=C%i!GF{_jlq<=7t+
zzFxaWGjQ*umv%=Ss~5YXS7aD##VYME^F2w8Julurb<k>1^)*|q(!v{UsyifYfkhX)
z-wxEhyM}w4rn6kv&ZFwq5g$$bYVDz=W{GxZU8~OC*7MV)WnZ_Mm$F7z`wZX7*YN>T
zYm$5CJ+H2{y7(E_h<e^NqSQGNl>UjbP>=~ppnmp#>Kak%90h;-Jaz7XzjdC5kD2Ot
zer4>ota(EgkhMjW&4o2Tq)W1_0aO?5j>>mqSM)S0YhC?<%Gy2__|+e6j}Adu2T0~3
z(=9|j(Ij*Px)vRYeu)O4GN;5C^tH0&d9)=Og1Vuy#+1xm7J<${qtFC&Jer2Si5@{G
zp$u8q$XZdd_Du{b2A8#>>Y=Qsqw9jsMg!3~sLW>&hu$FkVh44s`u}M=XfcI423r}M
z?M_EROrx;`*_dKTv6q&=)p5+q_~zp7CaLbiNegw%uQC=`@>g%p_2;;3fw-gDsH|Po
z2n}MN*XPO_MIF#^_Pe8eUeS4@;%@*t1&u(bp^H%+|8}6$(LHD^`W-q8{Slpw{)xt+
zb%@Yhv>6(Y_CV*MtW%|V2PH3R-bE*%3sA|giRi~D*V64qm!Nyl<>-EN1$r2L4?Tu{
zfSyIyqIb{_QFG$F9<@Y2LTjOXrqI<zc}&qcqnprvD6c<tL(tu*7fPIT!Dt3L5#5W<
zME9Yy&`fjzdH`LE9z^$}S?IUuH)sxe6qPlizD1>cU?W{M^b{&<K~bi4t<W>*>nOI<
zd821hU-V~mKKcu~7(I`^kLIE4QC<t^_M?~4ljs%nJbD$qk6uH|n=*ecS|6pJ(K(~H
z(Vl1l+84cx4n_;nvFKlDEP5Y(3zapC=A*J^(FW8El`-b!)bgz4JN>w5WxVviGvAR$
zO1>j)lzhjdq>}G`LM7i3W+mTQlMf`{u`ZjE?<BuTz8j26zN2na^4$zn^4%s>^4(5U
z^4(Xc<h!p?$#+Ll$#<tw$#*}YAD~xI$#>;RXUTUpQOS4pQOS2UsN_4D7gF+FZ&dQ#
zNL2D&AS(GT6qS588O=c7LieHz(S7J5G!y+0m3+4om3(&+m3(&rm3(&*m3+sLQzhTk
zARkD+Ylup|>x4?all&(6PV$-LyUD2JyD8|;Xe#;(x*3&xmySxl%S0vL{ftV!yM;==
zGbKMrzIz3geAfV#eAg9~eCLTuz8ix|z6(Po-%UUz-@S`UzDq$R-)%%C-)%!B-yK0E
z-^n<9L%!3J*6O%%WjuNDda-EzsgC0=(cL7jcLTq~KXpvCa$lBwO!7XckD2H5fjf1a
z@>AW}ajrV{S8-RoUE+g(6>;N@)<k_(|K&WbevI4SK2IH&`nS*1sn?VHL-BBi60Qmy
zFKG?R)z5ie#&e#R`;_x&`zYZ|L|-Jli&T5M@V7b!PZ`4|>B_$cYhLQq^QNQKIZmA*
zOFwC5q61Jvy1VeVI_B+P_D3CKri?ukdlwClw5!D4(ypq3K5Y$7b*$IF?2kJ3>R<9l
zOIX!$P)c9E;^l|9JS;!@aYOWSq&-`#oV}#FlX9SrFH+js;*RP@V-2#^#a&gj9{LJe
zzsPy&7@!i*vr*4$te)4T$a!}9{_4uunBwJNDd{2Uv<$6+E=Q%_kZ`&`=Xv4Jd0v8g
zUL~$wJe(`laK491{j#b^IMuNq%J_=Xo~Ol+P3rY3^LO#|BKtl}SJj=^r?|U1McidS
z#Xstx2mYyJ7L>6X#r><Lx>M>|)xTz3w|KnXA^uXH-bG1!O@e9<NB&m({44#}<veaL
z%HK$-)}B@S;y?HKYCrksI$w#mz7KneYp)K(6z0TZ5K0#;W$jZ#epUOQEB)b%m#bm8
zmwY}P<x{@K6P5E4K<zUw>%%JPOIICfhbh|&*j4IXo=tU9MysJsQCU;AD@wm}T`%+{
zbSPRA<sPl9H9Hlp&HgNuX9gW@F3l_GAyn3!rOl$OIeQDO%RYW->Y;}CsC}@NzS+g&
zGY@xS2gwK3P{{{|^VB}nC7!oHJx}f{a-Q5*<UB2?{h*b4t^gwuoCocM3#z@uo!W=F
zM0a_(OP~V$Z&>3qrO;H90a;YAN#4ve2HB7g=041u%Wv1f{GO@CmVFoSfFOv2RLFvx
zVCl=f6_UQE-hcy;4^}6bZ#NLX`K{<$pYHhSO(h(KYQYhV>whwyy(9L8M9_4i9D)v#
z;Q&~;kPZ+8iI4&LVAYx95DW>h339=r3&+795+MWfz>>mgT>q20pGKbz7}x)#>{99P
zfRfh#l(j$8Xv`H||Fh`YpQ{Tf|2q20qEA})^8~*YUH3DF8^<|rI(a;l${Gp5`2Vc6
zKV{v|zq{6F(2wMOZU!0fch>lnwGyIfOj*-FNJb57d>YnZu$n_#0+Oh^a-|;oi#iSB
zAsy=6H|6DosU`(-z>*ffCuD$i8P-1r$Fl5$yNQ`52Ru#9H0hu*Gt+c~B*+Jsa%P$!
zNPsjr0k-AMG|_MXwC1c83W;D@!A!FWu7PVsGtFwa2Hh%|u}%bjLKfTvE7oDQ2jgb6
zfYAa*3m7e6w7}oBKv_<>e_uVzf;nl+@V)6(+NjWhd%BFZ{U_ERleL9Pvj&;0%~pIJ
zG6|gt=gW9o!#0}m$ynZwgs~III%V}h)+v+q%D(3X(@Bsy+3#BF=l+)O_h%s&WIimJ
zH}X7OfIPSeo*-lAy}=j!ArOLKEChqheG>*UcVZ;ST$AHr0!#!M^DpyQ$=puUK;}(}
zh1n1XGWW<kkN^un=0ulG{J8{|As?>7Z*U!chnpbtwaX@RrQhLi35&!p8~s!M2ANmv
z9{dIOfx*R^GGGEr*_UzmD_|w8g7;w!B*S{x02@K(P22=BKWG|khfiTA$oylw(A}^H
zJ_nieWgle1e)tl;f&(C%_+v^KWG>WlP#(;o0#t-bAoGvQCUbX7INEX@X?IQo7mhVX
zH`n3Y4TL}#7`FBNy_-DpHq0xMR|ax?5DbAgz_4xL?~jY@%ly_dm$l4WEo({1oZHp7
zUPIIdWZv7C*q8Z0>`_VMy8JD3H(RpbOg+|weVGfT75guP9Y{L4a;z7~JWNeF_8QcJ
z2G9t)a9rkxYQo=#2-gzQ_&o8*Q{$4sF)#22KL`Zb_M!XLzh!>vIv{gtzlcA@*KL$F
z)jH!==A@Q6Y+HcLn_CmNGUtc`DrsxY-!gx44Ryaif6JUJt=X>wEkV*p=2sdBGLMrj
z$LfL=)CU`Q+B$(Ht^YR`e`MUc3+KxG4F3Erb3e3aza2D(5cXxfd1w9(M4eG5XaO?E
z{~^Ma1>e9ewQL;a?_-bycR2R%UT09!<)2t<@CCwJ9Sqyk))y2v#x(}@mU_|}gOdLZ
z>k5{39YHa_ydQN3Pq+q!V9vc#-fP-{Gtlox;{oBow;*{Rtx1Lq$bvjD<%VkoT97^s
zLm>)ukOVs*6LO&t%z3|O4Lf*_b>mSl9+IFk&)nT03SvRtORk1Y$b&+#;(6N^T)+*6
zLJ-8mQn2Hh+8JEIAHpF9WDUb)kY{dpUc`HX%-0_U36KOSkOtXs8uGxD=WH$5f-Crg
zJcB2~YLI#FPrx~l4;pnq)<5h9-Vg((e27SdWY`4hZ~|_EeB`MNvd*DBq(V1dXnTM+
zghLFhhE$NX4Bf#KqQS7PVG@7ufE);-j*S9&VJzz$${N3EkO5hc2RA`p2-g8e=my>p
z12PY9D##j$IdBaM!HRmw9$df^q9GBq)KT&-M&|X*hSN|0mV89hf-N|L2V{YNO~MDU
zkN_!=4hP@_$mF<g5DVtDxgNwoJY+#3*z=vlACe#y(jg0SxCdBLAG(3GdkR4AKRQT&
zBuIfYH~{Cs{58%2EjWWG1VcP5g*3>7b6{9ov9cE1fjzi_KZHXJ#6uEfKn~=Ad?>U8
zE!e?ONP%4NuaA33g?uQ4$`npnd(i{@LDP_Q2X6=l9V9^p+=R-FuoJk0Cxn9z;$bPI
zfvl}~4oq!$4-2;744x1KQ4kABunDr@1e}ALVA`0x4bI>WK@bDkkOMYNh!+Gw6zD+K
zYg`J+kO3#)9NdJ;O-X9723gP18)O~FSV(}?kPfnjV*ymQ#pYlG_TU1tj$;()ARd-N
z8f1Z8Gmb+lq{E5kT(1TB0X)FM4nIKFTb6Yk-CN=wWL-w-3}*)}kO-NO10Joh4;+9K
z5Nyvrq=Kx;sCD2x(6+%X_(Kw8K_OIbOWp(>q(VBFw&xu1hbUMISx^X-oyjL1$R}Xg
z5nF*L9DvH5um|h_jSGH&3j}w?){qUAyAxjs2kBVn*n_`82bR4^O9+M-u<nfwz#A;w
z2tWA4wZZ&01e-(nP{IsZkT;y`bMvqT(~<ZEZlHrS$b@)r6mr1MmwFiF+e;=a4J2N0
z4N^x@4ueP^aEAm)hb$-r`_aS$+{R!J*Z~=1ITtj+oC7*YfFwwPG{}G~I05G%CxmN<
zqF@<Dn84mb|4e03P2Y}hgvxV`tRE=tLs=tSo_~^2dETqbacR#rN9Fk-SUumIeR;k(
z&Hm45RraL~*#MRHURjO@p|+?z=QZKDwE0X>X_v0!xI7OuV_%*}Y*A?oe#>!bd*48%
z4cwaJ(hh8hO1Qq_xU}PC2533&3-+a*{|zeb_~xk0gD3Zfx6u#O{llot3tEBm<oV_v
z`_gVchRSo`eN@`dXHa?WJBdm=|5e-{Wd8^DFQYO`usoYNqS6*^%5jOG9on0HS^r(^
z)(mw<tK&|dv%Y3uo;z|;siXg?jb;V&*OlQa<X<Pxut?7^-!Yy(A^vUb10w=FLq>;=
z4TuO02=?@gh>G+a&;Op05q_RN;o<V9GUsl<<IDf)k9$P~1S*S-85RNL8crJLYGu4B
zZ_I2~TXT*khe7*{_KOIM3=53X+6-u{?H3+3I%M=D&eV1d3khdAqX=%n*44bc-t_bG
ziDHE_-|_mjWvr_O1q6pP2V9Y(JYVA0Cn}h0$T@^nSx79vizUf?Mg_<^XnHp+kEE%H
zn<1k^{lg|i(!{W?)`JDo{PoiSEB<uu((@T^+^TJ~<Xwb17gs?Uv8K|`TT=lYz`m?;
z>+)em4SyQuZ}VquG-hyPp(gAk?w>qwo_^joneW&IcNfS5tnCoR*_3kfFQtOM=9-(3
z#{M_@>u_AZ9uHBKdG44iZd6#rM9LPiDmq_Ta#`_(cNZr5`4yv33GcOaMZ-&W2v7rz
zTM4VHa@J%2DRZRBwcYutq_7qe&edG=L-dpN$~Ba*a!JFQG>?U~mug#E!X_Kly~Yfj
z;1nmirxp#XYFFlF^$Pa$A}1*}4u}W{^$XC4ozqI%9)#VTUq8g(eq~e-*cY1(FwF6$
zhJ&hIN#lX&8QiZfDI9v!sR0=s=rul+6xWBwpYz0)HfRakgYbxLN(xV3H9W3TklBjc
z#bRR#c2Os4{HJZxMGXtx4wTKG^p*VYg-U+%ek3dp0`bq40j^sBQU?CiU+bA=z%b`x
ziex6X6(GT148Ia)?I%U;H$I$tA;2ptC?de;LFwg?&r`~-i;{-bHD=Z3=>4*G>)Vpn
zk(68god3nkh|ICA<@YaWpG!IS=Woe-ebqT?gUfM%?PZWZsd|*n-K=Vn`sImXwGJE|
zYAyLm@|{+HYO((<W=H@f%>H^mCCqXP^`lv}VGoYAdn68hi_}R);~>WkaWK@8@@y*G
zYTz+WvHL}?a80$hKJ-cz7aADWJ=!ZYj6yy3DRzFej$Fj^2e#8!l3ZMDE%jAVTSu~Q
zs3Yg--9M;P#ojmh-5etabR{2{T(L=6A8>Qz-J14|&+PbMX8YXT@wHMWZ5=dYUCWNs
zH!sZQ{c~q==Xn3^ou9@0xpJb9?UvUI@3)P)l-ztsVD_xZy74J>#xFh1`(VYty47F#
z^lQg*e@s5srK;w`g*JXI+E=~j5b|!NCXK9T{V;bO?S>BGU(mO)^E4l~wrQ~?Ant|f
zfj73D_Wov4!yf{y-Pfk|>2{Sn_kHEMOJ1o}zDK)5ZC>o1R{qUHEvCl|Jd`~m>g@qN
z-W^h_)$XjGv?Dr-e{=TwRs4KP=9P)jH!^=ny=iqT{f^tt9zRbw6yZLhQcf4*?CLD;
z5}Q@hU7lhUdeNaU&o~F6aSlS`9E8R>2t%WsF7~`K`06KJhHja0B&F4{oo(z!Z65Z)
zkj+PzYc%tf`o;Xr{aN|C>rHC}wcUNV-{M5wU#ov<Vt(q!n7v~TA2MHXlyN0NQosDV
z!sRck+vE1$Fr66DBdhCxY9r%2I{Y*}&aTd+X)lMwpEJ%u_@p@q|LM5}OFL(vaW25l
ze=L~j9sK6@lS41N+2wzAdi5)-XvZY<k^Ed>;r;E@S5|ljW?k!f$F|a)vL~mV=;QlY
zVT?(=m43hO`GV&&?!nqp%*nD_@$bT)H*5Z$ZJZ16-!~UvnHrKFb0#If_gcN_eUAI}
zjUHh)z~b0fsTHe7<qfhucWci2+L?#`b8`V2=lHArbE<#P;au;?0axc$7`wLZ@IEd)
z6D@sR(k&n>d-PxS4z<?hms^_k$s1uNao0bws<ddujByD~mpX4+MxPL+{k&&w`J?@s
zyOix<@3yn+p_6lOgybbpYyW~*>gYb&2IFd9=Q}ws5ws?2t5p5t$i)!9UY)NlUlNsM
zIWC|eAo%Q+5r4Gb=VqMa&p5}QagM*_afMS0{@Qo=^n&_XSKmmx{l;G}_87hOlU{d6
z{yHOsXHX9pDMv}SFaGrPHqRJ`SLfV+W9cux+wcF-zfS848<K90_1$#pFb|j(yrj~a
zOgI0lQ-x*TW%{)_y5&@tH)hVbc%t2p_7g6byFT4!dAV5!G@7Z3f6MMoztf|$`yZqI
zzS#ZAM~m*XpBYoHPM5aljdT1BtMb|Ukc66Jze^vL=(gz2)OSXGSo4?nPTq~qy614N
z3VoX_#LmAKl)Yh-eD0G|Tg(&tTy*a3^lSEj%df3#_OAD-^7Z#$IYB=^D{)tTe>I0w
zd3$^lJTz&yk9G~Zd~Dmx*@JdD^v;~%QTS0dgUnX&0!3>w_ekznA2{`S<L3sQ#*Mnu
zv}(k>OS21Fy><BF@tK*!YYyjIQM%&pR`!Be-HduGM``c&80xfW_^`L5Zr1D7FS+&L
zdr`9*9&gI~HN{=GJuh#wx?s1fQf~K~y<T^i{hs;l<GprxHl7ha!Mu9meI4(F6?fzP
zuihGQ-~6{1z3c{BURb{RP@Hj&KS>Yc9Dj{x)mRyEqxYiTKfkrbi<fq>N;`Ysuk%O!
z8aie5`BS$%doP+DeYQvE_cok-zv`S$Yd?5*`fCx)1EIKkZCmne|IAwR6UW8OUo)%f
z;;4hhIsPPHc?}LPFb{Y5ZG6VW3Nu_Tx5)U_HpAQJyBYT<tZ&h#Rm@V}iz?6iUya$Z
z)~|M}j+-{GyxRNJ(fzka80YvC`x)o>GtTiR`QZP~9Dl~S`&t}t-ubKD*4NM1J-6P|
zc3Q89mlBg08{j7S;JRB#Qr!8dLN^}^=T`f}JwC0zC3W5Wt4)0KMt1gUw~js??<wv&
zy*BmgpWlWrnA7vX@+R8EtS^3#YrOfy-X*sVN6ozStqpGMmFL=vu|Joaey_s?=bw6Q
zS~-5@@P40|-2QG%w0E;LsSE74^x-~uif=<&llH$K@|fB6^|^c6UuZNUH_vVRPd?p~
z?FJ<}4}G4w`%?Hmr1oQwdF+%q1*&t5XewJxx)xR7FPfCfTqtxu)LFC7W4khU8K2p7
z@{Or3+8^aNoj2MLrF)U4F*+5cd8nI*Hb+xYJ`L)AMCnGRyN$L%>vR2fsPw(%kwVuQ
z#WXtUZ^5le8T+4yTeTm9(!W9G8X!zEr;@U9EhW6M=m?I?L8qW^p$pNuXfjGzbeZV8
z=qWS-y^P{USBC2)qBYUwsLb()J#=rNE76JQdnogfXjY*gqifL5QT*2Zi1N8l*R-sD
z4l0>*Y6JVD(2vnO=oZw)L_Y_WH~K020cbiZ{WbQWHwcdlsC^-nz5o(m`Lt~hvSBNo
z>~}!<w5jQY)<e6XPH0zD{22;rUk2rG@yDEFWItu2pR;1OK`3de%xPE`CC)lW)Dso|
z`1Y^shI*p|Q6JP0PPK1BiQ%L#wGz&rsD!gOD&g#liog9(@n;99{R%YF-$24?$uY?@
zvhnDkgp;P8GABeY^d*iH550eAOZNMrE+~0Y$KUkxP`c)6JkSvK2ca?O5cF*n`zUi>
zyn*gy-xHPm;DwqJ4qsIIg$JO-L7Bskuxm!MFa06tlBa}U$2n>r1LYgIgue>MqCmFF
z#M2b5g39r#C}m8Uv!g9qo&7Fo4RjRBJRiDo=*ws%DsyqfqIJ=Dlrp26k2XXXqm59p
zqYbG22b6vV5{|MQs{^vh93T}?@n77>f%>gpvzoufy?n<P8_AYM{AB+d^i}jQS`Xzj
zxiYuOQIs;P%y}l^Kf%7({UpkxrZTsg5Bd}PW6?{fg#QXE;l75hK(C|uT>HOaPL3zd
z#bHZCT)+dKXa0>;#)W4=9@sN3+#BM-FfT_oe|uoScrebxK^;fs9|XpEI5e6JD!g1M
z0IS~QL-2<<NQMl^2TLkMdl(8akPHVPA1wNC{{?plhImMY1CR^Gc{sQSaSx8+Ch)X*
zIP!2Kb8!@%ha;{c-vy`Ar+6BDf~n|(z+T5U4)jTLaTJ}0!!QR&?p4x(&S1})gTuT$
z{(~D08O?9F=Wpv-Tnlwa(@}3U3oV2?-1Kch#tG$c+!K}gI1J;1&hfYDY~p}wQ9FqK
z5jWf{WQ@=bxoHqb3n<Ne9LdaQaRBl`TZK6_AQ93bAFQjI;h}LeTEJ+5f5HON#w$Ah
zU*_BW)q*kMH2h@DLpB_R<6zj<@LN~t4u&n6zt_Sw9tN(<1A)4&<Cu)|O+i0`i7*Lb
zU@A<9SeOHILAF$MBYXmzU<=45eK*(QxAY~Ju^2;OAV^=&3mlXFqr=#jzML}Ofb`!T
z%Kl!?cLN#Q_Yw5u?-j5TWb2E%;(jm;gF(0%3`4-M$?<L=<38$xj4$~EWV1mVgN#*?
z@f)o`HW?FA7C%g(oa$E(j&<knp6Y%t_A7uTco2@kaFM^?MHj##c#HjbSi;}SK(>7L
zhw`@_w1Otk6l80SIzU@!ryd)Ij)O>be>mz1BVZ)>fIk!;FE0M2axG_m>j<)qLPx_`
zb^i<Wq@BJWz6bXHkiQ3`(jQ*ta+uVVaoElEWA!Bs-zI(Jp>aCQfSC{rvtTwz`o+Op
zFb2PaAr$7aFXIg7!8`CS$ov%Fy~y)8f6s>nun-bK^2K6U0x~vn8OSE*PUInQGhy2b
z+h7Nr=fUwPWO1!;(c>KZ4o<)+_>*HY@4~-(?D)T9-1u_h{Is#-#&P5Nyz!)Q<5K>m
z>`GaX`a@LaNsw|YWv8@b$z8Zi0wh5Sm{Z@f4us5EEb~=rPJ_%nF6%m^LONst)9-3F
z(eyb1($2F4E!cu1#6UbGK`Nv}7Mund&z%LQArGXjW=gv(mNr=?<UlUuLm_A@Q6EAO
zL_sVhLOL9PY{&(R%G8Mv4@)5h(!jI|^(}Zp5Trsr6o5G|1=8RqXkQ?%;0(c#4B2oK
zwAfX~#JPYwc!P|`mN_9T!5Zu#opPKHg<#H$5f_lL(uuGdHi3+n&V_uiw<65o0sasU
zF<@1TYd|=}KsMxpb8Xx~24q7nT!WjulyW8Ar4G)3%G3{05DPM|%W6mmnTJB^59?QP
z3*nFqry(B-K<d71$c22^Q4fVeFt1O1!5Tck8xkQIPD36PfUPz80J_0BxCVt_-hlJL
z4%}cU$QbEx*a4Z44f$Z+kn4a8_(M3vz*0zq1CRsPpb)GYaqj~eCoN;46G6s8XF@id
zhCC>MI*qX<xIs9`Sm-!Ngk;Eq6X4v0`~*AT0Gw+|m~6=d;0<+};Ri%R9C&hHiH9Vp
z+=BDL4OT-o<bt;yc@uVkTT8AD@sJHNcG&{t#j-tggBVDK(~u9g_V@wuAmf+MwdEW~
z+=2)ALmZ?-J`}=IC;W$8u;N8mEF6Fn5ao<p$cI9(ap9T}4+lCEmM&ZqoZ+VY-Ic!~
zy9c%eo7YKe$c4(T*aWh`q9^4BQU~%ITmxHPTt-72BoF2KkOvuW;1`$=$8QJ+9k`A_
zAp!D75=Sq7108ty5r0U9Ab-*sa-ebmc7<q&gB@@UWC0WNQP>BfASQ@&LB=Xq9?f;Z
z4Tge0ghLF(K_aY%RM-KTkPW9HYYcvjMWJ#q_5c}2EA7H}Q5g>??J#K%E<~jr(gc;?
zTcgr0oR5mT#;6=OZbl0jEnu|3|1}Gk65%(Vd;CA6=SPP<KKwtB;rgLr&6!C+^S^n#
zzhUg~4%+Op)q@H^b5C=z4sEWk6*T;0n0^3LF$n=9heMp4g2N`T7vvM_9~_{JX|>^;
z$2YCZW)8|&TDe8#;%C1yQ9+|4_2Yq?tK+R@{wUdwgIqrw7B!;HqF!I09QyITuKZTQ
zri@Xp&2`-Qahr0T@bSLEqy5wnE8}Eo)@ZIOzv-hP{>a<|=|oc2l=_(cX#F)6_cWE%
z@%&!hqr)S--t-C9$hca=*jh&n^-uRvFpkwVj@31e)isXQ{ZEh8{f3HEYjV5XwzIR3
z?zv(6*Sy)MC%)al^QS$HY90U9>)oC;7L|Xa={}wlyNSE7dFy`&dcWW6Q)g5%tMKj1
z*SqhU(!epd&%E-l_L|ehtL2BR?Z$JY)}&EF--HT|QAyR4k6!5f$#MT$bBC;X-Fokt
zW5LJl>RF#{NWY@?;_j}~$G^4eJwkK1;+UUmmOcH&-X8=0tY~rYqqNpzmmJ%8b0Phz
zx{JHif-eR=eN1nS{^IUV*!!Id-&~iH7BZ-=$;OI1x_olwm`R5nOCvkp7?EgK!1Hiv
z$NtLPR9X}Nb*;~Oubuu=z{J|=No}m(toYHL(+dyZTK4sz6VWHWe)Y0(?C<~7vA-d$
zC4F7%`<^y0YclR?<=0k?c3fSUACWP@=Jl;@%XPW5^Iq6r;XJoj6L)RRd>RIBTfaB4
zbN^}Ik4&C6`p&AFmx5|0wG63a9Un2eH~oN=d|Ehj{ggBBum5G{q>8&<e67KFi%I!c
zY|s2$J#}ZnowaM*P1b+E(V7gMZ9gYtUA2Q1f3JSz?z#J4e)!?2a`ioTzCUu|$?q25
z2zRDIVj<VP=G;ED<>=v-1NU2-U##=n<pJAg<$PmWcKiLioe!^E+?4l9i@3Jd<eiUi
z@2)lLkJvmr55JyW?F$EeRJ>2~LM6Uu(h8E()@`lQ@A|NI#xcU@2GCEeuh?(od|jQZ
zH8+p{U`f{C`{onN&&(<O;lS}07j{SaWc}G@`7FNQy)N!<CI)_BHU3zyP|vczmpSqB
zr05%-J753(yYrXEHQ72i&GsGU^L7z;$J^ZPFl_JDy7Mbrmd_ZzdSI&ad4~&g6Mp{p
zjS-f4+q5Q@0b3p8>ka5NA*t5s?<-urUv2clZ)<CU&bPCvHvP<&b<~ls@m@}Avi;-g
z{zJ~X-ftcM<{Y2vtu90qI4r(UtIVdHCc!%`R}6BaFR&8dnCXsb9m~$K&b?>Z{^ul@
zABPWi{~)&@a&Tai2|sMK8pV5U2O7^>lULWT`K3wNjinnWn)+1!%EIR0`ppsTmJdl<
zU$J_Xmuu(auBT$>h1*V^YP7E0(lx(D9y_+?+ganbb(>mwZ}JcI+MjAs<xUuW{kM-L
zep|U;{&mK+QfA|nH+ENV?7Mg9q5WH~*Zd;mpzpjb3*A0^xA{+dnZri0^O4R0g&AGv
z4Qd|TY^LdZ+bY%8-8?jP@`3Ol<~F{#B!4~k5ASwjzpG)btqy&+a?_ehcdvL~D_<pa
z#pdo+yMOl6#9iwW&cEU?4m)=ecW>XT9i3&j{g`vyFSkk_bDW}tuj=~_+AG@VPk-oe
zB{eIq$@y1~*ZkqwCo^Au=gmKV&HCVg9rtr3eV;ux`HJG7`Gs|tD^;Gl=lfs(T(vyl
zR>MEmHP{~K-ehm|!BMTd+U!_b`Z3I{l>7Ag)pK*c8hIz|_@9OMTf4YsX8F9Z?1grF
zN0!fUy57fo+!Eth=T7N2E*=g!aC@pv)=PDhPF5(`HMDTUcia|~d|+zkuz9(+ajdg(
ztg~^fvx9BBfC<a8u6kU5=_2p5l=`&Z_Hvt&EBG#I)b!x_LI>x5HC9zV`*kI++RMi^
zZE@dy8)fLEgVd+Fntd0pHeOikx7UKYf9Z4hPQU4vr}B=k{>-+?s$idsU9<VFqukHq
z_gdyJ8-982h<-2h4Q$+M_6M^9!wXi;ic4xSeOZCY;UvC~DgF&zU>xhbUNgmGeElw8
zPZ_zoGxazx<FqDy&%Lze+rHh8>_6uD>sHs++k4yJTi$L_OyKu}D%?7@<4y$kBig)L
zlkVj|@44EvZROmWqq0^VE1Y%smlhMhiA&fNe0;+^vz^_{`Cisj+#QdYUt`dD|C*Pg
zwwFJ-ZtQR8T~<vUJLmeom~Srk*wQn}lD;}^#N8N+i`U$TzZK#TvNU8=orNo=ZSvMu
zKj+u7-|f${t(r(5o}r3=2Tm`yUXuQC#e~?))wDMTd#@e;)uM?@?CSI@GcD6C;av~b
zYEazupK>C-ZT0V#EI*iadB@>T(%Rb&uUYZW4re;dYw+si%u(bOnIGCX*17X!<5*|O
z2T9)PIdfuvyLk9=_K<+gK{h|GIbOR@^qKID*&qL^F|F}6@65@oya%cDjoX)>Xb+$6
zaJuZCGv8nI{Bh)uo}RsaTc-_g(q#OgN%S%7CGP%v$2#9vo`1_7+Ti5=V!3-KYmU*R
zbR533dGhzOo$m$u4T^GTbY$6;FX@k`JO}I@Hte!rlTA0KG(FTlDDoSd$UVmc6GpqN
zTo`(1;pxqLDd(M(_VfFdKJPJV>qn;?D~{Ejoz-d8p3}}>&ObQBaYg%4!>-r*wFd9<
zUlzNxJU#CIx|QQQ#yD(f@!`HPOMIvG|9WcAGe^JHRC3?-;b#1MTk&t*Pa5B@+LYYt
zjtToUZy%~ReQzV@b%%#<{&vZoIrl!BxSD=+N`0j{5Vdpq`_|3RUEcTVn2TdZfB#W<
zV6z#Of4jTk$fa2;OwQ2{NO|tQoc+hL!1D7hrM5Y~=xVQcyRQOwH?JG_Q`!f<sbQz5
zW@+fdr@RmQ?;T^!M;q+7V0Zroryb(!#AL5Dac$?5>1y}cy(J%IOx^q8#1m`ou3yVH
z8ztSw`PW>0YNth~QE5|-HafZDOxrdu`1t-A?{{S3oQ}ITO!H-)aVzm}fXf8Gb+-q8
z_fmki)9vv`YOQMKzIoTH-R>NAb80*G)YNT!gQ_F$3hG5QTx0gf*;XU->qT~3y|A_2
z;8mYb@{ZiL?uvHPr-MGB?}t*K=5_ljBDhOr$n9?3xBB%zUFPQ%Sy!hFxukt}!mZlL
z`!>(VKi=(?<~>L&C4DE3t=CYuB%%CUu{&#dG@BlOp>x8w)hbn6wQ%3MFXEbx_?72<
z#hul`0j4hvnLjhVO;W{o1`V_P!E^kC^1~MntJ&$x^zOq3dD9O>ad#tker%nNf3>ih
zcEM!zAHG@VJr2$|A8+4g>88*xr>$5`o8&j;edj9|zj^KV&F2oUj|uRalImS^^wGR2
zbrx>ze?6pA|NI)G^XM<4<d;nYOm9u^^UCCyb&b<r>AWEO+=P19eKR&6t9K{y^TqC;
z(642;lK-Ob4Ih`hIxDG8wUJ|Q%-HVq>ejWcZLQvaec8Scr%zhksKUJPiv5gZyQ|i{
zclUsGkBqiG-7m(@q5RUHO>5G_&9!@%!MU~l-<j~su|Fn!y>^dg;ND3u?T$EBFLp(*
z$S|JcmG-3ho}|W}7w?}sXf>$%nypr8;f*%c9g?=dqKn;c2kPFHci9@+I$9GukE&Zo
zd^GW^wTG6PCEA^JtvY*K&rg?@ecfhW${JnmGkix}r{tI1JMVdQt<}Y^!I{r{h4ii8
z_?;^&%**}O^GfidjVtpnRGC5F^bX=*n|r3a+J1Dz#cfCP`#V3FZNIJTvas^Y%hdh&
zQvdmX+_b(+f47&!U5z*IrB&V1;OrmvZ~gG!HMaW(rqP1>jam8jTu}beb<Jh0sJL?h
z^;@v=jrf|`qho@r(!Hw!ZeBpG&}t~R6sf{=G}W1*pY_<wQHHF`X!7BI^H@v6m`dY#
zO8VhZRyM)^wegfWx41vTX`W3A<@tm*q6>I~4pu`3<brWrC4F$;z%GymCqOftzO*nD
zq+e+gWWi0a@FYKh2jrGvzbt)BLHe-7FgQH{l3@pAK`z{c%G5hH&<(sH1`;3{Ru3SZ
zAO%12LDoz2h8V7q1b=s3bdSdLH=RZwTRKO{+UOa3iI0x@kH4QZCR5f&mvz}T?V~>_
zTGIOHg)=!$J?a=sUtjbb+yqzlOS3k58s`@uj~VnMePwBfKWTmRT*5BnF_WmoOB$2;
zq;=9|4JpIe0K;18Zj8N*F^<0^gBv%a1&kIjTEJ)lqXmo>Fk0Y$t_5f=KQjK`j5c{%
z9mb0D5@0+Swx2nc*ht^6{NtMXKH|qXCTqwZhalRQAut2V@#3I7RDg<L*yixta*%Bt
zIvysf`!Zg9C>XZy@$&?ngiql#NZ+k9=#Ov~q(A&m@C%%SU*SBY6YdLW9!Nj@OK=(T
z;R;9}cG<4+jbH<DSq~+R1%J}`Zy5u=6+ix6>(KAQ@7?g38cvyq;V^$c@0#%0oO=|$
zRsH*)Fn(Re_5V*@`}`Ba-j{ssuI6nIbddV@FjUrqmdzIpQ2&<oPEEnEP2+g1`dfL9
zo2$RICk;EO=@`uKp{g4>FN(h>sQZ<0UqwCVNn_fj49Xbx(vDrX<r=PX9Y}#4kO|q4
z3pYVS{m~8FAqmcbBbAIi<I9-#Sdi!R(;#b`TY-k>Y!C2<aFF!_yYUR|0Tw(Td%{vk
zfi%bf8P_iBoSX8_vohE~H*g0}h=xRvd5vT)qdd3?GKrx)Lpy?e_x6SuVA)2^HPBRI
zyfhfrC3oj<Pmr<j(U1fwkOmnbW8n+Hv@&6ZAdoTe`4G;F)f6}fGTz;u7p(q}1X&>I
zE%OIhgFQHtZ(=~!AI}7D>P}f(JP!)MlJt_ilLncP4Yt%_F^~qbZg@Dz1cw=r4Y`m<
z{bpmu?~nu5wYVO*!&0~jrnLz>?0|D{6D-JQ?jUou#DgpKb2KDF8pQFge+S6g;EsIr
z4}xgOf<maQ<vhrNa}Zq@d%zAT1lxMV8EoqlR|tm`I05F?<P8`K@vs99Kn~QgAuJFB
z@gQT)&w(ZHZLC4o&MpAkruYxCPIfNHIC5DFI~%O%<Le4TA=Zv-LLOMR!p0B>OToQ0
zf5TF+ZA+enSV#nCN8$|8VAGCo9}olP-S`dMAg()MhI4QYD)T<k1>C`=H}QsWkh$1S
zKpt%BgF*p#^dk?z3CM%=fuxlOafNJ<@!ihgI+!uruo_N))e!PGct9+qLl)!=<(t7U
z!T_#s5O#<Id2c6U!L7g=>_EnayMhOJgS#i^jX*)hho^!w`Bv_+Qa{O<Gvj8ofYAa*
z3m7e6w1Ck9|NRy)C5X>I{y$`Nq~GJi|NVVOMTAEw!~g$RkN*!<$KPKoqfcj=vdSFT
zub{OX(0;ydE{{X{@&BVkqXHsAeS*D|#o)uk7+XKl$tf&6Ai^gqEW)O-v))-mKzLY0
zlvhw#*jSdl_78CO3-XERsO>0Mc=9^&kIoZNj%NYGJONc1(@*nMQ-koZ9=1lt-W$R#
z&tb9^4R?Lqx%?C1o*)7DijtuJE8%{vNVvaM*FV=vre$*jD|j6oa2H-Q+>rr6UZckQ
zMED2zd-?eU2RoAh9Un2cbFfc{ufLC1o0j%=ZS4d7{ruYa`nGD>x?S6V)`9jd{oA&&
zv$GHI_vvVBaOvw9=<Dd`=iAz$rDHosA0Howwmv?-j{ZIlzJ3ArEgd>)8$NK`%CW7z
zonK&}qfelJYez@lz;>-#+O=uZ+RwqarN6I#V39PH^m%;qR_0`o_14$x<HZ{6j>=pR
zE;t@eCNre5%n#wpF&o8JkpWTT!<G3L+&R`vIp*URH99PmUFA5B0GgJ{alhaIpHN&s
zTn9ahzx$Pm2#6dXEPpEb<ww=-X=ZXnzkULb-qJ5f*|N(j>&|<t6J7lG8@`c~lXpx0
z3mhG4ZKp3+S~V_@ip2~b0V&gF)qc^(ku+$d?4NwF@9;>P^i}8QD4HgH%RHVYean=b
zCVk74oF;vXrHP>|*vdN%wxVUB3u&AEd}Se^bvuW4En7PH`r6sGY1h`LRbZ=DEd%}A
z_&WsJ`LqcPcvu!%JNn!C`T01uY1yh}Kuf<?zW%;#{ad#UbntKK@9!UASF|kP)}Qn3
zTDEKJ+uFz1-oYoJWlP6EhnDtj+xXhI_5B-Vp~4NNPJL!sa8mO3qjq;zjy-O77v*@#
zc7IY?kp333)rO*F;o5VSh5wl0pQ9|8m?-7_L0Py{%CaD7QoJlknv_%)Buz?N76R4!
zsgAtAW8<|1^&IbZ;C1}5)8`p4FCRZ{t-)b_W4)MoM}Jo^RPE2s&ieb9`1$x|q0H0s
z67{e*KfcKOkbY&9>x}kiUycW%-3Uv+BIUlX#=P1nj+GQJCnqnj;8spfhVVTzf8f9P
zH@B4jJ+nySpR^SWwv~6EvK6)Me6F>r6t;c#ZS!BZ?Yt6fyQP%2cxD5Dc#CawO6lJ-
zZ~gcuw(X+k+i2bm%O>-+@|sbz6+OeX?0#43I=`@xkg!m%kbuZYpHTr`6Gn&nhfUD8
z3-$LdWnmS?he!VFyqVpK8mDUEH1PVdNRiC%l)&He{YvUJrKK4)F+2cwukzbcev@w(
z@>|sSh)^#de}7s6k>ac5;nn<ZUR{2d8Kt~JeL?~hKT{qY4;~%L@$n(P0TG-d*W2{q
zw~#RZ@rJYXzsWqOdjG~p21FPlDDBZ|)iO9=z5&r@jR+eR;S-`<&Wm})Mny?k5;vPr
zeOwH-@ePaidf0Z6Fz>*P%+=ekjQ;xUDsh$hs(!}C99Qk?J3cT_3AW;Q0`9^|hkj)u
zgQP)TG!zCuR`W-^Vh_EWqA`^4W%Ii}4n=->7zM>X-aH`OQQC5kUZFNKWL(E@R~Aw#
zs|g4RkD4e`ag7cgrKS~r>*F37&e5pAN8)W#Er#+cbL~dsZb^ZXkCf}BvafIBc@6Y=
zGoX7!L}(a?l>8`jdC7U*IIj)IlJDrxle{5w6lW^+TIA?aKE7Dw;eAx{a#c;cYRmNb
zRWpTm|FZw3dVW0VDEm3;{zCTUoE~camv0`j{h;RmeW=VwyXo#z^1tEvg7f70LdQ3Q
z61InBfZrdK0seks8Q{04mH~c`cv<`^Rt6p%FQE)P_^n7jAh1$Cc0Bm)KTrlto?QmU
zm8J|R<?CN716BBj^k`WZ`&6!WjeOwBf?3a12FS-U&y19ThGmqw_)1p>IM0>yqztq!
zt3R)_WuR7}zRVcPz##Q}LmBW>_YGyhaDO#COeIjxr0w#y)C<Jjor${nQ@sb!o~4{W
zctfDv1Z*k&S{t6d`~&=gn>4mz*H)grwM~>?nlyg!?m+6z$2Wc3MV?o}`BAM;dGnyJ
z^Tl?*6OMjmLIWl!uO;;NLYXJJ<Ukc~xjggk&-0UcH8ZXu?>oHI`;pW|vS8Z*>cEc)
zL!jOc%6-V5eYFmIWL`nTIfb0F7B`k=`m~e#fb$d1k$Py1S`Wop;)tzi8Z;%I?&Y4A
z25LoAQZlGN6-^1LtDZL<8WNV`=`g(1>F~@Ju96NFOGpP(9`xO@jgk&}TRbxz<eXT}
zQPQD&>C$0_`aUh1J_)k50=&`iiB=OL>0qw-qkqkyf4vmpGde0#-xhLm8b#?)YuE>s
zv$Jc@z5_iv_wCx<%S+pY_cKb-uxZ$Mc&j!oN7#-J<#rYt;I9o13mqi|<yr5lBrn<F
z&QD1TXP<~skzRJ3D90T+{(@4E>5sQmkGpU@u!#Fs9G84ITa9mw6nM7QAn|Puk+@HI
zQhW{fzEVcnkPV*{>wh)QwM!XiX#?!g$4S$TwuIQ=P1Oe8HHkD^(KMfk4YHqP14&2T
z=SBHN`i0XpQu2WI@fdn}Q6ILk*C)GQSZHLFwh87hbvhSK&!Xwvgz)w&^LRRsFCm?$
zs&RC)Qlj`s9H-&lqQVpM^}}?25X~p2r6HyU7Y`#_+Vm}&j-`p~<PzdKSdDA08ds4D
zAo+R@?%kgh*N5pz8~@SN{8!RT^4J?{n4)Xx?O!xZ?+~W&Cxz(|`%AD4wl(ClXTRGv
z)EC8VE8!ZchRaf3BC*k|RBR>H!D7Od@T72+U@JAXwR&wRCM$Iw|4e!QcvzQ7*nHKn
zrIir2RfH|$Nnv}U%^nY7Y4hbWu4gD~k}oBElhk{*vN)^~S7n(wW$xwu+{3Qv!)JJX
z^2|r_hi_V*=~S_+*!S^GtGu(9wv;(P?j{_Dcl44EXeMjA@@zz0)R#jYABjs4b)sx?
ze|Z5~KriC1t*F!whPXWQM*c7^&vaVqxHu?jpr3nMo?Dc-=+ni}FjVrK#8b*w_Nz)f
zxg7^6$BU+!J^4*GoXFCEN}5GuEAPkR`SiEOkHquoPD>q6Sr_H+q?r<lVsTl69|@1f
z<(aRT9>(RFPD>q^rGGOnd6FP(Mf2Z_q;bZhad~Eg{$X66>9o{wF)bngRe8?*mqr<s
zt!Vxmj;%D69w}$feC7Hup3ihz>Ua(;Wtx4d*3X$*iHW`pNm-IA<hV6ysE>=jtvo(-
z^tkZ>UO@pq;a=fU5l{WpY^y(oR?}mjt7&fiv;GlQxd$L6Y!AO_OI`XIaWa%k`KB!=
z9Z`<yziA&-?Qx>6-YcnM4E9)oJMZVPhv8QC51OPjUY6P>aV6MfNfDbE^2iC^v&vSq
z-E$Uq3D02@rRni>gG~LWGs&~s339)cI;&_Nk^9YIHBaR7j!m|r@&AzcZ+edSmnH$7
zoc^8(O5>-5zqEEJnlHo-hUd)H#96kYcDTT??B}pUDe{4#Z;RG9EG$^ATiWpdN|+2~
zy=eHorH*DR8vc#Az4jd8FOAI~_7>4cp|s&oEf)TfYFo8H4Zk$0<(WucbL`}pMde5C
zJI`!@J`9&lW4w5(U0d?Ip?rMGwTjx+5H5|{Z@VS$gC$(HXlw4Rc8`YZnT^Sk!WAt6
zd~AEzPS)|8U6Fgcgw>H_`uBT$hvILk@1=ZCQtYbl+v380hH{?LRVsLNWEAgUOsW+U
zM_HTBf|sVQRTaA`?`B+azf(D1nyd1rQU4qv`O9F3rK%l@rcWsT*;zc2KG@;ujm?tm
zV8itv-yYgQ;urjc^s!S<E*h@IxOIOtT+eJcK5w`dJt16<O75dCQIUL82HS@}8m?zH
z0!s>4Y4VMxl=<e(V)^FF67r2bHnt}|l5gUwKbmj;ct*a-R_#zUefndwaLY&X%`+Q`
zCE1}g`KDj7^fA0|THQpS<3yxf<4p4taY@jJ>z}<%J309WMEUpyaSf>_rH+1ld)TJa
z@?+8awLCY9dwrXZ$76a*hO;l_)9_wc#_`BjG(IWBC;K_#Q@Z;9L6k}zr=s^>L!9(&
zvPa`INo||h*y`iNCnt>=RDnF=WKl!OJO6YV@rqoZKKiQ`|Nmk7nDbNd`>-Kj<(3fU
zj|sEgbA-8c>7WE#NrU1c*6%+W?&9}fLq7{|`H;X?8B9UCv}98kxa-3$pAW*uM}?2)
zD}vf5ATTT<#7AyHPr0_{LEj&-ndI4iWxTwUGimim{xw`bSG~TZv81(x;~3ZX{s*r=
zu7v9wzO(zwhXuBx@&AtNhd;c2(M||n<3q=WhD`|diVBGSmu+AOL!KIj;x^Fz!(k}N
z4o+%2%v)Zp6|=(+*dgIz7>ayk^-|gvQm5(9dhGvaroZ93C)Dc}je9QFUHuPSx1{(Q
z%4>o&F4!dd$$dcXDbnuWq`&SzUB`@$l$GA-`BvKdK=FFUP~Xd1y|NVzx6<B!j&PT*
zo_P@TQir{GU1PAhseH&{vjwraG%e+s+wP@*OT8WuKu_+-0DV0r?dQk0hjpY2KNh|B
z7QM%2ln`!tRt|rTaF@>J4}z}Pyfk4idXJT`w^8q<+42FE?M;x+iBcx6P`);)Vec9d
z)y;R*0Hyx~KPlH6Dt|n_Jy;LXo8L<6D<t=JY3r2KA5QK8`g0!d3l#m}oJactiGR8W
zzdgL~$Z=PW>-(bdxml@=^xvCZIBp1A(f;}dd*s^VfUT%Ke#ai}HT8M0s6B?@PRi@Q
zYLAloMm@_O`g2OQhw9&h`|$JF!%58_!48T!G+IRJVENv52YXz5XpeybQTqJh$^aZG
z3StwfFH6`SeCv_wwRpc7$;ZX}%}8D~gr%T_u>3_>v{nz&=8>=rAu#_+Sc>-@k+5`B
z?PA(iA3MosQf|6}2^E&R8Ww%O=|1{4(GaEkX=gb@!Xxo4VS7-1T=>zDM~nA2mFqpN
zubn%;msGwakLr&<UcS5^{Pt*ml5bW)4}N>JuU%1F7$Q{E7Ui+UrYGA%iq8KRTa;9`
z#1{JFCEKE;vSqM^{<p_%(Mru1vW~rM{$K@O@B+55sHM-Nk)adRzNe8&{KaOEZ~Au}
zQf?(Zvz2enUR?~GZ6z!c2Yo+T^?28?@u9Rh<s9#azxDBn*8d>KB`x*g_v&G&9OSqJ
zSzlLrb&eS2Ca;AQf252`BbK)L0K?#>qW2C{Cw^p`3KG|e@FH<dP~-Y$k;r<{u77e}
z`7plT_)$`PCG1a%Z}`LC9*J)>$4iQ@j^hPNe^f6wd1$5ypu{&0Ey)fp9M_k}N9|CL
zo{~}clRZfKTB^-o>5FH07K)TOSFR>ua2YIaLc$^f=v))1ENZOuOTLNU5*Fhcyv8+n
z5AaTGGIt5B$%@cD(>~qW;=-k|&KJUB8eT~ZoKeTx=kB=hN&9|I3@-1<ce-xkZotaJ
z<1!b2KiQ)9tU18}C%!xX%A_mJ-s|nZw~XcddxOI)D4X1;v?ei~0#+^EdOd1x%iiC0
zE;qD88UKZ?b33mHtlzYs|JH)xJlxLfBJNUhZ)xg8_jWq@SDKs8$+1KCM+Rm_&a_S0
za%n{F&<SZ2v}SF@U7fV-Np;`Jbe`yt)^f8?kHQx^G|p*%biwt;!^~ds&74Q=-iT|n
zmcw<cdpiFg?ho&^=Y{TJU&b$q_}p(v|Bf^KhGiUEyw;|W_X*v_-J)iPUX8oesE=_C
z-v9I(y#MWM>y~!STr(PFT9Zw+UVN|clYopLf9qei%Z}-@D{Z`c_0;<E=RU{??NBo@
zo`>YGoW)(MAsgrZ;XJg$XMIN0yz;`mw|jPfrBkE5_oAlV`z3c>N{yM^dpe1`cJJIQ
zXf)~7ABLW*Gjc}jywew=y4TzF&eD|$eHSjP-N229C;N8dF5-I&x7gSorjY|L1g!1+
zldfrZi?7!8oOR*k5<AnI-Yrr!8XwxStW_E5_DaJB7iuMYObYGiKPhgWu8-|se_VB%
zb)aRfF0UkAXAUN%{9b%z%GEyg4#vLI(js}kSF4}q&pQzC`ogYnjmclWec;vpl(lrF
z9NmqcaxCO_gZ}Q@Oxp%V$4%?JKl_J`7KIJUckej)QkM!kji$HaZsVw}wcF1>{Q0{t
zJZa6`(ypPiT=8#$>!4-rH&;nqdSu@6q>r0fM%=ZT-B$OV<*d9@U%g>FhQ?5W65pl2
zwAJ3pfA_}|<{J{PSKHBgM5Q(N>h)N=af8za+uT7WC%Mn|5W75kt(`53f7<sZ-rK#k
z!nmla!?v7i7Cigsn5rwYn_f*yuNxV*$GYLh(yz7Ci|1gi$&BVdt~@_xvZHf$>S5Ev
zHOu6?o?F>?z|NWVR<^7%y}k(@%+4zDefHYArCrn4RjDV9Yw*tM;1c)Kp_l4xnP!`5
zIhQ%Nl=Mh(Zn3KRh4q!zpUm|CRdaW8<+iobZ*6~}!kjj75ijpL%(LI+K9X*}x`F+B
ze);m4!JDsF_^i!q);ad;KFr$t)~nUBn~d$CleKlrzg{|b|6A7J<pVZ$dG=aL|EV>2
zOS?AHfBPD|yOjFs|Nq*$rCl?(b_dA^d)Age+ON4w*$(z@JG&k_Irm0LUh=f|FL<Sn
z?xSrmt~U3X7kQS`nyjr-^^YSLL;QMmzPfx#RFdVmfP#SFvsXs^(SD!X+#lp^zPIAv
zyHP)TyyczvL0sR_<L_B-?djN~ze~W)DGdY94*cd)_Z^q`Mx(T2=YIM9N4x$S?lf}f
z?;nImxSZU6YF={r==AwR4#uxOV!qdu_Nn4ur5>LI#9zwII(}>5JAtV+rZxM_uU+}*
zLy7BCt=a_yd8BDHqm=vflyRTt_Wyc+^TUhxUU>JyvfYIy7q(~*y_FX?Ip+PU*OT$@
z_l^>e5kA@5Bl}*PX=_)`Rg;(fa;NIwuCzX|c~AMR`M-SHWT72nMU;B?>hYbCcQ<#w
zcJ#Dyjob6LYMx`<Uwg6N{S{Z=`SsI}reC_f{M8Lr7w)lpvrOKU_PTY(HExY-+#1)o
z)tbyblKa&MPJQ0^xk0CKqwX}V8ZqzE?1ENr9lm&cX6Epk!$WD0^I}hHaw~g5tZqiV
zm7}zGdkl42G<?|GQ8(-L>X+Pl@V%&64Uf||<5$I9w>>X!v$|lnt5R<Fo4sClnEjsl
z?c=?6cs8C9KEb?t;eFceQHs0q{#S2}xNrX3i(YmEEiWuzeJF13MB^H_T9eA=Jvybo
zQ9osN^C6?(YhicB@|zB6$rVh_6|QgBWJqGOj~N%;OVVTAs_+kN=dAi_NNjMIo|@R{
z1GWwv^or|m<p<YvtQ(*33C|z<mHN-`%laveu9yA1f0^a)-}<!M#+;eo1YWU@E_<>4
zi1aa&&eFE(s`$5bdz1ZlyUbr)r&j(Sd$*kLoYwY^sn+BA+R#1ss$3qI|2|_d6?ZfC
zWJT}UP@`j$&g+^udTU>9{n7SwA=+_?2d^z`cyn^&cj>R!Q^L0@{kyC40uTSDi@yHS
z_RROkzqxkbI+NtdxAIn*jau@CZmvc%Tk$XN?M5$Io=rQbI}$#A()}*OjceS#)?4iN
ze`k%`(ym=w+BIqaudOv}T=Uhq=Bv$l*2+-ojok%K?Y=$Hy31?#?-t~4(bZdP;d9C7
zcF#ihf=PjS@#}a-v2m07Wv|sxI={{S^}{;XGMYKGzMLP@_sbWZtrkytJN~a3EpH}h
zH17wAySF~gm~&_U&Q@tvkG=P0`5$W84L|?d=NtFGeEF|6jv*t5^DNU#@$Z7C=UHo)
z@H2;Z9avB$Cu{K+9sb>G!+zUO!q@)8%wOKCu=w=OmtJ1>%dX4q4!#-w*-qzo{93lS
zQq$vn&n0}6Ql8(8Ysi}1{%%aPce6FA3+%V_;bYyYYKr}SKjbm9>+5s(w7<}3L~fqj
z_Md#ZC)*85bROFB=dB-&nXS?6t0C@s>>TWH`+C&9kajJ{My%>l_0zJO_Eg@`TT|=a
zfeP*|_fFPmZeVI2M-B6yGLI7T`M*qG0@NC0b7M`~s%Rhd6|^sEI8U8-^lzQ#jvwm0
zpUNDFa=r2#>jtuAvK)eZ&)tt|(XUXNs+xl+ueTW^q|r%#hodO3)imFt5*`~+=e1<c
z7=1jLGD;a=hiDGrPWpAp`Ql!}q0YJZkB38@Q?OLw5c{k1-6?am$(q1L?f;F5vOI+5
zFgg^s-=YTlt8=;it@E^HxSl%ilgwY{Zl=-H#a~N~%f?zDI_Z}6I?C$|O;42Ozmg9;
zP{{{;TGk9er=cUzh3H81bJQEP#xH-g9U6e*hb9p9K!eb6XfQe(4MA6+q39+w61|E>
zp?{*|QCV|z0@@6nf{r503(&J@B6<;BjJ6;?%TRapJv0hki%v&BMB~vEbTPUC{Rrin
zy3OczROWHpiHd#2PU?JC$~;&9Nju5hLSiT4qS)zkRP1yQ6+2bHE@G$GR69AVc6w8_
z(^b_@1*)Ao5>K&{7b<p|iHe;PP_ferRP3}C6+7)j#ZDQh*h%L5GT6xlTd8v%Df94%
zo%pA*2iZI+Z!e+rMbS~VHQwlG!tIMnymp~tZx>MK?fIAd(TYFnoF%Q~?~0GEu{~D3
zp14!zYf<KLDei7k5qIjGCdxb@#oZP4&q6<kL5c2)`sc2?lX~uH{)IoqT~YrMRCiRR
zPxVio148LXSNys~{kx|6C*!S)uTg$ft$(!qrp|Mq+(RVYNluL=$hNbH{nU8^=#TPr
z|I{(~CAvFO<httk_GeyK9UuNw|CIVyKORw;*P!_Q&xia@7E<apKI>|H**Da`>KNs}
zeV#gwSLwG@{CZLk%6%#feGv^Way@nY>)$?49WPqqc?;F+Nj)mpTU6wF>Nw56b)FVK
z)bWwZ{qITnCxOhOj#pI1qe=de?)I^giP-$eKVk=el;(_P6e{hHF=!W5%H41@7^QAu
zj&$mKbR4Qfxku^NqvO$S=mhj@bRwFAPDU@HG3aHKdzr2foq<*&46$exbPmcrPZNjA
zoQiLu<N?jw=qQxeCpzk4%>oqLX}A~alF>ydb*5%9nu*e^)ty9_qQ9cc&|Bzov|L$@
zW(E2px)QZQ-$#3*YtT2)WYia3i-w>dq7f)@)XhXcLO($Hys!Hh{TTfQ-He_`x1g12
zSZqaKMX`y_2Hk<m_|c-}RUJS1)b!J0D|I|$iS7*LRnl1<UuaBc(&4`;oz?M<Pfb4;
z(pepUsEp&2`l{&teX?4A#Go~BEA6wo=v1@;It`Wj(goCUfB%v{QeRu>$CEJ5`0?kJ
zrCd+KC+(Xm=yLV?N<IIa=eeurRmMN5rzkEOYmg0pb*5-bv=Z71mH5i_)Nx`;-}U0>
zIp9vhNtZUA_}f-JPs`uo#jZyYdT?Lmb%5f(xKqbqJ@EfY?h>BjU%ev!spFbT^sm0^
zPU5vm^{*L!7r%eKgS{(o{9RO@$teF1>~ZZm&U3^MbqtO&Hb<@}_O=Dt;?(QCh4PbT
zF4_pCZK+&W&R566JlFa1?4yoHQO0FRI@0{r@ES$gOu3G<3(BFAC(5J#s5u&fRzSHY
zX)2<UFT_7}JV%NCy@)&UuLdgqy@ZN?HBs@;3Kjoqp@w{>j)%}_IbJ-UWsq)C4)&sA
zpM6ErQ60Nb;&}(u^S)NkJ6PmAb)11dF2%~j7lcc~&pl6hPTyZ7oNAx^63;uLo|mnj
zcT_!3?4|Z!m$rb$oaf`B_W!V){(ZrEl)S9rnNBwV-GB~9Q&DLjY(&Lgk{{GQ;!59f
z@z0cFhWymtRPUcN%Cn2c1*OfP>5OJ_VcQX`uLn^eYwB%+Y`6)QBYExt4+w@>NP-=Z
z1NmS|VCsM!xPm7{K|CZwI^;k;n0nL3250bqaEOB}Dxf4Z4YDC0%zX$OxPS))K^&w)
z7Tg3&U&04T-xF>)0Qq2bg7ppq@lSp)Fx5D+?*Z|UJwa&;Y3g7EdvJpwh=C+Xha4yb
zOCBO@!41M80a76g^1*yE>wvc9Zzu#AyI})EAspghDWpI;<Ul@{w<BKQ2~m)&!B5EM
z?*g!L!bac^@sI}Rz@k0J!5`va6Py533a>4AKn$#gOvs1I9XJPqAPzRken<8p5j33$
z2k0Of4uFLV;e#MZgbc_BtIiyUU`T*XkP8-FI1c`h2pNzEmR-3P1Va*Jz-cIiI^D1l
zX(Q`YCZL{Z3?xB1oQ6WE(;Yv+6Jj6<(&02Pfw#sQTp{&EGtCJ&z~8x02=1?AUr2yV
zxCxdNz|%eX9kjg&H+X{%Rzn8lLIGIy=6CRiIFL0mGaw%<-N-*M6k;G54nRIw^r1X}
zI|M^Kq{0En1=GId6L5tf(7{sJ1P34&3ZV|~m+ip~f*}FYAP4fn+#P?w75pI%QsDrc
zgF@hbq8U1rFv4ocfLt&iMi{{jq96&<ArCCxpk4t_&_No=`kb2Kga?K~I3z(9+yo0x
z(g{2umut#9E?ILo3RY8r6@skyln>S>*c@VTn*=)`2d;s|2>h8$d>|guXoO|Q;C>3%
zgqu@I%V~tq6n_f{kB)Goo7gYp@098I!{4T6*ac4Tn<IWC@plfyyohbkyfcLJD(=c*
zTYis)!kO$_nrUJ<<`~QM(Q|MUT-moTPy9f8$5a!GTF>ITs5_dDdZV(|Zz0GUzqa5E
zIUEoAk+Q+xvTn;cFrAIRs4I;NEq~iVw76kE1$KZ;AZ7vQD)Sp^O}vuPG|0n!CYl3Q
zb2uNgggpwfAhw2?#_c6DjcHBxp^lZACK#5&0kEuPrU`-^=vLcIlMIz#<{U_X9MIOm
zAIJl@SIjh<!17fyO*GiNW~Mm}@me#DOI<TfD%7cGrtyYk$OGH@W~`}erb&Z3|Bt=%
zfy?Rq|Nl)P#L6=HGj24J5JD0QAr><EH&Ll5`g5y0Vj*OjWebfqnOKN5V$DJ<Tee0B
z+1g~9g%Dz)P53?E=f1PH+4lK<zn|~#`~7^r_j&Z}b^cuEI@k3+*SYR<u5(@QV?|t0
z3hplu2P8utR6?r`!~>~d(UEfirC@AbM`Z=B5Crj%0r^l47M<!~D8uxxY5}SP)#Jzd
z)SK~q#fnE(tOL~xD%JfCx-qizo9V`l$(Yt(*!BP(g7{jJajT2iE@MoMn{eI2HRf-C
zmi01L^L65mgWIf=G01aSFJsAM{O7mCDdSC-u<k1JGTw3-^Kz_v@H4!?vJF}V;`c{I
zT(wZ~3n|}zsf*TwhR_Ja|L8O5v+x|qchH)nt)LCG11qSWYUWu>zQkvc<lhMDfJ~A<
zYv>G}NKZf3cVk}sSM>z(k?O*_zNiy8!(bQ+;>XnuoY+1ZeHlDpB8U%nnQGcKlH-fN
zE3vT&`-oq5nZ&+gPqEo~XiGX|Ea499@f}=*>PfzPa*;4{KI9uC@;#AM2@CQqkLq(`
z)rNW*<eLTZor2XM-zSjma*pJj$oDwfaV$B9@~sB>E`tlpO^8RncT_#ecfjR*ya}tI
z1z|d%Yv64Vzg3A~4eMb8B!l?Hb%D*yZ-K3_1JYn8q=S6VN2YG*#~}X9_Q3(@4hP{=
zI1EQ17mmVlI0>iVG{|>+WO|Xb$@v-r!=Ne44(Lb_pGsq3EI7hAm;jStGI+vN@PcXJ
z3;r+zWEz0Z1o7!5KE%YYtTTjx7Un=C%!epg1ktb*mct5=X*agr3c(Os!_M28Kft+o
z16G1eV_7#2CcrCDJ$=CZ&Kk?UlsEBfJ{_G2!O(@gFXA^?{J~6TUi_O!Fh3XOL3fsi
z62~yeq)|SGb>h#v7wg4;^lIkCXSE~C;!|guDC-+>Ez6kU*IDk?o@)iZ=LOC&;#o%-
zyG+_k_36)Mofmk6FH8rSK0}Y_=f#h<hWNvw8*vU~z4($J#QHO=3t*l2C0_`OpeM_3
zpyKDd5A*M!Nw5)|SoVVfFbG~Dy}d}wT>Y`+8;ep-rS6dO)f0MwIboe)2uRtGYg*3j
zKo|rTtUp9NmtYfdoj~*96r6?XX*1gf!w~)PQqV214Fa)ED!K#a!F-5<g|HZ6U^%P+
znbOb?VHc#s9+2q@$GZw|vAi1IhIQ}`$W+F*8*mF`lJUDuIA1dMc?J3KfN>!8;TPEK
zAS%8?vf(p00$;*ca14%v`0zRn;)nKYD1`6e9Gr&>Ao2YGKf)!r0^;}T8kE6JNXG`Z
z(Vswku*u|3S|-34koqy3G`)t3PmmQ52P@$%SOsg~Z4e(^@4$N402^TwybmcLK29XQ
zRM-LH*F}8Ih+nH+up9P327ChhK&G*zqX+eBThc1_5kEpRSvM5izzbf1;UH-(hFQ!H
zgOT73o-hJ}ArwMjHq_=ilkzx~d*<rNn04}f*JmkbO`#dIfM*Eb8f^n@p*@(fZX^3{
zs<Ho8=C{{aPG|n38q52cKcrtig68VykD<r)^NmT<Gy3u(={m*w0{ymc(R2Fwi|8f&
zd@ahGk-p5yKBmk+Q)BrV^3(*Xr~B;pi+*2OXF=GeHNrO~>~l53i$maN^=WFs`j$1e
zwP9YZUv5gA&1%Hkllfly<!0<}sgI)%>-y@~%eeR<%)9EBN1^Wec@K1)etr__sh^*Q
z`s?Rw6Q{90UdhWM*2n0#)nmPhep?XhLiFn;oR;~y`sId%X`~PL2J7PV>*LXP^z-t2
zKO7s0j-oD?dxy_tAIgIKZl_{{nrvrz2Ydi&@FB<~BE{PdoWUJ55CyT21Zj{7xljl^
z=Ba4ARQxBlLY;uVKGHu!`V^?5Ar8_Y3ksnG%0Zr0)gaHSejv}RiI4&rkOQR<%`<Bp
zBtkM|K`s<PF;s!2vF<s|4s`}kh=dr3ha|`Zr#kEhrgga|1UqmBH%Nvw$OMae<N+c<
zo;edB1#-cg=f@z31bMbhhBU~80w@PQ2c^P|s>&K%z#Tjx0Aj#|=f`A7hwA6aV&)wh
z5+2+k4UBmPwE#8Pf*W{(H1@|qHWY$sBlZIi@CFS;K^!DODr7<q<U<jZLKT=c#ui`;
zPT&e2poJJng$&4n0w{$T%2gJWgNiy(zPDuw*5Cl1PysTA&lIe|9-P4q0w4zBAqg^}
z0E(duD#3#C9Sd>|+d(cAKrvK-31!^^)ZhdYK@0Ja1gW63W1ueFdlW$#sHh)Jp%vJI
z{I--r1;|V4R$vYG;0&G+2?>x6S&$0_P!4|0Ne`H|po~B|WI-X6Ksi)_CH09txI+*`
zLJY)18mPI3Ga(l&xCe0qd7d%R-y?gV36KL-V5=tI;0B)H*Ouc$5tKn}JJJYd?TH&~
z!2w)gB4{BIQXm7wUv?Q(f~gfY0B7(94J1G^WI;X@f&6wGQ_om}+%vg@+#}09ZY-og
z9u$G91KS}MOsz==ct8TAKn7%WB5z=7!})_sFzJjvz#3d20HPoc5+M}|pcpE^%$BfV
z5ANUx8i;~KNP_|>g(`6GLOLK7G9d@@p$JN$3M{))2Ehd;g7{R_KorD78sva!H_itn
zK`LZ`g&pBR{P872DL8fK+(QDSKpqrA36z6<4~_*M;0IcWfdp{2XC4wD8PXsNoO+WU
zh=W8ZhH{XXf@Y8g6=3YZGB`mDBtSA`Lq14bxp7~v1F#112T%bxu~M0Ww3FL|Gq}M-
z&_XmwyLl?)Kt7a#Nk8HO2XFyzhyrO#Pl0U6gHkYdB5fe;>P7vr;{ehPIZy-@AZ_QS
zkPk&r3Kd}H%yGaP?7<y8Apl|^8PXsZN}v)f26AnH6HEj@h=wFcg&dH!_A1C2Ou2R;
z-H;6FPz0q=39W`uM!*d`K?5-m56O@Ng-`*;L$M>+f(uLp4a7hp6oK6^Yy}#Kf>=m^
zWJrTtD26hq1Y=k70uGP_WneiRdw|Ob;)ZmPw)Uu(hyx0t6tdh14^<#-=Sd)K=X?NH
zWe3iX4JM<pEx14-n7DHc@Ps%>5*<TW$On^`Ne=`-BxFJvSdJxKpc&6TkPpRRJb~~K
z0FjUmttMgz(17VAt_g^N1jzQ}98Tf4AH1hh?jZ-{J(;`<%K>>07U0WyfNaQzNI%LR
zWPqPP=NdA>MZ-3Tg+wTrjZMR_0k}m_HXt4X=5ih&9ZJA5lKepVJaj&JfP`1cD_BOc
z4yqOre>CX_v&GmMq96k*K)r<HfHx#UDx@zZ&oS5ltd_Aa_(2AgKn18?BMexA6-b-5
z6S#s0cta3GLJVk^6Gtox8ITWa%yjKG{mgaG)2C5+Hj{hn8y$FdU|HI_zD4C(sv#=v
z0Ik_BZFnotXIYlM<?{UWkmX>OXQ9$wH5`@pGx@%zJWCg%@=SCFmEVwJ{eBlvc}{Fg
zcxex`VL6;|XZ7owqSCHVhwVSJ{sznP9Mm6`Hl(Gfv^6~=%Jw^`JQF#h^6dWuD$jhw
zQTdIM=k;Nz6U)+ebPkngKk-T}?HSupX=@sRO8bwrqm4o3o?O~LPq8e|yRWe<ZDrrH
zEOv88rA^>GD#z=MN?Sw>S_^GX_@B@^EYCv=&>skwkIJ*;5>%eWkD=0z^aA03MvGXM
zXVv{IOWUH{dr8|(PgL4Hx}j%ey<sv~z+eG`1q>E2SioQbg9Qv0Fj%051&o=Ws;b4^
zBF_Sjo}uBMq0?r1`ULy+wx1s6?-?8zGK=p3`UiRXhH1k+Blzzb9_H)mqtVE0aA3Hv
zXJoKec9P)Aex7_eko|nL{#{v3ypG&e*Yf6`mahP}P?cy*p6JLx->}f|(CK`@{^d^U
z(Hd=FaNvA=$*Kp325SO?{KIHAv@-Ydn&a!`qt%85PK(g`hvVPY$~?e7NaG(?b1m;h
zSns0^;ux|I>GKNLk_xY2pAerJ{=xp@Q&_@;YyIfjV`Z*$WgSkxZ!7bmxE%KL(FTTw
z=)w#fH2iPExS30P`2hVlB{FJ>1$o|s`p^?Dsd)}uZKPt8d|Tv+S-e8Sy!`y9`$Pn3
z8B6qM-^$T_S46&tMKr2n{*A7sA?3Pnid6e}m$q}6o&!0Taw0=%D|KF@9M|hN2WH#f
z`4F$^6FE~KH%&K6o_e7-)jUV);tsEwCpIZ@Oa7lSIqznr_<D9mOGu>tJN7;yesY$j
zd03av&s+VPPYG}RBz$O)pI5+>@RH7IKh>^A1Y#NjVgqNmtLB+mNvFvZyR-T)(&((D
zu`y3#*LC@`avRl0@uf^u`ZWJ~eEF97kGgQmHl5w%X_IF&eR`TQUl$t7N+vtzC<{;0
zW5rkMwN`dYn$${&-~TgP(t}l!rUANrNt1)J-1o_H@86_xRIOjrC~2x-|Kb+BiyBP3
zg3%4@)b0KiQy(<5?{q%%{iXei55zT3o&V9eCEL0WSiE~pK7Bj}N;rqdZ|pl1^~;8N
zKDK*?RXy$#buFdqgz5RqUX6}OZ55GN#B-?<U)v_nfAW<>-Mg=z8Pr&{b&a)ew|<Qu
z_6mNhp-o4tW#?9GqyGhMcWR@6(=jVmJ9}Dp+v6Ym%;M>HJ}&Y;KEJ~`e=GMb86#b8
zVztN0ao0WHyx!2h$9g~eQbxTw$GR<!8hb2%iuR3{hrTtTd5;5mv|sHXAn`3f?Azee
z1vxk7Mc&CdmsVkUFY9NweM2wKJr?FZw_(8`^6cs);S#zujK03WGURHns#1eb=G;yO
zpUgWBxb`&<ZnSX4?6GcR7HoL)TbrTAi?;AC-bKpG3#XDczO#B&uPe7diksUk@mxi%
zoeNd&D>ph$u>WpdudRD&!%@m}T(1pX9=|@)BXq!t(~lB-FQhDa>G2o2U$#E}*3I&+
z3wO4qe}fWVrJ48Xh0m||o}O1e{Ab&SKiB?tQQ^pGhpM8C+HLT?bntW9x0G@^?5A}$
zP0WAXlGbDQTRU4U8JWJkXu*+br(V9A_rdy3i*}aNE~~`XwQI*QlOGMW>UFoBy4|H+
zMKN2RssG~g4=*mr+;#Mt+V&IrsnAxdHcC2l?9IBDXU?<vVz)>4f#)xK?>o|ds+F7R
z7Yz(PnM1UWSBKvie{<KMiF=luOzm-IUvIk^yC=OrVfU$bY5P>_7nAdkmz71|?%Xt>
z&w&%8*Cs?iO8(Kt<h$>q4$nMs%w+W`?v(<?&XWsX>fyaBz16+$#{;gt6V&sUU3Kc)
z+&Z=0#PihD`YlJ%_WPxBehogE@6ONJcD&K&FTJz><fR*LF^-NOYqilo&)4!l>O<M!
z8+qW})$_cA=Is4;;&nH>vM-C0pWj%IcNt2(@%Qyr1;4@Sf51oG0VTdGzf?5)DgVNS
zhhrA^J3iT}?9#bq2H(io@1;il4m(`?VC7fmoj=`O|L&udW2cYqTK%=7+r0*F7CmUp
z4R=d>vGcJOEBxOdxHjI->SShm_bxZ?9qMJ~X|~v*>YgUdwb!t_^!FMn;r8xq;y2-f
z>*JnrbC&zu?r|love()x&1<C>*aYpfSU-+;c@e`TT-0KRi~+TmTNOXF=yx&6`TNP^
z-QO>+3?Dz;X70HUEoU_0os4qa*4sD#XcKxT@xyt>KBixqSs&fLJFM@!6Oy(!Xws-<
z3+b0(@MYZMVwzvTiDK{Ymv64DKWj^$$s?Ux@xD&6vwvQG;3NB9&9{}+P0ZW%N~lrn
z?Om1)-(J6Dc6{eVr}TGt7E<mb48DvFzKrF%{PudjZ@E?fQ|-!n#y{tCYG<>tlRi99
zYh$CuUi)erd>Kz$_}#fJA9S)C`Chk*>l-%tKU}=MzUQ(w&adz={k?L%UFmJ`Wo+<e
zZ181#*?Hr_S<7#K7Ipmk&^^PGEa(T(Tk4mYW>?GIC%+!tD>yNDMyoaJ7o~fvo0Rx=
zAASGRd`p|x+R*Pvxv$GDde>@Q*3Jg;G1tx2cgA~fiTLvEdF$+2jjpvQ$1VOX5Beb}
z;l?Z|%<9wR>viuQ&AXm?Vpm2#+sVxu{L=q?|CKMael=%?GyP4J;~IP!cUsnTL)e{{
z-hS!g>wCN^==Y)6@3Tv*W?TwckbL>Od!8@7{aWOOp#$Ih;M+}&m%q5>{kImkp+R(u
z60Xh1DX;nEG+&i4J8ISDWsTQrk2<zk+W))IUKQIPPq*u_kp4i*^Xm5(7j<m1?~3iV
z70#~q;bV<X%{tdMcZcKov~A~(wwper6MdsBr5qgCH9T+fQpb+V+(#Wg?-N~n^Tqu?
z<j%X*;{2E;Io;peO~0h=eI(qnyk~D{tk*XD=I5wYKfked$>gCGnOP1qZ*;SnxjyfZ
z^HRp;(RWO3w5Q?W_Os3FuV}1Uu;xIp>UHziUj4RDQuDd-KejLIGfzW%gu$0_K=^U%
z@PlWk#|JuZSQGN|nxfr@P3T+HQta2gX!hf68zKfo_4=UO*3V|Ho3?1oR||)qKlPQW
zq5J-=y9sCTWgPC3yr!q!_>G^=_YVJf+YNR4C*yX}&rzvgN?pDT3mOz2eBWirN4{f<
zYF%8PcXPpnYwEY=-fNNa+3r=eXDj9T&7JoTG+%Z%rqs^EclcoYs&PBc1}9#6FMMc6
zr?Rxl7OyadhZh%Wqj|I1b%<UUU+?vpea$_(ERMS}F#fc8L-UPmKHK(rZ09ML81JKm
zvpo8;@pBVaEzRnk)Zoo=lPu18M$D}@dCjC|FMg3VWYRcq`tvE_?i8<zX*J+cH_Js=
zjFRt8%e(Axbjjs7``(G^Azv(7pWK&mSM+sN8$EyZc$=Sgmz>xh<?m(iW&Gda%lLoF
zN3lwIuVL^#{Qt}Mu>O6k@*dW`4t-L27i0x8(N$9MCB^F|#V0Mz7*Bj2>ED+s?@@oh
zAMf#^joJS>lznB`h_at6^ZIw8(j{K;l_c-`X!2Dingf*MJ&*EAR>f_W;!}v%1JQOY
zw@2ljD(O?=b7x-n&QkX-Q_?}x+!J5M9SJAt;GJkRX;<;H9^C>ZF2$E|ca-Wx(h}{A
zGOxs|W?uj9Q6=vrC0-t#lyP2&;$tkEb^q?Zhzx#+=&w$@)BiR<L{2V@8-OTCf-ES4
zDv+@hP9Wnbq96&fpa^REAIha2)ZllBehO3~Rq(Iucc_#~TYL}I^g9&WfH4j{?^OF9
z3NU8;Ni^-PXgX9e|9js<HT@2i)M0$VdCJI5`iM|TSNj|KGhajE$ITwxcvq#mMR?|A
z+{HiYZ^)B-cNr6!0>Ae;q<&2|HsjCy4gDj&hU`1lQF%fXBtkkECW8eG7BE=AU;%>#
z3>Gk0z+eG`1^&(g(#5-`|3CaeD-9*}&1fG0=}Uf}MuQeKINVg@lZScfzkQg-4L7Lv
zCntVq*24y<o<=b*--I6zlVBYCjfV+PJ;{0(ka5E8;SSsdnXJ)HU<=)#2gvjotxX)p
zP*)$<P}U7$UdHpvG=gOhjz1o*GGEjG)$1&aKb+tD!Men{O@#lS_SZF$G}u88uz}7X
zQ%|%P^nt$mb(7H95UyXIjC#Tpm<m4N2Y==t(1~pWK&BaJAk5M)OJDrEYJ5F%&c8>C
zp#(0$UDo|~`<D7=_>~ghh=1o>s-_Ra|4Bbn{|Y{)<a(8BO?*trH7_c@rlhWrvR2c-
zl+6E`k0~CDmG8h<q4wYoo)84FkN~-0Mtvmyq-?<fq+KH)jH$RRKn;G70_l(qL9`#F
zK_N(6LIsHLUhxGL3u#aYrBDebJUUxK4DAA0kOxIj2HJ+i4H=LPmEdGb-3JpP3SuE2
zilH3jg9qY=$r3W4+P9J=13@N2wI8Ky=GD*O&jOMl4JttD%y>wKbSQ)p5Fblb;7pko
zzXIN%0cn(uhh%W0z80Tg$&dz_AU@n&IY+UO2q{nrCNyaKK^&AqC795-Z3*K0NCVMO
z3ii!OBcwql<U$El00VneZXk`(iI4}zEjd4+2JvYmeg#b^A98&aw?=6U7r&!+;0zPN
z4>TaYNaG*_EY-AGLIR{fc3TxM^(YVE1eIXjp1L0Vz`=^}ApTRupG37kBJr^)zC^P?
ze6x!G$^@{cQGFr=KpGT5nW!~oj|O%%OoUj-1Q|nNVnZAd0Fe*_d0j{g*mh+bctZk+
zFQ5X@*m2$=6UxD}JLd?}!L0{jAqNUTKH?$$C;T9p_m_nrzIrSm55y;r1*AGr?m$JG
zt{G%P2~<D|{Q^p%5~R;TCgg(gOOze(hNw{-AH<(aqC0UxF<6YDyud_Ik3}H>ay%#(
z<Jblh!FCeY2Z#?A=T|5nkOn1SHJRgpH^f6O6hg5l_L)MSLB4As-!w>o60q=MKag)3
zIDvf6zyrJ?2qGZ{;vorAAp=spiNgnl5|EF<$#486HTgy59!C7^-DFw(mEA=RlfeQ8
z3m7b5uz<k=|CcRbOy;Nkr^o*Xh5Gsg`Tx-aK#*^+k0zV}`yn%YbWQ;NoqYg|SDBeh
z8ItD`nYay9#>;aHsk&yzeb7%0Rcz9`B=8N@`1^@x0^eC)8f}=<T;BknFfZ)@M@Ke<
z`DjDK)YC#kgV^`aeFLbKvFg=h<}Y)M(Y3Szf#Eve0M$MT<k?4=c#dhwOl2K>iSe)%
zU!5Kw@sZ#*c%+YJta7dfDh?Br<Cf}o{hc^>XT@`j%P&Vi<6a7%1Qde6km;ei@%@#o
zm$sGBwcM1lG0G>{U*eFl{9*)d*V*PbmtzhM@|i)3b@7?7Ev|`d3(|}Y^CdmH_453u
zRrc}q4PZlccxk87kS_`E;vcS+9VA`qn&D-GK7Q+8*N6J~dueb8p@g@4vVPi-u&_{$
zsynVbsyl9&zjls~oDL-q9#7T>hD?i?KHV!kaK2<vjy(~*VJB${44Eq%@oXUZ_I|QY
zXoR-LPS2@~%nLZaJgW{S%*VR(qQs?nvX3s`gK=IV<N2%iDPbS^R>zHdO4(A56Tm*Y
z<8z$q1h7u_6CCyB)P-^&(+-ewu^FUXm_5*!(?668U0IAJ+*76}Wg?!9@|^ekGLgu7
z`HsZX%0x2T#Mj@`%0w#L<XacNFB9pke^J@zw`C%e^&7a?|9zRrt{J{YnaKTh{cp-d
z{*(2;mI*nJa(?$vfJfKzqRe|mXmA)J=f2v{f(dyv_*pRcSuprn7=6v)XCX~>j$f;f
zd(wtt^guf=zJ9B?kWqyhCo>wK8uj6sh+$28*BkQQhVSpU^1Jbvc8-1$E=t?vf_t~U
z*ZP{S{pPF6I-56}d#`^x^I?Xzj`RK3zs)&8+l~_7!c~qvoo}w`IceK_Cy%6t=k|WE
ze%Xd`FWg_?TKL}S%?~(kqKm{Ax^nxufK8)^EnL#DPW{s@Zx7kO;01@`kt^%99<h9o
zSNE-af5TD2b&MYsU*AES)FkE9m4Um?`ZZrMVe>Gn!{^Tgov~|Yb%A!W%}V+nIPSdF
z<E1I86Afnm(5!aR=ZC-d|D}Q1(H$8*XRSN)VZ|Dis_PJmFRk+PasM1Y3ugl*J{yOv
zoqG>yX7fh-n9{J3#Tk?1>^6P;R=Ylpy56sCH-CMF!Oz0h^ur50UW~nJ@UtN0W#Vi0
z%d@wcA8qhclamih9)GcQ>x{bXJ@;*zy5`%j*WS@co2i+ED|hOb);(~t#n>ZOCRbbC
zy8iOsWd+BLYwvyhVBm=jYddoz|2FNUYNNj&Ke9%-F3)FFretjUsL|-#llmI`ER?*A
ze`DH~)kafSMYp=yY<I-_>+;4wHkns%X+hPw+_T-T9MJmY{nGp0WsIvCCgCa)roV3)
zab`q_XYHSA6}FrodB=0#u%EuZd~LSPN8>YW-&Co-ah7mrdq3zu>F~|At4uBGWlv5X
zo91-6*Oe9V7oF;#ojdXF18(3v2T8bpo}YzUO(nkN^Hbhy({Ay|v%aGur`Wx0cIL~p
z22Hf3<7`XrE#KZE=a|7C!{hJXdiMP~TTBw(`YLVp;{7kodSP*=!5i`0HB{_(a-e@z
z_TZJ{x(0PwYW&{E4O>K499#HmuIAi|PFL5JZNE-iKkqfvMmIxyS|0m)L;B{14{msu
z*J~8Ae)o{ZLk|5gZ~wOV%g^_k&3o_{CEObiTSVsB?LFfZ`{O->KL(Es-r-ZXsf`xQ
z{-k)!S4X;@SbO-&TUXvWP-S#wkNVi_rLnI@ZEAcwg+`yB21vLmKKXmYN0l$NwX5r@
zD$Q^CViSWu2C<95AH$oYDylY~obz?Ft}Pn>vViw;O1(RC|D0<F$_)M(B4Z91_q+Jg
z7Txy-)JFSeq|G0(bj*y&U$oiu+T`YM9&()EXYj{h@W){A$1r$=)TfDiZH_z`v}$du
z=4E#e@3}lMqtDOAYLDAnLJmG`bbWT&CcY7(gj;ejFY@3AO$XQv+-Bq8t!~+K$KH})
z_3VVB<!d@ryxQq4e4)~ZL2a}#>+72<r=PeL9eMk?y*ZmA=4|<Fn^DTE_ewX`nX&Gb
z=oNg2Ly52SjgHS*T*x>YeNq!K|M8&7179`xV-Wi#d1n<YkGXaA#P$3M{yF2Uzu$be
z#mLC>nh*1LUQ!u1{Yv*OM%pbJ9(Vg<m-<9e|DxIl&wq2(^ZTjadwPzzwN0(Dv56Qr
zpKoI-cJ>;tsWj2_x)qT<ul^F}>)o<1*=BqDe7)rH-0j_Z_lTka*k8Hd_;P0E7T*><
z2Bh!aaPy__P93>FWw%q8ig(+snmheb;p7(w@*Nc=zD`3|O>8nhV%PH1jRPJ!<(58Z
z5<aB(>h`&-Q+-}IvVZJnd}EZpG59@ex5w>Z>Yz>Gfy;l2+i=}|&ZQRRmcAx~Hg!C7
zaFubr5c)GJ&mV^;O}g%DlYVDG=VSd0{utWOPP2ygeznmTqgMVLT4&MsS;pFfb3AW4
z{;=T35uMw7b!y$D@V0kOmGDf~u9bwVY^Uw8xz61SJ*JkmGx%c&ETtcr(r%Xivhlse
zBcFdYYFnp_=LfFNFPYo!_O$HXXWIRo@abCjU9`g;P}&b7A5NZ~lAM>+%6#gqJ4^OD
zw*F{~Yah!^!`}HU*l}04JB|1btx}#Z%?iJjwr9sjlcu#^m)dH{Cl_Ylov<?}?!#Su
z9~G|;k3YiqK$Y`Wp89gyArG@xHox0)R{f>5qjJh}-@fB$+4gN8=Z806Pa(|a=5pRX
z$<x+(!{LoL&Fg&>KlJ<2KQ7s^XKs0iM=MG~)@_-+Y|{?<b1Ug9y#Jo+$hX}#_X;@v
zm0#?(+x0$P($seE6uY$P9cndy-r$enh4Y_|2p-kG)0;Qeo7BBE{6^5*A8shS(r5|a
zC#J8R+Nk$K<NbYhoOE`}?D}}$`>)x5T>G8Sdhgb1yYt$ZRd*|_9?(ziISJQv&clqx
zdtSJ3*Z%c$-OhF$_~iks+n3vxZ1=QXG$QP|ge3elx=Fa(Zox^hm$g-HK4wlmj%YkS
zX|gA6+p3#3(@Lif^y<5<wMzA#67Iz|3vd2%TC;lj@Z5K8)CqZ?{}kJ4cj4i6_fBY+
zUOR0~7<(msS7R>LUHq{B6{jCYq;H7WFnRQ@|6l$X^zXivcjB2Xe(R5c_vMOzgj1+B
zO>(EvJE%ABMD_2e6$k3#ub>m_Jy<Uj#XFi;ZQ|oWKAEogJK(1SU;L_Qs(Y0)IvHhM
zG~Eove?oKs>WXU6S5SVsRD_A<mV)mesG{$qGtfuqOmqpynuV@GdHEZ?6Xg|m^ffdB
zty7!+i0CwQF}f68impRnL${!@=pOWS^bEQR?PG-RTXZ7I>5iU)CZqo7`{-3P1^orx
zg1*4BdMdgF-Hqm>AEDo&AEVaT<`6m-{S+OCeunNqkD;g0<7g3j5|usxG><8E#(vfB
ze3f^>VrQaN*@8^x2`6^`9;GQ%Rg7*%ucI=a`rp}Kg!N6z8)QtQoE0(;agaZkKBU;7
z)jY}}xIq9!K@wy^0aSqnh0GS*Km+lR26<2hCa==Zn7+MbPzCZWPHUJ58i<8NNQEpY
z0Qn}TNngr1c!CyENKYQ*GhYevT}~(P1NjbT29$tVKh}dE$Tv6Bp%CO-oARAa4~T+f
z$bm92rT%aNgWm}1W$sO#!5g9>8M2`mD#4Q9QfKgkSV)0vC<6<ri(w)}K?>x8d~4He
zBz>O29psyvaUkE^%!Ohwrc$#8R|o*9<Pt&pZs$TVR6(oJ90S}S2;w0F3ZM++8=cnR
z3Vsj^X^;yg@PEy3M9M{@f5>-)#-@%+>bnZ~J0B9+h1jw#VZoJ(qS}vyM?KEVTU?~K
zs6UvuTE_W9-O()68_h$jpp^;NBRD|;>&2Hu0G05c`IB(1Pub*0N51#@d!G{JUF)bU
zTX5V4lr#88d`pzt)lmg?ucN92!(_04!2$*g7%X70fWZR)eiq=d^f%-G19`rcZ(;vO
z$HI$cQd;rM3gvBR7lG<&8|wn;ubYbQfO#+<qF^B`h8S25D?p|+^h4MM>97Z6x<cCi
z(eeB@2zv`;lD_KI<Nl55Q!IVWo6wLT{hl|q*7aMKKFZP;S^6AH|6=J&Ec!t^(gViN
zlO|O94(&vD!C}(%SAG!wr+pyQC#^CzyV@7R{}$f@4Y6f9woS)|yFvO@%d~}dvTY#e
zC7JVb)(#)Y@C_8gIVggYkS`EVB;igme;Up}_4GaS7oZq^fQ#@Wlz@zxC<PgxA#q$s
z%Ru_i%e0j=G%@2;)9*+8AeeCsb9j~Y?~?ADg!5v*)y&^w-kW((m<$^UHwB#vvd=Tb
zv6gV_VVZ2GTy28tX)E*FYb>WT|51(Q{mdWIFCRf=Jhx28(Bt~~#-#NbkjdaTL1zaK
zY%@-8pGl~vetsJ2ub;1t&18&l^|XlfG5T#XX4pi(Er@j?`t=f4%lusZazny2(uaG4
zb#eOjG7kS8{d`To2{JyWrtbu)i==+~kNQw>B^|NABd4ka%E6ubI~nqz2&`&zeLyx;
zfHCcg7T^TZ7O3Vq)eSr$0JIPdIZy!A&$7lmms)@o<nugg!84~7*ntzcK_1VSrVV+1
z1#8eiG{i$Pq(LTln9^1TX^;seVB3gzz!f~e8-gGbQb7DD6hJYQK_wVB=DLJdU=7|7
z1d)&cNstKzVDb#M0Z#~mNXP{<?5+k|&_Ft5K^{bMy=H>=yQu&^QmV3p07!sLD1izv
z<~&<~6~tQ*HxxoCR6=xf;)ZO<17n`aU11{lffk}61=69~e}abJq(rCyW9lLCpI`;n
z)FV+42NmE<J(CKVkOKu!4&rp!6vV%R_*6)NLNHU4Z?J_-Fm6lSpoX&cs1<nyCvXKn
zFn)n$a073Mgjh%ilMd_;YOn<d@PG`+hCC>Q3b5~p{h$C!pd6~e(wcq20X#qhQIH53
zkPYIOA)ym#geowz;h5k8?%)j?NQN}Xf+8q`DzNO#F~Au-K?Bhc5803hMNk0~ZLuj7
zKnbY2vL6IN6gYIFEI<OJK%^bvL3}(|cV~YHfGjA3Dv0XA`2q3s5YUsnK`N9%D|^xg
zt$L9c@P<Ulg-S5#&AEUmNQF$u0aHiP0znW3$xr~s{WvF(?nF6+O0etCbpgdt4sinr
z3&t-J7Mur>A4q}X!Pv_M+kyv}4q+ZVpwt!H4<|ghLnT;^;M_t9SieM?AZHxgz+^o8
zPQcEP3|X&me2|wgg`UJUh4Tm=5DSSQejgG+{5%-@aK0cG5+TT+G66XdJ)Ls~WneXf
zvI_B#4EbOZKt4bnh<zXq5@xb56oAz%jthREfhdTD1W1N7$b=lohaxD23XqpWreFys
z!Q>T8LO4(02Ts%@axasQ%Du*B{W5zRCW8eG7BE=gf7AlT9DVwKdi;NIV7TueNB;+g
zFkm{+k3rU9jQ-|x=Q<Yvyr*|EujNf$sCt(1$|V|;Cpt3FH!L(fbh=h;{c<PuXpJ^7
zIB-7B1Jr{<gEfKjh4>~aD|0WeIlf*#T864mi_rRqGZxy)JitGQQS&v|N|ymEb02LG
z$B=zwj60+4wf<hgJ|PVI4)$j#wGt*=>&I&mEAt6~A%3BA!}+4RmHE)nh!BSL28L31
zOFRPy4gbq9T~(&$Rqgn#>?nO3yu6g5(|<6)uOF_jt8z2{(1PCq{a9?b+Pc%v&$Qw*
zfS+?!OYXny?i;CURr?H>?h~%{^7HpqMk$8|hG0^sIiZ1mYHPB``XHN5)_OMrYTwY1
zaIM<L_V1P>Lc#-Qg!ucZiO%-Pf|nPIz3n@3N1z+?&F$9HCdL0iW5z`DlcxHP{4?fT
zCF7v0^JT^Jg-p&+A0&U0ujoJI%Rl5_AzwDNbUq%+<bq-HhQ`3{i>f{O%CDKP-xoJW
zN52T4AblyE5fnPjC+NTX{5d)Xh6HK@xen+1drc1u4fgU03-g)xyTeZIKIOlm<cQx2
zx+y$m`qgiRGh0t6<wobXLdMr~OQ}+0OMC(NXnk}EmPllql*0-oyv}~rTg4xOwGsDY
zoEIsyH+1KLbAvAkmWht|0+q5U<+Iv1hIL&wFs%Y9pK;Kc!0wgGb?57&(ME*%d-+C$
zg;8I4aaC#kBdIqeZ;^z3%A{NqtvPNq8^tHx=vw;Syu!G4!~A3)@e|>W>e4klm<nl-
zPq@F5M`zY=<^FJVt)USizETGb3DJhlQ?_}t&4@IQuI1_z;zy0>f{9os$D4@i;u}KA
zn-&xp9^fA~RO(*c@x-pW?SsiiSZI*DFZStc?xV}A>I-uz%YDsb^~)#p%U|o4&#)}E
zo2IX`RP~6EX)K8CMnQw;xrhI`MxEvB;~RjV6OGo-D<Cvn>*&ZL9#6vOh4==9g@#D6
z)SpS+)j}QYk757Ovh%o=*g{u!qzu?%n=0TjOw~b`4#hTVmXnpRK~jnOi;oXZN4P)d
zQt~7m)#uCDguqM<p$;^FyOg=;n)&))ac%qggv{^{3ylc(n&Dsl>!w`aiv39TQ>I_9
zJ;`RxYfo%2Rd0hNy$vi0Bj@&6kaHVf(*}Pyw~~tLOXX>2^{;+QeodGBmef42lCGEa
z>9Ur@Fx5<#Dd|f8+jNEb%vDNZNT`2gAZPtQpO$JHW$V+@g}7wa8YC_Gf0-7p<lmHj
zxoyz~g!%jUc}aEmUr5(py^V6Dz%q3J`E6<o7b(AHbS8XqFY&*k{BnO7;jffcvE5Uq
zC;pA3Ow=r^;`7LXbwSECP3^+Gl#^;3h@V!O*sPqJX6Pks;QTLVgWp~kHEkgI9iTtw
z6B|ix`R(Eaa|^0!g7%`a*Hq_MxgquS2@0at(}ad;r~5<%>3_$vrIP#OG_X7C8mJu2
z)7d_{RxNxsnVaV`uk*R%=RYlC2DJ~>dgv^E82$Vu3i%x>B#gX2!#|FHq_01B@u4Br
z0c3me)3#67d4ZB+SP_rz7;}BXx!=_vM<dm>+_TGlKrvy&=lAGZ@>|AF^2@rPR*7HA
zlKB4~U2917;oWt2%i&Lc3v}rV(EWzW4}oG0UHYBbUwo6-*k2#J?)S0(1LZnW)#5i=
zelLgXmtSKaS@zH`k7j$#x=XnjiMta>eIfajcR}U4@J}8Zp4_kf#q-0T|30b|KTKjH
zXX4+b<U@CF?dKH|5k&h`wZE{|ln?HSGy#N@bPm;*C22dCiK<Lx3{uzjC9GYQuKti(
z{x6dDm)CQ5;;LzrO8v1q>yIUMmK@8w#<BFZqvB-luMYfoHmT0HyvO4?<w>1U?GLN`
z84k`A3X*4<1Qp-u$@;YXA<u08tNTF7tDJ{uROk1~KT-;Dxbjq~+ZOv|+jRZCo>z$6
zu*v;l{IA=1_SLPI_!3#aS2?difg!Aq2%g51vF;u(85LjWqif045;n)5ic#_{^`|8#
zv}V2s>Cd+-;bj_5ogw*lLHo)1eyBU&f5^8y9Qucah&MFJzm%V+Oi#+8hK+xg|HvoX
z{+R#hU$^}x|6;R0%fHy{Y55nM)%>lHdcuKqx@T7Xy^6j%V6|d@v6-%{=<gj^mh1a7
zom~_^=d$elNLL?7TvE2H?JDoJWoip@9Vx#>X51g>!at=bhfqz42R)r#C4Ens6uZiC
zM(EF<x`{4SUqp^$5AwcW^;ptn@~6k~3JJxjT|`(2LI3XBk>mB&AJ0y12AMp;5@^O(
zt`qlPj~6=2-)pXqHe8xd{<c1lGA*|Lvoa!f&~5u;8FBt~+i%K<E9?KPjJUJy_hm%R
zW3ZBb-obO;WO<E#IZnU4Nx!^?WwA$feOaKl$7te}dVK`+=laRlh4<ni<0<Fh*TVL9
zwy&<sb!9cgf9|i%NJ{-;&GB^GLW6k9(*35fPSRL?-<)W{3MO9dC~4%ikdj7cN(`5~
zlE!~lJ^NSbeOetX;r}WR6{OYRQ}1f8s#1ebJ%dj@gHOGqXAC~|9Ip<)G5+SRK@;~Z
zIhoqy%)Z`sGj>mUf5Prl@6wh@1E|`_<ox4hWzn}gHx1}>;Kb;)3DJ*|f3z|A?)#|2
zGfx~dS$&H3fafG!`r5Ufx>&YsH0F$VpG9l>_<pkc&^-SMAM~`ZSRCEZ^u?|QpLzzL
zdJjV%Y3R$qJ*C><Q}5ie{?4&K9DA<So<+7f7AxpG(o^h`>eOvxlPlXBZvQsN?~>}l
ztEPRLXWiTTO#S7(W5ZhRKf#0T^^p>8TJ+d4!@p=bbNuex^$+!KV^v_kZEN1)*IS$C
z+sx`8Exz*V4g1H!{k!<o>%sGj+NjiT%B9af?=xdn{|Pf9+wc3NY=+%y587lpYJc8c
zy8W>I8iP+ggHOE`=cF&TcYi4_Z)q=jyzZUwe(b2gh=*1m4R;ti#@WAOL5JxV#vZ>m
zB=Z`5zz0gW6<>U_WB;Scj#DT8^u8v{`P;qUtxTyGnYC)d(YWN3CWm=oUZ}*^aOf`o
zxNF6EXYY-Db9!3SMO_a0_N^CrEMa?^WncdQgHOE!cZ?3*Y?$<Y-*$slel7=3-xxMN
zxR=MEO4`YIs8kzmKWTC(rrxHtW&^Fxet6ODP4%c@XI|)h+~#znXWI6O=|7GB@l7S1
z!Ka?Vr=FC9A@#Nt=Tto3Jhf5N!AoCku_3<WtDnztY1z@>Q_sBDccllX#e1kS?w=YQ
zaQ)23E%V3i@AXp7T#u?9`IC5OK;xFdr=G#5p24S{efU_TQ?t&s&E4U6K5g5%qwS^-
z;pLhIjnZnP1G|RjO<wBQahdz5!{>dXYj3`||A*Xpw_2PZvm~ecd%G9W&f7=AEz5iM
zhQ@kr!*70$TJ`fAYnMzOT9KLMF!M$?o0;qL4mmGXsqWFBt2Wxx@NoOt=Ji)J)+|_a
zAXxRf`D?F!+b5~{-1r~c7xtN_`Got^mn59Qr{3A=@qx}8)`a}LrfBzJ6UIok6uWdU
zn*Dg&hKK=Cy*}u+^|P7lrY#!t)xzQDPkp6o=)QmJZo+*{L%-Tcm8;#ic#~DvlIx$f
zo_Td<;5R!o)4MD&z4hROlh>B5H!9&hj$-HQ`FG!$UT@{KwBBdmzBwY!?#t;1y0(q|
zA>;jNX`w|6^Jp`ElSXcQ8y9~Ue>B>&Q)Y+W`G*_XEHvA&=+w3jlNKM_`=NQ}iK{%9
zjZw<M$~n(^Rn&6+;_DIhPlf-`G4$5HnO*kP>-Wl@&=*XH_5ArA{6Z=5X+AXXpz7zL
zb;>-o!S3?Py+u_oUHG)UkwvfGyQg2?Z}6#Sx#)^f^4)29mpzUyxg2NTJ25@vi$&{`
zc{z29&Yx<d=dT`b^V9B<6WgQwy%wZ-Hw!#fx}epXkH*{%esN4$Q-e>vHjf`v7Vn8}
zx5doon$P{=RqmDZr<cZU;~7Q#xT%c}TTaaHpnC1n)>h@&U3&GrUKTv+i)WoI*DiP?
z?$MI&74f`(Qo>#F^t@o@tT}&Tf9~o=1$k>f@87uX!w0!mL$mt~cfT65oa?By#5dH<
zb;zLc#V!2aocrUMyK}$Va!@t)@cicvgq>*@vwlQ4ZzK0}?r2XunAFMh>f`T@T8?Y7
z`6J5=O~>@M6Eaqt4YIqH+xCHc7epMbsg3MB8h<op$Gk7M980W|V0Xc_@oOIs|0J>Y
zFzc16o1<Ht=N<Gm<vK6^`8}_}%?J4!eCl<-_|cA;uQB#hc|IDtZ+x%&x3v$0`*xod
zwsC0VPim(hH2vTuRr80r_1(K4epRKqgQ@KVeIHjb{qKG1-N%QXyo;<vr7!s-w0b{%
z-)oigQ}(M}TeqJPD)H7wWj}5?tNS*qyk*{0`o%M@31muFsiLJT$44lqSe1cNWa*Ek
zisqJ8#m{5(WHb|%_}m43ztUAQPoE&^PU-?O@k&)me+#r3%e*_6;d#<0C3-O02IXf!
z-mOQ+p=^7SPJRDVrC(|xMyQ$2etNq&p)`N12B2#6MRW){2pxqEMxWSA*Pl=64=VXK
zV!IW{l*4gJy6Onp0R2Lr4mm&izLLs2a!E(c{bC3w=Vuv8UR9j_C&$zGWqj&>Z|e7Z
zOTS;dem`g8(Dyr3d@RcGBwf-MK&B4lM~>GKl~=)?P&LZ;)D@qLUC`?M>iY>Q{Re-a
z?pcJB^Bja?dsT3a{q%k7lztAsx6?{}x+VQ`J|+Efyj0NlQB(S^NjYf3x+IVZjh6mw
z@1fn%WK_yk3M%Jm3rf?1YAZSqmGglumGiL{mGiL!J&Jye9z(OyJoGqv0{sR(jb1>{
zpf^$0Mc1vRQhkd`U%GRsq?f9zy1$mvk4w^P%sN|;$%SxYXKopl^GZ37wqkh<D*H>h
z(D$QK`d7*RHOs~G*i+(bjas5@^!AnOPv0j>%DQsB)J3bWKRJK0Ustp-+6|TR-5uo`
zQrV*&&|YYDKJ@*Xl>Sb?&&R8zSB@WrO8OU|Gtq^p?5_cR{~)E`knG=(b$%cd=S11x
z7qwxT_0a>->1ZN41KofUXY?U-7WxGmj6R3GLs0p)<7`y=BZZ;W_S5&DQTo;V-hPV-
zCw5qZwnCTc_mlIc>kmW!GG>3D-`Dl~t<dlH1}fJMb&GObvA?c=i>}{`>|fLVC4>`u
zT}P$7-axyex6#4qJ#+$kAC-JKgT8-=O8SjReEdDRUa^5vj+&wESdT4~`l&fOg5?&d
z#3Sj__u)|bcKkkFR)mxC_yQ{Rj9mX#DBr=1?uAM{z-_I{29@#u|E|6~vnfL*6uv+6
z=V{!h&i_iEp0*=u8T@*>@H+rmPy|)bY6x{7ctR8;K^7DN9kWzc;0n1=3{~Jh4F3uc
z4>?c)7F<9@!`TjME-Yv82D!+RAsdRp;MWsdzk*#L0}4R~z1hP=&_EL8K?Rt3a(=)A
zin;d8YV+F&T1b8wdqXPoWgue&y&;OQNstKzP!8e`!0A<fKR~`?9EYlmsXL?ChaV*k
zRPdveLwk+`>jS_(8s7kDI#e;A%8!EhOD+fFI+P0t00-{3lh6VXzn(RHdRo*a9*7}~
zD;fk<OGzW@5JNi9B&ha_Qtji@vL5@vf7Q?DpZWMSrZQK*#&0i7Wd8SlK4q|y`1cF|
z@$nf8R^&Sc&45z&lkp)1V7Z)lz@EA<3tSxPs3!KUql$(+QO7!}9H;`9e)v9x7^ga_
zG$;kj{&iFy5D6)e2dV*eRBCVs!(_04!2<sp7N8pbjsL$6tf=-?c8v!K8AtNE8TB4a
zX{GD$Eq#t#x91+7<%jSHswWx0Cl5Hapf(u6f7PGhf4Bd@b)@+neICllXHCC>@;!6$
z`&S3*g82Tchsu}&6IA?m)kkHF<o`uqfIis44|ZUO@8BX-Pif3Mv26gzGy@HUS^8!1
z0Vv}p8$mbd4n3h4IDjMcgZ}U$q*4|K$~-z4b%CMa3M0S`M!{&1sWJKtm_c)B0WF~w
zJP)m*4XB|lY$e`ysEiS7k6OVC&;dF^C+G}aKqhmv2`nN%OJEtq!W-}=tbzns3yJV9
z$k>o1^gT!hnQHF$Eb&=DQ+N)VfsEggNy?lf*PV>fxyiLDV<Tj&gN$jA@hVf{2J2-E
z$St%S><KI50ZW+|yGh<eWenR07zr|7Z7eKiy^Lj(<=cc8d&rmw83!SL4rTm<6LHBH
zhdXSS@mkl>pP&r#s260MVm_RL({L8P2B|ZO;Cl!mofl9kJH@DsQ7r)(r+F15KVS3E
zdX4$(a070^Z4e&-GA8>z{0!oIqk57$Neyj5d@>Y}rXQdL<XDmhiKivo@>zG22C<(&
z#_D$h8UJ6%`uEAd7isVXnPg0UHuGP=Lgt&G<>*f!Q&X0kLo1MJG3$>qFXQOPFz=xc
zC)<WHKN+ULeK<^*Nzew`K?mpzb|8}{dJ1F={-vkn;}q-8!$r6NV!JQN>sOFZ-mbxQ
zsP<)9?Z;AlQZ|AHP!}45DV!o~9{Zj~YqNZgI92E^mIn~`W3&SHF)!c5mGHG&Q_nO1
zui)468PeMXs;B#uvtOivL_akl@6Uov;%l#|eqNTFvfpzx_BH4HJqt3mV13IP+uAU%
z)-N|D{$@3f(UbXJ`sIzp|9*{QG$TGseVly=(^nsE2<obzABDQ>=RMH>Ej})lI)t>#
z^&)luaPlQOin1Zwq`b@TWwoD6Dce%+#W!XuwyMc?mUqAhkOty2M<$x#m3C$i)Ej~z
z5)vQ<(jgm6c=ntKnNS6$wXrK$fgL!(L`a5Wurp#ExI!xMib8pQvga8p3gkJ`l1Cdi
z@Pr^pfMiI6OsE3Wx}*<m!3o^J6HH8)2jyE1s1{<tnCCGU@BnW}g-pnWLeSE<ngw}K
z2*wz|4Ll(Lv=9#|ApSISp#aLE3M?D(8vp^24q1=~g&;mNH6RVgagYyY&yaqwg+h?B
z=mJuQc|$zpLIqfI?p(kF{6GsaP~L>NDVGi)Wp*MIHzRHuO4VQsevk^8kOKu!493j~
z2Y#T1e5eGE7OVsDlNkfC{Pq<=8HjIV`7M?EG5M{O-)(zvhB(NELNKMCasdzUhB9#A
zg_0|HfVv$DexQLkD1%BcZcn<v7F@v-0zeD#kOY~K1Nk66G)=51n~(tMpm~99Pz+@t
zJ~Oo-4fJu42;wi3*Sx9{D2FPr>`0!#8QfqZXdxa<tl0+6VA_e}K`e-m%yba{n61DX
z?7<m4Arj&s6*3?n#7|}=Bz5MvU~0>;!3yla4ZI-=5}~9U_OPRzgDV7p_`pntG!Q?S
zIUs(Ti$T?$^ne41U(6_ogLDudnYmB^B~T9HFVnOKX#gv*2N&>$AP`@gagYRQkO{d^
z0meN^Gl-APWQeiHUXTQ-kOBEn29;pki?o6G-gE#L5FeaD5DO_FemD!D7^=XsH~9w#
z@BnWR-<)xf&<9&MkT1xCA}EClFzZWRzykt6zTp%NagYQ#PzYrp-*Yl{q|OBK@fi=5
z;NFkpK@dcOe9tK#tel7!QXvy^A*et3g&fF-5~zTv0jz^ks08r=+6rvJ0bC#%(jW`+
zz+@2D2WTN0QXv!apb$!+98`lTbKnk9kO~=)0|ih8W-g=`>|r7VKqRDswD}f7IT#P&
z+5~5C2Q8#PA(#v$&0q`OpoJL7ghD6<(_vhDkPT%}1(w4(Cd5DjxQ`$|kOo;0{}SOL
zADrFTAEKcEj7M@lAOVV?4CJMxe2*y`j7O6va1nJUUl0lDPz+{c$Pai!0%SuzSdL>K
zh=f>3gJLinPk6}UMN$PAPvn||R49WgNSs7iFnfit;5LPG2kB5Y6+3&8M-ZQ?mfp;R
zH&pmyKR?2QCm8#4-GDO$Kp~h+XCKG~(;0+^)Y;@6%D_4tyF&~l&%s7e0$Gv7561H-
zPY?w1oivwMQIIy>(kPC#fNc;3?u*F_NZYO75^MwcV6v1t2DA_Z8Bhk&Hfy|$ynqHG
zUt?d$1e4_)7hJ&uydel8AqL_h2~r^gvLO!&p#;jI3QS@--=GFtX!SaFSb>5kL_(0c
z?z!YeRGuSho9TRfgs?1a0}WAmUYdo<^T%zr%X6AN%kunFAC>2-zWVLA*e1_&OIeov
zgHh#K8I^dZqw>7e1C?i;tAv;5!k+qYcUhL_zB{NKrxxoaK2ubVW0(vUFj&A~0fPk$
z7BE=AU;%>#3>Gk0z+eG`1^#bYz?kgLRGtob-gfj14fhP4Hq+B5*sr(!^e}(V;J}bs
zc>MDZ^2CjPxMu|aJ;TF%J$*D9nN?gf`v36@0OBcfHZIQtrw8H#S{F+95rBWkZva&L
z^sn|UUe5alnX;iZq(Y?~%jpeNY#QdTbqn?N3GyF>!^fexW_R(|Ib{`paFv98%Jjr1
zYcU(eC#(2QlgR3*W!X!EuQ|-D^CT?WIGm~%&-<fm>8vluVwFmK!wphBLn{DnDYfOl
z(l=REAH4&T&h*_+Pp2DRrw8+W1o27!kNU2ATKa0Hp;DiQ_c^wt;XQpC%J=+v8X|C-
zPO$%S8hY#PkZ2^a>5eUFcn9PgRoNd^r@=ieFxV$-o|}J&gp<5m%FG`p=kBZ%`>WA7
zGqJzMH$V)hPqg^Klig+m{^0{;Ue=kQT4i03auBgmb$N=Di<D`19i5NgchFxrPw{l@
zqX^VEEkp1L>K+#AJA_s@T{=r;=8w~p@|4duDNo`Tvz+<ab(J!s(Us7#d}||QhU_kW
zNu_Mk<V1MCxkGhsdzJN)h-a1cLGJR&4`!A1?&zI15<YB(?{J-i%j&ZEXXV0Ce@>#v
zqfDcSn^U3cjY^)=4?M}USoAj;mh<9DxTj1{@@vQT>io*L^8PBn^8WB?`SoV~)AH-g
zfgg~@|44qT%V72Q2$~XiW8yJG9}<`MK_$O(QgI+V7;nq&O6mVcuRmQG4ANBZ$r)A3
zrz^*J+BuN(tY(|8ECyEZrqmnN=O&*rB9mMUavgYra=jc<((2(KuGLp*)wPALEXpyT
zGCesr4s5Kh+uWJgr~OG?Df>z}Rilrv&FEU;!^1;+_v|ZIfWCs0>!v!LG4*5*-8VX#
zpfsT?@1Wd2{e3!ry+HqicKuD-q-;wbb+(%(cF<QGx;jDf^fa4Gnybr!ydRe78;~@g
zhB{O#`T8`6`GkZA@iCj~`uy+GE9cXhIE;vc-vW&X--nROQ|g>w(;5&sBjDF-wpj-W
z%P)L@?kMst4J-E1mkDKG>nF=Wp>y@|sh_O#4c0KPtLJs!P4Sb8m8q$*?%FX!>yf77
zY~@_&ePBQBzCl-ZNZ!*XrM{Is%JGJAu}U6?he#>c*<32Z2z{M4Izs!TJj*`OY#X89
zhi%GEvYw(<o!2Mf<=jg7eA@XFpRw_uDfv(p+v<GC?$IyHdsDGP1^XI&nHqeVhNZuK
z#Nf-+;LFtD%QQs$&+uisHc*A{fguClHJ-oBdf+<uJzJ+0f4TbM`ljxWGQVu&ll6Fh
zOVf8A8hn`=e3=@2nO?Z?aLnR<$0u8rT{8GG9VGR}OO5&+cDVMz%CF8lf4aN=-A5_M
zP9NR1`fEqGdkx+!deE4DRxRx%+_4rb{NEqAHr~$aWM+EzE;sHS>Sg9>w%DQSo+iw-
z*RZ>~zR+r;<?~bCYtwG=$g{qqBB$8BY<A|$v<6MIrQ>W%?k(TmBIg+WU5841dv`YR
zn{dJPanHCp%YAP5xDr;`YweZhwbBc0g7#UgA4eafh+z^gYOzDcfZEHgiXU3^yO`ws
z{p9iP?-y5wkDqQc_uPk;Gk8GgrKGR*_RT-qgx*Q~aGtS`>6d2KN4M_|>-+A6r0orw
zG-}zRjBp2(_}=KVI(J&r`@IK0G9Q^*uxQh%h_Y`^yL4@>>iou<m~Z;NNS_}ieHI1&
zsrPE%>Fee(?%tv%>&92TJh{V%Np|m?x%chhqYvD9t{O~#F||=lbd1G!cNWj_YVEcB
z)iY^xYZq89UAb|ywodCKTO-#mJE&5<qNHy}NDFn-&vITY4>tHRHTW{^Fv{!lx;9a}
zoj$cX)a-+sJ60TTTQYjef=4TP7VFVZ%GDQ*pIx}9a@msmUELpP<3~>jckj|}V`TeL
zsg4Ia#NI32NgpV#O|{XqR<&PFP3^w8*Xo?@Q!O34&c8JE!NFHo6u!1=LG0|Rkvwqk
zSFZCmtsPFz|KR2zgD=xL8(dHMZ)WTY*Sgwh_-^aOjLs*=UaEW$ars<}DK9>lzp?Kq
z_X|D86fYS$;tgzPLnDFO$nmIC_l>nawAgZZ)Qy!t?K0gNVen-tb}{%e&42lNn{8d*
z^8T(~`y)3B>04+icByy7;LG%QY<zmq*$-CM+2>-y_{QO4m$PB3nvT2d*X){hZ@q7~
z&AMgqWoqzcYVc(mm8eqrEBBLM&dl86+oH#S^xYe7zVzLxBloB5cIr~`Zo5@;r#~v3
z{Ng~y8;+3csMF9@6PwJB*tPt0<A8@wxup-9gbyjcx_$2IRG$})>>vA?N_DcggxlM0
zkK4i2L7Tz@m;V&E;kx^rOD)PReN6^!>UikjD&u;*zz7^A;SNulbluk`{mz2U$NB|?
zAGZ!aXz*n!cKKq|%AZ5)Ec!mnSbK1e=S{~S7W_D(bDOVDt(z3y_Rgsio+;Y#j#+I~
z*-qPGbDg^vdQ2^A7w(e0rl;Nbji1i<4*z)D4R!h_<96|0Sveo2E?<TP4GIsw?=s{g
z-!VnCF0RkJxnROI^;>iAwMhAF_bTG+Bk{et^ZtS6%kIXM+Ijd6A8cPWZpYc+#7pmm
z5AEnwmR8w<@eMs_j8_}Yo7JvE^t$+ZugC0b?$Kp&+?9dxr_CFhZ(Q@)w$EcbPr1an
zLnWN$(U*;%o3LtWR_~++Z;qQ}an3VhZoSECCN+EUi>x7&#(6XLKnZuJcvVcR0gt*F
ze3`D>GJDyk9lUd8{EOPC@cw(MBj0x0+$-StSAMbEZrA&GNmJXsQ|!{Fcc|6;dF#vg
z%TvM~sC4Xmy0GUUgD=w$H<Vpzw1jaU{l$L09~$rPv*V<*TV~hC``&-e{^Q#3gw}hv
zR@<G|#;m$qVfBFVC(lW^rgI)<G~V;Vg}e5zpX+wE>%cD$Slzzdwq(1f?V=H3&m|<$
zE<oFW+UT}ha8m4LZIzpknNyD=8jnw!>`B|U>ZZ-K(y0Tz`fj7s$$Lt;7uzhn`O9g|
z>gB_8-?dRE<bD2AY^U9Yhu7UZp<R0IwD^^^SJHPi=3?E&5Bpzn`e8)+hKLQ5NAEJa
z|MkpB?=G9uR@?6x$;+$n%;mWKemdr{bnvhh2m4*=IHkDMZSN00LsIO<B{)s|&-gNR
z=AD?nPmC&?`QQ7(dk-I^WJSj4%J4W<3d&F`)mAhW#gCNY3vVLx`aUb-XHSWTTP_vZ
zQ>KOZxRck9(R!bEi_svKm!j{XvFOL>N|d6kT7}+0SL>C>NR_@nic0#aNIGc(QMrIj
zV@QX@KNjV&RONw6{ERP-UW$66tI;W_9B(Qr@yk0)eIFC0-;2cCkad0_le3X7-hn9Q
zSGl0g(IM#b=rEL@L>aRjE$?(kprPnX=o-`weH$HxN}ra|s2n$vz6JWeBTAnVIj$}1
z@$IQh>Eyd3a~UYrv1&i6MGvCU=pmFLPpZ$*Eod%!5j}?9MDx%}^d#DtIM1N%(Qi;}
zuPQ`eL%&1cLC>Q{(PET&)emUD+Kh`rozY7uwpEp)e&}^{E?S13MSntXpg*HF^yOi^
zcXV&`A&L!EwXpXqs4*IX)<qYf4bW9+L-YfbG2+qnjq!_sHb(JX7A?NTo<%31&Cpq>
zCAti4j{b<YL`zXMT7|YnpTnl@P%YXCl|DN*sMtRM^!-?r{w-qv2CS2Q6f)5-OR;|>
zD)wK9iv1U((dZIX?7s|6Mq|-O=nB*v`>jN!zs#Gc94{U8{YX^OzeJ8F{Z~>zrh|lQ
zjAo;9yd&sT^b6D<J&H<s&O_&*CsBs(sq)b+XaSmraxS8GqF<w*qvz0TXb~#qq8O#A
zRCN)pLQ7CdcPVO0x~`+r@1+ctbjx*@t?N^w^fi%m*Szi?6V8$_btu=|Ua0D#a{bju
z$D$2TZWUCfsMxj<D)G94z7L4FvQz9)7j*)e+7qq`ihsIjHENAYz0(ODgW96w(JrXO
z7Yq9S8A`tmNvGH|3S`2MsS@8%v<1t<&~_*;9u<4Lp>8aXMCJM&jf$P=pQK#JW6*b5
zei_}0dZ2Pn$DvYhO+Zhh^jA{S6ORq`{VJ6H7LuNBY>#2ROdn7c%K85gZI5!!6ray~
zP;TiIU(OzA2Fp@bGto$NA1d|9AymrFVU#e6&t29jK6kUxW2`@lo<z^0XHc=z*Jy3h
z@GUCm`#V(Xhwo8K^dgFXQx$b^H2zCfl$~h&*($zOr94xHqC?Q1(4A-nN?oP;8KsU=
zJw}UA6?XU$HA1N?RCUmMXnnK}^+ZFIYgN?<U5|3jM1O_i?>Cw<t$GeMrallKtPRnY
z=y3FTRO$`!(Hn!R(Kk`*w&)*G(j0vW6<@0jsRufv($B>f&E*`}PT|~v7UDt1=H^2M
zSWM-&7(5^dVju}Jp#WqIudx?nPQeab!4tF)2Pu#R1yBaY-lPwlzymZ83wfk33C)0f
zC<7B8(gx1p0Ra#TX^;mMU@?vKLDDy*8*-rxEDO1grxPFB9GLfjILMz%9#o`v9{YhC
z1b~eHO@b^afGV(<&+)+xG!PGIkOyU8LS<9bhk2+1GY76om<Sq(g+xdN8E;<zWnj{m
zJb@?37<(zRd63V%jH|bF#6I8$agYHeVAhZI;0H3UJ{=0dm<qxcWPE)TBts6AfoXsC
zfdGhwbXgw2G9-XF>GgzYNP*n{$KLtC<#hi4|D+H?tW7N2%^D$uA~Zq>p;?BB{->st
z{t#j}LL<}2giN!1gf^jBvskvaH5!?0wzcVFA=Ze6Hkse^eeV0Fna%e3?(_J5KcC-y
z9*^h!I`=u(Ip@0G=Q`Ip=Q`K*zQEFz_(2GyKt5E0^&pl*7$ieBl!4`7mO~(<Kt5D}
z)ew#aVUPy-Pzut=-o}k};0^JR26<2lwO})p_23QhkOp~B3Pyjb*qWPAB4j}!ltV4>
z%&1J9h|M4!@}UgOCvkm(2gE=c<Us{U-+X8I-}a{}{qBFykE)}V{ANZP(aeQB_cCu*
zpYjIMKzyb~cE%?tTJa6*xN%A!{CL#hAGNM;R7Y;u(hk#h3HwDo(LB@_EkbL-#+>U4
zT%d&IDb4CD;s-S!%E4?YWf1DlL$<*O>b?F?t=o`a8)IXLg9rIO)sluxD1lnA?owZI
z0bkHU1{6X$SlZWD9Kjpn!8jQ$V6=eI0!9lMEnu{O(E>&b7%gD5fYAa*3m7f%pJsu2
zMELe?eXK3jx>{vudtJZXA0OBCA+JWSfngfP`r#mb=Nk0T_2Zk-miiEzyJH17Fy9k8
zLl=;#7upB<>i^f*u#jU)pE>c1E`8-p*k82+$Ajx2Q$3bR|3&GSXogCE$Z(E#gZ0v1
zJ&5^W2!t0cb^S(bSuXu&pJ&-HjyD`~t*Be4BHR;_`TrB^rB87PVJ^0yp0Xo8>X{D(
z>BlSor!y~oO>cwvFAd}WzuV8Xr1|(m)P;adU!q^@=g**L_46jA!4wRW1@q18{1;!~
z_xigwCk>6@f7|c%f3lxz@n<c4lk57cmigcFS?$gVqH0k6?iYui0=^x{cN`@UA|W26
zPB9I#paksdkq5yQJRuAC)~5QZmhYOL;6?phCgef^6hSG-_sANMdb^2`08)1+^>$St
zzN*csv$Fy5RV`y3c|jl~LoSp-CDed9^>lT|I11!{BBVklNS$6Wlz|y_b(Ww3sne4_
z&0!D^X^;g{w^s~R;6=S&1{6aX)KY)v!iVq>hyzCp;sxU8Ivrw~5*~8EmJe-S5D2+Y
z0W}cUoMS*G)Pne}&WB>K;<|7H@muZIlCY2n`5?ZlHC$f~5D6Jj3}sLWj;*M>gcQht
z94LSau(77z7ra4yRy$B9=?ZaB4t9@HM+zli!*%Kb-jGPyS_+k5*N*)|5~P9nqfUY}
zaOl9fghUWu(c%v}4C2Awj`)HM>S@u7b>Im}j^sC}05fNf5ALAp$G#v0(x4d1K>P-m
zK^1uL-68{up$u{cV@t5$yFwuteD{XAaZW+}^;UrOP>v10ApJ=Spae>Xv#mR6hcHNk
zEXaidD27s~fNCfo!FD52upLF3z=iWCWwxtchoe$1+oN(X=&IMIsPr!%f=W5w3zhr9
zK>hztsN6@op|YKEGFrfB0iy+s7BE`CXaS=I{(rH68430O+x`FPe9rmAMh4=lNOk=8
z-|Y8qmZI}<WK&O<Yk2fm+jH_7puEg8eU(iU#e^Znd~liQ6CHy|e8T-^;KnOF2qzf*
z0&$e6Upy@=!rw2<MHf<UL`>+X={%rczgd1^u|YmTagkx60iiMMTYNw1j(G2{#&tJ~
z41VPn5{I!SF(IMR)W_h*NH&tX0sPO!Mnw?^AKh{FkqDg;7!)Ua6u(7t^=YfUPug-d
zyyvz3m(ms<8x|AlKL<<ve)9fw`d%R(|7!XM>(iIQyR=NaYN%~Dd390pdh*U?NS~ja
zJY9y?JGAr()w#4&<7p=w|8`RSQ^|RdR}2}W55HP5fy^8HNj=<Emg!HmeurZBk@|S~
z$_2{g1rNbkI7qyb9}us5^U2>CKgmO`#N*HAA%l&jZL~~vZTuc-Q6AIhp}ID{n?qEq
zNM8S|X%Js=yy_|&yNQkO*&)lt&SUg;F0Ri4rn+{1pSbxxIBs=K{V(N(2gUQR+Pj)`
zl(nH=ly`KE=?`|9+k>j7-fZRA>6_fw7xyoFH>q{z+`Z!$ZR;^$;qEoXv{N4>;hb-;
zc;{gJ&zt7>+3y)%d%I8k#f)wff{T~T)5d1n#HN<g?p)npyOwR={=~V#wRtB7H&gzx
z#x9_H|7N$G!dErv+|hQ)*UPujUi>N9U&v<(E0s5U*>&F&l-PV>@YT0UeLtPs;p-q<
z&#gJ5-7Zo7+*Xgfu5Igv!}=cS{m`hKhO>@zUl{+)k>V*aE5;35HKBFScZ;Y4*iYR9
zzBLX7G=6V>!4Grdt`>ZqRc(De?<bFUhMk#xB+7GklM<>W6nE+@G^QzCn`pnEZ#~24
zYs~0tEb)5B(MDfmMqgupkFT+v&rA6-HK1?pCy%e565Zoy?alFzbltMTx>=*QU7bE`
zZuQMUPlv-sUt>mJV@6+NMqgttjZV&<c<m<7SKd6F{GGnWj6TFxJ@k70t>!7KKFM0W
zaQ~CjpIq2!$Y!1s`NpI%JvJz)Hh;*<@!i6@E;f7httM@>)khZ0D~$Yld8Z5ODz|^n
zGksqPcPXNm^^wmvWp8P6^9SFmhD~Q|+&#3}(1ZV+vwvIixwcL-Y5Oox!mYT~Ca%a~
z-wBt*@2<BwlNA_pw9Gep+@+O`rf=;td9*9<bg6vT(wGJn6^H)f=+t^!WrNhBUC%|B
zCSKWP-DK^?MKhDTq`G9U=bcY|E<Uie;qkHET<bmM=<&{wBVR7R8eWm{LjUGIS)rpf
zPtI&}h4(zZ!)Z*nHf?t8*oE+bk%KO6SQnFKH8ZFtDD3nPQ?B)Y-^1ub%;-aGpl#}y
zw6!*VjP<VO(+lGU9iHaD<d^r4@0?k4@x7E?r;B1&j4k=l?%UAGizZImCof2nuRgdo
zuIlP6<&E`iN^<vZYHzl0^2pk%mQH3>1L7VYR#ipiP($_lIF|XHfB60uA?w$js{MTO
zl$+Igmsgf;`l7sIq0xufutA>JLIXZ{ch`=!KlNW6-`-|$pL5@>&z!1U+>GtUsCK@1
z{z8j0lj>b+b3Gw*QjaIMx;G2!=Wyxf=B^_eb!xFYakip#Q11&yA7VxyVsc#$ZTQ}Z
zbhADdWv!+aZ9Y-E<mh+Z=NNs6X-oq?dLpyqm3r?zZL;CD>u<ZgQL^~c;2&(`>RsqR
zCGYvUr(4p-g9=5BY3jbtAKo1N@+&s2E3X~eb8b*hpP$S$URSoxIB=`!_cJSBqs^ci
zZqb3FxC1*M9?*Hvw$9GJnn!!>*jFB|nVE99YE6ggd7V~K|4W^d#&mPu=a*InAHA%N
zyYk4sg4beaZGC^6X~w+k6`Si%TlbteU|6c|uVO{VN32fg9M&F-jGcRX@Z>@BIxTs4
zQ`FT_Ye$`VagPs`aWclV#`OKOFHbu=V}AO%udaKKTDvsv^sqs%?)>t#X3GX{eSOu!
z$D<Tws~Ya{w=$Ln7PNjjWoG=#Tb49?CFXFyHjAJ7D#EFH`|V(do(pI{qt=Igd*+3X
zE#EnBziqjzyU~Z3(T7-8?~`jUjZAX*IQZRe?Gpc)^SXalMCpPeZu>8(&y!QizDho<
z_3o70p?C42rkxj9ZhGPPwhogP9@+Osi`=6ZI^f5qkL1&pvmWxPHgWyv^O22?NB^^9
z#N~IM@A^)|{?F}+c+z5cub+61ou=+D@{JZ9l>S~ZF1g1yIh<R$ue5g5>Gz&6wQ}mc
zJNVrG$JZ#z8b{fm(TCXKMdy+nd#7g4_~?a=={z4??k{#}d*Rc^f81SubbEY|&-^Uk
zR-wl$=G&~<`}CFYflpUH99qHmC)Li`<IJuv9Nl(a{I*UxZ3nF`E}z~0ihus@6YYOW
zdG8g^T><!Zrd^!IH15{qnHlLtX*MmUPQSWnU%$upZguZt{o3&L?}zu>)%_}MC139?
z;m%HvzMQpZ$KFZ)kFCqJS@iblnb#(~S&;O`uD-vNZH!L-P*G;9=dCJpT-HG^%jdRi
zcyxNB#r5I~Dht<M?PuL?t)J_yOD|>+W=m_?-`hno^;bBrc&SChy~)GA9sAv)9eZY1
zb@*j@`3$2Eu_-&|e7yBYYW)<4)9%fdzBS_Q)Oy41R%UL|w)uv3<lCejrfJzvulfvW
zJviXWZ{8ajKIVx|Fa5C5yusxWKZLC{`VhNuCFWLm-yYMWHV<p|cD?Ka7CT2Nt#1`J
z^6YVFo^HH4`L3$}zOIlRl}y?P%cophkZBW5VjH8cqVheSY68_4jclj?cKw&OlkbW8
zZ^G(#O!2KFpEd14CYl<nzLa>4(n?q!Pqgwa*$Tai$};`8TlHJxz1vd^tG;<?vZ|GD
zTAfh&=G&#t_WJLo_dR|a!qNO$p^342e6pE({KxBTum7fb-{bcroP1~Qh05`rP&q!g
z2CaM}{crYR<JhRaVumk>B-H57hPKw!R~h};P)75d?+U)4g>=Y=GN=J-?!VGDJrEKh
z1M;B~tUPFc4ih0BGN2GD!E!WZ33x&nBtaGwLK&Eip+5k)LkMUg6|$ia%Agi(xIi7j
z1HvE~a-ak%!Q7MmfIIv*`m?E^z`xh0O=4sE5b&;4@B(En1#}2FYOx>sd;V>l>DOcM
zabxgrQ+A2-(13S1*8P#68|fb-zHU5LQCMF7>ppL!kBs=d$$)$P-u#}=o4?}k#&=+S
zB_A}d^%ZxBhfFX|Mhh4%V6=eI0!9lME%5)J1?rLHy8ZwCOz`W<H*M*gnn@eY9Wa9V
zjj#y}(-`L6Eg4f8Cc${ZJqr`SFv)T^xCKwZRk#K+*`d-0Q~GUohn^tQZL}WyFoOpA
zeGOyTQ07PI|BsZg&<L!+i?}=s7nom#u7<VnBLAhI_B!U*gG`nDKMSw%|0pW`fseyU
zFicxmHw1?2x5+@a!Zrvc4w>i<m;-Ym9u~ktNPuOq9AwHu-+*0^4SPVQ^Bhn7CH$VB
z1Si(j^_4J*|1%*PWSWdh-{C1R75pF&cCg>C;7pzLWHIl;x&a{5G&B^Z>;Fr;bZLj~
z3DV}>;xS#D=?mQyMcQXK<G-}^KES-RJ#WhYd{o*;TQV<cSs@h+AbkxM!D2{&C9o8h
zf%J2J5uWFGVK4)h^FIkz!b`9UKBodA8I`^ht6>eKz*=|()<G()2bpBMIgfBIy5KW{
zI7hHwInO&a><6TOKq{<<jgSVf!6CML9o-6<@CIbV9>{^WAQ#?+_X&FtJ%%1aKY)+m
z6Oc)^5qmbq9!=ml6+T7${|x<i`-}KHd_~;rC&K6-LOreOPYn5SHptY3d?kI$Wm>_q
zB>nPabiICF$~`Hw<hqlxQ&fCLNLeM<>7Vr*;m9%KArVp`1FFG=GFp5_XdwxT0blis
z^gptPQ((<IG2;a&Uf>JKPzcpv%{#Cgi0_C%h=ByC;&srDcU@-?e-IO)jQ42ECe(p|
zJp@7~<U#=yK`B&#g$4TtUx)-Ph|h*Jka}6Sro<Q0AQLLUxf#pB6S6@nQ0>7565teQ
zu$u!&pZ^eu0WBnfl;33_?N$`ZDCvo%0S72;$vo#od^xy)J4}RAT$9$E4?A##L`a2d
zu%R4@gG5M$Ovq}*zOC6e#6bbrQ`zhS?l2KzAOVu06fCKTwF7TRfegq77b<2GAr&$p
zlCmNLav&dypcE>>in2xn4&Vx55C>9Tra=*uK^53)2nQ}u3KdWdN;}RAh+hde@C0uN
zfo#ZwLMR8NJ?RH$@P-gbfON=#d?<wqFnfadK`}(yay}ppvLO$OKzWj5gEizqA(TKF
zRDyX2;tk^0!UfzR5VVj6xljr<U`2(v9f&UnPw<8~NCbB~_6N0KO@+BVxI-W$Knmo7
zO=oNfsgMZ;T}X#L#|Kxa1^cd?PY3~*ZiI(;s05qttOqS*Lq51V5C=#F`yRv#!XO*U
zph}ecq*X7{3f_<ec~ArvT;#402JuipMSB(4I+IoqALmIRe$9(O{B@*5HdKIDe~t~A
z;O0VD$b%xN8OU>-E60S?L7Xe71&hHP2MoSE(uZ+wpa#r`vu_Yz9hD$HI?A95;-6t1
z<U_3&HXcv>AZ8-Rhg?X0j(x!?u$WBRz!R*epx_I6Q?Z8+>%bFi14uu_gL5F~3o@V-
zY=SrrOoT+phhjJtjD4n&X7C7MTS$UZun1*4umeYM1rL}Afe;DtkO(P|4q1@)Jo}iA
zLMhZh0_BQ41Fb;idFL1^&m~g+$g`4^Ke-zAh03#$aWY!KXaS=I{!=VqMntFn%l-f9
z%pMgJ8|fVv9^)P1|9o&%khfoWU~fn7&>5jIF+ow`|Mh+Ud+PfS*P7_gIJXeB|2VfO
zr6135$q$(-tfH^D&L9#>`Z9AXzu$DHzql)FFSn3>%fX>h(J^XYe)l`e!u(jIJffJk
zaAoI=i=|9p-K)A|sbMwz@5eo9tcmI>K#{)A&6K_^e$a=JcM(};h<{Z*Hei|$%^(g2
z5`T@=ujB7S!X*9@m-|e2;_u1IVQgPF{yZM&m)(s&k&yABRNr{rbjMQTZ%0@cb$ea>
zC9Uy<lXn|e)_Li}K0+UF4gUwKwu%ah#<2i@)wCJXJYOHyQlI8()*Jgr8~aBa`$rr5
zM|)U&)Y#ZR`tRu<ZNbe?V|pOt!t-nQUVMD-sFqviZ$5o+UC%E(?e;Gm)@s$kpRd1U
zeZ$y4+SotZ*gx9XKib$oIw<pcy{mmayvARDq2;<~YsXFQ@J5=$`V-f`9CG-kXG6Y0
z4v_LRL7QOp)zyWwd>->zHt$5%?0O~Ei&t*m5>x-N5C0LjamfKidCpP7?U>O<^YHrx
z1FOPse`V|+EuPVQpAx&QiaF!;qHoIUiDN=zZ`tl0;XLeV*P!b89fD6k^XbK*xfk(y
zKS;tY|LBVy`+u3-Z|cM!UyqD({c_(|D>E9#<-I)Na8mj)^FzESFHrZ_WZ15tq>E)m
zC$B&AQgGJ8FLXT^(6?dSk(BLO)_sFQymI)yO5Ll*bpFh@%bxz^!)`}kIdp#2`StJC
znx5aIIr3sf;=K6RnqA3Ye?O|{cZy%}zUVPki|rj6xGNRKj}C14*(Te<-3J=(t^Dro
z&TAa_=1W@WuYU5K=$pF-RUI!Kn0NKU(eT0>3+##>X_xk8qniB_Yj=LmH-~`|&aA%E
z?hU@i{?W$%(HS#q7u5Xn{?XFaPZV8xF6YK`zdST7bnmW_H>aLm6i%M^a+Um&cH_c7
zKY7bL-s!Prx1US>&VS$Sub;N*)o5p0^>qL2uZ|8TU-4~0W4h4%mw}De`<jgHeSFVX
zgP&Wx=)$SK-#X6zzQL7+b{iTjDdhT4_qYDm!k>)&qn9M6bziu?#`I_!-%6aseiK(u
zYI<;ccyg=hpXW_W@mTxQf|sWKqt$n>et9#l=$2DC-$LJ1uk*7t^{(1wl<)d#k9o@I
z3ofJjoi+B47W*0dM?W*Zt^4JM&$e=Imz2EgOUB(+uS;Y9Xk-6qxjuZJjjS<`bh;dy
zKc~?m*YCUMpS92T_4|C$?b+MA_wH%zA8qU(eZ5V_`@3JJnFs9)G^Q`TdE?#IORgnU
zICuq&7~)tve#go1)U&Tf59{bsnN`z<@Ap0VNTD&EGrfHW?YiWKFDAUx+N<lrr1OK4
zKWovX#pX5dZ~Gvz%apT<@{AhJ`tUfjM<%?yIInkF<Cn%yvijOPc6P(bYbLcC_)*@_
zN#lL_=B|djTJ~~+&46FJTfcDLH2s=?(K#<;|7fxEsT;2<AAZ?=i&My_p9CguyVCHj
zMGxEWo8pia+`*)ETf1|N12sy*y<5|-?`Nla4SxLg&6=`3+V)#5{Vw|57*Xq4GdH**
zX&dh-b{-P$koCmk4$9KA|FEgb@9Na+`^xY!A3fw^{mT3mNxv-WQJst*UNzi#Z|~E#
zu94py-Cwx6X-Uy5A3W8p-L0F2w!`xKjPSgWu#C1De23AP4)bsyI{4YLHi0kA{_e!J
z*`I7ZpgePE?j!F;ooJu1ab$D^{<r!{IP(K(oxCsH{_3#x_?BDtTIWP|%x*U!XSL;E
zhs%ZSZf@b8rKs;)4qnan8v94b`F7oswc2sdXg*4P#WyUCY5yOOcr6|>eEEU?=Q~a*
ztMJ(OPrsoV4&zf?CiXb9cgOQfX@~N#dOqHH*6G3hqdhUV{u`ts-zKHMF;xqS8_3k0
zrY!Qkk4H}})d*^TWnLr2*R+<?q;M!L&2sqGsA%PzW-Ih68Up%ngX%X!*>7W(d4o*t
z2`Bq~0+szfiOPOEpt4`S?`fx@ozNL*XEX-wg3dx|ex;2=yP?VK`@gy0v9Yf)-+C#x
zjD3x{rbhC88+<_v>5va)VC-v5`NDIF7IHw^7%H?abcBfz329IS)nG|s<N{t$X2O5k
z4!A)Kq>tmh95R`&1Y1*V4)KIdgIp+qDzKcwe&*435bo_~T(^(0qn7rO)a%uvS=Q`(
zA=~rcjPgsy;k&nQvGgncqdvuk{=^9s*tSd9H|mMXSbM%`5t_$wYEc_=%1Cg564psy
z;(td!;^N-*l?pIUMhh4%V6=eI0!9lMEnu{O(E>&b7%lLhX8~SM{s-;<!~LUUqC#g(
z`)vn+aQ}dqIg$T&$Np=n*tXCOvu8+y)L+@Qn84_F5woLd18>`6SVZg$hNlaSpn|Fa
z{|5~o@rPmBC>AZG4$FbcD^n%-nK{uhLE+B?$s)G*Xz_*>{lS&y)bjD}#yh7>RC`F*
zQq?cuC@Q-&R~sq3s_MrI3<~j?7V8%k7!>Fe;1?F=GAkl9kdXi*B7>s*Vj`mKI=Q%n
z`Gxxj`uPL}`#JOs^6%Z(Ke)GJpTM5MeS(7>0t0&o_vqo!E4WY30rrNF{((+@y&ar;
z_Uhx<)48`p5C1+vj!wb;fdPGb`uFe)avq@Ra3^e^o`iD>3~&ezU}dm#&%hqReop?q
zg8KAu=o#o7JU~MemOmKt%vbFX&`hb{VvH_bwjN`g)%N`kY}cKBbcS*JWQ;s#mJP-R
zV@;xi=v6|Uqi&ozH+7j`fbL94U1W<E?t~q#E)NI`@|!_uU7P=J_4aj_jLp;rc+Hmj
zOm(s}YbN&f{m(IQ$A0~Md+-w+I>XjMwY5f{mS2nIBI$l8wthmFMr_?%{one|f2UvB
zevE!h$hx*4b06D}F}c6($C&)u_Q87FXXvX3s5X&$V`U<Eajqf_d0QRlk1-FY`}ob!
z=j=b9I|ryXkbVAkvQ)>tl>Fh#%7<(uFR8}~4dlNp4?#We$xmYx^A^(2*T?6#5$o5_
z$0w|3zkY`JJ@7hX|FXY?Ke@jLUSaG{`mwCm_cJPy%*+%F&A<<mI98Rxwtsev(byT$
zq0?pr1!@99{G!zHMWu^Us9#v<+#sLesEBYMzo;m`IWE5rH@U}@$vvHVPm#-BJr8ot
z{&u=M{-`S}&ru#4u5%gpQm)-Z;yl(w2LIF@NA@A>?9k`<=rGnqKPIUf3psbDEi%bh
z#iZYjFin3{%SmjY>;J=d2DS;k)9=S%FEeviFx9o!D;zsgx4pg?_!DEY{@M;Q9_ydC
zSD*j6y<Ywo>~%`=3h5Vnt$cvJ=IXEAV!gfi<fnemX^YO1{H5F8a2Y%>+uprm9vD>3
zM;zupljcr;GKtnq)dsq8Y~@<!o0T#|y@$ByFY*EE`8T8`zmaa2a<Ab#mqK@aWh?v8
zRI7Q%kd_DD5bvhtfkFRtS~k>4i<G~TmJ{tH54$ix>;S%#wP<0@vRBn`E{1`6?+#)r
zmkw8<lnsXTCN*XQrn=|Om+gIjo!$o)VRzH}z@UFRy_4&t_m9rqRDC|QZK6wy+`r{C
zQY0vm>?8TtX?bAgs{61cd;I-zWbfuR$uALg;wv^b#4Ar9uTDHfNW5&(9KvS*I$jUV
zDEEt(yF~Ce)7^M^vTo1s#LLS<w_#m-O(Lwr^<U-n2cFRT#mnwDagqgh<0bZ*cu%}~
z>(67MK3*w=k!yGr<Pz3X7q20nF%cdSJlh71@e2=Potz)Z_xG99vOw~VhL!SA&G^+3
zfkBZBq^-LS7U=Jh+NQd#<y6U|h+Gy8Ii}@}y3f}CQkfs<H)C2*R77mF&$J-JSl;?O
zlrHYNBj5Xb_kJigsCz$@ytPOlZ<l7e?drz+kOoWt)p+Y)Y<@e&_U}hu?5;cdy}!SX
z`zyr9a4(m*_tc+fwSZ;Q5|A_=gP$pg9CUHVTDsSvA!K4XRtW3wGu=7Ik*vJ;9Lu?P
zVEOyRlyS5v^K}De8^+S!(_WU#=-m2&x(O?No~P^Lpp@C`{-@UYFKIB0-(Dj(38vv7
zr(!T1)F_H;&0ownzia=yj|}Yk5Ayn5n{#;8f0@DNVgoytiSM$pCNqL&`>4ahtItPf
z#J?IGSwBV>XZ3lXzpCG|x_!YV-QD!(PW&m!^b1It_7fCvy`<~*!OPe)gNNYr<<DN5
z;(JZTIj0UFlwGOMXrj9Fse48<<eLojZJ569e0!Dq))%N8yX+^`=IXJ>M|woeW}O^A
zm2aK*nFjS>VPmCV3oYx%nwY51`svKy8yB&kmNHxX1IoL>>}P`lc#~Gc%R7aJXC~tA
z@97sBCC8EQzNjs6qP&S5p&#>I-4E~Zy8XmP>UX2s+mrCIfV~4GpQ~X}UD#-ULs)e=
z=`B?EZHS33k3R9UnttU|*2%dtl&ALk7uney+m?NXqs4?N{>5M~tR9KG0lY8F@C(z~
zj4;2Qbni;-NnbYW4gKe5#s*Pq!Asell2zL5v}ln_m@S+u(iH6z91-Os?-_Tpv#ydv
zo@4R}C;kKt<J`-(g)GyJ!G8b87>S#VfiC%47Y|Omnhg9)#KcC+da;!TEm8A*xWA7)
z|L|Y7<FYnvr&hVtjr>U7#m-?L!yXNWx%a*9fj4Z9A?IO?{+cnjVu36pFEvAN!S@`e
z%A~QvqS#2{7vvKY5*6eZ==1BRw!0^XZ6r_M{~gLzeV1*?`~1Or>OOg&?;)4An#Wwx
zd+qGbvIp7OV8?r}3rX8^`m~wJ!xqz{Ag>Vmq$&>jx|2VZxL;RWsOi+Ouis9(dJ9RX
z+nsuf9#WM-I_tOSdv}>!;=fA!7|IxVua`V#NIP{Bu~AV$Gh*&Bx@=oF?Xs<*e3G<3
zufGRp>eEgZR?9-#yD7E2zq*>L=iq<xzNjmx*`J(q$?LzJ?w0!wti1O*VTL}Ao>Hm8
zR5y-$G&~>w)j0m{eM%SAKO4_`p9u!*<LM~IV>$$8kO%UVk#2~mTHSJ|5DB__%KqrO
zP}FAxscRJ*^;PRy@9snLgVYsxVIv2Qzm5NUb;ncBzu5iGb>kDl)u{_#LU?<^OP$qq
zefZz2ThNsQ;%SgH>C;HlS2e%L1u8yB)6MkxMNMOLNJMN{pilIi838`CLu07b4U6#i
z3zJ6`9(`p$V(a@q_uhTZ))4Ma+?khnjMUrOUcYfKmW!>4f^tL3qhH12kFMMY+gy&<
zTYtPn{qaQPcye3%iQ_rc*QYzu$A|07FFGjPFOqe?pO<v!Q}%7}MN{@W`}X|xzUBME
zpW1IXeVjvD6A`8bAaR}pCgjIR{eF2!mAj6*&xx$N&vfVcRPxdNo<k*1-tRe7(r1WA
zi9Q}r5!M`>L7tT@8|ZAOzgMa8kahQ&?!?2DmAZT8-8**O^JFW9I8!AFmh$2&^fu?o
z_t(ernGr!=oUS`hA?g;t`ML9qCAKj<W68OVQUBjPzLc|ZEW7s}Bg<V`e($rCJU56v
z4bM!nPg!PrcUjal{W7tyMtw$$nid%orH0eo4X1zJGHr26Y)sl$ax;Fpk!n{ptk_ex
zeVD&&FSe3*g!j#LVZ;}t{9ml!#_;@Qcvcqw&NB67zt*TDYSx{42@7@m@SyO3$T>dI
z>bY}QL*DzNyPoBp#gkRL)MqLmH=epeXXw8*$uo`ESbQ$?K2vAiGgQv%?qj~Juhp%8
zCL%T}KnfArr<^<ecDm)dP1G{c4trP={~?5VTNhuoOqAy*-8u9b8W$NQZxpIsq#TuP
z#22_LVV-EJvyq%fIS+rdjh1cP2oq3e8z~#_w~d^GM<~x%kuQ@ux2B2|9dda`lO~H6
zOIcpbv%GG(u1JYyU$U+-wm0LYg>^nr)6|WE!~CYv{@kKPGuBz&UB?rxk5m@${1qI*
z=A0vo7M6t3&M_gq98+H&`^=y&f&)|&CX@6BVK9y94|bW`gQ}<AY~|SLo7~qI_b+=l
zsdeVuz2g^c>oH*A?lr}<c^@R<oNupq=V1KLo96i0?-^cuyHEVZjBXQxi<ivP#%9{Y
zrk3I#Tisu~mTlku#JRz>c_#)pQ~t5WE}(n=X1AQeS2gL}(RRt#%eiqKrhw3xhJ2Q=
zQhBqNUH3gfiOm-VUwy08_tUu@z7DeW+?q4m?Gkz5wtC!kZCf`S*7r#7heqWzoOPu8
z!uV&76i<m+F>ctZ39Wm+TQq|H83Sa0%MJxJes6xk4|C$K7JQvmZGAoOCy#fAotb?k
z%5!#;lEI|e-9^HsbZw&je!lgL|9gI-g2qbxHmuz?_=~<N!7Z+v^mJ}~xaRDS@gEMb
z?lt9|-Ekv69U8k=Q96<VHKy&`Zi+gPWi=*jL#IzOo2=Ti^~UG<hn63_^4yv!AGhmd
zQOSLDw1jh6_Vr8Om!5gF#Xs^Ixt%<Hw%MmE4x9HMI626x<6|#0`IzTISIQKPX?dLA
ztj?pJ-V&0weEpo|Z5D*|8XsNevSfkR(|^^UR1Y;B&f{W^<)n1{=+M)HKU_V+WMJQ$
zo2H$p3UK*ig5QK?1(mCKuT|4AZqw131+RQD&vMj~Wnn?5K0nuX?hjpG9Tj-U#Omc+
z&qi3{YhB&nmm|vp`+w6z)292aR*nlF8NBZH^h<4DdaUBWe8<6oW+BJ8|Mih{#19PG
zoVxc)%<>+iJ|EOz;!`GpYkHLp+8F#qm$89+YbIMzc9I!1rkQ2e6`QzG{l5Gq$HVW-
z=@UPU4lamZY@fO3;*_$9vvVTptI=D++2j<@ZTC`v%N(bi9=rX9)i!^sQ%V2htFLsL
zRKKl%!O97o58|jXU46y+mNxL~+mlBgXg)OJqoj3F?**)TdcdN9N%<#U*=kpdkL{rn
zZf(~ij~V?_8U0gb)qF7i@9|GHL%n`m*Y~r1sAi3G(xV3}ho4^XmgRcq(Tcfu<G@9x
z8CfN6{fz#pjQ**N{;7=qss4TbsZ4m5;5lq=#;cFFUpV??z?irx4&y9Oe4N#|WlY6*
z`||6{wznxbq9~6KlW_aqY#BJ=wEOK|Nwb#uUFmr~s>bP+^Q}#?OFD<WW3_R-2k%Y8
zC0zVM=bQocmf4owvg&^(&Gp;K&w9RIRulbfaOc@yzhOPCC1bhr0Io58Z2Ok)I!9bh
zePfQ9pT)<Pc89m`j_SK%LfZDmEt@{trjl^)s{32fXLX_f!#8>l`K86^%#s&gJ04s4
z#b<8a9#gukSd;KY-+}bkQ{!h<V)SEW-DK^?MKhDTq`G9U=e<OIZa=WK;qkHET<bmM
z=<&{wBVR7R8eWm{LjUGIS)rpfPtI&}g*p@NH5${cO`Baib|E}q<e*C%*2Sb*%?zpu
z3OoJ7lxzLp_gMb5(T|nSxpj}n?{<05_F$`>mv$`wv|ahwDf53>*&hD{{l$JCHG62m
z3pGm?-RS1|OHA_E3DKTi+i#A0VoYYgcRM6ruXvMpb=A)PHuc73X7*U<w7OvXRO^1-
z=ANB;^T532r<U%TpE$F2v?uRJ>htd7k2xQkyYtfEcdwcrywoJ^+rI6GD1mMVKKo(#
zv*Au&gKHSSh`g^c-G0pcU_!&!Ua=fxd-9Dl4lilO3_tN?mrpx?*0g!MJ_%3x^G!>=
z&cFP=IH1b*spIV{dnG^Ocl^y(&rEvbU6ajC7y7(Y@7(oP<@j1w({X#_rI*gWy<_3U
z8yg<m*=)@Lhgl{S^ZRSJ8U0up{a88K_YIo8zUY$Il}9cx&RJi{f9>}*$j)fwzqVtS
z!{=(9T*f}U+2ZskO?=vHnAxTKZO^yJqhC5nxH9Ga^OriUX?^+ekf9&>9sOzSLaVPT
zPNpBU@4Pw8@4}E``l`B0xTHf?mFp*ezkJHr=3|08^<4V;lHkai%|<^~v4NMaPq}S=
z`5_;NXROX|NI#Oee9m@dzE|uMgFl%+HJ!Sbhp1H4n2srbWY1?~h93Lyg!kFK?!ESn
za=f*n@7nm_FUB{zej@j$D8^t>>s5??tc-rFB)>fVR>so6g4Qpm%#43|%aUfV#2hyI
zu@bu&{a8f?cU@$0`R2}J7nf`_<@q3Nl-T9_;%n=J8?L-)^kel`{aBqGBlepa*y@$9
z-mx4wEoc7mj$dy4rcdwYe*Qlv1sq$mY{34VFYvr(^mmnMv*_*9Gp|i}vmoh>U44Hk
z+ZdhvA!8q^?~PTN<FXEVSw6RA!=uw1Ev^?|P+7S4YCr3CYyDhrU3xKtFk966wYQ66
z>aTEK@luP1dy|KKJNCOpJNC@3>hR0*@)_&4&Rp`^4!(7&`Pu02>a7uPr`8*8w=#2!
zw#_$fX{(?<N0j~as?U(tg9D!Y=Dm^OW1i^r(hnQW8(bdoL)h9kHdUT)x=2y3sPC7(
zZ<+1yv*VbnM{c*<@4UX$@vVC6BN}cnY4_&Er(eESZF`e;$+T(Em_9t~R!*}$PoBQ!
z_~O^yPj(yh@w>KH&b2Gw?rs0V$f!qB(x^Y64nbpj#Unf|@mx%;ho7ZO&krNL-fp=k
zYun40I{Q~l9puw@8{em2Rl^N@e8HukKZ{(wY((LP&YF~>4}MJSwENVdb=Qx^EWY@e
z_#Sgq<98w9OoN5Do;vUH&ym@iVmD15yUX;(=g<GU{ax`WYv@C#_N|-9_q+NmBYUdT
zSA6cXX6|eB3G`c(&x^_#6!R+-x2k_D`5vwBE5>(5+BdVGdZ-P^beeE{T2!~YiaLP4
zf0NpVq(=Q-scWOhD&<pCMa$_>j-nIM&rsP;z7gyD?x=lK+-bYaCs2h)MRm&NIL(;j
zbC#AYqU4~MSJ{X9pl_poXfA5lpT2L)-?Bdq`_}jU;Cm@Ph)9<SY6UVK*QZ0nyuM$B
zYKuaQUN_uH6J7iyoW4K8efM{)&i?dm{Z;$_-f_j2`nLCqw8@v_nzM{-s7{}7TscpN
z(Q)VzbQAh1dJ<*qRP8171lpYKOHgUkUpKz`HuU$6hatWa4}F_<C58EW<591kqLp}=
zqP&(V^-+pJr6KBvHbQ5kP0*ESGn7w%N^{hZzx3_bl_o5gd}4~)f=mURf63<`qSD^|
zBYl35e5r3g{+G5(XFGk{ZM99eq=!$<YT6K`Gx3u2bU|ggJ*q*wqMgwmXb-d(+8=d9
z$D>Xtp8}QM=v34h4MF>&6m3dBGy(08u0Wqc*P;W^chEs7pD>ldsMy6-(6@D_+ETTP
z*uikUZ^I69{bZuDjN6aa72SyrMzc`aj~4Xpoz-^Gl3q-#wpT!u2ILFLM~zV_H=3Zm
z&}JyF+DZ#l&gVnuWb|P)3Vj5X^jM>>qOH*b=%eTts15oP+7?yMGkH(n_E~KcE%A`!
zNuHGHS<)@np)dM08iGckq3A+13|)=VE?9dAjX-6;k*Ks)#rKug6`g~oq6^R}Gy!c{
zkFmPZC(#$tr_tpo+bS#2C^QLOg04b$qseG7`ZD?%x&}Rmrl8-WYtbrn1KN@dn}%x8
z&8P>Ojs~Nzp&{rNbQZc5-GcrD%|o}L2hr^)Wv8+OmA2wpsHCq7^lhLOX&WteqsW%>
zT%A^7Ut8vqQL0arm(dYu3hIZxf=WKzfWC}wM7N-uP&r?(qd%h=D0x81MCF`pN4uaq
z(cWkl`ZT%+or30|{^;8%`&Ra&d(ngF2k3j~IrM$>XS4v7^H7L#O(<WWL(wnM31}%Q
zZN9%jCEe+uZ*#1+MZWhsbt0VPf8wTXg*u~hJ@!MXzE_??<$4@|2BSk!$v>me*U)h&
zWr^|(dK8_Ao<g5PxtA)WQTsjWi~fj`R&5O$gx*4fQHiG==-Usg=SAX4GVa_@#}iJj
zFWJ9@mvT$r=2i`JZ+S-<sfK?Em2^>7-q}vy4)!l?7so#I?NXIP%uD<%&@hl`0rw>{
zbUFGEx)SYxGOo5RKcRBZNkN}Q*P^q~b?9z173ChTY(V#;o6tP;Rn(APeVb85^5?zJ
z4?`O2?So1=HVHLsr*Gq_NO>gj=CV*EugesQJtf}HqutQyb?mEetEskQyLY=w*i*K<
zj7oaBzU~}P-wyM>+g;FacTv9`c|+aKlYQvhS*q<X<#;?wC~hDVWq?+WHw~3?m$E=B
z&sw3V<b~%^$){ncly~8%A^rMxlj`%{z3JFR`Cv}?Y}6U0%+ke&%%^VyskV)j?d1O9
zCYh2chj4QIchOGhK~&<AkM=_kp@Yy5Q7QL7M&<tY5gLFVMqfZbMdf+pDEbC^94$gi
z&@1TY=xy{Q+KcP|OLR8+6}k)k8l?=8F%q@!px>e&qGjlD^q=TO^bA^`xR;|n(X*%{
zT7h!!R4$-Wj!-6RN1~Te?iI>abQXFY<sP8app@y#PiQ)7f}OE}Vv2r(nxRKfbMy<e
z3Ccc{rf5AfUNe+1iY3at!f=z?hf#)L)V4t%L3^N&qGQpv=oIuZ)Cc9>pq-AkL+7FR
zWz;T3JEHHPozOD0GipwT>4G*!yP<Zd13Cuf7+O!%5e-HAps}bkIvaIC7o!8wSJ6S}
zo9JLP8+AkXqr=dH=qU7KbToP#9fO`k$Dz`u_8C<2qm(21wxDVoQD^I4mm^)d9#|yp
zv$YzOJf-c3a_wrLN4d7Oi_qTa8k9V%J%LgtXj^ffc`wjDh7Le`qC9(O9Z^?Q+u*;?
zPi}E1{7pjT7d%6qB7bv}vZHYF0<+Hbm83@Xl^lQU#5xE5d!b2CJey}4?3O^dObO3A
zn>pAQJRk((Ar11N1Zu%*E;a-Yh=gRwf+DB{^Lbp0eVB(@kj^`HAmg-0LL#I>CdioW
zB~S_GeK|+q4Ka{G+@u^RX1)fj`*Cg|5RxDV%0b3nae+WcglsqkW@H3=@Pc?qhXSYs
zi>KHIjQ(^fPex*Q@C7ZTLq3#&(Vy=BzCYax%JO@C>Lxa(?ezlkGdECY%GMBY)N);+
z8D~uI_}IPIziu(tx%0!n^|M<hWd&tp0_*<B->x|iB;s?|3p{wBl!u=`^1XXMzq{T%
zY>4mO49JIaFk4D`Pz~w;ao-Y#huuub1?iw}32|U6X>3+s$zVPQDhQv${{rSqz<L?`
zfDHTkif`BYie0z*N*pNNQ78ph2et>h9`%(JI0ZI6>vO}P90l`U^_4(~hg8UgN^o!_
z44eWpr}~OBgh3KyLOz^=8nDC%unTxWBqTvL7$>6zj28IMu>g<m%58Z8k;#(2L9zgq
zzI-t@^qYnY{9lEx2I<58BL9<M9rNqKFiC$e>2o-fWtlB>ecEO*Fa6VQv0VC{#qr;^
zCC~TFw+HD9W|*=GC;hMbu&gf}2I+rg!hU1f?jU*=USs|!S`5eGBp9YGtQ!JDL8c6J
zD^xwscM~v7+gKLL@iNgJFbC#BJS>2PAbq`-!E%r(3w;B2K{o6Gna*?kAK<b+9?~yx
zXM4g!&7+k6ZP||bH(?hXVms+mwS(i2KsUlBkZBC+&i2p3Bp6SaXJG;uCRy$Vx8Mo5
z3fDj;JG2wnLwD#2GTlb&u@5t7px@UpmJMZog#Q0X{x<?E@FE`1!bEU@p3oV(fK0tm
zC+Gux^~)xqa_%M1$TS)ChAA)={2&l^u>Y^%3>c;?=3Q7f0A!kmhQf6H|0dW_@<%rI
z+YQpkQYL918AcfC7kh)3t8$Qj(-m+5et^qx1=h0tk7zYKPk7mG23+U=PjC~YulFsG
zK6IZ`@o}4Zd0DFmeTjn^D*nmDpG+fY3{62M*;e8#*TGH=?+)+^q{4dG2x;&di2sh)
z(XEgPZ$LKefgE@Xa^YQgpRfnfW9T9D1NaC&0hweQv6J-uzX0NgAcX(oui+T;;vXV_
z|9jXz2lhcO?1y*Z033vTka)@QK7a!F5I%yBp%6X+N#9}g2o%Ama1<nd#c&)xgA*YB
z8Vu7A;;{?FhmrV95+7LNi?0Mu!WSSuu*B!pYaqV5z5+KWh0{<5-+}makV*Q@N<I_c
zE+4S00DSl_K87Uk`ht{M;$vg$Bh(|qKS1)O^eYrUbjv|}=()2@`XGw0wKebx$aVT0
z9JeB^=x6BMF1kM65&R#?zQ%*}$&Z2vc$(!cLHrNO<ctj@olk@KL41nk1JGwd{3eN?
zCh?CYzAvZ1RPX`uZRQ5P%=>{q1VJ!_!1Ew}3uPLLhC>8Ig7``k|Cmt_4KXka;vgR8
z!$MdDiy;AIvLtU?V$&8dkF<z3XPI2vvHXt%DWk?gH{#|*UNA=ullb(MbjUfA<BtIG
zYbw`vJ!~i8r*d7%WXAsn&_hG{0=>WyzT<ck2ruQ2lta=-R<6eywv|4wrrp^V;#s$u
zeZ8jNpThJH=C{}RpUwQ<I{)`Ge^CGbL$pvoe+2zhKi`bwGzXcEv#dnF{7dv}{rnm9
ztbX2vc$k7=vS7Y>o&U{AV@ohhH`wlH{kF2qim(sY3I8x*AE^_*1#x*uA0Nq|l5eHo
zs|BoPc}M=+K_`$&`n^VR-;utpZP?GFb@uf*^BVpChlxY0I`Qbmyp#TaEB0%xKV~16
z_0=yQin{CP$Dp42c`tOletr__t)KTtgY@(D*q@nxpAyd(Se~F?*O2Ar`gLI}o1tGW
z;bNGdt^ePIFirL0R<JBdzdRXTub-Fuqukr%o+9^G(J|yHxi8DTP3}YTe36MA>av~x
zJ76bdf%xl{iB~tZuG<mygjC3cTquMRD1&(F;rM=|)PQ+Cjs>>h1-=joiI4&rkORd~
z230`aq!I{ekOjF=2-TqQUT6s#Z~%8mhGNk0+QsXj;tZ)!0agt-HiSVw$h)mI*nx~K
zPWNxc5qu#M;z8cKQ{WU-Kn<8TVLPw`XDGK|zA5wI2A<#xWzC33bK(Xr5CYkd4@Ds7
z-4bj-o>Aoa#TVis8|2zH=i0V{K*)kTC<F_h7d>Dign$+2S@N5Fn2__H21Ov{i350n
z7Lp+yvLPSrDZ2t81`;3zY`9K5z#Bp!9m=5^<O7l=*nlg@y&xUr+0TM!0Y^xNbjXH$
zD4@KwrVO-$WGDqU4RHcrh=e3a1G(>4gIzoJ4>6Dhc~A&m?b$cTGfy5QK8ZpRoPu(|
z`Hhker=S9AK+}=5f-~ep5uAc@r~(T+jtP$73LcOG>5v75P!2LUn+>>v2TX(*NQMl^
zh9Wox)nL|{_<>s&;tr9J0LhRBuH2(NU?K!UBqTv5<Ul?YK?Rs~B^}@bz7P+okOjF=
z0%ai2Tozo*MG)DY^A2f{4S7%mrC{kmTEG$9AP}s2a15{qXYc}F2!l9Cfpo}%LMVqS
zu;_{Xzy&5kAZQ^CGNAy<pc2e`aUFsylsRGxC*lO95ZRk_K_X;8HsnDel!HS3vISU!
z9k_ungh3o6Ksq>5zg!5XpaSG$fhE|0JxIN?Cxk%)q(BDbg492kLoHZP-z@dew%`g<
z7aarg!At6-Goc8o!Ky#uz#Y6m>Zem73ksnWDnW4}EMz}L+@J=`1`t0G=iv_E1(i?(
zW&>Fc_TUU|;0y7P2q};aMQ{qrp$aTqi6>YO!d8$EMQ{qLK^aUKum(r)gfK{i6iA0G
zC<K=w<S!@(b2qjDJD3O|kP7*53MxSvN*W;q!XO{2KpDm{!5VDA0o=eB;-CnM!FD)t
z0$1>Wi4X{pkOUc!2PIGmHDKnB4Z#K+!4142A1p_Z2JnE8k(@UufpSP6#WA54EIi1Q
zU^yC_Lo(z;G1!jbyg(q7gZ)_c3B@2cK}+z01V|Bmn*0QXpo}A};0uwE4dr0@499_x
zXW0e{;S|(@!vw-ZBxHisMC<?|U^a=gKs+RYjLl{-g|vf=3+VzLkO--e2^C;F72ALt
zc!Dpa`CtoBe2EVfg5t+KWCU_fpcX8GD3hQJsvtd>G(a_IXR;0oK#Atq;0<xJ$U~3^
zDRJxzO2KjtaR4u{nTLXmC6^yh-k8ri@B+Jqq#v~4vWT=mCX|6@F~<RKNP+?=fzkx7
zlO<e-;JK7-AsNcRav9r!Jvf6Kc!D>CKn!Rh2~r^gvLO!&AvclZzlcH&SS@G!7P|K`
z2UOm*u2|~cH{}^i-o@n|Tb}pjSx@Sa<Q-Jr_2hX{>VKr3Lf%L1SuXExPx4>tcY5jf
z=Y}5A@a}`k``7EJyw4mXjFk2A94y=QW%)tENxjP+^hN&5d(uQy-myla*U=?tLv#Qt
z?|6x*ya&m%h}2a{9gMt7^hD*I@ikQ5$4pr-@i$IJ3m7e6w1Ck9Mhh4%V6=eI0!9lM
zEnu|3e~Sg`k&wFI|2Ij(c=s`U2kytbGw)md;IW7Kmdg8))S=5eo4iB0uzUav1Y6b*
zlX=3(x_|e#8HwuO@qI?VEj{QPP2KN#a@@c2&F25dZ!mKH<(rG-mAc<pWd1?lS!}Vd
z1Gs`Ggg^{vAsNyj6LO&t%AgWzz|4g3kPGEd4YWm9JRu&EK)#*CK?dYNVtvAc^Z{^g
z!1fRaMNkVC4cQJ#Kt2Xpg0$}|0cqc7*NA!t2oY^eSV#kDuV>bTIw)|11jvPQs0Qg^
z;@+IJK_=uvDTwV{!4oRUo6=s!@a-d=d5ecw2fk1XZrC&i5+J)3$F#=o;MtnAK@Jo^
zd>iJW048#sN=LG6$cK=}sk4F%@X}Bp1exI2g>?`IQb(^)2V)8L4jdmM!M!K@f@F}o
z?;4PL?_x*Pi8?Nb>5V<12F&}APU?`Q{@4+!z=JwsZ%Ba>kj@;I;0ke&2+0Gm2h@U@
zE8Bt_q(A|bKp9j*4VVpLA7BGgCoFZp=0i}J2r(evdZp}YfJzx>oQxJQTEJ)lqXmo>
zFj~N90iy+s7Wi+r0Ixszi80|VgKyIPyd$E$BmAHD_6rZ}?HC*t<Q*P5V>$!L1%-Jt
z-dnVHEWh5-Q32k5k&!a18^6dqE<8pylMU1@y%|YIw@QZE@ax7p*?&L9rG<$v?*+<3
z_);m4G{2*xLj$5Bq9cN1G<M@UX~sszgocOC4V^JfGbAEBGBhkm#(A-A;o~zaz{f8p
zCMwiFHiiK@9${HXP*`M8RNbXK%d^}sCX8dqHZoA1j3dYJQhqZS{v({h!E|Aw89l5q
zVJ3vm2#lB=tu$kPSVZg$hHeXun4t?ZXz+*!gz;!0?F0wt$4-;BeKNH~A4MCZy?GC+
zYGk39&>T@eF5mE=7!P&qCmBzWR}*~Uw6x5W4Szei_F$Qexsr`ae*$$(bN#qcGUkiC
z2TOZT!*X@}5|+ujeDpMD_s%+X)Fj>h3R$;__s6j&Q9;oR7Rq0Bn_^TqrjTyAPqaGh
zjJht4b-MA5bSKy_(x$}EopnDr$o~9egM&F~OtRb;)$LEl2vWyjQTOF~XSpuC;W#oL
z%mDqEO<LZ`WqO*7DzBe?QD^L#Y@ymyKV<uF%&FSb8H3+vx-*WEhV_PVj9i(&*S2b!
zSgwnESb&e-cIwzYEdM>5<HO><Hka*uS*IKGXI4aLpwAt{%UC<9<dsO$HwOJump;`_
znA8vl$umA-K{KYsgy_yyI_vsk5B>S|F<4&45K6dbySi4ExJ+bycw5<4#(=*Y7ul9w
z-pK<qV?(1D64G#3HBNzd*82s-#NLgRZ0pK8X^+YH?sFJQCp6$rtY{a)xizHKjC1=4
z_UPAKJ(uc!li7Bs8mHO6ij?fv`OYz;g6<b5$-ugE_1ic}-h7ew`v=7-j5uLh#oO|3
zoKpEO?OMi~#QrKyVnZ$K?srTXzsi$!?P08mZah81SW{P<>h>*dQe;^*ValkJF^)6T
zz~j?TFZLU;cVm(1wQ=Tef3U!A-5jp{K?;5$if3A$zmdA((v3@B%=ei%cEGvjSC3B2
zYtv_R<il;ObN)ewOs76aV`@5n?rqc0AK#gmQMmO@+wGVAJlg#<W68*A{g$2>65em|
zKI$LU{Vld`7(DytmRaQ~KYXxZ$Dzj$Z2ZV(%ZcgxR+JWf=39AT_W%9ygBrU@dLKM4
zka4`9Us3{2XDk|Z`=i2-ANzFGrK)ZV-fTxZFx7rFmcE}YXuHujxTtExPxeiIs`up!
zr$+l9tc^EqzbWACfe+}bNPVQnboh_!I=5``-PWw0yH~y0X3^;EWu@~!^gllCLeb8R
zonCmeigt7A{<?MR`1IsohS@q@Yp-d4c2{Y_*5-`{E_>t5{M=oKFKX=HroRjAD>bHR
z2amke;N0_bI)Aj=tH+>k&iTIc;S*DBjpP0NedGN^@zlxq3dI{2=G$M0yprMbY3!!!
zjShMy#BW=(+bQVwn)hCB@QamkydUFuKgRKXjN|?M`^Nh*j^nfHq1WqgHBVXfN!IFx
z`=6Zt<ibuvHq-xjn3T`Q1_jmT4_P_BTUgh{X0N{0q>Z-v$bxx=kzX(GbYWfP_V4-5
z*jK_`is)s1<nvA0TbkVb!MCbm(-|9g4{bK|;6LZ=-<Eu?t<y~UE)JA%D{i%kD{|O(
z!X@#$>ut_t1%@0g^Nk*NX=S77Tl-8NE&aGshfBDiqT<kB9GzNkt89>3wClMD)5I&g
zjN|xdOsDu2?~5K&wb<UFfxA*s{OG`zpKY=&+<l<o-pcRZ?!1PV(P&Hce4KnI`sVII
zRmV#Q=3TvTG`#S}0=uF|+NFKjsAm7f+MS>C?NvP=X7!zRZ}9Cf#yE~o>X@{(Hh%P>
zSM73P+@QnL{FnUl{_&kNYc9T*vg>qF?254^AKHBzI(gB=NxY|sb7+m}2iL|`U7e-8
zvA#`7?%qx9&Gt<mSzFc8$*gKX+{44FsyG)7)$8L}=6C+#`&)#pUw5kZ^T|_gR_9$_
zS+?nm@`{DCHn|@U+Jf%`^|&K;+ok4oIrhxinwzobzHT#R;LW+4`;PHE-RtSHMWaWq
z7>u6>^|<{GyY$#>@`lycLt}ne`Qt8&H)CHKQ(e3H*sRZ6b!*e?=lOiUca``(zkk-n
zcPsrDeD(F#ot+#;zuLX}`%SL}-CDT4k@u3vUGWpDe5+n>=X)E+@iC6$qcL56tnB00
z`;C6?%##CWPW!1#v#6C9m)7)r@#uw<iwh>VnoPZGo|^xz7q3pxE^5DNn&#%PiT&12
zp0pySy8Xzp8NHsp6|<znN!p{FRl~U*c=Rpn^A7u)lnt#OIoxUKtL8UOj?DG$v?y}6
zdCS_{TH1N2;f&+>Om5Zq=cm4TYUPuU%`2G3wd>Veu3roDVFUA?dm?jbw+W%Ic6a#3
z>eHukG8&nd*KY6Ic|uCpH>qbFDdDzlj(pvI+2)TYB!p2Xp0IG-UgJ1EVi)5$K2yK-
z_8xh8n<lbz=h*Rcsoz%fi*Xzu<2XKYeN?!892GV=I{b#)(7gdqmztc}SafOrgo~P0
zv;XQiKF0BRjN|hpETfM--*Ggi!#v!F4t}<*P2fwjzdLbl_9t5pD9;?4`^dXdC)y`$
z92p(K`=$C^Y<?iEllO(&Umdm{-*U@d>zv4r+3hCethOBNaJjJE%`N?T&Q`w%ICwSN
zJ7ve5kGCF4t)Jp>+P&FQ<M=#c=l(w)@mf4&`0@k&&v%?sR^hSlpMFC#9LA@(Ozd%H
z?~dn};#cQk^?bbZtkaDvF}K3|_Lv^Ed04Zz>t!FX*f~mReXFpMXOBbk@KcAWc^or*
z3s=99d-A=lDa+*BolNXX%cpF<5h_}m8H?W?)z3Pg$JFs|Sf`Ftz-zp8ljl3HqOC<A
zN1O1jp+Ox`zPoAV-Qx-L1+)Vy-{QNY5)a02FnmK+zb#8Vda^u?<uZ*SoP2K{i%J%G
z8XbW?gFcInNBvN~p{nC0Ohz~He+qg9or+4le9#8$ld#&!s6XnD2BG0-Fe?7usjAk#
zj)tQ<P#%L-zweP~1^=nu(B43!P-$C$y|nHqpQ*HC(Kz&Zl-sX19-W7-L*r4#+)#L3
z)9yfDK=-2y(NpLm^fbB{#Yeod1jQ%2!fDmoqg-y<;pmI#Of(6NLsz0}&{b$AnvCY7
zFQf0HtI;Af1uaEiLCeu~sHGY04$wB}t7tnk9d$roLmkl!RKE3ZMT_h6?H|K>K@22A
zHWWiOSYd4O^WX(xkN|0r3nfqqW}FBcZ~%Akh8ReK49ElV3sDJXzT_it0WXMzM3D5P
zp*c_tm0<2i+`tvQAOsR23yPo`to(@|q<ulWp%Cup&)ne0{9YgCHhcp$`Yl)Z(9U@S
zEo49;Sh`|+2!RyHhe{AXFs={=$&d|YU^$rO5D4P;B_ArlY6#~W!XORup%iMt#*KC0
z4e^i$c~A<qU^A5U;0^JR26<2l;sZu}zqmsoltC?cQYR7v$xr~*V8wfCDTPceXn2Np
z1z*rYI^;tc82y%G>*ufw<iIIVD1aSdB1A$O6hSpudUJlj3(8FRUyptx5CiGsus38f
zUkSFR*c{>sn+D=*rUa_MlCs8Sp3Zkm1!4Y*-|}oTj-%x`3)vU*()Pt2?)6t*&9aJb
zi0383G@vZwhFH6p_%QFBz%kKss0Mfbi(fZK@Phx5&vJZ>hkVO5Va~M$_xdh(Z$zG4
zO8E&7^k3eX^8(_#{9eE1Rs-=H4#vr70iy+s7BE`CXaS=I{`V}vBhRn;{~zM{=wI=(
zFDWqi+TUjL_xjeqz&FkZjXzLHn0tNjzsRyA=;NqsGydjdx;Ea@URT;~pGKuEwzQv?
zcF-@;X8C1U11Yc;UV(Lx3L8P%%csNZkOA9Z2V}u65Z?)V(0%YWyaNZ|J$N4q;A0S9
z_Mf1KLE1_iCTaT|K|CX2CPYCr#6T>}g4s|^xHxnU%!PRn5A$IGyZ~BQ2#a7bB!KkE
zUxF@$WsnHcE?OpO<1B5G#Ws>oC+s497v5m~&i14c%sB4-#xjuc9>kZPaXbT^EyW+A
z_&oo^@eHu%ZZM2xaMFP>2jB}h1z$rc9D`y(f6k9H{~4SBnZ89&LmB)N&cJt24(Ff(
zE`n_TJz5FUPeY~>&RGz7;uJcJ_zs6$E4JakH_NBN6bOd8{_{7m{u2A}VV|p+zs$TZ
z^WHESrot5XfpxRlR(wN>Z}|_{|NZ>Sze2c;;LkSq`iYl#if?D}6>rv(cOG~YTJ!%y
zwvp>x@@y_FC$A3SIR9?nBmWzIM~ps4BquNyF=bPdzRdhRzwc7+|DNynKkJW#>KG*v
zPC+?TfhYIJbSMJG;#K{-$JOI~8LGjIdI83|l<_4McklwKPso5AD1Z_uhiWjRE+CuN
zVR`SD_kByS0ei^eoxT!k!JKz;Pw)jg&Z&c%CZVa|$h&zwBta?^fcST}0Xq;s@2=nt
zVUP^spCl9HJv|?apcKUKdrTAd4@r;;Igk%Ua0(2*OX#Ac*nt~(LKq}M8e~8|ltK-d
zQOU0X7m%@h13?CQO@d6YYtC_?24oxn@f(u?*^mc?P!7`GsTRz+?rlN*(7J&5eT@Mb
zj64l;p$McLlQKgC_TUbI5D7_;2?gLmSyBp>Py^<aAy%LP7w~{c$b=lohf=5kD?V1Z
zLo%d67UY6?E9?Tk5C-C#r3z}n!kREp1GcR>N8k#PkO?JF1Ga5g2X5d6fly32XHGe4
z4R+uR`5N{ON;~!qZjcD6kO4W659Lq=Zrpdozr6UCKLw6YunfE)5JGIRI~0NAlh_q1
zpa#r3kY;cISMY#TD1vgZ?nt`97s8+h-0avl_=0^G6vRJ#JfwoNJ^w*Ix}1V?sDfHB
z?}{BD0g@pNGNAy>x)EQH@lCWKK7KPH4+^0i<fD&_m0<^N;0a-1>%j3L3DO}43PJ9d
zHDJ?&xPo-R^n^eVzwk+r0l82BB~T4!J+TWofE$Q!_z;K(@r{!KIdBTfp&HD3VP9~A
z7|=p8WI`>-fUsVW04b0TS&$0_AU<{~!OV%W18l$!+`t?1!Lm1b7(5`P5Br7^D2H@s
z_5rnE(U)fku<S>^hh)fyVh~?F20!oR%*)uLE>H{xUp-z=5l=`F9Y7qR5TxGT0em46
zvO)Z|Te@-_um|zQBmKAP`dxQ%<2*q;h!1s75Z~#kU^bj<4#Zcw)SbJy6Bgnja}?<T
z@o(-v8k<5E<U!0B<{=L}$8kO(6LP`#8O|-Ffrl6Ahjg&_VI4$5mM?h&<hze;AjgLg
za1CZ(kO+BD1<EwiAA*LGRtS5Za|TtQOed`~IA0O$A1c5t5*tGj6hRG`&*a*GND#l{
ziBZ@Ns-ZTTZDU9~Btae&!6_(*DyRkXSn?%kz#g2z4LrdcLLdeLXL0=5C}coB^tL3t
zBj*#9cLC${-(>+ak~8&h@Bcp|ESgUAhK~RL&Hes+>-(t}n&|R{6o+EdJ|N@C<VQ79
zSmomr>Eq)Q?(Y*28-*W&I9>mA-6r?`s{Q??Z?PR~&U4+}>ANr96j&yGi#4c>i8t0H
z5-$eEe#9Enl&(#*-_N(6alxs!!q|_vuoHDcgDCS&H_kZl!rObhpT9WW<$OeZhaXac
z7uneQ-JBUY_x&>|VGX_UQQ;=xjQxn;T%dTa+}v-1<5%mP{;`j-<amzJm?k-G>U#Ud
z(OwY)j(%qBM_h1}XOCWDmjy5P>*acBO|MDYUOo0<W^`fin;VyG8vo>t`R=D){cOw4
z0G`v-d=;^B``00_jUB#VQIq<OK6~`a(EanDbS@jcvf*PRmksvm@ek^%c)rw_c1#|V
z+{ig5t!2jX^MiJs3~ar8!j|E-hrT%xcEX{(?dcATCBk#3#`I>tH!t@bHAOkv`1yaf
zs#p5Kp>KnJ{(tO!30zIv-}g=-7b({eHymW1PV*p?c}Rtf;dJVp1{zM2LO2;Shs;qZ
zLgviF#f=+6#%tC!7Rhi!uJC?;YwuI1bQSmiywCeQZ|mdh+u3{VwSMcjerw!ot^Jek
z*)7Q?W0zmqmb(PsCG0`|{&V|?ZP8y7X&xOg`%21+BX8>6>wi$9)4|GM@B8HkWUc=i
z_R+ztVr=tc<@<=s_Ys%xBQD=ZT)vN3p7^f98!LO~!SANjTs|a!piA>@G2)e1-rekW
z_9K0JvK!_EM4Ho;(`(&&6ERNGP%>-cm88%LSM{gOk6j;JvEiwWVXJ2x#dmix-V|wW
z@vASYeKMuXE8j1-%J&h|dlXmJFIgD;z<IW7^oB?W?~qT1d-_=R9AGQYoz&dp{-E>E
zdK`F$_d~4zH|O*pTMm78u^v6_uMLVo+nf7t&5y4fc4X1ev-9FEYM;PhWikt|YR?_=
zdCxM^uDu(yz$2;lly=A5tty9|i{6~1ZzcC~PR4Ww1~($jNdfya2Anz7{=%{oPZvI2
zc{pG5>2A@v*_n|O!`JD&rZctwV)<LXkGR*BW^K;5zFfUVV~gpX-0+U9HtFx?^K|!D
zhMg`o$u^0qBfYe}?x5k@4r|0#kB}U!@Z??HN0>)q{hTkWa~3?_za`??`&A9M>MS`b
z9;cBxsiSgJ7sK*>#QBr+KA*gBXK~ZCoDs?IM|}Rdr}v&6eLs$VJk=LA?`%tYj(MN;
z=b61D!_6Ab`Z8k0L$`fjZVxapsj@XDcdXmaTNk=wPLAn0Li=-<Dl1(z9L+E7zSVWa
zw5eG)tnQhHKCkpTqUEYeGg47LSa>TxMSSRK=k(Uw{kOwAwk-Y7aawp2gRT}&9<EFr
z%{`07yr~1`9z~kZo@VJi7+xW#{=4ak!;P9H^w#mQ7Uz77ZP%wtE4^Kjm{V(xxJ8;h
zDko&5<Tj|6SiN?)X<h2CiE1(Nw{hKnX%RO4uvW(h{Sq*(sz?3~dL~WiJ8gic%jrhz
zX1df{aLjtBtb8AF`99(&wy~4P&U$?^{QUEtyZgk{!Ws|E?_)o{Zq_R&m)X8%zAJn^
z4VJ8)veQ*m^O3ue<NIIJ^;^$uggNUz<S+HkD#PVRw*M40{kfj#%@Egwkl&Y%UoJLq
z)R>ZDAGOe#<IXXE118-#Vo~$@@>OTko*%fdBe`SS@_odlzs$KU>eRZQd{%i;5i;RR
zR~Ng9t!C6-6Zodz(tZzS@0R3Z&YbD*<l{x2kNqaaJ-PL6WWS{|!|wOATf6n<I-OZv
z5;iQ1XoPwE1m>@NA949UVzMhPHTYn}I>Yvlo}X+uCTooMA6v@z5wr4EzK{5|+womj
zntX`<b(zx+%&#5BJ5G^i*e92O__(wf1HI8>-%Q<S-EdDrZwvi(y;h#|wcgR;O?9kQ
zWbMM^u|Y4Bc5m4;+^ymA@_oe9XW@NpL(*UQKH}X;n-=A?cFP=XC$ZWDovg)sbCG73
zMw4^?zN}b0t552x)}rXN-~Nhhwd=--<?k*8PkVN`CH$DOabwo>2bCf|b$V*^XWyM`
zLe{uA?$CUHeN32ZyY)$nO?UT4J9vxrWB;@Jh|$$ny<4MC%yYDVw-T8CCRY=$%P|zi
z3FDkn2aN8K5?vp*ued$9E`HNHIxN3Y-odl~oA;N_>s%3QKq_LLSVgSUs)%)36|qjM
zB3HiO6!roe_5$epQab?~%w2c^(LnirQ>+K-i*+b~KH3^vKn6qt@xXB)8>mHf0Wb^*
z2jYQLARExdnj10T1o!~+09uQa3S<CU4p^@Q^ai{DC9ne638VrUKt5pLh&TXyzz2u|
zl7Xv0HlXc<aDd)`42T4hfK=cSkPk%SMf|W~kP(OjjsqEh_Hf7u*aN{p3~&U<1awDW
z{R{BFb-(G4>^1#Y`%JZAA3*W_rT>Y&rAesg(zGjbnSgT+)<WTT9#HPeHBhdBat)Mg
zpj-px8YtI5xdzHLP_BV;4U}tu){Ph4|8IgZGVNifwd<qxamF(KUT45@7r^PjCEyyM
za_e!g8_)w#x&Nwj08Stdd*FY{Uh^#IsVwIf3`3g4fHBY-XakTl0h<99fR%7<I5+?Z
z5`MdYM*^dO(SQ_?0b3CFE#QG#UX^7}`v25@)9PnG&_r(pFcp{vOb2EF^zM5W5DCl%
z#z0R#fFCdiziF?<T<|<#KCl2-2wcY`auj$GuozeZL<38KWx#S^1+Wqzw;F8Kn&bKc
z@A2&4fXdZGTt5Tk%J*~gdML|&ZuPy~v^SXSysZ1UG2KM-{G25a2BZR4fegSF^<5Nj
z1fV_LwNN2?0Xu<5fND=SorP%$bO)S(XyBjrbjM-J=@CGCy6L4vHGuYX$6)Q_9f0<9
z=K*aYSTLXjqJS768=(E%-2o>c8n_B%0IvYrw@v%BwW}gcfFa-v&|d8Wz#Txl8twtK
zH`@~E4J21b*g!r|O$YJ-@pwsc6?g=^0$RdOeSmNv5}-3r=!}z8;3{B%mndxk8-Vsp
z4+CTX9opI(7zW6I13)TZSO@-qM1b}~rvf*CJ9zmbMuyk|i9jwevL50F!hlF19!Lg`
z1J&xoFE9+42c!U30s3a5585d@_aPOy3dG_4)m7jT@CtB7S&RqLfeavD1o;~ykAX12
zv<YMeqJTIcxGDSt$$+6Do(E*W0U#5|1Hzg?E+8F{HAfx+@jxa(d!JhZ`Yn-mU?dO?
zqyV{qRx9K!5C+5p$-r@d_BfjYUO*TS4`c)RKumk+2}lNx18G1epw$6QHDCbH-ev_5
z4nzX+z)s)@a0AE%bj64Rumwf}VF2xYUIEbF=i>mKH$vxwBpM-4jiGaZ_ArM5kw6lV
z0qC0G9U*YU6k!9j|JVjd1hRpAV1+sS0=jt7CIalOp<`etklhjbwSkQTu7Ez?y*L51
zwl&ulX|jWVU?iZ`74`zqxt*^7({9iqklr8n98hKfCr9WBNCHv^B7UISAlQL3!Ws;_
z1zdq>ARh1;3I>t^-Qh?h5DmlwVWXf6fX<hlHyXMI@&GzJmi7S007<|dpq4Ar0niz+
zbnfd4AkGcX0vUkV9q|GRARLGUqJcOd2{-_x0O`OTAQQ+1I2qCkWXQpQ*aP|iD(FI1
z*m=1t*Fd=j$~91~fpQJ}8x3gTVZR^V|L-k)&VFQ=Z}3Qew=o`p@{v+snYro6K)J#{
zFjx{8;uq}gE0@Rv1N{Tr!w1Rwzxh0X&Rh+wc0wOSgZ^jV3E--Loq$#tvnVfD;Bd=3
zC@4fOk;&acJSBeq!QLL;?$Tgye?N9EKyP~RYiGL)*XWz{6c(L#=BVK-4+@fcqI<y6
zcf@-NaXVGuAGQQh{-T@4wL{#m__%|-{6l<XlF&f!U?F29!Tu6=f4?Aq9}4Q5XA_VN
zbT)wq%zyWsWv#^5U&fv#IaE5x(}X9uR!A_q;+!7X2y)n7VLIRi2nr7L_VX+vK|`Dt
z7b&EH1yJ~(9mW3>XRW8eeMb!qCQB6l=JgTkEt5<55aEw>MLM9fz#KK$J?~)rZi4Gx
z;FZWJM-4wIY%^5&L_O31ixr*~gB6w3{NQOydv_KFU3VKFEDvIu43_(`d#<=gXD1ef
z>mv=K@aQ=O*c9n6xaSt);UN!Xat^~iI*Za#!%ONX<MV-@aVj33hj$<a*bw)~PUs9v
zl^n=Lrc+$zbT}(LcV5rjY}g9@?st{xot+m&`P5Z7yMoRlCl>%clCAoHts&=e-oHd5
zb*G|SLW$;Wg=8<mv2!da4_tAxxV_flH1+afA9NPFG2;7Mkd4l^pgap;dRMqpKGor>
z>2-lTPDqC)=N}U68{~=0OmCD&g5N-YPd}+ItdR6(i|b7RoR1+~mjroFkh5|^y4ZG&
z*F|@P%iF9jG|7+EiAlG0fo=euiJ1Ne^DpuC8|Ob(E(w(e2l@L+ygm4u?OSC=#PmS<
zWs9)L792I?VTwQ$T@-lL^CUCH$=hn-eOzMcAv@sjd4%}6Q&k~hi6#A#{)KzqK63s#
zh3AUvApp(~@%F>@5MMV~8?QIgE3Y32A`cuVm+^W~ooC_&{gbQA6Rd^f`aut3d^7~b
zSP~E-4;(L%Dio67@e1gi%B<kEII;ATj#Xi22w~TNPpY4EfB^{GRtP&t9;_B}>0wh^
zwGl=gNPw~>4^?}b;%x}~p?mhsegtza6rIb(vl*C6kR!82nlD-=ZkFec{#e(v)!hRd
zrgh9XJg;8jggt|&ZZhf|v1>^>>JK~eXZdCB!DHcnuNg0GySrEZ7mM&`@$H9tq|cbB
z3`sNyS#byRk1V{#H5=?dV_E6##4BBOxQ$C%x_9WP^U2J2Vb#_x3}@V)vk7OwV$3Vj
z^twEKKDXVZWryAJ$QltIZ}#4CJwKuOZMmUSLURA^Ik3(zEZ*e}>Q(M(b<X_fe#w=`
zo$C-0KImNfsNlH+doCPW&-id!AAI+yGle(ng!@mwPD*((KI~1(?WA1&cSk<hAME)c
z^jx4*Xw|D-k>=hu<gfhPl)*t6HZvwW4+z}3^i=t|DUQ#!9PVwU=UaX9oPa_0117Cm
zaI<w!ttkl{*B=d^NVD0cnAnwz7nwbMy=Pu%-4(ZUHOkLTA-#kL*Szo4Vc#>WYRmpO
zlUH&5dOg?GOAmZX4z6hXe)i4(AJ0vBh~B<P^SE2&kkDg8o*37ub8lLH%G=9-&8!q0
zl@~Q-QMRGUN!z96=cbgOn^JymO8L1d<>#i9pPQmzb?NG<0a0yM*z8=1aS!VkA5Exy
z$+5j{g-)jS2fLlSIp>XUX8e?nH6%&i{YA|J>c7VObi7XzX(m+Hd3!O-*S)V@&Z_0X
zF|`8Zd2*loFGjuXc+!5(?ecR|Bu|z%3g2b(tKqS_TXVL|Ip6q^<ETlW=QqLlyCdoE
zw9e0yr{v9;`o6u>=in&Ep+QdVn#6`Rbx5>6+&uDK=60-UV0v~ls4y@w(I~=famwb=
z`qu3yJRbe==)^fUX6~328Ia%K3F8k8F7RFKhL#s6Y|ZI<_>JbVoT@SRteSM=WZjQm
ze$i`)ubFe#JgmRyLjE>i)IK)7^15ZZc81rsJrFMtIh3E9LVB@2Yhx6vv8`6Z35OT+
z|JqS)d&mNZ-2B*!<F40jUtj0%NqFyQOa8_j8u#pQw%g=ew-dIu68B%*A@}*3b@ERU
zo2!hR(a4s*fqJhO`Fm;}A5ea7ij_QcWm=B&>pEE+mt{qIX|k`<&iE>BOIx%#`y}7Y
z#<6y6wfkqPO6so)Xw%_~(_Yx<O*8VB!JT}X(`re*myNu7oR(hr;22TsR_3+1V{Kc<
z`be|7VO}7K<;T1ewX#>bJfAblv4(?3E903PW_T#_VrN9gbck4)r+FcUe>X1D9JY9P
z^<$fTqw0>me#A4{e(8tF3p_X0eYp1K$FQ_dW{;|K+;+@ah%_JPRd~}f{?U$GyS1bH
zXW8_#ew;q=d81A37P{W5-1O9o8#pIMpZrxmrDt|4^Qaq6txkS_shijHD|>%QAAHEH
zUrMNR{+4vS*ItbYrt))B%Fj*d)|c#H#lF_3K6YKS%%EQO+Y`H=*d<$h&=NVnPVhVW
zsrvJP>~;7i67x6pXj<6Ot+hM1w%gR&(pB_}$(DVOd_@7#XJ0L8o;$JCLd@S`&Pk*h
zd*ph~e2)t+m0_>z>`Pe}GA`ldCe8SX?=oX6dM+QKoP+guEWGk_QzqWDh^ZGE^|0v;
zi}8y6_;z(a(qD}0k*l+&zs$PuJbkD<WpK-T>#x=CA9h!<Eq(iAPOJ7A>}jt>{ytVc
zZ-07+=)#>&cPbpc`$yKud*$b*kY38qO&JpV>jc-Jy_;T$cJ3d%18bJB_DZCgS$=Lx
z`MD{ugA@A0(wlQLA8#~xb-bOK$@6SqhtogX=r5Zzci!izM!8W~uWV2D@^s|L`-ZlP
zyB7|nF0OtxZP{;~bQ*v9m}=PbxJ4hQtm(7xeh@En%g;^OU-N(BxhWW)sn#HHgYh?=
zn?mpSFtyJdniypj{8bO!1B};l%AVi`U^L&H2#n>HoFSOPY6gA-rgxCS`U1Ajn!=@b
zaxf|8M!}yJ{=za!WlgXv7;$iJV1&)d!C2}_pG;92fyaPp-NINfg}(w2)(x=r1Qb5H
z$J{)CoC5x6jX?moJs9sfm3R$C?^~644aZFclPr_LL%>tO9^h$UJj+c7V@Sopyp<H@
zZ18FDeDFmux;e@x;3#kocoCS^Gb{#^d<OvGeK~uNPVzyQToOQTIsB1cSAp@Wk;5>6
zoktT3ZiC<GZYeR$;MRjN%;plols}un6Tn-*kdeYuo&j$MXMj=7E8l~6fvq9WUT}Xf
zx)n+fFyvC610M$KR=|2)@F4IBFumtT8kzjI2t#<s&E9=0VH8LLeSV0!j+HoNUHoMO
zCOvlsi@<hZ(r;HV=|N23-{Ug7B0Xs08tjER=w3;G3<XyL!)^+m6W;%FHE_N7a|7T{
z3)csNb-;tb2N3rE=5u?BpU-p07H9aN(4>bld*uwqBYyyUzzYZmVt^ySRUjXz1><Q8
z*aHe63P=LdfNVe;1>=qd{s!^^T}!Mb2ZjL(AQD&sBmzf(t3WoOZH4j(j0A##c;rbM
zkdD9e0DWuN3LpdK0m;B4fX-aC0c1cVuoJieXxTtcz!?Y!;(!z&8>rR^&j97;^q~Gl
zC2R}00#qT#0mp$1p!}R3*y9N31xN;N0GtcT2rvv#05L!skPGOJgk1s7KnChasvo-p
z!9W};8rnmUh`+M|LsVj}Ksfxy00)4pz$-v^6vCMZn+E0q>EZB;#zX<+qQOZ)V`GWR
z%Tx(_2j_zmBlxvXwDzhuAZo0^S=L6_`1>kA`-kXk9{MKabX?D$hPd&!<#faWegxzK
zz46-=b#<`51~(mSI0JEjoxn%HuHZCqK45?bnf4sn09SE68vJk0;n8iY!M-1vITLC8
z31I^Ivrzv7dA1cfkzGaX;i$+3193nqkO^pYt%!^%cjX!=*Fd=j$~ExcsR1-?+?Owc
z1iEZoz|{uRdP$XYGT_%|9-;vauG2cugZP`iyG`p(pXu@Ig_CiO*7?#}-GADDZijoc
z=9czs(t7yqc!t)d?*!9&a#|n08-LT<Y+6T6>!oR3G_7;q2+&&QJj6-g0B(ePje#bB
z%8Br|IY8gURsWv(fAzk0ivJSirG2vGZh~(Me?I^}7XH?NT$+H&Rm0yk)PC1M+G(Cw
z<-WClocxsUA?G#qPkYG89+F@y1PAIzfy=sYyf=al2X+F-0UF=j0rCKj`ilU%K%6De
z9iVT6y8?91WHb;D+yGtyhA3zw0UC3M0rP+ufclpQfDGUjV1PbmOMv#8j|9AcU|>2B
z1;hY}zyTlyNC)T};*r1+AQzxMr7qAGumMH_K0p*ed(yk3-$?r!XaF9Ae&HQ}zAvs%
z{X#$s6BS~>7N~_jU3b74pgvwMpoKl=!+=O&1webvU4eN3efwLCcbBe!0-$~8^e!`(
z7z1~G4DRV$->yIua2!YnbdfLJ0R^B0XwP{r&=O_A5*P_Y0mp%Kz^4xM3($V@Oh8l@
z@dN2V1`w_fc>&s6u2l~*!49Sa(Lj0wq!*JIra*TfpZ;!yzXAFdHZ6=71GYdWP|Fbc
z2V4d8n?WWZxdZM2d4Q=AWCo%D`ZjY0@CryZM_3j}8_*pH10n$@jE^IM6+o^v#^xPy
z51{ez$Sz11kPIknVROJ8pq3r-08j!^z;PfC(C&)xyFnj7I553Co&{2XT0Iai;0(9|
zK0p{S9f$&AfJ7h}I1cRWiE&RaFz^bfh63;l@`CDV9Wd<)sRX9A`levo7f}UF?Lh-D
z)#D;C)#2r?Tm$7ADAz!_2Ff*1u7Pq5lxyJsO$}&4EVm!t|L^1PF7=Urz572DTR8c9
z|3B>ccN6weXKV0zOhX8IM~Ptu*II-=bvsQOE=nY{jaqeNf&^zJ$R!GYA8+^Z*4F+C
zd7w1dKd@yh8{QkQJ&8;jEbWY7u!ps#ZcF;(D<@*-0?@u`G455u*vL^M*vmVJWZ?Hw
zw-nJe1xI^fJp@^4>`6{t)(#?!jecBKg+EJM(7%?q9pq5StI}<6O_H{#yrv>tX#f4X
z^$qa}_NJ}-f_ndrZjB*>O4iH5`3s3usNgyQ7=E(#5H=!=Db-~Sl6y%!L!^N+xlDpW
z<YP0=-&@wXh$YzgNPXR8Qi)h<W@aWfle<}38p(_-#U>UOayKIncXLw@4>vPY)6Q*G
zJ}u3S<yKM?53#A0v60Np++AwqE;sRzN{!t-Oyn|;&Z6c8e%-B%Jj8Bha#N|BsgcaX
zNNjE*l^RK{%sfo3++-F;okf(9|EwEVwy#@<tEe}cPnV&+gC)MZ!`op8jHOj}sM^zS
z4jnjZplS$Fu)X`X2;Y)jld>J{_{pwg*vVP5>+U{ssULjvd(-a;`ZdJ71-beF{fTJ;
z<}yB4r*h`Xm!SU%3T|O-?P`SoJiPr3#Z1>CAuUBocd9WikgosY(+FLgv)@?-zs-v1
z-a)7X)OGJrg6<tOO4hxDMp50XY@6OOl2f<sJ|fIZ{Ge@{8i{2VR#FcO53z;J%2H-&
z0`oO9HghwvG_#VLnH1W#iQLFs?qOwSZY;Hsxx34)j7+SI-HnZ<Zn!QrF;};36H6l_
zD-W^U(%eWcHZv8Q$t<NtrlxLIZdR7Y9%5<PZF_qeZM!pcP~5h=vTI-Kw+FjkRKF_Q
zW(RO^U)whK<p*v1zfHm4Z`(ifX)LhqDh0p4ZQG>#;<in?FUht^_y1(uu9({-r*7Lr
zMQ9U$(6*(fmL4)IvAeNM>MoO+o52`OO~n?Lre+p0v5C~8(6;4nQnE}_Qx6MVH$@FB
zbF;Lta`P}k<&7Kawr%NVf=0pJ1O6<<9>!ub4<mDTH&ZJsb5og{vAI>*ZToW>ZM#2o
zP~5hi*tM^1+nHT2*|zCyQgX%XZPAa~_J5m#zu&e^3T&CLw_6qb{<dwC?u*+t>Aob}
zCf)y&ZQEe}ot(ODdx|h$+d-}W^c_v6n+ch;Sng)-W^QIIHnlX9!FG*I-HhDD?lP%b
zy=^8Fo0=IL8(X?t$>e5cRwnNF%fsBm$XG0s$=qb>wrwOfad(q>$jo8=VpDfx3o9e3
ziLt4NyStTCZenIycH4H~(^YDp#05GiZrc)e?Q7eXvFjz<_5tef!xgt}+aI;<|274G
zzikgHuw~x1`xN~Cwr!K{i`zEoz9icw-T#wq>*JjRId$8fD8l=bAGB?mR4Oy`urQLM
z3vFrYVPa}wCKaPrmKn>8EG(q5!g|{Xb*_<#sildzrK#A;Tr4&AaC0{{H#WvEGr5JC
zx^0V%Wo~B17M5~LsocYoI^I?m=4KXFG7EHgOvJG5=IC&jrN6zljJE9u9Td0iAa?C*
z+YV*di`w=Bp})OCk7KU5ZM*)cZU6TvxTtX>Ritkuy#!a-=ME~cXWqWO3x0pwzDfVZ
z?VI#pl6{l@i`%z{p#R*Oym+HPb%0?&gb45KRQAozXTyxaSP9OK<42RK5n<`Q=FUt9
z6z11Xx8Te{SKOp?>v5JC#p5l*Z#sL-3p_<c*9&dRfz#Goj%&h6TSWx3ww6eIjIFH;
z<SVVGj_@hGqh$=Q)b1|A<L5#6a~hp6UqVh@x93E7_bV3K#c$}g^p@@4>ox_l6xZ!j
zTq}!iOKnY&ZqjYV#$^ky)Fuhxsp~cg>n+Hs>sAMG9WR4!OP|U3_qzQFvJ}^Cvoh+U
z)HxZXn{;be#_&p=jX`+oy49{rnk}l^zKF}#sC2t6eYElKb=$K9-O`!+WwF~*yY)yn
z>2`4$!z*>fgz!kWi-r1@zDqz3OEB186fD!=)*`OsD&5jNF3s8T)h$0qWuvOmO6?OA
z%)pi2BjEFa=5<SOZ2pbvU|ZZ=T1?+`o#xS2u<M2GI_WKy>8+$h6tA62ZK#>v)(UzX
zR*#o*D2U8+Adrr@bdA-=7{O9Zy!uN0aBi)y+%MSLS{5Sp!J(~m+0)10P3rUY6u780
zW=2E&y#2g`y`?@l$Fo4&Cgvt`xztK*VkMIr$t{h{t>nfsvANjY!b5K6?&eM-25RFi
zdC`jfFD{rnx5XX$W{hgilIG4ye;1hkJkZu@>UD=*I3tZ%ro*-1)5PZ7MEFhLf^pPf
z$ICLEkUdQh^dh2;6I=s;rWj~>%pV9>$%mmboKnr9u+=QpD@!w?DZ%mQk<z@NHtt?x
z>EquQ&^78xUt!m56v492EG?>ZWDDtN2tSk#N>4-h-B~OhrA=3>rK2>jWll$ZwRDi}
zQ#!h_Jh2fvEJf2o>rct4r{xb3)@~I|OQ}t0VOmP{TIRG|f*dM4EK6E4h4oevq=&jQ
zqk((Shpq`LcPjfTwPI3BOKIbpGN<Kc3Hd_bSaQ^WeIaMOJ7c{o@{6imb-SZ<i*RiX
zG6;SH<-y~mKJZIty|%>lYy5Ro!@+V-|G@FM#qNp0w^^Jvl2C+?*OPRsh#e=B;ld$^
z0y|zH!kW0E`YLr2xlmuFdM&fQA|c23<h_y-0jHjpBoW%GqG>6$TU?lyQoWWrE$bo2
z_oQVf?1G%S9X~`~zABoQQoG%SX(`ofnbY#%|3N!eikP~Jv@1^_r^2*Ixi7UVU8t{8
zy_Q*DkJR)<WtQq=`u-BiGG8ij(z*hrR=u6H$1~*AZ8-wh;)<oGv<Yyv^pxhc%;^bH
zOHWzqWPN(EUMwv`5k`8^w3OP_Elf+PUdx=8f!~>yM<t}?g9wQ;D`ID*4i5{{QmWT7
zr{xXg_^vvpDddJzw=r|*LtHd1r4Gjm(^9I}GN+}(cjk-IkWY(xzw$Z4a4njaQipqm
zX(`ofnbY!2EiI*$|Lww>6#A|jIra3^5ush?)5E{k$0z`2&r7`IQiVhj9QgHEq3u7f
zv%w(ZKM=?_b+8NatNPYDkX>b)G@hV3kiI{uS}(FsmG0)a0jHksd+>L>%;{Dwz4_N^
zFH1mWPXBe5*21+&l>R*QyT3|*3zqyM>HiJSzA8QaMVIpYc=F304n(E#BrkFC{|nb*
z(by`vg!G?a*NU#i3Zo7!Ts%Pi;8@@@{E5u@aWlRKLEi*nomq)M^zjFDe%-y~u<37m
zVDefb%&%SHSkM+X->b>1`o0M5m0@$f=tw&tPREd7MMyBM!{Wb9!hb`B7mDr=!r;7*
zUpFslU=Zt%4@0>5e46<+fo#nc-yh#C*uSh5FBzpBTaMUz9s?2bUr0Y&H}@~g{p9~d
z!G~=B{C=h|@5S(^UiPVvb4W<*u-3Q<r=HeF(2uSKpVy_QwJb%{+PW<1ElWrwYgyB*
zUfwCqs`{;W8w#apn$IB3;?mPx_HtQDlFJ@Y+0(0DzA3$9ggnj`(i?&_lRYaa@gnT|
z64Lwa;z|kmwhs#KpXam+?a&tf)XOyA*XF--6W5kPDVirD5z1WYc_P$6v^4eG6|QPg
ztH{mY-v@D()s7lL4pqBJGEY{OopuNWPQC18QrW>~Ne!A>rYX&D))Qs1_`)Ta-z)c1
zR?qS6ox0q*?Z1}$JlTKga+lp~zZSd9`c5k*_h@0>lD;`hj=Icb$JA&3jDDRHFSlx5
zsnp5HLeW~Xn*LjMV1ziR|3r1@C&Z<02P(O2JK!c9O-GVk^qNT@ewD@KDs6J{N9C&f
z4|36WcFC#Bby0-zYf-sMohbZKxy~c5lJuobN`?CjR0G}tS{TzEFD6%MlYS-16^XFE
zc7^?lDBP@oxKwh{Jo+8zNeeQK#Jv$#tn6a0Tw6~M{v?H42a3OpD8u|^%U0|mv%(Qg
z=`%olUxdo5%DxT=`sxDtXjzXnP@BfU)=XBF-Ix06p(K3?T|ES*?h5rqcK>q`eerAf
z`8iX*>ZK>u<#jUV!&0}qSt69vV)B;us{Kdhor$<q`KvBhun8|0iAV1XsL7#u5k)b%
zN?X`ll3b*xuU(-YZE>@%njYuCzKro(c>k#WE=lN87dN+3S58=43+AT2oT0SWQ6#gv
zj;fi`m7;Y<oCxn!it4D;N!gNgR2ExXi?~Y4yLdq^9}T{a^#p4}f9XZ#Dz$i(Bv)@r
z@K>%d@0@V2vRdA$>x;fIPENf|GK1eZn<8bi)QQZJ<SL84=zH-c>FcT>mwFitKs%9M
zOs>)<B!5&cf5cUiTt4Q!zSQL!0Kcz_%2n#*;*ZMZ@DFlnS$r+mYZ3Z#or>gRsS|}i
zD%VTIRg%79N|37^(jYD>SE-YJKPp$-f6$kyC9khapo#)E!LL(Mxk`OuUy@vW$i@FJ
zERWi_mGBR8r3rGOSg^hr&0$&Mhig%}N}X6NNv^V#M~h<RafC2dNTfv@a8m%<A2b2b
z5@9Zpm#dT!mbJCJzpt-%u=;Gvx5r$neyc6wQ6F=u=27_XpVGG})h2M@w|S9ylw$WK
zK5{?LU@v%MZAPGwwis)=Lf>uX)8-APw23>jvhxFJ<7bj2QlCJ%R5o4`qQKxzPD}j0
zInMmQnPyj7bOA@xC)DSssp1AA^kIcGmp=9@eY`4@2V+8wPcw}%zjlRVYY}d$&+*VZ
zA@a}9@3K6WDDa!wu5m)XwX`80Mbq#YV=t}?pKqn7p={&V?@fpLyp1Xy{5);R>3CH_
zI?f^;wxy@zd&aY>WH1{nOMa-&$Eec5&$kv$ho6uiD>||4V10b5Q)!DtV-d!YrKdwE
z#HHJmr#zU+kDyC%h4w^sZ1H&yReA5;nSYeVA}TqvpzpXc%UL$N`5sw|&vmF|eN}?2
z7a;5L(q;V~+aOWPtk>f68>;dc*M-+BO)F8ILhX%6g!j~?%Ub6A_YRU^;R;(WU1mEj
zZU++tdv&&jfN<*a()^dm_CH&H{D{oO?LnnuExWH}rnxWI(q;Z0dngc@=9bD*R}{Ai
zmHqA%<fXAH*#y0sqIVH-rOR7pn+TL+$!L(A*@Mu1LM-a8uwJmmW%YJOy*+X5%0Htn
zE4@p|D6_0(s~5gkUiJ1wU0&U8U&~AH0YrAC+VA(+f=b*n>sP(qAbC~o!vR5F1Bgww
zKx<kTknO6=%P(C0k@c*o7eeHuk#Eh1?!tZ5e5m^RRFbo^P%rp&r%?Fw2}#c10W0*2
zqf~OTJq)zorfBDr;_Xcje(l)WVtQ{+V{!i5^1OM|J3jKRl8MIQjvDUNZ9+QuxvBsR
zQq<oWc0<hc49VPAkXgG2U7`MOVSi4qA!P0<*aDMT<{cz;!zb<eb-^m>gU0*0)3YQ$
z@z<{C*yT55Al^9#Q-@Zyc8AUyb<}V}7oX1tlC7&Cn?jJSh7d5dyL8Uo@glO(SL%f#
z@9rh_^DOKye=QHY!gQ)0PurfnPb$AOu4B4DJQ+peDPgJ#ektu@{_*1fvv>w#zN;H-
z;6FIu#q!Tw&{2#ay9lvs0Voz+cf=>^rpmt{cW-Y=u)mLgs64RjdBx|8gq1wfl`6h!
zy$}Ih9f0~u)Y+!^oQlVXMV}Pmx5|_eo>kdz@%W5|^wAlJ<T3#oKRyKdAU=gEJ|B09
zk9)9xsCy8LtK@o|E3!sky<8wTJjbsw=gW{^h_9PG(9xrZ4_g->#LMUef4vZ|qXxb4
z4`O+slF>&fyvHi=^VA2y_V63mUC0B-2>Fl)?o39(J4LPTn2e+kimR_$TvS$u;Tm85
zh1In9O>0?bdJtVO$mLz2%K-K}l+^_k9_fTn8^*EtoAT3I(63D&T!3@c;PcZ3{5Q(K
zE)IIZpI9B}=i!a9FAYffQpVd5$y0)3X&|{=aZ@E1$!}Zmn_ohVpG;oTMbUaeQ%`}5
zmXK=$?xpZ@u=;|AJA9au9$|_=sxeqv`1J7m$kK%LjDTMhVfsD^=Kx)%_fe%sF`lh=
z_Ve(U_@Pv|kNt*?7PXtF2$1S8JXEmnj^tOr4s$6|KEwOs0$eNrG3dKCoD=@A?JLLw
z#bU#SO0`UuVNiSt&W_5<Pn@-$E$%yNXfT~nz6m-}Ex~5jy>NYAP4ZV5HsymDVbB?@
zxL#mLeEH_}=hL5$c?c>(>fhq~GTb1@tJ{y4SN)AR`K0nq=jN8+3gnH$eUg`K@i_kG
z=U@;L>LZdV71#LnE&jr)7JdzRI<E8UT7uM8v+(8hM!_?@>WZ(4$tZZX@V@$*7%KCb
z@H3zZ$;QVEW0&D5C~Sz~<x(P1yj*O7k2jSaYKxD9dAWq^_N-Vz7kYYexTh_mF!^{T
zR9)}~46(G5{)KYU4Y4^<WTXQpTvv+=0`YNq;X1!=N1{+)xI@pl;+`{;U%>=%SMc*#
zWRrY(M}ruM{h;!|pgw+7WaL3X-u{#fmX1`gS~?IXpAdRCsD#~m!4`DUsHE7lyl45B
zj%VJYkx|uylxAC8<I{xUU;xrBK}0y)iOK@$3u3V|#ZgBEb@vbT^O28}``{YIGtVC1
z>p(n*VXxyH_;_e8E)4gDxjO$qU$)msrfTL%rMS(W&&BhucwQUN#|Y1>>OB5=(h6TD
z$<9?!)!kYSbeH2^0#$%#z!2z^8^qf?I~|PA%5T&YwnE)qQSTD}9L_s1Vl&t^aaNE|
z;WZP4Twn($bxDs3gzk;nNL4TM<uG25i?+w02(tYo^sJKK^UR-G#>-{MpIXG1MG<-W
z%JF-sNtWn>J<~>1oghyu>dh{^CZ=nudV=J0_y_sAJCaYFOAM&XxB4ICqsXYP5P`pT
zh4Sqvl!d*?A^GA9ubI-b-<FSGR}<{S$5Ib=LH(jy;GxJ@u`{2quvCeANMIm#z7<rE
zBp=yb36AA2*)l2UC9{8C`E2<-uF-xzSA;M5I^g0jG)tX>r}$Mitll<K9AnBBN2%}K
zC=R~f=k?`0fUa=d>k53knFaPmTv3C0eTBLgZKz0BEBHr>|Ic(qc@&2`e7#VxJ&5I9
zBCe~CWhelZZkvnL>Q0*0!#xVi63pwJuUqhw)wj0bt1Lf?4o&GkrLVov&(R-9SFk4u
z&<Cyq{z#wga8>$((0=lL$YHowf-6XuD{k_ANK~0Y!Dz*JS*Wi5r#>Y0i4?fc>%))r
z-N=^s-`)jjr1Ri$Rz!%K5H6)bRaYer!UJ%lVavMUAz%g4;5tG`1K&Vkg(zRv{(b%w
z_7Nx#Y!N4)?!rDCU8nX&y$^(+CE9OK*zb7A`)}5kP}mgC)NhAV>RKoYhuR+l*hM__
zx(mOj@_J->VT#{^?fzq5Gsc-h!FQ=p!BE@r6g&-biAEOB4^}H+qcWc_WG5v!p$*~f
zM9?R-4F$U7b+2Ikda@^V`=R>634sdjKJ!Cmit>iP7AW^{_Yd(4rd|-AKZR)wVlApF
zk83g;RQWI3E`<-_C7*<}w!oiq@C>Bc$?dB&3%zS0%@z3Piv3^EM|8q{RUc7-ztz)E
za)sfVkRL_*xk_B;>yo0jO1k*kRyFnFkY`~?!&Ob3=g-UhRaqpx73#*ro-OzuL^IvI
z-l%@yWhvBK6t408YK%tZz6$b7_9Yt(dq8|5$T`@Z>4?Q=iTk|VLF_l>6aQPm^4k`_
z`FtxJv#G)hMtDt7_9w{s@JK&O_zwXv2UO6BW&Kh3Gh_XIzP+M;va=wcsxL%rEvz+s
zBvgKFEA#nV3rzX@%JZxIrHL2hg;3W(pC!10{8i$<Du3hfck%qCZ)xy4Ey!M04tL@@
zua|=13e%4(B2zC9lxNPk#)l!XckCwV*3GV4?;f~D`iU&?@9(1;$dZ1-3a+DEQF01;
z1C%a3JsN`)*WaMvKyN=!e*A5V=lMAKa=HS)+c15*g?JeA?b^<QI11usU09Nf)Gg$j
zLS;9U7OEro>v)E;lpmI`w3Bf)1yu8WRQA)6&ohxvY%GI&bd79Mz5hV*k)6$A{v@z#
zi93EWze;d{+~};4-{ZJel1<ZxThk%<Jlx+nw$P@X@SE4g7}oaca8`PnzWn`2#Hns)
z!-m5%9KAxPy3-7p13#}6%)ej+sH!9~xsNxN00?tQ`tVnRE2uj~xJlnba?}WAX`?th
z3%0FKlLBxUF0eRB7jqG(Z2*gtdTuhghZG|h^^qWN-<I^?*N(+Y;}u)n<HsB9HIpRN
z+fU{n8dPM+LOK<}AFrdra!UDai0k|u7>#u$p@H7P!8EEQ`OO9S=Lzy_!*4|ZMU&fz
zzE2c?R<NJH#9x7Pja6qeu>Ll@l;jHfG87hH79|o7HqzqbG#28lHj;n5C+c~!x%S`%
z&{-U>GX?gS$R%#>3R8@Bs85(zQf&A<Eli5dU1We&^#BK(orkbgV@a}E8po;652(rl
zf33h4f+!kl16zVs^(OgM;5R>}^_7N6g5>N#Tll7Xl!tt|!5p93J<1m)?nN<K3ZJ3+
zHVQh|h7RuIzGfhA%TzCj@cSqHhjG3%i0npXq_|GcMY~|!f#+iI+fMB{SNs;{G<eyH
ztu3MaR<~LD#wEE4fDS-)LNw&$LYXXT`u{$gC0*Mh7<K)t>W9VZdVn92N7X*G9EA&T
zy2vMzrz)7_iThd}A56xF(EJA3#kb1OkIIrP$TC@wWxOB@H~uT#1j;@6iI4v(S!_o$
zwQ!XLSuowj^pY{*D_Mfv1HBbg2mGgHQPmT#1X)}W2jvk=kz0y95{ENcFtR}NCBds&
zsgJ@-T6Q`3GRO~1D9@<=<ZYSnqmbQqN8H&!Kiuog$H&U42*3HV=gsU%y<Urx;3k|a
zpf2yu;_}M8J?UhZvg)lY^5#O;7{pKV9xFv&RXd_Zg2D|2P#v=Kb?Cj6coMH)ycR>L
z_LRDh#}sv-H@!JSL-4J6X8t`H>7*f7O>Y_UDyln`JBf#PAZiyQV+)$eqd4h)I^uH0
z-<p`74<4^zv&T5NXFQGja&cW7lQQyd=yPhmXqmWKo;&(uUDH-~4{Vs$G2`&OdWjSE
z44%5lsB^@wCF$r#+L1rYFLMtb3;%n~cxl_+z4E_Ugg=XKKhz_A#zbXEqCv=tI~W_W
z@EX@_u>Xu@rMDBWbk*TDE@|oBp`*?xGv9?(TemQraeK}tjysFBJR(i6%hTs`+f7<_
z*e#E&5#jM>?;Y3k6Pn+a8#*N<_wSyghi@ISc$YV*SGlLvIrE?UC08DIu0urlpmXV?
zg69tGxo~Jb<HIzUf2cEsH|vD^Prpt|c`-ihP0H=0T>W=PKG+}Z`5^RMpi^kot6h=i
z-Ztbfx?NS}^GW)CS!Vf}mF&--e`eih&+0VIw*$5J|2Dbha=iT<z~W60(0%%T#j2e5
zIe$!&40G)Kq{f>I!;aLq=&z_<Uq5-H4D}gHujb$hUo@{b+Il2DHDSBq=9g0Y#vlA<
z^!2o!d8M1L^|XEXE<6iwnto-E(2wiKJ&Jzu+o~-m8XaAI+F<>avHRxUNxSTtofV3{
zH1boV*`&dmz@tgE9DG)_I-gi|;qHX@*N>l=bL{nqC8K_C+^SkO@*JHLk*3Y8+Y6rG
zdGL$g#v@g_U%UTU=ltBW+8w*N$emj>oKp4o+8k$FkNiCfla6cMZ@_x5m^mxQ&#6Dz
z%Vcm+hRux0&I1B>E<KgnisL3S`BwWKow9#Vho{fR+C23SZ~h|MW2%9n^kaZx!pR5G
zK9$kN{KVuNxaLAY%CbKu>h_y4%SV3W`jZ9|UbI`=Pj*71)}l{C{9$*K(awuB!@J01
zSL}HmJjbZtb-PN#I%&w3m}J<k_GsG1QMM<~r5eZ0N2Z806Eog%24VfIZ+=d;m);yZ
z>{O6PO3<{niMyYT$`}@!tiU@4bMj}9oIauPf)tzaX30joq&@R%bZT|A<E6!~TMe(+
zz%6Ay3R(-qEz(^4TK|($cKeG<-=j5p_@AD)Jn&cd<pVlTbsv8G%Cdx(`Dl;O;TLHx
zZFjC=<hvIA9iMGE+}ldexBBEc0fX!ZOj@(xX6v3>QxebzWa({oDJFL1;zedpU+<Y0
zT6e|mT#fCMIj8xt)<aEiEjQbU{N2dxd7jytc3)=qclPgm;qvEb_xtfv`+Yf``g_Ck
z3v*tzpS-;>=B`<IdAhEbCpTE_>XG)U&xf{EKUBCm<wk$EWBK8lP1d+SKKdKhwJ|&G
z_1E&&HT51QBpL5oxV`?={yS&gnRLqS(!i{=t*cv2+5QUO5M<%CZ{K2o%jcekW^bE_
znmpcdXL>@7DqUu6dobz1j<e51ZTI6FZ_Hj|j-6Xj>B*S!txxZAHnO|>#P#5*rlSq*
ztDXMo?3E<$wmZk|H6gux3?3g<#bBPF!;R#N$vT%Dwp|J7RolFBkF{&=y*H4(_`-3{
z9m!vKaLxNp9riu5s<!NpGkF!)uh(;3z4XAR<lu_7?`Pjkxqy0xg*SPTwTW%c5|iPZ
z)?Pf77?f)MarKNfgPXmd)ceNT%j-WP-W4nz{_{8A_FCuIYx2~p6{}qS<#mrklbTs(
z^q*h3Vc%I@B}N<ZUe}u9Z4u=VRmCzmre^%5r*=E8$?DA+y1tj;iMv;Pu85l$-fzxv
z>zRBXt+&54?l+3N@Y9$->sGk)+lhPfzkkv_yCvCV?D8wya+jc=%IqL1@3+A?+AOQj
ziy=8Xx(?et^<tv&m4oJD&t1be4Bd5U6~`@N^^5l1FEg^0uiMo2vN(LfaapwTbKJw$
z+PCh7pBQuDoc7{N9Jjg_$>)`?ckNBxmTT<x4D^hgTy3fU9hu9W$FuE^RMZZsle=;U
z)_k!1H6FTc&Rd&dRgU!^Rrf`WPjmb9Xwap_iBG{(K0VCXlvsNj+RZK$p4EcfycQE0
z-X8YIVDwaz%sWqmdo($;V8xm!hb1fPH?t4G_x-HMU*I3Q_S2{L)CwB(RGwh>r?O2C
z-QPF$nep`Ia<NvfYlkF`lVSiR(rg%H-=KN3r}g5UC-^zaCPdCx_HX<7ZI1PfRHJ%b
z8^pZEng&*Wvl>jw>EGn+^aVz`@uwule=eGzD(|(V+w3vftM(1b8Gy2Ogz4{N*rY4I
z@0$&9+N)*Z5f(Yc?o|5iZMyl*D);C-@mbd@O0=8I-!{)Z^*b)Q@aw`F8+V?V<lH4P
z>+OV;P3Nos)^FvZi;rI{<hWJLUuf^aD?9G09=+n?{8cgA+tmvE*m9<Y@_MZqnYVr)
z(RPds?H)_ViiZ}W57`Uv-O%0|{aWvU$*8L9KQ-x@ux+dL*0vdgHE-hEw9KDq?f6fJ
z_f!c8))~J0Ry&`W55jfUq_@e5Inp@D|EOW}ZFrB)>~w1TduyJInP_Q~o^(O$LS2pQ
z-jCL_8hCJ8lQl-wBbsW~K>wb}mp^Uuq`T`jKb$t<r$awCY8Ik9A^Sz!yANt69nAZX
zkYF_tbK)$#-c8-^Xjjk-$f?#S*4r{JKRfXFz?QxCSXAoz?BFN=&#2dWv-)b-Ow(D%
zH|d@I>93j>KR)_$dgDgVN=-)|TsL~j&FjnFC}1lzkt@=CWz#Xq$lImXpi_q0Sq3kk
z58OB7>UpgS`@Vd%yRc?in|A2Gp@SmQT(JH9;d(RPPR|rOyZ7m4nm>5UHQyDF*9P@$
zVUwMdS07`QB}~4%$$9a~oAy+9d_COC?(O37u0G@T-5mDZUYz~=owx?E7&u0;dZYCE
zDi>|ANVA%D&n`zsG)<h@eyI1_4&uAD&UZ?VucG-Vf3sEVq0#NO<NX~A@9E#Ub^l7g
zfB(~fh>qu746`5Kp3%uR^3QX140caxn^J2I=G~Zli8dW#Yd+mvb@R;>*<<eG#A+7x
zj=bAfqslDv$iQC?T|ha1&cbt34jRzs^e<zE?0Q}0n0X_^tEQVark$AGP%pjp*iOnv
zn7ggqi{vZaUp)u%H+qrMAgAuGkPXYzhJ4W;UwPWq{M)J5Iy^lbEKU2{eANuR_G97Y
zMtf|~54qCUZ)AnPG;aJdA?(e_gT4N`{^VIe>peq~+b+PlfwmOhHS>?1hM&l3yr^2O
z%Ew*e1|``%F?%{E>VZv_YoWv5eoV*SO4bhctKRX1<+H8x&)l{Bbyt<QpX1M6KD%S_
zb!+=~KP|ZPQ3rM3FQydUx%zYD8|;=vi489v*lE=6#k*r>x+8TXEc4$f0(+bFdW+B9
z)+T?mCd998)Fh(+HFt-wQR0ERSAI|Wsb+BI;I@z6&DvZ)<s8-l^(24$w%3#mz2Ezb
z$-Hs1q_2&i2IiS9ds<Ip=hfCe2Wzb!Y>)9IOK*6DWpd{VvkWsn)#~^l#`d1e5T^|p
zc|k)wT8G}=rteu3^D|7ohMU(vZ0-MM#kTQU(rUl!wmiFeSD@9Zp)s3(s#*P)`q}Vz
zn1wgjVsWZl?f2&0KI`>QygFswrI74DE_ZL=kZUt{$@D+0Q1^K;`D$I2C%&uj#>(D#
z@VhBBmk-Gw=+b;!jCkdhcQ?D8{peJg<GQi>dAf3Xty^y*#z`7VW=*`36k6e`{<QhA
z>w_ycJhd@w^^Bv~zsls>;#Xf(`(#R&SH53vE&O>y#RTo>g=dl$M;vN4wpm20Zn5Z3
zvUo4r$@7nQn?Ja{PrGSaYxh>IugpC+d19*K_MBE(%d<B>NB^4DyE*<Q`sc2%*}1;z
z#}}@zDp&Vgy{m^#k7Iw1KeQ?8Ndq&~&t|M1pZlqPSekg>6`RP1@9IBDl6hUoa19!m
zGr!8%1Phn`wgzYinO@{+>E54B&FXE+uCyX;#|VGT$k#jct1ewVH6W_Z3Y(oPF;Btz
z8%Gl=Uvg}3TcMMw{lRYMZq9k*n;Ac)V+~1?cYjf{fcmJ%e`f7vLUo<D7qfib``YEK
zS{@uzD?pwn_qqRK)Z30H?dROCiMqv=g|{&Hf%9zF=nat$-XWh1_w=#sIlxw)JE^(H
z{XyrS^*Df+-d9*Zan9*KwjBEGVm*4;UmFyGwm0|Pnjc>|?8u^_XXnLT)IOnw{vQjk
zYR?_=dCxM^uDu(yz$2;lly=A5tty9|i{6~1ZzcC~PUbjI)(%bz*q<@r%&GPlmYsOI
z@af9K`I=96i_Xo?jGP$0PUm$z!uyNm?<i^dz95HJ)7pwF_2x3uf9X>5@*2a`T}LbL
z$$q%M^%6111+jWE=i0%bkGt$%UAoid$eXMSzNzmgw@j<kIOb-RyhFqCw_Zne%JM_2
zqS>xhuFV}JPnI_d-(~Zw;jy|~bGFPm-}sT^s7asaV|-=I`Vpsfex5ufZ^qR3?VUac
zM>!4+a%$HkHms>bqV?hCk?%55uURoYyBSm%n3!l3VYWDB^JsnR_7fhD{&;laoEtND
zOo|N1@9zY=V&%M1L(7X3w&rv_{6_OwPSu!uR!zEbvhGJOzvwl@*UY&qCdbAw`8HqF
zJ~qAbx@Ed{hS#<|5HAop^t#fl&H2`stJi33F};%;-gUBae)D;{`zymvmzrdoMAeaA
z+Fp0i@NI`RVyj0;4pw;buI?lLd&MHnFRODFJl?-0;@SIE4Y%qnIVv8fkvXZOa#I(>
z6%H{=4Wt}*hQ*sT(C)0K+l<dAFKrFTd-iMej{9jLa~-dqYI)DwW$Liu=<jkE)QdEK
zdpq#en{nK>mG!S4*t4dI);^cM`LAl4X}#(kR=ek`SICRXtbANdeCXzTNY88K@*DZr
zT}FM(J@RsX#+pAKWk!r!)BBQqJ@S{u+h<qH70GQb4tkvTG33eZ`lGshoDgf};B?<)
zK*rSmedj`Vty#R*XKjpPHMZ4CIN|VO{$D$)Z4X)CkeeTSaoqK~?d$9OJqh1`X7%ov
zL*t$u&UTx8>vqD{R^t9^JLEoJvrhggVsn*|GaA{B(7?Hyth_xnj}OS7ocH<Ug*%Iz
zrsa%Cem~;#&po~O?CAS(^y8_%uz6<|Ud;QfKhNwP8E)2a)|U}09=h%Oa(jS*NtLZJ
zxntdS-nsz!beX+GXn*cfWu>czqxq%Xx4Mp)HZ|*p)jiYD=apVZv|LqbMk>k&3vcD8
zhz~vOoZfo7|8{uCmZcv$P77~h(ADC}!<C7nxo5G^odZknv!_{l4~AFBssC<z;&7v8
z3B7fEti?GWW83wq(n@bvWGL42Aa0RnkID%dDY*^mC04K9ZCaQ5Yoc0A{B2zKUs{As
zKdja9LB9lib3u>%9rR3^(0AGZPnXk;*3EROx8RudP?=d<D|zV3v>fNxb+R}vi{)FB
zeU)~`S8-d~qRrVS`DQkbwPUN@KT}mwe^o%64qu%1BF}D`QFs~L$)`E3mehOM$g9U`
z>4guD5w&h*UW+@{wsowJG^<-WzO&8JJMToT?3FIh=Ztc!;o#BAc;<!~9*Vr!8Ids^
zB39;UUWmaOCKleX#lx!~+w2=vckJ~ep3(M8KTKZWxv}oUwKqS8rF}A^?~`w5<@|A8
zg*PqZAMLocTRXacmQ6qF$LRx~H`>&0q3f;6O;5eJf%NK=e3eh>ncd1f>K5h9CBMJa
z&FlG<y}zUnK4jJ}CDb{8OZss1+nJu{T+H}=gLVHA51Mre@cht5Cvg6=nR&*uFJxVt
zmf}*^#Si^m=I>ql;_1q%P1bmdKK2}Dz0_s++~C|MeI4UXhI|U1(fnE)j(g1fbwB#c
zUj3)yLsc_+<o4}lHgm1^`)hp<jBGVk5vpA?|BDiH{LEj7Ea%;*FWN7EmWT({db%p^
zT;!bbo4HBOAx*oUnKU{M_V+U;Mn#$qkLv8c?9k)lsVgHN@9Ax_ub=6sRaQ&GJ^mP6
z<=vG7A29Q?g4L%zD*xIiPRpWNMqSUe*em%nE<Efo{(NNAPM>RA=T|(~U7O=Nu>RV$
zz(utOKatga7QC<W%}rxpKCz9RJa*RWli}x|_uSnlrWW2)n^U}FbhBPLxy<%8^IhTV
zX|QDVl%1}knvdL#9N+(%uHSlQBYfk4g_n9~mErOu+kc9h{#;M=W{7J-$nQ(XFBcm)
zYD`J7k6P%=ap#!70h4YVv8Z`{`Kq&N&ktPKk=(JZOWmLT?sT`){ALX&rg*|uoLRi3
z_b2OP{h3H}Q><b`+gY){51sDQwGTHvV&I-ZgB$dIS$RlZ%f|DfcHHE+Q><LNpKhAi
z;&p{z2WYHX_ilgpZC9tA_jq9#Rw1k7s3T)0+(*Bp8w+p6zSgHcc3rg0pkDUd6T6?-
zC0l&Z5;?z4@H_gc`tyM7b?DzSe^Za9g&o~myK`&1O|30mMZcJA+4sm-6cBy()sp79
z6I)?Cqr=i0d*ph~e2)t+m0_>z>`Pe}GA`ldCe8SX?=oX6dM+QKoP&3AEWFIQE$Y;|
zpL|w%Q4uoXOIH`WiLGYTUK9AH-_m{$X785d;#=@6ypxX?c|P`=6!+xTyOI5t&J4TX
z({An7o9lFDbxGK;FrpFcAc6U7v^RdHET!I}=z#D=>u2aJ3qEUIe_E$o{${zGzj%m^
zCu6S+Ygg|*n9`!=!KZCE&9Uum8Z=1r(%9RLQ@2>(P1<z(Y!i<jt*|bNm7~Ku`lPu`
zvu-iN$>GFZsj|ZQ2Z#Pl9sjca-2qcmjMna&f_W}BZk&<!^9x1GWmW(95WeWc++|Z;
zdgdNDVmanTht^|OryaA!xb_`O@9wH6ng-}qnWLkawB)caH(PJ!#G4i|^+KZ_Hoajn
zUV(XwMr=G2<9g)ktm!YaE<8^kDo+{Q^4|Ju_4|k2RcuS&{+QFMeFpC)VXK(8sCwT1
z^bXO5JDu)SIC}SwtdaLd-y1oy@5@ahMeEifgC}s@4i>Luh$2s0VfHfQ`1mSQZJ&2I
z{<!UNSLyYsUqUx`FgFfgfq7A;m*2-6NN}%j+<E7&H97rmT{`uC)GnKLxvQEi3ibGW
z!=($#<s}wgtDcL7)tnHrW7cIIuTM6qnICHg^~lKD9J)AB+U(S!K_@xxBD3dxO?KNK
zP3*cZ$a~gb^VU3f8uz&VD}8tEuIpMHJGw}#GU^v^2TI3@;lrQ1x8C_?Qk!!fy@JlS
z3_5zvBg)%$%@V&4OYZDCf%3ck7xHIxC*aGbH6fkD&9-*fcyi2gw<!b8Ozv~{(iyI*
z)1i&K;O{!CH@MW`gAwZt+dq1Kvf-GlG2VY{QFyeQTJ7b>trwroSgncvfe+L3^YphX
zJu1(CmSlcyX-?mH;@>?Ew{INzXYvNOB>y{;(>T1-WBr^_8MmU&Do3_D(A+%zMD^B_
zb=OR}w5j><h;#e4=^eO`)g1Gu%ns&{`&p8!VSD;|-zt}a{%qm@^5B?u2P=0RvD?2{
zwO%G4R-*sM!c%P1YtD6a4z@XPX^r^F{C#)w``!Pwsb(!R^IaZK4mDbW@v14M_q4<O
z5B?RW+&iKbe01E%9P2+PJ?z`2(V0ujhX*x&bLkP<@+Jo4FRw{(^Ys<q-Zvhd-6W`c
z+!7P<kl0@*xCZUr^g^_A|6t6&<gxt7?EZV8PuC#d_uYH!aUXC;<H72*oJm8Ui57;w
zs~>-I*CK?+(oy<&+L-Bi{MaVVmCK_l&z^p;o^!j1c~9-4F6&j*i(PVZ({GV&Mm@&3
zk@?d<J5a06&_&aZn8*CIVDRu-w?~GAR(4r3yl$7%M|un&?8<TB%-@@gMbiyBf9{|^
z<*8=eTeq|)&S$4SnP+OgVyEBfDXZhqM!#hBT7#_fjsDv8=)&f3xnxq3YhCY4nUf5b
z>>2Rdx66R++TNLHx0s%H4%B)V(Z9jO@J+3f8`v#Qe-zr}wcGJsSDJi?{&ktt4$Q+H
zW_A$v$t55@E-l7DZ}iwVQ}<an+>_ATLVsPal_!0zcXW7z_ICr*-{Y}CFOzm}*)!a&
z;qpX-sr&B-ydAndW!|<OR-ZFg2SuI2>qnMvuM!6)9dp(lv3}JrW2;Q75T25qy7Y~;
ze&eN5+fO;O>FkpA^(f!=rv+D>YdLp;UgbSeJ?}X_oVsOq=&R<R=RERTo)9o&-4^UQ
zVDjB~zm_|7v%`8buk&YQk(*vu-aEB++kK<NNgmBL>NRNj1pN}`?{J>A)#V!|T^oJ*
zn3u6z*(5<%`b_%1Prg&$1dq&ln=nRciLoupoBpu$=G@H38x39^Z)axmJlogd^v^c>
z%O=g8_j#&OZWQK+n7^kZN8UHIRouOBD0Ol5t7*%A>!j28)5lc9p2scvIAu+rg>ux8
z!s}_@yGPd{8TDlgLLXjv8+s<;C^zWDggS=<uQZvyx^Iv_#sSDXk*4<1m{udRzT7&i
zKe*=lJ^IOt7CRdcO<t_qRs1rw@kg4&<WR?mG{w$3dq!;;|9ir@6&0h!_j~Ki+}mgW
ziVD42&QDygtbexw$8BQvlJQ}!q+7kN?#=H0+Sk{iX{!Y<R%=&!+2@7N(rs(9pH`oW
zb(?HlX8uX*kj0jZw)O|we>u2ers>`aEB!04(rCQ>*?>iFa}7V@EX+C-Z|!lPl67`B
zyZ_d7_U#VW+S~np*zom}#*a3SY&)fIV4Z06*Fu<HUfcV|L_P`5x0mYL7@tx&@2|N#
zY15*d)^3@j?Ic#4pp&)CUzbLcbN;@pSUjsw>Z;bF=(OMdifpy(#);+cE(A||cA4_R
zl*yMh{XwOOPo19H{MmQsnvgXvjyp8pUmp|Z+HQT)V$<FIb2;u7>&JHd>zwnnZoTFl
z?fA6CsEkbeeSb=O#ES<<+YB>$uxHDdnH+bLjgNXB9AftVb?_%&E2FW2u|0M6SJ-*9
z+SYzty-%rCoQzIP<hVCbwHOe-{mk}Y9H>w4&M=k$$k}UfN*!>2FjS5;&zw^AobVmy
z?|x4B9`biRXN$OnZxgd`sF9o%aSg?Yxm#HNt&hKMgPVfyf!l*0fMF&as(U7POZ+W-
zgBR-_IF7=p07ezc+<o|~g1_iFN~bL#d^h%A$IJ0+waXl@@J-Ku9k1v+;}yQQ_^;!&
z{myuWZ{hvxcwN6EUb27T8)fVpP|C_h?f<+cr$n{DT>uXQUk0n}U-<skcRwe5Tk5-?
z6TX}D-OmZ%1mZAsW%jOKzMsLoF~!e42cvrCveoQf_$Cf}m!Dp(Xn8vVe|6#iC>Yf>
z_bb>5d>lLwd;&~*5&^<DWH_onoKR>rz_kE!dKC)&3EybJdwe{Dd{FmyQP8^x_k{1C
zl<4o0nm=9sn+)t*4aMWtRf{)D@K;j2>fs6Bt0*yEb@^U>BVHY~c!h5ul&BYUUkdam
zd|RNzc-7?-&h0PJpSpa)nfRsp6V972(Vu#}!ddPmrsIW>4k~BD8R^Vl@peXvcI7Ad
zaRrlIxv8}?!WrY={hV+%_jf%<HY}WJ&Ca?eyMZZk-2rlrT6{ax58MpD?ZJ3$!}SN-
zfgQjY9&t|KRp0?&Red3x70vco6i>e&(o5}*Klo>`LM{Emxy#@EoN#vWcRfdKrEmr?
zTTe&n*TS{706Ax*hvXa#rh0KGSOFfco=*OJ-V)<oBBV1~Nas@Zbn<6?e)n_28MWW_
zoCq=tXT-9#SH<fG^?FG-vz4{m->R2{GgM3Trz$U`U*SwscGhWe{r(AkpsM8_fXRLy
zf!~2u^_4CD7S8x&^*KF{e+B)ZaFjRduT26s0#5-q22TZBgQtO2^|EmG<~QY~ax0vL
ziM=*_{jJ`9Oh9;4Zqc1ol8sDP3tu=Nvc&LJ^-&a_5zcGm=p08%54A@Khq=c{KiS(8
zFomB9Mw+-B@B;8F@D}hJFow9?NAP8EJ{WyCt^(>?S~pt}YzwXg?g7>Y_X1Z14+U2P
z)A^CA`kB%#oYz=jAL{AGaEr<H6in@gdVMXNr&waTRdyi4Gs5|XCHhn8hx`fW4VLOp
zIRCFif9mlH=kals5H{6ANOnPcO#J{=eI=Za$NK4%FY4(hf0QrTU~1P@^*q_PaDE*-
z*RHsIOHfZx{pJex087EJA<hj<@zV3c8FB3FxZ=-aPYrwC1MCXFo?vgVm+-tT{ua(#
zW9P6@`qazEMA!w%9S+7YiJJs&48}THR-aD+lN`1H$DgtEufwtZ4}?SZs1(AX@?E_B
zSOK{yoh!kZs^C@$>0oyJgU=oR!RIoB=h~GZ=K{z@`d<j9u~?LvoFZGcMwIQXFP^?{
zJ?HuZ&yk(Q3C~fzLh-4$bCH6av%$aM{v2=%@LWM&dOqV{J};ap#M;*Hji2&WIOB(n
zU8#SrUOwl;Tu9HTBUyiHA(-r10SIUAaB29P%2!pe3?MhPBLCb>Fs2*0SzvweY%u9*
z4w%N=bHN?K^T9sg1z;97_#}QW0{;$P3|7@A!nrx@3>j)i)#a5}=HvAMH^XzDVAXTN
znKrClC|(a?s!|E>RBy0$4`Y~u=Y%tAn0|{t7Y2V+|BVMX2hR|mv&G-S`7oS_{;pZH
z{#XfrWGAb@xJ7#yn0>4TQ+pc=R>>`#`+_|Wd^qaq-3x!(xV{fedfqQQ=Y+q7^IO=t
zE+jWp#dQbBg+ZTGe~t$a1y2A6fG2|2fWyHEi<<;~2%Zckd2~_93umrybQTMROY&+_
z<qu~8e^js7fJNZWV9M_<VCvs?1(S_*2d990g71KPfhnGT;P+q$aCL;~2(ArAJjzDk
zfnZ~>GuRG11dKAp4F#hw$c+H61&;)80FMSA0ZYKuA+HqN0qh1=g5}^@U{CNOun%|%
z*dH7NR)E)n1Hik%f#Ch%ATXUl6AUK3L;}KjE;ROFdLccaAH`g6A)khUDZht<JA+-o
zqz?%geJ#!vJQa*<%GF>wI1cOuP5`5fu>OfJI2pfDR#?9y80><0L%<{t;!~Z+!i~V+
zluu-*HUK&7*;nd<>w_tOegSs^8-V+O8-NFap>q}<*^_Xd3Oi?o!c(^=Y6qLZj}mML
zjsW)nPXh;nXMo3nsXm+qruvZNL_bV*?g>Zdp-{NixPAxM$&E*QO!a>p7-f@N5AFiq
z1g3B|gAaqZfX{%pg0F+OgP(wRfOEk+!4(naF0dYWH@Go)54asT8Eg*T3+@a)0H%CA
z3=RYz0VjixgUOywfYG<+Qo!gda;L%QBXX%=5%>(a2{;XG3%&&I1-=R%4gLc>6MO?a
z7km>O2fhQ|1-=hH3Vr~th64W>+!p)<Yy^G^_5eQv2Z6CaS~(A#16~P!3zli&d|t2*
zI1lUx&Id<>KZBQnHDJH-;EG`Ah|>mt0apb#MqX3{HwD)K_W}P5b_dr6?*-QZ?+4cd
zr+^!PuYntZ4UnHAFr9CMunNkFaP9{?4}|hty_`^eNbL=5pY^Ly7b!*fy$+1B!^MNC
zo!AT}drAUFfT<pw2R;Bs-HLAzamwGoN5GfB$HBM3Dd1<|(_pf{mVi>2=lcbJlRQv+
z!94Cp+$MP_K9zsr{0(+4M{)m01^>qd|4KY7oQFYWj)h+x*HB)Wy9$3$H+Kz8diVoO
z_I(3PW$q>zWu47Olf9#^REB~df}tz!5%?JRG58i3X=CHOm*856?-iKj-U$fjOtAAO
zNN%eCp-<*;&H<|rFoscfz!jX2q%;R(osZHJjJib`2Ob3`eU1iG_$VW693%xV#&37<
zR<Inb2}OE=YlFSPEx=>I!@#~^FEGth%m&ju1=)Q7I17w2$K+=94u5_GJ6D3_R<C!O
z!>;rpPit@!a9eP9aC>knxC8h+SPZ6m!3a$HPyoW24(zN43Rk`Vav1UJ!Vk*2vL5&-
zn8H5}z5+f8z6-t#egM7-ehR(^eh1C~4}cziuD~hj42fD`iWl{t>g)n`rUAv<9@kNS
zGS^s>x3{KXYR?V9^})@+O~K8<RA09Mn}J({sU2wprhGyjq4Wc{2UFYA0UQk$gVDF(
zP<JR{%bYP7w#u1;e?r{&{2Xg%G3CPA5lo>d=i|B+7;`H$RiMOJfWwjE$^<ZuqE_Aq
z+ky>{Uv~e8y}N;nX<hg}J}HDyWJ|(G2q6?n$a@GOgs7;5-qfTJCW;V32qA<JLfa0p
zV}~{&gb><<ki-tzqUU$5#yReN?)y3S%Q?^IxzA_T$Jc+YHS2AzwPwwl^>RgaC#f<{
z8AuKwlgWYP6_P5(lm#SJgegChRL!NV&wh$3uawMNW=}E?*)Wn}WK=VxTueHU>EuZA
z0Xdp%$OnchQ<R)Tl8q&2kxpbJ$)=**PEyT;@;Et>yh1vY>`P@XB>PU8D=F3ozjwaX
zs~{8gEr|7DPX8$Si>5K_tu@(<>_j#vmy#x=*x#^COXX`y#?jrDJV2U};`_#&tVddq
zres%=&ycJe=}uac{8p6pB(uog<W;f{nN9X1YfxVONzUEK29hk3%#L&?2a{__ds3A5
zF!Cfhg1k#Qkk83c<VVtxWLuJrCE0dl6G<=9nN*N`Hz`+>uH*)C3MtB;c_|-~o@608
zjeJSYAm5SRWGU%OekJ`$P0Di?S(9X&P#TdzWK%Mj<eaB$F3Gu0**wyfRFWQK7%A2d
z%kiyV1evHWL9Cy_^yhs@4f_sh{c!B26zh$$kgh*)45#c%_XctVxsjYg#*#D0E#z*J
zV>~6_A+qhH*gxzb#qmM{S%dQ5O<I$CNO8QGNRA*6knFQ$Nn|v6klaqP4wO$w_GL;9
zmNA87Taf)o4k3Rc{YZ|TmGjATGKxG)GB4Q$@*<f@{zmfIQ5KTdNNvhBn`}znAm!vu
z(wMwW@|l(0A^Ggca>>c$J(4OhWcSHg<OA|J`INjxJ|jPn%tNV9xxXaalCMZJvY6~k
zmXQ6)cjN@}cXBrQo?J(MAlH*0N%8qBBgOH=C-Nlu2gxy!teh0b6%{1E1;mdxr8}uX
zhLcsub)+V_ldMYaBWsdHWF4{%#}jo)ds3J5BlXBNWIgf_$-YH-iEKdLARCeo$VTL6
zvN0*@-7q4>b|#LORrMlB$Dd+5W3ay*FY}18bQ~~`Y)SuxWE(P!6x&@mDfY)pNHIMJ
zsOmhB>Ov6HV|KFs5KRY;ziN;jNwJ^rM2hcSE3zkPO^RWAl499<kz%@HUaGnXWZJZg
z>9YD{CJ+t3os{&Fm62k8pGYxYK2-Gy$Of_=#CYO+jpGlg;j=7#zr0etpCZzRSBlAz
zWC=Ne<g>1vO7dBkj!W2flpE-NPwpT;k>dNMoJ=Mw$Y*2~mY-#jX_7j8KD0=FW5}wJ
z=45rUC#g;LCD~^v=a6+s@wsB#RJ!mvU>~CN;|&{=V*6}OQkJqd<hS*xdTw8Op8wD5
z@e#`-j<fPf@%|r^O~|KYAo+|8BA=6Ddj3#7cQ5_+71R6vIAI6FiRtYm#q<(LIk}g#
zBKMKvcrJ-_CJ&LK{Em>v$fKm#&m1Fbktw8@uNPF$*o$+D()y}NFEI_#WHFqWueh!(
z=6j8llQ+o#lFzns4w*|{Bkz*p_s%^sn7l7uC-cZ}?^E?0z4UzjpWo+C3@7H7N{acN
zB<193QXG$*A-j-gNwMw!LXIOZkYandNLG-Uqz3c-l@#+8!>XQ{m$`~=%J=)v$ufo$
z^IcAMCZovF<SJ53Kbjm*t|2FqYsqiZRXyAO?@o6;!-?tg9VbmUmK4+7Op58okz%@A
zNip4Rq?oQPRL`Kx#BgGH`S+LWCT%$GV{??XC7YA&NNduJ97Xb5Q<=ycG@HbC7!-&`
zGO|$${mD!Zj_^h};*g3Qh-d$`T=*=&9CmPq0#Qgn8gftsEmw{?VFO3_BNA*wvN$pY
z*(idx8_Nb;IKm5&NJ17$p+AM?L);yf8<{AA0Y6#_JlQ9Attu<zhonV~sxlLH@~&hQ
zQW(dIVX|pA=YZXd15Zb~qhQN$*}?3$IAIhn<Gr!*TEHG&2t^#ykb`pQ&t+L*4}U}>
z30WwD_B^)lZnUEuqJj)lIKdy0h(#jOkb@#<cV~Iv3<VNco-Ab3UIqhe$`bB~LJA5X
zo?ozmJ0g*cTxhW)HG?BU5swTML8m9<zzdN`7Tvw*Mhs-VSq_MuNCGmUYs>P%3o%GX
z5e)j!AKr*YGV-C@SClWyg&3rx5c>U?7rYUNbmXBNM*VpW&Im;u(vXL87!BZcI3pBs
zNJAc|JWgf;J7gjs<!~58c_JDaD1|;>Zh3=w9r7V8CtM*ee#avn`6z?IP+o^SB9VY}
z6hYsf?FCK<MFKKW1l?hLPT&Ah_ihxDkcoVV`bkY;2QMfQi)3UXALTIOK+*#C@J2LJ
zkb@#<vokY=9o!L#BxIrh<q*IBoSaxj#3LQ~&>qh+!X665Aq|DloxtY?&JbV1DaeI5
zd1wJA_#+NkD21*w>j#eDx2U-8D}F=B6o_X>R1S`1WkujOruaQ13uRbQ7fvd2Py*da
zOlKbN2jaLtip&mW`1#Beku{m$0@mk3>DWbFKa*J~DL+yi|CQ687{;_{*Q!d{AiJ1h
z8!#{0a}Zje@*xW!u&lhMRgHZfua__8HQKGhnJ-y@QrOY0U7h*B5%#Moi#LozyGaD|
zB^}5#(v{32%VER;lNoG~Lw{#7rcPB^44Hs*6hLbU^C9hOuual#j*y28OLrntK}Ab4
zU4+1d_m)7WppaoR$Q&3fWn9PxRF&Bw2Kk8Nq_;aKyyX-|Arb~xm3a@TDl_HecL|d0
ztI8C^s>(8;&xvq%q`;h$;i)j<OGk+U*o|a(=yGCQfn3;(t}2U%7AMKQkOlWKbaS#i
z0i}rIgt?g$ufb?M(?cQbIe{LH92iWjDsx6W3Si1fb#El26jqa}%0iJ2t;sA4qL2+!
zPPm7o0R3Hg&(L;bIgk$d6y}LM*l<EI4ka*fXFBjl9MX`7GU$6SPdFnHrO@?cd60up
zPU0JQQBKH#{q(A`OxVp}xe<+IWT6E5GnpQo5sEmNvi)U{1<>-Y%F0tW>Jm_wfVu?K
zC7><=bqT0TKwSd=TT6hSI<kri)za(o+lSvXqHZ8juVCm89NTjuR{UL_#k8L_;&%o1
z({C`j1zYj08BV*Xe`qYmV+_NM#W;LxMF0Nyf);p(_YjRK*#>6lh|UmA1zCk@XrY>F
zS_A1ffcC+v?jdxGW!8ry%P|%&XkSgP#d<8GTh!UQk@igxO%dHsv4ifbq^RTYI&R@x
zvy<2QVSs9!1adb@n(_P_zBPO4H=X54B==(u<{}ge5QcCp#d3%yi9CqINXAi!M%0b#
zM7yX5xii{A)RQclE~Ka%x*NKy`i&=NAyCylk#xo+OokiWv7hPQ!{hJXUlQ#$yw(e%
znMO{>OjY+U<b2k@t(<!sjJa+A16X4r{d$l#=!stFOTXTvE&7OV^uxF24D)-9H>zbg
zM~>n3u~^D{#*vZaEy`B>Ex|j;#a-OPedOT*#NVmaYQi;U+8-ewzu_^Spa5d};_vJ}
zgZMj@;%{b(zn}UNuTX?!*4t~c7~=0eh-QSGYm+QXH(23ib57&HiT3fBfTwi7!bI8~
z7~YwjgvoG$D@4;x&U&NW0+uLXoSJZ>eF~=H8Qt!r6~lUvo|pzN%z$Wivut~?k@E4T
zpAVvFuPx`g0O~>)dZ>r`&_@F-WxRFxf%b+lKqDBUF^nL#yC!5)G=m(?v7Yga$rdm{
zOSFP$j`EuL8;Zw~ijz2n(>Q~4oW(i(f()F;1zbcX#NUAwpGEO^gfBz<eNORrLa*W)
zvT+?Za1-KhZ-_>#9`7F`C<g~bP!|5=YLRlTq0wFiTDVL3uE#9e0}zN6VtVx3%0BKE
z?$iDN51|mlFpVH`Hi8j?IS@^doO|LK?hC%+I$|-G*XJP=x9Prv`LqW!`~q?zlnBEj
zh{l)n!zz}00QrvP`W>YZfA>f<L+C#g_E^Ml1Ia<K!(fEb?<L!DciQLD{%wC(kI!#?
z)o0m?X^GFQ5@C4BIi-GNIF?{3A~68V5rviL$9Vm*iuTo5gSA+P7_7%eh^D8U^29d8
zV<&nc0ei6@NjQunIELdmfi#?kXa@5h95D>D&>P}2qk}rAVA(C@Y~QpugaHiEm41y$
zBQ!x%G=m(?VT=|qK}(3HyPSP2?Ph3?j<BX*C$bAH&=uX#9oDcxPxM9~h-MJWDE1L{
z7y>=Ihst>mv=7HfjKVPbIg(>A7USTAiI@yGOoa!$AevEfKJ&EuVHSemNWTzr9_Awq
z;fTOeEXPVjV=YAE%QD$v6znksW8eUP3}gElj&Rz;$q1~YJpexNgQzoJm(Pp%o1OFM
zZjY`IpD*zl*n(|nL_cpi>z?-A*o%GGj{^|j*N4c%NXAhdLkfPv3HUO88hILL@H5hJ
z7QY|^7m$f>%|N#IK}gkSf66j+M+dfFOXjCdil!qewoCDSCARlL7>uWER|<v?#sHW@
zY*S*tEVhXrut5RC_2IRC5bM(cVttIoI6UX|Kwg`TAcP<WODNB!5c}~+axvD@e<V2y
zqp^f;QIE9v+iaq)>kkb35oP#<KkymiZ?t{ES5!d8d^J!7n$SX3R6})WLo|-eL##tl
zwqhR_j5(Nx7cBP_=06!%DARfjTOaypfJQJxV;G?cnxYxxXbxkvfC*aSD$}`!*0i@l
zTeO22I=~#A&>5nc#JsDp?!@|<%(-yUXwh8_?c{84=zxy+jpZH3@b2(}CuYC{t$E!P
zZO|6^4BLt9j4rUi6Z#EhSZ}0K<||l+4Ybch6zwaq3bAyrCTlQGO^BwJoc$3*6U}S=
zSYQ1~@c`dQOviXkmb2{iuMTZIrYth(SA+JNsD&r=(;;2xUz@Chy3mClL^GCYDOt~9
zScJt0M+BBYe8)#(8D_Bkd&3vY=@#GZ;`=TNE3pczahvjuCf8ss#4$n)#CQG%Y(y+J
zK{VgiWj4#(hUHntvMtAY+Sib4u?{iVOusm6!6qz34~X}kiOYCL`A;FUa0S<J9qzb^
z9Nfko+{Jx7z;AerCwLCgjF)pfhBtVNcbJG$e85M1!XNmIFQ|Y9??n?;AsVq?tIKjZ
zv#jfRA6v<7=#2gl(-iATETadep^)LH@!C{4VGg$AI@@d(>)-~towDA6Z_OUs_kGu$
zO#89#x=+%6M%8_u%v7~sCa<X4>#$zyLNwRum!s-`m%OiPe@s4AwQH~}n)ue}&|deu
z?z$|esQ>6&vzhh&k#YY}jW7Cdp`SkEH27}34V2SH?B%sY?1yM#>9+|DnC1`PO;?X)
zuCH2dL;5%V?zLvL%T?VCm~X@H=G}#MOI3G6#y3z+qZ|FYtNITh?Nsf<Ne5NCBRNLZ
zKAv<|wND{ERP9xmo|bBwV)+-+KV0=%b^2?oUh}4(ud2ToPC<LHs=F4$)K(3*f__n|
z{?X(nRlE2tEPls|-(TYQw8-IXL*n;}_`McICQ=69+ei0)96%BdLNr{Olb+GFCGFvi
zP$Z)a+8V4cxFZSqC_y=FtFTW&6yji~$vy<!cO%O{He_0S|G^#Np3)R#AO{5~g=;m|
zH4>4EOgPkH+K5IRa$umtJ{cD14+kh99?s1~E(%cwt=jDWkc3ib)u9^>h({7qVNjQS
zKVp!8BG^)Xk%$%L2=UuqtcMijqXgy9rVRDr1TTaj60s0vFODI^cS|Btk%4UF!_|Q0
zKr+&x+lcKJp-6yuU{n`!n8Skamq^4y+)!_i6l5S9`6!1D-y;TaM=X+203-HGX0SpA
zboq?QVTQ8imEWi0x48ICAbtnwv|u_gfi3Le1a~MAhh(H76FDe>g9&8_vz8p|ARNgk
zgLW&*3v!sl9?l3A-K`lOc5sA0LJ^4=BqI%(D1dm_KnJGi4<{%f9$<_^Dl(9da%i{V
zy}%as@PbY|jt7wqFEhr6xB)8;iAX^@@=yk?_AEPWU<XIIA{3>F>cF_L=*WCv4=*Sn
zZb*zmA~KMVa%h`VCXmAhDX{NExxfn{h(#h&kppp)RTN^8fOKRb7X^@Y;l05C7I1(w
zLJ)&QWFQ+w(6(S1U=DjYL4jx_!LBRs4_e(=KBOZHxhREr&`$>juz)S>;e~KSBMF(v
zLm9NX^PXV?JGeuMC?p~S`4A5@n%gi<*ux242tf=IkOupnyasoOn?9ouiv*-24}~ZN
ze_%_d0|QvV0p18fIHHjR@7}B<=-9Gek%$yzBM*frg>E0VcUZv@{s=`RVvr1ZUlQra
zMImJUc<*q67c!ySpJ8DJ8`#4O3MdhS1f(Mi;vOQ|0G1I3NEygFg}6sZdl2gtCa{1L
zN>C1MJNm;MHn4*`#0|1hh(!vrk%vN*LU%A_1fwA=BQlVUJc#>>w1zSaj9>*v_#+Cj
z5ce4+BMY|nlm!Y=4ufG#6E+a{7db=RV-$*bSPkd14hMK61mTEA62$#Q1(1!PJYWD5
z*h1V}WbeQ<Q3}~ehJh(8U<-SAAsq2YLnd;Nk8=2rqU=U9ZJ5Cdc5p%{^c`7$FoPW&
z;R<g=A_3{hLm^5b8$)>^8m42JCbE%-LTHVnOko65^oJ`#5sL&QBMrH*ccL6n3UM!#
z5v(BYhjK+Iq7jc|q@w_3(4N3NAnuW}hbz1h3i0>c(vXb;l%O0s6PX8Wk&6P9K>RH>
zQ&^!t9N>*e#3BJHNJkzDQ3_F+k`b(64=1?8A5qAfOt%Z41tcH?IVgjUE9DObLXd?#
z6rvO|H->>6HgJSDl!!qhQjm@;<f9z=Q+O}1fgK#-3I(E(h;-zj2(qcn1Lm-SJ)Gc$
zNW>ro8OTQw%An=Wbm5H<gd-YBNJSP3Q4RwSwr|+N0p18f401i$uBTD%aDX$spn!O|
zDF(^NL_W%p<;8d?KnZlF^PXXa{&0jVLJ^BZq#y&?C_)*uX0W}&40dpa7ZeZ=jKo3P
zoArVsX!%e!a7HrHk%e3opakVG@TELq2Umn38i`0p7IIMlnIFT$1m>`T6Z{d5G-M(d
z<uLN+y}}B1a77$)AfLrF;EhD2A`>|%fK~wWf;sG<6G%5qU<-RV!5!kp_&B5@2l*&M
z8T1wOLu?T9K{{M#Ghc)t9MMQZCUTIEB3J}7FWAEi3W$dr<B*CRltC+m_X8U^z!@P3
zM?8|@J%{%&mokAVEZ_idgdh@0NJR#6Pylg{uqo`|jYz~H5vj;T5yC@xABaOLGLVft
zltF(!WeIyY!5!lM$SBAbP(Db6?Lvlu6BJM)3b9B*Hj1FFWSWq}40cF^V;Iwh0trY%
z77C%Yh;;}vSfM{0;0`5Xk&H~_qZCGqDOcFTA2~1yXFRwfG=h1c5M@YNLb*YADa(dZ
zm_$<ENI(t>V6}{OiV&2+b~)2T0rXce4!jVHM3GUv59C3ACCd&4!jXY8n5<$x2wlTC
z$U_mzAzw?`ARIABKpyPYQND;n60~AicGx2UDM&{)yw}r>0+d3&iDf`I(l@gVFxkQ~
zpa>>$v?FsnpLfXP*#?jctsT4%WI%f->jeo(yoN%U9HP9TMBEYPk9?#aV_J}<Fl~4t
z1h&UXM55p))>$gAAq4hmyk{i9^)%}XS<pH|Il>>}A>m{cq71ThK1c9|;w<AL1zP8r
zFZ#m)&hUZ)N<<+R2}nj7GLeIPWdFjXGf3#3XIsR;`jzLElIvAo6A;&p?TtAnMH<OD
z4@-uTLwMbWv>;cJ+jT3ilUAi$oR=R;hBfEBG1C+0^DOC3Vz@J;7HLn4YYT@+ONQ4W
z#ksAoOkZ4cOQYL@;bze-t{aK-EaLp7IA0>pQ+A@i_#L^QtiyC_GyEM=T&we;|8Dw=
zYpG-DFQ(^9_h9-@qI)qZ&ZX4ANTzp<`COpCIG0+D6xa6j=`YR`?qHa4WOe#CVYr)2
zM_fPoiSD*^i*q>B$OQTqFy0qZTpzqfitDdNyndP2Z!o-!tVOptKRJr-add}~@#IZX
zT!ZLC7Bc=$#uwL)N7F6m_4=f^Zc$GEU+8~?ZgK55LiIlS(cP8Tb4V@vSEawWKjIU^
z|G@Z;^cU;Tg>FAySJFL?Zd-CN`3L>QeEQSfl<CxAImNltvviB|&IWXg^T1>17Vl4-
z#}els#ks6cjF&|Jj^rS^?~teI7U%x!kPjKJjOmMO-7i?KJ>)_98_<6=!;AG$pA_Xi
zf_%&P{m2G%KNr(sxC+K^PX9fmxE{SojL+-mNU=TjB}Ms<BgOVtg&a=qVt7%WN9h*V
zraIE?K>r<dFJ(M!Qe4};PKxczjT}w>pjw^=sys~p_KdG?)Fq%U0d)zeOF&%$>Jm_w
zfVu?KC7><=bqT0T;2&E8T1;++OoLx*oD;Kl_6v0On=-@M&Bwi~g=c_=v(I$jnH~YY
z9^TGV0~CSILHzF=7%<h@&EH?NPWM&ts++fSh>t>yC`OUSb@mHV_y;N6J*EUr3seM5
z_nqd}f!DczPG+O0;mU7wYFaat75HoaC5KI)8sHb`=c$mJj%p(x;jftPGkq>2%KQ2G
z_)qut2$0p2ndrH=%%1AvreKm&f)pNs)c<Ls=jGw;?-B5QU(PSk-%a7oJj6IGt4pB5
zP2u6<<L2u&&BMpTS5Y}kpu(NUmQD1=P4{*83l5akp?#oVkgvO&V!EGi<uHBv4*omC
z*y|nC=eMy;S1L!-Dxx%{`uAi_$XyWEXLYaEl4)>iz{O20&j_i6`il}8EtOCoF-}ui
zJzWRU@;8k}SZDgxlv(Q;ki#{qP#$`E=Cq67*26Uv9wEG^ALu7W-NgTu{aga4&-IY{
zYtw&LwZHTap6*`RpVI=e78tHE)z5dfM}We^opR`|cd&AKW!6Ug&Zk668AiJ?_uw;a
zx#mCaZ{>LO6VrQbnz+xSbn@qh7HuA+?poX<|5Q|?#JR`DEZW<tSJ;tt+1yh|3CT6B
zDps606Z*&2Ic{c02bEWJ3w@c;VVq}n#5`qCqES$69_K8i={2v{<fmV)s=c3gvu_>Q
zo^_^EJNBsa#nNYWt+uUABJMBW%lU|&VtQUTIG=i`i)qKB9+7p!Jm3A8=XzystNR`%
z4!cu^^)KeVR!H;R*rZYQf!!~6tv@uS`s~Xc!$L=2&Yq-LF>2uIag92k${Ngl@4dwI
zmY$tj^XK^)ujhok%ebFZYVaZLll_T-kAp7<I0V<q=}Q^f*@)p{+SgLPns4Cy!m_-u
zn*Eh4FRce3+mfaEew6l4zbr7_$hrHG(tNXL=|2A$ySeyd@tyfDP9u6ftNZS%Q<`D7
zVg3ya4N~^Fb6!h&znWv_R%qUCb|5VwbN3;WeQ(_Cn}70+7&6Uz$<2N~){8kux=)(k
zVuR|Q!Jl`|E{J*k%jW%Oo1NZr!D#2rna5Y;W!-Qsdcn1Y*8Rou88_J)a5_nUxcBBZ
zR}yQjKDztk?ew$D&%B+mZqmi(ZFGv*CWeXOY?j_%^(yaiW4%3THTvIr^t8^E6_>Po
z^q%P9*t+S$S{EB|?yHd)t{}v1cH5yNcY4Jw-!x~r;R3HNV*>MSA{ID~3`kyoKC=zy
z$)x4m;(L1GPschwe>v0UxnF3j*D;=pj7;1<&+?yp?s1HFb!R>U((;YkdUaODhCB0g
zhej;*_Q<{ctjXNh?Y9keKdYg?=F3<=HtGf4#C$`0du)$A_ExdH)6m;}syX%4a9`IY
zzt0xW7VSp3A1j-v!@ZEK6uD+%{s);+$WZIMUsLSe?#^^NALyA8xY#W5=*vm@PQfYu
zoR{h<hBHdZp4)s?hRqzyluk$72A0?D*(RsQ^|f!?jIY{cO2*1@lpph!Yp#83@I~o<
zzhdH$({%^<U5MHk@blD-BYQ2HIzIj8hTW#+oTD5dhFjnMa?{8Ut%r?xx&M@1cRiol
z3zp9sZ9j7U)>U`g4%Aw>n|q6;_uKM%-1bdt*H}J(dn_urVeI`<jYA7$4lB1?kF&V9
z(Q*&#caO9^M_F!dU$JbMqhGJ9H@?P9eUz|hXvKxhi%qYrE-vY?;81h!N0z4d_x}ca
zb7?yr^!vuP_4J<XPU?JQ^&!JW!;+Wg%|Aco`luIK2e!0Xc&LPP$kOyWbZ9+t;@5#D
zmhX+_#!nCDh3~FgqxaH-kLRZzzVuRV_7mrlrR^o|%;i<pp3Ruk_QDazPJJFcb3Jjs
z#bgtEoeMQD-At0*pUQrdeWhIUvtmwk4WlUE;khZ-QtDhEe(+|{paxy557@T#;YTC)
z*A<*=?IDH>Rn&Xr(DC@o?m8Rp{90CZ=T1G>E$dUiq$sM|eq44p<0{uJr0FeKW8KBJ
zcwLwAd$(OXpBR|g_4Ag9tz%k#oNt%A?Z(c}%r{ngAAT$M-S^rtV$gy`wW`**(fI9v
zlk;0z<qum~z3GspeO)^3;ry(%m~ZRo;n6j$6mj(uu0QW{_?CO4<>Ph^GCBL;ruR*A
zW0Oa%IJYb<-)HMXZ#oa1B)eL3#%~R)<o$B?p~oLJbuaBt=`wTU&4Z=uxQ|)d4wA}#
z8RM(4elhs<*y6)|osKTLme~2`iLU0;j*Q<m?#Oknv#gQ!FWL_(B8rr6+cog&cIxVg
z4Kd2E@lV=n-+LH(cE;7q+H0?Ku6CwazQvozrj@T=rx8+7M_E6rPeIc@jjw3@*!+)H
zzn)tB<FkiHdG<zHzn#Y&T>jq1sm7UMlN!FR`(?%80Zn?hKKn(n@XM3@y@?GL^Ig(g
zOt1T@(z4cbo8EUSFq*umOJUw~#Q@`zt75lC4_~**u%-Pht|N38!v);YwGR&;s1-Q+
zxySB4zbV@d(7m{KaK!Vw8_l&!T|07}$IVg<*EG<+NvoF68znf-^&R0pH*%$NnAz9&
z#nus-of`FR68DyCC(`HlMU(l(!;CM5uj-_maNec!Z);X&dJJ0EZ`q8Z&BsR<kL0tK
zCY9gkkoh-#KDHd`@S|2Y&ydK4ea>g!Kd4*Yvig8t^IrC?q2yYLG~B^y#|(R{x%%_!
zx_gq(&Ufq``QrWDjJ;QC|1xyb$!kwvujZa*X}Dm!F`IfEsT~u0ZRO^;L+$kgKASG-
zro62mQF!m-1hX0LT>F&XN9>bs@=rypALeQwh<U4*+GSF$onMRx?ml?H`hZ#f7|pw!
z6PJdQZ=3Vw)Ug_~6m`ZQz1QA*$>Y#ETeI60$E7t7^gC_R>LAxUr0sN3hlg9A&6sCp
zlbv)`>uN)dBD;dEZAP6~Y`nEo?XVV_b-C^$4QJP4N}hHV%~{1d&9+asiZ3q;NFQZ7
z=vcREeP5pV;`f#P)lCi*<eH;wgQxEOIQsSv9`fEFgRV8&-rnKJ$)^23UA4FFHuK(s
zA9-$0dcWn1_sxH>W8ag-b8DWg->hYj?%bl+W)B|MOFB{ZY4`5#^Z4G9_G?Z{ES9G4
z)w@*l_j=bp7gSu>vu9eh7S1PjOkQ{Q_J()<Y*XU-QMqP`O^>8b(<kbWK5wG^!syMb
zQO6^4u4q*`Uh%ol)vX)awdcCVP%+%!|67>rr1$$Er7R(3@3Gn=-j46y=l$9_uHLhc
z-*tLrZ(ejUFTTn4>Z}iG|MK_uYo&Zw%QgT0-vT}*P4D?1r44`2e)Q<e$gmz)CYlsI
zy&uujHuAU2KNuZdXqKVRwc8wN`4Vk9Zm;)zU#)$2Gu)rbKF`zX)+p`6@wzpZc8v^Z
zeDW&$gICh@rYJ{`9DJeijIl@F);QC(nMsbt-aT1omo?SPZacH5vS1X~zy^us`}@N+
z8ZL&LyhdqM-0(=yu8mn^E41fSUz}5ZKl4_{=cg2IS$}lh9Km%KX?mqGp1TZ!ZVvHv
zuJXG^ZsWNj@0?Ez`u+B^m$TX)8=GRbit9<XVtTi_e(pK`Y;p57I{MYqC&rIXvUz6t
ze0lU^n;N%*o!)=W=K81feL1vtkF!=U53Kz4f$h&nYP|oNaQVii!)tF_+kdFJD(`b0
z_K}S(#Plv3F8A2gXG65P$+gtvPVHZRIAf{ntQ%%k{=q-M&T`Ouo*Nk`hC6<!p8L2*
zb`@QsW-oPn+xdAwndOG(jWm*T+IpYR-!jIYXK1AN5gKNd(yPi+ll(9GJs!u|KAbq#
zVOM@x;8@SL!S@duOygMCQkrkmeLJ7D^?Mh4aE_Ln&P83*OZ$!lbl*HKZePuMwHq52
zG2AI>dMmoE&79KUW7mFP^@b(pEZlKDsOZj({vDdi+O1d@ey2P8J}+tc^m9BCKU8_w
z-QID`hlTYvjx8TGvDLvi^G!ED-0gSivqN>RrAhneaAmmuy?0@=U7ETqop&=SxJr(}
z;+5NXDylX;zb9l%#A%)zm6mV6uc5rbxs2W=J{9*?*WXojw|30xUz65`ooqR?Wmubj
z+c}<;=6kJ=M|pa`m18=1w_mKa?Z;Y%%F@dV=4JZdU*6`$#-e?%xV|mzcZ>bH7+k)+
zHF;;P&#zres@L}2a%4cA0cU=jb8>I=vnH18pDm^R_=+!vAz9|fZ`wpY`C#}s$=&N}
zzH8v9;*~XK?(Q~mn5_}tgHpM8WMxnPYGK)EZ&9__tiu!hG$Y?0HmJ3J%c5D)?P6_`
zH*ssTbi8qTclGNdI@ng}X<>h&-{rf@-}w|KEbLL&C29IFdCOUb?8oa%-<P{<*Li>K
zh0oL>eTp}4RK)4e@+kB0e)M|M`yS`)m*20)KEqX--fG2T$7QZDyCR2A5Bg$qY_Qe9
zk+vSC^ILg78hz#EfYg`l*QDdb<rnVkKlyc{^<<~tclig{-aUSAWkU6kv^C={Ma5s!
zKC8v?pESK%0}p#dz0A+L^<nfX&!h$m+n<@*y?V&yn0-kG-95Y<Q@E}yeGkr`^;7=H
zU(a{Ay5a2e)z3GbD%X5|RDO9`VdT8f9d+I&FumWU^*hNe`*`5+lEr4`)$C-2*^PVG
zyRp?I^T_Gy$BLf()OMXY&r?bJzv5db0zV(=Q*u48ciOubSA8-+E-=mdp?Tch8f7P)
z$`9OTHz}<Tt*VwsHoLYO?(%G7v(O_pKbxFsc%XRy@+-{?MogOjb)_-SoJhwJ7wXhs
zu&^v*(Z>!BUlq|K#sxaGH{Kr7VtAtUsaBC63J-DpUMlA)MpZ^7CUy$5T${0PvVnDn
zxlbp5K0R-F?vlgvBWINlb6~rYKEKVHT3wrapt$d;cbaF4YsEe6Zro4i-v9KC*Mr9T
zSUUDC<Gg^heEY6xp9!zNV}ouVlUoNLo3D}&A9S;2yDM#P)UMmSTX@eYJZsZHe17k~
z%AQ(c((}4;QJ3f++^!#LIC}iSQySZAhq;`n^6W#y0`AL@-bclj;#E(7+8_4v<L0IZ
z>a06$K3k)3eh=l|-X^ib<JKFwaUX#+-xs6$T$(l|;_JEV2WFMM{5j_EqpYA6BXZ80
zKAb*rk<)mNcV%{BzQ4R5Rq}4O?BFKDoYZ4mjkS(X98z9V&r++TS4e|_B_*tj>eA=q
zTH=!_J}33OHf_u;zddo%=hCz{EAzMBDJTq^z18lz$4=I-G~dBTOk-2pT^s$h>~qkw
z`-YQxf1bO&`*4RxT}I|F8a8AFW!F}kuk|IHPTMsO>hC@~{PoJ;59=HXS~a}1eEYT8
zw;Ogatn<fw?q`wqr!!8@etD{B%7T0McOPhDK5SdZ(pOt|czg-lSHn4?ne7A(uG>qW
zx943GW|c1}`+Dwb-r5#f#S>CKPWW1X;PhjMhkTy=bde9+yrVR|xQ{P>`}IfXP|K!E
zD<;G~nR2}1{z#)PH4em;&YY5b?<&hD>Rgm-hG~E8U1O80#)z)hkKXG$Vez6Dx!oUH
z1iz~GHq3N$wTMhUAJX(TeF^(Cu#dz0=~I6>b$I{!Pdyfg8XNWP_Uy@~#L2Rk+bO%@
z())e+{Dt1*@l}cqKZGZa@6>X)T^(<0^Wx9j+YheMM(;>uFwcWCZ@K1x>bvtZN}DuF
ztlgmB;@*Z^qg&7WWp@9@twX|3Y4vzKbT`k;>WSe_OiP+OWbw#p6E8H|v1DSSRcEZn
zxm%ib_XysURqXiohZo$#Agwp!<JFQAYD`(*y4|H`<(4)h8f@2j^lL2_!_BkWb*yms
zk#%<0QcN#jcJ6s`n{|!eH1is8!R_j&5n=lG3U9@qF>AZs+wDcaZ0?<q-fz@d{i011
zUoD?BqV90dHl3I3itzL=+a3`a*D-8Unda3v?){La=d^Zw?KAs)q8rY<oi;7Te*LEf
ztETN~_+;DN&mmb~EDLILPmT0Be_B@MooPbB;d@85V}`x38EXABd(^9Dd)u#ey;r@(
z`PaF;U+Flk`guLedxfW`L_5k-K3?zV_3Gx2jkCv`v>cid>{z}(dpyrnN#(r!TK>gd
z*25+|ZrOX*v`_8o1gw0yq^$F@t1oUX&Y0M6qA$n0(r_QL*M=(>8E>5?|2)vidi})l
zD-@;1Lq;TY8T&;M(dt$^?gNpA>wmiOj|R`pPu9vGP&#Cg<&tgMA8!pwb#AlBKUlk7
zd4-bun55x?+>1X<s?dH@-^F~i{`1Z8mm`<Y*(aOt7}TQguk$Czv;Eb#66HL+;D@6(
zh7Y)Q{-*QOV|HDR54HHRx%>K1&pTske7KqVDS+<}X@5GP`p<*owYur#H=LHW{bqT@
z)h8Y2T#1ZM_P%vsWz`e?wYf(`Iu5%Pu%^M7XYLJODvnpbyLaZBXSUlH%v}2RT<Dco
z1CI`l)8{^-u42A3bYGM>OkCz;=@aWS&1l`0g~_h+dIeKEjrjO;wn5t^&A5M1nqFq!
zW|NI+hiXQLztWSx8|%6|=;Hc08_kVIXe`XIk6!J_eL~W3Bj@L)b*p!K<K|0QuTrlb
zPU&Gbv0=?WdOqm6vSrhG8PnKS9HsgG{o_Q#A!7OVZuj41wsiZ&apB&aFANVGb!_yQ
zCU$SCk8NnxJSzI|UFtlLK9^H3v`B3Iw#v^VH8$_~@KgVTIg77&zBUP|@}kG2v>9_B
zaa__*nqKVjw&y?hU9-WcQPKOeN1ydc>GnxW?)Y}M@98hKU(G7o!S4WRxJ9S4LQWrO
z(5r2qy=|>r<&C@SKVIM?pA~bdWL>M$d2RSTQ%8Eg+tY3ruk^h7Mj7(<hvOMLf@beN
zw^uV^-iN~NRi|y7pj^)Lqtf&WSG4{?|53^%<u(7HxfOjU_L<ivqQTaHcSF|?eZ1_b
zODXsMNz*&`bj`G<zVqXs-TUA?bp4W$M+5t8J8*YLou$2Z?^+$!jO}2zG+eVE6PCDV
zG+GlgD|F4yh&me-m#hsJ_q^w4S-P*n)4cNn?w69jS06rJ*t*_{=Vp7C+uB(Kj@G<B
z^M3Qp{nihX_TIl_>^Yzf_lilMqf>_mXH8se-8#Zy_}K?;$|^e_pZqOz&KtuABNt_K
z+ID0i=eeZcjS*S(U;CSGsCDO4=$cO}HY}PrurxKzYR2o1ZD(xBI%CW4+7HtEJzDE*
zi&=U#me=v0zwVTeY?<DYd3U?TH42V?(jvFp9DmMRG?RX(#JQ&BEDeA2;_9pHaUL0C
zOdsyNWjHM4f&anmLr-N|4SubBW|H$3wXWD-I4r-K*E6rm=?8aSI6s{H(Ajy&o4s=X
zwrzvP%;i~kX}&IF{mZodE#CyC&#AG<_EpF9r)KG{Znqaz1n=wEwR31J&m&6Za&boL
z?x}{IdnF&)T0HdL_46Mm9kFR&y4iS5u;<s@iM{z;UYDlVX5bp9dUJygFTGL6>x)fh
z;pcjR1M*+&3tpS(*7E$x(dW2VPTHQ28y~elo!ECr;Pj=xM{RxOF#D-tiNRFuzB^i<
zIlV@!I{TOD!^QS|cKrBPQ`;uLo8Rto53j&0rh%t#c}7pS-MY^A)4IGPXZiddYAlB9
zlsBtl@7ADRp_T_a?m0JO<CKLXe_b&6!S!EdwH!|FIl^$arTvC1Q*k0}he?NmSLd3}
zcrj!8o&Elv?HB31`F!Bo%ZM$S93OZ~<@_r9{U*=qD_<scy|uo0NR;_S&r=<mNB)+w
zYf6$|-hwO{_YX?PIg|45MPE`nw@Gc)HT!JswhMH(F1)_C)%dW>#}DeIUVYJu^QY2w
zuyS^Nmr@Pe3%7^VxE}ahYri)qX0$(1y~l*3el2wdb@{Z3<3DM7{s;A1$$B^{Y*Mdp
zHGj79cwYI?M?bgF)VJ(<#Piw7X6tyS*+RVE3&U4_@~gV=VVaiW^lay1>)+--8PcxV
zuh%z@4{ZMKdI8_%#ztbeGGj%nomJmI>O8r~IIw^Gx-RBpxBooXHSov1ujR=<jXBJ{
zdeZtR?0+%9yKkV+$NmG3O&yu1@pwyC@%(Ww<*S1~7$%%MvWDqN@8j?PPVOv~^PHK+
zt&|(1t1k;b(a5oVSk&`A(KqyJ>1|(kZtpLV?Iu0t_n<VK!KG1JKa5+mIIU}3%~fN@
z>)&?{3a&nJ-S~#RFQg3^KgN}NilyP+<*x}h>h-mw!NTX7@$aW(J#)OY=vkCS*Vts=
z3k$cz^Bw(0+OIWvai!VsM+&a)3-xfBpXAzb`t`#3M(d7^eCyMDWKo0Zg?w*G<(xc9
z>qFSECi6n~wn=HyXKi*tu<_d|=|^rFe~S5egTrCY!<~}0gOD#1XC=gE#Tn^Mp80Ok
zaqFhXcH4C`*fD6+IUno89pCZ&yGts+r!xcJBpuy<Z2Xj_8xxHd{q$(o`*DXdq7EMJ
z{xyF~VDx#O$(7byN#dxaGmg3wc5ZGwv&P~op&3P)>)%-$G+*y#`=xkU0>kWVB-Yzc
zS&FJFtX8bjt9~qc;KLD57VSS8T+-_6@&ezDyJto0*v~zj((>hg+$KAJx8qJruPeX0
zNA7)F{l`TO%#KeoPx5S~(Wr^(GmcB7;ZBuVcfXO_rEjx}&t>^XmBzbu-CnwV99-^D
zHrKN-YA?T0O!;lg=gq(=yOnIo(>+Ed>Fq7Myeje;exbgN!G`%OqP{NbR2t3sA!)eh
z&d!faZ2ccxJ(;<-c23rYUwYPQ{^fI~$-wk(gB@OkFXeO8R7`K6z1@JmWAhE&R|P-0
z`9Ap9-KS-v&(8hfRKQK+@GV0E{rDZgx|3^apN?ze{G#ICC4({bb{;cG@o$~nd|b*}
z-M;2;GMj%E=P+gLW8|9Vj&+Vr+CS&w?#r=NW6U4f)mif6;Gbfv3^HArxKnBPpb7WY
zO502Rr)@6%8ugvp^1;tTe1^AZv+DI0?P_lZzxG~#aBI=?+KagFRQg@k^^4ZYZu_s<
z+NXA?II(Mq#gA1s`BmSn(frWMk!#+UntbNo>mS5?8_fQaQs-#PNAE3`-S2p-L!XPM
zOx`|gUa-&EY~hfAA7VIO3zEv^t-ViN<TFLNy_>F0=kxxKKh-;$w0BK$+bM;U`?z%9
zOPOqwhU?vILGd3q{MRlWoVmHJJSOXx-y_=`$vwOA!&SxNmp8<^u#lGTMfl@tVPASa
zxA|>I^46fO6Gt4@{CImth->?uNoy^R4&!_99Yx~>)pb4b_qJs5RmC+r&XGVgb+`qX
zq7i>zQE5VQ=qvqA#QG$guS}n0c3hvU{F?}Df=UJ5>{_M2*~PfZU37DJql{$Q|H^gb
zr%d5q>s*ezAnLytb>D~c-i_w4PN1&$p6!a?J4z%V6S}rsUxOE7kd7i4@R_xRH=-e)
zUCoDXU;4uxF-V7ahE-kfJ>|psSuKuzOkoEvD50+Rp674ap?zQP{h#Z+|GvI^3nkl|
z7Qds(#4yICU5kB}9paFK0*JcpwW={3$Kv1DX`jw#zkvSV>b1A1&VB$U5lokKApc%H
z_M-m!bo?{wuD9@E;nj`01k@#<E&+83s7pXy0_qY_mw>ti)Fq%Uf&XPCP=)2Ks8B65
z*E84C`mIjwB2Gey`_`9n?o8ZcF77E`#xSB@!k4s*`@;X(^;wD~`)AZ?`H>TFf8bm5
zeI41N-=FKYRM%a}c_hl~TiunSp2{e;iT_F+l{%EG0mOMwPPa?vNX7Y6alTWDD8wQW
zIvTtV@wWkEk-~;r3b`iri9r0F3h}qI?cfA6ev<R&*JR?)ljT8&^9M%oM?8{Y&bfmS
zBp?NLoF525B(hKrof;&}If-iv@we;}k&8l@)?z-0L@e^_Fb*eoZQ%d~5|N8Sg!4H`
zLkW0bLuQ2p6rv0<lxZGxI1y|FyM~-2K@tinEK!%FJ)EI$NIRTS!iix6K9_cIf;d4e
z>VULC5zOT*6SCU!T073&z}}2yhNu%!)LmExZFAm3C#Kbz_XcM~BOYF?q<ADlhm+Or
zh(<gVT+0#HbFv`*u4e&CA^xVPH^e;viO7X6C%EM>?L~PY264R^7kMzVWxnu62*MGK
zI3ywk=@92I<NJ~*flfd6RqTtzK1$uFOF&%$>Jm_wfVu?KC7><=bqT0TKwScVzXbT{
zB%A!-e*WLvZ>pQO$KO8vKizk_!pG0I@{#|4>1Y1Os-F4J<2R~kjKNPr>AC-Kep@-r
zs43&6$|?xHRhQsGJqaEz{(j!mr_Qmq_M`FwH-%q-X&W1F@c=%*jw<T`FcmF-)5vX)
z(C^!`|KjiAjL=YcO%D|F)zh=$wMEQ#goeLNJhQ(+wR~w+DksFxM(O?}BeFZgDZgL7
zAm8b;f;?QjJly<U{1pL}i(~d5FMBU*>&h4Z%Ogtl98@mRpa1{s`{U=hthMxB{`&rO
z>DT4E_qSQ~{-QY_AR2LgfuHZxD#3l!443>re18l6yKj*Bi@F^CGwbmC_bAqxr|Lb4
za~q-&KjFoDYKZ~7r|kdXdvf<sxJ~t{Ts~1=f7|?Z9msj{`{nyqzeMFakUsw|{tWZ|
zau=$Wo6`)^a<?YMy3n2Z-DlyyyvbNw2Y7gUxCMGh<tn!Gzis}y+_t><{c?-t`&K`P
zE9ZwqQ-{xlDAyX~5|+>5+ww{Eb5!ozDnF|1%P6w|?m_#H*Qv~w(<stskV(n*@&Oy6
z;VqTR5Y_q&=Ny!1{$Rrv`-l=!)X`buqbis0=PP!h)7`wOyTj$LbFZ9#qBNDi`A?d^
z*e|5>(sNyDAHbWK{+E4)g8m~k0z5=EWjI?>)CV#`W2z!xPUZXcb@TC{H}$6I>9L8(
z>PfGAPjw0K@SIA$C}Lc(4LFeE?|1SZnT4;XAKk|EcO}1#!@f)``}d<t%OcjDs(hx>
zDwR=ZSzSHRZo+vv(d>m-H#;HjXEmQAm67N45SM8IenI|J3?r?Je}DU}To+<F<%}=R
z0gll4%V;dWrd}ld<jku*udk_`wzO<?s)kqi_|q=78=;hTQTK_ut`c=!CF;6L)OD4p
z>ni!j)K#*;ko~ZxUynPz^%UOQEKi;v|2c5(@EKwEcMbP4S5$xTy6TYY@7Jj7D*4}9
zSIK|2Zjt|NohIr!NYr(Z{4?qx(cpSEb+^q;*w)NAY}l=-!$T&SkJ7z)F{x%fMd28;
zf)7jg8D?Bo*Hxmft3+K_iMp;5bzLRux=Pe_mB=;Kb(N^=DiOy`>bgqQb(M(iKwVdf
zx~>wj9jNOnQP))>wgYutCI7$FRq~Inv;Q5}!_1+&zd^e1A(eBv;xfDmL}RZZQ;O@H
z!$@)8!Eo~1c&hsjr28cPJf0iFajU(|mE<;f*_7|bQ(e!OuJiwSJYR+r*9`qgasA(4
zHJ&Z)s%z%bwRAC_xCCqg(ackg7fNy(NH(8rPA(wDHTQ+2SZ;CMQgsbmCa!IZ>4;0+
zqFppRt02vP8OfzW*>X}``(B|MUz;02RM(iLYtIfW1eZ2t<q%Cx)%dkYaWRx<Ae29l
zbx2dPF3BzSGCh*2DrEIYS5lu0ARCYoWJ7WzX+Z8L4aqdJF?o$_LjFcJCB=13Ia!Tm
zYfd&ITafKY6S5cCigX}blT*nyWDwbw6whavkz2|3<T0`%nMs<H56RBt?_?KJTx+)=
zMS0rNuDbRuT@x4OF@XLS^cRgSx2K5hhknv_U`L8=YcMIU+YTkClOxF|<S6nrIgXsh
z{Kk{B$qA&AoJ7WxQ%FPR;ZC+8JxD9klk7|Skgg=xw3S}uEHaMd78_+Y8ANKap$C&z
zB)0`9y~$8Ao?JlYkYQw1Hju?+S2BW}MlK~|$z|lP<O=c+awXZWs!X<;6wk7(C8Nn0
zGK1VemXWb!2d-alCf&(6ax=M|+(E{Z2gn`dNpdIoE4hozB@@WUB-hxLB_#I~DBqFC
zNNui(pCFCNlVmUQ6gh!p8&b|DPm^oOpUJIcI=P!XON#nA&XGsSi{vRXlguE0C9}yZ
zWEE}kH(;n<g}gy3$y?+m@-}&t%q1_7cgcI?J+he0BgMTF4@j{cMM8CdfOOx0*p9?@
z!}^e##|&44wwGihl5IrUg?vK}AWKNL9obvbk>oR>bR$2IGssV52>A!Oiu_DQlNIDv
zQpWa78Ot=t1m^v(Tt`!qc2$|Wo+h5N>dEs_h(t1MxNFY~;@KuyZ=Pp@x}GM!gV;&i
z!X1%FKst(`Z_mCSP6$N;GEoHGVSJ|H0B=Mg37JsW)5Lc(-!HBRb!PvMROI0QWj#&*
z<2st^RF(aE^)$(su<jA^kk1o4?nI=D9XJPtx)9G~n(%#@K&GIOVKc}a7%XL6IQ3=P
z(C<g00IvPnccB34MqL8x5)k({{@dsO`7I!Os>`vXkxX`#%*J)x!nbB8ul2(Kd}|VD
z-;I)H97o|>BkuE@&X1WyazEx^E<&*YVF<@kEQe^4$b&eHWE_QP#67LMnYOrRwr!Kj
zzj42s*VbY^zST{zk@igxO%da~hPYQ%G!f>N_xhSLek<C=J;J7FgSIe3dvru6i2Izo
zLfk9g13l3jw&)A-w{FC}&EkEEd$a8@7(*}&!{LBYNTwXdkWQF@Z;hCC6PCvq%`lm6
zS4_cFxWfaUm<BKWZcMq7GcXh0@PRM<;E!1dKp+$d!fXU11amMK^B@{AEkounM^nsf
zT6yoS8SO1$f-3s_9T8oYQT)JGHCpr&&mn{{zIgUvF~qYEjTv4%`#zucg;2tPe*atQ
zj1cu*)a8BE!?))DR&Rv5&WOrVTEVsvrP@CJTxUcgW%<2*bnnLjBtiTgP0`pQ8gWR3
zICtWNaKu17Z)48RD+Eap&$nbj)De-)*LyCss&R}7Im}=MQO{%);*f+iWFZgV>Ve4P
zw`Czpp~Z1WIL8&=jxX|QFG4xYYVo;3IAV~1WTe4Khu`5yMj8rXUYqv?dpIK;2K-Pp
zfjMm81b6r&6tPG^GO|#JQs~xY{t)#}*ufqCh=QnpA_dtfLK*aRnFnm(ggmxw|9X@G
z(vS=BH<84HGx~@}5>k<Yd=#M!;`1(t8LZ$4e}p0yDab?tWSmelf+_mL72b$M0@7j2
zNxm%Pp$s|(Odl4og#)~yL<~f|7)20&SJEHiM|~7xk$_~RAr~bmhqfW_3+Avx63Su9
zi8?Ddvj2`jI<gTZ_FX7M8M4?HmP3c{o=_wq4Z3oc0}jZBL37?G98m}ZW99*G#34y!
z3x-8L3`|%agdh@`D2HiFmJ9t6Wy*R$5y~NN!}Jl37?`)?I{_g`hLIWN41egfXIO+I
z2I=OMLnpR5xOS$@kbxXTb)g;N@0odZ<MW4fWFy3ivPBBqyR(fU75)438X}P~fbtl~
z^1)^>^M?{nLzx!hkppde-Z#YWID_H5SA>sX{X^S<ekdBv`gdgdkd5K<0&gUs0J>wD
z4;&DQSj3N`e4yjRdmPWWa6|%fP=FGYLwf?lKn~rB%)^<41H7@8&xrUAYeS0T4Hr^;
z&rc%7_jQD-JDe2Hr%Wcr_kVYC38`+>C7><=bqT0TKwSd=KbL?O3+MR{fBt`}pO3#=
zfJdP8ckSI&)d2iU*8|W?_57+6=VV2b$nOabw`9@eK1+^un$(tQaB9F;;Su2L=H0Kd
zfJRFN)Q923bH#;X#J_F&9HC!LnYCUnIf9E!;<?rm+Rt&U!E^q9c>q^Dvs*_0D5<}_
zR5!!$@1Exs3&7zg<G2U+^YI_(?KUltPHB4L_m!y6kLP*)E0?O1)L)nW3Td3FQ@#3$
z2Y@U4b8Y!g!*`a3m;cT1mHkcs+TYKex)0o@c}T;1G40nJFOAR$o)YBg=@GzjsCXYr
z`uElo{oST2g511a0(laee&W5mlK*BLj%CF-9JZ;JRZL16gI6kF<B;&ruQ4YvJxx73
zmaRYQ&7lg%^i8GpB+VzC*G)QzWti$exbhKa=^0@M`pa3bqCc%N@qBO{S$DnK%__&e
z!Z@N|FV%D3iQ+>>vk3->!G5+0+g8%>E-un@-+!}7NZUjR!~Q#s^sKii3ned>@%u%3
z4x73-#IT|)BFTX7`n#we>=v&@^V%b+Y*n9A7f)$Z5Yvn0HBr~+2#v}QuP8t<PCQw;
zK2-f(DxU@y<0SrR98s`hoa8@^)A_q`QvdSW)W2*GVjMgAA7vx`_I_M~{N3FY9#VOh
z@>)K>+0@TqtDnJEKZC7)23!3M_CMwsY{!{=pJ}c(FsgmOR>x4!CjnQYd?qyCmeZ&C
z=%5odyRRM*9C7wGJM4=#Vz|!Z4laLh<5c6!ut^PH*Zs0$@PH=0Tc7=+Soq~h{@%m}
zi}{}GEr#p9s<f>2+@|-P3XCQ%>Qb2ZTrt4-<f_=M(ZknmGHhu-i}O3(#c%<4bnU~#
z2Wkb5e(tfm&u_|h19UI$9USre?nZO1QrC`2GMO9Sm2%Cdf%Z*WwS3+v!Evtd2=}>>
zE0x2{zP>NEj>zoPsBe?Fw|qBno=UFyqRIT?VaAujS9Q`&IPcQ=w>2v>JqE4ow`@ky
z=HsJ_N9yt&&v`2TPG`vcn?4^~j&%4@tD9#?<ibAZv+p0&EpJ(UK(Bc(`_@o$f0;Dg
z!D+_~d#t(o^Xj_lXRyEcedUNp{S3DH8SH<?GuX{IZ!Fh5eyE=NxJPysU7}_$b$i?S
zc|e)vhUbkml5^U6pU~ejhV#ZjgT!#5VOA-<sw_3h|DxaHah&bLiDMmh<(CDH^=un_
z|DeG%j$th=#Bfdb?R?VK?_KP{Ia+Qy7j;c9?K=|Cee<}ueKqUVZfq#7d7P4_x1!tH
z%qa~%cJ237Z&+f^!X4LxitgO#-=V3j-HLVLce=Ar^OBZNKgT2SLzQ>k?H$K_SXgi4
z*z!>mTOEuu-*ofC-F}xoJ5=X9aW667aAmmuy?0@=U7ETqop&=SxJr(};+5NXDylX;
zzb9l%#A&VpOUt+4*HGTzTt@E_AN8}<>SwFf&sM9StyVu<t$wyz{cQC!TlKTm;y6P6
zY_<B?YOx)tpRHCuTP?N&^|RILXRF0_pnkUcU-{YUT&_u~t{F?$lEpKPR$TweqQ7Xk
zMNfJLmQ$!oPJ41~U8Zy*dyrE|PSr}!#&Rk`DK7GI`a&5)+LGJIKICqa+wqi#NlvRM
zGssb79?7(nMI^V%DL;^0TUE-K_au_%lx40Y&mGI$NS-5>O((mNGf45wus0b``jLl7
zPWLKP$pG>ksUWYDv&lzf5Lt`sufgOnat`TC&Lcg^g`|QEBNvd1$Vf7r+(<4Vcast1
zb#f_LpKH3yNMmvZX+}~8%IV}5(x0R(l%?c$Qj_bn@nlnS7de64M+T8e<Wce%d4)Vq
zj%1zuM7olk9#=+?C&>)*9C?-eh5SUGC&j%0*T{F2r&yP&>%Y=<VX=Oh>|dTGzt3<6
zbh9p$ZOMnESbv3NKEwViKVxcI%zc|sKWED4xF_cwp?=Pk&&v?@J5VAX>BvVJ)X$kx
zF5JtUf?UWZa(xX>@JAf7PzrIMvke@P&%Rfe{bhfM{cAj50Od%ey$Ju==S&OPheplg
zUhz=Y(R}8K$ePS=0r!Qo^R{B=<^>BS_iB^LD5pJ<9eN4vTI|#8VAX(SC3E24mS;7|
z!UrrT`vdVjM>wySFRpx!!z!G4(l0%id%MX}*wHWNqn1q6V_*SC*srEM-Y_ohCK1e=
zbRg46S2Bw%hmkh>RoEbh{?4R$J~aX9D1g=y=0n=m;24bdfA2Zfk`7g628PU&_y2F6
zSLJ!v@1I#sq5Io&CEuP~mGcKo?Zh83RX6GqP?vzZ1k@#<E&+83s7v6VR0160$to&T
z6X)J2AC3plkWca7tpng6{mlOhmgT?toWHm?ei_8Q@LKgM?^RFaJ~DCN^|)r0_e_iX
zqs4vD;(ljwZ}S1;%I7n+n(!Pl?c&+~L*!wcHR3oDi43<NgK6J_tq{#{Qrs6c7UMC7
zVa8${zBQtMe|$j;yu*8l#*`G#8k(UaIzu!SWEG~Ng=(s44W!=y+6Sw;htORE;u&A@
z9P3y(!5p2@7VRLKE~F*8p}VTzcybm3RoxRwXH3FmxWOI!nf^UI#<wPkb{k&n1<_0+
zr(>q7yB1|B>ODxN439wE+bx>iKTu}^#Iq4&Ss%B|srL(akc<1s!!=|JOedr%by3iM
z12^%lc}V*s<l{Fy#uF6a84B?dVj8c=B8cY)L}S9bZ_fSt#t`@Ve`~tY-W``9?&sgb
zvewgOli>HqFT6KhmPHTq=)alwSIqQWnEqPY-_Y(#yE7(YGA2O`UzhPWFw7QAq2E8d
zE`;m#`7Hy{+$Ha;+8>ioRqYzQA5GQz62s}xUiZ6hbv+0&S#{REHbmo1x%sNfPIN11
z4_0;8Vwl>h;r^p~5X62!e1^qmN9;#L4rjX%&)-DRF7{pGvn)P$VjKLvz68<!AJv&)
z$Ff9%pTn{Olt9$mD9*!*^Twji1d}R!j*t#fSArJ5+x1}sJ2=7>2}nT(a!`O$Xz^QJ
z)UQwq@q1hsMleGXzoCm%zooVLjqCtd_(Rn17lqjW!`|7z<#hg!|KtvtP?ibdMk9m}
zl91;RLMD^-c&F$|-4Vj=agC5^6EYzavV~?IV%eHC8X@MPO<xNk7K>%V|9zeAtQni%
z_rLxB-`~FHyn6RJ_c_<O&UJmxbsnyV&*uVL>dsLR1M!dv#?+N9zzS@^5uCvdbPx-|
z*HZ>$!#OB`Vz8>oG2jU9;0roPfE+M4Cf{HSjt~pyK=@=R0lQl01cX0^IB=}Z@sI-P
zkOie+Q-}CL2Pu#a*^mdq&w?BGbSxx-c;;n*6VHc8h=w@G29x@<9e_1BfD;5lBvkl8
zu%q$U6Vf3Y@<8}J5dIAM)3)FW=^*AL3<cqEGzJo2FJwV3s3}9@oe&6#a1IKg1av%q
zvLO$IpMx|t5=z0a8R-OT$OgmaloJrX3>?7)w2%$wpa6=Y49r`Q7gzwXAp9Ndg;H>{
z<Ts?iUdV)eC;>6SsRdN{J@8~b3Zfwi+*^`H$b?)d0P9x739*m}*>DaDp%jd*h!Y&a
z8QdWd5+E6bUxjl}2&G`wnmmF7ID;pILL#I<I^=>~8`1@7kO}#1(X}<lfIFDC<GO+t
zgzp8n_JoIcFzUeZ-~<Vf4SC>hLp~u5oI0XIh=yz^1LICeu<1;GAQF<{92A0;Epb3J
z#6uDkbt5fyqzl|Z2f~L#0hB<jJ!J*Xfk_Ya4H=LFfewU)0w@8sBl&>^kkJQyfn{Ir
zD<}fXeyl^*K*|EB2a#4d2Zm1Q7BazTFlmCM(d>glupEP)K?ezLoFDRG@0-L0744b+
z<H<KTPC!C56uiat@}PYYBEi{*dkvDn)0b-o*<h&Q-hoiiK`InNDM%C14+MhNpJO2n
z3<Jm$^amGk2Y=9l=wOS1cu0a&NQW%Qg?uQ2QZSr^4xwN&5^MvB5A00Jzey92;#){r
z6b&dEP&DxWN&|+R$ont1|1Y0QT1;mD-(dUSNpI(!Wl(<AdLx8hd8JAXd2bg>H6?ca
zsuZ>hdw*WP&s${MZea^;#olYY7oOTe>*v`Pb9}4WC+eZt|7&@*Ny;46aqVjAZq70f
zzTTy*P_d6z?4uR?XvIGIud$C_%J;fjWw5-;%<X9{TaBLe!Ih8mzf9SB-0@Vke);$6
z&mAzl@3^`=%oY3S!?Rp_M_<1;BXi3)wZ0g-djE+lx0cgBIzZ@en$wuoJ$BZLi$Ae+
zO~Oa*%)%a8E$XH_YqqfP!dGuvPvRvOOZ`W!ivOXT`a#k1@6Q=+kGo^KxATOW8y__v
zxOvBR`|Z~GV^rs9Lzcs-KbZdL!0sATw6(|Wy3j6g(dDSx>vG!OPDpPS9&*sK<qmxC
zQYTic=C%KR-PK7m?HqDajvF4YZ&2h^u&(u}ee;{I>sV`U3soK3j^*@~&EGofyA4}^
zm_Or{{jWBCJ;G#0(JkxmF4s-jSNdS{=I%4;8<FF4YT=z{R7ExAwsF(-0d|RHMPV7E
ztOo7wR;}-ieTsebrAv=S&h4StNB<r6(aIdviXC;sJGkhjVxd-Tu2uWqiR(c=L;Boa
zvr3y_Hbqma3A}V`!o41!J1ch7iXF9LN3GaVD|Xb19kpUd-EW9ouh`S(%ZGheyl>H<
z=-%O7SNo)Odtj(`y|X#^;G<eMrxb1A`(6$=?_hT1!R_^Wwdu2^jh&~uQRi)Y3WC&A
z;*J)tY*{k1HT9X=gGGGn)6d>s>UaD{UF4nD_GE5|n7aA%EvlrM_Y2ooow({v-C}H#
z<oF7gw0h0#Qrc17iO`4{Px_AUGqd%=dh5dO4t;Ov<#%>@l+d3h$M^Y_6%(%n&q};{
z;lBIO_ZCH78rbK9?dLbte!KVPP0Qyt4P(rV9IojnNsD|l8?1<%618IE!rJd^kJ>k!
z-}6F9my)ed{A@bSroXe7NZ<FD=d`N3@0#_N#g0z4;iFY2Co6W;LNAIPwPHst%7J1>
zt=LhEa-i5z|C8;go#-3W_rD1nXi3=FRzotJMP7z6j6?L*xgZ(hCC???6v>bj9Yb}*
z)FV34kM{;Li(~)EcDIVXE#;!8VsBd}zBBoDbp%h)K_X;8J}CCKj00m#+CR<S_GN5s
zE8E#t*x3FZ_O&mvt^J)%?JJDagTh6OEkstH12zylS}|X>CG)^Wvz`WdU=+lITv-$i
zC>l^SplCqRfT96K1BwO|4JaB=H1J=hfhy#;vi*NO2C8pnTzN5#V0T1An0^s9{lXqz
zjAxH({O|h*2r$KFjkvbKbeI8AFdOE=0(cu1gIH3KJK$qTg<T*PF)scv>;Ic<@~@NT
zm+@oppJKZ&><j)I?9&@jrY&Gd8|*TW^~{(T5Goc^uG_01mWFI^RB2yR*2P@tVyXA4
zB-MwCr8DbY^uOzKytzJ(ZfxtW-#!58q+cJ7bkVQ7BFE_0$06PI>)uF>e!U9u8S3K{
z=bXd#1^Ru}+5UIit5?{lzpQ<_uxBaYfn%)Vz6E#i2jPcP2k~$YtZ0z81xH8(;UCUI
zw7r8CL_55&JMRy!;0vJ;1sRY7`A`f}b;5!gvW-};!8%xj9SA>eS+pA&)#UnsCAdK%
zq(C}kfv_R>giwfr43KJ(7qEaVFrov&7W#t=hz^ClPyj}ZGq#2P;0nH=g?z4)InP8Z
zumdN^sYl$xP8=-272+Wo(jXIZpadjr#)bX38~B5;AzuKoU~SGhU;)HJ0hE9XHsq0z
z3k6UDh7Cz$Bd!SqLWS*kG|zx|NP;xTfqW<eJKh6<umJW#F<{sv8ACi2KnX~^M}!Tz
zn0(X(EI<c2Ane7BTabTC(hqTv1j6<^7SbUb5?c};^1-DQ$Ahr>E&wwMmL()X5tKn}
zYpxOGfEo97e{dDDEqRA%$be!HcH1@(3Q3Ry`A`J5HlzjOK-gwyK^a(gq^|(ZVUKOn
znK-}=GQr4}YYM_1+YX$-4NAa)vFm{l1<7{A1;*V8Lno8yXi9-}(Dq;*(!r%SX@+Fj
z3!aYH9YX>*_aU#42-eQ*gHT8rMms$i4M#U4IY0P=<7nc7Xh?@*kX*^v7~~t|1p>#C
z4=4uV2sn2<*UX*xp%D5{;1Gy`Y$yezx5z7mf)1iRxHeD%Wu6@CMcyF>(jgnpK>-v)
z85ntUtw0UdU<dud1>8Z{bvyVXAqJ8`JmbVSiLxjfP&A-uK+%Ar0Yw8ZuK`1X`u*GX
z{{i~x?A;@SwC*9^ll;Oo?p{H@U2WY1f&;VxUV#BKytDx!!R1~6>?H?N15duMq*s|A
zya2aQ6>?aBPgqEJh@Vz%HLA6GM5s0(C}2iF@I<wk6g?nN6UMyjmZlyaQ++(VwA!!$
z?+C3XoKIv+Q-4ihs3xrPRx!TE($q^E$T`F@K4Dsqa4mC)djxp}GwpnkCRke@CLGK8
zR|qpUAlNr#TDVl3^?^)r&xGToxjamtzJvcHjI-$uGv;#C`v4I0Hi)GjP_+<ECQ`L#
ze3!+lBzBc2$ImNV>!Ar2GoSl<1V;o0hHAq+wD$HPWW`Gx66P>9B*3?qTKre@%_@8a
z@JaieMeVqgt->DwpQMs?Q{fLl>mLwa?hjyyK22^_$`5r!h&1s@Db*lNx)-F$BQ!+5
zuyQigZF&*>57HpXX{fDF!^ftwPXgH=!A7YLzxbA=PA3-eIawb@K|Ri&Q~CVQULt#Y
z-w3Zj{gs;-7~<^}=uob`pol<ifcJDRC>P3$^x4}-1V1fr8V83!uOM$<FAp!jPTl-8
zT{XU%F1~i1y}f<CeY<w*)UA70pN`#aHQjxBsma-k{V>=()vY7xeP8{nZbe?5*k(!|
zMi}@}4ppXNt_o3)6}r7vo-g^jaF}#LzAgcjy7KEHd^NnK*NwHf0a^HDru@nCZAh(&
z*KvhhUS2vczZM?hz3Pvyms<8OQBh`E$$2O*Gfl`B)e&jCTIB1uY8G*dbcgB7l)9?e
zB1wZlq`NP~k<X0sbU**Ld+{|b_l@!E1^xAM60f*M=E&bKzm|VBJLgs^|F4l3anHOh
zZwuB;^O))t7@?7`l?^%<?FqK*KVF_*`C9Q)dha>c%3hymoj%W0M<sFD)F6C9s^8V$
z+g{>X^P8mq;e8{jEkdUi@#pK~r#ddj&tpZ7-{m*)YyHDCUcTaq=jG%7KZ@T`w1=>W
zXOc*NO%Ul1eO~;&n*VY9>H7FZ0W<<j82u{s)8E8j`Ck2_aw<LbgCd@78|CMURudK!
z5X|E_cp}?`?)vJljbn8-un66Wa|_*xbLYJ9+`JfgMfrFI{;3XyFP1+_Lnr;c9IsCU
z%^9+On;>PMq08j*@oT~G@cGkoioEsG$1CP05R3jXO1|~w;&<_Cf~N+Ag#?$s;^cG4
z2mbz_tXpx8A^LL!3Z=0;dyd%Ooum9&tbZ^Egogy`-<IXqvOJdG{eODCzWVd!>dz;1
zB+8<=ZbDc2OP|%1{(Mut!UDX!19|Pgl<w^H=W!7)JQnfp5$6%_9&w)3-{njH($mK;
zo`cU>o|Z`~c9y^ED!<1o?&tFNUY7pcG$YAnvK7*q=dHT@{Sc-J4dHnaqzMWMo9+>)
z@tXV+c@xjIU(2G0hhIoo5JgzN7b>o$%PZw6pQAtT4E=d^%VphGz5zYF0>z_O%XdgX
zh=+HCpPwd-RQ$P)|0o>;^}4qf4;YrtAXL!~ME)KBFdgOkAgFwuMP8q?$k#!n!I7Qi
z&xT)h@rGn%x{33=Afx3cu($W{2<&8U|I%;RavgWo=S{Q^i$&a;qFjkbpLpIlmY1vF
zoZ5$d;vI%~-tsgr;+7Ek9bxcmUMfEa)W+q9lQp?K(F7~&)AKp!to$T+@%Q7)J!31%
zRkHs4mGdmFXX10t|DvbF%j)6TYg$<kmbA5tMLgq$&S*w2zptKCuBQ5gMFdlw&=BU&
z^zcVzy18U*x}Urj6HygD<DYre%QsC4=MZh;ntt5ls#{jcTQwzbJ*;or`n$cG=J&`y
z5Yr%e#_lomwsh<@cjw9+n#22uaCT3Y>^l_o%ev`a*1HCkJ?R#8BdPsZznq0LbrH!H
z5%GD<btcExtZw5^zqYG(Z|3Q~wWSYNTKRP7QTtJspyf5&w6a`yaq$*>RreI}`JY;_
zRQjm1Rfk=g=sI)#?tYTz`OS=$7d4hHo70B%zs-B}iG1EwjT=-S*!@`7SBIumpL(pr
z+^EsVawce(j2gInY=ce*vIjGl8Q;fh)!T=CUioZR=B??GcQY@hl$hU7f8e}t;N@w@
z!d#}+%oX2#P7WfR;(u#Qc)r8J*{&nQQs4Vh@xP_`-%|W<{jvY8Z(PK4<L7FhTv~MU
z;9cv-OBdx$U-G*9zYex)aORZ9^1=1qtNv!&&n0Pv{2Vg+?#aR;-JQ1e{JR}EKH~j2
z-Q&a`+8AB<KI-tK<HwBNJxQCwND<$IkPW@drfx}23mVf*wd0k&eLuc+TGexJe0Z<B
z6XI-2yU}+=<BVFBHL3o9deyg&DP8CJ<frpfdLNr)IPq%RH<#9!_gRf$Sq*n9{=7a+
zRs4B94(0u3BFc-~BHOn!wwNA$<)^wQ9u_<~^5KUQtF>_7x8bdo=g+=>H<Wjvs9392
z#ST4EItGk48~vrF(RGU-Z;sltF!vk7Dtn$h>~nnG`)&CMes8D<_viM<EBSC%tG-Js
zO-kFcyVi(1<GS~`_wIDhz^QxAyWMoQDf%ievGIC7#$xH`RjW!(JWtJTyw=k%yLj*e
z>zWU$oS$=UnD?QwC{^=yK35KYL0>HIbhXOZXkhR3H(MkxYCksMgAO*|nSIkUEvbg8
zploaRHe=)3eI!W-<oK@rQd0k?9L1lPLya@j-0uAy{=AI&7E`ObRrPA=_sQ17aeYS4
z`Sz`(IROvW*T3OkKcQogg=I`w0A;1=KoM@wM|FM2UUGWUIcDnHUUxcO3oGsN{<Q`M
zskv<e_nEC7<4k>LkO&tw*DkGBmA5VPADQ*IoZ$HV_%~cO<(G!P;n!x`#U17o>oO+E
zR)lM^b>k0hLhi=zm~QB0{FRB-(XBhfy000Vu=SO?wHh@nBHTr}Jez5D+r=~=HDp>s
zgS>BR+<syju<}$x$^UA1E7Q5(?b^aK_keufCEec5@~-!D*M5&phb8CE*>EzV=-X5M
z+c%NgE?K$Y+wQ#?e<0_>ELW3!zslY2&aPwb&#AlWjj~bWTkc4(S$+Ec`F=+qx=^0`
z$<O-*x&>wz?#`X+(Zu8J|2w~5gNKX!uKeWug;rat#c%vE{PgLKrxs56r2lN=!$}vL
z_qfoZ)`JjqvR_W$i9VXLjDAbUv=3}I-|&M^YBtoB9Gg8eEA-;x*4I}RZM{ibKI1ji
zs@ox*&5xa3m%6d$!&{!k)oTT>-8rE4fJ6V9zJE*X)y7?>pl9-|RxNqdFf!X_&uNF~
zAMQ82oZ{<$Jl`{X)a|7;CU5RGewZVbxFs$k+~e<@YG$@he)B-x*4~HRj(xf7PW>-3
zj(RWMwbJ>+<?a7<m@zf7o;BGy0gr9FG}uy9Ek66>H$zm>cRn_+`QF-jQ)1i3JEX2=
zT!b87?G0Vjx73lJUhH`*B|Ey!)y8M)Up)Qs{6@>B{&FRIlNiU+P_8c=++6+Si1v<E
zdfGbg>v!z@;=4hGNppJC@kj|6rha{j@Hci#j?d`YmYX$=XCM6b$}j8JXzsVXx8?Oc
z(JpNcM;@Knxu4bE_`lvSStrVtT6HyXaqd@dJqS7TOWBjoj!v1`UUgR2>3;aF>KXQT
zhIvj|#auvgeP;2IZ@2A#Jl_5-x1TnJhB=<!b75&x^~m%UV~@rpo-jI0C4IJ>-<ktI
z*2LV%&pva1^fJGcdUM(x^66eZ@>tx~6!Y#Hf7djo0+8!7v!;BSKl1A@+aG`b@U`XF
zRv#!+UE8HT_D*5+%%}~u?<5i5PjWe(;FYr{e0cGEYny6LQejS`-gQr{v&`Cgu=?(z
zA3klf5<Q2T$mQkCzVL@T`xKwd>z#i0`thKwpJ!WTzt$|_e2vomZe`og^7@d=i(%C+
zJJ)zB{>v2qWs3hY#ebRNzfAF8ruZ*Y{Fg=XeWj7VH~w?|mpvIEzH_P_+ivgjYPCn_
z>raxBdyU`MKIz*<4v+kN#%Q~=I<flJ5$4ovB*JyfoAPAKx`<v;UAA}l@bgKlyyuMk
zdiLP&PJS)bblLymP8#-m%irT0YJN6w;_hu1>|U9yyR@+P`h$56M^+piYqz$?#Bp~T
zT%j%JES+^~m6WC3H+O?&`+}RFH<@&OQoy&{LjBs!Gyd`6_7gW2u2mH<u34^k-^{tU
z+OPW38!27Symxy@jLlbm&-z1KBA<85za;N|>g4>ocClYdOO7?4d$^UumgD1ho?7+b
z?MH{ECrZ*X#%Zfn6Y?*_9@V+G-rKTk&f!{ZW}B>=b8<_|adVID*<rf(`1O|f6r#;Z
zty((uRgV$_$0KKl)HoUbuT~*H?wizZU-ceu?h1L`cu?mDe78@O;|twk+EVJ_s&&|V
za-Gf9rF-(qhF<!th03f;*PVV>_cvWBNh{_0+mYc*AB0q$^L@IZ_TW_a+xGvO^}~?1
zO}{?5YFv1;yC(~%D=?^m^S*mv<hyxYVl1L^)~TGjdu2M=9D1~BTgL3eA5K5F@!{6Z
z^g~bwq5Yt_w&ljE_bzpMtEhQ+|HPG@ZQfY_*$mI{Pqy4rr+zx-W9I0T>rqpD>%V_t
zpGohDX|qnYI=}Y2Ze8nmdH)jQb7JM&z4mXP<IVTDxrlF+<20WwKaW29nnvCG=ZF&x
z*0*!nxxY#O2gjZ5yG_0@`xC~EcNO6Z`+pS{*f%`r=l%nB`;5#pxV$#|_N=it)XS&c
zZ<zG?&K0Cj*59AEmvoZL!Su<^Tk2NDR)1%~z6P%C=Ehv>6MM?Ers?{XpKtjhy6uE3
z^wY`V%#V&Td~NKC`RQE~URgF~oY_V9h-uZwuN+su_mT7g<HmS0MqdthH-E(fi(ZdA
zn9sSUO1$Ttebx2oysI&`UE@=OkIY${NL}zp2K}g2jjw;x^rxK#$G1jlJZ7bM)(<#Y
zILl(??vZzbdXFrs7f@I}u3xQ69c6fb?y$x)qqek8YuxAEoPuf1?|5hIJl*_3+-L8*
zd`xHI0lAz;J{mtIDKR_2!t|}lcjxV~Z?aqQ*CzC=_-p$o`)i}RTrpNs9z!YSs#LMf
z62wxkilh@`30^}|t(NK|?;^!<`tgjCBkRu|S4DrE3Mr3&)E_6p>c=6<V?<0C%vP0c
zJYwY~ooMT`b`VK3gY+5F1(|^yg``<VKEEUD`Z0U*SiVFesT|KX!V$H!9m!)w`Up7$
z$zxSF4!IL4^5F>jF?90Sx@Xg~g>WLCWTZ%=h*umV;_Zt}L00HPKQ2v7t0{@}RMuld
zgL1!jO_6H$w?I~$Uq9YV9+UHIKAiN&IU_|nh9T=BM<C6R%r`5?Bl4&pS0;})6Y<bw
zB3Xl2MiWl_9)lFu^9^K8<XHXj;(F@GjY+Lpe>VLs2`BpgyCOx|u-6|a&Z{5u^)&sJ
z&)ZXfTrZ?ZcYmZv_W=Fzj;x!Mk7tlturAKa-_!Ci8vTm+T#=&ujX_dGW&eOpkYo8>
zp??>BJVNgxp33_7A{?6~Z)6puPo?AZW3J@z&mOl}f7}xNaWVSiM85T7rx@o@e!j~2
zCXG7ryD?IfXTs<jAe$mZdObluCQ7~!#CgSaA)oRRPdITrpD8*K{~DwfaxJnGG6Cs;
zT!-ZIN%{aO?vwS%QOHE3IFA$P$3MwsL7b-=+r+VAIZ8NjU9*uQeaDe%<O$^K$kWJH
z$Xuj|FBJ6Snxr|bi}*x2@&&Q%W4DNJKT^bZ0BMO7_j4EIA*3TR14(nEd_TJ*zu<Qe
zG7}kzJc68o{0b?~EA*`&$0Uz$66Y2AsVLvcgcJJPifoJAjil>GN<)g{Mfui`6_Upg
ziQ_Amk2eV?;v0_?`XNnE^`{^2BQ;~YIIgn(CJ|2LHyCM(L_az{ktHp%Au<AKft-r0
zNQZv>&U4eToNyu?u}E<qKF6LOr!F6FBag#*HvO9jC(@CGtb^Q)j3a_{O9QD0%!X8v
z?7;oJp_B^$$$mA9%M2x>N2HOP))8F6AEF@zge_wU2-`(lNcfg}39_IF%+FE246t?d
z<Jr=+s#J(iI@=mmCBruOq$9i?`&}Uha;9NVi@q$T6BjsxKSV(Sq(d&0ff)tT8k`{%
zVj%^xp$Lp-GOutq)}ai<go9S#2B8oQ@gVF_(;*j%z^FU<1b5Ja^$-Jb9mPE<<?y={
z%<Z{n!53m64GKWaA?yIY5Dlqt4h*@$t-%$dAQ3X52#kAj4ERGdq>A6Y_ziI&9JjiI
z4w4`XOdLrg_(L3IKoOYtVLJqZu!~KFd@$+DcJPHb$bdpH>&Lku5E38*@}LYX`m+z*
zAqo;89rB<IEC#S2+#w1QARY2R8pt;bIDwcCIUmZvg?gD5Vj&YsK+KDrdmp_*-eAIk
zdI;$SPY@ppiI4&Lp!nZJ=Wn7HNP}}wF+a51c*-^;KsJ<si96Q`Tp{0p-&J_;gBGIr
z@QH;a*bCW^4<%sCbIJ<(gC|5mEF?kVD6SJE6GstPs<>7V#W@mSFXTcom`vdOGbwuz
z18F>vbD{`8i?l+?Y|6qMo&$zl=Th!_9pwm_%I`APljjl->xNY+PjHTX3CLWCdX@VQ
zS@<3Mt5J@LyKFw&S+`rj`H<0;gh7^o6WeU7^UUDEz5r>tkn<p2km*QIWHwUFJ1@qa
zrxBM04{~d8fHZt(<`TyLd+sBCXFvfME+T%U8fgQO>`x$Val8bRVK3wgznib14=6Au
z4APQ(Wstrk)+_vYmh!@U)|Y1q$Jzx~mHeRu>_VzaagYY*pbXTZRV8QehgisfA~2c4
z^A>y|7E<9H7>BVPlts~iq5(w%iUt%7C>l^S@ZY2XK3#v~|L+67k41x>uvV)58lP)W
zrEa-xlki1V6NGKf&}QW}H;wsi3{9X82%9)H(oFm&OiK_p#xLXhPUyXe^KMsDPvsb4
z2kj0X;0+UD5(Ggggu^tL0kc5|^Fi2U*M(?U0?S|p#K9_94eMYNR4lKO-ns(LuR>Pj
z*@$(K-x|njP#ttl%WaM4A?L#aSO|;Y3de7-pxp|Y11I4OR4g0W*AE7OScG3K;crp+
zSNyAdBMO`6Xm|%E5pN&_!(x65zllqbF|ZVt!E#tl9?$Z<9?SX)co$ZJu;~^y(eJ}5
zh=<i67O}4i`e=jfLcA`-QL*%({t(Fa1Jp;_B86`P;Rm6N-?8d)d-{0fYFG;iumKJe
zZWD4dBtu1c*ui=#?1D7-1opxK_?%-7A%&g&VdNKZ1il8bRFntda{vQyxs2{2t-=Sw
zW71>5Hj)3{@D+Oc8gk6afA3~}CwvG&5CRp;R@M&)eZo?xSVpsb42*?0p<>z2`bU+1
z3x8@;IA;V@ET6FLQ`ip&;1E<SqD&p<_c2(-F<1Frs6TH8+dRM%e83OH@;UNL{krho
zb`nnMf7jqx;ls}!9AOYtEYJFV`~+Qzd*iCQ{8?}vSp>x(mc8s3_HiFlhPFb*lFIt-
zO27BBen|iOOJtUQ{TT8a{d#TAQ>Ri|PO?2$zwdM8aIV>T<VF3q%g8JGbp!II(&ta4
z!I<?rm44UZy4Hn?<!6rjMSrZ=R+q4^>cg8M>s31T@9+z`p7=NE&+#%oBE|Fd@A4Db
zgLL%NrzH@b1Xt3Fmi1}+-!-{5we;6#3EN`y+hdWd_3PpqiLxciizq8E>m!mT1c^t7
z<OuHI50MZDdm$5YARmkjXyX8Xh=w@W3k9%%7h5bOKmnA1A?-6}payHm0u$OF`hzQY
zLLfv!9EkRp49JE&C<M_4qXrvr0B3Lm;g?beF%S=FkOQJ^rWne=s2c4ZAp8W_k<loK
zfpo}&A~2?%#2l<Z_@;CP(UFh@!k*lpb`mY<AO_+=w43CB2^}Av5D1ZQ4y<TraRpyU
z0pYXK3EaRRVj%&NAq`4F_^~txE3gA6a0B6MRM^6}fiHxD+zH0_fg`wpJNSbZ(jg0S
zp%}`*i1J|xjv#!R>OhpAcu0dBD1c%x<~}tCTj&p>LpTvqAsY(7foHcP2>+N_a1IJU
z_{OxTPaeP)Tp$pHBM}R*0$XqdcZh@vKbZ-v?}bdrfg&(!K)S&Rd_i<3#X%yZLl#u{
z(oAcJjvAo{(1H#UU@v4s4&;Lo_nI24!48~2`2H0gG%-*BHjRk~ikfhK-fx}|3aO9}
z=4y@u9mGN+q=I-Jmx4`m@(6ig)q=Ex77`&H3c<pXG=LrS2Tw=_(Q)hm&fo@VVAzsv
zkkN|x!N`j9gB$omXlu?7!uO_o8_FD{!#Pm5rOZPNBtSBxK@nJ46CMIV_}^5w<GkPw
ziI58EkPYX+xINbtJRuOGAie|pz|e;K9CASFNZvsB>NM$uF2Dscpcq8wohvMWI54y2
zoDdE1VBLk^AbfU4!UD*GQZVX@1nX|Z4_ZiqTqpobJM;nzAP(|+aEt?C!5M_jSQ6wy
z0qA;h-5?7@pGP31LI$`y5*Biy08ILGEkO&Z1GtW0Hjr~d9+(Yc9rg~PoPfztbP8Ee
z0*20{8xkM|+=roONCgKs(gr$6A4i&LUpEI!aGbz7VF9>%kS|Drb71UAS%LyDq&M+H
zv=8S8V_&vG@kGj*KV=3C1Gs(=3Q?1|Hy{^`C!-&TglO0c#UKTemLT#CT8IiJ?T`+}
zA*36e!3}&N6rvy+;vf-HAR&}8I0XrLPzu7wv+!lm4=MaOi1(ZL-BT~cH;MTENr%>K
z7rvLpZ)3geg%sgeA;ovD_%5u0{1hp^JB2@H5ng;NitpwDNZDV6e)~YZ6yIPXTs08;
z#k*F-YoeDbq}Z=4iU$4)4Hy#1zwiIA+-=wIz5h+rXv1;S7d%lrJybKT-1{H(jDN8I
zzg~JjRF+lBuL`dR+1H&7@+bafWE)Ec!vCM_IAoAUJ6hI{EBYBLj(Az$B$rIZSgU|w
zzYq_hTdK3=KHI|ho)}?Ju5=M!bG>gIQKzlg?hzg^LxX=Z4<COo;jly;>qJ-w(l^3D
zY%Gtnw$$D9MtOSWv<u%WC4>|H!4=;o)ttZi=7#;?-D|T|_eL3g`o(OkRnr;c-G}$9
zDrbtxwV&hH-2VCYx3fIlM)bN`=k9U0^oHGrh1P3mp7tT{zr=nboNCOBC#thex2Gp%
zZT`q|>yKW}%^n0V95T^<(dm9c_Vf2phnC};Z(iMR+QW@g3*v5lv1Z%hrU%y^vDkQe
z@}4Dm*{3{<u1}+Ft-pw`dE<3q2UE<32d-)TO>)iUyEgxPHskQ(LwDX>IpM2jt&NL#
zU-4d7s~q0Gxa?-$<wm9-rq}3y=F*kg-z+(5)T8%!jccnWb83E7kM}#@v1(O8q}S9o
zLq~4(PguNq`r?MO{W~kZO@v<FYj><k^!--D6yGL_Z<9avZSt}{OYHcjRjb<m_(88*
zvtHYGqUE;chm5jACfUSTG(BZ>DrM@HepfQ07b?C;6kjBdLKI&lk4Dbz@y&S4qAM2{
z_H>N?*Rj_ucFnQQG+Ru)k-EEDmF&=AecfwYYi>QC>3c<bIMcXWgY^4*>eP6<Yjjwn
z{l{BM(oOk2=&c()a`2Hxlit{Qr^cbKO)Yb6w|tm=_?;%EIc+BQ)D?`PzDC_yt@`tD
z4Tg(wZ>`W-+^)YfV$-VZH=Y<xuRcGw>|)lL4%ZH7y|RDlx`z9Av>abaoZlw%h|@!Y
z-K+d$aIVpe$h+?Q2K{vQ>WwLFcE6Eky-bq6brkWP>H4texWl)btuQvLo-sagbc(~(
zF4q>vUjF-hkr?pq$Jg78qz{@lpF8Y~&+y0zHls{Vf0gn|U2WkQ>w^1lZ*7=)?EjxH
zlK*rcBmcjAhrFy$keBuK@v6Nj2b*ivzIWn!kk61lx7V!FCYVjplxhMm-I{Q($LG$A
zFN*dD&z>UOa_wc;cRb@ZMGp^%cx1VIu-(9sj+&BLE&VQy{^rJjy*Cu!94?Qwu_MNY
zyR>V*KC;E|Wcvdxqwg1f#Qa~fp1m!qj7m=KIJe8YnOom7w{Jh=%3BW)&Rl$M(Z{o*
zr<4tIp--)^&~wu!b|+?Rzuou1UDcu6H50z?-n<{Je+N(98uUg`7uUX}^z-%>;kKSI
zI<%nrhWAbSSf1H&*=Ct~_@L9TxBaHgsakcKbz9Jr_P8JA`~3XP9G_y#o+q0Zb&h?_
z>*PoEM~~Zaz+io?xgPtfT)khvfVMZ<D%GkdYi}>R^69p@H-28zWP9zE2W_Sr6wd0Q
z+oJg9P<(SJzBv@%9Exua#W#oIo8y0jZ;qGsx$#%~(pV;c=ltjT$Y^dMzH|QE_l4rC
zLh)6xg*uNFedTJ^VRJVoBVBamLyO{!c3nE(ED9Qa<W&dr_h&7Mc|5OUNi1^-%i$DX
z75{W!75aWXsSEvME>(YP!`+S{6!qEO9!VFQ)BzbwnEzy3=l>fUXJOy`zrmh4iEEJ!
ziY+taU+6#lt8JMT8)o{-88>AE&Y*<^5M!wd!Gv*CcJNo(F#q4!BEQHE*;dC`Fhj})
z@>%=ioZIAw=a{fRu55e!tle>Co8#P{4Q0FIKe9P?$HrIK99tOij06YBUC4MT<g<3h
zVr*<>TjR=h#uYZk752rIZHu3^D~=U5$;zT=K+%Ar0Yw9f1{4h_8c;N#Xh6|`qJjSc
z4T$0DPoC&AYJy!htM4FV;I2*i*!2e3tB7&uVvM;MPcFubSKj}ut?=J%1N`sW{t6rK
z|B3yt(8~V{8{n6*`~ACYe*X$PUr`ob*1p#motgthNOA;U2!$w!hB!!sy^sag7)?Y$
zG6>t=TnenP;dKNTFs6;d0sKMO?FxI`C=hnI!sgbx8v7v@G9U-U98<yuHxqKfpZ0}#
zNCshpYeCzBHCVhtSnvd4XPX73U{n+PHHd;_*bA9pT!(fY2!tp|gj^7Iv%(fSmGV~z
z7Ildqd?5$Su=5f&u^C`wMjYS-S{jeD;2fAWAa4)}(csvSb%+LwCfIF)78Zc;wcrN+
zV6LW}2?C+C4g1=n4~VoT&5#Sl9XLN1#1@P@5f`{ZG^9f|#MvSt5A3jcjD>W_hD3Yv
z1*MS2xFHj48P(th@sJ6^#?g@e6XEC48C-jz56A%F&#@GY961J}As&(-71ALKav>jb
z`fyxdB$!}NVGTmZ!p=rn6b&dEP&A-uK+%Ar0Yw9f1{4h_8hEh=s4_`!N(R(QsE^pY
zhlIO_cu#Wo3i9o0>ldbR4+;pLtO*O&1iJf#X~W$k`0pMb=Hu=a8Y)(U0>XWMZ~f1n
zAn%Y!+3f$HX!BoJvNY}8$0o9K7r%~OHC;7Achw|k(;d{=21<2gT}Dw)6^rmsMYT@q
zjJ!boD`R^NiB+GFprDXok8uBxX&ynE@Nln*8V^+FAdK*-5taJ`a1txOUmSO`tuD6v
zE=Z%g!ggP)iPV<c^SeFW=HnHr4G0O=hxJ76A!URWZUgW)U~1ZeZNj(V2m@b@cf`br
znlKM9t=7xOU*jwL26+AHemR{HxM^X#%9J@?B!BYPpWhG5^CQP+`80e$xQDMMe6ltq
z)Ps`3W=Z%E5Pk(t>%$vRUlZFZ^p!$gUM!XMbqRgB?D#`{O)K|W&`b88@G|-;_ml8j
zeU)$f`}CzlSMlUe=xa%NeqLH%KKk$#`g&LIXChPFxGYqG<@OY+)KUTZ%Ku2#mxl*8
zq3q|uLmTE5pbalCS@!mo3tPC>*WNxjA}}yii{}Sxp-Qz+NN~7T-9|54K7V6GaCpGP
zV2!UjFeG?lx$dn*Vt%)%<+3XLOo*y^?IxnEIe3Ll4EM01lvnt!IMn#p?H%>o9SL7~
zdnf&NagF_2{u;hB+eJD0K(CiV+I+-PSufYni{r;H&`U)L`a{*|1N}}rFWUZ$f=JJc
z{d>Hej#gL7b7dV>-u`DgdS9<2L)yH=QdvhoqNBtY=}3Mm{Z>IvV~6+m@KCpTegS!I
zQF^MBfM9J!`Qqxmyl!rg#=oNc+^iJOv*pLiNTleuy7`IlQtJPx{5)09i%Q6gw!cV8
zFI#?Iq@&8^<Ymgw^K>*xUw(4*I-)y3o+IitWC=R*e36dy<tHRU8ycbI&A`jXquf=E
z{8)PSwi1QnW%FD486lo2;#m-^PiG8mxMHyYu`0&m-Y1>0FG{EWqV%%2e_m2waLHc&
z`B(WGh_s6L;fC_GNcJSM{C#L5e?Qp0LSk8Ho|V5JS|J~h_Kb?O%YKC9_j0gTSlDkr
zBMAFq{Yj1;*)P5y#54KX?+3f5+kX2#bYy$w?+20AzIr|9KPRnaq*dCfzh{0;>$Cu0
zP2~@smrm!i?`@IJ=e@U|m(CKxCR11y-$jb=qO8`EG_#Me;aD4daL%W@J6yXl+2LA9
zRLfg&e)B9Wy&g^po$>kQxWMY}_&(=@jd^U>9iNi<{<kwthAw<NP;>6=)y6Y!wfkVG
z?_mS86_4Hs;X8JAHxVwXw`P6(?mODW9fzLnQ_ZcXf$z%B`F+;<wP-uScX#P{V|+yO
z!d0u1^Y2R*kwfjzKTdP@IzQR%%W%KU@cGusyKYR#cbk?LDoO3=Q&Fod(sE`rTbAiC
zy-Qlhon8aW>hx@#+vDWBcUq6D+SogD=~#R}ac<`Ky<`4J=X>$V_#p@D3<x<AvnuQ}
zpH(A!&GQ+Tar*tuR%Q4Q93a9ezKgzW@s_2t@sU>)-$j3o?;^{|qFiOKojhm5L*s1)
znG1ub7mTu6kl$cx+a57dy;^!s7}|d!9|vDKh;W_8?pS=!!L7!jVH4`#s`F^c-~o+$
zw>tbtJLl04`CF3f&Bu2%eSm6J_hluet!6a2=vH9y*1XPzdDpZ9n(tp0zb<z8%GC{D
zcb-B&Wp@!S>{}D(1q%imhL66c+1%$}y0!yMzS=T);kEOtYz#|0JETaG7e+a1Rg-Y%
z#w}mJ)*#7sM(_yV8PQ91!>k|QyKTQPt7C({jT7!rXOi#V>y2mK9@hNmf@K{|lD_ol
z^sg05vowQN_Iqbi(V9J@Z;#|&6LY(%RSzR)oeui>^^q>07<TiEjGoiy%bbflOv+xb
zKA_jk8+~i&m>WS3w`1b&hCNms|7>}k7x^xF+4<7f$ni~c8ne2`&RTKtCzh^B_^6#(
z*h8yD-E?Qo78YLk>P_oOzI@ln`HlafoBBb~^6$?XZI8QSy0`O$nj0TAAGmqPcKhwt
z`D0Y)8N)G9<m1ohRo^AYr~Y92qXWBZOwraJx9dW?z(tp%YOl*_dpjY$S$N1n%a%K+
z)5`H}`P2E*hjbR_o!9>Rbyp|Nv~$QwIc|8ozCn>w!MfI?_RVj;u4ApaEmZWEUy}1%
zHh=4^?>21xVg8I)_P^Tn^$3$0MYpWKyIePAU+II*o4e1%AHN)*Qw#4rqbjN?w~d>w
z53oxtD+<dPWi@Dbw`zTF>{EOuUAm<BOgb~o?cT#2#zDyM-=Vd79Jaf$ed*WVIexaY
z#=XZ$$4(vn_}#Pi&i7wgmiMqWV;CAS#zCz*)^M?AQ=j)^Z7fghP3_q3*8M|WOx#W8
z+Lhf84Rh);=pG-Hw7v2EJuvd!ye=^oQ90{WPTjpSooo(0TD2`>_TdkwpWFCw>*oJ|
zK9f$Hi}a0hoaVFT=h0_h)2Ms@9C4z-`gSfm_c!VP;JCAWx5*b~e}b>#K_c9eZtrG!
z*Za9^zsIJ-l5^*5I2lp&?Wz9ln@DY!tX%MIcb?7u@_lZWt4Y3J<!*Op*D?3!)Lr#P
z*{Ja?cO=-XK7IduzoQSu*qVOSZPcm-x&>wz?#`X+(Zu8JnWs~xRmnA<zjXaZZPg}U
zei*rS;X&G+Wj${TZm6#Jd1mk8peGlWzq+aFW}~>}U#Gk~cmL~?U!U8$-+FxD$mc!L
zM^l#3Z|Ru!f$ioSe(*`nhPsktvu9?7UR>Pz`l_O>H>rQh?}ghToz0J(U6;DC=EGZ_
z#no#CuiZJI_JBkGn!bNa?A69ycz<+}-!n@dHH^%**>l<<`iJ`sFQ@qWAJ6v;A9Z_a
zjmew4jUVPneN6GKwEWuY17)gfyVS?tDU6;OwW0Q%B-$N+lCSRsube&M!;9xz+f;Ls
z3UeCuu6t^oW!BDv)pr;D@M)WsHq6f>f1lnyvoHMN&OXH_^LnS>y?#6>>*v{4*{?NA
zIA5c5zgyY%vy9=9uZLmPE<4wFwjAzpbyd@-oerN_9;(0n_O`{}G%FY}Vb<fN%_XT5
zV~f<PBeh?hJ*RZxyr0`EzLn;=joZU>h(=Mh>Wh1$itkR9cC2ogyLb1x=7xL54=F3I
z+r_ZBS7g0`#l>8U>hk?@BKZgJp#7%)t5=;XJ3D^D!;<tLm*%hgwxDqC)OAiLH5<9U
z^7R<J(<(l#?TOJ>N*_jCz1VO<?}szicOUL@sq@JEdBcV*;aS>7KCk^zhmPwFc9?BG
zJp9(upFTGJC}P?0lCt$Drk<_ezG3ZOW-+$RQKWCu{;4+(6nW3SaB=hY);7aF=umQV
z-3HC0xm#<vFKp`gCVdLu%g>=}T@~L-if<*wx02#pN%5_u_*PPUE2VTj^WN<tF*aZM
z9cbSy`d?|Ayi-E*W@q!-S9~iC?q^#zX4{#d_$wcT4{YU7lv3L8O}-Q998jyKPj22)
zw<@;!I}7$TaBVj?=31ZFQ>Had*RTA1%NNmYCtSfNuN=<&=qSV2#;%y3-ZkNsWn;#f
zU38C_R(<@+arJv2Ngpt7j3;CH<#2cNS1hpT^|*uioNKDYd*0bsU60PY8e`ivJ~jBr
zoVAI3Tm2}1pEkb!P1B!t798IirSX`R;#oi7WZ^7}mAgmY3F<wvs9r!J?MT!y)vDA{
zhWF<VYdkY*OY1bnx02#p$$4-4C;K)nvi+pW>X7Pd44Qp(W8{i^C6*7dsh|y2t*STm
zQCjU?uV1=n`_9D<XWIAq>cBtQw^A(6H~m;Cc}$S-twhtHv;f3Hbx=$lC#ERVVV)wj
zL~{E{bUW($A?Y{O4MWmIs0&2W)S!z%c16xXatrD{Kyr+3H_{QAi=?SRmye`sqcfpS
zG88GsZaE|GvR$N0KPKrvDqU*Qr62nvkLwV2OC(z|1F_IlFQ;G4x_&IobHmN36iz=L
z<hkK0$EP0~@!W8g<I|51kQ$MOKT4mze_rmle>Pl2d^W_P?+cgv$e;DSHJW^g^5KeX
zg&d>LmpD$}Fa6x(==PJ3o1j1LEu`>s^WWgJ%eH@2DF$56VLt~s)5`BRi|O1y;0*o{
z1qqN2xljgXTo`L`hERxw6v&1mFq(<&82v0oPzENvQ>{SEj~5Ej5D&?a4!KYSM%^i|
z;0{_y;_``aAH{c<;=9Xs1mz6^Ar{gg7mC2hh4KYX;0w`^0$ET1WgzB^b#tRULn35A
zKKyU--IZ34`yh&TZ`#;Gp=36;mb~2TXroOm<(}1XFCky#$Lk#XD*Sjw@vyAy%PWw$
z|Hz-0ZFOumJ*!H8<j?DQzP$Xu|M&fQ6&Pc;%6rX{{QZ$nuP9AbDHCk{s!FAhFtMuS
z?9V!c22_=bz+w^)b!CyNpo7Zx|8$2-hV*O2z>mDB#h9~{2HX?;7URDvd;>gWyBOoO
zlYL?wmN-U)5%au?aqcVFF2<HiCVYp0I8KE7o_%6m_j~OByXI9FV*=mhgHVh~+`@Up
zxMMM9_%gr680pn)%RycsO=pl5%PH2y_(?JL@fL_Nu^R~c@6NX_#``6J7<0Idcq(*v
z1HFjxeplHp#wI7Q?+#LoGyRbDf3iP?&&gvZh~)?}OTVu8St!@ZAI+yO%ICl1Yr&eR
z9l#&7po18QhZIN$nkD2p9z~_W7}Q_`uHXs&5D5z)7Lp(h&ViWo(jD@#aWLoEEap=8
z70+nM1!Eqy4j|@8UjT8C1S!>cSA!+*67fFC0pa`64TMhyE$AQt(jg0SLHKAeVnDAN
zoWU1jAp>$C4+^0Kj9=k9030C}gbxR2-XjYj4st=fS4yC)7U`_bekcUt%fSg;!4rf}
zhXhE5G{}G)C<NhuzyfT+1^gi!EV$R5zzxKl=xLA-Vm|Z~-nn@od_IVI&Wpf;_pUW0
zfSBVv4{WIadqOA_gI#^{48lKzkvYG?31T1}vW4V1QVdc<_JcpfLoyVC1<zt95c8D#
zLJH5wb70(*ec%XMNP;wQX~y>wq(e41H|HAzQX#Shx_}%ovgA0}3t8a%I&niD6oGkb
zzSkfM_O>C7V9}O5LjhP=vkn;@NGF)vaQ#5c<y{8G9Z3U7op`lC0tGt<^1-4P`GiP_
z>%;ls9HjOmE+_@-{^$}y!EPWDbdWcQYv;s12!;O6=o7^J*lsi=q(LT>fx~dl1Cfvn
z`A`g{BPc5_<QW1-axA1k8CZ|vIB)`2@Pt5!gar@_y3w556$u%T2V(wb@t$=@ig!f=
zq<DXd`KrZx)($D&X`PYceK!Uv-Zx?%Yw`Z_K#KQ@D4*h8t}KcM6b&dEP&A-uK+%Ar
z0Yg+U>EE{h4-E0~3e^1G13;ipfUh<r*egim;Ttk7I8ZZH6DYd_px?#8)WDN(Hmuqj
zN(G@tPvx)xpRkbd5I?QjYE*0W2#nW*0%imRPgM5{2?`Ae)PynI*3#6&W2%p^QV$F8
zj?iktu_3lJ_16T3mfNmZY!&wSmZo0XK+YkK5ysHrS}!fOXI{bB+6QTZwdG;3ftFq&
z%-DcnQW}m;o~7x)kcePkuX5vg5l^4Kga0s0g+Bm0yN()LADb?sR8{x`=%x1u;9Ny)
zm87?U>WefF!fg3A9cU~WNYWsU*44{9P%}8#R}(ofEF{Po4H87QkK=RxdCOBj0BZK~
z8IEnN(0jRUpSZ4Mk!={^BZaNCIB)qj?+~pvB#57ESDA|XofGLB$L~|+>5;=5KMjwj
zwQ|zr?c%udc!C0aeFHV(x3C8+w+Srwf8ehYTP5iupc*D^g>drgIp_uXl}plaN=$j4
z`2>I7BImgwd2wN{s0)+lN=J%g%k3H?I9KI;;pNGf?H(;Twmkj6>c;Bnw%_W;1-<x^
zmvHtkFHgIy1M8>Zf2$ky)9t_4%|N}qq^GzzERUfsJb<aB*U?GVjfaP9FWJB1#&Pa9
zxW8+N^RL+yww-Pq^PJ_WZKo$YE0+nOGk>;Cp}sxB0Q1&L@riw+jFjud$H%|Yz6u-t
z^5eWC{QS5PS%m$lBeDgIF!14y(aPIw_+1_kH<Tt)E)x~`F4O0mYK~kcs4_`)J5t{n
z{QP`B%`v%02lBmO$1%@Y<a~>KII{D3<wB%a&Aw;T)?6|+osRB{ZyJzRao1H=wR}&~
zw`^=WlQ6m(RYaId$&w3Ic_890fqd%Lik+!qXR6qlj<~VyfKzwVpjxvRPZ{kza@M+K
z=i3Z4oU>VyhV`fIPWAf9g!QZ6UD4&*o!v3h>c?L!G5Bb<<g#?V{aD)ztGax+hqmyZ
zB3w+Db?u(KGt4!l*YQ)2<9se9%^UjUNY+<PzFB^|xc%&pn(^$E<101sJT<%VT2H_1
z;=vEBYd)xQe$KgJ-iOMfRL$4<TsioKBsHUrNUa+5)2cRgO@G*&(rM@Nj~dP!mil(y
ztS`M!j=G+`eQoPG9~INSB*)jjeXEh<9}l$ba<93%`IV3J7HqClqxai8F3;Ng@zEP<
z>rW-ABW*!yRl=cT%c@<SG`-D{ovt1Ge0SAzpJHb!^paBg#hAaw&a@N#Icn99X%}YP
zSbg<yoemGj4F2x?`@^cHU%UCr=Qh%<ldWeAXlSq4nZC%*^slxbeObFu#on{ey?3X3
z22R~`-tDHdP0?3*iH+CO#}O+(H~##2RWewVdt;-4z0==pk-Vt=*nkf@*nDU9P0zHX
z8mfY_t=-#<jcdmT_5nG*YrmA#|0zeY_jIW7ciDS3rJq2p+VfFe-?5jRo^+0x`nK1d
zPS?UpyS#s`fkA3+o4|c$Ysb)E5J6vpS`{_dF0EIUw=MG@nf17w;Q0OcH(WO5mxjOL
z*Jj$q9p)4H@bAJmCHCoCH~!Ej<Zk?q>4sj$Uzu1P-MTZZ`<k%{TVJVLt5L%u!YTHd
zihZVQnj}q>zh7oe`80pz*I%|j{{G=>ihX9^QrfS2i~DHn38O;`s&9DTq>ts99hYsE
zsfQ0b{d(JP+MKFYr&+fJJ-z7<qc2shI)5|Ar`WRR$>v3!V_)++`BDAR<8~Y{SYK<d
z$G$38@7FJ&Pp*du_hjwuWmi7kHuuKQYnp7Yz4D;VRD;4<J#<@oTgDGhc+bL1lD?MD
zdwo=&qZ7RsKK}gV_9>+|K8ySKQg+0W5xHMleIGDhvCnjm>eA%xCvV38;JxR`#gP`B
zYiv&_ne3f<;do#AZ)H8tHG15;#%fQ45nWI2y3qH{`SY%y>;Ap%w42rL%(YrmZDAJv
zbsWX@Sp8`3gMocq?gjXKap2=^?>*=-KdQM!-)>ibSe^WqbYp#YNg7V0ky>@*+I7>*
z<Eq?lcz;3ixQ?%HcB&m{Z*%+M`gVhBv^L!tJ&m#AoLj9LP<?ZLW=Z1)$+hbBo8P<P
zy4Y4TznI#;QLD%W2Ml{$9!fo>r>O|HZ(_=fA@fI09Dk(ghDGBWEIVXB)>pC5RO~Yq
z`%J|?Q?buf>@yYn%=-<KKHs^5{)TSieYxzTpAR%xcyB?WjjNAhpLw^IByH*{^m1i#
z_>U>Ow(TD0-DFj=#k@~1O}RJrqs*8cA9sJ8zcxJfOG%n0*9VJ}N2MHcHF<O6nnsgr
z%&!uaS(NqOU3>Fp?|C^sy8TWPVKy?ZPp$eiTU&LB-I8Ud)py4Z{C>m_^S14pR^0OO
z;)38+o2M+?uuYPF87jh^`}qUu%kv#JcJcq_Yv1TCcdCCfub%au2{tKyEe#qpwz?`w
z=jCt*O6|L!I@h^x(<cv0^LOc*Z#MC|;q~+2GMCaBeuXiLeWqfcnN`E3<Kdai3rIg#
zH0b-T<vwj;e^;ArQ6LtRD)P`>sV>rl->)J?KXyH&=$EXI<hGE^k*>&w$nnTVNKa&A
z<V0i>r08%|BRRFy42h|W)B-sV$=KtkcA5IVWx3D!S$ok^1G?`B{{TrfQ2GT)v$FIM
z`8x6ulHsP(6C}<5qC;CZNeJW=qzbtZSrr+BtcHw78X-3#=^E4}A!{N<U$-$*=t+dp
z_v_02y&_#gA0iI1^dKBfJW?NIJ7j+(x41M2IRrTvITFeE0o_~3VMq;fI5H4P|Fmuq
zawKvMax`)Satv}i@(tw2NH^q9$ni+g-^_SzIel)d>-%3N(Jw2~XN05~OJ1x9C-l}9
zNp(oFMhgA4M~c2*8zhf?sUwo=oYWa9`gLuQiNy8aU^l7QOY%IRuPzlF7<(<oV8?+(
z`-nT}APK}ge<qIH58w}RkO4(t-iPfF2(gd~`C!tQ?cfV>kO75Y){k>RAS6Hr<Utu&
za05GlJ48VOq(dH*fyDs!gF8e)0;EG82m^3SaDptzhca-XO;-!CkO?JVMtegZZS-ZJ
z=4N#SPY^e5B4j{5l!7_$SV!=MXh?z#C;~HXHd}CmC`f`VC;}7O_HDog0wD%cAPe%r
zkekg4oIs387dKx#q(T;mvFT-C!PxZwc6-Se*-F~#(3c^4LMG2;EC}m{RnaL_*hdzy
zUicl`s}XKK*9mF2fa`%QfD&-xx3FXRpV~ym@xaZ10x(=eTu3J#y1KBcQZlI7W&@Gm
za}TgR8TJB$(j*gj8Jox);wcevg;$kaKnF>nEQ$sc4JaB=G@xie(ZGM72C9(d%J%=;
z`CZvgU5w8acA<V$O2ruEZ&|OrUySKK%Qh`C7($?85o54Fq|zwHxt}4-Knv=%u-ELL
zZR7r|ExTyf3xz2lmPn)+b36mYxZ-+djKhbDMc8(}DjEq`8nV4nrF~6VSL=V*dzE$+
zs8~9)-bMerKF6Eu<LJh=?)vQmkWTvb;Yb(#x+`*wetjI$UBB*))aci%5TCFktyt!;
zeSv;ob+#Mn_XV;oSifC_)v`WK|6ACz*3yUjBU^VdhC7*jR%R=|x50Ku0WsgASd76O
zEWs9hArhitFJwXv<UtXb8IUH32ik=sM{WW!&R^KDi+K$rApz1M8;ZeIMZFAiARok7
zc45<wOA#p&Z2A88g;+=gE%ksTNCQj0=Uu@U_Cg_)LL}et8BhdeAnemKAP3B9(iQ}+
zLXyEqh=vR(26Zj!1P}^IkOTQp1h(9Bo)8B~kOgI6O+%9doa0)Upu7Iy3NcU$4m9jI
zLn;WnbH~@v3%EldL_#!J*5@}QKnk2=%)50Xj)zF@?^MWxB1oc<Ef0!7*Np24=b#W`
zo1<gMhNu?g4TKH3dwcdlBIMC1C+xrNz_l~yhj<9>LR_#Hia^~JeL!h9q#bF81jYoE
zfSR$PHelF`{DC`|(-xtH1&|J9VCBepz#kGJ754VwTJ$B)VBL>nL9{ufLlKDf2BZFj
z0W}Eway#e`wgWhBAQH3?3*tTz&rxHfcy`u9isz%auf(%fSriQ@8c;N#Xh6|`q5(w%
ziUt%7{GA#wB=WF-+x|ZwI6xcV6&Nr>6Bhn^F91Oif!YA?=~&%Y3Rmt1;2-G+pu*<g
zUT^cCYEXXV+9HIWTf$P>L5d&Nl-TvFQaqk&>JM$4cXGV2u`fX?cE;Dclocv=#)_S>
zVrQ((XZzRK8K(u(hNBATcgT9TMQ7dKdHGY45)EsoK03Rpd#idrKSz|fJ(}K>b|hs!
z+rzV5dq-ctHzRY)H?_VPx_bYKE4P+Ql4584u;9s&4?mn(t%du(4R5VHfA;;mp$@#P
zY1>n)iXD2SbPO18Hu_6Tqw5ww-W;`OVeU7ERrWl2*ys4V_uIC^C-P7c?$5_hucZA`
zt@<vlG%0P%?ph=6jO(u085fMgHzwnp)T*~u=qzs6-x;xKRrVWCjHXwgpIde@>r97h
z2ee+<zjR%*kTH^jM7WYTzfI;5r-uZ)SNX}{T%#G0cis05`swV|8&lfsek09#8GT)j
zBHWp-4||R~e7o5SW3%cR;}b`xI9%;=ZE@^n#m-on2iCmidu!)SiESJ2kh+?_x}KuE
z9Nb*}<cRi;ReIVw@9TH${NlSog-LUI)bU6O7^Z%GO2a$!?ePv#t2WoFeecBeAfF+9
zZm(ITO)#6HDb)mCx;5cmkI$VKU#!bB!&8oLx%RT_JDzcyqK5}WJhI$9*lyrRM@`AB
zmVTE;e{*BN-W!s1nm!8b@s51EZU5u(_HViUv?(;q@%)|(OOvWcrmq-#G$!$c(P1he
zv*q||4*XaXb0a_d%>B{J{8H-8X?Mt{d-cd;aa&W&yKDRvJL3a)RflfZO!&Tg^L~<V
z|AVJ)4SFM}i>qR1tjq(e*cl(%8WdZ9^4au>anA2On7wS`hxLE>;QYhL>_=S+=y(1|
z{?55lTIH@)Qo+X;b{WMDyY4X5{z}fMn@zX0Tkd(GdW$b_ox`r$Ts*I;e`(s~Lg7L0
zSXU|S=ac>XZ=U|7QO=nCU4~{(b1mDJGftA$I?2zq6Zv0lvLE*5<=1;pnfRb>?Xaac
z7L|5-=lJzA^E1cSA0JF#tQ_us&bteA^O~=lsD3!m&Hlad<CbVknhzO~)cK7^+J!C8
z&<Jxy4%h!+qfgAQ+3c^GKcHmDpe~C(F#7q-kiG7$=Y>u)s$2F%M_;WRF2eWr{RvNu
zetgx#X0+M0HHpWf7f;_R&2o)s(f8|FZzb}~eU(0DwQ6|5Yr9SjA8_K!)9zPxJ9XYO
z)b`Pu?(aqUeLJSc{nL9NgwbEkH=wXL|7>ugVK?La`V+I)pDtT?{D%(Hzln}b4Lq}b
zY1MuGjU=hVU=i+2*ot~%uKL!$q1{vc{Fcc-Dt5+-ov~tPtk@YVcE*aGaZ+M-f`#c@
zlkd*kW8Y-=W~XlE8wRcZJjnjz4vL-e@%>rv*2>L(|BIfrn>~7%WjQdT+hCXL3*KhD
z7JV*i)j(&b0e#=dZ|J*h+7GAiP5XNDL22~i8Lu4(JKcQ2+9BZ~lC)op6;l}<Ola+X
z{mF%+=40w^+-;r~+A6i#*tB;|`r7=M)$HL$VdN;+w`^Q%@1C%2`d6Ee#aE59x#U!P
z(I<mHjjuAuYH9LDUBmAf@3uw$KFELYfk(dveSKd4?z165!&|goc5AIswI2uH3Vd(J
zx}s~f<}vq^TrcbT$Z&tRZ6_QRJLAfB#x|&1-(Mz)el%g9szO?VSoq}BiM}<4H|j+H
z8p9iP(S-SLvOCSjj!T)VlkumF>r`w{72DHv>W+nA@+M<(!5wsv2IoK;&zM|rgHT9-
zY$yQ}cghjCLOz}JCRG^A3tC8|jkyexSuX-h9z>oHMc4$`3%O7XCKHHfCS$%K242SY
zG=+Nce~SI-Utx1vs@RuO*px-lfT96K1BwO|4JaB=G@xie(SV`>MFamC8lW2c8~cBT
z@lkm#AE%x~yXil9F8XKf^bN?jISq)4JwCR|uS(Ktkc$I)8D5XJ3A5kwB71zgvSoXG
z2V^1?g9U9V*5E{ei-t7F1Rd=ssgMUnkU?Xv@V_O|h8qfrkP3#?XtRO-kO{`v)!Ts+
z<bg3K6?4aXLM$W-iA{Yb<bs$7-T?w33euq%ENYT2umfFf?Aak7iovW7@k1m;gC&j3
z?hp%!a1Q!YUZNo$l0nSxE_^D)Lly{IdqZsG-M}A`XyeHPqXy^*a=@q|>ySd9K`t0_
z-<d%=6hbK^H$^{C2GMQU2iag`O<NWCf^cA&2APo1k+`4$%sXNC4(?!yt+_h{LYCfc
z-Wj`jcVRzoPhKG!`u8A@kP3xh#l>_5Ux<Tj$b$m<E*yK2XK=%YJ{sbo5X>FRZR%~2
zj^GS#;0vMPNk589UnC?#ItU*V!bV0}6b&dEP&A-uK+%Ar0Yw9f1{4h_8u;rqAgWs4
z|F->qpgb4$?=AlWeS*9~!?j@n!4s#I8~oc#4yFd4)OVy;rG`>LsL@k7EWjr$Bs|1V
ztF{`|T0J6E8xRyQg9Fw5LV`jA0-0{SE;TO?kEuQ$URt8`j$p=h=3uup_16T3YQidS
z#V<eGy|jUxLmcB1ru7Kddf|Z}$Sc@uq9#bgH05%baIG)ylPyihGEI5Nv~cDwurwXW
zEatvm+JKPY@-Th+4*ruc&Zfc#oxOfu_oyo6*JnS1s-E--#8I!xnOaMt>Z_mE-MQZ|
zuh7x5ZpN0+b?;w(*t7qi&S@UXp0Gy0&S&ot>=mS8o0ywD5_ySw=m-Ne?%@~cHBsos
z)KvHMnDCH@Fdq>dotT<NBT)h2%eQ-!Pu(u>i)DKb_0JIozM61tK(JmF_#`kjjb~qP
z`8<{O=?{KQQknKAgTilKKf>K9&#xS(%hTiZ=L^&XPt^L$ehd^}2663b>Tb?54_15`
zgr&asrQ*v#@nxX+GWctJ85qdE48Ey4v9DRZ-2vZj9oXWu+HOukev2V<j~i`?F&w(+
z;Sat+iZ26Y&h$qikNLoGG7)3n-4@xtow3FA=qo?fJ)!tAFk4I;dS{`RWQPvx>t5Sh
zbL;s`-z(C?na153q~G6Dr^ee|qr)2QKi*Q3ZVnUSymg~T4nERo(i=PP)Hu|&sb#M1
zmJhQJzthAtr_JP^I^m<B`k<E!r}#2Z=1kvulfIGeqP*M=>1=-N?7GyAH6PycEUsQF
zc<s&swFeyf*Yy2cVy`ytG6lci^tb#U_Ra;aifZlugP`Ii1;Ru_-5Dw>CMw>L6z?|_
zG)znk5H><>F2Y7oQMZapig}~N#56<2!ono8!os2?MZ?6>#H6CUgocKSiTeLOdvA=&
zPM&i*@B4pGGatVE=CWpH%`<Ce&#bkcXEc_}ZnjJ)blrW_Bl+8_>NnHXSO#h=gBcq}
z9MNu8l%I^($H<+|X*r!geN2sIpvE##V;QKi3>sSx8<6|N!<ma8nHc_JSJzYahaSzz
zXkb}Zy}fUziK$&)qt0xU{H|`>82z%#l8yT(Ch4dXOqxG_*JBe}jrg(t<IVd#l(O>m
z6N>T?eIzuN!5=@I+2K;1_s3bh@Y2<{hU_R_cqsIOQ$n3{{iftTHS4q;^<&2ErS0zY
z(Tzc?o_B0fer4Yq-w({`ecejqdudDL-kbORFunXGMTsz`Td=n<VehNW`ga<*ty7;s
z&4WE&*<BW)nVx!}Vom$X*&SE#%~fN}h>f|QUtAt~_(wy+r3ZHBzZ5rP%Lm&mGiF~s
zyRq)HwNDs$j$Lfr-q~dx9<V>1bHMOvblj}lgC-B0-EmQ~4KbHTKR5cDXWj^?<a-Fl
z?S1gws%hUv&e`<+mskBqKessH^ss?1zIx)NCQAlvd3nYBHZh8_#h9+mn;DBk@>{G*
zou0UA^P(ot>kqiMT=?jhQ9UcS-wt){K9~MA^b65ge)Y|~4t8&!aoM)ibA%epK#gUf
z#xhW28K|)g9G;)EEaldMZk05=jPjEE<Qaee(@vhzr_@*m^G3xykeaS2aYnmb@`^}L
z{$5}06=dVl{iA5#x9r}?+P3Oqr>SS392n4d8~p`eG^QKSX70tGKZ{<yWMsh$oiwS1
zAO4iwap&=UYp)*GFFgO5GiluDuc)y+m-J1&`8OXu<MH*V><w`nCVRhbdF}J35(2wy
z&RXsE#u$DFzoe~8W7+SggT4y~4_~^s-<b|mO3!-j{yJ!AhU<h>55I2T?0V&?#ftI)
z{bGqN@%H0AuU*pLjOg3#>6nefn!HsfdvD`cM=LFE){bQmNL!e>El`m*LWyNS*Hpz9
zWS~2yLD~&@<(E$-DLhgb$gX@wSw1N&VJ8eU87hO&N$5~C1m&mLAZ?ALF{HB1zf<f3
zHSU2L_aIOTK5T+KC<XPK+w|#v0=vNf?{N?QDCR+Qr@G1?eRsR!jO9Q5?QQ>vx=J;^
z0^%p&0v=Gjh&~$V-M+v5M==njul_&t?QI?VRR`4qss&UFs1{Hypjtq+fNBBN0;&a6
z3;b_eK)S5ozHQD0eZW!~eFl~9uM4Z`zb<{)KWby@gD!o|rH{Du1^+w622f)H{5mFp
z!~>A>aj!7}8dI)tdpE{y9fC@orydND0^(ng0oM2t_(2k+LN*1o0vw4A-~wmC!3zI$
z@C9dHt^FVjj)OI^0USUF>5v63yz}c}6J&$L+Sfx86hIYNQxRJQE)7j_0`zDG6hj#}
z5g))0k{}f}!P#0d0{og1R{*l16e=KvYa}14z?!ySPsoA_!2Lx@hcd9YXZzqo<!=V$
zKn2EfZox4^2sl#b;0qy8#r3D5&f5n9!J2E+4TeA^^wH3t6N)>rtTXlii4m{~vZ1gm
z`*$VG2b}H3wz@M3A&>@{5bcJ-9<b;7*FhR&LZUmz1;wzEO6qc`1~=jX=wTCNLn$~=
zf$a>g{jmq6L&gBsg)(sSG{pnZqXtNUG{}H#$c3zdtTzaSa<In9q%LJo?n~;RT0pgc
zY5~;(ss&UFs1{Hypjtq+z`a|5S12X)FZchSrqxd;Hb4Nb^^rR546V)>1mM3p20$;R
zDQ|hachxc3z8&wbtr@)!ZOeO>@^M3j(ZPfm(8tUi8W|Vi6B89|^8X*fg1Za@c{QV%
z+1=Ka<=z$+CVzUyr}IwhZJ~?y3Jwo31rjjD0`MgL4ff@25i>1#WMpU*)9vxycSa{W
z%KU)nSgrn7CnkV^2SF^iBb^3q3v8P$o8krZVY)60YOgD6G*SB68cfHe+($;mm*3rN
zgKD!4X0tA@)XEHKN}A~XMjH&*>LusHVxl6<=3sei#m+|db(g^y2SJX*lZAhF91`O|
zj`xr9yx)`u#r8LOPNiN!23{?VdFD0Mm}i@U-{yIUHZ&+sr)T+Jm1nV~i)lYfe_N9+
z`<rd)B^M||L(aR{vMy@0<?r(46%;w`*Y+G?T=RGT?%30ZMfYM)DZYPX&t9Jx?ejZ(
zD%8cukOh+OZ6Nv1Go`Op1|;8c#OC<x?D=P9V8nr6=eg$E-DJ-5YIB~Kqi!9j&oHGY
z&pt8X5kWCCy|hFKG3A$Pn!62mVs~g*D)nUE7SX|BzZ|OZdXp8WgSSO+n2gIcXpKtQ
z;u<vWr1o`Hz;!P}eaeK~TYjX>%DpA<pz(NW6@XvgU!*?mF2kMsizmx#?k|Ci|Iz(L
z%FEsEFB<0mSvitplk4)g_m_WEwn|OMWxT)0H8QHubl&8CBh#-R`ej<|RC68+spFGj
z8^<DcT7in4qKod>NebK@Bgu9A|MNZgAK9qFbWFdy2NPh&IIQEpTz{!xhusXHnQUOb
z0guoo)ck_{v*lSAU3+CYzp}%-mFL>$y!LtWlZ-KZ092(ad%>POdLA|AQGOt`v9W`r
zLbN{jbbpZR-ji*Zt~XtD&6*sc@po_p%l@pKO6(jB=}gyPc+Dn^<!yy2Uw6u5hIzV_
zI#nr;Cu=RQece`?kJFFs%4vBFwqq?%Dwipmz69Gb|ET=>{{4^cEqD99mb|lR<ssny
z!F^SJ#U*dHw(>J#KBiy&R@+dIEyE^|mDj@qoP+G&<?WZ7m+^Wb-CYLbeNXb{!@}C<
zUCxahzbOw><(SPkQ`0j_Aj|&j+{iYZ?rb+C{+Aq?o>l(nI+67>ch-|<n_qsz<-FZA
z9qXNIsOCOm)tHqSc7h$qZ&`C}V>o6yZ!tlUu{wfFjWva1`qSqDIX|9k!;)>t^P6wb
zR2@Hi#{0gMO_OcH!l#9qp6A4d&D%@bXns6QdlB1;4NPfuQSppR{3UxikK}g_l4;7H
z@w{u8HpOiUH}1#z&UA1@G~-fEg|X%sRw;bPS%wJtZ9yla^~rDG=f-0;$FSo0K45xW
zkS;tlTpJQ#iURh_!@jI9Wh6mHem~s#-3erw{O;7ms~XM@#V#Ww<%<0!UR9j=dDlBm
zf9HCXbykvQlzAPN8CSa3=UrLfmG#Zn#GUQdl$E*~$;&U#%ks=Caj@i^#2TNa@4VXt
zn4YOk_kfkhjdoI8&G&@Y%+n6oP|BLm3DfeL->?O>rsX_TvVH3Z6-CQ~sK)YwbLMt!
z<&!s>yLCLZ=jDa{O5aUskvVJEgazBW^`F0UO%dm4prq?_d)eFXCH}l&W{}Gp!>e!i
zPCTFS$i&d1MY9cYnT~O3C5p1ZxV?w$TD|p2pL$njA05<0*}BF#xNE;AH+x2`Xw<2L
z)1s40c}P1zTaCst?6aih%4<EGyS|}KZaP2o@|z`rhi0`usde(%k~3z=MO)g8jr(2O
zszv=_eGm4!e{@d$83()0PkiiP(G>l%@xxY3Y|;JQ!jXJalLu*y<&u5D4d0)We_>|A
z<@}Rbl@3>PuY0{c?3?(5F+TB)iU)DbBWNqqSgP@`Cd8I{ESl>(PK}3^e6_<EH6E54
z59_aqhxM~g?k}B>A4%PG<)bm3jyKr9#U*5OmRtJh%N>ud&z!O9>GzvzX?NdmybpDs
zxMS%R55ETQjhWK?LerbeMh<N?pu@hK`gu3ME!~#cY$4x9pzT^?+4tGXst&VSpY$tp
zd~!jLvn6NrL)*UdY}$sEW7n)}+0JV^?~i>YUCb9YUP(#AtYRNKquny_YeVOuHv6}Y
zTy*BdT34&ez^*)41mXOpv1}dd)vA5FGc7WFXGMC4%t~Hv7~^v5%0>4@1>IT<YL$M8
zHuc_;?p&)m7ss?cko0Ufn~aYFx_`ZDd4YELn!(RJRsO>6$1aYuq1}9_q`Q$Y=V-*W
zcH?~BwCWw2kUVeTM@1)h*i^TxKeYes^Me`~6lJtA-HvIyTJ~FY`27`4)p%HHJgn2F
zZ;qSa@6cqY^6ySAdek%d>w^zCzA?`wUyX<L$tlnGcQ&|kE92m22VP(Oxx3fZhR>GV
zXhJ`j2i@d)JJ@om_T_=kuXJ_#bWe7-E*Gx8*VD$|W`3XQtI;tddJey$C>Hda;(2IR
z#*1y*&L49ucx=KH*YP$-_h&V<)1RH-Qg(I8_Llhv6{XEENw@noyO4>eN8Ij_GGj^5
zrS4~9s(L<uriDdzaVOo|_Uk8j;U7C((k0IClheP>5~tFe_WjhjS!&#@C;fhUIXcGk
z#O^PbXVg!~T{ZDQ%BD}P_fZKj*Z6$jXxQu8l=G#9$F4s1Y-m=qd0pNM?pr_MVCwcP
zhrZe{HExy~H%pD1HEf{ImGIyX-+ld+=dSl#nAp~FQ19=*U8ly)QsZW+akJF8S!&!Y
zdG1UP%q?D$^y9h1KNL;W=1*|`YV)y{V-ik9?<jihJH@KmC)91*OS&744tah2y5?}n
zqa}6rp8DdP|5s0b<?lc0$8DPEPMzW=%u<xsM@hPX$D^yPqkH}smp8M)0?!}1=6&aq
z7Z~*Ug4^-iyY}j?#?4aWW~p(r)VNt{+^l9ZZss(3quuE%ZqJ<TdhC&b``>lC^!-C+
z+x=bs8{=kCO<B`_PLY0f5;selDW&aB23;M+ApJZd&_~cnl<HX}3YGS{ICLq>_h}5z
zp)=8RbT+yRor~t7^U>qz0`wfZ2$lYOi_yzW%eKsY*c9p8Ci#%ACPP35FVaa<{}>dP
zEoCe^8udY^puXtS=mb>y#66D6cKd+2pP8}$nQWI=b%iEG<FJl&vfUR@M|3?(vzn4_
zUZ3V-CEDD7O!|q*`naqq{vbmO3)A{7QOQ>;l%HFrHJXUFL6cDp`VRUqT8KKMKcjrN
z*C74Qx}cI@X~#GB<1)61%l@pHM|G5OI7d3k?|D@AcLA0CT|{Mn73i~QC7O<2L1}ta
zuA;L2Krr{YQdToA+n4S6f(*kfP1_%i(iEwTLa9DiMx&F^F=#M47F~jRqtBq@(B<fO
zRQ6NAF`4^L8T(Ype#E6Lm-#Yyksm2nV^AqqV^Jwr-l&v?$5AO)lTayFPoNu7e^l%^
z6|F?I=xsC<ZNRp}P;9O|jdn*P(NSm=%C?mlGzg7DpG6bUjp$7DRWuR(0G)##M(3hM
z=zR1m6yHh159kuK8cjy6>nIA_GPFVQt29hP*P<b48p<`JtViYB%rBypHDwdJ1<gR;
zLbsqFpj*+yDE+GpN6}Z%E9efiu_gT_(AMZ1Xh(Dx+7o>f?Tx;Jjzr%@eNpUf2t?mQ
zr=of2v*?HDW^_NAgL1wM@1vif2T_jMAbsGDpmIJl!Q98o*!N4$rycX8jLFcL>qXAz
zeW;wzCa9cG8&uBc1E`$O7O0%hmZ+T1R_L4PL+BT%6Z#|C4pp#k2eb~_5q$)8K?k8-
zQObnkigK<MH&ptf^+YAV(O~Y6rL1FI@+;jqLO=#5%Bht5_NbI|Y-x-K*ctU^8h=>B
zlV}%Iw)F@q{Xe>*a(%g?E79&~D%t~;{mQj&?qg-_dnNmA!aTV)WymIfGQA6>xk=&N
z8?UQ9sNBciK_!pxqB=AejYRjN3(<Y(7L>AL*p7aPzKZTg-$oChd(nfa<VWr&=DtwI
zami2Z`^jn2$#f|ycK8-`MZZHwpx>i%?>U2xMbDzr$Lbs^+YbYCe<o!U<FfsRs6WVX
zn{={WOYGATwL<%%_0fr_H98q>h-%R$=xVen`aEijO1~*PRQ4w}H}?@T_8pS_HDz8B
z$Z(#;cIXdiOY|b@j8>qJqL<J>^e1#0dIep8UPTw9*U)6N3SEI-M`iyv&@E^+`U-jr
z%|f~N81uz_q^2K_v44-`%Z24S=F9K|>Dr={DMNRZb8Hxba?Hl_8;;IpnsaWvJ|fVa
zOmprH$IuwG6y<l>cs=kNXK2l~XQIyNEVL8KHVkg)e6&A`T@2hKrCb`ghbdfxhGpn7
zbUFGg%DqZ{3k>T}u1y2?67d-~ypOI!_n{lmgXm`T82U0=f^J3Ia(|*M8r)HAV;G3;
zK>g6y&;XQUF+7FxOkj|2*}aAG8>_sBzKZ6dpP~EFpV0#J7J3jB-}FM1Yfd?gK8_wi
zrT^4tXsOtmi^muAuoAMN2r9uIqq~7G=pYHwVGk5TIameY2M(?<0{lS_DUboVPz>c@
z6{sj0@Bm+khGZxtKj~-=6hS#y2az}M1YZb)WXOU-s090|<PXxnAm2~`<=}7}KkiWS
zrLU{FxztrW(L^+dw0&6S3n`$+=~Ux%29DxFfK8AGrJ%;?<T{ocFZ^GP(<w1JE8*-Z
z?mPAP{aMJf1loridkR_xl`w*7xBA@Mz-bZp5!46GMFUakw;#y;<E}9}o7DZ&IGsri
zcvk+3=UX%r_CQUX&P2AG(2)IFaj!&k;Ot`JSfF(ORUDRZUxgIXWkC^Cf@2)_H1G!l
zY=S%}1*;i#6=xU%37`(D1yl>D7EmpqT0pgcYJvX?7U1>uSMmS8V|r*?MY-ID`UmLg
z$g>-I1!{(2EEiuL@x7_n&Ey|6yA}1Iq@51pA0vbKbNN9{JV95+yF(}F3^MdUdqZFI
zbX^V4g|<A4Q8AIwlIJqE-x$PS#sVs-__+dCL54ca6Mri4ld=+pS>#20o|-T&KF2Xk
zN3=HifHq><2E_k6mif^z9TXeI=zCq0*ZWy6zKHQG6aT)N_4Q1P5A1nco@F~I$~30q
zAPU6qQ09xD<qW2`GA@3835+*mp7_<xWc>ef+{A_)!?pVr<!7iF>^OJ#o6ny;+RQvI
z%MW9d7ObPjPyBWKL@6s0Ls81(y~a=+fj#{o3=)896=}0kd?5s)fwlpu?^n_x3ray^
zQlx^!Wsv%L2hc$RB!R>}r~rwpsD~s-g*0Ai%Ap!0uA)6Sfg20~e~>tfxljmIFoJhD
zKL~+nNQ9NJ3FJMm0E(dutgYE5IDsp8f)9xA@=C~tJs>d}i=h-MKpKM_!3Fxj2nd4&
zkas|N|I3CVD2FPr;vLT(+`tojAR3Y&6>`9#5!(TY@0bC3joB9sjV|B;Rp8tNdqW8H
zp;9*t65uR2a88{e5wai`JZ#wq$UQ9&eC?QqR5%XSTt^OIZBJV8f+Wa+GN=SM%1Icc
zLIz|*l>>Hbfvq775+EIlfIuON4P-sYHlPw*xF*w}1j?ZbthpCuKsh*ae{=!Ahgc7C
zp^E#v>%*L9(1DW^<Ddh@nLqG@FtF)J{=o~X!Lt)Kh7vcH^`xAFKaFb=KXMNg_htX?
z96MC>V_P2B6Le4$KQf^|#|nAi=t<dxO^^*qLnw1l0%=1zMz9)29v~4iVGo=I&2Wwb
z`i#JakO5gESr^K|V-)*^L`a5IkUFX?*aP`c1bL&`w-*Y^81e+ZoMXAiPekSZJ_eOo
z1LA`tzXO9&`5hT<p6`LmZ_;Q~em~sI)9z+<Mddf_K2-c}`<dr^p|V|dP%WTZK(&Bs
z0o4Mk1yl?CyB4rw1Cjr7{J-$XaD6yoKxS!UV*L{$^!`y(p9+o9`UgdX^m6kz#|5dC
z$QTBYIB_1f7J)od5d^)ZQpV$cjgAQqj){tm3e{_z$9L3tN9)5Q!e@m?PSXsIiii%^
zX=CWm<768UFe5l1NUx6xpBksv#u7io$u>-@i`K@}o=e>X^Mmv{_95#8$LIrM^@M8)
zhzN=#o=}7~Qg2EVs}G@>$jNqMcqBnRV(AOxWIK#NeT2pfkBT&<88~R<pQQ1!-67BG
z*t3*pZ#8~LJ+DKD&byD?wZ72u%6RLyKAh{kb|%lo19={|EShd}=33ed7q4CXVordc
zcmMC3UOw!X+p_nV=w>Y)a<+!>{5@FGSx%UB+w$`^ujXbHY<bOT`;S3h4_%L3G-{gr
z;-iBj+!yZV+1t3ig%0&Y<8N%9QI>k)!xvuJ*Jkhfj~zE3eR}t@lETjd%g@ErM~n9a
zjb+<b8)Eim*^kw|(D6`aqZMy#x%PS9zNPP7dScC#{SS3)Tuyxw&-5Bgk0mFc{h{QW
z2W_|JHW+g3^mk1TEjwV{Z@^@&Z->_N8tv!(%aivkjb&Lv(2P!_$88QvU%GDQ(w1|>
zdZ_U`#4gWuIoMi_-{IBx<A!Sdj=v^;$8?>PtH?&vy*l@fTUk6_lkMF&WUc+)y56S;
ze)G0XR`T%5(1ST@{0=pKhZ?^_jo;zX;8?uhl^aFWIS!Kh#_0R{?dx;?)#d+w{0=oP
z$BO%3uDiuLb;T!HtLMMd?&)^(I}YARpKz&XwfuCTwmNU{@(GXVx-7JM@y$jp4V4Gy
z&Mt^PxwPZCwdHDD4mB>vyX}*&o_&q>Uh4fdmQx+;jL*#MHoxcU{OwOVxIZ%MyC-k#
zoxSw<;@9USPp=;1L%A|uzinFg`E=H+7YC_vIn=luYFv&*$?09^udA{=oK9Ptw5?hC
zt)6tB8ka+j%b~{QP~&pQ{XmV&aV&IYxaWp7k=NIh?A&LKj~9I)G?v{;rr+MSA+CR7
z&sV!{{otv!Q|FEQWbVjQM?O&+`Mk4rC+R-#Bk7a^{oC_ja(blfhYwmmb?&L~FJ6fb
z?XsZpk2hZZ^!%drmSyx8pf7;N@`s`;>q6@<Kd;8+P~&o_aXHku9Dkp<9Le+v{BQPW
z{jLA1UkpBBv?C?azUN3gmK%6M7$ibE<U%o2gZ(V*16~jfD<KOCp&YDd)BmhD<4_Iq
z@hfNWgJ?*GG{}TpD28&d?n~Pf_=6rY$WI{@F<u4IpUwk9AO&)u3~cCQ=K&#*4B2oT
ztmtp&0=|$4()TVO%AxV2tOH??4B0YGU%W6#1!VyF012WX-*hej8&C2FVUP-WP!0~X
z(|LjpRzfzEf(`HYo)7}5kOybMp7uWv&_O!nK?ziYBW-ye;17wA4!KYQ)!;~9Ko9VT
zL`a8RC;^3fDkm5L1yBmr;6wjFJ*<R$s04fZ2}&QqYS7UC&l3W{0Gl8WN<sBu#nw;!
z@B6UkI&d8%a*pP34MF8x&gDG%eOht78YpvUHJUk}KBtUZ)ukLjIuwKWvEHi>tJezd
z1@$RQi`XvegG&GA8b8)*#vOT{bO8@2W_c=_2W4QjnEas{)D`~7Z}nb$Rw>o$pjtq+
zfNBBN0;&a63#b-QEudOJwSZ~?)dH#o{-Fixu=MtAa}paxS<dMHW&iYl<eM%>`CI>V
z@%wK8Wwxr1y4YtWzR2s$zWw&tMSRrn)jvIi_347EltKj%Z&hL<OWb8e;>r%Oq>c?X
zK{kk=c@E@*8+9)sK*%kn0IEQI&Xb`Cs-ZD;Dx07PN<sX_eIZ1&0cjx(#P3_;ez}79
zdK*CeyGx-0s$mHJ+tH8#IdB{r<HPL%UT~IU*H9*WAq3LF8h>ps@P`o4g9P$)#9kqg
z3K>xJ0C{W9F+ntSQkhT;WgtG<#ZU$k7h)3>K`A7+CNGc=`Zo9;Ljm}9Vi}}CacA=7
z!m)u@SN0DpA*>tQf@~-QhwjuTLq!kNjXE$$rLRaiIP_v3R8wC(gt}p0bN#T6`rt&!
zflAO&2kZ)gkOr9`b-<1LbIjm0fOR1Ra-a+<LGdIFIDiwlf(N)z-|ILC1sx=VI;a*<
zEudOJwSZ~?)dH#oR12sUP%ZF3X8~Tll&Ah>|9_K*|L;BjBjR-W@ToKPT76V}c!)MQ
zEGWk0`u|_;`|qwawUsj`-yD$Pd1wr)Acgm}Qu~Gqi$cS7dO{UMOvO0Cu>qmFplPv6
zYsJon*TcIFp1jTx<G|KdgYISz-WI`8A=-dwf*26nz}D88`KOKZ&7l^|+pMG1QwAwE
zEa4rD_iY)T1YS>-Nw9%DZE9xBQ$RqF#77t-=WP(@%{OWy=WQ_OjdYT?5$IipJ9+bA
zVH|i{3?^?rk~L$V{g~I*I6owQnDIzud$zWL%uBJ8^t$LfdwonVyE7hB7^(-3b?Tkv
z=4H|7bm{|S-I{F5s$z?TU)Bo_t69iA*{3UNvXki)XhY0~V!qgyS7c+{NN<Z6Z7h~x
zl2{OZZGSM?$Y?LIX(jWmA5>#JRG(F2JQQ@~J7UypXe`%9?w$A6uC8a!KkacQDzW{A
z)X)WvPC+-ON6-4;n^awWf2yR0NV@SG4o}a2{)^c*qZcjFX^(&YeXCg)y1Y0#WS@oo
zs+*5T+3<Z7`U7e#69;HFrtP|<U)pW-=L75cJ!%oMrbp?(^`Q@U_72%qHJKaBa_Ubs
zmYJnj6~~0p?k8^Lcm<t!+V7*-(EQkiE}3tfpHk`<pTot{g}NS%rDIOftcRY>_n6r;
zr`yh;Vbx6^?O5FJ$m&ZSC)I5=HGla;Vq~yyjpgb~4mS-UCvQ(4wYTZesE<?D#=IZA
zc3l4j!ISciKEK7enwXVCC7l}M;iHG2bW&qHWL14Q;jfAD&?`d9)dw5b72MbVM%Asp
zmyRu5QFc8rpdz)0#r{_Bc-;S5e<!O7HO7M)<3Ww_pvHLk&&7DKpv_BTxnx$xi*4G@
zA9E~tY{C@R@is^IXEn6bpPk@Rc6G`2miY(yZsssaxBE4_kcp>9-0qPwV@c4Z?q_1E
zdOm-qg++F8C*9lj>nC{eTs&OTCC=}Y)4$FVr_!7D{k}=}{A%*!J};M6#XcU|DgNXR
zhiN<u_v8UoW7&H9=5ISiT~6CE(<-R(ejDcl+jqwFePLqy_J(%%J=n6GbnhCsx2*T-
zf~n1}^%{K3c1&jRyqAu|m4ETskVjf8otLdi`l2uGFk#00*%xawuhzNT*UNXp)p>Sn
zAFm!ix&4lG*L6p)o)~=Kh7av%gK5jrSSA^g?7zG`e?~y-fF-k!X2sVjc38N4<7R!`
z)*o$6Sifj5--k2i@0G}wnr0v552%Q^{iPZU!j5OAK-$DKmMiq%_&yVu`f~Ev@VJ{!
zyGHgIHqKL9Ij4Q->BkP8AG+tfq8v3oCocW?i&x&cHQ8N_1);`*xI9DIv94wDo?RQ-
zTJ4@Zs=C6ir&UG&gl5AkDkxX=X`dygO6IpyBi^wMTetRj_2-kP+^Ed`ae3*6FUro&
zS7Sk_u^`k~5OE<FuTHsb{p0-su8-NDd12GR<fSvWD{3qVH5P;#3qpQB)L0N|EC?wF
zACFyrJ*w`!uX3&QduRAxbpLwJx1&0@`Q*sjNwE)IK2pXzMO#NnSJhVEeskR`r@KE{
z-Zpl~rZqiWAK&=?tiaeew_VU=zct}?`sNwy6VDFWAEO%-8*y#O&|SgfN-VxvUwCoO
z#PgaJ@oFpxH5P;#3*zq+3*s{EVbVTmZr?Pvd&;-vX`)l;GHM)XqcqTDq0n4nFreIS
z3`yt&RQjCLPH0$#iW|9X&lAjTlg2hn*&criRS?D@gmlu5sYN@W(@?ghM5EHSIUP-5
zg}+mb3N=0j<&C;5H9iH`&L~BVPr;4Ah8s#B`2Qh3#eXU`Mc#4x-gC39`Nn$wHLE}U
z&iemke2R3wjh?4|ADv$%bx<v!T0pgcY5~;(ss&UFs1{Hy@V{$;I_$o-|9=|OR`fBE
zzS+;yKV15VpQ5j`^qU?4wdYG;^!e>gecMY&^LL6HpnlK(*RcX5PJon+dyN$!b%74h
z2c+(hdOIZ%k|7mxARmgL6e_?T=ZOR;fJ(5U@M`dD2!s?!2R|#e0X1<2<Qw)9PvAI=
z;2k*uB&I+KNIU^YNC){Iy^S^7gB*|;jS`<xzAs<%ZTYZ<q=hUf1N%n!&x0?>H{%PS
z60A5l8}MsNj04yM1yBwe8)8L5AXIbxxM8y}NPujRSOS3%4UO&DHputjQz4Id0`?fq
z2?AT-lMneI@dQ#@G7iNM)|ztzc~AriZHP+%IS``Z9KjwK(wSwD4EbE=HeJXcc(}5E
zFo0iowgsD@7_5mW-~gp=Xiwq@KoadiC16dzbq6SS=eUR;Fa)Fm*dOG(?io-9Hqu`T
zd_dyLropEE*aI5VZ_VD5b-@=hpcu-a0;<7!AZb7YH8BMm55{)j4+&s}edXRI-%%Ie
z8+A}Epjtq+fNBBN0;&a63#b-QEudO}=VXlV<iG6yAEph8{=N6V%nb+&iVV?djb8um
ziifR5puEf7kB@d)wDlbw6CNBB6&n?**Eo;wsPT^0hew3Z3Xhzo85|W69j?>HD0YgI
zZ9u?`;D8{#J|=u>oL(D?ueOtIm{u2!6Me0@(%;0%Hb}2yAF_`4v&ZU#^xA-kph*1D
zBeaovQ<_+P2;t$JY$t|ChD623;^XaPJ1i<LG9*YJ9u;XyGjPzzKS|?dyMuSKUS|LL
zG~P#L@CC7{H>B`>=V{SMVUgLtewtP<#$lQG)XTf?T?V61z4)2;H*Z_w=*iF?WZMsc
z_?=|`YTIVt|L|GbfLi--Chc7Y<37Z<J;$^SV_s|TQ{wf>U<a~K4n=v4chb^d?K3X&
zw|kZ2BI(_RJFx<ItyVU(L2rwIfY7Lzh#;M!$i8cAS!UjMZCfT%zogVL*%B)n57Au4
z?#Y&wtX|5yv6gp3jpYUB%<bCBCvP-&>v(F<%M1IJzMIk_bJng23$}IZKY!<%BKkt|
zZmF^Cb9>p_?<M}cVP=ra8^fz__f9;Y@yNu`qD8X}ahZ;BX(fuXz_`7K>{`9`NuPRG
zW*;5YMA^E=Ik;=TCO3OVtZ3A!gVUmuOSdV?0p4*nmSLYIEmvOa;oS8NZF1B3p_kt*
z2|P5b{YkBp&z77qLoQ;I+s6H_ZPlXwu)YU--9I{~{)~fN=O;dPuxN^Y+4x~ACbsDQ
zZsAD2i^{t)K5F}d8@@j$|H90K%lRj>DjlxoUiW%?*f;S9V|?Np6%XQ=NASL_u}tmK
z$ne7)hsbk1RiFLmK2m-5z0be$?ufp&5%<kqI{h)PadS32d!o}Yt9e@#Wy}yMFYS(`
zZ(O%}RnIe*cBRBOPdiy@@!DL)XZc3=iEdx6?YVWgqHHym=ailsy4-$djBix`!=K$s
z4L+T*VD#;e3--4@wBlmLBXeKlMm58@y(*i)&*rvT9~fF#G4i@gqw94}%sW12>U-6R
zmTfl#f4BET?rFwyI{c@#o$PGC-ICRP=Ze=_E*O)&q-4%VQ;&>4SNQ7sj`LotFn#Ao
zWBJG<9mY+*HO#5!mA0C;-@RUvw54f-0ZVp#GiT512hM9;-cpoqW8^r}-#hqhz3-oz
z+3Dk*zTF0%`abY&)n{Mq^4Iz7>my`)Ek4^4akKfd%e`z?)p`5HPJ3VK_M*)x>w5lg
zynd@}kY@EOs?Waav#<K>t3LbxIiG#i7hm<oSAFpVzF*rWai_=oPVY5;_2Mf_4?R@o
zJ!Q_V<!u$EJ8g0JfHk>)?!2l+3$8ulb4$O{dt$6lm$n-d9v++NuKMDuzW5DZO|N`<
zYWA0hd2y8Qg=#G4Ti+VcU|pbvcdsLFd^zZeg$vFd@B5Wo{15dm&3AsG-l76xm3d0K
zbvNf<SAFqSUwqXUe{%DNKR<fv(dF%0&(5F5wc*=Kt`F50U-iY8a-jO+tG@VB4pd+K
z0}H-SaqE?q9r^LR^_%)C%8$n9jaKIlwfSjh+2QSp+JHG(fz88@oSoyiX4kk&5d+4R
zHw!;Y{U3eHG?v-pt**`=(`t6&wvIWi2CgnDi*I{rYTnMHZLg=k|GdxZ!Nf=#E$I?&
zPM)s%;;X*+e=lErX;(D2I~v;~#dluX@M^k2c2g9COw*myFao7Jr$O2)-O$UZ%rmzw
z8rvLy>&yQD>12JnqZ*`LknX4kX`Z7Ss(~)13gZT8qjW@Ndy*e>yP>f?@wfRQtwFZO
zYpQ`RvdY7#Y}W~`S>N3Dch}>Qm;$nXCsguIcUI%^aJ+_8j$MrbK;P<_^j(HrD28gV
zpM`C}3!-5qWI-X6gY|6s^-6zUs0L}Ub_PF)hGa;COvr^|C<p7llt1tXJ!EiB3ZaPc
zDsXV8TQGz`3gkc;$UCP8gg`Q6!*Q^pZO8?DArUq~K9oaa+Mzrk45Tlye4k8>0YJeY
zrN#iroy2$i;O`Ivptk?N8@>!l;IxSA0rf$1(Ll5i{ZIP-SBWnHz7fUXu!QeUKsmnu
zjpOSoZr~4zpbn}9R12sUP%WTZK(&Bs0o4Mk1yl?C&s(4lyR7a1pDJ0P2e<U4FtjrD
zVXtFn>ia#PY3a8ueX$oXJ`Yr%f73Z@X-~Zu)C_GH*O;f9(Qm#v)C@fs?`fWHj-4Gq
zhThEUYo0$89bq0Hi~5+yebEW#@kyw^d3-9WHILU}d*c6GGt6Utl6hHu=3ASW>6jO3
zo-b+jjK`a&8<9qQr)5~iycF~NmFPP2xcL0vtG~ZB+i?J@Y!ol>gD_YL>5v6dM|2jv
zESLx4=YJe3DWq<eyuU&;xKP>W58~&a20C6R(;*8S>#;ugLpGE`1w`}Sy9dP2zY>zk
z&>kp&#`ySqfR`xmt<hkBJ#ZEr8d2{BVUP~u=YJf^z=aA+@$*lCbjX8BaKd(OP{j3O
z&Gq8}UXTP8;D!x{Kq)v=PW&JYQmIru3svCOf@1^m^Us99mW)Ftc(kUT3{oKjyr_5;
zKmTOtqv0Bb6maOwGVq5q7xE01VB^aE!53V*vn|j=CX_%q<hY?w4Suv^XM_0pmqQ-)
zb=K6)IY2SEa$-Fp0rr6S`B#F|qwE`Wpzn`8pcKvyU|mm+9TFfD_CP)qK?$6NN+=u1
zKIoHD22O+757fi9;*TO_UG7y4K<-NoQSrM`2h{?q1yl>D7EmpqT0pgcY5~;(ss(;;
z0bZY!$bZ@YKRl8z*+&NHejfuMmQTm?ef2x;;YQbbV>AFo`EQN~Fv#q)ZzB~e47Z^P
z{0!mUc(*kBum=Q5d;)EPHkgnGznDoI6KjeMFoN`V8H_&kc6_VehlNpW&)Xt2JSJ98
zzZzRxd8anb(*-fhI8Vd8P-D7q=9s=`Uuw#O63u*x0T5_u^s855nHE3%Vdi6~@xxzg
zTu)IJp>hn_ru62R1~tb}I~IT(#b0+E4=9$l_Smxsv~2gVIlpqu8m4O>pX6VTsk7Cu
zkExP$s{g<0{~wdB`u}$rqx%0JIGUxL3|5pkdq_Xw8~T|m8#ty!jy<09X-<<PV|N^l
z8{Vu}{h=>z`0AQt$OUfVzSMDPEEDy1r+vEaKHs<T^Iv>YRd@4d+rahD?YWtwuj_g3
znG^Yksjo6_Z|*Ah9-bH1^q92m#ZN!Vj4kMOWBsBH6WU#yGvfG*pKZRue$$4?_M(<=
zKN<Ft_wcz38r5y^*@KsczB8v?pVBeQ>$e`YWKcl2t%~xkyQJ%|a_q_mee~&e8Ar|x
zeEnERi=`7c4|m#k>ZtChYg?z&?WvbH=I@64Yd>}$Jw-X(@Tsqx*D3jM-&fk78`>Or
zC8x*JYme@zT%#zD43+Kub^iZf8vXw_9{ITbk6%`<zSM5;%!+N>zFua~?Q;26zih+e
z6swX2&A3VLr!G)q*?r=UrB^)s8oW1VO7ja%Z!Q}-wAFwP`)=yz-Tbz6TV}I`)Gbpl
zsIlz(Y-Lr4S*=g{l{r4SpvT#gGy0)z-+4A|!^*L1*0pTsHJ!TAzLGBH3mdPbq+wRE
zkDbwO8ThrK^H7`p+eR)rb7HNlRb^n;EJX<-J}KYSj`eEQzTKG?8NRb3y+dXtFE@;F
zxpn2D`=WwwEe5qpzr=3?{Tnrw=UUCVIHv7^q-VR?WPB9R{p(fB3$(-641VUR@)veL
zc5xhai@8So-AI^oG~!yjaXxQa^$tx)o;UELqLVvps@v5c+JE->K@ALwGTNAK$FyB7
z`>i_s{)(om|G(=0uloP1{{Py{t935-_41u?b)MbY$E(LrZoeblb=}dcCk7w5;X}LB
zVA@7BmPv*r`!6rgpApbHV9D&GS@Cs>9TqO%xLIGf^+#J1)-T%2ck<jM-7AqTHO)TA
zA5al-`%BgTU-kc2{r}U(ra$Kxq$r;lpCitVA9!He)J3;GIP&WBs`KxszJ9teZkc!S
zN6ue`PhQ|RX*Vy0yl87IKfE%&LiPVw{r^jq56)cdxTeLAZNi3r9CY})_k8;=&mP<K
zo=c~Vx}bA|i|AwEDdi<)pMCkd$v-Te;@xy?Xvgl0UtSa%UA0m5|5yG0RsVmvKF%)d
z@PPg4oCAhWqvK}X9yEF2Y}Nl??4tVrtN#B|4pjet)&F10!SQP^Dj%Kby18fAp-)1R
zw_U3L=7MG}yQjEjg|@e7(aQOIML98A(!E>d-uJWPJqES8eWR-M4MW>4HbLiuu8pkr
zshSmfHf0-q>zutL-987uqV~$-@3uNt<aO!U<A?Hyu^->>q5A*-z5M^Pd95+GGaB0;
z#ozvZ=4F5kv_~4GO_FY^hL$MRnnr(p(irF_s@S8$(Ff4+C|ywvz9?N#4RcV|G0a2h
zZfTg0wnmquZO~Py6S@O+Mn6KuKYu^UwhdQNx}O@V&__^d7ww8(M#I3|wx~#(qvX3G
z>JKtdm21p*FI4hPm92q&)1Ists7{x@#Reag%fXm$UIC5y^F*myR_H!zScDEnQ`oi|
z7l1yqGwHVsYFq%W0}6^Kgh49gK{+_k|JW0BuoAMN6l^F^o)7}5kOybMo&x3pI!K2+
zD1mBlq@a3$KO{mr<U$ElgX2(^gFhrfI^;qL&@it!!3ZdTQm6(WE>=CPgnXz3d+Iex
zMzS0<qsS)&f*Kb9drsm!ff^S8ThymqEV_GKfSicBN-@h)ttrDG-$b-pO!-1Js4FCV
z#d7>6GGPxCvyR-fZ6E=htoYqQbKorLe;XS>GpDZN1?r$$K(&Bs0o4Mk1yl>D7Empq
zT0phHf8GLh*hOvs{}-8l^CA9GDJ1<VzSqzv+|J}{dyesPsDPSb4{4?Ubr?wB@FlHG
zebA+Ex%4MbX8ON1Mu5GeqBMh=p&1ot4?xXei~a5g8UC*E0i^s$xw+Rk0aSq);{!;Y
zUl`~i306WrSX)p(0um#@4?;i>NstA5ARmgL8UiWc*-!%IV9opJ2+%_kc=GBQ4K?ut
z4E0D4dEhGV#vri+@<HMTSn=+g1cguq*1YqkLm`xahWA__2o!BZT1bULs0NqD<R20t
z8%m%Ys=$-7qJvG44aHz>i$6b%fHJN_M=EJuAOwoQp7Q1dd0<UEhCVO?^aNWdfa73K
zWvLe=Kr(nzahm|i;7FzI5YR&sxM;8|gn`3D)I)&|B(9%}3weixF4zN#p~98@bDg_E
z;~s1ad?6Wfp%7B3xGjVd=tHILO2~ym*wl}D0jPo;DsXM6yw!joq(MFugH?a_4PM|o
z0Q*256nL^OSPx_!NQN}X0I8?Tg#suBsk1AGl0od-Tqox^ggk*<r*i*lYF0%ZR12sU
zP%WTZK(&Bs0o4Mk1yl?C7g~T<Amzz_+5cY`6&$3~{@(jv-2NluBK}7H{y7$=!toix
zYoKxn7V~bT%xb8x$m}a`vR6Q8j8+?feY7#*!6a!-O^Y*nm%-@o-vmE*+0-`b8oVuZ
zN^KwgV%}+Gn7})%^ywLmZsk4BX7*k7dnX#hFMF4Lrx~~KyMK3L4P>+E4DUtW7SS9)
zIN#~8wH?7cJKmAWPjFP^3^|&B7;R{9R9vLIvKwO$NS<ZF+ag9Q+M4wO(dowZg7q;o
zP4<WkiqJBfenqCZ1~uEQy}<`q7Dk#MjrovlM21E&EinN4pk~{MIgR$|t~BM1nf+VJ
zf0l!sm(8GS&Aa1#qkTfd69T5iM8!piM@}=I2VR%&HW+OodC;&l+L-@4tI<!&()Kv#
zL1Gi~N~}Dzz_@K=-ehB@^!kWs#^u}zm5f{S{;eI%`>y2$=gjTe$|r9$ck6g+&&vz@
zmA;$OB6HTR2@AG$>py?znj*f9!h5U6vd`^hZ@-uL^M;v0E^iF4zTG?Ve8wXaLyH#8
zHpFE*#-)`Im(#ethwNIt^+}(4S7sj_)I{03#yPlaza}?(MyzPmse{v^lS?ti0p6)K
zmSLYIEmvOa;oS8NZF1B3p_kt*2|P5b{YkBp&z77qLoQ;$+s6H_ZPlXwu)YU--9I{~
z{)~fN=O;dPuxN^Y+4x~ACbsDQZsABpd58CMjpdSk!42P^lYe1m!sYyvS(Oe~bFX{7
zJ?xwKgE2nwjU<GhGJ<z}jb&<=Mus2eI7F)P2-J84$ye2Q1Rpn4;}Jya-Or7@@c6~o
z2l>6R;M2_RN8j${I&J5qmnZH#@`9qQGTvXTPu*TrZn)IBSy=CP4|_kKYPhxO+fLSB
zewDcIslx}YS0ACCIYRC)DfjmYIvwHF|J<|7KC4b2AK3GhTMOGq-mpua@X7m*-u(`!
z@d(s-1Zq42H6Fo#E*^meZ7@6!&B}POP22fnjs=fRnBqF#=IH*chIab16I{x!F4^8P
z{~&$lhe^8Kui1r6JU!xekCYipf-ZGG6I0dm`7<pnvWq+E-nL&q!Anu%hD*A{`F(Qw
z*ID9Jdegq&H|d^VO@7?x<<hFy$3r{CpWNXvjrO6QZj!F`_RZgRin^S(W2RM5<NY?y
z2e$8w>HEUO^z9Ap?t8FhIqBXtZf{xd)df?VUF$XYmhG6#;(0F}i7Wr&vmuYPRyr?R
zlk`Pj+E>Di`Li!p;}$qHdT#xK=_@;@d1SBSUB&qPymw3eBi@gA)_K&;>+Qh@Pb|G0
zaW-RKzor3M;bS!IrnkIAyOO({k1h8#x$^0`h~QBJFTSu=pKd>0Tcy>VzA)uVzYn~Y
zo>b!&sBsI_xCPa7t8RU8xMcOig%_X5x%R}Z`-g?^dVSQ5C%;<|!8@q0r(8$r*Uo+Y
z$(#O(JzFoi{Y2WgQ+MA!InJ?%8n-}=TcEFOJIXtw$KyBki`pNfuflg!P-!fO?0xV}
zhcmA4G%6ihIcj*%#V=Z4J2q;Mf5!#U@z!?Lw+++}8Pln83)Hv;QeM=!1+!1|PHz#v
z^4o`x_nsO37SE@njrZNa+~OrkKb|}ML(xQS{siZ*HXmy_CgD`{j-uDTQ>>bOLOra#
zq`T4Rkk`krYYvw@T2g24sV~m?fA!>7{{EwW+@^`{)G2PlEJb;Jl%xxIJi5v{y62B^
zc{3X<@cf}`-gho}fkB@yxE;T}Yp?E!R7h)$@B90o+Os9NW%vHsJ2zY${pFF5u1(qL
z(WUZ*wyWYpZyldJfZv59#_e?+w#v_LR^01LK5G(o)1%<*4ZGN(rRTQCug(l=_t86#
zeV{0x;xx*0cH1|+_GS)xDK>n`PbnLI@R{*l%L<2J>p?GdcyI42tNM}j0U9gm_D!1f
zLvW|;%X2y(>=zb$$T@be8n-~~qQ)&y;}%FcP~#T7Ir6QvI>VipXKpsMJk^T!B^seL
zmZjHU3>e&EP;k3b?~jTY`*6o+FRZt&_v6S5y61LmC_i)G0!6uGd~fV^)9RhxuYBt1
zwdaxBZ@;|Q?aeytqUyh3@z87M$E~_j>2!m>kPpcA{$6nll4&0@x0fo?jw=5D(x#ax
z^BIoezASBcpQF;a_XUcXloMzN^h>laN;8;&pDpDS`XqW9mA1E1bRqf;`W*T#nu&gg
zzJq>`O1teD^fD^n9y7P28rxSTKhoA%$b1>RNhkRmhe|$tQJP+ri74G<<r`-Py1Xh+
zpwrPHbTc{?%|fT4R7EQ~v=`gt=f^M<rCrnDjk1p62{aa+g(jfoC_kfy8|ZAbVI8A=
z3=$uGF4JvLj?wTax(JOxm!L19&!ET96tsb*qCAT}impP3pli^vXev4d#YP4l`aC)t
zU5hS4UqIKO>(S@Xm(dr|40H#&1>K8oMGv9d&{HV3He5hoL95VLQH2f&*uu~V-GSbR
z?m{0xbI>;En`meBU33ci9=aXPLr<a~qLpYqdLQR#Kl%__fc8YOv0)^75S8}vLR8ML
zls9ubu(5skx8?0Y(n)!H7;S;JN9oRNjB7Cz?a1_av=hp?m$qL+5GwI3o<h5$oHK=W
z4A@$6Lsz1dA;SigvT7_3?lPZz{Wr&>$g-}h<V@w*k8_<s3KYfD=NvmY&crt01!17Z
zq~Kbj?zI4HJQX!21vm2y$b)jQ_oBRjA0$Es6hJxHjKOaMd_V^&kOc)$3RYveeqjWJ
zfdSGW8w#Kls=<+)yBm0c4pu@A6hk>!`>-7t0U?kKSx^9FPz}l4qy7BIBW!{^C<W_D
z<Pp3;59y%Bq~ILX=e#Y#7U&<vq$p;2YLmMER7{G0CLTpvd|f3UDnT7o3#b-QEudOJ
zwSZ~?)dK&G7N9!dSN{LknEuX2QC@Q7J8NhW9D!p{Gi+wrU>FKDLk8nppn?jJOHv79
z9;9D(xGnGg=qoT2W<es%h53*KOJFI;kcIAm*C89;02!nY`WCh={o7rsb34cM3YM*g
z=inKpQ(!IQ>p+HbrZ0f>8<$~`tEpdpSJr=$@j#dg!4Lvk2!&}720yhW|L9ZjH0U4#
zA|VPSPC_&~9bzCB^biL#ARZDR8yn0-XTfZ!8DzUH$%_VB!_%$V2e>fq1a<7`(_=$k
z@2^>dcNpf?gIu;bhxO-y0USuL##;FM##*@77z>^hrInBlQvWG26(p8|#860u5^&|l
zkN{bb3x!Y#*}N7V2djF#hl2)OpbsQM3Zz38<U%2oK(aOCPy%N`VhCDMxt7$BdOIkF
zQYeRNaB0MK1U2y!G8oT>T<~km`!q=Wgj_fauJ=(-0$$(`Nnq22_jqsyH}C;}2m?K=
zgmlP+d?<x-ux`q=2YtX3{2>8SVH4!SaVP`1{vE*?hCn{oq>mkTfOOacg-{BWAc1&o
zKw>y}LMo&|IXH4nyFecp0zTjmVUPsrpfqDXBti;gQt^Bi?3<HkC<Pk_VkLkVXj+gS
z0-*>bc&`nFKq_Q_6BV60NP|r9;NGbNxku+g1t{EGD&(HTy~)jdk4i@ip#&t3gbyS_
z3Zy}4TVg^`dFly1podI24rd{$9kzr*uxihJ6mlRR0y~fvj>B27?~ENF0dich7dUjm
z?obL2k1!6o-8e5`-<`ZdAyk2N56%TtLt{7c*Pmrj0uG+o1N5+RF#CsM$QsJFpc0&i
zaV|gyZX-}ggySPAd!tweI`AAzSqG_8^7W>SLLO8>A0Ja)ksi%}5-5ktaoA@(#|&YQ
zu`Xmn6*&8{9t;5=@P{zaL&ya7@i+<@kOzHjOuug(QTd$=Lgn{F9aIab7EmpqT0pgc
zY5~;(H5Q=RoPGxuJhk#1;qD(5>mN1sDgU5|kX~+hsryHSM?S5MiPY-+`CNUhe;oh)
zV`GB-gQBBl^cRQnnAqP(0SJu<>QVdC_U3Q^e6PX7)*_JSQ67d{DrM2ucXUj6a7<Ke
zRH$C#JiepGJ6aze5k3poY|Y@Pi0E*gHU^(+C)<F48NmTTdVNgz)HuC17XND}+c2#z
zS{qY)F7L?957O({hpa<>17h_-dTl^NP-M_FZG=`l)g?`=K7=MBC)<hPks(p>vGh4{
zvK@vadq|KzJSx(ZX5gTaf0D+_c85LBa@etyXKK~2yPnsfL+9N`?pj}Hd1buyTOZDK
zUOSV%G6SVwQ_*yrGuP5yxOna27jpvqy!(IO^zvc9+?Kt^L^o^ckh3*}_bi^jHI|kW
zX5F^@yv?h*83kKjbK3r6kk>=kBNvUD=Dzso;0X7HyA@@-aeE6L>W9YP*gT^w^}>fQ
zyt1#&-t`|lZa(_-?qwx~p9Pkmi&vBmLu7kxTWyHhn`J*%_d>@*nT=MwvE|z5dHa^W
zcj<{WQ}#d9v2i)|En_5|$C8uJ{!sGGgSK098w@#i`nx8FmL0I}H(;{Xw?pfBjrQ~2
z<;lC0#<DCSXhx^e<2Hw-FI_itY0J4`JtoAKdMujjJ5KfMR{grY8moTYA5Qpd{JI^v
z4{Iz_A_g2>v*Cc}(4PX=ep%n6*WxXYx}QI~<h$!78+*Py^I3n@uUqx&R{gqFzwZB>
zU$^S7t$t@-_19MYwN-y@)nB`>Hhx{<Mc+#goTD#7U*r4b?t0l74W>TVq4R<7t9yEQ
zH{00w^e2r1TD~y7bJyEGZw|m$rKhA*{k2tpZ7Bx@B`-Lw&3&!m%A_A`HJ2X`+!D9{
zxtVKS9lb5)<$JAMK^xye+7~sJ<K`UC?QQq@+7}KK{;=op>pA^gRDW%;i|Vhf`fE!$
zQ2n(>pML*gOZ%R^c7}fcPMbCO^0|p!RDW&NUt7w7>aVT(YfCxk_tQb&g@cDL-P`X>
zhbg6Jy>@>cG&I9?LaK*fw{Ld6^3-BQ`GB?!jpeYnAMbhXlKy5y-)>LGY#i3)tvcCz
z8^1bQX>qflfls%6v+284m%eIK=zj!ySP9us1eIX_B>kko7j%#W>97Zip&YCN=r;zg
zFarER4=IoVxljz{U`2bO20XwQq9GXyE!i%b14U2{)<NVAJi!;jAQ`ft5GuibD*1!-
zFUU6(Ksh)Zr_Wa?+hbX6U)2P@QLOr_n!dpl)}OwEpbX%gfdN#1Rm$6F+Rz~xRDV^j
zugUb)g=k2JLZ}2A+G#w%7fLOdu0#Ju(8DJBKvqL0<MO>WC$8^6NF;4K?15sa02}Tz
z9<#AIq(D(3Y3Hy%sGLhb&UswJbZ~GpaE+tYXcm29Gv~8D(^lNWMu2?#tr*JS>?!8g
zBke-=iS|ii+h`e7!U(3_>T^E>r$uZRy(gbl`a9q2H`M<be^stRbx<v!T0pgcY5~;(
zss&UFs1{Hypjtq+fNBBN0)J`&Ua^1W|G%8+|5hJzF^0V(F0^oGz(3Lg9PF4+|NRG`
zX0T<xd>34Xmdt;!*0MH?Ys}Nl?pKuNP&4#kyr+4(xoq3Kjo!@bYo0$89bq0Hi~5+y
zebEW#@kyw^d3-9WHILU}dsgOc%0A~YKgqnTKJ%^3%XG|(G|!iGddB0;(~U@TpE=z!
z=B1eDuSD0G$8A_Xmipj(^(zlyA30D870{T%<pttLo(vLWQohHx39=!HI+z^D2RG_o
zLO>4%PzBc1w<JRmR6}FxS~fuul!6m=D!vdRiZ6LGq(Ko#9f~V>f&p@%6e>Xc%ZD_f
zo(M7^2aZGIrqm~a7o6qTHF(ANLI|XTHD$yL{2>JNU;sz#6$0YRodHD;khkU>6GTgW
z6BI)kq~kYG3}ukeisOMID23$K<OT9U--fy_C;;D1EQ2&C?o7V$eRc(}uIwLHLRdGp
z1=%3}&ko)39fpb?s2lZIkV@Z^a&YLyJgBD6$`E(94>tX%r-wwyflAPLupbD7G{}VP
zN3m0Xjv1T=ur7o^4wOM9D4wJN@vC+MSMUIrfvh(O1sx=VI;a*<EudOJwSZ~?)dH#o
zR12sUP%ZF3X8~Tll&Ag;|9?Hv0fKbD_x+!y)kj2y#Obu5xb4da-h)iu|NqUt|IaHn
zwsPj=n+Y<!O5X-v`IN0_guJu;&_H1{ARtI$5d=p?&d{Rq!Lb1mQ)2^yqdnq-!-8T0
z^e!SU9=f22sUblDp}qU`3DUat>e0uwSD#+mK2v-5=&cP63F#BuySr<MYw!Lprq~AY
z;gLPM2TY9%4J8gjWK=+mHr5zBp}+CF_F={x{qCRfyY`*<u6;C%Vjkq178a3lI$Z##
zmCz3aO9&x=Lv)-(PKY56gM<&WwM`)HSG<RMTh!hsbtfz{uuRLbdRqj~&<BLZMFyMZ
zCo_LH)?t2Bh&CXa01SK|!Pd49^Vb>Y$7rX=g~zZ%vP}YATx`IvvJw?TQsX+Fch(U@
zVL6i}S@rH~J)l_HdSQ5b&dbBByV!IdjQMqCS`Xe9K{{PjaDX-@MyW$oh?;dqnAho6
zZajC!b$FG&>pD%8zP9zv>H2d_GQGXlv~2eYa~atq7aqe9um@hJm3ZvtbD?$_k+PwW
zswp1#a-QXQ?lRmt&z>y2*YiArw10G-eOUI}^Ep<rwk_fq%mw^cnRj;&2+(zRcfaRS
z&Gx0NY0wa3dHQ8@%rc&%n(Hl(x*{2-0#!HiofYK}<ukj+mU6k(E~*~J3+zwKDLMX^
zRy1C3WZ^D@#&{m=I4-KJl&!{VNFNp+Yq~~kn74uYBX0}SRV*85O<K8!n644?)g2rZ
z9TXg{pUHeFQ!kjyR4R33GPDIdph`(O$v#{!n#<I`bU5zrbN^LCu>aPIosC@MzaLyZ
zcQR9K;fdC^g&fn9=3~mBo==9yf$B8*){c@$c?dKe(>)g_clRjb!vyK0Vw^j&31hyb
zeE)v<<s3;FPcW9fU(S&q^L|_I<^CDS{Cl~s<Q^GD+TWgMDeKY9|J8YxJ0bJL9#5I=
zF+vIsgXB%BIY&cX@>uk5p5uTJt?>rPE&m^!vtMlE$$o!(&T8_gk&H3S0jgEyyG2SP
z^62^FzgG_LWRUIsak={AJj%5s=UjdRye;JSMjI=?aAq?b%c6#5rr!hkB{123tl9P@
z=Hqf^K9{L+JDoVL(my(`+CRhY?su{;d6#YcelX=-%7`lqos4BKARsg<CL%~@x<|;h
zWGW-Sp6|*04~+MdU*^{?H&O>KgWMnGb}8qjn)I5AfA5^sx)mAE37fsk@XI-o;(N}R
zPt!Fec?>n%SJTL}YVAB;BCY4YnMdL{$xp&P=kK@Wdb~M*1?K#Th&hFBoTI=$%HOZg
zf2}L*&+{T>Ky3B8@!9B?b1L&~nE#K?wXQJ<7$l!^t|gxh$Y=B)<?|kY4@0z5<EHUE
z7#j8G`LFqn`|Y`oG~3etJ~G81%>{B<(F9?<j~V{WJjQDE^28)hj?sE9;6J<8B%gAv
z{q~&Kl*vMKK54Eo+R*{MPMIwFck^kwwf{?HvZf4}?qiYKc=H{s_O+yw3!I_$wItVj
z#s6@=e|!E1na_W*WQ^em$i47wu<AlP)TP?bzr(fqF~+yZVZ23-<t=g`$&5Bjt0QB-
z8wPe`Rzt<z*1&Ra3k&1(`X<J|GG0evrmc}ies86Zx#@RU7cD!G*Hqb}l!<JXoi?r$
z`Iww4`R$N$V!HRnhw~0&ei$?TddPCQH#g@x^R}pY={2Wee$BJ2X`4Y2gqM?7!02#o
zh;dmoY3^$+>(<&f^CT}~p8>|a@J_|JyjS>|?4%5FG)-&G)AHUS<)D&u*1XSs$@E|8
z_oK$OQ{&ndbmSWbT!|XX^^tq$y|t_Bne$J3oQX<oe<3w=fumE<jp@;|KKLe8SKps&
zkr!Nz<@gPUr{_Qa#cZ3=i<aoL$3OqR)vOC$UK|~=&%%Dy&BvqoL7UrK(j^YiZcN*C
zNx!t)=+6h%^Lx}HWKECKf$Kvb?(7}1t7<a8Ys&{oy3Eq6ietiP_Y=2ryn;?V?e|e^
zXnyQMm&`ZLPbu|_&*5U~Li@JH(lMuK)<e(cd(7;a(`{$au<E9db}a69Wc8(vlj^pb
zn!kJ^aRJ%4#&Y!~hnt3wleZ_2+S_z!)W<1nW8M#5JFfqN;7NH$pWotK&2Q;YN%vfr
zgRRxLc4}O^tg62%uHE~QQm&jMKM!2JG_t5j_v!GH37f_>t((zlu}$}SU%2jGI-}hK
z&#H0l{;$Thi|8Tecf`X}ORVcyPQTc=&BpLPo2tuW^2R$4-_^U`p!08=;?*7H!IJx=
zXMFIsYma^YfL1f$THL2CHg@sZ`A+L0*AIKS_kQ}zxo`4JV!RJkFWf%o)JxmHT{x@Z
zJNLI~7iTl8{DRA=Z|t((uDZTuOW)b_Ei>NN{1&?{$=haopy5w;pWZ0D{qfeV)9O9!
z|Mp8yt~v4f^OvLP&m-Tj&{$S@^vmiNKH2`UkDRQ}IsW*=_}z<&4_VdOef!41!yBIO
z%yZduqb1$5uU&h$#iA=oXI*`RM-FzYp76@Ch_vrsj2+g&qdcps<rBmmFdpxzoT`kR
zZM*LCzBH-tz$>d~2I^+)KH>L+muva{l1;5PQm3<WjBKyUCh)Vlt=0#I7FLYB?$YRb
zofGqpkD2;jb)se44Z+{-{gD1dBPCs9>tO?OpLjTP@goz%U+n67%Kp%!IT;Ns%c{5c
z?KCm9%WHfa*toqjKUX&YsYs1~r^dh2W?rpxxv!V+gsb!H);?Z6escRA>8|UJUOh4R
zzzrYD-(V`-HI_++B>OKf&z}*{I$+7{qgnBFiX9d%-?&*{xAjL`6V@-<%eTATB;6~K
zEj7(P$RAJ<ar;X({+$~CPK|%3#=leJ->LEMmVR2g|7G_vPkhsE!1QU?J2#10etvOP
z_h$~DJGL-?a`VYN+vkpu-;b+BtCI{1+HRPpxiQSo{kh4LmZ|aY#4c+5yWM3Gn(3(r
zD%P~GoZWE+b$Q0;-Ho}QUtAt~_(wy+r3ZHBzZ5rP%Lm&mGiF~syRq)HwNDt9(uZM`
z*iVgrr^dgNa-hb)Q{&%BIk;T9D#@|`t*#F9&RA}`GPUq~Up4-n*hP(h_jiwfcbTfL
z3NZJ<H1^HRq#l4KGNlY;xM-mmq<yyn)u5NqPUvN{8+sKTj$T8hKT;JMj$TKj(VtQ2
zlXVMSiQY!jQ5xh7FC&)dr)Wd;3$zg``^HbwAbD$w(qt*|unhL7E&3p8hdQATpwrP-
z=uEUVx)^PPu0Y$O8R)~P^f`4x<+!C?(%i35k^Y8q+*T+}mB!&w(%CcCA8m(@L#03B
zL{!%I19M+GV;?(NU-~9^fea^bLzL#+qo^ZVjEdckp|bDK(P1dZY<LVkj{2itqOyHg
z!PI}r*mq5~Z^=9-kfEG(cIX9E`m|lFwVt^jn6ZD@Z`T`4{+pA2C^`=HHXn~C<L3TS
z#(q??UR~x<)ngpyao!p*W<Vc6=c6<`DGN}lLFGHi#(c{;H}`2W_H~l&G-6%|$S{d?
zP0%M$2h<;xD%Yv#U^EyN8-}2hP%RpOhM{3-I64D;3Qa(tMr+QexzCZY?OgU-`+P1W
z>-UpB38hI{S%f}}E=FtYZSMDD>>u!3yES4zVvokC<o`bNe&sxw`{LYny=!b=)~iBg
zz3b-vN&B_AkBreivOk*F6)7t+JVUyM=u&ff+0XxD?_A)jsMf|k3MM8R7$vFM*3i(@
z@QzA~cQjN~R7#8MM$pYg*eVw4Rx#1Eu&gXG%}ZjTVRFn1b+ALlNiw{ZrX`gn7MU8U
zCEEXaXJ#WHDxFi`|NG9F_4_@0?U`9K>s{}<%*?vHqt8_-4_~o71nTmQ!I$&K>hkfb
zMMYBQ52*7>Bp#U(DLNMyOE}5bIDF9$b;)MJPr#>(TS>&1c_>zVyPouU9?D(pud1h8
z2q*E^#h3i$JKE*v>GLeA)f07G)l+SJ(UXIIp5(bc|3RG>u^MH{^`)+eb0K-6ONR8-
z_J}%b8_sqU{4w~nWwtPU^lFR5zXyLVehd7S`1j%Oz~>saGOqofY`@d<G;5QgsvS?m
zh9~ub#@(>tsVJ+5DoQRC!9{SVaW`yuQfC;)I}FNr?uqa}Wy7<WM!u>Y&(vEP1Dti$
zmS+?<x-K^C5#ZZxdRDdP>3zqwHa&}I3&gHx3de3_+tZ1AhS>KE1b_Ntl%F_<{~q&+
z55Fe1J|{R)zrMuY0{%MqE9`y-&8njuhGw(tDCy9QJ4y&-gX5e!iVrM?!{9czjuHjA
z;5@I65(I`bG+=1J(14)<Lj#5e3=J3>`0vz!^uzrAyPkGB7-Y@*>-e9;*I;*<{CA*}
zMAm5hLPvwFr;xQ1vYtWKM69_Vn|Fj6XYW+x#C7bGbv19mX4nF6!w$%ScR;R@i!bY$
zK7@b59+36B`#|iSNyo>h_@9BSXO%U{MesFz2aa?OE(Td^@*~Kau~K*$xn!-5tb38p
zPFW`@>!4&UqQslU@!R<C2C{BLoUFl+wHAHpM3J=>vYz4u=`G@TG5#AZ`Gx?zi%j3b
ztAyE$UkLl)5ZK)sj`fFuV0Y{IzaBO~G}q3+e;sDP<B$xqU=F0f0$2p%GVwRTn~()>
zfw+^zc?zCk`&oD%7P7q<UgZBvAg+Y%AK@nucaiis(xJME^lXOr*#9Q}Zo>OR2J*cQ
zL-@Y}R)V<U_%gqAEIbTj2s0MOf!)de0dN`ag>&!=i1Wm61MT1e=mg?^$FI#b9N`xI
zT7%d(kpDyU?V)Vf12+gnj<FB~UeF2J!u=qwGk#a-4n6dJ593dPM16Za{sedw9)nPb
z03YZL;wIup!(@HCK03=nPg~$E5GQMb*MO`6wo+DPE&n0@hv3Wlby-I&w*6%7@@$v~
zDX;(*!4g;s&qF$_hBfdSY=BJI3~#~TU<d31v9*v3A3y=f`g?Ju#QiO-rvrNfyarMx
zL_U#6&Wi%EOHs(aQy}yDTzEhJ2kDeL;DWra@C4_Ie;dcn60QWkhacf*I0-+&JzPuH
ztlI1Ief*d8v9gA-J-)1!>;m0DoNS-wydU7NwmG_w`hF0^9l<}U|Nk2QTm646((Rz<
zv4nHx|7{hvZ==Jt5!l@Y&ihS2SN1g`?CpB^s&+;V+oH_*Mpt&*qS8J{-In``v@ha|
ztx;)%q;5++tf}2m8MpBV8*GPsI0(hSScGEYp4JY$VE_a`Hf)DxwW<GLfs5csACwC;
z18)$Ur2#Mjk{|`rARWYpseFIx7+eHL`lL+Y2?HPrmceSsfx}P&7r~J(7#Hb-2l)og
z1c-tZSPj`w2qhqPP~E@;K47I!NfynzfC<`xF9bjcSRn;+pcG^f!4IS_?J%4Gv4a{=
zpSYj^j)8|WGD9wuf@1^X1t0K(KnQ_#kPUfo5KcfTI5tEl3<Q>f*r#=YW+3f+CT&0o
zl!4e$4S*1c2N~Rx`}cC_LK#U0u}8Zc^1zuo*9<(N3j}}#l3*F+gS1=CpdCp6Un&$r
z5tM)zZCE@c!(#AeU@!^RK{n*V8SrEvClHcg9b`iu*zLClFxZj`%OL}{gD(Ru@iN!~
ziy;r3O!Oy%2Xp~nh=6#=gM;AJf_oQaLmnK26Hwd|o!?8DhHOwgC>xLjDX<K(AQuY2
zy%n;;8BkiIFF5Rp-v*t4SiBejCuF-VIs$JP009sIRuKELUiT9>_(2FH!*a-gY{-K`
zC;_K-#0}EsOS|q16F}}Oau2kD+{?Cu+?x)=2{;4J?b+^tJ{}+(EQ1WlfrC&Cr67aD
z&fpGS;0sY;gEYv7TquBJPy)?5l17*SNstB^kOPHK3>XqpCO{Ne!3N793v!?UilJR+
z@*9>zHWa`K@aw`p$b*A$rYrJw<C<Ur&+g<cq`)$W@+LfFfO`+lhakv=V^9K?p2Pup
z5Y&r!VL2QFXCKl9&JUsk2!K@B4#jX0ynAyESPmI*rZ4C8BP@hK3T%gBxCqMzkRCV&
zZUfN)<iSCRA4FIvhKt}a6kS3p<UK?^22X$DgfrkdjQ>y&K)!*;NXi5p1E*1>8S=q-
zG%`WPqa1@0@C+soAO%*35kH)OoCvN3j%Kb67D$Ex6Y*g&6i1<tXpTWL1jLYj$bg7g
z$_5mIQye-6E2Ka+lt39cPC-8q4@n7}3){gdk$Axm0wDw}kOV1^2I-Ii*^mnba2QU&
zK`XkNiVtqnC?8PfqCIoTbFsXSG<DUUgKou__ZBC7d0(lIFYhk(@a27_8NNJAo#i|^
z?u0MzVs+Us*J*$+?>6$xE$>eI@#Ps*p1b9p$(iHw>}fbd0~Iyk$i`zzElLOVrRRjW
z#0ha>lO}}5M0D#CnP8rP5xB`%_%mB3U^^;t!c=}IBqoGU2#t@IzgSEQwV1E9{udn^
zZM8<nnE&%_{)OrGEQ)JsT5XBf5blNyFWQK?w<;XcENDf?YUUDyQ7tC!;w;hOGb$RU
z^3j4>!h=P5!D6?DW?Z#*!R@>nXDYX$MO4ZyZel+|v#Zlkw@2|B2S(J2SHvbnZ{;>M
zpF?VEml7H40gpGz8-&Z%WL1R|Q(>VA386DI+c2GOEQeA_j*V)Z>e-dzJzPz^n+bd7
z`tf%EBk^WlCti7e7gsU8TL^2Kr{+y{>Fp>9zP|04%ISTxO1%AaJ<Gd6)p+H3C7{}P
z?ZzKfRo6J~x2_YnpHysI#WcT7SlbQbR@GhOxc_#YxaE5eRpZ`8*sL4It*X4naqp-S
z_gi{B%&l`Z?pyiGYoziVVT-i5wF)*hHX7Ss!BOVW_+YFARa5PBo0`>C*xq)-fdAfA
zkW0#!CT-Q<tMyu5^%kmWy;`s3q^0UUtzO&Ho_ULQ9jVV!uWyH!2<MVgp$+=?q%JoG
z`0rijMs@3I+7Z1{+NBM9T+ina=3<DenATS~!RyaVtKDRvDJ(9|QgfMCs(EwOzFC4U
zvwW{aTw9R*X$30?8}Mh!9AUPGhDWJoOLTLsyQ*Ik2P>8>u`4CvwX&t&+k@lTu6XY#
z*3&SS{c@ih3A;%{nwEyjZ7H_Gv>TqLJ8!~P<I3+Hz8w6!sypr8AvTlz*r(ZCQukpp
z3ByV36Z@>5$Z`Vuv;B$|ziKbZ#P)mYb)qGxD!-(`o)61J`8bhZnu`Xoitx((Ke3)*
z0GTV+xQ<sXGxmFRJ88sl%*j>D40BGEe;}(#la*M4;}Wn_YQ}J5u>Rm6;iYW}l0Vlv
zRo|l95RNUNuVO?k?Kw_;;9#GW15w9%RfktEDmv_`-`kegCjjmt6exNeg#SL_<DXP@
zC=Y<qp%$^^d-Z&gDM~%-njcjri8r1@dim3yg4h;WlklsP)o#B{lr1(L#kZFm%^s(o
zHr=?F#1TLk83R$%t(mh^%aeRBD2jA-LdPFz=^$;IT`ykY2p_G6b0SOxG$h<9J)FeJ
z>$z?l6x+*FEmn$ugc-p_Z-SIriDMb(w&2{d1*)#pIJ$7IJq~;LX?nZi=gdJIuX}14
z@Whw4&SlA;SYD$OgQt;Uyl&UH?WkI2?ebpK<(1b>scQFu+=l}GOnDQ`7ISE#nM<qk
zR^PT<ZR>mqSFx=V9rxDtYn287$9#KLUgqN~A0ls>U0&5*w_c9a7ET_|wRj~js&T5F
zUwb{OTAn5DL3-S7Qh9L8Ky>vCyhfc2c}CCMig8z{Rhk5v41SzbjZ<Ziav8wE>gtYN
zKJ6XhYCRSCN;yaD#~JqC40~^ey|)qHzrM?_higoOS&OEO_8&QO<<m#n4sx8mUQvb(
z;9l&|YG3-Qm!4hP_2k*Di>EhUezdgK=2<j%t9p*>^7)HhU)x5Veo(?K?z*!5?+b?o
z#`WI2|H`uP<Ll-=^!o?-A2$E^nbT)F%-Y;SQKqTaySZJY7Tj!14ugMwv27#QZ`Nma
z+VafiCUb{nEjTvw{jhzbP8GbdqRs5hXXry!uh*f&eIv(T8RXIRmzJiM-@bV)W&LgS
z`YhP=^~~*We)PSm-P`m*4wLJpzq{w@TfUn#qwNP<0z3Bo;=7O?@8A2FhhgvS&$IV-
zg7G4gL(9jlqdquNH~!0^Lr$Bfbbev)<}W5&d{^BzY}Dm}A-7MSVAy;6ziRKTruNxt
zY8TGWMaqj|$8G+DzNugBxwF|@v)kplEn-Ziv*;zm=Yds?PHwEf@kn08x5}j_oV(wZ
zbAH=x^%itXO=!AvZ)@h3sO?&qZS=??A2gjbcFWm%?{>S#<6xH!uNCZG*xa?S?c@h-
zCq^-jGFYy6^Kf?!mvE0QwKY54c+1qaFBXjb-DyVMc?Zjm<{x_C<SuJy!EfDOp06mQ
z)$5fmi(KnI^}x{B3AKN&b-3x{N#`c)82t06-+e!&?bfl`?Ve^%o3C8&P`67DKD_&M
zi>1zPb#uqB9-Zm)UDuO~(!T!d?6}psL*iZV__|l_X*p-uq442Jk9v)AIq+fTt&Ob3
zW7?fKzhGmNygkh6VeHT3ux)drh;hgLe($_^+JextolYiP?E1pVyJ}?}Y-`!!wqlGw
z?=EV3ljnG6_pZIbqv*0*udma6zZ^d{U~SRG#IccWryt$qKCuz=v3SujIW*t6=9{*0
z=az4p;TY=tp^N878@D9%czIm<##<XTXxgNNaJ$s&J=Oi${IEMNbnAb`by&v1*{|-K
zTJqWc0Ueqv_doSq%4a?L@V=(X=XTJr_vT*z`4w}gq}{*VC+j8Nfz{`Ych=Y4H==`Y
z?FYN~@94kh$f9#G#p`DGx-B>}dYGxzlqP5CBV?@E<gmU$!(To*6%#(R@9CFcw5GdF
zF<&%Wj{o@RFTLLLUvyM@DMQrjJ!AbkaAC-@wW-6Sr(X8hI>dX>NMCd5%+`^|M}PeN
z!0q3&2E4CaZ_x*zy}t9x_@0ji{k%3l!S~3v&zG#Lo0PM3+((O7f8w;;kvWd)_396L
z)4cfmqJl%`M?W2zdB^Pb?}qoNo3v-y#!UAf=BU7I=H98#IWwocT{QBa?|0by!tRsL
zoP23lnZwDqOnVj<r#_MVYQwYZxZcn7*P9$34K3W3IQ-1Kc3!vmDaD0N`!w3W(j$M%
zJ9W2~eDii&=?6|!+tbsBb|hZf()Y~1V|{YYo!T3de_@tq!JRGAkJP)kGpOv1PkFbd
zY?&M!>vY}na!BjphP^k#-kV|X&9L`o*n3+wYx07#?<Ify!=Sf@q`NVXxtp|;lUz=n
z2^haHrfbadn2F7vTQNH;#MJ0Sc*hYJ{$A+b_DTA)f`&*q!`_==?@h|V{DRwmjQ4z@
z{%5}?Fa7nY7v_#1RJuLKd(w{&w4Jn~;9cK&*xDH?;ohph``#(8^%gaZpZVOb7-gaB
zlZL%F(Tid4&9L_-<-oA__SW<>t*<OP5&Po$Df3@_o%I+GiCzqQZ~yJ~-u~?G9-U)6
zjMqo|d_L7qnaur{DPA5Rj&ID`WH@ga{@wV)@$Kj7bL-UkSOIk^pSOf*Su*xVcaUmF
ziZQ_Q^YpoKfA~CoZrdL|PoJCihtJdJmHpxK^f_UF_&j|+mwH~+d<aGFx1!Gw{KoiV
zZ_S<$`dlb=-cZ%^s@eyOuW+6|uc+Gdo+F&(-!goebM?G_o-hCPxjpKfABm5wFSj%I
zgnnK!KHYK3Onioblv((#@Wl?D$n6XI{2JBHos^%7*O^Osk#fgllZ|c_)!y3({3qF#
z`8f+JlqY?T3v&*b<6fowE+;;@?o0SGB>u7<zs$YR=bNbWP$YgC;<tb}x>(ip6Q`{u
z+r(+>fIkL57@xU9s(r*D{6%b!$Irlj6n`iFWB3R0L-C98!|`RFO9Z~8--ZAByb^W3
ziNwz<h2qG5ap+D>|DE`4*mlR4xfmqRHVVHP{v-G;@MqxPi%(rssJFI{@LS<y!%el1
zHW;5VecJ+ju4P+{&pZa3tcxa1Hks%90KO-4Sv%rK;djE9Z^_XmZQF$375_9ouST{9
zXdsxIV2j6RiHB_qKFc|5C-ITdb~k-j<e6<WK3!P0C-HspWxZHm{B!vI@I6WM0DPHe
zGf?&;x3ow491wMGNY(s&n*5V;iET*LZd{t4pU7jMiy>)K%K_1-|M8Sm{k(<vOaV|9
z;opb<lzx6L|Mj^M>YNG54=KNN*QxFW<db+`#COG~JJLqpDCzk3;;+Q-g8vFWX;D_;
zQ#O><_>=M1;LpKdi_bNbb@-d`U&GJE-++GrpE6|o4u2#5ulU^lZO-IRCVoqN&augw
zzs>lx#Yz^w%<b5MFZv4+w0Rcl{0m8k$Q=mckVQ=g<y>u-WAIJvkHZ&zB;ZRqv*IV?
zPsd+^pM?JmK4r~T$Tk0y?d%meVRI^sGJY7n!D29M>`}L=%!Z9U>hw^>u(9_r?KC$a
zZ<qjbGy4B!W3Q@xy^6N=y4YwVxe=7%XUt(;2LEN9vaC-|hl6keioan0ErgrLnlgOv
z6zV<x2`B|Ww#A0tAGMpetYID1X5L?6FV7{ZjxqsKAQKKk8F<X7qXa++q&|)heoxd<
z;vpYOz$KY&D1cHhoS^|j1BM0+4Hz0QG+=1J(14+V|En6Pjo=mS|Fxli<lnJtcZQC+
zv(h=IyFc5`-FmJq>thDpt*vR1wJR^f2Ow*92C`q)+dM}YStr+*?NoeO`?Cn1g2k`|
zo`z>Y?8wMD&w|VmTL#a=3-BT=2eCmYYnUW1S+kiAvi?cdVaeLT)$l5;0kJE%7JnVc
z8alfZ8-KD!eG|yK_b$jLHveS(couAduIv*VfE)S$I>@^G&g>JLfU@3t8^}8D?(Cbx
zK3NC76J&jLPxgt;z_<9n6=bb>H}>^{2f+t?A&>pCR<9rb7rJOR;ZEUKv>&*b?Hkz+
z6nl5QIsYQz%0Sj_$~sN4#UtxM`*2KbJ;^%E{`?;RwcSXc3;n&)Nv=Cb_KDpBv27@M
zxdAeu6XE}An{Xn6VHb{mJMv?Uo+l6EPtgB|;hXjUwaGU}u)EppPtlLnWxtbt%)-7{
zeZPdY@_)L%U7s)w^l(qHPi%aNt7sQaY{1pj?whZi3+W)^34DJ=34#=0EJis7UNmq?
zkO?_Z0Hu({Yy4r5ehj;9wRZgX2I<p~{)}{xHT5}A0LLKJiT`j6WG!?lIMQj%@?#|r
z4nh%>KpA+}r=Ei^_(KrL8q>ufYiQR&HXMc&XVL@dkO6s62*;op92?LKK{N1%KoEOu
z$*>$UAsY(e7+eHdUuXg!2!aTZ!IE^yfINsGPh6<0{xAV7kOV2P45U5Fg#tJX#UM6U
z-M|Fxzz2dL3alVD-O?Zvav&cL!U+(=1TN4FJi!~J3`T*JDY5&O0ox%TilGz~+6g}h
zf+!ICZz*7+%tS#F$oCzx;37CN=->vP&;@+KAA%qXk{}&2AR7vx2)Zz6DE8qNLk<+c
zVK@O|Bd!db+!;RtA6N}%pxIsM0{og#P9PidKn78=;24PQ%v{>KGa!SP@vs`Qz_B@T
z!vM$wXYOI%;0MRR*+d)=0%@>X{1$`-u^s2!5_!M^$&dqQpc#WM?ZDcabKoGH04D}9
ze82+9;NFIDAqaux;MkV9AqYxA?7~?<Y{F%9Ko8)|V3?m5X#}~q<$$##|3U1n1$0Hv
zkOA8vq#JsLbnx$v{ID9@_2U@CLuP;S51a;|<H5uaQQ$j-Ye6dHz!^}6Qbr!a_oqyO
zWf=N^GoTD7ts_bQD6S91Fkm!g4HiQITm+{;^bGM}gVZtT2TGxAEa#3R?XVbfpa2fT
z2{;2~;1tBQpqReiiy(cyfiTrYdq!A<FV79J_;Rlf#+Up3tN3!ilX>ZKzwV4L&n-*w
z<vzL$U!E}@z?bKnNATs@!HO@>D%0@gx#V$txu;8AmS=`&e0ffI9$${P!I$Tz>G-Ox
z1Jq+ULj#5e3=J3>`0v#KLww33|FZo*v7mLW^*?h`d}wUMf4=QMyN#ZUwY2gRi&qb#
zVNECAJ(|>4ID}=D@VHoOLTI=(IxZHoe~F3FVPeZv?BV!nr&jsZ?3UPV)oAvQ;w%xt
zi5S$;Y#;e>;S<2)i!wlq2m3Ob-JVA58&ONOZf2bkZ&t*fM?<BDYqTEjHDr^09qjf`
zYHQJV#%l;X)+w%p$yLMq25b3wBReaKYHLJn@%VDC*n1yQD-44vlT~|6l142Jn*0)X
zCp~Vlp)F3{*(7e}ys2?3O+|P1xP!yQ)XR<R2l1$>#ublWHU1>_RgAx~USrME%k`?+
zn{v2C<d^+g8YDcAcKS6c=YzakT1dlsjyF_g*6b&BVcQBLY6TBWicb*RI_3FrR1fz}
zOG$GN*L$0(<wUsyoi|h-)3<L?L^X0eR6j1?qOjX$DdN4tu+3uFW-)BD7`9nHI*_Rx
z4X1yY2HfOu$vPvgUbDrq!w+YFlHG9M@J$D%4!)yX-GQ&H{PIGxh#!CFy|kBvOSU#T
z9`L}n?|V4E@Yz2v)>*U0HDtx}+b?HZ>-b(+cqDHx@4xExW-aa6+4uBwogd!t$|vt<
zB<6R!v||3sF|97l^gH~@{xz3~cRBCrCWp8s8;?f4I%4pwx%KPR+u!u;z@0N&c^3^^
zQn&fg1^t3MzNRSO^ptS-r43K3=WR`Iv~J(YzHc6ixNFh4HG@5Ne{sNaz^kRlar!0J
zsPbLvx%sC~4?U{vy>-%8jcXtK$L=r9zuoHc(d*frC%<@LQ|WWurv}RP{yf_(X|Zy>
z&+lm$xUgMucjq3qj-#)9voe2a|LsqF`^{I*->r50>@o8lhHVzZHp}I>D?Dfzwpl(N
z?@{vYQNuQiv>OjK=(XGX`!|;S^9$d<Z>jgom34defAr?FpZ4@Wf9uo7E;Xd>Ysy2R
z$ze~EMdr1AUr6)v_+)!l$M!#-f48g41eZD9W#{7){JIYQ#jv^Z`{&QxzP8SKr)AIl
zGxOOwJ6la|HK$GgRg7~E68(MB*Ibs{f615*miF@;U-?`8CbrT&v!2M0Kf0*RsTWH&
z{y;x+4+(cVuCx1|PgiEGsekFmkTZ1~#ID#fu;IXWznZagL)v$Dcb&pmWFHCl)a52g
z1zy_@_@sVwzRA~_5m9@KLJ~)vUQ%!J`tIY0`O;6noW5t1gSntE`bw9scWo%SWqHAy
zkHk5oo_*7>xnkH{F%2Jlpw;~!x82|1wiew}9t^{_EYAogha*1}hM)0xa9_)k&S`gs
z?%UjW^uwEW)mqhHPVkP}-<@xKg0T$sIp_Bkr=R}z?bqjgf8pikZ!~=F9j|G%if8t+
zZRq1+*jzDet{65~44W&4%@t`+mv3wP{-u6PUubq$$uGO#`mS$w_g@`NfoIppzH_<3
z4^v8B<-1CZ1)Ch^zEhC&&Kr01ZrgW5TkjB4)6TCOHdjP1hRv14fkme_PJcEdwAK4N
zN57{ipD+gj+lDRQ@_#3z->Zqy3w~a_@`r$F-!?hp9`4ld)%)IkXQ^Xd`UIkfOE|;k
zieYm_%7I~X#jv>|<-jYj;nqiApYh@PJ<IDX^E&R=@JYkwis+@+&wB#r^&h<Gon9yJ
zd$g$7f7@4~1J`+tS>_Ye@$0RxPkNF$!Rq_bpdDkoUN~#L9MhxY<b+j&8opgS>mBDe
z9#ZbQoL?`X<L)Q;b|K?mGVZ32qbfATimcIR%BA|fUp%ELQ?_KxmFaReH+&PmOs#8y
z-yh!-pVxP>zhRq*-yUDaXFK4_^}RqF=Tz-CsMnWqHxCf^7~vY?hv0KgxlIZi|Ftnn
zZR}FyYQQcT^AqQzpVu3IE8BE6*gnSZi~k*dKl}!@7`w&qfKOMpts6dF9JUAXd6cm|
zg3r`88}>|88ynaMktuC986zEmznVDzlWhyw?FuAMuk)AL7Faj4j&iI!^D?0fT)ZhW
z5Crj%3ij`|=J5X@lz<a`OujGytgwzeEr3G)Uj%ph`+Oh*7K41(^#r)^&hG;eAm4Y*
zg2UiQfoTVUkPNFK4@yA3`RW5vAm4n=l5Gl>VP60}QBiWC2rhy<6~-4LAQjd@E|h>9
z^FzBp5G2Do$cGYeVZNvr1c1yTT@0C!4@KZe#q$I|h>}VO%OMN$p$N*L85Oe&_=5$~
zAR7)s2{;9C9q@w)NQF$uhZ9f+*k4hCf{+nbLoO77)5FLJ{$Pc4$N`yi`k!K7pn&@L
zm)aQM=227o0`5(y(6^#nNCFQ>=3yh>I@#B*mXeKM%>B$h@85j^`2%Hy@t9Rd@d3jb
z8Zb0qXu!~bp#eh!h6W4`7#jHBq=DK9Q*r%2(=3#&Ewwq=PIRisTxyv+ZC~g86~|=W
z^6ku3mifxEE?(v(*Cp(yw`=p>Z{hzOjy);Ib+?}XGVlDaUeo<Qy`Ec==hh5efZg3e
zN7S9t8KpZ{baXq2Yr_7f6^`A*f0Mp_2l{IacGsEzUG?q8obRq*qdWV0==%ra`|1CO
z;|J*fWj*cxrZwGSBcP`1x+R$=pzA}CwF7|=0v51A8f3tB$b~{U0cSwr-Pr@Mb*dZ&
zM+&$b$U1OeSO>EH+e9ay7x?o|w-~lVKBVx<mJLO42J&tpJUG_nog3CcHaPJf=?#96
z4=!{<njjlaKq+|hei#Mv?kH=%(;*X1fSWUYe-H@EARkIW)_D7)fF#I-94G=e>ev7X
zgforkLm+=;oxZHMUk5Ifp+Ja`vPA!?AIN&>RLFKm-n%G25Xd|2Vh~%g`5<ePw?jTm
zxQFyZHspcDL>~uaKu`<hhfMHp$1zBT?d_4d1M-1aN8$%r|LfnGYr!(ehca;PLO)1X
ze8%0HK@$CKg?hi6vp4CaAIy_X_l8mkpr1>=JGC4RgCl)jZZH6nVKFT0gFZm<C5?SK
z7yMv3<ilY&0cW5LoceJMFo8>d&KrOa0bl{KPatbw#NL7UF8H#R$8d%Q3=J3>Ff?Fj
zz|er90Yd|Z2L2N?;7B4K`<K`Mv&1{pV!qY_z(h-;HPkva@ju@NKq>k&)?%OPT2^eV
z#WvPr8*8zRwb-%No~MTVIQI0L{es?_`$<Np13S8TP2BSE+HqU<y^LKm`fN-NPG9^!
zzr=R-{yU<&@7g=!g=MxYtG{XM^!b;`yC?14<Mix4z6}*C;YyzDc*O6PIjP07@4a*9
zOT#{I|L&&+&rRGK@o|H&t`qYvyBce;jkVauTI}P;FOQtl%UFwjsgOQw>Dx8dVvic%
zdQ-aBO9##$>HpEC0LCl&tL<)zEyeBgb91HzHxFL$#DUD|wGX<_Te516wNCT*UrSms
z{~c_B(MNA`cs;g>>5ljE`kaX|)?zO@+K4d#8HX@AJY)SjaAC-@wW-6Sr(X8hI>dX>
zNMCd5%+`^|M}PeN!0q2F$^ph0Ob&}a`0VwaSH|~zEa>O8@d>_1wtc>2UEQRdrQ<$Y
zy!sQT-Mn<oQm<Ek(3|GP-xn1eIzRg9$jm!tw|_UhN8O}7%Qj}Z_b^8VW-H1>#z9OD
zGpD>=H1ePCci8*F?vu})d}&vi!^yWydlnX_K9T%t!?WwS-p^|OJ{nrMEphmndF{Mz
z@l%QmoAzn6f2BwMmUrrIE&1l{wqh?-?2NKD{?LxZOI!M$*>|i@&bd>2WAZP|@+`Qs
zMf#C?7k37gz40mI9*n7&931O(-STos>*2xQy?9UZ7N5U+yxaJV)2}c3xW$PPkIuZZ
zq$PH`8M84te9-XrS+g(BpL?N0z!huSh;fMl?OU!&x_5X+&t0uk&lhiIyt1c+3u{(;
zR7OU}IbEO4+xVD!&km1&``D#-o>+AF$v0=FPAMA}z#4zG{@&Bv`;*7tINfj8Ifr*o
z*H8blN6Y?7#DI79|2TMTOxM7E7ZqiaD&NLWoZd~T`|1lWeLW6s`r7MhV=Z=DKhbl~
zk9<0=s<p{&{qEsEF8TRQ=gm`}9$s3u>XT`oHtx`*;cqh;BlVSVlXgz~epgA@tj~|G
zf1{1puvZ=^{bA*+=F4+7)|)W@9$#61@a13$ce2~MDaKlCV=cC^7TZ{hE$xA^7W-(6
z{MUPak-6dMM=c`<wqZ^Ib1X~_yWSj9Fn(Uo`{oA>-~C0Xt@fI)cYc*W<EJKHjGUX-
z@s%yJ`K|}^9gMZuml_#sv85a=nRa_{X)WImJ{?+bU*cEy#r?EnQu`fsdp+`2Tr20n
zoqv6a=RftiDSne{Yo%A9)o1&@m0sU1*><eVSc@(CGuC1oYq6yq7;CW|E_^yEDWv_H
z%xAm2HH<;2&*>ZeGuL9<m<##eu-4f4hB<Ra>6<Xt7}Mu7l=-o+8giisj5Wseu|9%c
z!1#ta^O%|Y-41-<;C$vI<JWY3an-fOvaa}gYl;`wqX9OYp#eh!h6W4`7#c7%U}(V5
zfT00H1BM0+4Hz2u7d23u^D3_YU&!`fy+&U|{WI3-i(P`--1zPr*xiNO73DXuyGG4e
zdk=PJtku^v@n?L0J%URyMM)`wGvG{N@(1}QUMdV=eZ3V{gM8;Ng?UQZkOy7p&WHdj
z<ika9Vx4^|6hav|GjDA*6haYr(6<r@5#qDHJ{6WjAxK|}7x;or??)-ZKLhd|_5lsC
z=LqW{8xDi>ZS>oKKNQQnD9V$puaAIqaAKXkKTLp&;7hrR2ODJGNt}(DCk6hD{iZ+`
z<U$hb?6V*j0`F$6I%Gl)L^Q`X0j!3Ad+0BMb>P*OV_=1>`;i%(Szqt@0P%wb26W_F
zuo!Zo6dXHYcd|2n7sj9=p7r(lPzsK$u|M2{bTNkL1ts9ee61izgF+|+XXcpsfE7|;
z@q_3CE`k^?^#Wf=gIp+tV^9pGp!jkPD1#DxoxM*#;sL`M8Zb0qXu!~bp#eh!h6W4`
z7#c7%@V`d`yoxDd|ML2O`NsUUtN#<sp%yFys2^?DEC47<PsPWzRtWD7%I!)M<wU$w
zxj!sAJRvSIF4Ai99M#4&BHkJu6a9E}>_k)lxS058i#dVsx_h_=2TuzR4z*enqQj<I
z&53;L-orJ@Y>77~RNSj5x3E9dY9S6eCp^I#ES3n&!7-t+p%cw9=2)v1Cea$fE2D?&
zxaio3xao;}XWhefP~6nmh)`>ET&xzRZ@(co3FGg&$xTtZ>EE(<udU^4CLXVs$_5Y{
zVgYw)-?Fc$7YQlfv-g%i*E(Nb?bPqt`{Gyqp1mLYDu2)3!F2#@HA-PL$JVIvY2TqY
zm7jn0d-n1TdHJsV-}G?y@6K!6+IQ#e-<fx6YJ6wjux;@C`-W`;!?uB8+u+Z!ZO}bV
z=H@mpslVCxo=esjJN(+MXlci^*c11y&TBZi<%+!zd~ojAthWu@28L||!?uB8+rX#Z
zq3J=t{1vthENVOCVH?%IY2O7+HoO}4na|2kV>b1^kn-X|*W>ri>JvV(aUaGJ?inQQ
z)wa!zBE}u}`@QqxX$wNnb~>4GvFi&b@2Zt`u&rf>+ln#%iZXSugiD^|o!z_k0*|80
zZoR%v_x*DG*nqV~7Zb-uww-=-llw%*QMxitLHoCH%{Oi1&Mn_G!!gwPLl@7FHf~Ai
z@$$Izjkh*x(6mVj;dZIld#d}h`C)fl=+^&=>#&T2vtQjewdAw?13ENU?tkjJl+SuF
z{t%_g=XTJXalZDs9{z!2&d+Z2;@C371_I+ZCWm*{*WEXwgKzBzyZG<uzvsxJb1}v1
zX7{=+I5T>fsnwJwXBi)5T*&0GzCpuZJ~<T=KD6)YmtVA|yG=1)G+U1U_~<Xa-t#wX
zAQ(0fjPKDKHW0eDGi)FjHV_OO2y(wPY#<mm5TqP@IBEO(@FtylXKh(|`k~MFy?^1+
zEk5l_Uv9Z{dgPVE<NGilX5UZ=*JjYtphk~ReRIM7hEbP&@{0`{2qRTn7={gmwEeF2
zT~|H#-iCjq-v8*g^x-ooU~+K(Xq4lf<Cf0L>6U)$(_<cXJ33+N^t$7pd$@6*4{`=R
zJSK#>U}`wS27+M&LCT9^1L3c>fpCtov^3Dh^O(~q|CzUX8-5CiYsU0Y8T(^;r%k4a
z-h<x?za>7ON|Nu&+i3O__Su+vskFf#h0iftJbnlKBz&fO+GgW3wbS+jKHV_3SMizB
zX<LuaE4xj`7rBNl6&d~;Y%~0o-+?#20nc1!=Ii=G1T2GGC<eFw%nt?&q(d$ogED9~
zfMYNLk|7;(;24xavw<9k36KowkORj+q2JB}{2(8SpbP@&_p?G8<UuL8G3b442*<(1
z^OP@yfDKkdE);=bp8;Jzf?mL|&p`QOt-!x(pP{<%zu(A4ga5`l6l%j68Zb0qXu!~b
zp#eh!h6W4`7#c7%U})ffrv_>xR>k%I&#=9<r8aN<?{{l+&t<Op?Vb3nIQ(C+4Pe*>
zP?Wl?X?Fr~@}2ltusbXNr|aAG2_xS<7x!n_1&~XbfTiS$tW^jE3nW7kc(G1l0$4!o
z1mr_0I6Bae181O_Bk%2?@Jj6kzK{h)a0Uk4LLU*NfMZ?O;6oCmg1qzl!vt6jg-|3u
zb^;u4r7sEmAsI3u2gF8zSAEU_3y6(?B5<Q~*8}_@88RUUf~XT|kOv3Bxe@V04irEX
zy3K+jI0MbF6A%wJ$Z;pVV8T9t7Zii33I8FFI#&YC=s<1<2SGZKT_6`6O~?eR+j0y}
zfT<laLozIXfcW7UWOw9RPzGL|=+^@)_%Q#@3Mo)T$Fet_$`N1%zn-KER>K53m$yT{
zbX1d>zF>i5$b=J63T4bQ3+hdpA-)giLKY~##0$RQ4?z$C@sJFbzQoZFA2J~yYEyV*
z&5Yp;4Hz0QG+=1J(14)<Lj#5e3=J3>`13U&uUL`)^7?;P`G;D}*IEDwXX$=uf;o}p
z`mqzI|2NnG=&joT@U5-oQ5)WEdDT-q@Hg;|<?Gf!;cswosMsVB(+22gw5p$Ra)#If
zh|*52`m5RkXrj2f#&cvb??)qQ`Kx*#9vWkoz;aCH47G$2wIZhXkBJ{-37wcI$L{2q
z4PQIY60b$sQQe=)ek+Wq6&@bdAL9pBZGYM|;XA3}mtPaUlVZ0MP}Ib*6JXd0Fzf`}
zH_WgTVAu)xbL<3MiKTDPA@PgzZmCQA`#P_VnKb;Tk@v3%ik#l>K)ddXK3VwBlcO3%
z8+HN=I{}8B0K-neUuP%4SpWab?Q83-cUtz$KQo`5v$NIYR&(0)U&XiT2TA+<NndkW
zZvQ1?I#}AzbA07*^_$pA_sn`CKmO>VHm6=J+4uwVl*I<K!|Axr?t4C6nYE_=r5{7i
z)NK&EV#~mW1K<5>#?B3C-`(AH3UmA!Gch?lb-77Wf!DSJKB?cFZ}N3!MAY7*ki=1^
zm(-iQzWexLzReip87$$<1%=U9x^%s3L&+`63*LMr&LQ>eo9^|WUom$|+WpIYvR>l7
zfN>dP{ePcE`&WA8Z+WNg){<}DZu^{<q9pPTMSdLGk$7oK-!uD;^~pJRYHv*bg;|~j
zceY4BQt#r<pt3hUWz0>@563!Px4ax;tp7LG{~PQ7jrIQ~2V?!evHoA~AIAEBWBtFB
z17rRFt`03yzsg=4mKk?!Rsns)PcwJO<nU<G=V>3=CbZe!x?ADy25o1#tem}XL+gj<
z?Af--b^G2^trf*s{~y?X&f=4OjrIRhUe08U%6vD_<&iZnH=SH>UhU+(lKkh-^>lCX
ze5mi`(+k%zS8a{VlXG~xz*^@i@28%2t-CdC(3c~=nfto2{$KQBtpER?SpOeF`=*cO
zDKf?<>;IWns?Kr6Q|{NMcq&Y}w6$QHsf;#X{Lc78@hQeOx@^^T{4?>pvwZ-cCetQk
zg)FJIE#sR14eR*>4>K+ah0`_r3C(7pAMl4LNQQLCfrC&6ZjYlI@P~LvgG?xZ5^#Eg
zxvwa-1j;}Rtb0Nb#6v19hYZMpgHQraJ;+y>09IH>p2)qdkpCCKy(d#(Ap#adHk<$#
z=EnL!1f)V190o_`#kPY$komH!ArDHxnSL1`h=Nqel5Ktd>@s}$=GFwT!8*tX7hmLq
zC|Cx$Py+6K*$*<8HVv|%2#mG-%sn1P{R9gvhD^wZB5)i|xd1<i0vjxcEXao<D1&Ar
zD3jn17D$6^I0z-+6u@=B4<aBHG9e#MKpCXgqWlF>4q!FpLJ>GUjEvw9R!D~&C<d2D
zn3oOz*VppLx2>a`pgk-80-ZBgzib|Q!1qoePw-DbDfqE{@Peb#h57p_;4z=Pzz@LB
z!4JVNz@HFPM=8Uv$+~_&8fMdz=opf|q~5Td0o&n^uI=|U*7hrgGc;gmz|er90Yd|Z
z1`G`t8Zb0qXyE_025KXI#r6MbY%g@--Av~-=B~^9^-=fy-&y-F_6m&k|9}4ae<>3g
zZk5@{_UrHlWP*GTQJgclg9i+NKuCgP&`$b8APQ0_fO&963L@+NbD#v=9qCtrGH6Ht
zfe&QDF(?6F`V8X11`7QFeqaUZJ8);MzaIoaIuyV$@p<p(gN}*|_(2k6z;?I@?O698
z1W{mxoQCvUK(pI81_6))*^mbzl(Xef0LQ?s5%NGD9E5n*{cne2xCkDNi4#&G59O4B
z=Uw!Lz!~st!ha~Zn?4cnXinb~90MonpF8A(vk93Xqb<jv1Uy;$Z-o?C{Q&X93CQWl
zwZO3x*9HqD!+<XMuo#MEeF|&;EszWWJxLd2fb?tTLLoTOcj*UKNP%pS{>(CP?2SGk
z9+LWSE^G%UU*ZKn2!s%@KoX=t8rb@BUO#*go1@2|4rNW+9m5$KFf?Fjz|er90Yd|Z
z1`G`t8Zb2Q=V^e~tAAtte{`(XoDdsoxz+-}^yt{o_~>A3)YRC?iMj!Ro{Eoatq|TN
zl-pUeej?tf+#ePlo)DK97il$lj%s5X5pRu-iGCc@0VY`}A8j!wD2)^k*Wlo3;lZI+
z7R`rEwVD%IlkVXfWwykd6Dsailv~&zYPArDoFnV)6Rn|Eb8t*(Z0JODj5*e-g-NtV
z@H*(>IxadkB5r!3(vbgySOy;vYK@MI)xz}cH{^z4M6N!4y^=cj=olX9-6dRdrngep
z^&Z~2Zc#!)W8-3H#KcWaG{v%5KQTTu+<afpo}!tU#9(w393Gco4o;jA8y*#G=@{H8
z*o*Vq>gV5fz4IrdbhD*1uW`&T(&D=PdSPSYBBol*!O;;!#R`ABd@Yc#;q}fL5*uxe
z4z)x-ZtkDJzwl7YXmhyeWMC2(Qsb2Kn_utz$f>bv@CvauSDam2a*jd*9TZ)tsL<F5
z3mJ)P&GCCVzFIwQjt!5CFh>NJUno9KEozDA)ZbP57$zyVxypGV^c9F}0`hu)2h8C*
zS)bpk(7oVe35^Mh2o3JuqicA#u!xS{q2`D#US3@~d7C56VLd{-MtYe$cIn=uch8>o
zpwY3@;!tpKc!W9J!rQE7o5555T;ojTwizVfrqCBLqLyY8gCZxkFBGwl@VagrVt`aO
zoX9A$y1-myE!1SyifUwNqBYo_{@AG&OT0B9*xIva9K}4;8kgXMB1{Ao={%>0M}>0K
z)VAH!*u?0GvE~SqB`$ViyWn6#b?efmw@E^K>cQK#x#<b29g6Fvbqn$~!k&brwH^Hs
zBWhWrqRBl;<9<Cqa_E~8=MU2VGZ+?;#xoVum}rg)o;Wo$L9&>_Wsx+I1NJ0(w(+rN
zMi=kM@Gha9J9X*i6&B{zwPUA<&S4!pQ_*_#=-kOW%-p-3J!H4=&Jm&EUZGtgJ4f~i
zH%Eqt_6Q5>(xXe4PMsoqgmv%U+tj)|tXF8K$WGxsBFX=5=CDp-UfyAmq1_@QyLF7{
z+___T*WRY`eD_BFYh8$%?+ukYu5FI0<;=r>xVNesUjmP(@5Zhh(U%|lQqaMOT8U=s
z)OgjFMgaSsRQH9dRfSD;e-M7Ex<A}v4vi(Ww%>#=m3Krf%&JVasP$O%{-v(>0Q$Ye
zNj;D*F}j;nXRFgt>OqL!4*u^~Jk4WBM}8usV?8KnVi(1vr=_yzGFRF^$%E&#G?EA1
z)a`}k+g&T=$#A{AR?L&()#S<WTGi*t@LJX9$?z(95~=4&CVh_L9)&wW@^%S%8=#dL
z-4+b(#pGZbLaip$yg2t(btBij*17m@VW-%B3BkX;nUotf9$Ig0e-!>xYB{@_*5Qhi
zYdZU?6Rc;?;9yIqtF7csD<;>M>%CFK>)o_Uay=>U33^)^C=Do%Zb`K*rQ1^3Ok9O_
z-O6oWZA)n=xt9d%cM!Gt`~wZ5Gz3xxt8Wt(RnHCeHZfDxXS^!sP+iW0)yP?|1@qF5
zsqIFEHouCT)8e8dOl`~Cp_;`1rmN($7QbCjV&hhvFNi3jFVR!{HSufrod0P(J+9Xk
zKl<CnH3t!yCRAC6oVl8u_G)p{Vsf>F-ZZG1uS8Rg)9&liPDmAAt>&wCuai3E!oL3M
z{m)0QRK3+ax2MI;S-WJ#v^>u>&QwmzO{>t=wA?gkjnlI952odWo)*au$rqXu<t?sZ
z`l8bF)lKidSJQISpfyg*n-$U`Hn1dLvebP(=Gdt*!SM-k;ZlL5-I%7Avt<p~ffG+2
zRU~<T<D7uX>8Zi<qWx**x{p|GxbzLvvW4UJGA6c~?avG%?_;{W?HGR&SMm9F6=6dv
z%X`zpUh(Nlu6O-5?P}TQ_N%;d9l7$Vkt>a`w#stdwBY`$ay@e$xh60!Cr;{~w08`v
zDccFVy0Tn1ErkE7TyI}TE|U~a98=GEMqxY*b`Z9(vRr?l+<BIluj-#sujZpKaaAl|
zQdcDY>fToxDm`2qeW})M#S8hQEDqAk;s94p!trXXwgpl6I|<{Zg;(ob;*3PAIVM<p
z2}%q$Ck4mGNh2xeNtu%}RgEiuUh(Cib{{RT!pc~lBlZ%{4I`-ffO1n!iagG)lExx%
zP^6C_I-FN8z2(rJlRS{8k89=UZqZS!t|M2@6&>}{b(Be1adO`fCy(VXH&v8eEj%xm
zyjNFvu}!2mBAS<Z2`l;$|5|5K^&|0&vgbu3Efhn%io8~~g-?*BP>aW!Fe7-P*&5t8
zK0YAM5*<Ecu-O_wb7)RX3^XUi&^aTo^TW*6sJI9<UQg|ERe#lZMNj*<_Ob1?NNYIH
zs?l_j(4V4qEhMVxx65^`8oBm!uFG+?OjRe>=%~2q1I*LR7HLrjM2Aj{jY}jaG=0=W
zE}tDYmrK5PAg-dm4j@;+_2mkTN-&2;l=p?G8Vj5eZ?3VvoNpl4P(2?V>C31p*Foe;
zyS`jncNLur!+5Thf^+@0TzfvX=bz;U^7Pi_N!8_P$91J#-3Nz|r?84V3Fblc%k_<q
zPV75;^pKj%;QzPl=apRsXXzlpRm`hTr3@8SDnpfwXbw!OnGBzCov0hgV6Vr^s*&L^
z=LS@kVIZx=Xtl}nS50yz{t-FSZXkzU7w+=nSVb2{kRz?K98~YV^dn3&YlWlcy4YR=
z8Pcnf;d5jtyherrGz){`5@JHFe?$*OH;}=8@9|{LOjSJ`MFy9zDwPTJFfcYW%wmoR
z8ZCXkgUq4Usq~oCsE$b4aN2hL@@X#{S=GpLjB^97k;R|RJS|@W;^Ni5oSM{Ck;D52
za@fm87x!y*@&)InT`PxLIETbW#{H3e3Aup`_I$~$Musnuq3{|R^xKbCKqYh3KK7dG
zBlQNd4A<MPKzZ21RctqoBa6$|Rm+H0WdoyQ%mE4J@aRNy-$ZH7WC!QhL?*c(X5T<2
zdmbIGMkaaQ2)ITjiTq!vJ2#NQo<|Y#@_?(Tm#>f^?HU=zBytBfM~2eDsI_ORiQ$^)
zL#;b+U%&3y?{}ru$nrI^6jm$Ch_FcvJV?2fHiZH+PSR0RdAx5Rk6kx5p3THn)Xg`@
z<MK__GE=!h85WvY{!DwbXB73Ga|2oIx^a=0>ngHrK)!&=vXnoOTst~bbKNYzfjsth
zZh1BGd?)3miad#9<(alZfguew&7+JP$YHNT&7|`IS22&imoigX4*&i`1_Z`c5Tm9t
zoT-5ftE-VgzOCePqEb2W?>{V5x3MiPZO!#iSOXbkKB%~gdN_{^0aauuHx7<A&`FK+
z!u<x%_x3W8S&a<8Ntw7-2CKPJm8rQdd~YB}Pra>|@u#Y~xFThuvK+&B;bF|TUtAJ%
zOlw*mqG}L-W;OAPu?LrLE0u?<@zZkEH2%~Y#NW<zZTcOEKcI5_qvEc%7Bz}r?rRx0
zh~Hi(v#N<-<`}0{jeksRbopp9BG*I*B17&CWU#m0KJ=rDt5_dyL59N0GK@A`wO2VF
zI>ILpX52B9X$#!wYa)xZ-Dx*?Z?e~mylP~rE9K$4O65U&@ED|zk9&2NVT&5ek$VF<
z>^jM5DOc3SoTQ&A2yT^fQCW`2=mdtDL#KsCTjXh3f0ZY!=)@bp8mIOJNPnd-2c5X)
zh+67p)ILnV@_iPbd8O~f!8IS9Y)2kB_LvsG8rH<NvwD8CI*ut}g9w)max6s;D}C*9
zZ~f9$;?gDyu&MSpNMDH1O>YmnNJkBBX)W!$3ybkxh@-Gdx^>N~=@i{m<I2++!a<qm
zFrt<^Y^KT{#XhG-vQH*-h`zM%GE~rqu1uLJp&geSfp%PUQ|YieMkjq@+SpC3d3tbU
zJe#Wia?wZry^6x?wQ{n8P9%S{@Zq81Q8G<J8}ku8$~k46^CV%$oK(x68i(&q&hbKj
z$%Hvt;T*}g>f))W_oP+?!i`7YPWWT--9+!jmCC)=Rm5>AUp3LY%%8FAUHU6UM_M@$
z9bGL8l4fsYFNFsQb6AU){&H7W(UW$Lt|$F8k>7q^JLHccT(?u2uH-!58k`rwd5;rr
zLxuB1U)PII`V5<Xuf?&IXF8E#tX_7ltvL}V=Sw$Le`t&j)3osRJ~J842o8;i;B_`J
zI5HtFCiptF`1*BN>qjiF!&S<$#DAl598iAz+Hx#<GjUu?f2H|7^mq4g{a8=?+j`pV
z?`#94g9*0?q`!VX>>$jUt7*5yg+>HhqQeqG>C{xyt#>j<MDy~-l$aTubNw`HePH%9
zCva_h-Ieym#JQTxSId;hd&>`6UhN{hY@77$-n2!sJ-Nbh$;(0dcyE@T9;plBr2ls@
z=d9Mk(?8LFYC-~?zS=EmU}U7steR#HWX_TFt4liMylb7-pD%GeqQ{l(sfBtJPjn~s
z%AInPrNyNW<JY7Mc!)laPm5p5K{ZaD^CCKva_}KHUB;T#zGVq3^(mXQuSTY!Z11q^
zOV@D|<Qh>cG(MgIX6cVsd#9yDOJQabq1q)K7aJU-c1Z_^TSB8_61k3~SM+^Jzn)yD
zq7JsVk=V8Som~e_3FB3w=3g~BxK4NTRTZdtP!k>ey&4^CC;jV?Np#RdlY#kwS~+W8
zoemP|{SJ<>cYg;*l=pvMtAi)>>&bO0>L5ot|8W(|K?}lUT~`O!>)O7m1Sy9#(ZRNA
zbdW>(Wo?>T4yx$j-s*H<ReRc*v!+iwRA2Rjt@O2*E1|p`=+~3$$i7i}UC6xuS{<||
zjMtCXD+iUk(XXbw=5^qcYSNxdx|bu1q`ik0H?IX+{(DxJ_UY>6Q+o5|xxj3(C)l3e
zC-iH`xw6mxov9G%pvUzENAQ7Kv>aKL(_6Kh{)X)&w_LRzXCc2o*YC`BwjO^=Jq_-S
z)OyUM)kr$bf|<#h$mFHOXo9NpNnJgzpCe%_%G{-cgyJ5@GlF!XHpI6Qsmtk#d2~&;
zzAAH)dge7hYMUhY9vg?Ww%ww>{swE0XX-OsD#wn~2J^hCeilpGu(a~<+C)uByIf~E
zzBb;c@7Jfz$~mj6oI{qV=VVklr&EP<vN(1>0Y}uDW==>{yFAtBvF+^Fo~^i@n-iv)
zBeb~yx$K|JLjY|n?<p~AengNLF6eFx$L`Z~g-%>urM>T<UOQa-o|r!Alu=jpyw&Y_
z&gQ%ognLjwPtqvu_ZXAJ5tpczI&CthnpgI6_pTmZt}l7&{*!h;?8LT&>8IDbbn1XO
z(Xr&|JTRlocrCo%{#H9oqUNilp&D0yuL<E`)$w4tmq)R`VxG#rc=lD+o%UU{s(K#9
zc=7<!aed*c4kq7px`3*0Z*-lCK19C@bbYl(E-$tRtNB#@2sVey>&_?oc@kdq+)dZB
zNiKqu?qs>oxxrkXO-yGh)}29?#J(0PfYye25~dngu3Nd}NcDM0CgFzha;)Wb2kn~b
z^()G-PM1OQ*$EoKM(UMsRT%~)$m_M5zcrD;o{x##0U{{7Qr`S^8RYsRLr+}~?I>H~
zD$1~sG=x-@fhR4xC8z$oa#(aZB#w%56zFoaK$Zp|U8PSF##U7hdLRB>Ii&6J=K5MW
zj<h5OGyEQ^<<$$id=j_FXTLvqOXH3E3`AG^p%*e|Rgw=SRUWca^GxbiHLkp^jpyL?
z+S(+J+4ECAK`8ao#=eni`Il(}a*uI!O)bBM*0;~5x<3uSkiOOtwZf+IY@8tbE4Rzq
ze*0>M%Iz}c*v#?`&XVWRLelGo9-iPDAL@FN`<O4=fvP+cnIa)F1#3b`!-*3;N*U~V
zR%`PltZXOi+d*tg82dASnXc=;oNK=qw{lgKTrIrb%%JP)hbC2>Oa4~l^t$Tc>O&mG
zAW`M%a<nBaCbq|yr^T#|eFi7VWEN6oAN{<Vrl0h4<(!J;#iOeh`_p(*UKT<y`ZJxY
z*uIbkt$*D<lz7uNT=Fi2YgJcXB=4lGY30Qdu0HXxZEwr9a-fxUxsGH`AN0yME-C-^
z5}@U^7}ixtLjYcPO=iA_skOb2mFq`;Hi%|GsY+hY*3Xf!lGkhX?FQ&T^fX*=e>~J4
zJ9JJw(hiS>F340=RZlk_VpR3!$GO$G@_Hs|2~lO&UwBy-CGDA%ZBNNBWa)=@N|&`0
z={2z(R-WDp=P?^n9q9}XrSm`@-L#9@%lf@PYh_)|mGpb*+mg15<s_*)5#T-oDJSnk
zEIJC&!e1@xm4`F`;&w$#%b(k>pkwqKNP1&Q<8)mg_Vy#ZT*nf3_3g(O`Z*F-bb3#z
zrsJyZhu9<*mjH4vk^ZQMd5#Ft!e7;C^~19@E=yW{s{DLxe~#4ZRfS{a&#(@z$><;g
z83&1MdK&C)Pei#Mrt%oei>x|$tk3_`AHwZr><#@~IY;!dRo|9A6$xX1rcCNVM7UsR
z2#-J*W$a8<eN-A>N>qnrYx>^mNgpZSy^W*eBgxA3rF{v)KSKX0?+IGN$%;W4<(2xj
znDj>=*I>e2(dCwBI}_XHavfA@clGn_>3{GSE&nCF?6a>CSl5$_;HE$$u)u8Y=kZ#2
zJ^!x`<Xp2TkMK83x8$?5C%IggbnDCdf)llMeOJ@3wZ)0?>e57gy`Z$mA)Konv%f=8
zF3^V!*&pKATs>_abe-&0<0*fm=S99slvUc__x1DTJSiKW>f8TdTXbcAu1V=dWH@=@
zl=hd`CZ&t?xt*_gpBi$_ko3*;Bl$1-ss29Y;3~FoLWo=1+j?4D>ixyUcC?!Rya;P^
zJ1bNoO?F97fBhT@E8CCh+wPR>is@S>FY>tAAnohpFpe;3mC|?3P`8@@Qhuv(<<I*e
z9Mtkq6H&rS-pV~#Ya6teX3<4F`?NMe_FcW#O86v>RV@o*``m`?qQeap^y9_$Bvn6_
zaOS;Q<0>}|YT88~Kk4U4SkZ_5d0*_Ji>pOnf#{<Q{LqKjg^KxIdDva@T4b!omET)!
z9IP&{C4KU2S~-1{`U~QwCWOmvxXN>BqPpL%Dbe9-!syR1d<tEkbIU%diy8Quej~0P
zD{pgMU9&h|(|!YqE0^%vyKiC~E1$|cv!(4?PQJLK$5n(Gtm#daLGo&{o;NgA@fErc
z%Jbz*J-mdId}@uMEV4q0(eue(FWvjF6Bh<@50k#gWb(<Th1c6K|Eg0HZrW~1eu$h}
zUTNi1_DNZ<oJS6>zNFC+IpjXIM3>XvZxySh^J?FaS`;aggq89pY1^ZpBVlEq{eINU
zmq56Q&<G@r!%3U+Yo#*CwXd1-aMSe3GmE6J!u?2Hq%C<`A&vU|NE?Tgb3!=BkA6DV
z^_gQQTBQoB_o-&2-^o{NlN)LBmA6yz<vQTqpz^J%TnA(Hb0loVdMMu+5SIw<AkRbt
zC4VdF;OcY-2`=?e(ol_4>!IXh2nVOAaz#y#)%(CCG1?fbc5{~W#+UC455+uyEYDZl
zt|a_zuA&F&F4lBl@}(Rgz(|fQ*V7~V^kO?vjf<uDGA$%HEG{WHv^?!!>0u>I#k9Lg
zqc7)zJ?(*{-Q~B6`F}O-;|TZfq+KiPmD8^6yLsB1iQ<u0((b9rr?yj)_NmvTeR_G?
zr|4lNOvSVx)YC3y)CuHX-;cDfu9Wsl(@bhy=5K2z`6kZ@+MA!WRqn)>3zCeC3i6xS
zPEzGhh`TyaU@n*cD?O})5&7-yQi=?w;^Yxa-p%E;sh$gYcd26Djf$%>O+`(EH({%B
z`u)_w^)PbAbA8mIxM|npJnfnAgsY?tS*KQ>|01$UThm7mFX1ZcJ7RzqqqLvWj!OOM
zL<Av~<+WM{n`1|@5+jb6g_}Lw*xMMb|EO}mid<i7N2~U$IJl;gwgBW&pZlw%?+Gn0
ztQH3HVuP7cqe`NsMbh_%9$vyp`s{rr{sV~+HwxtWZ5Rxq9V@DozUxlexoKLZy_d48
zwT*Oxu(&!ALl%^o;IJ8DHAHJ8qDYrFvPkhhrORr6rxE*zBV=7T=1XJ=h?o!IGGehn
zpE-0jo%fb$_d_{H(rLeE9M;n*-33zaq>RYOZh#hEzaO%eCRiN+tk587`FW$VXTPU;
zaZR4(tGz}=oez)<#4$9b%F+s7WLbTUEWE=7Pm3nG_NO!%-??dBsF?1|>%>)5ZCv_I
zNR8#@>8_Y2cX<)R`GV+IUJImNn=V(Z*Jc{|1j`IkBU1>po4*#B)EQ6Csm7`GTjH{}
zA!T}8FA!MbS_;$1(D+JmNnavkHVo~HVHXU_sCtw7RgF{Qkb9DegWCO1*5OYxUp-fw
z`!r82i*oJC$E6HN{-=~5SLbBtf#TKG22u~#YBDNv9ofF5Z_9ZV^=TTSNom8AG(G`R
zM!c?6)MthFInszGbpt;)zu!r_=*Km+HmHhy6ZT8nFB4#zA;);Ohimbc-@6v7>GYuj
zPBi!S@Ry{k$0QGTyGlLq2{TWOj<p|?Hc#r1evDpW?TEyaN<8kwBkvPwdOWg*-<R#i
zR1*6ddeKkCa?oWc0dVpz;*S3Vh>i*?>qv$%n9-nRg@l)~W|KeHy1vpb+^Y0+jmICs
zh3(Ho?Kv=_*3`I2_Dj1YX?dzVuhqVmICXM7k(JMmCyb=q7k`NwHi}%LHnT0)5T!j`
zehvHN3$3t98>c^3spX{e?^?Si;icT9>)RrO=)~T45ibt}xRu}p%VG5G)I+7dyeH`G
zT*aH9l<<lrN7D~kQk^TWCjlH?qvo@HvWQsM(aMcC`7!}HX0h$9#amu(mZ|Bzw%nKq
z>v7NZ%Z+}lQn|?`o*?3pXNkx4ctqb)2E$v+waTZtsX7upiSE|uVeRw2ny{YoMdV7`
zEbAroxl;0K!_BFbYo&QG&P%y6IXrvT{jx3M=<nl)zH{5axDOV;nDF=T7f1G<8~$+a
zffv?$@-keX`;5uq`SyF7r=GuW*og06-{sfCHKxI=MN>xmkDR&k=_73iInG|sI$hq4
zOb!cnhu`}5nR!3XNII8yG_%zGe9o`_I|h9{eNRHb^!n<f-mn1@uGPNuRWCiewCl;U
zTNh7ny!>cst<AHPfF-MXj_dOIi(Oya#`9%g30FA9<>ZCsFQ2|}`m>qAK_hy9ciXwW
zK{-vj4~xH}iF@{I5v(1gGMgM$c#VxY_S}zmCVjiJsq2%IUTM1L+i&aL8GlD_w~u-+
zYv=h9?Wr2?MVFBMv+iCI5?OF&$gl0{|62RV?8C#t-YrXZXt^@{+jst<D6c&z*IV3m
zW&7V34hxLyy?6hWW#Pxy&3)+i5Ar{3{_!)X&vclzxdr2rs(ka@>qbt$v}W3gWk3Go
z<=1!L^UjJ7nyoo7dD~OR3igMToSM#knFkP)L;AaWp1$R~Ni*7huqCi#-!Hxk+426p
zk9qhze{kzZ2QrnT;n;6h)A7>Ft&+Fgds|%B(Almhy`o=w?71i2Yy82hkB>K5UYL8<
zZxrQUO-J04jYp$i9Wi*;-1>Fu?QeQ^;Le$?yo-h{soQ+$f_}jrUt>I;2E^o0_kGu{
zpBKLqmKLaFU)a|_>W2e=Yg#yFXV-`FrU#b2UidI$_f(9Ud~>?D)Hw&=_{iIzD_zn(
zwcf+enEOtu`(b+B`}e<=b@JZ+qXK&jo3)2_V1k5;i~aS<UrK+?^}46l_z?*YU9?(O
z?wOsnqMK(%pLd^mc}^qxy?aTxWNV}20S|2ZzK8P*pZ)V<oi%G*LsmS${c^Uoj_-wq
zNAmV!Us{##eBrYxwz(}=PBdK_6x8$i@ee;`Ep0h;#JbL7FI(rgK6JmLe5-~V@J`de
zxu5jfS-)st>CnMlpM1sX!l9wtC$yOxKi#QO+3z;Wl`5Zk{)k~yrriBnvu_s0{Jlxg
zpaThhpO>T`ZhbQGhj*8~ntco9MGg1GnwU>Q58XSvSBD8(JI!nO((UF8O|sWsT=Vey
z`Ih(ke&L`f-%wdi4)>)EPpju`O>eYr-^spj9*VeY(YQ5(J$8R_z;eK=rN?pV?iw|{
zmwImgsnbJ`Dtm98^i|{9$NsVVOY?8Hx_tC{cIU}29@td+9COXNZ<rhoB`m#T%y$uu
zzqf9ydt}4ppT6_0`c3SYRQdk4dgtD6-x~dLy>&l#xIZXAWl+nVuf!bu>fC3C;{UN{
zd#yE!vPZq%$eD+8x;Ogt#g{)S_+k6rH?w=S8{hcW-yZzp!6mJlKan@lmwO#;kI7-f
zs`$0-7OeVkT#BXN5G7^KsI8;N-0k;M-LZ|mTP#j{^9XHVcQxPom{%>|de*wA<3peJ
zy(Q?uS`p86F6z4?^4|MLL~Ok{-kJLY556XcjH2^Ov!sW59=Ve3A9`eR(EEvzd5QDd
zWxVzMqeVf}v$-ktSL6NjzIFYss+TLt;SRGi_w3*E-uE&8oU?Au{<Md7FZwcI_No>y
z4T`>R)?<vNtML{;b>E$C$Fo1OeG)(Q@!$K6@B2iX`FE^LIQP)=4}HDxtza6<Q|k3%
z+pe7u*f4MEu%~a2oLs;0MV~F!yyFM_f30gaU${5)mv4AKQ|sHVH-{9ApV#xg`2oXs
ze-Ub{z2@tkU**sEsmT{3=jL^MWy@^B@#1B2n0V#x*K+UeIqBTUDM4Kx2-{Y+Ce^R>
zj&WPVemJ`?t8Lu{bT_N=y;Xnry;EH4EovA)^SNCy%0kyCpE%Mz{jTY0-`sn+`;7Rv
z73Ci87ql-SIR_V{{B&yX4~65*d1E}kTyv<&u%s{IHx+LFR&l)JpVT9@9lw+`^FYjn
zRwD!c=GZ+lDRp+=_Y041aw%(7cVO=)zVBC$`tgt&ZqvlAO?oZe`}b#Vdo64C%)maW
zr+#@nZ^Oq8{_)UDJ3smM$7d8Jlowr-L-R!cyIZ$9dDptY$74rCJf6D5Hmu#1UrzU&
zpWpGWes`yz#WsO@z3F~qUh1`_!LsF_EO|M7b9=XhOP)`5w|(k1zxeYHA89v<c6?D&
zx!&;>b(8x|kDLBn_k~Z~Te$7LS6=n1pE@bgrSsmgr*03kC2{Xk<6Ztuchj#W&wP2<
z>5XM)UAK3BwEmjQEeEaN^hVD&+7*p)pq##?hBLh~<MOVp^`=-GKK$0_?JZA!o!oF`
z;r*x6b6O<Ez2nh(6Zdm9KLS7SeX>FGPCuR-Gw<X0(&XhYFRZ`)_~h?O8@nz2e0+Rc
z>aRuB^ACl;ycAh?$@iJv4n2Q*=wh!ABddO!dX{?ss6XgU^WyJ|3J#qg{d8pJ9kbiN
z8{VUC(w=1-Gu?ZbqXM(J39I+tGd{gCJ4TOp8~whA)2U`Z{V;0V{DU7m*53B}rM`Pt
zzHong(yQJ-Zhqf-UX}0Z%@=mvHUF2CVz0pPA^p3Qjd}f0%<^wvNgQ;aPf6y*CXeuL
zq28yRzW9B9iS6wDcSLpHwRgk|%WPLxf790K^DmQkPujc3>Dhfed#dq<*+!2X@<G!{
zW4D~G_ind)JPvl*@LIv{h0R?H+fIJac7pp+soK6cI}PfS^T@p!Pj(m={mKJgU$}kz
zVD`Ft4kyYs_Gmk9S^Le3vP-?*$=^yF|6F+d_~nsvdVM_JqvYG8^B?q0{c6vh&EA^b
zF3)Wd<#~{lgKe7|MT|S{_j~8X(-wrD?Q}BXV%HZ=-c>8>U|Y)$w-sajnfJ^)lgZ)c
z^4&FD!acUs*6eiSEmPONSTOc?rx|tU9V|PVf9QdeyR4xFzjb?gKF^fu^-7mTu63V!
zU})@w+CSGi-1PCJa}#z9{`u4IzMs-|>)7mePgCyI^74E7`IX<!*f#S1Ul!cH_lcI{
z{;~MGQL`ErtlDv|*l*Y8@6kv4tQziZhrtc=9$44-_Lv2QQT^Jl-?rz%#`aTQ37h%B
z4-c=H^>AJEqQ?7F_h<9N?zqsc{}tC^83$*-x^HU9XZr_qXs+D<)N?7H_27C@s$Sd<
znlsMVKG(xPaLoDHjb0pEHfnt9P3c}Q9XNla|3{a^M&DHRddYLVvwPQG;8Aqht=HG-
zzF&?X8?d(MV&d4yw$qPpa-Yck_cPjj?lavkJ^1kM(=C=dyVcDdzj}10&v#u<E=v2_
zr{1CILBCuoWL}GpgzGeJ)1qH|g6h3H?9s+Q-gfz^Ap`I3bKmaE*4dZ8DcX>6$2@Et
zsp+k~eE+eJ3*LCD?r)tE-WxY^?bq`jDlQEi^68lPjMIz$AA9ctmebPs{ofQ7p$JJx
zLXL$Zgb+d!LKGF{ScDKlCxj3}D1{J0NKPSy5JCtcL?H<wTk`+R>TW+h{(J8{zx{jO
z>%HD<ud7erwPwxCn)A$B_gXUsZ{~9UC6&L&&lWbVemtw?u4QHxMl*&e+?@QdVbY#X
zkD_-yyrMg<S2M<wQhaZ8cPUKhxngK**H(UtTaHxL^3K1yU|y2@!)480ZOGaEhWk@#
zT;h-#*=^X(eRD6Xt+W1I?WW#`Q(e16-<gp2+Vbhf*;nisK=+ic>+kKa@!*5cEQk6I
zOXl5<o?Sjw({DxiHjfJRFYNT(yy%onwvn{fQRuibzo6;d`VVb0wMYB5%TCYo=%ssN
zWk^_%)!L0(jV-6iWDlhHesFK~?0(M{X{SE){yJJ?Nv@`ENWFpUZY@&SUzB5TGMaY7
zh~F@E6sF%(v-J1xtvF*ymdlRrPrY08QoFRP@1m^x8w?fm9Sx#+ZX>mS4O7>hIli%y
z%7N2Q8ujh4JE3zg|4N@~)qhzt#^{yt(b<JO$CCQrSM}!S4$!^gzp{;5<OPSePgk!<
za_O_S=h8_zo8pG#4x(-OA%)NOV)U+z+{$g#i^lexV-Vi{H)X9U3(dDS9X8gyhqC98
zPdsy$+M(P#$7g&y*gfxNdbjuwudcf#eOaKNT&rQ|eU*X}wuO7|GA^Od)KNIJ&N|yx
zWz5QF<17bNvTC|zOuJL-$40AtZCG>uh5j4XGM;QJjdLzmt+8NX!6M%;t*whZf(8zs
zVckkM+_RBYRHu_o0zPNc9(YRjer(QN`QqpvpVwbD)!$on?J2`q<+A5@_TJS^FT^Tz
zowgJALsI*al)g!CL;U_qLH=*lbv_Jp+%fagx;YyRwFj14m}nWa%7$+&q;j9tK5|;&
zf`X!R*VETDO3ob_`(<QNjouRvAL#dO^b21%#_WTncvJ~?mR)O<uGYZ5q2J5X-Odf|
z68~^(tjF=oT}<~>skwVQ&j+OO<m;?g>d!`$&(-?uA2p&);~f@NT{{`(ehY8aSEZTy
z!2rhhVtr;E1s~<2ZYmoc%MEOQ^U#AHBmI0|rFDF4H2Y1(_dfcYDlSUmJ!I*+zEi(V
zku5%wI3?+Yj#o-iTCJla946i0KDA9B`>U&RL+C5*rEydLDxJ@oyxzOw@*}e|2UR{5
zMP9vi<-nS|oh(0BTABW>Dr3%m?ZkC`TR#qaIcc7WX-f2U#p|`p<yd5fH5+`~PdBVh
z6`w{5)%YDvvS-m~OuBM;g=x8}4Z<gyL=@&sPZ+G<=WvILJzgLGKDEf5axaB%bE_LC
z^}a6i?sdV<u<aa;b%RqH-5PkM_Nq9&r-OQR_lc0n&P(?E3YHAo84|Kk{p-9ni~3K>
z+~(iP&(Z3_N|Pl|3>1_fa$QHM+~-bhr+M{mSj@J{-`+arDOH)W`CzZAy-q)!b7EJ}
z%X-GtBV(z)E&s0NnQRz$+ce<$XRT+^&J(U@IL;WHyFz91jt+JM%(SUTT||6e`9G`Z
z^Sw)!>C=8OVKc+*1|Il%P4?MF!d_m~;ONsfY9qI8sykW5ue?`cPSUy$oirP+b29s$
zyEGCz)is2@Z<ViEUOb?4J-thM`BRVXy|RBi`mw!zzjwQI+?zL_Ih6M5qZHraUfnCr
zemL+(w-ooGRYxso^>SC+xQ6le1K)m)j)*#He1YGMrSXRCnh{k_?{*8SJ^60@_+ZO*
zUl*(#zq9u9E%(29CVw~1tirlEQhr348iZHR+Fg0~{Y2*%vTyTLJJgB)99K<cN&A55
zbx&NU-SCjg-%RJ+&!c`QzpLS3I7B0BQ^eJPWpj4R=G)9{)Z_B}(GisAcQr*k?!QSH
zo2S?1rfyEVpju8h_tzdWV&BPf;Z=Mbj+cM=xppSwdk0}}@BVA^4(a(Xwpv{?R&~d_
z1@7O^P3_>j!sc+B=23Z1S~G_2D%rE@*=BJ0Iz1-Y)S1xM_uPw)RkJ@o^m?D)Gr=f(
z%`u;g$}(A9DV?usEpyr4eSMIj-i>21ZCbtkeA-yeUd_j(@U#1L3*$btFXEY-j>7p*
zgY!PjlI`25m3r)On66@+UBAM->c)zBT|H~|&dZ|>y3t<Pi_<-1c`B;M))^C*d<+bG
zV?FDIR-Wcq<sMs`o<6l&QE3Y0MY?YN-P@iwpZXzW-yB6J)k|vnS9Twq-f`3L(A|})
zSE;L&L;qI8MEGZwS?ka(t6n!Q+_ryl*rHurf1~f4I<E5?cW<c5=iA4=PUn7F>fd@P
zo#`8)*g-X;_W0!R+l7m+KR1|jEg&ey_0HZE6^@$|-`mpt{<4er_M9lP>onT-<97Gy
zX7}SBtcX<dj9)$cN?^nd<+F<1|4Q-gbj7qyc)5KVJI-3YUGedN>i(H4t?~=QZ_K(|
zyR}x;-{v!(l+wA#-L7{*?8S>3uCBkCE?nW)eSMb<-}?%#^H=xZxApPhAnuc;bSZm$
zHBw5KJyW!FYMx8%mgn~4!KxbDE9_7XUUfNojn9e3lN<Xq>lw~(%u;;kPdl11=<<cu
z*VmuTT9vi&WT8UVA)TvBvjgUNZLRt~l6YK^>f3}{{wrkr+vyt|atWyBGw#EYbjNFR
zn>=*Uv)&Oqz&ux--_WFZ7)?DHGQL%d%5Bs4q;Hx!!)<S`J<EP9b~>Cfx<cCE3tc|)
zj8AIE!{hJft{8Xyoww)vT5*Y6XU^JjZkIyjywBO;6~=EE>CO1hU$S@Z#p>}drp%9c
z`QWpC|8<K!pY-m&W$*p1RhM+zv3-?K1M+Q$WUs-I$i>cybyf#Y^IE-aQPuSxS2}6=
zb$Kw=IDhw#afWRd@Qn;@CF4Zx@`IzI+V~i+N!&eJvs3H2FGhbmHE&tk;sf&orWFpb
zX1pP_yAA4_+?cyJx5vp33a4``hd%D8+f(Lje(KiSKEvFMZF&?i?v&cK8&S{4xSdd+
zuyI3L;a$5?-}2+%t;h(wmznJ|E6n1i3-{fzwZwI6&iWo(^-$v{pNy71G`Q2c`=yh5
z?_V~|+-=`-VZZ6Mf<tAp-=uMS+LtY|3-=AS8Be%&**Rd>d!-}3HCx7wGK?PAq+FeP
z`Y##RG3M1#cyH+z8t~Gi(9%iGwCx3Vo1@haMekaj+k8y+=<W_3ch%?lw{+j=FwDI`
z+1>cv%!D~AzGiO>5?-`SaCExs`(yTQgZ6E`LYQ|^@~>Ni1-ZZ7a$mEgZ_=jbI>E{3
zKL#{An09u<=j$GRuW#vN=ceRev)-$1tIwTzV9Bkj6TX`!Wq+$aqgTeO-Luz3IW@j;
zV#qn(QIf{lXGe^9Gq!omhxsk8cAhZfn*NMacg6)xGz(ih<?Gt?gJ-EnO{8@0rL-d>
zF~44&s46vk`gPL^3u-#={4DdjO+EcjDt3O>e+SR6C|f!T$Hzy{?dLaWyxqkHTNm5a
zS$VqCaA)I|9bIN`OwP4=U+We3=Td&?##M}oR2j3bX^Sf_3yn<&)(lsDa=EgD)~0DK
z41QQ2>Be|X@~`v9t2TZ;`z$-vIjiZYjBLxer%t^h4TlDs+O~Oic+aH8d<!Ctiv!PU
z<ZQHivuxDBYF6W#wOzb@(Kz>l@I?Wk20j}L6t0tR`=#+(oAhZvc7@IC>SeswVCT6>
z8^$agba_GFM>j9aDqEk}d64+tm->Ya*}1ITW^3!bYcQeLMW^du2l{9{$i5SCx@Gfl
zSEpA!Q+UU(r-<)c{ixk8`J=zpHfr|h*ml3p87BklM9n=s)OS~#u099XV(*4j-<)-y
zHq1!PdU|vDzSYVGY3KGFIePwpfx^4iJ&zx*<<cjO@Tm#^UKEu7pdXoe;K3o~-~q2p
z`*(VgGWbn{U9DC*K2U0O;Vt%jrRz4VUhn8-lZv0_-R@CUwsWoiScA@0zZ<))s@%M(
z-lB)gcJV5Tblo)n1{pUiRM9%U&Z0rPq5CVjFRN&C<kqKtH}_0e?>@KR7q00jt{Z+N
ze#^r~gKM_iWZ-3eXv5S`sXe!?%&jn|x_R?Y@BI=h^IoqsZW?>BQB>3S<<AT%w`uF=
zqvrck{jQCBtLIt%Rp(Lhljc659k-PHtG%K7J)2HyFNdnMyEbU#S&asDC$*a1q5Yir
z+G7`dJ-PJ`_hmK2b$eb~VQ}`?$}Nla-lcR}Xx60Qg6j2J!|o+7@~rf=+ayiykH$;w
zf%`u7CbG^p9;U}`h8ezG5tm-r|H+v~3L3`k4~~0zqQP3egOU7mNVr(9sIv3hQ|S|K
z_1&Cxd$9G?HI+X(eY#%v!LI1Vo!;{tSQ?KnO0MzNU4MP$dtbd)e_g)b*RFT|v3Qe7
zZw;DH+MIma%#ZhbrFeXs^}hYZ@yo96^q)MuYm>|NcArkGMfj}AYuxxp-$5=j4$_}X
z*R}1elO9%NSY&#$ZI|TTu3rv?UkLl5wg1wV<A>v#_P$7cyCT_p9=&|e$}4Mc8&oo#
zGT>?RFF_yIxL#`)vc2^J#dE`V4yONYYa-HR&Sc#t-W!6HmiiyBW7EnfFspmeE%nOk
z;cL(BIv>zt)C<aAS7Gncq+>hAYPIbeb1*Eo|AU(szKl9(+A4pO?&{g&iqh=5(FaCK
z@o2bpd)&dwFDv))T3={>u4=Aw>WQ{fhxJTNH1?_2sckRr^@m8;)x0uTvDWa_e(~)?
zE3F(lLgS(R%-KqIYe&@Xb}_!!h@tpZ$y{7_aM<-}iR<spQ|rHIiK|Q6-Iw*|zHPOo
zzw_C08mqq#n@U+uk*@niBjR+YL!pPe*Wb49+wR@<8m&E*Vb^<O$8n!@(iSan596IM
z>AD{>R{LvrEi%wtn57W$X-x7<n=8IA1C82;#7w!kaB~E0Mq?*&-MPK07R-FH?D)<x
zfeT&NY!C4cttVSN^^|OUwMEZAwg~W&$<|8!>P4#+U#C`B_&8qC<J2ts+)hvDKkwI~
z!R4D9M$BmV;btcH9{nW$&YvsXqcpv%Qhxb5YAS0VyP3E7@L*VM^V`|+xz(06_&SI2
zxMa_-_Rysd2PMwbeRO^Hm4>^tmyGM7`y~09qw@5bqc<JhO8D+d@sK5X9QWC(*E;jf
zx%!h{O`3RbkNdb*zN+uO?Y;4O(Pjn4b*-fFfp%=l+=eR?P3IWLwmIn3yRcf9W~rTT
zu6f^VM1^`|5?2hT9hcgxdNqqaB`+V`Cdzov289dLmp1NLL$zzWjFV0y11^2oxOp@8
zjpVV8!iIWvlzMl(+P+5rSfyE44Sc+YTum9}v3zjvRm1DFJ(*13yHcu0qcR=@UGcVW
zcC1PJl(SWuFHj3xcym{i5k6Pr_NgDc{)%zz1}VOMRR*RwBpnPf?h%_>OKIH7yG5_J
zR?`mnG`w0J)q7{d*D();WG}AkW$j7T_IhZoZnD5+^ur!Sx&7+aY5Uq>u##rgnaT<D
z=YypBwqjNdhx~G87w`5{xjEx$)2Z){Pil2ssq@G~QyZ)HY4>#_&sC&;)$_aEw8)6$
zP;K?mlRx;zb*g`OheZd?t$jA0bL(`#-~;3FZFNL^k0yImSZ=a>rMlALpx%!MKKI>o
zXm(zcqGg#=Htd+TXzL!Hhe_f4)M!E7E508!SB`CXPxis-yk5PghBd+zmRvQq?>y${
z!V`>h#t8rVD6Xy8Yedqx{ij1aRb2gg-AKEv+ozYtN1s{fZB)>D^)P-HlI)Ed@N(hd
z8#~o*Z0TxU*rI)}jNw(6D(c^tl}{+LFuv8%n*KwI$H{_D9dD(z>(SuHw}OmA-nu)~
zoL)P9>04-BFn3&b;4a2$%chF!Ci#rl3aEXyorzsFZ;eKw3PT&7$yv4OOfQSs-N*a&
zRdwZi66w14zSK1uaq{+z>7lvSFJ7LQUwK~cmnkn6_y$cp?^31wn~}WRC5;cxYTBkW
zku83)Q#&uAm2tZ_Ic`=LYnW=TpT9h?$hS>?5YLsRau73E@w3l>dh@(?HH)p+eN9T{
zY~A-`5)R(h{Th5`z4d{y)DOwOEPMMWdS>pAuAfL+QzbQd{rN6c8-D+mq}My4LtpDx
z{!17aGltPo=xu4ytH-bmE$5Z9pWps8`|^%cvLR>Z);c-;wyyu?elv*c3F?TBg7T@*
zX7;asJh-AcwEDKgnz8OpV;T;RU8B~+@Lf{FZ{jzX*4$I;C`1>WA3DXO)2qI3hvgpV
zVSC8;MpWC|$J-l@KR9Ch@Pjuu@tdoLuorLM#Pq#cv%HbrGV1Pgnvt!lG<Ti<#*JsX
zudTYRTRnH~^Tdl|Itqq1RS%EaGw0Hdt05JF4WC$4U3{eP(U9_e^jAb}^VWJ)kNXcP
zU3OHd`sv0ix3T@Y=Wg2I5vnoGrNG7Y$=gw%I-j##_E7w`|4!-$>%F?x;N!u}>$|;N
z9Og$m)}DAXd%pJC!-L+tbsLmZb7Hnkwq2^{FDB1;7ky~Y;Spo%Z-~<NJ^EzYr{Vh(
z1NR;1Sd_7OMiAlKCG`tEx7~P=zU|R~Nqq}<dcM4rr{8Uw(($ex-?UwMOV%L8z>VKO
zq;k-4pHaHcfS`KK7Su32-eGure4W<{eQONg9N+Hw$d;MUdUO9P^$Vk%QsQP<<@vQV
ztY{(2PO00i`mHd%q=ToF4(B{S+I+1c^VmrD6@5N#XkK0Y`Htwe2UqRa@*NPfBz^vc
zF*gUlO5VG<*~0yKtm7+PSNBC!)mImG^#8Qz@$fozMxPpD)Nl2`Ju2@OUp=Pt-q}Bv
z?|h~BPEvc7XKlCC&Dbr(ZM^o{%?o23b*g8MZ8Px8nH0_DiyP2RO8%Yb{84v(uhdoR
z{07+{4NN(-YT}iZnocXN_nSw08aTZPryXx6^6gP<L1gT%!&L^pAJMV<r!{jNU1!DJ
zw|!%2m~$yTqFy-T0|m;ej>4)(V^>V-(066soz}fyd|7(uez28C&7h@g>lu$2w!xv-
zH~Lk{Uag`A3%{K|)y~Q~LN)QW%a~152FM)yo-KcBd8%o}Ix9%OCsO$<^xHlE(bnD1
z{pMCWQKLcQnQC)$-nM-7ta|kEg0DMvbezZU`;vd>_g*a;-#O{P6Q!wn_04)Kv|5wo
zdnnH1?#9YHG+!IekK>)Ho+5k-L+AcbxZ7ZFd}Pv&{d&9KIaxORI%QG6@tqdm?&;Ra
z4}1QSe~K?3M!dVVzTU@qTQ##@=V^z3)QFs-TXWRwT`l$cWj@=*?YWe1!L2HLznQN&
z<&|+^c16o;*Isw(dw6rQ!l%K?N6#<N-!O-ACG|%cU$;2)tkYv`<40%uxmh)8w({*}
z<%;k6zI9!<FDxgkimy!eUb=5=|6TD!hdnpUERVJRaeVt?qa)=vPF31euHpXIgI0ga
z*CYKBr0_Y-p7PP;uz}JQ!?7ni+-Wtd>7GgjwVGUi`9N*_$Fxz7v;}V@d*(?~Ha(uU
z-@mA1;&Z3t4omuc`FheKs@H*4v8{#&e)gojs_HD##pF`G$O~8E2S4c+u_D{H=P0`)
zdo$mxRo<ao@KODWw)l;>sWjfutrs@^RJ4Yb>!xPcqAIUCwByU&gtN;|zaP1F)TM^a
zRC9RVB>8vWF0fT&N2A}?o_POwYTGwmBbr`HnAUpQ_&t55)J<8K-;C!fQhZPCP`Wv=
zwORQtMwZ8WUcJBUgIjjw!p_wkq9+c}X*^AfabkJKL^=wlOCGL#lm4u(`p$S2^E*#o
zRK2$RigM>}b}lwe>o2T)sisWkDEYU_<C)D;$KdS&RugA_*E`(Tr1u~*m;Cun#yuHw
z?RBqXuVpebso%=<beh$?|DbIXLYHlvvrKEjgmyz`WSA~mU^8fX%(@Fngzs`Uaotyg
zyI&bUW>L|(n|r4fygn0r;7Rh#<pWbM=s%ul=W9EH@-k0q*EUZ%weaX+gRIw+O|zzY
zHF+C6&R1K{>Dx5-x#yk*yDHh!9!UQ6J*XcN+v3KM7X{yDzI>=Ps@u1@;T^54pR^m4
z;X9z;@*b2c+BO{p+r>sp5_YLysr0e>jc=JhF7DhpzG5T$<6B3sy?=N82Y1Szo|&*W
z>BOwpCv(Ouc<^w?-e!gawix8U3ES%O-DkIo{h|hDBg^rehB20of=hDB#3Cc(I=gZz
zh9n;tIaMLx{Q=F&>o)sN3u+N!8naO*J4YJQe;glX{N=sJcejphCQlFVUG-@Bm{Y2I
z`^)NlPg1dNbC&uRFO`GVt(y+AE9$Lh{7F|w_r-y9{~gs-x-HrFZ2qwWS6=J1Jj(MI
zDSV+{UOl~h#NNxe{*oUfL!OU``|)s)b~}~5q4|@?#5}l8eAT3MQLJEmaFb&bD~FdG
z8h9NvJ)?KJ_TJn*%dR!d95`xz(F$FDCz0BrZys}kRI~%9Sf$0@h^>0lYTxadeQLH>
z>a`{8@fU69w?FuuUApeZ?>=99cenmDaqRh%2llM{+S$)bSGz}tm(Mpwjh4L*rw`PX
z^3CMO^5dtyehZu9)bdcD!XF*HUPrbbJ}za^JnxxN+A~Aa`9?+x-|idAr~Q?-u2<`>
zcW2)-!<9N#eQq~yajp5SD%Bcx@b5B)-}9vKEm+;DomuYMb|ZFexp5(CMpFB4n-_%*
zZTw}vMcS5I+rCjJ3)+ix&Nja^-L=OIw=d?s4v!s_UhdiE<lOngU+b)z{aGvW+`-j^
zPa3b4{k!A`x>g;KudBxURs8nJeIi*e%|(F7n6l4X*rU5CS<_5f>nxAHTLCjY5L?ai
zGH(^M7D_Rc)kcLoYml!KCaoVP+|lGq>&GLqM48N66QvvV)<G|!Ezm0{NiDmM_C#-@
z6i4yRyX3Dv``*QCLP_Bk{+7o~8^m^%(;_^=eM$J`YcxsUu{csLN{9cNg3P;?u#eiJ
zx6l%I^7V(L_fdb2_ZQMfT&Dmfdt^nW(o4P`(0}YszK)N~4F7(<UU_*sE1;b@uOd%p
z9roqx>hNwNZ5r__osT!=@e%gqYu5asy&I+M$=8FC*6sPZTwIsOQ}`!eXGMCq{bze6
z<ww|)uWusd*I$KCzTU_m+A9g4D39{>Kcskw>z2;XWO=?^Lus~UrNb*<pF?_2{m;Tn
zw^gzRhV)&GuvZZ?nonsvjK7uGW2$Cpx?!ez^%ibUpmbxhcyt1K3N0x|^7SI5cPf7l
zZyMzk>$3Z(s2>mH<yMD%`T7sioR~j{cd^`mVNb1iKL0Z9S^uKFpkK6?BDdF)F#Kis
ziszOuJAA)rPd;CMnf}S=v@g@1eBSvo?aAkaFVmiU&h|3x$>&us)1KP1;`etA%1CGH
zU$htWi}q4}(Vl#M?K0ybpZmH@d-6G{%d{t-GrCNB@_C)hv?rf?xlDWV`H{=CC!fE#
zOndTqhRd`kpAWc9d-8dE%d{t-TenPm@_BFn(w^u$<@3@?{j6vYlriH`gtRrFy{gKd
z4r+wzqTH^@8leo=WsOlAv?)3aZH5Xzo1>x~jR5)luhP7*!hdzlf<bKEu~!>4M@9eG
z2NmOnzNi&yi3)$MP)BqqItOKrQ}0EnEgFZ8LQkU(s3INd7_>4v3GIkZMY)!28oC6X
ziHiAYXQ3jTK_H(mRhmatgtHoE{vft|+INvIpHb0n7N8<MenUmLzoQ~u6!32}N*KJy
zp%qbvcrs=5HcFVh@1fOE(cx>Lz0sQJAXF0-^S9PPMYu#CC7*+|c>kw<tqt~SV5cqG
z6m5r!_Qn`xm?|?t#dwS~ko*&QBcIn(wv7Fs^ZOC;5aXlAXhZY~+6;Y)iawm%D(`9N
zThtHDLq$HkM@#xm`8=CaIf~Hu_kR98;lR4=11kE>kMeMtu`i!9^Y?OC0W*=tV*4Q<
zM=@xS`tS1S5X>u}B2E=iaeXt8&pY{t{?x#ph@S>p7p;W~f9jyZA1$=RANkykf9Q`2
z_Jlu`P~nd%D*UO23V+nl5`X0LAO4{~^{^-WsgDYObWq_>BUJdKhnDywpI1;kUX${z
zbowkK9ThQOj@Cj~pxjo-)}Uexv=%M#M?Tk|GzXx_|I+?MU{BP?t!OKB7n+3bL90?O
z_o5~K$mf@n=AHZ5p9|O%{#-;w`AI^@qgPQ;Zf>B$A5o^{^QTGkstJD-Fw+CE-NK$o
zpH!5hBzsiKoqW!-;%|t4a+iTUQD2{-)zLSl+{x!D`$KoRa(8)hcVA1nlg}$A6ZPWf
za28^(3g+T|Lfq3R$;bI-?91o-lI8*XIi0FwPoz@~RHT!*FI$6ZqPNgGs7NO>kk4iH
zhxxCKJ(2(QP?7%)P?7(-sL20DXo)}a`J`kkG5<L{EwCrT(-IZoX^o0}YlALD+oC1@
z$md&<z7_k~A7ku^d~1)2a&3b4M?0g#P*b$TANjmR(tJig`_mhHB0POi5uU!NXm2dh
z3+Mp!cYow_!c52fXMcuZPvnmc+5jDfih4Ezbwfv@CH~0gxRK_*`Pm;w?1}!+3DrTz
zqC?SfD391=<Ixg-<a5VJbISbe&lK!c$Np4Ql=W%oDAWUWMQ5TV{>bN5k>*?Z*&k2r
ziFBTWigccbigaFpI-?8G5`X0Lmq_!P{Or$W?1^*^MMXMqK}EiAMdza1&=P;-^L|L*
z;Qj1RAohemD^SsXtU}|^HE1Ea7A^5dJ}-rA4CX)k6NNpIU%OF}UwcuJU;9y!P6yBu
zf8=vO$V7O5_9qT|)iFPcigZ3McOQ?6>z+bO{E^S2Ak8uGvp*NGr-}WGXmd0PorqpV
zr=ZDbi9hl=3I5QZRO|_V?x4b-d#Lc|0V@1?h?e*x|Gr;(Ci8Q6-e6C(Z#k$Inv3>D
z-=iY`KcK=N6OeyrFMTs7{1NSh7{iF|6ZXXMXH>Ks1*kDvD0gqhzWlrQKkUDrVo&7L
zGgRbLCMxnN3l;rWHd+!N`S<10cjrIHrz!oM3ikC;QI4CVA|9>K0cdMf_#?(c^6$6B
z)N4|Hm%h($gFO+Swy5yW7;TDnKt-H8qHWMlsPIqpKk{#|`98DQzta6r7wifDx}uHI
zZl&DGzo-5~cSGgwhRNLxm%H=E5Bc}eQkyQ)L8PAth^@EWT_040-vSlwO<%MI+7A`w
zr$1T`wM2E%0jP+l6)NI65Eb#XMnyUeLOY{_Q4w!XkbgTZThG1-hbrm{VjGD)5pO$G
zT;CoQ<zqA|%9|6~6&-{2MxD`q=y=oyoq*b-lhCoK8@d{uf{N=~gZ#T@nK%35`bwxd
zh%HuDeElP6eU6W!lhEVnZ1e;w?gQe{dFUxr_!|N8Z-IYrpVTo62C+@!`Xc?NqaxjA
zpd#OAq9VOKQISq_(4Oc#RK#lmD(dG#bQbD^igwW-U5+k7@1jf42k0{N1saIHLRX=0
z&>&QV(;ejB=Stu0ium&<a|W>`5Fb&$&!HmxiKqzoB~;kCjPet&^xRa0;~K{SXbLLg
zdJ7f#nu>;?cTm$xtRLE!x(zx+$_yMqL@)vpAOi|Ovp?s-83G^@Vs<OY63{d>2hG`|
zAXD3`Ak(m<KSzyFchna3f=KpLAd>wg$YVbT)sDs;mD&Pz+(&{y1SCT~=<QdKS%W78
z9Z-<PLMEujD98-K<e-Ag6@noiGC}na;W*539317k#}s7Q$1yvBe<$$|Cd4bqq9N%N
z*8!c=3NlNuKcgU1PT)F_0jg)Y1{e}XYjA}?h=wG{07Wa>DzJbFAZ}JeAO?~k0}4TV
zAonm}39b+Xv5*QmpiD*32Mch90EmVp$b>=&VBDQecx-J+SBQWF$N=RL)FZG24+w>L
z$Og5MwEtiaVsH`*X&?q{Mqmr>5DLkV4{B6eQ?P-E!CW7_*bjwckP3OAMkm}7Y`_D8
zAO=z(A2hfLHUb-P1%C*IV~`3tpy)tZJEtJiMh(FN?7;&9Arj&t6>>n)k#Y;BpmCn^
z28m$9u{#7nCdZ12lsOr3f>6w2Aq8?k*@?6xJwve5l6^C<0i%lwvOLhaL|Fl~B+3is
z0T2zzkPjMTunVF0h%Y2T4rr#)cHzbg^e+=G$m9V)GMz~*_DwjSqEbN?XkI~P!+s!m
z`&E!7f~tQ7nLR{8Cg?4yAajOD$N`hZ6=YtJ2zg+%1p5#KiBJfJ0l0xkNC&m06=arR
zf0H_dCW7L!3Nmx>hGUQeddsl`!H@{~pdW}CL_t27uHgD`4Dvv2Wd&KvY~ps8yqiOM
zfF(=-F9?NrNQFYsm`hm!OK^uEh=ydy0p)q54}K=5E6CD2U<QRC7D3VnTW|+4M`s8`
zK|G{F4k&jdAHg0xpk=>u(sP>>_6tC>6J-XRArN9A6U28Zrr-=>?z|XC14UE(02}av
z2uOq+Q0;;nm;eC~BaXXr48b7lMmWG5A|VOX%m^P$fM7^~91!z)nSm<=K@4PoS`W;@
z8G<1JvO$9m$rM~66cQjE3PIbPb6^i%5DM{-4uzoIi}PR)UJwfLkPc#UAw95wn8&n_
zXa*F5bsy3cf*=v{L4!e9MmfS+o-z;Iv&a&jD99MIi}9#<W+8I~(|N=Jve^$rQ@k*r
zPhLX)0{mM@zAK^`v~A@71omA~BX9DVeJ}PSpV1btC0raAVjkr~`@_CxGxDhdVFr_$
z#0M?Z#~p5B&QUfv)_AEPb8k+aVm}|UAK|7V<rVyKqp!;K*e~?Mf82SoZ{knfvS<q+
zkYf?}gfzkqnd1C;{6aG@x4>@d7e$$}66NL<?Gc)d7C2UrdGH|5pJTm6_>Eel@u(x3
zEYyQ~i)z!!w**tLT!z2+ANZC$z+Nf@SEX)p&OeuMpqZe!m@uFo?+AkmZ6e2p;Q5#|
zLxVAkf@7emMO|ayX!xGKjW{F|PsLTV4d4y2kPj_`sPhmADWJHTb_YBl2C~6$O$C`F
z1Vaj_t;HX3g$PIojbO~c8)6|F4A;@-0h6rA)F6{|k8MuAKTwo;a_mgl^vKfy>_l=L
z3)#dY5w&SXyf~lAzUC6*0ioE7hC&EhUqNQEfv|)SHi(BDu-J$lP}@WtAO$owSCH94
zC}e;tg~kZnAsVtlJB&6GTp<J!AR9EdU=FSj3aL;CEyGDS2!MFV1l0)Q47T78QIHII
zpt+T>fjdM%0%U;BHta(HB!k*^(hLG27ScgElC~Kvz!iev7-WOm4#Een5DH092zooo
z4{(PNNQ7)q-9;F|20S4OQb92ab8v(JI0osUx|{s_XZt4w{z-v<QsAEy_$LMaNr8V-
z;GY!uCk6gVfqzoqpA`5f1^!8a|8WZN$V~R*hupau>wfXPOw4^IzI`jKS3F;DBYvC`
z^Y5PJ#~?93Zu#oPbG-iGyqJ@94|X5GGbq`j+1JILn15Bwr7Gq}JycgF6LX-J<6IJM
z#rmL2*$<S{9Q$q>{9ey-Fsz4?Z2{*NLdn*G{pldq550n4Vt#xvkGarpXbY|@<{B1j
zVzg$zn-1^$fjRUB3+M-yU<EPQ9fS^np-{4kuo>cBtb6&@kazCDuno_Rzy*@IwpgEX
z5yZh!I0gq`IT+)v19XBIjt{~i=*;nAv<un|%%BIDL&?^M{q^e10SczX!-u%}!ga1W
z2;GUfSRe5Q$6|fLo2Wl3)&ji6zKDN^Hq7Y&O`&8nVZS4E0<k9GZQ&o+5^I%+weE(2
zSffg;VV8=T9s8rPC)R_z!?8$bu}+#Q$6|f7lcdpdSOH=?g|@+tSUc=4_Qe`zVqGye
z>`sCEn2qJw)}VNutA`vrb1c?@GRN(AXapbN6O?TF>^Fm!U;u4FY(LQQxK)ITP_p&L
z+^G%MhR0k(zY*8gCEvK#1k%$De4%1>e*Xm(s01ZjYup(?$u<qUGhq&hO}Je^T8p)s
zp5T81dKS*Xd3dc(8Z_m(D(5D)<yj)nL&bVOeL$>X^8)k9n7e{lPh}Wp!{Hg`B8|mb
zIP*9b>!@U5CRD6VG61!LSD1-;?!{UiDb!0*2k)RI+b#ALt5d(g9Q(cC4Q|AI<I0%D
zsTZ$@F$8n5p2b_viS-{$TavaM=W{H=A?EN`)#m*|DA~Gmz6ZR+j#zU+%)S1B{Y>nO
zHDSY`WD{$JUja?*oyU$f?goKa%R2<~jdHtUE$L&>5c7+|U+m0*MjUU#e6!r1Sa<s@
z)W!S)_KdJ&4D~q<#(aa^o>-qb1)5-f340^4V+Ud_<(lM=Sa;wP<{}Nn{QY0pFM!|R
zD~LJXzoCAdo5cQP5c8%NVJ6lg6?1f#Y+cyz3d=dKkBYo#BR?<Z;%>%%e-QI&H>W)`
z=Df9fiEHYiCglM0ll(T&0&NKu8`1`ItS0gmw_CYxJ+uLcEd{*^GvO|5<NQ6eO)cJq
zK+|A5X6v9jc~_%U{+ZyvXrBUMg#bH#=t@`xL9iP9VGXQ>VCacEb6Cgzde{IVun{)F
zW(WnbEkVOz3xq=i1i)6<2HPPLcEC>91yQgY_P|~cn<@GLb`Zu<=tJ1az9aewqS)`K
zPFZDt5Bt;54A{&52=pmLvp*Jn4*S^`FZ%3)b<|-q%wEC)%=@A_aFBgl^fkn=KOg-J
zhu9y8{sxEH?~N8gEc-)I8TosJ{dVjtv44X7p6n~IAIH81d8x?$G4=;zegneT4^*e!
zK<9FN8^YOdkKTeU?AxQM5W#*wv?6{SXMZ;P_aTyfS2P`Vv2Te!hTZIUL!ZGu_7A8N
z2T-AG6;ZZyFmDKAtAd}Ry%24KGW%6Q4Nl{3Ed;|z5M_6^ye!#qEXv4Y5P7>4mO&uq
z8`Y_I*t-lV^y^DFUIr^+BWb^wv@ac=)wtP&`BKblaoyT*7PH6L_riQW#KBQ0@k_X0
z$MJeth`SJRUDyD#I5!98fivgCwZ(Wq1%E5SDeS1C``VCCu$g0T^f1JNTYb_P^?{QR
z54wiDD}x?^Q*av2KmweFb8sFK;R0NQOOOPY;R;-ZWVi;`L2TXBi~UvOSRJYpE)7T^
zOokjsg9zt-ScBPmC>e|RVz!)PG3HuDIt0N62mwFhE5=x2TyzYM!ye2|peLcL`oFsq
z>A4p3V3>!!(te73SdIA_@Z{VwuDJ<*4qp&vR-CtnlI;X(c@j!C8_o@tpC5tR%lF5i
zF7o~Igj*3xws_p1D&>dBZ!y29*j&*m@_lja!TxOd@p3d!z8{2cl<#K~pEn@3aLl&K
z&3B@^<@@4X4Eu*m9iJl%7fOZW1m{l6&tE{3<oj2#b4_mVI(k#Sf0gss<aSaqyDK+;
zh(4C@*CyVYrQ&`Q`>Ap_&$07DZtp&359Q`rn7xvli*P@~{Du5nIqIN-yv~YqqHeyy
zZjRi3E}B=$?R)k=$d9X0cg1{+C0kX(RjpLmzHp7-<kt~)E;8;&l8-|)xMofHb;X(o
zpYgMx)OBj&Z>>^(7jo`<sq<Q#t6S=P1NL>~$9ioTqe976o_<LIO17GWsdlMwwPW8{
zejHAiw#&n%PF!k~icbgZbd=ju#J>u1KYL+jAvagTzOvj+Mb0b9?Nr9BiroAxX)MN|
z%?M))5Oqn6Ap=pdFUHAMw85hOh%uUI-^7?rjP=FXQuI-x9})e47z2oYup5|x=u>(_
zNA==9OY|$EUl8rS=$}O2BKjj+5PhKNKSbZ@2xCEv4_ra?l`}!~BcksS{ah63TbkV*
z?}5D#4f{ZByapg+*do0*X^lF9D|iC0CrIBlMW88=4r;u&p%3;D43Q863BWhFvNXs9
zzJHKD&=&7_7=amBf-N{h1n>^DEDf}|Uo{6W;C)A#Ccov|Kp=!d6r@5XDDyM22IxRb
zFadM0278zQ*^m#iiu4Vj3F4g%YY^{ictS9!Dsc@+fegq2RT4zJQ(*{ZU<uCP0ih5D
z=DZhS4ffy({tyJAAl{isg$&36<x1Q;gCU6bCoRAk(!irK_8|#UAp`QD5R`exK@*I?
z3@pJOJRtz0;20!9HsphT6^@}0jH(h&um*b&FX0A3EF?fOq(K2FSL0e>4%RRMJRuaK
zAQqA#9aJf!;{MJ9{2>TJLDYo|$bkaTR3|)O3AQi+JRuTdAOZ3~pE_d$o)8JCkO}#q
zNd3_eb%?Th43Z!XvcbI$We8Fr19G4cRJlJh0duehdx(SrP^2!JfH_QnP)LCcNTwap
zq0h4fdzb*?-pQ19%o1!t%$wu|(QphBLA3puAho-+ANpVfVtj1_;-&T=h=l~mfILvv
zA&tNkEWiew!2?1d3SuD%(m;GPqzal~4)zcL#~=w(Ap>$iQI~WBBQOI?umxxEf<TCd
zV~_-CPymXJsNY}>{tyERkPPWi2+Ded0ZhRH;>B@e+<+svf+qw(5~M*k<bz`q>_al7
zK_=vbxW6_B8*qdK(AKAZg9(^}4Fp3Z#6kkNHe(+WAqCPQ2lSfbCzyjZ*n=yCKqSOK
z8Ys8G9@v8`1VaQwLp&rw4zz4Zd4o`hh9pRXOwee>d9Vjp@C1Jdh6pHtLa=F#IRrxl
z#6TKkLLR6ZP<Frw%wYnUwk5A16r$i5Btj|_fO0$13G~4P9Ki$BjL94Df<Op?NQi|*
z$OiFJe;|ZFEF?fOq(MHY@&2SX=z}>pf-8u%<NYB5G)zbj5bsjjbi@w0LI4Cq1Vlp;
zWP<pBL>u(M2+Y79QeZ-7{06Z$bTAx)L`VhkKBXGyfH_!$BZzgD#k-X;kO~=)2RdEI
z6DWDl(t~|}h=l}5fdWwMN*urh%)th{AOJ!j0g@pd#G16y{4=N-Sb}&@(+dJ11QH+_
z(m`fMo`N=*fhE{O2t+|DWI!IY>`oZK0=yv*LLnK_AR9D#5HBzU8*l`72!Tk5g$&4n
zLTK3&KfxSqzzgjAkXDcY$&dzOUd236wxAw^30Q(7#KJL9?MpmBAB?~ZEWr`HAQ&Pb
z1`;3}#F`bdez*l~umBry1a}C5C`f@!$OohT_zl(|)&djjfp~%VejpekAO^%Y1bLur
zNt%EOn1eOggDV6>1jIlBi0=jpKyd(R31%SP!_R>N5bxvbfGJplEr|E>Js=38As)oL
z`Du^|vVp`8G(iu{z#iPe3j!b*VxYj9I1eJu5DN*A0vV74g`hbYf4~q-!4f<m5@I0%
z(m`(scEA)Yzy_Ql2tpwWVj&R<K-GpkfR<na=3ou>;0j(44aXo6QXn02pb%OP#Xd{`
z4-g+L20|z#g7}U=V+8RBYjAcZ%#aG15I>Im1;z1PA6&r;%qOA{2-%ZxKbdpj1p%)3
z3#x8}9rE09JB|2)HzYs~6hh1CToXLNYX)(Fcu@5qjldFuAQ{rZY$nGL0r9i&1N3L(
zKjed+C-DGB@bDu4ARTfbVLo92u~3~mL_iEgF2oMxfUP%a1JNM!A+Nv;ynRV8NCg`|
z$_7M&jXz}r5+M~PEaDiV1dB-r$OEG##1lNgJ^=qA4YGwUCBDl@E3g57h=oK*fvDw_
zuR!7n@sJNXD+n8SLK38b&T7&NydenG)({`?hhR7cIiS6kbO*7XmT53<z#sBJwhniY
z4u<PVM{oz#4TKH+As9?TNIyu1bkN*Hx`P)4g863lArMqU@dpAS6jH-Tk1hBM-k`CK
zaDXd#f!=of0!Ijd0#J^`%`T21781ew5aEGf5Fd@1fi(mkAw3`)BI7uBlsG~B1N?bN
zSV1S9Ye680`M)9|2I3(JQXvC!pa2vf;Rk4gJ{W-+Sb{A$gFARZ00ct>M8h#igcL}J
zY{&;O(Sj;yf*u%xDOi9FID#vPcf0)|2tpwWVj%&NAq_Gi^$FL>Ktbav{(*Y+;^%?8
z)r+6o8gLxchG&)>i|3%rI2O;>4AEogNzBD_*|8jp=U<Ib@f>hDdYtnWQ1Q%I2Nll>
zCvd+YeiQRU8{<~obLVh=EyqUerwVP#vo-d6VBQsX;#ps3j>Yr;?x^^!^ECPr^Vg_&
zwt5K_&wIO~;=F}ir=WK+cg0M^sU_;cvAB;JVZb@e#Is)Uo6<VW#eIr+COeViBdB=J
zC;an34{<D>af#zhj>WUy+o*VMEPg+*;CMdAE6}&-eN^1*h-Y{`IiAJw1dhcs!AjT{
z>uw%F$8cPP+Mprm6toTY!qFhP{Z6QO2HHZs_;-}o*t6pN6jc0{D4qk0XTR4t7Qb(a
zXT}+ve~R8l>vLW_LvF~i_`OElzYWLyF~@;$44!k`A9EM<3dg^pZn*PBvp5#dv+HnP
z{2pADWAPi(5%ekMDX4gs{uzD7acxxmeq@X`LA|is8S_MrU!yzG2k1xiF***tgU&$H
z&}(QBIt_Q?_t66!KjGL671vz?4jjKgz0hdPAE943?uDjvd;=|ywnhJ6*%XP$NLe{z
zMH|w|e(DT+mX)=4a&vBPG;X?!z1zeolU=4yadEXDJKbZ3{Y?Jb&zL^e-pSov?2er}
zWtI!->E<Ea2^W%6dryz4POULv*lwy`&XN3-)nJacOn2qqb-={2)2GguI?h8!e{eIM
zf$km?-6qauQCFRwQ{CJry1Go4RhQ|hck6EG>D1oP*`=M+SP@2H=HM`Etb>z>$MlI~
zW{MTPYhgCQ#ns(qdTCSf2uDxd$-|ZF3O9sTTIANn!Odw3>q5J+QggAL86M7j9-^l{
zTw1nyhO8?4y{FEc;w)bgSNPMtN8d8+SgMQXV!dV6q_i|t5TT`?Do@!(+o7F}*r~26
zD@XG-)y-|{6bF*Y({$#P8574(adFmhojPTF%dr!jrgx=&(JD+39{m3|vxAt4^_1Pw
zCtPh{xvA49vi7l)tHUfO*O@NDiCCA`6AhzH7+CJ#*L?TJe52&<-`9K>YY#IVkbW0t
z?RqEYiJqjLx_S_1+a&uFXE;o88Bemz5*HC+5K+<v?7O%*u|D*a@xKQ`gu$9~jimFg
zE>p&PNKq1g+G6HjQMem7arz7o2WKKcc98bP>qHlyb0;1O>eeI}a~w$DEqfHFALXEU
zP2@N!T*a=%db=g|Wu$+!xONRGy`}Up<5*l{U^$0gp6=5{IAx{Xw8Tw!&S%Qqh_D!P
zEZV|><vb+2#cLlI=dor5PO^z-lOm6qCq&kT1WC~-Badf`Om^@foB!AHS-iXPe``KZ
z`-^-oK3AO2Mx=i%4U)*Cel?5p?XU7#*w4nk$mbt&`z7mN|5-i@H{uy^Z`_=(ReX(-
zd=|fx{ZT&4l(5V;j{Ma`ozQONb4=|&&u0g*2zYy=lIkqwv#5`Mu>D@2y*XK2FaNkc
zi@Nzo^;y)<Kda9noGY#)|EkXsnEhFOw%}YN__O+K_WSu?ug{_mm9Ed)q<<)7VkPE=
zJgBC6OZC|l{iFIU?5AK~<a4<?#r8!$+i?76`7GQN;zrcxb8<H#pG`RaxjtLT+w2@=
zPO{CF=krXoyU1s)vh%rAmHuDL>p!Z~|F`7zpVeuR*QM*UB6TN#bX|ja`?_W4wXh$L
zeUaByw0|wHg_~^Lh&p{!?xrNK|Ex}DRKhY_B<+D{yTeh@Kd03DIj<dN{BaLm+;;y}
zofd7EH+~oQ(ZyY}D7OKa{Wt5e=mYae4@Kg*muqDe$4Tk~iQ=Eu8R5o6?q*H>f2F;s
zmw#5zgc}ds48@LXgJL&gTwu#_aXaGX<mvG5<BXC%SGbMB?KSM4mAe(`V^PNS(s6ST
zJ1cem6-MhnaZ|d#PF2Mc8&ii!dA<V`{k5ZRnR)(u^%mo@|7o88H|w*=^GwpEpmK4Z
z&n}KrnRzbUv?N_bInizOuk`$@JQr>z;D*O_vLd;gU(IvjHWara&xh;%>w15c=fX`2
zZbY8zHU5{IU&-^NsyJfXNnUHBTT#(>%bNaGp8tFA{i}Ii+z0=kt><Z^OHP&I{L?Is
zQ<-@#+~|-lBG1p4a`RVtF5HOUf<-+K(=X10U(IvjR{VY}^8AC`ZCUkPxJkr~$n!JJ
zel5>S`tbxc9I-LQkCf-TP|=SEwfL1h|Glc0*^igB?|+o<|LwXieuK}fR-A`X#qlaL
z--R3TPLas>Ayj%X?h^U%SNSg7*x*Lgb%R#_S-uOm0k{?U9w2vHR=x{2@wgHBKD70}
z!f4I$AN4_^eQzyOQ|GkIUHZ@SCic1Ql{rFB^4-u-^2cFfdm|o86!+Vrz4?R9tPO@D
zU&ZyryMhDD{i{BUKJDjzTiA8Pyc^dpea|fX`J*wm2ya_?c+I%46x&!3ZPRGzMR;TW
zExZmhFqX>V|5ljA{kJ22{@Fdl1kU{@@hM6FJb8Rdr+*)j{%uO7|LngPm!Ip^-%0-j
zQApTIr+;6O{{I%<zn}g;hxxyi{_YyZ@fm}NtQZCTMf$gur@vJCe?9$+%fSDB`7bFi
zrZtPh>xhUkxE%}->0c_mBK1Z8`zvMtSHk<>O8XpnTuP_?K#}(CeouQ!{@;ts&*kWU
zQua&I{#Y#$n&LLHB<%-@v@aFjznk_yhxfmg_7g+|*h;7U5Rvx007oC^;QAky`*^7>
z|L>K1BhlEiIYLR=4;5)&D!l(m+W$&;|66IFDUVC(v>z_g-uU;l|BuT3AI0V8a`bn~
zeM}vZ^8cRpBShMl3h&=d`=7)6-%5M&o}$>gfauChz)qxn`{J~pDIf5N_EVhugYEb6
zju|I^9><C{_m9RqVr*1;d{BB!Bi@x1TW1hOqdklwOy2(<CXvKayZ*lwE|JC}Tz@vE
zvE|&)VJ>M41Nl8rY^BrDfiS21TbO76t?>R_CPW$jt8_HeE)G-abaWz2Ivq;q?d-pu
zjz5R%@1$dDsW6N2hsgV}gxS3$%<_i#SIgs*pW5O7q&$}7tv|nuh^-@twwB<?T=<tz
zI!vVE|7Mu}P8w>~CxC1s-%HYPJmFO{k>@*UC>qqi6W*Wm{Lji_Ng5`}!&EvAClV&d
z(qa0WY4~%P{wHaePr4{mmtA^NPkv#oc3plP&`~IRZ9ZSgzp~e0zd{3|qcGu?{|edu
zcKQZ~Tmq{3jQemT-SOJoCJ$Zotaro?Fwdn-|B$X*_8QJ7_<>MIVaeICmCnphd^^YU
zL*m2ee9h1CUoDUKem48+bnDrbQ+p8SUtJ?~kaXRYX=+(tLN?`o$-Ot<!FFKRm(@O8
zw~g28Fu=X0mS*fuXWko<;#>9_rn@Eo{4|xu&HlD+R%Y<q^PBdZZE$MyMeS|3C&w*M
zPrl`t^NPaS)Lg`)>@_{h4-odsUW3z&K3qqk?6o!LN#QGd&CFk2<9tB}ab2%&F5w}E
z-+L@;)BkSwind+KIj?P((S7r{MlA+9A1<)txz!3XMMohj<FicLvwx@iMX{Dn_b1z4
zm@zJKhF{C5L$60=*v^i1|Mj)Oo2m)_*1XsJ?(O{Whh4u@)p||67`S2jnXwxNb@d%P
zBH{M>9r}g5<J3#oTi5Dp{eaI+2Mm0@=cGkPb+;-DmQ5RCIcR>^%KOcGD=yr@J(iRo
zjc<mAZ(Ot5IP3l4z}dA!9_E+Zzd&ZaBD~XZqX!#|ck<raPN_Tx8i%#|v2=jV)UMZW
z6$Oud66xFj$Hk;e^{=hU&1=12e?#6wlKd-BbG)^n-e$*f$$5RhwygZM{QZS#1IC;#
z^it3b8~ftadEOJ^L6eR`*=rDsxnp${%3k}kjZ|JjPhVYG@#UmB%`YCbY194DOUL6E
z8jaSoRJ~Z~%I#>`!?C<m)K2(U_L`nHG`i%kNA)Mx263-Ds;<9xxuC+fZR(Dj*B$#F
z>ruh%%hLOa*LinN@~`YQI76g(OkJ`2;e@RN`z-LSTtVel-S@pt%x`RxF<^yK{eDY&
zIJDWxds3amb(;oR1*w>LgjSEdnbrNk9p^gBhHvYmclOb3*V~4=dQY10JV^@Qw@&-t
zwe3GjcD>T1r?tzcpFjK9<+n;|SN6oVo4n!nKJiXvYpEQRy{7hRseMs?^kY$u_xlz#
zCv-S@ec<|F@1lt3&6OWK_BuQ1`c>sMHwoWV5x$m_uXeoh!DEd2{E6fD&RZULL9e6b
zay_dWi8+Ipr!DxzGx|$X{<a;yZ`mhPTb0uTM%8{>?fde+z3O#qdiJ}=!tc*Bc16|n
zV~o~K_}6h|enHc@^&i@1YLE79mz|#F(M$Kl%8;-itF;@o8e2}IucpJ%QJ8*D&C=h$
zx8jT;SuQ)eKlN_WOYPFGzKgQ%Z!lEMcQlCR_jqGrul@|ndQBQ<)rqv3J7u8r+<+C{
z16me+%I&l$sZE_8^+MnCj+#_|U)7tRJ3#k}|H?LMkry1=K3%;c$)(TQo=Yd?Y>FF_
zJBYd#FQwl%&-u6AzBC?WeMGUtIM0BE-7lm(+^1I9SgBXnd9Qn@c=K#UvbS&iVXe-q
zub){}ZD-8c`8M4GUVWOIxa(S#^ZhrTxbfocD&A9+?9H|qy0P=YD#0N)R%{C0-%4Zp
zH~qyOyzgo(%6@QZWXnm;JfD{05%Ro)&exn(kJFU*2ESK7)^1egZQpf!@7TAu)83XD
zLly4xE}mphXUm-LCl9Mk^Qb!F(1TX4i=TN_4NGZ}8yeqm#?(`KP4@8)g;Y*`TR#qa
zIcc7WX-f2U#p|`p<yd5fH5+`~PdBVh6`w{5JVSmWg|F;2u-zp8EE<hTS1zwGEmyTc
z_(YS4!kp;|gZ29y?ohGE>*L?27SXO*NbObGYYU5cW^@$tOgl%nnP{gm<bs~^EA4l0
z2FEQ*y{1?`?#H+8*TdGgXvKS!{e``<*Qou~HN=CYcBAa}N_>Z)qoAtXyIcIoMp27f
z51+Wj!0?gAwJx!dDhio}yE`@?9^7g_@2pDxW&M_4`(w(JC*KG8biQV%m-FJ`qAq3u
zPp{U}KD4l9qQ)}bca+jE%G4mdde-jByYDADzmR>Kr`n-T{O7o8Doff2Os{+5I`#aG
z<lh+YA%pr}tUGDg!S^bs+c(flHQKc^`RvmA>M6}9ck#{~%zL7JMEJ_KSI0`&8@<|F
zJGb`1ncFuc5Bs4!N69a>@L|#&gRGMtPRYNu-?WI|1SJ3RgU4;xoO!$76#McY%ca$w
z>-oX{c%P4VU%sB!{P3{YmMfWK!c6#gr~S7sBhKbFT&=31lwcPzB--?)an`b+XQnE5
zX4`)Hmcs8vQa{+gO6RjCulKIF{K)LgL6uKMkymeBIk4t#C(F;3R;GWeO50bLv80Z|
zRjp+%+q<t1GSs_qET&DXx1UcNtJ$mhm=u0?pKf8?=M(RD5@#KSIcnuDdAnb}xYn=7
zgSQSrt$vtaYIyW``-gL{yDoX&(TsMe0WSjRD8%ir?mYa7#gBG@vz9o$Z<{r}z<7OD
zopLd$&0UXcY#wUKcdt@>y?jh!yOv*~m+@Vr^RrO1$9BW4w`Ua07&fl??1%d_$1?~w
zmcmzm_qONFr+x_8H%HM)^^%(YmE8xYcic2Qba$odRqATxVDF^l-|`M?lE&2h(!OVr
z`hcj^g<EgV%(-{Vymft9i{)$m?{%c@n;?ZxBh@A9bNLS)Ep3K=URZs@u)@K1P4<Nv
zZoK{Ze$Ol4td;ofLTaD=z5O*FeDIm&P~Tz6yxY;U%cpAktq9-dQK9~Yot~Q)o#OpX
zDSUgTXzA2Em)I@O?Z<;vHMUpSp&Y#Ga`YOX6OAV~_G#8LocErk>)z<@Qkc+l#n9HS
zt^5?X9I343oqu(~yd?LB%bLB~khA*@<9eyx&7Im#^XlEOm~EB6y>-k}sxoEs!CqB+
zoqjs!#IB&1^^9qsjiq*c`FAbPWW%`IrUB1CYdwp0o^U<GamL`>6)KZ=bg&yB?qh#-
zZE!7VyixXA?KPzSaz~Y_pKiQz8{4mY?xqbMp&HX%3S3;DydCwa^Eu0955+sxj*@?6
zuho8A8YeEhcyG^%BD+qbZ9i^zpKf+P?!k&kCC~WP!><HJ+)zHN$Y&dpf0cV5a0z^!
zk$mU#kd@=2Yc6bcdTd7}&#S?^qcuCaOt6XN+iIyFoImYo#-Pg=T3=s(HfvSZ#*>8#
zS%-A4F3k>@=e4!!`$+uzDCO@cr<AxER(XCc4J%s6vQz4It9~m?FX`YZrNcSTk2YUx
z$UDqZJDGdu_>6A{yXW0Z?-u{z)pfU|FAMaOYc&kLuTpTrws7xV?h&Q@D0_|bw$eD_
zV$~W878We>{nFaH$RlXr@EO*vbi+LxSw(d^*(Bg|HtkwRDV@h?mmeGz)yBtoP2%p+
znw?tDeKGpmsd>xN79W@&Fs*QaHRVdG=MCzc+?cyJx5vp33a4``hd%D8+f(Lje(KiS
zKEvFMZF&?ihmI7!ve!6&S5wsA`)^Xl=IM30shiU-sFu^s{k4aT*mtsAcoiRq<K<s|
zuAN!@&7Y3KkIlI&UmV@z^ZLuC`g^OcJ!LqnT=x9V-n+W#g;<5I({^Is4e7eC26w+Q
ze$1kxb2s-+D|me-_`s9onac;JUeJF$(azU)1mj(?z>|)``A>uMKFpHs+o+X#>~NT_
zVw_#S!o2Fnig{f<Yxd5|BQKPs`f(%b`53no>Jv6@NGrT+H|kq{{JRwyVfQk#eP)GO
z+;rJS{z}*Fdr&_lw#AJhFABcReECpoRJU()!#i48KWR58!*@Wx<)mG6>AIb+n6?Qo
zw@+ioS*y1zJ|0lrKXav3eqs2HS$Au<)~fp3eBOPK+TBSfX1zX{GiJeqhdcH*GaRtR
zApcF+R+sNSyH)HLH82}lj`!cCb||ZT<g~&C1x4qsr>|+0oI5i1%gCY{y(b<%(C^#m
z7rt(kc^k>U&@Zo^UOr;)Wn6#BkC7qI$He`3I7qvl%HGiY$zx(3Tqk^DtqL6lALXKM
zDjOZk4Qzk&(1RW${d`}gb$o0z`%T67KKh#~E=r<)Nd9g7?(?;Gck53R$DTiVV9&a*
zo&CIYwR?1U`Fvy4XxZy<(#}eX@9V5r>d!`$&(-?uA2p&);~f@NT{{`(ehY8aSEZTy
z!2s?Xn@HuVm(q@m#Qb`7qN>#F>DNswEU4+c^RvwBHudyBso42h{~bKHQy1YoK0bPG
zKfgia?JhRhy4bGH%F~^OI~%v`=rVg_a<0w$TCbQJL&`VZxQa26Dr43)ZE@vgp|R<}
zn&GNXE?0KY+BB_&!4K;r<k@{`e3c<PmzCRWZJl=wCiJ@Kbp7i<AB_jucOp)=Y##3F
z^r~kH?-xk%4Lqxnv(fI&vQY!8S&eJfcJcN_<J=3v7X^eG_-rgtxE{)Th?0M{YerN#
zz1uCQ_T;<q<AW{NeO<6}{Lb3Xx7`2cnf%>2vkKpFNcH?hLHQ5*k(mb`98wM*@XEA*
zrxz)M-!$0OYL(*yrA8OtrV(FF5nrVX>c$VUPmKw(k;Q(w*>l31+ehlA3_W4oKXJBA
z;hvNc%x5E|^RgQmm$r8rF!EXBZqvqpZBcdlir0$^+Ah8R>W*KcU2VH5jCUn_pHtTO
zd;98!jo10s+qTm>yAjJh@^$+SjBGdTyT_s?cUtgmgk;bBRNW(*S%xPnXY|VN*T;DA
z7UeH@`W>@x=IcINxq9IbZ+@qj?9Ft}{XFW2^1B)ihC?*6Hbq<wST<+3Y`)FRMm;Xi
zA00vYt6?JIVU=0y&@HQ8H!j?^e{tBNU0i>o@0&WV^BQ+=sLJQt$G%Rd|B%|#UP@>B
zMksbr&8R&-IsA6vqU+BM=3EO1igCTOcSVKc=E}UEAdT1VOkZ7d=u79?uRY?F?(drX
z?xk7yg2_wXpYyu*ruU(~p&EQE)LvY7lG>|0YrCax#%>{Q<F(grUKr!3Q$2HRn}J`>
zq-Zu@+<@<@B>$4qH|cGN-(M-n|BbrNhhdI8W?ou1XM>^kz;X){ErV9sFrSZPZ_xa-
z_zu<YZrF4s`OUHG2Vy(7w5wg|w=R#mtY}<+UgCJlij8#Lvd5EJ{Y3b7g}ZNWxg`A3
zaDP|6J@EG#e0a#vdKT}LhSfG{7#MWmK6B7W^>XaRMo~@Qmp?P;|6}i5;Hs$B{=X4S
zEHf}HG}5i1;T;g=A}L-&LnXt+#9#v(LAh*Ud&k@v6%`dGl_eG#<|Ry2@={t@R%B#Y
zcCw<RGDRa(!=yLN|M!_aTQ`Jab<X?#&p9(6zy5~VYu2pw%$hZ8X4bQo!?Q2^vUSAz
z{r7#C@T2G47Doq7-7$UsLE0t5mH3uz>G{rY!<Ibd(V^z_u1$xBmiYhbq>nhcDs|`C
ztAChT^8&s(O1Q;4%jfQVx&7dtLs$0<h|%BBf8CZtDf*dtdrmCvUb~<N&ogb6{64?q
zAIBd}*!z=Z?#b)6?0#X^>{V~Ab}U@*OZD?Dr#*d_<zf76l=!M2x%oP`gC%<`ADL#&
zKR0a3&;>p2Z@(h_)NN1R_U%KPqHFOjQ{sE;`z6!9PhD7W_={hnZhP{9xd%rLeeUJY
zUugT_kX0`}es5>W!73$O=T{3Kh~M2|N#4xNB`fc5`;>W4P{;dj`66vV?b>q*-oE$X
zBd6R~zy5a7&F!`y>Am{lkWjyjI~@1T__9mcx}dL$R)4vtYr@DL^aEF}qt`c#E}wE=
z(9QRUkK6T?!O~*ox37IuHt(m7U){cVx6gAM7vblnJU8B7e(jGYucxm1?AOdCzdrKR
z;whtQx9td+{$szM)0daO5yErrFG_wlUA60`nXauLZfjb&^z{_oL#_`j_}o9g!<^jj
zZaUyU&$N~Hsq#FNAG2fsgIPZv-TOnuB;)RhUSF^LwBy*hUzyfdyz;%ysr~!B|D~+*
z-r}kc!`|JX-&=W0Ws99(eReeJ>$|^>iW>9NYQ3pv&sh`a<IAKRH~LOfowI4cPqRwr
zwO$<ZL%-7RdzZ!-{;~MnoVEQ1`erWUy{KZB_oi=K71z;saPh_!$8Y;$-#cffZVc{I
z`)t=Ga}s_(Fl7kW<vu089;22-wwpg|!-F5UO*|W1R{dMMjFDAG*UoujjiK8+uifz$
z{!mJJ-qLkb*v>V>UdTv#@aLQrKZMWzzT*k^IOkz6-2BGQB~GoVUy{a2K6Xu>{6k#N
z;!_KIeK067<3q2Eou4M;CWWk6n)>U~%8k3YeqXsk!ueFrJhytqtihQBUhenOThpJ8
zU3B~V_l*8(-}}0&!e4u7BjNs`)El}o^Y(jR@a%i&hqpRSKRP|>vvsC~K8xG@^xMlH
z9lL+IBkcq60oObJP;vU1gjSCpD;oIelgG#8c)yqMdfzVD-;}%<Ta;FLPq~hMq)Izy
zYSkCHdn{2swsjv^vFqxd_qeQBv~P9y$@hM+WxeaRy+^w<W}#9J9-Vz{bge_kyZ;!|
zdSAvjH>dryeR`kmtp?q-DXm+ZTl@d|4DCN9KGS;F?z%w{=HPAnR(KzNbW3IZZ3o}H
z$<b}Vz>NuqU+c_!nx%e{zIVqx`fFOtMPKi5GVh!nbv)>sh2M?o)%pE>PfyP1a%!LW
z*mw1iaCKeH-B-3eebD#rnywim3YPZwzVrDv=f`Bcy81_b@z#kO==-UhkLnTcr6&)|
zNI5fN<mR~BD;>UFUVePxq+|NW=ls&K@U4wYh)>B!^Uu@1ik;`p=-S=#bZ)DMvbJ}K
z=yPw*k)gRCyI$q`{L;5pzn$G{>i0Z1D&gGsOmMnx(vtgj49vgsv5Ax2zKohRr`43D
zldm80?v9a@C&u7cr-VCIwIs`9@bCTH7aegdI2~JlIAYJ@!#REfmldbJyJ)$L`|y)e
zuibd`!_Gf%JhXRhrZIY9QOxy8`>GduEZuzj$&?|t*R)Tn=Dwxaxp;!pFZYhUaY5$l
z9wj#peWK#foUSKhOE-Sf_1C;Np9<f=`@h$faxnMol$nJE<@p}2ch5MrcuP>H&8tHF
z-Cwx%nYU7cHuO8i{r5%1e&5f?_^D{qy3LbgJ3YO|WAWC5Gfz)?Wp~c{4S~N`Ezih(
zhq02B^LAp*grYYhT<%)=><u$o-`65@cTL%or-IzOJZT6yd;Fn7!mR8d=WT1bx#c4P
zk38nuYIE+Wug8D4c-^KsC%XUs@S)VFSIxZtg?0EvD(O3L<~iLvpZ8liAo0WZ<Fi+v
zZ1w8m_Pw`E^)5>2?$F^zufw!UlyI-t1qFV5p#QMW=YFfJ+GOdv%EfTZaAtIUc-{Pj
z>YUX)qj>Rb%k}0SS<zkh!1phCoG9%xp#KjwDdXO~HrV~Cg^%R?zSyTWm-j<TxFb<f
z2R%bfU+sOZ?1`)Qmp}FPEp5A;{jJP%RH^^y@S|A|avgP&_(p|=jvRJpRmb?p=6v_b
z={fJO+Nrx^*Zk{VPyeKA*77kKX*>sT?(~k%JM())9X<EO9`}juR&I7LG2L9;Wm3r#
zF2lTkD(mu_yu%cy485awMBB|%*Ufux)d$O3=6N3sZTrBhqqi<=ajVy(YgSr1esv>$
zz)E?k`t`Z!;T?v>b^GegF)8D2>hai*%bl<IY4nfDPp)54bL8s9%sZ<*mkm7Y^qT*=
zk3zz>^*y)!#RvReZShQ6t7jd$ymIXJC8ujWf5W%vIyr9p*=I}IZt8aMwBJKt_WQK&
z(Dz>VJbAdwp|w%H7mZ23E|2!wEX6J-!&36I51Z@53@*XG@0cRCw%b&+ddcygvDJ4E
zjSgImO`cQ24e5N(@&EbQ^u&Xs%bxA2&ntiX=j<LE5A1sSm%Zluj(sfW!cR%x(X4N;
zxcBTWM}of@Q@mo<iYenaIG*{(^tmy8Ru(<sw`puG?>Cfo?4X}Nh`4X~tq<=UbmZo#
zRn=izzA=m}^q!a(9O?7z=5^B_z@J5VJ{q<C&H-mmn$M;L`pigwepK77EsA%xdHFV7
zhqGm^!+mxwpsy{a);WOcGbg@?GS(HQ)p0mw@#53`^{n+qyP$p0o@hVR7xh88ZRmJ)
zWw`^TSX*LHE)``?R8FVG%-=MdEff`92)Ya%jy{i$L|;Qkp*v7+;g-)(%wnO6)^TgF
z{EmjBuB3GWdK1dAEFYnfsEi2~h03^KQ_*wi-RM>1CmMA}W6*ABEb4>CqvCU!fZFV!
z`sFG9dVj|blS!}Gfw&brm{769d{pf4C>nx3hl(9mp<;)(P_e^qRP68#Dt0)IiXEKE
zm)PM3RP4|X6+3*1iXDDN#SS<kDt3_Z(ZmkSyRO)w7aGIgfoLo`5*0g$U!uJoRKGRF
zpRFl7xRV|!58Y5H4}DQ759CoP58RTJ@<3V?J0zh}9%iFr2Ma28Sc!(9Z=qrbnly?X
z4xwU)!>HK7fqaP_+M;5I9;nzM7!^C*j*1=5qGE@3<VWn#36=8D2NgR=zNI{jLSs<o
zU03W7jfx$_Z?AzJtbSdJzt`WfLoE4_@<0`+*dY@YJ3N4j9oC>BXc;PY_z0EqP=ksc
z<ot^rt|EV82d3{+?9d+-JB&ib4pULFLu>LOcIbkN9r~hThry`W;Wkw4Fd2<Or=hWE
z1}b(Czc!m4h{xvhr1(OK9h})lI+SH5;iY~^N8ds-&=k_aHE%hI&O+ZHKF+-*&5?I9
zsQ6ONLr)Q2;#d7^6u+B46aN`C{@rT)%#*CdFMd1r@vFWZijPNA@w=<(e_Ks|s+#^&
zYW#1i@tf56#Ye<Ge${V4@hA8*@z<&GzoW)KTa91*5p3~?kS4W%y3%i5;^&`~CuKQ;
z9j|4r8l~B$JBm(0kD)Q>52)BV0MvftN`GdF$BAvdL6&`l6FYp22BV*#loj26RQ3-6
zwV!sA>4<Z%rXwDebQn=dM*<pyPD9V9!`gqk$#je*oTOtMD(M)HN;>fIzK{-U|6eJy
z%KggT9&1T&JGRqoQs#<(8I9!cB9v=Dw;ny84mF+_wl}s%HsPdPKZMeZ)IE$!ejZWx
z4`E&HyW3<sx{+Q<M|YIhJGz@uNeAOwD(RpOyO0iRpITiEzc)^Y6X7HsEm29w6{w`6
zmAZcj>uNvNCeu+udL<pNqLPj+sH9^nD)!ihp0|g!e`%BHSV}laM;<EacoLO#Jf-d*
z!n)e0v&nRLlU_-O4=U;KMI{~7VM;pu(DUiA_O)y>9oG;}(&2(iI%pFp>1b!SzuLc1
z>95z=o*YBDUVcXVvwtlbfSy+K;mx|*7g6eH<$O4zo*+vlKf9w}Nig(lbw7zi?GM=G
zaj8?3<EEi<ToWq$%tR&Ma$L3VUX#a-B%B;~GAhUAJ??pXsr~29?`MBqze)PU?xiSg
zHQg>X-EXPsmgA~@-IP9XVlVsrK1VpQ_w%S9TA=PHX;=H4HF?}Yq)(2^Jz6>LEo!<4
ztLc{Gs{O;7JZ?wA$#H4xD980cYe-vf3T*_KAs33F0&2mHioy>fAQ`eC9~#f={a5Dn
zj)>u$K{k|QpnS9hDxe0O4Wtchb9N`Po()A%4$aNaE%R~P=Hj-^!7cMxXX$uf#m(TK
zF^}~>WB%$w(o+uF{MFP2BY1ZY9wRB|5Cxf#4?Ca|qycA}zxs0KuCAn^R}cCzlqHZc
z4J}XrrBDTR;C>swLp;bBhJ_$w7uJ9qjWa)pgiI)eGLUf!UB*(^KsY2r4irHd$e4vP
zR-qS!f{amUfn`t(GCpAy)Pu)(jsani47pGO`=JJ$!-)q%As(`!2+H6P)I+udX^bR|
zPynS+1<sR6BZPq&@?i&5gUemCWgrSHPyz=)$IZwOBEbatP!6@=LL)dBBA|+6+RqJM
zFoCo{<N3ie37ZewU_YDy7wQ<>yy2IcGu+RDy_|>_wap3c)Dl}jKJ14>Amgk#T|v0}
zumLLbd*`5spcZ5fZ<)6{3q0>9PBa{~pR2p^Jl*^GUFPI&JRi6I0c;8~R-64C+zeWz
z%zHf-^(4)OXbDskb~m~oY;#*@u4OK2r~<cj%-Ib3ms{!%Kv)s;G(#oSLYwu>?+gJD
z4)Kr)xv&Oyz<#I!=U0daf*}HuAq%ucvw&s+%>tSQ{_iZntBD5l|NRethw&gFez-E<
ziug>4519B>i9dS;+r?M0l;6ZxFP?Srrx70!@z)u{y7(N+TrU&QJK#;$V^Q%1dXM!H
zsQ9_dIQZgYAH}-(i0$TYInFTF#czKre@ovs@o9UT^>9>tRNr7-{6!*J7vH_N_&X65
zpOihUk3+@xb|>q1qT-LZi}eIld}-ciJrosRZ<&`S1{L3`cUd2WiqHCX*6&8e4@~BI
zk-Ui=WPGY1w#isQo9(vSwryaWj4vhmknn>EC*zI0%J#<FHmYGIZplwD;bc6T5;b1?
zZN+Spv5X`R*&aeT8Pj5m8n6AfO=?*CIc=nby+nF0HLuM@=docw+k7=`NrU~|FZT1&
z*w01tE&E(-?wQ7O$z9`S{njmMl%?@}GL7dhv!7E&!Z)5n#(qARj>LTf*p|+$>(#&8
zlg5k94`V<7j{STv_H)44&v6t%ToXZ-$!L_i9*Y{)^%mI9em<i`Y`4u{WIvzGrRFlS
zpI_z?_HSxlBbifX4SBTZVsp5-lU^?fhERxr7)S=1r}92Xw+2d}94es}bhNYGz!L%>
z3}jvx-h1e>AP?3+DO5l;)Iu9791pO~>k`4b%;_>0av&c{pd2dU1k{5Y&*YvE0O1e=
zb0G)vp%`|<eyE0eXhVBf4*?JgF)$ahp#Ws8!QF5GYM>ruY(PEq2ALlw0^-2}Ij{^$
zU^i5P{d_SVwCQ_8C`3RENV{L!{Dn{qJD?0~&j2p8`8~i3MnD84!(5Q(f?Oy9c_ugj
zhu{RX;Tb^Yn(+gfYo-utLEoC^00^U9p99;V46?2w-C&z1W_KIHgVWVKgFzvbfOA{&
z4WUp5F4s^tAPlO&g)*#%c*ui7QR<{JH~=oxeIZ~1c|lYPG9Qbcvg!?UuVWuL0M*cj
zmp~z40(l|i(E%GkHY@{~qb0Z_zd<hazJc^YA(TKBb)8>lYzG!S`GrGJ3q@U6hg!()
zhW()mPQbG6oI}_TSvQk@H~{g!{01^-#-aYC+0R<nM)`Amkhv@71`-#PLM_Og6agR?
zQ2>ZPUg0g2C-54~HfS@9d_g?uhf^*f2X=$g2#y0GV1hNU4N6C1k5S|q{BC7mFvD)B
z1*cH#4IbbHeh>oQ>iY%nF~kQsqMRqWUyMiP-sOhMy;<g}lKb~iRPKBIP`QtKp>nVF
zMde;9b(gdWx}tJ#mT|A;-rEV4d-q^e?xBNFxvx${<-R9#1<L(b##okiLpN0J=SEcS
zbu&;&m(;h?J_tbN9z6z?bjF|(ZUid#;=53Zw<9WT2&wC(y`e3d1vCq27SJr9SwOSE
z<y*jspnrY*|3ss~^vA*fnFhe94E|5te|P-<|DVVD@2QUCx8K2P?>-1kZ{>MvIc?$G
z;MO_^U5J?Dvd8O?c_|pjJvl9I27QTKUG>Dbh4$)r2jg6Gx`9!}GtB9;;><~DsTt7;
zY3b1>gE=lyM%_<NicL49Covy_jK@>UepR%WwXra+2>bBEV?m=gFE4jIJ;8bF+xK`q
zJ&(5SP}<>++E^HiJv<G+%{0w_>)X8KR#D6e!*hq;al(qdGj~7r*#ei_?td`Zc;Fw0
zZ=C;QpXY9i-{s)8<m{bkw7IphFto8ScJJjmlxJkU<A2Xs7+caLzn>rYpVXgkS@&Ar
zHIJ06+U@zk?B4F}%B#ZW-{IZXA+FtEZmQZ?7}{7E+E^IcSQ!7Ru`skTF0?T&v@tHC
z4?o>Gb7SzEo^M?L^6_;Kf7s>F_^Atjf3z#_tp~|{S{vg+8{<OCfi}j4HpYdN18s~8
zZHx;k2ih1H+87s74zw{Yv@tHE9B5-)Xk%PRInc(q_;(!RB7|>U)^Bafcm;p(8K&Er
zMZU|?*U`e~HC+c3bRMV|sz;@NpXPf=zcjv$<--ox5B1<SAKO3}m>?I5pd4zzc>#SP
z=@(Z6^&pdtctIqXARCs!8rT8*p$41->8}P+V1`1@h4eAid=IfF-{CahL(TWlw2*IX
z_t58a5q%^1uH<K-?<rc3{wMh!CgO9bEt&;13uqS5ETCCHvw&s+%>tSQGz(}J&@Aw;
zvp@@?K6g%ypMJfMvHBD*$)x{!r|TJ89F_j(|1Q4d;vcX1lQVuG=h7Ku`QP*>$E8@_
zt19E&;RdVtloz4(z}Se2uekVp=Rqk{fcS9l0P)+dgK~Ml0d06CkO>Soq}u^5SMa_N
z!l44(TV3#(u4dicnPWgQ<U^4tFMcba3f%F74h0ztDI3Hux*ojniw=Mhkb}?jHmHGm
z(BtzQ0a=g--juII$cG|01mXBM=RqNa@Ul4@wm})x;^Q33brcDC?&J;Xz_|nYhdOZX
zNPLXxup4T@37_U7H~`hK4BzHTsDZgX`3-hJT`$tyoAiOHAIFCh$nhaA*bmP5F$Y5!
zxZx)&V|&PW8`~J9(PbdNK^W+R$QR57Kl)DPLIE5AcTVI8h=45E0p+m&7VI&YJVWRZ
z_JwRX0L~%o2cF;!!4L`&FaqBTzhNk3K>>(=vD7)*qFF$*fMx;B0-6Oh3uqS5ETCCH
zv%tU30z76h7leb-@{SLRO3R2!i=7^2NQoclhu?ZsN>b_!V|uDFIVvvQoDnsP|D!U}
z<Dv{EldR&VZb&x%aRh*AMl){ec%_@?nT&@2hOqz=)Ug0$j5AqyjFX{vm1p59Z=R7}
zxKhVY(b1SKIwLO4WQ>o_FdO1#M4Qa%!E@pg4e8P5!9hXI1W?8ikof<&=tDNLu^nRu
z@Yt*S2ge-mU`|ZRV7@-K$*X`*lx-%Rj1Q2irnjhtH75J??jxM(Qt6F08>Tgz<_3W-
zJKYscq+7-|9PeOF_jEPgG6tM1H-Pl*x(*JpZ^5O~ZI|YInlm)<b<(wS@k0N&T(C8V
zY+!4#?HJp*5NaBEjiBT8g^uCXbk*!oahYl4D!OdD9k#QZq#;O6L%dwzEIg7ccH;3~
zcbu>%)HIAWB+ErSJT1jE%WS+OX}-~#Z(dO}vFJm1rJ$5CJ$e(2cZgPY>PQ*mPusS!
zhV&W6cx!Y@dGl4%Q>~^)>?Y@p*A=>-_#<Sc_4<$<hbl?B<C1x|r9;ZPBkzJpN4Pm%
z%7L}4&tf~<lytCJNyA_@4f%wZ<!;J;NAyngBx$gyX^1w+MS82ze1}qpMNo(F#=>fs
zHL~)@MX`$<yO`hVD3s$JtaYOVmF?S58Rv7nLsDu&TC~)Q%Jx#WJGYbV)(Vq9bzKQx
zh7M7}TenANaB3L+BRY1TnIS%ueJcnPOuENASgQ|PoCnVD8<!SuWQ34uM&+DUo!@Ru
zPftrH@2;+M*|w?ch4e<xGQ}Ir*0cri+mA~8v9l5qjABM*pD@&#Hbb0wmLWNsp-GIX
zQdV7E39kN@Zk#zQDV=Ig{Z;Je>Kc0fcXi(jNu-_%bS+_ka;ZXpCL$@vwsI4~`#o9m
zK+4VIAn%JTtE}Zl23avk<;r%sZsj<CT&(3+&PO;uTFXs}F(oa1o`k(l=jd8M*$C!X
z_we@;Yut*hC12Jul_Eu3v4x~hsO2|j&bc<$iZ<3tSr46V0kwtRae3;_MO!!bJ92DB
z@R794?my-wXk)F2UApbdfBu;#mJB#@a&yj{>z935>+s4wy6{Jz51Qon#nS^`+QK-+
zyjRvc<_uWT=iEbMBhm)%{a71o<-c*PmFuZf^^Ti=KenUlaEG1G#MQUSTas|?<ibtY
zj*h$ee-^xSPp2b4dfumvwenK2Hr9$Z)`~XP%D-x?6^Hgx4?Q@)@VU-i?;ZPT+_<?@
zy(hSQ@?O!E?ab8^dmsAc!L=QCf55!%qa@sxSK7r-Iv9Gcf6nX&4JUn%q}L62>PQEN
z;{837x4SK$NaK0dtr9Nt-hh(9Egtl&I_oy*+x(EPr`#F-VpUznoe4eXe7W9z8qWj+
z_)e>L?6h{}cRkZiEn7d&$<XFK7q2~QH>L+ZJ1KwdmF=#+p<@l<URUCK#Q%x1*!E`z
z4*%VC?3(?HUf4IQ=ChAS^zEeU^~ln!&jNV>OjOe6w%@qsmlmf2!y+dBvZ&qDch*ms
z(tUlt_cNdT^7-&RzlGEG9nSY$y<?Uo%k7I(_s)*)6#d|WPm1QW*zbPdqtCB2x9s%J
zOLLdsztcK5gWhpnYDazhw{{OXk#g<}ZA=zzOcrfSmSyAepY$*=&j{C?-tp*!p?jvq
z-v9es`(B<|ckIo)4F|O`S;Q{dm@L|uEK&}%F<G=RS)?3jW3p&tvPe15#$?gPWRY^9
zjme^o$s*-I8<XYVaZDEZUZ(bWQ2Ih_<3p=_4)+9E-eA6W=^wEZrE9$IP4pBh`>A~o
zn%r-rx?i!n-zK~L)NlVvpMb{4dxvoH-SAyh`U<?K?x$y6{T|QvNBYH+PWk@m2C}@b
zhLdlh>Nj)cTe>sf9_3RuUGJ48kx!8le-bM3Pe<ij`wUd_CEp{}Z`?{AWq<h$O*eXF
zxm(>o8s#S)kB=4)G#2fN#-sABoX_)0e7UTv->a4H*x__AxQ1<6APcXKEb?ueZvGZY
zV+cyzx{>HsbS(M?Iu89Dy&a7p;}g(0^bS<!@1BTab6q5Q42?lgq6YL@zMIFP^8H-W
zC;7w<wr{e^w_35MoaZQz#aBHK{ZYxMKiU~(4nZZKfhcL$4MK;b!6<3g-GYushoJK9
zcNkhjp8u1_?D0B|zXX&}2m%hU4mnUU$9kSU_-gG3VUP%!kPkaR8@q=xAA(&V4@#j1
z+=sFqk|7t0p$c4vu^nW7zC0*}YH*_v217FBLn%~3J$Q`ZH;95v$cG(J3H9JX!3~Be
z$b@{@0hOTRU92aBLK##+J%sZvSLXQ31=~D-Zd4wXqxl{5V@M~&fCUPm6sn*O+;8J|
zh=*(_gi@#hH{Lz_K_p~CA(TN4xKJT@LpUTu4irHdRDlx}g%^ZEB3NJ<6hj$QK|OeI
zk@`UxBttHgz<#I!=WybIP>6?YD1tIL1oa^GP9zmhCKNy^RDttk(g<N-hJ4ro)!=d$
z*9b&`1xnxm=%$b!hy)YlLpjuf3zbqZL_ihCbZLQ45}2WYim)EmuwDZ)_h<}c5;h;U
z!G1UaE>nqT0r>&(Vaq`)G6}zsV}kga*^l9q=tP<<*blwfSUwfU$q(Nh@>_BoI0V&S
zkxsTdUBUIwZ}s<)9@Yc0I3`+pfN*FngtBe_87G}{D~<&+uV~og*yAVmW!>|Bj*W(+
zGPh_9T8`F(%q!X(f?+?~qtHB%IYvw25I8-+anMk1dV1EqVeZ$2<L@=F4NmlJsZ{<h
z<X?R5JjpNJdvqmGP59mDesF(~{ULN+OI;a6yxdY(2yJlu^M))a1#QtRpjkk(fM$Vz
zo&~tIHSqtR#(nS&7v^q<7d&*jy=VpOgHOS>tmL=hFcNG_A?vH)1P%I=(x_LL)oe?m
zvA+gg2lHS)WWqggFJ!@k@G!_ygsz7TPz;+umLsI$C_K*JPr#G#5P#>u)2u%OvefYR
zkMI-7@)qjUj&N|o+uGmPaHF-auJp^5KDg4SRr=G4zTA~GfD>WXqdN9~1>FF<I7S$(
zA>29`&H8d!0kVukLkWK;OooYsxf3RVZISIVr}0_12~NRjkVWQR?g28#vdqWq3$mO;
zTM&m6T%pD_iftoVAFcj9hQC{b%<mjQI_`u>@CIM#3B5p;{^$Vkhd_1PWOOEEsDDpE
zqhKoB4F-sZb;SP#d<(Xvi1lE88w|2cLz7^J`uA1XvY2!hW5bOg{f=e%)Z5yJ{xkFd
zd<m8C5r{v4^#7mRi89Fg$M6Z*makbq2;yV$4SWmVf%pPQpZIDx1`@{)Xbt=bve?Sa
zDgOQ$R`KAz8eW2DNvHIak7mCoSeHKPF|0?y6u29vLOU0V25qso$)gKtbcF@%FM18z
zZDVP~682v`hQ>a|8`uxBe2#vpu78VuudX|gPDk~8NVqnvUt{<8pB+ELjeXnO?cbgk
zC)e3to)Et)_PG{h>B#mQ?0)Oax?cUeJ?Xn%O{0YE&-wuMZ<!n1U5&$^ZGr0ck!Yy8
zJ`N36*CWu0>iT3fN?ngdjp}*};&W2tl;bU8dzSj!KXdF1xz6Ppm1{%l3DI$s3#o^4
zSeJT9u2s3N)?f>J*7El{co~XdJ;)LY*+6q&cL+{EIQ4b`ltU$Ww&0q9Qm6$do=e;y
z80u(B>#v{=gD6M@Ggx3Z><8O(gcHvLZr}+OwD;X;*L#9DFukcR49aQ4x4DYv29U8d
zOkjarD1ai^1`%y|o`E9R28W>c)x-m#5CJie1$nRyc0&bJLN(Nayr>I+5fBc^V1`^M
zf-3O3hUXp_0pU;p)ldg=-lcxdhCC>QaIW!O*a78m0OXz!0?CjIJD?mYp$6(9k#kZ2
z#ZU?r5ZQsaVHp%cCFnb1GYEz-h=feYhDxY`&>OHFltU%dKt0Hd&<Kc!a&V_^u|O{5
zgNzkY1~OjAA@Jtj8xNUK4AoEvPI~r%N~nQ4*nJZU&YqlG&_gg(%HQ2M*N_R>kOu`&
z1ZCjW9UDUkgh3*#0q2|f8=@c)%#aI(Pz>cz4YeQ+R=ptrBA`tV(hg>@Kn@f_2}s}i
zDyRirPxb|G2!U`&26>5?2ZgW=%Af}7z_}N;gHVWsY{-K`*a7<9*dOwt2+I1fPhau~
zBS4&$ydesbA;g>TU;$}U=zaJdvY-TH43-hT<N@-*yFcX{Oi%)cpjOn6bPd3s5CgeT
z3Kbw@w2S}~SRe=X2a=W`(gh<x#%;-ma;Sv4!Ppr}p$_72;k>{$h!{**D2GaL9!7p3
z8P*KPzR+d_*D~yfHX~Vw;!w&LIFBZ+Pzp65@1%;xkbltKM*1f58&p7>N!S?@A?q%V
z4`omgMO;t~9#c7Y5CdM(D43u;hO%eiH;4g0BjpfsAT)t<1|?7fy{B;;NQ7lj0aZ|)
zh<%dCGek{iU&x0V@R-4V5C9_}9HJl*%wT~WSO$eq3_G9<_Cpm^B$L+^6kJk?58igM
zwi|*_@hN)`m3GVfsI*0-4K034dr)bkl%djgc^8#7hPG%H&@7-?;D5^kP8{g&zwG}X
zmzFx)$T$FVQ_M1MfQ%TR3>^>^onSJj;kl}~{s-xTT^(YmCw152KYGaId|t;U#igfZ
zq$Qa3UK4ug$D7PaDM|AgHb5`_$Vth#S+>)8x<*IOj*B*!amJ0sM>zw3Oi$NDW3tJZ
zZogH&r+T^?%*h->_E8+|&G@oLrx;RkflUz?RV7S@Ii7Elp01OUQsdL+WYC=SbRCs8
zD;3Arq%`VqiD&4r(anSjbCve^K;1Re=G+r#bIZc*Q}IvbcB;FF`+Dh^HadQaOElu@
zZ%#KPC6hgV6CYKisYUT67T;WFewF8h@ebs`oRpDah)yC4iXW})e3Ui?KK^Q?(eX*s
zlFS)w7oXJg>1x3SmODv=J9;}RA6WIbDe1~cOq-P)ADu3_$MyG8zO%aX=?W(vtIzWJ
zbj2DnjM&}PmCrPde^b&d;}XR1o7HbPBWW6T7Jp!F(HG5!#7B~J`;>etX~cNZDL6GN
z$MQTMpEdo;4{VeC4^w@;+q7f@%K%iG(tXhT$bUtclK*I{uXlop!5GpLlFiZPG+DcF
zj@Br9|KYy|{@yFDmGjWhM|vB($g{L<dvqKo=H!X*aVfvac^vO>{*)>H*=1}yrsUN`
zQmpo=VB5vcv)D(T0h_Xq*t?3~l0D=&CQ7{3cU$ajx<a;{KX=Ock+^dC&6=0<zbWTc
z(j0JpKWjdvB#OWE0m@f0mB?Ox|G{cgC66Qc+nUGdk#kMy(X$Q7%6YNvQ=sm%eXMdG
zlzqaQ*=Ild{10LB$6eS*%G;%m<IMTqPnf61U)U$+BKz2Uxz|uoG+%Dbms|7Y9)E1z
z>!E?JDOca~@XR~HZeO_KvCn&sa$2;C{zF{gnlJbIPiEcPeqgJS&#n0Sj7R*B=Xll}
zBzDO(w>uc#Z_Ba3Hcx%_eqGCzD_vujKe_E}iMeISnTJ0AZ}jE9mK(X=@d5qZO=lk7
zI?M9v%1Of}ElJhQOMB#&TR-=CHDy7EcJKO5xO`u3-*ysTb^O%t-+J4B+LBu)O`Chu
z_N_J3ydU_j^R^)KuN$k^?($p8J$Q(O3w*4$?&kTOzKlHNarff>)s;ugBfGx#*s>M5
z<CZ?tv0K<o-Y@V@MemsYnM+t!)+ncpJB}Dv4gJQ_YoyD2t4H5|<nyP!ooZwH74e>y
zcQW{7W`y0?z1xuvg%R^p$H&jle$+Cy_wT2V2i;%h(_z?+`6qd%_m^--Z(MkMY}Y+m
zkNLP1z7y^H&5}pUjJGZw{?PQAXSdvO{B{@KDU6hGzs+6vNy?dSw}-##<exA%d(qH$
zD!yFrQs1rB$iWMa4Qp-T)rt~s{j|*;2QAtA=Hu6BKHq24G@ozH=lfsf^F4=lv)(c4
zOqKs=-|Lq@_w>-OH$CV0;QmiHk9T>kSC1k6b|xNKwL9Yf&gXlxpQP`aHy^yCcgsNu
zNg*%Y5pyc^@hLMl9d?N8>sxSgO~Kp)XFt?@!@v8b<F`feiF>PJGA0~<wDpWt{!_+=
zaBi2~D)uv$S0w%JH=x7nnk$x-Z@4SXG5h2O_p6><zIbMCuVul-&+yE|J9E9`&Q-1U
zjqe-M;ugQK?ZZF#{NYn6)rE@&T@ziDG*;hjW=HD#Yl9@*s;k?c{^)2*+?b)qpMBb#
z?>5s|XG}i$<J8lG-U@s8OL^jtQQ~{t{B6WTF?la$k4u_$)^qddfKj)H7;6`HPdIqT
zhsQ>4JH|Kep%UN2?|!!Kwcn=%-5vS!i>CCD&$oQ>Xkn|lJC;n^lT+}K^Ddr;?or~q
zYSac}&atZUPk*`Nv4o=bi~76~7uag<2YG9Y+yjk?5hZ+!50>~A&fHpc`}^<o-TTz8
zBaa_>=Jk5VBb)ReJXD>%AoGQ`Cku)1XTAyO9j6*9wq%SuabIumD?)YE6*mlN_wfqP
zvW+`iZLaxlYtN<L^ba5}ddK6RZqN8_<IofPDu?Vib#!k^*_nI1%CGB^|9R`W*COj*
z{s-^HmHV$#%K;mojp;s4^9|R0!|U&<`~9uGl~3GMe*CVIGk5)d?Wm;98^-*0_xFoa
zDDx2^Qm!=LaLqSd%7Nw^uK9*bInaE=HQ#V42md|3;eOXke&47*x2E#lnW;DZ96fCM
z%<R!~%eoxC;{8=^ydRwY<mZ_VS216g((asE^+oO;OH_|--3M0ey1M5*E-N%2a<O0Y
zKIH9hmvFzPy)dMH_UbhyDHFRmuD^2Iunj+c;&{upWf_A{P0jPJ<6X`jd;rlqy6>6b
zbls#S_w5*%f8}EnC%b(aHET|*DN83`KjhsVBPUPf!$PJK?o`#1ERVsz_j6x##IfLX
zZ294cJ&O<L_zhfEocivf<psQJ`bl|Dc;nFzJO8}#(B8F~#^{AbG1n*Ut6u1_bo1>e
zQ-<7L(>|%1_e0A0EuP@?%e`Z7T#&iCN6C#tpQt!Ar|Zes(v6>V{Wb5+r@}YH@tk*?
zq;KxoDKiTT%JV&3@1AjL@s^-Yn^%SUyT5SjGjF8?ZRmIEYMt)IffDZf85utnZCbZ^
za%`uk*LW=6dT^%ZYc6)te9iwIea+>Yruv;-`Tj1x&{wi83S@ETlXq*h1IlBod<V9;
zp`Fk!s2=T$vMycuWDIi)kITAlXb9?s%J=*p=qYp?sNc_(@9J_qiI3OA%EBjH3&+&a
zwNLSF=9RG}l)tGOEL1nrb<ZMc;}{mYrs;U(wwO>Je=G}8`Vd&MP+n13o<~QcFQL31
zw`@Wq(Cug>`VBe-{Q;edx;yZW0qu&$qT^8`D&PI-DyO9X1Yy<h-^zD!Nk2AG`Vu3$
znS_(S)6t_SeF`jF+24#x|Ki!`yL|VZgFfqsKL@%RosYhbE<nps@?iM}%|?GfA4a`-
z$M6Umg65#Z(8tg*D6i`+kDyPY;v4xix(a;;eGPpU-GSz#AEMaC@)i0bdKxW6ae36O
zMSGDa&WA<5_pe9G(Ens#am`1Z>xp+^iI5G&5X^;@2zelbHbj913ZV>KLg>Q_iI4}S
zPy?EeICV=HZ5hyf#3@Hq*8iJ6;=%WGub>{wf2F1Fa(u;Ye&SAx>FYv0cR9Y|HvbOs
z6aQEHh+oV<TyD~r>l<E#Ey|$=v_-RkW&zCtnguiqXcqW;7T__if&YIV&v$!#>CX!v
zfo=JK^=gp5$g)(R((hQ7=^ps8!|z~Q&dK_XjHL!Gz!CoLxB~w_j3Xd(d&!spE#V4~
zaRFMP($Cr%6@T8==#{XGZQ3{ie{GzAHrVfK=m$Q~9|k}G1i>J<1%`l(!!T6V(c$O_
z7zLp)2Et$*j0aiTqSt^6bbyX<19-rV&<Q$&9=gCw#M>1;h~9*HLO19RH$xBT1${sk
zSF{~0;`}d$`ym@1fyZD8<iS(044wrU7a<>g4hldP`~9vZJ~wC&*TMDR4zftuyVuX^
z*HGEX+J|3!55$+isXgTpWb6y^*$^9L681ZOTZD=)$d~LRekKc97oU|c`1{{stb%LY
zurt_}GuPrD0JfzacDYuyW#e%Q-tLCaCD;~i+yeZLvE4JO{bbw%sq>o}yWp>kS<o9p
z$3rfZLnTy$3-_BCFoE2A4nQ?{b7QhV70B3Yeh>m-5DD>MfiiIBSveBo!2}hc=P@x1
zqM#6D%!3g8USynuEXac$PzEyIK^4dt2YxUDA|M{jkOeZ{ff=$O7xJM9dh-n~88RUo
zDxeBZfUXVyz#U4UUjF7Aj5~~g9LR??Py#Z}!6B#t=eAt$;0?hL2{OjP8aM&<(B>NA
zf<!2WQYZ%(&RsY}K{B{=%|}8O<Us*cfYb+m5D8h32Zc}qyTO}lOU5^t3)!#?^t?n5
zhZsl(8Q-89>cFWZX$C!vfN&^;5^&+Z831`u2qmx^%D6tI-t7%}Pz9mXKamg*W{`0X
z3P8p=sDs{}i67>IjBij1<q)YSZYY6L$hirH3aA7b=OEIPc)<jjunbC|4E946)Pr+3
z$^&>qFhqhG4uP&aX@*J&zL|0cks#w7R6z~YffFAN^bic;5Cw^l1-VcJ+h8|TK|RR0
z2f0uLb9-_;s0CdwjtQAy8@Hf<^&%*PLr@29y*VZXLny?9b03Zib0G_IAs@CuIaGsF
zU()D<Jzx#U_yq@`8eDuiHh6&_gh3P}f*C9zV;n4l64(t@Py_YQra${a4pf4(A7v8!
z2CzRAKrtlqZ89Iq-~bfy-L(>GAc~JCIgk%0Kp)7tfnulw=OBIq+ZYJ?LF5NwM1#pU
z<Uu*qL+@L#5oChAE3SkZ@EgiLkOzfO2KCT;7~$c-aO^RH<3l9u2IrCF2S$JimcbhN
zdlYGg9Z(K+qp{r>@&e0lqg+Bgv<V{~sE0OVu}3(^g*tG)o%BH^)Ik0OYzrqKb1J_<
zDb(N1`Hm({V2<VZunltKi3<)u8zXffgoFDu6k=dUBIPED-yj@3Q#cop2?43t0t%rL
zJkmH0L_#){LIoT!VY`{+8N$-p7jmEy+GMaFc!3{;Ko~?qJeVL8vLO!&pa{0XZYVKx
z{8=c}g3D~K2UlxbrQXHbhLLf;#II9ZGz(}JxO@vZ5%gc+|8Gv4lbklk_@D3pZ=0Xm
zxrNo{&p0T<Qz>oPBJOFro3GZf3BPiyL86nT-$6T<xlNxU#jm_A{?-<Lm$4U_+gtIC
z&gO6Hyy7M%7MD51t-j>k3Z>ry;pQa88)Y7FtDko$+pP0?M-$#QtG9KZ5Po}*_L4G3
zxiu=C_&)bledd$ZywGe@#xiJ+u9v*@Q1W8SijohSEKM!v^Wn{}*7U_G$Ef9RZLaL2
z1L~_a|7y*@TJx{o^GT8J%Q&6x)&8`p9e*>=%WdtElREA|$wwt^_l?v1tCtKGyEuP!
z?*1Cf$zJUf{a@cZ{;536?*-rWbpGP&%w5y>e&GDXKKhE8B;07d&%C%j*CYk>o4ecT
z@IA#fk1TDqb@LV9jqx~qVC6f{P!Ye!vya}<chdTYPX|Y~eq-#^>wmoF>?5N`-Z<pu
zU1!aU&VE<5dQJQLG{5ObpUr=zk6Ze0UJv+N{^53i^%w8m)q6V6P%<{3-f`J?{`y~Q
z9{>7)^UHZBUAOh0dezFaT}Q22|8mgFy{jfVe$KsD38#N<-r3hTx1MQkJ9*O=eUcye
zHnZ)DieAU_cXY`}+v(YTJ@2QLa=*Cm*DDTBUl0&nQMA`-@AVEfp@&xVn6Ul6t}A@5
zzV{}_Yk2p}^Q7Lf{=T&fzj|TqclXV|^0jL_cbnxhzvjo@UwzxIXnWnSt5yXr(CJc?
z_(E@rt#oeTIP-X$&d(<W6x7$Gmrn4yb+i8!!;Wp&{H6~c)cmIZResYBG#0hFvbDLg
zHGgQ$ANu-3ymRLLtKRY4^5c(vzjfWc$Id+4>E*UdcY4ous9re8vU-T8<`1p;LkAk?
zJX3x=;^cKl>0iRTe7$4WEmss5wvK)B=3aXa*AECD-~M^cA6o39`9o{|&{7UGe`w7g
zTFSwHk3Y2L=RA72U;V^&pQbGP{<(}%HwV`g)pfj!Iep|?_+|JxYyQiv?`x5{yQb{P
zQ$g-so-~A<J^oN3--}mv5c_Q{H@AEw;E~5%TW!uA_4WAg7O&eh=S274A3l`&^s1Tn
zzp##eWqhaCJ03XmobH{^`>h<1_~HBU*{e^sdUbL8-dm=67bSFe=y0RgVdmXY!o6M>
z6!`Ih{=+(-`>n2Olcnn_7sD~bnbGy(b@LOdb5_&Oz>9DFddFSvkrmx_4}AZU$BEKD
z1N#3^lQQnzYlGdNTKGuL?~8qEb9q0cggX)yb<i`!^wr+i%AUA-fB92y-_o|r+26`M
zN0s`I4nLapAm8ih7o+(vZ*BMQ=)YVbU(l@I33c-QQ2cS}-k{8%EI;Y#;?Nf5^{wSb
zlx|GQT*=*0Ugzp=M#rH&&?vMIIs@&8K8O0C1t?u=EE`a&49mADk7kzN&>?6CjynRK
zic;h(3()bX^vMfHPZ3VO<*DBQ8GqZFPDj*JwzDJ<t~E+`5(}?^l)13~)BSE6&(WNC
zrGqw4GxeM1gG)ar`gz5G1qz@Psz95knLco|UH%j1X}0;^UXI`Gi6f56Jk9@ZzPHZX
zTk1SPTQm!37SJr9SwORZW&zCtnguiqXcqYQwt#f?K6g&dgA4D3c;EAP{q#@JxBMj7
zmj568_QhxQW%}evpZrMDCVlIrKmE&H*#_d%zaABT{#Vcqp!x4J|2X#e0=@;?B6FAr
zdoXSx$TAI0f*I=HS7A%>XD`Nv8$tXKWD%c(4ZOS*UxLZ3uewgBTMa3_bh=b1=N<M-
z{4Mh&xbOn;ZQ>Jubr-g~!UBFvBiu`zH~IS-!u&h<sf#cEpYc^+j%^zIt84!0^u4{d
zp?~^6%QszoWwPM_&}B(?0>Y^W3qZ!ZtOU;%^ksrls0Alpe7iv~h;O<63f`MT6eNQ9
znOk5th<~~5osUy1_5)9-aAuts=AIz_<-rgJ<yYb}c@;jB-~}eIKrR$O5p08qHu!@=
z5p07)(EDoQfl!EqM6iJPnlA(KF|UMbaN?sv8}Nb=Fc(Up94et20_b~efn3OkD$sL%
z_Le#Ts=<r$9RcxR0`V_D05ax;7eqijm>~<q&s+vf4S-OH1o1OJ;ZEFqkMo9LFvB(|
zgZ*#_PJqqF+{{OaET{tUDT)U(WP$jZ%h(z<P!I7^CxJWlh8Ot32#5g_WI`F#gB#ah
zD9GTgxsVTDdg6vG$b~5Cv0NyCBG?A|!OX{yBG>^opYlVji%+>rH{yW+2!&*@KrWO(
zDU?Gc)PVSy_l9tYfn2DC5q$75fd%rt2oKIZ$Q$ejr=HjlLcpyT;UNNcLoGP<#^#U>
z%fP)4@q-D(58O82eKzacpiHzMX@Yw2^TwW#2ZbQ>n7jLM9EgAzSmQ@pz?r&U=C%(8
z6WDyc!|>_Of;=b$@$(Ml!<5a(J0Ot!f%tcqLQOFFxdmH5&S3HaCqO=4ZG#h_3n9MY
z*dA)29tuZL=AjC5N0KHu1g3C)gAzD#JL#LiwFik4u_+Wm)+FMBa*)Ax{a^&N;obEJ
zh=AfL<S~lhU<A0wkbf{iZv!@lWl#Ywu^b1&AQNQF*4<DZN4bcnT!8pzo4^7UARpCS
zzyrL%4?-XeA|W13kO|q42L(_B`O~mfA_|pI2LUep#(8)KRebt5gtllF&@7-?K(oMq
zp9P%Aa)QpmRdOC56qS|{l@>ca%8(L2&@Um~7?qNgI>VTrYD|ubOE+gk&Eo&4jP$rD
zgUKYTNvURjH6%yPO)<-kvWv2Bl*yPLZB9%#8sekl4Q4}Meq`MHU{{A2?rXYh=|6JF
z<a}PoCdH+vWuzsT^<EQt=*OGPNhwM5nS@<GJT1kPlx$3AesoXQ=;+yT(FQZqv&YUd
z8#C~W_jFA(Cd;AhwlXds+YRPqjv@PyPNsA>n2piQYHpZjOfkwl>=Gt}S<$aVCncrE
zr_IUGwPk%2)3lS|q_k9Pn4!Z)Hxnkzbv<p@yHwwK8M{iBuFw`}a_SzX&1H#ct>Y(a
za%^Uc#$Lu~Q(AIT+`OQmG%{i^r=@%K2v(=1XWDjY;>dUbUg#eeeaJ>O%3SZ>=oO@6
zyn{J0DMOBJowL14FWXEy@$dgwca3tMLmjO#(Ug+85u`tm?rG9kY@fyqV`B8QS%&m@
zV|;X+AvrmCc3M*W;0CD-PBx^(#v7u&4MtyoLw`fyK;QTP?*w1JSYtwbT&&SJAkZf;
zpnv?}-nNhd@!o755O4I0_3`c>5a;LZ?Q8TlFmOS9f=@vIz`^?N=flRw4e<8!4+t;@
zB=`)ZG#UeA1N@A>-mwX>1AKfFd<W|<ZJQW%41$)fUt9C#88$B9ysi4trnlKj>?byO
z92<;x$S|5`nUpaXLfE!M*=C5dmI&+k388GyQ?|z?8x5(1W{gYh`?YG{-EvW}@L0lD
z#-NiwSYjO8N*Rbz%jCa-fo~29it*vUgrrnYZ>1dSm7FyG&t<VMo7(DHx@K7Oh^+@I
ze<z*)dq4x*k5kL3z3s;}Vf%3oP1}B)Lqpr!%C@H%oW;IuzreZD8SJjVKT)=Q<NbUB
z{rn6*@qPmh3H^Nr`1kkmiw!V%`*;U<$M^4VSGE)Uq-6UKh>Q1+_m``{&pU8ng14Vv
zd_ZiVaiD$KHW&tYbD{Y98HtoSvcGRYe1e}}pcHdofB!#Gw)<N1)oj^b-bC46agnn9
z{3XhEK`X_)e<<6Qzgo8c&kX$M%l6XqW!YM`A3Fc{rOUS1zH!+W+c#CV#r78~+q%|P
z+uN7zErbvMi)Gv2&){uL@D1=WQbv6S7=3*D4@~e6^i3GhKhT&EYge|7l>31GKE?#2
z(a&h`HYCJ)8+;9M#sTs10}|rB<L%3~w_iN<xxs%xtbd$O|AhE~{{B7#jg;>=V?uzx
z(Rlgw_C1$bwpU?;#`X3(W!oR?jt$E8hINOn-p=H`n=Fm%?Sj8rw*Suz{O8N|=JRFQ
zTDI4o|NGKqTWsIBY>VxiD%)cFi<RxltE{%SFWVmzzThvGZG(Zb)_<VCkHO!Evg#8%
zAU@7NAkI5BKEdCYl76Ay4)h)96BzH?e?Wl2Hz2{!$I!ojtf9Y8-~gWi23i{p+9U%5
z1AQsm)Y-IO490lhSbx8`Sf2y~F&YL8@VWf5z4tQ9_8ZusaoK)b+4je>E#p8kUR0B9
z5_uOaOXIR#`d7>L|CxdReA)iwd|9@Z?f1|Bed)3-wr^av#r92=ZLxjhvYnu|2TSBZ
zfMqK12}@oj>b@fU30v7V$TJGVbj^r1q^hm$%Wp9cR@!9}=N}gr<@w+`+P5+MC}SZj
zV}8wuPU2Og(#GYLpzd?hGTyG8HBRU3+KTtW>QhLAgarjfM<@FR1=-TqY}=psB|fjq
zjIY^NKk-Rh+h$uC>sA(f+XiqfQ>@zFyOeF4ZL$4*+x8<Zjct49W!j?IRwDTp+s?Yo
z_?m5M5ud$nla;5%hPGYEu})luZJV!E|GsVKH(}et%d|za)t749PcAdQX73D*Y+Kfj
z4J`KM_H&M9ifg{yHs2ci`?meG3ETd9nYL)Q*+agi+_vR=(`D5$&9x|rPs;6lwZ6?$
zAGkZQU7B<^LMx7S!fM;|RabM-+SPK+1y$-`4%5V<SKdR&bFQ=eN;+)s9i(2C>T9_2
zE+SZ|XL-lcATKez(~-qKFK4K)_3=tMIiHv2UcuPqrMaM&otGNrzF~debUAtH-Tsex
ziK9$~H_S`3)zpQ&G#m7?^Ae?$_sh>qT@!iPNgS4jd1<y<xR94-gI;!CHvGxF?3P9e
zi+ve8MjXWr^U~~PeIYN+2EFXOeDf#sl5@Q^FLKSxwNH~r=fX8t)i5v3zKFb#mu7=r
zc3!TryY{6%kZb>wE>a%^D{p%3>#zuSeq^!FM?3a+F*dmFd0@HpODDU0G#B);^Wpj@
z@)6L%nh$S;t|Q`;s`Fs~kcRnawz+U2AI%26?0mR2laG#^BRLJ%DdD7kHY6LB&lwHt
zXqopw7W?aGjMN1U^Vn>2?m`}$4SLym9R4S-pNb~(vQ+AV#(8Px@!CEw%>=#dyhwkQ
zKXdQQrw>r$^U{$xsv72{*+-5Gd1*H2W#{GEKbe<!smNID>w|8TOP7QO^+B^u!wY$7
zHt1#N<)&t?BdOO`s^7=LB?FD}v4D0&h&3P9Pb0HZlV;8`Mkg8#rf8En-R^T(?~8vx
z<J;8V*_$-UcQz$)fB5ghcQ$FmrQ5Z8<U5<}Bz;wF-`Q+=?JX4oi_{_V>Q<Vi_p-0)
zpOM#l{$6G;_nV@9UgbQdtLO1R6M4IzyygBg@@D%Is*g=eOSYaDFKqY6<-&Q9`%9MH
zd6Bf<tv(N!XkW`BRhyg#X}bN+^;g{R+G+O1wf)CWqEO1q#nR=&?{bfqbk*Bk>-On#
z*7GBaeY%d3hl)n&YOcZlSJQRmBK9iKE6Hk*uDi&?iH7NFw(<Q}(>3`b_6ne_B#XVh
z))UrcT7x>U*@pCAP1o9sq^qKdbR8tDcf)iw+bI64>H7L2=}MGN2rP0NYzbnw0o2vu
z4b#<Z1GlMk5mggQ!)M+8cJ~GQaxVjz$f5_i9wmLZ5Z2NtUClLEn@ZQ^T#th;lCEWH
zy7*a1m&7%kKZ+ZstJwzVUrpDri=@ljlZ3F?m;0fd^Aioz)oi2jucm9rMaq}-Z*H8f
z2MFtu*x-6>_Ep<oP1oX!q${S|AJgSZSnr1EYPK==SJUNkk#xCtx2B7(xk~vmpkq1b
z;SJN(Y{RUnbOl(WZuI|!>oJ61!tBadC+<ypw(U~hJ*CV_HYdf-qmPty)?%~r4r-u!
z|Ma7uxh!9SJYFAw3B*-lO?O;cYKA#|R-Bo(ntWDJ?u((a@`uIxJwon_;rynynUtO6
zSu2ul?UgjzJ!-LS6z>Y-*xukkjXy**dsSNFF*g@av$dhsHbJUw_N%rLqe)#B1v1at
zi6rG3XprP+LwdSlp4C20pD*3{{#+r%V{f19bdIh89IFEE;J06`@hknj^!zPV*La5{
z<-AE<yI5_f$vktiTm^Cukar?aan4QCmGoH~k&U~@1qH>=G9;_L=B6d5#Tt@ngR38@
zY|p^@p0v2*4XM+N>1nevqNf>c-R#s{TJy=_npiHh+no9JUZo6L-@QrNeO24ae0Z`*
zTS{!pWu?o+wiavJ<Bb%%w0Y49$r+bwi(Rm(w8b{?O@nrNf)rHyW7YLw1B<7FwA+~f
z6_xW?+VEIP3759>pDo`~hMyolTcU}maS3krU5=zr;wijzJk8c05|8BFR)&}Llr7W`
zAa=eLB=6qIN*S?BvaJOF^)g(Ko%1-}V2%-JjsK!$c)D7K#dk#(Nv5Pvs`tfg%eC(R
zcOHZ&!A7$oE>Wqo+==&(%Z0M4=STbJA$jL5;jP!HQfEb*_*-miOS{a;D2sdomh10o
zcz|sc|BSSA%@N&YKesl1J{qiEX9wiMVi`)AcS3{F^_>3`)-;~)ttyu|<yM}{&)4&F
zl|38(XSLa2T`O0)-gK68F-=AypYnbAk6y5;=5#}9+`Q-v){^LNEHTPGDg?FK*ElyR
zgP*2dNP^rmq#n(|p5q--jdL#iq?`j={+5v!S#AM253<i@w&kWO<=Z}KlD*V44kd<_
z>s-SAak1vlmOh!=neXa`40E(GJv}WwI^9SoQt1Qi>MHew_<xRfu-2n$rAm)uqhdNK
zLwdrTuj^IoN*S`H-=nWJ1#->E`N17ZIX_kZg!Jo)OXizyD*cj%RP`F%t)@XtDc7J>
z&GNkOoo06*`K#}3k}{%a8<Lei31V}1;{M~(@H%W<mTl=wmKV${QlurFa(h<Zx%@NI
znQo+SO@@&un=KpC#t9*ueSIPJ9HU-yE^;$s*$z@BOW<{kTWn2dy3v$O|GMb7S?TFq
z5w@=MYP%>kjg=Wn8q`}PdpB6lw<F{*=gSuBQf8%0Tjzh1YetRJZXP&WyDv*kqd(!L
z+({o_sTT@N$~iZu&r|OD=c|O~u9r)d^?_<Rt5c8Zryf&IXKNSgBI_~L&&ASjp2PCn
z#gC~|zPnz|F%x}=h(+!zl21LnK|Vufs%2a0LqhFmJ!G@Tlyfg}*xOyseUO^Rs*4=Y
z)Wq>@mF?fjr|q~QaspYTyh%Rg`jC7UG<96H7L?;&tc*!EBwwS{e4S9^xA%S6P5h-7
zk3ZTt*M#?jQr%v%Jj=19>`L*tRDCOD`%?9-q<65I-iZDLW*Guvk06jYz$Y4{Hz_sA
zoJ8$3A5V=7&o|B4#CD7d^%$5z=M1vn9oJH}((TI@6=$QPG-r1y*J2A{yhC(!LRxx?
zfxD*U&vq>Z%SFT@-`ymC()RD>s?%9)$F@4?B+}_DSt_;Wj@ech=$d8SSC>OPaxB~Y
zmok>JEcVA5Oqha($2wofU&?-RoI>?D5{De8ldg@clq>PaceM2yq2+J8k=F8?Hm{^M
zuVi}hlkaHrN^0{;YV%5_nuCsx{_)P^8-_)0TKv%(-%qv=^q#hH@{5x;?t2!$HXbJQ
zmocy8R2t)YN3+ZO4(nD{-+d_a<7Zy~x|2hz#9>9t(snLb9Nc<f)FZEs*5;Lbsd(4I
zh#}cWPtV`I`opW=zU`UUKKlO0$91}AM~eOCgid^B(8jCtmVKnnEBVwZQ!qDc+F5$X
z6TyRue3GWP-SLj6^HGnVeweW3{{0_1wb*j*x1oDiJk^Uv)04MJxW`^O^LmH-PiIwo
zN5nNf55`j3S$fB>O6m$rR&Ty~{K?6ILr*_3FD7~Rmd_)92=lIaud?9A=Ueg2KUTuk
zxx{>Y&yCAt63S1E{<Zg2zqa^%(SfnCZ`5Zxc3lzo{m!=;CxtStcWmQ4YRHbeZd&s|
z-$_Z&_4EG9?ZaD23R^oKs$Uz}b5dTPS9oSq;ydy`wb%b#q0K89-1=WNucR+8W%Z8L
z@l(Hl>uvvOOKzDoZSGCmx7JMae&Dyx+k(u$ZmeFr%Wo;~ZAVGCEw8kTpL8(vT>qTe
z4;oJT9!ako@YInG4#oR>CU19JJ~2$Eo5f2`y<_IR0VRW5Jm^_<)@{(Y`5|9VxikF5
zs=ACj6MD}1a=rUBjyZsKt=_TI+Lhn+Ogpt~{X8c_oA+G2_N?8Q9{B8}{IyrMyZVNX
zHH3RziSH5rC(2^mpBXs(ch|9N_Ah#2->jO?J|5AxldjhzOS3);<Uu1*NuS$(<C<Su
zoC*w!nE1=0c2D0~KVeGu_4(e<eDcfZ!}t6aPB|T})X!O#EVnOC-8(zFQ}lxiJ}H``
z%`2(RE2+&Zsm&|-#h0sI?%_T5xqh`jta!nA_TIIvqwen<au?6WUn}*{k%5IXwRt7A
zc_knIsOr5JgT~(VZMPvar~TTiZTh3f9;owuXz$Ta@7q1)`YEZ5Zx$-|H*H=?ZC*(!
z2im-n+Psod4zzhC7wuc!ee%5@Y+3KRZSPU~ZQagCFumiWv#*V=bqIO)A7fhY%lPKz
zw4b(5@3Xztpu0Aub!&5L|6iYBEMz_+=p9Y#UAyZBMVN!P?OWk}_|Ywu^|u{-^Cm~P
z0RuNC9Dc1c&nZil=Zbg7J^E`}%SB)Ba5C?l9d$hDn}y$v>DBrDeNRu$=yGb`A@1c}
z`8Lb*YFBgjl`T&n^u4>LYsQFzrTx9{eE!Y(F&VF}{!w4Nb>arbb{r_-sz<z+o;)lg
z<;;kYo8xY;boh38`SFF5j_Dtt^GnCVw>B;zJ|!Q`KTm7(O0Mx(y!GJB)01A=owI&J
z;O|w-GjiY2>E<Zs?Zlc1MQ=p7+_m!A8)j(pN@k?#bg$7Vf%l0!^Ls=cJ@>^P_lfOR
zZgwv*-CW#dQppo8!@Peg>+;*mLA>`FD&f2%+HRh@Zr*#VK3LW=&--9#+Xr49y>(fO
zTfH7#v(nP>D||#&^C3^~SoQ03(Zf3oi|h8)n`2VO-PGf;AD25{@zdxZlb>9_qUOle
ziy3F0P91v3foGjw^I!K-NZ7W%=eEE2fZwYvo=I!<tV5Sqj@`cGbgk!ad|$`MQSaD(
z_SurQo4Or5?f1}^{XXqG^u5<TPaf`aXl+#QMPt&h%gg7z0PhC$jwi!X^0N<{>%$B#
z!M^X9BK|$+m6UIT>bP^tcy!z7K<vmiPmm?d!8)(xSQL{peuZ_O#}L-lvEY<GGqPVx
zwo&wz<qM+awXp6>RQer$jrK*qMdkbJA@md~-}uxq&y>E)5>E@ZQKc!%LBh#5XxUG~
zhsajzm>7TixaxRRmwjAy45hz)Ty?CV%Ra6;zRll0t~!p(WgS<_g*x_#GX8*t_f7WY
z;zLKBMO=dSqLJvwsGJ|!PaRj|Pw%IW8S$t0Q^!O2Q~T*jr|Rp^cVh|{`Qy=8h8$Ox
zeQJL6{H6NQHyQ3DyKt(Hdb8nF|L-Ql*&kQ+t!^@${c%;lWySAL=7qJ-2i2}}UL+r?
zUvQJ*cujpioa%S0oXf`X&9)1t`mQ#az6SZQ`cgI-u0cL75zan77psp^llfSyrccVD
z>My8-Yh14xsK=zQLkueY)nnCqO)0->{8E24-Y=DKQXi$EbkWe6?DosO#C}WF{g^9P
z+3!hpKRt02tNT&)U9ucjTq2yk9Zy_lI2WsLh*BS1s{DIjBAo5GVz+QLocQWUxv{S=
zQplRzA9$T$k$l?9rR=Br^yu`gH{P#^pT*wmQHj@9PG!Gh^>}@n*w3u)Hw%?}jD5L1
zaf$piC}&pRg(mG|%eS7mRiBY2!`b3Xlr*aGiEoGGQ_5cy$nvzB-estszj;hh(!Cs&
zKF!aeA!q?Q41Ey|M^~W}&^4$5wUvJp>#FaC;*%lAyNYe`APaT2Qtl_Ca(})H^+jXQ
zp=c}`fs$4W=SnvXeHfjNK8w<g$g%~^Ko6jEP}}`k^=r^cdgQqLJKrwIB%GYjg=i0S
z5z4W37XFDX?nTevN38wom2_9MX;_|i6HelN2NgTMtL_)dy4v?&@d=RQU%|FukmU`2
zmgB#P(rrk$3zh3w;*<7`#Mc|O#h1&v+P`1v_b>5X!?rAt<pILCLmx!Njt`*&&>U3K
z@+dk5eGH}S>mEnRqmFnjc_@!tmeuGJ=xZpCeU=K8-z<mGr_dG-%t3^TzrhC7W@okU
zz0xPYv7Ji@C;5C86+3T5N21%%ThZ;PEgrRxywZ2RaXXGVzLj_~QSpggh;~8mLA#-g
zP>IJI)c)#9-@(T9<}$)zI+?p%rW(;btL|6Ky4r_a>02)Okn>RpvV2K8ozU;mwkS4H
z+8x!XoUfy3XY?3)Gg^cCpg*CK&y(mlv=*hT=}x2AUUvpvf!3j7_uo*Cp*xF8ett*W
zU~dP~*$L$wSftOpqnd6xw`$*TrCrvzoLx;gN$)kNJL-b!(RQdO+8zx+uS4Z{vaa^k
zR{S0$KFPO~MOm18-6DT?L?zxEP#&jr9_s#Lf3=^r3?KA|`_^NGlk)I5>V@X2`^j-l
z*8arGvE;njA2(aw?;-RC!aj_OogY#6k6~TykF4}lmUPQ;B0!eG*iq6u1eNnO6zz)+
zN7K<!=zZuIlrpd5Q@-UzbSz34R_2!%`$U4;r&#CDx*W$D4Fg%;C%mNl160b_hp1fN
z6=)Z9AKC-`1Qq-I1NB8eLnZ!jQ2P%nb(O^5ifto6mf_@A;va!Zenz6#p|_&$=oqvc
zdK=mgmFFgjSIUXnM_B1QEb(5!Hd}qvi*Sm)QHi$?D)IJ1#ooTC9_^3X;#2zoHyPhR
z!byDosKgh5N_;`6#CHp-M+c)4pOhQ5Z?8_mOZps9PmrZM;UvDBQ8}+(cKfM)c9rMG
z#`{rMDaY@M%6Y#@-7ki9wePIbr&ji}FE4~uj@Jp5baQPh*Ei=-sb5K#a{jube*8{Z
zRIa0*Xb^w*LTz?Z`_C%ZLu0%5C7hHW&XrP5s52}c{OyYpw~jhoxlRV6Han?(VwL*8
zaegO}Ke1CJD)*zwYJL^_s{K^2VSD5KCaC+}q3#!fmQz4_Pvsf{Gvq=sR6s4b-Oc?J
zA|M&EARo5Dey9PbXzB*=hERwCGvq)a?124H15PnK<3KP(fC;jpoPv;#mOus6fU|+L
zK?p=ZB4k4mltV4J(RlEKd@inHD1#bsKfrT;0(IfQmbz-^mO8)IEtUCg0@z-`x_8f(
zy5dbvx(NQxk!^FV_gRm5#0O!J2$_%%J77Q5gWG)41z})<TquHar~&5%*7<{K{0R@@
zwBrSlV1jH|25Vpk?1vg~4kWJ-1!gGJ5hqlzUI*?$*bU+#2TI@&xC~-D#6va|!vS#O
z!tV_ckO>8_8)WXHHn*@3BtkY6%in|f8}dLdm?*G7A(Vkj2<d}F$b(X-0r#P7hh)fw
zVyFU_VQhzZ$b(X-2DjlH3z8upN}&>Dek6|({032w3Hh)CDxn@cM)EsEK_=wG4yXjF
z;5{J}%AgABA^cYC3AwNvYQc@lvT`)PgPt2g2*iK|3ZN9Kpbp%*QG`G|WJ4j8LJhca
zQ}BaG$b>>DgBoz*#^Md(kPJEhkG=bWt6|+6{=X;+p$H)?g#3?+B!nV_5VD0*5lT@A
zArx&w2qA<JLTK9|b`jcy5JG4ZLJ~r@@cUfT>YNVtZr$g2?)&*Yck}Z0oi%IzUDr&r
zX3d)UUWh^xGN3wu{Q_2Sg*bT#MKqF-fdc3bWErrA8-fvoRAfV)4-|b^!5M*wLJ~4j
z06tq~c6O{I!V!-QsE=SBVGVDDAr4v4{E1^a>>*B^V~_^fNY)2-@I)Arkq1qCwhwHP
z!7??=@;L@?gb!w25J`VF^i-&G_%d!7Vv&kmXpUk&vnda<7$=CB;>-ARSSA81vb?!$
z&v~q)D)k2=KkAPdjRN{3=QA(*Rm)K~FyW*!jF^f{WZh*Qb9lczfBU>wu#k13-^8Eg
z5sTW$v*NY78uN!OtXEJ6FPVmZy#SU+v?0b39f--q0_bwkZv``?GTfdRf(XPT6RL|S
z2T@KmfX_X~;X^7Cu@GO}G~ok1$`V10K^EgC5>uhGm}y~lw4BTjX2;6ORF9XF#Un7T
zoXp}xIhn@Ea<U`@|5i?x0fTtPMGA}(%E>}e0EbiMWQou}T}~E+T-YX-lf^>!4AVg4
zEaM{&Cg;k@d=U@Tq;fJV1R(|5zn7EQAq*MNJ6}#_4re4I3#u0w4j&{T8`{Z~0U^kO
z?nPe19zF;|JhGvAiFJS-yiwYf)<9_ul-59L4V2bEX$_RtKxqy9|EmW0S|I!KMX}DB
zGFd~;{l&96;yLKHx?CHrR`|TK0sRTEMkE*C_Mi{_8?gyR-2nQnn06ROU?}4a!*CRJ
zVz>o9p)p?LEkvhJY!1=BbX&BC=)MrkG7nXhSInyy!z}6Vqj=qy*CJPdHf&jsVR%aa
z3gRlP!Oy%7!aDlbLv-1^euS;OzC=vH6<kMAw~hCD!cs9!1aSv;VFJsKB<{gX%z`iG
zVm|z_7)v0!DB?aGKr{|PbWd2G9sQ!N+oJ_qLUe{iV{}9(#jp{?DezLf9!a#vD2#?9
zMBdmv%=b1P6e~{@{bsz^6`~tYoPbG+*OlsV{h$5?2!MFzekqn?B|@+kqK)khh^7w0
zh?^nuiHNRfy3?)s?u0fB7tiL4oCB@t7iAMU5?VoQH&I^kytgR3h~ioGcJzy9&DTQY
zeyYQ3kyGX%{fE(**CHo{9<dRov@FcI;YIYuG)%_~_+Tc)GG`G*-dSJF!CcIPA4I+o
zQGStQXdy(d5s~Xe<n39EK>Um)SPGGUrl`|b%v<D7YC!)>ZT2OUt<SYrzVqhMzmxSp
z3KiZj2URqL4&<ndFy?8(JVdTSksDFu+!k$#%qK2H0IoIUS~o;q@Wl{qiY*}qVFgw~
z<eU;+B=7a1U*v%6kH!#fJggzEgUFF1@(FK*XuoMQaSOI$8$`}2(KTV+nnLWWYZ_2r
zn2!Zm2!8}%5k!uWK>Un}O!En!QPh1A{nT?Al!XdTGT#??3DM=(rG6M*4&|W+H>Oi3
zo?@H|#EQ^BWwb>*7{VAPFhyr{K{trwS9j4*>`AmhFIb^3tT6xsA-XEWs?bDj)InY7
zq8{p_0pw^1v3(m6?-Lsn_0R-O(G1Pe60IRREn+oPhc;@UCTc+kq7!AFj3w0NQUqZc
zmSY8O@WYyDt9~U`VKqV^a=ooXDAq%CVpwhFC35ZAK;-h%=5+$w-JE`rhq9*_2GPdK
zP~tEQhscGl1Chi1C!A&)d*Wy~U@V*<x?tXGN53JAQ5B-CAs6C!xI^UTpA6B?rUy~9
zK|d8<5V`t9SC)0F2GM?z=uB9DvG3l5Xfx$8`^a{tzeB&sg(`Bdigp8bFzg}mF`h!S
zvta?zwm~*t;uYTDE#5=4aU!}Xru|62$lWV)1&bdVMEhlBh~-coqD>KXR6s>kf(9x>
zv~41~Ppq5xyETMpm*^<3H#48E^ozWjB9CWJh<5)hiM?S3kw3m4`ePt$Fa)*`?FWf&
z1Jl^iFY@Jz{Jf$K3(?l#DB>76!U^Lr0h2Hpo|uYh5M5c0Nyhvwjb<Mz>Qosf+LOH}
z=b9ZdA=<Is&H5KWY{ztncB~HadO0x@Patv_i?%^l;3abL2BO^(kq_-7KI03@vJR?H
zQ>@D>hH20*a%hU2ogz=VXlu0wu_kmNa=7cF9_phZ8lee9J5!?j%sPpEcQ!<uMYnl<
zjQPx`U*ruHc}hh-dC|t#QsQ!~z-ojb6zj1Oo3Rz5Z6VQ}WtvF(MLuAWfA|1I`(Fo%
zhj9d=EszA9!Z}>TC0xZdi0(b>^bu{?Cq@0M6GbQ5rWO0HI1Y<_?hr&fkNX+-3qC+>
zXK}n2`%O5uVjsiH@HZlknWFB+-;}7kH4yFl?q&F&5I10oa*MxRvEC`TiUYh?N%41<
zz&eztzXB>l6Kc?a_*>LMRaAsH&L3re7x}B2@p>jd?upO5WcsfXx3FJrEw*p%q<?p@
z*U|JJF82Bu{U;T#&k&Oo{TGNA75!DHuc{E;6^5lMhTkIIQS?6`K2r3HdJ&(uMV%;z
zSpTA~D(hJdMcsR*`%^Kk7<Q3yJ*gvcoUBo7x*AMVv)FW6tW$Nxdevcg-D2-GpkJ<d
zU4wboDmH&Z`i&K@Ycai!VjdkC)=4qkl4zyqA3(HG^xG1LD*8td?G^oFi7tx%vdm9a
zF;7vRc?|bgyr;%+b;Wyb44bSNF2?hwe}>|9CB~_&7;h=Vf)vApiR%^p;@n=Gmy7dD
z@%=!=0i5@U&uVdAF3w3Kse|Hn^Lh{VA_}5CZP9U=Udo+sMzjJypU8X>jeMw<VV;nK
zd-Y_o$VLIw`C?;@AcR8v24c&1n-Ih!1?kY>8ovcR5rTN6AOqsJ3>lZW-OBT~j~FB(
z750^wH^LB!4Cra_n+42a1AF)(2&u?K9#kvy_XJ(ULi{+d30>GD3b9CpURAaM!V!&p
zSW}N7h(HX|k%c_SIOni{Eu7&Ee}o_cVxJN1V?{vx-Nhjp)@-97gdq|I(BSXb6~V|x
z0W@l{o{;M>Z}=k{qMes;L?aH#$U;6u`zSW>M;JsKBO+Im4)hQW@tGq2CdD~$Cg;jJ
z98>gR1aTe{jwr+;5g90erkw8&Fo7)`;0t*}>K?%eLnLC6ggl5F8#G}A8`#4aL5M^w
zQjmdMXf&qW(1!_ZU=KI=A{^03MLt6G7=|dsA{80PMn1Hgu#RX2D>%awL5M^g(vS&R
zQ<e>VSik{p2t)+pVWZEyVbGlY4-RmHFTxOw6l6fP1@#L(7{Ln8@IfFV5r<Sbw=6vF
ziSJ3Fh(I*rkcK>nn~TI}w)pI|fH+qX=OV7~N1lkSsT1h6VI5%xJ2=A=z6eDOQjm>&
zsJ3N0p%ubJG+<iT!WG`|gS;K@!2}ktfg1u5f^bA34;Jky2eOb4RYR5mUFgFCL5PL8
zVMr6Y(1!)=;0<w;N*E%Mhzu0K-k5cRH^dEtVTeUC(vS&~w8=D}4<nev9zMu|D)%wS
zkpXiP$^(1&AQQPLfVhW258^%sTR6ZCfe1k~;*f+)h$MGD2thP_JF`6GLzM%q9A>bA
z8v>Eqjq;mQzc7IX9N>mPL?9lS$c09C$^|o6!5MxK_bOQTVB4YqIz3r$Si>IT{)9m2
zSWqSyz#4XNh9`m$i5Mgz1L8gfbxZ!HAcq+eVcU!8kOz^}SOfYnf;p_=3V(zn4oOHw
z1`6QD2TuVs`Y><A^<{og?Z<urU9^H39FPxHYu-aEn7{%ya6=$M5RN#cArrYMfKGqP
z2)zNUCz6qdOo$uiG@t`Ln8O}E2thca5DRgyf|U*BKrU1Vu}+Y~0Jg|RK2!%Y9Iapi
z3pl_Rp@=~|l97fyxDH``Y?&t_5rcT7BMW(u4W)iy0$X^(7l8;tH1vj14@ic5IIrP@
zNW>x$DM&{a@}OzQc7z$MAnvnpMG*8xP(GN!4$km|FG3N66l5bGsy{J5v_d#cMlw%i
zARGD6wrAbY3MR0HCxQ@(7{ntPS+F0)dO~$H+X{LR_jFmn6|ymGN9e!^=CFnxyb+8j
zBq0?U$cDND<$$&$^F$nykcwOsKz%Il!vNNBg+GE3hDapB#EE)92J)cp%zDECF-SxT
z(vgKcsJpOSn860l@Psb{5r$Z#AQSme9Y_5_7Y49~Gkg$)P(&aaiO4`cG{>`zVFYV9
z!xtflLL$<U2Mt%&3kEQU4g3*`SR^4EHWS#!NJcvHCsGfSm^Zv(;70iogfMuzGd`jr
zpUm`dKnyaG2X7Cy1Crt3Nj)PRnb4lXdO>?C`xNXDjCkZi++c4GZ-gTn`O}$Z2IImN
zL5N2#WImJ?y0Aq&RA(}OL?a*ivnUgs=TLSeL3JM646g8jfgk<wfrdYI3}<*lH-L48
z9n=?5_pnD+Fz>D8Zvd{Vr~@P-V-3q+%Q~ZA9rFrhKZg&Z5C{JaL?lB$jL!l@Ar8Ue
z98-{mh^;a%HnQzug+Rn05qW5}opQh;g8D)<Vs|ht@?o`;<suLv2uBoRk%$zeBMW(u
z?V|k9fgZFYsjJ;Y*uoQ=H4Cpz|5UB;dXEQDTz~K+it8Cmh~iq=eZ~{livxJwo%fd#
z#kGOU3>Vj@_bH+=!^QQ8xkT}uTZ1UBp-d)<@9=vWPh8i&LloDX)wQ^0K@{isA}(S)
zaeXC>*Wx<5_+BS|t69u&ag9xlD6Z37W4da*7T5h}^IDwyi|e~Hcwbzbn8WMAyuQl&
z;###2!&ftW1Fyw=U3o389qr<^xb9w#DDu{>V7U06zmO=dIkh8-Yk_xpUtAv-4@`*b
z%l<@h-Fha=5!V~{^S-Eu?L={1e=Sk`CNPrm#Pv8ehKcfKFkGxpI8potu%0N^XFB7F
zYZx~fCa$B6<F&XZ@-tCf%Nb7;*UT0WKNACq;`)&~QCwq;VmfiHa2~Jk6YnXO!(LF@
zmDWIM4V2cv|H>LrrPSkOWjH!=4q$5U;breJcA~wbyK@I4lI+{NPnbN(Wh(7)*wgxt
zm;E&UxA&UrWbf$dDSC^V&an4!_ZAb1Nu+7*XH1wp#?wQjc6ae=!#iUBrZO|FG7fwW
z^AuPe&XCmq5&KVYn(E=@G0t1AKe)Mkpr`i)_X)FT>qFkt!`*X&o6A&LHJP5)m@(6x
z#yEO=Pn|G!nzxIWtR}-;UEDlfrWPN{b!&z@db_a<F%9dfXmrEfakArh7kAoIC>+O&
zbnX=yXE;g3J!W`u8BR~Dm&dfpw1G9jgL6AEpYA>SlrWC9mbhNIT+yyWd|6Ra=~+YR
z`ei)*+uCw&*rTGX3?EZ8q2fe)GcL|!{!v3S%^VcX8i;qtx{Rml3Ny2h5n162t8r#g
zTPc6_{us}xqS;Ju>bon;6uI23h~MeV+c8kIonk{=&$<mP<LoldktV=~Il4`A5$|be
z@i8gO<UJKxVdGHJN;9me{fNTp*bUr0oL$^(#Fpmlvv9s<#5ne-fn^j$m1a@+o&oPI
zmX;~)9Wxb+WLv6eSy4f8)SsMjTnp<<T2G_Dn4icCFRWG6y||7mx-(EmJa&n?@2O<n
zJG)GGaTB#j#Y+kG#eVQr{r}xK|K>K>_&3`i>u<I};dKArHb`tCw$HcQAd&hvryk|h
zooiveDYXrjD7FE&ze`>5ZLnKx0}Ca$0e=?!F^YD6q&@4a+W-E$|7N|f`<r^t{+oI)
zobKPN_oTn5cPr{Vmb#Pby|Av7s`pundJipMSnu5lV&4~kgVCbiE&oyPe{sO!xZ&jD
z<u%4-vh!D!{p~ydTG8SdV^X--umAtYF~*#CHhrg_#c@RbkN3W<OYwJIv`@LJF(RD~
zDuAycvSZ9MzOZaR_~>bBTC_HWt=kkH+Wxw2jKVe+i`phRB9*mh4*xtZit?;dY%6oI
zf#`~t=M>Xrd|RHsJK7X|BK+Mr#WvV~R<7Uvrd)Fs<x&+J=c{rhGo7rLv=0{FPT%fY
zMWy-nogY?)bAMBYMT#<{e5VXom`?s}8NPokDk{hK-~C}_x%@X}Df&E&swiy^jw4*x
zKy6%OI`ePK@>gdSMWy+x_rG7B!jF|P-X4kr${6pN;yR)D8!B9*umAsNdurlOqww6}
z`+q~5727GeQsF#`m+d-bbNIGwfA{xMRKC9(=fAy-MaMk{jlwe4B8cr*6X}%E@7pqd
z`&Uy`vTxt{KT@8;WBm8GS<!LNq;g?-dJx2R?t%=;6aH;^zW>)#RHpC0`(G}XIR1Xy
z{c~TG^XA{}i+vUCNJ$UZGp^XV#dZ?A<{y+x)>}I6DRFXN__v|YB;V<z&(dLB2^8n!
zO3bXNT~Q_eX1RXI=h6U0IZ~?>E?s=SigJjTk6EVtn{xc!pG(PQ8BJN9|7%(PZiYqW
z`MYt7ZTrG96}3qgRJE{7#kWlk%QpX}OyB;Yh$;X2bHA{CxxSR;^}m+o+Zh#=;M;e;
zS?{8K%0_XdEWR!BSdPOt>;3&d24&WLFzf#QU)TNnGb>vE@4x#^8S+@TxgPgu^4pnQ
zWuw6`_w>~-YWh4nR#$7$#LaatJbF~2re}?=+UL85w9-G%wR>s2^&6V_9&B9I!`N}2
z))RvX>qoDieX7>kt+PhT-PSI6Wi^=Vww7Xk1q*l2xx01u!-cad9;@D<$u!Mb*)Lk%
zeNZjxX#R&CJ37tgx-pd|S26b-SABKfvW|fjMyzn@K2hylm|DxLJENa8?m5`DQ~$Xa
zxZm7fjOQ`=!=kr&AL0!flo>g2YQKDMw@nx3MQ`k&AKC5XiVgGmB0NYM&m~}B|0z@I
z?bLnvv-@v#?0Q|BYIQq1EUoDiujeO2wu*a$rc2}9-R6GT@p|KVo!i(SZoja~`syz4
z>%?r&-!@`LfZM6=cUAb#Esgg}__0fm4h`8*A>vJ&mUc=0y&4_c?4J6^>zmg-PhW^F
zvyJ0oPqBU~LuY+axzS*6Ttw22{d&7!I$AgUFgc*_c+*AKdb*n~Ji_lDW@5aM)|LF8
z&(WFu*KL6P=$x7-rE+}sbyArZb>ZrTQ_tLgpC2**YH+`VCHHLRZE3i^*Mw$s`MvY0
zG~VPE+wE<uBu?wUy!yCFm1^ai9rRATf6e-Xnv2W(#*S|va_^vpC`Y4uo2H(K(jMTp
zq4~wgN-GZScz+{4Vadr?Kdl~hu3>YHY<`~^CB_^7x!%tB#-<Zr51L|U)OPHVf^C6T
zc{PR~9{c>&mFN~~i#ZPT7vq^NzO(#!`h&V!JL4)?T)+RQ%EhJU)jM|^>0;Zg{=7=(
zYOt?zVkB3|^l_ZtqTirxu3<~o&s<VxuB+ituMD$*xweD;t8I#j=U?P1c8iP_$M4cQ
zU-3<~%O5kpoZY!|eEG)qN4Jh%ed|VH8#tl8#dt2sDHA>$8Q0#GT|PAVz)v13fv*ne
zR9drf!Ia>Zp=QzRxp$6rl&kbQI?VX}EALP4o!U*Bx}{f@U&}_H(Ae8gR{K*@1)FvW
z?DryXgIuLen`VPXe(t4b{I-$2(W3+D{yVBx=(c#@gE_GW&Oej4`jyYAZel#ua>fTY
zI5ZtF=JC1)z6Z^I(>qyfZ_b`27aL{{95v_jvPR^WG8E%|^qv`9K{sgffV7y)F;%V%
z*mrGO?;0J{EH`hu_g>fe#TR~$k+z5JS@T7e>$iXLdg#K7o_W5Z8-A`7dw<g7yjt2T
zZ;$kB(Ue=R_;M;&G5NCe=t<u{H_dcxb*Oj2myW*ABH9ceml81BZ(5}8w9s^(6_D0%
z_ht2y{%Tv-YIfJVzVCs-a`}MX*P67v*y3vCstr5(cNxoXc+&dKU1@4)p0nC;#IDVk
z&qR79b@;e3VAIeh@8?*hZN9qgqZ7ZiaiSqtsnqL$OVG27<m>N-EFTwDV_xf%PMy?z
zE`;ok(&^;lY8%7;CvCS?uXH~7Ip6s*vhRtimL6w=)=mA*Y2Bc%3!Fy8Ut7CFzktto
z={U5e^@aL@@0#`h>$cX8aUo8wvN*x1;%{>jU(ED*op>iIPv>3S2kWD~9?ZBf)n-Pe
zRB<lUU)pX>u7qt_ziOrNlUIj>X4DG3lUHW{T$#<XEvCbbZm%=m$=~@Pss2)?Xg+x#
zx*_L%&doVv>;`syT=n%OySO?X`+L@?qZ6~!nd6W&zmnTH+9}mbknyJ0Uw-ay>(TYn
z)z2YL_ahec`*JqvT>XnHa&p_u-QSRVb*1Gl)KMEZ<KwpJnISJuZ`hO2;KatWy4$Wz
zI<ho9`Km+qQ+}Uzl=g!!Ved9Qnt5bU%eRZGUz*)$`01d>gXdOB-g5MHmeujwr`Wcu
zr15@L>0KqUZA7i=?u%1gd$ith<ih*it*2}rJLl~45gX@@;5+{>(s*S<uclv2-n&%o
z&-PPK4Ii}q!NPu7dA5CS4E2o6S<?3TEPj8K>iOP-dCjUFebQ>z5_2mfuOTW|Cf#Y6
zw8!*r)UG?{8;!GU&To>^=farOh;GBK?3?ww<{F!KRj=s1KGC&H)OFX~XV!nLpK*R9
zCt>ZR<3`xY3(Lzto;b6`*@L$2y5D{5aP&;$(R$VzXDb%9Eq7a5zt^6vAKdEMGVR3c
zULQtlFV4|f5L$2GnyUdS`#)#5Js!n=A1ZARk7c{>xNaTTd+vft<tkjQ`^xgzoF*n2
z{g<iL@4L9in07lkALfKquA+8E%lLNIiLt@9vY7W*db&Qp_DkKAp~sB-CC;!d*dy*;
z*=QxkE4gilvV1v`tJG>y#o+wQebp;;c+qg*!$}p!_qscHic#yAPd+|<;<fuz7Qc0O
z7UTJPSG#Z1_Q<nN8f$O<o?mX;HZ6yZYhpjec$YJO|MRWHOB`RM<^H&~BECrVXLmMg
zS4K{yc3PjEdd_USrNf`<btccV*xGEElSL18pCNB~hQm~>U$fu=!4*ur!>UDGdD8vB
zb?4ekhHvYwmvHx*+ckqmdiSYkkzbnQmFfPM?fZ?AU8*?ok6LBZPbb`S`Lm+t`8_d)
zlh$3^m$#bx>-&iDu1{TAW9Vb&TF<<XsNLE%>E&bdEpsO=es#+C;`3gI`h;;!|AI8$
zpgC!A9jo0~x8Z#9^VmxVVmh}PS*zloUG8>S)};RI#PQ}_*X}Fkw`+^%_Ew9xoEz@%
z#%~7x^9LUuGPIu6OSNIOOd19SAGpPG`7D&H99m<OWmjSB@(1Ir2UQ%<Z1Y&d6KkEK
zG(R+~G3QLbb*tIFb32Ohe7m`92|fJEdr7-~H@cU%>r%#fwP8m0jpG`(9O!&Fe<a@x
zmvQirt3+nJ<BpJirnf%FSUcXDWOv4ET%y;)R*{FEjmof_5#!1I3DWw79%*srV~>?<
zb!%t8O*r(pdrZd<s&d;`J0_p_RQdUo?5#YHBaK&b8xV`6@v@dStEqiI=Dgo!&uO#1
z^cdNFcJqK5o2I_*x2E5NpAU`UBv4!0pN}8tlRR>vX|n*E0SR{<{mO28@O2vt@1*%1
zs+7=pidKasRXpdcKJG62S!>bkTOGq{&j^0lIIZJMPd>LA^b_R`bBIe_?EmuVrROQb
zT@r`t-`jS*PJf@fp8HbvKa#1|_?`V!IzE5&nRCtkeUm{pzo>Q`=My-u`<awG`!oxh
zs9AQM{j5g?Kc26V#@jdkaGlO8Fa5Tn>R+|t=V&aJTi?sNUehK|YDd`4nmo{XR^T$f
z{;fX0%`pu~YFE2Qy|7o@J0Z=l<hK3>N&7+N5NFxN#_5_3>>Dn8e6riAp<UwcY>n|g
z`g<3%J(X+h-p>6v(s&CzK2DY``XzC4(j&QV%ICD2zm6C)@z!>acD?N{tjGyvnZeTf
zg+A;k|B$`nUYh#ekXKr<hNCKN`_!n{j(vMg_qNIys>1%)SNgnM(B|Hz#}j9pn59Hr
zQoU5GOtw|#rsji>E^M@^UFG?WRjTs5i8Md?=9!<4AFeRPyUK_|w_Cd{df;1SQ%cL6
zu(*a^9w+pg?qh$E=4aJ-Y`S_`l_@zI4Yo`$2`|W=8b4US_u-D^dptY($>THopPRJZ
zo~OKBKTd7gv#1W&*W~mKGB`Kxc$<cSf5dDb8|9HcH<{1D^-_5^w!VB^@52&5%QNl<
z?PqGQ8JyDi>cI20Rvgj$V~}O{`QbdbB8|5&fAOH5p`r7%KFnSf&~IYqHviTO9R{3P
zZnF4(TNU*?l*6ct*lth#AC#Z}sml|yKl(;*nzm`=zym7pZ%p)YXuU0JmC>R8?58t~
z#CRp=^nW8Qcero&iZkvEyxc9tb7+-Ob6Y>&)&5AsIQxMwK178_{%U-N`=F%yvs*Qy
z^2y!q!L=sch#Mbbz2?K*<>PnOdbs)4N1x<R#+jA5Z%?YfNVB$Esy*3VY4@!}=SQ-S
zvo$)_j(c~cYK6re0;kqJc8TMfxUj(bmDpBdoiSp(z56fDKBVWrXu!%EF&aBw&h`9s
z%A@0gWwwXgwTR5U--f@*uF`k|dbS%}wswz+wzXZ`FF5t6Q<bcDcYI&v^^7;lS`|D0
ztUAxGNcD1|&JvgH-PZ;i=v|JDZrA$7yOYM6_L}oe3f_56wKDGgmi<rqye#>AV~w;Q
zl-%}&vTc)I?jXv0q|qVk6Olc(dQDjTCTP=ho9U10<mx!7_t@I(<cXE4YW$9?Y#V;h
zrE-k*8#1WR*}4;l9eh>cWQPWNsYbhYCMWz{Un`}>q%MA$d=LH6Z9}?A+vBt6$X@v|
zXU}T8x&3K2Z`s1`YrAADxTWGYXJx;ATkj1H=5tyqZ^>;^{v>U;J(KImYn)2#mh1lI
z_KND;%k5APS@C<+s`<y7OlmT}dCx5zPkTxAS7KX<YSQ<VlIx}R05QMOEB$nHY8{-m
zeO>afFX}VZ7N!>5NxI(l$#HMT<Uc!X2;e?4X?}Sj<F@NeyViHIec3l<((2Cgd2N5R
z_nRA!pG|3TcvwuU<uciM>F?L|s{b<Cenb7Xhg<@y&L8*smvo1Vvzp#<(X-hR)88V8
z-<cz&`ZMx49y-2t%S!Fj_oQ#|@N(a4xo63jMUICvMwd$)e5T8rAKyl!vTaD-G#B-9
zy~D>YBNB2NuGG+0iys+2B+Bfu@slON5B}L^<~cJlUi;zumb^8yt8lXas9G<oep=ec
zvR=1l37@>@eR`O&E3(Eye*2QP+vV;q1@S$X4Q=DrdZFs(Un<q{%eydlc9Q3vCC#6%
z%ijH*&;71qe*Pu4A-TSr7_Zavy!>Xf>ff=;)E&LRFf09uw`HSa%R@H>4_LjvP7~`X
z98Wum@uuF?wD$M!rRp{0iOY`efB3bu)I7JVPr#E~>kL%$9NI?l+?@1xp7wsT?98pU
z+l*Z={_Y&O>y_Fs3u?4FGRh!oT+=eO>*+t{+OKq;^R(Waoc@i@`!8>&8F6Mz`#)AL
zOLFPGy64Xmvo{<Wk~4^7pO<v}%ej8k>*K-hxmVJ=#eKgG#P-tp-`OhF=g!LySn$4$
z&1di6fy2FQS~uF_(|ACn>G7t4@3QuDPo}iLI5+yEVMgkcKdvm@w^F@r+NnLi{CfI8
zTa}k>dLBJo)1`MB_aRF2`?4`-`J-R=%zyTNL;bx~R-Z7KUM6c!XTM$D^g;)Ot<iPl
zURmipF)4k6-nzK`6@&esYsp^^bJ#KM+?tu|40H#UnU`oCyuy~}Hl^jJ`8UY8Qm%5H
zlWVLR7!KWE(Q`?8+h4A}?R#a<RITo_`o8DhMCtFN<Tm`|4q|(3`6X`ioyLP}7;b3m
zYjbFw$J^AN+m`2)n_11G#oJd46Dx5)gj5cvvyCI0y(;_LpfVe_zWdc;U+Th(<6h|b
zlzrNHRNTZ__qonBKsvvF_T;J7gArwO>b&!h9MP`H4y!6|rUp45x3un4p}E$<z!`iT
zN%Nbp{<&L)^$ukQcDQorc8{MHE_j;O>7LPy=jC6`*WXY+Ac=d2rS+?|uKP_}Q_aUi
zD;QoJ^izU%gSr!2Pwm)YW?U_&xgU;iz0UW>>Y^My&n;`45W9TyBE6R>rt{33=AY5H
zRCCzP<N%+FAG%G{QR6;j>3p|e<<1Ev&-O0+{jT|M2P?e&9C6|5`2(wNm|DN9xIF!1
z6}~IfmgYAm{%pO^m7HIkNO!&3XXBG=gKa!kReJ0A_EO#3yP_7Ea=s>>m65CDco^zj
zxUngETcwXL9CFnvPu_UYvWn%&KV}}=75uoKG5fu-^!Ks!QyrgVgCp0>0w2Ds^B~IE
z^-_j|*WjFG6(;TIII_RFZsGHzeE+C)(faHG`K9zO>19vcz4_Gs-spSw_I+ROl6$sj
zF>NT{S7%7|@^SjB4rj+Nxv<lJ((tZLf43j`_M~R`{8hP4ntbUq$i?d*=YP`nnC6`G
zZqyg`m(|A@4AFkFA^bw%l9{_@b8M$I?(zGa(cyeIe_2D6<JR*Or(C@*R~ls-2G?}F
zvcJ}l5&Mpp*;0A_n4@JMzpItWcv8LCb(W`Z`fTvo>`MDC$-CX&AKG$e)0aB?&uu<>
z_(-!}XHUtvpeW{d`t9J{*VASD*4IgmJ-n%r>XDIs3v#O&tLAp~snIJpm%qvL()=Dq
zE#0&H{OW6ME1FI2|3{1W!EaW%T{H~c-e#`qso^^ZbAF&~TT<0c#Bv8@);x4|faT>g
z*X$o1wlX}@&*;;JPHTL}-5grs-L=>cQ~5qE9Vac-e(Mvi+EF8;*7)Qt*9rnIJ#0Jk
zVqkEz+x5N6${n>(=eJJjy2X;SH}@R-JkoTu-J9*6Q_XK3xxFkx%_nZ<@bf|8m(>$g
zxehFq*YvzuyDeq*Y41oF@M77U0~-6MEgz6qu;udf8@1Zhsq*I>?xB{pTf?o}j~uM@
zxKeN5wFMTZs^qAr9&7J0tY>PX@%(zG?JYTn7$TKJ=lo#Rn!{HvjO!3qarw{@+IQ@y
z%}^V;dPJ>mXX7kK3}s&9rE<)f@@vMR-_NwUv^L?%iYM!j7pOcrB){-;R^V*ktyNw{
zuzo4ha^Gu*pENxbcDQ@}ZTmj%-d(Tp>Ju3wd#&#@?yWp6V6NvT?$ef*`#NK#zi!vh
zZFS~7Q3-!LHu<sb`2~-Ij5>ryPd+<uV>tVK73p}jCGJMfvT>JQ`uV)7c_eY`wCOue
z?NW)D{Vr=ux$*0M@>{}v+8o>DDzhxB<WGCF<mk?^LG#>JZ4dPet0!CJaY8n}YQV!c
zEdzbIZ(KUxD7h^&e`&d=9<3bzX!4x!$G6|v_gk~b=YFs5oA=(@T4iy!9otvTZ@~85
zA&uAImxx8qiM3aTOz~a0EuhL;@AIa07IwMqVVt-7%Q%Dfb9pXWx-KwQx9s4^$aeFM
zS0(Nqtz+6|)}zrMPt0DDw&=i|z$pd&ZTP&DjvEc?n_Ql?H>bz(*D5D-Duvza)Tk#<
zm7TcyqW3U&W7{72d_R)Pd-_zt9<`}m)$+>L)~vAlp1Vc6*SCkow78ZPms52~gAX(L
z-Xo2-u-4F@?+i+u*68k~8Rr}B(p@~RN2B}64;<8|P8+@9*R9lZYw3JVHzs9P!{v!)
zGmT@~9dztfP_;|*)XrB{y=p$9T)nZ0%Z79ByL2479Qkmp`!Oxo_3P3KZj2oDF)!}r
zvW!hPGqdJT-(+>gWgE{z)D+vJ<Tk9X)D`2^tMU15^3uWWB8~T~Q#mvB=O&%1Yjict
zIPUmU;JMf9H*O@Cfb{pVu3l}mUY#y<sNOF|ZTf|_^L>Y0NEzk5ba1Z~!)v!cp3JtG
zW-aDda+_G|q<ZO7VPMLbq=TWxJz`R8s*PKI<MXqvRdoa34zF5U<7UE^HHFVCao*nb
zcio9q_j=b^*>tYS=sP_==k%>xyZy7agVl7ZOjD0%`yP<43yc}&nXm3?{Bm0S%nA$4
zpSO*F)GFS=@y3ELGj_M_(B3zcXEdbs>(*dy&YxF3S1s<7w4sGOB>D84z~%?j64t%D
z<h}6ORei>}BF(Slwhf<4<#^k8Zr$?>-smiMYIsxj+VQkry=Dg0H>oVXU~J!c?632V
z@pm*<)Jt#G)#WWmB#qmDGR(C6%4chS8u{ef$)Dq*ew*iKl;39MFmi85=fw#lMm%?F
z5&e2j%L|=dy)No|owz<Oc!K$+)ssK0PCuBy@v5n`pIWNz$VkkqS39zDjh+j;)!7u>
zZ1(Bt7ImBX_#ap8{Gi_st`lmB<sKa$HLLH!LE}fBZLoFG$lA+Knhtk1ZuRf9dD~7Z
z$Ef~~=N-PhQ}goXt~LcNJ6L86uky31{w-PA_|I0xS3B`{bX!_(=QkH@7xwJE<V5Eu
z%|>NpSs(es(K5ndXo#6zy9bB&OkBjX7Up98f)cc|*N=R@WYoZ_1I9IPzi4~FIM4ho
z0fAv{=daIKxfDho6KT0O-`6!7ar~Os)UX_zM~{!qsWdz1{p3e;7X(i@?NYhy^PdXy
zUdUD2rBC^?Ytyu@zQ%jo?mRVd-Pn19exKXt?v>wVm28gfJV^cBG8W6tkezyx(|mR9
zmknGk&pKZEFmS&1?X2tJCtJ1H;^z3YX9_tHdW!L0=tu5$$s7H#mQnM&vD+7R&Nv=a
zJ95_Hp$m4k>pK77YQ_`KtjJX!<(GY}ACY<B_969<{!h*NnLbJx{Jg=g)+-!tt2I9J
zB8_KGr1>?hR`1u}P0GKWeXU0o+0NDaPHj6^`DE<AqEd@ydI5Kq?BcqVbi9fltom+#
z|9Z21cQucx*L_t==8Q(K#>OAK*62gXZ)<H1IB}n}wpebQMN_j^=FM||>XuP=pQBfn
zhT5z({_EHO)_rxAZQbg5a-BihwkDNrGkv#oJ|2)<{e`Fg+DbP+_^$l0bnSwXz4Bt?
zOeVf)+hXFz<dfzLxu;h8-0!*V@}u-^cl%H5Q?S$L@wr_6Zd25bcJ1`M{qn1_1}Sab
zsb}f?$GM5IJDlpY?;3q@Q%=9zSI)d2b<nJJ-iAgiXN>!tHnJPXphePt&}pAh`uzUE
z^_tJEZg8~Y@VL0z&s6$UAHFfp@ZnFbG9U1r=Z!SKQI07`yawbhY-Ld1N|u#Uw_CNV
zoAi<no=`iS{qWZos}0CWVj=2p@TN;s64&0Gt=TVNv71ZUjmPz7y=c9;pL0SP?UkQ~
zd9ZC8N}s>I->hp<P3z%~sP+d}?60$+fAr$?IcLUR8T>SP@5biy_UH0Umb8A29z|Ap
zdS*wzw*mKt*RDPK#1NytD+lhW@N&_GSotew{}`T$l8*NiHJ|3%jQrW%*ge#Jyzc6a
z^P<0QTlj`Fzhj->G+Jw!x?;`3LH54}r5su@;rwzP$K^KrEh2o{IzHdR=c=J7$K9Cx
zh?rf6D-V1%qEq*`t7ba5O+RwW?zy!=_PO-%dRsUzz9D_?%aXj0&flunCiD5J`V*f{
zoN#lG=eX7jG+ut(d-++wMwLwN<!0ZKtE{-|v}|I>KFjOwwCVNe{m<8Lg$(en5&ZM&
zdd4G$ts7(ck@GcayqcdI%=>uygy8_2aE-)kE@L-L?k{ublTh}=(p0nZwU@CymP`Bd
zsEpge=l$%P$2RSdl2EzDT+L1YZriEHrSFYCpGHoJ2u}{v)fzqN^@1a&^$+i`>Zr4|
z_xe-rrU%--uFQ4*+M*o4CVQ7#YO-{>mfGRqUiSt*T(IZRjNGQ5mt;;}w_{4c);&DG
zCY9s#-V2|{cTPHRU(F-8zIiW|)~k{h96I8CV|}F^I?oK|9N~8%X*|`(cfwy@U0d(X
z?5#Rap5^Lpd7~XMxlxT#&vv!a>znz2zu#NZ`W??V?Q}KGut$S0AM-N~`8C?1>G;g?
zeV+oG{8{6&f_8DuB3_!G<BZ8~Ob)kIJ8$50tmF08)0^$7m|wH$rN_55$G=G%<xpQH
zdoGP<ku-V3y(#<sKX*!e=y-I@;@<B+9Jh+JJg_3B_3)r~J{<q5IE(U{oU0dc=6u}X
z``yBqW!d!{HS(9ena@|N?@-Twqjg^Q5$CW*(s;K<2DNVDVD#teW3TRcw13_;yxF<<
zDQ%{V-_v_?-IRHG&3Oh>`n*igu}f(xTl8qBZf<;QW5eg!?gP$NH`7@=XKB#q1?}>J
z`CUW0{&Hf6+LeKA%*%E$vOe1L!mTB*-LoR*b*?%lYC?Z`lPPsxao!}&?}@$reLZu}
zyO)k7t*V@wy!LdLDh)q<Ow#KW-?5L)Q~$+W2d2#Yj%{sa*<)Bn9p~jU9$tGp<M$mW
zWJ3~W)jU4+S|k6Beg7+MiMFv6^NY$qJ#@0S>C-+hhUFaSVRvZ3<;eEej&?8@e{jV1
z;Rmm5kjWgRa;)%vVEeN}$o9Yi6Q+IAJKV>l*C2D3yg5zB-5+xCnPu!V+L@8Q=RF<V
z{rvc`0iRD@**hiw*>52S?k7)MIxzK&{=Eq!7ubzpf00S&O(nNs`bL^xpM(0LF)c3-
zd6fTg+T%NQMs@o*YfGmAHunt&Wi065cWDovJ(WH$Cmx&r?0ELrxwr4^*xTHo|K_%N
z&o^y#`80ob1^a*o=0BC;`<wK=yWZ1_4c;8gytLcbWz3u?hguV^WX;iCeR$9-_ilr-
zYfQ-EI-xYbu=h{@`281qU*r0Vzx)*XaO{yUcLwPiR@fVsH)(A2?Mp0ot~B2IPxC+Y
z>TdIPg45~a2llM_(0QS6Bi$YyA3t0lIa>B?3+JXkx^3a@(sA<9B(IlIhxQyEF}D7?
z@3*!4nyU7J;@KJLxeh;$cNz?HgXkK_3fp>VNTgrZn5a)|O5~$Jw0q^pDXd6Q;x~lI
z?M{9U#CF6f#P&q748Fqn#S!@k^ou8QNcH>2@)gfP@R2LE;rHLZd<*G5!vB%-b66>Q
zhCuB0Qu)gh`RJ57K1Ti2>EqPUkA4}KBK$bS$Z8S!_!9RX`-yS+N+Q*#*d~hm_NDvZ
z#r9NTm>xtonei$RJ&2rU$UKWpr?@}<yVEUGOt)My-HKw<$qMf;{qA%F71P-$rW;gj
zI{DvBcUUnUAN$gJ{-T&p)R(zpI?Db{eeu!nr^;{+{eE1UlerM95yufZ?UPL)^6@5{
zL=^j<RR4c7zxj+O=C^<-=I2io^9vw~`2`Zi{FV@l=I5uFAKU1g_3OzXF+U5Um|rhq
zRbp=<+gR3@Sd(Z?6!W9ritgW)aY&Ko$0q$p+gjla68pziVq;<ik-tgt=)GS%;vOP@
zYf{^f9HvEXuYc?(iu-4!`)a@5Pew4FSWhpaSWoX_(<$y(m7Wv%dOH5rrRi1?t1#W_
zV$&(^3H|Q!*oUR*Y>8rdLyJwPxF_?w%Uh?IE|w^kca-Q$1x4>xk)<JfkBUrluZqkJ
zo`^sSa-kcgBC~?SJ{qD$IFgYEz5OaO8~7mjfQl>znb3$<kr}|`po+{5A&5gJG!CiA
zv=6IDZ8yaoVfe2qQX5Vwu`05xqr7*F`5tG!aE()uMIq?~%Y*!+ip(1Jzp2R7<5?au
zppn3`P`n+eEM8}_L&vbQi}s&%4wRGWoT4m5Z-gNQvS`{uu_z~NMGPX^5&aQ^;_XD`
zGp+V%6`2tdkqOmA>WcbIMkxKdGdYIiKW#_K=qz;)`8nzVnn@}$3;06+cNJMW9}vac
znM!2Xzth%KG6%iVcBXiqfdkEdrJbpC_6^m8w5J1Sgdhp3hiI1uo=~POD*G#JOHK^_
zH?>EVd_(2Gy-lj{!PGH)?a5h!SfnBsqRpuv(H34Ji5&ma_VB_SI9?$I*-&?sK1=_l
zJ-q0992XfLi0`$Dmr;f?mF2S!qW!J-`zqhGy;ao4*4OQ86>nQBF@s~BAD@*EIJWWu
z70m}-0k4bN*Ye>6OO?Z?6-4`51^Uz}QTs8+MxtnEOO=x}k+-sV8(SGqIJO~(;hD%o
zMi$3qe{%3VWtn^~WfAoPSSI}?wXqfSLPct4OSG}&pQG|k8(ZElIgTzO-w?iTXUpIf
z2f&Kd7h*Ue5bbR_Gfa=NMu=g^V!A}455tSMyA{pfxc=dCvPkI0l%p|G+Qx$CFXd!u
zusXsq05-qUwie8Ju+|$<NJD8?S_7puP+9|}HBedur8Q7m1En=kS_7puP+9|}HBedu
z|J!PS%M}08{$D$;VVvZ5+TZYxPE#fmITLbqx!yn&xju@zGxXoa9f;f{BFD~oh`c|q
zAaWxVbpiA*R=gJZF&;3#P@>2sC%PD-$hYx?;UZ6s$fXnuk?ZLJME(oWooc~#0f<iI
zr+Ciz8;Bwwn&?gtMJ^bTvnT-~x01-CCUQ=Q?kv-aJY1p^ITiAlK7=UpdWr55QRF2N
zId)PY^8dVp$dw?v{X~&l>on7a6SpCT{s`hO#L^#06nW3$=ug2N9IQufU;KhtJmv?Q
zB!=IFXe%cT*KuD&-oJq~+{T}bE7~hN#&$VgY}=G!Ton{`U$<)`+S`j`{1e5dDXFcS
z;%#kZG5vECbtScbbBg7hDYmQ&^j}oGzC^sD=uaiyQ1ss+-c$4!Z~I0p^C80@Dc<|L
z_H>>w&QryBV!G$_XDeRk5Oa&YSEKsBw!QO;_g*XBFWwGM@ivCUJd3x*BVHG8kLMlJ
z=NDVXf7(7z0rUD)Y<|Vt>v3cK|Ei6iziOAKcpFS5wZBxBAJSFCkLij|nf929x4~4r
z4J0v(TdZ$Un@p<Ax13_$#oK2p-Ud;5-d9tMQ@qWg1olJGmQeAwgGB#dwI5{1vO^($
zBT7dm@*w9J7lK^qa{x3E2SF}JYCs1@Fo!i<k%=g-OXfnx<wHLtBOTe$<vMC0ims`q
zaqTn{xzOO+s1EcX^1j6(oFBNOVNj9lrU-$!=9vZ)eq0Pe1j4w{AQp*8K{i~u|H*+L
z5<Ov3m32Wd!jS@Bj@5}sg=mvA8EMD_NmOONuw#3;LbUB9o{0}f6hvD<8OTNfL|av@
zU<L<>ACyJ=OtDBr3NoO|HqnC(JR#Z;ibEFiAQD%JwuE$H0UJ0sq>M;KCUhH7-zaK>
zCz*a(W0nsySix40<s%JQFwp0j5CkI}iO7dO*T+pD+ON@Q$-Lo!Fo?F!G9cQK6K&HZ
zAq}Ff!8l~20GjPtANU{;zJ?s*kq84L#)m%=jrpyh1M@>D(jeMz3FUV}@mry~3GWG=
zC^y72Ct;?n8)V$iBc7#6g1DhV6Zx>}!u;V6`>t$5q{Fit`#wZ_ESd1>Nx6}N4Cq@h
z41qAPWLmf(8%DiYHat;a!~27HA8v>o%yxq65atCvTk0Cl@EcCKA==>x8^N-X37wy)
zAJ{|Bo(MN2jbgtU&3mwiXzRiiA&7vFQ{nw_qU{OM=7beU!z=Sg46;!G)p4vdED(Z3
zq{3u8<wGc9Tv>0(Cr}<_Lw6$cgdKt>@i&N8Zd5Nc-T51Y4dRgtal?r%{1F0u52l4H
zLZ-4Uq3uN(;fhd1LVFt1!CA!VtP?_EJA=PFh&CJCHuATEB&39~9-CMXSiu$!aDxy0
z;k}vpZ6P8CDHzJ%u{f_9O%&%et%%~B$DSz8k;V|k`N=4vIL{eE6z3ggL~(A@pD4~x
zL_R5TZemLm=Vo<?;v7u0nJncAC5m&N@<eg2H<BpMyGpy#8Yr!S(i$kOf&VvaK$T*R
z{<ri0J9$i=PR{vn)Bn4V_4b(Iq)7b#e`DVN!uAA2+W_uky=YNjGUpRNsx5#HihP<5
z;(G<%VwJ+&yYq<^4LM&KTuD}jkM6=sBG<e(O)NONNx3E+q$$4nPs#yWjhxw@yfvk~
zl)HTfr%<vg4D%rdRTINR8wOfhe!Omsfn_Fh%CDsrNWYt|G>tgb;&fa~%bY0M2_9I+
z&BMvj&4rgNUqfrH4(C|y#n+*t)hcW}LA)<=^xLxH_LQqPuVV|#A<fT#*WMUdW~z%9
zO$pE|6S+l&_KNxt->pO^)|<t!-*J9UeFP8tm-^sLtuXJVDA#wof7FE^Z+=}DqO8U1
zBAC}jbs@?f%4^XUExGS0xJdIaz7}a|iS^g1_s=>K>)l4N-Z6^xwqu;?7=kLSx8`tZ
zy$d%Z!$hvoAHB|hwQhMV&w=$-_L)3oa|pWhWdBs+*|<jC#dsy>@>?LyujFUrl+E>_
z>@%y!x{CEHIrrZ60b;x<&b8LwKC0Pme9W9H&2DYH+p$Ac$FY9~IbB}8xa+aK^Tu+{
zZYIVnImf25Ir_x+Hn|eHJ$Fm>TypNcW)@<8CFjokpUR1;>@#^kI`^5f&tSLb_$gP(
zavt^Q)aj1nS9Tdb-ly@=U$e&>Ec)0W*3|pM!K~d0Myr2(j!0#5KPsE6QQ6#&%0Bz3
zY)(;Sb0#XAQ&icUgv#asRW=9XkIpry>@#Z0=DfP=DfZL+*4cg9jdS|7=S{QJ->S~c
z)APDKzD}L|YwdPbe7v=G&1`;$k&ag-=MwtSxqp<+m8Wd(pDM#dd25Ur_?yj0tD&tQ
zE;_GMurc<-{2I02-MBC@{@A|i6F=0x#yJEZ%5oLAPnU1~k?l~%dcfSpE89=IWEOQ>
zwk)pGtXc*WrZ=6q;|SOIxE4l^mLHZIaA_|wzg>UG#`cs)W>hl?J|kOtq0#(=W@fuC
zjXZdD-G{}WPR<NhJ~yDUx%>_e70Zq7J#BSpm&Pv!d@$=;us62x>S@2|9JAZtVz}(k
z#_04$9hJ}J=P1>4-;RclH(y?U{__a=`mBjoS}U)$Hr&%){qX*VQ^swYb^Hw1sig7l
zAANrAdb87&r@SiXemCG@x1;Uu5AWQ)N56x2HdtBCetwhdN}M0bRZ7k^=q`;{at^_E
z1I7GI276zQ32AmVVNj1VtNN7b*6HJ>@z-*l%x(^M9KJX)dj-!^N#ku;v#ZC=P9fv8
z-j!)@Qt^ELqc^^1y6PB?I(pEj&qd2=hn3GIu52!6Wpnf?n*&eTXTO!rz4xPY)+w92
zP}!V%|5G{UZkmhzs^r{k%I2O@HfLghw4dJUo8jE~ZaaCMwx4Pl&9B*G-Iqx@^_JJq
zIx)wnhqJ2dW#x19DVvK<*<6Un`GO}`S=w<`(%2gBJM{dl)ju+I-qtJAvTt6sXj5O-
za_MUSo1MCGO<X$uX{WkGzAO8>leO*8ck`;P8&)uQWYc|N2J5fAyVdjjM;kTebI~cA
zyHMF2ct1MFm$EtAm3?-;J-@%mRUU^gNj*3EgU9th3%(edTO}qtR$X7UQ^IJqc+*$?
z9j2_~dndma$yIh#uJZQsQ+KDn-E%gq^A6LV;*#&;cK^kwx1CQ}FS#RH*HQLa_ZK!|
ze(FzlJ+GuO_r%Rde{R{}@~-LIT}_Sz+O$aUIX~X8r+zG7mX*z+rEHFMWpiFBo9jc_
z+<?mFyjM1d;E&EdrEJc7WplkLo4ZiyoCj87e<?X9oU*yBl+BHxY;HC^={R0;4h3a%
zE80r)D>;XPvbhlFO7kl@*MhP+82_hoMJbzODM~7D$vL2u&6TWdE~X!yL;pwTyjM1-
z<B!gTsBF%AWpfxQoAb1rbbhe4(r>-SAKr7@q~avM`vKjyoJco2yYl>SlZ~Cnk9bx4
zQ4QsD?U!L(uItT;*xaDe{QlRS2KbCJ7_52iTvWws-dRIiWxiXyyH4T-e&_BW#w$5j
zva-4RmCd30qjT*mo2zkAUs2wYbMpV_9E`fsb=H#G-cYtJ0A+KK{pdCWs%eY*D>-+o
zvN;Kr&3&e9PC{jKohzGba6iBOD3eo9+1z5v=J@~7Im49Afv0Sa(nh+XUh*4xH{Dk5
z?fv$nvm1F?gs(O<7`ElNSq@&m?0O-O{&na9emj$nFIg7nrn>d;a({1OdDv-CdYK0s
zlXK<_e<ois<6WJIQwLYl<`LIm<SHfSyjM0yuClphmCXgKY)&a<a~CR`!%f*7P|CK=
zplnV!Wpk77mG*;Yn|?Q~p<z8^f5NZ}U3xbgcE#h@K2P?wo-^m3llRDLZ@KqP*_?37
z=3M)q%B7}kPO~4~hMclFZI#VIt86Y<W!naME#vQ(-@FyS*-O9W=awUPB*V2CE;=q@
zN;#H{iLH3eEuK=&F}||<@ikktbLwYLG$)GR-+K_b)lkZ@G>yom7Qe;BK1A{RbU)%b
zqBZdnu|M$!k)JC4?i0CW;AhOTZHa@3!-yk@{66hBfyi#@=S3Vv3?_~tJ|Q|0+w$8z
zKlc0WBC-yC=ZXBJ;P;$3h4_}pkN19MRml5GR3*+K+7jmxrxE@5=Sy5b6!$dv6Gc6l
zK=E6?^c%mZCsl@tIuTtE<LMBW5nB+K6U99MD~LtYD}GZKWs!Y7{aVJW&TuY=NV(oZ
zi9>k3o|wk6enc*j|1^(?$m<j4!2O#@K{iA#kybE=E&eWtNZ3v8$3*dbN+Oq%eh$;3
zD5p~K{7C)`j|AJ{hvh-~I?vI+ljA6Y^+`r)o+Iwzwcx&H=vs1bF2udrz6e7c(jk(q
z>A?!h<S_c*mcPi3gMu%@5swV0b1%99tl<rDk9r)kpvi&I1mYfbKg1vnvXR_d4m)@v
z49UoYCI@OW*dn70uQ?tT<?|`ZWfaM<Z0PZ~?ts6_ZB&%&hZH-quk-x`R%Cf|xv!mr
zs);Jc1Q_{o4>|Gcd_P6Gep2`wH{tuQ$oZ2BUk-*v`F=8ZPvrdZ=l$Y2e~Rb&5qW;p
zxfU<-{Mf>p1F!5Q)6lOMz;cN;#5ke@F_~BZU3HFMFheTC?TI4iPXywT3DrfEhgdw{
zj~&Ykslc%bu_(&-BXa$GFV9c$96#DA<c5PaO1sh;D6N6g8Yr!S(i$kOfgf7~oW}gi
z^Zy4p=TYTeNO2GKL|vXi#%C0DUqnCm9hX5_sNkd~&uC*S?_DCM;0mszsN2SSJz*)P
zS9B5d??7$?as{BM+r_X6TAVi!_h2Sw!54EeAO2X3B@kT{aUTvK8iyddC#=I$tl;%3
ztijK`4#GP6*F$vKynca~5S_R;UX`+yLwSh%d(?>HK6-VcxQDy~u_6)}W{pVJc@O%~
zzY&`tx&cISAJH(3z);2+hT$mc#Bd9ILSwwfTZm4d*c{^7zqV)((S0G7Wge<1ub5Xa
zhFQ|zNAX%b-&X<Juw^~e3|W5^b;B5D2LrT63$%pj42j0*h)#-OBZyPrrFcD(Xpd1C
z4M#X*56ioa2Po>I=r`lNt`OaL;si`myskuDYM?UOq8$uj3=^25GrFJ~M16M`{luO`
z3-p2&`obCmFc6}vLaYi+)J7fDg)Zu$J{mxdhS<q`8xijl8x!@=1WnNl&CwFAAv!H$
zHO!+t3lM-nEX8uHL<rU*6dNF((GDYSMmR)Qe7fq)Pa8E*6SW|oQxKil7b~zW#WN+H
z>XXY_hj~MEl^7<TtuSSHWukaqp)>sxYSDgGORoLEhWUtRw<{or-#^~KpZ7(5PU3wx
zMDTa;jN#8A?k~|~T#@%elX+>ODz7V}BFdu*G_Z*Ih-C0$oY^(mPw9WjJi0RPFT^~E
z`aKHqo8A>(mt|ZP`iti(5M?PTUx70D35w@(D4wgJcy5B?`3TBT#**@C{8#d5l$1B4
zc+P~s%X9H{?uz31DvIaMD4wgLc%F*?G%rQ*JQT%qHn>&)>zowDb2uzzyda1!n7Cfi
zFOGlW*d>k;;`k||$n_wOv*Oq#jw{OMeb8Xu;?KYV(a_{GO+2^c3{UtX5F!UeH1Z*G
zKm;NL;o?J)@9Z|>yS@1Cj#TLL-P{uqh(RK<5y^Mt6vcPt;`ts7_&)3ne-wRRj-fvh
zsqo`_u*h#KzV~Jz8wK#C0C7l08swEZKEoU~u!qP4p<0Dw9PHtW5Tqj;`B1IOv@n7h
z?BEQMGa?9)NJKu&sbg!1=gM6X3(=^9CUoI|a701m=yB!zAQGv_L@wlPOOabb<dld+
zDl(A=RsO!U;m0<OMH12=azuF6Vcv*F9P(hoamNa_aE2#BAU<b3A&!;eb3P8@crK3F
zzK8%1VoAp*Ine+{oLdAURGeeTnFnH!h!kX?02&S1Zy<70gd!S6xhYyTVx5o(&Bn|I
zA~!{T6Jk^97glgaB4}DimX0i_He-Ak!5r3bg*So`hDanL12*~`dl3k$=DdekBq9UW
zEvRQW!xKS>L>xq3Ba!za7X{Ga7_J8cSi=<}|3v{r4vb9Lv}XIl4S~o)9(VvwrU4xo
z!3NIoLl7bngA{nTWw{VJnsQM9bpw_S6WGENafZ}~5&Ht<Fo6|Z5rI@>q5vAkOb-)S
z!5-f5M+oAOicI7~qXU1VFoG5A;D-=IA{OZo`8mYzx9T04H>}|bKZGC}DG)zsXu=$x
z@J9%ekd7?mqg5y70eko%6Go=gDLfI>nZIS^L*0z+h&;%<uw9_qmGNPL7-S+3R^7-A
zfk3F6Q~z*49`w314SW!ZSP^@$UdV=CPwE{02tg{;Etm!tuz|RjH4*txx1t<yKrq5#
z)|dK*KjNU@k9`Eb(6MG*1S1^D11XOU<$=g45`h$CAapSO$bk1S_ID&B9sa|qZ^XmX
zj`AZBHcq^U5TrPB402)pVCBm45d`On%nMP-fc7NHjchlfJ7q=iWVREuJs5`ksccU#
z<_`^TwmW<fja=wXV>z%#2qF+Qo%)$UnIZRKS~wsY8OTKe)Mv6B$k7TWuz(Hh;R<i~
zAqc*+sH@pT#32phJBT=+dqWiGZ|{iW+^w`Lt%3g&HK58&|NZCxi=GkxHUR(+S5NZ#
zzxet8|MXdZ@vMA(KI6>!oK%sG8RIBY35Y_E@pc@`<Md5=pF@YtlX3p#eJ`H(pWr>g
z(QU#k7mjP?W!75zwE147c-CCIY~fbsa3&MmhC`n8y(`#UY6DEMpnuLnS|-Ob@$9)t
z;iO;xFFh|Wp4}JcyyEw)F^myXI6o<0fSlK2T?dw#Ap826{b0rVwBmhraC#y$qD=Dc
z#n(p^yl@@#dH*}zKc3k);LYlsvkfdW##&5NMb=5Hd*Qrf3Dx-yNR9MR)P=~uCc4oO
z%N~ItjN|Yx%bqs*+uBg3J_>UnY}1m~Wz0B_sqUm;ka8S|?*Jw&dmzhmRjixHt03of
z@p=;LzV)khFUtKO?gJ3r*Y%e1)w&nf+`nIUWqK604OdimMavi8RYa!)(Mz>S*Ma1P
z;}`C#ES%I2>^&tfUu>76dHXBoE#@hDt3X_1GFQxd+GJ5Gv53OCi+%I&_6srZJm!&6
zhyA@L`_})W`~z0vJg_vcfZ<TD46}f_wu7cduQ`*%cbwUr&&pLcPCha3*TZd}Jey?p
z#KX7gi;!^(boCrRPVt;|>OqK`nmy-A7Gk`T+xq>V$}7-}zYDp_s#iLn{G9K68QJ$l
zRZEYvLF=ae=Cp25*9A@^;;*gUp<lrDI!iI$n${QU2fl08f8et{$E`YPxmTXMWXcfh
zL31`Ozty6b>bxD?3nrDf$(67z>sPHbe)8&Y(2QE4ck;^YpDVLjw#9U~(d~7{JCAV9
zjPDh4l_29yt-t)--`1n+rK_JqobE>~==bGp(z*H<SLEcjnY+KCOjepN;7p`fQiqQl
z12zq9@_vq0+UBd<K05K8MXG0yWxMaVZXMWr?t)6?DqOAm%JSHpCMFsEm#Nk7yST@g
zc00*W%lA9EO0(br!4*ur!>UDGdD8vBb?4ekhHvYwmvHx*+ckqmdiS{ou&uKg@1yDd
zm+kwFl3l7e@sC<%(@!VdbNREP=J`D_hLhG^+n2YRuiVmpP;#5L%H|8GIz=qEX5)m<
z%X4;hjG5_o>|D%GF)eR|?nzG4*fc9TrH0q?`d|Lv$rm8*rTUT2_ivEqH^XY^`pyR{
zhlE~UwjpePYwf8Y^%r&YyP+MBb^F{;ttLA2J=0h$H}qjg`G@Qk_tMn&hP={>H5^rG
z+owjocI?}0y0=xvP?cNCKaa2M^Yizm^($Dod(PdhyB{u`Rq<H$22G}E&dPq#>h6PT
zQAhJX?AXzX@0H3vXJ7if`^AxZ*^ll7bTJS7<3df{L-SfCYA@mXiJ{oOk!EeTRC}_!
z((YS{&W~gtXKQq<9rx}?)e4I{1Wv7c>=J+HrO&%Zw`=|4-AQ9jd(HVK1@AnkS{e6#
zTlyUPm)k3<Z!fn)J!Hl2QLE-3Yci?H{N_EkkYlx%*sm^kcPWVPxol_~x7G_)H~&(p
zj$ht|xwDfz?<{HlbY1rD=X~esB*x3}Fx0tlV^j3DN*`Z1<f>Jkyz!uA70Z)<%sjR$
z_;EdBj`hY|E9ANTPj!5f4USwh3w-#l&Vwjt*Gm}=UW0R%RhYD+<H-KzeE<5<&$0jL
z=hI7{JNFJAINZyob)zjljR!=U9&Z}>E^9x(^GfF%V|B|8j*M(K-*{Ex?$J7?ZDu_h
z{qe-?C25Ne%n6)Q(BFprs)yJQ8q_zrJZo=GkK?aZPUch!yVt2vPnomDiK{Pq4|6xR
z?UBzt9@74@`?C5;f3>Y^HM{Fw-}k^^xqLwHYfV~SY;m>n|Ht0>z~yxIfBa4%|I0!w
z+{pY{2q6g}7D5P_tkNGv|I{5J-2OLfgwP1hLWqTCAzQX=jaa4`V_VM_V$HBvCi8oL
z&wbyt&GS5a_U!fi``zc&yU)4Lxz2U2>wB(qopY}1T;J26Rj(y|r_guXNaDNrZK3}y
z+rDR8mvv8U?00rwld%)`9yQroZ=uiOYFF<yDWNS@xzBmD>E_BSZ|`1s<HwCH_S9c{
z%zmax>AXJLo&9Z-N2aW^@l&ac<IdX@+<Y<X#}|KoW=P1vH-|lV>B^!oo_Rc7#LmWX
z=XJmOsE$vwjWeF_^2p;Y%BXSNxtG(rNfTeul(!x>Dy{qYhnl6&efm7_UAaklaXt3z
zTh`a?kJKq1Tt4iD9?Q0v|M=;!Z0`<>B4?R5tbC-U-$4l%6L9n1<VWV;KjULR*6P~E
z)Kl>*X75tX^NeXT@S}MzrBeR>SH_*68Y*@fJ?}zJuZHJ0Y&==;ZT6Wrv-;RgYEt{B
zzF+ixwQY;Jc~d#pjN`=TJQ_G@z}yZ?8*PrdGko3fuU|gkLt~tAoOoc~xb|Oe`?T4J
z*e@dY7Vf*kt5P4)7EfEfah&*+1*1QjKlF>UAF1ki9NDp-#(Cp7apO4gkW%`wmHX4o
zF=qD`j%YqNZfA$A<^$Fgmdt8>drI#9bFJ?uy}RDyP1@J~SH_7O$A5>7Y|~-ocbm*>
zd_VNN&~<w^mtCv3i1)db_UE1t&5rci{jrOCcIQWj-&p4GR<+k6YHl=XweQC0)pyHn
zAMn0MW2sLY&3u?u|3KTX?mE1DsmrIG2Yh(c_V(3QCA+-s77UAOoRmVpo4bU&?H-mA
ze^pcI?q}iL?L?&K+YJw7>|A}b<CM~u2Ke;e*@E|Im2mxA&cFH7Cy{HG56$1$QJqxq
z{txjT_Fp)@;ocd|;v1jHSp45R{`=4NuYHGpE??01=c=Ti*P}Z9XQ(I0L^qh$41E@D
zi8e>MeN!>7l|D%|Iu>n%@+hUUMLDJDb5>~sQTk|=@znOr>-%Yyen{DmsV+SKX)7Qc
zRX6>5Dy{VE_R??1<D;RERq1<`?P{{j6=dqD-;Uc)ZCifR1+IMo?Tn5?=^mEP2C2HD
z(r4QZm3&Kj^!=YtO%GLvk{%u*mGn64x08NteZQsBpDF1P`$*raOgtWF<+lqecH}lz
z87Iyo@Z<gJ`zDos&|lkOFyUl-nqsulmq}i<Iqc(qc|5sc9C=}_>Z*Xk>MFx{axL?z
zP{_MZOR$B_Y|a&M2YG)f4pJZoil7p#=3pyuhe$|-3@CsyFrUl2UKFk}s04XY!8o2=
zrOKs%mV(tF-nD~JNP%3q43%Kx$~y3dI7opUxD1tGL*aD>Z-|2w$brjX98b<Wf>dVl
zkOBEn0`mPcc^BrtaXfkMaq`6ZRCPRgG0P(7@m}bBt|1+Ge{uouub6S(YI#Qytwhro
z@}45|hOy)_hCK5<&SBIrhFr#vKW*%|<NL(TIvGDMW5@rI@#4j7TeOt-jkwU{!e1LJ
z{zu1&=TleRg1ToJFAg3M3dYH30iy+s7BE`CXaS=Ij219j;OQ2q#^Ohh^y@6RPnKC!
z#`-SiJ%MTsb?;m+V_x2smhVP~!6K-^x|&c6YJ*`~&bo~t(+o5QX6t{;cJiHRd0)99
zamu^khN(LZ2l8&YVf?eaQ~WaPWsLv-%9!9^j{}x51dZrZXbgtw|NB^ADKj$mSIWxo
z9rG*gSk~YSZr}x4NPr?}&-0!G1cL^Wp#Ws;uQ?~dEpRpE`3ZcX3><h~as?0YhEOo)
zImiVxumlnz6|$iSN<bRRY(NWD#|5{iaVi+(StkvAYqLG%KmnxIAv_d=M_smuL?{8P
zdbIOF8k9jLB+^)w3x#0SfV6_ADCbQq#6vFJ0yXEZJw!qp6hbkSfdjVog(OG=8Jk-P
zcC^hpg9eJhwh3Xu6^fxf2KRzskg>U?Abv9(Xs`^0WJm{J+GUd=9h_V9{0d2s2JUT0
zE5w7NEo~T(0M?ur?%)l{_SgW*!NP(4gD2SaBrec^jPI1Oon?^ah(aZJIq{qem!S-D
z`*93uFti5wj=H@I#}i^98%m%YWPGJJgo0)u_JU$49mKY-<Q?Q&>*<gUc~A(_E>jBS
zpc>2=KB$DUAt*S%K$@UB$3(`mR70h%RfE)h;`>ADJzKrD(k~}A<7Bje(E>&b7%gD5
zfYAa*3m7e6w7@@Y0W)HFQDwqY0Qb^P-VxE>5mTml`-KJcbO?$H^bQLNpU%hW14F$T
z-yZE9!+-DSD1UFi$Vi#h4e|Z$=zo9B?8rc6^uLqJ+0w+9dt-Xuo2g17%^&NC5dWx%
z=!hVVy8W0A>QRxJkg$+BA>mWigCfErLqY?i_%6GxrH{`{e;+@MCMsk~jE14gjae2P
z7#bNERduP1qqnv6(}c1Q*@m>~K3ne-<`?caH83nNT%!vUtqD;5vt$1aWA+W>q4Ri#
zl&KGhJ$VFCW!rO4&%+(7e0(Amd-w#!g!{AV?~c`P##r<AgcIL|qfB%*#%q9ls$Th4
zy&4rCY<$C>+~~&48`7e##sVgJ9+rtmP$eyqkJB>i7m1Ov*-F6Q{!_;68^>lFzxi$)
zo6Wgw9GiXkM4Ojv-Rpi(`{cO{)g@{&<G0-39O!jm(Z}iC&K>S)KXw1aHzw>qyAeO1
zv@xko&A)iGv`l;Z`9{ILj-DB{K1us?>Ng$DKmRiB__Q;p%-5X7$3dioTU_pb_O*eH
zZ*1G~rLX_gZ{8_S9kHs`fuhfBcdT4}{g@rEGW@T6%U#|}GLFqQj?FfHi`?YGvvXqa
zcprY@hx1o&%;<P<e3soxmFhDWIY0jO-y&~GyR_Q$(7uKN6TWhL)IDM5a=+W%u0>V!
zSbwdlNoG;U(8E@n#<|mvN4vG!G;X0|R=;Y?ZHpgT_4zu*<;zLqJ>Dp;h#nu*an_~1
z)>G*RG=5{;I5zt@4?@Oof*Z$XOW&jMo8X@hd~xxj>lb=|=`ict8n+j=-&kX5KIey0
z-y6RP9u!%zb!mJ`mxZrYn4U?YpR|WuXS~)-toP2Yu*4?Q&*w}{a$k3U{>rI4ntZe6
z;)B?NhdoN@|2BRT{GeO+L&F^&ZtT4-F6gsyweFqEz8^(@IWIw|O$XO}cWA0vue!xe
zrWR~HSGn}eH(h3*j!(=C{dCW()epPUK=kkWCb)5I_MyDjV`grDZ>MS6+<T>4t54nV
zqILz}Oc*A|&G-%Pxfgq-G@X_BO`8k7W=FowxVPbAmlWTeqUB4zzkcT1!U@K)*~dA5
zjo<K|>3!4bFY~?`_I%5a&Tg0(-RjQS5}r|v-|(K7;oBtSZ0S6kwFgJv4(mU<tdVhS
zcFRW(DvA$iTW`1UyW#ia&`OVrIYFffJNxo37tgk8)8p1&e6(TNl^r&>ay#|t{%u*<
z$Pb=zwq8H)m4u%cbuCZin?g#sYu?^p*}6o2app+=ntDYA>)-ENztzJB`L;uHdkyut
zzGOM?jPahE+H{D!+u(uYi<<?kob}DQyR$ypeoQs?_?*T^qt3NnvT0Z}ojFH(OE~jm
zDIL78Kl=Qn^|*%H4q9hLw##faA#07rK>P3WTRjlJk;ZRxZ;shKY1EshKc1f!>)UBt
z#u|qMBg*-{6up*e(>_0(@?1RVg%!v8Tx&PExYYg7U;GBA*^f(d_Uiie!QIoA@eLW?
zW#o7q9^d1~+nR@Ay}M42+B&5E+to6U)!j2()%0P0Esw6p=km=hOzj5xemkW<&x7{Y
z8Z6_MN|~&9EmQjV8l${+sp2(AWsG)Hv@^e(q0;}yYmkq}9_#zwls-9$&y@AHAX5Xv
ziSn4FmA*Q%BtvljUyMCAj5#)rHKu&gXAlfYAOqUHK?`Y+4;C)E_f&(?B*=v_u;%?#
z7m)W<6Co3d!Gd>HT_6CGz&O^Ju?-`zB@~0%Na}rXgJ94?GGszN6hkH0jN-jqaEDMx
zge)k6GBEcb9&m&IwXw!B&iK#zc6HV7RvX3}|D)fm{=MI;PUB_&Kl;t;KROOM=}dK1
zCKN&$n15VdWeY9?tE-$*<7Bje(E>&b7%gD5fYAa*3m7e6w1Ck9MhpDAEl`aFR2~0s
zWuj7@p)sluq)|%VWADuvUc)l^E#G3l!n)UO_-;4)DHx`0EE@!a!7!yUza4f$2n}56
z=x&$|b07}p!$MdB%R$Ec%anocg*QRI_j>?jl6T{eGcVr*mhZst2KjFECfE!zjYQ>p
zCgWiuj3dl=m;i=JmdkkQhah8b@4#J<sXf{O?4S#D1DPJ7)ri9kYUtw{!m`2457qx3
z#%~$NE8nj6Bpu`7I`ga0HLwm|=63>YVE#3bsf^!V%-cgZ=m^h)Ox@8Q&<lF&mrX=x
zK(zk%B-9%w!%N@?0kE5RKZmcuFl8|B%({Lc(^NDBrt5#p7=!;-zY96`D%COgkulak
zfnloZbK)J=|Jome(H8@4T-fXHeV6@@ev@6zfxzr4x>6J$4FM=ab5w~?2x{sdEfhi}
z)TM&*gme%e4Yo9%JAn9V2!&W!0*N5sXfJ_sFr$&)3T#3AI26+aV@pH61Gs=Yc*A8H
z-3@I;j`XR9f_$T0eAN}gWw66ng9esBA{2oY{u<O^50}9PpABx{1p$x*1yBJtby){q
z5Dc*p59PeWVppGY5DedOmv5<CVSih&2l2O(0pc?yA1;7=Q{9}72>G76H-thQBtSBx
zfeU>e@sJGS)1d;)>9h!d1So|HFsB2<8f@_45D8i+1qV7bQXm7eAs<Sh9Hf)OT{=1-
z84AFR4i76(Lk5T+2y^NWIlqeO53_1Xp1>ZGpad+`ga_wVq#x2D8#JwTz99<HV#sPk
zcqoSeTegQZsDSouxgJ3_hyz>;NP{9Mf%fgNJIMFez1ov^NP!|S>p(ui6_$W}W4#2*
zL7d#Wbs{a04%v_o7oZaCJLA^^BB3q?+7;v*=K+uc=3TK7ctZuabR#TiA)^QJ_av<#
z-yUBA^3CyFh;?Kha>3IXyFdoyKmdJ}iI55&`o4lR)P5-IKm(b>NFUT4PTohde+UIv
z58{FZ$c1t+8_lsBgO26+K%^&mgmN$&M_#=+J`;%_%E0YKYzT=^2$fKG62}iTumlpk
zDL+sF;yl<MTp$s0p%5-ZDU^eJjJ7UVgDu#DGq`~#_=1NoarmK-2pM2z!7;JN&Uz&#
z<7Bje(E>&b7%gD5fYAcK(*kCMd+864|M!mwpBacBfY>mN_ze(`0gCGYZw8r1giTRA
z0H{>|i9P^yz6HcjK-iRMybFX+#fKrj115xo2Sm(@=9}iWmO~<9!UOy?Arav^-vI*#
z4*fe}+%5NV?>$EU{d(~&Clj}+%J&_(eO0;Ab`r^h0;_ax3jF>2g98J67|HJw91*Q?
za?&ku4hh%vb8?#L7a9}j6A`8O43M~fJE>jvv#=pP1I*FB#6QYJ6C4sPx9OJRN>J6`
zQkMCJYVhPhc4h{$Ovd#ad<NJ_Az*s3y7H|F)oAo*?o(6s>C_!eJP;@mgeqyt)NS(X
z|BBB5*>5gu?zfQrMg?kOqQZTYoaoY&&$`Xe$hv^QXibQuNlZ+<mX?L+Yf5^ntn=~b
zNNAKiUSPenn~XA<<sa-PJ|ZkFi&++GBg=ID5E`>Am}T+|V(_29Pu|%wwUlQ{8&le?
z_+59XavWH0Y3asq4U97J85|oKCCOE6WY{KvZC+u$*)ZKUvfo&KueX+MqBVY+KqVgc
z$MHl3M#qFol)s24nRtp=_T2C%`}Tai&C~a7&GE@4-Cf;v+lYO+HP@#%ATY>}9r?sW
z2L|ZMfeY(&$2>Y@4hLKEkivfDdANXef6>Py`S#`a)AB9lqrR%Q<#v78ejF27)=giw
z>rzH!+6_ELs<z3G?%bn~Qqt(7FEgRCSbR*x%gk@5$K@rFbx$i3V&`PmRXygC?o^ij
z`uK`n>{+hM&o9fJ#N)y`YvugVm6Q4`b6}ayR)N3BU!^{Oa*Qcjsz|6t{_H(|k-umk
za`=1m_t(w`$=}oRF6Tok>;BgHkk0yF+a{A`zqZZO@-N4;v;KJI)?g#1b-<xky$WXJ
zw@{Z~-Qi@}@6GGe^7FJ~`DYw6LmrZ9l0c>?kYhFtYLJJ-(aJH?7s=?~orizL@%n4W
zrJS@EQhx;w;u+lZyY}h30?S`|(8Qs`7ujzt?o)g;p=tV@gX0$M?AmYP{<Vd?^FBbr
zIX-&j@H=roZJzCCci@G}N4?^1q;;MURJe4mHYVLBCiyZxRh9T!HEjO&M~*e_&OJA<
zzG}zX_WoV^)PL9`Y*n3(?QEA`TCr25I!POY+BEo+C9kUXb#LG0Kwx}>g+X`Ty6k&;
z&U2RnZ9TSUjc~n5L3yO?cSG~0HHY**)$^I*Sv6;#>as9y?5V=ZnpegQSv8?)x1$BL
zOC0GZ@hv~@U;Ev8dEd>By_0t-qulyl&VBd8L%yDMD#~M4ouYx{+09wP{dqoDKBetL
zZ8{^M$@<R^TlAlrHScV@i<`da)w6-$l%Ep(KVG}M-;q5Frf{uO>|#1@&Lh+FE%)T4
z<!|3-yX$*D_g44AmkyiiwCvoVFsH?bRH|J{eivKU44U;|+su-r@7~|I`*_P^n?A7F
zc5eEiS1uQP;#+oo7T;iUmHoDEzB%exhSkW>jU7&>*I9L7`;X^ykFR*=_KRyLf7q%+
z-7@Nw5faXM`K6WLUjF)7%N;qjTtEHlO8wKXoHXy#e^Q`lyA})Td`R1!3+--d(~?-f
znH`6Z-WHs);<ec;n#~XH{=e#*rCUSEZ)w2fEAPGEYwGI06Q;(tIsA6nRQqKQT4p<G
z?(Z+%b=+YscD9gkYi?UV)COF7G-=qe27@C$NZ1hduK$M7{TBI8%ssb$d;3b2s?J~u
zx31Hv7V-DmjTm)f_ffarmSOegub45`ee}G|D=&5&VzywrN;N_`Zf(z|Y<+Fb>K@l_
zA556lB>7Ug$-en2k5{)kO>p>pLysMlgB{BGk<epvr$;Z3@Qmnp=98b3{J%<DH2l#A
z`5(48z3S$z&hz)RQmJMt@l{y(eloxLCf}ffTSM>L)wy5o;(`k!ro2-bXWDwR|CM9!
zt5mI&a{s~)8#*?${APPbxBaX3HCr?ybNS_YC#IYobG=~CrVb1C-J%^(iLZ0#cB3c#
zJjAxg-PY>XSKhq5WP5{J{g?0kdS3RMCvT|j-sWCGDOV})oLX7q>a^J%KiKctb-))_
zeT_a`lyZ<!@&34Qjnnm^-;KZd&-rlK6Dj5D`wv^qNiMJn-O%f&htuu612&e}oW4J6
z?%pq+>lU+U^<NGeeYot%JU-8}fBf~kbMkhcuJ``%*N%LA<-1k*iC2!tEVps5_1Rx9
zDf#19H>T|CWEJ(G{jy%#^HxhsKmYJWyJ-Pj!)Y^Dn<jtLOMSm=)t48{_axo6%<ew9
z&bEiGhiu=w$7zpU@i^0q^bafH)LUjhJbJL!3{Cxs2R`o<y6o$?`kM=%znPNLDmvnr
z?Q?q>%fo$v+H_IpFE?MEHrLU)FyoBbnI<M>ZY7&Lj5)lx_2#bi7Pc{Mpi+IMq_1-E
zu6bX)zU!OCb7~)Xre)ihKkmaNkaxz_rW@Do9Qax9q#(<CCfyuspRBm@L)?je*4-x`
z-XA;k^xzoEi}YJF26~yp^4y)4Cu{%E@Z$$1k3QJ3V`_~y-iKd*Y3;@H>+eKTXGkBt
z+VqxlpNy^{ldQ&`ur<GK^ZmDD4lOM@ZC35jqXz@dY+nC-C+_R$4^W$~-1p<rrc3WG
zDYf_XA3DgPa@_7u!;-ITi5}9<xh$ii8SVLN6}x<qRgspp^I*MEw<q=<aCgmY-_V(d
zE_!|IZeRA{<<#a|xz9>e>X*M?uNi&4nEXfidg-c^KgThekF%26eQ<pAz!PhRn)L7e
zVDr>-xBQ(yo8UKLd0rXk<-f}(%u*$N7l#!G^!cKzx>=WpO&k_B9=PGr^qb9BwkSO|
z&tYJIS@6evKlTMF&#&}alRu@=k39$dY&jymXu<1eW6D1J#I<t^)$^~cUGiD){`C6|
zk#JT;f$8_E-RbS_Iqu$qh8xCLj+yk_-W2=S&fU8>=;Q+r%JU%Q{&b0UiPh(K7S8l(
z;j?`1xr|xWimVsEx^<hTdW#b~VmB>4MjHtajB3-};my>I-plKME9}wdtDbqI`gZfA
zRUc)nS$L%F^tKB-4BE>5uCm{c2Lx8;4tjN5=g>}z&9=N%r<u0=)cm>mk(X9<xW1um
z*SGX<^_KW<Ms&A6b$)Z^wmJ{KGy0A(`i|+bCU2L~cZ|_@%&4Ac4;X#N3@W70-$m-l
zgyU9auTA=P#pF>9Mh120w(O0iM&B`FmzaQ?_a;9w|Na>t`>|HnHm076Uom@^YMy6I
zn}HwAdnuJRi)S1q+{lu~2R<1&_~R4jyssF2$8_39e+2K!s7-fnjeNsy`PL67ED5EL
zXUW1b2gi<U?)H7n@l70CB_zJdbA<_QFtlIIN!!x0^}-RK`j3pAY(K{0+=m&p8){0&
z*_GT|zN=Z@DV6F(9|`CGL7Vh;x2wH7+GOMF_uh8hTeSFe(08`6)vouMoHK3CSF~*m
zQudpCsN;zT16QxNX<Byo_<^efvU=S&Q+wXt9)9d$y>Dlfz0S9`lyHlV6~rFf)2Ls^
z0XsW7`l_GpzWY!~n0iLi$y;lmE1%ne`?dPCv8heB=A6IzYS5YQwXwGw8-2{UELN%R
zDfT;1=XjeLmbF&YkDRymXqf6{%VkC%Gg4lTPn`Izf5*%_^PWG|Cph|a`{-kz1|^2L
zY+f6Ff9>V{MjtadW}0J0A2X>uqkON_Yt65pZu!Ihk~6#F0)31=X4+p>sV*w*Dn~1v
zdVg}E`#__QnZ29KuGL$lQr%YC$9q0BJJM_S$1d*KogW>3W0}KS)n1FJxzVK6z8j-g
z-z~R&z`MP49;;0o&3u?u|3KTX?mE1DsmrIG2Yh(c_V(3QCA+-s77UAOoRos^S$7F{
z+dV8L{;H<Z-Os|g+lffew;LYF*tz;<$0?;R4e;r`llKj_DB=3IoPYDDPa@YWADX|h
zqdKYJ{U72x?7wh)!@V<_#Wy|?e?JaN`mQhey2iqXeXlwHWmx9F&c_V5vW9m+ly^fa
zs_{KImPuc<Omx3#YoYY*YNc;|H`)@-K--`+Un;(3<XeXNcQllDH&ThDBkR3cE>l~=
zHAmZ_H0#MaEzKON=TS_cqFGQo7PUuTLc5}&C{3u^zQoZJ9ffl1s0~0dnKlL`4((=?
z<`r!^IsiR{(uJlyhSFrJm2YCu1fu-_<<>;|JxbG#wgGt^gSJ4&p$_N-bT~@$qjnZb
zTC~ehU-U&&#;~CBu0PGd+F9sSbSXL=O+ZPrb~PG-zJ^Ak;<sWB`V$(5%DWHq(T=E=
zzX9lCv>rBFhW12XmgVRx=qPk0D(}LqLGNG}FVMf=puG1W_BLmk*ixoU!pZU4kG4l?
z#?@k5RTdhC9z`|iF*E_qMYo~HQHdWr8{RKa#WFAPlT4Kz$h3)YHYlfq;%jI#N?ui4
zP(%9k{q;&e{;$(lKsf2!KaEPcpczfu7A-_2Z)Z^-^c+eTrs_QUD*72}NT0qhUFl>0
zb^3M?PSPjkSMo3AcN)426`vn=lX<5bG>{0HPzdE<#X)xfPY8u2kOJ9I1Z7}G;%q?P
z5tsMFy+H#BkOnzW1Z806OML;(;0cis4+WHm6f_G8p$yC^V0Iwyn0rDn#6t!YKsi`V
zA$^d7F)|?^%E0;pV+MkF*ZwBkLKa~hS@sLxMl4T<B`VTCn|Qz-f*}r4AP0(|609h=
zcHj<?kO&!20A*l4mv`uUF%Oks;mH2M3nC#Nk|7;(pa|r9nC897BY1-b(nt?wLRH9o
z1z0;_F9?7H$bu5E=)-adfOyD+3t;9<I>9hbA(i<&D1*9v*#?3k9x~;3KYoMJ#}ViL
zFvhk(1y~Q~xIh5JLmK2l8CbbfUcd|DAPw@N3@k=)E`SGwLIN0l98vD8VIQ#NT=#`I
zZ_Y8uh9bBH7LzHDbFn%6Sw4;mImiDDKS!Q5Irmp_Vt!AZ!MyEK&L7kR%|U(90<;ng
zW7nLy5EZf98x8)Fa|}%b8OK%vW?baTQ8j80v4ruWLi(frjy&;cln9xS4<%3u#>r>_
zqXqtZEI>8+i}C+^O?Yq8hVk(5GZ>~vGT)qbP^bo`@Q%e3KL7^*0RM<TfLkqjP6WgB
zXZr`ZPWpb&c>C`N_dUoY@6DQ#x9U&><o$}8sJvfpj=sn5T4-(fZ}UI!pW;`b4z{Zc
z^`HxMh3?P;#J7YK^Z^;m&>zIV!vL8_2ca^CVhFgwFmQ*FFbZU<k2U}cXbR2XS+IfT
z&;nY58d|{);%$w7g|<O$p)EWI?VtlZ51l|JOSB;@piC@+r4SFVz)DyRNw6N0VIyP`
zcM7@%QbDGw+dV^kR?r9<Llcm9)n$^h_pqC8Oh(rhx^Wfqezm+8zSded20_A!edIlT
zlkU2A)w>h6I`i@lbPwhq5r@2^-;H?*Ys$R5<L$t2Gx|4bK}Zws5BPo4N~QV%mhk%q
z`Yp(pA}t6bejzLfV+jrTT@PwQ4X6)wVHw-0Pzf`ahvI6?e@`5bpd7^Jhb65nKg;iG
zgfnISzro)`1Jc_N4AbB8F=6yCp|jE}&+vQ#GW{O^5>n6pqdq3wh&vf7z?tiqJ9vS#
zT}471BttQ%x$s3o9K=H@IP$C@<9sxb0~R#CctHZBKn4^+BKO_dPy*#3jX-t58sz?4
zd`QGW0;E6&<Unw3<{=02p$JMKpf307kOjG5UXQq-Jvf3Zct9CA)aN&NKpf;j5fnoi
zm^YxF16yzbcL)XzBtixhgZQ>_0P%g}0jW?56(D|X+#nv3APqbkvOVNL0bBrcj;9NR
zf*e!vQBeSwp$sY^m~%Q6G9ecV!K)c@gZPd}gUcX(BkaK$+`$XtARaD58MsmJL_z^v
zhBBxG26U)AApi=%ntKXqFinIM$bfvf0OEJTUQJktgG?xe3NUNMHgFlrpaSx2Q7~^y
zc?5e%gcL}JEGUFB5dRZ(!5SRE1-u~`G>`}xVAGD{3Z7uqo^`MU5+MVuJ8=BK9-P4o
zG!PF-kP11F58|)l7F2?DNA?RDkPju0`8@lxqn!pE!4t9|7Yg74lz=n_+kic|gBOVJ
z3oWF8OK0{AnUDkdPz1NYtP95voFTp&_JCq21M}{r3mm}}Jir^0As;S436z6{1Mz?(
zcz`d&LIR{f7UV)96hk@G?LoT10o=hCG$8K_r$IL4Lm5<nIgQ%Z;0E3h3yF{hxljxi
zw5h4V1GJC?`5<j>rBDHOw5Pd)H)x>*9B4z6_xU10+RqB00?hkRj-VXW&e#~t`Vt;o
zAqz^N9NhYmCWr^~{-gnXp&V>o*al)D9kN9SkS-_#+kqTkSOVhnTL#pa4`Lf|g@hq&
z17%PN>K6zPOCSlvk4P}YLMGS@W8V-7;!ngAmOv8Zj->34VxQpa!SRGVD1wC1%tH|b
zkHfx@3xyCn9$P~e1WX|PkPWU=SO@Wt=g%<+AbsFGmHmSjyh4ZzQlSXUr*SNycsd$N
zod!$7um_ljvkb~+kpC#+2URr33qm0cO29(He!v6bAsJF*un*LoNgijhEqFp26hR5x
zf=V!tB@C#+4jjQ1Jir@*K?7QdoQ<vKppXgDo-2dx<bGECnaP-2@joWx3@cH&HxplE
za{ngvvfR5FC!+=aObeJ1S-8rCQpow}<Q)+$<M?%h_+>PISV;JEMvVuCdNWi$+B=5-
z-qBJ1-hPphGHVzT{#yqC(Se%4@R=b|5#eEh;hLF#Q6YX)LIeF2j{yIP{s8{0vHwH#
z<7vfbnM~#;$|=r+4)u@&b&Gjjnf3AU!+t(v12u!6SZTc8N>t^_7}abghTr^C#!Sl?
z=v-ErH<a<`p^+o~!U83vEYGj9e7rai&@ZP7Qh9T|X6$@OK%h^!Y$D@Nx#iH0f%c!N
zp$?K|>Z;4S>c;K6{c?MT$SYAR<HYCJQu3wxfcRxxaXDelxo7*cztLhG4_m|i^ywQ;
zLl15$Fugm*{O$MWx8J~ZWi*9GZCW_P;@XeN8*l!2^RszAUZeV5ZE)v|S5C8DBO)6$
zv(DPV_0%}dH8k+T`K!(6eAj8q@POkcR;wS5kKo!mzn9oAu7BXx<b$_0E4mIpKcI$J
zUz32f-HQio3TpHGsDOhNlj<@qexQU)FTSU;i5>2A@#idezl+noPDBUgMK88XKX7Am
zvDd7uNN%TlN;sRW!a1#0<~h&qk=1p--;l}%eLEEOIlJa|hl$mjPsw|Af^qz+ar|m)
z+pnI(e}+68m_BgY_kFkFlT~MGPy0)gYM0+X{$=1#wJlEW&gwpW!@0fXYgMYwgC*Rb
zH-2>h_s43}iD#C59^GfenH}a^TK6jMP_V4ce3SB@Djm{SuKr<HlSf=YKIEB2ZQ5<Z
z-W7M9y=uKPVsex38a#Yu=-}r4+Z}(XS@7_i;+^S@7SkrlbBfxu_sa5$c5_->@+z@;
zX;Jsm%hxo6TOV1Oyg6~?+Si)3b!VUQtfV%L`pm+8$&w*v(POU#ZXfU$?el{zKHNEU
z>9va+?9Ix3yJYb0PY(&#BHF$Ab8W9RP4k=+J}O{N{Hxj#c0b>}>9jPzYtw<vQ*QGN
zpq#(go6oyBqV>roE4x~xo$%@Qm({Q42fna&(96@xHXa&#b2R69j$*$DvGdM_{n&Q2
z$6IE-f@0$r3^-AEX|F|P+nR&>&Al<OmR6-2u7uk=^<c9;tIxc<s=<Hj_|-6;8Puk3
zZKhl{uVy;qX5E%sLmX2p%c63}w144XuNnhy9DW$_GxgOuYY8{TWtRWWAIF|=9H{R9
zW6Z}*w|4T_f24)${WI=Py{3OY|E=FY9@aR1_4Fj$vMZOC_H~K>%c;gT2Nu}nS*_st
zQ8^yz&Rw=Pytb>(u8VmAS5yz?*6r0a=iZ?PwU+mck9zjV8R~;?N67J*q8&SW=m*bE
z8^8Z{t#^91v@LSjxuf9t%PlMmJ5KMbEg3`K6wmFyCtTB!67HqdTAQ0q_Q$-jp<w(Y
z^Vu~Q7gb)$|Fp}sqZ+@0pL%Xws#1+r;ww)Idc!*A+^}%(YCrsEjbHtDjY~C-H*NNH
zMnLeHV&CX7H(#waeS5D-BV1^EO;*ZFU_oKX&kjAB?kua3T=3?L5vK9C-?Xl?ZquR}
ziO(lHXTHYs18rMs(_`Cfo*mWMrCMJH_rrruU0iV|tTb&wp9Ve|AtTgnXEdW8f5u6|
zZLe4V?#I`|{D%#=xp9Lg#cD=iMPTSx-%Y;T=RNlom!u!cSBY<x=4;QFeUsjZ9~lz!
z(DvX^$04I#0?X$;7xdNG(>DfZ-=JPo?u%D^@Y(JoKTmRc$?JzVBBNX`9{T*%w3@Lw
zt0$aHNd4H{INsDa-ZZw+kXy#_rpEE6TSNV>8^@d0DIQ!t?1di7wwV9;>9B0?4vQjZ
znK!I_#C@@bMj+#O(>`{Sn$-TO?-zYvZQEjQ-c%R*2bAaiy5>Xr=e*b^eOc!TAzQlG
ze_?gHZ&q3@(~`<vy*o}w`bWl_8pn}tTUvj;=A=`z#eF}I=uy7wQILJN`SeNAFQzvA
z^6Lfd8Xmr8w{wMyn?v+i)3ehrwaVY^^hL(bOD9_g4emgnjPg8l^v$6KlNLL*Tk0|L
z_!oZKYTLd(@|XPC-#7bW^rF13TlOztY=ZLKxU}Gz?;_i;uk+dcxYhSxS-)t~kn-#t
z$7$bn={Rju!8^urq|qVEe@NK;t;ftO&2Cxyn-6@w-8;uto7JR$Ekt>)FpeV~{?)r}
zOs#tK+#huHNK4vj*3#CmHvM4atM?<SFZj|pjx_v(1)GfHNP7gI{wN@R=k1zrEox+U
zXtI4q&~qkDn;XZGw*BJWVPPZNbXfV_Ci5EK5B)B5-T&G+(mV8r(adJ(|5N$}Q>){b
zl4W$uC{qJo6R>2C$6GC3XYy)*GCuDal-D;@P0?X!Gc*F_wE<;(UK=!t-?r!>v>mFV
zlaYQsZ65phe>?6DTiDPyW*l#aA!wKP1}&sPK3KT$UKa#I668V|Skq?W0-=xynNSQC
z^nJNN0Lc4AxljsL6i#Odg%rqz%TNh6uB-!Zh=UZ!fy+<{HiKCY-Vg^VkOP-N1`ykV
z8{|VV$a_m3v^i-Y5%QoMtavWDJe2jI<|J_ed3Q-pm{iDxVla-k!`3fi7s!GOpqj)v
z0$vaaDNq3AVByX20Z%A4;deFOR{{;B(*9ft|E}?N|L9n|+zY(BRfBwi+Y;VSs7b!z
zpB-=a*T&kp)uJpe<GnhN@pgZ7tX;y{>Kr8FWVC?M0!9lMEnu{O(E>&b7%gD5fYAa*
z3;c5y;4$tO<Nx2}8PBXCV|YNuW63+~87*}0nQwcZal|xEO|W~i&yJlL8x3~Q2|7a;
zknbaRg>FztLzRqG&Sm@epgYSPpa=AXvn+E&rQyp7?E}ux7y5&YJsSY>ovQ>G!n_*{
z19#X++#}GDFbc-NSQrPgZy9?%f%z9f-hY=##y=b4o7zmJytn=a@3Rz>x6)@-sy(gA
zH~h0c4*rvT8tf%M`#{FlzKI(B7vNhDTYL^*gJH^G-kGw{4`iB(hQM_FZ}DG{iT(D&
z0g&ks<!Kwpxg%pT)=<vY!3ef#!8z0t+JKbD1DsE`%(sQjgpqNT+aL{|V_7>$XMPv#
zh74%WvJTJ@o(DVV1f8J^$hb*+=nCDSJIJ(){hx&Gjq%F{JHU`eNt0~X3R=T1(k1=_
z4iUcUSbsTJ4CDP}EWcsg|Br+_0f#}x;qGDkGw8FV*Ov3haK5)=-iBpw5>F@Qn={`6
zT7pdS`xM(91>^XColWF_ODm2K$kd2VfF@v=x-;KH|GNq0)mmSEd$Fvye)(Y3O+P;p
z_0Z3IqT}@Q6H#yd{1h}$KVOab<QwaTX#vZZ=-1U`xw(FwjQtMRFPE?y=4a`D*C9+j
zeYk&g{J&g(q@FVP0FZh=9a~go7r%GI9>@Us_Nq*Ef$o3l|4@7?2B48p1T+CEz5&D+
zKms^c)3s-MpxzJ*OCS+aARF?a5H5rG38(~XQ{o3#@Br~oDSiVIArFe749v|q7r+r*
z!2`S@7Lp(xvY-&kKt)rZ4LE`)_(CYegZLXrG^f4*@hOlEc~Au6<EsM9X>)XeSXcrD
zP`5Vw1o1zh0r5LvTZgoOFQh{yxMH|ih=*hlUjzkk0ZPE&kHD=SZN(4_u@DaqbY8_m
zJS0IXWP&~Cd?ZN6Rss}336z7>Ll$5I*`T7_Sbz;kxfP!RsgMELPz1L?{0dletlc3A
zQXvy^KzxsQLI6ZU7L<d0q|^d(pc2|Q!N%YU8pwbPPzmiRJdWT7UJwjLbiUQ)KEVd;
zz!~zW@5;ffC2@lrB!KuFNQZ35gHk95H#PA=7F-6$RxATA2!_zs*c=MMu?@!$%AgX=
zZOJn@fGc=F3KT*q*t8|z5CD--32x63Hw1wA5(ohCBcO#8aPG)&SOSTV0_l(i;y>U5
zR6^48*cdV(8w#Ne%<V`MNL}v$F5nHZ5D!U^2ANRR*T5})*X@Lz!5Q4Z6MP{~es|&g
zfm>i^&pyBoT)_(hAQIvr9#SC_E<h=WBU=k_02wUl4&D$7DUbn|p#m(rkq&SMPY8t)
zxCNCU{tIlt5nRC&A|VUp8te>S5DD>62F^V=o)8O3Jt;e&>czgG0K{jf`0I3py1fYx
z?vMjzPzfGR94ANw@xSQ>!B7d}bJH2LkO{e>eMvWn4*|P=<QEbk1ula{f3^X4F!bG(
z55&HMNDFvF0!aUz<6!awTF3_JgOl$l#ex-mZQhUoDUd%5`wVBF5bVyefC9J-Nh6qt
z%Mdx5ItB9K0%*r@93Tfm$C7@?1^1U&2Z>PN!?E`zec<ZP{vjTG1BnaL;WAhRah-(H
zsc0}|9TGyY2UtvF8I*^S|8U|5^9afiXdna1z&eusfEOe}Dx}ZAK2hWuY@*o~#D72r
zT!u2J05c8y0UKx!4&Var-~|B?32`7k29h8Z5@X2gOcV;C4CI<C&s@gIXn}u)1<csV
zOMiI$zkfvd%s~7A#D;0aZ-96V@Cys*>EP`j6cM9Q2Ky8Lzk0lXLzS&%{{i-~y}J7Q
z_3{szB6e)XG9MoqbFX}>-6za1+;3{2_$I)=2J50V0jhu22Y~F?u#YHBM6B$$hRWSi
z?n_6i8d%D2b#?jAd0&HPAv74>$@%U(RvAC9H>i&$!Y3#q+9x<<YOqgaRG@!IbVx+F
zb3jB4P86ukb^Za|8pzzQC-s2+EUK+?vb1OYC=(N9JiiC?*-hlPZrHx~3GiZ>JhzTA
zdAtk!4)9HQmM<esRhDD5*`ZXmihlv|C#Cx~c3^B|M7Ux@*)Edhy6=8tT}?=Iw4cwE
zn4q9Qs!vsG*312&v;&PY`PF(K|A-h4L}Qh?<@s(Zm48H-F4|}x&FsiP{0mrGW)er5
zlBOt*rS4nqk=U+ETp=35$T}{&%Cq<=laOeifWYvGs4%}!mPs1rpj>7jdONUZ!@lrc
z$9iow!+zvD;n;%kIvYg=&WH(#3JmZG2$>q9q1so%r=z+&1u6UH((`K@g!)BmRGo>7
z%f9&9XWud5v!X&Yc*yVxj|iU=7!{$9)F&j|$3HkGe7a&UE<t*~3<f*<_ytUhiPq?f
zt+GE)!syZ$5+0%n@e9?(q->wcx?kD*7u!pI-Ja}2$&aK@>^RCqmj-T8^tSX14fT<v
zM*H{$X#%74>1?brwUqA=$TQ0V)WS>W2SUo12itOqBd!@S5t<OCoQNG#Sf)#}&Xhip
zL>EGwei}--PgqQ-CL}U6<Z-!4{+r>YOqyD{P?1@ahB(5$t51XEkJ}J^8bXwCd4#hf
z9Jdy#&#Q#%$!~cc8D$cn68{xd8L9W_k;8T}`9gh|1e++6S{wtA^{S`7lhc%tsT@sB
z;MBmVU;JR37PPL2U4J{NUF6&~d=q{HagQ?51cy-AWSJbR*OX-unqaIWX*8tGm2*KR
zZWmRxK+Xa2nWggn$J5rH&3-#QNt=|Bs%evSOw-qIrTTQpv6pmkTc~=Kba?2};p<0%
zpB)wv6Rj5aBhit5{(<eBoTB|BA~~~yBK5U%R3QFi{>oyV{eDjx<$l~?zp80Ws7a!j
zBo0Yq8(2ly+&_}W`A<!|a*Y2-8i(o2nyopBV)6w;S=%bdbMoIio>-C-DI%)xpIXlP
z>C<&tpDu2-m2}C)br<Q<J}q63lcGzDHDP}{Jt<deR_e-kXt30;2H!NgWl_p9IoI2h
zh6^AU!fm?!Ds>k>AD`=n^Vg8>U^&oCE+F>gF-l3d>ZPaH(~#~~zu$(xPPZHJS53F1
z$B-6vZB{Z31gabrk8G+v*wEu?Y4HmP@bUMHikht}_rJ%6qgzY4kLgOZk8P-{Z)3Rf
z>8{~&4(pd0qF2Jodfhc6MyhV5jxqQ&QeIYO*;wFKg1Uz`H`1N?*V3)8$!F{LAoboq
zkbW+90m}VGd-h{UD^dDL#^m}^H4m~}GAGNWZZ(A0n@(BI;>UUOp^A~;a$F4gOR6JF
zl;#8FyDoOj?<0R|pQn_ODIwfS`ul|w5x2n6frS0N`O~FMcONEYT=vN!<Cukn2L#3{
zX&R$H-yG`7T3x+Pkyq+<Nt5r>(xlu*`9yQ0!nIcJ1(f?oxo9hy{d?(?>!q4~=xwLi
zOr8&PX~SS#nE9!s&q<#?4<+@q)pCAGJ-Qpslrr(O^aX^>#PO73r+EE!LgITeJ-K()
z-P@TcX-FjO7UCRb5*`z#tK5`(pJbNn&M~>k!&RA7dqmbzUj}sd9$|j5K99Ha2@F+k
z`nfcVrFG|rE2;|{Be#pnJ_}hU`KfyEBJs+7<db--?DtnO%YCTF<FHD+KH-6}iv6UF
zk{x|K{<@v=Tb4(n5@?i(EDs3^(l3|$n8(Yxo#H2U)ZGW`(&Mj`$l#D5jZbJ`kc5@>
zqQ6-m#bX64q%L)o^2L4m`f4gwkgrnCm2~8@_}BTDvKs$*xvqYYeR#7>S7xHQ(dG`c
z%F&R0RMw-7gGzTW;g(g|NABb8p4=bG`DoatfNc&C=DdCz*;o4GZFKv3d}LW(b=yj|
z&0<-qpDs_5_F#VNY!O0Bi!Quj8?l2tFKu9X7yl>Q(6pwvdx&iMcpnm8P1$$g1WCk!
zFZX{+{b~QJ@RAp48@C~BL&EOWhm~XPOIV$aV`6;t$5fWf{jn~cF;a3li*;oqyJ~n=
z@KZTfiB*?J1uDy>{CTpxYCKQMpQ-YUXHA;Uknr<CPma5`YFtwyqM{;ZDaWInJZLSH
zPm-v<)`u6Hx;@@Uh;ng}{Mr&O4)R%NHuZ^ZlKE|@m!o5*D7G}%U*fkSJ^KiARlkkc
zB9-5UJUpq(O)ZxYzXjpfv;KCKeRw?%|0F$Ggsn?hsqh;FKS|F8e(SDv(TXu8El)%8
zB*)vGIHWw}>En?4GWN;-9&c;7&gT<eCOeSZk9M%%fwtx8N*aFoyuhQXRMZ6d-PaLa
z-KV>bNV*Nzv4DmW3w1ImbuxN@{o02<Wxrv5(*u2~Jgg8_xlT|Y{C0X$Ka*MNC|%n^
zd**d^)TKr2V$a69=k;G+&!q2BrjMaDybT8>ZDGG7Z9b6^vv^dD2=dX)!cu=Eox1X;
z#G_n8)a+lk?3Y&tDcf?~bn9s3VE)(nlJaT$IE+-kPp;pFGO(l(0hnf(>W;-kG>iPY
zgg-66x+h<5^_09xpW$z(C&xg|dN~G4dkFKoYoy`vnR}A}U3-Wd>vUzsuugfjR_ZHv
zcA(3nzjFRcJB^xU@-72yD~}(=eJG#N!4XkBr7PRXd2iUREAwJ6U-T{VHp(Pws@#2w
zeY7mox7$3ve=yX=kHdD;U5mUZ8@X1r^~*Lo`(Ou4OZlzam#)r#lBy^5v23fw*6XRy
z$|4loDru5qsH;ChlpA6>m-E<19AP5}TR&14R?;eERu?wr@jbEO7#rd++&4-dTpp*3
z@G((JJ$Z|`V~Kky>wNWbOIXbEI2~m7ab01kZw%$dr7<g+nv*s;KdPf|vvFe7-!Cun
z9jo6?Ps&Rn>kZ}Q7W03tyi~AGXYZ<()*WLtJJ26@<)K8<KTv-!SgcQbGr~xH*Axy*
z#x;K<?LIvne7bj2$~z&SGU=WVrHq@iR^OhbFPBfsI92>p(=6#Tw2_or>!O!$+=y-0
z>20h2o9UY}yGpgg-J$N>lz#o+PETwt_7z)8ogv>5(AhdxDU;Ux*4glv^^mTNh5AKJ
z4b<&Y*;if5BiPWMO17G+$~vC_KaHR6{1y{eJwJ4@N*?Q49%W^IciC2V?kMY`l`2%p
z%Rt&(j}hjV7bE>~pY8Lj%sV;x_=I+Ia*7G3;bywwCR+9*e%URQ{ZvgO^<jv=^6Vk!
zT?yr*gkw+xyZh;EuGC!~q+eG@{I<NcXWen)Har{2`RKwjUEL8K5fkMvRkIS0oWJ_A
z850%7Baq&ThI7nNPSsLCndX38D#h;avk#Y<f2*AOM?|rwzxNC!<y1|4o)oYr^{1|!
zO5G~?(WTLlS6QcT0B4<S|0ExVFi+}hDR#PYqPrUsyOv>7c`soC>t595;WzCe5-yh$
z(wcD6_My>-6MH^6uYUQAXRw>0ZW2G`GJRT2cm5nhrEV&In%$zGJc)?Se($wR&KH*|
z=ZpN7>zB@E;fj5p*f54RZ!Swb^GLd+o|XGCT^*sjW=sCOSf;mm^b~r2qNnSwO;79`
z9yrS<COR-cx122L!#{qcQm$ogkC%u3BAzGL&@h&>O|&i^k6(n>Eq{*mv|+jK`uaHj
zXlW~sP@WKdBvX7!!qQUeC|$TG`Sh6;!V^{mO%6e!+?p%b99xd58ONp;=aomS?s_KI
zO<T6tm6d?NXpKA`OY^$!9z`h+&k}&`zC>o~x05pJ!f&0u*ai1ny0gr1w#%`%w8T{U
zFpBwUyp4&JW_-gLDPeqn6Q*i>y0ZS{+3}a_WP8WQ+gFYINjl_Q@qB6+`4orlc~6%Q
zdU>XVgp)`^VhzcBd>s~hh#g(9haCTjv!B@U$vwnx?PxehdK#{QE!ddp2=zbFsScng
zh%j=FzHU+ceg}nW=pU7Ea&E-S%x@>f&$pE6MAi+a&{XZaOJ<oaZ@=ujOJ(_A>${V<
z(pi6l8<0^Zq=9)kKQd8WzulAbUu>Jra^1P4TW+YO{#rkslsP#^){$TC0i_N9ag#oa
zm2+3_eRO47c~+3yO69Rf_9y45uDnvV{WR<@ToV-$s%+=Nx(}3itM=H5{dDEzw2~)(
z`r4vHf<pY2qRuAD@$Ibdn{ZLf65fyGJh4U{Q03bt3zTCM78vFqIon72{Tf<GK7Ko?
zm181lm2+F(XB}nY<ND;}(xpf8p|e}nbz?*3aQzT_`?9`Lx9wQN1x(@$ezKizxo#8X
z9510<6}42pv8{SRmtG|<DVuT}Nyp&W$S5DIs^nS9vutCorcAT`V3lp``Te)Hab_D=
z!u(KW8%+PyZKV8{vo4*w#OUjN=BX|V<HnvUoUD0e%#c+Rnsz%{FqFEWA8kdZ%a8ll
zes^Bpce7*f<Xy@rx4xHi-~I5AuV<Z#@|abpXdpIpqj5oPn$)R|_S<>Z;n#aqmKuG%
z%QueZ4iLL+3O}~s?Soye-I(rtEh6r@?~;NR+1UC$m=QVWy|0r(YjPo}O`*ky@#Zr#
z^45Pg*JAk6<^Nf}-W{4q`ravhlz#bx8R2by@EJI5M*Ps&{8m?Me6+o;{qkw+F2<SA
z2hq+#!mYV&{ZJcl>CvQN#~KWd_#k0J)Vuy0M)zCfKQZ^*`t9v2@f|Z*!maCcszv<0
zb|XgJ*nQNkw`Ewp`736Obss%%^U8}IhnOwc&KLy6E^W`IY<+Fb>K@l_A556lB>7Ug
z$-en2k5{)kO>p>pLysMY7#q-6;!EhUxznSUM|ei`JM+oUN&a7@EgJslgZvL$oL+VF
zR_FQqT5+$S#8+YA`^o&~n|y-`ZVkO}SLc4UiwiD{nDS0#oN4RL{#TB@&$t4mJiqY6
zhK>y_zuBJAZU3r$%@&QwTz+}pi798tTrb$Osl$SOw|ECoiLZ0#cB3c#JjAxgU87I<
zf3HvY*SQB$n+{rd{K~@SXQL04E=);2{obO$&3A1#A00bC$KN!{>!c$Wo==o;Bl_%k
zEvMF7>ug_sRQtiK_hwkt4Cs0$ZtS{Oa;j(f%;-4A=sW&@-FN&f8!0c|KNj~I+O5f^
zEgJ@Wd0>m_@}f@<j<PuNe24yBjs;)ap66-w9sk#Sf*u_q_Ph2|d6ORszxwLo=!JcZ
zzT+Ph^6C;dMQYRG_4*ulys_uikG^nucYm$BKc}7g<m8)c&O5o^tG)8_gZfU4H{<41
zZF;KNioiDptWUJJ{Wv?bYp3t-z0<?O+hU<(<-N!#w;nIt)%7!|O&h$se5_sdK0zTa
zJI4Cnaa%QM`hlw^{++v}-cC=Az3}if<F1BCe24Zm44Ckh+oSFYGnf0_?shGzqR0Ac
zO-(Y3I))y$+BA-b{+JgeT--v(tbWy&+ZI2x>hpDq%a@bJd%RIx5j{Sr<E%@2t*17m
z&t6Gii(T8k=@@Y*dGBm9zq%h<v_H9Pe^l>{6H<27ZdmWxW@Usk`j|KRnD@+Lys2{E
zG;hY+#iKtu(fQ2!<JVSQd+lhY>9qsuQ!kgs&y9P%{_Qj~p3ju$iphS3hoVQ`T5M-u
z!%bCM_-y}%pKP|x-+!#;!Lo1O?zonRy=dir^5&<9qaW-aaO>>l{yBH9p9#zVaen)P
z#;sB=)~Yz-Rk`Op?YE2#QJb1o@3DWQ?{g!4u5M@<x8M0)+jpAmxw(7A=~gA9CeQo%
zRT`zb(SV3=)B4ZMUr@1h(T|-ye%2(8nh@>LsrA;_HY3xWjy@NEuau75-kh6i(<wI9
z#-yirU1;<%Z}c%=>os2!qmOx`k9q5B_D769<`?9-C$8eY_!MnKYSYp4F68uTcz(mi
zlLg;qpLsLO=wp5vV++-$rLVMWZ1q*vN$tmxF>@XboHSr=hoy}+N8K5|Zur+PAMhz>
z{HkKV_pYp-dL?{b>ebKhc@JN=EcUA*1GenB_<H^2{kOldYGKPLd>|;{TE3OGEFiDx
z>ZBQQtBpS9$IYP~Td}jx_{a+L$R6Lv<j$_O$mQEExmWCRef`cadNgZSm!93?lJO0o
z+;4n1Eql9vvu^z|_iw&A{PVLXew@7Dxl{SZ)~ja){d{3kf7<HKD)Ds~vf8WRoR~M4
ze^NjAp>uxegND(Ai?8pRwI<!K?TI5}-{T#io^pH-wLai}EPdeXMj!KS>%P$a{%hR-
zDfdm0do7<+_3_j=XP@0{fA!Tvmn;9<e9Si*EywqM#OwVlXYNeT3LDqTbZ_nKfp30y
z&a`iKa&*5tlauV_Tk72$CEV=kt)J6wNUZttlEY0sJ1tDOHX!j6%Q}`@*S@#&{rKl6
zU*WxTC7kuiF=mY?tX`bcGo|**aTBdBdB@DEIce?0CjCFi89Z^EFYop!;qDZ#USiYl
z=PuR@u9>FZol<bs^W>td2@XAzGmXCJPh9M>&FG6heVew~7qnsSRLV>7{VhI&nhx~;
z|KW>1xEk-L>BgKYV^Q;~<4=n|DDi<J6Yr8}JE4<ME}g2$=mOLq-Gc_AC1?m*lYZ1l
z)DE42jzH(3GA?jFD!x{<{N<nv(L8iHdJ&CBuc9l^+h_vXj5Mr7yP&Jk(P$z%7F~;m
zph@T}=z3IqwNPzp-$zqWc|T<{Dt=nFpg*IpqZahVZ$ll?9cX_v9rZwWp<~btbSnBL
zD*jw}9M>*G-$J*dN6{VVF*Fl>2R(tli++aYq8HITv>5#Wy@7s+ia(eFv?kB)y#K0g
zgchNb&<p4u^b0f-Ek<+DuTl9v9o3)qQ}i18IeHVlf_{(QLT{thIEHu7XHjm8v_9y4
zbPoCeO++iv*HK<g)4q+GqQ_C*Gt_>7^1X7cl!ZFzMYJw@39XNIslofxr~_(=I-`xz
z5vVolgEm8hP~KnE%Gl->C}~ps@aV@$s(kr<i#SQP@@_OD;}*5`(cUP{$?}epc05W`
z$m8wxV;Pk(j=$c%8{ujZzAI{lI-oRtsJO*Yw)bLQKL%0d!Mx<r9Hkjgndq8Rwtp6F
z%o5U|e0!k<+L_;Uy({sxM*H%+4LSsEiyHE$A3vy!E0p-F=C3{BBz+xFiT`<&IAjdC
zvb_uQ`mueF?L!pGyC|}XrWwUPE~waN04nwwh)zNWp^^??(2vDaO=Vu}B>VLQnb<~&
zN6v5Zrot{-@}znZWgjYUlzHWRe+dPxFACZzs2?i(5!>p=&Z%6OmHn8awjfgg;pBJ*
zq8v+AkbXNC=Jn&;l<{w}9e<DW*_QIskl)Xt*htk5?SZyO#qJ$Y*}n_u$DJwT(S99I
zSHf{jRozgkcU5<EAj&%*+L34vRN`?1{rD~^J4!w%w#s|{i0Tc}E#)K)ZGdh^+n_tp
zj_6L*4oyc5cF~W`dR$Jc+GT4sU3{;jlCN#3Y!^u&{g^3bES2PEI?DrOW2Uo&ll`7U
z#rD*3+Fs~I)D^viE<y28rF{kc3f+VjqkGU2^bmR#rS1_wR@(FE4OI63Ey}sADnp+|
zzehO+s@v#5^as=jEk_rlcTuUw@1Yma2WScU5WR&`=V}{NBVtpPwkK+WMx)hGY@jkl
z)6nYZakK{dHChvu`q~_o`neYBj@CuTqxI3rs3j`(bVGC&+6Y~MHb&Q?_~+7YMw_8K
z(Pz<JXbV*8X*F8ijCa}4254K<5^aYzMmwO*(dSWH)E;$4yQ1UJ?&uWM0gXU=pfk~4
z=sJ{ZjCKd=gziP1(IV6ZEk*~R4^dZiILF!z4MT^bOVHuyHk7<;ccCNEB6Jjb1s#pv
zL&u`6DX?Cs8_M_s?M!qMx(LNq+D!B%^a$#Q-bVe=pHa$}*19I=DcTI3hCYXeqTSGN
zRKAZu`P42)qtJC|G`b7r8mTQnXQE%Bvr!vPm^o-GG!E^Fa%{8%P%Y|%E<(4U%h7ky
zc=QwWW%M)j6;ynhtwhVw)o24MvNfm`x(;<hH=rZYWYh!Qi29<N&=n|UK%0tgLARl)
zsEkp39W|V<`tdl*wdmLN*cOsZaMf0{9h!>Dc5)5TkEc<_*~oTeU*!riEhStVbQvo5
zQOnU0XgnH(zKkZKa^JHX<(yUG4Q5_H7DgE(Bk|T|8TGO<tt4D)=2oFn|Exy2)+zTz
zZfFv}rQTkT#-JNe?wM4{=w@^y`Zh}4pzP0=b5%bUMH!<a`|H4ZPnOFxlX_C}F$<M?
zXEr(k<(^I(fX+wfq4<8#u0geEI=Tcshb~2H6W20y02+@*qA#Oc(O1w66kmK=8H=_O
z{SsY;UO`u*chI${3H3q}S|8njTA&+IYjhK;MpMvH=oVD&WmD1V=<BHX_De(GK)0jY
z(Vgf)bQhY7?m<6BNt2ekRP`qM4E04ON*$v*fZCv0Xm9i_v@iNLIuJdIPC&WW)p9PX
zj-gUs#3uSN9Lm@Zv2#O~rGQM_Gb_h+Br4Yv4|E7R8kKUx@lfnO9+l%e5tZx1Bs2<r
z36;30qqT3KerP7@kDf#W&|)+Y{Tk)oT>A(OLAeK1g`w5aa8%MO$67ybLwS!?(o1$!
zwz8awdu`>sz&E0{DZfvkvRy9d$5W_eoP})Hh-FzI)BD8V8tp>(o~S)K0PTiOMY&ce
z&l$Z?&Jpp?sC^xELJy<P=%;93^dZ_G<sMWu0OcC58i@8n2cs{bLr`~g96ALZkCJDV
z7fKmZy@*n_R4<`29>fQgeE5QXJb*GzK=L8=fZ;yMnS3<lcVDy_+7FfU&;=cfQr4CG
zC9a*yx4H(QGgv+tmGg24D*I8hPyPGz%6s*)pH?ilV!2FtoKj-16R6nh161x=^U-lA
z$5uNTJ%vs~Popc)GbnX|su2AQ{REZcU4(Lvuj1OTZHux_d2ah0C2h*{huG^Yev6%o
zQ8{0~LD!>K&>iSiG#f2NZ=%;xTh5nnQI3_W4D~>7qQ2-YRK6K>8=Z~*fNntVqI=ML
z=w7q}J&OK>%J_l@sMv}88s4E+-mRAV>&7h00h#3fP>zEgDrK}YD))2t=oD1$2WO%V
z=u%Yf|1O|C(Z8UMC~1^;gSDV?LOJJ@;~I$e=XWS7$8|31ie{j49HkzjtSR|(Loe`q
zC@S@XoY!*SG6p?>jzuLuv7pw!Un~2Ix8@#)WuYJw*9<L-@Eb(EhH^eC*PrgF9B0a!
zb`jbWU5h%R=TLcmYC?R@XbZF-%0001{6OASF8r>*cK^%Ygv*+OJuYyrLIM=d;(CN_
zjNgLe`bmM1!eIOs9Cghwo)d<1PCx*}LmK2l8CX%#I)E3%K^o*k8CY;pwg(Rgg#^fe
zd?*I9k<>}x2EiZ?oym|1`A`g%U^9w+fIEajB4j}kl!3Vi@qilyKs;nXK9oQu#B*MI
zd67m)g<L2G^NFMp+(82=kOQS)@gnC4{JXyemoS&}Gmh&mH<6K0KA&se0@7widiPaV
zIcTvN^Oa~0-$6@X$hCyuX4GMBkOF2@gz{`u0;ON@y9VJGV-Hk~I&$(SFkb?OZ@(pS
z!H{piEdkr5>;v^cb5LJYo@pu}i|yrk#txjJh;>P5F39tV*)rlp)#xAj&YLswi9crR
z<!le7<k9An>MBo2fMResS6vkhiI5G&U_pjmAP!O?56Z#*)9NZO&_V{3fW`UhDo5}H
z<7Bje(E>&b7%gD5fYAa*3m7e6w1Ck9Mhh4%@c+{S)yVcEX&9Etg7+?HODOF|doCEJ
zoo#6Egu!5#meK$zekNo(N!T;+v3{FVXddfMz)vl7ek#Q0g!q^czX+c&e-4V^QxKo;
zGA$>(_-uX|R=_Ke0Fo~8A-xjBPje!yhBfehTiV3IFl7?|T9zk)_@OXN;&bA2_9H$d
z3Q+MEA=6dTXZQ}_5F6TYA=`@gY*;S-@;@Wo1-J;USat~&|M9X;{BLY0KJkUW1KkPV
zFuxuZ|JcbOe%CgF_z4$(+?zpsL5VNtRCpZ>(>CVcfHeIw!@k63@(niePu`9Fp2v>j
z&+j(-x&pFnc1zv(wmbUY>8uyO%s2GE4>2#kdL*r-`epY}@hv4jqH;j|K*{tD`Yz;x
z_+AoUOR^97){*F&{1zXt-|K%XJ`I@{e-pC)x?aUk?RU(JpA5-E1;<hRUYK?vFA#^V
zCA|2<`$4~rXKVZx@>~2dRp^)9)N3}&#Glw*{qNC)&EU8AATHA{+s(ZAQvR0TTd~vY
zV3>9=zpKjcOy&<(`F(`>cl5tcp!xdwQ|M{^e0}oJ01VSvmdkgkWV(o6($9a5UeV8+
zkWW)EOm&%WP~~?6EBXS#F#X7OKk2uXWeo}YOqK9f%r~m?yAj(quCl!)>3c?>#%3&k
zw#vGe%&Yak8?lcjRrd40@=ZCZe?~T<&y{>uWf#A9!yd?hy&zM2h=nZ3g9<RG9;A;?
z`bkx>K)<r81j<28rAhyx@}0OOG!=585O{w^RRLzER9hf@#qELjMC9EMc^`t6tb;g+
zha^aa49JH<sQN9q_B7kMLL^9gr}TYEKcR~D%(~DX3c!)}N)1SxW+GTgyClRx7UY5W
zO_z4dTVO$lrW#zq3j!b#;vfMsARF?a5H3S0l!Fy*mbTylsgMELkOzfO2Ih6hKePu|
zSOVsCX}1M0z>TW%Z8^ht<y`9#A9#a&TTTNBkPPXN50{}FRP{+eID;nyfCdsE4YD8)
zE<-ugZNM=ASMY>Hndcnw1as;n@jYt`_TUVj5DH5m3DO`N3ZWRvLB8{;21oD!Uyx4W
z1W1N7$b@{j0Jp%L^UWIULB4S({!oJ<7Lq`|b$0>eJ9jF|rv=!7D|kRK#6mJ;LLL-B
z8F*0UQ=tGZLj@hAj?}LKAm6yNw<e8{04WgJ^#9m97r30V{r^9CLI{<Rga;uBx#W@%
zLWp8Qi0&!6sRtp1s3C+9%591eLgN~P2_b|KLPH2iOvs4-@AZ^9&Ybz3IltfkoZtDK
zbM}7q?z5l0*Is+=?_T?|Zr@FKNCpLsr*_~BDUb)nplryq0mL_POCXZ_PAX)8RwME>
z*a_u+tAsE}1#v$%;F)9sKCl@wAO{SavkinnG#m!;ojU_V!b5rsj=d%43#=dn^1-AP
z=LWJtVMH9@43TX(Cr|_?Z8=_ug3aL2j(HH@Snb@AyakaE3*vij0T2qNok>50ffxsC
z1@;hSNt&SmG_2S^*ns#Znj`qYX2^m(NU}zu80-d<Zy^iv;P5bx%a-^d14O${Hwb`a
z$bkYd7|y=I9ehS$56FhxZ`jtJV}}6P49SoR>5v7vPyi*6Ka%Z6p<pzcV**>P^7oV|
zRJ<STL&fuQH!7Z^Vyv)Oz7!SD^;M{Nj`u;uyO%$D0F6V%b9*r=-UXJS;vFXu70+n#
z{1NYe!KirG>47dqx1!?NJ{=YBBa>0_UNi|6?=<nK*x#ax^)oAUJu2QAq)D=XWC6(n
zk_G-g7EmV|KbabDGdyq19sPsEcl^pf;wQf5$450Ldj$G<_&D<EydcM^{C5lrbaQkG
z2oSRs-yFlUVPMc-egx3d*WcX(cb%&5l8G=C9|Zj0{vP1}#<%~zeCMwiJLdA<<k64k
zwEU$};tr4E2_NfsZhi0YcME#t9*b;{IP<{B`P)16nzwINCjHO*h;ZG?mK-?|@=M$d
z7nA)1OUt^3JdbZT+B0+Etk9{622*2l=r65`uc=O>L+86yc{}TR-&(S5tBl;*_o(&B
z%y)SW<5q?X?=Id>T})3ApVzgprLsMpjN0$_h^Rf!^Ue1;&X;Dkyz60Tmyj~ls*tl?
zrrPh?Mh&VC=zg(FogpbzCEtab1&mJ^D(q(wes|f6oQDmyx20CIy7Ay~txHQTX!Phk
z&cnV{<GD4?@osG?-kIfj!7kH`hYa896}x!djK%tMygH2x%C%TH$9{NV^6E4HPQD8z
zpM=dG@68EIs9mjh`0j_Z5AVJ3Tw!vEex<7X5_{s}vMNs|%`iT@&%Q&SdrzE?oM}G6
z&_?rY^$XXNWOv=DL!*qLkbhLph^l4~={GDp<w{DetHX9*pE|H^m#Y0Y#@&B!;Qq3V
z_x>ItT!>QVfnEE9&%0}`xplsz^46`|&Kp)A{*<DuZ2A7%+i906U#Q}nv%<WSW#Ot$
zW43R+awah-z01c93*$z%ct6`Zd*ijOAK7mVWfg_of9a09UR!Jj&Y54Ma<yv>U-v&c
zyG6I$p-Zba9vt4+slztvEzL!^R#C&Es&!Mw>cn4t+Gp<#_XdkcZyjiO>fUvq>!$x)
zpM(pii1d|pD)oM^<>X!0;<W9`y}k0fy_nv><l=(fM{kT6Vb>*Yg5+!PU)9&(gZ|?D
zmM+*a``(rvj~2|VezZ=L7E`rm7Q8gM_fRM4NXdtUgzmE#r=ZIB*3DgWG%Crb6lylv
z<lSv^X+hx05k><Kbgk0&`H@flp982{p}eS&J1puPesa6^h3Y@+T=|$+c6QsgiB+0A
z9@#Qs)$N;W-UL|iuvUdDvgnc2!F!zUH)jkro*BG)G2-CDtV`;Z4wilFb2)BJ8|o2O
z4-xS#+w=ZdgN1Ly@=fjC2KDP)I&$X?-<Zc6g9fy+C`c;NA4_>zmA-o^CGjcS57e}M
zJ*In~w<~8j`%F7{+u?<cX~DUi&5bryrCvdG-}qx6s>OrEel;})^iCbyJaJJw$%o*m
z6q9AN%UBA#-01SL=a^H4O;>2@Ry{dx^EXKrPt2Y!j(TWO?Z$M6xBmzqf|75*<#oQR
zoS+fC{Cv{Nc}H7JZZWTQzfH6wQTL^gU+Lpfda~crk?nliE>Pe2eGUE4;)`=;r3c(y
z-1^ztf*miYuj?+t75aD5yLdA$d25Z2FP)33*7V!3uYaxnCw`i7bbHj3MrPdW&8T}*
z$d`Q556&<>c-<o6(L2dEpnZzu8&H0tutx0t?#=qi+^vpZdpU5FubF+{66z0C`DMoy
zjT2#2x2)0XV|ZitL(^r7VFRzXXmiQ<TFu%`yN302rOlFecZK}+i%hp7!=6{06?BTK
z=W=yV{cpzXKBl&*<~*k(m7ct-pGUo=>OHJ%L*cT=hjz|;{(gPqUA0ynH=U-IKf6ch
z_TGju!(vw(xX5JZRr`H5qR)kit_we(zPf8l$@3qg_ddv&y2Li?jM07Xaq}I<9OOAe
zeXv6Q<J%EMZ>Gt1uhY*ud?2ow`oVF7ON(^O)Qfsaz5ylQfSXU47)!nZCEtLi2DWOF
zZ@{IVmtTbjzpi&MZOhbY38%Nq<7d6g-&A?x+OcAQ>mu6I6q0YiMYC>qjcqVJ>QVFT
zt}_Ctk7%MQr^Gs^W`&2ndUp9m=4g+!kw*8o-q0T!d@o>k=AOqg^}6TF`<qZ7QR9-$
z*}aO(IX!bK9lv+$ndAKl_Z=MvzuK+{FgBhl`3B5;ak}xOXOp~d?F{g2J74qF$6Z&R
zFWeyK{lG_M=NFl8*LhZ5`aG%2jn##NBTdhF9&6V$;-{4FT$B8B=49~LU#6;88J~M6
z>O!bv>%%R(WS**NJVz^T?$zxr$IQEUaJTm1%g<Ue&cCb3&r7G(aVl1`JbQC+wW~ot
zweo*;WK!EBReOxx@Bi=S8&LB3muN8m(1R&&NAF3C+`YH^=iCiJQD<lur|nxIFG?Jd
zbi!V1?AG-SCs$igDI~2Ref1l2y{4;OEI$=~EBXg+Rn<Qq%1~Bb(rw8y?WzZ&2HdxO
zG=Jy*=|wF+FV6E@n=obJmYwt?Q{~g__ZwxB&%a6ojh6nW`uzKQf14|e{%8M5J_LLi
zJ1hASp#M`Z`k;a2M}R(`yo2U~<VS$MaMXPZ$AKx34Z?9~XK;W3h=mL&1}#VO5!gd6
z{b_~&6e|$^VK&pxtrQZO7kz0B<<uEM2w`L4Fl0dyXpJYHS@c_gzvf4vb0~e(=;%<2
zCeiQl_k0L2bpCh!2mGGzfWO6Wz(3Mwz}Nl)u(UKu7LY6;SwOOYWC6(nk_99SNEVPR
zAXz}NfMkI`v;alyKO6tQl;8g<<EF)!^8eql)1v>M8tCaTrdn4TM;%p%vHBn;E$s5&
z8At8THgr*v<w6l?lDTXk7$U%mdK~=43m@#VWC){9CI!-<Gxaa-pae0#S@@{csKR!T
z38kP(zsb#z3AtdXK^+pf3uR1l1jK+Ct1O(Rn}Q{TLJH(U5tM>eE$XG<%UI!T=EWFc
z3$THFj$J|i661i~Ar{1VUmI`)cTj>D?`wd)+(C@rjfYIe-5S>Cm>@vZH$fKUK`iYy
zS&#?8jGNsInUD(+jY%h@fwBp8U62m;#;k)F$ZA8nOgJ{MVLW6gM1fZa;(}zz1HF!n
z`GlfQDD6evAli&NHPGwAGAQki9n6Uzw0h8{2_cXI#h|cYKi~{8kO;{=u@m*b24G0v
zCox9W9a10<ia};c7|;VlFa--RVa$m^Ule>G0;EZ@fMfy50+IzJ3rH4_EFf7xvVdfP
z|2+#(^x_+T|I_jRZvKALJn#b$?5h-h1BAx_7hm@-ogJsU1u6Y~U4v93{{JtI_t(MO
zlamuZ44g=%GSJ&^q9`&NYLE8zbN8PfgnKDN?E(H%{oGxY-u`~V)s~@lpT2|sAdHQ+
z@F`|4tF0~0U>0RuF`cI@+YlAs*{nqQD>GSBMz;s2FGj*ef)XbSE<S{5EYs0S7aRTM
zWJ$4(_1fB*XmiTLwrT<W%1?lYdp|Fiz#x|Eus$0NP_1_lQZld4vRt$|*s2BLiD8gm
z-x*4eFX8i99!YtZb%Aco*CM<qzn6#iQ^i@rZyy8IK9%mwi#P**4dXi1)6*mH8)9Y=
z-{sNPHvM&7podcIvSPU%D$-=D#`0+{K2upyPbSwE-`Yv3r1~C^?B{a(sN$i>SrOi;
ze{evc6Pw5?aW=keQ^YnS3Da`F%BCv&IPkkX?Y=I-PUUHHa^qyO<FB_BeM_<kd#Peu
zk#4I$*q`W&GJ!BUDSz5u@ZY$<Shgjb$*O<<r)?wt#%(j%_6A|6RBS8KYQyhxTmHFi
z#4&!!gL>oxF)g9Kq#YWFs*?w`4*w<(`Z#%c_yl+a5=P{~T=aLQJ|YiRmzk^bn5~-H
zuX&|BzXko8SIYBK09m{|KZy+AoNaB@%JY-(ulIF+`t#!{&l_U@VtFRoQkD10&!t!{
z^5~!PlD8_HIPbzonXQ_SznhDXDldxb!II_W`!3G}B2H_TmD|qU!*gnohse_+Pi13g
zi^{6+W66BVZKR4@tp7b*f7!-|ZRlz%^Egs|ZpD71_`OC?q$fz}qV)JR?}>fH6FvbO
z%t$Q{FRmxAU-#kb>f|;x(24BJqCeYCeA{Fl%SN2|(|$tvU4DE%9^9%_$B{_<WCNL4
zH{q+W0sNk#x;F$&XI2%r$S<{I-L;J>($b5&msr-W;y#vIk%tx$z81`bZq!4Co>HZO
zbL{6Pt}T&oINaZxRQE1ncLi%J?ll#6-ST^u5z8yik%&rlel>nwR-R}0S&?=(aTuyJ
zc9dzU?zO`2p_n{Cq`?`gkk3s|tJ3(Vdo4FvkxrFi3G<stl}?ejLRs;3o{r%6Z}YS`
zzvXH6Q{|BuexKG7=R1H5=<Vm}Uw&++EZ3uckL9X+r?738igX8vgJfC&;u$duG)Q;y
zZ_^#*Bpwf{w2QR-&h+c^L6xrZbNsu{2a(R-J|8x-to&I1^7)X+y5Bw@l79_fe(Z<&
z{d>o5$@1SGd%KEb*A(@%OrpDB9T*AKId<nCzvL^`JH$Wae2MGx_s+|g{8Uhpw%Mdf
zoR_JfN!l|1JZ(<m87lJA|Fv`S<-Ye@+ZU5w1^3dwcYpBzG=E1ohG9qf6!-dT?i|tT
zJuzkW)mFDR-0Rw<wu|d8k#1L3h4(tTYpyH9etCgW$fMiV2z@bI&+nO8X?_)(OP8LT
z4?3_RL;iMz#-ShQ7_FVb_@6!^T;>$5r|)Cd7rrmNHQUL-w%3!|Z!SBe>USL)P*-0s
zWg8En&HY3;`N)}N@|#U|rN*Zx>@nQ&%EhMX2fu}bCz>z1-p|*3!9jdDs^VLqSJiX+
z$F0-yqF?^Fe&?ws$2Xic*m`~P!6i8v*PIKU@dRjPCE{z=C@%1LlI}2{^{p=@)>ytj
z;r-2%rxu@hJ$BXjb4^=IevxLFrF7WmGN80}&(>KzuC9FDdQ9a;u4zk0<G)%**e~CG
z{NvL<cAdDQ=je&S&5s-^m}t7_W0S+?$`AYUcbw|H3Oj3wa4TQyeF}BITQ+X+@!I|U
z&ql5d{K0MQ@Lu!X#+<yqCc&swCack3gj?PAV&jN+t%lk@-+9csyS8u5Ig6)!V>5hq
z+_Kxo1Jvgx@LfsOd24YscGJ3*E6kq0J`g#*e$3rswLNoWc1t&zkM4YDt=Ts6!8Y1!
z6!J*3xVB~A4z>61b@|%oXtxLP^M{n3O+VN8((=Nhc60VL<vYKs`2N@*NmEsR9{BTG
zV;${B2}vFIE#IR*e`s=e&g?U;S4TX{*tMbc+&xA3Bvr-Nu3f9)<30~CG<(}jA^A^w
z(2{XmJ;eF=XujuF$06fom#a_useYxLA5Y!)_@%nmg`Fv#Ca=A|yO{jaPL&UmN`4&a
zr!;>y=;f%wy?q__&%ct`@%oW2rW5y#`EK;StLyQDPdl7Ku5qtyVL|BYHg&za9=mM2
zCOY)<=10aFckYLrnsoW1#>%UFyOtMwh5T$&Uz;?&+O>wYzk06S6oa($ML$hhoV|NR
z!4b_vncD}m-*c+-+i~>n#cwSfs+|}*zW&SFpOy^j->7%1Q=gP`KRwFbo>-Tcm36f9
zDdgRk6_>P{+4!zQp239qo$_;@D*HD(x-2FxYS^lE`Ymjx&<08yqe32dOUouKY=C;u
zH%~nh`ur5yroYy??SmFRy}i~{z1X>Z65lK4*{YB?4zg*~vc=N|@%A(QY~5!@EDarM
z^7(C{`NH%L4f-~UeN8)QR}t=6quGT+n_UQ7)<G-&j8n&-RxC~T7`Uq6x04FiAN;0p
zIM-U;;Ue4z|1G^sr)^J6@g3PzzPtM2zI$I@m-jpz6V&U?_-NA-;!0K7`D5_x>%Q+>
z47dAUy{l(%#N0k-GVkuzDs54<f3I23`&J9(-Ch-L_rwGGJyu-)VR`L;RX<CAtN)}9
zw!(hhMkueOM7KJ7YIxr>D+j6d?*1`u;`Jgoi(8{zMu(>rEa!b&6>k0N?R{@`kM`7l
zr`EAs^$R7Be-1g*ORv-TBm05}UFtve0N)c<+3%12J4t?<E{!uRczkzZPs@m(F4i;H
zKi4EpcQN%8oy7S_v}nIc=jo0bJ8q}BKbC!*rP;MX>brxrtA%%o2yA%tGWVAkD!)>$
zq2CN2bhhE7QTtw3JJF?yVOHnu+cHjl+gLl(cyiCsyb*k>exQi&kHa-kz2{6=5o%Ca
zf8W&a)@F<<)0k0pL00MA^c(G;9#gtx{L*FpLcVLPimy1@^E<t%*9ZGKR{B{jyWz~>
zH;zXJ{(SSv^C`v${<(ge7OL{;?ZLV3J??c-=(qn=zw^9$eb<&vE^M@{asKhyo%_10
zdtG7t`~YE>gL`z`M?bJG>l8UH+~sx0r-3DAYo0bxOU^R(IikB^Bo!}HRmU4LuUks5
zO5ujNpLBaXjJ3Q!Zj{}3xg|lPJdLN{-K{r~cLTG|BEH5uwmvfUe-pENhPsR9IW40L
zJN5;3Uq3o_M|GW=4fP8McT5%ElCCS$UF*K@((kkO(8R2{TdqzmxOL5{U1M3BC9A@2
zb?2VzrAnV}mPg{dN^iQ`*pGZSS7+_0(h=iY?v6EGcm3V%eiuI4Rh7y5sh$gAp<%jr
z-prfk)YvI}*7c<6m9q2}EZwwKS-J6<ZNVEB9;fW3O5aXDeMQ~VX}ybl%kD`2opgA9
zIIG^9mMb6Hf9o9mUBoc&sh<oF4C*#uxTQz&?3SJnzPa?g|KaC+$42#@z4+{{oku^9
zGoRq_^LGJ(mbVYySsGt8ICaJ73z3_zXq-})$>ylyt1)1&N96O|j2rL1S>~BkcW&Dg
zZr!T}UyR<7q}ScUOY-k@?2Y8#$@;3tR=$U$dcPX9&nPCP&6RH+mwcT1<gWhs-XCXf
z>ORcwL8sxl^M?*z(pM%kwifpn^9vRoHmU8_O*l2|<<g(`YVMi3Y*=yWrYqBK)^Dd@
z>zCQ({je1BNk^wWKUUy6=g!@PU9C-rZfsxtB5sSvr+GW7IWBBsIaW<3yRW(rJ?#=d
zrF2fo=hK&SRyNNl9Gmif?B_ZIybtUh{BgqL`M%_NdrPt3*!RzVI{&?6h*{(CvavCb
zTo0Dr9d6L6+OF8*$*#$FE|WgduS_AIr}4SB<ljm1?__nn;rEh%r~iq6r#rl}DdaP>
z)Xs$loIks2LEk$soub;7S)FTo=t!5lGcWsuKk9B-o$IoT2=~YSLiGoWaN9Qpd}k8A
z>D=frAKEs<=8ZV;&B#X9ud0r!->qq6)ZW|ljjk)gh0l!N*reIKp*P%y1&=o!p>_RS
zQgt0={z#L&ci}tq(=PI@57l+<cD8w9tJjr&7_PQ{%ezBXyR#Nt@_cC+T<KYl@u`z$
zKHxp4pK8A`2aV5s?7L!(L4$&~r}jVTlhXBry2Ac-g5U8^HD63A*n*!|Rk-=bGlGxr
zs@u!B&vxT(&WeVeb{@?0RZNM#P_(LL@vPRAKWYsU>D!cgvrzIEHR)x0<4GGbPFPYt
zf2XqF{u-y6PtmTnxK_aIRmXf~-)c+#qEzLXQ)9-wa5GMRGrP^j9$rD0jDn8e@Qm`d
zj9caRVO7q)QyP4OhDv{hyhF~Evh8tGdxe<oYQOFDq_wVdho7G_=-$=yvKn?rx9ua`
z&2A!`EM0kI-WJ1llE0{zisVBh_tFllx)0@BoeT8o8|3@ms{aAE;W=s#H)Isf9{pUg
zeEK{6_|yAV@cjc-ea;{IRhIlkN&ce3!s#>6SX^%dY^?kD9hIx^zHIuV>u;x@PdG07
z=G4r3#{#c63)?U_$RB^is(MF_<FTzBpOxLYpf^%y>jAx#fL6&(N2jdR>TCKcz3E3$
z7b{bh-%Ram9T>lJ#<_%xF_oiDA6VB~^!=biG5^W_qTXN{s`0<{RZ{g~65kx;wkXR3
zG1;ogLdEalsAxN;4^OBbWr&ezD|9rv3#D8UdJuI)&!A4|C)63eT1h5zMa4H0-BES9
zOy-H!LHYJ#=w@^hdLH#dZ=wO{V>AdYL8qcsDPvDZx1fBlF?1Sforx|$XQ4~bx#(7O
zKDrwXLyx23sOXy&fr{g{BP|vEV^sZS#BozBQu(MsWMk<1&<>^DI+WX&Y&<H4y*QyG
zQ5Vz^bw@jLoL;CEI!UZYX~+-tMt#xEXaKqw4MeY?6xTu@qH|I4y~%lKL(()KZH0!R
z1JQ-(6qL&%bQbz8D#lqYMwg;X(6wkJ8jD7ud(hSB5p*qj6Wxq<$By5j_Gkj?f+nJq
z(Ou|Dlxq6Wjp%OlJM<W;j=fKy+UO~?Ir<|y7)?V*q3NhMdI1eaucI%}8>kMpy@@tP
z@1UmWJ#;jBA9X{2LT957(Qq^m-H$#&3(<U3j2C;3{(=^uwW{##S+oxN3T=dPZbO@)
zZ_&Q!dvq9Df=)+&K^LJk!-eifKcPp^GE{tDQ%3%{j8;PLqH;7Bt%;gfCC{KPs5UwY
z)kQ^rtNN(OSI$t;XGXS&d6BO~Hv@YRlju@Y3pGK-b=4L%MBAfQs3|%E?TC7yR0)TM
zpj6?7l1F4_sMrs$BwzZy$V51?AIvS{RZUGuj~;Uh)EI4wI-||dFWXo2KT-8d`R(>A
z2`AFG3MGxQXml33`m60L`f#ZFcKmkx)`Y7=cw@8)+6EnontZi=ML!F1E&N6LHxf?l
ze-qjY<r)f|if%y*IM#n>zjQ{0<QGVB<veFI50RkqO~>*?2*VZzGsqWU16~jUv5*Q`
zPzt&;u@%@r07O9&WIzFEa8h%)!4*I$Xmw-UAUHq(L_iEALMmiI0cdoW$t=MUln_sP
zG9Z)r63{cJj~%!}B&0wdh`J&RaEAy;hHOx$P0|GHAp|x<8WezLPqqOshyXD@QSwp8
zjbJc#0?9`m`D!fJ3jDKu)aCQc{H>q5i0X`)okM=+Vc(6Lv=?*^<+?(@_^kV_zq(AW
z@osgwp1Ie3?YAzM<)VLR80$(GaIG-^d;aU9jMQWrJePzYJA1HM&c(??QhYbsa3T9e
z?a)-z8O=aT;kQ2R95qNU59w$$9!`SzwzN7Aw_;R*nnEyP9Ks04!!8lTH>K%BEYpHu
zFyvU{Q87k4pYUnu*FNs@@V%*VtFp`ltiTyUAR44evVdd($pVrEBnwCukSrisK(c^j
z0m%ZA1tbed7WiWeQ2qaB{{NEIXh+bZo&rw5W7uLKlU+tL;VRsKFVj}m^@INKWr}A$
z0g9;HeJv_@E2ix%^VX&g0Nn{QU?zmX9GC}T5Dtq$OiAc&*bB+9AH?*OG(3al{9XyG
zVJ)l!F%_`xCA<PLiLr^5&C17w)*(%w2=}=ntXMyZ`7-gl5!L)q3FIKg6RV?@p$Z6p
zfmKm4c3A_h2G!vdzil9q<J$>?nBM?#Af{oc=-WOD#=uCzjDpedWfIG+;1e{5H}Dq3
zWQ4W`6KD?|K}=<6CE`$rDiv`JU|E0W2UYwY%<pQT3-+XA6gYq>bOd8)17hlgnn73S
zUa@QpIt79%evd;PVLVI#7jTE2#D51K!j~zDc?;I{0x?ZQy<u|2?;6-n6KX<x=m4F-
z47!0i^njkw8-#uPh<UUhY6Szp8U}+63<FybQ!TVMXh8$ehlXGPji50!0R=RLZN%FQ
zeSkJc4WR|JgjUcR+CW<nlQyaYb2*;*un;0(2`qyZ5DjY}2G&C|amS(?VKa#7>+R|g
zpDxsedQcz4I8HHDBM*x)vUSPBRZ%fkSeN-4s2HDGkNHAf@-FjYoWC}|#n|~(dgWu$
zMI2&$_s@h;W4-W4p+%VI{C)wV@3U52wuNfoU7x%_!;~2BtwXpUiA&gCt1)pyZNk)q
z>QDu0fhL%;E{ttu%r8PKp(6aOdR&w2rwocg*!u{Ger8wsU5PMq=Ks+?NUzcWl_eUX
zm~NwYE9M`fk1OWYI97SZ`4QnXnXmoT@Bgm<QC+sJ`_=Z6zfszpu=N*zqvHN2?p@-Z
zA?}|-h5u1;?-utiai2*fk9^Gze(!``kOad2it1ePk1VfhbKQ&<K`98o6Z9*P9fmv*
z?duji1fw7uG^wLE022^x;aXM5```{r2!%+9fgC7+FTP0)s3SK43&^Mb+k|><3$O;^
zpVS@lM16M+>fXT;A|M75;V{^1a&Len!2N_Q4@_zj4_JdU1V992L$_KyKOqvbAQuXt
z1k`JDUjq~92KL|u0T2l>kOG-d019mE1xg5mD98mPuFq~@1rd-AS&#=&I&2T6pvk$^
z18Wcsyh)G=rJ%`qF#r>=fJDw~E))UI6J%NtqfgwB4S8U|v)35{AOs>I22vp%49E{A
zAnv!~-9S7?#C_caEWna`Ni@WRCigA}I0>1M0|lU=AkAP10T2(VPy|LzIc~6mOfYCh
z+|UiwTcBVK_7DJ>kOTQp3|cJ-50+p94xofkh=oK*flMd>$5yn5Ks4AJu@2H86AHkg
zHF*dEAOvC{1=1l4a-kG7j5!`K1q*NhB@}>08`eP)IGXSt1Hljt#UMHzXo4OXf+aXY
z07OCzq`*nY0nrgA7mA=1G}?2mf+<*mGlW2TN9@swJO-V?3LGH>A|VmdK#X%M0MV&I
z4}|YpYjA*QNP{fMgA&j)BMexBBLqMw#6v1%Kpqr>dKbcjA((<C*g+^nLo%d84v7AX
zTC{nafFp!J5~PA?4;P&*I)gRXgFA?}@WYS}q8;3hw(iZ40Xa}&&SpIb3rhInTQ|~z
z`~U$x2@j$TThWW{!5LB@4~jwAn>0WMI9qc4!Dh$<-98)}==LRD-~dr@5{f|9k7EWU
z2tNYJkP7MpNej4x5@H|&N<q__b2Er@3`Jlx7+XO$<U`mH!a^x%+HicfoKJ{_Y&&c?
zoID6Npgw|muz}o><dso`2Wuz-gVER<azNognjqDcbs%$NTX(K?h=G)e>>o-X)0?;^
zac;o|LLmwqd{Ed7rM{deKh{AMxCe4RAr*py$WxF921?F1L_iFrgK++#1$xu44}?MF
zbhd>IFbHP9;0Ruzgiwft7>I{tNQHFBf?Ozo63Cx{t!AQNG>dBke&)U_-rvMKy?FO3
z;J0|!>xK%yHl?U|cN1kG@jfWZIpY0Knj{PScPv2DyUg!@?ElZ(&s*v3;)8p)z@Wc$
z0vM!p_x8uR-LGL(-T;MvJPU0#XRcek{^-l{aDntihkCmO`Um-YDiuZ}S}SY=l-|DH
zGx5!*=;!Yn;O&EVvU0zD)7+d~l=zQwohrQ8)x$Smx%0BGmvWu3+(qfbKEC++Q~BY-
zt(Kq5L=RsN;b=;PA)SBV*Y9ul{a1`Vb9s09PxFUk&GSnk`MK#dGAP$#;T-$nfyt}S
zi1)HtJdYLf4SvVx9y-we>GR1JPyIt$zKr&qZ(!*1aZ13<(+{J4sycEHw-Vt-#9f|}
zw&vC>tsx7;eLS*nK4~=bW!sHI+)t_LuJ|;{pL_hAt|DAWZ;wqe2VN@|cNlWBPZfur
zYVNB#<@VX&*}RRd`+<^inljl^p7#oQV(vShPD9LZe@?M+xjot8Ops?<&;pah{m;ke
zI!sRq;B~Ky2xpLzIkV}qG>iY*&yD22M)F_t&-7n&Zi>jK+sdk1wM)9x=5m^H<xwO1
zA&v!OF5OzQZ}iV<J{Lb%+fnrI<G<!V%`eU0>L2EB^<N|Tk&*n!e9WXwrg{zzsoCRH
zx97W-p1)`L!@g>7KgVCZc46<zo8~s}sxQm=Sc`Ib!_MOVa#4S=$9H|!M41|1Ih@>~
z?aOy3%(NV}=5;H57Z7M|Ht?<FA4c*Iv-qy$AI9m)+9o0UEPgONQGZwA&c&CS=Gl&)
z{ds9K+7qeQ!p~f-I&<chES&$oo!w_;l<nvsySB|X1vej-Xnw3^#Jl`Gv@LSYDdesO
zl}02cc9>_jGHu5MJ@a-mA5ZvreAeRZMSEvQOeq~|$2d;a_1mOzw<|Mu750_<!%T~l
z{KMG2^>+L5*xsG1KlE4-(#)W5*C&tGB~Fk%-$WhjFzPE6^5;*VX+IoOsZjr2SmKxt
zEfTD2`Iws)e%#b{P_@?D`y!~bYpKdt{i`PArWH48kXW;BzXiSZ<Dy#4`f-|7!&bpz
z$JBc~9Fjo0Gxcu@`H_i9GY2miK5^XHCR-MbYq0Eu`Dk}DlkOhV*JTvizpnR;dN}rt
zAJv0ZlH;qnu5Q)l!jn=n3){MzG#{L=;iSKQN}Kj&cHdKHdz(5sg*;bw`e|Y7RSjM>
z@#=rp<?;vHdAfJ<Z%F=OB>ynyR?k@bKk*Oq_xAfD`E%L2u+|#o1#|rcJ@5FN74InX
zH0?Ntx_;VV6!QBI=eE*0^3-JeVoU4JLEp%)PQKeTeW&@or0sVvH1q6Fy^pS*2zPAn
zpp0<~%v&wA8+PiROK7F750CzoKI4`Cz2WoII&9oG7eCFa`kaLsbzTM-t*LSAL&%B`
zOV-REH=y`%YB$NB%fV**ZH_1Q-4f&-{&Qs93%hBL^^5e}H2Q97b>jF6^{TYvcn=eH
zmi)O4dGJGXxvp84eV$K_Hd#e~A60qg?69RD{43ABpQ^4rKFzVv{HNKE2DfQ){_5H>
zK~3LW&7*y<nSrohNi${3t(D(C=s2OES&-G{Rh>*nZTexRbI|wOC4VmShBlfNvb}Xm
zqdqG$^QJd@?Rs+G^=2QUe^_I;mo~{`w0kP#!Jo!WiQk+NYoI-0@|*bw%^M#`u<ok2
zW#GEgzUF(|zp06D1yw!k<H<p<lJ@UBFvhj<TFIYFSh(cRMa!b&nE?AkI{TBhuP8Kj
z&7aW6sr&ZE^bNET`Kou5IfcJm3s@OGD1E)LB0A&8pCelD%RaUC-DTy1=hut~(^>Qt
zkUtB1SY_U)o=+`)8k`(AHEx{kUitf*lY*VwZcSR*dH+xvrT*UEdx)w`Tm5+2)IkYR
zkPMkn47w9Y8`y&ngh4DEhAb!mbtj&uU<%gY2ug^Acu0jTC;)ZZ3l(4i_7DIOkRc~t
zGzBuD05n`k8(4xpctHdtK?W3qt}E$-*juC<(xCwKvgrrlNqnsP+P^|HV~|rp<!3=g
zx@ohQ{3~FH-kdiO4shZj9keX5J$OMhoP+|<>%(&Jfhb6ZT+r&va&U)e5dBs1LAM|0
z8+;%ZPC^cpf&uMi7T^dW5DTf01EpZlpY`AfArK3xkOQ&-^pgQ=NQYb~1v{RHqW?=2
zq(L$0Ql88i#ClK+CY|66p|BZFLN1hm9?t?xaEAzphm%kMy5d>|2MB?9NQVN@8p<^Q
zcHje%kOb+F3+lY%7=bl-K`6vPGNeN;l!5_$ZaRYv_&^k-Ko%5$2K6aMU=8jN0ZEV!
zc~A=YK$1B)kVe=HCm|O!#*jv^0VTvjD&)ie75@sq^{w!=Uxm)0*h`&bM3eOB(=?BM
zMf_H;j6LADz7&KXg}>%QLHJG(eiQzh&xBO=^Lu_1gujHp<}2ZU>L-DmElrXIBnwCu
zkSrisK(c^j0m%ZA1tbed7LY6;S>SgqP>H2wWfiNms54;pA3gR~?Cqa1{#NYww_|X{
zcz!j|(<vV#FUB-V<8sLdb^bIiR}1@yakyd(?$={)#r%IY{?;8^r$8<gfhHNv27*EO
zsJ4<*j|7_`8N#TGNr5!zOnr<yC?Oq$Z)XkaV<I3^)XRV-^)H(t6LP_jIu(0x7g~+5
z5CfSYd`+5y_&!P~2tSj#Pz0r5Rg3y$h=&x&2F=>kAA$|!bKDB@g*~`KENGBlY`_uR
zK?$KC#>2)!H|!_Iz$U{<D5%H&>r=-Ek<<&NK@rFrP$v#Wz(5sQbR+83pa4oij9txy
zT!?ByT^{5?fHCVJ1;kiR3lq`<UhUaGBtcjQ;(`niPNO@66=>2nXa)9=On(#&+NL^#
z6$szF&JX}5^yLzMcw-<Fv>4-I0X7f<DUb#kJ*ijh#W90rZ?*+dADjs?OSS_8FoMot
z2{zyW?qE+HuvK3aME!3vNRwm%$pVrEBnwCukSrisK(c^j0m%Y?e+y9Dl1=y@kN@}b
za0&R!asPfE)17?%-90LX`~O>x_iriF)c&Cf<;qt02$MNExwr)?ohJJDySn%|eK~${
zwyMZ%w1rQq2{J88jg;x=Um+#~5JgjpgR(uuvw5~$#wsT#5zlYk6quX4PbJ>+#pOG(
z@bUMX*vs5}nv2g=58`Ny=QbnsFDHfNJ{Ic8w6#sqIQC_$ru6a-!hZ;<>r#;}hf3vJ
zQsk70JRypvqFyAkB3)CadIZk+>d5}<{mCpvar5iAODp2eU^&He**W-y@~mu5`7sB1
zD8Gui{8+46{X3H?ZgDJjtQ3CeY}G_g6E39W+K%j}1a`4bqdabwYim=?l_|ki&8dHI
zK%f&gQ>9O&u~>v{DEVtB&97o}>C$uaK?gQu$ls38IP~KjqqQ^mwi{)0g*<bL*3<Vf
z>kHo(-kR;?VB70S?KhVlQuVtI4XCTHm$J>B{M%22laHKPCcoKaS89BE!XCpNuUu@J
ze(+m3c%u2D>-~Jq7aXL%NEP1#y{ewmKW?3t7ya_b^*c{BIlken!Pe`O4=%~cxaM5&
zY&yOctwemy8pQ=3PtqOcv%dAE#2U-@C%nIT^3>uJug9($f39h3%>wcn{i76ei}1V4
zUgSJ%sJ$(<n$?X5k8538azUd<?{OaXts2j*agMqxOX^n?^1NV|X~si_Z}o~@yl%!~
z{W)HezlQ$8F00#KY#i~f)ll2#JC9j+*Y>SBXYrJ8Y=+N{TXx%cfco47nQW-)e6+Y4
zyJ_9Z6=qLgABdb@Kjv<++MYQwyQQ1VM|Zxn)@&Q+cN=v<3VEbiT-&m5huZu1x_s?(
zwA+LD`9sRirk`tkX?bB$yE%KB%4E}2@s(&fUz^itgR^Hw(V!0|H9l0jJvV!(>xt43
zd9ygT$H#xfCnxnw3i-gF*Ba|+KT1gIxNrF${rN+a!*gbzalJa?S;npnt>^A3qMl0?
zU%Pg#hL8I^z|ib%Glk@@;h*WRA(Lkw<2!53dEKybk=lo!3ubS%&FgG8V`kq$BeLH%
zUYS-owZG0?$zQ{^<WsZldq+HbJ2P$jrJ6quS$Fix<Cn|v6RWx|r(2I)*JEGJ=$I=@
z*T?Q@s~h;yXi?YDo4O10@0=TJGRd7fVbyrTm`7a|9}1S=&(_!#{aX8Qr|~tmerh%#
zVfQZcT_(9B<+t&htO}>tIOEf?1J$M|YmM1|r>)PThat7%GTRi!rZx@oKW^A^H$HSb
ziSstU-Tk;HlV)|Z$V|Gde!0F{fpuP7>k&s5G>hv{b6#_KZT#b^(pS1*$LxDsc05`z
zv-;6GO<GLVnpyDD<laM_q$4FC5)!)4;v1K$_^g||=4e!sPbt)FvdO#K=F)<|lOv1<
z9_U)7@AD&{{67cK2a|UVh1_9L=kSx;wJ%ivS?9{fyt1>~woR<k-0{ek39D}3T=OP?
zdx2=LQOJuddL(u59;f@w8AFX{2CrU>IJhwDl6s|sWgq)oj$6~FE&ibCbE}a5@ppw+
zsnT~Zr6fLO`+=Iaug7%n^LFJ7XP;>YZ#%rOF)cWkv$@eG+83f!&zV2IUlk7$`~BnZ
zuOCyz_w<+I`afqrc<^cXydILjhJS>=1|NTMJ`6)g^lR8BTz~r(*IO2GH+^^adLOnn
zOZ!2qIlbK`*6+==(PV%KcW{r6`{)POWt}3Yg}c1&_%yJ@Y|YaKYROr~K1XynjI_ZO
z;6M>BWL~$FUX{WPb3f_!co=JWf7~d$?{Z6mMtK@fzq?y+q7MG6dFfQh8}Hcq$k_i)
z%<dWLE}G}Gj4tfh7ubFM=-3_Ab!s-$FCg48ReVdju1t5W`@T!R&)P#1v*vEOI<?@|
zHLG@wWo?$M3cJ;vb`&pF`gF5A65myN)7{2?<h!{#Ye$ui7}s)ltm(Sz?{4?I@X?NZ
z+K)CEg*+@YO!v;4dDEO4JB81>o;1BumfnJ;o3<(|H$Jm1c*DZue7jbazMX#hin^!M
zdKdXhejOyg4lRdCejQ?l#jZARk;%?;%`vWOM4t;2T^D{neRbEAlIK4}?|qOlb%|}(
z8Ke8&<K{bz;eA&|K~*9D@$HDBH`8Rh*Xd^+J`mST{ouI4rA0bs>P5YR>kcR?;+a*o
zy9jqB@sX?VQEjhvYqLvljvN26IQ7-i+_+nL`ST>d4g>l~ejQ@l&s$d_zZ^?Fk?MWT
zVda>bCwBNo)t`Jbbz-#5>JM|4P25)h(Z<^!gEKyv<<+F_NcBGSxTMk>qxihNclK*U
z4}E4a#QbsQh!;(^w_Wahr)u*vFSGGuL4}S&UiFN&*`563u2J@~l=oNrdA+#)eZ$O=
zN6m($O}8)InK_1UR;cpx;w!o5zB3;>_F;?OQzm|BQ!8-k^F<{czrFnI#)7nQ^~d>9
z-cp5om$@=5bbhnAiHeT{9L!gb8?!`N+-$IIe5X;LlnYzlpkKmcRXEA7gXGsi<iAa+
zHw%|~UVarC{JP%3v@KJoC7j+akDv7}e^cd&YsZEz=35biMY#MWt?KDMNVyPtC1C2z
zvcBW`%xb-`Zd~A-A*+Wx{C2++m3CpO_w3V;S4@2DH+%DwJMSEatX>rSU_hUZyKZl(
z72Z4HyXEtm1o9mkRk$YK$1ieEYp^1EO2`Vyufxchd{0MZXQxpCB^m){ucn@yQEk5E
zi}oiUo1AoZxjDaV`i}NpI)=nhFRFT<JU8iZf}4KFUdj973WwaedglH3eHLwt*Ed@+
z-SczyxZc$1T~)=`dcX<?otabjhF`1Y^~oYV|D#S&|J-LgrmswNX>sQ0H>YK?D_z9-
zmHawPYI~$=kFopxTWAjK^kE&}#i75ILLRVNyQQp$z0%_F)i~29OAqFhN`4)LUEbub
z2s7yQxxL=pr}E8jT{E88Uzq<SvU8W1WWTd>HwYj5ujrqqkT-gEsmag#@-FWP@o<`*
z<XqqTYW{44RR@N@_U%2qpssg5&n=amlSin(ll(diDzz(_>6st7UG(3hY>OWiJqJEU
zvFPzOgQAmd%{sj(@Evxxj)mTu*-Iin&+kwiMg5Q}+*3!#2Zojb_bwkzUs*FNW6h5}
zYc>7!G2L*$$*zO!o`r=o{+RY1g?xaGb^pGja`oMpO@DO#?ey~r$7SD~npy8y;Pqx<
z8wLkaHb1I*FV;97+uHG2*_{h|BXzbO&`SwumE3f6%1W)irmxbQe%#8rm8sedOzmqO
z7{7DIxrB=`m7`4`Sl3$g{h&iJl?ECuP23u)e~-qi?cKzFb3bf!>eryJTZ?-?4E7z?
zy!En|8#JoC8uZd<_3pTWr#0vET{2ZYb(c@-N4xI4Vrg@@UD=WE7Ipr<(mMaD>(!d>
zc|Lr_+hW6y^l_{w;;TFDQ%bG<Egrn>{O#TLH`?_%cg*nhlcsq)98Km94y+f=``T2M
zU0&Px#zs6*mfE=dtNL|#gQ-oSqCHa8PMN7G+BoTB3u0PI_fFAvxeOKUmsD4Ve%Y>~
zy-<8cO=eg5&$nY)s5;BZ8lk+7%4mvIZO1A5(iSMoU{-7=!kLKWOjIR@YM`8o&;uyj
zhMq$kppk_APx3>N%s1~P9~AUM=DoxVqCxUOLH}^xza$?N^v55|O#xCM8)W0?a}Ev=
z0I`q(#h~R#J_38lRpU2(2dqE|n@3OvheYNJz>piDGlUQ}77jxe6oJ-w;+aKXcKBO;
zQ2agoPy99C6aSljC$hOGDY7feEJ2zi3rH4_EFf7xvVdd($pVrEBnwCu_`hobiZ*{X
z{{IBO#W&VP|Lp9#<$bKbjFG>^?_E^d#DeHYz7aOTX4nE-A(d^vL*rqR0ri032Rrzk
z1iL}>ci#)*``I_^Fy5E>eQ*Gt683xa5FCM25dG}GOk&%cq+=hINeAG2I1EpyBof~b
z&tUs&=na<LglxD2zp(6I#jina(y9YrruW$B7x*&iaEx`}%k*2H29o~*`s-n@FW(gx
zz6<_VzXeovs_HyNoun1mfFlG$7|5t6&;&g&1XHj9@lA0hghC`_fv8g`01Z)p0G1%e
zD1<^J#6SvULLL->`2M&Nbb~x_rXn;Jk{}&&ARmfBMsZsUgueuP5Iz$kAR0D95~M;N
zSXW_xkOo;$L|-veDpei92aKrDb$~Ds{wKYv6CM&luLj$L10+EX6o3!LN`YJ`f-w3c
zq(B;I;6p)to7`F`{Y8Bs1jP5o^Fa8LFa&pqfi%bh@r`h62!TjQhCI;a92&w&DuGMD
zgo<YiP(m&kQYqXSGC_}uVQX-JFs_qq$Ol92X^s#9F<{5NBm!c<q&YT(Fo*^VLu>%S
zVAO*2LkMV?vJPw@q62A$Jdl~Of3O0BuEYiI5Ca*I1M%HaC;;mooFmA997yiXae;;<
zwg5#R&JTD&B4j}xh;KXFfcUPJdq3;}nUHP8w*5JF@PZgfgcLXl8ITQmkTrmP3`9Zr
zw>5=I*k0W8jZkrqt%8d2Khh*wK(c^j0m%ZA1tbed7LY9P?_~jX4(IPZ{@>Td$H(8z
z$<-yO+y#KS%tBkunfFv#9bBB{1!(-LL%rPs{e%2Hl?tN~trfNbN^f89ncjXA75)5u
z1H64a0vWe%sO{u5&CSV0sSNaXovQQ*q92H%wwH%bfJflhOT}1wLv0tO5Bm_?{N6zN
z@-RV4cUg79jP~|(_n#gltHt~P|EYfNE=q5Izw$7B`VRVoFy-U=J64RJ*R52ZFJcjj
zPqMWznlfn7AWe#lmQG*UL^W2QSMJ}N{%m}^s2{Oa3-X@nAzZ_ikKZp}=HjMQIRsFx
z!X9#MOEvZd!-%!(V6o5gG5<#BUR6A<oRi5iG3LFNth;vqiZJJz$@o2?;&&BQKObpa
ze019yp)Y3Z`8_j}#>KBblipe;n?>1EA>ZJ4eD0wG?VmoMZ1L1Tq~*(K&-n(1E+3}^
z%sl-t+NY``t`;eWD&!;LE>B5Yb8D8?kcHts9@#gaG@ALc?ZzSQr_^*;d>Z9XxpEHW
zVaCz*_Sh72;I(pbhaornRB`C3=Dw;^Zl4XF&D+?zA1E0|ox)Pexe9q=?mL-5@DTIc
zpHpmHZclbN6Xcl|w7?{B|MT&=4%1TtWU{thL^y+#%$ZG>rCH1{OX;xBWk6}|o~^Tb
zTwVFP^_a?yT+^10#;*YTR>)Vr*83Fdez$Dg;N!LX`=5<m8~B6U+Tp$CyNx+{eNBQ<
zsZ3Uba<Vio-ucLx<`WEUG|yJQa6L(O*NyttPQor9l{2EM8ASRG%TBqHQtRrl-PflM
ztlOn(|BZ3?-y68UETjH|It|XRQs;qP`-9KBYp%I<zNGTjt=i5TRv-S9qO5HB{@dGW
zm#N26#W!b#c_+)lRh`Cc-+1LrVo-XQj~f=ojcoCLwsrQ#Yg<3E-xyWC@?W~+uGbdZ
zfpg~9s9fz@!`J<f&Ti2ycj(fpjR%MKb?UH9CVONq_S-6ISX8xc%2=KFt55svz2V+q
z@#w7s4Nu*>?sMI=nc+WkTzt<!k-iDx>oPX~&?aS$?)$mgr8-mZ4!;)C`DC54Mk_bA
zufOVM8);m;G%j8m7cY&Ax2Sewy2D#(T)Z?cKB4Qlp_a5^#879ikb7igdVlV0)?j-<
zm6(jZWBuh3ulMTJSiNEXl&Cf_7Rl=<FZ2}Qjwe*TYTM4TQqRsdNBUj7z4(o9e*D}X
zwVjf@hbmf3(SJ=lqUw2>P_x$CE6;r02KOmkzg8KmJH?~K!{@=v@o#&awvoogOXK2u
z8%pEiOXrk)K7Bc7W%G=}u_^Dzey%gX`@r78A16GX?@QUp-cnp|vG1S#bpCtC5VOYN
zWn*I=xgIRLJKUgCwOz5rlU<YVT&66erFt)(r}4RWwRO&Fwq367zteZ@g89#~yWj6T
z{Y916^NiM4S(r}wNEP3@PxC%V<Kh=aNaNxQ-;FQRcvZ*A^c&r$>o;GFSUh8gY_|Q>
z=6%o4p0JtxSErlEf5Y<X?Y}mx|CKY>9UmXC?sRZS=TGaquMY9NHL}{f>xVy3_K2|%
z;rdtoVbEsvu9~^^CuVHAUb^t|qxLf{MMNe0+}O3W@)0WynXLUF5$;Cdin=48xYvKK
zJXrPi_Q|iFSZ<m#IsEnMkV`KH>>m_MyZi!GxqFh<vm(23-};*Q#`sP&ShZnpva>=b
z&#i;)`yVp(j2F?K?4XJ-J!ie)+SEPOqrzTjE8dK9PM9i<ix+m5#>E#OPVF}7WqadE
z8!}E<E|AII4HkCUU*lBsDcaQ**9w@u>X@(WTkS=&Zg-7sFg@x~^X#rO0uC{TaEJ&O
z>ztYu9`@?l<rkTwJ<>)R-QRjce`xT%fZdsU9?R70o-glDMZHChOEzcsDlX^r%&Bzz
z-mPbj_b1$UbR7I@yCT5Yc&aomKJUfp#*>~+^1ih*z_aaq%~v0HU3tE6gFKJ^FDg5~
z$b7rbv+C04NnLKNE*u<bdd~A$yQUF8rF`d_<exJqgSzHrs`tt9xp$&2ggUl9+_FpN
zshY-fwBqJo-QIG{yo(2SYahP+tR;R$RrP;Mr`2&PR<k^Nb8xk*K|i(fe|1C}7ccU&
z-h~nB^+vB)klH1-`m&K@bniM&onCd^sxkF@pH1yQW~4KHkyQ74X<YpN=|wF+FV6E@
zn=obJmYwurQsvX^_ZwwrZnxiR=5^`3d&KtFRllEK*W}=M(<IN9Y7H70J(0<7tHK>C
zG4FmYyHnpLWgkm&_lGu1&~kb1@?IJjFO7>&KCZcIh^)b<^lEk;PR)|Z-f(ZDnW3UR
zk3N~qi*f2TP<Id$T@O{`;`LDlzv*@yN^xD*6m>>vY76y3o1^|{D|8V`^GfIn)EHfj
zwnNvV?NQO6^FLvHd&u<4GW%@$e1bH-oj#_$=*J1t_;&iQ@-8TiZ>JyiSo-~fG`^j&
z`Bmv>O*z#BEFfzk*9v+P@<5#%YcZ-oO(FPxdB66=YK#{FJ#Nx;@Q`UiFc_-SKN}U_
z2FxdX8kz-q;cO3%(%5zkCQXtBBnwCukSrisK(c^j0m%ZA1tbgnD_fuvi7%tSrfQ;Z
z>~dz-(_dWlUBAtEP|@F9^dCP<<(23wE{&n5Zw>994dKhwgn329@4DEnK75%vF>hA!
zyFT{S12J`FS@(+N{ZZ?R`C+JC#k@T_vSNM=>R2)Fih5Mci*dW^6>*Aq=dwJkVqI01
zYgDZBVVPgWauH6+{Pc?7H3(C)BHR*|MOG~TdyS#DV}GKKR0&k?$&A$KF9Gf##=@Tj
z;bTvHC-AVG@;B&G9v5Zu5-_3;v>POXD2C^QMHSklAOuRmiu!;62nAir{h|%q9%3LJ
zvV~IaF9l7?^;V#SFJ=B>=8dS#wFh@ds>L>-$yjv*ummN<gBZhZ$2AcF!rw&(sOzwQ
zNP#qP#)gTI4f&v3pZYuqh7>A_3qXuhH-cOc^$|vpN~Lig=yL6e@#+~+0vfcTABIxU
zRB&9ztb-iTGa=2OgsArHAF?2+193qy7<DB7fDd%;j6w)xGhW@4Hhf3$0ZVg^3t~X@
z;ZBB=Py*fPJKzpVh=&{~fMWWZ+4bU>!K*jhLL!Lq>_(Ps2UcJQj^G7KaPPxD`l1jI
zCqd+Aaqp2P$pVrEBnwCukSrisK(c^j0m%ZA1^)gPpm_EFG5+7p-*1{npwcneSLx{Q
zI>|H8!_mdpy-R0D?;tnjjDYgt|FZvt@&AV@%ZkYdG+`oqq}&!7Rb9p^CpRy?I`55#
z0slbN`2TLK|D8!S{=XJu{ViEp{(XBld?09RTmSmo*Cl8&<s?}ZS(ggm13s0?V~R&~
zU=v(4rEPn~U+mjSq_43|N6QQSok_L-dh9QNl_d>@{{h?vxcGR8up(W-=-25A{q=Ww
zx`dwsacujW{b^gLsR10ghbqnOD$*?c-HFKxguN&#s_d0pk>-jFq)Mw1>wahY)m9wp
zpQTCczdVh9veg$q4O$|@GnugeR%jjc5)oLgEVos~et)%7vMTgn{Od!Jn(hPU+M7{Z
zH8quOPBQ<sZPI`JU7ikM*G!iE)~>>40WAMLn~7~KS=Yiq?8kMgrzcJ^m>RP@2E9z$
zZPnboTmtb4fkO;&)rs{Y&M36pUqtzKPHs54P?oO~c4zk2IGubv{3a^BROhH~#W~ts
zVXKye!=<0-$0qY@!@t#EY~|zO;_f;_>EYz*5~OtU_9F#;E+UKlmGh?fv-9Sytx7*W
zEXwoEZ*3#_qL6%1j10=PSUAUicwn;Ri=x#~+vhuvS$Eg=tvP4$ly7W?&yHJm+jxNb
z+yt3yC>OOt-r{QPrgbY<m_2=cAaZ*Bn7hSld*;aOmTod1-TBU1vuy`uvTfAYDddr6
zac#@K9cu62>+-eF(QXgo=MO16n|`kGrR9Z1?dI&^VxOjp?~lKE-jq5(g?!-8YmIfZ
zA0;Gp+_!v>{`{fI;W@L<xLzIcEMwP()^qn1QMajzuU)%V!^eFdU}*NXnWEX_y*XhC
zwX5|G-~Dj*;k_50D@+c_WF3Zz_+n37Tvp}Dq#4F%_t|&obMJ}di=thBVV9(mA4mEr
z&7Tc=IjV4PUx)qkuOxQ7ex!@(#C>DF8@=!9dYNnm^{@)L#=WwI1);Co)b;9m?6U2e
z=+Mub9~o=hxgT<B(&dX9E3e9AQ+Sdn<cos_ygl&C<`$o{q8H=@%=ux|t^7BOrU!fM
zXyWr@z4aerC0`VhFAB*Qh2)FkALolgt**Eah0l!N*reIKp*P%y1&=o!p>_RSQgt0=
z{z#L&ci}tq(=IaBZ-5AQaF34r=m*wiog$}&yS(oBG_b^M&C>>I$yvreM|3xgwBcKf
z14X!ydEHWaRSGxE{iNIDVXWo-aii?M%Pk2S<!L<q?ryz_6qL+p|5C^s@7Vgt*#Aw;
z?iuPXn&-5PF6`JB*nR!z*d5h%YBtm_Alxxkd`r5nOn0sOzKi6GLh?m1{QQ}Am)D$n
zy8P+7W2N$^`xO_z&5xKBvZdDRc*;yatDe8(T`~^_4J%q;Vp_#omY><Mx6ZXV!}NW}
zs~#wLbjWxW<+dO#k^c&B90~fkuTRm{oZhK#o?Z4$e?P}4qh8b4+to^rI+X6ZNjaXv
zu|lq1*=*l>XUP|Z<clJHisXx;yT|l(8HM(*>phdno^==3N3(-flH;qnu5Q)l!jn=n
z3){MzG#{L=;iSKQN}Kj&cHeUi-KMXDLY^x-{j{+4ss^u`c=bQ)a`}VpJl#9_H#VOz
zG2Z0k@~mGb{U$6$xX4qw1?$GWSUldg_At-Z9T$DK&@-T9ljMtHs=MTiqWUjA@AX{T
zqVcS>iR2Y~`pqchni>Oor;cr&xTxJ|?~UzE@9AFZnG#=3o>#h~yYcAgwtJ{|8!W<Y
z-xTnjN%*F7qr-ggF&j2-#DQ-{HnM(IbyWRsO(UcB-j>PE(AP#GcRSlWvDNEJKMYq}
zzvbN_tKC@(E_uE*46gL7$N1DqGav9?(oYp%%t7NbAN#IYW6+@B?Wz4w`lNLIpsuig
zo#1!;Q_UAs3bx2(zN&EZk7ooQ-&MDlai8tR-JBH-JMBD}=c||!eW7So%i>wBms7tx
zNbFbgMIrg35c%L>v;8*56Z>un@(%wwGVX=lw8#2IdTtthx3oHOe1&>dKbg#Xm<V@j
z%$OH$#>sDHx4GEEE9jC@(D56dQQnqutNcE!%Gq~HgYSvZj-Zft$eB{MJ#K2R5VKwF
zx1FA})^+ai^K%B>yLw($!|v#|eT2J7#l1o<OIIG5x5coX<cs2^BKgqBy|fpo?l1XP
z=K_8D2Km0X>VLp(c#hh`4H<>AM?Y6ApZ-oi{`9^Tj4$sh?6+*s`(q6jz75MawRaoT
zuXE|hoi}`A9&Zd9(8{79sYHLQOx96l=NXfmwG3SwRrTAjBMt1^&Wn87C+eDZ4ed><
zPH+D)qRsfnGTAq(aFQ>I^wn?7^_s4BvHVo{Z9HYht@PJa$PZ;GD=+D`WSMr=15pF+
z+di7VQ}RV2>|$zP>%jP(GtMPkjHw)L`oOx@qVESCim5cvXldfsQ2l%KZQZWQSGgZH
zI`wPN*R9399|rplYu<X<%MBV;UJZKbvwC-2!PA=aWwO_*dTPlR#qar|z=U7gmQ`)e
z!WRWaPnijbN%)u$?W%_8XtV_?+N5dA3w?uHLPh(qES`C>J%2K?w`yulI9@SSJ}Jhd
z#2e~^wnIhxGTn=Rji;i`R@IjK+jx8lC(^;=B2*6zK#kELRJ8fh2C0fCnfZz~SXJAs
zh(~k-7HJa`VM9fGttHCqzN{~5hxSJoqt@se)CT<l<<S&+7qvx;P{M}Rry+hg+5{be
zHbqCGUC>de1B$IeozZcq_@0|PdKL9VpP}BUXfvLK3OkxYMSG~Qt*ZYy-PeWPRa46<
zvQW`>+6rxo8lhPn+rP6<52Hf*ylddk15I(I|93X;$RPRlpg%qLG|9II*9m2k%^>;q
z;6BVd+5ZLK9%9^0<ShK}gfNz4Huq|XsLuF~IgBZpOB&S~y8)d;8RLN_Ln-r#^YDwr
zygK(aYslof??#<|Ec4=CC%!+Ke~)o4ELX3>_$1bqE+`+n(=CjBvMdjZ!J6M1RoMsF
zgAL_U*(<hT-f$uNMD5U2)EUh{f6o_)_^ze!2NDl|t51;sjz5rK1|mg63S>Y&NRwm%
z$pVrEBnwCukSris;9tQ46lMQx{C_{nxM%5WEc&k7G%D}Ud_qemdkkAxei_Y#t8fFp
zOj}vk5BkHGDW3TRC~87o4t$xmvrP2+O+<IX444TaFbC#=_-=PNECw+pp}S!(B*T6X
z(^Jy$43_hIC9H;T`5g&snO_HDD&Y4^cm-lQjb1P<?<YT$;}rdlcQs=_pw92zsEjas
z(7kYqcx)h%bnk>g%x{1=5YsT!n((7w42&eqC>RZ2Cb8TKK0$MM18+f0;=9|e!35ev
zM-WpPT8TK+p-M$u16bCd`9T%G2lKlch;ORfla5i~0H)9pjG+yPsS|1jU7>r$vN7ls
z2&(u!4t0d_Facb^9d;7`9e4;|rX=PqSl0{0G!gZN$rZnAV9R9EnT!qhf#~BdrVP{a
ze)qPl7k%4BKX%bqeHgzJ>QP4sCiFEQ4-;TD=Vu$se3=)0(CrAP!@jjBOZ>?8TI5%4
zm_-<&wOKxya6S;vw*P3q6<4XO$`Tb;Ot;ay74r|##})Hxq*GpD7ZFaA`PyIouB}_{
zr(CQP(|fl2rD9w0TZgc9D#Gicb-&uSF5A|FFOxR5sRLsAPxMzIt~GI;i2Nz8RiVSk
z6XLoT*NMo}iP-CFcJO;A?1CiN4Pqj=OaT@^J)<lNGC{$;(geCe4CI6O4yYlBF*zqe
zgEF-R*nlI1fhFZ!FNlVCNQP8M2TjVe24DgfU;~ce1A5h%2OkKAFo*`-8eI1v{8j|O
zVMvE;$cJJOgKT0U4~jty=r92#gh3R<LkeU<4(Qh67{LUr!47;N0#ZS}Hnsr;m_P`m
zK^EkKA%=5@00;#Wu5TZR0dXHqfjlsvqS+dJAO;fQFr-5^SaBXgAQHqkC&anwOdE_l
zC?OOMLn&zL|H+p|XXYKi9S%b}7;-PLfkZeA>5vUM<OfskDVC53#s81JbAih#+yDQQ
zq9~MMgzzBb9u<|4TS5pSBf3*`Q%{8ONN5P5A=C(&LhcPACNrTS<bDf{Ye-^po1*`F
z?VjcsGw00t|Ne7+|MNS)XTN&)*?T{0@4eP{t-bc%Yp?a);6gp(2VoEeNstDapvU#h
z7Mvj(vfvWrgP)vzLpEH3#1<&rhhiuLLu0}~F^I<bx?l`8-~cY*14@X6R7i&$$OFAr
z*d0v47JMKK;vognAsgO;PHW02IDiX8LIGHsU>i_COdIkY%0RCz+rnEgZilTwr#<1p
z9@3!z-hx91@&=+ouOsCUyx=XEbYdF_hg8TAYKo1Z7)&~2KZt@jxCVM%*aqw&#)562
z7#Qp(GX`gff;cd@#MU5u;irMzierNU^sNaCmA*`}dSLUO922~HVJFCjYY=10JX{06
ze%Kqb;1Y!Q$DWW5K6b<(GQfT~zd<x)k0Ad>5<jpV&G8`;T%6e#B*8V%8%tS-`(L2r
zI3FO&1$%(rc-BF&8|imv|DfeT8y5sY3KT$HPmTjl5DoE=<R!x)5NQU(iEInbkOJ4B
z07^g%O4I{GFa}ew0ef%)H}Hcnhy;d%$-I0~NP}G1z<Dh04Q)^{#&9btuE$kW>(`@a
zSg)Sc7EoJ2Z2`3f{=F@rMf4`fGz>&6y{ugVL&P}#ib4EhG{3)Zz!b*xdi%L}1}j2b
zLiz6!671>X9uy>IeZ1X+en0p>z<au@k9&ZZpLcLa_Vyn+{=d0Q&)_ikC^FELxw^Vz
z4%d$oF6>!N=3pS6A(pAeQ=3!~Yk6*i>cFK^c8u-av~*=WI=H%ueMlpzy#qW0y}Z3#
z148}$f)tGEwzduo@(vc>18f*&Ehng#x2K;;Xh4YXqyTR(R<OFOd7GYc@w18Q_qJ_*
zAA)0w@&DZN{lO%+-NRbpZ$Mna+cy<svlTwRAr<}xJXGn(RHdUkVMIE(6_foyI+VXl
z2azNlu0es)&~Pd0|0r(UoBjQ`$)vam9|R(9n>pSvjUbsAA6^+RXH9-!vIP+@5kC>H
z+~38k!oL6Ncvbpm$W_H_3h~haaVwTZyyR6Y@;$`+w?#+Tz@9LFFiB(Q#n^sFeys2{
z@Y_Ns>@i1`Pr2gcW*PvspbzZlxVu%ymC9R)0@n<#{_X+plf3=C8CYuV73%KiTCsYP
zU!aG(-=F83wY6`6ufi7(7c;pB74bLZSihhCR=(u?xK_%;it;7K|BEtNk*^|6_{#|O
z#xH=T!6odMLt4!F{b)tpr83H*?0~cnUxk<#X&1~?r9ZN&Sj&Aii1JV$b`xH|+DGTx
zUzGle*#4vP`?s`<^80bxMV#$aan`HGk4&6;Qk)y2>#3b>E8{FxG=H=9r*+OhI)6H|
zFHv^H@r6&<VHzLTGZpr$^pg><iU*G<QapH^k!{3wL8^Foy8HQ&OFpcY^7|i^S5cpc
z@+#W*hG~RIWkjr#vrcs$2Z$Zjl35w-tJuG^Uf9K2Wfx;@0x<EoCKJV)M?2YZ;!~`O
z&(u)w;2ED7L)gNSaKE2yRX!-H8Z^<C%7U@OP)o@Ng`B|Kr7{)l9TMvIYq{zvt4-`>
zvP@MxMEMpbl2)RLRclFg`0wIjJkdA6*i^ESoN&LN^dmSNX|HOqr(z$(rK_~O_19&K
z-^6XG#&6?RS<krXRP3EcH!06N(39-kwjzzLe^k%>nSEA&WFJv>Y}sdpeSTZ-i1Sze
z>u<k}U#0Ct`<0kJwOyvlcAvygWx0y-C6~7R^xxlXcm7vfRoL#wUzaVUGH=VKBHlwa
z{(ihawQC96=rrQdx-WIL<};I&t==UQO6!}qxs|?oe)s&t(G5~&?i&@6+_~qxJ*#r*
zf8ASzvn*e7@M!oi2{YW=?;TK9-Yxt|QpYh9a~I4~hNc*W#^uRm5z_ve)oFa-N6Tuj
zW?k%4OZLqw6VFcFYrVJdU#{D>wef<Ri<5ajL7RnK)8|6uQrS*3lTLfRqiWBa`10F4
zw=*+a-Sjqg+>$n=Ul9ecTsrQW#tpRXtWJ0RY;c<Pw9}pDg^xU)J6^G5gx&Hn4Z0l8
z87Pw-;`+)s+hd+JzMGx(Y)072tedGNhOaZ;IUKaRJN<O9<8<9i;u>LZBf_cuj;Q^P
zh;r~%hto}>UaS3%oTzc?Vyf(>r%d*(nXpT#Vn$4Lqv(L4*V4|V)jB_P$HmYA^}1^J
z|2pCJ8zZl0<+Q1B11i@HSJb)V*lGV0E4|fMe|%eY(<TGA^<SmGPg7L2ee>n@th2Pu
zN&B0#!rIKXXqDO6<gd>iPYKEHTDpEg!l;&SX4_x;`ogACjvLoc>@RTX)|);XhYgq$
zp<A{3g+?#>ADZ3LGJnWY?Iwd3^>OX|jZAiri=$k#b<EJ1>XwT5I!Wgr_1<;atHI(i
zn+6ykyLHj;qG@yEJFOVUAjPlLdgt>lgU8Fx)|mWL{VI7s9J}rPOAY-~+tSRYthu<O
zWEFkB`-}bkb$&<0dt&O-S!X8Cnb4-0wUgI{NAcTzkDO^g;$ct6>)y%weqCG)kE;ES
zsQr$p{f?;pj{NKVj`#(NddOHgqHm+#iy9_x^tfu1aK(Q|&o_~4E*acuJ*SuFr24&h
z_oVhavi!5nRk!HGF8?ug<-9{Jr?i~crtb#sC+&p&&h_>#%j~;!R7bxK^R>SIR=1(D
z<n)|b*+DlKw|Ts#aO+drw|F0ipNl{<!_!w1c5l)xedboIT{B?)p8mD^AN^^@q2!o{
zjV-3qFNKFYx#p7h4a0Iw_g}P$y7#)_-Bd51v-xfzBZ`(*pQ83VqV_v-<ifK7qx~(M
z`n+WfmQ-H0p3^xRsl9QvesAN;JMNk;lMfwmv1Pk6Z7<ZU-K<+=4<3S_)8H!Cy#6%T
zv)H)D`R0XYF`v7i-&ud;*d2#8Hq@Nwda%mF*Y)r7-c!0CDqml;?7@L;^Pap}*JOLG
zRYy#xX%x)vu1r?@9Z~xov1qUMJF@s({>jbOL%z7%ve(o}@7mQ0UixI=+b&<8eSCR-
z*0}oP0_Yz>W1w8~b?(YYWkmCYN%B%VXX~%Vja{NBX+CIJlG*6@iUqAM(`Vp;6t3Tq
zM&BAfGCic5-@jzg0E>lR>%6%<DBYz^M9_4dI%VZb`X5N))P6_C)mQr+k!uz#Y5jTK
zJ87qs=Ym3KmiHOgdsdqT^%8<#4*qKJ-7ojL(r6b+TbEq(`v)r~JqVbc`0&PSm%(2x
z47+33`|Iu3H`ZFzYs=>4^O^?J&r}N6^xLF`URe!R#7+%gv1viA)rwQr4d?f`5ol4e
zwS1y!mpQyYklM{|-<{jK&cR3RlNa0Cn}>|lJU``Tv+Qlww^EaDo@zd^e;fMd(6A}j
zJiKdQ&bay3trs{BJ$B1oS!L7RLqBEDc;4{V@QAF=U+<YqpBc$d!-Aa8o&}k#*1h^J
ze8syZt0TtQsr`-!`>FkoOzv<{yZaY=16%41FnhO_Zd+1&PS6g6R<iC+3Y+xv38oL1
z?$0Y5eCN9snsqI@?wR=TP*d7zR+$U?ofx|GU0~I@w==X9N2a+HS^qTq-k^3(e>}ft
zY)G@0=kE`oomy&tdD~pkYE#u$ce+d{Y#!1tag~|r=ndb^bPM@5S?zaZ-jK$#!js#i
zHSWDK_x|+eFFZ2$Tx|X>_Pf=NyJ&|yJXqK{?ESc@Nr^e}Mg|k6yo}gy-DKYu`)-CC
z2dw?x-+EW4mo<5}#fx#d=7T9A&r|nq+c(yu$(j_Shy!<~z8bSLD|*K+s}K3>Lt>8e
z9X=`Fic?0U9(B_HV$-@tQ>xFe5}sA4_B$f%r*kB}jmzWm8>b9M)!DSqFfFL{?q*}s
zR_gaLeV*N{RJ38rr1u|czayG&u1pSd>#!+xrTN|=TnBIPZb+`#{pZt8^ZO21e5CuM
z*5mUF9QOa@-apB7RIH72=ezs1O<qW!c<K4b?%-&PH!l?L{jEAr3Ep5=>p+!1@;hRR
zxmEpDq<$=-U$rLdj6qEGs>qbp(a%wRv_AS072B!$he-W0KHct(M#Xk-QPH2|16sMA
zs{e+}mi3=*S4DL^O;i+x>Z;?3_nNBy6*AH9;#2=9bXQi2*QK3NZUbaA!7C@CoQl$M
zZJAf~laTsP<m&y_KMJqsl%h{X3d%OJZK&90JK6_LMJwa4>Te+RLlFD<*j`HsC+xKh
z75x*If3%(Ioxju<K*ay!?LJd&R~ID<L|#b8<5s!y9lh{jBBi?;$}2r-a!_qI1Z5wR
ze-!3rjw}yHN1)<e|43BCpY@gR*rj*xA|BeT<5h$-VP~Zlb2RZteon{(C2^5)%cSgx
zVhg1O$}0pVmofS|RP5J;dDS~}>3y)+Zxz;YX_6)$?IpX2?L|DCLG>P6`nHM)FY=G{
zNK*q<cx<7p!y5J@*`+B;-pb^tNEhW)NjGcp?GL2~N<5_fi}<MCL;qoXnh{Rqlh{6!
zWB;f6Z^_i4e>x|E@Y|w)z3Oj#x3p(DcRKgi*uiK9=L$H04}?QJWWXgTgSs=Z6F5K+
z#6T+KKq2VNVk`sq!i7)<qO*nxI71LbK^&w&23&$d(6OQ{fD4Ge{_O{8NPdEHh*vJl
zZ^6)-G7nx54QX&6^eLb=-~~}2zHfRBv^YW9gA;^9B4mO1zNsGX;cdVNqCoA#g=@ed
zP6SZ<aAADKSjyEGjN1SgP(m7915pW^gEIs{Jmf$L=(|v^zzOm>@ARnv`+))ysff!U
zh514-rt)`#aKgqzI$VNc&>zo!W>Kc$Q~xa=`))B;Qg*4V%g|4KwtVWV#gTJe_-gq_
zep-Z&mj7G7EW#&CCfo<Dh1da=qoxpcyJ9?B3Kea-sBCMHHV6apE$GT`H5U*zi*=X4
za1q;r8}Ypc#y6_Uf*=Oog3HaSvM5M|EGPuMJSuSYq_%+C0@6KKdAZ6E`n1V1yPD?)
z(dYE@CKdfe*D){pev1BcCqVQmY`|}#|8d{O6@8gMV_9@)7kx4fnHS;fqoU8J=;JAf
z1JUnwJ;cM;umKW5{GJ5KFxiN4Xb=EfSr*6L0XtzAh(5e~;0iaed(nN62H%3{-z@qB
zr^7)w1X4eJRT9PT;@j%=K<rl>S8VqKh;ieeuB*ekw%kNokT&tn_sXfeA#r5=VQzLS
zZPSir(P#b``>M@$=ear0Aq^K$VTY5<{|LD(|EtHNi+KKbk4YED{O=f-z5yF<1~Jtq
zUkpJ^-6#)MAg2DPy=s0a>ZqD`LPx3Q$D%H(c@NZEH7~|8YN_@q_BEIFk*eRcS+Aq|
z&5v~fs`VnAg8AvHWnIG5RE1l@x@gt<7<8>_UX(R4CjH|v=wklwjYH?rQF=bIN1eb8
zf*>5CAP&+Y3vwYJWZYNifFX!+>h|CUeh>zcAm{!<d=JqQ#QldOi1F)D5DSTr3MC-p
z9z+jJz#MErjB5{rSV)H~$cHk}=elhK!gpLhaDyPR%q3X(hSRUc@xcb1K#Yr5fD(jX
zIMEM13vwY33g9isx%UWzaJU3o+(*<E_Yz<V&fo(I5D)s%kOKK2<K99a%)u5M!40CI
z5Nx=w@Bwk(5v$AoL5!c*ha4yalbWOf^k@XI0S6Fc;tQb+9BXr2hyi`dfipxxESOLi
zID-$QLLL+ftwUJKh8&zB3eq7PbSM`#-~(ZhS)Xk{PCaA_P7np@kPTwYdpzVqJ{UIQ
z_)t0CUBUU20fkToCUR^E(U9GY^fsqVfDM$0`4-GWZY%5$Cap<7<b$3Gc?|s^4YEMd
zhPXgBIGGbSh=WTs2FPjPF$D*n)07YcKHVv2AfCtWgP{$_fMTAv#F%YMi0wsu!O)g<
zP}Y}Y_GAB`-=8uIV!U=5lz`lh<A58)K?>|1Kz!|qFBlJGTkwK3xDO>D8$=i|1Y<A-
z8)!e6?Ho|>gD4Png}7D<UnJr>&=(cglHsVh4hX+2;(FOrwcZjH*B~oYT*pKmA;toU
zG9s>>>Pc+@wFT4`P+LH40ks9x7Wh|NfLrnZhw=ZOfdSLJ@dFU%uMmC%gvS7Pf3L3Q
zF8&_Diooff((wO(%klqpWX1*+1MdAjLKMNi0h2^?qp`sl-vF<`=^>22G&Zo~bLo7z
z-ZwBnjP*1&=-p@FpM<Fx?>|8`R+M*{(lmwtHDEI2at~Y_sVCzn8$Wk{4=;CD3o9$r
zE?q6nt<0^ucz1E{*4d+rxu>VMrH6S}cXyA@U3>m*@V`kLu|qMgRp{@hif^lnv9&t<
zc#dOLj^7vK=EX+Qb)+%4vX93ci}qzP%>W)9r0>FCU|Zz^DW1PIleM+0t15S0LlqM(
z2`}Qq?erf_(m317@xN26iDL&%_avl<k26{sAF=GlGLIO936P0xe3;Lc(hwBFth6o&
z6>UT8N8zPfXNt~(VH%!h;ugB{Tk;j-jf1@v49;ftZ_=DuRjk1`oF@15s4aSlW62l(
z-86?tMLMJ+)gsL?(jI>I@7FXZ@>4~cy+Rbsi!`O6!dDmLpo4`S#Jb&RMY{dGDQeQX
zboA4-XR_|&v^QZ}k@f<~MxKHGL7@!gcc13&>*wy_=Pj!ouUlbb&(Ppt#`n8c9QO;E
zj)B<jk23e;go^C;>tb#FPZw6=BgX6(Q>JXN@pTHiUxiJj_=xgSVUx=EczFxsh;5vx
zj6}PDXqQM(ZBtneD)LfFn`9rN{<}PPW8J5DF7_M6e$CnMOn&!XB;_w<*1$lN*~gOY
ze0(SQxQ1Y$z)5&RV6_xi9`97Y`vp$_=x1^6R8pDN4EFyy@g5Xav43HEQNAnkRS~Gb
zr-CQ-2}zaGYD@TZC}G({wT(z?7|S20Rg`7NU)TM%ELX<CT2<f3v<b*`i~aIgF1w6A
zC4IJwE6Q}`X)8J72&gzGL^+O=w)*s+zT|I196yntM4Jrf+z4;QXvr@_Wm*2Xe2a5f
zl;w}l>2#JWY*2AdXR@p+*P`N;@-mxsAD8RO^H=y}9j4(I=;=;jW~waj6@D)&)>9X`
zQj&0B5hmF+i!_%JS5aX&EUCx~u|JU)pO%eJ?H8#dj)G5F%5F3CE?S8F5?55(uky_B
z@%F<ViwG<1C-Us~Q-%G6os|4oVW;VyB3@!$6k1UaRMc(4b}_8`*j6H6D(e7+YP&@A
zV_S*sL>(Z0AEx1p4Jzu<Pi-f{SrVo)Z|dN`X0;*hB2<`~GAS#hc-az06$h!F7Uf%u
za^;9^a{298g)OAxi1VZ3xUT)ff`Wy|4(Yt8+(xv!eL<M9t19wAq}!3@sW41K+WoKR
zQDqs<7Z*yVt>h!wFWZO~kq5S4N&6t8s#-Wic)Y<i5yupHkS=ZYyMIz$ENqg=Pc8nS
z3}>_c<1#GHTanHR8wg(&0|Ukc276WJ+ckdsG~e=n4PQ~l3t0ZNj2E-+<9riwGW~Ts
z&g%-d7*ZLI!fu(>@eR!Hp%v+t>`imn-?g{cri^XI5@y@#3VVz5McBI{Eu0~)9-$K_
zdIwilM56pl^&{JwV)sjg)m&4tt%zU0KRKQs+lb?R75BH}`TUc|OJQ3N!cJfNw{64z
z$!+u4_A+6wtF{$!{d;9mq_LyQhlucrDyEa52S?#KWy=l6s8rn^;*OP7QhACIGrymt
z@+8isM1E5M_Z*T9?-Qpi_P>^O3o7;}olhc<gDS!a(|nST<a<SRDuoq!Wyt%qkMC`W
z-fzwqaSqwDPMo{LG%C*9%6hCaoiQSDOdH{I5OI1T(wQKolgmKGea7Ff`(?jLXJwrs
z(w)M-RP}=t=iMxSTt`)w>k8ZaS^6sKps<hXppWy*kM?yj>5)02F3>`MCLN|<SEi#P
z$NnrG!e)tV|M7WVnU;^!Cere8+C-i5|C+X_PtsQDU&okt1Y!~w5s|jZ@QSo4H>lF4
zs^?fOmB%PC^ZV)7d(9Yr`}7(U$GT7Jszla(oJNtKAE!~+%9eE>mqU>!mGKt-e#NvH
zM7$&54e{1b{B68lsWAU6Uqo3+Wcxp=mqolj&M#3f|1E!hUoVTi`ZTSXV&72tJdw@(
zr}eTU>po3u3F~%q9{$z+XaBePk-0pS=PAvpUiDYsIH=!iQrhhEt*@`Y)var7caLA9
zJ<qLL)br5xxm*PP-TlqD({WU;IjEc2!>`XRJN03#d~LyGdxI4hJD6?jt+Q`uv#Apk
zW*$Dy`!y-tor6zLUT*zE&8aV{`rle`uh+rOcgA$@-DmKgo9pcR&w6^5dvh+Ve6PH5
zLhzB)x<mcewK<cbyL|7KH&-%`Ek63<i&f)KHfy6-$n)wD5zc1O&1FyX?lv;`CZl@4
z%Xc2sI<w@IPWN8pyq#J%nX7xU9`{BKM7aB5?$g>19=^#Ze(~BFiyO}IG5b&TU(=<I
zNN<7H_y^zr&~4I+9%CkjwK#a7aFXf5(x&Owig$YowjMKIg`M?9xRoyq-z&XtmX8~B
zq;~(n6VYpezw=x(yk~^x*vyNox0sa4WV-!DIJKXf<1Ho_JLswX-25;KH;9i1J{w)M
ztB>>Eh;u1jE*|V^I%&_?&13eQUni5T;9ay_Q|DIsf<onscJ+L^9X>m3b*%D3;=Q&y
zH*SX?n|$`P&dT$=`)wk^z1f(3Yh+NJqeBN6pZ31<uIT4)-)*lKJG(eMWlB@Um_}TH
zPI6-}*X%N8$KqEu&ee|&8DIZd?e|Lt_HW#)^|AMgx$p1gC#Te#&wU*4zU7)$%Szt1
zp4sH4^L?WU5oQH>j}-lzA6gcd5Hobu+J-G1c(^jR65)cc>N`Y6+G&N1eB`~Q_fN`p
z{q;{K4_xr*`WjQM61PsNd;`HkgliJw(7090M-7skW(ExNni;iJIi&rES4GwfvO72E
z(>VSG@A$ikaE}|$E*jGOROGVG`bo!KyZp3bX}0%(ReislT)1xk$RhE+yIeYts-50$
z?f6->_t)!BmZkI@cd%p9)rB_iCwh)jShPO3_Sp&g9Z2Cy!)9Off75cf<F{JfCWb}L
z?R`A=<_`U`mfHP$&U(_Px>6<^EQQ-KX<x(cE6#qmy!PMohttbW#BZbScXpHZZM$Jv
zV~X<5f?gYr<k_59acYd^`tFm)zG(1(dUBn#zv=d))^^`hGdAwr(sl7WJJby>HCfnA
zd8O`xf*U8lXg}GD{s@v?;_h{mzbjmR`<l-7*cS%rX5)1?y>D)}Wyf~w?d|hNX<nDf
zmPp4<{z>N1SDunz$C9yJOHMbRcdWHd^4W2FF06UC=>5?diS$vE_9y>(#{0wjs!vta
z8oT#K2fu}P!)qnvwkwLyXciK9#JJTC+K$XbIwCsWPIx$ZmZeQ@>RGL`^)(9Z?<cew
zad3X~gw8eRwb11LYtJYVE`31gs<<94o(+9x)3a=QdW%(|-x?lrUgvGLbnp7zdE#5(
z{?h*JTX^K@RMDJTq}OzVuVrFcVQ}UMlL7m>RqONQV1<93&cnq1EJrBLrNy>Bacp>>
z<0}Vh^s*{Vm~^q&)8^_J_c4pI3YXJ%CWTw~RdS!JR<RQeUTbu*ta0k?gP+5X_cSyc
ze{fIOz%%_r_sL{;Bs-VQ-#Yu&#;y0}&#ZCiv!*RW^=B47Yk%u*oz#PG-)-4qHH+)M
zR6jc}G+&gNY;dZ^&vnj~-Y-A#%{P;(wQxDOal)$WS606a5)ZvnxMG{`shxet)g5`<
zSm&|P^QR;BFSv9@tIGcJ(%xqiR=4ZGb13~Y{+aKeuafL?EA4GkTJpY{!(NQF>iufv
z3^%`N`>#7cbucYFnU~mj18p8L()IVPzT1U4jn}(P%qbrDuD$NND%a;;8{%=aEL^jB
zg6D%HKUDM?k!$Md*!9ZzqD9KWj$?ek?qqta?wKBGN!2y)mu<CbJ0`ZnPWlQ;`+M|D
zN&TO5)qZ{cb$)#oNaghUpnR|Hw>rxkc6wjmeBS4M)|5{vYP_sT!I9bKeY~`M&Z+(S
zl;2SM^$~B<+~{K_*Icf+>-42t?B=MUzM=1p_YJhP8*b}eGP~8pJ0s6L>7V{YCcD^M
zgj;;#>b654##v8r{&{myu<iBzH<l)8hh?l7b1FLVoX#=cHO!Irr)#&%JNij}&gIu5
zmrYEqH@Cx4Pb=-P)3IAq4XwO=oYENAEnW9#Pd$+T*ZB46GF-&(VdCOTCnvlMy!=a9
zxtXnfR*rk^wY9B|P0-G?elf&t>KfX{rTVn!^1+bOJ-v(1=k>~X`S`4V_M15-IiEL+
zzh3?AA?LE~SEzQS`wgwC7JJsYwHoUBa81+jJvQGNAFaQ=Xxrj5&F&8yKl{Vd=6qMp
zQ5;w2QSwt=y*Wp&KKNzBI`7x5UM08OALZEgSlFpaW_?Z4X^iO7U4%PP>$5p?-!6!F
z)6wyRB4*f_5XTP9H-xnqnqqypRn+SO>PahW5zfP?%7~Pd&hso*W^J8dXx(w<g9)Wa
zW-Y$9aM$dpsbxbr=Ak|!T+=3&=Vop%>T~#|=FuYE_}f;^`^vofsr>{E++z}#*6!TM
z2X9M5AKq*@zE|nY4OT-P@0bnGj~Fs&3ASr%FYIT1%BJ%MjU9Ej92@#<>Ce0Lc7`q+
zT2i**+_Wq8J2tHK%WV2U+KO<K4^4Y=xX@$HjhkDxw=o^^b*GZ22^+oN&)ZtvWkFNh
zFKC;)JwSwe)K%>#NbM(xdQ$BtXwH;HFTM{y^VDwdK=IwO`CX;+NdIxM<G3&VE&SvB
zCmF3;KX<pAyv}{k&coh(muuK|VN?2k(+63unVq-JcumI68ZnVi4dgFJyKM<Q`PGay
zrbfdw=4Ls>EO+AjOH#Puv#(`zt8-<|x>Gq%)6eco>)!rTKS4J}i2cpb*Ep#R`tii7
z`F(CYbB*ax-tT0y0|&d_oO#x7(LF0$-d{LL@%!`p*oK3|{*pHYZEnA4!^ts`e)Nlp
zoHt_M$We{$pKFh<Z`mw5W*5&#8a#91Z+d3Z*G-$x8*<rmXxMnu5&9QTrq-yVC>YiL
z{_90s8)luR-?MaG@I28XrS*#{-woGTxAFCXemgGBKQr-}aafhd-N$E4o_U8hpT5#@
z<My{bUfO5HYNG~)ua50~*gLJ;J1x1>i!A|1-q(COwQwWPJyN)cBROG5w%6;~ws&${
zOE-BVvu*qD`^%@so+@6|s$^Cho@cfjiTFK9_|dwap2PH=$3~y-F`)J6^MMBjKHAY?
z_Uzl9ig6cT@dC4!WakYTSBjQSJo{W3_TuyXSsO#AZTUV~GilcAf(=zCt@%Q^SSDL2
z9art2Xx8;^@eQWO+-q^I+l-(C+-FPAW$|tqmlj1ne|+|7?ilZ^Q6{%HU2Zre>{if@
z+?@|(TJ?V9y*TFxewB64IGoreKbzMhugZ~IS0B6Fo^ad6Wzh3vc~IN7p`&Ip228TE
z>*%1jIzblCLo;VokFb5(Df2=5OgHx{5#`gjcIw(Cocj%Lsh#HJ<n%3`4ZHN*y(gh)
z@Qw4w-;Cd5)1hQt^A*!4ez-QS7x#4MrTw+BTj5-1X6UX(7i#&ux5+LjtrOBe|MAx8
zD^uKC9zQhld-_vJ=ZD%qk=j3zD5r*}MreILX2txBuJJXNjT&3`rc3B_?QyHd*6(#9
zqyN}ZZj42-6yaXxuZT42`Jt2H+((*;uRL-dI-QDm7;WA)Zg;?mx$6^Yt9vfhe~llX
zY5Mb?`)9X?d%Mm~b*t}tzF@Y|s(r&>`1cxKSkJeBb~EX|c=rgc*Z<f*QLWM9xb<9z
zedjpNepH8h3r`uAtxtb9uU>=KS58mPJhbDp$?qCmq<v$g2<P|y-1VOd-83AA&RMjg
zOXyjf)Ely;8CEmvoBB>`HF?W^wZEg{%nlZ2PYeBrp7_khaP{mZ(H|l@m&DLs=OFC&
z$i?N3v2D<;vxl-**1VLn`iCC1n!PX0Hnz*`Hqh~L<RbcgNbSIO4)*=~jLvW9wQTym
zi?62txaEj!<guBb9}d3QJaYY@kU*Yiq;^}izoV!&d#)W@^ZKk}{*wzP*w|cpo_-v8
zx7xh-Js#QoG-!81Xu`N*yFT@I^pd8+AW-$MmHhtLR^$B+>uA=MCgCrr26I}d9Ib}7
zMzzs4s1C|wudD`2^R7%6<uOU7hfY9iq24II8kCb!15_N>8C3mcrGB*HxH_yO`qK0i
ze@2GP6`{6hF)H@^66N+x_8R3@Lq?xrB}GB@3#vd%QL+DQp08AWQ>8wuV*gx@WErd%
zlkk_s?ToA(ZI5aYFU%(U3>9$@ewoIi!Y>n#bTUJ91=<k(4sC><M4O;j(WdBIRE}2R
z7|l>^v^iQEHAW55mS}Ud71|nYjf!s~^Q|+bHQEmCk9I(v(T=D$+6kS8nxbE#ozWz;
z3;G>uh8{z^qCcRFO;sL8yQBGN5A+q<6UA1tUMP7cvqg!MtT);g?T1>R{n0+?0CY4u
z5S@n(Lcc^E(B0?|^bk4}%|M5tS?F-|1UdrEMn|H#DEm_0LdT$YP#3hBCVlGBuBa>8
z9d$!(Q4dt)XC`r0^~;p{Yl{5jHGwRR^<tuFNGg})q0*0KZe^5_s4cn<?T6CTF8NhD
zgi@B2+(OB?)l%L?$#dmnbQoHS(ln$L{b;E2m3>hjACxXAuM(7VQOd7!8A=&ZUO~s9
zlug-qlrqE^0rC}fMadh{cT0(F#b;-gp6EpM2bA+qc^;jLK1PGlDx^CE6=Q}&QDK*9
z=rD9TIvNc_$DuROS!g)A7@do5MV0)0kIqAXL?h6%=zP>)i++vhY;+mA1m*T#xf!LJ
zR%W1-b>&?&7A-};LaS7z9~G*NZb048jc6FU30;A1Mh~Iipcm0(RP?Leii&&`=YXnz
zsMK#%<fEMR!q#GH!}-_@ZHK-<JE9u=)(NeSnxb`3Gqf>kfr|6T677j{4k?GBHt0gM
z7rF-RjUGffx0KINJG2C4e791D-3Ox7buwHdDXXInsL02mD0P8sI64J&LN}qK(5)!v
zsB$kl7EMFHK=-5L&?D#sRGbH{s5lSY(KDzgD$WBh^e)OdUQy0Tv#Rf=)TdL}rylFl
zKukLb*9hH%TA+K;wxnYpYK4A_iu3;fx`zE8Myr$WN6>mGb%oLxJ%;W?39Gz{o<#4X
zKcYXQIcPQV{Vci`J%<L6kGW_NdI=TZi@SzyKyRR;@99lc<TK^7vY(*Te^8`Dk9FeQ
z6jKJ}K`b9ZKS!xkm2xx_ZHZ=~ozdfHAM^w|5T(wQ{H}5CN`A>sp-WhQ8a;}hLB;XK
zwL;Z@Pn1!aI6i;B`gOZYIC0$jXcP1y+7^9;D$xRTElQmr?az&QRX;kZtcv|rXC3u|
zG?f!h<O^k0*#gx>JE2ukZbM~U3zVEY!nc4j4%J1UqBT)1@~ajq;%y14K5bH8H*p-y
zFKZ8Cnol@!oCRoWlrk<|R~LP>y{d1S)aUHe?H{PNf2i925gNgM3edOY-+!u~HsPbq
zq=@_i;j7K^8uJhhl8-jlr$8jOFrrfZck$JhM0|2U?WYZY5B=z~4MzPrkHH1PAs#Xy
z4}`-+W3Y#8$cHj;96<kLh=D99fx1)@c~mN8ARj~>0dAm#M974EcngNyDA<A*L_rc{
zLLt<3puB)HghLW!Lm}w%4%-wQ!4IM#6|x~8w1!eH!5(}-330F+vLPSJz=#_Yb8rAZ
zh=DY?1cjjE$bP^cydVlvAsg;P8AMUfI6D(ZNQ6wt2OVx=Ou+#Z5Dyvf@8qYgfNRpH
zzS^Q{kdJf7Pi}gIzZ4%ZS7JZ(@A+-ZEg~!z)Jp$t;h$ljs-*Q6w%|A6!!45E|B)Xz
z9c_*SPT;VdGWVQqm^WU)aZyJ!19d}l&@wR6p>72mxWsxFG!~K|6Yhi7LehhN?BC5f
zl5kvT{wqG-%<<b61}Sh2-hv^6oov7nd_W0tpq|tgP+LH40ksAGu?4E|^T+=GxQ~{l
z7*vdls@ha0drza%2dJEcZ@zM|+?Zzrr~;aBR3G1gu#w-+qPcJ$E<@$CiQmMxANz~#
zRZ|l4TcDU@y@1LonRULzBL&?CGhil!!yK3gk+29BgP2m$9k2^_!(I^6BjWHFmb1JP
zzJf1Vj)pbNuLUs`viuC5gP6n^N-fe>6{>;ghp3H;aeO-H_bgXOYrrwqIlwmJJP=(E
z2_UASsOalB8pgsX!i<J7P&tY9{op;cfS2$J#AJfDf%eb|x`3F<(JJgi3#zI1WyiYy
z%nwv84`NyPpsEW_#6#PRxI^VMnsv@#3SFQrv;#4jp%%~$tW@j9qEjJ6wLA`Wf$=Z_
z+`$XBal9LF7b>Sz=56?`Cx~eh>I+j;%evT64{Aau=nQ6H0hVA5-Ju8c0#QzTi+NP|
zq3j2CU=M@90fxdb5K}F*Ht0hGXb6qK2pU5ZXbN&@2H&vX=I9-?1!@c}p%t`-HqZ__
zfS3%>Ixv^?M8E=wf+esFRzNJQhB#OUyV-X<`ZXkim_FX_Gxk>(>cQtwAH;YiF|9JJ
z7zZfkwdzow;iNhD$WRPo%wILmsh6l2H>b_K7$a4}yclby!}4oXjNhuxd?^hF=b0D2
zAIg~*<E6#Ai!2M@2*MHl8T2d&-x7tKAGzpdxB^#ITtlzJ4Y;Wy54{Dq;SS`(PjDCR
z!F_lD58)9MK;<OH=oi(M$)2EMJbM-5A@clZ)`{`ink+v<#W-Ot=06Z;E$(@%!xO?h
z1<}t>pJm_rly!dhZ-?(jaKx5BV0V4i3ICt92~!hlKsBfZdJxHWQwZ+|Nut4mbqiTn
z1r^)PqVeT9$LUGD%Fz-K<>w%Xeh}wbu0l9X=Ks~cKmWV^e*Sm({QRHn=Tp?}qFxsD
zpSU&%6@EX(^+VLlqRvdAe0<DSmbbxnNQE6BCOr_<gefQ?AB?$Xn?pE=XX02$gjC1|
z-c?CHJrmJXNC!inKYbt;lAsW5dCnBRGDLfM4&;Frk5ZXD?-f8@p5=@|_}3KAefA*y
zYQ{q<WIzt&K_SHPJS)a(7s6Z6(q$hIOCm18eJBRuN7Ejh!3Pu|J|<yQi)#reKzwW?
z6-q#>HfaJQumlHif*=ToI7os_$OC<BEc|c!fC92WkMq(9gfC7%5Pmq*AsZCbqiK*2
z#ZU(Ad9L;X;lDKv@}U@H<cmJYA(}kRf=h58N+7%;`-Tk21~F*1A2@*<1VK0?g18Qg
z`x|i|lL6Tvu1)PB3dERHJ?ao6Xb(1EOMMp$NuVcZACL*TkOzgJ(~SHEV+evI$be!n
zX^st{ALN2j3-%3`pvASq670bVf*=?2pa4ohzct~(797AC6d)RN;~@poAQuY3#e}wW
zhy|xM{03Q&3x(j^7CS=_ghL#pK{i~1d?*7Q>S1Fr1siY%1r&l#dwzpraOpt)LKwtC
z3E&VwrU!;#47T6`K@bgbkOrBM2cqFSABv$2bWF*1Fok~L2H}uxhCR$F3*Z9L5DzJk
z2I3kguFF~$Y!4=23y$CgK@bITup4qAAKrp~SL_Tn;0#_64snnI+2GfWbV4M=Kq_Rz
zHMkGOpl8W(!4mp`BltlWL_!RtLN??<0hEBuin0Nb)@<LM<AVakM|WZ&4YEM^ZY>5a
z8`22o;0!(x4M~szIgk$}pw)wYf-N|M4}?J?q(TPdKpE)w#17C8oIwFGkOXOv2YS5-
z11{hP@vs{*p#*eni5nP$GlW4Dq=J5L@)M#V9@6_@e=zP#TA&!@{V40;0;c^54?&O*
z`gZ&d3P^%9Fdsl(K{Uwiu{pRw5?q4&LI)DBL6k{w1kq-@8$_F}c&Td+ZV&|NL)iul
zhhaAmZKz7v4VmCFoIHUf$OHQk92?@nawK74H)KNLXzV_QV?wkuc?iWIUIeE@F$gCv
zvE#`HD1<Udnn3x4e28%+{%{|HCi5GlLGcvIs~_<LpFoZesSr7peL)V0mqO;y5A+l$
zIKl2v>@khspdT2{B>f=1Bh!8s`2}&13;N+42OJ<A(jW_RW@Dc@q#11IvMnef7i3Dd
z10yg2bFc*ma0V|3f^dj}SV)9ah@Xe8B2dVKx6sL;;{Nkz{fhf;Q<lZOaeGwUqrPUn
zxCj3Q75CoNSTF9W#q~$r(`umNzFYVc7CuSDbD+2{|5s019AJWUbkc0?5*Q-<_*FRZ
z6W;v%eFLW8WXIdj#WPqD;u6Y#7aWMWxCaG^Ss!orpx-<HV?%FO5BCu73ip5imj3_#
zDqnwHRKB-TG%9kcCQ=pjz{rR)V5lqOrx0&HZ%>7*uvdj&jEc~o{{OB2zFm}wVHzGd
zx|$;U*awGsm5S{+ouzlSLr~#^I$t`Lt?RG$XT9*jVObIU)BnHv4zcBzkB?PLW@Vt=
zK#I3aw+qieEE}kn#q*7bO9|WLH{?CPs1G%tnWSv>E}2kT-@MJO^v(0T=O2!4kTP@M
zsEFjwJ?HINmCJK9b*Ws_vV6(Gqv5|K%y4hNcR*Qrx9}%P9mh<}T`)@-nqm|hm&bFn
zw7+I`8Xx%4vf8Uz7yHzbeY48Mvs3q4?=Ae7>$Yueyx`{IWSQ(#53xU=3z17@JIzcw
z?e&hTJ#XU6Z}Z&F%xrbj+t_hS+K_%l#I;;H?wZC8wC$`;cl~T|n)bBQo#us)Je@mU
zv1EkZ@-Yp%9L}NcJ=9a|Z_zQ&8sE*%dNw2MW!BBq62sRS?;H-=-JO0q*m1h<r9PzD
z-bRFr?VziCI@>Vdu|-)yHHR~2o>&juw?0Sn)d-yfKg=;%GlTvW(s6UA>OXoDx31_-
z(bd_m&ck{>to`z=b4J5%LxSoxG)()(i#kP0ujZ(k<(gNTZqG={-m=qp>vMO9X72(P
z44P!U@M2$o>-qcXZzAn)zM=NS>7|>d-H(0t!@6z9njTqy!f4aQDf^e?<y>$pd^}z4
zTO!TD{rVK=;~^8XLgu$m+52RCzVq}n&bba<MZOuO<<4xjEX!twMOx=Q?sjFhd$hUK
z{rt)oZN^q@?2)yUYoOX^MDqu`@*=m?uHI|Wj=Qtdcb$47Z-0QcI4T*rX8h69%c?z`
zJfrQ2Jx-l_-+JhFQ0+59*d_JtU*$6*iTfbA=KG6Hk8c}qe*1*;)xE1;josnVYfbd@
zS@mDmJ>_=p%;jO!2mdKPBSb$3#(ex`z99Z;9}j=E?}j^4djH%v!awV~LG44~%sAu1
z2R9e=u#NiZ^yfx<=eEzPyO?`xGf}QmY&vbI^JuH?*6Ueb4`ijY^tv_3c)h=N^+jEy
zf*Tz=+lqT{sb2F?jvPMlM5D>0_q?cnv};r2OXkVn<Q)65i9v4LDLs_;xzW-V&u*H3
z9<Bk;Wpd34E0jh>_4kBsUXwGrTxW*%{7YpwvoCjgbXeh@^Gnxt3+RU{?XM(u;%39p
zi-Q7Os{E{Rt<lV|mo5hf{Cwr%lc{a@jZSO7j5c*{&g7bxyO#DCd#tG03cb48nd1^i
zrrJETc(gd??!V55LQ|ew`4;=mI$mS$*q56{Pg~^vqRXS;w-&1(HPG07sjc6^y6Z<d
z(4SXINBBI;w4PNK8Rx&R+x>35?d@@+9XIE{4H-SL?ev>F3@6p$9S+Yj_?p?e>0aBw
zmvK90Xu0d1)HgY`bx*L>x-s!vYt*UPs9_=D4omx6(rsn7N4+;)`+hJOl5%P8#`B?t
zS1<JI*hJQD$*Rb!R=s$hl;T(Sl6T7MDle@ZoJPH#TW8JavJvB2?T9yBd-3)4zNbnZ
zwRtZj-Pc7bBkSIHId7V46W2wvE~ZYea>;Q1(hZvwRhu0DCT#tJBRt|t@!J;AP+sr*
ztX{?bYTpQpZ~iCwM)<3J9;kg8ynXUr?5;aGp-YBcI&N~?cU*+?Snf+iM`gL@53fcP
zznmu9v9{r*^nD4<wf2u2R90NaLaVrESUtPqV%j#etwgwUDfc}54;lEZU30DM%DC~R
zB^l3`<|kaeUodZ4g8g~#O|+SCuFEymz6`>f8};e-@ZQ>#39=^}u-#C}&QBgaHn=;s
zN>Rhtktt(4x7=c1%g@@hsB}Yzfz{g>?1|!euoVxja?SqQTk^9?8aGI(S+DQ>UJVms
zTF?4nTE9lE!y*rBb-z1!3-8o<R+eiXoRm6q(EQ<(#+_)oapAZI%Z^%)@lyLTQ2R1?
zXuILx#FxQe?W5rTm+t|!Pl0z!R!5ApD@o6=ocyd)+sW&5j@r(roqUj}hxY0oYcbWJ
z`r=wavsWGVmwjolQ0-Gd*yY&Ru}?kQ?tVGD-RbT=A!kfNj$ED?<7=C+D&XC!ygkQs
z_(pCc5w3II)biwn(4OHI+dF;p{p2+sbBF&pXW*^#Kgx6+4}G(Ta93y)mTStg6$j^S
zH12r+>Gw@0Kc4J+bz9KH4iS3KOShkUvS7XDecqq(zDch6H22loiP}q_q;|dhRneem
z(~}bqcWf5*Q`%;a)WEzsIb8OaS&MMv^KZnQQo6KBZ`C#TSk1O`^b_WuPi{4K-s$~2
z4ARd&=6P#)HxX{>w9i~iG;B{?8C3mz$WN^UpC45F6cBd#_w^}oSSkl$@5fC|O3aBj
zGMF&sWyF5#Ci}M7cQf2LVD0z**1I~r<mJa^sh#z~l#u7Cd$;Wy>(OLQic!RYJ5yhc
z*_jo+W0%#3{PiLD$&^i(p0|oqMx-8f(*I)9x<*r~&#w}mRha$NOKZbsU%A`9FZwcx
zFq;|(yBx?-R9#}ZWSN2Xz8JgP!|p|F+dI9u)rZCR1J-Prx?tlr-m6LRyY}X5+41Y0
zHd*+b`OzyX`Gxkk5%t>dA8(pEv6V)H#wHKxmnMZf{MOp)!Zou#P0LH)=I>QD-=gpS
z#Qn{{GRL<wCl*8}^KL<mJLh~ebf&|@!Ux|NseJ&vDlsnQ-RkGUF7>9pPph@J<(*gN
zU*7C=xnu8>hmBu6Y<7REOZ&Nlf<KRqr(Hm@-wOx-_^5}9G6#2kn=Z$LoDS64o0`0$
zsI5oAgx;=J$xZ0@D240QbWYJP7lKwU8koJVtvoj8hoAqeJ^=n|pY1QH+e|_A9#2LQ
zmpN9YA0KKAVj9ldWL8OIs`b!OEQ{^9MOVF(W866NV!LW6uaKn4lW^6U<28_y+iz(M
z^=GIr%bn3FD9uwce>9qH+mGiMpnw?I4Y^PPbtmu+8=SxoA|W2q;Sv;rmMiZh!4&Ml
z1r!hsNss~JJ$@l*xslIc15OYGQIJEz<Iyz8g+kDACvIR1PT&JkkP10a0(CuzAH-iJ
z-jEH2V0evw0~6UFzlkx7;nS=Bb{wOOIP*SDJ$?~G^s4C7A{<mCK{n{yVt4R?SjdDz
zFzn5G@PioG4f&wohxOnEv5*M`P`5964So<0nUDwK8_P!h_zgsVmvD%O49J5rFzV0m
z-~!<g4;hdL>hX)%+L7}C{*%TpemZvX<8h1TO3IrSWdlu_M?WCuML$w|hzIfA_sTJf
zVtnF18k;D_CH~)zMHJ%@|Irx4kH;Sx(uYA-gYyE!_uh?(YZ96U1q<m%gkA!}Mbw*+
z#@NDK_4q=Jrk>OmP+LH40ks9x7EoJ2Z2`3f)D}=%;D4G0su1Ci$N$H&yqd-+(Vsk{
zaYeuIX8QQ|>cS7G=>NSJMBnzq{Qj>V%PQ>oSBz&BW0`B$t?)4|_9><}G`9UB8r)P<
z9n$m}R8Hz~treD7f{mh8b`s+s*Q(~l7}k%+tcv+R8@Ec6zRVV!zzh5!9HJl&c0*ka
zeuEfD1mTCX421tkODF;HobCv2AinMH1qxNWLS5Pvj3EqCARR1eM^Hj42wz6xd)DIn
z)G=@gv}lN}3tBwuTY^0ZN3pvhABw?Lm*YSTBtj~P@u>3JqzAkp3NoM&${>z%mkVNi
zeqC^YbP!`o^{`_Kh;gK1{HQ6o)aRIx31x<)jrSjJ5CkT)Rk%SAXf>hD6<k307p~hB
zyMiOg<cygDClKQ$>$bxl;MSfvLk3*y#PLlzkD;V9`|3g)9t1%Wq(L~DCB`jgft>d`
zVUPrA5M@oeARpqpGX@HDY={FWAr-_pzd|tXK{~*uC-#685aaRkp%`p!IW8z68sZ=c
zc0&fF_U0IUP$&c)+9YdG7l}GZjF%F1m3mTJKy3lF1=JQ$TR?3AwFT4`P+LH4fj_qZ
zk59OF5Z(uPe))^W|NFc9F=oAD@V~Xp#z4c3X9d}3vWBwzK{~(c5MR&Wz>vU+3c1OM
zHu7OX3SWQUnZ5y&<b4DEgM9tGgJpGO#s;pg(>z_>6^dYAk5Gkoi0pIL`FQ&Uc?W;I
zR`jbeHgH$?aSX8yz6o4I6z&RdSAX{a_etLV-T{h=Fd+&rUiTUsjPVWd3Y;Fo*mh$B
zyTH%@FL#A+U_eEf-h9vOABS-;5dN4t%Je0>CGw0arWPRj^E81mJk#acRF`SUY%9zm
zt*@hRg8squ>sWjq$0WaN!!$yCXL_s0+RN2r?afAo<l8Km<1{>Y_gBZW+u&=C=V7_#
z`hX*I5A5so=*bkDM}gt3p2bd#Ffw*8of<Ur`@6Az+AcgJ_Y>hpB%Ga^wfgET{lN<s
z`FUTv^04vDXC1yC>~&0|?uz%L19^U)(@lg6@8!KAZr=;V;?9Gw^seUIL&Iy8S$^;J
z6I-+!=C$wbI6awcDbL=Fsmy;ZGYT7Qef@)atbN7zznjs<A=e!6^P0AG4DM}7?XqY2
z&V~^~b}!1Ceca>xh{rkG*SDFwvzWFFDL*=PY(0G32RmbnSIy<>vG#Xb(Z`pzBgTMR
z?|j~6@OatT8k2vjUnTE{W4FD3siA*rTbkLFH5Yf3tfIc{FT(wGW9_d5i~TL${B%|;
zUHR0J9iOyr`YLmj<^6?;M;3e^5$`#tz2&quIqI?Y-|Rj%+o@O7<5x4YlF!uqVer~R
z=N>#;j{j0AKc?G{THAe3&DgkeOV`Ek>`*tj)MQ~d<(0Y%3T~YIqWxqq+Dk2jo#XCx
zlfNrme*2ov_ShE&>1N|~H@$Cew`Iq6>+S9HM`>Q?y@C`@{`HLahxb*Vs;D(~?~M+A
z3-5;4O2}<j6ra&7B=CrFs~z}uH52=b=y*Hf;pADCHo2*1wa(VpD73$y&}PKJ`OOnL
z*PPcvleSm&So?SFb>CIFKKI%XkE3Pbn#~g`>Z_80!hV1Lo!7&3KIZ#&zm(MfIrq+;
z_rvFPSC6$X&85v<x(*Jm+5MR1lkH1?yk+~{p6ahYB%Qu+YS+pu)()?0EXymcMZ0(-
z(QdAJy5VB)&AnI0m>Qo;-`%;xv)4y0^j-AlS(d#H3bwZx@CvuOb|Rd5tbOeAA5&M(
zJJfPY%Xw}3Zons#WS4Wjy~{HDE*;g;ufu$;ufNr8s4O`>XI6I5&BbjVuPNO6l=m7|
z!hS`8W`?J)B<$X#Tl&ncSi5Gx`aS(?^*{R4j6=yW4;x!d#RmcJ8swTw-Zu=(G2MUB
zChFenhIdoFe9q>(g^Va#T7AlvZsUg7@=hUcfC%TElk5Az+@e8pVYRrNU0(!hM!nc&
zsQcCWh^aB{;%s)W#eX#KG~}8`wrHOp*3q^~4|9iueNSIs{L;T5X>Rx0uBpC5<SnN*
ze8D?K%7R>TOU+uZ&OP?`9MrpL-5N!F-KpMhz5VVy8~>{N_YUf@_N|7xK3vl@e2>j{
z#z*UKFWR>FOtbsL#?St+v^jpsrTc>uwLY6O_w9m+Hys^6C}M_<332Sud_!1^p()mf
zTSdJt*oliu$<7`|RYs(wbe?CiGHdGuL+g$+A517cGHda*g}Y`)O)VSZNV$^E-=<A0
z&&}Lk)aUR^&7(!S@wcs-_mz3|J96RKfYJUIPJQ0WWRs=xvh|$K(Mau$tMz*uU*2)o
zbeVkUfQv2LooRcaX6<I(B71n?udklS-|J6vJ&TQdoNr!e7W29L`JMGgj@@xsV?)h(
zt_Q0;d|m%O@6V)kl&>#Z_Ta#_c~9P~YqGu8sw1Y;Gzw;SS0?u|jvE^Pm61E&ER&A=
zctr10lROrD`2PI%sp_%z{yg(I*$O+yzj^%AkKek4TQpfz{zcq9kNxF0hZ~ty-yUBw
z#bfu4v*fM5WaoK0A9__^>!vZR>-oJm`g}1z;_)@B+vd}sR(mneWL>od**y11`&;{d
z-aEVAj<0+@e>l8r+gI<p&sUGN7j|}DIkx7}t^P6fr(DUH6zlNSyE)4yeN+G5*VjwK
za^73qugO?bo*m_y58hUJX_9n**Nwe8u|po)47PrdJK|~6<POW-ZfLhS{_GmQ1$d7w
z*VI04U~!}1h)0Z*EbYztzCKSce%mN_)FF$(S<{`$w&jlHJ+8e7xA<KC$<5Y7zPQ`6
z*VIYx+SLkP`efnTE?=H~e0hG>xccL0qsfrMz0O@3sf=izFiBo&=WPAexUowVCCvv7
zOEMe%Ua_FnW!`r`kizvl(&$^mN2Z5#^ZS<!8ep;TYn?Zj2c^5Ti3pmmQ>Uz4NxuOp
zT&P#k>+$6}&p&fD9a;C$y2R5_i)U<=&2|cH(dWn66A~$ZpIM6d4ZZ*Q-U~zfpF4ih
z<-tCCv;Bk3-><X!DtzMAQPp2xOn=8SMV$0J*kAj*fr(n(^z!RZ%Gq$SY{A)koo1Yg
zirMXVdHd3;2m9&ZGgP_{yBxft-l&IO^`9vAYhO>E@?1UEzV9Gm=eYfCkC*mYvD&CX
z;j3eNANEe`_D)Og^kPfEk@q#9PA%NXxHu_X#F3n^BirlsY}-4zt)-j1k=eHW_x<Hl
zV^0;YYE?3;4bLg+vG(e*_9MUNn-%n1;Xb?hUWX$oeKv;pF8Vn-;i==a2Mvo2J$3qQ
zY<={|3N3Bw7vG^GoO-PN;5*;7(5!3Gb<f0yhnmv<vPycMIWctUyTGb*Z)a#Jj!bhY
zvi@oIy+Q4o{&;@P*pOx~&)?_XxjFaHa?Q8R6|FW^eRZeHgu><_{SsH1nU3D@-AuQT
zZ<C+NcOMwFi#|hAeiZaO8SK|5#Q#md{`)+K=V{zspHnn@%oF+Y>8~3meZOY~`;*!y
zm+gFWxWR%~kp-qso&)=umyOzX*+1^V*CBSTZ3<K0HvEG7M5%tBF{ODc<(e4nFCz~&
zaOyBG`cdzg3kJFd8&-Xv{6kc`@elC5CWTXvwO5a|7v)svNPHWY$K^Lp8IG#6X`f+Q
zQ0v{z#-y#(?_>HryIHAdo0M_wmus3j)!H|H+l-T2PRCV^HN9hBYvH#855!d&V6rr2
zld|D0`obnl<tqQ(*RFjV^zm$Y>$^ezLtC_2_H4aQwdVt$`F*t`q3}`72>gRf&y8K*
zYaQyg?VPPcddKpEn-`jYTV-va_BxGbJD&_+@xOemz4YF!;(gkuW9@m=lE%!_JyQD4
zaU)a=zW?7aHvTu?_oY~>$Hg;-oxY^%aq;w}<z86*U0>Q}xeri68e9X}IQkxgGXz0A
z<Uk4NyU-^YoFHF=<tp@>1_dOJp#L?bFkcAb8}n`uPS|)zhf7cl`s3NpEc#Etf6BOc
zIzar>W8w?d<KZc2>Pc+@wFT4`P+LH40ks9x7EoJ2Z2`3f)E4;nwg8W|zZw4@&GI^W
zwTu4i$&D)dqW@1B<F6jy&vzAgC$9ry@*@uepmI_$KV7w~OPHFfaDV0aep3!+1Bp-!
zMzpK62YU)y6r@2GC}~UC4S68GJ)NmVc#zSS8w8248-#yAbLa<IpvTyKF_zyR@<5OG
z=tkfMVl026PzGUS!6ne69m59vARID4jO91dC0-!DEu9FL;6CWkZ`20-ARG)i7aSoH
zVj%}C>+l;yg9-Kwf<)L2d7m?mpT=oh2sb3XkPpR>(tvp=hDhEQq(UAPLM($uG9ed~
zO^H8T0=KsO21$@lpN95~-M0bfP8=WNLD89gK?W3qaTja`Wo9Vv?D|0>eQU*cgpGOU
zW)3>mqzl}@sCz}<q$o5KL<Y788}I}1&E7N+-{Cc+z10Lv>7(QZL68Yz9KXyKdxIeu
zgDKcRd)}WI^+CZ8qCkw>7j=w!Qd>Z60ks9x7EoJ2Z2`3f)D}=%Ky88lJ`0FPt_lC;
z@&BHI0n@yL6)s`^3YS2S$$WU;#ogbltGSE6N3bH$)2xf+1mNG%2S9~y0pTaW-y;O?
z0s)hR8~DG*FMyrOFF-iYwPN}OZH*S7+M>^+T}>H}#1(D|Di3dM?MhTCtmYc3m}n{d
z2-MN{k@oPrf4zCkBfi!K&gd`=4SXdS7z8mti)Z9v8bO$ze$T86W1V<T#h-w*tYo<b
z4ATgZwuxdso99Ee31L=R7lZm4N$c>Iz&I!N!y~6`lYv<08{n&QuD~iOya_rBhG|HL
z#YcmIft+Q*FbzNNfJq7|8DhOX>#AdeVH*Cv0j_@DliY>R1_Og;zlQgifu9H00B>(E
zZw@Zfg(*~N@bI4G8$ftHgVlySPm@MXnQwr?J2=4I&owASA>-JZ22L1P3tPWsyIU2u
zmX6V!WnU=`6Mch26t3b(tddocRr_^28@BUc-8_3KkEHF4S(XFo3k?p&m4s@`kGBhB
zJBCZjN>tl5A>KTitG261Q?R$cJJu6LO**F7zS4(8dvPK%1w$j447#GM43^?iSu&(D
zA@b}GreA$Xi2VDs9K^Bi<8qM5^2g;Mh2>Anfi3F{X`7&INaaApw}f@MMDVZv&W?9q
z(yIB)BxS32$%NAS=521JZ=T;h|8R7Jl$rZRMI?9bId9LZT>1j{7U3+*mmEAA{!79P
z_x5`Sl$Cc2f0ER3%*5OUvy`DJMxk+eGFgPQzh-qBANbL-+N)U?`_z(sv&zJ?Q}<f$
zE&P}3wry>^;O63Fnd}s88gfma3z17@JIzcw?e&hTJ#XU6Z}Z&F%xrbj+t_hS+K_%l
zl$mnrxN90W(6+NW-SxA<Y1-3HcbXSI@^tQa#gY+r%f~e6ayW<a9EWHdk!vnG=2_#r
z*;&tKguTqVnOb7_I^&(gLA$%tPX{|r*S$pZhwSoD5pJqi{na-P>i3$IHv4?*>+5fI
z>ss60<Ckd9bE_8hJhXi-1<{^%7qt%zpZ{1N7+t8F<(dUv;~#wgL$^sQdW@MA*5crS
z!bzqJOPi)!E8guX*m}%-71s}a5pLxR!}m(Bo8{vM9jV<v@I>^Q;O{)w4DT7?IX3g+
z>MbT^)EWInxUV{#ZW8sn^^jptwjH*&GVrfCXYtgL4#Q_BEW6&;PHXNK>Z*PsT+8$E
z8`iE|Ve#n2zUb-o<8GE{?3^QWT)M$}jQNc<7T@fb$-a@!k7$d84&`4CaSH5t_QHo)
z&pSyGgUe53pKNkwc~No4IXj!lWYeVmz14TSFsJc)w~0B$1OIsJx!PAo^$U$&^glGa
zrDgt*rP@sfE$ZXi`5T$+9__Gl&DJqPW2##!;_D=xf7E-|Wv>Q{$7~v4eC*amzl)~L
zjsJi8%BafSfn2l1`K9iA!|1jJudS~QH*y}8*HCG{LY|y`z-_*jX5N$AYF`=uQ+;Ll
zn~D6jZ{d-rQ$=%XkzUgczLtq)g~6F4Oa|=hR;|yIgYN@B1j%Hbhly~OBNXS-Vq2d$
zHoVXAl>;?;S(PSCx>)RKb9IdSm_=EI%VjceDcriRlKWh>ik)ciTBD0)jZ<$Q{2YF~
zr=i*SgL}dTp6MUD@1OV4VK3Ex&I`>KWhNV(s_}E3bEWsoPki&uq-rf(4sM*V>iU({
zFN3&N3LoWi&0?GGshxet)g5`<Sm&|P^QR;BFSv9@tIGcJ(%xqiR=4XQlYKQ<g!}U`
zMXMyc+)8_!l$N}&=CBuIt$M#&Im69w+Wza#PaRAPPv#{y-k{ApC&^dFpVxnC-y0g&
z8qExQ>2h$u&sQEknc8;W=(P6BWU{NaB0ny7E$uP(SW&YTdUdrk$0d$TwRvdqXmQM4
zo9dURJHPr@_}*9`mDB5k^1Zs>>MU>A>3x0kd7t-LQ$D4r@v<fbM`oM%@zU}+r}oiN
zeq;G(o2zcoQTyl+<#f5?uG5!pv74iY`i8zY-Z#+FZn&*?$?R4W?~FY2q<{Jone3wU
zys-Gh)oq79jI*BL{PX6ZVB72aZ!AsH4$D|E=2UdzIh|uX^Uaa&uXOEpc}G9V&$;}1
z<g$sW_2zas>S?7Nb~<)zs-cy)k5igVHc5I8m_7AC{_r1<cRaiL*rVl-)*dd?e6&}7
z`pbf-S>YRNy+~qzKTFRa<K1)jhYT&A-`=#Ey{sU&QLj1|5{$F=9MRrac<(^lRi-jo
zh*VD&T|O96x~F&X`Mh2kFCU-v&wew<B<J&H@z<-rJ>*=r{R-77?{(#xT2(FftaDTQ
z=urFUNSazU=k15@&*rUckyG?V+M6#vd}imnZ`YvG2@fLFJ~~>rJN2;4!e&^#4SIKe
z)OBsRZfd(u<&NKS4qd13g<LaV_Wh%xHme#uZ|c+kg!|cd|A)PEfy*h||NqkkxfdY`
zkAx6Hk%SOJ2)Re4i(BdTL<kRxh7dvsp{5W*Lx^D}G&E#nCijLAl9-SY{_nMWGKQIR
z&hNbD{Lk-q&a+>y_w(78wbx$zyVhRM-fOS*-9r}WU(3G|d%~>MR&Te5y|d`YA^i_V
zoYF7YFz)fv@k443_G;N-@s2PrzmlzC;W6zNY$(yX5JTS%DL%E2j{kNa9d(9^a`oDG
zTaVHi35h8_BbsRKsgl}j-;>K)-BP0iyFVWvWnRMgc_-19_z(DeGaMkoC2aNEVYX!J
z*-@e1_`(fcFzn#)5e@C1RvKB)s!2rTzN<3XY5EDtwcO7%O>FT@^Xs7+8@IhYY_}(S
z(f3|YOoBBZb{(HKb@pxAHq^d6ECPpXU7B{iNyaYgn@I`R&l!95X~{QPXup<g9oyGG
zbKD~97GaKqPu+A=YHq)C^yiFOPYrJlU6|f}%l`R%PlvpdYlUUje&T1kuIf*(LsqGM
zd8mDP{5YWUrNEzC_&z-{wat-AUB@2qZC0&c$JZOUPn6n`{PyTImvwbg*rZ<CY<_?F
zp&O-YUmoH*dY-!~)TsNrb_VkwXvMymn0epn+`{`27M-G#r=OX>DYgr~+@yM~;luA6
z|FS>t!p;y+m$^x<^`>0PpKG+{;LvA2J%$$4nUYUmNXgF0!?a&67}Ri1NJ7h$hCNqj
z<;^sHHu2>C%f_#xzFz0J&z*0iN$m{5Z^!w^#b(AB=}nmSeBmMMMhD~VI~#24x8WNf
z>wWE><4bFYR6pOF7Wg#jz^;R1CN^51XteO~ZT}ae_NGVd+1KS=?xw)V)AZlvT^;Qk
ziNlgkIO&evzOliy%8N8Z(hJnSJcM1;zC6NP?$0^3{^bS5qDMcNI?&fwdcJ%ZdZ*%o
zx7{At{5&9ebI|5-L-uLC`f+NoYn$y!t1S);;-%hmn$Geyu%YUGsd#5yR6!=An9FXk
zUQBdpR*Lu7{B<eYqlTzxax+3H=Ca1<aFo{pN*9#(t;%U=Q&fRANBK*WnWD?kc4#un
z<EZjD+5x?da%-!6g7Vj=e1URVDtW~%<I+?%M|s3mc1CSc8?-0d9p$~6atO++2&H%j
z%&QRPNVG3H3AIPPQC`z2r=yrh8IJNQPPqzoM8870rBWV7ozT<h2=od%61|6xL-jOe
zvhiqZbRuevdZ7K#DX1IDxhof;-e?r+i|$4J(QnZJ^fZcXl-cM^^d343{RN$kiuc%a
z&^l-c+62Xh${y%KbPO7X`lE}{F!T#F23?NEp)1jS=xS8-L0E%|{I&ws`(^39v&e6n
z5M<(AznF9h*8r`BihQq)iucm`Xf|R0lYOq37LxyvG7&rFFb@%sMJ9!^J`qB(h1v%T
z;}f_b)jn7lpTV<}+6T+O-v^7R<39Dn5?+PAIrA7-L*;2jB{vx?l=$jIlcALP#0C84
zF|SSCW)E3h<5qPTW5c|t@A4r3Ci%>IF)k^TZKaE-mzlQ;<(Oz56oWm>I=mOM04H#u
z5|%w>ALdQMI40_dif@s+qM2wZq!6DN&twKRkj*w{Gz#M2B;<kiVvd8#QF92s#h4(D
z8C99{fK>RO_;As_RY7I}>Pc+@wFT4`P+LH40ksAG^DV$*=I_S;Z|3<{e5+ja6+Uah
zv!a1aCi+^JPoj@-722vq-{iH8WwN(C{J(?pX)5#Y#d1TLOanAQ3r_Gbc@MU+?E;zw
zm*5JBX*=tCLm#oPYKmh%9uh$G+fGDx!7P{!AutaXKqxGMr68sxbPw!<WH<m~dcg4>
z!b+A`!&>-)<p@~M{00zH0n1O|DTt|r2Vrf_qXJX}@o-!T75(IO&~I3-j8=hDtaE@w
z(!2}$GrtKogO~=RqCe9}7y}~+GZIEY`6Slc!CPnw&*24#$rNn~X3!2gfSBH+n#7?E
z6;*NdWnCZU`>U1*uv{7R!HIN?gwbFQ9iSDo1~GL+Euk}XQLP(;`a_^<c^v8t<6#20
zfd}j&{%ddt%BLjeZP?Zw#54(=0@GB>Rk2+)s1EI*J#++1umWr73f-Uw2>bRF^Js6>
z4*G&U3;+ih3`0OnHPD)%3-!Se8h{ZrghtR9<j@4ZBwl0mHrf<5fo9MgT0l!^4Q)V7
zdT1?}&-pBbFbIcbumV;=6s&`2*a*qQ9fNLxSP;|4`_(2seW(L<p&p1n`C@w0h<xTc
z6k|%FxE96u3?1gh_zH2o6w*-h3p|3yPz(F(^33ur#}PKuWq&=W$-3%L1u8-fs0K37
zgs1G=o$&9`Vi0yY0vc?)#Ih!FXfgk<_7if62B>Th(^d4kYW@y-Pc^T>xoN5FD8f}^
zzUD{E8%X#6#7~Gm`_}nr|2mv+T_~UQuxV{o88>8ogO9c~W?rsZu0#6jsnRI+?Z~{P
zYPlZ!8>r&w%(^bB^?gu#)%;-8Q8n*`j!?~yL7i3e6H!mqyzsA}t%_3|Z$9foRonhb
zA0eWi5_OEYwnaTBbTDN>)Q6&u5%obLHu#vGEboHdkObmes$!}J;;+UYc$Af;KrR$P
zDd_XxWCEhiHv$U4oIfyI5WYo38*3~iK`MwgRU_I0oFNHPAstM#X>)~8$OJi$y^}#a
z=O;lLh-ZD#9$E@IJkL9TGkAk|-WSjMF^~kKc@B?(BuIsH$Ob3c9HJl&lA#22s&bBC
z3Kn1sH^79Gw*Xu4h7?GLEVuzBP>uIQ`d|(=Fd95S2{Dib1~rHaEWj2bAqVoI7_4g2
zRsf+81-9go5=6eGK?an7IoF9ZC?N^bK=?kn0R=FcvJ?sBeosy^Z%^h0LpVf1Cg|43
zzF-D6U=Q9944H5Ptay>&3TcoDH=qED_|LVY{D}XlG!Xx@exQU1h=EkdfNYRc4>^H1
z#6k|_Loo=SDw%Kt@*%|-g%Z$i%D$k42#AI_I0-kP2ueZ61lxi+IKXJ|042mgwPxfi
z*nxI)wt)ha5Cb|b$Ul&S8Q6md1Vbo9LK37xHsnG9=$LX`h=EkdhS-)IuNCDROu-I>
zkC<dggAB-qBB<7yV}cFXg9rFQ1elv~T!@7vNQHFBg<{ZcLs}u&9D6_(<b!s5&IQcD
z2JB%pct9{jKrEy{I^;t!h?hLNAO}bA03}325@bLLn06#yZ~!GlK`bOg9%x%|e6WHT
zC;$UX_5(Zq|3V=dPC^JTl9C_?@*&NN@K6fgUDzLzK)mcS2U|D^I$enqlHdjufVmB2
z6+~Zi*KVW>;@}2U>rR@%0V3ce6hJBH^x%AZkrqgXlaL1ny|EpPhGIKx-G?|p0l8q(
zmunfaz@Q&tVKjse;Cvt-OdPmYAsnK?aS-zm4Q4~RCLk1|z-AbA9R!2vaLyk>KxYEm
zzyZQtC_9h`GIx#-c3|X5T;KuGkO?;+ZW0OwU_XU?f=svp$v)&K=uD>^fZP`w!emH<
zY{&zBKaLH~;Ng#bAPaH=*f)@Khsh8PiI4&(Aro>S4~n1^bQHt~axeocumg)AY&8P~
z1w=v>-LhvHaj!4#qtuhy0{=}G(B@<({?p_CCwsd2eLnc#!*gQLBp0#GWwNjDwEwj}
z0RF1+{?@AT{tlXDC5KxY@vdCDm;J5-^;n~-GHz8}dIu=%JiXk4ycIpYy?x#7v5hpI
zyKJw|ex>o;VjQ^+o5b_l5Dho6pPOQe?{pW%EI+DVX?#3Ymu#Q3-NQ}cR<@2?FPV7O
zVch?e*#s;flV29kM53AI5)|kut><<^y1yHu5#Z?`<SB;HOY6<icTyZ)Q@lN0rn~ug
zO5@@A+f=2;d&+dy2l-6&q?(qMj}Ol^<T-@@v;U^?-0E@Kvz8jp`_CPxtsZ}Ed~e^4
z(D<5_do0;=XKw1gbC2X^hiRkZ9#gIrbK?Apiub3^YISD6Q~RDb@4Fs3-E@M9L$xzi
z&RtHDUFY8MtBxYv8^x^1%0>~>2j`?*OsR2c@Se*-{pxh8)Mv})Td#~fp1kM&l6!2q
zR*0h3ZO3+p9(Ad<?x*icDs11b=elWa>f01W1>09&Tur~gy|NVFyj9j6Z41|Q9Fwr+
z;_1Y|j81Phg>4?u?A2WRoGm|Wf5UO3xu=$E`7Ymiee$*;{pKyKTH*iZ_-k+OYvo!I
zPpq4U_lS$I|LWxH%Y9mZ={`>0pjs7O$HJc`3<$k=zN&is_5aoJ*SGtK{4HIybMDP;
zJMS)<UFB%)#?69sXBRv%yLqQp(vgza@$p^e@Xb@H-2eS?+UoJr-;XmXxOY9Qn{D{d
z=j$3Bm~WP@zm(@q$$p78?Y7o>u(RsUtLYy1WN+qF>s&wW<)NCDmvjmbXmIobZ8eXj
zdTpX|_|X1m8cZFz|5@b|of?~DTO@p$dFqQsdReWebyMc?3|)z5ak<vt4_AM%2sdGs
z(x|ZB{-7P}Ge^GHnN?{~cIowuEA1W}Q@CaR+G%4L-=>t}D~|HoVGwkAz;tKLU;cNE
zmu^fu1m95ITgzkAZTt5fBW5gdd)DDWK#AqL2lX|Qvs-x|(cd(JHi#hUJVF*&rF7R^
zVv_q-zw4bC+gsyCI_}6V2^{IwYUcGl29s*h25uqZYqWFw-B!NOqxa0xcB^()*Yw=Z
z{Q+Gzj*8h?rB?L@h6RK>CdId`^XiO=bzXJq{Z4OCV)p!Pmx2m@`oXSkBU$TZYeIkO
z(t|bvDSi6co{29tpLcO^8u4;|t@R^IhmC8#C&qlk<(F4`pL^q2iT6dc$;h=rm7)6A
zo-df;(#U1WoXbfwHM0#CE#JCbQK8Z4FM~IQ9hb?*O6l7*-B4cVoAe$<KI(DMORtOf
zNTTgat{w+{qTcSpT}!`jk~d`h+;_{3Y2K9XU(VF1J#T(V*uqzB9p5P;hl~nzY-7AN
zxar_T>toHsU*_-S9S`k`)Eh>c!x9tQFR)ylzH@?sb=%qZCcHU5XKBvjeRIS8O9wgP
zPl`4|xmM#wRu^aQF6?#exz>rosxh~^826TW*d71jNxzXkmQKA&@E1nemuv03sB<E;
z(zbQFJx#9cxnsUUKDgiIX05+(^+WZVO*)5mo5;I7-p$Chu0GCkFEZ(N$+)0nWL>vQ
zd+QA!v*(z`*6Isfj%eP0Suc<FLFqi+Zz^1I@9?e#k6vwTw7bTd<K{Co^5=F{CaA|j
ztH(iGnsxD<xgoRA=~>-}^r@izT&`t&sA6(l<%w(6<DeI%kE=J1_U<%$VV9R#t3#Cw
zjW<t{zv(;LdhNI|%M``N1BS$P9Qjre*8B?ZVeU!c?2b41%HV<d(W<$9iU;(wT)ai+
z)s+FM&Mg=E&D5z?`d&%9wG=MMqwwYU_c~8&yO<Bxf3Pw3eE5I+IB50w=GpIijq5q5
zWmuif0nZ1n9eC%911`n9_vtUn-#7PGO}aOIZtVSQFP#UjT^xM7Z_h2euWqZcq(}UY
zl?xivco#2)Yy4H*VvqFttD^ivR&5Wfu}*Q$+Hg^~YrdAnJKuYmcbLaJAnCs8)}8q+
zY8`oCmax>;UOm1!B%1b4$u4K7rpCJ)cIckGe{<o$YnM*H8o%GBP4PzKRWrTb<&5jm
zlm0Tiuaj%F?7M1ot=U2Qmi$m-@>`pX{5Q1%`{X{{IdgTQTeH(g)#IDh<C_z{4R1aE
z9?yd`w#&5)&JEM9J8IRUv`#TqR*V><f89A~W~Fg!#?<R^Cauqy5w5($mBOjVHy@Z;
z)coDjyy@%X{lm8H!uRq(VZWSLTV$uNw%cww`TOrY!V{iV`f6bvvqR&}lf0U1)Ng2d
zpZ;W0xML;OU4F>v*sJmTHzm0Tl*aM8Zjanv^)GcSneCMyk-#&L7*i|PI%P0AtGR6P
zy)TW5PPVb^__)Al@R`~+2J7Z7i+H!NeQ_lH52bJqoSko**!tbPa5Q6e_3X@b-*&6f
z<n5ablfEZA_ji04x}>bHid?I&gMFV~BXbQsR?NJ6`Nhod;*ZOQpPF6wSioiD&`kpZ
zc|U$sy1!D7Z~kY;H~-cCil6hoOS~Ubz1x$CcYcl)=zEBofSBmAq^ylLLk-a8XgFd1
zlgG{e;dohLi&^x$00)>1ArJ#;kPW4vKO5VC1NcECBta$=fDY}SH|W1p0HvTyoo5Q8
z!4JYA8WKVD@yQ0!&qt>VeR{wd6c9&xG9iok5-_l)?+bW91f)P7=<*C~10Ep0jg<^J
zpiSQ&@qH{O2!U8ghXSZZ9bp5LAsmv$GWQ0PK|M~EK0Dn1sK?3DCuuC@5tNVuIUpPh
zSiorTgBZw!V$gM_9Dx($(wRV)z6N%nfY@PN50J=w0hmw;xk3nGV;~i>p$K%x6VDvV
zG<-TnR&l$+@5ablC@H_%#EpJBHulpov0^;z-x>=m#=-u*v9F(wdlh3||JHcde|D^E
z1m~Fy>Pc+@wFT4`P+LH40ks9x7EoJ2Z2`3f)E4+}vH*{ZzZ?I*j%CqDT=XXw{l~?)
zKQWeA^aB@TvqXP(!$$x5vA!Y?{)+Lw!e_unW5(Y@4E#^V{)#lH$Nvf|FovCm%m~q#
z$t1>oZcxn&n~L$iACK=9^M7xQuV^C`?WZ=tD{bK;QTR8M#ez2N8^V915+Xs2=N0W5
z2DE9ILLTVTE@2CfV8Wxk6L^5|(<Ry>^kFhYLn4^c{@@2OkOa20E%<>F#CTodOG~>l
z3Z_+Pp8-FJg)GPgIsI#$Knal$11BL1q%piTNe`5dtxaXV0E~2LFN6%PA>mBX0_-3J
z^1%#S+CUD7@#2o)3K8`<E);<nKkEUJ5DTLXnTJ@g;Cgh12#5i@#-ts@m{)T-ZA1_X
zx~<s;P9Vm7-hcwoAtP+S0Zcj&7kEP~WJ4Y#S)fo1j*OE_glx!zRBO(wEAc}nn3Abh
zAjU{0!wnE^qeiraI)MjxcgG%(1G)5F(zWH>!4F~~8PXsFvLP1=pak-JvR^M0OnY-q
zpo4uy-K3t>7EoJ2Z2`3f)D}=%Ky3lF1=JQ$Tj0+vz~hr_!aqI!-`#im49@_?=Pm$d
zy7MJ_pNZ1Yf846r=xMm}oW!VjLs=e=UFAAxihF=>ps$xgZaS=`e2AZ7iqDkUd>~!k
z+t<gBG3Nn1E}7`LxXf^OaZ@M)rc4at+whD{H_@By>Fwtk@bOxFm$BYWA-*Rs_8|o>
zfeJT;r;Cr<bhk;KK76>nEKDF@GcSu*gz=deNX+7+?0=O%fW9h!0Ny;OifM)>{^C#%
zv^vjA$z|VkFH2(i;jOJ*TxPllN@fdm2~v1jNxlJsr5HZ@>DiuDRb<wBuILaxj!+9f
z0ZQimc-9@F;USIT7wf`VSFgF`2Oz+md9f}MZ3;s)yglinF0G43KmGoDEbD}S!}9OH
z8?vvQbrC#k4bgB93JAcYE`cB79nH4pQuv8MUd-2(Y3YgQ_)^Y$KKioky!kGKo}S}}
zc*rAi!Pm>h-Pgm@#m{$&$R_eoPtP1JJD>7nc}UI)M7++#Spr>&x4J`h8S=rGL7Cr!
z08hmXH_@yhouB=OxD=i~er3K2gujCFG)^Y3HWFs`pt88c@oiZyvy;MC;pR;OgQT>H
zeMCnu4_HE&MXG&-j|D51KRv!UPC3@HnxYjzRw6DurUt};$z-)rUCKt*VCnc21*s&s
zU=7cJ>1F592oHWDKmTBod_{;fN3!vCBauIxe^9`57i<vZS!Pd>$D3(mpnPD*DbpoK
z608$GCSuXDbbqu>b;hF1B(nVrU9s;>_sMSJy42H4W?c=^jE@O%ok{CbS@&s~abTUu
zQ*m6${e|#6;Zc?^j;t^9N%5PX3R~6*f18v~yj^&c`m(a*hmDG{TO7-Ghm_}2H9g^<
zG?iz6EtwR)?5dac(bE(8UUuvN&p<qHu=rVCL~+fC=``_oM3d24oY%==<#|zlS^kzA
zf1Ve*J@*rbxHf}Pac!38i|X3^o$W=L5&2TsOtPbIP=LF1zBN>N(o~9Lx@23C2cOzo
z<iW@G7V(W{-KX{w@tL!}%obCm_^en~#qZ9nw9XbSyS}N6RO|fEPp|7z^1%bUWwGs-
zGCN7v-*0*C(kIw2Komd8-r|}O`$V#j78mRA5oP%&(&b1TWwud#mN%w4Y-AGOVKGGy
zqWa{Ga+I`x`DGIL@r5GtX0o)`XFnh6O>xZfyb<Sj)mSWle$9wH{IhFD$+o|B&4jc4
z(`zP@b)V*;$p4S?P+X7ZtW)I`b?oocC2VH#VY~3*qNOL=Ig4r6yv6#&GTTV`L9?4G
zp3n0`>|=s`MVKu(6BKo*xUTKdkMp~{?rN*5yTWNB6;l^>FhDI(?RH!*W288IJbm2#
zX1N4P|6d}m&nNkZ`by+OneQ4GyN@pnVS~|ZE3@y%+lGJeXXDEDQfkv78ZN`jFC1~L
zP5y1avh`)VNOlt6RWKs`y$SQ6EWMJQXa@aLJBfW9*~gYJ!^f7{NnB^Y<<aN175jv;
zj~)B0`DmZt^6mHg2phLm-8b0K)+{D}pt_dY#_Lk%9mjoK=0&|-OV?fm{CxVIegCNZ
zihLIK{j_|#vhL&ZDeP&*y0UuW_vKKexq~Xr!k?v>=7ab@n+XP_Irn#Ircf~bdEF`d
zkZy6E{Mj`b&9*-}r@!)l%$8#aKfC4kJ|CZJf$CfX2*cl$Y$_OvI>}j;KdQeAR{z82
z`bX#U_x>Bou8lwcZ?NU~e|8Q|HALzduS^{v&Y=}*#5w4W|NS|L925CvAS#E?rw{oh
zXZxS!mnqx+==`L5j%|Ndhl=yJV*4NcH`;#Kuk8HoS^l`(mS3MA%5B;0g;c*~aULJr
zMbw`~<f%n<d?yo+Q<)9^Zv83t@nfG6#J6ceS-l|6X)?=Y$MtawcHv&wizgM;&7&ws
z<;RO--+aOrsrD6V7WGA0z5o0Ap?sfQ_Tf=Q7VY}m@suq8BgZo$&&9r5-G19wTxb8t
zzK-nskgydemhCIj`e*<3AJ=8V->jH~U3ncP`SNW@Im^OvEvsg_D|{!4?V^muikZ)+
z5C7TXx-Wm$NoHR7kuSd=74?)k>&k5R`+BPU{;TXit?VALELVQJ2mQD_l>Y~c`^xfr
zTk)SO>cO&mRZr<YrI_Vp>WII3Y{`F{@3bp}WsIrv_o%n-+7aCzlTzkhYH@Yb&CZ=_
zx=s8w!u{f!CEbtio=++H-|l10ZKODl0i8SE-*R!qxp!ma8}g^x>#e%nrsJ-jItTYQ
z@%P$1``Bsj3#4$jk32qmrNy_^{hw9vxfyo1$C388M|JJlYvBIt8}0kddHfS?22=)&
zsc*PB;CPb$VDF7BzfY{X@<9BnA5WfIdg9sGHRI1VX<4m+=b1qwoXwK!D<0pt(?IXb
zw90l@Zr`i%{jzg9U3-l4bZXIPe$}&exPRfjv0N)J*lk9ufkU@Xj#;|lKig+phg#x%
z^F7Aj`{vuulU8*bH7U61k;4U(%oo3DoNBFjy+42FDT_7OnR-O7wfdRCTcyYK_u~c}
zui3}<OvL(tuie)V?Y_``%*o5^;!R8O6Wd3GTifP*qwtq41`T<%>zI8PJ)i3HmiiBO
z7&>?JimR>qYR`|C$p%UJ*6dQu)(xvySw47nFk)uC=<CHAd*{g<mv6NmWpQo2<(G%>
zqtAPAxmJYb<~HxY806&J{lX9LqTFxCEgbm%Ovc$p->)nzYCCUl6WWiY_)2tLf0);B
zldD%|QUBLwRbOjfou4yk;)&7_E#uAZ_l|$dHw(CtmuvO=Wqqq!dUxZKI_zJ$*KpyW
z<Rv%eo}PGV*u%`-n_AA_Tf}>HDZaLCTMQlduCIyZ3uC$3x7+RJd_RG{3;3wB-utw}
z!11yRRi^%2PxHpNr*3)vT1EHVu9S|`)?eOJOnGT5m4l>`Z%0g5SU>FlWMtvKUZW2z
zyqMVG@{vyFllG6<F>3!M8k1Jhw?VF@bMt*zf$~}FI+HseyD(&3l=5Bd-Bvo+ZiSqh
zdf~jz>PtLFagT*Bn6GZi`+OsRRIgh?=j2vln|>ZX>7GWx-YGBp$L^h^w7UJD<J;}M
zWWS2%cUwEwuK4z9y{WRq?&FTMjr(b_&08<`5emx|7dJdPLphbgy$POs+2>WWp^jf^
zclHVnpWpLz*7ZHQrOhh!=|1OCugXf9Y@ifw&!mHfT~}TBdS%T&^8weRudwsBs$ch=
zba2--t18o!x5IjDJ$}RH%&K#vtTuI>H0D|Td(@K~rTAvrkJ!+4fAy&7i_160>}{hT
z@Wym;XXTIjVfok2jy0R=L0g8Uh%fqXXZh=bmA7(qc1JzaOYJzm>h`zBedG7+w%%=)
zJ3{L!eW#@3Cj2a$*jt{MTg!^?I4?VIyx>#|n}iGF_W!W{^^&(IX2tT28Yw>cmRWC)
z9jxrHs4?ciwKm?1?}XIYoYlH8Cap=J?{Smndl*~XQ5<(++gqFOPn~0Bla+Kq`$9d9
z0{gtpEr%UhWW2e3^#x6}xbNCOLWE207qlk2Thk|lU)yvq-JRNWP0&{cM@Mh;?6~~E
zrsNyOo&Ry4a_xtR_^gI0E~Z4aICE-fuhXmhYxL;yX7i-WMea5~jdB~cB)woIz7V8v
z8`mcE`l(Blm)=W_4pvppmE8L!<aBp~j^mH)5AOecpP++$S4Fb(-}iZ^_GPE`W%nkF
zerdf#`5Rch>nW>8yO)1=)AsBAm0!GzJO9JEeXD=8c6eE3#f>*L=!@2XMi#l&dBdfi
zJ9@5*G&i}Jn%ut4lb0tfb)9t=Se3r?3$VBB_k!>2NaghEfLxERH`~h%+r6!4v7m0R
z_3x(@HeAst|M*;sULM+$FY??XUB7CdcTp?9OIp3)XtQa}7PRcW6`ur>T`u<YEIrwK
z`G~gOZ5C;7`Kqd+viSVGIT?P}m$rPkzF_BL`Z9JA`BCWG(ct`#o0GR!ee=Y%s8aRm
zoA&pq(dWd^vyLW2-fw70W0z$Q5pLOA!{AKwLzivB@4hs=ljJe^LauAzu)^h)r^R<3
zH^`R8rRaVloM&d%ly?@E^%DvzMrZCD>#G(1Y@b2ZwVM|DN4Ac(N!~!4jC6l>JigMU
zA#H6nyID9K>3#m{(&s+;ar3*@bV-^rNZ!of@EL7vlo`2JeDxYHE<W^eAJDUK<9bDm
zzQ1RQr}ynA<6m_B#^FE9=Us=P;(YJNF3mnW;kECTUrXP2w6#yqbgQ|cW|vbFDxI``
zHpta~J>U3}?u!er90`20zh}{<8$HsVKfK_R@oJuFX5A(+S1Xqs9bLNnN7{^}eABLA
zxqqW;^T96n*EbH?Z}YXuXTI^CIEv%yJV<z4wc5PnKi&Iv>qgI)&0i!mI~4BN>QwN#
zNgaEert*-l_Munu=<BF`w=;v54aq)jdTYwKg`>ytydXMC%eB6JF|6qM4B4IyhS{kH
zHydjo8aJS{sFtO6QTO0FeT$07vr5wSb}{kpM4zL2lQ*o-DgANW_&3FAPnYLz{wXhi
z!HmuJmpr%g-bTu|{`*a%Q(9jfey`+B(EaO%<9ocBy|v3=$J-r;<}MsGU>S98E9tn_
z=WN<<)!3sSe`@fP<-hE!wl`?S;NsG)7iaufudQK?U+3~J!B(Vi>d_gGjulLtckO!o
z?w00*wzMmLym_1F+XXu-JBKy49ZRFnE$RAw&`Iq>PwhibuC?@H?%5sIgT~%z*290&
z>((^_mOolt(&38>53i_w=sAx2!pG7l+Gmo{noaYQUFEg%+}jU%^>vm(tHq5O1JGYw
zZy7f>nygRTTO~5|v7Y?-NZ0tFvukIqH#ZuhF+bfQa;1|@c3uiMbZ$;s=UP9m-*_(b
zaq5MADP7IR)vNMrx0~ITH)}K}eG=F1wP7N@S-Ki$m44ryS+l6uwI?o-ZQk3RZF2ZX
zr|YvXcrUrz#g=zdf3>eY@f|_A){@zATN)cL7<9#baPWBZVY-*kCRM4W$RA;r_j1Wj
z!}RmK1D2l8-On^lZ1GI<>!BJOx4k@Uw<mki_g+s-f;As@9iKLJ_HEjHdJhosMIUN)
z`c1D@>x}9byf}5>e$SN7ueIe)&*G;ae_Q>rf5A4Md!%p+k7ouS-(9DBtDXt1tX$;{
zI_^4@=Og!zI#;x&dGVZ<JkRXro<pwnX!Cd0b*eec+<R)|`ELDMjJ)J~xc`GaZRXCs
z<*pca`Nde?KS*}on)YMia<2<dmBG*I9!lR9G$a0-1g*F^FY~unn6!SZa;Z$VSUPV0
zvKDpqZ>OA7Ui1r6`|k5Q%zgGiVdogvwCp9JPaj@*oHfcbeT3<)?N<y31>f}BlePDr
zOuNo^wAt&6aBr%9?{H?H{KAcHH#Cpm{OO_dtqHfBod-Nkko&c26*OWt@0BGxyNvWJ
z(ebl<8gz12<%PD7+nu~;cGA`D$A#}_?rhhogW7jrQl~3x3kO7)pY=M{wn_NUDLW=6
z`QDh9$?e7p>ArY;?zPBsO6QiT%{yhCs@`gz?&kTI5}J=$aQ@I9z0?a2o6BTFX+w}}
zEuT@_rC7uEjM{hK{}tbTHKg|tbzFvg?KsYUM4P*d&l!|%N`1YcPW_iZo}YU1=$_hB
zU)R4(JJ)cLzus>zUj4biRl{NMyd|qT1YNL6x+Ytm)@61*^C>f$PmSmP^q6%02EQHW
z9~YY$W284>+Vh2ntQ#GSx9@DQt>1=ke607idtO~8+tEqHcW+wY)1(8t4vv}FXnms5
z!o#=yUyRzD9<gU%mv_0F0%;?Y&6J+wixP(=op90}yM1GWX_XgghNKr{tbJ~6&}6Nf
z?c2gH;s~?7zKHK|rlP_!t7R+nDjkgMduzzug}V-@eF0(@bEg^y$M2eTHvW8cg(&me
z_B9rN)&Fp`W<S&AiQAQiH+g@Vz>7_}R_^O9F1_pba&LC?>j6H4o3>o>WRp(Cr~RLJ
zuidk`;6e3;GTAffdAieE?W3J{U9@#bZTtSnj>Q&VX>RbXv{9qU-bX`My(l($gFmaf
zBEC8^-lo(z(CqdLi!ZLXyVADj*<&Wp?l;NX>1;NCKtSE77`_p}3uL+0GY6lT@cW8V
z2RB`t4yXN`4%a%6l(4F>)x`V>Jzcsa(3f$G6s||(d4<3J;J127|BQ{T<WZU5{_@ZI
z0(?&07S3~ssvoY@Ki9S*?fR?_VZE4AHDt;b=n<6aO_qkz+#x%GayiJpMaQGxq2hi2
zc{BjcL>1^obRK#MjYlt|G~LR6LXV?4=vnkS$|WYdg<e5#qj~6Ev=Gfhe?jk|G+D_W
zqT*dT-@aA0M4zG^&?2-i`V19)A&SwF=nHfL`U;(l{)#R_-=NWGDJs7C{ubSXzC%S{
zyZ7ihR8y1mp%qZ}l~qJpC(}VIqoAycRzaJf)lo~d2HF|LPnpsI)kDXkwNMwdHY)l<
z*Fi;o$cbCk_f_f>EApcW>-AYLCLU>(+=kJYT&DC!ZBSufUa=_ep}o-}v=90Y<&jlc
zn|*n;tel3@)Tf+*()6JWMae_uGIRvG8l@^!MxkTS!zg*HB(G#H=zY`;#kPDaPo~5+
zGMfLD%}D<wRGcSeK-mkOiaMe`=qS_=73WLymU1sT2TeogqG!?h=oNG!D*7{rp;}r}
zzhb2x%I%_3^bKBy3OkMF*s6Z1Qh!xpCsWotuwG1$2-guU5b>~%GNi17VjE?1lsJ^*
z(U+(v`U;(nmZ0;{U(uClDS7~Xk3K?Wlm~JCnkZ#O^x>53z*udi@I_Y<H9>XImS|OU
z4O#<@L3PmsXf0HnKY61(f!0OOqxDg7-iBxuv>__ayAdkJeK$c{peATbv>9rJwm_{>
zQ`81+jZQ$@qBGF;Xc)>hqFjespqtQ6=x($#D*F3cp~Akwpz2#H^*I&xt;RZ0=ESs}
z&BESaqMWlV5#=0ZJ5kO>whJZAGOl%{XzSREI-~p1jc5wG9X*8ZLyw>b(W7Yj@m2jO
zrT&$+hQB|48^RfI{I;kZHAh7~MV>1udounGl?%~M=o*x&U8-Ni^;3`Ii0ekAPh2<H
zMAievCNf)893L(3XDIbQ6z5-ob;K)8-xIDja~Du?J<>d`<QfqDfTip55-Q^1xaEES
zq&|Tn9&Of{ftbD}oY+4d74|%h&P30k<@>Ap)5!u@|LOj=<W~dM_e90{_d><__g3X2
z=_&8aCiQU>``2R~$CIW>s{N@Gm91Da6}3dYQ9INZ9fVziP?3K#(Oh&knxQHEPe|o%
zF3Wu>Ka6isjzAZnPf_X^WgAX-32Kdgf%ZouP-k=n`V!?@QwmpvYs50T4%Hy7)Xhpg
zbQ3E2=Eb1GE`FfuJ0<n066aNwbsiul%9a@RFWZ5(M&nWHOj!a-T_@XxivKO@dgXL<
zFPeZ-7L{M2`_XG?3R;AIg_e-6|74%FriHX=z#saqWql%qVhf{LTnC``VavNXQE@;V
zWPq+M*C<SeC^!iPV9=BG;0=+G47s4&i}m0EQE(E3KL`EZ)KTCKF>n%YKq(m6u??Id
z1Y#f!Za^s*^<g_WLkPq`8r%R`U;aD59x@;oO2M%oeFh;C(xDji?b(O6oKn%AGk|o0
zD<~lrPC_n}fC0}uw%`Hb5C<or0Q4OwFEAQHAPzF10CWdYcY`B%Lj)v22IPYFVE)s<
z9wvhlq9GYFAQwu(h#MOVZ~$+JgcQhz0?=_J9<T=w2!|xdfIKLLa1GKpnlwTzoP=D^
z8ABSu0Td7eX^;=PW2xie-|fRTUklrDQ<W7$9&uCU2jNx7M{W+&=aWWl><1P~?1%oD
zKijNA!q(v&D_}ba;ZH6P&A*8)*d~0+gtGl_`MA}o#Bsn099B~1p0W?~CSe>Gbwtxp
zS2PnXg-?CnI_r?$TU--p9Q-Z+x1&P|SDE?=Qh`B7GF=D;6V5dbO@aKy*aFQ4gC*oC
zINYir3xOCo33*To`urK0fgQMtKPL60wt(6KY73|>@E>UbP0s55d)2AwO6^y&vpnpr
zG2mGQ$|o^4ydDpgVocYj#${uD#F!p2c1MgM6Ju}Q@<8`aJk+VCsm#9@%MEEh08P+>
z6NJA9+t?<?aAd(HxB_C@&idZaN9?Pb;+T(zB98qG%BKX@3IBw`&)+VX1+yUp=D`98
zg(a{Q#FT{Yfqjq+2S7{@IQ~Oe$?|Gg3t}wndUOMbset7t@D#)(#@T9fP8Fac$XH(q
z72`Q|&~I3-j8=hDtaE@w(z^@#GrtKogO~=RqOapf7y}~+GZIEY`6Slc!CPnw&*24#
z$rNn~X3!2gfSBH+n#7?E6;*NdWnCZU`>U1*uv{7R!HINK>PY&bd>YBR(O?c8pcS+R
zF?B>Op)+(*ts8^-L!fGT9O?|?VFI{;2khc_*WeD6Pf5(%u&q0YX%adGrm2>zV#{h!
z9oj*A=m?fz1=i3Nx<L;R_U<X>(cY*X^aXnu01hx1hJcuApfy1k>VqLP03&D!ji52e
zp$U9RyvFElv?*!=&7e87fR@l2+JKn!&{{B`^H~UC5Dv>=1+0Q7SO?Lt5t4~J2HgU&
zAf}J^t4)0RPzUNlJrHA>#8iiCQ;Z+o$aN!pLDXknj8}|dS&Xe~z`Pjyx0&UAO*u#A
zw=gfRO)+Ll*zHXtY|eV&zha%(PoFkC=EYd-4J`k{vL5qd+<Y|4+T1Hw26Ofk{s?Na
zUiddy&o&X?Bf>uh@hw?h!hOqebP1;?!m?Z)sz61k0o7m%4LId~NlVyIjQ!PW$FV?M
z?=r%K5=IkUj6Nm)?u2=d7K6yABOs13r!I98;V!XWlVvUDw^E;NgYxN1=68OyoXq^e
zkCu-ze?ql<8qHA6pGUt}&DS8EH9<^&g+J5(iT_fy@6s~6|C#SnQJ0E(P}Db~E*2_$
znTk4F)Ptgq`bYhmnsX>`h=B~qfjp4$Y)#v@XrGqG$=jl$tzNX_djRchGJXDpN5f=D
z2GKq)+8DDT7fQj7=iE@phFmBB2cGd_APIzD40|5eA|V~bGpu-it;Ta}2G5a2AjZ9$
zffd++7}GAEALAee(jgo2pcrDSG7rTd8o{f95yVudeFO@i1Z-;%7r25Sgn&U!mcb7~
zAQ6f{{6AI$1F!(`f9D9^5DZZe3u%x8)wo`rz!m%;1TsOt7WFKcg91|EBxHejc29$R
zC;@G*aSQN<Xh?&6C;=Vv+W<@<iaH?^Za@K)LMZ?5DUc3XphKAu|KZ}lY%&CcxW5qh
zAFkB5p^yUUkOd~xEy6!*B&32q^`8k?fbi35FUOvc1o};g12P~7@}L-Wjrp$uGYEzx
zNQV+IZ;JiF0dl~^gt);Ls<lAD5u70yav%?ipcD*D2@m$*1g;PQ;SdMOkOnzW3?40M
zi-H(%ZpAjpgd8Xa*Vfn>f*}-QAq}$N2IPab8RrCMU<G#I3L#Jox^377CE(GP`~@Y%
zKq=_7!&V>%Gq48_2!<$#g*3>3JP0@ExKIMx?TH_ZzzQ5-GK4~w1@^F{EPxF-fGc=I
zC`3ULq(TnlgLu&*{ujmnr#aYw1B?bgh=3SKgDfZlS!dD?7T^f3AYL*@Ln54nOep`(
znUNJ~0vm7yR|thjh=pXxg<{a{LRheY(clLm5Drlg3#pI+xuDC-0W)xh5Qv0W$cB6<
z2JNoc8|*-Q7d#pgLHPPLw;}D21Zj}d4I6eREI5Ja8*U5U5CV?2goj9w^<;k#?ZZ)!
z4%y(;3!6a_*!JceKndwk4BB=mnD!wL!4F~~3vxl;mpDMYu#beC{_Hb=uwW0~Alh-W
zK(ynEw%HU&hf<h4h+{(<j2=u_$O6&kT5TBi2R}#}PWb{|Cyog@pgV$jNEuCehiYRe
z8;}k~AR9}5K{05LBYmE1gKW^9L_UBwgiq!8kO^_##03Q)_u<^Y1I&C;P(YR+_V8yL
zcz{(9=MRzKFoXPpR44-TnH&eaAqKJ`4+?^@&n(UvTxYW{#6l6s=dd4$Z-?1~6S#sm
z1Vbo9LJTBA3Y>&YNDIMMb5SS-gL#~*UfI23Jyf?7*EA~bEj3Va|0(Kyac}ufx9r+_
ziHdvJHmn!-dpazOXVG6#aWAW${y7V1v)jMG|DSvNPQN(-{BQC9CwvO_=xHA8-pSn4
z)2h9>$dQUN2faP|;`Ng#@zisg;#cawAbm5mu?Ek+l;5JIl0S^keFBzSvdkr*<R`;c
zis7>#$rsD-{b>bC{!XZdWL(1dvLG^4__uIHKlS%FnRTMwqTJ_=Ay=Vj1Ip^a^O3CF
z_nC{Ia4snPk?`(Z7RmVpu;1ooWqv_K+;Wz6I1tC{$gYwf6=94rKQH*^_{c9Gw-i!4
z(-4i{`{f&{@--#;c!-H)iPsyFuNvWV-Zerxo~zq*-|4e_e1ihz)7^YL1O43GJzH2?
zyW@Lu%5+bcKu<hWdbkAQs?c|ma8W1OPsI26ROXXPq+f@PpW2IR=6CiIK28Rx(wL@7
zqZwf;1GiPO`=l}QZ>DjwTi{0tlYH#3-{;eB>5{YY<2(~-7^X^ty||E>tU;u~67oqy
z*56FSlt34+DFJ~vas16fWi}$)|6uxkT0XYX$7#v_leEZ}|E)YDEuUvsneU-LND2Q)
zQh6^gZ-15+@x5I!iE>y2+Q38X;`cYx5~%PE@chg)|7ae4oEDKjQN};cH?fXYzq>|+
z{mT7+nN}2ArCSBb|JMlSACu<fvNV_12$F61%l@P3LtUU`YngAovbrFg<xkTW$+}O|
zC$86zed37p6|*j}f!g0qN~Ia++bswgem-lwV%f01D@WDua4eI1%%j}zGLGexdzG)}
zraze#{5<`7QnA6ywAT(t`res&KEQEi)ogBQW&bJuZq)v1+^$X=eLB!9J#dj(;(<rw
zb4Sli@uQC6T9s=VrDV-+vLfAPmSsx&{ce3rYj$gy-SyJyXD!E6XgD!_`6%k7S|Xg<
zKaJWyjVK2#A_qrSwo=5@io5in=e{c*^_Py?-p}OJ&CA}G&5cd|o&IU!0!8|cd|8mx
zb(FmCnqK{Oj%e$zZPVuBxr$#`ep<Du<GII;ZnXN(@lTW1N1X3p=Xd6>_9ydK`-$=C
zD9+cu>BJj4np*ya)f#V|Vij9j5O8vsX}^P=EB1PH<gM>J>NU0hm!2<H&vNyiap>yk
z#}4KNXK%zd+**nI{6WHgf8Re>G4}{^t!g@bd!&tRnz*>_s3}|8ncvj^zFSIMWv#r@
zon2auifXf$aa2-#4}LAK_e<98+i!<1=&JVrqW1sN`<>pP#O(RoE(I0*^n+d7MzYq+
z)`b4lg*Mg6v~kL{^s_w^Uur(@;@~vm<@{RfN0ts7*L+Wm`G(6cul7Fo#*uQ`Te?3D
zRfg(cd%j?XOCy&hb1o;%)XX+mw0!G!MTJJEzYN|KcAV!93lZP0>4x$;-=y~_@_B!4
zW$hgm;&s&iUxZy&D(*Oa;Tp9geDIW@w<ZVsTlF1k>sdUvx!3LC-#_Y;`iQY!v|;1d
z;LK0Ej=mdbJz?}OJNyD{uO7O#Jg!o3+Nx3KB4RJ<oZ=aIUN;f0YTtdH5sz{+ue=<-
z!YirH{5B`tyHpB3AGI^dpo`~Zrxf}>(5^1mn(Kc!cj$Mg+g@0A>cPqf8;+G~Jvbmg
z|3!ZIoRDobp2ZR0FH-)Fcgs2yIJjt$nR!KfS$<Z79<_ehY?876c%_2{cMrE(!-L&l
z?bk)^uSM;z#Yeoiu@&Vs=GDWWzx&EL#In(n_hX~)PCWGf`cR{em3PM!Pn(#0?E(+L
z;yaOYtpz&odQ{%vsxhR~r32S`ja{_xVNRD@7Be4Le73-JW5uuxt`8}`4R05`?%UJx
z#T55%kL}yF_I1}qA;w0%I^Vy$A#sB2(bg`!v$q%VJ$mp^@6H&_Lc^D#iDTL~i?^@g
zZEaroW^0@Nm0RlV59j?xbB-<7>QgB`H@&!F{lw~ZdN1l>xH+=LoNs5?HE0nWdQ7|P
zoq_T68=`fF``t-Nvj;31I%(XQ#@iN;tH0ue^(YUuzZSK>mix9_=S^Gk?3<A9ANM`b
zKSrPLzevyfQ*|E}{r~mX@>ly|`FHtOQTt7Ky=>jWaea$Z)2yaGY1eA%rpyzzix{Ij
zK-5DAs-9}<uUC0#4Zpc-j`_&G&|5s`YUh~xGb8Ud&FMT#?Kfp^>+@YF2YzoFc>Ic2
z<P_V@Yo@<mb7TK09mY1&RxQ_Rf5ZQM!sejvA(p$_efiDQ^%Lh0{cc|Wo0q<mRdqc2
z<$l8bXeGkQG89J^Y%^(__xPJeQy)&9^3yIquQm&-J$<wL;-j!lT6w%18z{m(&U&%I
ztJ3mEYQHHj4dcGqzly%EorPUi?0t2te%Oo9d~+xF{=F?qN9?-d6Mb(>VBZ!t1xY1_
zV`=Y{>^y6ladYMR$Vy*?9;xrtW<kV*o{>N3Rn^<N=9~X3epA$bPTE*@d|co&_)KjZ
zgLQM4MZ8<szBrP;)DEH?JaBftZDQ+p^TN@L)zz~z*L~ZqMw7R1GEDlO?A+h+VdxUB
zqedcJUkCd>y+-C5daRgv_wtLG-^Cx74L>!z?y-Q&#-W=A1k$JFDED@9EuG^rEu9~}
zzjn@GM6K-y4O0ACBsUqAvRb#7`O}OhZ?<zUDf$t~)qYO)X}$V!YOrgY?MbUG4h-UD
z-E&Nn3aY*Z!e@f4i1(q~vdEG^OkBFk`Y5JWHbF6`QoJMOQBnyqTXYD@t+Ub{?Tvb(
zcIXV0rUzvh+7FFDxfNHgK&dK~yHT35B)=zglTw~wnRl7Wizu%@ly}fE=r1VMgHrU9
z9fyiO5#v#jejZoL-}Os<07Ux5>vj_m6KPk9egTFk)xGE+@L@mI`*+Fbz^D6B1eM}F
zd1JH%D*tFd)jM<PUHYf{HC64`3>EL#n}4*Q>izZ~?$=VaAKf3N{pc$orIRYL{9Uy4
zj#?a#NBIwa5_AbC-dmGrN{%hMxJ&s{7Zvsq`>Wmy3mZ!L`|<wRPx9B$0p(mJKM~@6
zvIWbcf3SL7KYdGPVGmG`>!)8J?TPAf{q%jH0#lFcrynPkN{*;lsF*EaH26UbWI{3M
zI@2!{oFJFFTlfRA0|mqmqt7QKGG72DRNk%-Lf9Bcg={DST`GOiztjW%Rpa_ao%in;
z)Bmp?&!5Ry{Zg>WtswJ*M92gA&z!J&Qd>Z60ks9x7EoK@6ASQ{{JZi0JNf_qv+@6r
zXy+FFP@nT4@&9A2|G#={{}()5MZkaK_<r?xexCap{@)zWFUI2k%ylTnjXdUB6k{#K
z*a|TwUyQ>qVBI~|i7^O;%!}m*%!}~=!heQXeyY;DtP}m=g-;E!UW~1Hg8tF?d@*kS
z?~TzH4HRPh{hy7!*I=7^%zarUY)D=;fbyv^^K#X4o!a<nfbyv$^OmaRdem8B{Ir-l
zv#yJ3eIL|bH9r`2RLwh~BUJNaP-oTrMATC?uStB`syIcw^I0FN+E$76V!WN0yjeG0
zwO%YMn4hUyu1c8ds&N0#G4~~;ONak4Iru>qh%xpi;0?hL3S#V%@J*WvqEXQnA|VD6
zL5GI4(IEWC3BPgLJW4r$5+WfMGC+*A=TS>m0Ol2m2OPl_#MlcZM1l?Pnv@U;F^~wU
zU_}F_@YyE()<wY$D1cI^R+YR46F3Pv)mR1-aD-?`gcLXlH=qbgK)*UR02{CeKDjJY
zLJE|E4h@S2U;+wAgG|T)qneZxm<+*SLcV%HB#80(!dJo#(5FtY1rLaXSV)GGkOelB
z4N*o!S&D)<Ff$--@P=SWhGNjBF;^GlU<Quh49Rd3jA-PwgIGw0laK}34H)}sgdIWn
zMkxR%>UIzC10}>j5~PAQ^`{j$LMWs`Cggwzbzd@^giMGwM&SnJgLYHGfFFcFIK;t8
z$c9`f038!-1Lj}@_TT|ZD1vIuNHgSveRIkgcz_ZLpaisOnAQa|um>@Qe=;Z_5@H|~
z(jf~9K*y9gAO=z)l!oUbkhS8NU<%<71+kC>sgMmtpxqk#gBjR^6ZnC?8OMcCh=dqO
zgmlP(@^Sml=GX&LAQSSS7|O@oo3_Uu;0R*ey#mD8`&dYYbjXHcs79l;8Q6gnctAMB
zLNeq)0f<IzU9bRKZ~$lUh8ReOOvr;0(6=B?P(V0DLnh=x0hEHdC20g#5M%$vSbr=2
z8$Cb)k-Rv`f>NkvMLhr|VA6$jfQ~ic!5&gUjHNFDhpv<xh=6J~oELaN37B?c9|(aY
zNE6zfbU_iA_Mn_VI7CAZRI_Ctu!qRr>;pw0UeK7pXb6XBu;`0TAOuoC-j8F0@PDdn
zPgn?tXh<JO-Qd76!DA411mT-B2O<YE4>{mHjIspjkPRWjDHo6mlbuLEq=CH)+aLlm
zT*(7B(g(I493Mi#*^9U!4sxK{B(8bLn~YAOEPxmnp9|Hdu?~u+bN;@>588g@7x+OU
z<b%FH#{n@eJ_2GOE&%%ka?W6&U|$#wiI4;NPz<sljspf@0_I=?_TU7r;0?hL3W^!n
zY9<OPkOi-GiI4K~N~OYYm$={h1r_&aGQF~UuE#8k`#JGHE1t2`liC9RKP;flLH-5f
z|9vJhgm$KTU|ZjbQ+Xe1qo?7@^}uLWLs_1m&IcVd#XZ0`(AP^LHyzeeKEzKk#b?Uw
zDbpv(d;9wMP4V^&V63`{o{P&2cNaH>B4EnIAcbcj<H=3*CVP7Oc?NvER*bbb(Q{LH
za}2SMdjP|l6%6`z@o}5(Hp$b+b2`_w2op$!Qx>lXBa#}xF~#_D6TMMWrhE9#3}mdZ
ziC$mdpy?iNiYdO-F=D@-z54&1FlA%?tyN>Pv$V=`Fo*j>Zc$`e=xYn^6=JK&xFwa2
zER5t*KD3@NVvKP{*>0cyN@IE(F?KkMEln#*<Mey`PM_f!pz!qQJ=raQ>P#BjpM(0B
zZ6|i|Zd^|<SL_2rGy<p0_Uu1>ly88C2rv8v<f9R_q;1l2(TA|prT9u%{=HuSJw3k<
zVI~H7d3gp5CstN{80%klEXMka!>QIgqM}+IqEY4pAczgZkAM@#5Pq*-u<dS{ZKQbk
zOH_q-=@aZ1;3C`xh;hi}`-t~RV+dogU9u;()6*Nxa@nzc+=5-o(&pk$Msnbf_mz`3
z*@XR8wQpVawfj5Ab7r53gsBqu+wp?`!Q(}<FMn4uo%rAO4gUxC&1Byzgbh^fE7Ho}
z@*mnpoMU<UQ&8T-)DksC<>;@JKV2ReepmjyUCJ&e!ie%0i+(=o+U{qi7`vW~eq6pp
z8A@f{$7Sdw%S~a3Mp+pWW%}bXB+kK}b;5t<5Djl%cQ<cJLs|UhXxYAH87J~v_&pPT
z1+v(-pe+4T8F6BntR;@m%ZS)VJhSx?VRn|;U8H|9%fhb(*Mg`YK9ma)-j(otn?^Q$
zS6O(GPFt}*;Ln1q%v}^E>DbO6)=!+J@GM&|Y+=QEdD-<R#a%<zMenpKKH-m0<WUEe
zKM*s*iAkJ1Ns_t38w>8S_I{d2WqA|K_CJ_D_(D*!@zcBsXWhqn6UlN@5P2icFPeGb
z^A5isWW<!|UffFwJBfVw)CWK(Rk}?ov5{#Jh`MbKyd~Yb`#wo`po=$~q;e(F@dwj~
zdQD2#->BC_IzK))QLn|auIyYsuh$aU_VIZqe+XN4-l;7A(Rtgl{?qd=_swupb>3qM
zQyWIWJI?!L*?E`$?@8zTSLfBA<w<#25^V}%nhPRNg2aL)_pQlNo|LD}Mb!J^I{)94
zAL86>N!O=#FJ_&nBd&4X$hErua^7iC?|w^<cYV-ed~UwOp`YFQ#F>wXvKig}&cR(%
z7n7fLM7X|3Mq0jlrg-bqrTw&kt$k}8)=WNLZTCP~{kIvF9owIxuzL0u;hvZ#?({64
z@TQ(c%bTe?7In=%7EwQO_Q4Sg6WVuQuzyV!eOr5qa8~b^9XS#5>*iT*W(WF}zV96J
zD6Z`&udJ{+%AiD}py(U;ah2k0Qmf(N@2o1mm~**T4cV7#Ox@dct?|~<XJyq^Elk3$
zFHMli&hbnq*P8r8=yKWKj;8Gnc!t+p;Pw2g8?N8aZhqa<#4$c)kX<3?`d&Kj`iAu@
z_3d)LQ|*CjpA)VH4|$$a`<zhwoY>n$CY!;{n*1LabKQiSNV!(OU)Hy(rFS<zsl)!2
zdkq&3N?xM&IU(%wzt`tP4u4W|tx;7Et#8re(IvkfTN=k?Y@Ax$)6H>9>QjB&z5Uy*
zDw#t&+gT}pJB-@1^o7mn$|nYmulJ<p+hzUxH0;sh)LX^;w|8?B66<i2vVpcTxmK4I
z#U(9fH@ZGL&uGHJj`=qpDEb&5T@k%Ga`2iBhRq!O%i8YbS^+=lI)sMy)eao~z%#z*
z&&t+)bk8RA4|{NRy}5R=Yr7<T1M|Ns*J>2#(6D*42leBeW=|jDF*|&@a*)}(7lqbg
z8SU%$Y8dm3wyMq|+{1=*3kMmW3tiD(H}14cho4t1&+zQGruP?93pO4aUN}^jHZpEf
z)jlWGJ}1_66y@M%N=aNw!oli8o{j0E_BoM9yK;Tnn&ny(Rw<1N>+KKPu|9L;d!1R8
z7G;-S&$!a=!7+tf=C7SLhVfm`ej;3Pl-CY}pvwcMJ8S-;k<(yy@N?%Q{eJoJ{v-cZ
z2S=uut>8PX+-%CVu5^0SZOo~{CabFHS2{T^c6gG_eai<+Bk$N$zA|(43$@P)wa<z8
z&f^Bz8u3m<Dp#JFSySFwSk_M{s2H8OZ>+CY__KWmRo8A>=pWfS+9r7eZEe#1{qgup
zmxi>p)$C^BaHRM7t4p8z<j2kLTGJ(I${=|&e?$HkYV$5gt`%Rs#*2#&ecT81EZn$W
z5u@+#S>ow^`^oqhUB7WydR=@Q!BvV+?Q^2u?!sM5zi*N^Wc=KB%Z(XJ*j3o?OpV&}
z=9h#meAU+Rog#9`s6fXy##@7%4o<W_);#=W{$Bb<NOqoRq&X}xvHb$e)#*DY7+ANR
zeQ&~><8zkgEZ#Ra+`n{?BV)~aiTD~fvbs2XcVVw%&$UhzR*kvU#kjZ3!|wPGPx_7Y
zv2^NH!goTY`-q(vbxwp<+O|%&r^%H)cg$DF2lu<&to8S;eyCovN$1dRG!j0Qo<pxb
z&T=m@>2}GupkriRw@Z8L4Ii`Tn8w!X3tWz9-hWvyk9SAXdA#3LxZ>X7T?-z)+Sq7!
zjWx&3XK3Wl?W#=ZVG=z!X04GM-<g(<`*2v#bCV{9z5C|UZhy7U3AN9O7Ol_SFSWE8
zQfF(m+uv1nG2H0iy4`!nuP7^5rTf!d**6agTdt}9wDIIVXWTBl9<o6HTK<*T6K1Wp
zdb>UBP5VZY^gkGJO21&kxW`M!52-oWt7V79JHovDO16fD$Fy6pp+xIK4DY$6_(rcD
zQ~ktFpU8UCeoUJb<*@ekycLtatao?I)i=SJZ!PnxGv=B)ORjaVMDw|6T;9HG2Xvwa
zJ+v8UeJ^X+<HiYXR=QrR)b#X|9DHmTh;Wro>semQKRz+iNtW{JQt!!+FMrh_Ys68@
zf$1}yN_S<^xWCC>gj;$s_v{YqL1XVU>)}7?b?X`d%O5Q+>F~vchgTM*kE=IsI`_{~
zxR+V0LzN4SH&2qk={wqb?YJ?^6vf5^hQxIo`Bo9u{7P&3#Yy4pjyL$q;DPzks=0lN
z2lTUCyhZ2Ll>w>FEf@OD)TveaUP*he6fVf4@a6dTI!|l6m=D)~urc<0_|jQBWpkZ^
zn)do`?u1y{Xlh%D^bO9dd*Fw`eJ-B9?0oN_eaAxsE#7YIvNpu)rxBH3UQT_@`{ror
zIi*jfulvVpcdnLOZ&K#g%cWr#?zWrteRyQD_m$ntD;%-Y;d@5?MSNERR@E7C-=p3m
z#i2@96Q(`=-{W)Q8uwyyty#JnXO({6omsP}*R>}uk!{}Foo#aXNT=(wFL*Dx+r_pD
z@5gzEE&m66of!@g;S#p`?J!%i_3WrnZ{D$mE*N%j_=tw~Pb-bAXVoMka^KamZ}s3?
zb#~mA#>NW<U2z{AJl=em?&Y&dRca~nN0{ZkT(Z+J{XE~1mg-aYGffj)Jk$JosK&-^
zFAv-8$zJrm*AtUq&4*pbr%j!Gn|EEkrQ=2)YIXWeuT|@e>KD8?b>M!_l+LfU<xbDy
zryqY?{jq<+HooI7g<E($Gx+%KI^A3KOlW20DsRwn*P%QgxqsBTqBYHn=d@hOdo(HE
zwx<19xZLZ)Q)Te8x`)!Y1<i>6CP6E1&ddC*6(+48t6a)=iKO`Qm$j&?e>>%z@}ghR
z?DxIK^_<f(tj^|u=L6Rcyz|8Y7aBc7rTD(Nw`$V8>2qW6Uwi31aP8vY+kJa(*?o0e
zjU_$ecdT5{m~s^_g=_p(++vUP`m3V+Lso4MtFcaT&f0KMw`;zZ#XH}7nRl2+UkUn;
z$hB_Wnct$;kq2f8OKt5f0*7l|ns&WO#xCodNeS1_8GH3<Nq-6Hx;(b8f9AMF)-A#u
z2cNp>rqtYi=jhKFvz{8>9J(;Q{g(an`7V<5TpN~I`-z|Fx~f0D4q2u4VKMw0zK1TA
z`$NVD9F8aU+7>uv$uAL`A3M&tXINz5uG4E<ixbCJX;-4Ynlf1A$Eh)69=o?ney;Xm
zvES?d(Z*}|?jY|{xUU<${Izd|`M1)v6~|{d7h3;3_wIn!jla9JeoSDK=a=%h7dPgf
zoc2FsMf2?yUfk|5p};uME_O{v^O0M>p6wd=Rl*Z_^5GHtcy}P>N50+J0PkLbKCkTh
z9CROgL*ve-%)+^&9?4hERQs@qi_MHN(wi{t`NBiijSj}!cQ)A8Z^Jh}*8AE$=l^_%
zWWRgU0-q)w*mZEs#765AjTRoh?f+ub-t>q)`?|c#-4qyknm)i%z7-`7OFH4CJ9hiV
z2Gc4p(hNy2$XNT_+Mvl=H`}*`U&Ik+dwr2_hcguwmRT)Zp;zf(WZzpu?k?PQU}jPC
zcT4l8uaEZ++qR4M)B{DhoL5_9r?0l#ZaMk;?>xd2o>ls4VI8wW<IR)2nrqZ=XnLRf
z94Xwf66-EM<aF%S`2Cxb+yhGEcwM(gZm;^6I+o1#%8y9k8A|kH<9ag~oz+~n_}-UB
zMJLrhEKJ_ePpz)7OPv{SQ)(P&cKe0J7uVZeY1{McF_UNao8;|uHk&^npl%fRe?gM{
zo;mo$gx^<`I=JcDbU5wjbhy@mq=Z$4ttRGA=;_iWp%LE=l*09BJg@NAAN*D?>7TK&
zl{_l*+h4+4?$0^3{^bS5qDTLay?24DqU!(s2SG(e1;s?A+!`j{3KbO<74Mj+XlR%i
zcZK98pyGXNUZ||7Fj3LaFj28E$uzC7&`8O!tkkHmyr7X`X=0+D_jhJCY%bOF|DEUj
z&-42o=Ea-Oo|&~~)_m7}&CHrFBraUle(mKIKQ>r)XV4}0bB|_inzL!zgj(mYDCHiY
z{>+Rb&(g>o3GLWM_eovYZ<O`lP`MX;19h<AnLD&IdJElymZOKzyXbM$!a^}x*5lD{
z^c%DxdKYbkHnvohCTJV9DVm8kN54W_qCcXo&}%5?GFtI$LR+*Y>WJ<|??>hP1I%Y(
zT#FjeO{f#P2PJIALueN?AMK9HGeSL3u0_csjQX=0>N6a2-DF2au0a;ElRWAxw|I>`
zQL1DkMWf6=VWfIdFtITNr8{6`Xj`4TV<>({vi=x~Tcdn~jwXb04ocI+DDQva*SH_`
zMo*)Up_kCfs5SPPf_6lG(e5bs!j1jWY3MlA51oKcN2j9x=#%IyRNe!RMBhPU&>WOz
zjPV@GkiYRN8jt>oE<o#J--YO-=wdV&rTJl;k8-=$xB*>_ZbuW*z34OOJLnqpBb4Tu
z@e?!&{T^M1b|!w-qvO#H=rnXAIuqTD&PLPFx#;WY%jh<A3;G87I+}@IMBhZ45;s&g
z#{1AL)B)X#$}>0bq7t8U6->`{sLy*yeB!-gu8$AJAM1zFuINW-0Qxa%@~=N%p+0v}
z-G4vQjpPG2v<KQB#dgX7)Z|}(PNCMhLXL5smbj-Gt<Dvaj}qs~XJ+TupCwSAF{pn2
z;rjVUpq=qI5}kvNLW{W8y17Ou8|IU5p>D1b$_Xi$ARY3+)<aP|APkZr2TH(UDBB?d
zk{}C;z;+nhAq0{k2a3UdIL~QA1f)U^6hb*Tj$j}7!6Hb7Lr@6i;5d@~;0KE!6%Iim
z$Ye)O;0bw91m)mOK`PJCCqXV;2Ybd33Mp92!9c<40RdoyG{}J>D1*AWMz9N&NZni`
zlno6TI{_~$E#+6n0r>5-k~EKcqleG{G#@PoN5+i0gS=aIitT>r|LM6#Y?(yG4^G2%
z7;&M#vIgpw|9%#zN09H`)5C2`9<-oM(n5P~@&nc{z!v)2@-6TJI0;{YY1zuY;V=?R
zOFF-|fxK%h?-iSt|AhDX<$2F0y|rg-Z3x@HI*)-ogJ^ZXqSS{5Am1@=h{`j~)@UPW
z42N0w0{Q0rPLS_PZ-h-C%Xn12c{~N=`_q$gGX)+8(<0kPfV?a8Ap8b5Ko)1T3v`D^
zpclw;53R>Bte}B@Ecv$eNPdse*B@oQ5!izd;i#Jffbx?#yB{8a_F#YxAm57bi2i^+
zh&n+hcnCT}7w85(Ko&c+1uVs`%V8xX!gKHfyadVcDx|;$koRO$(aj+5t;%BVuO-K`
zhgNVOv<7)TR+gruVR`Pj8EIJFSCnV3oAUb}DjmY+{FeCu8sSc!`ESDdD|9a8xp!IQ
zIdqvTpp1R;PD*3;SAXZ<sulhryfuBcZafnY-kkqq!uqew1>nMXzzY1%!k>H-I$b&^
z9B&od>Y;Y*U&#1_%oT7Cu7lY909dg9zuP<kG6zF*uAv2(mYZ~_{shy~0^7CJ<Jul=
zrT>=wt?+lBnO{5dX-kl$Zmt0O+t^|}=|akIDZ>J>T?Y0tX9w#$VHae=Zji+WB<Tl0
z8k9mg$UFh^9a9<aI1kssok~&W1~?5imXs0D9elvH0sU(Tfp{>&8c2acD1maYk+vCh
z2X`ozc3LBTgD3bv2%K+B+0uk|A9z3_q(BDjhg>Lt2rfY0@y~?<D2EY@&-y?BBtRmh
zK`D4Qqr8E1D1kDtYEJk;-tBjT5#S9GV1z_Shb+j4Vz9!_ZeRqND<>5)pbX@_e{b*u
zdGEgnN}wDvXhRf(J!#(wTp$2aAQy_kp15%WR~P|4kVE{Ifi>lV12}`c>t6(=P!6t?
zBMFcQ$spxQ7RWpRMc_)h7y(kI=7E&mt}p^*UI1UpolKDT{+%fIV&F6s!*#GSP!E6$
zxI-cwf>U7Kf$Iiu@PlG-?Z~mg8yq{K5C9R72=b2qb&$zoZNM2ufa#t87=EvT6v&1g
z$cJK(IRH%W`)Bey!kK+g2*qI4h48~7NQ7j_f_x}~5-0=vu3QtigD3bv46FguJOA$8
zxW4Y34_1J@=bs5SJ%|f%0vB)xUx<f9NQW%QhtqH!QXb~KVEqW^1_N{lPw;~TNQR<b
z*rPXT3{3Cs$MZWG(jf;5p#-d42?w}<2LwPW<U=8pfYf~kFulJY!tVq~giOeVQ&0l(
zOoL5d;txE)3;ZAgQXvcSLFUAf`$+cvxCZb9KZt;2$c6J@?}m-Q2f`o~vfvQpgG{n)
z02lCq{UGxMxWWhs7)Y9hd?*BYW*`r)gVi8x3)X|N0VKkH$OFeAgdJo&r4XDvI40yl
z8CVZxKP-YZqQeLm$aqN^I1eX2Aq+A=#!9Ri3vmFMLm*-_VS#)o1exU76+%Fsldyf1
zP2dYjP!2M8syCE?s~2t|9?~XoJz(XHn~B5?q(e5yTmtEk4W3g-pO6Mw;QKgf5|Uwr
zFV_z#;1tY02!r$x$_S9bRmU*S4*}rz6vqN1WJ58OK~4k;){%rSig<!zD1-c1;xmrp
zLlL;gV?$U0xlju7f|bk(5C$>_fJ}&82qkcR9)1(Jc31(~kP8J+2*q$6l=-AVZ~!N8
z0eA2O9|!>N1=wmK3Q3R&11NvxJwfRgNc&Fu3et|dib`8h<`a<i;Wbq9MBP$nf!Zu!
z#m4{o`~P8~fiZpwk@0@K=077g)GshHq_3-ANNCWUnY>aQ7^A-a{~!7O|G(>9|6%(3
zurkM#EOw}5xyI=3j{HuxRQT!d6&=hQ&XZ%9Pat%_fGVr%yO_?Z@9O^y74KYouq%_}
zO|Xa$3#UB#tM{kn-QrPtn7r$0$D=w{zX>nrc#~tqtgS6fOR5G6xAKnYKZVN$cjn=e
z^P6mvub;m;Zt6obc#HFA)q4KXq4AoLd~l|oTeRj<X%lO9RzJ7t-S-ienosj{@8{eF
z+PQ;x(Rr5tjM(T%Nv9!9G{GX*tNE(&UyTQ`xtwz!$C+SJ=}&u~ySbhCD$&my!Ufx~
z?uQ=0eW`Zd;IL56tDapupY%U!St`ya-$bZ>J_&~}p0szHwM&^37fSf;?7Z17aiXOY
z?M(jBvjV9`6!UQAO2%iQs^nd7>KQmFal_<ioKg=bueFob#4Zl(uVtx7p9Xf`#R3y7
zW`xJa#jEd+OWFxnw=r`AlRcQ;UzUEdHV=iITeGR=HzE+Pq-{&PQtX&R82fRIZ?rI}
zZdp|_Xwy%y2*;&%O<J1M>@Rb%$zsH>ggF7t;ksNlsn-=UCo;xAFe1XA0xL9_2|~i7
zf<yhIq9r+~*IB0euKurb?gKH-2WtFla|g&f=mj``TiwQC$mRZX)NHQiQHc-j9dm7;
z99jGXpjx~#QA&&{MQGQaCt>C~zQ6`~TDa9?dEjTWdY-CjPv#exnx<Z#@(%mO9)0yW
zNLDn!6U&l@w29EU=tsCI*s8jx&<^zv37Tm#!M|*Sx70Y)60({vu#1cdO|Ym;kFs5^
zzk2$W@E(0#3va3(UQ@m;)5B|?Z$HM33lCs$3hlzRjH~COf6lk2G$#F0J$zMcB+uQ-
zk_N3|BOKwJ-WBIm(@b=*Sc-j;A3V`omWuo!*KMB8O?kF98wKFjnoKBphtv}l7#XUj
zkubJv?jypZ*ghvRNG+%y!mb_Iw^hqWVbOCULi|a15&lu3^ZdgCqe5in94#%$ScC`H
z7sC2V?RqNmX4N>fv@0ZS$bBR^cAoB5(y9yVw;qu2&5Vc+3XJd%jg5_puFQLq-UjRG
z&95<zS-eTZZBb8DY-!kSia#@3noWEoHce4|R{!Ur+qAx&-yZcCPF~}C^%qwXuW4v?
zJ7=)1Halmry*4}VuW(=0&T@Q-150dZN;gtAd151HuG5Zd8>?LxX~ND<Dy~CnoWzFC
zo)a1uUm0a;d`g<o;w*e-RCH{pDc6gQjqKB|L(4z<v^f>^eDype;c#h0eFK<R+5D!K
zpX6A+tp8Pfnfy5se(^WxtxA6Zf8$T$Sn};z{dy(e%6eDb|0nADllpoCWfSY-XS|*+
zBARe;76*_lj+xZOo1>7g1IXC5C5+Ak1_bov-;D4mCrO5C-t$m>R{v+ayce5VDD~|E
zwPQ*;k?KR;HnnnFUu|1u+8M9TiKMluOlfC)wQ|gqcE(rBqo%Yo-r}#*j(#lF9;R}R
zDLK@o5f?9I9nYXCpJKD5x7GLvkMj=-4DpYpZQ>sjt<DdnU3-k?t=j*}Jn}pbKyfIp
zy=PBxB=gZ2QLXHYQS(e9>(%p&821M??Zz-y7WE>tHc49YVEcB$MSVR#E<QApEGyH)
zsQV14KEFzQATwzNhJ?h1#>J`o+$#2kMuk-D(aNM4(n2cNFW1se3$Gfk?yPJ1Co(W@
zmX>}bjlHAUL^-afsYmrRb-F1YSXzOkDQREI5~Ia+KrKeBOivN<YJ!q-$DsPE{;x7U
zEvZO5Jtc{$>1lrDHZdJ*m3AI)QPs}o>C0qi+|+7k-2SDV+4q-r9&b_A&XV^=>2@;e
zhLONiTqx2X_zYVXX|@+Lsm<ZQD4IqTO`$|sgfv&Qsn66rC-GU!Qc>S|u+zMLl{(76
zHmzM36CD>99z@-y9$#i+^Pd?g(O)G`$QZRO3>hgDvGTZ$@;Tu&WLM+~HJtJDV?t#z
zuy881e`=dby=&k&)$0SXkExB6Xo~}uj`g&;gc_r#IImGVZw#};#p@=b`xdC4vrO|+
z{r}KCY-y|vuq#3*SXij#w`9ob^IVzQOx4SE$#Y_u+S-#3D-G==-`X<EWwkI#y6(k4
zne<HE$05`->4`oFw3pR<nZ)mJxHjf`(hi}{-lpYeDf>>V`_%TjK6{$pjv#JUU?=I1
zSihsy8ItBb@T0ZygSl2qJ15-8y@I!7yY5b|N$N&vurp8BV}Wx+M`|sIs%;2U+34K@
zhb(R+g3hQ5`W@kNc~?Czg`%X+D$Q0kP9*#_m&&$#7CWo9d9-=U&ZyTcZ6~ePmAJ{l
zZS^!G+w<67TN|RF!hO|xK=Q$9_G$IL9&|Nh`IGPDLgs~%j0wMHOTB%-oPbrD2x>a=
z#hsR3qG|9+Q&_9B!q~o6ExY9!v}Um!FNW<}IWOBylMHGXDc9o3eyu;Dwj0&siN650
z|5ZCi%Hx^)wfHx+0rC%O>px*f^Kz#^kH^<I9!({A&Q`f$AblKG-K#lR=4Vvv{_q*p
zcC+V%$5Q&3^~Y*2cPi_<Mm*rF*LPC9spp@fmwPcSWsBCPm->NZsV+%c*&Xmt0jR7j
zw8n>&H7@!ws!C;Dk)|D6>R;7qGuk8TE4KAl!)Ka9P40Ke@*)=?_IVbyAdueLHTe&Z
zjUO)K1>-^^qhsm7%lRd)Yc3x8{BQN`vOhN2qnBzAiDwCjFu_9l2-;wP<W-rM+k-H;
zbKV5)oE7a&EnP%N`$O$$%W*t7hPFLEHZVLw-68QUX=1K+Uge^m22A~dGW{AI@N3@g
z%hGI8?HZk`wDVL0;;-sbY3sukcI~A)mA2o3ifujBK7#r6k2kx13AbsS%JDw!3}di^
zR6#tytj_iAovYeX!Z;#&RCMgnh=}14;Z$A|)WL%|@g;F0`LgCx87I#lF~vzwwLL0f
z3c$m?b`mGjaSIA$_(8S3#IIIH1xH84hbF|cE^$?k9Z%8Fd7bqqwQ#BKU0D}5watGh
ze&jxCEc@GOVNm@@p8BhCgq6BG37dIdF4ApOJst}x<FQs7nPT)`$vfvN<E{@uRNGl+
zD!0j{s^JenC4A%m!gg%0u$^4P0DU|(Ksxs<??D^b3X<PSwQE-6neiblyLp8M&LV~-
z-1~7?%QCbl8>OyKL#3{l{-PwrooanjIk%)KzaP@iZ;cyS=x!?|xGg$bk<J(dC6z@7
zdqziV<58-^n*Y@NZhmc!5-}|1$G*z3ORF4v1ed2JVR0+hCR)o<<M_T}Fcw$xhFr!Y
z=x-cf;l&DmitWb4X_gx%jWls9$CtELbE(W5PI(o1L(Q*ZLk~Qdw<TqpC)@U^b(~g5
zOFiYyw%=7-*X(ag9`j{?<oyyiRmW8V*sk@DtJc-x$G|=<Khc$$6CpoIbCz}n?CXOK
zvRRMOu31fs&a78&!%4gdrZO-=20~aQip<Nv(#pJ3#dhX-#vmSRER|)Tg@xLGmik65
zTcixURheh{idS=+n);&VHZ}E6%xyZJIeM#)VVK*rdOtXT^N3BW_k+!CD#tY0RI`sQ
zG0H+-mSr?Z|6~~aLA)kuX+uj}Q>4A`$tZ!hsXP2P=}Xb;!<uPH>Z*M0xD|DkseH)L
z!yy%C3y^-&pM;~dMmVa5LE^QRMGb?rkqzwB(sPX323ONeMOvm|<}dTdYW-#x+-mJk
zweLSKHk=7+S<LggJkuh}l6soG=A(BBr^}}md6Ar`HXYQl192;PF-(5cSSs`4*5jtU
z*vnO%Ng9bk?{RGU|LR=1k{2?uQvhL*x~RW)PBkw`9@X+r&AE8RPZEBH;^ueVk11Ww
zVcP@?xr3oyr|BHIxF1j9;(AOCmwFCw+|*Wgndi4K^1Lk7^P8=fS0p`Ev5$Fv^H6<O
z|5uscI#lF0t$ii=txe@NsS>K#P3^Pma}1l(nN@r3_){6*Z^=)2uB_gJwEObS<8MT`
z%&Q&B{RwgX*YQ`G)@#O<om~QcKTzXO`V6Kx)W#~b?P|YAjoYrow?w?8LAgIOGb(&W
zcyJ({-;j#1_|K3@(X}!$0y~G1=eOZLSPQ!vNA9fuRXPwqsk$HQ&nn|}#6S2cz)uEl
zcANR}`UgMqaqsVN^TY}5Jd)nz+O)7$rZ-7DrnX>`9ygEUPRgQ5U`5;*nao|U=SVwJ
zk5W(T?ZC(6CKB%cslJoGK&o~e%Ip3W<+2tJmF)%7xQ&Z}gR)dl$1YXUaV=rd6SRa!
zuD9l*rDqAx(2BI%k6NR?UH^*pzE#3!o{k6W?J1iM+L2$vFk-7UsMxBshOHhWeTB!x
zhX?;do4GPA2XH)dyGWVfYG8Z<UT5De?HvDD?uZ|GW^W08QcqT<0}s}#mpkTVtWm!<
zv7cO9H;_81l$&x~rj#L*LSv$1<JH!V4<k}q{7czh%TiGv$??qFHgZl=`_P8t%hCnp
zoKDaHd%ApCan8r8w-5iW?lIN94LJsLeapQeX;!K><Isw>T^&nMx0_$T+*g+cuWFl;
z?59|>5>q8C!>FWYsSQ?fE9vd;!Xxbq1Mal31qn}(_}2y-RsVKsdqCSS;i|gdJbdbl
z-uRI*1sMij3ylb0T9xpP2%1?fex#17xm4DH51&$PUD1D+GQ%4W)yIu|*;aFW$kHwg
zyUBN<=Cl7DEi9_NCEow4oj6P%uW*$JXQ`gwy({xO@o#=jrkYE$y_}=wQkmBSEAqCR
zn%AdRtoKv%y6HMiZA4RhPp;Gaeu#OR_35OYQQjxF=BL!xf09@NG&@Q@(ZW0`B5)@A
zC5?#fYA%&=@cLI3aiF$oB^&{G(Cn?IoA7u_64_o^*Qn`5-TpA!r6ShG(oF8TF*-NY
zKRPO6zBYF3KZ6jd<&o(=hjx5*RH$O7lsj(3i#*f&CdXW>U6*=pH`Z&b=d^U%TusaJ
zjIS)!<20svoQi$^#d2HP9Lp-=u4f-PzHFOcxlO8ZHH-nM7Jnu?RJGf9i`wlrUM(+z
zu;;&KxA7KL?Pi`=OLZHVmupSPBeq|gmuofqred>N7PTyuI5V)*hT~{uTd+DbBkpCN
zsJ2h8uX3M+%k+FynhY+pNZBUkE!{iCj^laj;qng*=C0Pv(0G4(wDMesjQ%sc9y%jD
z0jGac-Wk*|n##N8Y8ds$tMsmeB)pD#IJJ8N{!)pAc&TTqbYyNv^&=kmlYAzNj32b%
z*hW)$W7MzSR4J4tzp0LE{!_y!$2ZkKetP9)e*7?Lw^uzr1(24R|CM8#+Pw0tx-92F
zY+VQ&iKR6C*rpp#rUz2kt=iX9e$-ql>QhshRe672Yvb9gHkUDS?b$AKJ7!2iWRbE%
z(wG!7_u)S08!bJW!V<~IoavztxmGva)v{EC#e<#I@2g7qwQcHA)sGNKxh3JQ?LLAp
z+qH72>ez&N_~rY2vV2Tg+Y<c%ZB6)XPge`S43(HYv!W(i)n}D|72!9sxq3a9$Tkj5
z9;+JuB(`bS6+L4{T&NU-YQFP8HTRnB^;;^$rS@GE2X>mCoil%oNAj#(yXH4OI-bW&
zw2>a|xB(UWW<*EF^W`Ufr`R&AVjpdKeUGW$){dv$Y*hP|#JwZ-+l?P@&0cCbDFx<V
zmF1?sLAl(ZX8Ea}He~TF+LjY|pRH<l%_4kusxtYgX<2Mp%Ti(gN}FmIC)bvO2kjcF
z+CPo$)$K3tGuU2Ry2@gEZRtwlMeJvuU(Dl0>=;vVu2}z=c=;xmHm;(bU$$s{-hc{s
z@v1vhoNDf(qN6IKM@=i<74Fr0R;DN=KDdua9OYu~qqv!++4pbb$>gUDKQg}C^IJ7e
zR6mt%gsS5blBY~@>--3wSTd}%xJ^Uv$MB`!)f%_@jXW)LN!cLrRLfEkw`uG&e~w6O
zC~>95ZDo8*Jk=K8`zy9r<~ND&9JXuEU{oFB%wxNjo~xE465k2z`>T8?b&^NLeky;p
z1T{|)T3k!qY2mC)6P^{@D$|6d9nGDVCM3+pifxh6bN%BMu&Sm9Nr#%-nrS7VVqeX)
zA_H}$4{K><zz>!2{#SWg(u(+TBF-hPC`FZi{*|<n;v$}S?u2sJ0hN2=9SL~BPk)hC
z<Q9)!kw{wcRejg^SCLi%*kxW0OIi`zX!%I{CYIzav8}c(G(!Enot}fl#uCTczN+Ph
zv0{7Gbd<>U+RBY2w%1l}$T>XNr-f5(TXKoB)HaQnN6+*0@ziVA?s)5Ewxlt)3OCX|
ztLetPzKf8?Jj*B$dk=+9*xThoRePIf%73-Ku5M>Z!&=xY^Q3phwyL(2c&yE40c@|$
zW^zrYu@m23IAWOya!oRpCFM<0jcYPXJh+kTk}%e?RHPpXZ}sbvuxi((r5{OC0TtUS
zueCCrRlU|2+}3uj32gtXYc+kBDxf!xSdu}m^+o6`8U3QfpNIPB>VK`BRhbtm<E>_1
z5PN80)XEMS`IGc3HmU8J0xH~BEjz_#2KJfTR?1Unwwdx8nV?EqmpC`Iugi5iNb^%V
zDAL{UjvaDTJ1G9aVQL>LIBZtsH`C<UH5aXaA>nahr*>`r!^NF!bF17oP9CH)<yF0(
z;iYyla3f(e#Zj2ri)5TjFVh}EAC@?}q{UHaLJZFpSJro8yP8X7AHHp|nm1(}MZIcM
zdaG``%Jin+Z{qO}y_itLE$ObdxJzJrZE<I;a9=g<#0Fv)tq!g%uhhDLio%8K-^zXm
z^?J2F^551U?38y)<(NO3`SD;~%%=58wJQ-j3#R9r64kqMT3%>?TS*JDB<W)UmA3xZ
z$9JUvzooMOua=myZGGi7Nh)gk2tXwsOyfMJHlU>8iu-<l5fA3$Kw?u<JXF6QXyhCc
zZ?)YIG{u8H#-P?4=4sJa9re+^wJBqJ)4`@C{aiIodC(ZqURq$YS{};rYA%&&@$1U8
zSYZPXJea3NxfUryYNj<yyEVj@4`GseXRUTDwY?(wS92d296yH+ixey@rua5JU#KP$
zwmX1%d}rzLZMq&)Y)ct$z-`T?axCv~MZ9Wbc?T-iwXr-8Je$X{`SqE{p@h{`CwcVO
z&ghTG;~r0dizMdDT0I*cH8*-zsQ<jc__*jOe;(M1jtY&Q@po}hIS%5%Vd7ze1*uz}
z66UMA@*Y7nod;>li0$?LvQdWU=7jdt_IcN~kNVTpzmRze%#Vw6bzcCg?VB+tDp($7
z)!wZTTS&R1@2m38MGV{L0N*67^3H`Rt!sIk3kZ#!D-Z68{Y>S1p>DsY@lVoM?>R{M
zZZz31PQD+iKD`>jZZ+*X%a0n%zrTD>9-y5>%Cy!X-JM>9&E<+#zMFSeCH>VNE~TQ4
zAsMN9J4y0k&HSUa6KgB0CC)YXRc&ov7Gw;>5sTbolCnVVG4&Rkn!+tbtl1ccuj;z`
zzsj;eUeMzZQZI=qs+5Q3V@Q%ds$YxLVIFMf^rR0{o5|8H1>43D&Yf(3UJchj*B|01
z9Y6c=<N321Cbhm38~)XO0#kVsA)OQ!2QV*B3iR?M(qxnW597(_D$0+_XWY+JZX+jF
zwUw#vFy$q&m3g^hZY$ICCFb#(Hb{=BDA6F-@f1jV!>GoOhrIbvrOza3rRJi=tK7Hz
zz9L@T)Hszg!@PW#I?k7ETAHoBtr5Wf>TzzmzS`2Slohq5U-2XPqqeq23~`srwM%nr
zhZg3Fc-PXEv`uPnH|!sbCzk5*UaH5tnaxa9iCV@;SZXenb%{ki(=$YU)%!xXD&oCQ
z6<eC(+}xIb)m{kTgw@l8xh<==7fiOSt-WBfW%c%gsob^l(5~(tBDVPx`e97lU$n9<
zHne6RO433tOGWt>z)th@Bk5Vn1TFnk_B$lp+P0egjs*7AmY$4kuPr?#R=BTP9*W&O
z*r$c3vh6DUXt9lUe%W5LAN{ZPwI5Jy?A)-KFE{DxDHZ)BwZe?!939!enR}ZF+%vIM
z{Iy#n>Z`t{x7egU)7&JQyNTeHUfsz<?3Xm2V!mG+>a7eoC+n)a%P@BrJSUciVR*?%
ziUqZcCBb4!9qpL=&E3jd5Vg3IdOg?No%WV9%`cvGiwc%ow(50?yS$q2)JT`R2@<{*
zxRFY{!WO3RReNks!Y6TbMm-**X))T}N3D|>!%I8iQ8U?p9pw45(BTU6vH!pGU1Cql
zLxW{<k0!>S7du2<?o(de!0WTmt_&EncVoWgjY-z;e!Rqa9WgVJ#<#(;V7Be0n<*Qv
z-n{zFVt?NWgD*D!?S${4w*AJ%v})^+{RZu^G}V5VlNa2x{JQ<FL+N?j-gMgWYoJ$$
zTTv??ojG9Dm%}3mJiU*yS3Ta-4h?6_yS;Vp`Q%?d-mvp<`}a2<b=>;ptbNZF=6_N5
zz2UI~&fLxR`rrHBaA#YIx0kOu+%blHdvDsK?>8SAeRR#b*bjr(O&q*Dcxuj<uWoZL
zXMVzw;%;q^;}0bM(Rtj2D?1N*_P2{{y5!l}k9kd8yy=BAT}N3h-KHqxMu@vkCsSWr
z|ME+HE?wKZW?t)*Z?9XtxkT}P{<Q&*yPjRw=MCcb4eD5f<(fX5dfa<voKN)N6JOj-
z4*ns1`Ph3$^FDdtvlp+HKD^}34t3uV-u(HIjJUkMw>PfbG`Z8w#h#}(f3fv;FlDrA
z=ji8md>gi9!ssQ-o78XgMZ0Sw-&@?tt!Uiy4Ig-P^)UaQZ*VV+cI<!hcZ6STCE?rQ
z+OFG{jBhUY3wWi;n4nRM-i_RGV%*m+o$Gin`1_<OR#)r3Bm73z;l(~f5-;Cakh}e}
zrXP=8|K8^peqo??gPJerc}`wGa8J|Zl+T~vkosm1``FvgtNIzgwqIF%_LC>NKSjBl
zM1$5~netOV!>y7RzdvogEBTt;{@&A@Y`xQQ)VAHb2JGryG}-bD?=`CK44dcQIk>mc
z?D%F=-#*(TV%3j}nr$lRb~W`-hq&nXogUiFw<vnc@s>aQ{icggEp&4)$UI?nqP0bd
z=lM-tCLMUX<EEZXmpy3NoOhPh@RdKkWAS%ecKr18g2wN)Y~N{)?ShhDx_|d$i_8OM
zx3+ETzmWF;)Z=+R7*uFo&vN!voA$4TyQP(v#O6$L9=*3;gJD+=+=;$RV@~GgHCXzt
za$TLX-R@Z9-&=fs`~1D5Z@e+H!GnGWwmkXDnXg~{P1^ACGMT}$)O}!P&+uvXj~#Kc
zzU=tx&y)78JoTAXy?ys?4?VHz)o$ElT02(Uz3}GEgKbvcSW)ca6Fg?PYx(4zUqz-|
z*c>;ivwKNqS=%R=n^g^8-FJVtzmb3VnFs6&y3QJ8JU{7w&Ub&e(0MReKJ#wQ>RU$+
z^vZ7b<>sRezis0(?PB{6cOPl@^WCj(kxxz|U9}%2?)JUeBINNOJn!{hGk101wO*HE
z%lf=}sf|U}sjd+R>^Dy4X3?C{;%?D0x9q|7Ry!5lu^;$js>k=!rg*<zR2Da7M%Q`Y
z?sk|-Bef5s90tn=c5MBrYxHj^yXRX4+I(W`d~C;_*!~+HPu<bDMbma|OK=xKN8DiP
zWSlg--O$x-w{Hph#(mS*k-G=qT(Rzy-4C6Y3<;judI)*<pnBft`n{YN)aqv6y6*$m
zeIIz@r$-(>@#^7AFJ4-Iu-x*}+lJ%M6eliRw58d#bSvKVV9df`IX$poU)=c8r@Ol}
z@KlNm+6`&(#U`h`J?}T%Tk_MpU0-qG+dpb~diARVakuvjEj?K{<j`-IPekV3T;iO6
zUx(B)jmqBhE#LJu#qJO}o>l!mdo~0-G~WN>y7r6qxPR#MLEZO(#V-H-zYly*t<M`A
z-!;IyWrI6sT0f;^44!u2;q-4-x!;))JUPBk=g-&wa+CpF54ql_-kW>nU`f!Dv)^vp
z)x~Ap=0~poylG45on<>3`K@g4@dN|CL)7wgOOp>r&D^{5tXtz*#vfJ=dF}l|_oFWz
zd)#f~z?oC8wYfkW@q4vgyVN&*cKMRByC0n>eEGrrt50O#eBy4)QQ>>vdi3^_7nVoT
zXY^6en|kx|xliBmTh!-))%TuA`6+1My>BNv_HMK*_4=%!tg|PEG4H#2-tFg<py7s$
zq84s^Bk#H69hV*M?7scPv^`&}yS4hx2lLZN&x`>ZESFi|9nxrhfW?HqC*M9h?1`tB
zUq0Rcd)IkCH@LRUc|(JhdE84-&%6H4vRk8udfx~S{`lZqJJ;SC`1GQVj>Gz0{Aqp0
zlggFXxc@NTQ;v7#(q+3Jr`EgL_Ky`AQ+syW=GiP_fXmg}uk{$ysEgg6#CeRH5JrRL
z$cEdBa<AXtCZlPq;ZF}~yD6#j!jI>UXxBMm#X+lqKaQopHHdLtgXMvlnF}6$dg9D!
zN84{%HLcAH9}IXrq)+$$q4U<~U-h|m-(_wQac+ZU$9)a5(i;V>t@|!<-FJz-r#%zd
zCo&~+rsFFcmu3YRTAUB=IpOAq1rA+T@s5@67)dXAg&UmK9eT5I(u$w$48KhY*f!^r
zwe#1xI8Lxwn(LMHq7UC9Q{7EmeELwo7GJO1a4i4l{U_ea9@u?a>&AZ$`fkwkogP@2
zJCnTe@BZHK5j9`deMh+NJHnDq{ino~S;zGGbxzLwM$0{ZekA8Y_nd&hub1DOx8sq%
zy%wb~ZmYI)K6z^Yw&1qC250Trbam|6lSgh&-{aon`i71#&6{!e^t2(=A15D`<8>MJ
zl5dLzbKYA0MYFIw?s>(xTf~hly1ZlF%Nc>4j=Wd*9pSGZZFDm3T<7Rt4?NZ5K*NDg
zydB-iW_0gc>lJ0DI^Gns+wLJ{pijK}{*#+rE<V4nuzc(fA3kVl-=}ZgcZ3}W-+jbk
z=_Sjw8$tOOeU2@^xW=__N><d-r5n?zqkmP)wfirB*8cZB=TGcd6zab?GoW?&$>PP1
zuk4+8Epo`jl2+lxyrZYuIct*DAIrwwzi`p^F4^}FeYxQLypGp`a`t@L@mBJOuX?}5
zIN?Ecd?Vq`wAppv5q5ZW@pEhLF7J6giSaA?=myJ6etthVdBl8o;=R0=o1V&l_2WU!
zI^4OP=QJv(-x%-9D^}C*=H(-U<tQ)Dk;A4GwGDY;-cMiNnD^<n_m#&EFSzeu?3W!^
zY<x71zWIA<`^x(L)GmIP@0~s7FuBFny$;ziowGVTp8c}zFqdERI^5n$+{!~r21^&8
zW_zdaod3zT<0<u%U4HOvw(6ZR@21on?fiVkR%6@m?q^OvH*r^VYqS6GHp7BDefQy`
zk>eli^1?40tsDG0=9h@IyEm0wYPy{H<JEEWzIUwN>$mfB53l_X-#hU7D%W@Ft&eWF
z!J@;PS0=u6<GRyr=Eb;Aj`yGY9pSTTJ9gmj$9<k2KKj}B2VUwty{Oo0-?_k%=`NF#
z-F<uhxOeAMtC$;?z5wxYU`n5x*W&L)_U}0>_O(&X-mRDQzRj+&N}D@*jl6pvUZ{R+
zSfTlDn%`TU_uJS|d+sNh?Xt{os7{5ZB%p0rUx0Q%7omO8#i&FXbMva-?Zv+_ko9Hg
z43uyG8RaJDO7uB&75X}wh#o?pLBB$uL$9DOqUC53THk^(Mf5k;iE7iF-|Cze5>C42
z72lnG6?ctTUxyNn%6ilp-KhJgdv2PuTb-*?{9Cfk31r!fyZY#BsLY>~X68?yZ(H@}
zjU#h^Z}7N>_}h+(zYJ8u>p<A``LY$6M_c?E*lxpiS>mk}qYXL-C0Z4}(Q9mrGS{=Q
zC%OQA3|)v$Mwg(0=yEg>U4d>ySD}0(S9t*)h`xkwL0?7RK-Z&Z(T(UY=qB{Jddzo#
zK9BOQi1BxHH(G}7K__#8eEZoLg1&>ELl2_78lZfDI$-#Z(fiS(Xjk-8bP#$Ry?}m+
zUP8Y{ALrV?MP(lGLR9SI3;I0W>ipeeA8WQz<fzLB*pVSU<wLYHnuB_xAEDy+W7H4L
zMV~~Eq5<e9s2ty!Yt`q=R_D={<9B2`-?dhk$qlsc6i-3r_>ZF$Ps&s@44sCipwrRM
zQGfIt8i4+U2BC7lI~e@~4MpW$iWz8YGz{h2*veDrG&BO0xzQp~dHyQ~{S@W<OU5#E
zF4_$HC!jJX%3|~gx)gl`yBpD-=+meNx)L3Uu0p-hL^KQKJ5I(A(dSX7*iv3VdG$z1
zLZ=WPYtc}29r_f?H=k5{r4a^wK5ccLZLyc6!(_J0GTu@#I-(QM4(LR*J30v!cXQDR
z=zMfJx&VD1U5LJnE=3iNwG5ScmzJY44^tw#6nzer=i}C(KcGoyDf%*Mj~$XxC-hbH
zdvr4@@33t_XK{Ty(Dmppl;6s3G??pq2Mt4+?$20?GDV#69*S*@leoqs=xp>Tx)A*Y
zl?<Ja7NJbLVZ4Jf?Sipc1LiM7+n`^g52L(pX>>ucv5~k_cxB5-Tqxh8$!HOpfs%)e
zJJIv#Zz!)w7%dtyM;mHDdA!ot73I-8qkM0R$9{}%Xelc5o&SbPx|VWGpGUmb@@N-H
zh2W~+^_KF8+fb^%1b*vtfh%e98%I+9M1U;3e`%CwDnCT~pdX==P~Oj!&)O=vXdrqN
zm1E_h%Tdy>@mcg3x)#kx*P{iflusv73AZhArO%(O&Z{lwXBbqmV!JH8a3|$oZ}dU5
z584ft?|{oS%lE%&&MAXXNoPY)Z*&-%i;hJlpL(HE#_|roS{{0%9<2MIap>dd5_Bq>
zh%&xrOhU<{#*OH7RPsUqx)%*XFQB35Ep#T@iZF+v_oGjtozYq7BWMIV0F6S2pt0yU
zG#;IT&P9XJd1y46fG$GkqlxGObUnHd-G(kg_n?c>edsdu1o||31zmxbpsUfFC}oVX
zCFy?+`XKr|D&@wD=s=V_W*m#YjE+OsqEpcnGz?vj&OtYzt59rWT#KfnZ=jn{@|3a}
zJ&a;2<7a3(N*Y$Sq0Pu&8E6l5C+d#Ai4I5ipfaEO+o+@qXYl5UJxr@U_a^Cr%TVX}
zN0eQ-lX_kJi~G}{&o8Ys!jrgnU|T-O@)_y9IeG#$pri>k9TlM5o>WeubaNHj9LA9-
z$5YeM8T4`1zePjPLUbYe9l9F*9+mdXkLWt|Jo-9%5#5hoLOHimjB+f6wv6!?^k?)I
zT7uq2*=D?hmZBDf|98|9r7lsg&%nMI-5#y@E!W3x#U5n2s=IUJw?6kV@4sm7Fl$A7
z=qB#OZk*fL4&~g&9w==q^*oZN^f`&uxr*gHM4#dWvSi`T8r_4ALf_H-#qe97Q&^pA
zSo}3%o7ha2!PF-YqC?O==qOa|JsM3!$DrHLvFK&g3nlF-<51F;G6AK`QM^$}2oq6>
z_ac7lbLXma>dJYivi+1K7M8a4w0hhT6?;5@O1q#Vnt)Pw7}ubk&{t4rGzIO3ZbiGJ
z@1hT*5}!TMp@f6HY@|$42BOcPgJeHS-ZoNJD#Ov=(UIs~bTsNtm>xw3qvU;K3_1ag
zMfskMaTWR)dI0r7b5Y6$<8jmvy^n}^5_LucP){@vrOs7?(R4HfmHZfrQnx8H(Vx*U
z^ba%~y@N)gO-LA&HOBi;!lJg@=Ab=UpN9@W6VOrU0`v)VAsU2IHW|aw#po>5h%QB!
zp{vp5C~Z%Lvdc)@QF$5t5Pb#BN7tgX0hM*=?`R4-jJVr``lFlCC1@J@0=flFMbpt;
z=yvolx&yt1?nXOOf4+rwLn#}L?&#YnX-e6P(w0*wD~+?z{phFYLG*j{5L%3Wi2jZq
zMy;t|KSCR$N6<;=Q8Wns6pccO8{={`AC>Q!e~!xc%L~wN(J#>p=vU|s^lS7cdIq&5
zBNd`8(C^Up==W$hlyq&BxuMUYlFp3+1uIEOc?~3;H$~$?7Awj@%&5>eGRpRbXbZG4
z+7YGhQ|rs7sN@4%l<u$60+srfHmaJR9nfc3r#);;LffMoPy;IAaE2tk9BR#P2?xou
zqFio+J1Jkpzql_DH~Rd$)HSMm@s|s-{6M>3!d-;gp+BNhF40#o8c_NQYJZJ3n$eZ@
zYiJPq8ybaPM<twpps8pX`YC!FrL0%VQ3(TWJ0oSbQm;Pofm)%`F1JS8qD@d2v?=P3
zHbX;Ddz3m{X^m2cDh{a04q1OwKiT0<>>&QdeGKSx?kZzAPWAH93wO<MGY+L}RVJVx
zh#&N0ls2jHI64`ntXJqesqJQ8bRfr@iVi}jqa#rAP(?Tk{wADH;7-CR{v@2fpwAhr
zzCSMEBpFupzp^NI+pzvN`XKra8jS8oUq;_U*P{o~H1q>>EBYZS$9DmJPFVH0a(s#-
z#R+5yCZ0q?P_l^<ikkfC^S##U?@Pij{`f|c>hCN4daSX9K98$9zpI?@0X9+JsmqJF
zlk}K`wntw=yP~h4z0hP->Zw=JQRq5!BDx-xdS(L}fKoQ8{lm?u#Pt?*DY_MvdgXOg
z>XmJ17WxMIHkyGRMt7heqm*sNFVRetwutf;D(N;0rLCa6jnXDi_M+r<<sFnft?Wa|
zbIN|y2|a{%Lq9~NUzLN39VP#k{!Mx~fICSK;$Pf*fIe5LGMe9FKmHWSi?S@x-P1=>
z^Y0>5+9#CV#$o7ERE{I@uFo}E(JnEM_or~z0yj~pv`3<Ke|h5fQ?1-vQcpX-jN=>v
zS$@Kug!ep}iC#pr(aWgV^JnyX^cS=gy^7Yu9>1bi=rvUA^gB8Uy@5)7{s&5*M!AU|
zN6XM}&_B@!2*+L2fLf5Qr5(@vFvdw}eKZJdfJ(jI7?n9pZBUc_ZMAn$YHimx#GPD^
z_!IXzpwFGDNPArDFZPvdl!ZR0u_f9TmG((HbUNX5MC)_j2T=LuLwmFf+5x34p-@*E
zUqqcy>PDp#N}Z^5MyUf8XH?oBUD4Ahb*hm%O6h_Ah|<S3UP9^P8m$RePqYi#3+;ot
zqCRLJRIbAl^m!(g$N4SSK{cz+Q-mm~xRdMNgi1Y-hB~6@=!58XbP`IRxx$Vve`Cij
zxRc|Fe>uNet`%tMNX8T7{O0A_5#9Y!RMJr%`U!drb;kV(v@2SGPD4+k^re(9P&vK_
z=<_G4X}x+r`GoW$;mJd#y!lkp5qcc$hUTND<LGlDs&ge)KMrFS>Tzg$8SU}MSdGzu
z(grh185)6_j-$_KsEGZlA7?P`<obu8Vs8&r>fNEJgliZo#|Z#^-a&OfLOG6HhY!dy
z7I)I#@IobBPC(W3p`BQtgu0?W=yH^?CgTezZAo=pzz>!4ID_}!#OLF<lk<u{ai0eI
zJbcPy#Dj!Ot|J*_F<?)*zD}qu>Wub5yP!Xz-B9{qN)PmR)CHCPS1(k`h2Cfbv=3^B
z_C@bU-B2k{2cZ4Yf#`5_2>K{W8`j7egEAa7U02NCT$elU<hsPaxc2~k?zmdx|FrJ@
z3@Y(|7B!&Xq7wgws2s-)^ts;D`YxwM)p7BYWJfvg7bv?F>KwIRKZS~aDX;ap*J`bA
zX%iZ8BHxo!>s#7h75?-&)oS&(R`>U+?r)v$FNS03^Q9^0_$~2i-hbTIPz&!HsKoPj
zRO*3UsHC0Us3)3*CZK!J1!y)Z?bmnFW9WNmA$kxsU8g=bnpzggc`ey5wv^=>`P%_y
zY|hvZrEj46OXIgbCz(1|S@rZ6%kiaLjzgs!i$^=5bI^xT#_rVP%|ks{m-{8Zpi5C1
zH^!*OCZr>|U(yk!kD<2jo<<qFQtz8E)}!7xc@167_5-NgKVi&Hy?-Ltmj?PAUh3Rl
z)x*g*^wfNR2R(<|yC`EjG6A3Q1X>S0hgzX!XnoYS9%VO5Us$1!WSopPLZ_qjm5hO?
z4VsKLMd_O<%~1MGN^_JxkYbC<9AkE<gp>Y=X+A1-o+=5aw8tbb%F+vWQa<%VA42=1
z)6jwF40I40hYm(1-iM+uqQlX*(NX9HbTlgM08jKLIu@02`SGaaU;23J^*x3jBYcz5
zJLu!63khQ?IvkybK7sn7vFLR471SS<arOZ8C>n&`LW9v3R<vu;htW`UAUYF$1`R_u
zqEDe|=qyz1BKbm}dr6&>N$g^tFOqR5>2obA?Xz{L5lump&<*IP=th)0ucV@1p>kjA
z94hy<B%N(RB@VWta$XmK!Du!qqd?BfWmM#gwz!k?wnK-aj%NP!d4AOSf2#X?NcYzn
z^}?UC?$4Ls+MGFB87}^${1!K|FovR@?;bjWbqo5%K4=4UHrf!Kk6NQL?o69UjsGU7
z>3a0JXw-65%0u((`GG7a<;pqK36*g=@s|MFJTcn*F%m8tHbuyG7Vg2Q;UaAq-($TO
z`Vs1ieumN(Qtj@Bo@IRi`Xf3BEkOsP(*GQWc0fm>522$_Ilq)`Nq<v+48fh0<Kkc3
zOBtxmC8EtSBH=Y}XZ?vgsjqLNQeW4jK9zLS0G)z1MyI1TsOkJ!e{=qZxRdjXKXLB?
z`kWeyKR=~%AP5!x1sT7Sa$CmldZLe^Qm)GVwkJ@z-zLWi0DW!=<!OFPe93tv&SkmI
zZi%lOsPsq4%W6C7Pt=|Da#YgPJv0nuOx3sur93e%L1mmo&ZDMteO?1s)~l!2tGH{;
z_FvIQ&{Ex>qzi4H25tU^>gmEBdx)J|qwk_^&>XZKnuk7sO8R&Zm2rqps1w>5jYYel
zMwGE~<7(6emG&lMa~1JY@Hg?&6?bAU@h{gYw$SDu(B>tO@LIFYl)ru@pE$5yigrMM
zL%X0i(B9}D=#%K5XedgVXnYF2i^}nxq4aOU!#xN!JmO#6OSz`K!>-0rjrzVR=~Kef
z43+e0i_Sys(A6mSGK_msd-NdM3jGjuK#!wsQPKv_J19odgwg@^AuV<%ar;0#BtaGw
zz;&?a0$sreB47oi!hSdfC16FOb_5sj1V4y}HINR6;1raARRHG)ckqE2NCfU7Dye8T
z6hH}B2NE{$03Qg0M974ExDNI~gbz}`A>5D$CE#$H^&jdh=cx#t865I~Y~0z>NOWW0
zqIvZdA9M{A%;UNgu7SeR6}%t}7C|Z;f>Tfq_6rCTctH##K_=uw30N<rz1ff7P!2MQ
ztTXsR3?zcvx%x^9>Vw9>8pwcLC<2=wS!e$tI0YqO-5)!EAH+jC;mwBvewTs60Bi~&
zum-Z>JjnCr?hpcrkOil~iUOfK_`o7agIp*9n?d-2Fi3<fSs%<gB!k?H^aB|rO@}<N
z^&or@2FZ{ECEzfW?GOP;kOf6xJB;lR0?CjA#b7_2b3p{8LJkx{IXF_uxq}}pf>byJ
zg-{NTBiRprun1D&5EOz`*iPUHc~Au9;7vw~ha|{_>tOGRpE2wQ!=r=~0>B7qkOM_f
z1`cD{4<V2U>5u~@U{68f3cj!i(jgB@z;+z@1-u~w)<7oYK@nJuC*6Q2gn<!KAPe%K
z2+F~60_OlPh=3%>hEq@i*4`WkJRt-UArtc8Jd{JC1!43hjF1L7Pz2Uf2_twxJfy-Q
zC<fanNXOs@Qb}dQX;7vS9`J=2NQHd34z_;85BNY4=ae?{2#ANYNrVM5_$~Knoh-3A
zEW&Ln?1xiO3bxZZ&O)vSigB|BEm(y6#heoo8*{!T#OG4NXoda2)rkGjEbuaLF4i-a
zaXi-D$Zw2&E1uv+10WS;%v4#_QXNB6yxCv;9bvvoyfmP!z)ktn?B}=J3eJz7hwI?U
zI_-bO6{KwSdJ&uaiXVPEt>pZuH+l#SK;^zjIXF`BbO-q!_bImfp~;XAIdC4VR&fs0
zfVx1!_qd@#i>I8+K=*?~Th7Pz+d>H8PC%Ww#&p@%-9pJmi}9O_Cb9n%>ad#QK_=^`
z!HNOI?%)MsumZB607}7C1{NV3Y%kPT{2&AJp#*FhaP*KtM@WNQC;`VyY=;0aLK@^j
zDcBctT=0WMkO8Nm91ILxdO!fIfK14TQn0;JUvY;3FhUySLNVAg(CGmYkObLK03~2u
zQeSZf4+wxnNQWFKgmQ3TfYcp)Apuh15S#~F22I@{09HU2<U<MAFpyfe)LEd;0(BOs
zvp}5%>MT%afjSG+S>Qjx0(7mEd-wE^*s5c~bPVVtwd1}kgODvA<o+&d)q;Kv^klsk
z{KPhycTnaxl(`HaVq0hUhV3#>VGn-Ge4dwB?~C?>%ltkIP3T9-e9ndZ?#=d#=%$X0
zx5I0Y23x?i?BjP+`dHSuJ%U^LKHOopHDdiJ>*1_tI5LjUwvCVqC2)X!^>Nbxa{1j5
zwcy(J@w*HyhjX~Q2pJqhzFYPQ`{cV}udr_|tb<GJFNSy7C*PeGe`T!y3GcH_zUL?3
zCjK4%VA~<KeZ=*Z^7}V9$olW7e2ZAVk^3?0ds)whci<|#$F|0VuL<Pw+Xg+v_6*no
zJHfQv=Jy@A3m@Y49{N7WO>7IO2RUs2fNhriwt~Z~?}v||73=c7qtE!=25k$U^SdSb
zGS`-lzio0n7JIfyJUgMC;49oYqVlbRulfB2IPm*8Zd#)!SZ|MZgfIF1D%<5dPx<`L
z<(Nm{O@50V&hYzN_zvX#v9-ASiQkU)*a+RtwvW(E^o9Xjp~JD^=WKhM-|wOaU<beV
zqZ#OjXb$Y+_bxOOKH!=zz!uWT3A6xC!dGBgwz6+Hj0Dq?&hKro9d^QeSOAM)2`qyZ
zuo|8PSu)Yx@D^mj+aSv&&UG1HWc_7W3(v4Fb5O72_j-_}g!NzGSCB>K?6=~YcXJ(Y
z!bfa>3q6c`FW8CA#-JNv6UZ_im3geDz*Lxwn<?-(m=@VS0`9<r@EhC!S)9=>&>bFu
zULeaov>wN>f(H7rMzL)qzsKn7kFwqf?7@d{OaWhTfnLxRx`8ac(LT@*`s>@KqO&1R
zU!R8h!E|^M0wDx;a{ROKBbb&<e!H`8Fvv0!4To9!dK2uJML4st-yV1yWVy?>_xODf
zc9L%1f}{NY1U`d3tZ#$ukjMI`kj3vG@b?D4w}WZf%J0|V7#xQ$;S}t}{Ws`oc!S?9
z2&*k++Q)>=mb_pG3)$Y4eA69@_`QiT<PPzF7v_>D9$~u+e9t~{-yHvE_}!Fk&7e8h
zf*pLy_FMS-6XNmPi!!<c;eCx`ZUNKs2ETWht!MFjui5&0{Qf{+KZ54zzmKDz>A#zC
zEzR|KILWqC`t~#ExBBlN(F^)-3$EExj}r-p4ZoY4tv4sUEx@$g#NVH~U)k0Iw=H$|
z_Gl|Jzpe0hpP64f!qrj_TU)lbGuzjm-v)iX6~}LFb`Cde*qik}`nJ{_!$ChzKeqMP
zw~s_U_21)BZ~eCqI$8fc74_492ce<*?|K~1N<XGt*HX5x(DyZDyS2VAf^AXyc5xTa
z?|J%q6Wlb_-95*)HTw1>biMvt^19?xNtcpGq`VLvPx_JaMDnWSE2%f7zLPpB1G|{B
zgY})T3o>Ch$incW;sCBN0zx1L7C|zk!y(9nQ&0ruV8eK?+{<$TFYto|NCDn|k$0w)
zLMVZ9u&;-Ea0er-fmDdFBrie<l!G;6o7`7a$2doz-VgvWkOZla0r^k}#lZ8>^31a0
z1g_u%0T2UgAO+H4KjeXo1vAu1A;@(A&k-u!!3{jY7mOg|z$uUkhoBIOLB@p@#&~(Y
zLme0PK>Z*B)&S2XDCr<$!v#<Tr6A+NHW*ySh26jt!XO?p;Sjho<{JSiAY;JUkOKu!
z3guwU7_U7zgB$ol2*iL9G9V91z^Vyu!4<qA01_b&PD44k+YpD~3n3sc=O#fmoPzUU
z-ITZnckqS)kek2hkPSsp0_EV?jPt<=2!IGkfE37pJU9jCp%mn0J_ERb7x=*%NP!H<
zgHv!G%E5*--W}XP>dAPJ{IDP70XYvyf>e-pp|o#(VFe^ZA-IsY5+D-}K|WjudD&<L
z_&^9q*}DRgAsxIamy;nKqz;j`qO^^?$V6)(6*8a{ls2RhFhF;3gHzzhn0|L~gAmAs
zLy!ljpcHH<_Z`3$q%EHXIgk&I<aMb-<3S$0$^~g-*n$D_!G`+94LrdIR=^=B2AlTm
z15faUFi3#&29Di<uz@>x!KqFh`ytE%29WRJra~s{hdek1Wnk5r{SXGZPy(LLY=baJ
zfJI$M%TNTKU9lyUgH1QC7o1@P_&@+;LJ^cf_wHOb#DlzmYtw^cLm0$^hYJcTAPG`o
zKlt`!9nv5Za-aZ;!KN421uozL5g-r6r$7emhtqH#d|f#X<iTmM?Ss9*8Qj1Vd?5i6
zAq6tw5EMZPl!HxQ><iuy0E<ArDU=3TkO!q8A2xLYR|o-lh-3|<KssbW4#>S}Yd7o%
zt}p`R-n86ncIwZ0AOIE(AS_S}Wsp6P>jGPMYyj86X%NSNbT|d)!EG=$h6E@Bk0Bfr
z&V#)Nejp4|AVYL0X%Gs*ei-3_cvu0sPzFxJIS(uvg&!z{60jYOdysp$E5I-Yn?e|*
zfz6|w8v>vlMvTQRtN^)}YBhm#g10v|g>1-$MHBfAx!^k)TS6A(KmjC7;hG^ELLMhf
zupdSQu@4d<H<<8+5GHV+iH*SszTu<`NP|;g{S<KlMYGTd(g&=F<Ql;`ifvFbo9mC|
z_@Km5=0OCc!+Efc=RDvIiI4(mbGT-(naefK!!P(iI-G*@PzvQ>oq!uKKzDG15#SAe
z5C-ue50b8d6iA0GNSn{~EI^?M$|1m3>)Xz@)7qzjsI+sXZy|m4J*f2CMzLM`H&O;m
zUs3uJGTz{b%2>gDsEj2@pF{dYQf^Bha4RZ(Mj4NgcD(d?q}?rTEGhpwqcVOl50(CK
z3M$8+qpz<;rJpM8JQ=rGfJz^EHY)w;5$uz`z{{*l-*z=B{o%H#O-r6lMWr7-1eI|F
zX>-bPrlZoom-exYkGzOVKY13%lk1l{NX8_5LB<ZGA0_>ZH(8fH?Iu+E$9+&4$9NW%
zzV|Ft`v1@A>tj(FkMPC6^b>cmF8$<gsEm_HJ5$DT=Av>wACR$$Fx*R@!kcwDe>y6C
z?l;gI2CdyFV;^-(odxPFP-lTU3)ESl&H{B7sIx$w1?ntNXMs8k{P(s1L*L4iiUqwu
z#w`Z;MaTI?2R-E%7#Y&nmG9#DMTSSs3XP2ljqnSOjgRx2!+*cH*kHfFm>BsP933?`
z6itYX7k}bI_39TMH!oN|bo(${`R=v5okalSBuY!Z%X>b?x<bc=2ggRoMbC&gI8W+g
zm=F^m9vQxX58@eyM@Po+UEWxwh2muA?>{%#KQKN%Hauufd}y3<AKSu0BVs~h&9};M
zypvsEd<5qZKZMUeE<P|m)ITyXDsX0KBwr8I+{DF)@JO_i-Q(d=A<^^VnCZdEZdCM~
zs1Ws|e43k~!^ZrB8!tP#2V(kudVz&lkUl;z9H2;-xlM1zKa5QjcKMqOB42j@r|;`F
z)4%H|_o^pY1Y-m3+vVDNq<qpH8))Bzl>0XmEd2dvM91<8U&bo1!o!NK8lT2`1cGHX
z$T0bGXh)cAm#JYg1xXE$8~bWmJbJQG!sCIOhsU#GT?>zV6V!=q&#2*<7akJI=j;Px
z`7pM8F;NSz0qp=>6TAE+eW>BR&NgetXhMfG-c<MP!@6%DGVW`z+!*!#(s%bha_Pz}
z_e;@>9{MGD#&Soez}vH97JT$$azsNvo|hRR?j~(IF+2CwZx-5)UAa0U^z_#k?_cms
zkIiF44qMp2bZ1I5>2XOvakpql=xZr^uf;#xbL`hc8~6^g2zjM<(a?=E9_%(DWN+Ct
z8|M2PChjtd{!knf>b`xr$g<<6;0y16OrDkTeaq3muj|^v?x$^;z4pBLX4~cCvQ`%^
zJ`!|t(&hYJ8@nuhvy^)SYJ5EWaOa8B?v8TmbEBi7<At{hS8QwEXvpf_KQ7+?*0C#w
z?(gyp**G~~>IcVPXmIhV`CX6h@##7AyNdw_jy(9Jlb6lW#>c+QRK5-7J~U;O!SZ(e
z{G>*XYof-V&i*{R*~#&{znn9=Ro{jqH*fm>renx2_ZZ9M9t80l-{J@FNA_LmZ}aLm
zpO)3%y45aV<J$dqvg7M}+<fLt?g{QssK;CK(tzF`S6}Hpb^HJHZy(xF-x(}#WQ-hX
z7<PVsQs__XM^78Jr`@e4R=s!rG}LA3cl#m+eU{5}E^7StdVKe@H{5+2eK2l%>tCAR
zd2Y<e`-gNsd?$YCou7)fXS8~n=Lxu9W3cT1!u7Jw3m*8^_q^ki%X=3WUWy;t@x2#P
zHYJUJWqsRDUbDF`!M!4bW$ZV$UMp6NvWk1`Qs}m!=ZxJ(+J3Tq%*sn=*11?+4|pV#
zXAb&^y9eUD?tiG$r8en43!)~3EJ%FbIIjEM8&?Oc%<I`^*!`*3s6*BKd-?vwSI2cc
zw&I1Jw&_Rwd!2jf`Ml84uMB_Ysge!*9=ke`d@k?ykzNuOe;IkR(?sugtoqGJNL)Jf
zNWr(eZOc0~965O5m0^vH%x9pw+dXq{+kr2g`0&N%b>BX$`}W}vKirwPY~W|poJuZy
zyK<06;<@AZIljHLd#?Sn+(%N&jSTlkUTbk_N0S|AazidCw-?&<Yjfz2ea#!K?wc6f
z?!6NaF^`s7t_2w%n>glZyQik?xz^}|zU`e(xmN$CVZ+gqPXF0moAKiA$(M|dS6lCy
z^ZL5{Dfg`BH+=e3`L}srJ#y(_d|>{ceK)LRegO4&*OO<w?l9-eN2C1e{cdr(-GYSQ
z{0@x%{p*WYW_R5?CA<3zJb&gP$NQ@9?LkuyU+wUcjeWzMX=#sTx?k*b>Di<o-5Y&1
z&-cdd0`Bjr_2Ag10}s1h+4cOV-+6qvr_qhO>Bqk~_SVZ^5Agb<@e75wn+>2X=_<!N
z-uBth*N48E<l^-C{;Zxoe);2rKDK_g%iPNUh>7*=Gx`Sin_7vx)eF)$x9_-Y+*iTl
z6Q;XNvi<Ut%*HL^izjzK|HtYbZF7(F+$i^N4gVLueRxo{U)?tiivr>%U46dMth#R+
z)_v3P{V#qQJteY_&#*G)+fnQN9iLl&u%h9XS8azneYN{Xmlq7<M}OI=+h<+BXxh9(
zzZHXmcxGA6=VyK{2rhLRbh2Yf@1*+zPrljuv8lTcTD;bDng4-$7yoE|p64Od_S(IT
zS6{gB?#^XbZf<yBSF=~%cbRKZym+8-`w*v;@u_Pa1Gx{bp7+21Hw~TCa`&IVRrtMH
z4*mPSL0I=~!J~mEZcSKbf42Cmv=6#>eJvvJ@^I?6Of^2%9JVi6Kkesdr%z};enyvG
zt6pC@Bc|-Nm5Hg3EL&e@c_NkPR{BVN<ooi}rXTExOlm#r>q9e>z1H4Z^1{qFTK}~9
z%<Y8yJAKYK)t=QbSY9Zr_nUM2`M1u#ZJj*svisNp7YZi*+<tqH7X!{VeDKIGr<u>l
zL5|n(h+Utv#qS3t`6$^pPYw_J`OA0O6-<7w&)D2~KIJ<Lrt%yLgDVEhXFo6c<n;mL
zp7^oTkl8bDb!!&;{FPN@y`DL7`K!8b3)X#G@Y=Sh_wO|Qd3MPb-YeocHiPBz_wy6p
z-_>ex*P+|Hx&;{8_1?Mfe57G^^0Cra9=g7;%ZrTTjS+XR9s2s}^D|ETYD~Cx-@e=}
zbLMXQXuD<l!as^%t3Pwy6EZQ_D)o59&vm}f{)g;i#?NEsEVwsp+R%kvR<_y{``g&H
zV}E?+ZGQ&sR;b7O=)y}gFGMX)yLk2wzp-mqCHydI=;mE#wlrHkWZUa6E^E)|-!|1<
z`*+e;h2*w*DS7sym$t5K_G<jGx^D|geAIngFlI)N<u<?G-u3yFl^ZQ-A4Kphror;(
zf*b2+G<^O_X5X*YUVU_p%O^7qKHMSkT=wfhnbCzy@)f?%Lm$LoIlbs?(lMi7m;Dd*
zEjZk?>k`{dOHXcpXzH@#`*z#yKXI9U*+g~x;Q6^N{jXbi9IgAd;P#IbyG_49zmY+I
zgQdf<Nmlng{?gNj`ldF1Ve(Y_Z~f-XYdGzdsjY_`Jv4Ia<N%(1Ro(qo^wNsDZwuai
z_I%X3ZL?Qy*~#;kYC1iAbF*^f%p+U-gnjmDNaFTu4c}Sbs{6j_E}1hPvS@R^^F`j#
zQr#Ua8_@rY)4hkazjwQ==xt-iZMK0|0&k8f_byv7qj=4Bo|AU=lK436;9KyJvg*Pc
zj-@$0`t<&}By#-GmhN@m7W{wf+k!5XZ~DDM^`4^4MQF)3Cy)hI=g#efc4VDmu5!*m
z?f#y6-%tECVSk8tV(EgrW@uNmE!qv`ab@`~pgO1j!{~6<IlqzNEbeb=bBHnoW|SLw
z4EY#&d|c^^E=MU^jmezjf9jlpGGAaeeOs9$&@?}w`{&FXHIMcW*YC))?*D(x5h(Km
z*3ALPJ2@oIx;X%OZht%(59;Os<ee4n1)I+SSbhFK^SS?Ajl82`Mc*FHScYGITTy;_
zLcvwi7ixOHQ|9=S`ThQGZa>q!e*ZL|UpgO1s6MBk%;)z{bNQL(@iWcgXFh+Q`P_Zx
z^Y*zi-<)^doO6`UbxWNE>MT%afjSG+S)k4Wbrz_zK%E8ZEMRVddaT^z8A^4rW$p-m
z{O`_}R@$C#LV;<K`O{2u^!?wOM@^oScVG}pp2;7{fR{YWF0^G`o{1mDw*S*}V~IWf
z9rI(!e0={qb7aZ<cmJ+=vi_&ck!6|-%Y4o&`TbY(Udj6piNLU+avn;-+k!bSARlDz
zDkm~m0_4DTuwnq0Z?P!uP{ufefw2WI@Pjaj2P5RdDKLFQz^WnszzGT%Gq7*OZ*T#3
z@Phot%tOIIuOm1^4DjlSk_2gx3H!l^=iE~v6ZV75&D5P|7-U{1Pw;~XSOH0p3Yl;S
zPJvr9t{bu;7mAoq$v}GY0zYsdZF)jHtN@ueDG^e@x+VTW=1WTjnKP*n{IIjkjZ^?d
z5YKZ&>5vU&;Cvtcz_~SUAp+9j6j(W65AcCR$c9`f00+vQ5s(0hAagSofoYy2na}7t
zSW#BFLk5&UIanJw2b6$mP9t9@jsb_DtP}Qsi10uJICbVXM1Tyc%REHB5C*p0IX-wn
zIe7FSt$=(NM!pAQ0Qrtf2JDAZ?wp_dK@Lzlm}3p$`XK_+APW+PqL2fQjETlW8f1aY
zdy@}^kU~Pe4pw6b11y3J*bl{E;9kEAxQ%5lC6MoxWP0Hj<hvy9<2WxYf<#D$G>~tT
z?1x;)9*;lf%#rVmTnAfkjz?OMvUU(E<!jwiXMs8k)LEd;0(BOsvp}5%>MZb|VF4?G
z5%lkW|35f7GBP^Ke@^@iH+2et|HwH2w7CUjo`A@pIA#}!nkk=3`}fQXFiL+1U*<2C
zh392tnp%0TM!DUG`4C4oRoJCXQ(!v%fB~_gaiQ`4fl(p;v7zyEVx!b|^JzlYwy5vs
z%RB%E_C5#`Ebuf}W&vQXKejugGS}z?i<mgsCUXOf*Ta=ae^eG<kZ?_cdxR_Nufipv
z@ehxP2%Q-i;U5<|droLnaHuwyfm~B9iyA%&hX*^&!y((~k|+`M#Rwa-F=%1Cj%L)&
z1JI|uxPjMapI!Mc&jauk{V{{(?2y*4o;_eYWM=l_lbz3O{H|Z$=7B+ft_lA9mDPja
z+qE=E>n|ECEhjIyXZdyeU5C>1w!P`J<JUm14!5FKK00&2sxOB}4tRPWV<7Y~4VF(k
zG@LQ-_SU)QlYjYm!_LF)-`{xjf3f!_fH7VD|NkXH>=TU&wG3k4#vTMCwjc;%t7t+J
zNeCHPDl`~-s^}n=5~NCn20^N!w4taHjIFgx)e;1uu~pRnbtVaO?$hP@{=d)j`)+gF
zmrv$>&pG$pv)yygJ@?$oYfq2a`O&5HQ+`>uC$RQK7vZi(l~v(;lbrg5uBdk`vE;|w
z*FXI+ZQtB)9=^MH`1jT8mC7Qoxo6bcxy`w_;O?bs?>K(Gr+AmMS8tR#_R$fCb{&TW
zde^BswdD8Q_v<SPch{pwykEapzqP^fb3d6lx6+j0<^v-#+-6Pj?iZfC<ly0YtebC%
z-~ase0>m2qTD#1E;Wzew*E(on`@uocHFtfL6{MT}qFQR($miQKH|}e(m~^H=(Aq6}
z=={<caPif!o_ou74LdY%S@^g9%ldVg?msl`^wRZpbD8(oRk&Ny=xEj0Cv|%Fy|d|S
zk2a2DOHY|Qet>7c$*UHeuiwpn>Uu@#ZOOM<C*#+AvS?w;TMu{4n^0l-#hgN0rYK(X
z*R&nn;=;0)pHmJ#XFNh{H?QTYMz22X?H$(P_^IFH{I9N?-s{z&!{1ju_VNAf##6Rb
zXN^%yc+WI`r>0a{={G7pyT|i}C7%~QKlNPik>BLn))m-zG5FKI-KR`1S)}->cOG`#
zJ-L=^M(_E>s`i}Y?%VWpzJX$y*Ivie$5h-kGQQlpleao;JsVJQ?%=iEUG`l*9eP?<
z!{sVtPHQdi(Y<K9<w3Jv!<FMDM*m!)@TKqeT?zcHgyzVml;&fWo!*>7d1-7Z2T9Mq
z8#peq?d=}-2HoH4K4km!6N$}E?`owB+BWpF!P`!*;2YhHHEHb}F29<UWqjD6d~oZp
zkM~^~XZ$_km--GDuEgvcef+4yqLb9iNZ~H%^T_8Li+p)zNzU59CfnzwpDUBle|GC(
za|gb2sQm(;Ym^n+x&r$qdv}bz{dm%W4aZ7<*XxtrCvM#PnC}!>@?(O>z)#w3D;>A|
z#QYWUTN*iqzo<LAwed%%S(z8Uf4AXiE{Z0u$6CAPzqHmq&-(bvIfpOe9y+ErA6|0p
z%NpI*Z~mg~7Y#E8+MVY+CKh+v)e~QSy`%W}$TCB>UuYCM`&vwyRptiw<M&jL2;1vY
zd$XeSY%ao^-uTL@o1;H)bu%X&w?AH?P?pE_RrUJsno(m_)6&yw+R+)fYKdR&jE$2o
zf4cFP8IwxveyduoD9xm-dkrsNE0?tE+4J@5+kC)#N0#tBYL2|*P}pw#{ZiG|gt#W;
zW`(EquiJe`>!R*=cIB-r5ZG57cg2zo?mxAO8|C<<P&3yON1omIHRfOk=jOwAZHw-4
ztZUQ`#)U2I+K|~T=A><KJW}G<awlF~e|6~d&x4BA^x5_4dyCKixb%^Mu~G4TDy?0%
zTf3yDA;X*o9CUHGUHQS?{yS%#Ic8sY=c^Z;j;~tUpb_8LVJuT?w_wZDuPe@aJTp`0
z?cbwwi`;>m&W>GvV|7HgI&N7>&nmskx1KELaXIDLx|9t&O80#@v`weSizfPozQ6PQ
zkh`9`tnV)+R9RDu{IFcN{=Qwy5#y?Mr5w6--1BbD#MzAphpcX*yX<tVeagDxcGq(^
zwy8fjuF)3OskVf7>$jW=znX395B&SqA82YRf3E!_Po%`vIkc~z`@uy$3UzGrVpY)T
zY=5_(29Fp#=Rg+q^1o{RfmxRLo$r|u(C%_mZKWnJE3}yQw)?VIWA0a3P&IS!<QDD$
z_Q5A8FO27F?QH85*w!f!<zVvouQF`w6xh}&=&`Nt@{|TA2Hbe|BI@SFO2a$8n6#!%
zAFr#;`(;e;-SZ=N-u2;TTWi<$h+ES&g*H2_-`D5f{9m`0+7h*(PfqTd6Yu|6p>d@$
zzfI;Dre3(StyA#9ckg$3r%v?DukG7i>&5+1d!A!!?REtvP3k$LU(m2a)jpj)tm1-i
z+71qA*|1IEgiq4%dp~^pHsAN-*)8|KJBuc-D?V~bod!p4=C*X}TYgQct3Q<Vt+Zl%
zgC?)MzU0~Mc}ssSL)m}pe!ayNA5;tOYFnq^Yy-XzXDO#$_P+C_^DW)(k{MlddUkI)
zd$q&UvprLN>P<IHa447i%E+^Bi@T_R`%i|ya(M8TuWo?TtrZDJW9LrXs7&^bs_Fj2
z<o6O76L?EJTes_T{q60i`gA>U@U+j39Ujeh_G<BRMVlotqkbA#{K@Im=ixjfr%$Q1
z>ssvF9trlXOJ!6DN?&t2ch>P=noK+vYf271`^EesySg~={XI*+?riwN@&j)MRJaql
zv)K6!V;<bpubDDt&cppN$L@C9-Xos*3o{t(qaJB)XWP~(u&q<@_0}Hg!)COtGs~;b
zzRM$wh1Xu&{qy084=P>mH~m1<)!U{rzQ#Ndt=+8jx9%D0E-m@f^O%LtKUz9{Sht+i
zJ+7ngHK{*(W%@Vz8GN6Gc^X=~?Iris9Pe0sZW+Vm#b1wAK6IS@!THwl6(^W}sd=vT
zM8j9~V=ebR@qT;G%$fP%_VK&s!GQ+`*1fX!Y^C1OmkpcETW%=!<$qv|n6k=xc_oi|
z9@?rseyRPX!h0|Obld03dslpXdOp~oHPo*kHE<H&<FOpqwoZX<odQu_GP`^q9_k)3
z_Gy={JN)}yDs*jS`u)j+?`S`s@TAhZ{o59@_OYcr|NVV;GfVqCaZHWc#$~2rAI{uW
z(Yw*KdAB;5PC1rzT(fw;ZJmN|yfyExUGdJC;xh`z9LPGn<WXDa>PtrGU*7+4T?@wl
zEaT%}rAHR|$n~QIj>UGEx?Sn}%k)j#CuG;Qty7@$F0*6!ritILKf1g~obIYenb}|V
z_-c9K?sexUt~FM=T!ruUTFPI>^VPncE4usFy8La=v3+XRTX1isL(vC4?u9PdyejKf
z>FLa6wv2nXdTGDA^`;Yg&(y}Rc6~Ox#g~OY2`jduQ1vZ$`Yn8%<MM*}Z*PnG@qcTb
z0+O)cS*GO~XF?I?8lp7>u~lFiYFVr^mM)(7q@__jFRX-pgw;d-Ge^s_Na3IVE#H&H
zh@n1<f4bmChV*!@sTjGui8a=Z{jprajN+TD|CiPuu&h0BpJ$~olQgicLBPCJo?R&1
zTls(y*1=)W=qY0m3~`VKS>Vk5fgVD^1Y$02258*TApqha4Kl%rd9`j33br)}7_09?
znu2W&0_JP`{Now~nRa{^lV>F67}`h1RtykZg89)?m@_?<`O!3z!O+6U{U`RX)+BJ{
zS-5&#f(+`uSesxb`~GTu0tcR36s%F;$r!it06%Chvp6Q!3%dvFhfT+dZ%nJ#De&Rm
zSFBaA4*qJrf*~|Uam8tuAQk>2YZe5vUcqwPngt}9ZL_6-Ed^{TU`qj83fNM>mIAgE
zu%*DiF9iw{wDtS{QwuRay()9}7++k>pv_V!*u)&}(UleDCHxKr+bi)m<7tJUFxbK0
zts$@$Kb@hgRXFSTdp-PjSTEq&JKSG!9z~!ih=HhLSTSea0V~!MD2^=w`_McgkwL0W
z(1X8M!YUA3AFP<$HVB5oK->(1!BDUXy$igAn(zo7gV^d~>p??k0?j~dudsy)!yby}
zht&<OD}VRM|J{?{#lZ=@iN_!q0y=00^`QZXtvR+Ow1zhM+EDCxh{*pv4C@2K;XN1u
z0kDbiFTgb@*pm3$jeQ+JY(dx%7?c0IBxzR)N<$N93eBM<xI$ZK2koIFi1h6w{>FC3
zc7bl-0X@MJ`aoY0TN!Lw5bt|egi7!ZRE8>06{>+2s>A1mTLXI)TNCR7wV*cCfqKvY
z8iCjxvE^VY=QAB<fq2jSBUk_nAr6+pa##V$gdLAv4GADNYkzMMo)eUZx1j<!gV;pb
z`<=N1;ysN8)$;1;bN&|ZlYGQ)`|{*9{JYn&`0ucWg>C%`#w{5H{{+M)+7D6pMV%Av
zkFW)6T8O$Y>ghkbwuNZ&J%HgHB?U4d8*-rw*M~UB0aq>_9^egr5DH?wi#WIhl^FvI
zg=m-w*P#VtU0q-vWI$cU?tLH>VqhI4!yXXh`lT4-stgUm4GPxF2<2~Q#-qg8R47El
zOc3K#PK>j8LjV{c6%NBW$b=jaiz3Ivb;tpw6vu!_m<c8j>tu*EGScA;WJ4}Em!@q1
zJ&5%(#5x)0Kzs`%2gJu#y<j;cf><l#8MyKwqzib1xSr@C6k;G2QXv~E(?;ka6k=c=
z#6uD|liyz82L=#}Ks%6OuHXS;9gKM(*1yPrEXV~19=tRJSC|L!@C>v(h>3xD5D!U^
zEUtZ&7bl2;!=R%L(t~JYeIOcQAr3OYi9SO^@Pp-$2q~baU782+AlBE2tbv78H~<--
zuSvKt1OmVa@sJFA;4oZ=Y$)YI8h{Jv!3WYI6YOgdCb-n5oPi$1`W%Ph3}iqSIMl%n
zxI!230<msKG{ivyB*9_04nB3+2XWw6kK@55$OQZP#2E|_1F;YX$&d~ikP8kCI40=8
z6SBdpA>lzNM8ix-fD|x87P#t24=_PIB*7lYfM?*)l=J{s@B%+L08Y&~fAE6P=J<ni
zkO|`1@flFKZfM{-I5B6*1>)cUoPoML#~%X0kO?|h!h|zm-v&Q01Y%*iux*JOq=S7s
z@&E!L5>g-&oZL7L=pedd-gBCB*i0y;Cwwq~5h}Y=o<Tf|i3f+yq#gLcGthUzEf^uG
zyJBgyG#<F=L0UpGq(O8~{)RO0?n6F766}G1zN9TAfR`8N59>fTjC~LZ$v)&Elp0Q&
z_;Gv)g)Sor3+6!@<bb_D=O2I#<XpipigE-wU>`&tjHb?wA$-UJk5JMOOkjpwC^eS0
z4kBSD%o|7gz%x(`_ys+fAPvlL2{IuEl<|ZC&fo$%a03tU20sV|pK#JD0t@kw3imX5
z{fXOH(a*4LwiK|X!2jM9u;<j?{WrY-|9<3u-}nCiRqyz>&3~8Pp>SUL$iWnc2XLP2
zuD)7Hg>JI1?+CHRz$k;Sf9Qyah>%ee*<V#Dr=eT+2b)&E4OP4&uf_gEIDHH8Qh!vS
z^0wmO_#?krT)_}FE^u6Agm2_TLm+c$9335Sd&%PV&0ZwF3*zWV9F(<=ufy>TiSQja
zVw`VSxNpd~Q6b|(B8iY#8=yn}`K08Zk30Uv`Lu`2gl*KS&PN2qdH|6j?{lU5e|JtI
zuC0`^oDtV7JMpigbmt_Uu<qEOiEBn)Tt@}^Muri|5iG0_Dcp&4r~C3p+w1id^z6N2
zNy`!8K~ZB#=)C-(YoUm>7yA|(J0gN>w^)0@3+<}Kt<Vf%TtfdcpSY|l*DUVkd=mN1
zE~Ps3Eff$E6cTC4S1rHuju{>nH7>wCBr>A6IJiiIX8CC#)(RAx2Zi7rtR8!VV;E~#
z@{58uDlB~L2-cOzJO9HL*Z=U(>+?6WOMU*LjGaR_a4fOTL_}0*r0>Y6QKJIGl^X2J
zU|)Vbt@ru*6Kj$1RdJJvUG<jmAK@Q9BGNy&AOLg`M)vD4<oyMKi1dDj8xbDsMuZ3Y
zheU*gjkDx~sAzd*+<$~2ByvP386m=SK;M~{XCdQ!1EcdQj;|$wMP7;X(%|N#B~L7A
z%sL>xW5WUhEp^bDeb(z#{8=3oaa&G!Vr;5!q2R#i5dri9^U6pfwkD9Tfg?jkh{Iaq
z9E>G7&<o;~7at?qpOp~<`||Rjpsd+B?x7B37h#?v`wr&ixh4EKe&?l?Z`Wu;xUX0m
zM3kGil{`P<p1LsScdMqQoN(Lf=$P;(e9P}>e&?N2pybz#-)#Jjubt;tl;2p~=AEZp
zKSaUKt21xntiyi-Y-Zm#R$+MaySl}FUL7ciuW+9ZJK6U|oj39I<9B{~SmGz#Th|RS
z9w4?W#8uRdAI15S*BK2}b%Pd6v<>1M{$R7T$s&(U?EIs;A@V-2Z2x23NMPUJ)s4j0
z{^hcdY$?adufve{Ti1<L+~nnzTsP9t|EO*pM*q9IVaCm$)s1uPlk0|~qbQ#zEOm($
zbw-7X;%BM*p4i(KJu-YmNT{e|uj`;FcOLAwE@y4?+cskf5d!0`bW}wC)x>5Ij=qUH
z|G1b%28NHLjQ?FeiaIay@z3&0<mF%Gmna7bxcQ^B7Ww!`X)W^auhLr7ACZ4|ENNu0
zq@2*wUWXUtJ8EpCrA-p~W}WWhe1@Rq)q{ezB(JWCwAH=dXRy@$<qq6~lCF=@hvlWC
zrM>9FZ;@er3;knzA^dpaC!GC0x;OPt<ab^=8eX>#!fgz0ud>gpS)N;QF0TB}3!gah
zx4N#{mqKKlOC7C<or%3qdKg=%@_JNWT@_*c!S=eY8rk_rbu||K&+^{HzQ4+QaUB!o
zBhSBF7m+P>H36F!hP>apt|sC}U4BG9CZqpZeG}!wI^RV(^h5ij`sRWDSM^Qg^&izY
zvCgm9n$ib!#x}%elLv-Y>O7F^+YpPdfB5HhUih&qFU|5h4g4188;s3Mt32I0jYR&c
z(@2z~XmoWwF{0(wyEpYj<g;~piQ~DT<%P*benb$R-zcv1V#qeHd=^|w#5K}^@+ii5
z8TL_<^3LDlPS0<3nHO%OaT~?H_O0{Eyf|KUe&@xD&hn(d@G#%Jx?ONx6aG^17mB;a
zu6h1MzeUIIym*R!VpL>cfbW||oqg)Mqtzg?4JN-TWBXvmbxzktm2ZqeiT2TCas3bf
zyw0x#cKuP^5#{#J>P|BI{;uwbGW=I{C+&3@e_nSE<3?RBL|rhW|54j}4*jp%UXf23
zxcResm&rcsawLu=%DcMWiE!Sup>p{W?M5g36qHd*PgC?qM~t)dVa0v}`}5LoY{<B%
z2;Yd1pmDyTf#ZTAgDvIGi~R-VQ@9W2_n*~qao=Zr9iDaF5;p_fj7ElWfqrvs&P&gH
znZ@Ts{~qs_a^{|YEshl(IW`0B^4r)k*k37QS~pc0`-i*ByfP=!><>0enG@&Z$IfGf
z*SApqjdF-T_m*_<*+klk^L<^HtZqETK9P2LY4eZ$uW0t=^-HCF1x<}5Y~$;&qap%*
z-`qpIt(0<nOq~4o79uV3RtXdx_=4+MUbzYnn}8<jZPVA`goe?_$@AblfrayYM{!GM
zxz6fwljqMrEHrAY<@~JstRCfXz}5$xfgx<=DRIbdZ%OBf;E++=drgcCBqE|N*Jb}7
zY?gEtX`^GOb=&JZazun^^Ta+^?4Py2`q%#QPJ^G8_<LaU%1b~<MC1s|I)Ebn1^48^
z;--eJKIKDP$7^Aqi!|(zAOEnZP!>28_p`oHWSlq$5#}FkukT4k*;ltmA`e8F%C9r8
z@5%kp)c52C<>!y;_@CX=2|sVH7kTlu+!zvmLE8P<eVP_G;`<T>_wpir8t0F%Wag)j
za3e0aqF>vq3HKx&^U^0WJlsDx{IBv>`#N3T<gM?3{3R@3m(9F9^6f0@O<w+JEHzkD
z0fB7?_fz87!se1c8olNCZ^o<gh7BzFlWOtt5C2%=QHDAq_QZFy_@}MP`yHGAyPQ(Q
zv0~oeE}ngwTAnHhZE9DGd!aQK{)OiBMk7Xf+Qu%g-HGaDIlnY)UU|qH8x#3)812ul
zO=kA}-L>i5Yya}K2ia1$Gq8DK$omT#5^-I~#7%x%Y8i9kr=`whzt-Pe#)bQ5=y_p=
z8AMx0m9~^EF`n^9WmS}UF{WXCJrd{cg}=PEQEtCPn<VPUUtRx1Unh$)*@8y>3~n3b
zl><w>{rH{NXaC200^uh(-_I*6Kcc+-m7n;0Kc_q8l^2l?hQIM+&iAvy{f(dKzwuLw
za?WEt<%iCBe#A8<hTng7jS+Q3kb@f!I#Ge0xwhHetDCqnFz3A&6<XB0och^}b{SvK
ztC%=x$H3_uns%7BZ7~I_MknFU_0>nazKQv5)x;4Ew|CEd)jH<Ry2gV?nP+`qj7qE=
zwfquuge>7zFIVNOA6$z*{@}EG8RhfEb^V*PEAz7D*pExruj4Z7;@l02a)bd_tzGb`
zne&w`&FePV9vEA8+NeigUh+FOsrJP{7q9gxy}R6}#=Wu}cUhH+#k#dQ+Ul)dDaGDD
z+GJYHfTQN&kstN%_VM6~&Av|O;<3Af2yf0l{}SI$K5%bh^rHh8lX9G&?0N3FtJ}2+
zN5j1)lsw}u&e=`4i)&QUcz3e%xZD5fbx6hcC~WJC-mEg|UZd5$0`?VhTKIBMm_|{i
zv=-?S(=l+(@*NK&=Qi#2W2d4++7}8~+&rVx%272N^bOeYY#8?i^T`ygU1G))rE+wy
zw&#CO@f>k}%#ec-qYgyOXqdSD&hU&O6H=%+jamtJl~c@<sxLU;HnC+&(`_TV<(6$<
z?@YUsiyqb+TBORz1M>&l)(x$pt#M=PrJ3u?7VkJ`^R>yTTaVn)HvEcv-QFVo;=eh%
zpy<uf6YC$^=H0Z@<(q!H4%U3n#k16*5=TxaDHr_}<x8$otd|iv(Nw(hym5WbrJP79
zbF$Co(^1{aw<^|k^{OjRD+k<r#WVJH!d*;cxvO4HcHU`IYUxiuJS(zxt)t({C8;k{
zB8%vset7=Cah}y%!ke<NZFBwo#m$FqSbgGPV#MKAFILW4HL%vx$sXrcpIZBZ<1Xi>
zLTeW`|9|?rp%b_$Xze0`gQ}#C_j~WYZ~G5kwR*2~ksrTx{aAa<@9Zy6+6}6<`ghy9
zp`Rz))(!ogcFndP=&@lgSvM}uYOjy|`RLn~w@+<&z-cahG)udY=+<OSxmz1cZajY=
z;D++zgHo+4?s>AaZ1Fj*V#D9reZ01!+_ki8BaH+4^*Hp-=t0{a7XPMIHJ39jHhiAG
z@58E&=K5pW8?X0gUORKAw03{*t|B+2TD$ia8Y|zgur2DdW$A-nIZP}z<4o?w!)Ke^
z`Z{t%`fsgP%u<vAmhf`oMt$ZSb-L#`pTfTuI`__`=tn-gy8rs)%{$}k?--QQZ~@P@
z^&-5ptzNVry6=AVg{7Q|r436MkmPo=<*m7<YyZCWK>yiww*RZv18qUSRcrT6=Bva@
zhsKYq`Kzz{=<%^Vq7PTUS@ehXrF3&fFF7AmsHAN@&|jWZx|S3WeB8Dks3<SC^*}o-
z0bOkCf!fvsjj2)Dz4gssK1qB}xwEDX<ES2@e%!fr+wt1a!uKmZnVC4WX|44hWkTEP
z?!Q>ms7LX7j@x1<FjvZQzty$a`iuiPRVpTyF5h`Z$4aYAb^hJ!flgqoL2KvpG^2Ho
zW))VhUe@W#_SJTC&Ya!RSF^i8y^c-x2H#qL!24gnZs?8{;<#nMoim_ek#?g(^q&v#
zd*t!)urb?j7V>Z0Ea72dLiD+p#~2%A#7=8BWYN&l-)tOfsxaoqJwb7vOP)_z5cGM4
zUsj)g5uN_BrFi#Y3-`8KyBp66KdQU#`qm5E9pZZ5cI(ylhPnUUY8x7T?02D9&4c$C
zWNYs%+!Z_M*z!W=-jOD6CFSYK&cSz2fBBAi;O>^a4ovXQ-DDohJ9L(On|mVT`_J0;
ze)n3fj^l%#Hz*T6|IX}Z%|1MS`|OMZ!zv6L$2@L}yC>#FGmX=0tP0Y;=r*M7l3_zX
zip;6ev+ug*gI-3?s%=|e)HL(1qxR7tzx7eyFPXSZSGjMYsRukwA5*T5GDf7e>o@t_
zp4R1lT(;s!`rXvyTT|LK99E&kZ|yI)pI@u$2M2=at9e_-8UB7<`$|1UcpKIjK5IB<
z&G&<6hPwAqW=`wBW5B>F9uJBQs^D6Eo@wiO<|<k4ll>3XOsw;;@VEU6t@!lGS6w!r
znQ?5?J(uXhx7!WhGkVh1a=hzj32*t%`UhXQFI-x=V%Fn*+i!MCY5m+@>up<K)V99p
zHn&DOD{3s9FzWYn!#Xl1deTx}>UCQ<q}-&at#eM534ZBzIP*ohh^`s8H%?fTIHK0U
z-2?XX{MJ&Qch=bMxi``M(}<8czs_5A*X#Wom9m}v9o#>y^UdCc_QhylLM-<^`-Tp^
z>t8?l(c}h4+XY7)s~fTR>?l)+e%0b}&lg|Xw$Fj~kB2E*yQY`MzuK@WszXf6FPeP5
zfAq4EQ~UierN`xyKPV-=c7MJNcR#uccgo?&UDG~wX?*?e{;H#Ij}G~1lWl!bkuJ9N
zMQc19nYQh8jpuRSF7?{V_+O#&B3<T8TDQ7djcL8l`uB+*uIsNk{e4o2a*>$>8(x1h
zXJe%UN4X#DCEP{795#MkLVA2<$M?oOn!dAb)g9|ST04K*{geG;+iq?0i0kxcmU4e%
zOvHnv?VENC9a(i*V&&;yT^;{;@RkGfHg9e7d&bHL(?La<VCf%ZC-zUWtwZ|u*WssY
z%v{+sB8=xL^eMG=4twM4`P_bW;fV9Va%*=urx@xaS09|RNaL=1aJc#l@ogr>@_gp+
z*C8$6PlWe8?9-09?{7#<89T7L-R2Uh?pyDjwriidJfg#+;c>cWt^f7wmA>jKj$8ET
z7j3=XD*Ez#h0#i4hhe)Kuls4X+sje@10!43Iq}K8Lp;yyCft2m^4o4fJ2qW#EiuM;
zbymkUdoQ^iT6koz>&kXPLmyVWK^gsL*FXKp65fWNm64sbi5cZwDQh1ctubw19k&g~
zhiyBx?D?FR-%LzkE|sS^?nBS9@v%1}b3I3B+?pLUcz;!Hd(wu5_v??$e6N#ln+?2U
zy4vEdW3?&we>-JZG^fYm74@}o>EHbtTW{OBeaoI4kDPJmR9)P(usm10J@Z=8X)oK~
za{IYw@~Ws+!}@Nud-~((Xun2llNPnu-aChN40yJtwQKk5QSTX@yU*R*?pB@Q8JV6t
ze;(0woo-;9+mNQ$c5E6wn>8RT^|ITpK`oy?jC?t^P17;qYr2*Bs&Mk&QeX5^D!x2i
z+^gxn4_M2AqQL1Cyboe|z8FkjnZqb?AU2#C#k&?$u{>5)reQl`r(@~fig&S%;#uY_
zEL}E*!yCCYDY4in?1xxxVHAc3joYyEu&LPj*xlF#*q^Z`Y$kRg_70Zg8y{eoVnsZ;
zG!?w(p>R8-h<Ms#8-mzAVYi6qDy)d-8Z5~w&d=h1Ie+KBdtrGe!>fqpRc8?&%T~0I
zVszrK;#jgyDT(FrhEf{a8(S7D&aWJHIMxXpfUSV#oE7Hd8`oniVUw^`u{*Ifus5+a
zvEuw{V{xO@!-{u8n2TbGUuIz<nm<Qgye}c*_b%?m`|4uz#~qh(B?wy!8-mqgL$O`4
z5!hCQ_dd28b^;c+%0#RgI}7_0HWn+s{rMsGF?K$-EXP=Yt%NmUJ7MFn1F=i6e%NK$
z5bR3qH0&zu8f*gg5cV_dDeO9I7WQ*&2|L;bY#r<-Y;)`v*p}F>SP$$rY)@<oHW-_V
zU5?#_U5jOUlW`OF8*CDGAJ&XLh<%9t0s8`b6kCh}k&YE}v5#XrU^#c=80<-GH1-sB
zI`#}!tZ&J@d*f~_X=6N&J%_!BJ&(PMy@1WeUdFz}Ud1*bZ+^zQVy|JlVsBu5vA3|1
z*i7vE*t^*2*n8NIu@A6Yu-VvT?625;Sn|U79riiajD3my8Eapd<6?_q-zmzNIJOG5
z1hyWw6t)#sgBA149I=bA<*+NTPS{jzdF*biGxi*|BK8KhGWHR+3idZ_HEfY$yz78%
zjje(0gLT0MVryfUVe4SGVC!KIVjEzeVwsm~EJOKif^Cj%hV6iDffeunw8V<~JOuLJ
zb+EhxA<8?u6;BY`HL8Os@0nO%>_e<5&$-xfSRTh2XJB7pDa+!05u<pA!VYU`FZeru
zF1}@sz6jria2leEEgF9!{3%!s+H`DX>@4g6>})J`!qRS0<}K}2B386llu2a~_Is>o
zr$oJ4f)(%Et-yA}uEhR;O%VIB>#)CI*JJNuH(;M(zrboJzgw}@vB}uF*zMS6*d5rm
zSlSX}cWf%Q50<vmXuy7rosRtm`!O~RyA-=0E8ao-4toT92>Ss01NJ#K9b1(0d>mUH
zdkQP+&1tMiKR?Ky-)@=rF49l5uc8eU+hX#uB9=8ZjP<cgutC_>*v6#C25d|0Mr=>)
zCaf2BGgi!>-+~p#$$<Ph+?KiB;y5DQGa$BJxO2vOVryf)uuKP0`eViQWdL>#)*H(;
zKpBSp4Er8-Gu9VNS}6Y5W7r@pWk(6dzC}D}(~OO<W3Zw<4#jrChGB<eBe22PDC~6X
z``8`WNm$w>B?kK&)`)$J{G@F(*2m7mQWuojSaF_*A%D)ZWiGTh&$rR`fY^@Ut}^y0
zwh`8h9gRJYosYeUU54d)V5F=lSFrc7*RV}FK4r`3ioJpDjlGE-guRWOfX%{A!#=>$
zrYpZ<uVZttH?dE#v`xxySaCggiKQ)3USY*`p|Bn04r`AU=fm~7V1BJ--mN&FvS>3w
zY_24UIKK{9k#BlzV{9iZ`;;zN{#LqS2VuKo-@|%fM`3$nBe3i<PR0(#ihLc4{Ta)(
z(a1GW!H;namNvo?FA;YBd{oOkRS_?W_3M6u7I&gNxnQediJP$pwk}qjS1jbu2er%-
z75>Yh#emo-E0%Jv!`9??Gc0jcT44KOTVX|ihrBQvv2C%Ue7a#j#dgF}=ao*_Ygo#f
zF$>Ez+gOwH=z*<;rOsI5Bd+oJ^Dh-Gf2UQTjl&Xu%T|c|Da~Jnv7$Y*!;14rh5UJw
zmU)!oJe<%(-$ZOx$w%S78dmhPxbHW9$8l+cjLXR98rU%$$OW5-t&iP>ZHN`^Nh9n@
zY!j>l3G9k>!?wZp#?odPhhW=dKf!jw+7pMa*f4Al><?H^Z1JMZhZ8!sANCpg|G9PZ
z$phPZ`CLzEFl_7PQ|D<^o`ExCCwd5gSXc*XkOfY3mRi6Nh=Fx*7_vaqo9hjDK`6|F
zBsdHiVBd!}4{Yn@Ge6vi_7eX8u9qKAhyI^gGrwTHeEaDfi#9HX8`bOB%**7-ee#6%
z@4wT!`TvnM^WA1~P9-R>T<mmUX3hK@aLz8Gv;Z#%1rsEJ8M46XVG%_KUJwkn&6WbT
z6tJa$Ed^{TU`qj83fNM>mIAgE_`jC|3_(fj|BGi<sf>O7){J`#5bvNCZ2zjY|3!Fz
zwf=uL1BMU9pke-I`yPPpdjPiY0q`87%0GS&;05(lyu06|YTo<s;{A8=KDl@YU0Cr>
zxOn$F9XH~=XR#H0CqS$%c@D%{mDTZo3VRyPz*!J$O^WRT_9BS&CB-_BHE>(-`ysy{
zfmjEm0lIxTo-aZUzs0&4;@H1nuY*{V&?VomST{k$@g`QRQ&S85I99BwBDPGdSldKw
z_po9esJghR58Zfx(;ZS7Xb)<fw{}8f^bp!Dan54xhi4$xoM?nD;wp}J1jM>QcR{Qn
zR)>8Luws3qdi*^T{~7%KGt{*5_k`bK{SC3c`E1;L$FYkt_d~;PNBBTIfZ=yxctD&w
z5QkUT91!1>*acz^*GYaC#=RYX|4;ZvLs{Z0z7b!rJ*8~@1_fI=(%~%-n^-HpeE#3!
zxBB}G-__#TC=_gt8vKITDshZ=td3KSzqR?l%X7R6R>y44-!1chSHQn>ei*IM+T`n9
zu^#z<_rZ$w^2O$j9hm?3P^?e>-y^Ys`F|HCJp24Gg`cVDGxPTqLwCsE7m7A6Ul;Bo
z`FleC?~=GFo$u}=w0Zfu32XhmhNG0Jf7Le|N)ZR~yv+@aum{q?iR*a)902j$oOuai
zj)9^BH}HS}NCKW+DsDV$67xm8AqDJtrlbQs#KI+TVfb(e1Vc0=fcOrB`2IpNq(M5I
zgX>V22imUS0Ye}dq9GPo+D(auScroJNCsVLo>zl-=r#||fOyA1d|$!740R7GLn?>|
zq8g|S9$<n5NP<*21DTKwrN|diW?F#w{(=uggZN%X4v0xvVwDu}4TexifdgO$r*fnV
z_<;c`lb@mt#lmt}2WOxZW!DvaAQqN``1XcquMUG)XCoA1U>=C|FkE;@=nVm2fJDfG
zTyUUXIfDy`bt%Mmd=eoQ#J6JHU^yg0DjbG%+8Hf<C><<^>)@#+P7n;y5C`iZ8FE2a
zo$w(BQs4lX!KVgcL%}y2OtshtXCMP|L40Q+7$QMDh>nL;NQZN99h5qx4b+7epa&li
z-(AQA`?|y#GC*ICdJ8@f4c8$Xa>1cKX#slh20sV|>u)dY;rC&<4oU;UfH+8on1&n=
zo`HQMjtOEiz&uzE>mV7@Aro@JxiQBCJ$OPelxo6pAqHY04iaDwm>~-sbi}ba=>g&!
z45=W#!SD>6TM#DbzzsaW8~h*?#P_xezR^&(C1nb_fEW0I5$3^iSO*yp(26{OXJFr&
zvJ6`20$$();(HD=ArAJyVK@WVAqT{yf>PiHo)7>Ah=Ev0g~N~m&TR-AydehC;S$)l
zrEEe&=mG%{3Ckf7QbBwt;yPqQE;zL#JwOkhFa&0T2~y!OWI-u6>K^F92Mi!4tHeVh
zq(C}cf*f#aPa1$Lc)$>dg;dCdTqxCn@W31VzyRyu0GxqmAigc01O?x#u<yjVfdRxM
z3paQ24VFV9#B|0z?16?|@DHJo2HBu=#UC7oa}e5%bATks25ooB253Eq7X&~&q(d&0
z>Onezm{^end%(UoejorMVL7BjE|ls+y!w)FkPUUcC<AZ~GGS&v+(Ist>Q8z>0L+7U
zI6RPaAH=yp@L<Y1q{AhM8^Ygk2@F0Q7Y@TY5ED6*U=M`8N8N%n@C;!em>_*LWoZm?
zf-d8zuMi7<2Eu|w5Z}1aj3+%HGaMVixx&0i$`NRy&>$z8yqHM%;4q1EfJjJ!EO7pS
z<G>IwK>{Skkam+PD^Pg~e!&Nl;1XoPGq9h^aiB8Pg%+R(PZ$CLV1O8ig*cdL<oMID
zZ~!u(j$>ZGSA6eH^uH_cTl9||u%eIM2`l=cwXve_TLmln$?dVCzuFcn`mklNqVL@e
zEBdI-v6g->R;(!|zULwC5B_YkXUBX0hV}oOHw%vp8#~hS5rDRen`0qA+C)~nuB2Qy
zIJ~yKL;S<TBEm*RYU}o|r|ruMSYtybu{N-_GmBn^ga(Ey<rEi3U*GrreMdyHyxB+=
z!i-=(my2U?V5lK5+*+kijy@tXlw$}#V$FS4r;7|^ozHP2f&%l_aTjhPA_MZn6>i3k
zELh#{U-eypZu#rHG55`~Eyp_Z*COl@+I0Q2Qc5B5T>$IDw{6Ss{8aOeiX7#dxBeT+
z_D5U(x@*?!9!79Zd26FmoW&Z7%|*5g&4?A(64p$ow&ZECSoIoW98#$XeG6IEXf9Y{
z(6SDg4qa>67aBMsz_JV7&e59_5&g$r?0YiZa$c|3NX-i?L@8KTt6=>*2Rj_I4S{kn
z0Mdz{kq>VXTtO;W)}4!H-ydwR&)>+-ymcS*&R?9D`ut63>hl-p<6Om(CX@#5%P2iL
zSo1so`uYF=*VYj`%XLO;H$I@k(hIvZ9fMLPpR99!<>l6`%8nTM+dTghi|2IM{l(Og
zT#Ma=JKK6=10yorW=-+#7oNQ2;Ng0d-%cW3R*u^{^{X9CZrvH<b}KBV_Pw}K(<{4-
zcro5EY5%pj&|+LyOVEeV+Vx*`eEfl>KYgI-HET|2;JF|F`>Z$CjLNOG%M2KPWB+%p
zgBG?Q928x1*H>9Vy4f$PrM8WHzAba(z7~tQ7IKZ!+AVtM{L&b3@zt=Nd&_nWJ2Y=u
z__zMc`gNG@KQ!(1()D$7c~^u!lGbiXqoY-0pVaBy_s*uTJ=!>qEj?xK_yL~%Ca+p>
zzJ53Rsp}P`w<TR_os3`e$)bfVZ#~>GZ$gFT7jp`2nWA{jU(<GQiwnzIe!i2jnf4;Q
zc`a8pdi7y%@30QXPyHU}e|6pTUat-v{=Vw5kMCzUp0cGnbCE6KJ=6G|no?z@->CHL
z9?u(=d|vqc)N{Q@ev=zxS7Vj`jlJJ7hGr?x-G5zHzntSQ>yw&o`*=&G>AjQZT$+4v
z<jMZG)4y0*Z|at8`azcP8aJ-fZ`kkMTv|T1txHzJ<!WulD%*+tc+qytgJ!*kE5}QW
z{<%WoOW*Cg68KvQ&5=zh&BrV|y*Y>S(%4cClAe7xa9m{D+db|Ly1&(Z$oA<c5}Tdg
z)k+t%ZRlr%x1C(UJ5C)$cn+6e&B`)9Y*0S9_1DMyE{!w(p72Y3hYMF?_KiM%)M3#{
z%0Z-X_wBVJ-#?mFJ}D&X*2RuT+-tiu`tacOv#sn3-H%Mzxi;ui+qz``Q`aRM+g#+Y
zN6nF!917cwzhA1_nh@87+^q1l{&l<WXkFC(&aRhXV!g4Z+!JZ-T>D3!NQtX+XkS0~
zgNu3;>e%MRs-V-^{%$`F9x-^%fvk@iE3~*<v1Eh$Pi^8xIX)@W%(cXkXE%P0IoQFu
z`S4xaqI(?c8nuIQXiGWGow0H9<xe;MGGkJS-EUQ^6{VS!b+6&&Yvq!5J$t@>eH%I}
zwsp>I>zutXbHC{>%3rV2?e@9e`C|SLm-XLnEB^TRbw^Jf*}CY*ww_N)EV%TdOk2jv
z=__mPj#io*_*ti=CY{TP)a0g(?mhXYrN&1y%{BLlA>5;7_s6^&V=1TSdu9Z*yWCV;
zsmaR<EvCKgzU<YQ`&AZH&D=Y=g?oT~@Cn{c5MvE?JGYbz7<|>^Rr7i8&l&Ns*{$$r
zEtlS^SSa~S{m@-bD+hY=ZjKm>u#1`In$n^09G8rjPVKJ6>#qzO<n>v`vxq^X>QA`1
z**S=7eoIUIs%~8SOZ~7%%QsK7A5rRiP2D3Kw}rP^F*tr>iE^disg#AguPxzy)Oyk3
zk>#JZ>ioN7@5D1xKRp?h_0y>?JkM$H(c+muwdu%MgC%}WX95$S6n@mk(|h2PspXap
z%I!a__U3rqC#RpB?|kHiS25NJv9$LyjWeAtJeu~tZ&lwpADm8_Q231VjQMNUMi!}h
z@bl=Ev-a{%izR-W##Pdm-+!QE_Sjb!K7Q-7BI_OEKK>zT(X`#Q#?+ctuk#w-{jwbQ
zM5n;qw9fMfHV$nx!+!ObB`X<oj!yaDu;Jp|dbgKlZM@4E1>;>>yZd3yosa&wDtT?m
z7x(<Ki<KU?a$DCjUBCHx;_eNmn^jtlCtWxft=&g2D@CX4cAj>NwXI(k80?+GGdxSb
z$+mu(ZT&J)KWyul{ZCuJ?0id+ZyCz|TlecNuK1u@aMwd4jz8}^&FMns*@SNz)?X7k
z;&x}QZ%KOLZr(nptWSpBojbg5**>G{HJkm}tWkz%Yi7m9H<|XyGrQyQj8|I1v#mEa
zcj886vUgNX_a7#|m%y07TMW=??fP7Qd;6(AT~8c5?Q>&?NAsP%TD)A*W=YJbp9U6x
zays>SIOFA(_OxrUZ+j%zw=R`YAt-&#>D*bze`zxDSga{I^z0Y&i|p#+z?_jDBD}NV
z3(F6@8BpO)<j!K}H;j33Q@>`)m^lyk#~i!cZF`S+Cq<dTvm~wEXwB_xuVEjKZ8>)N
z*r3XbS58g#)0VsL-?Z=3Z_Up2XIEo9&l29@ODkNK?b%Y|Kfm7CKf5l9ZC$cSuiS@q
z`k>yd@~grh^;**F+K1bHb9mlh$&dXv76#oIH#y<vg(p6}mduX6+O5;-FV25jW=_ZT
zpM5;78s%lZ#a*>8*Ub(%P;p`0_?U%jXO&qRd8BQn8SO8GwanT0YLu=S&ps+!`d3%3
zO|4UI*R6&d=IT9KL=3PyIp$*Z!<*V(PTFwsNR3fl>+uZ5S(F#sx@5L>$wWCAo^io+
z#OPBmwRS7>zS8xlXjV-<xuN#ZX-9W%c1%5fn{l6ht%bY!@4w}nQ%Ha4$DYMcM*LhS
z?7^<ljdm4l_wM$vTBW)-fBp&mMDBgGc81N4wUu_>k#4CcSLtrf-+3vw*VS)p+Bvms
zwQbbR-PIT$T5RdxAL=vzd03IDSN7OP?tS0qe%qfX|I)KTwI5C{8yZpl(aG!Fd(@~b
z!h2RDvi8~{kFPd+FRMmGmxRU5b%WM?JIOEN%MJIm$zKiJn)fW7am+5?hljdHjD6ar
z>kj{ZmkM25nSOur;5*unCp@XNZvVE0gl9RA1zVneU2)dqnVC9o{~n!N<PO|)cI@&S
zt0TJAamz}2R_R^dWw*5B6UWr3ZCqw5_TkK36}=lxn|G^|>6Bwh$2E)hZ}={@!SEYA
z7qPf=KGNU*?ZFFY>}eHWV!^<nP8WTmCKMaCcxZ)=hxT+GI?ylgxxCiyQO3fVl{@_2
z#Chs1yM)Ih({FkonSOI#i&o2%#~qrwGJ$)P2bS@*Dz}eS`*qv(;~QfFeJ3aRRR}qm
zIl1!U9sM4T?bt7?d`Kqala_Q&?r;BOTJI_!#B8XSQl--(^Ysbpb;)e&jWuf7{BG9R
zK8N0Nb6z_6qj|qiZ<=FbO#$wewRX3Be6G6a4VRDaKD?;(ne?UKwJ%fs<%`2E-O^h3
z@VY&74$t4J3U}Q+J-WIN%BU2uV8Sn_A5ZvU{a$6jzDfVi^~N?>%2mem)xMo8y8G9<
z{B6&%eQMTQaBrnU(FZ;5g)Z5=D(hD1>CC~ljE}c^X}`PmrW1P4)W)xNeKxzrmxVtG
zE4HFg^(}Y$Eqt8g@`CvmZ;SIN|NhIAGTUoieca;1i%rfp?)3fFE)Q>3zrN9@;nbet
zZ^zNE`>$Hh>k-fO^o3qOcU8pmSYC-$YN4~9gk|FtEbCQNz-mz{Vd-)y?_kBVO|r_^
zAFIVug_Y`9hVGOa*jZSbF(X-TS>J+FRk#cqKgTw~G8CvZ#qPm2!|uZ}BxyW^rKvKW
z#?o{cZ(*sX#zKV@g{o>Sfpx={#gY|9M=Y0MBWqqMov?MWow4rNuGn7KZdkGY3(cFc
zKei_}6ibmb?!@-Pigk1bU~{nE*jLzrSk}0(totz>%Q+fZdqwfVis#nDu_7HQIt9;Z
zEzfU7I@+T#mCCY}Wp_FLa>SBm;`y$TWAVgaF^YGw|2MBUQTIOS2`M8<r*r%b^T0fT
zz8HEU%p@&r>rXH*hJtKce}cI{R8ZUc6SOm;!GRPw2g)$oMi>GHh=+8@0S%3k8+bzo
zZ5L~@DP15E68bZK0Ezr9<}<Udj^YO~xc$$rKk?73Jz=Jf7py-a+PnW3>rSN1piSX^
zz9G25nOUSKHV)Q-n2#;yVcX9p{jgfB4x+D+zBEYxk@Y96*Pe)F9f?%iS`rji+h$7v
zTMF1xz?K5G6tJa$Ed~DPqySxH>HYs@^rydPP-3w&Yl1_;Cgx8c1u;+iB{%jjE3-B*
z6l`K`fLG#o72b7)!e9sAXn3yyK4qWy9=aJ$!dVd8U#$aRd+*=&-oNd=|9^b%{{{8$
z2kN1Cmn4_J?>q4h5Zr;gP>#B#DWCVAx_HOF;63%SXr-Y9i1*jaKq>g&`0lz`2jE}%
z{<`gb^?%*F>N<*CD8$2IV2D(?4$r`W>yH);U<M~Kh6AAx4Ku+6@sJ7%V>@~<K|F{x
zlpPq57HcAl@tS0?XB@^8j9`KUI1FNZCIhlSSCnwT3;aO5Q)C1ah%pr-m>?b!Ar)Lp
z5GRO*IJg8^kPD?s@_rGxKpHrd;y1W}7c7TFNP#rC1ljNmoJx}h;07KL0OCFP6vzdK
zGK2*#5D9xA9nOJx2i^yQAsSq03j)9d2_W8czXVRy4?P5c2@)U~(m=fH?#6(<SkpkP
zeGmuY-S&p`2YetDq9GY_z`i1F3}~Stc!3WjLmE`B#P}Q}Kr*C(8P2@J^Ah?6u8;s(
z;7y+)01RM+ct`^AUb{VQohx|3OxOeBJ@<1E!2FYBNP~1(UIPo4AQS9s;sy*51F^6U
z(%=kaKo&T-kT#$LH}HS}FhVwzszsb36Fh2D&L9B9JMUTW4D9QW9?%dxK)mA~43S`h
zcu0i<V1_Jks7n|S52-Md2T0<5ccnhZgt}1hetQCcCqXKlfo!mEK>9;N@BnWxfKx+`
z3p2q4@sJ1y;2h+DrV(+}ksgo&>2Mu#K+}{m1g_u-eqew&NPr~R1L=?pnr6fSy1)>K
zgmoa+lo4yXh;>;SHmB@?C-{H~k|7PQgGUSU4-UW?$Zkn~FbBy8LZL1X%Z5O~JM6)(
zxQ9d#@1uLb5J&>?E_xP(w&mR50EqX>V_`X5f`a$SOSLCn;04z2hd<-DYX`!B<&X#|
zklTs4xDziB?|qx#0OWvuXVRw&X$+a5?aH$tFhd5!bi*y=fPHt)uP5gNabWI6dGKWX
z8@fQQ_`5fMgLqe4JjBz19x}nHKY0Xaz<B_1f|TLxgJ;mfm$C&WNE*rUAsY?{5LO_0
z23;T;V!<m23(FxVn0yLhAH;&sSn?B6z%Y({hfClTMwtU6m>><FfrEkY$CEw~12e<%
z3kSd{g5!cW_(3Q{!%Q$iJS0L2q(M5IgX@qD8Ihz_6c)7aQ(xh(Ca+&4)@c#<Dz?p*
z0=5+R^AxaWSGoN6|Lbc#L&l8>4A*i!Y0NwO#n@+l?X?WI_Nmk~`JH{w9(`!7#P?`e
znZSQSfYQ0GPiLRbp(DlxDS<R7{PYSB3kn}GR@;pi`XjV;qg`9o^LZ1<ppb~D5uw@v
zkx>C5VLr`tP22c%9TyoGZU_&F2=p1$*~dF9EHuKW_W=HE+M;o@HjSI>nl^9lGcshH
zk4IQUWOS<*K7vr9-dG&b5HQjz5<dPSD*mC34S|jQ4Ti@4VF7{fhXhV&ES&j|4Pfz?
zu&Btkf98q+wKW=rhKw|fhzxG~Z#x+dAWni8LI3^7VuggUqx?y)fA)}rL&gP!O^DF;
z3W<#HX{z(_#Aj1oV_oBBy5=oh8|!?cSjXU>jQ-z;HTLg9^6~T>)Y}q$OQ!iWZBA5l
z7GXkOOlxQxjSCA63kuUV3J4q-#Z^p{@rI6yQiT7wwme~sivJ3<5<+{cgrt>4GxR7b
zX->kOyPc#}MDx2V)-8AwURAWTz#@`H*OCjH93I^~#V|qE8lh$Pki%<+W`3ub6dv6l
zC3&H}q`9H#B4v#(ilW`<Ai1N<!J1F<d5B8vH%v|gFX7H8$7LXzmqw1uyJ!iCrKMxg
z)lkw}%YH?7Bg0ryaz~d!NxLMc72OF23q^{)NmDNOig|(THyX{)MLxI5XqsSIn~s*&
zrnnT|95lmQ@_Ecd(-)PGu@Ei0vwUt#(X@Qf$2xv1g*%gcj07~ZoqTTVg<n3>W9@g7
z@cW)z4z{8tH<Yy$p?z0a^1BPo%m>u0!}|u!*hJR8L(}e%{T@a$@!=qAzsJzLipXW?
z6k0Y3VeRfGw1m5II$uJ|I3$PnGn#I<?Dr;`ewUo~cZJ^^*<Ci8*Bm(w9;5j!me1oi
z5#G0QzP&;-d?ai3j3;Q)WxvJIjOlVYErXW4Kt4C|4Kt0i9A{@VzqWFoR}t>Y$j7LG
zrn@hvX&p5EW?2*8%*%c#YfaJ8Zpm@s+gFO;r*c}gLo=z4t4A~UlIwI=p{ep$d^gU^
zTRui#G|g2x?ZsLzx*~FTLxtaWWq0qPDOKgP_eV3;m5(95_hxP>Yh%$e7&x&mYvE|d
z-tuw9x7M^@%V`iJ+%=ZdUVMwqD^fnjY&3Ja?Dr$IY(AK2eOwcoezB~HZ@Ojh@kVQR
zE6}v3<?z;^>AsVXyADm+FZ<mn+})GUZ3|lVWjRg7xA4q-D9-x0sc0ESxx9#PCK@Zq
zZO(q-E?$nG_@<)iTiI{Aa92t`-;-#XTXOyQ5iPrdT<$NT8IH)u$UyTeDZ9IYmaIzC
zJ0iR^`FtOs8CC6pn6GM3r77R>R17p^*6H#)nubQpTH||dw12WD*2BzRD{H0EyspaW
zQcn1_tl9MDdQ<_;G)~Un%0l~H_FEk-TU8foqiI&i*OUfm<|q;4H^&fbbSB)8)1L2o
zvi6^xrft!(f06UNBbx59TwcT+Ij?K-`Sw85{3z#nAEC{Z%j5vzH$gtPA!upiWlhW-
zHb=^NIZ|kM<T&$vNF{Bz96vF}t8|x-J049tUv|g0A<0WQ{XRg`43hmCg*HOYBfb~O
z`O0Z97cHZZ+~$0YmUc`&ZXBA{Bp>4wG=q<PzN^uc`m*28(8LEst@BsRQ8Z7H<F^?t
zd%T=h+tIW)<#hfE&15HQdxW+}zDDgsGu)Ql9YQl7k=^k<OeLe7d~RkmeM>o=&!QQl
zWWN{Cv@}rG=XO<u*HKQ>>uAY*4A<J-Z8Q@*thM`SMh5h)wO`S^X3E+#w6ykeTD?Tm
z#meCow&Oe=$nJ`v8Ai%!Pt&I)kCWr)h~{@jKJME>`$7)y9klG}vR^G)Mx0#MYN44<
zi8Fgs&-vz~k~UaQE57%r7_Q0TwLmj&lr_Essbs6#_71|`dvbW4(R9OQzha$V-S2Xq
z_eM(_E9ZHCwB+4#o)1RTd&q5*51P50e2fujnuBs0j6zHJO+K#p2By+gKCbxguKB*4
z&QWN7hve`kq3N?_cT>^Qp33P=@lgyLWp^K<=^Ds!ULdr0<+8ygOEJxm<0rnKtwhRc
zunNs<l^ot$;f{w!)_J}GEt`*nT5CyYI@LYmHZ=1l`8;-_CHIie<7>2x_vN^xp=G<v
z?hc|Us{W+-&S(Y?w5;QD0?ovN&DI*#fVH&cIG;x|ye-$aD`?r%<ns3mn!bYUHxn&+
zwwzY?&~$6%xI98jxGG=Yo}!t(<YVNbrEQkWMj-~cGLq%^iSIFMw#sQ$63u*5j*AA(
z)LPccqooazwMuAy9pv&{4J{)`&Nmm~cY<7o>Y<JMT-F++naj(^XpWYws=uyix{b2m
z_QLN}*{?fV#vM6Ly9>W9<TUU^GpNQ7`k{HXkkfAvnzpo@m&4HXOhC6TFMcAtFJ&!I
zxXY6BXtW4VHHH#~mRwf$OVkwe@A7dcqA8!r;Y~sF<AJSpTxOtYd&y}Pi<X@u=i7X=
zw4!oZTZCrnBKuv2rfV*zUp!huS2?XdMKf=dufLxQchlvv@dcVj)!vI|*ZPj~`F<(F
zJ0pj;Te!O-pD$f|MMooOodyTcjH<fu16o2~+3#^QKh-tmv~br<c6Sa<(@Jh5E~6QD
z%4u*7O?h8VzguWtwdL@#(30)sI?e5{lD1V2?+Kb;Cpq6<pqVbo;VBIEnZsqR2%1rK
ztt}zksm2A$qG?rm?u4fCmFreTG%wY?P*pUYyX>weT1K`Um%3=$A#yorB>bxS7R`jl
zhsmw;vNf7XD<8uR%}bSUozVQY$$q<`CES+d(hE(a>YI6?8G6h4I}pvZR4#w-3co+g
zb;cJhJ6m=afR>=T*9bw=(%H5?w{d8u>2m%?2zLwQ^A+D7&~K6bPDV>p^`EDs`K8F`
zF-N#NBexs#&`iVRV=P3|sP1Q$qM5&zkGm4hOLae;fTn*ar}KKW?ECU@H=!A5w5-!$
zE1F-fTsBhBlH1GavP)>Ga(LgMrK!s9cOtwv`P{@D81rp8U5=q8gv;6~G=r+I@)Mfz
zshsBw<0^)G@_A4!6tk)wzlo;T$ZgYIG))^he&XHIj0tjF9-}39lhgh;;nz;?pT0s%
zm?*b7;=8|I-^giNTxcK2$1Q`FTtbfDTf*I!@^PKf3?6cORRv8^)zunkrm^xd>Y!;<
zeJO@}6=Ny+7)^z{sd5==CBnNShu01*TQ#PoM@u*@pGQ~W?z-%^Cz?*x&+aSSsp9M{
z+^v`Mcc{>g%4y0_w&JC_uk}YWsm8B@(G(B4Jab4z$BnFYT?j|ZzAj&Dd2FI+#>jqS
z(ERM>{FsL3rFzCfms8OXmHmE%rd=SH7cuuM!A?%AC1`2Ma+zEq!c&b~tPy_O$my~U
zO{p&DCAV`*8j-X<-z{jSN^*JLfo6PL_M0lSh4T6CMbl50wf$%rs%IkKqbb|u^GFx&
z=E}!7iRM*8&W|6_Oo|-8i)el-zZqy6)z}=D7{%B@PG^d;;x$Q5s|Uib>N=Q%mYpKU
z<vE(NPS$=$OP(x;NAsX)o#pd&Kr^YXAEnV0)wpswwB#M~`Bp&Fb&%^;Wi-tt`54vF
zvcHr4))s!fWxoy3yj0gl9hz1(-q{k({IwijTM?e>{=B1b7bcghE@%mT<oNXvn(7%w
zAK_OuW;6gTO?6K<1WiZh-MZ`!N7FEfYORe#GkC~a5L&{!avcmsOZJuHHy$l5Q!X#>
zqnT7=haZUWZpv+h5l#Q8e2iIW+V*l>=AtF@@WndLAEW7_<n)UZnrb}u6QQa6u1539
zl*9WBP5+5}olZnEj+X1&W;D%SIe)hccS&*@e1+zvY9|@`Q#7jn-#)YiJ2_nriSShI
z=}|O4)i|pe&GbZ0zq4o>Rk^x==9MXzgR5vd4sM;M*U_{K<g~wymaS@E?h8%TXZRJ(
zsOrBwL(`X$`yelcMkn9;xP=`!kA?Dai=k;f<+Lw_mM~h*H%H+&K|VK{Va5t%zwe-F
z%F6Ao7R^s}U8seYO-Iu@e)UCo3^ZD6P0)-CkXUOiggY)a)><31<Y>8UbP$><O*;#X
z2ddV7J<v?5H0_O+P+rdS{%Fb;`51%IjL&6v;+=D4u{gq;u}y~G74taR?<ll1)&2e$
zG_Skzx$&V8#qdBrMiiR%xO^Uy(3I)2U%E_+7Zb6q<1!P?cvfy-K19>G%IVCbU*=cJ
z`MVe`L3MpwZqej&wF)g;k;?(YS&BhbFE^m+r^&}n657x5akrsqv*q*HiKbIM*Zo@f
zRrTA&d;i(Y;<8SIgJ@ol<TxKe^YfM4h!beZs^=PK&@`%h_VZ|3)x9`F5sHQf`qsz&
z1x+a`$0bv^Q;ikeL-YDoPQOQJ399>rr)VbC*jFxET6wvw6)Mg#V&wW(6fLcRoc27X
zR1EcGO@rpejiU8=lox(ga~CS1na;~;S`AI7(p=E8=gRS`C)|a}WwJ3^nrd!9b2LpE
zIbFmz^$c6&`0+SI(eTj6I?fCMD;ZvLx$2IlXYz=(J5RKPDzdwNXntBbyg?#7H(48o
zrszayZ|c6E@Vj0<Mj)D5HJ4<xaQ8wk<0OfaJzQ>gBhj>~=c^OZ60XVVHwDeCn%gr2
zEkjlJ#rFr56LPyTUxcUXZ!ALd@{y0RO!#dqmzQ`ny=r{zQ#6x${0~i&B_Efru9C4`
zE*sotC|WnUUVe#|+)~zdqbURAxO|JIVKCh~KMtT7Rbx;;prtVYX6^1cTJ}RZe@_eT
z3pp>(p_y;X=W!WLQT18L9!2Xehj&Z3Q;maUp(XPIjdffe3U{h<`UEXO<@W`eQPqD@
znAoRlA-6e9Us1BR%H^sAnxE>qOIbAYCfS`6nqD=wR1wWf)mN^HmR3wo)0)C>tejSL
z(KM>Dv_@#js%JLMggY8W>vU<2roAGE=Z0pUA!{_viXR{CwD#K#%@8WP<8s2nXL9@E
zg{B)Tm$iW+JXQYEjaM?R$>I5m@cd*g0L}cfT#rJ~w8!MKF-~ZzYiI;oT4ULrc=t+Q
zQcmZ|XxXZElA%P!%u7_(X)p&(r<!v&56#e8KE^^czgcqHFGcfG^*2_cX;l4)1T>v$
z-sXC=1XaIe6Po^voX%TCc>U$Nkb-9XNsh}dv}DzN$~S1)hvmBe9hz1({&E=2tm@|+
zL({!2=g}!NO_+S#pU~1&X@3dL^jtpf&uB(fp5H|Cik8d9U9@B-R$Au~-5y0#OfI{R
z(R8Y|iATwbPBka>mC#gUstgS&#yfKSiVICO21W5vbgH=;Z=soI%VkKs-<N$vj$ait
zui|q0)j&(o%g3#QW?U=hZ$mWg*CGYpTtl0prK#rEwL;Sjl=Gt<n)!yDetNWoQ*!*e
zqM4q^ap{Sc(OfR~ebF?7<YRcFWi#o*I(|ciwnaWJQx6oKNp4I0(fsIqTKf$a?np3e
zZ7iA+CZ}^anx>>&UM8SvRsGW#w1jE0Uxq9c4IeSKKE`a}j)_#(8dF7;G$wUfYn*~&
zpmSoaEkX0!BcI0#G!2trtlg~<8WZ%awRLF5?XusELQ~CQ*@9+L<@pW~-fwcgrJ`kQ
zk>j@)&73Qz)qXUuwX*g-TAJ$FT{>C<lbo#Md=ky@shqz*qUn<5_Ua;<@gv!92Aa8}
zoF6yP6uqq7LGx3MAwLk>xAJjw(6W={V?0Mo*ea*N?`X-Y`M?Z;D2i$fPrQ@sr5Y0~
zjh4&+iFF#3Lo;*JYOPg3GpgpCR2Jbe;m_J#bu?2WIexX#(mKoe(LnfBjZx^(vQ_sa
zbp2R2QBJ?MXa?0>-HvFQJ94@2f~HrEz4EGolIA3rt3JZ-1v%{ppqb9f;SE8{Fv!>6
z;X-RIpYKQ!p6Xf~B(%D6nuek&Z_9BRkESmpYfN)d5?0A^`9S!kgJzxfyt<%h7<jYR
zW}%sO%g3FIrls>_?e1eVGm{mpwKz0`>fAm-Q<}<oz8Wn}HJA7^wB#akTPNQC_PZ~q
z)n+tJyj(W6qiJ8se!oJ~os{!v51Lt(zx&X<c(87L9*2ZGRsZiOT7qi+sTnOpHGXv#
zP1{F~^93|7Ro~(&nlf50rwlnNTGc(+ZK2hZ-Q7n^R+X1uMR-f(JQDB98&%JHUZR-_
z%i-~pcRl1XR18f$hrSe=h6f7PY2}FKrF!Q7Hkw{lFW*7SP|ej4@9_IgmGiBZ2=9U%
zm-=X$-{s>rK{KtF%V`U=4Aq!<8#Jxz-6e{EqES7o<P{dh^toJK#M%OWs`pcRqZw59
zLj6T}s{84|LQ9aZ0X}G6mE`jnftLJ{e7>X5^q<IOatxZTm7H$|v;@`sjVQFVGje^K
zgr=y*F{h%LRrxj(EnD@x;zQwA^{xz$0Tr`qylyd?fty0>vauXZzg?~itI)jq%K5ey
zO{a>>1~iT8-kBkOMXS1h+a}yylk;sST7qg`#@E8#X}PUSL({R4g>{?{3az>v=Obw5
zw`IR4&=MNS`E~{^yRuxK&!ZVtbG)ty?V5aD_yx_N%1ee>SQJ}Mt9xkK48~c<`4O5)
z^?u4zG)46sTda+dZIJyID#Q6QXlET>QM6=L{Vj=>a8OPw4O+Hp&S!Zvv#NenLeuS+
z>q0d&FD9K?A6Kl`p;yf_uZNbVn*Y)mEn$)H`Q|>LIhv-OT>f0qw0hZHdo*1mS#w9r
zC?}_LcQjL5`FuUmjH>6b{m?Xp<-8mu-0@<Fb^L~*C9jw3ub=SiB-hnIw1n2OyU}PF
zo8&wSL({AJG-9ojw99gwC!!ftb!G~h=6m^kXP{-P+QeA2j2Uv8&POv}khMj^uj;+F
zWoSAc)LW-PJeuK(TvtCuGv1T6&(Soh>+ct6392!&WD%adoPJ-TDKs9|$K5U5<;ZpQ
zTQnULVy)dB5ZY!rydTh#RsD$LXld8wdVU(ssG2Jz)|)Yh%K3I#_}wd??=>{-0r|MM
z(DbUhpM|EV`T`Hpk|)dc=!x*lBwp)tdx54YDIY`OC0@UIavBs7FZLFe&#i=T_pzMk
zWre#}vR@~(Y*oLwBAQusA6gYHLp4vUCYoQ49KX6kQ@tD12u;U@-um2{p(U&4^S4Ix
zDlW&*O}Lvce7<QnIth2GcX_&@8C2K7UTAvNd=M`*zb<l|2cnsokYjy}chOAy<?Dwp
zS^^I!tlb5mWvkxj3_(kqC5Jao`1P0bHv-K|RnNuxMmp7Xf3nb2&pxN485ktDj>{ah
zY*)Emn}?RBdjD-9nleYukELh{s`hFnnnCp(Cjre!r^x!a>(Ml~<m3K-?45U9Q_I%(
zx1xeQC^kfmh`q&v1zYT0V=tft5fl}PfMPcm>?QWDu^`x^VsFu77d7^-v7)FLtSBPy
zZ#H_(TGxB;Irn{@_x<PaIXH*!UTeylHM3{Wo|(N#Fih6i%WVf!v%P|`V77O(9Q(nf
zX4LjaM0}&DKmP%ySJJvX17>8;3m1eOtMe;hx_MOhCYbdt&C5M71)GO^Bp5cD*q7}&
zn3>JFy#mwhp>=KpQ?mUPAHh_tKE8q(*q*&KA;;z;GAZD@IcOSL!3=o0YoEVdU<x+>
zk{8U3fxo?6K`<TL*INWk)0@WU4rXC%HN-d16%DB0R}gY+U40cHmxb144I$@5ZC^*o
zm8R*c!8DyHYbqF9C({Z{=S%&sJ(!a1zw9h@6*RscU^certT&j6?UnWytOPA@e=su^
zTHD(+Sje%t=1?&GMq1toFb!MxKN?KS*7J`Clk!min=ImEd(vkJIUE>gpBHgvnwGt*
zTnJ{JLv64O%#cLOwpy^dG|%h7%tmVGjY2LHjc*&678}a!^Ri1Y)@JsB+3=8VFLxMB
zkCzPg>^PX3y(2vhW?<(K#DVEp{fe_%RlziWH^8*`h>U$2cSU?`4UiQ~{fOE{oCT}e
zLHm*f!FEwwy#-SkX?=VElTzu};tQDmA<f@+FcUUN+UL)~8F^vzr%r;srD@~@v#@bz
z9xxMoCMf`BVDG2h1e;0YD=y+YPV-j^%(jG<qdb^dqHRGX*iC8|PcRdE*6;$;yr6a#
z=YHzG&@`HW8JO)`f~gl$TeSmI;$@D#{W^hJ`1~K3j@>VNiTK!Dcpo7*fu_+9OdCe~
z(?LRRGtKi5Fcltx?ej7W%!WfB?Aa(V6Pv5jgDDo!b`&XCP0FT&8R}8{%>lEqG3x>_
z{UqAn#5tojN2<FD%)-`)tOGMgiX8tMo5g@Bo6)ju1v4hlI^PLqV1Bw+un>CRKLn=V
zNB!>@nC&CA{V6c*IcmT2V2ZNTPsKTqW;XY5UBt)sNZbMA>k}UexiA{vQz18i`qfJ?
z6JGw=+a(c9V(sHSnB^udM>3dg2(^7Gm=&9a?c>Xs2kB;^a*kkz4zw@M0cK<8zc>rs
z2UIsdnC1$#Utur>%Zn1sl#lvaNiZF|2b2RduzPo9Fmq#Cj_N{=J!{kk(<f8=)faNi
z_Km?5Y|U&7F!g2X&uzgpY(HX0A-9Z{w;PyYCaqr|FbjJp;wR+TGh!f^jlJ_92&Th9
z3-<M<15*#9?PDmIf~~h0DdgB3)HpC3n+KT$reycQX<$-sYJ=G#KDGvYKA7<kwZRfF
z{WIEUuM~24@o!&_wP3n#)Q6(MwAf5wFSkYLvi@%en1by~-2<k)MDub`#Ft2!8O$`0
zrg0KX#eCx&m<<!0_IbGkX6Q<FuYswPY2S1kOwaa0Jpi-3qq<LoE*oRM08_B%<Tqee
zwm#w=m<kIG?eq5;%*giMd;`;Dr|m66UgYlst)nbpmSHr$>|i!F&QX9F*mx)(n3g@)
zx`J6>Q`;8<Q#;cB#RE)VnfiEHFf$fS*_W*nm?|T+Uo|i#TL)DO%*4i5^}rOH=slnj
zn6?2eZ*wr~c$#h-FeMgw+UKPMn1#)=b_FxAJqX@lx>3}Jv|wg-wo(9?n%zGJfa#CW
zbVEdZ?46uAk66#%<&OZfu)PIi!L&)#&J)2@Y@fqaFavwmm<6W51|fSJ%mdT0`}txa
zht0zFax1{hY+unDFax`XZU8f}eb$@7Y|N%6Fhw?Mm)&40_S|y-OzlK{{3w`-J(ryT
zGk2u%oduI_Q$M%}X6-=77FWRxY%TFEFb#W8cVEb{XVb@EI+kucm<@-|*xT<lnBJTA
z#Yte+)wDnT1SY+t?L0;3vNc(f3w#3y57?)X8BBpq2lgx*n7SBktK#f<(|BrA7cdQL
zZ-u~&Y<+uCA;+ErN`NWSXu4&<l;>%`Q4!3Noyt`OGd-a`SrbfEh?cFch>z_fXb7fd
z{cbZb3wtJR4W>Is%c~KL&98L<Q=O)H?g^%SP5sIj%z^`@?CsoFum-d)gG7An-P2$&
zGkcdB24=&eIQ#g9gXw$HdK)8j*&dS#VA_w=R#U*NtWD1ZQ@T?-&lT~pJtm95Y;3*C
za>3aAxDiZZ?@6M-^z1oh6PSg)YugTHb))5t1v8wZZDv21)RM{_0aGhzUH$>438($@
z888*w8*~9oiOog!cD^EXaafx@yD8+@T8Mi>?h=)I1g2ws`*Sc8JBvYlx5C2u5*wHi
zn|tlk{RpOE>k7Vt*&b6rNE7klBLeoinerh%CAD8x!PtHX@m&l{ZQ2jz1v9X|y&#x!
z1+`TXFbx)#+o$U;;+sePuQZsgHPx*k<glsOUbl*fZwi&G0j6O6P#vMmo~_hiHfL(T
zrXs$<G>ukZ2DWyvz0fT}^V}KCI)%3L9$;p+KBu=}Z0&+Sn8enI^as<fpmq)hGqCp%
zp<os^uN)!d*#4Q(U`95tHy%vG?njfsRP6o!456Eewj+bkW#fZ|U>5ccZJCf`^}AXy
zwr_hqn2o)|*a)WENPTh}n3Ao@+6AU%_kew1R<>XKFqqkuwuR$hdThq9_p8$)z7w=A
z<G?IqXq{gMQ?PUHZh)C;(R#ZJW^G3O$_l1q=S4mP)7PN731FH6RQIi59Vz<&W?f3}
zJzv1o>>l-9=z7z>&LKbY%<9|;Og)d*c}^k6p7-+zxmMJE1%w=XZgdlJTWS7^gX!3s
zz*1m}&osXBLYK{jtH2~IsI#v(PcZ9FI_~rW(_W+TH2|})wYp8fOl%!WOE48%H`fl#
z=uZ2MPGE+mv_86nDcIPo7nqHWE&2$?o)P<jso1;OK|&4-Kkdsq1WcMM$gg>`VPIP3
zf1|*3IDElgP7kJL?JW{a!`2v12UD?i;d8(&Z2Y_cOvl>(QZU0D>T9dOOrL0*UI(W7
zO3M)=;$zQNTfsCoT8^Dy7AI<#y<kSR7v&I`m96zV24-S=eohI-*2J6#Q?aumEFwO3
zZ@dnsWcP|YV3ri>_YXyURjBVi1+zV&zWY)zHb0&Sre){xya&^;waLj~`l{6SsbD5H
zF3DH`cFsfFxg(g3txL-x<d{vJ!OU#$SAH-BYtw~=ZX)eZl|n9&rdv|P$Hr#mgdD4n
z%3x}2FtzvR>R`5Kl+^~4a1fKdTzxS81?p>!!K`eo+ycztN&EY@f_0+09l<Q?sZVwT
zQ?qr~K47+@)bIVkly7OC0|jIK-#{>l?G@C4nJ?1#hJqO#s7*(Lso5I7abVU}G~G#p
z-Jt#CG%yu=uAL2LV&}Qd2eY-HHdq2?8Aa1rDRkMnYHNiYJ9j1;Oo`1W_Vu;}%$7py
zV+WX#&5!Q^)3P;G2f_4g?~NHud6Sm+B$$e|t#e>H_Kx5Zn3naO*T4)oaL7K-w}mbn
z*F6xrY<~9%n3>J{yb$rlQ=7g4)6b#){0>axOyxd<DcPLDH!!n-`b&m_h>z`$$^xcg
zYlX6d8Q7jF1(-rZ)6EAat)uyK1=F)Na>Yb^?A^NunEDpYUs*8Cc^Y3OFzpd4S53&V
z@kT8$eM?%u^}tlvkZfN^jlk4}DQgZUu|39Zgj^;1tkD6?#^&_93OP2G@&?o2qiJZt
z3<}y-1He=`Y{x!-1HiOwJxvIhGMu)pa4;)7Utk27k@@aeFx5BerxU>xY=81pFeNL;
zEHEwGk24QU&(?e{2D7kdjTK-9c0XSOW@dA98^COjsSP%Rsa&b8#P`+oDZ)~}#y-2j
zl&p_E0H!t4`|nYqYoPI+08_Jbtj~g}m``2=GvJV5`*g2@>2S!3J-a0s8&BQ`(-xq*
zj|H1g`?YwX%f^YX!88|WIg-H4Z0*q}Fe5wjA_dIK-U~^EU<1|<Wd^gbcS_m7R7@^6
zm>GxJ*q7G@%-}*<A;Hwt&PBm2Y^`nyA(ukyybPGc*85Zxx}B+9RWRi{nnq19^#;o7
zf@x3DHq#JH$DT==3C6~@t-%y*K306kPnVUp=`LV;w!gL~nC1?Z^97UGymwzP6?^sz
z0#iuTrh`R%Cn*a9)0$`+!-X#EW5<9Q*n6A_LXORWP60D9zn=-FVeNdb(8VDz_I|Jk
z%$i2~?ByapUn*x5x{GODMuC~@(J|{LFdchWxgAW&)-lF{Y2VX2-!I~0>qU=%8Fo`!
z{Q+jpN^N=uOt)E->{tJC0Zeg-w!tf4DmKq>6U@wf;~tm|2jSSq_ekin^%l>;q+--A
zufR<BP^Z1F4a_{3_8T9;ly_*Jzk(?q(6Xh0=||Bz%H#_BMN^g)O!JxcSGmB<Y=1yr
zFx6UWmx6*-rO!A;z$CV&(j83C=EF*ZX>kCGeR(T@sRz^es(@*(((={-Q@T>!I$*lJ
zv>a+M3l3bfPot@jW6!3oz|0w`UD|^w<7pb5!6YB*e?7pgIQ+vtjox6E_0-4xh3*g<
zUw<&eGg`mFV5%k54?@9otW8INso9y7qruE<ebaa_?Ja79$zWD?X3Y#RT{x99fa%#-
zc_EmFo$<R2%>0PjZ#9?_9}uy(%X%;!dxqEuW@PJaw+S|b+G-b=l%Lk`J}?{muF+vI
z1sk^?2h$a!c0LVeW@r1yfoa%1`7)S=tz*0arW#1gdl$^OhWdsTOplG<_BMD1W@39_
z62LSkX?$;mE)M6k*ZlydxJcvs0%m6C@O=lf9H6#$C=6DS+Rq8h)}GoqCzt_;1=^>Z
z2h7UG8wJ43-D!E<z!b@}9L2#jcd0*@5^M|AEe~cpO?6dZDo>hcPcZdd+7EewDcC#6
z24EUCuiOMo&-(V3V3zMRFYQEpIAqk`2A#lk?4H*h%*@vM^#W7(puW}zOvBEp>?d@S
zXu5;Ilo8YhLj+@IQw;+%u)S5Iz)Z~V^<dT*YWql`%bpjegQ+Xg^3DO%v-$f4U?#Tb
zVkwwy5cQ!|LXORMt^+f$`$vpm{iyC%F#Qr*=R3hH8)+ZA7fi90+V2pUij7Z?3HFZK
z^c0x+CiS87BEI+3Ru(X|p0>B^V45Y=R(HUx?B4SbOr@pqJq454`j?j?J{&e-?`w%*
zN*iVG!A$I2l4LLgI|m~bOvRqxGP)s+YBVp7V5%?F&N;xeE2&+a!K`fTogd7+ncm+D
zgQ?j$2}&>{KEz{Rwvs{)2b<Wla$tt<)TWieq{7q&)xoS5%4&nzEVRAV7jihb#y*Y4
zU`96g)dI}S>Z2`~iLH6+2&U;y^Vbbb$<FEU0aLf4<@E!z7N)v^U@D2q4Fof@{#gfR
zWcRJ1U>f#*W+a#?h_<6~V5;YoO%m)3t>0;2>UWgQ2D9LxeS7=O2Q#oUR+oV3)wEr%
z6l@l)kF`Sg22CRxOvm0CZUNJ<GZA(OUG|=2k6>)<eGp8krs<l&tXF8dCxtFc_Z*mw
z%|BlPQ!(GT24-P%jJLrwUupe508`AR><O45AHA=>5W4Ky;Em8_W4(7^M%K4~22-;7
z_y%UqLECwTBG6@f&a!}EfgP#e>|n|*lqtY0?EP;(FfHplU4<Mw$FLZfft_vR0j6eW
z{*)DRdTOgmU<!6$s0L>Cp*~p)%*OVg*8@|rbGsXXY1uPLb1);Dr)dMG%s_3>0ZhUA
zlCEGT98O~2KD@!qE2-_ZU`F=b6CiZU(((=fQ!zV-fGLX5_`<;qY+hvqn65pQ8w+OK
zMQt?^%vOl{-&8PFY1)2gfoa(JX7j)dBWa!&gX!@R8hab85Nsb!V-1-3CY9SD<k&pn
zW-!ZWnubZ}rqZ(Q7IL4d+yTK7Xgfa&CgI~Z_W3&jrex3iXTj9$zHkvtfdjbhb+3Y1
z*!K-?3D%94_rB0wLv<eux&1VM@nBZgkG~eWtba)Y)3S5lK7pyqP`jjn=|gE<O85}3
zh4rVI#m9N^AqD%gWdk#Y3-W6oBsZ8kCzW#nQ&ypJg}}51TE9iX%<TJqCBQ7~tiLi~
zx<H!eieR=2^uARUOwH!pYJ!=w()`s0Gd!X7(GW~Ckjga!)3Ns&t%WX|E6@nJ_cVW9
zz)Wu_>j`FKd$fJQ^oMDk_Z7Nqtws=-A(ZwdgTXYfsPBe}`1;cLhJ&eR(*A0UkZVuJ
zJ`+TIx2WzEFhxdctC?Wdmb7eh!IW$t?joVf=EIhQnb><UBbbe?DT)HKl&1B&2~1s!
z`qg$J$JX7%f|+O0^6m$-s;U1S0kg67#eaaQ*|~3Lz_fmJJb6Jdwol}W(49x^cN0v(
z=1T8@S=gGfM_^Vnt&itmhJ~~ouS9$wXnokgl+0f~f|=%1-LHbN_jzexn%>lhG8F?G
zL2aKE%*6aE7nquzv6UCh(2MqK1;M0vYWpH!dNwEH4yL+8^HLhjScpDDQ~<NE^8l)V
z8FJ9}Q3FiL*22~SQ?c*usKInbT5nCk6i;Y5T7elNC~FU<PN25xESL+;a}O{xd*9d_
zOv%nV@CTFFIIKUIo}CX845niHo<hM)IMB?#e~tjN8EF1SgK61)X1tKo&^A38OwG<`
zodITIbMOW*m4TLbA(&<yt@CAITDFg6HJI)qwf%Z93w!^uQ7|^wyba9E&UD%ZCgHGm
zdmHQ%jP2z)45nL7(>)HR#-VBUx~IX+Y=24|n1+o@E{phZ=%&5y4KNei_kI^l&*l@Y
zV5$Uq?|CNV*gB5{FpCSVqqksI_WtODkYi)6FJL(Ei{$S+m=PbPvd^=F66Lj0A9n&%
zU#GUp38rA}H;>T8hq>(ID*&cpbK!1aCboy8IGD8|&0i@n)lnK>c`(fz%2Z&+43v3-
z>0eX-^Ad6|X*n8zS=c+~CPMBcm1`;Fj?#X&9hjc2JM08z=t}Pu-NB?+wBCAwS=f4?
zK0=qRweJU}%1z@N1g2zX<P8zJD`}pGf$5gh{&W<WW+3%bJ(vX_T(z&aNH8V4Z%qd?
zte|Pk5%IBoSqs3_v#G6?f|=R3Bv*mirqX_6onZHAUShzEZ0=zzn2C*ncY;aXsPFCt
zv$6H)hrrCIX&-S6Ok(q4r@$2KJgxI!Mpj1_A%}ze?d^9R%(9Kz>JFI1_Rl;Ny1S{Z
zo(j48)L&kLsn|1JqLBMS>+-#ji=*)+gIOC<o2G(U*gmg}#gP{r1Z!UoM=<ktTDBZu
zCboyj8O+G`rREp9Y`tw^FvU1pM@le>eY3bEm~Ia356XcVlW04y3}$6}zN>?&*?Ruk
zU?z6XaeXi)JDZ>}n1=0FYa!yp#~$tN(iTkBgyyBA&}DlHyMY<mT5%sR+Y}m~pU`be
z?Ggy4WOL>N!BqI*n|)q%U{-c!;ZPCZLLv3*S#6|XFQ{LQ1C!XdYbJpi*}kG_LYLL=
zY%o)Mn&<goN_<4wKHVi?hOyL#R)Xp7QQuuF<Q~%eMT6Pc`t~hgiXpV$*dcV;*%N!f
zRP4R!K``?iY8Nw@j_qeZ38svr?f0CBZxc=TlF-FRUhK<z4NT3}Ufu@Nv-y$-BECg5
zjVE9d8#lcG)3SM*H((|gn(jL=D;pzy2D7ofbKk(EeY9<5aEDzoQ@_drW^6+1GCP=>
zJx?pZOl&SPADD%GyTKJq|CyGz7?_6T&jZYcLoMxXS{6*Pkm^<v@v-t&1GD6&{a-CG
z-4V*_ftjw;@-_m~u(Q^hgIV)aKWzhMVdd=rrfx*#x`Ih;KGqvdwUFjT3ueNH9_-5-
z0H$GM+W}x&cJ^Hen1a2B2nW-%_B%qv$KL0S1yk0f<K2m1X130JDwvUtEoOmfXVZ2x
z56sq*_6Li>)Q2cr0j6Qk_G`fOt7%>~2st))y%|hmWix>(*qK<n!3-g^k39fpdqde#
zA=jJc?}UgiGi7JNOl+RvBA8|!^`WbR;X`=#b$JWS#@0#S2eTfcd3g+GIYHx#2U9Mj
z?fkW1?2Mx%Fa?_f_yi`!(RQ8!X01bgO)7yrv-QuJ!3=DTVKy)wd$*VyOv&DpxPV#D
z(>xaf)5g>KEh^;ZQyY{3(?6xUWxy<VY1^s@rYcG6s4AFl1ubt)A;+E#>VhfQ+(<((
zE!$7m49v*-m)2nBL|R80FcUi`rVE%Nh32^@n4Z0B^97T}(mu8?n2vobF9^)AoZ4kD
zn1Y@283tx@r*gx=G{q<z1Eywqo&cs|&plJX%xYS1Gr=U*AIt^QvA%N=m|-uiqve8q
zq3y#6X2M6j?b}Qgn7S0b2W$dUvGQ&Q)37ysv4W*ho9+iQur;_xz_jd}8-IYA{AvEq
zfGOBJhYMgjw%6?nn2q%jH${AGf6qNIJzIbE2uu-5>*%@AWp;iAW+_g~W&^XaHANo<
zWA}xxU{X%nKGMJxNi^L|9<a-JYJ;p`hO$&Q7ntP_>Kl25E}I)E2&Q0jf<=Tb4t%z+
zb9W)f`pME@CbnL=f{;5y^H&8-xrXMi2AKIh9W&GcQ?X|aHJF8c>#`}B`ViG^1*R!O
z(`_%}W6$=T!HhX*9rXayvh@tTMSS?6pS=zI!A$FEy8Q)PM_DkKne7D#1=BKHMF@76
z+GRADK8eOR9t@l3NM0s`>6~dFHUrGS)&>{^YeaPyg4xQ8lKp!ASSDCi+8?Y2Q?a?K
z^+N6~&EG~aHG2=c4a~y)eixYj2-V#OW?VqoVK7A+&C78x9oyr1S}^v`H4e-aMs+WP
zY4*|k>J2c1hT7#Wn1#KwwhG<))K<^Hl<W-q1TZ~&kNp-*V()-HfLUMB@_qr+eWz{p
zJD82ly*iXcx{<VOPGGte8edK@1G_io0kg8b<^{mC>^mlIV3tzUF2%vrA88t;1Y>KR
z%L`q$mR$v=VC(cf!E6ht-+O^ctUqV~W@O*sX(HmwMB8~wFg5F++kqL_d&y2<I(+ol
z-tW81jP?h;M0{)<)(1?(_TKaZv#@X44gxc?`J5qO3N=l47?_&9Ya0b-T0-rt2Q#qy
zY9yF6lD7TnU}k*y*}iOZgj@o>cP{|bv2Wil6>?i?f4>S$Q;_<>Ixq!mzcFBXwijiq
zh)+xXbSIc954H1NFymyJ?ja$Ui|QT&vpl8#atciU2W98Mtn8W2BG?34j_Y7bZ)(3g
zU^X^S^AODNfZFdVm?fH~`x4B$ljb=QOp{32d!ft549S8uqHRAFOnrf-k+Br)l9$@g
z5lpd|<}U}Br8_OJGnl>*)y)rPW9RS{1~ajGQwli~^{bL#79&l!9GHfkUsoAS^?>%f
z)xjjz_G^pyn4Rl`Su0W-GzPP=duR*6s!<<m3#MapJRQL->^m#nz^rUe+6T<c=1={=
zR43@%YoK5n$_9cNSl_7w(>|s5kD*{XKWe{`U>dfzXB?R70@a-)7~88g4NSq-63-U#
zv9Z8>FjGNVA4|ZDYU-ye!PM;DxE4&s)+9uONvxmT0;aUm_;!F9nD6cp@#Us%@F19i
zjRnkL)^pSkPJ-##{=su#N~U{B$YrB`e+^7=i?Z8b5<Bzf0horZ%Y6c7WWMnNOnH?0
z!5g8=&bogGre*sfK8yI+8v1WSH;q2SW+;t3vvo^ZzznRf%MPY|Oz$5GFsU?cANjyk
zb!i{r3T9$+BgI5~9ckG-M11q8ZdovE3{9gFn2~+Ep&FPzg8E-AFwIBmFZICG+i84_
zz$~|@ZgVhIW6Iiq+1MOo2Qb}LTIXE_+fDt-8%$k+GOdVjE@c5=O173{fM9GLN(h*_
zF7@$nFjX!Z-v}@(n;#kr){~uKIuT6C_AyTt@v-NCSzxB~w11f=<T_J3F9y@9sa;kG
zUA9+Y4VaFdU9<tr7Dm(945r>r%Vq*IzM%fR8_fEE`p^L|Eqh))3a0u@?RNsqu$k8R
zSt0j~mhB>#nysU~3MPG}?c<h^W9Mqz2eYu}^T&d*wjVFzdr8aj8q7MA+8_x`@sQf;
z6PV4B-d9sZe37)gQW@BVo%fm<OjC^3TQ)GuS(=yJLXPd>Z~@cLqW6?SLYJLmT@*~o
z*4vf<Q?WUeGGLlnG|v^m6l~paRWLpCjhbMFLbNXHf=TR~;|;+y`>Cy(iTKzvdut)b
z+K~p#vYPrv7cf--wN+0r=?Rtd1v9YmMqi<uN^Ktmrk_UZd@z`fod+KVrm)bqFdWRl
z+V2=J^D8Ph0nEm1Fa=D-{B$Omk*)Qc3#Mk{zeQlWc<Kks!3=F^IgDV657aJEV0!jk
zwh2tCPU~{Jkb6htiv_c?vuF2%X<6BhfT>5&d%z!Hs@t^vo&nR;q~*8(W@7VPSA?#X
zmg6Rv;S*)|z|^g1{XPOSvo%W3!7S|A{uP*F9M!dfnHEy^5lqkayL<&x)}V4}U>4@j
znaZNPJ84_U3T9y6=Ew!6uTIOB7fj3M7z={wQfd1w0;VcMb=|?tY%OtVp<A8SZv`;h
zBU(pQz%(Oh|5pP{Rf*PH9U&)CzgL6l*xs+Eg0Xp!R$vl)N7^1t%l4Ob2GeJycJ3kK
zV`nAy1~aj}k^W$ow$xVr!L;nTCm2j+r8Wo!Gq7__BfyMokMU?Q1$(bH9!#yGZDBH)
znaw-S05iqV`Y?d0no`|`LXPcsUIu1m{lRK5Gwc7>gBfbj_%?#6*HN|&%*fa-Fg<%m
zx)02hN^Nx*Ogc>2aWLyM`kZ_k%y5;;#R=U@)CQNqbnJ|Z8-lf_a(BV3cj$e=3Z`ZA
zvCqIv1E@bIfEn1F<y$ay7ut?KfGH=_a(n?ZKc_zV9n2U++qpwIq%oeh87DA3dk)Ac
z<i^l+^MGktA65WN!{+APM0{*6w>X$0iT3TKz?AF^*z!WI3vItDFaw)A^aRtfajX}Z
zhV=&xz_bTx{WcMdtr=@6blJG1onUO<tP_}ltpVyT;$!Wj7ntHJZRdRii=%bk4@}3t
z$1(`aScKN)5HNL4syj@?$JU&T0<*EbuX-?S*p)=B=aDKnqmz>&!T9>|=|Ya}510dH
zX7`T;V466ZzokNsJ>#qra@A=2SO=zN>q=w5v^S`&wt`t$yW9z8V*9A}f|=jY_I3!&
zz{-0JOr@Y{oD#Z9n!od4#vIh|Enw0%+BaPnx@=r>2TaBGgFOT@c+>nn1=D7sd3h<~
zWBE%Iy7g&Wcn_x0(dX%8!Oqb<r;7OI(mZD@561QeIfCg%(!L}In3nCcb_Ub1voZ36
z88XoRr7)QO2K5akn0g+yb4f7kI9iT!U>f$lr^;Z85wvX8!7OYnS{qC`owkqqLXPP+
z2Gg?hZd!n8j?+B11yj_e>2?G&vGHj)Fdcih?E|JQM$795W|=`*AefD<A0G&&$V26H
zVCKBEE{B4d*c`=3q5FmU%Q!GiGVT8+fl2InVH%hg9|5-SBW8ms*_x;MVEXeke@jGs
zY`n1&OqHF=tp(GvdB<p>%gzzm0;Xi+$sJ${_MEo|%*LMC4}uvw(Rwq3>DW4`lVC>n
zj{Y2&)}8wECBatG_Hhl&bdTEfHkdAf_OTDZEdI3ZKLIoDplQ4SGqW|qZ@^6KdGMXk
zb)tFsEaccT>^Cqadv~0n0`k(5`bHKoT|Qbz*}>HDv}_766MNT@4@_cnudad}pt{At
zbOzejd4OqLXdRUW)Apoouo9S|3uV>7Z0vn)Eimf_YUg@jD%O`Y0#od!KHeP6w211q
z5xQq-x*fnQCTgp$U}`qT^cK1gsGYT7x;?bc1Hhyc)K&w)EDNb!LcsKF9bPz?p(xGY
z2r#omb;p9~D$}w}1hcSjGE5b^UbJkpz@)8Icb<?tPV>ANOvm2QuK+W!`KC2sHa1q-
z0EUmyl0Ij%(5*?^kqJ!Mm6mO{kYoE64+uFg+CGkgsT$JwPJpQ;dapPOX7#1)BABHY
zP4_C8E;F_LEiiLaYODKTrmIx<F_@wk^}l#9Yi=6fYcM6N-y|?Io74IPW@66<DT1-{
z@1=_9H+*Ot%nYVu>msv(No>A2H<%$eEt?CNjm<L@61waxkfLBpwywDZn3+9mlmW9I
zr)g9KQw^eZSryF0=2>eB7E67oE||@S#@7%`$-WiPOz4)Pb<`S6&FVt~X1GP$Zx^AP
zK-)r3q08*&D|Fw`H2Q++hEtym0@F01zA+fg#LiU<6Koch8!mLOQ{No}W@P>I1Tez|
zT8=4TDpnse!7O{J+*~mABwCI|BEEAp-Q{3f_Rhu#rpivs8wDn@vA`xU-C3IMb};K`
zTEDSiYSx$R2eW;o{q7Mk{+{>`Fbx|soB=bX(sEn?Q|+X7z9Lu)T8^87^`LgS2d1e*
z+uI{B9sAz)bHUg%=PNKZdxo`vX{*pQJ_;60^ZXS|!}g@72|4zDD^n%3LAK8;E0~q7
zg~$b_Wowl3f~mgIaeF~9B^#?05prxk)*Z~o&Ic|HreJgb6-0dOJ!cg#iM`9O0j57k
z=Q8SmX**G-22&epTWt!a_(J`v6_|?k5$(Yw_Fb*cU>df@s|T3!1x=$jn07i%!yinw
zm-bElMSSd@5-j3l&zGTKHr9_vfJr{IpBxQlWo>^vn8Ahm?qm@kTR${IuxRSL1~4O=
z16T;A8B2X~8JLdk4O$ImVSDV>gDIa=TWti>cA)WX6S}P5*afEkMs@drsXVC-4hvoO
z9^yEdf%)2Lq5G2BB@Rr-_M%)Ca<8dfZh%?Y_ciW<sdLcwVFi=e*zp;d?Fzl`CxBU2
z(>DE9$hDyU@&QbdLeuyHW*SHPtM6bsHh<+%8ELS!(@tPI3r#mCn2J5u<^hw=(6&`T
z=(7D*ZeWI0v@VMaIrfZL3QWQFWtA7YiS!<z0<#5E+k1jpD$_K)z?2<m{u+Skx6-mT
z5prxS)e=l+rSY{BEE{dVoxluiexo~>md!=>0#mW`Mf-qR?o!|FC*osc(LsWBqU9X|
zW@YE)4g)i?^{k`7OvyCQdckf{ACCmnT%&oJ4rV?{*&Hw>o9ABureovcrC`REG~HET
z8n*v!9hkI<)^CiEW9!Jaf?2LpzuyU_VDn9T!E9}5*$#o3-cb7;6LLLi{hktx?ZY@P
zbdOViv49!bJB;gKYPPrF4w$kQ&C5eDb8edMQ!q;#+F!i{GqL++BA9}G-{n1+@ga>b
z8BG6@_9dxcDmG7(QH8v)HSdmKDz+Cdhmeb-{fjf0p1mu|52j^nR|^Zq_U0<V6j`ZV
zN`l#5QC}-3SWQ}v%0jmr%}aGKJ*$t}LXJHr*9Wt*^%jl6v<+z*Ex;^njbU3bb0qbH
zj$mqb)?YU;153jP%yyEd;RmK+=N<(LR*05uAef%{fey^b#+XCFY;m-`jRdo%P`@7s
zru3riZIXzOtuL7d#=p-r8_cqr*3o=0O+K3EC4#a0<w`IUdlp(N;$vt0MuV9v(>{9(
zm~|$#-wvV6&hgp<W|~Fwau7_-#;j&AeM{QjPJ(IJy1sK@Rs~J>5||;7_Cwde%&VxK
zZ-bfGJD>-Gsc0QN0n=(|TX-Sl4p3iv1Ew2BpJ(2IsV32MKZ7aERQDU0dK1lahAQZH
zPt&qx0n@PYT6QpX7MiXCOvm1T<P*9hY1v%CwCo(nVqm6f)b<`=QX0*3Ss|A|StT$H
zJ3p)%m~J*rw-%UcBlV$rLe7o)eIqb!EM?8XlzVA>Z3L@E<Ldxsm`Cl>6-+;i+SwaS
zwThNk3nnpN3joum(liEuY1nt-LWJC8+TVwR>DYRZ5nz@sG%sVpB=$~tqR?e$I!zV2
zFR1Njftk0{wm%Qdz}9#z2Gg*yzzQ(c9_r(3z!YqbVuN5;Xr4EN*;rp<5^Nx~>25I7
z5n68tz$_7z9R<^zpniV>Ow0C(oCUM7a$E$H*!P95f~na1?pt7nb+nG|gJ}#jFOLNa
zrsa(X(|4fkHJGg?)lCw*?D_H&n2yb5q=@+9XuU~Qq08n3GlQwKQGd<`rjMj{&JCtz
z?b1c)vVAdyz@);o&WnPnF3`M`05fc(X_Nso@1f5w6~PqSs12%uNo;PerqKOB>$fhL
z<v@B~T%{V$8KfMDOp=mab4f}Rr&4&p@Nh(xU#jVBn}xOxhCihYQu-BFaAVJ$G8fl>
zaF5`@5{^==>8wUvLdWnz<XP6iH4hcKT}kMc!5(aJ-IDz4`f&ML4LoflFRENpJA9vA
z4Kr2>?duorm#(MC03iP-X2mNt?%3I*d*g=mnvnT*t)ZOWPd#NuyK6nEp333ZwU#VS
zbte03G)_%s`)iHm^wdA{sm)?{tual{=xBG1<;CRm>zd|AUX(xLG-tKD)}6*_&1Qd%
z=F^tl?ix!^%K7VBXI6GaF1u?#^sKs!ay=+>%h!I?kR+8u-Tt&SK6EAOLB8hE*e@)+
z`B1;mzFh;u{rU_F2x~}W732S%Y`RUc<RCrG33jrf>HgODhixiMwYxTQ<jB5#`jPrK
zU=B{?Dcs+qWkXg@Bj%xgUhB#1W5RpsAJ;l_Ju}9MKd=4NdofCq^J<wTUmKq8!Rd9i
z=to}nVSOC*<ZB*qe$g(_1Y|wo`?wbHORol2wV_?8oh9dLvW&UXkBg#>Dp5yh7iOXF
zAf;as@fp(7GK=d!xCcxor-fmctYbnQ{^MF$dYi9O9Q_>Pvm!^h)+Y>H^b?sx9`w#q
z_*_|6T}k(=ZT@5;51FK&SJL$|3q55X=^N5gBi>3uzx2##cY;Ap$}FW{@$gK~qYIcC
z*M!VJuA%P|W&3&Un*BA{MqK+D=L`F5)zhzGs!fhF2JP=3an=ymYB*<+`<^@!rbvX0
zx{^xeAJ{Kl?<Yf+q%6|UE9rWUa^2*S+%u-@`F3p5@Mk;v$%LMx^z%x(o|Dki<dJ6Q
zll2-^3Jn+(;x8os{`uPie_P;h3;b<?zb){$1^%|c-xm1W0)JcJZwvfwfxj*A|HlHD
z0+V`58RR*NzFs~dVLl;!2Ke{|_pMPqFf_m?IB4*|fY8AKgM9o$!^3=r;$NSzP=6mk
zolg9(f5_lr0SJc&hYLNSA*=fMg@+8U1R{A!b)7S4F)u0Q#k2TRozp+Uwn6@(Az>kb
z;mR@{%PQOJ!h?c?Mg|S;r)(S&tP2_x5Q;rJ9?rhL!~A{y!ox#@`V0*Z2*cc^hjagc
zLAroYdn%sYJ)Hf*2O$ligS`2Mh5LmE_y+q8_UjiA955IYpF$=qyswlEVYi^ceM2I`
zq+Iy_W+6idW9A|#1oNCireUL&|5heFU+HOtqM)MYvPf;5w_@_5H@+4u{{Du!2Jtfx
zznF%T0`WVu6sAC3#r&-FGmApq%PT0%Hw1PJ9264a3zPN@5_zdRbZ}Tuzrg{0mA<|~
zgTrf7ua77&51U6(M*Pn||EPC><&m7lD{E;Fa?w6R;2^(#!e-9SwZN9jZ1B+FJ}@qR
zG9uRle&iR&=E^@+@NZuHR=}?~^CbP-4lKXHeggx1{bAuy)R(V+f4@*a|8UeuSjf;&
z|A4vzRDhwqyao>)G)Na7>Kp#2^8PcQPI*M$(_<Hz5@k{&ECu_v&k!)UFaF;?@8Osa
z5<m8NUxvJ=&&&U{yhn)4`-cBh_WzUJf95^3@Sn^3gdcWy%OYo8+Kq+?RS8RWq&3L9
zT7IX%@~-m>4GR#?5YR6m^p}4O3K`t50`;hWUpe(FR1p;-$`q5HJpcC}zGT9cL2jZ<
zI<y=ykLc{Y4`CGYh&qxhTquh=G9yGY1MlM(79iqxc0Pl@*UEkeCl3t>8#)LrQ+Dfg
zo$9zgRMtuNRafXt#oy^Z5HuJ~!EaD{TSi+=_iddl@Ba_Kc9;MD<=3SkC-VAGPB++Z
zxUVi0Jpqyq(hVBnJIrs;P~=Xe@8m4vO0V(}Isx-b4$i~jPioBnf5hLj((6G^OO3zN
z%jes4xGq#gB>Uk{9UXKULdN7Kw{h7fdi*WEQ`tU4`V^q>+n@65Aur;aT_jyz*jD&(
zCfWZ7<7JJnJZosLQxN{L7cwqI({<dT(*}R1mo?o6zJ7tCHU2EHoR1ceN$(T-2K5UH
zm+Pkc@Adrp!gwN0@jLm4pPq4oFn*4~KZT#}N4N<-pep{G{_KCkPk%JTAFld;<*VXc
zrT;BoHNY0>ZT|PZIt16-XZZKN+8;81##cpL+*g(Ghu4_%PQkS?>2)FdY7_kZuY6VL
zxS>89K_=S$m#<F6-@o%!A+Le_FkGKf;+L=1#oyBuqJ01Ct3u}lbVOf~+vAt7YVh}e
z@>Su_+*f^mulHMD4aYk%@uNWd629t$aC<5Es{F0LKi8-Jxaa;i-Ky-Xx8xlB(?9>{
zSFO0j`_&g<zw1|R;OTYwt6xn9`>Xxx66pMuezgSTQMdmXFNl6s_<Q;|;;;9saqx#F
zc$bNz@}+U<b@3m4Rp^|7j_6mT%KY+GJ^uckuL}8ZkQervSoW8%{=0rv=wNHHbOAag
z%Kh@y?)ck&%=Ei{^>@Ci{k`6AeO0`}6F+W0eANZvF8HdUqMQ$USN|9N>R<I$`>s`t
z0sdQG{awHMKjo`N*yPXlt7^#p&R2!M{~2HXUB5aU{(x;s5{}o99;VlY?5m=_|5d*#
zbi$z{`qdnjfBEWE{QWy$74kUxP3~7;|B(MVj{H~ss?c$R&s;>DvsJ%*Rg1s>ldpD$
z4DVO_|6Y&y>d$8cH@xQ+KNImQ`qfeR-49<)KfCDP^{c*tp&`LPo)_xM!_|NHj3Dgw
z&p%4J?-ceCebDco5k!64KO=}SsS&J!v*^dt`%a-B1NM*l@Ea6>Kjkr!8ezdALN<M@
zE5<)R%U)0+q-fcXpzP`U;{RIN|J^gjpDFwAo-zJ6%kBdEiJwUPih3V|-{UB|*7HC0
zQKa5~c2mEtdeIO4nX>=Cs`tS^#=R~Wi;ExovY$cO6*c~=vj3~9m&Xi$ru_e}>c0Mu
z@*97YzcFlpu1XTmjSo?N^Y6-!N4zkdpTB5OqCRUO{O6zab}XLd)VP@btdl-IZh^mf
zyA*BkXI?6Zi3$9Oai_R#*2M2K<V7j(n`UkBzsO5^pZhB>$I<57XYln63<(X!qn`Xc
z)ar*_Vt?dCbPJjBE4s$l$cyfGdBIRAD0nD3K>5M<9}l3yMo|0B&#%7D30KqaZNJY)
zU6*uqo{#js<jf|R&HJCuN2MS3i20EZkyk8bL;Xuq@zUrYf7k;Pf<ZN^r~5^j^epp#
z)nbe$`ezkF-p+*|RQ-{b3hQdbPdWSwKPZXc(n!ln((*-({rBnpybu4*AAgoP_BZ(u
z=eefug^@5p84@INA?o?RDf6GnL#_Oxl++gD{8+8LA4kr^p#SYW9QsWjM12_T@*pzt
zziEdu1=8(c?|;>WPyEP31nNRa{MkJ4epdM3&w5|*o3v^nt@Q7PO1>hkzvAn^OY5hv
zyA@0?m%XpoLt5!)N&QUgulYJp@6Y&|@i+NUBOmGCI!@2WU-7g5CJ#9Z{c{~RMjp)a
zxmt1_{!*Lgd9bfz!;iG=?cNM&+3eE#-!AXB-;`JQnaV4D>;XR;BntdL;nRB8-}{-?
zKCQpdhPiG3osX6K(XYSwkq7%WTo5-BV|pG$clxKx`n&tb&vZ0m5Q`uCbXvo%>E8{N
zkj{VKSK0f}q2Ht<?uqH=zRT(SC4c>0nLZ#o4QzA=V|1lMo%iQEPi)+L`r$h9rF&Ul
zwAu5>ujzVKmj!jZS9!c^(}2ksx8t6rbZEA}tLNvW@YLYiRR)HxZkB6rM$_ROn_EkT
zQqN@7R5^wRyMV?*?oFAPjR7Berxd7O_Wr(g6YE$H&MXu&a#xoL(N*e?-!b1JN$!}K
zQ99I0o3a1M=&vhB_*K~1{99Vh(FyA-bqlmaj?xc}aT~hio+M3><13!0$lkNHvV0tM
zwNWl<!~8P-mFwh6^$ebqy<BOJ$h*^{CFxu}5nul+lV(ZVs+Fm{Ghk}&@qzDl-_u?g
zS?X?phbAhvZIeWlHBC-;agjof&1#>ok+*fM<FNCU$B*uG-qI_4M#pAzx)rK=Fs>zz
zWx{|}=`iJ(f3~AzPP`d0{N0JWTRs&0bm&W){mmXnoDbDRWWOe!*IQsvsdQLSF}wcN
zn1X{}dVYJ6rOky430^ICEst~f*wJb4A7jfb9wA8`<a8}V6!D*zEKB^Hcyo+z_xAOl
z=YDsw`ytnwZFTuv3&w81{JBvsuS1uSX%07vZ9cUAOw=}yjc@(h6#p_fvQ<B?$yXZ(
zdrjOUNgL((CKhxIj7V8K?CF9xe=OT{tk~h@r`*<F9k^%4y|^pd*DoV5zQKg9(!ssR
z%Fx4GT-ps<R`x<n_BlJFKHo4On|>sz=lou$i<iyu8e`P9Lay$VyR%>2dtBIg!=bEA
zu0MR1>%xq4PIVf12Xro7bX@k+@BuaY7Nx_};eNx)weGOC|BC5LM@)Ae+rL_uFl*h&
zv7I}FniifsQx?zoa{iVNK0I#kuFCNV1M9|zj4t(NLEr>855JTlx{=2pFBs&A$=Pgj
z{yMI_ION2lo1+x1Bc}`sxOL-sk&$mIu4>))SO%B5sa-=bNF9qoyV7BFgMigbb|r;R
zuhRNP!z|tFW#~J<nziBbz!K%#_uZB3odfS(P$^1>80#m=ZFp<1+uvi`_}w1Z{bX3+
ziLi+kVs<9<vUZP%)!}H28bZ!3)-tmA>=SiIc*a)Q;n(b2?s{df)ww(`scetTMf#kW
z)lHJB;yFg?@S<<8XUG4j*>7&WZvBRr*uVF6Kh@-vV*9+pzwCIi@mTfwuru<gbeNY^
zFje38Zkl(i!?~M=oSL~f^r-*h4)rJa_b^{w6jkP%BxP?Z<Q7&uUv%oH(rw!(Y&zJY
zwsUaKvD1fiYSUrN%GtNeHOn+EN|M^jb}4yz#p<Q==6c2_?V1@;V9DJN8MckZ(ci1R
zx>dik*mDE?V1w-UGd)*UOq<rWb4dM*SH3Usf4F`^>$Fp6P8Yo}C(%}E?6%^VE0W_&
zR%ow`EwWr27-wtwr9$>E8E=of)wa)(Z=)UDSNcCY{0GL~vOhO}zqni;=O<BHs_vMx
z&2>Us)0BH-PWHLn@nziR<z>fhvq{n+IlfAjN_X)7-ps@Eqr1}m+4g&rqH<?#FlFoG
zG5fZkOHfwWi+8KCU#&QDes-4U14fiPwWD*DhWDRq_n$1$+oMg6Q`yd4-6Gxfm!#d*
zgk4g?M;NlY%^ckBR_vwNT$kHzy*jjcz8a2ASFL>T*{$!JG)d}QN63v1&+|}Ic~3&^
z9E)zAP0qY_t+RId!hNZ+;hEK+r`<k*Nv;oad}HT&RZ}O<uht`a)uod$VP|TjERS5-
zrR3)^EpDy4vNi?jE|JR-GHc`A{%hJdA3Gs?=B!r=CpA4VrerN^+gXl9TTN-?TV(@|
zDfbfTmNv9AWUUpxBG3BE@eQ|M?^|ekx3$eZj@`dH=&H)yLp<NEmGhV4we4-y*1e>Q
z*#<l+kn!Fh#~uWH&89fFDYn|c#aFj}fWK6d{a{P-A6*8Ad%bM=rfcH%M%{N#xD-?M
z>i!z4emi=s>$c<aGD(^%_d`zi(;{E%lgj7oU-RI__KOzizZ;*FbGq|j^sxaK&pXY#
zjD9>^<nQ&6HaTLim8o;|_UQ6sHS>bLJbAX^UdPcBPHJcG+`S<I56Y+I`mNe+>-3Lx
zyJtPpwpW2Sxl?DfY+9s2>0_zk<5Hhkqhs<-#GGIQ5nt`uACgOtEPA*5Q@7p|s=c@u
zAKujc!0aU}4ejPHbuHOu2&V9A3%SsniZ+ubHOmy%DLx>o;Uj(dri#<iEhFP^FIHvx
zpsl<`lKeb{T+y&LMM{;7FSNe%$ieOVj+{D6-?qZ{kBMH9XQ~uxRAfbxcoq|KFN=&x
zZ0mk*((EdV^(TF+KAJo0OhEJbji(KGy=+gX#13d{hh+Pu3?Fkf_;bk)n%$Xd1`eM(
zuHi|`-K~mmB^{gAAC=H3t6q{?%W_-$?Q*R%_u|nxxi^@Ojp^KA>dTKKPefnH`A6%e
z2QEE(Ge?q^$#M}bx-6};Bj<u8mu4+nv8|#@XiAyMHT5@KB46A&-Lt}gzL;N^%dzB1
zP34!@a~|As+Pomid0(|&+1IAJH;dZ3*=utJYZr&xlC)EnQ?443dT>|PA>p}t?7UNP
z(B#LXbFH+LPh4@Rcv#3`k5XGDsg>-f6DmDe`Fy~rT6Ha3E@rw|Aj9hxPgj=hxPPMi
z$|^a>mvF!&L9i^>qC}s2P8l7BB<3i#I;fWM+v`ws$1=@#)y&c;VSj4Kcl2wm@Jyw2
z*yMDeg-)F%dE~t<x$B(DTEu5wu2GGe4D&wtqM~I}<P=BD#mMFTHgV&a`)f8nnK&}r
zfxN{^4poeN{ieeG$9cBwPyP}WRU7y77IMGVeRB0F=4j`0+1}^5l=3v~)P@cHvXt=I
zzoz&6+cy@y)4`|2enF*!t!|wyRf4=-I-T@zdg=D|RmVM%*DhqrxF;>8;l-7U%2$-6
zg{_6$>}{V97K;2h>4mDZf6K<zzjfJkJ$T8pRbkCa*L}Su*|jIukjUk|ADg^BHhNdi
z_DMZzH~ctngm%!dJ-55RYNL96`kt}KYLvqu_b>msU;BW2y3!$sQ?mw#dX|WpT&Y{o
zs>-VSE*I*>uFvZ5^xMYT<+?4XxJ{A{%JId2{ZQb&<>ABB4&&=w@b-B9>~3T|_0&h_
z^SkXFSK)-qbV<4<=P#yi<<)uOH)h{>`$XSoQp%_tH47d3v?q7gDK(~s7Cvwh{lP0a
zzCQX+9a^3$JfQ22q^w736!W-NJ$ggjv1vt}E#(H*(?9Kqy+F-H{{FLEp>{&9_guYO
zVu2k)*Da3gn&vdZapJXach6j}9Dgv}FYarNWs#E9NsjNsg1~hJhhA+p*eB!r47Uo8
z9RAK{fAjY@o+k_`x2tPxh1rsHQ!V1VUL&Pmk7J3&=jL#6G<zF6ZK?a*Gk&_^aow!f
zBf5V~vEaxg`M%mZXPslU5;o5|dtZHYN7j$u*Pp*~Zu`6&UTr>Qn|&`O7y8J;n5$7b
zoOhibu&&`EgUaL5K2w#7Z$2IIRQM>y*ZTHJ7uv$J`A12*g86c#L)$tVmLAHwd!fg)
zv}`F6$A`E$_N{Vpbf<+g4rPw@9a0W<Db`HL?b(*6Z?}gn(yGlIHpMTgYJ6z2=c4#R
z8BEv84chOryh|Ib1(C};dVH<e`WdHqSW{i<JYJ!G;N4ZT&YB$7HLzU7-K_=t;a=`3
z=db9-wNJ{0yj!w$L?*u+rxj(+ZQK!Bds(*?8?)ufS=jY8<aWt&xsOiiR3USnz##R8
zPTF@Z=6Da>`8<PvrK-lH7~}9;sTbfca=J5W&O6g5-{%^QzdN^$xi)Ui<)N={UTIRP
zs8oK&{7E-!qc80*m&4^+K+LC%?`pT{+~w1_Jd3-2>*!r->k8G<tDkN+K9{0#l%&RT
ze?Lh-$>q+w@xy$J`c4^jbxTCXYXv9HTD>+rbJ3F<hA)pijJ0=i{x%JERpvW>qJb?q
z?arLM>oP|<Etqq5%e?UiN)9YJzHDQhMR7qR?Dsj#?uU~vAAVQi`>e_LM$9Pb^XPEt
zLf5bO&S{x%p<~bT$1&cO^LMFXz&CT_SzRg(syH#zs@>UL^&ifU9d$-`cY4{Ei(hYi
zh4~@5zfTOQR`C3dm8P}XQ{HH8jyVS}-_bNz(<6^Y9EdhNFXD;&f~S1{n33u_JWjRe
zYTc<%KDj>L(zpLbt2V4-;;gI#qiTA$RlDK-E88z1&Jy&!x@V#2*IAatZSNW4Fg0m=
z!R!l{PZ(k-zof2dDfY+7<DA1$j+fh4QfI7Jz0Ll{=WkDc7yM%VxH`Fgw*<9SmK@@W
z`$t~+J{^@a*T+jQgZ*1IOkB1&e1*%9faHKd58w3qSm$_~>37BKsaB3}PWa=_)3giL
zO>Gx6G}U8Q%UaDkr~^KXDHZsz(}jel`w}GSsyvRJe(L6?1K+*9dUt=nP8X`az30xX
z^^U_2&Fyw>rty-KSlcpIjxT$&?Ey0rtZ~;rb($TxCEvJ;NBnC$4nMzO<CcQ81NwK4
zm85?1{ddfez19wAPgc6P=ve%m_@xKGImGW&o}cz&>Zs9cawV-teD7sH=;deG6V}c)
zv4Sc~3+aWWaDzNoR(hP-aoBO!>nD55%~xTsbv{wQQ%0^|Rm^>S+w1=AhWAo+R9rp1
zC0m~G7hNhm{WN8x>xuJ{6oxV@9TKna4@=q6(02J=gG29LUJO3-d2E@u{KZ$?&YFCn
z`?t+E(2dLWmMOF6j%C_X?R=jvE;f2c-J>2y3T#f?H2p&Hr|o-<`98}X<6?Q7b1GNf
zvEz~>Cw#7?`5ta)-z`j2(S7ys676EV4wjnw=>_`J+H!sLam&~-CZ@`G&v_>{_AcmE
zY2>rsDThZ*zcqRLn5jd)wS|u!ko%WnMQdFexjC`X!FLWv60@&(P}{w+)VImuD{q>2
z4fgEZC|QyQ$oboN$?3=>$2E%-4Lz=JeXN?TY}fp1$?_M<UCEidc+E-m`bg4S*)F$V
zS^RAt^)9==u4c&ZcX?ZZPCd3B%&<D=c;EdQpMNUwRFa0v<w#qeIQ!Y&P2&?jFDtq^
z*Zjk(VHsYGsiTi>;IX9LiiK`|l5|#1_hrY1=lb=D{C@oM<{`-mM;B~=7&mlA`)eo5
zJP7ih(7gx7;}XVLN{2r_cC@`4CT(5ndTrmXmF}7Lc(?jy%j22JR)2WDW;Pq@!clHV
zmtvmu2|nQ5f9c{|-)?yKO8Ic;?JVocn@?YiAGWf^<$$&D13BH6JIXAHEq|%gv*eVa
z&+oeSYLGH=b?tVVht)b*C$w!f1GXzCr|WgDZk5#;wz@<eYxic>`|UZl4V~TY!?)F!
zhTSMo$u-y4F_PpV_xA%13`;opy3g1<ccV6!RkdAJ`NOM~YXVZoZ_MfwSxntCgCsqW
z+hu%>^+UdmP5yrT;=Oq#;u3qte(w1_Z?m9X+gqjdel{T(ZKJas--^#KAD!LpGupH0
zl(e2pp7hz1cDI9DwXB<0d>Girbmt=Sr;zPD-syXTtV^{S+Sj<e^G>6l6DPd9Rr^8p
zh*w#X#+O-^CGrf~ksROB)bU@MHPn0z^8e%D_Du`F)R{Qi-K|m0=TDZ#^p+A<!*=cD
z@+QQ;bbj0;W1{P)NijXDl#FVTYmk>JF=chdmRZX>@0c2a_qs@1>Cn_M%6j5MkwP&!
z^EIB>z;&ge^r%0EH7Q(r_@slG>O5{8B}w(1h1~vrTSm5;*rA{IsbXs;dl#C0#H(9h
z&kD5zB9_J_c23Iw5}%%u>&<;n7SsByeHNB3fA0A=&${jNt<LfAY<6GQWkbqWPSfm0
zo!#~n@mZzg@rh;U7kXQ)f74Tb7r(S0?{eqGb>oo=<yH^!d)e3`Nn7Od&OGMwda3uT
z>Al+LZWma#>g08ifx6_?kyBSx9=|l%;o=IcO_Ag4KCeg4BO8Ma1qR+Y)NetXg<r<b
z?zf@9lU27<hR3CPKFx_^_vLo}EIH%5GV7mizq8Y6LED#gTYEjTbbM7Ty5bz|9mf(U
z-`qlZF)yoha6IYkdFRF9K8DUx?B~mk`@g!nyRfCp0ngSaB07KDWa%ME%Vj%HzhphV
z&Z}+D$0ZvK>G!34uFzQtlas4XyZG|@#1q~Hya!`EF3Wwg%$ua2;J&h-GNoB}uZ7+{
zW`uumZ`FQ%wXUh*k)^Je$9p$fuF2uTy9>sv4rI4B{m`np=j2sRpRc#t=TmlqF2X6#
zw=_N0LCEz{GqYc*z}*{<Eoj(b+|AzW#|3>^T_B-<ffZGP-8^Q724O52F2^^tZ{nw3
zX-;qR`l>p)#4j_RpE`ZSMrlmvp(Prf9n;$gKh0Z9l(*f}{5!9-YkKMARi9_OT2$N9
zx_aue+6zYq-t3a~)75=nLUBKm`{$;PM_U>*)y!cn&@XQF)o+m(pHv=kVXDD2==$ba
znfEtwlBCM=c=CGa+<aZ0_breRzQ^%)^uV{z)vL!2oRV~W^o3W=cD7vMg7^M4M7jeM
zFKrs{X~CYsOM?5k&0jvwq*dm5>R+Y(=cAT_<t7)Cr0#NjXYMWYSbS((Hp8S>&dPUP
zwNXP)FC4L0<<>sKxD#y*b2>}XUAcZ;0(RA!>E5wb#EL@qZe~qPa}Jt+#Z~J6ymlGq
z@%MK|caWs>a(o@e+&WY<&yB^)&c(gjcX4}coeJIsvVE<0zuv5pMMs_J2j6SiPULU?
z?%Q`tM`u~G_HEeJt81@B4%yvgY>s2=@4DByQ#t3C5R5fC%jNjb<7d}aBEIO=x^)$%
ztUlds(jcsfpESPXu1;Nww0P^-wLq=nGY#8sOVSLDko$hWMfMYAV|pIUQ?}2s?&nYL
zOe*k)`COk_JLk9AFsIU^W0G`I?l=5Tm53>wl<{bX49nJh+S_F7wTTx3-*^nq__9u~
zLjy)W#CWZ-obHl6<xZwFn!CuY(Cd%Kc0O+yTk}gMW#^=*!G}|Gz8dm+4W6T9xe15k
zh9BOXuYS3P(dBAsm4&Nq+VeD6Ib^{(+x$`=MwP|$V2qr<Tx&d)Z<NFL-mUj$OWf3Q
z&x>3yaQEu=iG^nm`}!<y-5C|$Bg%GOedtEwtiX$J^~00$?>Vt%=&-2c(GKfJeR{Dv
zbHBws_0uJ3vYhUV8Kv{PJd8c3zoZ*FGOdw!!%<};^Q{bh*Lq>=$J2KDevqU$a=K3O
z(XX=S7<>5Uv#+a{1$-*?F}mcQshV=fhM((Kt#O%sOC)KMobK^wbNf9TJjVF^&L^MN
z3nveM*sS5I&9~R&n$jR@-JJ2o;LlOAT(RBjC-*&3Xzqd`qvx)T%(W=|oR{mwdUrxR
zKWt13R8<{|wL$WD<H6%`rSt5MuMj<5-J*I}Cx^=e?-oC^$?N`>=)33K1I0I>T;zV^
z;P#er-V?n_M{3#~yYHvZxc2dZM`uR7b-mwV!ig%Yc8tUL06wU6cy642?R4)iA=kft
zORJ`CaU#wy_tM<8kM(vmdnL8i4q1$OO!;{~GA{2MU71DMZ+;m)_sfh$6TF*!*mtPb
zfH#%P4Okv`M2-1~PqO`XW<OS9h;!EIxpZUZ9}JeJIZqySyXJ~Q5r!uvZq*#2+l%J~
z^a)Cb71~4Brc8SK^5QE?w}2B}$~;(m-L>uT`?{@`ZO^1k`Oae94%#N>o3dYMb85Tt
z;=OwJG9JEv^QF&&-Vc0yTD^@{>dKWH+GQlxf6D3lcGV?2={(;KHIK+TLH(+-`B??C
z*6+rIw1|zBYg8SL`UsHicY46SD1X<g^-VigCbqtF`Q+zbJL*>au*`jKMBw*Z-VM+X
zU6$i3+iY(4JR^s0pK>Kv|J1r?UZms+YifPDF=AefU&)gPIvvO7l;rld$9-p;!!eE4
zgau7`KXc_P&9G;#wu1gnjn<Sta(HegNA$Zva{E2jqsJ@%a;A4<%Ac>(KkP!8u*25_
z4MFOa^9O&Ke{aVz^jF&oi}F^vHzX~3<<R=0JvUe0aD2exKI1x^9ozE$<+D<D&4CR&
zAa_IVC#5st`^T^GsPy#J@uCA>4hXurNf%ggLXNj7n=d6qE_cAVX^?E^SC)@U10822
zY^ia5VPdP9s?&i7D;1ymD0W?+Eg|>D#z|OfCXfGmS??Im>3z!XD^<gCEN8i~ik0Io
zN0;g`{`{V;&igLDEQR@T*$-w7%j^3ggZk8sR#`8HJt`gYcK?8i`yK1_+!<0bNAqf5
zmP*ofxx7RA7Fcv=zoJ3E*fEz&-(G&dW{uo_eZJ20zchbJ{R5lF^}#q>PFJ@T-(jxP
zIlS(^%PUpSXYIN7t@XpBB^+ElYwQSoexTTV%rl^GQ#zb#H|tAC=5Y@WWePt$%qP+7
z(U>Q#$`?C(d2x@h;_og$#aPJQO~@s?hnHHL`QyW?y<fYBH8IYwrs}%-=tynY?&vp4
z)7~!Iu?|J9w--%LhYo5K7W}zM(_Q`@?qztqJT7rew*=*!h)=HTkMEd^_~i2b=XsE-
za(#>#=w3>{*x)#A(*8o7D~_KT-_UTyIlJ@f`NyOGm|DKqGfB!Px3@1LYZ`nT79A5C
z+@-j~)@=J4ZGUssq29hFVfEkjTA)fsnw{kM3ZCnjDSx-Q6A#r`k!^OD9xiu%hDJDg
z&+k#7!Kp({dvwuC(r8)koptUcxBA~J7aSMwVEou8?s?~P6Q0kkUSo-A@TqajjTj5P
zmHX!+FE12(zvJn}jiUp6$86CS2)g`YjNANO9g>0@ba<UF=mo|Ha($ROX8JU~ZIMx<
zqszt?X*kdFG{QZpk9o&c_b&^MF4AnreC$EluZE|34_R-FTjA#1d*HhXd%TM7ifU1_
z;F{)3j|Y2gulx?<oOQCDpA8IqyJhF5T|N2~T^!>!Vei8sAG>WkF>~wo+TX3q!we@S
zDMGGaTTI6-M>;Edu3c7mVAhElN1u3oX5l-pg2fm5sZ$fDt%ponQ&GQJ&Tsb8<js<L
zyTAY`roQ+7O6zY<uA3U@-zD6$^rfY5PGNqxkdWIO7oK@Wtr@eO9d{X;J!t=A!ls=O
zwo>1xKOMX{YDnaoO;|f9KTog8ezaM?U7POI$~I8{FtWkw!}sc*ntQHWt>tz4^++o8
z49_TE<?`P8yh=KGyYgDk{uj>nof@6wxO+mr3VV8~wgi^SP^d_m=eS?W@kKw9`ZQL?
zSo73E*=C$~AAhWL-RO(nJFYDLG9~rM2qVfX`>D@oYt5Eb3oKu?xZ#7Hs~o0WyS}Tv
z;z0Sb4Jse*A0Kt1GsdTKx(AcJYG1iktx>VGlw|8py?d0xFTw9~%Ws<Gk%2E}M&p^b
z4CYpp4#x_1x0I45KilADGgtJi_Ud(TyHk1V7F;xD#?0>%s(dhD-cgo|_wjk?q1N5M
zc;L*uoY&$O{ZTJh@zj(v9?i@(TWVfTnu30#sEDswn-)zQb+x+oogMMy>c@z)QHP~Y
z$42Hq7<$!x((+beA$T5yZz&y|4zDQd^D^zuxq@Bttld>GR#)0oyj$!%MI+VQGsRQH
zT)SA{t#nXz&b6!8rV*#3&M(QlK=rUiuF1Pw?p>0xd6`);YxS=8i$D%z1iYU)*kRs1
z&zWwcEh`;b)b=~kLUkl{@h0=wV;e@?TAQ*l3iH_ogxrxAX)*Us4H;bGy>FudL#DPI
zex~^IEN7!~sHO~9czbk)?3foQDC9b-BmAR3ce;^3K-u8)&`X6@SJdn{P_)UHi*3AW
z4!kpVH}*-$?a2CNm2cxhjr>dAKiVp|U5T=@-z;~^^0wuhK?}F8d>x;2f+Qu$^9MCj
zGaab8>5{t5zDjBP*G;azJLA$2$7LCcZ%gPf_u~hT6iJHBFVf97EHyUQ&XNy5R-bma
z^7Tp$PapJ1dS3kLMxP4fT7~9cumba8a(yJV30^VvdHA<Beu}zPPwG1F&9ie$^xVX9
zeO~l#=vzA)b+Jm8Yfx-#;@2y>c~e@RSyoQDAnuR%Q_JqSb!_pci{TR!t_UBfF6Zy%
zq{mstr`C(F`>2&^<<OPh?YBF8zA<39w&L0?^Q!M``$3Z4!PNcn`(wYNypPf1i1&P8
zKKK<s7qR>UO<1~w5N5<4Pe~8Am98Kxjqn=6#t5$?MAs|bM5sl03t?Y`cM%36yoXSv
zhhf;y{f6>hK9QaSm<N8v59ZbMc@cI%SOH;2gg^Cu?DhLgdbSLB5Bg(&m)L(N(i5(T
zPtMCf=#KS;@qY;jD<gb`ur0zj2pd5r5n(HYHiW(i-y_r^{ERRXVKTy12)`oSju6$Z
z-+}Nu!kY*)WRUca5IP`yjW7#BDI?atA;f`sQVxV=5#~aOV-ax%w4`r{Fb~2u2wf1i
zLs$TzFT#Qd!w|Y69D~peA&yRyiXvQ!uo%MS2;C7zA@o3KLRbpnafIa&UPFjuY4wj0
zst~?KSRLU9gf$VSA*_uM#}P_i2=OUpsUE^mgbfgmMA#7F41}<e-hi+P!nFvSBixFx
zCBowfVLQDQVOxaB2-_nphI+u6T>5ed@i_y1RfL@pR!7(cVFQHS5cWdY9icBmZ-iqI
z_Ch!gVQ+-f5o!@GK<JN9?5o6ia<adOdjGL+P2SJ;SL(e5bVa>u5Q=&aKq%@x0->n)
znFvL_M<EpTz89gW_y5D*`$xw;ZU4iGc4%m-Lx%>TLqkJDLx&Cx4ILUfG&FSR(4n~+
zItUF79Xd2LbZF?%(2!gWLPLk<YG~XBLqms#hK3Fe9k-#Op`oGSd7Zpo`8<8T%d^(^
z`L5^Bo3&nR&pBtGefHV={MhHb-!o|hHGcmZ)cCy<)cAcjsPX#{*wy&`2vFnqQ$da2
zCxIHjUkGaaUI1$Reg){^phcj@@5bN8?+<_)zvJJ|_4|D#sPX%ApvLdU-^TCw*Vg@h
zkAWJ$e+_E<-UVv>{yV7gyYcrKp!gZre!m|9YW#j8sPTIM)cCy&)cE}gP~-O%pvLbn
zgBrg#f*QYn1Zw=g6V&*9F#KZteiEqh`{|&@?`MM=zfS@+e!mFx3eX}@<M$gujo-^b
zjo%*vHGaoWP51k~8r1mRd{6QJ;dg!S$b2{Kf5-2aXuh8hKN-J6*M7f4X20J{K#kuY
z1T}tt7S#BC4XE+^zd()Ow}KkKe+O#(-VJK}Zh?J`-wy*dem@!1_<bU%@%#Cp#_#!{
z#_yMb8o$p5HGZEDYW#jLsPQ{~ny}yRPlFo2SA!bAzX)pl-T-<$==-3?@4tW=zbC^V
z#_z*Gjo%LiHGapxW9s)iexAJF?-zj@zt@5qzrO-%{JtL4_#Hq0-S79$L5<(P0X2UA
z4b=EO9sV$WH-0vLH}lx|eGaJcdoif-`)#1c?{|Y5zni;s<M-!4jo<O_MEm{z5vcKd
zJE)oO-+>yxoA3PX>vw&hs{ead|6lw*6@D^)hc5kozX8<D_XVKF?-iiN?=ONHzpn!|
zet!$p_<cL5@%xXU#_zqL#_y@HyYc%mpvLcJeK&r`zXa^}`z4^p?^l8vzt03Ue!mIS
z_}%#1_#Hn}+3)u!K#xYc4%GPlB~asc<8R~l^`OS@pMV;_{|RdRJ`{d2e#gI+?DxCz
zxAA)>s9ERF1vT^ia!}*<)u6`jZ-5%VZv-`dZv~wU`YovO`;VZ;?}OkE<M&KZ<M(qx
zjo-~YHh!N6YW!~2Z{v5fejC4=_1pLz|B9pE@2`Ryzi$CG^Zg4@<M#xp@%zu9#_#6)
za|3>#fVr#hCiQ=3$@m>?{l9HsimpQZa3ttV&@9laLGJ>+PH}~)ukZK#AJ^A+Wct59
z^1su5;D2df-!u6?s^1?^@p~Fc=RvM%A8tt+4VXWKwf*tizd+AM`gPEOcuL=?=>M+8
z|61=2@C^h1o1kZau2a2H_^j_gnAZsU+rw~A8UdKUxA)=G_Y?k>uUULXe|>+T|6R=u
z@a?|(j|X20cpRWdgW@RpKl<yt0R7()_+RVcNYbzWnV=b{ch)}j^zQ!O*27rouZI}7
zzaEYw|I?n{xBuIEXrsU0@v3*iKK1mD{NL6?%-LTLcIa;}d!KrGul;ZB;sT$s%LSmu
zE>rfYr+3u<w%%;jD^xwi=Ks?_y>I@vdKQ7tjE5UQjXiJNr=H#q|J!;vy7t$@v82Bq
zV(b5DPw#a9t)A1sXZnY$lK%c(x=%g5pZ&M(6@bs^c{!-j^NM}y>7DAoZSP9(nf9&%
zHTImjPd&XK{kQF113uH<EKt*)Z=ZU4r}=N&vw_dFcQ~kNZ{$Ap^p5i1)*GdIcGWv}
zpL%-d_;2f-sCp-<9?n(^x9pE~(u*}2m<KEcRs)-W-N1;ev9tmUj!RBj3akXy0vmyC
zz;0kDHl8uSWMCGs09XpF1l9pNf$5Mj7gz+W0M-JVft|o$81N`y954l#3CshQ04srY
zz-C}4FnAWu)4)VvI&cfH7<d<($qr!X<;h9ofKeIAN#lX3fZ4lNfM*S`3D^k?fs@7p
zlYr^K9AGi93fKtj21Z<qz5^>hhfRPDz)oP~7MvY1X~z7By1*LnOhDdrU<t744)ik#
zeJVwLU@9;NSOBa5)&ZM=y}*b&p$9M(xCK}WtO7OyJAom0;oN)%J_CCJ^JTj+zzpCP
zU@@>9cmY@kYzB4$L!9UvFcX*utb{%rflc_l2N-!KYzWK-mH=yj?SOgiI}w--ECyBs
zTY$k6p(ijMSO8Q5?*co4p*g4n%mEeyt4;cBq=98X(mBurSO}~HHUPsXK|f#)unbra
z>;y*UA|IFwECp5r+koNcA|IFyECbd9JAe`Ap)Fu8umV^QYz6iLM@>c<FcVk+tN_*l
zTY<g6Q7)7NGl2!b3Sb?u6-YWC`zJ63*Z^z;_5#ze*v<o%0`CI5fe~1Ex8|W77<D1^
z1ZDvXfofnqunpJ)jKpF%378Em237*=ft|nzERf@Y8NdQyC9nb52@J=gIS!Zx%mtPJ
ztAGu_Hem3@7#F}4U=FYlSPrZPHUQgzy}(g8=!^%Z0&{_-z#3pPuoD=9MRyD^1(*#i
z237$ZfbGCuU~w{ZoB<tyYG6IE4H)8qj=)r49<Tyf2kZcbUx_&a%mfw!Yk)0)S!~Ax
zGk{xw6~IPdH!yrA`~yq}wxP}8`yuuO<^h|3g*}04YzljU7m&9T7(EEK2Ns~t3Scd;
z8Q293_d?!X=oesqTYL$q`EK8)1*j81`@rG@(e~Z&?LE+UFl-4_?}3gB(HGF=NSj!7
zFVZgrAs3$qTVO9>3(6-z-U@skd@tGsU2rJu2D&4TKKzLM{b6_TECTl4hjOGxflgQi
zeeiiZup5|y^wKfONka}m+rV^S>Lak%PpFH}qsyQN=rmCLyN;w;pc_H=0xMB(4P=_%
zei;i)1U91_|1vgd&R3W}peup(z;<Bp{b&<(6zDi$K6q9@?`7DWUI5kt=0b2duze`X
zK}VzCD?!%)J5XoONw66{PeePLK}S9SS-_@lOVWs+ElIP1wZQ0KEJ;g&y};bvmZWvS
zaQt7>*}ytrJ23QDOVT7@9<T&h39JJ)13Q7F-z-TZfpNeTU?wmRSOTmB)&d)W|Ni~o
z7Qoa<`s**HhvV)R8Rk3LOMsn6!e2)xB~=}cIgIpMC{F-2N8#=lbQ91Dv;hNu|3uk&
zfD0J-TZzxLz^-F(KMoB1J&(L1E5;J&i$E!GC$Ipx8wdi6fCqpF0rR&Cv>tc`SPi@i
zn7{u(hfd%Tq#p&sKsnM&fG6;|5-@)|k?sP10?eQJj(5fhNlE5=yN{xu=KH?pyI{}Y
zv-uwFW1x1>YEbi?R`cD@r9cJnJ#;tUF%9Fh`M%p(_-wutxg2Tpy~IjT^PRybLCyE}
zo&wDQT><(y@C0xwVC-$|Yks@J{8q*5$MbhJE=E}&^!`)28+~uU=f6xk9rp^re!w7L
zFkk`p2h5@B08sP$LPJ1PfCGVMq^ANepp6%SJbZo%r~=I2#h~Ur@yh`ZPyn9Gfh&N4
zKa)Qh=mU-eeg=8~^EU=G6BrAe0-Oq%zrR5DgN(tz{*rY*@?7|wr}TwLrvM{>>CoeH
zU<NP_I2AY%I0-O+r-3?vGXSUZJfOwEZAxDSIuq~$R|7s^Ht-_ke*t_04E(La=ZPpg
z8!&&@gBAfdDt!=aHxx((P64uk(*OrB0XP#l3&;V^0gQcf&1cZ_Kqmv|15<ztfvLd7
zz$JkB8wPqXFdRq&jsT7Xjsntwqk&_9QGgwI4swqLHNT^E9O!5u12`Ty0muYS0<r+}
zX9Yb3xCi~Y7bpW30}lZY0~NqB;BjC%@FcJrvR8mU4O9c>Z{K={Lf#0#1{?+)4w&Cg
zF@OK-m^S0t{9efA8t-Oan)zbJ`#R*C-%+{r|E0|Q*2WB!{RmzoHxucxz{x;1FdjGq
zI1|VL&H)DIlUc*gMcM^S0WJbA2J(T+fGdD2ftkS7z%{^Ztam=pYk?zCzYuf|a3gRN
zPz((G4YXtWQGtB(dznu4!~8ba(@56<ImoL8HU2Vn%y01gqW%~j^V?)o#AANL$MBfG
zevyG^WWZOz*FXob9rzB|0sH_A*wU<XKO+4T&<*ScegpOZe*k|1`=K2RkOB+^%8$jE
z1GNHc;g1oZhXY3dM+0`i{0+2W`neo==C?J^Qa|hP+58URc}TAUHGMSvMt@Uge#`12
zm6^VovhN}12f)0)Jsk1QRVaS|@BxF7P66)5=R%+eFtXxCHZWId<ELMdo{w}8xJ&t_
z{UGx11I#mEQ`gLwPNYkez7_NxjOpQ!VFeCGd#S*I!2ZB6U?^bf_UnwgOMuf=|4GQ(
ziS+GC-v;Uh76aD-3xVqaQ~z7=C4gI$Ha7nq=~ATc0|LMz;KbuFu7Pcb!Qg6p1on!D
zP}aYOpxzREei*nPXa`>^_=f=p1H%C;(1QH^P(K77)3>{j{t31|8#@05x*IU|XavkV
z=dDQZ2fji0{0w5d8erh>Ief0$Cw&%dmZP=6@SFn~uOS@)o&)^A&A`B49X`JaA3p?y
z0P}Yl@(O?}fGdH4znAd&<$cm?@VOZBOMrpD2IRdCyaBukyakv)6N`L=&mRI$fd4zB
zcc{Jf$h!uZ1zZRG12BJYgGTjv6KE^&iPEdl=hyb>_dA$7?*RjUZ=mcgl}AB0=<|o5
zF?~K8zBmUkf0ICS^?4ZdI#{~3f_Jm{+d;q7=Wjq0`kV}%21zd?YbZV+yieMU&x7GZ
z^B&y5-*2e<yXu>~L%@Hi>Wl!j?Ni@|dWY>(*9zSZm3~Jc|HysHj=|?qO4}g+@O|1i
z4WAuKACCG1zn66e@|?<dflkrqi$SO9^K{SxefEIP)aPqK3-x(F$Q&%aOrP#S{vwqf
zfczmUdj<BGi~O5ZW_ah}^Bqbb1in=9K7_m_%3lgvsm~_HG4Y9s3rvh;=*5^HCRQ}@
ziHRl5@7?T+I;39&UIJDD=C`2DAC5)l{;vPdeLUzCU^=h@*b0or`E>#?8CVJI21X$U
zH~+`WJlop{j2MJ^zzkpxV4kT@-5>n|s)5zOI$#5^85ns0VliL>Fa?+a%mL;D_$kh$
zIlz2i5wH}f21Xr(IRcp9L0ka53v33q1G@p!k)gl~z%J9NRHT6kfO&|p6j%Y^-y$ci
z12zF$ft^6oFsx6&Xka`r1(*Tc0xSYn051S*fsMcxU<a@V7<w?`AYdFY378Jd2Id2c
zfofn4uo2h}>;laHBQxW{_-ZUL5tt3E0nBfi%>d>ACdOF@YydU`=KrGY1xzeH8khh~
z0%ihpfJK1$J*;)WE?@%2%VfZe-&ufJH}(KS;QJB43}8915?BMw!WgOsHUe9L9l%Je
z&(nYfKsB%t*b3|f_5wq(j?c#cS`DlRHUZm!If%8E11|t;fStfNtmBh_slZHN4zL7R
z4(tT>0yA*_S_o_fb^?2Wp`+j*J8T5Z1GWNVj)hNwYG4(x4%h<h0CodrO`8WS0oDV1
zfFYyNZ=f333G4-iVBOq&0_Yg@6&MXn0;+*kz*^v4U>mR(7@i4#17m>6z%*bkFdtY1
zR0HdPu_t020keV8C!q{j22=y<fH7k+)__UCRA3IU2v`oR1XcqZfi1vpASnxW0LB25
zfpx$ZU^lS-WVCk*#t|?Dm<_xOnE#Ky71#mn28NFVA211+3Csb^|D0Y5tOBNGqg`M<
zuo2h-YzNH$DK-CFbQ~}hSnhy5fL*|l(@_SD0>%Q90rL+30$>?X4Xgsz0-Jzsz>qV*
z4~zvS0F!~4z+7M%@B*+Nm@ollz%*bcFb7x!ECp5oYk_xxO~6)Q2e1bi;e@WhL|_JB
z?vWP*D}mL(Mqmf98yJ2j^Z+IR(}7vQ0$}M`&~qZ%2c`qFfVseYU@@>9co*0T>;RH-
zAPX1^OaLYW(}0=4Er7XSt_D^E8-Xprc3>AU<ZSc{SPHBFUI5krn}Dsr4q)&(kPjRM
zi~+_2lYv>l0$?#<?x@!Tn}J=xUSQ-T@B)*7nZSHt5l{`R0yY5Vp4xoxb}ld<SOhEu
zs)5zOR$w<U^gOf=OaLYW(}0=4JYWg10$2;Y3v2?m0=t00li?F!0x%Vr4a^6Y0@c7;
zU<0rX*aHl4L2qCjFa?+n%mx+!OMz9uyTB%38?Xx)aXxGhOaRQ?_gr8R@B**~co*0V
z488!ef$_jpU>2|dSO!!BtAX`^c^7*xFk}k&fr-F$U_P(}SP85JHUZm!J;0DW@B-t2
zDZq4KHn0F#3akP)0OrnpCotqf=nG5(W&w+UrNF*-?@1TI=D-+WJYeqNrvftpa}U23
z*bHn3%ssq$hjIci7gz`^0agH;fL%b68|x9U7}x@s`}YyRxJxijffc|iVC^*U=A+-h
zRA2_M8rTbrzZB({K^`!6I(UEuz$#!nFrol$0ONtlz|_m32k<Vi8Mx&NtY5$$V8{&c
z0n-3;FTWZv_wpNoEx>MIq6hu~RsySmp;w~+z%pRuOw<Kt0oA~2U_G$G3)xqr99RRG
zXLTb0^Q>+@V4llu2dZbmHo#tBs1LRSW&=xr6~Hamf(KX)jJghO0keQLz;<9aFnKn{
z8L$=@QV1Eq6kr1|{2!<XtO3lkx81;m>#>#r^9`MYc7RpDc3?yi<N?!xWxxhtH!%1H
z$O2~gF;0NBzy@F^FzP1g1<V5W-VA%*0vW&pU<WX^7&Zj90HbaNFE9&OQi8Dy>;lH#
zfqnx^fofpJe0&C~f$<AqZ(s?q0+<|tU4VtaxVtg`fknXZa+Cqnfu#>(oC7<7ArGT{
zU@9<rDP#e2fofngupL<SC@8QSn6?b|1U3WP0rNeiq)NyKHUeXwgbjhozye?$umjiw
zjCl%u18xE4uYe3-JFv3~^XO^x6IcMO0@eW=fX%=*U?;E#82k*{0*(U40ONs4z*Jxc
zFr^yp*MI_xftBX-aNfg~TY3L*Hqz$Kb_S@qQ#}vV+}BP6HFvP)4%6JZP6su2u+O8O
zxj!(my~#IciIGR+_ok3<&hmLkoBQ2MLCxLmwV>v=ji-W|JKi?%nREPmpyn=M8K}A2
zI1Kb{(CMHxpqGG}d!P`gxfj_8YUJlaj=5L%B5m$_(m~$>9Sv&kxUNLG>Bj}2Mh_RL
z9rV9{|Fyt>E%09p{MQ2iwZMNZ@Lvo3|80T4@OMPYDc#kG`{rih*~wpnlakR$W9guN
zn%2#9wy1xoC22pDcYS2(FOT1jXC_Do@x`7&pe=~0O#Rf?2KV#%&LLlAHsz&{CvCo+
z`GGpp@@}<v1)g1_etZ|@lzqkaTkqemUvAs$Ogryny5}mq8vy=}9pvxvGVQ_3eMXNO
zQI7?&Khh00#GRo29`gJCMH)B+&q0uHxtjX)!WJf7@)pYr5SJQxl|Qk($eP@r?%F{;
zx|>+;zmVmrO|l!lxMJ!B-X~4|jWo7DY2j?@+2E&L69-aG-xS&*G>`I%Ph!4X_Of5V
z@|;GNr#--a*Y8sMcaZj4sAqUT(k9WKQEa~>oB4^!<nK|vqGq-ieTez7J1M_>G~dDQ
z#g_t1zbfM7v&Lu#>l)IapZzMrdp?HGfwQskQ_fKG`yXb0PK>ky`WwE6WlSehnXYXh
z?X#11eM<R-cgfGn&$*QPbbi44$-V4f7QQHB<Q9#iK7QG!>_?nIkRQE*<;faH;d5Ev
zjW2kZdRZN8H+MGE8M1dhzF;yK<)O35A3245!Ftl7X3CAe&hpkRw3}}a$5m?$`SMn>
z-0}!%!{KZvCzJnIz;ZbA+kU40&Tp9Rdz1B}5%#m{Am+Q<ncs3V^Bo$m_EeTTab`C2
zH5238^e<oj34X`&x*epI_!5UHkNriywo=+VFQ4U(^~}$6F`ZaJ{;H!$vyNka4f<i$
zh19X+uS+oBe?G@=V=MFf4xqh4XRzO0w@}Z5yVUQ!?2r9V(z4N%Q-w3H(KAQmCFe})
z>Hn4a_DSRmtYy8v0Ml0WFaH4Mx8sW`MoyE9wCGT-6Sf!0-~Ism)rJQ)hOY(soADgH
zn6zvV^9$hT#mMgnvHc3oo1&X2r!hpDiu1CO)9@+VE8old=6x2EA9{y;!N-{{pUZR+
zzLaCi^He__Uy?Ct%f+NUx00_VjpHnDBkM<ZlZH34Joh*9CzM~jhwF8h)@AD(^aqy7
ze*YyRT;E&qWeU??Q#b2JZzpZspMI*zWw{q$xHNp;wQRR|HuHN<W4fV(@++QYy_O=D
zcerWK&Y#Iw{tl^I<Do-x3+kC4h_iiL7is1ew%ddC(fG%4K>zntk~&)0PL{?+iJ#*u
zbPf3`_GkMIqLm|=4yaw5=A-?7^7kCbcB1#u&fN!+Kj#bPx7^M4DrDE>N2ss=VU}kd
z$^NJ1QeOO6^>Y*DBt9mMwUVzBlPC}UiM`DHY|UFY?h;KuTVJAooC)&#Kc&2sO{AXH
ztQWt7cIpX|25*!7un(Ad8h(^~MFrHqXcFbe2G$qcR~Wx0|0X?#vOi8Nh7Td%b|>XE
zoJjljR**k7jPiVMvtGCQY5k1lsoK}9+7~)^s+|)kulIb`uSsEhR(y%h=wZWyQ$s!T
z*q+b9blwweC+}$Tr_EtHqBx;$7v<NgA6;4>n^%#qPxCrm>rA2aDSMmsI`9Q(({A7p
z()hEi7smK9>uam#W6^TzQ?GT`d~ed!YaT}0gD<X{bW1X6$VvZ&)E~R%Q(hY7<iAWm
z+peZxiY_95P7CWNus<7lU9XXrPp5t%j9-)Aw4F5BPI(r5vCiaIXdE@-9buEM+s6Ks
z;^B0ExoDkeVT^M6@MS_XZc?-_b{@idSsHJZFOjeKM%txNcF5Mckb?Ec#98(Z*6UFm
z89tBcY|XdYaZI;-%l>*#qTZErn6AB%)S~^n$wT|JeL?-xHBM8jDaY$%d9&iO)OzN3
z^iXcS;+tN@N2Lc)PRk{v{vXI+`YrpHmco4VJK1JFCbSNe{6v4%uN6O{24l~_jZ7C!
zC#}PmA5FgJHrgpocFq>f6ZMH!{)2oeH;~4=sYjLKfmA!wg~yP#|C7{t1npEefqMGZ
zGe5SJdPS#Dj}qC>*-ZU2r;)$#V(J@KyyLxx{1yLZe%IHO6L(N<QzL1cXqRZ}YRYww
zWO?TY9H;hXrjviddn2$%vHIB-V7?7sgg4_Y=RE3TsbhYD;`u}t^-0w}(WP<SqV>84
z<H?M-+Lx%W{V?+PUPZekUqfnF922)tubi1|&-oea)l6o7_F|@sS2CTqfB&lyNvX11
zI_}$zUrUZ94enw4aVy)c$|QB&%l!0Gwo`UK^K(Q?v>&D+xG?fk7qMNx_Nn5xsCOdF
zdKFi)yg=uT_(`nSj&sF<sGpA?m@smh(#h{Gr{D6<Vt$GAb|{|cUcmB{hghDj@m=*f
z;~lr+?Ix|GiO1NUJDqxz$uC`+H&tsWuj<hLSDBNn+sW67^~C5^_AS#<?c+tabDVdq
z=eY4FQ;$a3Eu{9_uOnY)7VR0$V>^N2)TeDQ<(Fz*3M;;?`IO~>RQk~+f2F?4_Uc}v
zKHfV>yCgSX_3Fm3zC(JZK1%&;@^2pI;eO~>L80U;{wVmJ`UF2Ff7`&h@kC4iI1i3z
zdHJ1eH#~&#OzdN}7n)4IiU(L;-ogA%eCN%y=N{PiK4*E!FDwr~LYj|rl;Ml3p7lNI
zk$o`By|QP?=d@#}m2w*7hqN8cFV#9(pm~+tO*!SF)}NWK6t&}r2aKQVM6>Y&BPQJ_
z>bnomXpr`ePByPYCV75kJ06Y4sxb9vQn~9y+NsFL`Qt<UVfvM;eIrs#ez)w_iXX}_
z?WJ8u8XjgzN<q2@Uqm<gk;|E%D*l=mX^#qx-`sQ6j{IJ)_$8+K>c{t2jGX2VC@)$@
zdBF=vvr0)*WJe3u1;ZbP5>JCVZ{;{{SNzna{V4;J7hOy0yOiyxzQ=ZwH6PsgUgIE?
zTk)m){`MU#_iJA=zafXCV^WR$9=V13#X6}^*URM3(>+K#{9x=@p*SIaB;^LY<g;H(
z8dZGMk<W9T<4N+BDn3g;mVA*hY_H$~mbd-RbUS_+!RYJ#H|JZ0;*+XZsF!s<>*pUr
zeVWfDe~aSCSU%G+?e8s9X`k?1&bO46te<uf^WAN1xAt=8mvm8X0P7L9uB3)p<m+Cb
z`C3N#VGKs2XA8dUWoXxV)URO-<rFkBzeeQ+3wfT+NM?E8PSV10lv95v<##Ebi@(79
z{Gq%LYW;}(RX39MG|@h-m>g!jTC`5YWl#S|>XU~1E`*p#fyLCjS>v^^lltX-$adSF
zlD-pVFY#4f&-P08QlHXS$d~aj<rVAP*>(x*Wqu;P#n<>M(>^cTvCO4BM<!{P=55L-
z$}9Pr{p~xS^6GSMcfU(H_FT&8(RjBVtNc-<#uo<V@^A1;%1Mbb-}i6Q7TGWGBm3i*
z{tY)%uk@$Yzk%}s;%y_>^G}wijHaC6gG{I4Sw6P>r0#8$=ev;YcBL}i6;pq|lYH$%
z&8sLU@R7!M5!<y_vAxFSERTN4dahcgGZdeP@uL|=uafDUZ@#50?|zTtqvL4GEw_`}
z2kyr-PipZaA*O!Tv!o&UEAwv3DV6*#oy+UjQLbks`5W>nH&^|#9n5-V(xVpZ%oNCP
zJf8f8x6>Z!iuWqh$e)e4#H=rV#S;m|{Z$tByF+nhK??2Cr**&JWwxJsDETr^VtHge
z<+f`dYM9FQ8|AMe#aI5PSug$=sSokxgU};#0rf0We_Mw!?Xi+Nv`#l{VZC<kD`DM(
zHE7)Bt)jhxan;i}YsWp7>2Ig%r{R0@#t&6zt3Rj6uKQDdk!VD5l&6&P0_wM2<IQ&-
z<@gW}7<s)~hms$sJ)-5z_i8+5=p5OkeZ`u^c5AXpk=?(~WVSHfHo&KIh6mrJH|;bk
zF3uUa@6fzX^|4+|?bl9cI$Y0sF6=94A}Rk(+9?GuIQQG(LG~~71Nke|Zfpki52!ug
zxh!{%VgDQ{mi~E&>&5>4Elu%Vnfl=?VY^K}wv)Mx_1yA*pY|8qYt$!p3d{3k*X|qG
zeoGeXcO61`)<a3#@S`|J|Fmh;zfbeD_zTwS(mZxFGwsrRi)vl39m4v_igPR<QjYT-
zyx#-44VX*^g8Jjs%e9U)RdIEj;(d$SZMlo>)PGDqyY4MBWba<Zh1r_Vk)i6(a@K1b
zMA~x@Y5Ymbi5x`gaWda|E9<30NfTE%7IGf-;_znXQ^`5BSK9=pW19atIZSuV=lU52
zKd$PMeAow!9Ruxb$0vP4ij(`w>36^O^FsXanc*+iI@PFswDU98FL{#k>Mo-mIrt$X
z!(aN9?rBFb&TK8D9)X8h&#ySw{|eJ_#6M=<+TP&!h%0{Y{+@nHJBjUB2iC(%=C{7W
z{9dj1ty*8&v5p)GdBFo|KZouKy}B1lyNLB0@q<=I-_)C^U%AFn=uFzr>1TPN#!u@-
zl$W`L?Y3M@z9x<T<mu$^)wpbh-%f=5hHJ^!i63e+@uOY$<hH@&&wrirye&+(YCp-@
zpY7FT(@u$_NmCW4hY(B|{cCr!UZuu?MfD3Z(H6>cx+uTmaZ-==4L{B?rhda#%IT<K
zc^uCP%=qfPi{*_UvAkUJeJ873ozK%`pL7IHMxOf?&11<a(>%9MqTGyC<ZG{_9BZ27
z$u52K*lxY<0ds$)ULA^8B45#tS(>kDQ^?=qV!M@!qdiZtUMYU0!01(XBmJBeV*8D1
zzj;6MHJs1<vQgYOqi~+7mvsQkTX2ps>CS0vukLxKZ5X{K-}(t@W&`VGoXfbY#mfAw
z@uaq!*iMz!$$G7i(TTKAY!c<CenP%fwUgpxc^mE>Ok5P%Lq5wp<jW{yd06q5^>WVp
zR@EyjV7kIjz01F(o(<a9;x8~ix}AEqp3Zcw{9#wz7W{_oRlG&ogSf_wmyS=!Z(l&Y
zg5#MEs~_cxyHh@9e$Az<SBmG;W?py#s+U7QRy;sjt9`CX@t8~Fy=)cbl>JCr-$t6a
zinQT7_OIYY(&V9}5v`Aj#q4L%7tD7rV7l~V>d~~B`Hh?9hdkyxcQD^88r6M3!$#(3
z>AarXMtOx1>30anm1P$5>!&im>N4?ZzpGQcW*JF&LCuf0%czHM2x)`v-CUSwX8bwR
zN!!1n+?1o34rpFBiiW^#_*=JAPRiL#TW%r^jbi-@-PcCmqnxVQoIh>YjQZ!nM)K8M
zOFy~vo<W)VZQH_r*|hIuY2K8|A7wfZN3~Dbj;6d~oV)tR_Xf5T*ScWW`kHbD_09~l
z+=~4dp-7T<EbHgaBTdt~*NgSn$m{;kpnkskpINW`Hs)7o{cfmWe)n~(UydL6GyTk5
z!u;HyNE_u}8{#5U9uY0qJnw#re5vw7!OgT!hT_Jw-5dvnsial2DW~EU&I9ivrgQIR
zKN~&tOS#5H7VaOgwIqc#uKIM}m)gd5JzA%mzotA(1?4&ZLE5hMq3KV`b(~3BcdORN
zN7(PuyBJ5->7Khp`$UcQ3EM-g*Efc7REEy!y`NBzz*lT9rg*XF5%T9=$a!yD#`2Px
zv`^E&sBeA-^Giju*U=79*|lzejjKB;$Ei5KO#P_RbKG>D6MBYA-g#`Nv770%EsRsr
zZehQj<EeL(je3Uer+<RF2kFRVd*N2{SvB6$HQvgeV!a~yqvlQOUA~U(d2lap#!Gn?
z>o-rLyoTdgUUd(t3tvz)d?k9W;zi(X(#_XXPlx39=p5Ooc&$e3Lue88E|Q+UV_Dyk
zLjCMpm@ZZvkT;Ebl<N6rs@}WF*F8`~=h_Cn=aDyza#F7%wQXfT>#Lb|zePVrPhda0
z;%qN>4)rh9ewwXy-~Yb&Eb8aIq^b9jb}3G^9!|S-T||9dx_51UlYF-C*lr5Ot=W$%
zewUv%v7Tcd_4Gc>eE$&oqxdkU9q^}#Lqi>u7hFTyBkI=vpQpI9O6yBhacS*N%5k1Z
zTCDkGmp#H-pWQl7#8**%;|J8QcRA~Mw=>`QDrvNj`8MqDMn8|@JM-HrW?ZChC0~xl
zN6B66r}KU0J8%zb_|h+BJE=7+Z+@1vO8bagaen@T<WFc^*c878bgx$*Rk`B2jKTO$
z8RYlq+*+)CwsRQub7}lEwlEzyowW6M(unr`_6EvLdzSgdACl%M4#|Cy`exkCeuWf|
z)Z9b9BDLdxk9?(yQ(c-rX(!Qsaotb(Zq_(nME?AD*nV3XX@>Tnsv62q8AlqJ#P<8N
zj<#yu$x(dOu#s|GWWUDEw0m|r>le)A_^iyNoXUqu8y;YJ{4dsbzRYynHtOTv!*odN
zRzVH<vh*CJL+fh!B=XxNziSrTi)eqS*LoE@obA?x+5ZImhNV8KLUC%&AC&L*uzq(v
z`w`LoP+&RJPW%A68DG74FVWB%*twtTxw~J_EmQ8JUMXjjb{t2(1b$$wpI_&-KJ6Qh
z6>L8!Kg4pVujef0*P^XAf#}Vw-=y)<ivlArb>KN7eqh_A%YNkgkkET9WnWTX>w)+_
z3CasJ?=2cv*~hY-48+f7-gz}H%YNm4SKh<&R@vEBNc~C<A<g-kdN|z4{m)whdAw)n
z(0UVAI>Spn(sl2Wem><^X&n#z!SdXPWv83Cj+S&Vzy5U6*mG>pmdmvNd8TW=r#_9Z
zF>Rkkf7T;zH+D(1(LSN;S<mwe^K%qu`g6(O)Iq)yFViK5lRu(#a3kwQ@x#kTZu}nd
z*X|^Z{z2NUdEf$*;p_RC{mreWyo~>ly2g^m?WEcFk>C3e`_ocPJ5;S^ek$T{BQIO~
zf65G=cVg4YU-T(yisH^5t-n>zP<~=FsS|cF{?6CA#fBeoHgeNfu$_W~Nju|wFQ@zf
z_A5tmW90^>&G(E<z1ZojA3K4xViaj)6U(!nCV$hT%nwhZedC(1Z3*%f-$nh?bzTX6
z$NchE+PhBuNz-#S=P#7k_%r)eQ^NYrNzC`*KFjp8M)M`0{i5s)>f==W(5e1b>G^R$
z<2~{t<#j3@pG$wF>pfVHXjJz+b-H)!8nAba`p3VeJ~<O;ck^2^#%_hp)T1Xv+O<yn
z`Albi!FqYKsfYIg(){J*i{#Rdo@*($0daxpZ<_S+>wdCO&lk!+mHfjgH*FW?)fcf}
zSzpu61vsA={W@@-7zA3jn&|?a|6MD|muqK!RyXBZ-X(vr_B}h!@kUO;yX1?GWWVfs
z&e%JVX_wAVejDGL%*_zrT-NKA-oF2^o#YzQ_VtwS#Xl4<?Ra(H<kS0JR;>%6t0~7_
zPFkS-Hh2#0XN6xLH2t;EE_THGMqb)4l%G<~{A`WaO4*@TaX?F)?bm93OS?|%m(C?N
zE9E5y;+maIN2Onn&f~6H>X)~R_HEF4saJ7f)050E%AvkJdamgCi1jKypuV+FQ+}JM
ztBK`RQRc^VKa{QaXsn8>I?FVU?kCOqmi3yoA9Wl=`Bk%IH=UQtpAp|Vq-poEzD;sE
zwQpGz$97*%Ic2hwvxj=6>%OO1_h(glzH8U>(0bihm*~E{`yICD+>f+Q_o_YGuhX8P
zUy3we!e>)&pVn#1Qu?*CitStb$nVzuP(?B2dM+kkT=Sp|KX7lxhb=r{XY!TVNE;M4
zx{p))Ewa1T6R+Ya{{)ujAIb7!jV}l8L(IHO$gb|YSsvAS+Nyh-mV-GSdSs`{JJ^2O
zQsxH_qTarR%=cANPUe%OsnVn6QtA=kO8yi*hi%n3Ozh7%B=#`n)K`*LS(qOf%X38#
z^V-;@?*QCI8vCFgrbtq@p1b8<q;aeGHTNs(=|j9`)-B%@#t*G`kgrJJBMFS8zG-^y
zoT)gtN%J<lp5+Z`viCxs>jR2cGFMXHAnsv|e!Ys%noef>jug^tod;c`DW_HYMlj0y
z`K6>GthYu^(<7u-twR|~H)!3mzt8osUh8C7&#4Mtrkp+(?d3U$?dR#<B%=MM={U-F
zYu}4pOuN)<W__2QuM~@BYCeSjNx7AX2aTRpzmOJB;JoWSlQgXOqE6!^^0wYv|C#ce
zM{^#BHP4%Cm|t-m->c~y$8?9{z_dfyu0`=r=_xGtXdTVDkL3={<M_kWtMq&3TNg;)
z4%*GJiRsA4q<Iff@0R~C?biK4X-wtk(~cF|ce7?tZgd;vwfQ;DnslzU+(Y|1U!vTg
zo?~Td{MRea@D1D>gWv2Ep`~okr}s_EG%x)}u)Ulh<)s~g-_HVnEJ6NKtz-TO_3_@w
z{3fhR#!p`PJ@F5=)4Y~)iWRq)>t3f}7~k8no=d*iZ<JGn_13H#tv}+s<)9VKl$-tm
z^{Q9=QddDcxqo1}MfX`j-7ohZ%KUQegDuapei#0shtacE>vi~8@`b*qo=){Ab`;MK
z;kQ`sK8e(!^|XEz+izFgVN<;1(z;ao8RfM%lX`cse-+wCT6M2e_$lS|NT1%R)YFfD
z>|yjQ(YdtbMCNy&Mg1%GXWFUvL7Vm7hDGaK@iw-Xz<r&O)24gLa-5^iN7{ySw6SyS
za>n0XyU5>u3-xKvWxf1%=GQq$T~CvG)Njwvv`g2W%x}D(^~z__uT|%fCKP99${wj#
z%ifQ%z3>@K2cKZN>U_%U%VoZ;h3TSEl<$0>?KUZH>;8=SC3DE%sPWYG0_8=%VR=`C
z<=&B`T@$Ha(R(b<)cZjhL8j~UzJg8nc}>e$uda*b<^Luv)xKM)_%V7c`O+uSPgz+^
z`}Ce~!`;mHD(;W}oBhfCoceYvZn5fKHB<i1)qQ{M9L8rUA5m`kGpwI>BB@h;acZ6x
z>K@NMitVN-UbA7pGV4M1yOa}N#PUq7)1mE@m-;#L{T-z7R#NXvq^WhJnb<7%gS^@v
z+Qt1G{g!<y%QLW;nDJ;in$-Uk`JzXWwx30PavoxN8^)`-KWJ3^UGh5fd-OfZsN#jX
zH>iKT?oWHq<~o^K$M*f7vb=jN+X+9!d}}iG>f6lx+JBHQ`ZmkkbRVCm{jd^onCV~X
zb>vTfoU|`bX~iiux6?o2b<D5)ih8^Be5GR&{p?L;J3T+Cy<F<!!nx1bsWrutgb*bu
z?+m7EFQR>#b^p?IFy)rK!urkw$mbEQ%46Cu{p&l)*M2u?{Zp)8qw`$ZyG*+ep?-ae
z=N$)APVXG{r~XFLOug^Yx{&FtFIhk9dD23~!)~oVor+`P8(Chgdy>%2v{&XZ=C|&q
zA98gbY93Dc$;+r$&jT#4(|tnk<E&@xVZT~*Z`gPn<+_(KKQx&2JGB4jYuu!qOnDXK
zM3+)tr}n2FJ-@CkqntJy$3ZgI2ji!TZqnXkX(#VF^i%nI%5i#GukZn;d-T3h5#l9N
zKUl)@=$WLs1AH}<+l2iLA$3yGEi4b-M(R3?G$C5HjPg8ls7J%aEYF+Cbe^97w798X
ziJRqdolndDV13JK(tO#$qj<xXM*iNl^oK{|s7vqtRBAm6EM|FJ<1YIW)@#;!+O7D<
zqPV0j%=WB`3)2f^*Hluw=2zq*%576zmpzAa!vpJ_{9h-#cKkrOkq=0tdGvn<;tykY
zo5p?YciN{y_gb}MSzf64HAVYPyPb0UewJ5Zzcu@4i}sDSUwJ?4`iAYKE~MP#g^cI>
z-eG+g77??q)oNdF6U}d>Tz4*M#VxFFe)HYv+dY$h%MyQ;hiUWwv&}kgQygr5ugCEF
zBBU)1v|}FPE3<y}W>bDfl;sY*=WqCX*O2DCEq<Mo;`cI6DAM|stodnG9Md9wJM|o^
zelGjprT0RL1Jp03__+K_jYsX%iGh7z>weRvY|n~&S!3UZDU|2>mNZN2NdW6VT#)4M
zqP|@kM<sesC+`}zTdL=2T{?$#so(W0Xon8P7sa}ND3RWckIIgA>TA<Dao*2*J!stc
z(Qy^qY0>^%rS-XfFYQ^Oc^CeO_40}-uQ$f>=rz>8ZVS`C&&ij63G-c=5BXRGjGyv9
zAz$xxEKg|tayyyMY+-yC!M&96cgiC2cW2Um>6cL7c0KP7jAlLC5v2KLEcZ+A^nrNd
zACwaaQNNs^^!$qT>JKIjPGf$gis`;FY`1qF>lbY&E&GWyZ6U{H@J#YG_(_|8V0}-J
z^QR+~cI!Ho@)HAb5#CEPc1hes{;s3Q*Nu9n{{_#JzidADgW!eiU)#WZM|^0;k-waB
za&>-iT|qfTyC}E7%X*nQw?`hPT#KK45v>2Fy|~(~(0z9659D)V-7<OxG;T@}-(bs4
zvi!pQ$QHH}`;~g6>s*kbII8h9%8BbaPTJ4p>zT)XRo+WIO048d-9|gMeMG*RS(M+T
z`tByS>-e4dW$oniwsQRVv8Wh*?Yi%3yPExvC|*rypQ_OPTJtHCldJPj=9%hGFKJ&h
z_3G9*tIwc(4<1mOc3j%W?Zc>tUE?ZS>s;Mm<SQReT5<vPDb;hQyca3IqlER-o~Hb)
zFw;$X-ck7k^JAK~t^~{b7E)fZ>|LYtv2Pd4J9IBq*F`&b{F8cgzDju+Uoqc*5A#d4
zf0oOSA)TW;hj86WS+9B>^b?N#{p(2~&UMBfy;^6JSF>Lct-mb;@tIBYq?&RHu>Y8P
z9<4*!c;0KqW63wlSAYG|t9B>l)~{rF?N;jDs5qin_n66luwS8z*<R(Pq-h!-Eh8x>
zwvcih7~dAOo40}ap>Juw%<o8hpCAoAN$Suz$hnN|*G`pRGx>gM-ww*@KAHCh-H0R1
zzL2i>Hyrxjhv#SNS+SUU^eQgRZex9qXx)jj+X}W<CA;(}j;s5Xathz0oWkw$r{bcv
z16f{tH|3N~l>DIT)ia%m`x9gT$UoUnS1qZ11k1}5k5_8{c09oPPSv-5M!p8c4gSq6
zk7=Bxf6R2`In{fgdKOtoGk#-xm2t|+((_=e_Mw>cXq(USCdE+|*K<8_==p2G0*#NC
zbZ>xtrGI=*WdBn&?pm~-*ghbC`Wo`pTB%0|D!mDN6rM}}_8vpNGMqyXK)y|JP38Ga
zmmS3N_TSjQoXaS$CYxz@oaNRZnV+k5wqpk6XB|$yW}TaI6|dB4US+G@6!_ElsdXvk
zr0Sg5j`+j$vp$dd)MC9h`e#>@FJ0@1RsOMRTsP``;lG#u@6f$+@1^uha1Cih^QTzP
zbHYW;&+2BoevR*jGufY9_`&FD*Ly`-r?dago2gImB+`x&(gv*?&bu^Dcgh}`_rA}V
zU*AqSeZR0??QNt5zcWAjg?=AH@sw)>^F8O1uUzlJg^H<v&W~)TT<0_U%jC<{y-^Vs
z2V6NO*+!Djp*YNX4bydA(J$FfkK)F(znFHE(jJyEOxxSpuI(wd(^IJNTfuTG>}%Ge
zp5vKzui$uWJCZbWU|b+>H1<vHB46R1)T7lwzScREn}zX!p^((4I6IzB{-R{^r}S}s
zvR$Te4PG;j3PkbxCD&=(mzezWlSp&Nie`}(i#kqby3|7XRpUq#qOIB&auvVU719nB
zn^><qm;B-PnQr`)<r&MF_MfNuGM{{vcXOP@FI2yuB!58TIx6|z6Ij3J5tjQNC4cf^
z%#Utnenj_K=`p7B-E6N4<HD@t(JZ#xd7|X0ofPf+*&FEJDxH5iJINOlpIhUhZ@?}$
zN?+|8e$`LYc<#B0<qdl&CwwGnvBp`!9rSa19oM^Jt!qBrr^gguxeue9j31<r?p<83
zQr|MgOU>$cSH9Lutpm*%mB#;NgW3Oj(JDQMh>BWu4;5708`b&J@fF)G(LIm1n0l9;
zs`(zEA6*u<W7YcIzCY8IcmQVF&-#%1_GNP4F1v>LZnx|{i|JhLSD89LwytM>&v@#Q
zjCC7JT9QroL|r;>cPSn$)BJCHk^Fg6DL?iB<)rDJu<94)x12+HorlprZMuI5X<aSX
z{@k#T^*daog<9V$?qmP+bdJk&a(t$)B45Fe_zhm@TPyurhBCk9bG~=lekI$Fe?ogk
z?bIV7+I2YlQItm7n4<kn{Ym`B{M-*oT??sCf$o!PRxv+a<Ex{H`W61fcFg}KGX5zn
zqh8t5xt`Q$f9q+ZoowAKcfLga$i39ptMQd~JJUr+vAj>~m@|#_n~x;T#d>bmKi5CV
z-=Xz1?qRxOEvZNQo%26Tr`f1?PZ|5y_c8TJzMpb?XEPnrypQPlX#jDs>0em1`D4l}
zm`J-9VUacKL+wJ!t=W(AvR@~)>)s$A>#dQKpTYiB={%qE0PEHN!E(=Sq*k3nn{KDx
zZ6{I>>*p-@zCt|`npcfM%Bgsr@-wxbrs^I)Q~PPtV9KdEopP<kOm~kV?W`bm9YLDz
zA<g)Sa&r!3yX6Nfy^ZA+366&{-G|nG&a~wl(!eLAp*5sAuaZ_`-!^t}Y8<<@ACzdl
zYFj|Q7LDUtJKJp<nUr)8>gDL%)~xl@qx%)hgVd`@@miDC`%sDY-9eOFtav`E^{80u
zp8Il+<H{pwr)E)?^k~<;Lf^o1-7_e!NAES1D=sU{VSenN)F)oS{)YDFJWRLo{1Eww
z<?V;Fz0eg*XXrUd@dDQKJj{Go3DfCUkUw!f`_-U(llrsSZiV8d<g;0?VLNF~h_qPo
zXXXpEYr5_|leMmSwT~9UNyblZ#Y-8u6fo(`|Bz<i%=R;ME{JNqE>_$W-O7C`q33!*
z#rs{SaXfX7raqSE*`F+p>zLw?sP2n06kjx)!Fm;5&cjxnGaIztG>Xrz_e#9dFJ+MC
zjrNbG9=4kh&6oZ)i)r8HX8gZ3^fO=g`6cpG>0I`=MDbg;&KU*w&>oiIw7*UJd!mc&
zlq(KuZzrE;H~B2-)GK@`)7co@#=iFNNfU~j(>F3*vxE9|Xg{-PUGWT}{hYd&%KwS&
zdc~jo7t0-k)W0dDHJiv+hVeKF?Y8x>os0um-s5L^!2$SRd?;^MzdVZPicjMEsZ9&1
zf4Ykl*N6S*k&w<~&L1hK`9k_FGMw#{SCdwRX@}zVte<-fX~uKZJ6FHYk*{+|?qu?3
z)UbZ7?pacEDBs$~`o&+9w&*<C@e0#@kFtLutrIPZ=R0)XZQGCXtA<g&<2ce>#f{nH
z*`G?q(T+m$rzl>Fy+Qsi(bPAY&JuNtW>2R+5yeqeiWd`6>gUtEbji+@@3GyG?A&qy
z)9nt@zQ@>3z4kMU_N!37?4W(hp?D&6BKgCQus!c&+OOs+%Ij8K6;OUmaf1`>490k<
zQhxao%1OriC1#&)Qhs0<<;2gU+&)qNoop{%d@V1MFGuOPi~Nqk^uJ&6s#EjO*+KsF
zPe=<y9U7nBJ1D>5Huk%{fqYrVQcsKgk|F96Efg&i_5VgWap_gHOXElBeA%NeNdGr2
zBF!4u&w^~PGfp`@Kd^rBPt5PpI*a2}|GclggXOI{r{*^>zcPn%JI^I`>G`H-s_cY)
z(X1O0#d{Us$UYj!X<BzvuBZH(Lel&TSij&;+PO#fGtH;79k1qx_YcZ1DJONmPTGOE
z5>q58q5JVZJ!i{V#`0R(uk(BA(>ICjHt0OmpnH*A#VNUK$rn-_8ec&<KK#Qq)4zbm
zMU`lisB<^tpme1ReC$__(jAK_$E$SVG?sUk${xqjKbgmqb`-O{Qr*wzyg|KswO)r(
zS?(Uf=W3b9u-vkc^}GK?8cN~$zVvpMM-*rE=>E9;SMmi;V0oYR^{#vAk2?7yRr9)H
zOftWZcoF&2-(tU#Elhj$+^SaR&updbh?mT~EWy17mhz;+Gui(d>Dj%G{b{;}`6(w;
zZh4q;Lwe3qivFgfe$(UR&&#C!D%X)e<2$B{W+-2B+8s>yYJbl;i|sV+;rH!x&Y`?u
zquMK@ywE44u{A7@-9Wq4R5IVCanz-_FXJKBw_ZwGgw7g$Lz-_{S`VA<qr5DQ6YEUs
zQ@M@#ol{u9T;-POOlRD|a>t=eXDfb>+{FC+$LLQ#;ye?lx<~PxkgR!Jb1%nfVG8*g
zaE`!MkmS#%JbO0fWX@#TQ^I&7UH90Y?^s^1d-TA4l;{1N_UI0=UYYK%qR%m1a538}
zc$VqbBgh}Uf_}-ko^~z5e6~QJ6wODw-UI8?zSQ(5<wP=AucVuD3U!{S*L*G1bFQBE
zRjzU3Y+*XJk2FpDcCE%;(HU&NP4{+IFa6?^T{<#Y&$5!#t^1u+t%qLS*TfgIpFO&V
zY|5k^BYUWS`zNIF)s)lvDET{ENqg_7UCWn~rd&(A_b6_*j3A!_?`I7%{sYYVRHEk*
zMe1L@)|tpe+AAzSmt0SIg^HIm|787&BPrJhp=MlkUrD~G_B;2Tv`0ecuRhJMg8SH?
z#AmGEI)=1j6Z4&R_9LWtqgeMXU8Ur+mW%%v>fw{V?V3l$w^B~0)|<Kj{nUH{^=mwm
z^-_-`ZFMl;o>2aa9A5$XsZaYuZZpg4!=wr2TNBi$XDjpVI!DzWN;`IHy$tJnWod_!
zFH81`VBS9j`&rJQ9Iwt(wTgR!cz@XV%cgUh?=#A6-bR|)O4|N5X=^#<SB+r05A*Ip
z)bE`{`7OUNzh^xAT{49B>QdaBp?Ms}b6C@EgU*}Y$C$S09x_kQdHkZun<=MqKB*7u
zqG{K)g!L+P4r$T7M#UW*=Y?8dLx-_mx!&JQ*LbndBVX~O)HnM9$}P}*jOx5rdo24`
z`3n2*-_CZMJhWe(#-(!$@1<-3mgnhwQm;59AM4zS&^vz+<(0h6`o7g{->LhR)JIvr
zSNV+*mZ!Z=TKXnw`@czp?~-=i#{P6*JYi`|std9|MITY`CaqtAhuMDkH|7W0*<R}m
z>JxsM_Da(@Y5J6WZk+4Qx>$QO(<y(D22)wT^JAtvhA>^O@!G4nyg>6ZG4TGyq13zP
z5z>@JoS$*+AEl2|k3z+D$sba`nAWqN%h`|6Ft+E>dQx{H^V@Zfw0=i9fel=zT%uK1
z(>@lROPz|3(*GiV?oRe6XBPSD^qxUfwBE=3g!<9(4&O^o-AH}v6xX!r{g=pf8gIu@
zzoJJdzwjCIm+G9{rt#g4xWLR4+j-=#`I5BmefeAKLu>@oIr4MSz2w7nc>nM4rJTmJ
z6Zdc?{z=h!*0GuL!#cl*@24KF*C@|+5bfPKmV92F8+=;N!doaesPPbZl6+m;Nz1Qd
z{VK(Mi8E<0e=pl{V;&lPLLag{C;V^bbz~9kpRak-r1h)mSM~?jyZv?v-pBUsI^R@Q
zQf`LU^R7|ks}arH#&qd$@)c_zaHG*dNl8f=?^55u!1*>p`R*9`6Y^JB<G8Ap<?RPh
z|GXQR?mkE3^cc3+93w6CvD`P8^78)0bc?7>aa8sREN{~|Y<{17Swop$hl7$C7d08o
zkBR2WAGyafKl?QDSKLT@X8%MzJF%}DJL7fl{`IKpY4Qj4y_H}u`K-T_)`({R!F01|
z{$8d#M2q{FZat6fdDE$9(K}3+zRL1QjOnt+Se^_$jQtb3r%8W<<y}*$XZC2;%d4TD
zRTG%b(ERc)VZQw+(hlvzxmvGXmy*9t@l}b=1D;c8AMa<>qaFLb8IM_7$FgpvAJeNS
zH~V;|>&KABA7;JWAnyUv^`1@oH1b>LaK2m8*-o0?Tkzs}sA;Ed6!TlPANI|po>hI!
z_vn7LFqQVGxP;|>@>iP1iCg2Q>{;rQr+BJ!BK1f=M0Popa)MeP)0a?Qz4*%RVLDCo
zwD1Ya3+UdkMZX);s`Cr3q56OK--q*^=}%1etp3}nfA2roZecIwSi$rr_$;$%zYIMO
z%hdYfIF$9$HILjjy<ejEF?cKGH6BR5EXBnhox_r~t~CBkz6!~$AI){9^E>Jh{$Bd%
zxoOp7?6+Ib7qWB@=UhvBbv{r2t{~H)Un#$69rH^MW`9zZ@6bJS&12-tdV>1;w7=Bc
zO@7aA>Xn7_2Bu1q?MCtk7E*48^zp>0U+-3y2ft+fs-fgd(YliL49l~lEYCSx>nZ%y
z4Ebq|<Zsh?J{BOqSL=p%Dbr~$lh1NB+bvbQ%^$EImD4m%G!D}jF%C|i&++a%SMATF
zy)r(aTu%#Wx6WGu#Uq`wS+6pm&mGcqubP`n{R3F9%=%C~i|HEKC4zm@jJpiQS(V!7
zN+z;>*N@aQ@HzX_w}blkTu8k#m2ba>{Dm4fHQ%$I`xffkdNpbMTGHTpQkUYlF2wal
zzq)N~C;pS{r**bZ=RR)@^D}N^dp(<&&O4CuLeG+-TmAFIsko^*Mt!2%?_%;#eLd?p
z&6Zv}m@cbky5&Ps|3&O~J>n=F36jb%?vg=UPGWiH?WA3b_Z*7%x-?%4ucv=1z966D
zE71`3D$#uE(Y&cz$ovYOr#d&%-U)r*IQ4R_vwoeELx=MH`A!f0>(qT&gXT-a4Xj_M
ze)Z*%&!c$0P4mujFW+17W05ia^Jtz#UR6I|BQ1H3@`9SD#jkNaj!kBMpZZh$I@1kt
z)(c|8G;%X9Vmf>X``P`4>=`A^swTAsNqe6m_3IudU+3@if6%V+qv;>-kffw@AV2y7
z$48ykyQuieKA;@C#$~R9>5N~fPe9K->U3`KU|w1wFY9ZT_f4n%DW5Z4qVs!44&}Ji
zPO;`y@;e%L2XZ{dw@}ZVZ%Lz{ioQ=;5GAceCmuw*4#jOAjoWO^n?~LH6gN<hLe1OA
zQr2(PbDI*yrw+xdxjxD*s$;$6ozy$JKjWB6tt-)T%IQ&D9NNWxG--Wom)~7;Y5%a|
z*1i$kZ)(1y{KO*C_;A)Q=wf?0zmVFVA}!rbe|5AnU3@Ovue*}@Zp4k}!5*%GeH8W0
zx)mEQd+9!);yBhXx|R73-6OYP92x%L_teK-M?ZG!{=%ky_=dAQ^<J$ndat}h^SEXi
z<;LsSj#cNNTFsN>n`w{67bwRCKbrCG7|eQJ(NK`(Ia`@ubOqNHub#UXXgyEhp4QYa
zT|+s&anb_aBlwpoznipkBlY$@O8Et0QtxGy<A0gyj-}*pA47d>zo36Cr;%1_+*lQ#
z`*i={c!2fO2G%$AFZvVh>3ETH9g`W)1TlGx{@%AqJ&L<4pQD^q-BSfWqJG_fkS|;7
zQfL$PY1jVQ@;%El^?rp_@2%F|#QGH;>e1QB{lp{w;(xMU4(>P1IB1BIudhb!wy>Sl
zAIaCO^&znz%iA^I^JSM_>|18P>Hz;)hHhZJvh9?Uc`5zbKA!#TJD&M@cQIY{6shfE
zQJsf7?_+!U|02J$g5?3MLxa(d^-8VV-?6<uoi9DuXpEix@|UHS<*o|mhZK)nj$yuc
zFy;2?ey&N+ZF&{2*67^R*+Bj@^w-$Uc>~8w&nvWF*CguWpGkQMo%3S9vtHp!_NQ(b
z^$35&{Psi1?+h^=+>hhdVj*>Deg*$SK39b8m4?Y*s(rb60_Dd=dqr(d=6C9S;ezAX
zzUO|f163O+&!c$Ds`V|X_f=B0eui$QoX91lz86@}ejD}5xR?6W!8q75ldKxwZpGpC
z@SCw)MlRd0SA1WO{o2H<-D6q5HkCB@V(#nBIxqPZ$Jb$;4F`Y2yX1@LIe%E|q($*W
zvzL0s<i`-c$J;+nHNHxYVEs15Q#BUqWq*nFy0@|1@(gK~X#OsiN2E`M(ygM7A8D89
zY>p56X8N(EkogYrWk4BYr_d*q*ZDR1nn$s{>{X;roKKA1yg1mJaqYW`wC{KF`yZ4)
zRIhV9%PUS|fAY^^Iy#T~<aJVR_+93E<j*qEv{91(807{}WICq)mcC3o_R8;#y8npS
z$mj1Rb>h603w;X$)HC=r+x0xb@{aGBUpka}I(wOpeMb2y^O)axI_=XnLGxX4o28L*
zl4a-GVSK-|<3{$gOY_3Ek@fo&x72+@J=|JvW1q9#f-gubPhh!y4b#C#Sl@dUX>B#z
ztsKnrYWqFpFI+}_)3r}#DISgLd{M7?9zBF|8Z@ta_1q_%&-x`!_A^KEQPnr}L;9zr
zX>XC%y-Aw+I@@=&Qf{%<hp^UZyYA^M*HCU1(q<ebD~>Nyyl6X%{f)mzdEP@PKOkCz
zxYpFGIhEyh#YH~dho+ps`o&sb+vc;r{ZrNpI;mgP@vNVWxX=Q5k#@$*fe`sa@^|yM
ztXKO6`EAoEzv*?3k9zHot`AsVDB6PAV)QJ)_eKoO(tB1mTo{;i>RoKdb`JH49>uip
zPs(Z2xbTc6e}nEtB44n)2=|j_K4xCS`c7OR8o91nOy`|OzR2gizmMn9?pZpAS~Slp
z%gGm9#(JqQG98#m{;<~f&|OToD6YyD4Qu}iJWW0Q&y!j;zk6WZ5zs45&xzZ6DZfJV
zxV47%Oz3{6<}&IL#-Z*+)GOFT``Pu})_Nc3Rl(KNCtvGl`B_Z+M^k?JPRhwDrClOb
z>X+KdRlo8sW<3YSzgd^<ovhdTCfg0nWBtHs%rBJRisw)dS1bGL`M3DTvz@XE_N(z>
zraNwDd9L=)xcb-hnfix*ndizSm$IFRzQ35zzLi%=Iq9deyy#ofWVLTc{Ak8QX#@E>
zn>jv1UsAtry&q)tQ}05>Lk(we{Fk1}erA17ead97hG!|yQ%#yXiS}}@Az$mQ)T1Pq
zG*|0d)hkT5>iJd-`~3dU&ozPh9fwd}Hpa0Tw~ZIF{RZ7vHzN~Ua8k++mKW$=yKe>i
z(^gBGq4T@#8|ssOkJ_C@J&W|*r|w3|FMFJ{=P>#w)J6H_ny=xfDaU7LdC$GnJL^oQ
zTd-c3aZ;!I+4KnOhZCgPkCV3R9=HA>wpXHY=skgY2e+`DE{&@K^*`-5>YuFhK;U|&
zLmNoz6nD2No~oZr`M!@SFZM9g8HZ7i0vFR^=~=au{V4sN{F#?9U7)m8^Qchsy6a2I
z>1!s<dYiOr66IR-Ji1lC<I|+`LDAW?f4$~QLihaHkFp>3A*4O0&>od~Po!7p$cW-s
zo8pUf$uB#K^|B^W|B%+#XtL~Z63d%QNNu{e?bA7_EQR+n&0F|=n!0?-iONpJcT(?!
z>}orQa-+JhE|h;u6z^gC>5rd+I&URkMt<85Y`^vh($;0Pn-xLk5R4zI#&ga9|5UYG
zO@Fj0KTB~%hxSWPlyV{(A2oWPFbhKAqNK3i3kz!B>r3N!&3umanlTT}I)TT~{d#vP
zUhUAn>DK*ea|i9>IfeB+dF)r<e)cD^g!w5N$CZyV-Kg&`wI~j;Ent4rJjyHF#QMp9
z((e_b_P>~ph~{FJ!L&)OqP}FNyG83BQ+xj+&0IrT<EEZ5KWReyM~33C9?g@Qapdnf
znEKeWnYLWcbm`HgJ(}lTC-QyR7M<rBKO=vY_Mc9T%hIiy-`f9DeDrIN#&d55<)$A`
z+Ia-~RhLd`#XfG<mj=aqmTcyCt{{K%tz3`t@;H8N@?T&W^{LhUPOsj>%+~sr{Rhhv
zI%g#=<9WFEq@<){(OyD+vS{BcR-D_ceW7nT?P<}vnWeZcr1dHX>msfelG0A1ozm|h
ze~X^u1Qg$7Z>D{`$Fg5#h3rrAfgFzwvRiyM`)j$5azgTR;fG9jDXy_&|1#sms(a?F
zi&&nwnd2=#h3SO$v7&LRe;4Jaz;4FgMQKb|T}K-KC-t<gBF)}Sd9C;z62qT@R!zG(
z%bA}ZWj&Y9i5Yisp7m<o&Dljgb8ljQojM;B%;NZnDK1UOUp~#(qUR|;oJ#pY#Hps;
zo`;xjc$oU-o=kmmHD4<g&$rDXU*6Mf-={b-SL;<*8OvLAuFQFjesLW}{wl;%X1yrU
zduiogF+bxz@}*+kF>#t(_c#7U<j>c9bZeeg=>EIoQ?_S)j5O;!zW3Ou{U>b%<(Fvu
z#Md*OuXDNu{HFgkilZVvrc?Ajg7Z`A)iIlP%2vGD{uT2}uVj9pp6$2JBMrB(orI`k
zFVpq9uj^RCc3Ks8CE8doc|7G6olRP+{l{`U%iH%b-&?`@m6=LkNx%2KqVaVM^K*0`
z=&fOX;6+lG=64+?ndyI;o*TD}U_Hl?l<z;5{C#(^zjf+oFYez=z5G3-cC0hl0+RYL
ze;x$QYNx(Ex3azs!I$9=%wf7v?=AFc{^m_0fA;gF3C;7k_VJ?M*iO!M9Pd8G<K-dB
z4dzhqvdNU6r*WBcx9lc;`p#7PTFSAvvwpGSrOcCAUUMP)(U8n^gT5zV+eW*TY$DBS
zBu!{M=4>Q?p^f=%Z%{AyYSJtV$9Mh7>`&oEY^Uo!j&qOhi`oXUzD4)RHE*-N<yFde
zYaNg2eBmsnyef^)%-xzdaq`E0Vf}19X9~<<ySW#$o@<%v-%CE1##{b6rmJF<Q`t-!
zKZP{Z!t%yTnD#1Os2WTCI~A8WG*7!z$XA<3YSH%%!f(<KJ)4;ybx>~Uv9d4L0W*H$
zT7Mlerpun9zZ1`pcIsZjqIx-+Ke;2=KgU+ecj5a&Mqcl)d@nmv$934XRpUYPq3kfW
zAJh9837peSy=EWf#PnRaLHk9nlXi`~%JaWP_O^aRx#@}{lOJLKDsG_s$ZsrfTBr6E
zhx)!`I#v6%`!u$1Yh`}3&H>?(OlRx;uU7fpt$V}L+1eL(vfYq_`j=|F`!Fy~zk)j{
zCr9@P4$KoXpL1|eV%BZHo9%lJC4ZsfBag;Y@B)@cbl;Kl8s*u}qn!9LtY`m)`Ekwr
zQpJhs_(G7;qw{L&S^F{5#XhFHx6scW$)pyYV`}jn1yd`jxR~|~2RQy)?j>z|g82=I
zCyacHzPD8SGWAH-cy6p@d*P!=-3L?O$|mwvETJAT?fZcY=I1HC_dY}Z{0+>nSxEja
zodbG5V1AM8(mX@`#5g<{dgYzUbj@kxi%euXs{RyhVt&?C<_Dup2V1Fc=5@?3ynuT2
z;(K+bzYU82%U@uAvWv85JE`?h)~kGx>BfaxKmJMiq4|_kR>!nM?|mlg`L1;b%hMib
zd5ZR_z8>axy6CTT-G8O)-p=`N^2hMJ+vr)EPCc4FqaGb6Fl|$uU-2>XGZa7APi6hC
zTbS?ro-~+Cc^P|nAK|!z`T4hzwsw;?^{~Dr$aLvj)VD(SI_1YxPN!)5Fs6NfQm<CT
zxn_REaQ-xLTwp2tS$6|z?(vjg_bJn*7^h|)A-wC4bMh4*=V-oq{ge~)QEt<6>eY_;
z&)BEtPtp#|A0sFCYU&%GMOvzTFK-L=E6Qa5L&{IZrI3-6hWnxeL9>>yUK!GjNXJi>
zzKEO5eqMD7`y0@C()AY0qa|EVGPGV<&>t+}Nq(&>*-P1e;RWosMdzj1p{(DFd&Pb`
z==|4O!1F_i#zjKsl5C|L(^;?eKcv2!sJ9d6RwF0*3%1wrI?L<tXS$<<_Ot2vT=J95
z_oVPW$sWaPT_><!#~m!Ux@rHYoAoVv&#_JR$c3?t9eZ?t>(aTuqm=cFeqz18>3Z&a
z9PQX5Iq5T)_Nsrb2c@UpOKsCSVfz=`309H6+)aDd$e)R6te1Z}%Nvd*f4G)<l;^M?
zcE!6ndLEv38p{iosUL{D!{|@PW~RHVDYstnV_54|$6;*0^Je<LNc(&g<J0(|Q+j#x
z+3)|0z59>rtFHU_4?2?7$YH}qZaQq(u#v+?K|+E9g@g?@P$&>^ppf8Tf<c0AHEPsQ
zFvu-OL9v1>NT^XzL!m~Ff*MyNM}o2(IdUWvBqX@+<Lvob+V$<azW;x3b-Uer_de(S
z<8|KW_xpTCS&3?=>}T3v)r}S}rJeEfPg35)o|6|w6<7OzD~{%`Dc^m!+MAixb_Qpu
zUY8w@p--uN|1&D@`EBJ#zNdbB?fw(^xR!U={6h}!AO6HK(y8`ZFI_jvmG^O1oS|%=
zbDo#jd%>{1H+ikG^^I!R)5g>DPs-=nb<EqoU$|{mJHshTt7lYh_(^NW_IHEDKlY^7
zyK%fa*O%p;$`2-4`ClqOvck^er<L#HdCA!y{eM+H)UJztJf}L#<EyRSG1ZIaWakuf
zDYN(RnKhbMYOwi@=0=U{Sd_-U`!&^D_?FTvdq2#u=WK6#-;Up*{kAZo{=(-JcfY0a
ze^-9Q(u_BhpR}}KUik$}EALW!b2qEK@?!0$so&UkepT_ba(#4;FE4vOowV;0t#%(y
zwR#2H)&A7?RldZ=_mHJsmX27uV5uiR7;)P7Emk^lx5g*$Nu~YIDy||suJQu3e8%1b
zhHp{6`O>_NeJ|m$_~LbR?iL$o`~DTm`RQC=_ny@D#onv>-CVbiusr-%>TlA%qm0;g
zcTmZR^N_v&CqJNe1Fy1p?0V?qtL<p8^JgSS<&Jz#{kgrWbS}e=Tf5)(&uaN_k=o0<
zM*WTOet7YIxK-`A*?m06?sIE@t#UJus9xO~rLJ~A&PZ3i3j6)Sa<(&??HEc`|6||K
z`jQyMozbH9yzP5tH0Mhg<<Hpp<Zb6kMu6&d{7wCNKcjJLFV=CD`l9kf4=SHmr+lT|
z?<XzakfVO9!xc}?yY>F-YtJV`cKz!6vg!}VsNaImsC;0X;@xZSGlNH!cT3lL&q|GJ
z*Aq%Z?KxrTtlAj~P`lMPX?^$KmEY^9_0iUUqQz5Y_c?z%4~|%QPka7qjaU6Kd$0B$
z*7z(~zk9hJILA@J&FZhf-b2T7R4yY|X>XF^AGGHzSG&$s#A$hTsp6Y_M(w5AIP_ZT
z+OFl1mUda{_e1O7QXjh??d9Ni;_A2e%)~F~zT{@lA$#pU?Gvy48O?RkxsGRXFgedZ
z{m-j@K#R7&VP5~vw0l<h0DE3eEZ6qA{!VH9*E9|jeyU#?qkP8~U0iOU-PQ$_Yk0TX
zseV=4-TS)A`~5|Kx5uql`68Q-_uQ;<%Wb@xIgXw4-XlxfHJPmThHYHVG%N34s_Xrd
zJ(qcM9d@qs9b;;LXvEHMdyaK|K<&9stG|A`etX({?&NpXuCKk9PS|(e5+Akad!5qu
zTQr^?cAe^YP0O2`l#U$KxRhU~bl9$M!4F#8zgM|47i>Ja&NUOan?1)3epYb~|6JuJ
z?faYOKQz8mHqHSa+K#>-D^0A{`oNzmU9jJURM_!8*sAN(p;y&zt6isxS`<f@okyup
zYrQ|$hj$T|FHgnJ@m67RmvOu~<9z0{QZL>@o%J4e{a^T$#wXfa<3Hu4<FNK>wY#)Z
z@%DaL`Mvi0>1sDEpA1)feO9l5<I9O7(w@79?0w&BKye@Xi0W0?{+Y4o>*Y3I(vWD^
ztth2yA5wdJZC)(a<|9*!)UVI2ifhL1CxMabC#zWFP<N&J>$c~?RQrBZ)}{3`_FfoX
zr+QQC^#0>trS^My_;SXp-}dVu*Lml7PkoP;m)UdGpuM+8)~dhY$5lV|eQI~u%8k&T
zvp=%-YkhmZwy)f-W5XxaZiUU~SKp!i<7M-v@z3kH@cNMIXG|*fyi#f4J$C)D`K7fs
zPqTER)`#1;%~fdo2RVOlB%bIQ^}F@;skFZgCjH>C3vb*ManEDB9((<@FI2wu_>bOr
z{jbmb_-{KZ!&1_!AAR%98*jaEPwDjF;4{^)-SX-`-t<~LcHzQzzVPygTK=^3()B;N
z@bbx@{$lE>!n@z-U3&e(Z(e-uzO*-gdd=tV`_c0+@A~6YOaFN6hu^yJ@=JGyJR17U
zvybJy{J`&*s@}Rg?ZKs0jW56Y)ZXV0Ja+z$uYNJ>XOI2u<*84+nfKeaj$c3Y=7puN
zUik83xl6ANKJbl4dTJj%_~teDzgW2Nvp1vf-WB-Vg}1gOWPJUNXSQBfme=>mE6-ne
zF(S4*p!q#Ny70_XFTVcbAD?~m&gVYV{py96KlqQii3`7f`MF)M-1$JybD1yw&Go{C
z$8H+EFxvg<U*5dBJ8$CeZ&V-qL-&n!sg=+DB=Gfb{{6ATyIx!R_}oj6KJl&g$3A`j
z&B3BaA04~!T*EgnT=(kVZhtuUjnKb!J^IqplK0kgH-whGIC<xV7hikh>6WK<J$lo~
z@fY6uYeLcYW{&-JS6BPSrDs2RdG*VIZ`}IW>7@$^JG>vc>%yxS#yVzSdSmLjKfJXo
z^6Hl#{o7j?j(o-M?l<D6E<E@8>#x1>*aOcz)BN%yrLUcS?(8Q&@!1`ZJvaN~*Pj`B
zH0{N|zxLwi|1`E#cJ0;+7v9|Y>hIoI8hh!5-v<5ek2_xoc-e32C!gGK&nqw9`t%Q<
z`s?eDJ$7OK#n0?sc;WI#a)0;OTX(+R_0(Tqd+o;;UY~pZs*vmMetGWI8y<V*^|5<i
z@A%w>7daFz{%1A+y$K0O$6@qf0Ml^iq~KI>;WT$)YRM%I2hfN%9K#8m!aSC7(67X1
z@M_?aiT$WSCywJBX0e_JvrULX0+`xy;WNI=VKjkDiOX3mg3kdi>kxzp#Gw#OgSqf1
z>v9a7N-pOyk7Zon*I)y}5Ca|+T{s<GxW&5gIP7u~OvAcxi*;Ge#cVx7kbrdLq8R&d
z7)>~e0i1<9*NAo4h#*8D4k^gS0kq*5PGB78F^^^3UshrbHX{r%NWy;9pdQC@4$eOg
zU5)jKLOP1E4~KCSJs7|u+<B;2g>~47AjBaXg=j<@j^PBxaUSzn#x-vZHXsa{*pC{t
zpcCgXixn$~3+u57AxJ<jim?w>IE(?D##u~b5$+z08&Z&sLhL~!+HeZvSoU7V3o%GS
zCh}2=8q}i`$8i#)IEPuRzLGIR0@6{8Dm39JPGb@7D;X~YAp&toK_T|w01l!NZ8(8b
zn8zAV_9Ma&gBo;V6wd$g(`u|o2%?aHToj`T({O(u`wT&dKpe7Bhy!Ru8%|&x=do-R
zePaVQBMdRf#D3JH1)VsDS*+k5z8WEjLN4~93Qg$20H)#2^T9?0Ar2`h!~wM71m>~w
z{ltL{h(SK~qXoxt66Y|B6<l;SAqojd#{f=a8jD!v%@`mK*(k&w97G$&aUSzn$!`_b
zU;{QI3^7PTCQ4C*dUWC>X5n%T<AC)@Kst(X7)>~e9-PHA7U9nO$0`IN0&&PjA=+>X
z^H|0t#!75P3^GxQ8nmDj$1#i5*AfFl5QSpwLlur<8jD!Pv(!2SAp&toK{g6;00+^C
zah%6IR<0usgdqk=$VVw^a2)3_3l|?^!6qai9mS}^08Zm9rm+b3>xl^)5rjCTpb&d-
z5N#O8vJVmqHefSikcoVhVn6E9f=(RANu0whR;(vBY(f;$k&9v+MiY84fYX?UyD#w}
z2r0<MK^((*%wx?B#Dp-!APM=XM+-V}949e~bC|{I4-pFzkd9*P!(kjn4+d}+i*Vn-
zKEyhtpb&e|hGRH|am-_lA7g|t#2^#-C`AqG(SlB##3;^T#f`*-5Tv6DO&Gu;+&@eV
zScep3qYwwsh&CL<35?@B=CN`kF<}G3kc3jyqXnHfj!~S0Gnu&ptC4_o<e~~qIEn$B
z#xxe;{t;rsI&4G)Qjm>8>_H<=VICW9VvG=jOyr{!^*D}`7{x4BZ{pa&CWIggxo{7l
zPprd6#32QR*n<N&h(;X437o<>=CSN%Vn7&TkcoWMpdKyg#3*Lr@=?YG>k)-?RN*k1
z(1QV-h5KgWLJ%SlhZGdz02<MTV>pFzoX0#i1QHK2QHuSjM+-VJiWMJYT(BM?NI*Jr
zaTq-~4fl^TM%ai5q#zrGIDmsVhH;$7JeCD<%wPjzkc3R+qZIXMK_`ymBxd0fOib8>
z5Tqj)`%r}@^x!NO;r<E62tkNIAr7Jq$8Z9ta2_jf;TXmSY(^6DQHuSjM+-VJigR!Y
zAs&Pv9s6(?O&Gv5+(Q{3#32RQD8wEdL>rFb6y~w=lf;2ABq0-}s6h*kV-&MkeJlG1
zn-GF1q$3wqXu?qp;4BugDvW)FAVeS=h1i1wIEY4^!Z_x!ES$Ko24RRn67o@s8q}i&
zoj8e6oP*14#EDG^K`x3>g`?=f08Zm97U8~y{e~b!AP$AtgM(<pF`U3DjAI_lB8U@f
z5QZ2eAs?lvM+-V}66Y|B)sc)NLJ)-nq@x)7P=&*2!cp|#G#0Vyc4Eaw1R(-($i^NV
zKqK043gei^vO9<qn~{lp>_<IXa2zKwiWO1Bi1i3T6cUh*VpO3A12~PdaE~T7Y(x-J
zkc~p@!2vX)4X1D(D?dd{*o+t?As?lvM+=VQ99-@sE^I;qa#4(ZXu<%_!aauZK@cL4
zf<o-UF`U3DjALai{UaayQIAd>$0*LhWh?z+JwlL<TomIlj$#03F^xsIZ(}U54jU1H
zIHVvOg*bqNXv7JOV_6*WU^8NnkNv1YJz8)Qqi~65A7MR05QTK)q8R&d7)>~e9-PKm
zEW&*|@gWEiNI^CVu?Gim5REv76F85RJBSe*uo+><L@D;81}!*_lNiN0I4||95rQbB
zBNxS}!eKPwC<bsEXW^bmoCrb$Qjm=UXv8?qV;(E-A})j>3HjKM8noafMlp*OcM}iR
zV-pgPj$9O@3QahQ9!z5q?n%UhAVeSq**J(coWLoZ$FgK%K@#$@A2p~)3p#Neqd12Z
zpC%rJAPVWoMHLRC2?IEdvzW#r)_sQK3_*xM98yq-gJ{GFoWeNfu`-4IhZvNi1*2Gz
z%D7+?LXeJP>_Zira1>`TjYYWM!|{%F*oYv+AsYv95RGWV37p3~mZh=3uo+>9K@##&
ziv6fTJz8)MF6qRGO^8AQ(vgc|>_Zg}qX|72z%&-IDuXz&5kZJR3ijXt8gUFKa0=r%
zkCpdw++zbaBMdP}LMBR4gBEmR6th^dlkvnRgdiQc*oVV7jkB1>B35M*8zPW`LL5LN
z+HeZzF^^?g#Dz83fG{K>6ZzPW8g$|$&cWqAVnGNJkc(m*#!>X(G^VkLRrfPqh(ijp
zaR3L=h!Z%4ah%7pY{my+h(QuEk&peTK?^!@9J5%RLrh3OI&x8reK?FJ97PWXu<o;r
z5h4(W6l9|iZ8(LM4=^SOLkyCTiBi;{1)VsKlbFToT;f0oqL6@e<f0gd(S)NIz-dfl
z5$p1Z1t}=R9vr|yG~xutaUSzn_8>804K`pil2D5Ms6h)laT2pwv5V^iHX#I2$VD;s
zAt;|1kb*+&!2ujZBie8Z=P{3E1@w;%h(QwaQHuSjK|NZ~iIbScirtJA)*}JAD8^wN
z#aT>a5$+Fh3}GFD5P>*kqY#Z~!zqko9?J?D8*D}xN>Ps%bYc|e;8H{^*n}vgBNxS}
z!eKPwD0(n}(^$l+hlvMqNI^FC;2@6S1WsWb^H}yd#tC7FK@w`vf=-NL7B0oagw=>b
z0*X<ECLBc%25=f@v524&#s+anK_L#H4aaZ-<Cw>q&l3w`kc3R+qZBo0!Ev0#D9*v<
z5#qvnY(fHZu@6;f!cp{K0H<*l(^yr?{=-H@AO+bd#2y?(8;;=w=CQJj7!igTBq1OB
zQG<H4pc5xC3ztWU5v#EYA&5c(_Mr+*IEo&e##u~b5$=x>CpIDo+1P_dwBZ=$v1||V
zVGTAT6Q$UX<2Z>?%wqLk#tfSff^-z43WsqN16ahWFVHt4kb*rphEo{Fc_e+2aln4G
zpcBV&4zpOjkN&U;>DY&(7{FP$m(ve|5P=jFVh;}BAR5tz6Bx%lHhhU~MGP`giv6fT
zJ&xlXX5sQ>_5;=<1W`ypI&!fORXB{J7{FP$?<Y2FL<HiHjY1s637o=t%wt&vF(C<=
zD8+u%pasV<i`8GDf8=5x4x<T2(Sy@)|0;cB9fA;nIAo&`dvE}aXu~m_!g(w^z_EZ0
z*o+t?Artx7j~djY6UT89E|u&jgdhs($VD;sp$do5gaMq!SxjTq<BSu65P=kA;~*N*
zhGRH^aV&d+a|ubvL@8=ej~1N7C|s)8cUX^2h(ZF=k&7xcp$7vvi)k#vy_)gEMns?u
z$8ZAUIFEU(d6Kb07&4KM8l1!|)_;w@5ruRVV;`!}grn%eX`ID0+-v9?L5M&cQjm>3
zIDms_#4((}IOegTmi>k>Bq1NA*pC`?;y6y?99+K6F@+FBApyB4MimaD2|YNAX)MD1
zDfSzJ5Ql6OVh;|W4dXbE(u4Gm8nmDjqi{LI{=sU5ARW2bhbkOK6ON(>r*RhU-(Y;O
z5kZJUHVSb72XPGNvFvHCZ&-sEWTF)NQG-q#$2rWx`OvxoA&5c(a#4jQ9K`?@v9697
z5QI3SU=I$U4JU94<Cw>qZ?bO?h9qR71}*5sag5>|X0hU1j1AUf6QYoSbmXEK`%r}@
z9K`@m<1D7J2={to#YO}n4k^gS9yH<@#&I6=SkpkP2ty1qk&peTK|NY<949dfmv0j<
z)}t8va2Q9?g8`hzG#0V$JH&)IWTOymIDv7T$2?Xx5)U?`6gB9?ah${`oF6%^z-nwl
z6cUh*TvXvOj-m$xn1=gzIgYUrL5M&$3ULspa30IPM;us#4cLqrBq0;|*pGU&pcBV&
z60>k=VqCBZA&5c(a#4lDXhILBv4~a8>?iEO0kq*5PT&;AaURS5i@2}>Vc3rvwBRIW
zvHJV;jVL4_7saT;VH`yd7UAB)zQINWVGoYs6wYHFD_iLgn-PW><YPZ-(1K2!#3;_e
z<p=B|tj2nTAOX23Miq{t2WK&jMXY;<SP+Cbq#zpy(1<piz$uJl9?RN@5gQPO7$hMR
z`6xv_I&mB)F$<S=VnYbhk&9wf;V_P(2Lm{bv)K4UVnZBKkc~Y!fP-j68&2Rnmi>s>
zum+nEh8Sd`6g8+v3r^x3X5n&_@k0m_kd9nbp$SLPg8`hzSxjRQ?j4LHA`piZWTOxV
z(1;V5$Fd(28#Z7wVvvb^l%fXp=)_5!!-}6UZU{jFa&Z_<=)qY`V-fD19NS1iAsW$!
zV;IMIEbF3wgdqk=$j5%vqXnHfj!~S$ELQxK;|rS*g?%`TqZq(6R{e~zKoBAjhivS@
z0USglj^PBxF^`qU7#D0n43bca{is1FMllPQZpH&4h(a#*p$do5gwvSDB33<1Ob9{*
z;*f%DoWeNrpQAtQM-A%HiQ_nlb8zWl`>`G&NI*LFp$do5gdPmwG^VkLRlOX`h(ikY
z-~bxYhGRH|ah%6IR{oqZ!DfUZ21zKze$=2IE$GB?oP*0Rh!Y{mMKSiF3Qg$208Zm9
zrr~~^F~UX!Ar2`h#2y?(Bie8Rr!bE5SlLIM*nrL0j~djY1)VsFQOsiXFBwCGAPTwI
zhblDTD0*-f(^$l+=ZOy+5rH^lV-F7CAlh&Yr*IydPcUA{L_YST2K8vcNsQtgT>3e_
zu^Q{K2_c9=0@9I-V(dc`dT<(xaQ_uCA_#kM00+^A6F7x&to$`&g$)Qp3^I|AQtU?!
zS}=-pn8o@5;z1M=kd9*PLlq9=D0(n}(>RMoxDOH=;*f$u9Kb=e;TTR~9?O11j97y(
zWTFQ3Xu)xeV#RM6E38Kp(vgcQ97YdL<1D7Jh>a)NcSu1Y_TV5IaRR4s9&3geAH*OD
z`6$JH)Sw<MIF3=c{5P>63JKVUCLBc%25=hFScLoU7!RyN5aN)HgE)p$7{_@mJH>H?
zFvK7erKm>>M&U9{|A;~Ya#4&b97Yq4;w+}I2>0I;12!T8aY#WS_Mj2Ra025vk7X|~
zHrR|XBq1NAs7DJraT4b+3zyUEE3C#QBp@ACIEo$&;55!+8gV1Uf@~Dx02(olHGiOg
zgdqu;$j5%vpdOt#j&oS?BF6}#kdA$*!eJam4+d}=(^xmkK0yRhP>2I)!zqko9vjAp
z14+n4DQZxU797VY&S4fSULp>JAPVUy#$oi}ET*xD!k6h2Z8(MVn8&hl&JAop81k_n
zE$GB?jA9lm&M@AHLIR4h4~KCS1DM9DKeEjTLL5?%jRQD{Hk`tFtbB#>#|CUh43dzK
z8nmDj$8i!aXNd#ru?ZnaKsxr}Fq&`_JvfbNEW&+)xDbI9WTOy!a1f0+g>lSd<)4TR
zNyx;1{_~#^_|FLZX9WH;0{<C-|BS$YM&SRCBXE_AucxzJo8jt`myz?Ji_6t6D?Hbc
z594o<T;{UAI5VR#<Drr~{#~ld9&~m7t$$kDLs>hEcIOn9r0vYk+WA1*&Rx46$jPGK
zrTPco`q%nbzoY(()Zdx?z(a)(xVT*Fa)synRyzOgZp*gqX?I0#-x0lSYg%mhr<~l)
z&cBDf!gDq2U0o95(zb-h#M~CX<<7LY?a|w|M<*nwZQZs#Hav!YFO|Fe-<ONtdRKT%
zbcFNo={!6?Ncj!8{9m@?;uf$WdHK0nd07t@I)96Bh3DOjP}NmV**kWmMHcVO$}h~>
z_2Blbox65t(gg9Z@O&3#HoecvY}xf-VODYBr4mjX(a!oSoo#$)8*#gGD7pI~7nhH*
zjms{MK}7V9xR~(dE!(!<9(_mJjxFI^W1_c4rfu6E5xG5j>m6y)TN5I;$AoW*WJ{dB
zwJn?Y-~VP?Ts}g(?ia`IQ`>G!+jiThBDW-@ZH-Jw+a8_}nMNlG+qcD}MQ#nhEhf@w
z?`A81nalrGJ~lil?Y8i(5qC#N@MFhIeJuMw>qP9>5|@?`e#hH=T=9RFzqqr~ZjTAS
zV+V2FNL(KOb33B9{oBpBbo{ORAIGmV#!egmvTgsfjU5SWS9r`ehWxH=F^RE^$|tPe
zzii+Ctatmi?OP(#61PStq=j$U61ihX8V9QL6I=D^{?2Xv|E|mNzhm3&2^{Tl&T*~t
zu8H&R11@Rz7iH|uOv}u9C_kfcXLef7&WzmLv<G+Pv+fGdE7`uwUE+3qE^Bw<Ls`3H
zGm3Nait?Ou(%tiB)+Ox-zbi70U}M7*oc(=0%XhFmE@4|-T1@0!ksJ(3TO#8UoKx`j
z=opSQ{uz|JCx^BRgK~$%srO!%6_F-#I6C=j$!~Gmp^2>tX%XQG;b{?(JGN|(rseI<
zKc#Z_yxm#v9CDFK7wde0WvMKCyTk3<5)(MsY44x$#>S>y3^{yzWcWvKzSysG?(Tjl
z=kr-<g%|T{oOToM-jP5*P8@qL=C|G*y)_~&DtZU~Cv)KG0DtGUq{TTk6r0m#qO)<f
z&?)zJyJ=gTa!$NAIBh$Zp_s_<t%-4IcMx(M>zwh(f0wg;QQ=ObPTq&~b33y$b`z&l
z_q$Hr?TK3xqGQ<wiCecggG?D`TQgV}zCHG1o6~NO+p#@udnBWLsg1ii_bGO<-2Qiz
z+wzWb<xbmMGzd<;tDIPDXF2(G)W0p+`SrBgJ#ewS#_VEwmS5Vp&KM@J{_XwZT$8r#
zh_-m0vH76WeuNX*$2L1{I>*u9sFV0_hMmhx!uDkK`_FNvn$xe7-x2-k$TW@!Cx1Qp
zi_MbWK;AhvWB#v$lX6bH_0IOZ^Y#$E)j5;5I2-J=>*>V1BWl}r`f=iS`k}bpY*c2B
zHev&A4hm<Tv%lVO+I)Ku{&{dZ{W<recXoH_Zba3K?f;zhX}P;NH=UzY?Y)<Kz@_u!
z9jC@W$Kld&I(;`eebd2?=-9XzF4T6{<8My5dphkor=7E1>-gV^?>Oe1{B7H|IY;Nk
zaT&07E;YcuxGQ@5#l!AmedicWv~h9TbB_5KJDHsP<<7X>wavM0UM%nQowa-SgS+h9
zD<FUOJNtLa+kxh6hjZV1dkEvUUA%j7L3h^G(U)B=-Z>l>`?-pCqqaxxNQ_CiSk}1*
zzunIENS+ifo)b=tm#$6Dk?8DO=Uj-nbTU}n&i=l5ep}wz4riQ5E*@to&c3;G>$a_2
z^urUPogvqSD(zomPIby{`F}_4#NnJ%^n3B7a`MhI!KKTcv%Q~U{X34Qe>UutEpWz7
zr{l$KaL$V&9uD#govVk&-YFAfg)W|hEO)NI@4SvxJAH86#M!nv$Ldd5_ReF~4uQ10
zKB{(|eH_JI&v^p)XS>eDz%B?k(#BKP?!R33I4n8CV%|PFb&Yz3vf;5@7}8>sw%EnY
z*~aUfv9lA*$vfL<m+_1HIN9mr-|S?kELC0XFuizuyw4dgCqBE5ILE-Hp>WFQlefe2
zpZCvI+&{17d2e?{&O=%Me0sevBPX|LcNXQZxBKkqrE*#MyLK0*-T%<rMR*R;y?D=M
z)|Sfb&Uo<ttc#Dq?<jlezU}<G`HTIk?4`%%f0n$|rt|OU|Mzl{#e~SVe8?G!i~olH
zT9=&}`Gv%u#&h^?9#?sCz4+kyj&f~oPMep?<?qgVIA>SULvI(nf#=6fjJpfRg7f^C
zS@K|7VeUg|IS=O098VVaX6)n<{o--aO}Usj9tt9zJDASl=be2P9UFcJSMZn}ZyyPl
zp20T!k7uw;+v@xcf@>~4%M{;t|G#^l`G}2m8~uAa&*?jzy^&S;zXj>sM{jXr4Bt*T
z&Xwj4o?aAtCClHA+=*S|=(N3zww-1f!QH#^Oa6Jh)DWYy?$QpkLAmsr^Urdfv~dO7
zLK6=aX6!C3%6DEN@)*FpU6~wM&il<39H6eW6}=-oE&Q(V=osgDByGoz$eZ6@f7!oV
zzxn2W)_3;Lzt#`GD~Y}@weR-t*3<s=*8jWy-TJ@)N;qwJT)eNi^S_;bavsV^%XpYm
zBjes&=iK;!tzYqu^;r)(D>Hd6QQdu4sqTFl5AWJ-Z93;ALw~W&ysW&P`6X!_r#Tm2
zdYnF;^{d}r{}5yN&-Iti#}?MV|9{4Gac4N^gNJ7hXGHxu4`+P;*JoqrozE%P^UiYr
z%W?OCcN}+DyKK+O$lSW?_N)hYW^t{#6jKn#hSu3ToE0Hd-l24jaE|e-iF;?pLxl=V
zFUoe}r)6f{TXg@uyR$Ml!7kMa;ac&3)wz$hocc~bm(HaV{~vXncY{mq$8n8$XZwWc
z;>#b#aMG;M6&F*lpD6GBhj(Ah=e_3qb$R|q(J`d~tKM@l-_?J`#k6|A$~AmS%SURp
zy!&1)cl&|r?Y&3K58dj1vEJS{^*3*_B2=z2Q1!dFD<5!^Qt$1mU*4wm)qhp}KzHls
zXIkF=sFv65R60DN^(DJhzyD9#F2B2!27FxQ`rB1MHbwcwC6$lguKZrBcj#r+3w*cQ
z4M<Tw`74UEs7&eDGOhRX(t3|8l@I)l(jor1hclifN$S_LUuoIA#-r|D<wK)XzPC*6
z9C=ddRIKVZ`zxRNX_fE3R&kenR?EwOr*!fyZO78r)ZUpXm2bF8X`+Xg*ZoTEj%2Hy
z<u_}2Y>nEfenjQV($!w-S>;0~wLUgU_3Iu{K5?`1wM{A?oT~E4Ra(9fpftKv{ZwpH
zzux?DRcCxs`2!|S+JCd!OHNi=`>@)}+pYTEzfd~)xV67Q?RmGTozPw_AKYYd2dEwY
zajp0IoXU>{Dot$DdXFmQV{g=X5qO{aY5ud7TdVr9{#u^+1=aI9rS*Q#sNeVot)Kar
z+G)K?>lePGbSzcv3>{T|_)6v5?RcAPR{eHgEidEc>*D$7srIU?RWJ4v%J*4Z1xM6>
zL8jJwzM^&-zOHu8oYC@D{#cFEo{t^xWnWbLW3Q^b>(5ng$d0F?dsRP?KWyXF^So2*
z^Da|=p+8Z3UBg=L&mXaJ$_*teKlx>~TbH16{`_$oXMOFg`VIA0K6q4V^<B1|>B@V(
zNA)VoEbgn-?o^t}4Shsu__)f4e_icX98$k$j;nn5PZd||PAxA>Q~A1mN=NKEQ4pkj
ze5A^EKcTejGis-nKjP!WA26(PeXlEj#Kx^+rQ+#&z}oNBdfyx^pJ`NlvAfh>YmLeU
z+kW@kpzWNxN$KEvl`s0C;$Cal%MlkXA0Aga<fit9A5niL&#8WIz1mNWSK6Jf^@+i%
z=V{mJ-dwF8E4O-f{VE?<KHw(BU*4s9Wv{8fj?bu`>qClfYDQ_-r`6Bc(@GEhO7+Gb
zQ+wg3Rc_8t>lZFpdn13)`u3kG?JrV#=pn7Ictiay*!^iJT<a^pr1nZaqV{GMw0z-u
zm5*Jc<-K;D@_moC=SYd-^8SHRuWzYd`@_l?Sv>u&YTxs9EnogMwVU_2$`5`{Y4|r3
z=aG+UefYIDPPeOmMvj(ye^u=?lxe+Bhtiz2imT!wm5cXNyQv@7^1!!r-|#-7`V&9U
z`iXa`eUHCbzaLS4`C6sXwx1I1IQ3ei_7=XX_1<=!O1(ktW!ZIO(yreg*Q<QSFBNCx
zPu0&vxzdjB+V=lQd5>omUtojE2mVxP)=$)5Yn#$a{;-vEKDpZQ-Sru@<F`xgR3@q4
zLA$SK{YmBL_Ne`4yU&$8tM;3lRnIF#`@6DRX=t<7XZ%+6GXhkuV!zh=zo4}Br)qcU
zn<^K~M4uC1*_6_Z2UO1Udc|4Pu6BK{)p}36fBH9CIsU+xQ-5$t<=yz>T~2<^uD{WL
zQN6vZR6Z*~ag|)qejZt&@^yASiT;w>@yu7b*lwi@*QlKmyH6bYjq2sJYJI`2YCqhb
zo92AAKKdJKZ*7OxPy9p6Tca(F)%vA_YG=aE^8kDPIP!pP_th#l6{~h)U(~pi|55cq
zf1`2*e^a^W9a^6EHI=X3r~bO_`Le4*<ue*oF4>NksVh`J`TaUBd@m?}=GQ78ddT|S
zrnJxEDSy`5_fdJbKWP1&9WND6DUR+A^;h?t(%$!~T-ke-_p@;*IiY-o?cabut6ksc
zRlekJN{_suG$&i-r~1@S<#UR++^!#I?E2hWVB7aul`jZZ`4PMCd;eMW8Zxwe?W<}(
zwnu5`qLx>OsGYTUDy{sWwtwVxwd-onKW@KQdp>r5JMtc_FNx6jx^7ZEj}R@dw(Ch=
zjQR<;<27JJ<vedxe;(y(cgU_UL+x6>*RGFaw<+H6NwqVvSM_?c)bAM=E$?tsJ2@wm
z-)qnRmCq`kNZUWX_8jbO?-xbGYH#^k^|Rov{%e1r{GsK_ABj|d;X&%h`#LT6^Hlqj
zht#i|JqM(2Q{K;xHy?Y>YoAd4y;rHd<$qNFM_iRpwde3DyI$<QLUGJgsa`>?`W>|K
zTpOn4<-b*${3pfZ{a58(f1v!{RJGr0&kOz=6kkz-(&4YEd|rT!@87MyJtz2m-^Syl
zmJfYM?KNDjv_C^>(Jxd#a<Af?d{gcFFQ|Uen_8c9M(c~7*7A-=w0yzNuZl4(pS0_^
z-~HB(i~5OuLF@Ztm7n;EwHu;*ceJ+K!>&KI_WrQMA8>T8t6kmdzwdL}9#4DDs^t$X
zI_u;6RsW1#xB9-Va^7~HO?^n^BG+lT&wjOA`Jn1m*m2|?rMUO<2N|7q+wJ+J!Oo{S
zJCCDpR@{dYRevU5^<4SGkxo5NFV$~-TKS3_)L*$>-;1tM`O2NP-DS#qKWN)?M)d;i
z{+ngbFI|a>zxyrK8~UEol5CZ44!3dsuG(ua)B4^F)hmnC`qsZ|eV(tDFa1gRwRS$X
zCaS&g0F^&<pUQRoRe3*qZXdo&`L*`GKJ~id_q|>1)$LdR6{E@*J*c$&yJ~MCO6$iK
zt)2I4z0YsezpFhT1Yf3h!+)mrUUvTVTKs2Lsh!F&)ho9+j^wBx-#M-CKCOQ0?0GrI
zp6`;I)o#1pUx%(xf3@GVINP<p%;rI6;<f*$?D=QXp0ASaxqI?W^_TofwX@gWd&}*4
zFWBA#D?X@rmY%llI;ea{mg=W&SN}_oXnDiO)Smaa^5wR_8eUfUJ~y>9F{5!9dqHX6
z1FE<5N!5$D>z~&_EuZvKxv3wkow7fuoxS$lR&lGAXW9L{_On`FVeuq>O8Huw@0j|w
z+FScUEzh~2ek$|SfBWw&9-Bw$9o2Sv*>h0qhg7aBNBzdzb6UBrU;b+?FW+MI?7g;b
zvzA9+ru`H7TlL?*QRQ48Ro-)@^8MdYoOw^GzlxVs-~XiY1$IA3{Ic?sPpZ6+y}$Y2
zqJHA}gR{<g?{-f0E3Q)eMfMz<vsvq_?feb+qw;0GN^5QYuHWW?mbWU-vS#%cY5O4{
zPwf}Hpz+Jut^DLB^_TS}<vpX7_xDrUz#pr1;yYAmaoF=#`D<!_GEwUT>^;Tx*UA^z
zePA#_{bhYyY1z9~FYuEp*ZzIw>pYcu-K^y!hn42p{ieK9{a4H>t}(lh1lss?O{@G|
zi^?6b`%}N2f9=s)-#wu?Dj!mRIrf|$8KdR>{J~&nduMLfdXH<hpDG{M`i2*^zSW-3
zMr<B!B1q->f2{Rxo0abkRXw*<#kF=(>xb@9JYF`h;2)>_pxs~cKBf9)*-8WWBgRf#
z8P}_w<W8mW@6-B;5aqq!t9<`k>en+!?GArj+p~6++Uc!Uni{Nfm8-SBt4#UeuWEhS
z&B_PZ^Je#M<>$64^|Sj}j?L2yFKYSnA+^_P``tB7?UmSjZL-ayEj4Jl=W@m0_pIt2
z`l#B8->&T$EK<2KyAS95S=;54rPSAs^Y9|o3;uxG^F5;WdcUXqm>q9J_MS5wspCFi
znNsf-^|O?wcC+eKFXw{tmG(YcaG91L`HaeEtWZC-_FPtL&$*RbtX=D8!QMCh-miLH
z-&MTPKUP|2?~xtvQ+sYU-&(Rq`Rbh($E&JeV(({pciMip`)Rq|KL=k?y{<1PU0S8|
zh^yi{^Go$RSfl)MJHA8hye+fm*h6+7EwlHh_`B49WrW&mxASAz?yqBCP@Dx{QM=9G
z)_8f_{Ui2qtN(lT@3B_xxD_Zr@`%=F#3?PXd0@9etzWR`*jRfn8MgOxkGr+r)#ia3
zzNmIHR$4saTEA4Hw7o&=qwV?8^>XD$p4R$|K;;*#|B9{Jp0a2yPqh2>kj-2APpBX7
z6)NXu-yyPQw7lHrg$ryxbof;*k8fA`sr%J$^&TxR8dq9r+f$UL^%LE8Tn=h|^D)IU
zbA#3=f7iBSTJ5&aEAMem_2z86!(UhZUVH8g%vJr#Z)*7wyFO0j+kV)k_2KqD5YVK2
zr9FSR)~O$Vn}5&vx!Rd{TxrKyt&g<l<?!z+z8pJl3hezY)L-TDEWXJ<Dc|re#nF9_
z@`<-9tv;#tJy&SGm&NP#ZM9!(&&A0*RBr5Ns^=M}^&>W~?!QfWx675Twc}yXRpn=F
zzNEQa+wC)?{-VFGyuWQnbdk!>+5Bj<y%%<UT;pH)rq+kPr25Uj*YdtBwKMcZr8(yn
zNAqhcSA9_F!l2UHZ7SCnseHiQx(-Czb6FRE4BxqLv}ddR+6!tg@LKin_hsdSZ&aG`
zoXU+wDBsnu`pHA;r));cC+$8LxJKn$U())uHgDavQ}uENZM%N1_2qV*JF?5#wfEL?
zo8Rz$LUEPcqV-vO)L%i4+Ud1<G1n6+mtps{kuBP8zc`hfviIr9pQv1peYY#G*8X2g
zSNYgU#dYK}THbE+jvgn}PM+=OLmg^o&|PWpsMfdNq_lfh>13ATE_jd928+kXp3jD!
z(Dvm0M*UU%LiHm3w7kUTo92G4xR%><$Wn;%bAMF3k@j6D+ODg$cE6~8QSH>tTmM!*
z^+)O_r&IAS*mqtpdp=IK?<P5M8khKK^|#laTk71@o^OfbUK^vlN0a*7d%5a)+i?_V
z`_<Q;OX|L^{=GM=|2f<4fb(i^#NL}T?7PoIsg}>AD~_@{_0#tq<x{Uve_r-Iufg7z
z#%$g#%f2HN*#7A7P`{}@ilZn&X~X>%SEwzw`(MM7@<W&2EA9SPXXjaoy)T@x`KkuH
zz6IO-=-On(Sv#b5y6pU!TdwUo@|w0MINrwNO68~CrF`fL)%URWlb=w%z=K-9u+8$H
zP`#|LDxaFH^#ykQSo*s1-S%C;!^#KSb=m)`if`~O)z2DG`Ep<F-{dLf!)@L+@Rag{
zc3gyiL*>S79wzJWT7Sl#SG}H5`)k)LPQQBf<J+WiKJU_gEV)ei=mxE?IHI(_T<ss)
zt$h2a%6V>7+HUhA9rj%7S*7whKT>&Dn>Q-htbColAC&oMd}CA9&VrpsBloI)fSpI(
z_Fgt-_pR0@wNt)D_4eMP?Mk-!*P(~iZplZ~PWg<szue~Adu{$Myh7`vZTkb>P<!R}
zew$<4;~%Nzo;L3l`x~{FXY<+q9(LT+sGQ#mYB#i2`CywL@cFIk_1k-T*NF1V?R!$I
z9slk2Jt-$Z`=ugA<$5R8-jN%$e56GE_THfWQa`D5;%1ev{iw>#{ayKZKc(S;8lS9p
zYaDxDS3B`ON`qg~`hu;h?``jO-FAQOy-xj<KdExH_CDctTFd(nsGW{)DxE4-+HBuN
zqKlO8`-<Wjvg><5s_Gw#RqEfPG@wu0op(U-2HQM(xXmwD+jq(td+%Lq^CYqM9U#0-
z_5AI-RpJxs*VX37%RjI7hwQuL+5)ZbeqCwN^{PKvu6+FcDqnP~@;){nmTJdmpB?8J
z|E2YT;kF$MYA4z5hhqh5XK<@h-yBPOlulZ{FIVl9+jYL&?$42SeVw%XWqFaxjoCPb
zpH+W@nHq1OTCJbC#`^iImJhwIy#GhEzP3Qi_Xa4f%~LzoRzC3><;(3oab%O~#ph}}
z#~#x9kx;c;aYp&MGg=@0E#+ry9`n$9R4&y^%k%7fa=TZ@UxxkOq~klPKVtK6XDTgk
z^MXS;%J-dC+%vWx%Ix{5-{xKBp3`v~oS}Xjrj@$c^ZVE*v_3gr+tqB}Q$uYYY^GA>
zlkGYYdR+NddtUSTq3VU&{VC6`Z&UU=pMniq-*8y{blZGE?<wW|u2uYF_Iz6K8QUL+
zw0#pX8kg|TX?gWljoYyOek{`7uiRX;zUzJ)7dw8Zex!c9Kdd;q?R-gWQ~5JfYH!Kj
zr<1SL_U-+&jnh8W^RVZGCA+UKcq^`)<!Yz)H%fDC9;w{!J2UUs@<2PDo86S3Y*xRK
zKUe;cpW5>~s(7b<p)}8)=cjDGquTD<{_j)0_O}%0;O#0uWWP)4eZQ86-mh}0_B=WE
z2`#U-ahSVNaZG(p^~3Fbc*#xMUGZC$kN=h0NxVztmabFY$L^cmHjg-zq2&!V+7H3j
zPL{j!9mmw}g6&^ddv2KArFvb9R{sYoKVsXvutRY)?@|8+c3y?ryhQ(hTb${tU-Bd6
zUG4faY|mMd_Pc_t+Z4xIAC>bAR=#9O-@U6JRXfX{(fR-zr?PX(C%;?q?X~?B+N-$w
zZN7WP-h+$2tnx?f_h11}s-FKk^*8fAjeqp_Re$bItse?g|DiTt<GG~uC1EN*@(-1Z
z4OPA(PV0;QTX~;bwSLg92jPF#`d)kg%CY&V341P`xKnX<xa&CVw%=<_tk?3|5VhN|
zMRB{?cZz1aUsvqX^1XIm^c5@bYx7_MliHr>s}<Ms7UdId{QTW4e!H(Hx~V_6kE#E@
zY1ON=<EQLHTHai5<MKOeug&7U-_ECdw7z4R;t2>;JK^cdd)RwV*5}pV(7j5#UsF4+
z_PoD#gW3zdLjCl9QE8sN&$ZflJk_Y>-Ni~h`9Fno-iNDgzR1h2!$tO9vi2`pUpJ|E
zmUbxK2Kz4A8lX7Fu2H$USCk&QP0I(pRet6=)jt%Z<$0IRSKDuaHji3s*SqdD+Ri+C
ze_5zd{nj;#yZ=VD<74j)9m(4MA$xCi4O73BcD?Pk@0Nphz6AbK^?QG>a(-3HCtj`8
z{~H$f-HM~{!&=_HQ~jj=Mfq-<e^2~~^1gOGja}4vnrP28CH8wRS37?fj;Q_kF>R0k
zix%%~8ovd5-|V*EQ+e2RIjc|Wo4wUv*FL2s_I@^I??cP)Q@M!`sQruu<&*7vIuxMo
zn){WO_q8cqyG`3yp04%bKhpBRvl{=BM=kEVwcOR7U%c#nDC3VR*KN;v?RLITJ*_wf
z?S9pos{Du@mvuJJ)sblZd|GjM+w*DO4;9amA1L+zxcZN^`*n4UmUoq^zTcSAvCn9H
zhQ6)!@%DSC;WVwUEY|u~dw*`V=T{Fq4~w3)db8?p@XOl%_Md5a_o(u%^H#1=?Pc7f
z)YInO7i=D&;Fz|1%;q(wf>giHjuXEnwNqighjg>+W?qEiZT^+o^^R7(I-5uHdY9HG
z+wYcrTC~2%?ms!ts^5lhD4nwBT>mRo&Z}AVM=s5~%qw4J^P2JYzE*aR#-Yev>&xvv
z*s))69rDupBY)6(pZ`|-&0R{Dx2s%bxc0BFeV@p&`M!x~Re#vFJGe~oCVx-$roN^1
zu6BKmZ_)DMe5GFY`$zAOsJ{#srIXgrgw4Z6Zc@9h7ZhjkE2_V6kH)_tOX=jbTHlqV
z@*eiS7iiC~Wnb3%tW4FfwezIFuG<-QKN$;A+~GNjr{k+CA8yalB|hpeyin`wwkuuh
zuH~^$seW^ZmQQU`8gAFQ#C00a_8gV>v+o(v&#T;|{cb+h=JCt-tGzm#&zRew?Hji5
zPlrOazWcLUUSjWIc|B@x`HfmXX7dE`_WbYKr}afPk27<NwzKRCmG`py&XlXQU!(G_
zcAZGI>sFv$uY&Eo^ZK#1bEnEz+w)YaJ$F}rU2%H-Luu_}8V6UqFHYI{U-v8RuRvdw
z^PW|??p(FsAFk!`Ls~xa6{UIaSG=(=D_{9h<y)^-zI})C!S;Q)p;pTaex<bbHnqEV
zt<oa{N<(+6-cp+K$+q9i?YW@0UvatJtGMgzxhMJxwHyCItq=U7)~DM1fp?PfBiE_i
z$a>`~dzB{J@o~tG(*kcT?_Z(gsN+?Q^OU`pB>$J<^eWZz+7GDQ-rp$SZS(6B_Iwoh
zkhW*?+p5=W^JGWr6i>q)T0a+~`pKVBI{BR97_;}>ichKB)EjE2Vpyr)<60hT-vhc`
z)b8@vRNvR;hx;zg`+i^bJnjA+|FXudD@xl@UTx#}0i|VqYA@rk+Kac}SH&JsJ6<1C
zyk5stuKziU$6w{$-lhCVuGWwJMfnE1uk`*z%adQSxZbCF-MiF(sLj{K2P!_Fo3y;v
zuAd&8Rj=~Ls#lh!)YHCW^v9^Yn?3I(+Pp<Tkm5M>F7@9qu5#Wr*1yeDOxg8s&c62q
zMyS8QOV5k;{Uu<p>IXz>Jo@c-twY~edvktTA8zmS8FQ9jp*X5fTi$*L6mRFZ-zIIh
z$5!=QVCP%7eLpU-_ol2@)bCuB+VS?a^n>c()#lL;#c6x1OSF6;PW=b}LFL^nepfsH
z#_T)W@G{jqbWZ7r&3EQ_s^5k=#W(h(+AIIF(!|%*ZkHX;wHviPu6Ew#b*WtUt4e!q
zzNYd%#W!}D(la*i7;NL>`iS~V^;bOJz3M0DgKB5t%UbVY$3^Xg;>`HA#Z#$zsoz%l
zhWDy`sC~bPU(oW&Q%dLTds(7gpS*Ufow>)A_S)~8mcOZZM^>s{xy@U5+4ZmM4V90y
z-yc?%E1zZWZ_QDPqw6Ncm-T|yk9|q)*4p(U+|Ca#d!8s;u6kwntGrK;%1=F~<qP&6
z9J^ZMpB1fg?e@NsdQRoqH)@=G?fmMnd7@y8-^<=hT0f!o`&ty|++*6_4!b|Q-l~4Q
zSF61atJi1u=e>8Ue(a>;2(;sR>IJp8_X|n`ZNA8FtJ)d1@n74Z{;GS_j%StDSK4z+
ziQTt`gSC9E&HJ?1tGxFYw7nh~YNz>!N*A6{JQJT(|Lt8W?{Dv66CSG9Y~PWW+qh5s
zS>?R!dAK}Q`Qb0A{Brx<YWT;LU$Eb?rM{&8y6m}Nx!ng6N3=ZJuDks<Z=N%vb~7yQ
zk+s@B&#$T7q0cJc8l^P$F11r(=Xs@VkH-$RlWgCyJW4H&hqc|Y8EUWO{VJDOt+dPT
zvtC(hKhoY8yzRNV-}bAgT~GZ6)ZTKtf3?r4Ug$MyukJ35d$L_$Gd`-k*IA{Z_WU)L
zXWM1ZuX*)~x7N;^BR^EUXU;11uTc3z_B+R}U#UG$d%g>|=jw2qx2U%JQ<>f8z3sbk
z-xKPm#O49LzOJ}kzoqSJu<yYOK59Sqa`hkocco<?(ek3(l^^=P>McE{c71-P^<#C)
zhuZtC-v-6sXZv@_eutB4<@-LV^J}VK?Iqjq?K*Bzy$1X4m*JsuB{qNDYuBT8dp|9B
zN%cL-6-W0+RloU1%7@x@b;6GSoNz54wE5ripQ?O7r{XUQ)cDk{(e@U6N_k&z)vNxE
zmN(e(8)@Gkf{$r=@HL7zZ<$ixn^Z4yy;2{Wk1ncLe(sxUKmG$Y4(lx*yDtRCtK4!s
zu3har&ceg$ufl$>T7H+>shChZN9;S9kA1(4{ff%RTR!?mmG8PVFKXv?wS5=zvG*5`
ztJHt>9;L10if`Dy3x)n%?G)H??P1rq=67p6<2%*w(g&2T{j8P`*>h1}o7(N(uC(Kq
zN+<1n@Sj!rjtAB6NWS_T3D<VE-mCS&-%-6OPo*CAJ!0)mDnD1Easg$k=RK}8>+@RP
zen$ED_o@D&=e0cbdM%&(jN+gBy_N^QNAdL8{7vet`e}Ao{f4Vm-t%QGFaMU7``hzp
ztIeCvoK<_Sb|0Oyd91)hEg!S@vn+e>nX&nUKzrWzwdb&2d%ukCxAFdh>d)Bo;PPhW
z2d_|i=mnMYx9@hLk7#?2{8iiQU#N0kn^f+|&y^ms`K9Hp+8*y;C=Kq``Wbug7_#ek
z*R5)|dP(cEZ2!gnTH{jGt@^R{-6qt|my9r-Kgr)vJcnFWzI&tMs=ZI^eXN~oFSS!-
z^TExR#^X~ef98*N{Cw5gvE#Pf?z?AfzP!s%{T119UuW}&?Y6xoc75-+@1EiI`|nnp
z-x{;|)xrDJUx)42C7Z9BdRYB?jw&wyJf+?C9vE%kAG(t?UPE>tZeF8$zV=;U$wP7G
z+538LrTX)-`-iXnF1tTV?UdO2PM^&e6l_<0-!H5GN&Ed)fPGi?vfuI4j;p?>U1y7I
zp3KLdm+S6U{qjduZsJAl2iI#APpr-NH`w*g)80!u;?;kpyXt4y`&!-0s#npd_VS+A
z`ns!>E)A=m=f_p9^_NN~?R}#4P1W<eUgc+el%C1Z@zQJWyRG)S=JwmPKGl9d;*+3!
zgMDxH$yR$K8<m#Ze6gpS;>b9l@?-X1x@7m&tiP&!t8M?t3YCv+(D*dmsCuFH?^s+f
zy`S3spu_G*V;@%B69-kVIn>5=SjR)G-JcrnP`U79TA!S(v|*R}4Yl#FwfRk-Z>s;~
zXKg$FqSUiN%ZIboUY^~bC;v<RMcQ?|$bPTd`nvk5y}|l<kIK#1@qfnVQ<6WVb{E!Z
zJ1Sh2p9|JFby#~tUh22xJ8I9%uFG}yJ-pVwi&h*^za92nw$9%F#%%s_=pps9*UqcS
zThvdYU7x$`J5`p=&ko!Car1XoF5d1BwRS!<e^2pL*!$wroyynR_nd`pZO<Wl?#;6I
zqlR>~=ViZdF0${HbrmW<6sC5jeyMW9_PgKZHb3Z<pzZ8WQn|fXX?*(*C=Il@N9=qG
zd_mjYZ{PbS>^kC8sPe;u>c{(}`d_l=q3X3-9&7KnS$5w_wfU$HoA<1JUhU*qJl-GF
z{;IR*w2_VKKj&L2muJW8;4-!EbLqLOUio%=A8rrP_AR`mde!zESoA4vf8IUn$8Uw|
zEpJdcPkVowoKwFYmub6NKdLm<OZB6l(fT_3e(GlDOYhYdr_F2h*}T1<&7bF;Q2qFm
zs$cND`k%N-%RTKr?Xz9&_<m5!y<SoN$SbPX@S@@g|D3jS!meN8cc{J8pQv2UGHZ86
z<s0n#OP$RlEUi_$6-BC7V9zVfcKr&q>(1Vfs$9Qa-(0Po;P<G1SNnc&CRpVr?7ALq
z^Zg_CeKRY`#?$h>w!i(XeE+=G&t0zgC;z7SeeC*__j~o{Wxv~~wfXksgIZo~^Cu0h
z%IDd8lE;&3FL9aDTKf)@`hCS4{iM<iJ0Co3ex~|sTJCH2U9T>UlV_OP@o&=lqAbN7
zy<7Q1>56-;y>Io}cN0IGS1-R$<-?y)oaHyE-N{E)Kfvx6V>Tb{Q=$G`|E7AOgG!HF
zqvdrURytCrb~65^^h}M~ue0Ajj9jOBWp-VSw)x~qo4=d8pz^+3RKM1qC+Gg6?eVwy
z63-VE=USUzPqg`>u?p3zTT*#no0m?s@BVo{I`8`J{yLbhxIH{n{>U9lYpWE;nEf7l
z#_n%J_bdJxyWS_(sebF%wLHM)k5fGr-<ZAE^v|f>$VRoBm!~+r?fRW;^A~e}vi(=7
za&zBSy~^vAHm}$6c$?3e`n;A;+I{X&i{hBH^P%Wf<tJuUF4eA6sdhZ%*mG>}XVve*
z_f#(VZuL|9S;g7ht#s`**59S`-2T4E8T-2&Woy-+#}Sn)|D*C*E^6P?`fdJ!*1JZi
zpCf-ze(Gwa{=Zjw-<4WllB@oGe`0ajbw2##%9q*i!o2MFKFR;kckV2E{_onNc3bUt
zoRc<hlW6m0BO_|3FI4^HJgc}X9#kA<`?P+oZO0LNUd`xHdA9(S&#?LHf=84ewEI%x
zwDKJ_mcFUf!+z(JakJuco6zzxyWgI<R_*)0tm7<xN^u<dhsw2=XnDE4w*{0b-lcEY
zdiy?6WZT_r@2Q@4-(2pkeuth@`7V1-2-u^1uU+SYzoT+FRa(BcSoz?uDy^{VX2mM&
z{|Aa|=#=6Qw12N(`+Y4hTdwWcdqM4aAJX#F0JXPZ@2Ooj|2Fb7Enn`hdOlaGe8zjV
zJm(qp8|ta{j;z!2=wGYcUi)6=Ve_^*_Ps07zV~_B{LA1is^2i6H1yK%814A!wfX<9
zN7SzWgDRJ2_wR6fPf7i|;_>)}*2ni*-sX{KZ2qFdo`=rZ^GCJK%lQ4?#?7uXN3OT}
zzgNFw_8n&`McX-M?=vHVDi>?_n}E+LUwcCBg^z0dChd9D-=6R4KBx7rPpG{Kdyn??
zSAPxmKGSXAk<Pr!;`_YPLHpj>{DAr^m{dPgkrsEo+V%OcmM7Z#^n|^aH4mzvWcw~~
z#@<sVuT%Tccd4C3`@P@7LFL!pt2Ex8lMneQ-+jOOJMy&h6Y*-t>nZJzKD&<g*?AT4
zX_fP{?P{-5e)$>2<?&Ue%k6hdU6smv+k0%Z%~N$JYk7ywThG{atIOtnUF~_OYewa&
z;}nm#{T{4xv-&+`ziaKV>v!dHm2Yp?`d)ip_g&O@X4rSXoG`UFbVl1-m#_7~w<zti
zzjGBIqIRn7I@@2VdQ;vix7Ow*L+!b_;)^z(pI5m<{<@DYxBGN~y%+SqrZ~?mDm^r;
zw8)+p`cA8zvRztUlBqZgD%7vr1?4+p)K9_JRle8G(?0ti+57>;?_<v^wF4>_e5;l>
z*mb+TQSF4@tJK%7lb)ICFV@~egYA2;tHm*MM&;}5Ib+0*hq14#-tu*dvwBL~;hU{=
zx&7WL)<^M-+4s-|dtdBrQN8#ZRo?AKO3&EwGq+Ct=0$1wA-mr!*gR9Y{jMhR%W5a!
z-AYTort*D-im%e%TiWB*Uip71jkWPBKcW0YqsGg_?(YruKJWRo+MTiI?Zgvmzcxta
zhd!cy7Itbohwc5&&EEHW?Y{3fruBPmp0@uN%6HrKA^5P`2|TK_{Yv$loM-#@z3O)&
zQp-K;y<*t@{ajhR%7xnVQJ4Mu+ME^YXVQ)z|L>~()-NetyQFrjPb(k)Un*Z@;}Myv
zeAXWI>uS$qq4v8*f14i}{GIxbv~t6jsb1najqhIjyEv_nSU+}tp4p*#dw1G?vHQtn
zrs{isOZ|5LN%@5urIlByo$#j=zuUvAKVrW(=(G9rc$+8lvH6U4JN~+#wQ(&}`<3>d
zk@Ft4*Kt70Ywi8C%;uZRebmp?_tpQ5eOD~7-;cD~_ora{-n88A*U`_b-Q*vuT~8mS
zk*SJf&d$Rrn}4c{weh<`<qA$J@4HO>*V^y2CswQ7LpEO$YtJvO%~n56<>PI>so*v(
zkNvRvt+V^}-fh|*w+^La=TvU5eNP{@-}6WRQS19=6j!&sr_R~+FY(>F9{Sq*Uddf5
zKV|35kxwe${b9u&e6!;4-LL*K>^aHz39XN{b}MW@=e=9Y{ZFf2pSR+OzgzW(?RN|D
z_MV<$_xFN4_3Qd>>&NC}tL=R!<I@_a{#Z-XwH@vDJ5leK)NiuQFSOcoW56{k@9C~M
z5<jH4!tMRQ&F;6+Zg!ur_o6X-KAo}o!BBf{8Mf!W_)f(c@VMHowz$u{q38MXF7;b*
zTycfkbu95_mEUXgZ+<%!Pr1#P#3m??=s#;bV(qy0?p3|v=hbe29siT|UNK?wj18+)
zuixfz%QDqo#=|!LHjftYW3>~wTjhK0KGz?leDV(!SJwAcuHqKu=bltMlXib@w)f(q
z<6575zqU8)cI5-VpnSBwFV?+B+u>#N6&Z<&ukKZqE4W<sM(jSZH(33L+jC9we$^lR
zu+kFy?wMong}wGYHuM?A*<teqp>{nzbYAVpp4Ixu$CdirruJIxcR*hD{cq+g7LWbT
zpt@h>li$$tC7Z`|owELHzR2y*T0gW(@z2=&kbkwx`97d@$lgE0XH>q==CuRzwLW-_
z>Mz;+Ntx~MaQhxuQKoU5v+oKX_I)YQuIFxbYB$h+FL1=ZZ--v4_I>PpnM>C8pBdBs
zcfC>dI%?JaUW>P=R_mMXdAQ^^Dwk}}Ws|om-d20h9ecm}iGNY`+HKx@sY%O=ey#e|
zZ)kmMhvIOv?}={qo)l{HT)ri$*KEhnl06?*+IvJ@vf7Kc<7~l>+j9FZ8M{&ShZ>cZ
z+27;su<z)p)}PN`wcf+#CG-BIaqzU`CiZdl(`?W8ZpRh(QoGWw4VK=gawRrDaK`Qz
zp6}QCoKTII-*44lqJ94wzD?(aN1w*U>jteKwD<BEn^%cVQu~QFE57OvDsAmm>NTr=
zLN_X1`k9vZ+kUUJ-zhBF_e+n5)n36{DxYP)_bdO9^5s`3uGHTt?ylQZe)3+$7x0YY
zbz4+EaD&$Ou2#PNI;HXdQ2nB8m2XJY^57wrFSFx&#?JrdX!T$6bCvhB`HxDQFOIf(
zq_wvH3o_K+kpk5l`>xvc7}fT7+4X3xou>tM-7W7?`{DLIqT7yV|6<k8v-`zfoA+(E
zdEGAi-PXcmDwk;Qh5o-%|Kaw&P;sT=I+Ld56PIZmGL9%som6}iQCdHIztYw(DlWg5
z)V}`{YG<vzUj;;{Ua~#^bl;)!LszQZ*jrS7;YFo=E7a~<doORd-w*cLcbBeTtGz?x
zO1s~$ewSaT_Pn1_{h=7Gp9|3P$xH7wTeW_qMg7J8Qt>qSDIYMR^?~o#@l^hKwO^iO
z@!2>PS=<$QYQMqe5s$pA_9j26^8XJ__XC$#Sw4RJn2bMz)mGCsn>mXW=1f+Ym@Ltl
zvSfwDk{MH0Xjm+<Fj=u=g@wfuixn%TteCMx!(_^eDJy1JOj)6#qB3QLip7#8D%0P4
zzx#Z9y*`~i=Q-y-*SYTN?|sgLbABG5AOGFi>*9Gi<D#&Cd0Y>?wkXKE>&`IV>iD_i
zruaRpom;~3oBkHQUo|htdFshwyDpxWly`*dZ;tDoyW_fGOZ>cl&Bwy|d*VK5+5f`l
zjj_LM9|-5~I}*01#n0<D$9Z($&%=G4UlruNHeQEV^YJjw(Y&xtiU0oJl7ED8HvBN0
zw|ZsR?u^&B&xz~T&A$rg-4Z|dn)TOk+>$tdt$jM&=Z+;|UiJ-zad%%8_HT&aLpU0*
zLmc?OJQ&w|2W!K4n?D-PTlUp(-rm<jU9|t+@crSB#(Iv|!{){IcW^;C{&1Xk&c8k!
zf5zf4-o6E4dt?0G@A<JmuKPsL)3%es_VA5ioK+Ww?X}Cp{)aY(`(ND~whLbm<86)O
z|BB>r-`nH5<hp0V_2<R?+m6e^cq#GwM=Rp>(arIDj<+lc<DP#<xWDV-ym05{FwUuO
z3)g!sF?^qLZ}@!Y=fZUt#`W1vmxbeRnF-gsI)3hS$$jCx16PFe*2jPMZCN}&TjF|S
zU;KW>k-i|$mc%gL`t!r*1ILANUU)I=zv-NypPfGm<KFat>$qoz<9EdG&m8z~_&jez
z*k1d3IB)$;VSCO@827bx;qz;GLH@NThy6QtgzXdY^W_(=2%ncc5RSk5#30X+Plx?$
z=LNl-^IRBb-XlT2CzgiquiG0w?|N7G{&4KC2je`m=8f?E@_2pw#@~eVHk}%-x8&R5
zyw~DB{j9j}J0o7-c=WVbj=O_g*IpOSJ2}ql%MQf)h@W%c6o0<%cj5TMaeP=F+vBON
z;d=W^!}qs*D#*8aPZ)Pzyl%Mq+u^!f;{JPkZ#ZwuZDIf6)nR*FY$wZ34CmkSYB+9n
zJdbxS3D>!MOW58S_p_@$5YE3T&R2K770>7Y)qinZ+L0T^TOPl!yerPDtFyxK>*M<F
ztP|sTsSR>0`);`2IYr_8z47mr7M>EWyY2LF{w>di<8FE+oVWYyVgI8Kh0j;s6V9J=
zaritZ{=LDHuZH7}ribmxzYWJd9oKie9}fGM#roJ5$EQ8#hH)1DJji=zM%b>M734Vh
zzOdaI&)+3EVVpa6hvT+x3fEcpn=sD$;qd*bx#7G+!{Pf`XN3JnV|$u&d-!~JNwDW_
z@!!=wd~G;>d;A{Hk!Qm=r^Wef<p;xcH+?3Yzw(zse=mPGocD74KGVXuZ#o+1iIwql
zsuLav$8C5mZ1=|T<CeJoTo%W*C*pO6yUWA%cgF8cuE-15KmVMty>2jE|Abf%>z@yD
z9g6Swta#n)@RD%7qvwb7QceovzOX5LKH3uWcjFJjap&9?zTdkwjKAz)*uOfCr|WMB
z#~&B>R|iMKaXUW~wtM3KVaJnU{8e+p@oVl3-ye7+$ay$^zOiLj`2My3Tc>+A9JeDi
zmh-|e&a!U=Io8}5&foLX@Of*TSC+@?Neh$0_Zz<$#@YTrIRCi3Fy7PgdsM5(!{@t?
zhU0HJE{wNocaZ0_cztHoyTbPi&x`jj4%@@u4BM0A{J*6+T<46=aNT_mhVgHT^|R*h
zvHbrF=RFb6<BI*^yoK?4&W#@lpSNrX+gTqE+rxXqcvmkApAW@;cjS9v+($2t$B*rE
z_aDOX`}YO;55#eDT}{~k!r^fIsqs3+x_5@pbLIs3Z;Fq*GG2E&@?se0xVSFZ@VRjO
z-J8OA2mTa3ABo>vymobv^Nj1m{_EnpVSl{-ynQ5`w>e(d-Tu3vmyPlDcl;s9v7|ff
zUl~6)UJ|d*u1pKxZ`%>%I{3b@-5U36Ywil)Z@nh$-%=6A*%GfW?}_`Jqnm?#tK$1v
zJ|`T1_20wsH~u+nj~fo#eev%SR>tp-y%w)utvowi@6^m#AF&-Ri`Toi+!yq*E{?Z{
z;`ga;iTkhB>%;gdd&4*j<M$|5#_?czyuPvF(jf1WGs1PQd_H_W7}xLfCd2+)eh}{C
z<!^@TrmPF&o)y>Y*IgB^w|X*sf77Mm^WodWcFCsrbNt_*x%$p<on2#LoTuZsb6Q+K
zu8E%u@7x-$zag&MUWnt`k$9c{<oNy2!#@i0-4y@s`B40R%d&XAcy(MK&WYbESrXTU
z%MS&)w#Ls@H=GeZ&uR$UJvRsWcJzkNTjIZa^jdNFeB8Igbq~hhU-`#yU)!Gxde{)h
z{R7_($8EnSY|n}HcWUhSJ6gj2^S=?Uw`5TmXZcHEobB;*;X}8E{oCTWx-VW|o)^FO
zz2S^-{%IG4@s7JN=<i^>Ubk;+*njG180Wh4!uH5Z;k;dO9yoL$?4J|AH*oFT@cEqh
z@6@03*D%h;v%+>^yk2^KO_2BHcZK7(JrO?d`FoIK>wCiID<2E`+xOqFed4d-`YYo)
z;N*C{e#1jy|IVav{>tQVz1RK_#(z4Fqle>sHY<Kl=d{D&yxmuY>urvIzkl@2FwXg_
z!gf<!zi)~Ej_&^0e|G*WocCH3w#%;z+f5zex>q-a&o2~(?fEx^{j1~q*%RlHJ%0>x
z?Ehzwdq>>2Zv4OX!Se9^#`yiAm*YHsD1QF6|AH|7%hU1ralf<Szu~+y`osQf9}mZE
zyeNF$68}BiljC)=tE<BGw<d@0Pkk%g|JwNX9s3uCd3f#maNLrE;rkWWhR@qx51(I)
z*C)1J9gaWa@39^-!*P$Uisg*|p2ONWA8d-_!pU)8vieuyxJ_|Abm}Rge%d+^?(3X5
zufDK8d_Hn%*k1WkIB(DQ!}ZQj334s_R@kojPuT9eB7DE_w?V$WHQ~H7-WIO2VrlsP
zU}4z5=3imE?5uEK%l{Y7JMPV}T@kP6A2}h&vFn{-|GE|7`0L&m&c7vo|7%0Mo`2_G
z!v5WHT-{g~<U1>l+YjZ3aULxU+ZWy$#y>004?EX{<2T0d6I^mIe19<Bzj8-7Z%<#?
z9=#|WzbRgqUXmG(UmvfR-!c@wKjZQs_pXlz`Q}7ndr6$9UOpPW-x2qx$Hm)y4~6p&
z{wa)m-Ij3PmdtQ`N}N|#?+Bl7x-cAfczw|KrVGP%XID6HPh3a79KV0`@{3{r+LhtF
ztFMpmYiIbp;TPfa!9RrY56AuMn&ZQ~?kx-Q?O7JKC;TaFcg6AU$o1j86?0>G;`fI4
z#PRW*c-`rtE5do(eiE*`r#YPW@+;x`o8mfURvb_F{a^lypF>=7YdCIeyiRuN9bvrn
zaoo8j?q@fYhH+QM_3et<aJ|hJhWpv@vG93G{GR=;sUUYsQaEozV)%aB_Aven@%r5*
zCxq{>j`e;*PxyXsY0&SLZx7>~_TM1qs(4-R{5Wp!{Bbz{(YUTY@Y!&kD?c2@S$I+y
zXXTCI{Fnb8#@qPr@Ok&A!sl6)VSC(H;_J@~pO-uvwlBXN#@TRs`2MWB!{<Zw;rcJc
z>uK}WhU1TH592=__l>Jw336?n2<L5y?f0w`!f~78_t<8|emL)juzyutPp^#Yv4ef#
z`s?E7j)&uMcg1zgjn{?ipY=+R>!z2&@t6E0T=(vqf*dbohwUxj3dg0ShtDaug!9iS
z4D)*Bo#FH0IKFH+5RPB5Iczt^b<?V$aQ>XMAor2D-&z>k-@dwV{ml!)aR=jd$`!AN
z&xgJr<Xjkq?bGqP<J~*LdB;5x_Mbly<ar^khYrQ-j%(xhZ0?MIhqN|5oOjOKV|iW-
z@~(V7Y%iG(+a+g(`+O~qx39(TIUk7EY1e!{oWJe^;rgq}!+AH|5#(4O$N!`8_4Z|i
z{VA7(?ZSAyb@}sQoV)YF{T}#b_<na{kaK%U*xtA&>|YtLi_DAvF4Foqf3A-6`nK5b
z_h$sTu6{C%yCsf8+vE3h4m}y<ofYpt__-j*wJ(MJkA5J0eyB2ho)iCG{mytEH@+>%
zwd9lGxD~I(*DDOi-<TY>`#u$}fAZY${kpPn-rD`)^WivN?1=OE%4fs(yYj>NFU0Fw
zJK{cQecY$*jn~tc#C7uecpdkaPX|4%kL~1~_k{7zPYLsR`0YWSW%2XABe#X??D}#z
zZ|i@;=M{Uyai_+0`O7DU&#ONf<en9;zotAE&O0ae_pNcBzWZxooH<v7^RE0{IB!jC
zpIhR(?C>M;_Y1=~XY_>6o8r8Bcl^9>@7ZCz6XJEPqw(|D6<3Dy4qg>+Uk%4y+YvsW
z@WXK3(=G|yb4tT}UHPH#{h?dJ{&mNN>mIy0>|YzNGrjPO@coWB@7$de#=rXhc)a-i
zfO&B}eamTK{3CmV-gn3PS@E5)|K+&eKA0Zn<NQB|<4!m!e7_{_KX2I?uCs4ZxX$j_
zK9}4R<Xjm0>(g<Z+#37W;e}zmJAV@HWBZxm{3G#s%ik9E-}zuT?xFFpz5DlJ|Avwv
z$Cmgx=0o2M`_I`G#+enb_Z+@69CvNpXRnL%(=E4!<IhS8avqM~uh<dyb(h5J;;Vid
zuDdCo|6TF>-%p<y&R-SxWe4K-gZ9P0d)Pb`uDd7BkE`PTXH~qOxHo=(_@Vhh-aG5V
zbq>VqvMEDh{G;*nggtY@_j~UO<L>@t(EDo>;q!_(?;Ktk&RZU@>s=SG!)%-m*Ew!s
zxZl04VZ2>C!}iLf;rpxOI&I@U;q$>bkIva1j$0D<4Nu2?_Rf2Q91AZD+pY2MnJ$?O
z*EueJKE6L*AKe?jZ?(QK$hq#;_&OJb&xh^|<D6U)&OaE}o7>I^$L;<`IPTgx;l5vs
z`=1x$_<G$L;rrFGom{di9Jl62VZ8l!g>kOi6pnlJ=5Sv}*M<F0{4^Z5=A&UdD}MgG
zb}GoV`=jCbRdF8O9pC3I7l-lY#P9vA-5bW+_O-BoeOwP*{lz#h$Il6`i|ymkwlMy@
zr9s}aejToVQ+L?E@y4*db5+=XT6Zj8oKH8z&$D;Mb=b1_y~Qp62<NRYiML%rp2Oqe
z{72s(w)5gXV^b{m!UJLd^0>b^bTHh{jl0A4v^Y*4`e_*N#yI~jzb44PEB3$T_l4uP
z$M55;jMvo<+!yqC!jky<Cj`B0i{sFy*TeUFFAe9vd?XyV;rOtB?YqP0%}rrDC$3*F
z`ChosQxn5^cYisIyE$GjzWPWwf5npU{k*S-?S`*}`&b_LMRVfy$XQ<t_p|?>Vcdmr
z9dPuGaNR>SVS8mp824yOIPTz?VS7&eJapM*Vf<_3_ajdm3*%n0K5Vx>63*Wg_ea-#
zKFGDTJjj0}jyGGY!|~U~{ojGB!{?il!*<>;!gc0t3D;l0ChR{F*E5^q^}2a$!}aDQ
zh3~h=&w=keIqYA)E9~F&k#K)&-xlQA_^$Bzgm^vj<$-XW*B%Y~pT0j_|Exn{oKxOa
zvgYBQnvJJianIX_-ZQh|w#(jl>f(kylW*O2|IIJGwQa|*-~7zI=Y8OjH%@-z`VW4s
z<n(V{|D#{NdgqJR{O8Bt{LVlA_TcaCd-mtI-F4pckKFdqTd$w@?4$S8{NldvJp5+b
zzaPGB*_-!&_pKX_9$C8k=o{yK>#-j^bNL%bzx_b_Klf~Y>_5Z*UijCS_q_Vn#J)E_
z_}mo_y#1+vzxu-))@<zf(u$iNc;kwPpZootU--<Q4<)_%kH?-p?~U6&v;EWmX!-ej
zpZ~(opS<m*D~`T+>v{Kl`i(8;{c-~#|FHF?``=nVwda9f=8YYB>US?abIRuX-g^8W
z_fOyO>c+Qje*BH!AAiGr_rChpQ*XWT@duxM@$o}HyW#w|-Z=C4^WG>pbl=3|&(2%+
z(svGSdB-zZpQ$?ek^bLYbKf&heBs_(?|Sv!=Y8PA@3>+2(c@ou`agfX?Zq#j_nzC%
z-TL_J=Z>B6)f;YmvEiR@-Fw@6Z@%L4XWn(gmmfd#$RoS5_CI~zHy>Gj!*x%7`<262
zl)ZRh=Jegq-1d{(?)%zP=U(*oYo0mxe=GN|`RvA{Z@uxge}8f2ts9^J=M_&Keq`VE
zr=NMz?KN*)^qr?$Z}`K%Fa5(S+g_WT*?7f~qYI~>J@d>@Jn-O?|M|h@XTNjt<@Y{y
z<acvsZvXe;jVFKY#2-Gj;^Z4%J^86uU)}uV|K7NCWcB7ZJ70Oe;q0$p@xcABTr>Rq
z4M+C>@!>~S?q0F;k;{Mj$^$2#ed+gZz2@N?W~QI7_}!y#UHH?HCmwkH?p<ph*tg@&
z-#zP3oBsd*rTPB_NJkEeP=Pu$q8-B+!z7aZQPlZZjBJ#k91Unj4~8&-X(YTYiWVUQ
zxhO*=YEX|Rw4wuj7)NwGnUIbg<f9bTXhaLTFpM!ICy)tCk%tmgp%x8jLnnIBk5Nou
z8X2?5g<@2q39aZrH~KJ+DR{Le%0WIn{*1KJQ3a}@4T~Dlj$U|N7$ql>3m$1lg|O5Y
zHJ}-7=!9}L>W5{6Xd0F!qD9DpSGA)8_{nHg2CZ~d52b13@qaW3<wP_NZAFxc99WW!
zl&Mh#>fjakXaJVrq8TL5CKo(Xjk4iUR#XCy2%{=^)g$VJk}T@S1e8ya)-B3FF1#KT
z6{8F_P`*b^=)fRGFb-{FWNAIJOcQw(EAo18RE;{cqYJ|r!z7aDkPVBm6nQ8?6&lcq
z9`s`fqnN-n65dXKScD7|pbRx=LMys4h!Kn<?H%k4naDvAs!@j)v||91m_hPfvLPFJ
zs6s6o(2O>8q6b5mK*Bt7VG%Nrivm=l9!+RP2fERRaZF*sJIRH7RG<!xXhAy$FpNng
zzl-irh;me+0d45PC?=3FpFGGwF3M1e8Z@B;eHg?zrVyP#7UZA^)o4Tu+A)A(j9~`J
zCz1t=k&Qx>qZSS5#}Fnkjf8iT35!sGVpO6Yt>{2E`Y?iV91C1&NJl1ekdGo%pc-{(
zK|8w8iy6#c$i7gB5>%lU4QNIidN71hOd#PTIzs`9QHC1SqY16(KsWj@h!Koq3ekJW
zicI9A6fNjNFUBy586+>FJ1j*u@=$^*G@u!6=s`b5G52KhAqxd4Mj2|*iVk$64}+LO
z^j<ndCUTIEB9x*6)u=-wTF{Oz^kNt@NIr$E$U_5~(S}a+U<jj_z%&*uCMU8`fHKse
z9vv9O6w*#L#mGSsDo~9&w4)aT7)JT~=mrgFLnnGLfoaTrzw06cxhO^%Dp7+bw4xh*
z7{oY^CB_9vM<#NRk0Ml{5iMv(7kV*_F)UtU{*aA46rvnes6_)h(Ssq3Vj2k_ATKhI
zg<KS%7&T}@E4nd=5sYIB(Ff@b3y_XX6rmK=Xh9cxF@xj`av~dfC`T1)(SSDepdX`{
zz}(ZwhAiZw9v$ez2&NEyh#W{qCUQ`U3bddX!<fVj=ATXuEJYq_(Tp~9q6edxz%&w;
zk^_s7fh^>r05xbu2l_CG5lkUEgIrjEbYvnQMJPoD8qtnk3}6^zn8ExHlM&e{L<wrq
zfM&Fz6GIrqG!o7vD;6OGxhOyxDp7-aG@%t8=*A#MFom>CG9wfDC_*VJP>n{kqZb1h
zL-I26Vkt^cjw;lm4gDBJ!bix5MaV!Fa#4U{)Sw<sXhjFQ(T72dU>sA3K1x<BKsqv!
zk5W{l3%wY|7$%XNMNTY6HVRRNS~Q>yo#;V7hA@F?%sq?TC_^P`P>&|Gq7Q?ZLfXg3
zg>+;h2c@V$9U9S&E(~B2Ge|z0e8@&2%2A7Ew4nz>7{xR)vgr`HC_p9Z(SbgUV+zqZ
z<Uu+zk&hx&pbm{_K^J;4j4@0i`Qv0lHVRRT1~j7$Js83SrZM+idO{WoP=<Omp%vZe
z!yv{ng|r;9ArnO?MK$Wsf-VeT7-N{k43d|dODsh;3Q>gyG@}ze7{vspG4~VnhAiZw
z0A;8_J(|#p4s>H23(g}Oa*&TAl%fueXhA!AF@PD&&m|YKk%vN*pd3|bMko3)iU~|3
z;e0Y;5i*d4Toj`cHE2Qy`Y?#-0y@M3q$3AKC`C0I(T*<kVi;qXLGmZbip5xpY~-N?
z<)}gfn$d$%Od}zWjL1bXDp8Lnw4wuj7{L^x734!Ea*&S-G@=E)7{&~eFC-HdV<`$z
zf^t-$7R~6#D5kOKBKkrWicyA2)T0%H7{?US^2vfs<f90ss6z|7(2D^KV+@l>UP&fo
zBM*frM=jbgfoUXsiaf|d0g6$NR&<~ngBZaS7F<jg<e&m|XhaLz(S=^jAi02UuoQ(T
zK{=|>fM&FzAETH?!YVd}3}hh}1t>-tYS4sMbf6o37{L_MK21L4pa`X?Mk89#g<cF`
z67xSpJ`|z~&1gd>dN71(%q^rRWFQyCs6-Q5(TypjT|!65L=K8jjXE@<1??Ed7-o?D
zS#yL!)S>~M=s`b*FoC(BbA9BZ7&T}@D>~4PaZDkth<_mm`6xvNs!@kVbfFgm7{(YT
zF@xmQbc4lMiaZpe1XZX-1Der>ehgt037;n`79k6{C_p8e(25RpqYr79(izf`k0O+!
z1p^qv43-v?1BEC-IjYcrHguu~Lm0&brjf9QJjg;W%20_Ww4xh*7)NxOxkC=}QG`;|
zp#|;e#Q=tp`~^C~QWT;bRj5S+n$d<%^k4|1n7}j=O6Un$$VCB)QHDy?qZQp4#1zuj
z(ibw3gHlwW8g*zvF9tA%Nz5Sma&wBs$VMJYP>xzOpbbNqz}zdyh74pO7X_$9JzCL?
zL5yGuQ7QS5j!fjE2&Je-Bihl0VT@r0^Vg9J*~mi)YSDl;^kWngn8w^Mk`1{iMj2{Q
zk0x}W8+{nW2*we8iF{aqbYvn2MW{eE8qtm}^kNuen8D&QbB#QdqYAZXKr?zUgb7R|
z;YxBM16e3QF>26+R&<~neHce{71@x9d{m$gjcCUJhB1cZFVh{ek%tmgp%x8jMjJZO
zgMJKQ6w^p3Cm%9UfHKsh72W8=2%@X$4LK-6DXLM27PO-m0~p2_W-$LNbcSpcq8wGI
zMH_n1k0DHB?pMi!EEJ#^m1sgY1~Gzh99xuKfE?tb2o<P93)<0zUJPIoGe}-fPpCoz
z+R%v}OknQUTpzh8KrzZtk5+V}4}+LObPe5L0Wy(~B9x*6)o4UJdNF`8OkxJfmGp$g
z$U`AYP>xzOqYXXi#{{M^_gcC_E(%bLO4Ohpt>{2EMlg;kL|-Q>@==6FbfFhxn8f^V
zuyYim9JOdbGuqIJehgt06PU)LD!M{Fn$V3wj9>~2uA?L5ARk4jKph&<jxO|K2J^p3
zFIb9f<e?Dds6`t((Sv@BBH?=Wj4b4$0A;8|D>~4PK8#=-Q;4d~BNiYNImkyTs!@kV
zw4faW7{(YTF@wb$$cj7^q6D>QKpQ$SiV4j97JVTD^=L&O1~GyuMBgS0icpFQRHF`!
zXvZ+dFo_u?*N_9*C`T>Y(1{)-Y;;{@p#Wv5K|MOqhe3>E3ek7y1?eb4DeBOIc66Z^
z1DM1Nmfqm{$U`B@QH5GGpa(;kz%&wS$%FzFqXtdr#vsNqg=iC5kd92`ARk32MKv1H
zf_8La0F#)({O^(tg(ycA8qkbR^q?Q3m_Wk!$b}5#q8MeUK|Pw#iVk#R5K~C2V@F6w
z4)RfoYSf_xUFgLC#xRK)%)in6AsdA#M-^((fM&Fz2mKhrC>DL6oG3ss>d}f0bfXW0
z7{?USen3WKA_t|YMjaZ_ivbK{3^Q0<Pc9Uq1XXB2GuqIJ9`s`Z)5y4qtsxi1s6-Pw
z(1$^cU>sA3en>VfKsqu}iVC!&3j-L#43d9DXIPA-$U`AYP>w1zqYa(tK|h8tjYSP)
zL>6*UfMS%P2KDI1AVx5Sw9Vv0Ix>-id=#Mq)o4LGx-fuYjA0TpNd7Uou^8ECKr?zU
ziU~|3;bt--0|h8UCF;?H4s@drgBZa$jy<eQM<()7foe3O9Rrv|@-5`RQskio<)}pi
z+R%v}^kWF4m_Wi$#4#*F2C`6qGSs6L9q7g&Mlglwr*w#PWFiOoC_*W!QHK_Ep%=rL
z#0-*~=nYGeheDK~993vQ8%8mWge~Mm779>?O4Ohp-5A6a(tbuJ<RBlVs6aIu(T*+*
zU>IYV#0-*uPA)7(9tu&826SQw)0o>#XUIS<icy9dbf6D|7{L_Mwz4<mqZAdWLnGSJ
zivbK{43n6_{9lj<OOcH{l%oo@Xh0h}F@#Y}AmNu}L<VwEfMQgl2HhCM2%;A9VFA*S
zi5wK66cwmLJG#(|0SsddlStl1KIEYgRj5S++R%>)B-~0SWT61XC_@dJ(1$@pw~+}8
zkd920q5^ejL_50Bi(!mm5;IuZN*?5)5GANWEt=7Wehgt06PQNAcJqoX<e~tTs6i82
z(SZ?6A^H^=k%>~&p%E=;M;9hBgXCYEODsh;@=$^*)S>~+=tK`DFpY#ZIzutaP=k7;
z?Qm_RBNI6&MK$WsjxG#f3^SO2I~lMP*(gK_s?dODbfO1C7{%P*&<Ao+j7rp?2_5Le
zAVx5SV=q`NKsqv!k0O+!0(EFX7ltv086@u{9~L7Ug(yKes!)ptw4onE7{xRaeoIbd
zp#a4wLnZ3bgl_a<5F;4J6rwxm5(|)nYP6sW0~p36W-z~l?vRZ_l%oo@Xhs`4F@#Y}
zAmL6ng)HQv0L7?BE4tB#L5v`}i!8`QK8jF*YP6sWy%@kS#xR5A-;ocCu@u?JLm|r1
zfM&Fz6a5&%1g4SD$<C040u-YRm8eH6`Y?zQOd-0PtjIwTN>PDo)S(@{m_hRI$%i}?
zq6ForMKgLZgoJzO3mM2lF3M1e8nmJV-5A6O#*x-VXUIVjDo}?;w4)2X7{(-Kuy_|e
zp%7JQMjLuCiU}m#%eJrx8OTB|%21Ccw4xh>7{NHA`^ba^NJl=3P>KrFp#{Adz!)Zx
z+)YndjHSp%A<9vO1~g*`qnN-n5_Xdli;#h0l%W#!XhJKxF^CaNA?*+3LniW3gi=(X
z4(;f|0LCzh<Uf)Ti?I}WC`1X$QH5GGqYXnC#RR62&_h;ap#YVrK|Na0he1ps+CxTU
zA_o<yLpypgfJr3ZPbOre5ap;sEgH~_HgsYLqnN-n7Ck^`$U*_iP>&|Gq8oh}#5kf}
zIzuM%QG`-dqYjN|K^J;4hUC5E!(!y2995`A1Der>ehgs(34bCRGLVH_6rdPos6;)Q
z(1C6YVg%!uLiA_)Lnd-iiV9St9Ro=2BO8_?4<#r^6>8CpPK;t23H!_+3Q&wPRH6p;
zXhk>rFo<!aJxFKBL=K8jfjV?y0K=F>@?Yo)*~mjVs!)qIbfO=lNa!aE79k6{C_phP
zQI96Hq7Q?ZLi$5wK@Rd!ifYuM5iRJ#FeZ`wS2AHK@=%BpRG|TF=)ou^FpY%2kqueM
zMFEOYh8onP39T5!IMN2lhD_ujA4Mod9oo@_UJPRl$@|HLY!sp#Rj5S+hA@pq50eE2
zC_^hc(1#I>V+zqDWI!fzP=PvhVHnASu7^Anq8wFdMh}KCifJSqa7`4T7-gtIEBY{w
z=<nhrGLerWRG=Dl=)wSoF^L%@|AWn9F$z(RDm0)OJ?O_M5{BG6GLVH_l%Wy}I#QxK
z@0yqS-C+4;DbZrTw{7(fdB-KG(bV&aQRQD#q5|)NHxA8?M!YOJ+?gEZyeBEDST#G!
z{ZC4i`M>07so!vPKadpFeLp!WJ~cV2xho|aKlXy+XJ<!q(-NcV)oI=rNR7sxO7*;T
zcC>g$is$-CQO%;%sKW0Qv$B$+vh?Jr({B<g*Ca&?PD+f*|DGB(`kO83UWRN~ni?fI
zX6nbuQODY(Xkd0?)cR~{H0a&-y!6y)WN~8Dos<}reJdqO{-*oMB-5PKsOxP>QO<qI
zQRz!$@}6|>_LOMqLn+bBhS~a&lxS{QQWQNgJ4!e{HLAZf)w@?IQTw8#sHG|;Dmj6S
zPo_kzA4-nOdXl0-zaMD(Q({!*eer@b$l&j(RQXLrjo*3q_{~+;U8yEDIchpIJF50B
z|KMultVoP<no_*unG#h!nH*Jk`7-<X<Y>Z6o_)VcjK*fAMp=z?zcE#wH+EBERM(jr
zb$-V^Hzh?q<gR};HLCtFS(6i^xnD|)$}$q8`twqwjBCu%bV`)*bNBeUq$vHZ<f!&`
z*X&4&Ixn6bb-j@sEq*j9%G;k3E%<MuwY$`)_T<#4{fmjwh~Ls=lRur_O8ma7-~n<U
znC+d;*-^#1w5Y}3_$=@{wH$NVe{W*c@|d~#Tw;{%9reZKiBZP~lcEB;8t+exy3S0D
za(|r|C9|0!@2)TUQnGbC^ZC!&QIC1+bARPte4YO<I`uaR`&OlRpCvg;yFEE7+L0Qi
zz0-MLW?!}J?b+E;{Wnshrk%;r^hXk-Y4e=_TuM}QT3S@X9=pld_>R<Q+6%YS?k(4E
zGKR@K<!>F-{b6>L*-gjG-TMuxQQ2+g{Ma0BOO0CCRNM9D=SK5%A3GeG9rgOX&CveD
zXu%*|oG?4e`gm%T|3kLpp3^p_u$|<ndoz2yDJ9C;@4VCTJ^H<kO)q6%i<6?sccn!A
zUVzPde0EfPc~Z3W4*DERju!npF`D_X>z$t*6}&Mk>V6{0GfMw%NQ{b)=L^3w|L>R`
zje0RR>m>8!yMccsMMa;S9gWjh(G&E2ihKQga+L81`!M$lHnF=Q$NnHGO7<IriFeue
z<m{+(JAI#+8Wm2@^6Wn?N?w-~joqIZrLnCZzcJ4|IW0<`n-WcaJS{5vuY0_Fc2wsY
z)#h`OZI54KPA^J}^7&-KH<P217u+LiSMo1*SN%{@)O>++k7KW`?DQ*%YLCPy<9+Va
zaT#>Ecz#Nh&4w4eJuO;vvHM(_7LERdZ(f-kRsT0BsuyDlbIeViardwh_R-__AT{Ky
zTt}9N#S{KoWPd|nQq+GL+wOF47n+-O#=D08PIHg1Cr2aVMpKRZ5Nir=5u5xS!r_nd
zvuF73PCCDve>BgII^LNS^|@~Cm1$9baavS=9RHXUlU_)S(%C_6M`G0X3HtgQf4d~j
zy9#Mh`zy1f?uQbii3iy9F!|0-@!U1pI}9n&;N>aN{O3}|li5)}y=6T^wx`9Z+mfR4
z^HZ&5ntOJX-9jdDp`$$|8oHHTh^O=W$$LXmR7$_Ke@cy7*QG|u+moWf52mU6*~C}e
z`xU9tV!vJMVn1{LBc`028qGZKz9;G8?v$u0CnYNV6FrY4c|K^)uTF~^UrvoC{H|yI
z5Bb_I<DO-X?&8Y@v!lv6Dbd6}^0$+jE~@A?dYLb-PxfwTN>s5VF)C$SgF~)=X-d@H
zNNzrr@ne2?lJUguB7d8(f-e=FmmHOgvnBJAqRdytwqKgp``wSfwNU$o<fz%abw8XO
z<)7{QjY(0O>o)NDsoi4Qy(v-87iUL>r>4rwWV+IQxc|m|V#32IQAZy?Wv3bJa_D_2
z(IWA&ZlOHV#vlC6iHUntqh{ByU(J4Y^ZjMBqh^02V*an>5^*)%@3wNbxTm#=(UjO%
zerIY_bq4=<QQVr777dGgRX<9M3iru3JDlew_=;t0w_i+tX0~+-_Pt#Gc##ZG)7zE)
zT}LMQq~R(#=buSYf}FG9&$FZ2OW9_=vE{yQd9i9#e&{EcJlK^_|6)b*X>{Yo|8~CJ
z^iS9R7dw44HOiZoKiS=aV)}U@B^pU!^FLwl7qFGTnD2KUi-9S6ceZzjIK76SoSPK2
zKE_AbcE;m!o><X4mFT@BInT8wPUH(>&*b04V!AIj{={u`{`VB|iEi#O@As3loSe@k
zMx$b0fxlN(@!G6tnl5JMvthc)_M?JMF=cYInCC|TWnXabv)SX3#Ax7xlxX;r<f!pv
z{%|GR^SiiK@gi3|E%~GS`x@EC#PlZlkp0$*q3Px9{W|meJ2CQ`=I4F0qluE)-sNRe
zYg427?4n#g@8ib<3F7>3_=&%dH6;&Mp2H@NryI6W{$AgS(Yf|T^gN%>NBn;*J1v^~
zPWfbtJg!+?;oger!+2AV&5n{^FwgvDYCxPlnf-ktDVj-Rx5tT{ksRb+%D%<V#J+5L
zX}z7FJSg_P+x*@wh9t0yE_%Gu`Ss%L`_rO9`YJe`zQw=#tzz?k<wm)nrJjF&lt2DL
zop2}LOP9NPQlin`)M)ZGpXJDezp9l+#V;{2{j2owfP8!xJ+3C_>#5!i5u+E%Q%A+Z
zytJtDBZ<}_NxDp3B?k3~lMDE8`Tcz3JFdUcxQVXK4(Ico+N7i?>&;nF=3C;BAA)4F
z)ArA(QT&*rHcHgDB}b#;{luK4XsB>@H1;If#KZX~(GmY^ql-mfQCqzwC#IM)@o*wZ
z4w@(497u{rHmNsSQ>>FDM+xk>m5-Mus{Pin+hKAoONp8@d>64>d44oXiN@s5Y_-_n
zS7t{`>3ptxtNNlC`T_TUKL2_*o4iwerjN|C`1qUTV?)J!rtfG<)T=Itz9Sz$k{B(1
zfnEAhPRl`llPI6eXCLy%xV&1lJT;oj{`y<!<$LseotWltM0FljrygRTKj0Gsbgxcn
ze9%~Lxt`w!7uM4u+btRAPXl7$$KCJlq-gwfbC9V1`MG$aMw<L#QZ)LYoGJE~o8ydm
ze0d2S-bm&_<9wcdx_-^&^2rC(GapEcYCkHD`T<bd$M~N(*8h|kGhq(dahvN`UBQ>+
z@~LaZ2JxoP_<eq7-uzL1a%}wVV*jyPhn(}DBF{gJE7rG^s)h2!KQ;7(IWPXi?5KBv
zxUx-M;O`XVox>LY#}~!ca{dr~P<>P@kKg0Ezf>>PiLv6~T)OKLf9m*h-$U%@yW~Gs
zuVk95QT`{sw}=&e3lpP)wR}!Yt``f^E>)l1L7xwqV}Dm;`~>5lFPE6le)mzB${ysO
z<PLt#e(DR<qD$RxHUE>}%CAfG`v-IW5%Z>wZf)i7Zzo4`YLx9>TGbJm3C?Ak#o}M{
zCiC(P`*r=U4lzP3tGi3yQu`LKW^;aslzWG~mXYQib#a$(cC2D6?4Vt4C|k*=kJWYl
zHr({D)f`Fe<V)=0VYT#XasIDlVnfq!QwN9%W1sN7A2{{N{gtKSVyb-P@3*z@qA#(v
z|4p?<rI=CZm;?Tc?@znd#c9!e{|%rXu_*5~_1r6R6#H*u2MJkfy|2ov3)CRf?#XZV
zm#&bjKCI8uD=eBXZuz@xnLi`b?c)8##%wgNdWi{ja$T$1{gY~bzX6U`iLKRYqLt?A
z?fmR9{;i%FDioj7)K|Ci4K`h)KFsE?^S`c#xL?nb%C_XUsa!Sm$?Wh9wa&%-{{ne{
z47HcB`)qOcL-PE0^&j7&&&~W#j%eM&hThAkYUCIG)sc}B<>?t37MPF!%BSPv#X0I>
ze|sb6Ot!a|+-K6cyt813e(Nu@J^v634kt%>dFCTeu412y<*jk~wt?SI){3cOOy4m3
zdn+kwd>eaOug1JRF&diZ_$)Q(pVW3M*}={H;2lX(WnZeE^;oUSuhmG^Vpsbo=#}4B
zoSGJmuNUX{>zmXMz3ianW%b$#a`|3yb-wFd$p2E<wwgHmmnl*1$Bg|2u_}qYe>Scj
zVSFRM{+XDfE?&ULI+n3-J!7(%)hV|u{<}CkBQ_i&TPqzecHK?l$^ZC#GXGCg4}Omx
zE=-MjJLEeyQ~e$DcZ5G*mKIHl4})KpH`J?zbYD2B=Hg?u=emctxxY`Eo1dFY`7!G%
z@uzsU9HD1=L!EJAT2%4d)TrTJwFz4rJLvkZSN)b8AP3g|LX3Pg(L#(`b(I?PkXZR!
z_NlL~+V5V}q)i{t*QD}2dAdj4-mAaQc(1zR4K>QyY2FKDUrW-WrF=WtZ<f2S)+0aT
zn#ua<lf;K-#e%lPsNz_xcqhAKuL+051AaPKkQ${Ys5KsxUzVAhd&qnm8P3yF?ln(O
z$hn_(u9|6}NKbK?E%E6>wM{;s&*J}0V%5^q)F1L<quwF+Eo%?U<&^iNMbQ=F!kuzJ
zLRwVtWBF&c`#r$M+RV-Mdizt7qKPZWe5QN!ca=upE5@&3(|)sFpQ)Gjx7aFs<Xv$p
z`H%d2H`#t>dxre1MlKm+XEp5LX*&Hp+rLz-&?i*NHLVY%M12eNQ+kuSc5{1zTH@{G
zOVI~bu-A86t7vnb8hPd$daN7u#_H*%AEwWGdHE${mYB2ei|@_8dqXe1+<1Easy_Gs
zK{2SEevaxVKjWHyWSM`X+^Ytu>vcb0PmG$g>HPEN>O<!E8}yx<5>;+flYZVj=mQ(Y
zw<7gS%NO~;%Cu-?i5~kYvAI+1{hRo$jwx9wKaE@0cuI^DKNppV)#B@j*wD@YE4tW4
zHQik#um4+YW&=I?k~(uWP?r>Ssdehkqsyggr}On+$7;7%#Nb+ez~@}=9sGvQ6I`b{
z#r!mgq4HMxSH;0@acK3ie8p$<TopIT)9*7!H^^@vk^g_KUzj!r?=!z+a@{Pk@&b8Y
z-&LQ?Pu`^-X;jbsLoBKm$K<Fsv3u&1`kzb4C}))OiJ^zs*1P=sM7E)4UtHxL%jLlz
zSp#^T{s+xNqWC7pkEV;!a>xAp`2C;F!@u=nUo(eaQcpg|7Jg~_BH6Cg@4kaxzI&{W
zl@I=;=KPg?kMOTQ=z)JLhqXIzg}kh$DF3>8`Z4$Sadn*fGWRU=bi1+C)HNSUi>j_N
z7JH6niw)(@d7Qs&ogJmk;a~Fk{8aknbNLU*|7Xnh{yaZ;zjY_;4+W3Q<!8Ire75mh
zew!_}oXXC>A}(1k$*oc&cAKNy+|TpY!;<yE>c6aSh`Z{Wayo4NvbCCRYP^TlGf$|A
zxAXUdsZr)ZJ^nN1?P<O#79^|v`t`44w}>D9272LV)i3Ipxm(D;lWsrDmgL}a>kVDE
zv%RljySa+2O&w>AM*TLuPHxOo11uH;CfIo;8<?xU5TmAVqMNJP**(7dE?@kK+S6J_
z!Xa^+z6a=_a!@Uir59OC2V3NfPX4uoKYYf$_wj?P^un3y#7o7GYps9WtZ)7bn_tEc
z%IM%P=8D`sA0z*}#D|BHqTcKEZhE4*8FJ-&*w_Yk-OtZn5F^y)3${Yu=xY`;t!otj
zUCu72|7q8|kxi$tnI3k&)f|1$TEdt0<ppwy+G;3`4L?Ap&%55!`k?EqJ+4#NnA3Lk
z-^e%Q*Ef%?VYtr*y7&?u{6gM4Tbv&kyML`F{~kT?hq>9}&a>vNR4kE)2fiTJ{!-3e
zZ5}=?m-egU)Y+rf8=K#wC;LHaRQfrwTHn)Cni4g>U%&PNzAwj@)mj7GmFhS9Z2VF&
z?A>~eEV=PR^4cl%qIT#TGR^?|`XPO6P7)vZ3!AKXiB31@wf-Q_eaih?`y2i#Iacxo
zd1JEDd8dlaKUJ5!u4cSK%%34|hILkPBkwi;zR*3~EPwW}u}j#~Gj#hYwcHK-cbmC7
zppRkitu5?84Vm^$Hu^`o_!{dWUu3s0>XSbv=H}{Q)t^1D@_jW&-7Vz$l^VUvTITcO
z+WXa8my7Y@Wahn&|ASn=Ozk<F-|g3@@$CgKitUfE5$klV>(p)5!N<>~quJ_?54*P(
zIem?_(hYL(N6bZ$y5>GUbq?D(U#~Wo%s*8JzG@BcpLF>F_TA1G&SKMg>B?;T{4Ji`
zQu|gI>kRQy&hP3LD?euK?Et&{5Pkh#?Ca%Uo8-+Qb<hUmTf1ugvYK$a-r;p?G*{8V
zBWjaR@ZtB0dB>?`{-(b93B7(t4tPy|`Kz_br^J^}neQn!w^e=BOg}rtk_W`tzwpOQ
z`~I%>-6!rXuuivjc9cIWEgBP>D+lH7PtxPJW=DAiV$zS@w|QNlmdyCHbLF?{AIg!|
zp{lmH_sYa*(NXdAVzIgV*qS|?{tEpUh|TYp4?iF#{X*?`ADQHYv6E7x;ibO&m-|jL
zXa9EIW%9z+=8YX!l(5TF$wj}d7a8vdWZJ>*`_-K4%*ryo=MnMzb?X3A<i3^et=$!W
zS)BbJogUA&Kbsb1Eao42<C-7nIfwb|DdzfjWSy(F&k$3-C&xDF!+$RZ_S5$aAJ?Z$
zpK8AJoH@J5d=I<1Oh0^^@0YmFWokXWO7*pD^80jg#Pf^Z+1`m3FOJur{KouU=bY>1
znJ<~UAKAatzf06>>%_(c@p!Fze<PnS5yw8wm&(Q3_sC^;=;0q1qp$S&cb*yiSY6m{
z?O;ZIQEc3GdciSv`C)$cZN15_`Nt>Ojb|^NhxE?oAWLkmeJ8t9OAcPm4?D!=Ou6(~
zIrsN+LYKbh1ig+m#ijmO#n8X#hV6FUDnIRY%@OCwk#ifZU-y`sKdVDONRE^E(!b>W
zqsB>>>rQ8D7ns+%^l`a)eRFm+Er-^BfIN?}ou7*Pr;9%iif7lVt<<c2@3O9ZHQ)O%
zU;2mMX2d#wCjYpG|9_ud6uJLj^O4_*6P5bn*PJ7!R`9FgC#|jgR*bb?JNIJ8S!bA=
z%f9t>Y5!ISUEtpQy|D3Ls3E)Mkhjx=_4u4YKK>)N^s=7zxAMgA=t51<_EmPff^YxO
zeVi)J-=_Y`vzD}$4aslA?dl&rZZymm9+LOO-lb>jNoHFwe=RW@XGd*2ta*Nw-Mg2@
zqik*;oBo-;)PE;BVO%bCeBY#c@@Dt=X|<smY_4_1l7EQD?=}8=to?mPKK_+?9CeS|
z$gxo0AWqg_s8{`{wVgk)*{|tKf1@tjW9>}d$=s;_<x_P-u5p5UppQxOHGh*hc%`22
zORl5eDtSg8t#mKtV$NsT%OdqgnSS)`>LP1JS<Pzcx9exrv8BH?2AfFF5pR3gj5WLb
zJLKBMu4`?e|8~Am=H4$<UvCsQs>He?exznzkYtTyww~iNa!0+oE|p!KW}Z9rr0d1d
z<zmje)Nkqhx>RiAbCv8eU3_d5x4XZ@56|Tr_o!Rk+g$V0T%&&NP%oUT{#dUM(qD~S
zksS4^!-jvPE}kOGKlQDDR2N^48_2(#Y&XeM>W#JydI)nDiEX|5_=@#p{hRqaN!|J&
zyKHext~tC+t@uwqa8Ud&6Z<csWA#Or`laU}A3sYiVSOSepY5{eGBro<d^Y_eJG#~O
zz3lE!@_V&dqvlUmV^6(E&lkCV5?`=3kX0?dsuAnt;5v23$cf^%ek(zIDe~{h3jMbD
z*Iz6qSW}sJP;O9b9s46L)oR;J`Eq1TJu}T_&Q$M^eOw-&I^LQgn;)B#Xl+le-6RM6
zKs@93*|X%yQ_LBgsVUdv{+0bdC|Bm2d+RVWzAq4Wx(f84O~>M~TJcIb_NdzQpYBnw
zQEM%x)Y?FUIFS7z>tU~|OKxW4a^8@bG?YN!>}UFYV&L=UX0tl|ICbpr#qxIdb&ff`
zUR+}vb?kdUoik|-po=dSsAK!4-OH)gJ=E$&*7`c-gy#QPgHXFv{8-&nuUGvSKmCMS
zYm#5c$whSC`LJ5yR(>TfbpOHgjQQsA3)Uw1O38kD95p9riiLc$_BVX!ODWN)xEWas
z7&WIYPpKO}W&XFxjcjiEbLN{**WN^@2l<gYp>;$pB~Fi>slIuq{QF)pRV^{HmOX!5
zZElUAv_ah5slLfkw^=707*+=+%1zISPh(=kr`*FI#LhPLbh`R^q5A1LIpVX<mv3f<
z+3YLic#@sz<L582R&cW#@>y}i*gfAD^Q}LO@sF`R?*Bj5g<j-aE7Y*t>G5A`-sNmZ
zzN!0%`tPIqJ8Kd>ACwcn?m63f^UR*J)Q8RdwowgQ%&w!G<ec-w%3slcf>;viANG;`
z-PS(lu#^3XQUBxW^#|mtH`sZO^_I`lf!e*7KU7&0>Q;9SPq2wki-nouNKSGzss?Tv
zm7o4=9xtJ%UHWo$^nAIn>Zkhg!^S+BZuOvxZ#Q38>g|6(C&$yp`EtQhb6Kd)zm2}`
zmS@a;hI+W+9{awd2N72$`QoA)<Eq)`K4Km0V)1Riee!Yr&&3VTi3hvrsnh&Ts4>;c
z)eneg*2@+Qu>ro5?D^2xFX-*tY6$tKVhums;U2fh<E3gG>$wvd@{V4#>RfT>J$zcd
zJj9QZA5&Z1#joGV_Soct@A1oT$qj{S^G@;Rh;xeMDfMg)8y;rQt!jh$dfa}!QlD`L
ztxL2$$zS<Y@lLhi*ZElun|NHzNEY}1XubA)e)oMbi=9?xi5pkB&OtpvCqBr&tQpp=
z6w~F<mc8_Psob2-*4THkcrdQ!9^a`3SR)Rf!$xlub5q^Ja`ibI>CF=7ZdL=yo&7KI
zy-n60^Te%7tP7~e67;TJtJS7e>{VW#%ck4--oQWkb(>u0yo|%<q>j&@rFSxK9pYBP
zJaOP+HYCnW>+eeBglfLpZ|;lVZNAPVpIF-YCjWV-_<opO{Y^jAY0UHF9Qk|X8T#1H
zr+y|z>5nVT)427ygpYf!q@HZxk8Kx;z3Z(3sY4g3Glz`R{ROuDh<jV&{;yFtJ|vgv
z&pJ+!$8Qz~Hd*6i!{v{W!F|?=FN5>R&Oe6PXToFj^bOCP)VW1!ymIleK+RJ0XJfW{
zZjdM@UZ@Va!yMktFa9d7eL=7PsyS=6W}=puW-Ix>BpaKZITqI@*~=`t__;di_wwsz
zy@55V>GzrcAF1W%sj>HpyT8)kndhF1tgoKWc3$%DpB{VO!RGJeyD$0o)oh8*>d_>B
z*WJ%|KBdnzcF{(2r#5N&rnq6As`X=2i`7tK?X)@QG1qNsk%C@xem&WKraqV!*PlAJ
z_9>3>+sg0p8TL9qi=5(fw|G*b?(b~nGoQ33a<h3A<NN5bP(0|Kt7a5O+VADN;$5Mf
zzKG4uxW@&)?^QQc?NMv_Lt#VTmS2zg&O6+P{xI`?GKrPVVtJ|9yGU);x6Jp)S?fw-
zC;YKbJkOKAMvd3^A9adeVDh76Hg-Ng&Yq&*ugj6*Z^t4z{UiLq_+=llmhnw_pI?;7
zVbk<j|1tOTT{_agFBnzle#%&KYOU)xzAip~LoL5a-L0PN`hr~kS@l)Dx{VGdzA5g@
z>Ae;1=MDMzQR{o^qM=LGqVE%{Jclo}zEJu;dRi<OC&?xJsZPJrSkFJM5*M@SpIkjn
za@Pg?em&oLKU?S#`>e@i$@6p7>?2}e<5R9LH<s|Fg3lkT55(x>#82^ik{zarxjACv
z;z#6ewM+87<dP%vkHr){Lx~!<gnbo=&qW`R6V9j4oos;~>)%g~yZBd`ael6UB2(rQ
z;=h`C{8o0xH@dG<U%5utm(?kB)4$Fd@Vmq|z4lUeRC4S&)Z6&xZoaC&oc}aGOE<sP
zVES%UgPbPbna7fOX;FDfYBYMHy6C@R*?DYcQh!k`zwajRd+G3RVkcj&e~Dg>#r*&A
zqm6X%E%_x9{}a`0KjzD>RcT(jAC*f6<=9^K_?#H@H!)r9UcnbzUe{|{yU6NNm$=@{
zPBBn@mT8`vA~{Fxmd=hF$=A#Fml`L_GmXU;9Lq&?f4_X2BhTJp{9k*2q1pG_#j5FJ
zu}WVk#^sZt^>^k^{4EiSrsenI<E)8a?w*It?`P>l+{%B5-j}&&u{Gf@@|+s0Q7)OU
z2khU>hJNCj_T{kA9P`zBM8Cy8o2(sW$}6pRsh#+D#Sh49U1j7~a?WSOtzU?#=DP6x
za;`c#XBNBjZe7=fj&Wa&C!1sSK%t(nL(H!=e&w4!=jyTL!s%zk2J1dKYOJOgT$g@F
zp4D%te+&6(^96kPL2FaX#XPYfUu~59InTYV$IPXxboKr)zn}WIxT|*S=lhLfX9GXa
z5ChYHqK7|?Z<(8^x2$#9*P;$<5mP3wQkT$Y?_+9`A--X~AhSX2{;72!wMg-O=HFU-
z^EUndO?m<~;f(pnOX6pziYbfCJzcd}Kd6>3%H*CtJ;7K3pT3Jv@Ryl%@$b9p^b5@W
zDRk^v-oU5z8rGkhkJVMDt9#gJ`(5r?AJgSp1%H$0*h}5F<out|jdg^EAJf}<c2ucW
zP%mWit86_@AwS6eu)e<3{PN$dugmLyCxh#zU&oKsTxm!7p<b_Sp_;1FHCOP-#d?T8
zsmZ=%-z{v<^Tq_VT<u%d{MCe$a{JtOn+tw1SDoAA9>?i&>3)4N9ag_v-Fm%e1@u<Y
zuO2x;&6BGZZxJ8F>cuNlquw$(yUCjCEO}MFOHSf5<Q-NA<$hA0S0l8XZq4zJ;+{C(
zc!Ii0pRriYGriE-ezBOKo=BH-^7&Me*jWBW_IS2y7K#O)1$CsclLPAMJ~8|%_a=5!
zUTsd#H1F2b((hBBeqLRaMjrp3lG_`0izzd7O1F{wNq<0Y70Z@Bp~m^L-ptxqqx+la
zXJaGm`fX}h_4lBdUaP(x&y<_Q*+%o4;C>3u<NMb58^z-czE>osOpfypYi}9yL;v04
zbt3z_MJ?^w-00JMUu~2l9(S#y3u_#0bBs$T*=5!d|0?!aFIvE6=BvX-zHc3XZO&Za
zyEWp&@2!=wg@g?EAs5X3g*B!#*gQL*?>SM&67zShxmhmO={+*^@RRRRo9o}A6P^EF
zvWlS{-dV}LM*UkS4xT5L?z6TgUv=iGMLX>~Tl|<K7jBnN8`+*5pVKOK?mZTheg3^%
zcaOP9P>=o9nk?JQc~(3ZV;bb8QL(V!dpU*fW#k1iU+#W?&ZfrI^<qN*`E2t?YL-uu
z>qBDyu(+^Y&b-9jzN!a#POKFp$MVG@@vE$o&HmT<&F;5f9Bfnz{ovTRo_Fj0%U%+D
z>3?XIJSHAzoGd4JcV*l<UJ*aY{S}|OT>Zs=+mqBcbUptP*Z&WDy_N6J)@zBo72;5q
z8m(I_is-ITO<#8=TfC3G{N3Dc5o5%I>ZAPT7Wwp>dU&>!S7r{y<-P`SL2b6+!|dif
zYrOiY`F~W`yg+B-+K9PZEN;)-#g{!RY5HiI_m1U-%N%R1V^r-j^RS*mE!O|ITJhWJ
z#|PN(0dv`{=AA{xABo2wH<yX7!EZ|SU_ImfhOJE%(BWU@=vT<dhR3Yu7OXSIMGzAT
zPvtXmc(PnuEnW{_A}*f72X?BvKS>sOw(%46tM|{lRu6hBdBnTUllkm%$DWyrFTXT5
z;%uo{ll@N5+}~mgm#Q`N1;fA8<KNB>#s0Qu`IneBE$6k$3ysH#C2zWS_CK9`?3p*e
z7BhQaP*aPy^Z%h9ldoF%K=z;5w)K%k+sSvV7x<vqaEIEQ4`;kA*5`{wi|Fzu_V!Wn
zbeS6ChsOVkI74p}ugd8k@!rr1^{ngXeB1S25=)+x_vF&-wfY)%maEoEQ!BKIU88D*
z67^`_BWlZ!tBIB*MWZ*%gIDRdSIe*JxT>ez`}v-gs{yjveYP62!FtBnSIz$~jQtU7
zlh$s#tOI2Ifv<c+UsuaU#KAE>u!wGZ&$cco_BWUE|L@S>A^YT{<P>W&>aUuW;;=ra
zLX9+~zHI)w8cEGqtY@$Lfqr&8CF=FA$@pCLsa)LuPxEc;xz;tB+Re`y^2meg)y--H
z_f~xkyHy*v+(d_0%FA!+FT~Q^pYvJuVxgGZcbLB9)2<vk9AkH{h|9(ud_-@_M=PuO
zgMKJYtm^oZcs<*i%Ln8Z{d$FZv~-qwlTQqbgG=8bm%C2pCUaXOSF+FP3yr%}4&g)P
za`D8k_yQeFZD1dZ^}U|Av<|3+U9X_U`2&uv))(Dx?!U*U*>pmwIP-u!tFO)cmVD4n
z|E22hPpO&R&&Ymtb&dG-J?E>b3&hPa^5uz*i|!?VD*xAOl(Oxf`^`JQt)DMmiYpQQ
zw27N_*SV&AnCqRh-mPjM*O^cERqkbho-lzw^f#~_>(<4_Z2E%uF)E(vd2;5+XMCpe
zhiYav*rXP%HTD8=c+r3y@=fz650p2tmp1uUo?HCT?5J0LQ}(#Id7FFri}-jGnfOrk
zD{4eKuG!}qP?0sAd)e?ujPobHe8~HdRcfHWknuV5J5P+<r!KIDKKkmcDC05l^ncb=
z-sJD!bN|+M({{N3H_U^4(MFf~e>3k@#=nPc?;*Rm*1pGFH0Telk9MuqTYkg2YViI7
zeRv;x__yQd@iBR<_ax5|tkaAiQ46a9N9Dx@&yc&E4puwv6}I+nHmujGSFdK6-<<#P
z=T5y=GT9d;`nw2X#g*)ztb^ul(a+3@_0u77y6u`{HH8>$?V|2Qws*f+rv4~eVE*;S
z9rAJ7$@C`HOv}$*J!~`2+KOj%>36H&)JEwW^a5MOl{$6b4t-{sIH&d+R`;|P${}jK
z;qBu5nPgrdW{N{?A5|~OWwm0==zO{R2Jbh0LJhIVdd>y574GqLYb0l~W6v`NbH(7_
zsKvh~AAN?cJj!<-Iku)F{?Soxxww6i9Q~*~aJ?9On%GH?BVuRTjcn=N=Jw<6D~m5x
z@yYLt<N5lR1a<25Y7ud^c($5Bo@-noHt0#FK23+CbaI7yu#4UPL>#(MOrZA?@pY;C
zxoeON)-0-r<+N{!;cfC<iLF>V_zrfM#vbIm>T}JJSe)%yP0`70kPnT1RXugB`0PER
zl5^CO`lh;*%-4uo_<4OYePkUHi#qf+ZysB#a*YhWb2}ZX;S<<M+4KBk7eCZ%B%fjZ
zS5Gi4kJh@^f$PPq_wse`lca5Q-WqfNqOmTMx4+G=<>uTXx;ZE>>#c|M&B<5EDOc;W
zliaWM^)CKCb+LM8wfp^%I%gr7v*cMd<>;&GifwFqC0n)rGk3pQ=1ehqr#xZXXiYiu
zIrHxOTy{UUfZg%a)=#((^?TWu)P()&-)X(pQ~a?>Eh49ms*fjL=F`v1haVx2-m>q{
zVl^9DAZJ%uZ)s#(i{<Ev4;oAEESsjM<K*~kxo@#JzRo(-0s8p9xucgs``YEC_Wkac
zPgLtemfmhH?i2FckT_c@W{DlG>Y7}&#2_8a@QY6Jw+-;06WM8>URZ4~&DOJbiH#G-
z)(_mb=g4!dF(-UXAH~+v*YnpQb`z<QPM}NuL6-WX@NRy;R-AcVEFpW&UNQR-^~LY#
zMBJaNzN>NHRTFAH`K<e}ee5mGno^l{yaGAALyc9a{>fb_cV8}#r<ymlP;Mc6(C6o<
zuV&N@nZ@cJ>z0i>t;c*?eJM8Pn4d;<{fzax$#dlm>jzy^bod|fewOta^VC9*eW$Av
zHmi^Jv;T=>>#Wuz)eQ@-GnVy);lJ{&E5x1^?1;@Yijmdwdf8z$-Kbi7h4m4=e)St<
zyg?1fr>F0etL26Tm(kl-<oz`B)IeVc$=2n);P3Gp>mV7c?JxB{!WZ468aZK^dMA_K
zmyzqg^nI4R&(^c|@R4JBVZVj%R@-b9t9HrJL+15*YdF?}3-6;tcANVXJ<~q%>e$+h
z*xo3PxAM`1ugR0kjsJx8gc}{dO8sBYPmkv_OXZ9U&6j$y$eLTvHGC;Wz5Xw;dW}Bk
zME*TXEc%?7vyJV^ouwy=ui{~rz9r*n^<Ans{6{`24;NgihEikY^r;{25X;UcGkw;2
zX43N?^^=}>>9G8+ei}bapKs$=S@H{g_NBAEM7_P<q;>nTH8?i;KK7q&-RlnHy~R%d
zCQi4?qpymk=ZMAXq`70}d?|g&nYDiwL(foOtBJE_%QfTXjXrzy^ksMObv0dCBo3-)
z=5~_xF?OEFrs=otpXTj!J}Rco+#sITs7ZFa{%7e#4qxzR@#j=}y;ZCeGX}pXrsask
zA2yeJtoN!X8f>$dm}fewlVdaFg>1EFs~pq)ZE^i6xo;c0`i&T~S1t6oXG+#0(#hDX
zmM%4RGN0?yW6z{m_fMo3^IU%}d;GlE@~~PU-<UtrW2t{~z9`3tAJx`%`o1cs%V9O{
zVM+`yKSeG$oe!^KfAick+t1O54jF&JDg3d5Ey{5d*=*uc{o%jF@7LtgFSE-G{n73E
zB=uh!8ysA$r`>CvMjw{*U+X5;o9bSYOZT{bs(hnA7}k?i|3CK5JwC3YeE276N?T}P
z3kAx3TUsbkU|ZTkOM%@an`U8?EXk&{2=69MHf<o6B^TNvmqkJDvPDo(Dhn1Zia!?x
zf1)4@f?O=RD0l&?;id&a7Xi5l@_wJ0GiT2xo3`Nl*ZZ*_adT##nR(`!=RR}hEJt<@
zr2n_kH|X=r@d?i-kNzR{YGy6DC+1|8ga75we@|?|>Dc9I;7g1)rx%<09c17x=6@wJ
zeIapZFM8}g=t_TcSnJFUJ6pr&<BKgv-(b_S;Jx)$@VJG)&w_Wx;S2wcz2vj8O}~M+
z*W;tCpr0F&iFX(Wxa;p>UYBy#27P<Uy|kGQUsbZU=(hZ6$jD6i{Ws`{W!Mqq^S$e_
zrKds{e4EVe=y4DF|1;Px^w8bp{C-cYa|!e~?iT7<`|MO~E_ytJZMd7*DhZ$7_Y<C%
zu%6H0M-waDjb45lUvD{il$&Gt%EW4Sv*)?>J#-DeTKB2&)(6<>kC`9&kNe<F&k5K-
z{Dnbs2!m<pf-Rc4gnst}CwM-CjJ*7H{2F4u$;fOS`ts%nkiE(1s?WeTYtUur?N(yI
znqAR5gYe^p;76>v^@qqHI{9j1jNw=DMew(lpGRDW{3Tega5FI?viCZ9k=YlZOOdk(
z@!i|RzIBVyfA}~LcjE(bt|xgW?G7O~PR#82BRXYI;CCY5)&u?Vy&k@jdEm=r!6Ek#
z{E=6X&st<2Te&~B+akvJJ!^1t0{O>R_z;<B<$b5s&ob9{kp*Iv8piOZ(RstzyR(@u
zx%G_^e9mtnf2X2TE@r*((GuvM<*yJM?S=f#$4^BjZ~iQ{p7lGQwYBikI<CTpz7l_P
zB7E`^JpL3k|33QhpV$P}abp%={TyVg3LVJ%ES^31t;V-vJ?e-lpNBrLqk}7cz`2ck
zu&>w^-&5qJ(FL2Z^P9#q2kgk*J>d0s;;$}b1sr_DIyqv5I%0&$7ctgu*yk$b>v&`X
zy*oSuJpPUB+)5w9C(i=E5!?M8*6BFTcMM?*v4<UBCQnYj<!SgiiH)5$4%s0$xIeaG
z@^6v18s;~^obj2w=;<Zs-2GpJuWw_W{OBco>NNKK`S0Q%1&I+O=!yC88G8MUa&*+A
zjEz5DfxV96k6e#mQHL&k9y~UokMb?}Gt}M4KH}_|z_CtuUxjT)zc0TE-oie1Y-S$h
z&z|2CJ@5j&JeBx`^-G^Zo(0|+oB<wT=7Y_6cz=Ar57<}7ml%ZSI`9#btZxN2YB{!k
zH8Sxu`wAc8L*Do(a5?fF*x4+6e|-!bnvr#6HN618TkI0LW%xt<-(NBQ1>_*eSEQlY
z?0+y<?B)Dl5Z8SMn}rN{Pe+dKf`+s3L9nNDShI=$qK<Jk)sgQ`W7F|h@|1hgBS~b`
ze=PDs{QDz(RR1LS3;*rLdi)#unfw}fBX<?(56_wS+uw(e@b$w}@Z}E2CjSIoc_;FK
zK5xZ7@85*pMxWk!2WMl@kz2nAox$}C{MGQ~;LCc{T#WDYFKj6Esv)jOe3sa#6}X4+
zEe}F&=;!7q;Kz^gDX(Mg@GHWc%Sggkb>#SSP2}0K=s@Hwbs>LWk4(M8{v5f}$A+Nm
ziR7aO;gP-JZFEHV5Zbd|71z@5XVI(sVDBrDd3>Vh_r?~GL!S8#x?lyr*tMzXk*RMW
zkK_k$j>7Z!iI-45{A0#nh!00RIxUZF4N?9g{yBW@`#!m_3Gnyd+3S3Wbw`HJn2x+-
zueK5cZh~JQBfpi|3!T0cpKmJtV!Q6Xf%9I!0~c)DW^}?<=$j*ciX4OfB4&<Yzq{$X
z4&Gb-8T0_W{^0@4?|opgnI87lBQLNHDd<HEuofN&{|Vm}eS5|+$OJlR+UHo;uOd^o
z5a$pJ-3(8s_F>%L5+kBt{7doqjzOQq;0y9Cm!K1(@Xzu$kgG2;Mj!SbU9@>0<oPmu
z2juo@bYT>n>;8<*q0f!aG8R1O2|+_>d<J~D@djvG$yp$L`}9KW9zM@<*5LPZ@CERp
zRwJ*!U&Or8;e)&5hok2cM`9B;!yD+IJbMH+dm@iJ;pfaJ=Qo>tTsu7WOZ>~F`0xLV
ztzum^vuAMQJ;*k?Jq2G3<Lgyig#UzpJMCclT2CFi{qpnh^H&iQVUv%03!8+W8D+h^
z@Q@$hVcJ)a?ajcDPkQ<b<P}yDv-sgH^!svR#JXS75BxB@iZwq8*?1bfZiA*bvsTyO
zNBkI_gzjp^-bcSr%=#79>+kqPe$M$EkN&)zcG$YL#9i-Q#vTZ||M|uEOLuV2g}B9k
z9AhCPnE_}sm%XuDSm!I)o2i@3ehWOqydS;<pBXvu`mtlk!h3b(D-R~O34i^l89c6q
zrkC)GZ#)~Dbf3kzpM{q2?eb%=SIFtj*P<J+trOp8ov%YCfm^#1I^!kQVhynz^Q(g|
z5&`rOvXb}k3*Wv>ES$&o<(SX32g!wDPg0*HM~Hs)pyMiz#CCX)E%et~<ay@N=z+P|
z0dnl&>+rEQV4v=Q*5rf3=-o4jYpy<*{DtV`m(f+ci?x4}Gr#EhC3DID@%N2u;s4*0
z<HTOyhh4ujgO6}6^!W%LL;udq(m!_d#!lv(B)9S&HWPj5{USJE11?9WttE#M-O8NN
zGjGqvFCxyV`zre39`YfZXg3=<WzJhgKFIB!4^6IrTh^U;3b}h4-5K2#`*aGl-3{Ks
zmWA=Rrd>!|Y(wh;;*eKaYu5eg7&iG4>=rzjEn_aLScBE*A?CjkoBZJ>Y*ybyD|-&~
zgI>N@(eL<}Ibx5karRS~V+B5H<Ro<44<tu|pAN2Ja#26Jg8uHumkV?5Zx6~p$6U$5
zyoaB0$uj2m5cZpQ$ZDAT`Fp^ho6s+NAlvAJ*?W^0BF}KiEOfy)q1|oBeLeaY+t4~5
zUl?C@CVA7Rk(cyyJi}Wz!xNM7o4rTllf$cL%thb9J9WecGr_rHC4TTJltItc*zHIj
z`}8rk`Wg5fez@@(VhVim%|p<#7yk;sXLd9C_gs9nUxQl|Kbf57<qf-V4itIC{!L}w
zH+u1jh#$Ilh8K^+znFr~Y}<*rp16rM+De%het!Ks=x87952AiA^x?7SgM;ub9)R|J
z_$UY9XZ{SoADU+IH?94c{{+sC5f@#3DQi8E`D2@+#8J5zYjicfGj!@m!n=P$&)xzr
ze+~YhgDk-3FQW?w_axrHH(7oteKq1I;OE|ruQz!yc`^PQ#{at;T{0707_G$5Lf1?t
z#=aSRAH(O0X3z)E!(-Gvh7R=yuzMH52d9ERdMHBfbq;)YGj=qAF7d(BbM9pQKBDYq
z_zyi92A3O&0q=Vl+^(jdjqoNu)<o>W^Wa<Y4t$TjT>An3JbuafdlA>;o7G)M{fF50
zPUxRQr={>yI`O}1$+y63OQ5ZXvdC#->yat=^k(#Q9X>#A25|@a_Qqea4(O)kzd?_*
zBbR@~cf?P)9(%d^9c&1?XY=vUZWI36Ec7RHJcBrKa6irzB;e_t%E&h{H*9UHX`I#i
zFZ}2s?#IA}CoUsL%Q^Dg5y<1M6_)Rk3d?&h_QMC<*~}${TzKKnA5~&QCtJfQe5TiF
z`^PfwW+X0{5B~U7*${RFKKA2#=bJ0x-*KGJU=DkXx4ftFcP~7+MB=M*+Lc+!lgcdb
z&&sV-{W$KDsj%|5a$O8^G5p(cmhTCUS3HhQsVL*lP1f!k<(B_f@Wa>eai1@@lFwt)
zzs|VmkXG^!o&(D*-@hv?|NZn+Hr~p<i+tV1y-k$ou-`fQk8}W!UGO1uk+aCRABFF5
z9KJ)4G0{)SGtpna;Etpd%dN;Ilt0hiLcwv|<uZ=*ljWB8C0+;q4SvS28S5i_Cj6D$
z^m6D?VI>b8Zw=qcc)zN!hW8(5dEVu0%AwHXS?+0K4KnnR&k-{*p9Fm*e$PEnFLGDW
z&luzT+*kB>Xuh8PsSB~SyN<W=;O6;uCGXReaTbDnQ4pSci+35vL#uz#_Row#d>P@R
zkJ*bWtQ__!N8T*^M7d=V+j=*E@6ReN4}9i9=Xw5YvA4v!ZJ|63A9OSS#nAD(aaQh&
z*r|*0@&8$2rS{-I{D8#!^oc(%v4lTZ$z8?B{?E#+;YR#i_$~D|ZPVa#{WvRIk1e^8
z^+5+E`r#Y=idH^a+4>W3#*ZA{2wh$*v$CsLzkfgjV&^=xN+P4a9@b-5@VcPV%HVtY
ziIZ|Okb`I71@w^B0uBC+uKz9kV4-g&lyiR_;~h`Cv!K<ND!C8}{=}!Te#AVEf_LEQ
z+>gtw%nI^CUtk@Y*h_*Rh93idIeQTYkFyeolw0}r=;A}iS(z`>7k)$f@8hi;_EYYV
z8_t$no(I6?pUidXPF8j`b85hsTEjdptF(H52wv#)jNpGSe`EiLi9LM8t_kEPQUje2
zfOnR#){hWpe8^fObD4wSt6eKB>j&^f3LXEMO3s`z=3cy`7_GE?<OI?!@a(-6+_hU~
zd7ziSku`c5-u@f?Upvl9f?GNUe?!AG_R~XtB>8jJ{R@>=WFhq5gZ>^Uw^~odFC)GZ
zdzFOtIpoI67@j`#5WMMY0%!ab@9Hwk$6ERRiY)r5qu<sC8RLEWW~~!vqCdV_!5Mn^
z(&C*Uc+Yzau-Cz7UkAURmcxUr5qdHEGHZP{>nHs93*-oS@Rz{{|K@J3FIMpGRk@YH
z{$(DstSq>+ZUhd0DE&EjhqX&iV7!muJ?P~3!s8)uybSqS#(H2|(^oLZU!oJPg7*8u
ze~-Wq<c=)C{Q|~iZIk;0i@i({W95<I^h?MdeuWP{$^+xO2OakueZcoA<d=;N?pA{z
z-X=yTzHXgL9Dq)gckjGkue8$G@@y8L0J%zs$}9`tO7cUg!-?Y#fwtrv{rDNf=s@d1
zcn-fIvM=~}&`td9LDrKE;C&_QDKhaeW8MuNu0j9JhPKepLhodLhTUmk&aVUW8~*NK
zenM;XMeY|oBOkeoh<*PL^g`$5kkKqW>^qOOIY8*Znw<r0iO;g{Raz-@LHeJ>O?NSm
zdd6GAI$z5C(I-Csj_~nX{~h3V9ymV9T=?i{1Uh(xuXq<Q2|ZfTBPrql593Don5^$9
z^uX7l74yrpMoHGsf8cn_zbE{AEBti^a&#WH2ECN~C;c9TeSmKHn~|;Qtj&Ay^0!&L
z%aM2b$XLMAM;e=D{S-YTdA@I8S1zoyvdBy1U+@EQyZ4XW35PC;5U(e()4n?7yp6G-
zZ~Cj?;z757w|_k{_a<^>K^KYJ;Hy0GV5A&<)Q9|`_dLjm7uoRqi$3vRJjhOj{9hV=
zOCihIS;)xM*pTDV6N^}bukbgvDD^6Opa1e-MNTh*#@HIqfsFf8_BWow4z$9vk3&20
z$9+79Syz9V)ykcrIc!@i@p--nJ&%4*lS9a1E9G5z>rc#|^@?=!_le+-e5a6q&xi2-
zL)cNyb7hFBtaf<gBWQ@sX7@!F%iwG7&dj}!?t@3XO^k<}Wj=(Kf(L&mSwCM5@xuei
zp3;lRBeEJ1-r1XVyAgUI+ZlAE=Og;~8}j%iblvL}R^ohgwGTR803Xo*u;^}l@ErRX
zUa=$4Jd3UL?*}f>AvXwJu<?nd=$;#p0oKbS>x5sCX5IWRBVWXJ$-khZ;KMv0H})cb
zIo8p42;*ObT+vr*684laBA3G_-^AAK4c{?WA3lf=9g_S28i>q_?fNqM^I7yQ@lrZM
zIdQ!A7wBm0yC;s^yaOFx#HQ_pU9N_=IUkar2;F{)Eyp))#b@>ryIU8r=ER6z_#?fZ
zzxmj5I*4976uCMN-9{eD^BV0R!*6*AzQ^XJWQ?8Z_ouAoWO(fR=m~UjdLwP{J$zYY
z=xfZc5gQdj*P(M-xhpY$A9DEsIt_ouLgpjrfDAc-+`06Njf>1>{ZC+x@!2EDR309*
z=p%ve;`xB}LziS{!V9mVYhPjfB)-Q|=m+gR_%qfa@X&$dxJw2*GZQ}l0lfPJYfIiI
zH^jOEYXz7azD)+dx)r_Xxs$o?hF*99eiB{vA@a-mr}00A#h*auL|7~9Jopiw^)5nw
z8PB?%^+aE$b_YLnulQWD4-~=1_`!P^+tqq4`t&vM-4#6UfsfEpUVKpxx;w?axUKky
z33$_kJa{t5{Nb$o*O<c{ta~l`7yFfcnX%CmIr`0`?<{=B9P*wZ2Jt@xZrDQ~bsl8F
z3;%lXk<!>L&r9$O@vLtyYjg;FcmiurT#>{kC;!2?VjEf8JU&_q|Iort<df)^S*!{8
zr=Q^&A0r2TzF&jem!QA+QP{uqZRm62FmD9CdIEHsfjv1H8M%`3-N#$W7w|#uftO|i
zyR?!#7B+-6%)Wt)2#&vFTxc--CDw&~=e+p6Kc((($n8haQRt6MC#Ev@|AoF4&|@<H
z-H+a6ow9E;4{T?SxGKwCp5CXCMdo73+FS#kd!a-2Ll)&@;>0hlx1bkx!#{>^a`5>u
zcDS{I^}*Nl@eyjt&qVftCpKUk@GTS2*^fPIjl#p9!`}TG`qiON@yD|_fZG6a$2@$j
ziw|8c_hRPj(3SYV)>l|J=9@rICcB{l=RxG12tU4az8pM=?>$$+JLt(Y{FY>l#BI<5
zAJT)IdzRx@BIA*tqc8FAeDs&XNA`(4?T<Wv19?RLvWGwy{QgKUvM#o(5gx(s@{l*l
zaYn;)EP9A|DS{nL^pU^8|Bet_=kakfv-$5B`Z#F3l|lC;?}d-VFT)?RW}r)+z&@-+
zZ=$=0Z((iA;NLK`&cN^F5nGRdcHo#FM$Yen57Fr<;+zEi``GJf{R_4Yo9TZO`aFmp
z{u%gS7p+Qk$luX{kFs9q5C6x=8hnuv9>hMRZsz&d;JAr3_CU|Sz>C6r>^&zY(I<WR
zZ%6;W&K!~d1oZZ!n-bTt)}MzS*aY8$=*6AkKV;Xl5qd1ew$;PS@JRA{eB!;K6E-b-
z13t(y){5961s<u3@B<!$M~E|8iCsL4kUeB6k54E5LH_g5={$Ulf3b$(m-`Frc`>{+
z4tkNFNVQ?(i2st<k;sd*r!F%Knh4EUi)=G85AP)>@=RZzCz#6%%ng6q|84Zy&8#Cj
zFa=NNu`!7m)Z^EBuvdO$HjkWnp|jPCU-JuOd^5804)&Bii^MAI*6r{m^Y`Gld;i2*
ziaq=+^k=O6H{hX8^b+}p<S*c(@(G+j#kWBYhOtjR&JU#VB_sPWmkQ|f1=_HVDb}+U
zz8}Vi_wUWzPC|DQcl&l{4D4)%_4WK1K50a^tw%SKQ_G=8Quu6%tI*ZNs(zv0FNp=v
z!AWdO4qvTRY#M%C3f}V&gCtlF&j#!=erF1rXD(qK=)<!w`~+Y6r@^Q2ZFVIxPHttm
z4St-Cu0;>0;PnLM`4z11*^{l|@3B7bGY@QV?k(1zytV&mVz>3<tqAz0@vkEAnP)fb
z!gH+Se#pXG(CIL-$*ete$sq%YXVH-&-@k*FA2P4!(YuY<UUX>|-JXAd`LH*h#V2eX
zk1b*j-g(FrK4Bhvmq$NY=)oj>m_zpt&tY!QqR+_J_`TqA2|fe9ruR|iv6i*PHbwqK
zj0~+Z#6~&hmfjg&!tUh%0ZvKcVbK}o*!~dlviRtC()LF5;BDaZ8SLn6;J*Uhm}d@N
z%}-|>V$u}8K>kQ@_zHZ8eavEuENoiqo%DmA%b|Bt_>XDiJ_0>`*q1c>7ZKJcht7@A
ze}uRqkIqZni~P-mPS9+acq4l_d_kV2^=V+Qf!@UN8S=-&%YY@{kgSEr4+XE4z~8}I
zLet3E=v>B-bHN$p#eX_-E__Y=nZO6|On^q{CaZ^j9)iDK21k6C40g_kT~E)$SGoh<
zW3BTum^(b}L)Yg&Mt|Lkufh0<Bk31>BlrY9{HEMyc#^rKZei@5DBBqsgI6OKbeqP0
z0lwidwm*Z9DSOhsm!MZUJOS-;yI|)6=#IDGOY~DK@nmEp{8mL@tXqOyK_0uEpbvRB
z$io~G|Ax2!y|a~Ntv&ST-vs^Mf$m%J<F;Tk;hhwINU9yax*J^ai}FW7+mGQ(=5OIU
zXaC50?*T2a`NRK%jQttB;QI{mc%J?I9D9Zt;_e)Ap_l!Y{4V%z=%-d}ZW3S8i~jV1
zYeIAyv`9S;Ps_TaU$V%h+$op51sgIQc}9k^Y377~8o_p^@KHUj_&GlSUu=2`TjJl!
zyq{w|e#tNEm0UsphcmY$;B{gGKl@;LbeNyDO%ltcyvWPf&`sDwFL|ZmZ@|Og;+xFc
z5g&MgYsH^T;$!6Cy%g(_Mb_m^sPAxiXBX%JO<FVbm!@CxL_Tmx{gydh#d^XIt%p+o
z4QM|D9^C@XZi8mTSi|VeB=gLnLwzz|@`9<E{1-tU@m*58kT=I(<~o>rIrjO7(CxSA
zDd9nQ#e+Uc>;rE2_mS6_A9~3LFMEh>BhL`u5*K@*NeVsbL1$!yHq65_oq6ttzUrg=
zTg;~(yCk|BKcRIT`T~C=^$5JS5BUECe`z!QiX1UkUiQJUSJu(kj;YwcTj9UgfcYD?
z=_=^{zpT{+<QM<U_kG&2_ic#}fjqaq$NF4|ti8lo?2{%QW$u#0fY-CT!wc`id)?^!
zvyr8{@yjm;_jl-L6Fk8j{Ny0A*w@yr$SE;m;u3g6_?(<f_D$NS(M|AN8h<7IHTpUP
z`$yi>BRb(|+L9}aum(B&1m9=jLt^jb0Cd4;j6B0y>;rB7$oz@(b5FqYC(u3y4&*k5
zS+DGB?Da(S)nECKeU1F@@Og+s{P-Xq(b?#oB(%zrGxO9kCN$2zMtv9SP97p#hL3X@
zcoOTT@KrP5HT)y^7Jl=e$Xw808GO9_`TU|UQqV882AjSKI^D}W*yr%UAHH(>{R?A`
zLnc$;zKMRIr7wX#!v00rv-DcTrNnJ1;w&Hh8>uEgISCp2F8&g{l>G@dop>PK2!6!l
zDg1xyh+VAVVPtd|y>cr$3|Y?7Uj`c+Sq%>ohxt#(4?F_i_ds*#lZLJl^kZfn<B(JE
zkx%iLL%T=tSICJZBk<=2bjY9K+1r3621=m^Q}B|Pm~a?BBt>~%^ciF2&<T;9;q6<I
z{aNrayyju;)6mLGf7$)<C-89@#PZ$;Jo>*CTI7BXy@(b4#F(iR>j>Sl-RMH%4|N9x
zJeWofy;IQL%q_!yUG}^51z%<sF(3Nz9LZWBcZnF~Kcnqo(3<^|2=R65O4errJn|Sg
z`~};M9>`sd>{RkQ0sZ^|{^%6e7J2bQH_ykElV8iNVlH>__v6qVI(e91D{;B+IARd;
zA32E$A7;EuXm`MP%NxKpq~TS`FMkvNk-fnD7I+^S&+Y?$Z$XpKA`j@jl*rCF=E6Qm
z{u*#2&d6Z9QlCS{{>AekWV#uijA19Y!Y{i|U@r!`<L7&j=L~u_j}6ToOaFDO8Fn$d
zf%Row@|U11cLLXQh)te=M{c9N=s>a2IcSWJ>#4vFFka>x^o2f-^s;tWKu;N$m^jtL
zI=u_6kU`&T$lGDeiFhW(-k2BP#Ah)N^rq)6aJ~#){s25?B4_ApZ-vAu(0nGe!Y|Em
zK0Tjit)XMS6@5;AB!kZKrIEX9;cNWF#2?`U^j{9$lO=|=*tfUvEfe1XpD(c9_=geJ
zEy3BH3~@;kec<E%lO%R5Hxqq_{>-t)I56bukg+^Cy#jvVpFIJYM>ok?#o<%I=~p~+
zM?-oF?LWjXd7rk}g!D7~{tCXwFGzJ_>;J_XV=q&W!%O7byu|b=WH9j^Xhl9Vw*dVK
zT~pW@dH>n}b@+?icK$|usyFBtS<1jO)+*uy{Hg5km=p5sAs$ZCr{^tv8uBF;{-fs+
zWViuZ!^0N2I^Xl)%6?J~Kh{GoGW!5)gU^|sf$ZY1c&=rA*ds{X!hFlnA;cJd{ILvq
z951m>1b^56M|512x#B~o@tyKtp}YlIL`V57+K?lN+)mu~9`=V^WE#ISLjRc<FwMyM
z7oq>_@XO!f(UtK3#qb5Oln=e0y#;+uJmMt}?E5h`Xcg;^FOfvveBWeFvaZNsW+wKE
zHO=D-TaSS|`OI__oryeT&<#0qamfkbKz%+*JaRj>82H>l*e~`^Gp~R@vG?#H&|B;X
z`-m3$#CJP&?;_vuN-MFv2R)Y*{L#m9$9xt)D$QE8vLBXT0WWOE??6_P-$TC8MHaB0
zpG#bZuK0*w{9(_Y$OCc|`2l0jz}Jv{iOuMNr;+X3kr!f84>H36Gi&%1#>W3i;S(g#
z)n4@A@N@7u`%}Z;fIr`6Zhu8i7QnN2!gKJN2U%;yA5II8^UhsH;y`kjNp!FEMb?ts
zaq2thvNynE9(Wwhe1Y-7m)QumSa=Uwq#lLmCczI`)_5Uu0DJ_SA0Y>k5}$<}pPaey
zpyLwwzIpMP@h_9uU(e_Gn|^Y0Srcq%9=cfvP+o?Q&AEltBJ}ca$V(z?9&|wN`>Y9c
z$l&jI*gN&!#Tt%7cHzAoxo<x<Gs6D04_QeQFSlZkBA;c9yU}OFR#|+rR@%1y6<t<V
zh9ZThro&U%np6`$>+!5l73+!Y=08T((erZWL6UEyq&GsJ-QWX!@&r0Q^Lgg^7&LE%
zwrikI1HK43uOxQDLT3*D3;OJe?4e7%H!$~IpeM8*CiZA0PncT>J;$S~@qKdmRv!GY
z{6=CX<|Fq5d!|kxuMK_C+lfON_fYs$))`+iM~t3D9z79Y(7l;W;1AucE0JsVsjUyt
z_vG@e`_XB$=^Ol$_=Y%0mTv~SfPAX&K<N24bYP!$Sp0|U;Hk4&1LQFEH~8#-DSwDL
z{u?-1qb6dOE%464jQcI>SHr)Dv2NY)2mR)=*e>!O5#o2>-=G0=$<fa+wmlEc^VP^D
zGMOWfIE)U;qCb33qgz_hW6+}YZDjZy+Ka6uX7J&=dhl%`tWAd8X*z=3Kx-d1$bt@D
zbZQD*d<Tgfu$07`Nr@@=JIS7rXDfQ27&C(3l4dOLuiyo8U#<9aX?(88ZtxU#H6{K4
z`r0}cnuJ+bWX-!0eR~^n&R%$WGV*g7bRQ3`A7I_KqH{P4BxmUoFCiz7z;{cS<E@O1
zZS!L1vSDQHK<I~jo=(ogOPt_?&oaalz7AvpyO_auOL$rH&m%Vvpf}$ek6nij@VjpU
zH2I0>Hs*|<Vv*zV6L;m1j~sKc*s~kP9(%}@<@aX2Z$R&mFNqwD9Q*-Z#OF(HfKSL1
zdGS|#qDMABC;XZuW650r)~ncA^nOxg1Uz%!V?BnDKe3^#m#>m}-$Yy>`K)351@O=E
zjz?bX4|t@p{eIRz@h*IQ2Dntv7kn${Nt5O9Ik}WpVEydn`CdgXmtudAV;{Vd+KKYh
z(L31G9J1m;KWA>ozT+=?YncQ1L>@x^H#3hK=!H&5RKhFA!8iCei5lqrCVgH3o+q-#
z<j)f2{D+)b==4_n+vGmrM(#lF7R{XreS|Ob@HTmmG%<k(z3cZQN9cvjkKpST;#=Z{
zVdj%%{;67g)E}_^{Fg+hXUOMSPr_&KV2@vdU;YG6#8ipTu+FcsZs?N?xzrRo!XJmH
zzKq`gCu6N+9_z`Cz-Oszm<w}`AnVCPMbDAfklbBde0TUCK8Y}&)?Z*Nu+b4&H{?1c
zc_;AmuvhMR9@*X*8;bwrKLFZc<MK1%0b(@qpRBF?DfD|D`ofcuYSszAqxH|w0lYK#
zso9UvE5Q4RS+kO7*&n*GFPCNAeE74evzZUM)hzX?2JBA~9(fkp-wF)AX5vb8GI2zN
zSSvM!x%?SiZi5cj0!O~oa|QeaZ+O3op5X7+t>E!%%ERai_#=U>XyvR$jy!K3|H(50
zJ$^9sN2WZJz<naLhTmFmf`75G$>*3C>*d2YY(+0v#A#mm!2=)Xk&#q8`V~8yevtZk
z6NpV%_t#N(AK)_$z^f193*pmb;O8{w;4<*M7h8~90nf~WKJP*obf1MTv7Vq^8rshU
z@3Zhb;^;W^{qPUrADP=D;Q3Ad{sVlPr7b++`y2iIoHgLPQn}mlA+Yl)i7`FkbrL*I
z4la8#bGRSc|C;`>DJkSN&)QkUKPmDm-cII$U+v}nRNtxiZyt1KAN1>?k3H$D1>N+L
z*g@j`gP^VSj|^wvwG8>MG(KelzrjM^qz-~7YSDkhW?uZBtmt=q5a0RC9X*nH7`k_(
z@5!BI7NTS5FSQl=5PSHgJ?H-tm$Sa?-DilqGaIlYufTKAC$)ujpugOs@VWS#&$5>2
zNFTl!0hg8d1HR(b&_(!iJosP-BCJuSlDLt5PTz9)u8TFsw@k2Kk$}hj!t(*>eF6HO
z7^D^bn#GSD#x}KLQ+=FO^|E$8^huulj0aujmAD++l6;o7?dV7G|0lt}%*i6}8o?%e
z-$RbRO1npqBWUP_zw^+^>c%gUx!|kkr$dYXg?=J4Uu53+nmK%8?>}kV#ypvqe=_!n
zz1bXkF2&e#H(dhX(8nI^F!??I{^&h;A^#$6zlTm<j?LwLjm)*!JmfdG8!|f#jo^Fh
z_sBW^YU+O&3!e7ix5|6c`3sQGlh7M&=!*OCn_1fgHZDOfCG}@~26TgOC;I;@It<=O
zwKF#PmNfoIW+M6%yA*jDH1N;7=&=NRlU@NGzKO2l>}&)(oqGkmkk>qWW|@z$^=DzX
z@$)jjW^K`Vetb1AdRxx<<<0<q=<OlDnEpFF{XVos4zu`JK78XW=j@WQkAg4Kim&e>
z4$tHB<R#AL97>Y@JjlT?_NtZr5_z9Ddjn$-`==<&KZAe#O|kdDGEN$v$Ulz`!3Xu8
z%ro{)@}s%$!B(@-E6_UwZ|2C!WF<#P?4Kh}&T#J4FMbzi+alQgVK2OVE^_ui&_#5*
zA08sk%RIpvd;uP0&&!hoj~~N7zXJ!>+t0b21o|&>C9vcf<bDE6@>(B&AMta7ytnUO
z)@=^D<zZy>QS?tWYj_(m+Xm$7e}HG~)=KD29=KKV{MfS`zK4YkND#y3*dxmF4apQX
zIl|ibevVy5raUhqC(JGXS?Eo!F?Sh#JWXHY@I`^M$Zz_v7pWh>pK0odJCf|B=a=#~
z{GC9ylEgg`bbz1p0?8ZD&EW0FZ?uj;)`$sGKgAaP9Q*N8bP%$htw66lLA{5oEUb_5
zbpQMBzZCc{1^!Ec|5D(;6!`y_0(riB{d6tg+QkJVs>b#eem~~lzLSoAbJI0^Pj`-G
z-L!Uss(<Bd{d*5*KLvg+c{ll8fd3}Hml6lb@9h!&{0#fU^4x~MEx!lwUXT2q`KtcC
zls$1(|1JHzC;O=KygsDMALq=!YWEr4-=d54xNU#XaI>0qzg^_g1a8q=y4_v)U-JBi
zsIH&;BVB$eITk68->3WSA-0g`?|xhN|0H|n^1PmR6y*2T-Su<j8}@v8A6d$`{7Ls$
z_NuObW|A&n)TG<p)Tw`0B=z{O@J^f>=T*BMdl&Nj#__t}BOlS_H|?U~ZXjnO^-tz?
zKkF~l<*(pNN%;c5{_SbdzqjKXOZmFTG+g{U`uQnhWGSyFS0TR}61slqDqUasqW*p7
zC5`7DFKGBl&3gPduCbr<`ghMSX}B#{XuP(N2a|p;ASWchrygU^`#gJ`AL{2x|Iq!7
z=bW~{tz(Z=e%A-}@2lj`)HA-n{2s7b!*3urBF}fN(a-D4b$`#`n@f2hp!;k2rLGSU
z+e`U|t8}|9G2QRI>^DjIgT(9dyQ0pnzgN%y!8N-41@0)4`dQ?S<u`z@FTeNxN<Yv2
zz8>$UM&0is{7R{R@KHVfmS5`nEu2%6^1Es^+(*PU@;vmShWn^Ww_8uXO3MFmiQUfv
zJ>IED>)*MYYmoZ;Ilm{r2LyEc>6httT?grQE&aOuOmb)fch@iU@AR}D|EaIoaA)d%
z9<0^BWqavyuHd~xX?MX}8twx2Zsqx$wYq-Gle+&6?5#-oH5+t!;5!<w2OnI@_qkV(
z`^eAq?>R?m_#*?l{x05m6Sx;%*7a@V5#{+_&JWA)In#B&7ynj2ciD1r=`#KN%ubr$
z=H_*~vR!ol@3-jRds7<!bBIf&zgsywA-|842bbSVKcnjxtkC7_57zzdbD=KZaI-!B
zH#PjJduzCxj@9LF%+lp=-lBgOoUP~6b%*}Fhuo7I_nW%ES;Q*x+{0NT`JKyIFZsQI
zGc)r0c%A-T#D0Z5$G@$AE4S$KCvVZew?3wS<F+0=?0AjO2KM}<UGN$`-#xF<<J?4^
zTFRf~Ju&&6MQ%-gCvg@+em~+YqWr$`6<z-f@2bi30T~UqfwLs?e9ko8&y*IszqD?5
zCVOB~e<^XV{Jt`z>qAp?yEk9d<$JPkA@zIO^Sg^!Ql8iSOV4vW@7l`q4ZZsL;=k*5
zi=NZZ@AEF1)c4qOx94NJ{>_7QKObdu`#V<Z@n1bc!_Qi!>w7A6{l&-IbhXRZe@^#v
z1$htY{|@p1@_WH`8g3oAQhC1rr@G%ayLJ5*TOSR*uGb^L`*#9&>r47~(v!O11u6Y}
z>NECyDs(^R@IIZuzxtl;?~U2IpQp$<s`2gdt{}f9&y}{ly7bQ)uLsEysrK({_#13{
zGG)H5Us0*c_k2!|U;j&8e(HMtd*-wHx5wtw;37TGH(%HItXr$cebb}cKXRq+?-hH#
z>%Oj^pCacic)UU$Mt)ap)a|d}-FQ__u1J30iRt<PvAaC4AJo5HGxa>y&Cu=MwEc#z
zy>!3#@2l(A^FFV%3q7Ep=T6nnXR@~_<&XbPk5_NY(>2fN=PSq!O8sH%|H$tP?`rs-
zcXj_yvF9P>U7U-Q-`fw?aQEBm8(OUUDI?D%^{3i;?XF#Q`J2Di?dsziulRcXd_Yo<
z`w@9pX*aZ+e!h!by*%H_Jqz-C6Zu#9-SS;sKHk=&7ufpy1>0T(ZnN>@o*02YtU<Ti
z(4~Jb4e9nz4e94wPto{HsnvL2{4L$?BhCj%`&UoX@QWVT&rdGZ?OtHtS?WJxUsrxN
zyrAbf#r7L+s@2aI%+dWW*i*wzdQJD!WBY@P#_4|U`X60?r0t(PWtZ={O5+o^{f?)|
zgUNW$u;(hjb8Wsk(r*9AIl4a1U6NA&hOM9OVUJawLx<||7ua@c(!X?h%k6sn+wFCD
zXR|JU<PZ(N&*>VE?~*T;eh#bEzZaA1mgghwbz5NT%kMs<%Mbgz?st4h|6a;Ig21mo
zQ@3BYME5_Jcdn%T0?ydV?>hGI<@YY~^zu9R%Nn0+Y<uv^Gy1vbGTrW;wKn}P(dC!!
ztIOZ$)a55M>+$b6QP)pz)%|XHM8i#gRhQp!qAuT)y*?Q?bg`~~)7D3CruFk(Q*^)Q
z<TP9l=L-e?Qr>x%-%4BFud)4|MThC}-?aUb@h9r_=^>XY@ZY^u_j~Ge{rnE^8cF$^
zSL=3dF<t)AA2r-8ul{X2P?taRB~8~YoQ;=uCrsCP>~owhuO}Zb<@+3~`;A|q@jl^t
zT^@W-!#&0Rjlf-ef*$t*+i&>8Df)T5rQt8`(7#uFQRDH(cs<^!wm<*A?QcGA^TWjt
z>G7VNrTd?Bf_}ch=DQVJ^!N|5$0y^r_38SuC-pcd*#7VqJ8l}{U2KKtWL;nRn*RNR
z?Qf0u>gOpP8t?nbr3(BNck1$hE#Ke0OFy5={;AZzYWok9IFBmN_g<;%-&wEQ-~T<E
zF68W`etcB_ZecG;o)6=Ui2PPwq~YHAo30Pp{hVOOFVi2_{lCGz7y|#%OB(*w4|G2(
zuGMtd=V6;JOZ9Kd&vpM#+VM?KQnzdSt1iENgB~w#^TUG=>UQ^kU-!4}5KXt>A`Lh9
zbX|VUaeCZ)SL*%_+eiQ2Z|UDaT>swn1>G+AW&M16s~$K0p6=&@qjf)z@cyIB>rLCA
zZDTJ-o`bgB+}@!3x#Bkcdw@N!+ig9*&W;azzOCzTSgn5-9i{Q#hka1#@18sL{5A~g
zaUZ`$KOaz~;on@N@qFbiJ^rj8==ygmb^9yM)8zr%e}3}!y8Ln5uYH9xS~AWXO}vXA
zYhN92KRedh*3~`KACL77#8$WUc67%(IO1s?It4K6b+*m+vSP9Jwt>M_Lv8)E>FY_f
z4eF+rwa}WS;GSkHrx<RayKhYl$kp~J9r2Yzt5){M+s>AL=h^MjBp$Ziu9J}k!$O;f
zX<uo@x_Y|?yV|<D&WrQsx%|<=aQ$sP@xge%J&}IvD0`gMY#nTSoZh|!{hImAVf%91
z@NQ}eZkk>b+2R<pT@mGk#+r5>wjO9>lUFTCS9@D`cTA&X9d5&2?S|73Y5@mg@!rn9
z{&u}?y3e=Wu>GBS4P1bSSd~*=R4d2vGS+wW;GK!Vey%aK;n*5+!L99FWv{A6qX0V&
zI(v&?JGutog7(!hHz?~;IYnT7MX=IuY4~|Iynht@VB5;>c*#}^Y4a22xOR7r5f$_B
z7<?a76A{{cPiT`Yx5{Z(4F@h2-e1<K1{-J|Z0qMNrh)TZJO*5_7fIqZG;89Nvmjug
zDb^efM1xYcD`g4he{Nf>yK7)jJ@3Yt-5p)$#^_t>hj^|Hg&p`W)5p@5P>pH7MBwcP
zhDUf^$Jz~?yZhjv*uY>%S6?jA-_<+V8S6_7cJ=iR@F{PbpWX)c4_03y-rqLZ*YE9!
zcOyEKnZ7tWJF2gN_O@PESJq;?ugPqs$+!dU{ey1F?1*=^4RsF|;bRaH`Y~1RW76xR
z+A1}%N+h_i57pG&w#wQUS_GJTBvc<*8jLkWV|BqmO|YqX;e1usP^hbEY_==uSK6(l
zPB#-u7U~Y9Zk1D46Nm<4HKC?pb+oZ*1x?2ulR8<?J84@NYG6GZs%3$szgwOD8Y9tA
zV?!Wpj|ZN6QNNXX8Z<>)BB6%b#?xdRS!dN(ePc}vOD+AJ3|u%8TwWbi-NYh|p@t~a
zHSoAf)K{$#PLlRQ!$^H?gVf77H^Ud<NbyL5bBgll>i)hpA=Cx1Gwij?^Y<PiA1qxF
z`6)NNvKn3x7_~+PmF)1!jo1mNepP%hHn1A?zox6VgP)$h4&f^^-W+U&1MAY_J%eqI
zPE3sfLysbQPG4^q!41TE+Irho#XDkciG*Wgcn!ZW-T=4__1bnW7GK*QS7H(C?CQpD
zIQBwl?BF;sIJ7c`hIKQxAj>~vU#@n;Z=-)BTldj+*CHF%5%2Bm??GtW`+5ia`>=P$
zKHLrLMC^l5RW#2~La>b+vO2U7xJkuuy>XlRdm(GbBWFI=Np#xUu9(8#l#|vm<>%22
zd{jB58hH7q;M)uEQtn0G?eZdcuFTTqiDG!t$ELgp9z(9n2aDl7yE^3xUijRDT*M-w
z+GXG*&r{X&GWC3*HCfgB;RjAi;LWtVR;wQx>G}w~Kz-l9U@Wn!uLwlJNS_{f-R>ii
zC<Z|<OqjA4FlCk!7uIT^kEIZHgJ!x8x`-&P8iK~UymHEZv?)b<DKAC)8I;Svk+hd`
z?+Dt9Z9IbVVdPuvoRZP@q5l4O?_jLAZLsUyxWhOwkkav@8y}@jY_NL(=dQbZWgDL0
z;JO5YDzp{b9F8n&6l-$`&sWiRtYskHUynx@?C<aEuN~@b7lRV%!@3|jB9qz&;?;14
zx5lHdr>CzMx$Nqd`53=4GX_j-Aii4Qj6XF^@oTG@RG~8gJaqBm*17zj$nH#^<GXFP
zd0dU(+Xk|0Vr~7a&W$Ddy1UxfEndv3b#|>1msg6dT3Zj+DBiJ$vfIUb&+Y2(>+KOz
zn&vK*<*F8&q38dY>Ia{+?`(urPu$GgI|l!;N_|2gL&HlnTrnTpK*nw|Okur^q3vOP
z;{CE54y|7<^yTJfGo+)#>R5B(H$^wW+nKQ_O<39H52N$$cEc-;WGE!?#0j?E-^-@2
z=%?`(6tOWhy3lLu9yRW$emYez#txA_07pTtx+$vsu%U#^bp|~8H{s`4Q#2Z?Y8!}G
zcef1;)WqquD}j3hjM&!Spu0xE1p52i)=3}2=Xs}IwXf^KIqGj;z0Tc{v13`<{LT`Y
zK}mG>Ena+~^S8r`$HC`CFs*n{-EFqF)z!NSw`*Xqf2bW452e2u$nrtQq7#P1r*!&*
z(a+V+CqM%87<2W5tH`?p73=ToL*m8S3Xg~k%fIdU_X0<EF1XVEz4+5}!0nUz)8doV
zpg$tb;ZU=2-WX5jaU}i8KkSwrgLHOv48)Y5E#(3;L;m332$=T1p<ZzXkUJX&TDxFy
z9S2zRQe$)x!0I8Sesup*ue&deV|QQgs<V2K2Z=q@_%nro>R&7t>cIsO7Ua1!{-(Vi
zLvS!_CHTjC+q>J)*;-BMKHT-^_H`q>;sC@4+dA5mBXT%2_Cd?0<^?hB?}i%#HL>c(
zhT725f@_N>s`-2eVDarHPMJraqx-9FtO>@%DP7tWiYk9u{L6#syXLgUrkYqJ+N9<_
zamwDbxBd3fPBAcIhlF-|j3W14t)1YRSF%6|(I(jkQQfhj0fJqlKep1(F3?Ts50`Rw
z<bryU{jqT=#5}F=kki*tZ^_=Iud{`pHPX#Q4S4(R*h0tPcQWp8tynEia3t6qSJsju
z2k#_fQ6Cy;=<8k6-=&x-)LX3$w_>7#9c;zsZyR=|Z3Ts2^!R6B2WhiRQX^P>H(M%S
z<vHenK5mLu$3o$7aA_c{{k~TyPhFv7+WtZOsJ1rc4@!BOGofN5RQY-5IpvwF3gv??
z_$+6i4g4VRMvu#yO|{2%@;H>4`UJGG>!b1ho-W)N5htbBeDKTGd0O{%tm{=SOb7bY
z@ne89HY&s4yBppR4|<FSqAyQke%rIDreCpT9@B5vfG}jgv1|m~@c|qLKv-)n+gs_|
z@y$l~WW?$!Cnm5%(ujW}VLQ6Jl|?3hHXx3I__IFX@~U4DC~zvl&p-@#Xf=7tQfT#_
zg29Xqp)+)10BWx7GCJ@m8_uKb$q2aEIYV7|hAwb?Gd=d3+wRwml9Kbs!NrzRGaV68
z6;I1tVzG0@Z(i9)@FPCxzkw&%$DHe!TlxQey&4tZMd#>tPBYc+ecDCrh6ma{*^Thi
zII9y;jA5<^9AP}lt{+Ce##zuY(KpD_kyq?q7t=|_E>Y*Pm0F+gYs(g|lK|f^XiIA}
zzOo?K^I;-q{o2|gAa0zA-0a0Re3W;?8mhE)N(!^EqOo=-mTkqCbNV*$E8_&G;)FN}
z(RRq=$Uv@C8zI@?YS;;O860eD$LlsYEx{icHHHhm1GD3X-&6{IRAgPC4@Z<n_g|!I
z3-g^nal5c+PDw2m^xj5y8#htN9GE%sszU(>7mQ&qG3=zu96xTj2z~%3%Td|TJ!YaU
z#VbPl#Wr6}CGK@-343j;ozdXNu1%ioYTHkC4i+5AM<z#bwHvmWmMULjeDK-C+u)<8
z37&?ZGpZc7ry%a=c5O$_Cl()PX_X;!GrID5TL&w<J0uJOL&lUY5`74qZZEoWnvr~}
z3!uFU&glHtf!k6dA8FR?N7V0JoZqlHSSd9pAu@wFJc<q|vw|kQQ%z2#t9K~g92ak%
ze#9sJEBdRYA*7s{=4ex>VW}MhP#$TDhGQ+w!KPTGsj)iP+#HJpngaDflZTV`?+9EZ
zSQQJ`G{q!^NWY?!c1DjXPdC^Qm29HuvfU^XSU?oa!N^Rc1sBTpm89K1z_c`+7HSZ`
zttO~+=7G{~DM`&hLroZL>|vm-&VNKAVAhCNZO{xggrc#g#+GQPA!yI@80o|ASQ3wd
zgZN#ak@A{Qb0iS0uA^_9#b|JO)Um-^f!m*TTiRTwwuSnuC2cM=((9T<r;e_#Rx!Ga
zaX9NRUaf=5ho}&I2=$$yH%Za;uNsoLTExuhQ+S1V#hvR??d(ue(Q<~OUAR%!%lJCN
zJI{~8H5RO+-0+X|J=v1X<WP5qTU!=I@tQZP_kcFd)s2y0EE=fNIe4MjzLdL)V}be_
z<x{)ycy=@%&4P&J)Wj*sX<6;;9#n2D<&&p)Dc`zYe5ILd#ibuu*W;|iCg?nqJ{!V#
z^7d}ZJm8J&zU-=RiVqI;_s(<byx29`O4EkE!LCjTbcNTLhDF|nJs#O@DD)*X8n$dN
zVW?LUxQ-skQ1^mGwA#M9U)mVFty_!nHhXAyg4bM&?UU~A=J+7;x2jgQ=VD<p`$Gv^
zBvlq71VgNKc%TBDOSB92wiDTQ6m)W3X*heL?*0QE9bjzq46jm^>c427FIsEb2b_6o
zewX>bB=ffkVCJ9sck%p<-jw<O(dvo!wD%<3^xB#(hBtT#yiedIebOIK^z@ypWJAW8
zK?gbhn_$&b8*N+3-)0<`#%U+xh`w3E0@wD(<7O}Ebe;p<=t&BsUiO|6?W@~l`Gp^@
zpk9aPT4{-XOHyXX?6xK=ta%;p5xRL*`nVc>l4!R(b>T+{U>%|8kWhIR$<@kySW1~s
z-?{N-^4{GmdU_h76j@ca?R=ZRXTU$*eFKuKThmVp3cqOHvA+2$=Pz0ro4a`NlJ2&i
zl^tyevn1Py06OCB-6zt{(3C4}ow40CHDg>3&9^niylsqO)<tl3&BNIf+n;&Uw^Dv8
zN7_qvzf%^)<jKt5+w8-Z2-!e<Uz;|U7x%fmr>9WoFRp`b;%{gk<<;#SAM@P4t`5dL
z-EPa(AH{9OS4B~)9e)-8myUfCeBp#n`6`^fMC1d5-Z_H5_wYIFI4)k?JJj8+G|Pz&
zUdQ3*7SY1)TREU5`ja)h(8f#hsirNi%{fEy*y?y&BE}F3g*juB_{7DFb>$~*$MDYh
zo8Y0b#upNPn(?>S&OQF+$m&?*3)#0l{)L~K0EYg{@z=*1e|z&FDO!5`?KOk|P4@b8
zM0U*aw?BU)V_p?knm%*e=yQ9hEnZyQ=Q3Mgab!>M+?Kv_8p;^n!@aX1j;O4|51T#I
zJJ7YNH{Rimq0I&t&OeO#>-_{?Y2IeP=&0g;UA@}lC?P!zni{?LnCi2YaD1@Cl|b&r
zKFhAkJpRw<*0~6g>3_DnkMoIbW>`Da$Gnk!7$4G$FJyR2=}5O;z_V&Fdd&qlQkJ*B
zUM6C-tds5j62v=Z+>!llpQmt7p{40-GV#$^eQh5%-Itl?rfu}KeY^;+RL+9Di9OG{
z-To8YM)$XM8~tq`KRbwpb_T!8J^u-Qh5igb%_b(3wJ2t5+k!E!iLLK038(gA`qt?q
zIrO7#>h<_Fqx)RlHn3XCHOwXWN~2*!oTPlhlpiu)g;iTOfAL}hBuNksEMDBxwzg?m
zU;wo6eKpK}C19$CIy>Y2%^Y+qz>OaXCsPdd4r(az0Vhn^8=T6mWzkq@p7T6TJ<rGI
z)AbYOxr*o)9Ay7m+Dwu%6Bkl$V0V`CU{g~gz_RBed*%N9bdDks!9^nr)9vbKvcNA3
zG=&1%uQUBuN_k7eDGiOMH3075=8^KyT<3YJdOpq>f2KThMu!~+2iNkXl~kpK>dS(<
zd;xRdq|1utNU%Cq9d4FAY}vP$@-kB{$AKi+<)5i5H+A(P0{s<{psKUa86@oaIVTGX
z?Z%mQ(q{un0@}%3WxNVgM|{2%L=Lpe$2;YL>Qgw?WH-ZKnlR-ic*P>lz>^Y{xT;?t
z3L%5oJGf+|nV924wIcLGl5d$XWs#a=6*&YsYSz*mtL0BJ8%@FH#+D{^R7v3=aOIW@
zj^MvRHZlmRg<qw9oV&g$sLw~KEQ#hrfvIrAR0WqZ8mlUMPdZa!a2oH1Ga&R;$Y<y=
zcXGo88)^)wfji2^ZGs!FXx!??`bc8~0ZX$`QF0K1=R`NWI=2-LGkg)Sft}=rb>ZL!
zHuKuq4cpQzT?R;|)Q~w)`(lQcySU++=@iJO;HfRa=BTr7lie`Y;XpH-8(0<yh3y1{
z8MD$2XL!{GXy&o28&08R7_<Ov`rOS8tLWLhqCwIhO##{5a&Yvx;h07-RDmz1xZzZP
zEs+9OXq_nQvb!5jgE(AaXt#$OhB4he8T_ZZVUV?GV|8QLrlIhG$eoP0ryDNF3}qpx
zH+;31yM9@)DO4K@)@*~ud%NNFcycH(91b^DYswYIp5}(FL66yEn>p;`t`}l~nhb5{
z{u~_lb;GHoT|-pVbz^f#9XpIhVL|3(;<`M4AC66w46WP88WqneXVLaZXUoH3b5zj?
zfATPbGs9#1xp9HL$d5J!BaKZ_Lo+qDrv3hISf!V%0}c8NWi(`;i#4=3zzrL+jYWZN
z@nf~!y_@*G)ZB{V%F*+Z@Y3Ol1Kne3Ehmc6vF%}EYQ~V9<R~j(axfVUW9l6pdXT&C
zrod?~vN$kaHw?VHd_@g;=3-qu-3=3{mZPCffrh0)QF2C3X1HOh8yimv1!JfhW#f#W
zavU)}bCC>_!PT*7Mg|Tp?x#Kys3yPM7!Fmh5c3-hiJ|46S*w}F@Os>qNCcbHERcp*
zW|e}I1JN#Lz`!0dCaj*kjBj8M9TT=GcrtW!!_FQP7Q)v@6s(!oVPnFEgMsEcXZ*v*
zgcIwvw28CI&Ke!zhP7#0*A%Q39F2~eQv`EN#GEWJ>vN>Lz8NCR=>vPc-RooEk8;DK
z(VIDi16z!0V&IQ<!x#7897DA=o~GB|@SV>Muk4H{rKZL(b25F-ErOAah9aG143k6C
zd2V<mG&pOKa3IuBA8M|b4T}Q*9pi?Lv{bS8!gfYMSr|T<?}ihF84j!vzpDUQ=yQP^
zwz)anvOLxhSXPBrKSfR6%xhs0ocN$kF(c#dehvJwMeq%w+S(wyJ)>>Cq3v;Q_=WSU
z*xV6MQbbGntzy%PVCYJi*znRKcY9hXFFEFO>KB)+pX<~gU$TClQ@^BS{V`7c2_@_2
zJM|})tY6^NpH#Abp;PZKS%0ikA1GOWoKs&_vVM_MUtO|3;MCWYtgmwFgC*;$o%-66
z^*T<FwOv}WUfvVXHnpx~eXXN!LM7|x`b6It9y_@-%v?9jDWzfNxnaVkVU7_Pk--4-
zvE!Op$WGXI$|>T$e$uqfgS>_kU&RiA$cn(0=@`g?P4w{Q$;z`hyHNzLVy!yWcXcQt
zf$J%;+Lmxw$%mAeSyC=`gKgZJU;`eVn!D7MtGb5ZX~-?It5j)lISR75fJb==Jo@9E
zvL8`|h|p8|9H;th4D*W0s6Hju6qpJ<F4{-7U2CzeQO<biy78(m+SJ0fu69ASD+#0>
z+Mr_4`r^0>t)#!5RGZ*(vH0Oy%=A)G^4fXl1WkRA9buuq@QuJvQ1C4c&4F5WI2&Vu
zDttET4So|fenGTTQ?RPBQR>XPj4MG8JB2@r9w##vyW0I-qPDO-(G?8U+!$^VtKSrI
z`m7k$XGh7k78*;RyB7DUcIr(GZD4jQhN+WnayzVd#vNZ`+)`^Rbdhm)FYfbnB27iJ
zurp6JjFa7vJb=`dsdlQarlDEq2c*2bP#%gbllO!){J5g>g$}+umB6<Y?PZ-KYFr)T
z%jpK&k6?5y`%-Um0IFWQR?2<}km<wZ0Tc{oxGBKWVcbo<$pNVPFkWd32@O|!6Z@-r
zSt)y=OnVdatNI9Gubd%uwKuW8ZXe(kkmbQJ2%7dLwm0=eev+b6w3IoTcwW^vHaqQ1
z?5^9%Sr19X=y+V(nV4PG+q5wuqtHkAOyEr1uHe*R4DE~o;=q`gy#ON_4Ml3jKhlqh
z*EK#uVJ(kRXX0~J7t-$licXa}6O*gD+HhcLOx9eay0Oamzv9yhtclAt9?>QZs)9(B
z3^Oz}ak+w9&iR(crVz;;XFet-SM?@I!$A^>I}Ke-Os-&>&>=OA)tYm(pC$O1cwE8A
z*_9A)%{ks+p)V7cD>xM+sna=%lgxM~7I(oo++<)(46a~U>|j%*Db&niW*E-Q-NfMv
z#)Y%gw}3M@YzLZXL-g9n@u5ICbh@y+T1TnpCQ?;j+Y};O5mtF1)0P`nRUL<hQGaMd
zB}sa0Y0C|(s@^77OT93pt8Z?fR`sCe)QQfJw%mxS>UbrwP6R;aEalvGtI8GcGSz0{
ztzdI?KoXn=h8ux(zmk?vFb1N48#n4I7+L06E#Z=lyqO!fM5}tHq^oUyF!*t6t*RIQ
zSmtEPxv5r_E9VrvO*uEi>T(il^?^e9uBJSs-=#J1yV>P6jrGI{h4t{*<*t;BT5F-r
z6w{Yk54*AHb9cMmP(#YkpdCEW+=4Sv8)ym30tpS`s+^o&(~4Mdc_d_8Uj$vpe^Os=
z>3T8AvBuh%xa+ZMGCXKZSqp&~XT#X3otV)%LNhZ?#RwQ<*91T5W4v8YXo=Tfr+8D!
zcXG;cCQuVbPfOhd(`TSTf}PM(J11ktoM_jh!kc3a!6<6_6v0VsqqLu7*TY~s2}+%r
z)6RuDJNp{M6H~|I9GG1SFuFZTCsrTe*j$Y>#$-1R3aT)EWud(iFPWR6$F8nATpnl4
z-Q4}v;WP36Z>@6O<V?i`btZh8ZF6gR13^wP>HSjN)vm#TC7n_z#|-Mp&UXzAw8d6Z
z?6jS@Lv4d=6P(E86*JYg)*knw9co+OwzjKhsE4M!vbK&x8oDdyZu;SaNNO`7ww(!Z
z47OxPh7LQ1k83V%1v(tGLvv|n2b}YHU7drVuhzU5zT#w3y#L&Ie;|?I{XPBK+KD!e
z_THg>9h{uLg)i2qzC&Di(Y$(SkQbGE^_t6G-N&D--=4OCvlYG7K3|f{Gk2(cgMQ<e
zmzFi_sBYL-w)YF^XUAw>W8NJe(Ua^^o4zc|ze6}RC*tiKf9J(fd27>+Se2_UKJX^{
zQ`=#wW?4#35Xs2~IxC`)WhF2ABz+jh*8Q0EU$Ct?b@UB!jC-_j!cnIEE<4uVVIU=-
zv^TQ#@wjcw!9D&MLMrPc@12w-%Rk()p2m{W!kl&xC)b=1RQ?$`KWWEkQY5T~p7VFC
ztuwX}NNF$oo*z%xAu2fSwZv#Xm-ai0?D6lQ9mAuf05;gTn7($~vA)I>!X~Fbp|b2n
z?$8{^7DW0GzLEJ(N=lFXOYT^oqXd$sh54$U_`b&{>ML%Hmstz3`EnitDG9O%-Grl~
z;t=H(=<POTe+8z@fss%;77PcMnQb%W>j+G_10$ZJJ_;}09B7X-uDHHgvZ_)qF^{z8
z+=Y#YoULy>jf{pI_g8Q2HG`#r<4lEtBjr)emPe!|QXgm_DpYQ`_&L(wP7YiZdvnV|
zjZMu?9}}E9@=&sG8>>G>QXgtR(lypZ2Tr`wa6LPAIAbx%FH1D#%x#hbXCj6w-UQJ3
zG{I$Or`}A8L|2p@n&q~e<r;Gr2X+}Ti@2qZo2NW^Lx;%@oYSX7WG2dU)~?clW4E6z
z2p6dwm|YzhLxjQ{CEq1;*v)~di$)_(T*n(1Iu#%(J#z-%@RrAEqcT_$@J1W$aM#RZ
ziUZTqP#tRyux%ytAeyLFeybUOcL#21kb@~iF9ZQ92vv~|!IJC~7xp{^=RKS@ydF?R
zmaM9&@id*1Q$DA_Om$$?27=0gO8K5nx#1Dp+m?MCj%l!~uJSzsyVodKc~O&%ILQUF
zJd&_vi5>pi+kvlb<hVzSl_9M`Hb5T-Q9hOQJI#SxULO{+)5qcVdhFxW8T_KbF#f)q
zkHvqIe)e@>YsnQB<bZQbwk)YV6J8dMw5Sf)V{2wCk=?6lPj0X&tVCbQ0X(DxLE$O&
z<jw4Q-j!j;Gf1!{awv7=&g?psD^&|*>d2oJ+L3XRb~5Ho?lH-dx<WYBuhctZN`2ia
z;d-zXp1M`l39IQHd5O6sp&TK~heez?{|+@qBve!19J1*iYiMk$m-lN0KdC2vEUpip
zrtp(G@&`qAtaCU75`w?flS3$~uW1U@N(?HpA@$@Cit3@g*)nqaAdgT4!|5LB!l@^h
zP*mR(TowXFr=FZbQ9UCx$|k1p#Sg%N^H--x5-QlxBII+*Ie(?f?PFX{IcKj_xqS_i
zqLcK)*(z18Za}IHr~^zwL#g9zm8yeF5ma^L!Re3lRjRJKQEjd{<vZEsD8N9o3$F=w
zIq!ohf!duhe##i^9dL$>!y2re%uUMJGpLT$H&>&dP~G}`oKtQW8d&xMfDJgXrkwmg
zDk)k+2P)5J%E|p#$7&<Bqy<!!DJQ=V{0bSc2%bDX{YOr-QFL%5f3M07j?&L#;Eqie
zWw<QFEmVddr5rmf<q@p)s5<Pg)RF9Rs?<2r4%@4gE8F;?YI>Koc~XtT!M_*@e|^3~
zt()K=b!C>+i9%9M)cHOs=d2>-WIfoy6xgR#KQ*LY)KW6O&b3Q<ndOuV0`j27mb&sn
z9UZDFr*2%KPQ+KVsFE9LS5c@7)koNp2}MahU{siw@WXQo9~L2oA2D~KQ&wi#Wyj2O
z%F0z43r|~-+gDUuo#;`sK{3|{>#Krxo=)oFHI)d`OpPlP#qZD{P9N}I0j4<^l>}%r
zV~Bo|KH#^adXpzKPL;t0{wu(d^=7L`@s+8E4-5672IDX&TFE%@W1(LES<6W^rGw=@
zqHFO@r|l#7#A2s)^)^KthXxxv>*GCr{p$*EWpZ9r?j2J2S5EmS{chrXak&*saNml$
z6~%#VR2zS4{11S$tZHsW3q`8}Bx38y!G)q6qu`{4oyW!a@=y7(`eLnE+e-6JzRXeT
z?fpf&zVOn%=+T`E?fbcBgfsGeYvlIJ^Wyz|(zEm-Fm@jXCf3Ufrl79Y!-YevK{7PF
zzq@!b=Z3juP44=Ve#GY92CdA#Xel_}#v2#_Le_X}SgxRv_n6r~-8LLA_;UECp{-#%
zV@u4=%@L%#1a|B`IU~MOC?s#@X&Y1;N8sXX+u8@W1Jf06U$9`&w#QSaV%3#XiXX-t
zPhDluw`~}irn*aHEZTzifKG{U09(y*>@_1hxUQF@-7)<}KJ*YiDUBcb!^D7^r;FEI
ze4<%uU~nBb%xIcPo?tYebabtfgyRmt$gaPvW9fc4jLt2Z(%1IkOvtDCckKQQoIY=`
zjj?%!-oS3NPZyl-Q|McI{QkC%uC<ECcSlYulA_-^bXXl-t|KG~f0iG&ko|Hwv;+AZ
zc`)Y=L>6H+TW*W_+{nY2ur{w7UKtb4#mln4F1#`(><B&-JtcED=M#$YEzIAg>lA;f
zlywPhRBHT@umvrn&jXCacO-m4+sIuuqvtmgzF6y&UK4j4_o|el^$1v7yX;WEwr1G=
zJV$B>!NX-6M$z0Y*+wSZYv{&VuVO(aY~JYQ&H4VWc3xEJkxdABwT(2VtqMl0;|N%J
zO9xm%TB|-4Yr1sQnDDkbRdOPHH$mIi((o=^Ts*ohSS8R4i+N-OyvEo&dJ2lS#>T0*
zoza*w*4Vg}YNK_|wsCY`&?sPO6V8lh=l@2`ZDc!xrM&OHEj&xN6HG_Q+lcW5z2joC
zbp<P!rB%EjG%1Z^p^d>##u%H1BjGjuwvX4`g(DFYo|bVuWAdEc#zxHGWuGf5G4~>P
zh1mA-I%eKjczMUf%Wg9QuSq)wzXN!!5h9O7%UQ?L^eVI&xsIjjH4<L0<F@q-*KG9L
z++`~ovxas)eZ-m=c!QDFyRzn`aVmxvj0`@ukEASX(YsTkCSC7K8TisVmFC52($RbN
z-ogm{HN3&z%(e77yJ2^PmU3TUF*0Ifgf^vdvEglGwv9^>><;jo{d#gSIu5_tdq*Q^
zQ)px8W8`!9l5#K-UejnXb9VU~BgSy_pkWNRT61)0X?Ymc)}ZOME6syrv;*B8v=I)I
z83k<UQd*xl<GC5g!Lc;2m29I3x`Q|tm~Vs~+YXLJj3xfHv18l8v#6aQx`XRpU>euT
zn=$<*`OKkBp{>30GN#Da9-pk8qN|ZN``pL~K2_cw(&Mn0BRlrl&TYcW0ES0O)6w)_
z9M73H$&&MNw<*M7hIWVSa2qv!2R|$Md6j?}V?tc&SP1&eSXT169c@!YYx^9)h@qSf
zc!$_#ZA#mq5%7#)=r*M!4IKC)Vw*NrMX9M2wQ-1T=0Cq|huf(6n|5W%ar*qgSQIFt
zc0m@)l2877+atPG$wiOS^cK<eIukTRH#nB2d8syPYR-9t(zGvbSF`}=8Y91@*I;y8
zXCYi|ORvS)Z3SyH?pW(FqP2^-h4UL@t;yJJHNAwl_fk1Y(%MVIRUASzpO9dCwvn5c
z)g^MVT23BIvR8bFX@wkSOfDv9>+j-zQEpP@RSZ(Ka$ljOpBz{dr<Q`Hv0R+#z}hym
zWWQ_d?*JJbEG=IpVaWu;R|Wsh_Sdk1Bi@Zy{+(P`qTh#?wU9FsHqN8rN2>oha!rYD
zyBBTugEpLw(03iH47lC{lJYWLPLf`q(B0RDFW2RPC<hFxc*#L}*xjz<zEJ7QzGF}K
zU!lvY)oF11CShqKc`X@dygg0>32u4&vNqVnR%1}@k4XJa?t0ouK0(SS=yJB@<gFJu
z{4X0ZO)cus18`=36YcRE>-9WL`6OL#whtV9b}lY=-lvdUl#IK}i2B;5z*2LDS?1&g
z#<JLR7Rt#Ej2!u}0fdH9UshDF$fd@Yy7Hnr_}p%5`W{zQ@1U>tf24gyaeb8S0;g_#
zQC%b?n94n9hte(_;Vd$j{jtv!Tu!;%cP9H^viT(YH3BPTbAfdr?K0ULlzlsPw&c?l
z3ho5p>{}J1<_=uhgEG5X2Cf!3p^)Cil6M3qPC1P-*@c!{wq?u?p4p;lJSC_xF?WHz
zO(*m0_r4RHgd<<Ho!iIsd=CT<ww6w=kHl(u4Lv${p4`E~opFp44Tq|Pxeb0@lsOx4
z6rN|lm!0ChY%}&Y?$;TO77|$c!YB!I?VGMjv@-b2;17A9)|`hn_;mAr_NT>Xj2o=B
zi;%39>>08<s1`<ODEroeo8cLOIS(4jZfJ9KsiN~0LT6yin#;YDekto;S0&dY)wd;r
zd?JRO9?cI6_GJBQc-@RWP;<YPyyyLC=W8x|(l=)5F@z^#Cs!%5$~;yvCY!5rwM(Fh
z_t4B;NOCXorybYa(j@&~NdL-w*%y}98osLd^!>|COG5A6p_`l;kas@JJw$WHfBJq2
zH|$%N3Ut`~AM|H#H8St)cXR)n&=fxnhuM6vsJ%~aQxsaseDp@KelN(}g~TVXOSH4^
zIHHZ{wngw&wS1mUE<9G6Nc7>vDeIwsQMvt<458mSv~84gRDmW%PZuvJd`_lM`8tgK
znJHBkp^Q^^sJgIx?hHGn?>4)ezGg8uJuh{~!dXK-iIqd0?7C4W^Lq|l<ccCr5>-*8
z%3h*On9=B>qip_|kKS?hr`82uM!p-smFIG;W_w?Mhn_pGf#Km8uQ;mxZ*xD?>tpmI
z$i={p3z-!C_6HAcI4vTe(2ptV8=9EfYW2|_eb1`-?%^Q%s1%;A{^j09KAofGPtHdm
zZ%S>*8Vv2FYzklb(l(%RZ=S=Ui1-nPMo}pX$dNaB+eFjtG*uRkoF)zVC-gm--yyuC
zh4VFzJ5zRshQsdayF??k93l#0*@7_+mc`g?FMPkO2V6KI!`BePiY6ZVQ!$0@&B-OC
zg7d|y&lY(_Og(q1In-1M;RTPYX&8?1_MRNiq)hnpi>eK7OvKhUcH4w1uT}5fNZadp
z7MWJIw^_Fx#~RwPjeQ@b=541u7VhGrb<Vo$U46k(aEBBm#x;(zjyy{eSK*kQ#(KLx
zq9$v78)fER-gv*<I}4}LPU@Z!_#*z$f+RR!tma=>H5vc9scM~-E*BV<-Qu3hj;_v5
zwKxLfrA*dKkQA6}Xv4RfoQt-k>|oAb$jQh+Q&V6C@X~G$W!1dsE1WKC+yL)3H&m%U
z;)<RHDHGg<FM@SV@l{AH?`HFXq6YOLH|a~5Oug7-_k9jJ%DzTS_4j4w-Lta5_|oP?
zHGYedVR@E2YGd|?>*V<|@Tul~D!NqoPFC>xT%GX39z3^%F*o+NM`YJl_*2fBL^!(1
zshp;0tdX;uPT-@~;6U1`I;U706`_-?lUqauk7Iy0x<<yG4vfu#oJp;jEBHy<A%0~Y
z6m#&mv{iIz<PHktO`c~^9<J7US!ntf`ev>4o8}ytjB;p24#*i@kArI+1IMggtC-9=
z{sM@ShqGBHXI-o0tf*c~`8K4y7AknjT7<b<#1<p9*5BG!Xd6;E9isl`7HjS$5gcWH
zaF4R>!WU1e`f63@r%pM6_V^=caSX)@?tH~REy`z>K5tTMsX0P$I*54_3)BZ~doD17
zvwc0A!g~hex+PuOEu|m6W$19S;CHSXt4_`9cY^B*Eo*Wgow{F~8v=Oggu7}xy5*FJ
zjI}#>>KW_jOH?14gQfmxJ!f@UT!}TGXXYvQCd;=KVLfNf<euMyMasLoIpDN1?tB`}
zCvmg3bDK3xt@_F!w_)4gjVM}Q!vkr2sDs_#e(G;q!|OP5l_0r7eecm!{2;~*4LCjM
z15(kxs<=8k)wfO^Rx$SGJ`K;v+dqwE?oO`5hhdCZpyRBefx(FLoj2oO4BPc%oz*hm
z*7!X%lYYj4GoL+h=(!QUMc~zK;VtS8a!ohpZ|t*t7eZi`#s?#O4T<kx^f;6-eutsw
z`I9uP`A9?D_)xC?o*xUwcn+@huHo)f89UM6*Un)d^+uq4Rud5PkzSvTHjMae*cj&n
zHU=jGW$6Rg(ZNQ&R@m36b94Ipvmdv%k$_p((>FBW6$ao-y6tj5D|bi}0JQbCuj3{s
z`LaR0TaB&n)%NrEIPg<nQ|asmLAhOBe6Gn;_CV+QkVU87e3!)jl0ssz1D_E)1l&mh
z-`Zn3kM%9^wQ<Gl01hWoCAVPlWwpT=ADQEmJMyI)(V+!DAuMlyhQn3dYsfVm4R*qz
z%BD-COz?2sMYgRwvF#~<le(|#O1qD@U44v<EelPyeJgV57<0#3GhOTd*m6CLTpwbM
zu}s?_+4ksZ<|?|t(CgFAb&U9RhbL?1dOkYj)6Mn5ZBU|cPu&vq$$vW6k+G|ZhqwMe
z=-b4nCT84-Ui(k+m6&vy&DVA4z5ld7cPwh=p8tQ)uZc-b+;$`SSN4VEyF=Jn&dE97
z9ugJe=t23mxy(uHBJ>veNaV-p$>hj-)mrSi)}xcrqfUE>CDlfUo<F*de6@TYs$iS_
z=-CnNfe~yAFmJnIMoh%my5*By{UC@VrmOr+@jo10UvNJhn>7`^^(Saitq+uTl8>`}
z6os|~_TZ|&U4!Rstds;4^6i@7+Iahr{h3hUDyLMUqqlcnT71rvfOCCLnt+gNFVq^~
zUr8O0^`QoJMBIF6M%GAj!8b0HwTRX7xsHx_xNnuad_PyY>_CVgbu;iSQ7-Q0pZIDL
zL$vTHfBX5nmNWA5xA@L2_TK?12gdM3hUd-l4U$!Jedg>fMI+C5#A@5R`5=<yL1e#z
zykS!u7i?W@u)phE*@rOw`Jub%PtpqN{bu@;eLB~<x6%DYbw_k5gGh$N;me%UXQ4y$
z?bb7}33@zJ=Y;Z3`%BR48m54eX)nIrh&rbO!~1W8zqceW6=X|brW@HSaI7OgQRd*(
z+xFjl3rzN9WbefC=t#bbk1j%7zA7&qsJ<M=Ig4&2UGEJEtk;hEN5FE3e3kluuD}}n
z?=CU6(XW!rm;R2n`)go8^?khobp^K5$5iO-;O~}6#*w`+>0?sz1N&dec{tva@hekf
z^~vq2<~w5&m+0>|$v24f2b>n#ykySqh9t2d-z1bn|2}vVKb8aEu{EpXOs1FH47xhI
z@X*bgzo*8PMdGWTJ?*fxx)}{x>pK+Od|K4^TwJrUI)@G-!*VBq<)K@ZJ=Qmb?~X6{
z@Kkc;#69CI`J9G^eUdWEiZ-625bp?6Ol-z`JCyV87Uk-D1*%^u<Gn4)5^eHTTWKld
zNjdLrQ4Y;1mkLwPJ6n_wuI`csRG4z!*P>iLEU(LDFG%{~eJ#q*C8F!=x4UxM@Xi)>
z?eL@;!ohQ*Dv!6V>?-s>NtF$(;XZ=cTo*n&yUHcVGjrWVm6LfvFBu#st1@}LgQK^D
zg}y6Q`H;LVq247B{uSJJErOTVxfMCl0h6cvfqJh;=r_oRYkK*hk2>bhSd*tbCv~h@
zxg|cot`fWO7UgzEOK*wBNM*uEy{i^4j-NB67C_p+3tWWUQn}U7SC@2qnb$|EeNBVO
zR?EDkjCZLTP?}_H$&@0|rkwYv8ZhimZrk+1J5&wY{TE#`c}h7kdRmRgcbxdvq59Bi
zgN|2auH&h<h_`vKk*n3Z*4kC@e&v*%shg;Hu%)*~a<d{dix(#X{i{@>SnQm@cuK&W
zE*<G~GB#GjO)CKxjrSyo5#y#$8CSkl<Q)yW%HSs7<Q16NqhWewW`frYrsW%5-_bQ7
zt68hQKP>M;`GA{08m=?AR_-(D8Z`Jt+W0)yfY>G7W<iNI#JdKZ>8S6gDGJE^_kd2v
zjc(HuOVCPn9!D#QzSg+=OTkvx@j5FrZ0zim$j-pll!9fchx!N5QQ`Qx@oxBL;*`hv
z9)J$n3%gVz53Tqal4(<ZAa4r^5#=jm^6r=T4N^@iO{JhEmOO$OmDm=xZ0j9h@zA73
zA#!(z&Z$g8XL48VP*-<HwPfIR2Ba?D%~zsABw_oJ$R&0f!QN{<MgqwOyZ!mt;G?b9
zPuPKc9>w+1dHOSVK;OyVzp-NN-Tj@SHXS@A_wotxoG*Bqey3q8rQgB+Zq>2*rfJ??
z?qpF4^Yap)eA4;NKXLT@j4wV6y}<*vK(Ui^kx4GJY1vAQF?x<;uY#Fd2WudGn*M4{
zf5aCha38b7kysnNB)-^Tyr8-nKS^w{<KvH}nu(Lr#1=>EowU$k31&2Kt(9ZL2{Wkt
zH}dV4WZ4if`9&}9O&)E@r>1RAFEN&ZorbV&3s%MxnH*w$CBH4>7@5nU=Zo6b_Vx3>
zIF`=|SV|1-w11v`flt_8$%4syPDH;PZOJ}jy@<RP_7Vdc`0NhA%K(e*cysOk(m&sD
zxAg~!c$J16o2rGjj~)0)+Nx=>emc&bIbG33z7Jy$h5jslK-M&DUcrt~Z0>gMzga^=
zi-$2-(B3tM(6KOxdUC<n5WLy&uA>LQyPuQ}(0IMA;78%*f-Y+6`0<&U&NwZn>1pd<
z7cQ625*X#fujG@(PSSMo;-W`qt}_qWF?bW-Zz{mM`gZ=r-s?FoIn?Rbsl@v-u{yR}
z!);Y?Zd&V!sSQWv;+Vfgwsf2HZ0UOx{R;fRt2%aAQTWS6qmIL*y&BWdu_U~~(Q~*n
zmm(ta&9<UvhH&`w`a&CL(!e`^3#{Qc&k@_e$0X`b5F4WBzp(&cm^18Fn1s`aRt38G
z=X?UXxw<g1=vLK!5Lv+6?d&Uj?d*gT9Ng9(>C9z2xJ@s@ZR$~<0ynxaYjmG#zb!s8
z6FS`Cqne{X#h9$C;lrm(w=a_8(Q9(JlW(cRrq3ouz{Oj<Sp6)Si;8vlVl@u&n0#88
zjzjwj0=8nkHBy#Lqa)y;!aS~4?RHR}TwPSz{OBbhEFq8Ep@YW3=nD_N-)#M*RoOfz
zvXNtB@@Fwk?p9-sA-gWzjBFiuj6;*rvToqvS(5{kZ)lEKlX<cxM)o!r`g6^%r0^|q
z(|Gm#PeY?64lj5X?7%!g)X+0U9)Apas`(iDY}}!KPjGmC33<!X_N7%a6@1&YgAcIF
z?VtQX^gSdA33R;i8#Wi(JGziSVViBu+WcSk-Um*u>#7eQ+e)kiIY^EYl;D_+qd03v
zB(t-#vop&^Sk@m)W-SS6?Fge}^k(MG?nJXQlbKm*Wn5QH-Bb-Cs6hk)A{9YDYWV4w
zn$)CjQTYjKQkA-?nhL5?m#WmID!8ChH&v+{`aSpEbKiY4_szU{^LA!aa6Yl6dFP&g
z_ndRjJ@+5I@7dBfaot}IOd56EI&V=r+KXJ=M@JsKBk6X$=<znZY$G=e@Z;_9PEMxT
z)(e?HbW}TzeaENT+kqZZvaP82h$)|_XpudBT>9)z%o|3XJfT{nQYEH<t=qh@#nk^>
z8#E3K0zc=!7hwIE7qkVHHl|u8Bu`2HXgx&om)#>7L<tK|=#oi^qFWmWv?Vq$Y<p|P
z`wa-vBkz@sh@sCg@0b&{@y_00W_=Uw#&?<T3T)t>>LE^kFtVlH9$>F+swaEkc(E4q
zFXdbGesrZUEruit!O#cy>&>kO-I$QK^eeYNy`$&$Lbn{Rp7-N(KW4^@4au!57p+IN
z%Ecp#9y^k|h_Ckifog3FHJQq2`nqMnThkPFubiL1An<NqayDk*)p@xAg6rAMM~QCB
zcd()N%~{NOTV+tgBZT07KlFWstIg%K?IE*OQj-nj4@>?o%^3Ov!K1xVONRmn$K~m_
zY5Wzcdr7}EYIC2j-`zV6>U73`%Y+}J7|XqPPrKYO$#xMmo?k#6K<SiuMg(KM9RGd;
z&qk!}dSP3wttA>_E{1(KbS;w6ZIzx5?eCqYuBV$WJz4>B-u#}}ta6uEX500Iu12Xu
z+V_53%9NjH6H)ChKi=LBs_<>c^M(0!N`9B06d1xkJfA=FL_2PWr^l=%$qB>8KiUrK
z@ZrLKLdL-BE^RlgMmc^6TXO2Fw*+6i8oS)m4lQEDn3uCuAD3%%YJBP%;(Hno5XT)}
zlGx+-;n*(RtfbHW#ggPvTC;dm>WA*;mpu88@twwh$j@WPbwSgUlVgRspw3=!|23a%
z??3dlDpKioaZB)*-H8P^To`Z7*;wolNsRoD4m<jT?Ra4q9=vRmuLxKVuOGF_haaZf
z)wq7!Tu-{u=Vk7k?BqeB<!SFu@f0RkH)}rD22W5Z1yVe4_ivQn(N2?jJ|}P(_Dv$^
zV3@+kg$^j;^X{$0e2L|{VWi>M%|ls7hjN74t_n3!G`F8eO|w-mYy($Bd!ZN4yg!Fs
z(G?BHs|Fk#$9Eobc+d-pun!j>idYhzlKW-R#?v1PhWTz{O|6x0*4smt>K~U5j0gFT
zntQz{VA{r27v2F^dV1YJk9{DWGs-w;H=R=-4NX^vPy=q|oAJD8zyr2Dcz7I2=gl$#
zcm@l}%1?Rz@}hw6D6gj}>zVe=`|-OCwr<Exfafu5u9V-sxZsWnFBxDR*<4uezw0hd
zr*5EfFgGvShJ;7@tar{1>LAR&k?Pev^|ENwrUQmWVMQq0)0}-_7Hfc`v3<7l3Ii?E
zx_>4b40oWY_~P0GIKrS;$G@sIoKbUp^JRhWkZ0i+fN~kwE>Ho9vXBJ+HCsm{+sEsT
zt$%lQa(&K+cGKQbuP*G8^;4k}=J!y^*oURY_MINM8rBj<vAU_PQ)_>5<$uM15B;q0
zv8^BYgb&@_RVPkCrw_|<Esk{w9&525Ms9J+78Vy4u;B@%OAM>V-+_baT{F-Vd};Jp
zCkGBIJ<51M!w#V3hF`YRmjqut^O&0AKao8!-79Ulocf(W<veb$VE2|=={m4jbd->;
zo@d@eI&o(wD6VN<;*KF};DfTZqt#}P&Rb0v=D2{#X4{G%kb`Bt=FqcBqJ9Tz@=qiy
z>n)8zf#N|c9xiThOnF_x>4Q1bIa76Th_&+Vl{{vuYV$q&&eFXkdpO^D#_LSr{jPQQ
zq95ZQrac-Wuh;Z+=t!|i`x!ofK62pZT{urR23J+EEa%8~5uaR;9I4nx-TBp3@lEC<
z4Du28`|Jp{_5XgY%lCs=C+pOn*3nGgxi6boFZ0GbX7UG-xwv)aHw2u}Tj!k9*%HRb
zYE?`=`97i(xc!4f`<*f_Y}iO`nXeD3-%tDezV`iIc%F-%62G_T`h#v?(0W>%uC(tL
zyL_KTt+Z47*L=QnUp$MovC-Im#JvhO22m6*yX!O>AL}15(fNp)b3fPR`yptzolm#@
ztuEhBffrMImSe*v`tFXKnh>yjSKqG+xR(BS+U2AC-GqnxedNCTMzV;UZXCKPzI*2x
z*htKkYZb4~e2DOP;kKy)H}T_))g$ovQOv)dz$UlCF5F+-+=^<58ynAy@7i!UHTC#@
zZ0AC{q4LcQSodieKdA^+ZQ#UG9wm0?WhWPB8ackwWg+(n<q*{WBq!&9mjsN5ZlSs*
zpU1fznyb<#%Q_9>48Li-jR(N1jjc0QWo{9(G6jFOGyG$S%|h=SyH}&a)goh|x;@`m
z1P^Qjv}V!{Q!bZkjgrpm%O*HFSWR_pOlTJC*c__iO-~r`KDPh+>|;l<QLv%L*mFiW
zadM4@BM;8iSl4LdRqPL|l#gk8EgRvg%2Kw@+hVU5$D3;cUfQ>;Q;{sJ$N5PE-MwNv
zrs|u^CYXJ4dnQyQiWQoEl32fJlVuiLQKi(}KWEHvIN{|0GF&WU!UqlRadg9Q1ryxk
zIFwa)JcQw1ZihoUyrob;qSV+^RQ)%Db&(c12u|M)s9+C#PbXMM9?sKl`M}n#V~$5b
zmkhf!ZN>{&c~iS<@9PoSO#A|t7*Kw(0Tr}%xQDTUx**_~_8C98QhuA&v^+RRwwZA9
zCP%6PIC~RsL(V4hE!vZa1)0T46R~g2x=*}47Q6B;?Yx}$E)pW}y+-Vjy4Cu<p&f_8
zoR9mru-(WDN*mZWixYYrqh9ufL-0coKSD?Ta4`VwlRO6g_RY>@x8gBTdWsa+S#O<{
zZ^F>o5BhHU#<Z3mG4Vud<h{H?or<?Nb_IiHndcw%gLm+9pT@q=2<PkwcBX=e4LI8j
zdG?wF#yczzKmG`EDrda9GDG;f=f|{@vw)@CjToDl=beukc_}T}72517^!_P7KHwv)
z+e5p}cyNjnTi0f-I=mL(%BNy`{NT$t_6h2MW_`^YVYhGH|G07i*!Jpm#3$}lXtNHM
z_2OO=O~OM#-qpzn)(zTyb31OEbNZ2MEZg=O;g*^xJlO?*yP`*d4EWKGcJaD0vHT;m
zCiorlg-$VDQvI2{Ef)I#`?q@zMr=QBK>s{fc}a(pdy~0_ckXc`JvkVAeT8-V(Cr#s
z{d|g~%yeJ%!U@VO=ZjC6=svQDA}eY%IBO36dCVO7D8b4x6}Cl1FegiM?dH4-L#q(Z
z%AzRwxX=pU0m8>KdM^;mct*gu^KLJc%iG!?AY43S_ChhPiw=yLpynq@)Z5!_Wd;ZT
zuv0@6SzUS08eyGMG7oC(ulJya-kJ+TjR3|?cpoh_=Vb+gZQ@op`0Ao6TCj}g4w`u1
zjZ=%__@7$)TZI{ByNphk?<sEMSVZQlV#0Z2n?2YKPy6Q`e`Z;qM;6_VUzQnWtB!&+
z+{yV)@HC3Maqn_BSb3Ka^FsAE126T`0v@z=U0=o3nZri-W__Ps)WDTq)+0kV;1}>t
z^m27rLmj9c7KrV-UCBE)Br)IjpoU|D#Uu;ogWLp^eK}q=!&4&9e6a7mV1z}!2u(A-
zXFqAeCtwOrZ@Yc63W1`X*ZtzalCmbP4{K(4*b!z&o*cy4n{i#hyRnC7YMk$%fTilO
ziNCWf1&nR-drMqmNH><O#$>7`E-4_^-+2Mk5|<<t!)!Z3cswzw4bO(70>%@Q7>MoQ
z1p(ukgCcA=P@;S%=d7%Y!V=+BAY2+${W^M#zMJuJa?N@>WrjVrkgJy222{K<!Wxeg
zDPErbArmj$#-YGt|LVWg5w<FfoTn+UHRkL3@lNf?Gu%cTM^}By*hWs~Tz{VTfm4$?
z@WHygVul5Mw->q3V}IR5pC)zU44ceYUEJGFnBfs6xJy-hd&vm<1g(M2&M#IDx5kS2
z-!S1urDoBM6<7UX6n)l1?K4JvIdPIu5@*<(W>}no!}@m30cO~fKWxNX)bX-!j-E8Z
ziW7gzZZ>|l4QAdtVzY6o6K^y~vhST1ZDgD(HRMR-eqZ&Ygj0RTHMb53w_oyp-@Z_z
z7q{HlbVGdC>wBffjz#BuD(8C#PkCtUuHu?l#{aVS+ul+IMGuYt>A&e|i;oza@SSmA
z@P2=M8}_v^?hT*ww0(TrtS~2)Kc4h{cMVRXANw&64p9!oXGOoJe=pmWx#qme!*9CZ
z^cXLpTt4Sd6Ad@yG637gHSt}K?F`}KnE7$S;l_4`U|qc8d~YMdH1>X8$*J?YU>$aA
zgRck}Pn^aT$fBA_=UCffz@eWo;-uT1m_5}OuLxL|JspT+;NCMrMq#YZBC!tT+T>*i
zPOV$%P%Q8CPYPT{f~>O_1dQ|zEXeJW?!!1ne@e-R>uu<}avx=bXWL+e`762C{B$c0
z<pK)F@irJ?=B}N!efOBM!ZUx?ON*U}ed(I#yO=G(&Yk+g&Yz*SILIoG>pMQ+d|Ukm
z{?@>eO&eJv`G@oEg#N9PU#Q_5ujSnHx2Rnf*8>P0E1z0(&hz_rqz{n6!FT*;TfX5O
zXa&U#mf`9b#rGqP8Y<^a+%<t^0;c!U&(SyaMfJg%^Ypvq;t{(-^9P$sW<rj;*8SHF
zI43`%)(UZlIgVH7ZM45@-COR#?auF~Z<<-U%Yq7q&U4+a`M3t6U|tk3YDcKPyr^Jq
zI50+Hv|dU4Y{1%-<VW{qoutCIQ^2}$LkHT7THz<Z6H4&A@5!o_vI~vuQD}sgKC;CU
zCg{-kSQh`I^+KopZ9&^Nj#cvW)I5=mgDTz0LG*9;YkwHU61$9BRVcS|VDIpQ6>oXq
zz*9jMJJE*D>NkP^`U6Bm0#r~2YS295&UHsR$-bl95X&gQ2vmYsg7=jb@H=oF5P>sp
zU%3GLh}{$kjSlZC8{qeA@T7O*WtE>UcB$KZw#rLB_B)ptY+oXJq)Tf5CcpN4G9AFI
zO{yIqLz|oLrrNR8<-E9&5ZWaFU9;|o@SV=H-Vsv>YR)Bl4RH^}9k5;O073nGw!Vl<
zbLn0N`VDVKJ2&k+Kf`wKT=(q)cHbUc^S)~~OBcT5)>ri+s?#5IAIkkPdMTlCtkJX=
z<P~n{-v%ai%sKJq+@11itV!3MYu=n2ZzTxT%-;@rc&9aM<?FZ#4p%P8!~7|Hdxzk~
zxnZqA`?9kOVyh!nFtKZ*UY)}|2ja*#9k_GurXw9wJF3GI%Jz27F9KfjL1&cdjt0~>
z#f6OY_rC;v?%1-A?!AY<tzLH=fA_haty8bpikOc+i1vTgzrC_}0{#$SPjrM;7AbHO
z{1118R~D~$xq$xjk%hfUz|y(^#R+kLUp$qx^SR>GlyZ333+~Wt`>t$IIPjx#f5ALz
zq7TSE!2n{{sXB>k08y`kHN$G8#ZK?!hn}<9P1>JF9;7q%^8Ci_A#fe3mI{Of|7@0c
zt^~zHZ8y0Hreyo2JIs94vANeI4-x0N>grVi+7d}L;=RkKL>qaLin_+ay}6Oc@>>F~
ziB~sJ8_2SGxnq6vO+;J!P5~6W@tKR8t>4*%G#I+S)PsY~Qpo7!6gNFE9oz(M_>Rxx
zcj|bHr8;hiw2oM%GHo4lo);umRo=3++5<1^=<fHMZ_&RywoC2#>_zh1^zU>NXV!8S
zO7X@)bpb=KnFGETBEE*(W67X^cQkW#6dRqkGCDd}*`W06@a@=e>@I32*9zS(f?Uq`
z%Prq!7om@w@2B48ZLf8af;sf<UKp*5lpXF|tHE^cB5{|)dm#k!5^<Nq6#V}^NGN<_
ziCsBT!h<Umtr3Q4!$m{hQwJP$H|TrOmSW3Tu9%$6#M87*xV;H(ZjtX2Q(SJsre^j!
zcTdybQJ#xEzH9d^B`frI=g#7fZrzFBzbJFt0%A{5#vZ==QjDP4=5!CdJB+lwD-j+O
zSX4aDBNj!;W6NEgeKA>-dOV1D7bTBs*Acz916_Pv(xH3nqNJ0@yXO=%c1Zj$3H&|x
zJT|2|h<I&y9&xf5!#oMY82(=^W}PRivK16++}nB!h|r&0q^du7cvAAP8g?9|jEMAV
zKlF<NcL@1txZvUCh$#ETa*|)VQ#49`_4`G6OngJqC{W@?yi_dQ4SW>Jb)$j^%GHL7
zU)vDhi7(aWXsKWuTf|~tld*F(d~K7nPm(5R)8cf5wsW2KGRytln>u_$B<QPoC%Pl|
zccP51beQ<=+nljrFZ@!Mr}M6SC0Z~rmNFPLE=z7XoucX0RqN)~n|5d;zIv3#g@d5M
z5K4`>dBiL5@lCP)_B{3|R~pXg(pI9Bk8$3C3j({ri;H&HRyV>{H#v8;<B216xtNKB
z$~CSbSJ{L!-&BC_*r?^mB-1RsH3&`TJ|NC-HXuI<K(p=QDb8`vBM*_b#b-1-xWvf)
zq*Kn*<H%83+6L`SLZj+%mjxa{mUb=Dwd`<F^+z`rAm7>KoIT@@I3I`YaW1g)ci?87
zUUu7P7N|u4*BI5j;aTKN==(sHt~FQZMYm!8CHeHD$wT8uNDsU&MrSqywiB1faJ#25
zw+-0tL7m>Jw+C(~E-T?Rt&^f%n|{Pa3oJ0v;arx^6H5N*NX$ZwdryOzeuqB{(;fW|
z1;b>VLmv)S{tZ6w#LWu=zKu_HKk}}MU|GS_d9&7jho!W^v)*IxYKO;pJ<qvovG7CH
zL?j2?j_!Cg(D7}@w!8^*@z!?ES>f#{df?r*#ysAXK+OcSxXoqMN?O}MCQK*V+c1Bp
z-_zd4p|g*s@_UNVbYr&4TXmIO2XRirOv~JkYtOHZP&?uObZ!<`s?q$;>BAZ(B-*#f
zv9nIxoyzjf+}BPMygFA)?#3QpyC5_|#WZd+y0N_tbYg77YbdMlSA4LYIkqQHTQb~n
zKR7y2iGLXGmJ5gND|7ZfyNo9}jx}w$cZh2kCqLjrmxp--ph~_jcKzXY1KRN^9(mxk
z)O$vK+Be*TQmpG&1Z;LI>Kk+l4tC_ckfHn-^<MNZT^_ilQh2;lE>#Xob5rXGqlhqo
zfqm^Fv8X7i;=r@&n|QOv1%O`I7G8B=FqL&bGyTE`1#Wz6Z_hHk>cG&$ID$2KC{6Kj
zc9X!-`khMQ3TF1ZjWFXn%)t*CVUiBaUF+TqA3qK}w>x&-$X4vR8L`ZXRcrv!y|Hfv
z%o!b~F^_A9o$v3&_us!4b>R<-J;g;-HfVaG-T-(AbKb*p&f8uCE#Q)0SsI-yS97@A
z22*-udIj>|I$jA8>9^AkIk<I9*(JSaMtDWNwxsIaS!RIyiE3*ESIeqTsDs`m-p|<t
zo27R{1P;^zEmU@#Dqta7z>Z;(<3oV`V~n#k<hBY{(xVbFwNXWGz*Fs->e8{}f94c^
z>Cq^vIZRFANy{xW^l}p2eeA$|vmFLcfbK=9dpl529pSym2l2Yuo_%OXb<kaild__W
z00ZqgHTXK+X-RcZi@x*R39Gko4oo2!%3ZfR2>s<_SPp0`<Z?}H3BfuVk4G>D{JCvB
zg0IL|e&jg8Ivxdlp5A@|DyxhwwBVg%*acr)P8j1Lg(k|kPPgI%Zyb;4o_Par@HK}i
z=II{5xjfb8sWbW8iPmqx&-}($`Qi8Hm+nMkTDh`SIjqs5H%2_)G+HBXGSi|_m=5=1
zTN+*pF7M3)AM<y`&<10I5Wcky%ex9~m<KFX)aEt*YOUYEAIIe5usxHmnZI2%SEsi$
zJcp$bFrHJGqqO4Dc_us@7Ym@tygGQmkjC$8p6?amqa1gi$Gk?+L2@p}DU8x(dG9mp
z;sAJY@mDOu&a`O`Pwn?Tv87oxw7sRb73<Hm*6q}oUlwgG@v@Xh9`K~-i8d|rc)nBF
z*yZN{aJp^jo44(C?RyysiLR%ax4LcV8?|H|T+zNsG1Rwd)S;Osv&-#X(!V*Zs&-U=
zR_!FK-0nr~8x=3XifXs<F1MZd21aRJ@O+A-!8;wefn&jH?x>-#%D-bx&HWws*^7EC
zLGKbv#p3T&kImA99QcR6V=55Kem{Wa-?z};ckC5E(02;i*<E9Ts))Pv_s8A8Kjgp*
zguM6RdHnXzaE~>n(O3~|BB`w-20Qj}5%Cq@)VX7nf@tNy(?|5K24I{BE-#>GTU>*<
z(ekYba!PL(;cxEuidE6RQEl4u4K11H=K%M$Sk|IZ$$~-UkGkJR!L$CYfp71W`R#Mg
zw>)e~+y>5lOK(=7P2LGr=}Dc(GoEkadToV|;xpP6Yx4X(`w_)v{62qFaOV2LD(C~h
zBO7E|UVP`|cf_W}20rl`)LQ82YcWjb@bW0PBrbU^i|!O}|L$Hs&hj6C{67`TVl>B&
zNC?TlzoP#R+kG2s_m7be-4@%i2N%z)zaNk75D$M-zVu;?(GQI}`9!UR74l*g`0f&K
zH?BdRbw?~)ag4&rC*<2{#D1fSe1nH~hM|2F4$L<djD9?WpAMwH;h0Q$*|f|g^mS0=
z)CG}*0rp|p_m?zSCl}M#zx{GJr*O-5asajfdQ?s26iwMOy%mCQ)VJyz>-P-o!TIK7
zmfWvYS95=tn}onK`_DP_yZasQ5s6bM6bqdGc__AH+x92iew>DkKTbIe9*m&{vb%Y1
zjz3?F<!uUDlnZ|k`u4>AqK{-bI7?Gn8(`vl9^X$n-;cHe(D|h&(f4?}6HjdJz>DWu
zdfs*mwWV*x_HQ4hZ**6B72oit_P*K2_tJ}#qRnQ>BfWc*(fg9}Lcf>MkJ6U7Y;!a4
zCS<I7U9^`zLOsO!tyb_Bmz1FquQ#4RpJmvu{Mu-=c&%at{po3khY&C=q)inXHQ8U1
zDAy2g_0-lS&a|(<W)y90&frTJI^wn`U{3+tD#F}$8)6K##TiUIRZ=gJz0i?LkHk4L
zP}Z_bcNKDufNd3Bj%}Bnwr$#FDtv$bDDnu<Xopi6-FSHtxkDx<j7w7+V|3vtk1)U~
zj2v5T3OHv*<5;FxW_1vXV^tn4$z_*mGG7&+YRE6x{&gHotP>ixt=9z(AEU_O!K`u>
zkEG3c4HG<Y`<<u_XYk^OdNoedPPV;0v!>?B=TQGO$w2a8LQJudO{djzoY*EbHuB&m
znm~iECuM9XVD4(d%M1iUErA(3<BlU~GU1jyH}eg8_o>00wO(60LgQHzD<%X#@}N_*
z&q==5qE>9e?eeYAyWIIwP#}UxO47LHL&N1Cn_VUM)R5!t2_%zUd84LYvautQ?mg?>
z_Cdx|sh<a72l}u+Ep`Hp!gr98l<$9Fl;KA1e_({(4WtuzWD8G8x=GZoneQNUUG}?@
z)<C_~dAyi?C(+i~_xQC)K`?ANeh;2GcG5j`LE1?ML|pikly~VnTzPrF1@0-#)|z$h
znlO*5N>ZJg#$wFFLDcG5=b?CL*+9_)|0=d5QUCYj!LgZ6vbZ<8@I^oD|F3kws|=zy
z)Qaa5s5$!a9H0Z*n4Xe05y#pD<E15@MI;_|Y>U7%UwGJ<)=#m#xRCYi59PM6glNlk
zs}soIn6694DGkEhReft7YZ{&4c1t;S-s{4(+7<O_XSMUog!HzOvwji7nh4Wv#TQ85
z5+&oi*e^chl%yA47e6>c{86H*%{TNhR%ZAN|7t*Z&XvmVW&8%D;Dh0A1cWQx$M_7%
zw1)3`7dY1E!S}iS6C`%?Sb#CZO-ev_pX~2#8+*g2{26;!TTo(tvSuCB9b5a&+fh2+
zxJ0${#<2zHY|Xl(_&vTzzh~iRR{5di_;^wO2j3Ykt;6Np;do9+`{=I9`C_e6S99^R
z&hJHfuncI`@AS4Q;K_K31kZCj+JA%Ji*+n{v0mcuclFZh2SH+`zMqJ3UhRNW>9w=N
zDzuFAY0NSE@>hkC=B-Z6YUBfi6BQYr06Nc;s_&<LzB5m&QPb#)Cw`O}efOxe(+e8T
z9_?Q49CLB)e8A-|2rkt(!sZ=xoCDsFxYT|xcOGllEvCv3>W;hu)(=TnhW2ec$GA1;
zt*_{9VWh@M2Uha9=J9T+%e^0TXksl)206E$_?-KV>lTQ;&e*VOlW3>U^4n!ZpK)!e
z)(+n)lfwOq1FOkkM6Gb|M12f;)8N}s1NU9)b|cq4=hR^w9m^It%;epd2fhjZ*OAjd
zZ-O_lL$$h}#`t#pM{c9Ib~I1xXTZa?C#tQTN8jQR*-{Cg8<mnc7{~Ez9&rcX)d%h$
zdOJ}2T@?Fyen~jzxZV<QHb}|v!_v2@j@C<iY5O9d=CSYfH#s;ksnZ5Ym9ncblHO|}
zS}kx2CExi;>os#RTtc*nkb{>uaU%uJ-e{XF5u++qV>zmA9!`DuD(0hCP|KjPM)(yM
zOmS}s5<RsOwpyog(202u0lrTjlw6#9TopLQe%zKKkK>Z8F|NOzMNMVS*}rRsR}|b>
zHjlc=9OR@esx&T9?uzZ{4r-_1;YK7~r;-KgSk5h|24lj-WCNm8Z`M4GT8arD@hNK=
zI!9dB5WJ%f&{7r<e-(CEl<{aM){IQ}U4F?yj3gw8My2H!$7h_lw+S^J6CEiB6(Hv8
zCa!^m$FEm>aJalmG%b9{vWSrTNh$Yf)QGz9qt#o0!M7gbWHMCKV4W_ZPGrLE<x`+{
zIqg6}1M>7;0X}M?qv=$afo-9iBoc0OtS)smi`tHfPDgpVQgfwJ1mQ=V6U<-?G0}8o
z)9OhY0<MK#_i69p*;`jqSUw@;ej2r<&OBf+s+OHXi*&U%m-Fve(U+`adJDls%fqiE
z$C`5(b}91jDF6AID-q>6cmeew6HQmg6<5i!7|QxxgL;sut(RYqg1MZka^Q;s2c<$<
zd;x!)L&s6?nG^F=?{^+U&#Uj8keJ~{P+M{EnBjPx`K*Gg(gL)HD~6#r#2sAiFr1T|
z7BHwsAf!PYHFsK%n#WuWsfzraZT+<PU5>M@`AB=tq>@o?zZ3Nk>I*SWx3+K1(NybL
z>??BIruDktkmFy&p3mZzTf7~Q<H}f!mz&6V@ABva)6->ZAy=@nV;S2j7RQqLiK0E3
zvnO(6xv_Z4N~aPw{*W2lyon*LVj`1HBy-7(m6|M!k55cYBquWILMm?+5;;4y8TQJs
z<9U00vN(}TCC04W_*guV0hx(nDxJ?2isQN5=8?^@uS&jOK<@V&u|skT*UD$yJpw?t
zFwnj}CvVz`wKUSd+&g!)R22uNv&H!=&UiW9!20Q~%gyS15AAFCjTpD=+Fw&sfk9)6
z#<OqMX>{#9mqu4mm&OcoU{{W=8gOZJ1$A@!QRL4qjR3lGJwnY3E_rZt70|7#jy|Ap
z&^{%XkFElEaBy6t^Rd4X69?O}RX(4o`8~&}=aDPJ?)WI3nsaSJ4$Hq|cIaHQ342v@
zE99i=yPO$wZT3d{Hys6VIQIj*h3y@Kn6!7Xx9C3D)6Cv&Vw2{t^SlD_=>@;|q_UaD
ze6>#dUEPjRp(;L}PNp*xmOW-!seC?Hw8v8!YdlU7C}9^T-B6XW<GGZTn@m^}xp51j
z$SPzqlZALXH!+qePQ>+4HEAaj#mV?YJXx3=&nFV`iL^bD9#7;7_C#hZS)@=E`?{3j
z5@OX0zOiaW3(*?3FxPS7)*-|#>KESgd$>JZb=N0!l#}=<UcI2=Ro6~){k$uvOM~81
zb!l|%LYGEYP?yFm;+0FIs|s8iT|wP=bq`{VOQWj-bhl8k<^>Oqt^yiy%plgdd~_AS
zgM;JHs{%(BWd&r9h%;RKq5ToCFXwkHesQc>k2ux(T@N-K52@aBkn25|B37KGbWT-O
zen$J^4pM&R0C@7FU-FATv`0XfN(G(CLLw6%8!x2dX**L)Ojz;pWWi34=QFvCok@?o
zL1)}fjwO-sB-4q69k-D}<&%@eVkSOm*~LT=fyB*^a_LmYp0JWOa;;1;pPR^!7p%!l
zK8`q*85<vO&5wS`H|DH7##;l8o*$9^gXBlub?MEIeo4ift}R_Z?F#C~0?LnE8eMI|
zrO_4Cr9t_TOQWlWxHP(gy76W`Vueeis{(Y7Q1Rwv500(^8gUd5D_lOh3gE%P@#YPI
z1KT?n7D}`*dbixih;uvJ_w1P2@(6z8y^X74JGSnd*`fZvI<{l)F5GrT`v^xc@0!`W
z=ZWq6X146zyL}s)p>Df+-49IQ9{R0&cJJRavpu_S`<89|XZ&||-<}zQ<N7Aey?z<@
zwqUWmOdI!__EM9sM6qSOYprjdM;_4;UPU!`9!+N|ei>)u>DsY!wR+f^cQ&~5Jo}W-
zciz*s3FER(6TFtPsE95$i)jwaTz{oA1v)HX#!}AJDO9eYEw^ed<!)JLxdHqA<rpn#
z7LXr0xdn|Y@;9|1mGjR{7#HL>g^c!-{^2;z7GX@lo?jAk5qndxK|Y5Ab`A8)`)ONx
z>;nG(PdS!oD<8!L3$5L;=V|l{;HWsU<FPH{s0BDXQ+aH<=6t8ww&y$Db4NDyQo`Aj
zOn9*q*1hjW&~RWbOPIw5u7e{u+%!WxkUf3`wuQa<yY`U%XuqKzziZD&ab^E@7j6~(
z_V`}xf8DOyuBP8$%{sod;<tVK_Uv=pj?iygXZOuKNp%W`?nCt3!;kOSv3(!jj+hlW
zJMnW|`~C6#+ku7V1WudSZEhQ!gMR|e-EX&R-)8BH)^3&iZTFttkjmvPwi@4XhU>9i
zvr4YmTKt9^y>N+{;x{&e-?q%m?AZzpKv{HW-1ky%)44G*XyE-UOfsmh)l%EHt3}$o
zd*`~Zp=Nvg@jvr#z<z}bZKw_P(H86@z)s?sZP`8FM}H#y(Qmhl-yYw+ZTr3*GkZR&
ze!s(kMZ6F{3;mo)(cN)4gRvDpzyFh{yx9AyRp&l8`u1)74bK<QS_{#j-`DW(Tg7&2
z_4{4?`<6Uz)NtY7rhadTw@De#x2xZq7M*+G-(f2bPh0Ri?390B$G>mIu?G$QZuPq$
ztKi?R{Z6?Z<5|zYZ(pk6XZ8C#`1c)N{O?r1BRFdC-=Ti5+k}bnZ{Xi|9;-o}>i2i?
z?=!etPJ_RPe}Al6K=&&6_wes~tF-+>{eCb1zF(+Q{r+9r@4CG3Ge@7ZLd^>Pz1r^t
zPj*H9dmsP)19A1+`_yk^>bH&Rw~E5~e*SHyI!6J8e3WqB&%f`+AY&CVuXn!v7krD+
zw|&@FUD%CNDL6xoU+Ats`X<f@iEodUDvJ#q5T?L+Onpa8l5O{vwa<bswMRUb-?z?J
zYc+9jht_>>;@eJVpGpCFJE<KqIKR*H@3@kXe!m;z>U;6uMWn45P>4PCo3m)_{Ko6%
zw2%MmoU=FU&FT_%=gwCb%Y`h?!lJ6SSOYC*OxTMt6|gvRM9(P_56<r|%iqQ3&oTG+
zSFrv|@Zxv)29H^AWcpp~jiIYCiANr@E<4}&e9}^0`$lK_&`y5)Bn}`YRJ)DHneYt*
z83qYZ)N#Ji@(tfrI~pVPcBEV$16N^;#5b|9SFcy9&hX5qu3R~vb>J5H3+v@PaQzm}
zJr(GxKjA};zV3m}@jG_VVlyCM7@p1-<9AW$*WnA$FMcOJa)gNC=?shf-Gl!;^iIFy
zT5YjMfNkXf+X@b;lYaR3CH{SZeblk76YBS;a4_1r|MJ-+<$Q9uC}JJKJ=V39p3K(s
zS#eMsdnfK(N3e)T&d}n8ZJ?LhU=d4Au!PsfeVcRuT;WCBGQkpF1<QJR6|(;Sv7!wH
zf?-$R^m|jRGc;-x)7b`}!=L}5I$u_-Wf8zB-iY(l>oG3lZqO&UJHOGns}bCmiM)3A
zHngL2d~d9!e0S>;dvNfY&PV?dGA41?+hih@9#6%mrjFu@RN4dDSS-UsdCi3On4OL}
z-*P1^XdF{%n>sf``#2az-ngZb;sWYQ$T(Hr$ortz!2bQ)U^5T7v)fFax2Ykw<aTnu
zYJ;!&VxqWvU$x{q!VG+h+lf5g%NG30$z2PmfqLLX66|Ka3J&Ypt#B%#hR)evA3`p3
zI>zZX-ASe;wt!=Mc)@`aipI~Xj&ksB(cb9*t)9#MbMEbi?=5#lpINWL$ev)kqMZ5?
z>~OwX#-QrFRm0z?_VNYzY_skxUJ_sY?Uj~qv`L4~<v)dSVP-ELD|;My?hj<Q%p%=;
z`0?58`_cAEspD;E`;Sr6ai$b<Q%c=N@wXzXkafFRKc;Fisj>W6E^Upc^L8O`B@4xg
zVj(|~OxUOfTXw1-O0}vExdFELk5yfuYg>0d-4)cGPp1*fdZOW$wUr%T7dYg)U%5)_
zM%s+Vs~gfguNM|p5p7R9-Z<pdr;DvX?RgK|b-g{Z2!vOfy0#I#PmZGpG4?5XjulE+
z%DvaDyW`E+F9x4Mp5UxuI<k22$>EXs;61WCf6Kc^mi>Unp~vWc;+8wqUq##9PJK^~
zPtIQ3b6@ty^9bR=GPXn4nYYn<wBR*gM7A@J4+$wJ+4|q*`0Y$Nu!4$vEub8^30}o8
z=9PF_B%W%y`eFQ;V*}x;duo;zZrtRf7MqpNr_mR6M<xRBv_Io%ueO5F768>ghW2M1
zT@e8M&xv6)R{UhF2>x?;T>UY-IWN*~)$SDd`$=ji`Q9OQK=S+=>p+Z+VtmWyXhW5a
z`z%I`;~V;#u4i!X1HJ(KA@I;v)WrrQtVn)p@MSL^j_~M{QnNcto7$LOu=4Y`a3@P+
zvf`WRQH~Ohp2K=)a!NcU-&OQqPxK7jx6^cwv~$0(e00ZUXnKAkDsrxTyyq*8+}KMG
zYh{!%1-2-6|5yz9LMU7=Tk5{i%K}%k>ZXYfP`g3t3U?75k$zT2F7j(y{ZAScl06zn
zDGOP!8i(7lDwW9w?R}`zRc4BFb8_ttxl9<k2CVI*TbYADJ|*eSVoqVAD<)-hC{(f<
zoy0EfO&DXs(GDv$-DB$LdlmLs>a_i=MXAmKXxFXIifc}a&h>zF+R?O=YT?B*Zd^p}
z`fKWq@%z=dki@=9)9)92e&2{Wg$e$w=l7=-{`JUlU3mBRlP$k<j=2iCuLdvfUgU3d
zhoaxN*E@VGBVTT9m*VkHeACA`CtA6>bVm&uhdFnsA;0#<CPO=?zt!D)Z?v`H*l4E4
zJf6T_LoY33J4wyWN!GuU+R-##w;t)RkcD%XB_o_dr{G=@a5VkzjIW7(g1;7Pg>&)o
zJZ25{1H#9&nB30WNro|#RCCs8>;)9KbT~<JO8WFA2S%;kNNOm6ROq6eGRHEfzJhcC
zI^wzODeMu{<AHBmh(j$o_a4PwL2uuoL_)j7oT`=*nC<HMHhAhkc|S!<8=h}Yqt@@G
z;j|Gc8f4%-pf4HWsIDNguq?eS@5t^Q&42<n;M9x?IHTE4%k5i+d#w$Q>_LgE@YU{Z
z#Yb>1KDtwm-Y2<}b5x!;Vdg4!-GMi%AyfThZEVNxJ-c@A+>U7|@w{8|Ou6|d(4Ni<
z@N^n-;=!6)wOq;{(-$3ac`$)FRAhyZ&h$|*{i4KoQ^VJKPR^%!=M!#DqX<yBJid-R
znq`gv@zj*hS?mz<s(tsbA@`1yN1k)b!`dI0{dFEWccgUWd0)m)_sB(xAMQ)`o0I(0
zJx!6~*UmpOjjK`9(9Sb*EIfg^0m-553y~MENJn$7xm2<9By#o^_ySfs>eXXhdv_Y}
z8p0BC^A>nnC&A8Kyld2G(w+5Ae)lZ$=`OHp9s54n4?B?yx3r;)Yq0OvJ^%M|I}8Oh
zwXKu-m1E>f$ZuQlEmjmpx9&EB91(D$HUUh<d6dn041FDWUCTGcH|I@sb_Osa;>qT!
z))+_LhHo@r&?oUm1@Xx1=BtsX;k&5Q=>SZB6Y{RM?~((my<dEgu=%`$kfW6y=UzC5
z^?hS(v7(^$TFh5qPoi>!3yC?Op?LqKR!c!aM=!;oo_W{0QH&|45PztKm9wzgEN&um
z>n!v((37GjFUmBceonGb{X8|6nH<l>6Ih`_&8mzFrgJ|R?-8N3tdB8$2{JwA9`SH?
zzPfu#=nkqj__zx%&UZkIjGyiZ?F7&G+18VgvlTv@H*w_BpgNPGO&eEC<K?dK%$1u{
zok84eqtPfW6u_E6T`Cu&y_A0KGzJwx&f(6%=gsZnIz3jmqDS{M258qt?>YFLUptM@
zHhSb!0oo~gTmyU_^NWwg$`+n$!rq+xybVQC-ooGM4xE<n^n`_aE8s=(-5JrT8?e*d
zwknG?=YR=tsVu<wRpFugZayaSEdyk{BOY+{Fy~pVcxV{~Wl7C8gzoSt3>Gl43ZBJf
zCRVutkra+on2UILX~*H{(SU^cpmR+o9Ibt5K%w}!(jA8{A5&5vHOyZ;eAH0t<qa~_
zJER7>)P=TCi8_>fcI;NCw$vkrwmknlj=4`qx-@#w(rlI(a_`W8y;D1)+0u^V`aI@9
z9}_ih#8&hr|9(^aj@rBPv-<rYV)@5JP2Ksx_CAfcx}WaZTx{l5;tzbhPwo}O(fzSQ
zEdbtKtvrTaMhsQB<f;IV<Fr20@=YhF_?$+(V>oPWQtN8xo!<qUyx_ol?KUDW+aD7m
zVC~nLgS{YrBXCzYn~+=WkI`?0nR16U>wXM+dGS6P<FI3`4uf#6X~j5s=enQ6H|!e|
zlO1f?C@m~5@Lk?=g`05TT|<oj*_~T<Z^PEe$F|Jw%x-t~qwSEq(A}Vu5>JsL5A7zv
zDlR`Ii22qCU(@yA1EX%8bmYMY^w>jt4m^19R#Pu{I0rnAK4m=hD&5x1tl$ngdPE)n
z@VeSs^eMyAjMMwJB^f6l%y+(u_bSnzbLNvB+iQ3Axc9sJ>!Rgi8J=65fNlBn*fR~K
z1Ge2XY>)7ZoP6GDWWA=Ma`Ce|oV(803a;*|AiGs~acOJyu-yjBIp#G9i$s~ID?8;J
zlk&MQaXv*y#zj8o44WJqC|~;$#SHP$xjUBX2H02W$mXo?i7s^O2G086O=o=&7xH1)
zTp*viYuzM%yXE|z#XYq-vKyVB?K(f&QXTU{cTQ{<{D@^bRRbhhepLF4!;(XFYD$i~
zV&@}s;?66s`?kYm4mT%2aVnl1f)9WO?gGM_YnU|<?;I29?qU5KPZnr@^iKHt-kB}?
z9@&nUXJ@xRLOVuTX3A;5%rci7wtaXSw?fX53#+{J9O!;Ic1RYhG$3zCRXAzwtp#V6
z0%r=(Cvjf+I{LL0Cj+&hRr&uLuvIT!xiv(x%<-Sz#x%n*1$V4?74fwNwtz|>^q{t#
zsBz^W=AqqS*-j21C;c+^KNBXWpPU#^d%pO0eK6ti=tcc|%Xn1Ayi&DwzUe5`cr=Q<
zmf=dc4V>q>*Sx=b+Op5m+m~8fr38*E+mQRVe|J&Qo5{36bM5!J_hV(TF#(9`a6$0s
zto1*K&1L$%S~RZRhwmq3yJFdz%P!%SIwT7BG0sOdoaO4=SR9XTH~H>$hwc>#L#uV!
zL_CQj0IGdV=c$72mDwtmkLN^9hH2c?X($-lMdjkTzN?K7Z0L9P@{=4S|0M|{_`ucD
z&5Sd4)3><JN8TDE+}v)j&i`0Eu77*T+b*GhJEhZ$$2~aD>EDPKot_uxIN{_ztm(QK
z%T|vd*&w3K>xllnd9><jtLuoiQeu&xzH_ca@#<G%q7xOqLtb8zI=<sNEy)Wp%e*|K
zf1kI?MSNp9PU+udTS884$>xqry3*#vW<<t&T*`s)mBlG|kA5!cc=5&z12Ek~`gcip
zVl1KfI%oQ>%cScNS7PZhJ#T26LR)3WdRxa=aHz%WD|>Yqx$l>C@~l@Ukj~Y0T&E2e
z0$C-~Asr{_g!*3lentN-`J(pBcTC64J}!NW^*W;42`*EjXQ>DWf4{EdXwG9BB<+ZE
zzdtW|P`;UMR%>ZjzM8}@zGKC}M&ix!@m0|I1&s4Wye?BLV?s`)F3e0hep4Rs3)q8)
zEK__UzG$uEd*3JaZ;QMfS%BCFy<-L&Js;UE4lFSY-Sb2X6&lR$?T>7k-SxzFg$L(M
zT4Ct$lQ_&ka{!`6`B4iVI>D0Nw(AkGh*Ad}?Kl0)3XV=@IQ#cd|Ek$}Buxn1&C(na
zXgswc4)Qqn!ppT3C(Th!M4~M=^`H^<OVInBo5m7p%m+!4&;#+d)uRWUrqqT8=jy@$
zw|}p~=jx*cZf5(AS>U4@B++$s(gwF>+mqY(?a^q{USUUnEwHl37$?pXnBlg}%x>Se
zn~nl0`aCc5Dh_h19(G}m`{CWOXW!QCI4QJcM(hPf7vhF)XDdFv8BKR;nm7{go)pCb
z9O3{il{&q|7ya+P&B;%mhW$Qj#6Wk*B0<MYqlASs>fsz77!&8><SLj~E+^NOCWTGv
zRt;Meonv$(u!%^~`B)^S{bmNRU@5NYRtNrNW;nthXci*>;$H0IC^j!jaJX?9Z%|bA
z%f4k>kvs2``h4yVKYiA!P8VQ(+I`ciFO^1(aiwW>O6v3)<^g6K#eBX}z@<6;nPwDN
zR+{cUE_HVk^BuG9d>m4qx9h>h`Gj5vFYgCw51Lh+uvh!KyMzqy@kOa$I`3oFufKQp
zqYb>1?Hfn>!MifGjJ+RH&-6ZqS<hbY?MDZ+4yebIesHaHeV)a<->grcxIhD>Ur?a^
zqw*+76yv@>IzO%Yw&)rNq8j%vWBuK%Pk(<6tJ0`3t~9OkxKD4Jn04y))3ADs0?SI%
z9gq8Ku?B3`osWNa33dh#lPz$D%Qw642WbzQRh)EncL~}5xIcsSXtRF(y|W)}^fB&t
z?7EeyWp~^^h4pT;p1t1NpKhbWwNmx@6}eyTBG%rOJ_BFfnHY=bCeq2tT;9&%Dy^iQ
zP9||-7VgN(BomW)?M|(U@nUW~kuOZ9$0p;+9L{@A#N(4i+ZxNq<N4x*ey7%CqEMJj
z<Zzi^YSK>P%28YaXy+#~84IVH>3Trz&e0_HAwP;Wey8}d@)>Vk(_;N!zBi2i#}kvO
zL^3^@vc`&5Ay>#xCNs%Q9(uO%#z<nqz0)k6v@?^bi9$XzVUOnuWATDjj8Dc>`FO5?
z8_dRZ{ad(5)=Cv7tV!FN#8qfxx#AdZhqcBgQ@DFEiN130e0^vnl>Udtc&q+-4>|26
z`KqjUp^j$PJH0ch7uIBXi}#Roe_nlWnEp(SjoU?-{X}shpP0a9m$+!x9#4-Iigr3)
zjBEXA=ZdM+cn&w&<qLGn-`J#Gn3&8Ja+!%-d~zbA_h%Z{XXfl&A)Ok_O%`$!nH)}9
zCvlH&Y9f`uMn~$;FUtKMv`>TeVBS}*uWE~@<iqcM?+F$0<?QX9L2WaH&ks$xtu~jE
zy1t3^bk?=53ctMq+(%2OC33q+`l#dHf1R_g{jKh3yuLAv{ZA%g$*JPlSYf<4R*2i<
z6XOW}#dIQ`nk>f0Gj2Q^ON=ElxH=#+7N1P#Gj;-D%^u4q<G89Zo*uV#`^R+{R=zl1
zq_HD~Ypd-{9#_RCCe!hBDn5}C;|cFCs$o9@=~la@N}U;ZT-|-YkM5WGDvdq<z^z>m
zc*lkh+#kw@ho+!bK{(FQ+56t}hP0hdrP5Y0lS#)jxSn@x3`^YTmt?^jv(QCuKTqJc
z@q8wkE~XF}#}K?ysbV29X(2R@W69h*Zsii0#F%Z5CE}T+HDSScQg)&+Uce3JMdT?I
z=Xn3Z^P=xOT_^U>b02d*6&?uHPeT*1wV(KG#wP5A;h3R&^wd;=wh)O+5wL`${P!02
z!uQ^<h4e%+pGqJT98agL@myj&GnTRnse)z0-4a^Aj>pF*Q}G-eHlDT;xp5nQ3yT<!
z=jhJ*cwYD4Bs`UJkz|o>oli_;;z$R_lgMI{b|RM(7d!KQx(k||k;F!M7KryNEun7y
zRp&h$+_=b^%P!&`F078qWI*oMVH=`1qe6^VLsMp}4YAK$#J+s94bh<%_x}7<A98F*
zo&&-jW~moC7nz67)IBiWqc|<1<>Yvo#J(%0A4%UD&M@83Xn6eu_t&WYruA88opc^`
ze&)#w?;Q0ZpL#;Z{G|^E)k}BpAiXf&*RVT?e6_p2yU)UOyoa#KCm`OgQCi1)6}xAG
z;q5+a(eduYCa++4yJydYmt*HeY^VWV>`ZM|%W8|8v*Io4#1G>2Xq;={yzcm<5uQsC
zTx*i8=p3t)6YRv^lSgB6d*zX$vs7;^9GGi$;<0HkzE9#?Kh-Bb$tmfAalZOJL2>%l
zyO>R7zc1hxfM9a_<J4GHcY>Vw-k^9rbsojvqf(DETf*VddAgtbWUG#=QQ`d<e6KL?
zUA>I`BCbv}I1MS=&GDTc*uL$i_Gq8@G#=S*3Nt}*`u8#Un(prhcK44{V^!JB-n~Kb
zcD9@JzHoSSp4e_SVgr+A53OdS_9kz8!VIV5e3-|s0|cuVGk6o16JMHCA$BgxqVq$G
zl_p!Md;aQ;-f<{aHcLKE|3D9XP@zS#!E%f~*=u{n0%DLej$iBrhdgyG?-0WV{ak4d
zH&Ry@=jK^MPfEP6{9q5fb;9ei9Q%2R8;7EN`p?&g1bcqVwZ6Ngu#kfrYU@_MnYHS3
ziwpFYWwBmez$P%<k=<xc)6Pq~Fd`S+<Q9L$=eCbW%co)CLWBlda0<icm!v*VWP9gR
zc1sT`<&F%?EuDjLZ1(D*$oVy>wts$qO7c6B^W)bOM+a)7%-hC%|GXKL*Oy&#y>AqI
zmd$b6tG8j;BJ-HEBjM4Y!v5{=7p46@gpKoNJq|ivs{Lmz5i=HJUQb}3eU!W!6dTYs
z{dwg$bOrZg^vdgU+NvMN%<ny)h@4-8dV|}oAHQFab~}&Sidny2|Ch$pzFl3GU;MUW
zbsjVQxTAZ7opGpE?w>z{0{ga4j!jEAa27;=!>~!_@mZW)iGW9g8vD0H=J6CxcA0q`
zbo>-oDIn+KOw+v=>q;$J9t{c&XqW9ga^Aic=ZJdM<8s<&E2qroEY34U%%?$}!R@n^
z&(F*FbEfIX=OE%^D_60Y;%l*gz6=TrZGW8Wo;ebXuR+=z^L7>oW6d__?aMB_8Ppcu
z&e$K$E&1^_==i6`WXJe~Ma0y6`_*I7@@Y_JKpQmk$$dTgLw<aE`<jULFu{(5w@pv?
z&s)@b<GDfnFZuB{WINObWaf40nP_>9Os5*JJTJKPmwV^6OB^zk)Pl#M7Vl9UGrw#9
zO62?+)Z0J5JWn|EDL;OP;O|PC?mTAxulCQML4o1ok;WhA-?e9h@iz>cWFC+IwMck0
zs4+S_JoRZm9tRyiF@Mo!G3+NV|Mh73Gbl5lO?vs`JZSab=$*giv`H_QZXPuAnaKGx
zs4}=+w(|KoIe$6z!+v}YA})HlVxCT(?4KutvO?J%=ZhzPBp6SFv^D1K<Yyz{&7iXI
z_Qn2s>PP)}8+5!=8I8y2n9pmcqUF<|%z*Z1=9BZTk<azc=W^PlnOk?Au>50@^J`FT
za69$mmwoBQ(|-I8A|9H#W8N<Pc>lZ^l-HMCa_)8c^TBu<hAlFWSAQZB9t|q&-~O1#
z>u3CU9CW-Sv%ua$=RdUdNuARf`Kf4mG$=HnO}6vM@%+$F_s-*T+GZ=K%;)*Dk@IO#
zXK?#$<&*2lH-5&C&q2h+R<7JS_l+;~&zC`AL=Z<dy6x#{=Zj<YjlUI)uR+=z^Y+@g
zNO&`-ExesQdb_ipd-G?5@kW}DzAlUNRP8I+a_PEOujcJWqw3rr)+=ozym>2i$UR78
zt@Ic+PC4LNu_x&uMFRg4?-FAX9=(NV{(rlGVw`$X+S2*+ezr8|v2?&{k6OHyXj;RN
z5!SU^+Sb{>?Pptq7!Uu#o+6LML$arow5Qo${BvYaQMkxTj7fu%3vr0^rPnX?Z#RZS
zE@1xKe;o3o9aX;Mhkrz5_XEh6{1{jn0($bL=l+hLErkn?exi4uR}I*%q84vJvB^)r
zM$;OGj9R{Q?#q6*6+CGA$@>@f6wTDmProb4o;Y7R@XLRW>?sNtS&1=eP;wy-6=j}%
z>+c1#o8_#_1smPMb71sWpITFRDv@ST;n`S8!otp;l6H3aANbjs|3DmG2~mxJ;W;pN
z!}5q4VI=#%MqZJ}SETJ-|A&6I=MA{wrT+_i3s+bVukjV;U&7v=koNZCr9Y?k7M(k-
z+?Y048HHVOuD0}#BC#vOv_|@2fEC_Ia<vW|82vh2uGWFdAak`2Y^)?<VQHMJ?fj~r
zorO+dIw)a4V`m2rjNPz2q7E*uee1|8VjSmchyID5?e!FRJ4pW*_O>j!S_h4<F#i(v
z#<^Ph<v*wP7M(k-+?Y048HHW(zSUb_^Rp}efn|C2a2=_Z3fSr7{Kvy%`bxAs8bUz8
zb<=hpc|YjVzv!LE@UzP9V?!&a%;&|gN6x1~ox$_;Rz7*(YV4{XpI&Dflr1X0eye}J
z3<?Wvf4ny|_S?bu8l=rJZ>#=QB)l2a7T(VItoiC|e!LAj{$;oBo6T<9^Z3Iv+c#-{
zMkHij_x|f>c{M0BpdD)bweb37zF*~cdgpaHZPTCQSd4kT@oysM*`VU!Hrt73KKGmc
zw|+biB2M~q$oxI@yZ!TLP-5S9%H!eAe;16uVc910dEj~^d>T|4jXiQcIsfnd_#AjV
zb#D5?qz(s1Q%S^8=JC1Ti<U=&QiIxO8;>08Z~TYed0bW-ZR6A(m*W31a$XH8?ZHkB
zymJ1w^!t9i4kTW-ai;kCPyO>{P+Dj^<oLaGBN$(Uwms(W_<xRsKZEM}vp4qR6Mx{x
z-=O26I-@KDq8k{Q*Q<XREw2Wp2DC?iUO87A`7gcmx|}xZ&#{|d*8V7Ro((DvZnvFy
zX8*eM$9_ByB3}A)$o##0vw!{!O6=QCId8l6UxV>CEZby0Z~RFld>T|4jXiSicI&_S
z@j2*t%00&Nx%p-KzemfXL8$@lvz<qd^-JIAokzxII&5pcE}C`Iy<W+<xdpB*P<4+>
z|08l<4Ju{I;dtddZuS54<8=`6vR#XcuRradFN4xT+absA)&DCPUo6?6Y>)X{`$i=E
z8C2Jwy?s{J**5%dKmMYRhjVr_TeIrcf{nM1vvdZFU#^M8n4dQy=EtBoWpkbQ;XBE$
zf3tV}^k-}STrp3V|15Hz3~JKt%b%xD+~(Zh@O<nxpF5NXVn@NYYf;Y|7wOHTk1!M?
zeAF^^Us^`_DaN|4-5#y34V~Y~NBY;bAHfK9?MEWWjyTfwQ_`;Et9sXU<o+K_<KfBn
zsQ2)Mf@z<1zv|7A>)v1%UE*9My6-?XTHSXb6ioL#4qv;ocio2xuN3(VqYEwTlN+kM
z;Nt3N`7tP}Q_NHR@ECmVExq&8kKc6C67zK8t&#I&P*WFwk(y$jYTwp7Phsr{k0Mf2
zJQ;}evQe}1rDDl;u5A*w#5^5X6D>~$B`I6##uM*xc<8R)dFs!ed^qFoh3_$M@wY|J
zn?Yqvm?A=V-Z)N;e0%S_^<iIF3bg0yR=Lf*n4i^aqvgk-DBZSv`Qg618G@g_?aIIv
z_b$bB=I#2r-gVW5H-oyEvb3u%yge-E#aHgud8;?8OTsFvN9=mBTs@l2S1W~5vsA52
zs~U5;TAA~VSx>)R$5AL%v;5X=)bj_yTdhj686qFs=Are`@?%i8ZkxXRa7}63J9_7*
zOaFIy`vP&LohvpF^@dXNossipP!*GvcG-b1?!S%S(K}y##5(8lz_v)|=47ikM9Yss
zNxD7x^27G@S_ppnwx>3(xL@77O0T`EcRh9C%b+TzEA6QRUmW9Jdbb~6@ROsZ0<M(w
zO{aFqIC=Fu!{A_EsgC8;k6yh;$K%A?1?w<a$Vy2xUaE`ryi+@r*A$ODNP%~^#C7I9
zJ>z0^%m0o%NEkmM@y*`bjt_NA+_otO6Qr1)F+k1e94R^ruz6Elj2TSp<&ou~#TqAa
zQ&O&-@6%~{#wXi8Ob>12<!$|)ZE(6-w!Idpt<sC|V;cKYvVD1DAlmcQdQ<3!>D~&|
zPSF)_l@Wr3q<ixHLFl4i(TMf5{{A3s6iv~X<$NwsTT+i>!*|QNQ}P2rXa*}z5O!sh
zdN;$f3<IX<D<gc=X$ys_Zdb9PA6O@6M+c)5LvW2+Cw?S?6lsK^+$-&5)q~OLgo9x3
zYh*oIOL#&(>u2eM1JjS8PgT@4snp+_y6C3^p}_j#`1IPQAo_7m*-#win7H)aLE35i
zyV00wuKrM<w$5HhwBy)+I#4?mht<Yirn~9GLFjUyVZB9;882$>C=g_ub*t2DIE$B4
zQ?<orGoP(g%hmj0krC7@R#|);!7Q=S9Jzl}wp7h67I8Ywv4gyopSKIyTC<RyuM)uK
zSY6V(5O;ahX)#xR<mC4rD7t-le$1uWXzBw5hKEAuJRq3}(pL3}h@*NQa5+$WHH<4;
zm>utlu0p_hz>Prdy?H<_*%M7q9<XX6NLx~mlLx#_#`jZ!+6_1l@VTdgxHpaj9rBEz
z0gH2hTd5#=9I!t8Bl&WwB=%-$BZtx}P$yArR|=RP-W$7fU3?@K8;O-FsL7!^+q80J
zOdYF>6+F`&V_&+M8H}C`<Fkl+M&AhGOMdu+`qF(;U#nsZP}suag49>3lCRqfw$K^F
z#BN`(mV98?CpUi23e;;jpX^t)$|p}wuRxsy_sPEX@NOBKZhRy<J#<Nn4O3apntJiP
z@Kl2OAJ5$me(#FajlcISzk1Ys|H?xvRzF@(8h}pNpVAKxOecmIunhjxfl9CbbYbg?
z)lF!Bia<TepGLN?SpD?mPf_TEYXT>B1kp)*{bT(jLE4$?ALoO$ZL5F8cLt%U=Gtxb
zkIRADvyZ!LGqbz==sL-3lR5<TjiOzjnrh_hRx>~EB;W4-ZeB0C83tFuYFZLiBKCoG
zR6jUyTP*ftv3zx5p<2ln%ZrWqtW_ywkJd{~Th?L}@!#Xx|D%3#d`mv{hWdg%hsCEf
z)#XxBFH5&~*NfZ3vDoiR-JF;iyl(u1VieP6k9uPFOZ}X^gY@H=iDR-}Yxy14$L_)F
z!y5#n*TI8Q2NzcP>A<xN_L-;mMxqBp$R5g+*kcqQlKQy#Cenv2Qeo-aYG!T3l4>zq
zETN3xRCeKG>?=$A2CtKFzT&6$*38PI7FFYa;mxF%Y}Rt$#%znUR=tkhP)bFr#y@{&
z*S2DZ0k>qoTbdobZiD+>IDP(+j49<O0?Q^H(Kv54S5w(_jZJ)tOyQ|?G@w6`@-{I@
zKMMPC&4>5DwT-voIWfxX?=9g8bre~}hT~5TOJ=VXFPEHb%f}B!C8xosB=eh%eH+e}
zJ5cG^v24pHK0YjYL)&s#k(Di<J~S+ud$Q%wa&nGyIu}^ZFiBZ2RvZSupZ$)}&N9wf
zP89|(qrc@wE@q7Lhf~GD%jvb&=w)L&eRe()*$n<dJoglBI|=EBKaias|HR;B3}>gI
z#8h^AygYb0gWG91**G_7RszcwK27N*s)nc1(PlX}c)B($dHpSSnM79O$%*=~WcFI|
za>@B|Ifua#RBVf!!xXIsRR;3a0yb||7R%*Y6MMm?rm8g?HP32&T9k<~-znJn@+ke~
zfz2c0w^8}ygAX`A$6`5&|7OqlTXD6LaA~kVo@hqZSBAJCJD{i0qf4iCpwiJF`7FVC
z)Ihn<sIo!(@v_CbZR7Ayxs*TV_SonHPM@{uG{(Mt>d3Hk7uvVOsxS5xSr3~<jg<A*
zu;;ULi&mXXK5v!F(@-dOZL`TkfzxGcAy=@nDJwZyOy<+YLVRo@F*zBxCe!g^eylJV
zPsEdUZu2IFEQ}?_3OOrnC9Q&O700bidMsln)2Xqsv5AR7aWi&IGHlAStVAL;QJl!7
ztaK)onzSbild17|d@NySCM`VWq+-(9rD63|PcbQU|9n;U&&#OaZi(?8x0T;PADEgt
zG=_f_OO=gr)KS^a4xzr-yPc)u@l?E+h+FybOeQ`tmdZ^|j9ZDxVq$D8GoH-5c9w{z
z^Y%CZ3x&x<JZ@PNnN%?`iGL*v6Jrxe-Oh@I%vdgy$;VUaNjsexPZh~<3zLORZZd7B
zGGu3*ho5~au$^_vlMVY-BF)47@cYKl6y}R;W7kl>4Pj$L>zq~_+bw;i{1(T?L=9W)
z(57WV5y?2jbT<=i9)0HN!S}uYND#)nI(9$K&^ha?m*3h|Z{5Q<^v3h@GtUfOZ{DaJ
zy{`CN!p1dj91}Sr@;~H=eAL)4#ZY_MpYN$X=XY*AI(a-2-5SQFNaK+o{*DI8I)3P`
z79BfzxY9Awl9Bc-&OJNwa+mhTG+p!i6Q3Hqj>GwVC^aivJn**8diLtcwZ)u_8#hGz
zz@c?&DljO`nVi^k<=crzZrC;NbZK-2b>r2EX9wTk!Q)l9KIZx0)1MA3TbG%dA;nmR
z`Ctbs9b*U2;hsG)EP4GsIJ{yzimc{Br#>?*nY~uLTynB4pE?<poCcp-23zhxrDMmk
zEuZ=9u;dMG%V9-U@&4>uZ@lkP5zym(7f^Rhna8d|cTDLzjd5vo1$Ecp&Yv1q-}U5^
zefL-LZe5pMrwOhuyMns?6??l*qwDP5rO_2M7W;y%&Au#XIQv%?E2U2^+Sz&As^Q$O
zEcLb~oN`UVRC7elEFwg)*zNLc&H2v-wx=+YpI%m2!r=FbcXUOxbG1rUZYp-KSAk|X
ziS4d#AFU@lh)A_lQ_n<%DfXnap-b;@`GXf?bMk^!vF5}vJK8LbLTVv9SFYyhPC4<t
zZZ~W!Dm>%+E%va?gKO{9eV}U@L$BH@8#;S>@HXT>k_^_2SdVKr=z8orN$}|L8?v9z
ze17nH^hWjJ=<c}|-E|poJ-TE4KlCnL|6K=EBaUkx99;(z4-Sr}C(cCDhlcT!`lhE9
zvQC}phrh3Qx=+TGi{D9oafm0^Jt>lFum!AzQlX#wcjg|wf4dIAp1$FA*jELPh@$h<
zRKafI4i2nEaNi&QsloSsxHuSn_p^>KyodTJG9B0LvTZf&Sd3%j(`N^-<KQtedcEE!
z$A*LV3cb=cXdEs0<YEc;#MnzEx|$&NZV7W$hmjxo-h%QM0_!dObi0>qFFcjLVifCh
z+jj|l+DmqR5eZebLi%#<Fi>|r)Xoh{XZ~J247J@a?Q6}5(3!j-qx4jZ+HgL~xrgz*
z16Q}_N)5V9Rw}o+Sjp3Ex3T+TcddH_^YQctVzE0AE5y1Q(pt9%VzCD$%mFWqX8E$S
zVE-I{m%ccx{_;kMVe}FEdGmZ!IxxgCDOgWgNEc;vpwgG0vp$x7epvbl?ZeBW684ef
z&kai-J^9G8>fq^L46K7rIkaI(A<`V(4}VC%5L@}x-7?J!gV%w-M}$#xUuuZ`sT`|n
zUmCm~yq++4+3%I}G+ZwfI}oFnQ*dKnb{?Bra8k8YQ0Ks(7vHtvzEqjF>2Q3(In?U3
zXsDB$d=~au?EO2y_h?a?;9LmU3a;{nm#`P@0OtW3Ioy$7s$zWSGsk;z#?}{Zqq8%N
zbCB0{SQK8JOTCC02P?<JLl83H`NB>eWr$ai#sWY5eK`T&{dVBXgV#a0Sg<T=P_bb4
zg~96~cq~{R**Q<z_Lac0cgg4s!`3q7jUA};<r91#-Od+>r4N742(S3QRHAZ*z5ifX
zI`MkRu=K#bGIKF1Js5m?8GNM!mA(vveP!>j4oe@QePy{+qI~7RrD5r$Ctq1MJ#c<C
z`|E-A&?&z%g!@SID?j{U{e!l_D_fX(Y4AGm_lz)V?n@0SzuNiL!Rx{64TG1R{UCig
z64?#@8mS-n;qS`;c%Bje&B5y+oF6QU8k8SwdU^1A2<`{VBRl6#_k1m|?BUbA6}=8M
zCdLNNokp$<OCSE85nl0qg$XrYj(&YuI`MkRu=K#bvhiwEdNBC(x5hlf<13@TJuH2M
z_LUBb@6T6w&7bZT_?cMtXueS?<*Vf~(oW?^@oU4<S5JPl>^h?ROm!V)p(V~qHvLXu
z9fe6Adl`ws;16L$@=9O12bT3P`pV$-;O|v~R|T&JjsEW7_2BiE!OPAzaL@HfWH<OT
z$<))Xflf;B!ylP1Z1}yw>mi&kERQPK7dE^)cs&I7h2@c*^YS&nA6WMAX<{#<LwG8E
z`vvP{{f%Mi#NRuHr528vBY!X~op?QESbAXF7<nx!JsA923fI#J(nTR1s6^&3qkl9k
zorLz6Wm60LOY-KhbkdW*EWaN9B(NSj<wAbz7QKutVet3iBhEgwx61Q}@z)2h2Y>Gv
ziYj8?lzY+Q-x$0uyk0RJ`8hUhycLQ32Hz#QdKx`CDZ&qbWIi$Sr-Ro+IG<QHRVber
zd1LUp2<{WhCqL&^>%SRT{w^7hVW?P!ys870zWw8!a?H3Vc6-o0n-S~8-%G+1>RT-_
z9!p1WAC_Lc9y3f`u-}ZXib@v-A72K)=|H7#17W|3zj;_X3GFw_sTSoo)2oN2m!AA)
zS#`lV*z{Wi>!MSRWEch_&B6Te_v0&Kt&wACdd=YV;O`}2RNc2KR1TJY+u(KK^^D=j
z&pxqfZ6xv={5Mjc@WbD?A+S%3-aU9dg!74IQ-$)0(e;DZMR1>3KKVJny62sN<qw|@
z_EN<PPo;1F;QVUihGFT%-%Ez57L{Mc-#sk7cs*vAx?sPF-xHNC3_dOe?5Wb#MJXMq
zMCLc?dxxcy(0;R=YEgc(ZDd$_>B(=FRTp(x8{c-HpDvttm=_ky%~B2Lmno&P^0;=S
zG40$!<QzWcS3}JYpE`M%_&4^?9g#FozHd2cDraS~F_!h(#>nUz`o=8l$o<Pnvt8Dl
zJcC~T0MX^E!tkg|B9ph0nX&j}I-ju<6ZW`0mQTj>$;o(n+{O)<fkEASK2MM8G!kR+
z+(bG#nakTbJ3XGX)5&Dqwi3l+CYhMbk83o#g1R&gJ)qMVkB?8L;yExLPg{xHxDEbO
zX=^;5i{k~FcwVE?71X71;z19M#AGUwOi!k)v7%MT74nnGOfr*C(92Qd<B18KMmJEG
z#_R`m8c96AV@=vtvY5{23W<qK+ye4st}vFg6S-VbqtO-Ar7^Ner!g^J%#DNV$@JJ{
zJeiv)7AE5H$)atI<>T>uQJ14Ds7qt#cYA2q)<iy&Oczt*HXdckO{7xALSoXg3dQlf
zH8!TnG0_dwrBVBkP9rr2+{H<HW+<PSm;~xn+8$4j6^b_AFpBGPbOm*3On+FXF_}nN
z`QmsnWrI)-m@|1hkw~DI(y91FYEqM<E2v9jb=*sXp1R2;Kw;8O#uFJlnq=oEG8rp9
zPINsqx`4Vgu6k)C<GC?Bk26*nM|Z^S@riMeDW((g)MPO}p3!M^19fSf8`I@TC-JsZ
zYNC+OAc(+X;{~f2pNyyS@mwL5vGqRh3hL6hobb??OjtQPSHQDVxk;E+CYMau$&78K
zCQ^y<TwIeQ-3`>GaeCZC!%n9VJBpc1I-V)m6L{b%9!Jk73)YwgBhYDd19fQ}O6oMM
zTq2Vgv+c1&Jd?C0EObZ8P87xq<CDcAqNPToE2v9j(}afxp6Rkug$ar$lgY8<Sgtsh
zE+BeMrZSU-r0yS9H&B<xEf0-CdLo%mB@ore(<y5_ml)5CrL01#VA*hzgs!Wupe~J<
zQo0;=u9!-V=j==|U&z?7<4L<PF_|mmG84J@<b-a!T|r|pzBlo;Nut3SOTAfLnwrYv
z;*>g#;51~5oF?0-F4pt*v>3y?0?=82oXlk|r+dNA<8>zz3=@m(kTjml=rjtYYL>IE
ze05==TFDlyrlojq{V9fbgPi;0W~YMSVfx@vL&d+6?EgUGTm3zL_~aY%R>7*#MRkfl
zW8tAg>No-ii4K>}`>E-uc=t;M!|?8pi+KO4)cc0bz3?u3t_Rg~U;9bW4@O;%3*Q@|
z90t|(DMv?)B*ziCZvN1gE^^fB)x6zk;1yB|Fg^5yGpFF_rF(v{T3^70rAMrC3EqX<
zAG0~!=NbyXQ*V%Nw(?nx#h#IRe|GEO_3mHU2-CI8t@`M>CA%+5{a@KWc>Q}TC@WFt
z(Qv58msL9>(X%0*MH*lH@P{yRKUBuh86p(=;U`wz__FiS!RtMo$99rOWl+IFyB{i}
z>Z9jYk1wZZ2Cx6%-s`8R<u><dI3zuPR>twmy94VveClVkA0O8ZPsK<1;Smmw?O5#d
zvOhL{|FHVQ-=D*4a4=o6T%41iaK3qB|FHVS>+>tUFQVjDk5gA4k4pcB*e#Vh&^6w+
zIaimST@h@%aVmabSp5;&+dF75T%78F&^UA~7w3AMI{oCZ`lTn&@1VND^hK21lK!8R
z^||W@{q*0V)QJb@nsvYJw{E@pxsUaRo5PwPdj78Szx44AGz`5aW|4w`-$$4K>1=Pf
znLj`D{GIscdim-@el(nXvq@~`7K=r@J~h?$llw0DISo%9Pg3E2_8ML2UTxqFK<9^P
zyn2Wl_1vOWFUbG6YY#guosWQP56^U2oq(LY_He5w{H!TFU+7PQfs`(v&*?Jg6-a$`
zKw7{vZNI6thnaj3JWQT=G%r5<s`RnfeDV3rDZ-VCz(}O{V$6Tc_R~iQdVX$41^h7l
z`{RrKrquuXVvqdGt~Cyd=E%p!&`FAZuqs)SbJ5CTP+tVHbi}IG<YwpnWQlGa4Mr6m
zGQ=}pPdrqLig$yqM2Hfm)GP1)$iO?V$(29R3-A4yt&jHmL8-~{?BNLIFlf%>2&SIs
zB1cD*kb~Fc&X&8#5v&^Omyj95Scu5&hu=wn+09lyuc}5eUm3jK{pVES27NtBEQ9K!
zXBT$QYjWw@;PvmFN3BSmN5i5PUv7Rf5<MHjnHZ>|iZ6cn!^9UqT!Y|M#g~hX!RtMo
z!}_Uf*;OAsyIOoXxj1<J2Y23~={y=1p=Vx`+jcatp1WjBh7^O7uwFbjJQY8K507zh
ze5*CN(PP8v4}W(KufPFy$#Ss{KjAgGwLdhhe(}2eitmdk+129I^{1oKzae%@r4DpW
zu6@qcrE6CN-zrYM^vtmOBeb)3P+-V7)d8b%=vXe+wK#R*_^|q=C&%xgxdHV>l<Y$P
zT%UXTQ-1pQ@BDBxS=8sEMybhh`maVShoQs81XR>O!pY%}5^{W9t{+@@ws$$Y1mX^f
zZWn3#L9EGi<*!99lR=j}DE22)N5qinOR}F{|FoY>UPle>D^Z})`Tgtt^J~zJ>l4BG
z^+yAKdClYX6T$fH$3zj4yj=H#OyfQFnMimy=*eT_J@MWV8F=SC0&9NQk9Vhv@7W_D
z*HE?JVw<IZJg4Cav`63>u~$H?i%*|)`M`7PpIo%F^R`vPMgz}bA#5|S>lLe<E!J&2
zTdS5!`D1i8u4dP*X0`s2*i-DU8orhr8ftbPJ4~_*rDkc)qQ~aT)#~BJTDEEB%C^s?
z4uH!x>sF<KMmS?svr6?%V+lI9%A|krW3dlO+Sh)>mBpd$EbO|#-%ZbV#vYb;6dd?0
z!3Vy0z(q6qfWooqM|B)sFBUN3c*%pK>%{>^9A{4He2jOy7{G`l{x@|TT@U^naa{J`
z=z6f<h~w<%bUwNs+&AK={g{rU>%n{@j@74i99<9I8*!X#!O`Vly%9(H$31*>J2-E|
zam9n9>%n*<j`N?_`RID^-H2oQCp<X19c(w^xaz^t_29Y@NBNA-N7sYtMjWetQpeHt
z;JFdUSr3k`2g^M;en-Z=+D{Q5rc;`7fqNMi5hGt~whEtEY&0?WER~vw(Z4HYd-bOW
zFI%{2havr!SsP`_E#j$p$ibf(ynNn-CS2xhl8No{@)shJ$&gA3g&IpJA?(o)zf)*v
z=`gm(>2rgZEu1~}B%ZRz7k+l|@&&iY-emfH8AC>XF0f4DXC}Q^Wq2w^+x!D5=ehI4
zlGEQpBNkPS3mboaSh9MpHEQ|TX3zfZsN^&FjAVMC>l!Wblx_B&Ul^90p>4K<LXGaJ
zZ1&tQ4olXaY_@0lJ|pALh6{f3`Rh7d_Cfj75v!6%aiE&5*h@`R1{w{T+cPh(N6d>s
zDKfkB=jF3fFIWD*-u2Q?T=C<G`FZ|Jk@I6v4+j}1Q#AF~Gg3dN{*E6%Ub~IjR+#>w
z=liE`P(WAv_>`1C{!78=FNaMq539Z$2@eJ}bhm?))WbE6ht9Q3oQ29CRyEM2zw7ee
zr5#SVp`z%NKvmsv^$Tu$Z_P4auhz0p+4ZVT!R2Ae=S>a1Gd)3QYN}9bP>qw~(`Jd|
z*<W^P2Et)i1PY#qZ1{@X-plj1(44<msuY~?4M%SZ{jhv5{k_4<7xgGbk*`%mUVm)<
z{lUu@MKm?Z#C^8mS0a(g5JN;L?PZ45X{hkS?<8-n9R{Ce`Chs>c=^KFWN#uWoBY+m
z%NN`xdy|Rh7aJ}GmMQ%3+KXj|r{Zg$EbEnD8<wp8RvNXq?29M=(XeFoT5QzvabHgV
zMpW_{{6;c8(D}b1uClDJe|1>0hPK-dN;SJF+wJq0hb3!IcH6UjoWmdbO+Wcip~rk3
zm)MsUu#cct#g+msr{4Qd^>zX8Dwwkgh04oc?Fk1v0j^B|8s0<j^vf<EZFxBWv1uW1
zA(j8M%;RJK%!T*n;r_PODLL_9MG}0X&QZ4(Y`WCAd8~$vnfZ8Sh4As>*H(r;PXF_j
z!AI@N%HU(>U#tv1M!&u?_*nHXR|X%~Bj&>pxK$mB!k1tCxOg>MeT3!X%x|p>KAOM1
zGWgj0uT};ho35=4K34zhmBGiWL*|2P`ImmDcYX9TXEA3XI5#Tuq4WP{W$|<3m6gR$
z`QNTAe)j(E%Hk*a?^YH+8?LV`e%@GN{9OO{k?Y5hI`CYLs?Vk@#*IHO{ocyr=ehr|
zviLdq>dNA$_8(UkKeNBTviM2=r<KLeJvUYcKflfOm;da?&$rMz=)Bd)7R%NgYFWI8
zHvI>Kmn-Uu6-8@JwAj~VpEdt*@UnTUpW!NSt@5x9o_{S8c?{#8n7a3}y3|Q9Km1O?
zTI(pb!B_sv;N=QugMmd;Hn`!B2QOQ28w@Vb?@6E9c{8v);irGSSYmi8ZT84}Vo(0p
zVae!kl@W@mV*k}Y8J3)03yo4Xw$rt*M<tuVM<l}oUDwp&Cfn)ke;<~Nq3yJTGTYoy
z+3DGD3`@?Q?6fD@z9{4Awg2HKo4<}b4ZfY$^-2vahdL*mX=PNc@L{uJt!Cq|w9z?V
z#UbcM)5fYP^Z4waM$4l?Q6d4Myr)+le^Kf&{=a+Yv7flpJEyT2^LqWyBInhhQVvpK
zv>J;gq+U<meusAE(^)THu$D>-iwoICX|96f^>~|eQS7PYHXH6Rv?*1LZFs-JIZqq?
z{{3&E`BlZL*Q-afmBn&dKD`{{@#xYjT_=N)&*<!ZKA&n3F~;+g>u(yojNS+xE;5pb
znB-#HeErRl$Yt<R5%zk?b~_2^hu;}k4Fa-lu3tTP`NG*|&mt<@Oul9CG6uKJ-sR#w
zZ9Cr@Sg!EHT`v|Io{F!X{*fGun%_1oS^ceb8N^j%#<?}alGkgw%ONA%@1?t<lF{Hp
zlJSAg(+qKz?f12}4NKP0_S-?JzV52*cf;CY$=j3thLZ7q8I#iMbQzue7&EH|cA%E#
zaKi}0J>Lb6{bBlU9p7N`#1MB{_)jw_nQ|0>jkmbQtGbYt_;E=VRE@O<_J>PvAH1yo
zp3o_^>PuYZ4?Ev6czL~^uzWJI{l4_hNMtnl<N$N!fcCp{!{B8NXTN^xbYgfHah3gE
zdDr0O4Q{{v$@mQ!&u6|fu#Dl;qCw`<T{`zqrQEOFGc39NEjqk{gV{BYL$!N{CA-(U
zms?)8@mt>&mAnR@8%E9@(8f=^cUW?Vw($-M?#;&UdEc;P@5#pdmX~Xh=QjqHH%wC0
zO9T&tUv_T2nzx<%W>~Hb9~it`{?^;SXum1PpHmMEUM{a?_Ad+f(HkF(L>7ZD5RW}o
zGdc<7hu_!sY9AWBT;Xglm}qQ!H{yerE4b|ilZ9*fv*Uqf37>BC68*wcX|qF?@#@5|
zWc0VjsKn$Lav(h{8NHSnm0a9+SEizp%itH1*`6X~7Xdp^@wLyr9~qX6q3tuUm~5X{
zzjs(N_GF)d<$9Fo{}1bO1-u`iZa45afsHkPal6!RiR+D?aIx`DO|_s?Z#g`_H3V-B
z>j*QZWZc#Z9+xi-m0DN5;lcGSTCZ;4z;esJ_>mpDjs_!_zxQ@Z<2u)-HPO_b<b#h4
zUN*1SMk5c$qLVu#k;f1#2AFSa9mV_NU)nWzxx(3?pX!_;QWH(tVC?$_FI#XM3@#7n
zHSw9i@^r~K4F1d^c#wIw)@i)oxcS(yWc0Vn@XBnrP4>HsyN4yG*FvL|jqUW-o~UFq
z_{cKYX$LB89msY%{r$s|F|?ibBBt6G|LneD$=Q>g_9WY<WbS-vzn^UWIu4grOieZB
ztBd7=+@^s23CzRk*=Tt%C_*F{v}K}|hfhmA%s<{c5B<cAR!*3YZBInbhd~`2K-x8O
zMCxPYqkepNZ89obV7fOVplcA=xBs7#@;-kcn7mQ;InzG=1Ch`+i0$9cpO<p)ebSHi
zviX1GaH*E9RO@tYAdCt3cgy#zAV7@yn*PCP`7$V{)h0Uf^#!S~(SyD76^YGs<SrIt
z{x*Cpa{dgeGuTxZ{yro1xBBCL{6!j9I&#Cj+=ze|gK~PZtItWjT+Rm5%OGrtdAe{Y
z5}phy>fL^rr&E?6Ps<yx=ypySt(=2W$X}SJW-eNu3<@*al!+&fp9k{2^Aw$JwR6UN
zZ7W31mqA^A_SMc8=Us8zkFV(CQacy!y|1f_{qtc^NMQTn*myl4AIoVo%*&;@U^?l-
zi$N{H?SyL<=jQ!*`4&1q>117bi+0afo9aD;E2Y897IoAXGa8XpD)H1?h_S<imoJLw
zVUmgMabr0WnGC)mLPjr@P-<X=cMc?ErGr=ntA_ior)5Yo2*>9^XBP%9TR404Q=crI
z`Pk#LmBGsw+#Y+AiEDz-RRhb^C0wtR`n<RE{y^sIuhxbor@w`USE$)e*$+qR!;;l&
ztx?OzHoLbGm3#)D;S|Fd8GTNKbrG}!6=O%T&7N!yOU}?X+pDN5m$|$+ELnT9+0gRc
zIucmEPUEs6$VNKu`{8f1Q@Jff_21~y;N|nT(l9DCi}-apejGeDc=^1R8J$c#PCWZm
zBr+L%B2t_5!*A{|)OlFG7k+5)@`ba>-b7@Zyz%tl<qK|;y~)I5-r8pZ%hYAmHH5Nd
z7~4Bg@wHEub>=S*OICj?4X;$Qxa^B3j}J>$uf;|!ANS>@zY>*v2ESPbyX`>5+>wZ@
zEbAMe8kVe~?Y3ue*>0zw9hR&;*==a~YJV-Td|?uhUS?5Y@VD8jvrZjTXY;Rqdhqi3
zTWO>ss=emZCk8L0*E*w>i+%6R--tvmgKrSOJ)MT>B%mMuuD1EcX9h1{INR)5L}i<W
zlY^HrxNY_>7mtCLek8D5;Zu%YqGxz2zIMv@K*WD^ShD(C>oSO|#*Fi)h9$4pa+gC!
zw%;|Mi%Ld=4@t&*im+XT?Leig{XYF;!;&?${e}@&+3(HM!;-fr`wb-{uK^tRd|(+n
zjopUnd!)I6AATR3#Vz9t3)PA?*E;nRgO}6aYQw0qtEj48_wt#+%j&h*<&lqV_Kly6
zL_UMxL~65s_`7x_k1ffc9=x34Y&Nv0%4Tb42QO=In+-4DpU8EOb3YSUzAhuUArvk{
zp3s3xSNr`2?-lsMuw?eP;_%AtDz>WYZ8|qBxxE&>oU*cA&;M*xvKoAB8SJ_Pm98Dk
zc75TC!;(3)UH2olvg_A>Zdh{nWY>Mk$~i{-{|PK>m}IAyibNRvezx2sWJrr+EawY9
zKX^I)tvGs7dB5oNbAy-DYqinK#(ntWFGM1n!EcD?o~jR>g!IE7*jA_i-@(fn&Q`;T
z%C`E_g~7`i+*ZTM#&;G?-xiB~e=M8L*PB^f;BMC|I1O2>+c*qaEtm4grlzVjyKdpS
zqtOSZ9k51|uE)V<YRX9qR?`}JaC40FkB7b#SXbfGp<beOcq(1};OAvteN)rnVx{!S
zMLRo>C)TpHX5C+9QU;UGaXj47bR@`PG3N8u?QUO3f_iG|nJ5`$8#?=UhGj$k(Pg>J
zC?{>`^*bW(n}Xf6^7C45@y7GR(yKR`Ew?T&t%_Wib-Qfim{Lr=@6mjdL&I_cXQ^4T
z%B831XeNRqbk4TC_sdb~+z{ubB74dRx+uQ`m9FvdUTMn*-mL4Un#&d!D|t;P7yj<B
zbQ0RXL#yR}sgujPP7r)6Ef({jge%`EbT@|^>f{KUTPzmsI)-C0R5UbyUh~Vt(qm8l
z99nn0U*gbL0?XMc-!+ubBF(4$@VEI55~@7CxB70`=S!<apO>ro!`Wh~EZ)}SZ?~Lp
zixurF-|ckz?+sor{vH%Y^}ec!-5tAY-Oqg>7CQxdzay3{RdX@5_u}%4gO}TD@zKi4
zc7F5kM<SQO-y*ehKm5L($@aSOR|YR%ID73`L}i-?E)HJC;I`SjT)g&m{2vCEt4oGq
z2$Rc@$8@0LYp1*~=+dtaOICkt4X;#Ran-(x*rj2~>$TkFkdf^-`D;<hXz-zBu-^_;
zd^?owxB2VCk~Osbh7niU?+gEESn~E{zkSJg<E6kdhDlC(si=j)-)^&YJ6~#)#GW9o
zo8R-*!OQ4xv5||Z?(v-c$Ag#CYpK!8#yQ^c%aO=t@D<{@r%FdBA^q?NveOs-$>3!S
zXQ!dWRCfB>Zw_A0;C32LHXb84yc}4z@M%deQ8hf3jyB76$OHduSn~Q??lOt2*3!>@
zZCEmUt$4ZQWLv)a&!dvl;8T+Mo+57-fjdwMWXtRS#jxZJZOdUrR<?ZL>%)?{CtD6J
zC)dDE{mZ~|b{gLe)Bi~G2S5C6_S?Xs5K5S8U+o*eHF){_tu~Ab%_4rC*DtOOUOumd
zMkf>7<dxrvL?(l8L~4_M_{|-r+2r)U9lU(uY_c~I*(NXiyTQvB+$MXI>0Ydh9HoFV
zcYEx1?As|<=dwGnbLU9*lSixdg4!Fp_V)tI+-0;jgt}$O2|7^mwO_97op^Ovvie(b
zc%_=f<yf@pKMhM(uSG{KANOVRKSw2>!LOFVZaYvhcO+bwWqs`rhb3!hyX{$Aw%hqX
z8kVd**==a~uH6hQUzh}?mr6ny{B5>McZ1U~!~J*WzYShKe=ChnM9vWoeq-?Rc`Y+K
znYho^|IbKdGWZ1X+EYcKlW>0cyV~T{|225|!r5eRBC<`M`R3r|3vQFW$;4yc-rH8i
z9+mseosHzqb==rzzSyiSHu(*nYJEC<iqT873{S<^K3Ue$Rl}0i-%6tv_x{+O>we|l
z81`#DTFvdreZtN+ci{BEQ}(WkbE&Yi#1~6QxVO7-+n1VlrC=Af<nz_VN)z_f(uU*M
zsym0JN3S<Tt-JfAPS(3R`KWc+tGNdy%sX6|hpqhKxjIx<Xwetz_?<57{`|aMSS&-g
z`>e|0hf7w&r_Fb`ZDvagcKwM`y}3wRnyn^!(A$W4+Tga?dMsbIsp0Nwvs5hQMJvi5
z?v?z%OM}H$>iYI0v;#60V_ffczwe@BDA@99SMp|Ee5VV$m2mB~t;4Xs$Lxh_{n+CT
zyP)B{$A#tZ)|?lu%Ezz1B`P~J#71d6J&l@O46Xwe-`K?c@g7$%`!Sf?g{`=uqtsOW
zb+7w<Yqip}N)@}l3yS6b`Y!kTuIfHKo<>mhYFW1wjt%d3VfUBH)qT}!b6W}P|2R~1
zjBMmX(njvr;OzPlyH3y#Ta8j)$LjL%0TVp>zwSu14M&r(U*CyOqbAs0Y8SSW>j4wo
zzQqc5Y|rhdEBL`L$M*|shGj3I<9p90!!hbXS1-G&Tbj*!DYr<GLGQm0x-gEf?X~Jn
z>~n98AKWLKTzF+;vp8t6U^nZ>U~EkLyInZ4i2cVJO?!c?2*erJhg_KLFx9zZvvq_?
zx6^nmIq~ho>a(84lAimCWB-T$4|VSYCRdf+2R=Xq%~;H+8O+F7W_m!w2u6eJ|DU!j
zt5LU*n5NZHH%K$1nbNCzuhbQ)tBS5_sf7uVXBCXc*uf6=Ft*}g2Pb?ncJz5!FP@N?
zB#J{eWJ9v7m)-Dr*{s$dN%VP1J~qpjCA<4O_ug~weO2$(t16Yc$JjGW*E{$8yXT&J
z@44rmYxJ<Rj2n91;T5Etx0{U+KhC<d=I*0DhR<o=OWGrj;jFov;Zk96)_lfr=`c8J
zPGh)C7@ReqF<jP$<Gww9%fNlxZ$A<eiX7{HCklU$&puQ0I&^=F^>5A5tcRSf2hPEH
z`ZF7^hiH#9imD@3q4TU?yLIDb436OO%EdN(`3J`$SBU=@s|`otkL)<M&09aa@$!vk
zn?sAJ$Eme0=5d<0$LSxbv(iI5HeMHl+wkb}TWfumzhKMH>!;Qa4J?1mN;t%&UW4^^
zA1aY{&%WE*->^=KwoW*g=jGcsODEBzWOU_6sztB2t-T!UC7G}lgZYp59M)b=!v+>A
zfMq{(<%c&*kHHakEp=z@;j}&i3o=W0)_zXI1{P(2<#9RrBjeIth!432<FXHxNCRY>
zvi7lBFM&lU^m3c>*O&3X|Grc8aXHs-oHll8?Qb=XzycNRczmC@W3zNS^7tM_y?V@A
zdwQ*#z@inp;l8l;^BOiVaayp}eqO@{CK(IX+S6;;fb#_``;7~q+pPW>%5Pj%pICc&
z)<>$_=RT=y{;kO<eMGz&H`=mzY6{|aeAJ0WBpBVHZNiEvXkNR0KJ)s_=f}uvh=#=q
z+IlCnn^!BIp?Qt+$5u>3!*=^)9v4<@L&J9aD2BE6{~EU27k!J@pLY(audA8Nx_X#m
zet!?=1~)n~oU^dntoZHrfx6pn>j3gY?s{!yZH4XO4*-9i(~^)SoE@kdMJ0c|rVow)
ze4n#z;-74HoY(KByW<@Z20@}!1(l5iB>qRejOY;8rC@z*y=%Ps2r(g^{d%nEcIe|D
zL%z>B3vCXs`H-Jvr<m<O$2SMx4j`t}LHt^jk64reNoxBq)%STHanqT#7HT(%VCAan
z>o+203;LaL3}51x__+c6LWISRcgSscbziWH0v7cBkMR8y_>O+>AQJ3*i?vgT+X;#3
z`yZ?J`uh?R5|lnzrYCkq_1EAsh4fMAFee@VAK>XGDHEO397RQ#W&`p(u5_IE!eIQ2
zaTsaZ?~jLeh&m!o)_F?F{leW*a$l1<qO<BY+9Ir6>bPZ;%b?ijzeV3T&f;w8*kWmV
zVc~db@$dul(@PH@oh=<Xdia6E^QHMCOQlDq=MK+IFU`(q-j}~PM&3iT*JVsSypta!
z-mmM+`@{2JnLl!D9uhMA^?l)?fyJdGM`sQE4SnH{9iE>#a%>U!f1Yi5_mFxShf()v
z$I*Ser7!=p^GmZw7mglYgv5@MgHEpq{~_m=gK(K^t8_wDt({s!F*}?{EW+vFU*uH|
z@H|dq`~zV}Upa7Oe(CW1!?UG_=Seq4FCULtFCiw=JK#d}!n|&A46k$3i%TRwuZP~a
zC#nwz_m3elk2sS?U7MRG{v-4V8$H`zsN*ciIB(|d{JmGtTZryrd1Ifo|4W0>zeZ+_
zJ>|_4cVdll5%qm2k9)mUa;fk5_YZzR|NglByK}Spy%U7r{we*tfM+?k>=}!kA*vq8
zOr86A{SnEBd>TR&lH4o0Z)!?Z#ijaJAPeCcN9W5?vc%&!sQB1=-yk?xwjNd-#`D5e
z;z=of7Jf8}pH5R0<UEDiU+NMO*CTy75!I$Ahl&&$nhm9ji>U^#=eCe^A@v^$Kh~L?
zR=<>BTB@L?Ug<d5H_P@;a^q!-j*N_=J{fYd#ryBs_R<?K+c-RZcXx4L?a7Qqo)F(6
z{J^;EFbaQfM_G1wJiGC-jb?{~i%0nsA7NhJ;$TXi@jbCc^n$xhw$-O|8!!LhwmP`X
zf1<|T%lU!j8GXth#$rdO5^A?B=jFm?$r)|E;}n&B&*ao*$r-fLamvPhxbS1+k}YJM
zD26vQ57C|s;bU3Or}u7_oFm(6ABFY~OY*n>h5apZ9Vy8T8_-(k>>>s3L^O--`O=SX
zmM(^}=b_|h**@Giuxz6&xQ6k%qu}rE*ss~^)ye6Nmo3_Q$0HuE0hSJIylg>h9FII~
zhppMM$P+RKh|i%sYCplE@Q2zV<(K?_B4#C?a1iGk*vYNbkno8&9OPLE43^=pa}3<7
zkFZ#ygpDShi1^|i8uD4!eU2>Lz*X1k^%C;?-NssrzA%i9>#?;O4pa;f#qbFaVjEN;
zUGUWaA;!Xea^ZoE?~~ES&*0rc@#q^M`=_0-$m7Clt+|Rh;P47AA{@bK&1%i_9UgOU
z9o~3-3_j)t*8$J*SH3c^JfknAhM56IrxH2-ZbV;S=R9)sU}@>-;pqovOB6kxJ-$?$
znLRlD@SKRrvOW^?o28Fvs~@LI$j{saef;lyuG?(Zzvi!^czy787mxoZ7B)*CL8~99
z4nE~<o%jb6IIUfH<j7&19dO@YJUT8}L&l*JV5nIrM(93NLdOEj`Qg%L$vLu(4<+g+
z(Z4Oc=df_#kd9mKKekyi4`s(g$;o51^VNZ6>$k3nI!YSGdyj&@+g8On3(NM(*EU|Z
zXe%9$c)XVQ=<6FVThJQEBhM`uZ<93M?mu#5Zg!fE!S%RHd}Ay!hKvj1eJF3*PuM8@
zeQmS#&5f6BG}|0pJenKtLjOH{cz!9DaUA;lG3wi6aHjZ&{(j~b@~w+YNAWk?@++l{
z*TvwrJe>S%Brho-oziQAD<=n*FJ{&bakJN8ZP15Gs7+J9(&q8NfkV^Ouk`nw`1jnA
z2M!;Yp3{0Lls8Kc(Uw2D!h2Q0^Ul+i&5|={)#H?n*MDz%<B~08TwMcO?n9-w17Wi)
z=Z@-T$vLvE4khaC7^7m|MOq!D(;c3Fpfor8$m|?+z;?WRYO{1OlpPNxH?225Lq2-$
z$ovEJA4}esmj{-&-+Ca#eU5d#5rx0op6OY>z#L4@nfvyg+Q!QoZP}x!vsYYRPi%d3
z<7Eq4?0DoMTg7t8nO|C5Lb@xZa3a5Y>%={X!35uCU1_2ajHu~GZSE3l5HfCBg-II_
zWBp+{LI1ouH?QMu+aFVys%{&R+(xB|qCKSsg2H&<w$w2%1n)iFta+25>iL!WZt=&x
zd)APvi_C6svfgZ*+9Q9wXWyjwAG;Ooz4!EmCjP$Xd=U{9tQYWxE%Vd%mrJMC+*M+S
zBG`gHQj4q?i}%*um9poSyh6hF{YtJ{t)`RNa@EgPlF4i;ovNl&nS`I-w}&Bfex{r#
zRx*V|DpgLUvx#gWnaCu)Y&BO-R5F!)lXq)ad@lIud_J4a7Ar-sj5hgnE?r0!GG5lt
zWcN+(BcA_I@s4Mt!TU+sEq@l6|Kilt$t3=(T5Ie|7{9QmK9;c);*-bf1EcWwItBF6
zyy~OfH%j{w@4AXN7jbn#TG!wff?j7IdVFQ$bv2p~9b8?HDBo}%K7_}j@C_LE@D2P_
zsdNVej&T|&?3<r%Y`o3}_szrWX*b?<4d_Yw(2@1T`LJ(Vc<I4dI_)dDp0|pNR6WYq
zei+Zl-m_1yVP9?ztn1OY3d2PBMyC=wu6eC~xwTnxMvumEipu_Ga&@!h43402%Eo=T
z&>oj;A!ArEJXFLlM#w%?LT$CI=Ad)96YygWPdBlPjH#)CK^=!_%zeV95xeLyG-5%`
z{`l$6X7$&|V{WJ}V_nuiY3nj}scCc>3+gykHP;q!AB5)+JRknpnqOKLmnuu0y>dah
zEEo7CTo$Tz+E@n5p9caq>y=Auo7HDS`H!LciFN2~8(N1?4x_~T)%bl)&>478+8Y*K
zZ~Md31NXxy8_8j2<WcbV__va{(?fT8<UVc*_n3^2i*+gi9UWCT61ek({S+&DC?sZU
zQ}58;=HIAs_U!t`>pj|AjaBtp_d7pr>ps>A1$2M6($gyfN2w(CNo^Eutf(X}+B0D-
z&o!<Rk8iv_gPvr(I%N5GY&X8dii_}?9{G0C&Yu@>$i<@)1^#-)Z_%~WQngk`mLBxP
zYx$jsZVc()EA?hu#B=^w^~t559E+|)d@Jd2sFhJarAOh9^cnXm`7T;I3eI*@Q>={J
zmEQLwDE4EHx)(^whpxF#PJV{Ii5_VpfYp;N$-dy^U)*?oj^+!7R;ja3>GalHhqgOx
zH67G&|AL6ey*N^P-ldkBRm)d6e`(|OJ-DwJUdK75qy0Z<blh#Xv~S1jO{lc(mGIwd
zG@$QLHvEccS8JD6+y-(*y^`B%;WKLEs5$gD!rNYMuGM9TD#Vt#rq^@l2G(uNt|sJY
z;Tr6n`cR4V6L%`TToHOf4PlfMTJ0(hbBpSe*FP)zWR^U`pQ_(Zd~36G6g}!k?~F(_
zIa5mB#13hfVh*qATG*xNiaDkh+9lbxBGe0;WS_bF{ATGeIFhf0-nb6jjvo?wtEg!O
zZy!isSeL(xpLx!DSN?`UT+ySG766!;T6NTsqw&mR^!>j)F5QLrs%tPt`%sBAKDND?
z+l3BS{Zlnm^TsS3tkUF{)RKwLb*NSo>529HwrDH0f4kEC{vRfM@)iR3%iXB4@b588
z?MHC=dgo}TKHphzJIjkcDq_1RKEJ364Dk5B_|u!E|B=W4C|!X0L+a%?>t&|d4k)J0
znxXnD5_X+or)l9zmrJ@EnKpN${uZ4{zIHd&fQq(z_8Cw7%x39*D4#Kst~oBd_h$!|
zvESM`WLg~S+B^z>_jtxj5GH1{{LIG77CmA{QD3ikd=~Zm&uzSHL8}~(JZy)r{rp(u
z2^kAxwZka<y&YxQ;roAO<7FGo4hI*H?Qq90Y`koP+u`8y{E3>c_x|F*@{GQe8z#y*
zI+akHWH~#3b+hD*w#;#g%6{eIbDJe+&`QTC8~5RRzcen{LdJ<=c&O-FjF5e(^tII;
z-`OlVN4C|WL}goDdVaIy9LiQllI{F=2bOJ=g~c!)brk&F_Svx4nY({=<7JDs%<+iF
z^ZQ#DHeR-%HI7Ff9%J=i8;d+4V}SS^%3JmmEDC>LJKX-l#>+OE9S$xY+u^IfzVWgR
zZij=*!*lo2-xye)m{~PsYkUpn?mkpPZIb2O@|&9_XS8LGuFzgl*{{6%H#bYppp}kO
zHtxfdFO5sKka2PiY_$)S-VVe>&T?-5+nXil$hJC^sBEj3ervPj9LiQllCA#R1IyNL
z{ta<=W1Zil@ORs1(_Uvj|2rEmTeM}4qP|}7cz%E5?`*tmL2De3JUqs(TpWu$A!A^y
zb{K`fx1+3h=8oUpc-cm?!@<R4J3RDXZ@g@S+u`8y@SIkEWng(mUpfr4`yQQ2s7<n*
zFa9^1C1<o{j#E_jEARc@X2}_}(s9bheYpMAamf}kP87pK?a*U{>_ermtseUQ&60Cu
zTOCSNw$=0B+blVUvel7fd*$yAEZZmxi(x$KDEPbWQ{?Y)zrFX`#>*CMnd1?U=lAV@
zf8%8fTH|=+;l9fJ!C2%883V-UP~NhiU{Uz{+TqF9H(s{U>~L`L*bbll2OBTj;C48;
zJUn;5@(%}=CuUX+*&1Jixw{XQP@7~qul%FUk~7*eM^|XCsO(pE|KrV)Giasbl#ToF
z_#ci-wvcgh4Q#a!mEI1t;+fC>lg*NIWLq6dRJPSO-`FfUhqBd?Wc&D^4lG;0`8UMf
zjdgyH!ryJ5c$L)TXCC@z8!ub5Wsai0Uh#N-fBwylmn~?G<B^BQ*t`FHEb@emfw9_Q
z6#m|hvg~m8zu0)$Mzh1g#bY~Me{17q8{7^Dmxt%>*Z$?e@{GQ87-si9I+akHWI1pB
zA2v(QXv-X@sO(o-Z*P{IK`R}nY}|*h|BvI6Eo7W1hKJgr#|YVnN?%*u@jq>roFm)n
zP@=M}cHY@6Ift^<p=A3{D)0T$|2(j4qbw|j@u;KV@3BvDk#P-A4K>`=)#e%XXm6?R
zH%@hyG57yxCHKs~-gvpAt#(61*Y}Fwcz5Gv4_flZ$jdgq|BuHaZ^-x}IfnAY{REG~
zKeCO#{=aU#+@sm}*hELI0(tj&KkCH(4b+Ks+m%|abf(g-RaWS*<4<|~|8E<wo59Dx
z`1Eo8by6R%{hNX1jae;(Z27Ojnxqevp~u7Bs?YbLRxfO#(>zmep1~b&Q6~rGC+Yrh
z9k%i3l&)U7yji-69zCOX%Fyb<dwSAl-ssYor7DMO4=kXDFm$R17|*ZI|H)?QFgVIK
zQg62_y=Au8Iw_H9IXn)Zcz;}a3GorvU>x?LGPGgw_*(vVo27%1$JaR3px2<suWXhc
zh8iPdm7Qyk@5TJQr0Tf$lpfc$flH`G)X8PSYpA=aY@t|97Ax6gw&GS2>55y;dF5gy
zT}WrMe$muWPvwgFj9<<slhu48S;-|5)k>x6rrcuQE%?c@T|?dViWMJa*bAv#(objn
zf}26%^<t%x&U#h9;Hetw|4P;Nc^y7-DYAz8_qiaZ=%A>l{)mzZPydL%F*V2AomHBU
zdrFVTE0*eLb6wK6QOkVE)RB$r6jPTpmW-kCF=~Jt8nGr~XvBgV8gHP^wM8S&U@RJO
zpr#(>bEvs%Xv8WYP!o}BTF#)RuE7y2U?`4vgE-;@2;fMm`LKg}w0f*}yjqiX<*=uz
zsb#kfqdHqEuT`t^z2Ey(n~!4Kh*E8+2P4-i&!8S{G>vlYltqJUA#F!p)bKWKR6(oO
z-BWG7pLkKiR?pz6T%Wv>S~PNuXz!m6?92P@0YjF(W8Gs$;qRWy*J#bcd#Nj^jS4*}
z*&9t&QWNzH)jAP%PrJWcD$;KcEdQSyucPQ0f0S<MRTH1LJpaMQ%NCr)$0HA~>t8{g
zswGEuIoSf+`D_1SEOLgdDaLB&QTTg1(30)_|G4q8jb@*Ni^ul4<HL=YZE*V>Tpm7S
z+53MDEYIj$z+s}-qf-gBNtUzopEgU*Xv-X@sO(oR{@<G=XV6N=DI53UdmoKUwvch6
z7#=DL9V28PDt&Er$A8`|IY+kDp+sd{UHX4EOU|KebtKu&e>|{kqbxXv@u;KV@3zl%
zd+l=Zzihm0(Uv(L@pyiJ@BiI+*@D(M9(j0-ZE<cyO>gxyo!B!r*E+2=dfiX_TRbj>
zccq%Ed;1X%83P19l(!rOe_uOHT(|MEjb?{Y>gyGc?eOIF8!y}7b~v~^Ja?bJVPJV;
zX4R0b_cfTi`%vlaG&o0=^R+FTC1<o{j;_#NQQ5D2bmL~p8MM-I%Eo=T`=)Wp7BWt*
zfvxtT(%XTSt)ASvS#pkSt3!#(wtC?cn<eK^wmOt-_p6xUo1e60TkSO0@n#BVYtfAB
zR;UbnyScVn@x>I6L!h;Wc<bY!!tvq{41<FWSfkNz0-f7t<DvNUNNbG{*E`m=MihQI
zR&dm$g4QNhck{-}6+J@wEu#h&O~1+d(Wf?Ew&183k34^*Y<c(gvB(oL7RPFXQTQWm
z(3{wJxkj_Wfko3c_`)q4FWcZYIJi9g?!jB18CagtmoLLa07j?MV~@N>+VO*%C1bQz
zj!{hQ`%m7sS#ky~beyuWonH9txMT|%BZ}dnA_Or)_MsAKr<ZqZmW(6Y=`dnyJKb~p
zX305}oem}2Q)*6M{^2OuqIEplssd};mWMZR@Q$O8x7W_pJi6?_e7wAKynKWxLo6~T
zX^9@f$ImN$eDEW~^AR(&LKcoZfTOr^9Oh^5=f=)Yh-%{bd0gq|>B%U5g0?zN8)4c@
zpTBzAA;R~yi*G5pC+{4L_O-AD=HbKf@DQSc`2Ob{rZ?^~dO$+sGG170b-dDYvyHH~
z8d%7^aqD=cEvIxhw`<Tgr8ctOwNLoKYS#|L*RPpxYOVT}S{ske(U}bUro!EZ|8ejU
z(gEEz7~tdEN{{EhI6NO?u}6y==H<=ZW9KDAEg^Pk@xp##$GuU!jMXPulpTj@UmgSP
z5W)M}!;{J$E`Dh+xyNk-O#j@TvCt0@zkk2qt>j<$ayNa>*%WWXItLZpn*q21<9GrE
zmMicB4=Oy*-)GZ{!^1L6O<AZkPs=}Q<Fey<DvwzmA-bO1LXeT8iy9U4G?y3-PZ(FM
zr$n+3u8>|5Mrw)2Jl&ca4o?_QzpQlrQ6#SM&jGAlkwf0bW0!uZg&^+=o*Z2*Vd?6^
z7MQOmGEp*)##fYjX@xilU%#UC<>ZFvOX)u}>Je^@++%}r$Gkn0A3JX$Y8#HX-%)zo
zQ5>E(vi~8JrhR&#Kh>HEGZnT*Zl_en>#mK4kgHm%Hdj~h8?_W?4UWV7zA!ajenS*F
z7Jh$E>38?u;rSh-T@I;b$6>x-{qeE$9ir+;n;n|(-%$EK^b=8hk7rGEH8#vV?%jX&
zJccN9EOz_1l^zq*gYmeTw#vNjxqmFYhNyJ>_PP5&6tBwXDFdT-zsqi09<Pqw+4>Ey
z)YNVka~))N9JbGenKAMhqSe6+HJnH8^Yz&wdAx>(8qTTXFt0Bi951gSDjnERqj>$B
zYTUo`KoqZ|t?xpDfLGJ~4)b~9@Ob$Q(dkw3$$kIcgTwQ=(Wc70*5}5~YlvE}&Qy6#
z{n0~Fyl%ieA2EoSx6AWa&s&J%uF4*NO^xrjjts`zM%y6scWGfP{Dr9R>g?_pmHuA+
z^HKa=L;ol@NmwA1I%ivcse*Mu37c}}>8+#V<tapYy|x#@6OV!S7l-F*Og0z6nd2~T
zTOS@fZy_oRwYNy#o>KO;`;jQ#(6r&XtKOKFg%O-EAI`C>=OaWZ1KSaw1HLmLAJ^J;
zn4edV52lwGenM0;oV^@X_VWB!B|oAbggm4n9hW+*ZmrYq4xg&a{iPaR?QhpgwQ6bA
ze{8L`>U)UsJ)&^F_O-q^nNcf1r=n%yXmuTc<*(bilW}Amhr^+9oCo!vN?z?$t>gT$
z;^j)9jU6u@>aI!DGBk8&HP)RNg$jj`jkS7RCDB6H|3=BT^&7TMHb%a2&r}g2>KxwP
z-`sc^$Kfrb<YL?0TN;a8A-+Jk$#L0c6n>fC)W<fDpWJx)MzhVKMbx&r?ryw{gWKlt
za{W8ySDq;kELY4_72-O11{lUdN2d~Lr+=zseWkKlvPN6$H4s<N8Si<UC2!DjuZ4_k
zzfN^rGKP$yYhb^9sKnau?o*p3>&W&yin!W-mzFn6-l6PwBpIJnKB-fSkx?Z$P)+QW
zW~1*#=@1XB_ffLum0m#W+^who!f^DjW-McYD=KdpE*xiG>EVS(qxg`g4(d8rsVm>3
z2O;lw&ew;-$3s1g$FkzFzS0M0l=6EJBD1%%j7<r8bgj`T$rDVcs%RW)3`Zl9?{G5u
zuJEpA6rDdy`z2vcA``{qdxsseF2~{dVdk-omowU15^tf4q3|>k0!OV%vA>8GRquh9
z+Z!)y&{JL;`Tj(WjdN>bkuStw3q^-^%m{n@DEzS<$u|4KnT?loG@Bh+RBf}D&ThP{
zgWK%r^8H6;v+w@o!19egwGLysqf?2s-~Xg!-ty#T$sBFP*HCOd*CftumfS&$zLv7G
zT`zoVT(X9YF(tr;-rtie$<Va~+x7bS&60U!yY8dh*x{`0`o*U<OYWiU`l@7oQ2DM)
zPe;kxXNksZe7RN8dzwo>GaN29`z~}kzy8v<```<aUaV@mknw(N%QM5_isJ2CN^dhi
z7lkjFs6U>4tlAUSR$BBh1D{2{_w&Q?a5a81sMeC;<X)wV^Uq2?#93RdUH4tDd=}Zu
z^-`m$wtM=l>(*beVCBWI5(=c0D&hnm?_arROGx!wqk9&2DE#km8}Tkqt$oI=x0Z3v
z&)*OIqQWV@cR;fx3Ul-KSG&HSQ2=)<{Ja0EY_E<9Mc|=yy4phaU#AK_7;eXNec(zh
z4Y%!=`oXm|ob$_}aA%k>>-U4ca3G9-820ja`r#~zH*FdAo#(?~+YL!S2<!YxIILn;
z0JENU|7s{Ki>2kyT<8O5>2v0<^@B6|T>7<8xE_6;{OkSTg8FQ|&=)qK&vU;nV5KRG
zhk9@yvht{1R$R-z>o){!tu2mqd!F^ta2F+92L;T-p8vs{HaAcF;TIg|rE_?%#VH;1
z8>f?G5Bu=@iMt%<b@_X#vf4q!z&=OSb4|V3d~~f<>bT{)Uuw7f3JTrB2g~-(w*=mh
z_PsmBP(<M64(Fzc&+K%Z8|ZB-!AR{CUN0(fP4;_1tMw(vNu(t$0pqV%{8oq3eR0!)
z{w4Tx?gQ+1QRjO{#)552d^VtrHaQx8cN~1X_Bi>Rl)_(#hOgFE+bFe<gri!+^HHsn
zc{<dm4W%bh{0k(U+nsF_H>MnCJN|Qn19jIcN=VX`{I)}XE92RLNA-7ZJ1M@q<tF-7
z%5CuO7T<7539nxW-HASsb?@nou~+pQW0+SO@{zIIlrLPy+aUO^KisZ<e;#ipS-*=1
zf^KuRP8>$RO5>1yKmy*5-(N-_EgYJjpP8FIS~_~<;ibd#vn2aB6~2q$<EK=uOfgja
zMy2WD_AsRbv^q%CFwZjVJ>9H%lc=ld`IY)^IOTixO^Tm(tKaUuNBm0o|2uvU1adI`
zp0`@U8Y3N{iD|>dHLu<G?A=>;SIVAS%48E>K9}_}>0%+1_cE1yI_sv>m2|F9&Q>c4
z^Il6PlTRnzyqEBEULjdY`#IMwq`Z74nJ6Ulg`E9fOD>VbLoRvGO_%d-G3OVv*^FDs
zr|>3Brku!E)O#&|q-1#?y8o%j_gel82-Edu%e;~cOES?%V!V?x=zXjuUaNSlWuLOC
z_wkMj_qnhs*b8i`)M|>iFQgfD*$ln)!tFbFBPGyY+GK2dek;bo`zJr8--?Mf9rMOY
zEU0<M<;?(%SVJ;2VnNM2F3;or6ibdc!?p*G!|%8x@D_@NBW@Ul;&>x~BUXR_jyu>7
z;Ek1^5<b>H?c?~Ng6p$unBVSG-|KiI1!IexZ~&moWHBFq5grXb4eyHlltU}lQ}t#U
zlbD)x_=S<LDO-F~z;P{Ly34oXHr!MG3YeIh^48E26EJ?3Xu@rCYO2<#b!u*1&P^=S
z>v+55ryL}eRho@<lO}E9d+`RI<gxH+^&R!~u++sA0l%tXZc{LC3K;w-CvEs_+4lT)
zYO5yHs#~ig1CI0GJ`&%qS|(oJ>ow~O&@7ER;Ri^yAn%qju`MIBvmSh7=fo`*tkI4V
zk6X0$TYpy+Jf>^%1$xgg^BIY!wO+w0qfu>Q&Y{KJEvo-s5Z{q3*!Hz<7H*?9;<sJZ
zns|On(|O~w^i3%lcvzp8e#rdJjqbx7p8(7!#5~QNNG8bqV`TyBsFU*X58EEi-CuX)
z!Dy*dX;)fjOYOb9Q*|^iG*^G!!SjX!!0eM|(Eh8K+o53}4-K!DR!Adq%|Y|__Ags&
zGz;Q;$~NfzvuD+u9Xh9m&!L4($}3i@39nN0t4Ta%mP}{T<+AIS{d~1h$eKB{k}c#C
z#bP#9NcxxxD}Ex8EvG%dP|X(b7@BX-p<XeOOcg81v{x;pGgYrrt`@vhxlr)jYNeXu
zH_!O(whLGfJll5;{XS#9%K>p8?7%x`qx3-`=jEW@R4V5dGMP-WiUmxu3Vo%L`Ens`
z`oJyck^srNRnM<x%Xz#^m(LUvzFSS_lDS|XRP)tT$}MMouad|W3tqOGE275|Ub>2j
zJDXDL81930%=aVp!Dcbv)d#<)#=(bJXGHb^mKx!fR7vM^ZYr0rRLj|PIakaU%k;05
zU&-gn$&|H}EV}7b)%UXHYA#vMm9vRrIR%yC3BYuskaCmuFv#Xp)iQe0O}OQBy5M`&
zOcMX)WoUU?kx&1z{_9vfMC<?ikMS<`BhD!2C<p5T(tn?IW4sk(;m2<Wp1>L*h!5Kz
z%5Ug-J21XyXg$ez-@@8rFud`OkMQz3a|ZMOvwEEwYXN2r7z=7>Y{&Y*(1>;6hDI!?
zq492zM%*a3XvBdU8ZTkZV&sVJKSLuH)X?Z){bFdunx3H%3u<Vb!#c*$i1j6gMl7hI
zF^4seMI&x9wrIqG8XB!zZ5pwYxS<gXYG~~JL7PVGBxPvCf|@<jR;&e$u3`sPU~j^E
zq!$7>Vh2trjsn)5hL1wrzzD_hRsct=;fLZ_-eL0*YuKSUcHC~`h&9|$92bK);tVqs
z$Dtp#`G_^VP#o_CaKsu`00+m>*AZLO^M?%HuKKikS5J@fzThJXSFP69+RHd|5up?j
z@{n)D^S<%LA0d2d{~&>}$8ek}HLqT{BkX&rjqE)X=<KYXrE5sCotz*sC*7y^OZCr5
zUQL`?f~faWam7czead@OXOiHthvliZPKQC*r~)U$JkbRsNK=$r(3NX}kD_2o*x!(-
zH5oT%ou2=^<WsC2q)u(M>HT5rP5~FtDah(Q*2n5QshpI^@zW*5+@E!1GaLRg{%DIm
z*-DFkPa#Hn_kD<+9za>C1FN0+W@FK>ATqJ&yQ`JuMQqv+G*?h=%0IZ)P(fVYyVE}G
zI}W;KwS%{WI(mOt#~$Z9&Pn}&*H0c|n!B*!yhZi%TLKQpXyAnRyXUcI{EqXOz;_$=
zr<36E`QN=BX9~O4snk{b?249gC+Ht^&~X(h3)|NMet!mUuHwm~GZpL9gJUgop!*E=
zU|j&rCU2>A|7XC{Gme5T*BUM?kmD?Tw)cU6VU+yUoY_5t{gUCScWiKc`*rM1G@Qt&
zq&>WhneWDWAK#={iUjxf%i^2lk@}VOxfij-XB^Q)>+MzZo1nlkf<w?-)}cUz3dR5r
z%eMzQ%hH~G8Fg~&qVO0ES^fRBp6~uTjSo6g`4{jDgPf`GzJ}~76ScpO+#ck8H<3ys
zfbF^1+Lw!IKka5KsR{z$39pbXo2_NREqlp=o6lpX;wL@qQ9Q%|e6c5T^NGB@ukp)n
zCY!1h$^~ph5j`julZlj@P2_z)<7cyJ+FJ6y<`w856S=ql{$sq`;Ca7r2)0W4H~SiP
zjwnlm5~_85ED^6s+Ar`q?`yDa?pHA_&;)^yAoe)k-g>if3c$R#*b95k=)Fa3-<q{k
zEU2Ne7309rh?T|Ahy^t?c3`h-XvA8Rp%Dve&I>LJ8ZsW*Q~Or_uvc22^#}UpsPZcv
z#M!xDqS_;bi{P&BO^SZPdo!ZO?%v?f!1+yua|iau+J@x(*6~*m119Gw*A0|8b7~DY
z=BK9kJXRbGN5TO;)(FxUeyH%%Jm14}s49%S&tsp>^0q5DZSzFxN8QD7sth-Z<qfeV
zmJ!h)RxM%du{BO12Cq9fPEBXt@;8!$^>jtGv(^ET@=r}YIk2KwPZtpXXTEy$1au+#
z({`~3`+IKNS5FF09~gZeb6MczW6jvX8d#6=e&q@5*UgxU9gLwk4sEw_#16Iq4qn5(
zCvZp|cKfqZI)%AWt_|0*FNYp63Ae4)h^gPY8~a_>b59@1)Q$GpMrC=m*}wq|ANa^)
z8+G)r>$hGW4i`?EOPytMz^ahwgKB&|f&FnLPe{3_;IwB@o(k9p4}q(Pr+td24=g-V
zdiyL(WN)pluF~mRP&d3cIFEg9Bp=iqgTK)<^VJsYM;TtaFdowcT&=sO+B%=?yan6S
zhXlUro}r55H1<<Uo~_uchU1s}5ps}am!?Rwzj-FIO>3=OuZd^C5Hi#?&bQ;-hiUZi
zC4W$J12%Nvjdgu-;C7e-+^WyXa%?~QvHy*u8=O4oZ7~~@@vZL;fJ@GAqBtLXjhrKv
zvG*O82Z_Px`(uSe_-DT%a+B1FD{U0%&=bRe_KK3`b6D#VO<p?@1oA=g_?oBJ<g`!D
z(3-q$_6KuV^Zqn;VXK`7{LYMDUORQLR<AE%Xkr^x_jDfCD;jPw6z*Q^neIYACNRg{
zz<gkNyLO7!?R7EOB}U@;rio937sokvc>d^8>G1sFrPAWz`3L4^mku4Bot~MU(J<H9
zFb_REw{%#8z|ToM*EvUzNF+f3`u@vbB02}*u4dN{<Ct?%Rm-7Y>HBxB?{e!oj{?UJ
zxwuxQZJEv;ALe~QV2)jO+okSl)AZpRk?mk{dL)~1c>?Qrq9f;I8Fg4gNvB>4W<7E_
z&_*yPD(3byqCu_pZahc7jJ>0wC)!d4vu<)$OX|CuCvLzRdFyVgpW&qFf};w{ASSYP
z;(vi&e_}eZo~>ppg+ehoHRZ0JTBFndQoYvhSf{oI=Z-F%aElt}y})_Pp8hyR{xkZO
z@~^004<4SMnLS=woSi;;;85wv!XmzX3g0M^;qd%YGN=CjJpTQ#`hmVrs=o{P_Z|5A
zU*lX@&bHX1doX8Tom1mG(V9dYV{QSqoKBU9W@%=6Y5JI?MZOKFF)PczF?G}5gj%#E
z`&4`$o<De`G&lRm>>L;+KAr*a!h!j(9XoJH{Cx}bKDRJ;Wc~rVM=R%e$|F0e_bUaQ
zT~?v(LN%95RtotX&X+wG2blR{wovgsoXqhOsMa{$d=#^=NGjW>@lpPp!RIC`ex_1z
z{Y)y8OyX26pQz;X$y~aa%v7@pKN{c9E59@e8#~E1jidh4J{Hb6nlG)Ck-yQB_nSE}
zn|aGuik|Q0%bALsPZhFWs^XQinWUSBFu7D7C+4y{&eR%EximYy!YO%Y8}15bB)G8J
z<1k*@3hMV`marG>#}BhYwzP-&!8X2_c2jvTiJZ1dB31U&u<D$f%zNonrji+fAKn8!
zjlH1ehjfAvBdG_f8CpihN&7O5laK+YQuoj}Q_9ZvW8ZU<W2gRli;e~{qEF-6aoww6
zGo@-uk*>MTGuQ*fw9&~M+~$4QJhee;halkzGSYEC4B6MRd=>n&90R*>HWc4RlhV0Q
zC$VNd=@?-om0p3Ew<WCO`oS9tj?+-~KZo@U^@Z5)z^1wia3PDOA=6mM;3n^#ynByc
zos`I=bD2GnUnVJarZagr8Te^M?>N>hVf2`{sVPHJ{T5EO-$#q^lZtK~>y<FN!YA8A
zr8GTKGD<0}6zpF8W4BKD!#*wdGgwbt4gF#1ep|^+X9{6-`|3Mdde-{j3P9iUot!uC
z7zZzVM&g0j-&b%B5~dGh2d(nzqhbIHyA$RhrQLn^Jzr0M1IEmL?8V7&Tmjt*bj&i1
zAO7D#q<=y6*D@x1=5MW0du)y8@=`}RTs_CjQhAu-<mep?8r`AmNoMXewCt(MF6v?b
z-e(G9CT#E#(3o1@lXpe%rqnmw3>(VcNSH`}ytcV@7x8$~Z8RHaSDI_>NzChhyX97V
zM395aNo8IkKLX!THBY=UI6lQYIzNb#e|OlPPJF@WaWD%J(KMP41_QV3X~*4$)>RsU
zX5uRG=-TjGzZk*WNLCQe-bkn{d-_=LIE+0#8SH&wWhTGrP3%`r4rZThHxMj{l0Se=
z*pyt)ym$}c<;CX!YkI!8F^L7kq?O<=u12V-WRLyFJ(`wxuT5)!_5KL7I4-gadmSTJ
z>>@u9`{WpG275q*V+h^szDLJ`KMdd)LS_rcE7%hnJ}Q+=1{YbXiHx5}7t`59BA3Gd
z71N0#5_-!S_z~8dh2sSFjTVlo>t|hDpYf}1vEV0Yvyn(s7I39dMfPtu4jK2^@}oA6
z*o{hn4~_%enjjo1?m#iawNABwC`5}A2wHBZR<6}+owNAM^IOQ_CtEG6`Sg9&mK@qu
z`Vvec*!8JA2%E-*q~x!M#z+n!NQTctmaswRb-`83VF|%{Dx@Ruk0^shLdW1IGvPF%
z*A<xFEPeAB`&i%^#!tGqaoi9wX2x+TOS}w(gIyq)k!bcQKlm&HGy~#L^S=mv>2ba*
zKX7})gG8av$zByWdbiCZEWYUQ5{nm%By0REBN7y9cO%+`MMB4;cNPte!4@50wcf<d
z4|67Q(ZbQSLe{`vQ$At;l%aRkV@bU;$K&)$6z&oArO@j!bm7OsdG9xdY_G+9&g~7y
zGm_oNI6B?Z(SFzY@d*5*>Oq9+1qqzR$aTmog2q5&SdBmF1lR}6U@v!aSRbJL2=4*j
z85{@mAcIpVVczg7e!Go>f7mha0dCzt3QwUZ^_kVuwCRgM#}}qq#DArp-xuv^;uW!F
z+U4kP=kF)n!EZS=&bA*gbbH1mH9?FQcjr7lBjfzJ^P(LAP?2ZK>63hHoncz?_dC_^
z7sT&)?)7vHyD(Fg9csmSfNZ;amfD8H@ErK6fEkl7r2`ZM1l4tET~D!f(C8%Kdqx}=
zU1S{gak~+N5B1w*g~M*1)!lpc9ao}ok1B(_K554FA>w_QaV;6t<NENx?G?vZyDAwu
zZ}1&~1LxWlzkwa`?<XE4+z48$-}%h?J@LC*qpFZC5+YZdXS%}Bz{Th8Pke=N1>1<S
z=GcN+fopv(PWhW9j@5R*<xRuI!<;CO>h;)vyI&i1&aI=DDu)R+rE}BH;k<=t%5z>q
zUaGD(S4z#cObMbf#(5umZs>tsaa#uTUga0)T(1kK4JXn8Zdb4~TO_O{n(m8>@*9f`
zpCtDjJ8l$h0vh3Olt&8M^sT3zhx03ZqamfqaXY%ZuD<DZl!v>3J>%qK*C7uVKg(2R
zoXKsQpmQ~<3vdJd4yED$SNxTx@b!1%J3?>H74e-(1weG4)7kDXs6G$oTF}`p?Kt>U
z)7aG|)kdDvigVNIs_*kblup9sJRHg^y@<SEv8K`s3Bo6R=L~G%BIN}K0lL#9b)NHH
z$Yt>L=Jej7`YD6{>xLtH;<5I+_%5l^@7x!pll{<13$B`q0m(VyW})*8VkkJ@*T3JX
zXi=L(vTtQkj<Ub(V!l`f-dhyRdjdv$Mjzfhv4(Hw@E?&cAS!v7M&kSv=Q?u>2XOjn
z&O`Ax9f#_9hw>ME2lFPS2E%Q1nk!|MBBRF`(e-(Z9mAA&06u!D`OsRuQ@bC9nt&d%
z%Ni}$F`Qg;QKqQi)%k+s9LF9Jytb;1qdwg#KZL?D)Rts9y~}Y<s_*9O9FDr>_s8*l
zIrRH6J-$hnpOs@rl^~KOgJnf6;|J)>7jQI=Lg8q9+y%Z433@7d1ldg$I(=`*b7zvL
zbO6a0M`ss~;9rN19D%o#dZzRJ(xHQg=Vpm_Ip)cRe~$A+jDY(41^s=|@5t{5aZs+m
zKL;C^?e%w|KE_YJt?T<k_I>pNY!%-hIk4K9DW8%Arok_-Kc3zi@?Bjx*DyH4?7<;m
zlA6yG$cyZT!BM`ZL-+4{zIV|%acdMzQjf6&&JuwqP;83F-_Fm9Z>Q~#tfvopzKK#a
z;Q!_cu;%Rj0XaTbJJW4UR-OCT+O+%y-J2)Aj2Ogz`CY0}Xjp#x92zg!-$d^jpGSA+
zf1JmLRd;|K0UgxVYYj1uc<z16hR32<*KrW8!?a+TmtY@+A3ldB^orzJ+TP2-Z>Q~V
zTVOZb?hMWALRQ)Cg!$%HR=he)U+e!B^R0Di1;r1nZ`)vN3g?;bcAoW(8?p?q$!|3G
z@h43WrPBx}eLKS+sdiNhW9_ZGrC(t_==aC)`+M^D06fimSLE+nPXzxDahCmo`CaIU
zexFC~q9c8FiS@&Dx69wPZkX<*{9VgV`C2#PTpnJ5CPcA%!hDN=ixcxUeYsn~paz$Q
zk;^n>Ia`qTD}O@vR6u_du*hMhf>>e}Z8ecjc-9V7nrv^e#nWrAE5qQRrjz$#H)(PW
zpMhNs%!69V5{i4(yq$mz6&x`YHel9`YV8y*FbVyLZ9Wm>IsOFtKMIx?$;8_?m42SN
z$?!(3cjXO`9bsZ#Ln@NqGw#LuWok;-kCG?abf}ujCBLzU5*2};_hK#hOP1Zn&%8`c
z4MKvI5~RZS^6JR%FF3fvg&a29Pq1=WkFUcohr%&4;Cr9a%MSSGFusLlV3#50#OA40
z++L@Bv>-)&c2Kpy7}1_dg`i*|h4GYC-_IeprJ&Df+%&3PRdMAfi3>lzn<{2p{F5#e
zbCrD2uT-%A;p3cGP;-Z4@>4bqubRZYpJXaouDa=B0+mFvxIk3M6w|qCDxXeRG-5$b
zKGcVTh8%|+yYR88fJY1tJGG|`8>^svl?Y4@!)4^ybN_bpBZu%PjKsI3vG<g+kvHJ$
zqIl58FbW$3H8y>75s8XXeCRzTiPoPNbxWdKn*(Fe`6bU`jS$68yoU9eZZ{+GO|8CJ
z#yl6r!$9hdWMiP#+CR@=jTgnoz?wCa++?}gtdk9LjO9ate_*F!Fj?n|Z({B@J}TBJ
z1aLf}#=?tOr;b5R&+j0h0{P|@UJvWoD7^6ofeK;@A?FJ1#QlUQd;|5YL8<rI?+Bb;
zlL~cGKD}PV;z+cK#U#&jOFu-kqv3e}@s@xy`G$53ieWtD?-i_^L>q=>{Yb!ErOOo)
zytxZ>0r`7T`WvJ_uv*Z4yBE25QMd-|3qq&suD#m_-+;W~9U%|-z-@60|7*$y&m(v5
z>iG<y*0J=&9fX_KP;yhkF?OmkVE<10w*P>fxdp6&L>z<`#C0qtPnRm>4`|=^ZOFfH
zieg|Td@6NnD_BqA8{KjKU3{axmTs$zlx>#Jw>TEH6|^LMdqpO3eHY($@3wH^KEAlt
zr0kz@5#3(_EZv#cbVXpb!ekNHMdmelr27K2XW1$Dmg*9jL`b)#*06hE-kylyjqB%b
z;r*xL2mg8$sI{GZAlhH`xWFYSc^ij);DyO(I~l^)ullGAPKT=O17|)Tjdu{cW`yh)
z-tU8Nz;VYY^&aP$JBdf!+@TT}DlNO&S*D8vSa_iLBgzx<I)3Y2@vs~pct*ggxHl&u
za0C_i{M4|4kCl7*w|5C$nO&9@{3jdWION<Hy5Mxc-|YQgmoQ?lz<X}q!|%Z!8a{!(
z>3uhi!C!@K?SD#+!G?cE)VL<P^sRU=_Ub=lzSR+Jx4&KdS@Ug8ebfA6?4Dt}hLhp}
zwCY#2Ods1YVvj5b0MSS({k(*|tj43phd`(N1@QS8%N3ZPzROJe*X}kFy=sIr)U}3g
z=@Gr0qW5}8TV*`jN9mSm$Ne~m7>TB-8_4;UWM=ztZnWTJ5q-Wes-%<Ni0=TrJP^DJ
z)LHyc{000-3aCF(p(F6wb-pU4`JwpdQ5CNUo)e%jIc`|XQk^EY{+fiR%{g7|6!&*9
zl$^N(OJ7}>m4ENL&v6bc(6t|mk#C(S;%~&a)h|?IMA|;Z*6WIP*#662xS36xD1$;<
ze%;^i4}(Y5MfgR<!+F>j^U%G3*FI2??7ta_@y@XrNS-GZPwTM3D4vM@Q8<ZfNAy`I
z$6?D+^oP+&+y-qBrLa!+VjM*A6enBc)+nwabi#AxHjJkz`orji*Y`YEzS#$F9DCN%
zUh{b#@wIXA$rC2?nLu1E3U550jLpnvZz+7_R5|~$R7FW7=$z+}6Ns}BO$k%4Q(0vs
zZwe^(yH_k2<v=Mu#;7!|C$J6`xNwYy<sYgxulK-g#agZ#2Ekjw6#MUU3dX*VtoKh~
zkDfcBv2-up!9|?oHsp?&upOqIM;pyEc=W(u$8y+joa$in$grR71Iv#L(7nw6f;B_;
z85f=9@Op`S`d0?^tI~0;ii5w>GEV+5MR+p4NVRy_{y!W8PPJAO)nk88#T)4ign8|$
zJxsCPz$CzNgIqF`$Ww9PO0HZ^CDX;ckJ7YBl=M#^RoQb*ZK86aS}s&7<#aY#C>9XB
z%;sIUjQf_^GOmCovvzHw6fTq|D%C2LCQ26y<!UjNOyqLuO17Nz%3js3O|%O>@+;0s
zsl7h~jCUWpv;JR&Umafmei~(N5vVPfkr7_ZyD8KQ#x>d;Dg`IpT-7)F$JN$ErQ#x?
zJ(cv6l~ma)<8o=fn)Og9%JUPp{sHTueIi*zB`LRzTE#vB&(&-)gG#!YeA(820)B1;
z{cjrM-TLP|z)SFhq<{7&A#Wwbs}QRp#y1H+7lSW;NB|%2eV%~7`wE{0;g(VxdGeGH
z?={cxafdz&dIB-`C|Dl*<QpGUWB(ldqlTxQiRFa^ays0x?|tA;b!$|7x%ZxZI{$GC
z;-`_g6!9>0X8%aE2qWEBk?YfE5Ub>|LA%01&Z-U_o?l#=o<A^KDw%tL`WQ*C6lls6
zYuJXO^#o#?VYFCp5$9Ij<XD_YihK@t4)M=0dL$=&uC78a_Upaa0(W@TO&lRlRmnqf
z&@lW)9!(;eXQsjs79l=2TR<!`jE<25v#dNVV<`lm_bWaxN3;*{Nhp{H3k&0T0`boQ
zc~BCVd%h1UKBz`&7>-CjdN7&uwO0i$o-1Q#HFJg+3u<VbM_lzQ`kXM<MHw2gpoT^r
zF~9(g{<A}XMt@L4qkvecp%J^TFf?L84UH{#*fe6@ub~kOYG_;u(1@Mp42@V&$N3#)
zqpu=X#5UT!SMIlr9A&>cDn6QDepm7P#^lia@^Bj?%Y&daI)3-_L-Q<LU4MoncH&o|
zWY+P!2>uLd6N4xua?2jU@*p_%yngwvp?Mxa$9xe|9(nS-{v!5j*F---a{7GL`vTD$
z!uK;C>wNX&0FGFPZST-DA6vd?^8p<F9dam+3jrLl4mT7>X1C2ptV0dOvG*PuN36pP
z;NbPp+X9EQ-tqZPjwU(!p2&-c*<TZTQ>4nux2}I_XgULoA#psaW!bZ5Xc~j~0d+!b
z&bcoOI&`L~-uUHxj(iGJpND(68~qh=_8AVxd#1}8E;9C`_gBk^jZ2)-uzZGoMZ;Pf
zB~f;aVrDYu-ow3ViLV!iZSh?JGj3bd$BWv}K8HKh*TfbLDQznYxJx}GtpV)O#4UMG
zxHUC2oxyC<kkYxemn5wNR%*D;=YBga_^`iG2vEm6FK77sBIm7BUOF%um{v9v<`@BS
z4EAFQBjXbf$^HK^vHhRcFkACdCnAOsfH|gRxwRl*+70Vr;X9Nsaf;#_^1}5;k^D{f
zT{_rjy!9}hGb(!)?@6lxD$dxqO{@ZD|04v0i!zkXQWcef#X&vivd~%60Wo&z{Z!PP
zM=Tkqv3Lv1#dQgDAK+C1C-Rv!AnA<HQEx@O@_<9Z3iJ6kB?r}PKj4_(`TTzl=Q-Bz
zIIOF8c42H#Uh>Tt(>vfVkZ-V3R?%ZRd!^qe_3t=dSLdsgqwr5Bk<TE%$$sH{h84Q`
zA)e?KhlrHlOz-pF$nhof9bt4t%O54V<ej60z*k*7+eVp0m<-8GcU2Hp!P(vP(dmbb
zzoh#d>&^pyXHJ}N&LiG_5O=#~SeNVvDP|l3H;3w-2k6aQy41w|vku)wz^+kg2EJ4J
zF~cpa)>d!@cFu2T-**9eUUw|?vyHWth1F(dc3s0fi@2?XA+#0%<mCQ3hnVQPLk(f?
z2M`TkAP$U=-Geimb!W+Mqp+wjA1#f6dAl2i*b<VE&ZV!W8hOC8>NeVRwn2KtydYyw
zClME1=YFH9=`lPlS*zBNbuN!N1V1-VY=z%@_BnYDFUH^MsZ!mLf_~+@%B}B)!{G2m
zyk1QCI-dZpb6s%aGdha#?Elpu9`&8kINwvUwb1uv@K0$!J>hXG*%BVuhdvW2AJ3=Z
zjWoQ=o5BMtcwo@WAuBkMuI5uFuw3@CZVu0;rSq8-UKdQ3^L{2<Eqi!wx14nSf*n{!
zu|>ROfXD2r2tX&Rc)mAT#Q{Lt&*Sj{uOI^Z(B~g2-sv5Ua%61(`;hsr;4;U8DJOyY
zpigW$UW<s9omMva62^t@Q}M{DT`#)#?Nc4?q?s1U>h`mz@-`?gy1Hl0(Y}EDdh#1z
zPi1o`n8tVI)Kxjn$2%BX8^uQ+e3X@4Y{i%?>%CR1QJEM^EGXfXKH=>Ejo9unG-5#w
zjY~K)HFCrbIYT2B)a3a-i*pD=BUS-{Jrl=v=`PK$vJa7u1|YQ#&q-4fKd-7x%br~0
z-8j22Jj5!<V8ULQ=OwxaO+1J(G<V=3x3wrz0H;MwbR+NU0a~$&3ee(t=Q!?gl#w~p
zX_|=@Zb`4R=-zKAFM#2F*_#4~^1CCAQICpiuTnt-ns#L6cQH=&y8islL~n2!64ER_
zXmKLkK{P2nNACX=(E=xOWpZEvvT~m5mQRm~4|9O8^ISg`xUtS#y#K%=X!4xBzMW`_
z-yd$xHP7IaUN^ji^DOZVE4h}w{blOLCa{<)JHe!{pjJ$y`;|Y~hBGM4MFTbJng(<}
z=2o074bxw}ej9nCYrf6}czH;Ck^L{x>NOA5p(Q@WSTlW6(mH~!Q)(`v_wh6=5{W2{
zlPbsKY_hY=PdccT61REXZqrYrqEF>IEP?YOqJ#UJ=vA{0=luY^A7H-A><``#(Ag5c
z!Fb6aOb%Tg=SBD(MkIgdeb76B-*u{<w#nVt=ae0k15ocj(_Y}aSl@pDzo7G#IZs+E
zO+G|HH3$9*_7u-z?lgOiHtc%a#8deFEv!Z5?@~r=t;DxaB37^k^9A9@^;Hs(9%_J3
z+BWeieA{lmVWC{2GHPN2hUOR-+a|UH=G<AaW<=(V>=1E-4Fp(Ev^Se_(5%*>%@gQK
z-D5*%|6ZasIK8n=Z?wIK*q|k|tOtWDd00aO2fw#%?mn%9#$n~Ns`N08C*BP&wVF8h
z^;dh|X;;&WI;gw1tNLp1-+Ii@8MXdH9bn>A`6(sS0%QvCf!tN0xDDdtmg}T$cf)3w
z59#CkujNFQMXLnknDrC2Gz^l(((s<$W2Ow7;<^3<td|cvs5I80>#n@1#z8A(YXOeW
zYH9z+x~p{8QyK7m89qPRf^o;VzAyTr&z#KX-Lwv7o_pk{MFXo&J?tUnLeR)x*Ll`2
z#NklyyTA+j>$Q%~8Queb6G@w%vb0~(>3R9aaehsWLs|nfp6?62tGST*djsp|???Xb
zR{DDt>s{hc%+<I>R#(Y8Dx9Wsvrk~HsNt+RolAIyxNM!9z6EPPv?Yt`2d-(g47_@S
zNz6BW8|yfyY}-Qz!(OjXKE#?3{Pe)!7fd1YO;*;=9M*!NunjnR)Vt#~$t(TgVE(H<
z+);!0;B^AM3m|dhr3+L)z-yu6JLjlou+GGHtS>@%l?nZ;gl|gq<vRv`V7*bi=r^(U
zh`Qg!ywco$Os=1>fa26!(&^0;58|w9kh@kC4<-Nmv|8ubc-VK-TbsY`99A9i0LLZ|
zL)X(JEBEvBn16qr?Y0Z-n@S(F@BGVZtuTmhkn3Buw$Ym#F`!Gh6^XJBaA5d{@lS$>
z;qeC-bYlP1MS^V)3nPJFj7_!9Ron$^@A>|40p2+-Np(VqcN@3iOrY1cO?O@T!x|D)
zr|359tyC=z&XY#vR5L#>pkH!$Teywl_OgsoquD`B6z>a*d#fCGepA4yO~IMf8bbXj
zriExf>grM2R1@`k*lwskOU{u%@^YUIWyb!;&{dA*R!0%5h@8@$MS&cgv;Mb2ZotA%
znDJS{og;?hv9TTN2*9CMKjtk+T2jg5y#B4r?=+6}S6Wk(p60L@(Cc6QmDcPxPy8*6
zOUh-}-^IO4dEW3A+9oi!;9HB6)!7fwSY1(e&n_*pc8S2bPv2R2&uZI!zAZreC#c9F
zG;~9AXXbVEBlA8qn#gRESkCnx`#IRhRnXT5`SZ#LQSA0A@afY;x?6Awe)f9D^H2MA
z%JzU^%7bkT8ti|lDotsv2K(hPenrt1V_Z27aer>5*}(O5QHzf1;=BR8*Eup7m>$!j
zifVPnxO_$wPUbnu!<Zm>Y@F6|Kx5`O%hRy^71TdlFP%axswK|y4qE<s-=KEd<DB>D
zb^Hgg+0pQ*U1QtedI9z~BrfANY0f~LozG6_ypVAXadwh$v)ODS>z50KB;I3Ar1N<n
zryZ4C2G1;KGkDF3(}D`QlwWkyDC>?J4qiD|p<40js_Ul8)wE9+9q!h!m144*C};f)
z67rL%wUEfAT{r0#v(-$o?B$c<HitPoc^S5|&p9cz{%3*tuAmwB0lf`ALLcC9Y%gDQ
zacq^yd&PoRNJGup6waFP)Rv3qt+ih9QZ_2$7qhvPo5wvCzld8bsY)v4mhn4^>DYac
zE+mu1YQo1Y3O|v}B(h$?O=dFXV!2pI;l@N)AJDntD1ESL%t!PA#hpgz12<E^)8dIr
z3J;g#=r9YVWpG`nkjdt~MB2@pKEN}zq`^$4n#b=MShQCz<Z<?x#9+V&yAKNGbQuV%
zfGZ@bsYJG#%vH*nVlkKT%6Jl?s}DTPv7_|CrZFGU2k&7WF+v}d)1>+YPIAk+Y$}n#
zV|UPTGE+`g5*5$2#zEFg;6eCQsz7h!W$_+e1^=sx1K$+ReR1o`?gN|wS8xx@%b}MN
znMx{O#M^nPOtn%ex_G)S)71z2vG*LM4>pbYh(34?d(#p6z;j*P$I2&NxcEY*n$G0$
z3<uqs!|``M?|Nn&Bw@qJbf%Eb6*Ba)2kvu~D|qN5g}<^s-X*l=100x_v#ET+$LopJ
z0!<9Xd@h?WdU-gybOL=K-fjCsb$+oE>&;R6VDp#{b^@QJU%)<{`heFjVfVCRJv!!i
z#`h8S@G<z}M}~!O3FkyH_~K`M3*SYY@x<VZ_nyG_IG<zT?1k`AK8OexQK`%d3Wqe-
zT6=k25^INg_Kdee(0)qMp20Z`(;j_4k6nc>_Nh5e=hD9K7V$Wa=O+C^GFS9dULuFr
zM5}(bQmzP(#Ao{_aK5uo=MTh+V9woRLFrsb<`3+`-5-la+>+3u5eI5$d=Q`!>y!<R
zSWrXbHSBMV9I=LB(TMY9hQ<}_lMRj7MV6rv3u<V*iu*-|M(hg9(1-;!G|t~)(};B&
zhDI!?q45gt{unu8U5TL)3u<VbpA685TX0!4;y?|Jh0ohGVpm&+Ml7hIvGY!wM(k?B
z(1-;!G~N%;h~1<a8nK{;#w&N(a>TlOLn9W{aei6t<<IXT8sXueo~`>RF{Gi8nDe10
zzAzwP916H<-UdNr@ppF|f5Gs==<E%S2O%UK4|@XV^XOMu6i~&G)W1Z14smXX`l|f_
zjGa8OJ5FAOonk5dh3$J8Za^&h9C7)c0r?uFdn4nJ0V5s+ljiRPVs!n-*Wmpd!`|SC
zEIXO|(m;0dWSpUJ{@Vu<pIB#h$AJS{jJFfM8K?6KtIB7+i2FkQb*ijrke)J`fSL}=
za^lNzbOu*>HyO?^yY)Vz!3*%%g{DDc-4}d0h$C(x8H!^Dc|wMd*o9&!4!YN5;fPxZ
zhT_<kv~k2P??Z9C7Q_)3ybHxa?=~7)VuOXDIM&lPj@SidD30wJ8%OMdF%-v30UWUl
z!cZLhaSzGpBQ_WpisPLCj@SiVD2`Un<|B5&7K(%JOBq>W7i6J0UI^fbjh2MsC=_fy
zVi#>)IAk8#TLMRncg9PKcuu2+idV8ABCP;02Rx$u>B~jpV+0(CBp}_Y<knYx*TW%J
z3r^klbbjy)Qv&Ze<^p{_$7lH7j}3@>usNUy|DL^Z_=oZR8ok!}hq3qvTnVY$v|m$w
zdEv+7_#SF*MDCBghxV_qjyZH}eumbVOzRM0JpJe4VRR%&Y1|*i;vQH(`nD?D&Wk@0
z$M;Y=>cM|}e;oc{^rF#g-E5tX!#}WY^f@)_=9NKl4>qoP@O$^i@ji@hG<sco@74nb
z|LCzsnGDGJB(Eu)BK9n56)XKJKgwt9EsPEt4+74swcRp`yQ>^b)q=7kb)L$$Sqq-B
zOcW5VVc`mhr}F_iHk=&>HCGXJZd&4?!r89WYDlF)6<JhLHo0prbbUXg066Dm`vbB)
z%0kvFohDvBqns8w*SuoBi5Jo86_eN1Iwaa5y$7$=$SgJ~4QSt~Vx#*HE11?<u86CX
z>^UdrEd_%a1!+SX1#}_ftCWNEO|FNA6r(eEo=+A<D>v6wMKsP~IQO8SXK!(Jt+aE<
z7l_8gmz#|2t%n4zK$T>cYwLXXH&YMzaizP9HxNC!1EOnoUA4??A;O;9>8ds*tFU$d
zsMFq6bu;GgrEvbRN;ds>=!lR3PFQCTYvq4S$?yhp3&LbzZB0$}5u+<@oGWm3C-&>#
zyM$r;SYHr)o~d*h2<!REjp00!&T#?KW{{>csuCBjOmP=7Qo~5kVovwzdlbk2yyC5m
zj5urD>^v%e#}L;#eM;$cD{=(}*QsWCWNii*x5nnni(Nd5v|r>E1LmmWbq{jJ!+2G?
zRYf^uW}wXFlZD^9w1}DA_=Fdhy6Ng?F7;Z8?qr71HFg(9IzmOD&g0_TBi*#g38U}8
zAN%xYkpn@rg-;j$Miq#+EQ#dd+^xOHI|#yyLh%7;rvLtNq7Qohspcx)(nV5by@q8v
zIc$bG@l}GMVW~<bh-$s!o)3J!^ocvaMlg6etx31uYMmNxsy~heKKsFE#drB$7A`_%
zuyxV+x1XT4);9}3^YB6sjJe^?Fnhkyjc3(AC9*;dtyg<s+LhH>i`1=UnfWH+QJJ7v
z`ndJhvTJ?+u<N^5J0+5PIiK{!l4wsi(dzyw7pZlp-PIb+#O+f3QF$loml3;v7IXFW
zcssSWin~b3RGw^D^094#ax_ok59DZy6iu3ja1rw?(pE)&=XcRQfjJrNMQLQ&fpkY-
z_6Oxc|Gv(JKG0l&dVO_mm1uA-^a;!fzt6VS1;%qO<wF0YBi#nZ(P?T=x!XSs?|mzB
zLxMS`;<{+9LYJ#hoq@(K)eYDQ*nf-vgu~LqZW1TugYSsMc}!y^`gZ`|l}Mb&#QWLA
zE3cubX2mbFtVh;5tu+*HD6gGjwTQds(7SquRqKf4e}mgu_kWK8H|vq~{dXAV0bCgs
zH-wjPRqhz<YU{+GOd_jUj$ku9@Z2gH9)16}=6hguMG*HZ-$yj=2NpU%7x&lXy)lm;
z3NLlc_FP<M+czohPC=#Gm%JN}BX|c6ufcs=+0hBCQJCi7YuVuXS>&nPQt6{}7q7cj
z{hW`iAEe2ZQ5e`m#z`Je%O#5$zbKE+bv-eviGRP2Q^vM6%0Qg*Yf6U+tRIG#N7}x)
zMcGxu0IEg*$+hV&%=?5}_-WJ2+D6XX-_<P(w<8~qVmrDV0>e9ZhM7TLqNZc(6}<2q
z@Ol&stOwp1=@-T~&tU$)-!Tl+13c_UE_8qM8>efl&BhAe+a=lWQ+DEDehlCU-uptn
zy-d*OH8j1^7zVFBC2+G}f2SLk_k9-366VPJxjvA5EgR0)eH2R|&EuN_##R_yJ9RAr
zMkTy+Az#C8>vjGT=F$6|2zd1(H_v|w_^d8iXwm5L#oq4$O{SC{cWvvz6QN0i`{mv?
zrz`4W0`Wlibiem`+!6NWe9>i}tE40H(U&J2=XL1ldbVL@_E-#vYDx6q_1*AQ&5Yyx
z#B^dEImUjblE_X?&FLaQhs6y)3HMkpT&3nM1u7eGAD@I@`b`IpbBX3jfraV`&7pzr
z54txS2BV2X4qh|W;VXWV<(NUa{W_(-&mA~C6Qs}Zbf+Z*UZX}Uw3WI%3%Ne{_jI3`
z*t78o=Aol)6F&)<bDy}LU@RO$E(ru)X%5?Qi{sEcEn4Tsb(#Tbt;Lq0rwjI2)$qjI
z%@d!*eAurR5Z&1#n5Y^*^tQkc;QQQ>1JiS}rP=w1A6hti<N!@|q81Cx$eEj-e}Hts
zwomiYSw|H>;&MuW<G!6kzn!JNC3R7+Dp117FjyD_VRR)aW9M{NDS*c+^JL>%KwtL2
zb=6(k0zWHYLTX68D85<9Etyzmdb8uKs552PkTN=<yY%?31U}@i%LRefSqDDtY@hm4
z^zOx3r+<B^kGf%q<t{mCeFi*%`ci!Fa4Y=ASso*_yzj0rRYHY#IdFt+{SfS;^*gfm
z)9NW&f7iVECKtdmeM##qkKe6dDT@eB*t_)}(|(9wt6ysJ6ZX`fJg?H7q$e2`d@kb=
zSNhKDx(oJqGiplRaNA*r8c)EjOGu_iZzlteG(sQr`$u%Iir$a^0D92tSVe^AUE;OD
zyej`G0yZc^=C9VooWMSZ>dbY+TI}l<yoY)Rd^Ni6!#t?g9z?eZy0kWoy|<+f!PQGx
z>gI_VXIBI+!8M_i1)6AcvL_|>&Ac}7z)#Z&gUbit-i?Gy3WSVr3FEs5pV~qbX@+~N
z9~?;Y8iVdnMdFjBonKM<qqq|552k_pc(U)Q%uuho`X`r2_^ZQ0_RYLqf<GD;Z~YTr
zEQ{zTB6uq+y<Nn37#DBd$rik3_uxy%MT6JUY)iZ0hr4Y=4<N|N=aW|i+&Fqx9+vUE
z_dI-fQ`VEkvx6$2D7!(=jdWMDY0vrUp-i%oZ>oN{06#x29huV}bIvx0xnf-S`NV|%
z_s0siSeM#9lWx{RM)s}ixXVF2*l?D=6wnMyG5Wv6u>QJVSwkq_0E;y*!%{uZ9$0&R
z05q@FsCJHCt93A~mZ~dm+Qv+N^rnfYQq((#Fnx%i3QBU;>b1^Ux{JQLqV6hFyx}h3
zTUb2&wb{}V=DV$;-J#j(g%UlTcl4p@rNc+&O9$qr7ZDp}o29p%&f^X=U1SCe6}tJ1
z4Sc&@!_pa4xu(v?0#2Q&<M-Q@tx%oK^L*A`DvNhJpH$yy?si#k6zuUa1K^|u7xzK0
z#U<B7yjo}CSMvqj1j*#mg+#89^9$vCI`3CKuYf{~2`_=$R&wCrnrJ%34`Cu!h*xWC
zkK<Y=W($sSwBXw{eWHu|+KO~64wm6H_;SKQlb20Wz9-ZBI}U&hEBxO3&<)K!Wb)Tn
zL0`G(;Td2ZJ`bC6b(|!&a{_S^j<df6pL-QDAWp|yYm*N;2OoMBI5onYvejMioniRw
z{+yc9&2(PsdlBshv=0;qa#79UtiD5h9{xFuj{)(~`b*d0*abfxhASwOtzC0A@@7Qa
zLHVFqC_EV|lbCt01>YRT&wx1TFasl);=5Q$0WYstcfgll4PH82U|esF0T<6jR6mCJ
z5_1f;tPeH4wYq;0Pn}X}-f8%$n<hSo^}pksbQ{ga*%cH?oTM}OHjKi@y)m~{E3LH2
z@4!8ygcPMCi3$<*WC{OAEe|Rj*AI$A%!#$f#k5fZo|MEhukhS35}sz6ieS(IHz7<|
zd~F#NAIjBJd1M*N#MuT(h<R_H;_Jpi@w7#-T($=z-2SG4+n;Td*|KW5{nkO-qq8to
z2=+-2-2M}TwqKW#@jCj26v_Sj$pPB0c7&BQ@K`viGJp|mxtWs(l^%a!06cB1a1hv~
z+E-M)n;xvBWr6CHgtpslQMl+aN@cf-84qW8%~MEeV18Jxn+L}s1tRs(8bxWC>QT@b
z`cxDi*E@}2l%^#VkGF|PSTo*G0!5ae;G!(bAZa~D^lpj5LAnRE6yQGJZ){Jm3QsWI
zs<o%*7Y~;Zo8&gvMd1#dsp0Wuw8<$tk>j7@O|sUh3?8;+JEj#m-r=vN(e0=GW73W+
z{vyXT+RVU39Tdw_Nr&v8^bk3I(Pp+maa!;ABGs2Yh(sBb%WIQx_=n~Db5S}$`#IEK
zl)Nr9TWdHoMoX42a@<op5ly9KwB&V4@ftbS(MDBqmr5aq$reG7Y>VWK9Oq~&yI~0%
zk%d(pXtw?7HcbZfLxAVVu?`#r9H!sMag8<)!z5J*REkW~kJ2yqPvlru?T?iIf?w%a
zTaIHA0qZPs9HV`(V;^$ckIJ^(x1Wyc+r#ZgaP;qWGtGUwJ*u5`t}1)h*iq!z?+)iH
z{V<P_<J~YP!}?wAJ`>3!jIZMdR6|YgQ+9M~RJ(^{df5HV^=TXa2jk&IkFoA<i-JGe
zJgieLlq}rlv(arHwk|V^Ry5zxc-RruX1di{5Ve9}AZk!8sk0#rsfQ4mZQ>wJ_yETB
zLxbR2TBhV}ErS@Kbabw8(Y!-^-98AeMdahnaG9f-ntQ6zY~#F>Q1Q6=;X&|7Z-LDz
zR)DBzL{jm%*%{S-5o2A50w+^>^no>$qD3(}AqLyzk3_Z=^Y%eCZzs|@DLmEsx)ZWH
zSXbPDw@qj@sshq<Y=@Y@wu!s&{RQ!z69Rbp=VSdgVhcA-d;xIRJMct!wPI;?4Nq4z
zSKL~I90caZtrK6w_r<R+F3mo)boilJdERpmemitbJZK92Z=LuO{+?TypIdxn_UIyF
z6BMQ(K5oOeFXP+8i?c_M-2dS0fu)0U(+@0)HVJAIJWrZM+7af7trKZ{i&#lZ*K2D;
zrb}RbwRIvF-OjesC~FXyQoyr)dnEnt*<QEV8%-MnBQTqaHv2&5C;GM_Zy(~VmAs^<
z{n71vJ+5kZAKD#=ZWr(x)P&#<M#I})Oi;KV@WqKp{XrM~W>3i^^}*q2n!#B?$wh5$
zjqbOj&46c<ji%7%!Du>BBUd!0wsX;KjWZ0cFhpDGyCczUX(sBPQA9hk@uSi0Y#WdC
z#Ds|Y^x<ecrcaN_WF*q<@o4y-8JB2~e!d#r2KotK%}`q!8z-XM+H!VzWT7TO`y0{i
zK|6e<O06m0O8WxJWk?s3m1-eVL3*zAv2ggLi<5nE%Y}qmjS7ZH7nQzk0?UWCSXoI?
zgg-nL-8O7jAX<`*)uY=%2i>b}Ns#1wtZ%!(%2hO?Hfzysx_3Le&6(&n;4iRi5pBr+
zACGQh+ePH+fe_sZJhXNQ_OYHH#bSkI`is%DdRB{s_ZGCd=@!K9=MFC}Ax&cG=vPI4
z#GMq+pE-8q=!~iJ^D5%)kL!4BzL>4#$|%m~`d%iHz{^E`)i0wk9E!W)mHQ$x#Q7?&
ztR9MUA>>ll_c_0);+`I2<d3WPc5EIXC0irpO&E09^m|QpdP>trbRJN-%su-i2|A?0
zdsG9*`901z-C}s^DftJi;ZHrGN?RpE<-2l;aygMrro40+b=L|gsg_O^%DyR2m8+yt
zc`f0hhE=s#@v9ZLSVrZwOeU487R&j3pga|7SEW!u3_8vE<y1LQC|BKFwVF$M>2$J!
zQdax)J5R48R{ywjQXUHY8DKnEnabGM65{n_6MQxnQkyDXg*b=dGuMlV)dy^>>#c+#
z4MpSwaNfgl#NYejmPxDoG%xRT!*{)xFbXeaWw+-LyEkK#s-E?=95Xg!K}`*nImG1+
zjaZvEG-5#wjU9;78yc})ZD_=Tl1<2*^7jKY2JmD0KtHO7?m-Mj;(i`6e8YdNasy{p
zj3a^Ay}=Qyyigo(1aQPECltrYPuqM9p(o@ibMDG6tZyH8d;|hjL|5HIYvVYVFRbx-
z@SzEU<&yMzZfhe&x7P6MSR+XtUlefkK*A{;%h*$B)Dn{Ryt3^f%yo}DVQnL}SlHij
z+xH^dMor!3y`=TeM9~c{2Wbz=`q+AFpiMAnYr#Defa_Yi0FL`&JL=#W*+Z6L7S87b
zuw6?V3vMUgIWjl_XKxz;$9dH+bi;)%XAQ4=KHG)2Yv~8nT2HU^z*@moi-*FFE}UTj
zRlw(ztz7Dc@3RfG`8kf-cmbW*%TJ4+ce~+2w--i-%eQyo4c~6-{{E;NzIVxvy@4DT
z=TW21@T@~v{sEO`zlaDdVq<uH)ad=zoq;yp0aM*S7XonITQ8GuIf?pmhKInGS>t*!
z2qQY0Ldu-i%(lM!jsULS?J4Bo+@*^FShJO!wqO#d8E1GiF!Jt<@=F02J1k*zmYB5h
z1h@Dgr^m}H0l0{5J>c0_?Ek!tw<qMJ@xBp&lUKIf({8OUE?CPwBk{rc!LQ$G<7J<0
zz87}c-%a~{%C4yPn9*Ac2dyR7^ANdf%U3g_IN&k3emA$TH(k6JTPv@kXuE9N7NN$H
zSHp=$rzuLgLr!^z<<J+Y9sJROwbfNjAkst6R;y&kr(rIS;;~))!?`A}2za&b9Arv4
zY~D#>9Ix&snjttMrWOl@=Hs<{B5*`aF%}ZeCwcwe2pqwwMz`dgfs0?V+x1L0ur;Y$
zZ;u7nJKezlNVvj%7F_sr13QzjFZ`$ld$8V~rVA~?4&`@xV_NGL-w&?(KK0+7s{Kn{
z-_i3pzrjO)77WF2Z5$X?8ir+i%ZBNl&a{2)O<TAC7cre_ojJHip=kr&j<^tyoXfr&
zb$x8Oep3$fygL_c(>2{_o}b7E;UcCR-G9#%g76{JhvxeU)V<Ms_n$trPF|X_+w@Ey
z8t!S-r_s23rw?rd&+iSu>Gw@((qdih#}3Zm>X|;Y>^o7{BmmbH-L&m$a=!&@rUsfm
zG;cfcm&RvcX!_7FJMOn&g42hFc_#>CM~F4d(+6xko%#cQ<0wiLH&;N5{o^v?I+~y8
z=|$^fVb+4LAYHWGRWHKA{cbnxTH7z3t|5CuE&lNYObw?#>?aN#?7~g(Di=jU8on>u
zus&XBT&<r4R+<__XDZaXzjr=h;XZ}!0^J{Oh<r+9s2IG?Aq%c%P9e|K8epN+S;i|q
zbWp|qX4hdG9vK5P9Z(AEX<zHO@Sp`_=iyR*jD?lnt^5v>M4lCQQdHbl<YF0mbT{e0
z<+&x`bC2nKSi0Z)UpYtt6{&(UA@&yKA1T-Nh`8fm))<sq{2N^VW4(i#AAv#<A~%)-
z9=t}(AYRuGo@)r8iEgv=#>h4*TBphAHuR2Q1RZXpNzE(yNI$2cAIg<&N58Ke17LLX
z0pdmh9!l*{?QmZGM}6p*I_@b>I7a+1oQD9A(cfjnb^7z6RiX1jFJ3>8E>wPQq_(tg
zr~51e=oX{P@cj;AERlS3FN$Ip#>U@~bRLqKu4Lp$c3%|b7qpEpBR&gW9&%S76-xwn
z(d^gWM9d?Wrcsw3%k)MN$;Y{p=Fa=H&OyI~IL2?_9jsiY({y3qoP+)X;^b&cmxo+3
zKC*qzTkjxFq1%+&`u7>c5%_nwApQG?_V0k_v3uz=5}qh)+}QII4*Uj4$_bO}r2W{p
z%iqsv*bmHa0od2DCkJfZ##{fa{w)AYduIu2@V;+;6R^zNE7;cpc8!(Ax;ljYsQFzq
z(L8=^e}huE&9m5->NaPBZDz2qq;En1OONkZzf%k5>uKyA6+Ee3|GpFZKmMKI=|00h
zgFjweI(l$!$?SFLZra~+<fEv#uYijXjZ=h&_e$@G@0b|r0cX7QgjWI9TKLZM9Nl~S
zTWn|5779$PR_h|KSSF4VF3Q3A1Mq_ziZUs+<O7X**@`bP<85O3k#OHM@zYp4BZ7(=
zAq`Aal!7Aead0d3{v54=B<yw3ut){=G43VY_0e#vO+kXIqe#B#Z7$rH<fIiq=u09!
zyb#|6e_elg!4JXG`&>@c`&?Q=sSkp^J_?r7R5AV1<WIUL*c+l?W!00`GARZBkp2jM
zOBB4|R>FNp^oia`26tYid4ZASBDm|EC^#(daB-!LA_vqb1bclX?18$An=_Rezx`;Z
zNoFVHqc%6hwONo75{>T$`HtFkDhXsR5w)>oh-_oF1yIM)B_Y$V2HQsLluPvc!&q{O
zoXo!#<WWWOdNa6Y@z}2VC~~H#oyBKlJH~`mNs$*$x;)MCV~p{dxaX!`3x+Kz<KBBx
zO(C?*j2ew}?v=uSMSZ7{jd$%jH6IVM;h!ft775=m2;F|8k7@UV>88KRa$}AhguWbF
zaEyT$^q6w^*KV48rbTC(l4gXGp)1PUw_GF>>iyD1gyp(``MXBvreg9RQ_s=u36;Vv
zwj3hYkoE#HPFTnKHb}EykFZGnU@YMxXjc{O8LVrAw0l*>6nnqK(`hI=TXEJIq!Zrv
zOe_3rJUt#CZ}-rP8evQ^>U%g%o`IV@ld1PjpHlK({A9Ph{rZb}=m#?#A8gOh;fyw@
z_ugJ)>b+lvqsjK{VXYse8Qz;rH~i~xv^ie37w4@tUQ_iOzVM|vwMM45xC3qabpzVz
z^;>tlUIpsC|FfU&q7g2%Ugz$|yz)H<cg$oF(NZ0BdEL4VzW;j;e=;#^+VegF*=f%!
z;tzPXJMxWN<>6W#Ps}UdQ+7)=5*SBM+6W~ugeSZtTtAg}({3@B^5_Y{Od0oND`nr$
z7L&z7+Io+z;3e>D*7NaRULswnAXO;kCtRdq-~rA;8gC7n_c^^vHj%*{T)%(^3GvjY
zU&Lc?ekxJMo1aN!G<3a*H;4V=Bat~T--pc807&A$s<j5iv$+qbX2S@5kn%F9E|$TQ
zc$u7AO((PBQNn_oNG1viWC)q0qe3-9J&?~<yu6pE-lC`R@MLPnE0l|V;C)Wl%_h*H
zsf-V#*h(OO$*X2Ecp9>bF3)%O0lh6cN*`<*^AUaUBIe`~`XHZi6Mi*C1*GuoVAfA2
z)46KCn8NdcMZa3M`oKs36w*oL$oU!HO}N!El0$ISGV9@CLoX3{8#0mcFh1OTww$jZ
zjm*pC^LR)V{eXnALf-eg#sR%8I!YgG8uJl-Ksih!^nvR_C+Qp>hs-CT(_}g8Rq};O
z0<UZ4Q|J*h4vMK<vgoDK*@BzGn81UZ>9U(n7PHB$3ojG!MY&=zg+9O-fZsxjW2&6b
zRPY3`3ygRbr2DO4dRugqKG-zoyZV6Nay)_gl=`4g{$0FB#|*>xUd5alhcDJUS@<Yl
zJ_cWWFI)Iph|$I1iyyhb$9tAH5yN{#=g7tmWRt%Z3u<UQk9eR(BW^0TXvBdU8Xn?{
zhDNNnHZ)>E4UGiil7>d?fHO2=K@E+M12keio}m#7YG}NHII58&c6b;Xv7m;=vxv)D
zG~$MgMI#Q>&^V5GuAvb-j0}xfP(x!cV#9_;>|(>vhy^t?wj!2n(}<ZKY#K43hQ`|g
z8nFvkLn9W{(0Bo{ZzD&n8!|LvK^@e^mFES^h?SH7qdf$UD7)%~iCF+!hJHn~_&{s4
z*4XA~UX~D_zgk`*>w*m;3V7kX@x&ch&x=kQE;pOBpX2=AcLi>~91-jILvwRG$Tc&z
z5xX4=#j$PD#u4kdLvg$qz!B@1Lvif=yv;|f;|;~}b^u4LV-3YoztiR;cGDD!W6NDO
zj#$SSisM26N37!u#gW-%^AWqs48`$g07tCj3dP}l!R8~@F$Hkku3{8B?<O4L<%89=
z3Q{;a9?ouMEVb~(o^P_yBgR`*`M7rkj5>CwIuE54w}I3Vs{K4Q<*gxVg4`7REGraq
zokW>Wg1R@ZsFm%}LoztkYm2ON*+7((L<~pr@*ML29>IAQPV<^bQLNLsEPr$EvA>Z7
z=G^e(?r%zhql*6vICHvMzsU6hIbY&9a{aCrC&F#IA3hfNbQDU2y*nP&p7d~TCiU~~
z9-?W(Ko7VC;NzSI>d<f(zT6+~5v7;O`>tLFyG9`E`;9T+<=TLpJJZ71(<4;ZyN*4-
zeilZZ)~eJceyxMglW#?g=n;KafpjI*sdFZu7T?ugjWQ6VS?QSK$M$#h2z}=KCAw!x
z{m;i92D{0}xEun*y~Q!n8Jv@M<B>2_udiN1fiX?<LmSr0u_C@WKks<j!WYPylEQJm
z=-UcTY7mb+d7@;XmVJLl;*sCQ^+@OqH3(p5ZzAS-1IvzKiql{pDT2B!<w~{iy(M3)
zprmK5^Ede08SA5Hd-KF=(D(kQWL@EgF9GlgcyFHgd-(R=&zNuZ6<Pb2zg_%U^KDIi
zyAAFBKH8o8Iq^*+q~GaXjs1w1K#mrFm{Q|{YHR<DTGOdhO3}S2Ac5Bl>6t-qFGe9E
zyW(xG64gUzy;7}3v<1rMN?AvhO)Q$;9WdYPT4&pFR%d=kxhBZX@oNV$!k=*@O40}a
ze#!cs@-CPM;{V$Y$|X|8<q#gIUa$FH*Z6iK9{g=bHX}N><2?H_Sl@n%`x@iyQB*Tq
zL&<-#g*z}N_rup{TM*wnlnD=e+%~ZW95ikN-zn9PpM`-FXS;nGJTEgH13_7dB5#oM
zS$2ST4M!hAgK<1(e+$^Y#KJfhAg9K$)(}|u8`TuXH~LLwL{iNRxz^u<zQZ@!LVu+^
z0r{Qs0slJ7fSk}-^F+cU>fx7Z((Ap*kNG8xFS?7IPa;lPsg|dvR34egYoW;$IsTX*
z*#9j9_e(T~i$a_zrB`jXOUt!W%Q*I-dPKNeve#>_LG}CeIn6HE)Jw{aF{dIy5$EPL
zD(#0?e*D$IAH-Kq$wBAF!?Zi9=BGoj$Csk2c!Y`<B{kJDlylyd5pX^kN{e#qWIsKN
zSao0dc;oTo#<r+FaCaLGX2HGJ2k!G0TpcmzZhW}dfft`v#YGIZsa^0<VQ`|{e+#+0
zssY1qK^(OkzKqva@eEi4CPmpWKJ_*Gy5~dS#RxC8eQaiNa}cXLVP}tH@#fQ#OwUJ!
zZN0R-+Uc4H3Or9PAwJm657rEXOplv4Lts|iNBxpztTxZfh!J+<?1slNGaef(HLIo0
znI;;uk2wCBkhWBI9=aqN4EHqRUOhA{I6Z$Ob`=Fz%4JGaypG4!<$kc`vlh$pZVl78
zg1Ay74a&!|_}+!MN;hnKxmHD4Lm%Y|^n7y&u>yh<>lb9v;ngzC19Hq=#{T*x2M?Q6
zTBsvPI+5>FoWoeWUbjJ>H7XiuUyeDD;ZE9cctH?Ps`S9o8zb+*wlzKp#~FGwrNV|J
zKQy2HHqEJRnp9P;IL>ORzZiycUu_r|tzSnX5W%oqJHgj)V;*fcD&o-^_W7@i-wl33
z%-`1GD{Q<pGxPjQZ#M{hf-Tc#JI1#8ois?g**5V9h&d#%m(ug0deH@I9g*!ra0iu-
zB7grA+IPqAxx_PzYC%GHc+P@?2@i%cZhcvVSU!5!3Ewf*n6Lbe&eZ=V))7`Zyw(eS
zdkk-qEn^8(!yeCG1HIPsO)O`$-ddoEwzalc0vf%&ANXCi;qiDY=3dbTkNJ4zvzQ-6
z#S7jH>9vY}U5nmh5Ysr>$hL{Ui*bkv!04WIA(y?vMkr_XxA48RFn@^jcUtv>2U*Uk
zei*98hQ10ASyZD3g6KY|=<b0o0(AS=UFgAuBNdJ7Qa7&tbrV8yu|3f{ao~&XMQgCC
z_<mb{m-h$;h!vm%?Ls5Hw5O(w?|@8YrUQFm{m58C|Cq!8bi`tw`hflJ(^v-)4dEjV
z7h<5W;Oq;w!-oL2g0TY2TGsR53-Wg}{<tCN@V<UGd<@$5!0^khtout6u1EKb$Adot
zp04kV#l%m^pZ=CUW6KtciBt}yRx&uSP2mi<oXS)xDBg~&2)CTf1rk{FoK5?j-%{fO
zK3Np*rAYQl8S6~!I@UVX0_l?1B_F^B!{OVaL0h%py*t%T2Rx(G<D9?K9T)MPn=5zE
z^TE^5#cyFR!=LS0;}&H@mofkRmLqma+BZ?{Y-+b!mvb=p?{iq|h~G&%$i=_6aNcXt
z(f)Ba&TXyV#U#M7Eb^V-a@u|!cWK4zBEZK!_hs=-W+BOn{Dv0os}~&Uj&0pifBvJW
zzNnzmzUmC-`5eaRKOz}BO?)+dM0hTR;K7UuP?~uqBJKmK(GPgMe;eHFavyxWMSbVy
zx);s7O*QH-VNRAP>|QeSHof(F$y$%F9M52$)oralp?$sn9hztOJ?LBdU9qEe{z33}
z(N}CE$I*|}rqe6~&(?_xcREh#z|p1B^c+eVmJS^`@)bSS|9|e@1wPWWtP?F5gh4^W
zEVAvO7@);bS*)ZxJv}T=eN|uGuOHo=>83%d(@CXM)47zXq%WffvN%V_UF2l(a^`Sc
zwgu!M%VNOGLFC8gH!8~y5p!H*M~<?6yd6LnqwDJE5B2<?|9h><S4mZOW)@DvB&qst
z@AtmX`#k^WF8O0Wgrlpb6%sRSiYqIZWqqH^Ysc{{$p6m#vO8$@h{*ikikbh}i4$si
z^g7<JanYmLQ@=Gx-<rjOq3Q>?0hGqMW*2GPE0=&HFi%FOd==Jj;PneLUH>AJPrkk1
zH30T1AKg9em3pkwgJ<Bga9zwWZQYQ^_q!ID5Y^TDA8XhA&EO-yl`u0X>+r1SwShhV
zUV79*WB|{>_J!-wc+?#GuL)q9ODI!qkGSi8ANFZUmh=wU>wYsa3v{ygy8jK&dq(f`
z(C?zf>*Uy-`gxatSa<+yB)JVA!LbBvo)8RZ42u#l7opK0C8UYL$xB~UW(}U3!nt>B
zeB{Hw_YcUbX$?MEX!xC=;cBERe6qg?o+5S3{ttZbe=By1{}pyJQuGSyg@R<m#Ws{e
zRim;SLfTzKg;QLAH_rV<vp2G67KdgfC6q&xH!$*4_+B>AtkN+s-2rNBL1g$J-MOER
zJNFH}CmU>d2K!*oeG4W>T>7afJz|IFan@7;1ThCgMKFB12-?o-{3M>m_fpsH`o{o2
z1=O2b84`b(P0Xz?b)=7EbA{!Wv69QMRQKDY9|t{VRj;hMi<j(SJH|)A53>n1Ff~Xu
z67vpUHplraRD-}>WR4Bb6(0URk(<~T;B>V0tZH4!;DjRhDWBop!#~m7OR$`OFJGrJ
zJmdm+Z8mX%Xd5rD24rv68zg1!+W`;EO5d7`*hx&c(v3Vh-^xaF4fE9VZ0}eSbKoBn
zoy?5q7a*rGo|v1vu`I4h^r(}og1_D;Sb<X}@=&e$??JY!amq$(VrP>tph+m-l;w%#
zK1Oy6K6Cd`dY^gchapG2dr9;=x<NyA!u57-c}`~)Vp8pGHkx&7`)2ILEck(&XG2|X
z%xCVBbF@;XdzZE6G0We#jxrzOEs}SU-UjL&Kh5(m9CU%3JVxF+{c;WV6zo07yl|m4
zd%4zHQiVj!d!KuL%yA7#&HnweJtrH-W$b#4!+xTk6?>iqy2kb-_7;6U_NE$IRri85
zn0gLzLFybZjI<E2lGo<=wtqZ}+b9NT_3LriX4Lhiu6ja-6KwX{>kzLKbKH*A%)t-9
zZez}SK<J_f{WV%4ViFoN@AM4BwDg?konyxQK6?&E#AV_Bviim+VbfRl=s9l3WbU&F
z8<9OP+eYmdr2fygEI+>!_6&C%bA$QQlHs&4KN+{#OFw?Vx#r>KJ&%v~-TSoE>z4}N
zT{{<JFE;0#YIRmt*EsW1FC5P`@9?la=XC7)jzMOrcfj!s_LfSEw$Iq|k7qAl@}FVW
z_~Dm&_wdirFJ;CewSMfga9)0KriXW*`?kHu&Aga<yzXWGIgTEUjQuNh-1;T8n}VD~
zTm|#(YxdpV_3gY@vqRUu_wwHSJ>wq#95-k)o(t-@VT^17IR}ws*747Jk84|!oZ)Et
zeemC7Ud%m~1OpklX5Q=QclDgJGCwbBZqMy3T_)g@^6sb4_4p>9ZSMPW_^0B|6-C}i
zSMx4E1*zek+jB#6PG_R;9PdU(PP`5}7w+R7aWZ7?m^!BHYO@RQLRtADHE?hp{KA4h
z)f^hxu{hOtOcRdLecpV6$L;!<>t1(n&-aGhz$=s-eg?F7JX2MmZC;&O>q^gz`6d!@
zSLQK~=AE+lsq?y0lYr9Ajr*oL*0WgVx<_Bh>w4DQjO~5@y!V(HoVm91Djx4!2PN0u
z1z!us?Hw~$yD@(RMlzn`t%UeBPhvlx1A!ucTX=a>%BkpbBB1N%Jn!w`3D>Z9tQ}Wr
zA3PaT0^Xy}dBi^l*~MC_(-w?JBp&sTudS@X(?Y5vumHgPPTWV%dyjt}+WW8oOV63g
zzAWc{$Uk>!=34I^)p_EV{WbqQm68wIfTpoLOFxLbr=0ikz30(AB$jm<AK*hm?B#YY
z%=miM7SPFapSOndI_g~L`#vvuF7G49aUUG(=S9z@Zn2}r0^QjY#JEOm>jLP0m&XZ3
zHJ*_MFC7#BP=y8z-H0CY7O_7o$3G3tW}k@O@fKiHb;#L9&f)vV_UPvH(E=C>j78_0
zW#{YJ9dN#!)r7Lyx+GCkYQjZc8U7(Qo=5N;<(KI+XPK2guh&HFNy%sP&jHw7#{F13
z$LKOrYx<GIe2ZPzTBzC6UBeovz44Jdc&sD3BzjObXYhP;>~UagTxXA|v8n4Gh2GF}
z%;J1^{lm}){Bwjy7%V7#rhAUXT)z#>?VocA*Bd!2wNU+I%RuC!4KE`fO#1MdcX%^&
z;YSk6>m{xN(bWu3se)kTSbvQPv;K>~vpBxCx;nc661O<w&-lGt7d3T`K1A<&?;iSq
zU_Cb3W4p1>!TP*6VUD_-M2R7&>iZa<J=S*xj@$V~v;-4l4#Fqk?e900-*4;Jh|j10
z9`ujSO34h#Ef*$@VoNY5bXV3_XIrX^A6#&+e5G#D*Ic_FK6piM9~u3Ax=PH;`)`?e
zP~Y<!Xs~~bC@lp}E07n_3GV%LX>zay89t*J_J5K4Up^u35Bscf(Dak>EK>?c9%tU`
zlh`9eKFd_`F@cpszuK~yL+H^@(zE<mvvhS7`su#UQw9q~W3S?}v0HdQ5g57}|Avw8
zH;}H(J--<|V)!wdC5Rm+;_?*z9|1oZ{hkAdYO&Q3@S^_vVz0A<q|mRyVDCEMyh%OI
zBzRQ+{Qv>lOHw=<HbbcYkc+COqq*ioao2#I#$980R{(t-&w<ky6^bxU^Zon$?;%yq
z_s74{p5G&DKV-jO?D_sx(A(AhVNC<LxJ$p^w)*}mo@?(db&heaeAhFUNB!@;v53B|
z&*wAEz29ZOcjF%WCUb7@_<r1dFVM%11p-LlyLa3V^Lv>t_bz{CzVqJi4D|MD0_VXN
zy`1=ZP+cN1_HMzUsZ=uzniH8uE+|EndcBd$1*xOybkqKrmA_Wy$C~}FYd_A(Uv2rZ
zVvq8#b)FIkmizkWfz2lp-~F`2(-Nt<m1u4C#PMKyISc>6s`&SV;B>lp?mSNUl0G-O
z`<ZfX>L~I4Ec!<q<}FnM)u$ER<~e9qjwbKLpb=<-vSd=MKuV9`w#~B-q>h4Tv}Tr?
z`rypmOb5aVhXTVKC5S{F4Fa66k&6fO#94L=_X;M1*k`13>GZi~rCAToLk_CBNq*qz
z^1g@!mSWmD^xVE46aoGgTdSy*iQD8?QAt^Ub1Vp6jeA77%yhHc)L)8mA_!y>e^TFb
z>_?xW<`8{1MI<A1{nEMw)+=6m1tlM0^#}^hGUg7B?&Z0e)j5_Xv@a_HeYlB>ebW*~
z*{tJz@rd*2<DuU5=G*U-ap?(e5#z4YWUpiWfg4!?1kK~{_<4gREwaFH(Tbc<1xOe4
zfT<C{ajWYTM+j=@q{&xe+(N$Zxh}E3dcV|yBEmUJ*>Z`y<v}6#8TpaAPkxr=M-;$z
ztl#;sq`pxqRm@67Y+1idI+cDP8Js=NZ^Q((-VFjwQ{of)n$ACYmRzGk5V!>pbTo_g
zJ2X;{U-aR3%YGEztjpxxrQc=yzGvfIgqJQt=BxR9{2|AGl3_8(rwiF^A*u)PKtZ8T
zO;PJjP0g&OrjplEN5gz4l}t^^AEk9175E)sU0$K@w*h;LS)XJh$VQb$E}t(3a0R5M
zTGwU~gAZ^U0C%f3i5|N{#<a)2Z1&{lmW&xZNbi6-Hm_C?BuM8nSVM4;)KNt~LY+-1
zJ-5~s<^qm(&Yp7~dWw4HPFD7L69z$);##>{T0*W%2JA)X>%;n-vF)Mu?KFMG*~WCH
znhS#IiD2JtksZhhv$0z@_Dj2;d!G%WeZ3z0*0W_!g>TPx8R8d2xpWp2(X4<C$ltLO
zmZbzZdK7GJ&-tJt(E-)`C0_V-GJo1mrJ@*QZsnY#<KFsD)*97vsU8NYW2s{SY6z<9
zH-448=PF9)Bh|yGDsDq*@c><DX$iD)D6=Me{ahBWR>TxMps9tS{*o@$TtMtUH~w4o
z7;pZ$UVi~>N~!905QshBR&r|??suDvI|SPX5uZ=2>bVWR-{XDRMi8azl~TDLVdm25
zmi+iW`9YaaHn=Dsi6ICT2oNsGcgylacClfV>Tg1ZP9W>}fS!lWa}+Hl%@*rRW5qU`
zR<mh>KOor93RBgC!jw`<$`8H@YJ4dgxNz@t6^$B|yS01;k@s4um;HP8xPNFyVvt0B
zLP19Q*rMF|HQ?R{opttjGDwz$qf1P*-v8^wK#=pf@bokqa?DU}_h6w=B!iX{!b2^8
zgT2)7w~47zI#Vs9GbUFcb%OJGB9LbZ-jd%BLl3sLv#SW5Zq6E$y&@}|^A<DL50cjn
zOr*n8_9WxU*47IETjmU!hDt&nCdbIr-q2D5T4aaET}D~^DLtO8KO+9~WZ&FMtlS%Q
zhk^|b#tx(2>|pt4u<!Vfi~MgQRvxB?nOS;F1?{Y^p)obRdWpnG^}8p>$fF$copt=l
zVOu@cn2jFK(8>ROj5q2H4t!a|zjprA@h@6jR>dA^IhaU*1D9av*RsUsqj+IoS#CTd
zceg%Dxf@=)M!B0aXh8PKvYz(~yJ`<8Cpd^#-y7w@5a@PsU7VC~a>E`AFA@ew84vCv
za$d9bo>N;(owe&tg&L&ZDt3nD1@heEcgy}v&F6G7-Wgo5h{r|(XuG}oQ4%m(u6Y5*
zD!&u3WlDVeHDzM8e0rzu@d&7NxlBHt%jF>k!Edk14{CGd$>hZRNRHj7+yQ2l<b0mR
z6PDy7d3`sKAzab(cH>t0sqAio-u>9AImvNTnFG-$qjw7*XH4pRr@IQ9hMJp?!&zbY
zWb)odz8XcvLWIQxF&>)?>|EXWIbWugf>Jrm6&qoObHz9A$Qx61DOArH;M}RtoKPND
zQjO4`GfHtrow>!iGGlw)W%tbFR51!GjXXdKYG%(a$caWyjQ=S0!Bi4BMXAWsXQ2ol
z5Awz1TCNG0n3xnMoKtiq&yab!@Y5czX<hR(DVj@bGn6NCUQm1vc@q5r*_Eryi&7qV
zZxaWDhZDb|beM@j@;Ez;I3}C7dePR)wM_v2eaH|2=rw7E-Anz-Iw1QL!%hT$;?{Sf
z90pM>tX9H?qH!*nns`g?Tp<TTxHeoc;uE)iG-Z&$uLXFH!9K}p?|GSQI>=N?)q1&H
z*nd-TB-dpS4hES`#cy~5hs9^E$umEw*Kq4MZdnJwhItY-`8~*AY>8@Jq&9-xcPBFS
za+od^%7IE9#LJoaj2>`%V4_jL`bAN`n9g%L4U&<0%gYb9lN3;N%QfG7n48mavbId8
zwLR_pTW?PQeW@N9s_>&pkTJM(`#&o>KblH5D;QL>LB$b53;+<wN$MOZQ$r<y{aJ6v
zX(=|$4Dz*LBA_aRtA*hkeKYYNjlS6%&tot`;-Rl~`%xn*0$PM;wpQD-@;+t`k38(n
zVYU{O@|AR{URS0&5*7hCCyxw?)26sq>S(qhQ^zwLx8jbtA_qvF{J0+AnTFp6Z<Bd}
zfYLPq-ll1F><dHDYV$0$<tLXs71B?jkFDZ`n}?uFjbINk$hRMia99`hm^L1ibxy&S
zp-l(<dd>7A2<-}V`r))2bGi_l*^AE~_x9pswh~rKB|svvoltmN%=10U#xanmJFpH?
zhoKboFY}?0{xAbn{N9WU;jGk2h=b=^^E1eMM5xW$LThyuhpe6C6CV^>L)=_XkFb)2
zG$#I~p2rADa+pVLI)rwN(*96$))w%Z2LjBPMUBVJu>jLr2lIL?oqr{EiIi3w)l?}D
zzQT>7F`m;P(VxhEOnB}YPq#dD0yf5cK3%NPXp&BITN9<JeH_VNJrg7{7=z5q7UJM6
z|IO5cS}v?)!v?IoQ!GHAnkvGAAV}kSY6`XJXII-D7~fMT17}|u|3}(aB$2T_3ul2i
zGQ_qc_mBR><2jj1P->KOnW(C408Ykngp|N!A!Iy`%aG|f<G>=G{aHPS$rtXicbfcj
ztf)4^IR(fV_hVEAY`3_bxUcRv`t1%>h%jenZFaudTh~TV0IRNM(rW6Q2Zh|%gPK<`
zJ8u4;cxUhYhuK^SNh0bd#1W(ria<B@Jg^|7qHfG{2spS#;P4h#z0=VT{6WAuwOk=v
zD=NXv1?CSfCNJ(&8Tiq?4TTS{;9u4sB)ot)_1}B)P8Ve{1`0$ITDh}*w`cRieB7<C
zkG_fDn>Z{Q1K*^N?V?}<_G4zfy*L-ntj#W{;L#!zcR?I|?i2t_VRX5oRSZvwZwj&<
zU!RL}wCL}6Z>dV5+%J^(BBSN~c3!7^Sm3R_J`}}0M>aOZku=oLv^afE;F&@z*X~mM
z74CwyOY7p#(E(U!iL#Eo4yo)ww-WMFI%}&|7ufx08iyln7pWlfHhmhX!r*27Zkyk$
zWj+N#Hc(D8^a8$QopL%)(-(y@T1;qG$pmw+oA0Fz5>zI+`*7&YUKZG;ZqQyrj}?4l
zZ0kppNm0C0=`+X(oSZt*rqj#dqRpyD!_a@jOs!TgRg{xvp#IA}F#xJ_C&lW&X5Vc3
zw$VZ^sMQ+9OitTIiAo)2y(}Bi?LOX|AITC^lXAFke{ln+ptsKJx$k_m*MFu(GOWeO
zIciG;r3uOBEK<EwGH0)kqFKk9OgGyr5K~4LiA)n(+D5Lvl_y~}$QMfGVl@<uSxBpt
zSU6U$u)$|)3XQ!WRxCnZ39PN+=F3QvS38$r5P_7xU*A9ZZjYadNjcZZSF&oU_|lvc
z@(waaF2ZHUuXaA{U0)~#g>*HWj%qcGFP%Qbc{liX>=(t}0MV$zw=8cz0-rtXIL+o+
zX`RwoUu(>(aDB^6LPS(bGE)#7i%!T6ICt)Rj`p0F=(%_g=KE_BFi{}U2hJfnfss{5
zOl0Zob8bB*GSzfYDAx;>LP>NK4cZTdKO1bg`E>_i!)dcgQ9BDU^6+G=T!w*ct`)$a
zGdwml@3(Wex1JeTMKWpZ-A1Su^zh`*ALxCw^UEIIfQ28MN9+&i_6B~AIX%2UfH=-w
zNsHMKj&~SFfvKBIc(^1{O1H$7%diToVN8qt3!#>7c%7Lx!WUw=>(OK>9RQRFcQrcY
z&ReN-s+iB7x<x>L$at6mz7u&Y`~6YhHg#_q&V?`souMHKs_;D7d*1vhrAt#qg+d@4
zo|#1m-KM78ReM}y;P^jiInimgE+a%pVi1B{?C@Wc&WUVLwyZ09Oq;VFO;ig(HmqmM
zVNsF1v8Ld6C|jT;Kgd!Y-sDGe6Eb1`MVvye%cK05nhInN#Qr9~AHCDVYqg-9%NL_U
z!7~jK|0qONk;k45Xb+WZk5s*DvxT5s&(=!0a+TY3@R%KsBj4k238wn(9+XxVO*wzh
zqkr$s)l?x@!`?|NBb5qI2po1A&k%cw=RrfRu3g{G(}}AT&A@&*i&lTIoq}ADMga+p
z<+Ye`*SE!G@U%iDEEHhWJY=3^)}{DNZ*FTr0k-XQHBx2|XTDSGQYB3UHr^ny;>}Mc
z3<}u-5N=J;Qc+Ik4>*kRC*=o!sLv#vE@sfZdvu3?zgjwo3XO8QnD-Q-L*d5;@9zE>
z?cEB$!38b`A%lB5Cp_7J?UBd!O{X);JJ^SNxH<NNJUm7Mr|@-d+Zn#U!3R(H_#jh*
z9j{QRRkL+0eIZTekeU+i)t*gFsak)jDPmG;oX*z0^{d*}?K3q6YMcwV52F}*xG>&B
z4|VLbuv|`)`ubyX__-4#KBxKr*bjV-=m;?}X2H?qeYnLyl{3b8a62mJ@VDDv<zz&e
z<L5|^vY6u3+G2>nH>dz1oY)8m!!cu*Ol}EX<xy%e-(Kym<=cy`+_kfgSL|fyCr~y4
z;1h@pd+qkGD_M}9dvLwG<`M>fQqOVplSA1Ci!m{1Bl{<P@=;3{1U6!Y5ol7MK<Q?I
z?<0|Puk~f47hz+mNFmAGhxf(Wr2gRNWS(G?f`?*#u_f~)!CaUrCpYd~_ILvLQ@LJ+
z0xgEOG!$_BaC?gkUhE&no^|t0zCFv<-ov#ATC-woAh%-8Qa(L-pPNaKpJX7!YL!f-
zP;3<WCRT{4Fb?f0B(pm$FG-0?20|(8w5QZ@IqW1cFA=W#%%^F4?E^|@PR8uMQ3(Rz
z>JTSxKrkm2aE;_ttWK}44=6l=09C{QAqr|>^bhW$fRE@#f}6HpFMBQ}W&3)|@mc63
zA^l=iEaA2#{8PBe$ck<5>1qg{;b{&FR4RO1?%lb{Ic_Zz=aM61RaNoPpr{|vSDaKa
zVyG>+-tgW>?{+kj%w&Udwpz(XX#q)v^c6A3q|n(2j2sRVZDzE%Ve@s~K7stsh4pl`
z5Guy)$cL0ea^ZIr!b%>ipZu2cjEDLqTj1;)uk&n8+PC5$O;cA3bFw{opL@57TqUSw
zvQaiHsPWY-5%YmgQgRTKne<I@bPBzJ7Ja%WdJ}1Cbj!|*MFuXl5Oszw<!+A0Fvrj>
zJLiSdR3%)uCsZg2#QXp<lu^uA#Zik^`3k+x+kfG`GuT#+3qE)5v}hFh7JTopP~%yj
z(&vx=IO$>;Wg?LcB*{8D{0s}aM-+}~y}|?x(5FVd(;yib8q?Ba`h6l4U%(zx3KZjK
zCHwb~UIusdysU@y4%o{GUBNCh7-i>DUo22pLKCI=Hqu79PS{_<{ZUiu5<MS-R%&Pw
zft8AVxuI_`Xo2MAibciePU$rYbWB0Um=gMZVc7%i2pKhF4hwI5(&H`pbWo0p<xDZ>
znGqaE;btY5QKCq;sgZ6}4yi=&e14=n6VDw^6OHk+`aL%O={{I8HaB5Zk{L#t#Q@0x
zFkpZ*Q}m~C<ZqjOG}gb5RDgC9X7!oXxcxM`FJ%wWjed*$$WBMIy8M!zyA;m2z5J4|
z*fliiC05>U{JOU%U{TA}^SMH(;{}}JOaVr*<w%~p!+pmc!@a;ALkY<5*0CL|K05Xb
z-t%&>+eC$WzETK5EjmwvK$uVQ99~MmGmI)Wwu)onmHe?JkEH!daLvY5u~%vrtS8)&
z+uB~iaU<uVUnf1g_{#J9(QwS38m#LL5OIc>hrieU#H{=$=6w>sun+Iaz$7?Wd=Jgj
z_v}wi`a|Df{}&?1`Hbc_o8Q>aZ+u;7kbH}o+j!ph6f#n^P6m_je222dq9)4K*`>L~
zWzeL-e>eZR(5|T1vr8R(FBlHL5>LF;;n3uLxm=}?4I@#)vbFW)%gYGblW3m6=3nf5
zQuOguYM?xYIK3h<$jCex!bWdptC0m4ZUG|>O(Vms%+NO*L~s@+(%va^{AKuWte<PL
z-l#{VOeiXQ5kS9K3*;PQBmcsL@~_gV#xNaVWHE6OFDtu<oWJmc+AekKSVyE}UA!W}
zNo$Mz&<&42W^zG3mqj*3Ng0^QUCC3aT96YGc+e6@o=HZy9H54>(&;Yz-cWWHWF1Pf
z-(a=aaH^PT9>DdiLh3tu`^_%aXTSM=+LBB`G}@9L(C?7^YuW*IBmjn~3_AUYFn1s#
zM0%y{JhO)umb|&Xw^T;Zt#%+VOOLvk*kMGk6*+R@KdU{&_`jn`#XxlkAXIrT=Fdg>
z8J##f+GCH*MQK<g%gP$g2XRHcNDTNh4SyKFmvgg@Y-3c5Q#Ia<ALqsw>5Bt{=v-Wd
zAMrJ!>@?5nACiZ5-rD3g&eMKB4=n-Ja!pk>XZuQg%H*IZ(?B2|B}JgqIRvG^79sy7
z#iC$j%-A0jFL}Du{`nX&^mFUnc<7rA+VfVevNUnw{XR{ErAnq$tSaMHLm)~hKcc|e
z{-Pruwx}Vy7<qee_s*?cO<RohgukcZCeIdYwPG$(exITDG*t^CAYQ_#1n*+dsj=H`
zyh!$o=I8mvZXU@`Am79rG#z*D5dB~BY}ZBW-7kNKHYS!nA0mYZvkCgpyRiRCY&^r0
zIy=Mhr1FqFDMrHI7Ej6;zVm0Eoh02sX*`%yuESt*dST^iR$}6%8%MT1gVLx{C9VVm
zx~Y5lpuWe(kM_i5V7j4~#|$`r6G(<2^Q8C54wQQNia%}qOwY4!DStXv!ykIQ`|y0M
z|1!oYba)~1cwq?FV7VF=GZn=QollA!k@^Ki9(`^XWfwS&oPRlugeOxV!YiGyxt+T|
zJQTgDeD{MzV9adXI=LA>9$ofmP1_+E<Be?77Sh44<9$~3{EdIn<56(sl?#PpSgNb}
zqmP(jeM)CCmUsX^v0!BD{LOF4J(QG_FL@=^C(a|M&^~kH=e=j<8bQ8Ptd+y6dM2kF
ziP+k}KZ4%IA@Fe=hgkfjhk&A!Bpg*1e`U)-6hdN_!cs5?Bk$x)aw0X^yt=Y_IW>7A
zHQB}gS7%d`S71|KS;VJVzQB2XuSCzBm4Ze!s^*agjt!{;s~nM$()f|XBaykc<AG~3
zP=nF`@K?nD15euYvLp@=%Te$AS;}Uy%b^%n6NR^C7P}U{bR~dI=Y=D74XN6_!E0wG
z14>$Fdw%4Cw+2}ES~1G!;n3wfI1QcqhD$;)$hT4cl`HbH{E}<UjiVw7w5J9Zu5w`O
z3~WAskG^$qoq-scJYaY1Q5|mqWA1CN60B$N`MXfm%hJ+`s9Y-4O65$TDyw2KCqXB&
zW;gwO%(+Fhd_(%i#TN8;Kh&W)i&L$hu+S4<Q7=>*=?c=1WU^`Qmy8pG1CKo2<9)TD
zS}2s$QKaBKcdcjnD9Ih_ftBk!e<J)Hc8u<9yNx1i>mAi>#_*7hf2IB9QsdZqD?M0>
z3HeF=p2;^1#S`-}{#Ub1hsp=dUb^rjjAal!x!#@cP-e)wjQ<e*UefHrv{#VI^jhGE
z+91|$!N1Ll2EPC!nJhm|H)}Wn&JE<#1ElOHOl6&j_0`@@+587?SJqlb2$u4VG2)bd
zKA|)hTeXWj0AIm-T<S*cWmL5Zbk??<tbApLE}wI^N0*cNat;}ZB}8Z7xd@n$+J1UG
zA10=gfI)--N<1wil~J5rV#36C-(Fs4np}yU5k=O@dn7)|u}BQ9sgkI$Iv7>!nw8fQ
zO6HoGsA+WBtGc(D+=L}1k&}TMcuZq3v7xel^0*t%lJ`OWX}kH5d^R#a3O%|<ayrsZ
ziU=f=n2<w_$$X1`@8ma<_hQJF;r8o`(?*fp6Qu}-b#Ry>6{7v`0kZg_9?#AEh<4=x
z_BpfpzGB#{wJ1yNJ4JKjdD+8=do}Go*u!JsR-L|;efp4oRumu4kB9Av<VU#v;Y9M^
zt)IQ|dg{|X>a^@@*>~Gn@-bagQwmAQ?on(__J!<g`JMPJC)34O9;RV|Zxo{--R-tk
zCG0dcHIEqmmS7$@mdt)ie%@U-0rxWk%kzbrHeXQWJ6L=>vE?T2VBF;_s1hhDS7Cr?
zcTCavT*s#S{FNQ-%RMGrL*2uRmVqE*_*)!k9C(Lb(+dxC56eQj+EU^zz^fdrHVnUG
zEm!s}XHxv*?D4+mBF$Upk{Y`Es}G8eYT5)X*+_E)B}vGV#S&j;97q9qbVyxYS!_vi
zwUDFHeK+37_0l<XS|RDeW1<JQCk#YPDN3}_HX`?W)tck^$zzpbxlw@SBS4Lw!1`tq
z&!v3QUTS9%6@!yhetU_Y`(NXG$#_*Q;z-qUW8$BjBhP!d=Xt1pR4&868=xshVDZ<<
zfAscEEofBI#fJ8F5g2=BxYHt<(t(PPk^A3-v&dpdMAt{<uu#o3GC>iB59HD{PMw;L
z&XgK;WYOi$<iaz#tZZ7MN8HAaA?URQR;slySJfdTRD-x-l@`U%2naE}b?gM?8VJr*
zyOYADei6)|S#F*^di0E?A`=kQEVD2b4i&LKwV6h*EQ|Fcf|ug_ik{Ep%ia4<pj1Q&
zvG;{~McJ+B-{X|=FJf0J9aJc&GZFk!p;WOhR{QMHLKUBq`N`|Gj#M1dT)TT~fk*~x
zcV6h|4>^;Sau!QnSML7)#isg%c@`{<p(L)o#Jzj+WFg9C!y2-MI_P$buvM~Rs~cbV
zcJDbQ#4M#7fHykamlg}IBBz5tl!-#fi}U2UO65DJ6WeKP$oGsZF#BQawaQ-5T%1MV
z$D))6Y0jd8vh=<F&ZlcR{PRO$d=ZOG5YiYL*faHH_&_22yvUf*S^YtLnq`M3Wb~8A
zjtkCb{6_%heA`dnH-hx5Y5pd>d7;iCHe;dpJMo{?gu<R{&RhZDkgbRBjGnUQ=YSkX
z+CtP23NNoOUJr1Zl`FxnXUFnv&yVT7z55Z`6dZk>+Ybi}FEa<?fZ=a(5PezQdH2Dg
z_Eor#?mWV%_N6^M;=GkBk)KOk3&KXa9A%3tZ;m`hSp?}r;OB<|i$m{xsmJf2dsI=y
zty+m9u^xck9kV66bv}&oHEeCrH-)58G(<zn{wg}P&mnlw9N+yT9$)NAnvW^R=Fv;?
zYZSe}_q}vcV)2${#LaE(F&*X<L6=}*055oh6r`#rA%mU@_(yfDaPajy?g55&DL>5I
zqTAS|!!OoTK!t&o>pnW9+wWGn_*4FVNymkh&q&4oWi*dSOb`=F72u^#9ulo2MY34n
z2<DwKR#N^qZH^pgAazj%ry1E_1X43t4YI#fi}H;qqmrJ8@o2_X80(ZsSHwyf9QpZ&
z^|hyfw~Yt%L?#frH22@^-D{;v7LkNHl+cAusrxH{<gkUr?wYYBC-b>F@Iqd;X_(hm
z9~W=G@y8xs4a1;ZjfxcnF5+z8ZcTs@0~~4u4n25FSrz5`GxCE7gr^DAwY9q<r|%7j
zT^cpUEtYPrqWB5D_JOX$DOCv%h%_D@K@8lUx34TRdZc-le8|wz5%@1`okj3bn9Xz&
zyt5r&_y=!&r*cS;E2DlRSC=SJg6E74FuLFP=QCiGb7w^J?1}pBD-ih#J*QirP`NnD
zBn*bg?%BYLD&q%+JSl15>T7Q6`kDh{g|Gv&2L@Z%5TV3p%s7th@h1#Z$7A@#!TJs$
z*3oI@Ks4a|=^KB`dZZ)P$UMRN5zVv7WJz>*yFL0%v9d)l;m8k{dK311P@2JJKj34t
z6V*%xiABiFNv~f*>J{k6*o^M+>x3YsqFP1fPNt@Oc*F)&)~Fhhmryn10jhVNUyrm&
zpBT>}hf~+#dBzs8iKe*mahJ1~CBNW@%$`rF`GcPm#qNw%c8|GM0ipi5f&=N0vo|;>
z0pl?G?(Vj?7c&UHsur`2S}v<xIh+UO8MVBZ^TkLEvQdSvj4y3UPE+b{QvOuh9EDGB
z?Y}J;3{8%IesR6KAQ@yCmX(xgvg>!@xRV<brBHI7a}^9zZhnX+zl4eD+xnf+<44U#
zd&)6I986X^Ac29|E6?y_`c4$2&|(hR$<1bK=A!uNjF0`o|LxHNbowwVR7z=7i<HTB
zF$#_-h$pxT)cAQIhA57P1-XNw0{IIY)QoKdJrXT0n5v+pMv>^fkUn+hOewHq+x6>H
z=1M^=Dy17JP|2}z7n16@Grc{lsFUbFHinv;n6Kf{sKGnq<2`sPlg?yHVNN}g4^n<)
z-d%lm<4ydIH<#r~P$}lq85H%1n@bL2ziq|0ct~b$T7K}OvZrA69DdnS{vXsnp}51N
z6oKsFD(1i*C(tmZDx8eVgO|zkJ6<iUBw`lInM|XBRJ>rRy?hzbL9IoJOjtvF!a9EG
zn1z{6haUo0A7S?wh=JSPToGmCdz=}l^LZMk4N+(u1SUF$E?Cz*b?o06|JQJ}a}dmE
z;}0e#PpaZMcptO=Pk=HFZ30g>G6hso*CA{qc&>q>HsFSI`Zdm1ar5=w`sWJ)rlguJ
z7L?rK9tq_NQXLs=RzC8s3~W6mA9;Tgh9gm)4DA$$ec#BDcX`i4xJUs7)+-ggcS$h3
z&jE6d=MYyb@{*_Ufl70LFUHtTr0<#G->0B*3i}pXc)gKtWv=CErq`{mER|yVcCgSC
z+jf{WWr?Zj=Cy3;bd)|57IUYXVWWN~ckT>SKo*evqFL*IO}_+aJ=O~WEf|3UGbj{-
z-q65&U1STYW)ZQcs|uF7LCWxK+~OBsEmaH{j^t_QxL_b592c?9jI(EtD_4Nj-c*I{
z5#j+$)tmIY-cVQpKA6E<TJ7{bmhA(Pg7WANxEgrtb9xNBC-;$yu{m8vDvktY4_=+&
zZ?`|1)p=cS(eIb+ke+7du8?HbR?zAX^`tv9U5Q>AJgh^}2yF#Lm#>=qGV>$E?}nbB
zqP=+jH<g_a&z7?}eVD$jP=#HoQ0B98TyU`XX18v=e$h~o0jlzvS0~{vj$eA-!V%nF
zT|t6}!5N?bE+_LRP~)nWF6Oe;tO^Knu$q6x`B?a!<7AY=4DM3=m>AR;6^vf`Ym-VZ
zonM+c27_;pz4tLaN86|R{Ix4s`hou1;n~DM6@2(x>`%+sr?1fOF!t+=*I%7M(y}zy
z@l1viSSw)%)Yr|v9=oGoKh^n+%Hw@#6EJuO89s4{lL2}cpO(=5%`d9>F<tYGolKfn
zy34vo6LpP;^tl)QfcRl<-<tQvp4*(ejtNGt%k5Rbe}Q@SuZqnWDGh5Y2<%E&`@!}o
zIYy&TB}ntBSQ(dRB=|wrB?=XPFmZiX;bs?Ky<jgne&fx=4_?jpB1<(&2e6pJ@2vQ6
zx4yRXJnG=>?$X7JmuHq|a64z4{}`VeuCBqa?zOj-amjhF`a1FnKvNZrl3DLc7_!w@
z0^ja%Z&)Ztc|<b?<rzexp-q|frM}tMxhC_CEOcs=_Xb;n-4Qja<(>v-ZhlJ-&a74&
z*(lVd`^eI0m{2&A;H>L#SO=43aG12RH+c_6pS|&c{{3yL0`FmLql&V9X=l`%9mwD?
zU&c@Uc+cGCiclGm#boAIA_$cnlHZTqq4@sNMTrGOyx%nyYfT#bw9RdjutqO8jV4;*
zl|?9AN}5*N^R3gZMHYBONhH+W6o_VhHqmdy+Z!K5>v+>HL$Op><0kqD<&CvXN~9D#
zN(eJ_uEH6-R<A2p&uk34jL)Zt1*s*-0@hYAvhU^xiGOrO;W)NG>T?GhCP%%~Ali^s
zl6V<I7m>d=PZsLsLM}qIWxjQBRc%hJm*63xi=9<ZU&_~l8d@0S@)Z>*afpT`W5?cj
z$k?%Ss9=Af8QbQ;ZTuPe74#YD389+N8`&0oR(Pb%@xHQhxg|Z+h01LWar3^3|Khzb
z?4an^2lGx{*(0cr(mq0cl(r12edIno%I}=B#i@t<j$lmE1}(<h_MeA1ntHxejSze;
z8l|%s@zzv&$=4Vt!tWHDvpTRcv`kUyJsMW|o1ZSqGmXrMV&b<n^$!f)GV?Qb(VHK{
zC6)7GG2PJir9-3#WA}Q(i!(~z8|BKiMh4j|I(i_maY17)mKm;;<&{D2BYQy{gkJ5U
z2`PRlxDZp682_kyzvO+TD4(g+vef{sy`{oOSN$%l`hdb4$JZEpZtE>wybeVh5?WeN
zLX);k#RghQXUpk}?MrlcBRmTZN)gJ2Ry%+0*~MiGoW2f?e5tx3y|TJFaAo*>bPUh#
z&kYr8AjY5(V|Yg8Ji~~%;TiD(i5tVl@{IZtcCCCXg-uHSYMjNsh#s?tZ~TR)S7uOy
zvQ#X=>{e41=g3$1gNmiIyzx7l$jI}^Ysl_s^x{$eMV=(SCDAEmkNkCCJZXb1cf&|%
z+2F}B{4M@aRI`#6kmxrnO^muW_kHJ2-M*ZFU!z=UR4VzL@`m!+eTH}PTMmz}LDtj>
zES7xyjvg$Db~31lhFY=0GRdX+-U>^W<jYqFuGiX7aZ00-ANJ5~0+<8#jm@3={P(-{
zPllNw17B7;k4V=l3hkoyT51Y>2i1F1Q;?F3Etl|v66$udeQN4>;PUX^^DX|p3PG`&
z&6aDdAX`Yc76zC4#@(^PxKkqWmzqwJUr%fmQ(IGPI(_|{OGlFkMT!GpU$NSqSUk^_
zltJxF`klAGG{{~U|IV=`Mm4F$nEc|Q?lA0n=$j2fo&MW8Jh}aLM=z*HUJ7#J!Y&^+
z>#_Lt<3Hu`4cPlpTLC##4fQ-{Idia$h|PJ96bB%~BS#=_aIB99+Mwcjy`H;Yplw7K
zjZ^kwB!1dnfUf_j|E-OFi?NpIDvCOm-`E9`|H<g*NcmzPv?8*-oLzD3ZOk#zb$`DP
zxMkAn=C6CPTZ80esgMtmS0<daSZ9@8v9-v)-2Ha)WNBXoYH&TKgO~T&|CZyn;a4nC
zQlB%r&^>+}j>&@4?g8;e$UGQ($&EW0uZZbzeQqZ8T+Nl-oK8&DGYAULmy}0XOsoo#
z14zpKtQ>wvFKt%SQMy`2T&0{nv@ePTOS7&DBH)Ee(UALGaX#b=&y+Ftv>S3kldvh7
zaozk6-nc4_pjs|A@~XOx@15p@DD3%kZUsu>K1C%qtX(F;=p&tbxo2Q=XfLfVHM{Lg
z%cy7%bsr@t)DFUw>&m4_V4#1?_*5TlyLnH-MqWVx9O{N4!ga9?M^<V|`U|9{R$Hn2
zs2MU1Ql(8v_>>*P=8Lrccu729uq-Tq=B2DYa5wU0(QuwE%$oSft_-*|@qWGMgRjKg
zpO~I|Z_(pTY9B|^__q(&@eLOTv@B>?YVG2j=QIf=PU*dKr|$y>whIek8PP{7I9c`f
zs|hI+U6S`Ysw4F~H?NJ?2~r-uL+!e1H5cY<XzVUG+MhsA%PABH3?)!cn36A*Rg%Be
zj^?)|p(Eoz`TVzOdc3#8yk1ozM+JzQSfa!|{@Bt%E}P3`Y8j>U)3wYk<93zF^$0V1
z6yDQ`bKQLKBHlyEEE$`zpKg7t_uN__L9h90Lzy<{Oy_Ns#8U#%VcyNteLO!lNADJR
zek|ra6!1YlFLngcK{{WG^>18N{td_bw%~uWu?(mKTFKUPnUbz$!AT+8b9{~yPRb;j
zV0spha{d|r#pNIw@c=lo>!E$&mTa2_;>OI=fUHZ)NPCrA8>C|9Y3#qo&XaZnbrNsW
z^SSvuL)jj{uB8M;?;@Mg$5;eL8@*)l0A@1L0ds2P^w{6h-X|5>ZT}!6@5lbZlWkM5
zwxK>V!j9~gpTpv;YQ7Yl@b(LBb5S{0LL#o5O)^k>Og?h)xzGbb{)iq)1pRVT$idcx
z-TVjYK$tK|+CnHVYH_VDv5hFoJbx7eExeo1mb~MgKd9&P)C6i`qefaT9k{H{lhzin
zVb7cNd<`dU-}#L{QggJhvX1VJ-OFwCy+OP)GpNz6jMjxGkLc`{vA(iE^+j1<23l~P
zQJl}C^WQz2Udi@E33W4_)9{rbms{EP>Uw_#&(nG#a$BSo9fEV#m)B4jUIj59+%yft
ztZ19R@W0*PC%!>|1i{tH{Jd<B9&@>^SrarRcb%#0s6y!E$F<%#uY9GH&lMvjwn)@o
zZt7{-6qUfrp6!=<dkJoYsGcpN$d21eG~X!MqjJ&%n^P6Nc_?0^YBcq-no$MP05;jn
zXbg_(+zuTc9_x0P=c*^W5SNND%zU<xQwv0#K>ov-b^?q-jf{+IXt0LWSv;)4i$Yo1
zQvqn|Q<_#cUeJdPW(QY!)(aBD`UjdS288X8dZ+#D6iu|OI!|8$UMunFX^&Q6WXhzg
z`E;lgc=-AanFCG?|C*MMXXM9GnU`1SdD&g^_Py3Aox+7EHeJ1IS@XxuKk#G|d@D$?
z3lW=m=t0~@PHrn3!RkyKVg?By_>a6=_(k$Lj4Nn&ACQ<TSEEK{-X{`&px-gM`#;8h
zb(`CKA5*EZ&^b)Fo$=@a>r#svjcPGe!1<7UUNZNI`$ZqN{z}tB3-S%%4TnuE%#9zS
zjYkR(t)d)~#Vr?J>+^vy$cJGTF}ccC9%m*$5WMgN+7$Sg3N{O5sIS+wyHoY%2z`FT
zY$IKTe3wl@w!sUDlgWu3a^iPH(bRf~p?F1C9$;|WO+RjTs!+?9YIV4y<@VHC<Ya?k
zH=gkJU6r0Q>4b4+r5cv9xTl%F=n<J`#1e_e0kK368JhlGMf+A#<1sOXFi)uduU<7R
zggRIO5|^rT?$z<vAV5NR28NbcSoC<ny@dkcW>ivID@7_70nQa;2mA#43!RcJZ0mW*
zeGKM0dDPKD^4<_N#Y$;p^;{L))x>>_-n#V-V(Uw#nx~Sf^aGyiiu%KbKSjUd?giT|
z`~_hp%9I<bP!re8E%j~qjf|eWnf9JnmVPhD4luP7#2qWEkKdvE<_D7275T_{B2`ho
zd5&>X8NcLVt=<QiGec`n^ymm-rqZZ|4P}ksZb!)wJHI=AU6H9mrBckHWMzQzj8e(O
z#Zv{(Vm%-MUCXVjx}UDbR<h?eKR}v89BUn653AQRf+f3w`KvdYtHjX6#D_J#cHYEm
z#o%JfjE2{)`8AFLlr{4|BTYc+cuCcmX6{^=V`Y-2M3Xm8m!wLG3NVjvZLG_t*?@EL
zjK+te%MlZ@u7lBv6FC}xj0}1=>G#ZH7iMgTnso_|mv!Kr{I!ZZdW}~h4eH(lk|LbJ
zPr1=6^}adc_vx#l3w05?T}_EjE-^_%;Y*6^(}AVyr0-iS6oRl?E+FRP(B-aqui%-a
z1y%pa0|Y){nE6R=iOpGR*sXw3srt@FKaF1F?T;!9I?!Zug^Y4y-V&eZ_U*H1pzsO)
z+41}u$9@&Mi>RhTrS{m(H}Y6d)TrUL7ygZUk5z>5`}cbXeZvUn@Ydg~X=2=yDd>xq
zMq}n;MJ)?OkY}$_p96<UU)_gE_l;2=9*pnnIx~ii;cvG;D8)8^NYnQY0vN4b3caPG
zY^GAGV$n4ZB>N+GBIoneF`ZQg?+&r5;hS7)npMd@&&qxHT~_{LaG<P%?8BR{rG0*V
zS-98y;>;z<Izr^90wnk;?jdngiE1oGC-Coc`r5HW>qQhZsRLDpCl4K(UPPbL@3;LJ
z=?uZ52j--Ys*8fu_E&v|o{>RR<|U>Z8GqxZhd;mzr7l+)El(Ygqv#}kIr&MNql~3#
zohC3MJhEPr6~(Ti%>eXa@XL*B#ITaTk*}qXAqheiml59pY40zUY=h-n(Okc;;^4~u
z)?j1!N(VL2?Ov*(%}lybg*k$+$N?)wnE8qn8*uOnK9lk6yv4*PO1te)dKtMo5K@>-
z_o+9}y4h=Uk7}8EHbOru*<|EdUYrT%4(!&f#iKpG>l_#$x&nt4#orwe=YnvYZt(m|
zNjtubJBNmTt^<+w3Kqlg=-sbZatZZXW~Jnt!G<UOc+q3EN;*?-pfopXa0K?+WK#Hh
zlWhpZX=>g-(fj^|VzFAPATL$kpM&&xxEg+7ar}kP$JwIiZAyZXrx$)%#T2tg3FyP(
zb}%W^ull$3`b9_j<ig?FDh4MB9KN~2)?yxevf`1Rs<(lhdxzOyL;4jC>Pa#xv+a>+
z+JxNS2zFkNG0^!h2oC@qE4JiEbKGi-2jDWRgqY`y-77ZRl&dq`&---NqBbqLI(-Lb
zGpZ~!vqys$I~<vW|22m!jB>RkIk<&1f=@eAK`wQlP16L+NW5Lo#m1Xxix>WFkJB2D
ziw`89;RTqFH_Yk`s(P6h1o9<4z8imc2=*z1>td{y0~}U^W%ua!8YI1Y0<4VAy!~~a
z{0=K9BA!Jmz7}py5Yy;F(c>^91vXD{vW0>|iKr=I*+7rh2Q6e^ZKfZ(;+~t#qL+A-
zua%^V`jENppVI5q`7g@1qmd@4NG*3$XI!kTVs~M70Xj!ojlr}y`t9~#5QTq@yxDx~
zAo@F~U-(F`*9&+L_m$8GvCfw=_L1Z<;TPIIsR{?de+6|`+*r*u0yx1Af|s`c9q}El
z$lxNSCG^0N3PnOYhR<!~<eb!M3(aMho9)HL)+IPRyXc9~LRz}!%zMhX4_~<5j2qC_
z=7355S576|E+J0nG|8!Z*5cBgZ==5q8V{1qt)}bxhTQzIp?p%RNBN-=UmPp6QR;Ms
zmofJ;zfb&(+mjO+)CWs9P<phYz$ek42R_}NcUTcv)bRP>7m1q?l+{L99KxZN=bE|z
zFlbM{SOa#Sle7n|w5T154ctqcha{K{sJ~m&*~ZV%<|}PcW<)oY_pj??7v4+#RVv0E
z*lQyl6#9!@*k&7sj<$MwI%J|!0ZBq?RtdueQ-4-Jd*_YhXY(kjuQKI1TZhKhdgt~q
z_kD)eK{Z-bl1A}`V{n>Kx1ZGSw)uYQW=&~4P-{uVxET9{3E)f=UPKhwxn#1)iwxGd
z6P&}-y-LLl63UcD!?~kQsT7yG2pox+G`8#;w)Wm6ErO>(c<Wu$CC}*`k3OsC8AvLv
z))41`N!L0DpQIkbZf;03eT9Cf@xS+c2Q4tG)y3<G0yLq3pz}@}t^#ZG>O4ffN7r&+
zMB|OM#K-i#67PMM@HNh%isg_ng|C9O7k4)>xtaGPVB{uuc27zYswbGW{rDX{^WLac
zbA$jg?}QoTEZ*Xt59~aCkal3<%GLJ8Rn^mI8S{v#PTc%PpO4iMGmdtAP_@;H60tbg
zLYC&B47Fc=q<MlPAo$@G{EHeWTp>1JW&G!rJ{dN<(1cNGWY*d1AJA(X?2@OjU`ebF
zkkugER}5e<_0r%~U^hU&m<(3+eRn@eoA=y-_0C3U$Z4vaxl8as{IeM4iwbkOm?JUr
z?MJ6E!2Oni@bLHA4|kDZ@lN;adE9=c#$62K)pcH_mY1_z8a?7Q=>nj%tOGceq4_b7
z=8*wEjdam$Ykp>ZaZNc9<vhVRiJu_9Xm{a+onte+dDw+)Jim=$*}O3nUMM|P;c{kg
z?f5lB!HBErFdvo>_}IH?$uU)2jvU}7<9D>#D5gCrM+hU_9#odJN$0Oj_S76$M4}Pf
zc_uQLPnpgmche8qIiuCi^y;N5BC>mHSthYq51eXsP;Px@4H^Lg$>dsNuX@jej$b5?
z)rw$5Y1AG#+d^>Pi*)W}a%-sdz=NKG+{s=kez=yRbLap6oG*F%GuM|R`9;02Z`?ti
zc)Pi1qpsy(yTPb;+K*Z45SMxVt{cBYS%!C&R?-p+AtZzLSa7q#sguPoBwZLOry>Us
zG_=-5I3fze71_~NuF$P*doF{d5qu!LGWyqIUrsH|bjgJ;vWjI7OYU_giIh5}uig9!
zVomt91#N~B5=j?1F83YV$7Dbl3j6tZuI*Dfbl|{fiACRF?)e7lG+K?BZ?_OlYN~$R
zCSk?N8C$*TgnoYFzbXHAk*;_ZbP=HTnFnsACz)||Tby;|mpuNKDF@k729}m0RF~FT
zj{cLmbEid^=UV{CsJjz5jCSWUdN3L)SC;enf>%`7^L@}ecrLKdU3g~CwJ2+io*8II
zBz#}l?&U9q??U+#QGx~=CVFeP)Jxe?Dbi*Bc&&%Y=?6jmdC|9oZpQyS&JWPlvHML#
zK6!HgZ;XFt8coblyBO0jC(%E>5=6=X2*t{OR8ZcnpVj$-mJ2Z!O;Pa<R^>;)GjUWB
zYt>9na7TiA1t-e;?o4@Wf!Op)DHj&<H7|FJpqG-EGWj-Q)6E*b=WD!Y!XIBQ)zRWc
z#qfHDLi)|Bvi`4e`2H@F1Fq^BNY!?m+r8z-Jc<1|(<s!k4dsxdW118~0PjEt36<aR
z+1K5(w*Q2-o7n|gD`poElWpm+*xTa=Ju*v$QbD}~>5l#}MZ>go790(4^~W%mbLi6@
zlKwfGD~|s88R^ZR(sVWUypjD*F@!YG;r%2#ipA8dVq_oG@3XtvV-La{jAW5ju>umz
zqxQg_x+B7<4W3)@>~>PS$rux5AG}D9=kKULf&rqmADR`;RolxgDePx>$jxm}ua~_o
z4OgXzq|WgZgQSsDW2%-IEY}C;BO-SMBXzO<iT}&+A7xT3wieNdQ_LZT-AK8l3G$qe
z>9KErZ@-;Drw<>F>AP2y9j1*)+X)QsytxnWlvXZ-dFROBW<<_;j*BFIZdt43*D|lU
zGb`p8d^R+)327tt8tKiMUR|BJ?!umJ|1#14<sR3b=J7&=TxD`$4V4d6tUVbLlLr+e
zf!idVKJS<VnIlgkla_cwV=oT|`LglMPiT4>ds!bZnZxAnp%p!+UvXSS*&eRwd5m7`
zu*?KfJ{w3WDIo5hOqE6>+Gxn<DFueiPmswzBR^>8IVFEZm}c8AA)#V?6&<av(Db1l
zs5<i)TeewgqFx&Jx0(CR*Y?f5lsz3Z_c1P<fgJo0HwUb*ar;9taZJC_{ZIP&=V%I0
zDl|~}GUFxm5HyfbDR*f-qhw>~iXv_<4HwDT_}tmEm~?|5HXic)%+;V=%jFT8F8P6B
zegU_YfZi~V`-Nq!vg)H|#=7}NckKk~a^;JtxSrMdyaYII2##zx4pIO&8qeeSV<C~y
zhmj{2bYF~mwb0DAyB$$DCUIPN1%4&Qdt!u9jlBvuq{3SGfW;tT<8!0eD_s(Od-qU^
zVaGAsbg)G&o}&+ci$S`fpkgV8g?}&8yyn6UWee?Zu>`Xwoh*hQ-t%^E9}7P$mUEem
zw(L8APjp3dQ7kQSy@31^iO2Nwcb>dB&L?XY?LL#a5&dQJBa|zvsEP>BC&*px&i-hQ
zthN}dK7wf5*lMAc7;IeEC0bk7M)%NsfxhqVG4Y$uqsb#Gja^YaTJX5Ukw5g;A{W%l
z8LWj4hGtwaC!ZUa`$Fwz?cmQgD5&@;8OZ(2^R|CUo(G(_I=g_-^~5ikaoo%I1Nb^M
zvwW%5m`Bul_smMT(3-s*r=O>!IDkaW1rJD(Cz|lQK=-|uJTNf{#UAM|sztYd?nF=o
zuo@VD-d8nUG4rw>_txXe?qU0Qn-yUNRb)r#1rg`nJnFVL*Ob*muLgI@gZf_MEA(L>
z7^|b|>nb~kYLjc8VhiTREWFy3#$G@6^nSc}V2<!t6q~Ud1T<vcDf+v9AB1|RIO%F$
zCPust=9vRDq|xs+h<UoVGBV<x-*o#hd2gmzNM~vVNY`X)O4Ji}%QN!r!cV(%C&FA%
z$)R3rc0^H3NllfXeAcmD?s6$pl(=YU|9>)iO70rC$6RYJi*Ppdhi{|p(%SxYH}R%t
zkDF8B?X6&caA!8_++gONg1_}-b_UtN*>ts3FBa8XQ7rQZg|YJ)@H+}o4x4O>42u$;
zNBNia+Zmrv@@LIEMJwD*XI7M3y4Uv8*9ptXx~(UKk4YPZ`SvB)%}^N}&FrsAi$HK!
zm)E)d-F(j6%9#ZmmbvQoJ^?mSk)l`hTyOlczh9ZhJs>I~hN9yEV=Ta{q*Y?j>kUu(
zEAr(7e2Jo$4iPYj)8tHfFEiic(1D;YLHs;0e@3Ey4kDY(1AwOISqoU^bNr=_K9W&T
z2peI&f|}3Zkv(lC1DtD~dEtJ=XQyd1Mf#H0MSTWYGOLI}LPmlF28by&86*{cm$i^*
zZg#wV1~*r&j0zw5ydp^jK@oI738)jxPRj>UB1x2#NSvZ9MU;~c%qaDQ$0ZEJ#(`|U
zll;xru~S`{`$J_0!owKC7|iP8fz9x@*q_4zh-jVY{hH1;KQWXqt+yi4^h5yO-aFJ$
zRo2*DU}K?rp9eA!zASib=lu%P>dHiDesZZbD_~_Fy=}4Yaf;QEHs0oFbRttjVr!JC
z6tg-d^YD0>!MmLybcNwpa<Dt;@Z_FT8VuhbgYINwd@|_eRL&KvwOZw{`Tm#mdTu8U
z(^nUxM#b}BOzwe7`_MPrZ_k;Gbi>0oe#V<$^w~mj{dyS<->{#wy@MK-6aVB?F-X6z
z_?#~FKu*?wWq`f#K|RmGqdhj?*ciZztxN4?q+nd~A_2u?2(}C}=%LP7oQ=c!*zVS2
zzWE*W1xSAtTMNj@lFm<yO*jQSrZuwe>`Dg)VK61sap|lfK^kE&;ImY|<OlwS{Ck1E
z_wIe7KQyndtt>K#!Q3}-MPyX7IVZ6u=-1F*L1<)G0EKi|T7e>=`Mk?iL5EFeTiEq;
zimNC=)yS2@N*FMJaAsa6(%Mw+?DfgztEFr?UsV3Q{`?~PGtxog4SM`Hew^|<v)*2u
zqer!I@j-yUKK+X=#pq9sPY329-E=|#fKK#<nR~j~MQk7pCl(th|EtWCyzfol@6$j^
zV<{{bbyQbgNYe>if<VGs_<6)OA=hs_Q}%&D0F2XhGYSRulzz_*okO-q&x0>PmN_^$
zhs@eVUT^NH;<WbF_guWy5co>lU4)0yX3!<hIml+9Z+vT7rI-^k`guvrq{eb{Fn1x}
zd`K{db$A8tA?xwTOB`QHo~)Fss4&MY>U?!=VSO3lL-~5@Sdb8%S<b)d*Q?1iz{m30
zI?6gYJ{DRkAon5^BU|IgtQ>VtJCY3f7YXH3AkR3jpEdSw5BFtCu-6wObW2utW|}#v
zPVnYV6``J?%$$xEsjdjPo7DGy&v&}_p13!xM@6)hR^Cf7Xv!!#tS+v};~H7t8yd$p
zrvPNBP#HRgDW_?XthC`>U0I}dC1_UuBcL^Ova4%3VsFP=m8Q*sJ#`p`u^mX5CeB*u
z1j9~zeB8Zj5_LXG#V|zaXkj>huFx77ftN9qx-Y=BGG_cr+>`NqCs~#suVBtR`Nd>W
z&NC;D%Rr5g>qFF~Ahw-bp28~_rPh?^J*4M)b4uk=Sw3&<JZAsvS<rb@jOjdhW^|cL
zHS0Z>$^sc1z!QG%<jHav*1{0Ac8kT-v8AQdF?3CH^KxU;qfzwpF6OGWa)EhRem`%T
zw}-HCbA~u2+z;F`oEKx;9s3K)FQq}jdRJSSTVHHRhe8RMNL!y&^m!Ghl4M|tmWI0M
zp5Y%if0g_rHKEB^aU@9|LkPy|b=}%UaKR<?7=gLK!A8rc$5gLmLh)wz`ZBDHE6eSN
zTFpy~D;FgrgkBmL8(P;i^55e&rV&Q!p8cg>`<pKu0UI_eN0VQDJ^IeUO~nMAyYxE;
zs+Mi*T6@jP%1_^+Vz}$m)oK&$sd4H|Gn+ddo+?FW8mC+zt*w{z`M37Tj~!iy*cUR7
ze!KlZGqRQhto@Lllf)=}q;Dmml2&NOwe7iDY$is(+g$N&K~mpQSS7gU9@T$TWf*gN
zo7(h2e#2GFCD>{r`CU#1OdtRvQ?DW?JgW+G5UJ^cypzJ7$$Y?i(`n!@gop7<vT(X0
z$haw7$+*?w6Y5Ox#t-ZDOTJ&(PgYlETWmG?l{;U;*=YYW@^0r<-h7p6L8;cr=Of*0
zqR(l1J2BQ}y*|7DyC+97VGxy(iYYZcWLBL(pnTx!I1?*BN<4zWDZy(M|4b^j?X}HO
zf^QE8CSL~|o<<v2>_2m#t?yB~mc*E%1dN0=;!KIC)AwOLDle*3N1rk%A2es?@|y3n
zh94LTLsZBWJkKk^oO%y=UuT;0eAa{!oC%^nHwlUw@&3PL_{MiCxpoxwN)fFzoWDxW
zOyd2IqQ)uS@D^QNW+sPxs4{dK%(MF!+9tO&gKk%|ke$qzwW@ftyRyDI+d}aRo%*1b
z0jKFg>!<>T#U6Ye4670wj6sT7n3(h>dd_bAofm6$YNcfBF<>2y4dcRl{5^rbSJfP<
zY-N?=O71|s!b&1sQHT7T1(tNn1J}qfXu&{{?gl@Zvinn5PU;+jyA$u?dNO8sdKq5q
zxic%L1y>BxdUds{*jCHJ^ZV;tVJ7a@^ANm7%>!%?^P-)~;|*@#dJo3|)TLGD(<tIM
zyD)Gl;^iE1C|nbv2YK!Vzt30>c^=TU(WYC1FAQTgvsZI-N#;Zii%ZgH95SIes%<?~
zoq~5|;Oc|!jP+v*JarHM9$oxDrDy^|-0;^Az1Y!i5<a?8HJ5LMC7DZ42bvPN+MZ2K
zi9V5<LSrMg)S0DQAn}=}DLruexiNW4LRTYp?D~qIz4(|UhDCl=zN-|WQ}K`Thvk7{
z+YmmpbzJ9ESdS0FG**?@NAcpI+&p{q=oziaIL2EBTjh}=cx$g_>MDG2ZyOzRvE=A+
z;#gEJXYx@_<s*X`N(Qa7Rb=mGe$^845Yg?V3-4{Ub)~h~>%UA^m{0XZ^DZwPQHMIL
zCPf2$_M;->{nP}bJQ=yvne(tyxe!EQIbW`)m7U1=2k|=;R_9DRgb}n*c(F8OoD@%#
zWrVx@$RC2TT-;~$b(9C~?sPVEVW+Cv?&tJ6bUv|9Es4WyhBaW`N9Qs7&AcruVddqG
zRb`J*y;s`SCNBGF=MQPe-&4O_`mwC&exI_2a&G5!ie8~_40sbwK{1ZBcvp|zq<;4V
z;xp0hL@vm4H=e=#CIe}i2r4-!s2`zsZV;gWtTeD;K)C)}ioycCaZB5p1snel`N!<y
zN=(GqaPdiu7JGpnThZiSG;*~ta(H@o%%gYd1(;9Qv)NoxWkgWw^9R8))ih;C67na#
z^P^KB2%vcd|Kh%o+-jpc?)JoSmI8EFEoQT*B`Y_C5mT4*r2&vXxL5dK1vea?SD*QO
zK8rupmts}(VmY5l9456qF3xsL)k=4K{1oe+EnSovn=W-XaUOFg_u2C6gTi)Psn+uK
zEEFplF5i_~n^VL&p=QN_@;jm^f>@p`p`o^}M&buatB9evh5AXiN58R|M$lSVKS{8>
zynE8OUmgR2G%BcZ7c}4|vVO4S&vW0h@2Xs5<kGp9IJuO(58bVb4Yc+~`L-*-+d95i
z&Xv8h{b}KU+IVOj^XPccUP5VdMBzxh;Vbo+PCnbSAJ+mbMWKd*Ra_2|3l~9|?TfNT
z^}yN~H@3)UG2gk<;^B}|mN5y0^j)bln0}1(tG-Y|Y*(X`ZhpqwL#Q)>q@qHhkyZM3
zS_Z%Y@rNU45-y2^giD%H)JwXjPRhdybq6jV<`;VMoAWscC{zSJJtO<<6?%?#{%1W$
zUat*Xsz-%Vp2U>eIUW1vo;l5wGqpUz!8xatV`_ZN?c%5)zFwr)E_kchhnHsB%i*ar
z&|p^A)|r#{34MI*$?6@nKX*SA-@B<Ra7w?+g)Q=BtG~>(F0NnFTCy@~WcD#?oYSeX
zir0&6MAqQWOOAe$h=0nWu|~b#s192@Yf_IbdZ&tOLED%$nroWMl&-^CnjGsz6hye}
zbhFJfeY#m}Une8^W2O{VR%1Hwg(Gyc0jo3mz4k{DB7t2UvfTxb=VbFiCIjP89^0e0
z9~@DG-wO^6;%Fx@a%!yU?lVy<1+@a4g{FU49J?o{CzGemf}CFQAzi54ncFB26r&1c
z?8aU&{x77K4CA?15hY0cV~%b96Uwl5cj@9q7Qn=HMz-&63QeLsv`XH#Ifq*xqpevC
z%&Pp%d2Hu_diO|cJ2>#=Nm$+oHGL;uq5OD9Q>V0E#J1b4x}ltQniS(hsU_#|9DWSC
zmUMJN@5vj#=<P}5q*lx6dL>`X2YU+O<gUpgifj@&cJu!=F{p!rL-&NA+8Du|e@iT2
zHO3KR1V>sx7$=tJ;D~Epl$3<SUNk^s9V7VLdS15f>i2sfEpir>*A9&&pE`D9^o*UW
z#1g5a0wih@=%TYd`>O39L&5;O{4n7WLwK<=Qf8mu^@YjkZ%IOuDvj$wod#EZz6Vzo
z(xqG@Q;mWvE2z^6=PenT;SJF@3bvJ&nlp<aPg@sr_rDL)B}eExJUZDtRbs(}%-I-#
z3u*EWWQ3!sXly%=eq&1yM-f|ItBJ&7R0NZHfy#fa3_ra#8g&_klEJINcn`L!*I-nL
zib~}nmLe2Xc$H#gA+T$GPfwm%6y|YdQFWf71QE<<aA>gMc-BNA464}zz`E{|LZPFO
zn;_EL@iQ5WSzPj-cW+d$S86$JcdE%V2w@SgWih^~cVXiQq{v)PI|o}kZS%0>U=Nm9
zG1}Asa5D&ySc`zm6^QO4k6=#m15&!=j6^~?3y(?adPvKioq|Uz(86=oY%PtjW0_CV
zh9VI87|IW)WfNbJl9Zp-xIgsoq@1nv3u~!|#UA97_!G^eH@{~@JKq4C)2P-JFoj-m
zH0liot%q1>je!sEY4nw`fcn199O&qRm5Ic=%{=_f?Z>&^<_pC^Y8%`7fToov{Mb+A
zTsAUcJ+D*H2|bnBggP5dE7V05pQ#EtaD$R$XpA&E|D%^2_DvpZ6ry|;ePRPBcY)O}
zgZKM;KU+u76tw0cner(l&M2@kL>K;p(oGN-q?$FhA=Z#!vjnf$%k=xa$Cqo96;!$}
zMsV?hT#*k9LN!=8@eK|O&qxU|tgYdJi63!epFlz`%FNWlvMy3WP|hEGb8e-PY+7pb
zVJP-_k9@!PJoFhxW5ZIWq6>=fQJe|)6mmwgZgS+TtOKoN{741jw0y^9Q41u`GrHo3
z{8&TmzbK!t6iYCx*!AQs$mrEd^S(+GK@^^mNgsN;$7j$UxlszET0^-5`}O^j+#5C&
z!}ss$;rn3)zS}Iq(B&+?9Y>8AWkXNLdu&MMsNBfcOX;A#f=;*wr|kZ@w!w8_F~$34
z^j_Q^i}8;QV9Q9@KkNHq3|@Nt*>^~saCjy?32}1~wLJSQA$XpN>+Sq3`L#sD&0IS@
z$T7Tc&gmYXuwXY?KhY1OU*!GUC|j!fb@kbw7;W9G$9R^N%|Lh<Zo_}iPBal%KD#(`
zg^}e*T5~$#){hC^L8v&Ym;k!iy>sI_W78K`V6>3pmVyf3s>e3=MIAHHMu9F9vu|o(
zBIsNU8-vB@$X=N^9vA8|Gj@L^e%9Mx88i&7)Wce?T2$e+ZbOg0m!0JFG1S->{pW$I
z>)A%50v<y0KD_4{Ubg*R^lOOy*XAb}+TT)rccflge;{R#%>}+g=zao8O|-6)b(_<?
z|J7NX0tBmK(?C6j4?Nym52;qHqVrWnwR@o}i@eFRrA`MnhU1BhH&=*PZAi1xG6K1U
z6Oav&9dM#usD{NL6iIMU*5!2dEinwANTVlz@J6yktlc4me`MK{J@@4xo}vP(d&q5A
z&X+gftx$jo|BQSI7#C%1%$HP4UBsrcwXQx-_GqB}P&1OhfmmT1zk*}|G0K>|94w2y
zCPgDeXYsmS6B9zi=G4;{+n4B5fcrO)VuP9KNu<7svBBWtjStd(uJ8!0=+HDe&6TdQ
zeDkS>Pu|!RJ~=<XxZZ`O%gLd8KIzQ~@`p>6N-m3?;>fm74pGP`6+$NNl>FdF&NtW0
z2`xH0nLqrX<`p;pmmZ9S$0)D1No|>#o9RfRO1wW!Q7U-#e&wI64pi)^w_VR5*f19=
z)3hS1z|}t3d7&rQfQd?(u#!ar4d;P^$*arL|C#irWUfqyfFfhRh<1sMl^*Ez<;H#Y
zSky-4g!{&^jC!;Eu&_2}Tdec}Z~sc39yV~Lgub1QXvpwxm$w?5>PE$TUcD9+t6^9y
z!ni7veaJS|&uBWm@hyG!?IGfsM>3=h7Ko!;NA_Pk#xomU_K2;8evI0*Ko!3h`seif
zZ~bJ?K4s1xdI=&I4Q585Z|qT3hGIX_Zr)@B4LMG@i#n!wV&AjjbUb_9eaDDsd?!Wc
z5i5FWZ2`TK=cHKMs?3nEPV#i}>UR>)K))7diTc{}t1C-jpKA;Fi1Q4;ie5<jkI31X
zxjEFt>>@!Cgr~-75<>bM>kD`+G9vowegK;ZJVV0D=`-nim}@ozmAqwS>V@9^V);xK
zxkd#QkV6)$(YTO3(fPH&+JKYy46@51nlv^yVN_*#7;Y1@(D97?0E$(8LyWxKezx|V
z`7ywVb+XGKpwmn?zD6lmQ-hYYKM9(aweR%QKTQXXdZSVZQTr08y}E*kke1j?m0jNG
zAWuBa)v(8Drx^|_cH6VAr^ooix8jRGq|GtN8?Wu?C-i;}uJm9IV3$?XA;pD|m0*Y}
zLHWf_k?Um6?&-lyXbfMgMxi1}hnXn<V6ekK(e-41ZTzO_D;hJkSX|bm<LEpGNz`#T
zWc$+|4gnNwgvDAl)JdHHdqjkEa8pI)6S*f80Cdoe21<fBViAf5ew6rLXCFP+V;_|=
zxV12^1elWUcpHPA#{X32uGv{%L;GXAoA6S3$K7|(HsQNW+Y(oVND=z6&AvX_t23k1
zZz0O)Qt8~%>P2X8smtcZI3LjS|EOPg7q}!_K>RK0GEw&R<B+sm?9~e-bfa65kW2zd
zj2^h%OV?q<%Bs#*65Qo%C6~41u&m$v#$(h)Q%S`H<3ssDO1%c|-XKIH+qd%`?t%}y
zSjaTeXkgFxGjVeqz2krm=+oFitU=oY50FUsgIDlcrmqoyW7!gqj5|D$%+!JPP-P%b
zO`wooURh4vCz1p|<6D^7^}qRM>PQ~WUs;yqDc#D*?uCTPmrgZvefEQC2sVg>bKG$X
z*UR{}dvI$7ptX?8D@%=4Y77l-1fCAiqjNBm&g#Pvj9s?20_M3|Z$zm3q6{}qJtalO
z;Wh_xNwIws&!Z~=#xA;vyu+vc9zs*aQVw;dOG?AzZj@qeW`Avz_zv^fV8Y35t)ZKr
zaeTjXarLqen5D7iHOa}N=qa|Z5Wv(L!%p8d=dF$D5kF`CST$W$Jt}8cx++dZ-sO>(
zvF;}lY}-gIG^^`$<s@~hrc$n4n3%PljDM@p$@i_dQ5}HEb-1VD4M+Y@$M=$`$sJ|F
zFjI<3B9r{)5fo3XNA2PUw@+|>V0A&ALF8l@?Bw)FNwe5*7do7?0b3VzQmA7<I#*^^
z+md?^{S$^FzO^{7^s7lp>E>B6r0D&>NBY{z?h=oTA!u1-<oVbe^|Ml$qes&xq&%G-
zJ3}8~nnLI!+8(VhF0z<{vQQud5+{m-?0(IME-+65V@{ni9Xj^+;1?7Ie4D<0=kr6=
zpJ|>YmGxTYjr1NK^V{X|!(D9A83Gm1#k}4>7ySK$HoC<M6w;EeZ_2tHjwy1}az`p*
zNM6Xpl$FjR%#SqLC(fHWe6{l3B$2d(3dkUDIwCO~Lrwj|m0h^6`fY8ZH@|`F?D!){
zW)9_(bwaMn&J}9H{~b(>bC@Fh!iCD){P}A=u@;gKUZ_jcfdI9fp%t_gSW|fJxApsW
z8l&Q5v(hoxcEBv{@k@<<i=ptb*#|fOQPXj!)w+z$D}~2`QtSf0CSBrWQy041%*pee
ztd~-SFzqJZua9l~5%oaTw_TfR+UV?wrPTHdZLtBO6!N*1kdSyvQ$aUiG{Qg*q`AlR
zc*j2eq{S}XHUl^)PgeLNram$Dpp(@};KW=$S1Odzzd0uXtr7r>q@b16>!~R(91Y*X
zLxDp9@rm3g=*4&{O<zTk<gP(~5ey;cUF$tBTwh%Uw?_~OS`*1}Gp>7H=#2{)Jwl{s
zh_n&VLLq$x6<{#9DJfO6wz{r9n6$^#$pH5eOe?tg=5rMPhap!jy-}l0T?GmlEw|!1
zdXLfCV2(r&rq4vxQn6fCCTa3OxR$K#H2RE;LF*@?-D|BxxF33kw&vT{tPgVQh=;Li
zFaaQ#<18`&SFWD5zO6fbdpK%&l=GQLK{hHR)I~1i`DV}E=-+dw1XR~OhHm`)P;v>g
z^i`Pw6}R1$iD$o_LkHW-hG)>RtkH_%uhx0(>qz8q;>LF?eJyLYW8hW7)n%8!WD!#{
z?H$OWg3R^f5JZegGPd9Ck2$<LQOE^hp;WA8b4rh(QA&Xf(L`@2R!HnG!Yg+AYipv>
z4w@;lvZgub#yD*avWq*YmPHkOfhM_C8@mxbNP8diV!TuhtFIjC;T^>Y;Zo3&<SmG%
z=n#6P9@FM;n^?`$*OxA?EbeU+vo}`L@Y**Y^?2x1rXHe@Ika7JO|S>67d-JaPcKGj
zcNA8O)sj;CIj;nL%D=|+*_`sT%beZ#GUd7Q3(d|fH`h@v;tIN<%@{7Hno%0QzHk?F
z`<ji8^x*8C1|J893s9pf)l^piu?Y<9;%4*B6?Iw=+!q{&oz2y#h?e_o=Iah6+-4i*
zc-cF`jz38Dp3rL>QCEXbp|}*K4@ARd=p!NygQAYeRNa46ev-`j_T5@nJt%KJE_HLr
zoO!uafZIp)Sa<*9P;#QTo~5dv`P6aK-luc?MqY3Fb=Uwrmyzy1a}2w)y@vP#6!3u|
z{_Xl*$KE^Cy9&6K|3G;0By(8$8XtniFz<2%>tcGHik<j+7uKUQ$U;hYr7)8GMO%!}
zO7h>6AKU0(h$BChh@l*e6!9W{_pOc>ANFgpM({ZKqiFUsoesmOXnVm>5=qqeL5xfD
zTDv(TpUwN+{3ef2P3CfyY^6{WE-ytAkfJ2#e#+3{5_QO#xd+$L!g4`O9Q$qj;g<l4
z)RP{a9iow!?o)1UlE350xJm;y*K{#g4^`+$pTCi|GFs&Zq;Jq%M&EH&q=}P`y)g!l
zzto%Wd#m}dQ4Wzk+!R@L;&@;&c=AQwd0_^{4`GwfiMh0pp1Y2?IH?=}6&h=R3IZ($
z#W9f*3}^OJbjW?VV_30M>3tKz0PJNVP>h^BbH97fiDP*LYLwHFLK&$^P@lmgiH~?|
zl}E5)SO5d4C_#CMc;u~`);FI|K7T-M>}exE_7u;{4pBQ#_1)d?7Akk?6?#n3Pv{s)
zi94BFT$GGDR+Lf+(a7IIVNy6Q-mA|K-n-YgJ7iDx!E$5dc!M}Kz=o<?-t~F*=gNVc
zBUQo)e8=FH%^z@UpG5k5y<DkPq)HxQ*DkkKms^XeNlZyMHMx#osmbo@Y-$pF;_})`
z2P9;9-N|orw3eJKGz#^41h)X=M~}iOgj209xchE3*X=IMELUJF(RNalOtaYS$elgd
ztr)?}m@lZbPWmL2Kgz||o_DrpKv^qC@{8THWU0&ZC$V<&`=rk&szI)Ru>M>{?wzf*
z78l!{ZW|m&JY7z9ZoOeB*-20HQ?kI&_N4MpM!(bcOT77NAabsP=|@Wd;g@8e+{Yf^
z<(G<ozFX6D^2Hi|!SDyPE4WPprz#L3gNqS)_B&-WKblNh{$#A^=w>?5-g(g7lYx;f
zX0Pss)I)R(xzy}zUF$$sX)<#UMl{y#banN%Tl?56_p6sNG(#RNWJiq<7{+KRI+W0H
zvNzVDP$}f$k5X<w=jl`Wjr#2Lo2^~hgQ-;dl-J5xLc@Tgb&3c*4lmNQ@$?VKoaZI<
zO|V#o{bRd{#OL(!&8x&O(yoQ2l9hcL<aZbmS_1&g$n0{U0wb?|_BhZkYEexF*|W!w
znOGMy*B4&w?XOx80W%=rUun18TFQ4oexyDJHlHT?66c1uSIM9U^>~jVJa3=*Pymz{
z57LLf#r`A*F=>2^+W~#}lI+@^UFulgANA<{)mo*VtrZokW*DnPHLPly9shunHxu-s
z0&HX>bvD@(fgmB?-WYn}W(1E80;-b;Azk34;%f%qjNk9A9nx-45+7x{>&mo9zb#jc
zMhdb;uB8io;LUk}C(}{Ozxa0CS*$Bz?2^gH%sj2FEM4rfKDqEN*|SG}%6tEN3k9@g
z3DG@RUW||7EfMW$WL0ptt{D_Un-L>PV}2e=NNmlZi+V36epm5vTXP$w){af;GO%zi
zXsfXQtu^N~H2{XDjz*Xuq5%KIu%&Bc8{ClmBljLjDDtIB6iOoGey{<G6EOtHfmlH1
z10_(btUfi<?zU89K5Qrs3taQ<!nGi*Mo7BUWd|9A>WMYxbW{TR07Xv>bS;+|cz4@t
z*D=uwGx;wcWN%?c0Jf#pt)a0_(czzouoUDAC4@$4%Q=a~ktm^yi^J*b5YXq7<O{mk
zfY<9azVT0$J#v7J#TLEk4VBZqP<y{by{gkNgRA1!hTm;`tG8#s@6sqVUDxHoIdl$F
zZ9a}}JxF{)kFB#bj16m4$p}t&Ah3#IdIL15fucaw6|;Vp@z;tSFm+HZ`0|0C7M*Np
z{5QM5q2#a1r+3xrHFS#i*ob_F8&|UEy(`3=Wql~0{ANdo$rJfv1{q`pz`&{H78qw9
z`g5L!2eJFgb?@q_XHriWa-}*{;WNn8wf2q89}!w;HdohBp=V~s%C)WM_pS3j@x7zU
z>OFF8)En$C)mSvs$hG&dJ`*&BJlg(YPTr*FX1wlr+yp|jYgM#@h)P~z7BU`%q=kc<
z^a`C;(UV?*-~e|*vBpnF_3tV5NqTUm)1sL>AKUI9%N%PTTN~wDXXaRQK?3BIzUk?5
zFZR|Rc8y9I`7;gH1}>!On@hREh@M$vLG?+twy2GD`hPvV!l>ZESZ?TT_f+9zrP~`B
z`k|iqpfCt?)l8*YMX*Dc?X0U_V35%<#y(4XpVBd$HC5aIt6qq+<^PZVnnx?yN>E1(
zR2nJZl<X=~LKfG-3x{AxM1&mtj<|y&qEBpq!zL16)I2tM4>4uxs4R^Fm0DkmsUaY>
z)xV1L9FsO|Fk@%RlSMi7DNcvEa)kyve?}>hC}sDvB|7oSweaE~WqOHe>5KR|Wuwr>
zr><0N1b)!vd~(<1T%&s@zQx;jnQ9Q$8x1(Gl|iwyh_Et={1Q{*B4YmG-bZ0M_}J*s
zH~3-mgYF&^835x#J}lJghn)^$Yfy~+w?R5_4E>Z2k9?jQ5pGLRSh;wo-|yz$S_U!e
zrAY10)3Py12MFsjIQ^cU^U-_^g|2mq?iqVNWTfyIp_k}=p1+X179Q3)G`NRMlsamN
zhG-!oWLD&hq3e%-!Q&aoU#>RlrD|QrlM+-pOIIIAw30>%5(*INFMN;w@ZG@mL%eZt
zKg3&zw2HGss*Z>jPxjg>YS}^qX&Lc(8Qi`z3d3W%5}P-?c|sgty&mQ>>724plV_59
zl8<uQ_#HobRzhxfr#$jw7c-NvcqaM0ez~_#ot#ne$de3cMB*9RJ@U^SFG+%vWQ8AP
zp_43j;Z}pl6L5!r;-?bY9VZq=KJ&HNR!1UN7uyKoX*C~QU+QSB(b|%ecTl&5PXsoA
zl|>12vv%DZ|B3NH;p*Dy)>`)Br407LW%1DAocr~&65lJ=r&7oL)J#J@%3LVgChUdN
zNtLmQU$Ao;thVt<xgL+7ok6cjXMeu-Y)?i^h1ELRb}0hkLQB|^ou7N4Q=2&M<b5Ty
z11LrXsh@xdtob!DMypsW>qqh9n~&$q$UZ6~zW`O7P%H-jgokq;0~M>;Ra0nn&Hm6V
ztt)6Q;bQs^)FHHk=Pv!cn>&(^`hDFMbOV>QmoeP<H%e}?XShUjK%Z}}Eq0r8h)4iV
zSX{h_25ZU|F6VFl6!nlM;u883Ziy_URD@`aQqWX%2DxU3J+*NO>PgsWe3)H3*Bx)$
zI_a$kO29SJ^+KfV9I8YLS(aGbg`0{yl)w2ccQfTQ_b_)e_cZ|#*&H2(JP)M&kRI3O
zC#VzOeh(YOzv}2*-IY!zauJpNbW$*EBQU`*8_vv0#CdGWiNMWLg%M`ZtCBm{ay|{8
zMp3S!0>5LatWq%h?X?-14tOBUx?cDV8!yB3DObfN!>C^IrArrr2Mrx4T0BT^?IlH3
zKj}a+G<9=6WuDdU=bH!U3o+j7cr|?(oqy<??XMAPTaM6o=Q!!8r%yp{sk3(dbWBZ(
zW0EQ-efak85Wq@freA>~9m|jI8Ye%3!;xT7RR}#cZ9bzJ`b3byxK8N#9(zB>cXnp+
za(-p?s<d>PK8vn#I=(^T0A)b<e~z&t25&6%*j^h!K7u<qS5rcmTkY^{uLc(-UZ?nd
za({kL>!SD?@S2GWlgt(Az%>EZR$N)REOlUAtnKI3@j<N3>an}u)K8ZPN}X*>;dSul
zJ&p;3dtwM`RO9>bw>Xd}F(1aRHugEbkJI>O;$Gtx>}vb_SBBQ^hj|x~m9oaW1t)_i
zP_ic*p_ENV2j|foPqt6|b~`bUh98dq^xi#vc-vVe=a_ff+V=2jh#pOiYOzs6V1@8>
zVsq{@N;7_Rjtjmyw<3ibPoZewUv5fRlf&S*oj+GLA{Ah$Q&6sSuQKIuUQm+5Nt-=+
zaix5@nk}YP?I_+|Zv0lwXU6|V#c4>7X1G?nM!EqSqB;AF7}H}@QM3RVP#{#9mHNy1
zDSkEJO7Lcb|DxB59}*>1#I=I=GCr5jFvbD!_Vn7E3i(obK*TFw;CsNI(ZY}q$^Osk
zW@N9{5B5Y)yjKKYEb1+Z1~1K7RJk{6FG~EQNB;<64YCb%axCW6QgF5TgZ2z!Ax98I
zwERfJ64#9+#4Gq0)j(NG!~4f0?|F5p{az0nwY1WJ`{J><=?*lc@GO!liB<s^JkinG
z!guRu-WyZ*=|qO-8oeN3u5*gI2WCv=!y-~ttyWBWtj5AdzYKc)6)+DqidER*?3Uvk
zDt`qLBygj-b~EQ;Rj8N6a-)jUf4r7c>TE`Q-#Luj%<J}+x7TwBGA>mS&aJaF4_T&u
z)by=+j<(%MG_A>1!Unq4Oorj5)gC2wbeVaOkO=gWD`uvIv~gSAVqc!8{QU;>r!n%O
zQ}XsA_(HZ)4l@~@uT6sEhU7Nqw&Gr=2E@(Htx4K)Mj~FuEy+{pk1iWo>*pMys9zz>
zHKJ@mI8!0rT1ZWqydyu>(d0QORoL?1?^M1Lgn5M09>eaT$Dh`-hpL6BT&$N>{1GEJ
z$&u9lV|IPo)u_Aa>(|G`2o_cvnV@+c_PEEiEZXeS*R;MY5x571Pdw!dZVVWHWCme4
zv(hbo8>-&>E#SAO#;D2)Mq=|8nR?@`Mjx#)kM3-HZ2_BA#RUb;BGS-mtk}D%!Uw>f
zVAfaiQg}XYk$C)D-9C_h#vvkhQSK7XN=ZIdwsO@LJvAjh8p(}23EulJ^%!pcu%d|$
ztyMm@A3Pz3Va0&j0U$q?AK4&Fv!@sQxDM>;QX^B2(xJk9+^{OLL*x;+sZ;p*m)aTJ
z@|5S4sf3BnqB)OuzoO?Z2;JOGz|vJl@r5wWj^Da>yL$k)9&bZNVr<7DZ4AAp7Y@yx
z&x<;EENwsdmDt4MdolVF3w9c~iVl%?=ymBFR$TO<EtZLlc6RV!N^oRK;2=xQ%}W?z
zccDGM*1XtW>!K!-e_(G<a1luoGq(R((lR_r9w4?v**9Zf^85sSIo2}2hMsN|JX|68
zuu+V%QG|}KLP6yA{BgVZ(BS8>ZxW2$>@Is+gWx0X^%&pAJY410xzV0SsXpuBV7{w)
zkLWS)JxXDaFI5qls&S{oRU~{zcMj_ktMNd;Q^U@~Y=C)tz|dZ#{G!R;T>N<RlI-FG
zQt`i}@4NLK|AYLkgIU?Af?_}9Wn8Y-#=H4(+L2Kg!&!L6@USwUu>E|-&oed#Ic{31
z>Nj*3hA<`SxH7>iLTkYXsH@R(4SXSG#RlsD%1>amg$nFs;s^Pdq1)9VFvF;`_|$|j
zu$+z2jW#~Y_h8nhs|~xh(wu8wLYj~PA12tk2tkHfaJ*#mS>7H*G3jD1%oc09_8+AU
zw;%ZlMGhgPlSSN(PRn$PAH{>ZEWq=`ekW@febV@WfDN+kdE@!~tUf;Ww0^tX^2+KG
zYFg;>2Zv>w8(`KlQe}9QxZlpvbsY_V-}q6!`)cbFOqK{0(bbIR*OzA{G1Ts_onI1r
zRI`~`Z!gZV1BF65m_EzP#(tkX2i^uCpO%fN9vqABxSaE(HR}i%Q$2zW4&D5fK0D$$
z2$enNP`xo?X30Iq$GZn^jG^x|#B^I6lsxazHcAvD=^@)d-~`2_seOgtp@@q!^1}t~
zDj>wqq<H?Iu~8kN#G&jV$y3f4J5=(AnS(G7)CrBm;Ug@n#YfeZnYn8F;_A%mb=Hb_
zgQowjuce<bb=0pl6-W^u=nTpbhA9^BWvqD(XSfxJt@N_@R^$f;JAUX_ygAFF7<i^s
ztyby^t8!0sCi>J&?sICLJP^ke_9Dwb=-FU_jpuvMMU5sT-qox5(xLY|G<+!WTij#a
z)<Sc>y(qh}bxnNH#;^ORw^n&*wE6aGcTEs2SIhaelYir3wrU7Z%W3-H1oS>=c;1gv
z77pug(@`O#IowX@XN|ww=w2o$yf++N9OyzM@}F3y-><LR{z38+k*$3NKlcl*y#;n@
zB$Ce_2Gv-M$!#`vx$WMVky0s}gJDjEL^<uo)10oj_?^xj^da@c@0rYf<8c?-G`R7`
zN9YH~++f?O@%N*da|fasx?=x7>fQuAvh*wuEgLWs9I!BsGa0~$p}m9~k4xRH?jB=C
zr|Q(c9(SvknHyYP+FJ5Rs<KMz#blAk#!PH*gaO~V+{94~fx%%B`&=N79%G!r7v}0Z
zV0;ZR!q_mzH;%{y#3TXk`@R2KrBkJ<Zp|=mdrB(RsdN72`@iM=Hn#q>{i^r7YEU8e
zu#gU;9BPvZE26Mfz~rR7=fUc+6PvE)_rdEtj0HaRYM4cZl%g^ToG#6id0p=3FrvdJ
zQ$AOJ<-z6)pU)f7zhG>G%`MXZ?4phgk%o}wOmAKB?9fs+s8#X5QmC>_c~kBbd&G0P
z925De7ujwn??%k8@dm`Qo-*gGMP11Gz;0qC56Q04X%^C}zotF<?T!>-W^KpS+BVv=
zoRa7XR*(ApPYX>JI~nP72p3EwvSxLiG%K|GXipE4TCQBKrgW7<8cx*V)B&NfpW?1F
zNvUE9g!BTa&0=|5_j+`O*#BA@k!d<{n0Hh%lDARs1NP39G2IQ>hFI}%8g(zuCy`8M
z%?IVy4$e(YC42tH^b(1=V5rZ@({dlfqkpW+r&35Gpt%^rV~vM1LDTSx!k2fAIbF>c
z^A+6`rI%M^Wa@~m$Z49|H1gQi#ufGnE!uE`_}aMoqKE8#+V7%|aq67GP6J(h01^XQ
zx?i8*lqtTXrmeEgz8T|@xj%ZhJ5$MX*+MCk%ORDs!G3W#HApY9dgS&$RI;hDGSfha
zDngTQHkKPCBO9Bz^Sx?Zjckk`rl)?UIcNKyq^vl0wDs9KWTqbIdA+9FU3?gLS-Ki!
z^BI)`=2Sp3CdOK-Q$tFpHl#iYWPfCz#Ln4MF+W~(_}sj;WONSdNqz13XDDB$lD7XA
zp@;NErAkytGRrD3<PG{eV-F9fQ!FFn_4-gb@k%xsJ0N;R4=<gI<E6J@2lU_MQEzr6
zAH7%a?|4_An_>n@FIk+E(gqmYLwY?Ap0E98evQ8#{Uc6w5u~sCGOFOzso$&boxCmG
zYE<yS+WNz2R>U3uP>*l#H9XIEm@hE8AcS0n!~Yp;cWH5}2lPC5zgzLT)0PMOp;0=t
z6oTfYbOYf}g_RgN@`dhP!)hv1j7&ReLLiiuia8WTj!XyE|Nlf+9&83_uqZmLVjlS|
zQL2n>vggNXO37BqEC5dt{|bI2#(f!F5Avc~mRUR|m3osrmv$*VYicl5u2fvF$Thjg
z$KUGgEvfB*W>uAH2JLi)Owtq?O#Ju1D&AEf=55l$rAjFJ2V(i&p|9J!uJAVHk3q|T
z<+%nxtMx^&l_Oa~j6=p*xjwnao&oER`LG_#)}JW(B@ufnJw|cnW8!e#G=1z`Es=P!
z-oq{I<Ci2FORX7atL(gya-l!&dU1G(Ab_b^vx9OkE~i6gjz_=lUbE3z$&s?)KE3yw
zuc3WB*P32j>P!Q)?sVJ77g7a*iEUh6^qr&?>GgD!XE}yS`?wAJ!(nFT!{4j_%*C-q
zJ}<bGocV)SXuFry{Zwx?`Frv+ju%Y8*P5-@D%E;fIp}F-#RUP8<IyUl4n%Cofxcpx
z8NPYf^Sbr#FqbL`P9?00HUht<Sk(pjBXn3}L*BjZjSarcTsD)bAwYp&rZPqio`$Il
zkfTDTZpeF+A=1v|)x3~K5Qi?wbN6Wa*zN7-jSPLG69vCFwB9@X{yjUifQU4bg4O#I
z|3>&WG#cBJzO&rA0qh4&T}*d+BX~ro6*}4UYb&13W(u`bsSpOz#CRT+aj}Z7X4%+Z
z_u$B}@u;Jd`?IxN8oDP9i=1m$>3b4B&|JM`>m{%ZlnO^e-U(1_W4j3xu{?)({?v`d
z=6cX$-d@a#@J?sQa}3SzJ?(6~iF69V51C4;mdh)3fd`T=9wZ~DhJWLEqDFCa{GWN=
z&ae8<gYO3gmD2U{vHO#Sj$|#bYCUYCkI5-=M|hT8yZLE}5pOJaP<k70ZTxoheLRb+
z2sQ=TN-2BzK-O^V1_<$(Lm96|^e3{BmGVBd1VRA_WY>+2u>A<<Ga~*vvT_k;!t_I5
z8Mtg{WHamWVIU|dOdDm2IUPlLd^Gt1z3<VtaXmzjIiz8XI_o31^NzhwM5%a&4X^yZ
zE^G?<p}BOiBnMcMnRI<eBUjqJbzNg|%je##C5p}PNx{nHeD1#2rxVoE$s_V8qx&6F
z_&OMcqM2$0xfYQYCA2B8rJT3zfxY*SNDo8QkTNnQW>fpCWBpB#(Qh|MBlAm1NgK68
zwWMAJgw*68P9WYmTg+BbgpTSC%{Wh2iiGP|oUXK2^7uFaj!L<XHpFo7TIq0`v7=7U
zBKB{1!q}8IR>ZZzRahz^S;IZgDOyf0QRV7UD9Jxa38W6nFQwNB4VW|ac()Cm%V#R3
zw9*85`y05}$c?f48MAa_y|r{kKx1={r@QY_$)oKDI+V!@aj=pMYH%ZbEg`*pRRgN!
z*6Ou4BI#9iB{kSx^akcINjmo|WYOVfqeYw&-Sf-n!^xL>>sAfY>3jik<!TVU@vwXk
zKaXGoGM-J(FPWdGM^da9D@V5e{ZO?CA$=qbOq~07Y<k7X6lHTOm-Q7vQH%}pg;y#Y
zq)n^U^A(-*`9>uhpyO>eRWEwPdn`JS*@OKPU3*Z8khfdc-GsU39yg+%1*}lMD>_Ny
zN#kR^fW+4Mxnb&)e?otE>-oKQv_*y4-Xlib84eVqzVv5kN5r=bf3N=B%rgHonl>N1
z*YO|Zmcu?sqsmnTofrP~RdFby8av}Hl&xU);?W*lEd;Wb4|~g_D9J$oOjex-*^B6}
z8B?>gdcF1VeB(xQy(87Z+!=m+Oz6!xoajeWY0JSmi~T0QMPVi<MEjCVXejbPhGIH1
zoj7p`Cq@zcVaE>+6#n11EQ-KWX1`xK432KLcqEy1#1;>KuOYTL@#lIz$<NUal0{%_
zthg8EksXf0e{eIQKRLWvmot}Mx7=KrnQJx{&YnBhoIic$)VbuDb7$ty&73`Tc79=Q
z?%eFzlgYW{*$1p^!Y{gp`bAwe<{nI;Nez0DfuBH^Q_JsPA77-c=OzM4jxa1`E?a-<
zLDtds1cXi$)vLvHP5H7bB0fOb+6Loqb$QDV_(JdMwEPXki+@H=?VMKj&3dcJWIQ8V
zcO#EKNzJ$#Ad`AU#RiZQ_J~mBnwJMq!1hSqSOF^oxo-CLkiKpD4lxeJ5a<YeBTg(h
zJ^7FIbN3c{&Id>c0sb2}f7-TFW?e%yoW<!o4s)Qtx;LtpJ?QKd3M#g)gt^L|kNqP@
zL&<a$WB{S$^C(t0-CA!h``v~*(u4?{GFJqyA~n4_Q>UlS$bK1~dG1R*`hcE@_?HxF
z6;qL+GQ?;J#WU%Ps0FSb>$4PN*?*M{IUO&L5}$;u^PG=UoymvAFiKaDGt{_o=Cr_6
z_h{PNe-ZuTOP!UOnVIG0ssIee{%pUdhc08&!bhbRaIbE4Yt$PIA~%|1hCc4P<mpq@
zpolDE<eZW`vce?DF8D%rA!@I!`@MVJqtk3YK$*Zos#ZYp_gk~5e=@lQSw186Tc#$L
z5y>jWtJcw-N-)41QuRdiXOYbZdw#4h3dUT3#|2+ln(bJ9{IR!cIzB&v(IwH0D;2aw
zwAN4^BY=>`zmMqqMc>e~Cj)8<j!t2R_Ga{34Bj0mYtEmN{Qh1&P;`?x_BQ%3p7EJL
z!7=t!q062ENLfr3Q%Wjc7dl%4J-kQn-_~~xWt-$1^8MIz5+i=%5xfD8KqwJ-fcSXM
z7(Vd5MxU>3tjx@>)fX}-%e5-CAbPw*A-zN5hZXuB{~7bWXnpPc{6Yr3&BPe%_9*$i
zibMxFiOl7PTo2Y$^hsxLqKKRXffrX9@Qv~Jgao1Ib`9F)#m3D{@j{fE4hz}yjj&#u
z&R&@g(Bv_uh=|yX9OqLC>t|h1NzPeVwt4^Z`S#x-A5;ombz^ybDGiY`-MWlcP@y!8
z#XqB$>@+>Tf_%|5l6LZ?f-0v(EyEQtAc{j<o)%QB4q|x`4SyBl7vOn@zCMk*K?V;=
zPFBn1Y$nC@>o7NU`s5XQ9Sq-p($5t=jUs?0bgYbm1r*wmTUxvRC0+3#@ZguyWq|9|
zCb*!?Q`RJjx`N078?MgF>EY_Uq%N8wFS;5F=s@_jJTH1Nd1YfxN-cHUA<XSKY>c>g
zfJMJ{P(3Jyr9!!=LqB_MS?Z<*S#<;_;GfyoLdw%8B=5M8tJm{6FIKZh-{igyt!i?c
z<$*>%9dyU<Mzw0Cj#xGdC?Y?+ztUg$9^nf{ZYRCoer-vffRD~#HrpOPB5~U_7@rch
zec5~Vm2Tasgf`8npRMp0QYtG*sb`})Lkbybwno|3SCKB*1tBw!F7L1uhXDZ0Iv;%A
z(ep%v9*?NOT0&)APMjx%FC2zb>G?MYp&jkoVT>{9>ThX#&BZT1m`tOphX5;w4Oz5L
z0i%(Y4CX2@N^`zGRP)Aus#vXOpcg2eV(NZu?jxXOEOR397LP|D@1mM7pq2=bN?A*?
z2L-M`!)19dno8Zdrb&LJFOU)$a-sfd{z|o$JchiZgAw3N=pK)IL-(^9wKBq}DjTG6
ze?@rIn+?`5Zm+-N$YY4J?0mrQi*7}GIy(xzQ!e7HvL2xqmnjfL5{F0hhaWb)`?FfF
ziSgdaF+0ZXk6Zd!{~f}mp)II!e%Orj&*(#eW;Jx&)6fdnA)QlG)zCLMin6iZe{S|A
zP`<&T>l>$20k+`~aBy3ib^pyA{dR-qY@-*QJr%r!d1XpZ>&g$mY;CS-*5HU&;-1p$
zxA)9plF!!a(AE__TzG!r>zrIlqQ){3)}nfW#S`->DLvWKHQBGRZ2UOwSL?ViQPD&Z
zKR>^|vDT~qtLQK*5AXG!I~kUW)l?CkL&Q-;z4U#0y~l41W%uN0_w--Ekxx_{v#@+x
z+d%KvV;uVf+SbGOAwMRmp_&$ChH66oDLvNBKmD7jPko0bX`fIKNE8HT=@yB^U_|z8
z9n#y<%+(#Jw5dx(G+E4K_dCcd2gNUrN>{@uG{?a9ZTO<K1)unBPp>=`R%=LbL!ysT
z4pRU)@z2^*XH_2U1oAqi|CcVPtAC)6qeT89(9LgPV{Fbxef#kKG#bFAD&<UY0R@of
z1s{+H8QycZpIcN9%JA01U9Sd3g`GgW2gcT9xJWR<KVu6ex_y!PS}Kd)l*;o-GsyEr
zs`o1IPv|806Q0{C=@nvV<4{vXAWx=r))CD^2HygdwWfLQm=`}Ty_)i9E|#k5-Ee^l
zG!SXb(7Uf}DoM|hRbVIsKjdZ9;t3kj+~LBtWTDKyJm%xN_h)m61I<Y#{mJXCWdMuI
zFcGaCh!%l1*Sf2f1MX*RvBm$xqbH;s7qZ2Cn8~Y%0&W?{paKzOz?=gI%uhLBl_$w-
z_@1#6oEfhctHkJE2cPNHzvfy4JGsW3qW&J=Zti51k>PJKNEuO4KA+V5cdyuw{{|<L
zX9sCo!;fYllR56mY33_(UCz|lAGw%AM32B5DPXs4gOyk?*S+niSbHUbO`ZRtGrD!%
z6EmLuDXHZ>1xMK0?Bbd(c$a}MEu(6S%5@la;>z0$mVTNR%LOR<8yy9tpGgM^qmOLQ
z4yBKTe-rwMnaeNV>*-dfE2%=cP^zW^urC#8Y<TC`H+i@fVrlBRdcF{;*a7liCd4Sd
z!$Z65aHN;8Zy{^dnX;gke?0z(T}$VUkVV8l^Xzkej%_t4mCLzIsBxrT+^wqFeopVz
zlPezYfqjzART1iiU*x)yyf_v^jDv592uaI4%frUL#=j37#l=c0RV$Yi6FWXY>0UkV
zs~%rP{E==ND<$1rymR9FRGw8Me<<3S#Rp9O<;V0n+Wom+Ux>*J`r<O#Of2L*dS1z~
z9{(b6%9rZT5<j7Ax!J{sJL_;f-ly01ZUn0#M_So<5?PPZH%%HO4R#;U;b+#~8~g7*
zc0b?gG_TF4TQ>#nBwi{%gSQKfG^FS}Gs)#|BFBZ-?S3oq!J}$Z(DQI8*u60{M`Lp7
zj9HgoRJe-9AE}ZEhn+_Z9en>y)UyHMEJ|r%+pF%xi7?Hg6(>%>-SHrU=GmMsO-3kx
zrQU1T(LY~jk=j<umP@MgOHNJ~1@=rpJx<nPE92SLEchm1&O)1&bx_{;Mr&=Zv9Q)!
z@oHYJG&_t*7hO>9k-SG^t*DIELR8FxWK<wPW^PFg$^az}jYVe4F(E-m7d|xOUcA@i
zdr+%VXhD%HMnQY6rG2c33<#W_n^1A^NbO!)*;r|)Tny<kfj%C+PeVYzT_YLq)sD=0
zN|xSUE7^2@CWCC;B|X3P?<#qx_f0Yr5hOJWN3Gqa=u8T|C=mly7W<ML)%BOx<6W{m
zfsZf}qlex6RyXGf_#UdY8d_u_??E=oA>rIIvOy}rd`kxBlrL(J)VrK(n_AflmdyGO
z_I^d=J0g};3r_mN%p5n5uJw@_uGWXj>3FwZyXbRT=7KiZjB5=CyVFL=dE`Q_5sg36
z@{fs@7{U7)!hxvp!0Q+jmLqXB)4lFtxdhRvbE~+rROG4AQWNG|E<Tr6slLGFSwEs1
zz~`z{a8VbA)OG7W_H9CUSbrAk?lA7DrpNTeYL`3<AQQuC0S%CZ7AQpdB6$I+6#XE4
zQSa%up?I|Cdhd5MuR(*+`PI4Lk{4WH`ee`ohX=LmGtlQFX7A$qA{}4!ojIm{BCBeU
zgf;sodR=zB*r5qzT~u<FaxOxFCRqoXPjsyCg?bMU1^3Eq)5x6%WzQba&)@U)EZDjA
zLb{~elkjm|dPNl|zoGN`uoZ^q9~?OPr$bY;DhM_dUUH|Pk8$%LD7R6TaCsF3CY@8%
zu~B_V%`>h(p!pMgU8)0-ByyX`L9!*h2g5a1u8g6vzSfkYo?;^d-i!Z&igys6x$`BW
zi);Cel2P#5&!fPltMjndv9kP$E*X@Ci5!-7*%5}Za*JlY8U*hoW^tq}MlrA}4;{&b
zfGUA^i@qu2-v3s&HdsZqFh|!h!RpCHE+1?6(=vZZi1y5y2)}pf`;Yw{%0389ySlwK
zlKSHl@H!qj9oA18cnb-;Wp1?0ck6XB9tn1Ed9J~~^La}db#cRdsSd+m2-ZoGzV(QB
z3DZU?h14+%5;pdJ=MmcXF<zj*86OY|88C{qq|fm9KXLp%nau@JK3hqJMZ_O2BC1PA
zbTwgMC9woyu8nZ6W(VD2Tlf>2L$yGv)`kqeR_i+Sge#E-IaY?<K70+r6Un4iJd8>t
zzGvNF=}=|=BW|7y3bf=6MwLjq`A%S(g$(*G=PD|uL5Yo1vh`CZ<&}F%zcXcv`XjfT
zkq_jtWN@m&5x;XreI4r}7!~=$3u*f-buMP6rx!O?A2vb;Y)Ge;Cmz!KaqxQ2c1@!o
z2_UVouCT+NXbV1=+??Z}G$tjI2suhYnq2(i)-zSVr5k1%*$XfL1gH6AY^UfA<g*Ki
z1im3`TIOc#?#-|D)(v?E)l#NhDJvDhnaRrLSHdZ<`x9Z8p!2RZZ<vVUc5_Jw8%i>+
zWdFZd@8#Z{(o@z^VBuc<w|B9ZNQT`yLv;OILff<p2!4cuZ~6XXU3@=RLmrlj+pY__
zP@!cWm6=cQbzSp8EK(*_*O`?LZB+B2%)nL~-Ff_OpQoV#Vx@vAav9yWg@nNur$&>C
z6vfDJ_?Cx(dNaw3pYk_qa5C687@B>9ccxG)AYTg$VLnurm3y3ncKNp+YIcOIuEYIL
z>h(>&Q(*_mnA~7Sk4p%hYWrvP`Gl&s2}^5zt+l)WB*M|kl`rdBTeR<}mvR7-Wa?Cw
zc(T;mhVsXh>nqTH=IY6HpCW^2#whrGRH7rnTG=n*N6G)D{2;!~Hix*SZkr9cU`Ve>
zCTWdotF7yAu-mRA@wv9#oG!nek^O31m|rih2=vfI-v^;h>KwsP`ivI+kT1<;Ye{y7
zPzjWV<Lt=fJ3ZP&Y+_VI<WY!Xi1yey=1C69x3pA9rL-Q&FlgwIGI%I>35j+Aq{?_G
znO`EHP6b28!Lp6Z)HA6w36?3>jsJV{vW@kHbCTK8TA<Fk%(#BJ%_sDAiFebNV|#4E
zZ3SCg%KN&KoJ3rnadkp0q6XYhsf#^NhDveywEG)lmhrdDVbvUrUi7ht%-sGR?J!us
zrj3s>dwP|`VG3y)oXudV`@imZU{dl>YxznYeN5o76Z8cwBY-8%Ld8jSP&Hgw_0(hz
zC6y4cek#Bi4IfU9ckzmJv0N(@BCi1!X+!Y}<J=LsfLkQ~r>9#cPt~(U;2`N*P^{$w
zd;hKO`xmp7T)tXRyogE#>CC%7at`09@4xsh-q^tAGlHaMYl`oZT-D$vh1Q2N$>mDV
zq7Q7&T5w-49^0?h&uzGl``FE+-swmNh&>UkRrUtQG=VxvZG(Qwxs<<;y+ziv(Fg%#
z<u}kO@sjHB+R3iY$>$%ybv)<y_v9T6$_0sWam9l)P-eTOz_BlZwTlDde11C$^vYpB
z3){Q`CqqM>!v6bqufT}mQVPHX*m*aRc)MPss~`5_N1SbcL$!WUsC8qb4fZ8T4hmsx
zXn0>|ngIlhgF-}c268pPED%N`IEC!h&R=Sr!LQ>N#@_hBR0v+JATf)}@B2OEfK1(^
z@4NX~k!6h~uzGZGMUX$Rd}C)Ee9ZBm3B<b=B6#M~I`6(m^>O-Kj~<3ITa**YV@&T+
zMcz93Bi?Nn*AYZLG}*$k9&(qAN>ZT7XYqU*%r#K5;V9fAb0kKf6#_%|?J{-A3li^`
z19V^Pt+dLxeZi}H1M}ri@rf21u1|ba)5X>Ux9bZZUfDauDUMrT)c$W{!v=ZLYc#tc
znz7cJg=-05{~VD1<)ztMR;Dc?(8A<rpk9S&*ZH(g2kEuNNYLrP`lWW>Dd$G{r8ZW?
zgP5>*;nhFo-XXILQ92;)cx{2Y)(~WY>v$<4BHN>6^Ov-((eL(#;@TTCm^9o!=xd|q
zk9eAZ<_KQML5!>!e<fwjjoFpC<yFkb=oXKDY1cXx($zvbuU#BG@>D*R?5BgO=xn^P
zf9mlU6x_-eDz$Q2muI3P>$n8<2pWl0U#U^>EiEktYV_EGN^v;p<o`~ihqrX%c+2QS
z2s-ZX;~4#RN2&nE&$0g*&n|#km@kxb`CM7$BN)DmpS1tTgt=_o5z;W%j%%z?BPv;L
z&B@8R$kzg)VYBB~yX|_&1SHj<ShMhT?tzzQLMO|N(-p^hFb;qmxoTcPSH0(odye8K
zVnfUG1N`>_oGVqg<mSRP?K+-Y>Y%>c>|#Se3lxHGudgu&PQLSKR}5_`D3>dlQl=t-
z6!{cQGlW?w^@x4eKBD<w@}Xg9<+&|~&gi-9{v`Rq4EnRIc6H5`la6xbwrngc9^oYK
z(cg=<hl-~uGM=Ve=erH6kJFL5qk2D~$F=vuUOisd8UYO;*X?-ph5jdc)J-3Jp0%DP
zenQdn_DszV_<F?prr#!&8IaWk0U%{*g<+pKVc52<@37;aH`I41XTm67%Bw&k9ysb`
zib40jcZZowSDc+jZ)|%x=FR2yViRLGd@1;p$JaAO2+wS`fZl*)5WRi|VH(DhH;lto
zuJ5w$lrK@%ZtM4m-4oImeOytLUr@uwx=A1P<_csV+6yeb8MY0bWLQ0{CNdNRjEnj9
z{7QTMR%1?D6W~q@EeK1&0?c{Y`MmQ5>V6yDPQYR0M2wx)4=am1G2#s;NP}^S-h&^B
zZNFyQxk{mwL&JnjfD%8*@@uUHa*e@V6F=zf9b8DYG|ZGbHc{4{5|xWjN})8NxZnp~
zG%tU3C={g&Ay?87%0Ah#{j5K>li9EaWQ)GU5L#7O;n<AaDLlVR*T@#rrEE4*I0MxM
zCGqK}t;%>GbiGl22>OfB=aQ%E@bhL%X}BaH@-h+sljsv?8z-k#E>6;NlV_rCi10TS
z<)-Nvzx5Lcura>gehwsi?5*63o^bn^OlN~~u~tJEUn-~oj$EI=qKpUB1KL=l0cO^?
zeQ(zq*D_HN?Mc1ur#_(A1@|A3%myp^Wq&UxO7&D#sxzQ(1y=SE&EF0t6>f`lRpi?X
zlxeNEw~_h~%CIP|eZI|OYH9rOs-p#o%R!=Qxth-@y~&X`X_X|!ITK1H_aa;5b*F{O
z&dLiv<;DDzhsxl1kLKK(Cea?Xl&j@Rh04%1$)D0|H}=`yIO~3;n@1H<12x!DZ#G!o
zLBTM*Ci-JXqZ3FK&eduttBATWvY^MP{~JAMydm*XQ|NWt=*%`(!TS-+)-iGd*v)$D
zrl3S{sR~=SczFBA1><cr5Ktj#5@I9ZAiE{S>v4Fz>kcB3KaB;IY}6ZF?dp)U{oaJA
zK9bFZsAHlaPouW;Y>{PBNmo|R3G^7k^ZroNLv*cIM`fJhZPXZw;XLu66$s^708(^;
zp?B+fZheY!-IKe9dHAwDzF3yc3pp(CRY~KaMZL1I(|SxhN$S*+D!<Y;<qv{f0niJ=
zdXRSyT(1j%5jL*E+HK#UyT0A=p(I#y6?RFj2oM~#5@O>Pl2enNjTu4dL~ez-n^X8p
zVD0`$^-k<GuiswdM6YDCmCs-JOYe+MhN*P5ia>OpP@0EQ7su!sNzkV0lYD-CxzcJq
zyuq~**F+XhOw_!%&#d2j)S2o?T?iLtWO_$3CRhR(4W@lJYP?f^pN&lcu(s)5cm0KY
zs-7-t6@gsbQxSN&5XzM>d)h9DKWmCXrl^;PNvcQ<6gE+^>QLYYgCDr7M)%$E`;~#$
zXHlXFF=a|g;lrsgQR(J@io)!8+Aqs*RGKJxs5GhJVzb5hk)cxK;t?@)JMUoJqos5%
zsMJsbG+h&!mQNwQtBp*e`KkM@i%W#E$S2wycX8h4P%-{B#+QnD8W$>l70;>s1)S30
z#ldfQw1ObIJPO4{dC;>ApEDuJaCT0H5-f1y(=b3@&t<x3zs?0y`l``af^T%PRqD!S
z(orUpQlh+9C#3L(@9Cv_-ghxi;{1FQT@aVS$ZKXjew6&i#%#Z7qq!_lk=D1DR_07_
z9RhvwVmVBurW=iwlaptbf?)b&kW})+JZJxVh&uvfm!s?Qp7&lx|7p0ko|#{0qCQPZ
zf{_Y1HZBK0`AUujmO~Sw%Elu#?mQrg)iC-gl;HD&!ktV+lB2)JpVzey#e5-^F6)+m
z+y@n1<aG10)6F04iYqA~@S+ZVj8t<$_MY3`4s6Wmqo4KYERzkQu$0djzr;zNl|Cm%
zJ|p?jesR$u42`o^XiQlS5}n!4-EraljW(pe08W<wjzQ-J{{XVA>LyJOQ8Oud`E(J1
z^th8S$ucUtD5KKoNShn}T+2Z*oy*mY{mw%)*!R!18yxv3=9uLL$wxJI?Ao~LqCU{B
z5qf}nOw((((xB6a(cz6u{WMxoTiIsL<?cOQ^pLJrs@bwu?YQ{d24zR^TtblCqtD;f
z@1jpiBm<b%&82mW&#cGIF8fq^FJ`KM7rewMr@;5OPu(Y6LN_4(b`1;iK|Pj(l^z{y
z19W-FA2mAMg#&iSh}lswXJ*azww-K1ACy#3EFx7Gtq^#`$a?vrEEhQ=<kOBP^Q}8A
zq&R-c-zY~VmP%wGahSNc@;jbw9NMA6$=|4-8~rEpN&qw#0y0ed4i!bHa*R55`pD1T
z>((@R2K@@F$feE&oyC^uZb9N>hJL=bhklN`wqGB0d~}K&Y_=Ip$@rtU*A1`BX!L!$
zxh7H47gt3mR=`r=*N9X4^QZK>jQwx4Wvx_GIY@dkFvSFti#cf87LD;S_O(}z1agPI
z+29odf21bpWMb5<iy{rXn9r9~{yX`y((Wh|iI_n*F_^)t{)NZ)p+454TB%$_5fC|^
zJgEGJbJn;U63;O@`C?ZcLsVo>A(c}_jw!K>b1OQwoZDsASV72JcJ=zwT5A=x0@p7!
z*Or<y-F3!Z)#Dqjl)`Eyuhcv@48_|c8E-bQI%4$G-n`(mDwc}%Y_6^>3UXiaZ_Z2I
zp;wDz;DMXBx`@(*Y)Z*Q%*yGd<7YitltWKA;8K-b6ml&`)l2y#H%l@<TIURXwXsG!
z&uC8k5r;m;obQJr4=Y2qdTI(33t<hFq7`Vted9iHVYo!xAtzlaan)Y&8orOIDe#ct
z55^B7e)`+0U5@073j*hhe?;*f(cgqF4qiiFw$x7)_{Q3=PjuP3XuJ*E4e+2)Fo{z9
zAI4@H|F?$!MJ-|sqU@#C)|$8ab3lO_jB#M}q>p!>CAhy+l~C)=j>^=+(GYsj;jLF*
z-enWJgm}!!#>rk)IQD5H348I@%n-<`#3&^LdY4r9L#L1JKj59`G&oDSARu0-stz8X
zZeiBzieD45if%o*YB{SzVSCq$yyv{LbFXF@FD4zOp;;p4V~w?tv~iCr?@H_lfKzUi
zK{pp0Rs0b;=sJ~hBm05}c%P|@gCfdw)V73_CAC2~qv`L7Z}Zoz45b<XV5Eb$vqEl8
zVeer#<W@XdRK3)xIwfCG<pXR#je^BXTpoa=`J3}K{?)|ckBnPwTt1RMB#ey*?2N8a
znE3Ib{Km4tO;n?myj+U=iK!_ukX7r-hrY<f|DYO$-Ma6nI*g`I)s0P=9s%-4btLl_
z<0|&lB{V#B?|(3sIz)Nm^|g&zaZNU)0z<XAiV*xY6`6Deso0n^oV3A1_*Hd#Aq-{f
z9v`%MK0PzQw;gbAXngu+q+1j77QCxBu0Y5!jt)oHt_ONpM!(%)RTQ%l{ZDkdu@7jR
zbseCU94_%&!$QI;v~D$|%z1*b*mCXetCj695dRH?4Z}0(1&4TMzbW$zk`zSnh|A>T
ziIb<4uiWs^am_=EF+6kyp>a#Az_7j8UBg8s7D&dr^Sh*#sS|Uph*2MsbEoTB;(<aJ
zX<bIfVx;3IJUtLK2*R*h%ttCLfx07^t&+9sePDIttv~l-2P<JQGu;wT>hioa$-#IG
zHWd7(_?W~GvqIeBeR{mRZyJgxW{;>%V<=?=4bP|jL)=5E8QA^_(M{?KL-ZmWm4ywY
z{!wq%pZ3!X@TSDZMM&OIZO9A`vi)P8+(mEbFe>L#HQj`apdU2|Zatz8G#Kx6SgQHF
zq$Z#CXuXVXBu@A;E$5#Ep&EaPUybJ;O%n&YHg+2w9CRIQ>q~zUb-Hc5!bBc1m9<Kg
zfg%A~GkC}Dka&lc;XVpND0xlFu*7-Bc!Y#G*35bP3+fA^jZ2PU8|-AYCD>el*9dFk
zKzm?69eg2>;IjMl{enMJ=eKZy!oR{8v}NUzL+5z_%nCy{Yqk9i#02H}R&O^t;m2R#
z)(Sp=JYqs}@TF04kJSm03nw-&mNN01Cwv?Seb)rGh6irB*+Gi1i(7oMyO$Hx&JY3C
zd;|?~K1Z>Rq7a8fu9$t=`y_Fx!JyP_Y?2_d1s%9;*5Zj<9*v`JR56{&WUI>Hr#FS8
zRRaxWpeQdWdn{}5^dETNm6(wV(snDM0xYP?)5arQOGT8BAZN})!b@Nz8QGKgDVet>
z03c&Gq%-<_V?|Z-Y0R{4Dmy~>`FM)-byTc;pZJa=byNf2@qEei+AkGZx3Nl*k)L0c
zP^fv?QhfFiO``|DM18>Nq|#RI5caFtR}4q)3rY1c-$%Vue?};}Aypfj-@5t3{@#`Y
zv`<8bo}5Yo<7RqTuF!=?CuDRksnoOV16w0t{H>H7az3q(kqQTv>_`M|=(USgg=6bP
zBb1dK<h^<?$DVuR%L|7Seh89FB=KK&Y;#;xv(q#7en@oO#_al<N(`1WC->Rz!uv91
z)Q760JdW%rJ#gahHoWhNagX<%Di_dTp^QpvXvu{C;ks3Q&&_e4cIw%n0w6L|juiNF
zd^UbsKktd|+M`*tY_FQG%_P-cNYEq}VE$&zJO9khO=62OQ9e^DR}@Ie?~{yaK;KDj
zf#|b%Y~s;nZ;k3f6-8Wgm7;R{S7r5`y-u#lGlk7CdgIo=6<&#y+f`IC!TroyjJ?dw
zLux>Wm12~KYactBPie_5or{pM-&|gL^ZeS>B)AJ)ndcNAma&cdae4Qb5q*{~7jigD
zof}IF>y48Et|?(2!WW}Aik>^gx~t2;Fs=jnP#UC-r0Gf*kqC$@c)4gU22G3pBljA6
z5&heZ_RZP$y4W2E%$Jysd-dnzcT+yV{|(If{Cpd(6LEfDK8b7OT*y6kcY0-rZlBgA
zMZ9M!U;FH$&Nc>gxQyG_b5`*8>1>pV(CLBE)o2`I+1`ediSqpM-<Ic3A<(8LUQufA
z&NtxiP^%+K^8%s>Ok@C-jSf@1uutd=<|E^{+VSWFp%KMeF+#YLCu0eUQm9f9<?$lP
zkb+46{FKHDUr5A=!!$a;m2O{rIgR?=>6|*P*JY9<eWe3HGp7#le!bqCPYh+Jhy^bH
zJ@ee%2RgWtuD{Xti)pWlzK`5ZZTtyAN}4C%UeIZsP8O2Jd-v4Wi*GB844!d3!qENZ
zEb0D|1a{0^Q-qzu-WwkMk}jONTtixAR8bxf>Q>hRbw-3<DlhlW|H*0wVZ12B98foX
zO7GeBcT)Bas)aqe-8j%>8~t|ubrn|++r$x#UvP7tNJApka>ab5jOMvQtUZaRBz~%&
z#OV7(6VY_z0rJc_EVGpt`!Dxwh-`>hJk&fb6qOO-L>$>RZ^4u2PH0Ak#s_eG9F?;d
zdFpJOwb0-}m3&3^Y-Z_NV`gJv0SK3Gt2>;^0IVXn<-42Tt#F!&m@=e7ho9Hi?JxHD
zo=5LNX*N2>N7~1uG!)$of4ly41KX#dywac2^G*IQ%GWV;|BU-VP{*Oq$Kt!gE42fB
zaJE~9;T_}mxU-QwnL);66fqvN04*Z}V-EjBClNZ?e#H2wa?33g5?{SWUsZnxmA1Lf
z_xG=v?`O~f&V(sV3nn_y%Wu9PE&AUd{5=R0_{NmYZ}ihweWN$mv-LtPpM?$=tZpnX
zLz8g2Q<8CfEAuO}D{Yy-k%NWq8adTkRLOyA$VDhZDNL0d%*y$_;N<?!AMt#`p26kn
zSQ^jSFp{5D-K0*P8Ozo;di<ptppggS6!R(q$1w{v7WLlw`F^?WzMDLS+Aq~~Da@fC
z2Ly%TnfpGrl}6%DzFI2gGH7mj+dPw8k4)7m9dvSE2Ytypk7eBcOn^;iYat{Vf=}g<
z{5E+ZZ$YhwdN<#aaVoe~hw2@X`xW4M2KznueU1GZoEjL2hN9`CWMrepMZ_MEvv4&S
z&fj&r0E6Mtm-N~^;rq+e=rvkK8{5#Y!OzG6uB=-OiWiCvs%U(Rpb-2szO~%}J())J
zrWxiQ!>R6sxetH4LCjqMi~y9>A3PX+_+9eVVBxXwfoe1LMY*8e&b4<NSuk7<#ciRG
zX?TE!%$KAhZg^G#F%$;lo=6KIpGPhXTr$r9&oa9C_FIUXpm36yZ}V$wt+fR?Uq-(E
zgI6*(M1j_ba+T6u@Gqfc_Z+K&%eBJOg{QPtoVe8J)ry;hhNG2mb9JMwveeNyB4tcL
z&fV~%P1d5AqMfb2jH248QLP823Xl(HdH4T1Y;l7xjQuOI>!qZZl97Th$Q*WGr0aaZ
zDLRK5Rt-e)1@H>#39b9ZdnK_2jsb{jm9+d{^*zR>M%23y&xS2Nq<NVGJ-l`ZWwQ^K
zI{Li^F(a#n*}dQW=SH`wzzYI0VMo=$deM9IdhNYuC>y&lAg_J|9viol)~Kfc&(Qw4
zF1xf+s-Zr$juoWI(+OOT_wGOUWPcX;8Zd@@4T4T&zscdi&rseM<;59lG?N^BK~;<o
zpdeIX_=KC)g?Os-r6h;(rDU`e_wD+@{x08@Vq>Q^|1a8Eps-muqi?MuAHTH<jIDvh
z>BjmZPYe&LTH-_5LE=QiVZmU!Twsa&o~O=U^n6VR=noDC+OK?6A6bmAFi{<VN8>Uc
z)i0F;*I{-7Fdg4f=|@v8mpT3ni)<Qg)L>!OM&JB>PhOz0aV8s8%W#ScbsZz5YxDWH
zo*wF)HZEg_dc*lg_T}_jQkE-JcCN7{9_z;Us;PP|1Oadzc$lbKcH1=uJJ@-i!emL2
z4mNHqveSvef#tl7ea>6!H0l5p;7P1kRm`l@?G;~;4WPoxw@S+ooJ=j;>v%=-T&<X`
z7i%b`gc##>WLBxbHL)4xx%*jn?F35NAp5+aBjYOa81fT7A6y1*R=(g_CH?&aAK%5e
zvo&;Gh;--n3vxA;YH}Jb6ZudVByaOjk`dPm<@H)CGmQ>`<ecW=yWgWQn5-?H;>E{6
zdiHcV7ycq=G^tCh*tn7;V-huoV1Et?PE?SltcS>H`S~iJH`jwS_)5tD*Rg)xg3R?o
zAm26j*t^%+kyzUZ{Up;!(<0r_5aG_fQNHLIq5zih@1uI&<G;`wBXwj?o8e{E(c*mg
zdkqrj+By0`J*Tm+=)uXFSdzZl$?!uUM~9+`P^!iZ3do`szhd&k-{Qzw7#%G6Kl{~d
z6MwAA9Bdhwv3MdG3w@0~KFsG>4YWZ}nC&HL_~72xd-ROBk6Jkj!;;4bNz{sz39N&Z
z->3I{>-R?C?fvJd`FxDHi}(J=D%MUNla>V57FmRXZsLdFA(Obs*7AG^mv4dQixdwR
zdqU3VV=ErtM7u(q>#&s8@DKSVU&#E(rF-ye>RaUD{J`N7{2EtJ!r!g$IOE67oGzpy
z<gO!{pt-TG_=Uls$G&U?+W>Ug$21sKoDQVRQExWr5Sk9BW*;_DVb$8S`7nq|RWMl{
zpni->%1Iq-z4=VXTF3CJc*@3-_fas9bG-=*iBdfQvwP~~snZgq%4iocDen-7AE<-L
zLvJr!{cmUqyMZ8_-Se9FUHxh;D^Prab@OP%WCFE);wLbIB5pxMmBCu*oEp(B1V^~~
zX=4vh>tX|f_ovpbZAcc`V7vHUeUGt^GsX{b4A)ixx2#BY=EmI2HQe6DC$ztkIIbF)
zWavw^lePIbZ6Jl3Y5A)inTDQ#s?W=k9OWVnCE>3|ew^#}50ulnG!i)#d`&%?CaaPk
z)HW|VAA9r@o_<^nauJgIaw!#FLcNk2Cb_D*!8w)hE^8J1e+s`&w&|o+c{{SK(%Sx#
z_G4q9_vm#Qe+kz`v~~0qLZ>#|!+du2d*w6H8Res;RYbA5&r}WjykEoK;9xKQ85sjU
z3OCl)utU1xp{?Pz^CnNWW>Lc}ohs+yvY@iqYu|IiTr4h|%U<a*?fI6vwleZ5YLvV%
zG?4sE7Y)G1mYN8P3hu*t2rWGQL*Ck-mDWbNR9<;%IT8vlWVL@-+u6Za#9&-sbjLaF
zEIQs7_o;Lf{37F7NypAHH(@h42Y;o{!S;hnmq<R>wR4_jkmVq4e}uAb2A|vSitURE
zQ6Wt0GX4x<6Hk%&=7h)Wf08zh-}j#KQF32;>y!5Zm?V-$Lc1E5hv;H&c<Ok!pEF9O
zOT|i2!GctOJf5oF2R3dd`D;A;2%D+SuY`;9vk$Y1V&WmQ|6}s`)R8%BLN*!!j1O8<
zVdk^~jr>Y(khah{9Ze&LEBw<y$y<S^tiL_@vKT%S#%lbi(eCK`5B2<lM>z(}FV^0`
z)}hxQy33*G0|Xl~=Q`^mTL+n7TJ?(A^mrvMcCd=efS&KLYsQE5JP&p`PqhA&>f0E9
zUt2q7+<l0(zxHX2+TrijPv4hgEq#>aJjxkMsQNt$-BmpR8m?}k1Ux$2dgom{kERF8
z?VLp-f&EZkp~Oe@xc1h$zRkJoB$f3RI^^DzxNI(Vw~lO9Cq_r@v(m97qAXafjoIVz
zPjU>Rm>gq~!e_z2&`q3wK(FP_AE<dOwl<d0wdUcawo0QDgl=9l(t#(?Ebs{A7bnZ5
zhqi{TEWf$>8^j<@;~8D7%yi>D<c<)2&Rd9#5b|Bz^lVir4O*#GYt^!<zeuD&p(X+d
zI=H}7{@Bl3sd7vg;CB@0GAUo;*QxX|_RV0ti$Ck>Z@@Ccu#(OqtX#h06gYm5k3A(H
zAWGTT*iW9KZrWLaZU|O+14SI!d<g9y#VF(vY%kwx%-m9+nh(vonmUiF6Oe@8iI|WK
zQ#KY1PQM;$Ggu#kt!;j0G;Hncv9YvRInV_qjzCsJVQYpq_Crtq&!GKUwNkI>I_(|>
z5RP~5z3Z}5qyiVj;_3SiWa7u%VV$?WrfKrghDRF+38?4mXmXuZ+C4*uNFfT4lBYSp
z1Cc5RT#<D62o8wKhN4xBKOJCyKcLU}_;>J(4~m~1RgO~g^P%5SZ_rN$K?>s#s{*BG
z^!T^`wTjtyaR{@h?JPaEnzIihRS$8cXaY;6lrad#2E3c~UYrd$O_!$AXSUW@FV&nU
z%lP}Bp9wbRG`8H<yQ$A<`RMhM#oC)Oj6bbyVH>`!VyQ3bx$W(c#~}_cdqEHdG_>vV
zt+3UJR3(FdMqN>XS`>&S-P`<x%GyayXXpC&qhDBBLj&*y=1R}aBS%f_PLcOld;5pL
zzdVPi4d5kGN<?@Odx!|1lk0cCJVqZZ+GXqxttdKu(D1pvns*k`wR%uPCGHS8tK^gp
z)Q!V)-8ta-<0+v#onPZ`JV+AIXM9@wcC9Pu9F>)Voq<N0QR~es11F2CKaf2+4Pq6-
zGJBf%Bhhu>)9TDFEj89#H#VTR0<8X|UYD)^o#)N^B}S|L6r-uc>$3e-LVXyAzEl6h
zD9|GgmNEp44Yb#70~Ipqa^4h8B?}|>Q?QVFA2^-zFXSw1f1qTT_tfeJS=s&C{3&xb
zs?BRlv$c(txWiHGcN8qvv)5H0sfZrj<w`wDDPM0dvnSQu2G&CgRI!Z4p8a^2J&T5$
zNOP{JR8^v9qBOih(@gXsV;g2#xz<{0c{yBOg7s6Mc_T_EcC3%{u`luD7V@yl*>bv~
zV}9L9pqx@0P!%C^2~To8miNyw=jg_IYl-o-a+VMNA!$}(y|lH`RS$k-iZZ&0&jbvI
zeyN`GxEcp)^e@r(EOxMr^ND}s^MxXsmS-#Jv@T@ewuZsCYLc$ptP{@sjaSbF&X2VJ
zuf2OCjJS>r;3!p5@|R476zjgsedPyU#wa-wnG8vtzfk~FZZF|^AJKC>__WfmsZP(r
zN!pleiAj6NBph{xpRLmm#`hjQm#sUG>l#6wi=!atNR+w`Mh><Av-WiYS!ki;`2s=>
z1wfcX(qL;fFa`q>PILiuC>W@&V)^-jsS77%a&@_@Eaak*^P3iDh6d5P;ToobR`1a?
zdoba}Rq9|9Bj=(Icr=$o&__8{PDPbtuLE!F_JjYfbdJWPr*uI4qPCTQc1cM?Fl)CP
zhv{Vd$Z#q7E#MQr{{~GH(T|cxL&>T(Z(a~8@8Qv>*m*>FbbMnrt=rfV<2pw|bP_CY
z;wt_#KH_3Wqxh}0oa*clNv*3@lz6ea?m@jL)}b}vu*FbgUs2l)D;%G?t5exUN5M1_
zSNwd~FoTfcR4HA~N)eZQ>N-S$B)>xay(O=<ju0|r;T~y1+4-p1mtRr%s1ziSgc4hX
z>M-Xq7JQ7l&<7&v&wEC{S3lh&6iRDc7QM@yqvZ3vbCiZ8O`}XjH5EM*bzWsJf)9Dm
zgO8|`Dx~ZAqH==u>J1k~&Qjb^SWu0iDB%kwgu@tUw)uu*AkPzCLcMy7I?_^SWoG8u
zTC=?f=_tHNuKC*!yD=qCm5PN@Au48rQWL6&+54TJ`EtRL6@){X(>I3cHl$8}n|;)q
z_1k)d$I_Iu^(Mz!l%vhLH*UaqS!89F7%4hB{XILhoGIvDjbfis-}*W7P1fp5tK`U7
zQ$%vCUZ(ec3pMZ157*SvQQhG{6YtaaY`=|b1Y2^H8Wp22S*&!3O*26>AXo^Fu%+MA
zUJd=^L^fM3rE(C)Q)dFF3n#vTafvE#J|o?zAefiMdPk9!<vA<2_kN6Z(9jI}L6xno
zbE3>S3O*uouz^kijaqAcX#wpStR1rR7(YX!6jb5XRapd3K*(mh0go(7)Z2P%`=8S`
zJZ=M{ap^ir5j5sDR#tAQ3LwnQGRiH!XKe6;pYzUYI)z>dVX0U|Krf^vG7jgV=dU!^
zvo|qyJEzSx>gGE9dXaHZ_}Jz-jK7xkw~*+t#7qZc+itzZ#3y8LLKL9x5uVT-oRcWZ
z06;U@9<Gc01QW9HJ;{?fv|=yU@)9x-mTmrJTGQj*eqEw^fRaJkN==8Nk_l2J_TnvT
z!XxW}JjU?!gWq<~Lyk-yQJbk+DVtMh>G5Fz3+CLtgERx>a^eisLBzdEdv{II-6b+b
z(`j6w=Hkj^iW;Rf(?j?(7t+jY@3;JUq1r!;m|8hiRne%&H?P;~y?D~!3)DrbrBSt5
zH!`8Lp=eUpQc<=c>*6(b{sqqh4wv`<yr5}av`ZpfWY21P4X^$Qc^ATwgww3GAfr|q
zXg4=6s1(k-Nf(m3b*5f~AaoZ}SD3%3u6oGQ^hc?GOC`h{I<-1E_%egviC!+Gj4_z`
zj{AN8s?y>L2yQ`%W*To4wrak#(Pmt1%T9Nlyf8{tvl-n3jIkY_rANyWu@=Uj+j~Wi
zemOTlzl_nS`s$a@g6qflSKeXvQQM|R_<mwF-=U`#D=eJ1$6x__uM@r}9*@?n(3-(V
zlW(I>+~uH|EM-s&p<k(ydF7!a-Qfy#b#mwnc!senz>dYRNX^Yb!k~bQ;omnOkTZ-<
zKdEK1)b;sHs}nWX7cb1~)`F_In~c}!?~#Y^C&MT}Rh~i-I6p#{9tK;UU!FP%iPM=n
zxq%;3Cp&AiQzzl}=9>Wbxlf<x{a^58M;&clQF}OrV2DZxs8T(ag2V8evHLw-2z@AW
z>0G&5)A3B?!wR61qkkv$fQ*fq{2Jm_qHAb|p^BgREaMfL&XRQx^HXVn8>=E?8w-oF
zc1B*0r@F4A47T#^dlb)c`3O#3I&5)@Fs8w4(h;nVwD;CK(UD>d#y%!eEZO(fkp#_f
z>#+I9T-&br!1H=7qlY+tsn??lXbc_ff)jvcx!720p%_OXV&Cx6{qBCp*-|B2&qF{6
ztx$G&crNqYQJcW*ZSdn-kJ4S^kW7jQ6QD1xhnIw3o9o72$o*UDL`$pa9^+TDk&px8
zo1zzw2S$%cH=*K;q{JB7y!v^iuc;b2$}>c2aPWtn`_1Qj=LRwM#cU0gtrRp&9mYc$
zp#f2D%A7FN#AA0m8J|2`t^-#N(Mc5Q0lG^en!Kd1i@I{<L-?WVC_SjMfGMkZKDpAA
zT0E(Q7!?c|;91sg_%HqD)>9G)`+Hr}%-FXnn(2e>8Ux@CiQ6f_a%N?Hwot9Y#EK`&
z*`S)P)(QnQ0xSSVnwkvj=g(h^ri=C3)MO?*oeih6nW<A#lg$NiTbc72eV?%n*`r3|
z=E_QNF4_IB_q{yVe$Tfxq9Btiq1~r6>_n$Asbw`axv~22YU>76BV-gf8r-XpRvV4;
zms0Dk^9a$bFDyXUQE|3Z2ybSJ7oya3Sje7lg!S5V_R4e+h?hiYP{#0*7kYRgYln$-
zvA%>*&-vLU$T?hNc=vwOt<yxM9@I<4Fqgf9EOF|3J(SgPI?UE;j}CKlfDRKw6@7J>
zBcXwzZ+0X!VC3YsvWXjWV#oEBL~gA&|DKbp6KUl0mMWDDV5HtcNO$UUG<5KoUz_e^
zE(6;p1YRR9dTUR;$DGsK??*l|^l~)1?rhTJ`^e+ZPlt`7EyM@<HGJ?c{O;*e-4WNt
zIV<1yKdNNKb=fOzV;k8YeVLN|s1>|2qx;A$=(DuA?e7_4HS*O=I;#_7$t)e)?Df<*
z+lP{il8j$b7X}!*#lm;~nbI+mUaF(#6^3<__I&OV;7YMgJ4WvFsNz$I>_?qK#KsAY
zicH)59xo?VmAPk)K~)qBb%ym?{Je?heqoGXUD(bupPq4ty8eI=95FsjsYSI0$_2)j
zi(e#ji;doPF_2rIR`hd1v|>a|Y@oJ=$QflDpExlMCFDV5faQXW6lu~hf@dUW#6~XD
zM((<rf9dwYKM9FwWGiYy*Nde>rd(1r5Q#l|_HQJ53;GcXjwtjP{as>Ap;x}|ve54z
z>(9sEMSbBo<8+Tn$G`$2AYu4O-Nxn1r%`Y8+WMmG$I`+QW8mb}3g3}ALq!ox6&wkr
z40Fp(Nyag9Irxtr-$ANjRH_53^r5LxR+cMGhki!h(gjRrb6(z(0mb<Mpz7db2@iXz
zUia;7;emkm+B0i{KN|h~$?lrhrAobC&*oJi0c|;Y7Zlb(9re7s=ho|m_m~v#MB-!m
zSz}+?>myhdG;+DI&Ta!S(E6w@ul~ULsCOEy45(TyMjyE9%iH@ig$%;_D(L`*J%HO;
z>=NpDVQFn$vE3i__82f7K(lhHg2;E-9P0km1Sl=2R`D(Ob5JQpUQm~N@G!EhSmJ|b
zpMQ_%Yf$X4IWI9VOCN(1%iYbqN593Ob=G0Swm0|gi<C_<R4u~(d9R}n@)@6}a?}_e
zu={?GK0+|se6|WZLN(Q>$ObDLO@8B{CrjXg<j#|3$Q;NfNHbZvm>=+x6(LB`b%Zx3
zTf&=<&H?Evx^g7?<zlNJ(a+hPRJdBw$e~_bP2Ur$iIj+9q6*@W15*#Uf8vS38HA^b
zme>7t;l1V@w3kUkNBQ(dWfzAiWYin<I|r!#XWV$!kF@<cv87OInw6xaElO*(alNy8
zqm7<V>kAE24;ov`e}4<tUfYn02@6Ye9qYog_~G{VIC@KFN<krn)X8MZ!vcs#mb8^V
z4NU~<G=!Xq_ekLWpfCI#IY_OwTbGyC7q$QKa4#b0oa{q{ksG<OeQ&>5ag+j!4Gh<-
zAH&J|+L6x+7T$f%+kVbvm<{TgVg-i1aww4dlcl@E?imqsoR##wF26dHgTK*(z=JOF
zeovY6_v&Y19lHg>s2kDm7$_x7`?KG#=d=IIL)DuQijw~zUi*UuqYDMW+`w(R?Ft(#
z#s_*BW8yVRPd^=3+r~5ah#3MwX3!LV3h%mC&o|1-JsOSh=1sp8j+Az{7|@e`4T-av
zVmi#!kjD#61kJy6UVyQ26Q?{32%U>F^;#+{dyy?9Kc!3vk&z_nMkFCRF+-Z8tl{5C
zu)rb>U)cUZ@qacp;CNm{bwE3x<p1N@=HL#h0geDFN>>uu)J7aFct;+w>Y%I{G}po{
zR9(2(pmnqv#M0|dgRzJiKK3l?TmjMUy0^UGC$ydaRN<Wk8_Fi-&k@6hubN(shPUl~
zi9S>9`T2)!tv?t3=f|Q-4@BI8%A>K1_CHMA9d;3>hzMNMt3IvAlKgv=nL2p6Grx>*
ztcFCQ5X=xmRtmH0kHw~MEX}bg5Z3OJzQ^u^qT|QZ+c*BK{E@<330QX5aJI@g=+WAP
zxoQv<%K1X2s0ip7{Xd3|5<fyZ0+@*!1(=`w9X}G=?@(Cn+WKr`>CJDp7|~<vZhXnf
zC|$})&GP`En&^Uu@4Z{EPxRKI_()z7_3x0q4dfX@81K<zN_@`6mx^`NoCQGL=(GXk
z(xRlx`x$3vAuL}!2|P%2Q#l)B-%VONGGExJa%j!Hw1NO+1cnTu$2pzR=)%E|INf9d
z_Hc;4CHYV{UN}Y?yHC^7GX1YpQ;jfaOiWf$eK{=YsM)EL6uJ{aI*A#*9>G`YeS#6&
zS#K>f?M*^q5QK!Yj{i3<t9qpmqPST9Kn~`F!=1q|=p5+ldQ9UFdTRiCv5t(DR7O{4
zp#4t<Ob~$Fnnr=m%gV{H2||*AD;OBs!x>J8uaW#p1}>E&<hiofSASK-bFM*VNx@b{
zgggY&Ty$tJpzLbnGA4(z5`!XHWDn%I$-h##Y;Qe1WCb<bNPby_3q^EX!-FN(S?QPO
z*?e|z1QJ$QM<9J(KX2^!`{_mTb-s>E<?Mfak5g?j)szy}jvl*z1UtG>KB|D!&<>Vo
z%t#XL(3O+5cGB*<l+JZ-9dSH3m<ugaq`-!xJKXJ}cg70&AQxuR6(C;3WQGl$;t8VR
zO=FyKJsNU5B`0jw=|ormOyoM$GS!;MVngFVMXgLt!}v#YqFhu$B(U7zw!k5do~j(r
zKY0bgp-Y;-Z2GZDa8G6P`7$a@c!hUpPbhPP490s;#zKvc6PIix!@COzezbFeeG_Hi
z=}uuzG8K-h2g|I=2OJ+cJ6Ri5O(wbW#i^S7jmb}j7w-=2L33MWxJ?L;^{ZTcm*F*%
z&liFz2ErLty`hUpB=u@Ifkh?Gz1gjS6k;nNvK}FeaI{WJoPqeB#Wf73oWt&9>he~8
zmDp6{r`rBW(R-$sJ5UiXHJ3Le#^H?KyTz~TzJD1Cf4!O(P(Gj9n1jl%8gheQOZzHo
z3$}lmSS(Kl!?k1k@ENNp=7{%)1pBkK(Qh}{9z+nwi!~45FA9dWfYMd7mj3qtgIk-4
zbQKYbm2@eS(H+EwJ=6@DCl&Hg^J@-klY_LT_hR=~JsyJokcC_dHLNnq&C7Gb?-9*a
zHj<@xb+$+VI08M_I%|tZKt!~qjj{hs`(bS!m>1N47IpftUX$b-6rXo77`i-&G=bJ-
zGoN!i>q0uLFXD+Wb$UGfPRLBjplFC!W0kBxE#U=OQpA}W`|5R!=PY(`ZkFakWE4ke
zdyVyz&+#L1fd7miSt3CzOEYWDwOclhW-RB^P#ENLrF;qn2+6}L@-Xr+$IYhYZx6}~
zl`0Iy+9M!M#}7{-=qHEH9t!nu;4*73?|u#K96$?etFs7${ixZ`@8f>zW^G4g*o+E5
zLOAz7xTD^z-?3$a4LPJ>8kllo+4r3!!&+2JrwU;p%i(fqx4d%&R~Wi`g<+lkOsKK&
zuE=WRCwGD`JZF@~e4)&u1f+~2x$syk9hsl-D@%N?(L;A$O<q6Os$MA1-@4ISo9lEJ
z-MhfjHI_~nvAb5@A!MLf$s(vtkqX0mIT%H!1sU^s7atsbW7l`<QL#|R3(1Vakg{8S
zm+#T%&|n0+KSezU2+9RXCb+QPY6llDcc+(MDNy;g=o6qNq8=t@<lMcEHj`(gd_9{<
z7b4(B5<jGIBUu;Omzz(x{YXMXDU{1Nk;R~@n$V_OH&a~4_i4J_d@ja6=ESOX@e=#$
zY^nVDxut8i2{R6%&fqMHeQxOXE-$|_d8$$fOW8ub7OYB6)Jyfew|<o8xYHIXi)Xz@
z|NZJ8@Eq&d_uHs{GqQOQ4?7rZ`xSaz!B5jiuWCyGs9S9{RuJ*r>ZqO`HXgA3KNLRJ
zXp|dhFD($%#S7gnr=?RoLsfFPx2*Hy8AspAOggBPOHs8HRfhF37{7FT+}#JV0BUNk
zme%QU^h;B)s&hg!7y!8FN@7=T>HgRcT3k;@><Zf2I|IGf^1V&Jet<{hGOzRc-pS9?
zhvs6&{XPlt{SUFca1k%P8LAmVW4&4;LSypW?RdNwsBOab2p;>?AzIQ-bve3lqN##l
z@{B<YespzU0Q@bnwPwu|>ykU<>Ia=U-9Q6*LyzWYfsjxlNe<*mO)vYP8pKGbT&Y=A
zPZKdM>r2<sHbSRNafbNLr}TR5-L3SUq5Q*Q*B+N4kAZj<$wxk&10tBLRcmy*_HF0@
zF<4DsH`p^X6({$f(tFiD-xCiSn=@_5GG+#MVt)*OyMBs{AP!7zF}ySR6_mkCoz&V|
z^VXqIbF0Jcy|gz5rVZVFsUt-L`Uk+o47l$OJ}Zt)IpQ{N<aICibcZu&rJ6$7UI`T{
zR8Xf5Di^}9ak<sWuSS$J3#yQ&4Mj{CePQ=IhQs68%jZa?b?CLTT*>#@Sce|F`Z&Ac
z-1D5>kcB%&l6fSN$H=Mud%ENl!Z*tKvaZ=l5#{NE)JLy5ITfK68+c}hehw2C8kk?4
zUPssqJ7MI-=7EQs=9W7b99&>+;_+8{<3j3Vt(s4lqpDIgok`3g(op3%sW$UdTA);z
z`IcHKKjn4&6rMj9Z!uo!Ip?utep~0fn^lc|izCmr*~{(jT$Ow-S1(mV6^=tQ!m~fs
zduM+JtR>xmZtfM6#`=g}Br<;Ye^oLIHu|g>d_t`jYHxH}8|afH`OMuC(;3MIYuo&w
zJA)I*!wQP^VkT471#H~L#_g%w#G|nevnJ>65&1l|(r5#eir^YpnU@TTt{$dI<jDbT
zM?}d(*%an#WP9SOH`cRgyjiN`P!3NlA`W!wG!43BfbR%@#gD}4Z*<>Do(4WyD`#uj
z;Cc)0PWjyM;k}<0-4tWGa0``OSEk{7N_CjaiQjOYS+A$-?tT+t9?`L-N;SeA<<X>X
zcS^ZF++z-peip7Huj63P+QIW2m=o=ucko*8d4*I^s#d}j+D`L%H0T`4Lp_$a;LYe$
z=Ud`J$_>@CkIFhc>1>Y|*!<QDsQB*IXa9h)L-15djmO3UKuqhhl6AbU*ZVHiqOrCt
z;uphgF&(8ebjF8seK;b%a8(@J;2f+AD$NZ=FJ1lw#OcSPkzbho+tqc>x?`IbbYxT8
z?%&wYdgDujf0a?Jsa`7eGP0g^>S0<()4SoVd)E~vL!XqF5Gg^-Lf3MZ_pBf4f)oqv
zJ`9qFXX?;{XB$1}>eMLw@i~XqSv|;{tLRr8HZXx&SCvevP)e0m;ILyuj!*{67X^3<
zz3@67lxBdnmgmWu2Y*-jcywetLj)xZ0;L+!$s4r{uGv7s;9{XzyD*)qh1o_!RWqD`
z-K8qJ_k5JOfGCk9lNVXK$ohM?euK8JuHJyts~B@kBqK9U5YjS)+Z*01QK;_GbNVXw
zUPcZW086%~0g)M;W*l>V0qi0b&o{T!X|vnJlEA;HueiR3&ws$s<9}o9$kYj)qa>{#
z7S>uT=tn6!>WLHS2b0OyBbOQ0dgF33Srm&MQ<_5uF)^}WK3-dH&A^u}3C~>@8F3`n
ztTb1Fsj?*njo2$7intq#%4q8q?)?_&-qccWNv8=d{`y9P8xj8;Jp~MuxKFQr+x4<E
zexi1qqsZt1<NvS0@EXS2RXc!knDaNS`0rhB2`Qp3{$c&x{ST^j9ij%)sG#mM=DzjH
zE+rn)^SJsD<4oq}QEzpz?=c%Da0wbno=aq9M`F^G9Y~%{S8^p_m@4^k2p;7`yhDzA
z*cjuB%$a@kuRNYOS+7>I`AR*c<R>gFsI%ZDay|;LabruS(Q6OE9;pgy^<LCzqmy83
z^KBNHlj{x7NPb3emd0{N!qBuy^}~8C_XhO09vl@pDv4M+^-ZYQ40P2D`U){0BRjT#
z$IYGox>6yZE2nCzL5ka$JC*6L)oZ=kjk%X|VXgv9k{d&%OX*wpi};~>11#}_dQFqR
z-s3+N#(Ai~qTyIEHmIl5`-^qxkd1zeBkdZahezM!)*Co}wgLqzmxDtpDK6>x<>jR|
z`XPu@GO*_|@gmBUBhIDuwGRr}XQ-2$%=hax-TB3#?0$T2_;}voWkoFQTJv8XD#ZE$
zJ=U!Y%5K9_#nmn~yLJqZXDIN1$_pbjJpsS?m>z%P7d;$m9sMslEL^FQ13=2%#`VaM
zrqK_4(k{a>%l0h@Vq9N?-hd}wgFu@@C~NCsl)#esUTDoq?s;QsH<#eBj)}HDk%U14
zat9F^9`f|BdAt_-XAzMs$e{CrnjL~cw;;g_7gs|r<4iGr+GC1Q|1>-#=&lJ=O4Y+k
zLAxfM1?l<i@NMIp7M~yL&&;pPwr{}|&|Ya>m#{V)zqF}rHD)F&OHCEJFo#O6HRE{t
z`5vwVA9=N0tw#lA4RI12j2Z|1rGVtjcelIeP%Kmn`4pU4!uNXTz+@uuL9^bwAM@86
zISi$At&pjz^-jqhXqq|`+6hXoGTp9Zw#r!K?(m`fm>d|7v)Ewbxma&b`x31T|AsEU
znn$zlYPDVnU=yNVCW>h?;75#MmVmIa2+>y@s^2gxdn`7n{M?1XV`3G$tpisJsL)l%
zI28cgOGT*G%*`YrbFt|f<Kl9y`8NV7PZ?g^>aj~>>opiQH<EnokJyfWyCY?tq0{lU
zPp2v9Ri#o@SAC~GK|-W`$rneL<On=MypEL2-?(!8fR}Uv*`qh>z1s5hxCy{<^;B5P
z!UxZN;FtIWbs&Wh<f!mIm*qF=h3)|cNYMaF43HuZzehj&t{3*wk%}#m@jbpNwAsj^
zX3~VbH@s*(WE_#LFHd*~pTAGj!{)aSC7W|cVDh)I!*Pt?ie;kmAJt=Qe@6L2X}J!n
zdu>KBymTHI9W(mvjwD-a?<c!#heDJ?Xhue{W**<`fr~%euR6Xnf$+_AwVuzJvW8B?
zk%D>RW64;^&ji)*Dv}`&1^I`fb0a&VZ|IUcwR$0yG42HNa`Jmc=IU{Q#Q^p{ar+p+
zbClx{1CX^5Y%2OCjZICRH{QDT22z-2fx^rSEG3;SR7mm_#Q!rdC~dwAP7fateD+>m
z5tLAKqwcgbVpth|3?0?%O|pA$(DNm%We|fZJM4fpwKwX$)APr#m^fDnQ!S#dIoy=%
zgCpxjy*n9PK5edsPqPg80{K-cp~2v!39Jt0w${ASP=ykdyYvFi?MBB%(y~UE`OeiN
z`+@=QYhyu?Joa9*hPM@WbS%1Vtj&v<EAp!u!>?4{^$=JhQRk7cM1wsf{MyauinTQA
zIH2pv1uXU296&&jsil{@?x9bojSjPH_|oIdLEgmqd0Ar7VS<1zorIy+od)AP=1{11
zPRg;X)JPZK0Zj0s-xW$4>83B91OV$|c(-3Geqm|N;QV7-!}!PCp->NW?lC*JNAK$5
zQ>9ux1Td}iW5w3U_h{>9<<~H<aV62eq+A)bx60^Z0aB)q_kQ$y4HhwyjMIg^Tv_*I
z2U5Sw*+MR#DJmx?^%A~N7LboSJ)R$se^6!T2b3{RHzImMKabHjcApX+(CExBO1T=z
zZJS$O1}&P;Z<;!+DzHo#kGNVa4zc@H!{88^Arc#fYbt!Oq|fEf1H>MuP9UXg6&y<P
zJ_l9LK`7A)ET~*%tLEH`d&ziD_~-9bC7n;D^YDh0Hn1A@?0in1r*k+{?RG@LAbwR9
zR4}c(5QCpq=hqiob49dPlN>YLU;JkBoQ$9Acsi`ttB9pd2c4zW#Xvs4PtPs+tKz?C
z6gyc1BdTsM)2;M;Mhcd+Zq1|Jx{Fu&P`}(L<laM;K$!GJy+%^6x&epdrgvtJ3)U`c
zao6uSTOgT1z0_KijS3}j5v1XwBoDY;3x!gVnxTkqYI42Rnwng0A%|izaK4zEUAkEr
zSvu%Sq`*oQiim5C{M!0@uO64~YY9J<6snNKBqzKuz6Z=+{e{&ZELv!6|9BOG>WB5=
zj&J&Bx*AkdnQ|V*X{Z1g6|bW8y-<GAPfJ*Y=b10$j!KK8<Cce<=UZ7N%9z1aEheye
z-g|B_4D$6{HmpVp@g}$6JzYy{ausER$|$JV(mZksD*wi>@do52W}OnhsNzviOr5`?
zMbF@6Qn0hFJr(_RKN^qE|La5cqk`rAx&5ej8pP{$`k(MsY*7NC^cF+NK{*STTOEmu
z5IU956Mk%WIvs>4XOyWRU#SunGt;dKNwy|+w;k_!(z|DMV|jfkeQSMwx^)?vK#1HZ
zi*F>qL(AavCk4_|n%=oY;^#HJw~Go>J)yjUx<{UudfEvHkH;mSIu*c&9OM6r%KaLN
zRPi?50B(>8k_ZP82??cTP~mmq-?C(nt~z>8rYn%0#i){l2BF$%O-(KW-<+Bhr5~@&
zrR9yadBnI#ikCez+yB_zV*);@S`qz%asUqGKseFMW55$g1czsar-G3Typ9LQ9bcYQ
zUc#KekLtCKzSF~hX)8;R`mu5IXGx7wa{HxvPRR-Sz?ROOMt?l4t<iy_G3vEbjq^zp
zgW=m60Z7pL(c0h6IFIGlHPq3OY<o!Ax9j`wuvg)LItnJ~9sLVi4b?|s*v$8y3Py)+
zAj+D-vfBU3$*&3IRaW!m5Dh03D!`p5yXK}lJD-q}GWJMCWb@>~ypRSy^)wRD28h%6
z5BGnVcDm`a+(58%LyItl)i+U+0)J~QH1xhJPd=!r4;>tfjio>!kbuZ_vA6fXOUcWm
z&2l-aUN?-8)Fqf@D)wA-Ho4E<XOuiidU*oi3fKWB&!eY}eJrYJc6An|{t#o|Wir9S
zAb}bkAovN6uMr|v1C@|wP{?Fsbyi%tFoVF9z;do6buE%tU@Y=Hgkf2JZS=r-6Ksml
z<T{S|uZZ6*t#X&VUM#CEHq91nTCThLy=sjjyGGraLXs0A%rS{okr|t@Z+%#eorWEy
ztB$fk2lY7#>Bj^LNOlyf!r&i!zi!q@=~3}!zNpRepPINCXW}vHsVe>-)h1S3t0EP|
zLj;A%#z>&5G1K`H3wnOzpJE;c>rI&8oTF1Qthz9F3q2(O(DWu|$N;&QHT|6J_wzYY
ziDUyYFf)*N2!!c844T)*@6yT~wgClM;K^EA??7EfBoQ*krcrJ7<m8zpgdSmi@6q?$
z`TGigMJ?Lq?8@9SM2ht_j(xVr*W8Tb)1#g#iqdB)Z-KG#GiI$`O<QdW`kCdB)O=M{
zkfBtz*e_!J%sIIW^|Pg3H^^~0IJL0QRk0gu`93|CgY{#<u}9X>3?kxdC*3HvqlE*V
zhcyS)OtP>re3xSkkC2VaM9+mnx>gOL)q^5#vphhowjIbbjjpgaDz5$<1!v^|8*KF4
z^Sbb$VlJO9mXu}01))`=q-8~xb{Z=p_<*d-{)#7m(_v7`XEM25N<}c|<Z4P(3R6mA
zidq^ud@HD1PTwo>Dz~3W#35J8*>t@EU@B~`uC|cA-<*}af~iUH^$n<xt%a${`4wao
z;@39rW9IYp3%cf0FV$<As!lz3DuJ3%RfY(B%jgpa|Ja)keCBAtglg9%1cKl?nqX83
z80<v<ue0H(UR;;!9QMPD`GIp9tYWA(hI0J3$U7CjBEIhq5f+G@Mj0;xh4XjIOC@m5
zu+a>es0Cd7FHL}<8u_vJ`-(q{d7~N30?ZwjM%D}&%(wx|U&VDiWcI_?t<uoLt2rdX
zmQ<X!)2N*P)S1Jcg2fG|<}JYjW}Snaw@1+N!%V(jjo<^8^>Zp4zsEZ`O5}=@p!k7P
z?>QuXmzQ*8osCYgd&7%a_G3U-n#>_Ic-Q#PP_`pSLDb^;9705k0GI^kMZ&X}NDS$P
z^}b|P2j~ceWPyVFKFwbfMGwnTeOG3|lOY|oKFrutm+QX&7TG7%9|o!{g)7Zk?IKsx
z^0_pcvlpv%lw{EX`kX6Y;;=|AAP?~H@!dQBQt2ClThB@Rw`+hT#csoTzERKZs-~$X
z#QM_uElZwV`h^XB^8ac>>>Ke42DB~}#%XJs?Y)9N-1aq`b&2UUa&E2*=R-x6T)9{)
z2hG_Qx8CX#+Zm-#EYCKuxCr-$+%P<6yWrL~naQD{bG1;)qu=L{4TB8sa$x$xC@p_o
z*uJVSuTNaJlM3o>iapKWtJibu5!(BpJ5OKLW@!H)fnyQ9{roemaQ9}-3!(?S^NNxW
zRrI}1g*u7L;AiBDJ<ipm-Su+fdAj++d(b?$^#Ad9xILN(Q$apkDVEYzg`qi~Ob*Kz
z$8~uw$dkz?cyn?HvMMrW9*za!6>@IzBXQ*(_q^n}N(FI%1tjiB6&cwPh@EqCxuvgw
zHEE_?A4Kq8IVW;W^n;!}L0!p8xt6IHwT{BW$uT+9FP4Y8S@9G*Mn_p<<X*BncBxuV
zOWh{5Oito@W-o;AH*5OaeVY7Hh0@<#xYp<ir(bQgZJtJZrY9bzgSF|4e2=66^|6r+
z1U~$|2El-)58G3E?t5R`i~kJFLmhoEhs=x7Z!ye#1p5)1J3!2f=>Ip{jW^4C!8^s?
z9s5O*Z8W)&4k;{(#Y0_R!LOxlB0R|0&eXIt2V2xF6`aZdg`qo-gl3_&KM#tOrB;w4
zg9AR5<!BZ+^ozEl>L{eC+{|>L)<t0DPw`!=#av9hL(g~Y6nWEfbBzfulFJ44W(m4t
zfEolY-+ty6;tb?dfHUiGWf?ofdS+qmcY9`uh6JZypT4-UO8XV}MFxW074jYl2el;N
zk|3>Oon(!pHyE30wF78V%YX)~cJcVmueLU>EdoCoUP_=`AQZuY*lSI%!(-TOqbDTM
zdM;n6q3=XG9n3B-p@rns<c#1HP^0l{5@=VLYa_gQva>NGY)u$-m<uomp(D<vPCt!q
zUa*{aneLCW_dGqvsidet{o--s0cT%H9WXCk1{vA6%4m!`E&g$KlY5QLfuY2ifIfLo
z1@F57W}qO*AJ*%3pnHEGsukG{uA@ntR4c!Y@>8*sf~kPQe?yd(wEEMJ-RsfIWLPX@
z(*?vsh=oDl-UkdFd_?*Dl?QeZuaDUl>#gfnfcmn;;cwB8C5moEu(4$JL&a}yApdP0
zqwk+v>`2JPPFzu7r`S?B8i}X<8gmg!*p+LgTutESe5$pwx`ejyKr}l`s=}P&z4E=?
zw`=|B{3$tXU{F$l@tozA$#V)9g4a>8rI;)_(Z}fsBEqHsqa&UAy0DGNc^OCaRX+Yd
z1H97Z&|rrE#GRwwCFg%{=zcnl%VHp_f%^t3HXp40a7P`~ft4r$UE9^@(7~5$-y?C<
z>rLe5T|-kh!>0Wc41g8P1M<PtA(HX7->vj~MhLB=T{UK>k~0#CH)vW&Bq@_Z$rLnI
z1n>l39G#LeORuR$r(rHZp@A%f7b4X32S!q<u5&IHqy6W+|50&FGV&w0PNzazJ7@=u
zzO-C#%3c~f{Z%=4jwfKJM`1Y!s#Hbch}eXpV^bHd%5QafsmV)LUZ&+GB`@dY<-q{=
z7W`kH@uVNKaWX8SPFpFR3!*A6TGQ7AXT9em&OTQ`@#}0_;RHSA099`4?9_W5ghE}o
z%aGtz3P?!GxX6?4(fjxz>fH1-%twIrVWV4He}VBbQo$~}dVOiFwJQ0T3U=>Y#+=gn
z9>H7GnbU;J{BJ3!J?GM7Rd-t^#<I_?WQd}V)<c$ue&08_xhE&fwOqOuBD@`SwVO0z
zKBAws^P(P|c{YxZj%v?=iyotK2**X-S;Ikd^<9J}e)lBpapjMYKDrXGBq|P^5gYKJ
z8~c14htkC8=jYdT0&jg|9d3d!a=9H_pVB@iSP{(TlZw%0)LR2PGKR9TarVE-vqMo=
zE)!;Rek3{V9A)At6AyH1XlDFth{r5-R%YNjY0k-9jLy9CPPs2IbJR^=Z#J#Y{JTFb
zV?z((u-QhK;JoOt^EcOte+thT|2C})&9*jH*QGkeu&SNIISd}ZHDvAeBjU<OC8F3(
z@5STatLb?ExrbA*wwlOi*^l5pU8k_tD$e29OVC9qEpfZuk-A!;tMRb=pFBGqwbiSY
zYCcLy0-$i7p1O(-JaFg(85^0Hv)~CWIG~hob^Sn*$1>jN3ySs+*I|Q*&<z$ucHz>*
z$Fm;orx7?;g1&~Xa~vbNy8}*n4qPAvM@LwMAPaxv*dGoOiBIUU?7XPg4nC?UnXzMs
zSK7d_j<E5EzgIs6P%$hO|Mhk~xAA@Iu)5Bm8UohsNbVVfI5;iQ*GLAOBC(2%{;~IQ
zh4-VzjpDUFG#XzU??{KN0EtExkH5jAW8iefG+GlPahf#JBa4p|!-Snkza(tFkg%?S
zYMj62QE*OUccKnqrBqE-Yr5JFzw;&@BE}QrETvMF!1`(q{CeAH?}gft(r<~wWo2#8
zlfYj=um%?ozRH_xI*sa^X*72{{yIM*&&cclqny=7gVijcpW9xn>_5_>&Lr0z*#3@y
zSyTXJ0q8lTrqdIH|3W%|t$--9bqO{amK<VAB^Jm6onQB@w}T~*ewJfNz8{*bj$^{;
zLt}rxM;}_n5*)%1M-^rLxyz_`8q8Z1&Lwmx`@Of!y;Rnv+Qt~`ZG^mqv{*JU58PMy
zKy$_u(Ejatt3VFai}esCuHw%4aQZf{;>q@od?55{o;hCg&UiYT3d%*4vq@Ey@aYjM
zyc7RM=AqOvli1gDt&^oh=%t{y!Jl@2QexOvX5g}c-$wbIWxcmPrex-csU+Kpc*R7h
zF2Y316fRDkP%3|AX<_~Xdj%m=L$x1){%&-xo#*0NQ6X41H*D+8JkR2@ZLC81RP|^E
zoR^`6)-d+N&^POUWTa)(<<pFh!$q0PrzJ+p)#}^p>Tx1wgm_#L40c`F60+y*?^m|k
zL_>w$UTg#Zn0NMp!8acNOHU?D)-stwv8sXrN#n~PFH6%;{FHYs@;qu80Hy_<A5R*l
zjY<ktG|baMk*3~LpgIaxe{?#bQpe<x)}Dyk#8fZ&(e+}J8X1%LtnkI&eufLWongZ9
z&r3c0Gu8()D%X2<`KRF4vbV`UA!Y&`S-hWXt!t>Dr+PLM;4z}n2bMB|(Oj{S4<IJ|
z`(tyzG|vlSDg<d`K(COLc(HBXQp<X0`}cGiT_R%rK;>Tj+tF{){}grgbul*W)?4Yf
z(*Xr2x$V)?)|14;Kx(??e*sO-3|NBe1mltQKX{p}zt(F|D-*W*CEZ%X)*}gSi%)9$
z8=i&4;Sc>Zii?f#{B$EzznHFM89->{Mv}R6jT`XvOInbPeg62}PHrYEC_7j#)Zxd5
z8Y9q;;I={HA-yJv7n9#8|5t1oFx{WZDnSz0(OdpYVU(ca#$`zGOZwjXs-DwP7~wDl
zomeZ)@V-~QP0Q%>6G&`LBC$Uev>CT+(+h0w)7bYbUACj)o0X<Sk^;)nxM_1;icLA}
zB<jIV8dzDQhi~5H@zFF2B-YVjq*gjq=#Gq$Jdu_#Emks9zCAiV<pX;Cb|;1Ar-Uz1
zLs~!rzl21sc2Hp#E;rPxw`~CVSraOR2o!i+=z$D+K3~C9msU|sy90J%E)mer>nC{o
zH%eYUorFK>A<~x6<5u3+rBHLLRLMq_Y>xU{&#G{_D7q+SxP+8K6ivLCGVQ~9ZN~5E
zkqdycgmE5|w$RPpMn2vH5k@*%L=MUty=~k(t0(J)LaCaSGA!qG?1ix-uD+eTezDnU
zpuVycc0Xi9jLw7mi^0+F)t{e>XNH>I=k?x=ojD%4_1u*DwtTy_{TH9_or7vn%cJ;h
zh&Wz>2$(cT?|@RO%JRp2U~7u(ev9{AgovUqIO-7B)t3!kN0#C^%<Y9D$%9$K&f>`J
zpAmbHb&PFT@>6;b+he^L8VcRa0*H*G%;)AtF+AqA`W)Wf9UGiO9#%G^i*C@kQ=lfX
zovbWXHn8iI_(72|=Yh1>S}3wIJAdZ1)q|g){|1_d<Zq<r=8$9n3(v`v#Mk>WrJ6#(
zSvs4|=-^ZGJ-*zjOv&kawqNJ*8??HsWDC#^vW0<hfOGSmho!*`#%=KDu}^8+6wNH=
zgUpF!HXSHWhLop-KJcLY<;00lmAJ5R)O$#7F*d#A;X)i#bLn~}NH^!ECQ%m)y~1q(
z#{zr}_^ThsaT<d#G`KU{OM{{ae~}R&*7Td7uk_QgpEofzH<cKNUwA`&da8me9K~pb
zye@Im7o~QauARy#9cKZ2@zf;bL?$H0=;W!>l9fg8TY&xRmcB+7#c0<6+u}6o*gslN
z&ll7BNqCM~7utSC2Y$l$SD!-;7WhUj3eZ1*NoI0Xt$*@y-yS%ZFH|E)m<DV_1YnC&
zWq9C~?s^$08j>&M3d+6h&~YWFh;N@)ah39{%*(xVJy`-ApQ{&iKL}Jmo5W-6b6(}w
zE2|=WE1gHAsH#yzK1TrD!3`2m{|PO3_I{0e-$*rtZ$tbX=`V@#-t_U89IXo)>@oR&
zd$Is&z_lo!j<AkY6r6acs?2pFcGF{H7@dIE)3Z<!aphK1vbdf63I0#FZxd28uA0qM
zfek5#;PJ_yd-VPte1SGN5fBsS{(zCeH{4i~=@N>QR#93pRSLwOXEw|dz%Zmvs*LLS
zIh{}~_OQ(9?pM=azcRz>iE55w_wSTxM>QlW9sy4PS{obd3+FVK5ZqO=%f${-z1qPb
z0IfDI>yGkOTmXA(Jz(aj;y1Ifq)^0Cy4NqZz>}HRCufs5&wo%hr$~KRYT|^ml{bor
zhmx@x8+q(oUEL9t7NZ00T>KznfBHg0lA8f6Smn-0QpR~bhV8$taYXagUZmdUELgW&
zSAi;rIJ$W8Ct~bwn%x(?Do*EIACRkW8BspRaQOH`bqIetUJDHvhG0grPrvKuUYx3>
z(9Z=?KSATxM38t&$B71C857U-Y)P3Tyv#96+D~W>WK;+Sij}IWlK!)yjvVVmlTNNG
z>`ILC1$}mQe^dFcSqsP<N^w;QOHh|LF7tfG9!#vS#Ce+w3Eno!5<;xpmp1<bDLFQ7
z=;Eq^Hs>s-Km!vA_QJpS=y8qx)=>Ikqr||OZY65u0}`iKSrv*U%`7hV@gMQz7INGQ
zVHDO1=p-qE$B7V1t2jGG_3V?2oh+j(oq2Ek8nGX-VT8YKrir63ts=`z)Z^*a1-t^-
zS`KWQnitThgY3m+Mi`NLh}<Vo^`z8HiK_{X8MT_?ponN=#u}^6hAzHg^MEuWa%{cT
zkiM+Q*|Owtbg)B=cbkI~T};L{uI7jm3o%WgWGbj?VJC|ieQ})D%=$c{c)uU-2eY&*
z-VY*9h4^8bBJWhxpZNuc0slm<%2>7^S2;77E9&hzA5Ze*l;v;Qm|wfqXtq(z8Ri$R
z|3m$~_ScVy^ThV%GwOeg#?^<D9g+^C-=aU7<#{KJ-h8z?AE};=pf}f)21V+n#-{XU
z(lr#?m+3Wn+Qi*mT3TC24~~ngpdCc)nR`Fpt&>+P<zgBo+j+F8lM^#l_m1QU6`W2k
zduaP9>OP8yU?c>Npy5tyRXs=c_~1i4Q&SWA+)Fc?IYK|n(k=)&>8&-XkRWQ1ke?8o
z!4!7x@%6S^kjdtwN{w}F@~P`6At?sH99+|qiX*>4;o9I|&jm6@s~Z+s%VmYZB8{1*
z6e%(^o!C<2%UGf>!2h&7zlMlq2&SI6W*!g*HtVaV1sISq8|+~0PpO+YyE(SL!svtp
z+UsvSjDEX8bV&Tltk3p4X&1qdBRaBxAftr;>)?6p#VbIUvL`<_?(ONROeIq*ri)_F
zg}LR0z_TAp?z#zaiDc?g7ETcoD0x49$FxQqj@A<!p;)|7FE8QOyl>!fwub%QFZAk^
zH<sqs7xB2hc=+%t&`_H<{Oyk1Jk0A;nh)%}Vnkkff83OB!_tja6JmI6ydpkmiWUer
zyzJbUdssF~6&Es<LN2A;LA|`}A)$s;Kzjzulz8;Iqq8LF487FSKs|)c!rUTiC8+qa
z9<*>0tt^=CRonomh<Yu7+{@?@<G(?kva#A}F3dNK3sjkQHXq}Vr6;^a)%ZE1_b%~y
zg@vB>Y6n64LsTntzL*}vAJyMG`08F-J{m)hp}zQ?8A!_`YlBDF296&jGu|HO!vLJ4
zTFU8OlXU1gB!a#VZoKpU@h#cI;GTC2dJUt~+{5h6`PmJD28ydpdFc@er$r-Y;fFqX
zmSU}$R2Qu;Djmo?CwPm<rYT6rQzwZb42BRI7v+wPp`imSOSd*WI!7JFbQ--Z>Zr?6
zfNnN58P?CAzZgvy>$R!LOm;dOPG>Vxv{EpUb%`kx+7=p5qMokB*+bOy3oG?X3IX5U
z_33n6ro~iPr4F~TF%#RLRkYnz7fahQ?=pLEi?T<T2U}R0U!H3iu6(S*u)j?r>aW$A
zp6J$@(vV$IR(BL4eNnb3ohcMPQwglxd)rw@zsbp{P^gE<0YVgWm?`2G#BK1X#G}4X
zFO8n6nS8ZWtSY%jyM@@BdI)0lQYmsY^`3|vg&qwaNpAm`UdyqI{pwO8rti3TejihM
zROvB@`6HdTCMW1VO^>fSE%c}Z8IU%JO121UkQ1v~z%;~<gmpDMHTe&8enX12a4tw$
zK2VkvCs~yyxvW$|JDXc?>Gju{6LrC6;e_jJ%UTDt_Uhf2JbM+jZ$d!gwLBW*Qs&4D
z3B+k2WKY~GGA~zlL3vtp@)d3;KPLAQN%MZar-{eAbhBfqrFR>O<Pm4b_!ZhO@b<|i
zVY(P_AQHwd`~mtlr<Xe^iSG954Zm9NT~@b~>a%ACFWpZweoF<p^v0W`S}w@K#sfy5
zq@E;pcfUA@QH9&HCMmDzc-K{ZCiY(E(P6rR#zi&2i}g^&aXR264l^Nfk|d9gCo)*(
zxmPNCkikSS641h09X{{ejkDgRKBtKEMq=sp`DN*1!&Kh26$0?Oj{&}Cu=|~R9p9X&
z2bo+MWscN|;!r92c}5fqq}d9AWo*CT5yp!y%u4YlNF~{G^I7{N3QtG9%f|V6WT&m3
zw7mY&FY}&@oQzto9-<%!kFq<!>X|&J#lZ4`?R_UB;rqx25lUp$%ZQMb1ATn!e_ii)
z^j+Tb;O{C#Xxa?F9Uo`>Huy=IgaqkSih_jk;(T$sl43mEe{v(fs6VRZ4zPYkKJTsZ
z%rxh&HxZmbyh@_0;s29h+M^|OjLz8yd5MLH6>11JZRqgHx9UARf7%b*JCnws#a0kJ
zBB5(DF>cRsACTih6Xk{_6NL>+nVQ68%8t!F+WwfsZ`(6#4-3`{bqr3D|DU_J0h25%
z%LGGE1Vzn3#HLpvg+g0bdm^(ctE$l<Z^VuNe=DoHiqa)AGBdI=y0S8&^QXGHRZLr8
zSwu}3Wzlt*5)>I+B}X6KwimIURvAQP(jFeB*HNZKWm*QA)N#jN2iJYS_ndRjxsf*_
zZd6AX?bh>DW=6z~`*Y6s|MPyRN|;qO2_`Laq}Wy;*nhm(7vHG&@#8PG`<R@m)@r#@
zwjt3@478S8PwQvc|9jd_f)@#*hSmad2iYeq52fzYObLd=fN>g7obS@-ICz+QC!C0y
zUNv!>akim5H?}5^(hh^_Q5pO-K3(D)Lj31r)<h-MP`O<4JdJ$Cf9kcewPcT<_sg<A
z#VrkO+TF|nGz=DKL*h&u+X0V1`P}d|YUM_)uE%Io`jIcxHOM=Nfqhu7-_)kEO*dj_
zjM!c;G{$W(p{OnbUGYIjS0E*v&jNeCpnG8^=vNs#;7OOpXA6LvEUQekUxb7zk<Lxt
z`rzL<_g1fZIlov-)yWZ~fZf%m#c!DjXrdRUyK<(KDOYtr9d!$V^VI2$t}!v!J4knD
z^@IhBtow~RpSPE|owzTPqNFGm7SSs~2oNk{u95V83ji=82Zeu=Uryh<v(?z%JkwrP
zP`?r$POAV(z=IkmCjNZl2#qr^$`KjBihY7XK8!n`*zm+7cxKb*Uun0lwtXPqbfAY8
z5aWg?gO3CJ-h&I2J2t*NslJuS$Bo?CD1sRDxKND>`@rz@)S}gKGZ-I{&-;F+rrY59
z`fJHwG*VftJpk*1N6`YLxKfU|Cu?TxJnw$in<_s58V}VKiC@&Tw);!B>_go?0|(C{
zx?i3t;o>*cF(NZl%BM;Sqs|({{7VTb8h9N~zIstV^YvKsuuC!URbb7Ol%H&Tx9MM&
zoF0V2@)~o@59w<jzD~uV5%CzjZsU4bk!GREBH6gj;dDsPXDfc$_e(0IVpW_Y(;xCU
z_e5mT)L)T4h&OF)JB(MwOcx@00!thts?bfPZza0uh0s#?fq0E#p2#zZDHvd+U;l0T
zCI~p3?`)ho3($}HDsbLW#Tq2?eYi7A00j^1)84AGPqD`8GX1qVp_bSf+so{)vQK3#
zKE#~jcS>5e(cYwff!*&5a0d$tR`p&dPmQP%(wDYjfS6cJ8uQb{au)w9?cn)B5FeLD
z$${Z<=0;_WpLp2#3CG1u51M<7{+W6a^$#q&;?}tgV$GaU!t^9_=`YgHnfP{DZ$R6^
ztu*f?k2BZUk*N_M)_VWO^CwfsGp_Z0d(25m7aH;pW0c)e4bK<$AtUQ|0zL9}jen!2
zC^MGu7EKF#&)2@8cvKqbkpR({0npZtVi@a@UL)`pfO#W<0mZSd+o<Y&bYalI@3IW2
z%%p<EOoUH+ZzuiESA(2(RMm>)X2pav(-~}C<L+PZS;Vs$Rf7^#`?-}VssULdvC#;{
zre5Z5eZPw#pBzP$fT~9;;Px7-1JKW^oHjg{@Tc%^@=XE%E*%A6J00|<PyMg4>Y9pQ
z2s|JYqwKwmF-m|xq0!9FW)p0~9ts;6qcpbD-ouVRgs^h0n$D*Y8<2<&Eu_BmH>1X3
zPl(nO!#lL5_$^vY&>1>3rFwOYe|YWN9ed43AgoX?0X|q696TFCL{y{vVT0HVblF2_
zrzvYhuEpXk#-Vt@SL?mKE9{du(r`8WhALI&`JI{<c#MEyvvIdQaHPpi%?QS_U(I5W
znyMG$_xPx^6}eP>>%|YE!ts0(uI82p`ZKo9jZ>8M2pe@<f;WDjq31a*3xaNG_D-(?
z3*8ifHA@)pcQ&wJ0tD3(tOWT)Mn-8Z$%s^dsI~=DLktCpdC^yTkLW<@5z>vxx>X2=
zFy|q^?{MnBlWE_pq>358;1|3U8a6jWh0o}#@tEtAbMHQ?^sAOlv~6%Vmr=k2pAS{a
z3O7!7<FMc>jqxj)1wDT@*wg2Q?5|QG4~Uz*vcI_I&YosuPcM3b9n|}zzK4}=gMFCC
zk~2mji*s=S71bORgZni!`^c`#CshvwTdP+q{o!w3n)GS&Fx+WN78aj?WX(@WLmM8h
zXKeEKxzASzx_m92t)iAd9>v<^_sL7ejSKQ;R!$M*vAlUpyUB)EMLBR8s3e}>-OM7M
zu0vT~aLpUXoHea`*>t&>E9$XL%n&-bKYT{MCiw=wWaGDE$;WV?_&LlM8fL>!G=+p6
z4qu(LZ|t<aAErK5ew}6$7MpK(u883LnC6k*@ATDVO|F+|K#;{OLPWS=P=tGAC4@5%
z-gEXIy_=a_t(@~KDl1~*{R4V8ea8P07^{&S=j10PGexnLiqs60g-Rb7UQUMNV;FT(
zE*Et|re8i&VuDk0TDE`W2P|JEGf0b+{X(@^&kgMnMExh)>gQ*{EhW952VX2Xoq1z3
z5qGk`4)tV;piUZjl79nxQszsLgaTQy_tW;Ch>c%N)hjZ;Qx=BI%ax$4;5sQaAfGxM
z#-JcY1Xqy9T$N+^7s@gdkL!C+JfktI3A)w;=+TW|y<b05@@Heo5lMZ>|Jy1)ctI#k
zV;d*_gR+e=KPnr`XU{5n5nB}^C2_|;IP`KVmqQti->6t>p;-l%F}kP+42Zxc$>#yk
zRw*<}4V4Nc!zeBhVtG1sOONWkI4r0*%gDKx5uv>SqA5B;>JGk)K3B}imx*8|V&m3*
zDCSm=x=;wr06rO71Y|J4gHmIb=|Gu1JN)O)9-}Fz;MV}2fF3s4qzUesk*QPR_*Au6
zX{1Uzrbi(|qEe;<1<@7s2<iRa`{KTM@X&hW`1%O3gTcb&8BlMtMwYxo>^<N&xwtB!
z+Kpu$9JjR_Q&W9wu#BBLQnov8aB=7gjC-<?@o}LAvAJ*jQzf6WLw$FYuu2`M?$0oK
zF>ycFVKh#=!{`oBJKnW*?7gq+uOVea{@`_ukO9$x<Mu_RL|&ViLE()iX5e7^ID><Y
zPnWolJt-^~;rDe6Z|X~r=I-Ki6XGmp7J_tmjU0yX47RG<v|aS=hw^r@ZkBQD*J=7~
z{I#Orq_NKWW6+SqLC`2VTCN*G-~sbkrGJh7PX4Z)1Bzn3O9Ci;Rl2k=2qIL$=T<);
zMG?ejPta!<mz}gBJa_%i)q7j*_GJY0#l;OmSV99vPCq|f|5>V}YN>Qt^|AN+v2^i(
z1aH3E2>0@o3XN*HRE++vil}&jZ<xGO>Z|54QAkFX<^a>vSFM;Vr{q2j4KJP!;t~%?
zT*C0cZ%tcUBsrUDluM~9QIq`KiihtTzv{-XYZ;6#WF{IpRbC=etxfT(9ydJk939v0
z$-?P*1EOhfN89G@)J_u&Z;!7!hw7p6PbZqliE?ARh#PgMu_x^8SQ#II?g*!sq|>Ko
z5wrwR$jsUejN<Ep*whg8_4dZ4;k`2v+QLyvE-o}4Kb)F2j~xFL!<28KK(!at2T%RN
z(U^h;nrmYIokSK8{90{q3LX#E#_;ze;kYFL$x5|KPPviv8|h0b8_x8gTr@iWgN$(@
z2Fx}q7%$Q3yUfUxo$a^!7JcsIFHxU0eKmo6wX>{;CvHO0snI0?W`Orq%-bP@G4K{*
zh;D-K60h$^^gSGYPU}uQp{5XyLzlX1<W7fKn&W1Jf{3b1LOwDbLgYriH8N^VEcl%y
zZ8UHl_Eci4Lib*%N52F-k$MJOiWyj5AZz!&TE*{yWi8?RgsJtJ`r=sjLbQqGm<v)|
zc&~PB`mrH!7?h+e;D9jH*jB2#P&kVhuJws98g6OWlkv6o-fDHyjLfVp<VuBHTGg)F
z<N>`d{^-juTos>;yhSc!u!iAW>sD`j*vquWLb~w_abp$ZYO!$_d#GF=_hiFF922yn
zmLoBd2J6wW?_m)2NS=`%_?ULVxHmBI741Vw5?L?y;(k-|JErGkTSN`|>5;xeJ?>@;
zJ?m<4sj!N&CWZdAOqqIx6T7XWSFz9lMv+QQ+%L4uIIPp-!*s*4kZ=%F@?Pbf1Fcu(
zLIDG9F&uNk@d;x$_I^U*A^LeYFE!U&8<=y6S%I9{V)39ow_X!NWy-a5zLYAehdU=X
zcUFGn<cHFPr}-y?(BxOk$N;LuQ4Byk<>y?So-Br`0qGHEw%J^fctI#m08mpiyJ*Yq
zgUO{Pe#43JRAlB;wNh&MgE5gPSq7A#sXMe8Mm`4bbzSb&*a)Ywia{(8eX4aIDI1-h
z<muJp-Xl-WF#Q=Xc+MNw*~g%A9ZEp2uJ3HEvFS&lR-rWxh8W!!d(A@FXF+vuUV5%c
zDk_s@cZ0ig)(h&1cK=q@@n~~oK%8ANaLx0{WKp{J%%msxJ(>BG#OHu;RleMPnvbUR
ze9QK>LMJd)3Q*#GefPks7GJO|QY?C)B`zrQ#!RoJ87mgxAtZiTY^*%TQUeg7CwNJM
z8*Y528-F9uDs^jDdU!kWsNwa;V(E);mTFXvY+S(>Y1OFq2T0cNwXwukwX8|L+R?2T
zNDtUA%>C7~<*hPxO5MqcL2@XRBx3F}DqE^NUk__$bo&0H!&`aC0Y6nJ)bc71Kf(B^
z$*CN^xIb1kbpEVf{Rsad+8Tpe8E#+2KGP^IjWsknX7Tg1E5$I?h|)}OA}&E6!D-r1
z_&!o>Y2?h4;ohY*ni{I5iqjA8_#$~>fAIW8O*7Zu>+Bt7;pGdJYzd(P3JiXa1{j4K
z#g&r<WB!64TTv*vFC%mJPdf51hq}5fIt{8Q0+xH=xp_u@nUpq6=Gsd*(pFAHbI)Ry
zhvpd|sa~yA3aVs=caBs|aO^d=H{n#S;b#i@DvnhcBW)aMF_U`RvE)KF0y60q9N3|j
z75ippwY<9da*4lbEc#+FVW+R6JbO)^<zD@rLyb8kh^xl;bnCgI$0{8`8iMnw2G1Kh
zJixuU`YzollyiEn5f`62Us(dmT(@<%i@(KKgVJnL_<^Qgc#G^ei1b0CmPqPu;rhWz
z64b0gZWNW0S&Q98UAr@X2Hv(EAfrWabi^{K?+tx}anX<JHQswHP7T7iiecgwZ`3Mc
z=~NAWO+U+iUF8^)<AK4TdRMBO7}q6wuaR}rGbW~+(!jJ8!J{1(&ZXWK8ZPVzjWt)K
zi&S2l^*&thi&gD_b_V5yVhixwstSU7GSBHd+)%i2Vhs^A4iNxYUkn%oynD2Wv|uKE
z=)tjWGD4xpnfU$9DcXD^V^O?;G2&4VY1&EtF7pFWsOT8odT;}60^JP=p5~?X?h-pM
zWdwm56RwEy2v7>?5lP*&X6UV9m{P*rChoKUmriUiwb=#|UOUz6Y^7=oMWLM+>9}_C
zSG5e#?2O3JRn*A|%x6<TK9_r5215Kh)>~JWR$9$d%lE9bTc?&zEVoY0o}OEoU0zw5
zJ2BHbetM;Ka`x2RYdlXclq*z&3`1m*EavkHuZYx&l*mCGF8(QH!N#~{-BWISz`LfH
zgP3ogNutEwZLh_^WBj{Y@9*MYF_t+G|0QA;sf|w>-rxOU!~6N2*5*oW=gJbq{7}{p
zY9IGr$UKLV(lG5SUGz+~#j;NYcK`Jnef3qPNR0TlSaa7uK|2fZR+lzV*U0j*m8DC8
z&64;F#~y-DTgstesa95jU6%dO6k=T~f6%F-abhiIYcerNrQAGYYuD+336QZ_>qlN`
z?e^rUqMs|&^HL`+Br|i;V!U1dd6lQhFK8qR4(hafapO~JFOq3VX?ab7yREi1;JI&F
zur+t@{>I@CtmipYhh|h?v|3u}gTV2kEAcCF!NpwyR*7Ft7m5u%x0qHL*Fh<GI<zT1
zD;->4{-i(6gTzrbe#`Z`V>gK3l1)`hg^H@O3Dvi8v90B3V}5i>xXyf!8^E<!uDa{u
z*jk;#ZFjG;o}aB28W^1c!TOBUeJqCUqcUb~!A?=7)ubh7`DhQXc>(Po{+zQ{q+0q1
zvONJ-ulG{QawSHiymyrB&cl7=+#2U|Oi5F?lTCo~NtrTa=)-!?lMBuop&mS6%GT=j
ztSaW^O&(ogMd19Y0zR|yH>?MQft(1?{INon@0s74L;SM5+qC<1{qvSTX5gBX)1|Cm
z%qpv%TxVI2OGrZCdzMz{^;+WKr<PCYM0`fewCn$I5O$8ZVVHRXz6|DJ6^|t&;U;gv
zv>Wbq#<qfod7T%E3Qi~R9dGo}WEzFcH6Rtq7SLuV%Q-eX7}v<HeK%h+=VPEqssQZx
z^%bCdg1rOZ_TVcVx*Uv;Dwd)cIkeBsUQDg^*>$%m2RUFbZo!uuP*^EejZQ|sMAKd3
zz06Y~{kgp=L8+JN_j}i<)1*H~;b)@XNEqMbt?*~!1>ysCff5cIr+KBl-I5kNy#ID{
z?mwjsujl!0UGDS{Is^*KIx=)(fnki?GDeDk$guU%3D^h%9FW7+&ePGn5}_vTbNxH&
zVt;cRZI5ZR7+h8WKoVDyxcl_)X?<o)qW;<vh%(NWMT2i(a~YMdRC}+x-dTRo!#@z0
z_#-0z>~~0NfxUS1z0|LWb#J2MVYLZp_T|f4i1pKYT?yh{4bPEBz^3zyrCPpRQ8vN^
z<6S1c=CvFd49tdHt)4=E!^GojIlb=5VR(iz{!L=<N6d6tU=<HAblLbK+vg7R!tY+e
zytkDK0G7`Oaah4$z|7M275F*W^5FgC3E_oR0g6RnU-dG}=X?LcSqsFg3MrJeRCU9U
z4REvD$kt|44LFf2DlXa#(%A8SLvR0zvc_PaP7q&fVyqL;;Dz6I)&baK=&3KK%NTA;
z-6=n8b3N4|bsdS5RxI_OwV!y1HDzf!Nhpu8GU3H!iZV#zlL(rN1Fe!?rYQ(zM*$!8
z?xCHIme}>~18D7|sbTmM#~C`?{Q!N#rS_%HhNn&1!7#i>ajO5&$hHF~c7)-#n=tHk
z-N7VhxlJ&0Iz%U^(uF|BKJl$q)+A4tYsi%Y6c<A$DJs1H_jT%fDc@tvyd7VK4UU40
zf3CsCNqFdO^SqgQYh}XjzZANHM~)&^8E`B<CCDl95!WxlRP$60qbkv6B3z)d74ny|
zVO}eLq7}=?r~-)FU~xc3okhJ*PW0k7l0|Zi(EbgdG1eTS6se7sa~tcOjmu0};WKm0
z;q#cUQyAtO?FUTNjohE1)2Sn~&a?_1NTp_d<I9iHdlmm&gZD}TgsP6}7xfzT9u3D(
zByIvDSwbiXpFA7lAu7Oer@r64=g`(-U!%#Pn!H8h1CDIPOwdw3n=6#FDv3&hVxof5
zQ&AP=DwT|SZTkq76G{)5N{3>YPKwGe1U~Si&NU&=E0rA5({P4`UU?EqXP%g{o7zmN
zFgb+o4Hcf1;)6Uh4>W0>_29|yb?Y^x41u)E>rOb{VeFadJuB0Imsj+%`CQRY)l_vX
zpN>DcU{AxLGd0A$f6%!bw{Eo%X`~_!hv)+<B<&haUv}=d;iJzuUoPqPQtl_$ojYK+
zhTFjX;RlK?3_ukRv*wA~U)h#Go+qE9`+6+$k7&^7nauD((<y1woJ7DoZ2XU#JRK%8
zjPv<=&4b>bxIT&UxbP6+8yH^%MsBRio-6E{cj)U+y(3mmuMm;b8+%!l(H!Lw!4YIe
z&-!~ezDCz8ZY_5>oo}PVDur*seG82|ai8Vc<UN^6F`q-zlXt$oveDjJX+7xS81d0X
zcO|m=Tw=3xCa<`WM{6HX|DcY+0ZUQx2?`{IP>O*~e&cOCm#QM2wfW~e!ujVc?k1DX
zsPJ8XZ*oC|RoP2CrtdHL=ZXgCgmU!wN_W`o&j{@`FpD21q;Uf>!zfw#v9ces#{2J4
zaar8{wsIcnIl}JktOJG+j&={w?&{da<%z{JB9>x+KMtc{u<?2e3^v4kHTBj1%{*^*
z3^~>uJzM@+`Ov|H0vpr+h|8m=(wN2T=MX+UyQ4YO@bddMEHBT@)ic=wqC!ghri4`l
z3G{KjmIvqi>s|)+XpO(8w~<81JjMsS@!eVmv$hb`;Ytn2gct2$Mv8OEz_a?`Ub8lj
zj))aq&^D;?LkGo&E~uE0_!h$32R)Oo%D^?iwA5jJM>@7@?3{yt>g+8>ydz-(#L+@V
z1<xmE=NLce#@9J{6wHS%VFEC^5@^cN2%$})ED;(XJGQU%W^Yi;djwv51Ves71hQWH
zPwIU;eCxQ+^DO5X{d{-p=bKV}2ojIcsK%xz$Ekw_{XT@_@hj0l$5>FC13^?TqtvMi
zBoz@dCdWpSq(w_#hB+yEIo7c-hw?KOQ3H%CPh!$HEHRTwt%eW0vU}~am#tM&>1sg{
zCS57o$+Yx&VbUpYh8_t003LTjE_6zMSPPopl`vjV3o>;_znqLyANXt`WM!ioo^H7H
z<5fU?m&@g<hQ#Gs@$nT;t8ktd<nC@_QGz{3+_=&J7(qF&+^mR=3}>iA)u1YQ7vAAx
zzTRn<gm&ZwcH?!LPQ4cryTc-HgWy&$pG>D6R27IPW8(@a7dBS1WF!zPM&?@P@~Pnc
z1*t2RgIH&E#++YaTVne2fF`Oqu$CJ4Fwn`NnaBW6%I356lvnFswKI`xy1!(9Kb8*x
zr*ho>5+jcyij|&@nHT?bqYU7|bGJtun`7LCp$WIcE2xG3$GWb4ohH_oIt=#>V**|-
z<2Ri06Gw+rIKtaAw#xLEF`m8#MB%gOO+hlS-7r}1eI3M@E2`v-(I<_+WsFnR)&OV}
zr8VF|9pi^hW|~9AuY{;gOyj?ao7%F|1u5i1*~tp^j@VCAaeVv<deib$Mt0uu#UXnr
zQ>&$FY2bT`i0ZGmNXwgu3)i$<*?Vg!7liK&o`dJGqk&fl3ZIN0zL#RIQ>`xw*dA1q
z2c(mhH8y4+rhkijXyzwIX4ynsts43Fm^wbGYu8kSA*wZro~fG$?R2rdqlQr%nRvpf
z<xb9JYT0yAra(dL%0Q!>hpkSe^*!x>)~QuV^?D5^VI{i0Ch^vQTsXtvEG8-z1yC0F
zkvNCB-aG$a$9A5pru<S3CIh#QW#^Z1MH55VyFwqcwQ}DMMog~BJQ5r@C>HjG*YkcV
zQ_$udb78V}PazRubafIQLN$%f$ZS0u7c1-SdhHiKqxF#>Oqw!k(+eE8{WkUz1q$00
z&Zhk~z+gK3J<=!wPr^p*Y8^2a4{9E3BJo>Uo8GTkT1ciVm<^dJ)v_3T;?mZ6WM{gl
zj=WSwaRl420zB~E*HE@y-RfaJ`}Qi@hSn25sn=`jKgQDE&2mH#aC{9Nxn6-X(_z41
z?(L1gALPSC*C9oY^)fdZv8RsQa`z9RfN<n&{8J1w9ZVG1_7C;Cc7JE`0&bXVRI9~)
zz-~s#pAKf0(39w-!|zftDF`p%8C=2WFyc{1yREDnQM&Rz{eAE6SkGhzJw}_eZbw|O
z?NN3u;=f}4y2s;kFEh0N<(##&-tAuA!DMJe6lMJ6R)B9Z{ml}SUGH9+NhbbU-`@@Y
z3m9`#@f(F~pk_SD0A7F|ldQmimzr8KqeQ7EJstzda3~FdA2}8-s7+mSW6-EgEj8-7
z2H;w#G3Y4Ky;P3Uf++ij{7|ob`7>Ob`Wd~J2VXPhTK;1y2Gpx~r+(I{53p_nsaxjP
zDJO&c_HUb7t<27qo<gR_?25}$_wh0P{lhQq_q#{sx5qX7j)<mlPcV$AbmfJur|$g<
z^_H4et?N_7T<ISKZ*1c4{W|M!Cy$pa`D(6K6_n0=DvMD<K^?&Kqs}_99ung}%m70i
z{<NiUl*?3xdCU1Nn1F}^p5_%?^AhCI3Jg(^Eoy?BcMcba;qTm452#sz0CV-kv1AcR
zM>R5@wjW3#@sw+GBjk{(r~PV11+*jk-Lt}bK32!pVJ-e#ES)TgS|)2JoZX08y+B9v
zf-p`DUtB*rYXtcoF+r^#@`x*&P(q!r)(R#r+n*n!Xv%v*%>U+hI<&(4*hFLgw?$g3
zY?;lcCqC}z`&`QNYn4j9T2S>B4D2zIWy{uV)dMBD30=`3s0jV2$d~-3++!WC0#zA*
zZt-)fKIM#QiCH~$`gE&(;^gtu$&;r~wofmeI)19Xy0UV5`P6K3C3y;6Jd$K66xnbE
zD<H$lWRr{8{rBV7oEaS$KlpJ(-i?2X;SvwJ_hRCrk^f)GSlw{DW>lC?n=?3!Mw9q+
zVskZAY@)M;D$vyCCX&>_lnp)Q$@0tL*IQp`rs|dRjZ7o0WeE3IQGrub<6sWI!qQeU
zQ}h6noyJtw`XE25v#~rsi!rcm<i|lSK~Kt}gU>yKvD1xOwVJMLYzvnAFi!5IRZR4>
zCS({iobX-JbY0%(UuWen%DoHn*IBvl2G$9`5{o}*?|%lN+F~}B_siPzonUS8yY;>-
zUWp}ZRbTVqxZc>w^`SymJ3=OobNXkUH9=kr0ohVrm;5p}Kp{%X;7hd4B;I0Z`s*!C
zH_?}Xa&SfmB8+y{hD(`5|D2jY`wcSR2YypEGnlpRwPLNcPgir~T1QBcXb&d1eOGx0
z3e8z-;nRbkme|ca@=7p7^d_l(OBe>gNrVp~20LXVbRluS4DEVvbM^`CIr#=46Ei5g
z7b=G+gPsq5oFV1Q4>h0ts{F~_qn)nO2=X4a0OdQWU#jLr_u^I&TnzOn+Oie2D1OM$
z_Y<_=b$bKu<VaY^h}8I=$v~+b{}h9yvUr<}%!=HUM||REoHd;Tl60=(BYh_;!!?pP
zSWZ8yH(>5iG+A(3k93?GlP0JcYCNv$S=c9GGdB{kq`hzGIk7eodLDlRVo>x)^_n#5
zef2ioC>j{ojQ|A<u$;y{(;z~?zNjXA(16gp@aFEjowzE(sS8A36ptiDy(PzZe-g4w
z#NWmP>uUITj<=XS7ijg!RFV-$3bW?krYUE26neGSMEr514F{uhwJjh)oIRvm_Mp!_
zQJ}1m-eDzaBKmto9;1r@kXs7(M1^WhLGj>X4ikVkI^-i^8@y02mg^ay1PUWLN}M(Y
zP0Dj#!qf>SZyo#N8PSVIHh3YdlUyCGdq6O;k0cEo#<x#?6=|olb!7={_ZvG`5Cb)G
z^!ZMoPIhA%@l!op2J~cNuou3~@om#cMEkjVE?4t{V1EA)%j`8=-PSaEyFwq$t6LjR
z5Eh@mMAOgVr{r_csRBF*dc+o+{GPwL4T3+zL3{=HtBHs8_q?ZQ*IOxt$Df#P2N#%j
z*&{Xqe845#gFNGD{B2_QGgzB?v4|<)IkgkC_-LD46Ix>#gDP1FNRQPOG$*M5`KhY7
zuzB=@7iwAC++Id_W<7ut@Wcle5q>NQZycOfg6J3oeFCmlcpS(;s64ufUEJtdn>#sI
z$QMwDmO?M51QtC!qscGq{xh!k3OWpz*Ra;njEnox<yI;mg?$xsCHB}q^+<zHq2jTd
zM)oK<G7`f=pYQ32lfX{*e$3r-RNrQ5Fm*~*m0jef^M^HQXvpwAx-Wc5$wT9Y+s{w=
z7j?ThB!)kBpJe<kz$>__Y40O{?A(W+^6IrL!V8#^CDhe-HCk3AMUoipsreIfAgwP;
zcf2Fsn{l=ATg_@VwqE1A9lHbuNfwZV`LrIg$%p21@EZKVm-N_qSIU@^YjZXDgEzp=
zJ>Dcbz^(lF&<7;WUFo*aKe!~Ii`i@F&`BgdscB&9U{J0E^=ku)<Ht8Vp!Wyc<>Q}j
zxbkO&+vp(gTUDO-SX0J;E@aPc0$dXr{_ds+X77W~6EPrt4Ck_iV0!48HoRQ4$>ME|
ztLN8iXR{a1@~yZid*vA|Hw^tH{>-HV!Gy>+@~OH~tfT{yGD*+UAL)P`V0u*I%qbFj
zc%9zw#2c7{nMb5&fCxfP<-*07MW2#@!Bk7g@qpj%5jod<V7uFarnLBzNtMflf7Dzh
zFuV4VhzhF2oN|uzoZK^pJ{u~JfcqV*kU)VbHP1s6F+(KxC^DPA+C1$iTotG~L}G**
zz=1}#Kdz74|A8UAF*Ioy;bRWS)(rHC;-4Z0H#qUUx3S*W>V33n2l$`x4>(Umqm(<J
zpj}lpgqs2w<0njgQ=gx(0ttG=R~*-z8!9ixJ=yT}(K$o<0AEC#N!6NwQrCb30}>8u
zD{hADM!!+6=F%A_Qzky;do}G`e>|3t*DQ?)THJzgbU91ygokjLxJ9sVbl4)udG7x0
zAR51gTzPz&9lF8hnd6^s*cKnnn@@kABYSgM-~v}OK1#l+`(x-}DqX5tYnxmZl}trU
zY25)S1hdl*`g%O2xf4B}8X`-J+V}uf3iC>h95GVd{dP1AVc_yb&6-s`o@q_H$)4B@
z^P$Qp8c;?~W2TkC6bs332w5XzdnRt3z0%u`2wJb|YfZgC<rj{@JXeryAkx>u@{oDI
zqHuxQ7MRNtsge|1XM2mmGzcT-Xkxda73P>L^Nro*{gkuk()VAi0pYdk>^Y0F`w}8{
zr&Yq6$5@MuHkU>7lwxY*W4;snZ|nS!u9qNCdnG4W#H{wi=f=l=;yKobK-|7j$~PM6
zx^jbf37P`x4vIo&HIFm?aEin<&>xHsmGsjd_#9ZtzzR*bR_5n`4}nSO^K(mb_4&C~
zj3CFmt?l`_B)lp=*PB1#S>3&Vin<%dQRn0docm>Zj}E?%Hni>0);KCZsXtHr8FjRa
zk;3jvl@iq=Xu=j?w2(8=3l-aw^;vZLgkaBR8>w2RQd5gtm&GK*laaZxEDj}eZ(?bJ
zeB!}Z_vaIPZ9wy($T~vZ837hQt_gWKATT!mxrPZtrW7ygee=F{fGr5L5uo7!SyHX?
znx50GIS<}4I81@U6pFQlv#FY&Z8q^XY%Gx>vhJQ+d*)~1+xxj{5kr97+OvhV?gN?j
z)%JQ9i<#-PE^TyW%^xy!wXbEv6(H;gj`~vf8jGh3=W7|cATslew>iHh8LI9&LRc7d
z$8-HBn86v841B%5|Gj%0o<uKuCX?}tI@L;wIWDv_D?f}Wo~gR8d~zyErF6i#@2F!@
zN1yU2KV|)PU+M7mTsl`SV+v^A1CObETTb8Swg1664(nVjr)%hi!z$!cS5dLh-JGAh
zDwRa@b7)?L0N+vXacmkE+r$ETFX3A25iY?Z9*HcP)!k%Bskw%j67u#dQm7OQN(k;k
zAS3rewW>wb8E0!{XX4`)?$7Lpw_=}j2JrKxat>U~afTXmj@;{nB<HvrrW?cj=DRx0
ztqzC+Q&XNdE+5F*<c7U|5~e~STTJ^!=#R5&SXu%Hh6U@~1FbE*qbtHWH|qVGuCLG2
zCsknXwe}W@N$7||sf9e!6Ec<20=h>#r9d?|{%8_DsvLgKpu6jW8_Z6?o1sFSIr337
zL_8;XitNYZC+>Ko=7TfGrJzN%Hv`FXR)4-Y?W~K8SjhV*NoaVN+8gc7&hq>{q6y~j
z@#I{h?--B&E~%HApHD7zE-@Y_K#NA8n@Vs97%=5IOtBWR66BY!VeO2*BOTNl7$KBW
zJyF(CraY(irbf4k&LeE7(#|A{{^RAQjW0O$o__f+4>mF3fBT{%;6ITa^mq12hnUH6
zD=0!LMvf&)>^+yYmd&LWGNm#D4exzIUn3cRj<3;l@y-6*<VCo%e2q=C=+RbEz9KpT
znyWh-%Xsd`^m8Aa>+_3y6Qh-<UFJ5V4W0IZ@$Ikw80|V84G^qL4G%T!QO4T6=tqfv
zib19hcPt~(?z=Ts@xhm9e|$a(u>!(@DvWQQ;VUi_^uRm;j*~bN)@O3ooDq!uRS3__
zfXcf;zrxcmzSEKG$BUSo?l*E$j+lYb%>Qsg@Xy5krkq)d^1g|4K6%BSX9j+kUq))Q
z)KDEMw6*)PICQ6sl#UbK6fMr|5bKZ(f9`%-_zx~Du|PUo546^MYb~1--rE-+H;aVc
z!h=x2S1M@ST5oSLHg0UI>uz1D*jB{?!nAqOHTe`gs@6JetJQ58HrZ!g$yiit%RT>9
zb`6pzE5%Z!UP|RX+GB3NZ^5luKu)4oE~WjHo(DqZ#OGv`fstV9Hh!QwikXF_vq(+I
zzpMkv?+M6>S)-f(hsb~UhyrZ_gYHWAs+1)MdFF#}Q~m*FfCnicS)~BG4ko{%&LFtJ
zFoB5`nuPekFM~hDCXj2cx%0xSUa^GfW+mFO+C$@GI%Ve<z2LhyU*^~ZRWS_#i&Rjq
zJv}++yNuJI80H)Gb+18a2lmAAQazV%6zd8-ioUV<^Nbmnof-m_2?MHupp>kxp*{-j
zds{(0_ugH7vOh8=YSdkPDHKcH#XsF3;faunDxo;3pMC#_B`!L@*4k>qo^5tl17l5O
zk_igQZa0Ckcagbs*;9Op_^Jxqg<=1|p4$6M6*I8-HS+l|#S;I)ZudHw7}J}V!Z9X4
zQ?94VRaM8u>>ax&S(U4zgd)3Ws;b1Dyd+QCJdcV*$On9{<zZPRe=an+e}Q?76^t2c
zZ+3UKnvz{nK^Ke}MX6|1O5fslMOEd&QBV!8;uqo)iAC^ez#o8es{`h^;uln&lutr$
zm>kBxD5BUCVza0w8%h_AQi%`EL)A-9uJsE2TvPwu;k7f}a~n2W5#*5%{@%GS)HGJg
z#UhZ<RQ`-t<`3Qy*P2(fx5SsD)5w90>3z`I+p3qTma@gNhGO9PDP65VmU_Dn>F3$~
zq@s15`-&p+adR3pU=XGe#9j6YjeCM&%zwd|X&`jg`*~H@#@rC91$LykXa$m>v(eny
zY6rT0?Ga~B{32o|<!a5>pbK_8NCkZq&KeKyNlev`<qdEvZv1iF^^LGBql^58iV(fl
zu}>Cft;O!*TK}}O);k-jcxwe3X1U#Cv&(8{9ns_fyZ*+DjgC$qJC<TUT<StO8DK&T
zf~yy4t=i|*;bJSB*!8uCjn8jqz_aQ+@cym;|AcEJ-BU@|at+ul!7QlxV>wiXq23AG
z71)ZsQ{w+OcQ{-e?;9Inw-1M>mchhF%taIF=LB|W<&fQA@fkfn{grM_D?CwARo!I|
zbu_S2PV?DheQ&<RkuB#j3D8GQ;cT~xo9U#{At?80*5S!ez7JSb#d^N#O!&Irvwm*l
zout74=N>Rg-78J)1t?!*2;avhr9pfj`vk*iu~~!jqU#jyG_q?}>|_Ichx$ZVh(_NP
z{*xmUQOi=vSJ1gtcd(Sn^xUc_L7bP3rGg{pgHTc_3I`s{udyN7TyOEqoa?3GOyo<I
zvR^1V1!GpqJPo1$G5zd~C*#^E<4Rv_;{XS7+%pZ|PvL6Ym$&H3maXj_1T6qiVU=t1
z3Zd@<`~PO1_Qha~n82_fzs?llJ>Hzz+v$|Mx9B^m7jn63y{@cyZtFz$*2tPf*k{NJ
zDubS2((f`T(gm*@SyOnEk&m+?Xad=+gw5$-7U|&+&~AptRElzl+03;tG1a>sv1^e`
zr@cZtlg(Cg1y4DtGF|3uw}PTo+|#=?t?s`qR=t73<QyGsjF2Y-3Rpr96<uy%)=i2j
zOimP4ss7F;ro(SH)C2{5X6(Pi|I8Yd`K0YkV8Th@Wesm07W#awjVST@?Dw%u{ABuN
z%&{)34oItm?!vk}H-WmG_VUhVXZt}&;_l^+j1&e?4N;z~9n|~P{unhz-EK>@>5+mQ
zvoP`Z`H1Ej{}gd#)kV-V9yxLIUsxWPL2j;+DU?uKtI9;lp|l_w-CzXCn%+(<gl|$4
zh&?WJC^o=i%CP~E;R>cd>Q0Tn)5j&wQ~pb>+>r$wS56;UzHv`5Xz|Dy!$O)ecD`AL
zy~inOIyXu%5i}*OAcKbyf|Afx;LQ)~XZL=bxq<XfXMM$Q0cgFxbRW`*h4wm9wcvTT
za*}zfA$60?Nrlo+xdOg}+71~-%(F`jO&T&_t6dCY1P70i$JM;%;n8Qkni1su1+?$o
zyumy4x;CDSC8tsQB4sb(`1rUFIYKl`3u}Nivx_8-<m7bn+;JOBv`;dI7j(6x6!<H^
zPh%(ERDB8vv@WyuV;y{EWcAeJY9ArLFw5{6n==u)SP@a9Xo?ubUn&|#=6H+V!`@A0
z7p`@8)-ei?V-K)dw@Irin=Y;I<@&!SpCa;uk$`3}_?Bn>8aNiDh|`F^#WwMu%t6v|
zy3UHsirU#gC%&rRmERX$ZhiY?+V?W4T(*=4BK7>7@a_Curj77GrzZsmr#<T<B=2`(
zvzYmVzT6a`>s8M>)9g0j^>i?5{#vic?hBO6K1M2J<G%!_$HjjiU%5fRPm}<LB<V~=
zqp_X$&pNsiF>@3IR8qB^g9{MDbhiEyT`&e@=8ua@rhYD4%-dwQ&-S`DF%x5eS2X^1
z3}<J>Lq<OBPxU>|^04QLkSGI8<H25@d7k*^it{|ix49n10jQ+Pxf;se@KD;_rs<?|
zDXfe@RN3U~_8JbqBIkwD*kZb<MrJX{Yh$>i7&=F^$6^NV<R)ma^&lmboM2q$zp(zu
z)XQkq<(9Rg%m_&;pm<=>q%cOBEJY<TF{{f_L&pQk5%%&*dud0iOjf(JE$%jQ;xCnt
zF^iTDa~7m^L!&<>6e4RX_t$tE<?MWxg;UZ#q752ISO?bz+Tz~ijK+4kPk;CDf9H2a
zPFBT~>NB5?^J%m-<d{i=EF^s-KmofC$PiaPm&w&k8Q&>18kR;PzL!DB4^Io6yo+jF
zVBo9nJu3I8nq=DB0wYcfuUYGEcUB+tyBm0GhqzR!m6c7KLrgq}HS>~rkaBt5ZEA4@
z7I(>8J3aKU$+W!oa)(&p!=&W|?Hn??;fuSz$f0e)$0!5b2XX3vB(GB3*<RLry&%SX
zFxMv|BK^&AjryTVW89OC6cI*W9R9l1<uhp@^!jN`1qJ9iS7LIp7Gqyr2md&Je+A<n
zvYVS-P*Ec26+U=tEW0?*c8Rd1XM|~l@jpN?k1&iShbcL7xxa&NqW|4n-4OgPf4zf<
zg}nc1BS%h*VQ<KshM|2!@$~^HCwdj)pJEuj1d|!W&g42Ab9krj)llP?H<O3@v6!e6
z=!LT+BUsCuIFX@)v+G+6?d^M8>pSfr{(n6@Q#F@r0N<#gFtDtnuk@A*(s@BnVgGd^
zhgN$#+Yd+?R?uTym~-wMJ;u3I3OU)b%J5rK9~h%%#+LeuF>0&*@MxdVG_d!K*Gb(D
z%hJ|N8NQvKwsInQJfA66(uH&hla2utWBl2~w<*0iy1x=0{{;Ihj}*D;4oiulioQ<%
zzL`I<z(Oz2#uCp->I+Ix{v%Ol{nQ&@(H}pHiNhDcbJ0%b5w4xAjMwwGOuY4b-8sW2
z5aLE*3?P}d?pGz`L7wZ87d#g^{^r@@EJoHxM6`vU9@FcZ_@627q!wgU!A5*}d}LW}
zL8K4#m!v91CA5vbKlNXf|88qf)ILX9{o~pqc$5J?%(!P7CY}{Coa8Bm*8lF8#Fm9P
zJ!kU8LHBY_Ws7Y+UgC!=PtU-<&!)<iMp{?hQ`k|&(YB|1t`e;@jOO_BSnQ%a5BK(V
zeUFEqQfsbaCbu+4IX*oN(eGjqnsvMWTqh3fM1cd$3f%v@_5C+~IF@}fD!(!|5e%yS
zbelPit@38vuhFk(w%1jELH1gpUkfhAWYtU8Gw3p_DE&&8(D4gvve$K6V|V>dM~}jG
zP8G74?5HxYBoWe1*rzmh_ior9t=IC!bg8ED`ZkoWzDq3&-D+&r{giWE)B<G6wK}>r
zRlWZN<3~B{GnOy$#Q)~RQqV7!uV&HR1fX_V58E3?i-0x>!&h8^4G-TpIff+h({u}^
z_I_A0+NLiW^yBY;iOLZMIS5=R0*B>fsvwwX0bxhgZpokzbrfja_^pY@lzv7IBMyQ%
zld=zMnqT}iS07455H~kKx*3Tbp$f+_!pkWMOyZyMXZL?b)x+2saa*XqL~ru;nwm4N
z9Q-BVq+FKo8M|cfld<?U5}*8;U{XWR&wsZ=Uuft`18=!nPCH%Xtcp_vB{UbA*P?|@
zLCu&9nTB6cK^Sx{ni}83H?w|2Dtz_u!d3RPo7%L4-{2nGXz9fXX~D2}GWL=VROh-j
z)yQS<WAXNRRG+=R!3gq=w&Vg%>@UlA1hbLLcR@)Txr_<aNPUO>o{xZT&F95H5co)!
zbWm=+fV3M>jxj-bq1V~)bzuH(&7(J8Nd8`LZ(KsAmsMH|uxoa<RIQfSx-954^!HTO
zk*66HOQYf^T`j91h{}`-)sd`NnrVF>dP@|6{D1<VKPbcbT^_RK;dwr)?=SfhSB9Vu
zF%$zDlva&U_0ijK#B!WCq2XEHub(CHo>;VId<!trV83m$^d^@SPsYl>{aeRgn~*3E
zLr%Ozuc7w`Qv0_m4HB%i6TK@o?7?e@IWXUxLqHZ$)bl3{Bpy&mnk_)9Z?=|Ib@R>^
zhp(JJk@V!hdT!(MBwuRn+vKTI9q6-Zc>7HO;5>Q43-C=B-#C6;(kx5_b&jLs)WSf`
zi5)6?b_4$n|7Y6k?d^U{IDCH5tkXYXo^}Y<um+|yhGUeafb|8%2+>g48l9QEFBW|(
zoYki(-_7j}5ud^OTzHM_DJ<GdcdG%#ztBbvf<QQJDc>H;6WF+SJ;#x62=^4rjUooZ
zfERU}Fm<J}HLLRGS;xk8V_bk?&DH%1d!97V7ge$P>Q(uw7<?w)u=}2VJ0(2JRubwm
z*H-RTWHDnDf5DuG=w`ryNPnH6#F`Ymo6EQbNDm45OS3ip-KXj7@V$=hk*<5ydZt({
z=%#kcbUFZhOfC}zyTUVLP@D-`e#`@D|MFv+B3C?I>rQ>G=`S~N)0EWV5_@pde1;m*
zpr@dk#X_el)rxiq7&qjFY0%iZUn&^2`k`^)1DnW*gJ$H;?stoP0rCp^ivhe6_!p1-
zrn4rQtOv+z6fo-=R%$_2{wMp*8{)#)2xknXC@o%zw0`!RuW;zI?)jB$qn?+7X`G*z
zqfc|6yj0K1H>G;Xsh@rxb1twA);HP@tOfHCu3sF4<uhUyX@o!<sBTB9wAd#b9^lY(
zN{m0{{S^62@=TCCo7)(?fJ%6bV*vJmtj%k%zQR*`3nuR8V|ifCA$4^XG5ewOXTc`M
zo=iLuO9pDcVdP>=)Sfi_bC)~!2Q-`ZYksPz%C1eT4SxGVL`C^QZl%Z~3Dcw_8!O&s
zT*n%5WHc28QuX!J&;OqJ!Oq6j?&Ws#f!6jG25)p$n{A!Q`J`U|>5o&dJ}^$L&-i+E
zaFlKQbB!QFR!Ld?asiUd$}W$f6(x))mSyI`QI0CsJtJ=d5BDbxZ9dAif$r`w8wx^3
zP81Gx)4E?RoM|vsnWu{&t6Q=_Y@O+oK~1ym`QTlt%sCJrY}{<>D_ozW=d^|d?gnu?
zgl=xWWssc}HXzKCMM#fZdNT37<oZ+hGR6mhnT=+5YgP5r;C<r{EmoZU#H`ms0WAdp
zQQ?M8Fuo-I8ZMi-W8Kj=r^@L%oPQNuqBTOc6T70M?|*+$<rjU|V1hA>bqc`bbs2sH
zWUSKvAJymbHq~Bih{Z7|dOxlM1y&qPuj8I<7%!@>w0D_({f$_18aA#}pI*RrhUsnW
zJ9F3nNSQk?L0e1gAECS5Z)QDrv)6<lvw4X*Nn`H|9T<E6J9pZf4>sDH46AJ{x9Q)b
zzw1TjJixs{k9MmA{2Alp9DI@eepCySu}PDr2VQ}Jvvpe(sH)Ipi>S;SLk8By3#a#t
z{=}@RrS@iOc^TkKUZ|SHPa#jF$B+nxiESg#-1v9qyJn1PYV*>LOd^)?ro+!+e2{~u
zAGeDTj?vakoET2c?88gxchPSJF)3;==t!~fvXn7y_BHucV#5K-&gq|=exoBB3S|%F
z?kS{Zq7^%pIPFlHpfpRV(<!v5&G`Wjp;DrH;tyJ+HdcN3PUX9>zcW-155mE|8k*jJ
zjD34BqG>~O&Y6*;H$Ls&yN?7xu~<)+Rr}5a<><%sek8w>vdk*Z$oT~0Yn9t)St!{o
zb}N=R@l>e37IXM&m;q94h+&aWwKlpN4_-ls_xzlUz1`}ymfNhdRk*(L{lax;{nKTy
zQmhthwW=!mqoZaGJZ=XqK^lgRpTUN1QW4z_MDonuC;kcbC~@#F69_+%_?+2`S1BD8
ztLAoK4a~R_`SvLuGc?hx#qNt~3paN*C<KvVQ$2RF52x?6zHRcJG%F^gdJ<@COA0CE
zv?s?ITfXou_V^jVnN=E%e9jE2=N>U1z&%kL#ogofsMmJSoZTeXD;r*nP~|@w-syc$
ze@s@`2sb$>92;Ar#@UnDCmUuAFaa+5RP@f?zjm;g;E<qDl-;-8t-w7A@^Xux6}f?a
zDgu}4F{Wn1EzTwJ0@<H~7czdax{gqK8#>tN-gn}HMt39Qj{JIC4}BmRSZszLqP`e~
z_a7H*8wQ5L+7_wtI{n-S^Ng9gfzqwD&g!-kE=9auybKAMz7|@0L{#<s38JkTnO^vp
zj!YpQO)6U{>0ALL|I{WFETlbBozs5B*H+N*FS?v0XZ3++;~Ljba~~1e1GWGnWn#n2
zUOW-_CbJ=z#Mrfq$NF@^GKM{%tviaMjYf!|!U28;XgX{<j(>{bl#J_M40>*N-zYj3
z*t=Jj5UF}#xw*5wdRiMQGGLU0X|R{XqHms;nqCb{U&W{JC(+C$MaarPIWh*F!SY|!
z^mF6Y^y83^IwKGw^;L9@Y@O};YwhLBxa5%*uldwD82d8T^4_2d+G#Y=WzhG|%pUht
zE3Dke(F52i77aZJGIziW=RDPnZs_q4_Z#@$=q1UQGezL|s#-qULzH-y>iC{Dg(x{0
zE{w8__#R`J#!kQST*d3fYNLMUY%`Nx@Xr(*XX|I0<?NYSwsL&d&L(ZVv|pyWwa!Nb
ztD&Lz?(R_0I{xW~lccguKCS6w>ienRS1~CZvx%;0jG2jX*I@V2JXU;W9sF2nia)Xl
z4r-o1f8scD%#fy5wy#{a@-8_Ch?h*Q0;tavChri3z{GH;LfE!BuU5<CGJf3;VcViS
zzuj61(z#MP@8McCy{5evF!nz$xYtPD3eOtUYb>nh-Xn0=((7Q4lbe5BpYLGm2>lJl
zCw|tNTDGnYkCwQ3%-TlD)8%?DRjcR9z)f3TZ*9RA_Haxf8+vx{h%;BH<?^MX>KC@w
z5Jdogs7Q+#N7jGhaWt*0I-~ie@QmboOJ=>FZ}+bcx10hwEl5O1w=u(Bk6;rseVFAc
ziEH%Q_1`An#hAhOtP>-WePZ2#$-hiJkNyK9Pgj<fQGs%=UdO|~q7E87k0h(3ThS16
z7K)mvwKh)szHlC}nDGJMoL1yOUztC`aau!5(~ml|ln3TjDw9rSF;rBjg~UVqg*5VX
zdKM*41CmM{xbg(|h?<OStyV603Yt*Rd?kO8Jbuy(?AU`JVGc;)k1At!Rj}pJC53d`
zW$U+nnsF$}6?K=JD@&Jfy;tkCPwaE;!}zaGGZUgbfu1)#O`p@>U7VSO&o{n+hZ>w*
z1=^4zBhvu!DgC_3PY%khMbF6?HqJhRTcZP1M@-Lg1@~Zeh~#ilr`Q5N{`w2Y*wf-<
z$3xwoO;wNlnAy{IpWm=GF`MR@^%!8D8GqC>wGp-LP-%pzj4<*y@e<+nEi*(gk$#Ty
zop1h9+&KC<49@Dnn^dDQXXfW^>@Bip(C~HywGZ~RM%#k%PdAMC#n2!G`V7#G=4X$e
z5Ce>;mmX*!diTb-vQqp?EJq~^{!y;wjI&0xn_mGw68#0IEQpD~nXGgr(;%IxK+`q8
z)SKP9tXTnBZR7+!K;sE}avIUU63@Ago-O#mI8_!qv9#XVT5E688}0K-;b$&L8Iy8`
zF)Rkt6R%~83ysuS%(^~fk@0oQtii?iJofz<eV=^0wKHb`PJkf_KrYPa!Wf!|)?sAG
zgT@2jqqWGFHn2g{lArP~2H#QA9>i@Hr<Kj4?L%5NqO{w@l0u3Sqb_;?QU}f-nym!X
z@4`hrX-&G7)$43#fq$Ur8z0k=`IyGKzVT&RSBVFL438wBNbF;Bu+}ya-q%2NHJE?L
zJ=sX^)j^Rkld+k5T<#k8)`q&`<DN{OGif;sVhCic{D6|?hsC!jdPzF5l%t$rdb|Zw
z#}c}lq;7LK*F*Dc0f~)3oALAa-lhDF)+WM+AitOxhR<?Ak9E<QhOgJ_IsHS_`w>0q
z(SkpM0S0KWNSX}lJ<WdZ|2SjAfv7y|HI>Xf*OR&s<<n4@HJ!|@mIzxOdo)h!XG!|>
zL*3b|p__0^1;imUIgF_vlbm18fUuoyFIidrdnHF69<Nm!Xp=7~2nfjQ8YG#Wo!<LV
zMVt2oo`S_ih@w&H#uKzE0Z9;{W#Si8ztSJSm@IbL2>Wsj-9E%=P~nSUjc=Tg`21>n
zt-HRWKmu)F%fT;j-OjhxFQ;1ww+731?tB<gLf3F!#eU1Wdw=TeO}6YcYWZ9y>#ICp
zfAQD+Y4KQ9T8MwD_7H~dshX(F=+QD5uYBS;`4aV7&*Q8Rx$XfH!6x>a#Ms_qp;juD
z8x;(~Nj2u@{Q8+Q=Ne~=^%{_XvS+jY*=z>5F>~FG`MGTgd>K2``w8ZnyNDxpB)4qr
zgO9lO!SQMh;hRha?mFsDW!ivW*5|-i_z(T6&1=iemb?%<MC^v$59vHMV9kO=0T3y+
z)@%*`!9U}=kDR?j(_;MDJ47_I(pM($@U1>rk3n{d3St=EUQF{|J6ACK>P&n6Y*zqk
z(>trHunUNwMs1gEB2qwm%;ZZN59>Jjnd44v*6G0S-~CO+vq^2HE~7eXh2Y_ct8J^C
znLw>bE`eGFazkPUvewt0=fvPqUk!YidZDJs&!&V_T%{s}g!(tL$KUaojjJT*%9V7c
zkwX|C0eZiZOeQ@!zr;jjFOzpNUesI>33v%bD-knEb&@a0rS|fcMrY6~Sjl8DAxc4l
z_p?SZ;Eb#C7s;RL0)}>+x=7oOMP}iF$P#=)-{;h=%!P|DZHAf}<15}#MwP`Z-~XRf
zEC2({jwCO}HF59|1H|vRXBu?>hDvQL{|&A@nW<%~bqoxXOp(@KqKk#zu7&0U`d&I;
zDdsfhL`^7za*{N{L=uIi?E^)posFk?3Gt-?)roq3M*js*vL!I-Ecui`5vn&})oYZT
zO?=nz#vP$pcL9(~^;{`U)Pk9l7{!M}16jOyzoqjedT=WMZ^`&26bucO#jRCwC~zJV
z|MNaTIk42e)Y*uJGddap+|=tf6{?%}y=uOk!n!GDvuR<f5jsF*F6%c9?<2EVQgXi^
z(!936(HF0Y#2wQ#6~SWzy_T@qH|_}r5v7SJ1hdwsf1LLp)c>Mv4DpmMW{6nIfB_h<
z1UTaP#xY9O&Ee;{zH7rSJAcBy$I1}ACkZpvWGE%~oz)IVNm+1-#E13%?EN`q238Yg
z&4k`t=?<Nb8UGm|Lc*K$OvpYH4>%}VJ%xBc*~`@{sL3g*p+%F62bk+Ufx1a!Tg{-(
zqR>cH3K=~Mo|nVp1F1@W*ziL}UXqPi-gQP^QbbW>S@VuOci!cry(@iuv=bHg99K3U
z*`jezFp`hbTJ|Jf;n*N`fv~8ikgLT*q*C|G4+<Qj5-CH3tHksx^G*;ci6_!lhR&q(
zz@^L<D(Ls(No-_?3u>hnEgYLZq?w><t4u8Hkyq*Sp6Xe|nUiT*e)gEi@5IAA=BQ3w
z2evaBTUaO7-0Gq6cN2p(=>&$u9LHs`)#uGCXcN8!j$47Yv0wMjDK<pgB*M0mK7x=z
z<wn%mjwOpJ4=BM{k^r-H|AX|$Y>Zb*sE=3zh703+$hh&N&&>%Y<DY9J!Qgp}-8vn{
zpeW|6B|lS%#-Lytc*zUC>xHr6E9F8tj~T)w6%q)woFX;yBGk3v?dyFrz3S;&)kkL`
zzs&EkevhZI5k!9A6jG7yY|@dsRFzK&xyx|T7ik&1_)}6pv?QfNLH*QP;1A4(`~k@!
zh^>A2^U80^FK9P~6+nLX%9Spv&TZ^y>I`ji&iImEiVf7o8Nc-KZH^2}mwm66t`$l}
zbePK>8ta>)iR{EjppfEf^V!r2Du+*lMDjzjBmd$v(-<=T<UvF7pa304SD)PL=kzn}
zf9n{ztbsMDh9<{SR3qp+{<((Hx5-cDj7)Ur0H<qS5g;jrVp-J>Z@~&}VG!_&G#7(c
z<u3$=)F|N7o~&CC16=LX4T1%H1+Z#u<AJFRP*WogL<og(?We&aVcatfTd+cbK~=+-
zi~rV@|EM9WRI8QJ<mXM?t@r26ciQVEPuJ6_G>i&CUC5`@g6ev1;}0B!W+UfnY0Mk0
zE0II~X<^rlublX|rte}wW#=5#(+_rbpXQH)pQG)M7^LR;g?4Lmd2K;#x1(`8pskuT
zOWX_#LK63yYyAh28}p_fhS=gO?PYXs25Al?HF$;dWdJ;0B+7W`9f7t<mS^x0A|1l}
zLbGppk(!OL+PX?GNx7c9zxYbWK7ej7*E5Y;L6vV%veJlB(uS`omegyC8J7F-Al7{u
zpXd3f>>kSOVU%f<QmKq8DuLLlim2nc_+3gj>I1%1kpoIYM%WmZvu{!ZD8FaNv+_JS
zEAqVA+3vQ2I9KECtm#m-AKKGwZEpk9U&X>?4SK&Q^0?XDytIydQfCD?u9@~~3uBIK
zzs?OEyUhf_M;p5hm4Sq3M-$!lqF(Dl-<*abOyz7=Nqs&NACs$K!z=yjjjKSTZ3~Yc
z%p^}f-I?U5wu(_b#0aa=pBwL$m@P6NP;TbEL(b+<0ZY-Dvc3sp=lNbUIaev=tA4JY
z_u3dJ%EB}wXA)@E3T%7K&yzV8*^Hz9$;~7XN5ct~SR>SEPc9qH+KL=t?E#pehSw5L
zh%N`O%_oui0n61nHVjb+Bl6X}I8k{?Ri(?|$vKRu>8+!$1hIx0WF7G)Q%6_z^B%n0
zq5WLmtEWo{-|2ZA<_7WGmpfzNMA0%gy^j$1$jZ7QC-fQA9S_TE?CH0<7>37-#UhZb
z!P46;G)X>=d!zmGRsFexQMiq_q}QKW2b5LdHco!<4dijDmt%*!$UJ%0#3LfN)y!6T
z`H+5pcb+*VL`r4T=`xt^G=XInV2NN_lceXH3^bVc1{c>6Dl_VvhzT1S_aJuy8V9Ce
zrIgDy8da4sA{mn^NaWmmzO+COBzzXqQG$|MEKTrhGPag^6?x`;r~eTOEaf*;|G#{;
z=IU8=)|N93P$`?^gPFbJ8DTX29OoTqy=!#Gp~AxS&(6;`&m^PqFul_<yZ-3pCo+;s
zZXvfddqVE#-Fkm+{7I}j8$I`9f@$<9htERuu)AG&oP6{(%q3!86+={m3CU0xW(Ic=
zo?nCCiMqoT7!K!SNL)z)f_f~i@4i8F-16~RVsqGh&i)@LzvQaq033WqjI9Z1@8D-0
z+RNlUKa26dnQFg)RgQzmCQ=uPl4QpZC|K<WR9QBF67&Sf8uh-KeCgZ`$I}3$sI%GK
zkX~1dl{(exx23V91AXZDe!-DQ%lP7Kn5E3!F*Z-)yPfsTAvRU7qq0|{;?Q;FGI9m^
z7wsQaFD=W>4~%}`no`eG4De9((!<gQ_U!&YSNW-CK7z^4p-v07sF_h}?CV1}eqQr3
z6$~0F15##L)zPd<$K)KYawlkAuH`9w8h>*;vvjGdKt#;BAWjlakJms{RimS(-eB@=
zvo07yfSDlII~}s;Yq?y$oUbVOOsYt6YE7)77oLMzL~K1<apz!?XqCOnn89U*_b1mm
z0Fjz|4=_OSzR{I?&mEvERV&;u0v#*J6Rj-cpJF6|;+bT>geP~u(y4`ZICHCWX#<AO
z8r!osw-S%(<M;kkf1G-PU<ly{pQHy%zWlIx<~Q&ehT$-ed+podhX-KH!iTbV-n$u7
zs<t*S6DX>+VELdi?f7xP<3iXim(3`&3>v?bB8m^xYcG*D=Y6@*1p4S&qC7CSlszLD
zWzpXVsXvjfIfP9_Ed_Bi`CH~9rIxn3>xh6{#FTA$PkeN__Z#<%zSNh1<t5|PHoD>`
zU?ya5y|au82UBy@cs+H2t~o;b1e2poh0D_<nZX*~vC(#GjvtaKdTI31WRMaC!)sT=
z>O^a(@jZ%gF17uDlKjYwAk>Q(oACPYI(j3GFkmiImtn06%z)>OaX}jq<puc-M~QfL
zFAjfP*M7)$V>Y!QW}rdakp|0wkJQ*x`o;RaBMa;1S;gTTmfhIi1TBT^m>a)GIn>#L
zGyWjx!^rceo)e<uaxPoQ8rO;IO4CEpagqL$jXfWPd7#{=7At<qRUGmK^<AS#ObqGk
zTw8b+?NDH!lpx#q`5+H|Qqyt|vwXoXpyIP@ovpLd4?Yz0!}!KtQvBuRwjkTRL!aw#
zE0(RBjhN*zuFOKHN;W*49kJ%EO!825#rTz&c4HM7AB<>Uqf|qOpDZEwAa<~V?g_s_
zo}lzm_M~U+*Tq9s!$J|{0>9#3jP9ELfOCwN4sP*)a?~s>?T2x=^Tn)R$3Qhc0?h*6
zkD>>@Mr`0UMkc<Eu>s%!uXZl&AnlC0;Hy|c;(qA*8hHy*IS4OMH^P2G;GfXnPrkU{
zb^s3JGE81veV|zzU*$vp4EB4Bi5vfPqb&#{s}BFzkyVgTRUiOnj*PM9_F4(pCmKgf
zDqHK}g=|60<t+Pt!6~7V*sig^lYijIZH#ooFs^#BkW~VpPco0Rzj-_ZNOd83Yl&BJ
zMSIP}{}sMwCY>sRQ&a$TT$_KyHQ%IZYq7u>ajf{o_|vAtQH&$s2ay|DJr$lo(@59q
zP?YM?nT2y~Z*n~<YQ%q*^}7Zj5E}<UEm68$1=zg<?nr6RGdOaeF)#?_G$lC-l=z$P
zQXX-eDBJmiUK4X*hJLTRHKAz?y8wh`-mldah}q<Ht+B0=4>Q(eq5zSzLRD8n(5?`4
zDZESX_rbr4r6Z&kUj9SEL|RD^;vl-pXSkx^C20E@+s^xp*lYbbA*&Ar4OG}~BNuPJ
zpkFSIia%;K7yIr<n&z?3G+ZjGzJr(OJ@UR?>|3O#HkPmS@Vpnz`yZqp8G&tbAx7w3
z9C?~hK|kBJ8}FSf*YeqV9(8c2irSd<a1X}rIC!<(n?Qv)zU_bO_v;4Fbus#6tf<Rv
z$?U4&*vIr*AMW?lmhl>nXxwpar;$Vzu{HykYjjP#kyU%&=jayXiE71qsZ_}-8EKsi
z%1GtYi8Q1Vai@{;Na{O&)UWw$JR}L4iI|@r_$m7#n-KFZE454&_cWeO$m{c-tvSe|
zBmR&IA){aJ`qGdukgZfv3<BIIc}jZ%Wxt)3H_>ik_%XdNwzi3Q+ghE2zm8A$&sNDJ
zQs7Qa^MA(YJTDNkK<|a`-98`G$vzQ|{bz05Rpq|7&Rctb>U$kp%a^?}vhFEtFBkik
zX^lFWnpn9E%2$(kz`@ruHmpJpj_2vx^N0)}Jb(<$`V!hc?3{%CPpUl}g3S5s6<InM
zEAdcShh9Wn1j9j5EoAG3uD{>0l>q9I_A#Nhh=vv#KgWFf!6u)`v=F5Mxt%}w()w#E
z+eq7p0RnprO{Kt|#vj&3gN+ZDxQ;Bo3M$!@6j_lry>;>wQ=0N5npGqNdnY`WA0Rtv
z>l99W6J-!1tb$e@tkVaCpNrDxsoFntg5a<qV3|R!cLDm%*p$f(;_tb18Q>5e2WU!%
z4P2(J&eA%f+cJN3er~zDxw*rfuiOGk4fUQJioTq8rr{d%Z8Xk&Xz;E=os}$?a=qQJ
zH;<0o6}}e#Q|_hlkn=3*tOuao2L5BH6Gm&of<e2`(tRj;1hk8+HTr%|dh)$@>t{%+
zm?wM$r(l`|$`ke+qk;+odKy(2twzfQ`ebj`KI2TT>Y>F2kiuC-UyK@9a(Oz~Awom4
zHlGdkIW$V;N{M~Tg}RL)J@qAFom0=(%9_*qTXuY5zk+A=)qc2cvYJC@Rw1j>YfAo+
zVX<AQ6g|rayu_;Bug34wP8^+2Y&MzVL;Q4{^kERsKe($e&$a?7a>P6`;xocj9#A+B
z11aoujDL#Z<~EqatkwP#DkiCO_XB(?1)ZjP2?fy}X=bNZ>Kv5Ia$E5}K4Hz2s+h7l
z$-Q*nT5Swls|X8l+_j2-ijiw|x2CIUH8YKkHW+|l5<F%lq;7>BamMC6*m3NDs_*40
z4S-3x)pWGl#<V%9dmO{lOPtX>xes{{nJpP{Ac_EA;!5js`{-;Yfi6hjEA1An%3VNJ
zg5We_$4-2wyq^~SHgTZcyBxVvK)+4S&o(kBwh+dnqSEH^th~WTNy=a7-$HnpZ&EQa
zd_xV%XQl{JAD>i5g7<5Nf4@Zg`66+h47WkoM48aNxW1B>QtjSEwRvZI%R}82aT(Nj
z8Ox`W?I{}^EF9O!9YlGytt{|Quf5XlL-ItnR!!$q4WyX`Zc_H^9eV8!J{~K+(NuHE
z!eVAzM{am*LkcQwPHPwUX!658@FBL_0%3Zd`b%uLy^FL%1&>SBr8c!7ZLPF=(mxjM
z0dl4A<J^F+arhjd1Mzi2j0X12llM65iM&*~mMP{l*@kzevvIk-xzS#qpGAa!YkqbI
zzvgGRHkapTTfH7%cnU`hx1E@FbLJ=zlctbr%2)kp^ulNnDjSZk$s_7D%{acMS0Kil
zk;}aT<uaTu)iP{SKv;7ZAM-ea<p^hJFwS@=B-ofA(eyHPKi9pra<v5%c+LY7q{SY9
z?!aObB=soUCO{~#zSF^dc3)=TGG(%vO1@Tg@`W@NC`7nuMG+rdW2nvOhT4LBK%;?c
zjclQ+`M|Hlo@*PPY?LecbS^KRTA>0jAh!+?S3qyMd?m283h#2{Iy%I2d6@Dg6y^rk
zvHpRz)OnAp`jA!&Upq-f`Lg<$Ay@?C4No6_Uo4)^4bE#t*dEdR6o;jQJaqCSD)+g(
zv$=_EjI{y`*Ewr;&~(-eZ79WTzFbJb7?;PMpnW>4={k9nHXw$Yb{iCu$CBtZqQWCk
zt&C?#XH)~b@l~d_hw(zBtenKcG7$MOBfmeb{BhgMIKdi`k?b5{G!3AWQIWTg>gVbG
zCha~JtI4FX0LbfEZYXmqee*o`M&i%H|5NBnGCuK4x`;UmK*1<voO)9V8I~t7B0zCN
zSwKsPh7kXvBDmz?oF+cE_S}%K)F|Y0>1;zK=WG?bQX5&}nFTMXTkHKliq>DN$y<~n
zI&ANiIfZ>DUQpkB0ZP~C<BAXH4;98j6wAi7Z@#F{W*>rYJ+AElVST%(k;#Q`)O+|y
zIL?nuSr#bE9wK8)Te2T_>*L;c#gSL1(x@b<_<HPgO_ra6`>KuiuEGCCytj9TrKvJ@
zPQoeYgPNW<o4Wl|;r7gu=93#=%DN%c&!-ji7DSU4#*R;hIv+Ky57qL3$Uu4#`7Rtu
zGEKZ%W9#+yW9bW64dWtK8AmiiP7L<XZd>-^|L?$h6J5wYR6Qey-W<*oWKtLsh-r;f
z(-dd4yp$ZO3nL(fZ@#-1&S7Wkg-j`*QKoQzz=tY-S=ES$%vt*$D_fJ0t)+CXApue^
z1K^5fbQ#ajq4}V@`QZHAI!128ctYM9VY-~=pT?JIpV8u4Gr2m@O(di>4}q6r@jE{M
zafk1ZSJJ6`HC0p%_>2ll{7d|m{m&?wo1}nMLyyIrmC7uUHFC`E(HY5#Ygyf5W&hlr
zB0J_+VeF3{V3Y)o70&%ReT~CEod7=UvzM&{uvkN5``-}Klj%&pP)O@?LTXx?)rvkD
z7la*cWd99U_Mfa~i|B~<b6#`p!5;7;EH?Ckidk=U9%_T`kA|D0r=lK-Rs-r*q2O&`
zudro_>BlXN&!n>m2-S-DT6*Gmk7lh7!~B?T_~p8RlcuNP@UnXCCEly)D*1=8bjZkg
zl;e|DEEmM`{r79WpFg9aD%E~PcNU4tynr7;S%{4}{UP%d^Jl(ey>(@2rPVyOe9ua|
zb!zFva_iLW>A98J<&~wm6Em&jr&n4hXHU(&MzeAer^~?NLI(}ve?i>r2Bb=0E5dN7
zVrE1Z9U>H@eYH%aTPLC?VwJX{qGg?w;sF%F{EHhV8D1+#60ZvJMy8gjl!`SayvPg6
zy`=X^`3q=@&*=TW{#WD4k$dnUM?&4>#=l?$4$x`io@r1dP2gq%8Diw}&2LjN@1y}t
zbDB;?ej6Eo{qxML9)VGkHUCv3e<vGTe40+?0I!TuGG!wgzpU|0VX@qX4b^R2iL{oh
zPq{Wr-78fag=z}%cHtwk5Q&{!rW8X?J}G*#k8jfZIQ4gwBOFVJFRtvMfdiWX_<>97
z-KEyLC(;EWgXZ~UvM8J$h$%VdN^1jHdD4X?Qi0xA|MB9G>4-HNrh%FwRr_mQ%qK+T
z-S!|&{VHh_{g)bWFS0dSCB98f(&6vRcYu|E`PN3)$-^1{uDF$HFYR2q)ZT0ex}LO(
z1-Z@LAB`pF3ydv|^w=g54#7gH&~YG3du}f?YS4Yj-qy1!cEk;~MHM5(D32dpi)wUr
z?{^$K5T%s$QlXkNFbxxoSDF2qa`p>$pszw|XVowlR4|BNDmLZe|Hyjzl_eacTy_)G
zqC1F^MaAcjnd7JWefTKBZM1a6{tfo)!m?`oQw)>YWbtp&{QcP(RZGQs_H~qzUnOgH
zmZ5XSAI7o-bvpYluHKwqsn$@+r=rIV?XFPg%XbRyu?R(GfHzxBm(<Y<ax~*P4CRo*
z_>!Bi>Z{}sq+euj<a{4_#L`T%;Z-U*;OUhz-kI(>ry;}(aOL)%V2z!{I%-Aj%`HS$
z!aFnW2}bTqP1DxF|Ect7+8D|Go!=Q<irL!%nEEo(cWpu5P&NL_eBwS!{!(Z=`9YrV
z(vV*A(PtEw4lH1F!~5L0THS+7>X$RRmn#yp3lEb@p@;$hPMZ7rOQ%;N)$29*2w=eT
zm`v40AqpEg*I7`5#=n496J4pZLC?0E`#^RJ(G#U6R2xsi=;Wzi@1uvv`3B=|=SU+f
zBA9cFL0_zyu_t%$>yta<<N1s)Q3gNi_~#nN1%(2nqOGAwzJ|7g)LEg%j@X-mT69Ig
z2%+kmt#tv!f3T_AY*sw!(v#j$0qJZXJzmj<xGCDF$Z7d<?dz>ik%Z$a4Z775=g{R-
z$^=1}<SN1?U4kxw)D+axoB*xZSf$Xm^cNC`pxJ2wHWbqi+QIDa-q$Lh3ORg5xrVP}
z%^Oxk{Ue%pdLJYm1lW_xrh<{!H+w!TvTk9!Tpm-7iH9Up(DQG2toNa3h{s0SMw4SR
zV+$nyv-qsK4^+{V^meNLD*Uy+vfSES*$U!wPq{JeDyB_jvo+J#S{1Qp1ANNG^sJq@
z_$%Rk6bw<_Hm0@|RD^*}&F*SbdjOz5NJeP1=&g-djsd1dU}>*(y1FVLw6#Hx`PAR^
z=gtP#;cF=xVemxDzBu`c*e4q%TeNfY2|ZK8d*NheY8Z}+zwASwc>L3idS)+jn{R2Z
z#`rh)3_R<A*%}*KmhaweZN-^1jL%%93`j3j+6p5w`okY&L|g4(!$LGjnM`D1C-YJK
z)F~+d|1N1cJbhBh^kgjMBTlR+AN<lL-2HHf1$|f0J{=q%ab1I&nx|aM$uvUuja(_)
zD5!QY$`;zrw4(V)ymLMwqO`USfB!|ax75t<o=l;${non&@*GWnbGzEUBK5oI-mk0b
z-GvS+Sa6ykHke!&d>2;1HJ3V<WVA>dPH;eIfPJ~9+Vao2AJ2FyY#YS!Z=7d;wcu;(
zHmv3D4(c70nz41&hi?73Q-?3OF~*m9@hKalOP*}x(S?EjXb-B^&n(oW>mtE=KIRy9
zD9@HRyS?T^zyLs1UzC=6tpp}g5`zrmCE39p*d^m<-gtr75L##Gt%Pxaswea`ZQA(3
z2VGo~lU2CC#dJ0A!4i<s3SN*$o_<(A&l#0!R+*5KX?YH#a~lhNwqS2Ue$H*wxrT42
zuQ`0%D5CZ!S3!<U1)FRbg49m(=6eh}4Cy24j{qw?2`pjaoo)?v9dPHRbRAAAr9`Cv
zLN7Nf%OCW$?EMPu1fgF}DVNV)X5@m4>1Sy+*t_2OzP*c_Rd)+M$roVn60^?Up~2QG
zR!~%42D;E>W$x>=jQ^c)WL|F>B3F8E0A~sqRHT$pnQQY5C)+2MlJ_j1IGvoGU79^U
zmz+C2lRPoAGPiniDY<-NS?3vGReL8?>W}uE$cKY1`j-HNfQuo#ObAU>C~8~+*VQyJ
z(^b9iiJ-nvhnf~7*a`VEk?KNAd&$pJc0RDYwb5C|e08Bc!%Mw)T7QP~&vJFYmTi<(
z6Wru<pt;_`dz}3T%jU|EzeRK`$o7*(`>J-x!2H0;oY-Ti!^r8Z&|$x{C^D0OyZ%Zm
z>u1n%n9r3es13E3yDAq}A!+8vJ4&v~-cA*$=M-jwYUEPV8lRcEz}-HZTp8j=eX9ww
zT9p0?syOe{bbq+utaG}GSwYz}DrnR?b6dHFs&$Hqd|8H=4d}9D@MT}G>G<XkvVVW@
z9ABdoQM=TEM;;S?5Q%(8pN76mlPB;w8XLN1@V*_4uvrsM$NnD4j6Ew%(x}Ztbw|O>
zV=d|ZyYPLMFO!*y*T@&D)p891(w2+_nx9*0gUIkZiBdN|hvu&b);h~;_|-xS6>=q@
zQDbjB;^sk*BOqF?6||A-%W*H!`?#MJTdmnSc>;*D&8<L2cqbel%GW(q=Vmf>G@=O|
zOfU}rxW1362f3dyX3pP&&I^0O<DOu!2Nj+%pD`omr4|-ToVdf(p83Fxt)fI7Aa#{;
z-dkSpz$Q7~+T3hC2=*fwhgpZl_l&s?v7KM|T9NAz`vhaJgOUHek2-P*Ih{%_RWH};
zs(y2Vv~*Rk`{9yvJ+#bJ0k_hqKp+b3GJ`;sLDA12)-xJgHVQAjThp-j6R~o7#V<ro
z&-kN@A6NAj$55}e5e%{yKPD*5La!$rF%yG4(&tk^qEL?4n88VPxcH-Hzpqza*@0Ob
zm>8C->JG#S?zfS3H}13hojeJ20W>e<3tqLmvC<MC**o?A+)O$7gq;oO^~*uc!R}SD
z>6&W(*aOmvF2(fHi*BFmuAjEonL+<Sy-}+cvc9S<p=xCez(x&7X4Xa_nbEA_U&;U>
zJz9(AA>8jL^!?uWH}nD2-EeS_%ny?2UUQqZ^$`khT;T?(pyP%*R4kK2IG<zOGYu9G
zh^y437}(H9V!@#g%)iN}O9kwj;!oNsj7_kGgDYy+jGxjxr0Zt0gIqzrN5hc1Q0zgm
z>83xWYX(8n0X(+sF5~nDAKL-PMjp%P$D8jXU5F32givpQ{d4$3R#(s9*6XQUAyu!a
zqMv6##u&eG?-R67n>`v8z%tFPw=UrsbNX46L0wilRF^fhm>CRB{2n~FoCl{%ymQ^5
zb;OjiwOl%v(>#1u1SyHzk~BkNTzg_Se@x#`;+GlsS0*xNM2*5TiLH-Dl5XrX4JTc!
zijB4PUT*h236)aGVA?=g_I)nh+JbH7W2Pdku}m8%Yn>i5Lal94D?STf%syWKH0`eS
zt#<n|j4$9wQXB<!>o>kjc%+G_-=&#kb9N3h;aY;Z_lIU(pVz;xF)@fD0@1e~d5?Xv
z;VZ0Qh=RCZ@~4DfIRz4Qv$>5CNjk@;u+b%^Cw%R>IIzfGHvs_KT7ny{5nzRmjgEMq
zTZ4K6fQ*?2iljZ9aMhFJjE+c<f12bk8HgkJ4Ug*U9iE|WCO(gLG<1`s@@}-ij8An@
zegSKl1#MwKW2Gkzl@cHZjNIVLCiqZ#O+TgYeR{n=p2Wb&ICEZ%FBS2C12RZQOwRF7
zF^q6@IylJtd!MJA2kYqstk*06BcsY9u}z)c1veY}eD@n1UdCkGTHdecQ&QfPPqkLW
zu|z%>4T(Y^MlN3HIN!l2kW#jq%4cEJ2LK(WTwaHUByJ1X4j@~jlHOwbEE3PE`2YZ|
z)-jTsIbfl~H^0m|zhCn5C4qvjif+uOOp5ucC}@HH=%Fk>P-K#PmRn7{OYiyKWH8s_
zGx;EbmJ!f)%z4nqxcH-vJ*J{8F6_I+4TAY(Q|qz({c(*JQ0N4sGy}>&U0?r~^xian
zH<qt(uIZmS+sxF@r7KxrWuTY3--|OW6|qYLxDvre8>_S_d$H26P2npt=wfW4<Q{Dy
z1v-J+Fk`14{4Mv!(eZ=xzvJKT&@CGObi)LS4%Ql7u+MoklJkO{r5enF7~_p_KSVK;
zE!0!WqqTubW#KDx6`Xmm-uwN(R6ZE=h}sGlQzv$lg9OUpv|)$L{U%;d+fZy(fytoq
zdNr;oGU4WBYtJQ-_Vmm7QqFJq-U|Lfqs>+E4|Br!_k;L{`+bGJ-@~6KpH`Jb^VN8;
z1$1fPyrPTc{BQnyd;XcZbP-~)QBfAXiss^c=01}J=0#RfIlF8OpWr^H9p9kpr8C)b
z87_htob(5-%3o?-)oYwrzAN^??%k>`E*Z=>GTr;(5$k~dPTh+crvl|;?&;u7q-_Y(
z?al7`=~FmeFz0mYv;Fivs5f|gavZ24$KdAyVh2yDCT~2Z*XQ6b;y%Z?rp%G2821Dt
zxl&}1>`4MxD}wL$fB+ZcrJ=tkU+L)0)A>{Zz8GMOnv#5;nLX{vS4Hm&o!tC7rFVi^
z<1F5Z06f95hG%zwowmg$Ch9@=f*uv;nhGs5b0-c6CJ`_LdJp3*RkB%RrfaGc);d>;
z;FVYG+1{B)RZSH`G%7HF8xvC*K0E{N(U!f~m|7vzw=sOah`uF>fe@St_|*&T?R#76
zJHqCH+<U^U`LB9@I#(!`IM~jG)K>TF3$LcVz_!`@7Q06?Y2V9ds#(99QW$W<!Lg3Z
zsb)R9-*?@~9G_JCg@MbHf-jIw%RS$%_q!K`6(2w+HCH?9$i(CLnmPVfad4n;6%dYU
zU^jAUTF+g(Cy+}K%>`01Cw6}lf(dfzqxxR<eqZe|0NT}v<w?~l-<GHk$t$o&d!JJB
zXRW(~X$V`FJ3UDM%_~92M{l#c+y=TGtJembWk$%x_d|wQJaUI7E_MCYjt)y#%U&s8
z1ibR3)6@Yko&MsGuJbFEbY2ggW+aOWPO%cJqoumQ_#scc!QN{Uy}s2(u81n8Y+M|j
zlBTc3!`u^9`@L+!iy~24=>FYoZgqD6`7VQ=jMb>BcVK*=Qc3Oa8FQ|$5c^|(9yc2;
z9h>KMRxr9t&?!w1Y|Fj>-mkMp+m`VOBbIF$|8yg@n6-g!{)Ffg6mQ<Y(^<aEN`-(f
zl3|^YuH}mPG+a!Pfz%144n-J@E-%?RD7$||+tLmxY3^*Vo(4oIV<<fgLR;#rceWpd
z_rKEaA*(2bSVgsu5}Se;OrV`2=wU*&eLY+C8}h!9r;EnUGJSmTvR6>wl`EVG)z=%_
zYWE~#T{}UN5$7^-u;lw`cjZvg-^ebYgc|;`T+8Ukr=B0;kw!XK^E0}!q+dTaWPx65
z@q6~~i{)ea5%@hu#*ATw8U6@Y%WAKRomIw$xv<07-U@6JVx*cF)gQgW>c`|<I-5&j
z{71#R+U+2A;8`ry<OR$7Gbj$LKmk{By2mvWP>GE~lSqQp7Q65$TNqal3IR^aH|P12
zE6I>LT2+Jjt1tXE+Flzfyk_xA_Wo%6JcU`{_{??0#vK0?!}$|3&d#t+{@){eVzM!W
z84_h#GS@}TTZN+CW5Kd1moVTGqv*-p%x<tr*=9VL;^1yE6{4y(WvBRF8`~4`(&ESI
z|G{5{<z`a@L0t9l7a3P=>M?#>Z2(9?6s#h!jOid&5AOe&LtlCHP-8eo$!B0}qPhRH
z)*Dklru0U#SwS(?diz`t#w!Gq=oq&ggdds_!dt3;)9CIe-5fJ=zPVxnqf%;4NfWJ6
z(lnQJA>b3fJQKX6``(wxtIDUs3W2TQ{js}7zLyahoiE9R=ZUV7$WUB1ar1wX>ovu(
zU&gSbp1gNbuix(Pn^`^!dLFa`j?q658sB?|{@%^cYWWDnR@UfliYeA>FH6BO%5~4<
zVV-d_%!l1e&a*QA!aq1`ix@x&@U?pCvL%0|{<5;%3!bf0Zu}v607cW6Hc&L(U0s!M
z2y9Hm7n>_fk}3;oXzy@iBF8J)dL>^iHM~?0bxvk&dp|`vkiq!sD?M$tdq>Q7akbT8
z1EWLla&#z>%>{N5*A^WhKB#vOV<3qCO7>?xpsQUM;|_C38kuydfjDqLp49ym=oA2v
zrE;WblDbWm@-LO7^Kku->H9eNXrF%(+50xWsJ-2mm9ZDDzanHWRC3jNrk+ybl|q%P
zrih2HQTz8MtOb@N@yPc(vKjgPY_VR>H*{aBB=BSt`hW8z6c<d0a@9$tv`%nzNq;N+
z8wo+4i-x__;9*nDo=iQHSai41@4Hvi*rDoI9Wg&7qt)r4rd5ssWta7*^m%Xonv(+s
z6z#@VN6bgnRR@k4@TlVxbKv{9wjG+5RhkY06TPKP^dKVr2*f1hY`d3{vt)ChcTR=H
zo!jfRI<^<WJ>#(?d`;LWVlV{uvCo){hHl+NxTCnS+O;uH@3fKqDJdsYEg9j6h#;BY
zOO2rC*Garb=)LF0%#LULG-iB5<F>B!ydeHCH4a`ygtZ(Uff_0u#?9djx9YH%Vqc5Q
zy^*GFQ1co@E$EyRyxomUZQCpI!cZ(b3kaEd8R-|{SQa=yJp?(dgK8*;C8MU~%-t=W
zgqC%Fx4!<~4;o+lR`Bd27T590T{?;+*Fkvpc^JL;XL6!zXB-)LDvQeL3?@19*_F_w
zjXHnA!*>iFU3crRjyHf^R?e{e3J1MjKYQ{|+}MxeOq><Wfg-KV6<vgLo<_bjYWKqs
zkMpQOVKnYBt*?LZe#0jXH6eKT$U|Z6Sud&9CWyHp=4h~ml4&%xBSzFH5uGrfT4}Gg
zcGgkp5z5CduXnd#TdSetAJX@7_{VB3KqrF|3FGp>5$9;!6AWV_GkaNL?ZQVlzk@c>
z8F>9gAg|Eve{D*z>c!m&ui0tHFSBMds3Xc%0HK}Mz;?FQiwcybfwn%7gFGHG`}aDo
z8G1N|n51Jrbd=9duY*3D#K`ctiJpUvoJ6fx1-(be`j@=3YskW<Aw@2u{2E(t>#|ir
zw#XMK1P|x<uzrrliyWQBdZ-~Y74`E(_{amrYM7zMJ;5+4P{~n|rLrbBzf5>Rhndtk
zPPd&c$je*^$<k^KJqf9znvS7DSy&u%&YyAh(TPl^3=~7Z>MeD<EawYs<Qs2v`~&!>
zX#m8eY6WE^Tl%4;JUp$Sknm})S<jFb-TbVr)tD|zjOq$1i@F$EuY5q^gGMu;$;f4o
z5M$B%7AdeT9U6bFF%f?);;zOKu8zNE<o}zo7zXnwJjKc8kl)PNH<fnlYTHN9p#wiZ
zi1w`--gtqE0~`|#dbPFL5p)E2rlDB`s!&cKN1<a(pqUvkcNjr|)yZ-Y|4?|-uhG}J
zo~Hc5RW#O9bej0Wy+OW4<z!6!b1JE@fB-Lpu;&6M@bu-N^c>a4^!4_}!UBrFKSzYV
zv25d?VkE==h<=8{Tg0osg<Fae%7IEZI&|ty<h>a4(4P&`GZ=#&_;?2&?DM-XfS3oi
zFGW1V0G=IcS)0v>f4Y(MVRAqFU!!?f?H<dGR}eG-Du(Wd)<|xt3uTy9dUlI6Q1i6_
zLniqFtWk-T($4s=<kJy;<LEFfJx3LWwf5jkdB0+xN%y4`M6ID<W(NXC%MoO9n>F0u
zxk9nFa5h!*v(2VQ%(xBQpXk7+e$&xI2vGTDbXn!fss@}|#A+5g4vfq2J@z%y{IOB`
zsD6|t)MJ1-d;Q7rup&=QjHD*#Ne`)23GgCwdVLEI+4W5#7FNh-%C$7|95H8w$UX@j
z9elZ}w;Gt2JZJQXj*PFtfk$e31w(ws8Bk?nP`lHP&5Jh7l;5c48;UGwkEkg;!~^A@
zX!`g`L-UU?mogH!XLMY43?(pB;@bM>eQSeHMpA{XrpZYsYdQs(Z&TgA`sZs=%rUOL
zd_)6}dxDYj^>IxX)8o%`h))1`j1e3j|6GHf$QkTl_~avB6ylR&5wl!M8Wn)U9Gvd&
zixPcFd4c|%+UVQQov8gBpQJ`F#RQcnWRuv?BBS=+%Ggx<8j^D8J?m}|yFlTCy-XkT
zVKWc5p$cWBxE)^&athOj?D@a4v<1zJoI*{1ulI85I>?kAsa!jXv04Zm5V)&RpsETu
z-NaHFKW<_vbvUnrUs5|#hUEqwsYZ3P^QZJZHD0WIr(+g{ktryYob+0oTVnQacbiK)
ztE-ZUDj!QmDl^S)5!4y&Xbs}m*e4i7-An)hl)EO;4@2M2cQHhu2LPQ4P<s_jQ-MS#
z0jLL<$jW;`+_$%<;)=ZombpT!fa8(94%YAWT)!Co($7{N2sckR&ztUPTO;!X>0PM&
zOgkkBJUsv1hNi!n{GwvHsKVTUPl=@8L(;Z+1(<w@!gn^1a5H;xSGd-yfK*>5S8xiH
zX`87Kr!U)5@PhA7zbY)Js@X;*+fV`Fetd791~W0Q;yz`+-ubOIW;lZuuzUtF_IyQE
ziqjM%C0L`7Q4!|pXdcoiWJ=o9Z)9qunxn7{tOYQ(X`yFrCz<D!D^#kO{RH+$zEplh
z<p`ZR5t~<3*JUt;Q989y%wKJIK}=@xEzWbI$Gcj`kd(Y8_6f#h%<~<Vo##u}(1?Q>
zVvV{672(p^=%S77@I9L5d<?ELAC-^BPi-zw0+1im^p;#4WP5wZlEXmRV~dt&R5l^U
zPSF(PB9fP5)kbCG^{U5y$UxD!`3mLSLxi$Q%J!A?zV=A0bQ8r1TgdT6Df@A4FD&?A
zD|+0M4O0vT14wc#qU&$GN7dmV{JX8NK!H|@B0yb;W0Oay4m0$A{hGsHsBfv2O66=t
z1yV`26k3+htHR@yC1gH+N^^?uQQXk=u+=U|gyWxyc_&;fl5EkdWoo5rs#I1n@1;R8
z?~N|P;4HSl*=mM&o_?J=yBS}nW$K~ttVOyEoSRC<_cKbSaxo~#_@rcWzQ?*MJ}y7y
zvhbyngt%X$E1pDTJIGm7F?tokEUzkinB#ZcH+YUTOM~y;@!arti}nAHyLW+-EHCQ>
z14IRNG-W+)PlK314YnNZjjUH!Gtzk@ZoHqD%6fH)MrLJ3Rwb305oBc6qernsX2wBf
z)5qbkE@H_l+lz=PDk8F)!+6*}sBNx}i0EM1Dzdn;d61dG_x`@${~3|@Mn+Uex3G1(
zGczJ?-1~og|L^hpUOA))d+ngT_yfih!0~U^{N5M3d8NZrfU@UNEu`UC%(PMG<v{+Q
zPGOhKKh(d$_BmhY1<x<(NylZC(rW7kM}L*X*JAXr^5j@ug1s@WLO1N#Sv*1XR#}^=
zi%w>wvn3R8&lFLHOq76J9l__9;a;CTAt?p3C$`qFu6M3O>cROb-!-`7_DS&t%nD$@
zvgpf58xh24y|*g5^CfJ<`Q!d)YbZqwO{CR>POGzvf`LoW0u6Uqlu~8PJ_5>wpj>G`
z{*-T&K7TxogyD;+2Xv3J?f+ZzeaV-Grj5x;n78Pd!MI(?#@(z@81CqjWC)TZ3|BHG
z4`uJ8KP?U-iFK)`XV?x+f>CrdJqyn{Gbc8{>Ysfn2ilU^__zHZBnCU1x4w|G=liqi
zAh(&cLYJxiUg~d|FE#rJ@+MJuUW`N)(8<e@ftNKQDav1Le9Qaaq<t&-#oktb9E<j<
zI6l4GA19x$<jW1TAfb*+=C3??w69Fy#sgX=-6}ICT^-^aPWo#5T6?v|5L2;c&vejt
zFz4bIQvX)?>8#3=P{c5p`*n8}&!8r|0-}8d&$ysQ|J*s;-(d{B7@~eE&Vtczm&}Zv
z|HJ4r`!}7en?X&$T)C1d6$;9SOR-E{hPpXz4=2cpm{W{WRd>1!#k>k}q=h4l+r(RL
zpVQdLX6L$KBZdwF-;VU;WWN>Z?$iCO*qz|ltexcPXMgF<CtJ@TGcF1<&5WuT%8~I0
zN9)uyzBi6N@)Dy{DZEJh7X3*i-kej`epc4AS&KVAF0_o&kc+*pBwKt$-*f+~lXL;t
zIFrI(o&mvcj2)xTJ?_^>1`bn>a=8dKWQ9n$_EZg>#oGhnNKAt0>hpi?=}}0AIfJ4E
z1xZ@l%tIr0*m&>(;xRgf4YxjkkdJFoB-w*8_+vcSm2?~h9Vei7&g}am<Za2d94m)r
zI;cQ>cAihAKB4bB^*2fMG=^?@S6nULu`mfv=Cw7mx#QbkO&U>kvr%kB>UkL2o9f4o
z>TqAdlu{+b2C*a3;^iRq8mynt)?<F%RK%OrYGF2CDJqu2i^(V{+Q=gv346%-z%{&@
z#?L~4XBfG=SM%iIa#vKB<yADOKsY0F3S>Nnch3i&jT0jOsD|v2X2~-~2O8~>cavH3
z!DQeZKiMByIsbA7Dg%D5>2;Vo?L99i_Fl76FY4+7<fYEk<88SPTwQ)(k+Zs-cnP-V
zZ$elU7fxBA5oP9?`T>upmrz%|p2<|p$PkdPb0$ta(I(`5I3R8ZUn+a=sC;FB_j9Nc
zXC(Fsae=Q@x|YtK6g+%G3~huIOCuBONWVbuIXvf4J~xM7qCpuS!SuezuaLuSa8qNy
z?ET6paR+yyj`kn9ac_{ss{~gkd~#9K!u|)H4JY|iQ6rnHHL~hVIIxuD#Fr#H?ujCL
z*$Agg@C?|q+OJPm@}+ti&BvTR$z4?#G4~SR7C9kj<JEojrI3BpXhzLiuz+mlKt6wy
z-s8Q0L%)@7;ek9GWI~&YXvyY^VS+KdKS8w{0<=-De7_z~G*V5g7|xj>bK>kI!S|@~
zv!+$-y~e6(W%g^jzt3tVpD#uAvdZ<~-t%~>{Zg+38<+ULd)?ViKU6MMvc(Kkf)?1_
z5@OTHf1a<`XsRW;BdV2LUrY%GMStD$VKD{Tc1II}abgHWzY}_S?B8mhclwyERG=yp
zp0YXM7oN`=2)d?WZw@w=B=kz1b158$X~=94k*>QZbh?rr(F=lyP}01bvA)MQ8o%P%
zUV9^_;+U27<1oDLp%`8QA<E|C6vN12y10=y`=9mr6!fYKb5aMr&|cU?xOA_+(7WpT
z7)<>Qbt`Zfsmh7+8@g;joR(!yN(_}H4Df)SHU2FQ<zC8ukbRx{N};<}>&9m5QF(3m
z8$@MdD6t%&sy$j~{W+uar+!)C#;nhwYLi3x-vq#<<hb1LmUkcVoV{wRy>U}gMnq-R
zxz!JA8ovFI@#8Xg<P0&ObxC!jQ#S~FC$5T!r?GCvGyU7%cwiYzXU+AFIIdmXed-^G
z1DuVGlAO()ouhV9Bf79Ez}T72)wa+mo^(>5h3JTPR?*+D6c(%HVl{x5dsT21Ny%E+
z+61RZq8!%Xb!L8V^m%R9^Bu$rs~F}wCX>@Z|J(HQ=kF@tV_Z8Smea>VQ;1?^y(pvK
z-1$~dmWIusP-s+}m8NnMQouQ#jlz>JDFmI}N+rh$RHu$n@9fK&z4Pnd^NPsP4MVi4
zDX8a7P@gjM>%Pl-9`w|xSgVyo?INs+BH&bK`UHsX^F8N4$jfz{Ge6}pBYBTA<^1l^
z`~5D)IG<VV70_@IbohjRe`ll|s`1$lI9Gx-J^sB$U}3arME2eKHnA0EXHOYnZyNfr
zf=ypfpR~!LF}i&8=l-6+uLQ|}y0TuLHq~Mh6j#`(*xZw&vh+rw4-wHfsL;Euq6{~@
zE*&U&!<tWn@#X6%#ooCd6K0;Wy>O>L=8YThPA!{3i_@lOi@725=#czT-W~d@{7}li
z&LQOs+9yr<jD*FnvlP6Q%k%G2zJ?is$17ms&?H2cf(B>w&bK0?+4!o`C#&^*B@Bz`
zF?ShdQY0Wi)?M~2_&9l?sU>Y&#Kq-W#dAIBb9+JRj+Ou*ND=U1ZIx}E+U~oPFaTgm
z$Onp(;p1|^QTz&{Gxwo>1$xmNSW_%%YNzPgrP+LtEmd;hp<cb90a_+)lAuW<<R!?p
z+|c(c{fS3o$UhFDG!@HbWpC1GCZ$l7<qz^+o)Sl6y!}DjH!Sd|oRFU|Io(<Qzl;u`
zB=IN-q#x8YwfB=FVqP)ISUim-bF@hrlm`5Ik)Ffu$HeA_+TY&Xg7ym~=?Z!^rBbig
zpYQZI$AzV93+QqtcnBi%#B<h@hD@<~#K^OamE1Pd!Qn04Kk(?HTn%dZY#nX`+NEP5
zEqzSLW0XP^;Fc9lhj)J7dtMgUe4|th>op~(DISTMT$8WyC3zhQ@0g)4L({3M<4-e)
zkuTM26{O_H4qn;RatEhR^bMKM;Z+LXO3SrM7%YOOAJuy{<?^x)H>qQGE5T5R-7XVq
zY~~xC@aBu8;d&`TpSh|E78}^CL*)eZEhinwFSsB83Gwf=-mmmE_sle6ymG}#9d#ol
z;5;l`K{0Z%1(An1kfgYRPvna77RnRfM8Orgr_ouqQ-iTLx>TDgFE}B#9eaKz#Hy7)
z^3$3oqOavSo}Ea%>Bu8|#w61P6MOoAp^0C0XE=STTt&mROa<CjLyV<zBWG--tiJvZ
zihfx=0zHml2Nd#UH2(4XZtJ+?GrDgf%t<ON)>rZ`h+nR@*Dr5g38c({>PjdjXvE=Q
zaGS^a>$~I-T2v^O6(+858lG$VZ7H_OLF$qo=VPCA<D5bL{Zc*3*J};MPk5k)+boPL
zCwt*_e5r(|!iGdw+W)ljU8~NDzS|lC`COVgK(cOfZTb&2W;=Tt9~!Af=oT%>`&+LY
z4GKJi@l1wi?7YXD6U?Df2^GaNx(Mh1gH>pj;{@upb6}CHt2fChs3LG(wgL>-`n7iU
zMIUUf^p;jGqe&j~walpHx_9XL?f>aWae`=CI$E`$r^s$ysGt<<!apOkKIhkRN299}
zn!XjJzpK<u-)y4=AUNRc3Biz77E$MTVRHfX*xPHD+HBb!$i3dK=REZW@(LgtgAp>r
zLQ0Iy6~i3H5hzKPyROsl5`7L<U+VGvV-YHMpdoo9SnOh(3wj>Y&lB8o)+9H1EkLX*
zLHd3mIo71(;ZMoLlXtMXavxcjz1KVXOhbkvbQ<0sC?F%|VVSd%npZq{hCz?m8MbL(
z3QYQedf5^f=}M=!*;h;Oje1VIcX*GUsv)Y(U)<?%IsX*5#Z${tU#5FR-#M@512yD;
zx7Sd^==45RR*ZkUB!iv`i>_RQvNf@lHZ&UFIzPn9(@f0p^w0IjJ=UuAV!c+4_nj1l
zy=MdKPuzRAqh;{)I_j?GtNCozD~d-JO*TezXFxyXOX{RlLdn_r4NrjzTz}u`|Dbqw
z+ST!bZa2_?lk0?9!e?8(mX{x%M}*$Z063Zy563?v`*#08*%1s1l&oa2CXh;_%?az{
zoBugJ8@#2yaCv31v9)&a(Q}!yey}O9NjTK%w|82GC$CF!5uGIiUe0dI?e)&q<ttLX
zO`VQSp?s4_6I1zLCW?rO>X5z0R6nH8-_Fz6cd=g^oE*vf{TB=#a{FhM|K`XVDh|VI
z(z=A6)R5q3OXnLoN%X}LQB79NFNqgXfLC(0fx&Oj;4X?#PU`iW`j1*)P`4WN@dg!P
z#T7Vqbu7h)&AMMDuTgDDlKWkbYbHPa2Di8PVsp!xk$=xiwOT6neFgDL?CWjgDdxY6
zv0A-#?YHXTdZR0KD;}>vEtYx-y=%+B#Du4eYhMl6la9&IEo}AGsNXLfRjLJao{r~j
zuaR-A1*v7dZ+ov1+;R4h9QL!T2>rb_f}fD7?B;5*aIC#HQhuvBQ=<#RWC9ugUP&Se
zoJTqNvCqO!g+9LjVQ-(0g+){#jkIfbb|&y*)_$uG*97P}a*w>2MKJoia+@ll9t6p2
zFfLL#d<DcPFgW>b;Bv+un?bpxX0uu@RGTV^oJzd`!To3!+66AW#@RUoCxeu3p%pAA
z&mMlIqRaAJxQ}%x>LT6~ol|U`?LTMEovEz}e;PAASXT21trG>$(|9i<R<13y(5K-G
zG9cRcHvB{-L#UAdF@p3FM)H241%9Wc8w!t~{6QO56dSYW7a1FHer2g0q9**AP8~JQ
zR<b~gaLu|ttK0wD!@-f81pA<pFNU7_Hb9q7hogcPN1R?Lm~d2}<Sxc3xG8=S)f#VE
z6|7xA$eoS#O}|b2Q>@p7hz&QFPt!jK?>gM-DD<JUzx<8!xWwYUd$03-#{Ka*Pgy^S
zqZ-e!FuL^P1G%dCa<)<dWI)j(Kh()3K0*%|a)<;AlruX0EtEIFxe(raWkabk2)&SR
ztH=A=3zS6Du!8yyE@ZtV)jZDl&Zd9G_y|r*Yqb>?X`e&c%l`O$KU#p`o1u@rw|l${
z^bzHX*=C`s0`)l;3SuH1&PBoxyg0@I4=s5c86k;FB(~8J=6~ON9$Hp5km`$8+A2PA
zfY@kL@W}%<h2Ug%t?5sp$Cw5N2dVH<!P~g*De5dS`N(MQw9s8?ZC*i2QIBIJFI}bn
zd6-@>RuGX=4*ahu4Ajuo&I`SB3e_pss8zF(+6ET~slX$KEv~3K$Z|fq(@q|zqoA3~
z<r_JMU=}l%+v{ym#q2{2#&`%j;o@J@FX?+`SS!}@1;nz-(vl631E^=J*8zL($UPqO
zeZ^V$@53n5C>E3BOdat!B#;xKE7<a@+wXI8nJHBRxY&wKRZdKMYn>+OSe28RBbu95
ze|+xq`qlu=iIJzGAxn}TAEMUaRkARdAoX!gS9@QTfWs$t05*DAylEfDf}SDdLCG1g
z9FZ?_Ze)*xKAgH)2y=+ws|M=}*vqht1_>IdHoPQt-9OuzpxO+>Y)vyqx9emm&in3I
z3+bF&$@lnj;Ju9i<9fMX|MWjl=UG{2MIH|i^uSWXclICm#)cgD5P`}C6cUgvB^i>|
z9mnB&N|z%qmt@13YaPoWIL?q0OIsg>wr2H2l%_0|qp+;o^zw_GoT4rAvz)>QW$kZ)
zubc0t!zief%T1(2jtcA9^Ax<<J5O2oze~kh*lcDMD9^>7$bm9g%l?<qhF<A4I%o3m
zP9j}PutMczz`Tsjoc@nIJB*%S*x<0#yU#moK=E$lr{3Qaou;+Sf@O%Zlelo%!w(wy
zv#Io!b%||Bsw!((L(E(gAZoCNc&%sjTMV;#RApH?+aeQpoZt2-KQxZd5z@o58r^mW
z`Ss%aUtPVnh6wx3Zbxc{v^HjDT%YATk3A#tD+zI2leI5(2?*ADmi0z48O(ncTa3CX
zLGDQUxQZ}-Bttatk@WE+N5ZVq1si&gcHc?8MY<tKog(oY1Lf>pwd!SWWeu4M3n*ux
z>*yUxBgzL_X6a0;wT4!FD+Dv2(D#e}*SlWd7y*}PzxUJAxG32$64uFPM#tLk*RhKA
zsM)AAC<4gosiG)$OaUZbIU{Rs4dBve5ZiiupsSL>&~9P-qz~f4r4CX6FSV~MTwCcN
zZpFySDL*y|HF66GanILvFEeV)POLnY+!Z7Hf{!{`GJ`fKc@(`Xmb6nhPUjww&=!mk
z0mv80@o|PH?)(~cZWYt!$>aMBKgkNMN+djLYpC`cE<gE)jZM=)#PVXhyE)vL5uSl1
zPkr>O7;`_{I-N#UeX*sKk2^S(O1)7(H~0W~@u4;Ro+44kvA8m%Afu4Y8ti`$ZRIPd
zh=kIXP^*?x>~|sOfB%K_53(*8I*>`8Hp&;o6$lexTs@9y1#Q(`(!n6`t;UrNOZXat
zknwzjb$#-eJ=y`TS_-4cKwVCI;BleyG@z3^sDPJ{unagh7$F+qvG$CdLI$VNe`Zi$
zvRDbLVKpD}wDQ5BP@{WXPF_-pV^{+J;-?v_wo#|!*Z3DKC>Mj-{cG)W@bZk8H#%#;
z$k4hWIC3QW$P8j4vw?W64_0ZzYUVBQ6u06RpkdoPc-U}sKk3owK})!QqQ`P{$)1dh
zj<0A8XR-ad(489&|MB1-%5~Xa`RDu#tDW`BuUXUWIINFh@9n(D#=;8HNx%SbEUaD-
zy;{Wzx7IGT&>{<zeWPXSuRWm8`0eLXA5-@JTzfOWer;u=v%c0|N6%DMxjG}`FnlBB
z+d0RYl@gLUk;#dmUe~WK{Y#_qjbvx{*!n^|57BV^J$kO`pBB0W@`EA?>zI>yKk)dk
z%+<)i=@<3cB)Mv-UTsvAi-tl_F?-rPe2w5e`L6J!={G6=*eP3Y!Z~TJEF9>SYUJmg
zzgPQ4AME17y7*vQH^61VodCgz8_C8rJoXD7&p{k=8CB`)#k|56I4Bn>q{KCarXG1<
z_w{q%qvv}1Sl8>i1!>^r<ou)etP@eLQ9#7If<UZAXZ)+dkI>JjBhuHmRwai^M{6HA
zvg7J82ekQdZ;*6KS=^Jod5nJY_)(>w$QCTGEgVBRzDxd^>^)2CFH*rk^Fz~*MS^qW
zT0>87`Fh8v)6hq2#d26IAWi_y7my7$dm>y#IPUBTW-+N&8&GW(J?-9IkD!Shq^Gw-
zP>Q*TvQCd<Wvv`TJ**PqgNu;{0h|D(K%xNUd+uedn<#MSd_JTeB`VZ<2hTIQMK@G6
z7~v~gU6i^SIAO-`x&NSiHl!D9oIY`AnE|cbU<^ig*!_NQ?r0WKX_hP5Ivm3ykvUIw
z#H=7!XtBI>fG<^HzD&{^<a#FZzEjiH-fa_uaYNN^f}d+kxIaSvAkpFYT3ta1llW8Q
ze+=hPu066nW0e5kH)SK^_&9;sY)<%B{JhwC1AY&9J$}f{<w^1!9aD8kU*@MpY1IM;
zV>b57?)Ulonh#Lhr-nRlZYyb+$`?12KlqZy6*v8wY#5m})j=w0&fwuzL-69?QN0Ft
zKI6#_EY;l29-;=N+DF8^!FHx69sJ~t)WiBa^V^EXkIZH-=sodb?2roy?%mx)aV>>T
zVPjN}z|;Esw?Cs~9eUa*IXqZVNVf9OGokW<vbd+r=dl;KbxUV!K?9v(OQlG3+F}MO
z%I4O>D#9OEdI*SIYzx664054Mu4&eO=audrGo><o&r!Kh0HA444cC*}wmUjXG#-;{
zX8Dt=%)R1A{L8cYRPH?Oke}t+tDN{vSQwJ(l)qt7E+Yr_?(5epGEpH{gc2o><X|`~
zC9Mg2KB}G}>vF^9Qy(A5r#_ht@cBi(e$%tw+!4EzEjCM;QdQXmP6coz$Y)Yv;E&nk
zG8#Ue3|2f3CZ^$i|I*z%eH5+Mveilr!+&U2`AiH?yWg*+3V#{e`&Mds9Zbiy<kGq)
zbMhSAQ2r$&V>W>rnY^T5)$IH9wx_26GpI({B8ucrysyqVv(_*5_7nb{S_Pe<BE6xU
zr?;VuYT!iG26G39@be;BXQP+SQ(uKRQtGNbuiO8qd3LwmzA7wQViO9n-1L!5!SPYE
zf2)4K(BomFR!7TMh@7o;<qI_Xx6@bK3jW7R6qRziZU}i4Nrk8gxs}^fPLR8+sEPSn
zaDmXx+h4haHxl^B)-(uw`l_MMQ7x>MOJXx3rJjD<z^>8GG1@OH5Zf(LjLq8J+9sy5
zyt>u9g6Ixg!*kl<ehUaWY`+$KL^7bX0U@BDhxg?L@SDvz#P5u0rY37CXMV@8Qv!aQ
zgOXnG>MEVo*L6)jI2JNt3VRLR`nIId!C607T~~*Dv;N-pH|jXM*)*(T*U85V<<#bc
ze4IvVG;vCZY3a^5?D}&vM~?*xC?%kL$nA9xIYS$_U+0}M)D~&fGY!PBDd#?Enk2x#
z9I!!tG8(D4^3XyWwiZ+R`zYfPBO0rRAX=x}ZKE8dB)K6Ltq0`=vH=?$d-)}(-N8h3
zWUL+lD+C{$b;T$}{|~Su=a0Mh1iX;<a_5iZR3pEng+ivPPcafUU2e&hXL&rO9u%W6
zTg{<ttuQ;TCs~GKAsKlS87yL>3r$WvuKWS8`8Pz9vw{MjiG1ZXAJdq*tk?Qd;6s4g
z6D3nZX`ZbA5%n?iob(y$&6nY+F^^KP8lLl``Z>`bkECBB?MK*izfyJ==u0vVfZ6D>
z%vM+0`xNZ~g?#`wlxpkRU<F6LhI%%uON(ggD161(1KY0`89zIFWcIYt{QHU>YA$S0
z-1x+q_-}G;1p~n2Qd9W<OHwAb^v3e#ma471BC%?%WvF8gZ|`y*vtW(gOB+{pQKcLX
zHU8Ib537%+@A&5yd5rl=Gb+`TPQ)Wim6Lx_C!&nyOG+-jBv0ot=6fVX$LxCn#%^Ts
z=Q`f=Lgbqla-~e4T|=S4JMtF1EniX|@`nQ``KeQs$xkS>9?<l5`$rV*_rxAwT1AU-
z^j%w6mfEl$TDh3|u#WRfKTG><d|3*Sd6zY0V?f75U(N(M($HLQsUaJ8E}lx9-#_0x
zy*NLk*@*1}l1uHs*U_5f<cDPx7Y{3y0CL%{cPR8}?4=)JEM3{QT^MNUmsww$>#nSa
zovrmvtAE}4P3^bWkQSQ0N^!HkMaE%-9jpu{T~5VfgTZGM?=7)9vZ)^{vSY5liVWV;
zX?hl?drlwzTB|m~a<!6`gvh|osrxe=-}!~rt67XJ@GISFrY-@J>~JdboVLqnM#A(n
zPZ`sfJAl(!y$CUa;HQuw7Y}Q`LJg#1_WIl0UQ0jLTBDRl3b4XUW>1Plq;JFVFr|nd
zlTT((2npEz*#A3){}6BWxWvI=8RdQg>$P=P=YLAeT3Z9Zw+dCXi-Z}?vDZ6YTyJFN
z?r(Z{JLppFxOhm<Tb_9XeQ7NYCiN4-VkxRNl=qd)k8Iaj7G#`ck^>$}vP)jazdYn1
zz?h6Zu<h&HNN%qoM4g&kn3c<{Uf%7)e=E60IRqq5m4pI9kO;$v(+|)uxzv$eZLY80
zjMZ|Ty&B}4O)2&8!X}~sOIqRK;9V&jCnsoz^8+pmU-DDNJ{cKw`(@sGq5yumjtXn#
zj8dlfMYk|d#fN;4K1;zPq$ep%yRZr6;luj<Tkm5Wj{@=;$YUzz9YDm#SAEV+Kzlkw
zj0i2r{>ty?u6gJ0LFs2#4K*!P<cN_VfHcZ^75*Z<Zq+%LTrjENRbF3O0VK64wBJu0
zegLkpKq|(#htZ90^!4Jc7K>pcU+`38Q3wpSJO2yR@kB>OJq*IWmhSia=)O|THY<&W
z+z0jy9%pGe_zT6a(>6p4Sk-xzRXqo<%vO(~AgSl;xpx1NXIwG|+&#Wu*>P#BjC-b+
zsA;OTtMwJkzr>^2dXTN6<5IDyAPlE5DgB?wFg&z|-fw-ccb1A_Pz!UlOg67{yb02~
zJdb-@qE5WgUTup#WsK=T6wqkB9ceDF9r-kof)TJmK^%?Dxcx@GmcC%44J+w}CfD#d
z`UNNty*Yn-f3NW2aq92IC_4W<A!b^M5IG{W`L4cR_2p)vT!ljpT}^<b7+g2_l9(Kp
zM4SkkfmWytAG`Pt`j!!^w;^t2dzORWQ|IBxZ2Ab=1aw{Wh}nc(>Fn$gqs%O~=Rg^7
ztZV?Am{CW?()qoRbXL~Y5pILP&78`(ATUHpr^vh^d__*C;XykuQ@%IW!ZN<MgEg?M
zk7c^<Jqs`}f+P@$omarCG9}~@JYJL{PArg}x%V7Op9EB5n6$O=D|O>bz2_n<B%jOH
zN;+<u5968SBh*aiWEgq5h0T@Sel=-V`o<^3*cp)#<9<n?*gl2TB#ChgRh+_`^!X0{
zUv0w!b%9<hN1}(U358mW<PwTGMe$})?2x2Yw?yw5o_^;&I&MNLgKn)OF=5H#dsBa;
z^w`tivbwN#X=$Ogbn3)I#}<x0xHPk{aB4Aq^iuoSiN#YV7iJz@I(GE<;_-)d$ZZ)+
zxOHBPW-<*!W2gG$T&)l_%cYz`xiYd#$}QvY`P7!|wIG!Xt3i6;ANJG8unXVd`HlN3
z-?vn=L|pp{eb!Gs*P|cgJ5;O1LKQW6<oTo;4_>D5#UT;iEcBCZdvY4GpqQ=aAPdwC
zCMXNcSU>02Ttd2Erd%(hp&7@@1I<I!?^iH&2-1%z8c$CuswdgPHispKFp~~Tf^x+3
zB3g>*UpyOHnOj&|=mK_-1opeAL-1HXU#wRv)p9jdjFC&|WfYweLO`ECgGoR69^ucY
zH_-;9b9Jk06t29a{0mLIL!axZ&lx|0=~UUii~(0Ml|^&Vg}0-n58#ttXKP~-J*Lmw
zGpfoZ5^py6f~lZ5EDQgz+oyw)itsh@k=-Yhjm3Jg%cx0-${I2c(Ff%BjbCy!o`(Mg
z1edF4k<<hG>R>(Iz@EYRK0UGsqo*F#z0A~Jkg_>Ew+4JXVYykXmLerP$i%%v$k*fy
zik~|Sjaw%U_zg4mjCZ!-_pj!g#cZMGHFcm6a)t29ve`UIS@~-adz1H!Oj21G>XjHo
z#@<UKX2q+~tFj2iD=fAe{OQ;9*rtEOt?LXF<65&&Dwhh%he)NfE{~%ybmG%Ko$|Wh
z*F!@tlrNo@A0*tI{FTM<Y&_@QA1gg=<k~1>hyNIIJs5Z(lF#z!7dt&VeXNN#kYSx!
zTcyVADUBf*Jbh1LLfx%Ph(49WBj}I+82uLWI|N^Bt#nY#B9I!GCe{e$h9wpn$YmB^
zze-OL-m?4lu9te_IhoHEt4O9U;weCzPX*5R6)3$;Y@X$AZ^O!hVBXu$9BR&2iglO<
zYCjWgY!Wl+mK07Hg;IyogI}YPMvp9m5sZ%dLf_ALEJXSuN}<#dA&NN(jfw4$dV$8B
z))ub9V>5*99655vE~sHM2wgseSEXgaB^&gNpia)F+xxyD_84(DXsY<e+w?f2caG%8
z5Dl7I^aQMNpL&dTb|5;&tmCZ{q7%)E?dAHp^{%WeBdC65vj=n4|G;)?6D)$}YfPiI
z0~bjTwzRGn^E$mQ>CfnOIduQ9Ecow$_>cy1BW@x@t-1sD<(z(g*UuB~-fZ<u_BZyB
z*&lj0)MENM!#O5%Xsd@;3&3c2<YS1BhaT6>iN|?s5nXa5wjQvBDlBU8yr~xp9ZA{E
zRu?sF=$$br;m7qDw|{y3+z_LnjIPaN5hrIEBq%$A9-FR2snn;<{9d8-wvlTR0<VQa
zcmVVo*AbgM<8kkl6c0+Y+>|7wTo9ghOV=}Q6&Z@|3L1mfR3@0ixA%UKwzAL%Jgurf
zA*!^BcZ#kl$<<m!A*MMUQzf!To-y^6<WI^+?3>u82qCU9wEF$NTsV#rBS-^AJdOm6
z2e{1Q0jYm7`kogzBJx8<(_bp&kqiPa5$;ExY54i}kBI!xd}QNtYgGp@_|MqCD%jU7
zEX7CL8y$OZ!>|ul)>drR>ZGYp=`o7*8gQFm0MSfTrH`9=Y~4E53{e`?JYi`5>_9F;
zH;$ssDIVR-08LMHibD@FbPw5Ep|{{2j9pX0V_^wx$2;I<NFr=6Tf2LEir26|6nczy
zui$(4=<lb#QREMzaNzxD!$D$f^$phDKw`n%=8}qlce-!-2~QuXR)b=>n91krDx!Qq
z?O-4YRcdOyR6BUdi1iIFnQ;b`lfE$AT32$?$veb)+ZLt=8<^Vb>^0|)lZwq+-l}_R
ziS+>7iPc2z78cCd<#%R1y&pb_e7=&)XSAU_LA(56GjE(+oJ*XlbC=F6TtWosXt4X=
z>hJHIO}5R)Rlh;w{ed3i-XMux_uJwzqBCbq@f<jNQr&mKfXMg^ZoK_f1803P?yQeH
zi9@AV?D*qYR?>1PX|1q4(>M3_<oo8vFt>PcZzyk@q{tSmTr`YiPCE9};?{kLsQ7{l
z9~tbMYh?bf`!?Ls9H8qc0|Y?A&8%LLe!lXb6NeYM-PwRjffh)TsF~Q2!s$p;KdfxA
zrp=Y=ckB$LN!c2X+rLDfG}&I26Qr30*(+R%eJhXZ7^K~2Yn?}8JT;IQbND^e$;U0U
zp(EuThZZ`;b>wWrj)l=zMt{21@cbc(l`0jR$mj(LX~kip;|{z}7Y(4aco>!oy9It#
z&@wBSRW@<!1gu*y!+smsZ)k4JU|y7lvCQJw@74F&{x&81;Co53Sz_jx$OE57*{68@
zvL5%;e<!xG1T`JH_*SnaXH%w%G(u+T-c@!k>;n9k$D@ocJbijVK6c{dqoJ)BagjjT
z$r5t>dyOI^#fKrf@b0S_GoW-~Wfxs)Uq&3E)Za!=v5lL$4y{Z@moPc4zZ=~nypTAI
zSXH!QHad$fsMH8v?*&q*8W4&pRE<AzD9@J4jkz<KMwpk1tr87D{o|y*=j}T8QL6DS
ztlw;PmirE!4=lDCQf~D%=6nCu=zQk!^4%o&JT|p;egsdv+J9aR8u(THtn^5|q3%LQ
zdU{TaRgFv>VCtVJ!w!agt#`z}$2Oy|%GSm@$b&YM{C;bn55C&WmryaV5zK7?;5YWq
zzUs?OI=H;Xuw9EUNB#bXQj{;3;oufLoG7d0f(T8@vu^bJ0E=P1Qfi<_hP{|B0p)JE
zC~uw*Z0yN)R>@}qgGiYY^}ls_wQ~vXQ*Gw;Zmus{zk2C7u`f;kE0?7K0DM3Izknx;
zX(Yjr`1gR``{;krYqzqwf})y_#)*Bo-ssbN8{`+TyTFf<YW$3=p*>^Dr9yZN_VT%x
zc$oaD2(Hy?p%h%}piDm;Dryg8?)Tp3U3V<ZHPE}8QP(;6Q20LrIPtHd*EHz(cB*1R
zi2R084(@G^Jh4+>Gc_M5Iq)HUulZjXIqvK(Rz3EB#xVJKc{mDRezTs(j=_e2E_r@Q
z8;Sri@(d_95{-Z-K^rmr`PQK^pq-u$c%t9Z=oQ_P#!Xe_mo+I#+QredbL&aTUbUx#
z8dUsh#=rYW1{F1um9boq4n}H*X5{1a2bI1KKfUgJP}LGCx$}X+Ms|Onyu#GpT_a7i
z@~*>1cK^u3h0tHI7$I@92~U^swFzP)q9@9k+du0)57;zXaw92D=U$(ehq@>WvRM}w
zM1a-s!4w>;ko`*?!B&REyxMhq6VJHLSB8d${FAM&748l*Z8Z=`LY2Vs=u_Y9@e}0k
zg(xc7MA-+l$_ChWZeeu`%m@FB{CND?9^M2ub5yN1(Eg4~N?46kRPuu^X0W3dnRE9(
z&;Rb?qpc4+IOW|NeP8OeQZ|R2OWypovVQap(oalBBG->1j?2mStlJp;(73SaROZEu
z@s%Pp2FKe!DReX|@lc8ZCPo_)#vD1$Q2enk*K|?xdG>>ae7+259g{)=viNzJYb^SM
ztn)PeMQB(Y2CZ}>C`65VSTALRQX5QrHa&add}m{o^9fu}!D~bOLJ#3V2doXF_r{nT
zcdbK@ey`!YTE%P_dMiE4qltP@D1z94?UE!IIxt9Yr=7lX=kGlH6x4j?3T()wIW!2q
zTHKP{zD>3zwb=Eok0|}7OG@bXog4i$`i21;WhribKmWv^;hVwBgjZ<TIz-hvWUtOK
z-Y8=+<@x{Y@iFNsP$|@~<|;;IPL37N9HDd<!APQ1r;m{t3@qaA@Nn{KeotMKaj|8)
zUM`B%or3;bM*k}niOo$WXCYS4mwYIr2*}0x5FUPB!pFG>^Sus^yp4~zaFp>8-R1Su
zZP;O(C4@K0*~@A^HT8>>OHxl$xog2n2fCrmL3qdZBr&{hzw6n4UaZkI{ft|GOgcK)
ze{^Jx2j<-v{YTAt3i^9D)KEn~S1zi!I>$*B|5ofZu>AS<Z~JtC+=`3@gzJd;I6uq4
z#*E`<F?#V%Uu=CNn{R~KP@<ZU&mwzf=Jj~LT~i0&%vWLm_DfwguZ+Bju-J2&=iYgn
zH!p~rT)9!L>$pg_CKMfvz~Z`aGG6c;MN^MslKYDNpZ+h@%Ou$xR-ZylFrZ<<DFZ@V
zAih?Eh#bVWp{?z=Q;wcK6Shq2xwfo@d@jH5#s5+Z5$(LhGD7CA0HQrh-`$@!ITX>x
z${Jt@pk50j`f-fkY5q^WHA7pxT&`I!G;}TM3F=lC^;*uqQg}J=5UJy?<1++@6sVE`
z8tMg>SBY^yLIWZVesQ$u^}Zl#(A)LBw>ug)MJH1UQj|IfF|}**Of62vb;lQ~cDDyX
zPjPRnG-FwBp`~t8E!c5IP3$v;&O~EznCJe-7;i9p#N>7R)x1oNVL?Bb+1>Y{+=jS?
z{Qe63FSH1>0R5x|F<7!SdiVc5&xhbqN!Ghr(-^Lptf=%`lH=bZSw9gEf(l$RXR+I2
zeTZ;l6AFeBClUd9FvcUF9OEIfS=MT&4+kpe%FTSO5e9_~D69q-+<qnXRp~m4Hia5>
zS(l2>Qn6C1S}K3L_eqP^l;DBbE%FjwaMGOR>ECiTz)Than$1R33iI&I2&1I@<PVB)
zid`pc9ou(GHpR0NyK)0^#?8RhUkWPJv$ShRja23@c9hWi-tTJKle`evluYR4@KHZ1
zn>(A35(2DU**0cxb~ls^hCb(&E_893KY7yWmg$q_dbNPK{9*u8Ak4jrnXqomd(7`e
zEOfMZrXxFCf+~psg?sdv_rFff3A?Z&pqA17(Vo-#7eFB~Wf9NY_?zeYcEZs@wVtch
zn#i_#NP=Gjm-`ugLSkcDt38C@teiY9VVms@fNOZHl@ae|yhPD2Bm$3y>kk?Ec1AuQ
zgpDYR7P;AA3B`(zE~IB>kG8INHm=SdJvn={hyOMfXOCV(@=a$IuNIjXxuNI2dr{#J
zu;T$TjDA$fb?^fl8v8v4Pk<+@(08@B?>6iG;gNXu*;aV^Oe@zsn}s|N&LX@bA!Z<E
z)bSulEdR9Ol>N`ckj)vJdZ{Nbr4MI0i<SpvooGC{GiLPs-Jemm_69ZF*5%&v!pbTF
z3xx*m!y3x(PvU>$`#Q7QD<C4?((U6=B1}G28fCMhQUL*BP0W7t$_nyPR{<)^{>y!)
zzR_JfQz)ahas_F|p#lX47=$W?rGAo6P_=i~yt5~$JW}6Mz$O?;;9`EJ7rpfaR#2@~
zb5U4Ri49cRT!jg$BTkWX%*$CY<WX@T0v>5~%(wLS>1{Sq9Jj8yq<f^&F^j_aV2jFH
z3r|aZ1MMyo*wm84Dmt!w7MUF9NVFEi?<id9z%h9D&aV)Er66J2uLQCku<f-%5Mz$V
z6Z9y6_sBO(7M-HVLc{oso^$$BNtlI1>mhIoOs!+uG?tH~AB>yo_@aI2WXHeVu<2eX
zoBHw(>vM8r)uY*FP(}~xoJswdvyzfjNMXtofGGFZ=r!9O*AJH)#|_7FrIyyGjyTyk
zQxC#Ywp>CFY-$8NKpdu`btaW81lEr`^>s;mi^R>?jl2t*?N{=~y}_`Jvw_J*kN7NQ
zKV&KJk~OGUHFQPDc<1-_CwaD2`$j1xxPWFftrcOC@b`7CZ*%`Y4V>Re_1}nHi_s-o
zLVSt!ZGJ@4-_%<v=k57ar9E}9xRT&;r&RCF$m5}}0?UkwNvMc&H-)u^P6!Hz&XIpW
z&ujjzl$GLJ#Y&<iB;u<H6&n2-rL{zG8reGachvcnU$Yk07rF*PbFtK)?ZYi{02CUv
zNDwU)H^8l|UeNtwk0)f&MYoZwX2YCDWG1H<h@L9X-9`NX=9O-u+|;9wTHkBx*Qs;2
zLJ)18ZNN>sAJl3%ez0m6#Ad#x?;{wR(GO-&lQCPX0VUM^7@f?gwLrXt{DK&YLFki<
z_z5qh_~wspfN}qhj&Zs@p*l;3*T+b<WW#czw*OEfooKD4&x^Un)LSw((k<nK>b2I}
zmuoC$hsa{p=i}I`vSC)}_6dDfyHf-B`(hl+`Mj91?@(7-nsiatdeAw2j&8$PwC4!e
zV?A4KqHuu%E_wW^z4Aoy9Jvfmeo94wd2@6j+Ved9N@CcjVWpl$^}@^Rs4G<{9hb9=
zX4;IrqCsWObK1xAq`q1?hmM40RV&Ep$s7z-_OVZ~9BOI~v>iX9_cQh4!ToF<+Q}_O
zk|dwmLvoo$zt<rugKFbuZTXKvvH#-KcUAMJ8~NI?qpil-TCH`abhc4#<uYfKuSInK
zV3{#l@a!e~9~p0hT;-AaAq!3dwa<M=+06z||Ans8>(VEyIT&@tS_wHmmuJ$FbooZT
zFVUY-*84TEX?H+CB5*{LbAl}$!&Bo;j|5xVR5dsD(ez&kjUd};Q*cs&z7RolZCQ20
z#u^&A+`X-AUS>rhwgb8v%Azhw!jy|K{vTD$!9zAi_+SN8@vJbxh;>la`WZVuz3ZRX
zW<F@t%BUCCP@3`N<h8LIKV@(n!JOt06P3SVbDVa6if706)q&0gzdu~m+SkxRJqXm~
zM6h0KP)SQT6=SQ>aXe0eA+Ys6p=oLQB?=!JIj=9)Mld{m^b>nPksSXP!w&rglhF5i
zJ<r`)VzbaAA(Pa~Bt#Q1M2Ee?Mhqy(3dh#g+~Ajq+keRL)8AG)I$}j7Of&``7=ID4
zjtTTK{=JeG6kLnJ>`&@>?EUC7WoslWb>kW?Npn*|A2ZZ;$5G4?Y%4YY?=&wyJp+^%
zZQ)Q_>(auKtFx<0d!3SN4L?{iIP_W8s{uDqxVc<&<x$6*(tsG7<$R%05J)V{3Hz8m
zkw+E<RPr!~|I7Hl0QDiPK$IVoG6WSpuIaDy@6!lEbgQYA=>IQfygK<yD95x3;Hyx>
z|Bcxb(u)xgBjZ^F^AP!V>%+#^I7cNUhlT;rM>^}trP@f(#`fNxV+@DbW}V)$%7~V^
z-lOk7{jDNDm+42B_urx4-yf2nG+O>=j1)`IGGfKpkfa{T|9ra{{~Jfbv5O=69!F=6
zv4gfaHcK4aJ@}XOqg?B)Usp1>)gyjsbn?BCVzv#h7=2ww0_#S<-SFcHsxx@N_K$gb
zgizknO~mZ4_E`BB-n7+KDb(uD<o*-tde)V}^-@;G&}X+IYlq&D0_}o6Wle=n_wc`m
zy=NpOSKc=^(e1vN?tGN5<%_yy6iZ7=K+7xiz4rV2Kon}lDoXq)jf5B?t#F0a(S~@f
zi+u<N>d~M9L%vafUL)!{tq$+Yv@>`|bu*ghe61isjLGOpyM8|@)ZA~DYxQgsL6LIb
z3C0JQHMs5d%u7q3ifXM;$VAN`A?^!9O}$Q^!QCIE+;$O(7-Vd_IW2&-Z&itIdyYiy
zQW~dp5wY%8Bena#L?5};Z$C@yWwvBJomnYn0new>J%yGq+|-RNVmC{zwH4+M7#?!_
z$425I<$n$ya!If8op&oc=g1n=5@_YEOPw3&@OOqm8Cj&!A~qw-kgtRB8>+&_kt2|x
z?i(|FU6mDT=x6Ld>|#WuHJfxBYMmE1)WLg#l_MskRpniH9si<){;;{<`habE1Gh@@
zx5RMXc%x@1SDUQL0iI@f_|7bS#;t|k;>t=3C1uxF7T3DK)%09<#_6+WSb5Bx6GY@Q
zp+efGYo-od_q?(@U|S#9H8X|L#mC`O82w&JqDZvh!xJ7`RYq|@tvodK+{&RTg>kQ;
zo;2#$IysZFI_U8j)$?RF0N*h@efsNttQsH@8k2?<(+FvDwy)ufx6Tu17YVHO4yFug
z^ufu$kAAVkG~la3C>knV!zV1F#<_i!$O`36#GbwcbdRZ_p0Lruj}BDSJ!Nr)*Hh<4
z*}L|}Kv{RUHrr>M&OB2lEKq1va>^ggrQt}}M3MLz#isN1QIyj8O|Xrh@;!cyH;^>0
z)J1(>(=SN0H6;kBjV4=KT3vznVoTmYZ%-6(!au<`#GLHQ76h+2`fR1MZ@+USc_O!1
zfG#g-MBoGgV(4d`Z+e(-E9Rgi^2!9ub8MvIFt}Z2Gb2+tdhED`X%oXmMxKFH4`M_7
zzTlQ{FumXMhWlUT(Ld@BW($=}qn1^LrX9gknWS3j=$cw3sh-yzmlOJ+{2<jk?0HG(
z|6zS@Ppx~rs2N0=Qmxv|ggo;Z`7$Fq=x^d*$|V(8c{df%7pve*22-%<`xlI)u#N<*
zNmlcOJKs&7VALJ2_a2%YF-T0(hEXy=XAR@8SE<(*Q?J+e=x$PGE-YPR>m$TqtRn&o
zF&PAt`W?;V%g`aG0sKe!KBkkp*Nd4u7;)#~X7)a%^yW0;E>ZnzK`KM5FhSf5|AfaA
zWB+fmF08FK*dE?K^Rs^J<;hAutixrCP^OKQB^DYq@?zQ>Td}Vik&^}8Igd7r)u7%$
z<M#}lJC>*&W%EGLdg6PEOyxTF0i^;3haWt(7;xWZp5OaLp8RVD)kdjO%V}egH)N?J
z&yJgu2RstUcdh-@-=nykt%sSWZvD-p${Q&e%3}&Ij<J`!&nKpiSo3Ie<8*u3L@<dq
zBTCAQ3N5y_@6H_U7<kv=bZ8wtak7Pi@5pF;jiKY;)3yR)z1LN+HyEWK>CFli2>Zs0
zCaLx%r`fv*aeQw^*;FU>v!cHi9mDI(+FR^&;WGfGqtX)ctR?u65>pjUKc{K*@lSbs
zjIGV*Yv`>Nd49Wr78*3X$;_M&&53o3y?xZj-oQr-VK$2d4avPJX4+R~Ph4XKbo`dk
z2w-lV?oIi*4k3*4g51;l^xSr)E!{8c5C&UoZ}*RqVsyrczZzEvk7D|aE?I|2bQgP7
z(EIh6SHC))LreLnT&fpp*#NfmRYcFWS0$=-6S1vZ_@(1r;W*+8tg6w0w_oP(J9;kH
zv-NCPDXT`=+|UsYH@&u`2p(>JgMU$0$u64beeyefxmpaue6e0C*OgzE-*c)WZ%C0x
zy^_b4PvUjSeq<q<)0$@He?{@stT|bO9*hfGtu#T${hi7Dqhk9A&3}X#uJTEWHZRQ*
zrRuw_4!6{~4ukz#d)3BDrFyizC!X8iFTo~hZmWELvv0xiJ~}A|l}c2Tb}?fKfy3#<
z$jtBc<Wh5M6M$o`eQE2m3QR)ex8RB*3#Yz9=eC`bNFTI$SikDnbyn9C($`ME%f=9}
z=J&7$P}ZmMVn?sYUk$URQYqgMGYHwP5YQ4H*M=}F)dGu6be~W9U_HRAwDbrsTbi8e
zi!UFULC~1S4_hKxIKPqOx27a71$nlo(}3Ef$z=mUUNDZ}Z4sF$YnA$T!AxdnA5t;~
z9Cj0+6(T4OR-Z&cTP0V_{_nlq-+$Q3g|OJj>UavCNB*EdaH5{?IUV5e?YDAcw=bT*
zj%KIGeybM><HYkDUEsOT_Vfv;^0jKcQ~{<cT7%2KRJuSx-fXJ9lqH+@=nyFqU2$2<
z`-TrkFYxFi+dv<`s8G+-P6mN!*|wyM<-%8W!uaWRANxnKH*&uz_?2wjOd%7XA#<S#
zt%rjo`#UWoqpCvn>WsXkBE<K|98C<1E^v-43%N+Wn|6P~M^+5*%m?(dZ+)qIcKT$q
zQYzMR5#4NMX>lzsHM!jCR(D?9x1P014MBr>FK3<uRO?A&2)dP7uc?l=UI-7Y6bsE#
zJ&%NN1o6zC2%D!*pN-Cxn{dD7@@MklnS4&1d6(L-n`ICiX3Tvt`k5dXm2*)gR5`sE
zaVXQ}4+l(e87Y?308hv@{Fr3RA5J$^3L@Ny)*gvINj*+DzNv?USOpXmQ0HkG{Wg~2
zmbA#koS+h_CAjtD%@6V8iLy08@2xrIzNJ3Ii>JVOyH7vmXhQnP<!j9%x@(Xe)t<`Y
zQ9^Suxr}_dF56^t0j8etVoMJ&a+jmseT7F;=uKS@!*af%1GFdTUolwt_MZ;KE-zqe
z2T;{<<>@F2VGPI|4;CeXs@7DNy%N5@`;}Vvm2v>4@3oL#ta-}zmMDB8#Hsc?YwokH
zVu^BwNA(Fv5kIq;v&v787-5Rg;}|53)0gRU`L3?p$Mo@18MtM>6iGamL}NLgv-dpV
z1FaToBZ|7;!NJk%4_p#jteC&<`U`%p!Gk66#wgNNVac*7bC6ePWZiApzmRn}tGV_f
zYLjiYmzZ|f*Hc<fgK0B~Sr}jDt^ZkQ-_>&_N{bdDqI1X`_Wat9r?OGD5$4L-pkAMy
zSz4N%xrr19>x)bOvX9G1g(%S3q%gp^6JE`fWkZa=cIPPlB<KUaz&_w&lgb?Kebn(`
z=_^>xAmBM4Dm@(hvrKV;taSNJF;33NW#$jZOuehwWyi{kAJTL+^*tluuSMa1vHI-D
zDpD-L+aLg;cB2zK=J%cg#@?vc!ZOkYWx7rVC>e%R&HVb$==tm)ReqR}<G+U1EQ#R<
z$xf$a@nFEK(Qh}5zt~u?_nKOq&x_|V&j4cn6iH%;S*_~f#+{<4(gS#8Y6V?A^|^U*
z=sr)sPoMK?#G)f#eeIH9!fOj%Is5-kf42WWc`_bFC@T3{y--KTMWJ_UL&FqGbvBS(
zY&1-qdu9pR-_)=A?^EaHD*ZS0q&`o#zGRH^gxoo(BN*Z&gmvul$DE+?1++nI1YaX&
z`xDBS4>erVTRbiYU*6fIOV9!BGT}S$G2;in(`Rc+3sGfj8oO=hNsrGXZl!?kOpPoJ
zSk2cbW48&tQ5RWb?wEwmq1<5yQ6g8ZjrzSWbz?~%g9R4VLv+~z^5XoL_xrN-Sh-Ls
z<Wc=T$ZR1UprN0U{sV>S*jf&ZGnr${7H#$F$P-bOSkU3%6_Alf_5G%Qi1!2D+aj(A
zDZ-FzD)R%4C_bjYv;Cc<S<(5GM**a?*^VPi!<b{(LNcH4C(QA0k<8mA6zBYLHQJ+~
zrt`;-fkR?7T&(=mYh@2-m)gLLuV6}wU<ZLSjhm?;c3=rIzY(K<(ZX0@46naN-}gm-
zdB0xg{j%l_ht&d%IkgGP8-JMnVu11Y8nGInvy)4G{nx5N4mB|IHS{opqvdR`y`fs>
zlu<@?191$9Aw_LcgXerx-#I`l-%OOLgoys?2B~GNjqKO^e!}D5Su_=_G;#$L&?Nt+
z`ATTO8Njs9_<>jGhYXsp`LS}+2Xg<5dJlrHijn;Tl>z+CRGe9WCD;pn1q+;nGW==x
z$GtfKRzekZw0a9e&Vksk(>rMfy4ffJ#MgwG9nPeT0TDIoYRu-@T94T~qv#2II7xuS
z9MpJ{f&8A7CZC|B5b}e&hnfOUm>#rgqBvILhEM7JjJ|pdd5e&;iRCyy&8tOjuag+W
zRug%&{SM*nEtSg*pDI$A7q7GzulA5hg5fNpd{63w`r196BgB*-`p}m;Vy;bsQ2H7A
zxQ?b|cCOR!Y#hObJ$Ihc^`IP;YXvX`%pxq{fE<XD=leJx5{Dq`wet%aPtTWnkb|R^
ziL+}s{R-dSh0fVZibJ>yY$bLPW0-aPaXoYqFJTR^1gYsiacejOzS;;gjZ#=vMdhe2
z(HH8t3=uH$DSqlq<AErss|ufxXQW=>a1z9L6&ty7ltF7w%d~iR#o}HgZz4e2*zW23
z`Q25N^=cy$0)2&);FV|}T`U)s*l+5OkS(=|*iplveat^|_R`8_mfMm3rbh!Qz<&Hy
z*>cwPk=uK}!BOA{Z*R2M7f0%llRkgk^s$Frt3peHD?*eEgA+~tD^C|ZT19~sKqw^B
zB0EURbwZC*>j(5n4%pNO%IfP<4^wBEEmP_wcQo*N6ImaJ!AjC6iIr@j1`*&AugBq^
zkYD<_gD88B620P8N0hW~v;jiI_9a{BV;_36Wj=swlhLp?A2w_ByJKLP<4Cs&&Lu&>
z3Cm_6g4hq3QYxJnx@fgl7m=8-*}mKX?q+PL=mVNJ0pna<S;Atg6&ln`b6U03O-H3#
zCC-BCC+9nKU#Hh^{*B5v+hwX@7u^b1n9=i;&GSPx@Z<XV>8U}UsmW`ynZwDuY3z#_
zR+^wg59g)$lAQH|-qWdXb^J6PMnNf8L9x-o$gv8B7wmx}z%GHERz@k)GkNFeg_Q@R
zLFhziXx^{&f>@Sfz6eWG`_iZ?GU;3~*TL6Rhh2b?1gV<mZ<oaXgIfQ{e$lpVA1@N!
zU3k|1?=VgUHS|;gy{uTlXHfeZpBbOqC;fU<jUXFVt0<CR0h?A%L(x?5Xv;6RFMIs*
zWWJComaC{v(I6kfg~G#ddFqPIsaTLyI*WHs^~XciYEiLn+_!^xC*8D=H%2Fz4^+GZ
zv3jwRuPtn>uvr3ne_UT#YD1U0wzAP#mqZa`^yAs5^?C$fMC?QP$`Vph@>W0zM;**N
zQFep$Rxx9`lOZjz|40y*@+{7ZbJmeDqumrX#w$>?w6Sm<!CLE=H?IVK%}3Wv((HZe
zzo|7~9(uWVP8d+FgI!{C=#<TWi{3z4AwI%^E{(%P!(AM}INlQL-NV$G{pR|TroMg>
z`v3T2PPUiEzt=DZWWehu%z6AE`8z399NIR(J5jTbVTAEIW%889Rd16f#4M23dBH@C
z&3yZ-96z1Og27eGrLa_(c<ntSAEPf9el|OM1cG+m^fC!D=-8vqCBPgJ6Ov;Wn`Wjz
z*KkkV`MwZyvx^qzxc7ha=ZhG^LaEYh=vZv>Z))6xFPth)E~a?ALk5TkxNCZW@W@})
zbaE#e$dBq^MoGrsI3)5k+bti`<KOG>TrVuWW~;Z^x+0Z3<0dfvVI%zDSFjrY7RltD
zE19}-q63Qjd;@Dl^f6hh>+X-!b8?(L8jekje5a&&T16N0GcslO{UXCyqH3<axrt}c
z+|I8rB6JJ5gjtWBGW8Bm?QrpL(cgP=X>nn_1uNw`DrMWGL_E*f3AdYL(D&!5o$w0K
z2&R;Jt{)?gdVaaERxj#kL?#rIC8*<1Up5NPn)SSMFJn?@7f95x-0y9g_I945u}-Y^
zK`l>m*`$xX4Z*{<CgrSI^TaRRoimlYb0(a7q+6-p8*(;wJRKP2`!eiTr@bA57K$Ex
zQm;|zy^e3DQ9Hg=D&`6~@J-;)wT0eh2ED7UwWCfK%~fO#uIcYZS*L5xltKX~!d$(g
za=!?|GKh){mb#;L6E=){kH1gIPa+~s`_~!yD=$AT$d5Df;AOq`!O!YAd5?TuPA%i*
znJ9R8n7mD^MSMILnt8Qm|G$IzZ#Z(Y2rMCyvb{&Pf0$>42Bt_VsX?R4-8*%TUXEev
z+}N@|PMK3213%9WJQ)hz`Qz?ANl^>%Uhe#HrOCDs8!yqwg6Pl=6D(Brx7(M4U&vOA
zjjAs9$}mU?uroSF`kNf>%w&;2->m209xf{9FgKMyXf6?}qEzL3PTU?I@M&zOkCW$1
zgypNY+8Z}Lr-;k#ocH~Q59J!ALcUo+80U%gj>>h!_)W}7^jDgebQljZgj-1dS-XT5
zSzVJ#cztCZrK~P(Ed$wt-GZjx04u?UfmH!UD%q@512p*82L@&E-yFP&s;zF$)x96}
z*A$>1Y9`lf+7~N8tegl!hFn2~*20d_pD2Y!>YLy)edLaLfA`%0OJRLUB`<~*N58M?
zry1Lh-*+2+m`1bO03@e!eCS3R$p0{Be&ni$GE&kA<2Z#!2|t_q0DZ6O05Aq$jAca9
zGnVZn3%s=|Q9h?_7;}bGe?c2t)ri-9vJ4g&OvU)CkX#dY$`Jfq#Tf%nSFvy+n=z~u
z!lqNEo&|EY&aI$~=EAB9ev{9Q44?jtCx3;n(k2x0WhomQuX^XZyuC*cnrzg}MUA|Q
z?{x>p>8I3YdAi&=<EQRoTSr=!mhw*Nv*x_-OglcFKHe;3YSoN9Fc-=H=*Wb5+@ts5
z%{+hTlBFwm7@c8H*|WoX8fb3!`KB<q-Uh#;=XmRGY68SeD*+Qrwgrv4Jo>$o)JR(s
z!0ylLNIL(x5-E8u<K8KGCRXt`I8pR^i=BW809w%}Hnw{nwJ@5L>ROW$+6x$vS}^?O
zBRW<@dM_Yu$WxVuHebM{6rM&NPXD?)OEcL#f~6XjOaV+o&fet2p^Y(p?mv3`;zT3g
z%vY;Eg6YfZ=`-H7rA$z-0uaa|>UNy5IT=pnE-pXQ=-%D0@AF;N>)9-dCaBnOrAWww
zmF{g6iw87ceePSmu|C*nBK50~Rmo;95aCK-anIYE?pferxl%rivSF~ia7pnxGp4t|
zYhd#yM6_nAxoSm?i5&Bq8`GTpiGE4uyJ;UUhAja-Cv0TZcPX*>L(PZFgu?wIzra3I
zJMZ-7^H4p4R)QjwTzMiB{3;jWl(1V{_w~+iC`@Vt5T#NuMbBijiA2=@E*Nbr@({y@
z;?b?7v#V573e1K+XFI<_JQgm<yL8IvhCN2UcYletaZ6zHy3`-X+R2%gHM~;r&mzip
zAY-Rq*1AefHaC<XJe6nUFB*UhJ;bg%*}eVeiZ`TvrXbN4C=u=ZD!2P+uvmyHjbgqU
zEVfq&(c4(O+a=nS*U?pE?ULsic!yr2?QhmPDU^5B5uh!8*H#tWc8n%k(nH3mGS-_b
zN=%X^df4sLfr4N@W5)U5nE3GUfXtD}4dYDqQH@Ld!)Vt4#2zi|evok@t(;EPQjPN9
zyH-J3srTx&x$_;0&Ozm6-KHkIal;Rj2(S(Q>to8Akf^&>{z8~%c2g@?o{O4uWyy33
zq^{H1e91oYv}7#6VUD+3Rm!=r**KHGa7JC(x*=cAoC!<$(=G3l>{-;YlPc$;eFi~k
zCJ!opzaDq$LFFIExaq=JhRa40mDYRc$c*Y$fC`hH=Hlkwf?(~x0xVdy7c(ELh_C*O
z)(}F7_5!V*M1qWV8^jKz14(Na+Ynon+V|`iSnYG0OC{EXk<VVFulXqcHu^exzd#d*
zi)O2B<;b7;XZS>=m_u1O_|GI~|5AYOUeouv^#PBc=b8cRvwW^vw0UJ@C9ufIVfccI
zH>C^JbJ}lI-j%&Z5QGwlZ@P5m1$k`hlHQ;6zRr<AonJaC1T{kMHW;QzFkMvkd_0$y
z{LNN1#{Ac8%=*0cf5XIb%&7`DmhZ8CjsRN-{#JD>#5SA%RmFo5;^}I5wwTP=xrxs!
zdhGMR$un^oJ}>d7No8lnpN1%IuAZ}aHXNS0^8;p#0?ve9{}`$Aqk4K6%wYPL)tP0T
zLfzp&1+6+BKX2*{d!4G(?0d)}PNhC>*8dO2m&Zn}j{%48+C&)rUc(ri>BQ~wC3k<{
zqiYB+G(^jSuoYbonD$h}oF(co9fL@aoasZSv?XEl7_<Xf(`9{@ZlGqn)ybew6{1WX
zb=Z}5#Ctq75W(p9yALRyoVM;>&mjy_9N@+}s1kKN81dv{-=ZhAJ^&r2*_D7?g!q`;
zUDdinq9N0&j4f|N;x#tH{1I=Bv#6y|1-?@)KwY)!h_mILzU|hR%HrXenYHh+)`sWB
zSMyRjlbq$<|E%VAMC_oMk<B197^5m=&wBI*<qMqAbww_(b}rdKDBx$P6>W5rI7c6C
zv*(*LcY^U&t7szS{O31E$`vb&So<+X_eeOJcGw4_t)N;FeLAPdz5Uf(gAJ4mhW7xQ
zt7beHhSWNLXlV(B*I(4<W&RyL{h)P9Cf{tDGs^Qq)6CfwDvFyDMio&NIwN5bmKO<Q
zXyrNgIh{Fu6a`V6^-@6yGsF?j!8w9|hOZtW&uqq2T~PS2(9?EO|4zdcpW@1!(`C-q
z)K9zd)BY}(YS~h~rT{b^p^2QWkLf**{=LQ!T?IHnCq-XBlAc^XUxL@sEaJqZK|@Zl
zS<BQ{_;iK_p!r-_%tRF>3?{dh=6O@E@}E~P2H9-BP|TJm4W1ZU-|zEtlpBo*s-Bk>
zaShb|3Vr52dea*lZ2wv#n{7ra4wn+n%aouki5!jBX&Tvmn0#QgJQ<Br-9?5>-#10z
zh~6dVb=$8Q2Psp?*U|o3d1!LN3djX0&G{EycTC>rOXBcG@BQ2{PgduUqEZesbz}ol
zbQ!sC^j_YaQlEM+|8goWnH1FlCEoc&M%1a-k7D^#Z`Nx#^{2Eo{n%QbII$H>LO8}S
zLA%h1r+z+fdUTleNTZpg)m_SAP%Y+A{;#1#IrSyZn!=i5n{>jn<J2L3%C%N-8aXxC
zE#0BQc4d<o?rit;lYXyy*ww(I>ba1d8kZt##khV3H7|E7i|OzA@yyqqE-?Rx+J>Dy
zEhZ*HcZj3X`ywh&U%;%W-RPF3+fh?jH)m(QzxR4IimLf2tLk)f)`|!olA-ZW?7X4f
z$3X;keL=gGY_V9$p+J~i%w;4&@ituFLBF$nU+45ppHq0nker?vMjCHS0fR{3$&&)U
zwfd=ZdSVAQ155}@jw;fLm=5kj{Ow0IFW9}s^~AAJjpkN6ovYIKjbWN%K_WpfR>e7n
z8SBqchkJA7GR~dUv2tGz&Z@&mv;bG2S&h^eioM&BbQ#F`OpwJ9XMUyp?!MUVHF~cW
zOA%61giW~;N~(YouKl3q3*B#1dkQ=;DFQ1-!${oI3G$DGNOq&JcypNgW5wGfuXGiu
zyD?KSf<9(0_FSqAOSK9?Alqd&ncW1(zr`@iQC0m)r5@FEb?bF*?`DdqL!Zs$%T*N$
z;)#W_99zfkcy@Vg9W!(WCExR;gmGz`Izt=!+54CLXCv;fS*RD`2qBM%vsvk<rlfHk
z#0-+S3?J&uTfV1k)}xy4?)*R626QE~xU*=~tty461Y=gmGJNnYeQ`GBAXlhn3#g_c
zaW;`^Tyq{7FrDjj5NbF+0cgbN5PRROc`>-ob##c7QoSy0d8i$$%+N<zl5#Z5SMEJ?
z6o90QquzaGa^8#u_+pY~%-p;EGN4$`p?Fl&tE1t`0B#R_JMYwMeS3s{PYm!z*y&}j
z>yw4XKnPFyEX1n=kU`Sj7kZ+uAwB=|BiW^b){a?2+MM4QNs!C}5@gi)_Zr3vSRO-W
zG(sKeyLfW)%7ae7AQy6=n)Jh(kCpz7<74S;DL_r6Ds-J@pnMCnCziI>x>EFXt;+^P
z$7fFpi?G=CzRKxX?V!37j^Z+M_O^Nm5Pgw8N3Sy&XUztm5Zip2e*Ulb^=>VpO?$D4
z7N_8hMLx$|*FEBm^T9?T(`YnMG8aAm8qM>72&{eeMXV{J90@uiyw%^ui?*iV1nJ)*
zKLs|7=cyeZ#7TgX5WyX-BcLkv?tg{nROTSh+kX*#aLBy@^JU3Mbc#Y<NI+9pI;%_c
z+w!^}<hX!WsRn$gl{lp8gX=31{iTxWG*6f#JW<h}tf!a*HoB&8*wME1vvY$vma-Ow
zdgd6ic|>bexk|ED!8LxaYIT|7Tx}smuWA>rGq_%0djz?>nA_jObrT=KK<MHy<L)jd
z9miFY@?v!VG9%0OU+meylJ;9~HZmEd>ri%4qfv1H>a{x)_xoq(R2h}DLc~`FBB~H#
zC>3xW{<8a5?wrk_iE=etsby;ANtaShy+@yk?f>OqOzU7@#lz%mGGUHw7sc(6O=}fQ
zU)E{|^k?kDbS?}U0Q<_Kc#c@#*!b0=f6d%8C<>rFKTXZ#ut`X_7*jN;42zO&Gi4lY
z$hKS|!Nj~=@H9g=sTcOqO%&FP^{}X*0)iiO`YF0muT`B7Ia}R#tFu*{Q$Ed&P^uHO
z@+FU6ZvCxW3*@6`f?_5tM#Yj>G@1G?72BuaS1>&E&a=FljegD#a!RCv)IEBSrZEA@
z)xELUdQ|r8K22}eOn-SVzWNjTv*_*Q12zI;#GdPh5salICDZKqw;Rq(K^mHu82Y`l
z;`S^JVVi^Pl55t2aCHSqlCvkSz`&k8f#!k_A<+|JTkL|_6Uz%Ls|YT_zjJ!M_CBWR
zcQ$+E2(qL~L~N?!kI)9V*A@Y#h>+ffBJW^0sw+z07er8+@x8^1N0s{Fl|mtc=3XE5
zd_AGZw?9f<>+zQxR_-&kd&=T9_TTO2c=5ajmAtvW2&eq!m6rB)DMZ%gjQokx39fXu
zRuRQ@b)}0q@Vl-L5JTeeutqEZV;L!E$l&k0f9+^-CX1rGVFg9Ca+ygB9HCjE-Js`T
z>XM!q)+1E?S9Uu&l`HH+k;?ZJCM`GuSs3j`Bq8IU@Fn@3x+Q$Jg@mczW^oI~^0{T=
zTRqs-8=KDOf9FYU!`t`<cA<hzk<AHcCVIK>-ua(nJeK$@5rBn274#H0QR1<o3st6(
z*ciU4e;U*U^|q^)&ba9$psRihcamXH+QhZ<*;}NZ;5=TF>$m$%9cE6+(EawuJvuBj
z19&u|dQsOnC7$fiDf&+x36lEwk{HqKQK8EL`AU#$_Gn;v>gW3E#-Qgs=&gvh3?KxJ
zY4dsfo<qZU0;FWDjVZl<+MQSFds~4YI0WMlHrucefzQr9WOeA-hnx<2tIzKR1p&bp
zbroAn?}SJeV>3>Dg!vP&ljdM2!TwZ&$;Mn=z<5k-0W2w=u&u5{mYugYRP?Bc)yao*
zXAdo}YtQk${``)Y@|8@k3CJisr`q;fJt8&7G148OS*|_1(|@GpqS7WQ1eXvuhhhY_
zH;`07Mjj6&CL9>}8{*IAV?;YXZAffNDXbRI=uGyCn?nts8>Tcj5{%k&dNiC9$b+~@
zB19RL8y+j}{4RSXVtrU}EGLQu9*9htlVXL8`5TPo<JgV;J$)Z*{a-$~;%Q-V`7ECK
zZq4I%fA(<QKcT1k;b(RXTXd+>kMVw3k9TiwfCqJlu+fo4<<sxg0c2$$L)#~Q_b-!T
z2*&71b62`kzswl_7Q?h%Q`ywzZKjUL#WgF<Ud6Nr6<AJZtiocVmMh}q!UxE-Gvy%F
zIX7n*F{hw>V^?hduE=!_{cNq{(yLZ>ZGW0Ibe!ypt><o5VsyeyrkwHbHEdOlEH*af
z?sT6`Swbt5tQ0~O_C#5w9O~pme0@2vyzTyzPJYbfAU_&t)ln!a$Lwjj14D?&ww#lO
z{EZ?{x#{zAA-NcTIHm^NFe{%CrL?m42fSxy8yPf6E@z4*NzcTkRPZKZqnhW<pY-@Q
zW9>4HTt1KPWRrcK*^l5QeftsS^SNfOuEYh`hfCU@BVzQ{&F3q;ltpEiq>T;2h+1L+
z(l2Q1+TOyRKTGOtC}w#e8`20i8iGjlrf@?Qjtdu&A34WAC?}rOy!6(S6W~AN!aE22
zljGiC*eP+m$E@vJzL|8_L*0Xw<;^n-mx4kGNu$SJm8BT8Sj8>G6~lHwZUz!cAa5#q
zjiTQ+I*f`6X7L5cl_0TE!1?3RMtgbXhAL_&X1~OYh&|DbtM%W{ipN&p<K(6;@o!^j
zx}SEj<C;dipm8{nMlq&GXNi`L`w=vu1fi?4Ultep<d^oHnQXC9s3Fu)4k-DIr%Z+N
zW;1X#qi(&0X92ktApnw4GJse{Yd~qjR;w;6;xF>jD^BOpNe0Lr&%*}x2iudHe$3|?
zh^fitQF1Y_>*fqNl*t{b&QTE@=2hkeO_>3i0Kr}pOS%8J(X(|ulSp;0l<|B_)6MRW
zC7n~m8h)YW)_@Eo*znu++@|~<<|~UGR5c^u%HS4knsiD}=zHh^uLD<W981pJc8zob
zRT_yer`xM%I;YzUtIg$QvFf4x>jawElo`p+H@MHP>L=~$8zFy-MIbzP#T90qY*>Bd
zttMw029nA)aWOB^FFIP2JuH+8jeI7b3o;vRc%<5y?n*Dym@5aEgQ1m=yhrq#vMsSR
zS6k_Aq9no+u6es&&%O3Ye(3O@BR<;LCtvfgoGy?)7KPPfy%|YJfb<8z|0ghMu|qMf
zRO+(AbdZPBD#)6*UV9zMPnL)5^w+H`Ai$tp!7|1%5p_^iofo-v@B$@wyU`YEI)aVh
zJ<%V8Zf>)#C}i#I>EuG>n$ryrj2rTG&}mlB^L>3WA`$G(2C5pMqPG~=H+!(`&#bJq
zAz4s+vYqJ(iO3rPhH7gDZsTublb0p=Of=y3Qnb~(!e%_A7hGfTtv%+)aE=B+96l9Q
z0wMKAy++d|+SsGUw_acAwA2x~n>z5Tode$&yjo<dtij%Qxbrjvr*s)5V+&c$x<OTC
zAqf1YAmI-xx@Y({<1SqQ5Yb0k_T=wM-K9iQ>TZDNE$cOy|7f317K<||ko~O7krKJ1
zl{3NX2R@M=#fTrGXtH!Z)$e;OM(EN|sVZSf&0OJ7)b}}bL=hR?^j5!an#(k*)sk0P
zLMiq9Dn+hP)kQtOsV@;<&n#FS`k2MmZ^LN8ppCZy>I~v?<LWc&>#%8NTo<0*C;tnG
z*e}*2m6lGMg+G+eT$PQwsNzHAe9k|I<HGsWeh+U9hj~2YQlXvu^c+)PLrkCj7`xIU
z1NVQz^tJhNEqhsS<k~_DMU|P4d6!W<qpMNRq-7bz>TGw_<Ys)cchVD$?RaDMdgrHX
zEQ65hGTfCGcYGguf?1#P$!0Su7f=snZVM5!#9s|IIt`g)aRyfs#bQ+3Ph*|<gut$`
z?S_OXRSQ#@xy~<`cp1Qws$6XyAga|#Qa=;xpPmy3wYf(suhwfI5!$Z%bN$$e2g5?C
z*o=U}i<AA7ghq%hCue^86ES`p@K2ME|D*c4==Vm_fm#(RLH!2U_~aXVbZk#CCWc|`
zM)&!oPh+P_8MHC1A|x7(X*YVB%xuo@?J{M{oUqiwMrSSTtZ!~~R-?rMBj*^4#sS*x
zPw=K>iB)VNT0W@PYWo8NxYz}7`2%jL@mJ-5nLqw5h8g;V!wh}R|0VMTQIYTZ;uWvH
zu+f`$3bFKe9NS`bp*y3*xeCWndG5A0ys;f`mz_>KgHjWXVlIqAfNLVR?%s5y0zwRq
zLV7KbF&jF+HBbNIEcBX5N9f1F3IJmfOPo!J_LrOl(AC4BD;eW$U{!{f&NPE^Hd{dr
zTCN7AI^jZ3z7Ogw_kXeX{d!PB$r|*XRcN7$BUics=FdujcE5FP5JnBEYMIumeuW<2
z{m<*We;8G(`D`uTZkUt%pL6xDw;$2IrP<R`kQ*)2Z84Ad+!zF7$eI{h+4b`{5&IF<
zO0{OaqC9cjZ0eb6N#xo5i?gQZiGL}rRM|`>=ZD|r$})^d@;g7K&w2VS&j^O_jEE;w
z57uCOx4x48F5TN&mHLw~dL%|b(>`VMou<B9WZ6p3fPDAqwMnTMD-~!X-5M^nZEVE+
z|KXi$^hYaa!e%|M_lk%$fAE}g*SH6KkGeEpa>KZZ+#G(&zZ@Ra&|}$ozv9Ool9b@U
z?2i(69tFHOSkn<1*+OjQEX@BMbz2pSi$Zn9_WEhS6rD9(^JeqR?;J^9s+{V6aXGf$
z5jT-RVJTzB@KV3o7nfYE=c<iD5hl+};NgH<<bjJ&&tZ44jSrZN4%R^Z4xY}~U=5Ui
zSC=ErU#tNqqxbs!<b`~$SVaR@@-A+%_{q(=no4oML^2@aRr=YC8sjmJb28c0I!W|=
z(8u(?XZ7*Oa;98FMM71cfpqOTwl4~w$^@y4nx>{dL)}F(64f3IMs*9eH$wh9!qjZ>
zMdRC<ex1|PXV42epDUrhQ%(iqa$wvh@=BgMzNgUSV=_*}5#T4^<-z4g{L8~~1A9L9
zete|!QI1h3pO*9S3cbeL57MuSh}V_1tu-);%j-zZQ>MB(XU3HZWtYK8qK8tK#!uMw
zUVj5ow^j0z>26?kR-8uk2vtoF(RUd|fu&XtDqePx2nZ)D{)ya|`|g>%e<cZ|Xtge&
zs?TD7wi<Rf!_)TwzAyLLd7s<cbR&qOW<4sxYj?WiaL)kO$r{M@7rvyQMvM7oA*)D~
z8k0w&4cT-+2&qr$v2I@;h$TSnSL9f1;UupwY;2%Tw(?G!4iGVl@wmqiYVk93mP<%z
z7p9ig`AK`fI1&wu&2X2<Mhrho&QD5S1Y;+Re!Ii$1j04{KTc7a^jZ#NDY=@-dtXC-
za~R%hIQ~Yv+kt9KKlVB>1Gc6ef#nMg4!ws+>kk`#b2l|xN2jesGj{Y_B$1~r)oOWX
z`YXwk*A}j}RRNwk+M9|giyJe0ZU!~h7`3WC5+GUWdcq4o2Vb?ZxzaO87^&p)M2L}_
zWo(bVmwWmw>I~Pi<wCKh%XU))Qf%@s1_hFfQh}w~%J+B)IV(R<X|fcoMAA*c7^BDi
zS)U#!rAN!fDxyu&;Kc^p+5Icw#gH+Z;x$$QvaM^qE-GGbE~7L3J$k=)en9Z1#hH^3
zY-^WNsn_fGr@o84T&Jy|x;Y}PQ6~+3dy;ZM$Jjw5Onry87fAi68QZIsJ&v681Uu+1
zm|NVlt<-cF_I^ri8x<Xe#H(vU4;4MG)U2%8>}=}<9G*b<k}L4xn}RR}l4UGa_T+zx
z5gUWD{Wq*>B6(ViTN~*2w`qdjl?seJ=Jt(YYImzjW!vZrxBkw=SDX_^K5(#gw!%t|
zuTZ+W(FKF|dh{%DJ_u_q)f-4u5PBrZ@&^g}DHv!*XNdkV$&MZ)W^Y`rFc~2q_fAR7
zNN`^pJW~MO2>m>^>G2a7KslIS1>luQIUp<Ri?c^jnz9W<B*6FY)AYCdjf`<<bz80O
z<u#<A;Ip^s&-Q+8RJ}w(Uj>{5ov9KQebo&na+<LUd<b}|<(Ga9ov<8K8<}b|pAAV~
z<bDG`{2DBEp}~P43b%1zGS_3lj4v~Ig{RY^)p4m=s1|{L@tL$x=<y@QL(_$pj0J>L
z@SUw5BV!=1CfGn;%^$oG_sQ({{d4ZQ=^R4ziq%3DWdM`*ySIV;Ug&nQ-4f<*^Y(XN
zPd+F-!p5PuB(4e*NLE(HCgnKJn3T!c-)0&t?L(UWqW28i??!4I0Kvx{-~ruX+#3u#
ztj1P<kv^+8V0;<hzjVns-Ofnfn8PU)uB4c>SE+>wGKr^ZbZ=#>bypR<Se8N6mzh}o
z7!BCGT<>A(r|E-|rjP5=241q0%j=;MPvy0R%LwTEh`x6Fu5)r?IE;y!=(lMP<<=wL
zX#@fgy$I|y72L05Sym7~w%nn=N$l}`6}KdII?FJM3e!U$sO46N6)bzW=1ILaJAQm(
z42>ixHDi-?+`)aCNyW;d`HPfA*Af1ulqJmH@ZB4K=H%TBczqaFbG35KD|_d-EmaAJ
z&@*HNdY?h!fy)nP!-4nQ+whMXy?sW?K1BH_SF0(10J%I_H><?+2X%6efVvGw#j&s=
z9X~bFAV=}jUrX$g-tSu<pw7%NHi0jJcF2K8g<(PfE6ZrI^4hJH4Wzw^J;su}T0bAm
ze{MAxqQBBXvm6>FMy6~d2guAVjkv6AEy|ZFNG%+er;VDbS2sIdStH?ZLdQF&=;LcG
z^cGiE5T@H(SzHs}y*x)g-~AzlH`Yh1bR)j37V2lBmOJ2I$O9wqKlv#)Ui39WTpk9T
zX(~jCOHK=jOK#TqkgXP~@FcFh+z2pa+mH66&++yj;8m0@R_Y;)Gr5#o&wW+SuCwwc
z(N^_3l-G<t<>;j1{1bXj(rc8%hxPl@=XYeT1paoY6d(C!Nh~fzscGZqF}D8p)75|R
z>7S11*A&@D_1?^XpF4YfvQr&GzYTTjP3AjauJULSF?G;};;nZJy$ISq{3c=zzDQ$=
z!Ox7UyN`=0jw@20c2#Rs3~}6n_ieo?;b#3|f`pBU#*RCHiLBfJVrX!O>3>12K#`<D
z){RI}%>_iIFb&ogJ6r2ICc7+&Uj!b$9kegJ^7fDWe7TAyEX91LTvI$!HIWfU=rDhW
zU@1OHj_q<X`LY+-9@ObIkuS4?y`kB`W$S(IcCNz*+gWaHUhmk=GESA*%vtYRlr>cS
z++L>7>$K9n#14YqO?L^R2d_#0JxMXKF+o#4KK4)<ac8+ot%#@ft|MoqCGJj(lcip*
z{JE{wMWxe;uVSs;T1MQW+|yugU9TsC4I!5FTwG)L>E1edkjsg?0g01j_KeKYpHcPK
z+Hu?eg|ZH6U1BZ8yEqz?(s+kN+v$Re2G8pLK_8wapi4bh&tz1j@8s~Tw`&?reX+)~
z68o99&I=oAY1IybEUAqQl|%`K@vGy&1%wQoA~dbm`7v9XrY`C+?tY7ox7l3mEp~6V
zdIC>kQ0(|=+Ve4uNwXSHJ5|pw^?gB#Gm70LdgJY%r0ux4y1`IT8#fW$R=K3i$@8*4
z);1Sd`%=C;{U?g%R9z26D_DenfJ#%{$j8SrnRu}IoLLj?Ur+3(#Pu1$+oEG14E^1{
z=<!+9L@3rPxmu>80;32!IirW+Th10C$i$b_c8AwQF!<m8=O0!ClDU|A4b~Z3oSN>F
zJFv~lCA1CGwYWx+JG9^2s<_+&<wObajF;;@-T5-wFe|+Rs`La1wq0F8;h)ZiQU*%|
zzO(w;TMsKt|12PVwhr>z_V_(@ETS(^KC6<ZI5(l+sZ*5Cv#?av!5NIv(Bz{GWiRLY
zP_i=BvYp&|4QoCnXQe!#*ZabnM}H4i!wO0fGB+rbVP8|4L&$9~ykYwm&ma!pVjI0U
z7FX5)b1=y<_8>jN3JOxpD`{@ndvg|U{3mZLz(X5oCs1j^Ko?De))x1bsszVHx+fS*
zMm>V*z9{=|Y~|9|Io_W}?ZvQ=D^-g{IeW#7N~u_yJ#h`SnmZd(4sso~!j^ggt2c1H
zYJM%rN0FQ_XgpJ+BYs28!0~UFWC$wDiKd|OC){@agcfSzUKVGUp`ZKz$=kCBs}WjL
zM;V2r5OXK@x)w115MN8}hQ94x4Jyrgwo%Y|L)0M|s7KDnAACtx$35njlLAN!{BbpK
zwUu_D0~-8eCR+=Gs2<izkVhn<$;tEQYrb&%>xggVZ>(%mXOuY}xzCLueY9T67aL7+
zCKQ^=Q+rZ>H_#YL(PAiP&({~a$5qNSArq9Ev5<+y8RlOyh@mrPF<F<4A+kg$^-$Y<
z<eLqrFmP9cHFY1?vLAh|Y&lD;qdBMF`%@l`A$K#1P<^LZQ8*#tArc8mgFiffIY`6y
zic7!UVE}@^!LQYtT-`-;1Y<N0NI1pt`+@7&H$6YM!N?%698JU1T18}cwvku!=UnMq
z;!#t^7f%jPiF)nqFrFm!raNtlx5`pk8|mIJSNJwT$W`%hi%qq;ve-Ir*uM2YMeiLI
zmoPrX2@+Y{!ukfiDl=qt$h3)<8wRRPXe&+FfRS&h&w2Zp%@m~wVWVV9LQRf0iGCw{
zx!>2bHlN96YuSS0&7=*9S8r%uwEf*mH_@6&Y+fad09DjN6>(B8FiHI`kSdjLExJy$
zNqtFGh3O-7A8<pd3|wn$=nqW0^+_Kum9uE=Sqd6wYqh|}okVY-ZE{#ll%fjQ?3+m1
zy{q)szOSkn2qO=tZVPsS*7d+8q>sJ$bj%({*F9cUMdRCC1!ZE2Pcc@Or<UiHCmq>w
z2G`v8>mzDrrd#g~RDgDSefvAP*U34iCd)#3FJqERD_jsWhWWqHz5+2u6^m1`{ot|i
zPb>q_S?@rpmB3X)Z@0cy`42R`F%McUK|n1M3XryZ*%b~`Ttg8Z{?5&L1;h-k-;cT@
z5;IGFWg=w;R^SOu>+|E($czzp3GDnCRL~TNVQlK%x5=3RC9cDK0W~h`d8XA_Io#gp
zqxI2^4LP@R*5^N@<Tv~Jon60<m?Y%OLz3e&Gsda&5-+uONlpyjw)one>w>ZCee0`j
z%LH`${q+A%+(7WA_6<0q9x!vP%G~w$Rn9s)1a@wk+;>D4FWj`cQ}pcv7~IgBieqhl
z0(fPF$>{ewRB`gx^=srDwOU*23{$kV0;c{?&Qsj;$ddp-qk5N0)l?vk2>1i`tCb&U
zrrHy!vB-s`g)Vka;z#48tMcUu7?cc6Q5L)cdn9|k{Q^(tuLsR~p^Q_kLVBpaQ2$U$
z39UKUo3GK|?S8k%PvIZT*R#!RvFfSwwD4&MI7^WFAY~jOgXAE}K*lGuB)_MA)jccy
zP_s~}l<N^nU1u6n&|pseuBbeJ%D4wjEL}!uEVH=S?)44{q!XSg&w6~I9!aUuj2cku
zr2a%^Q9}Mzi;@7>uIumY-FD-fL7Y-pu2pk+T_ceqg7fBTQsd*Q3?d+6Osln~z09u=
zS)$S?I>F0yF8=lxX}xYXt>a3R!+JC_5eO1puu+{GP~;F=;U#FEGzjF~#kq;2R?!8e
z#0?!U^tT@zzW7td8!YMjb=Vi7gTRmDP+pb9h}4O|le*xP@q6sX<m1{5NsLeIEc{BP
zF<29`gfx02n4e=$<`3$5Ox-`g8zl}wuNJcOgt`HajlVBk`nVv%39>|UMs|MJ>5!<+
zj+#=LJP>`-*CgXp->=s!eNy3q&||229NNd*Ht`YV>R=OZA4@b>Na>P6%<(R6WBYg;
zyK?&HJ${mhIg%|mD|rB6*0aYpc`DkG<w{1fE6IuYC4zLlKxoh4=(pdmYYHS`pt(c!
z51eNh9lAD-+4sHUo{T}Q|6DFpZJ7Rm9QI^z^ncX*9$g>~D$%5$-zS7d=%M_N{q2Ub
zX}#ozSL}5Lctxx))9{MXF_A=GG5ReIRi7@JJ^Zh<LEtY2#Vgq{h{(gMb2ve=1&&+^
ztLRC?OMim&@r?9UI7IQB)XISZR8xf?(sSJZE3F?Og6&|PLy_oDGtMJL4mBTmLXRmu
z=wsg+Cc{QwnvsmV(QkJsjf!j+zPaniD$LZ8JOtoKz~m612>uxzyVPG_p;E4tv!$G>
z?L;-uLj$4CW)KnRY@(;HCdnbBIY9*gYhh?$@5}&iimh2~c+==(7>Nc(zuloUVC3}n
zDNm<Ct&?0Ki}npVL}8%T2|*$nRn8hxTd!-fQQxOv<^@ioUnV_W(&s4kWf~8(F#zKQ
z0GQZ=!I%M2oXxya@A32x!L^H}TrsPA&Q2KDeu<vf?r$l3S>f6p1ZmSe2Hdn{W0O+%
z9K=G~>;1Lt0fb^fE>xv(oFG%)Yt)mwkmd)Ntl^b+p7diE4(Uk(#m`H*nTW~YxfLv?
zvU`uhR5mx(8Qm+qMC_UFZPuXj1CW<jQPhwQ6NM<~d~FNsSw8gKKlS#s9+VsPQZomd
z6_)c_`9WfIcB&-AJfL~qjXqy=IgIkPtnLnxk*|_!L8hWhVwkBb197~yMl(|_X?vK@
z@qmRnxkDsBl<`}WKixqA<X~gg@B2Afmyjhcr10Z;Jj?RgFY@$Ev_LJDOCi)|&W~q_
z+OK*<T^`}(f}Z*g?;L~7D=4v1$~RP=QCTkLAn6D=DlhpL$J~^c=k0ss-~vj>JDddl
zUQ}__IsSINmwPIIaB~A;JZPJ9Wuvpc@+hEHV6qw}W(Rbo{T!&<A<kfsIaG3<7j^_x
zSh%r0Z~b?r&p+bzb`fJg9Vo$U&ieg-?9oM74eIrLAuQ>ZStfd)^QGIE&;)rI_Yn~j
zdi#mz@CT(DH~6f4%Ij2p&TD$^saLA_UDOm+lW_R72E0`Fca3rluf+-NM_VQe;qJc!
z@qmx%=caQ*;sG9<m_BldY@L)cqN2h-qUW~nV;wO$E3vFAMkdDlpJVaHr!`f@&~f)4
zJRDgfNTIn)vaNvGo$Jmo`gmWhnqsXIX3<ED$Dg#=0UtSuwF1jXJ?7Whi-KZUF61hq
z9QR@dX}9a0>u537UhHknp2D{jCN95MHyw{jAFtPHa3M9T!2+a0AfFqXcm56DnJS{a
zakE^gRyD9XL7Vp;z4w2_n4<FnDGOV)82;4nDEy!GzxptIFbs^>=(1Pvx51wPbE2-{
z)@oa|*%KCPuiJd7<CE#5RfJE}5DJ9+byg~N^Pk>#*Ug}{Pf%^v@`Y-oT%42hr<(P?
zea?FxYNMgvZK+g^)b8_f<Vgfg=%*uRra&N5Baf!&b6OhT<JWitNhe|4gUI3C@21Y6
z?9)X_7m_pW!2Dik3sG2Lv<CN7anfS(iz%AQ>V2DUG1gjP{yn4^fv{H)wsmFY@|D)3
z?Tt>mH*kwbGKjb%Py2+v$JAdW@w74Wu<uIc?&m1u-(r}WZBwvq+{0Uad+TU1%7^uQ
zRS2p8g`ogpj(^6^*#7FlI2?%8MJ#R{iyv2ugRzmo;K#kwumxa_%$xKcr?tEUrj>|>
zB+I}Nal7G?m^5d6x-abGwfS7VgocPp)lvrtyYXQ?_T6!Ox}%H6<Xtd?IQqSY?E@XU
z_vyKuRCVkjc^d5-n@R(<a_VozHqrW+)KEvxpp<=CUf5cdI?9GuZ9nK_i1eJPma3Ut
zq3J2Ajycf~r0z&1ia+=%SyFOTC6?dn#qaau01@_3D@Rd1qkMcWY**>U1<}_|2R0@r
zdQ`^(oI%cdU0O?&+W#MW-vJ+0vHd@rSg0Bm6%=(vPz1#d9Sdv<DWt7{fEdk&6bOW5
zO##HVc6^Giz3bYsujMIEdARcIjkRNW8kMJ5p02&i|9fWcxpy|~Uclrg@BjJyuClXt
zznQuB%$zyr%$YMY_2^1oM83;8Wu+sUaJU4Gwd5Aw#!r;Ph?g_=W0gl!(28V&yjVvh
zcWK3e(~XO1Ifh&;iT57Ka_s`1!=uAdb1+f5=~ghbKNks99s`6D_rRZAl2wwQ4gE`G
zwfD71Jpi+m+7^!$;}hp#@|tRD%<-6iyqpV12y%TzJ^uE2-V+;I6KiGQPOGU|fc?h)
z>Ymt!;Miho%+}wrwT0PnKS`lZ+!A|hU#-*W)ON&%xRV1R=A8|R{iN8Jn_F7yQ>#s^
zE~xs69NkUxn(<LRhH5b`7=>Ws!HBQ1d@8|m%|^*VjG3=6J0}mvEK2U|ptDFy1}QD%
zf?AeW;Q<ML1j)O#2EYG&t!ATU;}Gw{;wjiRM%hf#Dzbc0QmD(hdPTpKJhDScE2;fN
zwwL<T4C6Tkc^ci>*rTwtaB^-@p?VHfcUD#oeMpHWN6&K5C`ag%r8uGwS>ZXd+&rV)
zp_TgkXL+aO!@*F5z%H{iDcxk#S+<<C`DiF$+6um-w#Fy9<w~Wi6cq1&@jmK>Y}43f
ze`$W>FLX_ND`<;_nZ5im=Qd3GPLTA~LJ3ziKnu(0SK3fzli5Clq$Evd8Rq)hqSP(6
zwI!t{DO=7L)BJG_{wR0m=uvXfJ=$%x(SGsrcKnz$4r*)P2(%@d>swnuYLblg+-%>7
zQ?>qHP>41BQ+zqRPf#b0eOYd=L<F|EuAszQl2@EVrzlG?pd=y*1SPkoOMzm^ZJ(y|
zbFkqhJPXt0SPr9J_78h(&kQ3mw%NI~E#^RTu&1-7HkZb}a{n>PCqipq$@?9^&Mv(0
z^=y^{#<@Ky#|#}FFr+SkMyOMmpN}=>B9%LHrdNrLE!hthD!O7OjhFXES?D4ne!9`t
zQ%BNZTkQvkIhc`#J?7nR)3~T4m7gMfZfir0>{|XW3_{pfptpTuj8t+`{$h;OBBM_I
z=V|?QGUE91Cr{3soTv0?>LG@yWu<Lk&0R?aEBhU93X&_eI&Xz&j^}^wZ#~yDp#W!9
z<>&ZHs0Y+H(eTNO_GX#l&(U=~Vu$iD)tZ-G+}USl^7vNhw%{0Sep8Y&#aKHfZ5?_!
zuD|dr79E+0Z^_2QN@>1shgim$9J|TNk;c=eH6%sV82U__iR$DXqhI+(rSkh=ZJVtx
zJBema(IZl8MCR`;FUwwmC|@?Wx42$w?;NZ*oKjMflUJq&t+MJQo2j;-+OiCE%}Sk5
zh^%s{cH}qtho+B${HLf=k#T^u-z%#YR@XP+p5!e39y*)l&1ktd0BtDc^^VQ<0^@g$
z4%OZ@yBHhe=RxC@=4pYj(zcZkm7ZwH0P;7hk*y_pvMWi{>QporH<sJo!{g$t>gpy$
z{*~3*Mz-E$<ZC;FeU@9Z7u{cI=VWp$)oyfZD{ir~A-{bqjd>w<qhNJY4VEs@S`Mu0
zsHh4c$T4@u;q{dZ=Tui#RF5AsVN~VFan+fXmE)^CBj?nN8dEiXY-Q%S>QN&{SB;+N
z^%^<~lLezj@{$L0I;r{u>==QCQ>ewdr4X)$7sHH;WpA6F+nc-9MN*8{R=l#|-+h_e
z`#-YXq{*oE)vs<$>c`yrrs}%x4JAIupeLaAVAZ2C<%zTvR^TMg4lq}1+XPsee=~Em
zan=L($;ce7Ph!1t$&`}p$)#o5^n)B5%0aj6l2R;Kf?0MyHB=-SB8QLG^ni@Xt{@q3
zn?aNN6T|Mnc!c8l$q&@JkY=fBaas{MhU#%ZC3qKdwu`I=+S3cxlbS2Io_VQ*dyH=N
zpdpzoNU{d77yHw;Aa*mk5tQsfn`iGWFDsSyqA49Kh&_3EbRdu^Q`C!YGM|rfjCeV+
zD`*@adRzKlQ?CU>WJ{7W6U`w6t)oq{KrDGK^v@A^E*>k!*K2)eTn>&9&6(^|%1nki
zNcCIoHT99ZRLX4LZ^oLiB0E;i#q%Cs^7Nli4Ei#9OSv{_u+*&bzz`D5bkK_#o7rfH
zY;R%8<9+{<)Jq%+Z+#J|xPhWFc;;#i(|Met6Z?~F;-T33CvTpoJ8qFlo~B`!Iqw_L
z=iWw_78YPUj{(A%hML7*;+csCt^V{R{%{-ylB{>)&>o!Ys<?i>k-u${jPF9!s@#eZ
zvQp)2AN*^mU}HND6)R%=W-9kuIPektik(AFAib{EMu94}@uLZAa7*$F5iQ_Tt3lNi
zF(?~m$fe*mTQsgr?pD%<m00qSa%C3&ObP)z{m^Oh*H&cZV*jqKd}%NX$q$lS0eoUk
zL_1F<V2#!JKo$HQ`=~vi%Xu^GR)XfNsGc(y*tbSm-Vs|NBPxmpdnSNoI;WSVcIs?>
zr?nLq6-8?7lMR|dx`+?b{8?q*+~WKx7)=&|Fk?_C2Q$(*QBE!8=JrxvDudd<w@$@=
z4aT0-H4W9?88QY;xl7b6n%vl)A|<mEFtlT>QAX%6@-a<<-;h>zHY}<`fSNRE7F9OY
z(KH_M2spN4ru;DbDm6B3X;;?*RUr4g!X6*$4=MCieS=v-{vmqjb;oM@275^47Z<}3
zfIu`Nc+yz<l(PiVM3ZEzvGXX2kMU9&%zNQ4=$#S4Vr+Sg$weFrJ{b$0<-)z`jSFgM
zcqd*pXbdz;{@UEWpxolg)q67G1~I*P2HNuCQZbOeH)xYlpZ+5?e?)1CcXB~?R#};G
zPFuTaCRv?wU@AqP+&tA9m~t4S{3~l5EvvuTOZ7<OXX3X~IWJE2?vp#~u^pa)iEq<4
zi+%G85eSMcecQWjWZB8a$I|eYs5MfS?<f6I$}FcB;r0)1I%gcvSf8hh&G(LE%JuPe
zV@G54GuCH6ZO{|EL-K{Ov@V%UF(h#kWt&_H*fPY{7M6+~NO8-}vDi26-I@FvlPct%
z^H_LT+gQ=m*w}(a|2TxkI|?e(bZZ#DWtry@v<0_lOd~gCO3mw?rm^IBhD>Dg1ryIb
z#5_l*zvp51%*qxSt48)SU=i=B$rX5G3bXR2Og7F5mpmkgdy?f<C;-V530RUwdSxWP
z%g`~?Uson&k9n|wm!5Z=@m#Ndre$`KH?OduB&R4#`BNnuYknOnM|rHI(@(Oxl;_r{
zl$}-F*CJyi&(<rB6=G+jK0-f|9<7{%kP|cZ#<MlCH%WN8o85vk_J(E2ylhP`VvRL+
zqsD1HdCDg!+f7!StS)Q7E-PHNV7sQZ2K%zAm5if?+~25A@tL$s>KYb7YhZV+mgdHW
z3hV^l*ih40i@#(2<=5x+v+-V&%Zl>yC@PZqsh!YO4N9nd2a=?-jb}!FRJK!1eGLv!
zG*xPQ^H<J`Y}VezP=t(lvp-<6%ap~X@TnI23bP7wRooGadW+#LfopXK$)571<!_RY
zWyP5tqm(;_*Bm>bs>F7pLY+v77|EKd1r>ENKB`t8fWl)3?>5QC4#_t<z}SKI;*=xi
z8AiWz=V-bHaRxa>`6a%xJay8pY<%f1mb@Touy{sVRFWD+KU&1HK{F2DN*fe5jE%-f
zqV)f|#@OP*QfUl1U}Xzb#a<EZLx)&(>A}{QMOoQCoB{8xs;|R|k)r~24HalROzD)U
zJr^iXcwddbaGchZBH!eaVii9lnM84lT&*m>A_`+~_WN$zmE)_#(SN6DC<n$=G*%^D
z7ygW50@|MmR=e0Z6b!qrSn({L(d}bjH?s%b7BkV7*f3jMm>oyTkQS1|M3)$)Vyob+
zuV|@nh80tXT~aVwoKq?HEn-_I;!fZ{#H40TF2j5rNhIm9l^t9SndChprC6u7$@4=i
z5Z?z=5K&TOW6+~#X?sW0Su$DjBpEA4(XYqaRM*X|gO699vkSjhOXCuXi7aFvEYnk*
zu!f+(H)V?4WwENUd7hV^$z!-+S`v8(p*PEXgg#M>g>HaYCbAA|n=RLi)yf0mjjf*a
z{U@dx{1r0JT9#us70r%%GtQpld3&Zze=PZOAw%$7>Dwls5s$56UrM>D&0EygSI$i)
z8UNDoDn;<o)|a(eMg&b`4Sw+Kqsc|+`uzOK+4)(;S>8qj#nJ|~v>9nd<zftey~rkQ
zLh8S5&r7|olwT*V_S(*npWdUCjzX-*Cf<*&9b9ZlFHd4BCRbvqDwjqomb^?_oZ&UM
zbD5zO<ut#^;Ny%Jw`k0QBY<hG&t^w0N#843H%Qtg&3O(y3>|~y6!C(4lsSKEOcGH%
zwEgZxgN(es%hh_G_Iq(-`JCxb^Ia`tKH-4DG#YknBR*Ws`L}5O_10=ca7+hPDq`T0
zRV!I1QWp^YM8`wAuPC#)EGNIL6pZ90jAeP`Hc5YFHSJdi&B*#8zF&fV$SIvtmY1cx
zOx9RHsRw28qExc+sm-FNksO^g$)mreHMgPmJuwXORErSVKjYb7dk^d@UYwVOfVC;g
zPE9scuyf6{8%jz?nfy&|r)<V3WSp*zg|R*=*H_@nF3D13lunGvV?RvBiR6bfrg#l6
zy|#6H1Lj7X>cE-Imw_f3^Vr(Jvq;I*#9t6(N!fDCd$kQ)s(t>rPkVmlK7CX}U1LMp
zocVA#+D2ul{T7LDqbKS*1rFb=oYF$<2#PAm$t%P**K<y2scD`xrVdLI`6o)};kRts
zn6Y`%=t*O(n8p>F%~IHmeWdEDbKvgr(cy1o*GL&uDeZ!srWR~9h3(bhGbm_mTwsnv
z-EldmS5+CPtg34{0k5JMfAfJ54e&5&(G+slMV)iX<M<%j-5iHvZay1}w9ATe+aK$Y
z(kCc~&yvU6bqs6JFPWd87bwvBTLCtW!`5ttML2+q48u<3eU?${bo*{p$&}*UJRF|p
ztvJEs6_*?JA2?-;^i-ZyQ;AIc7YrO-Xesl+>rGTnBaQd+mCJQ5#{L58G>2BGk(Qc;
z;E_r!Rad))65qaQ<O%K3e!LODxu<o_=m*Jq@z%dT)Js<yd)%kPt=y+`>zV`gl~pw~
z`(fXyvr#8hH%rnro-6Yf`3ilxr8#QP7i%mczbTDVNX)3#Fq%9ve~Wk|Ckc;itpZP~
zd=ojunhW+EV)Wl}FfMB3(TQH@JPwO9_Yetws_7hTBVRDZhb1*dYEK2ryJUIaWXEpT
zr{&+Va|&q@)sy@~Yv)Le<7k{r^<J=_C0jhBCr>WTE6AdWY7ayt{`1n`%r^KouJ)MP
z>|FEY%{tnwGamRoo=uorF32g(&4yQq-d*~jTIof&&v_4#d{*5!wT4Dsn5b%On1*9Q
z6FF^~bnLTC3m>8J7xX#&GYC4xmdu?j)8-rXI`2BIEwR^UL0(>IG4GEdJ!;aUvzd6z
zcB_V@m8H&Ur21HDJnKq*Us0SrSy)_FSe9*^ZzX+pQus^GP*a~ov=sjGO_*CGrhMyz
zbL5E`?4``fryS}oj~;FMNc)#-bmG}%rIQP2BXC)-l0^9kX{E_mk>$(xksqo@OIJQ#
zBU?VkoF$+;Sw^dTVS4Z$2F*UTr#tj<?wq-D1-}*V>7T}OC<jiDLV2qAQ4P5@I9^&E
zi9)fJY7*B=N7&>UW&Zq<MT;k=*gH8ZCojLGG}~LD9;4Jg+<9ZB$t4ey#<VmxP8w6+
z*f3YF=4T&*`w<$uR#arS*40<bHJr-4Q7b`}zk=#;gInu+nD;2l%PB1_rPJ-Pslwcv
z2D11jO{l7`Y;K-30TDhps|#D%PMY9FUY5CjtSg3{jdk^M|I011qqt9mrfPixb~QvU
zhUR4|a;X#bJlm|X9owzbsRE^)G5Su__gicArW$dZW2tY!A7lfD+*|3_wv8!I;`d8E
zd6atKz4g|C9lf*Iv(3J@s5T$%8CO<NG&#=)jg*^Jl9dmO(6nhX{%r5NYM=?mdW5Ae
zT$tRh+1hqWZPjdTNp>}0EDq#xtXujyCqd^m!?Le2^*%c*D@u(s&ZHC57`Pc52sV4^
zbXY4UO1L)l*>CaCYAeHwy2MwrS%1`4zBDR}<U94XK60*_Jjil9hR{r5#u^09lDsyr
zvUzjo^(E<J$-Qoy<*h9)DK&4A(IX?(Z!>5Nd~5K78NErdoZce5%$DzvGS~xe4v$xu
zE3sE~%BZ=`l<x7GXXoB&yl3QADYs>S;a@##CQ(HH1);?xw)dqQ{griE_-;$5V$bA4
zFUGF9xp^2)k_jO#5cwf3VrfZRGn<x)z4^5zTsPvL&DRa$$><bNV@PIB7NnNxoj4ky
z`Rox!JH|H3`FZjfVUC{M9NM}T98*zUFONAeWAuZc8T<+BLi<Y!fWbyRb`qwO+BfMM
z7*8f0s7qdKq6?xzT)9%S+e#4smz$H5U+VLgV5tv$IN6O$W_s!Gm`4Ko-gVe&DYvXN
zXG(Uq8fQuFkggPIAWM^5TIrTCE4f4doit&k*(^UK1F7k9df-H(-u=HP*l3Bv6lsgX
z43fjb%6bI8tFa*(?l>dAH-p-3lI0FW-B-6lx1v)aWPNUZ;~Zo}rN~JoQy3%*XP<=$
z0QFbk3m$v-*w^Yap6p_8DbAxR&MTxYquHS_KIb)7w>L!Dc7AqGt&E&(oP}1JQ<9fQ
z-s1eMnt7>@o>L~dwYNaVme`2QUrDrQY8z@ZE|D!SE47F>obPD+>y5SxoFR2pk{)E&
ze>z0~B<(#ov0hHEvhOWpf!23M6->#_%_%6uUXV3&yy7c^hWPedVfS|Ox`QrhG-Ck*
z&xeFAl=C4qO--~?+=_1sTw}~7)!<MbIC+hUb-01+@K@HpC2ixZzL1IiLQ62H!*NwA
zhBMiGg%u?vrAmSeM~WCZ{*{VK4$I^p%=OYUr!t=zXBby5sxh~BNNq%DorL#Uqm93D
zxCQA8w*6!J8ivfg{L;MK(lYXx<R~A&Y~$InucYrAXQ|1EbjTh2&0lnX)1Zrjut+wM
z9oV)=?)RqFyVcj!ZW=Bi!yJ>IrOo~#cdl$t?N9^ij>cSl6Hbq*=EZZGj>ys4Fuw?A
zwP3fG5~B?}acoTekm!s}kTHq~QN+PNSkS|ZGN_G-4oYJ>UyUoyFDk>KqNr+kW=89u
zUi>ZVj=&b}3tusF3tV=rV2DM`Il>Jt&4&P&Wm!=coKNzlBv(tls64i_=^eB1a-=he
zX7@X+7pKEpUJt%0ZET>a-7I68H;JY+wq}*@aFbC^;F>M+`xb6y3VZ97im7ThHA=z9
zauR!u@s6Qiq|aXl56hKXm8hdld>>o?3b5vro7SDE&c>#x_KMipgGW_1G}qDMH4K!z
zlQJhwvM8P1X_Th6n76*-HmAfXBC%7Smuvu&R7EQT_y5ZZrBzVM1|rYL%Leaz4sU1E
z*-mq9Ipd}tw0Ax`KwO!=3E$u4oF9#&svDbOCNwmfv_>ay4XsJM3Yu!xrOM`M-SV<F
z$NEGo+W_w+*Z@9XS*|Z%?sSbXX!^ThXk$uagDidNnJ_s!8ykxi7I+b#P&c=s26OUW
zE6z>iwV(e?6>quq?TC8n)Lv^7&>%ez<cBBvH}pu*gT>fVsVpmB&0tAID18k|5z1MP
z0<XzW!7>^9A&sYs#^&024b|43B@1l!EJ?a{Z)?X6wl%i3h1s)~TDE7-;|0G_YwmKB
z41bTDoG;@fD^w_iId<Q0gEd~s#C%ghPF_KNS)Q72lH+ta{+6{Z%`{p0a_p`u-x}3h
zlcH8Mll;SG@G9G7zGs!qZ!B!0PKLeaX%}rP#?h_EIF@>|b8$#lNm;QL;s}#DNB*O3
zV8&gw{YR}!X~tHVh@v(3PzkphyfjWKQGE*)F~{JypRpOW854rN2z|M}tRlq4O3TX{
zMJQ*4>H4yK7}kWGtR*?h;81?{tN8T3k9|<{3Ja&?VfRHkp%LCA>eob$ITyI(1nr%$
z91+9+;_L!re?<8NS^1Xx#B#V<BOv+4=DcId2|;==kA2*aDL%q_aiwJ2ul|^|S?d;d
zsWd6gH7d{QYx=Wuyafd%rNvmqE$eqWRj8cElmj!#Y?2m9nxy3fyx{YO{tJ)X5}mNM
zT`jdn*xHipJFTi0j$QHpOVYBquDYh8p%q*9vdNd)nB8*4WGjkT7i@WPsp!g4E-*<L
z>#s;c{6ThhURGgFsoH2%w((N5r|HjoYm;#cre;$QRt&Lc#(BH1ZLj~RpW9i<TTXLo
zuIRk_V;c`$(Cqtd1zO+F%lDQQ6z5GY!oFkFRf_2Y0?=^4m(VvAzeC@+v**g+Y1cFB
zS1HM)pw=V=nnKD@dj6McAF3*Os0;4d$2;pqT~B0T&*&)y#YIXV%R*66#yeTF08m6(
zSu*BAYLcmRE9H@lv5^wY`ePc&S~g+iROw?-Ui1psgpEyR|Bt*T{bx37W4FF-x~QvA
z)VW+A%ky&aY-#(dv(PJQ>F5O07qD`>1RE$9GBdk0SH*D2=987D)Ua%8R3ZClM7|dP
zO759CHFL3M$~f0Wu3%9+Q)qSWK3wWgY;{FP{>ZI*Exy>_*k8D5ZWXl?+q28CSpw@#
zoXb9?q%05NhF;pc+Dm^&dY{sPD!#;UuB&-na<{kQfb=HgZ+x$6JO)-T#6EyICAn%N
z&18N)yHG8uKV)oA8L^$^@xy{KT=NZG;@^t1#*Zo}ES)wzt2AeFMFs61j)gFEyb}(8
zX$R0L<VShvB+6NG!kQlVf7k!j!2i|2|JA_%)xiHu4Q#}<xM!vd%N4}6uDvd}&b6`?
z+kT2OKf;=byVJ!={GPi5dDhjn8<IEDX>3$|HvdL>gBUwv$ST~z=cnH%UUM<I^l|Md
z&R1W=ETr_e`jvBNIXUXp$GjS>>^!)7<mmAuGe<PenJ?^7Du>F8FBjqgr0xu#pYB&&
zf9w%RaN$6J9_m|kJF=@1uj)g~D?ORz6^k327L<=IZ!Ryy&Sy;vYpUxoZBV|b3Xz!g
z&E@rVbE+1$jA*E&L+4>{&9BJJoG^aO*vv7bGRyIj)#a57tH+KmuUSGnz121Fi~E`y
z=OVn)O@XA%?x9P@k3F!wq^_!|vAMCf#XY008ME!~X)Uer$d!-uWKJlbOi#yJ;^vz2
z89C+C<-<#+;cMpT5hEvz80E<vHHzM*d<mYW-l}>8Qb`oi?Z24fnN&Sci@hMKAD5sQ
zEjH|+zRl_>L_hV_{OsI%Xl<#h$3$lLRD<M);MKIIN!0^bRRj;-|0zZ6K#{?$j1=Zr
z!qvI;Fc;x{tpQrp(@j+&>muV?)di?;Yy)baP22A@MfCo{O-zG}7Or!($RF_0xpjeE
zVdi1{(oGdXWV%rg5CKv~Y>V`!;g>##1lK6h->8RV@~Ly{0UMGos#u5sfNrV@B`-aw
z3+fld6I3V5_j&YdstF<bi-BEM7c^InJp{V3Hi%TO#uwY;{*c*ijZ_n;oi5}H8uNB%
zO(?$bX?#Iy)8dQ$y09*=n`Jjv1@VMms|Tn{tsV{$gS)JM7;XyXCg@gq5kP&A-AD4G
z7t-o=w;QT+n1D-6Udy0B=x_9^b7f~sLlyR8YG@5~Yh6S%-k?f2rhMr8iso^qK6PG?
zU?a$G?jupH9{QjHMr03%^-0%WV!Xi<KHM2!B|;ya%M&R>j=PmdVp`qw1<h97>|@Fg
z=j*1r##}Aa(9+ac-#t}A?cav_AbmpegN7lm`37Vm!8J&b+@Pxs>F(;Q`PsR=Qe7j@
zfUJ-L6;n(y5<*5uH+N6f$iCsfPKY6(nCfOnq`S{w`cG8>Bf3zY81^}$En8@h*2Zoc
z#DZ|*mk{cN`6UDQ7QgIi+NTBhLubct`c7Bf!yr@_VXZD`62YpAgU!0|;}1y&>sKfD
z9b?z8YHY65eRUB*T~HsPzOpmYp^w}$MbSK1V7oPW1u(dCR*o3{4fK`f1uc!;WsMMT
zcy6Ng7OFmWK|1!A2bal85M#v8^ar>|zB=pgp?S1sNR95{i;Wu<o#e-)Z+x$Q9WK69
zU!;R$SN?9Ko!dvOr8G_5q)@2I<KPMQa}d2pPg#4SB6nX=PR2W~m2d<(D=+4@RyI|4
zxBE-#lK5>xTn=Xk$qX8wT>tx;mt`f8)<xf-Yb8>WEBe*ByipZst*FNSCEe3Uh%W+n
zS#}1=$KZ=|4gb8y)FaN1TUxP2TK5|nEF+T3jNQfE1|$58)aWwCFP%MpfseRKF7@di
z#sF2s8=(z-v41uC2<C1Oo~K>Ah&cTLt}F46{Ks^ir;<({%PE;by@XCU@2(0VawDh@
z>F+>&B+eNP5Lk98FTFn2IanV{YUfJH(cN_thWt1bbdnt16X}9a-Z(;$ohh)CR9<e#
zQDd4({eaKTm7{Z;jU~n1#U8T1c<!O~&#J!+G%2MoJDKxKG2C%~F<7RP>jJZmFuUe<
zqpcA@J&XaJ#1nfV{j4M+<D7)pRcvF}<10`J&gxdk&?dQeUbpdty*@ci5HF;<iY8Aj
zom@O><cR9}dYbM|HfuZ+hio@4Zgv;J&@RvPlow+TIMXx2Gh(D?)adaeJmswm<(%+>
znx=-DdX&YJ!gwh0p8G)|>d+3<PBce9Futf*z0V9W+UUDWkpAUy!lJ6C)`k`w0HM#4
zSBx7oVFKPSah4p@+f~@#SndnZWesM&U*dduWTnNwZdAxkPq{x*^>UObH|izSMfGBi
z9uQ{Gh3=OmHDlNW|4{J~#54P%Qa-JE2D|pql`qyA1F3nK9Qn&WfAh(k=Nb6wtP@hY
zlW9Ob^{40>A$~$ibu$R*1#=I&90{&6(Z?8AMd832s(v&-w^$c$McvfQL(mMiz3w_S
zV7{EynLr`ci|2VEvXGJ;xt~cjeK}mrf^9$-*-ESz52Q@EoT!(E#+JI;t_wm*S}8<c
z2zA0ftHHRB4Xb>MXcnSGR2wpe#-HTp)GsIMWd5A0B~93)r8~P2)k*vX^8Bm*L%#1D
z&wYEnqWws*%IH4@uphcYAEE1TKsfEN-<?$>`;hNdA?6u%vp>>Le^_sHmsuvi^zR~_
zgqe~B{|j;@_8Ogsr}*Unq@#|S@j4P*$A~9yRo}u3x<=k&V+Wj8-F5Lh$pj1aAunR~
z`y(YCM0)0<o7Njc)uTm=VTG^kqCSNEs4D|?Shu{mp}uBOO}EPzKL(;)HwPxvO|e*M
z$lR{#LxI+&8XVf#b>8tL3?unv-!yS69K)oWhoMfaYl`?DwhCPZy)E55$<WtM=%Ix*
z3#$VE3%dEhG%*u&Qy&_Rbn5T9WS-zUPMmaz`t~d)R!B$bmlJhD<D!<P2KwmM{$oFu
zoh`mMDk27^qB$r1a-v?i|5S9lc2+j7C`c1CKs52p!AST2VKof}a8-z6!&%&henz&Q
zemPM$HS^?VZQX9OWR#?d_aRrQPRK9z`{Nf<_%*JXVqidh>kptS#zVEVqj9&^h~kqN
z_G^x!kC41IM2V^hkt-fDEV?-A%=l`~*E+!`khj=Zq<bp`RUyQqX<~b$PCQ0!sKhJY
zGxUuQDc1>>%gf7&Ix$>O-D=(vdA`Te5HY9vPA1Y1?s$q!7hI(xV)#&LzV<KAU7Pm6
zmibxC(*(MgT?ExlWObStO8f%3G7|TNOQwB5HG^6cC$Sxex*4o~G(Vl-7r8;l|3IC1
zqG^Jhw^S#ikgjj7KVA|3jc6f8!nFbe$5ra9`H4DdY^LQ(YPC{rQ%(88x(4MjF2}5F
zb2-h;mNz$5mE*K>`U;11`I3b#<s(MW|1w@q-lGi4trk7uNITmuw0YMxJ<3?nL~o!w
zm52wtFQ<uWq(tv%q@IzBj9&4X_#JIeR{`k0SA8`<J4)|D*khZLYxWLWrH<8Fb_~%W
z(k1@~UriH7fg+-v=2?b4|Hx^I!2Mi2zp@gv-)&N@zI2p!-Y0NV`qe~Bh2ia2TM{^1
z2mW<w;xLd!bubp`;XRHps9h<@M?{y`fjVeus%+Sl{w-L?)PZIvei!einZB`cxV3y^
zJzZC#U(<EvL2A9Dx>KJWZF5+XO)af~O-YtZmS{6^>=)utQxn~uUo5)E<KCisk%*9?
zjVlJaG3A(Wb(C(1HY1Ra1QFuuH?0BuSl86pK<5t0-C66fPtnrNPSbRd4??@7V}Az4
z_Y;r~She&+Mfjes?+sfif{FOf?)xeEfF`JDb*zIt5bc*P?Huas6l*Yjud=C%<~PK9
z6m)>gi*dwf>Z|$LQ65N1bIp=ETeG=?ZS318-SktDjJrO&>_tUXlbD4uBwZm)*kUR!
z;p!;8*bNqIj!CyC=yHq^Hn$kB0|bKt>gV1A)6IDI!*O3$GMHR+xVClG8#KEekmo7e
zSjxA}ITt!kcj(}BGp3z1n6(afh^xR)^rLPjcD{U5%f~it?8Rv9%`YwMINjls(*?!I
zP@e{QV%Wm9#$4%Qmt2I3-=gT-oh{er;gpX}sos*cg&n6^oNBf8B+zHY>~9oTN+pl8
z>A>TU0n@LJ_UjZjdV}1R+J4P(hlnPUGC(tpQK_B1NG;j@qBwtF{D5l-25McVuNoU1
zl-^2~wJlG_S)PjKETr!YS@U<I6RU__#eLN`_kNw<&Z+J5EsrAUNP|;*$1hG7WT#Pk
zXCu9E&EVY?#XGs$jIsGpbo|b4@8sh$GE6WD)ne=U>j=q0^7y6cVkdkdnsY$x(`#Qg
zrUou_Eh7fNwG2w_e)ZM->}bDEF3YNG=CsbOAj~0?Ow#Q8DqVblaW>JM3yPL3pZv5U
zY_;$j<8Ko1ojv|mTR?6q!SOrhjw&2;I#4@DzE2m6k&^FrvLe>_{7}3{e}L;*q)h(a
z2ETW-o$Y8|=vXT&S?2pe?e#-6=P446&&x&F7;l7-GR?0Wzd1;AeU0rh#13_5$=lu^
z)3N`i;_ZB-|NXAdTZ-skM72TRItOf%)VAoH&FmJ_ahg3prJMeg0uXEYQ+9P-YXscP
z+qd)WvE*`lll9w9i89&VA#iV*(cXnfKbbbkn3DRpIQ-^qWz%m!2Y*(6vpzb`<Fv=q
zCgUx2QiDSjlbFi*ribZEnu2@Fr?R7~m<HImJn*eNsJ@z?9i=yUTUXDS+Z1qWI4#@P
zvqw*XFd(U`ijbZ)<>{V^sH<Hx#-MA~K|-uiU(L^s(p%Nou&9RI*zHHuI2m?{gYD}%
ztfyEGDoAD*o7B*kOHDmR>p)p%KkmHDZosCg4pD5_+@Se1q8au`3DUb>e_%FIOe>Ul
zzL50Q4(dnqv!iXCN;hMpSjTA&9o|!*n@XBXk@mZYV*-zMt)q^P%LD%IY+F0I-HFK`
z=ge$D<itQPhE0-QlGl6wKE#;!JHvI0L9e^Z=*5AvaFjU3)RLSddYW?D2YM|z{hC-}
zNU)f@^T&}X`~`9cW+&<O<XH3`33@Lae;K)maP@U9F=SMv>-;0M`Bp=tLj+U%26B4}
z9GNBgnH<^$|EPbDsHIt)kTHi9gP(Vm`qBLCxXemwchq9i)=_>AP3dXcS<^txeQ)2l
zRuR=pwCt?D%^K8o^e)E1dQOQfYTw8)J<S-7>A0W%U{j`|@@o+^l<$>Y*S;0awJmd6
zYaL=}5Jofy{Z=2QIciI0Rl1&~iF#Zs5NLXj`f7f5l&4eszP2KgzXQW4qCMKw6DwL&
zf2LT#Bfq|Ve?{QFF5VAqyaW0vl`p@czS+?U45B%sxu?0;$V}W9T|MLlMf39_Y|PsP
z-JP$aQp{D=HIl2-Ar>ck15mubASF9<7Scf{MIS?g>s>)HYIOM=XyfE#Cps2Pp8v4f
zUEeyu+Ol6qPUtEAhV~@7j|Pq7|BSsVi4_qMF=W|zXzQ->_rbods%&xA-{(HPr@*o4
zl4crATzl-w5sK!wy2ZyyG&}9%3@z&^?lRi>7!Z5bR|Cl9i7P0cG}?Jd*S2$mlSEUW
z_FmLe?m<qxU5@)bVxJR><9bM}2d#8H3rT*T`f7f5RA;3cJK}dNm~qa@Ni;|A>M8eQ
zB$|)K{oOY{WrP!qa;-Pw)xDU+>g+j-<Z=u#HVfxC>J#za-_u-gc^v2+@N*ACT7M^=
zG;Hl9ptrN_lH~Nta~vJgQpygC;oQi<pp)9S0_l^3z276j^<UB7a0<;r;GEIu3c_c{
zdD<>sY;j$EbrrUNa%`GL>MG9{kYQkQqTLUg#(n+n@ruAg*Sa0mH@Ca<+d8!kibIAF
zLeq*frD;rwl?b*AN;|5n-QV^U6iY(%S0eo_aL*Hp>Vd9-7(de$frq=(`}Ukv5^dp}
zDmr$|A&y5=3-=Daq`#VIo`d`JGr!%P=mbZLyZfqd5qIaed19R4!jv^o*Sv7foD&=y
zZc4sy>(@(A5DnEq71D$Mo=<LXT$5b9pT`Q=rkyS0QjI?rw$``Q5z#nl9B24pdk^OV
zqa_dQ)=OLlYKi`8q<2h7qtFvvF4uZvE;iPM^fS>djb=?a)B}{v_xJB*`WtFMbz{X(
z&q(rxUw93j?u3p@>;p+-W$BbPJzlo9sc|8WpLMJ{WPb?m-AkO(L-9i`Dq{WHK{D@f
zEfK#PcAfix&hHOfP#+k$p*kEQpZY=w4L%<!^@X`e9}MLhGkbGg%M3d{ggWT#xq;L=
z5K_W^*MN?wJ=xy=>|Ww2gXVci-`MGj>yhB9a!ofj(r_cHbc6cQ{OqXBlbYtmI95;|
zC0JMEG_T`KL%2?5d)Fbg{B946Vq-yWXh`SVdnx=dI9ZyG5_X8eK_BsWWL7V^*E8`r
z@p|Kgqn<>9YmOLd$ombB$or&m(k)B6AWqtUwAId}+^u%r-gUTP=VX8px=P2ByUl6a
z&NttpxjupB16@OnvD;90*V4SuelxBP%QCUF7tZii{dpnMJDz=bJrZ1#U9=|~T^SCH
zS5w(?)Xoj9POb7#{W)~H)y@r|&*JSOSN|O($)aH2u5D+zdmWZT{PjKfQZHnbHfyMt
z8F$qP5_dTL^=w6HoojHK`WAo;>uf!ps-2zg%R$gfeVAl6Z2{1_e8*Bn<%zCa47(%-
zyQH(_SISr%+F!%Dp{dkUp38cPFys``Opb`Ax4xmK#<fEHY|y*{G~cU!G(S6Pm!ukv
z%h(hLo#({Y88`G2WPB0LO-R4$b#g=z_O=MnAK<zY{B3k=^#eW~q}j<3B-zewp!rJB
zKr}ZaJ+W}<07cl}#7cwa6<thobHG_YayZ;eEH!9uLHf5N7pzn?UoT!aXzt>;tH7M5
z1&$e>M3VPLYn<JRduyD1j4Ri$M`#^SXUniuG8=<y)zwLmIp$eZI@)_%FEJC9Ks>$(
zwEx=Y%-vLb_jV05XkUSthOVMr)d_a`t*vULy=EO-j0_^F?W2)iB8rsgr-`wTOHcj@
z39j8;wC}0B26Y|%<XAZ#C&t#**40$2GmM;avr78K)4jwHqy3kF*j`ueIZhFMm@Cv*
zeOtF*m(qVccwoymnd^X6PHi7~r<Xh{nA-jX+*^C!9_0#AU@@+B@UncazM7vM)oHf=
z1=?Y+WnOE8!@iX`M%t4=5z$WaepU6e<Wj?Ruo>Gz8^CvMzbC8CF;Q=x8I$}xh%%R#
zm;%>^J-W_5pIeVrA}y_sd6Vq-c{{@8bC70pl_It+-ZW_5ko4LgIo0w+qSw`1P|P0j
z`^iWT`rzufk>JX5Z7{}VKRYlkOCDQIzgDQNsT?AjXbz<H78{Wg&8Hwe_`BDstK-Ts
zY0l_UpD~VgXo6ZZ+uX_BHI#n$Z`0dcuY4*fx7I74>>6n3_x=v}U6QvutxMm6P4PRZ
z*P`27GzSxC{*M?99;eF#-*IP;Pm{++G}p~-u-}Wi1LO+g^H~4hf=m_S^V5(%`SY&E
zIPEmoc%yGS;d4pe#<XstVoqhVV`iJA**BoK^dS+=r-SBYXC8bA5?n{R1{yRwF*lr?
z=B66Cc*0q-CEcDqdW!~7NpzoqwD6sp+lgxIv+jDx@T2x{K&B<9yJkrMM_f20!X>@&
zfxQJWGtqk{(&(L86bgcCfa~>b)wfv=(3@&(YH01&03wl{;&9og_qOOh3uJy!f9FU=
z?Kv)v%k8?gLDm}lig`H4%b^A*y5pc5Q{1w>&qn%L&2xhk-9L$-(XT@e*yYJ(x1t+C
zPW5v0{N{O$^^S47;g8s-x7>S}`28FZe)KsWBf{%4S3e^HXv6+O{9RRw`PtDiSxSF$
z)gq_D&t?A(U^DK)pn~XKhV;1=N0XU?Yk})Z!~YV4ee!_%(fo9b-o;f2Z<*r|hpRSr
zPwg$vfvhH)&jm$~HVrXWlGM0(-}a1sI)B|z$~Im&2N6w<EtQh(9Gux(ct9)B{5Pb<
z51$!VjroTtH~MuHKE}t?kLG7b+d0MBzd#e55Vbgz5I(jFM;EAr5|V4aS-s&=Q}myQ
z`(K{@>JCNZ7h)g@JY4JCLOd?NSsxD3Pix~GYjL92Ut!7d^Koy<@pRYE{S|!ybbMnH
z#U!|+^rn#Ga!tNdf{f^G3-%TVASM1@jx_vYzhe|p7rD-4{&qlbrR>vn&5&fyO#~9n
z(bIaH@p%{E-kLXv3bsWlKCg@VbX9$0Guh#e%I?q^z0FwU3qi9Li~O+|NQ#UuFv2SJ
z&HU^rU#E~`wYBxF&9;Y#c3^NxZS1?qYU2>@H;%sd1Vz*j=H4;!u9MppG`e(h(Wkw?
zu(ccgg^~j-*O7ypGE=*UFYYalhTI}~b}{aczwe_m)$Y%V{)WC9Kd8(2yrQ<g*~w;?
zIy&RV-r_kBNi<)A^rVMkBNWXyiGIecp#MN2V=~q6>a(MLJ4MW)lgqg!z0ntYBa&Rv
zdnrgcEi?NcilTtv{Wiv<ZyP_FBs)ZJU2|nii|uha9h7AmFZY(?CTd@btH1V^HHIuZ
zz;%$Jqk|6U=+yIF%JP(>Of}=}*laiTX|cAq_znrtPwOfUx`|F4qw7;KemnKei5NUc
zE}Yc5=?uv6&CYEDM)XGC=`GF&T}1B{xWDrH9<vpdcZ%pX>RVT?{X`QxzxMOv-eQE&
zrzv*l{6D`kXud`CGse@wUZ@jAzWLeFKAkEy3%@%azY_ntx4GByRiJ3`rE3lH8bm+C
zC+fsHnZ$Jwsn<#Y!D=DL%u+$T?)$E{xp&glxR2!ASB(VMF0KN@Pa21xw9DqRs}@!U
zx<IDIf9oxVgG%b-*C73D-9?69VVvtBsu)~O_({zvyrgrx=K82Ev)4So_ZDS_y>=~V
z{`juL-j&3Qwc=-OUZAtvKUKe{n9RDWM#lzY)U=-TK4KcRFWUY(q;E~!{%u9`wdT3j
zaR>ByDw^@T<1~kR^btKkJkfkTh+VOJe`781Lf0(AhFRtS&8ck|we*Wmj#yOLR988t
z-m$Pf`|;WF-8eq0r9%a}tiQ*5_7OW9{XGmm*kx>CO!59ct}_jJ?}qK(RdM!++f!3x
zv`oq|D^~eZ#m;>M&1+L1xDiCBRjfDqz)aVR@Hf#F9n$%_E~T$+NsD77lbnl;?<2^5
zC3<f{dRllWxt?(K5YIZO+f&Io$o4uXgU=<+llq94K_St6Gt$x<%GVRcLbQm%2F)vB
z&)lniG(VlPW0gL0ZqrXmb6y{D4k#g-Z$Y}<($$%YuraP;gXWAb?9=sCb=576w7rAl
z;i!V>j~Dh4WV;akw<3M6YL}fA{U^BkJE+@|$2O?_Fr5tPAey67`iLBZ=G%~t8Svgg
zisoZo8AhA0Lz~~Pel$Nj%I7I%Sw(H2r4c>fq2UVA?4Q<01dVa|?YRH;&2c{{!Wvz<
zZuKn!qrS^%uBwG2#vy`1j_ljPKIR$BEAZQI=k|O{QTn8LR!Uoj5cAZJ=4VISIr;f+
zwKdS!O_=<2ESiC6_MX;9u8E@lOp~31Pki5)^Sr{<#~73N!P{Lnw_i1CWRrul`$Tj6
z%s%Gc+;`&siCbsCj|A7Lu6{-&$FoC(Sgn3EKRepaDf{!nIUw1wsb0z3(QqHJ4zh~c
z`7Tg&?9FS8VdipI*qAGL7V!)Zn$)T<4$|CAG&>bkPVF3v^byY)G?R^eNOh&b#?7vH
zPeoswn|54Fyd0w$<PvK;Nps-IJ|bYqZEE0qcgQiu+pD@|&qQb`$M;N(zSu{M0j<Q_
zWNWTCVk4R2xH4Ts4V$FEf$?^#_``&?af_YRSs5?&5yybpiT3+I@s&Sh8ouP;L@s!r
zuJI1UDW#h0mJ|FAkxYF$^hzJ|%;5;`tuu#D5gEOSTKJqm??2R6^RuIUI>r1S9cSj~
z-mjrI`-qF6hpBzZ)=ED(hr~CoHDVjsB6I}@AwErgH9sAqx4yZi#;MR!LGA1Rw2#1P
ze3D)g);G7ckjahfHnE=m02kTXkEyTbXGiHx!Os=w%Z|@!dq3+VN<ay<G3npT_ls%j
z6W2*1Z1A)XJZ&s;RuDcrN^|1e2&|K2C&S1fG^e6hl-(WwqL1i}xjv$wbn#EQzMmA4
z=L^pc>RSx<SQqtaEEI6e<d!@h-KDQ62U$e#-;thw-{s>Jm3NEt4IW<xy=9QDAbfVT
zy;J#$@Owj5gL8u`BFWpYuQ<@?*AL_V-w*s=pa`4h$~APf4?4Q5e4!BBI7qriRf)qo
zI=X9Ld5#mc_ah+sg>%=BRJ4B}&Np;4?Tgk`^FGwxPC5svz1#NcD^?hGD9Nq1OaJ?c
zqItOMZuE7!dUT<mETO%f_I)4FS6pTAI?1e8t~td}R~4>+!Rt=Ud8Hg*VxR^4#j$8K
zYH#;}eZ^fg*24KuiMGh2Vz4p33?Mbg7rdUeqcSbI@1(wQZl=c}D^%$$ucxng%4lP1
z+!Ln#_$m@y^MuDBG5|g|Ledn3&rYGYp|PcI)cCQRM(b47)HybrtLP4n>?;Nvbgu$E
zZ+^GmC5pJK#Yw~nxV#|xJoVN5>=e2;In)ds-_lfH>)bJ4QeVeML3e=?lHdPC>O1@W
z7ZhQy2ws~W>RP{`a~pYrFlt86=)R&EDbY-Rus_GYd^{3dA@gjrm0d`)qnnq4Dxx_G
zn&%=Vnjc5{MZ;?+BEfaBILP4b4D@Y;W+hzC@OEtttz@fNQdQ&JNri?i8)NZz6qNP<
z@{oK*;JxB|o~uQ=G=b_)l4YCp>55t~cWX;sy;E*7+1CEaeZ^SNLv8&8(lb`>{iP!B
z64&{L{2mXRtn21C;7Mp~sAz4e9q*LlA{KV%^%cJw{)9ES??0{LeMR?KE)UyfXluh!
zsvvxJl*d!rCerr}r@uo)6U~vLzG4yDl-l}VxPSEZU%W_go$ET>@b_;R+=c%B#n_+G
z!3B)6oooA=ezGS)spThIDz5A+i5Dx}UFJ7((k&?abGV_exfk(MAkW&z^J&3niv;)W
zGQSaqST&VS?OaOj8*J%o#??KId+!Z58Y}j~;ueg%=%PJC$iJXp9qq?k<TIkcOLTaL
zy0mQX*rLAD=Sh9~84y^udhSL==LA>Kkl$VDPpG$IX&v(>*vHi^6XnDhxIFl0e3f&%
z^jk;U-DaFsF>=h<3PclDSF}{tVG%xs7CP1Ro7o@hWic>G9sFkSgJX42QHz+uMHR;{
zZfv4TaFTu^FS;1M6{N)b&m*n>@6Xea;5uCt7_`zDY?=De{B(x?+J%*)Dk>MD>768;
z=x$rm*F5)+24Jh_{YmCJu4&?M!;h8$8^%!S3c_cn&|SH(dhF;;N8Io<R5S-_s_LBE
zK1lZEz{!2hxU&~Q)5&KnJ6jQ0FAmyXeRB^G@(gZur#?G{_LTkxEE!s;4g++m!&AF^
z&g?4+@P+vOCEU-Mkzx2+YDKX@dt_H3>U6^Ky;EpU(e8CM&Ye6>G{^te*WB~+W!(RL
z(ujVFyz^WK8Tvg2|7q8aPcp|kX|&qwwzEy$R<H-{V4Zk%w4D=e8v9ivFl(9{>uZet
zD7qw+d^0*Pzgy$!A^Wuob4m&*d&Yf%)hAv73mkCAoZl5ETp$8{)VJ6H*jp`;Jvv7Y
zY~rV=4RnQXCVWd@u|Mb`*+)We+KcbzEAq-k%!tn`*a@=E37S*LzS=+)yspl+wdc0J
z;#i^^^9ipd&^F&Z^L7~oCDgsV&UVzss|_?e6>N*QCwU(My%Ug9JHL+f<;NfR4GFF@
zMGu2WvTeG?_ekzHhuingzTy^8NA$jdw0inK|0HU$;#mykMg@N-vE?c~ndKEQwHK6+
zEpIL_Y-p)zT3AzEhrQm)7hz+l#`@-R*d<j9TShcs@6JUvfu_d!6`7e6#*Z1BIc8L5
zIZoE7E?2A_sA;aLvYq%YsjF&gY;LS=anGo0#-7*iX)UdElKn_e=7jRe^lWTX)Lc_O
zBd2`2e00e)e9as^V&sGoqdb|TM$x;JFM;W(-l=*7Qbnk2cRvmagy|yd;Z3A>f74K;
z-~&XI7z0-j|BS9qxAKC{>%@9M^h*V8L<3n~+gL%n{npv8g>|l0?CpT@o5X5zeNfuD
zby8c8Estw#BSD<22FV*S@CHmg$s6mCUR|)=O+=><dz*7@Zpb~uFjNpeJGUOHYwB@u
zTm_E4uCHvWXs%moJGghSN@Sggd-@8RgCn`|HqvulvllDEC&=|?^gV`tlO%Sg6Z^|t
zY!cj1U5|CeHMXHq&eaBqhB)ftIHaT_-yy=yYX|YAAv=a5WpSEk;GN4KRr3}!x7fx6
zI#&xycLwh5D{cpE#1ro#{kZI<wTjfSg7=wy7WL3YJkeb&A^V5-K1*i2hf2u*>PT3J
zbd5B}P+crD><kGfSwq%``~JS-El^K=<lnL$_+z3NXeiYckfGd1?l=0)7Wa`wRZVmT
z$if=k+Nc;eX2OI~qsJ#&8w+a|Ze~elr&fpgX6<bb&jWqoDOCOCeWc^o>}gcWR6+CG
zboD^pVEQxRa-vRfK(7>}6%CD>A5J-6J(6eIP(K{+@d0XJmrKXwsEQ~Q(+&P0e^l>;
z+Sv-dYqrehd1n5?K<nZ<`!!%rR|}Esez32g@fOM0Hr)Twf1lNg`~vZwQ71m|&R@3I
zx1vrkxmGpLc0A^EjVQg7@%O&i$z0XRhp3Fj&zy%SZMw2W*r*e47u5-t7X44uN%Y~q
zVjzSm@ySQ13EvgdjUj8EDO=`2wsaAnbUUNik7o`v<DGv-T_qXYccRT&-&k2)RXewv
zv@vyu_h6fl>)M@>;a`u`x(*fNhgo;+zZEVFU=y-KizZJkom`Aak?Q*TzkW34LOB>;
zP}9^<Q;)KEG;VZPku?(Uhh-@LNqC8?T=nE|Omd9`FAsAU*EOI-H)uHc(GlO+l|@*v
zS_l#pWRp;l6R){=Hl>6`fU!S-ep|is)8qz|SbVvP%b~tSf4k!PV~=1gb^*>m#0_KH
z=07llu{bce%}uQ5<wIU(EaO7xHw}w_`k&Jn^8mXZ58^VX_V`$u1oUk0Mb>-L{Z7}O
zF6~VE?gvJ;Hs^CaSq!Qa4MAWNHSF!vXZ^@n44D2d<r9_-XDkkEFD>7WUoX9cG55u(
z-^B||FSGv<(;wh`eqc`<Ws=$Rf~bDn#8CR*G_3cVjmI#SajEL7L?7k*XZ<7PjJbi$
z(ef?Yv2GP(VPFSq*as^oj%Tb57}G~(_Pb+G8IMNwnQ@t#)92@9@Bb?`ry$G+jQNG~
zl}{XhHDdu_HMrq?$6R=XTxUZ0;=o2|SWQjOzjHp%<%wmkexrIMV?JPoTD~iH{4cn~
z;9X$bpm2WPlyAqL%NQL}d7hT<(Y1@sc8>r%M8kf1a=;CoFAi*yhJ8I|x%n>Mt1u6$
zVUa@{cjkO;z{rut@3O;Adr5yP(e6bJjnc4r8-J7$QG^A7kzqsm(6vSI;Qc9_NDvmd
zhITfwu$PAahyFxj8Q0QIFACcR>9cA3oyM3On38)wKTT8LH2l)%81n$5Lg;z)H_P{V
z^lQevTE6Y^;~}%#8X5Cx`RKWNKEH<bY=;Ga?S|jzd8BWu*WE77SfVckjCqN$6IKu3
zABm(dqLoP*jwv5XLkEdPHH@ZVMr031&r(=S!>E#VtPL2~8Oe*+d;_vLU)%;0*WpBJ
z{2|dm`QAO|$|anSHW?dYU^^n+eg4vaG8O{H&m&o>KQF9dJGH|iz^E*G9x>R^M{b#d
zMA9Aub}=fCu?Jtj`au%|7axfm#-7{n$S)Z4hAkOMW$H504~%(&FuiR9z;45DT;|&K
zgI3{IzKi!pt8FQt-nO&}Q_3=dk<j2WZxuz)a+#i+$eL9c$<eXDJh+UpkPQ|G#yn3v
zb@Y_ACvrY<GkGvonS{*@4mgJ~53v3kc71jkg*!<4e8Be7u%F^VVpE9)f$gVZ&wuo<
z;fzIqrFxeruv{(QYtNjV&iUN8;DieeyZw|CK4mNdjO7y1aBAB_`HYEME&e3zskeu0
zWQ;b=VLeS)Nnq{@#)80VaYOAu*fHZ{$1z5YUZ-I%AG@HQu@Ep4?3{0ppT`}>SQ{`R
zh%ud);=nEkNEpe4>wjPKGUp52W%Z-o@ni7Cxw9Dy13MHqly6U@3qE<{2*%>Te%7#x
zmoE8*G0#1Q&Vk)CkbX2SbRQ7_HU=q`Np1XDNrbwgAS?>(RiunPG2)6(7>nI&>37OE
z@agx@Vk`~}V#Lfh^B+Fcuu<lH=+h{i%lv$|Kh`qlzF&xow0uA9ULRwu4cG%3w(9WT
zP1&;=z;+T#v~P)qCvC9jZLpXP_NEQ?o(=Yq4Yt7s`^pCU-Uj>C2BQr}Qq|dZHdr4U
zY-by+zYXRFRtM!xJh2bjY+!s*F%m)T7g=fXryKV-J>~ugiNt7O@&J6Nd~T#wRTG~_
zA~83xo$;NqFFcnnX3X0z-}Ysr&3@zu#&W`q3@0xAnYxE8GYE|PG-0|<4FTH&ztQvd
zMat*JN*Zji7_dQFK8~NJd=zM#3iALPt>t?%WBCxuLivKgSeDbf=(0QvjQT6TC!b3}
z`C>L0E&NYarrQSd+F*VgEC`J37Jkn^UwUdOZY6yo8!Qa$5G~)gB{|uguMJqL`pkef
zC*I@dZFo3*3g`0z8>V5g<0l6g3j!lsi1QVGd(0V(g>A4Xu!FUHyeF}2_kX6wyuc39
z^3`2)tfh->uqd!2w0u{ELmqz5jMbLCMEsJypieDhL0}N)CVg*AIU15!wF52IilkZC
zakY!dToXh?bPe_sKuYyOb$-FzgD^@_7zGN^!x?kGp8Eo0USQW~*e?~wg&E6u%CZNk
z%*O|`eaDywSSfC}%yVb{V(RxWFqQ?B?~1uYN$sll1a`8P@0}YzAr&Ms|I@;Zm7si6
z?|dqkG0!tXK;@dx`|govk6|nWR-FF4Tc0>O#+aua_H0hC!x{6n!zTXg!q*rJ0AoI*
zchT+E5U?y%I@5m1_rKlE`8<$_S-2se$A0vqaZwwEfKh`{zQIUi!z$k*n6L=2qmeR}
zJ>gN4U)*Rd?kkk<gvN0pBr=~57<C-ZciOD}=DWm!(Yq5i1gS3T+%H;ki7;I*`GC2#
zeD}{EYSw2E7|SKfmmuqa?WyG}J*)-4sP~N7<ck9vrsdQ7yXPgV9q4&_fA<07K24b3
zr$fLF(#q8PZ44O8a?1DJewFKx$oh1@Z0SG3jxESr!B_y;ak%07yzHMd&3tiS^!JPf
z>aQx~d~R4=*P@Xb>(>z6n=#KT@MUQEdY`o0&5T8W<!RVMqxK*+knc&6!3S#CK94-L
zfiWMjc?PyW(ocU_zYSw;z_?xrdv&L!;1Yv&aQ|$4r}rf6{P%CWm9Y@8RQc%ShFT-v
z0Z2z3HRE;8=fk(7G;H|rp)(na0!x+8`-Y(5g?tw(bK;YWZ{vI!Z>G){0+uSDAH6M4
zEA!>6H=4313XD1&(N531>6aHQ`H5CORKp(qQpMv_zx4sTN5h8vkoh@oWgB_kPK{-}
zlNyWLV6k^o=Zm~2gx}yZqT$}{=G@Nj5_mr~=4nff#XnT@e_St(6OMY4%M>3aV(*^y
zt0`ME+F?^qJlCvivMBdLAzWtvmc4J}GJU|9uZf0FZ&+HuSjZ+{6xi-snMb9+){pbG
z0pmRksLW%RR`qAh{U0G_X!$lC{o+rIg@EZi@k{nErp}20o2ccxde@NyIG_6ytl`kG
zldpMid&az<Cbr)xFP)yom>WHqbOzVU2bCB9$e0gUAFXY3vs#N73x9^=RJ42-?faI=
zyAg2X9vXJ?h#k)5d@*3VY1q0whfiTF4vYxmcUf>*B*0k47s8A~q57;k;nw+#wE^p`
z<<t2k4vcLg%2)ATWC-W;eyP@7^YgB`VVH@v0b{vK`3iU4!ITC5|Ejn!&gX3{`+&;~
z0%O@q`GyzQlrkp1vizom-F3&!rrh-dOV#dSV5!<Y4r~p|;&&1E?@FRipxH$HYauSw
zu#>LO{++Q%-0~UIyZl^}R>YY98_Q-O?C#w*{FAXDFzQtNyvJwe^<>QZt>v4ce6xbl
z5MyCrxmv!)+ZKMx7#+%!qhZz0Yy?$`20t)j5Pn|n?ZbCsENX+fzfa7Uciq2U<b1()
zm|kWZutM#5Q$K&_4$kNO0sd_byZ`p;48}sh=mGqm=fAziXJY744{O*P^KQF}u^@W>
zwHh|)<Mdw`^Zkr@Jq^3y(F<WksCo(DuL2sj_Upms^Te--&%5iRJx=F*abUGtzE3_`
zWy-9;Z|&M|@KHg|7Xvm`%eU{ug{J)Uf~!u{uytRq&E|Y<z;@NJId{(9jxq5E^u31l
zy=irvu?Vm~V0dzUKJ!4qEXLx)U8Y??eD=-GPu|Oz2b)O@#|`H@FL$je%LBj;)Ua<d
zxBHOuMcQFAPT2W5#^UYD%+DUZiZRc@iO>7^@pGmz767I{Z^-*$4`Y#b*s2|#FzYkk
zuFT4hUce~K(C;|hs1Lp~eXGXpUc;ET9oDbci=!Fy0b8!+TR!R^ro0x1B+~HO4^P1w
zP|x$W!`2+!bTwl^V8iq>{cF$*RK94td^^AU@!gCGPa+L_tv&oQ#xj8Ebr!36&a@+a
zz;3`FGVROW-S2+R=gxGQ`$7><%zQiw?WNwuJ<27HPPg(6?|aa`jQPg7<lcW==4=0~
z=*yUQyi4?RS^1vI9c}Vwc!EnjqLq1MY%gMEfj<|%i7v5F%lF9qjimA<=Jw(}@dSR}
z+LcWK6GOlY#ZoeM(wZM(>8X7FX)bd-M)aMXo)Ka!1ngSvU2gjA{C631&vJ>&z%X3q
z#^-<hh_SZ0F5$xsV?92cwI^e~c`os)_AU*Tea>VoJl`eaXcf+PXtd;G#$o}NNYmbB
zo8=Qt-4SkaiRZQFt;+Xr&-ucwiS)f*dorm!LG>8}7ShU`v)2<=T`zT|wCjSv=<Hd3
z&ztTX@DP_7IoTz4)5_ebc-O}m3!UZ?ui%FBU3}aG5^wTd!l%2$QmxG6TG!_=7Cp-)
zJdkdj@6?@3EIGeCkv_fsBEa&s=Vd?m?dx1-#s#i~alnXM_cP_EAJ~psz63oDY`lg|
z_<fLRW5$3j(y+qA53Atk1uk@%b1%ea*G|~Z!&ns9WG!Fwj2TZb<_@_`9}?xu8`L<1
zF>#U0^j#3P{;~{HzlSlwSB&4d&R(AW(aUDOOA^Z*)9=U=7;6KzkH()xA7`D+nC~)|
zSdWU~GVfcl+Zl{`?r@20E#EoMT)Hn~u{&MnTo1kHHx(mIo^apgGRN<P{W|Ll(_RVy
z+h1$<KL5GQ>eCOp#OE5HebM@EgrAqO(j`V}yj1q&?WRo|d(<Tk!yhsY1FFxN&iUMr
zxdd78j79SPy$fT$)h<De$=Jkm{<D&?7_h0^TiBWmm)Va<@cf|F%Te)VD>z^9d6zg>
zEAz%Hp3P>=^Fr$W=LgoL<$L1Sci!ZDabP68`91&mbd)LQV=uZA#>{OOT=6jH^StCr
zu!Vh7x4oFLAh2?+%x?<MA@L?a78ZTE%(G3Y{f=Mp*`4&W#MZjZ^<jh+u9=a^m=D-g
ztzPObKZQ(cmG2doxu+H7>vQ#9vN-w(0(%W9(>Hst*R)YW5Uljlj6LicYVy4AHS~9l
zUrK*J#B5vtTZ#OVe$uJcC`P`E`yH1!q=!}JpP~M{G3LkSzKt5cEY1DR;@wXZb-?aF
zuDFKtwY9@;xc$`+81rp#iRqeNX*uWLg^Wdi0?%u8cB$_lBN_Aj3f-?^lPhMw#aQq+
zm!L-BdfDc|UrAj^`uxAU#J@D``wOeSHL*WjVpom68?L?e9>!=_L~0u@^Q{XfnwSUJ
zY7NV(eS%C6`8>BPO<b#$d0YB|TNn#$lP1pA^xxV?M%Odu?v<8cpY1(<53}7p!2012
z`CXP>n*J>3^R>f%-t%LE<hulb9fa?k?~<=~i!&AhrrWy{KO1m3WAS!nURki;QpPfR
zC%((j%A9=0JngVqU)^l-ybo9|{*d40hL;Ci#Q7rau(RXO@4;9`pTy@Cj6CBA#yr4A
zYh_+A@uMdh3j)j2upYy_)SR+j+JNn#VSUc}(v&ZvZ(4#+V9))QKF9eofE}vktGg#o
zLljx2AJ{St%l<LT>_-_pBtGxRb=P<}p9ff$mhX(nVmD(UV0wSJ^_D?xjESAnOy4#U
zru(+tHkcP!Z~Q&CLt)x8FL9YZV0yhAJvIAh#sW5FhJaCnahadq?#khOk#^Y4^+RuE
zEY=RYe$~HkWGvne3%|8bDPtKpz>O-9pZCjkYfYWw1E#;rb=!YFh4Te~?W5%zcVhLc
zjD>;eee4y_cvFW*ffZ}{iodwVl=JRg(h~ecKaDtI43`-Iwp7cv_P%MvK9XND`lTg|
ziyyuC!Sfjl0;7Q<(>L~k*Y{*B0D;w@VMA7~Ce<a&6uYIF^D@K}r`D8g%UA#y2_i1@
z(DGYnGUnag;-#VZ@uQp8Qx(cG{We(81`D^tbpDLmU~Ry9;Mw$^^e(PHu6~=}B@T?`
z8DYQAdv7^o9vpOa2yQsvRe9ByG8SluWmj#xfw4$CZ1m~9S{aMC!@eK-Oa^0~0cmP2
zyz!ppk9|0wu?VmlLs!vz4!pgV*g)22V9zx3YzV?GnR0rJG0$FUq5wBcL(bC&nld>A
ztWm>m`S{vNoX@?t#h+AWB!BIrj0J&F$Kf&?&kdf+SlkBl?~_R1O$SY)$4eU8fX&s)
z{PyOPH!$XRTf9U{QRk&#J51+^FfbCP^q!PYk8_LyqfW)xyn){xiCg(D8T(p&n({q)
zf}4gK67vGPmF#QGZw{j$jSEd9LI<Xq=Sq<tocepNIc65aQey#NcjNErT`1o>^<EMw
z@_D}DX@Z0XWBzgTi6tfGJt)oesZzd|dVlpbW8&b{SQHq`Ys#nlsAD!*8?b8pJ-^G+
zLsoys&-0H+GvlwROy4)p|H@bp*a$7(N7vm??rcdz)CLoWq@kXz=T)tIbw|$U0X9Ly
zp1-Sy*~fywxKGo&O#JSAvp%E1$N*#-F1esLsdV`+w4w948upJvta;`Lu){R$rGZ~O
zXXeXH6EMxqGT)B9bu?qXQEBG5gWhFW<wK_2Z3E`h${aE>YkM=_Xp46#-&?P|L?T+g
zX8_nG_|7yGmF%$}W1caIWsckT)?XM418dOUGyeUaUoaLJm)N$u6+KMdQ9dsY>`=r0
zq<1-J(7E*55{m-BP}O{wk19_m^GRZDhbPwc^B4PWV9b4lW!q4h+mHK|s$S-c0jtx>
ze4%ptUW|n&rHSV>Y-;u+q}J5)veHZ+AeH&dnRgJ|Nz9#X$#TNZxc!12jQN3)a^m{T
z-+9Doj0J)9*RT((_8iDq7+AfAo#dW+7Gs{AG(p0f%UreX<5L)m0y{~=Dm=4jcqZS|
zpPOdJa?pETaOk&ZG8SxyeZ2C<d5ndD(Tnl(etl?cF=MfI*cD@I!i<T@Y3Ba8^t@9l
zr<(2Vv%$i^Ucuk<^D1}x+-&zq9^{MGM)ww-wZeQJHm;jt<U1JY{y(fXeL(?WMH+Tt
z(}<@yUkun#4ZG^W2TVDbQE0UTm3i+!uRNUdg@MtF(R&hhLVurG*Kr%nJ0(rTwS2{o
zT^-^w14U`#KN|K%>?az!$@U8sTVo*kyz`Ii%UBE;^AcgT?!NzKEDkIKH~gNZx8FO5
zv5b;5@qW6(h@pRf{6h12@gvj3hZ@%W@UU$-Uu;I2C^6cB^8InowCflP%u2+5?Y)P|
zOBu7l6I#B<O2<v)eBomfv6Ihwc`aj}W7EVMNHC&-p4SxqjaWq1OT0GCJST#%eKzj#
zCu6=w*e@Cl(dnZeWGvL2CeIJ&GLH|AKasK6VhANeE>W4=oVGN|m=BK8Z8hx2*QSqS
ztnDPoLDUkLIk+fl%E-X!X(FUy!%ta8YDUuFS(aw{=jnN6|Ni3~#@y#xV?)B;d3E6~
zj0J)1g&TgJKHnb!Mjf27#@8PpHkZ%y|IHecP?@8T`8A8NFt7!<;e6gpkDSJs=RB)V
zQ@-=>eb}tCATT0`^Yxm$!IHbcW@*?bN9LR3V(<BB=3FF|`NX69ntUAwM!#{Hx_)o7
z!Q9JJ)8_}qeTB-_?YbZ^{drY$e;kWHk#!aYmZQDP(xQ!KeY!75r2V|enWiod*kDm$
z1zMTw&mX#qpXa_XO?WlzzN=pRim`wV76ryO3emFaj&zfkL?}&=0OR`n!@X*6F4G6B
zRKxCZO&P#g6j-x{m4ClKRfVh<-$j-#rswH)PY9UKpQr!2{wmHFwZY=RsN(rOj~<a<
z$@#n&TecfLZ%*@|0~red(|NG?zyH3Sv8WA}afxMvQJFQreMl-x(&ul7xkF)7-$vSD
zxmm|%b3SotVwpPT1E$lb>&CDR7PrB?m!&Q<1Z=7%vkqSQ$|!!%;FW1&h$bU@O}q7J
z#sY8-LQI<NaKQWXJd6czND~`z!)-L_*L~(N77bftJgU$7B}ZMznEOWf*0eHzX}sbV
z#>6dYqObNYUq5!mDU8K#PZM|GhMy;nxf!D+)kcvOX(Fg$U(S8#RK|RFSmOtJm)84s
z|A?^wFuhM_{<brT2HEa0V7qF%>dZr`XjmsP&t2BoiOPH_^TX#DbKh<GE(n`EdIxii
z7YC;I&Aa+t{~+h{+>;s$03)Vj+P}T$iH|v73>Z0h82d0h`zFRR?oAVeG;Ft)OH5nJ
z3+zx0dp=aZ1Lq3?%hj-V(w?I~m9)o!jn}Z!%O5Xi%zK|@Cll?uogB2mqQHo;n1*xq
zef}{nlLE8JAY)9oue~-{5ZELw->@U^y_w650qdb*`dZ62V0zzt;<jOPIG^W!Yy3|1
zjT`+4nc}iu{J?g`cYe>=i-P8uBnYgxh7})3r*)}(Az-BNIA4CtnNKhl2DX!iU32Z#
zLl}z!8=&#$D+|irWX%0wn!xnDS!O@+%yPye4<+);eczq4hOs!XU2wziGW*Pf+>B-X
zJu%-o*H-Vym=Bnq@1fyW(NI|66+{471yU|^#0Rfl!&n>`kB_K6AO7}2^nR5u<KaY`
z;fWX5S#v1BbRK;1=}(q&z8EmQ{dC#tek3&(0G6t6Mu3qrWEyf_*w2&&F<?=uYxr%5
zPx&I+#iMCrdjpe#(*OzcJ!a`f>c1b{@sufhg6%LphCBj{{*c~<^6B<V%m#}C8>Zz;
zhy`C|`O>M(gjjH32W$BfV!?rNol(AoSa4tnA2Hwa%LhiAcDaAG<%gE}Mqg*zC=p;o
zjeNvJg-fP=fJ9K8d7_qHAqB=~QV<pbb{tZw7s6h;{`I?&$b1=3San92US}R)Zv4ji
z?j2Zh0B&VIKd>V;?Eb4iC9xr~m`y&h#`4e8^Zs0L_SKxvZG(A%v7D!TtB)OcJ?9Gp
zdk{DLo=ZOa%<N;qe<jkOuPcZEV;hXh)Oo257`H89d;i=<T}RUAelpFBMI}r;o<mI~
zu{ba?aQR*I^$6~#60y&RPnpR1e8Aq(^8Gt}rfC=WpH7`G)DFu(^1^+&%qTDyqz1ps
z1uGh=84Epc={Ta{;F%AXGS&u+Ix*)vYs4X@4)?rZ$rsAEyn4c6oG%EB<r!fE9)9gS
z#>9)3ULj1^D;dB@VDj_4{#}Bc&jXD0H08VL4!_wBeqh|+3DbEu2#n<*VL$vDc!A4|
z0owsL{5-u+$J;&c@qL%S#QEGWS^9{|)b)|a2J-^b=?foy>`q*!-v$c;W4T1nE13I>
zDGQ>&_Q!8bL!Wu$F5oibz=*LJ+hxX2X4`sSwtS9c@OVZp+Me@8fsHWo5!U;m4W_Lx
z)~2D&RGEZjUAoci@4;8o%=H$;H^ZKP<TNCLWKSFzw*z5yr=4QzD(`D)=DDSW?eosc
ze<6|iqOYfk<BjJL_Q;oGs5?q5_Lem^BrNdJ_J1<wSqHs>8={@C`&Zq+jxjGVZU@44
zyKT&EjQN2PBU3(Nu)}-EVYqx=1ejOD9*n<f_9OAOrT-}3{QSGtB9Zyrz({Fxnfm&0
z53qa<+d00Y*$yFKWCU@(yt!9cV?$s(j-%(j_uM?QJ~Q62Y%szS=1_oDYGn?%^uI^p
zR=#Hx7zr?b-pGAoA2KH1wff&U{HU+z^4MU08!QCu0z)oQnM)SEbw58Zqb(83IqIP~
zjD^-)<7vv*FMF6tLkt-85u$;xlb?Kx*iO=y@t-vDuWc;sx(hc_RVeI>H1Vm1?fO)(
zkTK6UmfWQ>b$RW#!9u`TuTVZ+uS9LIxDDq1Hg%ak8!QN{Ki+}sMVFCb8!T#rwb@|e
zJ8RC3Xg~j_k=G)Tbsez5+JLdFqkOsz=Kel4=C{GZz<At2WlmpuADOE1U82Bfkj(Y6
z&xpD_#$vz*X_!7X6hEZKJiu75(DQV?;<Ld5HdqK4kB_KKecmu^gGGS#(P)_Yudj$)
zMLV#*8ur-Vj-{?6u~@r&3xAwg!&qCpe5XCW+{aiP7~4zqp1LjU`O&h43Da%ifDIP0
z!Q#M34{`hT3>SUP@8bQ*vNh;=*Yw}3o-rRV9vc$&Y2HI*rc2r*Kc|^%lL)K*<v?>R
z8neOTz;r&-*B)p5k{a^>V?HBcrOQ@7Fw#*(A7QJf6y1qLy{8Q(eoYf3Fgf4o&*uNi
z`GPi>_zgM-3Y+sC_~MznaK6Crsj;>{(!{CS^IYDdd7Ll!XPP)o!?wNV<8vAFY=oXp
zvz|9|{>DQYi^6E-c?6>U<J<CxBuTq(n{?sFcYe>KKmU7#v6v0!+cw?on^dO0wmM*g
zg@7&6>gDR5$2`c-3v8c=ZD0K7w~YCErkinx^t`oAv)^DWXoE$7>Fqx0`rXa(k?55g
z^8w>=2R%>MRY4mp0&Effp6j!1{ew^Od-{4OVl&?8LFSWehd3~{8R&U^zpS3in5R!_
zEC7skBjwX|V;ER}{KoI1>#C>?)@Fl|(==6?ZeVQl(Yv($y1yTZq%Q!h1mF2xuKUM?
zC}S~TWKc79+klgoG3MPNkv|J3-E59KqQF?k(erd2Cw5GYd4aKBp?tbt@dINyPna&}
z1Hf3$6Q;}gATajZ5H@J-0n}9`?O|Yh;5*Z|<54G@az1MFyqL}N+JLdWOV88oU2jHe
zEDVhG3gy%FN}CPl-YIoHKQNZpRHkkh1c9+#K$vb9gn*H<;Cj*ZSPU53?37Qp*~QMO
zF%K}kZFRZiv%vzu^!i-;m^TBDmF*V;wyXA@dJI<F2Futb^}Bd%FrN(;u)#vW<{R%x
zW10c0mVSst(%|lwZtmGZSeEPEGZ>2kWBN#GOy8?)Dr0THXyit1MA&bEd!As-vunB;
z>qpq{u{Wp+<?|xISQZebkN;?)kQcvknfmz82W&qLn>%pjo4A!_27&FZVaN5j?GVNy
zz;ZO~)n~pleF7P~r_SdE#`2TiQ<t9sVEwf+b@>?rwugqLx&4E1t7r$dlcD3N%xk~=
z7m0R>WeiB2&jXD63gv4$a`Xk9&kKzE7-6#?py&owrXQI8o}ceK`WVK7z^J{suIF!a
z)^Ci(fU(U-Wghl;5p^~Bp6)%;X&X#4U%c`6Um0ryHc7*-pL*8ojCuC7c%I7CWvdSu
z+unrfwznTxx>lw>whsWiO~VrQ5yZy$(=_b&HP;d=OBy1;R%=-1HTkAa4eyo66Ia}K
zm!I>+fa!Iu+n;e@dunC=;+;f~P<6I<Vmo}*x?p$4yuftc)t?struRQxzJ!2fYtL(&
zGV2yDGY(9Dmv6;B*D>baC-HedG#&gm#(cn-Uk<~MI$sBXvD_tW*uu4!bG|UJ7;cD{
z2pb!@<r&5z?sRi)HDQN%_PT+w*uLpv1R9s~U42+lk%?hK7;bnIyK7y<96xvuOgHyq
zIUE_vN(LXu`2xVU#|@Q9*teIg{*tjEFmk3brth5@vcbYOSi}a4+F&sotjz|C1LHVH
zqVMeRbMG>J(cy{MJAY;qxq<{j=wOR>lH0mpI1G%06x9o1`uHejgHhw9%I5(_WpSCh
zehAuNF&oT%Na`{JHdqwcvD&-n`pD}^jYVxRZ>CK?U@Qlz4t730P>w{lL&nH-Gme_D
zrA-U2VJrx2FWhjQ={hF@jO7I7({)^%4VEz~-JC0+e21R(;m7>E5U^BbMs2XTO__nw
zsc8rUOZB{%4JO8<&gZeg{J>JxXUGPN+F)@T%sn>UTr)y-{nLSGlgTODJr0azD`C29
z%@~&&^VncMV67;N`Q@5HuTb@>=h@`T7;p1D8_Wl6Kka!#3ZD3!pBDtShlc5PPuK>F
z0{c_T*H-n&C0r&g(A4|Up(lSse=6zo0Za9~0I-o-nO{#|xh?05*yM`=t2gX3YNJ1{
zS-+U`g%3}pegE@bF#UBgV5#0EZi8hUkvgBp2J-=9dyw8!-<Q}AOqa=L?tSb!rXd9E
zRNOGXG*&LZn=#Ks=nf5A{^T_@gqC$31x7cVFJU}ADK+M`!GgeeJVrF=_F&isi`rmq
zz<3NxW$I&Cw>LHBx52`|cq~d~>SNJ18_b=RI-eidK&?LYF>DCfiyHRNxl_)<t!#%-
zcDgwiN$)cDmg(0q76nF5BW|OD+I9Cb)&@+c;ezX4Aah%m>CQ<PZhYr_uT?&DK4U&$
zyJ?v2rwstxpkalt6@Ab7!nv01M(<ftd>FBod|pODy19=TVMG4;Los8q!gO<wI>L@Q
z^^28^d8eeCdy){=<E%;MSTv(3UCcm-U>Y(@Zn%i^iD~JA9M+7TJ^%Kr8S_ksZ$|6y
zuiafWow3kS=>pS4X1;%Km;EJU-lNk68C_iFUBCYPEo1)K>Ebx8%-DvprHr}D)5Vv@
z92n8C(KlcwW4<{Uhill*e;a)OWAV9YKNz+Ayl7~{T_zStH)H6i%$!eubTj5X-tw&x
z_S)zP8yO1&%hR5>>bn+`&&1+%a~&q-d%rX~-^>RrL!<AQ-d++n0zY8^Lb^Cb!@ix<
z{2gO$OChr~?9I!EJiwUeB=7`on7;c9mcGbXq#bs1cq0w@<nufyC)!f)zI4<DjD>-5
zADf6D_3=s!*k1UJo<~?!$*tzNL!4suKf>;LdIJq36@8~#HZ<uaef*FCjK^wTV7jlw
zV}tpCvAm{yy6qhVMxBG+lQ2EjsLclR1})o^^6B<&)CTjOX8C3)pYEFp*<fwJ=<oSG
zb-#`0^we0;28#jnXl3f_12WFA>_K|2ZVP*Duz(E~2F5%=W$Lzf%qE{WGj%=>Ft+)q
zOx@=50b?CbSb`1*2D8Yl&mFItcnbbR@?c<@WiwE|G`HXEe<2$zVuQtijYzYeckJ_j
znEtcSd8wZl0mgO#y^C%a#DN`z-<T(Kz3DkW-CS2r`TieY_W|Za(FOo`;Ev-im&27_
zH57k9P*y;yK%{q<-Z6A3LR6Hlp?6u3rnG>9pa=^H0t!Y%I<nFQg;1mm5kWvH|M%_X
zn@sXNGd%zA-sa6WZD(g^H=B)k|AbFrCKz3_!nm5>l)VoNr(MEe!{BeqZ_0(~$H)TH
zW7hz^@Z!1dbMT{>%s8-T;BSn36_%%-+p&>M`!F`=Lu)_iovCDAFuKlwCSGSSz+m(7
zG{xT;@qrZ;tm^3AeJM>-5f@bCXMy2?gzB(w)qZ{~_RL7)-_yr(&gowL66NOwt02TJ
zf4STbWC1XmD`MP_H*fOepT~@CTeMG%_xSPM2S(!{nm7&yz`XDpl~WuiY%sA7;(4)m
zCLB|RxI91J9ssK>3;aI>)<7`v^A69f*mWW-%hcO7roqCAGr$T6aXp0R-TT4tB0rT=
zd~Ur7h8LU2Mqi!s2dp}2+6ifvU6IWDSp=*~G_E!*XY44EkK()^#pYRPS4QsR$0HwD
zH6d<WrLI^NCqE0Uo?!YtzlThl9lO?C2VUHD=;!Ci{BvS+VYE}NNA)MOz-S(cc4_o~
zZ;{yvR-{JH-eeK5p4l?n1>@@V-TNn*wJ?eQh7(%Do;`RU)E6bOKy)60w&VI9eofq7
z2J?yNyaz4Y@|-wiI(64q$CtC-^VJM811tzDxQ#F_qwGEG=1!dFt0ZO!`F&)+Qi;r5
zpTyFjQ&HTKt&4sm3vY;>Q(~ISe{kWZ%1ra?B>vq_G^1Y-yQ^aXuwq$bX_i@=#Z9Jv
z1APLn&{2MC8r*9{7Wg4H-^DabSjDc989R~~JR*$8y?AS4I=7uktdU^p(|)Q<7WpZO
zZG{!eZ&Bkhd~O=v6`R{&eph?#Eym*%#&*MJ1wwvp=e_eK#hH6z`zEGY@Ah(>iZggS
zi-6HNI$EE(&*3iTn7$XbyU=EVC%u=F83&U1GX^p4)Yztv$O3k33_<&D{pk8+5ioc>
z8n65LFX~R@b~rZIz_^jq8v4leBeDG*?Zju}&XM`Sio*)EXX|+nekBWn;fV&>p_d9G
zIrZ}$h0i90vW&j?-XJpVxI8}tjE+@UmS1`n<Ku1sjIM2?iE~p^VL>pg5S26M?sR@U
z3Y|#e-_^r3yWT2U78Xt&w3A8fN1+bBe{H_s8mE%j1!4Q$o!pi8&&cmdY^AXOd48PF
zkGJ*(ICcnWet)*?UCK}Y1I|}qh03|E%s?!XQx+4fg<zj-{_X}DyOhLc3wE>Jq03|;
zFdEA-u{{S0VN*D1vdc-Vj8K+WhX#t01+FBq?yy2-IlQ)?MaHhiuD4>ECoA6BPZj_h
zE5wDL`8L+)uf;xd!??S1j~wK2U}E1bJGt@@Za0$nb51aB#gJT`$h1F``1j+`a=sY*
zttsPX5<45+4t2qXPOrC%;{11F$9FXGJ7N|XW{%%A!DA2ogQjA}-K5O#5Q8~8UKG*1
z|0MByrSW+E=ilxV$Y>^50G8OEXfNG8yaX1G>GxviBn{y;@th<8=7rZV4lQmz0p=5|
zV&Fn`Sas4g?n8SDCjK^(_8|7TA*PwWvnyT#apD4C*pVqe@pDQOjOO|nC(iXPh1p<q
z%?jhZXZobV!pTqjH+H=T?ZCqypC$8x(fKW!cn!%9Mtv7;Qip4JNO#hV{1@x<XcKA(
z&)9t!JC{Mr)y>V1IX<v5@EX;<S*YVju<E241j7N0?9BCIYsmCRvEvb@S#thkyrkg7
z*^gs$VYJ?7cOEBWPhxX@H0^Tv6fy&>Gpta4O}boz(I%QE*lU7ST>ib&6`elFlKJ&y
zO!N5;Yvxd#2}W^v5Wdu^Rw*);C7I7B(7NSp!?%MC)(2k0vY?IFP<0~38Cm6NhQNYC
zoS3GWBu`UImZup2lci~7lc#Be$?EP+k*BF;m#1lhH5KY7Ub~1W%t)2TSqjtA<Z*t5
z*<f^Tf!j~~&X(blo2@V-T@j}+!>xz|!wD|+vuSPqhnw2jkGvUjv%rc+kHuKOf4VO!
zN^w3-Zdxw6h4RSFpI>gCLUOZ<B(oE+hg1Es@2ZWb`cD0P|4U{U1Zz?1_|IglTryi1
zJ&s}huDt%*cVyv;$!w`$qqm0nF~_PFAD8^v=#>;_dgJ4IudcF*%m)`uW%+rV#>a{I
zX)Tjk4WTSm|I=~!&a7X%WL8hG7fO%oOBU)31}oGqYnrt@Pv+?ozu%58HH)9;m|(Sq
zxV%}PdO&dzg&AF;oG@5Yep9=DzK-I;uO~CFU|UN%U(a*u;O~~qwh6YZ%lRi17wjQ7
zyH_%U$K~?;KF&1~Pj{U(*&A}x`z7=92i)#w{Iz;eoL^y<!XgUO`zN#SgmU_4HtbLN
z`QDV9IVisF^YeMyQC#RPxkcVd=J)+#{kmV=<)b)#u-yC#vlJEq6Sv>Fxpjw9ex4z6
zGls=)qf;kOZKJrr2)S9K;<w+TZ$G|BaS?^-@5|%-3bVlAG0?o9-Rk>*&&$Jb0YYZl
z*knFG!|hP$M57K=PD5cPnAl$`bc|g;3yqgsWMX_<pZ;xvP5F7I$jz7*-zSQe^IfJm
zQ(?BkwCVCR4KR2-HgC_soss`get{Wsvu4KEz4*quYbh@Lk=(So$^7#G+z!(VwJlC@
zhQdsR*$UI<#n+)i+unTq^nNTi|AP2BnEAQ}shq(@a<iAj*RST5rm=JFpxg|FnF_PP
zwg}tr^O93|zh<AxO<$hO;F0NkyKj4WFJ9Jk#%tf_ax+&Y^Y6Uk_PcQ48Gih;6{dY5
zk24fzD$E9x*8MAaeqMzI6cz%L<ri5i&ri4H=2w^nCfi2g_3|`58|3CwSP)E>pS@9@
zrnX6L2AHhP0-NP#ZIzcL{GHsi?-gZHn5i&ZVOl7e<rC)R+v@(|qy5O*AvfcvWR_ou
zOa3hOoYKf{xtaUo=Yy>-g{M+}5rrB1<#Cq6v;*>O<o#K0ep|kcf`{d1AC+%E?U>vQ
zg_#Po!DRiDos^q?N?r%wZ*nuw$m?J$Ogk%&GZbcmiS^r=`<YbgFQIdCi(H7W!<m#W
zeJRd!Np8lK_;LoGOld}OrowE6X;<ZG8er*=0iEZJ@NeBf`S}#)S6Dz{row^>vlJFm
zn60p|!XgS|*W_)cfxRrW=f&4oFXip2Fbk}b5VyShjE5A*uFK5;6R*3a^$YR*Y=s#&
zlKJna;yh$q;Or{OFRU>CpYi!UT;b=Ru}8ql2zBVQ?Dq^xQ@<%UKNwE(s1Gi#UTzu1
zSqh7QiEZ6s)T>WXocEU8Ofa#n^LxAVd+5Rn(<90JJ3rWF4}N<4ManM%b^unW4j=V@
zo2ME1EB^dpP3bmp<jR~Y>bK?Q2ZPg5o@UERry5h7c0ZYYAlNToe%Ol4dX&sR2f}hr
z{c?ST%=1`oCKx6{b=d#p(mje}PvqtYYc9k+Gk!r;iVG{uVA<mGo5XtX&(1;$)3eCq
zf(p~J%HskGizv*OBu~>;m^V2-PHbxntfJ7Kdq?jdNA1b7WsAGslbX#pn#>D^7k_B`
z6)L%lUkeH;%$t&p-<N>>rA?*VUr?GMg?Y1QV?H6jSM-kfQ8t6qA{J7ZH#I)LePzpD
z=Wz=2rYYhS=5;CJ6y{A=#3{_{R>UdHo1utPm^X(aPGR1s6mbgkYKpi76Z?|)>1_P7
zLF{MZXM;Yl0q`32-Hn3+{i#nxz}^wYx~Hu%|B(gq$xSOFw_q{3>80crdO>bRg=`Ei
z1M)hooOqHS{~}f7X4aIOURQ2*Bf0rslbhB?UWZ^ux#>Q+g?h=&=r6ahUvB>Q6m=LW
zH*2)qjEQoKOp}{AOK$pnc^yKF<Ys&-xA022`PayeeJwY0i=qzS%gx>?H~&7lX|~*~
zV{$W2XJgO7L4?MFPtHBWX<p`W<u|$MXXF+<D>v<&+ydw27P*j(KSLkKvl-*7PM~rI
z{*aq?S#H5Aa?`KLEp%OO#-H(Z=yYoppPPnm%1w{RE%=w*w7=yRxFfg7-S|5EJ_s&U
zMYnt4p4_wtatr<|H~pd9LXYHTJc+MEn-w4N&-g-cH@nz(Mbop&Etn)XEt}i|DRPTs
zPl@ZFIlFz$&sPFza?{e~7Ie!^&mp(aQ*tw&PGRMR{XH%3(bBZtZMfA{W=3wg*?Ht<
z<dd77Uv5Uh6jn<p=gRQ9E>zBNA-VaB$c;TKH`60GPcgY!#pCPnT!Eq^shs+Aa<kw^
zWyQ9Riz_8JtF+woGIF!Z#@Au$mcIPH1n-M-v&+fN_mbQqaO;$~{lxqN73HQ?imyYb
z*Bj#{7w33nR+gJqRc>ZAxoNM+&8#6etyX*;hPC{BE|oLrm788$ZlOAIGwR7LTwiYf
zhAFHY6pW7V^O?UXl`{g?OR$UO7Y-)#H&VobN#h!)@bCWPaa#QDe+0}U<R?CJ+S5cH
z7X*{V*$QJ#<!J^K#+u3V(-r1Zn5nQ3*y}>Oh;8O=E-#B;VL^r23S+Oy^V7j(<+Q-W
zdxmD^YtHYH*9^J&!SLn{>YvB155Z)d{oU6hg?%sBn*C$FWJb%B%zJ{P_ds@Dd1WD4
zL}6wtd7R!_ZZ?>Bzv2hxhkRV}wvn5qFb{lzSeB-#FxE~U=T}%*VMcp-njwYh9prIA
zg=rmA;_fy2^4{I|X!{uoGr@|$8>zpD-<b?4ECN<bi0jhO3Q~UFPAUAi;c?7*`C<Np
zWG2}EV1@F_efR(lr%wM2DJ%l^tPsaquC7dRp3ZVJ!04WCEQ@&E#;-6_VV1&dg+&ym
zb&;1-SD2wNzrsv~Sqifi7EzeiRZ%~M84B|&%v6}AFk4{}g=w!V>ZdS6VSa^~3bPbu
zgB2C_qi%P9>___%^QG|Tu;RYbbK(5Y$aJupLfm(4g1B2b`)vSB977)Gj?5ynz;Xz2
z;xj^QFi)1)Sdi`e7ha$^Z}$}b{4*?z_>5LRm@F>bLmsE~l$#e!OtbFdC;UEKt5>{<
z<@EHCr)elGpfF2eVK7-ajlS}-1Qcc|EUYlCpFBS=m{?A+&8+?@td7tpTrG>`rR}Z_
zkegp&w!-u`<!PD<izv((C{NQ;m^Mfr=U14mFx{WRf1erml|tjT<LLy0U5jaN$t|KV
z`)zrg^-c=^y+O?HWTQL$zI$!3-24i&6{f$N!n}|V%^6m2JIv=c0kD#Sja@J;AFMic
zx4`NP<IB4_<_se<hNSTCNMjv-dTTuYzOO&Q#(5Vvpg0rkV_2cG%&TylkAucgxoN}X
zW-H7bE{`)t$W0rW!oRzU^}A7JB>ygytuS+xJkEGuZrTTOvlV6rQrKTYdp@3>yph^E
zG&+Sp+W_mZtzn}UWNb`I-2D?DS}FYcivcDc<0gOk9ltLq04Cluv~Qw`hc2hTm<kJm
zx!`@Y-PfJ|YdOVP3JWEq*?;vXxLZ2;*$KA4!>JF+!U~Hdm{<okR$f0%VIDA9{d9$S
z6VepxXC#<dKcB+<2`1JrpfFQmK`>eUEQN&<(iH1wCzx2ju)-n<Cf1LQQ*1wldB9}#
z(-r1TNK>qzkziu|d<yd?m{`967~X77`%(VhhqF_kw-x3YFOTypETk}Pf;>&1!YqZc
ziSjfJg#{HBQJ8m93TrRiOWgRwn*8%deX86%AEvMlLfpeyC5O{?&}Pbw&5rM9E4v@U
zM<h7onU-LU`{n$U%maoupVD?0pKYKk%&Ra%VLpZV6&6sKsj#5JEQN&>W-BZV)>CND
zGwwS48jEjE{57Pq-;_3KJJ?`&(<5z%r0iYz{chSkxf%22W_~O;`xCio3*}}kN?~_}
za{f`PbZ)AHxma%Y61izh<z_6CoB65S?9Woz*GaMVy!7TYEVi>h1XjsSUn95hdbye3
z$j$qm+#;bAwpl1=<za76rE&&;lAEzlZtRfUtRr&sos^sQdkTLJE6(|vj&C}i%Bd^N
z0Fzy3@GHy&^FRi)KkQq-coO9oQdmS`o-^_^4TS|1W+^PJFzu|oEMA5A6&6&O4JKYE
z@?3rA4{A?OSZ;oWg%qZpi$AVB^XfW_=ch1TVP1t9U=4--vLZvr%h}HUZYfMVFOTyp
z%mx#Wn@`?27ohyY3X3QVzlbkOQv(yXpMTTmcze53KcB)Zg|UnBGz~CWS$qofD=eTe
z6ATX|e1F%CfmA<BVYb2|3e*0O=cg;oP?%p~rot?R*$Rs&OuLlA<_PV1?o`S3)SkA&
z%**mP<BHt0t8%jyW?qYrD}4JbepKl6Yva1yv>S4>6=wb^k27w{O}mxC?hEbtclk-Y
ze;N_FnSaU6zAZQHj@*p9ax?#tn|)7i+5@>6|H{q$Pj2=@xoMB%KVzSJ^h8J6?xw=D
zCyF?QY4Ai*@iYCn{1m2TiH}=fzS1#XPK9Y%6>$pFk`!?Y(~`5Z$-*_&ZEr5+_h+#b
zxka+eEu1DdJ6&#}47pkG6T$eQ0*&)yDplgoRI?R^KP@ba(=@s13NsYu2Wu>pGt@XQ
zzqV~FOn+J)XDTeBFe9ftO-o@~E_s|^VYb5b-10O{g+;)I2<>^cbFC75KguIFJ+Its
zh57Tz<Fx#8vl8sUH?^8kIgJAGaiT>OW)_sk>4oHGE6iUwJA<$B^Zh8t(T}rHIeo?C
zW|Wef_eHts73JosCO6F+Z<8kdIF8E6>dP(CL~h|0a<kjXE!0JBR*&oq9vi^hvv;Sv
z?@~E~edT5jl3U<ix%o%P%{N+Z#>DJw9BgSCKYv@0fu}tTKfLgMC^vnM+&l~ArhO_m
z_J!OcR(3WG%0%V7)ou`826xICTqieUz1-LaxmgPHeJzjEHpW}-S5EQoyoMC!-z1Oo
zd?PnoVS&x^IDJcYmLjxg58uTH)Sh0284B|$%%5OK8jagY`2`eaDlDil3rsxU6t6>v
z6lN<dtgwi}*j9O2G=+H-ri0}Yw%_#@=N?mg8ejzl+jJWq5D))wpY|)v1QXAhM|@Xe
z48>Vsc)^ACzbjqgfwk}t(=@-0&+mgCd&iPl3bPd!QJD6fJU?AwhQj;`GZkhj%vM-L
zVcNFrET1s<Zo5RAOYQ03E;svox#>U1&D<fk$d7U}eu}pPA9X!M<+OImP1_?k|6aM-
z`{bq{kehihJM#(0;-R-Jey*(@k(+r^ZrT~SnHS`yU6q@8GdqJvEb@IU--{pdIhb}w
zZsr5IX;0*4Ca22tbIHwoDpfkZSPHWh7Ezd{$@9|{W+=?BFjHZc!fb^_6sA3$$_5Gh
z`_I>6&l(Tsl$(`XZh^dVGxE#LQ&4V^LaD5sP|gvfX78c>Jy=9;#<Ox`MdfA{lbf%E
z+_e9t@@K{4XG>dm{(h0lX(-H8n5{6aq#{3snF_NNrj=6Ur!Z4tw!*a1scf`x55bXv
z4<=E2ddteqUruhp@^Z6ZmK&=oH~kg4`D)3{tSz@tJ-J01%FWYMZpLe=ao?#(Ta@oO
zwP#Ra5rugTd77re!V1${$kPlc%vPAEr94f)!a@quTBXK4ZzkoBXMUyjG!$kk%vPAz
zT9Kc^OoiDB)7mKVQ<$kRTVYz;RQ9wm&W{{2@gHhWe>=I^?d7I-l$+T}ZjsJ%GrGoG
z;N5SEQaP>H<)(F$o4>o<>>hH{d&$l0of`LC;s;kx;;nJcxs$Cht&cp;P?)JOTVdK8
zscZq1i_Y<O*Sm6<${ALe)mI)D=qER$zuY_n<Q4&wo!@G2%1u|8p)kL~OodqrvlSLm
zm^M&RKZO|z^DE3$n58gVVG)ICgB0~sn4vJg!c2u(3bPd!0Xr$|N0WzV!D*<ozq7Ye
z*(t%Yj4Z;h4{C3xvJ!&bYEkYi#d#IxS6EPCw!+vu^0Md(^C`?!SV&<Jg?R?c%V~f;
z5{_eK>m6%D?P<R!H)B{Tdo09#HF`Gx4yrvuZpQoZ^YTp_H}iXHOoiDB(>{==X@C_M
z`pca2y|H>uKMR1Z6>LS9?(@ief%v*V8n_lO1v_!!F>>>bkFWd4FK+haaTDd{n-X7#
z!!uX&d%=SW3oFbsRi35~48LGV$1(A@#e-lQ1^aj0jsa8$bDG=&(^J{sLfmX^QWuJ|
zK9pN{Mk>QEtWa6DRQ};Pii?<XW3y6OHK7mIoPLmh-eG<uH_x0@_KFbK@xTfGdAK!K
zZr=H+Y>9A=7x=N#4JxO(KyKm1sVpeOZS6nTLvi{txdoP|#$BHm@8>fW7F3v}un^cE
zP%zpK{TFl$QaQsb<i=LY&9h2w-Y-&_F0{*gr8k_W{Mc7=3$2w~V7=VD8|Ce3D9ooY
zzrq4w;<cbD_R@A#Km8lIg*V4r<yOu4Glb2pa`S$tsGq`o3iB&005)CNkCrs=ae?aR
z-!3mp0IWBBGD7|A^T~Pn96GckK2H2h%2rrdVG)I~ALaRJ3iBvTSD05}hQfRb^D8U>
z)*3bnwRNwJH_y{Hih$w4p6s2aE<O(WcBZl)1RM1FDt?c=@26C@Q?N!SYT#{p47vjI
z?Mh|i1?#h6>m4#}cPhg~D8Kr<&JHIFfh`mIQuf&y{PQt;uiV1><rX<8H)hLCJ1jTP
z(Nxw}C}*}hYw#9fr|$MKxdl$hP5)JH;Zt%mf0LW{Oe({h(WtG5^eA<Y${AKz;A|@E
zDb#Q8+wb%3?md^v1`76V=>c6SP3=M|D<s&0c`M401umwt!h-#pvU~?w<d4+2XNFJI
z4}3wUUrLR8zW4mOy?LJqfV~25r21XAM$D!-8_XlvmFZV{k+I9Eard<Keo(qFnFkDS
zIHNQVefJ?hzK0a%yCRQcSLGH|nD?4IE)0fWVxn>``1VkLszdO)+<Z4u`R}#j$=11I
zw|7&V_NUxJ3iIET$9Zna%~n_-lFIOl1XRC)1GBtI<+KuPj=NhQvM^XNA#Ug9@=eIJ
zzhZ{>7%rXsEC0O1t1v%U(`cF)C;slEtuXy|D#OVy)&b)l+Q%Beg28UUEQRTRr?LZZ
zra^K4blQxUaWdonOJ%18OTV%6E}4;>#?0tGhWY)np!%2GQWTb&#;*%wT<+S>^YcFw
ztOC47Wf`^eMC_VeLfp22Uk;-Dw6yp%MKi$i3u(qZgGgZ}SRo-!d<IHLVG*!rgt)G$
zE6PzhJ+3tV8(diTik<#_mCOewi!&7#Ql!b!<!S0*^xPOMi}>s*pTbNqS$kRvvlSLm
znC4F7*A=mxSv@}7<(&ShgS`};*P(676a0XiCXX`|<_D9d>CY`s(*%1SGN-<4zg5pq
zWw8~e<w@h;ox?ha&*;$=W`Mbc{M!8pUu=MXxWD_rG6ef}N*CO%9P=yU0*W|O5f@a%
zSzvVDkM$GJ`y&d|^QQ6RG{*H^(8a~;pfC%Jj;R>8IQ8cv6ldg<TLjDlZ=~(F;IV~=
zd#BAj`Q>JS;mw&8_uQhlE>WDNFs(ou{|+&hvulTXK8iEJ-iH-RbJ8a#`537eOk;TP
zMZ<&5_{O`^C@utsKZHRh{$2<xBsVYE#^hLB_Mvy@QJQ+uH1>mF0sSJspGYs6#^AC2
zJU>^@=YOC$^My24Sg?|}oAI%nRZQda0<1&cZdtEVoTV_|%V~VBk8!is1fNixR!MFl
zusZNYYL}a7dD>E(r*ayf*I}B+^S6fDM)wsk4gRLMjXnJzk(mjWGO^PJG7GG@5Vx<y
z0zNK<!JZdvd)LkUehp6*x%m_pR9F~HRu-+Q+`M42at0I@QluGC#Oc-KW$}T@$`Vw>
z*$QLT<@xDg({URy!-sP*`iEm{7;H2wu}?IE<(Eg-cSJ`sUx|%%&0#(F%!|A)*<iFC
zUIQ!i@VT?FaN<~vG(L|s;5BissDsgQ8ZGWP4MxXeG;wYd0HZcT6OTtBu(I$P)&Wf%
zTUpICb{;B2*1Eu=Qt%e1oIY>t_=j=%p3N9S767AmLDO2Ev&r;V(^zRC%}!-L|D4RK
z9h<vh+~()Y^L;v^FuhK!&G5lQGpfwt=T$ziWAGZ*0j<jXdRt)O)WKgjjor<fX)WQk
zhFb>wMy5ARV|bo|acHv}73arI6Ktzsx58xxQ(T}?Y};a7j;%j*C$qpjutI5y$CWUc
zEI)5!d7K|CuaIVM;hfS0!~TW&wSwi^U)S>Snl(w|ztxT={#JVc>~$edd~Ppm8Y>IN
ziO)LL73Kq*CZt*UROQaF%AhMStyye-jcJPWYp=rmV6;DA+^XvNuE4@cGYD24{-(Mg
zIQW-N7D<R(d*k~HWS-`+V=<;#p-TI)WI?cA(Y}lJW*HXSAB;5iHoQjpRj&DI9*T>A
z{Vz3Ur$0ZQgUr)O9%q43{qQ<k>kV(?A>FB87_0;QjrpN{QEMemtsFBt$F@7#t(RV0
zKo$aP8}0LGrAqXzL1w+4#umZ~rJ4Tj7koYu@Wu8qoPdbqk_Co|U>w?i{;z(3g;N&R
zO>Tz5f(na(brJFt&u{(R<rYzxzlS0YjLyffesSk<J>_O7ETAw;VPP=p6Id4U7@+l%
zn->gs0NO_4`DOr2RzFK&VTEbE6=hMFAB>J;SU>SNW-81A!;2MEKk?kqR#-$~S|53u
zy21=Fx?X^Fc;Ssj=V0ON4*@U_{7vQjw(Jo<nFU7YM;P~2`<!?fbmAh4{IoX|<y4pf
z)*I5NvOM+1oywG-4feZWksaCVl12Ka@n`R2IrDD$avhn!UmAa|AKIX*ZFZ6cz;FPg
z{Ibn^_6%7FtVDEd#kc_%FZ1K3J|K->2SfXz`^BLYXM)k(22GsX*kCx&Qhwt3bOh{G
zA-@-LuPMpX92h@lHM+KIJy{s6rjTZZ<JHp1^g;34PdvZ%gV8(-%PG#YEHIpuP&qqP
zIe(MV4EodfGrTb_OX(1=djzba5SO!mn|u`KeJhPUCzyZ0$2h%UP-W&<SP)EXvn)HC
z_N2HFSTR_ka^@ZU5oYhC83C&$*ss?%EFts09p5f}|AmYB(YOHEQ$n0pzdBaaNi(Rh
z5ZEixI6Q%CaqIK{QJnTp8mk?(cCc*n$#eV3{9r4h+a2x4;W?*}1>Q|#9|^YQaKFji
zhQ!VrG4A&bY5X46Fc=;C(dy6m;5Nniho-Ryu!3#Y9+t&MhQ1}UhNZD7DVc`H@+yz*
z!(`#nvHpVgW$wir$UI}x82qfKlO~>UEbOxRMKWVjEDlYKGr_)$=GO^q{LKPGC@x~A
z@y|QZ-tX3uU)%Q1Ok-GftOHKk3fkAONDTXur7+Jdd7KG`nNylCU+!>{($qgnWA6&K
zb<eeXWHy*A&ObYiEr`x-u$;XXt$&N+Li5ttb-|{5S{vWu)WN?XjSUyfTOf&#OXgyE
zn&G8sY_Aaa@#GrV<W8Et<?{TrRk3SwScsQ(Z8ODrz$(BBwM&WDy70d11H%a!S+4;z
z7E_!b3^pyd4vi0uAPaz16RiFIeizB?1luyI3LnorF#Rhh#MSM*(m4gj?e0sk?DKN)
zat6V2332&Sn~bCULJ9WQ;zoawg~8~&*x7!+XW&rew5RrE8p{WNQ{A6k{qPMk9jusO
z;<)4kdseU|e=R&qai$_J1Xd+F7T{cS_0pfVP@M6V+`?;OV-LoaAKe3YC#MeHwQ>t8
zj9KzHA6OwsAKL}<6VIJYu)=~pHDXJ5Sar%00;A&*#x<+GJP#RLCpRw`jn`cvpuqi9
z*aM<{9*njF+V@4LA0#uu#={Dh6Rks)4Fk!%>tl0Mv|@L+9w7^W;b22?k+Vh#vIrQ>
zmoTnDl}Am;^bPUWV)y`?%nyb;9HlvU^;SGoI_={7I^Kr7bPB8Fn6WXoZ(@F@HhuAg
z%v6{ShK0ubUWet*65cx$$2Q4L2m3182QjX8g}Qtj8Jl4&7p(HF(|oM+Z%t!$h5Qa(
zD1p0`QwLjN`nRwhl4Iq3?Tsb;_~#G7H37l0O__0;(v19+#y%6u(x>SYJRCatu{~*Q
zrC^QLjro$yvk$JR3TZx?mwy|X_fQ(kE!cDGmh%0`cQm#?V7oLe`_n{<3n|QVOdc0d
zSXg1+<MK3vU^ISWIn5Qtr&Bq@3iF(ZojYNic#da);dwjtrQ+{zolj|o6sDhy&Al<r
z2km3ev+^s<0?RMtC!UYlV6?wun&S$roK0n6zsgMq>n5bBuSnZRahAgLQ?cVF=J)vE
zPs1tBt1ttsfso(wSG%2~I18+bV1eU>`7wu`mYV@qPl%gwsry=<CRkm;N`3WWkWBjx
zuD=L&D(zTKvH%#qk+yBqHicV|8Na77JQ*ablu<uI7E+jgCXI~};&x7WV>`v!V5VR>
zbCsw=W}Z!B?F8FW@+5C-7LJ`a;&#ZtVB0?w7f={G7dyAWIPrYUqcATR9dj`5WN`Dd
zl%G#w0kEp@MryNu$>aZ{I2#O4UdXC{-vqk>gQ1Ff&d29xKi};HnO9*xFmZpl_(nlI
zOgL$pVCk54^cWzX7Y7w)CFD1G{cwJMWGgHJ_M0&7-kQ7=i{g~U_(N{iW%)L;!LWl+
z9m*H-jiEI4E3wbVa2qxMd`)*U0}N02C@#yRPktryDdGZPvi!neVq1%IKJ6+TJB0jd
z7Ww)U%1;NYCD;PJk(Vr>FdM9Z5O+dP#%Yt&o)Lv<*J9V!uwCZnT+Yuoy$bV#$?6wW
zn5{5&U7n^6M)L_DlvA8f7=OmbGc<8NVS(X>#%+tXBiFlp%+hbh@<S7k4?Zv&2hqfF
z&<3Ni4ow{EytiWG8Jakrg~3X}YgCpT-JPEZakh~s65FRSP8>tL2`29EJ}}yEG0x*p
z<>Q1u!Nh$!07m@`<HUYugHc~Xi|b2ZG}fUNFI<veE7AT+W52*_RKK1N3t<<@tl#a}
zHLGs$ns^P~4~Cr;<Iu$G<q@#nf{p*M_<UG(()9lwZ(7Gz8DtT#XN0)8YvOle^Lflq
zyw>aklf{`}1%))lYq%Cz=`682Tza?T*Hjk$A9<VshLaMi`^QDM?WQ>GUToW9ImPYg
zQJ4;PR7f-M-KkBKruTkqu7PRh#0MF|KPWm2f<1;Mm8I?0Yj{fQSolF2yOk8P7n(fN
zoXma<*F3VuY)N`CK4*wzaj~pIyBwX?4|f44O>dHmpZ{T5>i3!VF_~XsL9id-ja1IU
zsijI%Trk<ikExjEil=5YBa491wF|Td#fPpY)3dqwJQ6J>-@_+lhQj<{@539ZEQjXy
zSWIzRii>~lglT?Nf81a)AJ~oP`2$+F=S$@$Gu=>!EU`2jKB>g#<(?cawgKLV`Qf;h
zH10OvM(imUKaWG}zr)7v${;DGgVFgk+T4Q+7LxfB;>wq<(V8rn5SMMhZXOo~s{wDM
zvfTZ?3ucv>pXTE8Pt5N@=QStEOt2ELLUBclb-qOw0u#$Q>%k>{Ud5hv@!#vgG$&@X
z!R#~h11k-GQ<^P~*X=;&2gAlCOD)*p4w(st2RyQ_Iek6IygB3Z8+hhNo6HX;=2vr3
zj;3T*LfqDhRui&tLfoqAxxOUx<ciNPRDbviG6PJ^FaM>3v&l>_u{|q~`Ro)~2uy6x
zW#O`2$yo0AxKYb4*Cf-y#JH2c`D5(~RutYyZT9YGOL#ehU}8Ckcky4RG{azXqjA{C
zFKlekpDdWi#Xs*yTfIJw?<=0XF8=K3o?xpQXXV!!!eB2(_Z76Ud%F&&G=2G9{Ikej
z@S=F0YJyRpKoid!Err=&RpI?ucZ?I~?4ANHeys~FYoXLWuwb}T7+{TINpW*C^7HdJ
z3k+At#Pbdt42E59)1TeS_mwbMMZt=#obeD=o&5BIu#K|D;yy~<&5r@$!Y)=f+GbeJ
z&cF0|f#L$sz<35nbSw)VcQ5`L=uGA*4f~2<izbK1k=YeoY<DzGj0^8SR*g)n6mM<)
zsguc!DlY!n8OH6I^Z{1ase`33t*VRdg7;B5ORuuOqByNuynWg_cRg;^V{MK3iJu?o
z3Nyg)z(x6ao9rJ(X_{cv=P}KXtw*iNY%tnJXk(K@OUXR1xcFxpXp^c=K1${Xdl^<J
zzgmm)eL@yem{vm`=Tn#kR!GQCyiOZdm{wDfpTaD#GD3dlFO_(kMHHsja`Cw-wpp=5
zB}Y@c7+?j3G@oiS3a9B#U-E;w1rzT<4uE9{Cf<W=D$=yT3J7sxS!^(mVD~P*#mmXO
zE`IKWb-4O&v5v5C%Bh2S;BVUQVw_K5CRo2{91c1g%({I4^Sl}x%h3)$J$yebocw%X
zctF7X(8_;3%m)j{!iqRg?b!H<agASVzlh?zVD$M4+Dq-qtR?e-{RAtR-y5(z_VheH
zU-H#aSY3tHbFo*2H2>VRdNt)20;6#r^ApGUu)<h<d7MXKUNGu|m|x}L-40P%d<qMI
z;Y5zwW$EBU{8$_Wt1VcL=2dc2nyi6~-}j68-6-`Uc4cS#dBA8ppmnY~33oZiyoxwq
zLfpi{SKCos0IV3SU^)B3GVVSrup)wq$J;O%Z3m1Kw*zY^HxJnJLYm_J6Fx9HZep6^
zaWeph2Q@0Ec&|eUjOI2NC*JG88oAgvSz>WlhVHEoZ*kg8Z{p&g?PA;?oz0KPY_Qfs
z+_TSJ+(;H^=HmDIVVtYlMc$q^*i%AWQ&#wMiql_{#|6OBqsMnlvrxyGxcfWh)LO!^
zN=S3)m?qQ7%vLV;K(KW!&*)@YTNuxTG-qFIbdJnw5Bb3gwkKvJo{NUSe1a|Qc;+~)
zI%V;8a50>$QQWZYW&TIz1EapwA6^vulBuu|81*xZ6Z=_2VV;h$eui;kAM`5B2S$Am
z<HSA~R9F~{`WeQF{mj!zZa%Q;@P2GFC%?VVJq4>yds+$hzed3@8SCug_x@nqFUjBV
zzGQ%jY3`c(^=yg@f>neS%CBXsiZ{q2U~614+d6tygv{s{+kOM!MREHDz-SwxiQC8m
zqp<)@+zvJvwKba9)>{8qo1uyAX@KR3_Fc4;#{c8T)X1AI_HSxt9ne}W+x-<Roc7d*
zxfnJQ)*WrswfSF@vEeR;H@u*|3CmS`HeDpsMz~m;Y%yClsscZbg+|BH#5gfcb4;ww
z27-xg76PL-L;K&EoL*Qs<%}fQ!dCO&C-aPrkF)j+I!b0Fn3!fD!NfGJ1QXK?Cz!Zx
zwQ;d+i**pUt*$TwjJ7+*iQC--YYVU8c0lX;&5Bd7aN329j~xTh#AAR5EIm5bq3v0<
z9uJ33oPUCgHHmINv`@0Hnn9*bj~zSE#AAm6Ru*2PvWR`q1nVp0H=;)M)s&`hhKpb4
z!!)zZxSN;EW5)K)LGWUZF-L2Y`N5#;I{Bep?X?$&Os5V3FzmBf7C$WCo&HpFGHs@d
zeI{7H-JW;I!eDg;dwtIE!eriAP`~JYglX<R_9EYp*c=!C?lIawm%Do?P6rES&nydm
z(Es*{zp%JYIYWzM=Q(KNy<6H67sDL~>wq81-*k<#VBy4t!RAK|3qPXKaGY*C77V)B
z@Td)j<&+lvH<Njn#`cGI;YG23`V|%gqjMmP6VHKcupICjmJ?0vXAv;EmX6kK$Yc*J
zoN{`Xx%hp}Xg6zq*n}(q)-~GJXd~@qE4VF>^%t~zul(7G%)7$HpPlj^y!fws9Pdk!
z&s}U7oIztb(f+xzm7h-=t7H8PZRU{s*mRlg3DzF|rntdlsy;=geH9-!p;ili4bTVH
zGur1d&7^aS>QJ0#t&2Yo5N%24^*Ee5`9;8j@HgeRZ}rXHWFgDNLQxw6%L~m%-6ONs
zxfrfs99r9|GjSKlOmn@9eJa@NBl<NZ3vGz?GmI<L?XSsX=GQK^E;<&VomkQ(jm-Mi
z#hOR!hgR`FeIl7}8_aD4o7eX%-e#fgE{6L#mGj1?IwvX4_};~EW0GZ=zlyh~4R%7X
zF6Hv&p}24e@=K1z^}hdJTQauG#h#0nWhlJpnqR0gnSZy7jer%*5AC<NS1lmZ_PF?G
zm}pN2-|R`|2XhH&+Mm`ePZrwiVmP=_nrDCXVX+y!odx%~*et>3FaCWRnQy;~WslYY
z^Xt^VZwi^;hU2D?U)v64_;D<7*yVg!M)|dyR&*J~d5^f*4p<>O|I3VC+>XZjHRjiE
zZXG_JSztjS?(=KiicwtP81xCj%KKY~$b83L?9J#thG`}p&C`I)Iu$$r!wW>0d+g@>
zm<@&-6U&L#y2xuSDJ}wros~>{mV$BG#XldzIPvo_8?3qz_eyFFOw!p7p5Nr=2lK-F
zD8CJn<9xe^z@8CI{Ol~EFwgI?aTm)ej=Kg}hLEOsZ;TJDpkU(XY5|1>!NhV-YyQ<$
zNXDtV4c1IZvw80)IK6O8KNH(Gv7Gb2%KbfA2#k)mXyUy9Hdr}$joK{OVC{8^)6T|Q
z#@HWV)|{E2kzmJH1aUZY%3>zii0(hnBeTKE!V2a0`@f~@l4;@i{64PVb2gcgV6}T>
zyFz9rSj90eJiIt%u@mf0soffxb}l}@F?;t+Co>YP!;Mvck(mirE@Q<2GCRS3-BP|9
znRY%tzpbC-<Yh4uZ1AYgrzy@%u&fJP)hDwPY)7TV#mTe_@%epyV&---Bf$pUj^J>U
zx&0EXK&~gRli3M&clhz!WZK2}{KhW$mCu)q1bgxIZ$6|rGr`(#-^}N<c7n~%{Vwlk
z+8^=x-Ml-T_gy2wJUJ_Rczy}i_V4Q3$m|4L<0@N^OuH1H-^uI6Pm&p6U0{X!b?0x-
z^&_*vW=4+zxc^OlC+kgaSKzoQ*opGZf@J137k{<^#?{$X`W3PW*c4cy{F;4U^?kD7
z_4xh$t+$6iO=f|K<!oMdR6a8OM!d}}R=**cm0<s4#re3T{}~_m^}|6mc^ufQutMeZ
zF3a|aOuGr!@`Spd&ON&-ng5oHO%meX=rgPknI{svM(woA{^Bo_dBLzkl;80ab0(1a
z6czw0D#ZCiTljXjz;Gf!X+HX^0w&3z=q&VCeEk;Wp7I8n=eCPsC#Sf@;kAp&!eE^Q
z+f?S^5HjE2F1Amw9}e!|{l$03#lQE0b$?;^)x#7Q0mB`Y^83Dk`x!F-T^Gai6te&N
zkD5cq{(*Bm!Hn)RYm=E^9|-nqm3R5rqu+C}EW-BN)1>Iz6c@Pf;`b<FIcJoOeRqdF
zaIro@n(wSPkMKA!JTIbh4takl?-Sa;@wTn-%>5J>1T%!V)YjkND#LB0{paG}#lW(p
zy$3%S8#N!8xIdKswcS#(Fc?l|s4T;}9<5AfJdB<HVVWDOx6VTr1bbeHOHLc}2U%EQ
zo=5TXm*XjCS5cfFY_5>zv1?myk?D_JEFjpn!PR)24JK}*ti=bGr#KH>{ahr(O@6;s
z5wZwat*GHS>32Q%^d|FWN$2-NkAfG=o{imGXo3AN8i&@gP?-qDg~4(PR^#WwrO8;<
z_%y4G$hC&d5B4M)hlAV;e;>snIosAsO6TJs+H=?bSw`kdPUmw|?8D;RGyq0(Of+$h
zX@hy;HQerK;ylumEuBCA1ubPyzTaVySr#yyG*g^-ACi`m&hHDtIPtz9FW9p}+|FSh
zKKA&*Xq>>f(ZiRFhlP`01gw@2S8mtWeA{}nr}KRb<2tk&<fga~7<N`HX8@LByM)1B
z6HI)5fsvZd_Z5tbo3n#ad!mW$=}C*VCz{xvelQ%Qs4U{VJg6`mte6ltXzdX`W-(Vf
zpL=6|;@sP#FfUlP=y-;4-}McZfrZo7W_mgs1AkLF^E_Lap96W_vF#p!_lVm)2=<~7
zm-=tTGqCEU83w}x7p2)^cy>P4=^5$#J2(M&Px^-g=EK5?3xc(QzbUTp`gDH&uH}gJ
zvjDs&uAhO?+#7B7tbHadoHPSqG}fX0edG$Cw?@EdzeP*kRh*y0YEQ-6<N7PG8#rm|
zV1FdX%K6@y*s~suJn8JmtTEf$emgd=6KCg7=jT<U;kBLj^AsQpgHburw)}p0HJMQ$
zou9vBVw1+bfTuQ@Wht1>uU(9V*BYJb^*LDx43Fs8o@gnH@}47Oh0@u$XrDmKe(E1S
zCyEqK=bx320}FleY7L6hipWg|YYcD1{4j3$r?KZzn_#U4J7L!5=N9Z4d7KYS7H5ND
z17dzSc$^*Z1s^9OV5w1?088;&EPFPc-vfen;<ItQUA$m-qH);yI!x4`f`!x80Z%&r
zY!~f^<KI0Z3xhR?wkKMVKk-+-qH)F2SwkocmeWb|!TM}u;j-!Mj1c#J(Pm4@yyena
znP@-5xQ5eS`hhG^5snW++=9Jp@Z$@ooc>Db?4@WQ#JC$xFJqM))2pVlc7lESZGkOh
zo>$VDUr2M|l3|U=A~n)kb6BA|+_OL7^AKOnboRUu*QV-cg(xmuE1h}7IN{z3&700P
zq{PxZdoh)l#osWU-zPT-;`grXfWy60hagx-XhAFsTJy@qYLgkSrL!+!g{*3}<`$W5
zq%*t*M0TX=kEh9OusMQt9)7A6nb{(p&rLDEi4)iG^D$4$bT%<5GtJ3hTi<@JB9CjE
z&U(NK=7)CP9QuGvYnRTi;iAo3HgFkP08ED!jGF?>rkln^$U<QK1gr4Rr9EUu`*i+W
zl2hTu2YYU=BC|TA^UoO29{0I~*)rH{EYLBXUw=U>{BsfPHjahCwnh63+QM$>_sNW|
z>HN6>XwByJ!{*6M6Ra5gjdehq|64x1q~w?dM%Q~1^V43J$9ci>3u)eY#~+|HePF3k
zn+8j9fA@p6iS|#lA5Q0~L~)*Ov9SP691DD4mJpY(L5m#}7wD1BYPvG(hjFidG5kE4
z;ZJ8--7%{-BTpKc?}K#yd_Ig5pU)QtYXq-ho1ryc)+iUnc?0SE-eolL*?nQKlF>N4
z&=Wk6yA#D}qoIEaR(f5fhGZeIB2oJgmf|(Q2v`-tN>zHF@6+Bf=`1PQE*RJOjbr@S
zZ;nmp_ZiOs6TdqUR+v66onKSMIPsdQ3DzZA7Bq2wrj1YM_e7zI&z>?BrcH>AOBg3U
zd&;XYKN!vHFfMLh2S)9QCbp*yRtH|gZHsnz_uu^5g+5VU79Us(A#U9#@BnA{hx@Iq
zh+~uF<<!A&V^Uef&(3@bGr<Z9apL^b0xK?9+t0i2gjJ`UVX&Km-Pk#h?+@A(d0D(*
zD}}ggfA_&|?xg9NDvvY3WaadO)fLhlvS!U~O4A0LC0O;nKjP_xlb<;)c7BB0uW^;C
zWyn0!;kXGa)SjVPQ*qdL;w-Qlg0<>7XagDhFgAzAG%J7hDK?W6=LIVTe^Z*<TL1Zo
zEC7ZF8M1zN<_E}Zu-wso)9Hh6<(o~Wn=obxak<*wYfcsb(*#?Qd-Eq`K`@+OQGS=g
zxA9ciDW@?r*5^%l?McNo!^i?)VOYU9w7&J)lp_nyg7bjraRuA_t+nT0BQxj3TSl!%
zxC=P>1?IzXOo%I(n*Jr3y&#>f5-g`xcPp8`B%NUcVp%Z1g;}d%7je?`2h;g;anR0H
zKZHZ9V<ClUOVin2cps+u5iCc3ZNEry+Ol+p-*6(^+i}l9ve0^%(?+)u#%--o>K2**
z>vVpP8QMJiB)@)UZ-n_^w0>wyU%rjQfKyI$b2_UpSo_J{aT?^9|6ADq1Us57;|7`M
z``9@%rrG_AjxZz3jPruEg}<o|;~$KiPiBFAloYe9rE2yk(|4w`qtSUCrdi^Z6do5k
zkj}5$V8<N&Qf)rx(|%6pzt@9vv4x-Q;C+c5O6R}HgV&47F0+ro!l|Eb!?_InjpanM
z9z@QOg~5K$9<#p>73F<5bSj-qi<Wa91k7KY+L7WS=hON9-e}@|5Z(*0-$u6|R&3hi
zn>;RbF`dEV+nutYReyat-+qx>vH8-+U_)jf^1#BWgC~;CCPcRpn)gKR&&Z6w)A{|8
zpTLXaJuW5~KCA`nj@E^3<@<y7Uu-Un)@0)SLzHF&tPHGR+yYo$JvlQ%ray#hCDF3r
zhus&xtbUrz^91&l=ypf*g~|uX^dvWH1uK~5B3PcNnf+I?AlSob9NOS%hX-;?b+goH
zdoG3-SLVx)mvo(WiKMw%&S+VJ@LH})jchX0?Pe{KGxJ01{qHb7POzMARwWv@6fEoO
z7kQd?ZZ~TxSlwa6KBP3Qd~ViTu#Z{(3ET?0`Llg6&FXVw_h#Eg-0ZVx{m`;E?ukRK
zQwLu$H~T`c86&&AO~y*P*$Tm~?9RfE?`9b{TP;{8?=ij|bluH*K_b}JnBPZr*X^P-
zEwCPfjV_b6k4%3_5eFuXEAQsly`8#0$yblkw7`5qe#U?6u^Tvb*DEOEz@%{%6>(tF
zxR(`iVA8lsZhoA``fdE_-GZ=i>JR{{4u4ZyA1r(whkeIvMVzOyJkFnB)eiRMbDI!Y
zRUyC0r*kf&{In|ZX^L?^Fj<@hhT|C40TUY?EH#7D^jCGW`hqRrITBCLGV2FM*J3fQ
z<oV!sGEX%(f5sVF<;i#c;P#4}{gO47-?j>K@{?J$-0Wvq!Lob`%jQcuUnC28-Te1+
z(6Z+#jZ=rrveb67{7JF6(?1o@NoLh|^Ya`WI8%mie~HZ3z|Gdc3g(A4dY11#nYW>v
ze~%XJ>&KmOsC4oRG>VO9X#YI_!dbEi7><9K=5ko>?U9R@CDho>=lUzaUM}!kS&H*C
zar58ZLECuv(*b05Q#X4#TV|SQn_ivJoy^zD%>pTz_Bp(G`*`KMWPwhxevQ^N?}|=j
zth1YcMuc`gXInfZJM}Zb4EP)CfY$TEw%EJ}jOL$c4Icin2Nq5o>mtuD0M-ZIM`>=H
za{YTA*VWCuf^9iga4MMrR$H)^&(`JJ!2+Y>3YMj2ANXNL_?HFW|GJw$2NJFGkd^%0
z-Un6<-xIChSl<`?m}7zMfU^*?!$;ThejVxW=GT)k&321sVfS(J(+5DDkY=}jwR>`V
z)6MVzOKA@7cm4%3??5+uE82H4%@5ytpKn|9Z8s|dm7%x;1?MlJI5ybL&t)*Kl(BmQ
znFoxX>4esJ{griO-uK{G1uK+huceQ3k%hsIWsO<AANvQ%{KMT0??R-w3vWG*P0yUR
z{s6`op`7A(ovnbIKjUR3y#K$+X(xExXgB{{2JPvEW1c4Sg3XVXWfi<wV#FC-IQa#}
zx%o9Re9`PMk#D~USbum8%ZU@+AC`AK1B=YK@oqLuu*uE$Rv`0CaI;3y`eEGN3vZ4f
z^G<QI-=q5<+UDQReo7Xc>1LOs<wVQkAIZ<hymQ=al@M3I*PLS%=UeDzyJ3aOxwi1b
zzqu`Pv!#Mvzw|QXkXZ+Pv75Q0ZH@W8nL7ChSzw8qUyno+pAW4C-TZSyw07f@czz+U
zlhJbGB(ck<JHDbcwUusGTCkn3t>b;kToao!VBFeTV`lQWwQl~K3uwOmMeC4-z&gST
z)*WriX7~^Q{$XFzEjNFb5L#;QPS_NV*<gF4WmyfcmFwAUJ(;%I&8BA0OcSk|xB72n
zfgjv#0<2(uX!QrzX+fs%h}8j2tb+wMR)`bp;QKLF2aFTzV1tbk;>0@mce<HBI$mQV
zugOt|&xHdAV&e;%_*~5p*vrv0anM;=;|U(Nop#X<y7@gdYvHx|cVEKh&1|!u-E3{N
zzo6}ZY9ep5i0$U*{b=HOzxNlpnP5%f{n(xsEX8Yb5wI?TiPz-(hhaPuOuP;j1bap>
z@%ovqFm}Yv4hnJqZ7jVQR-L-Dqp>j(%PC%$@+iy;b}ZUv824iOfd42>^SGPMjE)ny
zBP6|02fJzJb~qiI>!Yn%eCRS+@T{BvejM5dhf8zQ&bj$>iP3guZTFDk0_WYVT(m4`
z%a7;e`z^Z&+Z|rR?SS?|rIzpWIIz}&o&RAhq>@?A2v~W+a;{zTgiQZK9v1|Y#f8Dz
z3u#s!Zp@%GjZ1ERT?)&&?ev}@WI-@loOW3r=K~uOZ5Qm&pN0qH)X3Qm-m7l@Il=~b
z?WHqK@v?zqK``o{Xk!2LT#NNVG_emF3JZWyzs5MRUt3@W;WgYwXks6<6&6Xz@84zq
zDiH3}!E@cs@3+A;nZI8{G9OrNSfTv#70~*Ug}}seMut_rNfrT1PtJ_{8eY6t*SJT<
z{&KS!f_c7a`wCg;pV-_D;~M=pt{Rzk&&_ZU#<HLtueaiJGW~vRKSI+sHJMCiJ#@3q
z(QS(sZ2$d>Wd6so<1|`Vdx+Bn*tyND8Ei{NEWaz?7QIMup<EfPGpt})Ho|h++PRg<
zyty;@bAL9$i@&db$lEiNCxh*Y#(e|J{gW@^F2FFqP~HsIEPCum>-XZozsZ6HGFYGJ
zIDz)n@a@;g!bLLJ%IGm*GrSm{{pTez@BcFRJ@RO2^$QIqV<o|&?Xm@4{AI!W-*PLR
z!TTB7om_+YeAff^B_21K;oFJ<(SKM6ub#nvil&K)4Qut!VPv#G`3ycTeFy8u|1SO!
zS)>BA8LVJ?ZiA&U;mm$Ay<!Hxr)@jD__)f?Z;^$-`oIdt;R(R?fk#G=d0&pD8G;w{
z-ze9BETFIuSW9>#ripRm%Ga(-ae5`#MuIh{`906i1ZyE!g_ZjoQ5>r*kMn_Hhot<n
zxplt%f(i?R<rU(@-%(*zGT05lI&Wyqk7Ih(40c_x$ITymV3pxE@>R>=*Ly;+KJH4-
zKVacl7_1xoP37#_@!|wBU-kGjCloxJo6LMA-a2i(^8;C^Mh2g=hv3B=MiU&;GxJjz
ztC_*?Q^h!=lu?S}JYacXg~}<W=}oZx760{8oKInag#1!#<#>kTf?&mk{C?g!q8FL1
zFjgzRe>V9x_S<A$Fj<;@u*O1uLqbn};rW3T6>R3%Zx4_$uRP8NCW|w{u(H&i(-;1-
zgVGEo*wC6S++-0jaX&heG6IKhXWRN-&ERvs5WIHB81N%m2&^rvP<}P`2JtOUoL)P&
zzvGMTYyX;`%mSn15n6*OFLDcmy$!EXn#W)0$B$M1IvM=4U5xXrS#k~*PJR(Ev0YmI
zR-_o2r)~!Sd@}?ujvi8CDVYH#?$fzPWgAFlg2~bhfxQ54q;eLUzZQpWr!1^q{B~%x
zCoiv`4koL+4-5xyO!Eg=j@|qW4h>G47Fc`1I`sQ>6`7}g2KzU9%)t$wzt!t!xHXBj
zCz^O}Xo0<#H8Vfls9TRd@KT)J9NH|JCR)m^(R@3ETEekIurDsusz`BxcCq6M#%-*y
z2!~;(4xtVi{CWYJc)h^rl)>-YM%(&ahl3Os2KxY3uwBsJ?3rsHS)g;QerRI-v@RK}
zd`c|tZnv8+QJmc~gQaDO*_WS;<>zCb-myNv69UBZoB&uCcn!;fCe9;SpV)Rs6X%h-
z!hB%5kf!)d!yp*VBQZ^J9vM<t7z_{0RL-R>m)?U_232O^H!@flmSj(5{|1LC$5_7%
z{@WLrU+F_%4j?nYHbwgj+RSQaYLJEAl*efUGuWH(M#|6AIsaaY3xXAk+E1_)zf*66
z(Y}Hv&ac^^*l`7|P0|s59P@zT4u|=niQi-Qg5i9JtYVfg`F^DPGuTYQF3#)4`(Ol&
zj^UW5KKSH+uyEQ;dn<#_%hAN|zZ+nmM*A7sjcW~$QJn9c4Ca9qD$BS}2bp9hSXsfu
z@2cBi-2`jhY|p<GXAG97831b)joSrF?~<i_T#A6vu?lVV<fm{t>D147H-ld<Kr0ju
zVfKy%!Ro@_SO>Ja1D6jYWAA0~&lJ&4ygG3TnHTJNSfRKI^R`VT3xHJ-Y)<V3m&j}|
zoXcX|Zdksyy$?T!4Gn?$b=3C3a=@SWvAUV%9Gbzh3%2gNbtlOzFgk8xT)Cyw@o?zG
zg~4jW-<TinPut&k+=t9NEZ#yr{G-W&2{tHDpf4F44%;Y8EX_`9#x*7LkBCq6>8bPh
z`Lqp2&wj(Q6zH36E{_|P!9VXf056UjJ81%$=Y80I(frUt)mCFQo%&fHWU$eK^_=$(
z4sVVHM`y6Hg6)285^fg9%(1a@VwyRUa^ocv$0A@j&|;gRy_EIr5;A>U25T5i6L+re
zZMDN>_V^6`opZF^g`4u@Sa3qDU!(n9^xs1~4ve-RTE9OwzDWiTn&kJ5qIusrgi}tZ
zoH`hdt!U4rROH*p0IMgIv%=uQe7}uM%HY>nFfP!vW+zJ1H#viU#{sSQja1&RO)$C_
z2W?W;(tlE1WJ(7A4*1XT;>KDp^6|_!ErWlj0`2wNtKXqG6Ra$(U|XZ*o$ySE%m%9_
zSnpRx;`G9)yJvd5)mSy<MKV8Fc_D69mJ+APEU=D(?J*8MB=dY2s{>ASORnn9&76_J
zzsHVNrPD+lPBXWInZaI;wl!LvGY@8wg=WH>Pq0d_KHzl-d=#61VqBZyC)-k71nf+5
zX1kz0s(ybXnf6I+Tte&c(~Rk41{m)A*q&&s9&X@catQ3Ll$hCbrlwMyy(~WN**1A+
zl6gOkjggq<kH1c>P8I~C>kMeQzj_~c8K+%>pJnjx7~xLR>cHs+WH#6uSiy3lCExTc
zB(s)h@cWn0I(%_!02x~mo719Q+;{IZnGWX6ZQy#r5qvTF51OA@U{zs>`5lGj&)=`-
z$3OOY25S`EMrawoHTVt|nRQqh8w=3h%i4m^8Ny)L5R~TF-FZKvIDHk26M{8v`~jbz
znP4LXJ2~het~&YYUu5w6nsJBi*?QY!GWKN#|DGaRn;oCH$wFX5U<J#9w*PX?No2m&
zvGdg9@Z##f1~wrJfKeUL>b}|q4;M~ZY%rR?;KAmThAGR)*jE{B8?0b{Sh2}jI%4)t
zTm-Bu8f*t=$3uXBxE=g!GWau(PQ&_z*ADV=(7QI4-)~?IZnk(D7EWAGFzC9FpXR%W
zFGl}in*9{!SJ-<B8>z4{3Y(;`4;40BVV@{0sIV0ZTdlD53fru(?F!qeuzd=%6?R-<
zzbWjz!mcRnro!$h>|cd3OWv<j6y{b~PKD)H*fR<%p|Ix_rYo$H!d_8WZG|;dSaXH7
zR#-=c`4rY$VFMKQw!(%g?0toeQ`i)RnF^b$u!Ra+rm&R?TcfbA6}DAjA%*Qy*a3wd
zR@g~}ol)3Dg<VrvL}C9Z?4iQ4u9J^hsS3-Xu-pnOs4x%M377-mT;q3|6u=Va1^W67
z{#{@^5v#nTkn;|-Fj#3=;{4?-EOX6%xeg+lXF~>?1b?7~Vf|75XSc(`F>ND!_7b&o
z@Y;~wQ=cUZZG!Wh=$!pLylBj8?IOGIt-Q_5D;b&J+l4w5z<}sKEQ<w}7nWGRf&{Qc
zv+u{QyW#rw0XMqfTkvn~K?cA7Gb^m`N@|GHC&zqX&%xhVzhbbg)b5DWbQouX<&RoP
zSoZ&T!(3Q6aaMwvUl!-*TsBy@Xj~asYE64}pg7}Sx!GWOqH&nm(!=|%QCvh}+JEvm
zU10`TNXXCKrOIN;&-*Zg;T#y-1<NwM=iUgJ@hF3T&l}BZf2JK-2<&xOp|~kE=J4}I
z@8j4xdIfk--d~zDqd1>n)!@b9e?GvbbJ{uphAWsR+VdS7EFcSkVLw5`x%=h6*Nz|y
z3u)GX7sWK$lUP|2&7&}{!h8w~fK`f?6Z5NFaUGtTIQ6rII4`^=wo61|8axS+`X|Qq
z&H6b%Z`8r4FVzMU`;sBV;f}s`*W~wM;grQM#G#3CCRjdr4ci)RPxvt(3#^1Rv+W-G
zCcGuHehP~un7AKlSz`4|ET^7eVt$6g{0cJ_W+j+dPCLQGvP2Z7WzE5_Sv7*T61Tgq
zFhgN}g_#Po6lM$7IH8;og=tAS_&IY+hztC=;ssbZeZmWdV>tGuR<IQ7?h~vHn7H2t
z6c$uiNMT_xJQ`wIa3Cu@@4<XnIOWumW97s#T`Y?ZMsaATv;WkT;(UVPg~%OK^5I*Y
zG|dDP^9zB!1@FVMVBGj&+whXS6K7<L<@X-EHvd46{bT_!YR_TtqS&56Fd8R502BLe
zNMT_i%|Jq$EG1SJv?JDE*J0t5QwJ*!e`6g2u>5JPGekS)Q^c8IREMb$_lxa&1Pdq5
z0;>ssW17=ox%~OwMafw9czY@9qakDl7;U2u;l;h5jp#}i0Hgfy!o0X`g9-~JnAp}~
zu)>fQmJ=_4T^JG?P5Ei5vF(5p32{E5gHfBU1)F!!`w7MQz^I&fVP4EH07m((0~7PJ
z6c!fJ+>nqaOUuEJsb7PM$5am(m1So_oEMDR8b2Qs+u9F?7d)|D4#M*4sWata;cQ!5
zFuac0>-XI&$#ho^K6k?d=9OKSonsEp<M3Z9{NKyG-rUYw=6}$%EHQ&W`9Cxd{6`k2
zC&|qV^I3{ZOw-6FHy_M4DQ+e&34Hzwf8%|`WD623AlQ-wGX=8~ESNo(W@5WokQwEd
zXz<g`+(ss(X$$6Dq>MV&0UlS$;}Yu!Uw!13m><iKo0davo~PitH00~mG%pszJ*OS+
zGERHq6J0d;+Y5c72)-EohvhWDa4_|1hPNmziwA$*fsD2ijM}9bz8L+776QY89pms^
zp+fiGmyyvtm>IOUml@uY@aJzQH+=;Q$0os`3(W>`UdJYE@8yg=7&jlx$uDYa#=KFH
z;#MZawJR~xITgaV&0u&UMQOfu@8ZW4w+9TGo7*-|Mia7=3D#lRS<K!k=M}Kb_RK72
z&qhVhlig3q@7=rSdXgnWsi5kRpYGIe;<#?G7i6ZXfr;g;wPyM(GEag%d=%V5rh|#?
zQst$mVXw<f(+einug^dG29OzGZdjpqX}fyaIWixZSe7ayo0lOQ0EYWA_9fhY^bgzG
z4~7+@`u*IfBi}|t!NhWQZ2R~pjK#QdV7R2X?G3N=Bbx*ULkzdeNAy8t(-JJb*BIVk
z%!D*A<XM7;K_{Qt32~!pcB)S{Kf(I;?1R%SCvIVaH9Y^2mn8@$_TBO~d#s_j)d_Jw
z|7_rt#Yxiw6YE~;K!2X**9mcNw0@&D#cfWo&NIHpJ<Cb!yM#1vb$s4K7D}+bkNh|_
za^iL-Sc$P`ek9uih8>HxQHytW<sv(f5cg)4!a2$81iNhieTD33f;}1b_d8@K!Nl#}
zxb?>k$bL(R8&&A1SINQ&aU}vpa0qkicQGMuP5+mwl3huN+b}8r+hjKq;)b^V4yO)I
znvn!M<*!nL>`sFHTWQKzvik}7y|?9=Cu9#3?B~zBogu@?gxD^Vrk2Oc2Toa%6YTqQ
z5xzg9CRoOzQ5`AHonSp0J?KEDCD_IT16z~j1{3?lrl+oQ%b#Gaa`klPrr6gDC!~4f
z?NV(iO;3VN`8BCBS&0NoZn6)DFsJUNz{D}@#+460CaaQQc`xmB4s}?ThG62jRCUeA
z&eQ>|J(##pzp?PsWt8R{V0gWN#?Qx9l6jhw65_6Iymz1C=7ZsmLvb_Hnr$Mpz%UWA
zu@iTO$WDSiBiMl|FX5_Fcbr6uaqrgtcqmyZFfs1P%{kaiPMnbtcm8o#z8?(*!;Va4
z>G<)LMHIIZ4F1P$`zgH!*&cwRf|X(|@U2dM5%|j^Sk(^Sjw8ztlX5(sP=2Mh%yOni
z&Nc!Q^E=x3dET$z0CVOq(Rsl)?fa~!G)IDo{qwm|C*CCsfWedy^2<CHml#&RF4?4n
zGz*oyw}mVSCbr9~Q>$asJM}vNCLZ4}9UK2L*-0?5f3E5s<nx{@U@&Fkb^odF=oS=*
z8&<4)uEG8Hka@r`b855v)89Tr))3%-f|c9xQf;!KU^p+MxO$E1;%U57hm{F&jqkq<
zrOULFU}fQNiW{?ZA70LM;xy=FVmV*f<@%XS2NU~54e$CXWbMI<!wRK2dVLO?Y!X;$
z!9ISrD&LPnU^pqExNGH}@HV>-hJ_|8Q|BrlcRkO>&)w#ZZ+C(6)4}k-MR8e;<&Vi4
zf{F8`A$N;iBx|1#w|RxNlFSb#mSySsq6f(4gNb87=T`52L}r0ObMvz3siSqWlVC6$
za2xvBt1ZdygXI<MLhWYz$Z~q*bGO`J;&G+sn%UJTE<cz!uS=@btQnaHOx(x*t*mb&
zD*+~^S!;Wn*mw<=8{SB5J)urdAFMLm-@Tsrv2|^kW|)j)J}@}d;c*T6{ckdvA57ej
zJ}Z}hKiN1iu`KNT?#pD8z{Ivb{v;nCCsu=r_3OKI!XFf8fr;&Mef@NPtlFFqw|{HZ
zVHEdWLR_9VJJ%%J2_}|v<@5P!k?jE!xBG;`FP$K}l3+a+*4#*z3Ok>;Z|=^Yy8>A$
zF!A{3?vXx<tRk3Lze=mUt;q0%P~3j^p5)z5)*ei3vkC4aFOhWy6YJNz(TxdYJ}~jT
zYQ@2azmWOC(qV=AOWh*bXORUGEZ@q4SIJB;_#cm}UuGK)VNPG#41firG{+VxhePK7
z`MMAIrmF7&;3*=M9b_1#Lf8QT!!Aq14pJooN)eENjLNJ~uplEc3ls=LC{QFUDMJW?
zT4jY@5HKJ@Wk?i+f{ZYPGQ|HmFPxi`^ZWby`RMD*x99GA-+eD>(JU7XCmh+hS89Dq
z7F!{*&8`-2G>FU&R)ED-?w7fnEFO$s1BPB5{UTWc7)}n#uiTMMYJEu-X+Au-U+vjb
zgiX%d(o1Qki8OoqA8#Sc0OS2|w5w?a*#<CvZJf}qT|cs|VEh_a>D6MD$+m;>@lxUA
zHPguUi8QCbx4A!=AB?w4(Pq7Rkew583vUm8pDahjH5hq&3|TH1?}vQLAK<d6^=)*;
z$UVcmMUSo}GlTIpq*9e*Z<57=@iDlw@$3_1b}(M|W69BK9y!2x-yYns^(TsRg7LZ+
z|5Y2VS~&-S@p)8qNA=ezE>YOU&Fij{C4oH$C$zVzvgGGgWXWK>oG&DV{>F74_yHFf
z@AuKG7Ive!6fj<vcmAl?fh<*|*{R<!wV#+T(%hCh=px0XgYmJHV~HA1wo0UVY+w>L
zlh!U9L|p#E58;((a~i(m>)E^m)8UCs$g+ezJl$L6mo04m*LPK0=Ya9CRIYo9TFZ06
zc>j%C{c}9!7hNf`EZcrszl+QS#?$l_9hE?45%%El*`;K7cggG5$+K-USt~H!x8HqV
zs~wpGtQefo`ZBC@!DVE9z<57cj~7SM+B#9>ck&;<>UWp0OVvETQd}w+A4@AgDW|R-
zX<)p~POVtimEtnMcsXnDU;8H6b}(Mfw#)NwAj<;d?efnnKdm4;DdNU9o_Lll0LJ^F
zQ2j5zBMXA@>(N&ii>dttZlHPne)#mA2NV|##>+YNQ1lrxBiM6rLUS`%w$)m)l3;n6
zy>RoD8e}FgzJ@dyHg_MH1&r^Bc8qG>iY!*<_weT-WKF?%IcKcCTZOC@7_T4vTQH}{
z;zXM3@6_E(<^Z$635_#+9lx~oMaR547SJ&xl=#2$v*}nO)-(#s8F~&K*I-j?D(9-I
zk@M(D^Tt1udBJROLUB!_JU%ik2qsH)KRLVYc`_?lBW6F2s;cgDTwudA3zemD!J-o=
z&R7keLooZiV1@2vE-(kP*s?v}CJTV!!e@i$`q)17h5dlPeAE;USWdKW2Od^w+QD$+
zPZqQL^b|NXV4NH51!kEs=Er0iVA0HaZK$s1Q6`v?S=^DbmnqH<7N?m*D@#=U78}W|
zufpfXnT`CU{|&MnuvpDPb(q?#<#jSE%$klYZtEUgIYM<v1H(E~{ci7@p!WJ%V7v}9
zvI?xDxNNWjEH34T@+HV}bmDS_wcOoY&A;fH|DB%+tT4+j<K(?7l%GW>E>^_-axh!%
zd+Z{vRMyIVlx93w49l<m;C0DlE->mpXm&%1`&+RIwK0(<?56c{BAFK~4Nh>bVBFwl
zXZDjN*7|R=z?D}UyD&cC$J7^&K|2_YL9~ZW@~d^psT1b{D+)i4{f==%_g>R3a@x2C
z!%ZcY6YmGMe?Mp(9JKo3O+X4W&r2=BV;+pgQeF6&L!}?!L5mB3HF&nZ;EQ>CeASjL
zzE1cV657$y!C7Q(Fr1877PKBKUeTtk_CI)`tY$XNF6}M-gyO7VKFu7qdidhL$5Ziu
zaVB_y#x+`pQk&HN%p$B|+b>5`T&%E*`Dd$g+J(JZrb9W3bAnBP6RbmhI9{EOyMbrz
z2`|vRMSICSq#>CDUf2pJ6t}vLtq7T=0sI@Ln%T58%m4ZPMzTaOEHuUCeY$ZbSu~`M
z{f+&O`BiyvXgiq=3<o*I9r-<5?X&z~)Mgm>+L7<(P+R~E7e$Ku{nMe1$y`vme41Ic
z{POIra*WIk#^de{U$uwK3KxerwYX55B~Groo-757#u;R7s5oon$7Gp0mIFp@jd2ef
z75j|htWe@F-~{V{R=Rsf99jk(FF`Pz#ANw;-o<9pEV)Ve86d{>I#K6GGA|gF6Z4Ij
z4?1RS8X5O<qf*T&O`DD-g0+Dk#BySO1B?8-jpF=ZsmxAq8@z)oxmox+jd5*8omK0+
z7Yr*)X=eK0$0})cx4j--2eHGG*A>Pl)T}dDUicpOb!abp&#JbL7jd=o--W9}C~goK
zjTel&^vNp|$&y7J&o5Qvm$2)dT#9ppQ9odsdw<`o);gcChR(-0ytO(6h4DD^8{st>
z(;QppR~)XPb^$8}-{TxZd(^pY01lct!Ls0cY)=>hhP>@ssPW>k!SBE_d(i005;)c3
zvcPDa$G9(6PQc5rW&yAd;Co6l|2J=_dE|hRgN=)2!MKy}ezyP)TAUkfzGk7a{4;j_
zK{7{+@E#1~Chs>@C(8yat;L1XtQVZ~Gg&TJ1!g}^zt)4y+%huG?)_mbnGFmVMJy)_
zRm0Q4FRA(^f(_8jp;?;?*NakI5bR|Zcjv?K`v}HX;eN+7yZuwQ8^zhcOf0VTp4W$w
zIl-zh8~yp5x5(UJ<27^GU}_i+KR9}s%nCbZH#2-4zw*F;0Wd5y)(_)yYwuR`C<sRF
ziFV+p#u;$X;*2n%so&9Ry)o=4nFWmMfHv#;l8t0`FrH?5Qb%kiEzJZlBYaO~sWIlw
z56N6$G*>Xq`j2nHhz-Sgh4J|i&@m%i>3Nzw&Zc9DU{1&z$2FGa&cip}hJ#jzAQ+7a
zv@<6bjU`L8N9K1TW~q(L1BMfv>YiD4p;~(aVDD)b%FmRqnv>$}?IPQHRqfyZChG&1
zPm8l^<@|Zzv1Md~!16NljIUmmED@}VW}z{$WyJg*WFD|7nuW@8bnevhWVSaW>$h;$
z6IGT(us9aiZ%XBCiaP?v%QD8?9EYaXo_>*LkA+V*kQv$=wBG@zHv8?Z-RWdDu<CF^
zHvUI5HldcL3+$X`p*lPrvg8*sHx%*`v*%+U^(M=J*~Z)D#TA8Xkp;lEv$)kO;g6xh
z7gl5+j1FGEi=V`IB=dvu{Qg~qf5|-*m(w9KzqIvB9b{(s4jYih;JiVZ1;{M#gx6La
zgO6IY|A@>9#_PWF!P={22~etNIH5MnDAncynG0-!W}!AKcKvS{388YDJ3+rkh0AiY
zt}l_y-5EYN#Ny7Zy!$(u^<8*&&*Ex1E3Y8)KyM|mxQbKzk0LX7f%>tyzSG|BMdpqV
zUpuhwGoJXnk~!cz-bYt9|6wDGeLs9(g>kl~MHiAe!C(riw)Wrm;?ifpj>-h%ef#r+
z<<rP~V0^But3DHx*5aJ7;`8=wb85l}GQ6?Cj;6ki3pB;cb|?-EGp9Zp)wgI3G8b4r
zC=|slsN=+@*W&OKCNHzNK>vEGEXJPUYd^mD+o$(}6o(5P9~0|7Z>6qPMzEdmgOuNd
z#oe))wEXZFg??b>InX(YEC9yik|ta>lV$aeEa%i(#VU~n!3Mzz<=1A=g^grMaHZh=
zaIf5ud1T4Lie%rgk-5OEa6;|b<;#aLWIixH2DhAUs>YJ7PxyZ2bqJ_c{%k*rbAdro
zwQ`~rZRLekEYvQ!V3+~shqkx;_*61;-|+frLu30vhp?rE56z)CmoOgZ1*-!;i1}ff
zZx+g1o8p3C^lYs;zWD4b4;(H1!(~C^*V}kzEhz|&7?%R}JREU<jdr?I2^$<VbA#oF
z@5%bD`@AYy8W{B-#`XC8?O3vO5qBfcnPX(Dgc);6Eg|!QS>Ocgj%mJjvWVI*1%#b_
zx2;+ujnL^l?tJd(Pbf_rSS6O`pI?Wc{U(CpAi(j7`PKbpVmXQng4Jhn+lrKaKxT!U
z%QGuHqS+d<crfZeOtbBkOf`?vz_5|1erNh-;BsTYeh7f^a_*kBVF8(OKzMz@G<VIK
zUym#iEDlbn4#mDmUrXi(YpPkOJ)4#}^%I$SAnb!!+_E0mZ;{zy($XBm{JzVnQjp9I
zmd@g0f;YY=a}18mZ``RoZOGEVaQ;x;1Ba%~CCdS;z^uZxWAn+3L&EzdEK8u{-Wp_9
zuy$HpsQ<DLmp(_90#-(|P~G1)71X8-wzU_G)@w|2!@todD9$((K7*~rh0?6P%MK&&
zSs#H-XST6yc-?g;8nnL=LjAD5We*%8THiW94qsO=zYjYm;XyNeKz$9qr?{e~Ngc?{
z!(lJNZ0z0%kV`1e2&0ORrMEX;4Ua*v##&sc?gO57UP^Huu+q#n)J#_6%m)_D?2YlG
z#!{Rg%%fSTUHUgDuiDHFSHcO*2GnZQfa0tp!_N}1(oI}1H6lv^vuJUlayI;I1vanN
zE<O?0aoh<fnF(h1OK?JCX;g_|4>B9rB+WwQ^u*nLl`H^Omc=c5C1U|ubaG@_j@6l4
zhb$JX9*Zk-<|*tHLgh>b<74-maTPX^dBFIbUUt==M&<{515T(8xk&|9l9@+Et}jQH
z&)8392jgkxTY6Mo$CAOSvosI-n!HVMUSUgC4c$X_2`rx$XVun0=a5C%gjzoY!Fc^r
zFPBwomT7e4+`O}V@)L@S1v6@ChWfUY`-1^w4zQBU?i^U%kt{)2wMHAClDWVNvAD)D
z&2YGC<#dDP*DO?r8}%!zwoU`9%i_j(nt3TM8>}j`3eASRMi%{P<T^NV{()m;cCZ&&
z+~@ZCIb;c7CT1Ou_c}_J0)`71_4~Am&ut;|f${O#t$BF8&H>}soG*RBFDTA9#-ROu
zFiNv({oO0bV!?QRjc=GPlO=*RfD?)<^W3a^WL~hw%zoapB$W*RK?1vGp*hxY(xr-I
z@nB6@+>H1(KaqLBVwqk4_m;{p2doOS&te9sHPSrJU}&vbD8Jn=?}n8z)bB2^glE<Y
zj-P%LtVV_pSYVn#{T%q1#&CFfvxa1DFtcVh&7MCrVl!DL7|kP$Tb4Px6Il?<!r~s?
zzSM`z><VB1Fs@yx)7TW+_)Gw^!uQzLZQ;1b{o}WA&@96hUU%_&Hf2aU<PtI;814Dc
z-Yj5LX=;mZRH%Mv<J0Y@;Gm@$J26~Nv?h&R1;`R~EKSF<bSziLER+7bEb+pAoO!Vk
zl`};cf9{>BV>!Zjnx@H-W#MVsbu3xOGIT6k$D&~+rLly4#LE(^V+lHzrej$;mMe_6
znPuvKmor`%k4q88>zAoxIXY%a`R}sWb<73U8`>Dx0&MHN9h<|<3C$J5wD5b8Xm|g#
zsq2FmtPi|Kann|o>`HMK*sWC3%%-I|>7lPE8UCZ%PR&C3T^Lkm23a<kS+h`_yUAM<
z$PDmPJWbd3KYk&zg7G+0c3r$&X!G3(h8KG(XS>JNhh#pH=HvTO>108$I2L!@;r^G*
z0V_VOS=cVG271G8HI$zltO|UO>ls>);ywLjKCl|hHcjsM2bp1J_&qR;JO8M8HkljD
z&(^b)<p<Py=9?Y<ok@&q^~C%$#hKmkT!+P#ZkckH%sMyHe(+qw%eK~Lw)wE9WpSHs
z7HFkxL1bBqS?<}%64N5n99ZL@y=1P%aGhak=KsM2SJF^^UTF2Nnf-I6Caex2^TE}e
z*WsN(?nPvNPh>fVM-{xS46gL=!3p(y_V6P8$ZRX&eu?Fm-|(D?%(dEJXu;wdt{VfR
zGE^2nSOd*MeS2j0ftzH;FX8zoOY`Y3)2@;^Gs5=)*hdHQ+<HQ0SPP#8U~#=)|3<a7
zXI=Pn0vI=?%4Qfrp|Tj)!(M~MMO8be_EMe=@EnYp;o^Y5D9*ppU^v3;e(>WCWCpm>
zzs<~<-25Ff_t$U@XJ+o!4Y#V=crk8`%x~ozo*<d++sOQSjfqqH$b`(uHEXkRS7nOx
zfWa12^<T}h`@56bzK45NR+iM|zp8d|Y=igonRQ$H8?2h4a^gRtk;Kx>zF!n(NXUX<
zd`vX>XSXVg)fd^feL8&!KOKs5?TPHa>+N3dPiEd1*+<(PTU(NO_eZwb@}{xSqoFhd
z2P50;{DcaSOUR6eBm3xZV+SrbT0eMxjO?S&KL4XRnHfgM8P+Z>4_7Zu=7gQ-Z_I9P
zYozk?9FM#{<V@ZHBPf)g`2@@r7U$`ctoDOmScUd5E4%xz<rL?KmHPlQN6TA@WWm$n
z&#~Z`|8C<CBgqnfjcl_9r56t(^T5i+$Mvk@AK<dDwM*7{gTV~n)0*6~|CT~zK`=hf
zg6H>SlevG39B03euUnqX6NnsVsqYVm9u4K^{UdUmEx0(f4Vmp?_;VLnzh)E1E+q4S
zWwUm<(KYcgS>Vse>)6i2$5lCPmkrv#ola}r$3^GeqPQSfK9=US4RvdhS#u)SrPn@A
z|BTEJR*=PAeC0`PGUK(#et-EDBedePF$gP-kHzh{GBu6NcLUzTffFj{*5K23$%3$w
zK4rH4k32oe%&?l!XPdCiN;{vcNand6ncw(4_g*LS-GygXtSl98<-$*g%IW(%vaPdQ
zPg3PH<VLpH;cxKiLMYDmFtT0ll)G1f%mtO>b>CgC6O7nr?E))4uY2Opw^iN!|3ub3
zb^OjU6lZ{4#|c)4gHMX*BeO<D8Gc}9$bPj6nd7;rh_YO~nXcCP#OI?T+NIT|;%Yu5
z=8sbEqhnjQE;6zprRf684=4EC8*TKwKWC7+!FFmE+SlDZ+v9yQS9FwmUk&4ej_K+e
z7leNpqBD!D^jU+66z7BiSb^2=(t?q9$b5yO)V(OCS@-i5Uy<QI-pJ?C(obz&$ZSQU
z3^6Rtq?ya$>{%Zbi!zjEmY8yT1z8aOU<vQr1LwcIN@gq(S-&Hl+SDR*!5<;#bue9h
zF@Y>lDzcmf>xbW;Hk%^LnR4gp5{h%Z6j{!OY1TPp{+FX7#>>wA(H1iNhfaANEbDrW
zB{P?c(*909&CR2RfBTWS%ux}0o3^#zfR!=SW?4|VSoogS)`TkkCXpE{MrnV8ozh&g
zd8KM=XQil!^}0jJgUJ-<t`ce4X^%`~K1)=@_5F{x61-&o>XCIYw|ccWnHAn><@>Yq
z-x;Tqx!@m^hi+2qQq@nNo+b0cKMcsPD}DOShm|8#cSD`1i0fvTp0kzN>P1Cd<F2mh
z+Lq#+u$b{Q8~&Z6))#kdWc}*z+^@#Gr*Txo9@=nnfSO}|*qre_^vS0i?@@jM_y-C2
zwcnYVSM8<DaJv_A?f+}dB8qdijEcC1ukQ5IZZa4A!G3-XU*9kMc`#4g$T1kbwZR37
z^S6s!vpzb#XE<4~ePrDAZ-%TPGsDIdFX%Lu<{K{KR?d(I{&RuxF?hpywJDh&jMuMA
zvEm!ajPS=Xc^zJua0PZkp){?Xq9X3q)_t;|6j>tJ063wt*gM6|CJTbaXcoFhuq-+@
zfy~@FN`1}|*Q{n0uc~#zE9~W-iw{$r?cFE?Zh|PkjmK(-+Y<~Y2hP7YG2q!3wo4Gq
z2uHHZL#L=Y7X4n7`n)&BSx+rhduS6_1r~R)^_?_0HDH=HuxMuZI)0%!z+k(fl@rsv
zRj<1m^9fyGjnphuPX69*nvP}ZSgwv)<DqX^S>mo8hP$FrIn7-oEvdWhF`4oGDE0gr
z>u_axSGB%a!EnN1KcGdK=BjIz2kZl8!SPeo+GFe%Wq3`qP~FdZwtWPrp*91<PN6ib
zU;9(-Z3198K&b!jlzo3K#hJQCwr8_tomCy|V7SoY-^{^s(wEjpU^U<cN^^8>sV3-X
zZZKRls4PEK{#xz9w)Tk9eg?1oGR;h|m$kT1{fZnbzY0#ZpU(#4W6-tajv9kOVO8c>
z)!dB!0M=xdX2CtrouV|&VCkBL`eDb?-H*ruVDB;8_30-I$m~7;yABR8>LUjPWY#E$
z(^#uR3RoTZ9@`9Uoo$}lgZaUz-_btVH4b)&p*Wi}ye^^T9o6j@vJ|kgaDr*R1IM4|
z7mX$Jf;lyFX!iP*!dJ*Fy~6E@arvG$olIr}qq1~_7td9^XD0K4;R)u4R%P!v*d0IX
zBQTnqo!~Y8Jkr=ZTo$w~^K1AiE(NRtoM4)0r52f&l6k?b%w|V@3wOhz{DNSWm^Juz
zh}xf-KMeODrrB%f8#r7I+V}+fR*Q3J`Hd+$T=jcmpC|)%G>%=2tMG!SG90uxYu_mK
zjI%SmmcQfoC&)6uYQqWE0c~638-I}HfKj`=3or6#xTb!Q#@92ujwK7@X=VuHX=dwK
zbpI&zc?K+J%=!d%opylvpz*L>a9;S&E?GkLOCJ!WKC6QETilaGGLNv6Z_YSQwo2HB
zuPziN%Mdo)-Q^{+4Z?n#eG#XH)<<4pwFlPkLAF)c+8yEjSteM1_(5EkunsA!#|)x4
zpRmgx`qkXb0;B5~#{Ka8+36IQ4OS3Na7>_8J9xJ$Sq@kMX2*M-RBQP?kzcz<yY5q*
zVPIt3?B{dllNAQbtECyLL;s$8+K?HA70aKohODHpiH&<VBQpsb6XzH}79-4lalvn7
zW??^ezM=Y|lCX9S&JLwGi?E3awYrhj5caWuNhX<9Sm3j7_K?*R_Tkvd&B<bg?SJ|M
zUM{q;WCP=Un{Q-`?PLxx-hYKxIg`k`gW<wXV`<j57jbFO((EIw)Z~rB$OeHu&*MJo
zrOJ{dY)4@3ZHgNM#>eh=!zcYrmIB7dVD<DUb&s9~#_QKQZ}f8%mjTA>w|Vx2fn=G&
zX04l!+ZnBX`@k>}s{5`}v+I#%3Ck@vuo{_Pr0LK4OI;fSVAv2ek6aB}o}sv05qIX$
z8TBk7dQfEj`seIYW630J;<deQO4A~2e7{epki`n?o%f3^WOiYz&DGVMju%$#LW5fr
zmmsWox$aNMlEH9Mq`Dv4JZ~*oim=S{pQ~$58kmvA1%5AumvpU<ykNXNKVNfXGg%hc
z3oPzHN;Or^fXMIl;s?%CTu{VqyH!o?QKAP&_QSOag*_B!5>{xyr7C0=VJAP#=Ov33
zwt7uP+;(a8vkUv>QvUvA@xuD=X|MK63Bs-yY%!POl7(%XQ_Vz{BFu4kQw~|0uyKp=
z9js6}GlUuE{;tMurmzwP$DX6OEHK`;KUiIOdC}?~0OS3)v+rqjP0a->3_nL>Y4wdE
z%A$uv+TN$P;VEk<O%oVjL#Fhqg<B&nKZ~$+mTGtj(kvE?kKM+W@bex!7$1XIS64qw
zaZWH^zcI7hbtg*(<MnI%&206Y!7c31w2Y+`mjTAt<Z4|<tLJ=PVK1g=p9I$GkSWsq
z;=%nGO4AQ!ffH)a?p0peMrIfqS<d8plOL0rz<57&?$srY%mRiBCZ-t=$Nm0?b;uII
zhG^!{tojR=)Owu@X4WheSN6+2s*lWxVe1M%lczz9S|{vaO`pY~ZQi-yDIB!AyTKfq
zIc#Y5I^#3Rf?yRiv)OP_?eeIb>Id`3QHF#ltb@abi%y-iCT~!je^`|IJz=!1>F4f|
z*@naONI1c|qgC$t(%)oGFl=~b|7stv)ykOyM*V;{ntU&usbe`hW=e`o^Z1IW_EZ+T
zFrHtsFdmly7W=FYSk9)=y^2$sL9isv95%GZN3P&7(CX(J5v4vWhBhH7N%eyt3^zL1
z)@bEYW*&uu7MD3PGHzI@vHi#lpF|mKa6)m1r{Z5)3B@_UHZZH%AxX_mb8-~Et)b#x
zs&}D;iW?PfGbg;r+r<TDhS#wFdcl#t^1wG4U^E}lqJQ{D&6P}H?-yy5j<Fb*CG64p
zedWlqg$=6ucoSI;7>yUqui3&KFOr!?M;gC(vV+mw#JHI9H(OJj8>}UqV0-q3WBaHP
zm&pPwP3!>PF2+y8`AM^Zy{@Hcv!OLV-W-=ct?q8HKAJf+yH?Y^j?6eF{9F;^dJn08
zk<1N-3kvoF+JN#W8<F|JT4)wZb3sB`wSO^>4ZpvFalYEY8WiUSi(_$B_SZT{76hxH
zSt!324*ZSBP#w(UqSWsPV48O>y}6Uj1BPn=wr2tyUC}QsCo_(ZQh#>@ZBqO~Gg%rK
zZnm+0Soj9>>*JKu+AIJ@<wSdJr8eX>v$?|e_GqS-cm)c@WrEQfiT37V$51l-hj?-G
zi{(T+*tcFhSt3|j%|d0ldHPSaS4;z=F^F+@Dn3@%sw^-XXSnHJ7kl>*rD>c1Ypa%~
z!-jVD_hoAAy1^P~X4CBTyGvC+_`#^(2f@$Wyx%4j4qDxf6T|gGJ2d)_Ib=>S8fR#C
zN|gVDEE|l{91Jg3wB2n>W||aEQ?ti!jU#h{QJQG^=iP}W%Lc0pC)j^@t@~)&HzqRk
z<S6wXJDT@WiB)7iFdReJ51N%flS5{k5~cm|A~fu{x1L{7lq@hU$^hM~#i3QN66GQD
z&WN;%yN}|K)Y{B76YjNP5u!9#ypZ`OS#Wl^Zxi9gQD1DDKxTG_%ZcWFsX|9G4;amr
zkKskf^L5m^>j&!$uVH>8;JCBN?kW^#n-d<_X#IM0$E3A#dcbgkV|$|gy63cmEC{yZ
zS=~p%i}@#Bdqdg0a9g9T^WOTB%sn6WXL&<q`2=39?VeDWEOAkIua7o-Ps2aSTwt(m
z(CUEJ?(eGk$ZSg@<LbnY!)&!WIKW<j@39UTH+aeW^T-mwsLjx}c%xODxrN1#U#Zr*
zOt8`{%~9L^%_z-mFe9_^?gHb<f?&KXySz1ekwvFR)?wn`@3bN_3A;S^#uG9N7|(BW
z%+e!dHZWelm}NbukR^cOAfR^XJ-^&lvNW(t%u>gnRC}o`Fj{-C&Ay6Dy-abrV6@Ld
z`(=KEHDu<ck!49QT3n4KI~Yz>D$BfHzu<7y`Y!>D)<H~j-iR-!letA)`L+9Mka@v)
z9rjLMe3L97;?B2ddyCBQMU=q|CsY>i>_%!_Tfidvy=My>{HRt=J6Lu2p5m&%o%9x&
z3yjuetV6${f8r%Ui}Q&z&n~^cn=Bw~{U6;_yBL;5wpsfMgIyG72IFnEr`u;QlG(w`
za6;vLRN}TOOClI=v$hNV>O^rKu$Nif$L&5zBJ+tf6EAJTX42}H1IEY8D;rw%Av1X*
z^NX1~TGibS#`80zpH*ve0vI1>f2PN&Yn)qH$Fy}TD8Edwl5j$Gzq>7b4e*2Ux$@4M
zdJ8Bn7mT;d@kWzXnwI5}{a$rt+&zkOg7LUAZxmTZ<_0sv36*8{E01T9Wr9W2@0aeX
zECDcH&LJQ6?M`vgupsj}-DBg$WU^SW1}wi4OLxSPC4-rnH9qzTFCkk0dBAx8ZT|G)
zmt=l0UcUnwmVRW0m67GVvGgak@3DZH;RmVi3(t1yL2(W+K6a~Bv#5P?G8oTq;Mx)G
zC@w?9y_#~S6`3E5x7qr~$(P7-!T30<@J6@cWTsV-buXXr;Ycz&m>Eu}4$Y?b3C|-i
zUe5a;?on|b5mz|1T7F713k)xYlx9M{U&oMTgXPoAs$IttuV;Nn77%8b*B7g+^<NHH
zv=$e-{{54fevK>_j9)v>J`Vr>t#Ngv1y4LuYlsDmm(#PWsk%pq6*gqe2k%jSc9G`G
zt+y5+bAs_Pf62V`d9oA{*QCXV*U3C!d``Ej@MkZwOfY_3sZwdg9kP>Pygg6U8iUhA
zYqJ0tzfQlo|NbtrTw%q(DU8jl#Tmbh%x~<T=5{hG7;YS?Zw==P{zhg4<7065z@aKl
zr$}?$sl-%@bBVaLYL%nNJR+|0m(!b&`M~)2+_k*U5V9Z`pMQ1o?ZsOnt$wC8k$qIG
z?|r=FX=Vc(2jAl!6R&Zf<#xG1mJJrGS!fI%nz{c2GBbQQvLlq5;wsM{-I&a`HvAb0
zOf##qX)2j_UHG{o+O8Y+pUHe+HQ<EWy0LHJVlu;exbI;3b=@>MlPqyV<oa3X@(y(`
z;{mI~(wsHx{7)1Y0IR^#jQOMU12Wsj$oW^|oBL`{<N)LID1CeHvlQnPapl*H`I;;d
zjK(}J@Nvy*seW*SrNL|1o})0}*;gJoIyOZaY;Yv|>~ce#at1UH81)gxEv!^xHCYf0
z2QtNVSh+*(i5%YWJuJrAyVc!IaXzp(7MIgtL{&2L=I}ip#uaS+V;iyru-COXn^uP&
zN9OM!%LKy#f_;l|gBN#K>luFd3>RUtvoC%TzOI11ty!pD?p%AM=DQaR7b&V=)b-pT
zoEorQ%v++=-&@nld8H5*O*0o5Pt(&Z`U+V9jMfm0%NsLSwP!9E^*h>YTfXc=amKBY
z`Mq5&$4Zs}Mr#PhotrxptE-hI8O#FTQ{DNqrwlM!=P~Zqu-)n&$Oo3B#f93XM~(Dc
zIMvdO`zHLJFvh)S{4k!(0mjq3dhexHWC>unfKgfMl%0q_8Y-uV`)g9Q`DAVp_v(vn
za9PyiJYY2Du`Ky_S5?>kOc8f(q8}e`XmMF0zq9?;tF<m5;&}anBCc!G!QCm%=x-zI
zH?~lXwqz!-m*9lzZg5&^k;RI*Zqs*tMP>&p!Q!U%o!^nnDdKp$B!cmN=zA*sJJ~5B
zZvXUBy(rBzFcZtK{g7oJk!=ObtC>}sW8cS~UP_h;R*uD;U-Q}_vH%$G_lWic<K?Vd
z`n<XxMSm9=$LnVT<L#Mp^#wJ@VnrOUpB)Sb5B0-{g5Rn+mLTGI|0RQ!W^pTL_dQSb
zOA~R&Ukd*%#0+7)4w+zlEy%Ov-R+d7UnedA#^?LdDqSa0Tu{V)^WybWWcbT!#o>hN
z{!jf6OOcttcpvd{T0~r_)|J$_wuw02W)3huH(Ts}pw@{55y!`TG8kV6)7H6GQaMv}
z;?hK1hjJ#hKg$5)WA~P2>wZep3s!`+%ZnZQ7bElO#ASiu4^n&1xb&%7KhKG{N7mIj
zlx6^|GK>2=>&H4|g};w1Cyz6N@wic6m%**70k20*b>eJbmEdQnoU<km8cT75bm9`h
z%CNXGqqeL3++cjXY$#jp9Hr?2<7-IyzBAM{+$ZAt4*X^Z#reVbd?<AzfWttmUk(^9
zm{<oa{M{m(9+R1W2tU6@+xqZ$7MTaE0-RvncsRE2b^3WSKZ`?)xzou`=GYd#Zo1$_
ze%*9|y#}vgnrNxtZ^R{9D`zH{6}~6idjE-P7sK}O`wuSonS)I}=?ModE)k5zJlbDd
zc4m^fz-Zrt_HXYF)yVuT&57`0AbuMzi&~nt9pSYO?be0*N64IDE;zxx%~X8x*%ywb
zCtx&J(4O{ef?F#sO~cMen=seckSwpTVe3BXLl!NpX#ctDx?%(?2tSBzhWUM3=K4d5
zGYk8=NhLMMtY8ILTzu1aaCr;WUD#h0e|bXY0K*#%s{2`A*%!%tVD&T$m1RWQ_9QaH
zt|$X`3dQw*&C-J`0Jf1?shX)<$-KVsvmmVB`%S8<F&G3Z`RpD6t@2E#YR{&7!uO(R
zudlE5C#C5Cn*b+NmM68#;1Jg89t5NLhjGVJYAz=;?hW6spnZKVy9${DjOGg3_~)kK
zvZ$q*3`XM`t<{NR$H_9mc$=;MqsddUT#;X!_j(^Dv+WDtKVX{WSHwBV(!gjxp8_wo
zSn_WUSpW<N7S<i@!(*K=d##-D`@?lW8#=8X4t>pBU^U=-9A{_^AJ48$<^#imVVcw6
z7^vKSfU*PO{Lscc3fjnQ2gAQNf%em$F73$tVAtV<(o9b;rS^5ftng=-G48$b_uEoj
z;-Rq3fEP3OeX@Zp2aNg%t=q`bs_w?a;m=m2f|(0XyGL<}U`{x}vY_p(_k55n2dt82
zHqGu9t9_Kr{3HB+j%J}a*TOX1t{HHhupEhuyE*<wIkI>#Gn`;sV}5szr(P#>fjKk_
zrTK1f^-Zz>7!F8^%QI#0Xfor`@bwnce6V-(D`Xb1XcqUN>5iFX^}w*a`1wJMo1Sy)
z5t$7vO|wv08ZSw~p`rbJF4(J@h3Zf)wv*~3>#-=qIu^HcUS3r{!%yKoJLY#Q;RiL}
zO<;75L;L*2{uVfB`B}l<hwrJ6<{He+$vj|oW)JR_^^@g-@%p_rZsRv(_{SM|+&q6l
zb=`~yE3Bm%s^8H8%L`FlBG>}WLhaHgYGE#!^>~!}cQ~*P_sn%ClX<}KHLAmuo#qQ<
zjuYX}mEh0pZC+Q6CEL&8=R{~J#$$ykE*s1YCp0ED|N3+hnc-yQSn5@%e|It`SezCY
zs>7OB($!wr2UeD)88>{Y8cR7~STM>jcS=e;rTGMmu8mmEK7k!W$qc_lsehvbt#H4Y
zUC4Z3bbUZ8Ui)u#pW{9iIp#ku=urDX9~hsTmtOBYhSCgz@$qtDc8lN1oTsA<Z^8-n
z!!Q1t-;!m5@j9H(9&m@uC*n5WYqXTilpTJ~hjlpG(ygwWHZVSqRu|lmL2-s(BgadX
z*l+5SC4x<d6Dp@|$UGd%2K=A-4E%lo9LcU%FT5X4HH$tQrT!KhmL=uHa<xu4!6vb|
zS&w4WeU9N=cwaXgeun?ecdIb|yCzOyd_U+G#^ZcoeV&!Y4aY6tr4@jKRtMYp@aIG3
z!fWSRKbb=20~-e?Sa-A;18%%d7XMqg4!9ZOe^=8D_QA6_w6_bKReKb}h44H=OYJ@t
zxA$6EEMV2)dmQs<qk_MjCUb(d(afRQH>M5Wk@>(nGMi;=p!(e!h_p@dLA7V_fc0Z>
zzx>eYLrT;9dw85-Sr$E-pst&CFka3XyZq|<=K^y+OLIOPS2$W>v9<c;g3+8tJ9Vzh
z8ZzS_;r7HeZ}^H{2gz(;v2cRzg0`vB@I7R1FsEh?&FWhpUL%XX7+za3uJoB3s^3ju
zCAGLvn%|Ciy&A<?!OYAqwDDngYISge4bjYD!v*lb#4aC`<*+o--kF`-jSPRexC)$L
z9nd!A{ir>e6|CViTMWmjn1PqclEEy`EFF&jj`pgy_JUFWp&i}%n;M_iKg0JOXai<v
zm4$;=2L~8WGylRX2gqDt72pKRiE$MgkE%?T0alvX=(H-U$^2kc7F?_r<t_dend5S}
zENH_%nED%8B3L6h!TdaMymH98h0F&wOf!dO-<eiiA+uiz?;}0%Vu5}A50kmTa6Q6#
zi<Wiz6FZqTCp=!3!;7!pe_OR@23QQdhGjuJ)bi8kD9#T??Sf{Toxc;A;c9sQiS~Q3
zpVXL00mBR^&F;Hf?54OZuo}z;RC-R0Ys0nh{R5`iWaxf1-_2mynV9AZI4--I{t+Au
zdEh?>7_D_^J-TgF*SIV&>OZvW+npugpvC2gG&g+KO06Nrzry<^j7u!qw*$pl!KmL?
z!i%q*S#gTY3ub~7EGOF0%a0$B`N3%Zp*7m=8$cEWvlYcShiw(Sc=Om!H8%_Y6TTlq
z%h~z`R$Hq>NnwBWI(m^TM%dgNkBX34z#u!VoS0^z(&4`y9V_Cd47;Z4U=vpT{J&~1
zWfwN~&85pIKZmf6rw*z5#S8njtZyR4IfX5mv!y&)g0N$qC*oE>YnMb}j!8?@Jwmdu
zeA9d8P@GHHqVsJs$x?&`-ud`FGPkg<AAR{FS(>o-xBrco60MvbVMk0OqsTIZ&8bqf
zC7D;)_-WhTA<Gmty7dXQNAU?O*m(RcipvtVto^3SWPV|No)mhSEL)iQ&p9eCAZ&24
zIlU+@N7#bQ`X7)5g}vtbV=q~*uqN*EczM#=)9^HMuK21>R_ziktna;F@zSHk8HF8q
zeb*8)lQ8GneeKB1!cI19^MuSItiswp+sUlLdRcqdCW{qzEq9<Qi%nShF%8u|%P#EQ
z_uf@;4q@ecyYEnb@xt<_S6BNGr?9rivhz}0g0Lxr-ijwn6lPBP^E_Fyuz!cH{hiDu
z?1e%(JIGRm?W{iymu9X1+`{gc2plC#6Sib_$ysC`VY7{SlgKiJy?Nz>PszN(rk@+!
zlPptMO!7^Yrcc<KrI{%dmnAH2s8NkGzp%|0s;TQ(wy?|g_PCAF+9e=t?fAprljR7T
zm(+a(Sx{JkTQ%@<p{1ECY-{?w@V)52k@K(XCsBPUE*dNvPVm}@*Bs}^dDVJt5;l0n
zzMm-0B5Yo<qUt^_7OXH!vsK&a(<#m_?9n^Jj+4a;Te0-J$z%z_0?r-kx|u92H~Y6u
z6qh1wbFph}$kK$RkI?>Hiq@VP!b%LitM)ya!shN@9bT`6^(i}Y0_B%2tZC=Z)wLr>
z*x*YqHKDj%VP745p%qy)l$N*keNQ*sa%y!j30wb0RTr5>*uVd5bdbdgyRfU6T9fU<
zrkuKf!v|i)e~&e?EZq|y<R?oI_T-Z<nvx|8>osnZ+LxyY`{>@aW)znutl)Fz>tq?i
zwr%mgO_nLFSE;n-WLd(BJhx*IS+=k<#aGuQ%Mq5FJyNY9xxxl6Z{C;UqN5_)Y~EL+
z7m%5ReKmT#Y8Q*J%to#X6c;P3X!$W}OxT5Ocx%83ii;O^H1nF;Gb9KrxVX??6qgJ}
z`*~bLW{rKM#&w#A^S|_y8oL?75-Prr!w6an|CVZGyX3pEAum~$FrPoOFj=;+{H=bj
zLzW|~Y{T%LHdk257E#+ME;>(SSyF6M)E?R-tXG4UDnE;`eLE+gqcmfM`Lg1IWOiZB
zv2~A-#S0ty?vkI$5`^W>*wT?KS=gSO{@2M;z<B?iI`zXOvJ4S7VP~|O)0x6X?aydT
zaaqC^-f+E2mMv^#R_n23Il^*IO|g*W3Y$A}aCx%m=OX(E*3&g)CSmobABrQh2piI5
zqq^S43hVzy+3pl)7gpBvmFkChVI7XH#9K^lTqg({T(iS)vScv4pwqSZ#ce-+MwTKh
zqkglAWNE_QSX%TFS%$D8l}8>T%LK!TL;3Cf<7X>bmawSJUnG!a3#(H5w`8&$VJELl
zUQ3oM?Dad>Unh%(Uv}bUc|2(1Ffx;{6*-U8e#s*2df_(zQe3RC{IAWKLS`3M`9c|W
zjf)pHujT056qf+T=gN|+4X%-;h`7bC-T0d<O~e(d`fo3?OcD2cqwmdRS;FRd)~j_Q
zTcp`3b=Q{^mkY+nQjvA5zaWc#KC-RLJ{&Td%p`1m5%X>`i?G~{6P}XA3VVLsr|Q~a
z7q;-D<7y8bFU+xF-#?UQ0vK=WvRmqAk)?>Zk4q)t<2!ARrGfFfKkWBQ4q1kX8=bP|
z23e-C_O>g3kYx#LdB*dIEL+%ta^cV2=LoADJhq79a)q6_c*I2(4gatlpAUa+SbKrY
z1jg%EyNOfH6^n>_xVm`>ii;K2q0sEIWOiYF>I@B##S5Eq?(I~v1Yx&s)T>ICEbOh{
zuBtUM1&sG?yIEr<P+SHWub=Vo=PSrEMVgx`y|;xdOW1?;wN+bZ3tQj!On~BYq&<Id
zFj+1bFXyZ!`?`{u@<*2QfX}7wb1Y!I|JL=tuI`;;g?%1Zd>*A~7gnlc3w1vh55~(<
zX!mY)@0$$9+w4m15${u)DI(37#`djbX~Mp}UHlALhOpm@|NcE$rpRwa+(jo@mWUg1
zclau@Y+)Af*wth?!oKR=b~0J6$nQ~`EnkyGM@P1Gz1XVd$V|fiiAjA-W)b$}PUcXu
zSYeeuOnsZoF3djt+%d9vVVB~b3?NI87QahbvanOFKD<nEDZ-*(&w7b0P1x<9#u~{o
zgpD#!=s=b!tmV-=3(2yCO&or|Jz2J}gc(1mbv{Q}@Ym=!C@xpn*_S_2`>f~!k^R@<
za*Kl$XA%~@xs2)ui?E8xuJsfbE3DApO}miUg>9<!bqra&uro_Xs<kHpjL)&JYyG@|
z;*!Dg!3ln@1P6Qai>^2_7nltK>3xK(&E0E}d0vjJd+DVgR3h^VoAGPHbuyo@+~Et<
zI^h>~yVwOa-vh!*cf!9cAG&S^h1FVOQ`a0rnaFb1IP}6*iZcp(*!QA(R$>-*{Z4uH
z4A3fUScOJ!QkphlYi4DsJ+wnuN%tvrjdKcX8+Xo0X(kGbyHT<xnM+vHx!-4!xrMDb
zIxK<ABW!Hf8_$t>!T5STuIj^kWPV|f$38hl78GfISm?qYGDA#cKiqkIeI%Jt*vCT~
zEG098@v=0XHTp#|n}}Q2uv!H&hp?Q(71xnDg|+S9OkIl;g$0M%qAAWLEpLpvrn-fl
zd#emiIc;C(5%&G+q~FQB!Um<?ZcFA9);{s|9%OznKBpTtbgO3<0TDO<!WU}n289(l
z`R4>m)9^}UAN~F93+lenDD2ob@2U0LEX@4!#XOXzRak@gVT;IY!v2lgr0%O6!gh9>
zJ(l8}!e)*1t9$fBVINPA$)PxxFq^r>M`Uhc-G4l!t^polOD~82cAr<+Z#VyGPHFmt
zUBBF0^@CrSq0D5pE(L_O?>|W0-v))P&iYl2c|+OA{=3q4or}t16!uE)IaNQiFvI-!
zc2b;G*s{GHZj#xA)qLL(?muDA^<1Iu|D3|^9(d&!N;6T|nn^X(^DLLJl|QvobHy#}
zUVN1-O4B3kM8llt$-KgT_Fg?f<`eeniL$sg*5<Tdn6rE(HID+qu5KHz?pK1sR{MV+
zMQIw!MfP9zmUk|a8HKI7a!>6;%)-j-AFSr4Rha9VDVEZ-30v2qk1D4_SbV<s)xO**
z>_oec>fR|)*y5p0?3ABNSnH(l-&t@ATe+$0VT$tz>pS)MNiwgnalOx~`v9M?L0faw
zp3g7rqxAEiQ<?!`7xOhtCJPF?ciyms%wUe}zj{v#spnZnVR@{dt9_PP*okdT=2Mzh
zVSV48noedDcInIPcru5u)q_*jSaJ$87(Z0&e4?<JoMmc{=@Qoe-{+GkKew>JyUUOa
zcp>nB@oQDN;_p@=^NP4TpS-X3FFs+x@-_daIKQxbGyYK5fPgUXyt3+kEGVo%8H2jN
zHI$F+Kj*Z4t0_ODux92if03DmmHxV}Y8R`pesip9eX$8!Qn0?->pO%coc?Mc<>wT3
zq+}U&Kb<IS<>%k4x#<#CY;v*kl%`wQ(}Md|dwPV`95J~W#d(GOXn$)VnNQfVwq;Yv
z{K6h|u|6OR2s>SBj><16Y{}J2?@^qgLgYAmes<0fGNUv@lSX7_VYiR8SNEG%FkJNM
zS@Wzh%{Nh;O<3nMA9=_e!iIkCQupspVWW0k`-0*Ug=O_Vp~i$u*wuMer&63-*heR8
ztLutK*pmF0)aOIIV0>;K8&Fo=Tlj?CTJqOFl%HQ%qd8C2H9R29<SeAFw?ScduGcI@
zX&Nd<mSx@Lu?NYFV7woCeUP-6%nZiw5ytI47~Z1@d%R@N5sGsP8@MI>H_=_fZeF#H
zr#KH7FU#D?!#k3Bh2>ehvptzl*x?ormHEMVKX{gf{s<qgp8*jU7-O1EX$FNYK6iHt
znW0i-Ik&u2OYJd@!iu)7vy$S>!amxSPd(GI3Y%VXfrsL3!h*wcUL$h|dwy-jAIY3x
zy#K1CeqWc&C2ZxX?ZwGFBF+6TB&j`^S6J5QD(flE2gcj_-QTVcCG!ire!0mVvVcgl
z<C-;1$b!OFuG!g-%uqS9AKET2{ymvdSj%gpT9cWD^_kgM-HTd<6}$PC+P~Pq#z7+V
z+-6U57d1WuU@e%<DSN_9`B|&vQJ=fVXF>NamJaWs!4jUueF?`ilUL!77;t==tL9OE
ze+lhyvu4<xnmNHH!S`4ew4Ha-N0S*Wc?@RFY?`(FcC)(PTEU_VgyPn~&kSf4r`8^0
z-8|~|G|;|VRQ);}wEVKbD#7=-UZc$%@vT~Wa=~!(OLlF+i>=^Pi?h|sqdu38apMBn
zYTfmN_15AXTAB+cB)Z^Ki?i3yqdxPDahVf7Q)5063^%`6ceFo#dr9rfv%s+J@VOh>
z-3Dzgz(IS>4~88^asI<KijdW75Pn{VaTR_WGn~u@#^VZKS(r$+3M@aIP=23$-axI9
zUJ<vv;=?%<SF&Mb+=~b9tG%fijOTab<zJ!4LUot~mXGD<+5V=wFLr~~(=60S%l9X#
zH2q+>iKV)G?WH%vsn#yG*gWcQnPA<I48IXa<^{uta2U51j)7je1IUbx!ebZhqV)%L
zZFGa#;5CZdytVl>iVJ{QG_%?8;Ze;FFSR8zHjcFYajC_~Y+w~wT=$13ePoGX{WNoE
zX?E!qqwd3lU^LD!zr_Pv{7P{NO~T_0?Z+do4rFdH8uMsTg%Tf<`M}cP1nY-(Y|~*}
z`n2{;Zkk8^9tzs8H6Ju0^Mcia6Pzn(d5uf9kOjfs)GU<d;*1^{WcFs^cEJVrwUb5O
zB1;B)S&OsT&>lZ5r`pT|M(Yb&Ro9agiZj2SNB!;x+TwD<?~*yd@P-KMhxSXMlwD-T
zHzMP{eXvVi!);(Sw75`Nw(ehakm8cTsP33%xuQwE$h=@?IKg(=0LPOB;&DmQ+A{z~
zbwC@sWB4F4r!8C-v_=EwpCfaFQ6HhX-{^Xt%-%dQuGEBh2U#*$4LG5)bW3fPP38r2
zYUZ$Qg5&6}zo@!fTI5l`2aR@R+dtFcpw%G(jK(h7)O-7*$lPESIKlk9aOA%~<^ywT
z=Fn_>%|BI|u`Tnc-&?}CDy!4%aM1E|fPL^R4k!BS9p|Ziqz{b73tIE}Cyv2Eiwl4?
zh3~N}XkRR?5+t*>3eTgj;l<PgZPZxG0IU5h4()b>zh9)d95AXM4t8EYbL%|n@3U_O
zTd?B#VTyBu6^0Wm3)+SWTRV|?z-TO?EkE*839@W3svlaPxp@zf<$_WD(0UHIHk8cP
zCVU-3OZmKOF|rgep5K?wcRwQYf$=n>$K0JsW^5Z?m%f7++c^iTYq1;51g~NJ&=wz?
zuJ$Niu#(JH)c*booN9gK2g8d!&dp3X`d@eX$r9~()bA#t^%y=aoh%m&7b46LE&qr`
z>e+>@T^>VR9x#K$_5%hy`+}DY(E!nK#JFv6bR9Xf0vXK&)&P!Z+u^vVv{PN*onSNu
z(e_-~SP%|coF9z(2yNz@HSv<CSrClI%U*bmUjxi<h35mBall&DE*>zt2B1wew;K)z
zElu;=c?>p~aoA>Pg)(M5BJ*^}W563lvgPl$i6L`3!s`UaT`je>D483Kt`BIdk4&FS
z<^$t(xPN47d$J%Hb{OTCJhHNS&JcVjJSH&B+E+e(m*R{a^QgajfY!5H);_X$Fv<^K
z<a5joM*V;`bzg-$6ldrZUU$*T*6ux(%mQYG6YSgla2$8@#9w3yV3gkhc(MNDTk3k7
z24;K~hj#hf+s{#)7t92R<17nbeD;N7$<QC-qC=)lSY{g%^QeET=tp>c>7dN!$QZX3
zEI%A^4~EuY%0Ii|pxJh?yvz<XI*3zFGapz!W}Uje8B68|ds8!q?I;{KG|jV!%=&S7
z9Yi}~uilW%3ucEC?AzmT{NmMy#mS7rpx>X3L9`hwJ69rWniMW4+G}kqk0P@P^X@&2
zS!i`=1%?}OtUJb)s9gI+vN&Nw&WC^JwX?A6$5%TkuDh@TS3JGQ`Us2l#H;mskg(`k
zebhKh0;9IZavsg>dXdr`BjT#}IQ=o%BrxhfjJx;!9UO{U-BX0^e_C(|S*ozV{SDqD
zbBp{keyh}-EDem8vthmrweRtWxM0<_XDBX1SkmJ!#*ukNniIP&A3&BVY{d(6Zjt%G
zXk266SLG}BC0UlpZ|3YuOUe8q&4Z@JYMf<*@%GFf9j(U8Ibn<1mr!e6Kv<rF*1DA6
zC6V8@5{0wLf?$Q<1lJI(!{&48YOWYYgs&@T^o4WU2o_pHLi1?o#2Yiv(X3>!hWv~#
zKKnwmvoue_xp8JbJZN$8!eS@&zfG1PEbp8cH9nJtz4O8zTpB`SP?&jQ<_)qmFj@ys
z;fv3{u$&vfaIvu&thPT1;D{DPd$vwsA=>VEq}F7Ei`vX((;o0Wi^VwOXJoejG4q7*
zwW=!oY}LM%Kf_RrbAZua1MLgLx+7!>V6+EAqc4n07HPH}`D<fzv<zW9zig4;*!-1S
zP+U+LzK&m*X7t3!Iyg%_!R?4<vBG$M31GZ_JU^E(Ob@>>zci61&o4_D&o5V`$@4Q#
ziY$wk*|YpCU^r26u3%g9{Njc2{8B`kJU@>xo?oU&ljoNsjOS;X99ajRpH&#o&kpuq
z^-E@k`)r<H21^r-k53;MjZZZC!v6D%H2L^6ObM4o=4S<?@q)(dXBWovbBZ*1d%Bt7
zTEOe)V`-xC`elPr{p1>wBhuvctC5l?^fyrcpY>%Bm{!04$K2DNtsw@RO}n9bRzYk}
z&-DK`?~MO8U+RCGe<qpLhFKkNv|rtGWs||)2A0DJ3+Pymjs<lrS6J=wDdB6?tY_tX
zR+c%N2H-72Xk8M<>tNI|la86e%#c3r>#*(}4}5@^Q7yk#BJS~_f!~wG3FBqyEbNFY
zIi2FVGsC{FaiIPxvOdC6OP?-6Hb@wcO9C^)4`LlK&3aqE>P>NJB97O=BaF9ohOk$z
zZ<#=8dUY&QSl6CkJft`uSZI!g%Gu)if8Z`8)Yg6xS0d_#ie%Zscv}Z_EJw$JI+m+r
zhS}lqiEYix5-p7PyHQvfU+X7SKNGX(;6*+k%);*WS*G^-7G?!SS*$u1%dDu#&&CWF
zh}(BwXbT5zKG?yi|6YLC%#GqtlEt$)G+qa%Fy3YfI+iH%YdB|D7Uky>aeO|cusB>>
zD<ADznc~uPEQ6(qd%o-KH>vu0h4H@46vpfB6UO7Rbj+_~*}{0;1H!($H_S<O&(X1<
zj^zsL^7R|>l%~N=dvB|)G`u(~vH38vl3+N&ab3cjA3m1MVA}l=T>oCefM;Jgr!36y
z*%f`E)nI9sf%6wDxz#hrdcxwWCVhjk7-wT?Y7d<d;0vu4i+csm`C1nz?C*hV`%+wI
zVSHS77smUjkFX8r4Xr87K{}QsjE|);%*sJxG4)TX=UJ1OnZbBDQ-$%m&lkqy(sgW=
zj%{F89?HV!*j8b@&9)1BJSBP`glqk`PZ)2PBVe><VSW{}=d1B~PABe?j$IeV%Xv>2
zuiq14yqtOGgy#yDlh?1Xj+GR~(~QxvN;+0U7_UP;VZ825h4Hvn!gx93ge`nywT1e&
zvoPK+-F2)FvkH(HAG?EueY&)nx;`Wc<Jaji!g$>$3FG;t>ezf8OBZ(btqZBtE~|tM
zaxAV-wm}%*M{Wf(!w=$`jP26-QMEA?mo4J>UNImnVT9=d#pQr$a}3sUZPSJTU%0mB
zvN*ga<!xq|8y@p$+l*_}niVaKj~62|>^R=mCLJ>i<JW16u*o+Igr9>6<NM@TVZ44e
zVZ07@9dqbdypB0_EI}Bbn~B1B9g>CdIF~S9zZ7A7-nyApf&SzDkfviEVf<Q^p<`ZV
z_`Ij&t|ICgZl<upo6q7<)W)t4%naY-T*0`BBgd%wxJx3A&z0-Kc$)Wg?1?bm)_LcJ
z=L(jEuaSj?@inWYFh0j(gz<i_B#iI*YJkx-70dEY<#X5IptV_35tmZ;-793Rgz+&E
zC+tD*^Xi##XJLHp=`M`duMb%0xp1ieE^IBdpURRf%$lyf{h-w$Riw%LVZM%~3*+s%
zN*JFj8-($=tva?{$My;1{dYtdZ|jr7csb7r<7r;fvFkc^Psg6<Sl;=O^MQ|v!on{8
za`Z>)_maZ+T!|6J$8IHIJg$b0)f2|Yd{bdOzgEI{esRKhTxVgtZ@UYtQna*s53G-l
z4HCxNI!PFxD`SN5xj9J~zfVmC3q2PO&D-xb=Qg4KTLD%8PHaY_wkB^gS8GJJ9xU{p
zV#o%R%e_Ok8LT>stC_UdO%?#7`&3-d_*$MLjL(N47%yl1uD5Gan$e#}u90UNbo`9W
zBy2{fGR4U(!fJo<craNk7%wMZCu}-q7iL;k{w}5I0ONJoH1pT1WC<efNzX=u$P$Ic
zEqQA!S+X#`|8(hCijKK;EKL}{pZ0+9Yt@g-W@?Yyac}Asas2s2rm)s~-YZ4*^NBP+
z8=bA*yY_?e_Pny^ZPlJR!e0IEwS$zVVL@a$t4vOtMP>x!{r=gjebu}*i8x*si-_Z6
z*DB(!=g#Ov`Pqc6ORqVE%pua`>sh>rdt7UMPl`(rR`Y6!8f3}Ber{KK5m}1J&lJq8
zP39KH$6%UBvtr{i%_%NJ*z#t7s%Ooa!tRgxOWhl037fw4?QbZ}Y+;_Yowt(Z2piM(
zwU5Yhg>~8CJVF+|FtXqIxHbyoeQN^aW4_kUP0}b$i?G{ePE00?6=_DSFT(i!rd=2>
zi$fUiqj+Kb8sOBi1Y!I+U!pK?&6ZhIzhq&&oGu+p(J?m|Z|nAlQ)W_r9uddqN`{Er
z7Fd!)ahbxtzBZ)`S(Zri^2F3-WPTAh{j5=4{{kY8w^@!bz77U;ELX=2X^~@>rx~qd
zMjbQhm|4dxI%d_eSRJ$Jm|e#lV0^rMeti2J>OZH5+tRH?SF!|Q4R5to`-wzhd|#fd
zV=iHQKBVZFTgTFb@ioLFjPGePgz-9fh4KAvrZ8RypN?e-<NH>>FupEj3*&VN2;+6n
z(XpT~UiVyKyncp7k#mgKAzB!(gHgv!!ua0JtYa2oe0*AkZRpiVt&y?9hM&r=Mq}Ql
zV|HP@9~{E?S{E;j$2oN@LB|qxELj+@pG#Q3wC~kt8B=u3EsVEknvQvxS)h@5-)0Ew
zF*+u^Pu8(aVOgsmjimnb3FG&hS;F{S@eAA0^qp5J&1_+OJ_LmEzReNF=U7l!r-eJd
zru=e+@%#*n!}AZ@lRt-!)-j`wnRLvoV-{vOf%r33t1w=NSYf;lHeo!@4yHX@gJ=GD
zUrk?lU)7z(VaM^fKEn8#HAonbOA>bd!2<1VT+DBbFg_n93FB#|3R}Et<$bINra502
zfA1w-7~j{e(y<M~`1sr^jF)q}F#h~ypD>>05n=pU&`DvuJ<oyBJuLR$z&jqb|GX#S
zYK$&Ch}!IlFh0lfF8S{?W5A*z5q!>$`SJC-l876Wl5vyrYbxUS*li_@w`ZI%9@kkI
zkLxasw{;(3d_5Z^jkQ^lFn)hKMi_6GNjjDaW@ha<vvr{r)Mj20*QC|$Lu8pcap!d6
zE`iaW7W;4OM+16Mn)h@pZ+c|E^D$Uh$4WB82X4F{VubNASV<V)6V(vL*N}R`c$!Ux
z@v^iM#^+xgvszFGKF&JpSa%)kBaD}GkT5<zlXPqh81*fd^Ow5TP1LukA}(V66c(|5
z>ewn_d~MwzY<Twp>UYbwg7I<=SelAMQCrLRi8!9-5n;UlP7333=Y;XGbV(Sm`*mS_
zPTv#8$HWt1ysh&t4bLO&Bc5MjVZ44Nh4K2u=vXCT{CZSF7_UP;9c!v%t-!2MFT6fr
z{pxmX^bihO-zJMV{_NhRV=2P;TyYEIeVZnX_n$|{GKBGck5|Vsh4Fdo1LN&-d}AH;
z{^mUq$J^zJj^+I#axC$2R#+GxXC;O4xENtPu97f5K5Gc$<FlTQH3idt=jYjY8SwVn
z2{c~Dh`6(PwyXD<C+S$KFg{-93*&W27skiZDq(yqZP2l;V7%Y+Ud@Le)z#)hj)>#^
z9@Md1VZ45ZWszfoUmK%^HBR*Pp|Ti-RgCYVevil`jIR@BVSKJwgz;xVR$)BNSRJzo
z<KxUOjOXVN#``^981GxBFg_*{gz<hz6vq1@Sy;FCuBrD8UBdW%e~K{vxluQmc8~XL
z9{qi|-bw1)RU(c*@7bVZTZQpH+AfT@**-8cWKP$Bm+Dm+KxN4haS>x)#BIA+eK^IH
z^hAzp9v1_~^IJdg(<2mT(}}a|#0}DkO9G>NF1*GyZPE1?$}d$|dRprDWUEA)i|5Y5
zUm-ByJ?sV%mvZ@?iDdh9;*N;8M<W|#Qd|z0HYVV{|22H^*%#(#SpKZdz;Jz{FSJTv
zbdQH`;PLTULl_?u^>nPMFuqQ-62`Baal&|9XJNc7-G%XWq7Sn=P`^4IMyS2%AZB&J
zcz#L3`1>Sdgz>UW(y>%w{C&gu!g#x+3*-5%(y<M~_<FWg7*BIM8131yUD_3#>4bv;
z$IB5B$IE$A7*F$@j$IPQ*TL(;c;DXBu_wZ|=DfCn>X3Iuc+6w{_<Ns)!DwwoyEn(!
zh~msD&SpcqXx{c4nMIjZGhTPAj>UqRArV|ZG0pv_o@+*Fb{BDc9qhxb9t7~~-ymVV
znx|;LI*I+4B#g(6VOAf0mcN%gNf`e<uvB5Z|K<zh&p*?_sI4)-7m^Q8gM&8CyezH(
zyvD~_rZC>tK4Cn+EMdHyeqlV#Y+-z#91zCia&#=n41dXze`YpU#|$gOV;AH2^*ve`
zPtz!j&m)tLnT7qc?&%MZt=2~tVZ82EVSH_k6~_D4CXC0~h4K6xU^JGnT|VmjoZ5#Z
zs5qMqjnCUeowyX8IJYvZmL_k{G+}(*^$6p2$PmV#yLpB2xJ+TZ&3wXmTW9H*Ul^}L
zwlH3nfG}Q%9AP{zD2&%3R~WB@VO8XO;1(^6_mNS@Ow90pl|P3z>zGBytU4B}V>TVL
z>zG5w;&sd^j6Xw45XRqAOcb`|cyKy2owiOS3*+zOxrFgCks^$*yKZ4TE=?GZ^9bW>
zWQH)FrdJq`%M|ubh2Tx9yHCfmgz^0RV6>j$7_3+}RehE*N5$D}XnZ{jDzj?F)6CUL
z)3}=E(f_7tQWi>+&oQ%(S%mRxu~o-nb<Cz?c42(pI)w4{C0^LLX2m|B{&NcBaS6hB
zTPF(RWl0vs<6OdceksCuKe&bQxHMrrKaVh8_Y7e?O|LMXW+oUPyW@+jQ19RRRowrM
zvuvHXpiW$_ve5YC>%8Gh8rLD?d%kF4ybeZT{Q74S#?v$l<7rxi@ieW%cpYMO%*G6F
zRQR(lyD<Jae+RS15XZ-7yfD7jIdv>S#}aicSr{K@E@8Z!DLUpB#^*|!j(LRfH7f&*
z#x=It<-qBCv`+X`oXv*D*W@f^R?YaB@atH%Fg_*%!gx7zgz^3h3gczT)iJ}G$hwc1
zGdKLq7%cP*>3{2P1~Wr@;QcMO%fkC_sb^NLR9wjT{cW5uUe3;7ydSQojd%b_YkQ3Z
z75BeoNmTZ~{gA9<E-*8sPj%>2W|Z37tP*j&4jWh;{-VsH-x|(_gH}#Ii$mk@cVr9W
zpZN+1<7-cjuu=2dZKnK!!gzb;>X;#e`qpY|3W@RjqIJwDjL%yWGkn;=$ER5s&(9)^
zfBwuWY;&I->X}C@7>yUq@9xCZm#JOiz^rhBeT&xbmlkR)xkQ@0Z&P&4EsQ^ZNz*Y8
z7%%6G<Id!#a&8rI{Jv_tF#g`eK4JVCa75&{{o55oD8GP+<Il))MBJj&Mc<&fCnByy
zg%gL#@~#b!C2VUx1`7*2TPI8X?ng;sd>xDd<83x+$M<QJpH;=#w7%tQa;%8sYluT9
zE?!w^yzn|Wh4JfHf-rtPN)*Q9l7;d7TsoEl#@mJ0&!gi0w_P%n{crueI%#I9xc^Pl
z4@S?EvETXg<ba9`<;T~F9AUifL1Dbja)t4>Hmr*rgFG%;7|+kBV<urdO|vjw7K<<*
zXBEcF5-W`F*=@r3`e_IIuQB0NasS(Y3CjL=Oe6|>Zl3Ed&A((}ynZfWeBYX)V{RQw
z(=m^ZW$2g}jJH|d)*qIl`t1{Oyl;;P<L?Qd6vpGu3FB+|B^|pijIWXRbnJ<a<y{{+
zSNIq#tYam?%+N@5P38NgSP{pssWxFeKf8`Obn;6QaXh~<!gzj@bSzaTKd*@6`DF^@
z`T2A#ODDhUB97;GPbbc_A+m3IoSE6{(2smgwg}^UQ>!puzgT8ANRy9wn=rmdu?yqt
znL`-QFJ8x-I+h@8<aehQKykG_d!jI&U$Tz5gz<GSMHp`vw=kYxnvQvNECY<zGwcVx
zFYu{2n+=Wcm$F2h&waW&{D{^r=Tw|ki(6nmznCls%mgR+H+^kz%sBI#+Mnh9Dm(_!
z_!ulKjMu#+*nic*qT>Fy4pwEMa`H7YRv6FErek&;bAXwlUbqfo{rG#kNg|HdeT*<(
zmPtC6s*|5r#PR$xnKg%U^7-x)#_!d#bj&Y|r<tu|0UgT`#-Hm4h4K7yh4DHVHipL_
z)}22`i5ABD!6=NUX%aT@WTyJevsoA)gBCCv*H{*QFJn`2HX9nBn|5VZ&3IWHIu<XC
z*Ut%NhJ0}Bwt!>Yu-UnA(B}Ij7Kg^iQmQb%p3N7=`zT!)Un5sBYYF*r+n{4x!OZaU
zSO<)2)%rX2H;=MK9Dn{25OL+E4NZh_t?qd@g~tn~$>R!xQU9TpK2%eER?G}$hS#Vp
zhj%Yn2d7$^twfr<J>!J&_UtUIO{XFFQ3);0?jpbbQ}bkzxkMcQU6T}H{PP8Fk><@K
z?Xdf`{I-fX-Y(mP@z0g)6UN8j5n;`$_EFCgPJ)>sZ)(rmWACcpJIfVuyetN9WdHH~
zM6@uzXEzEvy|$qGte;63|6L)oF#b6}i!lC7$104MB~}>!J7zXvJkAcr+ic~{4$y+3
z{u?CXc$+1OxU7^uA5&bKh~s0|BkXS5o@FR5L!`N-n{fr%5fR7Ba#F<oeYR9Tip$lB
zGi;9Rciz^~(%9b@HVP|M^HLAW&!l5!VS5JuijO|DxncpM=OMUG@aG}1B96}on=n2f
z?85k3-~cm2J~UUVpPIA=PPMWmi8$VWV}$XwXOc*>$?-xKN;5;m@&5CQxbd_8kG*pN
zjH{~F|4<5~P$5c%2n9!|5TRlU1tJz4phARt30NRNFiG=h(&jNHX&bO;)Lw4XdW~8%
zDr&q|jen~|E#4qSBNhx$F=CadRU;ON*ItQQHEOT^*LP<2nQzw2Su;srDNJ!Zllh&s
z&wi}E&faUUv(MLWa&p_19NVQGigA3wPGM|!|N633n_Zd{zFfq+2k?C}^tEKUm!I{K
zK_^!r%&lpljaV)$EG)md`aHI-?@LZ@u`d_9=WyAVDE9ti-uO-@w^SIHf&C2iiXHac
z1hV9{U#FjDYWcc+Ruow*=kt1Fw_=B_Z+O_H*&}SG{1FL7B5%Nt@qaVq*h}mR2jmF0
zk<z?U{^qgNCdGJdVl%N4k>h7qw<yMGZZ+68#W-etyJD=@I~3zF%1*^tZkJ-5&)vdY
z3^~ddedaDd7IpU5ot_m%yt31K2j(cYZPBGmMck|Fxth_t4CWbZzQGnM#^qb27~7@A
zit(6siDDe{yi_sv0hTMq*Q+sDBe6G1U9pX9SB%HWYZc?T*mVY5uNdF^HyG@0gKad}
zCWCEOjK>;V6ytnuHP|+TZ8z8sgY7ifF2%SEyA|Uy>`{#82s1Y)`WSSA*Rp0S#(Fl#
zU~?7YzA{g-zKM6;<NED<#kj95RE*PHWU$4GahgjM<MJ(4EUEt~#%b0l#(k_&n7fam
zt{*x4gg#gHPG2q(0pojWmm$|{$n_a=gNEFYAvbEsjTv&Gd!3%8mM>3OP`!i=xk6#?
z-hn!MsOy*?x%!M4tjtfd$g6AaN0kPvSL{OtH$LXB7d2RiFwW<%?*HczPOjTveJV}X
zvwp=`cLxkMD2(g+{?6~*<?=G(%cZu_sLx_`#`Bdi#rR%4t{C^D3B}mA9r}jTm)Q00
z{N-+MNQJRfo?<+Y%U6u+r9d&ZgJH#3uFzmb1}j#K^BGZ$?QV%;JP$8bjO}2VVtIv?
zN4mDHRE*{772|gcL>1$D=`dKQVqCs1#oqSRS?_iE>{g7g*P|GhuU9cHU!TGH732M^
z286k}DC|r7@hjo3_r{n*N{;h6Y_Ji7jT&ssVB-dxP>kCl^xw(0;Dlr5+~LYMM_8Wx
zfq5Lt&iCoLO75E{uJqTni+s6M8&d4ESeiV~i73YPS)#5t<C5#5E}!L!@iS>rKh4y<
zboeZm7q+dPig8}L4Aw0y$hP+Ra;bUg_gO42JRciSjBV?nVr*N76l2>utQfDOk0{1A
zYg93=modfIwvH>tauWs%4J7Lz%jGG?`OH_0b-q9`wyj~s*oG7utVl7opT&xC86pNN
zQH;w_Dvb5)%6C5SVb>pOlpJ5LQ89j=xm__X`&xsoQ;hcuS}!cfe%`I*IG-C0w#i_d
z4YtK#TMf2NF>Z(LigCN|P>k*8PGQ`BKUn$$-+oT`a;bJAbYF6RVEdV;7}saMFuoq!
z&v}Zm{Vev=OwCKgXEB?_{isAS&P%Cc+;7Vi<GQX?jIUR(80&6SF&;B?D8_P~igDX^
zDaPgNHdv2hT)tk#cudr%7+<enF)rVLVqCsKgAFOhW1?YUL4A5u$#Fi%3^s1C34?{c
zncN@vdU*!RSB%@CKp6KG9uv)1a@?mEDmfk#mH2Y0{ixJusbiut#khQx>U!L#+ZE$J
z-Q}m5nwM^$rS|C_#W*j$igBOrQ;h4nUoq~}1BxZ-uEB;B<9<7=7?)whV55q08ODUM
zzVN+xkCNl-&AdNZcllmCTQM&C9D~hOjPJ$sga!56g-VX|xyWFP4YtH!OAS_Tuo}g<
z9U2wmc5hdV`|Vm`+<ts7?)K$U`$~_`Qu}SMVqBkn>U!L7w<yN_cGyodH7_GRi{*va
z5k?i`aru~H9D6WsunEPu--fm%>ovDgo?@Jre9dUD+ycdTO+Ty{*L9&{Y?q1@<9rq?
z#^sAB#(lFyF}@d<D#mhUim~oiD#qojH&|3LE?<XYJl5z`jIY<F7?-bGF)m+^!Fm<r
zu|}V;Ae%Ly<T#&$1{*Tiu)#(QHfpdj#kd{Dg|Y47vBt~?lKT<ctl7d?j>j5dUoO>7
z6#6XHW)&&M^;xX0xA5+-_%SX^6l0rJ>8F{RmwKP2+N`KzY$rMtW1H1!ur9^8Pj@TE
zZPcR}=cQM%i$8HI+|!<auurjH{30KZczUc~F|O+Y#n@&ID#rO7QjE(ttQhyr5rd5?
z#&&5;F)qWn!6p>rGK9XBtk*o2nj?(;k$k<mit$)#o?=|~`37647>}hE2@A4IOOzbv
zbE(0~4OU~YMuW8*Y^`G44(k--c3-a;+ocV{*e>x{s?V28wFUh?OSMY_igA4os_U^`
z+O8Per7=Iv)Vz%QES4Acn@%Xk<B-s|lgrNQY6Ze#x|@2vu+L)G<MI_M#<r(OF_tSf
zSj1o@im~k}RgCqeOfj}Sm5Ooyt5=N26H&!ju0t`_&rZd-Ub+m{tr(ZDM=>5R^(w~K
z>r;%&*RL3tZ@^%Kit%`9NLY|v8c}kb&rySo8Eo8O69x+ny8e)=^LdJKJLC&v`@-X;
zc}kA$(tIVy<E4l%m)bW=e3ojLN)_Y!EK`haNTp(IL+XWb`PhbZ`f{oH?DAP^eReCx
zHl#-}E<>-u`V7{u7~7Bm#kg$;6=NGRq!{;=VS|k*#&%*<F)sU<!NwKiGE4~L_T%x(
z?C%8Y{2ax2{4!TDF8e%#%~y=aFAIeQ*@?wUj_YNK!Im1V++Z~ZYcyE9V%!dE72|ea
zrx@Fb^}@LQc>L1q%cb_eKA)x9iGIbnJ_m$xToA`E4I6AsrOAC|Trs}hgktO`3O$&t
zpKK@c6yrHpzQGC<<9vn{<Mu05jPp{Y8TpBd6=T~PQH<-QL@~BmrHXMr%M|1CRVv2)
zwq7wF7ep0fxemoxuR9gv@^u-kTQM$Qk77yV9>w^2eTs4U`W55y4H#@tv7~X2upoOj
zqU1QAqXru@*to$a3>Nxsav$To<SEAOkS~nwQqs6b$+10~ujG=(J-%G3JuC59sy!=J
zjLT4_SW<sbjOFSTW4jbpjBP=OVr-W>4c4U?=d)WeZigPlI4`}5CHaCBOY#LN#`Q9w
z7~7>m#W<fsigEdd732OlVz5!g*!GMm#$^~c*o0zShS1hzo#(OC9ASaJAjNnrHBT`v
z`+S2fRE)<`i-ZN)o+V0->t(6I$_-XyuttNm8*Hs&+z#s$<91)K7~7r=!q{f<SgOyL
zOSL`yK1;Pd1B!8d4l2fdWyoN|1{*QhsKLezHg2#9gM}VS)_E>pp26}J<Gtw%6yxzy
zSTVMBg$64!Sh2w(ig7+m6ytoBD#mhU2CGzz^}1fM-<<xfoz8b3HCTtiIu$!{UiTv|
z%`U}Que%M_qu9H<?tO_%vsW>;b$yEQ_4*a#dKpmcqp$y5p}XFoVk|eL80*roVk|eJ
z7`MZy!Nv?Wt{B(ZgkqeR(8J07kDnpVQ;g;E72`PL0>!v|VS^PKtVl7A2`*NQ^Aa&w
ziNQ)0<1&;PtkPihig6jDig6h_4A!X_w^5g3T!wCg^%$&IG1jv_#W*kh1{*NgpkiEx
zA%hJYY(z0G!>D3hhB1SUE5_|Np%|AT^u6T%$1Kla`HHbF6)47e2^*}?U`2{?K8p<&
zF<6OWT!vD`xC~_mt5l5hS#PkY!8#P<ymTtY*XuG^x50W8<LmV*#`@W(SknDZF_s%J
z*q~yZmmz}<8*D@|&daF5#tb&D80T}sV4<Pp{>O58it+tD-(Up>3mdFZF@DCj$Y8|=
zix{j#F)m-J!O9F)X|Q_5xO`EAbr`JEU|otO?S)~m9>usH^%|^CSXc&*?%6Wl`)!+&
z<2_flE5_H`VX&RX_3|E3di}^sfA6Av#rS#!1`7)dD&Jxy$K_k17+-Ix!OD&6bt*Z&
zUYBBgy>5f`7}wjP<oJ49731q|GuU?HdJ{^HuNQhWxowl?%!;wkBVRH0pA{&^^Qy37
z?DsBIjOB_HV>@507}r_EU?qxi`AQXIzkZowe7#D=xP0}BarvSK>rjmS`klgpd~4lG
zj`P`LuwH}p8LZ!60|pyZjN4&I82iZBufIddv2Sgsl4HOAgfExsTMIpw+#iyjA5)C$
zGhZ?8M+J&;`NE2EKPps=^`*#Q#fouXi73WpC^1;6VqAtYVcbUShi+7Ie7$zX*blu{
zF)sT$gRNJL{m>hP1@)DUN{;in$zYoew#8su4Yti-+ZE$>*r6D=`%cBUuj~@W?Z<xT
z&^Ff}Qu|7t&r<!+`HFFU7AVGjC2X)l#dr)>q!{<3V#RoD8c~enkV+KecW9R?#(61I
zjPp{d80V#4v84CoDaQM;bSTDYb}Gg?(Pgl1gY_7!*I<1H>o?ed!3Gs$pYf1lYzu}J
zJLA|Bo^yWM5ye<;R56wtQ;g-t6=S&x#kl=K-*^2l*2kFTDaP~7e8pI<Krz;du)zuq
zR%EbZgGCHhVz5$!l_|#UP^lQVL%m`w7gdbqIuv8MPQ_TROEGT0ZpFC$dK6>1UW4@+
ztlwY*1{*ZkkimuxHli5U=cr;_pJR%#+_+*aH=!8Ig&t4te=L`$7`IWr!3q@P_6r-V
z&|pOdD>hifU?m1CHCUNqT%VPSaedY+#&S``Sgu1cmg`iE<+>E(_Ul%RZDfzZdJWcR
zuzrIL7;MmBLk1gGjO%PfF|M;w#aM1kF_s%wjO8X2W4X`|lKUU`l|03`{qhy#_A4-0
z*kFYQD>7KI!6F7LF<7Z$T%To%aeY=Q#&Y$Fv0PL!mg`WA<vJDP_UlrN+pk+Omg_NC
zufh5Z)^D%@gAE#N$Y8^Yaea;`#`QU>7|V?*#&Y9|vD}1WEEgJ1?tk1yd5Uox<r}QP
zU}1w58m!1*#RiKQtVA)cvr@&l&dL;Hxk|-Yu3j;giz>!)9g1-qbt=Ybb}7bbb}Pnm
zJ&LhhuVO6Mrx?riE5>CQP>j<YRE*OcQjFz>6=S&(#aM1sF_s%sjLR@?unB{OerWVR
zgXJs6Ysm!$3mdFZG4Ah0it+V|4Hhw2iDG=cQpIkn_|)Ir{Jl&uZih;P)f+5ounvQD
z8mvn(_K|ff#%1U+Sg*nQ4AyV30fP-1Y{+241{+Z<ssAaK)c+J?xpBo<ZbC7Z3q6tC
z|5z?hF>a%L#W>9Z#W>BdVk}pv7|RtY#&X4qv0OwkE<*{itE6+i`J)ef&GoTTgOw@9
zd*N3atX?sG$4XQ&j&JP{=KR;l=k{Yi<G-Jz+n0+(z<AH_9z(9*kQ?w>k(VaN(+&!A
z&#U2j4XX!Eb9FXi$c-wwJ8Mq;y_1_za%?9;KT7B)uE*_{rx>rH<SWK<1&Z<Y!iw>8
zD22kf9r)dV5nnE~9ZGx_t53dOsbZYZGR3%jm5Q-ky<&X5sA62c4q-v%>-ObR%h%(x
zSowIZpx0o1ig7;s4K|<{UvJQ0LyGbBh7C5N7~iKy4K}72UvJ!C6T-rx>xhkk&U0+c
z-0jKzfny!!DaO~EZ?J{Jg05Gl<oJ4(#IBZn^7ZN!<2s8f#&R8sv0SHOEZ3zN%XKTp
zay^Q%T(4p**JrSPgAEvLP%+NSkimuxHe#?*#p+iT{7RZJgbj?w6ytc)amDyOBNGM-
z{Wzh!&=;1=Gg!W2+}{fn<2B5%V*IX#Ld7`EBE>k(V#PSkh+;f0C=uq~8MOqJ9RG*9
zUP5yJCV#V?UrG#bqhlQ`Csrzq#|$-!ahi<=Ygg>8zdiHwlC-B2YZc?XtW%8dN9z^i
zylha6-wSoOV%#4#61!IN$7|4=6ytnuCU%|3jWxd-uW<Itw?#32|It>(xNWy7#&X*g
z<Lm8EjMLny7>{Xp2@6Y}aeqJ=W<U2T|DAjJKS}g4Fn+&U0kJm=<Ng;mSfOGc`Niw}
z_w^Jh#x|r_F^<WID8_A6Vz5%hxC~{AaqLK?FgLbA*?BLh4qq-30pl@rr_YK!#`)|r
zShujSq=hy@ny=~q&U`s|dbU}~@jZ15v88f8*V$IZI4|22d;7)5y~SN`yJ9T2Lot5G
z%1&a}OJe-4w_OI?ZLmFxabKDFWI}gwJ+=k24K_zH&gWdkIL&#Av3;4Z7}wcC#aM2U
zFsElI!|A84|F&y~QeQ3-0b@NYQ*u1Fh#GPoJ}dIl<a~A-Y4-SXsd?%3Su9Pq*L^C@
zGvD}O|Gme9zFcaWLq1DQb6BOxWgqk9QqvswS!&rQj5PB{oSvnoS>UtOe1;WcT`E-U
zt2Gb&#I<{oV%$c>it&9jq8PVBiDE2Qsu*9dOfeqURVv2it5=M5KB^dBuft%S!opHX
zu#xBwZ$A09_qsaUsN~p2Zc>b|x7lD@jO&dmIlkVQVtl=EgH0IMoBLCzgR!#n_2wzY
z*PCy!g~EdBvrNhH^(u+oAPtbz?v&<@!k+&1cHeKap5(wd%?*nE-~apPH{}%X{&%-x
z{A|lc#g04j8GoPIO^SW+o)w>RX>KM~CO_VK``qIl+d>R4)8(=LR>fZQ-5o2O+%{r2
zE4l58@%v$S5W7X>_+36b70bW9%J=K<B33SP-0r&-<NmkDU^9P~&@-g@hd;gqub%bV
zVYXsFf77qlJ2uB)a}^sqtN}@TY0gt@<&8hXFw|r74Yp7*F5e=9EjHK^VJ;pT89b);
z@0Yr~lq<Q*Pd?&A$7&Q~8`)^2xmL+>n(GwfG}jwx-mT;~&5eq2nwu2kw%tq&69?`O
zTMV{UG4{c4GuU>;Sg&^|mef}awo5TibGKrg<{pF1{CT3UVDQX#aJFJ>&*mt`bJ4kq
zahmfK<22_h#%V58jO7+7#<q2_VjO?Hgjj`?o%`QXgOwYs#$b(#@z|zaF@87MTE#e@
z>lC~8wDH8fN->t(pcwa~yM?*&JnE(Me?IT~$ohS`NCb?>^8-FB@))N%s2J<+kYZdf
z!-}03Su-G)^=#{iVtl<(VL@e>@a0m=5ZaOG4=5j}nWq?+Azv{rLxEykhOlCnga$Dj
z@yb^yjLWd*4YTGswn)kGdevgZ_}zI+6#M!Q$Nll=QpH%VTrsYf8pXKmjf$~<qFor5
zZ`}j;^|<nN`Esdk)a|pFp7FckdxRB8A{bwz{dTTj`U#ijfG?Mt=Ah4Fa%?|`6yvfF
zE5>CXQH;wzDlDk%6TVz(K107q)=w^bp0J>@7y5FkX%_h`wd}<Pix{j#G4|<{D#rb&
z%wUy@u|2C-jN312unxs|%+RSAU$0A;YrjfSunQhP`*5dccat0#k2N+bIkv3>zFZ^%
zIkv5XJ}dGV>)?=LT%W^=CF!SPY?nqAV>>aX7~6?)VpUQG_Rmi!#^Zv}FB5tVIc9l^
z@w`7@G4_KM7%Z$9k0%Nh<Mn_d#kj7E4Hi+1^{hmg(<PMs14~bQTn^qnpj^p)@~?MR
zJ659@*Gr?Yu$%}xh%~nxy%k#rdTDkmIiADz2y?Lxko)kT@A{3C>-Xg%UYe|*13rsg
zkH>C<!nl0w>l*RpQqvsuSu9N+*Nv$(zqb0(jV_;ilpOb!nZHWbGiI|D<F=h+u(`s*
za&cGJ?9+)TIj-vxV#`FH{lcXND>GQ7!RiebHCTsY+*djk<1%y^tlMBcit!pzuVRJ2
z`EM*AdV1Zb7|Zn=Y`|cH1{+e0*MWu=<GhR*Y}8<5ig8_!8*D-`&P!-C(I23L%<>fD
zSh0L!Fi6WDc-;oq4h4$w^Y&q4H6n1?>RmgWT%lqtS46B<1P*`Wn}6ZtiWOr&bVM=k
z(<O@Wy|Gj=mMb$@rDB|By<(hZlvte<jK>-sig6ot8m!A;-HNd;^(e;q>{X2A`V?ci
ze#PbtZ@}<8gjj$9gAEFE_YTwx&k;s^xkv<z??<CPEAklE=a^zV))-fe#}gBZ@x3GT
z>qI|7UbyUeit%_bUop;Sfv}*m7x{9jWiR$wYS|--aoI~0<Fc13#$_*4jLTlB7?-_X
zF)n*lv80$i#W>AQ#aOOOF_!B#SdYPai7l6Q=lbkZjPINMig7<0Fxa4C+(ttN8zxpS
z`DD2fgN+(&%wXe+u}(}V#`O|<D$$RSPnOG5jMqEz6=S&q#aJ$^7>_Xv72`CE6yr3D
zi8V+Wm_>wz<u{BK!QOT1C0H&A!4B3aIUXxED!FsEe(h2x*KNr4D8_Z&s~C@8`V`}P
zYQJJU)*lcSmW;XbHT>XGe=TH(lH)j?or-aP*k!QYig6q5QH<wDGk=rNGqeNWr)Mk1
za&r{p>&;b+?b$qHSZw3|H(xPc<6B5<rO2^;S)>@3VX-iG?||H6x8L#Ka`5!5Ov!PY
zl?JOfSX42tmk!0aK06iTGIS}%X?82dY4#|_Y4$3{ZPaJ5eqnB1tx@Xny+6<YqpQzB
zk^|#>4k^a@99E3wMigVYQN_4?V~TP4#)Y{uG)X=`TKq=epB&nm=nr6=mpsKdFZslp
zMUHJjfnuCySTTN<yHGKHzeSN^oMy3NoX?12TxTVUv0SNQe7!QocuZ8O7|YcgENZY0
zgLN9L%V6D#vA*;WYmv5PJJCxlDvY1i>l5aDNMPUk>SOPagJ*jNmE3(V`_XqC8&d3<
zcd!4nW5bH^9B70X0w>t_JE|DR9*hxd6*>0FjT38AY=T(3VxgxK{b-di)}=hfxUb|Z
z_Whe)j&O0W&I%M`T?!LhE$6dd7aFWcG0sb|Vtl=bu&`VQ_jg?H)Z5<sEjf7ktWk1F
z;}^xaue1|eBWYdu+?DTiX|7d_V>Q<)#${hG%-#Qx=DPE~hvB4`&t5~WPsu%U(XwAU
zxh;zEJ#|>6$>keSa_`uA`2TZh?ox7GzTJwkF72T-J0!8v^}kK*-}+2K2f;Ya0>!x9
z!@^vhLGJ#uw|(5@bD@&sx?ZH@PP*mDKRdZnL$1t_Yc%BA72~>Is~C^x*C}@W{a0^u
z`CP9U*YyU2-A(K^NsQMDHY&#RfK7_AZQZQchfg~5L6^@him^{_t76=5w<*Ts>+J^H
zp%~lUor<-UulT#m=Pt##e7hCnGVD=|^>gO43B5*L^Yvyc#&I5V6yyB>=PJg}9L!UU
z^D<vCZli^YarqW0#`#>V80Te)V*DKKQiGK%#yVJ|7`IWQVw}%*#kgM98f=}x)*Ebt
z!R}U!%dpX4n-t^u*k;8z%`J*?f8Q$1*-z+a)A%>u<@&>jl4JWhs@MaIu07kyjVZ>q
zZd@^r8JbXxbucuR+>h8!<SEAWl5emAgM|%NXs{xK6&oyKuo8on8m!D<l?JOfSkz!0
z2J19fm%+LX)?=_<gY_A#-(Uj<8#LIE!G;YsVz5zzjTvm*U=xb{{M@0_U7rs9*64qV
zaevQOjQeeY!NLYBG+2=^wr9L<U*gL}BCvJ5_EPGzB9C!C%M4a2EG%hZZh<uU8Sr&V
zj^`HZiQO)8Y_B&EyF;<N6=PesQ87+)6S22TnmnG^Y_KiFFd^pq=2peH&bA2)%lW7m
z$Te>rJwp!OTxML!alK3^xd#Ux_Q#QP|0kh?NR#E}DaLu3uNcpn7b?bbiww3{F&?8V
zQH;}EN~}}Lz^q)c<4=3yQ8~q{vl_*?-5U+oE-Wl*pdC8pxa_et{xbkQN{;KZSIHe2
zddQEd*{bB&C%#QFF5h;=xE*#V#y<a@ig8@tF2z`Gw_+@}M=_pr&HP<*oz<*46U+Wy
zI}{2-P?D=puCpS=xa`FSix{lLV5P#Gt?QILv8}83<sx3Yv#pEzET$8j&kloi3JX)&
z`B~YGN{;Jg6R~%SJdYzc6T`rh?;Tr+y<4%Zim@+tn__IUwi8<?X|nHdhrxC##_O=V
z47QutopL>%qwgX1AHsN^I&)V-&%ju2w!!8o_Ng16!V<5iyK@y|pW{5m-t~{wo1ENy
z#rRq7g$7%sSmkEyj1bGqV#WA9%S#kv|L0Q0curZa*zZp0^4E`Qgt>JD)aNgrI)9$a
zOFPMR$&cq=v&#1gtX1rYHy-g{PHvrIuldUmmgT&<UT?4s!dzZ(y|)dY-|OTylH7ab
z$0xsd^nH$PQjFuMH!JqoFDm}!<hBq);5^&9t%~t;XWNLqPvk!F^XMrq&FzY@4cVa>
z_pzOdvD_}j_<Fk)<23gOb9NB<3}5t;@49^E|8Jrnf$@B^Kv-CQgDnTU_k#DK%Dwhm
zq~!P>w^&$lTyDJ_AA0JFo1NS`k^_6);y*m%*m{F)P-(vE>z!DR@ba?VklSIfor<wP
zWS3%p`@q^#cfH+;vF+KT*<U|0*U8QNeWI>Wc7C76Y{fXndJeJoiyYqr<|@W^cb>4Y
zoR9YVPdWbUsPFrARzh-Md_O8xjPFNf#6BQ$eDA1KjK^U0ig652R56ZO=unK`J=3We
z=d(*O?$h0hvEQ^uF|O-gVXhyc?9YroxmymN4i5Nokq8)%CkB01<T2jUVn{JA!?3y@
z@AWa}%cWj#T*>jcC+|6@gQ;@)K8xj(ZBKzPE<5L?$d^k^v)E^`G`T(_it+VI3|1;E
zEOiXMMqP7kcDs^ey<V#rUvHhk)*ILBS8{y40mb-wg9aN?*W)?!E+xm;+fA%n>V>bj
zM=|cVGsm4y6h%HHa=f-Q+hB7P`^3iOUlVb!Kg?B(*L~+1Y`$Wv_mp8s?4`L-F&=9y
zBKBc9|Hy~F^93ijSQrc+^abp~pFH|X$I69;iLLy=@BR5-r%IFWab1eB&FU6bKxy9l
zU)Qg6*X#G?B3@qDP7Da+eE#7lAHZ$GEBmlwcRcv&KR7mKu+Sfp)4XzY!H=9=fnpbZ
z=J6joRwT^L<2J~TJby1Hxx0kTdHs$vom{CfXD2=)KYoAC*?)4ZhSCJ%cdj=oxpn8g
z?Mf%tspLKq{>8@~>k<~L>qrD?KJ)M8P<^k?HYz#pE1QUYRL<wI{$|B^e7%KOkH}s0
z(57?U^|lIgWd}QU##_Jc*a*peOn&6?*{EXwarSwB8ODgA&^)&oS8UF=U-U_Ly$Qv5
zj1u}|qHXaYCHukhh}|uW-_w+@80V#c7&5`*kg#Gr=PD%jDUsVe_L@y{@Y=6Pn5)lT
z`E5nb6N?;MOmbknx7`wApAp8-xh++U*W=0+W4Ri|Sguhqer~s2F}AI172`4AI>mU8
zg7u2=IC6txJf6Q>F)rUm#khQ%6l1x~im}`l#kgL!D#rD)O);*Q?TT@|>`;vBWv60X
zFS``ub>H2J@%r>0#dy9s^G}IB1|4KJTQR=g9L4y0a~0z>=NW81F-*?cx4lrYcmKY^
zAJZ;UjK|)K6=UDb62;ioEhY9@$qTn%xngX0YZPO<)JSY2>iXgHaqw(NyJ8QQ-14Mj
zYZc=$(K^L={;;0d=Oi(f+d%B|!q_g|tr+X|Mq(JaFx#ZqBX_sG#+6~SVm#*Cq8N|8
zw;F7lV(f?Bt{A7eLzuJID8q(t^jEuljw^QjD}H~eV>5Rr`U>RuUNu`WZihL-_<D=W
zkHApHYxhDWcg35VFL10#u^+APdb4B2im_ZoUGIX(Ww^X|y`_qM_pw{P;aI(5FMoIF
zn~tqj*W>c7Q*xnaM*Q`T9wo=^-fOTvmFBBHd*t~pFIz~iPk!Wa!B)k1ZoiG#7e$W8
z-rE(srSk(5?s_|jA$X2;ey6b6@*BqNVC;|Ft=NA>s?gQEc9{9+gf2mj$5OKu<9Bn;
zG1y$ic-%8jnA1UAufHMj&h=tnF5;De$NCW^H}Br?Q?3kUhFqo3V)epfsd{2xlEgTl
zQN`GA+MyWBbt=a9oGxK*zJlxRexSF=m7&*{i$uV<?0r5f@)+CseqtC1a$W`$<1!2?
z#&Sc7aT$gcV_P>O%#{y$`NC@-!g8~xXX8qa%P>Lg%W^)Cg+qTy=qDKO)0Ri<E5iPC
zWyQ&I@UE9n>>l}z{bvOR3oFL=@Iql>Neg`pX`a9M8sA1PQF1)@T}rH9<aqyra>e-G
zSR>5!709t)s>7FyM8H^II(=5;F}8JG2J03Umb6elq{)7i%}S2vhFgezRpeGh@5WM?
z*A811V_UaPF_zn|7|ZQYjN5&uVyB(G;Ru(PU5c^XZpH3@_`yLZw?{D^C(rzAqRvqE
zcmC$_Z#%g{Va_K2#yU}?<Q^FN$X}h@QbVp>F)m+?V!Y<os2In>wG)FwiudSQOAM29
z9xJXh*m}iS2R8_FdW|$$ulsztNCb@ay5DC-9^-NHfMR^TL4yqm3(Iw&^SIv9D_4G4
z4xaArQgW>GyGd@doPYIQxBJfk6ig)A9gN#Otk}d4fBtfJy+Xw}zMx34x}N(GcH`x<
zSTUXhMHFMdVu@nh$4ZIai!#t2k!8d%XyfZu62oFC&pYZB<9k3<F_!BfHXv#8{isuz
z(<QL#d*5`r9K3qjKyq00WSzKMF<u+&6XuPjLXn6!@I-?0Z-#sZNbY|5`<`pJM&#hJ
zL1J6vH=f%M5qm%w=Vh1}l!)WxMu@?%aQ_=6HYn_+uikm99K5`Y8EjlJUeB2@Sm<vF
zz1G*uGg!W298*(Zu&`o0zAjXZ%TS~k%M~leauI`-7_8J_Wd^HMjO(S|U{S?bCprw)
zX|OJXbt}gC>@irc!TJ>AHtJW5uQ#9=%MB{V^)jRwxBIYS4>tYuV%LvG6ytmUsKLe*
z<1&mZ#@Cx5_8rN@;UDh&lgmr!?}`2g_T5uYdbeYF#2%C%c|4yl%-Kk=C6D~8#L3Mg
zx$nx4Jg1yba$rCH$ew>VxrmbESd|jR*k@I$Si{Dl9WKo>#kdTW!ra^fdHL;WwKJVu
zhmzyGbP982hupQzb(cB04JyqqKJiUIwxZupGZKLuk3$B0RutJP?2fNKc8g1M&|pJ~
z@fz5$VpW%R{luj?q8RJasA4>S7!&5oj(qYsEA$ViOA)UOT)sS?#mdL`s(gbL2n)+~
zFqXpgc>b_R$?;ffF|mh`&#Uj*E(h;EwnQ<`%Tj}t3kypc$P3c!y#7tSa`4jZRC1h`
zF2(qI-HP!zxkoXU>s5@)*QXfUtbWCk#=FEGmU6LwX;87Gafo8P&%&@`oaTsPoX=5V
zPS21R-p_Humy1NeSkFRxoDLR6z9)>wk$J*gnvV+mzb`#LCI_$m<`R2Mej6?hz231R
zN)zm>BkN9etk_@?Bh96TT)Dw&h;5Th@SLkrF}4Nmim{J#tuR+FNb{JZzksgh)l0XM
zV?FCJ<TjDq_a!a9r*2k^pK;%!7(d6pRWVL;o58j##@E}S7}v{AgY7cdZed|5GwcM)
ze$Gq(3vNlTJ`4UYp`Tz$^EhIU3uE6}p<?g5dc4`CS)>@xtBMul_KO&-#9*bw5Ujv^
z)RhTyx&-#;M;H2bx6xpoD$SkmojAsouS+p*qi)6cKGvfc$FcM(#$%K|gY_%MvAqL|
zaXtqXW4R$>Pe`FzuZM+&<u~XO*lUje=mI%-y0lx#@jYjcVw~p8e<pMgX|mnTcTDD~
zKf;CL|1eK2a7^-oMrAz<8>~<<zULGv_UV8A(f3&uE4E^7<JHIx@)9BTWBHr!jU|fl
z^-6_>AunZs+&RCx_8oHY(rnjqk0jO+))K=Yiq~4#5gQT4*IQ5Qr@~mzdK{Cw{+TfM
z59RB1O!E12`J3hXh+&}1W$za@Q+|s`n!k{v`-e0)liV-mZ=QE-A@(a_T!yX0Mup`S
zRvsw_ug<m+`?dVW>)P9iJtd6Cp98ZF56zX|BKeWXIdXLWkk1iev2l5fefm?c+XW6b
zE^MA0o!r7todmat#|n;4&kn~4@-J2|MT1DkjTyl3yJI-kF5d#TPY4XY)&luNLXp7}
z<hbn(D_$fAj}^+%vvtC7&iQY8Vy9yf`Qp-irF`e>mB`;Q8yOiqQ@+>Cn{&1tyfiE2
zh-*su1~Fm$`>|K8lY_?^<>;lEUo?2ReCK>d4c4w0=cSX_mGYg_?3Tat4ntl_2TSGq
zkC*j%z97`gHu>G<<$C#>(;OC77MHt0*aIK<OQ#&XGDJn#l^x9eLz?U4|6H12Kl<xu
zyjXXzF2$1aDGYUreBLO>#!rl3=;vK;jO5-TzYTo*Cs#SPOR?t)H)B}u$&Cvu6h%Rr
zRr1?kk9g6sj&+On9~Lhk*fm`bql!Jb;iKdWu}|MogRbVWnX?k*gWSdc`~Yr|9?KUt
zF5lhtUUkn-&rK-V2o)Wj(1{lLd-E}CJ}(DPE~3~SN4@eg$4Z6u$R9}ab~%1&$>;vl
zu{^oEIz0n(|8TuI!q7*=MtXAdXB{QK#I9E$-&`9(?nNX28*ywdvA4;OcV2l^onv8P
z?t1@@ALIYL@)5gJeqR-;TMP`gh|*jyf3u!Ngw2-U&{x3DJ?i*p<>1Mc3iJAHoISN;
zu4m_wW>lDKqs{X5gmXXqK{<GG{gR-|=fm>b??T(U92*oSO)J;SAH>-0BSlB8aqK(9
za8G46EX=F3P|@I%!k)SB*I4TFt``=qnkU~;hSR{_a+2pKLOx4{6~@^)a{OFZrDxK?
zI!O-fkJoQmDu-AZj+5t0<U7(lQ;y5;dG$&;cx*)2%ZVNP*8lU%hmIL07Vf;>@9%}e
zUP0`pqtE$o`O{0YRM;8BHvIgQjgEB+<LjMp^SlYi`sjK;kslX+;Yn1hm*(h;V|}_)
zY%6rp{X^L!FNxWZ&QR%~sJQ<RtV|f%uT#n{RpkEzt2bD?Ftkypw2^%E|3R*U<X-BN
zSU%U0+zE<x3yU6sG)o6hQLNx)@q9}8(C+RZu2&?iQ;v|sy~F(j8x}TSj;I&Zx%&r}
zcaoG*j$mka_YbUFSg9O4#TIBbE-V5ja?m&T4|0){6Zyn--9NA;!e+{`Q|!d~4#*L#
zR9NAWvFm9zAO-f?NUnE*k{cFwgmg0G^Fqb)=Y>K?&q&X@q%uUEyfPFkxn5yTCp7Cf
z*cM@~d>5%SQTeV6nmr;+iXdgkAJlBv$%%e0QfZDFY?m;X7cDn#$c3b_UD>r<zQMu<
zn=j1e#WPm%a-iLd9Fu-@i7MYh$3$OVuUN4#*lYCLh+<_1>k#J3ce#@5GFXqn`V2N;
zu&u&ez399Q8En`{^QXd`F6lH!ot*Te5>@tHbUpNY_YZ9}F3j~6&GHHp_37PE;)0MX
zFj%2uk{68K+&{=ggrQ>4r*CvXj$pH2ov1U-@`;rxxdLHx<u}-@D#cza%+;A@5n&5q
zL&UZ&S8_XFlgLZGVq*r|Ww3F_q(7`sX@-i#E=xv{m)jH@m05nC{D%IZ*>8op^4+fF
zb_tW>iCk>#=CIf9l;#}{$Pp}bZv1*upWZ+z&cS90bJy#P|BeG#zOb+y(GHz*bpODL
zU7At`Zy+CsU?s%f>xAS8Rwm4|1(N1^#X3mt|0&jGupWc;5qnUjIY8{Yift7(Q+`8T
zKdRV}!G<Z#$Cca;l6zXQF_P0PbY4PVm>m&M1G*HEcGyX2g5mcd1{)E?&^|#dY_LLu
zNp}cLv)Et}gOwNzwlAm*us1=h(qQ!liyExMV4Vi*GFZ34dJNWUus(zJ8*IQ}g9aNi
z*s#Gy3^r=8F@ud8Y{FnLo_WI4_CJH=8?3-!VS^PKtjJ)+28$T1#9*Zcga0U~&MFO7
zZ?LGrIt<onur7mj8?47*y$0(uSiivr3^r)6A%hJYY{X!r1{*WjxWOh2h5=EKF69|4
z-(Up>3mXhR#h|<t8LZe~5rdT&tkhs-2CFn!y}_ae>o8cS!MY6AZLl7L^%|_tVEqOg
zFxa5Mh72}ruo1^(41KEHd)z;a`37Z>Jx7ianUiR?-C*#g2k9>S<w0!1U>HCL$>kX=
z-(Up>3mdG^U_}NiHdw@9B?c=sSed~p4OVZksKGi6)@iUVgLNCM$6&n%>oZut!3GRA
zXs{uJ4I6C4V50^bGuXJnCJYu5gAmyN43=-O0)vGOR%oyygB2SrVz3f}l^U$fV3h`|
zHyG9lg4&_OV4Vi*GFZ34dJNWUus(zJ8*IQ}g9aNi*s#Gy3^r=8F@ud8Y{FonBZJ#L
z&tUlmD==8tU|6pS(!nBw6&oyKuo8on8m!D<l?JOfSkz!02J19fm%+LX)?=_<gY_A#
z-(Uj<8+0tqII{1kQ0OF#BlE*4e#HlcVLdb*8!_1LjWqK_IfK$XRhT!XO_P^%g$3nv
zi6K{Muy$cse@IupZebW#r(<6c_L2ZLXr#GASWx-K4ThMLAh`lzSR;>w!YT8BGaO4(
zp9_TrmAzD0K|uNHh2;mZ4uf?WY4#dyz+l6|3Ip;oAxuIx(zf5sqvLg!re0oRu&^-s
zU)nU!GUSSd1?kIG1}hg9RM(A$+}ni(>C1<VH2+IjP@R26SWv&+D$LWtH1+v}AvY#0
zs9yeVu-SghP^!&BY*SDf<_Qa`&xHnCEG(!#%Y+4$y-rwAovjrXl+P~XdUp#8D#IpW
zLG}49VN#`Ob$3WuP+qnhY*biK`Tk<C*>bTUTYiSYA_luzSWvyJ5EfJ~YYq0FMw*`z
z7F71l276SP{4Z@g{6s*IF6}hfAB6?A?H*x4Wk2>s!7OaBbA<)f^<{?KQei>&l}2Hb
z)wK1}AuOm~?ljW;l(3+De#Kzl5*F0opAZ(*?qkA&>iX|Sn#W4vg35l9u%I%WB`m03
ziVb#!uyogxVWRg>h9c4qkqF1hfgvA3ENrkMgGB<E3?aRLo8<o^q0-1%@xO5Z8<x*v
z`G84yhW~F?XjbS&vW|dghkwaGe4CI;oaOyC!~gByjyXJZjQ88&{%<dq_4n9$GyUJ%
zKj?lt!vAg0aqhPx{ok&Yv|_SH`M;eu!~K@$|Ms6!sd@4{{<-|&_)O^1<;e5Nq1S{i
z3M~p<9J)jvUW<e-4c!<j3*8jDIrP?0Yv_*9dqTaT&7ns^KMw5-Jso;3^rz5YCDv}%
zVFmKv{KF!L-Ei334|~^PA3E&whkf&~rw;qeVMot6cE))#u9&f6#)oEnWX8v5+%w}x
zGd^(m#WR09^R6SVJaYGuy+^$#@3L9HpY@5OOO82w_C2##yy%2uzjy4a<8C|dj^obC
ze=`5mFTU<2bB-@K{*2?FIR5Q(Ui;GBFYP~}@x;P{9~ZpyWs6Q4JLw}QFP{6yxt}@Z
zx>Nsk>cGou!zaAryRV3zcFO6Gp1x+@>90KIjIC$9^~_TXA1my5)ho~X;aP7#d;a{3
z=9kRBVgBK-?tk^I=N$c--LLsf(VG_hZNcZxz4p9+p0{aX+4)CY@YM@$y>M3XH;Pxj
z_LPf$deMg0y?N2$7x!Ph@{%)O|J3XMGji3X$6Ypb*{aJ=TRgmYeDNpWaMcxmx#F`|
zmX`cq$rs;v{Z%urzUS&&m&|(8H{P`T-wLkjyyo1}@zT#;d*gLSy!mTyZeDuk^}oLU
z?i-fg_@c6t%f46EepC47@8A4`o1eZpddtWyk@Bm`x0bKE^~|?C{gzKx++2BF)%{gl
zsvf9%!?LBze!c9f>VH&!w&t4J<LlPcy{+!w>o(MVRQ~%?-F<Zr)IC=BtGeIR{j2Wi
z<u6-axctK9m&$*K$sKM^=$Oz9X;b&#3Gr_y%JCTKfhWotFO}nQ^7ql9neyMU@)6~d
z-{**xDU`qRz3+wI|IZA)GIYE|8sqnwA~`R#CG?fhCi(Acp)bq-|2A}={QsBbzx(Bg
z&sT-xT>Lf^`g-U=`F^bY4tl>x<3C8^+^=~5-6JwzmUO=C9U+JRHigE#-x7a+S<XJz
z`_KLMKi+vr8+ky!AQ$`VUdiDWxyrXg{qifWj4N&lJrqy%E1|Ibj`L%w#iU#+UzNPn
zOA6nT5^R=~zbumX$<}Z8hX&+`^28)(NS(b;&a9W(yj^4<fwS(FGtdTIQn&99H3;dG
zU$%y7q&AM0-(+b+>KAo?tQ=>`yyzJD760L`8v9o$eRiG9DISo|Sz>@1<nu524uAFM
zC4p+`|6i2f<h4Q)P%rZm`E9Eh%Vlz0EPo#<=hh2*wfy$9{C1kiT_wN$0rDcdR{Tp}
z6z<YamoC!$i>QZ7*Gki+2N~o6e_tg=+{>q2$K?Te$F-2}F&VR=T(1>FKSRzvUH<;8
zd`9Gcfqc3&asGRyOs?E07s`%upq@|$loM&XdRQYj9OUDEIl613{NIyny+^KfrBrpM
zvNuYa*_7S26WYh+`At#=u8S>FA68xPxkrg?x^q!iuI@7BeMHLV^4=hIin>Dkp}vCj
z!sT7peUId4GIfu7=Q?+7<nr&*LK||MLC(@K)?2Qx4N_Lr7xE3AcGqTI1Bd*WT+`J7
z&UM$vwQ;_aMLoNEI8FKhUoTzTxOTZk<ZhNO`3d>#kk8rD?)*1o-8EhNtdR8GbzK`E
zJ>&;<gtk6a<a9bH&;Q70vgOg&xKZNnkuT^4u7`A8o9TX~+t$?)>eA);oBKGuw;!K<
z{(}0w%ja=29ztGA<k%%2<QW5O)HTY@^}zi)BIk6-2lm9(&DZ7c-^mAhjq9SH>9+mY
zi80$WBFD4jvrIm&txuH6NvV9CUB3Rs>D%}!nH=ag{tx^ndA9UcxATYOT3o)pZRZz>
z!*XxZJ42pJL47*C`I|iS!|7cYmgm;w<Ld3fSH$WY_e9uQ*AA|2psQ~?Ewv5MPG}=n
z-)L9Y2F<Tb)IaJ2I^pWg9bNwZNAkk?+uQn^C2hDj={+d@f^CA!FLWIG-E?+B$D!XJ
zes${g(&@OXSJrRTZ94r%+n_F?*BE1<j-k)cYuD%4HtbD#b@^QXMcID2@Zgj!ojtit
z`o(mxCtnfg0PDvulzl;)x_;nn5bF3b(Mz-$_f2gZosMXG2l;e$vQ_jEb)wrpTm6IX
zrMnk7+u+LK`nW64^7BKXn_d-r4yCFv6uM77cbqAYF34|B%J;{m|KBO!^X1bopY!I2
zLKmDX&sUxk3Jskl&nQYCda>B0&&hGOEMUA__!?nP$nhpg=Njo#UywBZF2`EPofHav
zW}cK&j(=Sg3jIWW&zHZSlh4B<_j-Bwsavjl?@gi5o6eB&wOpf6Y}OHycAH%1I&ofn
z^EEP$m*YbD?Kb)Jz)s5N#KrQQtNebie9o57(c(XtA=g<Z$M?(Uck;Ph{=P)|!jL?-
z(J03`lBY8y4=<B6-z#k6C85x$$bMLU-za~7OU^l2KChDV|03miM1H$h^8GgXd#U8>
zGRYs_-terPf1>35`;zB!IYv$og^ri=KQ3ijAjkieI{2B?-`}Oa|0>6KNO|kzocGIh
zKPG9+mERwd-!7MWyjZ^fLu~mI^8Nkt{cx$vyCn}d$?;-2XQLdyD!>0m(tb$l<OE5l
zSL)#(^80t?c=9RIh8M{GwetCve8LxoLO00q^K$N~lD|*M-#v29_vCm{vDhv7UM<I$
zNFLYA@f-4aqp%;y@lSG`BgY>|8BThwJUc9D)XVXM^0`kw6T;4y_PSiY@04`zlDhlh
zMKWfP`nf^!vP6y_l(JkYzuhnS+$nv3gB)kb7^q0v<4GyU*X39uveyW^S3V2mKJq^K
zTqtsjBu~GU^FJi=19HwYQvd&w@8`Tu^ihuGa(ugd@I2zP(jIS>wp=E18zsMAl;5L~
zQ0P%P{z*R1$~k!6>Okwc)^X_flA9){-_UF5_}=LD$4^eyZLQa=)6i$=@(Wdup~KMM
zAl+qsJwwjjmpaS(dNA#CI=!u|Jn(wU_Bf}r!M1lYI{QM=*C*eY)7R-bR><jV^4J&S
zf|a-0`ik+D8~b96h4C-OSQrEEi!lPmWNdFSHp|)EgJW|sHnzsL>Bb2`;|0v$^qda!
zxw$g;SR<cwb2-fQFrU+NIgAT1pSw=xA3UGKypQK{(C6;g$MhL<wqM5QZ9JdTb2#W9
zbR6?H%=Mtt(DQrc2)%@^V=jhy9mcDlkq_o{n9u#MeDr+I&EwqM&CS{L_!fHZ=4#M)
zH($eC4Rf!_%-3LVF=xYk4f8!WXG=F<!@MkL&W1Tyx;dMhlVR?Ld99wiVcv#$nVYj=
zZl>pLn6qKNc376<T+F2x$ehfYmtj8U=4P4ZWvsi?Wlpy9Ew=4-cGvkF_JzG=Tbr}9
z2glA%*2ae3Bx|wqLHl1X#}4^?T0UFl^Q?SeYvDI@eu&xsCcX^$z@9FXBm2)_*I<j_
zgM&?ly@5@=Q_h2*0=^;m%HTtCzBTyeV3XmOgMSTvHrVoeL}pYzhhG!x`-O6Z&+TeC
z!e%?4P*nbg56=09hUIT(x8WOtU4czGw>06~bABP%7Wjdj56JoB;GaYPSSm7W<O92o
zF$ww#{1)*4+%3O9EFbt`;K%uke249W{f50i<=Rl_Qu)9S2cI2m4(=haQ}D&XZ|D4Y
zEpi_GR`ADtNWP;Vu}=>^%rD9Bu211U06!mminwp!e&BqI@Fl^w2wM$1|AffF7YF~?
z9{CRYfBJPX{}^mL?D;kF_wDk5-|&-iboUkb#2%EtVb|f)drrQ?pZAhC$Ly!G=eXCv
zw|AlZ4x5VmO|^W7&kJ_{PWcWWnX~oISNJ9Q{c-v1mU@Ga5I(L6`5X6k*wmAjN_)!(
z_8&ek*#2hu`-Aeqc$@D*o8>o*7vMMiseFgO1Aau<WB3r^3x@A)*7Y%;9ehE!k6a{w
z<Nk509O2W14;Vh)cgf%ID}GsyxIe>p@-z89>xP8y4}Lt{BQBEPZjle}86TD7gYtP=
zKF8b`^Xb9&#QhS!Vfa(wABB$(zERv`;UC0(7CuquKZKuff6Xo6`-Q(3zH8j$;PZvg
zn)3?(?@KR9^+obMkH=}~C(b8{z5*XK^cTKov@7ZoeIEV9`Qy<?U}w<p(KpZ!ChMEW
zSj+k6VTaQB=+pUt(1%>#aen!`MBdo~jMv<~65}=4fK|esPoDkpLB4p5$K1Wq^<nhc
zoR2crr(qMP%ed)+TXW;4oR1|j-oZU7$ksVKcc9i7)7h^d9Rwft`4=SY8SFLNG}!K(
zT}#-t{dMo2%$$_(&(lF?k6CfxZR}WWPG_ADMf*?my7zR_*@LOO7#C}s>tZ^dyk&Aa
zjInSorX$!t_(F~8;IYMY83TXs>dEOg=0nhL%)8vYXtJ?NZhn*-PbB<N@V`uF+dLig
z6*d}vHQ42+s}8*0!ltwC!r!6C!|;9Zm>7N+_(|b=fo}+Y7Z;lZe~VkYaqBkE_c%L@
zH{f%D&kp_;7pDY&OS(8a#4EX2JLe}`kYPQ?t>t7BXU8`AV2(fZ*aLdrmRr}Ew(+9V
zY1}*=Y%}z=wei5)<d@!>Y?Cqf(>9syv0gvl7xowS3_g9>GZ*g+d*;^9b3V4rKDOy(
zdmq0lHqJ=5Uf|XW+&Y0<Q^%P2=*wjNAQD?M$c>Npf6V@Lu)$l)WFH2J6?(0FR><dr
zZ%F=oy4dE|mLGWAjQDaMFCS>T44drian2UYJS5F?CewNRdrifG*V(Ap@0`wN_srCE
zu)l8H;GUCmf2Xs%n7<<)0rPejkAV5Qi$~xX3Cz<mKhGvM;Y*@3{Olmcejk%-=@^A&
z5+kCYCB*vLuf_M1ZvMAI;%P7jiHaSCURtpWh{fRe1&l{NB-g|E<ibm1u^5QMSS4ds
z?|DJ_?)-OH$K%+BBQB3U;}#U-aG`K7?)2nDUt!z6zsK8$x?L|3-Qed5`I#*Ew)WP)
z0e^{$;d5)+>H5R|eoi)>PA|^j)4*KHjjf^2&|mZ?=r?qCZ+*|X=L9DAT<rd|@tC`F
z{29iJ`Z?Hi;}grqPerF;Ti-2XMYiG2c4r$~*48w+u?qAUb{0B)uY8;>p6pr*Y%z~l
z@T@G`V%T>0%_n1%aZfr}erVjIgVqOe-$slt?%D3yZ``x_`EU5y-8100hr2jbw;qmr
z`c&7%VOQNV;B2!Ogkx(Gh=&b&_8WE$ereb=#O=B<LXeLdb_(|i+-J2dcVnH9nrosS
zTpkdEd)*bWI9S+D=o|70{lYlFjRBw^)8*dqxw^^qp?z^b;J%~#&1Cw_!RjwTePv(o
zkFY=Q1AGt2#{N$ieO<INr>{BRcCdYR;}my17<y~PHT5o;oc`h-l8bA~#WhV=8*S<O
zoDB0$H|ON_oSd%bbp24&^()?(v+KD%$YReJ?#n&MrtLUJo&%ojT7Ay8=WM&S?eGJp
z^EXbnaeMgYoWAGm`@XmD2Sd-(tr2~8`Q-F_U-$uY>;8#-cc$te5AuyWpY-1Di8@_u
zb2^<pr}Dt-Y|eLm=*6k*FF!iRu2}nf{7s(s(&L_>euZ@-_Y5(7f4TiVV*XFw;{$7g
zyl#|RGfF%UKV8NX^Cd=iGV{ZIF`mfT=0ndmA58y-9#b4IK0G{AGa0>wjm|xTaA4mX
zu)pr-hw7dmuaTJ3oZjZ1{R(=oMbKE&jWZ9{{z^ZQ80nne=JYljy`3)O+EtTW=i3+K
z+Aqj8d2IWhlH~c%f!Y%caq_umyOQIlvz^x;Y+DOEo0nn#j=LmY*2QGxo&z}eYjwGC
zZep)#?CA>~UUSRj=4boD{^r&xp8x9<*UI{?+iU$!`JV0_7km4>%BBo!$S(x@`;64V
z-aJcql=OeM7ya`g4j;a3j>VrZ<-0~c7*}Ag{h;SioZrkHr_1=bRQ7_Itp5zYec0)H
z<ulc1vUq&VYXb*rY@8bxC+o2_F3wh0@r<^9797uK;~fHcK6|R~lGT1+j4R%A5cWOD
z?en~U#uc!sc<ye0#y|wwUF>U+?%i3))84#43%ZicJG7pa^I(6oeTNqM6Kt+~e->;o
zZ0S_qn}z<G>D^iAw{HJ0*lD*1WA5Eqv3HWZ5Z;}&p?Y#-1dI)^&bBw>gPg71Kel$k
zezvpOjurGcVQ=0wpKg4xqCBUw)A?QU)7e)RG$z=a@jy0Xfve<wW7&=ccnknrdzaW;
zHx_^|*o_CUhXUfQ_SL&IvFCyt4`3dc8xy4Ncd<Xm1d|=d?r)vFM4ku9>8!+k%HBBq
z{yn^F5AWWC&+CQ$4%i@_)$=a5$K3uN8*HjS@MD9Vzw6M8bv)GH1^X*`M(FwUE?D%T
z+<Rc9A1%$j2X;EV2llCw+;bueWt@XK2KEGj-^Z;7@m{Gxd!+I+BD@Badp>0PJs<Lo
za}WHO340jk#!ZLbxM{lh06!~xr%q;V8}=*bw+`N0G`C-3>iYJ+_FI4EAUq?TTWiU!
zwd~El&QIjl2R;8^ZlBN0@o&>*Y;ejX<KA*(gWNNt_etE@!Fu)%F>h;ge(T)3E+x)5
zQ;hL+v9Zw=x%pQv1|vHk>2z8neD{^P=bUenwd>sb05iW2P`^*4TK3VwezKX~C!*z+
z%X>_wA{Q22%|>pz+!LNS2=6b+`8RU@jlJ=2Jel(&=lmOo*n43=H_3N7<op{s|Hi@g
zZ<OWy$T>TkrJZ%p_TycaPsm*5PI-<G@p^bC<xOXXLjCeL-Xnav{D$X4?vOa#Ps-<d
z`MX0t92fU#`FpE;^5=y@&&lUg@{HZH@;BBytL5XKTU{^TzagL5|0d%pIbJBoljIq?
zWpb>S;|Jw~=ko9@-w_fIgS}a{ik}%VGKi14Q_j0mo~K(N`9quxVq_324&NSPWZo~|
ze<vRu=XQ_CjmpQx$b4AJb;he>zLmq}nRC3i5iv7`@*U6f;T_0V%lAU5%OhpH-S+a>
zv*~#M-npfr&^x4z56S0yQcgSvy;Od~+6Cr&YvlXOB>!&ya<}~buzZ$ET9-+>&&sok
z&zuwr-6v)Ji~Nq*X1psAan5rkjZ>}-g)Ws3-ko@{{JrxOiH(-;pO-wGDzbQX;QjJ@
zi=2b^Q{s7VJW~k2>X+m<yqD6wkFrkYQSX<${Noj&5Z=*?cS2%sv<azuyx;M1$pfAv
z;kaw~5xlr-$roa<G4FXo(mh$O1^c!~zMp<w?0uNm$nkdhU{CH($`N~dKPboN<nxj@
z$DT<&Ut}(n?|3#9YrWO-9q+HaQ;v9l<d@|5xO_e+zwMUmO~`k|HQz63x;Q<&$M{2%
zPrTc*Sz`A-D4)&p!Fw%lllJ+ke8*mfn8)$n0@y=k*7Y&}Nkka-21nf6Me^IN^7)xu
z=L_=NyX1S1{QhM*;@y=$ljE!#V)0lP$q{kYx5yFi^LD<&kILT<%I9hMAl~|z8$+S*
zOZ#9?jpL;)=E=1$m-1p?4ZKI--lEt(5YGy~Nz%hRU*RLbbD;C&n(%XB&!msZ`PK6G
zHB#n#<uhI8oy8gUQgZt!xp!OT#zVRB(7_%L-CuLy{pY!OyIi~-##0zWP4@lXFRjk$
zYc2*PF~-1{ZMyDdi!t}ioPEu$r^`6jjftnbz82^7HK(tKkiLF)#ep9WjMe6z8G%0t
zeyQ9$$|gUCeN_A)2l|<jkBc8EH}Bf_I(vrr*A|H14!%41?4Hl>);oITf!Eud&hC4i
zeWB><2jo6|pzUmKY><ls+M76_-{<CEx%t;2H2-?wAncKx8x!Ql1XEo<cp^83&DqyO
z$iDvOrUO5Q#XG%nHa2Htr)p#Kn-09rMkC2OTe3J2%jWi<pALIIeN6J@_U(jEE@<D*
zL*+d-c<u#pXNVa?%pT&;5JQK!vvlvyg>7+bVRuQq7xodxni%%?n#wvZ-l34~o}SPV
z7t=Xa-M*@RYPya0ARxZY?Olc#I^Mqw@r^-ym?6#)?_^+`jCUruSk39A-%hvpMz5h$
zcy`Uj!XjQ1v9K;?^H5xS$n@+f^cb;|h%r8p`dkp8&-Yy+ai`K>T&ywrr;A@){)Skr
z@lWNPJ@RpJywFkTIpP}kM%SU+tn1n6dAZmX#IGW*^hEjY_78XO5<y%t;z$vf>|%Zq
zM~Zl2#3>^V6|uyK14b+=;)nO<on)EbM+Uox*l*}MVw4dBK3#QwNZLEdo;zDUo#Gn)
zx+oTp?_%u{<Ba<b;&J-QCuhI0SKEnl&)!>|-grr}PGjFet=IQTzIlxDg#3+IXy`NI
zrdh|QyMFKMecbL6n}Rre^qU*z#>NYXhsU!Hh=WJ`J7Vk+FOT;Jz@B37&l2fdE>3(w
z`1!X^XX*OCPjc=!9dsRIv=@TD<35=wc4E5eJnrupqvQUJXJhc3&UAV9;^|4+b=Y(0
z`@M3U>X`hcw<g<kw3oK&uvcu;F^+;whdp=Wl^2>VpU&^)Iau$D_*~=U#wGhge{*|Q
z9GYv@ndXv{okvc_Ct{5^4!e4CIy@c58!v>h#-TROn2H}TTc63k()A5xIbA;xev;?=
zJQDMrLqXp^cS}y+bNaq-<C~|;-0_iy$?5jK7<*6Fznz;aruX$7NdMk+9d~~uH|{<l
zYc?;mu}CIA4b}lC+yAhZ<l+Oc-hnj^%qbBofVmjfX?TActa*%!%v-aJ*}_^R_K3m0
z8kk>V-39ypV7&#t9jv=!KPRlWyLmF!*Ex;=dkJCBAdJl>`<_s&J-9s$;9JBxD)zC#
zS}OL6!ag?G7Yh5=q<g10{KDy;S-@H={EKcq7VEC?ExI*X_!Xz}el+-W`5kFGu7G`)
z`@?SuAJqO_XWiF*HdCLNY=4++UwD`FhyC3b++5oAgT3to(En_7Kb_vQ&hHC-XI*Ds
z{r=YTLrKRE<~S#vO>COvzFM&RXlIPmVS}f-zLOiHA38Cx(`7FCk4gFkp`&}d4te%X
z$?K48*D#LB*|yj|j@T!1f8D>+#kyvSjhaq&_P?*py^kXIJ_?CVm$-yyGwhFhlFU)C
zN3GkB7JG^!cJX(jL$Je`dtn~tY}+eJVtXWD?uB_5=38!TiTEw-d5XPr5i^N>aWQ5`
zJS6tgMci*#eslXPAihi6dW=`~x_!U=Hdo?1*T@HRJM1y4-=m3fE!Kl{EI7s>7_(j{
zaf6tzVUFVFY<RYp;|dW|_y(E3V(f}Nd4DM%%*n7XF81fezPN60UepQ3BACOuy21Da
z<BV6y{0;R3Tm2dNpq}s^`u~;B9GN#_FJA1Ki@L+!yr@4H_l-HDzjv-MjxE9b&c&Cw
zxt)uNMLaC_=ABGTEcTwmSQdQ+F}3dfExbRjivh<o3_)?=i0O9w^`gzOw=DJwb}`=2
z0qj+*<6@x?*qhhIfMb7Ny}pV4bYbfcyC@bb7!)Vy=4#j<c|ka#W9jzrK>VwFwqYu^
zUhAyZS2yRH>|D$F8nT^Z6&!@;b#rkh34PVN3SEZ2LXW50_++~1><^Zu_lY@QnDc?{
z%YBt|bH77p?l+yr(HIZBYRQ4u*PM;b+1S0=cjo1?o{-M}x<74fPG=8Iot<v>_LudO
z)7_kZ_=Wf0h3PVuJ*{DKy2^fn+&V_gKjeG`hsxUSq3kdC^Fi<z<mO(vxtI3IX6xTN
zX8D1)ud^h!C#SPHot>)AhDr~-&gSM`hvwXCx{PCg^7;d>v)ax=hjXzGv3G*rC+i2f
zwS>&^wcWY3gxvn0vX-7HHfOrn*+nZ3yq(SMVV@ft?9E!j>*8~;sLYG-o@kDR*`MnP
z*jtn5Vc1_YH$KRIe1JVu^<G*oMh5R$MvM%e&v~C5_t(2__VwBV%7hrNz0v0y@!4K@
z`Q+>{))=6V@ZTcFYpTB6+<Tk$k1d8CL!bADE~kryb8&Dk<_+<Zh+#uK5aNH3AGc2(
z_P0a7L);qj2!A*7iTEJ&PxL+PcZXO=?0E+rIZvJeb#ZIhi??E)?8PZMh?qm@;<KW^
zF18bW0<ng8j>yGhy77>U%f#MZcn3S4rNi@cI$jO&m3V(U;woP(W%!)LaN^zccR)_g
zM+_p~8;|`s7sv;D10#mg#ZDqlBHenki<QKC=MkUi;vTVAC-&$>%p;z|ckzxc77_1;
z$1~E1bwqq4$24MpPweZ7eKrxVn90T*ti4!Y-;};ig6^4U*Mqs|>Y?;ZI{Mdi-)9vu
zru%ZOD4ia=J$p07nPTj=xA)B_SESeHyX1c8bUNKLeXv=0ws^YgH=ap$`w8QjWwtd3
zb5CKcht86Ab9xT{81E^JXRi;|UfOsL`b(0x$?O&H?n#r~TR5HG9|(QFq%pm|J6+dt
zs?$}!oo*j0dVR2T`uVKOcQvHfW!y(|`Wy<KAY)DUoQoUV;~6GAvy^G?_e^&B`K-@w
z&y54|yvtEn<(_HGJ=2(&_gedAOc#HD_#muL<zfN$kB@18`Insk!W|EW?ppf*&nizp
zcCf|`xp!;?KP!8n-UWtvIrc}uoE$z#>?sxW?CgPf#|C^5yf^Cp+Pfj!eaJq4X>RW&
z_-CiO*H~`vrPOED4^+%fwmSZ488chsB);dsPdAml_T1Rttu<uw&1gTQ-eWJ@*x+>Q
z4ViqAtHdU{wL5-aU(mbyV6$?1o>|XXkDLyrTW4~*GFct5_C>J9F4tX|8@uH8xlXL5
z?h79uVl%VdlLYp|#av8gUlRD%v6m$7&Dir4`<*(Qzg-yCm9SQ!_g1xRy<0nWef2^a
z|6s0xwPV+3v3`txi+yR(S7Fn!R*Zeeu+OUV_w>teZa<!E_TtetUhm1{_Txcc)_d~6
zN9op=GwsO(`_FswVC;(+BJ9WG_Tovm4-fX>!CJIiht_+e;vV4k-9Ze}^LfvmgFP<4
z;<DVBB{weLzt4tZ9rb<TSnLhrZu(0?A?$nRY~%uA>Gn4}7`~Zwd#Fb0CO59ZxEJe_
z_r~ob?nNjckAY$PgT}$QAHa^fy~=WNnAyi+W{Saddg$W4_Qe>*-Q%Z=zW(jT1Fx?+
zKlq{P2cIrFyQ%8H>uk=(=AJvA>T|~}%MZN1=4|YtX=5)Ezi_jBF!ueL%&$)pp9b#%
z{FMBLcyq*}yD{+<;)j?g<G^b9q#GN*RXE~hu)i;2&LE2z8pO{aw){@<8DMW%%&p-w
zfDZw&Gl(t6zOaZbM;_cf8+*gT_kh@O<PUN9*fSTg>4+tNSpLSI#fZ`Tpd8;X3^C>K
zcVVwy#FC?Yh?zh<ImT6(S79v-d%t3TN%&Y0_k)<9-SRp4lu*dUCnD}1@5Np(`9OR=
z;^GnCkJ$HOiM@m$2>Su!8Gwi6gE&pZIAY&htg|6T9nVU^rvM)i;{EYV0OJ4g{0;VH
zM%)qNu2IKza&%*KjNhDZ2G0awK7xIiF-FID@_q6*#^iW*06rSbUErfZJU(LL5$gw^
z3S#A-lTU?wFy}#=Vw{Ose)w|W$2e8$f392){`8CG_<s3#&lbqv*kc*-|L_TIln<V9
zfS&~ZFZg8O6T;jA&lX%J?SSXQum|)%q`ndB4}E|?A36cufqx3VCg_lhjXoI9SNvc}
z!Y7z}z9Kp1SwCNKFxsd2@?865`~1uI7bk4Adlm?G0`>v60d@hl7`Bz$686=_Ji@-h
z2BPo6ros-wrtYujn{FscwC{W5``-3J*h-WWHZt9_POxLze?67wonY$@)-zAIm%^U9
zXP;bLs@r29b|3fAO!Fti(`UO5hxH4+UTdwzrSnz&v~g<VQtX4jH~uO-OU3gkw_iTi
z0^DBvxp%3^m_q7#y6sh-$$xdQo(WmGa&o$i@m%hizU*S?bI<g}=0pebnZ8d4=<{82
zpL6k@xo7%9`*e?;S#nQ(zCY7<u-B0DF3qhW@68%A#(lZCH<_b|U&p-{3;rG*-<fHg
z;^Jkp9dA!&tZl`;)m=ULaY`;`KNqua#gFZ;_ix?1DE8j)pqRFGS0vkV=sm`Y&QA*;
zE#~~(7vWEJF>M%wyZ45pA7*-YIQ-JiZ?ZpP+;n`~-o~~eMlcuO7W31?$2FOE%4PDE
z><_!0&PQ_7vdP(N_@Ufdfs1F)#q-40UY^hI5%{$D#mi;w0_$tf*R{3w%MPuzHLR;m
zw>7m&x#!^?2pfSlKiCGWzhPYfYj3<Zfb~qQlb$9YtP?=DAoG0HueCCMz*zoJS-VZA
zUs#LJv~G)aeXQMj>+o{K8u0#F!_Blte8xqwHDb399M+1lZjbe1w`Py^dbd{Z){n6+
zjWy{x(q?Y$80*t6p1{QsAZ7ru0vscNcmTu!xPIW){!tHD`*$%6SOY_Ua4`TF`(gbH
zYxY=Eg0BW^_E@8GYxr2d=a>N2CDiu<S)YHOe6T)`m;m%I9TULo|5*FSIzQI-v6dgS
zj-O5!pa)pH_xh|Hv38G`3XF+)zdjxxyRk7pqjj)+>PJs<eJJNs&wgJT=Vyf8AdUs&
z<3o8r8a-ae_&nWSmXn#cx%JGTXOhy**KQR5BKlmW=aFE0_<1BZX2-hZ-n=6`=s6`9
zJN0~jMhW-tY@flK%JX-K3v=;FZl6`lH<HP=?oU5py7}boHM#jD-fhqEE-uz(D*Jmq
z-|XnV*4KRzC$e4UeXywqa*z2VE>DgT!M@=7*(QwVI8FrqNBw-Lv%BuOP`BqI;-e9Z
ziSZrAqX%<8QTX@a8-Xv>=`(zxJT`zY){PIIknewz7@9fosmc7|B(b@8=Gd)?VBb{4
zh`|<POzqZ2Fb>TorUc_njEkLpc6-ue+zkJ&wI@B+r(vV9HVywL_S(h%?CESao;`MZ
zk0L$}>smp+W6T%aJOOhA9UF|iPIf+!&0Ju!!~$nCA8>OS)Hn1Ba~K!ri@7~weKD6o
zn_?aVzXawmI^Gxk410SA%@s1u=Me8Z*}0sXzv;Of^d)Hi_G8i2yw`_9ua(aV`Fv4q
z1lNI^!?8aD=~W*lv5WF~^hFYbJww*;<nu-O{8m1Nhl@VQ=kxM;T0W=E42AmS^9T8?
zJt7pEKU<zbm(Tt3alb(p=ltr(m>kmg(mX159bDrq`Tpv>#5K0ccU;F^<EmM)e7QV0
zKKsRqb8vlkE#&Wuk|xr9si^wR^7({(cE|_U*Xg_?KXW?BAJRivkUrAEHC$T#$Av;J
zUq?!QUEWa-4RRjJfO5Nhp7xUDe4!qY=GRY%rP**yOb&I9_CTGw^nY0pOABdsNdeup
zkT$M|dN@PcG9qaq-!9J`^0%uO*OriZ-SP4Ah@49cWrQ5chkPLqJyPGuC(40qxUyS1
z;ba@6yi=9^^Au#cd|q2ge$$oh@{7tZFTcF8s(E>NeQjf7%Q@B2XsG6*@~WZ*<rQmM
zT341|P~KMF)>>V@y1KokrLnENy0u-tx3yQbwy%nMq^Y5;y1c5X=7NRg)%7de+E<=a
z)z*|gkvDX-*S0oSHC|f!#<ubs8=7lc*0hx`C@OEOSy|rDTwT7h%}eJT`98%2I`%Sw
zrmE@;DFj!<^0s(2ND6JW)yvzmtcdHI8|oTrYc9WTsaFZrEv>au%N1+d+FKi%m!DIg
zzABRQ(YmU+y`ibrOJH?%{I80J=2(4amj*Yglx2BaMQd%erM3N>DK<v!>gM)nYs>2F
zuFfTJ`L1ZIuWGHW2}&T7I!OgqH8w17o~rz^s<ztpw(Ksi8qsdMq>L*`*ZfVjP1Vuc
zD%z%+`85sA$p2o5H@9actn=S~TQu;h$x6!#M^<F{s;btSikgPDXjOZ4eU_aljWrS7
ztFCQpYp-vut*U9OiZ)E8I89Yz7OR6KCsCe`y5;+zOwy{gt*tGslh4qq_J+oW_S?#9
zZfmY+Z)_9W&=A<OgNs#DTUWKJv0d&1Elo`g?G;TeHMLW@X~gVH+p4H#V6w<YL-T6s
z;x!e~s@AHeTCsK&^;OL^jkT>)$y9x9RkXaOwo%flXsfPjtZJ=jYq;GgUs69#qk+p;
zHPlFr1vOTZxb8;ryFgP_dwo{&X)Z6yvZ_t0BC9({KxeFuuJY72=q8ZdMr_0rx1r|R
zHIvVSuW9iw719l>8Y|k`YZ_WATB7X@EzNDgjht20);6`Y-Zr_MVU*$ze=^=*tz1Y!
z8XJ}cT|I+jL(5bI-K|AN7E+0OlR~T&s#}`t8nPUquzFF`Hn+5jg{_d3+FM&1gWEG%
z%{Vdd#u2+^Oxc_`+ZaDq)YP`EY;TE9B|CoE>KYnrCuJVF@3glzw^g^dHU_m(aCP|C
zmrggS%X6LjiNN~E{bni^QCnXwT2g`0fb^5P7U{WF?G4r0CdIXpup~$giDg$W>C>p~
zsIK+QM|O#Dy}0kS9n!Q_4b9mW#>rtK<-Q{g+(cWNWxCUt%^2TFA{D9K_U7uw+N$PN
zQ&Ll}*F<Y&nlgn!fa@-9C{fcc1CoGALa?T~RN^`&ovvMSBW8W_Nwv0D%gm>tJyx8_
zPhow1kBt>$w;JQVpSe)0FoWBR68Uq<<uV1@hXb0aXsm0f_;D&p_!V5$x_tGN%~EQm
z)Yk7+ZfcwNWoFv4&yBN8@viK-9Lk$p+8gR_3!d*JYaJ&Mn{CFu5AsKKeU|-^6A_aV
z%ST+{4EIHrIl&aRDZ1AMT2tLNr2-|@isVHm^Lw2aNpml2cSTcll?=>lva@okfs*d1
z*{VLLq3c9k3{$C-*zIFgYwhX=_=mEyxSS7BwiU~&J6dJ-Hu;M1u3jzkX*b{t^cMyz
zYJ7N-7z|9Z5SR$m*4I?ES1rtL9N|h&f)%wL-t;$%`PuS@_WD)JWbn}Fx%j+Mm3X)0
zmY2=Q!Cl*p9O_$J)=aV0YU{;O9Ib6N=3ZRsD&OKb#)LR?o|Rljd+UPOU}@5#xTH+9
z(#u)XEPu8XJXNwv+R`LGiQ4p+HRKu_#H|w0s7bj^Gv617SG1ufaMF-TyhVnStJ(v{
z)=A>ZTd}5E9JN9Hz!LN;S!RIQ)w4et@D?AOr?^~HvLZfuL#Ldgc1tn5!B$0cOUyE4
zmyXg_->8I|8k$$iibriD)=k>VF)H-3T@{VutMuUJ_)WL5Ma)^Wwz|PHh%L>vs2S<&
zF$ccCLb9f+wK=vZ5O@lVVypN)D>|e>(q#Y^s4m)2TMIXB&<XK|G0up4rf#?#3m1u2
zLF)crhPZ2aBbhd-i~3Ny3y8K<uWD_rZLYp8_@vcUVrt+&PnUwUQ562|pz_PCw;5d_
z9fuiB(}E4lnkuq(bt#kFDvM}N`8=IVcU`aH8e6IY{qk&A{5DALCzvLQjy2palW|P7
z<ksypsW!ek=PR4!!P7#i?KT*PXv29@BY~&Os7B7ra7NrAnIRF}-_UZ_Y4O#K)Kk1Q
zBkwjT1&~ZhTQ$houUayPwJ1v<+EyQ}s$Pj(dg^KMMap=hu|r@c;wQ`Hy=4@an%|-0
zsYF{FR#&*?&xE^JXo}rH>sO;<vdCOr!!o%=$Cf+-({k&KF3~L3eOYV$qKIR5Wo$U$
zN}154L|eql0}~gxq!p~bGFq#HgFi`M{S2h5%f#AUYNnDKQjADr)oN&W78Tpj5>uuu
zP8Daws#aNXfu#`lrnrkdSA3@I#BO3yS!~bZO4YFOnNrMp9gOQ=-O@T_{v^)wwB`_s
z8Jkx~W=thQpn;UCd{uKzv$Uo=dJeEmY8uNxrYqpCs<JL|3XNHe!vgH3bYRJGg+wYe
zH`cDMjk&0^$g5ks&D1!khni?ZG)w)HrOZYw^!vIorTVV!=*UKE;KG&*WuaoRVN=k#
z2_qo2nf3CeYQ~PZ`zfsoroSWCMLi#Sb;h#BwAZiGOl^jB!pvojwnT9+$)fhqpts9K
zGp8vTbrB7jGP$N@%>@hnBBdJw`5G^-`FNyBrbH#971dbt&2)2aTa7jIpnigJZ>AJh
z+tv~{*4p+p*;KEj)G7*+wjoG0o13jHyWwggDkoE2Is1=0QLJUnzM95z#a2118q?@+
zBH!^LOL5xb#qV?tO-&Y#-#?|AynZb6iy%!*+&R_2@Z1dPd#A(JNl-_1prR)RO^6K3
zkfdmUL?O75shk`O7V-vu!lVdwRZR_zSl~@<szm+83-9-o<W$gutCma9Ll!B?Fs`O%
zWsu$`uGqf1Wfg|-R<2gIH)R|H$8%m&yKGfpgC(vS*OLWlFPy0O<u$PP>CA-;x5P?V
z;_(c{?$nu82n{Hn8JW=3)V5}K`ihoiu@i$cSd>K$6JxB#+T~T%GDO1!!4h26+K81p
zyV2rRoT)FM+-<kDVI4C=spB``y4IE^8AYbOdZI@n*~A??T?L6JOx9o0CX>(;Nk*p4
z8BS`AR@cZXYTC0BIr2Kal(fCJNmkQa#KnP{wuI#3&5h|hej<lX&AiE7P+k+cK)r}d
zs5U-qqRaCH!pm#YY%Hd0Xw0;AS=%n2d`c|coX4B(c=uM6X|m?u4R})RL~`M9o}s~s
zilgj!w|rUqwH2BLWXv9*7V+Fv$>Qzmm{-A0wMOQ=GCPgW1OrRg8rVCiL^Z1`G9{Nd
zdyQvOGfmm!>eY5zvp8gIb&a1Y8rE8ysb5K#Nn6|T+LM8On`dA$YKcE=^Bg-eGluWT
z4;V2WIuZ=FIv$ZLSx@g_h<gR%!3LCN?k(t3Nu4FDjvKQYlw_jM#A~5G>yfCm%v)F0
zw%!)hKVyD$>snF+@lGEL6V1*-#hcu#3^+b&YhpT*u0Am<iH8zlbSJCL<;!c^E9BVF
z+S1%q+uU9O(_YaM<UL95=ka;Gh+D;yWs=5oGwZEa^n{5E?1e4MR>YPR0?%k@MptgH
zTGnWKrV@)2>C9=BM3cJlMY^ht`50nRYe5`El6vN-yueJ0I}@6dDJefvE;ylOE8+$v
zQ(AKOmB>XIvBqNN0#lR*OiUS4&q|mx=}uT4XicjP$*0w1aZ(j5UfQ&riIVHJ@$K8R
z2&qGaEKbjSdE9c-)iikk8e7&hw3N4ZwEMxyskIm{(v7iaP|{vDQG;lX*mD5suI%|`
zmFiW*)@CW)OogXY6IL;ig)CgdItyZw&pWqb*{Zs_q?vT4j0CGxyv`EKgsxgMCYhvu
zna<9rhmwJqNeXI>I_VdItDx-UOu3cT$_+?{islN8n3$SnxZ9_*V}6QQ36cOXnVJQh
z>8c^|j7!G!(&|XORaP~xY+mD@_z0?)re*&9HRu#=M7^+0iQtq4AUC!P67>SKv$+Sv
z4Q9IXil;&<CN|Fux{m)yhSR@9hly7P?zU?(q@-@nu4>8~+M1RvyDgIr#5-H&tTeTC
zG(i`G3X@XbE+bZBqkPR7%Ex9&?h<l+D0aG$x$D<e8E*8kp+LOx%(`!*yqPDq(}|gC
z2>0Sx#C%L~q!QMgcW!w-me%77z2>!|bgjS>W8KKACe(ecnN-4R$0i(^QtL2NBbBD}
z()FE$?MV#YgDQ1ZJYXZWA`-cmJ9unyJt&bjdA815qEAhQa(z2xJ1C{5Wo{8NUBRT`
zm&tmVS&z6u(h1JGmdh1WCM$lyg7e+jAft0{j4X~9j3dme$1frWIy<PW@nO7VHs}mz
z6V_xt)$bFT(h?uE1TGpEm6T!={B$YN=!#-iybzM=w8aRru43J4YGV%pWOE&a#GY4t
z0o;U56|t40^w)#6^WulnrOKwzJjwI@8g=9v#+?_StfG8bBqD><fU~H!V`JHdwyO5_
z+X6==biUU*UTwiElsSFxd{@iWwIY(fe(4giEXj!2A6}=ca}x0Llx23j?8`F|vQ`MU
zS-RAdS~MObB~klXRVgWOU9_#$3x9Qnz%(2Dbb59I^fbB?NExdnJ#n6{tf)!lMPLs?
znt-05R1k?EcdytOuw25bn;Q_H4VO_mk+hZUt!iPK9ndmqax1C=pT(pu6O~7Y;4!FL
zo@vzS`s5m!S(`nI>d-s2Ji4k~;uZt*MH(Da`Rc|Nd7j!XM%G#In@v2SZW*gW)`cWf
z-lMr*jFwE?f-aYuJMV$qY|f|lk3}g2T_e2$c>e4P@##lpMiAITQ}Tz0u(QdX*FEc+
zs?MvZT3scMZMc;(+9XfNvv}E^S{J48&g^x+y|ul?imG(F=*&pPvWDfJJ8HQ%1y6S&
zs;5}V<(VwAyJ&&fGaItDvY@Eq-19G}kdO^|>P~7-{ttDB%{bCsIBnzB#hi;-pD%-k
zz&?iy80k?t5(-(}7LCOuW}SmN35SshBbMgU$<S5e)mz`vSmPQ$lSn*cu_~57n%(0p
z*<4DDj6A_vC-yb%Ww`#=)HI0e(lV*ZrrXa@V{LO*4ZH@6Uzw{YX6M#O)LO8eqZ*A@
z4=SdiI{x%-hMI|s;ND~1dT@~xdkvE*l^SS7P@^soJzX}yWi=8{U<OsSJH@TNr%NWa
z0;Dw2Wvwd%GnOPF9j3fOmI1^umz@AYbG(~%byd4;2NGnglP==Pcna%nA(Fj}uUWAI
zrPbWjEBR7h_st~ab;Jso23YJ^iPDXvWz_5L0p8XXne~?xQe1%9R8>slTiWWpr;4+$
zCp?pueRH7A>*UU!)x?Jif$klYC#Y)5{idy<3A5k~YU?!sKiZw){6vnjF0*%um|A$Z
zra&u2%0x1CP2L_*8S)ityvDZL+ARB?>lXH~hqC0|-^#s#pX>t@*cK$=6{4<II(Tb~
zESYB`61#|0a&1*p_UBjBHMV7KLt?vi$sD8uo4y2$_o)=Inr&!-$<5~cxQ4{06xrPg
zsI~FzOP!39R#&`L_8i0L#TvL!He)qcfvA^ka+zowHy=rvl}P}X7eFRESE=v=H>OMP
zQEG3juWGALj*##rTztPwR6BxJW)p6==62kmR&f+eP)gn-KCTRDPFkrV?Sf9R(~({X
z7n)Q_vkH6l(~F;y6cQj0Xo@K^a@QEGPOc3<IaguvWLGuGbB}53Bi(gn)YaZ7TSvj!
zWnA5hkImu~yKbbhGS{(pO5o#IN%|b?sM&VYnEux#25c$iO<zG(Z4wC*GzLn_j~jgW
zj)IgcxVDPcE^DvFel~$;$TJYFO&2W8;*|7tp1v%UT&iy+rn#aI@h63o^(}FJqW9HA
z#hS=^2_>7NmhcR#Rs585R(tDZvIR_4H8vq@kq2hYs%e)9zo5uV*;gPTn=aD`Jgi>1
z-~u`=B}4JrlWhW(VM~`_jXc=hQtd6G1~zAMg4s7&Q#CI`rQ}o0O#H#6z$?d3$^Mef
z?a5JvX)f9nuYcpB-YMxX>N-KZPCC3*<YZ+_b4_o2WVM;}80@Q=bWOjx61S>`CJ9lt
z((#*0Zcr5*w3sGStE9K2ODmp6l8Kj7TbIeW#k@E)PVVsO(sb3<9Cwr^v^-75T<EXS
zLf$D!wdJRiF8ft=GVGTpw5+U25$kH@b}aLAug|-gp^=M@Ot-b>cJGv=jQY(=@#oxZ
z>GGJaOy1pZQYR;6!>q4{=((|hUb^)Cwrp?AKHS60Z7fZB@H#kF#U<|7h{RiF>|X6b
zqZOB$T-{41eGMees%@-`T}&>Y5;U3ib~(ujM$GRUID}0<)r)O}=Xs2!Ju+m?+cG1*
zUYo`EKR%w9gS|vRg^yhU;f>gzGO@=`hK$9pg!#0w6hYUCk9q1ESG8s3yN_SMcTr^N
z!jsF$I#l^v<<9;8**gn3E2_WY&m}|}=?3ZUlm=-PkcNe26Bf4Epu4*pK}u3Z5Cs%O
zFhD|5L_nn!1cL_2_xrnZ=H9u>jk!Gk_j%sn?B}~D=5)>6lb(M8Nx^uXST)7lo<EM0
z0pvG}d}UZF3uE}8zs2zbvCn9OrLiJ=wCwAYBuWe#b6RS=jFDQ8T3~#*V>HX?7M<Oh
z`a#t{E;67$yFBFR5c{}=p)vI(PDjq~F*>C9pl}Ogmuk&Jfc=E2{t=O(A)F%Xy0F&K
zxfxBHpEdT+V9&8;ajSj4!)+{0Npt<>=S+yniV?cS#!55d00PVPgO$W#tTwYarYJRp
z)z6$hr;cy+*-Gto(EALSsj@o?BiLK>F*(rJjs^6OV08e6pAZwpDYFq?*I}7l>wN;B
zCeaDutgz)QY&Df;CI9pm5Zp5^Ho<#KCy%0nJWc<&#76%WXRnEl!$^GQu*nf8$FM!9
zr<K^NjI)o8%eRRiZgi&{@*Qr^GK&GK{+A&aYt_?~y;kC8x9(i8W}*J89FUdueG}Oo
zD`%;jPw=yt@sfiQu9ZltAR|Ng(V+Ja`hhb(g0iRWnG=hx1ZXS@3@{c-S<e?$%89YE
z2g*uV&ivF>_I+x8IOM06)k<%4i2?dS^MUGk31g*?m2pbW1eRlRB3O;$d92*jI92NU
zGs~(gt)$FeaIATV3TFD(->m0%gXhH$rkFW0L;o7Izmxr_Tq<F7>T>Rs9}XSiN-icj
z8pcP3R$<cg^zftu(hnB1=FrrD{Bst;k)yJk*uuFCE;+0cDBmEC7mUBlEgab-zUVpN
zuNTgI>x<IAL@2k8=qIr1Nq=ejQ8OhC(TSG&I{TsM@=u+tZY2~)mC}FAI<v=l=#Y;J
z;*!bs)gUGlD^W1AI8qI!TWGcRlyW2=zeN2ALE>efUAGW|BVTASe0n8DhRM{0RAfu<
z4|@dV1Q4k-_I212rpJ$08Jku^5$<wZe!S?%Rk?fW(rkDyve1{WGy7R6oJ1I{4*c=q
zQWb(rpQJZ*kCDblnQVw;<#9|*9}YM6`P0^(EAsX0N1?g&SeEi$dU3|g0|q3-_+>vZ
zJT@VQ-qA|rj4)`@Ou$+Db?B&4?he57Q9KT}<ai+avm-(xSkGml9vcyj3MQ(Sev}$6
z`g4s?RIrsWjJjj>qt=la99pZL4j1~0D`QV)zo57XnSiuZ%%)x`J|J9vPB}X}YXxZJ
zOh~w#3gJiQGh`xpX{o?mqG|tv_cxmMR_1c1ypPIdccAZ&arRX{+!%Qw8=5WtmT|;O
zo!sb84n_s@L(^LQb#yY8(_%`$-*F15T*)6d{rNPt*sAQY(uaFQ8Q6<X)}Nq4Dps=`
zmQkAW<ArRtR8f<}&!4D8#M8N0tTjf|>_Z^Yfr$y>HT(%Gq@Q0cmE!a}(}HBBsq_Zg
zlYgH4!}W7oXYQo)eTIbNauWOL0FD#W8UEyBz}uB%uKOa50UY@Zu>bne$4`A-@Mg&q
ztM@zk;hD9|m0UeEpJm7?3VH&c{|t7A7pf!rKj!%K|Io?jc*CrQeH~Z1aw@kR`zIVG
z-q#^JtnoqQSW9a*G}f~^%$$qI%tjto3puRdy)n#hy5W#x9;17PM3&PB$;yTBvhEkb
z@737QV2!&@?V<_)uW(sneraq7X?T@T-$$_v^95iQ_0VtP*$L#5$dh>(i9F6^@1aS3
zis#%TsXcXwbSAag=NIZ1Iq)I}UgW@w9C(ofFLK~T4!p>L7dh}E2VUgBiyZiG&ViE2
z3Kq;tm~Zj3E)-(ZXj*zLlXih0joJCDqczYPX)U3h)=dl2LbNcgrxv00(W0~%t*;iZ
zC2IY(f!bhgs5V?1sg2ggYU8zu{8XH(P1j~>v$ciVVr_}`uC`oTslBJI(bj1jv=6k6
z+9vH|?GtUQwq4t)?b3E@UuoZHd$sSh1KJ_&h;~dnp{3T+YA3Z*+G*{q_KS8-yQKZD
zUD2*;e`<eg*R`A4ZSAghUwfcE(w^{JHkmDj?IqjGwlubMwhXpRw#>Gyw(Pc?w%oRS
zw*0n&wnDZdwqmvtwo<k-wsN)#wo0}twraK-w%2U6ZFOz+Z4GU&+nU(oY%OeW*xs_W
zw!Lj@XX{|=Wb0xJuywcfum#&fZQ-_Fw%)c#TeL0KmSF2=8(<q`8)6$~8(|w|8)F-1
zn_!z{n_`=0n_-(}n`4`2TVPvEo{AWQ-1z;H_iVFD*o{PAq{X>Rx3@1#lwZ)IkNi9H
z#dV=eUz1<wqOY+2_V6bY3r$I(^b1ywomjBage@tRzQ@C1Keh>O_}5EHe}6}%vuk?H
z2~MT-e*~}1-{GC+p)V`_h-3p+B&+mSgVg9neA@5)guo%c*PzJl;eEDdORJc%lfOx8
zf2wIybJiPI_xz#e>D2T5@AX>NB6*%$>6QMITkWC_j(TTr2Bn`>rs?`#M>hPKQR!D)
znb5rUH^YC-r1Tqi3}2nRbi-CML}1U4ldtA#ko{Kn%*ONDbHC~|WMauIO20S72ZN7x
zc*9;l#s2BTU6x0^yY+B3_5AaSdA7&CQguakrQiAXTcbuU*i<Qp(r-IGqwS#_U$x4q
z^xt-9wSGjVm4Ug?i>NcbYlFQ5V~Wb~i1<ILR<Hd-=Vpw}qx5t8O_+W>+u6H$mA+@D
z`CVJK{rly7O8;3*)jqQd9;=&Q=_>{7-#okZl^g|>{^-$~mku|-aipNqfBGae&Bxd7
zPI^`8t8A=R>*m#*nF}d>`$a+du4h;`udvd$np8hu?)3$_6jAzpEvvt>Z^gI8iYmRW
z`1pTEywPT5F{K~geb1e7w<|0zuJlDyRjB)Uwz=UY(2JN7F!kcO3-{BML@nuEIlaf|
z$u)<?ms0wmgFg=K*<#6^(n_BYHZWx0!_QZgK`-LBWb5ZOFL!NSS=8cw{k2zSq{=ic
zTREj)ocfL1bIO%_v%FYF%*rxw*GC`T&0PVt*uVeE^1S1UuF)zg{h3#nRBbzb=AV_6
zKEt(DU3cHlJh`&c4>`Co@zWa}Pgg-NA}ZrAe~j+cYkpN-tEIlwrSHD`<2qJDFaFOd
z^Ja>SB|6NjuJq}*PF|F(T<a$_ls?agjkgxrlB#4)rC%1=a&z;<_Ss%TFQRvg=|e{q
zo4dXiYVq&fqk{u>|2lMVZTnMAJ5ypuzN3LBs?<@>TVC5z==kWg1L`XMtsCR7SKGRK
zb3LUmk-byF*YkY%xW3Z=-EV8VO0z1KZ=m!Cs$KiywcrMo8!G*fey@)iKC1YTMoNET
zX3P51vuqgoy3(gRetv)1y&HoXEB%@y(>kn4_jX4a)|2>-KlG?<g<M}9YpV3W<=y!E
z-RvViX{PkeJLj&Sx?HBl&6R$}o+ho<<omc~3-ltkPD_2Y-ipZ!TcQ^Kw(tJ&X~|^u
zN55fzN*5bGw9-%WYJC5udS2}AU+2eNjXd_2(&sMv-nyGJN<3+$>`&bNcD~dXB9gaO
z&o{jv+T`r<sgv3${epob*XOFU`Q5jb{)3C%OYG=$bX!}cue|&12k$*DwxFHTPe^lN
z@!E%bN3>V^%WXG5DAjvKnGQ-{VspW_MutXi?TB8)gEh4W2Q&<7+ez1IpN;-5U`^<v
z3Z2nQ`q~tFGOt8XX!kBkUuewc^P!L5`M0amFRu7Oz3kU-WD8LG2BT6IPjhi|iEc`t
zw?_QS7ebzH=&tmu<5HiTHTs>}flB{faJOrn6E7s|q4c$?RoitdL&T{d^dinJnzJQh
z)3y@9s3ktDb2Pu+Vrc2XAxeKM$DmoMCVw6rs`TduPfXqKLi3GbN?-ciz9FmT*}e=%
zFXHm;vZFSAKV@J~)Z*W_{fo>?-}3Exy_9}QtxP%YmR-6&Lg`Omdj0*`eYB^&m44!%
z>4KkrSbt0(^dfq%yK-~X_CYlwb*+|t)u8QB-P1RSLNETeypy%{s+~<<iB|e48FQcO
zw0?4{7^R=xaR1N+SNA7pn#XQG$H*G1m-Ib+qOa25k3022t~2LK#3_B^{cfc{`7&-x
zywYbl@=yOSzW*arg3_-Y9eAj1r8QX+m45Gzulujev%Nq+rO&$i-|lC|*SpwX=?8Zl
z7xlQ*y!``|eplmhJNBnsntGtp$Mk63F0nwReS?%fe8Rf5OP<~<KUnFj|2g7(jj#{j
z8=~}0j%@wy(;+K*4psVo54K&O`}E45VM<@?QSoJi8_di!T<NFVmZ$u2Xu`n}=tZP&
zyEJ6l;F_~XqL%!-5IV2f+>i4#8Kv~2qu+>b_Vu1@qs21fTx{a9TfZ+JHwLxXuX%dj
zjUzkvJRNI)s%c$@7MR~;b>gmZ>iN%0Pb5n>wZ<#smA=CVXX-VpHF50(r60R;?4#WE
z!VgST`uR(a=f0o(+xC-`enx@11<r)!?J`;EH;owjYL$|0yH8R2@VZ0V-D^-Z_f(}X
zv*G8RLAS=-oTl_A3Sa&B_`@|p)0KYo`JAo4dw=5P8A=~;=dUlv_xozeOr^iJpmhGK
zjhpnIrS!e>?J78VVetdAmA+tsohLfYxP5jGdJ#ju-7@@qoo$ci>RPS+mz{Q<tdQx{
zJoJ)3BPW#ntiey)a?V%!sq-TbTyHaA+XAJpw*5}vpHr3}U#RqlyXE_*LZ5GHE>ilP
z<4=5<ETP(x#Y$iCX3cE(+Sl9mj?xFTTw3hvh+DUpDE)G+O#POF4s=?o^hd*Qj13*o
z{OY?(|3<efp<{kpGkBTOKl<X~u5_JmWLU2B8JqmRtMZf;5i69wOQ`}^qu%|y?MkI@
zk?n_SKLzXvU#0ZRQbkuRo4@z+_YC`Er{=C#HsJnhrB6BTUiv}}`^xL$g?NzzFLK~T
z4*1LgWBo-Md8xX+ouRS1II}_P=J5d?^&`atDpqjZqsj6*{aPKjuHCOnkky&)4s><v
zg@p*%kEHbNILW=f#sM?xlGf*Tua=XrnA5Enu32ELJ<+p3=~%C(uR`_Yhf5xKNQUD$
ze+#iNmWSA5VcaC^)}2ep?u%dDdiq?>!}_t`JuXHreRwYS`ife8gW7X>;5>WYt#kK<
zCkuyIebh7FaY=iK`{=tmcggh-V?T&2>#`rvWF-sSm;LkRo;re8zcET3OyEa01Shf+
zF<?Mcf*fHR5|t3B?;qyeYVK&JOgQ5-v|yvsr3*?D;|rFMrP3@3k1J?Y_mb{&&85yI
zNwIx>r=|2h>yTJ_a_L%7MkAGSHq>DQxE)Y76-L`{^t6yo=Hj-Wa^a^NBbS_q==<qG
zSTFltB@gw=HOa1#6?cK*F>xH4%LTHD?4$JCleh%6Jl}1kU5eO!w<0~F9M<60y=&x+
zGE(hQU+vbD{TcTA&h0A=E%;*20_WSwv8&lyRLq{ZIpgiQqhVAAPqFZsq4qZD$+c^C
zn$y7Yas4VVKVmM$z=}bdYM_M5+bvw*?CaJKUom&wPUqIOIp#?&RkerBu~-oa@$M^;
zuaF(r1NjWuQC(c`BX_rL!L47uVj`yn>lYY2m-85P`@wTLrqh${IQk(GZhi1l2Kr4^
z&zJo!H=4N(*jKi>T<YM~2QN{Vw-uWWpD*sl%@{rdb=DmD7Sns|DuHa&lD*|VIzLZ0
zPRk9*egv$)#-)sncex`{|EV{+k<FfB%z^0cW9+MhRl`vCcKA$mk{)7Uzaab3Yd+mM
zGQ@s<o+>3@#Usa&CkfDT>8;NYlQ=Z4DEHT0a72Rpj5SKcO(Y#}JilE!uCewvnij7y
zPns$0BZ!KSYrXspPtIoLY$V_ATnnCs-EteD#jg_MHEMbtI<nUDH;Jzr?{XKC&vZNE
zFR?H_B8<(Bt{1<1+_q@(5<KHhOLzOAq;oTVZyT|o+^kx4b5WDW*y=wC)k&7BW3U{K
z{cKSGBF5n%IPeu6cR#h<#Y&1vori5d(bJEUZ0%cF95u{*2#?zXh>e>i^li-kq*?!_
z^2dd>8xKrrH@@iY$Bg)KVu*f#htKnYOvi6?TB=-LX>5>mZXI-P=QhgLsJM=?FRy3y
z8RzgkdoZdee@xZLjTPe)%u8%69L{FpoWE!;uF}8u+|?ULk0Na{j*i<~tUVnt=cDEu
zrEm49P_>=bzjH6_yYYN(`jn1K_ufN&cT;I8A&W;5JBrz{ht*l@eB_b4&4fnP2vcLW
zj*5z3jMKVa%<ay9dpB)d0qD+xDYbqc_~PyjAQv_JdFh0{zgL|p=lKPKHGQ<lM<Vq8
z!p9MHNfXTtiJYfoe}%jAUQ%lHZU{Mf%JLD<dSp!};<^jn6j^dtj@Os{XwQ4ty2lzN
z-;L&*;@ou=zV16TMb*&|-2G(snM~8^Qm%)ixpV2ZBGNkC-6#4?L$Y$xn<FiRF0Ibx
zR8b7{<67NC&6FW-4@L4^8g8$2^AUu84!R%L12_^!BCH*$kmNlp$5@%)wdM<=eMa^<
z4?~ik)$-P9^&$~BR*yYVPW(S~!<?JEZaJLLaq@`AayFfM;?WL;qh@3bD~^zypCsxa
zTpyWk@8V4dYZ@Lt+bpQn7LMF@ymHMWv+m;HwvGC@4ae-p;*~I}L$!R|rru(lCz891
zx~UDTsu3CD$B9nnR2b!EzfQ#W=Z9n8zt_Vy+y>y+RZd1Yew;9&XPiu*s4Evd)+Dl2
z`b@&$QeHLa=qZ~`y$kmBb3rX$dS?G^<=@qSdS&5dYVjrum1eK^s!3&eCKdJ`%gcdp
zQi9>J_WLQ_e*l@Ppgo=Xd<fq|QF3v!?~3G-Id*5hZl@F%o~|=Y8XK4E$t(<D7(WKY
zAA5%s850yL_b;$c(zF4-R~RQpc^+0Vk9WBqBVqT`+6fT8#%9cyD7sCVPY+C&Dn6G7
zE*CDk^}%yS{HM>;uzD1ROQs~5wKc|!Sll4rveaGw6U8*Wegq>m#;t3Y2y}dQi3?$K
z^kz@FhV8lB%OF%jyxd*n+j)}odr!7Y#FMx*a!x<mg1fb>gzhHs^v2#s*S$tTX5cJ^
zn<Vazo5y|Um-`s&{gsCldu{=yu0XH6&vW#OxxZ55%mJYTqXW68!#=p=sTO*U7E39D
zI5Aj`mX;T&^Z0SM+2h$CQ}RM$69Ypd;^qE6KRt0o=9#lz)ftNVX>fk}YLA+p=jt{S
z|6`^`L?XFjGLQ?*B7@=r<0A&?C+GPY9Y-RSLO*hs;R=4Q2kMhJ`iV~#{57Tl<hAV_
zJkwvqZk>B=QZd}s5JwdVi;9VpyB(g}2R$u(H-$$$N4IKJY$XS(kC^9q|C;hTIwp>$
z&oUb>FHje4xlNzvD(>)1&YpbkhT`zWWq9y;qhcPy_tOufFOkJZQ9%*<A;5n6k#r@7
zeJ+JrGdX|Df3Ff)4-^&@&9LutxVN`*mV(K3pni8eEGV*{g{-^wKk`PEHTq&s*`=%U
zHwz43RH0Jw6G%;je6ByQSIW!h$xtIUiP9(h7ozfP*ZDlLaWor!L81Aaaz87Y!zcUv
zkK-VJKYek0&^nfau?+7ys;wh7j9oo<pYm*E;;qNVc!$VuAjes3|AFJ&SlX4y2OdWP
zTdBO}Sm+<7>Zmj{A-ya%CbK7wr2NN@m6NMho+l<rlk<G(aq&eyyt(y7uBf(9Z_U|~
z)Ej<1{3pCIPPp?kHhQPc9Z}4Y>XRORdO#`n4h|U*$6_1*>zO@te(gI}TJss@Z+;R1
zdZZZraAu#8PqN5_gJ?tP0DOm;#NB{|xQg<<9uw`iQwfq`7x(V0d>!_;FG+BlQg6<U
z`=$MMX#CdfZy$#9^i}Hm)n=~n6i`?%25^}C@$y;i5_LDf`((T@F+mn%xJ`i9;JKH@
zzE(IeI!0eXVSi6}8hA7>&`^VG-0~V98y3P91JrS2bki8Xb<D%|58}=#`!I$_EAsP)
zD-PoA_jb99fN21iq<XTUHnq5$mUH|F@#5SlQ7_(bh&dj(3xHY>k{A~k79BFsv!#B<
zwi9<gPzFq}dQP2we~{<r;fxXbTs|pNn2x+~UAXIJI^O>}6~{@>M!m9EC!@^6+)U3)
zhMPvcE0cJS)_G%-#lCGAOTN8%q{eohwc@;`iYi8ktV)XDMHE8FvRlWS1G%v?D5Osn
zlQl<6P@cKWi8}Y-c&g3%1fIK4)g4sI+wh2Bx)6QwibucHPiS?ZvO7<mY1enONXvG6
z#i_g0I7j=Q%_G;?(m*1E`l(3{UzY7Ro647fy9m4b%P*wFIF>g`H^onBemA;Y`RcCv
zNdfC$?XfXj?rJY;uOWqax+_Y$C;bBk_rA)&F^plsqJHh5@6^kU6QQvYu@>`HuAGp$
zUJGe9rt@QDa6zwRzDiAht$4EQtY_rEF=pv5E0WHk=r5h{So>mB=ljM}$?D}{Ife3T
z(07z$V`8P1d#xpUj!E_oBBy-&Nkom2c3(Mbzv9}FBzG?nN8c{Xj9lNko-&Gv28PJb
zO>=91#xjK!-%pkudyFGCxKP7~jp(q1{#LRNpW>(hZhbS=py+6^;;#0Xz8C_X6Db}e
zj~B$ByC3ylMEWz|C8zrQ8g65$x+m5Hd3&tFCAIceLy36`*4f=9d2Lqm;lJIwbP(}W
zU5}|!-jfL|kd~TYy0#WWVig_~6%lE^TGv@eoF$^t<EW#qzDV2QW@Ae}v2KG4kv-KY
zXNU>?<eCk4_0nmlPePQ>?*bKb`&9~_%E0NPD*B3U19s-6zDwL!t<&EKo&t3iywuR%
zNpDSdmV&EA=bJ5(J8?sJG0LY5@pad2@Z*b7C%1`lrdjGnSh!nD&Y<nJEq-8pLReHn
z3|G*^^pud@I&%7~@?Mu*!!UnD+5L9;iqdn#eG71UZ~v6BcZcq~IJY+K9VlbA-fNc0
z>%c^h+2af#G%kWFo%GwvS%yxV@uB?!ec5(qyHt(%fzf<=d&q28t61lzWVdNk7WqVo
z_x`=D3XLD_vN$1(t6<$1v+_`VKgjYozR|n|ZL~zLH&h=f7HnJpJRzQa6T{*L`l>am
ziMzMv%uZD)V?y}->Z`^(T}gS_t2XPU`h<o0$UBuIGV+a0YahgF^994V<evXO<ig{4
zV^|$HHjisK8my#DAK7r%<6w>N6Qbt%VFho+?${ywZ0G81LvgVop&?;jD;ou&uT6Cq
z4{}=H2>fgyswjh)2kED;U-#ZoxNPiv);pItdrNnGSX@7fRtl9`@yzAr=Fc8Ak>=Jn
zm+;6Vx0X~IdpSNO-Q|(K+tr(UMg$`(`L5yihUBe7SJ83oP<}QSl?}B)k~q1Ga1iSW
zjLPRJ3+)rd-qOUln{*7G+)G+yddhJ=iO0B-8Z{i@%P)JJWS&@`y!PlL*=_CfmDVBq
zq2k=8)1`t$hgz@{B<~-$eyL)S@Z!C`BXk>H+iOS12dc*maE^(3v!ZV;cUM82zoBF*
z-2OpGvV7X~mUNd5j2>g9>aCCZ;8-Z+(H|M)>u;f!8@1H8kH*$+uR%up5hV4F`Ysn3
zyX!WMmaew&dkocOue(QEk{$7;xIJspS=pV#a?jdQu@djtE#|WiF>+V>06vl&RS5U}
zIWDGG01Cc!-G7pr!iqJ8<uOuv1#_F3&cx~OAh(uG;SI17o@9bod(Kd4)cT0H$H<Fk
zgDm<cjYD5o=&nJM)xnJAc}=1eu{R5ptbCnG^^A>`aS`zjo!fV<`pWWR!%+>aTV?El
zxmYiLl1%+qlK<azGC=Rx(k<%(j8buYx2g2I{LZ2blYB^7u<juNrg1%exp=|=xjR??
z*t8lO{I+T}={wF>%w1o0zHA$BJx>)RoOi6bKKk-cZz}$mYZzZ?-tL2!4?|;rm6w7s
zEzCD;2Smh21qToGa@V~1qti%VpyAv@VB#i`pR4j=;VJK;f{i&4cQ#D*$i8@A7VUfS
zOl|3LADTPAxI{9-Q`1jsUmu&cZ%+tun;dcAE^o;t?)vsP@hZ7wpVxMm0WR4tQ^1}q
z*$3ggJU6;1!=8tpm7=xai9QeSE-I!>(;GfLxufA*a=_tI2?+x|=9Vb{M~z_laU}B$
z@|N`xgx!fT$q*lBUwvY!k1_9nu;#$D<H2y?90F3WVwYVFKBBJwKnq|YP;`W>zmb03
zofDTD<2VaJ#=Pa%ikB=hRb2)Y7$#4UaRpDoB&qC<iDd@9jOpG$efzQV<N+^tE1P5O
zSZ(1sd2EXEk`lFy!IWeA9Gj=Km;-n8ZMy3~#yDdm>2xhrF1^AtsAlOVdV5t2j|!?B
z7}PI_F&{3kW`%{jBqy!%_CCv}RcGo$;$!s%wpKh3XBDf@f>#-AYE9m+5VaDp%;?5N
zhRe!*ch=2i)IT(W%IvK!n<E$=)+;75)L8xE(Q{*wkh{Q5C7`kuiDszQa=UXP@nwiy
zj#=~+QNxNcZQ;(FXG7L|FA3jRg=fv3bR6FL4KE=X7rgom$iC~J9mBzi;a)qAXBud1
za9kh%TttTiC9wI&Q<Hu+HTE2f9q5-EM_%jkb6a<w4awok-tK%kvNt08PFQKzUItU+
zgN&ZSe#VpK{?DFpUhCGgN*0@1&s{0>a89Q2{Dt#u77-^uLXb&rS$pBV7k3FoA{8QA
zRD&W}xaQ$iX>y_W-I4KOVV3G)(w@)$A>pHWnB0U%an`E)e$EspyMypB+EZK%^G;Th
zVIM!_;El+5i%n2ZcSMZ5zpVveFAV)F#7p;=G#PrE;4R_d7HBJZXU_`bo8*~qDkhTc
zhuCp;QH<+AwDC$;M`yX7Tfs>_y@KL<xlTwrKh&H<92`+VSDt7d%5iw?Jbxf;0Absg
zI2sXjW2sM)8G27vy!%6z$ruLdjZU(v#o?c_;_@?Jb{M<)VeL#pWUM;i)?*5kw~0~l
z?EQ1+nY(a#yC+1(1|`Uthew~I6YR@hELicLH*%hY$AWMlyP$ZcUF22mF><kC!3kk9
z#^=!nYtrJPs#URI#eMYM$IRrNvtk;*AoNN=)~fA=u2tV@-&v7EW0^-~Y}Vwhqry0A
z!83CZ&)Dh5dOF@%VSzy*GA|m#5@)Yjli=m>E&DOjMz*?(v`o~7^r=|QTM#PuqS>`%
zAs1No9~0t!*v7~OR}ZZhS(M9Mn<L}gm##iDX{6m@IY}G_*hhX`ll6>Us$W#7z4{T<
zGeeoCE}3_!yi)1K9X};KMnHM$l6pr8IXm5mC>H%#DjmAoK=bsEBN^`Uhl(8+%+VBH
zy_OQ^)#5GmX!Ud4YYk1h?8Xr@qcEZq>{eXz!ePl>^n=1VES?psUZa*^Ki<y8Q%44y
z)>bM1qh&(Doqz7aw|BaJS$2tr*R(~%R?_Q{JO7<I7U?pt=+#GiY;`}`wZIolxc6Sl
zkt3{g@!2#IJiR2HQPsV1p94-?VUgi_U<7ZWk&zzn12%5krR7gu`#vImvIp9i**bUe
zS&N)}>3bPVa*3Kua0T?GpZENsX#Yj)ZDPa4Lwg_O__1X9*R1h-qrase9QORN&+p1{
zbdj7!#U>OP5U}>OYyU+XAMW@?Yjl(D8Yp!;J}BI4PsInD%QuG88}&ZN!ZVHPSxa$|
z3^bcN0k>9+wnqE(Q5)=;L<Nf051R2|+xU?|uWa#GhVCNV{)5a~zN?e(g1yx?m&zms
z#qJUIrKwpaABj+BSoM!!Xr6B)4qWCWiU_Y$AkT!ycXf0^ILkE>qZ8C%r<K&{RnmUe
zqW7jm5~6}U?MHBljp?93`_&khe(~B5p40PzgJi<($&lsb796Vr<?GK{m9Zz;xgNkm
z2&#PKWWBzLtep>!2n#iDytY=nks*9^syB+Ybm=)MFKvmg6*nrTe8>5j^`uRAEB8nQ
z`4N;Vv&2{e)TdN^<c84`1nB1l1*)}t`a8o)!1nTE`XDMeW`Gs@Do<#Sa@Bwz1)v=2
z62C#bPe7<~L`U-U2?u*`{~TdD>x#ak)<>qQs8Wi0STc-j$)U?!iSCP~ITBNgck#l}
zbNTCwGX;H72D+Y_ZY}kWuoGg8uGC8Xu%F8y|J2z!R@|uAO46efEwxNXz0kj+o!Mjg
zFk+W{wolfWO#Fy+&qy_RWTEG?=M5KS@Cj@s1V<vNh`js~Be|c7Zkd(6{&XoWE!9#j
zwntMonMu{LFK6?VHu);lj|F=6>&bN(Ba)R7F)@AYXK(wcfA-+R<%glCU`@?MIuZtV
z0tO^l>t_x7f#I<UF|=-f!k{5AsOn{^(-bdNr7a)hYQ&2zo-6?MCst9x#LLnLv!gx{
zIkmRiM^QLj=rf1LiSzw};v!^L(^54wHLLi5aQTRHwpMF->EeU^`@~-#oVm*)e->?6
z$zOXl)Yn#eZv>`NH^PxsT5^z_g$nGb?Un;EMa)V7Mx5+tpN3Sf<d2*Fd>B})j`mpT
zzs5uv*o)TgPf#Hht62`qnIwvnAG-d86A`a=QClb*BOLpWk7!mDh1c*WsE~f1e+0Ox
zG?b0sIly%?`d3?t6s{Mio@=7(e@&xl@x?W*N)Ann;u`r!RW+>>*V$*zplNHl7X46K
zP5Z2_rXA0$X&boq{IAxU_A_z=t~?*dHSbRwXxgoMx?drMUBhsvs}kyJTE4la?Q%78
z(S@hhwL6pR@@K?*GjS9#J)5R2m#g3rRg^61$%OF*jIJg+T~y*|RYP<j-oxskOQvb-
zD`;AU0-Clbo$*wc@2Gf=BHYbIb+frGop#QX*42eT{88d~PF<0wieciEf2^;oR}!bP
zU7hB>RFlc?bJaC%J7v<Pyru=EB&{_`Ux20+;adB09dsW$zU1`jAM(WztL3VB3u4-9
zn%1+nroG>eyuf|&*EQ_{={=fD(<YSDwE7<W`6W#Ed>!?mZWiL%R@WC$^(zZ;UjB-v
z+3<5rX=g+}q0Vh=p=kw(cM<Y;StCuWl^Z*h(^JYt%cN<m;;CCDoo<HJ*VVJSIn6{B
zNco9K9j9q0LBwa|Q7Q5$M_ST?Um{Ys*Jb%%HlwDkD5Gh=lg^%`-7M-!_=tZ4DSO&Q
z>$i1%(*J9DK8oj`RMxZ(<iqj2nifL*+hW#+{7BVQ)7Id&a}iCOSxnR7!gU{JRMq87
zwKT0A@tfV#>GM<47SmYMPN(E3VDcwZc1_z?P}BNkrG26=LVFD$-eYNhHOZeIe$=H*
z_4IH)#y=6wRKD2Nl>N+#<VPw^OGBPyr*3bFv|D@TUli#T5!Q<OL7XzEI;fj!T4ao&
z(q$E_wz;6w{50vjoI=<4ucB#{OF5qzsshx%y2(j%eN8)+-Y|8Q&yueq#t?@iJv8kl
z<)__{f9<Gue^3uZ^dntKMLO!HAsW%otszZj(VNKM%A;vN5tlQj{94$Z@}|E`|Ei|7
zpp3G1qAaL$Bk4CwyrF5ysRutqn0?Z;b+ls<Pogy~OASqHiQTN^LpS=3)6|o<nrT|4
ze419cHT9M-6AEItEd6nFyEFU0Rpdh>>Y0e))YFP8zCG&bX2$<&^xYY$BO(eH)U=C9
z%EbP_^lv)pFhu>{x~eYeTLyhq9zCUA{y=?eS&8=pb>J83ccnI(_BnYoCJS+)9`6e>
zd?9VBKNOQ7>insA{n;&39w%3If0)XfsLW3HqH6vYWmt`TreC^`+^!FKMcT~b2lBrL
zbu|I=bf$jlHQG!l{YSwbv{CYT2zfrJqo&QHT=tST!_(2eJ84?4E}B-AI=F^3)X$}9
ziKJ^lS?Y0qJ(QF@Z%+6kQc=dWF~3A#^<HXCoBtARow~5RJaMDk?$RC-(C4N+R*_f7
zD9`ff_warSd{fiDqdv`OOL?d~)_v9g&#Y_KIn`J2+Yr5)7%KPj=fvF*7wOk35@v4V
zWQank43(z6)}A=mB45bAB84^WQ|ic1l#?NTqdtC)`$F_(OVZ#E>77V<zeQbnuQ~4?
z>O%qQ?K$#vP66DKmkY_O{ypfM2>WC(-wNc<J^Gdf#A|9pO)CcbY?_vrw5BDmHOhM&
z@he36*P*@?ZiE?r-NKLR#7D$&%4R<G>Q}-WP8io{Ta}X36Wu1?D1<3u5B^-kjfnD6
zmVuhql{EA&s+)aI+v`s|io#AC)jw<^KSX39?rm!j*Dzh5^#5Y=WpJ!+I+FCyuI#i?
zg>uha#;Lz*Qaep`RhTO8Mg{q1F_r5Y!v2SH5pkP*UP!)(_%ILksg<sdpk3T1+(zYe
z{qZ8Yob>;Ztga?O)Nv7c!ZmFY{;eRKqU6CX>S$<${><Zl(!J{q>IC_Dn6@aQZzTO6
z?t?n$dij5YJh(#sf8En*c8~fmVl45mN*gf5u-v+;Z${qN_@A3{N+gW6_&2u%b;Cy4
z#p`xTR?y|N^hsuMk22j~NjEu4n$D26H;b8VP}a2Hk4m|knRPRw%{uBQ`py;cN4+zu
zP_NA*8|}c8m_eJFtm0$Xsi^9u=)+0J+SYt4kUz~xW5JTTt;Lj8CCYw0easo^;sDBK
zVSd^TeO_AX{v_2N3_lGyfqWCOUzM${bN;XM3h!v@(GKjbC9F4k@Xkq+UZ-tWRWxmM
zFYUKoecil`>ZdcP^lYFFiFlAsm(BlgQNO>UUbQ6dhG<B68X`aWdy@1XAZ{WS(hhf!
z-?OR9PtmXHA*S>#X?3|lX<at{x1j!KPEx;9=HMHK{9P5NX;%wq+Ly`rhM-Q(e~W&k
z0rj<)?m8ib;fpS(CZDfSZhOdU5i3&iy+|2`Nq-~)x1PlN^nV{$;X8wJyH7YLh?gmu
zc4yOxgNP-C`S!%`Lxk6l^d=+BDiQiK`JW-wsWwzc$R`mWskZWgiu<dSiy@j5hl8d%
zy5lwaW!lhZ4K*znaT2j5yQbx*e_!xA`9S`3BCK50nNh0WtDIi9C;yMWN}sIC)@jPS
zm%0?6iT)x3??Cc8U2pwqX2S2Ez&oI=*|x3@AP)QK6BZEP`&}vLdb;`J;+od9CE=r8
z_A=kuwA~N!Tf~Lbx-9?Cl%T&M|JJ6W?$WkJG@-uzK)ROFSC~aI@~9H+#t^58lZZpK
zx1?gW@=MI$ukZS_MJHWfqZ@9^>FQ4kXxcaUou9ZGVuMP5B<XlBvu?T#e@Cf$vx4^1
zg}PygDx_INtf?;=qw0T|ruwsjMR@-x^`%18muh@Z<|BW@=zpViI|peC8OiHH*>wGn
z?I=_1?4YeRjn%Y8$SLD#my!B&<Nu#+G_76}U3a&qVM_l^I$N0X@-FfFhq|#GKkHCe
zKBj-3O*%d#4sj~YgT1r~@i~OJU#9GX$*%^)^)dA`G?k{EMgL_8ZG^aGA+91Kse9d%
z>FO8%U*y1x9C(ofFLK~T4!p>L7dh}E2VUfW^&F62UN7;rx*;Vaef(Nk47K@^6)}-t
z7gNBKsE6I}lRW<d{T}!YF2f)2C;SEfz<qwTn8gvyj=~S{JmNm?9>K4~MZ~8{UWmL=
z)I95@!c2`itJqg|><+yAdrSRVFs#HWe^T(vWeO}#k`}|BA%_xHI7C1nh=eGJh8XAz
z^6M}W`omxt3L{_)jDravqB3$ds0p>9E;NM3&>Y@?*3ce0K>!3o5Qz8*`7Hbj=iwq)
z75&Jsffn=3s-OPY8%)^4EQCKEJCjWI4v@x!Fdb$>K_~{ZVJ^&v1+Wm7!ZKI^@4;Hw
z03X0d@G*P>IUpx|3R}S}cALT$^PT9whAA*T$uqM%f7Q7OH*b=#d-6-(5TkiEHp%m=
z9>OnCUDHa!e?p|C-$)1PRsSJ=)*~K`AQs{v4e`hTi%~CuE~vXf1c)fWC`mpwl5&P$
z)y0Wh2x&Wt`epn*j(i`xCy;Y7LL(zGCsF?hhIos1Sqyh+@jpEzgA|YfGQum61yaGw
z@DhHcf)1!VLt)$&fuhi!usT3TsDYgj=n3&4A}?}&rPfVc|4+l+Ob}tiZxQ>H{x14|
z;Rf7>hwubmhbHhC3d2(<0m*Qe0$zd$!W?W0w-#!dQ62`PmH8s<Erl=PTWEtH?Vu}k
zgL}{j^QLeU^&Kb)WuQD%0#9Oz3gcz^!Kkdv1~KaXHsv%6H*;VftjElX_zJt<!hSHs
zA=HQAxXJ8CliIN7N$!Q+-d^k<Ce0&=drcS)BViPbhB1&1#zGz#2jgJ^OoT}=8K%NC
zm<}J|-wfoLFbgiBH^daxHj|NO$yL6|vvHVDg6S|r*)iN0@;uBJx_K5!7&7}84KWZ4
zeIX9wApsJhAM}R-Fc1d8U>E{JVHk**jXVeD!aSG{3t%BEg2nI-EP<u)E-ZuPumV=X
zDv(jV)nJG<sMo?eSPvWEefR)AgpKeKY=X`3F>HZP;8WNN+h98w;tcAa;UfG5r{Nd)
z70$vrI1d-#68r|g!)3Svf526^26v%5^>+Xa0TH8=e1m7V;5OWZJ8%!~!@uwV9>ODd
z3{T)GXq2%Hg77B<dV{P;7z5)$#4+l}4{#1H!ezJ#ci|z}@Fx>wg&a^23PUj{1?8YT
zRD|kK2h5@=`p@8V*a17?3)lr;!fx0DU%}V#4SWlGVIO=4`{4i_ghOB!EtI|`aw}*9
zZ$evW4;`TsbcO)v27wR+!4LwW5C**<0+NcH<U>BF#;CAa1fvg6VrG7R3pXO7+<c$C
zhP!$oGuP#?w~Rh&6|94e@G)$MFX2BWs;M$}=U)%v7zDvd;`$@`(I|&I7xX(xzDwQN
z`X2X(;TV132{;L-;Agl5*Whm`MIMxg%1{+#_DjSO+@63R;3S9`!Lu<iQQ29}`*$V0
z2Wwz0tOIZ20Qq_Zet`VOj0yfFhm`OqVf_Vv!#{8xj>0iG4kCiE*9+nxCwY<AO@5qG
zc3WVlEp!5RA~ojeA(MK(kG^(49E5@%+_>|{lUaHdw}VRVqx%1}_?<C{|25FpPGV;G
zTa~hEo#fdz{7OyTN(Y%xXMqf=uAN3*67}cEW|3Rvi`h)nTkwAe?1OOJ9l>2K<l1l&
zbzS7yFdxj~U!FC_tT}8Zel3xwz;qCCoag7@5}bmw@C#gqKj13-3D@Bk+y)U3k!|>q
z93G*50#6|&`j;Usq=!t91+v1cP#DTVc@QxTH#1>2%z?Qu59Y%HSPaWxC9DEj)v_Mm
zhmEiqK83BY9d^Pl*aKg~Uic1VHu)fk=!o0}ZqugkBx%?3{7+?;0XrGt703yBARiQf
zg77L7g2GS)ib63c4ke%@l!DSw2FgM?C=V5&B2)qqLy$+nIG6}=Du3izG1MiX6ueFu
zzJt6J`htiBm@R`<kOH@f%3Ocy{GSZ-?mQQf7j+7F3GzcO2<2HMax@s?L;TzXTVWS`
z1$!Yg^>77pA?y}~WYpWXxSwPC7Mi8h*^zTW9>@;`p)eGM;!qOGK}Dzpm7yxsfZ9+G
z8p7+)6k5QW&>Gr8d*}p)2t%Do>3bpffhbr{oZpAjZ~-=}a_&XEN5L@k!yyWFUr2<3
zumg5OH|PN$!WQTaFOlx?$crEq>eP@1L^LCe7Ep|LSxG1jX0ew16VVvCxl-#U`hQv7
z5)QEt2mN3G426*}7AC+Xm<rQj7Ko^ef2(0Tj3G_qU?hx!FR_!4GF!*9iRj-!zZ8B|
zZdV|`2Ww#id;pu^6Zi_gh40}o9D^U=NB9}e!$tTVuD~_;8*acIxDW2cE2cW<?)m=?
zvzxpNZ^K=<5C6hLcmhu$srZri{ZDWfw!vp`4lcm&kW_5MOjg`}0z2VL_zGU*-72fY
z>O(DP1WlkB_!6>uF%c@MI%c;2fVyUgFHLI0%&J_&g4+-ac5KAcEdHggJ%IlXF`K-c
zXUfk`<a-y0!7L5}AsEubE3lAfi{T+WhW+q86yjMC7!Q*mH{^xVPzK_#(;q6Mt^%E*
z3rxpsCR~MU@H#Ys7Cd_cWMzkli`4tU=!d~5FpH}^8;zT>Fb*cc6i6z5!QMHz1ef72
zxDK}<srVPORMhR1kQ&lLddLV5P4?TN?f{*jGjxFf2!vn=gI*xwAo60qpJu}xm<J1B
zDJ+Ngzz_qmdl-(waX1Nv*hKofU^f8v(O2$<<8Trd!fIFphR8#l^MNN(1Al6%u<K&4
zF6svGJ=oAEgE@r%Dso{EQ4F~_490vIjDV8pOG7!R0F|H$RD&8&6JCSbP#+pXBS<P5
zW7ZU!LrZuQT0t9V3+<sJbcU|b4FbVm5l@`^!Dtu<6JQcdhG{Sp=D`A31R`Xmp&^!G
zwgOhcYFG#F!-ud5w!&wy1$M%h@D=QZ@4zh1qrZ^E>}T}9!f)^g{0aZSO}GPh;VH;2
zixglMsnMr{jF1_!K@P|b`Je#23dNu#6oE2O0V;tvv7YB2Ku6dNTVN}E20P(P_zJ#(
zy|5pSz;QSUKY>|fq3p85&zS!T7vMLz41d5i_zPr*%T2fk|H5r}0FU7*xD!n<Zw_xj
zD`*Yvp&Rso5b!3#c^(0MAQECA9ui>y41%FB3dX<)m;jSu8n_eVNb3Yx$-7}S41<xd
zgm%3`^=*N?6G9*idl4`U8d26wp&7J*L71I_4D@xGATwlzY;YR$9LTxAEb^j1!?XOz
zg`g-Dhd9g<pbYAAPzkC+1*i@+p*GY7v#3Wr>Vt^>xEJv&@+J5kF2f&i4I&{1R>5EJ
z58ME=kk$Kj;1=e0;2u1HNAMUl!nc8}_)G=KAvL6hbl^^;;rDr3*oXW5@IAam7_FfV
z?fEIB<asLfJN{+l81g;=2EkOA0d440J3%+qx8_F94{eoR!tRYa7Tz$Kxr>vST_GOH
zi1TCl)*~)w(WgRA1Lsj+gx??qc3y(+5Cr|GBLg8EdV}n^$PP<+wj7e7P6bC%pMYYh
zi^Eiy4*8)Vl!FQ|2s=Ze8tNL*6}rJ}%;rD?XbEq^KX4P8LNjQMy|<we>20dg{5ExY
zDET!C#)2U}z}^<v3OnEn*aP3dcW?;4hof);PQhx@zaBQgY4m5|0e=2Pp8bmYH@E_S
z!ar~e?!Y~G2#-M{Ub0&xIdUpU0~sI_1mjm2^oHRu8fuXLH6b(VY>*4`f{0YeFN5qL
zx=uQ8K@RNZg!;s(f%<N5Pq-anHF>ladO;+#fevt$`1}cf!*vj`5x+LUb`Y@&c@3<C
z(byRSlVA!=hZ!&%=D`A31WRBkEQ1yB0c?cLAS;1Cg>CQ|?1Wvg8@_^X;4mD8<8Tsw
zhF{<uT!5tFCG~w~Hcz9>Iuh?L&>dpPmp7pmw1KywD+IzI=)!k;SLhBspdn_BATwlz
z?2sFhiYk~@gV&%A)C05VfWDJ5dmXt6G=*@&=n3^917w5-&=6jS#?S<sL31bqMWHy{
zpzQC!Us4C40A?kiB$S3SP!?W=Lhvtk9)pHDIb1<~P4r6qqST+!4}EU>zA&B}@^qff
zfcdZhVxccAg>A4MX2TpX#7xw)l>TGnweUWC1e;(zY=9v!6h4Kmun-cVAAA6dU<-T#
zb73ABLUyQZgwgP>GJjvCX)^i=%4`Jk64(LDVJEDFFJLw7f;F%kzJxvS6(qnw7z}1n
z)Rc!}KArdNOw&8}EcOpUHrjbE$O{GFS2z#9!xh+rKmSlCZh~2qr~OuhN>CN5Lrtg+
zb)g<KfQIloG=`?o99qJg@D{X!HqaK@!T)ZNnKWgE?2r@kK|v@4MW84Yhf+`$%0YRk
z0F|IBcoSP_-=D%Z)y~J$pG|}&<YNN;;A@n@=d}4V_%o0`V<-gj{AcuYd0vO-^`Q~W
z!+Z^#<Jkqc1ec*P&zizj)PKU?@DE&vn{WsIg@^D2G~$v1UWT-g9x}iykQuT<4#)|4
zp%Z?0g_h6;WXEU+c$H^`pfvHE3Wf;eSrCLlPv}j(>Z9u8Q_}q=>Q?YJw1f5d@jl4z
zjg7DwK88<VD{P0);B(jsyWmUs3ci7FVK00K2jCEh2*K|#2#22VCixtS+y%P9Th!s!
z(3Lz5fYqqiL3OAJxk*zVIEwlNw1f6g2LH=L2xT<}cLy*#1Q*~pD1e)S@D1vHFdW7}
zFoeN9cmNr(lNqw1&H;^~8DzsOJA8)v3rI~|(?WX42$>)=WQA-XJ7KS2{~G)axzOi<
zyifoN!mCgSia=2)4ke%zl!0<k9x6g5s0>x1I@E+(P#fw(eP{@cpfNOs<^pkT0h7t+
zsqh1N^dtO)*%`PCQ^~Jsu#@Mq3%ngPleU1|59&ihXbhD}OBHyPI$Idd;ny#45q^Wq
z@CRIjQ9K_5(bTtC_zSat;0D}+J8%!~!@uwV9>ODd0vhp82FW1>oF?2<$aC>)A)Lm}
zS*T1Js=^z@uN4f0ArOgKG#tjxQD`Z4z!2}EUJk{0R)To0L7t3$3VZ|~LoLkfLInQx
zff+ChyoudBuZdsP;5DcN^`Q|ohGy^vw1Rff5xPJCbb~-xNLn|*2M~ll7(yWeA|V=L
zAr2Ct9}IxOumm^n!Vcmw6#Z}*38P^wjE4y@5vIXxm<tPFF)V?1VL7aXilo0Xbi}`m
z$ge;aNDb*=G-WX!+=&)Ee-m0mduR-u;cepA7Bt*_%{!$lW^bT>6S|`gf>3CMz76z5
z9RZObyZhoG0TN*V41r-V0>;4vm;_Ux2kt{*8tNG^3uePym=B9!3A_s{U>5ONh5R0@
zgAMQjY=lklF>HZPVH<3R&tWI*f-m7K_y)d(@8AF&gzw=9oPZx;26b#9bcO(^L_8b7
zIr8NqgplW<5C&zip94hXK^~6T2p9>cuzLpP68HJA5EjF`uoB*b4`DNW0^8s-*a^E~
zFYJSZa2SrkN%#rQz%OtfF2QBE3fJIoxDGerHr$1O;SoHAWW+NiyaZiI*9@2i!|A6-
z!n?$IC9Hteuom8jjj#zmfo-rIK8G)0H+&7>!ag_vhu|obgA?!$d9nzW!Ae*K>*0O)
z5H`UU*a~03*YGXug9C6Fj>8Xd3Qoh%@GD$`%kT&M1=ryg+=Xa}g>cf=8={~uBtk{{
zR}sy5?n@+47y3gCc@+zBq$vUV!(bQ&RiG*~<oWB+1Pn10^>7#oV__oPfZK2%9>DML
z1d`*&OYkzJg$(ctWQFXI3-UmIC<wB9uPBs&Qcw~4<If;i4vS$Wya#LGBls9Th3&8d
zcEKL_2EK)TuphpMBXA6UfKzZ54ABjBPlzy?wMX3%szP-r0>z;MRD?267OaZgjGyFz
zoRAB$Lk`FUufTrZjo-sByo-K?cc|OT;5_OJa2xeq5D`in=m|j(0ev7E`a(P;Kz|ql
z!(lX3QEsa%`2qFi3EY=@!}Ao75?+QhkPb3JX2=FPp|*0{K*=qU--0I4OqoR?_f_it
z$b+B<gg`s!2tSh^Z(<+Mzcbmng8C0gPd;UU-%($N{cr%j2eUYb{sjC0C*enU2#-L+
zeKPnP^>w%jx5QkD!>EtIDfmg5A45J4r{Rn;6YF{L#}M(POGFLinotKC!t2l+M65-=
z0UyFGxCi&)0el3H;4wS}8}G>EkP=csYDfnnG9ovD=Fk$}f;M1?DyXYNEvO3(K*S;Z
zJq$<T82kVtO7OfCl!mfU0nDO^(q}==2Du?06aWz&kUK+H=ng$V#6|r74gP>@@E3^q
z40#890ej$U5OE6mCpZmf;TI6G9{GLP44=SO5YY-b40=Hyhyf9a)YSnn2!_H47ztxw
zER2H*FcBuh6qp7{MR^N-YEm~#aFYYSazP%*2L)g*=JR0zyo$as6onE{5=uc?2!QU;
z1K!1M2yz(of=GyhSm?~N`^fi@A0R&g8|hC0FT=l>KY}xmnrCS-OAjKtVP+OHcs>*6
zzyeqV@4!-64y$1;Y=HOSBY}6%CioaWfvvC|K8GFf1$+s6;A{96_QH2?01m<-I0DDu
z1pEj;fgye&p6B5r{03LxPxu>dz-_n#Pr*i<lEX`o7BWC4$O68^1l&)C74ROcgAMQj
zd;}lEr?4G9hh4A-zJa~)9UO#1a0HHlh?7e0fgB9s&=Yz?6vRMZh=)WN0E1x|i~<qq
zk<XEapWy;rgx}#05b+msKgx9=42GdF5=O&t7z^WJB20#<Fdb&X9GC|SU@<I(<**Wx
zijBPM*1{LG?e)kzkaxo#_!<ncnP;ECHuxOAfZgyl7~%x#AE6dyT?gtx15>#h_C)TW
z`rEHf{jT}BKkC;BqX{&F7VrkV1*!PfNCWesHTtxSN4|~R4mv<5=mG)I9eTi@*!>%>
zLlF8!$jcxYbtv?NUeE`kAr|7H9}IxOFa$=xC>RUlp)h_Fhl!{sLnhQ&U@GcqaDaR}
z1T#_3ftO%DEQG~ih`Z$1J(Xv_Qa<P50{je@;CHwJSK&|i8?M7mxD9tf#CL>!7>>aY
z@QAP<!;h#>!&&$R&ch}69j?G|xC%Gm7Tkfma33DRBX|NDaZV1+P^UnC8PY&H$N-t(
z703)(Asgg?oRAyxLVhR!1)((ll!fw82z?PK3MHTvl!3BP9x6g*s0!6V#8~odJiMdw
z?lJlBRON*Yv%dH%qCe^ZFi6=GvvsH=AsS*J9=?HZVK11)Kj?2Lv+T$@l{z<aKNW`9
zpM-vjdS<wPnLeQfyiGgp09_ye0^u#pTgx+O4;dj1yaHJuJLH7ikO%TXL3kAkLlGzj
zC7>jfg3?eHDnezb0@a`fyau(P4%7of6jpIAhWr?wKvxKW?hpuRARUOvfc(A6=Yyy_
zLMP}9B07^N-60r4p%?UqD42?!Y092%oA!ubZ}V(E@;k5;mca^G1@FOXSPSc51AG7<
z!X^+g5cfl1B#eb|FcBuf6qo_Cz${{L+ZW;?5&FYG7z9IL7>s~XFb2$`GJaKq>QEDE
zLp^8+uR{xX6WW41v4T8U1@D>i;wtKEO8*Y-mcS}l1M6S|d<Y-G$M7i_qBZW8L4<NI
z=5<ilg9dPf_#cDgZ~{)kDfkJ_Knv`&gf~D$O5~T6`eo!QPz_#(CeRFOz-!=6T*Ukm
z{N~}gJ2!t}w<MHSZptFJh4xB+gZJkvN}UBcpHk;nas}iReCNNUzV*XNS8upSA1Gon
z>ZvdjQe!8XDgSgE&;H+mon5d8e!`!<wA=k)h~vcRNB9&zhh6X$d<*-b19XD->9anB
zl=yQ-#mDgD{|5QLvd++5`YIQ6XZn0*75;;Mxr;$b<-hD<NXZyZPvkZb0Z}jlvr!;x
zE@B}bWbNhvNGfC<hU}v?))!R7?>Es`LM{fy!7R$6FAXBf6tqh&|74%QZ}13YpQ7w>
zoePt}oe0HT_KuV*$a@w3PZly4lOA$`j4L$;8SBac|2GL4*ENLfD>H=5!9S1qN4d*u
z^4A}K^5d=*ezXH)Pp$0Bkv+fx&>dv`mhA75^(C^7D;#=(tTXvfi$h8LJeoxRSrWac
z@F!vKJp2Z`;4FyPjclw@khKqgz!~@*eu9%AYZ^|&DL4VLzTt1U3bIb(7|594ckm5}
zi1JboWgU*}iy8v5E=Sg4^@roI5)Q*b_yLweMpIeJ9u!$GBJ+<j51AEmfvg|N0wQ+e
z<`vW}k)y$vSdJapHzH!I@<Z3@{}=OYi3NYe_J<~WvR`Be?1TLvYZ1PHFG2Psd<tK~
zx3C3dkAWdRK`rxahS-dHBX<6O6S6<hlX&%iC_iK!#0%j*2V{OV8OXj&+2?!}WWS{B
zQT`RoA{+LqK^~|FH6arEf~?<`eVwO4_DRYf%X9Dw<}!DY4`d#9DYOG$LgrtxKmm}w
z!!N}Dd=AKd?=N9G?RYj!g^@50IzuFw#jqrL^RuMte%KuZAHgOI?qp8U5VH4hJ;?fp
z1+WU1fUJL*4l*x23+BRT7z_ho9LU-kUn0?m9hn<^K)yT%*~c$y8)bdv3e06szwGCi
zef<AvQL5nc`B)TpCA_$mb(^x@Q`XwZ{zzlpW*5}0LDp@`+S)*PA^zXVf!dU(tlJf_
zjJhlH-tWKym;>`*HcW-dFcW^KUXMkd0EUn~^*@80qakMw$Qc)M?uDF-A^ZL>!x^{$
z=iw4u1RG%|lknjw`aj?b$ew-Kzc1$x$hi^5xe{`Y#CKrq<qskbZ-cA@dno=Ox}%qM
zH@mR68$`(dAX(cV2W6o?42M}T7m`CQm<~_yN9NxP!%!Fr;~^a8!y=djDWM9KhB`0<
zY)}bGLQxn7qd?X#^n``57^c7&NQC~77G8zX5CWkP4KXknIza%e0$FDy`zM+~OOUk$
zec(FrmNm2o;V>M7AK*M(g4EcNb#t=c^=J4Kl8Wyz+waCaslERRed+&!c=aRC%tF>%
z{#S*p;gdCbQ(+iPf&qjR3qh#gM9vAaR&yT6KIk6M6JEx=1jycH4O#Xp--bPqAHD2%
zE{MDZ`6c8Jk<Wsx1<Z|J){<U;bf{&YO9sdUb1=(}ybbvl>;+k8x&vfw_AdAXHo->7
zirsU_f5X?X9lnJla19Q?PPhu6f~?iN1G4rsGj4xJz6^hXtZDrmWKC=#p5=vNPy`NP
z_CCA|t6?cDf`zaa=EFKz1}k6#l)~L&<dyIatby6k4MHFsra=V!3co-K+{7dIgE;62
zZ$les2d&^O=n9>oJ=Dcbc?gCcP#tPOH+T&?LK&zGU7#v-g>ujtYC|A2faCagAMQba
z7z6`h2n>Z$Fak!x7#Ir^pf^N9ABcizcn@UVP<Q0<5CgBHZv!V$KY-?_JHTnwPazbV
zpl=I5qJ9L8P`8E?sQ-l)sGCB2IEDT(^g<m5y&)ETUuX%<pgEL<N>BxwLIr3H^`Rz|
zhq_Q5UV|FY5UN5&s0Nkczf+VUyq`#q%)id!yL7mW%OlTV-2Ge3WxnnbvdrJgJdw;}
zHb8y^!+GD_;hC&&mpMbJ6V;iklHWwKe(An)Cv%4~SJ@By?_(x;ISu&+vh4l&gz)6t
z18HB2&`aJgLoS3HnXhSx{vqS?LD-RYFY8bxKDn^Jg!rAtO!QLciWB}5WSKi|k3E^k
zlyRMU#QO`zTqhHUv&w!)p39tP5oDQfly!CDkF<SRQx=Tf)aYNuT;{5zUTLJOE^3)?
zt%W_=7g9s%b0hb_ekbgm#lOeMG6yZ~O7{Oq*^0T0FUk8-#`6kc_7t^*E58jS@1#xt
z0VhD_s*@uhCH=jyE8ini2}kBnr2lBcbE!*Lh*x*?vNkKPiifQ8m3bgpcPR0d-?Oqu
zQs%*AepuEFN_=H4`563_`B9nElC~*p<YLjw9GkSao|qrNz08RhK`w_p0XMSOQTkq4
zLnq@w(w?NR9>a6lmm_+a<CA$Q=|iqzE`7%L=%xS2MtMnJE#)r#gRCi&IZ2s^mUcM-
zvugNL5?SUXWv)-wK+2r{J)R%MJO;hY{mHs{>F3@+FZ0@KaF>tgU6G}p_rzT0=>Ek_
z>PKbl7ptzX*Oa+HIrB*DNq;|x^z<TqCy~Q=CUbCqVlL$*YdU2vSmrEcPEG2l<Zpi5
zE<j%gdy>w2$bTUR@=WZ?9>0b7BmLpe*puIZqmaw+Oy=}|Q2xu9oxJmYL@#S2<h}9@
z<uC7#FOX$UU*_|r&B(hYhIqC|ABwz`XYnBOn$o}A1lfNqYY;NxUv<)R1X<?LLy=|O
zo%DsWcCSA2Dg6HqS=L0z-WqA=(x30gUIF}?gDhtrjU_DU|N5YRf?SCFkl(m+2F*$A
zOFl{e9Ln>;=sTmAGaKdG^0s=O9$D5eN|}XVuaOE*=743+P`){(Ue#9Ssg!;YVQ0o{
z7yeB{E#HcVurF(Dr5v(@)N5JeA+qGb7Ucfe-HF{O;@K9nR>%^@HIVogLw*hU4b0_z
zE#DR;(dR*y{fRQZo=fb&WAp>@U*_#)97on>wnP35^Jv0pg?tRXtanL|J*jW921Vw5
zGpcw+B1?UibKTPNd;)rztCcyYrkJNfFY%IhXKKPZk1To_`<M6q+sN|Hk#qLs{VjPS
z>6JMxX)oQ7cVb=zb!OblH&1fnDc{j2C};T=k~OE(a3}M!GA0&?eVO-^H8iPto`&ZI
zF`LD6SywFn%Ni6}f6xa1qp>6J0EyRI=%vlBMV2w@DEw=Q`8}RX`lYRkJy~NQ^W)92
zBYnaK<ezaT^YF43Mb21D4O!4jc(UhR)`+}@JxP~*L&*DJ0RBt=An#8Zmw$--6?*wC
zCf@<FE?V4|#;gG9XpnUR@~v_U|E?lSd{SdB@e{Y(K>7lyM;B0wdl>_Y!kzqPc@w>S
zQ+$cKJzOCk@{QMwd>TTy(w5~rB^>`ZVJ>SZTVf__ZAu}_8W{O@>4iLrG>%3+33pPy
z3CQ)aC-11HxRW+4@sRHlS*I)OE^_m{FYe-T7el<Hy~((g$hEMi;ZHL3A*khdrJSGI
z6?d{0sX1n{=k_47^y7^&m-f9II}&#p%aQj~F3cp|@+~L(bmiOWI^h>UmbJMzktN^C
zVo%l~RYWg)dSz|U6-Wn?pYj`R8FEqdpJS&uvaB<Zaj+J|N9J54-fc0L{yr!6H}bp^
z`ooYH{c7|w|5_XSGS4O7pw*xZ>8yaf0(Wh&EAR11$g=)G>c}K`7559#%bbgZ^F3w~
z?^@WCd~FW0HfkT{vZiYkdRZ6qkBax7$TN5@--91wXE1pq@A%3fYqW-;m%86q`7d=$
z){ec6**4@HxcdbEn(<t|Id5Pt;b%p?9rKs5FZ$ldvQ|XqhfeWK#+C;muSYNMfyq3R
z^%d!GFMFuRpqF(b`H-cYf-paVUcOOey-ytOr5?pAxgzGrAUl3-;CTk+t_|*_U!RD*
z2iPx(xvclOh`GFX4k62WvDL&wzQN@zLn(*Dn9Dk>VC+j@{SA6qZ&)9-<ZE~AZN`2j
z%%xro#eb<YeRwA8VfLbybsyWXHxYkAF_U#JO_0U??>v`$>A`dP7CNW&K|GT(?gFyD
zY#6ev>pG*J_a&UJm=C~Q)=nMAT-F&rK$iZjJ^qy-UK!BKdif8KW&PC4$nu_%Ij?c(
zBk*Sp`bL;PrhUt|yS!iIx6e<=vadqcI|U%iTE9f(zc81*=W<5&Bkc7dympvNz3h)H
zYto7#OFO8If6`ycT%+{!+0bv|d0(DO-;)+Q{}ApQ$QyD07G|<$?{D<M$XAf1-1j3(
zK1J|c`cv6wzMFVU8{UUJ5P2SU@*qFJ{}I@c^<jH3lQpJw&`W;T1L+5<6AzgaYyt9)
zkl!)#eJj6p+Tkt@b|kz$m`VR!20PN<l>k{wC+oOmO_B}st;GLp<S!r;`*$#x-#6!p
zS2^tc06BQ}E9R$=yWnqH%%tCtzPlUdZ(%O`5}G0ZMjHM?mhk^UmVAiBo_v=k!=0GR
zx|bQ)>xp?Q%zI!y5q?wdeo?ZF+m|E#GLJ6r$IF;YxboZZ4)M;0{t$93e#v)B3jC1o
z%_}^YJtpDkWj&UByU!z>R@lFcd`<M&v+-Qw^APg^$obJrc?A%j)W4icp9l3y+zmo6
zYY2bFzPL-op7d98e)cZx+*0P{kR|OUK)z$z@w_C@e?=|s-b6l2yk*_W7R==xa2)@$
zpk9QW2K_JC8!hoeFXv^Ktgf%sc!WL~&!_M_H};pKAA-FOlvh*C6UmEwn6JUS1Lm?e
zG#j#{D~FO3kXyiQ{2hXu)~NIHygcfsAoD5`uj{BKzf&MDMg9QuuQ2b5{s8{>K$dsm
zAIOrf_jo>(=WWsdM*4Ch%if(>%q5@7qL+NR3-){<+)TI&L6&}{DCSkrPsFawZMVW)
z;$Ix|(Xa<|`8I5dxvZI$xgP1ihGH(i52|7Q5GufVki1xpyBFd`4!p>L7dh}E2VUgB
ziyU~7121ymMGm~kffqUOA_xB8&H=gqZ)F<BO;YG<rX{uY_{~@jWbWX5em9zh%sa|&
zOxgS4?tVYBT~Qyw-ck4go=4oro$N9BmAJ@yZxIWTWqwXG`6**KS;elhW4D;(pZsQ?
zVsew@v5PhZzl*1UFA<7=;Sd3RAQGY=8e+gczKxs+{b4Z3Z*keXGX}=N1P~!}c-5dL
z)P}my5E?^scmrBPd*}oK5C}ma;wR*@@GG2$i(pmAeAhrPd1uw1=d~yEL^75oA`Rme
zNrmiP5HTKk5?oOF1EldFOoy3J5Q@QUknzj;umBdqQdkBn;5}Fi8{h-@2tI~SAP3}x
zPhl&V#cma@VJ7<_WS_wlkTIeElyG;)pV{xx#A|GlxLy4ZhHnnbtWHaq=^+`UfDDik
zUV$uN+^Hw$7|L9HMdDNiYO1(R#!SwGtBbw?Gy$1YcoSNI%mY^Bc@?M*wLpZ-kILMR
zjNyuS6?Ivt03|W21bfAdF|JZD4}EFmGGK^usLMkIs0fwdKP6<2P((g2e&!;6o<u#K
zHG)`(gEaV;0T!cP0y0l3bD$BBR4l?w#^6OvL!PPBGX5>%bL0c?lhWJp?;z@y$ZtVD
zC;&yE4m5xS=m!H}AmmW#T7>!?co&vKIR3~O`YhDdk#k}%7vzTg%1s{Ryh?owJ9i5)
zE{gqN2!o#RI>;EV?B9`b%|q}QePMVCB|zo^Wj)VJuoC@hka;xOCpHZANZ611dpH7_
zAsgg^ywHZ{?Vtm6hOW>J?unk~GNyeLj>8Ek0EM6!l!gk>47+mY%A3#%+Jelfj)Msh
z4UIwOgJ;2Pm;<X}9lQ@BWV~1QWr>h6;q6NO4f1!e1!Rt=1IXC<O~SbYBCaFff|5`M
z%0necO~3gvyacHrIc6y#9b^V8B0u(u!b^|_N<lez9&wm>kKi3z6J&kWNEij9LDuNJ
z4Cz4DU&y@9I2aGI7DwjsWG-3ekEepHjhGG};it@t%!FBR3H{$-7Re;-@Lv%hQ%4I@
zXCnzi=Kf_Jgse@Gc@&wOlX*#*la#T28AF%#U^4D5^Y}7XCF?q5j#cKOWzJCMS4GT5
zo&$4X9?XXYun-o(Vt5CZz*2Y@mcepZ0V`n@ya%hn5NlAcg>|qVHo*Jv0elD>;Um}t
zo8e>F0-wOAuobq!b}+;l)Uq~Q)_ea1r{Nd)70!a}8Im>OvNrq@$h?-U>ADP8;17^J
zO4r~ncoH{wb_;I9O}GR1;6D5d58xp@g2(U#o`Oah+kBMsG3v$-a1JiQWw;4<;UU=Y
zClh3a98eGnLop}?<)A!Ngz8WS%%Um!&){>|0XyLf*act0ZrB4~!PoE&d<%PFAAAS<
z;Q$<jLtqvyl)fc$D`*36LR)AL9ibC+h5+aWfe-}25CWkP2E8BxM0}5Y7>?1lPryky
z1wX?jxCVbiDe|a1REDZh2Sgmf?Fsk+PJ#%TQy&8p;ZMx|g1_M(xDEx>J3zOc<Uekb
zLrO?0j^g$h90w6W*y#mv@FQlYlz9vEZ9(QjMWjYf51Ak*<b#6n-zCx#R>maZ)j(f6
ziJ3p~nM0Y(1FPaI?0yUTO>PdMJ`BfAW<UNf_TB|PuA{mizq^ucIdL4taT1fK;)KKr
zNsw*DaZE_Gl2+Enl6Ki$$#!VjtfZB_iL@(LD?fMyL)(;wlmab}@@fhcC~qjQLJKKx
zN(+Iulmexp<y~m8TPPGt{@?GJIrq-JdsntY;Mf1}=ll80?wvEQGc#w-oH=u5uJeAp
zy!RvS9VZz7dc@0}M15(0vIMuq_Nj}D`~4}x?>|8t+&uJs`w66-K7lxilc<}PeKP;^
z$bS*;5Zu!uW#xh2(*b)H+;70GhdU4M0=SFe+-DX1U2tn0_?M9WD{v3OeFyF>aPNS7
zFWmd!_`DVWZ-@I+>wgXYUkCTcaK8z658QL%o(K07xTnEA1MXRHe0JmiHn=Cjbz7JT
zIl13=BJH2SeFAO>b?5}&UtxLwOW?l`?ln%`H21dv_I9}Uz<m(z!*Cymd)l=cqxJv4
z5zc1{{}s49tlvOef9nWu!qFD&8F0S_7kz#ku;<0Vqw!9}{|2<dSCH2i@&C_oZ-V;>
z+(+U5Pd-UIW}gV$o&@&|xNpO~3hqka_87Q7!MpqHaByB>)BgeD{1@Em@ShRG2Q>Xx
z5$BUg|M&R+BHRUd-{|D0@uL6VMciM;b3Smta2fpLa9HWYUxoM8aHqkYgL<9o)a~`l
z)L|FG#^JWX?SOj@T=aQ^1A7AAi*WsL18^UJyB%%@ZXetn+@)}r!)=1Q7Va##v*FH#
zJ0I@<_UAVA!4u)01a~{!MQ|6x-2rze+$`KaIDPu@z83CGxD?y~+z?zEZWwL^E(3Qt
z+@s;Hggc6M`~lqe;Jy!c31FMxu7Z0E+%<65!d(it5$;Eb^JBRGf%D++fcqBS|CN6G
zeBQqIA?$j%ZE*T*$NLVrn;h89c)!K^d-1;&ZWL}D?ku>o;c{?!xFXyn+_`X%f^#39
z1sa4~2S*!G+H2AlOCQ?f(T47I!0&}{Z-#rX#g%a`!~2zR*TB8efj<uKKZAP*+`Hgj
z0r!V+pMd)z#>bE0j>7#X+)v<s2FK^$5xyaUBjNoB-wC%4VdpsEgNVNq?vZ}JfIPo+
z0{K1;xC}b@w8P`;$m_*$FNgaw+&{v71NHfqtvAy>1eiYW!~1_aeuba<Kh*-KTHsU*
zoN9qnEpVy@PPM?P7C6-cr&{1t3!G|!Q!Q|+1x~fVsTMfZ0>8`_=!E`?wkuDCTMc&_
z++A?oTRH;A{iVC%xCixHaQDK|u8ez8zXSJtI6kZFKliP;heW%j`{1~z#l5ay)^q<a
zv8-QKowOY8uX8^j`p|Za&x`T@+L-!tFPnRL+;gD5bz6@_m!Fr##1BFr*|!^dj7{zf
zA7+`{ll&<h?bT?j_BFV_gX2E?19041|8F?jQyhc)0o;GVy$|mFaB<HD;B+?JdbksL
zXs_`jxDUX68jd<(?hSqg?qr{}J?KxkcOxzLf=8Ub9mcz>7pJXQ7u@M^v@<&cZY|uI
zaNO@b3vL}8Z9~_?=|0wZc<+I`9PR?Rm2ey2Hp6kB@H)7+!BLOTz2>*TeIM>9oIa0p
z-WAsF|5C)g7OofWBDhQ7&gsE^Iox;g{!O@V!@18zs4Mr<`CRC<fr0%0<9A&T_FmwA
z-sj?<BabtYw)^Kue=@jppK{~>;=bY@>i;Xx#i(n~!>BL!p;ITA?(&{TrZsQ2<=t|E
z<(_P*8y!3^bKXxTp9_)hqKBFGWXk#96gP?f_@3p<9e6(tj<!nY;Q!z8&pqFjcs~P<
z5AC9V0!P~f+A>D%?@X*m=9l(`d}v?(NIoA2-mY!lm*MC0Rs25)_jx$l{(J%MOK^V$
z_bIr4fou14S{xJjKmB3it9$7mLpguBOj+%4h{7-JF_6s<6CdvN^SPu4d<IS*+NVUH
z$3|e+Mf{9^K~FSQ*#C8u_fK%2g`?fehL}9UDgO8RXcx-oBlv$*kG#sy`ObR)jenyp
zkUq34TnqOPHeZFu{a@vziwl1wVYDay3~*Y7|IeKOZjWTyr}8@00uQGJxaRsR&@0zU
zqxk3f0O~-vt~&_-J@9i)#k&`2%kxqAY3KJFHr}W3pFsF?@K5_o(*G;*Pdh@|y}lWK
zhCcxJNx<`P-$WSKdn}jdh-f#)^9YPb-38Bb-3veQI0Cl?;a4IaZLfF_7;UGxz9YVG
z#Q*d0|JQ(h0RNnGm=Dhh@SpZzw3XwT4%*Ir2r!-rdlUYNC(lQ)K6m4v<-G&$W$=F-
zey0Cp{Ig!aiGQ{O`7zH=@eVbH&)}VBcR1ePiTB@uqdj>6|KG;{3*cy9`YwdCzC4>j
zd&ytJKl9_c2L4}x{AgqLJMe!I|EuA+F1;WA^YH$4{Ifi+P5IBYBLDvcj`-3hkN7Xb
zJsSSM#{b9g&v}~d^j7?T2>;JRycKY7grmJE*S$>tPW=A^{+sw`KF>uM@#=%S3-C+f
zSRU_9V>-%3T!V9-W<1_;Chd%O#(OT}vmGce5RXsdo$$Ya<N3VbviZLoVJwelZ<v0)
z_4BL+;ctf{e!LTxcBHf~Bm7x5{Lz5Z9`7lDkxqEdh2=aO|Fq}j*%<02o{xXp1HT9F
z><7wv%;(he%WHu%&gt+jMR9AqbfZyk6e@F->1Mrwdwvakt(UJXRvHH?Gg}0PVd`~z
zL*-^UJ3G5rX?p*0?5M_FFK|B#AAYW%$5ua&4c^$H!9`OJ^SsdbOJn85J2lTupoJc9
zc&=V<<}3TEi_J=7QNyl6*nQrf`S~D3%DaZ}gyP)ioraUj)cdUIOn6trLYBC)JdD8l
z!Cbk~^bGzWMX%EvsqWh^z@yu|6=c83$KuC-lBGR`)MUCeoXwA=ir#g%q$Wa;{(h9V
zVjc5OAYbN@L>`-+Ji5G_mTI-~d}Zd^W_jPul1B)FJd(iE&nI#0=&dJ#H|t0KfKxQm
z))<O-p0HG&G4;9|I02Bn-oYv1l}ZPu8_iOA5nbIZ9VnL;n`oL+b+J^dH%pDmY^71D
zO;>I@IK98zC^dVg>$SyZ&(#L~TP{Dr<o&tyKxsEB2%7Qhm*ji0dp+=3gI3$(tvm-;
zQLMZH{w}XHn#%7?monqU^v-mija3YTkeQQL$FZXWQokc;cK0b|#!|><yjU7Zr-st`
z!nQusd#!Nf=;PMOwr6{_<d>dIBeS7YF;yB$7Y6g0Trn&7O_XAT1kY`@A9qOGmu9Pt
zMSuJdhWgHx0b(E0-|dwuwHZ&^=kf5feH6Fk3e#@4Son4Ecn)UKbbBnRT2HvmR+)T;
zY(6`XPY39uAAWr{c%^!+a;VxYHOo_Tl~U8RT^NR3+q8Xp&tN)N%w)$)xh#7!Uoh!g
z;ZED1-DU6^v3T7aUq91-L)n7uShrULsFQEv0_K}o$9qq1Mc$;nUABz1&}5SjaP*Ez
zm>tU(9y@wB`Yy?q@zRH;D+|qPy*5~{HLJCyO8QV`dWitiHRB{&;}k08#`J#BD#MdO
z_;>|eZN|^ilkkope6T(@SDmTMOw<lmK?=u?p6laLDmC|4FjnW5Dl!I=-C0|YVQ&@3
zP_hYZp8!}XXz8I$A(t&=*c)uB-F@+4XfSt-UUckeoAwWK&Zh^n`Jrgf8Yr@R6>v&;
zUCCbHlqXJx<ABx7fw7a*1YCwpMp=yczj?<FpGj6~OY_${l@}(oyRUtCzt5oJO6z|@
zdSED0--`|HP1^Rn0&U(6F0dQ^_QiPUo5VV_yWB0%vC`aUz<(XHiA#<hC5;u44`-Vv
z;=cyEPI%qP+XO~9sqZ9PM_T=aYI*dFmIrN=k|u?E$Zxhv`I+n>Xo>!9;vc$A{Wpp~
zJFNbj#6RKtZ#L=oX!wBm8<oZ0(q^5r(<aW4#>oV6wrHGDfjwbR{W<YZ3QwGn_d$8z
zBk#A#`>)9Rxc4DjH_9_OC0(B0U#)R$us(z(z44{_sY)X|TY!**0lVl)7~7)LD^}+#
zkZUT1W_f-=@+G{>%hjtjNFK#{;qd%aeXd9r7^GVh<SD_6PI=v4q570cb~Y>QqC7WJ
zDbG|ICN1$<=M93=%hSjmW1u?Cw4DFeV*V?kPMuyUl^@&IR~pV0@}+!wC;Pb=fq`_%
zcUPf$w@W)9V?66UJLe5&M$<9O(E%feV@F>l{Pp3=1*H<jhq?N68PmgpX|TnIBOgGZ
zip#1W59dL{kGp{HbzwTLHkwQ2xzx-ID9)D=*?*nV2SM5d=9OX8HHr4BIPHbG*Ulv}
zr)R*pFr)7^{46d62)!FPm^mSpFQvy*1Ec97(yf^T00Xx*K;`>@6((}Ie7aCTRL1M{
z0L!Pxvc+@(Q1WF--$nS?#Aq=y29QbLP1tz0kRC5U*f6jj11n0t*?bY%O8S1nhq8ma
zY&l2hA5B3_$p!pqHQRC3Ijiklu^;ULp%f7d#Z)oPy6^6D0B#>7P9u-B^W*8x`<mcA
zc}DP_IP=)in(ed8ghF%82I|1E$$sjx{iOai{+hvzmmb7f;}s7t*s(|d8GfA2GF~~R
z-1Um$*U@d{II!a6g45@auVRHY)9JB6Xac8BXCFu2bOxDANDerZUvmAiqvJ9TTjWhc
zfmsowQloY}hlSXdz;NE@M%NLA>b_dJxzwmg+cnWHo!)SDu41_q=$L(R0Pqc7go7cB
zJcn}PA*VgN5+^5Ta~yiDvUO>Z%%oN?l^gpGfSb%!rw^Oviwi+5wVx9kjvYN88U)Hc
zPf@(O;IZ$1yhj-x5L5QV`0mX3P-!Gn;OH+EIebmoaUm%Ce9-h+=bSF*-mxm0t?omM
z3g!;aIiEC>?7j<lP=;r{6KK0<D2_mpbN<QKJJJ1Qq+Q|A<O-2*lij~&%i5T5*Sx`e
zKO<#_=jU00WwL2IF00}nx=sCeia$H7{yFha`2Km5evgLN#4ly|^LyRI8PYgU7XN6a
zX3M0m43g7ro41*9za;)bvjHhsWrBkO%a7FoB8@)PrqS@Hi+^Zb{YS)~8p+u*eqH>6
z*H*@vJPsXJY6q%~dTqW^YsQmfYXlj4oXeroT6s6hbLR5Fn7Q1*gqBU8Qh%VdOdB_O
z99q`3<VFdYIS6eAg%=7jzU<QJ%^ajg!w*1RNr%6M{78pfGbTZY&(Zvm7v@2-Crmq*
z?$rm}Hd<Q02l1=5YO`9NgM5QEs^2^w=9AblUCd$emmM`j$$F5ZX?u=^=Q=pJW5LP%
zq}rbK{2g1*wO$8JeLT)PXhO)~iFK&AN7<Ziz|Kn>0fR*vbX&oE(kXtU`{MkvQv61b
z^#bJICH_9lJ6+ve9il37_uv(12d=?>&#4#Yo1GIGyGG(0T7Y=I(Bj!<{hS&sW+qdz
zfDSF^Tj4gpm)QK;@YgtL#+{ywRzoEq<oPVyKCC}Zt<UJV>VYrmO+qWj#jlw!2<xC+
zTdP&(99X9}S~&m+$1CHkz??G80c__P)3!xw|76}VeYLA{_+Y)kbuatyrKlI-N6?2{
zk5cA+S-5@eq#du4@u8?wo3;UI4yHy&2U3H(pml;6G(Kp@L0ky(8SgOs)wIo6d0%zf
zuVWHxkUQ#)(Q56^N<*8;)|YM2;f+;mZNfJq+{muk*+HkB2sg4)b~fXW!5I>*KknDq
zb;m?47^NmgAa6mIG{SOrHeG8r4$CUX_7}@o?+ug}v37CGX4`M@GV|qq6$bj{^>}tY
zm70T0K{jdnkojCLGDQ%;{%2clGHsJxs5HvZqU<Xih9YEM8_D3wcvqV?I&QpcOn!o#
z=Ava?XYz;*>ow^LOH+#>3^eT)lQuS-_3QI?S8H3h*dl}Zm0{a$KS;q&+umg1M$%gJ
z+p!<xrZRnJVQJp9AL~El`9(`S!iK$}xw+`l(b5(BXvF4^mF)DLd85A9amMhR8$MW{
zpRXF7Bg6ItxGiW>wgtm(cfxEkUw+>YeL7dS!*k_*x&~$&%=zo%{DE?+Hp3OMhQAzR
zcR~2)P_-f34u^#wzS8n9%EA|8jQ@c%#=o!Yv=(vKWnnFW{hVu*@85^~$oJdK`-VT}
zC&oDmmWC(B!GEE=gu*wx9*mEHl0I}2x~|yeZqL=f47Jy?Yi)NvdllM?^VF+tzo<U!
zHSjN|4`Z4?vT0s`zNDV(b@1!6yq;_MmXY2*p2};v8e+U`0Zy%JfDz^UrIHll_|dnz
zhPc@7TfD*6Z`jU}MvpdHuk9ONs)>@xjAf%w%W<v*qXUPu<CS~m7?F+Y0Z4D4(OYA2
zvTK8b5Q5vSilSk_^|dEKhmoC~Uk3g8dqLbM>%cgFvqKx50cEw_CsR6nE7C1Thbl*N
zpI#nEj=ne~`x)*<e#bp{?A${}Ug^+CsW6I_p`%WN-o=5S%^5!lG4W53KBf*uA5Yc_
z@&7GUzRp}`{(C<1p#HHwXK3gO_`AKqxk|aVw6L>LUs^Em7X!W_1RpG8w{C8*JU2Im
zDL`qBJg>*gm!~V3KkR(;`$)UVOMy~BfOb=(a>&dFuSZxf=I<Kid=siU3g3Sh!nfOf
z#tnGC$<q=+&-F&NdD!5$5iQv-bB8DNjqB!<??!xmM!b?MU8Tn-GkGxF$*qQ^$A_Wq
zbnX2P<P}|eH!Qz-yHn2c{3d<`oDiQelq_{ipl<Jtlqu`_==d~sGi&~680yw$9i^)=
zlUjX<&wU}%?K`FHl2ziE_1^mdQ@ukgzl-Iw7P}a&F3Qq<bjk#{`KpOZl;_H3FP~)@
zShKM--SqAee)e$n$|uq%$J?~#29NAIV?Axg<_Cdemp3fCqQ&7NYGm5!1Gb%JWz0W2
z$(mrNDxUtF9jPX?lGiTDK9n=Q4Y0pWauj-W9oC`Xdt&#r5&s;YoOh|e;_Bcdz~{8E
z{wB26`rphSxL@{R;2-ci+emiaW7x^^4$2eP+CJj?k7Mo6;MWK1>k|8-RISa{p+Lmy
z5-M!$D1?E2e}B~G#X0wM$R@OF*5~2!q&D++JPjH2;=_O?>-#B-BjqPpP$d;V^WTQJ
zT4^&1S&Ukquy+=3?vHlYGUUrKlj!Dpgu1F7p?S>Aqojeq2L9npQM9E2hH;K%JwI*h
z`6Qdq0}|$MDNVBrH66zX^i+1cX@06Sz0@epmk(+962jN`;d9d^DjF8BY85==WWG`n
z*$-8~sH+RKeiE_?!_Xh(3mx8um7f7_(C5YXTePJg247%%e9pE9*FcnwJ}d3P_7b}g
zcav-eYyZ;1(iHUMt!&!~6uPHgDrOGIjaju6UL+prtpoe@VVUfN>l|%`M}*#<6p#C2
zsgy4kGlQ_5SsbZCp8!jX!_m$>P9&-GX}X^U+Zvru4KH4*EiG0=@5TOzX+NvGFT;lJ
zU^@xD))I<R{W4dY@$?1sv#b04lJ>hJvuc`d>}#nE^cBR5%0TPFb4PTqKds}%tWBVj
zx8u_6^+WA%{bsKp+XB{qv*0x0`;E<i&i8*=!iQ3~SsByr`;TdQv(GT(`^`SXZNA^`
zGx&bH&*1y#CI6i7H~S2E-)6w<F$~|P<^7YyhrS>9aLvbg<BI|_;|X?u%dYvhVcb)X
z|5c=+9)D~Id-7v@21A?jVW6d_WH-+sQTA$MKNB6t@dFsSJuB3g(^FcvCqriF^5#@m
z<LhP#?*<&>;Lc{<*fS8e0kC4V2@{4u7ubV+f<2D^a`^W;{!I+0;>Lkp!#ELGFXIi?
zmugKarvklJALGWrw*!tH$GKD!+dETBvi_wEyAj=T6T=)`66cwI?_gnn{U8)>GxdWO
z7s3a;=_#wLf|aVNR}bns;<SsxDP!fl{e|XCrnazT);Waj5m<JqNuZ^3!fzM2*v85{
z^>y2yT(iPfEcp$Gj`n-pIL{X+a+&er>~7PSE(HD9M(-?iFuyd{tWF(nR!ZdB4k?5K
zkc-(TCLKTMlppMyv~U`mnb~1%2}O=~*?ISGCBKF6+~@Rrmk0AJTE3NGTQfs7u<7T|
zOS>H04?|I3pSi&+YtQ;N8DB%Z3%vzl)((%BeW`Ct9)X=M&tyY`Sf8dmXL0y0U|rt)
zl*01phZSgtf0ek5Pn~ngvU}neElTG0_TjdVlF0LWPM(x4V^%{>Cq=AZkk56tP0czf
ztT%tH)I)VdqJsBsi=SIu8@ruQKjh6`P&<RWmMFmF*ir7?sUFv(?Xzu9+6Q-u-LrR;
zZOM9nKV0v)oo`ng+CCg5Q<gc3{Kx~Zw)r0m=RdZ2%l4FMNO=`}88>F0h0$#>GhiZ{
zcU#7<+A=7Ua!tiKlx6?W!rvhIJ=}F@Y~TA@T0zIxMV`QV^f-D++7+>{{!`k?Hx3<z
z=1|5K`4aYksNMJXVF-i08DXPUD)b#5wt;&HW`m_zoiaKZ#_xe{2j+00y`!GUejejN
zKh&72HX&FYo`8Y4HHb6${1`a)V*h7u*4Qck$hJ56V@&@Y*M6S;4pArh6RA5#GuMf<
z+-~i6?g?IocpP6nvaj25&H~=)-vIyJKUbemw_2f|bVrM2sq9@Up7$j@oC`4h`%|go
z!sM`HQ)v2jaiMJas0YEL+v9-&)Th%O!@12PbwF)Dv(C^JZi&LWz1-F)Y=f8Ui^6)m
z-1Sk|CNH<mg>6I`y&joAG=yey_V<7Kobw!<ld<<z**9qB2Ksl<KNR?}2Ugja4*WOM
zKOFd>FRbj_8Tbe2FBm`Z81m8v1E>BY-cY00@-?<c4*t!Ke-HdB2Qd70__sRY`{Cc_
z_^~(DxWVxsg6{N?<3Hl%r(OTEz5I;pf1a10a{Vvy@{0>j`uh;>`d^RmsuTV;<mdX|
z>*cq*{e8ceztQ!7!pm=V>;C}!ZvDRizgzzY;dkr*E%^JK^1l!N^^X5XUcRdM{tsz4
zF+A5Sln<y}_>jQD_G5B}Cox*tSB4Rn_7&pYm%!PbUc*B;Hr_`6=D>eH{aXV61N3hV
z{14LK7x=$V|Mh|2OTuq$h?svj{Wk>RJ@ju6{Jr$w82J0?M{CNQiS#+~8@mwZcf0tF
zT?qXP;@|4WKO+7<-~T-EUoU>1bMrbTWye#GFZpeQp!+&a7)M$I%72}=U*9=YnOfSX
zVBb#SZJnbyHZstF(tm%k9`q4u{Jl=taHBrYP|fdt3G?R{lT`Z%X+IGT*W^bjr*wcv
z^F9WBHhGsvlqi>%z$F^x0m!q9r7h;X&2i#jE~nnRA9?G21<e0}&Qi$m#XZOJfs@$d
zYBP)fA`chj(#M(Wbq|Z@(|tWz>k$W;Ll)2$?9&Ua{Y%XJdcyWEDi50TE>B*nTbm7Y
z4z5v|$GE=-eZf83E~lTD-$QBF!r_TC_87+UEp<|JCeP{WoJkpwcZRs~r+fbe^@uao
z1A3;(yn_yv#`Rti(&077q4Dif&E;u)JMwO~2DJM`wRx<qVvOBz0>}wLK9tvEXrR43
zF8Gz&ha*q!m11m%?{fox<I_g}7Seqk$6n7YJzFE8WMkvC4t+%$zaKQNx~;PT!%@>x
zd0|0R`Q(+lr^~a+@;Lf2%7r>s5Qei2MsC_D5k(OpJg^6T*rnC6do_YH9zJY^w{xyO
zWr3C-GVV&qAaab$fvxhg*lM-&2I6#aZ526(!1{E{8cPF=j)F?14W3#1ktP!0d%Raf
zAAda`?s?OTx^ozz365*pBlCQEVEq-g(PUYavE6%XzTm~uMSF@tkDZJh%ezu^Op=aR
zSDu&G$FHl^lD3kFTkW=ygpN4oIVW?>>v=}r<)#nT@)7+;yuN?gaaya-!dO0Ln1%v;
zy1oSElMar69`6Y6FB*HJ0uG$e%*Y&2jq1<Gs*BTc8;k<)w`TX@EKsx^CmhebE5Lv3
zc;;RsagqlxSx;fTr+8j%b&j-i#SICv2H~F0Wys5)tD4+7GU$n1fv_&v%q>ovF|iRT
z*Lag{&*$hFseGCC%YhB!`rzD^2Kj3ZtY7p@R=z^DOXMuqg+VxMFFBcFm21y>aV^pl
z*rYkh&6s5PMnBw59_ULik2$x+J#mgZ-tR_UH9ODk$74rb*fdP-2qk^?TKa6G^U>{!
z`uxINrCG^N-2rKloC>>BTg*sUHj2>Qj-=&#()V(X9+sAN{buEQ(j~N?zAR3E7yVWi
zr@xziD~r>=fqpBC)89kCmBs1bM8B2A>F=fA%Hs5Ir{Bur^!L+mWpVmP=(n;s{W<!r
zEKdI(@f%s3{@cZGWO4fUi{HrN^e>3t$l~-L62FnfuYmuEm%);DU!|c<WBL1K7z;<-
zH6Q#~;{|Iz__4+d)_m||jTfx>;J?pZ^TCfbUa;naA8Wi|%?Cf$c)^+v{`=iEAN*M3
z1#3R|xyJL?eDHIP=dbzTe-M6u%?Cf%c>bCXey;KSH6Q#~<H?$jypMb0SE7CN*`&6Y
zVMb%fF^-FY3Ykw5yxzSlD&X}e&O`OgHgTbj?`q&h9UsTfM&$n(2Tw0i+BKdXpUjRz
zQ;O4%cD)cee!grJU@rS{a!&lug*SF}UuDbS-C-QVyi<&GOkgXSkni2!9g;T|L+7l3
zD`bv(=<W={y1eNbd!vT%IqKopc=398>d@E6=+Mc3w*n{V*F_=M<~)Is9NNrY4p`bi
z=Xm0Xk+}cxVin?2SdKAamdD#YAzfdX`zM0+h0!;g^#$9o&$gk;o!j8|AJmf%=gXwm
zwekjpVgD_T(jKw-lIzbT=xMuy2jqph&?3QKB^dg{ut{F;#1Hl#U?u%?@Nd$UX<IY`
z+Jbb?{b<s?&NsX#DLUUM%$;v;Mm*9gX@d3R9h>_2<I(ASSK4yG{Tvruvy#?~etMkd
zf<m+Z1st)LP_E6);h3}0zrPbOmaBBMSNhb~IpizT=6nb98<zBz3EL2!p#m2M%6!6?
ze-OvG`#{JOSV!I|tq=O}5!pu}%??M}GTpA66S(ifU8`Vhw7b8=j9F*-=k|{Smi`HB
z$UM*RDs$h(2=LT#w#&hpw8bY#hx;!OZtUY*_e{7CHVcgtRu#0YnJLwl=H?cfxERJ_
z)jopYr|UZ2xfNa4v3;|EyEJnmdh%P5M%Ndl@dWz+34rP2)40=E%eNu+7Lb_k5c=f}
zA)fBjuN;pd?QTT8&fwmTkZzhZ-xY*~XrB81?jTGVt0U{0I}31o59DvT0ZGCpP`92S
zT?RX(jd>A-&DkjOq)Dg#FA3BCvUhcG{B$6F!AXDF^16@BH%enJtNYk|BYMA$yu0jV
zZ2D>0C_-1{kJR-T`x!l(KO?rz=1hL&5M^@G*j~gVjq&|9`+hTYiAmI(JobrzS*v@<
z>`T1$h8AexIJh&#j>Z6v;vqB6hG=8}S60<p`V%x#n^CBhGdH5VF3()?!j9Bnr7I1S
z1rpLMYlDO_IR}+|8!~SV1?nyj0<#sFs@2voJ>pZnq2L`m(jyL8at-YQ`dbp9C^>7}
zi8d~wef5E@-p_sJM)}(9PQJ?5-W}=}zZU;T#xB>-Q^3(}Db@WG-s55GuRJgI5^eMk
zaq^EDB5@&Tbmh0a7ct6jbzVLZ9$Q9w<*^)VJ?KD=HQF|<!djt%aDDnwL%*dh$1@ZX
zfdW5{!C9o`cqDC;ckgrZ@_BbF^_qH{@z@%QyxZ^_lS1t7m)A74iGrLBACdd1aJO8W
z{qDt5aX(A~IjRk+4#4JN=H?pe%YNdR=bQlUlbgdyjs5jGxidz2@_wgX9=$wI-m+PW
zT$U$q*$gaHmpZR`JGxZ%a~*IabDF++vc?0J(4SZ9Q%kd^cJiwA>ZYvUfp&7&M+-=+
zI?6@7x6@IQCJrE6d34i%H|=#8ezpl|<q+QW@oA+^$GHU4CW_$y%9GevikwpT#qKBB
zvkYugv$jfjPeuLj2=O=^(XCD!!2#{BG}YxT_=C@Al#JZ|6r}IQTGOXgJ1>zAHz?dc
z^=tI>3uti4M(Z(OfJS7UT!5UT`&my%p1zJSW<QI4*9rULXE=Qac_zv;9@ZRlGCb{w
z)ZN%u)P$b8lh1N+B0b67h;f@%$GHzNE{S^wBKweS#?kdmlu4S0+~uuVY2=c-0VDnE
z*#C70ugi}!_IpoY?DvAwS>|ura`=87@L`!UW`z#{A;4;uzLtn?j9njPrcQ5Rezs<>
zs<SjiIOuM;-Z)rp%y2zi_HC0G1|7#>xd~ev+^R*Te5%nX9~RzfXzCu@F85j-$!94)
z{I=5;Slc;l)r@clAmcfxPeSg&)w95)an_09#0Ob>FR*3)t}T=8(t{A*A*!^_bZvOP
zYw>B2aUsCw4%DGlz6zZrjOsItQN^BZeR1bDg24VzCMb$yQ*`{~--<iOt+WUJNqaA{
z^?k9eueQw#;s1R&H||SqT+v^nJ*F&OFi(87!@mH4JcqC@+|jhp-i=7v=Osw*^99*E
z2(VW<h;g6=mfO-$Whwto!n%^)E2R8HcQ3rQPEx-l>c_K}onH6K`w#~-;hxN7KeU|H
zq}=;z#3h~}ald^w!p}b6#j)V@Iq4&ylZ5wLq;=co^@5v~Wh7m)`;P(BIqdO%ek<0Q
zGK~z;fqdO^NROxCECS>7!p2|w?X8jW-WKwkwLbA-+jw0G?;V0qqMP}dwlaBk3N2uM
zwfMMoV4Ya^SNpgoyLs31nxxQvH|+zM*A+s;s+VDbd`iW%HO|C~KknF`0i78fZo=KF
zS}*E-SSH7m@*Xo54Q-BF8hZ=yfaMo%-`p>IwQm=Hq4MM<h<<ht_C0`+=FFYNW`6si
zz^JD(d#x<%&jDjudIpa;()|VCZhPDhKgTQQst@B`p9p<DV&j!%e?-ecy9Bs&cpn8^
z@g;3shW2_U;wX&mCvb$h={|*Ytn<h4ukB0wV@hX#3D^#=6C*R)my6Ar9Xl#|*(nFm
zr0?rTAi5Vkp80;-=6eO?0E&)mN5zBXuz%UE#P?V5zpZ_FQ{|b`G*nAcoO*0&B1clk
z$R7SI@?qJ3W6S3I=lG6s$GTt2XnYX=V&H|ML+30%2{`e*75^^<eNjIE`pp*yOM@f3
z3dLQZaicRZu*p0$joCs0x55l(ZCKLA&*t+JIdGREZjE7^FkOcUn;6fGXP6SV%9JJw
zX?y3N$<w4u50!A^3?fL_3X?7~I-1^@8s%L@Ixls2?8m^r())Y(cR)@>-9%^c1^6Xr
zIj&&EKlB?k7Oa;8)xI-x?8|MwYypnbFT>CFl)DWK{}Vm5;UT7-??pVuku#K**D<~2
z6Cw{jX!BW(Ha7jzan9EOBW-|A{PF)Jz;yl2KKwg49DMcuh5vX4?D#i*io3%0fdN?g
zf-v5*bErDMG;f1A_n31r152~Gx|(s>ZoQIQ!utmDRo-(iaNB|L4cwF8vgI)v#y9$I
zFguh+zveUJa`)y$1cqj0zHdSvY`5<qz0sLQ#}e9Kx<6ma<+Fph=dqMa<x^wn;4<W8
zBA^sA&e(PwzijvQwoUo|JqvFmkMP#*(IMOhiJL8rJmNx-JK93Vj-5}X@2C%8-Hd%$
z!sEJ)WgT^JIEMFYfREd@{{a~1)gH76`x)7w?K{p<-jsts{w!3B>@T>sKn=cv;}0!P
zVsj1}WIwj@u}Ghp76|vP<eBWQvTl}^|J%ObW@+z7@O%EeV)mYY3|O}hGyBi~1K926
zj-*_<xnGPXNRNasz;=3m9@`@{D?p#d(fm)OoPa)iQ7UPQGA|gt{~X~+|G8-@(Y=5i
z+3)N_i~;c_Q4Y_^#k8edcH!KF6ZmZ#u0&d;(N4ajJ#{Z|mEb=-hx@Q({-(dn8xTLs
zOQMdeC5|A%F&N};`YrIIJe5<~Ms(`$LLMrs5zeMN9k4bs3r2%KERd@iYikjo^=R#*
zq_@W6NExjMxf^-P@Y3#X_ML@8#%WED1c<|jZO-`Yfpy4JX|0DK(8>(%-*UgPa2Dbu
zte!Y)@BTPjVA%!HFgZLCvo1FbYz934vvOSrlqKH;eepjb>3|CU+3)M|&+(lAKI}6i
zOM5HN1swC7wHYKoWLp(ofNe8VfAS^et?UQZQDwRF;g28trJcCIJvBZwns(V#1nBq8
zMaYMJ<MI`r_h4Id{-Bd*b;7#<arvkWX>6HPKD0I@h!e<+W*n1_dtetbR++Ci4rd!s
z!r{J2>;uRt9P@1lv|I90n?K9wh0gAHytaiN99^5sH<Olc_8{NO;Lv3vYq4&I=LS3#
zO&;R0`*Fs^&FhG5n=61T)64vd^?}Z>ZaZ>bez&#zx?JiOZY$!G^ad(0BobrveK;0P
z{`P3Z?TGNgD*+4I)!5_w0OfD+MrXJ`%yi#}zX$gp)u(ZBv$LDPuuG7Blb@%t-{Cxh
zyN#Q3#r;dQI}7X$UL@@6xJLZ=#=d7G@Xh(KZGtQF*yF=)5E$d#?!&hGu$h*!w)%IO
zZUTP${WLd9nrqM*5BT37foYB%lN=Yl$y^=in!57xzI+|u4Zu`j<6MROwkQ4e_U}!9
z4B+n#;C}hU`Tk@94Tl9bu4N>DgHAAc4dUzbi6m(<%-=|ZQCiS>XPxB}S0fMdiR<v+
zMy{|tK?Gv(1PVuTc`gC{<fB6CXls||xMt-;zQFZ>Ji;?z6Nj=mu5Xh)f4%D>${V6f
zt+p2|w6YJhGkGla5Pc{stcO58wjUTqtq^IDuehU|dJS{j)pAq~!#&-;&V#%S`iJE8
zl3r?t`b6<JebI{Cv7_9l^452FpOH2?cJxf-b{_K5brA8RJz)=Eu(anlSa`=yX%^=?
z@Wqw}#w5O`fIZ^!oOjkas}h$X-d%oT=9lyy3s_w)U92}Ak3Kr<oDPXsGS_L84$PWw
zeDEVcrRll)A}@%Ra?eg|Mp{15h*qYDDsw};Dg$Bnh^(OfW#S-Kq>8Qm7KIE{o3Zyq
z2)sYqTm8`jgyvRq7V{=>$Ghq0?Z7#l(v-sfV;EK!DAn)}Q@z1@{m!aRoWe&rN0SGW
zH<C7a2gnXYhAq-@>nO8j7=fjm<4{LCa$S77cSZ6BgNSz{{x^8C4)=SJ%W(DRx>(mo
zTY)Ec7Oeq}@WgEbn+U;f6xc|4F(6&(L*Dmsvn`uBok;zD5q;>+N4H1jwnJ;ebK8BZ
zjGz2f`^ZfXVhGKR4@C0ofqxnO2b-E&%IXX|Qd-`4we7zHIwLLhOS}2JTX@HrfZeWh
zTRONUc>p%cciQ<cg*d?+Vq}j2z#d$qd6{{02(TmTi*t*Gxw_ITWtk)AYCJPPrV;Pi
zKFrL4GT)u2@t}&&;`#^B8}S}S{M-GoV17Ju9?D7|S}4~zxtKyZzwqw15v0-Q+2^(D
z{BCWp-zni*rdp}dY*tHkv1yiOZGqa>1&*9UZbf-?@;EY`%Gumwr0mK#X8mU5?-lqS
zl)~@Dyb`&~?}TOAEb=8y<?v4$OM+%pj$@f)aMV{kf&X}3X=!3q{NX$O#sy}~gV_E(
zh@Y_cszNfDtM4<si0~xV0Ju!UT*7O46xRUgHOlt>(Lv_Jb%2HYGC$#Yz&q`lfh!93
zJJ<Wfo9jN#?Yu|12){lneR;qA+|G8LKpM)TD(~-xKdxQ&*u2}=qw<?Xsp8-WWdG1H
zzg9RnJj=Ze`B6@2Eh|`?;jTAX?-UT1a?D=*<InpQ{Qu1M5BrkqEIDPFGxs(d9@2VO
zL$?>ctATCHxH!MF$QiS`h^sH8TTK5ktj8<j69$!L#;(<<2i+v)K^1LnBA5?#n!Vm=
zxwdZ!msBaM4)$%gt4*aC02%l*k)|JKiWV^kA9l`<Z$!Dc|92X5e5N*2@$bYUe3W-F
z&-J#po3jRCADs?*coN!4pPa`pnVei7k-kV9?4vT?{c(bIhmMoDFr^ihL#L3I{Wpz&
z>2Ju4ZeA)+#(jI~iAX~^vxv6hD42zxW0Nx0PP}^}|D5ja!u#>$sWZ_}zbf&f42&|=
zszeE4ceU^_Ph_qcgoS0UvlA7-_(WwX^3K(e0ruN)M+Rukol{Z^G~k`?z5v_eVmP)(
zhm_pm-2wkVdtS}C&)4|-)1MCs%Hf!tLtd&o<2(7S@`W1wI#wAr4@Z7k=RaS;j|f-&
z@{{rI@|6bsap@Or`qnUHDt*p$h7T+tF6pSre*`bZ<>`zAt&`I5A;kA_2MsIkEIS&e
zcqt7Zwq-v>%LEO(c_|IQ$kJvY|Ks~BNE7Y|LvIHG7unwL4?}BD1w2e^9SO!g5&8aU
zh{q>NlcW*S<kM}qLz7|DR7CP|3eyPFtr5CNcC(I#UJ~-Ieg90var^#R@N54v%@N`N
z+W9s9<7o|Z=Kyn-)lH}Rpw@KA%+ieL%HaKVltEhg4f}t${r^q;lRlWQ(g(kt>z4!i
zXp3Kj#yXKs+k|yzn-I5qZGOLve|ao!!?M;olC)6!2aD9EGg#gGqgn&{-L<)kv(n)^
zK!>Z>d)_lpHrJrf#=qaC!ZSPM8`NPsJ6patO@!_WB7--cE#EC>wGZxB+mD2NQyI2n
zGNW+~`W%#TA~gCu+a6IGr3}xt)AMb(L!$vUq)*=$(B^UEf82Romzxzu{1;!4mUQsD
zC{uYK-|uyJ-wWYaT4UJn!I6Gn#DBhm_Yto2{}Q~r^#A+t$EAO%O&=E)rSYI#6zI}8
z_~DC@5BcKD@Q*+5<@DqK75Hz-J3_n6SLy#gy!+*V{<VJ0BO0c-D}Ve$mWje&rDcLY
zx_K#GKDUKGc6zTw8Zsf%NrpH60bs%#4N&IbR|6KN*Nz0^oe0gn2J!gB(cEdExj(Yu
z4$TE9DNl^h&G_>3F3!o950`3{gQYpM-RWl&39ytX>zvmC52ZuCyL9-+@N0iE?DcS@
z!#D7sub@N1l@8y8cb5*|41Zkux7hTpVaPNx2fq<<+0Sp~KZ4&DmuG~=h?COTpWxlc
z9W<u6v+QV?;-xh9PL_$X-=$@O#@xJ=#$Ib_jPytOkaFMK@h%-2X?vp=Ta|bR!VSGe
zBN(0AyAd9xJ*GJk+ItV;@rlwN>4$Ujdu@1>_M(`a2>t9tUP?cFcj@Q-@M|A4?0s;g
zpFiV2UqL^FEB$-`?=Jm(5dOII_uKTXVXgCcP%a9L@UcHfKJ4GWz(4-H57CeR596PC
zGcBDwjt-%v+z9<Kjnd!8Z5~p0(4W?wc|^msUP^zTKw9GWN&HKhpg-oVc`5zH>3~0i
zc%(n8h!P#}M*%zDnuY6<k0GAWrcF#8@LvKJrANj)5qkU-;_->nqt3s7Wy2%%xU3GX
z%{?aV?`Y&=WMY{+9wFh79zP9Slpa5W_cicQkMjWDFEiDUbCg_ze^&4owws-exi*q_
z$KDFr3tgD}oWwO5Kt~$IGsUqNkD>&L{N>`oy-S|wBp!cz0(jhE@%TFjj|*WB9E(W&
zHB2WGRq)(m@iKe3^E1^&bAJ^5u=fr5ySxM9r=AdFFZuTle%J?Txnr8T`h=I0x$7Sg
zm;G~H?7T?wkz3tm8S49_pOf8RVp_4=NXWbP`9A{g@}RH4uj8F*z6|HVuJNDvkB71x
z;X2;Gig!OAaC74^Z<fjYNK1_OFL2x>P~OC_-cVSO2g4}iw@XLf<(KW`xt#p(w@Xz1
z4+luUN;`lD1!W{W<w2iApHu$-BJhK3?mdWqKMO1W|1)3_9^!osu>Ix5{c_*BjrVmo
z-s3&)H+h6jRd8StHk<T+1Aei<hi+2+jq<@#06W|JCgSk9D?kML>xB0$z=L(f*@<u4
zcv1dDy5joaJ2ss3w!x_t=SM$lv=GNSR+~vvs{Y0gvEz+(@}lpeJf+L;;hnS|J}($|
zPeAMaxf_9s+`;SfC|tm6b@~4$`7Zb&h7lb*`Xtna_Cx=UaDDK7Xv+hB{(IBO%eao^
zH~@c?@yvcvS%UBPA_VOqc3b}eztA7zGwc`~$KikS9}nA$aBZ(2;@us`{{??s`XAZ!
ztzpR2l||wG0pfCu{n-BhH~u;PS+0)%pW@xe57;Pv%s(2YWy^ezeE-Mh`!oF4EDz;)
z$ILkay(~_><9kmtVjd>@Fh>zaIu3=PUnzh71Yu@{?^CE5;S!$o9zwV~7Re)4fz~~9
zK!}B+`ms64L@LUIaMr>jc$SBAlEr&Bm+$nGrxDlsaHB#yHkOBhl1#>w=P$RTJSiL?
z<tcp(L9Y_%DHC2N^5tDb)<(C4uWFZ4lc~%ozs_6Qvz>Q#T3g*n7(TO&dutd58>ZH<
zzAa*N3tQbtSZZ>Q%@gx`BrH8X42#g6HXQc4k#MB7Wnv$tHSGG$V!shz7kuu0yeK&F
z+)=om<7xdicxzo4X1)tgUO<~*?$dFOUWvAI^2v;5it<tO-F;Cgx&Uc8mYI%Y8AC?=
zOV+<e#<n?6V$Ssi-%(|npwD1$hjKZd*5IGK?w;6r-P{+rRI9>-zqG$nUMS%jftwE0
zt25V_AY98<Y2f=)uyLs9Wm|FtW|H?U^PYi7;{HAM3-WO(`|+UPh}T-;h57rHp?md9
z<D)xEGY1E`QD*j8xUURaU#e9OE#L|!SUUy#G8j|1;Ig(j$6J{k_y!N3<7iZHPl~y_
zll!kd9=}rJ6TOTh!Z!&Vwj8`u*XF^tq%D~-6oOTUoXiVsoNynq$!ifPIcfR<KXfQx
zG0_7&M}SZIP_=1q*6_>5zRrR<t)(GBnmq`U?JOD=;yV9oE!fw(9p|<E<A9(U@&wY$
zew_c1GlYI%klzCH!;B9*nzVnWz@}w=4|ydy2ZkH0o7lO6B^W=F7xWe9kEh6-++t@^
z7|iC<=2P9~+YC{g1lbKU`)zT@r`%v1po->Z#s%$DK?+HG=n@!1I=~o}vw;guF%JOc
zsaNQXV`&}eOvlm-@U2)g?k9_-^jHof(ef?$$0tTdQD4KW;Lj*;;(MPxH-PuNd0*l2
zeY?O{@_lfxyszRrEWOh<uP*urz_6@;wS?Q<JPSLGuyj73%^Q49mo)rbv%v@Vw-rm1
zseC2{=7c^Yj%N@yF^)?acFT9R30q6pP<jx@&_^|1H({C0g4<b=1|FNoI^*~G;n~LD
zr{U`*t*PTVCQR->W?AP-Sb)!YCL92R-v;_8v-sMw@jr_Gk$k!^G3wXhe8O^Q8jH^b
z^cPaY=~O<SvVC(QVS@(1axbDE2RZUX>EX<HdPvh=O!#Py4K3|+iSh3yfaxx$-(J~I
z|D);8;97I1{3{5XP@uuPpD_K-o2^TVuz}I+fb|d1kAl*vF)3@%__O)c&a~n;6vV-S
zlkC8)xNcCx(i%Sqkva?$&T=C0cM?80EM<+z`)C0TEon0JPp0z)++~RDELNs251q;U
z05Zr+e6L&L4;DduY!|Nwey9Dtex})*PY;{?lSjNGfS@DO`AIZC(<F~P^blbFnHj>Q
zEDIS+6?P%2lqc}w-dvhMwBNXuaW=|`Hg|*4K9J)!Y_{dH3BwE5BM!dN%)NHIo6mD`
ztIp}Ob1#iCF>KP~6JuN=?C!H3FbB**MixE`amXjgBa}~Y555C-gy$kmAIR%1oXM;^
zTEN14R0ifecP8_Ju5N?PZ=J34qr?wZi~E}>b2BbwZrU+Y&vBuRPaH7U71G69$8x3N
z(QK-SPd3=n!$2vU^Xo-O>&onxz~6!sWd0soMoSp*eFx+~KC*|4{|gWo6yjZK|2N`a
z=W><VF9*!8Gjw!XXXYOYLrt}8mDwL{^SuK9E%-QVa0$cQ9h3v4FgfsPO&8Qd+eP&T
zy@<~|9s>s<Bb<lLKQ2tpC?bvYYc!qBQ^N2b!YhPxu-?B5G7#4pmm$wsq3ZY&ne4G#
ziS+I|glqXtfWa;zMp8R|rc8eo($7@zS&RKfS8z4_SQYzz=HIB`lc@L}Ipbdge|52R
zpgaeYJ@9pfDPBEO{G6(RUyHaf&yjT3nfFrJd=<S^$M-ClmT;SY33inw#1F-x4uWzV
zT5iFXmv}7Flu9$RbInr7j28JNdL=AsKihfES>9}NGs5(N%=z#djf#w)LpJ9Ahwx#q
zxVMl?<1}Qz+Y<`oe3ahf&mT#JkKu#a<gIpI>QFf2kK?$Tg?B0(hv9Z&;$V3zd>9T<
zV&0PIc3xhoVP@KrIX$d9IoZ3Gtc{gkw1jdf!*UK-<K4P6zhLaP*q>K}pVK~$GU`_J
z4?f##8pd#R-%FlO`IP5``<#9x-;7F>zX<vCp3_Xf;fBA=_z;ew7AFdj8^(ulbP<zf
zb|OFM%K|vR5yXMX-8iov#tBFELx&rdPY-1vvq+%ri%vIuAiWbAK?1~-FeJwdWsY6p
z#?fFDATj(tb#O?J4{0<v&MG&bP+5c7u^i-!@nS(`7@Q*u>Lg!t8y!WFPDCSvtajr$
z<vJ0i4yU>CCJM|d1rx;~^yOYH^K>^(0hu9IKK+D=biu6Q*SO(>qp1R<Bwue~$HEzI
z934MFB*A5^8%NO40To1K-<|2kllCg?9VhXbFGflKcDr$aayW)*qqE#NlFvlW?_t}2
z>)bddSbJD-KHCjPIZh4|zTOQ7A1G!Av!k|+w0+NU<D^j&Hn45CbKNk=o0;KEdZ<nN
zo#)0iWsGBljLNBNUb=1b+~CH;I>s&UQEnI;1E{b#dumPE_Ix*vn6i!+X*iiJWLQe7
zhy&sywyX=>xadxt1kR^(*?dv!VB=lr#uHvVn8KNIpg&&BaG7WO<03a+#xBeP@{l&a
z*o|XGHV2L1eu*2FPwn>6u=)46;pneDdxvm(Ip7<Yy5Xt8!8F!2sqvlZg006!H+(Rg
z-Ic+?Y7Ah-|FUrSSS~e)wNZ97Gq{(_rgVnFzQyJ8a9oquL@ozDS5P_s(Q$FW71REr
z)zJDCZR43rXqi{Gjh9cmYpG3b<Dt>8<k$SJY8!7fohpn-pIqHG4!Pydd<us#Iqo0h
z#<OjPrS7nnbxkOIYfisk&$QRNVFffG@1VE+6K(hF+_>N>1$>MSUDy(x`99W-8_u^N
z_Z{pG`m@)KEBuXvC-3VYHiyCyghHKhrOZ&;Vv8GBh!}!OZZwq{AIlWRXl8EKfm_{p
zxrqTBEQSGkFko1RJ~s{v98K+|ToS}GG<3ZiuTU7B*i#x$O=96Z$YrOAvn>>dYu9{9
z$5=GK8$xl%GsDAJNw=9lw!3k+^$p;%2})HQ3ep~-a7;m}AGy&@huE^3F7-;99kF3X
zhx54DFr%xwDK>1Y<oWp6Fr&-5IX3KiNq0+Z*ft64j}5y)!cwteMwc`Y8+N0l8;lJz
zcXJHIh7Cx%bZpq5gbl}r8NRzSHq4Cck=QV!cge(tne(Qk-CN_secjux_;6nrHyR(l
zRe4G%oOA`U%S;-*W1BPHC#*l%0-1Z<%G@^?nL7~fe7QRSQTEoe|GdwI>oNUaE_EvQ
zEWGHw>F;vy=!YM7IKZkQ&|`0K@90N(k9$Wy{F~f6`r+?&@7RZbyL-nz{Qd47`|yw0
zJN8v?j`PV?EuU+UJ&|we{faldFu2$d{4YiLle_{h2{qqY-H!H=?;qIjE6^|BJFwqZ
zp#KQJcVNG-K>zdTx8GNw|33L1g89}N{cjV$IU7&^{o*%g)98Od{N`L5{SS)YoIj)g
z`{KV|bTe{y6m%`z8<Oo$?8NOr9G*LZ-AnRuc=w+~>DCEom<A@m@$yE$<N(mkW<TKZ
zNMrVtbgf#F!#UW55jh8YXSw-VJz!?|FZRp`YgA?rHp)1U!!d$=Kf)Hw$3zSa`+d3j
znQ&U{@evkEi@iO<{ImnkI<X)4$*Ij!rgoryXQjczx!Bg&CsskYjVB7WMx1TVN42aU
zt>!Jdtn}Mwz_yQ$i5@gC$HWeQ4|On;<B^_SrD5(muq_fEVU&4rIn7Xd9MZJFaRv?W
z@$_!YS5~cyi_|gk7qkr-o*f-(6W(dkW7g#1u3^Y?W^J@W;Klp|IENA62hC?~{e>8&
zM@S<O_@%E_O8oR5N{yq#5DEF2Tf4Bqr$NWk*$H2^S|xEO#;M9L6|<$(0OV>r4|f@S
z(wI^6>49uk;j5!?DB^K)J}*dMh2ZXO4xxRi%Nw@sd@K51_gm9|m4N!tXeq;O#0(B;
zV;`{8+uJMGvGVrl_)v5o<lDF4n=R}Q&zopeIh6y4;$BptkR6?%^qS8|zeK{JR7X?s
z3M$mp^k+EzL~$gW=iaZCp>amq&EHBllD!=p;qdGjL@3*aI8W%Ng@BbFr`)J{uLy?^
zV;^FSqCW9j84erC+O_hkFg%CF^6qTj&>-%=cFV&-G$S9cZiSa{iAV`6@I1d?&hkzR
z$1y>+4Neb-Vbv4Ve@!^7fVDqJShP}-?-}86?g*Ky!ED}ZW5QjXRwUf^p9pA@|C!<R
zY^Rc_)@=Tf@F6yq?S4t$9Zt`crL_N9VYsQ6ZL4+Ru-l+vku(vwDa*=|v^6--&ea)*
z_Ss{tG_O!Y>%6lzpmnLD?kGwfaMulT5%|!!<u`_I1(wN8_6dF+K|H{WY-niI#2Xst
z8Sho{op9>$cD3Ru-&6|5rp0rM!INWM?l8l>tmoT3T-CG5uruH6@^w+FUz0Gij1*a4
z*TSk}lW>fld<t}jyWZFqs$Y|^QLLaRxQS<IS@miXMv4=HGGQyNye47(=rLicM>FYC
zrCerDdepY3>diC^S{UranRKcvld!B=PpDqZ#3$8LS!-xZ^<ffb>#b@Vt-I>PBn~tq
zx_VUJq57~OoEkxCKIv=Kg_-ivYW{dI@}R&oP!U_W>bnF!Jet~BVm!_Y;XP2*d6{y#
zMagKQ#DSvQw1?`vB+ee(s0NM-1*qVq`Ys7mWu|Z{lUDUz5}wDrGn5^aUblFvu1mss
zXJ7^w2Kp;olZWcOB#!7{WG7mvfV87}E+^cl1cs}AOTy7<={#iiLb{}Tx2ofk@CbgY
z+mf&XrgP}DIHim7WfY$s1^sfIjM+JnGW_|LFN^~QMS0Lc5gDF&Vx;*pd=~L}*B$3v
z+TZZr*Czl*KljYIOPPc)`FShPz=k-LM?Ih!%i_+y)M(~5UoV!lVZ-?hw2-6z{MTXO
z_>>i<RLrm(fwnI?ZJ6z*37NcX*a{nl<_W=9T6k)F5EHE#%d0F*#sHeR0Nqo%Fqpyy
ziHvo8uUqgIRilL4P+Qh&8%{DR4MTk-NE%u=&4vMO6Xej^={Ah|1+CK>3zLPu#qSJ-
zadJx;oYpD~-K%NOw6Gx~1PJc<uDIaNiz`KiYH>bG(`&ohM5MoUHq32<vn|YT8RWAK
zw1e)JJ(nV0N+2F74LU)J8M2oi0g`_7o=?iUbo}lL|9S47=jBC)gP-)ndyE5_4i+>h
zhqms-6ZBM=fDk;KqOpi+Z_p87F13`h;~*!}{BES>dPMj1Nx!83q^-kVtwUj=r3MNj
z{=B!G<x_$bL!zbH3~iu!H4pC#F}T?<!eD5P`yo7Ye!@#$k2>l@`$2BH#+kvH^+VfW
zpknR=G-EH}JrVe`PqaS2%K8`#1q*XI3TIEj+QN_x`tm@m-QVqHoT5KGUte0hmKDV3
z?x!nP?%1(NQwp=kIw#*3YBX>QQ3IFxnhRl<3Gcrp)q7~`><zuw_m(+rf6V6%BJyF)
zlFOKF5Mv$1wggw9q$taWQg#?0m*R8;jXq{vhIiO-tI99wT&ClqGZOB~XDe(N)UeR5
z8F_W355pn{+)(HBRhmy~oQlKDPDiibWy3Jt7qAQ~LeBH=m|bndz*x-Yl%<i=0=V4?
zOJhY>^kw4HgK(1$6Ip32mCM;R-x{|}iD7ud89_Q32#Wt&2aY9|wB4C*9wS(*W%GN7
zWtnL5>JHLa94NU@6vU)AJB)=Qng{g5@kN~i#}~&dUNIk-Zyt~)LGr>Urbv_E6VjvE
zT$oQdK#+#yS!SN*%!t^ePs88lYz6Px9K;;KnS~rc^PZ3!IHMsbz~wXhkT30f_T!(r
zr%j%*wSgBkBCpdiU#K(=R2r#;g}Ev|^T{jI&3GTJPBqGn!)^fDrOlbCI9$QW1}5zN
zwe7=!xBLC0IUtDUbV@Dy-#==FBQbDdy@hA6kI*r+DPlXT9sfMu4WCSQFW~(e+o$As
zjK#LP&To$lz9LuHzto(mAB63xX$x48PFH4pD9XGC@u^39GSc#H@TsMJaup_F)Hm^a
z%+q%U-+U%)4esoN0WB{!G6Bek@i|v?d)b3EV{(i8=L4Ht+*ycx3iz(l!hRlHQQch+
zba7Rijq?8naB=x%6MnRrq8(~T7f9Mv`ysa5Eb9atsRR7SL;3`Y$tCM24EDoueQH>I
zT!^Jl(@$8>pg}mss>qXl)8?)}bC<qhB64QH0U*cVo>L!hC`3pDd{hs`G4@or&-r$+
zFtsdB<kMCb7cNGP5BkIQw+-h~w3LRJ8Im=Uo~EayV=fS7a>KhrVFm7@XjrG8j`tO2
zchi~>`V$%0x=vXU#DSV<5L=PCiQHIf9IG8im!V}0U>|rglg*no(keeK)GETz#&%Ja
zBYWJIM|b&g<ZkdW><okB@uKiuTs=q~R{L>O?ic`*G-Kg3KTMH_@~((o(mj^t+j36#
z<4r;?##)L>3^T=uG|9GF<Hzyy;>tr;F@nn(ejHeOV2jXc3hAr0ez;aNT$eNb@R4FM
z=dW9E54KVCP#wvp(!R%iOSbPti^sJ?F>9A>#Q7{gd}4eMM!VP^CeDy#gFD#Q`Ehop
zVOR@E8N#S6szjoO$Vr=mU?1{qKYlSaFaQnVKt8)$RFH-q*ZbkJ$tUe{jt|qmw$00Z
zRG8hs!b0Mm+Y*l#ykm2l`c5>vt3Nx>k2{=&*-i;9j%7BcM`P9_`EBsy>=_$nliL1%
zln+;Yis@0v4N>|#-;Xy8U8uqF0v{%Om(XYBCL|&Dt#w>n=*JOe0Q4us=9)a@X_kkm
zJ>?<z$=jcfe};1o)Op<S{G@jmV8fWlFS7IaGvMbu4l8KrH_}B*1-$n;ko#i-V|k}z
z8>u$0N02{m1D0==e#6ck+*9#9VaqZP&=0+Lqr!6?1Lf&Eiw(%9<~l9%{bwN$=#d-M
zCT8ln0*-}nwl;IfO7K&xjm*&vP8o}GVX)-85&7a9N4Re6aA@8k9N!e@8IT&YGJ%0j
z+9of!FOIlf6OY?Sb)Wez2IE|3_J~A>%C;w8=6p;3o<Q~PmUciyJhV{@F4i_vhXe5W
z`?Hb8=kLf%=cSdpuW;lc3^L)>nQ>t^hF5u>f<fulZXOyPUtb)A3oit35oRcK4jrJM
zB`r$QMUyA=fEF%$2>w1hbb&#9p&%0<`alZ@y>i#V%DUg|P`Ha*YLD`vZ~5V(;w9F?
z@4BzlbOw$T`2I|=5AYnc70B2|GNc>$(WIE;)Q;G1Q^>V?2KQvnOX2HDjfZ_+YUudq
zrFbtD?+th+>a@%fOzdcX199$JE)wcZyV`pYPi=B}4=wFzISw%T@x{ARu>3<9?Ph-)
z@v*)P-8)O$ea;0w{a{zfU$*-)gzW-`jqDm7vwYI09|Iqp0G#9GxhRM00<K$E;tb{Q
zz^_lI_lsY*Dh~Hze5pM7yTC!^LgM#);spEn-?O+;&L&*t>=)skV_nm~7=F?wT1wVR
z&x4=SAxA2zZ~1Bf0CmdxVm0FbCgSST8!u~~@cN>q4v=kMV)K7#tezm=2HNTwaO&z|
zQ+?>D*6~IF`(y!)VAhMt?w12+zVq8xhW;p?7)wCv0AS#h%Q@?2vsd7T52bU^Mne4X
z^^s=Jz>Q;OR_()Apv-Zn5B~su-AUY8X%19tGsdVnX4j=P-0&aPi*+Hbwe$_>>pq0>
z(eoECgrB4BW%mEo_*eX1h4=Gy9`JIRp|L{7$}6SuY@R2=tV|yXOYasw5B*vw4Y=`W
zX3V64t~L}llur$-UJkn2P#9zuHGh)wpsx*u!=l;WCx*^86qZj<W`K^QgYGsIhFr75
zmUlpJ8w$h10@X7z;zQ2}hh>W}D|2`Y$ECJ4+y0es9Ls;ie>_}+>t6C}0So7bNp(U#
zz_7b7CV=CXdA|<nd_I9W#pM$$lYF8j9-ulFNf&QKJeP;u4!_EEZ@@e0;7#~{pFakQ
zySQT_hn;-hYhd=+o3ty=3P`-M?9c?HeSzVefWSno8&1Jc-Lxgn2?!jLEChB~?%8~C
zRzTo`Suu(e`oS3ifnkx8QdxDCh2di_zKw5}g^gjtR@!|t>Y;rSv>PgD*RSNA<b~Wj
zd>i6o9_KJ;dH%$%0QNzkS5A0uaq{;28+`BWfb(Iw3s}_0mD`F_FeZ5(6_!0olZ*Za
zoY6>e;q$2MSI!OOUA*JN@UFqZ(l8XCP;My=!xjYRKCmlc$1G&w!O~b^5NkEWGJPg6
z3t&DS5+@ak1KSTQ&5A>kwcmFvFXxxYw6N_!yuHla--Ce-2g=OtHfR`nfXpp07Z2EN
z0A}Ph*6+Qxe%iN`)!B}{Xd<@ppTa?S5A`kYyJg?L4`JwAq5+lfq~Es+(D9}H70pY_
zd_VGWY2eS`CvHr)rp@@jpLpRRt{=jC96i+hJ{#tucQTVNPH2B5Jb~q)O$ouFBVk-@
zj49Z(CGLurg)>Z|GlTwk6PQ2Tl<&VD_;9?x%l>~D|1Gph<el-d!nWy05f^RBj6>r^
z0otb2y#;j+<X}CU_8R09FAW@5`jxY3Z$)}n-lPor4#3)+O*?L;O#g1Ach9E12Y&Z#
z8uNG0ru{km(X(lUDPHc`v=0KVXVX4n-b3fkSU%y$JDWzDL(46YcT$f2IMTE`oAyZw
z3(MGfpXP9Ql?GAf?19gt6FlK66Ftbtj`5_xFodjaPlxz@vVzXmoOk<6l&4R-^KQrO
zh~>_^oxs|Lyq$OBaQuG?_<&YXp%AHBKPVOT<2WWC*LnQYc=!1_=31S{-(cif4jbo*
z-oe7nuN^yZ@7fle37ad=PtBA|o6Y?efw%vb&9~eVm$JWqFZPlLhH`1#h8BB?iwOy?
zcB#Q44R>JN)_?n!8+!Yu`fi-^F!o>I_wf+6W@Q=$zcBka3D1Xd$kJowH6M=l5wM-h
zeK@B?YPTeQXOK^3EC(~dOc6pd6nd8TtO&x%%|$*5wJrFj&YAi6wZfqJT1klpp7_E^
zNvl{A!@J2+`*3tE=>S7T=-{)44zwcvJfHybER}^mgShPE&*5MBKfjr){4t;nM6&!*
z!cf@XAdPtv-skN*zvW@(WlV@A=%+UudnSA%!1%WsTl=K=p((NL*P-F~Uamh6qRm|T
z{s)u+`bI_}`nG;U-|pTOaU!l?#D82pSk9Lb7CWb5Ea;qucIjqab$v?Nk}}A@`E@m$
zu0nZGc8;aT1|T#GJwX<c4Os~r!WKXg`gaL7^BCliARHFvG=@?64>Cz8Ol>yICW6YC
zP8?V=!KBoeL13dAq_-L^Zp~VmB?vRohH)d2uZM#C5`<g%gl$PVgl+j%I9Co~TRv#p
zg|-6_QG^!%88FHuer7&31|ZU-+fUKF8TJ+A!#?;LT(n&Fuiu9bU2Z^+DP1aED2#c2
z3+dX?#dmC;te1RC5qU8U$BLf@?>Z)QkLY_y*8?!)ei!d?I7>dj)6d7zn+0-L())L$
zUxzg*@B4oM@8or7L6ZLh-j%&pt%de9?&O-g**nU+AJ|qJPTo0FnJsBJ=iP52+@G^~
zSy9i`n;@Gohn}mi+Jwt|7Mndw_;3op8P!vw4aT;<t9YJ#wfAi&Z!H@$E)>nYF6d^D
z<+I+=^4&PZ;rp>T1hJMwg!~h0qvU@e4}D-S(w;w(=8nTZpNn?p9ReRip7C;8ur^s%
zYlAtKy2ihA>Sw=G<^4TiZRE8R%-rZ6{}K7Pa@#+_@5*f~$Ccau1^%eqMwm|n&Yc3^
z09@s^e>LwdavR~tliN5ZUAgVw;BP0l9hI=K+{STt3~=&Uet*-<DT7&>77nCfEH?(*
zrc4pX1aXQGdy3S*@eYC?NV$e8+R0=m*x1WSW+$b8d-$@{mar_f<>p_wEJfbU{T0fS
z|An?B@Aex#;N3omy!&M388KE~W<1jVNqOy0{QeB?A-PrQ;mAWXm0G<q4-SR#P-)Cp
zYdEGN^BYHq1eK>2c@r1uC!w$fnq&cpu^RAOlRxS1XQVsC=Dr^Iy|l&u048T*X6NeV
zX31v0*gT9+QGrl)_qD?9sTj)KiEh?|@<SWDm$t@i%zRn>F7hPKiS=fzu&gBBRY&#^
z%4OLdfJNucPMd}{C^Ei|Jk)?e-b|!9MUKIUm!M|-V7W0<dP=2Hw{5C$-1d$`UHJ65
z#7~CfS8KCXd@%B`r0EEU)hhc?q79GsJLhY?M~8KzeuQ=7c_m$=uR=YXzA*^3bd3YH
zJ)?cEWw0H2Z!CEZ-%sZ|N<+C~W3>kUVc&iphuH^<d$`GrPh!KaibrC#?%^=VKKwGQ
z)Ezn{lg?}v+GM_dC?-z`&~{zgt!eY=u`CQB+%kJK%;ICqL}HV7zlLM4Ue3yHHn<*%
z!nYW>m#}zh{H+$AjKKRWywk$Rv)EI|SI2$p3sb(=6-jr!P1o(D!?q?29L8XnJED3a
zug8YtMit(c8Jl;1kOzfWTI7sojU7$$h<C(>VgWB%q*B&axbp~UDV#q8ITjcO+1&Jp
z*e+XpT3~>!ecz^@@%%m&3l^HF;7(8N9ou*D@wRS(oj&e9GsL6iLQiPQ_4C`-7Z=Z`
z2W=bN>wtBJZ-2xx{eI_`4lu_lDADI@S$_ZfWuXO1sX{3;;kQEzE#R!CruUQ{g7o<@
zRLiB!4&dSULJr6CpeE%wKLg__jyEX}ARk)^M|;V&{Kv!lY%Z`o`Aon#KS^T+bCY;E
zFY!BRl%0PJo}seyPw}p@smiY^8&h^Aztr$J*?9%Z^yMazon6t{2-8M@z6$%vtGzD7
z*Zj1+K*}}pGTTApXqj#t%FEqx<pz-`E{6*T-Km^>Hqz>|oSb|j^YTk|uJE85**Q7@
z!(`r-L2DtyaxA~WxQd3u>?(^p422m&WseI?PAsm_A;#je`K8A9%6zT5uyasn(8f;O
z{+AksJ#8sHf-4}g`&94=B_<41gLc#TkZo0;$5G|#B0l;Eqt?nke5{UNfHX1&&g900
zBSEu@PuQ9<5+CParF^H<3sP}h9yoAYukAzo@N6dQ)PoK@4|Ou<a$}O1YQ<&d%OP>&
z>H->+;t9^yj+1+b>|YX|z@WSk(?L7G3k-L{<TC>}*r{_=hlwj3Qh0>%56UShH9odH
zafQtnH^JZl3oOmCn?DZCEYq!Y!z`VwGBD1!G&sX~Q7Uuu6UL%h=TN~5#1i1T+N4wU
ziR6D;7#2F4czPtvKLBd+USq;R%|;VLTiG)#PdeYw9Srrxp{p#qHpdRk(3#2=KecB$
zs9WKTM7>j7UtMU&F~70FHu5~!&aqdhsib+SRN1scA`~XwVf)QZqs?T}bcE9Q&1LD>
zO*d53dqGx&(&REq2P;Exvy04j(!0nmG3~@mp${|7FLE>ntqUX{r!2<%+1KFwqP7{=
zmxN!6d?=&sh}};_W;l408l&bjy+>r}FbLU)*8m%lALUGb>qPZ^m)kP*dxV$4{|c0U
z1^y{Rnzb&v1Nu?=<-YN*4sR2}<M%m%1hmd_A1&qkz$^G{LI2WDZzIXUn;tmatoV22
zKL&Z?I~C=|P-V8fG}oLg&n;C@2i89c8oUPK`t*<ko<RMzO<Au1f9PHXe}l`FlJ5d|
zTX}w_vN(+|bNaT1UEaYQ;l|3(e3O;9^g6h7hj3}>30v>DJz>;=^vy2RWa>w%_`5og
zhGw^N59<JpST$uBiu7x7wqYyqybO&7oh91Q)OU;E-egtNbCr4j?uu@2dZ;?TDE>ag
zS?@LWO>t$k=pEe{ON08^5d5P&+AnfVdA-v%(oce`TS*@vZF9ilwIrRp(4Y*`tOj(^
z1RUQp5r#wB*@pbPyypJu;t)Q0G6(z5d9HY+&lq>Tw^)5jCEKtc+x6iaJe*-Vtlx_D
z<StdNv$i|<UdV4R$Zgl<sX3p=@q;!Ypy1sI;a#4&gVv@8qImPOD}uU@N0&#K<d>bg
zBfxu&z_YXZm08x6_30M4`G76QFZHE5ejf+ixu)Y7VO@4Ob&>B#*vyn$vnCEm>LL6X
zI$P#@lcW!H%iPyiJRo&64v*Fkk`F4ZlQ6Mv4Pad!<caD1zRfG^u*R!Nh0!{GT2n8J
zjrkx3*1o15w?ykvY#f$vbB~o5(zMbQsz+s_aMY+RU&74~E)`m@v_bsY3YW*|F!Py?
zq~mw4Nw*gXpK2LjGL}-POSe~@nd68<Jht6{z<ib?e3`O5`<3`}91S^bAmfPBpj!d;
z0~5ug<09xxpzmcFgOVN>zE`Kmm*%G`4O{k3flo~}4O8>`qtlx&ACgPngFZ5}YHp%O
z(@T9=U-YN8ywAUzKCNmHQ<(ZP&3dnv$=Uwn@KzeyAoQKdHS1D16Ztq@C}9%^X+u|;
z3%+mEBXFDzffOQE+zw4%?xjbRUvnN!qrMy?Y**Toj7a@~5FVV-S(F=U<Yba4qyj(M
zRb>_SO-9lMI-9n1=I_SZ2~hpgPs#34;)9;PE;P2n=bf6styAjA8k)h;wmjYC4dz=?
ziO?tMI*B@uJ9UQcc(LR(ovn2Mv3O>EJmcoB3=yNSE(62&*|d3^HaJ5k+twm)B|Pq6
z8@UWNXS=iZ9bZJ(tHZ$u3=NM7-g67HOEoNIF??)4Kf%HwEeM#jRIsq-G_g8%bW+wA
zU83VGB5Zi1Z^sUY`HkQdS*5XK2iCMr<&V4j)Ysn<vmY6tdboFXCCBH=3FL`+$ef<%
zUGZqhV&Fwo>MvKU>p@={er?|q4m@ebJCq1XL~|Zwq~lvzkNTyJZC)KlNBTtIV)S{*
z?jKT~M2T8<vh&!{JJ6n#s}mlUKiOSr+%7b(`_oB<Vf6tklHy(*$x&IiGa80tCmPlj
z6UM6zb-(aQz=_VsW2KQtn^Mc9S4J3h^180Q9e&i>AQ;*P4?t{x-h)hi#w6lvZz)~u
z0Sr4vEpzc+frsbf+k9AfF8&pPGv~}=eljI|s^r6XF|pxKQvzG6EiK~HBbF|Eq;9z4
z8j>q{kMsq2kABzQEJ^1p^EjAInq7x^x67MbXzYVwKE7;1*smhrZh_(QY>`Ms1eLH)
zfDdi(I2!H*OEh@QApV6OG%x}({PqKg*MoU@ZVvT0VB%pZhO;cwlG!3?lVuThg~GB6
zvTva9O<sL+*2-0kceOWNAd;GvG}r4Xj+CoRIhP`C&O1neVZ&&fTfv9AaBqG^+6)o!
zU>72GL<+gL8-2)&d=THeN$zv<+C$1wKC9zJ{UDlnS-K?OZKQ_24%G*mUsz!Th}33`
z-GTDVxH3BPJK?_qxU`Pl(#{E7+##9q4LPVjp0%Dsx~EwFHZOJ9w*+#K{@93iLElfS
z|4Zmc$g_tRoxWxJZtxC{mG7uGCMylh?LoVr4|o-uLs9sJ-a#BzHr>JY1KB0(QZ{>n
zw1W04j%Eg^_0aZHKkz3lOa1Ns!P9^j=hT~H?R}(Q9U-8PIZnC&<)vG|OM~_+O^l}U
zJE@{6rguV@ONJVO*|t1_^4XT1_$O|Qs0;D=ylvMfqk_0?@8I-e@EtF<E%-I{7Dm26
z8mxJy3Ro@Z_<cXtxf{IsW_8|-Mfx$0LjFzIk=AhL+3W3V%#M+K%$Opqk1#o7R#;kC
zs5kg^B91He_jYf3Zqbf^#vNf?5q$=#O)DQ0K8l^_MV>qdZRk3d{4`!4AZ^YuM@dE+
ze8TtH*0y7ZGSETfqfd@~&-06gqB)8lc>4|QC%O+KKIbsfG1rsy9RiGP&-J9vJx{go
zZRKfy>8C{I1EegSJMKb0EQk3&!^xlDd}CQEm$Bauz~KvL-Vy%e(LA07KgZ~}rHQ9Y
z_#Dor1akN@Eew)?FPpRN@x>(EDHzZS#~gGM!XM3^aP(V8Ei}JlM-}_F^8G1Nzk2#(
zhJk5U^DVce_v^rk^}8GYe*F?a0JO-5<Ck;hZwT%NCOQb!9ca_4A1%xLD1-a?F`3Oz
zX^Z8Zi?*Upeiz<#FJKewW7rSW&&0Mp`r|nk7uo}0RCe5J{Vay}oj|wiveg*d%3r=c
z0BtKdCZlsQc?aiYD5?w7`*E#+Gp@V6dIly$GM0ZEb>ut^8Puq%tPH?;af3fEPL_4u
zMH<@f9R$GeVV3>Z;9oaU=Vkf(J+bqNXvP=H)y7TBP}w!hgqd$^-Euke=wFT$CpT}|
z+HbY$q%-O?pXc;tKY7J6>kXx!n~}z)AI|>)pC?uDiDE1(d&9e&QDUG054$clugpa4
z&KmEd;IykA;VCV=f<;@}S9<+jr;aB^ufKd-V9Jmjo4*EJo#yG|+(mhq<5#&1VT}81
zz@{qu@QJv<UxDDruzL^&dnm{cn%knlp9?sy^%+>2ofVw{^L{>H8OzRcAR;qgCOq;K
z?DN#zJa}HTN5)WTO7l<{&NCYr=DUW-mN)~2yzyPWrq%EOhlKYc!1%#UeD6cSxQ``{
zhB9ds?#^B=K>D9D${KH7@+HVqADr8!?5UYU=g?k8A@BQrq@{eJa|^$NNg0G=q?N9N
z2~=6JMNshJ9BSm3r1x^<%lu!#{J|;t&VFQBs*~Rcr2hc0jc8MblZRhp=Rh8pA#N{&
zqqXxN%6~8iz6yT!5ywC{Zo+#lg?bx?^{mj(eN2zJ^ffl0)^rHBV~4sr&x_83B`m8K
z#>%zwKCZ1rXD5vyZ~bm48bjt4)|d5R-CmD(Z3k&{ThBiRobd!dprAM~%^PhR;!0Zb
z<2iHYwpcmU#fC^ux&Y}bog3ebe5re7-exVI?0zfDML)H+5zfdUj1Td9yN#!`a~pZS
zm0MZIdu`nrPy3bq!TjF=hYs=HCI5nh*z3F-e#PxQcqa}#rxT<x_oy+ogyG+(6P#)M
zQ=1>ddJ)EYy;EQb?|n{K7!O1YWCj@%YzyWQ?w=r!&&eE{@K|Ta<JpDriq#({qz$?V
z8^RhAwr%7y?0-Wul%*5i8{qHu_S^e@j33{IE?2P!&2Y+yJ>JwDZgUugye9nXy+|`i
zL*K>{jdun1e!%usnq!rDY;*6fHuu+;l)(v~YzepAk9_h2NIL}UFPojv><0mJ`^u*|
zR@1f-Y3?+vdH(`&^?|<886V5j+=q}ZuJ1l-^ZS^c4_*s@l<&U@Fr9xN^BD8JthYF@
ztL=R7=ML;r`wegxc9V^FzY|Ywem@LYwKm<5?U!P`fK8Zct-|lBCOq;T%nQoXtxng>
z7tlZAil>I@X3SHqbwpCzhLp8ed)FmDF8P^O#Qif--hEQCww#><Z}>Ch$-U5z+5b=A
z|7QQ3bTPZDG=)!>&5Tl)Xmn?UiA9aI+n|4;ya+W5=R?N9d0D_9uTk}4)8VWvVBD_~
zpv1#DS-@s-lU@MBIa$C0!xzmH_TYd|*CnPc2WMpgtCXjz#uj6>_!kdWXPY=vV{kdm
zfo-v{(*=ev`EE1!^R5v;Z5tcaY0Ss0!x;iw!l!-3N?z)^HWaUbkK3YIEG}nCnA{8D
znK>b<%as1o)u>Us%A61eSqbkbztf2BPd3rrpF*D$aZh_~kqLJ9nRl>eluh1Bp2l&=
z_rrKse*9^?`}__zRxZCIPh;HAz=5^;v_?9Nrqi+ZD!W$rE2a^C1kngMP=@FH+Ud3K
zr^M}@G!fVA^Esji`iA*1%<PG^?uD?7^|Bve_5sP4J_}s51^bXkynIwZ&(`*h3WJ!F
zRu4hYlyY7Q<KO}0$MNtv{8PuU3WC7j;9VcwYs7IE6iG?j_u1Z)eo1uyEz)srpuG|8
z)Ltn0PzJrgdo|wieF1aR58@N{M}YMJR=5+NTd=U#0k#RSyj(JA;{6F=y@26B1T2-z
zH`xCYFjwefdO4>6xbi^qEbfQ@Jz$(OfE?)OG!J*1PfX;(VZAGO-{%VO?kkdCKzu%5
z#6R@iCnRgO%7fBwR-@^QnvOqcyZCz!W&MXC3cION9UC6(QR&JE%r4xd50c&g2%I?{
zD7SnC??!G(h>WB%%vTu)A<LADO-kB)g$s@XZOJkwAGGDF{QA%Ev(1}u9H+83WaXxR
zK^SrS8k~oN{L1&+tns)_<L}hTo)dkbVVy%*=YL{e$qw)9{Kpf|lcY^)s}`<U2oi43
zZy`Un)wsx#QMotT$L*%1)@~>6-$CAS?ZEc>S6eRQeHZV39Whq5z21#+wiY~rZ9i98
zls#GXSDw6t2?{iB!{M)DhXT_z?nAJ!eY{Z%ERB5So5(}QO%EsxQWXAXcI=3DI`U-v
z@3o5`YD=SYHPd>@*O#z<e+$`=?b_0Zfa#q}q|a5}Q1bgIOP_>y^5cSgcft6?I*r%E
zwAs6B#V2TQhLI=xeL<wG%;NHy9PDmb$NvQ0tYiE>giAXlaiaopwm|xHZq$2}siWG6
zA}@veH{^X3?niJe>&LdNTR{_?&mp~z+pn%#IR<`oYi$}`4&5^2BpC-=NcwG7Bg+6*
z;XS|R{w&?6`zi7tqFS9g>m@reI{*wvk?FYJ<XHa(9JWin|CWCv)BXhSacxKZ3kYLd
z4L}wneSI5#XVjQ;cz{J^-hT(o)pgLXx{hObcXb-f_XmJc!>$Vf!hQ%C)(Oyw*b<?S
zC;TA;ABDgs>L@e!yZVnHKIPw&(SNYNp#Rv9Z`jUZ2>R=qey>!8^+siYAJ7F)XTD9e
z<cL?AMd$H4I-^CA`7$B(F**~AOJvTw9b|H@msp2>^pt)`J03;^btGp(N0Pw1J~=br
z+su}qw_KX<K{*^B;r{Q$>}zt~BK$KdBjzjSc3n^#SK@&e<YZ($($c-43(^Srpqbl}
z-K&r<=|$JWUGOsw>FXK?PCc)VX`e2!7CznLrR(!G@Gl`Q^)%*=h6L6$vfh@tOV_*{
zS;S*C(?e%+CjarUY_4SuPRZ`G@J>8fHskwg5()41RtKZFuSZ<1AJZJb7*-h*>*p5R
zxW5I@ac$#15C58FY~wb>*v3&8abd(ZF0P%<we@4zd3g8h!Ae`+*P1Q}Bk!Y)+6J2s
zlU+_*l(21`2sSNHP=TK7KL_dA_UGeY*K%tK!+iKC`+tFitrlMB<LS(oY-7@Zr4Q*B
z?bjZp_2~m^2c-|%t{Q$ClAvXMl<-n|Z8|xl+?viY%W^J7e!4D+=B;h2@rV!a1xTWu
znyBMtNSnh>RQ1p<?)S?YDDb0EP=?Cy8xfan@M!!iJzatKDc~KI!GDIjQwHbdWXyvy
zIA_Kl3*#(AIL{4V47hLKgRw~2dJ|wOBT%-!E_O`Iq(EbF8PdKFXp>HQQ5O5=a^ywn
z^eXu`<LohbH!>=$M<Ao;Y+GIn_!@+~2z4S~UI)KB4-mJD08`vl_i>2>Q{Bfk4(#z(
z_u;~*4<XMbKY%X7@@J|t3@=^+G^)#>+}ee8!_|@ocl+TV>jpMwtgRGf$u4hgve(9E
zNmjq%@ZA%aCFA>n+dh6bs0Y2kelz@q@;T0x9^_g}cAU}P<U5xF3L9vcN(QzAq|Lq%
zzL2Aqv8^O+Z$*5L0p+oeg`aNNA5-J?346aA?lpnhj!HV3$Eux}!g9?<u`YJAMn<89
zPM||#IosgKk8j{Vo{OV0AFlSpK%%ME;9j(XIfr8G#I_SBu5x{oN3;8ctpbh+8Gn51
zkA$my#<do4FtnTO=DL^k$}z|};c;*}wgSFh!=1O*TG_Tc<H5F;WlBGg7j$`LbDgb?
zvjo^0uRcY)W92nBAsySf&H9N3)3nWHMPQg>eP{#9*DIi_ycy~Bv2+-zsU(fSZ0&&;
z$2D<f8{DFK*|~vq&`<o(9*nopCSJTAgL^7!_bxcN0HNjKSRN$3S*R?yIu*0m69xW%
z+`S2WT}O2XJnu=imDmYNNJ79ND2@pxBtdpe2qq+wWjR*xB4o*S63B~|C;P?PqQ$ZU
zgs=w)TPcNxwG=3%Y-KC^*0NKeK!K(utOW`bNPx1_@Bcr`y>suo?^zDCzwi65eoyz#
znVB<Z&YU@OW>3oyYetPumsi>W{4oz(>1X{{!qU8!!#2w^!)-Dg-VeSJvcP&q{=6LW
zK%GoI7fhe9K49LN!`PyC=xz_QI69c~&1(B$ZOW1D)hX$xJq-R{nN^45HYvc+v)ey^
zfOf08XNMOnF>DLMz{aI5+k@k2fony$LSfplfgaLN8_~;(?Je`&hadaa+xf<GmGHc<
zFPvv@BPEs(XT_j2JOb&EhUMTq&Iul(emgFdm+!Fj2k`Dlxd5@=<17)GU_N>b2W74w
z-$_2uR=VB7aF<)S0n~-Gk0{y1zalwO-5}DK%Z2)+_2S$@oDg9g<>%6jPor7al&`XK
zU|)hfAdUNsMsMG*f}8o;i+7r@Qg}4ne9(Hz`t-I{jn<j=;lc%sDW#(-sT<VX0Xbzm
zy9@YoSxn}g$<w$EX80k%;=UN&?2A#37lbm-8Iwy~39jvFrq2}353|l--ngzW#5~iU
zo!UQ96@D8Y+7%r*6=b*gupX4cV-OaHz+gU^xtQ6&t}Dk6$<qq_l)uWW<4?KkPU@25
z(I2`Ne*V~;aUB~dba`N^OB846%)9RV4ffZ2n~GISqO;vy4oTB1_W(P*HHFLlzYbrX
z!Y^dqC!AAk&>s^RTmhf`jty~&e~0*w&|BQ>dbEXF;_ednxNN*~oZSK&8xbs)j>hA`
zDvYXWE3AUsB5)Zd4uYy+N2+WBtKcF}oJ*O~ldf~6e#BmpBTlcS#e$LWx(;UqBT#8N
z)CZU|T$nnT!dSln<KkWdB`)hSV8gSs!$&+XDql0g0Mc_3>J`EW1B5<xC;Ypox#PTd
zDa@FpdGA)3G0FI$FlUnTTVO>z>K7(OG$@md-;dP1D5DJKX_8rtw^PG7vn0JoDa@HA
zut9@4vlw@e!IW7_Ki4*aH@dXR%9!)ZZDHgHx+9V%+i#R#!t=Aly^!#8jk*(lvL3gE
z1r<=s2iro(;1oCec{wc@9tA2rS1XOE!fCm)?FEejVLr}Mw-R9Zxn=@k7UD8I+hGD!
z{PPMkLKL>(_>>UgpYmYlkSa-)wPDcK9%cX%B`V>lr$ysfzNlxYCuuiu&B#WyqE!jQ
zaMWXH3#`g`dtlB?n^3x+>MZK|^Ux+d2l|<LUl1(l%vBFpoR3!ueyCY&{i#?PUZXI~
z_dz*Ul>QNcjV??sOkiQ_p(>^{XRA~5RL~NW_{Ss+PFmVuox=3PsN*}}@JWaY@VTv1
z1AGBAvCgr5qW!@9k25^%hl70Mp>2*J%ddkQ^Q8TKm3d|#muBD#Id5nS%HI6Gom+P~
zw-SKx%iH=S&CFO!xqS-hQRnNrw2-@>&HMM`)!kT{z(oX?=yI>2%huNWb*=5}M51U*
zbY1uiaC>>Pj5v<Ou`u=uX5mNL=I~BvqnFvpOQxsOm-H3V)7=GvNW;A4)5lJx;bvJZ
z;9cBT<f)!XU(p>2Pub=sbeB@PKWlPG9T37|5BvO5C*g|PHi4yjefRVNE{$?|CA>XQ
zg<-YD=xl8!y1RpZr;8uAfo-kfXd<a+Yk(hn!4?U{nvZ#29>R24PuD?z<@>XXpuaQB
zj89>YF^0CQV?Z_0Hzjd6K6o*2Q2_1a-4TRkePy4Hd1jxE^2qb19}BlXvL-SSzhZez
zWCM|i`|*a`>ju+$9C70O=_eR&4@Vg~*Z9l)V%JMAHijho?o7ueFi-1Az(d-J+xw$W
z#W(Xrd$f$yo@{9mtE?gJ!NrQ61%9LCNh574^57;3UkXpLc=V$VXBtm4n9DN#*hUoj
zeZcI>3B-wQM~>ed1}r~*b3+94@td0?n2+DYFkjCS!?>P>HYoKI#&mLK8)ZuEQ;h3C
z1!9}2v?Ds64;yrPe4G~^YCo6lPnx&1@5ixl@`UXjo;%q`Iv!&@&yqA1Xmjbg^fB&`
zFoRa5JG%1Wl0MR<CKpUE*dANox$OINo{e-{gS76u#(UWPPea^@`1yXQw(HmcfxOd}
ze<I?$B2d_h@C?A>J|*4xe&#a)%l9*HQJ5+%@R8#Vl*8u&?oVso9_(&0<G_)+jo9J?
z8Ko}6dWGfBGd%1UVsA%7UB-S<2NEn{Z(Q=d>@Mu>)An?Y5R<KEW@AP5%y3{|+c`+T
zzRxHlo~%uK<O_5rX|3Sco96w6QQoZ%ZpPUkX)UBn;+ETAgs^P4s2e_Wiq_@g`IMPt
zxK#*9oxr3v#7l|G#xd9?5Z_BkOBp|FkBa9j`*vdv8TA9p0#K6G;Yp#j4k|Qjn|Lem
ze#&^e59y%R&xt5XeQXI=8VrJt;}$qAsWzDI(c8S4cS=yNKU%^i!%w2OUqG7U710*<
z&jsGQ&FjHmh<oRB@8QwvjEu3ggcl2pvw*tKhG}#V9oFP?4<F_K<p|@;Tx{`@^c!CR
zIQi!`58IqIh)I3ydYwFe8PkAXe<j~|xE=xJSN<z=6J~qia>-EQvmozR5<hJU((o$5
z(-QvL@KNV8UFv+N?RO|or;W1nH}EIzn+xSu#yaW;%rcO4Y{T0CrullK!R4oj&evHO
z(s7&7!En?&MK~Ca`Md==l5pT}8ZOnl-tN5_VaWs9D&#?tj-x!bg;dAA8t$};=-Aoc
z0v78yy7M~jO@QTf+*=fu=s42<R=`+qNk8jaQf`=k{5$yZVLhe}dz-mchecFTk)%%4
zF0NZDom@uTw<8YQ8|It1y}f@IzG**ry5#p8@#FaT-}8;f`SxzO*><rUi0e$WT`oU9
zcDVq!<BId}Uc+^f)p5!jIJ#%+Aln+X)wJ(~0cg9U^L>cZ9(c~W&KHv}DSa*B{f4tX
zJp>f|9Dmfa5<X~Qnd${$ZG~g(ZbeSduC2f>oE?_aW-1qUincmR7;x8Z=Jx<MY5Ne~
zKHvBb!eIY?z}_Fmn`>3;*TdJ>rACc>QT1}!_cHt_Qb>4&^qmjn(Z}GIlnLf7U9N~j
z+6~k73y7BBz;`noUal@99AonN#!nzU^5D~WUx9L{Z~yA@F2i)Xx+Tu7f@9rAev{@;
z;z!;28NTtjyk7<P0^H+}xBT4ZYvISa%>k|&7aL}EcmrS^fbGT2fWB_<9|5atvrwmK
zgZ>lz+y>?RrpsVV6YnYKL%+`=e8SUGIeZ>&K5RcZANbGaz5s8`2QIn&EK1kgk=v1X
z()tg;8FQ0sLE8bNthfc~w%o@7i^pZ@_BAq}!ndw{VR@wEvI~-vKYqNHc(BfeYgaPs
zR=$XIb!@h;-v(xrzVz?W-k)PSh3ywC(ae5b8`Ik|JU=XL*-DJrei``u=?HZ)sFOb#
zhGpBbyzG6&@NwJ*y0-k)2*22Cw9jxY=VrIq+zlPVy2pK;tiSwbnXuh;IsSLJsc-2=
z`C+(QvF?d>$fVdhjrWF=A6OHd3>>qJ8IS!~%oFj9fp{B4;&+DnMOzv)9{boG4fZ{*
zGrn{4<M344XMY<M!g(@JDH|9ijkAz`XBeg7lJrpt+rY8HSv~iK?u}uzZ*pdWsyY+y
zB1?;h4=_Iri#^jL-CU0@M?ERMgl`IqjGvq{;NdT6us{CNg8lIuz-RQ~$1v!CB!&}O
zx&iO^b9<Odp&lrQJ4_zDt^7LN3!sg%Ntr=;l)qtN01nr3tdDzhG0c@%`R+EE;W}m4
z`IJY>&DV$nV`twoT&|P912^>q!zAIN@vb5r^4$c7%4D2YtmB?w;fUiuWBkmBwZXJG
z7)R~R<tLNg@4?OY5AmjK{|IkSgSs-MGlNI=HvJg>MKu2ua6U|r@tIzII0Q)O!a3^*
z$NF|fP`W+`H|hF<z5m7Dx7+)h_Wr)Te_-!B?fo;nJwL?DZ>HgSn+I<4;=l2eC!t0A
zLB9l?G<U+2dHA`6D}`TMc=}Q272&AMD-$sM9Die9<v)NY*7<B7{tGZ~%X~e|Pa>F)
zr~D>@`FKhU^YN4z=Hn@pd5ovTS`~G7X=5oK4s8QYFF(}B^)=)xc|g9>u3Cxlliy1k
zOb2zVK(8N*T}5900r;4P*ce1=yj)}L4a*WOtL#UhUZJ}+=*%JQoiZ(x(<G4m!@c2L
zITG_=$@b0+Ff=N2jx(ixX@94Q&1GwcsI;Q(Hg(Xn-ShT{X)&MVzpNuRn=wzra?7{N
zB*U(7UKk(Uer^Svb*>HXy6|A4^PPU#bW*?fSeY!7G!DqgP2S!uAQ;BC>dyROK6DR`
zC~s+-7*_Y+$mm1n{5{=!lRba$-e})=ZXma|Ens$JdWz@&aDly!jU5MiIC{V_LDs*O
za7S#GIdbNU<(HHpbn{o>=A-suxqO1;OJO$8oI%5pfEZvUC;Bgs+wH@mbYp#<kLUW8
z>l|I)1Nb^NE9M#(S_u!e9&iS6*SH+$W_mb}&)XQRxtBKKMC6fj&~ERO?0vGmPr;jO
zFIcbciEn?bUggF>qpDTtlgc*vkge;b;CU_b^Ri)InDTNqeh_KlbsmrN+HF*ZhmDF;
zGu3vvH}cV{V@YCH6s6~U+G%-T9pxSO+Eb@+?I5LY(<YRH4noVi`=Qj?<zX!2+BW9t
z_44;Jxfjx6nVfF#``G&od!LE7hs}qfALBX>#<?mZI~YK}+vi16zD(kE_*ceh**3O8
z-l+SyAK@&d=}-N>&`3t2?RE-H<>Po;BU5VAv0#>A={T;JVShfqPF>1lXm7F{UOx?+
zv|HzZCbbQ0?Z@${okG6{kY<d(+=RUFNzz}b>rNVsA!tI48o3M^Q9iKlC&7P$((xdq
zpU_bP0j95$a3^Z}%W!Oe6Zk#uO7;&>2k_U4F#J)jDGSsA+McHKSnijki5js1arm5x
zH8J<VjM^^{Pe;pDkNyho+8id&aZVETs=9k8XK>F3-M@uDdLrC@B6|0CaF0&lmJT-0
z05S{?v*Df(EEpZYiiH@jfoy(5aSv_bd3cORT!_~<M^G-z;NStQJxSBFa0ZUkP@&D>
zGdU(q)7&|Y)5WuC3Mj_YUz-BCPDetUfm2+l{t^BpTmp`9?&-nqWX*}?F9{!cIqq}}
z6!WU!X*}LZ`|@~&CF7lpw+gVak;|*|2E7MXm!1k(Vuym)gxxQO*&1x>6A$+|z!<J0
zf^j^CHsga)PMGuJbgj4-;Ntnw9Ji<c8pLT6DN+Bm;;zm0O^x9I6UA|VgLPY3Gv2xs
zmXs^u=Q^CTQPv+M{5*kcS<-#JxMz}bBkaKf8%@fHu=N5v#BJSCS(L(sfR9c0bMgvx
zuhh<Z$i5Eem@dUw(nH|(r`>8zc8;msei6cGpQLm$_FROE;l2#xRq>nkl69E%QlDkv
zVfIb?k9|<;F@_^=)A|dC=?waDuP=WOXWXdYS-huI_2(2%bcGI$G;}hllh@Barp$2^
z)_OlriL`UQte<W32&C_F^C0l6UhkyqA~}zbn^4M^C3$C-R9Kttm9{-;4@5j`1Z1p@
zWfb?jSO+cuEFNp4+sE2A;v4ly46EJq)3)b%W!RL!=c`+1rziXD%pJEkFHwK&Pa~Jo
zF*@=B{jVjjsk{_;FrPiNSC~y5R0>^yam-Xf)E5fdJ3Mi4^YG|F)j=t2>+~!yOp<wv
z6EN<!8S(wG{+Y3e(wS+X8nmrLSeAjssL7dWk=w>a$Y<|&Z;8Gso7z^D+6iZU@jlJv
zaC0n%GQG{hxoi+$FMe!~`}oG=<0@CcT^Ei4BH3q~$Mm*J+)~(XI2e!ZVuC*xkL@Jm
z$rH7~jK{J`;^q9Z@ycPP)QOa4)^E>uCy;j{-}SWM#!^e0etDdO=0|=}kC5Lx3vD6U
ze>*MfbcQD`$zQ9e7rb4z)&q1^9@&K$C`qlGq>uUBE9qrv+6P!8{%{VWQM_zkN}+80
z`4;R_*2zZ#Z@!-HAPpHA$9iYL5?x~Fr#vcx`IyO21Y^6zG_H(bK4ucbE-eUmskMDq
zM{&<bIJOg%U({`>K-%Xmi9FlhBdxAz$Lq^7-CxM{%qww@%3}l<@llK;TXu<dCDWj;
zNy<hM@xRDfp8s(_EAQuhr)Fy|Y@KVe=3)xvsC)2s@&E|i&)h$ag`09#8U4y(yBGnm
z`l?vSh{0+<n`NL7-fBH|@|N+Jh5jm*rJ)DcXw7`{GsAsd$7qJv81wDv-m*DbTm^^J
z1>PNkYAXBv#t=vB6W%2-J(X_y%K;HFvBf!Fx*zfQX4%kYsKQMh_)P1Moh2odP8G0!
z-vL+|>)mh^fQ+-#-GcS>`=_*@&p7ahI}Ni2Fz~B}tBz$XfbO=ieL8lp3Oj0J05FZS
z%^%0j6v$_5IAA;~KGPI@js`tsdL;`I{+)}q9BU!U*BLG(3E3{*Tfs3Y9y8I8uzVlH
zoBW!<oBX2ABQM#OG?UAZKnY=8aUz$+XH0<De81B(k%uEEOq)8<+p$@r$>*J}hua@p
zC$zmkvrtH!!V{m1m_eL5{8TQm9u(iJkhgkW(Gm_Bex_I7@1^{1@9XDfM?TNxZlt)W
zuzjdh<g^+q!wVU2PY#B-PAlctWx0sH#~OX)(-F%Dziam0th^qNFmZW#8|ih1_Fx$@
z^aM+Td^R3?E|Xk$I|Q`X(}{k);qWwWgq!?l*hPHbkfc!#PtJvP9u(WomBYB`ufKb+
zXIt+;a#<gT28%pET~V7*4o|f-$-AfFoAThaKEQN{yKja+=`YIXGYk*?D7SIGo@stw
zwzS>v3EXRp4;i}&b6U@~@SZNyWZJ|{-o?0|Yhm3^`=?Vv;QR;m%_72v(7%4$w65)O
zSX=1dkcYL0{tNT4(?kEpJgg(6GmnmM9W3Sfh1n@>k2T#+ANd8}J>12i7sC`I6ScVm
z(mpx7D`4o^_H7bIzHAFSC-(QSJDaZCaz0Rxk{9e}rEPC1Jl}Y64&)d72!Cd7a$$Su
znUnh0J2eWdIO$`uTF=jx@B)iNKaRf>zuL3qu-yFo+=#Q`?=r!1`Pgx^t6(1@oZCy@
zKVO0J4xxJ%hfmG1Ej<z8jt6YUL1=Gj-!R<1a25B>OUNW#3QFS+RxxFa1%eR{hNpb(
zCk9K0ZdqA`H0V$MVnmUPk&?M$!YQ}oy@z@9L~Y)2_w&Z5xsdo{7{k4g>;k8t{mv2I
zgUGf7eL3s8RL6u2q#OC|J~BBnJz?|_KA>?VhuW_?F6>d*E?j@a9*~5Nap3kMTa%ll
ziSzhz2YQ6}D#d|;GYo>{Xpqy~aKjT0Q-f*2KHqWS(MEd$wK&%(d@FAR#!eA2uyXh$
z4U^(HuQCc%0N2j7c|`fL36)*rIs7=Q5!+9?M@Ko^5{KvTi-F^Gho+FLf^^L|9Gq5!
zn(u2hf9OXeja}mjSG1p<@WqQgUltC}h(ko9`@=}(K#>R2v`t<-OeO$v41+d|6wOS}
zVF}yl1lPkR<z;j;j?`+DP0Sk}6*DG7Q`xfb?b$t)&jZgglb{jZ92W#iEE_olA!n+F
zXGHm>N>5^`d>fqWZxURjAN8Ss7CSa)k0f5Qu4+pC2y}}!iFa82dJoTIl%zUV7{+iT
zpS95hbA4VDFXruWMvsgGN3=gFh9@yJUzU!@vP7{o49>MJWKUfltZco&8CB+eA|AV+
zsE`Ogcwlx~7PGhv8m^twRb8+gg&n{KE*{tj5_lG4My|HluKvN{S(F0wVH9tB^>7XL
zzMmnO>JjK0oHSHl?k=l1yfP`LryJk2(<NX@qaLmU(oEmVAnB47@Ra2~i$f=ql8ETu
zUENQuD<T}{hj~pdfQ!OYj!`za$uBD#moH$zN-Mqc%*u1mxU5r6^WyN425`<!VfZrP
ziSa2NJr^J4{j-!`s{fK&o0ba}#7a%)z?Ug=X|rfAO;%>m`bdMsTi~TlVp}#@>Dkub
zOMay1MtD0nS(&ZkfK@8_?bSm#kX3ll5}pG(q7gOdjg^7=WNdl}tioCM(^!}*VI96>
z_am!E7O^|rWZ2=DkU)nnjqlY#)q~2fhwYxg;k=^3ctr;H3#ai?zwN_Q`xhXA+4KiZ
z?5O_}e9|CL>TBb*DwdN)_@XM5&4)B4ERrm3O7GB?K_x8{=fVxRjbkTfl%lkS-%}Gu
zGHC+qt_<wJ@S&<J_oU=9boP$UEyOr>PWO#Lyn8U>-*cdfk=7_rz0k-rbG1zTeDznJ
z{yEE6OA+x~!i!YyShzB%>arF2xe$qMNt-;ivs=T95uXp|L93W|_)BvW_Lht!$@p$M
zcH7kze7(m17wmD?r>+9qJGOOc8)x~`5?*HfI1{$_aj?B#8u4d~+uo4(BAeUe7VodY
zxWN+7#Hz<#4&L|TxW-?BCLh<B#y9(V?Dze(eK$;BmdE%$F(0(Z08z>uV{bY2HNeIG
zNjug^EM-61-ynRW{b<)&Km2tF<IgEr&!1<Av@Drr{p&9hDwh^iXeWPOi*%enx8a-o
z;e3;hF%H?45;`te;<zAcBFqyxyFteqS<|7pu~pFfx~~SFzs2tc%(w9@FUXCI?Y#jo
zpJ5uevxHJNNP_;UFVB|nM#SS&e1^S@!B=?IP))W@@3C(iY6ni1_gjF2<M>7WILbMB
z!7$_nX&@}t1#dMPi0f_mJ`W)s*MDIwtOemc-@qm7INyPA_4#QH?=)QWW1V8Ue@7VB
z`Tu>+FQ%bkJnW(IbM)$P9uK?_Og<Yx7w$d^%o}Om3OK(>JNwz}&+^B7u#ek;Z`tpG
z_q*XHt?#w>`|$R(QW{r=_XEzy{gS+KvzF1}{9&3&*?^yn(}`dyzEb$G;q!5kkHAeD
z8FryT*f?zj!N6BJ{G;LVw27y9Z#}A7dK08q{1gH)t;b&qA5ZbOe*)hwM_#^4M_f)i
z4*M~L<v8po@n+e48gCz?jbY@|r{Kr>$@D*q?;<`qKPjJHA6dp;zKr{M#7)Wt;Tp>v
z&e%p+K9XnPN#bFDjh{{HJiQX->)~SB{>5<c%sQT@_W`)Q!m=&?5ZpI90QHq&K9h#2
z$R!2>$G(&ZJ_e)RZM!c3o*#dqoLEZpFj8R0w3NQY_&j4CcP{WmHOAi~W4HM;oO0u|
znY&Ub7V&j%UAe%j%c!qb!EX2p()6bl^Y=JO*mElb!m7Jcef1`^0rlh05|3v)U6M;I
zLs>eFb>7l~`7sK_TzoT9edgjzl1#sT6?vr0K^EGvDFa{Bqq_Fu-{8lxh{w$+C$|Hh
z$Vq8g_?q#lcpq6^c5GCg=Mj>Psk5HoaOXSAdj1^8%4x03NhP4Y9h|0J5KprZ#(9GL
z6ouR7Pl2CU0v-T)rG0)2;Jt^@_0XQN1o1e}gCCb>$)W~yGjW#rM8EV~SBAfc{jl7c
zxNZeZda1f91h-4bflZRm%kzG+EKCD1?knMsPLpM6H%$1^1L~`EzDoUf_+`h8^Jc)<
zKiDCs<7v3JYq)3t*Za*Y!@J<Od7(BjCb`s6C!RsU^LvT!Jq7;Gix0w2v$Yf5cpO22
z(MEJkB;G&3uQsQ9mWfB*>7Hf6K8i5t+3&E6orPbYQ<&;$!)1Kv!Cf1$SW^Cc5n*@B
z+7oPrgA5QS`3;zH+pk<wKf_b#_hrQEIeeJ?ZQ+F9-9i~+op2GMlro(=07Kafpu2~j
zD}3h$r?tzYviNoQr;;pZs<a<(^@(##XW)#&Zy=06ysJz2XOSAsG2MlAJ3Q<B-x2q~
z@LUDmt?60Zn@QNKV5g<9%EUCr8)JBFYP>d8!@@)GDu&}2_3C_O=kQM2!4V$Lm}21~
z&ezHM;q;slEDV;Bcn=R)^)QZgjBx{2tByY8ArFi25{4;m+^Lk(4A|uK*uungHXM_e
z{qs>8bL=jIrW-g5;BXA=9+|@6YGtH4&aQs~pB<iIKbh`tf?u;F8h4r;!8|cxTt_xm
z+b?%jX5H&MJs%8%+r%pxt{z@JJcIdrwWA#e!#f-?Bz?hCn@Zpr{1H43KRY~DI}G}1
z3s9bD_i}#uUa&B~osk`Fi!dG}H@&E_<F2$layw!XanFX}E#N2ZJl@3r9pc0s)^`ne
z@mz44778+#o<q_!$CuV7r&T3w_@p)PH7;Fgh=OL}t~<4@xv7jCM32yl;bA%HX`(iX
zqP~R75ihRH`=Xw#Z&&3}DedIVe}WeYZ%ROIwlDo22j>rrSD2K|_|f)G;*lbY_g&ad
z+~@m!iKlw$NBEw^&34o)@;!Vw`JR|wgl<)xO1~<GP;g~P;;%BThueF6)d>}%6rIR;
zaozWDalLm~lRBTNqerVdT(3c!@Owx*ExI7>G<oXf%6h<XKLjjZV@S8JG5jxlqn%jt
znf2s7))XD^bLc4>CqS})47fjb=R&shk3lwwb49pM`6m%htV7J|@Z^^ErP(&cYez(e
zq1F#vGR{dXxAO?;+F`<~I)Z%FHHD@2yYTJf0hB|v>2QC8h4FsaFW{ygpuN|Hx5m+a
z@2}wJ`hmEAh9B1#{*rGz^rIeOTK`QL`Vzl3Kk6*TVY&?WJA5ZN7}@H>0OW*iY!^V4
zp{XfY5FD(jV9a0UCn+EFXF9PzHjyk$NWH)sdf@gx1MhexA6vpH<v$oLhzcr}#z)dh
zJ2Ig)s`KO#;p9=1vZ}b|ZKQ|En-Y{b%WBs2K^bmvGHKJ$CN8;+Eoe{c+DX>exIJO|
zEF0>0bO+0=l0IojcqRF8jh^PkA*r79e&aIWm}=bTso+|64CUhn9&AIyv=6Rhk>;a#
zy(LblYZReq{Uyt#Me=}oc*_g<ybo~lnSEC3ncu*j*FC=n%;m@Tl?LE&n6HsME`s^K
z(irCFtg}u*T2243?(6yh*0cOM>ueuaU{B~uqnR<A>XEzIJ~olpDV$`9rLB5k;ZWj=
z%eUN48`yM<jES89dR>Ry2tU?O*A?XX@yrj#v+iN}azElZkud0y_MBfDPndvzJQt(r
zERs4s8=2>g7!(C5upmeu%O|0aiJOk{{hud+-WGuGiMO|JC*wQ9EO)w`0$5(gXtbdX
zgKF^5a}xG;@T1Sx#`j0}(UPZ-p_#ak%QYtCGh`@phOo;y>odndmZM#|7t-^mK%Sfk
zZ<r!?0dt^(y^fy_yk3?`c_H2VSbC&|`KPQf9LKEEaG=O|>axQz1@fKo{t`NB6>w3{
zGLE-j9T7hApZL#UdXS+r`NqSv?uT#2JIi36mY3gs0cZTP@pd}NGf(>#<^y={5C0?$
zA~%{DPH8zy!kvR~Om7|D@<icSPQ=GJ46~|L<8VA8!5y_NO!r*F_n<m_CE=;_gSegU
z3lLW8rKfX}q)9l#5buKx@A^8t%5%k~ZT<#?N%MJ<#P39Uq`6b#m%>8~4{>kAH}iLq
z!JJq1d`#o5v3;};L>!jK`S!lh-WTJ|_)Iq`&&a-ht?BYL2$!#C4*<;dw(IiqBADy)
zhej}8+aAOGzR-t7;e0(9WfpaF-bNQ#hh+Vi>Gzt?*MCad_EKmA4z}&IWB6U!abyJR
zTcrN8EM+mb+$zsKV&!m}q^WIXLE|X)@@j;cTSUsJn~bwo;^=~_^DiZy*03ppdA=VW
z!8&-VGw5QwNI1t1gciU&zPqW1+pzBb5`^=oxn8+@dYJn&P7Zs@kI1AWwwrIiC}0W4
z4U6|@TqE{K-I(z9?t#mDD}6f$doS-D*t7{KX?c#F&++B+7u3ei1G_4jSUNUbyuMZF
z75hnS_FOMHg{5umIAq1wPX??*U&Mqv*SrvhC4jP4eg6RgiX3%;KY0Qv3k**`YE^!7
zk4XrRS{NSFxNF2V4&|>9sXePg|BfwU;NgvIHQ6JR>o1K>FThxD(3Re4xx*f*<-C()
z`DW0CwkyL$COen~fdZYo>jr&WTn?i8e+9<C*oW>GKkY+r#kcpN<=gtu{Eqw3bjN*Y
zy7PT#!t#A+!t#A+!t#A+!ixIPN9!-gV@Lm&V@)h;G`r=?LAO7}edDE-HS1d$6LssY
zEhNr-ng22MZFVXB3!H$|q<e8*as+nT!N|lw|AHrBqY`T!_c5EekJfDbHI@^WtB=dZ
zvJ%6K<b`n>^Z|>;RF^bX+Gq^a`-Q&dVT}kv_IxtcK?@T-Sj4k+QqP32Gs_6#S~t0S
z2Xmk0N7l>IG3i3uA8aRS*KiL9Y=rXm2&e96XuOAmwgc@7;@HV}(cJlI(6h28;-;Gx
zFmjINVi-w=-rOv0bxXKH(vdc?)Q|5}M2^~NZF=VJ`%xd_eH*?{W4ELy42S6?d#kqg
z;o^zD9lfHFGZ2U)``2X{z5|(f+TQ$c^shHz-3QFnGOP2Wkfx@D&G<7o{jxGOIw_NO
zdpA~MkX0Su?^AFt@b><_xeY&bBY#V8duY5gXn88$^ys<F4d!4$^3?n=ZhD`^aZS^Q
zkLVCb4(M%IVvjoCqxPuTew~xi|B1_;d%Viv=hcn}eDyt0X@Tp0I@W_L5pEUi_z#$T
z#^c6U!Oz<~`L;HX-*KBqciiUDop199%eQ%i#k!1R#Dv9q%wa`3EN=4}?#1#m20ioc
zhAgP<Ryd|#k%iM7NQz6aGBZEBeuI`{lK@_(lr`$BYmg^@irc=W$r{V+THx~jScTsx
zyJqq+iZHQ!xLz2GXfpY5&N!!fx*Y;uxz1zyBa9o#r_*%{XgM>{fBz%bD^nMig5R24
zcy2gmxAd$-Z38B@%fKXTG#?Y#kMy|yj&fa#=x(DvOYS<`ylZHuTA6iF&`&+X_|!88
zfFrACps1PaNX-CZ#i+I-^?j0etiQU>=xE0Ku3X*ZxC3#ppY3~Jr=tA0e%?Nq7Qxo-
zgP>l=-=`6leQ8~XQYg1M`#ITZK6hYxw$YT-<u0$z@9U9HvwUrX?GVdUoos+VbCxgH
zNAvah+?M8Yo8*yr&H|rjJ!~Xnb!kLxZZlf#uA5~4soPqyo?AqEuIJ?2^c=rqJx6z}
z=jhJsIl}UKj<CF*BP_4y2rJTaW~&|3{215cLEgh8aPqxi@56X|nH<5lKPG!aeQBW#
z^`TTKYn<D<Aqrcp!;VeXc0y0E|M(ceTj9w)GEOiKcV(c86N>aMXRh&jEMZObE$u7n
zpn0r+IGR3u0&vB$>%6#0=umDrFCqaQqJ*-&SO(kZ#waY$&EYz&X5>M$3^fZ7)jzr4
zKGqMTG8UAf3p<M=+l?;J#{54SbosdGx50}a;P+J0%7ug0Un(A_hsNw5*wvrAS1AG^
zg}d(DiTpRRb+!&4#C=FKbJ$2?{CH+UB&ky1k><DD{&dm|opuA{fqfR{K^hK}sk?E9
zLJi|YTm_N9yhY*I($f&f$K*P+XNDI_1vVtFUZ{v2&K+Pnexa<W?D4&S<lW7r1N{Nc
zS1k)$%Fl$`ACvdR>hQr76$>>3v0Q=fX8PzEz#Ge-w`<Ri(lhys*q>I)2q<Nu_evg9
zTTtN&nTs|yvTf6|NBoSsXG4yl>GtF1s{K9&q;}`*e(vw7$;Qet?AOwEoa2<ZQzYX)
zC5&=Yhz0_WsLwez`CQL;r0Z#;@XWgBxgWyGy<gna-QPXXy<@jCB!z$*MY{d@z~Q=G
zzD>9DJJ#)V$GV;Fyly8fuiFXB>vqEOx}C5;m2PL5QzyRwIQ=<_PF`}EHydx1s*D9}
z)1!Xy(2!Q|1QyqUB3;pkW&G(aDDo}3tJMBN<i+P7UW9MjImfo<X8lEt7v1bO!nB?E
z3*dJ>c>@^um(IsX27N8lR@gdg5QgnWGv1`#x)HQodUHb50TiGSac7a7z6AJPPUYL=
zl;5$O(jChw-FZ1BEH9^o<>i#HyqpsDr;=0JyDtMimMiN!*-PHviXUfYUMg>%WvcT0
za&yzSSf07IYU$<t3gDw0xm`>9pq`FW_-jko=L}yA_p9)`0Bw@)Z<(mg&tp*^^p^H#
zMrv$J)NcxV_6~_3+Yym1q#5sLc`a~BdxQl?wc#o1uDu)eJCRGbZ`lq#3%_uDIlP8%
zJidSAZ{TJgD2x0xYmc{AvANC~<b^5iQHdQ=;Nfyv&zsh8o6!*S=5GP34_gYaMP1>;
zHm!l3AnS~<zHEO-G~A1&7_!=Eml0CLi#Hk__30u(vu!AEZ$>!PBPD6m`R#R?yyK7c
znPv4>g!R7k+we_UsmI?E-fn3VKj#b#zpPVuC;VK#-i7Zv+R+z!x5alJzQSl=Shj(r
z`5g>{^-b@wu=RA5!}}6HJtz3}aI;_f7JI)JZ(r|3I^*?B$Fkn({lMe)6xTbESCqX~
z$hq4}<Q2=A>!3aaKYy&=E~%WIZy!c{=Jz9bC-M*c&bNAAl)^t+nxuz1#%W{yy9IHb
z*R0DQ$8YIv$s(0Z<ECV<2`O}e)Bg$JCygwNgnsNL`Xu0d>iqyTnWf+LaDK|d#^Wj;
zFVUG;@A7F2N85~jqYuJeWMflT(Kh}l{Jkvw+_ldz&Sp#_qi!(FKhYiaxr*AS&mxSs
zPx5W;6Tjp3iSD?4qC4L{5teVC2+Oxmgyq{O!v0k46ZPkE?7R6qaQb8NTgXz;pH2HS
zCDH%X58kHzb3N|d7|pTBTe<y<z{k3$x<BOZW7WQBfr{6@Sb>M@{^EY2;FG#spssxo
zJgEo&0@|n}zk)Y;P$a)!HGVX+rF^}TOl$jiYYymiv;O}paJoImI+)fMIFh!Z-2QJ#
zIOtDII(!apzHhhp*YGCI)XB`lzvCC{Waf=Hw0w14=^vwKzX4ocH(k$u6EK!9^TmAV
zx2~P}Hry;H>fCSP+n-qHHY+FQ?K_B<@CWUU>k}_4=I;*ThOYS!OQR^Bm*djsQ_|JN
zSW1zt1JOETrqzYye_&}B>BE#p1hn#%HCQOi?;#$`^gr?Tby?ph3_*W{chTJb4*_@G
zCf}yp_#Nvux?|l&cV4#<me*~B<#iijdEG`>k#39UIXEVgy6g9g{9n%P--R}a>m*(Q
zYme)XPC9jUcqQ_%4zAtRs-1(oI=mXNPJzwu#?Bh-Ex<ivfL#n&&-BcZ!D){DtqyMj
ztV>{%*h!(VzXNO=U;{Xy0}ECp+}{J%4;c4D4pjGJ&2I|d2l&twx~T3W?cnP00mQi$
ze%#%qZR6_jF~AN0)&ql-=V7ru{W@UYOO-oe;PyJo_LKFJ@~1jj*EakFZhwmVElZRA
z6H)6=3`6>WZq|i6fjg0R)YrI9Ql?WsIIJ#kO!FRS*M4er{S0s3rB>AUz5-zz*y_3N
zt1IGcPj~%>*d8j&UQM;BOYOfzx@s#c{1&*DZimqfyKqBeLu|+r)-w4u(pm-l<k@4v
zir-q^WBuXw+Hc_J-@n5*<B*qJEBh<PgYNr-#dp7y&!zA`=2v7V{T_a<OXS;h3BO}q
zLU*i7=+5gB!t%O=u)HoIEU!xlE7B!*XD)#<&vwcCO5~HZOH$q~*4C4k<WmbT6=Y}M
z<k4-RGU4_V*OOx_^JT!NbXeOi?WVSsZSX59ySV<eB1}@|jBE7Wjrlba-e5qrH<44J
z2Xlh4EamsclcpQ6{*1ck$KYipXZN^W|8w}odWm-YF95r-E`r+lCE%@ek711?b!AIf
zPB%7~a)z5YeZ3I+jEmUTSXn$!ovJM0bhBBW9yBIv{T>7Sh_&O0E@zOnfX4w3)?e+w
z2Fb(oTr4Z?Kq;)0^yVmnKtp}3>tJ{WV(e!=ps5s68q+8_xCLjPN|N8ouGtxEgs4nb
zlQ@+_7c!4^{u-CQ+BYhlNE&l{{8>gF$mI#}lP8j6m#0`}?qT6*&$dJ7wtGB8ZVzgY
z=ZjGK5jmg<N#WSwNx<nkMZQg^@H^HibjLb{?z~PREU!}t%j*=v@;ZgEKb215Iiy^#
zd<tZ0yf!<B?IApRLDrrUHix5_u$k7+W8efp_}@6xfOTONaOdmN$;_**f95<TX);Qs
zF3^qg6)GuDK2LfI;`vjo<C1yOCFu<6-j^XQ>fSd&##V%j%BMzYbf}E|Z?J}9dfD1P
z;=Bj1FQoroq&ccfOYb*uw6K9{y~1h@`0spTd%$$LmgGLprzl--_gBNOsQo?zaIb6f
zZFP;`ab2T3u4{DX>l$JCx<**Ot`U~6YlJnaYxIIbRlS||2hzRZaX+BG97^H7z|V)}
zz`3L|%}rRb+%B~owEg9{+tSOp+47XFR><jiLMl(CaF)@{JaYJXjprjO^LQ+fbQP8R
zTEz2mmv1X~e#hlbcU<mt=gXb2e7O^rFL%Q7<xbe2s@%P7&jC(<ip%!y^1mGJZ@906
zKBq3dH{9MPV_Fb>y_Rr4!gfQM+I$4|O;>0ta28R|8N~Vb4AafIMO!SXZFE>iIL0QY
zhsVrA*IaUb_<`{A$MTiyvoxQFTY6vQDAT8r9-<s_PsD?qwnz?j%&U0J?pWqli{$q_
zr04Q0-zLBOj^&r`Sbpiw%P(Ph`6Vnbzl7!Gm#{yT{BDMBYS1^;lU~vD=V}uUZtlrI
z(ssf79v6Tve~RnC(#x1_&4Yo@`?>sPKlg6*8?X|iLEF}s=7BP`0OBw7JVY`@S~dXA
zcCSb-Hp0*4LcUEd_#Mjy-LYKIotF#3@^V2~UM>jB%LQRg<l>mtws{-=5a4vX>mq#n
zQ(V4@-L+(%b4-9`yPmi)Ch$;8qsiE{jFpSk&wb8Z36(uiVeQ(%v|K$O9Ix~?I!^E5
zmL9^jZ^Cyxrk;iaZPw5BGx#2cu%!JGdtZt-<>V1~Q)cVZ%E=RPyB&2l@G$Kz{5Tfw
zG!e&Uz!Ex+;^(~c`AO#a?#@s4AYHfDId1ObyjuWgzI*Xz8F8F^E57|Pxj4o$()vZd
zExo<S&v4g|c*k?yogk2W>?5sFS&+xw0A1mE$oVl2fAU0Y{M_DY!C1rZAREM!30o?M
zoffZXJbXL+TxZC)=?s3yI)m<5XV9J38HD9^24Q)fL0DdA5LTo!j%M%r82SJ8xk^&6
zz;p6ibO!2#kMB@+V4s%z;pb1Wo?5!>d;vBW$E+^{&P?+sV=&mi2>6Xz582CmIpAJ@
zd`|e05iH%eyE5zmykaM#;c%(Zs+_UG@s*Wfm-t}-Kl0!i0+c(%;-0Pb>>E1_<3xmQ
z@bQ;NF@A3Rg>C+-FkapbKYwf-B}x5gZT=eYMc3wF<>>H4NWOg)DQMc1gsBY8RV#<4
zaeu0=?Gg8+9E1%%5>|$$LKvJ5Jt5-}yoaicvZUG_0-ZX_;~SK!*Xsfwn4-Fgsd~Ms
z{DJ6<+dWCVzWLc<oEue{(PQFqei)B8-!I#Rupyz5x8b}SHb;|=T)Os?vdncdS9&=_
zx~Is_xC-H1XUMnd41UKtgYH;o(4E&AgynSxVR@ZFSYBrkR-`lT&bW7zc0N1GYTb;?
zkY2RE(`}TiL7P9tbw9CDmQ+S;(;p3-$JREHJJqp{CZkV1CR?J<Krqv|hO|SU{fwP#
zJWTufSjXh{1nWY@^B2hq!@YvzSFm0@&Mop?6546g6v@*FaJf9mx5*Q~V|k)GmM6ON
z@<do(o(Rj!6JdFIBCLr#DKn7=Z*z3qrFb01?Y%MJBrmFXJO606ke|bV(bnA0Hy-c5
zjGLRVV%b@Gxq3OcjW-J1EaL-ABPzSC(2?xFUki9VcQ8TsG0Yv%er4V`Pqg$gp(X;l
z#RL?3T<yG2o+Rz|7=Mnbj*=%+z~MZZ0j_Ds8S%u+@Ot>MejLO*DL0mk#VNk$O<Ici
zg_()!CEo25SJ&FLd(u4p27J$-;WrDsULWLpSkLg|cU&Lnj_U*6`T9UuzCI9^uMdRf
z>jPm+tq*rc=Q@AMSC+{F-mD{(n-kII9)jDS;(D+&xuHxFx6V(O+PPmQ?q9`ax@c*V
zo*VE@8My{!#5(_2xa0jQbm#Z05a#<;JWjefym(K_dw`$wBToZe`S}sT^7A7#q#=_4
za#d+`+|tJMoRssL`1xI{^T3n04Ic+sJQu?B<GB#J<GBzo!^b0@w;|;9Vf?7uZsHpc
z>n`rxF5hTw!mLc|cJ6R8A`i40gS$I*UgQZ8o{k`O?T=&0(Plt4c7dZ^UGXv3F0+&o
z=fhJ#R~;YFmOj<!y`u3rS9YD$C5?wJwiz>AM!j9>1W(EPo0%5Ubl#Jmd4Qg7G{kzJ
zes`culX%Ca@wjh~ZNd`~&lMTnPlMZKgzjg+UFoIy%{ysY!n5ecwKLUfWpVfjHdc#m
z917e1XCkcYI{7wT$M0Cz(H-kLy7Rh@u)MA#EU)Vb%j-JAma6NH)+c3q(2Bi-w*aR<
zChN{dj$&T6wxB(rd~lBD+4XVnmV9ts4&{Tg!gVv0)eBIE>c?991~DnSy*47tN8QoI
zy@2dLabA>t1eEMvYF+K?wS=<(X~hcTBRDpjVd!3t82~w%9BsDOi{~Rhq~Xu-COxD9
zc2M~RQ9il0U}TOl<<gF!#04rSryLh${1<v08lrf-zA>-QqaW7c|G9<n@e#)TG32~1
zY_zwSer*2JG|J&G4UdmIy%=uVZ@1$8W8;gSi^R23dVo9mKp56xP2&0{Y!_ADycYE0
zerdZVtrx+M2+z(&*wf=XG4)7wS#v?Zj-c0;;TU*<@s5slSWSnsIuFke@E#*wv%$W2
zXYgC2?4(?jAL*gr#eRCOoUo$sCjwU&?k=9g{LB%#*DJllcw3OG6q7r{SbpTO>O0(d
zf=sT0Je?TYM88m@Uw}RX`S^11Cn*oWy*$_sfaT?v8DEh-+{syVRjV#zF1XxPWHK(-
zR{$4jdnMkar>GqN+S02l|E#^&J_#8yJ3;n*FdxP1=8CW1QK}1X<`KF{=idM)d00;i
z?gBA7PqTGFFNHfd(S^l%y3XgX;FoW|U(4{ePR8ft{+6&Nb8?iA{CXd*smbBWEV`k8
zQ@lxNU7wT3l`hcH^*zmT*-{`G%PE>C%AVo5k%f@EQyEQnvQOkT@PoR5cH!&s&GKd$
zACEOXZ-Cn$-|x+urf0iwYv0n=MjiqFMzZ)OOM|lTW_)WMD#;#x-iPsbfHgehWN>@m
z=I+740TDFp<#spnx2I6A>xk8s>i94YIj-3D%_>eD<Vci?YXeWWxhSWdV9Fa4-ju`J
zqddIB@-Sukkh&JV+j-o^II=LWcRf<ZE`h#i4KtJDQ+jQJw;`{V_%mClXBTl3p$w(T
zIyJ_58~jcQGd;Y5!f)Qv8x(aN$h$0UsY}pt?}S^QQuwke=A_)oSMt}}r1!whc=L!5
z=k0xl!*vYL66MeLD!)5P180W@>H)c9uWxF6I;s8%1m(gsvh7MKyx(y6el@3!`o2Cd
z<?ulZ@3aTB;Pte(gpXLb4JZqa+rAfWooh$4DtZI=XT&f_gs(3tqVpdOpWoX;UhPEM
z{H+1M`Sv}FXT$CC%W#y(GIagN3<p4{Yk#~vo*2^m)qpbDZ<@B-%fcrTx^=y8TE4B}
zlji5VkLh;U^~lQ_AfLzE&oX14a4L017P+Q@a{6iDY;=E{lqX`QG_-`zM)YN6qa}RK
z{EkN(pyS!I)rsN5vIa=Ut+8Hi4o8|JZ5^{79)&%N+bY!E5)fVv)lfI+8oeI(U-EoT
zhF^vr<@J?Oxqn*mV+b70zaDtNfRdPmErpDqCv53v{G15!YstoQg2b;i>*vIY-?FTq
z6Dnn#t*0pusk<p>pEtg-lwgw<Ho{2-&6J{O6x39%JJS1!y!_ct@caXwEyHt#Rv{hI
z@kOL1k{q*u$oFoHA*MogJyVwcREO5ryJg|amKT@D-+~UmKhJdlbzhMVxZUFFog4Y{
zN`>m=WNsX1GB~_nxq^?b#KS0e*-h(KDg2w^_j>Pl-8qeH*G`D~9gKSmYQEF`HKUt$
zG{b#^_+Ybt%kX-*Z(6u4-&(`hE!;WKaU3@xKFI~_1NJ|^4R?|cDO1$}NggmR@g2kA
z`Ah3&il6(h%HiblcP%Wabp4g0=eR-QGNx(2NBTNyOP1Sz037Eb_J$_+?XeADUil+0
zsY^TXt>xHOwEr(j`Do?nJpCcksLwO*3b8!8U(Bl?o1g9*EL_usTW93XVLSLebs9&c
z{<6GNyl|lJ!N=t&*2DakH4Y{0^FsPuL-133--S2nWSF?zer9x1{+JH=?fE8e3BS_h
zlJWl=u!J6rm$*zYob;O!pW(8$PbvJ;(ka5>yrSO%@|Mz<#&eo}13bQ$?brBb9)E{7
z<MJ-QqPX-UADNF|kq*f6ANa<z+0L?kA!Nt*XuSx2^u`cA`}ed_dT@17vM=f-@a)L?
z%bu;*0KP5@XMFK{EBwfl2<NWx%NH=K%KEoDd>H;0t3SpQx?u;h53o9X9Pq9*9t}Og
z_Zh&qDSXTHs9e>dx4TPyULC#w|9<%Q&GA?n#r3a%?E`Epwl)jY!rlS+wSW(33pnTm
zaPIu)@biHU+Me8Z@jrmYeJJ5?My^W1?<%b4JrXh*=6<ddY(G~&aC3Zvdj!h&Mi@NH
z@WyyR!!Z_bcV30EWBrfqC?9($0SC*z74K%}4m}b&F+O*QbaRY5ktf`%x5DVU0y>m@
zXoEZIXX>sG<b$>i_xiwh#}Tytevb5U;G66PkpXM2@C-N$N!#J$3^!xh`9?igN)v<r
zN>6vsm1t=>4!|+8m6@<=8>aoOqo1XDh27!D{#Jay0o#RN17@QjBD;kBIbhL<xemf0
zpY%Hib#7>{-myXVTsEwnvHrCbr<~PJ8~g9Ui$-_+eE@zk7`AnGdXgE7?)dv?>}PlU
z{S#m^{9`xE#drMubKWm^$KRLWk2+~tuD|2&tLmS*<L}=ABXi<A{{927X7~7gzrbJD
zd8`aSfuE9Ie~;fU;0O8&?+*Me{Ng+Q)SbQK@An9^KX=DpfcyZKx#O<|u%i3-SXRfw
z4>T0swZ}8xQ1f6)#!qD^bIACT51h_MgUDkXwe{4~aaZ4ok<91s>T5K1F>Zb9HA33<
z%$e?lwPFk}KGXdkNTbo2?)1Zme=_zMpXt68G=^|fjt6Qp%EgS)`X7$6;I2H})|djl
zz29Kxw4a2upeM4-pe`89!N4H4yC);Oj}O<=AvGiEXD2R+Tavi6x3apiIj@-JX-HFT
zg>w6;Odsw39mek#v;~}1m>Zp~>2j!aJhct|EUe(Eje-Ncv$NB)*mcX3=cqFouRZTS
zP#wn^(Nm*n!#vFCVRU$Ac%+6?hmPz<3raZmvvh<5$rw9vt&4C8157vbKJCshe_(cc
zQNWD9fcO_<HUrzQB^{2tbcO!eD$iM#fr)S@Wu0fM-wXNmr>>m-2wA@%!@rqcUrnaB
zf+}72M%rknc48DevC~cmjP@>;IF|1d(Y7t@txXLKCU_Dds0TwD(lb}jh;U%+owtf6
zQ4<$pc-v0-JB4vzSKZg*-e7q-OBgk}r8cQ&-_czT<6Eo4^9zs!DZ4d*wT96V9zrUI
z-C8*j-WEo;V{_!3k9(<%%p8*8cnh}??aS#ne{XJB&vB}!3y93-;CK{7qkLAB$BxW7
zx!&j|2j>cJ+@9z_JlYd$@b<dLdf?+;l%p$<7HPOY!X&(bt?azX*0oV)JIUWkATG8;
zI8VUz$hC8TuP$#K2(i48o(Ccf>mqHbG9s;m+aI$lHt*WC-7|?ZjNw8Ky-xeQDAOeE
z=X-ohgXupQZA#)7t*aH<K!2QPU*DO_^N1XDVC84$*yGCA5h>Q&Av?#ROm9b}rk%AG
zG~{)rww*2E0q~1$(UVTSXE@hrzOgQn_H{3S|7=z2e?^1PK5hvQPSfG83Fv{6tW`xF
zM;($dCE~8&YS&R5n|Ww_Uhc}{z1o#gT=xozR=Vz4>NFbi>o?urTW|g>8!4B~+jnjD
zQsFns#AWLB;01qdXE@%z!Q%ca_;Y$V_I5_kND1ZpLJ#`WE*8xe)7iMsn|*W|IVni$
zfy-aA{sZT*Z8Ul~rc~elsC~Kxvt`53;+Wz%I5oW}hrA6{^3d#9z{SAJwuyDN9`Dh|
zkaIGZsb?m03CwwYf7tE(u|7Nu>9am~nLXU{NuF6<8cNEnr+bKHhJI@MCZn4;E+Y=)
z!ugi$jRxN?F?{r6Uio_jVNsoOx~TWM;K%zDD65<C?Q(xUc*L~64;dl7=U}{qYJqx)
z<4k8GF6TelKjOV+^YG&sZLC{*fG?esYztfAW_gxEYk3R4{Yl26kFh)(&&^!f-<z46
zF*kVGEFa0ZkL07}RL(V=4I(=*woP7K0h-D8I8ToRY@kq<R7Q8Qt5G||6LH5DCMS>R
z?rK(qN}-qAZA@>6rKjUgH<g`V`mS$qrGC|erH%>xkU^FuzaK^1QMneC=^7-&a%S23
zSV=$Px!hd=d;@U9Gifhk-VDMoNz3GwGDMl`Wjw%!<XwO>YJ-?wKAz8qJk4x^U4o~w
zg*^6lon;5jnw&XIo2(NM=-zF~wOD8`DEoU5KfM<ub9D^NcU$La+tqm44C7pdIIuUc
zN<!<(KDa3#Qg*C2_@0Gq@cimW3w=Tm>bc5Ba<|9PlcT`ImuF^T<nOj|8PAs~<vT7@
z*8{XKt^s}Sre63kWIry;YvEsC4&^Xx`C^_~29znrBM#aZBY=qv7(ZNg7`Do|8QIaf
zSJJZ|em)*an*Db_$Q<_?kpBk|rnnZRb5W_Rl|zl`;c;1J`{!xU*5@1=(_R4WtkWfw
z+d+%Nc&?`kE3Q<&Vrslj3txx`mg#lCOE+oY8nH>Z>-pOnrYwDJ2Mfo1v88Ka4t+oL
zDqvM}1W43N9-6j;Ue3%b=ML-BEr)qax5?V!5o{0k``aqRqocU3ohk1rfTw9Y@7W&4
zbg=DUJ9h}_vVA6R7>2xA1dK9t1aHb$5xs|vUi#gF!X%!@5*FzZpTqHT=6n+IGHfy4
zmT;rt^>DX<x?<Y_V`}Ni*ir-;NLN=PcTWUP;(HR)1wPVD+n97bf$5>o^JKp9tU<fG
z0&mtQ$|(CfPl4aFAvZIWSIYx=bDrVK>dF=2X@<*r|8%&0oYUn#o<}aC=NX2hp7+bb
zGb6ujK0s_@<Li7L(;EZrOpia#=lT4?Q-OzL@6WRLv+*uU?>UXqi^|$%i+aP?n`QY@
z4u58Nyllxoml3CvdXO~yIl?C81DW*lsi&_cyfC6KAJ6&7G&xopr}+r*gKJ`#rq4(G
z1#pokFUH$-746Kwgq!W#Jbpzq+#1n9*@<cQ{*&{_Wq@@~muj?zmm>aKp=Y@!{&S#5
z=P_1<#{<52K+kjISpIY2E~xNmA6Jx~55F6WJkjQ|5B3uHyS-_9;v~*e`a&;9Tt4}}
zP(3fo;T0B^x{Q6DzcTm3ka6ql6j8YZU1sYjAvY|~R|BusXO;DQInnk=dAuyV7U7%h
zC7T_d+FzZ+gyPQW`3lw*%vUSZBiB_&Wl`pyI%t=MH&yFp`x>O7?ODU|#3UWg;Z$nl
zl_{h*F1@Kel`JfqMiH-HZ@eWxZX-X$-qiC+XwM!JTRA_rEA~)AM?Sw`0Y>aG!pGai
zp;Wbf%YeF$!j5F#Gqndw;f)EcO5dB{b{)9`b(8s{K4U)Kz_8HEZ?QP;7vuXo^K%@J
z0uIiNhf}bgQ2fN!EWH)qImRYw#rWQC__!a5_rtxz+@J&!m*rWuoTMGjC6O&VmJidq
zMPyg=|1RKfGVYv|kEE3mknyQ3_VnDCBtPKYyN!OP{T_UqYzQ4}^PQ*kdmqC_{AQf@
z14e!6{QV%@tWVT|<jA9;KWQ80`TYTeQ)Yl@=pIiertL#a4-fNCUVp^ggcb7onDY-r
zNn5CA;l3AXP`Cesy+4X~a+g<Nuj7Vjt&zHz-vtt7`So%nU#_q{veYvl2d<2S%q@&a
z0agz35NhbQy&E&2Yyk?7J_#HNkI?3M`H_ElznFjZ<0=_SDjaA|6pT5t$@Bbp<<X~&
zH=n_qdHpB6DL0!i-^jKpo@2iferP^@K3pceIp2LX;2kMEneQG0e4WBMWyw(~nFpT$
zoIJ$*)Sls40n5DkEZ`R_oKxL0zDoQHfOjbzGYcHx+BM#X%Xnn6Q~H;y!{ZQUn}%_(
ztrNqzyv6))f`7mHZ<*UQt_kQo{>|{)2fx0lL(>Os-u)K9uGR2`bM?=I{{i!#n9%7}
z()t3xXB2L<$}qg-??v!C48QKNF?4G|#17q&&3G?^-%arA!CfNr7`oSyH(dkpD)`;3
zICo6XaPP_L@V9_HPhmEVj2Rg+ggYB7&u>PU7bA?X5rA(}W^aSvD^tHr`MeW;uS@-s
zGNL{5G5E>szGO@7jL!lV+ZkT}DNCQjFV-_f`s1GwCJ|cD?rp2vUnfH{PxCWmd6F!`
zxE}ce@!ONvBTK0VtnaiV*q8nyaB&R&-mqalZ+O3ix2<PL=2MdVqtDS~pHo(!qutM_
zG;wEZCF|c;k)HRJ*f!GrucRfXt0&R6&=xA<=j{leG)_pAW1;mr0}Xw__%-uG{rvAt
z)1EwEy)8Uie!Lv-4P3O5$=iB5aE9;n?C}1oSRL*FXSI*YxGbBm<4yj218?TLNxwPa
z`;OY&B-c|XjE?|W&hswYBHF;CJ=NJcoXJ!j!=$HQ^HUENdP(26Nnd1>k$%FzV{}vA
zSgveez6+Sw6~_Ay{Ni$MSZ-KbBHRKU_>{DZ?4bVyzDks5>V+ma>&C^&W6Hu0NtZo&
zS%}foppVnb^SDXc(G`8Xp|3feQDC{xuL<60(k#6nmbN0xs7bt`DB_ULwUyc#k9L&z
z6J`7leDQJmCitRj_qHXnJ=jjBwuYYrFJ<Isc*pkFFX3*2b0|V8clo(2k<L5u<66^S
z@r|dr?uh{5I?hy@{BF)VT#^2%^D83($xG98wrq}=3WxB)&v*I_=w!Y4oxOjLcN3Z$
z&WAGZ#=~}!<aTfAK4{b6Cwu|a`O<KXqo;d!&#o=erG(-Xn!T(jLtLX@25z=hNH4K{
znbtDE<uTqgDa)Sxx-ss>=GrXwnR2}|In(`r2+w!qAe$VwZ9%$mdra7h2zHL>)|OLi
z7<X{GoAA2uZbtU2m*d>l<2;YZXkItektYfw56x<chGTy{-A(WKZc>gt+jsXRm*_%Y
z(kbPredWUS#z`BJr}j_LSKcXYO@6GoQW>3{ugolrOw>jz<J?p{GmTHXV!MH-<f94C
zdh$2EBl~^*DA8`jY*OaDB{@|JbRqmw`mVhDAZc&SkuBjybHk#G{C4JS+BUb&dUsFA
z8|&TEAb<6?gz|7<s&@TCwQ``!(>dp7FX2Ak^BS?&&#Wkn+O=h<QM@iZs7FoYZhL=*
ziQ+tZoCbHiGw-Ka-d+Ea7pJoRMY`F;-GbU!d}o>PIl6K)WpxA;I*V+}`yf5&BQ0du
z6Fye38gRGC?@OBO$?F7<DypD?e0ctt-+L1m@^_};{PHs0qkWd(Ka}jBqq`gy2QXbY
zd#E~QXLR|#?F268ba9@N;g_f3FQjcm_zd7!zl1qWUAxsG?vcdJq1v`kOWefM78V4+
z_#EqP3loX|8ub?d{W+F`_*3ZlPI#INhC_i$2k&TX3kMQByyFe&2!MFHB+mFmjHg>*
zV<VE7<wxn|UF<}qxD{5Z?ApA0*Y@7Q-b%$T$*oAUDtyp<%#BWu>7MRQsBPfO5n^Hb
zmKHbLN%;4ojcdcH9uw918rQBf%)g<H!n&vhu9&C$@mR+I_vl1zW(;Sh35@%X+5&dN
z&!+TMFfXOB5iBoC;a?Mcgem?Ri90iQ1A|z872nLF0yV!J_a_}w2UA=<3gcC;1PZ;p
z4-VnX(AT)%(mZ${MZ$egVfmhc_+74ehi7MplX>zVNchp=QRDxQ%)Maw__4Wb=KmA-
zuPI$WHMf`FUG8sm|H9k{EdH<E|A5B-t+^pB!t+0v8<HY!bV88tQLMz9PWaerFqHu1
zMVrCUCP`jbnj3{FYp7VpCm1Y|1S^*l4KBjqvg!C-APj!8!6_A9uBSvWkpK&OFN06a
zFtE~jdIDP{P-s2FU|4BCgFAmE-zGm&*-1Oc0Z{%Tadg|dzNBt*E{$>|0H;-9N&Q}9
zVd6T-xmU!qO0P6>&OmT!r575z6lRrL!*wgnDz(ClF0a%Q_iB^ps^mt)>3zmCT7*Wg
z?U~SuY%ouQ#mIbf-jI9%^OCypD1~_?k~9Ym=9P$X_ZUnofYM?2Lxb&U{o99dTyHGo
zf)1{4+X)qZ7Rt#VxgR-dl)R;iK+;a34U)Ezwm$b;Ab!yvGPmi*Fz++L^~-33hTM_2
zQP_^24O-ZjU>jcs&Z{|JZjY@cYtl#1G5`Am$5QMjtXe*l*iGih(^S_kqJQ@Q;}_{&
zhi}?O9**vF=^xn#&DPhMzE0NH6}A5l0=|k9i*oa{;<oygwjbU3b{=W4$N1LJCU+a+
z{3uS|hVbOYhG@tuy-&0Qc-XIepuI1^+ifJ4E$QC?SVBL>;oa6)${16!8qx>DB0y33
zWzs_Warw#E7RrzGZ3Im$OJBo$q0#>kynSuKEogITU--}O9Bl)PxGq9i^g_eK<eiQ+
z5%)t0i{zrN9ErsGt#NuB$BWY|8h3g)aHq>e!5EVh>f4mhF@9Zt7SsF)quIxxE;Tn|
zfos|Mj)>)~(|h8yi^_oVkkU~KF0bS}+xt~Wf#0nETAy^jInVDN_%CJrw|nf6ETeT1
zN!?lMSO%R&+ZN_GQwH@s>NTE_)~yMx$F)13i*PXS4BN-JQTd;VbucKNz&w%%EMr--
zf;aO?+CGAMo$?JHCLcw5;*p4h^A(efGk#Vsmxt}70Z*Om5oox5JbI^vrB}ZEqhzG`
zQ+JlX<P*=NVfjj$8F@_4HTLm6@?Zezk`Ls`jdE5^OIXjmNr(Ixdzz>RT$gb%;^)U_
zE&=SuyM<K8d@e)$vFiNrC~Q8C_iTn6CzB*@;`hS|=zlrfwYkb6oQg5V`spyID?Kl{
zC0v29*n1{xGI!{AWmxC1D%0bd9^r<+!n-gKJ`;xP@+p_#+>E7H>PMVPWeoOCC9@nK
zw3K#>-=QjI4JWo>f`D<BQrEWDCMGIVNlThIvy!0gR#qNc!ywY+!?A^va9;C}xe3FX
z*1J>Ult-*9EsA>du?5QO9?(D?<TB~?({+*89frG-^hR~MzRtCVt1M6Te(7E3MfLe=
z#KWADGgsREEdP*puFhU#X_0^VI-8=BDw{a-<>dKhUG%o+jpz&4(~r|XEIp3N&LF&x
zZPte^g&(jJj7P`fZYrzG|7(HWy|FkQpWqqwm<isqH9BjI^y920?oJasdldAxhbh_X
z?Q>-;SN>?zR^jjC*I8bd!+y)_Rj^H=)63)LW~v=wZ6&)6WGyx>;vgiRUN=`+f00<e
zM+wu_C2imV;HCVL9`^B_9=0Q-?;z8K&9s^W26!m56O4n9#plIt;nX{~3NOs<<mdv+
zKL<nFUhd?@6!7_v_@{{<G}V_YPF*5Bc<4tO8TNX@U@Lz``W(VrIrEHb0hup`@qA_Z
zTnh7skLfPpoB8sxqD=C~v=-q<Jo?0GS-e7e%i*xaAr6iW5yuUV2YKgHpU-l5pY=uP
zH-j)m@kldms#`#_goFI0;mToKjvr4zy04P;JuTru;>Z45Dg0i>o-nEd9ZWarToopd
zY_CqCO+d{?yj%$azA_vEd~z5oDx`f`5grHkM0INaytGm3o*iDS#IPF?25rao;ko%9
z9>0inj^QSS?bcnVX`dsp7oqc>h%kI8bH|19@+X;l0QqRIqpn!yC=0|%S>X3`A=CO@
zZhtE9od*}-B0Eoqn>?kA#dO?k>5}(P!?(&ys*mnrdtHc|eiwn?>^Cn(Upx!=Twm0u
z4MI#_Tt1(P@VDTX&N-LEbK!QK@oaqibHAhLjE5{iXFSAohU8o1UDp^r8R>8x)-&w=
z9K6XN;eqHDmD8BNq?=(_e&iGL`$E7HUPI@2nWy<Hg}<<Plwa2o`FL>|osV!#*VjY6
z81YH#O9YRW^-J;nrh+p^HUSP5VrzCFo?IUwvc5WW!LI{;yJo6W<|Au>wgJ8_ila*(
zbRE(z_;n_6)Q4+*_5yw}<3#sLKN_$uz;;X@s<Ok5J-E1XTJbyve%mB`dgpWnuztYe
zJEung+Xq-LPFyt{$$F_V_+1M>tj@ww4oA#e*CW;7cR+Bl?Q$<odlr7wN4s%Wfsuvr
zU|q9x2!4mvuV-QyyBUmEj|KcDh075Vn|WZL`8^(fH`CAVxaJz97Xao9MHr4Y^~(Tr
z+m&mby?#&*ZiOH9|I7Kt!!t}yPS+FFhmH2kaE|O$tOt69#r-S1<=*KAYgQ;nWu);+
zgyZ{FcvFr^2jz@(y#}y^F2I~F&JQC_(f;3P$%C$sAWq7z%Q$s1alQ_?<uP5b9I3a2
zA(-0QP85Y9uG<jL>ly9zG+f$FJO{e!IJ5;XLRj+r)p(2Emv)@xUk<MYEG`Gi@9P2M
zlj?bewE>pZ|5(?Cup~X(2CNQm1e|pZ@T46e-CUnY9=Oi)_5By19cV+jy~)z19%+lH
zO<Dlb-qj`LLVAer%@U^^-ePgdyEPd<IE=rst-0ECJ8|5Cay=H^{&uA0y4~BDcL3(P
z`kh7#QVtJluB$gZ^ys>J!$U34Y`>B`qaFQwONZ?r;okne2XM-7oL>-}%>TU?{w$Bz
zS$TN<i*di-aM$~#{B%F!`2fSCLO8FTpSQt}yUTH$f{a7I58>K)o*s6ij~>+i=!XGQ
zCv}0gL+=KRy8VOp{t&~6{d|1+Blz~Gt-Z1hbH_V|r?4z-cGD)s1Bn@uuddh^Y?QsL
z%%|7yj{;YcZ?sd+Q|2x2=R6@_UxWFvvq1#pJXxRnF{Ab4crWFA#!nzzqw^ULS^a$j
z!mwVx6>mO|TByz*>BA|@v*W`&vx9zbgCFYy)~aG1YYL;-+j>&yfR^wN2-i1c`@>Ba
ze-f}*2V7@*?NgQ>(>wz*TzGI{rmM0+j)@ssT2K^)o`-Q9>iwrJE$TJsYp0Nf=ne^g
z1!w~~x%mQBG23h7)!o$z><F2jy<~$d6u>6YdcUr<o$DzF&BoTLQ!%H)Hc{F(>Zkhk
z3o~4*ko1ZY7m$0~@VSVGK9(-kJz5LMy8C&A^Sb*5e8=qs{l4gUOpoy#RobCzSU6$(
zG}~3W*{$Q5JMPw@eN1Itv{7{C4E&4mor!aCpj(#z3({%hSsl8<X;8k9AJzr(B#oQ4
zGdzccYtPvR1(YfK9NcrrI<9nRAEZ6$gRBT&LON;tqV8<lvLbvLVY2PYitts1C2h(D
z#s{viMQBW2+cdAx(GoaE+#bylvmCL1aQVLi4<EKOr(=%0Q8`lIlp$}oTX@Eid9M6y
zG9?wv%7MW--3z?}>99<xbGwr7Qaj<+f02HQ?_c~n(xZOzw&j~}vkX|r8UGHUrxd<n
zbh#cTzOR|zx6IG?@GT%N<%RqIsK0JSSn98S=&yR*E#W^J;RZuo$NO9Z+i{M&dK$i$
zl=*O3&eFat{AYxJ9w<rs4-Dq`eeX8qnrV>!v+yh0^U3(G)3a%{h5w4u`Z2y^KK&H&
z_;}ge0=|<UF9JNFsf0aCHU{No0;Yv$LjKsN{tmul9qRpV-tsV3J&f@qtRF_0wlK!=
zl+6p{IC2TH!ExO013pll!QwIAMy&1Oj{vL9ZN&wi>i%hj|3QyX*j*9q>c^yO858+{
zeeg4c;j=;H{+#m9%}v<8I8_>0DG?^OC6QIvOTR?iSSEi3x656e=C3V{dOsv;`pet+
zUmz^o_}|$3w|J|Lzll;7J@tD05}Z50YS%!=cOnzg){{2U?KUTM)9;ZE>H7oT3GHb6
zonKBnW#E&Pk220=L|8sW@jTDoFAXp*nXfY5FE{;28-x0h?e({Ti}vy54bH#(9{fA9
z{$d0C5b$*h@5}Ft`3d|w;ph8e*xvsRus%$<&2V8o(q=!P1vJI7O1Y<AXFYXYK_0PA
zl27bYai3@_;_<m1`9K?;V3kJNU0}NNjyRVwPPrv4x42BJ0)8^BC71IO+H$7JI#1lk
zNm>|Nu=*O8`|<Fr4_gi|NaRw-h~jczmC&x^3!Hba$59IRuyA=EGELVR)R9H}ImzM{
z;XOH*KG&=)nRlH{>j;*WYI)^(2N9Jg=G|#gK70>3`y(;0PH&Qrdz+v0hvVxUFMc-U
z$zd*cOsj}b_ic#3C7fY?J{BG0_kHWxe71&;T%0w?PaMz7?OfOq^<~o<)>wS!6U!zp
z<9+BO9M7>|jAxwPkapZ*Z+@QMFyw@5Z0c=JnM+R(G8PS(I&HhNwCAk9aeY{qqxFGs
zd%l?GG%O<K>O&jyuv79;4i9RQj}g=jK3>ngEv1|!=i@+^Iu6h8gMrh_JD~&Z*Lq6}
z;Y4r5w$g*a9j0?3!cf0^{6roB+nB}|`|2TZdzy>TPaY>u^Pv{U{bGC<=ls%m$Y8=V
z?Z0k7ShfKVv-iXCCcRGu-K#*G^N6%NO^-krrh6&g32wAY&W9qJE<;#8Me#f@-Y#_^
zENR+|H`D(cqvcZt<E1MRhHaEy<<mD+L;sy^7vUWVyaz}6bKHM*I010BO&Xq~pBla$
z@J_(d*2!ti40{S-7b}eRki@?iU|kB6qw5%MHDKEm#wjw{(?|II0Pk1$)>?JK=EPTr
zvjE>0!FS?VX{Tc?{H}#x|H6DG4&etPcpT>e@SBP8fmq(HKpM`4-(mRm&B-aXwxLt=
zd>;I6f}in1c8Rht#CR9L@8+DJP-*_;@ADFW8_|`v8+Vn!ug?nv_j<5B?*S~^o@+a`
z1#pg?-ZLFL?Jts_tq8}5>%UGzJKt;W%kf4#AEhQOed<QrK^c<%Y9zx~AYM^Ak2Jil
zE8mRvnLl^C?oa0j%3((#F5De%xS0M+fP?mg<KdZX9mtQ@sRu)E5hry!6mb|pT)L_I
zI2XEG+%2cJ!scOr2=@Vs-M9zvxNh#XcnrgM`{4F8o-6rCadaDws|`n*r&72oiudRo
z&TG`K{UWr9Zg*ds;L!7+sH=x99>1BV5pz@LGv*HPz-dd)p_8zsP_?jZ6Xiiz(#LSA
zJDmeV6PE1py#qWVe<i#GE{E%Y?^bQAsOF<*Xle_u0b{pj(<XG~%~h2?5Vq!2CN^x^
zG&nmvdJsajAR9NOJ<Ec+E?a-uW%<}$5$>+8o^GF&?&{iiRoAr}A3E}|_3JxF0_z-Q
zgm>e)&Yb|g-X|r&bWh<2HYPfJ7B;)yK{7m3t4z*S7SYBcE7i()Z3J6PD--K0__O=E
z^I_(WOko=<f^4XC2D_8wV0Ct?I&t9!b>kkA>9K{0YNa*?v^@Bp_tLJw+2f(S05WDk
z&$Yu-(^E$#rx)hV=fn+c_|fVEHf>5Gl2y3Y!|`-o*4=sd!p@5}R!2w1Q8gvs&p=rf
z=Cv)&E5`z6ksjq5`u@&ale}-8nCqUvAT6i_edI?e0JfF8opc=%VP(Rg+_731+jvrV
z3*nep%EMdHL#fT<2tb_Y&@+oK9Q3&xqjuP~+j}^QzbuT~opb;imw10U#8h~+(3nS2
zMCDQhDCE<dQQuhC-3}!$7J;AjiTrs3_~`tRx-502B^*W=`m-L=f1T77KQ{;f#H0K@
z4&f+&j{iv*n4>=8FRe>BUkl+F{s|V|>oCtsW;ljt{eGf_dy<87-A8}Y;_mODeg83j
zX&UA56vUyMc1<Xi!&42{(-K^MUY)Kna$GYAPF$q#8Btir^Gw03I*Mx$JYDyHwxx3$
zWpcUNKhI6@XuRjaeTV4Mws!IyM?r_@M|kP4ZAR+<g2?}wi0l5M8xjA7@OM5kKJ%`)
zOW{T4*081U97|i>NFOwK{@FgUj2Zt+$R8EPODz7A@kV25<y~sO9&YMy%Ers_&3N#Z
zbKE-dP2VS2xx4{sdR&I5Kf@!4gnw3q`()Hjj`O~Xuz=-&3ssCk@oc`(@@jz*j;F*r
zhMHF!>%-lnvN*#PZub0j9BqLM*tC~e=p*X49$Qz}mEHBamb|$+qL=QQA~$7+{LuC~
zZDaa{H!1_KgFk<1IhDh0a3^uW7?fxGA;8FE@9(`4?lzQB9AC?^HM~jUt6jwOQ`}fb
z8u?K!=*N0b>~Dpi*V$s+E#d8gPibd-$_a5i9&pOYJ0twmvvJz*g4^-mg1DsDb%Mw!
zW`o}&@o_#L-sBtk@OsFMe@k67xYS|$J^-EJVML!qHj?X~G_U3G5uq)$VbB&yKaw;h
zZ6xd-KQHYH$Rfutrx7pPV(a+i9N;(RJh)c$qk!knDWm;>mZarl@bd?!q5i+Ze(-rB
zm5F(~`a<Vh2;)6wY`kb|a1Uo0h5m^sA6SbzheIi0L5$&U4n2E@mUJDot1FVd*6>ak
zUTOL0{ZG^nGf0#Afi@=nTZCb0cz5$Ys*AAx33r1Po>Ba2;OE_4i}*1gXQP}u@a8YY
zyDEGRd7;eljuN(Ejd1cjRljTNpAn}S&M&~<$M*B*vhw_7(%|t^TH3;wn#5!JjpBW|
zNxbB|W~50T#OZytNxbBI<brs&BOdWE52)4QjmT5%=3Qvb^6z=?Ky1d-vnSfZ9l*=7
zcqQVqZa2c=w0W7vIKBxSt}{8OM|~Cdy$GXJe_Qg<a_R!cNhoh!kT=&=e(tsREj*v!
zjc_Mn5H}mHHGCi89GBCufN-Q!<+mmL0Aak{cAd&F)XP5-+EnLKet0jH<MaGDz7B~~
z4nLMSeqLBh_(_DH@tL-UMXLfo-(%tQF^^XvE!tvd;hW)=SIfiC5#G-xEed~6wDqpn
zHO`9g-;#d0{R7bZEK8qDdl~TatZlY8zd{&>XIjeRW#QL=d0uJj_%G(&ZxP1JIL1d-
zq_|qc?~R5R8Vw%Daq`W+6W4NRe~8yc56&*&mPYLl^bgO{mRFGVbvSROfRrY*CTDOi
zVFmQO-c?wFTS9HG9>OJ%(wj-$P=?T_&B}oMbUv_+;*UIHnqDrgNF${IcTB>~`m+LW
z@|^ngJIEj9TWxohDW2o*xah}r{CLFSnhxc|z^+Q)&c4CQ?!KLuV^{XJf!^*dy<14L
z^2Pmk3~e9mOT1m4DYGeErEmgpZvbz~#+y}eJBC3V*RI@&A<7@F{ii*s^`cMqYS2yE
zTlIz~Iah#q+kw*`jO)x;OO|Pq>YzyGR*Vg5o+~)l7>8cSNe#MoNAqg%vFgaeeqP*g
zP-LTwR$jta57*`uEWBxPxL$0pKE^lPkEwBhWf<LKL1uo-+;0*FYi$IJ<13>x5nkNy
zu5r1gJ%X=r_{8*LZMq^8vg)m6#l0dzCx+IG{Eu`0(djApC;2<x;WHS0n@Zs;9bTO}
zRGXci;$qJ@y;bf%U!9ym&p!4$!TqM^um`}|rgWa@ex$(q!xuqjutr(#{yZ7wn{w|U
zd(u*;vM`mKv_4~p^?n?bUBL-<V5rVky9`G#OYb_9QOesXk{$&@!%fNpEan!2J=pb+
zGyWq4N=rSwOE+)iQGm?i^Dycpl!%Awpoq_Uei~?`&EkDH)@yGUyk4J<FtI=3teftC
zAMsE7#BYVZkh&}Fq|P(OdIU{#gL6hIyY}=BZ13*xhoTS*Fm)Tf_cMB*Wc6BUki}k8
ze(nKbsJ~nQ1{m+x(sgxf0B;Yw#>aUCKk5wi0AZ&XOhOu*y0Sg=Ph(|}tV3W}!cGqd
zdJmxl8K2|90F}=IP5yM?R)A)CpslRBVi@Oj>R4APEX<Ez?BihgUVqU9?*!g#ZGqUc
zNJ9ldE9pGX#Kh2+>^IrFvCs=Flm4~a!!2SDr}i<&aqlobvM+>QjI1|gUg=yHrsu{F
z;Pg-931OYstBM9~W_nI}+5y<b42P34JltB)`mjI>g+Sr+{Q=vAy>hh~YM$wX!_bi&
zGh<r&PQjfcIKQ+u%KRwoN`-+h^VsJ;Hz5~GTAEjh-`L3LoGud?!fE!N_BlxB(l9w<
z3rOsK_)vZT;QnmOaPk1Q_d$`$2_7PIvbjyU9QlEnl<7_)K_8F(QtlOY8NzCmga&O}
zup1F4gYf)Ku6Zp(PR@;J@cnnA^O&`P?wG^^gqmI_mM5iA5KzQDghg|pu{cC|&^on*
z{2`C9cc>rE1I?-*T28$H-%{UNRj#f_FuE~RmG-lYH_S6;c#!S*QMwvsC?c;>5Xm!j
z$p)iEZIV=`e=fANoa(gQ1{rs|k@c7RQr3VZ&O>(qM;UE5%aCIWup~zhY{zK|3s@&>
za!5GVIgTEX+gE3kGf-H@?V+}PdUQA21=;^b*eRjbKU<p|o|WB1X&?CXFw#9Tf<qB<
z_!;L6_sgY0Jq&#^icPQ8(HX68ouGNG!D>?}?A(%un_kc}Q7%Nd&T<9xRYtvTJOr?P
zWeo=pm=7|wC}l@FIJ0vR!VIA7R)RGT#kW6gEn0ThFJQ=QyoT!|petyA<myeKKT0jO
z<+xYT??}fziha9i8iL={i?E6McI_SL8|+nm2z#e**AP$m>J^&_^`>uE@2;)P6T`QQ
zdthMKfQARZ`gZjU4s5?l-CcBV9@@IKcc9WUFeo@~ieN*#dj}j>D5YU{_YUqsGzlNd
z5qywPO*^!v@SVGM_9l4R0PoqgV@IE+7uw;**;z1z6<-J3-P^bC>Oroyggd!LjxtF3
z4A7CY)1%cfyT{An$TzGj>QpUrZJ#Q*Kn!}cqIKNMnd4%o2euBJK*{=bA_efMmP{~=
zRdA2t>^!X!#@~uI=R}k}x>n)gDF0-{vx-eM=YwvRl?;aN-B|30!Ui7dCA2T)OClLs
z=hl}|ox6a<Y*Woq;wQ3`*5`H0!=0}!Tx+cInKzR*Z5o5bnw_P_)g@@tJJumMPHUMs
z_kruuOE5dmeV}9wTb%1+b@gA=y$#ny4W+@cHt4Fx))~*FE}e`vH?TZ-juZ6`b!r!Q
z!oJmjmAm%Ev_5$m>bXyg22?%5HKV+na$G0Gr0pc^^stx!S<jdb$5gtJj^5WB$~{pz
zp!}^3kQ$uCja$Er56Zy%nbZ^1iT<OGVjGaw@8w}D(&G3t^XYT6x1r9n9bx{r0e&97
z8Rs<Mk_T@+>!!HPu&$5}B-(A|R^qk&u<{^09Ad1@gI4cDULkap+qdJ*w0+K<bZy3u
zYmRpCjmP7Vo-{9|&=3E*c);cH;_*fl>78o|+r9ZoY1`%}L7mQd%pgtWo6bWHA|2AW
z+}a~8!?8tdB(L(2>)OZy_Bw0b=f36EFg`D5Ya`QxJfX~NH2STAA2*zKkMfQk@fBI2
z-zny|7xRi$@lx4hdS`?wCdaiUVhX!$(~-h)DXY@J@N2_Zau8jowU>mii{R@Gz8m>F
zFN_kuG&;mR1XyQjw0lAf_4#VziM+54YGgkYwlR_MQ0U*)6~>PhXJrhx1Wx$iiyfU<
zh&>I7bl5M$mb>y^<j<e3Qe|)7&I>nGw)XAZQsIG>-AZvDiukM}SDHLfzB+(}vO;^^
zZ5gkBeAm~(W#KW1&$w;}VVY0+0`7*l%zs~F=`hU;C_511|G&y$1$oWO;I)8lEEmgQ
zBimZWLXNQwBY#IEeLcsL@-YgxKmFyreC#chkG&=zV~88;Q<mGOaK{1b)lR`%nK?W<
zg9B4=Xo{W7$MI&^5%c0vn;OSuT(exO#W>XKu%+h5XRsi}&PY53;bBLhc23r&qBHRr
z7HtUNvs2uo>v{rq>HOF<4y+{D^butf?LPW&W7-H?c(!?+nD?2Vou58f!4G@yiHB#_
zT@2d=hqYzkY!ACaWpOkIC!TFcR|krwa7^3uVr4{k4-g;Y^(X#|wXv%ED&35~FI0x-
z(0pJ}%wnn^<6et2bDomlJ>c<yP}x5jN3%Q==M3z%L-Rlv<@d1U7wo}Rt(K7BVmdcT
z-s=5+gfh4p{76RhSZ;>%d+>W+a6?=?1m8Z;_F|+}orn3L2D-qn2K<#R3EXv?hA`S$
zwy$fcz|ZhnT8~EDH?-h5U!Ff7@t5QLZ_UChyj{-Ae;D!J)#7%lm@}2y%mFFu{qXxx
zOJ$_G9~POKeTj`*e8!x%_|hT5{dMy&e5Wza4!dPfp%3Z`$7s-1FV~QkKc7HfM(Qvy
zShL|y#L)Fn*C9M@lqY4{<59Vbf^x+&#<{37en6||m+*GLu`2Q4{Pc|Eld#hP8?4RC
zxQ^GC4z!c|jK6C@9NW_?BRAX8eX`Ostz+jgOb*t`aME|=5fkZs)*BhN0DdvxXlo}D
zyCO>S68gzSBbp}5w<|2}J}|wAn?lhZT3Et2<GyUq{|1Az{%(u-;&Ap?`on?U^J9He
z5F+6VVfzHOYhj*1lR?6-6?iY}N@AN$piFo+H2Nmx$*4S04|flC4-5|V_wC%e%i7f#
zf>NaoS4AA!eg_yA;}lbdgY)z(6Usiuakh`va5+Mx?^rgiVFKW!^Dgy?aL54Q-f>si
zc@}J4$`0*~7SMXVr9<o-+vbSyQLG3P%O!-gyv-tw#IB9<R-bPW0lmS8e%W{cnxEQV
zA-9jzEbi)o3dTrg$1n<je!>JhRKAO%I7AmO34m>^XBf_aR`4av+k3&@hwv7A8s&dB
z{4a)$61%Sz`=`Dfzbs>y*|^Attj);guN302)VrR}HO=~zqnN+YBfxOX!+b@xG}Z-S
z7&+BFIF__gC}dvNmm^P)wY)yw^6E4&Z?qAf065!n?~l-C5IfFjWxm+AVmS7#>iQ-q
z`zOPX&uyl=j);44Z1_lJ7-LXU_XxW<5T^G04RFt3%_S7E2C}+H_~#Wa@g4_vXK8qH
zW>Vu(w{?{k7b|l-HFtcH>oi?IZX<l69^Owl+f4?K+MRubL!dY$>Tr%jJi3&0Q3dyn
zpy68B)0H$!3H-$lH#(k3`U#7&M*0ZH_?W>pFHZsNd4x&!QXAlvgvD7jnpt+QGruI8
zk>6X)&$G&O8RuOdXIgsMT)QeZ|5K4Z^#<jDI%E~TxxW_TU4A<J{P|E>YuUu8a4|mw
z7lR>r)JeLo>t^7fygUQ%R9672)p^Pp(`B9DT0EC6%G#5dKKjeg;u{acvJGHZte?5_
zBhaB->$D60bz>(-8F68}0mO^f=-&e?eGdbsEBO8&>b?X%vZ7l5rZWr!3=lR&1Z)-&
z5U{f+BVsa>WC&!EkYr{6m8O^5GtDIFkYyHB#C;n#ROGp!qT;@xq9Xbfed<#mZqI$+
z_XU0Lsn6~IeO2e&TX*U14EXf#{iSp7t#j(ssZ*y;Rh_C^Wxvb2PT%2z;n$${dy7`@
zDF_c8T6S&KeuQx^Tz?VEgU#-J)-x3D<J;mr3pk#~Jp-{w5apK0ud{Co^P2@W^NUYi
zjSuQDd<*bgLj!@h)`@NZ|H}up)_m9VZ1C9%9-oK1n-{29GT$hC)d{Y3rrxq1dNJP<
z+sieWYvF)lfi82WE@MylB?n^a=W~!Y_Sq_~V7Fp)Volif2s@rMOr^JV?u7`uUkk#p
zl47o4`%oO`W;1g|>ku<lCa{;RGxQzdyY<YA5Ld4=rJjVH=a{oP3NUqrI&dRs1Ue7e
zs`KL_i&ISkp&u|0*C^J!8~bQwk{5TC07NdMpbH(5#c-l;um?d}u-&?LkoiG*WnSXs
zr%m-M>hW^=3NbGka&$9z<~J}e03B(Y>$g*|6|9Rl09W?zY|yB&p0#){2CiFg`5m{&
zr#6d8f}p*$v|C<k_=xU<$$2#T@&|;&xx(J++{zrz3o)~=`K6uJ3fmR7(Q8rXZUPOx
zxE{jHus6unYTM{Wdna1GGp1I~G;ze91VZw<clUJ}<<;KBc3ayYG;EE0uk-N9w?G%D
zTQ5i6V}5s&|5TZ!`{^6tgKg+4?ZeGThqms6u<d6+7n8oYS&Y?o8zGn{L`^@prFq|+
z?cHmT9@{%U^Bf;Or>}2_`$_8i(b#q-`983=llG727A-&)+yo;pc8XzHgz?nP9XL%b
z9|G?t>}tSj%RBu=2f%QaA+*|(fvg#J3-XROV{v(90TVNonw!S!0mH&rI1Vcqep&s~
z{t^3uZvb3<>~9ho(r>laYs<V5?|NaL&6K-kbFqLe$;>%2(SExF9k6E#Q5Uq2nu9KI
z&tSF(uQar^Dp<SCHX=Shv4XH;F-F4d)hs6QxgyEfNrq!gEIk+mI&H^^2H(z|Gp$!6
zt*i+HfgLqW!b*Cuo!>?{^bm4ep3MifDTM!6;IPCYSkmI$$*%>D?qLG{TBQ4X3pYFy
z-)k`~ReOkR(>evPbpq48ybkf(T5vuH8!<_fVaFqE#R+>e^Vbr{Vr5azcz7$q&ukIn
zVw$|h^Zicgt*UHUztF5^-iCDay0j%?pJENBW9U%dx7Dd%&RVhhETtnEtvfrNZnZ{t
znlY5-5ggd@_B+A99W%*Xk28LH7ht+}>07WXx0&~KZN^6mr}%sD&Nd&q?Y#rf=0ZFC
zZh0O-{pa32Z#VC-jnGG~_w=z*H1`C(9pUIeRyoR{HxpYX=CSgFi+gx9_M(r2xEJ9L
zQyxx50`$Xjj)}Ga;`i<V4a$=3{re<cLRe?h#S|;vbR;87ro%ox{T&<^uFj^`_dU~}
zmS$583w8WyYC~xgtwL~sXKf$D>e<i*z|w3e#~pDS`Xc19o(=sV@?GDCX4*akxayCY
zr-c5nFF+f5XRJKf*Kn13kA10cM)UO8vrV<@W?AO^={wgkQ=h^)$Bg$;q{(--zx=-I
zV|Zt~_;K<Ht!UIwxo5m-T1XGN$##WvrfgU0t>Z~ox$_g^NXHv6QeoTjA4o_08CnnT
zLYTQy>ft91%+|xZz^m57&mep?^^o~tJ^QStfrJ{=vjfV{#zsCQvvk%P2-+}lSlbn~
zHaM_np9gQ$$9nTmroZdZi#q^Zq6P-a)Sr_fFV*ueNE+%J_!8cA{LA$J6F=^~{$<|z
zC_V(*l2BJ$ysy@Yr}i^R6U4v=FFh;sE1-cg@xCtiZ{SWHBp=$h`4*nZyXpvG-^P!Q
z3Z=(9nzjJ3i1%H<)9_pxCZ7(C1iy7)$+WGH<qpWlrEl?CydRNQT!gXyr}0JpO}PmF
zKW)H2`&wx<&chra_ci(^;@Xzn)duSu`3_*FuAqK%y!So4%ii#!pf;R%Xv^?nH)eDM
z_xlK2UW6l&pFN|^W50$pet__@AB38)A0iA`yA+4-EAuAAz<-SQodq_Q`+{>9f-vmN
zuV*nZ48GQUMdl@#9>dUX1fdKgzt$eevza{z^HN$~oXuYo%7AIJF6msH(qK4p98A)=
z;arlA5B4Dei6!}G+KdN|b_1eNlTU>et2<J|nSYmupMaLT{#4~B<$*H7RvP&tb_KBW
zY~=4}h@<21b1$%Y{5is~EkGbQj?Jl4(2Ss*X|qoB)@FWT!U<!QO3|DKHtVW7cF(c>
zaj`K2W(q-U;c8F=`}iyHYVBA{8=uui+>PgR@TRuvH+a|jOuS#?N1OIr-f?Lg%s%2Q
zeo5Sn_uqo6{`>#JJ8jkfq~W8zQrZbxaXW(XLckN^so#fwRQhXv2l|oTUwsK09s51-
zwfwnXG<D(+2!kJIHL}I{rp2SZbajJalneBMJv;d8TFgE*@I$dGqW|04^1pz`zg49^
zaIfM&8hWJ3vEC{fv3j-|o{c`xCui5wWBquzsL`ym#JYMO%!t7`26q@GLg`oRhp4*N
zRN=d;1(QYknE3tGx=a>4|Jmft^!T_0H=J?aut5ew^z^PQQHQs8MS=!ov>lBn?J(z-
zRe$-c`s<w()!!Dps~!>WulUgipFub;)pLFWm%xLbuMs@e-B!F)cMnRV8`DpgdypnL
z)HIpSooK%USS;RYpq~a~+x8*QWdD^k4g(KqcvqP5#nUp(UwEZTbHfI^5Wt;&v>}*o
zOpPJ(KOAY(PLPiy>hN*ZJ>WyfG1=ML{0<!v2uBy!<;ad<+Z>*bs>2icjmkIlO|y*Q
zBlM0zT;31Go%k&8K+Y6s(DwoiHYk8OHt3>O>+|{x$}6JPuq(7pYe73zzG8O{23-8d
zHuvFD4P%$q0Uozihaik?l}*pKU(5r;u=C9#KM_lQ8)fm<3m*5!rJ<tji-qOqYy4Ww
z;vXsan8!8imxzC~gt_aN=-*~utd&sKXj@al^Gj&5Nx#LU%_aN0@@AhKeBp)_mH7p9
zC}fq3@v2xl<dglWMwm*oQd=y+$-upH>e6KS91EJs^i!l~`YtU-XOgtj@!1Bj?m`2C
zHi0^cHljf>(MJ}v9rf|#_%7n|n_sjUqJA<HVAj93c+|@?1DM!g<b}Re*6oL%u4cft
zS+>3h{Mlj`eAc@F|6+^Ju&yvafl9EwI}WgVXMEkqz@l>-T*q`W&XvC}V0sPIsXbvA
zD^_j9Zjmn?zwvoLYPz-oC*WP{J7M?3kA0o{^NuSCL!j6KwH+q{m-gZ$+&TUt9c`N)
zfM<97MOYR;cl^aPP9<4{oAhB*Zoznnm-0y;oQr2^VDCrL!bMmP_mF-F+im)p2i7)3
zZ8E;Q<hm8p=`>FRVcFL;&}M%04Dc7^>ku+XZawe%I(=XE8sewv1-#HnBL}#f87{70
zuW-+(g&L-{_nD@n?lEh_vJN>dCca1*u=BamasZ>kFWccWkr$TbC#0`=GTyDmVP?rr
zXGjxf`;n&r?v58v#XHx&&~Bb?Vc6FS3$<h{^gz<1{X=`eI!W1Cxm$V<BHZlwCu0DK
zcNW6IK%wG?bMmwW%nNEASg`Z-YD+NpXW2r0%@^wg+wQ}>6EY75J-u{H6RTN4A0n1<
zR7Gr?EM}x}+il1F=O8WeKwG2rgmsCsKAU`?E}q9b9|ce9uPF~(&n&HW;1Q<-ckQQ;
z7HL0(G(fA9cRq?=rVH;{$AdJ{SL_iyg@rT_InW84?h8>j)fRLk9@Ff@owk7S$fME;
z(f}|0k_LHxD4uQp?OLxK-btrd?&ssKb(}OGhM#LgNQ1OB-}IFPJj0&o9^<4j0K9+?
zz(V=j{LrsTJf&gNYVkHPO<V~Y$e}AQ+M$rgFrN0OH-ZlHHjMlHJ+Muv!51{JNcB6h
z(0B6Aw8Q-4Maq+~3&B$$H^*KP#x<Jt;;F2Rp2hn1(e%P{|A5$$4M<b$2(xDF!^08g
z+KxfItL+%Fu!!v#Aq~fNFdwe%xQOr++cAdlG~2=aG_xHXbI@LlgN9zs?1jl-#7fjJ
zF0IRI7pPa1|0L6k$ym!K4R$$fX}xlblnpcC=mPusVZ6}Sa68J4^Q-ikLPmN#B){Y~
zYje1^kKuaeJl`RgB9`R@YhB<ADB;UNgHNC2vDP<W&IHkQL+Hm<NR;m^j}s9GEg)Q8
zHXg&Wpu198s$K&dLp-L1J|5QfSIo>O!}yJQ&h-0sdDmkentsj;AVWJAx#z7d`^=j`
zCq5<_MOd9PY=h>aX;Ut3+r^;eo@cuS@9ufFOv^pb_7c3u&$DHi^5~vtJB4tJlT3Y^
zw$G8XYS~URyxDoS)IFBBwBs!^h*PhxyVby=eO=C1@Vl06fa!Iql#c6#Ud?<3`&B%%
zcDqAM>*PHzY4)(|9benLU)AWFw55BvCYrY4a^#V=;n@e!m!#fh&%Vc<NPNgT)U+RY
zljVn|#ks_fhmje^w|2stANOz}c(8%uY+<fgF64XtLaw8;yQ@$xlzQ5W{hfYip}W*k
z>T1vB%6;8M+tEFLwb%m#SC&h;T)*Gm5$s$0NRb`o_$WNvK2@fT;d~aE#`A!$4LGr3
zK0HjY-B&1<+xrT=y~WN>zr9@UDq`av-|y(@EmaD=x!x$-O|c_vYk%!Z@JF5txNBdB
zOp@;_@M9mZ$UClkT@HS+(AC{h>MQmYD&_u41$+PIIttynUf=KXySqE18ET3h$&l%L
zw-|ZrSkVXHS`HOFGk^LmbRO>|{C42Sz6fnU_5Tt0u{TvU_po2PQ}80PLBDoafR{0Q
zS+V}8JZ;*x4>$)r*UvwnMh~*C2|dnjnmz;O-4_h5?Z=k!Ode+Cel_k)kL9K1w~XhY
z{LmlO@?-y*GSU8X1P`HZUUmbIdC@-R3f`IS9^AFhM_POFGnd=WBOpv4F9IW<jHCSz
zo_n8;XJw{k6OlRcqcU>&cntY~{H_&#60l5^59))K73W=4cI*?8rzen((<jpU@<fD_
zw(=gwOQzf6J(;v{G5?IW9<tUs=j#At{vI#)r{b=1Ql6fMuyi?P+E`A+Q~vhjU3m!N
zFmb1Ro&g+|gOM5HJ`2yhOgyx`K|IJ>=YzP<HrwxOfU9l)nP++M!?t=)N0=JVrj^$8
zt6DtDoGWFxP)Wz@&v9sT?&vAfw^~AYdf#dltq<%1`&Ij5w3(MjBdkupY88a758<((
z;r6E<hj+I>#WdXh)RXWY?@uvIW$N~)o`P`gPd(E<C;C$iZ`Plp&bj@mXCqF%{?u~~
zEZU!<-N$<8*5?7H7yCeFa%?s2Z*!$!hiKI*lxFwY=F+aQon?RR`WUZiey~*(a-)vg
zs`@Uh%P#;gYV%mv$?FZupVZ3(@!!c}pnKQt%5QJl?;`KyRqf=BvFH7c-C=vGHs~dI
zRvX0l|AHTF^GkWhr7+TavA|vyg9Y&-cDtpGakPDZC7#trs$5N4XqQ8qYul2WfvYz6
zCOi}W6>@(S?wVI?OKq9CcJ;L;zV&qkd?TG#Bb*oWbPJvXzQN_|1V-9iyG%K%9eojC
zTIbb{z6N1h37U6V?OaBh9esmCn|4&o<&6l}y8I?Q>vceNxjAEQU2cjUught=@n+#w
z%kSlQXZgKe?r+5%d2Hjjzt!Y7WAsGJ^6h}HM|qI;t#}T~5AB=koyzDPfG6+}SIb%Z
zL+=D0dAJRC_SKj+*S5Y(;u998gBPd$<+)S!V9|Ijp5~o8#6G&#Me4pjbN^Z9m3*`R
zLfY@g&+WhHezEMoa8CULxOd@P6~<A1;&GTJVJbWFMjq}U?aUhQgS_J+jXUwYsys1*
zBMbV3!gyhS;~CQSzYTQL+y2#ALAL$x1`Vxix+dkl2&>cfua2<zQ*H+xxBY(~-re?}
z>A3Cxzv4aK{xeMZbKCz9Aza)4kJ#r#`_J%Z?LW)VZU6rbaq6}IA2qOO`>#Hbj{&Av
zJs-&Ggx925T~*s;?fPHDw@%&69E&{w@nb#wcj1*f%zc$@U9oXK2^e)Y9_Ld*oEB5p
zw4J#N;ab<O26=t{jD(XG$7-w_pB5Ub<7!tvi}18GKQH*SU!<Y->k9~Hy<_-6s4tcm
z%l{VvQ@UTmb2wJSI@#F!SIoOz^G!R!x_?8eKLvX~^5YY%PpVXRVAr>NVR6UqxF@At
zX~#Idy`#NYDRlPdD(&sv@JjS`^>_AEI(j?pA%;Out|>OGf1%vj*VEZm!8biYKJYEV
z*KHo#zJa@z!?*D4mZOfLDL3MM8$WZo_5}ff%|ajKJAy;KU>wrZatZJveGZGa-<E}0
z+ww!i(>SE@ebNN&AMuVW0gKSHWyrC25)bPl0~&U`|6{yUPk$o!pP6_T_B{#vf!sfg
zyXK4S0iP)|eWo7UXUoH{48DE-HJ-`OFL4j@1R8haofpqI=a}iccvoAc{g$62O#3ZO
ziyZAU=S`V^j6(M=z-NaQZPYd6H~y_dpSGGjl@Jz`4Yk3<wR+5P$$!Z^DX#PW@p}9Q
zk=5s%yr`^xfiRU-Q;(g<ify(#R;K*ydPpvPvGQbl-p27XR<v?FO&qrG__ocT-?6+?
z$Jqbv@I?7?yo7VzTYqQLU^*V>K>lHVNq&p503J@m?;xn(y|7h<&YnV{0w-@fT)cjv
zqra<wtFy1ar_|f;mr7A@V^i#?t)gB2U&u^t(;xAywuJVGus^9x#U8OfGF;maKD&11
zuXtCRK-gdKqg}zKhvuSvq+Hm(@muf&Zi<~@e>aJTHJL(F`_wIXr=4k)`$4!XziL02
zN7sI=0}g2)jC;T@BytGed8y6#GvdW<##-QLJ!mR=(Q)P_&1M`5T1uZfO`V}#I869p
ztX0~D=B&7*o2J-NoiX3Af)|$Iq1XqH^5q$yRtGX|e-QbqpZLQl<M=mOZO9YjQO6kX
z3AQa~$vc<rF>^(lpLchAPwt3eeIVJhZDmN^Z*+K&o{oWZngdwpqdxT`z}u1d9W6W_
zgS*y=Q^B46b`cNjTD@Zd<HdSJJl3PI{kP|aFrW7YO!e>Z;MulW_rtrJ_6dB)PxYO2
zvFOdLRlYy(xCkRJ_WLb7fR_^;80$a~4_s+H@-ipoqkA86ZkWC`-cOUC^2~fQKcwfa
zJIFf)X=pt90@x=v-!n@*7x#4Fk`C#zjLCBrVdU#n{8;~W&nWE&o`G=9cPQr;?@Z$3
zB0cg-SrYGTga`R_=q1xaWXFDyXXPnM!^N}Zb1u@*y_Oz?XUgKiaz97z=i#n=hh@^@
zJp|#rlKg~wC#B^>_f^tydWWRb>7?W4yJl>PO^1H=5QfAh->kQk9qTQo1cGlUHvrDx
zTco`|328K{VeCIW064C#;{Gx@gxN)9)>qx7@3H-5x)C0JTVU4^_aLm<{xZG5!H6$d
zw-)Fc`q_Pe(S~pjnSO&uT;?;qzNhVD{I{?n)Xz4^ay|6(DfiN*1!K_WW)0terstD(
zP3`dckPCmIead(j$h)oI_KZO0;b923?Ypf5952$wF<fn&#@UE4#@U2B>t!GV*bc4N
z!-7NoQ(MaTq&J8kzr)zfJ1*sycIrZeX}t<?kw%Cc&M#gBT&7L`pz=YUY(B&XB;%wl
z2q(R9{GxWq;xRtcy+rT~kB)s&9+}nzZ~~cPo^u-Sj2le@=}0|H(hXs1XC^^|@|lwR
zR=ID(ooUf#k#C;qm`p2bTjF_$+m_3O_T@sG_@vEpCGAK#AzXcVgwbCXl#4UZNFHhT
zl}FkhwiTx_2)5@|u{EPeBWY_Qns2^wxEOeGd$S#3uDyALzQ^p%qYxgqH&-C6nZ3CZ
zIB|Q!c0*;u`b~RNFnGje-qPz~n!SnS(z=ooq8LD*1%D0ex7IP9Cr!EM3?nUG8GO0#
zEKlucupIP99J^Mj)!P9arAL1aVeF%^)>j=E%a$<e24TA#7-i(b<^Vg8wKyV|d%PH@
zx!cXIZ?1tawGDjUk9=s}ug1ITK4A;^aSXG_J0D>S8Ls1|WjtG(W9{V%-V^a*<93Jf
zjSq&tw*(&2*(-QDu35r6WxYr4`*5eNBM)k;9*yUKSJYGGmGmPpaIJi3|Kc%1_p!Jq
z_;KnrVJzP;9WdqCHS!q3!hDcd%1CWLb(DBdz>fyOrJ?lGV6-72{b;;M+5ovU>7Nhd
zh5mV+o4*Ep*qR$(4YwL?wEdlHLBq9C>?b`AVU7Ls4b|M(zUx54_02yX@2+p2X}G@m
zC*nQsn`fBv=KAKJgmCrEKiNJfeDe%%=9@Qm(OK*G6vV0Ln}4c-MSb%+-~BYe^io@T
zPfDbbXMQ#ILF<6)i{}|dylC6lk5RqlyP2C1J?6Wyna(@+C1Jbq3dAE^-&xQ3&c2Qd
zXTO5)3O9BZ@9gIjU*FjllULf~aJ+=LPMu`ggkzErrhOQWxsJw<bjWu|C*$29<)OG7
z3%R%<-Hdmm;IgihAKE2tZ<q%CcrV61nNF+s5+^SCb>lKk#(kL+H%zzHyD5lkZLg+r
zS|l%!eGE_O5ig|I;@up>V_(aa`K$5HJiZ2Z*XG}Xch#G4{MF*U7U8_KZDIe)rT2Qg
zlinL}cj>(m?@I4sc-B7XoAAs_%j7ob7Ux7rlX*dB+ItIdT)3VCt?;)2u5+mxpKTHK
zGNiM{yETSKI(ojRi}z08F%Qf)^FY{bc%}}sk4hNxps@D{%=AePv)`O!hn8A#qIi{G
zTE?ND)e_FzsIAN|!xKD;UECJu%$a5Iuh?^qqPSz#x$3fu2H!F9T4OXPc^J^r(r9_C
zik;3a&YBp`)=})j4G*;WwjJL{lFmUP&a{s&F00G?5=jzoZHPBKU!JId%Ngv<>vCr3
z9US5fE-lqcRk*k|;ncEOpU19D))pg~v3#xz<5>C3mq%;qLNaL_65<c<UG_Oak;?O-
zAs*PB_9ID)91ja|He(Ce1vf*?_xcb%UR%bAR@lr08A(m=@DSI)w^eKQJUW-Cq<ch&
z8&7w5uaw`BA<m|Sl_?|1`Q^phYzn<L2R9HmHgCtuWwXb@QE70q9XSw$r=vrh5qxEM
zO{8=M=a>*jWuIPBf`4p?zrC<4LeZ4vaUpyoHY(YHGC=7&)k5gpC&Zh^cRx6>3e{(-
zFu!YKwXl?ef8P+Fdb+r+ift3I|JpUC_}mCq2agZ&H|;CUnj>%A0#_N`&%vAZ3yb!U
zM@!>`5H`vs;}svDqnDC-zJG|fi8Lnt!Y(N27Jm+V7Meo}Exi*%JcVKR+$8TOg?Q6g
z?(bup`8ik(Q|>2+uua&syHK6?7e}#22X*@aA#Ai(N4<#mzz}b`I$N8n)s}~_SzT$F
zTP#ZXoZ;a3i@W_rVw&2V<o7{oxXAaS<$kEJTrj+!nT9tSY~EpT&Pv0XTA9ZtA3LVa
z=KNNcXNP#OEpkv2Dzftb;1F(QZH{ARRZsGNPKX=GbjF|c=X`vj58+Z~=Y}|x#Pq%;
zY|KK*N!>m#gb$-gcI=y3g!%_eoAP-`h%;l3y%?Rt<^W4IoUxM1ms5ZBxP^9?d-CPf
zU&ZN&<2ZFzaXRBTPQ6u}t~icUXBDSAj^or*#p#LTICWETdgC}wy;PjOIF3_46{kOr
z<J3*XY0tSxqVG=K4Dcet7CfhJ26z#H3!YO?1H6dP1<$Fo0bWG#f|m_-XWU<|Q@I8A
z6bH9K8`q(A<<t<rZac^GJg9G{g}CMzGMpMV%X4W6J3WM@S_|ShwkODMM2RF1j{OPn
zB8nt<j_nEXBFZFqj_nEXA_^sVj{OPnB1$EAj{Q-*jx@b;>`;K0rdN&)3h>hO%CSQM
zUYcGx_9(zh(<{d&1$b%Yk@L0`_6A*9R-jGT<9o@w0Q)A5q9f1o*zM>m=P#PrII;1f
z;Y~9<lV#J`;PkZJCMg9#pTC|5>Uq|rO25|-4|-?g>{QPhJKWL;&yp~B@NOFuol4L2
zjD5kjx{EI*>*J#ZVV`#q9db4?)MK0>Umt%8CmW$-&i#ssdr%`>h?Se3vo3CfEHR`s
zvb=+`oW5*&W_U|}a%y7J@bq-vNON>#6vu~-PK=9K8{$C1hOX|FWsVqK!U^j5aL?{J
z5uWm8&mTpR8lGFc6kK!gx`ZQdEc=Y``vLHqjA409hFiWk_A>qn4h6-BYy1=Pe)JmU
zdvZyecpvRJ_5_-=!z1O@fe-n`l^u3)ruHr4Iq(^C<e150s~f&)whFpv?QNN@abYul
zaj;xw@td+g$c2s0p$|9CqdW}FwFwyOiiI8Q!fdZZ>YRnIbKy8mxW>_&t!9SyAuik;
zk+g+Jwi(!=E^K<ae4#nrI!ya87jA)OWJ&#8@50RJWw3%>$C0?DeYgvs#Ae&rNyjgb
z2WcPS!biCqq!bUf1|j_;UHI0yCENM2v~kvYShicL%hesGGc>WlE|KWsQ7#ThFQcmp
z=$JX6QS9;2E{?6=5gj?kg~N`S%uC#3UD&3b)!DK{oiy9Bm^>Wk;tb*ptp%P$VtAcI
zM-Mu%B-mDe?&IQb=SJ?kWb|g?_jTdZ*!pB*!JkL6a|_E8i&Y$qhH|gstR2elco%o$
zd~I||#-XCC_jBQL02%m;@N<HTvuUT<hnckR?}mr+A6zL{m$eXxcVYw&+uLE_F(c>o
z5Pp&ir?ITfqdG~JMb0O?IK%UW;w*B_k}S+#YWnsgKDO0EHIsZjz{Q81WPPU1;JN{G
z!DiUKfv$rYa<A3TZRvgvsYn0n)(-K7JuqJzVEeLS`|hNzo}A7P&fu))jaz4i^W$5$
zh<T0&BdS@4^by429D}iePJTFFLzvFjd>qfNukGLQ{u|6mQsy4yV>@9oh_VADqcb?c
zR$wEA>g<F$;FT)o+C&@I!ck>d5;jQWPx~0+4Da<vjB`ucKNq&eD#R9?{Zha|ffAo~
zG7{gINvr>~lNL6;VvehoIJA*ATpC7`r=`HZNZEW8KhDE{f_Gd!C=0l-O}qI?ghA$;
za9lOY0f)ii{BZc#w|B(?Sq@h@avX;-SsYrim0D~nWjKY6+~H&kA)?EsO_|+O*tZmd
zSSFMiI1enaupjK(67Y`_R{rU8<hnDK^G4)ljpXGn<b`@QJu{TQaBzHRERvx#2yzAf
zNRN7>b6B6jGt>PXe)MzdTBZx|&4=odm{q?#&0{SV$5DMvIa3BP*x(Azw}88|#0G%z
zDT^4+CcrjB+l($!CNcOR;-gEq2aUPKVS5|H8Cxn?81*OygGI%egwj4xmy+<AQqj?=
zBwV_GQl4ykV>mFOHhs3cF&M3pku&?fT5j9}gYW+dIkR-oZ<|3!cz7s3J-T@u=gk{M
zOoP~RqYwQHQdUOCow6b<T8>D_nLCNb3t_rW<MW_Pi}5A7e_8Hd!TnmN9t8QMaW`6E
z>uW?02n!I$sylXC-&8~oA~-2}K)BfSWZt6dLZW#KVeEfuUHKaF5tZ!BWs_3%li^n0
zI;Z?~k;OM~*LjSfo}vskiG3z)86ETx7Rs6HMp*Wow*XIf|HY9h9i>x#0gfIz#jGqS
z&oCUewX{O}OLJq+jnH}(;#}-6&ik`!zgee3*r?g#b`G`D^hiYSS*JoAbli~oZWbJ8
z791NL;tZk@*o}VQ6#IDeb(;Fk`W51AuPyGHnBVB{EX-mbAM#0?jiL-uP%m{&{-+?*
z#9|S<bE}y%{xsk^-^;bcT%Y$<gt_ZwzNPQ6^)lZ^cznIgcM#TWz07xk18oV`=eh02
z_W+~5Y#+RMIFCkTIv8k01KEDC@4<C7-#7F~lV$&Z-}m@opj*?!`R(X;Oio^EOw8cS
z)~VtA#MJ2K(eeEF#7utM;Mge693LJMTiytN>-fdv6Whl{FED;?KpQDe&rD1WYrSrS
zi-XRGCbmxpI@t(!czkAfYI16HdRY5<W^EP)3tKmi`i`^Ejg9>gWZr<1HMI>8Sbpq#
z+4TUH{ue{Jnz6lfN8uATUuc=CCH*8?uZ{HnQvcN_(F7k}Y@P^dWv2d#CULedVPr9b
z0Rav)G<$0?J@r*IiECzqC`X<nrgrjY)Nk<_jG&K1h1oPQJ~Fy_>y&XT<frMonHbMI
z_H)(v)~@oKYb%$LiOJz{=_8B`PmGKWZVvQdWYg5xh=Hy1MkYsLtQn`x8yTM%9lvmR
zYIH_zUDg|c!VQlPN!$T%WN3JsmE(2Z$jtDiGuV$)`!W|JJ8(X29nNnZr|wz27B38+
z8lK*|MRYgggpW;(Z@y^jmPt*w)qzb9&lvvJIAL&Z1w6XpqvNLDnZ6wRrCF%gFCh2m
z`E5ov<}-lpU1<<2OWG#&3H_2~7iPmLplBd<o97o%p2n{>ISX&YBs9s+Wf*-mVQAoO
zu(9JtCr!9E&cC^vbq-Waox9u7oym!bvHaNRmeHB~7PzP!UeqC#L?B<fwt#*g)<3qH
z9PRuTwB7fkF@Mi}N^Ks%{*Yhhc-t=ro**=-<&AK2;Ba^Qy_MCuy0~MAJzo-^M#f9U
z+YXnD9}=~FpVkJrN|b4@NyjsNMK^Cg@;2qzvj3r6DaE1TAv*WaVGM_oj$|95SlQa|
zRCHXavgO{HVfyx*p_^UVV%`sPqn!J~m#8>5Rq9y_^8?u6tU2m#a2^wp0ZK3qvN(tj
zUskn@E{LfoMrM}oFrrs6)}N_uK}X0T5y%X95{$lw88I1|RU8@pNn|uJby<G$!po*1
zr!g9?85pk7nafbup^46LkMeAeYwOrWfh^3iAjZpy>E5|2Cg!j=Z=}D3GlRIbiNRU)
z;jNg@FW1Z_Xm;M6<F|~|m%otbIQASzO?DuV24Xp0k-|@91qY*G9=kBVV)p5?x*k$T
zw-NiYDT3A8jFb92n3UMC4Pl+eq_Kk~C^$4Z$)pRja_b4kk7+HDIxvlcbjYt1R%WqZ
zq%HGC_|xd5R?+jcc|hA>okCEMuoYI?VSoD2rg-8G6TMyE5Pt?ke#`5T4e?CgCg3?(
zgytK)Z;Vg1wr5T7%v#pZ4COyHGnP+pjL{cDcW&k~(U|6l)Ss(@a@jUDl7~-faI<OT
z*-)ZeI6fTI?-cmZ@W|lSv7lXR@ltWN4UbJsZb5fV+saHD-lpNHnQ*>Bd;ux+B6z69
zQ=^+^gvT{$bVtTUH(xlDpBbFmJj~9ml<7eYaEBm-@rmh~(M{8)oYpqL-7*1V0<n*8
zwmNXI2Y+5Z$v6A79D`z;T~n58Se8jNDZ3<qW%Y*Bw2ia=h{O^L$(!~uW%O2COqs*h
zKIJ5qs?bxHwpK;^j$A}DQ5h=iOQ93YZ55Vxx?tAb*j$ziHs!lk=DIdvTS(IZbulC_
z2Mf-S&x-CMXq}JDt<|ugCN)Fk=MbSa!ZV^=Qj*r84nNGZi^BMa2^=#iE3*-(<z>CV
z$FS{X8vVlsj#jI*i)%hoXdEFprmHnsOI`1Eq~K_eERIHA+XN?^+d(1IYan&yD1qDA
zFE^()FGo9kz%w7=l=P1g__p#K9SS~<$##jD@;x@h*;tFLuCr+zCvei=#8Yrw3Q{Kb
zQ9dAwnL=dIq)Fqx0ym4U7FQP1*7+STI7161x*~RCvdm4%(7B)Tg0|E4Qd|_v?+Jo4
zRx6Y@m#agIRakQuO?bY);BCb@W_2)4nkNb#b#1VG)ymQ`y)rIAo9;=1H@z}9hf~Fp
z>`A&O3*MG04>e1ovD_XYI8HT5Xd>~lf;Umb1d_k(=R|K#k?`TYCEv`)xa<larwY!d
z#lq6gp_RD>(@k>`ZN5$uJnOA8ld%}OCh<;JdgxL5dzYv8R55ShqDi_B6g-_$zhtGh
zTu8w?L-6b(M(IP$aEi%Awmd#aaJ3gP?PD31tw^Q}&lLDJe-TR%{6)<D*42x%Vz^W2
zG4J-1=#>B2LAu5R2aPR9*^@j!Sn$UD9fi`qbXw;K&L(?C4%O{)`0U-xn!KE=v}(0o
zSgTx)U`TrB2@Z)&&sG=Emk*X+XxsV_!I`#eAnX*4=ua*R8}eZbbq=UK3QO?UA#g1H
z+~Gr~($*7q3XYbCON4Umios`guFUVUieTFM?kEq^gt}C$Ui1iF%of<jXnFy*-S!81
z1#cXOIS1|W7JJq+`RNn5nJR}`r|Eyc;OL^;6sAo1Z4kUEzl24gW^Hu1s?rS1XkRQ}
z4;5TYzfR7sEXlmIg`F=j@;ta3Q-Z7-)|?m_Jxt(1ekN;s()hkW@P^Sim@1R#uvl3>
zJdPI-PRe~iab@v$z4mQT@WyJGkn?8?`~0#Que%f}|BZsTvAQGPj2fA461eCxabnGo
z&BIU>4<)?dm$y~@J#K<hhlU0B!rJlzr$Aj4@-!lF+cuj83K;8#>o+zFd^;nTYdcsM
z7p)+I_1qVx;kXG2FQbAtR@(uWNw^rpMI}!cDZSdBo-V6Z4vMxCR(~!QTx*B@#gXdb
z9B1$1CRSM{{V|DC4_9r=7QsvO!LV|kbjAg)^&kFF__7>U#STpf-t-FWdBu;Ff-TcY
zP0M&TxC$gm=Muq5>%)L0qeD}IW7o21OQMU2k~F6UKdc6@{lUugB>s%xYo0f;H$R*F
z{DAV=8mAqvyCTPJf`{3i)c(PCfln{^_|9WCweDORO=~o5ZU1G0W0okzKM@ffy<BkU
zL?52tUB$s>@s5&_^CJZBLO9&v7g&mR^K6+uQgBpOjx>XBFCHa0X$>W1c!j{th@J%>
zOv%YA7>B6pZC>JRLW{o`(@4_1QsCMSOvVj^$f6*4%Kr#mC6U2~&1X^YWORhK66>X+
z3)+p$N)f!F>e4Qkc}uGt@Fsl`r}Kyy_^POACL}elzTiunhc$~ZUt9v_l9v2b1b1j3
zj_|0K(nN0f+#z^eEWp104z71gp|>;6>y~N>PC3NdYR>s|qfqYEIR3^(xQVBcC%ab{
zajp^^`Hn=E_qmj;oOTIb+?K)_8voA6*s9rh+70UXoZwF5!;3UI&I?@ozF3fe4nQ;?
zHNhFIE>9QmSr)RmP0!0>J{JVOZD*NP&CQ@GgR2FO50VmHYsOy`_&6H--SCX#bGHPI
zCBX^mJ4?KVlNQ7-FAIFEwnq)+Xw9V}db1*U)+XS?sD+3&7=CvPj@A|V<S9~H$oC$>
zOB-{m4c{v`QlFN6mx|cTeS$+(XT69!RhZT_f-_iJsG5ayDS3Oe;1~%yb<IU3t;Y!7
zB`f~oJ_k?o>7pBXJXY|fFO$;cv3h*1rVl09yjWP+SuMG_HM;varBzy7DNgR(hq5lD
z44h56*D1Y1nIcZ`^>~2??HwK}^a)_RhcDg+u@AjT^9h27K5G$63hSpTI`TxpA0`><
z2ORZu5kTdj`Yszb-%kqY&vVf0BA9$US@}fMN~hUIIQ{X_kMqHrrSlZUGfP5~@TUqq
zY^Q>pC){8x=cft2^?~sdsU*#(Cvb-6SI{jq{caasWb+Kcx83@g+Cpu%wj(7k&y3)0
z+F6*#!jcqv`vs5n5%w=qWtoR(2|UQDqpuFRpbdVu;BSJRcRHrVY=FKK#rCnDBlvbX
zFS)Qjd>4^?JXiUEBC_dr;6d8YOVDz##7<o=IO)1IRY>diKVQ?vm#`dCadpfRhl<0M
z>R4d~N47>sQRMdp5@!T{DUqGajM2*%3Qk==irA+c1dr0$f`K=Wn01LUy%!12bghC(
zx*{-L46ENa3eGSN<=Nz;XJNjKbwz2*<X;4DqEbOy<I@vlXJ%ZIqK_{Y+(18MDkoxi
z1otI^t8E>}yYr>$EWS66b#W}eFI9fa)kqhV`F)wdwqUZXQYc}PE@m1e&6|{l`CxB&
zX&FlrnOZVKHqDm{eptup>ZnGl4%2^y;05_MeE>SlA~`qZ{7S*yHizYsQneEXL-@T}
zaAy|bR`ko0VzLs$ChfDmO7NpPWIW}@_P$!+k^Wb*iWxp%Be-_$xnJhY8%M8hu`}<t
z2;PM_Zk6Lh9qDpL%@}JG2o}RF#e2An`&x-RjpBlHBH@uI&g%pROYq^KD5Kkg@4zEs
zwPp2s!P~YphhmT~23%%Erf(3updm@2$aLSRyz!%Yv-HObignl}OWZdJZi-yv=tj10
z7JT{Y0*6LJrKMd9bjVFacz=t;<7cS+;Lb%MA8%DYjF4QYmC@TG@R$ok(s;Yzm`@nC
z`-{d!$H^V^?^Mrj6&!1)t+s)0Hur9#Ca>?%G~GUbpvi^#YQ-o@xQ&AF@lJ^s2xfZO
zhkG{K<O}Y*l%JJ_1(;>j6g!1qTO3@(hYM5&^OXT*berJXHq$J(O7Q&dG@k1iNz#0e
z;MecWSoyy<plkX>BhYA!%W)E~GpBRA;J9@dxfb=eHu-&mqpLSrFKs6QgIJm!@mt<e
z7tegG?Jsi+3t3bB{(v`UY-Uux>MzB$SmgeJv^bnFDMbdLMi2f~a9N&a+?N=ASQ&j#
z@J8U!j5yUK%?}AYC}R55w-lm7UctRnaIK!Q=^CCdE$&N9d9VyWEV#zOhz0>8Vti{K
zX*f+jJ|cLwe6|(fM#I8%SA}do{!Q@0w!=Ey;+<!v{ZYYHznSUzq)&kw9zG`c5qo0?
zNcIaQmmQJC$75-vejYEl|1P-n3yIek5{YkIVe|P3!5x|_Z03>M$>zl3eNymH0<(qP
zzU?ZdP^CORCAjQcarUj5?f(zKkI2L7VZ6yQ^1Dm$$Na(qbfXsCu)^~DX~8kAXNN0L
z3;&G3wY_6Pk%mEJ`PnqyruWU`lM3{S6EmiUzt3sfDJx-IPAIF-H^2pN@y?W?|DVw~
z#t2TY6qibi)zrH21;MxVsIgX%r!Oi#`^8JtW|wO#zb`2dd!`C=<(SJ#WcOvk*}l^+
zj4sSowU6OaV|rf^yrF6Zor5XN>zj`#T{M&LuZDP=xNk=)rlkF~5EpKk*?pK`!AE*-
zC7YPHGj-M`e?7#vQ-Td5kmqj*zO^4P+9@{kn}V}(1)nG)X?~3CW{PyaB{+26CN{N^
zynI`5BK3oloYr4w+)>)Le<uysNXx~x-^G4ca3Oayry@IGxGWmEf6w9Za(}TFYsC%D
z_m$Q{NvA{-bbinfr^EDde<(P%PZ_ilQ<y$tU0B*#jVxj?Y5$1dx?86Z)3jgULUtEn
zt<R5Tt<PGn^^v8n{L+1Di(NhKe(_!p%ymEZOj$3}E#L6iRj~5yK>SSE-L-1jtQ5xC
z^yw%AmxAaB&f)dE^lu?|&YA9Xp3N8>b69{V$B{(=pkmK}$bq3lkVkXj8<<;VPdR=A
z^Cs{d!hj)pxB%-G+rR<g%kbAzhmOJ*5{H6LX|{&bqwV`)c*kCTIENLVU{uTUA;xd8
zF7Y5}a9d`*rVG+oZ)p}eM%ir4f1__gb&ozcglGNy^7(1hb#HbHi^UkIBR5En-`yPn
z-nstvP<+S9XZ?<|4bSd(oJZkZzcnJ>k@#`n&ZBwfqtMz93ZP~7;5@cYoa2Hx7Vn!_
z@0&*ZzJkZSI<XDDcMRUSLi|2*KOXl)JlPx2<%#(q-u;0e@D3eO-qT>pBfq&~+9yhy
zC#9yD)VDAlL>7Icj3`(A&XIaYyi@SgJrBt@`N`p)1|to|TQ7M!9dXmrO2~zTg%1P6
zBK<I4xNqkTSc}Oz!TMtBUfxs<ttW848AW7u;n|+|1751$)zMV$-FX7y#P;rNtlp@X
zJg4hq#B;yBGW(??%-ypyi+6WV&r|WP`*1SduwG+t7`(^#^JJK&;qK@8KuagFhbP0E
z?cvGtf|RW2j7@26IRo+P?c@0%1B>qCNgHvDw>xttV0y*(@oX$an9#(T;u52Qjo8+}
zMpp_;SXn+_Lf5gJpNC^%VR<pX?AW?=1Y@&lZ_Y+u)ZRQ8&sr}&26+*74)f~N=L0&|
ze3fkw>(hCX_6>Gld72pKa?de^yiyMkFZbnq-!Ju4DwWRm?qbF7F5%>>j?RusXGd4g
z@3a<L&ogO?%|j1+i<NS&yNs{r&3C&w@JQP#`#r~a<XRh?&Bayz@e{dv{H|iIztq*2
z>*y%rkn>!3Uwf{rz1&^tDdtLDr6_Anu_LUZUQ&J?EGzJK&*cZc`uxt`-tO-1{!)Lr
z2xfabdpi3%`nt;9eph#t$)?y5CM}O$B0t?XwH@!B_;ur_wvu}A5d7H6^q4!_HJm?!
zb5>MOnOByB?g83|_kR5Ny^1Lm>{Gu1?~KPX(|G6OS@oNEggp#DbBSH1EEz8Cv1xb6
zr}9VG!x;zd?f~z&60i&c9eU)CWutBKCcG!(w0J`SJ$rW8Al}L6M!65;uKZbgnKtIh
zrF|jZNqaNy0k24V6z{zFogHoV1$b8*tLI*gAZ*q319gJuS21rmu@3H<e3kp)koH9m
zZTGC7iw!RE?KiLC*~I^-I^EJnomBnUf@fDh2pd<Po$_S3s~@iZ5;n;=(2q+bu9kHG
zbMzw#OX|TC=ui))<vxQu^?>wL56HW#2ix&Z+S_ms(nU@$#XB$6g9*IH^<XQ)R1ccg
z^9FiwnM2#vgUf{n^1*MPo9jVyF4(fJn&*UVvVGtj%9u8UZ6Ei%cqI6woZo@I@p{Nk
z?G5|Nx+n1!%nR&IUT|rfL^s-6@T|I3#Iux7+h6gGmxh-mTy0_r?>>G@_X%wTX%_JF
zGOb>PcU-h>3|Bfk@$Bj@VO7CZTg1H4j%s_(cee4&>qC#Xc{ktx;r%r1U!Xj3pAqs;
zUPBw(>doU_Z5r*b>T<v@>c9fRc_m<xI$-VH)xf2mFUoxf?vy|C=IZt`-bs&bN01gI
zv4VGAw~39r3h!~<UP74aNz;Z_bem<uUaR?#&VJ`+Y#+;M9eSSTi$08%IaZ}jWZAWO
za+<krRcc%Z`9<BUfp&7Y!yoGh`xWbOCfXj89@FI6fd9yTg{>FdLpv<@7H=Q;3+e^N
zt*R%dg5Uk9J7zot-Ll`3VttCix3pNd0$M1uYXReV*Y$i5OPq>maz2_J`=AXfV0g~S
z>?UUl$!Oe(FfcG+iNuo|pl^eDy$*b8z2>vlyC>k;)y*g3U3Hy!kH?Su4n2u?TnQK`
zDU9j-0P?ZvWZIsJIF@#%jp=Cpej1)h`|0?(d-E{<j}V`6n9ef=&+vdct$X+o7Nr3?
zh{r1#4}k*HePNyfx~!-B<^C+WKO6TX?QrjvB<&EU`>H%wXgv>iwJnqb<1)=arpV9p
z5zb5Vy<YPDLWGBSKoI`9-wNe(8iFvSx%+mp6Hf+ya=(#Otup<arvP8=ita!19E7?1
zk6f?svHeG0fbjVKBR3$d+5RIh0uDy2!TuwxGu%hyMiWjL^OUZ{Y3K8#=FSdJ6QbZb
zJqKE6DC?`i6J?DH`)0HrcbCYX@7LVRIzL;R-=RLYB*Pcgug)@FdMV_l^_kCFpKrpm
zTc2N!chx=Oy$nCr=U4EKD**!~g;6i>fbG;eOxlvB8COsjX$$q6`_}-@IJXcFbT&Xg
z4@Wyen~L_Qu#Ba#wvA~u=Mt`CzZ*7>K2zeo7V+AQc6ny+uvg)oJii)0*G|x%fVz}<
z9mC~1KHO=7zNT~Y`PmYN*_dd>hxSI$TZ0WJQV;?=iK7|<`}0Og-^eUxf1<o0lF6f$
zXEa_2Q~UFJ(4{SSlic4d_qX8A@`%z7Z46;i+9B*M4fIjHxtQw9!@VM2HGIsnTrKWH
z>%=Cf;Yl}XZXY40Zl5T%0S(6VF}83j%;qcDj9<22MPoI9HrMu<-X?i}JMPq-TXENR
zf-(wp7V`fQ`+m3-Z@<{fqv3}P@qi#@q4xJS&}98(*|I)!uPW7hruR<#INo^=?|ekx
zl;NyXx~J1C@t&xs=i6G$zR=Bp$8G9c5$4*|cj$Y}roIc|ahv*Xgf+9N?*)!)Qz@7C
zA<WiS+h2J<-f637Yws}ljB{XnHr*Rrm5?)R&j*AL^7|8%m1|Qz1Xv;t%H~dqqi1g2
zj(6(E2j%`@+*L1_f719jgazdb{n7GGz<{qjsa}3m=za|M1V4^Hk+7d54`DiB%CQCH
zF@%Nr(6Ulp&k5eAke-fj@MO|f`f(U(5Vl_O`{_u25xE{8B<#Xae_S5l2Aj|8CiwB`
zpZ^Hx+V=KdTN2}g|2XKmb%pik-w_t`=ig&<MS7nAJ=cf-NxZv0ex~Q1%k>|4kNfc%
zrhK}7{JRjY^8uf+&k3JC!<+f^S$2@D+1ms>w|o|H>iP3OXJAo(K5hO{UM2H+!1U5S
z)V(gL{{x$U>jAe>GQ?THbUE6QrF+{*#mF^prR>=03y`n1QJFSAv)$3Q<x6;1`#{(i
z@nc)^W#0LSwuIr@Kl>`4UHkksyeHzrMt)u5Ct#qxCfJ+NwxM4EF73=W<o-?EX&acX
z+QM(+Ip7brQ28VM2n?KR+G-2GBXqxudxD>sExZ#t9i{`OTswo;5EkZxyizW%EhOHL
z@Qd3*r5}fp24QLoe~P$aS`GLBD8eIbVHhu*)4W-1;kQ7yku8j=SVN8FeB}2)Pi+jx
zVzgb~M_5B!cp!<OZ%vv%08Q5({t)l3J!G1$J^V4=<MxnY%ByP+e}Ztehd;B=346%!
zX7-Tf=i0-cBThYg_zMGz+C$nG+QVN0rdMNocp!pYg+YvwTaA6WJ!8j6cF)H$K0?J7
z!RRQ%;CUPqF?^l3yc0W=VUl4fzvM3j;cXs|np(h8BF~JUh<iMGlFNCl*Ivvo?VBss
zW}#C`C+jhs`@tn)XL_9cOHV&%VCg*c8Ca5!0dJwkMZLTI{1SFj3wXZJo5v0hv2YaD
zq~W`Q<x}}GwoWtO(HXu0yTnTmpYj&+r6p`u=9m03c2HORX@o;g`6BXZb}*3f<pOBU
zc=M@owj#V<oNc6sOrThnxbKXnvz>8b;oMvEQZK(fCQ1{Buqz3RiZX!hBrINh!aL(G
z5FRf=2fml^WHAQxuTyxP^q)p}wAg~U&m}Bcba$VDarg-shyU8CZ#R0gSWLRxOyHX*
zjP+b!%5~yPQQt}y@7(*1GX0IAvvkcE_QhDicTMUSVEA?3(lzEA5u7kW+}{$ng<)kJ
zj}hW_V~m(Z_*jje1$#yX*I02c(EoDy{6tH{gT#-2xegqaJnAVDfbkDpp5A})_bzY^
zgh?<jH+nkYe!!PdB)N?Pz6Lm;&i3nnz@LnT%(M0xevfdr<J#x=1KzbAW}M&QN1x9B
z@{WtNE`=OOOMTmVe&nB0<F<N#mblvH{}J!(Q~V_j-)ZxeZ}LZ;TC$!O@PshsN#~w;
zMkUX&Oz@8#)msslSHQo}<oUn>P4r!Ke6rEB$r<mj;IWB>J+^_^3<&LN<D#(Z_prY^
zaJ8+|c6klLIGa&jc8l3F?Q1&BszAOli%&nx`|>O1)9td=>lWh!1Lsy{sHzhy%M19#
zgmW;bK@MoULfAAukr|!Ghl_SkT;d!Ae%dg8Sn`*FXWTd@ZVqve#}0>vReTB}d1_e;
z{CqyzW>Tl=8#ov+y|PWExjLQhLA~bsT+f@ghZ(_E@x8_4Sv<8$-c~NNW;FxJmf;~{
zRpy#g#4`KK9g+pl#nM7oFU+%9$_>jp%P;Y<_axZZ-c=8ZN`>^IK1g`K#C}`(&ieB^
z>^`crDTgAhHuRE|{08we9)@teAlC>t)?!40jIDS>x~(wlI@8ByVmba6&NzqEYWg6o
zZ-*m~I>zDiew32hn<MeA^_8$A@Z%V#jdxre<1k$9)zNr%?bR`OPsE44Iu_x)5-`x#
zxe@jE9F?{9=s3CG2Y2OLZO`!t3;2VbQ2t0i0t2U-w%WV<3EdNLPw?Z|JHqJq4%6|X
z;|IKkurMFwm2z>%IK+DZe(^Dm(ociE5VkI)kGSB4SAu5-x-i(#FkWawUo7LA`(|ky
zWX>1If8_DKf$J@HRI2Hi=Ki1+x1A><Y&Bz=rs|J6O<R5v=(*#Wlkx73XPBNlp2^}p
zKAvHi^68FePC>YiXHK=xiSZ1>n~i5!j*x2L-#HC&>WybkH?XK}rVZhE=7E6ewW{$<
zQz6oR>$3WoHB!&LQ{bz!AuVR^S8c$9z_ava%v{l#cvl^D&uu>o;k;-=J^*<!zU~E_
zRj+v7d}fXY4ZFz$&NgI?HwTwF4v`aB6<@XC@X`S8W#;T5b187v#Rq4j{GE&UH2%&*
zIIk<DO=7!oPBy-;xp?ngKFyp{e3$byJljq&|MZ2c{MwO*E58oBr}5W`a9;O(-DIwS
z6_dGczu4E;UT*KpVF{&QY_F7hx+;}ocUM<*-DFd2tW83{x3|Bit6$fhc4uvSQin%W
zH5t`tzbd}|w6CYb?=N&#a$Wr$?d4)msnA~XJ1d1kN3qiBmn%^gn_@>;ggv1?^nypW
zBXxLO#Tu_te|sfY#7fgb5ldq$?YW-LLZQ9T-(BhIFP3}Tqf9o%jxcF?>=!v|pS}n0
zefVv_Pj%xwv=0x#kFDiH5zgzL=c%hbSMKdERC+79-g19mxvvwY(B08p?Ck6AFLcM&
zBsaxQ$<xEKRyVF~&|iu#YT2-1sRX-S&hMD572z$ha31wy7LISL3mvd6T$~<i;N35_
z>9-nz1^;AiA55e!gYu<I9#_#$zrDw=^mq4k6ne`z+^fI6v%jO%(NQQOywKSbE&Zn0
z5lK-$9}YQb|7-xy_fA(k``X+4D>=Wfr`^wWcVUfqU!lFLtJq)c@9U`K3Ndb*VMn;7
zuC^F{)s}4nzxz?Qn2#ahU3K^Zyl=#B7(c`_ZN&(l)AV^W!g(o-G8x2=W8VvT$92zj
zz0lQHDfj0}9pyr)T<+<HXu7&`y?tHXz2#hIp*Jd%rr0r=BzSiEl$6WGSu3Li9^}>}
zZ_VweUo5a-ySgg9$Ve9q5|+pJ_7^MdFrolNv(^+lk~OiP6X0L_;T*3AW#f$3?|Iqu
z6+4S4mI|2f%T+pZ-Iey9Qn9NatxUPt(bFHzKvV2U27ZGxjku<~#k&Z3sB1gW?_j@k
z3^>=;M*>cZHx3-_SBmeT<r0L&$KEXWDTK3b(EhE#ID8uKdg*t7aeMWDVgIx~ZbAB!
z_|4#_y6Cnk+YrvH(VE9tkMeweMw2}gwioW@*|X0&lkaCW97QzhpHB7+UV7=};-xe5
zf@$kZ?zyfNJ6Zj6ezB+6)7_El>gz6}+O&5S+e^7pxe#mfnqtRvjb(mmHnioJ;aP1X
z!|k)RgO9}fo$2k;9_#agi!<I3wWCV3cXsu4_Vjh-`g?MPj!LoA(bIu%i2A$z-tG%F
zY&i2Q6RCT{23<+qUCwoNcXV|0;lmjp-_LZG@Koukw0Gpn<#N$}h#Ra=Z;G9g=PQtx
zz&?2Jk>mYx{OCt`6z{m$ZZMqf#yu~;_FQMFSgw?NVB&IJrH<bI_5!}3s+3Co1;4X9
z)}L*PosyRVcw}B!mPI_X%(VVI0`GbJ%J^w}R>E^yUGfpmOJRXb(4JMY1{BcvmE$uF
z@F2UY;HjVFO1!fZvs3O@;a*Rc9PPtPKASh6uh`|`adj#e3i!;cx4nRVcVAbfv#Yne
zkV6wv?kKnS_7-BA(G)u(O|1(m%USSBSyCQzcn<Q3HbiwK{oA$ty{HeyL9Z2|Y3+$*
z0Bv7_SMaZ8r@p0{l*QG!GtUdSGtY@~clrbeoX=cGx!B#&+voQc{7N6kA^p8Q-M#(g
zUi8>Ib1}7Vik+6v4H%z>W#R??CFW_RZk|FN)jBc{+$H?>;K#TH+|@5e-F4fWeSq<z
zta7+B{cG@x`^=QLIE?fOTMv2jnSE#Kn9fJ^VXX8xgavE*@h!}CcxQUo;+~e@M7epm
zkOnW>F!pz8!weq!LLrUN??zsp1Uxt2jQ14$%oWhf7<$ChH3++alkTfK@RpWq5Eel%
z)?e|K5mv`vci@SL&u%wpx<0$Tcz1nvOw;w*JqGV_pB=-LSJ!9vScI$3?g{oe;j?3S
zGoKxG1=0<Cc27i{dOo`+8(7q5r#7GC8TOIrzk52K^{VH;J8+@i`#zHDG4<|g_^~a1
z2Jg5MunYo4CzG(`H-G!HwjFww+@Fp6&9*N?O3sx&Ca=HdKf2O*b)U*a<23qOhV_#2
zpncXlYM*VN?0UeM|L5Tz$PKv9$2%|mF7c_^P*3&y)aM{f8=B@LaQiJ5?Nj{w)E79k
zIldsD&qWw*1l#(x_y+5Rc-L!n-zYZch#I$Q{v!>D^$Czi^$FaFXUdhbJQjL&Hu8B6
z^XjyLT9^I>xT<rcaRYuF^S^|5T(r6LBPs2d;aTk}>vI}yrN?+T;b*Rxeg|oRa+p@e
zq(%CaJJ&0_`f&khF`W5RobMkM^27FxY2J(<>)We&$3=c#mGwNP`5OG(?;TVQw;<f*
z+t6Tb626%(*OaPUBWXciLzFKr(s*Omre$P_{+0V}72~-+`qu-Om-aDVo3(ZO4RU`I
z?n(X;!QqQ}R=%QXNAXy8#M5sjUWa$`^JclfP42hio=h|R9ztdI4&c@6|2F?_x2Mq6
zTj?snF_gnr486U%LNELerS@`f4kJUq81*|e#YUY#uesFMS18gqo>mTDJjOE@VQ&ZT
zfv!L%x8a=^%lX||9e3C@pzp#v<@6rh)dsx+&)Qb14SFlWv<^4**Mi4--^jn$p-mg4
zcIOU+>$N(&)0_*}?li@Y*&WJ}atZ1(bX~tCsG}FYIhfqf<7gr5g<<D(62qc)PDB*?
z3SEV=U#N7#i`L%ncfp^EJv-nqh$=?88FoZ5j6MI?Y*=5ou0P}-nUQ)`hyPW~RrC}v
zchb?*UFk0N6#DvmdV2lda&J#(F4vBkmfo2Ew<&gn{oj~x<!Faa1FJCSCO=moKl`D>
z)ZIJf`2(Ka%i*PXPkvit`vuXKo2|X|!@Ux5RJW;rJVX7R2y?%;d7r+=zPI@R!b69?
zUBB}ogf;u#=EJ~2Z!q|VQO7g4Bm9H-{TqJnxZ)#tXP<}bYd(r+y|fRQ^y{r&3byx`
zz;`}%j7qLipNDm18O&XNlIJ}FKU$KHWqFT|i$0#UZEX>EZEHV;XYF@jl^&~_bFF4?
zguYy^hd$jxsk6U7*WKPz?CtI>bo5p_Fh|iD-(03Cc1#zw{*&kbz|UMxyL1=AR4<9c
zywsTsTJ(3|Fa&>54MPPxopV3ExNYdj^<j1r`6-usJ94=~p}W7Q0yk7o1sl<{#~n~j
zu_GDc+=`hap?}HE+h_64{>0~b$HjW~xol`dSTM|=!E^cy2^vm6;hx(UOr*3I`}<3|
zp1xkcufG$XL^PRY%pn%xp@{qIn_@>qz;@HNdH;$0FkfGk`<HNMzQ2sSTc+$!XkGmb
zU|+!RtAb1YC7gZ851kl}+vD}&>%ikh`rpiI-_DlBH}Fn5ehv3P#-RBfyz|ob_|w_Y
zW@&r;6@+Pf+|(D@pgsPsL)(rCEN|aNIDH%JW3x~BeY`UdN8^1xc+__LdkEKSb?tU@
zZrygfDK^SDzHWf}tK~S2ei8X~?dy*LXSrR5JMB>i+7qth`yt+8ryUb-*KGd;;jq2#
zY_5?F%bI(j{1k9kRwo>7W%V<J(=KepdO%d2%+K+z7uH|e_BKq-tV_iFgy~*7!2{fj
zLF*fN{uO@aV%gwgxiH+08(P|Eo2;F+W%&rahkhzVKs=Y;Zvdwa_%GgZC16gyXIj6_
z+O(2*?pVRrwf_Mw>)P++{s-KZU)CR`L7sn)pShfTQHI209O6hGjV=2#-qo(Lev;N7
zai=Uyo)GV^c;@A%^Or0FkYDc<Lc)4>cQ#qi{ug0d&zjEJG^l4SNXzYaB=~V;taYnZ
z_#=<2t6R-Ebn8}A>{#70Ji{;9Xk5%PGV*oW1GT#u<cGSjM(zjWZuAl~X=83Z%IZch
zXlVT<J(j;)e-A}G)k6yl_di<?n9MOUDd%#lFIHA_of_6S=jY7fcJa2jfQGl?_u%so
zEOF>87BQEFsW7y~rS|?VzdyEfT~llbva8&IS+P#v^lNRsJY4c|B<?o9HvA~OQ`U#!
z9>^0iXu~@%+OF<w*yb>!VLu;jmf&go@h9M_?rHn64mhgUP5VX-^!gakQQGQLIu>E9
zr>f)R^}fQBI|iY@={_2cJgiQ~n{(^xcvI|HAAx#BeqB4$gLgMCCy-~@kNXSn37Aut
zldz<XJP~wQh9}AWWZabx>NlS$Q~PXn<P^M<b{2Q?Yj^_gsd(q5Wq&;0wS2VfAAm3|
z`=;yi8kGHM4sCZVf4cBMK2}$z&AD*Pv?+GXZn3_wj_KIr3_QE#OTUtq6Y(Bo_;2yf
zG<RFy`hg>Ds_7>xt+R!e#wXr65>IuV<@aF0<1=yG`oVtZd5Ji-oHqc*IK*+|kj6t8
z2YT2paa|q^%+W(_C)s~Z;w5#m6EvxlU2^ZiUE`6L4yK8;yLsoM<V*FHa^Z6#P6|&O
zgmypfLB0_8e4(AB5%Q~gelBq1dftmL)$^w7CL8Ga!yMYwb8XN15Kb9ARPGnxu5I_j
z@vPVC>OgZ2-8#?|J5dL$4r%#NA6<L03GbBiM%;t)MHvi9K3KjJS=&yj%yWRnWj=r~
zm3h<gSp%65JG3ctxBVXhOy#^8&w8y+&ds@U<=hlI)_#Qj?2LCIc++}!Gx|1!<qWee
z-o+MX*6*n;*@7@@mojbi<L!t1-F!~~u65yJz{l}!E~mfDaMEB}%LHP4GHKH?edaBI
zyELXq1NC@DXeD4yeNDo`dZ=|`E9kIJY?J$T+-ZO5ch-DfhA_=1`E~6C?XSH;`>W}a
z#^nlk@=Upr2J?K4iEQIiXBo$)W$oz|z-4$I_w|TF+K<39`7p9TSOM?6wCrxrhVAJk
zfW>wGQiQ3_H(lS^K<7&iZEI(&51M(nl02cD%Dm$W^bGv6oznW?3!FHss}IdNcI!h^
z?3mqg%g*G%(I=L}4)CkxK)ng_>Wm+#KU3MTzk3zpP)|%d?aceB4psmot*YF2;m)*X
zai=aQPpWIjiwqGZfHA!q@Xh7u8u@c|P2-Y2^_nm~Grp^L%fiDFc`!IuA7_9^eijiP
z<Q?$cc;}_%tm!E4q`yKO=)_*ZRlEEsyvKEP9$~7ZP3M~$=;%I&wyUE7Ke6(?2Kdac
z>gQwduGi}HvpKh}em2F9*=x%4TJV&vPqzMrc?<0wb@I+^Xww+q>X!9;JR0xR!N<z|
z@wlsAsE#~A;;3#iT+5gAo`@gI_h{a6DU9hpMZ&^9rq!pXB3$tT8nH5Ae60sh27Zt~
zr2h<|t837nhIi)UnYgPx<a~wd+SLe;>)MkLrn=U2O?3lZdzM3+x<)xMPn47D({u5z
z*Xs1CIY+KOHN~!D?<nK_<PGKb9O04tbL^qzzd#(P%!4?Q^0MXn0>oqd6(`Q~5Ehg%
z=)6eM(ee-Jg?g*~i5CL*M*P%fJ|E94=NshyV%!(;jVITxpM__)jE_3*5bu!)(=x`{
zG__rr-!SX6FYxZ>c^yRu&V3WhekFjD=A1(_8(GAZ#Y%5{;Js2>&ZbZ0opBa)fjlfY
zX($g^RfQA6xjOX%k9_QLaFh=hhrC>u#!HB_8ivgNWY2ceYU&a)d1&?i#Yx-tbH$g1
zeGOg$7|WdHs5(QNVV|vDyaMkm@0a5qls9zYm3ZexU)Z7E?$(#dJHxPJwEJPwKiU`8
zHk%FY=&QjeZIjxUr{mq#J?<;_QiQ4QHJxK_U|()_XuEA0`FRas=90Ew?aeJ34&dtS
zO>+)id(#v<rTt>PCC|YnJcs>ZKoCY<dIR`h4-HUT{(Tvj=seGx0H;3jJ&;4Bk7e6L
zP49Rn8cR>Zn7&yT3EyrtYtw(5q#yQcLf+mXFwU2FDQ9!VCr0cZ3hDDDn!n>Q7sLF#
z6SULv!*={#fa%zTIMhGxJ@X!fp9b~-#Q1YvTO0F<yxfLxr9TgRwYQA>UchMc@8BI*
z0_NCuZDZdLT$bSn3|;h7vs%Y9ZLAMk_dkbl@}_Bj2r$zBAnrlhVD`g!=f!;}Qsn5a
zPthZDqG1CA-UVX&Ukh4p{iEG|J;Jp9soiyL{~H~++FXUx-oC}5nY8_E49>#7D~EV*
zb?9h1p;@-}{Z<D@({gc`-n-M%3z2BwZK7Cj%yrHG>d<WZWrEo8k2q;)U*+Er#`2==
zpbh>g-u2RNwEofGQG5(MseZAp@LBr^{|?wE@KYV8{@uwuWHR0-dB^oR<PADT^>wbl
z;rFk>XGb03XGb`m$M*~Uxz7G_q22Fm@9FnD%2*9j!kkTasTiA`X^I``!pV1u|AGAN
zhb*+N-Q~#Px(CSq_OJz?7CC6&%+^oqztQIpV|{>?v2C*{SCuLKJf9;CjCcPtpk?ts
z@8GfD_gTUFVu)wfYN+jEe^S%@GH~>HKkOFMXPWd0u^hiDG}LyVfb}5<0rpJfjp@GZ
zWUP0<?`wEgUP=EejF&mc`-a4){bU}Lhi@UA>1tYpeOqufEz0T&gexAEhwtA_(6-;#
z+k9A=aL-BQrx$U)Z{oCgKaey?+tfR!?0y6o?YHrVA^gX9Cm#KoE)RVFX@Z_jcLL#>
zF7sr{40itK#K)C@Id)$A*uMZS^ZHA<e*t&$L7BPw@oT)3-UqXu7o-Kg??yPUdC&IC
zzk_$zHnVT^D}<?SZn}I>`bN}8oVZsgVoP<}%ilP3Y0I?l^IL;QTr`8+>j_63V;gX{
z?TF8#HfO=@{4~XmbbbP#Fw2*1b6Cb1@4peIb(iZsw0r^^hO+ye<R<}3DZAeTmu2?{
zxqr&iH{&tYebzZ!j+wSU;@Q<L*55xP%v{o6QvUvgaPsg4-~{}ky#FfrtYfTunoi59
zmi7}w555k(xE}m3!c-5ME)`4B1Fqkt?O*5Vay7f&5euw?wA?;3`O5%iF3BI)!ySw{
z-c}6<5bIw4e_0P_Y>>)yt;ke$f%fQN<vUhh9|6q8Gj<F5bco<5U>TEf{9`=pA37Ac
z)ThJb{yoT=wt#%Nw%~BQlU_dS*hpx?5eVm{Yhl;nJ+1@m5vDrO^xIp}0os4;7|D&{
zs=D7C+k<ro<2h&43$_hy_#$c<D_RwYZ3Xv^lamw7esXL(vR;0V-4e*^&yfzF)E|DQ
zd?<9JP4dIk&qSPmuJ4pv+Sp%ET{;?haoa4)RCR)Q$C$igFEPn8>-Ru5jDH`AuW<;w
zui$DMsxZ>CS4fX`Q0GCI2KDL$(xl!1M!jQd3Oi9?q<Ipa10GYxeVQKq(aOK3r(sMl
z8%xiHo$91_TAlPrgK1HYx(4%Q$Jjj}c?OxA{|ABw$6VSM3)+Eot=<`cC2%vqmpZLu
zum=H;aybikO<Qd_%ahN_2lvZ84Y>QkhuZLSfD@z(O6TI8={^{D=ELv^8t37i*HtpU
zIu7q{z2&&)ehAZgtK%LWKhdXke+RB(9)+|0KG~s}9A8CzYtC+6*|XtTGk&!PIP^9B
zaJXd0U8guW%7cqTK2A^LBScF0)#A)>EOxe&PScJ&><QD&IqA~IaE!w7S3AP>;`qz>
z6C$oK%R#&o({$IJf5;f6#q2$$Hm4JLbNd_Y8+U1b!}iPcc{NT?EDrm>y|FmdY3?CR
zd-2nwY~7$ea_!sW@UC@?unnYv`uI?xm4IackJZ2Pfy?^$Fx*-HXan7L@ZoqTosFO$
zqye4=5YCHxzp?C($Gcmfs6!VZOzTtAvJ@Q}bm&lr*q6aRE3F$PJ*N3L)uG6C0!_J$
z3|T|F)8cKycNpBaIK}T{c4?G4CfgH>2aOv#L;(X_bIf*W82MFw8NoB#5VeEU3);cW
z2qzCLKbGQ!cxM?hF7ef$a1q`)77h8$co&<vEk|b%llva>7t+djTO2sYZ?w6D+dbbi
z-UQ%GYXvas%gGqWQeByj@~8Jp3@z2?wceBy*VSjz4tZ$twn{vkCWr&Bc7Fu6UG+N{
zKSK8}MI2rUSO$TJ&rAD)mjRcuyIk%+15M_M_0z2bkHkCaO=dkWNDFy>6vBDg{fJt<
zKD<ZkK&$r%glQdUx=|C#p8Y(Iwc%N;aYt-yqPVb6>c$lgebx;fALfM*#=`jU|AYOd
z?AZNKr;Gxh0m`T#{Aw8munaN~E2AQCSw<zf|4_<^cGoQ<AMd2smxV3G&-f=$Miqqf
z(lYACd%TRw2-7lZx*1`UGTPzLXBlZ7WIf?e%WS9cMc!6bX3ZIMNAyjxBZdsVH`Y7y
zhtZ^01#il?sryndweHUXejn8LHNe(7PCQ;={axeD8#-F=Galn<{pCEUmOsa^#=iyK
zxEeUT60i&cW4f^jT<XS>+`lQh(SmnZH&*aYdP`Z1u<$c!K{s|IoR^N}*5Ey^8_Nh&
z-DtYmjOfPy^;m9?!zXo&d(Utzw^#DRJl(soT%=KKn(eqQX&K+>l<`Vd{HQ47YlKfN
z;{cWc<FPV+G;mqQkCFSAq>Sn3am)Bxz)5cp(h2CHj30+^Uh2F13*yDg__4szGH$xj
zj+8OS<{Yo<8RXZ2hSJqC;X3=rOZvn{J+D8$Zl17Pznfym%Y^lkb(Osep8KeM3AX#J
zyV^gnIIZ53z&GdOn9bAh`-^-R+yS5ZdeC4yY0izrI8n>{>0&1i%_0JDo^EJ_{@?f9
z-?p!&e}Z^wWA+1&=M0d?9HYVpJquxV=FuXXx7(gnBxrzrDDwUs&>-(u+HXJF_^y4b
z=i!<9<MMDl!dxDnAA4`jTA8dtUx;)c2f94lGTG;AbabWRxDmpD_5ojn^vN&tawDFZ
z=5vwesj$5V<C*2gy&D<MXRzhH4&}pV=7V>5)4UfWF3amBxU=l)%=2zqT;Af(ZA8Cg
z*M&I#!0y+-HJ=C`u>57(UMBR&Ulu8m53~t)--R&&zw5gRaD3NSBt`B|4w5*MWbd-|
zU0FElL<Ek*VRkE=eNOl-D^+xZ%u%Fhr%0Fig3oKVI*;&`xgt0X!cSCsD@(z7B;*VJ
zFz&LA^IxtB!YMD<NuH7IFD)x6o5st*`#I=K6&Ad^DKEHWGOsZCK_px`FDV$Si|O*}
zN!645^kvgC!&~yB<0BI`wi7U*a=sbqvfNG;xw6b5S4z~Jt#Uo;9pq?uy#VQC!0W3W
zULnK5S)6+llx|r*d5ni5MXo)fjBWJto(X?$)cPM=J!A5`J(G*IlE1W6TO3?0?Zmkb
zC7eed$dou4Z_gAq_g&nLqb!ux8n3*E=f3b*3@u;g182%EY{5sD*cp6qVPUokM<zbe
z9xRu!J@AsTwXH_S+lXg(2(OFBay}mE4B|8I-G0F4mcr7mfR8NT<3?vDDgnll)gR{h
zbn>YgoWTMr;eoI-N!xzF1|Byr7UoxG3yald_RpD5=KUN;K4boFU(a(Q>^uiH<?pU8
zfeK|o-B=H?-C~6fOru|pDx~WM>mBpV-<ha)?BkLTTkjU!nr!%c9q2>e=2#w;EyHr&
zEQ@7H%Z2nV^=2=u?%25<e&t0ILGno0mEP=3ZMk3xA)NeU4m0z5hyR^gKc;!0x?3|$
zzyNi-2mO|$?aYtWIPlqO&R$`}ZIKYfq%C_R(sKPSe18*u^nZls?b$Um0W9WMWq-CF
zjJg@Z!hPUwf{f|!cr((9@P+&^{4EH-HVQD|Z$<cKf7#}3hWggx9cK1!z!AS?`_BFJ
zQIBCRIq=g%6fG==tik5#i8Q3y@;34iJ0FHJJs1lG-VT^vuzgKss_me*Cu~1j4S|gJ
z4$z{^--$cz5TA|hciR5j0ArjiZ4>6_-!1RtTi><M@fY~Bs`&9-p`g8m&-ix4sbeRt
zQEi}0=!3M~f%w|KzaP)8Z{Y*NkI57G`&aXB{U2`y9}gE^EIi|VNbpTv0{)4|hGQP`
zO?>*pgLo$2YrKyjp5~LX#H*>FMxMk$Z}y{3+J6F_s2noh#{t(q)vFAymIdYp@&4WP
zdSm=dtJ$L@vg{L!aQ2jNN>P3}i-W+Hma}J{)9ig^o~Nk!<t%pdJtug{^C+~QuCwe`
zIuAcRWv>(L1UxysF~2>R8_i!laQQ&`R&oQh4WV9G*;D5}g}k#&T^RjtEPKMV>_3C&
zbBvx^Kg4J8uKN9Z^fOggwX8o6xQ<0g=PvxXF648(<4V9lTVb@p3&1%IKNO|utLb|?
z-pMy%Ru{4Ug8gUYLH%Xay{{l0SD*OJ661Xp;mk*%JL}eZUqcvS%p>WLx3A-we18)^
z)-~N5jCciE0~6QDKegF>eOuz1JUeljCi$kmeg`<obN~VkUW7&IAW&eWWBZ|&j+VoV
z0B8L$c{5Zp-j9%u?j!asJhObhEBEiq{Rg-wc?tIsOY#!JnAS@X-&{yv=b(Nnw10*>
zao*+NXgy?E=vp1hj=mB)JnzKZ*fQ=+m;46$16lq`=!7yj$on<IST5{)s!p(sXje(&
zzW@(u04X8I7Vo#v59%G`v5e5H-L2)Tyiw+BWv=TBpqZ$RiCw;%)%rL*sQ7iPfNc-I
zh_u~tG53A?3BufcpMIh5v3;K~&`Iq3^xp_;w(ryLfP<DX*!L-vf2;R<z$kyV6_hz`
zDffH&gNeg<lxMnOO55Y|pTU-@4*wB(q%5eXw3dH%WntR#Oq*#p0aJZq9HV4VG*^x-
zcvrfFyL4L}80#Bhw%*|kJOh)lsMvDW1@dz^dV?Vy+XibItdoS<x`{rB&@p`y;r*3T
zj}XV?5i6>U{XGJ>wyxRs;7Gia*5SA_T^c&Rn+XgCq0Vs}mC`qjkC<%7HXb@KV07#l
zNmqTPOpZT}Ygs={UQM51jmM5W-wCJX`=qo1h6Z?4+oLqn=^W(UPw3D#uq~hs(zZtX
zc1k13$6D`16TkI1+B@RWwy3`$9-nZf!8&y^0^D{tYiL2=Odb#R9)R~WJ9!ET;nF<1
z=_vhBRtI^f8#;E~B%|_2d8Xl>0U&uBLYcZca3;c4$JzGs$G(9{2ec@=vw*{QZNJXO
zdz{C5>7EPRGvKG;kb^k-qn}NGY(s$Nq_NI>2m)MvNvFTYYX@GaFB$JJv_qO7#zFC!
zUyvW@R2Sl;=|XxMYrP(mM(c6x=i<?fF-gzp7T#G;l%D2^cg@!<bTCYRt+xS0v_6wY
zNDF%o05*=Xl|65AWGp{Dx_NwfNY0wX`}pwY!I{x*!>H5tJTZh#Y#W{$8JpNHVe34E
zO$`qY<%dQ$kIr~SoB;-ZREGRq0Qzdx7nf^$v8Z`vo=&CmxjuYI=LRX7?rZ!Uun-#b
zSxE%-TzU4q>9L{w#Kjy#+dS}ne8O-t?U}HQ!Pz=KBwQ1()yC6|+<l(#%rY4O&!jRv
zGdQz#nx<xZSNM*^k=FHbnTaeilm%rtJ!xdPhVNs;BQvh7#vrT9ho>eatWD#H+_QWi
z9Ge-Q8Xue)ws{y}Sgb6rW7x>V)TZHyO*4aIm<K=D_{%8wjgH*Q)mpx0j!fOKVPtG@
zv&|8o0;z^5$R7GQ#-A|=I-a-J>wryeftnA2re0{PH%-mthbFde92>UQID7|<#$%;0
zxeXgEXV`?iu)s|Nc^YeN{(R~6$mu6b%We!z=KF;?$&yCY7#C!9Ae2gYAio_a`lV6;
zC{-S*fz*L(8;%E8&oRY!piD7++Skn}6CIDVqHy?rA<GH=n0K=+;v?E+hU+-(B0OuH
z9N>gq%s7#8h#jMIZh`iM?MD<BYZVv=m)cFvCD5M#0c#^QPAlLc{Wac%#JL?h<{jJW
zjhOe}m~SZWLOOOxyjbAL=Je}~0-jo0L3!JCmSey}$FmA&v+;8>?l{8sz)y(Dd<?V;
zC92n+Di8I>c^*6?QQSI|CGjT%e7jtP;q(`M-pG-s@IviSXIbtCdq-z30lr>g-}V2#
z+~?E#NaBZxrVnxCm*Fwx8S^-}exXpcK4|N&h(Xdd-K>k5MqX8aX7J4Z#_H?%(gM8I
zi+&!*5m#}lJ+>j6t<`p|EZ9wh&({W`DeLF7cl2rXZcKAv>*{lOdTw-Zph4cZIeFiX
zXRSM1@l4pI_)$8#CpE{2l$QjXvz3p4e$n4FN2j>x+hst|G1?;@Wqsk7n@Dr{!s23q
z{%y(_r+8)_VZue*<V^OMRs5%w@yXJbdTX#b9cGpC#g$40H=Q%O1?^f3Hg;j#{3ysF
zO<gKHIeU2-hto^!ct;~iI<?1<f;Nz#T}M|ct8Nbx6ipM52(6P2?S39|u>ETLydU}(
z^zi`G{yy=p#E<Pkk#}547y@DEc^Tgf8v7D(Tk&4To%+0hXA^ym7wpX$(02U$${Xzi
z)7gngAzq9Jj89yco>%`<=mXdNUV*sL-eOAWppJ0OqYvDK`~ai<t{BF-^I@o5YTFHH
zO}@MjebQ<vqIo9nv(dj_7l(r`=K*#g^0moC4Xg^7)@`m!ApTVdi_aTSXAbdtGP?{T
zECCe7npJ7|0qM+F4^TJh#bIO0Mx$6*^3P`zdH}sKqK92EE2KEhfuXv+o}pCLPYv|$
zzP2TGJ}ad?lrG_dPBh-5T%}4OJ%{&*em0a_oZkbM7zCWo*#T1;=%~{~+J5Lf^jGZ>
zpIv*jfOoYygw^n)J-V8AT-U5xH`9B9M%Nm4qSMuhHh_KOCGeqrn`Jy(+hzS6D|lzS
z&9ON9wEQL`nU{mS-I5ozpNn{JMc(${PJFgqLEasENf`UptAk+;3HsK&lJT(S3O17$
zd4LJ`9*wkle+=&0Hn4A=7WZ1<@X~n#_T#U{dy;pY`;~&r_8|@T34*IUJs$7m>4~^g
z_RP1+{>gaOzLm=4DG1}ZWS?1^Ytv{&P$;hucCGd!ym|Hp%(q(BC$Qizmcld7GhSu3
zu)~h4TfIHi^72j@tCwrbu+@xnkcSm9CA(CB?`u8N8!@nhJ$?aV<FA9K+?Yzly9oW1
zL*Vzwg1@JO?=&lJdZpCW?Oo<E-K1H)d<JMxHd-cJ|MX0RQO<->239^9Z$F-SDK5*8
z^I61Y*$~%U>oVT6<=Mc{28S?Uv{^L5xF)S0tQBa4nYtX)XZjICSU89O!!;c9wRm$T
zeLLoRM{LZ;wtO$?8h=IppTJVvvEx4QEX-ouinW$_w<C}eTF<;FBysD&#PLC!L>W9b
zEq;EPrY?=XDtH=wqwGxgapbYE2zD@al&>t-=JL`wgyY>5{%i#?W0nN(tT1V5hLtBh
zo~cYJX_<<p;e5dtmf*MKsZ5+Okwz%f5O#SWqcCjA(0CGL;Dk}?3;d{i9s{o09**%j
zgqZc`cfcq(yoYfLDYVNeVJj(NwUn?+Q^NM9ge|0m%?EO^evT#V1%<)2<icu;mCsX=
z@12FEyio?p*VCwDJ~V;W&<Vo~qlTKYeHQR4)%mhnL}*Wu2QP<s&p~*heANop@a^Og
zK$gZK-g6Ny^2AClo;y#W+HdWi2N)EJ3kXAqNxQY>dcdyz=c)LRO>4{Z!E?M%&;ICx
z;U9VdV0ta2_UZq5GHYFwaefcD7x{PTkFMS?mEJd2*J5f%AIiKM=W{ycznS;>?w_u@
z&%98xzQ4jOynl<Bd7&HB4C(#`KK8oA|7JObZJ<x#MW{<UzTmSvzW5isv%k`c%0}3Y
z_;GykV%~8P#{OggbNVangECzEpfAI-+Xp4=Cem@@T;%jKmuU|d;n9?SV~eLE$uE@(
z^D>WS>kaLroqK{ctuF0Eq`QA<=AG7=xw2OvowPoqQvBPN;D!wg1uXS7T~R&_JpA;!
z3H{AV)A&Lu1I$*=@0zdenGfVPUz-op7r8kBkR4^!3O^v{w{HGB%WAGxHmhm3ck$`(
zBdbu)R_3v+zO4F#-R0(&J3B;1X7!(WZiVjQ4a@R%t`??hwx`R)YdIKeg{|yf{dbmK
zXm;3(QjJqn#IV1QJlD2xZOPLzP#@>|`_?$kH9v}=B({daVbI@25S-6VSz{B<-x|i8
z`CZKCs{i1%&>h;-*WgauXfBM;UnkFLuoq(-$}0`_De+mP!PFm|276rtn(8A_o=>Th
z_FIK##UshIwB9aw8{t>M_}+Ux-g$q6+}|koH_83Ya(|25-zN84ac6sT3+~$9yc5s#
zH!++tWjNQmTN??RD1L?(Z>JfLFg)W~e?_Y|YwG<PZ#M9C9OPYP!q&p8MqKzR%zd3V
zX6}c0qvn37Hwp`4?Zjc;D2#-CUhnNO@WZ_sb3el4G7W#RfRTlrH1+Pj0(SUF_&Mm)
zdN+7Zt3h@Im4~scR;u=srtMv^z(&50_lPWXZuwn!zYRamN52<$mQ%D%U*p}5a9->$
zP{x$2#=isa&Emgb;&Z-(@%eh?A>n)n_1*L>oW210puZ!8h5n9Tw$k5`@oq45t-phK
zOa5#nZ%m;LBb*&FH|&!!zX-<~F9BZIBK}Q#a~R8HyqAK0p}e~=Uji#NJK8gS1T#Lf
zaGhh%7cd^QUq#pvVZN}O_YqdB#GDEof7-Z9n0cQq3mE#Q;X(#_0;u&i#9{xBz3+gN
zq^SPyoxMAbydWr|!U>3gs56`QL|F7dRDuG6VpwJ;a4UPe%LW8g#GDXw&X}{9bB?H(
zvtmvd4-+Q*f4^1rx?fdSPtWe{BK$wU{(NS-t6tTsS5>cGy?T`bdqO~qHMBtGHYI3H
z26c`%y>u7Ootkro7)P=**l=(vVLRq;5;t4U;3(m9R4!?eF-r?<dM{`F+I*VyjNQP}
z=afKO=dWa4QvX8Pa<1!Da2p-NxhV^>uE8*i2}i!n{7o+cd(p<^o$%)Y1R2c6p)KWu
zfK4r6V@qTp01aVou7xbH(zy|VS9i`V8e79h5YH<QV_r~6nB?soo5|0*iN@0WJfb5E
zvc|bL=4)}Cu!PB>nOEa_wF|@_yuh#@Mc7N$W%%u0sUEY2@5j4OY_r?YV7zL!E?~Ja
z4rS2KcenL!0pzRRo{s_7#nBw^_|S*=KMwrixSwOPLon|D1Yq*~diR)gTqDBlAiWUz
zs%h~k`-h;9;+{A1DM|t@U<tz$%X9QU5571r+6{v<f1V|UwK8NYn2oH>h~X*kv0u^|
z-mcwFU2Pro)laFi#6GOZoL*secW4;T(b0`TSNm4i<9uhEk#%%zn;oYgjTp05b{EG4
z&rLpRgktZ>#~qJPvBkT1@XwW9=L^DfrdgkFmQO?HsS0xBp<2DXP~Z40_*Co@{MPn~
z&%<r>1hfglK8GLe6Ib$$M|7DKrt}Nyh4dGF@k{vD_6fqSA|4fo_?F;Bn0XY8w4Mon
z>P8IrReZ<74J#cqZ{zUo8JJH??HO08G5XhmJJw>oYFHtUMywYe+EuFEbgc`^$kdxE
zOH-$iXBjNh{VuCm-S0Dqml$2Ax91D^_J~|z-r4t2U-=^Nb<)?q47k^SFGF7=?wGzt
z{~~=&!E*YVM+*u8Q!Y_`O{H6^uQ6=L{B@zPk*+d*Z7-bi@)d?NWSf<v(2sUWzLxr_
zb(Hp4VWX>k18~vtsH@PuHPDf$OMDal7q1FqSl#Daz!&N!l(&09H~BVT^2FyPR)r9&
ziFl}1sYQbK-5Km%*l|1p%JhLq_u(w$S)b@3O!cXJOn{<YU(}QB`J$DtVJb1>=ZTYo
zIJ#hhL-)5UN8V`}lPto|(^gb)W~G=SY$au1w1SC!;`h)lr2po(?!SKkw~_T|ID~y4
zKla~0<Qvbj_5tLxoK^?TZgxdnK2TA)kawsf{0Ov&j__lA+y33IVfqQ&T*Jim`QaL-
zEI;d$pSt|W8m6n^?nVB7hBx!iu~r&B=m%+w=?<1(!<5C#uVMNX(&l=hUppH7bb1n5
zx0I(ZTc;F*h3k@j>(coh-YiejB<1-Bd~2PHus`A#TbHEsB5RgpO%82Wdi_p@r;=Pt
ze0WIf9NvVPC$e5AgCPWP@?ku#*C~SaA`D@McZ0g4{VIcHI?Ny3dY$hYTCANS+@ryD
z89xWyjXtvVIx80(YcG|I{?wcN0(9#&JHLb*0-pOta%*;?uwc#3Z({M)nw<cLw`M1R
zrE7MsA&p(E*$Lu%Yjy%yx@ITv4|KMkB!H)Db^?DhxTl?o{&eUyJ1i6B=dIcC!`n4G
zzMoyQ^Lr1+LRV{cd^~o|j_+sJ?D&3m&5rM9*X;OycFm6OXV>ibes;}{?`PNSuw2U4
z?EDE~!ZkbF;g_z?F?@`BGT;}k+4(d4VrzE(0{_^Woxj4rXwA;w04rLv^LN1VYj$qT
zjo<3X*MaU(N2U(Obvyq6OrE%oe3O!PR;vg}UV#F&mO9uP>Ga(!)rsr$`Itp2*#AJM
z&l8s_kvradc0k^ZPM?onRB(m-)IEyAT?y3b|BZGmIz7L&PJcbz)R}tG&<Xnwe$?sz
z%Qrs}|6cgkdUVer#d>sxV|`LVI6k6B<8V8pNB80_x@a0c(8Z|Vb_dJr(OJB_9=#LN
zrXIb~(cq_(*P}CBc|BUgLOps{m(Ff@Q;%j?(WCc(pVp%Z+Y^2<JvvJxTi?&JdkW%Y
z@$z~zVdjbG%^3_K0=>Bi){CHo8U6_Bih6Sf%j?bmGPD%y&Fhf&P%KM3E@;M`)*co_
zQG@0kKyF&T)0@|WZml<OfV)U<j=}=HdFNPsr8fsSJiR%9rF!!&q_GRVIf(D+%>gXc
zn*;xx-W<SFy*cnt^=A4j9oekuW|=5IPjB|aTfN!$vwHLH9**wxW*?8$n|(j4H~W58
zZ}$DH-t7BXz1jD(db96m^=9AC>dh>dGQGJEVM4umFZhLeGyOund2jf|^yZtvKc+YD
z1OFnu8I!?<dh^WzTejYu?-!*-uYxJB19H>&t=@bK&|RcA?+2JXtD`q}plR);U5VbD
zr|o~C=Um<OJgVzy^mMLpPeECB>THTmSuu+k#k|{n5f$pt)Wg`1iXO*rt;gLOJSTb_
zVYea=LXW$R<3+-#>!dK%hf_bHzvw5M5J&4Lgx!{SR2<^t+$v$_31FO0jlsUP?0M0W
zF?7Ccr8Y5JQ93)iS~Zl;k224u?1S>4j+DVN9qD;)esq6RPgb@ZfNyUwCOKLef0{Yc
z1A(*C9O*%Tcbr4)u%?Z;V{@eRFPbA&ut0C9BpxkRp^DCts&q@|NEx<c{<@eWC0*Uj
zksi!&!5rx!sb74K^mc&jIa0b~bEJpDKbRxkkp_bK+uokr183Nm(GJ0R(!&6gC*GH>
zBB#o{k5biB^Gv>-7j-j*GW4Nc_YwB+EpuYOv^_a)M}dk6uyawkdl6+P@|xdTULOg!
z$ZNvxfFI@c9r?zShvmo9cS2ZB{@xkyT=<CmNz=hPby-vXPpog@+T0^dx^~ZP72m7g
zOJdBlJLX940r`0Ly5P(*w=SfHbVV0jz3$n{)PCR&d7L`K2AowsVDfH?ooz0%wr<r+
z!_%pBURRUfyWjs;ympYwdW*W9{OoM7&a4pa>aBrz%*xjbtR!pEqA1Mf3fDD-I%PVU
zxa?wsWwDUBWh3ioV;n{s5?RM@E$c?%7WqWj2!51xV|?RT*10D|OxJPIKzvcAtQoiq
z=n&oaD12*M=Uw40I`<^Y%lhPKmlv^hZic%Tc{>Jg=ACN>((r+7re5A1EN|<~;^l3f
zcSqW^b#8Gq`03<rof)pYty9B7TjxDoIw#=Gu>`|PdEN`(dMrWMz443LI<qwLw$3bG
zcE$(Gb<UL?Uci|@(}VHM6O=jE2o%9sZy7Cc^jQ>!hh03w!>S*ZH3CB>J!|WXo#`<S
zc+S>&W0pkD)_E-G*0#>O!R>V1+!}!>EU<MR7mKfKodFKd))~N3Tj%klu?t&g5Z|+P
z2C&rD8Tbcd7PL!0KdG%V@K0@>^jCIGW9wv@C_m5E>4&$rPT$YkI`8S>=+4&Z<FU3*
z-_P1QeLrjK^!==@)AzHsPT$YkI(<KD>-7Dst&`<aX6rl=VM1HyN$?A8o%9QBohQRD
zX6rl!{xMtUec)eY>%1>uMQa331x)nYv`=4=j&MV%Ay#)j4RnXPGxaX65jY(%dE$F~
zZc@_D)63I3TDGcm!{}XWdX{04o|P)6ZcCFhs>u0>%Py+;Xx*H3aRzuxbV`0}o$~&0
zi%v<{nfOtsd;s5g2&2A}!h-&vwoAgy6ToP@EP_!tD8fk_Uk1y@*vI1@6ppdEKSK6E
zoQ1UGCAcDifLdW&tt1Zw-i~&zLOb3r$%7C#v|Bwm^~>9>Xghic;O^|t@L0>0X2k4U
zoB-ZX=8)fcx7gW$$rHCpt!~L$p%BNpTKvAI^B0k}?2LxlivEa+Beg~3;}@B};;k7v
zB<C-<epcEuzjb?VqE4kf6V_lIqdm7=T}yjTVXDn?%t3z{b8JN%J?0>6ig;8U;-d^8
z%sc^%G9U(9_4$i@*`^l9Wz1jXu`I8K()kPK*_3@y9+YhvER$_Ae=%w5$?6Mjd@su?
zoTpxuf!$Aj4sdpwzj!F%E0cSbgt%k#7xXWhzfiDXEKo^2TC6~Y@W}7USLv3{UodRP
z{B<#ZLAtt`zc`oSg87T-)Gyx;aNqtm!1eqE-Ld(L8Tc=6{-QH;un(FA&akhL`HMNg
z<caqctH`OH<}dQuSY8W-44qH+qRuXE#aSXe*97Nm1!uZ)$SUV+A#b>wnBmqX7q#YR
z?f3emIdu-UoYQ}UIs<kmb++q9GZIa<pN08aIm>n4lyhUA`(X7I1?kZbcHcWn;mkqb
zFWxPj8b5!>*x%<{bF)ZjE3QYtSrtut?zWkOx!*B|SQC911Y57iaYu{YkI(gS7^UI1
zXM4s4ZGGHdzkodSByv1MW18nPuy0y~|89WrP6^DZRF)LqRKQ*NT-z3+TEmL&lsIEK
zWgwllIhUxg7_jAT9Cr`da<KQQyYt+^7c2u74bC2Lw+q;PoZ^qO2b{k-Y0HGC9*r{x
za4H7w6<ETy2HqJ0Tr9T>T)AC_e5^ycU8u@!Q$e|zqeTOKgUC@?soZy2bSHSm0~a+Q
z*7X{lg`RK4M$3&aJBn+JD^!cqaaTB=UbY5`!D*bbWn(Iw5wN`R2=a!z8;{>w-@6!Y
z(f0^@B!1NQ9>q7FJS=ZxzXV}>5%$q|GdykVDXu_&ArE&4%WUkQ=rCWrG&6-;+j$52
z94=6vcUQNBA}M8OXRtA+(#_z2koJ6wH!S16@e5^Q*~*vz?|8AaV>7>>jTA#Wjt6a&
z<>Kc(n<rrVeFDmkbtLDKKOSz*89WhhfwSIXcx2BZ^lx*{`cqszuuh2gN%*l&FXbCg
zzK*ha2I}yPLmfUAPUaj))6)^|NQ4xcFEjCy<QaGiEzh*yeXMiA>CuJzb)O9wAL4ut
zzJ*tfOhcLIJU@?N)%oj^&hz2VaKxSQmp^~urHk@-p-Y$X*iSK@#joc!HtfxKPXmna
z=eqZc@n*a^mmXf;yob~o%g2O+-cJ1H3EITV;h)wM@}}#F{YF>ukdBn2nfpRQuXMD&
z%F#;tv$BDs&rp+=TSh|wb2J#)pypbbuZuj|vv_j0I_)sDwNN*W&BHtf@KBPjNHRxF
zv2ppjBK+B!)8w(BS<k^d4sNHX=jLFduwV}6$+7rq4ko}MiYDwcJxKsd=U|>n8oQW-
z3F3QmFaa!`g9-eDaaWF}bPgtnm(Ib^U(L6eIT)6S^7H0k{P1=T#`m*xFwgREbT<d%
z<FRuvzMq|g@%`)^jPGaXV0=G22jlzMIT+v1&cXP8b`FN+QZ@(k0)z?YU|s~ja1Mrk
z;T+6M;1`>Nc^Uj;b1<)ff6*Mw<$x8<!Mp~rHJpQ4?S^k`p|1nY;rNy^ka9JXomsyk
z=dQm2@#Kk*eQ!DvaP=l;;#IWTx-WGUZG&Vzy_xk9^uf}Pg)sKxgzbj@m1C<Uxdg*f
z{lv$lH^kVAy!STHmhm3wD(cfovV$>CJfB0#g*L?uM`lxGxVJO!X6#^f%Xh>59?YZc
ziSg@8@g3EccSsAjYad??+`)Zi$!p<v@#-hYww=5lxSOrTdSff?oW02#;l}-asherf
zx29X@;JH>ec?;Y)!_t@nInEV7p?TBf?Cdo39{Rr(VR06wiFbwl#x1eU`PRY$4(_z+
z(cj@WN15{MOdW>jHIWZd;&U#&o_D}KG0|*K<N8o@9Pae&!qU8<ujgF`c7Cg|r8T_;
zK*kYS#kzkdaX|-ukHMKF9AoX3v@7p*Zl)x6hz4V!9jaX`Kcbbm!(%M+E6<t{zOEt<
z%<Bi3C+Mv+=H689gY7XoJ<mUpyJ0`F<6}&k+Qa}68wsv-fC+P2`S_A~|1k0y&wFq3
zAy=;wPR5eGUKwTg;mWw`V~Cf^0m#6&!k$H4K0J4Yev}o?eq=3>u3fwj{!s%`IxM$s
z;DZP!wsmP!ABCUQcT!8HX-6MV{oQRYNQ-Uclki8YaAag>C9`ZkLKt}d6DAB~3F@5p
z=6=e#8B=)Px2%>>FZSk$(C=g$<5-(?aa?@a%Gb}XeBZ%x#!M?uWz{$77ibPE*h5rw
z0++R$eHL}Y@jLndbNJT%;OF5Mf8CZ+K7(E33kbtU+R_(Y9Ao2lb`7>a;=Yn$!JAjP
zI3lYvShnv#@O>F!Wu5C+@J(D_#hY<ygG=KEx(>sobRx~KrD<AQ$EO{xFS++O9Zt&A
z7*3HXEGwq%hs*4Egnb9N(zGFyr7h-Qz$N7u!>R8UWPZNqX#GCkVvqVRzG*}I0p7&n
z<vS>okY=%|G2Z!zpV172=r{Nf=9hD3N6V+D%Q+uU+ttW-<Tc61PhCEK?(#ueNzX6v
z3-wr`HH1;tu<m4Tp5b<bi*@%Kemj1=2H!<_l`{G*!e|>@F0TOVGGe)BeB;~XXm=yb
z;`Gl?pkA8MlIf*PZ_eRlQhL4dTb*wDE#Qo58AaMldGBrR!TTZbijL>*(M^5?zvbzr
z<%v;m{0Z=Co%CmLYn_zoYMt~~aECf6{e)hvll~h1qLcp4etY^R)2Dx#PD(z~I_V$a
zF49T28(3Z^<r&=M0rRMKNu7*3>7NCL0Mb8qsgsr$^vV>{u5>c;Debqhyh)oO%*cL~
zZv%7jEG*;w>)jc6`VNOs7vmXtUkBctRbl0Q_zkEj*fG;LK)<%JejDy08*3C6*jTTQ
z#aA}g0EcH|4PdE_^~a>K3ma<?-?Om>u++vH_~&e_0X(&_2L7pymHx_}YHX}56XoaG
zSpD$U#_Ic78|yDU9NpPieLU92>ibz6tM6xRtiGSMvHE`2#_Ic78>{bUZLGeZwXw2X
z%51E^N0`vY`bYSMHdgwDHr7AEFJ@!C7XC3C>tEnsWMlmsU`008zXO)HvEC$v0PQ9{
z*Ma`f-YR2v>Rptri}>x4Y&3cpHQ;|D4#!gF+&p~C)1}?@CQ&#AHrVBle~MQiEFV|N
z8iaqLE~szn`eVNz*5CCAN1gP)E`0ZUXXB$nF)>6tu+GE!bfrfeGe-6(zbJ~LLI1eb
zNVRPNivw<myE7x}WgM$#E02qJsIFE{VWT<A*^iRjL4I;kndzbIdMK+)qN_VUG3%Y^
z-e}g2S@#keb00L)wq5vS!Vu4X22*0zK~>=9ScYrb)+c?HUbyAi<VFO!)geYp?7WzZ
zYud<{#Lw}*jKMd+EqVG6=neB^ZMIpS=q}3>@kpLTPh`65m=}!Kcj6ll*Q_y*8=aee
zg?W_f?wn1tW{qibte2*#bW@Ha=`Z8R-S91AM~SmL=}~dk^iI)^oE<rLX6?CrZSMsw
z$*;N53LV5U?gh<bT&Dc0tmR#vdFn)@yK{x)RwN@xOwOT`yK9B%*VPr4`Bau!1~<T6
zo_QJzO2S-&hLTvxU7q<wmRAsz543N}TCcqz3n(wl1ACv`%Sl;!GbKC1aB@ed$k}}n
zmU1Z!r|;_wVRE)gDns{4k`4ILc6AF!Qw*oR%QM6&cX`I*y$!Z3J}iR^Tp2K*2Xx5i
z6<Hj!cJDxhm3uw+!8h;qyt#Yt=iaw;?_0U|t=;=J?!5``Se|bSe?FvdZ+wdkKLp>j
z-9FFGfze#2o(Wv0h85t`vyF4j%w(fJJ-vDJ#Kd&}=FLY<*SAeJ>l4GZ!Rp9hyV+<A
zPfqsN2F6BO1MR_Db7Z($9c(r0cIvC^(BtE0j|_}8+k-<jt{o%2tOud@P<*owmb)}>
z2lwsqle;+M`EUmYae$^2fG{VMqwUGjMq_eds5Uw_TCdlKM(Xv+(Pn*Uve6o>4f#1K
z4ejNGbs~MF>B~2+OAZI!e8?xP6V?O2k8t0T$0Ok`&to@r)jv8iSZ%c1qxE)kV03h{
zJ=R~V4i67Bh9+yx$!6QnVQFYDhuJ#UOm|q9+)3r}&iH2C@lI3bm+a3wO=Vng82s*t
zUk$&Mhw*L83xWGsTAA(rtlK2X1M%b7Zvf%=n0OdlWHe;<Gr0q`$Aq=(5*aSM1C{V@
z?m*oc;R;m>k<Tj|d|(V*Np=PPPW!D0mpRkr-hs-vvHe!`FWPUVV1Z4_(wfp@jdd70
z<@Z~ubW8VJF>Hzx=aJ>^c<o}p)gD<sO?t-WW$CjfQpgz2U+;-<vUiH^KDhNAsFXpz
zZjqRH<m1fW^uFc})Pvw(bO-7k09(l&s8z)C%A>;_s3t$b{a&0SXTG|<1GOJvSL+Vc
zLEu{X9jJNDM4A_eu(THq1Ak~QiuVQG$jR2g*w9$5HZ(a|tqzZk)cf20{k3*;xH;6W
z)`#0IUrv^W4&<cV%{l^_<%yr$utw6w8j%W-L+e`|>juXB?9WD#Ps;sxeRS714~#ae
zjYfTRxYl25)f)Yi&B>AGz({+jS!*_%t*T!mrJ=nVA&qwdjqHErE?KsBaMY^bB^xh;
zZg>)TYJ&T!wXu=Of%@d&P`y>FjkbqsgCoO}gCmo<66hS-D}n5e+q){BT;)4%J2v9g
zy5lyV$a2RpmA<1LzlvV68SbO-8^@3O1?|sT_c#{*e2ne}-JdoQ;VG-{^z6-rqoW7n
z9595Ha2Dq5*El!pI0Lh5Esu9;Q6WD9IPcChVE;LRZ#<$Or7)~H$=0}GEe94q+!JA$
z?!6qYmmZ*SDH{!SY_?GuxB20+H5{b-B!m;2&x<^K*`6k$jW|!i&pfH_w!xIeiSQ?F
zC%gB3@Fsr75&T}>eR|D!iS;7-URn+q--Tm8;yevMmf!vO#<Kxu{&KGL-f*kqMAL4C
zYtVRBCUsQEf!Vo5oUXD!TV%!DTZg&mxy7b+^Zsz`*>t92xktK^(8i56#4cOiFI_SB
zgu_-x%cHriePMz#PPpnEx(M-eUBn@Y-ZNWCX#YG6X-wD8G554H9Qp7_`02aq#lH&r
z=39-a1&}Ry;l0*_>RxMx<(Om?X)VnmIM<|_TbOOWcyIRRG+!jw`ZHhS$%LDh(rfT4
zW?lv`GcDyH(1&`HQ&G-~M1gE^shrTnJe<J1n)P$;%57Knr0v8M291eWT^UUvFZYps
zvhbr0a5~bsI9iz&eg@#7j-Ywf@CcdG@hZ=%-4AD-+#m7e!MUlCeaO*7Z7-`pMUseR
zk*A|4*#ddNXaB^m%{miw^uqlB_kJMW-OrH}cK02(MCFhCHNm@?IoM*Ah&+bn-p?&^
zf&H_{AbzjWxubc4ZI+`Wxz#S!bmA#oz#*F>^3)X+CrZDNxMd?NoZ(}AoDDv-eV*;R
zCg3JNKLqbo_M*Nf;pQW8*#Gf71+F)`FJQ7(>9E5SBQqWZKd~E?>exmu^q4*tH;d9>
zHPy6oA!#VwT(^b(&h#Hm_){O-kR00E!nZu@ASKG}UgZ=~0CY`%ppS_>VA<A58~U!c
zqcIO#pPUbQ$cKG7^%wT#vOaVx+>{$rc(d#uinsK!l)q^js*ja4h-(@@^EkOk7-e%T
z9`Q4d;P=C6UBcGEIKt-f<#h?-oFg45hk3s7$QsG>;O1J-1-v!gCcKj8v2^rWPnJ=d
z4)m!^{#u<c%dcMRX=U>w(q{bg-TMMZi(kH#M6dN^T9jjwj|<^uJ|2!Y>yhb+-IH}@
z<)1CLN0~5{zKii@S&ObpU4%cf1M~X`z|%Yd+a+-G(Pi;y`ay4!J7T2_v;1Z-z24$6
zh$roL2H#=(y$F87|K+0>yM~`Sa@c+!t8laZl0NE4q|ef>_iWqsp@f-7okuHe{fPoY
zfbQCQIrX}&mxhkCb?Q_Z%^(bQ$cK65T9+7%ZH=~K%2B!3m*w{~_~q*m$P`YluO&_+
zTa?b6)-THqa5+==!T9d9m-}46!!Bz@ip34p%R=X3zq1W=>$Qfna2KsLjKYGohD)*d
zYOP^_!&_?@z|ysb4<n6TtThbcdut5?Si06Q@b|_H++!ZV)3t_yznOrQ@W#e!t}Sku
zwT3Jc<>#$6B%Tar*BbhMcCFzfy>Q*FHT3b=wT8Z*U2Ew3*|mngpIvL{``NXIzMoxd
z==<5VhQ6O&YshjbTWk0@gbCLgJ|2GIT0{DUYYm?Szt~#CC&NFs*6^wDFIsDODPTow
z4WABJeyt$~d(p;>v0h$@y<t^sJ05%n=nlt&>~}fG$bMJO*L@b;^2F`5Hz~<y$E6|3
z%N`QkaN~<-qx?mmq>jb<d9Kun>(jbFhu39XF8r|L^A&Yf;aJT_x$FWR&s!G8$7vg2
zKhHd~49K6)$G7N(FU<VSn1*wxq6@CuJKN(b`T+5~06*%{FXkJMz=-!n^xN2*yu`s|
z4tgVS9kW*le1V?Lddl#vOI{wNmC~W~>|r++d>O*#_kC89SEl~XTr{<9j{B@x_ej3-
zDwhWH)Pt6tKQHd4SNCH3c`5S7GJS=6Uyir%g&h}E`lzE>9<krl3&AgjFJAA$vn?^a
z)H&n44nOk48~Em@i}Oaf8LkSyG+Z!7d@aJHbqTz0&Ttrd$fq(!cphNk7~wVWlQBa1
zN|NF+!dn$?JI1f{y$yaW57GPI4!1nr>HXytX}!NRbVTo$vb}<|sj~eg&U{>l&26;%
zz5-*N7&jN1cUCCPmbGGXb*y`4eb1edcPr1Zehm4=PCz5`-tFp-Wzp-(;_@4;ES9mF
za+S(L+9b>4z2pZzu7CR{%3!@KgIC{RWst3GFbY1H{men%uj2~KRVo+CIhG0A^7ZB%
zmM5{dQO^z4I%I9>N>*8}PGN{_uAw~0FCW00ve`Ts$IBW^%}XC79P<6cE?g|0thvm^
z3;OjiJz0Z!1p02CUwV)sWa4<7P`b#zS^OYx;m47+J(nTG6VBPOz75?<KR5z)&wl=s
zl3%2?F=@AE&YxH`OWW<|xSY8drjf1fv^Kks0uTGtkGuD$@s5>^tosx`l>RfsFKa+!
zII^{#l|ITf;*hnTAAy@|JwN8&pK$L_x%X$?`}6Mo1^50U-og)Gvfq6l!ke;`G+c@A
zv>f64Ww`lBfBb&9!~Xbl@RR<ybp4;H-?+{Fs|vUD$6tXT^DX`H*Wi|?yZ*SGBHbUC
zh7S5;l%;7;EI-kEzYZF|i63?8_e1WoT&2%8dK1=he#_;9{K4{P9uI&H1rwXmncoJz
znfkN-T?CyKtE<?$)FX0iesT7K&6^uCEt<|0Pb|zX%{N-vEVUiW6$aEZj>L(k;l>l+
z1D%wolF#qJt@D}L0XHPy1&n3GIJTdz^j(c_X$N6>`~WaM!ka&Wn`=HfpNt|*uu)|@
z-7G7*xdxQw%C^WfzR&n*_dnqqkHBI&D9fC2E(K*K911-Pm#qa5T7HSJVcpE%3T;CD
ze%Wj93fX3ewd(_kGh8Q1c(_jV3Y;@!rnzw__0-~mS)2AI#9eJ&jrGViqHh82PHRL7
z_tp%$#hup1Sznweyo<!*j;#?T&Z0G<3KrNBExwc%OF(puC~@dB@@Hn}x8b~A8^alE
zxr9LSpW<BM8qs$K=^1;ZP0bD%ArH7F^j!$2*NDCkZoNkI0|qWSg3*{vJo0&_HDzl=
zuY!Nk8qse9wvsiXKSn&SJUXlqHTj9G5oNxjYeXT#E?DQ*xj5PXGlX5OHKM-&t`2KN
zS7K0viN@Oceg)j2txx1iDs!MC{Tku;X!-XW_;H=ZAviDU8V6^XxGiwiTe_9;g=kmT
z&cwMx_6stfM7j6}<eBoCdn_mt(P`!7^)8j<kFIQF4JF$HN<FuRat^-e@7;PS+fJw_
zat;jZs>r@-y;N_)bxT-Z<rW9ov7y-`3_58a;hgEukybC>zjg2Jcyp}4G4!>D4gm2i
zcTMBUm~KZ`Gp^29LF$lpyFa50q_32I`|t2ec_00!^tT!BSCYS(cs+f`qYgx`^x|R6
zA#H{_0_P(|NBAec$xAZ7eI4AaqkrKoZI5{W12=7s`kcCdySNNTn*i}9hvLTve8@*|
zq<K*G6M<#;_4#&o-juYlOsLD)Z)+=i8r%|}>8@kCkPRDL`eLX2FJLh{WiP_XypCDc
z=IoTjSp_Q6yPmidy_7F#SCx$}4M0(jq7UkuKH@gal^<SEV#SuV;Q1*Vtz2dV;>i0v
z)mHD!l_@f;>yr9mtS(tc<X`e_yQAKmkpb;_cH6eu8GC;`Td`dqeas=szhLDQbt`E*
zyQ4n7f_1J!dq!VR^5lb9OBP1C8LQWCbxm(juT&FOXvgDN7_&1GgsazANO`2~qf$xs
zbiAwi-01R<5${7k!iROaH^Q;KiEVo)xG5KQb?=+u&2XkKLY+$->iGPoY!Dg7bqu;r
z#Eu~P{(c6RZP&NNx6n-*_Qj9w`c{17xjD`cqn<}Tv^qSt5JP|9`qjT6&B9?;HXcLR
zN^(8I%D9?iU#>H#AdQQ=K)|p&Bdq9fR?qKEc7vas+0}>dr5U;`?!Dk%sGo1mD=mAT
z=05Plf?k~dD&E$1&N4-xY|fG8exO?*9Qs_00!+M~{o#)3Nq0n^(z-@H+#2Ed<jXT#
zi^ehTp2=|K02h|w(T}@%nYA6`J_hzEmSqppmb#F2g*S(v*f>geaiWY_PLu<@%jjX|
zIwY=x?lE#<qa6X5IzCXP#d??ZcejB*McpR6Y5Uj->kSVw_=uBb;$+hQcz-I}VA?KJ
z-^4a&&Tuhp7UT2{I$So!7MV$X<51-9{Eo7(to}WjU1SMS5<IhST!XsjU7vfHGPY+*
zAB^vaKwPPWHS6>jpu1o_xR2Jh$)4LGJy{bW^TInK(!t9;w+GI!ZE9WZFu++?hvQB8
z%D!g<)~_D{w>-EHu6$l}M+m(E`X1_;%%jyad(7S~(K+wz^3HO&6TaC`@Vf`{%l0`|
zpS%m)RVf#zPfDLrgFoXijMWQmeD*&g@0k9Pj1N22pu;2ahfRFj=WGEEsS_Qa^z<_x
z`kzr3UvM+sAqN|CFu}bUZib^Cnc`4wRdA&A0smc#@CW)A=NgIAJPIf2zZ7GCDGRo3
z>3_e9HV}&=vVb<vyCJ-|?~ZS+Pj#0E?2XcS*r4;C$sfskT7J+;j!)y+apDNvlyk?p
z_X&859&(iP8+Y$};e9G}0?HD552>{!+y(w_@anp0xp`R>fueO!`Q2#}!|r3PBu4|c
z^!>}*)4fY_EaF<Tl|3YBuYGq(wxoXQmb}IK<h0cjdhP*u(cQr%V~Wn1G4{#co_hj+
zD6^zJNZVwa<u}Jbyj%DrxaEnT-L@8`Zv|HzGln{LGfO_t%Nqq5yUEGOU)nyA?@)f6
z0yufu3kMxqx8tMGPE$Syj#FKkv25AzNn7PN<&KQO?+Z8i|1`WsM;gF)s3V;SKhcq}
zp1EZ2t<{m(w##&+(^Xn_UdYPHGvF`nH!T|_gG6t-ze&S#N4I)YIsL5ru5;_n8nL|Z
z1e&C8VcD|G??*ZzdmrHFW!@;WnYRbgPvwoUIR`U+N&xe4qQ8-Sp84|XNtzg|@*#{e
zJC+`4elz+!wmH#J9}Jq<9h{A~rq$AeF%od`VO$P-$x{r+J)miR72OPH`V1G2drGr#
z***|itJXledm>ERrB59*;{#vD`)T@nMMxXxV9W!X(nEod&)#lq$8rwGcK1e@;-Q(<
zLpiQH6XB$t$hht-_;nc9*~nHFCJ#Yak?k_Bn}DB;>+1N{<GM+>!*N{;e$jEAsh@0I
zw-w>^xb9rILpjWTk9B?yV0=%x_cY$RUiNqOLVcd&xf#Ia>3%%7a(!O-JmVjv4*ums
z80-8Cs?O&eeJ0)ppYJmJfaOo}@%7*h)^8K>ly%6A4LE<meX<9e)JpaNqYh9Wt_%79
zXCE-z%vhQ)*5k_e0neh0*LolDJks#?0bADN7`<l^u&^BnuT%aUaSOCTgrS|0dw<Wz
zw>;&0e?1=0?2qGH#`B}DaWfZB9;JO-%dCgFG_M2=#cKq#trJ?`OtU`UoZxiyO2@QT
z0rF6-p1siY2WYcwZ~W%mx#%eTroYq!<qhlM;V1_wAKkt$cI6{uqDR6l<BRve_V6S8
zOxs7f689q*9)0m8E*{6sRaPqYI6WGEf`|3bc!Z_#RG&r|$4G>kCxFpAt4G|0=+a|6
zj+0{XG~F+Z(XG-DI$1tC4^KuqCchgr-F}}*+Ojh2NuKIxJKl|NE;4RAzIhD3<9hH)
zS&Mip$>V`n`oHClZJvO*;n?O$sb73-^Ax~~#x`uJMWeL*REO;fFjHb=$kTu~lp$P$
z&aunW0h4E0W0w^Y)N$0ZI@5^hTnNYVhwhWLmyh7=HS!_#v}ET>@=Uy+V%BF~LUlqt
zdFi)#vs=UOThHY3CfD~Oces4HW5^D&m2&1T?mQN@kFb3{%heUbJqO>EN75cS?``v1
z>Erj2kWb7j=Ng#T7a+W}$LFi>7vkHrMFeBo&xM<^=f!;Ek@Z&7&{tS)l>L{xb|1FU
zm$*2j?<kiK(m;JD!Md}T0nW52ub9>=7#`z9JwEVZ*}e`<qm7sC(O`O{Z8s;YP1)f4
zjj*e7ek8ohmwpTryZ`H@@Q>D?t6|#cFGm=W3!)dl3V!*y)!yXQslUa_@U+Fh7XE0J
z>D^zPd*J<EuQUFH8GSfn`|L!WbcwOcy^8yEUB~1XsbgJtZvb5^XWr!@{UF0inbV(r
zqVU*T5T5bLBf9Q;;bho1F`wYGx4QfaU!*YAj}XRwj4<;km`;N<GA#S9SXkkqqBMFp
zDB8f6qI*mEh&<tZ!F6b3Vr%=Cq09C~ZwCzpeNl;dDk8<@9Bc@3_D5F$xA5I^`=fUt
zZrC5aEA@-_NACu_s6X1F%s5-ydw@Uemsp=>Xb5@nUckl1_C9>ev#fq<hY0Q1TZxS=
zUvbN{v9Vo!20X-eCA=o`TzE~wu#M?5`Vh)R+T4fDx4i@QNQ4u9C+-ij{LtP$>dKKg
zZpH$2<(v<@J~<jPnvd9AK90ETC_jmJF1%`!q?PC4r!;Ixl9UG3t~3qIM{FMKQ}7SE
z+|t>eywNk$hd4H7-%~UX_GzTI?0K*b333egS>O!$T;{qy512fwGuPFD7|YI);*@by
zK5l`!QaC=GM4u~b<B;pgrFOeDZ)_61#wGz9kM%>>w=}buFf7F<>=4d>X`yA#DeE<7
zePR6@`^c%8CG5~JF|OTCooyXh@e8W#Hlc*``zND)rF6QhqO(0~&F;d?*F`$_5*-K>
zF1VCv(OA(Ek{Foe30GUW<;=75E0|*FxC2|HX+GP9(zNJCOv;}xfj2}?;kU?5vz`Pp
zh<7rI-25`&BF`B1D*Pxbzsffr$|;G*y*2r;>yw`v9UzmHUqjqp#Qg@|CO$hgmoDQ|
z$4b*uvXe0Cz}>+zyL3KYW@l#lpJ85H`ZBljUHEY=>h}zd_RL4_8=-C!!zX7C5g%!!
zJ>rKhe;;%BrF{JS>GOxeyk}<&$ykQ#c0Yli(D@Tb=TBW)lJ?KwMje{EmihEw!jJW?
z>Hih{^m##~-|869!=cN`{tD8}IRJU{n-6iZF0(rE&lj@&XivgDX~fO=II%Ig2I(>`
z&;DUtONW1N<ebB6qM$r4b9}^ja~o_t3&TIkgpWrr{0zN#8y*FmanCD=tLfYB==1Xi
z1TGzuZ->XUiJ<SMPR?@W9FEkT$vegc8`g6ky2st8VD}@$?*98GXmA};Dq2MRtUzEz
zqpX=^bn_(NMjrH;Jl}!a>Dn-FPT1`rW}Qt>5{02h;@VG+4Qbc^K`g#HlPAF8oyilx
z(ldFkCXHR3$rHr)&g2PT>6tu%f3S}xm*@0Mo*<rCSkE(g=x_G4s55z3Cd$t{lgAHl
z&*bs_?3p}2_i%J~CXbKDp2_3;*)w^3KYJ#R?`O~C@%`+XJiebjlgIb7XY%-d_Dmj@
zi>%$o+R3IYJTr3^j^}=jFyWazzlC3TCJ+6>GkN|1zu1{Pe}sSROrAf%zvxV!YXK`d
zljkphiQawF69jhb|5xN8)blfWTS@*7INc&QxgMMPBk%va4lsG*`*d!yQqmiBq;-2E
z)*p3W#{13I?!NoHvMYVx(b1l4WtOE5sjRw!AE$5ym0fs(EB88xj#WwijdnwQ|37$(
zzRz#!`=Z|`x6gDq!v2dN_4^+9^U3hpy~9TDfqxb@uisY?mwMAWhnsp&8eZx18aMal
z5qGs9Y#x@^@3S;A{a*Csok0ur`CS}MemXsg=<oYuulIU{`wHemIETj{?M-}0gP)g7
zchB;&KG{8*?@X5$n)Yxs_2DggYnU#_8`O0({2P+J5k7T8$E2*JuFw37uD>tBXkDMM
zo5N4*`nkFUE`4q&b@MD<UN<MqJQ3YIgCT^{nW=jh!N@a&86H%8V(4`7EG)A>%RSn5
z-D<Hey&idA>s}(>zC~(9g;p0P2Gf5g8$iF-qc_4`q(?_#fgZhUEWXmC100?n9l%mO
zdN<P8g&rNm_w?uhmg>=ge@>4M;He%R_@{a_{guva&bDNkC_hh+_QP8}+V``1^j;p0
z?(}FMkJY1nKdVRkepZk6{j47C`&m8O_p^Gm?`QRB-_PpNESEAp`W6Ti>e2hbFVv&y
z7wXZsgkMaL-XH!kJ^EJgFVdrL4Oo#LeH*~mT#sHGAz;=j902-59a`?lJ`gZ@;&VVZ
zP3gCq3Ua(^R$u=zHZSzVzeC@>b~f<*)SC1(as7D3mYxm?b)zEZqZb*iyRw0IkFHQl
zrcQhi+KcGK{I)i5Yv-kHlQve-kq-f!`j)NNN^(26MR#J{gYl!zd??>|Qr!$Qg7L8H
zlM2R8e5ecZexJh-m-^2Uc#EEy;tq5n>aH;u)3s*VEL}frUT4nm<aOpdgBI${RYy~Z
zE7O^+UYy~I>BT+CHPEH=dCTj?11{YmyjfS*V13PQpd_mUi;Frh(-fU|4BxC%8KctX
z%X(y*Li=Wf(K>L36LX({<?1z}6EjVVC)0^_oeQ2hS5J5$&Ak1Zc+8{fH><;}yr?tB
z!sclOHsqI2hDYVg;W7M*e90OPu}422`o5eCAG1f_0rW1n7s)r*|B;k(_UI##2dzin
z5$+;AItmN)=vpkk(xU?$o*o^*Qa!q#G<Km!2k|{UI)J5mbl{)UqXT%VM+g3?9!-Cx
zGaEgcWup8%J=za%^=RME>e0g<j_&kmACJ|eeLt&5`+ioB_Wi6L?fY3h+V``1wC`v2
zXy4E3(JYrTJ^Cnw3H9is;TP)B^b7UqW8fFlqmPAuOpm@B{EPJHEr1p2(Z>O{Y(4r$
zBM7WL`X0zbs7s5z`2@h^Ssi=xjVALY>U5sY|Fy36fe!m7mS(2T!_t?nt@<1;@S8tM
zuX2H5g_+@cs7*&W)63M%VrzZ|r_Z(LTdj$?+3Bgqg>sUNjT>Mbzt3^U-md`b__%|_
zu;SpHah{7P`j{OHP?xzEc#As9Lsz~wrqk;3h&kKrV<|8`b-UA~2yG|*-z`|rM=e-3
zWj5t1f|kGTs?(Ymmb<lk<K9bG2cqAf3^(hB{tP2}72}+UA9eft@Xb%?ob<Okr`_**
zU$`0nG`x>g@rmyg{22dqzWM3SW4|BVl1>&bTURKslm_e-J=5WkF~b>fbIfpmyi+~d
zt?!_nI>oE>OX8(29D@mM4|KHo;ry`!(@kkZ{vP6J%j3_+6|y(~R7dv%-1}_2#U?(1
zZ;m<YcuRYcG7ag`<Bul7r}RL#mHHw*epzH=6T-ZBNZBi6(9s57=5;IHF<f#7n9zR?
z!jb-my6|2(1@$n3Fd5B=<aBqY<HyU&m;A@NlQ9o@PR6mb?wj#hR>VDrU${S6%JDn{
z^KJe@Q!E~7%J?RW$9iJC-9Q!7=DY#JS^WNeUgyKVt2`quT^@5TZF+}eDXvY=aAxD0
zH=4bmy~!lfjLP>F_844;G6kIB{^4o(UA&qJxiQN&;BB@R>y54UJg6DC>x-G2>CU&N
zTUb!TGisB0xN+X7Sq?9IFz6@rZkn8(<$2x=y9j^TvwVU5o~SpQ_WszmO^^N#zgb$3
z@Lm}1*<k&nl+9UGT-SRc+!GVc_VgkS51*Z%XiU#8EX^DGdLC|I=eHVLTGLwqB#q=7
z&U2A(%%j>0b%4E+cI6QQLjbImHEUXf9(#o~YSp4B#vRlFm@kgsWBDS?Z&S#amH{rF
z=|j|b{afqo`mxWVoymAT+{Z&6JqzWP8?WEkv<JuI4+5=vT>fCVi^k<qSTHVc#Nw-Q
zd4R(kmj|$PT;3v$U5v|v_};iYfTiQ|z&|%G58&yzJn&D)<@8r$a5FAvnJ7PRT<(Xr
z<8t56j?2&WaCA2=_wm?qx$kGk<-VUCm-~KpT<-hXak=kj$K}4C9hdulc3jSKDI1qB
zAWS$eUxHsaE~j5OE`J#OV&n3Q;2#^8KN9{$<MKxVRx~cZ1hD+L{KnSc?fCoApfwzS
zb4<kbUXKAxo-XIIZfuz>7-!$O#zZ{xPISj_)5h+`4(yW%dmQTly8V0Ic^uU97SlL(
z?DKepVLwKll5w8MIOwbNzE$F@?1OdB_!0IbSHEJX=em0Cq0Qr|Bu{l=rLWA=$o9Ct
z2m5N0eR|CuWkvlVb)6>wm$M7FZqc3Qr}nQt8DV4}q3BMR!q3VFvKfxRZq4KR`o*n4
zf?fwZbtdcy`V#(WX?VN5gZ|W!zHZ8qt59K@fc_=>S}#L*c|@;SSoF_?D7<FT9S|GM
zSHVb|^sp``F$X2}&u@->WeoUC&?IF}*fU5Yc;Q)&Rtfi0<SCo`=t-UvjhC$vV_3%F
z2!`_yGM0Td;&K1n^J4LpE@*fVdXbDZsQah%DIH1n3No!HVJ#PbF9Pn2)^*8C;QpuK
zol0_qnUAw;%wGV1pF!-&!zJ4#^OlZusslTP3=dS2AEAvD?XP<w(iQpboin*Z30ryl
zV&D$tZCaLS_g6#5=J}E@LpXW5-*dM^1bVVk=X)hH^Hzt~tp}Dkls)U6a)^9K9%bH#
z9RKq?{BMF!P&E`!rfm?W+rz67N7@5nm$RJE9$w?hOJr9H^LVz$q$Oka*CUR|TFOnv
zc?0pNIBR!jT!c+2*07sxC3nW<u@wlN@o3F#U%UI@@|4L=*Ug)ke;-^P+w$_cc6Ywz
zDa-PS(Mo+=i~W@u7@(!C<j%Kz3d_s;THo`Qr!Q6loC+{Ei)DpEuWl~A%O|j`0-$Vo
z3)(l^xp^RD^xbYDOyA!Y!sL#&7*3hbkHND0((<&(ooKOm`X029mMbVQ@yOk0Z$ln=
z_u1Rs`wI7dhkL)%z2D{D?{@F^;7z;cTk#ed`96FfY4s6PcJ!A%{r!M_0Kf1auT1u?
zOFjrVAIf>+B`%5o;V$BT#KmXd!1&CnzS}BG3xL38lfg1uq})SwhT#FbPMP7td#DKS
z<{qlof~MjXT`L(5SsjIEX}k`&JKaM?xai2sJ8Q$@j@?5=oJIFgDOg|^vG`J2ticG&
z{EWDpFk9s6v|)PbE}T0x=QbY3@1ZKq-(>5YshJrg720w{U^+Cg>Aey8(f3{%yNjjI
zs+Qnqp0)EPgwyv>y%}zO4;9;7Ca{bYH}S}mnZJ>3*dMtuc`y8FpUq%44)+dz2(Xph
zL-kR_OUsz|a&@?e%H$_<4;Ay(?LAZ<L)c5!Wm#B2S#kWtd7K~bKC!KS!PK^;Z4*;7
z&DI4nwj%83yW4uV0IT<Y9Jp3^4^>|3OSb}gXyg6_aECgz+%5G<z~qUqAz1a+YxU?t
zw9B7QjcRPrrR7d2@+L}P)$fFoyPiI+%5XLBdMd8iRl4gbpTM&8g*93mkYC(k`FRJ|
z1{9&~Vr@V^YC$;_tqtfJLC3Ygp9P<Z9faR{-1m97sTXnVNZ9A_<GAlizVYN?*_|n3
z+xP;)GX59wW_Ze~6qg$F5ytUgcQAiG-jA2fxy!utSCBU6rN8QE2*c~Sbe}$dzC475
z^WWca>3kD!>U7MD=yc!4w;uNr_8t86dfZ%jLRSv=q-F8^x#c-mc6b42e!VT@nI|Z7
z&d(LWym}Af(e}i6h9{KmN#^I|9M0G|dz_#965={LQ@ZunG|7S%S!e?+2(K2?tO%`X
z!I1Z~on8f6_59qI;Vzn=i^78Wxv$0ItNFPAhc`bLz|#4-uam|u=I4U=-uzquOXueT
z|3DALeawD-()qc--za0$#prKzLUoP<%S8Ek^K*W9J3r_9+4;F|c{sY8pY!q9`8nUu
z&d>RNc7D$Hv-5MlpPirc{p|dl?`P-dd_Oxs$8sr~pZhMtg!6OXgI_p5N561>?)&hI
z&CmS+{;~PFAHu(Ae(q|(ist8j1en-&Z@dlO>b5@yt)Xr!^K(A|OrBMkpUZdR|EHH2
zy9N6X(M$NP^^%{X4y3On>}RYK=q0~!btAe&3R8U-`(^q|zx->&(fu-EzabtKhxm9l
z2Vv$3U|)rSBnG=G*$KVJ#tP$p9bxig3Z5Rk<2_ZxcI}~+(NCV)3RKPldv&hNgL0rw
zz;ZD4p>%@FD)#Q7y-oSqHug)Du}9<zdufh=Y2)}6@O84=Tm!f_j$g+8;lv%Y+t9zr
zZlhp9e_2U9TC5@wwcDt4OYJrc+cAG#*lkExncaqWG5wa|7VC?0@*@3ym-^+;jHM3v
zd%(rkLwg3@m}6@!&Cj<miEKc$EBpce7q1FqSU&qB@P)FR_Yv%cwHAK@OrE$bUll^E
zZNfvfN-Yw+PaE$EnBTRsvd4UjZ2L3v=j_PlZt1_kEp3=_u4VqQw)(HG9AsX555RKa
zAYcFP!kMuhqW%qTjuEcII~QKb2BDF(Fx<ZoK20BflD@$K8Ir=340$c)syS}>2jZTy
zgexMf9V+=J+!tF9qpSZLZdvOociS*bb85j{7Dj!Z?$(UGJB+-@{DMoMK7$pVy=`~+
zVLd`)cJ4x)McQM|9K~6rHk!L*^gqB8^41J^YnS9smFoeMN9;EZtYXDUTyu*}T)w%m
zh^u{#$5Gftf%!+92{McM!rY7nkDuVgaS+|k?XqlNip{yUZ0-3iOXzC`aqk4rwddNB
z<gl!M()%EGS)cU4pO4htgK-Yc>+nk=uvD&lFq>Wv?DkBLXU2!=rDtj*-ufUt?zwyc
zeoQZf@$BqdalXKV+4Sz}(u?Jfa|ma;csmE_rE?R&8N#@p^mC4u3}(~&3H*!lm)`pa
zoVy3<RZy1eTzQ5t-ow{$bPDWc;2l_hdy#APOu)!Ezc?{H+c?)PpE2_ejr#QT=FJlm
z)BT$_%avdKwd&;1=-|j?qczzY9T;ql4h~jZ_5OByY_NZ%F<>|RbR8NOgbg)E`v>}m
zo49!0%9_29N9tnFiqh(C9Xh`~hm+<P+aY~J1MSIy{zh|Tv^G*5oE&O5hpN?)cB@`%
zRI82lkWXJ}=oo!B1AS}@J6x6{{mte`|73rAWO$@CSnVI19Im$-Lt|t0(ShMsd&H-;
zG<1yCeO+0~eKC8(y$^mj$B%82_NKGYh979;Q*Uw$`19G}ybbh^4EGO?jttjp?Rs;v
z*%%od8yst(W?GGbf&QQ#N<+u;c1zH@Vm=uiY>kZ!4>cQOL#=_yX06(+x2q%7;YM|`
zIXu>?`DI@kI!52EK;NqHNxfBX*N2-!^^sP6WUw|^n{3xcn<&|l;jxkCU{IE&p<}e(
z#+9Y;$^LNP8ovYZi}A^U@Lv@^8Lkbq+Gqen?V(2h&`7=69v*ECjMkd%)@Zd|4f0kR
zI+nNFg4PxDNo%q_JUlSj8f!P2W3B3BZKTy48kuZPjtxy#M~23HJ}C_yqwiqQw<>%x
zI?`XCY)v*thij7~&B>v$$-(~C;8?3ZJT%-tFj@6!Ee#!`^>(f-g-;HG`w;vN#V^Ju
zw}=0#@X5#^%6_<At2GDOwPv+7Ff;&h*&gk$4v(~}13^8MhK}X!aL~G9KB@KB`o|je
z!LeF(WVA8X>W5fq)f$7<#^6YGbfD#zeQD?zeRlwTtHLKE{loP}d!WreW_S`UZLHDi
z@9!TOt&R>?hlX?gPD$t(t#@=~DSUDSX~*wQ_{I3-&hTFqJ{fI|4iAsk+hb#+)v;!4
zs8*|0tH|MCvtFwsvwl64hK}W}23l9lCqu3JP-ARxv^@;DS3@Hm9&R`LN9quK1C4qu
z=yys($LJdXeXGJJ^~wIR{#vV5>#vRt)`#k7a>K3u=0I~`q}_%V=$B<_=oqa-t}KO5
z`r#hLZy3KApNznNRrsViIyBfA?uQ0DFgjcxnCu@Is}0wi!_9gN4WU2alhV+!yp4g@
z74ykJbzo$;Itc+%9j*6I4zwUgz}ExS$?9-@wA%2?zBF`<zPo_FRpFCCNDk^IgYD7A
zWV3&0tO_-DU=Ui>V5@&}vhCAa8ahVnU0qoUpKONvDEyAbFUBXwz@HDtu9Tas2iXtt
zZj4utg<rZ>9dns?gPV3+$}O>NY{9qKZ8=~f>^S_)(`R4APk(0{F*Xp9aT4bqj04-o
z2`(<_^<Z3>@9^beJ;~#ZZq9t-EGq=PC-CrnFZaGT-a-fKli#G>e%pN{C&NwLC*e(c
z4NVAp3cmTw!}dYD#qn^9ZR4=R6RdgaO-_WL4Cu<c4!f3!WlRg6*^1%jIPary({92s
z#)jn3-upTl7=!yWx*m&`6GKx+*QAGhC%ndckeDCZ9mpfp6UZYe|DZNbgCEQNbi6gs
zFzgxlnMd&q{WZ_9f0Vi>?EZ`co_PS@cyh1^&!q8SZwq<mEZ`x}JkY%#gg5DB9N`(#
z&TnZa92;_fhuG{U04E&}!8=V0;p=eo$;zXWoDDzWsWb5%^3;RjmsU)vYFErtlM1)y
zsV4m8SsqW7665hyS?D63lCrftg}WC)@1>^f<$UShqzyl*3-aGN#_iycSyOP6AKA}{
z%sLm}n*Ru!#?L&8|LCvzkMdM_jIbHT0sqbNjVA|-@Lw7)!hdtXL;gF@z31^J|1pm6
zA8EJWR%R{1&2$&>PH`ir=fllM_-h;7A%88vPxz~}^LF;wn9O>Z!mau10!IVsSQdYk
z6QlX7G<3*c<OlYZ!VeeWTk`{94;R`MKhR(EgY>JcGr}IpIN*niU0mUZ6c*u!43?Ki
zj{+XzzQnyBjW_v$afBa8yXJ?-!Oe6Zi+73}Iek3be1sn!0e8p`kAa`?L#YDNfghfr
zaBF^eqN9OyEQ=q?iP8K}8amGpl|I@lFGV?NS@LA~rSclG<SB5IcW8SR-nkUtns*3$
z8h++cyhDG@JG3zhe-QR`#sTj<gKs=JScG@dcoA9hOyD8!Jj=bGjW>CRafEkByXKwe
z!Oe7^i+73}Iek9de1vx{gFED%=fF>Rr`-Hq+*iFo;nuwKLPrDXSQhV;6Qg;jG<2SK
zdirQT7Jhg!zBNA(_7b68@dN!eKinK{sdK_!#yH@Im-CG$2aE7S8ZW{RuK*tM!z<nU
za=gh8j3fL&+BHAC25zSNYP?h2$mwh0<|F*@Qn*8YcoqDFA4-k#9c0Pt6mHEAuXi+%
zj%D#fIWd|aN<-)Qq0%=1+Ac*oX<70{_-R@4Cb%g}hVT~Nc?-TZ?-2G@{LG_xhyI#(
zhT#_eAnfgo1KzoUZ#+3zgm=<-5#D(R@Q`=j>E7?co4ms~!aJm0^UizWX1edeJH?Hh
zz7K9b!aHw+JLH{r!%ujp)L_zqciyjXYu@>Qqk(iRi+9S2(Y#X{I?p>jeKpV~{O}=s
zYknZ?!$P~_2l{J%=!aYCoUo5F4*20?eB;T%BK(lXi}1t8frtF?3HSaa-sA_y5q==;
znjby`H`Dzz-YIV6^s{jD5q|gx+#x@F3Vy;5rN+n({O~!2Tl2%`9Sx*oS^Q8=jOK^Z
z(0P8S^xX=yU5awjvg8Z!)3W4?a8s7t5^v$1tMILPhp;c>XCB2n^w+$zKit9}gngB9
zz&l^#8&3`v;hi*Igm=CUJmj5kxc4{lChstg@D6F$yz?EnneMmoPH`ir--Vlx@XlA@
z4teKW@DtuCoj~otJKs~dHSc`i(Lg$u#XIH1Xx=Feo#&mNzT1E{;fEjMTk`{9R}1Zm
zALy_7;Q+X$&I$W5<A5K2!Z)5AEW!_Iya+%16nMxFKXdP&<4t~G9N~u_rr&nV`zyGa
z?l199aU-X{hMSM@!;jz&`QaDv6MiV21n$5Ozfrg~KV0KzARWu%hjL;xKa_^f^FyWY
zV9*xIlHb8k%aY&2O<8g~yoGoEh;Pk1g#8IW^C;e-zvi7o;THZN>{`YF@BEo>JULi|
zchYzf-uVmgkazy--hacJyu&!cJEUF9l7GO>bg#oZ#f_Z)6K+1jJKNz7dFSu&6W%GE
z81BG3|5CU$@BG`*KsuJiJLSY^-YE^8=bfIu+k!UXhwJgJ`GK(i3hjy?=&$+VAh@N@
z4Zg#XQSd{BZ#+3zgdfs)5q{_e9`eIF_g;@T`GIkSA4t3Ahm8osba%o##f_Zq3^yO)
zhXn4BA2z^G_@Q*sMF)P^Md8-`u&bkibS#S>%8AkZP#QYq2RXxlcG-<MH)|W_UTFWP
z95Hu)Y+RS@4%&4%-e32oNVq)_PVT$oJ$JM(5+`wUJ!K}F)+c)*EM*hNSHg=ogP-ss
z?Zt%c13&X9UZlU~MUKaW-w3-o<A4`$;o|0C9xvMUh>t~nNT;mvOky}I>y!OcoOW(%
zKe)-Kw{-7Y;Y~heUNmps25!<Z2)rqc$oT>A=kt-o&PVMFcgUN!hM(|e=>)msP3A|>
zM{&KaspAAoWnCENwGXK+PR-89o_MbR+%K^=8_8aHmc^!|K7Y>i)B@M?a^CDfMJM^3
zYZrIH+}0+SAEtg-Qnq$+ZPx~byhy%{@!~<CnY?%h<WqR@5cp|cB<yyQH^qze*SvTv
z+`?~!-JWs4i<nz9PYzbXi(LP!c`?NaUc5t!)AHisaFZ90aPK4WCNDBCniuZ`H|aPM
z^riTa^E<<zkMQE5aEH8jNB9XZmM-eqL0)9uyWz#EqLaKhnXJc}-=s3+>WO*k!8|LM
z{4TV%PMEdeSTxS%zDHs6-qblWt>&f)900L6JZR?b?{~~0@!;bV_Z~Ore+j?WT$wSA
zQhqNlFfGeVLx-}QJj^ks@bDmL(>zSrkkG4mnEslFzW}%JDPbdw10EiAadR+_hwWT{
z8ZRO<$AE`?y4k(&f;ah;^lCo6E8I-$)}SH9huj?ve?G#e!*GXudKCPGPfHiG?jWCb
zD>IK#bY^^d2}@5samL$GJ{@;u#)L}ww7kGHpO%Ks^J%5;SkObB+u?QB_5PvJv36~&
zF;pAEZjLGzm9>YlTD37SIxsZU3f4)Mh9<3z{;{E<=8#*T-(%*Jq)lxB-Isy~$*;$`
zJdj7JuiOlLdJidQ*S_Lw`X}0U|FPWl5iaWQ$2#Z1)+845wMVM8#xPd&H5%=De|>DE
zKH92H`U{LoLwlLBdk#peZS$4BdxB=&?l@Pr<Mq<yBFpx`X#a4n#cdPy!Tx?!OJiV&
zOPz!DX7#erUKX&vMr084aW9rR<kN|+>{&M_;hXi83#Vk2tamvcVegIKDfs2X>wb3U
zzJrkzdH3%4QHtHyycy5-!6(B_*>)fIJ{51_6<fx(ye$t|8_4|-M%x6>fSYvegS@5r
zLtf5=KOgGRq=RQt+#h}-2T#CvC<jl6pUA<|%^y1`2fOXBAE4;ey5j@kFHfnAD$k6T
zQKg~tGODMKZC%>^gYoV9NV9f@{=zE^_Yk37^{e!kHa6kD8HcjsE~wkdTpY^}<VW%h
z!!W*1r_MOw^`?u9KHsdtI|pHN;S{guVS0^%?X#I)%i%xA;TOJc!%e>4>fTd$3(hoN
zB)trljh&b`mJQp3;D4yYJMG@v@MbucyR;jYq5Zabo-<+W_j&jxJx3uAX_~;l0DnG&
z&ET8qnlc1z-oeB!a5mgw`#BeW(tb)i57&NT>uQ!1Zt^_aaMe&|&ySTh+)&{#W-#j!
zXB7>l3txAz4R@={EGjy68@>Sk@|3pW^33QqTpBuT!?ND;d_~i;Y%k>%uIVcc9rj_=
z*V#`|mPlVjp5Pipj#J4aY;$aRk3cxKhlk^>Wdh@0jGuW@+0$d}!y>yFM&!^X>9=h+
z(&teo(Wd;E0GG6J;&?P+kUfueVMq_-SlkvLZP2+m5xKy4PjL92=<wy^<z-YF&%<f^
z-p2zE%j-$*{S>?fXBJQQ=QiGxUHGTE_tWrZ-k4{RJuEl*W*ulb^b8Z;=Kq=aW}1f}
ze`%Vi;b+004`ENocUqo+J=?)V20RY#P!3%NKaoSFo33_H26WqxKS$9?86a}>QOaLr
z*rkg8Qf1H4ACsfcRk*d>c^>@bDV00r1*qF~Y3L%k^L$0q^5jmLHf#>*7j`Hu&QR_g
z1f5|g6c%l?w9E3%U))x^Q}QC@gYALi1h#b@|0}Q;O8mHeZKvd=F8;rf2HVX6NFPTM
zc<Jl3#cn4y*_R_eZI%2<dnPR}!7qV*;gx*j$?VG;l2^b_rz3R6Y21*!8sRCAiC5(2
zYw_)5Ti*l}Zt;J;^CvCvP8jEP_?gGaV1Y5-8wlHopMvpjD#Fetf&j+z<6<xwBe1;L
zKQImU7g^X!@>WL&>x=h`YdQ6Hz$8w3E&<MixWdJea%VkBow5x|Uqn)qWPS2Zg(uzr
zukeUYD&rW^n4U|Z!jYC<z|y)z-}0W6mH_6-dz<g{EC3IumFe#T9^!t#dtZ(>%Y=2R
z%j83FOPQqSF?jfP?&H`nr4d~4VYvD5o)Fr?-w1aouRjPsX`rR!^JU0uwuQcAa;e>J
znS0J?*Jr!fFEK~NnR9LF-UQn_ZW1x~w|!L6N0}-4P0wdg`4zk7#}G%J!;=54y+Y=m
z{*CrS9^{WYlH?;j*FxnZ9U~{}l20NpDQ^cjbURAVkBH(~pL_;*$U}2TU-QuC4Svg$
zx?NrA%24RkZ6$<h-V0&6o<f*T?-d8w8jGbD!gPBKVY*#~FimF&({zR~T}L5Im%G5O
z>Y)w)5;kG=#7_HKyAv<%ESSCbu+B-c37(|B!b7!q9Y%H-<5^<yt7H0sN08u%Uvrs&
za*rQVJLVV_1*g}9d0qCIM>zO4o~vbJDmnr8*yD~pcH-pwpA|Xh<lATuyFq@k4SfgS
zx($6-wIR)8-*au~Yc~RZC_D=Lrp^+D8Cz4XFz0OjK=H&61D?2A@r0IhKXN=Fa!&J$
zz&>yz;1}<BvYR@Oc$ryyzWAx)i=PF2@pHu&y6%7B_+pLvj{GU?rcRHJo|YV!vK^VA
z2tSWaUc<g4pKQSimZg11*O*q&cl=86!><E=_>JNRt%F?S_+gFuj(m1I@I#@9y{WTA
zVa7y8<cq0*zm~%lrtkQj;)&k}Jn;v`6I$>7qvHwbJ2bxtY>oPkd_i>J7f;;Y)Op0q
z%-ZwCwTdtP9Pq_o6kq7N|EuGRt5>c!lw4YvKPfo9&T%<C$jVb$tA1qSOmm$^<Te3Z
zxaiK=^e<2>?n#!9YdKQGowxXR#UIxN{P7RPA9~FCPsblWz0vSTq2Lv^igH!-URQ|$
zMPqGLjpbJ>Sfnt6={=tLCRN07%i$8!xBOf2$bSMJxnA*zwxj&l@rd*-ntud#<&B1a
zJfSQca8u_QFH<)JpHz;>Y#P1z);5iGaL0IIJ^cBsU0)MXHC(^3tkFtIU(+F#wH74#
zq>Ea9d0*2#uH{G(*VpW%_+w+hA3H1l&^FLr9Dl4`Uz5+W2!J?$6pCVrRwOq%By^)<
zk-`k7G9;gqB92=Qmzch0H^n2n2RyQe;t_3^-_!Ak$QR8&0$aPjCSMrB2yy=L#Igjv
zsq>7NsT+b%_Evmyvw%<bQGB9#VPD55w7K&x5#2xCLdDVc)%{!?;VnIW4q;mV31OOF
zLzuSPg)luX3t?KP3Sm0m0%N{khY3TS@7osS`=Ac_4q-aqAx!5xgz0>TFrDuZrt=-b
zbiM_~e4hs$L+ASr1^GU*L%u_p&UXmY`3_+^-yuxrJA~<chcKOQ4f_D@2OvM22XndS
zs(De~F-m@p!CnJCVg6#Uy?~GT3t_y^c?#<#Tr|jYyAF(V8EiixEt_3gOE}uC7%rsi
zs3082APg7Mcyths{RhK^^p3l5F`AwS`uW7@(6BIV4GYuLFs}d5_0d%IL71+O5T@(n
z$p?{2ODE&$`VbiFgM82WSeGQ}x=OBRk^8;VwYM94lY66FWbGxxJh=~RMi5ztISFB8
z?Tze_CH(M1k;u-K<P-&$y|ILUkNg7oeGPnLpCKRocz3LsA{<F!?T_V8x;H5|*CKKK
z&N{5uU|T)|IAjf{`Nljd<ACH82g4nSbrB3l*liVzZm#jv=`96ru1V5x^00Q3SGAiw
zsomr~?Ph<Y-IT-H&HQP%X+x?!&QoyajrC{cS*4HbKQ2WXNZoBk+Ee(+dJg9G3WPBa
z>iMCh4G;0Kj)_O&P6u&WZeLJwx4F11L#Z>aQ=oejk%DG%OMQr2>OkC52jZ4G5VzEU
zxH(U*@k^ZuoO5Fu&bblomO7L0w1;Xq?O)n0bt>UGrqytcVYFN7T*6Z?(Qx4bfeR0a
zTX;a+!UN(K9-y1@sS5Nn2sG<>>E5P*GuYW^b9J^m)JX{YEM&jjts24}fj;4p>=z>O
zhT%U_06PgdPr)x1?{kQAWkI}y5a-~6c>hM;{!@^@|3K#amvSdU=a=ArRRQdK!1w(C
zr|`dC8=1+8-sIV+OOboz)62o!tb<;BXLV3Xp36GNBlx&}kx5;O#**U0YP{zooW#%S
zDT^<#te*0)te*0)te*0)te*0)te*0)te*0)te*0)te*0)te*0)te!HM)B(%1s19E3
z>Ojg+mv0Eu<r~6u`GzoEz9CGPZwS-n8^Uz?hA>^eAxxKV2-D>o!gTp&Fnb0B@AzUL
z!}Blx0eK_qUdivt#`Vb+hJS6?9<=LDVc)63@@}n8Vc)I7{-lJ4_adzD1N(~WaHav<
zn5D6jydUs`ur9TNb*b24hBctg7SDU2y9YPbiq9FiM-xkGE9{Rxh&X50XJ%(E+%~(k
zaL1YYw${R2z0tZouhN{KnQqNYY@2PixIXR7LG3es%(2xAhHGOZxND_<-0X`#)$F}5
z*wZ|<4L7ybapxB9Gn`snILcnol5MsR;Nyo>j~xfvJGuN+lGb!<8?QFBYh9VAjpDa3
zfjgZIcI;hc-ZoZHl*vbsH@9k#*ad+QaAdmuAD1-F^U64Ev}OS`@7S7I+IB|?&jih;
z+cO6{1i%Wt!n90g?t$D~yZv6sPqI&M@?p@1la#jeE=P7_k{H+g@$3!ye-vRlq?kMu
z<=va~RX%2L5g*s77gBLlHO#SDb=V!<7pHvHY@Oel=8|WenP6ACaCPL|?DSOQ!ilAs
zb7y8BHj_A>>lhYH*GgEAm84_1r74utLCFS`$R!8aTuw}E>mM4PBK@bkZ<Ow-sC#g}
z;p<PJOgdq;4BaUN5TYLTcKP0f+ctS&9C#u5Oj;HXo0@6P;_n>ONT$P5Kz!Tw3c_uD
z*o?H#3T}Fi;%dy!w=Bq%Rc}$a>DD>*#)WfRS*R}Ebwy!K$zQwuF(|Jd*H%7_@=~0m
zTWT%WGSZ@mHj51Ew+V$44Weqx_ju5--qqP>KtsF~Y;DD17SFO|kG*)Nlk6dNX07}u
zLDT2)GmqM<!7&<Pc3+4c_kRIy_Q8~^S)88ai!S~Q_=fG8@oZtRvD>!(S@`*FJu61m
z=U)5nnp}x6=d>0lE^5usT4`tfzXX4rwllYc8)PRh#NW31!nwf9GFb=ta24S4c=AEj
z$WdLE$q`W*f5Mq3Z<&}d;>3QU__)ut7x%(ieGuxP8OweJwCsjbBaHe#<uqY*Qx1xo
z>GXgvz6YQ@>ymgnm!n*FN6T;Q&yd?{{i9P8Q=<v?L-ZzJHF<Y_wPD;nihjckJe=P^
zzw!IJ4mUh#{H`PM4&Rc)_YD<p$>F=@%~d#u@0Kc!CE%m{0{a~LEyTyYrxPZ1kzb@3
zB_=vF?F{_A2kBGBL+(|WLiVVZnsywnTipQ}pX%!vGk*tk=43AE3}`;9jJ~4Y)-a3L
z_t=oCuVfqhKImW@ld_?Wg+G>!ruS-u6W!>C_~wsok@0_kpLuX*!jIjz>?_#=x*qpE
z^Vi1s=}_<z`{(bPaJGH@1mA35xX*T?b>32adcn#D-_Ecu`KiOrGC_q^e&*av+iQ0_
zP$rsg?$zXvbc@`{Y!~a2U%K?qD66B!bgMqIG-nS-ib?`6gp=N;J^vbMh;8a?_@-Tk
zb{5tT?JP1TVYuIr9wkF1FW10d>fpEdHgPs2NfxIkdAn(gSw1uS&bs9H#Ea){s5|b-
z`W@UCt0v+R&+Hj_io3B9F1&A8(<J3fnplRFq*D2lON;4wb(%{Ax{2Szcp;<=WA(P(
zr6FaP<rRC0QP+I#guGhaNd!Qq7x#%asq|vOmGMVU@)Czj>&$;OWnxatis;O>P`a$C
z&RnI+jJgt?+4iZOb>_c=e!m~p<#Ti<GhmbWBjkwa(AO2!t3-EgHdg|9Ip)V;MZ0{6
z45Mv?za`XTD#Jj}zd*xs<^7J()2;08B8^mbOI}45QzsI=h<eZUQqGXY|8?IYbN^%9
zR^}#m$je-jt380p<F&!=>nKOB==pt0&)52KFVa*ZMQcvgHPMgF=-2MoWFKb7i^#Q-
zpE8dmeI5IwEL=~r!IjetWCit3;tBQ6bqM3Pm%QG&9${j7=T7kNq<3y~>9el9dh$yz
z-+~kz&BwC?^oVRzc7T|?(=u%r(4p$iZ=ZTp+}K*5&sC-bUnMiZalTBm^<`z+CX|z;
zrtJW`f_}e_B$TB|WY}&+<t@Qo`%rcOljD2^_z_GUIJ%dqOT?@^VLxc<mpa29pr5*g
z^i_24$vi2ZH!$c18LTJO4W$3?L!9FNA0)Z{e=md!`+w=@_h!28@p#vxK5E7CLJ0qI
zd@~1p9N%nm;~lCr+RgT>-7-Fs@OXQ087~Q({fUmxZ*j{QX&;j>V?9a7Nc(C(H>SC{
z_H$#JTWCKwM%qvL$r$OD+Rx$JU;8<Hx6*!UjC5=GZ$iz)Y&`8UUDjvaqg3D3Ew5L}
z>ZN?1?`sP1XI%~Pl7HC`9%%B83X1fD2N;;`2RGq69D7(EO)9q)96;mo=n83DuI{lT
za->_`qdbkYe2*P>GKyu)zU~kyA2se1UE^R?#<z=<vFI9y3XXy@UI~4oyT|&nP0|A>
z-Tg(%rhORbDelWcZeLsVoW&i}%{QT}(q^da*@uJnPW>3$HtpF*6qR|3)Y>}2+;-8A
znYPWo<|^plcCAFu-WAY$B+}#>5bEQUnQWJLgrDfK*8>*9?+iF`QNNWjFm*AFm*=VQ
zN4!;scfjCv>A?E^VmFUt(nU+Y#)P+YahyQ^lrDrHG4ZptF6a(17PmG?S-)cQ(35ON
z*yEx9(eB0m0^EZ+opTnq!lojAl>`>U3#PU$ZS!HAW5U@*?!b|2w{vf8FOF6@3OMDV
zEz67+7n@VF6ZVXP&6~rs3Oa6L%kSjqus3c6duxmEuhk;tErna6wv6WsYka(TmHKiq
zEob#HbRgmFgHV~?d?$G9Xw)(H&i=3KyKr&#idgDKRON*klRc7owq1?Av)teMzphhn
z@$^l-9=*)0ZQZdCI0!P?Jm?qJNFGNP_#4$Wx@La`^0)~98aK{-vIXs_R33MYX_@kP
zjpS{f+z$O~p;+qJPK%Pb5mjkn#-z>W^H9Ja%c<4vYb0;;#CE7tPek3+>(R^1+SVQA
zEp0L!UGEDWoqIM{*msufrp)*CvQa9&r>a2et~`~sYN#vP{2k9-y2~nGSgWxc5Bf02
za@2)6e&hbj8%JFi3NB%hXute_d;QgbbbLH^GTnCWk-Tx#u_x62f2mh5Q)}FMx38US
zj&!yEx1av}`t(#YI~Oyp-F#uKl5Ac(d7LL%8eqKdU9mjwkkDFpzxkw#ss)3e!VIo)
zEw7<G&gZ{#9ebinf)@3&9gyFs>eb8CTGwTKJ#N8HgVy{!R`$<dXbkw`FdGa8YHi%-
z)oNg-f%;ib-^s8`ay=mDQ%}M7!O+*X_Sp5K+-E^I?D<BQ`w;emiCx}&BPMmcw_@*=
z_?vI%|5`*AfAj79_f~k!H~jT{F75APOXdC%*_UC*4wdAApi|cVaGrr-<epU<rZ;&o
z{N<c#=E3Z7M1DR2I}h#f*;r(KG7$@laIvs;gq1V<iI=$e=I_!d{+*IW5J&cOnK;pO
zc1l`^BWLdGbmD1jNX`kuOB$T-$me52GKKI`hTL<l%h}Fr^d{#bjMM|eNIh71CD~@+
zZr>)j#JYR;{Sx+jl4d;HUxd3%i`LsN%}kxQ)SB4Zs?SZ#EzTb`F;VB#2QF20qCu{7
zn`qCsT5dCdy{=6bx&|o5@0Z~ir-S%nSg;jl-0<#s$b;}GzwLTUJNL5yx2&BYY#u+}
z*|NwtKhb{ZFLxQ7k8iHgl)0ma!JUhb`<XAu;+y-XK8f<mg+n?Qxo~o?(-PdhNcTeb
zemLH2f22XyhCUMCDXrMoD6|s42Lqi#$KLL~wTm6zN8z2LCs;GGE7tdB>3}Hk8J~Q-
zEFYwmWyJDkxGKUE$K&t|*Q5yk5Jnt??FRaZ<B5pd6&)l_(};GP#mm;bT-MXO_nsKV
zJOX$v`vff3Etg{ayC+t-UIILFp8@X+;Ck9e!_Td!Ss`+Z=P|(3Y%SIsTN8u#v2fQH
zGdI(j#~d#XS~qtWJRa_;1$zd&TeFkUPw3k;IXgS;XnX?vu}00rdy@U0s5hJQt%Ze&
z*|trO{to{{eWp3VHElW!?^9r1p(N*IjnI=3XJVq+o?e`2EY8kPG^S@4mgWt8Jx?*P
z^IMHAt?4ZQG7ja(UP-(1RKVon{V#0TD=a+TN3$yOLwLQiPm*lFkNb#!zR6PgJS+Fu
zT-D>G)ATI1KC#4jYp$GLFE?CN>#hEg`apebxW74CZTAmOw%X0cWUDnaRvQ}~2rhdp
z4UG$H2I`|j&1P$o`{UStE<;&T&RrIzv4IP$7w4B6Mi7U@jW(+wWT@F1oUBy`MjM0G
zYJaO*Z?+oEc5QSZxFNJOv`3tw?HQnrvTWt$*K7<`2S-LnTchpT@bF-}H8zP`Rr{-x
zZQKFc-|qMC`z#IZk$CO)Gcfnhb>dhBfc<61U2sqA**k3!by=Tpl3(rqv<!B)`odHL
z<!;xOXZ|PEP1F;)`H%5fFVAxIBK`8y;eIB5&%y6#wHNQ%a8De6&y%+tcmIido_zc%
z6DJ;b#&IW}Ms4rR!3Y3dU3$OboeoTrJLAWm<hj7Z=P5y+PHWZY8(UAt&drnRix4h4
zPZoCK)V8U`(`UC#&9~T!r&<e=_lheQKV0klsYVv2*9(J^uz^pRLpd>@>)ige7pQ!m
zcHFV2-u;A$Q|=RFGxJ9-QI0F;oBrltZESF`UTY2x*V_ZNp^<^w;N)n%TC0v$n*#$r
z-;{<9_=ffSBIKvI-8EZicC!~!{mHeu_8{Bb$WWs>(j1{k7_5#Bx2uDL%~5Fc!#-)F
zWuZON9PhmZwCz~CtJjBcwQhg^U<<|9sy7GvN1N@z!7(<${*jTO-Ia#+h_vnFWv=|B
zeY_a%m*V$w{6rRO{(c4g`Al}uL9qvNpx-UYnP_dBTfA@rl5*)Bvl*8y>I~c0bPNa9
zTRGp24A!fycK>Lth3c#gwQ9A2;r7T_e|u<Ptks?j_^vc`P;O7@GVgjC%ggJ`>;yXf
zsf#cw_f>BlYJ7{+wYBGjikj-%uR@)$4X{1D8sF3f9~z~xU~F5TKWEA8Tc4g<SQJx&
zQ04(?lHsQMq4rQ?babqSTDo?7ywB^<_F51GqXV^8yVV+O)vNXPWEFQuH(KaXhuY0*
z&>feC_NvFVz1O*NV41ug-)x6cJ}j%1^Hy~b{eGi9GBi2Ts13B6!y_ZLVO$v9ZnWB?
zBQ3iP|BO`gC=2ZoZ|w)9UGLd_6WpZz&3H>azs2QA+9>P&wfH3%3%!+ZJkq9L1NR&8
zdmDZ-j(R)3B`(u@1AZKby_0V|c^Evkt`Db{3-568IDR87c0c3>GZuRn-0a=ojW_f0
zUc6Z!E3bok9VI<5JW{KV)WABm$)RRrWVBJ8Y_>=G(b|3CT^c%92bDgSuN}j>HH&ad
zndq|q5d8TtUmw6X>xbbEh9ArIgM_Pb9?R!)__2KA?WUuyIELHG$C~{EL!<S6^hve)
zz`$gEpf-lf<?B$#0$s5*w3l(CFMSNOv2K{3kGpT?=VVwMV)-GA_Mw!Aps!zm{i=Lc
zUcbX*WBq7j=<}cw*IUj0$&tavWUXCC-PVVOg8D5D?PW9Drz>|$eggSqem{e^)F1gZ
ztLNV2vw-o@WntQks#~$^2wsLIo~&%(2-;AVMkV=zOM|p94(ow9uEKYQBWt75zCQx^
zC-M6ne$u{~CrMwo)33mv4`F`2!LyLIp5&`49?#6u^yq!Bez|2h`<*@H3gBUw54-p0
z-TO=K{SEj27T&uUyFn#+AHKa_DC?rk82zJwo1LYQ{j>#q3hv3)Ia4!eW8!Y%6bpWT
znz-iX=rph^;nw5*FT#CsL1KGh?EPiHWo&P44?W4(;n%ugj)Tvs_QXsJYWYGPmST?8
z*={hhXiv>AEK-*iKa97h>+ljc)+h^2J>LYraL*5Ug5x;yC;Rq2l0z%sfm@#aicZKW
z$cr7Yd%$SlE<BX-X@uWLG4}Z`XrcX=b<1_>KY*JwGamW4y>fjd-LnD<gHQ05ye>j|
zuSS|Fy+~X7L(=mjz{FM-hRbAmj|u1cU^BM2-<7_fx%`NI@5gX6&p*YR_<!#3OFR69
z^JkwY=`uX+1;4`2JVCo7jXxm_{qe6|7~*Ce!9klf^Y|MF58G~r19%*Mp^0N)saN9s
z9dRJ7KRR55(FUKDVTObG?t$~S2+Mr@0q-2HiXWcge(%C>$D4U!IZ9p*2AuT%6+hiq
z=JEC<Tg*6{Y1(^K|AaWi|7Z99JKhp6qrWG45p3;z2>S#!t;N!lG8VZ@x{At}vNJ7X
z^m(r^XK7?SKpaxu*MlbEmwz}q|Ly1$T1<VbwnaMsg)nLT0N;P%<|Fyb(ub$3W4Yt{
z8iW-&C3jq32ftJ=EwzYQS;e-EmG?BRP4OHc%FxP@8E(0+m35GncSaA(lytH@s1IyN
z4((ls`0}iSq%$)V|3mv7%X0&0%E~iqcZOd;e|LP4<(u)yBUzbbJP5upb}7mfQ<rFK
zI&JAsH@N=qTBPp@KD&<6^k;tqO!s~Ngj@H0bW7j&AL3DcUk~!E`@UYdgTBwoUemAQ
z6ehrhr=;)O1%5?+A9*|M`{<|pKDu?^w>$8KeV>$3T9#;UQby#j-4I7)3HgvVzdrbx
z$F&RgKkPI25Ptx>>@%0u|BxQ0PkM$cJg226p}tQ$G55F6;fn|-%;st9M|fr+v5-B{
zQoarUyrrZ&s{-5U_YvRCiD(-_cL-4DoNM_daOgUx-(N^?eX&k`hHf-&j|VB+8g*=t
zpIW?-VMxn*gn`Wivme&Yen9iy&VXlSV0E)y;Rj>>Y@@zt&I=Pfz%sEoJ2A5~J&h?&
zhV3!<X;c9SCX!~$#4~9*nDZhk>Ri;(QMywzQ;SpeX}RIn$~?+_@TkDjtS}z?Mer-k
ziZI>)Km8bfzXTHxF3aM#3E_Aa8{JieISe=#CYl%G{61s9Mt*wsL>@zamwtmbYQy`8
zOP;zJ!m^*<mv20@Lmdb%+sC=-S6wm3=qVh{F5TIoa&#&kK+db-ocR)Hq+H}LA1CYI
z)3pQ}*Cn?^{-nRZIlkG(_jB+4@s>7c`&=sz_}yv$uFj!0s+r{-`9`OM7@OBsQGNEL
zsmA>5!fbnS^X4;8JrRHNl(+K>n>U|;(ZO`<^rK2cm~Eq*H=owpR>whk^R3g3hZy4=
zn(_Mu@Now)fyX7;aS$<{rU-js5g^-}d4MVFo%?Qscgk}p%iF@u=Wol*_ZG~hPEDf#
zPP=fXaU#@+Gp81}VsdA3X<>&8BZ6|J1>?vpE+Fz4$Gw#6qGRoaG7;G*I@Yb>CpuQ?
zJeZRoF&*n5g`0hC+}@tnZI0hk{xJ6T)K#28$Z4@B9D=mDkC-+D(b;YXKY6;-*~)WI
ziPLpi1vVVk$DyD}`hCii15+A%liRy*33n-YSmf#*025oy+gv_H77^#+j0-t?q{8tM
zlm&65atYtmK_p(5Huhw@cmmTnpXbIQl0NJH&Ir$QL8u?ZbOD~Lcm%@uec`T24SuRy
zL;cw?(VgH=8QG6FWgz#f58_)MIfr3KWuWANGM%zrkN*ddURGAv4-U7~1!XhKW;6WK
zvVl$~<t=#G-VOq8hCSGYHF?0D1xLZnhr0C3P&YC@KN|kR6B5VN=gvLJYhBq(y)fP}
z4v&nVScba-?_J@~G91U7bTh2rrGH8{z9p{k*UJ&sqyhS4;dJ_UXZql^;~X71nCeFb
zmf^&hDv~FI6Y~J!Sot0<Pbawdz3?W^j{`@BQ|HI#Tk6Zpw;HRmd|2)bCuMMo!_7KO
zaVx$358!v6VYmt5L^o!AiA)#Wa)^G?7aD!8H@OS^MD9{HQU|>o{Mfx%eG_?y`|el=
z!?R1NA07`kg?z)T>*-1E3HPz-x}KioM7ZzKT0GV+$2p}fc<6tsUGH=3Ow$WNy|(9M
zz%R}SG=BGmU#QcuoKJ#3`N-4{%IZFF^O64KShyu$(x2QLej+1F=Xa4;>YB0s<TQm_
z`jb7NJD%!j_%7^8eaY(fC(?JE?$TghyX!m3bE^A}($GQQVf)ggG6b0=PgExEz}z+E
z64xe(T)IEXK+6xp9w6o7=y*!>+@Rt*(K;VA%wtd9a^i6(V^CyOMx)7wp55t*;3Kwa
z(ny-6O>=F)6LyHkw4o>x1HUdQ6j?|bAH;Hm41KUGPx2ks$5LFW$Jv=4)>z=+aogm=
zL}M;o6w<~Tr+RB}cwn?TJc>!($&rB(tQ2dGHb(lZ&FY9huUHxyd^a*YIW$xq7@&;H
z(HxQO4-uY#tPEv)npY*;$!BLHj__F%-&S5*U0?!k7DU~>8+ae!WbXs<O}eOGOyc`~
zGc>{_+hx4QGi<L$`L+P#S*gMk#7{l|`IU1F4qMDU9ps14t3jO`Rt@~R<O9;gwndsQ
z-XY#R2}e_3p!ia`yQC%4ch)6aL6fwbbMY;8KP}}I)bAAh)A~hTW?Z;fUCja}btQer
zS?~+{jyC+H?<iec)uHd0Q@Gi8u$)=<=fPi|?(1HatEqS8?y{U^oFe>5-ju#(UeVND
zUsGN(y00k>9rQKWgJJX>X=@pe^d^g-mHf*#OF7GO#oS8ee3ggp%k{YPu|GxeuX1-;
zuB7GTXz!PT|3n9;E^!g)A^&oWMOkx!p>JLCE;rAw_5O#uuvLV$dB#V;>w?GfPKL*{
z5$KCqJcMw4Bjwx&K%2<9M<X4U8PmSVAhLLvhsP3zkegBV98*yTJ>8x0MOk+-;F)f?
zYjO$P(CqFxV|EOlQJ-FFrR|kzJ_c~}I9jqg%+h2y(!)NS<E_U_97OEC4#Vzx$NTUn
zf)192$fA#cPSSsn$xtPE^r5zHpMr2{-74K)<QDVyB<2bI>{DIdaxm4Ou^u)tZIp@T
z9VWXUv_Rn<)+@uYUi0|!W0=bjmi^h&-TT>i3l9ih+2g};Df7v>Qt}-4@9<69o`rbq
zGx*KC$v64Re%p0F&xc#e?uF*N()V1vS*95uY)GC5KhpmKywkEmm>0v%NAkwJK7)Sf
z!(ZfJf=B2Vnf?U8Lz(^@_=!v}UDwn>roT+#rc7r!yaImAm(<;*_!hbPO2FjlPOg?y
zr{!vC=s>PYoxBQkv1~8L`)vG-Y*PHoywIO~NM7R_ACV!icmBD$0gt~1Fg`Ju=w*VN
z<s{*V{|zp#l3ixb{LS!Z9EP#&!s=)*hd+7xjqd#>6VCD<*YpT(=Hqqvu?@bJZ#)7c
z&bK+(6%Ho#c%-5)#i8124o3ic7w~Pu&+si|xh@+IhIE9d#TNAr#ADvxjrXBA|BqFZ
zwoAxUwnxsX@NL>DzNK7Ax8QlN!}C78^YmtNLfR5%a6X{IX7nSWtWPoZ(lX&}UA)t!
z^B(v9Fy2yUx*Rinfu0WfGnh`x${dl09|YdB@iX;_e0~hye3%ybGEK|j`!wN-uUQ6F
zcrmRQj5Zy@Y@H#X%d?Ib!mh-8Gw0YIfp}W(?6vRC$)n&Wa%XDh{MmDHw^9S^V5g5x
z%)I8~6r59=%~m^w6X(+u&P~`oxalxVvM~OpBMv{zEP33NUUdcVk=Dx{VzB85>pYS(
zr<sGBYO+`p+>|&xcsS<+cTS$E=n;Cc3kn-6xIgIVgnGeCR2ZRIhaugsjnJKiS$*PZ
z%X+_}t8|PB*-bh>qv-s9+<ga}T}Ac(-M5>tApss$#6n1@p}pOG+X9jeDI}0a3RQW$
za$mA!ci*xl1r-qmK_gX^B8aG{h=QotP_X<gV8MdDHxwJe^0WK@erM*~d+vSr?cF5!
z$Nzu!^LFmcoH=u5=FB<M$I5dnKRye8*7+x42QmWu_C>g9q%8%!LQlsll>NJVo0`Ai
zU>U@D60=|9nI1<++F7_CKy>H3L9^yzo<IBq{Dg;7_l!=UJHMoGv#do&epQvz<aA^@
z6<SB8LdSIEd(fVz?dN&lLH~#OzZdkmarn-!L%KEp2V!MF9()jf7w>WcmY+WbT;cpI
z_H@D>&fhkBpMx8HcC!bD>4yFJX7BTGFC9fc9y^vu*TWVzHn(g28_n%fK5#C^4XDt@
z_VFHpn`Y_Im_IU99FR2kK%3<lqt)ABR(T7yO*VZQ@Qu!8e#L}E&t)3f4?VsOt&Ho-
z`(l3f>n_c-`Pp4Ab~4($Lmir(T}ExZzO2WSk0DRY>ulK6ht%2ZBXHm7H{mBTiQ(VE
z&)Yq^-ox`Qwhz~2a7cgddw`|hB<}CxTXZdPGtLi)i^j<}rpvyFG4NwN!ZDuoFTamC
z^38J;b+n-${}YE-^2GWRIO6*;!_jB^X#i(s^UvWHxG=9x-s28V!U7zzewpOU;8$~k
z+$%xQ?*I>Be&+07n)GZx=NHcJSI&L{w$LwqkKe*CpbL4@`6NvO$20;s)kl$fkUC-g
z=(61oH}jZt@t=Y_-pBbp{DS<0hCdJnhVf>>X1eisq62=2u(%HR4g5q0q@MelKnMIu
z;ie8Sbp;s^mP4qML_hp5;)t1?en_WK>xWe6n0{Do_7^sLzXn~h?)J27&v1Lbeithv
z%Hk*Cck$DjnAI1=D|4bu=Z|nN9p#E3o|kp>{26}G8Fu%HsoRX1AHeQ4vmu3YJCx<4
z*sxN7{%A5Zi_BMPH2nqm;_G}IWAdDq$fUmmhCKgg$nzQ4fA}}J#Z0u`_W#Si8IfTu
zlYdCwo&5csU8kX_Ql{~G*V9raYPwlARVA=v-#P_1x#`nBM_%JCHk5}f2Q35bnY>K)
z-;PgYZu@SO5y!=panw_^Db1UY4Rr=_d2my=G|`69<!!=Px~{zI!@_a1?5~>wJe22C
zoxK}up<CoQdD?zkJ+?bwh<h6BfF`tn>2TACJpLEr#pQ7;U_>6LpR8=WzC8nY1h?*!
z@8M`59g~x}=~QT$n+hG1xhzYb;~@`7ebBuZ>4XmdhP?>LlsWetX*jy~j=>2I@=u0g
zk-n0h&$s-R$vzG~knjBg>*~<(9_5wv(Y^*64nR0*eO3r(=1QIocU_vG`ylw!NEp`<
z_M=}W;~nV2h>vt`18+#5>Ul}{z|YSQ@Y%l1zHpN-pX2O<VGBOygXtauzn~oG2R9Aj
zcm`OPWdNu8D?&SAXEScBK3EolBZpw(IGk`X9BiwN!Z=O{(+>Lxr#f9c6ZjJ3(WJ*~
zN^Hp+Qr;}!)NO<M@lg2fk{*sEWOXocD*fmk0e4&n9|^ym(ZR%>q=S!we_RJsuTa;{
zL715TxUP+qhaF5M)Z>3duY6_)_2`a{71c_jsLWuTsKO?xCL50t&)LCzn6$Y>c82+C
zta#D?qYO9}{2=m=-&zhG4>$X6l*N>VA`1w29DdZXIokXLt~Pv&ETCM{aI!uiIEb^u
z#f|IYFdmQudfJZB+7XAi^Um&qO&X~Oq<_iyBL8~v9pJ+}y{5MZVTts{WEayT{u2Oi
zOh6OPGDCK0{Bj289Jj`OjETejc+FlnzHR+j*)SLGm<(z<5q=k2AkJYnodkEhEi=E=
zCCo4RV>h(xd4Quyn-kel{^$c<T}DjzWS5rI&40SBC5Vxrt*NkGZfoS>g)YA=V}1)y
zEyg!_3jRjtp8_{ws26qHV4OwxQBN+R4I_AM+sb5@!e5suaV&GNQl^s5Y4Dde6W~U>
zTjAiPf5N-{*ndfamA0qnlvWv7+on#%H+g)evrmUDH0wNH1l=z9gT4%CSqFHUy0BP3
zdoAFCJfJN~9vCkYh7y&slRo$vj<z$M{ao0x4tAFFI~z9XCeKRyXTHKT;c#tN%J+qU
z6}m&X==#;CP(ML_LECwVLu2Bh{fF`3>F{5U_Rl`W0>DZem;I~fz)$-3sn=1M@i)%X
zn?5k^Y;tb)MO%3WwK(7x%)v7&Q_ffEvCn^%l@HA&_>0NnWx@&WUP~uQclJ}EBb|Mt
zbJ&*1|567$C$G!0LRu4Ka4;qS&-pGtjF$sA>mVr}*Zh*|N5?bmH6gtq9t$oe^Mf$(
zvB-Rr2Y?22M)=>hwe_HrJUQs>ENt>Db*FA?HMsALtyQdn-;VZElzcROU#_K{3p~P;
z<Pq}ei{Q7z>l6{>7Eb|q^cqDGZoNiPg<IArn5L{3kcJI#>otmg3tP8FLH~)?D7c?c
zuTfk8cpB*|OPb-l)`rL$#YVt4TB8^+VbL`T*88>K;h^3jBZgg?LrxBK!YySka$pF4
zA_r2hFiemGEVB`XSK2$zlaIReneWz#+k1M_y1l1DN83C523)hb(9x6DKiMVzwnL2n
zNZ(*b`{AZ(n0~nVO6`YlLitc8hC15bXG__@ux;Qek(XQH7Folv&G@k|ei3aLjf1*B
z30C?9qC;PdxRgsTg)M1{4t*K?f^;D7BpspWc-JrB7@ly(sPjmYelS-9T3_zq7$)&d
zJ`&C(1@V+TCEe4J(51jbx?c%f`U<abewR6W9}{Np9SZV6B4aW=DU4;oae|Zu(+c6j
zeu9+6t6f^uJ0V;wEsZ0lcX-cWkYCjKHsGT%Wr)5;fK%xmkufg-Y+S~?3Vwl%NxQJI
zfsDCY;ngzcT1Ok{YsIO%XX;+bU%0Urb+VkBB2UR&gPfbX7~!^ET3vNXEML@(m%~q=
znYsdQ(HC6zxDxJApJCr8+@Zc}@?Hx!^jl14S^q{l3v#^aD#W|k5@*JJ*T5Yg_fZD%
zeA4v@qe+vcJ0^qdxJK5YIc|-QQOx`w+U^Z5eQDR>+#rZ@Z3^unOB^zOx(VO54cUIs
z8{lSJy3yH(!In03Grk2kal9Tsj;G#88-{I?V<_U2IJdz~f5LBrKjZU$zkoLQy~)Lw
z_OcxAczd}8e$rl2FIjBRUf!(mvb_k6x5J<Paq8zg@GWM-wv$eT*3PNW5$%jQpt^EK
z{l3M~mJ}v>LuBo(fMq?t&DnRtmU<AG`40F6^$5A8@khc?M^eY4m)_~{-UYjk9wj@e
z^UNLK&aWOel+`8-vNWU#83_0`lO?ZOU2NZSz5-)wp8eMG?gfk<qlD>ay!Sd<a{yr)
zaaiJ^en?7x*Usyh*_~ZF??BpwZqx2m8JqmOJee?jOS$QJh*#l!gf1(KCmbh*{S)l#
zL;1wVId6yGj`jmp&VzBzyMRa9w~TY{hTjg4b0WyC?syOIgmS;xy9e%2FEo4i!7bw)
zrWxvxX7BxQ>v7HpENo0?G<)=Kq%*h|>wbjman1+frkU(G=R<&RG|u^m35$+%q%Z$~
zOD9eL>{1=Z`tqs@c6pvJXsawNwEM+4pMtZI>|H8jFFdK@_VsE%=2*teH6rHlNn%J}
zpLY>tdm}vZhJYPtj^T9&zAO;KE-MK(Fcw9g8HvR)Hy+!${D)94ZeAtJZ|YuYmy}_%
zk-ISO8Shhop{)KSY^_WG2X1NW#PbRKIKKD{ZGIvS{i$a~w|x%oq&S~<agxIBgAAmh
zF2NZu@3VlVE_vA5k0jw#@<`|qJ@X~N2lPVE2)#@@9wu~A&oJ#TyEGq7OtW5hgy|r%
z(j6?zpx*=?L%6Twr*#GCp^R-5M%|Evzpe~{L((>3E<ICUYJ6}r=8-5b9t0hhjqQC}
z^yB))2FH{<4#stgF90r)1sid#+e`FC#EZQ*lEUuxo`SC+UR+Lp6@JCwE`nz7Yj9VB
zy9%1U$KYP?_PR3Na&WIfv-b_S<L{5qPtwruk9^bOiM%Jmc@_GP*gFmyzB$6OLrK}<
zLtA4%{#%IGNTz<<ghgd4WyZeVrp$K`CI<IxMcy4rDMTwN6QfKlGvrM3qj)=o{TrSg
zrA-;ZvnL+znfe~+5;*<VlgJVShg~E;0G#kO`OFybVAx-@Yh_^=AY8jS3F9~6MRNt5
z;iu`|kANqv*XiDm;YOX~OoKU;$OmR{D)Fi9l;1pG_!CJNsO9d0n6#WweqTO;{N`>r
zzc5%FDz5i=E&SZMm2q=N8ok#K)JnyH6NAGV_DF_E^E$x3Rg2~?>a!IV#|t&G{mu#K
z(D&0cytJ<0ZN`>+)pq)3{f3B))}j3U8Oq%1oJ{uT!FQAKm$Bb3;cxYeh0%KB351DU
zWBkYQ<5=(4v|&WQ{0eS-n>6%#8`J-Vi}TwcPA2<1e2ZS7P6^<^86lh<^F9e!=H&+P
zzR*dU138ZPnzpB0I;8s#_$KZ@(hvMT1U*Ybd@~^*Gz}q+=-t`>>u{KSC>-_W65fYh
zpEeS8?TKMgoMG53=sT9jpOGf*zdHNx&i)7N`gEgrUB~nM4RddxjTcQ9d$&{=(+kTW
zq)Enl|8_KZ$KjqPN9S*x-=CcQ7ia&?+5d8O6XFQnL0zLPd(FF0VOWrUtRF#tsjG9K
z7egE&oy0#C=>#~yOTwo()4o6Jdp5v<di(v5Y1AXX2i`gXP%kOW8q9XUijLxVWiPx?
z^H2DRoa6jd2I(7j0XK{e^y4~7doN@Q{N3e@yk61Z+YNq|;?R13q&7ZkUd^)7rZ_TE
z+zR}>7iSt^ps{QcZayHMN8xv=r&h#aT~3EhnK>Q%4|X?rh>Q78mTmt@naTFXHZN_K
z=O$TCdkS5uZEz21Scf3kg-QPQa{0@`7M=>>!#isk#`;c5M{w=qaP6CjD@>cXc(+^<
zE{0LhHll(3kRS{^FYA%3ck!;(X3%VFa#yvE9Wze>z8$%HwW0RG`AW8h8Ne59FBxxd
z`00CC_k&yC1<ZOV%cZ2Q-?~5i^gXPsciq=Kz_^3QdQ97T7W|@j&oz6*lXMR&{TtoG
zYQofob!?OWE%&e<NV*Hr{wn(>ykGU%2otkI_p44&sk$SpIWGCO)rN>n-(=GSV|tC7
z2V~8`wYt8N>MBky0=jN?K9z0tIYIe^_b!So3B$sB5!3EEd@k@s`E9!QJoqWr+0Hz(
zAN>3v?XVv_xh(8lo+*1DLceDQ^r6v%$Uo)c4Cukd(1Uw`s&T_Cc!O;Ljw`RBilY9(
zo?FQ27R;Pgi{k@h40Ha6AP-Z$Wq9A~<gK`#IGD%y2V^yWb4*^n%q*4H{czv#a6cZ(
zv)QoUsFh$mgSTU61D^CA23zR84){p#Owh}*2<fupnsTjz_h8ZG$9=`k-qpxsi#J#r
zA25j+`i}sftT(cLgnAaV&vkSisp!gK{oUaKyE*crUWRw>nry${9RYW**G{f#Wi(PR
z(DBAa(yLkx8%EIgpTjaV`*<>0es4qlOMm?sxP{*tb~JwM*B?t8hJAVZ%NXH!e6#;0
z@pEt|#cy-*<xGf-U8y_k;hVh<2QTwr0$&fC@j4wWc`IQaFOj$E@q~S4@>w@<lF#bl
zPzbKyA${HB0Ly+=yR-Ao?s9gIv**ID!x!t%vTRwNJZFcz5Unzkd0zlc5^rvnx_V31
zu6%c;z1m%^<|>u0Y8zhU#FJ8%p@OxtG-xb5b$4|X@$y`7@7oJNW564rRd|DWi-(2v
zZpSb4Tv_zNW;ve(oBVfOVt%2O2TSGQK-kCcxGPmUi(R>%_Kxm+drw!ct<>%3JF6u;
zpw(V#EBZaryrx3O@=E#^fWBR;kM4HRhc~@))iQ{x_Ow^<_ETr6!^d-9c)_(Ar7;yc
zfkw7LY0ryXd9p6}wm0i(F@DB4zLhq3GW-|fcM5)l=R8qZuZZE`g=h8KOG_P2=`SyV
zo6LHu!^Q6qSAE|*nJ&vC%N?#2u%!;jBO(iUkJqZibfPp<wj`xPy<!>`&S;<R@KA3g
z(Mx$p9u4L$bQ!5WJLx<Fa59b|e#ScsKVw{3o|DkGzYqYNdYa5T3MT+xy(*ALq;^oV
zxPJ7Bz?sy)-#K+<=Z5D4XS|QU41T(gzY=cU$7g+)V}1P9@Y8+#Q;9>(C$BN?Xdiza
z{GxrXW{-H1`uOy3)W<hrs-wm}KJ^e{$a@NPZznW*Yk_U+>3nP9Owt|e<BL2c53*0f
z{{A_D6O-8A-?>U|*yZ23K8c;rqdXE>!?trSX~+82i(DS+!ZHYt$*3S6`YiD~qt62#
zw#$OE&xb8#Mj3x|q7HH|!UT`jZ0;YZl<}G~-T^2S2HNM&6;;~P)mE(H9nqd@S65rP
zr@O1#(^J9Yj`{B1&YrR#dkHiZ8iHP4CPn|2d8dpjyRty1%=C%jW%5AT!#qeo%!ga#
zCC8=nFh@!pCHMzr1o*1Mw~Ki%ww3*SnfJ}M=iAz<m3()u%(p~4dfW2V&Rpyv(NySY
z-sQ~g*`QTqitNQL!cQt7z30>T%<Tq+n{#+l-u<q8ba~4i2p0rllRb}{P9YoCr1MkP
z7ih{-|5H~5V<+gi_3$H~55m^^iLf>NjB)LVaP+tR33p}&ZfScAyO43vE=Op?)P<>b
zDLhEIDLlwF7~oOubizI_FFD3t$Gobk{;uQhaxdg`cPWpzY}@geeS5i5>g0=}Xn<Yq
z-JP*MRvL7K{m2WpUowjPlJ+rYZ-TAMc^q!`7dFF|@zF*2w(ZiEt9-LA_$_O6tr$<U
z@BCu??ssc>d{2sN6E&1wkPb$&7XwDx`AhN5@_z~JpiF`H<#5wT+Zl#C-gdUYPk1f0
z-)YA8$@j5es&KRINc(t&qk(ix?!0<B6}o+-LdV+2g#0z(9blE7&fbn<dv~P`cRQAI
z?IphhZ$@_&+q&_LdA^*F@>eQ!jK4Vda)aCFfvPiY*Sxifx_>w7o^A4Sl%<pJ*~{>4
z`OCJ?E8r%~l@3PQW4IQAyIc`QBmBlSW3Csx20!69J9pCJy%v6?={iSKlcCA(sUx3q
zt(oav4LH&y;|bwm;uHS7*5GQ*n&l+OqHCPnrq%3S2X_*^*TbKN>97q^9<dDwp5~c0
z9`Uffy}`h@c=x$`d>M~pH!H_7+226EiR_a&#81wYIK(ga@6wMrZUGMFku<VBz87U;
zOl;hKE7Jm;$UC0<x($B1-4ZA9ux=k|faeZ}N6LhGxEVj*J@97QFbsPuzJq)#S{SDD
z$9q`g`4d0p?;XHn>9%_ZbQt>$+mI*1-R0nj|Lz89OWyG~nD;KgP!^JYk%gpJ*Fjj8
z8Sgy^qhVV2I5>VY4r$Qkai4>gzMt^g`{2(w)HTPbIK*);<3MM9z{O>~aC}Va-r@R2
zl<fhm(qV#=bjW!3gTO=h55tyx-;eK);3ssG2BD2|oq6~e>>v$<e;jTaske|XGTs9&
zOzyJ032rUJc{k)6;U_X&?uIO@yDV>4;c_pegmazqPK9&wcUjtv67C|)x{EC*y36wI
ziXNdCD;1HuEZ?bMgk}vxy5F5ZcL+1#U6wmVJlCy0s_07ZaoDx92Nj*78+i}qC*Ut8
zxQFr??BfWZQckjMkhj@3J_R~OzKhO?>I?KQ57KfD?@}WU^#??tnV*LUGUrE!;bt3>
z_QJJ=UIS}&3+2Y=;b!}xE)$t=bw$Q|7=COgTnE;&;}Q7Nh;Cy)^A7xYwwm%gkipm&
z^<{^HIH^a!VB&^%cnfW8%cMoxC1I@zVWrGgIXISCAg>{7zV6}>2gm=qZGTmTMdB&B
z!+5;QJfJf{&I?^~-!^HK{_0~$gSfxx?6<*|y1W^>DE}<z7N_SZb46zI{^^O*49gzx
zav~m$l*RYpCf%G@49Ws^{=)z+WBM<mmzfTE;ySF~uwB0&ZY|@uukkzZ6B(B}hwJ*O
z@pISI#W+tnJ~Dz$V1+>}TJ@K(KxL0$yLqr5skGTvrL1msWkp-^`4hl$&Kh?(H2)Oe
zVzQiNdIsmLg<nHnYxaKT=wlf9fo1+<`hiD(?!tucrOnjAD!ycUqMYCzm%l=M(TTsr
zH}OAV{F=;uCAMku8Ev*}rmgiN`=3Iy=BwYrpN3(-!*@V4c;)vlO!VSc;MP1tz4$fw
z3D1b05xvJfi)nW}e@o$<yk4wRg_FMH`P&KfhWc#scRYVTf$k8`gnDtOh^JosjiNnu
z?1Og2cD`NFsrBMh@D~&4#b<DACNhBffP73__*J*DKRUYEHgYBd_8f4~R_JGRYxDjs
z7(>m56K%ze^|=4c7#DseY=*--c)y5aD;axDg?!dJ?e9oi+AsAQ+otG3>TKB`{3Wc1
z1o1F`_)o+WdB*k`gh5aK%jJ`FgzXYL?vFQ=2Kf2rB*%mQaCU$LO1~Mff}iCkWyx^`
zf6;t2ds6|=vSpfK+2YM(m!`!3IQsXZzu3<h20Y`mpuBc*9<y96`klp`--VgF-X1^4
z0e`NeoG<(3o@#eKHjkMK9U17GJqBLgd6n{{_817yg>}*FO>^bKGMIsHmcf%K1C)7o
zI^1?1uz7#hKf`94uuOI@gvmH82Y<rujUQuFpyOzmo`hMSFpPC<$H~@D>gA@xQLj!{
zQr7RsbbwQ659<_ru1tEC=a`P9&3Ff@c+bXnKwqr?qv<;^MmzHxmQ}`ky~~%-F7Pb7
z4d6w>=Q6gR`aG9DVVQ=&lD3(OwnHYMjrhX+X1p6+`ozKfNdJf5?EgqRISg)=S2N->
z>`?rurw^wMQx~T6vgqL>0L%DC!j|-`&b4)~_3zPuA<j9lgY-bpF>urHE<eiaec+Dk
z*nQzQk&Zn;h08cjbTDxqq;Q(E9SIL9aIkii(HYac=O}!l(?i{6b>zVcM$*(UOm|jN
zx*<@gByHkm&*D)EZ)&r5I__AN4s{%56UTnX!Cwq+#Mv^8gCd3W^`-P=_2g(ObW}D`
zX7ocw%Un$kG>VL%PGMM^p<Ayz+4;wPG0tLJA<q#*2jIw4ha*l9FV=PiCu1C_*0P9)
zVd6*r?Itb2OPoFUPQpnz`b)dww{BM_ARckgVLQaU>dCOBEfIDu!r9JFqzzLSme9^l
z0xa`954NPww#9T#cj>$geNBe3JaxNU05{W^4?9R7aTmf(Q+4gG9qxF$+X#9mYIiJm
z370mY+g+!^*`RN`sn%baImf+RVjV}}{^)657vc);Ms1LFBruYG*t||M?-=wZ&=A6e
zO)!xVjMv!j>{IEaE-AV;xk#m}+vH;Si`juTnVzg}lc~_rHYsm^ah~$^=(};h_)X59
z1!7H`GkwRY-V)F+eL%v^1P?Hrb0u86<QgE|Y+H1n3V6}moG;}s(m!l%_LeK0oWHmb
zF^PlU#IX|LyV~C>=kvwhu4*pt=Q?^jI&-<McKr2r<a)buy`|W~N;wTWT7EjeQx9M}
zY|5SvnnlK~!MDgb>UoB(#g7nIvVdXOMkUPpgki)l{UE|i`Lldj&N}_GfR}RMOr{C^
z3?p7ii(%)wFsAuJd<XQzWT&QweG{Qo=n+5SEX2~&VMUc*sX=<gK{`aP@>|PQA8wJA
z46EQrIa;L+Qx}#XN7n<Ea&!Z1Nzcm4OqO+|<>p4XiSq*3L3${I0k~=S4ghuhI=JI<
z^9=ZjToTzOa*=Za=csUzTM|y3FH$%g^;g^=`Y3x(|1|GBg;UZD<(%!aoUdRcT@Ayu
z%Sma6K%u}42(U7;U*S$|K2Amss<gC>9D=`?9gvaf$!Zyy3LS0ZY|~}PHfhttpi$a1
z+aSX(G<1jk7V-~uWDpi>UlNabm3|1n8IQUxDIWQj{?bnPt=q|F#FMtbuuY^1?PQCg
zEg>wSooodx+sQ?+B|T{;%(reQFNK@wy##iU9!lwAxM`$+F#>nIom4>IMC~N4e=(|X
z?r8sF3~}RWhiq=!%Vhc&;|Vl`c*5o~QUBt_ik8&vTCVN9Or@*a&L!{{vjc4>Jz3p$
zQlX=5N9Kq)momq#1#pgwe8V;nj-Ok+OC9|ZhvR(4k@5b;n7_|JPI+F*U*A7e7~3#{
zGazQ4WMR051CLt^<3k&VYMY0=?SyM;3^!C8@;$<28pDj#WD6#bq@X`2G>2pE7Vnjg
z=2N}hNLhw?x(t4eDCF^zGxLo?`}&xU<o|HwpJm0ls77UWMXbyihh;WVoL9%<9P85I
z+=@;|=W|;^9Hui-oU2?M%8|dIy;F8b|AqW;4Z>Nb@wK*VRlL8scy|SLKYw_5m8tAA
zas5gS2VB-K$L!WXVFjzy)q5kDbwmA|{E^Y(fUEmPa0>>Cqoe)hh5qQqvDz@}guK%1
zrNFP+U}%s$l5ekfd5o{k-Qe=L7<_{{MZ-6*gI|LbEZZ~)1lMf8puT+8n&z=|sDG><
zPrF@I9P6(Qt;IbawxnF1n!*$t!UrgP6#444-Z`Kds>9HHqo%nLh8XpYz?hHo>hrN?
zLv8ayf0I8z9kQ^$xPGWMI@Vvd*|6<AD40gD^k26W@>A1(v!=a4%oynnplrM4J~+~&
zYH`&_t?ZAEuJuO-`-e;oEceGY)GCEVTl&Xbpy5ST4-Ml87GENw4t0LssPoeZODsc;
zz*rae+r7%DYHjSv0J(t3FAf)m$41=kF9T?gHFxQWS@v{?1%mTp)e#?u=1lXo``P9l
znut#>C#gf&Cm~5F&FM3H-_dO-3)@e!^G7$qO*uq=_L(@2c@@6dtGnHVS-3Z=?_2Oq
z`NSG!yf@*;{?uD&^Ar6-`rA41*6gR}(6`BZEBp{<?hbkbzM0nNT-ZBISSEWXY~7c-
z3+}qKuy6HU@TU=c=Kzm<-<lK$^u61~VY&}O29c)s7+AZ<^lkWNp6+(`J+P&0NE7L}
z4}L+OF_$HI{)s*R#^}npGh@7frIBiro$QUm3&SI9-(&s$C|PvfB;fkywauG1iKP4b
z&YnN9);;SSY=qC1dV2Hu9$OEQ{G&|5dcYlkD4QAZlezHsxpMq~DMwrH_v5>+K4W75
zEVp^@2b?uc-iO>b;~j_j&anIek+o3uIK%q>b6VY0M2ezgQ>~2*8iC}RqtwqtF!4H?
zBy7B%CW<C?H8D)IzR0_5PcklIyJh{btT>Osa{M^UR+YcBp$FklIM&6-2xCl>_X+o{
z>!Kb<#?%wj`b=8cgT1K<3O?rHtpJn~uMdfr^Mnxb(ya%UGEEAJmZa_Dej0gC;yso#
zWsa0>L@u)2G>>9_D#Q`qJ0a!%S>WN_j@*0mUVJBNft}JSc244hz$s%+j*&RO@nQJI
z?jYM0^<{8=6gc%+u?OJRcat$qcUPF1lYR*9`2Az_6I%8CW1oV*+++3``(1Yz8U54l
zBBLxp37dW_%Ax6Vh|}mEvd^0^jA9r10}HWZQpP=OAOC|eYnr@=-8cIPdwbQ)BS9FO
z+0$2>9D4pI`Uu}iYp)ns*wIB{&<ro4Z8kYH-fmN&;%zrMg0$a8q474%cFKMS+o`m-
zFT*Wz?n^;k;jE$i23+<S@Co}egk#?*&`r?)j~gDc{e-U~Oy<AX=LzIy1kUQguLD-b
zL%hF>YXHPg*^$`~`!n$4TG=-o9qhBndcrs1N4h9;?A)8h`5m~4gMFKTCxPR;4hQo;
z2jfQOU()_Q!k9Mk%i6*Z93J+~f-+HgAgt{pf=0-;i_pL494`GVJA`*7vQJPP9@e~K
z1JOs{8@C{REh)Sv(-xeO<-JVPy^m-(_NQz@K|YQ~zPPW2{je4<+x!#2iwX8J{eRLA
z({=Sz<dbgO$F}uBx0P+yE%if~c>S<XFj4(HmK2^)KcCca3H2lUj-=g@KK9F4SHDDD
zF_F5OsIw!zgo$9{a%YmTap^NrG?76Q!$c(!>&LWZ?%_n<>9zxhChrO7w&N39f6`Xj
zJ|k@v@qZ6^sb9v4*DqznMD_c<r0|6L{ep&5^~?Sp>u@{5#YF0`zH=otS056uuL&XI
zwNwu*b(0hlt&#A~U(QoPjF>vHV^cUF<5))wgLL-(fV@hX6DD5f)G-s4`Hzyq6UzK6
z8cvltbu`QT&j=S2Df487DCM3U8ZY})sCfA&N02&b6k1;o?wlEP6wd|;?^Awo4`$GI
zP!E4a{w17s#`@9q^mi4`w!^i2hKrv2rwZr!vMZb(lzRTR3g@}8PsYNVa#%}3UDWR@
zJimyE^sR%qLh#t3;-Eh|TrB%X%$@5GZR#JX4e>72g1x-}=W4?{vKt5Y&6}Uw(pIYC
zID4)KQ&3M$c;BhaLCGDsAvH56M@{k+ltb6IZqjsuQuaAoP)=^n$$ZOt;Z*n^gL)R7
zup8Xc2V$Hl_;FsTl{P;eu5BvL?hWEhcX5*NZ838{Ov~P5Jq@swzcZY@M-tA+7}@5D
zv=cuE(*eEcCkeetVL}(@NU)>V+uNnNPhy%)-e5qhJ;xHJgUDI@U|23JOX+)(zX^8$
zetK+Adg#?Cj69x%zpf0KXqNw6eYx~ZeIfsHm*Q73jx~1_BhmOB+N3dlhxVR;i;j?X
zfrCx|vf0}UIAdemT|jEb(E9?Xj7wz<y&wGa_;!D|_4xN$a6^Qfu`X!}?`UrJ4um^C
z_NAYsp~t?@ws`8syYx>R?^?MRy?gs0#A`I>eU1r>j(K^PA@AOPF2cmb$F;jqz)8c}
zosv7k>&-$Z_%hy>!Z73{YjY#_YO}1&=);Xuo)0`>olW-+hMOuG`%18gR0;0Ymiq)}
zO1ePX<b@LWKcx>sy=U`DH}xIIkRQSxbh>Sy)8;kMgHEowJHRHjrZIrSr<-<u1;a$2
z?0UuFC`XyU<hPdnN5U<#iD5_JM}2V=ZI~U&Q*aOY=!V+J*iL8e6n86N!&MlL+exeF
zz+>=jbzmlYG`^jlG`itfxGCG|&wSVA73(0!BaB9LXwJoX8^%|n52)LS<2b^ieA>e}
z2DhF==y35nVOzTF+(I|pb?F0Fm%}AtK{}wVCkV6aD|6r`Ep5*3h0Xl&tg5bKo$iT%
zA?_Ez4(b>@Ep=QMhH{cJsiO(>o&-EJvPLlvZqn4}(&2ZQ4jfthVB}n9-oejx_Iwxb
z?I`c0cv64N6X{tD_@IoC52*{GHN+8?Epd=fq(1R!(pt(7)i0^Tk2IwYB)_L14)b^#
zY{CoOaa>H3VKWrpg>(Z!7C#u`SOHui-SAXlhd_=tiWezsB2)1g7RC$fjdYPWr7XDL
zHcUJ0dyp=G860c*5i2L5D;{>Kn|nV2aiV<@nG#Qze%v2@GUAK=mOjD)_{I7nlSk_M
zGmC&j_bZmbt@|BJL(i+93U|D3K|i5Q_brygU-~Gk>~~#1gZ^p#4Dt<1FPK+fjW~_^
z80$<}w2#3$X8n-&D8o6Aeiq=w#QPhQFT|wog^S&{Zqj;*ymdC{3HcM0Wi53Ki|{VJ
zby%c5g#7yI9oSPaP#apm(;Dj3G!2D2gj^d~h&(2@fgRA6;9ItbWxypoC+%S+{2H`}
z9Z0~gVVw?Kx?QY+Tel0QrQ5|BaL3yP{e(u{F3yC%w2O1?cU`-ne_FdBPwRH^Ld0p*
zE?#89>f6P6@TcsPc2R&^Orv(O1BE$J1DQnMCX*$7+t6;MKT?8Q+62SSC%w?aW!n5i
ze~A9lAM)`{T`BRaaM#60-(r0j-}IIKFe?EL>GV4|(ccxg**-To`vTaMH>82-GOYo8
z2ed**3$1lwfEPMMzYaRQL$K@Uj_II%zz<<MAS%leNs1TdgS4`YME~K_;27mc1N`wY
z;$Yg8ucUDk;!cVV5|`yaM`MKkP?lZn<i|$fO_m?263obq8sbZP6qzv$zXmcR6)D%c
zFGPGTCr04ba)S7^oEU>UE+^<GbZI#;4u6poo9%a<oS=W2oM7E(Ik5$C8p(;RCM+r^
zs7t6bFG84@MzSHb&?b@ylh7s7j*r3FDe~O|n9~*BWjoYsoiB0pN}QL%Ep14{y)1;w
za-1Ww<K^%tZi#<sgZQrq;~Uw*{tCy#q=(opLpa@b9=OR{2iY>wJ@Yc(D*X`4^8@9=
zSpT5C<z%O|wNus_SNh1A<$Og@7WP}q<X5Y5A>5VtQ6|5JHa{Vg=`ZE_T6}And==bM
zFF}0B<g0`DxU-C72UQo>CdEOT*SR<%pSQuydbq~f*Ta_lh<v^QenGmB&q6n8ii9Bt
zLX*hn*E_s#fL)gdB|n*_$pdf@?&e6EATZ04O2QH5i8xqx!teMrbl=Jkm6paI4<iny
zEwcJ{e1~}lo-BSab$Owu4ueby<At*NHYclJ2fWF$dI!1L_4jTBK9P|kyKjPD1KGWU
ziP%2hEx@N``5WQZvYhE@S$-Sbaam43p;OE9H^E<I`J3%`oh+w+nk;ACX<2>;+>K=U
zTTEC~mQ(IfmcP~DAuh7c(^69tN%ozVJ9o$0{hgp&cvH*px4Zn1zh8nlTE4s!VSzkG
z`@Rcq!flPg-5rB_w}ZPV26s;k?p_D?${5^zF}U|RxQk<OABe%-@7#}OZT+y_k=~cb
z;(a(4?<2<Dy#JQ~Kbui;H4pE^=!cG^`x0~aXBgh%?#TED;3-pN?ejt4kvAxf4#U2H
zhu}vVcsC4X2g~!_pojCp*W(U<iA%Z6x2GA7PlRW@Pn)=Q-jDnn)CKT-#<>l>Sc8@O
z=eA`T*}COy^C#g)9U5JiZT21p4uO$y!ZIDJbMc-kU|1HM8)RA#UpNDiwAO0d!e|+-
zxPn#HVtFGs-WSG->*Z#Cvz)n3cFQF};yD+$R{3S5EApCUN%y1pQ9sJMA=e1lm;4I+
zCzCqg!EtLZW=@3pz^inbuM)2_(x#KB+tGaJ`g$Ac_KXSU7UJne(h7DM#-YOUdJK7R
zdOpi<=`(y2-?~kc_edA_OA_ka2$z1^x9}}8f;hf`AK$(CE^Qc{9~Upnda-F)KK%jQ
zbvRIGKXf=m|9=l|*6WX8vwbi<(#g0#!FP~8{3QK4yh?YIw#T!EOrvj!lX=(e^9Ixb
zVTgx(z%+h=pY8*McrxDO2qP>(l3)!z4v#4-v}sv$<r|8eZ}~AIC-Y`l!{p(g0#5Xw
z=;@!q&*|xS#fOpIeB>_yD|+$?g-dj)dbc5%5BxRY;_oMrM_ZxieuFSEjoL&=gjQj3
zQZ0|NT&=9K@1Pi7LfKJPT?g4X3+GXGgNyP9-F%O4AW{Z#u0~`N<5;=0oA)H>lXHj$
z9`OV|glqAh0vzSng}}x1!7|(Dpl(80FnZAnYz^T)V*33N@VFy!!~9Zd#NXs?Utwf~
zm-!R?#o!GK^TzQ&tz5+G>UIYS1YK#sH%CJnh8o#s+sTxf(f0Jez%R0xyvaPt{wJH~
zX78`DygZ4#i2k757n~M8<NYHBk0K53b0j?BqH&tNe<Kd_T)&s5VXh{V=WJ7($caog
zgKz3W$!{~<q~%$M+cJ^-w!mLtPC<c;qg+mf9o8@IO9Kq+mpEC!S=_U#-NR0IOE^Hx
zJ*=~kPtu@yh-Gfpn_-7(w0JXsTV&+9PJU8$F-Lov^zGfP)A3ClVcd+DHQ}vU`V;<%
zy%}!dSqFko>TF-YOP(2r{!tj*8|H8#3oy+d%SorX#oR?3_E+{Ze9~&xkxUe%%Q6~<
zgJqU6;h`J*VYYu2Z}ix+g2mzf!r*8D8^;Re+K3rP`({8r&{n`7_CVP)j&ZnZKiURh
z+6(OtCWGC0QCy}4xuc&JR`4}X3|lLW)&_jsU1}1@*>klmb#dH|!!dKxbd<oL$DC)J
zQU~jrv4P1Mn5p$JTZhUUB5CfH05i(dOOhSP6_!tH9UKaDWXzJ}=$}>xv&BAoJJ1fg
zEls;?n2|A4BST~3qy7kM2qyvrqf2+Xh9C8D`D_2!*23u4(J_CpIzCk9p<7olIXOo>
z1NU*^epp-Q4tWJ<bZhHNwJkCHdnCYGLP$E0$Kdz$ij_@ZgN}AvXM1@Y@r0#6AnvR;
zG*%g~=b!i1v<DkGN5+Rj_G=fK_wiT;z~b_~uZOMf<KRH-2`SeQ1w5$r0C|1|&IzM!
zWX913o`*KnV0TD>$R14%oMtm19(O5Md-CPJK5zREnx)OmAMqE1{pSz&kIrAQW+{je
zx|+NNwZY-yh`(lR1V_UcZBbzvZ_&{B;2Kjm%ZzRrjf6LQr}$&@QDvKW(3y1|;%#Br
zLOkfc*qob-#GAsfMMKn2m9y6HG5E!Pacmq<N)dtO&#8o2RvdNsSJj5c@#I{^w1eGD
zm?3B>I6H#7m0_#w*)dBL6JWiEv`r(7&DL7X#H||f%l)JN{81JWJtUpo2}h5FJWOZU
zI#jWHZqt?zHFubY83MDibOEkYC#~)b;h6+7?QjpmL<?bgadcx4zNZ(SCSQQI(hn8C
z2FQ@3NWS;-mX4mm9Y;|@Od45l*@ET8VO_(<e{c9NUAVRujbh7xA20L;1mMDa?Q6ou
z{0P|$cD%lyw;U(;itGK8Yg^_k|NWJ}DFFw6fVa99<}ys@S@6dV1acrhsFwr7Gx#Vx
zSJ`sd8wKNzjDsMXmuE-d8=a;P(>*8x-{1(l%GYxu@RsX>YZgES<?VC5HQ*&9_rZ|m
zji-zk@yzKMPIrgp_B_ur<zgoXa~)j_HFfoTPoyKfoCH}7d4VB>kry)?%L^6JN(|*u
zCo?FM?uI_59=_4(VeX}%`$@RNJ4Mha{L!(sBjfm28(zkvvZmu|%e={J5WZ-ODUXZ}
zUsxL~_7Aar)Q7G1p;Icnhk??-W1i*yheMI)Wozaa7Oz~rXwBNf+STjufAyjTD_1Wp
ztUY_xBAeTZARr~dgSWZ<H|G@a62#d)Ue0CTo9>Lad3kMUYy;uMuf^NEu()+)^-SO2
zsQsrJe=mS*^)@f5jfc2)2d@61aXi5r;+o-YMsuzWkyi!(o`f41fJ|b*sMn7EFUAR(
z!;xPx=<}~Rd(GNK%hxVlZZf(~xsk2o68p?c&Rn`;&D!~eg6Sg%F2HkqdL;0(56X9U
z6Z+dj1EahQ1PzS+34@^!^>cXUI6RyWVV-PXvbuC=gAWO2%ZGj~UUjt(5xU8*nDU+l
zzgDlZdGSDT{V2-gWYB?rZRQx2?-?E@aMrC^w0h;qr!HEscJZ?Lr>rrg)O&-Pr?x*4
zsavv9SU(wW0WQSBq0N)gAlHsyFaFY@ioeCsaw*RhAUq;*T^&uuz$NQBxdSn|adcTf
zSku%W^Dq;7b8KYm0;A>~-_ZY1=vp*+bQfwvHqh2N!;bW9u7wAVNv3T{|N0F9Zyx8Z
zq2^w<X30w2GV;{+)hMrND6ivGdEtG*)oYg(7OY;ncIkro%L;2yXiHbFC@frb^14%O
z9X1X}36d}Vma}|8o<d(d^Bu?sF)d!eMRh#IF~Cd%nDI`;{n*6S?s!AS9F#3QQ%+br
z2bA&hfFW$BgC+kb@Z*I1&$X&<#Fu%e9*0ZD^&IQ4+<W2AZy9ItI~=?0=FLSoX*t2g
zKL}%`DTqh9$-}gXXBO-*-W2ZzF5XEl9&zN4u;nOYx4qohjnhV?biRvovWp{Q!LQ;h
z5$7NHW8W}L2d{m*IE!4IIiL?bVDdz|m><$9`8yhLq&Yg4M~}$iS>o`J-o;p(r95DI
zN5S71;A7Zn4o=2~i{Y=!foX6oxZL4g;ox<>^GrK&OTDjhu%|oNNdAGJd5PzLjf=B3
z7KgM*p82iI><ky@Oc#gwIUBUtyxOra>E{_>P2V{#-nlB?VSC$nLMv(1Y3p>)bMY}q
zjikl0n;qdFj7%MD$-xT#9Nfgu`Xh}Rf5pZ55EK{l!hHEIzLa|vZvGfA2OMb5-UbuT
z&I6Ix7)F~sd4UPbWH-VlPJRC=>4>+Vke;dDpo?qhF>AiqUxK{adErcU$l+|nv%<TY
zXPKup$h@6LmHD@6-iS+U%;60403wkl<82DU!aC-?BZL(m+~V+TjloL25|;U9xxLuI
zzQn=4+UXh_UfH~2*_tz~!erNG4R1vYbVLjETo@kuQ~zN|(Ldx@T--2h2ErCqtL*)6
z@|RkjIk+FQw|>08vH%^i+Mq<D4u_n|TnyU8%=BXVx`7VA&8`bT^=ji|Ea(R6g@GDp
z8gV(tmcmdCj*W7LP_7BY^Qz^pQl$;Ak5=-z99{zVtA44s*jdf_Z8)tKeVi{98h7N$
zz!rT_&T~_yT@vIidWM5-WDYvU$KVGgZt9;od3|EOCi8xKzNcEw7xAoMSFTjbb+)xv
zI!bLF7-#qPcC`1DVowmHLPxS=?_YWaXx@hQm3()vqcLGP9xwQ=az~|D&K2|3j%sh&
zua=9wrBWXE^t88EdrRHj(SlEfj!?=rbQ$P826XOxS>}rE)%J3470l4(m)c9Yo>H~g
zRjqclRXRG_%CUDrQ=uai+Om9=D@)N$uY~(@{I0-Hc;_6P**q6N>ZmK>Pb2wbJ&3&I
zyXLP!cp%rX4!R9)_Agjx(!aP0-;_ya4F<Rvb~S#+K>pAWKmD!zv+|a-={VOi4)?#f
zxOHI}ggbooVfF7TUk^NN$ggwu4X}j{)+4`3yZyE_-3T{vzX3MsH8cVCCVbP#`=!^w
zEo(&b_V4TACqf{#9hm-f^82MXE8JXvBEL<=yH2+_8c4_F-Y-q3f~!T7rn!#anzH0K
z;e%W8t@(gqw+YRP59qJ?KzNgN#jx8M2Ym2m7gy>!2ut9DFsz;r?f@R*ev7l;3Y&G$
zIKl^{UGu@);byvb!VYjFr|*E9M)=@OaL4)JZSa#aO>M&y@WDG3Zp{aGIT}dE<oF<+
z3e5+p&~<#^#z|^#+ufj%a)bJa`zziJn`KTJYU@6eC5$ffd*PP4Cfq&van1X^v|%WB
zsP}~5-iL4Dx9Rw1*!%I*dXI64OXA#*Z;3-a%CHYI4vms6qGJs{#FlfCp)9m{qFe4<
zCk*rWQKo@7%!}Y5dfs)e@i3nFG2X{rJV`@`J*04c0^iAb&6x6$@+HhRq=_;xdpbW2
zx0El#K7}9K+5gansS8u>O!f+V2C!^PpM_1DiO1GqCd>NJ_4zQ|#QAyHL3*I)5x8j<
zW1k(@+dmAqZbN+6;pOm?HYE3y%iZTZKmC9T=b6-sUoA*DaehGIth@6$cv;N8A@MPV
zOVYxQv&b8u4=NZ*Ps1?HPbQ=p!tjn~l`!T;xF_Lr3U6vx5VC^ld_ko{xxhXv-*NdO
z{Keo-=l_~MEBSdfX><Kiw#kFxW}D=k>!bLdjbO}e!rhwfQn03d#oRB9xwCAy4maV)
zBjF)_fEfJiBjK&t%`x|hG53pN?tz&5{Fr-L%-y?pl)ejN;b+I(^J4C@a$jZp@obsO
zxLqw=PAUu*hp_y>`!wdxt&A53xc>{@>j!G3;=qaKe(@s#&o_C&kvNollw5652i>=-
zYyMeF`p)S~#^2Xx*YAG@`Y3Z)_I-+0)-%II_CAhpEgyafH{+b8;)o1lyr0t_^8Z(~
zVF<f)B3Ps(u#`=o#vGH#CZ;WN|9AK%{@)v1P2LdTXc%Xyi$glLJ2*oJbeO;~EQ$k>
zmF|ef3&UpNehbRZCxMstQ_lW_v;PR2d3-5s;ph6aaQ_)6Kwy$+lrWLk|Lbu7#o=D5
za0hw;c_uE>6qGyi`**^^NV&{F`I5fH3J2r;6Yek`BDk_3>^cR@w$AcpTW4GR2<8kZ
z&wdS<I^Ju*sf7P6;6-0h{_TZTkw3u?w+@VReSvcIuj0lyeHhohbMBpS{{jDSRn7YS
z8-A7I(0YFam(vv1;|2rUWQrpr#jU`{{aQ`!ED3j|0c1DxwgB;@p6K3B$sxAW>E7X)
zjETp%1Wj&7|2Ntx={q$>Z-;WTjwy$2JGOH~t)QJh#=YC*E#pmdZuV=)#fQK@hztH;
zn?D42*yd&4ZV%$w$KoQs3(TChm+5qTLQK4?sf;}sqyC1%daMstuyGahEE5Q<aPw*`
zN+7kk2144+d@SCO+|$u++?d09-z?H@`$o*W(93WHnK?%CYM6iQlZxPI@%DvV#@afM
zVY<!U0WQuy%qVio`!LyV*cOuJYFM792X!IybM~HDTXvTu%l}wGG-yKT>QAohNXK(Q
zyYweJ9Zfqw|B>&^Rl2)6EBTJzo_u#DU+(VcEOvC1JGy#Goz-$KIzy8Rjd4h>x2MOi
z<hmeD&0eyDLGLz{G0R`dn|CEoIJab)eE<4l2@Gg2;2DX}E#>pw9c{(#3ZCMu^t6>b
z{H|iLr@hjhZ_D+xb@z0|C{KfqP|kAR>dKbivycbst(`CDu3THO9n=;(O5J$Q%J1#$
z%ooeu?QNaqd@0vmj#8Tn9ii5?DJfgt2}+s|bLGzOb6sAfUCcz-q4*tvpYT2T>UsE4
zh8$&Vi)T)(9Bf@$dBpjsV*txE#vB~$neB*s^p8cD%+a&`@+b4?VpBemR@?WKIrOPs
z&f#r?E&T-QL&9PwlQm9WiOk^KnB-l@;h55lT`{)mba5q)l!4&xVmRP>9GvLk00&#T
zOIOZ=bpw|1=Q{g7q$lx6ufeI}kw%Vt$y4=k;e3hE_yXV{9On%KIuLgr{Aq-aUYGuf
z&OQmY%!_;oaYaYV{MZQymoZ)H?5oqe_X3Y+$1>bNXzq&Y10KOm{V#RE{IQ*LuIyyM
zh@svsQn~yW%psG%NT-zbBDhJvk9-ObEr4H8kAPk5@*-uMhg<S5Wjh~!LD{CZe%q&E
zd-6OkVQ{OB9a}C@xb>XVQbz-0Om5C8RjP0WCYXCng^tM}lwX#zUd9%u;akd&ZG&OU
zgyx{#W=tHyN%>PYNt<At6^w)SxYEUC-Snus5!?n&wXr%J7`H4m<!kHrgaC&f1FQmm
z;#%$OHL&Bds~2%7w`47sw2(&f59OZigH83$fFHwH2Aa3dcK(O$9hS|R@C)(@Jm<ho
zBfPa7?l^C)gP-tLs!n$8Hi@@hsBlZWEx2-#IqnxZdPvjc_$-|w&1b35b$o{TJk$Ys
zCe$@{Y{W9pyRzl?kjo3d&6>L5vrN{kV_Tjxx?Om-io6QXQioCRub2EQo;7<X9Ii7}
z8cW=FoNq+e3Eya5832CL_YxPEVI044j&=dogc!C$rST}%!foEI4xYES=W$$3xJ3$w
z<;9FQ;_$Bx!oqm>BOcRR;q>(;2YYe=E4tj$5|lTY0p-Co+Z`;w%^nSu3)`NQA3=>#
z<#!R%nE_rW+{O3~%Gu2s5k8LNKzceH;d@C-aGc%j86N8|^$%e8w%XTf_bN7dgs~fZ
z)wax)*z`0qGCs`hPiCKAvw>R)k3p=BV=EXo%i+z3fX5_#=5v$E^G5Z3smmANg@P<G
zZ!EnWeuX8A=C3L&U4gxU%jcUNPYagKUt_k4otbYC*oV0smceBW%7=8Y+^p=(WM_j8
zEo-D-c9NryxG3Kk=L-BNQ(sM+pTKpb%ExJq;wbql^BLQKgLtooO+0KvnvQGXX4>p;
z25F=2uY;S$<ipW^UXz`F*nluC^Em(fQuv9?lR06TU*`PtyRgqh!eu^K!a2|IGKF(y
zWYTTs9GQOOj4*?aveR(r+f4H=Nk})GL$>b?-j|TJhGF`znmGLsJWhn0m%c{Pkv{gZ
zeTVB+nw0PCi*a812KbAK+{rxp%#FD?7d3)AAZLRx?)7!!Lvoxllb^4_JZkV-JgPOg
zUZ{ZEFvq&`6VI_ODV#RZBrAFLMwFqJ!<4s_dF%%<OmxaE_-1<uWoO2_8Gh2=c_Y51
zZ8F|X_;HT)Hrg<CVZbF}#A)Sxcy2JqNYEXecO;!}1|E?SZ^1Wd(fbB3hacxxSnjhU
zd$^`}Z$lVyFb{%*dE__gdMo@%^V{)bnlc|N`xWlq+wS)Z=y2sAy6G;&W7xZ3Te_xY
z-;M8}92Cy_^pK|02MmkG3&UiN_np8?IrScA-{b6iVb|l1&gn*RhhZWE?{m1`2V3fu
zWlg+HQ|IRc@TZY{&oK2dE&D<Ehj0LJd1Jd^`LKRCNBbE!NBbuD)z8tUb3J9z?T9P#
zm2!deweN+Wp09nsxMTCR_rpIvU;82WrOnrV7%+OimhGGKu^%!13}gQOJK8tf73&QR
z(OZRgPh{TYQ{esm;l2rc9l|twA448OH{MIYJ0CjEEpRgq`GIwrG{+dmZ}uK?_z25(
zMV?`}af4sjFAUv)0j~((5he`7T?lZ?K4bP3@4=6>@cRM${^h<I$F|Geyw4%doaBAZ
zI0#rB7_)oz>^C|p<mHDEhrE0a_|u+^#J<6P94~<WvS%Q%QJ+3rZNDtzT{zy4nf;-n
z^uM5dhHz+TXno+<0#3u-DenD6-|IrZiu(w;@AeBw&&?uKhYMxC`AMqKpR!X6;>mtg
z7ibFi{xcoBkCFMs-bcSYJZAQ>^X}nR59@Vf{Wvnjv(R?W|Cf-K7@T!TEQ47=z6bpE
z#q!oL-&ngCs$c@$!x@6`?afC+`mxF}RAIjP08Jzlkr3nrWx2aIWgp6dJld^%PtS+n
zP4k}GKG)^<tA=haK-vtk48CUlun2?aPI2;&eqXnKreH2Ld2Y=-X8dffgZY~3Kn>^D
zKq-4z?p1&jE46VPo;zvo+%gXD8KihHfM**xuO0L2;{_LH>L&?R-wMfNCi@}0PfML3
zeEm((LmvGi=|Y?M7Hrar-fTwd#@Z7k@E@VIDf=DJBKrQj_$J+?Rdg|FWgB6htR8L3
zqS=`^A}4+T7`DqF!Vcm>WBtg*C0>d96?`+j<FHn;JMb_rd6)6|1_f>M_8qYA$M2^I
zAAsx%+xYI@&)}!yOFXeD9~#DQ-QD{I;vXLHJa5it)0HvTP|a|M@p{UfB}FBf@z5_3
z&(+X|qJ3GywE0T^`u?$K6HW*Z`NPN?^g|9u8F1K`ME4U&i+PCTy|vZ*wV~a{W7$bu
zv6=U}GDE!I0#?TM8a6qdsow7a5B@bg%leXj*LL`mF4h^_GQWemX`SLdg>dS9u3s^H
zCiFhte}q5Xm%uG+V?qaQ(oH<gfbp=t_GiEgoaQg)E#$El?=Nr%{0YtyzW5vbg+{T-
zSNxF<@?oTGf#vV;lYEXLe-iIPz(--Hc>e^f@IT=Q6Tf5U-xJ`A!cOs;I+!mzzajX7
za)mB$M!1wmoVF0I#hU^+-cb_jj4|vs_sf*O;@9HA5AOnNzgGHf;3>Nh4rjywS8?ms
z_WW7a_+jEf;oFaXTY1_qjC&ycHb>(=*T6;nX40>Jw8C>=vmg_B?rJyWLCm2DH_~`)
z5Dh3?2j+a#wtZ|}M(d`<o2JT2!$r%y#hVT|sY4AHmS?lKhl05heU%SD7D;*-I>X=%
zj2O%h<1nqw-rj(b`X#UY#K|;^BjfF>a7cJOo&61tR&$>_rRd4nBPjF}4}Z}-;_VBS
zuE2!(%XkMloZexGOoKcMoop){UlE=*`;^ZEyy!K?VVI5E<Q<GK>90v#))BvH^GDte
z)8EZIBq<JPFmYgW{xKeBHsVM-C0)F)YZlVr*)gG)@o@`^cbI||c|#pT`9u@aGQ~S$
z0@x@GQ@o=98<(eo_b-?Wh{8|xjs`sCAnBs~nE^SNd_Kf!7_*du?wVg5ET9u+HZa5&
zl6&&)mELMKS1I@U)wZ^BS6fHEqf{#TCBM7c(-S)akP40I>SB8rjulk$p6##UomtSm
z4ZQXljCmlvjd*6cS%WUpAg%<c4vdd(C}4+0oWNqKtF73R?<`iar?RuuUGC`V&iCg0
zVzr~It;=W6>&T-_r2O2uG6h!d?CHw&_I9@SwE0+LF8jG$XQ`v&_f$I(8<8jvg2kRx
z=t!>2`d$usVn1h>%fHf_YisW<w{=viJstUKrCh4^RN6~DJ(Xg$Ty3vJDNTirP-^<i
zn4@;(FYWwzxZCjSz)!~L$6;;gc(Xp#?B(H4v-9iyJw08OE|h9JSfMAM&$m^vp`y2n
zY_+#_mwGy)nM#F@WXi6uc7aCnlzTtq>E@{jd!%w;0)0K8kNmOoWmxU5wzn5coqna9
z>+0>PbXL21!Nj>rM->yGo$b*wOodLMajq*v;frp#d+|E~za+jm5&ks0%=6`rZitAk
z?sB!%*-`51?d&blYWK_CU8T16*tVNg=t$Na&z}TZ$sd;|%ABf^HgQSQi&JG)ztUO4
z`KMA>sWaDG!r`)NS1#9)>uE2xMN2#tIzkrvmwlk=X^|P7-R;#9+EX!CEOm5Xzfm>c
zhJTejH!YQWVlpEYIzp%`zmr}032)4Udp>>(@FQ<f2kCQL3*k@0e3JKB_R<I7+UsKY
znLYr4us7xuxH&dpJC?EIQhdwYDjPJzPQ}j{=w}+@r@tEunsWr?Tj5uREn^(4?<}Vc
zQx}H8n9MKMhlT6pvae(X@Q|LB&Rzvu=wN;Fo3z_+yMJ#D+{C>ac0dzg*TPLB>)WTn
zEpw5wcj9#Ti6Tptji$exd~R!<!mamCoZ)C79g|zrPNzbv(^TjP!%?0$Whsk<56;53
z<^zVEEi@}Wpugq=Ew>nUF5`d?Ug+XVT?b(ad=Q4!^TCUNhkS6JvkS0U_lzTaK-x7Q
zl;CE%Mc4su<g^Sojqt%aaL4)JeE10;q{{aR_@JV2Yd-KD4Wwgoe2`9s=7Ut|IzF&6
zavRD=WCzDe>p^GG$A;|K05^GtGD>*n0(@(pVc16ej8Qy8f6X%@&seVv8)O{t%#e#K
zJQIW^@Jtwnd+E(NR@S-QS5pHX;vRPPg|Nvpj3Ycl+BMIN!Oe6>VF$R8({Z?Igl7ie
zj`Pe2{Dfyx1;67Nma*sAaRU47TqD_}aFb`K^SO_0v!j7Af_c%&j5E@S(X5jS9bp}#
zvzoHh`N9ud@vZrRVHXMQiXZ5&`GI;)>YQOOVI1(oOKHQ@g(dJq5D)8^aelZMc*qYg
zbM_^$$q$Sp{6N|@KfD5Nrh6&u05@{_O1No+A6^W1oF85eKjDYej?@JFaGAob`QdU$
z1L@cyen=-q^Fu0hJwIf!9HVVRIcZsP1^jeB<Vv_HOE^Xn-gynaHSd`56a0)(yhDG@
zJ9<3Du&WpcymPgSE4&kgCGbudR?j=v01tWRT4!Geo4ms~!aJm0^Ue)$Gu_w04sau<
zuZNpPc;~fn$9d;^_zCZ%4m>B|oi`}lns;t=G?0!R;+=G2H1DKB*Yi%3nX?dnxEXY6
ze&Bq@Eke8E2l{J%;5b|AoME>z4*20V+Awut3H%VmOOPdR0v__i?aqEPZ1Mx+2tSZ^
z%@1#do9Vs<c7PlF@HV(<gdg4rcbp&YfS>R~>O{~4{BWnjt@+{Yjt0`PL;R3VjOK?_
z=z4yz{SsTZnJnjKb(!7;x}`2T#(O98f%<xv%Ma^>V<L&q^$y0DvDIUkgMAOeX$v00
zznk$h&E7q<VTgw^jd)}ppJ^w>C)|4(FVo`PM;nH6j`Rs%zaQVk#WXpdW7r2Atc;Hs
zhqOqX52`riJ%)WKAr8}*I3J0{Vc19O<Cw7=<+GGQkO#Dxk2(0dut=M+eXfrKmb5+S
z?DxTD*^v%iZ=Zmh_}X9xX@Tlb!cD_95cY*0fIHq69)h2=h1BUo*A`e;x}U{!e5^a%
zDQ>Q(qnmt?_3UIQ=4~rxQJhQen8W2gd=lqC&mS47jhOQXpHlR(J#n6O8v1IVHt8`<
z&zp%f{@<HtwPR_vw@_ze9vS%x#sgSS_>&7K4|8q&G%QkpZw)_j-a&XKXj9;)hh5p!
zg(dLQBY-78eZkrH!X`hlEogrF65PbcIkX@x@Y9#!rn$rM(}&@X^V1jMC;XH;->CQi
zFJ4D@2lw-viS&thC#!hpQAG=Rhx4he;GM5Hno0M8yUshiG@mN{H}b(>(Oy{hITD7k
z;MYKB=x*{JH@sliK)F69>tBX9z$@PXyzmCcl~VtK+y-xa%jLZ;O!0=uZmv1YTAhsf
zzK!_gm+v_HZrB08Vjb_haFc&1e>MO70B)u^A9g?w_~(ak(}-@qAMQB+d=GxYKdCd5
zj(_6vh_dcS3OD(I^QRp5{n*h!I>2N9*XK{Ayj!s5CgmO0JKo3uecHWu#BF7U=uEEf
zEk?a9!EYAw6Vwf6K^`~pEdLOWFkv|MwwdtoK73S<J=4pAf#Ww=w_A*M&UJF)##u4S
zY1|Twy-gUWihm2<ktoue*N-dzR&M|ohZx`O=U^=xe3bbu(iAhJ(M{x=aXqSEz%{_*
zZhxBgFjot=b+>o*badtVxCTz#Sc@Y^E7RbXbB&5Ed7bvC$1Qcmw!t-0?!jRh{+{^&
z|33*^>O#XvTeWa4-czQmZC%vk$#{QM;lv~HMK=6dg|jZB_kw1;znE}Um;2d$CKrOt
z*(??39(L|^dql(Un#%hote)w2c_b|P;9tNk<v`iP^=0nc3wa4On-9x@YrXt&{r7O}
zmn0lz2xsOp3Qpsa{L+tbEr63W1t0Sf;=-F43Kz?S;rzwZYy});)M227eMGK16DMJx
z1kX$T-MX)(ne{{3gZyFt%?y>6#O3<E&@={Iq<c@miHw&ue&S&qu)mi@_#Bio?^5O7
z1g__^Z4s6@2uE9f0S(?XZy&@J-0y%s;E&-m9q#=QE@dX+vj4%t;Jmzo5&EKez#a*}
zNSSCD!8Hc@nAd|eoXZPw#o?X{xCz$|2TRyJRx4~Sj~2?q@s+IZa&N^ic9-(yVt0E_
zXQjPdDRt)CiXB*0?rQIjE$XL2V?flCD|U7JMNnnu>z|J=>E9oWZ|X70KY8H=;G3E7
zm$pCV@_z{Y$XAS`#~#Et8$XuOebDhV)P-ZP8D>p1?5#*6h!;CMrQ;nK!+Cduc%+N?
zNSAzXL%yVq&q0{<2?%!-ejLvqO&g{zjM5c#Oe1^cj{$5m+{eO}G;|+;Wkx*5!w%8_
z4LP`J9(HGh4uxCy0eDvDF!)IyAnA<I?Z~%;C!G;GT;Z&{qYBrbkB-d@&XHiJ{V~>y
zdTiz#`+ZDsp_FsSV#(<f-g7d|J0gMJ@F0*qTlCHZnl%jjEJr5L9m4QHQH+dTB%b%V
z9H(ecZ9ix;q_a)Y$-WiaH_s!r!(U8r9_blu-=X}pvRC#=aZeJ@DE$y}o^qc$H-w$y
zbs`@EOL;biOo^<fuF<gFfHgV=FqD6nU@w!z75vmElppc^p>tI_gnbliE{$MMRIr2*
zeU*gwq!{c(c>4e=dILof=pg3N>aAw)WWb0_6d2}p48O1}aBp}Fmp&)UZ%T~CF<kUd
z!nH)<VmhK5HC?AFTmqAXYgr6e5?w1|xEj&5O5uWfNTh4E!X+?CbghlyN}}tG7_LTi
zouzOwt)%igN8u8fB)VQ0!<9tWc`;m#=sI8FVqYhTu9CtfFiCWAE1vKw;gaa8#&9*F
zYXjh<KgBmuDHF(B+!xBe+65{twtfDheVb-)05Ci+!m$w3@w_3vvKQ<vZZ+p#ws`gp
zPA@YAcrn>V<DX?UUW3h7Pwc}H9Hzwl%t)mNI|B3NTxVY&`jmQ{Hc;mKE<zK=VF5yp
z&q^3CWst$)NznpS`Y9hXW?B~Wj8kLpu^D4VF^6?0WK|#|;C=$`<hNBDjM-v&w<H8v
zGG!E}fc=p%<ZlN08$sHTJ>(7MA5t1cpiQH+V_BVK{?X6MZbn+{S5h}@!8iH2Z%;GM
zGPFt9MX|77wM#rZUSuEqC4gZ*a)#uL_foh;$FPseA9Wbvev0@Z>=f^1@RNPWY<tqK
z9swNFlD+?&)8qNBJ>^tK)gRhaD3&l|TP%+iw)AutM#_cJ4gJ+IbI$&NWVq2$jNLUH
z-;uNjh3fF(qW2Krfyr>h7r=#extsTL<m)2$ZVzR_rEs4(KEwuCIhI#+9@{Woq0elC
zJ2StdvC!bqj@a(yeB2hiHDk}ljh6fQ6ic<=oH5}20c>kypzku!=O`LBZ-e2&0!)W*
zwa;k=$K7IKHmwWLznV19x~EBTZq8n|hnW=L9P~RQF~qc;?lz3Cu!#}LvF*GHwA!%)
z?xDuFjE}Cw_c3tEIO5fC%UFSMSK!C>qSw%dsSD#FC&*D6jw702Zv$*I?AOAsgI8lA
zp^NDg?i#=cX~Iv^Og`^unAsk8w4cZ+&+*_~FWN+a2lDA&v?Cg}2lkJzLOO{B=la4|
zBmClI0Q8lcylW9I;~Vysx$bct{J;%p5d9;yA>JrTd5y6Ve6e0Q;^Rmqs*RIiKHv01
zpS$UL#EHLSOTO3*XK!C;@DV3vUIST{Oe5D56GP&BG0}UekP&0GEpz9V`q%SRzK;tZ
zjiglWJ~<IgNEE)=d;WUREqumr;j<g@t@-RGxP><e_XhkpUcH$%Onn$U6`zs6ZUHRq
zH^L?_5s&cFZTJrGf(HaI-<o2(K7Y@_;+FnFJXKNR**0?ycBbbKn9E?5-)P`xCq6Gl
z`^T%8=A7&8NJE!Fq_nW#KO(wxa*0wZ0?;>6IaB{|zK(ML3z+X3a(sO&=uz>^`rDh}
zr+Jn4al9FR6A{OL2Js_zc%0I{A94rcU>{zkI94?8>`wK%GH-#Om`9r$mc%6ZrYU<l
zaFJK!%n8q9avbzF_;X!F#zxc^)Nx+xRPRoNNq>+0#9yE%vHtQ7xTSA-`Yel2=6p>4
zFyDI@U}PMmVWMy?-rWwjjo0LD#lB%lo4h7zvrf47bB}{J`rYv#X(La1)9gJ3+HLWL
zYe$Svo+ce^PdY83&En2@_nWkA-$KTk#4WUZ$b>iV&v^7}oo45X#eFEow{kAo_LU2@
zYSqdq^1@8S$#{i}aObOU*Lkg9GtOJ{v6}nrT0rvy%$qaZvuW-qb#i17Q~&+L16vEF
zt%c#*W<2{^s}}IanamE34-MmSHHaEMtj7Ma_UN0}Hg8@d3^6fu_WZ(%`HSYSQw^c7
zy>BV*3^`v^BIgN7GxTq>&};4gZkpK#{W!{4`k4>noAt>%S;#ANQ~n9huWi8dp9Gw=
zv$q2Qd7ABy{YU9fl7CD)^QL;AMi}w)EH&{bzZqCqj*ca6&vrKuhzp8=aX$+jGZ0tW
z8q;|(()}F#WvzgDp_KVN{3H(=F5qcM{YL<EhwVcp)*+^-%tN*0FMLBqaW;B<tlA?S
zC$o*6y}dasKH=>f9P+?Lplzl0e7WrRl=8T?wA2>6tuz%H^U-Z3zq8Vj?~(cFFM?Ll
zgI~fo+cWhW^UJU=<3|Xt&(X*@fa6b&6$n>fPE)+EAfATZaCl?buNl}dO_PvHGb~$6
z2kYz`h{HM~t>46VK&$G*>3k3;-(iq^2u|@cJfv`bw*gMVF)iDVu;1H&SNf<wK$!Fo
z2={&b*mw9LZJ4^S3_N3fhaUl!jPqmIk{)@R->f71ZP(9!1~+m36n2mvV1EubP1VhN
zKMJ?#TAr8SJo01k6HZH-_hz|Dc+$N0w-nBBhTF|m2e&AN^T>9_+rHKCZG~IX4(Fcj
z95(A9p1y|R-0=6(Xb2<J6M}IS``kZK>7=$H+duYxq0(hPo9&%*(vQPmjNFC&-_+ju
zR*CM*@H~5?wmim+pfB?T@+9rW!#x9RuQJA;?c!4oB(-sa!`sdKt;1n;INslZz85*F
z<w%eYTELTtBQiNoV+e=!?iie=L&N<MaH3lp(M|X<<{P@@&kf*(UeOH#{};dq>0upr
zT8DB&cT9&nDSg2go$s6K{X^qJdF+AsB2zW}5<jGUiudmr?V>w5ugJQJ)85n>mNjAH
zaEwF!*W3V3XcxFCfYW)6r!VkQcDn&y_(7*1lqd2(4KO<Yahy8;(*c`u-g0w)jgJ6s
zEL3rRy1^;$?n*n(8Fy5=ay>rI;dT~t9eJFF?kM+`di~z`f!tJRD&U@;?n<Sz?D|D}
zfKKX<S10!uxcRUj4}cU31MT4{?G8WRmhWnB%j2N1j}zTJUFCdtwc4BOF8bB>YBhS`
zG8H;P6=Wjy%wC|2dgf^;!%|OIuishB`)xRnTP>G5`Mh6uZ#h@#?d@&rh#hK9g^o~b
zXx-bDq43Y1aA)z`2S4gY@|Zqzxi9=_B%dsQ8N+a1bAN;fyoB-60dTW_%XFl#bRfQ^
zuha}&40|?y#yEXW{Peed1*@-xCW-SL#zFt!xh}5s4;ascss4fVF&@R3vmOq2Km<7K
ze%|N7&2*mc?3u8ICfkR|WSI~9ZRwj0H*wE`9ngSW9||`O$Me*?2f?lT6MMn$5cr9{
zPOV1hOwK{EywOWBZ<7=6VG1wxs+^xX+@()wb>?m|Z8)72&Pq+1@Hqc9W!Z*>FOI~w
z<_m@$CA2HPpugq|@~qS;!;WSg@WnB-Vd}yZU(|=y^TM&fLtZ$}*~h~sFEB0P1=6m0
zp&f4GZi5}rgq(K3O(VQ82ktm8<lrYonkp6>@IqeU)x6N@(kBf&$P4MDXkJK#j`M<*
zo4WofN4rTc=BcH9QkKwPc%~QM5{I&iVRIRWCg2&{J}H}|z60FglM@|$U08%qtXy~j
zV95(7IlBiod4Y83`tO6A_$W(*v_SQIxM`&RPk=jK|MTD{^`EMMT>Vq7X<2Zx!pr)n
zj^v)&1ulI;WB&RX(UH<GrTpT3h_t0og<&xWYw;F=P7Svan;A45oCfX`1;=|98{u0T
zgKLEEG{A{2BtMZJ+SF-=Hq`!dg-gRk@_^R05^!NWn<tH%c@W$tKft{@hFf3+w}or*
z)&i~yeZqOXS-=C1TILU}AKPH~!TPm$LrZb{V}EgA0rpFcntKNc%QvPMjExMOS={K4
z4=*o{ZnSIA4C5Qq3u;4SBej9k{H<#^@#CF=IW@dXmpKDziosgpf|V=QtX#IJuzJz_
zh4Kx1?dp}w%uL@z0DWB3AzrU;eRra0lf%pQcot}#f%YclP2Q2YX1k{CP44ZbVE5VR
zhT6!O=^ZwHIp`FVudx5q?41KTq~G0)u>pT9XYLE0>Gp+^2YBbxivX+XmAyb3UjZ<>
zzs0@j45v)u{B$uE&bz;Kcv;b-%cMT7DW0$BA&sPc9Cknt_;tO)7ti0>2n%7Sc>QoE
z?<a8cv+=i^cB1TA_ZyK8b;5*uS<UFB(a<H=(Ub4#?JW9j#bQ?(*CY8IT{z*8!v#ad
zcE1{XMLQK5s;;}Yqqj3xc5{cB>>y~|2L5a?b{QTY!?wow*rnIcmAZ<h?)D-smMZ!k
z-9-!o@E#K$j%w?zcE;|oNrjG(<;E^G&_zAA^JUlV<EioPTxTv{>Fy}Ex92*0{LY?^
z_EN>~>}|`(23V=k5hCsQ>Oxm`(pHAx9>#A3Kk8i0laL1n@T0aKHMZ5$%pc2L+7R!F
z8HXSF)XcA-4Q+y({S2lf{fsU6mVO4?8pF2YXH3w~$e1{UlktYoBynEMIOub{#Ko09
z2l1J(48k40`mp-@L0*b@#C@@|Uk00PfcRLC{3h-8+xCMlg`2ov4m(H}u&;odM$Y_P
z1b4h|atZvTZ<1Pfu5Xg`4$3PPZuU>eZ|t93=4c=ts(*@^hDL2Qor*}eG>tp!_^rvb
zRpEnIfj-R#Y{yp!&594`ulayHD)q^*S2GUy;5D>i>cSHEAc%+lu)M1y=fAcA5BcD=
z&b|sZ>z;9h4@kS_gKObty4S!CaDxx7gPTV9;7YjTd~h}Vgbz~X-voScy~3^e;B}4$
z(lI$cNT)*cK`L||A7rwW9lA~j@Ggwh8^c~tno&1zaI{l~&|i4xCVUI;P}VT)W(O;6
zUgQR4QXOva%NrehU08%)>{#Viz>+6!bM}p}$rGeQ^TF+K6CY)0kPlG(X1Hni_6z41
zZejSaKT^c2&~k6oo8TvWkg9MTAF$kThScn1xI^L8<CM3!v<ZoE$}^%51D$|X^5wI`
zIa$u{vJXd_{UWi$z7F;<fPT3rne(+l9Q4;r9B1=8h===*-+_368#%Xby9a<gBXhq-
zSAni~Ie6=C^6mkh!b9^NZrbF+_W<@F)FsCZ*3a$%K@^yN-1R<{d*G(t3%J&BC&^fG
zz3KL@4fdAMr?2ey<KD~;><`+Rc-=c0uNUz|?~l9w=s2hk%dFXZKj<f)bMMv+<Xg()
ze)xxQP2LAJoYmPTj<na0AY8})Xe|B%F1~?7{EJbxc5h+-kiP|6F~RS2XFOas@8c5x
z+Gex&u*Iuwa!wQ8>TwH3q0+yp9|tyVoGkVu<827@CLM9i#GUy=wUNQ%fZfwH&%?E)
zX4@d1>or@Q?494cK?0FC9|UcQyDGVsKOVjGJGy<;0`#Grb$&E0nHViC3G}zd@|ca4
z!A#^&mr+uF&cL25$<HTZ`57#hHvmI{n@$^LsU8NoLO=Hatn0E&`@G5!c0OH1Ke{jR
zeB9~mirx8nP4Ekf-okkq_~|MW*cSK)RqJ3|;TKlFNyp2=PqHs@4~E|$hvF{Y`Plke
z-cTDBcOTs2!-jvnnfR{MHV;Xd2ltS@$C~-@7+2xST;g4VoL0v!vb>YI<e`6)dvHRD
z<9y3Lpo8VT7x?E8@Xx0vC~p^!gYjT9tl=SD;0}m<^tWbd7xnqhu*_rS(?Y*kIkwU-
zq0DiwKwX_-zh7OQ&7+?x6ZCGPW!4lc(+u2F-p%;dbwPIo7fN@uxJlZs*TT}~l?b-H
zy;gA-jQSj^j2duva(Yzw&zs@!gkW;90#8^+;Ueh|mkV8a%NtpIcXl{F!FRj!&*59g
z>FX~Sid8%h;#*h`ZoDpffnOf$M@|eM5k|#nxrADT+sjRv+ve-|mth$Ri`OT@S|lu1
zuZ-6!VF~ri@T`Q#+9tzhN?5#&8h_N2Y8Qm>6Mxly=zod$yE>=eL*l3EKH?uM8?VW1
zfv;=ZjN@foSVGx&EiNpfY`j(%)}U;>Y>=iE(W*YYnJ%oZZ0KKKHeR3ekClygiSt)w
z<2~g3Vr3KfyRumgnS$e#MkoDGOr``U78(kaIE0no>{ovVxTvS4FYsBo`I9}A4ClH3
z&%q}AL$Edc!*KH_@C+yXBd`hoY1o99Ip{CK&7Y*heuPb<#ru+r^T}A8N8#pA(qbH&
zPK);y_zP~qDQOUn>2n_ZYYI;A2wuW5O~O3}TlzT+57TP$zNx~P2E#1vP2RUv80iSp
zZt}jX!kBiLUX%BI<F@@$;^HsFoAG|A!kK6O7;f{Q@qVnrnOFY8v@_mMRXFp=UzmQz
z`#Id~<1t;1Wn@0*akzyResfOrmkyR`YuG2?7P|ON*k3zX(xYL23%Ah7Z^Hi0!ICx&
z`y|{#FTV-99d=kgwrs=lkn)szM;we9!u*DAXm{YV^~P{<vyP<<*q`UVLg5D~5BgI|
z|5ek1viqBJb1Xuxw{Bav_4^Yu-oGO85e2kLT2h{-o`I_guhIwkBzl)GLwAst+&f|6
zWxo8y=-<o!oO(K@cvFF!ZI$~?*;e=T@O}&Ym`}b_AnhxThxFL8Xz_LjyrjoHG0!@@
z@m|XrCOx<375#nLqoen+oB4LY$$E_~)2ZHGv2=ciHz-KMo(k5`ggs(=!%uL3dset^
z(FpgxfEPK)JX{F8EUz%1&EEbh{n>z#{XZJk(mKU^7GS09;$;%zZ1JA0=+roM84_N~
z;5mQ~-FB>czumi&0m;hP^?>oA{tL(b!Un%MTo@i3IZ<|TSFriW-cDxDEgWP0d75Pe
zubCC9BfgKl=mY)bt#&gHAHd?C^%%asbqx^qNk|gPJ{a&CWzX}GA3Gmpzqf%4r5(&f
zn9R`-?qK{l-**UYeu8i5PrfCt+4!amk@$zgT^Ap7ONY7mbz#8$EvzTe$eiFTz&68u
zxU-LdEp#(2;y4O^0ez4wLSJ1N;3aLjS7MICdo=7idSZKtp8#!PIv@&ifTliPm=7rz
znKR1)o;Y&&q0<<_A^4NRx{sJ-+CUkh3+*JNIXrK6C&rK5vvVZqNaU=Y;#9kz_88!l
zIX2FRao+7%_+9+;C1h|O2b_5452I-AXKwb6hr2iyx|!w(j!hLueKSwj26z8xA?RZ=
z4*i7InWb87z|q?d|MfU8K$s5uT_{#6I3hQS(;+rJ`aAq)W*_ho818RkouY(?IX(ie
zraa;l3KcwtSSVu(5-$+eM#o1CeNCMv3>%gg`U49Q$T*ZOdwbPP7sABwj?V;Huv0b0
z`Q-nEY<U{?4Yu{-t(t0EzT8>$yK!ux)K<a{LTq+y_wmsidsZS98k6Cjez7-KZo>km
zkykw^Q_8#Kw@^&g_~w8iMRI%{vsi8K?P<@K^1Zm=r_#~U+1Z)z#B(E9UBxpre(Y#Q
zDs+T8)H`MCW8fW;t#d)Em93fV3HYWwc^b;Nql^_;ybgrTq<9jeE!W<QLdT0KJ>^oR
zisy`CJ4w@^Be`H6%$eI4fL_YMlU#X=yv*!}iCX;F7o3MM8tDV{!hIrsefSZc`d9Da
zJlVk$FUyAYNWJ_uwl`jQW%_8g|HnN73jq`8ZS-Xq!!7hN4#TKtNXrr%mL-2k`Jak!
zk>P}6*lG9~<MaS&p}*CqHt)=b<d<Q~83%f91#OtRF!my1dL@Vl-FYzjtu&$^R{{^|
zS>^20VGA9?FQnamTbkCw&2-nm4sau<>)@u5eO=4o7TG9kC9B~lYbB{o4ze_9kLMW*
zFZF}$@jTO|Pa4#E*<|*3rjw!<&QhW4_}K8S@WR=kQ}Y7(`W&HM@dEudF9<KQz8LmG
z#sM$9$i)?22*MJ0Aq=bMh4X-ixC_ocAGWkR;RVvJd7%t9(=EXcaDx{raMK7coC|lH
z7mDx`UPu=t$-LkzyqXuPE`8FlgS?PVispq>=r}J}dBb{@u`2g1a;zlvM|re?^k*_&
zzsm>ZIsJu)HsV`&h_a1g0}fW&zu;$hbS#$fh5#$_i?XdQZSd8w!&es;;VZk&dLdxR
zJ0s4%05*AtbZUMXgPZs$n}d8JSL1NgaJ_|nra`#l{4xqZ;g?i}=wyf96G~aaa%lC2
z$11L$wn?Q!{-G|%9R<ys9X+H8`~29=dd775;^aMoYZfh7w|eQ?vkUXru3f$K<aKKo
zt+9Ip69R(q+E(Oi2FiOi%DK_LN$z38Jv_r}{PH+%H{H6>A1#mc53@%Jc`R><mX;1}
z@DaQOn^JHq2>KkP6FiW4u_`;<lafHr#B?^=cU57h)n0*$+0xP4fFJKvb+wh-N<Fx4
zv5eQ-iup>l6A$}!=G%R2U@Q7vu?M<Rq0w}^_##SAM^4VWz7%<rHh3|<HE+KR?y!&0
z<Xr+c+W_NOIgUH*(U-7sGT9|Z+i&T!yy+;<dj()$iJ!DN#=R6j-ba5KZ5ZNY+PeJ{
z?o}>a+P|E!lXdr5h<g!WX!FN<HvJaZ9?sZZiLiivwB~p0AJV@KxfXe`4RCezL0-Jp
zrC%480s5d%V&%nEfTg^++S!-Gma<~`$lQ<6PMdO!=lEzdjcXAnC?CXOdDDb>nCe{z
zKe<o-3Vg?9$~Ev4nUcy6PNwiqSxD63lgF!7TpeQiC@jxbZ)nB%V96g@Sv8xD*VfMD
z<-pi;++_B;W)UX>z+l`H;Kp{|^@={qBDMqG34R0o#qi#tXSyByt<|n&qNlKUcmXb0
zUN<y4?3Zzk5H8e!9N@Yc&aT?9`IW#A_bgbyHRC07O%w7+SlqQ>{g=Co6r4Zww)J0V
zcLfl3iukR$aJ)F;uddbX{Z3QGf3-hY<V_2x7sBr*{tNI*JR%5v7z10}3u;5yh+yu5
zCj2z<UyZw<aW5JDb{D_3BjZD5?gqDXPZ$5i12xJ<!p;!C1=t$m;Pw!|`Q;k#m>?YP
zt+MIQAH`$N)^D%CZ>%VO&^-<ge(g4my~S?<)`nc%eF8ru;p$*t<;OkoOm{!=TeQW@
zDbR0!@mn0?!+lvc-Nl17>Po^rEASif5!?8IA1&OHt;47a<M(XwTZRiS9Na;HUv0h6
z_Z;Qdma}o6D}Kvsm8whkdE&PUn@3#Uo-clD>|5BR?_lL8`JE|#Yf+>w?jg!g;AV;6
z**UZBJ3DZ<8TX-qd&syC6Zf*(`jVsbaPeE=Zy76AF%@g`^ncj9^SGPJ_HX>>-Wws6
z3>k|i5y_lHndf;P%8+@Ur;<{N=0S==Dn(^((14WYD6>#9hSGormGXP9eO=q-zVGhm
z`+I)Ff6x7TxoPdS*E-K*_<TOcah_}K%QBAlj-n?TYw^^vy3vn$r`fke#<6Z=(vMx9
zI+h-%$q-EctYqlYzDbh?GHl2xpO-pyZ1|~TSEL=2bs6WCK6NbPyerd=$-<2D%A7iu
zabDT9W3n>iymF_GWt>+&?O3a!!$vqUZH^T(jyW;ySjDtsO}dTAxL&1G$1<*WRr;~M
zgEG#meCk-nc~_?$t2J;)#(7mv9m_cHn)G9X2lhQRma1vT+JKAbU^1SorJpxy#E`z_
zTr%?CwWp2^?_17^(Xs1J9UC&d+>pM>W7SU`8$P_;@U&w!P90;H=*0B6teJ5<?d0_1
zwbG9B^YEk#qkGj(J62y$(TLLQSSS5h+F5DG>ZTn_qL~wu^Qm{*vD6&vryZ*unJl_~
zgS7uH7X?=;{~Kl;8=gAWDE(LzT&ZJ?Gmf1)uSxo`D7aGRHO)A7>bz#@$D-g$o!30$
z*s1ecq#sKLS2|9&JnfhhlXGpAek=;E)b(0t96NQrHmPHRD|KGmjAN(HYnOg33a-?7
z?K6&@I<G_OSQJO;W9gWFEG@Xw-oe)?b)Mkraat@~pK*M6k0@}`W8sF3<LO^W^K<9Z
zj;DPg?Rb}r<58@g;^M9u$D>#~b-Y`~@n}4!FyzLJ<I&|$9q*oTyvNYf&hL?NJPPt2
zL(^llXU6fg!|C(tm2o_p*QxV+XB<yEoPK_v^yBGCacca1(~l<;Bi-)(QpcjiNI%v;
z{a9LJr1@gN>BpEP%7cOF$0SDb9@pB-F^C$EH0a}WS(m!ayEJQFr)7=S4VpFe*jDX2
z>0847<9PMtzPo6Bwz}_L?2qM}<a+JM)Bd|=dR>;bH?@}?O;O(?kv!j18mInydQubi
zDqk-B^Cy!3Ju>;<7udt<S+y)rI+iuGX<ey8muOI}lm9Y|RJ{@1Bl;8FKhn%;_e_MD
zzLz?uy3e9NsdJ)#N6P&v=cLw*PrpudUbJ4CalOppY3HW)8%7ozQa9SfIil_mqm68w
z)QYKN>3g`6S}}F3avCQmbz<sR*>aUrIg!+fX~!E_k4ffzQYWS#bDQL`q()3X<~GS=
zNqv}htWD~>No|;ZEcM-_E=)g``fgGerX8!<y@x@j$7WI&rX5eI&g8w4+A!^StK<uu
z_^y(8Ix9V%o@FQT)SynCI$i2EYuThm>r=6G+Of1aO4+_Tdq;mFyJy%wk@q719mSYZ
zCHXrk)%`nqzV12q5QE9u|9Srop<VKwS21Ilm;CSOShDBQrhK^?EnC*;kXEdx{>$xC
z-`|+r!`{yOd^4+XLj1*l{eIo%Em%t6wJ|CG^v$&W38}HA$A5Ax^V7#tEd5#wPP-O=
zG)P^^KTcieLgS3)=rx^D9wo1{DE&IAF)cprI{a0$R&9Ptjw$)i<h8Pg%()`l#f>lZ
z??gP~-#IcLJ<{->dobzVs?)w!o#sgdsN1+kz4SKBKY!+qmHwC4YFndmn<R)tW=r}#
zdBpdkIyS<BrO7!Zk*n{Z-h^`cJDgum9&es{U2F1L*H@CqnkAoD@Cw)Du~!|-6l!(z
z0>o4Qoi)@M)a}N!K2CIx=$srOdiK>uX>lDLd(E+&A$hGqJ<6u_f}&$(Qpe<3>b&Nm
zW!g{T_-+;RwWJbX=G@f(hMbD@mUU`1Ygs!LC&>w?9ZLEp6%YUB$GXi^ZjAor%+z`R
z7B_8DapNDSu4kuXJT;EAzgha<t{276Kb{xiPI^rH=l|-O{}Hp%82{m#|1rk@a_@hP
z-T(5wx>UBN4K?*&M*Cl`{g1iY(Hei`&+17dMR47=+kla2F%x0FUtAhesY1rFx03#?
zJEU@%jAP5wkFizS!Sq<t2J=5~opv-CHxZ{gmby*y*ox%$new#rqP!0QT%UF<%3sI+
z<-04B-(}v@&U-s~ED6_XN7Kg>aaIuT!(>$22Wc^%Hl}nKKkYiJ(yk36hYjmCHtmDR
zR%y?sL%Y+?eJ6Qt-62C$N8PhDj)u)y-t}3||M5AK>M$-1qtbehY5&d?J9;E~=WBG|
z)yaEgjN`rJb<=az;nX|U-%lP-BcUj-BP`N~i+_;(eq@6Xik`~N|Bgjb9L0R^-#DXg
z^MA;XQ)4&YQ~y2<Ut@{Wj%PZ0Bzop9no~3f@o?%HiRjqJ$zyF!JxdZD`y_d+*{SDA
zqGO*Xk9G7+NqX}r-Op>%uQ@6*Nd_z?@jbKotWAC%-8Z>z^v@Wc0)Qk~{Tuenu}J%*
z#berjnN%M(ilyjJ6l+obr2a%4mhm0$SdknV`ss|Y&X`hbIni}f=cmP{-{SN6<>|lE
z6kR(y9-WiAU-WnCUeUiZuI(Lu$!n+f9$Ig@$U5Ht)-zCD`Xm<sx+H&ZE%`9i|1_5B
z#t{8UjV1bbwCKLgSW?esr5)>)<fk-S_6;@D$F;+Gnf}L|`Im9^N)Aj6WX#=rliB(I
z*<1&8^K#enX?iAW&a|<n`8svI|GhD~UfKwcoWAEUde`26?)l6Vb|-z7wl^VlPBgD*
z52z3hdwrhj)u;AAmPvl*y^g1S7JWDRUh1<0$?ImsLUf%}9T3IU>Gz7_E2;y&bx!nb
zWTfMh+CC{untBkY=kV0CUrBwRJl>@5ppnBH4D!T<Wu>I{PwM>SXU#n<a_Xa`UQX)$
z<Y%=!1T;i*`RI|F^m6nbjwp5xyLU<>wQSa=Y3&A0>vd^zdI^@MCQkoIdM0Zwj~*s-
zB+{VKyYVB;_`&t`^#}EKpXk4%oUudf#;A`Q)l_kK{iAc}(db}QQbqr8$>?|evgGv?
zv{R!0rAC#+&(q$P9lZtfiX=$?`_qIOA5{OBFGu6;Y<xLg9ax_h^%>tt>9gqb5dNQW
zK&Fs0el+?0=o<g`I3SvHPA_;&<FJ1j_W$cSr}7~B4WiTkMDdyydl@*Hj9>fze=+_P
zPDbZMe=^SZyMsPY)lE_SM1NAam^wGj=b6JF&P}aB{rkDmIsbaTcP%FGo%#);G%P5V
z9#?7jHF!w((|(IG$|vhZ$=_cYk4ptk;-qV&{-^IBZ3pZXopEZFGxgH-WEgdcJ{q2k
zqc#~&rAASa{z>x9(ivB&UcEz&=3Y~id|h;R@60G$_Np606g$!V>C!~%-f4eleDnYB
z`@^c7v8&S7Ripk$+`l9HuJiu)6#hgutifg}yGK5W@F$aVQ$A1mGV*zvALAj5&!hU|
zA9Qy*xBsu}k7!LYt83)YrAWm?wrG6mJe!Om|Bl8M-8apMSweQ_q<H_|&yUt!qd(Di
zGrn_1$l*Kx?H<*gAN|QVKTA0KwDY5DC2i#IlpRvGO0z|lkkk36+bVVcl&y08`{(KR
zOMRXv`FUzDd)l+qk$pxHvXOlvO)HMGTqS4!XMV08&Q7l{9`XGUnkI80!rlDtlQlHy
zJG^^ZJ$aE&bA+~ihm9E7ZGeVfw23x_dC_M%Lo2UpZ`P}2x6!quclbxwh>qt8%?Bs9
zueTnY`Y4I((P#Nj`>bd5lS3m^$NJ-`?-tJZys_s4{XmO#-Sp2d^!=hCwUXQNw6CY}
zM)dhbr#?UZ>uH}y_rD}WOT?a!wuNH&h`!yU9)4YMs+SQjVE(E971#S{Qlnm-XctAY
z!BAfc*J+uiK>z8J>g-Aj#$BK&|D|G}Kc7U}ppa{)v_bTF6i-ncMA>(K(!Ytk`<xqn
zk6V&@DH+rDJict;so!oIo%~KK4}A7$8Liz#c8iW>4e7`92QEnBn*H>yoBChQP-}SI
zVUepdo-0e`LkBmE{+$uynZm`s8^zcq{*GcS`YgiEXf92?Q#|@?hdxx=XKC|}_6iJj
zMs#kpUm!ZSc=9^2WPV0{p6Ij7ljHK9AM=f_Q}Wb35_zL>L^kk0{QHmik!JnI&1%$+
zUe{H(LA_-Aw@ZVjt?Sf__T`-JqyK&ue>KgLraze1|DssVh(m8V>pQTgu<ofBGjK>U
zwxjrxAKm&59@bV+Ms1y>{iEaA<&9_L|K)ge-5jCbfWbF*8&G#Zx8B2R+0$-qG8OAN
zPyeiyP3!5kQuMt%p_WYwef`Fl-9S-})b81<n`QcFRD(y3NRB76Q~pr9rz+XYX6t(N
zq-OMHsn&fYYM;Ral6~{&UeS3)Po39#@Cd_k@;{zeJT!I*y{uk+$Fxp1rqXgJx<(mu
zPyW71jRC35O&TqAkIE^mXwq}w;9+C`@%q(6^I?O#1Ckoi^S{(+leFi~Q#Pre`n<j;
zZ<0pKuyNy1t5xlkh0|>n*}kc{4e6;g9W<ix;BGzAzLoxYH16i1PLIAL8q4>zYemP}
zhtw{sT7w7o?|bUEs-w@khE{dbc2^BcGr?)s>XY$Vt<!(YI{My_P|x0o9<}P$>eI7(
z|GM@pM2<_xLb0E+)0otGwfhbq(rrZdKL38|Y4^J=b#CgMv=N=U*5rTxJZ)5`V(g)`
z&;P|HrRCeBA=*IFAo>*^aW?i;Jk3r!KOOB`drRM-2Hi%~@v#2b|FFfp|9<X&*k*Cs
zxs3-8>fLbUz#*->4I{JuZ7#3>(>bTjC$jOXP<t!^*0+07ZYMe5KgRV@s8zptohF_z
ziGEt<KkdIR?LIB**6r4JfQLAgIwPWI(Nq5U;-5cHc_4McQ#Ri9U&hod?FUbi=S6Y4
z@4uXvp5do3=9{R8+jAI*FL!E82UBAb|9yK!FGrN6X)OC+$MsXFKX^p*D8P~?N*_)J
z7yf+eKIKo{=eT}!_W|g|zK33Ydyn+Ooqvqs5NkVlfX@c>{O@+o8cXIwo%*iDz$25F
z`Zu5F{HJsN&FA^k&S_t_-ajVRsaz;}>b(D!SQ$B3{M5P00sXfxoVs?ISgmfuM<nOd
zY<TUS<b(YqJ$s}_P}*8R^qYZYklvL^e&cZes~qdnvQ@=&Epa*<)owrlw{F(5L#k8$
zKc0rMjvh(vAC2NkA2?!_Q*jfwwgB60^vUpXwBC?BmhSx&&SpL3`!t@7YWuRMjoX^p
z|7Sd#9P0o1zyD)_|6_swV}buo3rxHu5e|*lL-Iu0&P5^IojVrJITR0Xjj@9McOq<9
z8p5t&A>2?T7H)bo5!&6J2rYKfySrmyL5V~t_jn?_vpN=vdzn*~{W^vBd(Xnf_L039
z3unxWhmzYun77CCrAuO=;T?MV15_#3BtqXtvG81tMEIsp2<5eCiY*Lb!!3z0%5QIf
z+A@SoODDqZBNAbD`4C1OOoU-|y!&g0u4SJ@SU)`;u0P@#=c<WNXt}kM>alRv*M8&n
zqD1KMW(ae$xbK))sMOhd?{R(OUlZXDP2}tT^lZ`ESa|B?cz9*GIc|-I#P#uTxPB}=
zFwy&3D}-?Vq<Gj~F@(Rj$HU@T@o;a>c!+=Ndz)h6W%Di2T}@EPyMLF(!$W7<cRer>
z+PuI%n-U?*cE4-XJsujji-qQI#=?VD;-T0xiLm5T?>e7HM?YvcdX9K_b%Eb7n5d51
z;{6rp#lqTGo%^Nle4Ge-8haPt67P^4&F-uGPWO2sT-hWZ4rQ@V^(8ezED<K36%RMH
ziHDWF6XCvV<Kd&nLzuuO`z!fuP(0lAQ7l~ZTnHy0jfIC+dbdR>d+qzj!+Nz!%@&E!
zmY?sK9Kv^Z#>4FT-ZSStsdf13%5S3IpRw0hx8vz;iEwm--?@4&7OKzk8wPB&u23vY
z%p4ETUl+pYDY3BTlX!Ta{Rdr}2%DD0!tp2K;p}hXp|H6$xyJRk#6rh1iSXy45UTBs
zhYlw_2QwoPW=%8S2Jx`<ckdF}od`SU#zN<Y@$l|R?^mo855M$@hY~XrVa1j4aN%6<
zIGh{{Ef9asS7PD)=hbeyUgK`@tWU2*==4D>+}I-)vaT@p8)D(za`Euf4$m1?i--Bc
z;$g($M5yJ#)|(%+o@Nf!%%|xdzTE9T<Hh7i&-b+t;oEJo@a8M=aNkh9wW(rzdMvzp
zNjyyLZEWQd$!m>zJ%pq6VxdCqcxYz6L-rU$tyoxJED_H8fPeDaiBc>U{_3D!ofHcP
z#o%MFC&I(xKj$jyp+GGB{$M=Zc6lP~s2uYmw-8#^jD=lWe79LVeEeM^Os^XY!#|IO
zebc;ud6<|Gv!AXP&v(SacW)=cv4`T}@>lf%uJdktF`N5#@22a^@88Bk$zlBa0HM({
z5r$kG4+X^dw<qFZ#@&AV@Cv`5S~wQ&8=nXVANH(^dmcM05pMWOud!$>Y|d$(2V&u)
zOMO>v-`m&wD{l*-?C?bR;?h{S>Z5qb|6>RT4#&e>dHA_`9Dc}iN6u~dY%FAw3qL&U
z`8a-WmM0MgpPvZ3uZV?b{)~sgVy)pJ&!KC4?)=N#JF~y|E^&4Uw>E(R;<xs9vGC;n
zM0ntZL}*>W??C$g3kSr|Yl+Z#ObBm^u{Vt4vELHm%@7MYPsBnkb6ntl`81cty$}ms
zn|bcUJ)an&Ry^o;l?%qhqcaoXX?A>_-+yfp4@2|wf%s^=JcJVq?7N3&hsueY@`+GN
zYz})P7FLW+gvM}e$O>cN^SV>TpnKhR(3}g$!@`!aFmy*eJPSALR*r`?h2WJuX#b=6
z%KbixSjgWu7TR}>g@I!2`<m)1b1Wp+KUk6os~!$v1#DO(md5#A$=MBKVd=6&m;t-?
zdyeaDn3+9~cM#`?AM@j3$6bkV;4yaQ%L$+G#jIEuRW*d_KN#0)u`u0lfAYh+Z|w75
zXAf<GM7W@q{;=5Ud{nGn4g;&i!ql%}#%=LXr;Jz{8^TnvI<E<z+o;w0&Jgw#@UGZw
ziE#XtL@4uzH-5e5`D1u9!nHS^8w*#9x!3=Wg#!Z;q5ey;FuFM3%}a!wa_|j{%=5+1
zdEXnS1+|qe^ijW$hem($_Z;sZaPICd@}8}JJBJ_H>nHJWjq`6_!UnKrPpeq?<T<~g
z($9O1VDIrFayEM`OyGn1JB;&@M7YtvJ3k{Q8inxJ1e_#?#%uH?%x}r(Vvl{B?2U!S
za=RE2|3sHWX!vE^J38Xwg?b@?gzz=|JyZS`o*xUxCW-OPe%teoM0iWQRfC<a_j+I8
zM0?p`L)2HyRW%m!Wln_Z9~;x;cxX^xzE+Bb*GhU$rx$)0mk3vj$quDMc%XO)2Y0%b
z^D^^i2RXU6wco6JG9IqllL#+Ap9s004B@h-Z1HG3R9x-%>*3}-P5n0Ygm}1JeD|B0
z2v?0sghuo6vGaC39SgtQs;|x;kD23(kHkZT@gY2XVLUXvQ#`@FAB(t`JUITox34Zv
zgzs}DLbLqhL5#c$D+j>4ez0>Ed>)$B^Ae*Iq1#ch)+HWJ^oxhy)#Kq2UBrX;z&A0z
z^LqZgiOqlW-X3|iCad4Q!F8Xr``>I?`yKP17eem8ae17ti^Rjt9b+L|hj`f1+gNYL
zb5Ggp@MAob5tC1vOR*h^Fg~6LW7xS(7i+-h#lr>r#57xu!J*x8>eINdaK3oR@u}a)
zY!2(T;(=>C$G*U7Yg=oV=HGI3EcAz!onS`3+x4G@&<54SMJ>nVb31YLG91bLsrOzx
zCpX<v1SYhkJ+{7vC-F?Tvt!}n)v?g-WBq+Nf9djAXxodv;G+^S>c?a9cu@#*2Kn8F
z;d0KkR^`L>2gSx^@sQ8hn&IBPLt~-b2|d+mI9^^289~>`m%gxmZOwRC2A3YJD*n!l
zhsU3yk;XZ`JcOMM5}{XvXi)(N!~E!ZuL9K)VeGph?8p`m%}2*WIeu^5-|rmE4WVa6
zI3O;v)lP(a#oI2pwy#D!)Z7K%*}paZSXl^9oRbK1@%=|Hd!}CeErVV68Q=GEy@Gj7
zydAg9wx|CM@!j0G%{vo)v5DWu!{7PFQcC{a{gLPO&M=SP;^E|4_sHb4&M*ab{UnKw
zK7w!d#zVVBvGDfSu5&>=y!V^jl8X-+Z>tYu;qx=?w^#VSJx?ySNre6h`cLi^>_$(C
zlW$geSAcmuJU<bR$p6Ew{gxZ9UwpBBF6|QG*<0m!bH1gC*6*fc;Lkxm+26`<6Uv$U
zTG4(B#lU5;aPkU!0QmUe`+k$@5WE!o8+PI(c|Ns7B0SP45xy4R-CXnDV~H@;IO@}u
z9p8_KRyDoDC%bE%?K|#WZWN!1)o4HB)Gy^=UmAzMwu|W@e9(6bj@cB#`gYb0#NC-U
z#>2x8!H^O#7+=;ak3X~8(e#UV)GcLCn0ZZ0nBUx*!FM72niuCBhASgOctu?O{;vH7
zZRE~+Sap{eU6`Putq(tgV>aQ54zTjic<3dMKYKS8rahDh+a|HuNjVQcg7F_HET^;4
z493*(9auFW7Ji_+^1LUO-u8aGqA>oOG`!sx=<GjnPfxKZZchyJe(Pu0&0M#gqzmNd
zwHM2=t?_X8j98e|o?UR>3FG_>Zhu8fE`2-^KKv>k=4^<E_E~Tr+t#g1ztF}ro~NNc
zfFFF&{AW7$`go}4JJ;4_>%t)veKr=p850j(f0sL-(#K-uvOmSbN$WWD@%oEGxVm=;
z&&%W1aBJ~5;`dpYQall=zMlwn=CBKG6_Xp8tN4BwYpTEc{hg=j>7U?kIdf4{JT%za
zPam8j#>R@zyXEBkV<EgO=6@S%U8i9zG@23*E%Wh_^DblC3FdHBMdQm0Q}<f4yFjk-
z$2mW!1?Y#**Tlnb^xIFcEjOO|>g;$}_kAM#^{I8Fdhw7ICsiD%9vDN1-4G8Ghp0Dj
zVCM(oA@?4(l5<V)#wEqz-jqZ*e?SOZH;adk-phKebH(4ccft6FX$bc^<396%&*S>T
zht1;h!g#m_x75Wc33k63z8?L=`0!kh4?J_&Egs%<-F#x;(e}7{ZY<O>_80Gohtl8S
zaQ5wP>^<&}g-)=i!=>;Qc7L#)ZRzpyI5B$;&z8=BgE?Ws@^~2kVInL#6E}*t`(fp6
zjc99e-t`lhI+3nzrv5uX?>rC-d43P!V>t6@SuxQ=-PaJd+#CyK@JnGi`1GrZQ0;_&
z-;)Tpz9~jGy6-H%8BW6tcD-5rTe77Zv!r*3!I}JJ;^EVrelNazEc_{!Zr<blE|;tE
z_~ljcxBJ^zXdv$szw?Ls;JRMEa{=9~K5D?$FHehw5f8JIvArXH>O4r_O|s{wDL-FC
zPxR!|W$|$CWLO0&Zk-&$f~kD{jo*skn~(9pC~<XM?5>eBwdtyPE94waa|3Nu<t<n<
z&vjwRU$jEU)iCM~n#fqzh^uShd0jZtY@Ixm4}ZK7!a^L^3zrlb84Cr(<fvx&=4!rW
zvv?VGRBssAf@b^{PBx}}OZlBK<D5i)&Z8;6ej*lj7nFxH<^4<X@D)xRGZJUx`cC<1
zYP_@~tGaxinqo{MG=){uuTO-V;80E&e;FUoDJ3pu<Mbc-Y=AXKc>akT>c-C3-=XGa
z*ZOjJ3he3i1?&)450}Fqc%&2?eb7CGH{j)3wp-I*9V!k#-zLu8f5ARu=!_edhVatr
zczEN+kkrakOUsi*-u-la2pg+f^Bl=%kHesg)$(eZr{P2qIDY@7-eXua9&YK1|5wCA
zHas{8r{0<se!$SXSH{C11--ZZPJV%DwfL&7@&C3|?bSAfUuwd3zIpU^I3eCP+!6~#
z#eUve>gLrrw_q&H+^?pDzn*Ieli6~Gdgu)CPzENxHi7Pk^^b{{@7D8`x%YpY%{Q|@
zdwsB79^9+0+(F;UoA3r-F1FKeXDn>$BoAuPVRPXh|JSE+4h-i1-SKc^HTA_?dJG@L
zL(wPWAx7WdqZiTglUTU@yLgzqHx{NW3t{sF@r*aWI1&pbj63JWFkK9_yAT$>6AKT+
z%8|wSO`Y_|ABph(-67PwKN0T1mEZNJ2{XIaj1ZnW6bnDSu75CBj^VFw<n>niVN?n8
zz>RyG&}Z{vf{U&hkqD(f#ZTh0R9syAmIx=FpxHmw&)~n8M$^(|J@4`ojK4;m{}Apw
zTmR#**kPkzabBOJAuK9GBOZ;1SzT#dpEo?H&O28v%C{q7V%wp9#|Y0<yie_K?32|J
zC*H-YV&VH2UH2{5c}_1voHV@}w)NHH7w1=quhBVa%4@uv3=aMVmoB~uroz1&a?yFs
z;FLIC*f9~F-x9)h7+kOxyWq*6&$8J45nhHLH9n%HjsLGjw0Ks2T%u;AC0;BS52cQH
z*8o1tcR)_@d6Q@T?qW+^GB^=7i?3Hc6W8$VQP-Q=g5SrX-V^3`((f(b?RlTJbVxn*
z$9e8^E}eCwehy6Oe_JfPSThm+hHI}(gZ<Ovq4IBj%aG5;8Sm`#=rMD={}sA;bt3$_
zNMEX=-F7hSa6f*hdG4R6=faP7=cOAiW{dkmsNlR(^uZeQ`H(Lg|EhleBOWf<DBiwT
z7n)Q4sfqBM{K~UN-1EUpeE8v7_wEG0#KH@o=?C4cr*)1#lK5EE1y6tFw<wCrds_LP
zQhGylL>K(jRBf?UoZm((94R19o|Hpkb<f9e{WHA7r<LX614GP_UuWeMBkmVAhp<?E
zIPH^oXpv2i<ji=O_MQ5KZ4X?M2+!c>;XknhZP8~64mc4D%U`4A7qf9YzjIIfcg#*t
zK1d_NwYhb01b?rqK@(kQOk!qU>v*_&3Ebq5vg`R!j`g2|PuZyEU2x?rI3zyS!PoDu
zWaEoq!~S?UlOH}CC<lt*1-O<8H%@{<qha3NGkj*8*R^xKy>cQ?2(xcVgavYNdK=fF
ziGQ6M3m>0D>#f8w+4bSXOx||hr-*O1_N8UyM8i&Ms}Evf@)z;&I^O8<d^}8V9}m?k
z!ycTyXC3~3UDAn@WyX*b1{JSj&+=;dhMV`&1yA1$$K*x#_vxItxP%3*A7vY3Ex{IF
zSAuuV=oUFQQ{MI+<a;~l0&)9BZnmbK8$GKhB2E{5Mi-4ugtzILYD3`gXc}2eW)ZI&
zV9N<MJRiS*Mvou+IUb%|r4I)uw>73i=&HYe4dG8dj<n*lE7+t5{~7+ug=(&CdU%)8
zy2g869(CQNu$JCj{0IHM3w~XwN77S27LIO(r;T2uD|ge3<Mn#@uib2Q$;0xuEPitC
zn#1~o7un9&UQaZbpB!oqzh{lZH#Fi3^SV&XT(wCZXim?;lJ<S#VcT@PkXcXHxHcO5
z*;QfSW9-D=bNsuxxgY1_Iq<rRydJTO&+%o&v*Y3IUHGg&EX|w<TfXp)i`FnejLll5
z|B;&}GLN}>0S|U%M;uzdw;HLa-=&h5n-h8uQ{e7%dW9ABZyLc2`lgpLtk$R8BcAVt
zbLYX_`S_^i`b3!Xk$%r@dUG+{jyJx0fsS?UvGDDJi8TG^VoZGQ93H~^@?~!+dhM{<
zo9-QK4x8af!|U~3N_!Xa#ffk|4Sd=8_$WJD!20TM=#R_QzE9$`1?pdVI_e4JJWdPX
zs2`ui***2l<l&;o&ZYG4;m^65=?U{%*GFyLOfB)ITJjS7Kh5!l`dTevlF#ceRzt#_
zd3phPbL!8{)*s-fT;|%pl^#7E^B|s^FGgdp;x+U85r&SI%hMg(LM!cApgyEAoB8|O
zt#sBpdO+<QZdXIe=ehJ?MRD6EpE(T;q1G(6!I{$^qM_dpVN-pvJ|-}p@h{f1g2Qip
zLKo2o`vpM({8nC$Ue`gdjE+43w`x6vC$s1Sv<l&^_w_;Z$f*xQSVE&M?F(yhOvT65
zFEFt9b@&NpPI?``Z80ZUU8$0DE5HdlbU6LiBG6#&b*pRr-6a;fuExa=>wnYpzctp!
ziFl#2Jxf>M{uT6I7P?AIu7V*;?xTx)#>4k@^pR-kvGQe$d^)2wje>J>X2T&xW8utw
z@$ki7b+TM}s}OxFcP~31j>)NKal_V~^fGKZd!*}%t^K{+yPsao+iZH4KJQiDkwhCc
z@SX0%;^Dat>a3q*p?iHjpp~>HP7aN&Q=F^E3%8y*qWAHX{-}8GFMiwo<oG1Nbt^uX
z9)rc()eza@;Vc}qc6SJmd@7!6>m3^Z26<F-St3-fD=*&C2bAyGm&o;wYM9??Z!ucx
z+(bCjHKzD;n9r~NRbJtfY~w<>rldZ?YxrQl{DFJFEn$nXcwW6TvjaPP?K$SB^~+%Y
zh#&Rh;C)_o+;ZA;-2Jc=&gS*!ah#txL)=Z!A2F{dK2+zyxEeFqrB)(zr+HfAo~SSQ
z3p}{rxUYqs9V@5<*rKXfdcT;S$~$Tl_Nr0|me-{p<n2w>Vxepuz4eP=0nEShS$3~U
zU%-LIUF5>PL|8sj|5WU}!4?Z{vPQJjXIH5Mi^W61Tl6#Tur}q`Rs8btd&Z4_?-WO)
zx+TKl_vH75-jO87%C-&RRWbVenPOJ{muiF~>AezV)!|>l_aAZ4AR2xNeBhG?kLq!D
zR7d2Hhk4|J_*%4uY`H+suPQsjrb1WIjr8MPi`5K;X}Ro)aIy?7Xg+;DP-k8l4>vro
zM?=31&8DwhL_E#J2Xd?O{CLQ;Q6J}Fn4eetiPIr{_;(u~Ii#i$4_9ACD?QDJV)6rA
zHh)t*94nd#UFGwvOmzDP`bCRi{hMO3mb!O}{EmrXb{Tp%&i^46wx5#-6&tF9ujcPp
z#oHcr6<_Zf%r|o!ucxm6*qV>nAA+}z;J$O=!VWpSeM2IAa4(LOAGc<v0UsB;?EA!h
zaP8@M`15mG3tp``!y04@c3KM~{=|Q?;mu&NB$qE_%P-V{D<_HXuVdk^K{(|kF8dHi
z;+I@+S(l?Ts_}2bQHe0^s5R7uG%@ZNWvut-#3h&08}0R-uF*R<p~tkBCb*L(dK7<L
zYu_X6`WE)|d{~WJ!8)c|VrusgE~LG(ZLt=$&U|s(5b-<eC3W}tiLfp!eVb5M!rF>2
zB*GJNtdwzGEXJn7s|8{u_hjS!)4pLkZ!d2C6sOOAM@$Tlg`fYT>1L_>96KlvrWw!m
zne<K{ON8HQ(aATmeg0TDl!yJs$HR34W8vAdG^)J&rj7MMlW$zXS_mFF&c8pmh=nS@
zd8e^)pF{7of;UGUTl1~{n>eh{o(<o%4wT>ccErM9@i6*KPs3ajLiOqP46<d5UTVI-
z%;BUyah#U?RxfRe+Vx&}QVyoS9Kww>dKX-s#r3ayoDXxWbMf=E+<K$$<1)GR{Wb7O
z{j<0vY=jBDZ-52jX!ZqqU4`vqhC9uU<JGUl0i1vGKKjsgzob1|9j9OA?`<$@y8C|h
zw|W3(%-evYpVgb77sj2de=|_tf2r>yhNsHI)-a+(akZ>iXx~ju*AXYn@d>!IsvKN&
zSiQDVUk7IY{5d?pXN~vpaasQ9MZX=B^LOa0ZI!3D#6q+FdOo-6b50f`V&Es(Gy%_5
zl21FY!Z~tmqH_z&&qep)7yQ569Nzjk0XyU2iFNX26|A~Lk9npwmPT}u+<5y$Tx_bn
z&R5gYNPqtYH^tq&g7MHsP7H#}7rm#hy3Tru8a~p8jrec)kJjBg;19Vo4?a~EkELPb
zdk16TTz=fs!8&kBd@@eGQCjSGVf%;F8;{Y7u&v?k#`u`pA&%eX(jZT<WjFQ3>;R|P
zwyE{RvtbH-_gf=9aq-X`Hg0W77d&b0V74A7{@PkCgfH*1&R{;(Xq!YnH4n{KQOs_D
zUu*V@mEZM+#Xu+6G@%^3ve~b2d0P&3JI(q1b2MMRL?|qlpM@huO3KSZdV+jdvIITO
zk1IOMm+ksF@~6)NwS;>#`40YwpFy~)5g%WO_g>@Ui`7}Li-{xU^@D!KZ?xLWFUyB2
zYDb)Z^Y_+BVB@u$=)g5_XbcUgceWSacjyN%2C#G7eTKrtzhTBPeRkYejfQ%+9GrM2
z7G9Xdj}39+)ilQya;~qMv~nW+V&2QybS3@ON3Z^+>*$Xs)J)Umsr&yR&X26HPA0FP
zhYjVbsQ2i_OMZxlcc$pS+z;1a`mG&l_Ixm~K_ax;rB0J?Q9u0VuV4=DIdBkH^Hcd6
zatn`ls!2N^gBRt+hwp4^KtsG@$GyMLqxl~BP(Sn{doB2>s{4$)k`}(2j=_g_T)^%x
z(QSOxTpiYIhkhR)eDxO$V~?)%(wp*O`UC7L&o3Km4N=eP!D`kU<lIB6;vv_1_;bIW
z*+$Q>jCSAM`Zsgpp_6!A@{xPeS+7^rC$5ZF{<PNT-*w%0-`lh)PUwy=Kiv;E#92bz
z3?552&4k4Zy?d5zTfwnPHQ@zrdXIKqpfB(_j=S=ZJt8=)RaX4YzAb){vk&WKokP!0
zg(K(d5xCAau{{4t>sbfvQ84x+Z2UGXJo*kS&q|9uK~Mfh6SXmyS@H1H?dt7D@be>e
z%vyCEtzX}GH?>puER(B0$cOK&yPRblZ1bV<zn@3%3bxliV(kH+_WL6qI@9lm`1jJG
z@zAj?UWI#2ZlGIUbFMLOkW*a>h=Eu9&Iz9U7%oM%O-Ftz1V2g?)(-*3w-<<q)px-&
z|L(8GX;U>GR?t1o8>wMh%Uc{*m2O$nT}@X;U$}8Re8M)xV0iRyz+H0lHQaDheHi%$
zEP*Xk)z6t}iPxWu`Xc({Ptgc@XfttB^L|))IUeNC+pEVzQSr8SJAK!l{=G4TqGGVq
zRDB`+gxOQ%MQzWASK;Gb(b^!cD3Az`sgeI!kDuYh7P()1HQb}EZ^i|;z{#<2ZMFGs
z!g(#_;1T|rLK{>W6boO@w(sLB`ORL_;`*)Tn5&>XJP9l0;HppX_&wHgv&X{a*TQx&
zel?%Z`izY)7L!xigI;TfBOd!H5hmOz&R}a!=WjRfex1Bi9d_jSTHj)>wZYr*nV6sZ
zCtt|BZZyL264pWS#sqO+=L0>%J!<GlV)iDzF#p~1GO@l!P2D6BZfP11eaz#mTi9-b
zJd+m%#p6@m)l^EMh8072$Gm#1^6#Cr$EEJq$=dmi^eMkBsjj9O9t%ZjiKrI*#kg}H
zwzl-5W4Ef4YU8L9cqp4S&D*S<eWLHt5$_I3ga<d#d70_b3VI}q^keYj7Fbo|QgLq{
z-^<0D#`_#j9F(JVbHNule?c{UrCIWvo_H?5no)fJ2`lTnPt_LIJ7D}p$JJ$5Sc4dc
zXBObaH*jEW`@6cr|JU?F{(@nD>36-L_kV-F)ev=jb8EPAx+ASn>2I9s-yg#FrJLem
z!&P*>9NLGgdh_{s7`t_^xz>r^M@;we!2`!=TU?iuU2i@!77p*1L#5QcYsJhT)<p8s
zYtz+x7pVij$2~o9>^8l{udKuORu8)Fb)VsboO%K8#ltSVT?3{q>8%g>3!nC-WlQRH
z+=-(`Cqi{GQSvS0IZyvhp06wl_xa?U`gmXu4a(<j;ds`pde*P%vv0M}rDi-VQ6E*3
z$6pV!)-%!?6aE~<uGOD|U%L|FMZV}=4<_%V-)8Eq@zru;eBr`axI(<#nN1%Mj@<S-
z?ranb_261d{>cl6W-rhm<LkW3VZRvKfXnudWJ7U&&iuHwokY0gDK&{}6rhdgOtz-X
zHrbqCXcf(PH{C7<^SvyGyWs>{^(UB;d$n4-hBd_<`Zc)kIr?wBT;2wY9@?UJKFl27
zREu597vHE&PpT=tr8|A^YvUhyCtSnJPrRTfHjtK+8!vQ&jcV+eIGQFm577D3*!_hf
zv_%`Ay(#8t(YxMa|JV8Ss2b-LImw4Zci|^K8--{0u93IL?75P!BaCbJMQYVM#nwpu
zqu=?>d6T<4HqpFj$6w{@NVxQ&*ck-3es<pv<V+phz3v@*3AS5<7=+Jgy36Il7t8fL
zN7Es-)jjMpN*-impQBgC!xhDS59a+MAMX+u7k}tkB3w|f89niuep)NfcfrL+A{_<?
zipag|_<pPWJoLErko#zq^XRJ{*8AX6Uimp8mIz(vs2Sc@)5?`W&xyGv?ni%?gbfGG
zYsfYF;XdEETVM7?y$?1iEuL<~$NdV$!~OiwrwHyVZJmw(4$p%pFsCsryF8nkxUxEN
zKO8>+!#<_|jcwn>`XqQ@m3UmdRsS(FUHvvJ7IOnnsE^Ef4(^`y1+8@nzp_hhd3X;T
z%rs4}_zc)bUtRf`eFyMi@p$!5b-4V3_wziWM#ojp7gGyl!T;=avmV~s$MlS1c(jtW
zO0lsL5A5k5)!+DTj5>v`8NNFfy8eOF56Wfna!nU&50}HM_G08*I;NJjNx9Hsv>H{e
z-CRY#sGs`b0(%W%M$Mx%PZ|3tucHIS{mcV;VElZjl(CAPPridsII%}p`IK8uh>4l%
zvdQvgq8whYZaeo4dogd)dzHrv7O?$K#^IV39<W#TV|AuD*!U}L_!s_n{q1@jcRZ`#
zR#_bgKP!)*(b#@o1Dd8jKb@sc${g)0w7>5=cImJF&Ow)}1?KZ(rQ-20w!P0jqtWN$
z@8dA9D6P~2zTxS<c<ys?Hp_L7IexkN<t5s6pxisRyZpF7eJ@5%z~-ms(`Z-QKcsgs
z{HVEz+wI+~L2bmNV`-Cm_H@9vN=x;6epF+%f;9;(BxAk5fq47~PyT?LVM|51bvu5&
z?m=tA>tQu~xaDTC`YvpGS)7W`=U{N(DPreM>-zGlWfMJ{x99<yZHSn9_AJ=>r(YJm
z+#6I}FWX^zhHBX>MVIErK~-+FrV2k+U!uOmQSaPNudRe_g=p!r>NL4{a)&*lXX>ZS
zNQ9zm)X<ly$LGk!*7TJe>LS19jfYWU<fSoszPWHF8-GjVKKZ;oUiD*P^=5rjW7xc%
zz3<1zuj=8P&4yyUr<@%A2TZ$Juk<lmM672s{*Kl0jXbED-+7IlcSIbp`?L!D|1!<~
zjyw=Q)z<3SXNL#<^kUdyCcNHtued6sCx%;}uA?X3*`K|%ifgVp3pWi^SFE<5qL18@
zM-^VztGk?5+Mp+8emil)z>@S}+#Y~0<=sPUQ(NC)mHx+%I1Ja`jbq-ggp>XIZ@jfd
z%$;?J1}UXhR>PE7tpAX}`}e}UZ{$r}U-dh7Jb<S<>yfk*=bx&t#w5Z*I5Pbf`NWpD
z<CdlG#6#EDy&qUSkGxTj7j|5F3#@!VZ?BL0!0fhV5@8A)eH2FA0Vi*pr)OCw7Tzl$
zXEw^utLS+7Gva4<sbxL!4(luW4;9r1QSYo^2|kBmH;BKQaI@P&_WIfH6>YZW-b=qc
zE1td*{xy$<xdp9lw1APg=gIu?lm@5-Z)&Vi&rS3!*;Je|To1yvhT-Ifa(UL7)`#fs
zzu5JO2d$Iy?ZiB4o*<9paFro`KTq&)pUDpVy8mt3%RSFG|L*f>yi4&Zd#|Od9?Yi4
z&##@HrFEXxx1crJi=k(K(6{P@Pvy)IdA|E<zcD#I7Ao)6*AVC9HsMlSm1i8Eeymnw
zgZ*E~J6OJfPo`AWKW$B0kASDJ_^_DS(#Y{!Y5v=2N4ebLcfJ4Cw69~EAA-fWcZgh=
z4<|obs0I|fqbtf`-~UAX)Rx0L*grnQUfwx$%{}lD-ZXQ)F6?l3ePa>Jxd*Ft8{%pH
z*kP<s%7q*9#zH^5eAjmPaTR;-(p%1H-^|Tw_V3wE?c9>j$|S_d3-+eoBtBi|jLXze
z1L)T)^fS%38hiD5QGC>8OM0WlE$Z)Ca2Uot)7?IeC#>%n^J};z+QYcGtb3e6)6I|*
z;$~}G{KvOHyupU>W;nYRaE+mGva#4G{*b+nQxjnsTx<dRdu6e|q=~(2KgGj7SeIoH
z{r;4GlNz>4CBDD~kB;)EAslF==OBk(^xa=>pk?1=lYG`JaLZFq+s6xc+rW*n;`35m
z{Y`#cXwFBj*DL3P-9^-0Vtz_LdT|N-E2%bh{_y>@%OrfIwt0uf?I;eL&=iI7((U-N
z%Afk-OXaV;oe9h1VtPv}z0{`GNnp;HS7@d465;n^F}*TtUvTSV=l_YDo?Yd)AYogN
z>H3CG(1RUume_n5wmc^m%ERbSTz_H-d=59;%Jn&oXdislTrcXx19GV!UcfK2;o!_8
zuv&gJK0|Kp69>1b6Xn3XdN^+iEOM_WXo$O>R~z7p56jW0qxA#2S+l<jKXsrZ)rar>
zYR{taPJz))<W=ciG~HBr{USVUuYQ6*@5;&X@b9nf=5SQqD{e2CX5VK`b;)-$C)<`=
zq%OFe9%x24tJ`j0rYGdPHx#sI=py}<-|V*?j$4XYqxQYBFYw#<G#&l$7MpxYujQZ@
z+luA)U}ACn_Yq#KyHC&NbN!<+@I9~ITNeGUIr9BBnn~_%{g$p1dxs9mft>Ql^}f9Z
zmX-1yW4@9N2Ftk`Vlby(Soec^14s4aa;e+<!}8rQ*}R`UiBs0=Z5`liv2cinIKL46
zwZk5g?6m(jdh`g~7B_8SPo8(9eg61gEwJ^gSQy4{>zlI$ta+tQ+#U~qi@m3>fd_wj
zHb?F8Tx-{Yle=L`mE-Er&(%%O&<L}vN8S(*_0OT1M$&8Ib_jpHR*w#PG4iRrS*brd
zlMe9jXV|yc#n#NkRyDEM8Yi`;6OKM?OjlV0<BwL0L-^w^yf3yVABW*`JgQ;0EQ)%W
z)|2mpRa0QVNmwvi4$JMjP3<S5Z@QkX-+I6~urf1WH{Wh;fnNG}E4-MiKV$Bl9;b&I
zTmC!S@26&_d1%jSJN0wm<9B_mXZTLj%VOa(xLB{K&mWA3vPbMi;lE4i?7R5(D*A8N
zoqX@yqI`J$F`T}SUJz$D97=@8*VCM<*^Dk)O5?4<OY6jb<z@8u=P-D&8lta0@SBd`
zt8V{V{V*gJx(?Hus%{_e9qPL;5}`tlcqrN!|Mj-t{&BpyfOcZrh3>iZXWY%EA65}(
zd|06}+`ZYF+takomGT+J94oD!=|D>rRzqE=jy8sIFTv%aaA=@9VK&ZLt7jmG*S53w
z3%AXoqh|l6jxA@+N<3tBo%TcZuJH8<`Lre*uER66d+^6WJjD;6z`K`P!rMz=O&+|D
zpL>q-Hyih_;hChuY5_5Jh1@S82d2Cx|Fc`qc~noJ0h`g@MLStrp``{ia2+vT<PR9Q
z)}9R4eVVo&K2j~W%-mdeRROlB<a@u!r7rZ)#n$!AabgSk*Hx|Ymo={`t`AEZ$;W1Y
zs|$<Rn_HgNF02=@*WPw9I8q!mZ-L9p+HcboU$c2tw!YLo>t>>R@kLX((dAP8xR0#k
zoo#Jvrk>Y4J&p<P-M}7=*?Mxu{HPo|iU%StnD#o3_|Y16Q@Qms49rbWerv8@#zS>{
zQNJ>c0PnJ`qc11vr_cg7wUt{B!<fUkcLm)Io9{Q4vmHC|h@8R2)o;>QR|n1bE*7fO
z;BUjfv&8qg$7t+?oI9p2Ki~CF@~ixAxF09U)w}4pd@$~-<>EUFP5c{2o@1>MmUn?0
z+Z?;kxuxY{pS$(k@bB8qwDCaK`Pf?BmoP6_6X~R;fiHJ{N}Er|rFznRd#Wwr_(&WQ
ztzTYkZZ&(rVm|(1CCx9d#=fmTRt%39(x=Jg`5N4CZ(+FrpeIgLhrym|AM!h1`C&0m
zd{T~Az%}xu&ExcrxOtRM#*fw;5_^wVkcYH!uKeQEoI6J~<XXD)WzU&ywg==L>r*$0
zOZFL2NxtWSk7Z%ii}oYlsy45V?}ynNj^Cc=`)v#D)jx+%kJ{IYgT_8$jZ-}45mSZn
z=+Ae-p>@_)U}HA<uwR}%0LR{(pw}q|?>SR!zb-avs>kJPq22J+7>BXnMYGM7uXFQb
zmtM9hiRlh%jRY=vjGx*r^=!&m*mMG(erukuss-q&HPwuB93FcCR;fi|uxT}$kK7`@
zU~FGFaeiHPI4^|Pap19u`qLZWFS|6o7ANDC$JAXviTh9F{D)$&AYIVlJ-OHdUhj1;
zF<%;Pv@dO)cRZbYF8h2Bi^_SH3y0qOf&OVOy^!{D9iEn08A5f~7$5HYe6tSLt-&(~
z@mDVzq?lOf0{2g-^?ur*2St;AJdJ-I)vxWZUq4uX<a@g5TzhKqTfDKHgt2FLb^Xg>
z4E+2WzCK}`<*FH9DVVm^HUDO}d+c$#&OC3lr|CFd#m)oq$BIGp0K7ZrT(%cq*}sAp
zqv-sSu<<Fql_m69Uh$bv&NQSgw(%Rx$$B*$nT*5dinF}p=t6ri8-?%<&3QRLEW6(|
z8|sPeQYRVX1I~HGJkJqhzrUn+)=7@ywFZ~#8CH=m@^^zew5MEYGE7~_KDRW++vc=O
zehi*w9~eKE%SKCmroQRuI_^{cBmJB4w8j#1!7GczU%u=0Z18RFpf-9#94<)Xii0%c
z9rERX`2Bo?HOF@LRJWyTa9|C&SkLwIiTNB`j8|Ok`9iMC-)ejG>2P$TI`Cr$eFKwL
zi@)~gtAVD{;kO$r8y47T8%;i3v5N-B!vpu=hOOT7J`Sds<JaQqo@Q#Qmawd%KKYk$
zi_M-9XY1#BJ}Y-3RPRWa%#!zPeA57Wwj-SR!1ycUQhH$_EjaHo>uF;4es#^svexLt
zSdNRWsolZHa&Pp@una$D87}|xsd-n(9dZ2k+j=~+?WHr$%`4Q7ztOw=v;q&W^PO_7
z;WgYE$p3NUjyU3sgg&S_f58U_uTsx6q$ADy$a>m@UijoMc-mC&t`+TfDK3AOHs`Ct
zQ}jR1RO^hUi}&&&9Qv#TZNVndx^NyGw~*dGDK`t?g$Z(~jT|ccfL@}%+l-+Dhr-Gc
zF#Qwx!v4EU*=z9~UOHxt=0f~R`@DZtEYlLXs#&vIV@>5;_jy8pOdQo?k0YD(;%MIE
zIr-{meSz}U@~S$whF&nedHyDS*uSmK-=qKI`UBon$BWsmFl!1tKOZg*{lOgB`j1TN
zB=fuH7yCBF^J?|~@(ANgh<*I}B|e;)#~iECMBUZxxS+H=UC(cw$BBJ8{LxH#Rm1v+
z{9Gok{;De83#yZhu~2(^x#ekz1T4A99%uP5>KEE+rFH#3U{TCH&cyW(TFcx|r%%+2
z%%+YWY){oRb@&~83sb6nV4bQIENdap7SYXecQgJf@QGe)UHh3D>9@hYaE&^zJRYG{
zdKmwOU(l{uaPh;|I=+sFi^NP0eDPC9_AIU!L8mPE8}}}RL%sC&s=`lkbZDx2t)jZc
zxN=>hCy-x{Y?(D1JpcEHYSwCM!o&FNYCJPf?LHm1UZM{)g}vNov6#(;{}TOZvuo^M
zscTQ%czX@aXL=8s>^6OBI=(p^9`bGoPnz34{L#wz-~GdS=GX2IYlrez8+Ohj?kaSl
z{eEDN()4QyJ)!St*k9?cY-0RR{TJiA)O{~sipzYz*i0BhU;KOx-i8M);ohLG)~aCX
zw=k>kG4-p@UoEQMH@_G^3~ZqPSzEq+#lI!>NZ-;U8E<{&2DN@ux}>zaO5V<A-*4}r
zonhLSBjEWLbe-eB%fIPrpDFXr$^5sm$-TGh^Db1kj)lQ(%+uT#;D8pNu$OBd6MOA?
z=yS14-KFZHYt+L(*$0pJKNNQh<VEAV)C9R*uON*2R^M5U|NgpO*Bv<S6@8kb;sORV
zf{ooj63;yn;r;^lO<Y04pTL)!tzrG7j;ew~cHuMk90>a>*HaJDJk@a2B<C-<1t#~T
zWeUeb4|zIcg`UU_{1j+pJTzi}T9J(gz99cr(|z#sk=O7dZ84Co?u83=_j)e#Ls|_F
ze)YI{jgU`eT&tD-Gap62zt{|C{<_&YiD-|lKGFNucEo$*4f=)Rx75vSvkRBR#QAgL
zY>Aq2m9^9B_1?xBuQ=;2FKTvIOB>I|?fjA%wzJ_On&kGz{7oO!g2C_bMeCd8#|8BB
zN7i-z#1)l1H*-|n;?0ZryI*mBp%<372;q10y!H~BsyrNi5w`!T)*Y^AQ_{NjBi@aG
zV;il)@7wKpc^ap<-r)Cedv&&gEtOn%-ka)=Rr(1#^?-5ok8)&#_?tv4RXKt;p49uJ
zjn;gn2a_A0&GwAWk2DUhy#y{Mrr75KE8qGa$HKCWrS%nGvG;Kf&9%!~UrVuhoc+tw
zkZt5-UbWQKxNeg*<h*hKcJ}+3W^v7e;^yh!^f=4G@XC4_Z1(+mdT;mXQ^TqvpW_61
zbOb)V0IRmczlm(W0=D$IR4j{^rOv$@rxY~)_C@Hj-S(`!OUJgA$KtT7eCxB!8qBrs
zm&qD7A9T1#o`}aT@}%xxa_DKb(@6Vh@3L;04Y$>?Rwo7?HII(`yh(1qD%L;Ss6QbF
zOMZ-}XqE?>^KY=uTEX*Vwdo;P_Soa}O9eX3cT2&LruuAk^1~OrJ9r50?QfkCr@pp;
zmf^P-TjK;c{cRz2h&-Lr+3$-E)*C(_uFJV4&!|^xi5ot8t^_<Zj~;lnSq?f4cRlww
zzbw*oF_&VUVR(0ae`6b9TwCOJ|0Zh0uk?;eshjZmA+dZR?m3U%Dq{Sf$?3VjxwoD`
zB0oNoUtM76J^p)sA$3k$@xIzxw{aiJMJtN8iLRghURnYM)P^@d@6~$}Tchgw{W&#G
z!vV0bGaXT!AH~big0v-G{fwV}%`4Uis0q)fH^k~E-@6Z=#~&8wuz1zAY>?fYUGE0i
zI+51jd8>WWd^c&c=K!YKi*bfNRCoJ9Yr*5y`Y^^__^8@xl=@*JjQAQ}u-n=y;#N(O
z7%Eq86N4~y?5%2j<E*{WGt4*YWy|>vonR1MGvTm4)n|M%S^avs`2NOo5ZBlXQ8B7D
z>{0syjy!<dx58+gTI|v2S#`fXc{|&!^_^`v_$hV!TlC>ZbpourvW7gurH#c+HGbaq
zi}>0o{?4`bBv!ife?jpx<R|`A`+ZZuzPuv(ZR2UrZ>$yFW8dd<`pfV6Za(`ndec0$
z)sdIMt*o$Tz1pHWO+1vghKFn3=TCNfXOo&woaB3+53i*y#Lt;oX&1S--aKyoL7%>n
zx`oESzO$b72G2m!*AL?VZ(i0jgmZsAMNf>T_wm%bxzx)!;nr&Xw1W8WpkBo#Y{pIx
z!nq$8(f%)~1!3eOvHRg+J+SF=<RN(|=B7PqFZWsEMLczf1-~B9<9tS+vZ=b^4_E{T
zH_otMe>^_fM>n+Mud4R4(`sAg^$O!&a;`dE%q=`efA)a&hAA{y7Cp3%-ZN3ocnev-
zTd(#KW7Su(mG4h7kAAahzzg+q&Zgn2SR000v6iq>{kt-#tGd|#e<B{bUT2@_RBIRP
zzY%vg-0E4zV)~x9<4QKox1XjqhDX-m3EHnN?CX4=^)edo#B1?T{Ze}hOVDrdtY25(
zgVELI*#id$cMj6?I0jeD`Q=Znso&)L;{W8!IOGkzTzJ^x3w>OEt8fkshqu4J#AXlZ
z(ecM37`SV(p2tqt7-kKRU)t}Wu_FJ-hg)abOJOWiW>}lAXx@&$_NaB<HF!7%8~C#N
z^=fT-e{%=5@$azYPI)UP&zoky-(BpDE3WNk4?`xJb2g0y)3ebw8;$?GWpL?Yv355;
zJ&AV@=%K>ZXwBui8(_G4Yy55OHbnpb1O1+F_17D#n||>O(QD#GF6>>Eu=#{mmMeSV
zZ~=3_yMeeiw@nYzUjF<n?i-7pV!wz9aofN-_mz!@nH9w%Y?$WXhs17Cn6eb^RJl?=
zUwqcYNxfUzQ_Jpme+*k_tOGaFcVlAVT6OoG@aoSBG(mN}v6lLA1?WxqcJ1HhMr*7*
z>Dh$tYR=o_O4J|NrcXARKE8l13^dDwbSk@Toi6WxQTOeTGh%zGc&IIhV_9MF*ZOUP
z^b=s)4tU$^6?>?%t5YVZ1-e={c+y&YLcL=Q$LWD5e$XQ@$K9`Z27E7mhfn!_vnLWy
zOwFY)sIJ=;x2F!*UT_PWsF5z7Y3vhV1wWS-CubS|AXs=k42||)9iYKJ?IgzG#n?Y-
z&-qbpX;0jv;_O||bc~2;9$Hu5Pya8+)urLjd-n0clJ#(K@>{-hD?c0G_aEbhE$mcO
zUiP$a@=a^IHSzEx_9wTB_8-GU*PBE;moF>_m*ec7_Uq9^74#3Xo@+g-2abnrFZ`%Z
zY^bJwfJO*<16{;NH~4;!eLE}QCcfGKvb}7y=*m0bM-ezr5A^;T7LLK|G;qZ{IF%h<
zDQR5~4ix{C&cXln<m$$}=FD%cjq{y7`0984HuD(Yo_?tcGv7D2ZT9-m6**mR)h6#^
z*rsp1$MY1=S+~fqw{@L8s_kgrx8Z#aJWXG`h!;j0OIf+td#qmj5w@JHZf_a=&3}{Z
zhrK#Yi+-I)%$VPPx$qW@ZH8yAaBeAMiJnm#q1SRE@*6B&JC2{l@e`HhOFnBDtzlh$
z^}F-l`YREtzoJKRg03B*hFc4J8{tj7bT9jkg}0;rlBW&nh!*tMC2;$wdX_$j-nnx@
zQT7{Zje@2=Kxbc}FE-S@$K%BFzteXd!jIKGpCN|do{f{`Sc^jJ&>5bKmjXHP$O(HI
zapn)OydRw~9FESumtQxqBkX^5G@HqrQEd0?7iuWBto0?H6LZt}AoDT(IQh^CPEWl7
zUh8!<{T=SZmQ48T@h7c${-H11L@fy$FL+0<zCQj_U!3Rs<2d2`dARdIJ+K+}WsSEk
zQrTYDZ}Hrvv>A+<>HK9M=^=MilhPS^m*A74`V<?~kZ|EXnxN00>Xwpv^`l^uSR04y
zBJQ}SxEdp$Ud5~CH$&_#hfT2Wi(c{^*4!@^kG7IeMeGmkWqo4-K6u}M!<41$C6vNB
z!{F9(c`3H`!jyKK=?Sqt8CF)DBW`ifluB}Sob{fs^ykF$vSR9f_<v?&`?{Ly2f~X3
zt=Q@_dt;x1O*o)gW}msn%rE7i-pUu|H;{&Sx|*Iq9a_`5HyhVeBlUG)NN09#eulX2
zV+~`V=kHeH>-=ibY;*!Uyuv31=IPazrQPSy6k_G#>7MzJzvUjV-!+GP6fafpSKq*q
zMw8U5jqT-_toOc1pX@1XawlnwX~y)ncdGnq%<$tovD8Rz&yL1*yE+Hfccl-j%HNLD
z=nt4%3O65PgV$)mZsyr!vD%<Ltq$ii8PiC3+T>5YzmkrvwMI*?ZMaih#yu}{A0EOf
z2lNmAoD1K@)ug}G#^>qv;N#K8^`w8l`xHzu)=Y)0o57||&8!R2I%RH=L%5&?Ui>fz
zpR;GKNA>yIiHpYK<1_o-*kTS%_R3r_rWPCkyUJ9-&38r5FvEl1>d=LHAh}^Vz4?~d
zUA2m)rL!J*LqDM+|CYh8G|Fy&NAG95W2>IxLpWf(*t`xO`OY8mGS~0cQwzchJ)EKs
ziaj|n^hPzKI9j(<jX)RX=tI-Ww=K`})i`?-E>b_yiQ8hZY7#vF2lv5(=|}C`Y3dm+
zv2s{UU&xOG?&a@MbkH!^w2$4Fz=B=&->acMA0Xc@um=cVd~(>*Asuuc9~67V=X3PL
z@!WfIZ(lcco4(9ntI&kpnmH_l<;RS75j`O$G8cBO0<`O6=J+X$zFY5x&G%>b{3q>m
z75jC@kGuK!k~a23@#93f*Xy``^;`0yznWwwzBP|`OXC%}o&6U3q^`rMc|BV)SpC0L
z{IkVXd8|{vs&3}DZI8o+EI3DB@KZUon0_40=eh5r>sF}K&%^y<bZZgXq^b3SqH01~
zq~nkJ(fe>DUYRt4{yz)f7tjlXBboX4#Cz6t*QiatXU7iq7Mt^jRn=8v(=c?ou@rn<
z4Qh<9wv!9|Sn5rCNw3A%@U%S4F0|Y_0^UA6)ZXn2>CfBL0{i*)X<C(!R*0Q3u5rga
z`zcqOvmD50E@xb)|NW!&&z^LhYh-#;uWJG<Yoy2VF^s5T58B7pzxiq%jCzxAv-(as
zI%Ox_zH5x<{d;?d8eGjThxXH4({ifm*>T0Ya(<^e9&T4|;@OR}J@eWDzw-Z4c<{h@
z`FQ{?MtuAr96jG&4?5)7J@V>9??_os2kcXa&C)A;Ku=B1G&)~jLp+^%CT)F8Z)$@+
zAx*os2_Jl|&V?0cJ623i9NsDS*yH*O^y%r!kLCB%FtXqp`%=GDcZ;*y3*`l$abI}6
zt~@r!ANs<|2k@dCE|rZ26;sWRs<F4wcxs*Ky&`9?vEC<ED~}W>ufe(_Fut{Z$&>I;
z?fBM8JyrggbI2aZTVX*pxju^qSf@|c$sY4AYMi>xzcvxNejpx;z@YhbSRZ@qc3EdC
zZjJ3MYyIb#LuPAn;$rPxbofE@yiyIdjNT|K-)OM~;;(&S`;El%NikKO?<db!NA|T2
zwHf})xhH7lzl*Wm3cUvLb*<Qam46yfkT3Jq6>{+Xf%=_lt7b3To0jli4m@z+C$`ya
zpY>oIpU)n_0r;T4m^-Lmz%SEQ>I<{?OV3)HqAQ!j?~g8|eU8%g7r57*ba*Ek{Z>7_
z$7zP^)!Fszox^i&K2_sCA!fG8Jw90W7)~?iGJMlk?riES7S2+4%(kC4r}tm5?Mzry
z@N==l7o|thkUQ}>4fGCde<`avfsH>9^Sfy24h`|`EwGgTuKAk2tw?h`@0ppO<zZVj
z!FahSr=ohj`fX~-+P<rI_uv)Qz3x`eRG?es){aVWs+4snvC_Ri4jPHCKbKGN|66+J
z64+C=y4o-kUdY5}V*MwY=$q|u`d9a8j&JGCJ0BGH;&e|-$Kg+h#q3ea^BFK{h1h*W
z96Wie^Ino~E!dO3_~v1CL=~DQp|7);CWhnRR@Up2mxX?h_LJF*Thtol74$bPw%}sD
zJATcd!(NS;b-(%es{<YFoT?YGPc<=Zyg3eAW1OgO;O|!o(bL8C8fU55x8Rv_-e*Z4
zZiUe+huC-awY7Qi`QqF7%eZgE)8%2=u<2~tjHVPn3$C#qCr(~w&);&`Z}y`#JJ;&o
zfDNC~ugxWAf0Cy&^eskt_N_OZ6mxy9^_&IYwO>HXvGFJ0>&NiJR^!U~2wXW=?BkH^
z<&9H(<)WvWo6B+ddM}N(CQnqi%2z&|{1t6yOusi1pA~3v{Ix%mp6XZZ*1~wdx2|(J
z{UzBSgbf$V^$W$*bG5CxyvY9eCT|Yfq!x^?sZaiwvGvqr{~6X-;;)DGb?BKoG{_9L
zpVNzGUMv=Ag3mYU{o<L0#`{@z^&YJG((xAU#Ozd>f0?~NKjYVVYRZqqNG<ogOb@TR
z9()%2cB;$0ci5(nT%M+n)Xz1$@@*zHTwV3RO=74HUGW~REDtBVVgDK)=*Yik7gz5s
z<l~ZR<!yA*)$j&}9Q=@OzrZsH+thq`vgh;sbF=&1<=N$_a#?(zFJFd^vsM6Sp11_R
z4&=Mh_`8Qb99!o;BUlI3LxrI~y8iF{{{v2Kg<GHcQU9l*7})HcI&4#tR=BqvF1r+-
zs3oF(v<G_lTt2-BTUx@$M_i||`E{7AcJjU6hpn6HyDVO64Phi4lt;Ta;on>IAoynH
z23iy@zf#_s<YaMq22GWhU#3_;8DvR^f2ZzK^X<_SgN4s8^!&bhCffi#CVY3#qxQSW
zrD?QDeq-%p9Ph^UViwuM^aVZ8!rqZ}G!{R!sT>bQSK%o<oVy;b?5>Y>y?RRi48Gp8
zzXfUKTlMhIfGacPEDqjhe)-(*-r;<l+1$3vG4pK9mg`~6-(&SA>cC#T+lKh;sz>22
zf30=D(p|;S6kI}+cHCq?(+hIi_%5R_Zl*U2wsNnJ*bo-4Gu|G9<c!Y`4OI(>%ln;w
zX??l?7j~&+j}ZMaksWsyw%22=eXYysi$-`zY<0r_B}cmV)$}9GI(!igFE)n5<<_vZ
z(lK}jABU<r+T(yci}Y3|*)R5tJ?`r~<GojWcBAL_>9M(1*=LNCep>Yx?3d3qegE@s
z)NSX}Vz6%CH{Q$fw%YqVdi*(SoMSvkMAJSiUpCSh-3P#<FYHzBp<X_ucRElVc?qn!
z!`h(h%@TiKvu8v3R(7Yg>a*-?YivK-HoEW!dDWesHje9IX8odg`6c-Eiq?*KH89S5
z>fsx_bUv)QOCR9JQMmVUeyz{v_0@3w)RGJ22^;QwH_*bcJs-TSjsFf>a|qVndW-oc
z@~f5@kxLP_{k<Gt(kt0tbnQp@^GoX`eDxUo*wvZtEF@lW#3jG$YtxLKy4zPlC(L!;
zZMUd@`DoirdTu4%^N!ps=ela3^XAh<*TT61;=F;nD7R<Y;Lz|ZtcSG6r(48TG1^&7
zUnMtooU8A2uKxFNIVT1;81uX-H0C{GV6%GcMz#I3-gEbcycVC6JHtAhv}3>8a=E?{
z+g@}du6f0MoS(gmcr~8=IQiGJaH^VjMM=GjJo*bX)CKZjK@NX**mDn83tUG-jpM(r
zw40b**oDoDc>c|`zLBTDIsf}D#@<2SYM9vc-TCjU7ucYZ`5tNno6K=eP>=H2jECr^
zCiaTHVGZsVes~YJ@1Y^G(8^-0$W`Ltxc>ei@tH*rYCUb*N00JKH3_Y=oA$|5%=53G
zInLgf-)SCK(HDR7rJA%!1=lZ)Bg8<~AJl=X>?0mwt(h&Ob@`lX8JnW?&Go$D$Ru2Q
zLN2u{8tqw9lijO_VZO7>W0BZg@tc18blSIqx{GdYDxZg&$EqT7W*BWOUuWFGr@!dK
zJY>9Y;YE0JWEqWl8x8fgzS>o>P+bl!WUDR<)%%api1Kb3ZTG%wfAB19z~LXY6mJ`?
zd#v(|#7THf*JV;$e&^mR;bk5E+|9=^+Wu}i@)XRtK<#}ytvBVU=Oe`1r+27%*?cM<
ze}etCUkn#((&j(W+;ZUE`>lumqEFq_cN^&A?1tArSijArhUza5#bB+U#qMYReoS45
zNACYf|BM}$xX(!%y!VYX8vf3EnSMG9xN^GZ``~wPxp!7!y{Jr{-Nuu5st=}Kj=RL{
z8CB`FGPrFX4luXR;Q3tj$aUx8|FhKr*V`L0OdTN?s^r!Sg_RxXl8IO7U+wX%&`5r|
z9q->~kIwga_XHgbD|U+KDTBmUYkQyh<IK!rR-W|!mJK^tuYJ*)4ZdG6MxWfA+Lq8)
zn4v$|gl5OvU(#dEibiXf>fm?nNySP126*>bEpfb6&(a*{zJsr7)4SsR<BekAMLZ7E
zZ=pxN?g}5K>AQce-yr9{fG1VtYRQ;>1>EgkM()e)%W=*_AKPzzf&OG>K4R})uc=4b
z?1hQ?v}{oES9Nn^J;thZ@ICsy@VF?=w5FQc+PJe7fQL=hsh{gxZ^D`QaG%_tn_u6c
zoW0K{jd!Pa%=6g_G1S3#&z%6*$HIj+V#iz-9ESIgde78$H6D&w0$c8Z4`<?og73kG
z3Gk%7IC+Vd`-<Lvi6&y#ciFTE4x5%8cAdqSV(h81{Q0o@rKQ^7eS46G%XQe<Ni04m
zpZC9v&#KcT2VLuTdr5NO*J<{pvT^i2>gSDPQ&#;N`Lv~soa5iOX^;yJi|Kr7TlShU
zS3R;4hsp68uhN2r)o6UPrjh;WaojnWM$Asf$=#Aiyhpjcb*h}!%I<^#xUx?bcs)g}
zeHR<f*TcFGM!~V_o%E&HetSpt`C{vk_<P*d))V1s@n5ZJJSks4RFAq}Nps!!tU9@?
zb->ByeS`kZ&3Y->?3JzOJ0tXP<jALN+9&84|1Ljq(t`1NDHYA>W4uAzT=t^)I_6z$
zy}chIzwd6;8#xc>!ljM4|MSu8d9mm1`_m2k^+Mq08#LG+en`+-)8C}c;ncn6*Wxy7
zmdD}U8R{Nf+^(i)$9(6<OYLpt%aaRW+G2TLM-Az^7k!~Wd{SI3wr64*op!5tA;R%q
zpR1qoMWNTkq&g?p6V}1sfhEh-r{ba1t<GIRFNmuFUs`wIi&5f#!2N74kKTBQ)`D*v
zmYCzMFnfi*1Wk|!4o&y~jx<m^ih<|4S&wJ;(s275aek<v{i}Rl3wFNrA+EiLc97T4
zvq|n7@Z4uK_gL>Uam{!8>O-GTv%<gOFX;DuVGlg~yY@Ic@Imw})VQVWQ-j_v>zVjR
z?KdqzLyNVW<ZM@V>@R-Xih&t(*(~U}u;Ecy@&$}8V+_B+`Y&MD8SGMBEEgBocmAc;
zGq%k?`0g-#pP;+9z-qqAdba1VpSD-mST;XQFHY94DXI4mrwQa-C4Q{jiCt=1mtU$M
z;mZs8uHY7W{0TWDK6=cS+c`XYc8NVj9j!Ag)JI<~h6|~u2dkyerHAEX^qgXBj(*2F
zYkd3cWBS2!!o6rQ_|Phs8sDFW@Z{hDHIZ1YAx8(7hZhsolJx(>m(s51(?WFAkU{De
zzPR3Z+ZGo$_0>r3KY^y1+gPl-)=GRhG*7hG%NqEt>a`2S@ki$A8jlT7*U~N9Va>cN
z^d`mqS>`(nmu2qm{uAJXSov{19X3F(skMDe-&r5I8^82XYpllO#yRmR*ZkBP!#FiX
zLAC!#{3hRO%afIOZIAdn1IHG@ds+HN@656<4$fB-3kUPbjh6J@H+q5cb>l}g&rPn|
zmzMY0jUDuQoHrGJekJbLl(LS@&hK<_?cd?a5qLI)7T2G->q5^;il1jcg`u~2zT|z+
zr19sSbVL{UI7u8{?eDi+@>46kvLVu+`o`jPo_n14J6rbRTk-co4*j+r^zdHKCI8~N
zo8x*QtF4oW!R~nYxr$<<mR?o|J@`ZRul=A;QxnJK$7_@5ts?Y%e|s3uq94zc1NVw`
z*WIyMZJd`z5*L@7Pi3(Z4)9st=>2r+&P((>&8arc-0?j)MaNb7Kpyr{|2<;=ZCP4@
z?TVF<C-27H0N04^vT~^mAAGP&@3;y-i2XV6sfjqde2;eoy<{&C?78zN&(ciQw}cZ*
zD#F$o^5si02+u0y#v8DC3cSh1#$)K8PfCdQk@`MYvkh!`{2cr_-I^C4mn!P{jED4(
z+QEP<G?050f*t*yr&Zv=8KdN-IdA5lP4nd1LfTh+tiDUnHygZUs~6?e>j{4Fr-Gb0
z@P~fFSNhs@tig)GWqkHYFIc@L+An~E4&kD<`uDWj{M%tuU7D2-XOvcFjF+!8%@t~o
z;&~FG=y1J7nEvTOHN?~M<p6yT1BZx<o3dI9_zn&Xfon_k&CKl?JYAMnezc}%K#Sqm
z3#|#6cm22Y3)s6MU+-UUov;;6Bad6mgI74`)$-;)-#YLndy!Vt?!{>w{h#QWvxf3>
zaz9)lANpmZlU<|20P9ed>5K7dkE8lNH>$DaROct~du#RD3iz;=M!D9r&oE%s1ej3G
znigLVsBb-W9sPj^T75?s?t*o#aPTYt7klRc9%Yp^{s9COu>m5oiU=ww20{p-C}>C_
zfizNR8+{#SCShPQ6K5s_uw!3Y``Xrmy<;!v+I8){E9%;N0lRDY|IRJ%yfYaP@Z0D6
z_W$6s?}j<=E$5zl+CBH&`=T$IyG!O1=Q*GGdX=~oxb2GWko$usO&~^sE*vo%zWS1V
zALM1vvG~dG(6A|;eFyxEe#Y-ziVt=leIIo({!9(D!`2t#&)w9C7!H1LXXvmH8F_yX
z#yt(4b}H*oWa_D-*gvN29}AF4#@&7ke)G2Eko2Z}9)1Kit}DKW#8$?2!*4*}Zha_w
zb@0ZMe$E>127QRDl|DyK)4y5oUId>&%SF$VzslUicz@7#oqPjhtd;j;4UNvaU=w)p
zG;GXG<Y&CcIiWJv?R$~)xf^tAL|0Ga%rW+HDsphkPw4owSl2P8nw@;U1K|B{kmGH7
zu&!uChrG$2KwtRbO4hZzV87mCKG0nc;qT4)h_c9DJv2Gu9DKo9tXsy=&O&U!-Pk~E
z_F~5P?s@1dbl5WN+cI?UL7%V=LtpnB0Zu=YM|lyt|7`rLcZq{M$lTmc4B&0n5Qjq(
zZ1;%!k(JYsA!sIhoymvcJLYC7H2eGme&ZXRd>3cok@xd&M$V}B05T-s4j6GY?ICx&
z_rU(5uUfiuHxInAUm<o6zxa4~rX1hoPGk^M;`{X9=-+dxGZ>$DGHbtI(aX=WSH?sS
zKN9<bU6*@qZk>yMxgC3k{4QtC??WfO0Z)F74*B4(_#5b=KfR3aRY9Xukay_6*OTb;
zBf;-Ld|Jlwqz~SlivNWSw%?173ZEn|#O^RB)$hW`w0Q|@LjP*~stdrCvEJW?AN4V7
zI%ENs@cnuoa}WGEZ0hz$@=YOZ<SXbN`Ho5<I`4r&=#4toPOstb-H3i3#oC>67o#^j
z&qKb^!M}Wu9zb@#_=>m+Ht4Pf>>2v!ar9Sr{Mq5(kUP<fSVk_f=sS?f7IHG*Ltdsq
zJM7B4*w;D--44A^dW{(7LD>DJ=!+2J{TFczbXEhpVi2Tw4Le)?2zy<x5g+^~{^fDx
z#Xd@(Rm}DC>^Y$uhY?S>d;qy56IdsF&sin(z(48tT6~^k;qyIn(a~MV@#62*=(MA6
zWj?oJFCG8t-C@MBX#b2o@M%s)Ht}1pnhB04v1W!xCjOgqSRvx2=*PLt|NEP>hVI7x
z!hP&B;1`UCmzUwAl|cW`4#H;dLhJ-x`OfqB$KW5j8h?mBe*Gu91^s{63T(-y*q7hP
z&HD|X4Bi~lnf=wnh%X$?oXp@n%~$BHvBXec1&6y?r=XudJCWGm71(9wX%710rv&{}
zk{j_cbVffM2LA;HqYoZH=I0>4Vf=6WwfB&##Yxtdd7O#AoE(Nzy7&%2r_Mx=E_etT
zJ)AKkZ-4!c`2SV-6UUS1gB^=3M1Ck6J{Z3Z-BR0=oHSxE2OuBGe`3FfLW@4w>{HRz
z@bkzKtc#)XaoCpG%)wL0!FwmLuHB0K8D!>f==lVGz!K*9IQ+^tZz0zG68jGP9<n9-
zrq|(Xp<65V!=Hsd`+Q4`mv>XqA@g2l9RgnuzmYZ0Y;teWEzwTg`Su(>1oroK?CguI
zJLTT)X}1&8TSa_h3_17<;Ne<gweaUR%*BPLv7X9fuks>dLDv%(1-E}zu_wwnzrtRQ
z8%(SX-q;HMzV0r3#;3^_d5%1}X~ehBC%(fN$KA}@gtGlkgU>qQ``kp{)|upqF6SJ{
z64oXUkRx*mF{n!RFHa`Vemwhp*qf`cLHB~=n4##<UD36DzzMxO4w}3KtykQ{zFmNL
z-b?5n^ilLoY{fWm3=wNYmkenjUdMbtIUnA9nz#shwHG{k0`qbAt?a#^pXFX0*^m7W
zdHT~t`06C|;w$XsqqqGplDiI{9DO=*jbhe^zv6Q|fsK5MJ(bJIlSHl-Z^!z5YwZ6k
z%pLyI7;Ib45d5a8=tA`E&Dg})eDwb@$mBMx8;+A0C^owcdVkG2jrkuAPaL_7_4207
zV*+31V%9{gA+CxOw;2gN4<>)(D8_I#{ti0#Xl(i0n-L?Szsjx9_j{us_hsHrB46ur
z;#lbRpLvF2?=PXw;olOY!RH%%vCtTQ?=xag5$<5>k3Rgy=R4qgbn7+b4Ngb@uEZzX
zop{b(@C34d`tHEshgJR1XUN#IKQOm-*xDzFAC<$;KjH)RLq{wm=5i)`ZSOPJ(0jXn
z*o<=WR?)lH^}rts;;(KCewX57Ur+oMJ9-g3x8>gCz%aj8jYU5)KSNeQ`{Cr3K;w$N
zuyN>zvi<QRAIAq`Y?sZ%7e_A~QiCo6@8=$5-H870nZsQEl{ny4%>VVs;!W7TDbRd#
zY}`ZmBbN}*SxWg+Sg%BUzI{IiPyC*L%_P3mle1mut(8|`^Tx0j@e#h?wX9R1sRLj1
zqy7oV#f1@Q{yh7D*WwEv!Fn40okF>G=1%U<?}H!I9lS5~Lo?d{%M9*5`jgxVL;fPV
z_2nwoP)C!$K<vf;5%U6`Z!p&B%=0Jrv!8Gmegi&i4`lxz(0|q|>^C2Z?)ZV&(uu?<
z-ej&nVU2*D`Rgb24{blhU%9mo8()c!UBTSWLWZ|tzR^D?`eZK-8GINYy_9wB7WnP=
zupWM&^)Ytp&0*LJ{Kn;{LZ^CiX|Ol5(0f}<NAL%bm-#lazE@ZWv$i_+b9CC%#7}s}
z!3U?^jNXK{1=ywsyAngcj5rhH{-GB>@L}Y998SFMS>&{Vy-n=gK9oNMx%lXK<{zBe
zTCgeb-dp#w4!NE+XbU!ffAX@fV%=0j_tO~z{^)}K>}A30y)kSH9>6bz*Bj2^OdLER
zUz@*ydB6K-<_0}|&tz!zD!g6BndS@dp{m*E+8Lh1=H7!1e&-DKD)Cdsfky*AZGZTE
zpMStB%UHi4zi$<=&S~MS*8*%Hzn^6e55hnB@Ez88tTk`l0$l)~?}om7f%$ys2mE>D
z?{Vb(SZsz5*gglaPK3sCXZDUKfj9Mc0_Ta0|E@mp@($#5-cOFf?OlBPz6H-F$elp1
zNbcdMbJ0E6t2c9L>v8lrWBCO;Q;D2!iB26fn0?AivE}c=PmF&7I`c2@!Ba)-iJV8S
zM*(qWcrEu))+p%vXOYDT=-XTIQO-Mx`xqJTMHA3*t(<dSO)UOWVz2Gk>5o}k?T9{y
zo(s^Y2V&Dsg{MyZ8}flYTt<xIW5!xAmwfC_#G^*RtI&G_{5Q5c{^IBG9zNUW=fIcD
z`;}wKGsEUDIt%~cLvppSZ(B{o55u?km^pd=YPk!8nCkY#^NzsI&t~5NzpZnSb?J8S
zIP-9IA+#$+uUx=d@FnalbAS7LeAkWsR=tfc!g_5F_<gTp?Be~ztB|WpRzL%Ap0FRf
z?o@Od{>f+X#HZj;wgr1@@Z!|*>?4iFmt}tCoW7jJ%;|wH1gED8@O77w&%{`E>PlR!
zFFevp9REF*$;e^69^UKCo*1;=8auS@X`BtZ3Ol!m_0%PtuR+GTT*vwhdr|cy`UF3y
z557z(d_EGoUv(P$HrU<?$N78*e9Agy0ecS>teKjy6JH>s*srdivKAkJOu;7?K8f#(
zt^9TqVwLEj&5y@6GC#4tw8uRBIs*S<74(0By-a+PA15P+_prxx7w>=O_h{C+r;%^a
zjs1czv6G8A+clka?-S^qr}$36p{!LO$BsRNZfGY~h>tTCzvOagzwP_1325sm;!u-l
z_sECQH|U4=7<1`O=x_YW26Wg_%ke{+@R6C5OXqQx@ksIz;PWnr;LE{d)6nxD(!Rtf
zUO1WYeM#Q!w)A%)I)yRb$h>ckfA{Kn?A7!j{)4O?v;{HMebK!$kQwOr^fk!&^~4VP
z!DF<Sz|S3cCHo=B^ig-PPrny28f@MB_$2!`qsx$icfTUuGakLlI;rz>*j4`i(w#WT
z?Zn=&7e_a<roRCmfv2vz3BLjRcP{O1b`JjDC}K3&om1i4kDez^`y~4l;JYdIXp84q
z|NMxKh9@7th4_CFKK)17CFbgKe2)E}z@Iq=eX%RN8N(O;Gi#KgtXs<1TTOEBD`W4E
zE;$Xq{e1em?K9e)ip~B4{1cobz^{Ge2mB7?;=W4ug-3Sr4a63l)6BWkJ<-v1&<TFq
zAKspPF*!c)`fBW0)f99F^R(YB#C~?g<^+k6>`Gkj1J?DOIcIzcIsX5~Cw+|d`%}z+
zf7%15OWTRFeN3(<Z7uwbHChjJ1?@kBJiU4ybsXZi$jMan$&_iFU6@I18s6DFh^=Ts
zXWqelK1dD%w(bpZJT6SU=^*HlB!)5){}bKVxE(o!lxf|bbrO7k-J9IK5+Xj&9Pfp#
z_#Ar755QyS$bGtT7G*Q?<+mhmj&Ht_`Cf7uaX0vC--YNQ^!9z|z#Y4E@g1-NIhn{9
zSx?=JK3)0?=Rp|DS6?%4%UBcbfX}fz_6I$5R~<NoI{5~cz!xXMn_=R<e??B9N#AR+
zHw!tR-;)?*F}f<BI2b<HzO}>%&<}E6d}0ghPW0rA1m~w{@2n$;*W5<?FXGp~$-XW2
z?Co>Oar}^V;=hOuPhl@_DKU0r{Dm*Me-2%D|7Ymr?b(;ZPy6mT)_aSXWBkCgA3+bE
zjgDcRKKf8}=m+=)zp_sSz1r!k5M44k2OY*-zIP7$Cj;@7j-@Vg(d$9tCFtv&zk?3P
zvu}kT(c^s9TD-fxfwAli3_H9zdgUB!)es-L6xts*hFBZxgt|s(0?j`u;{KyP<QpA}
zePix#TgihhpKvjIe)uC_z~|@FPZ@UZiQ%k4A4PuWu||0fA9N+Y?yc}(Pxflz-xn&;
zt-le+*c&>Q5Mu-H*3FRp5@;0VUgxukYkbV!&O_+z8(0Hu#-7V4WFwEb8hm{G$?)k5
ztjW-QL*T(1&@1~g&L82!{c^FL%g|}p689a)diXx#eaP6`#6A|>23`Z<xxwhEop^_C
zd5gOLyqEC6*{map8#Kaelll{bJd!+(CFqq$@V|aRM<K86Ls&n3j?a)!3<DeaEAP5B
zV1LoajmJnXJ8NF%X;<d@K6GjC(fE6n#9B@vet0Ur=d<XhJ%~3yhF-mlz2zg&O}}8D
z?nK`(rUwR-KLZ{7FXKnO0B=Lvi{RZI2C|<AU54%iExtj1!ErzI)o6bEUq^?tZg`G9
zB!Bc2e7l)r(7Wia&*9-|z1Wv(WqubEm+sBF{Wa!t8|aB#{%Jh>az`Os@Ysv!!^joP
zFJqjUOY8&rIcNy$l7q2{e<4N+{|unc16M*@%D=EX=g4}ZmzEL(?Lv9<<le>DJZ$6n
z*ou-DS^pl0-oF4p64~xCiT?YMvw;q;*_|~$a`_DY%`kkp6^AhQH*=<UE7mypMz8re
zi@PmrS8Q1sbR7rY|JV`UW}L4P?|Z>dZWVZTz69SJK9xIozI}tUHu%q5Tu<EfaPF>q
zRPGEQXJZlk`YJK)yRb*d_Fb!3JL2!m>QC<Ilf-;)#U8<1`!UXbD_Fn%D0|cR2%9nv
z`r3K`I+b!~G0rJ{SkFLLKe*qwEB?R)*3MtEp1T0ucMN_qblVyIa7Z6?3H&H_yLEHo
zl+0OQ<ozCeg`>uD7f~&-;0ifIg5E^7zps#a(|e2Cz@wia4?Drv*CR(a(azWCv!hmE
z|6hkT-N=<fPL}@}-+C2oqMP17yR+|rY4~05v!22p?w7;)5bVY1Ux|H$@CVS9k(=4$
zJdXW3Xjs(79>f63BCDJIfNy*u{IfGQ2j3(aLg#<W-t%nQOri%)B98PH{T@xc2|2uI
z4}2N)@QcjJujq@PdNK}p?t|gzf<0MNg8N0RIed3xbL04Qo3YjlFt3d7A;z)g$@mS&
z<43gN(_Bd0_e<7Xx8ggU&Ytd<#Mhwx6{nEn_!@E4rT8|;*l7n4t7+#9dI{^7aja2Z
zB9FZ*`+k%?=?wBJqvW47z?Tn0bK)tr=%e7f{2N`dH~!xD*oc$2!v}BR9z$f~&7Fz=
zeu@u!2mUF3Sxz-^x;%K`Eb?!@!LDt=Uh;d?`y009PvkbPKrbiptv^SO4?#CG7b}tH
z35QX3GX81}`Af*e8(UzrM-!98p68?EOIdd`y~W%vfR1nA?><JH1>TEelixj>brQ6{
zy&v&g<nAGC+GKqCkJ0_1?N|qlmGh|h;pogeScm<1Amc?J-ilm)gCDXVy8P8W*^_~%
zt}h~<AY~6`O&nm2oQn?zey{dmf25K)A9ZT*4Px-bF6fk%=$<#RBj+rZ@1L-Lc>*$o
z-*O3bcw-p*E_Z>`d+<9h!=3PYKm4T8+oNA6qOTle;%@R0&~wGe(5{Se4)*IKXwr5$
zYwtL^;vD#TGwf&|Vs|gFjz%{O>w^D;Y+sG;yI>r;<5u>E@wayDi_b6t9#~BL0N%Ww
z`MCjoeC#Ul1=oi|^fwe<o6R{oA3TMBaQ*h=V7`OS?Z%P{S>I~}HU)kB3iH>Fo>=u6
z`~2vtTdJ^y&~u-YSg$kxw=HE(m$P?w7O|Zdk^kk`KXguAm>9&T#InyLzXH8~4gB>L
z{CW)W$m_!75dEEf@#*+j%ZYJa&A-8MXQA6la%LXFcHc;Bnz8pg5&Lr)vW-5;DMr3-
zBd&QOYpuV~Fa5>m!bk9vGm|mm8|=6Uza8J@$yd1l1Y30Y>+mf+Itv|o41Cq&0(_7o
zuums&N5m)kjO)GE;~UMu$3PBee~r%K_Z`^UYYMpk@>KNBOmZ!;LrLW0gJr~qR}t4j
z=N$PFJlTvtvN>zHEtt3ahyneIZK@#diEJ%;7(eG0?9+VK?Z`(1<2#V~=*<}Fo?!h8
z&NK1P9qO+@uAlsbbq;IMC!qTi_ab}9-xlz~(bRj3c{*z}KK}PG5PUESIX~%k)~N9E
zuybh3&zTZr<_PBZ6?n7^8}S}<@t(sSR(*(VeuutfjXh)l_=BhHx&IY?aLiEhPL5(t
zM!Z43Cp!}!>b@I$Wi7-(@X?<~&Q`MCh@Zi_xRuygFJkZ)W1G-PzkVTlkJ!qktXY|_
z6Jo^kkEN~WaEqhpqKAp8;LEP~6aEnR%GvAhkHLpHoV}bp;!XI0XJR*xeVN!Xw&7uX
zpT5sx!=cwc6^w!T86G4D587;pZ9KIGJA&>WTuba}7;Cv*h>5{Jd!n;myqCB)dVJGa
z<XJyJJ`H3#csMp@D)D;yxE_8y8vFK-t<W)pbe_+@R>E7%#q)==4tszzM$AL+t=X5}
z8@pWqE<3Pijy%l5=V?Ef^(A!J47r_$O?Vdjz1hvk`)B0l(B}7>GQI=g(~r=9*v0b-
z(aXoOzXWf8h<@GlKK!)R@GbOusvh4OzceR@oS{STYtJQaT#gOJ2E6_xKG2Qq7vP6<
z$$@^@>+SZ$u1C<%pEC~Dq>GWggT}CK*&I2aOiY=74>^_i(kbY?{lPC6IYhU~w;f)I
zAg>1!bAE|jBjo*xLFiA$_I^2j(IxQiN6>o~`=m+oB$Avjz{Y=m2zThrAn)Ms@Wa)t
z#}9)Z=-_r_?LGKwJM8R0Y>bb&9`_IMz6Tx1oL&Juj;>g85B}JA*1X#x>&Wk4J|(6w
zn|1X+7zez&>L7R=y}k{+EO*r&{1kkB6zjVC@a2yr&e0S5_#pn`wZsTVlGk)ST}@&S
z4jMnh+z($$-p9V|)t!hRUxbc<PbQ)p9!B<VLY_X_3%lEmm|!0M>8`9xm*PzA$5>0*
z(}Rak*%Y0y4|Idxo#5SW?eOA1h~W%`4#-*XR&tcFkHPuaaNsK(_AJ1$9+`S~1^WTb
ztb<RJZ}DK$k<s5CW35+@zXadkiA<d`nX#V7UI}>rtA)5VblrX@V#WBR{m{Fgpl_$3
zi>m*Hto;kWG>F~8S9k>8eeWP_;xK&czVJLczW7w;@l4K4G7oK=lLJx5dt`6LeVje+
z!M+FW#<pc#=(r^B%AV)0;%l&(Z?V_%Y-iuT|Il(4+>?Ee!Pr@J_Cd&UJ9c&|v4FAV
z$T~c=sEJ%Ebmz<9bNA)&B>vx(*svwo@K7K8;fu&gLC0S~dzZsY=OYj0)XTkya~o61
zMa_pcwX8cn1gHMYFE(QQh3N2Gh>13mhq4SA*#%tjiQmOe{(WE8zVOB~*yy%p@W~AL
z8u|Y<3Z2nA-Di+rvw+yi^Uxpp+XT6Kow+>WHDs)kJq2vrw0^|Ri`gr`m$k$<*sD?a
z3+UMgSkwJ$1b#Yx%6(U{ZaaWHSmf>nbnyz-Fz?X*GcU4MzY{(vU=9n}3uG-*hz#9X
zf{z3)4?d241OFb-a!+LHo@3y1?A+_f-pYs2b*y#vL~r~Rx!L(~){V#GrxvhI`5Up~
zAMm}fH?x?deURG;b6Kll2S@DAc`*24@VlI6e+C+k#Fspl*yS?p-`VU1G~=(l4bPlT
zyx;<K{D;^{d_adesD2TC`kXwKCHQdzi7&v?FT?lq4rPA=-gpTfczPvvX*+D_7sN1n
z!RN0+D|F9OL-5(5&y}m$BW2w+8J_(N*?(;+afqAP+rZvz)rc;>ll*{DtiR4=u3uoS
zh}?W%#d`NU_JGhm7l20uKkK#Q(8-I4O(I{@PDhWeB8K_|Hm06Eoh_M9a4$ZAe&NrW
z+lb$wZ%<kR&p(VG`vkER^rxI@l<#|WyBPg>Ir)VbW6R*LU(o*((TO2^_Dhk8smHUg
zd>A=-S76g`U~i&`Tr&E;B}5MC&FGazbn&n7Bz!+SfiDmtzwIjgC1`PZfU&~k!?E8_
zSF&FqbeoRcf6N*go*n?L-#!qU!e_^wMof-ArhWlkn2+Xz(V6#<?|{F4{~7p-;IUT~
z_HHlq{FlT!(d#$kJHPiNF{>Ch^>z3PUpCZ_cm;mc&o99j!~{O%-QiEe*Y}chFpsmh
z?;yMQp&#K>zfy*7+zH-)g4jqqXU+QZ?{;Dy&~f54Xp!LGTi|<a-^q7C5TBVjeiZrm
z89sc5IiE9(SjT+Un(*jz&|yntyKoXb$=JR-nKdizywQnRVSu&Xo7jl%_!0~8GoK?S
zhh6RQFXkDWw#zQ8A&)h2mS<U0qu1lmZZ-72>wfnAKPG<hB5V1d@QvY({U@WR;iH95
zp`#<jR2CvfE$oG#LJavse0TWzf^Ar1<q*$CPdx3QD|)hS!}edk88-P^9~Fr^^dJtt
z4SNUq_(ABV<>TScBk&Q>L60E+C!Pk*M`OSEy?O=ljHk(?fd`jRcPQ(ju7&skKK7pZ
z_vP5M7xu^hU5xykOZ*$2Ou}m`@X_{uiG9rvSx-QVBaz*q*uyVpvGyLpJ_9!7?oq_6
zA0a0AI<fkFu{HQZGq<CiP0=Nz(eJI;k_zN^5B8}JX78Cb+VFw+6}J+{=#R~S$9`i?
zax-mw`5->%1*{ht%a!QB<5^c1K1yt;3SEo7c^w=2kOTjI%y<&)%U+GIhpsI`MjOF#
zTp779{Cj`wa-UO>Vf4u0_sGveH@3oGoBYiAsw-F*BPV}`_Ko;@$4(^Y5ZgE7apbEH
z{yw^H@euAG`8WO%?TvV}6NxkM$X_{^1fHLO#~$YpQ(T2#c^-ao3;QGRVa>nrw@*cf
zqT8mRx0|Lh7gs`)8`(439G~VA_F7j;j29U=n)m|xcY9>0-(}c5=HTKtIq!?#^&vX)
z{Zi}~Yo5KIVXZuy*eEiy{B71xUD4|fXBYnh-JizKfX8n_kLF*84ZV={5c0J%b2tn>
z=!*<*^ALKSM$00c-E8803%r&KKVL^2ax8rL4syrX-hglY@aApk+dw}0;s(yP4IuXg
z9ykj*eHETL3tiv)D)b<_;-MdrBj`2>I$g_r&f1%KIFWs@5OZ@se0COo9Bp0K6FSW$
z&WV4#@H6ZP_=dg!*DJB-e<!Yp{d?h6&IHiM>V1gMbb+_vjh*(u2f-d~hdzAwdF1VR
z*7eZ-<X!RG&LBQOy$_I+<#(`uF_!oR`g4<W$QPu{qR#kWwdDGbz(2T>ed-H|!y^k_
zbKyB?7dn)^80Nd4Y5f4Z@;UN<1#)q1oO!>T{XlfqU3Y^25$MS2_*KZ~3EvP;VeC^+
zfS0JaBfijQ$o0)T;3Gkgg@407G9OE^b8?UCF380xAD}NUzz=wtbpvaUQ{kE2ek8UF
zKV60&mwym`1pSwNk57s3)AKXV9AnR%H_&}k&@+SBGX{3t6ym8f;ali%(lzYSU^gbB
z_j@hD&mrbBu?uI7nCB}GL{}moF?`_Na*36FPh4RN@x@<|d54@EaGDDbwL+VIn{eI)
z8#4PQWb0VYTpi7tV>v!MHsC9G@UR`xf79?QE6JZLV!iig{6l=jzfHi-9!mURPjXN3
zgZk6{@j+tAOTptk$uS}qb};KE=HM>ovhI9r_Q&v2UvePv3!d8ze+eCW&phJBx1i_X
zp-0ap7W6(k0~tN;aeNi**M5V@DZCy%Ihfp7=u-y$AAy!XVEgv?GyHrxJ|grj#Yefg
z2fkP#^9|43;b$LpC)Ozg*rP)3&fS4E0Be$?FJ-L`J$G6`ei6L(6k{yO14sJ)C$w92
zHo1x4%AB&!J_I?#XFL(RBC_}DX5>q~gMW4-^Nuew@I2xRL)lMwY-A@)5k?80atw1n
zwYzUwr{8|t1ki84b&)r|C(hN+EAZMS*faUBo3B$Z`MafW)2);85BZNaW_Rk+tMj%}
zueiLfrlN3GQFT>m`DCZAsIaP{ysE^ht}QO9Ew7sFG*s2qloXYhmX{R!R<Dvec)Gt+
zr>3@ga&1XnUHSA9Q->Am@6;);sxPUnC@i9zuXR7`Q^#qjsVS)i$%^9A^4hw3+Xmjv
zI``{TRL{uPhVSs-ey@?z>e`|br-3ny%JW5imbOkHo^<^2<^@hPCV$&nLeXTx;>NC{
z`@St2TG;B321CJ)<%pQL<+7AoHQm>J+iq;Z$^3R^Zhr?^-|&43XXO7*p?&xDtty~h
zI7GGEg?3X|w8VlT-Ap=+TFl*a#=iwMHNPbnwT67F<aaAbZt9ErTg-372v&qFBlUav
z-A{h!rG5|e#Y4#j{)n`DhoLLlv3inIJ!wiwQN2@DQt#9j)|WUiaD8ocg;P>hIH{t<
z(irQwma>(FGo49=RmC&Pi|fmL!rPmywR~}1QH@hyIGImlQnveA%T6z>C@*$OD+(vq
zAp^6aC9<k$*&SN04J%zo&C>4{lX()^)*3(&)R*V$x@}kb>PA2Izo9-Sv@j5AO@?Dp
znYo74PnuZ0s+-XVX|ye`&PrMtdm3Fc%hlCG)53~s)X4PeiiXM(O|LZCX4WwhR8?N@
z6c!bsJDkFb3SDngFSUNZUUijIS6y1~6cyI!`dh87zIU47F`;EwOE><?ya_FZmp4zJ
zw+@)7sm`3XtfjP^9O~+cnpk@%-jE2zYvQ2<DnjGUYSF^0VoCeT>PGindDI_Bh8Khs
z|Kb_iI+gx~;g+@*-IfPl9z~wQLEoxU&)BwPY)(U6NiEc`FP~msKg+2>gO^kll^8+K
z{!;j_2U@2S^?PC&_UNK@A6{~GWqD=c<Pt3cPC4vQF-ze{ge3jlsJuz#^|d9_8p><Y
z{z|qs$t+V|;Z&4Qsx7S5ZETwPz7FB9np{;_SyER%xyrRwTW6N5Dr9&iXo>pTSvA!t
zY}4Q2tdld#*4GvmO)V~&)G)cYu)a|12g+r~A99tJ)XD&~d=ypJI@3#P>&oHB%EBq~
z3%$06cdAZT`uEf+ud1$9a2ac@Q(RI}QeRT+$Pk^1lB&sQEX@o0{q%a#dy@-m(n?5w
z5;akSuAfy?0xmP1qDfXi{-)Y4uc$1kFRLzg>O`g1RU&$-oD93JoP8%__w|GdHkIXN
zj;>QXz0kGs>F-O*QtvkPrN5g*yG4^Ks*9%Dw$<3x7#zh9X|&Stf_(Ty!-YSfm4=tr
zR#)PuR2EjjZ<_vInmFn2o!XN6!tyGou%@QCx{`lcS_rSWZ5AmSRM*u*_*yu|@Z~_y
zI7$lZr#SUx4OLSeMI@oMZxcn|ib52a%#>|g!)xFt5efB1>6%=tppl<i<Z*kWYqpW!
zq1K2$5K0uq;$^{j70yFE94HPog`=T_7Rt4i&^ktBb2B5GrLMkFR=X`aKN@R~I{wyH
zI|m9Lh(!~zNGJt2{zr3LSi|zb)A|M5(zf;iT3a1u>Xiaa1Bs4U?)F_@gJ!O%m;@<M
zG3C{@qHD^^Cu{plrdzi6hyqOM@>$k0cyD?fWcy`nqr6J#`n8rRs%}6dU<W37bmMk1
z#%xU*&6w?#jCo66mu+`ueh2dqo<L7_+WJ8Ly$R!xcU#l0yyHKmL;IU~^49CaJF(~7
zEZkWawf~<o;MweX6nic{m-Npn*lF=MhXeF$VMOhmz??{{jMc(65g5E+e|MAL@kqd1
zW>ZzhAD<hH^X*{Weh*+R;ix|niKUh8DRBS74)863ClaZCwwB+XetYpdkic?zaO(ps
z>?zY%l}WYHkKd6dzhLX)-yc|PK{RID*&h1t01O-J;=YTN3AJDjQ*_wPz@kktRc=S>
z4b}DXY+JIZ+8Y>sMnmnsRTHz%k+4QZNnuq(jWfBnx}io-RVEZ>>BTw?neuhPM;>JU
z3Lo_G@W>w7`=}h5H?~kWto})Bs}(-I(Iq=k-~P9+&(TV_xVp|MD=9>=>1vr!S`fW4
zfVyJS<=+F%zbCqK+!hT-!^tqN#9}T&*LKE*grm(`&R79^N@>0yY{qmrye(t2zv)V3
zq*o^p-jy;{9z8RJ-;R@zbx_nV-j0(<`s2yAR{5K>i;*=KU`VR3fwV0$cYx~K`pxh$
z?Wfkr_%ZyRmnK6+v1l?Li_D0{y}ZH+Df(|qD6rvI>0=XLy}#L0R$yJx==gXGLcx(P
z|8?_~#N)Aeb!$MDRGJ56{x>!7rlv$F3H)z;iRtqUV(q_i{cmFvshGjW_5a58|Hkz{
ziUYm1as9t>{g0j5xc<jK-MIeWxc=X`{?~r|#`V91<TtMWB_^<O{jXye8`uAA1#Mja
z|DRv~pFVtKr(@o2CPRrccgqfZ<=_*0m)$d@*HcT6{9cX^_(oKOqw~upVl|?^vdABp
z8}f~ioz{eJL?Rv-F*oE7hT?Mw(9QRaXeh3)t1XgU{)VbzHt7gVkYL6mjgR1w|Az5g
z2%tZI$%Rn=*>c3F_&6#TvuLny<+M?zgaK^)vylQDDX@_O8!51n0vjo?kpdeju#o~A
zDX@_O8!51n0vjo?Ar#m`@)LNr;*q=|$q(zr)0;<fL?jQZN2jiR`|@{SPB1ST3(g4>
z4rq;&Sw1i)kqnLx3>y|9RU(lbm@_*tJ~=l|OrXx+6e=e{BWGYvu~Sx9=Tuh|JLP1(
z)s_@i){)^?If)d;fjRA?@(c2FRmH$ue|)S%Bkd#e^9n}mzxjFk@92E}ckCGbcU*z`
zJ1SSdA2oKY`aL>-ocdcZQvV&7tJ@iuOZnzDe;jO^WEkq-p}C}_(P1#`Z;r+i$#5Vs
zKHw)W9MH%~;b>%FPHQOM5>6z@3t=QP$(QKw>(aNYZxg5?*}ReoEm_x+$+ddb*1qn2
z<&DHF<hys9uuGH<;SO(KC$cRlLpi58lyuWg0<o5saMDp3@Z@`B*5u|XUsqK#IKI)J
zJF?MfkHzOV7BnUriNiE52qa^%NTQKE7XEEgSk#+fsL9_JNhTV@Iz88E^~Z_dBtvm$
zF6ROwq4@9siF&$6850MXR1l^cAsX*kC0i*q)~Y{<jXJy_gEhV98M;VLp_5AO;h!q0
zxFgmE<4q~Q1dOXjN$gpu=7nsMF@}L@V;E%m>?wVE=fXwKr{+OqMEZ!*hwS`y@9Ty1
z?f}tvc*|%`=s`R8&<@86361?x3WlN!6t^e>8jcYuR+tvb98URzbJXHb&JD#if28xm
zF#1XHf>6ZUGdHcJaZXNJ={*e9Mawvexv{oL&^zG_D;$qS<v@$3zGxyDQ|D?Kll0|<
zXv%sadWJ+_{YEVbJL>u9XWBWt(MqNlqFeStda1s4F|}STv2!nDpM;1%rdsZ6Ml&2J
zNr{SJlFKJ}dP{1o@=R+5L`8LvV}Tq)YX{3g8`a}prVIy`jRu(vM8<MFk8WpwAdgV%
zes^?!Q>&G@s;0>t1F0&teR<31(Rs`0mIKrhd|o96tMO?z?VL<Ix{Md1M=_5w6!$$s
z$XM6%LUfrpW%i*A2imff(Je1BeRZ8|ab5yMsC^ZWZrKabwT?5jX1QbcLi9-gN}0px
zeJk40^f}qId=C)aju)bF_Cj>;XHe^2+7VT(Yk46Z%jkB_qn3=F!+2&CUWhJpA!U~E
z{w0^rR{}|&<=ae|n_V9ELi9*ibf|R)5TW6vJi0G0M33TL%E-L`z@tZTACTX`nZ!Ut
zvB!W2hSIw(<Avy!AEC@dIG22L-{y*+pEtGsK`q_aivpockk&QM-ZHx7mrbp^-CEu<
zx-V}#dQRV=mdx@`^sdXiYuY&q-q3w{AsuUJ3_qckP;42GhI|C%E^roV=$5@@G|pd}
zzRq(s)fYgzaXjlEE;YV2WpdB}y4IHhp=Ay*L+8>B)7j05#^!{RXlrea#goIyRTll@
zZCQ`~C;F0E{y@#L_;n!W%Lxq3DevG`;O6<`;ZUN{-x4gy$17@_9*QS8=9R7RnthNt
zZQ)3;abZicF%q5=Xh}NrL-A-RG7877W1pGL;Lfy<%4?jvE@hj;$+>NF8WYI~u1?kw
zWw!3Ap*ZzdGdCCJ%B*joeQryJBjMzt#^9o;lZ+&sU^0dU#asEp%xrnW_14yaXGhAH
zlOpV|AupN4=vcI{=6}8oaLPvH^+knd8vV&gOH;sS$D6HL?@X+L2vVeEA#N)9|7yTh
zp=9aI#s&GqN3U&u)2cK?!%g8(u&B2Ff3QkNk}v}1*Gf~i@pi1Ei6m%6+JY>kvde;Y
z>Vu&L!SI509>R=pG#G17G>*(|Oa$lufofFM^j{NtX~gz)tE8#ZHr&2}?khvLalew$
zH3lQMX;v(YT9dK$?O}!<SmXSbb*eeNu88GTEV?#gAY+=@TEncPV$r5>^V*81jXhPo
zu{g9~WWG~3HrJ^w;%H@S<D@vttSYr-Zv4WoP)4l6F|JkU21G3Dcr=i<E?x*XpBUYd
zZLkXOmJo~BWXRPlTGtNOM;cn=v3btOk>kdWE*Lp_)X2uzoOwa5)w8uHg4fzMClU@c
z#{Bae%d_j!jvT#q9i{Zk?C`*xXe<(IX1-^zqMtEyU`}<AXOW5%R8Hb>V2xAEY0aW~
zUuVNH5<x(MCsh>7zbYpc5jH4xYU_*mQ&hyEJAw-3oGq2(xm+kPVWfr^b3$h3O!do|
zPJL%adDW;q`Twf=3Aqb%N9RgGr>?$Y4R54QaY?D%Sx{J4R9@~BnPZMcwbcp*4x3fa
za4PGH<Txe=7dhToUsNWI>Nn-wJ5X4!PFQl%lcSZ>OE~@5p;#>^!^-98r9Oq~mawac
zp72J>3;fCD1P+(WfaDaA!?9>$Duq>aURBLu+v(*+CH$Kb#bRjX9|h1`5t7>o3X6+M
zCqw5tIoatHmDI~CMI?i{T$xZ+SfPd~@bb!<2~wue^Y6+!Rin71ZfbpXjcvTHzL=BA
zg|%|<mNT``wzx#ii(K>|5uf7XlIbIf_-OR`TUE~)3pG!?sn8RqhsOWwxhlw2=cCj*
z6KY(G>~I~D@yxbPlctoU6q|W1FOlgUmuvc@MVWYdEw8GB6ZkhL{EN#K1C>EY@>eEn
zESyOV<rT%1g+*n;1kQv7f%f?PL@S1p>cz$7_89I2{R?!7LP4a;;(~l9^{=|}%7zNX
z2-#qAyM(9kjOyB{g`DVOLZ!5wIMt>A>ZX?0IOU}r47H8=R(Z#)P8CzIc#;`JRmlve
zu6U{%QFUo)c~N;`g&vq1`y|e+s(+NuRBX)2$?4pBphk{x)J`a>si{ZAa>nH4j1m@V
zP@-5;HJ$9&@)F23YeI2oPFpjtXo7>(RYhe^-K?r2E>3{6kqk~pHZTW*eWfD)<QBxe
zq%0x-2Qe$_Q2~=-4Wftb5(ShXApdTP#p?pGR*d81S}IJYRC_RgOx|dbjFfi)Y+M1Y
ztG`Swe+zO)>A!grE)3?69VOwxV1E8+2^-2^4bLBK;Sw$k=I4%6^+)GQxUsZ67@Xse
zMnl2j_@AYyo8ZV&e<E4x4-*&+=B55EEf&z@Y~Zt7X>xKY&mu-vL$f1C=Sufl_VgtZ
za(e+Mr;$C5Iv2`eXlZb5p;g~_-zI&xz(O2^g^(Co51vDL4&ynTM^?qh@Epr?JkL@d
zS@WLABXYBYu`m~@waIH}k&}3%==}dj#8&LVOsg{oFj`r^-QsGA{y;uNZ|HbXdVFdj
zl<3ZL3QuN)_mH%ALdk(?`li2$|Lh9XQ9(okSMgZuA`_p?G5tzZRj>DQfrzc&nZMfB
z?`a^X5cS|@OVeT=P;)X-Vw2wWgcIQG>l{BhcgCaG%d~KsYC*7^07QI@r|C(r!}kUv
znv;u#==Tq<ZrbF)WRNH_H$=putZ&jOdO-)OO`><9|2UTplMT*i=UPo(4kU+Mz?~@5
z+l`c005x<7Cmh{zBtpp0X-mk-Mj34lW&G6a%^I5fz6}LcEZIqf0&Q_tWGcw$1Y)uI
zd?&m^Ej<(Uv?EyVp|Gqqwzk94*t>jLOT=9ZmP2x+KVswDg6#}?5e}HUn;p3qGC;|z
z7oz#b3+bIfZ;2EM2dDNSX3|H>$FwomPLxTDbf=-HHy<`|)OOu#VxVcvk+ExXgTYqI
zn^0tbuoZc|1FCR0mYKhdndj({jj%ec_C6D-9WeB~q>}p_|5yYChg}CyG+#w%S@<De
z@k2U~-`Zgm^C*20T=<KUunmm9v)vSERNGUYa87#961_|5E1^IeJxg3?2Zg6V;y_aK
zZzZA~sN=-_;RNTLja)Qg&)VW4#dQbsUd;n-Nfcl2RUHbnmQB5?SZOF42o>ZTsXG$5
zjF+q1j3zr8NXl2;Knhq+GJn<nMg|8xU?`B{_v7g~HQo*E+3uT#7Rm(!Vf0#SD^%#*
z_jUSvlSi-fpq9FP%eQKPq0lLYLNzh9WHyA-TIOWly#|%8VQw<z_Md6vu&pU6)kn@{
zS1=Y;$oN*-S<L>P37so<I_Nq3JH0yCi9}NK5{cV^`Hq=ugcFZ#4jZ+~g4lk~S9P=q
zIL!&m7_0uEMlkb8r-}K=SgW2-YvtCCXA}4f8b0P<kLyBk<f4+G)2cXFT|1R79Z#px
zbP%)GhdSHwc(xTg>@r=#d(p|yOcQ%)HPG6zi^gQ%)b0Sutgu@do3D9?)3WO_6S0KZ
zh7F1>_s(!DJJL>Tb1bzv#{C3bvSnxMDlle-l^td_n`J{6<K|jF!3Q<z1Tq`&^dlBh
zmEn>VmpZx|DBij6RQjmm;jRF=qD5cCLVY_MHz^#{?FsHw*&Xhi)jPvY#6X%uiU(b;
zvNXPhav1j3SQ5{PYab$u9KGcm=5CRYGslmW?+Y#klpD_@xG1sUUV}_{liEICy~^US
z!iz(u!t;#dZpw+kv%KZn1-bsg=eBXbYQrN*v6fapD2PDGoLO2tLb<ABQCmFDIO;=l
z<ekOi(Y4@Fve36`1HCbKZ@($by*i%Vbg=*r)2DFsi_?Uo(`DqtG#Rm2svTLacl?0^
z+rlu9(TL*1q&VxJv>foaCPfe8TgiBt5yEE+lWE+S=4rSn`c_%l_w*NxM1=m1zey4k
zTvnugB+N?E6N-wdnMg!p?IZ>y=jzGuYPGfXF(<^zl3QQg`$Oo2y9NJPc1180jm2C1
z5k&~D^RT<}>2&`pjqd9@E?2bRsI|~eRDtp5{K+Iob%X=0lqp}>GvrKsy=8xo&Z76$
z4G&fb29I?et4ANY(&ObfwAF%etS#X(oJY!DQv9K`k;>+n3wyMyV7T^dEzYm5nUB1(
z?b7bGRJ)c>-8&B*_!^dV`Ci#jugML|T8(Qu(I|E<l>OFa^joD%5>AM`s(2vO!4lZj
zPl{n%l78gE%B`opc$1a|Ph;AXeVsAv)Q$BO8ljJit*WUd-oqQvES_|2pjkyJLt~`W
zdqq#0g#K<>7Gg4F;WlgQJX!!V(BhAx^|`DR&ucX|32u;7#*+a;_u(WOpUqHOvVDD=
znn}-i85(`1ORB`^(^piV0+|5?OQGNnE_JfE7~|GelDU%pIT23ESqq`4L*UvecW2V|
z5<HX>1J@SS$yveFZCsYqQZntCy+pEYjsy32wVE)AYn|M_>m{R&eF4_MRvx}dQDv?D
zS{eR6Rh}7(#-i;^s|=OiU4x*kx7-D}K{KfLv-M(K?VhI3j>LS^S3q63I7?>dQZ+kP
zGP(ja(i0CwLbwv?7ESDA56Xz0Je+mj4lbu`k*b-_?eI!3<JoO1W%N|5)zkL;mi5qK
zY9(f8eFvcU3)oW}aA6C0&9<Q5DWHl-45F-zVyPO%AN2~jKrH1HAaUt5{F9-fUPD<4
z(Ygc<w3gpC0@i;t1JSrEIv_#^!EnrpsheXHN=jumatsA-R1`?Zct9G)R-5Kg!%1ti
zHO?xm$u{lv!#b8t1pLudQNf^q_ReGuwo(|3H*@WgPmktU%ZQ+tw6?ctjX!XgK=v^Z
zZs0SJ2|y%gM!0bEKN^`!VHej_O{d||G#Uy%<@7E*_lS$nbRfdVT&Zp_JOGGb_c8v<
z4jYOgGObcc$W%$sJWa<?BBm+LYgaqXVBk2D>&kS_YLWH6Wdvc~3H@$V^s}5iKT8e0
z3#`}Whw}an#@(!HNjs++NUjUH%s}EUWQBno<3gSUBE6sOLY@aAv51FU$V(j{uNVlQ
z`eDwc_fJhbB`)MEQ-)7Rm@=I>9W8zB=0dsvkx}S;s}0n)p}CDo5)nfFXq#T1r_ad5
zv>CCwHM>N}Rh^gt&Wl_5^ps1}q^XjtH+21DBSkhgF1(+`T1f0UWi71LTSI(Z+UO8p
z?+%p*b=Nv!yA9=k71`4g5NK_4g5d<j7VVTy?b0-CEjQ~}XgJ|_{0j((7;B3$p}ufW
zZ!ipk;oWe?&c5|n&5*~R47Y?Db)J^2wr#T3f`EDFrfhMO>^fU>+pfgQRZxsP9_5s&
zn;lh*K}UiF`|ZH~3a~GPw+FA8z8#Ye$a64Cg@3sS2Zt*%4{r^sRk-xfpB_YmEg|o2
zpgPgOk2Pezbqw#@!K@3BvgK5CM0_1{=_15U{H<Y0L|I#&kWK%$#oMAmxuhW*Dw%^*
zx@Q2?`2hNlf+oAV)WI+Q4`$!Fvn7LD7fjPCtUZ6l(t{C@cw%Rdej3B0#<B;TJ=@CG
zs(|REoC#ivI-?DD{!MYGa8rTdrlZohX-zZKarW1qE0Ybs^=(7t+jJb}1~g;x`LZG9
z<s~7O(M5SsX8;!yH^EJVe7_o<v8D#n5~==UNq(7`bdAwq>zXiPc2b#ORgy^byUAl|
zgYagXar3O3$JB8;gn%6|TR>t&_M&NsrE<>JsW^$5Ymu|GmKP-Sw!?Z<SYys@8pFAo
zMWqw30iCoOs^I^ZxsvO1I>#z7VHf2^v=Vydn2Zi?AaynyCL`~Y3DlhYAIq{_59VE?
zh^!O)rnuc|8Toqo9JI_!tW*ZCHA7O!mezZ!v9+aZX2VO#NtR?w*T{HNE}b!>$Bi3B
z_R;U9Ty|u6`dLfDH_F{oVIouz%e|Mf+#9NET{kM*n1y_q38Cwg$!T(*OaiA$8dT|J
zDk1EDFrAYXw>M|>|88a{1J?<T>z}*%JL#2{D+=L?Wyr=uN;a%^px+HkzLc5L82>jU
zQ+iGw*ksK0&#IIm|Ci)add9ncNtHUMvR;xDRbHj~`+q-|a(yy<yq1$F$Gka#g>iP5
z^}1U;`7&cgcILeHU=Jn#Si0taNnWMvkNrnZfLYpa=%QKdj$M-3g)KhgnpRoaim%T)
zcp@3LTVh44iN8$akzBy(JTrJCn{GBwBhUUk4v(K_4v%D?HSt(Ke@*zUuaVDYivKs-
z*npL!ZxU<1xzI$?n$<?<`d_u6qFPgobY7yQQ^(1s(5~E5FpIyHJd$;nI(?Pxd>kWK
z_eE?rvUhMG|6|M4G&lA4kFRy)2U&)v(@Ao8Qglk4AL+Qn{LeVI+1$sDeRmwm@4CP!
z+4VV3lv*W;Z70*`Kkkr9KmS`^sPzOZj0D}QB*^Zj=skB9ElJOYF;bLTKiES|YdW38
z*#1L4EG_@<c&UuvM%z8~>5x(5@ur>sjuS${ha2Y03Ky+MF0HlrBJy}!aZ;H%&y%`j
zW-athWeR!d`(Jb>X+wQya}vQw=^!?R2WRN-1!?+wwHr-U=a~Lm&M$4SLo6I<wN@Qe
zavY_#ygP}$0z9{#cy7&5N<6nPPYciCcnNYYD#pKCc@jL5DZh~CARa62dT+UiZ^eZI
z92gJSi;<*nyNl`32;RQQzfEN{$$Fx}%;a|5H!;}FlB-piYjsORPO>S<aUzKf=^)3o
zRi};nR-Mo69s*{HT>qyo#L~yBEX8C`S8bHGgjxcvi=3vms5%IgK!>J#A3;VV-p3Li
zy;Ip}C^SM*$kNxzN+G#QEJYom?*WvPea<BFJw)x!><>iF{_wGRW>m_AOb-RB2fJS#
zTyqcVM1vh$Se4TWeky}?URz7+oVF(Ul%U-^mW)Klq-N=CWfH1vN+RC@49Lga;2zs%
zOxl#3L<!uggg~Pf4NaoFUrD^?SB^&wCaYOzj;mZ8TZ598RtYbLDpy*17c?F4Y$6*`
zQ@Y)>+I76NDwJ6SM0P>%nl99{*e#a!B<sxf<qCjq=P2Gwr1hXbNjo+R>`1BAfd(Ed
zpobh@5IRWT$D6+IpJwN2scHAnK^DJLf%M-@eQb&x2dQ<oDf6sb<{Z<`1!@c%Xr00~
zFfO8~^JFxZ7n=UY>@GN^^Rk=<NO{thdLGS?%Dqtu(+M?#D`~NbF)b$}M9;!aKrRJx
zXlH@g*}fU5(QYc+T1J1jDLF*#JX%in^q8iL)L58%n|bDGu`R0F)MI?av^vJ!&wK)i
z?AUQQ)X312rc9$-<^==Ui#<<0j@J#O2dPpT^1gwH_SKMYfJn;?Zp%LakvTpbh@Ru0
zfV=}lBzW*2&N1N1KAQ#|^e6o)$sm0mm#58Rm9ePnaLUi?-=yusIBrjw`tSO*zGO~G
zzxC|`4G|_oqaFqVivy7}4V{5(!^7$4xStDThVHKYgkHe@Ox>uWR4+=N3+*1@Ifx4Y
z<A?ajEbQFZ&+kJ#FzK}qHB<9oYrZU{<c1n*ZlEOL=aI>$PKKzwA2*Y)FFl?It~-*&
zG?<)8jn~nh9@A&#jx<Wi=@S{-yF8W(1LttZA^a_8dY%XV3eVmVf6JVppRVQPP233t
zLxIRdO$Vv}29NPARlR@n`{%XP+tT#=0cB9wN`m__lD8O1PepZ^AB!33uS)-lj<fT&
zJ*6$iGH+g5n<P}#>YpgL9jmfaRjXFEcLbVXLO5Z@At#SQX-z7NVtW~o(TkON(NRW=
zG{r-qrU>7|mH8iNdb?ZoW=ro1)KgmeaJ9$osdo@UUaekLU@X%f>RqNkgTCi-$xs%*
z#_GxrZIV5#vR{pj$e~@)jOQ!OxVBnC8LxjfA}dDe{)27LqdzkUESb5T`<}?$U(91=
zDoedIy(_eldRtOwkf)x|eWV%DWoksW^&6#>kvm&+s0Sw8FIe2gV|mGPzr2&4_RR8b
zBJV^pKJ>m@5DNzf?lF|JVj>#@_t<?X`=8v_+7?ZOo4MX#paY*J3-XPQ8DlU$Q(>G(
ziy|{!fx4Ke7QGGXE_AcIEAAdgc{%lX7&>iF1(^UuvP$=JwcInbJJHjw)pGlqlE=Gs
zOMwVqysmH(x=t}=zEWjGDt@H3sTr+V+V0Lfs|BQXjj8>Vsx2}v)V_yDWL|y?g>%er
zY2D67ro`Ks@WQ2s83yAL^oG`c(t^yp)d3banRg4boED%qdFx)iD&CYxm!f6Zv|g^P
zv-Jz3S!!|UlIsW-IgxO}%@v$Wxq38DvrFGr)83A*C0`6gw0CEyKG^jX56;rVTz^8H
zG_trKo285-qq%;d>FWe{E>8j?wy7R`v<H8xDHCzMk26h~I=9R@Kx7m<P)2jugFsFP
zB6&wc6`dY6Wk$GVo-}1{a?8AA$~+B3x3dz6c;n9vm9figehow{z?E*TUralvp-**R
zoA51l!Dp%4*A76Q1ahKVYX}g*a9_r*YmEdVoL#T@MEc4z?VRtnGuo87+of2cDT51a
zaIOPV$|Cq;x37RHa|V8=9#^wzXQi?M(pL)*!RHPz(D)o^Ah*-IhAc1;u01x8LrpvV
zD5L3fERe(K{YHA%kQ0FjHN@-Hy`KU^G{PxvnNxuX&N2$!*V(3>XWTNEns%gR-OjD1
z)?&BT{Xm4y$GDIefC%@tGm9FZS4}&+y7;^fL~>5Qa;f?*5SfejUC3{yR-s$V3(+li
z?yE<7xr?(GqH*5JlsV2V<AvxleNCBbDAN(5``XczX=4U;881Ya8EncdbKCJkbeS=f
zk$Jz&<=#RAxsY0VE{aS$6;MO><%Q^W98+dLmttOsuGK^t;SI@5*0oxI2<7i_Yqgm&
zKe=U&Fc9r?39tSgh~PYxS{lPEfylg{>EgWHl=-_mu2+HFPw#(rA@2bB3CIAqFE2#n
z{61yGM<3?4{FQ+eyY1lcsdiSo?RX)&9WP{*(j>o8OENQ_=h36+#&yur*Fv|io<Ib{
z&h(`z=7s2Xyb#^j_NLZy7auP~*YZMit%;`A&2FuIfC!yKE}gw)bgd%Fh%AqyR>yX9
zUnP`T!h5;LSdXF%h>Y|MAi9<pqN!1CYVDV`mTtMyv~z^pdo>W@sDHa0RS!hCuA584
z=|Dt>@8Z^K05Xb8mCggAd-s;neKnePuAz(`g&&BF;$*iSFGSZ0nOZNowdMm6-LkEV
zPXvhIGng{EmKUPw(`wqe-EC)qfqdaY4mOa>T*x6n1jFl~hHmEwQ|6njWpwXHnKF;L
zWtISmK%YUb=3fd#aGpmQ-Le;=+d0v+^O4)msX%1xzqqq=IuOBdtjh^rh;HXXQzj0@
zIzn{sS5W2>FdRymju2hz0m_KPz0ae|cp<vXbCi*h_H#%2g6aJUw`DIx*Lum+>f_e>
z!1N{FgYL@<(Y02amP78?y%1gIJIaXt%7tp0>$>;T6q8RT>M~x4F4LPbGKyNPmFDNZ
zrdD5S=`vo3Zl@n*MBBXU&gno?tIp*gFGRQFh3IyMm|8!&eR(088eWL5wFk8X=bkRk
zIR?_hh2)x+k8ttvLNq>Jh;DhTsr81-bzX?Z#|zQ5%BUsW@`XEtUP#9>y7yYs*Te3d
zdLbRl=yvL<^$KGbEurUY1`v_2LGE05A-bKJl<Bo4F;d3Wv6gOmKZ8#X@X@ur5IuG;
zMAw>UYJE)a9U;1%R?5hH^>$}xk*RejwR9OTM7MJ!WyBj??9yim5E<zZx0V;8Yn@1$
zsf_eR%IJ}vWcu38ol`GFkIM_u?VLd^xnVm&EnUV7(Pb{8jI2)2b>;nfATrY3+>zc3
zMEs3&UHUv`%1GQ)WB8&ebEaG7Wgtf|3c2}Am-!fo*d3W=4f)(a2D^||K<=d0LU)$C
zal}uw=m>X>))R=>xCg1FDZd2}!Fhm-^VUE_y2rZX@<R03dsAi!ZKPIPe=?8*UH;h#
z$k*V5`(kJ~z(8bnbUTBA2!`UF4puopyz;GQTvg5@&W*>~-8kZ&v?`-qNn3+AG;7}M
zMknLZL?9X0w{v9dRNY0KG8NrVk4@f__D;OfQD7yJ*v*+AP5aS6M4C$&y`I$qAmSxW
zSD4Fs{}fh@V}RPolE7Yrq=g=sv_6sFGUjtsO}qa&8K_gVaACdBr(|Iuq|Q#KB6elG
zuM5qs=dztdslJv%#s12Hi^iCt?39iDRb?q{dzzto;^K<B64e^t_lenEC5Lyyy{+Ij
z)V+-;u!b5vOmv-ChVp-7loMQLVc~|Vlk`tR+XI1edqF!N=y73-(_o$ZE`oN?@_1?Y
z1i#N`jpl_N1MISla((D+5RWY<5gjRaFOQ9CO(4E$;dgo9J5TVr@Z}!(9-i{oc;Lf^
z$&7UFyO?=Bil@k*3@|5)CYc==OOevDe04L#O2)s8u@<vy*wR|cPOAFcvYNSzfeWp7
zSG1OylhT)GDJ?xFz~T%Z-ICiS`{x>)rC?LCkZa#0Nv=Gq5R<5kyuTKGa~n^#_Y!ZH
z(VWjyDjyGOh|0Ap^|6wc*5o2COyV*LDI;w>%d@63!r8ZhyUf3=H-&q2%Qy3Dawu8C
zr2}(_RPogr)rNX6t$xds?Y+h9O<liMcGIhy7<r;TrjLm0-2!Q&2R+k9)-rM*gHZN9
z%E(Q3<en*Reb8Xr2Ob;h&ekKQRD%hiS{e$C?%~nosUq?g3aW9K82n?VwR&b$k6rNk
zk|$dY(G4=A$MMVwHHV|{n?xopEELre^`dEY3-rZM=0T6-C7|jGj@nS9J~nAlGBinV
z4Vy^&%e)s|{XIHtu%ffb!vj2I5XM9D`JMV$o!rR9#~Re0l=OQd4;#g%DZQKcrs-dz
z3@Lr^Hc+RC_<J&>NT7IH@tWS-{z%@J!bOGAU_&&*N5=JxTkWLoQ)Rl!<r1(-atBx{
z55&GxdN5T$NzCU48_Da|GluB+)U7;q*;}*kGF!8{@H@d&)UHC%+&|#KChPmW)ZKtt
z-;es8_xXC)re}XGEme3O+NNw}Ak$sQ)<7ixp$@x~r?_?}Q|5-PZLL8-#GVXSmRaO*
z7gHvQEb5kbGiBa^UfQBbhKAJY<<`nIwQ>}%NjrrG@}P^)Gy|FILS_QV!E4!(mh=9A
z1($fZd-0O%9~@x%lY2X4#^sx3Hb;0XxFBWI1>bp;PQ?mE--m#-@K`%w_w4!t8_r{G
zhRCD9_7<4gyAiD`u*p2OzTKy><@e#8-Fp!EmGV<~nnOt?SGK-)2f@~rzU<zBU@u>>
zk%;MWP*Te}|L~m*RPPqJ)M2-PD~OG(pThgpm~EW?>@2m+Zh_*Wi+L~W*m)Qq%@3CY
z5q?-kpBi!l5W%Mmh~}c(fu#BpoF4=t@uY}b<_S|qd}LkgNgxNpA#HBU&jOLYPIn<M
z1Cbby-bs^|Uk4(+&vV;ZX==sYTHgVY-nUnNwB)7pYVAI$J!@bN4>X#;!vhN!3Psa7
zY*-qH$-JG3t?0z&zU3Riv^&2=+v?pEDfJ9^ZR#myYi^kVlXAT?VA4bX449M~kO7;?
zSa-{SZHgC^lL4CoEH?uteG~xW9xgF7YF|`f<FmjDv%tzcFrh#>zl8#$u^@y0zzLqv
z+_|9$SrOj5ZLGBKopmlMJeXMCuLkB6;onw<TIS$vnDn(=nO{2-HIxa)Y9tHKy^FeD
z>S@;+Yhvzt^myXpM~FY$KsoErijH|5*atjuf4gJ%!tAb{x?i$9;kHseXCBv<VY5TU
zdhd=4;cUCJXg3jFtoG7u9@c(>6WH+mmD>91wq$h^gNnr$xedxV)n(!O-YLP)@w6l3
z6|Sh^u{<j<;fm?lJ`1y!IUxNxg~54kiKMyjR_%TZxAo3w;|gZ`J~-31VY3`oGgFSE
z#@7}|x|r&rV_WSUybZ_Mx)%142WD+_P~oHuw05P;^2gR$<*8#~pLk#vuO`(FZbuC(
z9wxBGMNRwUw(g6bx)%1D2WIhVR_)n4GDGf?&DQzaQ^(@4hB`L8P|;c>@o7(8+uvN(
zAK!Zkg!pJ_v{@3NV(lsEea=(I&ZoJbNA{ZCtKkH{VU)edGj{^(4(uZj%*xYz=@$d$
zj!@+T#hR=<MR*_M@y=y2{Bk0X7gi0w&Gqn{^tp&WkMQ6vuygr+i3cVc=0MuN2^%7}
z$M3GFG>Q`AJf)<jV3H6_j0KmP3rx*CRnyXCF;Lg0a|@b`MPylMzXN#NcXr(<@a@(B
zAFu{^|24q-Wq}LrS3`T-@1OV6>r9cmy^uQ#xBiFVD(^;l-sv@~_P~$zjBgk+XY&x3
zX23V#E+NVPcQY(mDsqF3!_@@QNN7PQ<7QN=yOU|U+v0L!1}>KVeLVCL+-+X&sg&1u
zBCGCY#ho?J+P2dxqa6$1CIfEUKYcyh-#Vim+y0hW;4h#nCuG2Fzh|sxzh3?vX5tr_
z{ON^z`BUK5Hl3BV-}J01J0>qLd)xN%vbXKC*RgHk`>#BF?`_*FZwG_7)uHFmw*7Lj
z%}po6*{o($8M5b6&Xt=%gB-~&w7T>>-X-IURN8iFBvBZFo2(AFj=8#>r$`d1;+Qa^
zV?qak-_2t!8(_D+WwckGnC_2+gXP@5n=BH?Liv+g9xqJquaxXPH@bFl`a291?X>A!
zpi6ltUht!6uhjbcvh*7G2fBvnK+(LX^EB{z9TJLE{6}DZ9*IH461X0L2;YfT7mmBq
zb-Aa_a`y_;B69+wPJau8>#QwD^rXGu9FVO`awB82iZVz)2M9b?7!V^>r_WsA(51NU
zYEM5+;W*czr|vxClIykzI7{Tm)0Rw*!dC8XY9nMIl$GdGwlbA`c3NiI(n8}?5=gY^
zNMEW>NhA_(O@zVCa>aFC+>G1Uu`laT)`qwwJE~7bcyXz$n;Kfg2fTv`%>ileluKIA
zJ$kyH=8hXY{aP9bom0405tyrvMi!;!Q;(}E=CYd(iLIK5mkP7^Zt=7!K7->A2KlZ=
z!fA@fTDWdDE9E^N@+dWr+CxsKWlb{9nTmA!*NQhAR>wqS(v`*W;$J^EoY13|Rds4y
zDlVg6(6{w^R~XzQF;0kZeM#Jps4Bb@i-^0maJ?QUEs#s-kxnORO4BL5pN42KBp;kY
zB0N&Lgnmqhtg8fUy&A^PD!x!tty+0IneXDwZ4yhXkn}t2SzMXQ(WOl#=q|6?HcdTu
z+?M~2Ps7Jm1guIm&D{EN{~|46+Dj06dfypW+vV$H(%N;^h1;&^1{rIdb_FS+k+n{T
zrRuItEx2tNJS3_Yv~5{lG5zo^94IDz-@dnVc&5gqsH~<$7#^CYja$|_<xHensaqXk
z`jdC4A$0Zvu>|^LitTs4ZdbabzTzF#wS8~e=<wd+H78X+Ydtv<L@ZQ&2vTS#e&@r`
zO=1(H)NY*}Nuz0rOBsnTr_RqjN@>}lybZ}6;mVf9i_0X{J_DbwC$1zGE{!h5ypQ+;
zDz2MJvy!5^2A9-!Jf>ZFr|6sskG8d_ajsKDg+y`A;CoL`upieXI|*4%XFQtb3GQab
zu~1V*&c`#o!4C6aJ(kCy(j@uhu-e_wTwbOk2E_E$t!^p(Xn4(@xp!$`=X`(NXDK>{
zFnF_C?8@BPz8+tPzAO)#zN}$L<FSmnn%u@VSXG+@CQ=^FlUe$5M+8nXKjPta(KuJ|
z;S}Xy2t0=ObSMv;;liz_^wc`ED=V<S@ObM>yRr&fo&_%JuHp>1L@>nWJVSqKYRYx=
zQ{q-HW#E=Uj|xr*1pE=ZKaj@PI(}mmo$cd!PaiUu;+5UW1O7TRGJ{V=n>`GfpRDg=
zZFZZ(wI4<%syMPBd$0I8dQ30UpKN8=y#YJtVt?sVPi1vev6X1AKQLXFsWu0FjI8N)
zU(RUP@}<GU1Yhc7ng}U9f2?lPz87un+Lw;+luCDR>wPu7&(c_&|Ajaw;6_4HZ5f`f
ziL=oZU*w99+t(6<M>1X;YI0wvbko7!_ez_jWb5_yz{9jdCn3H?5(ufLkckX>WjY|P
zjx@SkJ8K3HYpYj+hkz<YyJ|(kyr=P?`beeMXLut^oeZ8<b+j?)fM=aLmEm$r%GWjX
zUWZqMhnsH4tUSL(-wq!b(7LYUu9ejjn`qh_&pf3+Hq8PT{c*UK(X{fS7nW){ci|R~
zch&(9(I3}m)EE3je@w}Mi+}kBGW;=*jTlK;(I2m5;AZFj1n*c%qJdaYRw3H&e~Wh?
z^4PYd{U2$2^9-2mdLHTN)AGf8j1Sq?<2HODZM;JLUY;mu=De$wka51G{BD%r-P31g
z`9&>rViBbkG~N-Sw@Dt0x79U<H|j$z*!g6r(Cc?fKT@yFQ_uEeybW7V^(5t=#z#HM
zQ{LL)jDD(OQIQVYosKk0-J?Bq*MMVMMd|Z1=-i8Ww`0qYGrK@gvAvI>*-vYxn`hCW
z={AhAQ?ryeI$CgXImFVdUB+PIgqEj_|0#<FuSciWk}~cSJasIM4b2*&cyre8maz#=
z4LmjiA(2GekEt_VoYwleZPEFHp;<Eto%V!IZaov>5g&gx4}7T?`^GO2T5aZu0#2ZO
z25zdn7dP3lc%R4Hhpl7u{`5KZat*mcOxegxyd-lbvyR+)Ug>XDm4pVFxMi!;l%=1Y
zJma^SI5PfPJ^tB>kv-%0dB!j0El<k)&-E_|Splda>e0e?O(h;7_(|r_o*8w8Kg8Gi
zfhU~M_S4SiG}^N?vv{S-7R6e0ad(G9x1kbglwA=T_V<iUvWcWWiGqEGo(m^R+ai1q
z&(iJ}Pk**-s=umOeMxE@Lp<Y<veHJXY)v@IvR&+$9ZPja+ZpARS(ozZ^k^t9GJGoh
z{bx@bIR>8Uv!S?NF}KD=GElskS9?=l_$O69B@Px(nV&J9aY>zYd|>TxP|;TKndQM}
zq6g13IDG4EBNB=>C;7Ibj9>KV!8{IM8;ca{tT-tvHu7K|TUKCVACKp;FsUy(;^Zv#
z#TH)eDJ%8G4o>pGL^mu3|2udx*En__#2&tofrsF>h^NIr-;Ik&=Fvwy+1e4=kbZ8@
z(vLB9X?ludi7H~~S>Y=Al0M$g(ucPV>E|ULJQY!OYH46I<%C|AuCjCLrK6>-7cTUX
zKD)4kw5IkfoxSyh$HcezmPhB#Sx;Wef}IC%9l_1gIukDZ`ZG_0gd?LK;A8F6e~8~u
zvQTeN;&7_%Im_d29al}H{4)2Q66q{(Bfd6H^l`_2B;nANdAB_gS7g}o);Y|DXCIXu
zFqPit%As4&BZ@)`88bpAV@8YMiX&TgKAvPwvbAYt?B7Bwx@kk_THaemTa!acGZA$m
ze>^Z(qms(#dx3V>RK~8&K7|e>a5ydMq8dGZ;kk=+`<4EMx>Xs2@Xjl`O%Ghp+vld8
z1lhx(sH}lB{43z)iSpF)$c=64_p4I%qJfrHH<RFNRgbS*dQzGk1R&PVcE8cV;v4SE
zBN>S$TnH`S6u0C0mii8#2`e_fq2Mp$x{gPTt6HxZ{U+mD$&(J(_<iqf$HeY!zcc)i
z`IF37#-)AHpOrkBaBq25iz<uP^7~KH{(^-0BvV4|u-IMWpXHrMy<WiD*vLpdevRL+
zlyPe_9$U9FpE}M`H&64juG@_=hC-7=QMpMYBymHP-PDD5{Da#@e7*vApJj7t)v29c
zn2bU6NOe;a{H!=xx45N#ujSUWB9>_0R=gWRi-S~)!rP)#zT~mln*x({$EQ4An9y&y
z2PUm;Lu(T4dxX}8s}t$AHA%;jJTlvo{I;|IG_BzMmDI^p8xKZiUp^1yg|EkVf-<6Z
zp}8Wd-mjVW2GcUeeFbL)3RG-SF#U~(9wpwSSr?v8&zw4%5~<ug(Sb6e&-Dn>>e<mf
zq~BHgo5KNuDylExd7~>#I!?Mg|HA0O!>wcWoT+0nnN!)>Li=qQQGyZWs+knbWEJ=q
zJt8``nbq=TKfU7H77v78(%xCDp9e$Y=^8CX1-<Ia*P{U*=Oy2V%+SKr>42TZ{$y!W
z=Ao3G8Ug_v@sHH-6;sik!cF7dwsnzm99l`?m&lXV%6CJVY;6da3RNHA2`9Kw+Gr7h
zox$VQDQ{IPG2yR&^JJFQ^{Zl9Otj`rmF)<B$cv9@TUO+o(WiXvUF1+`YAv;bnJAux
zuckaD-TY*$Ew*Py9Y++5N{3F9Z5gk4Whdg5wa@jdTN12xm#8b3JZ8j`Wh`1B{E2q`
zDiaEXnLiu-kSKJ=ddBaeoUJd>CC5qWWsC0)3SV{8om!QKY@!u)g+mANemNYPuQ=46
zC=d+n?TI<1MFVpx>j%os&a)#tty~p2dC|a}8TnjQI5IykKTrQ1ZGMj(qkoU%^EkX8
zm8;*68Y@=}j?5pOKTiEE7^(k`%N?zLkIR+v!Tj9O@;jJ6a<tS7=I7;()PF}x`@#Hz
z+)?^(p7gV(>&8Q--%$SOT<Is2Uyz@x{*F=Yh4RNpJNBA$IKqyX!PWAV^3)B?sSYw?
zI+`6AkM}Q^oK%I{bJTCS{<|$ygkGZEk)w0-X^+I>@quB(M(P@JC5^;)l@3*PaMLis
zb^fN1>~BdsW#jA03Z1;sdhp}M+P`{m`D66pM-|8*f(%Ok9ixaH%+D7hfLk(>P{IBL
zP0m;_e&o2}d0;cST~``u8XW^{65r8|#~AOH+;vDQtM5uU{VJY`WVBw*U)7$Z1_p~U
zT<nI^<TSa^Fd64FQ0+km$^@yqn8yd22Ik1E?=xvn>txB(^FG(`JH^er!)@V2qAjGq
zu*{u3Nx3FbX9pOL97>tj;mG~LE#HkM=KxL2jkQIBj(j7OtAXNiK2n;DNj6&|#zwy8
z=V6o+8}a~|=A+da2Ac7W1gfjybrHJr))OfhXKFpFYFXJE57cq|aygOx__+SWneJR!
z|B0sNBy84b1(^V(Ct5&m1;|&B5>w`jG@K?&>*h1>?fzsU7Inf+re*8%OqDVRwuRV{
zc0ZbK-%XQusHoH%O@Z0KMWW^I65W53fwa4j`9Oq92e?=#4CHl%qtGM<WCG(D?AB@r
zA|u<KGP>ozm|EAkwN3+aAZ1X2zA<X_XPYwbx@FD-av^144MVeKrp$L_W$TtN1|nZe
zeurARo#jBJ**PvgH`-dNWvdBS09_bpO-A^Hy?lM$((5kZ&}**w`mMtUn6bKA`)0li
zEz}t?cT-13{4qV`yB_yF(h~P|CLQ^nHmpoMICb@AirX{Fv7wM&PN@74ZONz(RHL$-
z_o&-LJSN83-drhngpsU+<<;5e8jFM~qQ7@6DFR}>JN1<lZcoq--h}%pU0sq5CbqT3
z((TLpV|Y@RSLt|#z!%7)y3>619KVGY-zr*I`=W2aQZmBzJx*JKo6}nOkUHY&%C5di
zOqEG>lwQ=ecf;XIBXdSJ(wcNvORs|sCl$zwp-0=H(I8(KOyxAI=BA$w<ev(6p?g1$
zkjOV&Ig((?<QT{SZkcKWaa_nuAVLGVAwjo13rGv?>`0lhil(!H%;T}KJ2?en=QR%8
zj7~BNxt9rZ(4sDAV_!0&<mEKVNFRH;z5We|^s!j=A=ocBW%f{I>|ETgTF<;oO$?5n
z)%|#XF^`Rki@)OM_X8QQ5WkPjfNjC=u^F(f`MskDCYU|K?-Z`m!<W$hJ05SZ^Z4D>
zQ&Y+v2JDoKa?kU7Wd=;z`%z#fo-TYWw;Vo3dtRDLo6=8r>Bp3{{hX0eUnp~CMt$4v
zlUd+Gwdb<Hg>s9tzy-e-GT@dcUIX4S(^O{78I^}sv$Oj;<;bby9#k=TP2pxPfOSaH
zSfFgL)?;r<Tdi%$gxtesauj4%z5_0^a+J$KKLEKD$Zm?0^9-$eOCRz<Tqm(88X%+;
z#Sd_rBe6ODh<wKxO{A3vk~ZAb>6x`o#@(6V=<S1q_y8Z!Uavkn*6G-X)q9;WzH8Ha
z!WUbCx0FFsMa3VI`4)crj7Q*25r4B?u}FCtr@$pfC-?Np>PO1I%|pVvaV+F`gpRw&
zica3Y%cDPfWyGDnWYsMaRmdaj5h*LbD|om}5BJb$dZW>LGM?1@NokS2-LsSy4wshp
z;X!*7uhvm)DZjG^W;3p~p=G0yLQ(ZCSToy_2FZ8WWsYPuV7btv?@bAgwQyEe`jIu`
z4UD$0p}x*86nh(T&#KtWihh(4M%8V1?)y0P2CSu?T}KU;dJ-i@2wE_ClCl?77Ew#U
zu4{a+aoe5u;xyp{H?u$E;w7^wIE-Awd!g%3(61}+y_)O|V4w1MVMF=7cLuDH-v?&E
z&f@oV88E3^E-+WS>2ZyxUt}+wM66rPoJyMqdCH2U??pNB?9L$KGfu6lrI!_+Qo=pb
z%QPOVFTI)mGRj{(@5Fvt-)bK(7EVanJE6ck8Rdmq(#KRDdty;wg7G04Fv0H*56tSt
zed#M0)1PA(wZrY`@bhAKtzgR)|4uo}xfPTPEo>E*5v}R8liC#^KT2fWmZ@J$8If5T
zQ!NjAKt;}EJjZx`%UJF+zlF~7{sjHoO^M|!i;96u*$1<{v$UQGE~0Ogibn!1yfFiA
zCBrfBG`XOjeLrUn?}cjuyc4cDQ*n)GLdzkUXGsMv{AtgU+F2Do^ujFHS(wdq3(=EV
z$H~D`T%VXYi;f(Q^9NvVX2X_kT92}GDQonYTC|F(nxoFCI~Wd4L_5p#q-@HDM*S=$
z+jS9_6Ee!Qhw<<;XCfl)C}q;j^#yTvH4(M&_E!DEXz}BL%NN~m!sd=svLk-MUw~RU
z6j`&QKLNP0_reB70Gv>i&vnM4+RwLTm##xuo9~>_F2v!KzL3k)G7EF@Pu&~ZGumIL
zI)6>!<O*-rPN0s(?L<|FMK<Oy9u{*Xo=h5Ma};8pIw!419V-hbOPvm*PVL2<@;mQO
z<-J^r?8QthnQi~HHN3YL@^s$Iq<TrNQqE%ub^nD}qQ9-BOo3Uq3XRu5+&PP!Km`Ad
zV27DZ@Dra+EcBVw6UMbv&Lpy_p~?#`XRl*<(HzqLxs*=^67oR@W#I)b?Oc!n7wsYC
zFVt|gA0{v<d$9*5y0kaHui)`sm@G7xcN2hLo8_JLaxTqymqvKkRZiuhU$u_q1=kp5
z7x8#K0D&DQFk{87EjS7-X=UBoTzMzj@}4!kleUiJ$*ect@W6Gv)9VMc1uj*HVAX+b
z<ehU2Q||9U{k2$C7>FTTXjohKh7G7|wdhT5-BdT)3D)rkl$`IDwUiOs$xX($@_2m&
z8Smjd7AAIAU`O$Y-L-RioBr(t+uXH@SDXwBr{;9UI+nNNv-USjqpp>(ws>u2Y&+Q$
zxb4ffldX)%j`03yo|LTXT@c~>{j$Kt?+{+|T5qxQcT#qH=<RSD!(Pe)S<ds8lpZbD
zdEqu%CZ1U<i%%~$_MLcRneU|MyMW6VhPP5ZTe%S#u^xiJWSql!Y}`p;GREm1nC0Dj
zfss2S;SN!yDVt>MdA2zbOzxqc_&VDuOl)iSt*JF-`Lnd;u|WFVv%<uyoV-dVVU@6@
z(*vr%Rz7>8?YY)u+Sh;BzH7HHbp-Aq;C^U$4PM$_Zgfr2!RsM(9KTyujnZ2-b95f>
zOMNpYHN~uyl$+!sMaoynEZd=3s3o+2(u`nOHyMFIo;8p%7xI#UEa8p^UFJ;#In9N<
zZy<7ej4ty55Si6xw9ek{cs;9C&q&fdWQEtq)Ru44+{lK=Uap3z6G_qW|Fn5ctIx=+
zXKv2SJJg9cvxjQo?pzxmQ^x%nJ&HVRL!?h6F=OT(QXh!yNXaiLDf=OnYGk&g=6?9c
zA7}|iqN?Oql)RiaKcZx+O}C_RMr{k4<7uH?w_rIl1yA>0R~w9DX&8S4RDX|1ySi4R
ztvRZdipYO!>w5fTk@yFJzsh5^fW`QGTfT|N0&9Mu&JVyIW6VR;%-NDZNl9^VOi2s>
zw}Gqr%6HIo_rk5DO6$K+{!3baKv7g6zX6eNr;r3^IIk1e1PElH3+V!6Jdgqx(iMoz
z_RE~l()`-pKn_!~EG=&VL^yb`TV{6yxj;cCL76>(<nXw@z#6`vu&4V)23)}AJ@rQw
z)H=R%-{I6B<7q?I9Cp_B0&X~7-0W0f+Q@GO?*+%F**DVT__KjLs~~nwzMpF6_jgD#
z%5~Twv3MQewkOKVd%{#lw)1&k&*SyM^7!4H0n6ogNd|07e)r1)>n|`j3e&l-^ij=Y
zX|LlVo%>2Z^RmFDuZbCOJD&N#4V@FA2wSV%cM(piPd&N2Oc7ParQsTB(?U6xZ&F|H
zHj^7}_PA91N5&^(VKt!cJ`)MsjNd&xFe@K1f$12t`k0FF<w9Wd;btGP<Goz$76Vm%
zVs|AZ#nlXWo-#8W`^Acg*Css=;$hBIgj0U+s(+_NLnQVl7;SFe+4J^R{;g(`Jz)G1
zz0pM!r<L73y8`y?56ezUR-7#L1$Q}*PujhvyG0u=xADoV&~i=*MD=*f+4r&ZmcEWt
z>E;9hbxn?^J>??=)O%({YaI<!gih~Qfl~X3+PWs3fIBLgV)6DP<d^$a6`1x8V_Z1@
z&72TUeYr|SY3Y~ng=P{LyR<%4m*8tTLB`K20v(|76HYjr_C@-;BkL30XoqX{6yu<m
zjjp(g(tn3<euH%;D*JQ~kY|8!QJild1$n`gkv+GGid)YGvYaP#?iCI6PB=HHI7)$A
zzHqg@`$l^kUz*lmb}?85q!T%!;w5ODz6By<x<p|hqug|$#(Q71t}fHVK<2A)OPQVq
z5_ciH8OVOB9r2(gwzCJ&Ono8n5gBl4GZ)w(aKpg(3f<^Xen!dvN8WdbNm(TS_soDf
zVE_XvsF+bi#EeG}0YMQ^6wzUJcNRu=ch(IA!<jK*JjIOR%<;r<hBND#69!C(0dvl0
zIPdrQba(aJZ<-zS``?e}>1Ua$>gww1>gwwFlJi!Od6yLU@Cclo_XUin(E33(!<ih$
zM<|8!<P`Yf5xDfGV*sx-W}FH<>(#7SI^{VJ5bB&`#sI`>W?Z`vP|;P7#BpsiL}rHe
z(h9WrDiL#UMmv;txY?tp-=-AzSt&S{nRb5CLY4<)kUKl_G@xnqBmW7QXFV0+FYrYX
zxQve<0M3yt@SJc(b;bHZdxQJ7&PSjLv?R9fzW?a5n%aDAsdq&i2eN+wXqxQ8@k`J!
zR0<ddUf>7dd^p!C7=tX;Gul?0>z3^dIAu0EmD(-~sCQl>btGF!)9G^pvFL*(p9yK!
z0F57vODnGo_-06AK{7fY4QbCo3c~+jl`nC20Dn*GSPQ(QCdO)ed5{6lIy@eBASkr8
z6>3A@F^bdJwGCLPtQe-uHQY=l1t0oqth6Z03+kJX?caI0&}>dtRwDVs+rKz#Wwv09
zo(5X2n7%A6p3Fg38(ZPy%m^5vYc^l6ZPm6k+~YjZ>3amAX%;P9M}o#4*ur6bJlui%
z9)+o`ZeB;cZ$tXDJPx5@#jI4eOJ$5<B(|tPZ}@{&yy4gi^3krQ055iByv|V`#8}$d
z7GiWNoabuJj0bgq!+oq;)T@bSoXGj_z>kBUy;acz5OS@@XP_IeX-T2lW2P$Y7OSam
zAFx)jkQiNxjR@bHob1UbrlgKBzV5AuK*n1;;3Z|=8>WkS9ifZJmP!{XH%3Q|KY=oN
zYV9+$fr)44!)HAMs6R9LCty<}u!jM=(1X$6(RaN7nBQ9TcZ}el1O3t-Jz)<3_DTfy
z8ejt=uy()}L}2>^b_kL$Ct+=bd8cQ#!|(MXd3OVBWQ48;zZVc@zb48Nk-B&bd80m>
z`Zy>7PMw?_fwP{?fWPg@K;G2HZ%96G(hdgfbR?03uwC){Mi0jP)ZM!YWgQIo`;oG!
z(>@8b)Ymj5S-ECeqC<a`b9>Ny=<yW4)g60-`dDG14TnC1*qeODAkQ&g9*NVvJUUP(
z?Vg|=@6i%=0AN2O`Fhw9zx#W1(hENUj57v2?_SK8o5(lM=hS(|mb~^xzR$dTgsliz
z*9iYtV83r8`DM<-??)oAAMyM52#ox?lb>gM<hPh~7RDa;J>+0?`JrNTDScYkz#Ha5
zm9RaCl04~gV=X9&@=9edq$E9%#Ij`HM#}mT5(Kj@TT;C|=w<e&DEY@oQ6A(^Ii5|x
z(JI+fe+PfbCs7T1;hG6>_PXaiS%scGrqc#tKGa@kz^J`*l*Hy;0O71{r7S%dWq20l
ztP#me_+aonF`=x#0Jdg?ULuoC0k`W5ZhKHHd28UXf8_QIDPLc}D9v$@&q%|*ds#xM
z2LrZDq*O}DzP4Qgoc-z01P!w9?2`az|M><f+7j$Ty%Xpg0KX;y&c3rlL>{hx(DFI~
zN9~xEAfCQz;=@#!-&evT9Kex1#4tQEI5XegT*pX8#tB;Qx=6lHqBVYi<ilu%PkAt|
z-!N}aB(C4^H}idhB)^&GIs2QsmY(A884)hlABBtM`*86k?EAjYBoFp|AIALb!9I**
z=IKbXejq+=N9f$fjr!b)UKX(mmZ+x7dX5H<3#1)}3)W@KzK@=-Z~|pn2It|#LwI!l
zP;N7r=xs3Mqop6OXz9{lh8U?^YfB|uS>Tn<78g5*anlVFzD@ED*LfRi^9>k+r`Ou|
z0ZrUJQgDESubv^uD5O_Y%;^|2qcQbz5%^xrOC92beQl|!zAOvoUfH8HjX7Xpvpc!Q
z5@!x#SyUkNe#Gg66&3}aBG-80IBAwgkSz)Q#3bOTy)U%(2sy+;xEC_O>1--_u&oL;
zWdzbSMLgJ0!qb|fvqs{l+mj)dzrR|ivtbkzpH(*Wt(ZL6a}Gwo%^Hq^JQ-&KMj2Ph
zQX<NDtc7&Z5UJ;Jfaa&Wyt>Lf8!q@0B6vBgk%nh=A)jl%Q;?sNoyp}E9`42C10{GI
z7#4Ibz2#KUP}O!x0?o|}4txwVXpgJW%bLpha<jh=3?8DJ)4{`>)U2s(?zg=w|C}&9
z#9PXb((obu;4Mz0<0uUmKJmt#vzI8owYH^%r?#9Oo(nnbp<OtjLPPVEg0q7#uC6p0
z>%e|*=BZdrDkm3eXSy>qxRE@SI%LaU4&G;ATpbJR8=~9#DhpY(lt8Wl<YCZk?P#tC
z<SRgCILJIeI9ogv_hN?V_0byuxe3XSsR+B7FmJbluv?J!z|C2Gl6PF7nY#ej$EeIR
zms2oq=yP|{a(4r7PJx@lRsz2_fa5DLt!{1NLBQ+U8=E<g&X@J0^Le}(juYO&$s_4u
z4}(^B@VXjzFi9-;5#Wq4Mle%);2j<_cwG+O7zKx5=PHhaS;DHD3PI0#68X{8yeZGI
zQZCiFdOU0K=(ODWLUr_oKUT}W2^;9}d7rioccgh>8>g+ME-wSGud3&brZFfNXdQxI
z2t0%!XI4Zs<!0DF^w48iiGz6_N<lBH4-WRk^{Us$2e;s<KAhgiEqFdxDi-@O%EA|P
z+J=;emRknmX^e&vZV8z;dbrLZG6|0%XiLLlq+T}>{O6VrYzkb;wZm}3%CFOx0iG;O
zF&_VKEq-{b;Xa6p23~soj}E^dbvX>RmfNaM#$UoT4$ofq8*r<1#YuhipW&`0ez!SL
zrdEz#Wb&lSZfLXv{E$+;efSM{(OxGHk6NMTR&!%%;(-N5=y<sq8!;seyn%+LhGUA&
z7=LvAc{kL_x|A(zY>I}L3GlebS(vJu!Q;PdfFDvbIp8n7Pmk@e1n>ubC~i0e7QMWe
z*Ka*p1?xh*ISs*~fn5R-D(xEEe#QFI3{Q?#H7(8-)S{Mwpw9OOdq%KID~MQ`-er@n
zC$7Td-Icrr-&l|y<aF3Agy%(8<0+&)*Y@#c{VoHx6dfDa?(66}paLD-@{7>L)`g_p
zbrZ_<Jb?2;8zj<k&CmKgJx*u4J_Ebn5VYPjS05q8F`WY6_mE!I%jf48sQH+&G$b2d
zI}Qp9#`8_c$HNH!EdZ}AG~;<{+{tKf!MllwH}H@^aYpb?@s>L86zw8wr%csvcgU!+
z6>;`pK0G1L9GiPv%VA%|j6xmX6B1r4tOj15&G4-`>gflhI$l$0DYv)kh{{}Mit4Hl
zWr^L%#hf08_PI~Rdq9+n9YE?DUi#EmE1jL|dY4*xxLuDC=2dvZCvu+%BY@dym2!yZ
zF126#=#3|-cVEiw88K&3toM6JG7}Qm2OdoFZ>#eMeMS6*ZkrUF*^YUPKcH1$aH3B$
zTUe5Rd(uSgslQ$OPu@+Jy?;cG=Jm8Zt{2rcAU+X4v?F=40n$m`j<}-@ZPKS_6d!aj
z+BwcYScBe~GQ`=qh(r3kp83V;ny}AN&pT%_^Q=e*%V^QBzX!3a$XA|P#7QyU9S=@I
z>`K`f^vBB;RXY7R+A8(KQFb@*AAwQ!QH-)9bZk4&LXOA?WH2CnOZB&`Kz0X&-)6kb
z(ToA)6+kfQwtObqTzy@x1`8SOa-C~)p@D3!M=S)>5es?D=6VoktBi!NS(-B(%`X-*
z+d<aa$jB3L-poP*&iw#ky*|qc=Y1_rz^7no{@O`s4z)Bv>C-LE+ODRDTbgs7JU3WK
z!1-=KI(NfqdC=^sHUDo*bGpm*LyYD(OB2+qb1%b(^)h^xvydJd!ZjP7Qdk?%=z167
z8z#WH3%*?hPHWi_Ft&0~_uT-Y4o&N@Ean{)$t$DF9)PFq_mTeu%k4?mB9j4;9kxB)
zS({maVzEQNoW*>nSSs$Z?dj&GX8~HNv~z%GZ310h2?%Qww7@*enS0<t`Sf-im}G|d
zvZXTRQ=)$Z(hse>3EE(!lV~BJcEz+2C#x_8$HlcKd;-TC;XkiHL(X3SPpJbt{sEAn
z4Mf*J2Yl#1>=x=2M)`VHyWGanx^4srE%I(>Nj(9fclZtS+@Ka)0BUQI$hkN0;eIvR
zLV{j&ARs|ma+9VJP!0x3cTHLMLxK0@F?UN^JIFNyc*<j}iZ;qyDl-9f%hrgVx<+1M
zXlX0!uLY2vH&~8}&{NNSp{?Tp$2_z=t=LkJWjjVob-3LKCvNsvSk{Rquf7o@`DS;J
zk7b_j<zxNN#P6W(Ifhb#zX8fO9C4(~E`hlFclp+GJ1%FNbCr~2j>l2*Usz>+edou^
z&$xi)Uk;dA8{&|Ou*}wcYgpi8NdD@^&iFk7^ge6=U^6^A*7RD?u%@ObGTPY~6jyju
zQu_5NrEd<})gmSB0N8;Z5AwZ_9u>)#Xcm57<iVt@TT;p*k42>S_P5C6Y7ZtnZcE_7
zog?!22uXaj>`W0yUN<G+7@4pI?vC;_OD^^Tk6FdK2Q-20(5l%!cOyxOvcJSO+7{G4
zTuQpXgObRX?b(#Tmn}Fa0nV1nq?Gq?73Hy2_lfWod7tPYKW*(P&;<TUY~o$$+uu{!
z3{=CAqIPm^gzgPU@(q&Ev4m%kkGePU0C!*5+8-mq+v(jHw(!mNHzi<c6IhzHD2YK|
z0E`|IpCQ2QFg#yrMiE{M!>X|HIFulpkoTny@=`9An>TbWMt{}j^KaSXiOH!=_;ec%
znqg*WP6)Hy6(V`1%u0D_Gn|VpYv*ESF(O!tdDE8f4PkgE03Xir=DhDzpy9lTy<`z+
z;HmLN6nI4K@q=CmxLNYEaOrVATr7h<U3RI2_XiQ)q$Q85JzDYnpMbWpFr(Di-iVb|
zzCy;b@e+`&4`uzl0u4P0hG_K#X!J^8&1AC#g?0#)fyIOl%SfS-GQNwJG2YySp^QHQ
zXZ*fdQx{$Q5`oJ+>}Sgh>s3ZxE;-_h*z|C;yCM=^@56h9c&UQVlb}BAJ--6Z-eY2C
zQq$5_PoSnHky8y)D_-xmY}|U|?|@TdAqmF!)jQ+l*(H)sdSU_ab}Ts1(y3u;KZnrH
zMwg>ZFT|Ht5y}k&4fB!TDqcRyO)KXMHfCE_whRNFOQ-N051!mtPRyTgMc83(5VGzE
zBWY8n0<ASumSrPwY2lSwW^2=Qd5V>J1h*P-(>x^Bdc?w32TtD%3xW;2-)1a9THN2&
zEVWKI+cF-1AKzAP$2WyjcSH>md1(<nP<CJuvZvRR(&9PG6237;TVyM362SC2mC$Y`
za6kpNm4!6`7R`?(kp^l;X#0_NI?B?mZOYm~U|#vV2Cz{1e-XG>{$L9;-=H%*hYHN2
zlXA>^?}kpwiORVqCgfBJWvAwbgC8{qL&R)aYO^PxpbFKH+9Zt9Fy~+Kdn|hWUdXwR
zp06Hfd6|C6zQ_6GDS-Ns1N*`Vz$PKdm?*FY!o2f8XW%!bGph*X$TxRBLlTa?2bfrv
z92=2jgl6v|?I%d+4mkN~mPbsR83|aL_-#r+dcOB#9DmRY_0EY|3-gv^@fc*O?DiDT
z125bAOXZq8PY5|}o=Y6x$-zrRGH$1x8Zcag{fSGMmjgUvH$En2U%hZ=X~ixtCmnZO
zbU|iDcNt(o93y>LQ?@q+wAK<H1vPaY%;o=W^9L&}?^zls$*#S8V<Exp^M8Qw?X^3s
zMP<7-Zix6}({O7a1P_#pzz%~)>J)*^LEfbzu=4<0Is*F@uw^2!{V>)p7lCaD*zytB
z<H);01eSq(D@9;gz*dgHUPs<lJQ!`1D;{eCCN?T@G~qo`;G3qv`=r2kNP+()0vCH5
z47k7cVa-XOGsgO^?!RL|BX84<aF)F<bJiocti_t6-E$RNsts`NMm~K*(Q@Job|c(s
z$CM~_z|fs5(0f?AG=BCp=m&=|ujzx@a-;HxB+|kLyQt#TD6MAg`DnsO?)!4eKo})p
zZDxXodNH*j<RlB(QrAy(d@7)oWMs|@W4x|Q<aJ{eyzUL<B=@I6+(oWutKjukC?|P+
z7UC|vzN~`Re?vLRYXv;S7-&$Uft3KwW61@BN?-}_MuJ}@1ut#AD)4sQX<EGrS9E*z
z1e~618|{IFdczdzZ9~+Qwl5%*b~Ci@IL&cTh=zT9ARuFr{5~!^ngDo5b}%u-QAR6{
zK744i&@|I}dK1TSWct{{VZ#b>XE0(h4?bp!EgF8_)Ql0dXc;k?mrHa0t9QZ^mx&!l
zb}Xg`HL%Y);UUg=2|5lq47Ad=<J3+z&hj~Mpu}mc$$0B0Dx~*-jfpB|hV;_kay!zK
zM{~nt_LX?C70(ZGBIE)qDSPcWx1)R!pkhU>O)lznRya2W&xm0-a91En93!^&cR!D{
zOwtblyyVdnHVVH_@nFK^D!`mvmWT9=1pau6C+Il|c{QH)K$)*c@-3Hg<S~-npvyF`
z$dH!uPKwYHPMMF2z=g++fXjIpf!*Z6qPAXBnk*KJ-FYL&EuhC&O}Xi810Kw~Nr(`t
zeex8&TgwPy9_eP_g&N$k#*+&A6S`)pYg)l92?RR19kls+^G>uI$k0c)Bg?4Zjw*PO
zmeI#QtE6Sba8H%AjDGH~f|i#2FzAj&?7cZW+&HZb#xM_6kz1_mG0=)O>`19K!8q#C
zD)>+njC~%jf>vh8PsGX$+`f#_l*=>{_dK&**~(8>QHHeQGgZ=3+s{@>OWi(KB`xKB
zzDinJ-3wLH(&}EUl9pCCze-x_;iW2RsfU-Vq@^9bQY9_z=+!D|Des$A(y}eysgjm_
z-(3RQ538i5&OWP>miF*<m9*sh%@WZ5SS2mn?bj-4X_It89eH5(P4dkw0qs&%($aR8
zuacJiVwEas$+ycA&~~komNvOom9(^nwX39MTdY$hE%ng7N?P`db*rSMO|DlZE$w0b
zDrwmkJ*uRoemAU=mipbON?Pi-SCzEX@5WWqQooy2NlX21S|u&@yIGaA)bHk1(o(;@
ztE8oVx2lqs`rW!pTI#n?m9*6FHdWG6zkREurGB@ql9u}IR|PFs^r_$NK+7e+;FKJX
z7xFBxiB$Vnz*CRgSHM$uJ5<24{GBV{*`~Wzz_a|_D&SfEzzTSlKd1tp<qxiaXZb@a
z;936eDR|DPS^iMqG2aOGG5CEPe8~oz5qj258TROahH?z+fQGURuRtTSJ$Ifu-&n(g
zsW=O&PohNR)rT!w_*|wFmuuL@W~{uaG@iVvG@iVvG@kzK8nq`5W?K<?QfWMSQfWMS
z5^1DA+4eN2A3SlSKUv)*;ypPM@tzDZ{MwNdL|g_j`}F3l>C`oGipsQqWaBJoL9Qv0
zZm$mL<m}F9&~<e7M`*`XK`S;m7PMv?qR#H5<n`AFWQB$|TD;AXQWKv2#=WyT^L+rb
z_u`(()GJe_UgN;GxmcWv9dFLy^*$TxyKf5ofC!v*K@_SY<?C$}E2t}$dnM$3V1$Rv
zPx)SnUAOb9qIZv+ToWUCWz8?`1s9XsoU>=y2SxIWOb4gH^C|F2DeyuHye0)+n*y&(
zffrNY^(pYl5jgul&z(&ryuA&Z3TE{oSP3vbf@jN`D$t1D%Amo<7*9-u?58;eerO83
zB?aD^0&h!!x2M3TrNF1Bz-OeuXQsdpOMxGr0zV=Jeq;*#uPN}OQs76Yz>i6RADaR{
zE(Lyk3jBl=_^b$=tB|tdiMyi(?DpWKrdjzE99J?0Co7s9Gnz2Ap9p^X(noCpE8}`N
z)aM+DpM-J!qzd@Qu|s-t1^f|+FHWg|?+^T`74W0Le|81@6UcvB1^foce|iP{Z>awn
z74ZK>%zb7B{IkHHm4cV`NxcuqjS2H5K>Z>hb^8X&KD&dw=Kyb4&Uv60@2#}D^Bd;_
zhm+z4h;e8u+n#fhcrpSvtt$^l={M@wz85S3J=^=jC7@^fU$g}Dw1<nAfS&eo$r8}h
zUgj<VJ?-bxC7`E0UA6@Dw6DvTfS&et#S+ld#{Rwp^z;W;Edf34=jtV(r~O>B1oX6@
zYnOnY_H*45(9?ddUjlmC&kajJPy4xX3Fv7*H!T4@?dRqtpr`%ZvIO+BpMO+IFY*06
z(3`!fM!XVP!rQOG{F6I-LU((Wbaz%scUK2=+`-!d`}td9ER<bN!ny$VHzXgnGk!Nl
z=+*-4l?dIg_<c+Swi<qqiR9fDuyrD^o`7|Zz<L9=Cz3DA8u)!h1hyG|PmI9U!S9_T
z{CWZQV}x!S{C*??+YY~PkHFT&@5K?=j`-aYfo+K2r$x$L33fIK$*;%e=sP3eFMQal
zpy?5z`!{UvkqB&U<lP#{&s&4vbI`wh82#6DBp*f}Rr1P}aXB)!>QBJX9_XW<@%S=6
z=e$hDTlrQDY3ZMiiO5ACv|9v5KeNBblX>Y&UX0MuUu+(sqff|1=-BT&Md;YKUykUF
z{rCNdK3eg6RwVBpfDMn(?Tj)niSSzln!6&hF!rpA<Q<0dVgHGgL7QkHKkp_9ZDJhT
z#)I*U-6;{e{Xlmx%k}7Zp6-qa9nZS$5rNUhdPQKgvBx4X+SoRcGH7ELupVByw6U|1
zd>C!)j7U9bM~fnPX)jkr%AmcBiNI(tM@RC~UVe(u(O!0s(9vGHM(AiS>qh8kFW*OW
zKzsQqQa7%HeGsV|*9{+v@Z<W@gOR*kQ|cGV%XRE8BYC-A{YoS+*QGa()Pw8KO%WLF
zZ*n9r?e7<_44(AhH+-%~lG7r)Vk{zjKjb|CN#F+_WKJq^tk@WSP2h6&k>kbbNKrV)
zjM@ZxjvFr|&~xlKA_30vV^{(ojv;F#z&Vca^T1JgIF<}Wio!XbT#^9im@+;A&T*xG
z0)LJz-z3m;e7QdX&N1ee1USc;MG0_@HH`^yjyK0g<l#J*{qhW?Lfs+l_}cXp{YnAm
zMZ~dxo{W@)V?TWhDGA5^Iu|Jk$9}ta3Xc8vuoRx`$KR&pV}Bl)l8^m*wUm79-)pDj
zV?X~2DX9+Z@82irOxELX(mI<~;2TM}0)ZzsxtD_vCwS}M*XVN7Y3LU&)@7vA&`&Ji
zL0R-0A9YX`{m3&Nl%@A;wI0*up`V#tfrjHZzg{~ONx%I8UqU-0Yy@Fg$isU`cnhpW
zzi=pPeD@$mt!=?mWQXB}54=o8KH{tFQ+^?s`P8ksM@0KR4XGY?aZF2?n?z#YCqaKn
zINJA{NJ%)__r*v_INJAKDLC5q^c0@7@2^wx(Y|*}$w&KMH6<VId##jwwC^vGlIlSF
z{w_gh+za3uHroRi3}M}M*cZdYB<8IxoTxPWXU{;VY5SKP7oSeS^JLq<z<VA}w($!*
z2RV+9r{s_lAMF5te+T%7JHS8K0shGfc#isaq7~9KLi`;a;BV^yKd%G)Egj%*?EwFe
z4)C{Ez|)h>LrSYZ@&D)me^Uqe8#};X*8%>94)E7^fWNr{o?f~~1^Xa=-45{Ubbw#0
z1N`b8;MYvSvqwIJ9=RAja+2$jl(=h34)#dmyQkpE@lkN(8y=f4gZT+oX6=ePbjWk;
zJfkjW*BOBvj}(Q|JHL+P!^!yx%ekN9OkaIIl26GJ>8D2~!0Dq~Bb-T3|NKP)J$>^o
z3H0>Kt0d6VCwEJrr$7D}DJmy@@z)W}>;!q}M;9RBoI-QCRlhGmKkVLB!cdCallaLX
z1W!=3^0PtsIw<qf<NOOU{E@uut@k4Rk-W5vE&hPav?-3`XCm3}6gIWvVx!q`H|Jt#
zDW@VO;b|GqTPvRFte7^m5Gg4KOQhvohLnb<1&ywNrzIU(fj=$k`;`2YcmX6{9iweu
zCoyepPz8>(xz$rR${zO{;A;0qaI*uSTCxuY)ZlRw)|&RYPK7dPr(YwbX@&OsLrOb|
z42vqrz_X%k>!Xm|?u$9nZ{9SJR!1yNTDJRiq-to{;x8d}M9copJ?h1f)7KAM<paP1
zZ%7GfC#ND+!<D<*A4Ry52W@F+6+B2wyDC;u3)0fY-l>u=t*dVpd__B7CDel!xLlRx
z(b86^qC9H-TdVa3-4|Fh+Tq(s)oT5_h_tkIw(<9X+qX07iZ$(%#k^PsZTZtG?2z*j
z+U!iy+Hd5MKU@396#mRZ+ij%n+B|ZW<!9uv=TLMXwSCPuMg5`x?fE%s(B`M6enDQ^
zCtnshNY9FBpU1IHEEP+py$$qWQu1$+lJ&79zg+Y>=BEu#^hzd-w)V2elQ7!UmJvGI
zNaqM0ZDA>ojy1_{5v>W^d;#0ss|nla15fX?PPWBKNOG^uk0wrlzN2vJ@eL#&P6?K^
z5)9G0BxmaKLL{G(aO!hZ0-Snkk8mbEb@f#OJ@qvpfu1_+5}~JrD_RNna}rXMYbJ1@
z?mk0`N>2TK6VVmt#*8nxj$yC=x%Xs<WBhOp%a~GbZ@>vJd25C^S+_{Sas20cMG{Wd
zDUxuqK9Pizb%`XLtVcv~-1CpruXSpvnJ+PNGHV_WwMK>uih9pKQs;{FY?;+;%j~FI
zh9yQcQ;`GdBiibaKBB=6=_6Y0kUpa64(TJ>uSidC%NDsUuntYHPuQ6Dum>lD`+C<0
z7Fdy%dcTwwZmhK;Ep@(9l`>G@pH?9QtzlhQ!>)+sdTVQ7ZK?g|tCWhG-+;ZpiW*Ss
zhg3n!zDhrN7-itwI(YmSM_ua5`VD<EHkGM~2#&Scz}ohyx;ErQ5BfZH5uqlIKJ$1=
zlz^k(9F%}#DVx|*jBg_+deehaN})$xkid!g=v8~C<fCU@DkUF%=`tz#=ucmxKTW6=
zed>n^dS$J)i0Lk&74#ICk~2bxw1UGW=-lBFbnb8oI=48pW4je3lo>)>OOt-1Fh%>0
zXM*+}E<yVam!SQSEPYaBNoX0zGofWPPEIn%>zCKBKd_DoEobv4_7*c>c=xX3@*3WZ
z1{2ycmOnwZ)>0$CJCNANy!?s%EQC*J_YgjzcZKi?Z5+ZUv~vib(AFV*LYsPcW19*3
zb^1wYcQ1cp+d4e&ohS4|gU9koV<VpLMC?nt)OL)}CG^ikehGawkuJ6UBITyGqemyF
zIr^c0H59P#hvg#d$mm@c)-koMJszY>ZSx3SYTJ8soG*Ng`N!u-a!P<@q}qj-mvpJ^
z@6oZ0l~CtZko+<d`hBboxVuLiIU?-YEuDEShCXC{@a};GtHI>7m@gjMUTA1FH-~6D
zt>IBMl%HkLZe9$JIx!mB%!%PqD?~#%euo}af*izc1bD9m9LuMj4XMDJG_<io1sPe!
zTPXisq$EAizFzO34BFP#70RGbd=mVhwPo;ghBf$d4Q@xZn(vNeyVCBKu22qn+=u*2
zTU{jap#3ddK@QfHay*5^Jq~VCVj<Rk`^4Dg>)}Wt)>f3EGh|50Puu*cg3YlG3BC(Y
z=hbq-*S%1;9r$C#R1fIPli<f(9^w=HR|ucrw?g;?f93G<+CzWHgwxnM#$cHVzRTqy
zKEW@A@Cp7Xgir884lgq8U}SQ7O7K4}4`oX5J0X06Z*h3>DTjsI7hhbdEw%E=XnSHH
zsjZ?kN$nM-NounwO;Wo>X_DG0N|V%9QJSRoiqa&tS(GNJjiNM3?G&X+YAc_HeLbPC
z@zWaEu}<t$4wukA4wuj_4wuj#4wujl4ws;RhfC1A!zJk3;S%)ha0&W#xCFgAT!KFJ
zb>|d)I$VN29WFti4ws-$hfC0>!zJj`;S%)ea0&W!xCDJVT!KCwE<v9fM}L%{Pb}lM
z>2KB(pWsVE_yoO%@CmvN;S=;5!YAlBgip|O2%n(q5I#ZQA$)?)L-+)}hwurycX+Pt
z@+9u8V7%9N$_U>Namd6V7IAQ%$eou!&r`Vr6X0BT`Yeb?93QSIy%3Be4$jr14HL@c
zO3~B^oZ}JYKgpGgx3#c$%+D9tk3{Pm+^ow%E^jgo>vekvd|1aJ9ni48pS$`dm&Llz
zM>4B1$u!i%MjgmZoitRSp-<w8>;@zq@ym7*#%aM#PQmfi_DIw>DIalrCF0D9tDO;(
z;3T2FW{5|^G2YOoq_4B{n+3f6HC+0*52t*5FM3s+v}2rES8m1KIy^}W*~v@#y`P70
z>F-gv^z$fO`gasA{W=Pl{v3r%Klb4(L7r70{{~3d$<TF`{_N9HZt2H9TyAS$hu0nL
z4x842*<dcWn%jovB(wB$KYy~$C%9LA?~d|q#HSq{Tl2!<u4qfX%DWh6R7Rw<)&wOx
za=U>#B&p9a-`rMb&tu11Z-V9>Z#}}zYRVwZ+u4D(f_SS=aPJuFcPNa_Xxey7PjIis
z4kho9nHejKTY-@?ZUupyKjA%A&C4r0ZXJeC+!_LzbgOd%%vIUQ6t|S1Z2ulA`iic1
z+%inr@!nWSX<q}6x0!**+swe@ZDZi^b};a`t_?h{YXgt#)WG99HSoCJ3_PwM1CQ&c
zHbp-M9@me7$Ms|2as3#0Tt5aL*N=h6^<&_1{TO&$KL#GxkAcVaQ>#~ash=Z|0*_OR
z=W)$D$P&46^(YNbeR1U|4Ntvs)hG>5{c+_d4NpCC)h7*4eR5SN4NtvtMJEkU{c^P?
z4NpCDB_<6|eRHKH4NtvuB_#=;?Ahy5?9;&G_G#d8`!w*leHwV&J`Fr>p9UVcPXmwJ
zr-8@q)4=2QY2b1DH1K%;ZA#IPfyeb@;BoyJcw9dQ9@me7$Ms|2as3#0Tt5aL*N=h6
z^<&_1{TO&$Kjjqt7<gPi1|HXsfyeb@;BoyJcw9dQ9@me7$Ms|2as3#0Tt5aL*N=h6
z_0yc99|Mo;$H3$IG4Qy43_PwM1CQ&+z~lNc@VI^qJgy%DkL$<4<N7i1xPJI<MKEIz
z{FZ^o^<&_1{TO&$KL#GxkAcVaW8iW97<gPi1|HXsfyeb@;Bo!5s{YUe^>bXvf8&uh
z?6Ppx-ky=OZ*XBjd9qpYU_Q=<4iAl+)#ampUkQyj)#ao9&kT)Y)#YRR4EqE5*nWrn
z0Xf;e@BM-D*#6u8f%0e{%m0D$Xg@3cf%0fy?}p-m>e_+!_t_HKS#tc)p3;8}Jl=l|
zJl=l|Jl=l|Jl=l|Jl=l|Jl=l|Jl=l|Jl=l|Jl=l|Jl=l|Jnr9Sr0B=M<N7i1xPA;g
zt{(%B>&L+3`Z4ghehfUW9|Mo;$H3$IG4Qy444nGmxz*r{3}(Jb|HX5wQ8@L(bE{D}
z^}|!DQ8@L(Q>sxo^}|!DQ8@L(Q>sxo^}|!DQ8@L(Q>sxo^}{o%Q8@L(GpSKH^}{o%
zKAiI(IkRcMmWBs8ar)G(y}GwiuVFdOc&)35mj@$wIf0pmmlKz1csXI2hUY3I@6o2=
z<pgCKUQSG=;Uo1A?GjQyaz@qWkKrTrkKrTrkKrTrkKrTrkKrTrkKrTr58>%w`3A?y
zXy549?DhbBBvKU4w>YkVeMRAmKzlE6K3vWOzk_}zaD0ZP4hy{e{2)$p*bmn0hv3Y+
zVbu2no;)4VQ~&pSa&|<|_UKckJVU+y5t82;gIO8JQ)v1-EKU6GO1a)1-40$FQs0n|
z*wLTmBlh-Z`G{TqSw3RFf0mEf`Jd$@{o&8@k$&@M_zXb1bLZy-ufJ&fjM@*syc1ZC
zy@L1cH_X2u`on=<zgp7#+%dZKPn6Hyqyc{-zxdaRdaO|Ys`^cZ{8jar3i+$*Cl&Iu
zfAB>6AFV(81<$nq(fsTWJm>yL^RplD?E4?dFE<c)=f&kWP80WA^1;-*V7^NeYwHTM
zv39LM8*9S~w6XT8KpShD3be6ys6ZRjc?vDZ*W0lBcn^}NUz|H_%;PRGH<|OLdYnT&
zw7t|)tkZXHo&)U*Rnjy5Vf=g+5<)^O2zWPyvBOC`<LKE)X?VudZzHAQ8CPF{l!j+~
zy-x)^<Lsj<@MpaJV}<;TyN6WB&-i<d3i%m_cdwA2@%Xn$Y4u}V{$q-Mxx0KGbUT;&
z<;&k*P(j>K<ojO=j&a)GS#Cl;#%d3+P7z#R@MJtVoAn9fFePZiO_?^V4dFfCycxi_
z%gsED7574_HV;o0)2@zid2~R?xUhvml<d!tj`qd<8N)lBj&{a<nvUpbZ``lxh>mv0
zeVdNxXn)+l>4=VY$bFoS=xC4J&*_MccFBF6j_7Eg+~4Vlj&{m@o{s2fuOD^LZnRC>
z(P>_}Y*^Y0akQ7w9uFT!yS>tr!^hEXAM)xfIQk*>lgm9jAueBPZ047hiDzHQMfeI{
z&IL>i&IOckezs7jk3Kix4r5^N@-@eU16q7LwScEZxiMd>$FxFAOJSz{+`Qb+pQP!{
z6Z+=vL*9K~Q%+D+pvgC*9@WsvyQVm&u4<CXwBI0STL`~ObSStwI-JHAesu}u`d@(*
zy81-A;3MgxyD3R@_Unzps{&0(ca`XT-5rutW`gc2(fPWoNayLUf#n)As^=vV{iav&
zkUvg}nR6yhq${=RPr>IkB@Z&SG!+_nE5gu}NrMl;mZuk6qBL?cdpzDD#06d0u=&3A
zY~(ozw<^Df{p_b#68XLH(*X5f@8hkzIe^`a7iZ1^<s?nH6+T#fUIOI>mh!R?<>e7d
zu11i<ohk775jbUd1F#Dq?aui6=p^?|<b{CR^F8{z#_og6uzBWMdQ0<G&ht6ek&smZ
z3HT7w4Um_>`CM==xDz<*06GI|Z>*`&Jzc)rzNzK-qUI=Pf%*Vyhzku(?Txym{+92N
z&_%&XyaOq{FERTP%e|r<!`$?j?vqMto)XCG=K(w=PfbIiX{xJZkVnH)@=R_iG*3y$
zqv1M_$Q@{5s!@X;1&oCTWf>eY>K57$b>(YDY5JU6Xu_O<?X)i_mtPBOSXo*CA>#pI
z%l$=bSfubvYN8@MDLe_aSMhOPK8>S<!qd-(Z_~G><s**y;;qF&#?<2wTaT%_k4OnY
z>7+DL$GI4x#S=DyleHzhQ8caC(w4_{5Paqc8#Nq7;=H9|rgyYjNe<GIB$TGBN=>(e
zlC5O=k$9cyLHR5fM=Wj8p2mZEHCyHI)R?h}K&v=&S~6czpJ`>9k)j<<3H9(hCx*+B
zffR{8;AG1YuEO&ivjMFyHNcTV=(aND=Ur9(%B1M`l7RClJ}W*5_oK#@$76mpn8%8=
zRbC02xMn==;M`Wmm#1Rf?+>^O%W-8_j^X~2<!*WhTjB*kX!Coc7Zh|acomSKU+|9J
zm8j~oNdAk|guO|aeN|Yr_j({jOndaxlYl=0$sZH?Tg|@{<Yh?I-d4W@JX^EgRW7uZ
zYDx{Iwwd@<S8Og!#uwPgk8*TozPh3wi?G$8M-;-B2iyT+L!@6Hu+0<Tr2h@6wt&lG
zD26>!>i!Mj^2HJ1u?={5MLJoQ)o?ytQ);Tm2}SDoXTX9sWgII~^Y|m*B*pBwxy@R@
ze?d+C&(?lPWcV2}=!3?dT$EQ}Vq=}~sDbUndlcJ7mFwCYibG2c#l5g#J`h$;c~$~V
z;3HYWjo`F2pneOV4%kmfKI}sLu7!L)?B9Uh7lHj9uumhfGXYyAQpUxAtr~$n1X%Y7
zY%X9UBK+<F>~9g+*?_Gbfn5t&uL!?G0Xv+j7W)ZD@>X89D`CeFW-XfSMA!*PVy!)D
z%4PZrS^;(TJIWHAysb>Ved^^QoLb)kGO%6ib-R)SwK*Yy12uY60-Rc1lmMq@w*&X6
zB-HM%5jZ6oXeGJDNkW|uj!;rU>V05BiPZh91UU8IB>~Ph7!~0!qsbV+`6OOjOFITT
zbB3By)&kCWavJ=siM84Rp$2QU+@xu<G-XXAZwkzaa>Tc&Ft5V7@NCzk5hu<;sw*^2
z#?{dFRz3SN%VdTs7*CD>pSmIhE6;?x<!Kl*LXf|}DK8~C+e&h?llB}y!qQ%8X|9V&
z>v6NP8t+5<I~J*~*oGV7>KmT8Cu|lHT%?NvZvtnD;&p`}7G94=h!Bixw?$}3(p1(j
zOuMl!%EzanJxG7R8lhe`6fa3Q`%X&{(MD?#ujCm`-HS3?ip>oLK6}{S(t<0n`L-!o
zW<*3{=Dzl8=kRLMdX%B9WoEb<z*Ecj0Y{x0%M}Y+7LkPYdG#&DBAdj;D)%FY#X(_2
z1trCBMrBSLalF+Rq>-8bqf!1=r}^TH=7thR60Zf4zi4M<lJPU`%XOrZ`u5WI8jK#z
zxBP+#ae#-zCjqtA-h_<w_m_2I#3FiL2&i38z;~INYUP^{V&#i~N3dZLM*r_yPJJ~e
zw#bTG8QxQ1(>1y$tPKbwiZk@giZtt6$VkwbNP8nd{(^QK20kX&W`HySvVrD9TjPvw
zPe6UICR!Q?xNX%~l)(}w0w2i0dsMZ6)FJKCP-v{FD`0e<R-TGrtrm|aHw-ZE0hEBB
zT7ia~8-SOwyhcgn(gdj0C5QBBg_csG1}i(IrhKt!TB)Vn)JW5}#{TU$l5ge`=95wW
zXymi?PmI*1jgQj&(XyTt?6a)N@xVzGP~)uP#FQM=;bOG@Y~a1mG1j+~8=c1*VS7El
z{#a~kZO2Z%bb7CRZZI^J+n^g<WWxhrJ}U4AQq$8>UZt7}-8rDsuV*K#9DUlzKc|BH
zVqND3WpV<70FB{1ra;gfBZb|8pN1sSgUE0`V3lOxt_xo|ycBc{aIuqRA6ZY<0m~W;
z+N->>2pfRklROyt@^!<%16B=R_Ab_;8OiTm93Ls)t$@>veW}ExsRQPxT(?K^6HeI<
zh`_~f-39pI(QW0C+VwLc<;tIFm!*NLG$xboOxV>!NR{Zsd-0|abTM`&9@=djJX+5Q
znE!sHz<y2n)ZK$9zfzsqV;%+#y~@!#{*ZOBM@`PLg9eXv5rTv5+dQ&7Jy=(J9JJP&
zX;PsXE?bt`e-1SKP~H^G2c#drV9IE$!E8vzd9g-H|EiaVtw26+TbTHD*5E_H=w)Al
zZ?4fgVeXG2lrnmM2Dm+NU<YmeH7vch&G}Fuis={h55FNHG-xl{D4CLc9pTTKvMuHz
z39a;@<T28ft4Emcz)$9^X8n-0_#sk?)Z$0Lt<L4iwwX<}dRr<#xuIMG7i3})NGzlJ
zNLY{c=NQMiriQQKPD7rCy4pfZou1Xpdj3xV|4PbocL>K-!CQLF&zg609%~AG5DvEu
zgUH6maY@niOcQry7!kqzX)r!q?#~Ha>iZkYsV&1&bXDtgb=&oj1rx1ludm0~G)1QW
zQ6_X1ZH(4oi|uB&*0!r(5E0%Pz&hg1{A|Nzy!_IWI|0^MY;^I7Sjy6X2aRK-4I0RJ
zDO%r(hG$c$w%j0dH<r~c0+%{;w{TWM<l4}Ku^(-X-(2-wsQfjcWZPwc((1Igzwt}H
zZ*^XyAGlgeWhQrzH7zDIoP%|_i3z-=)jZzqO`3a<Psh)M*^a>749TZ)CWphyIJqn2
z)#FVYJ}(`rQ84QmRDp(?+{0?Jw~iLYr|t<T=3UwcN_+1GSf%!syrV$}=c@A#uo1}^
z!1DRJTC8YB<1>3z!5`~_C}by_|A6%TdV4-0w~n#O$QRfN>wAoanEHyZJ`T_z2sgG%
z8=Vz_lf#LCF>dRD8_Ol_!)fIwM<|8!sR?j$J}m`)Mg%Us;%ozNu4$R-dc_<MM#;{@
z?<+96oQv_Xq^TanXz(<WL`tN(z*0Tws6GHi242Ody2w(!?x;2g#ZDd-C0m3!=a)!+
z&P#00Ph8GxKyimh#hjGvSxRPCdkCW(omqkhW2w7DU@SF<RSutyWjw<&Y~BIj$2mtU
zq>&h_2Zrt*o94}&qsQi(ZK{_&dQ2;q>UwOxrT=3y#r&L)Z1)HAv;C(d{{=`=zN}DD
zt`?84z*%131o%FH?VA8!9<Wst;3t63i;;50XIue#`ixrr!W~A`CVVjg6XlsUUSJ!n
zfxOZ6T(-lQ1UTut0q(E!N?F%*P!@Ua8_CN!^HKQGcabW`nc1%EAaD0bekuF93T2Ds
z{ulPb??N<To-X<H$ZhuXf-p5-ufMp=e6+L2ynMpz7r^vkV(3xm9`#@{n(9{r@`xx5
zOXuhRVdeE2M92Bm?`o){zb;POqVD#Jz*(;JtJ(%UXkle}06gA75*SZa+>Y|@K|=jm
zw+6G^V=RGuSnev|FYE4vvCI)3jB>CI)+H=h{@15A?gQ_KQ}{C<`FGX%g0*_7*VqW0
zt8VP`)G-^2@;?UN&!q4tJ==-;7kcJj4nD(<U^raYRIKIK9$IGVnD$xldJ(>JWkeK*
z=n}}`C2}wUXeb9Ic#b(LNWhkO1qr<kv8U1aOFq5ncbtUC{}@H;?>JC<uT()xjd7R%
zHPHHAMxuw;0cUT=&KNHRV!~%$jHdS9s)9dTeJ<#3K@uM?u)7Jf-d4(61Xxme)YUsk
z&f28Lk-BrupXEJ>B=wOsf9jl;{I1a{CO>)!)SlMi9Rw45zl*#!ilZpHQ_7+zyR`T_
z>5(Ec0|}YaQHFbw{B>W#9zkMzQtu+CzZT2!bunnN_+ZxrSdtlqNl9(V>a3Lff#C)x
zY)Y0Id<3|QL#LO@vPxmr8trlq)&XRO^<hBI8rK!46&t8MsK~rV&-aR~mzNps=g5OA
zCDTe=g6FFWg<9;LDyPLS0-iX90vTk9JS2o!$@&bmtno};W0`m8xsIHSAP2i7RX+u5
zv-tiFqg<i=GANBTu&>P{N1ezWtQvovBDr|*>-7q3fw88MTu0XR`o%A{&$m|EUA45L
z^Y6nFzzx@-+Bk`3yrb0~<8tG>I7Tv*MelXHhY~6O5b!b*kPz?Q$XYRZ(3f&Njq;#`
zKUoRS*Ak}I%gzc=Gd<$aqpnJhd=3fLA$?MhXnJ^t4E0msKg|e52}XJJ?AP>?KO#kW
z=(gnAzOb+>arBW7B+&nd8emJZM9gU$;MZh+@C$I5Tj)quWc-cvFxe(AgV6sD9Oe_6
zURq1_aXrMkXFH9EEE5QQHb$?f4H0T%&Fg}8XIS%w(0;uh8+uv@4qO33J#_+PMI_%R
z61Fm7&L<kWH35tIGT}jb8I=jk;rDtTtiSbX8v>?RHrXR^-=wbG&gE@=svF(5vDAcp
zcbvk-dGR7Xaiur{Ql4%|^jGwq<h{Q69rK;^XQZdBzCRNWvk~BS{>D~Kn6v4H=ra4X
z=)6}rPi&qhIcV_{K>Jtdd>?4ooVF?e@()0Gmc^VTIov`fgdof{Ugwgr@UNf~eM@A`
zG4kjLoci7Zuz^T^J06VRhj=jIdpux1U&+5WX}uZC#`wLXm!EXx*_=Q(I07Txp-3|B
zNE!P?U@T+z2#j^1EHcXY<@zw@Ww`>A5y71P$T!rw6CU|`9Px2`oIbvxL4PBm*-!-M
zQD=d#8@cq^TJ1FOUN|;T5ow7pdkE2eKF_k?oOuM7v58^k?B{CiKZSXD0lDKCj0+}m
z$4VVHJ@D-D49ib^OascSFU`nL#;$X-J<}}moT%mY^EQ~=@N+UoRg_1c`wY&}rsx4j
z35zWyoY#~-Qjw=nLk9Mdt03cISo^-PcJqP=t@>I(eXEq(-T=7PJ;y<_vF=8Mn=9aM
zt$@3|0`8v`aCZTh&o|q%v9zgRbh5bV9@5EqZvszR^+|yL4ax7dgk3<G=Y0vAizNDy
zNK$xQ1f29Vv4n>J3+pXdWv5pq&r6Z$RVB|O=C`+>1jBAC>1bPe*JGgZ>{kf%98cu*
zJ+H{fI!RBJ@*W2)+%vSqy2Pri)ygI#?7tBOaK)|>tJ?y50%Z`^+RRm06InlLV0t8$
zdPR4!ai><V&P$BzcCj@gX!l>~0cxk{5WavzKz_vXH0$T#^4<wdov+kt`Wt$Nl=Cd}
zSUBk=7PF_V-JO8&fos#VUP9h(>zL7JnrqdU$<f5G1+2(hN7YiShxJPBJsRBvhA8OY
zZv;GSe$C2Q2d;NvU0;vaGR`lI(Hpil1LmOZO)eK!Eo6L-mt$>)E|#tBl_i?-WOu~I
z8JjwakNO~xDZIa8Ya}ZK!uJ!>8_G72a1OHj4B2|OzU&Lo1RAHUzXHfRNPeGw9=~6V
zz(}{4Fx$`BCkgu)$wWHFR=>pW{3x?3HQ2n0GuFIIZSY?ie9P2<JV9R=OZ$`l^$l^R
z<@dlAroP%V4s&y!-xGVgh_ehfP64wsyem%+{Uh>mWq2;u(r38cgZ}^uHY44p>rm|3
z4=L6ca0Hd5N{>yX8;N65gL!cagC}T3$EmdKJeV2uvVOS7gR)1r;Jef<Ge=@aC8*^u
zkjrDgJBFLl_>|o4Gd%ki8nX2WoQM7|crX(dQU+rcX*5fhzQMA`;q;cRs?@^u9kope
zPf@h=GJ<s`p6~54*3g^PLH(Bo&bAO5J<o4Sl<>fX^isFmvjOC@1&jDjzLmj)?NVE+
zV~fP(i{PcjoRviIo+^WV;{+OAN6``G^D@R{6uhs0+JWR>6?Kpb3@gqsrs}o->cFS9
z58wZ+)IMF2*Tcu!ryKE+_7Q*7LHl6-G96zOz%m77l^(S=_!*bNBQ>T+tq<5}c;@2}
z^Bktw$9h`G91Rg$ncc;=2OPY^NG82Gc~{WTNPkM(;nP%}zK?(`dR|L}%;$lpWW6BS
zDZqDKPGsE#kegRAD?vv3-h_bW@}-1kYd~HEWEWi@k*5TxweRALVlAKa3WA50R=1a(
zK-Z4fEcC%1cso!U*^UA~p7;6~=e-WY2#0f+fE<IAb{=aeXf{U#ek^EQ{1n|kna+iy
zd>b}T@HkCra#OLcM?<-3@|JnVO#S<9rdv1Lb;7#PjK_zwGHIRD0Jk+o<4@Ha;FuBU
zTOQQv#lX|2@}`2(;SCnTGxUc!FMG4*!(dmB@HkZle}u&&eOd!@h-R1V$?`g;i}1rJ
z9p=X|>qL}!C6Yg89f#lNMqnr4_dE}_mDT?pfOV|f&Gc#`%evH~mzgcgJ2L^!GVe-&
zv)%8Gz-0uw2k;_>fqbhzwIln@Sgw=d+gQ_cpkuGR3*+2j_=dI_QJ)7?&W#RiZXT`o
z67=As$A@utnF4E(ql&nZtiP@#anJmeykqfE<{`42IiysW+*EFD!vspod?_X0IDN)-
zxO4<uUMM$l1gGzmxaQ@QyyIo*4~O^Rpq!<?;?uY2L;VArORWR<8av#@jIVk$j5-P}
zMdOn(s)_}^=F!mMn<G*tJZJ@-^o-X%I;e4AZChzt(Fo^g-U!nS!ALn&e}5Ewq@Hhv
zX?Abo$;i6>$MREsLyLtr91{%Pl6fmkKN5EtP1&Q%&F!9FT^OO$@y&1@?K%JSc9_Nv
zMWzxI0L|jgDlZDt8nui=>^fS1bEG)1mG>wJ2-@VGa2_IK^?x@^voGFxw_|w_lKFP=
zUYvgKnnQ}UZLAwUiAtfz!=p&Ac|S}aR_rMA^(ATh4?Wu9t@|Nrsq=&gyws;2-N?bi
zhm7;j?7@b`Mm`VGjVd%dYYTY&=+n3$6db|Vk12nN(6tpqRdI3C?;hPK^S$&z<rxDV
zo}XwJKM>%@JDbgU_%UVIM|Iz%$L|dMcknJa-lL9jxjKb%?duJ4+%YpAXep0oY_ZKa
z0hn3s)IHj<!GT-0Mb`_L_Gz`d8_N4^Xxl#9_SfT<;n^K$HCl119#<oDFd)&&MO`qC
z=*d|P58OK$mh<@5ms)TSxG)WO;q+-_Y$f0}P!Jui;?vsF*&-6vbOD~<qT>uDuZszA
zt9yBc?*OZZZXT`~(Rm(|PIPkIh~sJD6sb_I=#kMBJkDTqVZf+ycbq}f9%vknZ8s^r
zaAfqeCS^2prD~l1aJlNt9Z|*?YazcI1NBJ^|9}QYZ^Q~x);h^$r3@0TD3`xya{jcz
z!ZDChYUAYm;Q_<t3VNwonbbQ{10w^6UjOM1zMCV79{l*I4ZY3kH#(p=FR*nW7c3<l
zLy6}p27HnR9UZ|A0UwU*&*^bptngSstOP?FTJ?0<&9A&KM*uez(_s_0j{qk|ZH&>5
zah~Di5GPm|93T#=y4lRE5FS0);>FwT9Ml1sLxY{OU2``>>l!r4gPriphxi#sYzHv6
zveK`Mt3CKt8k9_Il(#i!yn2lDHU-^6=~1Uh)D)5^G@Q8zHo_|wnMyA{fO~3g6(f1r
zV-&kSWE+d*N3p%|dw>TMo;4x)LgPcL9_qaK>ZqVK11CQikJFS8-;bp;DK{ZZarNSQ
zft5EtG=eYpVK#tFQ;?E+%J@LG*pSJ*tmmjmUcy<|ei68|$1tC#KfFR7nS(dNi`BNZ
za5{@CCbflTMpPI<gvSvckLd6#y|aw+Cu1SQo`=R>Jd`6rH_8&ay~4brL$ub>V$l4C
z6ifqy9=3asKNy+^2KXTx=>0z)g)3uMhI2YROA*v{TvGn=K|I!mdSDeBv%&V}=5mYP
zlZ^5h6z~WQ|1z>p2M-k7P%ckJxEYLiGYuR9VTy-H(7#)^EPRc%oiXK5a9~fyqs;G-
zu-vRq#!K7v^<-&l*rV7q2AkF8Mi;*h#oo5%n-);GwmA&)Sz0zFs!*uGbkuBr<79=j
zp|>7UTWHGTO#JkGqlu&PHRT{~kI=Q_d*st_YyvMJXe-JWF!}J~w*>kbAji^yrgR?C
z(^V1cbuA4u!7;cHsEI|^X@P!NC(dVJ<J0vFiDipl@X8L%j&$ILvp4NcIDyUBZWeU3
z0V1ki`{OI<F1GV?x0>x1_JC>ZMKX&?TcHV;VSMl$l)?zIKTe<?<K{s+Vl)2GlhK&C
zv=Y}##173#z4~UolHl3lWbN0QXVf;gacvv-##`ME3C~I3=>vQ6&O}I;IJ*t{$rXU1
zpP--N{R7k4o6D`OCCtnmFCG1v(+zIC^<X9-L>o}A_k!PG=ygTJ%twRT+_OCko=IDL
za2XP@rMdfYSC2SOTK!+(W-ZyS_*;`>eZ4lhzY?8SrdY`XF?x5e1g#F%s7-&!$GGqz
z(2AFjo!fP*O>Uvdjn@x%P(~nD;8h>ddD2H`(MyCbHu8#Bd6fKku&1dwT`Y@r<7jg}
zaCagFCTLFY5dIG&@lc|(WUKWV2Nrud@?!vMXaIT&+DYVjjBuO`!KGe5qr*Q=e1g0(
zf;~z6;1*fQ*CF6AxM$z{=(r0s2$F^raikM-^#%skaBmIt)S^SZF9SNb(?mL2^Rp;#
zI;{CXSo2BRZ#-`yS2)Ov7SiS*uUg1H8X|Rn9Z+k_^?1nwpZ9Jp)z1ui;=&LfeX^-I
z8B=`idn5vW7c})neblQ657^2(#o{GCAP(ms^vXb<Uv@IR{-Y4QsB7^FV60c2mQb|&
zd6?4pKMuRvVhp!0Lp1fybABC$C*}=HGTFtX--YrvVJO0VNOVJ5ra296%Kiy-ty4<%
zI7*54Qi7W_KWlio9j}h#L<P<zVYHT=Vtao?Um%f|_zm<yOBjVouUHW)#6ysbw=%oI
zlJ9rs!}$O{x`O$jc`3`&joLQA`}+x558jF`VUev9;D%jrYkMgNGrQMft$OCBM?Snt
z*H#aQ%{LVBnj*fkLD^}o%OLL!XjL4|P^UQU%1tkvWlYQ|wOfu-nip#lYqx@jXYHgG
zD*<k@1<~6oq^*Z&(`!S##L`v;-lA(TG}9g6i7{MsLQTZhSNC{Wtczs3#&AI~V)xww
z8vUkDh_4aNvJL9OGL2lp`2)f<x!2doTf@lNvw*c&W~tSlA!%@Za2>z}OnT9IchVbQ
zHKxcgRXei)zn;azM;Sa99wCS1?-9jE^6N7S#>bibTuDZL(ZvSLzaI#O)J!%61KkL}
zQ4BZU)n`-Uyyy6Y-{yo*^AKKpZW+PxYy@Y0FTrA8N0M0|$0owwMS>T^wGafHp6+!|
zsMlu|F~IN^WI#WqfKUdZuDz(}qQc9A8J&4P(X5y0>x^Q0ESE10YzH}IyqCQV!go!8
zb3bYK2wZG@80%}IJeqcFKWRMhvY&LO_R94Z!nKMsUH>gb__Vg^$9Z`_Q*TeP=g$Dm
z3SE@i66+;~*NGOgxrT@rIi(6-7sPm78{)+_8wALqNYZA6ZH3>LM_~Q&dvpZ$7yQ04
z0^0$<{}F)=!0)3Yus-;GTLjh@zt4`qcEazx2V>h(<_4r#+X8lR0-Un%nE<E!cP7AD
zhr1(iw#{RJ(VowSS3Xnkps{9$M<^*FYxl1NIBR%X0-Uv+5P?feKMuIHK4bBS77z#8
zjuEU0JVCnp`iAz_DYhd7o>aWdlc2G8pba7W9eOrvHy=3G?i^ja{x;@#IUxt<mmH$G
zB9F7`hLbU7trc?l7>Rut1>kUTFrK^ue((ii`ud;@ru1$-FO1i$xz6ooTq$^cPOjY8
zSZdSML2S4H<%P88E6DSo=hCl)v=@xz#!pePR97&@FptR+tko}!=?lHvJfrKzC~EsX
z&{0pfYi&#WEC$pNo8}ddCio9h@Dka72)tD-l#JtX_H4Jgt78UcY1t{8CTfP>$jXZ&
zo>)ha5xeSq`c$^f1>2J7LPsy9)<PR1L9y-6A+K$ny>$Sj<M*-pbd<bo_9bX?@Xl*M
zQ|CB4`6kdrDD05A{dW#;&$VMxY>xflB0Qf$w*vOHcK$;JdK`byJM~db{N(c3N7Y;9
z5WN%@UU8H0B#^zWI0KtGo;Yq!6QRModE4~onP$_5L9dU~?I1)h#`+)RG%xQpm3h)1
z(v=!a;O$x`(+@Pd-2=PN0fw&L($<RP^_9+!Ht;YKH+VQFt60F&<ToAXXgsS}7O+Dt
zf3flv0kd8zxIm3O5)ZCSK5Z@T6{7*FbJrVI$L;Cf6KZ$jHIup_W`nDDkKX&VVzC9|
zY>(d4>$dCDZ@V77aU!gxZl~J%9=*p6?$LXHU9Vi%&gxol@Y6+DcM0OFE-14e-M<Dq
zfA*|_(;ab;$KF0MX9qv+6O2!CMp&$VHPBnDA34~q01t#yEa(}4=plv9%{tZ~AG~IR
zgDEba>lVNemIZcl8fp`)59Hk<Nhs!JUMki+tKeeGbwY5k_1a<<UfJeTI?+7qGLM6s
zJW~G+h%@mNk7dQ)B&C1c7BuoM%cXi$Sr3qnko-|!{9eC+BLeK*gXfv{v#&N`Jz9ES
zf6&T?8derYx-$kI%?<&-2uWatJA=kr>5Mk4v5Ix>ngZV~1wJqWm!1^ik4a=;jgc}!
zxJWr6T%;_GlioQPa^y?>`?ZyW6^GpeScrBH2cPchJv@MgX!q1`at+3UQ33;{l)txy
zP50>b5tv6emav8}zkLPf(T%q-pWguj1D&+jfrPc&ihGuQkOv33^FH|iKHcvL1rJVo
zsaLIrYk?h)qJx3b^M;cJj`xK`zLJ9(TCoqFutzUytu2+<(MmjOFE*}EsN=<2TouHX
z&G7kj@h(%z*U`9D5Ld3|FN{6CG%}xsbLJ=fv?mDUfkS{mUOvxL01@;f&r>uugCTo=
z8D;dvnBNs+{#6=ssD-SoAyUs4K+!?RG3XoKR9BqAQ@1?43jX44S`%s9u9=H0r-9CT
zr6F>ZG`8u7`bdPqbFwjd$2K?%BkeVQHPD;K)!jO~;QorT&D-vJZ01cO=Y5X`&Ia6W
zO-$-`Tp%+R4B@)#8}#*2{7>_sE{_Mzq0l9kywr6relq6=uoHpsz0EAPX-gEVBfh?f
zWhz~!*@2%0PF!nj1gC3ttDFnS<=~B~S;&=u%m)O<35fXTYXB8j&lv+Ru9hZG!9rHC
zw$zF!N%#3|*EyiO2+5y~5_WL}b|QYCmH<10Fnfxh^DySU6iLR6U9H{q?FL==@Lf%R
zi^6+)@EbtSn-+L13J2%S$_?pnvT!}5He=_@5a@nE{LR4E;EH%Fcjj<A8YgJ=xg_dF
z@MaCrT(#5>=xOcXux;6#qoXe&?LWY)t~8BzyS0BI>{h@K?2}lxE@ATkYb;DH=4(oP
zw73losaLn8%-a(1IM_;O!T4}GcVuV@<aIk~`Ls3aCjFW4e@5W6Wy0_F;Q9Xj^4s<`
z`;^f<So-yf#Q7ieE!yjS$WIGe8#`^+>NPCpe8lHkiw_2R5>gVgn%q#V$Gr*ZRgVE~
zdnk+?E37(CXF3(Yxw?el$@UcH;TqdhI#2DkeOvV6FyE_oBgHeo3C3t5+x1z%UO*BH
z<2sY@ny+~^V#gM5hwA{`cuSV^vc<J(B(}F%kk!D)z%2`!F3`XYuE&1H9Ky`G>tF@(
zbAuO#Q;H3^u8$gvuly2t)Yq10_eAZUfQ(gNfkwY{j(h_9M(4v>1f0+k*mnlTdO7X<
z;PbbwLrwqW!!d-(c=0pfx&idV>aId=JozPrZ@^JGT_HC<{Tjx*)z1Hh;9R8-#+u)O
zW1F)`v1Q7rwhQ1KyG6z<;2i5{3!cUtzEcPv$S8W+0ek((-c;Mf_Z`gM$5P=uPVQww
z@UYy=0ViVka<AaQDYsburW?4}l+O<8dva3#*1*B)4G<P5_VFENEVj2`NFD2LDDhk>
zeJNK+S4VlirHg;>M%iVBl<zX=byB>_;MO)x-`)gtZ(?M5A1c39k0AXm<XsKn>f_3Q
z?11Et0W0G7))812{O;kwC?oUkjO5EmIP-6w04I;NBXDUuy<Wipzr?%lrtQocn_jUF
zroNsIeY~0e24wVYLr~T(=-C_U+DdDgwI{<>))+(zy~bp&^Sj6+wg!%QDFP3i$_TF-
z3ICxe)y`BJT8qWd-psHBoYXd&PZkygAI&RxiB3jDcw==0Tf)VuQM!>G(1|Yg0$twJ
zz*+ie2MaVU^$zHz#K7A33Gzi7%6XWvjs~*>^a82(zCJuC*5O0>q-a=)=p~##T72NG
zw$mqt&{wtpFg<8I%I2-}J77U~xOKFNfXbQ^HkG-mgaf>8xk!(z2ZDyX6whH#;&zvF
zQU^Ijmo=c%-&;f1E>A7s+;Z@CbzK5ZJVSkmzh3IXmazT|gf;abq7KWVm%PmJVmUiz
zbBH}m0dJmVX0$JII+&+-dVr~v1IhOc;`yeNk9e<y{he9B%gNK*P26iCJdt@jX0Z6O
zD<G#M`CjW#{5~oIE93Y19*nXv@5xBMY=kraVF_^ZxF`Y_op3)hZ#Fcwq*sFO0@w>9
z^xNH7<57v8+&FL*a##))7nrzc>>AP-jScp%q;RZ|Ua}U)VLKnB4M*pL8t)K+)vv>R
z0>|hrWnPCehugjSP@&$s&GjjA`L}FuB#oQ*20Obq0WM&Uv7*si0Ix0L(=&k4hu@0d
z&qAYXK%@V18odKhbM~s-z^Rx&O5X*Xo=f3LNgsZnhGR3w!o`LSJrB7QXVl{9dnx%r
z&~qlY7fOCex9-ChGTT8OwGe&-%h3GWLT=GCqRl4(wJlhW;<2TpPh*tY5Jd>hGZkpW
zmpvb$3A_;IJg^3#n_nf}%T?07S|weyo;c<e)YS9I(Yi+I#HwFIxtPHgIB~!!JH2Mx
z4xP!Wz#GKNR)ZJ>4v4WGxf{^P%R4An=-*mG`egoklFpZ<^yxo*&ZGnWar#jGocvso
zM(rT4;NK3(8{j3nd<S^(V;iIW1^!+Nd~pi=!xXsB|A-X+KHTT;!$0x(A7N+t=pgFz
z6!=#u@NXmVzBW?)4)A#Y3d{y4Z(UnSp6@%(V-+5JZ6I2X*ll7-Xveg&67$*8#2@?s
z`LH4c8?K#FYQj-&uM$G@V*-t3<NV4`py3vFB|iU2pb<V|i@Gm(eNhxDvgp2r4~`{>
z>txaP9HxosIJwW&6`OcKuR+?;geuU9>Thizxo^kv!JROd>0?|Q_!V_GoBW(UwG?sq
zU$2gc&-e{^-?r>?WoC6yl;E}Xe<Sp4LpvXc<)Q8<!~e7lEIE%;mpH%J5WEB?`b9-U
zau~iiehddR!0I5IK%<u`=~(j9%Pn<AZxIja+9#KgU+h5S=oF!$ZHXF$rgH*~@Zq@2
zIxnqh^b!k}dCZcG_^;)G6O8yn=2=na!Q5Q07X|A$Vxy}NKOJjLp`(U@KV8+}CA(V&
zk^HLzFWLPS2#HR*26(r^ux0>5AQJfCwKd!p<-xoAaO4o)>uPvgxdyb1e747Lh4WLJ
z;m^NOnt3O5AfV#$x%$Oucs;;2LGq(vo_1J>BrxXZn!@0e{JojquI0*XVt2r-<(soG
zZsv>O7#})k%SgmAJW8uiiUoASbB};7^tPkFc0pMw{|89^tF%(rt-wQGeG(5#S@rvR
znD00-+naC%PJh~(pJjJ5Ao3yq50SWZ!g>gA>Oo#>k`r=^LC4cK!dK{phkXuSx7z;5
z&ovjWuso)t#>p1KRhY;0>}3Z)_Cb=iVc7%ldr}0p6Mi4!!KfGJ9f{=I0O8DkU;>;x
z8Y6J&rDHcotj$-3@n)kv<t|Ec@wi!+(N7V(Szj6aa1fgrT@Rwg&H%g*EOw}_sl?X-
z2Vowp3wWHO6LYQ2BfydGZ*YI(aksy54508h`ht@=$qTm)g*0g+f(OTr0d;yL=w=~_
zo~b9oPD1kaCpKj6)#x|wjcs~c_~G)@H#=F6Yj$?LJo4F|uzUe0y!j-3!7I-_0ZCWt
zRm{!DPKC_&{YG<M$kK^-go4yLnnvH8^iDdA*H$=(IJC_etx2(fkvRKkdw3ur9=0xQ
z8?4G|8V)u?M-AK-N1XJLFZ3AknYw*B2t@F-i1ShEIVg1(l=_U8<6=PWuyQ=(=5uo?
zT|;^DHhuCuL4uDO1*@x<Ib6L%ifu_ghw$XO!sZj49fVz(!Z+Y*{O*;=N14$%)U!_i
z*H~_jTG*jP*7Q1?s|_>3XLU_)u#mqw$jugVyo20oA*VaYT^90ygFJ2_=R3%A7IKG%
zh%TN7G?*#X>fQ2WTx)12{YB=h#q(+{^?C<c^32z8_&kJk{5%DBH)MRCidAhH^mo`k
z*gf~*;O1=PW%3Gw4r4^<3BvDo+F?ERCt*j%yJosV{Yuwq%Je*H<GjzS<YnJ5hE%v}
z5UfWnAkGU&D1(%t>uG`zfCKxb%r-tlpJF(L8lhE14{t=v!}&_K_*;N~3Okvj?L<mh
z=uzWFhO@RsVR*fiz^LXu;_|iI^fz&f-32o{XS)sTGo!YDpJH)`ZTc_|$J@_Q>SE-9
z)VKwJnE@`iA#}y(!dl9>`r_UWCf$di<H^tfX=+Z~$G~AP(>x~-5a?F(@G<uE9>jlw
z{AQIh$|A6o&nTy@8Re(uz5t9pYy#|ezV0hu1F~TcoC$|64dgpZL#v<fVx%7dg{{(3
zb^CCy@+ZKeJND8V`g_JO5*{dI=@M)Gtoh)|FBl2!T-qRQhc@EDe<iK4-EDjxT9ydy
ze*@aSq!r%36HXsmub*(&T2R{~8bh7$!>Z<dCq-vKopsNsb@sEg2R{^s)z|Bd%M+(B
zEmF>)r>q!)1Lx&gIfM)DBk8xdsRd{a=NI*R6Vm^sHeHyvU7$fNS0kL8_Lw61np%T!
zzUPFKD8i#FVbqAF6}aZX@@t5Q@YZsLd22qc&HD3Aw5_$l_gGlbS$p7{UWi0YFRI&V
zVxiAA6FCE#I<f!6)`_hxwG*e|MpC(<bt0w<_&-{*rLDbLV;b=c<-}$<quREuYFU#p
ze~eFY%0vXtc?yR}sU9;=m{zHFtJ-F5zdQ%o3DHewq?KU_OXF`hB>Em7x01!3rE!dG
z-dq*m97B?bU3^t{YIP_s_m1A(-p>!BjUVCX^21yADmO8JFlTt|10lm3agCVu9P!8M
zS!dotY@LXWe@5K8f{eB(=O;*rT#5}t_(*89Zfk_<EiuJ<tjB(QTnFw<OE*Zr(eek|
zVRGxlLStS3eiJ9-P&wZ+$DxoZT1eD6tn0Nx@<^OCS=V8YvBOO6!BdLZxEQ<pus>lN
ze2Zoxw1V|$9#(0<Gi*Fen`9f^Lo!KQ_kfNhitS+-VXgWP*?U|+Ry|?etRIp?+A2{u
zP|Y8dC9W5(l4v_^5Ryf7!tV|L37xdyZXh0@(mnuv7jNTfW5K+|_<t?Q67-P>KVyT3
zG&Z;M{yjX4wY?D-dFTT+Mx93C|HmRpeFfLc;tsJm6Ca(6T-^P~dQp25nIfOeE=;=&
zHsNo5saEbWyV`(u3EIf73#Rp0{<eJzKk%h6<0p;1h|F7r>LX+C#;{wHNBy6akJX@*
z^0!JXe>0SC^8DYFkGfa|MB8ke#PV(Z_03w2SbZQ*8z>J|i0X7S)E5wrVJqNszl;CW
z7{+HIYU?MXaYQy5Z~CJ|jyGmZL1F)&{o7z5zMr#aMm_mZ7AL<Df_;}!?=8-%nWMAn
z=oND6%fDyUSNG=BpucC-Cku1x@y49W&czp?p{Kpi&#E<+&#Je^Wz_kjbLy$xGwSgn
zIdvNj(cQWRW(9|5)ILw<)XG>lVj6u(R{#CHCZkrt?|x5a)N=>t)QpK4wHkgiosM!^
z@u{{o@qa&c!SAas$f~aRTRJkQ4t*x0|GxrmLp?PktJVfw(z^KnhF)UXt0MjSNlyP=
z%i{Qc$6iQ9q>)I&y}u*yf8v<-vFQN&w+??#w&`#9%XB`{MP9lD|Ce+v{?9ZU=^UiF
zHeHFom)pcI={<w=qD?R1?;A+(*uQUkzn{eapR$SnXCBh?FY~;D#C)$JeXxB_|K)Ai
zRc^@YwZxY<&Zzyf_(tYB8TG{7S+xSzL!T(+)GGMP`|C`f6v1mjPIbfo%Uz&r{9Om>
zrv(|+>0kIF)=f%ni;ur<0$2;$ychoVL^}PstUC3@j9MQ5zxC3LS`&Ynk9>~&drobD
zznda4--5Y0)e|(s@&CP$#vxt*P(~eyzhlN`_1`@H|M90;buj+=>8finp8~A#b4G2m
zMMfRpmQ_Xk-gjPBjlkd8>*dsV{QVJjxDWomy?0h!a#2=I!v7CI>YB%{68@g|74Ev@
z@0mzr4ucLK&8l<o|Fb^LskUFU`UJy8_}z7WMzvrPcIB9inz1zMeOykxHzlKXzBZ>O
zY>01f9DqJj%&0R!`&nyFJ&5wRACghU1sIvm%cyZ%=G1R}vg*F?vue*>VfRfr^%9<S
znfT9)IvO_o!dqFjS<js6cL@5^(ph!#NvO*#(1G9F#;khm-_Y@yfWL({*%*1>%&AU0
zW>s!LRz3e}M%{EnM(xmmlOK~a`U_20FU+cqHqEKtgLA6Bn^LrsVVmXDHq-I{AG7M)
zyL0NCHL~hG@PFh#IrZ3~8MV|GsPpMcop7d77Y@s*Q%=B)4EP&iD_ai2S-3Z`rgK<U
ztv?Sd5~pU>b@SmP`e)R|>u1z*n7^+vD5tvM?*?mT)$r|cZwCLr{SuVhn$;&u*ZexG
z`t-}F`@YMn0&H+i;BPu2tIlhNzt{+0U&HU4ugj@T@ONXRO^M$aH|3{f6~A?R5YnDV
zo8b=OciW;pFn1<A+X_A7FHfBC#?h5XuOYpGv=Hfir1?m1BCUWt%OSO){ZHRMt9pKv
zRTEH;t4Cqh{eDI*tjnmCfPd&IrM8)t!M9!ETk!jcEAZ8}=kQG%{Qv4E*gF0`jL$ds
z!r!~E$C*I<T^H%YtMC#a{vLCCRt-cuwZJ!R`xyM$UeE{N_kWPld3Jsq4)nT=8VT5-
zrLwBihZ*(j$*|R}@rD^--H*tqJJ2q#?*dtyGHNZr_W}H<b8~9(-Z^y#eDdzF#~04c
zsPTaJDCE>;-zfE;$Kj7o!5dL<<x6dqRkuw>KLUQ#cR97^jyW}dt&F<&$DF!k>x}y6
z!{`sdZ3A2n*yHA~ffav3zX0rGJe{{E{uYr&Bh{j9i-*7#AJ3?lw#}-20lRV8oN9g^
zeG~t$L;4x;Gw}Cv*fiHQ&O^EY=}N+oy6uruv+?)ZyK-ve8R%#D|Ak0*+?Y{U;qS>O
z;;pumVB7fr0;JcF79qWd^n(5W`}q4VQr%5Cwb!*-)fc{@9S>G4k4HAUApNULPOXK%
zSA35%_$R?u@&8>>*YE$6QS0LW^HfGn8Ula$1!j%#N3F1dd-54|aOaHL5ctDqV1*s+
zdDhBV*s)SyJdja;xezw~lqsWJ$fy<0%&1GUS#>53z^n<HOV`P&2cF2Ny-&=j&o9ZS
z53bIt(@}PJ;6|;JQwP8nPT4T4_Sg#bKQ^b<1H5h}*aQA<igXEVVo%Z{?SpjEWm)z5
z8aZ_!{y*XDth)0x*yATTwectLfq?adO{|M{@AM(;AHP58o>gP<m-GdswQ=lf>s}aZ
z@c%hT{BG=Aq|1?>M|v6QHKc_|A0fSg^fA)PcvpK9q?M4mBdvwh18F4E1f&s2dm-(Q
zG!f|_q$1MkNarG5jC29gl}KkIU4rx^(juhANbey%h4i6K%c9+wy4tiZ{xWT9({lLB
zv>wt(q!BjN<1f=Fr2Ua5A<ag*0_hy2bCLLcnI~;}0e{~_ddo{6;{Pk+{VRUELDEL}
zzocIH|HerCJHr0ui;`n)8fX9RkH7mN<&h3Tnq>d-ZLN_uG2a-Z@irZZzoaD%-{zWa
z|DJ)rd|C25o6g1G3y?0giF8bVv*{`PWqKWHkxdKn_gR|=XCiDx_*bU2kk+$lBm7;#
zOG3lHt0Hwn>h2}dOB#p&OPYZHOPYlLA7oRV{W}?dC5^%VnI<CD+H^Aho?_D+{5{u8
zbMb#B;x9&e25COhBBX^#FCi^JdJ}0S*!-GE-H^K5v=;vMMCygKG19U~=N93Q@%Ixw
zF5}Ded%(Zq_xecd5e`53%kk)M`2RzfXVkVB%g5sXA6|!5O7y`Z{(mZb^Xz}-)V}!t
z+6%I3ON@6%?2MZe@B>e@=hVWlbE@+gjKLpaeEJ(=k>-s0?CgxXa{_4I$*Gf(?~~3L
zV-L)#w`ah2W1QLjQJj<g3BDP)voC{hnx0Wtz-OGaJmM+%))xSuvqx6l1={)e|79;D
zp7=bc8h*;EMfm+7{J=u|o%>iu^|>pfKE(eA)MZs`U+8IER-J$`d;wr1!Rr;o3^<yp
zW?>xeH9Mz%IvTpeSi1&NccflO%OS0Tv=WlQ_r(7XM5;sj8g(0qzu9B5Y7G9i9F$Qf
zU6oV6&qtiMCFT$>!$<Xm-X71Ye_(7n6Er0pUcCr^H-Vo%8Glbh;_oYwUO;*cX#vuk
zNDGnPMfw=&ZKNTCGU~Q}W!0QVFivfPuf9&qsmlgr)KhC_)cZ?eHoI$9t@{M{jmHVr
z9W&~6l-c#ptUBbTta=f88jC!WW@go47!PhiJ8g*gYT9YA1;l*EB91zCEwtwcIdwY9
zx@pavYN|z>49uz3FowQ<AMUcD?RJIjY=ideF&8n}%Q<!Bh8eXVVxbX3mHMGiMxB0j
zM(xrKV>jCFZp1-zR?etd_(1j5w`SExCuh_{cPn+`9T+Qb%BUZY&Zw1PU+sud-<}A&
zL_E<B_<@kKVQ5A@`wRR%{y+TfteQM5qb@^i*nRJey5?&5vJztUJmyn~gX<7)^Gn%<
zwKM9XEz#HB&8RJ3LEQ5o;*G1aY75xKp2t9E@OjOzA(qFSuK?S<0x{uE7-xq6lu_F~
zk2=E69tQlr+j44coQFMbU{+lY*}htkQ`a<R)YD&N)CKP#*83Db4=YU99h+6lVH`dK
zGCp-b;xe>(&tEg@hF%%9-ewtf9_pmNfK5)zslPpfx*)#z6m$8*mq84;2zMr6d!x^T
zA75UnsgGm6_)b<G`A_h`T=bK-vZ@E{XpKEH>IBqf1<11D70@B{*tA_%?Qm39EqEF6
z;tv`1-J=<G`7gkO*Mo>%S6VHnwtYXR?gxJCXRx1MP!8s;_duRUkAeSqA)|JBD5vhl
zJapbN@RyMP$tma~_^VdPs+uz5{)a*LOHSRoEbO)cGEG4LISBsa_^dkn9<(9i?0KhT
z)pK`X%-;+1(VIb=&8d~P!}yQ7KJ);-L=M>|&&9lTG{&Woh%4JO>J7vb`(ZBd=F(Yp
z<GYBV--iz0L=1vDANy~_-j`?9o2cK5@C&PAUVXuSIW=<)^z(mV+(tEO&^`kZlRtiJ
z245+~ynA278pAVc>l|XPYtZ-5|5ojrQTq<fshgfws`tFC+73QsgMBdf`y74t(VSX(
zEOdsL_x9tVAIt^zM>(hCBj=qD$f<eA*A0*Uyo<gz2sS-nm5kb8JA5~HCd$U#=NZ^o
z-<PuL())92=zBSJ^y-)g{*Jj$DWfLBXI(TA{7}XK*ydB8XVedSXAys7)K^n-Di7cD
z!VQQU&(5jyF36}u56h^3A&z|y_H@i9$b+Syo%-g~<xgkT)96cEqW@0&8~h%0wN&q{
zItcTO<6%qFmddCRi*o7^*z7FW-&yZsE>jD?`&3Rnac)K(xfA9F%{g^d5&q$;tXlmL
z*ac$o<Du(sk?*qKv+D7u;4`j*4Yxs88)wxzh<CqvE~n-mg*6V?#{%@7Gmn7zK9N<^
z;X@`ZmsN{Tflk(g9tR=*K%f7q0sRDXs-`Wn>bt2~^(xxpi298BE9Op<w#lhcFF~IJ
z;QOGH?wBWC3z=%b<GTN3)iBr}x|kY$2mBz$o7tP@R6F|g1s7)3$Jh#6_3ezh5k92$
zY<!m<a+mK$J3!Ch9+Shj>+yFk)=f@V>dqZ9YL7eMYaYw0N2h017HcCnK8!V-VQBmJ
zvg*?UY_<o!<G4L!h3{Jf|L?Rk>J0tf0-dab-}l2FZ-CAgq5RS=7z-XloB;S+yC4>W
zz5f0!`uxi9=l5k5T!5OhGvaFCdt<!XZ}p5iVEwFm_96J^wybK*WBffC@$>EQ%dm;&
zPcmxo&+x|&KnMRodtzR5>nd0iLcMN!A8P|>!;hB9s{j55dAelOSzBQac4$t$)ibA-
zLmB^r?tdEzeaymnnn{S^KgOED!#TC%J~_2I@CSW`IVb)OIu8CEe{U_D_2W(O|GklV
z!zb;BzIZYC*5LPENc$iifV3~tK}csKU4Zm=q-&67Bb|&i2kAnj>tXw&p|gqGWYpF8
z{bm#V$ij?z9{(SQBkw)8$fz&T9{F9eYMGws<AA>hds3yG8g?M!dGy&=0s9zfqn^+Y
z(!NM_NVP~mAb#lb9%R7(FGZSzv|t?Ow9x-OA1n1=%>ABP3AVp&PQ47=;m;_w#XcD|
z8*`Gk(MQK%UUkfV82diTsA0Roubl+jK%cn&YP?N58*AzquMVDqvFjGh)xJTz0UnEy
zUOFhNx|Oo3v=ZWg1JU0u!+OSNSYzm#RXcXhs-5r1LSV?)0zdIZPOZ5C?#P{s7zlZW
zV~+C`eDw+4bL!4Fp`YE*w`(B_#;mQc#C#58#;>rygV85G+Agd5Luap{-4BD!EW&u(
zfS70b#b`_LJPD5N(iJhsN8TCRV~&3~=376a4`bY0`W?K((;afHms7i<&prgX`fr4B
zb4AP{H^n+4`p(2z=(l;qP(v{$puc~+0BcI%`^HjP_0Ox(&pTm$2Y#JzRBE>YkP-gx
zOW6E%lXB`=wAX>3Af^WWU+&DPHAcg~AD&fLps&pT7Cv$j`ZRpiIp~X>Rz|FaG3ok)
zF^@g~vE4tFdK&Y*Ut!l*U`%@f^_=_}V#jaMZt#Uu5rb^o7i%=nWB!TpXXkuI{d7LY
zQ^YBQUdyRj@GlE)&#8BRg6tc^2aZ8qFt@+&hm1PnI@D=YR?XW4^Gf`^?_1D==7jmM
zLHMg5pqpntz&ixj!(T%7!CzwyGLuy=U59lH%t5aK>>8B!D}44<i1(g=kG%@8XV=1d
z%oQ2ch%xHbyRdcy*wN6<=c{Ga_FH1z^xT|U0N9&IZzFw(M4IQ2o*sg^IsV>tA<9}?
zsWaxGP4Rn$R}oL*@5lq-Gw}DK|7Fz1v$ME>jlO{2S0E1hX(Oy_?U_?sqwFux?u!9G
z=OV!8p>5xUjo|kONXu^sfA#;`yAv=S%l`5I=iIj~m29o35tRzrqo^4(gJFy@#*)-n
zhU{cl6iSF>3+<AmQYnf`rAU;Jtr8_kB}zr9RKM4Sp6|2uJpI1M@js6L?>IPmcis1O
zU(30Cw)1nI*EKi=C*yRKz)u&GFaBX5ThPY$4!HT!gs|hBgz(00am#9XjoR^W@&I|T
zWv+i7|8R$PVoN%0N(hNd#4pz-goI)7@b2kxh9w><ev%OKT&GBlczAj^JJ0@fXUF%w
zoDfPq6%XH^MvwaNT_4B8@7i_!6!FM(acQN5uw4Er*>!(x77Gu%#)<NAQ*0l>4rGwq
zMz1M99o_8vhxi!9PEsG7ic>Imi*d&MSUA(?0XN0M&lRZLee~7$Yo8@M<;4`27z3=~
z<LsM-E;ZDZK2<0g4|9FrfJFBE=7+_UGvi^YHdt@pGaJNowy#f$hYIZDyW)ns9*>10
zC!1HhKOXw9CrM)x!v1p;!pN+67(PtS!*9{=fgLC^-ZhrX;nV-GoxfFC&#2G$`n}^%
za{UJqLblIo^Th&>YTpjA&}AE6G%yyL+us%U;-S6#o9$$5raQy#6ho8A*Bm>JJ`{XW
zJ*TisY+0+W`p0oO*U^WYV`1wex;%t^EGp*e5(|5kr@Q*q(tj8HsBaz=gPoKR3X=IK
zHs~hCs8A&qUV6q@WL!KfE-AJxLHE8<_oP^Ow1>aXywZ3{+*?JA`1{wfP?_&*>i33+
zi3R=dB4)p^T0FG+H6i3C$3x|B62kcQv2Z>eyf;A|lE{EE4xdXt#K2R;f%lZs)_L;d
zjoFI@Y~wo#;X|uk&U~KDsi_ay*t1Y$xE%7!u`r0Pj+veiO45;1_E#fEo6<sfNg2;N
z91B?mj4{W@!tT$>a;CV0jy^ETSitAAv~$Z<3E|f{#!-dEJkQ8cj2Cw|lvAab3;C&x
zPqa7t_B@;3XBmI=0Xra$daSYg^YIz(IVD?8LR+-nuPr|`UR)9nlj_j(IkE71TfVZ3
zXRjTXjuu#ah}~<#j*4X)ca;ZgA)c{+JoZmC4jiN2>{1_nR&SPE`djj&?BFS4nN0)4
zIr==`+2oL3^u3?lj5hvt?nF$&RNRX+zM#AIEt_s^LGPbBDITu;$!}tdIpUp*UMDwK
z%e$wuZwF)Hw~78v0ROgC3_IZAgfQ5#3Gc+iJ<I9Rx_G$xDfxPFT#H-d;h<b`@s@0j
z`=qqyPwUd-KCzIJXxzPppGZpxo4;b4#O=3Fq9+yQ#vSwQO1fp=jI>xtd^;hW&@UdA
zu+1~*!KzAP^UwI5pN+MuiEsI+2iTF!scdX@di({MddOHZmA~B1hJO|hTgk!lmtvvE
zAo9dUR8yDwgXM3>tMi*=PV7)O)wm{4+?W{;*GzMN@p9p<`i~D7JSHC2ZO~s!jmMv-
zZ<o;{GEw0avVaU^;%an8OFV!zSc^~aDb6h<*Ml;+7LCys?U9FRn2mM#2%n+I32Yed
z?n#%lPkXlZT;D6;sy1wzoM$JWvoLpWEKId6T0zd#_72>Op9_ieY}cXmh*-Gnuo%hb
zk1(yA@mFE?ABC|z$2i{hD&!&OwuI2uc7!;jgY9i>$ZY2irPHs`hrCX)a7*00&_rVo
zzc0N)Ub=#qj!){gIvx_pc%Oy#u_Fh^(i6wL$Tw{l&$M-|!q@QQ{K@5FmE9w?+ekiG
z>`~#6ICg?|<5MQJ5-&Qhq%mTCKKP?v3E|=O@i4wDJI3!^K0@4El?;p%XF2YC@xyKW
z<<$3#aXQAsX8U&Tj)z6Dcv#POr}2*$^%VbJW1K#Z-#?i>Kf#=l^1OAcde=+{Q(utJ
zo0t%`iNSsuXda48z5Y2Ly2tU$_$y^x_k%f{x5P|re}xTlOtrLC330Zvf6*f$>~i02
z{N%pJ#RuYwVx5gQ?u>_(<av7&?bDt-xZW##dLla&XWw>@jEB-`uKyTYk-?6!k>lyf
z2`AE9v2}@-@sP5IuVZI7TxyQ?frL<6f8-rtOByAFDSY(EN9eTvcx01thFB=uxqI1?
zS?+nA&l8Z|oIJ2$-?KY2eV-X4zn_YC*oli9$U$7hhib>|*N9Q**kZc9mCqPehHY_t
zxnLY(yAE$-E51PPcVeY8&2QB)&Ul@@(N}%6-Q11F(Vx?Ec4=@5J3uB+9cIq0D?Q{N
z_npm#(bt_F#Hr^*bKUZmCFSob8}kk^zVmsSvMt#tUN(0AQokI|jD-ne(v@e%LkGW4
z!AEWAtnFmXX4@aO-Gt`!e7EgJoY=v*()P4d#m^6mQJ;t($pxI?`wI6cWm_5<C|KWd
zGtBGx{8Rpf@G5(k$yY4ZzVC@c>aZbseyda|A#||K&6ex2jdD4|zeosoh+S(H*G3)5
z+g4-uBy+z{u_0_#&^Af$vo{OLQoUH{^d!BUb~I1;344BBo_UXb#=>8ECW9<?*~y2n
z$+P+6HLhQy3Vpd;-_XImSF&ku#=_SV<fk4rKFSflJV{=c7?0}PGuY~T?v{5IAD+G3
zc<(%VYyS*7(*Atw4Cae#UZhvE6T-4D#nab`gURHG(XlXcu6`t&C+V-rT@%9lEn=aP
zc<AAV@o<R!SzJusfE}s-O+36$|4-DX-x;6Y-kEMRHTT7)R@!I$-`=^O@?k&5LbIyc
z-Z>@57-w9_cb1~_<gtzZJF%O&yhqsIo8<==nSU(Ej%vr6Z?osxX#O~JzS_35^6p<m
zuRb;w{7T=k(|L{9-IL{g#4Gz}^J|xg`HPG35@KPF`j293)?FJ5SN>=&@ow_{t#>Z<
z<OhZ;Z%ys<bS$hsHx_O@SDeD;bra`I;Ky%%(>RIT^;jWSSdneMOAbL9p3@f<A5927
z2Cx@X>BFb7a6o@eYi;cIwH5uwQq88u!X+QXLW9Y%@U-%;>||W?ET3|L+{{7a(37?8
zcx9=;2JT|VFCjnLyo>U6C~2(ON{nAr&SR6h(8v4f;&d{9&3WRcUTnZ_IkWz@<h0E9
zbRoz7ea0$m$8>&ri~btEI3av~p*gu<_~>icVDZ*9li3q>oc#fR#NXYk%@69cbiVSG
zyTuafH2Dtqe}<gzG@rayn~6)VyGlN68@<}@9P)DiP3#M~{L1({Q*0BT>Rxro)nnxT
z1LK9u&99O7SF~GiKJ=Y;_}N$G7sTS<leJ<y<6+DP*0kItpEa5d8^-qBBHzXKkK4_c
zkdNd+ax`VxM>;n+L!N!C82+?a=vUCVQF~UK77sW6Brh5x|N3Ovy>uP(hKYM#h==<o
z7z49elZ%sYvhwVid{!E{C5wB%bk2>&Rlm_EvQ<C~b@~hJlX&sR1!8w{6;2Y@-Yh>b
zij1vS?pMV)<fsO{DIx}ZkRBfXRsQ-exs{*UE-}L0r>TpWukB`W+^uqc2h0zP$v?hB
z+)eK9B||B*;vt9LtPk<<nKsxVcDmzqZFi~mrN0m0g1G!5A2`EUF7G7%{4#drL3Xuz
zJbe0-+-n7So=4=Pnz9eg*#UBYNuu#rGj0Dpxw@Pjl94mnh|%K64XqQx4G$Ur(u>8p
zbehcW;JdyXD#n~)jD0gd^=(3E!5`$i!|;S3nBqQt$bQ>+LfG(zITkka68j3Tk>kuV
zZqVkpeq$bz-Ffn5xj1@wXC__$Egrt%t5&mDW5s4OD)39n(NjH(Js_4TVht0&RF>RV
zWdoT1a5|ej@_TWbI*brc9$F^8G>&}9akuNUA+EKOoX<T?+Gm7Zn7DNBC_eI4F=nc9
z0o#&A?mDq+v)ZxMF1m|7-7cQH<#aZ=2fZeX(?8O7#!ox>=yMB*@tcu(x^h3geY2l&
zx^Yt3&hlfvKY2kcWQes_yXOXSxW=(-eO_{dan5k_1N{F6-}g-Ss;LX)R>Tl9#ZGr$
zXlxf}=g36s-?hm+V?Wn>Enh4ok@s)4!Mxid{ga<?ep7u{q(wqV;=4MYK_B(!$M%n!
z#Lkp<UG?5h_vU4@zpL4ty<!-0)R^4Oqu0&P=a(HnnZC4tk6jr<-+q(t-YB+vBpzzz
zx3)lR{n?M|<+#HO$<zD3)7788R6gZu%xA1{|75YyAhNm3ak=b$aW-?tPqC1&fXuu>
zCU!WN?fCuLcsPm7F4G1R-Xr@N;=>|jn5`;i|G}QFv6#;qVC>UZyhHxB_v7RJwu+3s
zOm~a8PS(X@209zXgEy6qg-^@sKQ`$8SBxQZ#b3%(f<BdUUfoOM;TE!!M>n6`D0Wh&
z$Og~4Iu?qO(<%jx_2_x8Y3A1)f5I8!<otYtxUphGt3lcOsLXHh9jB;A;jMB6zAqWd
zZ)?kSeG@|Y?ec1q#Xn@AT`jup_lw@K#zbExh*#dEa~0X=pV`5ij0-;4z>Xc{|69p#
zlaCKiiG|<k>C(D#aeVy1#(XuOUFJc#TfX#0xx;;Rt*fAer>@YK741Jy{B^Q%N-DV-
zXRhLaI9FSo;hID5X9xH4G4<pIN5{fbpBYo!FE-HUSDwzt(7i|am(`!d!zksS!&Zzl
z{@W(b7*{_bJT){S{9a6+Y!;hX!ZnodME>~Ee&{0S-ArsiM<+}WFBB%@?C|2gWbRja
zN!MR{rr1=DWS4U8SMIUwcq{Ui&#|rdvaMgsHRi=b(w>A6D`6b3jf$!3MSN$8*2b1a
z=z;U@Ihp;|4=)-&#NV{G>S}$s%$!4#xMFrZB+|!i+ON8Pyt`XMC`5j`^IOk8!)KAt
zjg!e<b@7in6ssmis3qPVBu_e(Y>bSD)P@P<(m3)1ZMk1;$3J{@b}aP0OgzYb?PL#s
zyU{!t+tKq|zCsx~ZYK}=@03E?jm<eh%yv7ynJNzYw3L{!l(|eg)8cEn+xy8b9UV2*
zSeKsvP}6*vwjcYvyp;CL{>+%;u(@OPFI`aniC;ZYOj7fmc-S*fKBBVzAUBg1TkCZ;
zy=cmJvq=;A_?E^Lo!>Q%T5Bu5IQ2VneuZ&7AMim%pOrt~VYxWv9x*Y5SBF^B^Rjtm
zvRNjXe12ifMt{05r1Jv5#RvF?oG33Z27AvKN_;r+-B`%&lMp`oM9x|)dbY9AFJx=F
zSY+s>+Lvv<o?avkwtj|BS=d-#bx7cF<pG{{kDK)U6uDJnwSn|(l^CkubK=ZK^7EIN
zgCTp*(3hXo`8s`CvmLv_Kkg`Jy!5QKNLSPG{pKvL)c5>(^ZNQs%yoT+ya-!=pinG)
zQiCl~_S4m`y0-pOJI|eCobooG`Ib2b`nG!!*)$%ksIPC(*FVk`=VZIbwpdtMDsB##
ze;cXJ?dj0HViLA?_;`KUpPmhpPn~a0lx+X>t~EjId&g(#1m8Tlv9Z=1eqo^N-=K_R
z6GHEX+JCUQT{3d=-QvKn<q}88Kk<zN&k}?5GVUZR%jj5@sq)AC(UaQlr9)(C3wd8a
zhs80Ynpt(7AzrD@KU9^=JI}mQWV5tU*>ZGqi@6l>&{*x3{X1K$Uxz415%*nJ(Y#9u
zaw-N1bZp)ZW0l_Ii=K|JB>%#0J@5cMN{EFk_~$vx<nGAzTPs6I6u*@*{wURs&bKsH
zpDiA!Eyg^B9U^Nx`Ls5C%P2CCeIlLE#%~^Eo5^+4ALP%-YoF(|`Ca0qEcc-AOWuly
zn&%{h2Ku1+a8FF%XKq2v@z`VLSvw|#ZtV31AI8GHKZH<A9QG{#y?dw}AU$0t-W(u?
z`|VqCG2i>mZQ8Vh*rSVi`OW;^mE`VZZSknQUk*8JAf9h(Zd?5l_OMU<+nU|-V&v`@
zZNK1la|o_mnU0Ko+FXSg;<Omst1iQ~iK*`;pJcq}P-DsNa##7~vb%{F-j*wRjqRQ%
z&v;`(nEsq`68%p)C@)e;S@`c$uun`ey|QufDD8iaICz!Z0$b4JG`Y_ct<$Sz{%VBr
z>27sfPuBJQ8=3MS?<IsS{N0(Ud}a^vak8A(a_#O~{RZ&kr}8K78VB4bjyjR=+$ZOD
zp7ArE{^V=Q-(SCy%X`07fA%O}E52t2yS_Od+8e(;ug!kmA!a$<_<pz?ag}&@u$;AK
z>U52`_OsLY+x+BfAh|Ba-aaJuT_=xOls*Ts?&5^-%0#imT6HIDi>L9SwwGTiA7=Z0
z3VnCqF8uW_-<SMmKBy?WhI26N9&v%~z3f+_ZMpNsht2iLO!<_S`koy15JM!2y9?DJ
z^W=U0%n;f;c4`G<7~5Rb>Z0BEvQf^B;>&1#T^c#d@ms&MwON)p<5}aaJ$|#V_(Mm}
zEl>7We`<M6On%D#nhWFMh0nCL&)*Gly<B5gpR0-YwtdMb`@9u9@U^k#(i_FFWMaoG
z@$JL>IbXj*+|{`=KT(=ZEFt&aQag$rK5<U%266|sgUD@f`ZefLdEjDVP<psU9Q0+P
z_|y5F=uDTG*g;!|-_@I3-}L|=yVhJ&FY6aN8rxhcXDdei;7oDNF7oC&&-FBpqU&$4
zLzip2S(C)p_U~cK2X7D?`@C=heLY0)8<0QWufergD|a7ekZ1NR@hLXazUT?liD-N-
znYvgzovZET0AAlrzxRo`dKu@^;h|{>p_smV#Id`bdk$G$I8i=*x%jiKYbM3R%w_WL
zC$P2Z@TudjpKI=GsksQBPc2SPaRG{;7<!9qo6>_WK35eh^%nEA^7*@J+E$El4_zwI
zoZqwWbT)N}_Me?$jC_;z3Wdd7`k+-4@_boBSb5m^QGZU|Os@HkRWGqk{9I;H@$PuB
zbz45Rh&mWA-my-O`C<Nt@4fU3F`w)2e9}0A@0@(GdB|Fh6|?PGBR&kqUVa~Qm-(v-
za_i3RP9};Qi#&6!^&x)yu&cG^8>~BTPcH`Xsq$)fK4u<kkov7Q2Q=C`*p=FmeQP?`
znubXJj1`Kp;b(Q%{$iE4M(|rL+<TTaAL5qOM&cpo)Gi~2$kjGU<o)t^sJ)*p6YG_{
zT@3m<`{&q&W5_~bc>-np?Nt3--1y7>ahSrteEhTgMf7=`Ip*8sA`6>KSxZNkn>!NQ
zJm|MFWbPr`r}^)PZCj)pzmUyGd@eU#`9G0k*d|W<nEhb`yR&h(=#OtE(}xN2RdnxD
z@?1ShPLxc>?}*k7nd{P*E49-ZZzP1SY+bdIVy@Q4g3aYQYRU7kOH+TbUW}d;SB5fT
zi?iA42JTz%J7b2M;^8#ydO;g`6Eb#2Cq807Tf;n^f2){@en(^YU%!ckL*mRNcI@r~
z;w$Ih%)VXqjd}RW=7E)^Nvg3<Hn|sLe9ng)PPZn*wck5WdytEtdc?!ti{ysI)Q^u9
z!)2KZE+gjJqfK3}q&|9Yjrxy_*7_xcpTwG}eE&wj^;sc~En{B1vENh7uiCeZzRkav
zoN41VHyWeZ_br=!8b6ew?DM}6=WP;uKJUDN#;VKBgI^?n+(q8?KI7SY%&An;hNYz!
zkeMo1@R4>EAANo`pLb?FB<Y9ie>GlyK`il!*z6qT(2gA(pMj3YNa8o@RwnOahEvaR
z?SbU`Ec0yHu`uftap{HT47z!4;w1k6L1UZCtfkR*?a0A9;?>1L{$lvi@qF>lvG9Jk
zSa`gjwN|a!IC@@mgm|c~T)g|0WdoksBKNXD{QQ>O$24<B*YkPCkBMyMc79^V6Xe`D
z<P!SVov%scM^cQH>wRtit77qNKL1s=UHn;IXRny6K5Syni{=jN$3qrfTGq~7)^6(%
z8=4Ea({(P8gLeN18=Jd)i%ln+-)M_(2gs2mYMVRwb29wCW6pBz5@U^n_2<~7>}5r3
z_v@2=<E7aJ<pLa2m%QvI)0ZmmdHv)X*r?w!tmm&FH+2?S;4AC9SD`KDS*M9@ztAr1
z<+pdrsa2xa$#kDzNV!w);8ZfuTZ~4RPk-3D3b9W$W6JZ(=v(xEK@PdPaq=o{c8xh2
z`-&iXW+!^yXRO$9e2N^e&oA(gUzatOxkk>drkKONDJYQ3UOgv=!tU)?&#L*21K8>g
zKUmMDf3F^GJdi@h^7OBE-|U=SrRn%2b3QBNOKv55WW0O51nctU27eJ}J!71v?<-GL
zem?aEW73?D*<ru6E^qA-*?aS5G4^sk<9m6<O!3SnGW4VTE4@CE&Q~?gDT=z{zj=j>
zMdph|v};ecsmD_D{&70?xbdUd_vU-Vov&D@zfx?V9_P{Lb<^qiV)j#f_AcMKiG2xT
zuMVx`PF**dpM9B)Y3}om_xSxg*)B0c-)8#0tFdMqKE`k3jB%>-10~h>V(q{60pm?}
zwR2TD%kpC9tz`TTd9CyLxy!^shs1WLd$xnktn9exxq`!Nd$Kl~TF`o;2HIWTpkHx$
znhO%bmE*)ue9ybu{I-|Pfve||?#9k!ecl1GPc9BCLvg<Tp@rfc$4Ae|Our#o%Opng
zdFw0UVq@u{xBFe0+KPwssarO?)T6a_cg+1w#F1?0dHiFypUs6Y6K8!aM$z8~)1tAk
z+)QCMnh#8#7!T#H(S|3p>3nBtKHx?EU^x9b*L|XAbGBd`qUUqAv$^}HTXXmvAO18S
zCLguQ{t~^|WBv8y$#U`f{AGImYh}+&HM9oqIc>AfT9Dnb@RL~ORc+p?zd3_9>2ABD
z@mL9V>h2-Ntn{tsaPc%7+vg_bywI9g{WHe6qpUW#x`vpnmbpW*-i;@aasKR1ZMrMJ
z>wRj@{C#l{-!Z4WImc?oZS2!D@>s4<Ec{?RTH#lI?G$qOym8B;^7NIB^|irJcJ(1T
z9z7q^6phJrC)<fw{hQps?Nrq4s9nj(Nj>F(jZw0G71J!`r(fc?GUNf-ldH+V?X~Is
zc6~9Gei`RP&%}&V=g;`D$9ozNH)7|Ds0+Ec=u$D9-{0KM7S4B{GJGlhc{EWTbFSyH
zx{7JU)dMS7_d~{4J9fbd;&(bZXbkz}A0C?>`EK(J`hBzCuVq{I*U)}nd7f<%8*`TN
zN`i5v_D)m&@9Arem2~rV^7E*<$GgRL)7VV*A{ytvI>5T%)%sf8KH+;~Yqn%NJKKg%
zZPf-3k>B^&gM;p|Yqt1Yyj6isIg$RIbp{(mriy5j6{Yma3_hZw*hV`yU}N{uiN&t7
z_XGL%oz5?q5EkX5g9Q>o<y$>ddIq_;#Pudd&p+um^<LUjzJom}qpcThFt@|L&WY)p
zG{09N$D7&W(&|-9yvqmV@|$<OOb18A!gIOg>Snq3JnPi7dGihWUm4qBNx8@`&__Dj
zdZXAsi_D5mhCa*>u`hQzW=&^${G+_O&$AHi+xRnC*ezE_zGBzNC%w*&l@PBCHkO$s
zhFjn|^yt<5=(bqm`*LK0k1x7}jo3?WwcCyK;bv{OUVZ1eX6^v{$;=MA{DGK1LE8-=
z53jZ6ui5iXb@?dAJxiY|&l39#=U??#oepBW;>KAw$3r1wgc&mvLX8z<{vzuLN2p_I
z^XK)gvk?<?F}}Ni4Qtn&ZKv-aeQ8Y3R!z_!U%#f^wf~4&{Okwvhjg_JCiao{r8`6U
z=nwVti)F3H(O*NxiSJ)EHoZ!m>9}4`&^i6lg^bRhF4xgi{;Rf}oO*8*bItgSPZ(uf
zdm8^=M@;`*LKyR=7$lWXrH?OMYpf?0zt*)5&#>S2EH<TB^;oE@AD`YTP8%kTq<^Mw
zQD(Wqc^~O#$IZgd%Z)*e(>o3kW4Ko%KIe*$>GHGs(eG(jn%k%##;T@X#zPC~{Bz0j
zbISbMxyCHR)u9`|TftnN<L~P&{_8`3m#9~Nb5Zt1&q%F9v^MYK(fr78{bUR>^)WHE
zzA819UppkfwM34rq}Vab{MHrhqu8xxv3R)a9y(Q*ZnJee#7BvVN9Spi`OXH9ig~qd
zv&mwcXUJI#^Vi+@Gd6sES#gUp{KQ_oS(HCk?xbJklCBhY()q!6SZ~87{K~FZ*0&dm
z7gn>)w~rJr6c>N3m46&X4wbk6ck%Frd)@My@rc-KZ6<xFXS_siw}?MmT`r$VCZ1%^
zZof$^Vr(8g*VU`9_+Gm|@T4^sZ0rX5oJt0xXPiDfU!2M}Z=P;ETS%Lc;rYGUkq&%L
zCF5D=XX3WoDD7JQv`3T^GiN_XEW)RCe4Op1gL`KmJ@&a1)nSqRpL1SdrwUGCkLqjt
zzGB=L_&s*}r8msiuVZ5!^Ng7AsT{IjN-o0pN0D`pae=s|@_Mo51?Fn1YE%2mC7WNh
zor383v-=R8vlg52!l%YOJCDwTHzQ-SzP9#9Tzc1G;|o6a?xN(0{M5NjjQln~sZVZb
zFXnb`0r6Z*K6GJSI`go#L1bq&TU6>ZWA?lFA~x!^Vdl9V8$IW?6=z;e&Kl5tdRtc<
z@M>pc*)sA`<HgG-u-iMM{4w6Dnov9V7v&KW`Q_it<tP09J5>z7{~nKi2|JRGGQ#Kf
z>KXm}<1H4^d;fZM=yv2yvBi(QbtUDpb}8*rdUlBZp41=v{2i5^eg5GMCefMEzu2*D
z^!fklO&ou`si@<?Zawqb4e2$YUC(YEJM|in+rwX0@7&X00P<Fw|M=#kqwhWX<NZge
zod;E|(axL1+6}2*?bu5_QZg#1wMqNml`DF;(%;?)6unu^pJR&tKEjb!_|tM7`FrNw
zIv;yekC!+`wK`UsqxH+HeB=cxmHXy(4Br+`IQpiWN}UobrRV+i*E{`bqy4+f{A-z7
zd3BH%i~qZW|M`_tUMn?Ndv^UR$6nWMK-YmCy)3F{yKcSzQjPxZj1W847E16}Zg#9-
zDSdi(%Fg+3Cq&ZRp>MaSSUm^k`NN+7xv~E^d|>aq=uKz;?eL?o-umO!GJmn^gF5})
z2}dR5f8^n>-SH0<`pb9xyAzJy@vq(I?+e<kdhJ^O?W_!~ot%~apIZB0WzwH%=+`03
z+snE|@4QdW`kOqY_y5~F&i<sL|NUbBcn#P4cUAabT&7)z0X=(l`L|d5dqw(_az}@x
z4e`=ce^E<&^>3Hic|e0U?FQATTr+ArcI$^@Hu>Kb_g~I#*}GepZk_W|vUC2E`W>~J
zd7TIOn{d%_?Rw|+{j<ye@uxGA`*u^f)U4bTcCb(H|8)6(s86dF|NVr2DbFB(8Q~AR
z_?HUiwUJ%AUH6{~^$+zJ)akDu+CMV<|GC2dc<ugwYWn_Fy8c8e{^`K*+c6p7OO8rg
zRQ&&B#s0ZP|Ev-Jp{rVZ?N*<`{o7To(yo7AkN?y{|K&8N9+l|-<!%3VzBd{U?K_}P
z_;0fCXXR;qv>NSt^!l@s{BuLK8`S^L4*iFl{1vhO2eJ6?68aC<|DVI#9f@jkThy+S
zo1K!??{96<xo^Ar{@_MlChzob%Y5Yay*lT0^X9?7na`sENafz%-Z-dp-+q0%=T@y+
zr*_R+RcltS+OAK>?s<Ri6#hvl$)Y>_gT4MsCiY)!*56sYzXeKv)(3qDcI?@$Q@cJL
zdboL~zqN(G;N2~;QuN~O>-r>CYFz_u5-T;!!%%<BJ2kgy{oJO>S-Gj{*=Z>vh16UY
zvVKPD(VtRUMBD6~6q}Tk-0ZX#IoatcIqA(Zb6aGkrPQl>bbn;~+O#?HEw`2Pb6clp
zdfmVOXXezaGNek)D$#+tEpjsc<d^82)U*canQ6JnEmG3cb5nAz%1TqPl<a0lijbU<
z(X4fD(-tYYt<th{o2IvDnw*o;D7xs;U($2ZvXgU~WxGoKmJM?=(psfu{Bc<L?wF1E
zyW_K4X6B?fP0P(lub-Wqebpa_Mn@bidq!GvW^Qt(_VK~q%w{dpvRkF6q#ZpXwR*Lq
zA8KjQBW;$O(JVPNr9ne2*&?}qMp|x4+L7iw(jLbOnW>bS$r(p#6zxxMnpH14T{Zvq
zxoL|dXQZaJXp++`>yL}K$Vp9amYbYiKRxG2d0VHarXA^m^akl^+0g}4(^^%nVtb_c
z;qQE7YGzJu%d8`v<Cu)2z4T8VRI5r<onxJoo)-04ohrw!rVFFqbCvYW7P`~tlxCT!
z=|`lXktWJW&un<~s=4)Bre~z;wMJ1-=GGh3X>h+D{ridloSvGR9(7&|!c*_)H-)Gj
z-8Q*ts=sRbKc8BpH*J}5q&NTFzO1zD27h;O>t@+alCzt&)K$@#=<C151V^fKq<fBB
zKe|+lCh1wZ=?!xK@digk#?Ptsk5wZxt#xjT)Fwyj)T}{+^py1EjH6XMQv3R8Imt&p
zG-z`~8nd#~TP5d^J9Q`H+4WMgvT|rjrAw<-sve0)%Oe_<mf0$|L3VnY2D_?WYUhpv
zuk({j5WvioM!7An%1p^kQ4cbb+bTJurCx~2-1JEEH|#}O(;D@U{--&c=1|~<EyO^7
z_&<8y>9WDzX4x-yz>&{g`t)nj$$K&#mkr0~WF=M_oLA%0YBi5+>(p|6-|N)Uy|%Tg
zR6n|{cIlCA?dm$m{u(ufv`4l__t&WT$NoA;_E)KM<ouddYN~64^t`-|9eVfneprK|
z2JA*&)dn5<4`|S#TTh>>{m<v<inZLat^IBLx@5x!7^-ejF{{?B65al&W~F5wQK(kU
z2t_*0YN`WLlXH@z{=OpQJFSS(bs;0|=w17TaUxE_GIKv;HpN1sIm(g~<lmNhR^uLX
z*d64<{eD5F=U8@ozraXq1>_8$SZqDbS+Ouvj(XGUa>*CV<!*F6x!BWZnB$S}K2<K~
zi9*&%m`@n9QI2(oJXKjaI60vQTgqXY=lZ;wxnz0GD^9c~W2GFU{MF-^Su_8owJdU(
z!{ud1=g7;ph=+y+<?KpWV{)pw>9*$e<s}NstL-_<+LC&584?&<&D9ig|NG3{c0NfS
zsgh?Lo-ikRiuvV1a+GpG9pw*KUuyk`oL!0K@;+re)7ZxPv6klU?lC8_$32=_A7eiG
zd3pTY`SNe_j0fge`%uU_xk=W*%dg$o%32J0!Dt=sr)|vFn9GUv(MA_qtMQzBjj|Rv
z$$A#$?<<Ejd5^i*>pXM2UtV5r>*t}`U74m;mUC+-w|TN$T3zeN<Y%&K$O)Q@T5^i~
z__v<D+@c=t*Y_%G66C)MzHOcSO!HPn<jLiDCdkd!dQZM^k2&kw=J>xi&yr7GRyiB1
z#}B_-k9j~oSDQa64>@|Y{G?o6L;ZKn-h^<eJma13TIZ81*E>~?Nsf4ndAfaaW!E*6
zH?+2AhWzGoa}%Fbl<Sel+jpk=%VU>#S>Ep!^;u@VaD=%Fee&{jb7AD?sxM+DC#-MV
zr@wFT{8A0`5f^(-!TisHt=8su_56)~8viXBxk&lsREI9GE>f<#xcuxkbFXJ)D$iBs
zLFK=mn<&?+trp2O7aHySF4ksUYpscEELZ=0!}M)F`8;{aX7XO!_4T@diSoMU@@`lt
z-!BLExp~lGqs)6*_p|Fo<sYRV$@RW-Jjdny9gmRjR*sc3&M+5Us)=boeRDf`9!58|
zrP2?1*)FN(<0qR7ecv4CdGdFe<{ISHrklIWrXPnIn-`Fy9CeHQ-yCgRQcj-i=gL!#
zbl-^&=~Lx;v4Qzj$+lL@&B2Yg25^Bqq&X^G96m&Yk@2uVdoFz4dbfjg?mKzq6>^N1
z#zI~({o&Y{@&xlq1D>R_7s~nSzhW=SOQu^NSI2vV`guo$ylJZW&p~fnFHRTl*UsOn
zV^KO+<2CDL$6GT;*H_QAZsRv|DWA&YI)7As>n-k=KV=W1{PeAB)ssBeGw;`k{N?E9
zHS&vH<SW~nF9`R_Ny@pF-DQ4K|Gap+xm)vqwaiWR_)SiKkUaGz)|afKW51f$(XNNu
zko|MyC~Ihw{PM-O>Q6c6i^xfdS=NZ`Fwg3^;-8R1jZ)+l^D>jHanu)yr;+hP=JQ^Y
z?<KQmOruleJbItpvUjZ)+i4Dl&8oIEvKi{pD_TQG)(=^aQ^*|4J8axW^Sr;9W4w$F
zAt!UHtA?EPfm`K6*{oS~zw1fn<>Y+JPOygeA?tn$TMtU^CY>X9PHwIk=-C17^5C!R
z=w0RqR>Z=sqpj1R_m4g!?@f2J*_7ui$<Ys#%U)&8)=D}4V&*i~%IB{#w|2R?)|&Ks
zviYGate>vO-rZ@gg8h8me9|!WY0b7AxR`yIM0akGm+tR5Me-BbrS;mY#~#nG4YxLs
zU8*Fv{5G38dn9=n!QS_<PG!C4b+lLM&E{sCTQ_&mGjfgD;jXSlzDLYU2<<!4A9D$L
zU$Kc}JR@C}4BZhAC)}v5<is=CxY4(I4&)PaEqT^UbTrS}$@7TyttBJ-MH*Op@qo1h
zboAoS>G@7&Tp;&MhANrQ$Zn~RFQ?D<nSUT#ef4iC_HY9q^PwF0m8b9{w|OQ)e^u(n
z=P38b+T`cE<KYK7@W{p1kg=ty<||&;2HVUdb=zf)=Q?x2bT@i7?4q^i!M>M+r%yB0
z<w|`$$eitpD%Oky?^kGO&G-oK5M=MyIq#XL$YBTi#&=D8-#Xf})iK+3uV!z`nWszl
zJU?CC&&Hq7i9DTdj@vxOnfmC~Wu6OPhyi?rHmbm$jx<m75}g`-lm27-vh?q5bn*Rf
zJR7~uoT~dDJYfExK7I8pAG=cd&Ngp6RQs`|9k#GJ+xd_+=4}gD$26P%eq+r;Q}b!$
z=Eo;J*WcOu%AWF!+IehQ4RYSYxqNY)Y<*oO9@=Y@*&F#6eV0Aax|gTf%g^=aY1T8g
zr3dd?GtWL&WZy5p&vOy{>hcZlx4~MEncC)3^Xt9HUR&$b^heWMtm|q+4k}?bzth~>
zu*d0H5A*bmJ^%csxl8`wfO>y?vUl8+<7*xF-EE$iyEnnY7xv&DdZr%lny<LMwEDA|
zXR;R~pR#7Kr}<a9vgj)M=GctgYy^3{VITeejxO{vNBs$#*3No^Gw8wfWNwqWIezY8
z{WWZ*`B&}MPWdYIRX+Z?3mu%IeG8ehDcsw8e;zb{N_LY{$y#^okX|<TKEga8zuaJ+
zSmY6NruFHAHtl^s+se09V-LHuX2Z$dv#)qo?NM_yWT;;)>&LFQ#{VL^#;$kLmeF&n
zAFzkFm19rIZ9-SiAG9}LPRBOBCU%%*KG*!uTWnqDN!H!-Rp00FS#PMzCDzZ^G4HBO
zL*8af`dMfGJXvO!%buoflAOmTolXYx(v_*LI)ALKA7hKymK!tJK)Sh+9K5lVjepA=
z6*>DMHH7GS?iBs_PDjtGJ#THv0sc-LQvAJmxT$~iE-(7U4n{tu*$<vgWHa`$3E2;N
zK7;+NQjx9wh3>Qx576P0uVWLGyWY4+ALvPeSa@>2br#Fa{l6-PA!AKunV0^RA7F1|
z<aiT(+Ce^F)>gx{Lysct{F&y{cd>h)#ljQki)S+V#FwJy9jwQ>(sOI{s33ch`k~k~
z-C7N8UGRWdh>yG9?+xGQkLg}gcWdL=(q3h(8UL0ocvV}Mvo^xqY1M1Z=aQ3t_jo>*
ze@cGO{jOJjbADfxvTjdbEoJ*J)CV`}*MmLHecfhF_84nEd$HM%TSHTw@3}@y)`h<*
zYTb=KELGMu^~sQz#CuP8uL)neN6g&oW^tAHa7#1yrlYUwucANGvw_y)Herj&_(KOh
z%e8|1sCWMv<`~Jwb#wVH<-GH5GWD!?w!CZ&RTh6rhSq40J5#KM|Ct|RTbpZ>ic`(e
zlIJF8u`$2UPv!lYOq48ZUjIhds_Y#U;@@}K$QH#tGeB0a)yKmJcm{8%wyjLI&2?6)
zV$IT2G42%4{wJ7+7gKE-LMO#|?=`fZNMCgz*T39EUb*;Yh50P@{#Nl#x6NdUt(g${
zqX+3!b^R?~ZTlc!{3DrAwn|&XML!;0AKd$jC>|%jcknmm*~s(h`~70`GRiWI|LG(y
ziSut;tv?CY4P8r?__Y>fvBN}iN1n?(&5xw(cY0Ro4RY|Mu}w7v)ArH7F}7<G&G*}u
zOtLPTOeePIbBkN2Gs2vF3ENq|+g4b{{@R8e-bqo?ar(c;sh)vJBpbFxldJ(J%Qf_S
z+0(^IBdjg9O`63Qvq80&@uA|P@_gKO+mgy0%?Ia8w4SAu>n4%&(l+hcW_8ROp<ite
z&r<iZtucGkb7EqZZ9B-d?X&{k|6`k!X#PBr&nI8y$yxNg$XVwq&j|g?u9lv~9@u`d
zjLou*p1WvO-u*(p@TP6;#C)O7dCHxXFT8Bqw|&0Q=X}rbjK~*$vt2POU${j~F=BbX
z@Tu*D9r?l(exOju9|p6Pr4#dq0vEYjQvUG0ZH4yvLk9boH8Ow5ZyeBQR{pTYw&=3_
zVG#X3V@LjQDS65l3WU;^h&2)mgq^k_sX%z73Y*-aKp0!qI*Snn!rl5RV^)DMlTMwn
ztU$Q0hWhO&5bmm}yrEziT8pnsEErBUR!dAO7**={zyFU~;EfZF;mh!`)vY1jNH=<0
z|G0;~(S@Y5`KDWpxA*eL`{UuOwd{2^Js{VU8(NpzlYQK7jTza^tH(AQwEXb7wT}<5
zfzOL+t}?c%;Qd-f#G&6=AG4Va6=zHoYp+N#CP?repqD(CBNiXc-i_Pjy%~MU{{x<>
zc*wH|;=nc&tjB-Ox(#~P{(W)FA~xj=F=4W`6Tcdhika&E<esDG30qJ~+0MjbF~a%c
ztG~Ai9TUkNThKU(zq1YPt?8lru@Tnisc)EN97E?%TIM+bI)Bm*?|h1MKCqW`JtP{>
z(($vBjKd?{ZqFCk#zrKBbLe!TS#lqA`m|-rM2E}oaR1}~j<>+^7C7Dl$6Mfd3mk8O
z<1KK!1&+7C@fJAV0>@k6cnkdhpamW_M3tTi4`D@<f}zLk0-?z7N5`$3<OW_DEjJ`D
zlvNm)%fUu@0Y7IsJ~3_{);0;I?2lY$nyte_`;+CeuJAme@53BF>)3uN{!k;ocbV81
zJ)af*HUz`u>iQNq`guSR7x4K$``bIOtKWk2ZgpM-=Zr1nbM)Qs5hHM);|CnOUU~Vq
zMUG8E^qW+8=;?D^d8|!7r#iQh?Rxv7x~E3R+2*q?)X}p|uAk)l9M{~NsIK<UaZdE^
z$7sJKSr{fQwLl%$81FC9P9x+E+SqsN366Kq@{XyC{f~K{l>J5J33j+f`!mheIM(z;
zNNQwW+~=9{W=otmtNhV2&8wl#uDMN4VTa=uD93uYJrtd9n_Bj0J8W|Ne&?;Sou!P+
zF4lhTHSYq~j{2*E&&oWkv3kmLbamZB+VUiMxG%JEX_fD*j4RG}pL|FEu2Wa{Yh>RU
zwps48!2YPO65Tgy-<h`IGWU1i8suTU`+Om<8ntsH<y+wAsGcqz>MB#TO^mK#J4_BG
z(Q!r3bDs0Z9=qNw{jy3OSEVU$QP+^0iSED3aYGzeL4Bg~Ejw1uNCsxPUd1b2Lw)-m
z+rLI0a)fi2q}!gPoBY0CT~b{?$#Hf47M16Z<D=_G*UhQmc*iZRtz7cuN!lvvpGESN
z^VDyVlO{Pg&-EucE-Axt+Aqg3D_molGS1NkksMERY$1JDCEM0Hf83+A`%H503gwR0
zyYGyG)*5(TPTkIMj|IotET8k{$uX^HVD3y=wq5A>{Ekt^ME4mWr@G8_ca2jw`PaVc
z*4OvYM9!BiRj@CST(;LHQQzL@ezV+rjqQ5d^^RXq)G>Y^TYxMme|y_3+eG(im*Tto
z<hbuL-`m%;UtL#RrCpV0k?TkGtKs}C*N@&YvcrAXIRB9EiOM;|?>TjSSFRdW9k1;p
zqmX5P?eezTFHsv8b^RgsS8@Ga=N{F8A<EZAd1}lhYxdPv?p4Zt$bH)=*G%m-$#o9-
zZI%1wlOtZDzWI*T?{H=9a_oMSqVhX#rt`b{eVJ{B;}`gSMOl6Bd(ZOZ*LH~Q`?h0k
z&v0I8_xZwc%Z?p)NIUFzpBlD@l%u`+R&d;WzqfZ@mg`6Nsc1XPcAn0zEe9CsUR2Hr
z$}!3Q`RW&yf024e?`W@BUfUEVQ(bJ?hyzL5#`igXpXYwj-$R<`K2iCj>ttz%$nMOG
z?q|Edx$lnuqnyjg-+KGkC|6XTEZ0xeo>94??-}aV#_>^mPEx=3>GCZ7`bRrAQqHJd
zin@PM*E#HaBsYnUTNU*axrpwYp`E|5?K)aJko|40-_?C4MfX#$Ln(fD-Bjh@;d|eA
z)h*M#<Woz(sf{l*r`_ET{>_mujy|<dHjixkuKKP+Hd-JDEzt_C(FRwcEv`m8T!U+o
zi}vV%j)>l`mxs>ig6q%~-OwF95c!5)=#4(;i|f%3{V@OoF$jY(1VeEHZp1JQ$4$5y
zBVd{&jKVF5{MKmPhB1irc^q!Xcuc?@n20+O$?arJ!BkAcU6_s;n2Eb_5AMZ%xE~MT
zLCnHKn2m=q2ajMb9z`TikKu7Vf%$k6PvL1Sz%zIj3laI!=kPohV+mfsi+Bl3@iJb)
zt5}BD@H&=b1>V30a<mbfuo+wM9wNQ_09)}PwqZLy!pGQwPp}i8Vi!KcZhVeNf4{^Y
ze1*N(hp+Js_TyW8hwpI!2k`@b#3B5IpYaP0<5&EKBM(9<djevJBOmf3dM>jd3gHA4
z#)&uyC!+{XK~WS#ag;zwoQl(MI?lkEI18mv8f9=c&Osu|;#`zNd7OvyaRDmeLR^H4
zQ4y6;8JD06s-haIqXufC7A{3?)WK!A9CdLJ8?X_Zuo+wM9^S_X*oqIa4cqY%KE@7w
zf}QvjyYLxy<8yq0FR=$-VK4UKYkY(KsD~?XC6bVg`ba@4($D~rpSBDn^h1A`+71IT
z2!j#%WK-Rt514K5+tpu)><#l3n6$u59hoNLu0p13HbWMggJ}y~m3du#2Gc@;2@BD5
z5H}r!nvvNKrg(#JEeHn#vmX*s7R+a08bf)U2j(y^!AD|brZilHi%}7kz^sN#z>Ej3
zGgL!$2;BnL6HJW;E-VODLLD&6K^PXe+fWZe?jY<5Nk~S0G*pj9NJnEdK?a(FnGUH)
zLxbp8G(tKWqX{z56wG&MhAeP9L8ua1AO|hc3a!xw!iCTlSEC)S!L`UmdvriYbV43F
zqYJJ>S9C*n^gvJaLT~gzUtEuV=#K#yh(Q>PAsC7qa3h9cIBvqt7=e)(g<EhdM&mY&
z!B~vL?HG><xC0Y$CnjMsreG?j;Vw+a49vvcxCi&*KHQH7@E~U4A<V|Zn1e?!7ms2d
z9>e2!0`u`Cp2E{ufM@V57Ge>e!}C~-C3pcZ;w3D_%XkH^Vi{h;>sXEzcmpf(CRSlJ
z-oo2hgLkkN>#!d0Vgoi}6E<TD-oyL&09)}PwqZLy!pGQwPp}i8Vi!KcZhVd}@Fn)(
zE9}KSe2s6gAK&6Te2)V-h#&AH4&f*Kj9+jVzv4Iij*#F##1Kb5<VOJ%gr$PPvNX>J
zu@^WAC&O~3U`jd^MKKgd36z9omf<v<j%e&+m=`R438i3}TQJ2QOjU<-kchH47v)eM
z=iz)@08{2ccoZxd4Hu&#EVT)i^Mp%K1yxZErtL!w)I=>@irT1y%U~H&s0+&!!xgY(
z>d5##*|t7Xkcu=kKtnWw<u#!(njiyBk%?x=LUULO5LzG_2em{iv_>0Tg|@gF?QjjQ
zMK0Q-13ID;^3WMwa2=vCXg65W6?(ujgXqr^gx<ITH)0ru<0jmU5g3V4xCOUjG;YHf
zjKw(Ij`5g)J1`M<ViG1}3Z`Nj?!t7;z)akYdvGuA!~J*w4`LP`!fZT@Id}wf@hIlu
zF+7eZFdt9iDLjn@cm~g6Ar|2|Jded#f*0^2Ucyqmj92g~mf<zLj^$W^H?R_KVii{7
zExe62cn52-4(stQHee$*VKcViJ-m+(uoWL-8@A&ke2g9V1UvC5cHuMZ#^?9~Ut$lw
z!d~pd*Z2ne@h!f?_c(xq_yIrS5PrhX_yvdYD}KZ82r)X17~;r>{IFCloQRWPNoptp
zk5+`Duv{=$dKyZgBrIVJ1yKkm;8dK3({TpQ#91hX(y-JpSRxb7K_bfHT$F>QZQ(pv
z(ikp41y}|cEME*4qarGyGA@B-$)PH$!4kSq1D1k^TDTOoQ3sY7hRabGmfVCZa3zwE
zjQU7HD$>vZmg<B?NJnEdK?a&46U~r?=Ez11<e(*5p*7mzDzwGb@F+&O2G=4N?a=`p
z(Fu9zj4rqimN15H=#C!fiC*Z9KIjX}6GK1r#{dk3rGjBFhF~aez>V;@M;MNqa5F|=
zBu3#D+=|h-4P!7C<8V91V*>8LMBIr<n2afyifOnD(=h`xaX0S4y|@qe;{iN~S$GJu
z@i6A#5zNJ-n1{#kIG(_KJc+09G#20)Jd1@`gy--)7Gnusz>9bZOYt&Z!K+w?*YG-)
zV+G#8O1z0xSdF*vHrC)Bti?L4$Gg~ojo5_E*n;=)K0d%!e28t>j*sv$cHk52#HZMW
z&#)Vx;|qL=J@^WHu@7J48|=ro_zvIW01n~@{D?#N2|wc(9LBHs4ZkDA=|5tyd^F@k
zeppT!3Zf8BKw+E+OI*Xrurw{4f}$t}%Va|dcw8r(3d^p;>9FK1SgIV(f+fSDG|J#?
zoP$J^#knYl@;DFY;{sH`h483TxEK{t36){lcc_A@sD|qB$UvxxTDTOoQ3sdda@0jV
zT!AZ*gk;o53R01V2C!uINNzUWwlSI@15J^MX2?QwSfU+TAP1HhhgN8fHn<9HaWyQj
z3)jHX>X3`}=zxysggkUc7hDI+cSARHhh_00ng{5G-spqAxE}q`9|JHDgD@CFFcdf7
zMhwGn+=QDk0wXaBx8PQc#%&mbu^5NjF&-0e2PWc9Ou}SL!BkAcU6_s;n2Eb_5AMZ%
zxE~MTLCnHKn2m=q2ajMb9>qL7hR5*)=Hp2`g{QFq&)``s#3DS0=dl<|@B&`MOIV7R
z@d{qWGQ5V@u^cP#23F!ttio!%g}1Q=?_e#~VLjf(25iJ8Y{nM6hxhRTw&Fu<!*+ax
zkFf)vU?)DsE_{aF_#9v0OYFf{*o%Gm8sA_)zQuR=9tUs`Kj254n2-M3{)}I67{B5-
z{Ep!F1jG<WKIBIM6htAMfWkQB_>*i;MiHEXq9}&qD1nkV6{q2JoPjfO7D^$?=a<3R
zI0uO+i*r#9<#8U)#|5Z>3vm%HMnzOYWn6+PsETT+jvA<mTDTOoQ3sbHdfuxp>fs7p
zi6kVWK2ng1G&Dd%G(tKWqX{z56q#s-EHp<pS|A54(F(2623Mgiu0}gtgKLqC_UM3)
z=!86UMi*R%uIPsD=z*T-h2H3czPKL!&>sUZ5Q8unLogIK;6@C?aNLBOF#;no3b)`^
zjK*ykgRvNg+c6#!a0e#hPE5jNOu<x4!(Et;8JLN?aS!greYhVF;6cp7Lzs<+F$a%e
zE*`}^Jch^d1m@#OJcXyR0MFoAEW{!_hv%^vOYj0-#7kI;m+=Z-#WK8x*RdQc@CH`m
zO{~IdyoI;12Jc`k)?q!~#mfAS$11GGTX-95@DA4E2du}p_zvIW0Di>rfB$c_z#)D1
z)A4@$f2-4um-cuI9B+Z+EpWUAj<>+^7C7Dl$6Mfd3mk8O<1KK!1&+7C|78pOAH+xY
Awg3PC

literal 0
HcmV?d00001


From af6ff95e94c45281e81f6b3f5783108534ab9024 Mon Sep 17 00:00:00 2001
From: Shaopeng <81775155+shaopeng-gh@users.noreply.github.com>
Date: Thu, 16 Dec 2021 17:04:43 -0800
Subject: [PATCH 03/10] add Release History

---
 src/ReleaseHistory.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/ReleaseHistory.md b/src/ReleaseHistory.md
index cf2ef2b43..b1e07c54c 100644
--- a/src/ReleaseHistory.md
+++ b/src/ReleaseHistory.md
@@ -2,6 +2,8 @@
 
 ## Unreleased
 
+* BUGFIX: Fix Error BA2006: '...' was compiled with one or more modules which were not built using minimum required tool versions [533](https://github.com/microsoft/binskim/pull/533)
+
 ## **v1.9.0** [NuGet Package](https://www.nuget.org/packages/Microsoft.CodeAnalysis.BinSkim/1.9.0)
 
 * BUGFIX: Fix telemetry session creation. [515](https://github.com/microsoft/binskim/pull/515)

From 02f655652b6840a94be5a489bad5720ff892f0d3 Mon Sep 17 00:00:00 2001
From: Shaopeng <81775155+shaopeng-gh@users.noreply.github.com>
Date: Thu, 6 Jan 2022 18:44:28 -0800
Subject: [PATCH 04/10] update comments with date and person

---
 .../PERules/BA2006.BuildWithSecureTools.cs    | 72 ++++++++++---------
 1 file changed, 40 insertions(+), 32 deletions(-)

diff --git a/src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs b/src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs
index e3bce0d4f..c8dc7fd81 100644
--- a/src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs
+++ b/src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs
@@ -119,7 +119,9 @@ public override void AnalyzePortableExecutableAndPdb(BinaryAnalyzerContext conte
                 if (omDetails.WellKnownCompiler != WellKnownCompilers.MicrosoftC
                     && omDetails.WellKnownCompiler != WellKnownCompilers.MicrosoftCxx)
                 {
-                    // TODO: https://github.com/Microsoft/binskim/issues/114
+                    // TODO: MikeFan (1/6/2022)
+                    // We need to take a step back and comprehensively review our compiler/language support.
+                    // https://github.com/Microsoft/binskim/issues/114
                     continue;
                 }
 
@@ -139,37 +141,43 @@ public override void AnalyzePortableExecutableAndPdb(BinaryAnalyzerContext conte
                         break;
                     }
 
-                    //case Language.MASM:
-                    //{
-                    //    minCompilerVersion =
-                    //        context.Policy.GetProperty(MinimumToolVersions)[nameof(Language.MASM)];
-                    //    break;
-                    //}
-
-                    //case Language.CVTRES:
-                    //{
-                    //    minCompilerVersion =
-                    //        context.Policy.GetProperty(MinimumToolVersions)[nameof(Language.CVTRES)];
-                    //    break;
-                    //}
-
-                    //case Language.CSharp:
-                    //{
-                    //    minCompilerVersion =
-                    //        context.Policy.GetProperty(MinimumToolVersions)[nameof(Language.CSharp)];
-                    //    break;
-                    //}
-
-                    // Language data is not always included if it is only compiled with SymTagCompiland without SymTagCompilandDetails
-                    // https://docs.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/compilanddetails?view=vs-2022
-                    // Compiland information is split between symbols with a SymTagCompiland tag (low detail)
-                    // and a SymTagCompilandDetails tag (high detail).
-                    //case Language.Unknown:
-                    //{
-                    //    minCompilerVersion =
-                    //        context.Policy.GetProperty(MinimumToolVersions)[nameof(Language.Unknown)];
-                    //    break;
-                    //}
+                    /*
+                    TODO: MikeFan (1/6/2022)
+                    We need to take a step back and comprehensively review our compiler/language support.
+                    https://github.com/Microsoft/binskim/issues/114
+
+                    case Language.MASM:
+                    {
+                        minCompilerVersion =
+                            context.Policy.GetProperty(MinimumToolVersions)[nameof(Language.MASM)];
+                        break;
+                    }
+
+                    case Language.CVTRES:
+                    {
+                        minCompilerVersion =
+                            context.Policy.GetProperty(MinimumToolVersions)[nameof(Language.CVTRES)];
+                        break;
+                    }
+
+                    case Language.CSharp:
+                    {
+                        minCompilerVersion =
+                            context.Policy.GetProperty(MinimumToolVersions)[nameof(Language.CSharp)];
+                        break;
+                    }
+
+                    Language data is not always included if it is only compiled with SymTagCompiland without SymTagCompilandDetails
+                    https://docs.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/compilanddetails?view=vs-2022
+                    Compiland information is split between symbols with a SymTagCompiland tag (low detail)
+                    and a SymTagCompilandDetails tag (high detail).
+                    case Language.Unknown:
+                    {
+                        minCompilerVersion =
+                            context.Policy.GetProperty(MinimumToolVersions)[nameof(Language.Unknown)];
+                        break;
+                    }
+                    */
 
                     default:
                     {

From a9fc939affb339421a4bf072d97b88ef9c3b05ab Mon Sep 17 00:00:00 2001
From: Shaopeng <81775155+shaopeng-gh@users.noreply.github.com>
Date: Fri, 7 Jan 2022 00:10:41 -0800
Subject: [PATCH 05/10] fix the SDK, point Binskim to the fixed branch, run
 rebaseline, so 1. check if fix works 2. now we can review the actual change
 without noise

---
 .../Expected/BinSkim.win-x64.ni.dll.sarif     | 397 ++++++++++--------
 .../Expected/BinSkim.win-x86.ni.dll.sarif     | 397 ++++++++++--------
 .../Expected/Binskim.linux-x64.dll.sarif      | 385 ++++++++++-------
 .../Expected/Binskim.win-x64.RTR.dll.sarif    | 397 ++++++++++--------
 .../Expected/Binskim.win-x64.dll.sarif        | 385 ++++++++++-------
 .../Expected/Binskim.win-x86.RTR.dll.sarif    | 397 ++++++++++--------
 .../Expected/Binskim.win-x86.dll.sarif        | 385 ++++++++++-------
 ...rupted_Native_x86_VS2013_Default.exe.sarif |   1 -
 ...ore_RTR_linux-x64_VS2019_Default.dll.sarif | 397 ++++++++++--------
 ...tCore_RTR_win-x64_VS2019_Default.dll.sarif | 397 ++++++++++--------
 ...tCore_RTR_win-x86_VS2019_Default.dll.sarif | 397 ++++++++++--------
 ...NetCore_linux-x64_VS2019_Default.dll.sarif | 397 ++++++++++--------
 ...otNetCore_win-x64_VS2019_Default.dll.sarif | 397 ++++++++++--------
 ...otNetCore_win-x64_VS2019_Default.exe.sarif | 397 ++++++++++--------
 ...otNetCore_win-x86_VS2019_Default.dll.sarif | 397 ++++++++++--------
 ...InteropAssemblyForAtlTestLibrary.dll.sarif | 385 ++++++++++-------
 .../Expected/ManagedResourcesOnly.dll.sarif   | 385 ++++++++++-------
 ...aged_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif | 397 ++++++++++--------
 ...anaged_AnyCPU_VS2017_Prefer32Bit.exe.sarif | 397 ++++++++++--------
 .../Managed_x64_VS2015_FSharp.exe.sarif       | 397 ++++++++++--------
 ...VS2019_CSharp_DebugType_Embedded.dll.sarif | 397 ++++++++++--------
 ...x64_VS2019_CSharp_DebugType_Full.dll.sarif | 397 ++++++++++--------
 ...x64_VS2019_CSharp_DebugType_None.dll.sarif | 385 ++++++++++-------
 ..._VS2019_CSharp_DebugType_PdbOnly.dll.sarif | 397 ++++++++++--------
 ...VS2019_CSharp_DebugType_Portable.dll.sarif | 397 ++++++++++--------
 ...x64_VS2019_VB_DebugType_Embedded.dll.sarif | 397 ++++++++++--------
 ...ged_x64_VS2019_VB_DebugType_Full.dll.sarif | 397 ++++++++++--------
 ...ged_x64_VS2019_VB_DebugType_None.dll.sarif | 385 ++++++++++-------
 ..._x64_VS2019_VB_DebugType_PdbOnly.dll.sarif | 397 ++++++++++--------
 ...x64_VS2019_VB_DebugType_Portable.dll.sarif | 397 ++++++++++--------
 .../Expected/Managed_x86_VS2013_Wpf.exe.sarif | 397 ++++++++++--------
 .../Managed_x86_VS2015_FSharp.dll.sarif       | 397 ++++++++++--------
 .../MixedMode_x64_VS2013_Default.dll.sarif    | 397 ++++++++++--------
 .../MixedMode_x64_VS2013_NoPdb.exe.sarif      | 277 +++++++-----
 .../MixedMode_x64_VS2015_Default.exe.sarif    | 397 ++++++++++--------
 ...4_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif | 397 ++++++++++--------
 ..._VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif | 397 ++++++++++--------
 ..._x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif | 397 ++++++++++--------
 ..._x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif | 277 +++++++-----
 .../MixedMode_x86_VS2013_Default.exe.sarif    | 397 ++++++++++--------
 .../MixedMode_x86_VS2013_MissingPdb.dll.sarif | 277 +++++++-----
 .../MixedMode_x86_VS2015_Default.exe.sarif    | 397 ++++++++++--------
 ...ve_ARM_VS2015_CvtresResourceOnly.dll.sarif | 385 ++++++++++-------
 .../Native_x64_VS2013_Default.dll.sarif       | 397 ++++++++++--------
 ...ve_x64_VS2015_CvtresResourceOnly.dll.sarif | 385 ++++++++++-------
 .../Native_x64_VS2015_Default.dll.sarif       | 397 ++++++++++--------
 ...ve_x64_VS2019_Atl_NoPdbGenerated.dll.sarif | 277 +++++++-----
 ...4_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif | 397 ++++++++++--------
 ..._VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif | 397 ++++++++++--------
 ..._x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif | 397 ++++++++++--------
 ..._x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif | 277 +++++++-----
 .../Native_x64_VS2019_SDL_Enabled.exe.sarif   | 397 ++++++++++--------
 ...tive_x64_VSCode_Rust_DebugInfo_0.exe.sarif | 397 ++++++++++--------
 ...tive_x64_VSCode_Rust_DebugInfo_1.exe.sarif | 397 ++++++++++--------
 ...tive_x64_VSCode_Rust_DebugInfo_2.exe.sarif | 397 ++++++++++--------
 .../Native_x86_VS2012_SDL_Enabled.exe.sarif   | 397 ++++++++++--------
 .../Native_x86_VS2013_Default.exe.sarif       | 397 ++++++++++--------
 .../Native_x86_VS2013_PdbMissing.exe.sarif    | 277 +++++++-----
 .../Native_x86_VS2013_ResourceOnly.dll.sarif  | 397 ++++++++++--------
 ...Native_x86_VS2015_AtlProxyStubPS.dll.sarif | 397 ++++++++++--------
 ...ve_x86_VS2015_CvtresResourceOnly.dll.sarif | 385 ++++++++++-------
 .../Native_x86_VS2015_Default.exe.sarif       | 397 ++++++++++--------
 .../Native_x86_VS2015_Default_Debug.dll.sarif | 397 ++++++++++--------
 ...ve_x86_VS2017_15.5.4_PdbStripped.dll.sarif | 277 +++++++-----
 .../Native_x86_VS2019_SDL_Enabled.exe.sarif   | 397 ++++++++++--------
 .../Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif   | 397 ++++++++++--------
 .../Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif  | 313 ++++++++------
 .../Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif  | 277 +++++++-----
 .../Expected/Uwp_ARM_VS2017_VB.dll.sarif      | 397 ++++++++++--------
 ...wp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif | 397 ++++++++++--------
 .../Uwp_x64_VS2015_DefaultBlankApp.dll.sarif  | 313 ++++++++------
 .../Uwp_x64_VS2015_DefaultBlankApp.exe.sarif  | 277 +++++++-----
 .../Expected/Uwp_x64_VS2017_Cpp.dll.sarif     | 397 ++++++++++--------
 .../Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif    | 397 ++++++++++--------
 .../Uwp_x86_VS2015_DefaultBlankApp.dll.sarif  | 313 ++++++++------
 .../Uwp_x86_VS2015_DefaultBlankApp.exe.sarif  | 277 +++++++-----
 .../Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif    | 397 ++++++++++--------
 .../Wix_3.11.1_VS2017_Bootstrapper.exe.sarif  | 397 ++++++++++--------
 .../Expected/clang.default_compilation.sarif  | 385 ++++++++++-------
 .../Expected/clang.elf.objectivec.dwarf.sarif | 397 ++++++++++--------
 .../Expected/clang.execstack.sarif            | 385 ++++++++++-------
 .../Expected/clang.execstack.so.sarif         | 385 ++++++++++-------
 .../Expected/clang.immediate_binding.sarif    | 385 ++++++++++-------
 .../Expected/clang.no_immediate_binding.sarif | 385 ++++++++++-------
 .../Expected/clang.no_stack_protector.sarif   | 385 ++++++++++-------
 .../Expected/clang.noexecstack.sarif          | 385 ++++++++++-------
 .../Expected/clang.noexecstack.so.sarif       | 385 ++++++++++-------
 .../Expected/clang.non_pie_executable.sarif   | 385 ++++++++++-------
 .../Expected/clang.object_file.o.sarif        | 385 ++++++++++-------
 .../Expected/clang.pie_executable.sarif       | 385 ++++++++++-------
 .../Expected/clang.relocationsro.sarif        | 385 ++++++++++-------
 .../Expected/clang.relocationsrw.sarif        | 385 ++++++++++-------
 .../Expected/clang.shared_library.so.sarif    | 385 ++++++++++-------
 .../Expected/clang.stack_protector.a.sarif    |   1 -
 .../Expected/clang.stack_protector.sarif      | 385 ++++++++++-------
 .../Expected/clang.stack_protector.so.sarif   | 385 ++++++++++-------
 .../clangcl.pe.cpp.codeview.exe.sarif         | 397 ++++++++++--------
 .../Expected/gcc.default_compilation.sarif    | 385 ++++++++++-------
 ...rongsspbuffersize8+fnostackprotector.sarif | 397 ++++++++++--------
 .../Expected/gcc.execstack.sarif              | 385 ++++++++++-------
 .../Expected/gcc.execstack.so.sarif           | 385 ++++++++++-------
 .../Expected/gcc.fortified.sarif              | 385 ++++++++++-------
 .../Expected/gcc.gsplitdwarf.5.dwo.sarif      | 397 ++++++++++--------
 .../Expected/gcc.gsplitdwarf.5.sarif          | 397 ++++++++++--------
 ...oworld.4.o.no-stack-clash-protection.sarif | 397 ++++++++++--------
 ...oworld.5.o.no-stack-clash-protection.sarif | 397 ++++++++++--------
 .../gcc.helloworld.execstack.5.o.sarif        | 397 ++++++++++--------
 .../Expected/gcc.helloworld.nodwarf.sarif     | 385 ++++++++++-------
 .../gcc.helloworld.noexecstack.5.o.sarif      | 397 ++++++++++--------
 .../Expected/gcc.immediate_binding.sarif      | 385 ++++++++++-------
 .../gcc.no_fortification_required.sarif       | 385 ++++++++++-------
 .../Expected/gcc.no_immediate_binding.sarif   | 385 ++++++++++-------
 .../Expected/gcc.no_stack_protector.sarif     | 385 ++++++++++-------
 .../Expected/gcc.noexecstack.sarif            | 385 ++++++++++-------
 .../Expected/gcc.noexecstack.so.sarif         | 385 ++++++++++-------
 .../Expected/gcc.non_pie_executable.sarif     | 385 ++++++++++-------
 ...objcopy.stripall.addgnudebuglink.dbg.sarif | 397 ++++++++++--------
 ...gcc.objcopy.stripall.addgnudebuglink.sarif | 385 ++++++++++-------
 .../Expected/gcc.object_file.o.sarif          | 385 ++++++++++-------
 .../gcc.pe.objectivec.dwarf.exe.sarif         | 277 +++++++-----
 .../Expected/gcc.pie_executable.sarif         | 385 ++++++++++-------
 .../Expected/gcc.relocationsro.sarif          | 385 ++++++++++-------
 .../Expected/gcc.relocationsrw.sarif          | 385 ++++++++++-------
 .../Expected/gcc.requiredsymbol.4.o.sarif     | 397 ++++++++++--------
 .../Expected/gcc.requiredsymbol.5.o.sarif     | 397 ++++++++++--------
 .../Expected/gcc.shared_library.so.sarif      | 385 ++++++++++-------
 .../Expected/gcc.stack_protector.a.sarif      |   1 -
 .../Expected/gcc.stack_protector.sarif        | 385 ++++++++++-------
 .../Expected/gcc.stack_protector.so.sarif     | 385 ++++++++++-------
 .../Expected/gcc.unfortified.sarif            | 385 ++++++++++-------
 130 files changed, 28091 insertions(+), 20195 deletions(-)

diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif
index bb6cbc52c..65d6d9d03 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif
@@ -790,10 +790,13 @@
           "rules": [
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -805,20 +808,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -836,17 +841,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -861,20 +868,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -892,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -920,20 +931,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -948,20 +961,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -979,20 +994,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1004,20 +1021,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1035,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1060,20 +1081,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1088,20 +1111,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1122,17 +1147,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1144,17 +1171,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1166,17 +1195,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1191,17 +1222,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1216,17 +1249,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1238,17 +1273,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1260,17 +1297,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1282,17 +1321,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1304,17 +1345,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1326,17 +1369,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1348,17 +1393,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1376,17 +1423,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1398,17 +1447,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1420,17 +1471,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1442,20 +1495,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1470,20 +1525,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1501,20 +1558,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1526,20 +1585,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1560,20 +1621,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1585,20 +1648,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1613,20 +1678,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1644,10 +1711,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1672,7 +1738,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif
index 1f7827462..ebcc7c5d5 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif
@@ -788,10 +788,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -803,20 +806,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -828,20 +833,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -859,17 +866,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -884,20 +893,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -915,20 +926,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -943,20 +956,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1002,20 +1019,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1027,20 +1046,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1058,20 +1079,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1092,17 +1115,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1114,17 +1139,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1136,17 +1163,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1161,17 +1190,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1186,17 +1217,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1208,17 +1241,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1230,17 +1265,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1252,17 +1289,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1274,17 +1313,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1296,17 +1337,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1318,17 +1361,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1346,17 +1391,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1368,17 +1415,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1390,17 +1439,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1415,20 +1466,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1446,20 +1499,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1471,20 +1526,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1505,20 +1562,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1530,20 +1589,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1558,20 +1619,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1583,20 +1646,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1611,20 +1676,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1642,10 +1709,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1670,7 +1736,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif
index 8eb5f44e6..6ec50de89 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif
@@ -772,10 +772,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -787,20 +790,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -812,20 +817,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -840,20 +847,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -871,20 +880,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -899,20 +910,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -924,20 +937,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -952,20 +967,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -986,20 +1003,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1017,20 +1036,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1042,20 +1063,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1073,20 +1096,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1098,20 +1123,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1126,20 +1153,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1160,17 +1189,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1182,17 +1213,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1204,17 +1237,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1229,17 +1264,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1254,17 +1291,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1276,17 +1315,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1298,17 +1339,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1320,17 +1363,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1342,17 +1387,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1364,17 +1411,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1386,17 +1435,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1414,17 +1465,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1436,17 +1489,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1458,17 +1513,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1483,20 +1540,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1514,20 +1573,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1539,20 +1600,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1567,20 +1630,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1598,10 +1663,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1646,7 +1710,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif
index be14e14d1..64053d782 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif
@@ -790,10 +790,13 @@
           "rules": [
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -805,20 +808,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -836,17 +841,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -861,20 +868,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -892,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -920,20 +931,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -948,20 +961,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -979,20 +994,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1004,20 +1021,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1035,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1060,20 +1081,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1088,20 +1111,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1122,17 +1147,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1144,17 +1171,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1166,17 +1195,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1191,17 +1222,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1216,17 +1249,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1238,17 +1273,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1260,17 +1297,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1282,17 +1321,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1304,17 +1345,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1326,17 +1369,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1348,17 +1393,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1376,17 +1423,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1398,17 +1447,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1420,17 +1471,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1442,20 +1495,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1470,20 +1525,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1501,20 +1558,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1526,20 +1585,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1560,20 +1621,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1585,20 +1648,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1613,20 +1678,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1644,10 +1711,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1672,7 +1738,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif
index bb317f7e7..79b1d4cb0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif
@@ -772,10 +772,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -787,20 +790,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -812,20 +817,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -840,20 +847,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -871,20 +880,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -899,20 +910,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -924,20 +937,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -952,20 +967,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -986,20 +1003,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1017,20 +1036,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1042,20 +1063,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1073,20 +1096,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1098,20 +1123,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1126,20 +1153,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1160,17 +1189,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1182,17 +1213,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1204,17 +1237,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1229,17 +1264,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1254,17 +1291,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1276,17 +1315,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1298,17 +1339,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1320,17 +1363,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1342,17 +1387,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1364,17 +1411,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1386,17 +1435,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1414,17 +1465,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1436,17 +1489,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1458,17 +1513,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1483,20 +1540,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1514,20 +1573,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1539,20 +1600,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1567,20 +1630,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1598,10 +1663,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1646,7 +1710,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif
index e43aaf0d1..50fe6d486 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif
@@ -788,10 +788,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -803,20 +806,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -828,20 +833,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -859,17 +866,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -884,20 +893,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -915,20 +926,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -943,20 +956,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1002,20 +1019,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1027,20 +1046,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1058,20 +1079,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1092,17 +1115,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1114,17 +1139,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1136,17 +1163,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1161,17 +1190,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1186,17 +1217,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1208,17 +1241,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1230,17 +1265,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1252,17 +1289,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1274,17 +1313,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1296,17 +1337,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1318,17 +1361,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1346,17 +1391,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1368,17 +1415,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1390,17 +1439,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1415,20 +1466,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1446,20 +1499,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1471,20 +1526,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1505,20 +1562,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1530,20 +1589,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1558,20 +1619,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1583,20 +1646,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1611,20 +1676,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1642,10 +1709,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1670,7 +1736,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif
index 92dda9ce4..933aa32a2 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +786,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -836,20 +843,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -867,20 +876,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -895,20 +906,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -920,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -948,20 +963,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -982,20 +999,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1013,20 +1032,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1038,20 +1059,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1069,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1103,17 +1128,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1125,17 +1152,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1147,17 +1176,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1172,17 +1203,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1197,17 +1230,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1219,17 +1254,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1241,17 +1278,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1263,17 +1302,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1285,17 +1326,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1307,17 +1350,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1329,17 +1374,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1357,17 +1404,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1379,17 +1428,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1401,17 +1452,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1426,20 +1479,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1457,20 +1512,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1482,20 +1539,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1510,20 +1569,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1535,20 +1596,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1563,20 +1626,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1594,10 +1659,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1642,7 +1706,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Corrupted_Native_x86_VS2013_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Corrupted_Native_x86_VS2013_Default.exe.sarif
index 657da81f3..1ed0528af 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Corrupted_Native_x86_VS2013_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Corrupted_Native_x86_VS2013_Default.exe.sarif
@@ -50,7 +50,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif
index 737c671a7..9d15fcbc5 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif
@@ -795,10 +795,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -810,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -835,20 +840,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -863,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -894,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -922,20 +933,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -947,20 +960,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -975,20 +990,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1009,20 +1026,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1040,20 +1059,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1065,20 +1086,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1096,20 +1119,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1121,20 +1146,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1149,20 +1176,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1183,17 +1212,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1205,17 +1236,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1227,17 +1260,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1252,17 +1287,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1277,17 +1314,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1299,17 +1338,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1321,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1343,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1365,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1387,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1409,17 +1458,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1437,17 +1488,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1459,17 +1512,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1481,17 +1536,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1509,17 +1566,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1534,20 +1593,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1565,20 +1626,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1590,20 +1653,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1618,20 +1683,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1649,10 +1716,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1677,7 +1743,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif
index ee7b4cd70..56b3adc58 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif
@@ -795,10 +795,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -810,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -835,20 +840,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -863,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -894,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -922,20 +933,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -947,20 +960,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -975,20 +990,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1009,20 +1026,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1040,20 +1059,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1065,20 +1086,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1096,20 +1119,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1121,20 +1146,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1149,20 +1176,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1183,17 +1212,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1205,17 +1236,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1227,17 +1260,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1252,17 +1287,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1277,17 +1314,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1299,17 +1338,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1321,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1343,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1365,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1387,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1409,17 +1458,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1437,17 +1488,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1459,17 +1512,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1481,17 +1536,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1509,17 +1566,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1534,20 +1593,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1565,20 +1626,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1590,20 +1653,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1618,20 +1683,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1649,10 +1716,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1677,7 +1743,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif
index 9f25db574..f1bda8df7 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif
@@ -791,10 +791,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +866,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +929,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +956,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1082,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1151,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1175,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1199,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1226,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1253,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1277,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1301,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1325,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1349,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1373,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1397,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1427,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1451,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1475,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1532,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1565,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1622,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1649,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1679,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,10 +1712,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1673,7 +1739,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif
index ddcf41a4f..1c5b99a21 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif
@@ -795,10 +795,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -810,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -835,20 +840,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -863,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -894,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -922,20 +933,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -947,20 +960,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -975,20 +990,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1009,20 +1026,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1040,20 +1059,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1065,20 +1086,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1096,20 +1119,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1121,20 +1146,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1149,20 +1176,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1183,17 +1212,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1205,17 +1236,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1227,17 +1260,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1252,17 +1287,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1277,17 +1314,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1299,17 +1338,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1321,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1343,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1365,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1387,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1409,17 +1458,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1437,17 +1488,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1459,17 +1512,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1481,17 +1536,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1509,17 +1566,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1534,20 +1593,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1565,20 +1626,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1590,20 +1653,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1618,20 +1683,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1649,10 +1716,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1677,7 +1743,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif
index 3cb656772..daeb0d495 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif
@@ -795,10 +795,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -810,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -835,20 +840,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -863,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -894,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -922,20 +933,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -947,20 +960,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -975,20 +990,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1009,20 +1026,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1040,20 +1059,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1065,20 +1086,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1096,20 +1119,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1121,20 +1146,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1149,20 +1176,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1183,17 +1212,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1205,17 +1236,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1227,17 +1260,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1252,17 +1287,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1277,17 +1314,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1299,17 +1338,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1321,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1343,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1365,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1387,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1409,17 +1458,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1437,17 +1488,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1459,17 +1512,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1481,17 +1536,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1509,17 +1566,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1534,20 +1593,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1565,20 +1626,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1590,20 +1653,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1618,20 +1683,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1649,10 +1716,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1677,7 +1743,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif
index 4cb3fc583..c04c4b3dd 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif
@@ -786,10 +786,13 @@
           "rules": [
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -801,20 +804,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -832,17 +837,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -857,20 +864,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -888,20 +897,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -916,20 +927,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -947,20 +960,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -972,20 +987,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -997,20 +1014,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1025,20 +1044,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1059,17 +1080,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1081,17 +1104,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1103,17 +1128,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1128,17 +1155,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1153,17 +1182,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1175,17 +1206,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1197,17 +1230,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1219,17 +1254,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1241,17 +1278,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1263,17 +1302,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1285,17 +1326,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1313,17 +1356,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1335,17 +1380,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1357,17 +1404,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1379,20 +1428,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1407,20 +1458,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1435,20 +1488,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1466,20 +1521,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1491,20 +1548,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1525,20 +1584,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1556,20 +1617,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1581,20 +1644,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1609,20 +1674,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1640,10 +1707,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1668,7 +1734,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif
index 9a11763c7..60c860595 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif
@@ -791,10 +791,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +866,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +929,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +956,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1082,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1151,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1175,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1199,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1226,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1253,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1277,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1301,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1325,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1349,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1373,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1397,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1427,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1451,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1475,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1532,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1565,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1622,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1649,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1679,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,10 +1712,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1673,7 +1739,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif
index a548c6db5..29bb9a1ec 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +786,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -836,20 +843,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -867,20 +876,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -895,20 +906,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -920,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -948,20 +963,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -982,20 +999,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1013,20 +1032,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1038,20 +1059,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1069,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1103,17 +1128,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1125,17 +1152,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1147,17 +1176,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1172,17 +1203,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1197,17 +1230,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1219,17 +1254,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1241,17 +1278,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1263,17 +1302,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1285,17 +1326,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1307,17 +1350,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1329,17 +1374,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1357,17 +1404,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1379,17 +1428,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1401,17 +1452,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1426,20 +1479,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1457,20 +1512,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1482,20 +1539,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1510,20 +1569,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1535,20 +1596,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1563,20 +1626,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1594,10 +1659,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1642,7 +1706,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif
index 424eccf83..9cb9f5861 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif
@@ -771,10 +771,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -786,20 +789,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -811,20 +816,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -839,20 +846,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -870,20 +879,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -898,20 +909,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -923,20 +936,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -951,20 +966,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -985,20 +1002,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1016,20 +1035,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1041,20 +1062,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1072,20 +1095,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1097,20 +1122,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1125,20 +1152,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1159,17 +1188,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1181,17 +1212,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1203,17 +1236,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1228,17 +1263,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1253,17 +1290,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1275,17 +1314,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1297,17 +1338,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1319,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1341,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1363,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1385,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1413,17 +1464,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1435,17 +1488,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1457,17 +1512,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1482,20 +1539,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1513,20 +1572,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1538,20 +1599,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1566,20 +1629,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1597,10 +1662,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1645,7 +1709,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif
index f2d68c0aa..b503fe5aa 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif
@@ -785,10 +785,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -800,20 +803,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -825,20 +830,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -853,20 +860,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -884,20 +893,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -912,20 +923,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -937,20 +950,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -965,20 +980,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -999,20 +1016,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1030,20 +1049,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1055,20 +1076,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1089,17 +1112,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1111,17 +1136,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1133,17 +1160,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1158,17 +1187,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1183,17 +1214,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1205,17 +1238,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1227,17 +1262,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1249,17 +1286,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1271,17 +1310,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1293,17 +1334,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1315,17 +1358,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1343,17 +1388,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1365,17 +1412,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1387,17 +1436,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1415,17 +1466,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1440,20 +1493,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1471,20 +1526,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1502,20 +1559,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1527,20 +1586,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1555,20 +1616,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1580,20 +1643,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1608,20 +1673,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1639,10 +1706,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1667,7 +1733,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif
index 42594fd5a..beb05901c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif
@@ -788,10 +788,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -803,20 +806,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -828,20 +833,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -856,20 +863,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -887,20 +896,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -915,20 +926,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -940,20 +953,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -968,20 +983,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1002,20 +1019,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1033,20 +1052,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1058,20 +1079,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1089,20 +1112,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1123,17 +1148,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1145,17 +1172,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1167,17 +1196,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1192,17 +1223,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1217,17 +1250,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1239,17 +1274,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1261,17 +1298,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1283,17 +1322,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1305,17 +1346,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1327,17 +1370,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1349,17 +1394,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1377,17 +1424,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1399,17 +1448,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1421,17 +1472,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1449,17 +1502,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1474,20 +1529,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1505,20 +1562,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1530,20 +1589,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1558,20 +1619,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1583,20 +1646,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1611,20 +1676,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1642,10 +1709,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1670,7 +1736,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif
index 746bbff38..89e03df15 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif
@@ -790,10 +790,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -805,20 +808,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -830,20 +835,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -858,20 +865,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -889,20 +898,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -917,20 +928,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -942,20 +955,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -970,20 +985,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1004,20 +1021,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1035,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1060,20 +1081,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1085,20 +1108,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1113,20 +1138,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1147,17 +1174,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1169,17 +1198,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1191,17 +1222,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1216,17 +1249,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1241,17 +1276,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1263,17 +1300,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1285,17 +1324,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1307,17 +1348,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1329,17 +1372,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1351,17 +1396,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1373,17 +1420,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1401,17 +1450,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1423,17 +1474,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1445,17 +1498,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1473,17 +1528,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1498,20 +1555,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1529,20 +1588,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1560,20 +1621,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1585,20 +1648,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1613,20 +1678,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1644,10 +1711,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1672,7 +1738,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif
index 409780d31..6c33f0790 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif
@@ -791,10 +791,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +866,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +929,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +956,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1082,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1151,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1175,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1199,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1226,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1253,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1277,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1301,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1325,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1349,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1373,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1397,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1427,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1451,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1475,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1532,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1565,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1622,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1649,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1679,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,10 +1712,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1673,7 +1739,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif
index 425c672a8..cacfafb66 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif
@@ -791,10 +791,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +866,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +929,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +956,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1082,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1151,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1175,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1199,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1226,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1253,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1277,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1301,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1325,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1349,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1373,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1397,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1427,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1451,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1475,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1532,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1565,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1622,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1649,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1679,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,10 +1712,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1673,7 +1739,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif
index 5e422baa5..87178f04a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +786,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -836,20 +843,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -867,20 +876,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -895,20 +906,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -920,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -948,20 +963,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -982,20 +999,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1013,20 +1032,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1038,20 +1059,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1069,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1103,17 +1128,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1125,17 +1152,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1147,17 +1176,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1172,17 +1203,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1197,17 +1230,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1219,17 +1254,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1241,17 +1278,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1263,17 +1302,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1285,17 +1326,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1307,17 +1350,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1329,17 +1374,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1357,17 +1404,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1379,17 +1428,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1401,17 +1452,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1426,20 +1479,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1457,20 +1512,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1482,20 +1539,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1510,20 +1569,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1535,20 +1596,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1563,20 +1626,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1594,10 +1659,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1642,7 +1706,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif
index c4762c40d..2545c7a7d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif
@@ -791,10 +791,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +866,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +929,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +956,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1082,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1151,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1175,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1199,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1226,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1253,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1277,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1301,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1325,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1349,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1373,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1397,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1427,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1451,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1475,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1532,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1565,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1622,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1649,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1679,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,10 +1712,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1673,7 +1739,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif
index 07122911d..232ddc41f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif
@@ -791,10 +791,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +866,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +929,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +956,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1082,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1151,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1175,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1199,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1226,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1253,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1277,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1301,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1325,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1349,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1373,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1397,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1427,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1451,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1475,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1532,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1565,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1622,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1649,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1679,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,10 +1712,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1673,7 +1739,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif
index ae31c8c2f..de3e04dfc 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif
@@ -791,10 +791,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +866,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +929,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +956,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1082,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1151,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1175,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1199,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1226,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1253,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1277,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1301,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1325,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1349,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1373,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1397,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1427,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1451,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1475,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1532,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1565,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1622,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1649,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1679,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,10 +1712,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1673,7 +1739,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif
index 5451af733..366d4741c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif
@@ -791,10 +791,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +866,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +929,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +956,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1082,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1151,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1175,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1199,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1226,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1253,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1277,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1301,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1325,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1349,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1373,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1397,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1427,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1451,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1475,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1532,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1565,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1622,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1649,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1679,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,10 +1712,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1673,7 +1739,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif
index 28542b0c5..3b1516b1b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +786,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -836,20 +843,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -867,20 +876,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -895,20 +906,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -920,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -948,20 +963,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -982,20 +999,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1013,20 +1032,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1038,20 +1059,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1069,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1103,17 +1128,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1125,17 +1152,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1147,17 +1176,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1172,17 +1203,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1197,17 +1230,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1219,17 +1254,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1241,17 +1278,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1263,17 +1302,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1285,17 +1326,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1307,17 +1350,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1329,17 +1374,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1357,17 +1404,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1379,17 +1428,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1401,17 +1452,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1426,20 +1479,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1457,20 +1512,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1482,20 +1539,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1510,20 +1569,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1535,20 +1596,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1563,20 +1626,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1594,10 +1659,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1642,7 +1706,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif
index bff3c2ac8..cf3650996 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif
@@ -791,10 +791,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +866,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +929,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +956,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1082,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1151,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1175,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1199,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1226,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1253,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1277,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1301,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1325,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1349,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1373,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1397,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1427,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1451,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1475,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1532,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1565,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1622,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1649,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1679,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,10 +1712,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1673,7 +1739,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif
index 8838bed96..4aadd4f96 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif
@@ -791,10 +791,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -859,20 +866,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -890,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -918,20 +929,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -943,20 +956,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1005,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1036,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1061,20 +1082,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1092,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1126,17 +1151,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1148,17 +1175,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1170,17 +1199,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1195,17 +1226,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1220,17 +1253,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1242,17 +1277,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1264,17 +1301,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1286,17 +1325,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1308,17 +1349,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1330,17 +1373,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1352,17 +1397,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1380,17 +1427,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1402,17 +1451,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1424,17 +1475,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1452,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1477,20 +1532,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1508,20 +1565,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1561,20 +1622,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1586,20 +1649,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1614,20 +1679,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1645,10 +1712,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1673,7 +1739,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif
index 5bdec020b..e5c573d30 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif
@@ -788,10 +788,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -803,20 +806,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -828,20 +833,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -856,20 +863,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -887,20 +896,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -915,20 +926,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -940,20 +953,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -968,20 +983,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1002,20 +1019,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1033,20 +1052,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1058,20 +1079,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1089,20 +1112,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1123,17 +1148,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1145,17 +1172,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1167,17 +1196,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1192,17 +1223,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1217,17 +1250,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1239,17 +1274,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1261,17 +1298,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1283,17 +1322,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1305,17 +1346,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1327,17 +1370,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1349,17 +1394,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1377,17 +1424,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1399,17 +1448,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1421,17 +1472,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1449,17 +1502,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1474,20 +1529,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1505,20 +1562,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1530,20 +1589,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1558,20 +1619,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1583,20 +1646,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1611,20 +1676,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1642,10 +1709,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1670,7 +1736,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif
index a90dc7ec7..419e0dcdc 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif
@@ -788,10 +788,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -803,20 +806,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -828,20 +833,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -856,20 +863,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -887,20 +896,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -915,20 +926,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -940,20 +953,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -968,20 +983,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1002,20 +1019,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1033,20 +1052,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1058,20 +1079,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1089,20 +1112,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1123,17 +1148,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1145,17 +1172,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1167,17 +1196,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1192,17 +1223,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1217,17 +1250,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1239,17 +1274,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1261,17 +1298,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1283,17 +1322,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1305,17 +1346,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1327,17 +1370,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1349,17 +1394,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1377,17 +1424,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1399,17 +1448,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1421,17 +1472,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1449,17 +1502,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1474,20 +1529,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1505,20 +1562,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1530,20 +1589,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1558,20 +1619,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1583,20 +1646,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1611,20 +1676,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1642,10 +1709,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1670,7 +1736,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif
index 6b7d4c235..5c7311b7b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif
@@ -789,10 +789,13 @@
           "rules": [
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -807,20 +810,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -838,20 +843,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -863,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -891,20 +900,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -919,17 +930,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -944,17 +957,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -966,17 +981,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -988,17 +1005,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1010,17 +1029,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1032,17 +1053,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1054,17 +1077,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1076,17 +1101,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1104,17 +1131,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1126,17 +1155,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1148,17 +1179,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1170,20 +1203,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1195,20 +1230,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1226,17 +1263,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1251,20 +1290,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1279,20 +1320,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1310,20 +1353,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1341,20 +1386,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1366,20 +1413,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1394,20 +1443,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1428,20 +1479,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1459,20 +1512,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1484,20 +1539,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1509,20 +1566,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1537,20 +1596,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1568,17 +1629,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1599,17 +1662,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1621,17 +1686,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1643,10 +1710,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1671,7 +1737,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif
index 61a2ac74f..8f997e867 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif
@@ -548,10 +548,13 @@
           "rules": [
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -566,20 +569,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -591,20 +596,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -619,20 +626,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -647,17 +656,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -672,17 +683,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -694,17 +707,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -716,17 +731,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -738,17 +755,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -760,17 +779,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -782,17 +803,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -804,17 +827,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -832,17 +857,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -854,17 +881,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -876,17 +905,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -898,20 +929,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -926,20 +959,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -957,20 +992,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -982,20 +1019,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1016,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1047,20 +1088,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1072,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1100,20 +1145,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1131,10 +1178,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1179,7 +1225,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif
index 5e2b8f9df..d8fb13d6d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif
@@ -787,10 +787,13 @@
           "rules": [
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -805,20 +808,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -830,20 +835,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -858,20 +865,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -886,17 +895,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -911,17 +922,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -933,17 +946,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -955,17 +970,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -977,17 +994,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -999,17 +1018,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1021,17 +1042,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1043,17 +1066,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1071,17 +1096,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1093,17 +1120,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1115,17 +1144,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1137,20 +1168,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1162,20 +1195,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1193,17 +1228,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1218,20 +1255,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1246,20 +1285,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1277,20 +1318,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1308,20 +1351,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1333,20 +1378,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1361,20 +1408,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1395,20 +1444,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1426,20 +1477,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1451,20 +1504,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1482,20 +1537,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1507,20 +1564,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1535,20 +1594,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1566,17 +1627,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1597,17 +1660,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1619,17 +1684,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1641,10 +1708,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1669,7 +1735,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
index 62f8441bc..c3858194b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
@@ -790,10 +790,13 @@
           "rules": [
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -808,20 +811,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -839,20 +844,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -864,20 +871,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -892,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -920,17 +931,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -945,17 +958,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -967,17 +982,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -989,17 +1006,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1011,17 +1030,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1033,17 +1054,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1055,17 +1078,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1077,17 +1102,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1105,17 +1132,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1127,17 +1156,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1149,17 +1180,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1171,20 +1204,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1196,20 +1231,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1227,17 +1264,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1252,20 +1291,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1280,20 +1321,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1311,20 +1354,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1342,20 +1387,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1367,20 +1414,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1395,20 +1444,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1429,20 +1480,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1460,20 +1513,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1485,20 +1540,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1510,20 +1567,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1538,20 +1597,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1569,17 +1630,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1600,17 +1663,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1622,17 +1687,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1644,10 +1711,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1672,7 +1738,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
index c4872d266..281195b9d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
@@ -790,10 +790,13 @@
           "rules": [
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -808,20 +811,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -839,20 +844,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -864,20 +871,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -892,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -920,17 +931,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -945,17 +958,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -967,17 +982,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -989,17 +1006,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1011,17 +1030,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1033,17 +1054,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1055,17 +1078,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1077,17 +1102,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1105,17 +1132,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1127,17 +1156,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1149,17 +1180,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1171,20 +1204,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1196,20 +1231,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1227,17 +1264,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1252,20 +1291,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1280,20 +1321,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1311,20 +1354,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1342,20 +1387,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1367,20 +1414,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1395,20 +1444,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1429,20 +1480,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1460,20 +1513,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1485,20 +1540,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1510,20 +1567,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1538,20 +1597,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1569,17 +1630,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1600,17 +1663,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1622,17 +1687,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1644,10 +1711,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1672,7 +1738,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
index 31a81fb66..e8753fd8d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
@@ -790,10 +790,13 @@
           "rules": [
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -808,20 +811,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -839,20 +844,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -864,20 +871,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -892,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -920,17 +931,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -945,17 +958,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -967,17 +982,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -989,17 +1006,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1011,17 +1030,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1033,17 +1054,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1055,17 +1078,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1077,17 +1102,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1105,17 +1132,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1127,17 +1156,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1149,17 +1180,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1171,20 +1204,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1196,20 +1231,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1227,17 +1264,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1252,20 +1291,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1280,20 +1321,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1311,20 +1354,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1342,20 +1387,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1367,20 +1414,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1395,20 +1444,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1429,20 +1480,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1460,20 +1513,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1485,20 +1540,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1510,20 +1567,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1538,20 +1597,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1569,17 +1630,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1600,17 +1663,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1622,17 +1687,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1644,10 +1711,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1672,7 +1738,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
index 7c214e370..9fd342723 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
@@ -550,10 +550,13 @@
           "rules": [
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -568,20 +571,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -599,20 +604,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -624,20 +631,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -652,20 +661,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -680,17 +691,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -705,17 +718,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -727,17 +742,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -749,17 +766,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -771,17 +790,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -793,17 +814,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -815,17 +838,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -837,17 +862,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -865,17 +892,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -887,17 +916,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -909,17 +940,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -931,20 +964,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -959,20 +994,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -990,20 +1027,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1015,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1049,20 +1090,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1074,20 +1117,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1102,20 +1147,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1133,10 +1180,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1181,7 +1227,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif
index 919eb0d23..a9164171b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif
@@ -784,10 +784,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -799,20 +802,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -827,20 +832,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -855,17 +862,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -880,17 +889,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -902,17 +913,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -924,17 +937,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -946,17 +961,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -968,17 +985,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -990,17 +1009,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1012,17 +1033,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1040,17 +1063,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1062,17 +1087,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1084,17 +1111,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1106,20 +1135,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1137,17 +1168,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1162,20 +1195,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1190,20 +1225,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1221,20 +1258,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1252,20 +1291,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1277,20 +1318,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1305,20 +1348,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1339,20 +1384,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1370,20 +1417,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1395,20 +1444,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1426,20 +1477,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1451,20 +1504,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1479,20 +1534,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1504,20 +1561,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1532,20 +1591,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1563,17 +1624,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1594,17 +1657,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1616,17 +1681,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1638,10 +1705,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1666,7 +1732,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif
index 9ab35211b..40d87b128 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif
@@ -548,10 +548,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -563,20 +566,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -591,20 +596,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -622,20 +629,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -650,17 +659,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -675,17 +686,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -697,17 +710,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -719,17 +734,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -741,17 +758,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -763,17 +782,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -785,17 +806,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -807,17 +830,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -835,17 +860,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -857,17 +884,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -879,17 +908,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -904,20 +935,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -935,20 +968,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -960,20 +995,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -994,20 +1031,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1019,20 +1058,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1047,20 +1088,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1072,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1100,20 +1145,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1131,10 +1178,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1179,7 +1225,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif
index 970d913bd..b2567f3bc 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif
@@ -784,10 +784,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -799,20 +802,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -827,20 +832,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -855,17 +862,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -880,17 +889,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -902,17 +913,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -924,17 +937,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -946,17 +961,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -968,17 +985,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -990,17 +1009,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1012,17 +1033,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1040,17 +1063,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1062,17 +1087,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1084,17 +1111,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1106,20 +1135,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1137,17 +1168,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1162,20 +1195,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1190,20 +1225,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1221,20 +1258,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1252,20 +1291,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1277,20 +1318,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1305,20 +1348,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1339,20 +1384,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1370,20 +1417,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1395,20 +1444,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1426,20 +1477,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1451,20 +1504,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1479,20 +1534,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1504,20 +1561,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1532,20 +1591,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1563,17 +1624,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1594,17 +1657,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1616,17 +1681,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1638,10 +1705,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1666,7 +1732,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif
index b06af7739..fc34cd4d0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif
@@ -770,10 +770,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -785,20 +788,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -810,20 +815,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -838,20 +845,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -869,20 +878,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -897,20 +908,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -925,20 +938,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -959,20 +974,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -990,20 +1007,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1015,20 +1034,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1046,20 +1067,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1071,20 +1094,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1099,20 +1124,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1133,17 +1160,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1155,17 +1184,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1177,17 +1208,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1202,17 +1235,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1227,17 +1262,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1249,17 +1286,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1271,17 +1310,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1293,17 +1334,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1315,17 +1358,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1337,17 +1382,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1359,17 +1406,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1387,17 +1436,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1409,17 +1460,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1431,17 +1484,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1456,20 +1511,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1487,20 +1544,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1512,20 +1571,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1537,20 +1598,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1565,20 +1628,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1596,10 +1661,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1644,7 +1708,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif
index 1a0b2f52f..17bcc6e90 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif
@@ -791,10 +791,13 @@
           "rules": [
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -809,20 +812,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -840,20 +845,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -865,20 +872,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -893,20 +902,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -921,17 +932,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -946,17 +959,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -968,17 +983,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -990,17 +1007,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1012,17 +1031,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1034,17 +1055,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1056,17 +1079,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1078,17 +1103,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1106,17 +1133,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1128,17 +1157,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1150,17 +1181,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1172,20 +1205,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1197,20 +1232,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1228,17 +1265,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1253,20 +1292,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1281,20 +1322,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1312,20 +1355,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1343,20 +1388,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1368,20 +1415,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1396,20 +1445,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1430,20 +1481,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1461,20 +1514,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1486,20 +1541,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1511,20 +1568,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1539,20 +1598,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1570,17 +1631,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1601,17 +1664,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1623,17 +1688,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1645,10 +1712,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1673,7 +1739,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif
index 59b669cea..03ce70d6a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif
@@ -770,10 +770,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -785,20 +788,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -810,20 +815,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -838,20 +845,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -869,20 +878,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -897,20 +908,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -925,20 +938,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -959,20 +974,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -990,20 +1007,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1015,20 +1034,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1046,20 +1067,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1071,20 +1094,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1099,20 +1124,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1133,17 +1160,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1155,17 +1184,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1177,17 +1208,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1202,17 +1235,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1227,17 +1262,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1249,17 +1286,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1271,17 +1310,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1293,17 +1334,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1315,17 +1358,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1337,17 +1382,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1359,17 +1406,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1387,17 +1436,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1409,17 +1460,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1431,17 +1484,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1456,20 +1511,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1487,20 +1544,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1512,20 +1571,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1537,20 +1598,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1565,20 +1628,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1596,10 +1661,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1644,7 +1708,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif
index 1fd5f10a1..1477baf9f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif
@@ -788,10 +788,13 @@
           "rules": [
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -809,20 +812,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -834,20 +839,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -862,20 +869,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -890,17 +899,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -915,17 +926,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -937,17 +950,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -959,17 +974,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -981,17 +998,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1003,17 +1022,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1025,17 +1046,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1047,17 +1070,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1075,17 +1100,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1097,17 +1124,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1119,17 +1148,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1141,20 +1172,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1166,20 +1199,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1197,17 +1232,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1222,20 +1259,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1250,20 +1289,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1281,20 +1322,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1309,20 +1352,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1340,20 +1385,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1365,20 +1412,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1393,20 +1442,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1427,20 +1478,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1458,20 +1511,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1483,20 +1538,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1508,20 +1565,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1536,20 +1595,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1567,17 +1628,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1598,17 +1661,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1620,17 +1685,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1642,10 +1709,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1670,7 +1736,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif
index d337b9ff2..0af238da9 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif
@@ -547,10 +547,13 @@
           "rules": [
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -568,20 +571,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -593,20 +598,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -621,20 +628,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -649,17 +658,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -674,17 +685,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -696,17 +709,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -718,17 +733,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -740,17 +757,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -762,17 +781,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -784,17 +805,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -806,17 +829,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -834,17 +859,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -856,17 +883,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -878,17 +907,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -900,20 +931,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -928,20 +961,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -956,20 +991,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -987,20 +1024,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1012,20 +1051,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1046,20 +1087,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1071,20 +1114,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1099,20 +1144,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1130,10 +1177,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1178,7 +1224,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
index 740d26351..6c3f13f61 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
@@ -787,10 +787,13 @@
           "rules": [
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -808,20 +811,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -833,20 +838,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -861,20 +868,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -889,17 +898,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -914,17 +925,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -936,17 +949,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -958,17 +973,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -980,17 +997,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1002,17 +1021,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1024,17 +1045,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1046,17 +1069,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1074,17 +1099,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1096,17 +1123,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1118,17 +1147,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1140,20 +1171,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1165,20 +1198,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1196,17 +1231,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1221,20 +1258,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1249,20 +1288,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1280,20 +1321,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1308,20 +1351,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1339,20 +1384,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1364,20 +1411,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1392,20 +1441,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1426,20 +1477,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1457,20 +1510,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1482,20 +1537,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1507,20 +1564,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1535,20 +1594,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1566,17 +1627,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1597,17 +1660,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1619,17 +1684,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1641,10 +1708,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1669,7 +1735,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
index a312bbe48..a61379755 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -789,20 +792,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -814,20 +819,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -842,20 +849,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -870,17 +879,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -895,17 +906,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -917,17 +930,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -939,17 +954,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -961,17 +978,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -983,17 +1002,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1005,17 +1026,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1027,17 +1050,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1055,17 +1080,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1077,17 +1104,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1099,17 +1128,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1121,20 +1152,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1146,20 +1179,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1177,17 +1212,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1202,20 +1239,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1230,20 +1269,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1261,20 +1302,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1289,20 +1332,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1320,20 +1365,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1345,20 +1392,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1373,20 +1422,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1407,20 +1458,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1438,20 +1491,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1463,20 +1518,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1488,20 +1545,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1516,20 +1575,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1547,17 +1608,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1578,17 +1641,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1600,17 +1665,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1622,10 +1689,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1650,7 +1716,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
index e0b79a3a0..a5eb4726f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
@@ -787,10 +787,13 @@
           "rules": [
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -808,20 +811,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -833,20 +838,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -861,20 +868,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -889,17 +898,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -914,17 +925,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -936,17 +949,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -958,17 +973,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -980,17 +997,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1002,17 +1021,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1024,17 +1045,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1046,17 +1069,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1074,17 +1099,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1096,17 +1123,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1118,17 +1147,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1140,20 +1171,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1165,20 +1198,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1196,17 +1231,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1221,20 +1258,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1249,20 +1288,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1280,20 +1321,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1308,20 +1351,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1339,20 +1384,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1364,20 +1411,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1392,20 +1441,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1426,20 +1477,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1457,20 +1510,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1482,20 +1537,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1507,20 +1564,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1535,20 +1594,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1566,17 +1627,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1597,17 +1660,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1619,17 +1684,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1641,10 +1708,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1669,7 +1735,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
index 889776c6f..e365fd876 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
@@ -547,10 +547,13 @@
           "rules": [
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -568,20 +571,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -593,20 +598,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -621,20 +628,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -649,17 +658,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -674,17 +685,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -696,17 +709,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -718,17 +733,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -740,17 +757,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -762,17 +781,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -784,17 +805,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -806,17 +829,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -834,17 +859,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -856,17 +883,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -878,17 +907,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -900,20 +931,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -928,20 +961,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -956,20 +991,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -987,20 +1024,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1012,20 +1051,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1046,20 +1087,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1071,20 +1114,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1099,20 +1144,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1130,10 +1177,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1178,7 +1224,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif
index f3aa1ef58..062e9c375 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif
@@ -786,10 +786,13 @@
           "rules": [
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -801,20 +804,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -829,20 +834,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -857,17 +864,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -882,17 +891,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -904,17 +915,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -926,17 +939,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -948,17 +963,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -970,17 +987,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -992,17 +1011,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1014,17 +1035,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1042,17 +1065,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1064,17 +1089,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1086,17 +1113,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1108,20 +1137,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1133,20 +1164,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1164,17 +1197,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1189,20 +1224,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1217,20 +1254,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1248,20 +1287,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1276,20 +1317,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1307,20 +1350,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1332,20 +1377,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1360,20 +1407,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1394,20 +1443,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1425,20 +1476,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1450,20 +1503,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1481,20 +1536,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1506,20 +1563,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1534,20 +1593,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1565,17 +1626,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1596,17 +1659,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1618,17 +1683,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1640,10 +1707,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1668,7 +1734,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif
index 70b6b30a1..c0d25e497 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif
@@ -761,10 +761,13 @@
           "rules": [
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -776,20 +779,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -804,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -832,17 +839,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -857,17 +866,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -879,17 +890,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -901,17 +914,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -923,17 +938,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -945,17 +962,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -967,17 +986,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -989,17 +1010,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1017,17 +1040,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1039,17 +1064,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1061,17 +1088,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1083,20 +1112,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1108,20 +1139,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1139,17 +1172,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1164,20 +1199,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1192,20 +1229,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1223,20 +1262,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1251,20 +1292,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1282,20 +1325,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1307,20 +1352,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1335,20 +1382,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1369,20 +1418,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1400,20 +1451,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1425,20 +1478,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1456,20 +1511,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1481,20 +1538,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1509,20 +1568,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1540,17 +1601,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1571,17 +1634,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1593,17 +1658,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1615,10 +1682,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1643,7 +1709,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif
index c60f2fb69..f80f85b9c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif
@@ -783,10 +783,13 @@
           "rules": [
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -798,20 +801,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -826,20 +831,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -854,17 +861,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -879,17 +888,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -901,17 +912,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -923,17 +936,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -945,17 +960,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -967,17 +984,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -989,17 +1008,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1011,17 +1032,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1039,17 +1062,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1061,17 +1086,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1083,17 +1110,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1105,20 +1134,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1130,20 +1161,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1161,17 +1194,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1186,20 +1221,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1214,20 +1251,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1245,20 +1284,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1273,20 +1314,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1304,20 +1347,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1329,20 +1374,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1357,20 +1404,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1391,20 +1440,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1422,20 +1473,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1447,20 +1500,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1478,20 +1533,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1503,20 +1560,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1531,20 +1590,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1562,17 +1623,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1593,17 +1656,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1615,17 +1680,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1637,10 +1704,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1665,7 +1731,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif
index d2eb7b22d..27a0be62c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif
@@ -783,10 +783,13 @@
           "rules": [
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -798,20 +801,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -826,20 +831,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -854,17 +861,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -879,17 +888,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -901,17 +912,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -923,17 +936,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -945,17 +960,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -967,17 +984,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -989,17 +1008,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1011,17 +1032,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1039,17 +1062,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1061,17 +1086,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1083,17 +1110,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1105,20 +1134,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1130,20 +1161,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1161,17 +1194,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1186,20 +1221,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1214,20 +1251,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1245,20 +1284,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1273,20 +1314,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1304,20 +1347,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1329,20 +1374,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1357,20 +1404,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1391,20 +1440,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1422,20 +1473,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1447,20 +1500,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1478,20 +1533,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1503,20 +1560,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1531,20 +1590,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1562,17 +1623,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1593,17 +1656,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1615,17 +1680,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1637,10 +1704,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1665,7 +1731,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif
index fbe4213d4..d062bfb89 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif
@@ -789,10 +789,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -804,20 +807,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -832,20 +837,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -863,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -891,17 +900,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -916,17 +927,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -938,17 +951,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -960,17 +975,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -982,17 +999,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1004,17 +1023,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1026,17 +1047,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1048,17 +1071,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1076,17 +1101,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1098,17 +1125,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1120,17 +1149,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1142,20 +1173,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1173,17 +1206,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1198,20 +1233,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1226,20 +1263,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1257,20 +1296,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1288,20 +1329,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1313,20 +1356,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1341,20 +1386,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1375,20 +1422,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1406,20 +1455,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1431,20 +1482,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1456,20 +1509,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1484,20 +1539,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1509,20 +1566,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1537,20 +1596,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1568,17 +1629,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1599,17 +1662,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1621,17 +1686,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1643,10 +1710,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1671,7 +1737,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif
index 9c26e0574..bfb9813c5 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif
@@ -789,10 +789,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -804,20 +807,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -832,20 +837,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -863,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -891,17 +900,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -916,17 +927,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -938,17 +951,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -960,17 +975,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -982,17 +999,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1004,17 +1023,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1026,17 +1047,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1048,17 +1071,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1076,17 +1101,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1098,17 +1125,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1120,17 +1149,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1142,20 +1173,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1173,17 +1206,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1198,20 +1233,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1226,20 +1263,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1257,20 +1296,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1288,20 +1329,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1313,20 +1356,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1341,20 +1386,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1375,20 +1422,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1406,20 +1455,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1431,20 +1482,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1456,20 +1509,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1484,20 +1539,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1509,20 +1566,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1537,20 +1596,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1568,17 +1629,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1599,17 +1662,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1621,17 +1686,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1643,10 +1710,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1671,7 +1737,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif
index c795810c2..24cc42147 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif
@@ -548,10 +548,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -563,20 +566,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -591,20 +596,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -622,20 +629,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -650,17 +659,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -675,17 +686,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -697,17 +710,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -719,17 +734,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -741,17 +758,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -763,17 +782,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -785,17 +806,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -807,17 +830,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -835,17 +860,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -857,17 +884,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -879,17 +908,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -904,20 +935,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -935,20 +968,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -960,20 +995,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -994,20 +1031,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1019,20 +1058,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1047,20 +1088,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1072,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1100,20 +1145,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1131,10 +1178,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1179,7 +1225,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif
index 819864167..422cc36ba 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif
@@ -793,10 +793,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -808,20 +811,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -833,20 +838,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -861,20 +868,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -892,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -920,20 +931,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -948,20 +961,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -982,20 +997,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1013,20 +1030,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1038,20 +1057,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1069,20 +1090,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1094,20 +1117,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1122,20 +1147,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1156,17 +1183,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1178,17 +1207,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1200,17 +1231,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1225,17 +1258,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1250,17 +1285,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1272,17 +1309,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1294,17 +1333,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1316,17 +1357,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1338,17 +1381,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1360,17 +1405,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1382,17 +1429,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1410,17 +1459,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1432,17 +1483,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1454,17 +1507,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1482,17 +1537,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1507,20 +1564,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1538,20 +1597,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1563,20 +1624,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1588,20 +1651,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1616,20 +1681,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1647,10 +1714,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1675,7 +1741,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif
index ed35008ef..d964961a0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif
@@ -785,10 +785,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -800,20 +803,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -859,17 +866,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -884,17 +893,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -906,17 +917,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -928,17 +941,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -950,17 +965,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -972,17 +989,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -994,17 +1013,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1016,17 +1037,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1044,17 +1067,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1066,17 +1091,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1088,17 +1115,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1110,20 +1139,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1141,17 +1172,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1166,20 +1199,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1194,20 +1229,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1225,20 +1262,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1253,20 +1292,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1284,20 +1325,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1309,20 +1352,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1337,20 +1382,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1371,20 +1418,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1402,20 +1451,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1427,20 +1478,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1452,20 +1505,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1480,20 +1535,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1505,20 +1562,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1564,17 +1625,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1595,17 +1658,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1617,17 +1682,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1639,10 +1706,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1667,7 +1733,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif
index 2655b2e5d..b4bfdd928 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif
@@ -770,10 +770,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -785,20 +788,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -810,20 +815,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -838,20 +845,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -869,20 +878,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -897,20 +908,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -925,20 +938,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -959,20 +974,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -990,20 +1007,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1015,20 +1034,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1046,20 +1067,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1071,20 +1094,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1099,20 +1124,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1133,17 +1160,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1155,17 +1184,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1177,17 +1208,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1202,17 +1235,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1227,17 +1262,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1249,17 +1286,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1271,17 +1310,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1293,17 +1334,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1315,17 +1358,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1337,17 +1382,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1359,17 +1406,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1387,17 +1436,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1409,17 +1460,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1431,17 +1484,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1456,20 +1511,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1487,20 +1544,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1512,20 +1571,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1537,20 +1598,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1565,20 +1628,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1596,10 +1661,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1644,7 +1708,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif
index 2cb1a3d62..74c363ff2 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif
@@ -786,10 +786,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -801,20 +804,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -832,20 +837,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -860,17 +867,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -885,17 +894,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -907,17 +918,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -929,17 +942,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -951,17 +966,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -973,17 +990,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -995,17 +1014,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1017,17 +1038,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1045,17 +1068,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1067,17 +1092,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1089,17 +1116,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1111,20 +1140,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1142,17 +1173,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1167,20 +1200,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1195,20 +1230,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1226,20 +1263,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1254,20 +1293,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1285,20 +1326,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1310,20 +1353,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1338,20 +1383,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1372,20 +1419,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1403,20 +1452,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1428,20 +1479,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1453,20 +1506,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1481,20 +1536,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1506,20 +1563,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1534,20 +1593,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1565,17 +1626,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1596,17 +1659,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1618,17 +1683,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1640,10 +1707,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1668,7 +1734,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif
index 671bb1a69..ced2de24f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif
@@ -786,10 +786,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -801,20 +804,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -832,20 +837,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -860,17 +867,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -885,17 +894,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -907,17 +918,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -929,17 +942,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -951,17 +966,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -973,17 +990,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -995,17 +1014,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1017,17 +1038,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1045,17 +1068,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1067,17 +1092,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1089,17 +1116,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1111,20 +1140,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1142,17 +1173,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1167,20 +1200,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1195,20 +1230,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1226,20 +1263,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1254,20 +1293,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1285,20 +1326,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1310,20 +1353,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1338,20 +1383,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1372,20 +1419,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1403,20 +1452,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1428,20 +1479,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1453,20 +1506,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1481,20 +1536,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1506,20 +1563,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1534,20 +1593,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1565,17 +1626,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1596,17 +1659,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1618,17 +1683,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1640,10 +1707,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1668,7 +1734,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif
index 21276b14c..7f165a3e4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif
@@ -546,10 +546,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -561,20 +564,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -592,20 +597,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -620,17 +627,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -645,17 +654,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -667,17 +678,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -689,17 +702,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -711,17 +726,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -733,17 +750,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -755,17 +774,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -777,17 +798,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -805,17 +828,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -827,17 +852,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -849,17 +876,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -874,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -902,20 +933,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -933,20 +966,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -958,20 +993,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -992,20 +1029,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1017,20 +1056,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1045,20 +1086,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1070,20 +1113,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1098,20 +1143,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1129,10 +1176,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1177,7 +1223,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif
index 63cff34d6..f4ecb2572 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif
@@ -785,10 +785,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -800,20 +803,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -859,17 +866,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -884,17 +893,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -906,17 +917,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -928,17 +941,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -950,17 +965,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -972,17 +989,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -994,17 +1013,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1016,17 +1037,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1044,17 +1067,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1066,17 +1091,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1088,17 +1115,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1110,20 +1139,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1141,17 +1172,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1166,20 +1199,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1194,20 +1229,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1225,20 +1262,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1253,20 +1292,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1284,20 +1325,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1309,20 +1352,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1337,20 +1382,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1371,20 +1418,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1402,20 +1451,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1427,20 +1478,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1452,20 +1505,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1480,20 +1535,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1505,20 +1562,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1564,17 +1625,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1595,17 +1658,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1617,17 +1682,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1639,10 +1706,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1667,7 +1733,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif
index 848b1e3b0..68ef9a93e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif
@@ -796,10 +796,13 @@
           "rules": [
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -817,20 +820,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -842,20 +847,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -870,20 +877,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -904,17 +913,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -926,17 +937,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -948,17 +961,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -973,17 +988,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -998,17 +1015,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1020,17 +1039,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1042,17 +1063,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1064,17 +1087,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1086,17 +1111,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1108,17 +1135,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1130,17 +1159,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1158,17 +1189,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1180,17 +1213,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1202,17 +1237,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1224,20 +1261,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1249,20 +1288,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1280,17 +1321,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1305,20 +1348,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1333,20 +1378,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1364,20 +1411,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1392,20 +1441,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1423,20 +1474,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1448,20 +1501,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1476,20 +1531,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1510,20 +1567,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1541,20 +1600,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1566,20 +1627,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1591,20 +1654,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1619,20 +1684,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1650,10 +1717,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1678,7 +1744,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif
index 8df82d0c4..d86c3a995 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif
@@ -624,10 +624,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -639,20 +642,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -667,20 +672,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -695,20 +702,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -729,20 +738,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -760,20 +771,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -785,20 +798,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -816,20 +831,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -844,20 +861,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -872,17 +891,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -897,17 +918,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -919,17 +942,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -941,17 +966,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -963,17 +990,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -985,17 +1014,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1007,17 +1038,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1029,17 +1062,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1057,17 +1092,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1079,17 +1116,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1101,17 +1140,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1126,20 +1167,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1200,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1182,20 +1227,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1207,20 +1254,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1232,20 +1281,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1260,20 +1311,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1291,10 +1344,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1339,7 +1391,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif
index 80e240961..2bdc140b4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif
@@ -550,10 +550,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -565,20 +568,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -593,20 +598,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -624,20 +631,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -652,20 +661,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -680,17 +691,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -705,17 +718,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -727,17 +742,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -749,17 +766,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -771,17 +790,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -793,17 +814,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -815,17 +838,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -837,17 +862,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -865,17 +892,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -887,17 +916,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -909,17 +940,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -934,20 +967,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -965,20 +1000,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -990,20 +1027,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1024,20 +1063,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1049,20 +1090,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1074,20 +1117,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1102,20 +1147,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1133,10 +1180,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1181,7 +1227,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif
index 2657e9c08..a9363ccc4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif
@@ -790,10 +790,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -805,20 +808,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -830,20 +835,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -858,20 +865,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -889,20 +898,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -917,20 +928,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -942,20 +955,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -970,20 +985,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1004,20 +1021,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1035,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1060,20 +1081,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1091,20 +1114,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1119,20 +1144,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1153,17 +1180,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1175,17 +1204,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1197,17 +1228,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1222,17 +1255,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1247,17 +1282,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1269,17 +1306,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1291,17 +1330,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1313,17 +1354,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1335,17 +1378,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1357,17 +1402,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1379,17 +1426,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1407,17 +1456,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1429,17 +1480,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1451,17 +1504,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1479,17 +1534,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1504,20 +1561,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1535,20 +1594,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1560,20 +1621,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1585,20 +1648,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1613,20 +1678,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1644,10 +1711,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1672,7 +1738,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif
index 7b49280a7..f460a1e68 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif
@@ -788,10 +788,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -803,20 +806,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -828,20 +833,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -856,20 +863,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -887,20 +896,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -915,20 +926,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -940,20 +953,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -968,20 +983,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1002,20 +1019,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1033,20 +1052,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1058,20 +1079,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1089,20 +1112,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1123,17 +1148,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1145,17 +1172,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1167,17 +1196,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1192,17 +1223,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1217,17 +1250,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1239,17 +1274,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1261,17 +1298,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1283,17 +1322,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1305,17 +1346,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1327,17 +1370,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1349,17 +1394,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1377,17 +1424,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1399,17 +1448,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1421,17 +1472,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1449,17 +1502,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1474,20 +1529,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1505,20 +1562,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1530,20 +1589,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1558,20 +1619,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1583,20 +1646,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1611,20 +1676,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1642,10 +1709,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1670,7 +1736,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif
index 952b46338..2a95faac1 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif
@@ -624,10 +624,13 @@
           "rules": [
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -642,20 +645,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -670,20 +675,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -704,20 +711,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -735,20 +744,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -760,20 +771,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -791,20 +804,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -816,20 +831,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -844,20 +861,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -872,17 +891,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -897,17 +918,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -919,17 +942,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -941,17 +966,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -963,17 +990,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -985,17 +1014,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1007,17 +1038,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1029,17 +1062,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1057,17 +1092,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1079,17 +1116,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1101,17 +1140,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1123,20 +1164,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1151,20 +1194,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1182,20 +1227,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1207,20 +1254,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1232,20 +1281,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1260,20 +1311,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1291,10 +1344,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1339,7 +1391,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif
index 69ddf6274..f50bbe73a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif
@@ -548,10 +548,13 @@
           "rules": [
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -566,20 +569,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -591,20 +596,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -619,20 +626,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -647,17 +656,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -672,17 +683,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -694,17 +707,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -716,17 +731,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -738,17 +755,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -760,17 +779,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -782,17 +803,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -804,17 +827,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -832,17 +857,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -854,17 +881,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -876,17 +905,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -898,20 +929,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -926,20 +959,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -957,20 +992,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -982,20 +1019,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1016,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1047,20 +1088,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1072,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1100,20 +1145,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1131,10 +1178,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1179,7 +1225,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif
index ed2e8e1e3..f4d8de87c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif
@@ -794,10 +794,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +812,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -840,20 +845,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -874,17 +881,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -896,17 +905,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -918,17 +929,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -943,17 +956,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -968,17 +983,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -990,17 +1007,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1012,17 +1031,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1034,17 +1055,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1056,17 +1079,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1078,17 +1103,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1100,17 +1127,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1128,17 +1157,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1150,17 +1181,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1172,17 +1205,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1194,20 +1229,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1225,17 +1262,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1250,20 +1289,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1278,20 +1319,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1309,20 +1352,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1337,20 +1382,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1368,20 +1415,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1393,20 +1442,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1421,20 +1472,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1455,20 +1508,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1486,20 +1541,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1511,20 +1568,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1536,20 +1595,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1564,20 +1625,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1652,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1682,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,10 +1715,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1676,7 +1742,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif
index a8fb7089c..2ab54d3e3 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif
@@ -794,10 +794,13 @@
           "rules": [
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -809,20 +812,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -837,20 +842,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -871,17 +878,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -893,17 +902,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -915,17 +926,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -940,17 +953,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -965,17 +980,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -987,17 +1004,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1009,17 +1028,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1031,17 +1052,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1053,17 +1076,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1075,17 +1100,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1097,17 +1124,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1125,17 +1154,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1147,17 +1178,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1169,17 +1202,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1191,20 +1226,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1216,20 +1253,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1247,17 +1286,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1272,20 +1313,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1300,20 +1343,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1331,20 +1376,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1359,20 +1406,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1390,20 +1439,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1415,20 +1466,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1443,20 +1496,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1477,20 +1532,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1508,20 +1565,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1533,20 +1592,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1564,20 +1625,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1652,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1682,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,10 +1715,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1676,7 +1742,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif
index 36a857b6b..ac694af16 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif
@@ -622,10 +622,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -637,20 +640,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -665,20 +670,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -693,20 +700,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -727,20 +736,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -758,20 +769,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -783,20 +796,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -814,20 +829,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -842,17 +859,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -867,17 +886,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -889,17 +910,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -911,17 +934,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -933,17 +958,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -955,17 +982,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -977,17 +1006,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -999,17 +1030,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1027,17 +1060,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1049,17 +1084,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1071,17 +1108,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1096,20 +1135,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1127,20 +1168,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1152,20 +1195,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1177,20 +1222,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1205,20 +1252,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1230,20 +1279,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1258,20 +1309,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1289,10 +1342,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1337,7 +1389,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif
index 9c85f2193..10468401e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif
@@ -548,10 +548,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -563,20 +566,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -591,20 +596,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -622,20 +629,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -650,17 +659,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -675,17 +686,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -697,17 +710,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -719,17 +734,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -741,17 +758,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -763,17 +782,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -785,17 +806,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -807,17 +830,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -835,17 +860,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -857,17 +884,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -879,17 +908,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -904,20 +935,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -935,20 +968,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -960,20 +995,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -994,20 +1031,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1019,20 +1058,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1047,20 +1088,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1072,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1100,20 +1145,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1131,10 +1178,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1179,7 +1225,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif
index f78ae0aa5..8201480c5 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif
@@ -794,10 +794,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -809,20 +812,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -840,20 +845,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -874,17 +881,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -896,17 +905,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -918,17 +929,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -943,17 +956,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -968,17 +983,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -990,17 +1007,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1012,17 +1031,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1034,17 +1055,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1056,17 +1079,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1078,17 +1103,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1100,17 +1127,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1128,17 +1157,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1150,17 +1181,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1172,17 +1205,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1194,20 +1229,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1225,17 +1262,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1250,20 +1289,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1278,20 +1319,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1309,20 +1352,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1337,20 +1382,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1368,20 +1415,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1393,20 +1442,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1421,20 +1472,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1455,20 +1508,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1486,20 +1541,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1511,20 +1568,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1536,20 +1595,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1564,20 +1625,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1589,20 +1652,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1617,20 +1682,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1648,10 +1715,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1676,7 +1742,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif
index 53a852bdd..03b323971 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif
@@ -788,10 +788,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -803,20 +806,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -828,20 +833,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -859,17 +866,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -884,20 +893,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -915,20 +926,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -943,20 +956,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -971,20 +986,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1002,20 +1019,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1027,20 +1046,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1058,20 +1079,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1092,17 +1115,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1114,17 +1139,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1136,17 +1163,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1161,17 +1190,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1186,17 +1217,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1208,17 +1241,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1230,17 +1265,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1252,17 +1289,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1274,17 +1313,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1296,17 +1337,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1318,17 +1361,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1346,17 +1391,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1368,17 +1415,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1390,17 +1439,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1415,20 +1466,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1446,20 +1499,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1471,20 +1526,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1505,20 +1562,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1530,20 +1589,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1558,20 +1619,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1583,20 +1646,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1611,20 +1676,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1642,10 +1709,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1670,7 +1736,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif
index 1efe8af75..572a4f33e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +786,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +846,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +873,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +936,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +966,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +999,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1026,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1056,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1125,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1152,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1185,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1212,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1242,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1269,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1299,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1332,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1365,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1389,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1413,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1437,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1461,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1440,17 +1491,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1462,17 +1515,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1484,17 +1539,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1509,17 +1566,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1534,17 +1593,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1556,17 +1617,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1578,17 +1641,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1600,10 +1665,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1628,7 +1692,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif
index 4dace2bce..cdbd59af4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif
@@ -790,10 +790,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -805,20 +808,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -830,20 +835,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -861,17 +868,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -886,20 +895,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -914,20 +925,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -945,20 +958,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -973,20 +988,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1004,20 +1021,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1029,20 +1048,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1057,20 +1078,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1091,20 +1114,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1122,20 +1147,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1147,20 +1174,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1178,20 +1207,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1203,20 +1234,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1231,20 +1264,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1256,20 +1291,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1284,20 +1321,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1315,17 +1354,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1346,17 +1387,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1368,17 +1411,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1390,17 +1435,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1412,17 +1459,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1434,17 +1483,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1462,17 +1513,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1484,17 +1537,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1506,17 +1561,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1531,17 +1588,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1556,17 +1615,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1578,17 +1639,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1600,17 +1663,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1622,17 +1687,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1644,10 +1711,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1672,7 +1738,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif
index 2106596f9..c6c2dd4c7 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif
@@ -766,10 +766,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -781,20 +784,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -806,20 +811,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -837,17 +844,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -862,20 +871,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -890,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -921,20 +934,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -949,20 +964,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -980,20 +997,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1005,20 +1024,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1033,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1067,20 +1090,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1098,20 +1123,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1123,20 +1150,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1154,20 +1183,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1179,20 +1210,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1207,20 +1240,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1232,20 +1267,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1260,20 +1297,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1291,17 +1330,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1322,17 +1363,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1344,17 +1387,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1366,17 +1411,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1388,17 +1435,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1410,17 +1459,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1438,17 +1489,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1460,17 +1513,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1482,17 +1537,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1507,17 +1564,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1532,17 +1591,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1554,17 +1615,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1576,17 +1639,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1598,10 +1663,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1626,7 +1690,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif
index 9ad06775e..ced8d21a8 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif
@@ -767,10 +767,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -782,20 +785,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -807,20 +812,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -838,17 +845,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -863,20 +872,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -891,20 +902,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -922,20 +935,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -950,20 +965,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -981,20 +998,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1006,20 +1025,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1034,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1068,20 +1091,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1099,20 +1124,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1124,20 +1151,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1155,20 +1184,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1180,20 +1211,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1208,20 +1241,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1233,20 +1268,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1261,20 +1298,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1292,17 +1331,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1323,17 +1364,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1345,17 +1388,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1367,17 +1412,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1389,17 +1436,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1411,17 +1460,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1439,17 +1490,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1461,17 +1514,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1483,17 +1538,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1508,17 +1565,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1533,17 +1592,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1555,17 +1616,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1577,17 +1640,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1599,10 +1664,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1627,7 +1691,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif
index f97b4d9b7..71ea0b041 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif
@@ -769,10 +769,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +787,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +814,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +847,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +874,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +904,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +937,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +967,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +1000,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1027,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1057,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1093,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1126,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1153,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1186,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1213,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1243,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1270,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1300,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1333,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1366,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1390,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1414,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1438,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1462,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1441,17 +1492,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1463,17 +1516,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1485,17 +1540,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1510,17 +1567,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1535,17 +1594,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1557,17 +1618,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1579,17 +1642,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1601,10 +1666,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1629,7 +1693,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif
index 3932661a6..37f9d23aa 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +786,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +846,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +873,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +936,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +966,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +999,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1026,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1056,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1125,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1152,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1185,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1212,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1242,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1269,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1299,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1332,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1365,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1389,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1413,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1437,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1461,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1440,17 +1491,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1462,17 +1515,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1484,17 +1539,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1509,17 +1566,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1534,17 +1593,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1556,17 +1617,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1578,17 +1641,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1600,10 +1665,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1628,7 +1692,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif
index 8cd3417e8..55fb931a0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +786,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +846,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +873,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +936,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +966,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +999,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1026,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1056,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1125,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1152,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1185,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1212,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1242,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1269,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1299,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1332,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1365,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1389,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1413,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1437,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1461,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1440,17 +1491,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1462,17 +1515,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1484,17 +1539,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1509,17 +1566,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1534,17 +1593,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1556,17 +1617,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1578,17 +1641,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1600,10 +1665,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1628,7 +1692,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif
index 2bf4e51a2..5c58272b9 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +786,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +846,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +873,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +936,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +966,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +999,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1026,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1056,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1125,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1152,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1185,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1212,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1242,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1269,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1299,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1332,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1365,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1389,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1413,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1437,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1461,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1440,17 +1491,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1462,17 +1515,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1484,17 +1539,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1509,17 +1566,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1534,17 +1593,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1556,17 +1617,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1578,17 +1641,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1600,10 +1665,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1628,7 +1692,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif
index fed7f4958..e2c05f952 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif
@@ -769,10 +769,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +787,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +814,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +847,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +874,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +904,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +937,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +967,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +1000,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1027,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1057,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1093,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1126,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1153,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1186,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1213,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1243,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1270,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1300,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1333,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1366,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1390,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1414,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1438,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1462,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1441,17 +1492,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1463,17 +1516,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1485,17 +1540,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1510,17 +1567,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1535,17 +1594,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1557,17 +1618,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1579,17 +1642,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1601,10 +1666,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1629,7 +1693,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif
index ad3165422..6a78d0a88 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +786,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +846,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +873,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +936,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +966,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +999,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1026,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1056,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1125,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1152,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1185,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1212,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1242,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1269,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1299,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1332,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1365,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1389,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1413,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1437,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1461,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1440,17 +1491,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1462,17 +1515,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1484,17 +1539,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1509,17 +1566,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1534,17 +1593,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1556,17 +1617,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1578,17 +1641,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1600,10 +1665,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1628,7 +1692,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif
index eb72b4850..d5ff61efa 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif
@@ -780,10 +780,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -795,20 +798,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -820,20 +825,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -851,17 +858,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -876,20 +885,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -904,20 +915,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -935,20 +948,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -963,20 +978,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -994,20 +1011,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1019,20 +1038,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1047,20 +1068,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1081,20 +1104,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1112,20 +1137,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1137,20 +1164,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1168,20 +1197,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1193,20 +1224,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1221,20 +1254,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1246,20 +1281,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1274,20 +1311,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1305,17 +1344,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1336,17 +1377,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1358,17 +1401,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1380,17 +1425,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1405,17 +1452,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1430,17 +1479,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1452,17 +1503,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1474,17 +1527,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1496,17 +1551,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1518,17 +1575,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1540,17 +1599,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1568,17 +1629,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1590,17 +1653,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1612,10 +1677,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             }
           ],
           "properties": {
@@ -1640,7 +1704,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif
index 62c28fec1..cd0f0024b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif
@@ -769,10 +769,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +787,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +814,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +847,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +874,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +904,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +937,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +967,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +1000,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1027,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1057,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1093,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1126,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1153,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1186,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1213,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1243,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1270,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1300,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1333,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1366,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1390,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1414,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1438,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1462,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1441,17 +1492,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1463,17 +1516,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1485,17 +1540,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1510,17 +1567,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1535,17 +1594,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1557,17 +1618,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1579,17 +1642,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1601,10 +1666,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1629,7 +1693,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif
index d8cf9c904..615a3ae24 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +786,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +846,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +873,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +936,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +966,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +999,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1026,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1056,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1125,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1152,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1185,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1212,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1242,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1269,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1299,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1332,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1365,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1389,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1413,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1437,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1461,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1440,17 +1491,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1462,17 +1515,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1484,17 +1539,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1509,17 +1566,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1534,17 +1593,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1556,17 +1617,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1578,17 +1641,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1600,10 +1665,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1628,7 +1692,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif
index 00a2a57b7..eb99839b5 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif
@@ -767,10 +767,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -782,20 +785,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -807,20 +812,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -838,17 +845,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -863,20 +872,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -891,20 +902,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -922,20 +935,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -950,20 +965,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -981,20 +998,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1006,20 +1025,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1034,20 +1055,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1068,20 +1091,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1099,20 +1124,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1124,20 +1151,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1155,20 +1184,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1180,20 +1211,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1208,20 +1241,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1233,20 +1268,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1261,20 +1298,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1292,17 +1331,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1323,17 +1364,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1345,17 +1388,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1367,17 +1412,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1389,17 +1436,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1411,17 +1460,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1439,17 +1490,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1461,17 +1514,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1483,17 +1538,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1508,17 +1565,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1533,17 +1592,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1555,17 +1616,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1577,17 +1640,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1599,10 +1664,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1627,7 +1691,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif
index 55e6791e6..c80e665bb 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif
@@ -769,10 +769,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +787,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +814,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +847,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +874,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +904,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +937,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +967,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +1000,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1027,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1057,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1093,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1126,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1153,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1186,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1213,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1243,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1270,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1300,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1333,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1366,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1390,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1414,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1438,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1462,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1441,17 +1492,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1463,17 +1516,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1485,17 +1540,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1510,17 +1567,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1535,17 +1594,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1557,17 +1618,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1579,17 +1642,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1601,10 +1666,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1629,7 +1693,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.a.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.a.sarif
index f89139875..ef272b59e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.a.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.a.sarif
@@ -50,7 +50,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif
index 578b66b28..5f491d2c5 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +786,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +846,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +873,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +936,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +966,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +999,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1026,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1056,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1125,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1152,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1185,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1212,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1242,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1269,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1299,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1332,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1365,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1389,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1413,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1437,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1461,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1440,17 +1491,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1462,17 +1515,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1484,17 +1539,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1509,17 +1566,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1534,17 +1593,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1556,17 +1617,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1578,17 +1641,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1600,10 +1665,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1628,7 +1692,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif
index 6e851b19b..16c236d2c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif
@@ -769,10 +769,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -784,20 +787,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -809,20 +814,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -840,17 +847,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -865,20 +874,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -893,20 +904,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -924,20 +937,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -952,20 +967,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -983,20 +1000,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1008,20 +1027,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1036,20 +1057,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1070,20 +1093,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1101,20 +1126,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1126,20 +1153,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1157,20 +1186,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1182,20 +1213,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1210,20 +1243,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1235,20 +1270,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1263,20 +1300,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1294,17 +1333,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1325,17 +1366,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1347,17 +1390,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1369,17 +1414,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1391,17 +1438,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1413,17 +1462,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1441,17 +1492,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1463,17 +1516,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1485,17 +1540,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1510,17 +1567,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1535,17 +1594,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1557,17 +1618,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1579,17 +1642,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1601,10 +1666,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             }
           ],
           "properties": {
@@ -1629,7 +1693,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif
index 5b0b10f0a..bf1a95853 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif
@@ -783,10 +783,13 @@
           "rules": [
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -798,20 +801,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -826,20 +831,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -854,17 +861,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -879,17 +888,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -901,17 +912,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -923,17 +936,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -945,17 +960,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -967,17 +984,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -989,17 +1008,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1011,17 +1032,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1039,17 +1062,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1061,17 +1086,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1083,17 +1110,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -1105,20 +1134,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -1130,20 +1161,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -1161,17 +1194,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -1186,20 +1221,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -1214,20 +1251,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -1245,20 +1284,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -1273,20 +1314,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1304,20 +1347,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1329,20 +1374,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1357,20 +1404,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1391,20 +1440,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1422,20 +1473,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1447,20 +1500,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1478,20 +1533,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1503,20 +1560,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1531,20 +1590,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1562,17 +1623,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1593,17 +1656,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1615,17 +1680,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1637,10 +1704,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             }
           ],
           "properties": {
@@ -1665,7 +1731,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif
index 1d40f5b78..0c4a9e366 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif
@@ -765,10 +765,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -780,20 +783,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -805,20 +810,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -836,17 +843,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -861,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -889,20 +900,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -920,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -948,20 +963,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -979,20 +996,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1004,20 +1023,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1032,20 +1053,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1066,20 +1089,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1097,20 +1122,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1122,20 +1149,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1153,20 +1182,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1178,20 +1209,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1206,20 +1239,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1231,20 +1266,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1259,20 +1296,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1290,17 +1329,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1321,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1343,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1365,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1387,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1409,17 +1458,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1431,17 +1482,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1453,17 +1506,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1478,17 +1533,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1503,17 +1560,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1525,17 +1584,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1547,17 +1608,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1569,17 +1632,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1597,10 +1662,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1625,7 +1689,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif
index e9da98295..1e92efe4e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif
@@ -786,10 +786,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -801,20 +804,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -826,20 +831,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -857,17 +864,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -882,20 +891,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -910,20 +921,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -941,20 +954,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -969,20 +984,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1000,20 +1017,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1025,20 +1044,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1053,20 +1074,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1087,20 +1110,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1118,20 +1143,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1143,20 +1170,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1174,20 +1203,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1199,20 +1230,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1227,20 +1260,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1252,20 +1287,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1280,20 +1317,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1311,17 +1350,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1342,17 +1383,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1364,17 +1407,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1386,17 +1431,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1408,17 +1455,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1430,17 +1479,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1455,17 +1506,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1480,17 +1533,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1502,17 +1557,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1524,17 +1581,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1546,17 +1605,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1568,17 +1629,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1590,17 +1653,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1612,17 +1677,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1640,10 +1707,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1668,7 +1734,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif
index a1e549e32..98d22b0ab 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif
@@ -763,10 +763,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -778,20 +781,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -803,20 +808,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -834,17 +841,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -859,20 +868,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -887,20 +898,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -918,20 +931,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -946,20 +961,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -977,20 +994,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1002,20 +1021,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1030,20 +1051,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1064,20 +1087,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1095,20 +1120,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1120,20 +1147,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1151,20 +1180,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1176,20 +1207,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1204,20 +1237,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1229,20 +1264,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1257,20 +1294,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1288,17 +1327,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1319,17 +1360,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1341,17 +1384,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1363,17 +1408,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1385,17 +1432,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1407,17 +1456,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1429,17 +1480,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1451,17 +1504,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1476,17 +1531,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1501,17 +1558,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1523,17 +1582,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1545,17 +1606,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1567,17 +1630,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1595,10 +1660,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1623,7 +1687,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif
index ab9c258f9..bff84f6ea 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif
@@ -764,10 +764,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -779,20 +782,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -804,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -835,17 +842,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -860,20 +869,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -888,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -919,20 +932,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -947,20 +962,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -978,20 +995,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1003,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1031,20 +1052,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1065,20 +1088,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1096,20 +1121,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1121,20 +1148,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1152,20 +1181,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1177,20 +1208,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1205,20 +1238,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1230,20 +1265,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1258,20 +1295,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1289,17 +1328,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1320,17 +1361,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1342,17 +1385,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1364,17 +1409,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1386,17 +1433,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1408,17 +1457,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1430,17 +1481,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1452,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1477,17 +1532,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1502,17 +1559,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1524,17 +1583,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1546,17 +1607,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1568,17 +1631,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1596,10 +1661,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1624,7 +1688,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif
index 81fd266b3..e5b18e2dc 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif
@@ -766,10 +766,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -781,20 +784,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -806,20 +811,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -837,17 +844,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -862,20 +871,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -890,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -921,20 +934,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -949,20 +964,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -980,20 +997,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1005,20 +1024,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1033,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1067,20 +1090,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1098,20 +1123,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1123,20 +1150,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1154,20 +1183,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1179,20 +1210,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1207,20 +1240,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1232,20 +1267,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1260,20 +1297,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1291,17 +1330,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1322,17 +1363,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1344,17 +1387,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1366,17 +1411,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1388,17 +1435,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1410,17 +1459,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1432,17 +1483,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1454,17 +1507,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1479,17 +1534,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1504,17 +1561,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1526,17 +1585,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1548,17 +1609,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1570,17 +1633,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1598,10 +1663,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1626,7 +1690,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif
index 3ff12dfa9..b9025e7e8 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif
@@ -804,10 +804,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -819,20 +822,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -844,20 +849,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -875,17 +882,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -900,20 +909,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -928,20 +939,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -959,20 +972,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -987,20 +1002,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1018,20 +1035,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1043,20 +1062,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1071,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1105,20 +1128,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1136,20 +1161,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1161,20 +1188,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1192,20 +1221,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1217,20 +1248,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1245,20 +1278,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1270,20 +1305,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1298,20 +1335,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1329,17 +1368,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1360,17 +1401,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1382,17 +1425,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1404,17 +1449,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1429,17 +1476,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1454,17 +1503,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1476,17 +1527,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1498,17 +1551,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1520,17 +1575,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1542,17 +1599,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1564,17 +1623,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1586,17 +1647,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1614,17 +1677,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1636,17 +1701,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1658,10 +1725,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             }
           ],
           "properties": {
@@ -1686,7 +1752,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif
index 11b0ddfd4..dc0daf762 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif
@@ -791,10 +791,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -806,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -831,20 +836,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -862,17 +869,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -887,20 +896,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -915,20 +926,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -946,20 +959,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -974,20 +989,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1005,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1030,20 +1049,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1058,20 +1079,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1092,20 +1115,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1123,20 +1148,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1148,20 +1175,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1179,20 +1208,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1204,20 +1235,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1232,20 +1265,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1257,20 +1292,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1285,20 +1322,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1316,17 +1355,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1347,17 +1388,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1369,17 +1412,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1391,17 +1436,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1413,17 +1460,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1435,17 +1484,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1457,17 +1508,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1479,17 +1532,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1504,17 +1559,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1529,17 +1586,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1551,17 +1610,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1573,17 +1634,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1595,17 +1658,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1617,17 +1682,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1645,10 +1712,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1673,7 +1739,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif
index 936dfd938..21d092754 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif
@@ -786,10 +786,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -801,20 +804,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -826,20 +831,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -857,17 +864,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -882,20 +891,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -910,20 +921,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -941,20 +954,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -969,20 +984,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1000,20 +1017,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1025,20 +1044,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1053,20 +1074,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1087,20 +1110,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1118,20 +1143,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1143,20 +1170,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1174,20 +1203,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1199,20 +1230,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1227,20 +1260,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1252,20 +1287,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1280,20 +1317,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1311,17 +1350,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1342,17 +1383,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1364,17 +1407,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1386,17 +1431,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1408,17 +1455,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1430,17 +1479,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1455,17 +1506,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1480,17 +1533,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1502,17 +1557,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1524,17 +1581,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1546,17 +1605,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1568,17 +1629,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1590,17 +1653,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1612,17 +1677,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1640,10 +1707,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1668,7 +1734,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif
index 18a6fcf49..459c7a484 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif
@@ -787,10 +787,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -802,20 +805,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -827,20 +832,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -858,17 +865,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -883,20 +892,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -911,20 +922,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -942,20 +955,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -970,20 +985,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1001,20 +1018,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1026,20 +1045,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1054,20 +1075,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1088,20 +1111,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1119,20 +1144,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1144,20 +1171,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1175,20 +1204,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1200,20 +1231,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1228,20 +1261,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1253,20 +1288,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1281,20 +1318,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1312,17 +1351,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1343,17 +1384,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1365,17 +1408,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1387,17 +1432,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1409,17 +1456,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1431,17 +1480,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1456,17 +1507,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1481,17 +1534,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1503,17 +1558,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1525,17 +1582,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1547,17 +1606,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1569,17 +1630,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1591,17 +1654,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1613,17 +1678,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1641,10 +1708,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1669,7 +1735,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif
index c5fff30d4..71d6188ac 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif
@@ -785,10 +785,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -800,20 +803,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -825,20 +830,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -856,17 +863,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -881,20 +890,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -909,20 +920,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -940,20 +953,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -968,20 +983,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -999,20 +1016,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1024,20 +1043,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1052,20 +1073,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1086,20 +1109,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1117,20 +1142,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1142,20 +1169,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1173,20 +1202,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1198,20 +1229,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1226,20 +1259,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1251,20 +1286,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1279,20 +1316,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1310,17 +1349,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1341,17 +1382,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1363,17 +1406,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1385,17 +1430,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1407,17 +1454,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1429,17 +1478,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1454,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1479,17 +1532,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1501,17 +1556,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1523,17 +1580,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1545,17 +1604,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1567,17 +1628,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1589,17 +1652,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1611,17 +1676,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1639,10 +1706,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1667,7 +1733,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif
index 8513c526d..a1af4303f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif
@@ -768,10 +768,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -783,20 +786,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -808,20 +813,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -839,17 +846,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -864,20 +873,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -892,20 +903,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -923,20 +936,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -951,20 +966,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -982,20 +999,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1007,20 +1026,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1035,20 +1056,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1069,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1100,20 +1125,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1125,20 +1152,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1156,20 +1185,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1181,20 +1212,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1209,20 +1242,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1234,20 +1269,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1262,20 +1299,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1293,17 +1332,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1324,17 +1365,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1346,17 +1389,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1368,17 +1413,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1390,17 +1437,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1412,17 +1461,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1434,17 +1485,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1456,17 +1509,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1481,17 +1536,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1506,17 +1563,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1528,17 +1587,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1550,17 +1611,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1572,17 +1635,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1600,10 +1665,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1628,7 +1692,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif
index 2592d3ea2..3c828b129 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif
@@ -787,10 +787,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -802,20 +805,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -827,20 +832,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -858,17 +865,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -883,20 +892,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -911,20 +922,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -942,20 +955,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -970,20 +985,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1001,20 +1018,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1026,20 +1045,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1054,20 +1075,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1088,20 +1111,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1119,20 +1144,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1144,20 +1171,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1175,20 +1204,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1200,20 +1231,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1228,20 +1261,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1253,20 +1288,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1281,20 +1318,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1312,17 +1351,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1343,17 +1384,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1365,17 +1408,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1387,17 +1432,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1409,17 +1456,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1431,17 +1480,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1456,17 +1507,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1481,17 +1534,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1503,17 +1558,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1525,17 +1582,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1547,17 +1606,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1569,17 +1630,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1591,17 +1654,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1613,17 +1678,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1641,10 +1708,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1669,7 +1735,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif
index 1b13fc73c..aa06601e2 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif
@@ -766,10 +766,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -781,20 +784,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -806,20 +811,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -837,17 +844,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -862,20 +871,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -890,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -921,20 +934,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -949,20 +964,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -980,20 +997,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1005,20 +1024,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1033,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1067,20 +1090,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1098,20 +1123,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1123,20 +1150,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1154,20 +1183,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1179,20 +1210,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1207,20 +1240,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1232,20 +1267,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1260,20 +1297,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1291,17 +1330,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1322,17 +1363,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1344,17 +1387,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1366,17 +1411,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1388,17 +1435,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1410,17 +1459,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1432,17 +1483,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1454,17 +1507,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1479,17 +1534,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1504,17 +1561,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1526,17 +1585,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1548,17 +1609,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1570,17 +1633,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1598,10 +1663,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1626,7 +1690,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif
index aed6007fa..ec7218504 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif
@@ -766,10 +766,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -781,20 +784,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -806,20 +811,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -837,17 +844,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -862,20 +871,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -890,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -921,20 +934,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -949,20 +964,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -980,20 +997,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1005,20 +1024,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1033,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1067,20 +1090,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1098,20 +1123,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1123,20 +1150,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1154,20 +1183,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1179,20 +1210,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1207,20 +1240,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1232,20 +1267,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1260,20 +1297,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1291,17 +1330,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1322,17 +1363,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1344,17 +1387,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1366,17 +1411,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1388,17 +1435,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1410,17 +1459,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1432,17 +1483,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1454,17 +1507,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1479,17 +1534,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1504,17 +1561,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1526,17 +1585,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1548,17 +1609,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1570,17 +1633,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1598,10 +1663,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1626,7 +1690,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif
index d06cc2060..00169bfdc 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif
@@ -765,10 +765,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -780,20 +783,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -805,20 +810,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -836,17 +843,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -861,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -889,20 +900,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -920,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -948,20 +963,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -979,20 +996,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1004,20 +1023,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1032,20 +1053,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1066,20 +1089,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1097,20 +1122,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1122,20 +1149,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1153,20 +1182,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1178,20 +1209,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1206,20 +1239,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1231,20 +1266,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1259,20 +1296,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1290,17 +1329,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1321,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1343,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1365,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1387,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1409,17 +1458,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1431,17 +1482,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1453,17 +1506,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1478,17 +1533,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1503,17 +1560,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1525,17 +1584,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1547,17 +1608,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1569,17 +1632,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1597,10 +1662,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1625,7 +1689,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif
index 572620b5d..76e30e0e0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif
@@ -765,10 +765,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -780,20 +783,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -805,20 +810,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -836,17 +843,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -861,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -889,20 +900,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -920,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -948,20 +963,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -979,20 +996,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1004,20 +1023,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1032,20 +1053,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1066,20 +1089,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1097,20 +1122,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1122,20 +1149,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1153,20 +1182,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1178,20 +1209,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1206,20 +1239,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1231,20 +1266,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1259,20 +1296,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1290,17 +1329,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1321,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1343,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1365,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1387,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1409,17 +1458,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1431,17 +1482,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1453,17 +1506,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1478,17 +1533,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1503,17 +1560,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1525,17 +1584,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1547,17 +1608,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1569,17 +1632,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1597,10 +1662,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1625,7 +1689,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif
index 18041a37d..26a2ec96b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif
@@ -765,10 +765,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -780,20 +783,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -805,20 +810,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -836,17 +843,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -861,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -889,20 +900,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -920,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -948,20 +963,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -979,20 +996,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1004,20 +1023,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1032,20 +1053,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1066,20 +1089,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1097,20 +1122,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1122,20 +1149,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1153,20 +1182,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1178,20 +1209,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1206,20 +1239,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1231,20 +1266,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1259,20 +1296,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1290,17 +1329,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1321,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1343,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1365,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1387,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1409,17 +1458,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1431,17 +1482,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1453,17 +1506,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1478,17 +1533,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1503,17 +1560,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1525,17 +1584,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1547,17 +1608,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1569,17 +1632,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1597,10 +1662,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1625,7 +1689,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif
index a77beb456..db5a7a2ee 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif
@@ -766,10 +766,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -781,20 +784,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -806,20 +811,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -837,17 +844,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -862,20 +871,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -890,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -921,20 +934,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -949,20 +964,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -980,20 +997,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1005,20 +1024,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1033,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1067,20 +1090,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1098,20 +1123,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1123,20 +1150,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1154,20 +1183,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1179,20 +1210,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1207,20 +1240,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1232,20 +1267,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1260,20 +1297,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1291,17 +1330,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1322,17 +1363,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1344,17 +1387,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1366,17 +1411,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1388,17 +1435,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1410,17 +1459,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1432,17 +1483,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1454,17 +1507,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1479,17 +1534,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1504,17 +1561,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1526,17 +1585,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1548,17 +1609,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1570,17 +1633,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1598,10 +1663,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1626,7 +1690,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif
index 2f262ac72..70aa2d308 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif
@@ -765,10 +765,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -780,20 +783,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -805,20 +810,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -836,17 +843,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -861,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -889,20 +900,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -920,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -948,20 +963,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -979,20 +996,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1004,20 +1023,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1032,20 +1053,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1066,20 +1089,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1097,20 +1122,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1122,20 +1149,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1153,20 +1182,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1178,20 +1209,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1206,20 +1239,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1231,20 +1266,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1259,20 +1296,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1290,17 +1329,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1321,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1343,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1365,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1387,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1409,17 +1458,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1431,17 +1482,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1453,17 +1506,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1478,17 +1533,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1503,17 +1560,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1525,17 +1584,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1547,17 +1608,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1569,17 +1632,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1597,10 +1662,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1625,7 +1689,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif
index f85e732f4..a352562a4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif
@@ -804,10 +804,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -819,20 +822,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -844,20 +849,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -875,17 +882,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -900,20 +909,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -928,20 +939,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -959,20 +972,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -987,20 +1002,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1018,20 +1035,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1043,20 +1062,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1071,20 +1092,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1105,20 +1128,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1136,20 +1161,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1161,20 +1188,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1192,20 +1221,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1217,20 +1248,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1245,20 +1278,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1270,20 +1305,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1298,20 +1335,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1329,17 +1368,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1360,17 +1401,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1382,17 +1425,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1404,17 +1449,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1429,17 +1476,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1454,17 +1503,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1476,17 +1527,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1498,17 +1551,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1520,17 +1575,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1542,17 +1599,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1564,17 +1623,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1586,17 +1647,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1614,17 +1677,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1636,17 +1701,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1658,10 +1725,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             }
           ],
           "properties": {
@@ -1686,7 +1752,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif
index ad4101d3d..cafef0877 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif
@@ -764,10 +764,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -779,20 +782,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -804,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -835,17 +842,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -860,20 +869,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -888,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -919,20 +932,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -947,20 +962,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -978,20 +995,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1003,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1031,20 +1052,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1065,20 +1088,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1096,20 +1121,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1121,20 +1148,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1152,20 +1181,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1177,20 +1208,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1205,20 +1238,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1230,20 +1265,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1258,20 +1295,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1289,17 +1328,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1320,17 +1361,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1342,17 +1385,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1364,17 +1409,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1386,17 +1433,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1408,17 +1457,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1433,17 +1484,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1458,17 +1511,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1480,17 +1535,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1502,17 +1559,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1524,17 +1583,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1546,17 +1607,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1568,17 +1631,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1596,10 +1661,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1624,7 +1688,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif
index 283ccc4c2..1b735753c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif
@@ -780,10 +780,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -795,20 +798,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -820,20 +825,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -851,17 +858,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -876,20 +885,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -904,20 +915,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -935,20 +948,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -963,20 +978,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -994,20 +1011,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1019,20 +1038,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1047,20 +1068,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1081,20 +1104,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1112,20 +1137,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1137,20 +1164,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1168,20 +1197,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1193,20 +1224,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1221,20 +1254,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1246,20 +1281,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1274,20 +1311,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1305,17 +1344,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1336,17 +1377,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1358,17 +1401,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1380,17 +1425,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1405,17 +1452,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1430,17 +1479,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1452,17 +1503,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1474,17 +1527,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1496,17 +1551,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1518,17 +1575,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1540,17 +1599,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1568,17 +1629,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1590,17 +1653,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1612,10 +1677,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             }
           ],
           "properties": {
@@ -1640,7 +1704,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif
index 336295499..73b08fdae 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif
@@ -546,10 +546,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -561,20 +564,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -589,20 +594,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -620,20 +627,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -648,17 +657,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -673,17 +684,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -695,17 +708,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -717,17 +732,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -739,17 +756,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -761,17 +780,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -783,17 +804,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -805,17 +828,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -833,17 +858,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -855,17 +882,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -877,17 +906,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -902,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -933,20 +966,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -958,20 +993,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -992,20 +1029,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1017,20 +1056,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1045,20 +1086,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1070,20 +1113,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1098,20 +1143,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1129,10 +1176,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             }
           ],
           "properties": {
@@ -1177,7 +1223,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif
index 2262b817b..9d2d81f2c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif
@@ -766,10 +766,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -781,20 +784,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -806,20 +811,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -837,17 +844,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -862,20 +871,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -890,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -921,20 +934,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -949,20 +964,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -980,20 +997,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1005,20 +1024,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1033,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1067,20 +1090,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1098,20 +1123,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1123,20 +1150,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1154,20 +1183,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1179,20 +1210,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1207,20 +1240,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1232,20 +1267,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1260,20 +1297,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1291,17 +1330,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1322,17 +1363,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1344,17 +1387,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1366,17 +1411,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1388,17 +1435,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1410,17 +1459,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1432,17 +1483,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1454,17 +1507,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1479,17 +1534,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1504,17 +1561,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1526,17 +1585,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1548,17 +1609,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1570,17 +1633,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1598,10 +1663,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1626,7 +1690,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif
index f1c44447a..198bdb5ab 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif
@@ -765,10 +765,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -780,20 +783,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -805,20 +810,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -836,17 +843,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -861,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -889,20 +900,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -920,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -948,20 +963,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -979,20 +996,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1004,20 +1023,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1032,20 +1053,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1066,20 +1089,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1097,20 +1122,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1122,20 +1149,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1153,20 +1182,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1178,20 +1209,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1206,20 +1239,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1231,20 +1266,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1259,20 +1296,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1290,17 +1329,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1321,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1343,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1365,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1387,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1409,17 +1458,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1431,17 +1482,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1453,17 +1506,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1478,17 +1533,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1503,17 +1560,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1525,17 +1584,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1547,17 +1608,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1569,17 +1632,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1597,10 +1662,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1625,7 +1689,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif
index 5fbb05e12..b3496781a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif
@@ -764,10 +764,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -779,20 +782,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -804,20 +809,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -835,17 +842,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -860,20 +869,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -888,20 +899,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -919,20 +932,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -947,20 +962,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -978,20 +995,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1003,20 +1022,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1031,20 +1052,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1065,20 +1088,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1096,20 +1121,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1121,20 +1148,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1152,20 +1181,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1177,20 +1208,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1205,20 +1238,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1230,20 +1265,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1258,20 +1295,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1289,17 +1328,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1320,17 +1361,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1342,17 +1385,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1364,17 +1409,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1386,17 +1433,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1408,17 +1457,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1430,17 +1481,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1452,17 +1505,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1477,17 +1532,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1502,17 +1559,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1524,17 +1583,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1546,17 +1607,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1568,17 +1631,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1596,10 +1661,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1624,7 +1688,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif
index 312145eac..931a64434 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif
@@ -786,10 +786,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -801,20 +804,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -826,20 +831,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -857,17 +864,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -882,20 +891,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -910,20 +921,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -941,20 +954,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -969,20 +984,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1000,20 +1017,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1025,20 +1044,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1053,20 +1074,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1087,20 +1110,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1118,20 +1143,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1143,20 +1170,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1174,20 +1203,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1199,20 +1230,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1227,20 +1260,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1252,20 +1287,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1280,20 +1317,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1311,17 +1350,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1342,17 +1383,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1364,17 +1407,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1386,17 +1431,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1408,17 +1455,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1430,17 +1479,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1455,17 +1506,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1480,17 +1533,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1502,17 +1557,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1524,17 +1581,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1546,17 +1605,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1568,17 +1629,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1590,17 +1653,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1612,17 +1677,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1640,10 +1707,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1668,7 +1734,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif
index 843601633..075b1de8a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif
@@ -787,10 +787,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -802,20 +805,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -827,20 +832,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -858,17 +865,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -883,20 +892,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -911,20 +922,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -942,20 +955,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -970,20 +985,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -1001,20 +1018,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1026,20 +1045,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1054,20 +1075,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1088,20 +1111,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1119,20 +1144,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1144,20 +1171,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1175,20 +1204,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1200,20 +1231,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1228,20 +1261,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1253,20 +1288,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1281,20 +1318,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1312,17 +1351,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1343,17 +1384,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1365,17 +1408,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1387,17 +1432,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1409,17 +1456,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1431,17 +1480,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1456,17 +1507,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1481,17 +1534,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1503,17 +1558,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3004",
-              "name": "GenerateRequiredSymbolFormat",
               "fullDescription": {
                 "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
+              "help": {
+                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The version of the debugging dwarf format is '{0}' for the file '{1}'"
@@ -1525,17 +1582,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3004GenerateRequiredSymbolFormat",
-              "help": {
-                "text": "This check ensures that debugging dwarf version used is 5. The dwarf version 5 contains more information and should be used. Use the compiler flags '-gdwarf-5' to enable this."
-              }
+              "shortDescription": null,
+              "name": "GenerateRequiredSymbolFormat",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1547,17 +1606,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1569,17 +1630,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1591,17 +1654,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1613,17 +1678,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1641,10 +1708,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1669,7 +1735,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif
index 87314dd22..f88dafd66 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif
@@ -766,10 +766,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -781,20 +784,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -806,20 +811,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -837,17 +844,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -862,20 +871,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -890,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -921,20 +934,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -949,20 +964,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -980,20 +997,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1005,20 +1024,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1033,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1067,20 +1090,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1098,20 +1123,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1123,20 +1150,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1154,20 +1183,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1179,20 +1210,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1207,20 +1240,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1232,20 +1267,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1260,20 +1297,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1291,17 +1330,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1322,17 +1363,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1344,17 +1387,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1366,17 +1411,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1388,17 +1435,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1410,17 +1459,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1432,17 +1483,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1454,17 +1507,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1479,17 +1534,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1504,17 +1561,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1526,17 +1585,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1548,17 +1609,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1570,17 +1633,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1598,10 +1663,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1626,7 +1690,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.a.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.a.sarif
index a5ab148a0..989407353 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.a.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.a.sarif
@@ -50,7 +50,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif
index e498ed1b9..18e78bdcc 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif
@@ -765,10 +765,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -780,20 +783,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -805,20 +810,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -836,17 +843,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -861,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -889,20 +900,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -920,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -948,20 +963,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -979,20 +996,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1004,20 +1023,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1032,20 +1053,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1066,20 +1089,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1097,20 +1122,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1122,20 +1149,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1153,20 +1182,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1178,20 +1209,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1206,20 +1239,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1231,20 +1266,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1259,20 +1296,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1290,17 +1329,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1321,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1343,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1365,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1387,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1409,17 +1458,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1431,17 +1482,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1453,17 +1506,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1478,17 +1533,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1503,17 +1560,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1525,17 +1584,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1547,17 +1608,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1569,17 +1632,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1597,10 +1662,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1625,7 +1689,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif
index c0fa83431..c931c9ad0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif
@@ -766,10 +766,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -781,20 +784,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -806,20 +811,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -837,17 +844,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -862,20 +871,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -890,20 +901,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -921,20 +934,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -949,20 +964,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -980,20 +997,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1005,20 +1024,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1033,20 +1054,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1067,20 +1090,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1098,20 +1123,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1123,20 +1150,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1154,20 +1183,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1179,20 +1210,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1207,20 +1240,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1232,20 +1267,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1260,20 +1297,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1291,17 +1330,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1322,17 +1363,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1344,17 +1387,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1366,17 +1411,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1388,17 +1435,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1410,17 +1459,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1432,17 +1483,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1454,17 +1507,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1479,17 +1534,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1504,17 +1561,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1526,17 +1585,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1548,17 +1609,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1570,17 +1633,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1598,10 +1663,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1626,7 +1690,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif
index 9c7fc0650..85b8b4821 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif
@@ -765,10 +765,13 @@
           "rules": [
             {
               "id": "BA2001",
-              "name": "LoadImageAboveFourGigabyteAddress",
               "fullDescription": {
                 "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
+              "help": {
+                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a 64-bit image with a base address that is >= 4 gigabytes, increasing the effectiveness of Address Space Layout Randomization (which helps prevent attackers from executing security-sensitive code in well-known locations)."
@@ -780,20 +783,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2001LoadImageAboveFourGigabyteAddress",
-              "help": {
-                "text": "64-bit images should have a preferred base address above the 4GB boundary to prevent triggering an Address Space Layout Randomization (ASLR) compatibility mode that decreases security. ASLR compatibility mode reduces the number of locations to which ASLR may relocate the binary, reducing its effectiveness at mitigating memory corruption vulnerabilities. To resolve this issue, either use the default preferred base address by removing any uses of /baseaddress from compiler command lines, or /BASE from linker command lines (recommended), or configure your program to start at a base address above 4GB when compiled for 64 bit platforms (by changing the constant passed to /baseaddress or /BASE). Note that if you choose to continue using a custom preferred base address, you will need to make this modification only for 64-bit builds, as base addresses above 4GB are not valid for 32-bit binaries."
-              },
+              "shortDescription": null,
+              "name": "LoadImageAboveFourGigabyteAddress",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
             },
             {
               "id": "BA2002",
-              "name": "DoNotIncorporateVulnerableDependencies",
               "fullDescription": {
                 "text": "Binaries should not take dependencies on code with known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
+              "help": {
+                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not incorporate any known vulnerable dependencies, as configured by current policy."
@@ -805,20 +810,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2002DoNotIncorporateVulnerableDependencies",
-              "help": {
-                "text": "Binaries should not take dependencies on code with known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotIncorporateVulnerableDependencies",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
             },
             {
               "id": "BA2004",
-              "name": "EnableSecureSourceCodeHashing",
               "fullDescription": {
                 "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
+              "help": {
+                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a {1} binary which was compiled with a secure (SHA-256) source code hashing algorithm."
@@ -836,17 +843,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2004EnableSecureSourceCodeHashing",
-              "help": {
-                "text": "Compilers can generate and store checksums of source files in order to provide linkage between binaries, their PDBs, and associated source code. This information is typically used to resolve source file when debugging but it can also be used to verify that a specific body of source code is, in fact, the code that was used to produce a specific set of binaries and PDBs. This validation is helpful in verifying supply chain integrity. Due to this security focus, it is important that the hashing algorithm used to produce checksums is secure. Legacy hashing algorithms, such as MD5 and SHA-1, have been demonstrated to be broken by modern hardware (that is, it is computationally feasible to force hash collisions, in which a common hash is generated from distinct files). Using a secure hashing algorithm, such as SHA-256, prevents the possibility of collision attacks, in which the checksum of a malicious file is used to produce a hash that satisfies the system that it is, in fact, the original file processed by the compiler. For managed binaries, pass '-checksumalgorithm:SHA256' on the csc.exe command-line or populate the '<ChecksumAlgorithm>' project property with 'SHA256' to enable secure source code hashing. For native binaries, pass '/ZH:SHA_256' on the cl.exe command-line to enable secure source code hashing."
-              }
+              "shortDescription": null,
+              "name": "EnableSecureSourceCodeHashing",
+              "guid": null
             },
             {
               "id": "BA2005",
-              "name": "DoNotShipVulnerableBinaries",
               "fullDescription": {
                 "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
+              "help": {
+                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is not known to be an obsolete binary that is vulnerable to one or more security problems."
@@ -861,20 +870,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2005DoNotShipVulnerableBinaries",
-              "help": {
-                "text": "Do not ship obsolete libraries for which there are known security vulnerabilities."
-              },
+              "shortDescription": null,
+              "name": "DoNotShipVulnerableBinaries",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
             },
             {
               "id": "BA2006",
-              "name": "BuildWithSecureTools",
               "fullDescription": {
                 "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
+              "help": {
+                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
+              },
               "messageStrings": {
                 "Error": {
                   "text": "'{0}' was compiled with one or more modules which were not built using minimum required tool versions (compiler version {1}). More recent toolchains contain mitigations that make it more difficult for an attacker to exploit vulnerabilities in programs they produce. To resolve this issue, compile and/or link your binary with more recent tools. If you are servicing a product where the tool chain cannot be modified (e.g. producing a hotfix for an already shipped version) ignore this warning. Modules built outside of policy: \r\n{2}"
@@ -889,20 +900,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2006BuildWithSecureTools",
-              "help": {
-                "text": "Application code should be compiled with the most up-to-date tool sets possible to take advantage of the most current compile-time security features. Among other things, these features provide address space layout randomization, help prevent arbitrary code execution, and enable code generation that can help prevent speculative execution side-channel attacks."
-              },
+              "shortDescription": null,
+              "name": "BuildWithSecureTools",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
             },
             {
               "id": "BA2007",
-              "name": "EnableCriticalCompilerWarnings",
               "fullDescription": {
                 "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
+              "help": {
+                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' was compiled at a secure warning level ({1}) and does not include any modules that disable specific warnings that are required by policy. As a result, it is less likely that memory corruption, information disclosure, double-free and other security-related vulnerabilities exist in code."
@@ -920,20 +933,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2007EnableCriticalCompilerWarnings",
-              "help": {
-                "text": "Binaries should be compiled with a warning level that enables all critical security-relevant checks. Enabling at least warning level 3 enables important static analysis in the compiler that can identify bugs with a potential to provoke memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, compile at warning level 3 or higher by supplying /W3, /W4, or /Wall to the compiler, and resolve the warnings emitted."
-              },
+              "shortDescription": null,
+              "name": "EnableCriticalCompilerWarnings",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
             },
             {
               "id": "BA2008",
-              "name": "EnableControlFlowGuard",
               "fullDescription": {
                 "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
+              "help": {
+                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the control flow guard mitigation. As a result, the operating system will force an application to close if an attacker is able to redirect execution in the component to an unexpected location."
@@ -948,20 +963,22 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2008EnableControlFlowGuard",
-              "help": {
-                "text": "Binaries should enable the compiler control guard feature (CFG) at build time to prevent attackers from redirecting execution to unexpected, unsafe locations. CFG analyzes and discovers all indirect-call instructions at compilation and link time. It also injects a check that precedes every indirect call in code that ensures the target is an expected, safe location.  If that check fails at runtime, the operating system will close the program."
-              },
+              "shortDescription": null,
+              "name": "EnableControlFlowGuard",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
             },
             {
               "id": "BA2009",
-              "name": "EnableAddressSpaceLayoutRandomization",
               "fullDescription": {
                 "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
+              "help": {
+                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is properly compiled to enable Address Space Layout Randomization, reducing an attacker's ability to exploit code in well-known locations."
@@ -979,20 +996,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2009EnableAddressSpaceLayoutRandomization",
-              "help": {
-                "text": "Binaries should linked as DYNAMICBASE to be eligible for relocation by Address Space Layout Randomization (ASLR). ASLR is an important mitigation that makes it more difficult for an attacker to exploit memory corruption vulnerabilities. Configure your tools to build with this feature enabled. For C and C++ binaries, add /DYNAMICBASE to your linker command line. For .NET applications, use a compiler shipping with Visual Studio 2008 or later."
-              },
+              "shortDescription": null,
+              "name": "EnableAddressSpaceLayoutRandomization",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
             },
             {
               "id": "BA2010",
-              "name": "DoNotMarkImportsSectionAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' does not have an imports section that is marked as executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1004,20 +1023,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2010DoNotMarkImportsSectionAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. Because the loader will always mark the imports section as writable, it is therefore important to mark this section as non-executable. To resolve this issue, ensure that your program does not mark the imports section executable. Look for uses of /SECTION or /MERGE on the linker command line, or #pragma segment in source code, which change the imports section to be executable, or which merge the \".rdata\" segment into an executable section."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkImportsSectionAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
             },
             {
               "id": "BA2011",
-              "name": "EnableStackProtection",
               "fullDescription": {
                 "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
+              "help": {
+                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled for all modules, making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities. "
@@ -1032,20 +1053,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2011EnableStackProtection",
-              "help": {
-                "text": "Binaries should be built with the stack protector buffer security feature (/GS) enabled to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. To resolve this issue, ensure that all modules compiled into the binary are compiled with the stack protector enabled by supplying /GS on the Visual C++ compiler command line."
-              },
+              "shortDescription": null,
+              "name": "EnableStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
             },
             {
               "id": "BA2012",
-              "name": "DoNotModifyStackProtectionCookie",
               "fullDescription": {
                 "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
+              "help": {
+                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly preserves the stack protecter cookie. This has the effect of enabling a significant increase in entropy provided by the operating system over that produced by the C runtime start-up code."
@@ -1066,20 +1089,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2012DoNotModifyStackProtectionCookie",
-              "help": {
-                "text": "Application code should not interfere with the stack protector. The stack protector (/GS) is a security feature of the compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. The stack protector relies on a random number, called the \"security cookie\", to detect these buffer overflows. This 'cookie' is statically linked with your binary from a Visual C++ library in the form of the symbol __security_cookie. On recent Windows versions, the loader looks for the statically linked value of this cookie, and initializes the cookie with a far better source of entropy -- the system's secure random number generator -- rather than the limited random number generator available early in the C runtime startup code. When this symbol is not the default value, the additional entropy is not injected by the operating system, reducing the effectiveness of the stack protector. To resolve this issue, ensure that your code does not reference or create a symbol named __security_cookie or __security_cookie_complement."
-              },
+              "shortDescription": null,
+              "name": "DoNotModifyStackProtectionCookie",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
             },
             {
               "id": "BA2013",
-              "name": "InitializeStackProtection",
               "fullDescription": {
                 "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
+              "help": {
+                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the buffer security feature that properly initializes the stack protecter. This has the effect of increasing the effectiveness of the feature and reducing spurious detections."
@@ -1097,20 +1122,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2013InitializeStackProtection",
-              "help": {
-                "text": "Binaries should properly initialize the stack protector (/GS) in order to increase the difficulty of exploiting stack buffer overflow memory corruption vulnerabilities. The stack protector requires access to entropy in order to be effective, which means a binary must initialize a random number generator at startup, by calling __security_init_cookie() as close to the binary's entry point as possible. Failing to do so will result in spurious buffer overflow detections on the part of the stack protector. To resolve this issue, use the default entry point provided by the C runtime, which will make this call for you, or call __security_init_cookie() manually in your custom entry point."
-              },
+              "shortDescription": null,
+              "name": "InitializeStackProtection",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
             },
             {
               "id": "BA2014",
-              "name": "DoNotDisableStackProtectionForFunctions",
               "fullDescription": {
                 "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
+              "help": {
+                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a C or C++ binary built with the stack protector buffer security feature enabled which does not disable protection for any individual functions (via __declspec(safebuffers), making it more difficult for an attacker to exploit stack buffer overflow memory corruption vulnerabilities."
@@ -1122,20 +1149,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2014DoNotDisableStackProtectionForFunctions",
-              "help": {
-                "text": "Application code should not disable stack protection for individual functions. The stack protector (/GS) is a security feature of the Windows native compiler which makes it more difficult to exploit stack buffer overflow memory corruption vulnerabilities. Disabling the stack protector, even on a function-by-function basis, can compromise the security of code. To resolve this issue, remove occurrences of __declspec(safebuffers) from your code. If the additional code inserted by the stack protector has been shown in profiling to cause a significant performance problem for your application, attempt to move stack buffer modifications out of the hot path of execution to allow the compiler to avoid inserting stack protector checks in these locations rather than disabling the stack protector altogether."
-              },
+              "shortDescription": null,
+              "name": "DoNotDisableStackProtectionForFunctions",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
             },
             {
               "id": "BA2015",
-              "name": "EnableHighEntropyVirtualAddresses",
               "fullDescription": {
                 "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
+              "help": {
+                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is high entropy ASLR compatible, reducing an attacker's ability to exploit code in well-known locations."
@@ -1153,20 +1182,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2015EnableHighEntropyVirtualAddresses",
-              "help": {
-                "text": "Binaries should be marked as high entropy Address Space Layout Randomization (ASLR) compatible. High entropy allows ASLR to be more effective in mitigating memory corruption vulnerabilities. To resolve this issue, configure your tool chain to mark the program high entropy compatible; e.g. by supplying /HIGHENTROPYVA to the C or C++ linker command line. Binaries must also be compiled as /LARGEADDRESSAWARE in order to enable high entropy ASLR."
-              },
+              "shortDescription": null,
+              "name": "EnableHighEntropyVirtualAddresses",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
             },
             {
               "id": "BA2016",
-              "name": "MarkImageAsNXCompatible",
               "fullDescription": {
                 "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
+              "help": {
+                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is marked as NX compatible, helping to prevent attackers from executing code that is injected into data segments."
@@ -1178,20 +1209,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2016MarkImageAsNXCompatible",
-              "help": {
-                "text": "Binaries should be marked as NX compatible to help prevent execution of untrusted data as code. The NXCompat bit, also known as \"Data Execution Prevention\" (DEP) or \"Execute Disable\" (XD), triggers a processor security feature that allows a program to mark a piece of memory as non-executable. This helps mitigate memory corruption vulnerabilities by preventing an attacker from supplying direct shellcode in their exploit (because the exploit comes in the form of input data to the exploited program on a data segment, rather than on an executable code segment). Ensure that your tools are configured to mark your binaries as NX compatible, e.g. by passing /NXCOMPAT to the C/C++ linker."
-              },
+              "shortDescription": null,
+              "name": "MarkImageAsNXCompatible",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
             },
             {
               "id": "BA2018",
-              "name": "EnableSafeSEH",
               "fullDescription": {
                 "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
+              "help": {
+                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is an x86 binary that enables SafeSEH, a mitigation that verifies SEH exception jump targets are defined as exception handlers in the program (and not shellcode)."
@@ -1206,20 +1239,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2018EnableSafeSEH",
-              "help": {
-                "text": "X86 binaries should enable the SafeSEH mitigation to minimize exploitable memory corruption issues. SafeSEH makes it more difficult to exploit vulnerabilities that permit overwriting SEH control blocks on the stack, by verifying that the location to which a thrown SEH exception would jump is indeed defined as an exception handler in the source program (and not shellcode). To resolve this issue, supply the /SafeSEH flag on the linker command line. Note that you will need to configure your build system to supply this flag for x86 builds only, as the /SafeSEH flag is invalid when linking for ARM and x64."
-              },
+              "shortDescription": null,
+              "name": "EnableSafeSEH",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
             },
             {
               "id": "BA2019",
-              "name": "DoNotMarkWritableSectionsAsShared",
               "fullDescription": {
                 "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
+              "help": {
+                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and writable, helping to prevent the exploitation of code vulnerabilities."
@@ -1231,20 +1266,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2019DoNotMarkWritableSectionsAsShared",
-              "help": {
-                "text": "Code or data sections should not be marked as both shared and writable. Because these sections are shared across processes, this condition might permit a process with low privilege to alter memory in a higher privilege process. If you do not actually require that a section be both writable and shared, remove one or both of these attributes (by modifying your .DEF file, the appropriate linker /section switch arguments, etc.). If you must share common data across processes (for inter-process communication (IPC) or other purposes) use CreateFileMapping with proper security attributes or an actual IPC mechanism instead (COM, named pipes, LPC, etc.)."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsShared",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
             },
             {
               "id": "BA2021",
-              "name": "DoNotMarkWritableSectionsAsExecutable",
               "fullDescription": {
                 "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
+              "help": {
+                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' contains no data or code sections marked as both shared and executable, helping to prevent the exploitation of code vulnerabilities."
@@ -1259,20 +1296,22 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2021DoNotMarkWritableSectionsAsExecutable",
-              "help": {
-                "text": "PE sections should not be marked as both writable and executable. This condition makes it easier for an attacker to exploit memory corruption vulnerabilities, as it may provide an attacker executable location(s) to inject shellcode. To resolve this issue, configure your tools to not emit memory sections that are writable and executable. For example, look for uses of /SECTION on the linker command line for C and C++ programs, or #pragma section in C and C++ source code, which mark a section with both attributes. Be sure to disable incremental linking in release builds, as this feature creates a writable and executable section named '.textbss' in order to function."
-              },
+              "shortDescription": null,
+              "name": "DoNotMarkWritableSectionsAsExecutable",
+              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
             },
             {
               "id": "BA2022",
-              "name": "SignSecurely",
               "fullDescription": {
                 "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
+              "help": {
+                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' appears to be signed with secure cryptographic algorithms. WinTrustVerify successfully validated the binary but did not attempt to validate certificate chaining or that the root certificate is trusted. The following digitial signature algorithms were detected: {1}"
@@ -1290,17 +1329,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2022SignSecurely",
-              "help": {
-                "text": "Images should be correctly signed by trusted publishers using cryptographically secure signature algorithms. This rule invokes WinTrustVerify to validate that binary hash, signing and public key algorithms are secure and, where configurable, that key sizes meet acceptable size thresholds."
-              }
+              "shortDescription": null,
+              "name": "SignSecurely",
+              "guid": null
             },
             {
               "id": "BA2024",
-              "name": "EnableSpectreMitigations",
               "fullDescription": {
                 "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
+              "help": {
+                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
+              },
               "messageStrings": {
                 "Warning": {
                   "text": "'{0}' was compiled with one or more modules that do not enable code generation mitigations for speculative execution side-channel attack (Spectre) vulnerabilities. Spectre attacks can compromise hardware-based isolation, allowing non-privileged users to retrieve potentially sensitive data from the CPU cache. To resolve the issue, provide the /Qspectre switch on the compiler command-line (or /d2guardspecload in cases where your compiler supports this switch and it is not possible to update to a toolset that supports /Qspectre). This warning should be addressed for code that operates on data that crosses a trust boundary and that can affect execution, such as parsing untrusted file inputs or processing query strings of a web request.\r\n{1}"
@@ -1321,17 +1362,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2024EnableSpectreMitigations",
-              "help": {
-                "text": "Application code should be compiled with the Spectre mitigations switch (/Qspectre) and toolsets that support it."
-              }
+              "shortDescription": null,
+              "name": "EnableSpectreMitigations",
+              "guid": null
             },
             {
               "id": "BA2025",
-              "name": "EnableShadowStack",
               "fullDescription": {
                 "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
+              "help": {
+                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' enables the Control-flow Enforcement Technology (CET) Shadow Stack mitigation."
@@ -1343,17 +1386,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2025EnableShadowStack",
-              "help": {
-                "text": "Control-flow Enforcement Technology (CET) Shadow Stack is a computer processor feature that provides capabilities to defend against return-oriented programming (ROP) based malware attacks."
-              }
+              "shortDescription": null,
+              "name": "EnableShadowStack",
+              "guid": null
             },
             {
               "id": "BA2026",
-              "name": "EnableAdditionalSdlSecurityChecks",
               "fullDescription": {
                 "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
+              "help": {
+                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "'{0}' is a Windows PE that was compiled with recommended Security Development Lifecycle (SDL) checks. These checks change security-relevant warnings into errors, and set additional secure code-generation features."
@@ -1365,17 +1410,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA2026EnableAdditionalSdlSecurityChecks",
-              "help": {
-                "text": "/sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. By default, /sdl is off. /sdl- disables the additional security checks."
-              }
+              "shortDescription": null,
+              "name": "EnableAdditionalSdlSecurityChecks",
+              "guid": null
             },
             {
               "id": "BA3003",
-              "name": "EnableStackProtector",
               "fullDescription": {
                 "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
+              "help": {
+                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Stack protector was found on '{0}'.  However, if you are not compiling with '--stack-protector-strong', it may provide additional protections."
@@ -1387,17 +1434,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3003EnableStackProtector",
-              "help": {
-                "text": "The stack protector ensures that all functions that use buffers over a certain size will use a stack cookie (and check it) to prevent stack based buffer overflows, exiting if stack smashing is detected. Use '--fstack-protector-strong' (all buffers of 4 bytes or more) or '--fstack-protector-all' (all functions) to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackProtector",
+              "guid": null
             },
             {
               "id": "BA3005",
-              "name": "EnableStackClashProtection",
               "fullDescription": {
                 "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
+              "help": {
+                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The Stack Clash Protection was present, so '{0}' is protected."
@@ -1409,17 +1458,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3005EnableStackClashProtection",
-              "help": {
-                "text": "This check ensures that stack clash protection is enabled. Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around. Use the compiler flags '-fstack-clash-protection' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableStackClashProtection",
+              "guid": null
             },
             {
               "id": "BA5001",
-              "name": "EnablePositionIndependentExecutableMachO",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1431,17 +1482,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5001EnablePositionIndependentExecutableMachO",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutableMachO",
+              "guid": null
             },
             {
               "id": "BA5002",
-              "name": "DoNotAllowExecutableStack",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "Executable stack is not allowed on executable '{0}'."
@@ -1453,17 +1506,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA5002DoNotAllowExecutableStack",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure do not enable flag \"--allow_stack_execute\"."
-              }
+              "shortDescription": null,
+              "name": "DoNotAllowExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3001",
-              "name": "EnablePositionIndependentExecutable",
               "fullDescription": {
                 "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
+              "help": {
+                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
+              },
               "messageStrings": {
                 "Pass_Executable": {
                   "text": "PIE enabled on executable '{0}'."
@@ -1478,17 +1533,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3001EnablePositionIndependentExecutable",
-              "help": {
-                "text": "A Position Independent Executable (PIE) relocates all of its sections at load time, including the code section, if ASLR is enabled in the Linux kernel (instead of just the stack/heap). This makes ROP-style attacks more difficult. This can be enabled by passing '-f pie' to clang/gcc."
-              }
+              "shortDescription": null,
+              "name": "EnablePositionIndependentExecutable",
+              "guid": null
             },
             {
               "id": "BA3002",
-              "name": "DoNotMarkStackAsExecutable",
               "fullDescription": {
                 "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
+              "help": {
+                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "GNU_STACK segment marked as non-executable on '{0}'."
@@ -1503,17 +1560,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3002DoNotMarkStackAsExecutable",
-              "help": {
-                "text": "This checks if a binary has an executable stack; an executable stack allows attackers to redirect code flow into stack memory, which is an easy place for an attacker to store shellcode. Ensure you are compiling with '-z noexecstack' to mark the stack as non-executable."
-              }
+              "shortDescription": null,
+              "name": "DoNotMarkStackAsExecutable",
+              "guid": null
             },
             {
               "id": "BA3006",
-              "name": "EnableNonExecutableStack",
               "fullDescription": {
                 "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
+              "help": {
+                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The non-executable stack flag was present, so '{0}' is protected."
@@ -1525,17 +1584,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3006EnableNonExecutableStack",
-              "help": {
-                "text": "This check ensures that non-executable stack is enabled. A common type of exploit is the stack buffer overflow. An application receives, from an attacker, more data than it is prepared for and stores this information on its stack, writing beyond the space reserved for it. This can be designed to cause execution of the data written on the stack. One mechanism to mitigate this vulnerability is for the system to not allow the execution of instructions in sections of memory identified as part of the stack. Use the compiler flags '-z noexecstack' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableNonExecutableStack",
+              "guid": null
             },
             {
               "id": "BA3010",
-              "name": "EnableReadOnlyRelocations",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The GNU_RELRO segment was present, so '{0}' is protected."
@@ -1547,17 +1608,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3010EnableReadOnlyRelocations",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,relro' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableReadOnlyRelocations",
+              "guid": null
             },
             {
               "id": "BA3011",
-              "name": "EnableBindNow",
               "fullDescription": {
                 "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
+              "help": {
+                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
+              },
               "messageStrings": {
                 "Pass": {
                   "text": "The BIND_NOW flag was present, so '{0}' is protected."
@@ -1569,17 +1632,19 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3011EnableBindNow",
-              "help": {
-                "text": "This check ensures that some relocation data is marked as read only after the executable is loaded, and moved below the '.data' section in memory. This prevents them from being overwritten, which can redirect control flow. Use the compiler flags '-Wl,z,now' to enable this."
-              }
+              "shortDescription": null,
+              "name": "EnableBindNow",
+              "guid": null
             },
             {
               "id": "BA3030",
-              "name": "UseCheckedFunctionsWithGcc",
               "fullDescription": {
                 "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
               },
+              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
+              "help": {
+                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
+              },
               "messageStrings": {
                 "Pass_AllFunctionsChecked": {
                   "text": "All functions that can be checked in '{0}' are using the checked versions, so this binary is protected from overflows caused by those function's use."
@@ -1597,10 +1662,9 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "helpUri": "https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-BA3030UseCheckedFunctionsWithGcc",
-              "help": {
-                "text": "GCC can automatically replace unsafe functions with checked variants when it can statically determine the length of a buffer or string. In the case of an overflow, the checked version will safely exit the program (rather than potentially allowing an exploit). This feature can be enabled by passing '-DFortify_Source=2' when optimization level 2 is enabled ('-O2')."
-              }
+              "shortDescription": null,
+              "name": "UseCheckedFunctionsWithGcc",
+              "guid": null
             }
           ],
           "properties": {
@@ -1625,7 +1689,6 @@
           }
         }
       ],
-      "automationDetails": {},
       "columnKind": "utf16CodeUnits"
     }
   ]

From 0ca3e3a19ac287592c4348e15f8751a69c3ce475 Mon Sep 17 00:00:00 2001
From: Shaopeng <81775155+shaopeng-gh@users.noreply.github.com>
Date: Fri, 7 Jan 2022 01:40:35 -0800
Subject: [PATCH 06/10] update SDK branch to use DataMember.Order and run
 re-baseline in Binskim

---
 .../Expected/BinSkim.win-x64.ni.dll.sarif     | 98 +++----------------
 .../Expected/BinSkim.win-x86.ni.dll.sarif     | 98 +++----------------
 .../Expected/Binskim.linux-x64.dll.sarif      | 94 +++---------------
 .../Expected/Binskim.win-x64.RTR.dll.sarif    | 98 +++----------------
 .../Expected/Binskim.win-x64.dll.sarif        | 94 +++---------------
 .../Expected/Binskim.win-x86.RTR.dll.sarif    | 98 +++----------------
 .../Expected/Binskim.win-x86.dll.sarif        | 94 +++---------------
 ...ore_RTR_linux-x64_VS2019_Default.dll.sarif | 98 +++----------------
 ...tCore_RTR_win-x64_VS2019_Default.dll.sarif | 98 +++----------------
 ...tCore_RTR_win-x86_VS2019_Default.dll.sarif | 98 +++----------------
 ...NetCore_linux-x64_VS2019_Default.dll.sarif | 98 +++----------------
 ...otNetCore_win-x64_VS2019_Default.dll.sarif | 98 +++----------------
 ...otNetCore_win-x64_VS2019_Default.exe.sarif | 98 +++----------------
 ...otNetCore_win-x86_VS2019_Default.dll.sarif | 98 +++----------------
 ...InteropAssemblyForAtlTestLibrary.dll.sarif | 94 +++---------------
 .../Expected/ManagedResourcesOnly.dll.sarif   | 94 +++---------------
 ...aged_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif | 98 +++----------------
 ...anaged_AnyCPU_VS2017_Prefer32Bit.exe.sarif | 98 +++----------------
 .../Managed_x64_VS2015_FSharp.exe.sarif       | 98 +++----------------
 ...VS2019_CSharp_DebugType_Embedded.dll.sarif | 98 +++----------------
 ...x64_VS2019_CSharp_DebugType_Full.dll.sarif | 98 +++----------------
 ...x64_VS2019_CSharp_DebugType_None.dll.sarif | 94 +++---------------
 ..._VS2019_CSharp_DebugType_PdbOnly.dll.sarif | 98 +++----------------
 ...VS2019_CSharp_DebugType_Portable.dll.sarif | 98 +++----------------
 ...x64_VS2019_VB_DebugType_Embedded.dll.sarif | 98 +++----------------
 ...ged_x64_VS2019_VB_DebugType_Full.dll.sarif | 98 +++----------------
 ...ged_x64_VS2019_VB_DebugType_None.dll.sarif | 94 +++---------------
 ..._x64_VS2019_VB_DebugType_PdbOnly.dll.sarif | 98 +++----------------
 ...x64_VS2019_VB_DebugType_Portable.dll.sarif | 98 +++----------------
 .../Expected/Managed_x86_VS2013_Wpf.exe.sarif | 98 +++----------------
 .../Managed_x86_VS2015_FSharp.dll.sarif       | 98 +++----------------
 .../MixedMode_x64_VS2013_Default.dll.sarif    | 98 +++----------------
 .../MixedMode_x64_VS2013_NoPdb.exe.sarif      | 70 +++----------
 .../MixedMode_x64_VS2015_Default.exe.sarif    | 98 +++----------------
 ...4_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif | 98 +++----------------
 ..._VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif | 98 +++----------------
 ..._x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif | 98 +++----------------
 ..._x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif | 70 +++----------
 .../MixedMode_x86_VS2013_Default.exe.sarif    | 98 +++----------------
 .../MixedMode_x86_VS2013_MissingPdb.dll.sarif | 70 +++----------
 .../MixedMode_x86_VS2015_Default.exe.sarif    | 98 +++----------------
 ...ve_ARM_VS2015_CvtresResourceOnly.dll.sarif | 94 +++---------------
 .../Native_x64_VS2013_Default.dll.sarif       | 98 +++----------------
 ...ve_x64_VS2015_CvtresResourceOnly.dll.sarif | 94 +++---------------
 .../Native_x64_VS2015_Default.dll.sarif       | 98 +++----------------
 ...ve_x64_VS2019_Atl_NoPdbGenerated.dll.sarif | 70 +++----------
 ...4_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif | 98 +++----------------
 ..._VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif | 98 +++----------------
 ..._x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif | 98 +++----------------
 ..._x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif | 70 +++----------
 .../Native_x64_VS2019_SDL_Enabled.exe.sarif   | 98 +++----------------
 ...tive_x64_VSCode_Rust_DebugInfo_0.exe.sarif | 98 +++----------------
 ...tive_x64_VSCode_Rust_DebugInfo_1.exe.sarif | 98 +++----------------
 ...tive_x64_VSCode_Rust_DebugInfo_2.exe.sarif | 98 +++----------------
 .../Native_x86_VS2012_SDL_Enabled.exe.sarif   | 98 +++----------------
 .../Native_x86_VS2013_Default.exe.sarif       | 98 +++----------------
 .../Native_x86_VS2013_PdbMissing.exe.sarif    | 70 +++----------
 .../Native_x86_VS2013_ResourceOnly.dll.sarif  | 98 +++----------------
 ...Native_x86_VS2015_AtlProxyStubPS.dll.sarif | 98 +++----------------
 ...ve_x86_VS2015_CvtresResourceOnly.dll.sarif | 94 +++---------------
 .../Native_x86_VS2015_Default.exe.sarif       | 98 +++----------------
 .../Native_x86_VS2015_Default_Debug.dll.sarif | 98 +++----------------
 ...ve_x86_VS2017_15.5.4_PdbStripped.dll.sarif | 70 +++----------
 .../Native_x86_VS2019_SDL_Enabled.exe.sarif   | 98 +++----------------
 .../Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif   | 98 +++----------------
 .../Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif  | 76 +++-----------
 .../Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif  | 70 +++----------
 .../Expected/Uwp_ARM_VS2017_VB.dll.sarif      | 98 +++----------------
 ...wp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif | 98 +++----------------
 .../Uwp_x64_VS2015_DefaultBlankApp.dll.sarif  | 76 +++-----------
 .../Uwp_x64_VS2015_DefaultBlankApp.exe.sarif  | 70 +++----------
 .../Expected/Uwp_x64_VS2017_Cpp.dll.sarif     | 98 +++----------------
 .../Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif    | 98 +++----------------
 .../Uwp_x86_VS2015_DefaultBlankApp.dll.sarif  | 76 +++-----------
 .../Uwp_x86_VS2015_DefaultBlankApp.exe.sarif  | 70 +++----------
 .../Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif    | 98 +++----------------
 .../Wix_3.11.1_VS2017_Bootstrapper.exe.sarif  | 98 +++----------------
 .../Expected/clang.default_compilation.sarif  | 94 +++---------------
 .../Expected/clang.elf.objectivec.dwarf.sarif | 98 +++----------------
 .../Expected/clang.execstack.sarif            | 94 +++---------------
 .../Expected/clang.execstack.so.sarif         | 94 +++---------------
 .../Expected/clang.immediate_binding.sarif    | 94 +++---------------
 .../Expected/clang.no_immediate_binding.sarif | 94 +++---------------
 .../Expected/clang.no_stack_protector.sarif   | 94 +++---------------
 .../Expected/clang.noexecstack.sarif          | 94 +++---------------
 .../Expected/clang.noexecstack.so.sarif       | 94 +++---------------
 .../Expected/clang.non_pie_executable.sarif   | 94 +++---------------
 .../Expected/clang.object_file.o.sarif        | 94 +++---------------
 .../Expected/clang.pie_executable.sarif       | 94 +++---------------
 .../Expected/clang.relocationsro.sarif        | 94 +++---------------
 .../Expected/clang.relocationsrw.sarif        | 94 +++---------------
 .../Expected/clang.shared_library.so.sarif    | 94 +++---------------
 .../Expected/clang.stack_protector.sarif      | 94 +++---------------
 .../Expected/clang.stack_protector.so.sarif   | 94 +++---------------
 .../clangcl.pe.cpp.codeview.exe.sarif         | 98 +++----------------
 .../Expected/gcc.default_compilation.sarif    | 94 +++---------------
 ...rongsspbuffersize8+fnostackprotector.sarif | 98 +++----------------
 .../Expected/gcc.execstack.sarif              | 94 +++---------------
 .../Expected/gcc.execstack.so.sarif           | 94 +++---------------
 .../Expected/gcc.fortified.sarif              | 94 +++---------------
 .../Expected/gcc.gsplitdwarf.5.dwo.sarif      | 98 +++----------------
 .../Expected/gcc.gsplitdwarf.5.sarif          | 98 +++----------------
 ...oworld.4.o.no-stack-clash-protection.sarif | 98 +++----------------
 ...oworld.5.o.no-stack-clash-protection.sarif | 98 +++----------------
 .../gcc.helloworld.execstack.5.o.sarif        | 98 +++----------------
 .../Expected/gcc.helloworld.nodwarf.sarif     | 94 +++---------------
 .../gcc.helloworld.noexecstack.5.o.sarif      | 98 +++----------------
 .../Expected/gcc.immediate_binding.sarif      | 94 +++---------------
 .../gcc.no_fortification_required.sarif       | 94 +++---------------
 .../Expected/gcc.no_immediate_binding.sarif   | 94 +++---------------
 .../Expected/gcc.no_stack_protector.sarif     | 94 +++---------------
 .../Expected/gcc.noexecstack.sarif            | 94 +++---------------
 .../Expected/gcc.noexecstack.so.sarif         | 94 +++---------------
 .../Expected/gcc.non_pie_executable.sarif     | 94 +++---------------
 ...objcopy.stripall.addgnudebuglink.dbg.sarif | 98 +++----------------
 ...gcc.objcopy.stripall.addgnudebuglink.sarif | 94 +++---------------
 .../Expected/gcc.object_file.o.sarif          | 94 +++---------------
 .../gcc.pe.objectivec.dwarf.exe.sarif         | 70 +++----------
 .../Expected/gcc.pie_executable.sarif         | 94 +++---------------
 .../Expected/gcc.relocationsro.sarif          | 94 +++---------------
 .../Expected/gcc.relocationsrw.sarif          | 94 +++---------------
 .../Expected/gcc.requiredsymbol.4.o.sarif     | 98 +++----------------
 .../Expected/gcc.requiredsymbol.5.o.sarif     | 98 +++----------------
 .../Expected/gcc.shared_library.so.sarif      | 94 +++---------------
 .../Expected/gcc.stack_protector.sarif        | 94 +++---------------
 .../Expected/gcc.stack_protector.so.sarif     | 94 +++---------------
 .../Expected/gcc.unfortified.sarif            | 94 +++---------------
 127 files changed, 1929 insertions(+), 9955 deletions(-)

diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif
index 65d6d9d03..6c43d65db 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x64.ni.dll.sarif
@@ -808,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -841,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2006",
@@ -868,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -901,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -931,9 +923,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -961,9 +951,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -994,9 +982,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1021,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1054,9 +1038,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1081,9 +1063,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1111,9 +1091,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1147,9 +1125,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1171,9 +1147,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1195,9 +1169,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1222,9 +1194,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1249,9 +1219,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1273,9 +1241,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1297,9 +1263,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1321,9 +1285,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1345,9 +1307,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1369,9 +1329,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1393,9 +1351,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1423,9 +1379,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1447,9 +1401,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1471,9 +1423,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1495,9 +1445,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1525,9 +1473,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1558,9 +1504,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1585,9 +1529,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1621,9 +1563,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1648,9 +1588,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1678,9 +1616,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1711,9 +1647,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif
index ebcc7c5d5..2ff88948d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/BinSkim.win-x86.ni.dll.sarif
@@ -806,9 +806,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -833,9 +831,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2006",
@@ -893,9 +887,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -926,9 +918,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1019,9 +1005,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1046,9 +1030,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1079,9 +1061,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1139,9 +1117,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1163,9 +1139,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1190,9 +1164,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1217,9 +1189,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1241,9 +1211,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1265,9 +1233,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1289,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1313,9 +1277,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1337,9 +1299,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1361,9 +1321,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1391,9 +1349,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1415,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1439,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1466,9 +1418,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1499,9 +1449,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1526,9 +1474,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1562,9 +1508,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1589,9 +1533,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1619,9 +1561,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1646,9 +1586,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1676,9 +1614,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1709,9 +1645,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif
index 6ec50de89..96bd3efce 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.linux-x64.dll.sarif
@@ -790,9 +790,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -817,9 +815,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -847,9 +843,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -880,9 +874,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -910,9 +902,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -937,9 +927,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -967,9 +955,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1003,9 +989,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1036,9 +1020,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1063,9 +1045,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1096,9 +1076,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1123,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1153,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1189,9 +1163,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1213,9 +1185,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1237,9 +1207,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1264,9 +1232,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1291,9 +1257,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1315,9 +1279,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1339,9 +1301,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1363,9 +1323,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1387,9 +1345,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1411,9 +1367,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1435,9 +1389,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1465,9 +1417,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1489,9 +1439,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1513,9 +1461,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1540,9 +1486,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1573,9 +1517,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1600,9 +1542,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1630,9 +1570,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1663,9 +1601,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif
index 64053d782..62462cbb0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.RTR.dll.sarif
@@ -808,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -841,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2006",
@@ -868,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -901,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -931,9 +923,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -961,9 +951,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -994,9 +982,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1021,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1054,9 +1038,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1081,9 +1063,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1111,9 +1091,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1147,9 +1125,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1171,9 +1147,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1195,9 +1169,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1222,9 +1194,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1249,9 +1219,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1273,9 +1241,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1297,9 +1263,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1321,9 +1285,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1345,9 +1307,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1369,9 +1329,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1393,9 +1351,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1423,9 +1379,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1447,9 +1401,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1471,9 +1423,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1495,9 +1445,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1525,9 +1473,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1558,9 +1504,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1585,9 +1529,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1621,9 +1563,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1648,9 +1588,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1678,9 +1616,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1711,9 +1647,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif
index 79b1d4cb0..57417ded1 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x64.dll.sarif
@@ -790,9 +790,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -817,9 +815,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -847,9 +843,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -880,9 +874,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -910,9 +902,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -937,9 +927,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -967,9 +955,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1003,9 +989,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1036,9 +1020,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1063,9 +1045,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1096,9 +1076,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1123,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1153,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1189,9 +1163,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1213,9 +1185,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1237,9 +1207,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1264,9 +1232,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1291,9 +1257,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1315,9 +1279,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1339,9 +1301,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1363,9 +1323,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1387,9 +1345,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1411,9 +1367,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1435,9 +1389,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1465,9 +1417,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1489,9 +1439,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1513,9 +1461,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1540,9 +1486,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1573,9 +1517,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1600,9 +1542,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1630,9 +1570,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1663,9 +1601,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif
index 50fe6d486..be4a16ba1 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.RTR.dll.sarif
@@ -806,9 +806,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -833,9 +831,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2006",
@@ -893,9 +887,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -926,9 +918,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1019,9 +1005,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1046,9 +1030,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1079,9 +1061,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1139,9 +1117,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1163,9 +1139,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1190,9 +1164,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1217,9 +1189,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1241,9 +1211,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1265,9 +1233,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1289,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1313,9 +1277,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1337,9 +1299,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1361,9 +1321,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1391,9 +1349,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1415,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1439,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1466,9 +1418,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1499,9 +1449,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1526,9 +1474,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1562,9 +1508,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1589,9 +1533,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1619,9 +1561,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1646,9 +1586,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1676,9 +1614,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1709,9 +1645,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif
index 933aa32a2..8efdebd1d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Binskim.win-x86.dll.sarif
@@ -786,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -813,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -843,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -876,9 +870,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -906,9 +898,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -933,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -963,9 +951,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1032,9 +1016,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1059,9 +1041,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1092,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1128,9 +1106,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1176,9 +1150,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1203,9 +1175,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1230,9 +1200,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1254,9 +1222,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1278,9 +1244,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1302,9 +1266,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1326,9 +1288,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1350,9 +1310,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1374,9 +1332,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1404,9 +1360,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1428,9 +1382,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1452,9 +1404,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1479,9 +1429,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1512,9 +1460,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1539,9 +1485,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1569,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1596,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1626,9 +1566,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1659,9 +1597,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif
index 9d15fcbc5..55823c135 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_linux-x64_VS2019_Default.dll.sarif
@@ -813,9 +813,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -840,9 +838,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -870,9 +866,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -903,9 +897,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -933,9 +925,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -960,9 +950,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -990,9 +978,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1026,9 +1012,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1059,9 +1043,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1086,9 +1068,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1119,9 +1099,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1146,9 +1124,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1176,9 +1152,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1212,9 +1186,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1236,9 +1208,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1260,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1287,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1314,9 +1280,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1338,9 +1302,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1362,9 +1324,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1386,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1410,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1434,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1458,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1488,9 +1440,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1512,9 +1462,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1536,9 +1484,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1626,9 +1568,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1653,9 +1593,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1683,9 +1621,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1716,9 +1652,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif
index 56b3adc58..f946b8c9a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x64_VS2019_Default.dll.sarif
@@ -813,9 +813,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -840,9 +838,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -870,9 +866,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -903,9 +897,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -933,9 +925,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -960,9 +950,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -990,9 +978,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1026,9 +1012,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1059,9 +1043,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1086,9 +1068,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1119,9 +1099,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1146,9 +1124,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1176,9 +1152,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1212,9 +1186,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1236,9 +1208,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1260,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1287,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1314,9 +1280,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1338,9 +1302,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1362,9 +1324,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1386,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1410,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1434,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1458,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1488,9 +1440,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1512,9 +1462,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1536,9 +1484,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1626,9 +1568,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1653,9 +1593,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1683,9 +1621,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1716,9 +1652,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif
index f1bda8df7..5eeb6b548 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_RTR_win-x86_VS2019_Default.dll.sarif
@@ -809,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -899,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -929,9 +921,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1022,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1055,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1082,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1151,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1175,9 +1151,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1199,9 +1173,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1226,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1253,9 +1223,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1277,9 +1245,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1301,9 +1267,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1325,9 +1289,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1349,9 +1311,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1373,9 +1333,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1397,9 +1355,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1427,9 +1383,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1451,9 +1405,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1475,9 +1427,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1622,9 +1564,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1649,9 +1589,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1679,9 +1617,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1712,9 +1648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif
index 1c5b99a21..c7076a5bf 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_linux-x64_VS2019_Default.dll.sarif
@@ -813,9 +813,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -840,9 +838,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -870,9 +866,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -903,9 +897,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -933,9 +925,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -960,9 +950,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -990,9 +978,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1026,9 +1012,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1059,9 +1043,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1086,9 +1068,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1119,9 +1099,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1146,9 +1124,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1176,9 +1152,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1212,9 +1186,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1236,9 +1208,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1260,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1287,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1314,9 +1280,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1338,9 +1302,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1362,9 +1324,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1386,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1410,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1434,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1458,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1488,9 +1440,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1512,9 +1462,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1536,9 +1484,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1626,9 +1568,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1653,9 +1593,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1683,9 +1621,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1716,9 +1652,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif
index daeb0d495..cdf60b472 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.dll.sarif
@@ -813,9 +813,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -840,9 +838,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -870,9 +866,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -903,9 +897,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -933,9 +925,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -960,9 +950,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -990,9 +978,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1026,9 +1012,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1059,9 +1043,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1086,9 +1068,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1119,9 +1099,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1146,9 +1124,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1176,9 +1152,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1212,9 +1186,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1236,9 +1208,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1260,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1287,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1314,9 +1280,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1338,9 +1302,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1362,9 +1324,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1386,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1410,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1434,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1458,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1488,9 +1440,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1512,9 +1462,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1536,9 +1484,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1626,9 +1568,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1653,9 +1593,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1683,9 +1621,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1716,9 +1652,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif
index c04c4b3dd..e22dcf742 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x64_VS2019_Default.exe.sarif
@@ -804,9 +804,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -837,9 +835,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2006",
@@ -864,9 +860,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -897,9 +891,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -927,9 +919,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -960,9 +950,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -987,9 +975,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1014,9 +1000,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1044,9 +1028,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1080,9 +1062,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1104,9 +1084,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1128,9 +1106,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1155,9 +1131,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1182,9 +1156,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1206,9 +1178,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1230,9 +1200,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1254,9 +1222,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1278,9 +1244,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1302,9 +1266,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1326,9 +1288,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1356,9 +1316,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1380,9 +1338,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1404,9 +1360,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1428,9 +1382,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1458,9 +1410,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1488,9 +1438,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1521,9 +1469,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1548,9 +1494,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1584,9 +1528,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1617,9 +1559,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1644,9 +1584,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1674,9 +1612,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1707,9 +1643,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif
index 60c860595..d0f304d5f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/DotNetCore_win-x86_VS2019_Default.dll.sarif
@@ -809,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -899,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -929,9 +921,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1022,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1055,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1082,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1151,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1175,9 +1151,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1199,9 +1173,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1226,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1253,9 +1223,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1277,9 +1245,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1301,9 +1267,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1325,9 +1289,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1349,9 +1311,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1373,9 +1333,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1397,9 +1355,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1427,9 +1383,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1451,9 +1405,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1475,9 +1427,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1622,9 +1564,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1649,9 +1589,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1679,9 +1617,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1712,9 +1648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif
index 29bb9a1ec..300460d03 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedInteropAssemblyForAtlTestLibrary.dll.sarif
@@ -786,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -813,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -843,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -876,9 +870,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -906,9 +898,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -933,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -963,9 +951,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1032,9 +1016,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1059,9 +1041,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1092,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1128,9 +1106,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1176,9 +1150,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1203,9 +1175,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1230,9 +1200,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1254,9 +1222,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1278,9 +1244,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1302,9 +1266,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1326,9 +1288,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1350,9 +1310,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1374,9 +1332,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1404,9 +1360,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1428,9 +1382,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1452,9 +1404,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1479,9 +1429,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1512,9 +1460,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1539,9 +1485,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1569,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1596,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1626,9 +1566,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1659,9 +1597,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif
index 9cb9f5861..376d42a07 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/ManagedResourcesOnly.dll.sarif
@@ -789,9 +789,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -816,9 +814,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -846,9 +842,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -879,9 +873,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -909,9 +901,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -936,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -966,9 +954,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1002,9 +988,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1035,9 +1019,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1062,9 +1044,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1095,9 +1075,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1122,9 +1100,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1188,9 +1162,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1212,9 +1184,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1236,9 +1206,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1263,9 +1231,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1290,9 +1256,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1314,9 +1278,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1338,9 +1300,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1362,9 +1322,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1386,9 +1344,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1410,9 +1366,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1434,9 +1388,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1464,9 +1416,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1488,9 +1438,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1512,9 +1460,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1539,9 +1485,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1572,9 +1516,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1599,9 +1541,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1629,9 +1569,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1662,9 +1600,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif
index b503fe5aa..b44604fdf 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_NoPrefer32Bit.exe.sarif
@@ -803,9 +803,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -830,9 +828,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -860,9 +856,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -893,9 +887,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -923,9 +915,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -950,9 +940,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -980,9 +968,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1016,9 +1002,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1049,9 +1033,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1076,9 +1058,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1112,9 +1092,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1136,9 +1114,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1160,9 +1136,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1187,9 +1161,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1214,9 +1186,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1238,9 +1208,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1262,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1286,9 +1252,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1310,9 +1274,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1334,9 +1296,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1358,9 +1318,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1388,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1412,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1436,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1466,9 +1418,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1493,9 +1443,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1526,9 +1474,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1559,9 +1505,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1586,9 +1530,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1616,9 +1558,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1643,9 +1583,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1673,9 +1611,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1706,9 +1642,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif
index beb05901c..9e46dd05b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_AnyCPU_VS2017_Prefer32Bit.exe.sarif
@@ -806,9 +806,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -833,9 +831,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -863,9 +859,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -896,9 +890,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -926,9 +918,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -953,9 +943,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -983,9 +971,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1019,9 +1005,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1052,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1079,9 +1061,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1112,9 +1092,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1148,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1172,9 +1148,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1196,9 +1170,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1223,9 +1195,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1250,9 +1220,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1274,9 +1242,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1298,9 +1264,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1322,9 +1286,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1346,9 +1308,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1370,9 +1330,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1394,9 +1352,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1424,9 +1380,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1448,9 +1402,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1472,9 +1424,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1502,9 +1452,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1529,9 +1477,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1562,9 +1508,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1589,9 +1533,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1619,9 +1561,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1646,9 +1586,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1676,9 +1614,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1709,9 +1645,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif
index 89e03df15..3a5b828e6 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2015_FSharp.exe.sarif
@@ -808,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -835,9 +833,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -865,9 +861,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -898,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -928,9 +920,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -955,9 +945,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -985,9 +973,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1021,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1054,9 +1038,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1081,9 +1063,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1108,9 +1088,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1138,9 +1116,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1174,9 +1150,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1198,9 +1172,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1222,9 +1194,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1249,9 +1219,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1276,9 +1244,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1300,9 +1266,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1324,9 +1288,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1348,9 +1310,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1372,9 +1332,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1396,9 +1354,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1420,9 +1376,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1450,9 +1404,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1474,9 +1426,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1498,9 +1448,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1528,9 +1476,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1555,9 +1501,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1588,9 +1532,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1621,9 +1563,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1648,9 +1588,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1678,9 +1616,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1711,9 +1647,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif
index 6c33f0790..8542a50c3 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Embedded.dll.sarif
@@ -809,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -899,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -929,9 +921,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1022,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1055,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1082,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1151,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1175,9 +1151,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1199,9 +1173,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1226,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1253,9 +1223,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1277,9 +1245,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1301,9 +1267,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1325,9 +1289,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1349,9 +1311,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1373,9 +1333,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1397,9 +1355,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1427,9 +1383,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1451,9 +1405,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1475,9 +1427,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1622,9 +1564,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1649,9 +1589,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1679,9 +1617,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1712,9 +1648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif
index cacfafb66..0c6ea83fa 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Full.dll.sarif
@@ -809,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -899,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -929,9 +921,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1022,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1055,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1082,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1151,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1175,9 +1151,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1199,9 +1173,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1226,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1253,9 +1223,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1277,9 +1245,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1301,9 +1267,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1325,9 +1289,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1349,9 +1311,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1373,9 +1333,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1397,9 +1355,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1427,9 +1383,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1451,9 +1405,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1475,9 +1427,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1622,9 +1564,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1649,9 +1589,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1679,9 +1617,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1712,9 +1648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif
index 87178f04a..41f311b97 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_None.dll.sarif
@@ -786,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -813,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -843,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -876,9 +870,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -906,9 +898,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -933,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -963,9 +951,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1032,9 +1016,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1059,9 +1041,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1092,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1128,9 +1106,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1176,9 +1150,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1203,9 +1175,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1230,9 +1200,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1254,9 +1222,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1278,9 +1244,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1302,9 +1266,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1326,9 +1288,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1350,9 +1310,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1374,9 +1332,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1404,9 +1360,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1428,9 +1382,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1452,9 +1404,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1479,9 +1429,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1512,9 +1460,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1539,9 +1485,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1569,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1596,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1626,9 +1566,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1659,9 +1597,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif
index 2545c7a7d..d8dc2e5b8 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_PdbOnly.dll.sarif
@@ -809,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -899,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -929,9 +921,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1022,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1055,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1082,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1151,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1175,9 +1151,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1199,9 +1173,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1226,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1253,9 +1223,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1277,9 +1245,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1301,9 +1267,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1325,9 +1289,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1349,9 +1311,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1373,9 +1333,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1397,9 +1355,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1427,9 +1383,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1451,9 +1405,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1475,9 +1427,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1622,9 +1564,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1649,9 +1589,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1679,9 +1617,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1712,9 +1648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif
index 232ddc41f..baace4b16 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_CSharp_DebugType_Portable.dll.sarif
@@ -809,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -899,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -929,9 +921,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1022,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1055,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1082,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1151,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1175,9 +1151,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1199,9 +1173,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1226,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1253,9 +1223,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1277,9 +1245,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1301,9 +1267,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1325,9 +1289,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1349,9 +1311,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1373,9 +1333,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1397,9 +1355,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1427,9 +1383,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1451,9 +1405,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1475,9 +1427,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1622,9 +1564,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1649,9 +1589,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1679,9 +1617,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1712,9 +1648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif
index de3e04dfc..0520c9879 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Embedded.dll.sarif
@@ -809,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -899,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -929,9 +921,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1022,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1055,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1082,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1151,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1175,9 +1151,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1199,9 +1173,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1226,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1253,9 +1223,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1277,9 +1245,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1301,9 +1267,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1325,9 +1289,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1349,9 +1311,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1373,9 +1333,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1397,9 +1355,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1427,9 +1383,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1451,9 +1405,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1475,9 +1427,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1622,9 +1564,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1649,9 +1589,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1679,9 +1617,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1712,9 +1648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif
index 366d4741c..d2d9e2629 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Full.dll.sarif
@@ -809,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -899,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -929,9 +921,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1022,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1055,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1082,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1151,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1175,9 +1151,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1199,9 +1173,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1226,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1253,9 +1223,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1277,9 +1245,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1301,9 +1267,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1325,9 +1289,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1349,9 +1311,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1373,9 +1333,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1397,9 +1355,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1427,9 +1383,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1451,9 +1405,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1475,9 +1427,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1622,9 +1564,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1649,9 +1589,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1679,9 +1617,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1712,9 +1648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif
index 3b1516b1b..ae52f39d6 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_None.dll.sarif
@@ -786,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -813,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -843,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -876,9 +870,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -906,9 +898,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -933,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -963,9 +951,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1032,9 +1016,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1059,9 +1041,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1092,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1128,9 +1106,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1176,9 +1150,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1203,9 +1175,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1230,9 +1200,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1254,9 +1222,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1278,9 +1244,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1302,9 +1266,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1326,9 +1288,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1350,9 +1310,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1374,9 +1332,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1404,9 +1360,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1428,9 +1382,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1452,9 +1404,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1479,9 +1429,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1512,9 +1460,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1539,9 +1485,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1569,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1596,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1626,9 +1566,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1659,9 +1597,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif
index cf3650996..6e6aafd03 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_PdbOnly.dll.sarif
@@ -809,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -899,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -929,9 +921,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1022,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1055,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1082,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1151,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1175,9 +1151,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1199,9 +1173,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1226,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1253,9 +1223,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1277,9 +1245,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1301,9 +1267,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1325,9 +1289,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1349,9 +1311,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1373,9 +1333,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1397,9 +1355,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1427,9 +1383,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1451,9 +1405,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1475,9 +1427,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1622,9 +1564,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1649,9 +1589,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1679,9 +1617,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1712,9 +1648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif
index 4aadd4f96..f803bb07c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x64_VS2019_VB_DebugType_Portable.dll.sarif
@@ -809,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -899,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -929,9 +921,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1022,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1055,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1082,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1151,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1175,9 +1151,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1199,9 +1173,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1226,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1253,9 +1223,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1277,9 +1245,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1301,9 +1267,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1325,9 +1289,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1349,9 +1311,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1373,9 +1333,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1397,9 +1355,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1427,9 +1383,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1451,9 +1405,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1475,9 +1427,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1622,9 +1564,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1649,9 +1589,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1679,9 +1617,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1712,9 +1648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif
index e5c573d30..8118c6ca6 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2013_Wpf.exe.sarif
@@ -806,9 +806,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -833,9 +831,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -863,9 +859,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -896,9 +890,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -926,9 +918,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -953,9 +943,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -983,9 +971,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1019,9 +1005,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1052,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1079,9 +1061,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1112,9 +1092,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1148,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1172,9 +1148,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1196,9 +1170,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1223,9 +1195,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1250,9 +1220,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1274,9 +1242,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1298,9 +1264,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1322,9 +1286,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1346,9 +1308,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1370,9 +1330,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1394,9 +1352,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1424,9 +1380,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1448,9 +1402,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1472,9 +1424,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1502,9 +1452,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1529,9 +1477,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1562,9 +1508,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1589,9 +1533,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1619,9 +1561,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1646,9 +1586,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1676,9 +1614,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1709,9 +1645,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif
index 419e0dcdc..98061a657 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Managed_x86_VS2015_FSharp.dll.sarif
@@ -806,9 +806,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -833,9 +831,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -863,9 +859,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -896,9 +890,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -926,9 +918,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -953,9 +943,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -983,9 +971,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1019,9 +1005,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1052,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1079,9 +1061,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1112,9 +1092,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1148,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1172,9 +1148,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1196,9 +1170,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1223,9 +1195,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1250,9 +1220,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1274,9 +1242,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1298,9 +1264,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1322,9 +1286,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1346,9 +1308,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1370,9 +1330,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1394,9 +1352,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1424,9 +1380,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1448,9 +1402,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1472,9 +1424,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1502,9 +1452,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1529,9 +1477,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1562,9 +1508,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1589,9 +1533,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1619,9 +1561,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1646,9 +1586,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1676,9 +1614,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1709,9 +1645,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif
index 5c7311b7b..95a41397e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_Default.dll.sarif
@@ -810,9 +810,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -843,9 +841,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -870,9 +866,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -900,9 +894,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -930,9 +922,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -957,9 +947,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -981,9 +969,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1005,9 +991,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1029,9 +1013,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1053,9 +1035,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1077,9 +1057,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1101,9 +1079,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1131,9 +1107,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1155,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1179,9 +1151,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1203,9 +1173,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1230,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1263,9 +1229,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1290,9 +1254,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1320,9 +1282,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1353,9 +1313,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1386,9 +1344,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1413,9 +1369,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1443,9 +1397,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1479,9 +1431,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1512,9 +1462,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1539,9 +1487,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1596,9 +1540,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1629,9 +1571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1662,9 +1602,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1686,9 +1624,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1710,9 +1646,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif
index 8f997e867..84d8f59c3 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2013_NoPdb.exe.sarif
@@ -569,9 +569,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -596,9 +594,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -626,9 +622,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -656,9 +650,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -683,9 +675,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -707,9 +697,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -731,9 +719,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -755,9 +741,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -779,9 +763,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -803,9 +785,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -827,9 +807,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -857,9 +835,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -881,9 +857,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -905,9 +879,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -929,9 +901,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -959,9 +929,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -992,9 +960,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1019,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1055,9 +1019,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1088,9 +1050,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1115,9 +1075,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1145,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1178,9 +1134,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif
index d8fb13d6d..c7a7030bc 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2015_Default.exe.sarif
@@ -808,9 +808,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -835,9 +833,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -865,9 +861,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -895,9 +889,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -922,9 +914,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -946,9 +936,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -970,9 +958,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -994,9 +980,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1018,9 +1002,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1042,9 +1024,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1066,9 +1046,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1096,9 +1074,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1120,9 +1096,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1144,9 +1118,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1168,9 +1140,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1195,9 +1165,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1228,9 +1196,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1255,9 +1221,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1285,9 +1249,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1318,9 +1280,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1351,9 +1311,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1378,9 +1336,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1408,9 +1364,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1444,9 +1398,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1477,9 +1429,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1504,9 +1454,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1537,9 +1485,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1564,9 +1510,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1594,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1627,9 +1569,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1660,9 +1600,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1684,9 +1622,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1708,9 +1644,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
index c3858194b..13441c362 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
@@ -811,9 +811,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -844,9 +842,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -871,9 +867,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -901,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -931,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -958,9 +948,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -982,9 +970,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1006,9 +992,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1030,9 +1014,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1054,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1078,9 +1058,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1102,9 +1080,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1132,9 +1108,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1156,9 +1130,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1180,9 +1152,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1204,9 +1174,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1231,9 +1199,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1264,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1291,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1321,9 +1283,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1354,9 +1314,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1387,9 +1345,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1414,9 +1370,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1444,9 +1398,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1480,9 +1432,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1513,9 +1463,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1540,9 +1488,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1567,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1597,9 +1541,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1630,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1663,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1687,9 +1625,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1711,9 +1647,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
index 281195b9d..dabf629dd 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
@@ -811,9 +811,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -844,9 +842,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -871,9 +867,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -901,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -931,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -958,9 +948,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -982,9 +970,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1006,9 +992,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1030,9 +1014,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1054,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1078,9 +1058,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1102,9 +1080,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1132,9 +1108,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1156,9 +1130,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1180,9 +1152,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1204,9 +1174,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1231,9 +1199,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1264,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1291,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1321,9 +1283,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1354,9 +1314,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1387,9 +1345,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1414,9 +1370,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1444,9 +1398,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1480,9 +1432,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1513,9 +1463,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1540,9 +1488,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1567,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1597,9 +1541,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1630,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1663,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1687,9 +1625,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1711,9 +1647,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
index e8753fd8d..714196152 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
@@ -811,9 +811,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -844,9 +842,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -871,9 +867,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -901,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -931,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -958,9 +948,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -982,9 +970,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1006,9 +992,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1030,9 +1014,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1054,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1078,9 +1058,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1102,9 +1080,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1132,9 +1108,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1156,9 +1130,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1180,9 +1152,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1204,9 +1174,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1231,9 +1199,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1264,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1291,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1321,9 +1283,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1354,9 +1314,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1387,9 +1345,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1414,9 +1370,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1444,9 +1398,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1480,9 +1432,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1513,9 +1463,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1540,9 +1488,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1567,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1597,9 +1541,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1630,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1663,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1687,9 +1625,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1711,9 +1647,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
index 9fd342723..8e43b9e59 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
@@ -571,9 +571,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -604,9 +602,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -631,9 +627,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -661,9 +655,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -691,9 +683,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -718,9 +708,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -742,9 +730,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -766,9 +752,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -790,9 +774,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -814,9 +796,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -838,9 +818,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -862,9 +840,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -892,9 +868,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -916,9 +890,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -940,9 +912,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -964,9 +934,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -994,9 +962,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1027,9 +993,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1054,9 +1018,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1090,9 +1052,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1117,9 +1077,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1147,9 +1105,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1180,9 +1136,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif
index a9164171b..15b954d5f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_Default.exe.sarif
@@ -802,9 +802,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -832,9 +830,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -862,9 +858,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -889,9 +883,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -913,9 +905,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -937,9 +927,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -961,9 +949,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -985,9 +971,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1009,9 +993,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1033,9 +1015,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1063,9 +1043,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1087,9 +1065,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1111,9 +1087,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2002",
@@ -1135,9 +1109,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1168,9 +1140,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1195,9 +1165,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1225,9 +1193,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1258,9 +1224,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1291,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1318,9 +1280,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1348,9 +1308,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1384,9 +1342,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1417,9 +1373,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1444,9 +1398,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1477,9 +1429,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1504,9 +1454,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1534,9 +1482,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1561,9 +1507,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1591,9 +1535,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1624,9 +1566,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1657,9 +1597,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1681,9 +1619,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1705,9 +1641,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif
index 40d87b128..fab135633 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2013_MissingPdb.dll.sarif
@@ -566,9 +566,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -596,9 +594,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -629,9 +625,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -659,9 +653,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -686,9 +678,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -710,9 +700,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -734,9 +722,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -758,9 +744,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -782,9 +766,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -806,9 +788,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -830,9 +810,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -860,9 +838,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -884,9 +860,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -908,9 +882,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -935,9 +907,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -968,9 +938,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -995,9 +963,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1031,9 +997,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1058,9 +1022,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1088,9 +1050,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1115,9 +1075,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1145,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1178,9 +1134,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif
index b2567f3bc..cf6a8bc4d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/MixedMode_x86_VS2015_Default.exe.sarif
@@ -802,9 +802,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -832,9 +830,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -862,9 +858,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -889,9 +883,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -913,9 +905,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -937,9 +927,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -961,9 +949,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -985,9 +971,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1009,9 +993,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1033,9 +1015,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1063,9 +1043,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1087,9 +1065,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1111,9 +1087,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2002",
@@ -1135,9 +1109,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1168,9 +1140,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1195,9 +1165,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1225,9 +1193,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1258,9 +1224,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1291,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1318,9 +1280,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1348,9 +1308,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1384,9 +1342,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1417,9 +1373,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1444,9 +1398,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1477,9 +1429,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1504,9 +1454,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1534,9 +1482,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1561,9 +1507,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1591,9 +1535,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1624,9 +1566,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1657,9 +1597,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1681,9 +1619,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1705,9 +1641,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif
index fc34cd4d0..19fdf00ea 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_ARM_VS2015_CvtresResourceOnly.dll.sarif
@@ -788,9 +788,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -815,9 +813,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -845,9 +841,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -878,9 +872,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -908,9 +900,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -938,9 +928,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -974,9 +962,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1007,9 +993,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1034,9 +1018,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1067,9 +1049,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1094,9 +1074,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1124,9 +1102,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1160,9 +1136,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1184,9 +1158,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1208,9 +1180,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1235,9 +1205,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1262,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1286,9 +1252,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1310,9 +1274,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1334,9 +1296,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1358,9 +1318,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1382,9 +1340,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1406,9 +1362,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1436,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1460,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1484,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1511,9 +1459,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1544,9 +1490,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1571,9 +1515,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1598,9 +1540,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1628,9 +1568,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1661,9 +1599,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif
index 17bcc6e90..66059aa34 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2013_Default.dll.sarif
@@ -812,9 +812,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -845,9 +843,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -872,9 +868,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -902,9 +896,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -932,9 +924,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -959,9 +949,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -983,9 +971,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1007,9 +993,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1031,9 +1015,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1055,9 +1037,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1079,9 +1059,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1103,9 +1081,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1133,9 +1109,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1157,9 +1131,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1181,9 +1153,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1205,9 +1175,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1232,9 +1200,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1265,9 +1231,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1292,9 +1256,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1322,9 +1284,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1355,9 +1315,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1388,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1415,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1445,9 +1399,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1481,9 +1433,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1514,9 +1464,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1541,9 +1489,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1568,9 +1514,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1598,9 +1542,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1631,9 +1573,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1664,9 +1604,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1688,9 +1626,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1712,9 +1648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif
index 03ce70d6a..9032c9d7f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_CvtresResourceOnly.dll.sarif
@@ -788,9 +788,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -815,9 +813,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -845,9 +841,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -878,9 +872,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -908,9 +900,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -938,9 +928,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -974,9 +962,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1007,9 +993,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1034,9 +1018,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1067,9 +1049,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1094,9 +1074,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1124,9 +1102,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1160,9 +1136,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1184,9 +1158,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1208,9 +1180,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1235,9 +1205,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1262,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1286,9 +1252,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1310,9 +1274,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1334,9 +1296,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1358,9 +1318,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1382,9 +1340,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1406,9 +1362,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1436,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1460,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1484,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1511,9 +1459,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1544,9 +1490,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1571,9 +1515,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1598,9 +1540,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1628,9 +1568,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1661,9 +1599,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif
index 1477baf9f..d871a6de1 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2015_Default.dll.sarif
@@ -812,9 +812,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -839,9 +837,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -869,9 +865,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -899,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -926,9 +918,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -950,9 +940,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -974,9 +962,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -998,9 +984,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1022,9 +1006,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1046,9 +1028,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1070,9 +1050,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1100,9 +1078,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1124,9 +1100,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1148,9 +1122,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1172,9 +1144,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1199,9 +1169,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1232,9 +1200,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1259,9 +1225,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1289,9 +1253,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1322,9 +1284,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1352,9 +1312,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1385,9 +1343,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1412,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1442,9 +1396,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1478,9 +1430,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1511,9 +1461,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1538,9 +1486,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1595,9 +1539,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1628,9 +1570,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1661,9 +1601,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1685,9 +1623,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1709,9 +1645,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif
index 0af238da9..a806bccd9 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_Atl_NoPdbGenerated.dll.sarif
@@ -571,9 +571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -598,9 +596,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -628,9 +624,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -658,9 +652,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -685,9 +677,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -709,9 +699,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -733,9 +721,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -757,9 +743,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -781,9 +765,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -805,9 +787,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -829,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -859,9 +837,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -883,9 +859,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -907,9 +881,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -931,9 +903,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -961,9 +931,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -991,9 +959,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1024,9 +990,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1051,9 +1015,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1087,9 +1049,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1114,9 +1074,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1144,9 +1102,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1177,9 +1133,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
index 6c3f13f61..054c162aa 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_DEFAULT.dll.sarif
@@ -811,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -838,9 +836,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -868,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -898,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -925,9 +917,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -949,9 +939,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -973,9 +961,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -997,9 +983,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1021,9 +1005,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1045,9 +1027,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1069,9 +1049,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1099,9 +1077,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1123,9 +1099,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1147,9 +1121,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1171,9 +1143,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1198,9 +1168,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1231,9 +1199,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1258,9 +1224,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1288,9 +1252,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1321,9 +1283,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1351,9 +1311,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1384,9 +1342,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1411,9 +1367,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1441,9 +1395,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1477,9 +1429,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1510,9 +1460,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1537,9 +1485,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1564,9 +1510,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1594,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1627,9 +1569,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1660,9 +1600,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1684,9 +1622,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1708,9 +1644,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
index a61379755..d1c5f94b6 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FASTLINK.dll.sarif
@@ -792,9 +792,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -819,9 +817,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -849,9 +845,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -879,9 +873,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -906,9 +898,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -930,9 +920,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -954,9 +942,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -978,9 +964,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1002,9 +986,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1026,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1050,9 +1030,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1080,9 +1058,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1104,9 +1080,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1128,9 +1102,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1152,9 +1124,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1179,9 +1149,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1212,9 +1180,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1239,9 +1205,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1269,9 +1233,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1302,9 +1264,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1332,9 +1292,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1365,9 +1323,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1392,9 +1348,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1422,9 +1376,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1458,9 +1410,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1491,9 +1441,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1518,9 +1466,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1545,9 +1491,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1575,9 +1519,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1608,9 +1550,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1641,9 +1581,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1665,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1689,9 +1625,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
index a5eb4726f..6e7945105 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_FULL.dll.sarif
@@ -811,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -838,9 +836,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -868,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -898,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -925,9 +917,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -949,9 +939,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -973,9 +961,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -997,9 +983,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1021,9 +1005,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1045,9 +1027,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1069,9 +1049,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1099,9 +1077,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1123,9 +1099,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1147,9 +1121,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1171,9 +1143,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1198,9 +1168,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1231,9 +1199,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1258,9 +1224,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1288,9 +1252,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1321,9 +1283,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1351,9 +1311,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1384,9 +1342,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1411,9 +1367,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1441,9 +1395,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1477,9 +1429,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1510,9 +1460,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1537,9 +1485,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1564,9 +1510,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1594,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1627,9 +1569,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1660,9 +1600,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1684,9 +1622,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1708,9 +1644,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
index e365fd876..8a4f25a9b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_CPlusPlus_DEBUG_NONE.dll.sarif
@@ -571,9 +571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -598,9 +596,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -628,9 +624,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -658,9 +652,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -685,9 +677,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -709,9 +699,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -733,9 +721,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -757,9 +743,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -781,9 +765,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -805,9 +787,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -829,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -859,9 +837,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -883,9 +859,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -907,9 +881,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -931,9 +903,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -961,9 +931,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -991,9 +959,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1024,9 +990,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1051,9 +1015,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1087,9 +1049,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1114,9 +1074,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1144,9 +1102,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1177,9 +1133,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif
index 062e9c375..30520d43a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VS2019_SDL_Enabled.exe.sarif
@@ -804,9 +804,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -834,9 +832,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -864,9 +860,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -891,9 +885,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -915,9 +907,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -939,9 +929,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -963,9 +951,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -987,9 +973,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1011,9 +995,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1035,9 +1017,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1065,9 +1045,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1089,9 +1067,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1113,9 +1089,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1137,9 +1111,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1164,9 +1136,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1197,9 +1167,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1224,9 +1192,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1254,9 +1220,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1287,9 +1251,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1317,9 +1279,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1350,9 +1310,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1377,9 +1335,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1407,9 +1363,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1443,9 +1397,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1476,9 +1428,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1503,9 +1453,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1536,9 +1484,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1563,9 +1509,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1626,9 +1568,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1659,9 +1599,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1683,9 +1621,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1707,9 +1643,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif
index c0d25e497..9935e605a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_0.exe.sarif
@@ -779,9 +779,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -809,9 +807,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -839,9 +835,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -866,9 +860,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -890,9 +882,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -914,9 +904,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -938,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -962,9 +948,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -986,9 +970,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1010,9 +992,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1040,9 +1020,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1064,9 +1042,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1088,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1112,9 +1086,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1139,9 +1111,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1172,9 +1142,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1199,9 +1167,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1229,9 +1195,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1262,9 +1226,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1292,9 +1254,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1325,9 +1285,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1352,9 +1310,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1382,9 +1338,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1418,9 +1372,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1451,9 +1403,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1478,9 +1428,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1511,9 +1459,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1538,9 +1484,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1568,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1601,9 +1543,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1634,9 +1574,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1658,9 +1596,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1682,9 +1618,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif
index f80f85b9c..95879d033 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_1.exe.sarif
@@ -801,9 +801,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -831,9 +829,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -861,9 +857,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -888,9 +882,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -912,9 +904,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -936,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -960,9 +948,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -984,9 +970,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1008,9 +992,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1032,9 +1014,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1062,9 +1042,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1086,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1110,9 +1086,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1134,9 +1108,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1161,9 +1133,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1194,9 +1164,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1221,9 +1189,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1251,9 +1217,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1284,9 +1248,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1314,9 +1276,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1347,9 +1307,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1374,9 +1332,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1404,9 +1360,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1440,9 +1394,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1473,9 +1425,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1500,9 +1450,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1533,9 +1481,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1560,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1590,9 +1534,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1623,9 +1565,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1656,9 +1596,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1680,9 +1618,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1704,9 +1640,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif
index 27a0be62c..ccb761236 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x64_VSCode_Rust_DebugInfo_2.exe.sarif
@@ -801,9 +801,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -831,9 +829,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -861,9 +857,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -888,9 +882,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -912,9 +904,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -936,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -960,9 +948,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -984,9 +970,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1008,9 +992,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1032,9 +1014,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1062,9 +1042,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1086,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1110,9 +1086,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1134,9 +1108,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1161,9 +1133,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1194,9 +1164,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1221,9 +1189,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1251,9 +1217,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1284,9 +1248,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1314,9 +1276,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1347,9 +1307,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1374,9 +1332,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1404,9 +1360,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1440,9 +1394,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1473,9 +1425,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1500,9 +1450,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1533,9 +1481,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1560,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1590,9 +1534,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1623,9 +1565,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1656,9 +1596,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1680,9 +1618,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1704,9 +1640,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif
index d062bfb89..66eed0aa6 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2012_SDL_Enabled.exe.sarif
@@ -807,9 +807,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -837,9 +835,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -870,9 +866,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -900,9 +894,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -927,9 +919,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -951,9 +941,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -975,9 +963,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1023,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1047,9 +1029,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1071,9 +1051,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1101,9 +1079,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1125,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1149,9 +1123,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2002",
@@ -1173,9 +1145,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1206,9 +1176,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1233,9 +1201,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1263,9 +1229,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1296,9 +1260,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1329,9 +1291,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1356,9 +1316,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1386,9 +1344,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1422,9 +1378,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1455,9 +1409,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1482,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1509,9 +1459,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1539,9 +1487,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1596,9 +1540,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1629,9 +1571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1662,9 +1602,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1686,9 +1624,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1710,9 +1646,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif
index bfb9813c5..42bb4375c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_Default.exe.sarif
@@ -807,9 +807,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -837,9 +835,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -870,9 +866,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -900,9 +894,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -927,9 +919,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -951,9 +941,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -975,9 +963,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1023,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1047,9 +1029,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1071,9 +1051,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1101,9 +1079,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1125,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1149,9 +1123,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2002",
@@ -1173,9 +1145,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1206,9 +1176,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1233,9 +1201,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1263,9 +1229,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1296,9 +1260,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1329,9 +1291,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1356,9 +1316,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1386,9 +1344,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1422,9 +1378,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1455,9 +1409,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1482,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1509,9 +1459,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1539,9 +1487,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1596,9 +1540,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1629,9 +1571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1662,9 +1602,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1686,9 +1624,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1710,9 +1646,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif
index 24cc42147..929259100 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_PdbMissing.exe.sarif
@@ -566,9 +566,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -596,9 +594,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -629,9 +625,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -659,9 +653,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -686,9 +678,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -710,9 +700,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -734,9 +722,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -758,9 +744,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -782,9 +766,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -806,9 +788,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -830,9 +810,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -860,9 +838,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -884,9 +860,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -908,9 +882,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -935,9 +907,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -968,9 +938,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -995,9 +963,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1031,9 +997,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1058,9 +1022,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1088,9 +1050,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1115,9 +1075,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1145,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1178,9 +1134,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif
index 422cc36ba..b29612c1f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2013_ResourceOnly.dll.sarif
@@ -811,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -838,9 +836,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -868,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -901,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -931,9 +923,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -961,9 +951,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -997,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1030,9 +1016,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1057,9 +1041,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1090,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1117,9 +1097,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1147,9 +1125,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1183,9 +1159,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1207,9 +1181,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1231,9 +1203,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1258,9 +1228,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1285,9 +1253,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1309,9 +1275,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1333,9 +1297,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1357,9 +1319,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1381,9 +1341,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1405,9 +1363,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1429,9 +1385,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1459,9 +1413,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1483,9 +1435,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1507,9 +1457,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1537,9 +1485,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1564,9 +1510,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1597,9 +1541,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1624,9 +1566,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1651,9 +1591,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1681,9 +1619,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1714,9 +1650,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif
index d964961a0..29983f715 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_AtlProxyStubPS.dll.sarif
@@ -803,9 +803,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -893,9 +887,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -917,9 +909,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -941,9 +931,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -965,9 +953,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -989,9 +975,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1013,9 +997,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1037,9 +1019,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1067,9 +1047,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1091,9 +1069,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1115,9 +1091,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2002",
@@ -1139,9 +1113,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1172,9 +1144,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1199,9 +1169,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1229,9 +1197,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1262,9 +1228,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1292,9 +1256,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1325,9 +1287,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1352,9 +1312,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1382,9 +1340,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1418,9 +1374,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1451,9 +1405,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1478,9 +1430,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1535,9 +1483,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1562,9 +1508,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1625,9 +1567,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1658,9 +1598,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1682,9 +1620,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1706,9 +1642,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif
index b4bfdd928..13aff9024 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_CvtresResourceOnly.dll.sarif
@@ -788,9 +788,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -815,9 +813,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -845,9 +841,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -878,9 +872,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -908,9 +900,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -938,9 +928,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -974,9 +962,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1007,9 +993,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1034,9 +1018,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1067,9 +1049,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1094,9 +1074,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1124,9 +1102,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1160,9 +1136,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1184,9 +1158,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1208,9 +1180,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1235,9 +1205,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1262,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1286,9 +1252,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1310,9 +1274,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1334,9 +1296,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1358,9 +1318,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1382,9 +1340,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1406,9 +1362,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1436,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1460,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1484,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1511,9 +1459,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1544,9 +1490,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1571,9 +1515,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1598,9 +1540,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1628,9 +1568,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1661,9 +1599,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif
index 74c363ff2..f4d840892 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default.exe.sarif
@@ -804,9 +804,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -837,9 +835,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -867,9 +863,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -894,9 +888,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -918,9 +910,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -942,9 +932,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -966,9 +954,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -990,9 +976,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1014,9 +998,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1038,9 +1020,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1068,9 +1048,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1092,9 +1070,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1116,9 +1092,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2002",
@@ -1140,9 +1114,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1173,9 +1145,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1200,9 +1170,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1230,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1263,9 +1229,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1293,9 +1257,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1326,9 +1288,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1353,9 +1313,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1383,9 +1341,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1419,9 +1375,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1452,9 +1406,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1479,9 +1431,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1506,9 +1456,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1536,9 +1484,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1563,9 +1509,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1626,9 +1568,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1659,9 +1599,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1683,9 +1621,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1707,9 +1643,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif
index ced2de24f..ad6747277 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2015_Default_Debug.dll.sarif
@@ -804,9 +804,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -837,9 +835,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -867,9 +863,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -894,9 +888,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -918,9 +910,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -942,9 +932,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -966,9 +954,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -990,9 +976,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1014,9 +998,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1038,9 +1020,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1068,9 +1048,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1092,9 +1070,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1116,9 +1092,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2002",
@@ -1140,9 +1114,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1173,9 +1145,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1200,9 +1170,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1230,9 +1198,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1263,9 +1229,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1293,9 +1257,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1326,9 +1288,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1353,9 +1313,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1383,9 +1341,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1419,9 +1375,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1452,9 +1406,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1479,9 +1431,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1506,9 +1456,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1536,9 +1484,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1563,9 +1509,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1626,9 +1568,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1659,9 +1599,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1683,9 +1621,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1707,9 +1643,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif
index 7f165a3e4..7f9ace01e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2017_15.5.4_PdbStripped.dll.sarif
@@ -564,9 +564,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -597,9 +595,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -627,9 +623,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -654,9 +648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -678,9 +670,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -702,9 +692,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -726,9 +714,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -750,9 +736,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -774,9 +758,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -798,9 +780,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -828,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -852,9 +830,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -876,9 +852,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -903,9 +877,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -933,9 +905,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -966,9 +936,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -993,9 +961,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1029,9 +995,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1056,9 +1020,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1086,9 +1048,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1113,9 +1073,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1143,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1176,9 +1132,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif
index f4ecb2572..815688fa4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Native_x86_VS2019_SDL_Enabled.exe.sarif
@@ -803,9 +803,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -893,9 +887,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -917,9 +909,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -941,9 +931,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -965,9 +953,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -989,9 +975,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1013,9 +997,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1037,9 +1019,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1067,9 +1047,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1091,9 +1069,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1115,9 +1091,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2002",
@@ -1139,9 +1113,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1172,9 +1144,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1199,9 +1169,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1229,9 +1197,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1262,9 +1228,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1292,9 +1256,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1325,9 +1287,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1352,9 +1312,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1382,9 +1340,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1418,9 +1374,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1451,9 +1405,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1478,9 +1430,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1535,9 +1483,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1562,9 +1508,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1625,9 +1567,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1658,9 +1598,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1682,9 +1620,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1706,9 +1642,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif
index 68ef9a93e..4feb22244 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM64_VS2019_Cpp.dll.sarif
@@ -820,9 +820,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -847,9 +845,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -877,9 +873,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -913,9 +907,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -937,9 +929,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -961,9 +951,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -988,9 +976,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1015,9 +1001,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1039,9 +1023,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1063,9 +1045,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1087,9 +1067,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1111,9 +1089,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1135,9 +1111,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1159,9 +1133,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1189,9 +1161,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1213,9 +1183,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1237,9 +1205,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1261,9 +1227,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1288,9 +1252,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1321,9 +1283,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1348,9 +1308,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1378,9 +1336,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1411,9 +1367,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1441,9 +1395,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1474,9 +1426,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1501,9 +1451,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1531,9 +1479,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1567,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1600,9 +1544,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1627,9 +1569,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1654,9 +1594,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1684,9 +1622,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1717,9 +1653,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif
index d86c3a995..a5b456f82 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.dll.sarif
@@ -642,9 +642,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -672,9 +670,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -702,9 +698,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -738,9 +732,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -771,9 +763,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -798,9 +788,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -831,9 +819,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -861,9 +847,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -891,9 +875,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -918,9 +900,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -942,9 +922,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -966,9 +944,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -990,9 +966,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1014,9 +988,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1038,9 +1010,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1062,9 +1032,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1092,9 +1060,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1116,9 +1082,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1140,9 +1104,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1167,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1200,9 +1160,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1227,9 +1185,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1254,9 +1210,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1281,9 +1235,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1311,9 +1263,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1344,9 +1294,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif
index 2bdc140b4..d356d8b5b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2015_DefaultBlankApp.exe.sarif
@@ -568,9 +568,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -598,9 +596,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -631,9 +627,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -661,9 +655,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -691,9 +683,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -718,9 +708,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -742,9 +730,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -766,9 +752,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -790,9 +774,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -814,9 +796,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -838,9 +818,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -862,9 +840,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -892,9 +868,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -916,9 +890,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -940,9 +912,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -967,9 +937,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1000,9 +968,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1027,9 +993,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1063,9 +1027,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1090,9 +1052,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1117,9 +1077,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1147,9 +1105,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1180,9 +1136,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif
index a9363ccc4..317a07eaa 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_ARM_VS2017_VB.dll.sarif
@@ -808,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -835,9 +833,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -865,9 +861,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -898,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -928,9 +920,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -955,9 +945,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -985,9 +973,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1021,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1054,9 +1038,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1081,9 +1063,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1114,9 +1094,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1144,9 +1122,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1180,9 +1156,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1204,9 +1178,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1228,9 +1200,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1255,9 +1225,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1282,9 +1250,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1306,9 +1272,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1330,9 +1294,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1354,9 +1316,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1378,9 +1338,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1402,9 +1360,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1426,9 +1382,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1456,9 +1410,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1480,9 +1432,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1504,9 +1454,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1534,9 +1482,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1561,9 +1507,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1594,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1621,9 +1563,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1648,9 +1588,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1678,9 +1616,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1711,9 +1647,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif
index f460a1e68..b2a40a893 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_AnyCpu_VS2019_Vb_ClassLibrary.dll.sarif
@@ -806,9 +806,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -833,9 +831,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -863,9 +859,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -896,9 +890,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -926,9 +918,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -953,9 +943,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -983,9 +971,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1019,9 +1005,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1052,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1079,9 +1061,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1112,9 +1092,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1148,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1172,9 +1148,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1196,9 +1170,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1223,9 +1195,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1250,9 +1220,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1274,9 +1242,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1298,9 +1264,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1322,9 +1286,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1346,9 +1308,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1370,9 +1330,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1394,9 +1352,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1424,9 +1380,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1448,9 +1402,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1472,9 +1424,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2004",
@@ -1502,9 +1452,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1529,9 +1477,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1562,9 +1508,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1589,9 +1533,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1619,9 +1561,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1646,9 +1586,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1676,9 +1614,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1709,9 +1645,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif
index 2a95faac1..dc600b2a0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.dll.sarif
@@ -645,9 +645,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -675,9 +673,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -711,9 +707,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -744,9 +738,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -771,9 +763,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -804,9 +794,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -831,9 +819,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -861,9 +847,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -891,9 +875,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -918,9 +900,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -942,9 +922,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -966,9 +944,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -990,9 +966,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1014,9 +988,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1038,9 +1010,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1062,9 +1032,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1092,9 +1060,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1116,9 +1082,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1140,9 +1104,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1164,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1194,9 +1154,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1227,9 +1185,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1254,9 +1210,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1281,9 +1235,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1311,9 +1263,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1344,9 +1294,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif
index f50bbe73a..a204b13bc 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2015_DefaultBlankApp.exe.sarif
@@ -569,9 +569,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -596,9 +594,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -626,9 +622,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -656,9 +650,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -683,9 +675,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -707,9 +697,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -731,9 +719,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -755,9 +741,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -779,9 +763,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -803,9 +785,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -827,9 +807,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -857,9 +835,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -881,9 +857,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -905,9 +879,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -929,9 +901,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -959,9 +929,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -992,9 +960,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1019,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1055,9 +1019,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1088,9 +1050,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1115,9 +1075,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1145,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1178,9 +1134,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif
index f4d8de87c..0278ded2f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2017_Cpp.dll.sarif
@@ -812,9 +812,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -845,9 +843,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -881,9 +877,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -905,9 +899,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -929,9 +921,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -956,9 +946,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -983,9 +971,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1007,9 +993,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1031,9 +1015,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1055,9 +1037,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1079,9 +1059,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1103,9 +1081,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1127,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1157,9 +1131,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1181,9 +1153,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1205,9 +1175,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2002",
@@ -1229,9 +1197,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1262,9 +1228,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1289,9 +1253,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1319,9 +1281,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1352,9 +1312,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1382,9 +1340,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1415,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1442,9 +1396,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1472,9 +1424,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1508,9 +1458,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1541,9 +1489,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1568,9 +1514,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1595,9 +1539,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1625,9 +1567,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1652,9 +1592,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1682,9 +1620,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1715,9 +1651,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif
index 2ab54d3e3..50a1ecc3e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x64_VS2019_Cpp_DirectX12.exe.sarif
@@ -812,9 +812,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -842,9 +840,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -878,9 +874,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -902,9 +896,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -926,9 +918,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -953,9 +943,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -980,9 +968,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1004,9 +990,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1028,9 +1012,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1052,9 +1034,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1076,9 +1056,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1100,9 +1078,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1124,9 +1100,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1154,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1178,9 +1150,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1202,9 +1172,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1226,9 +1194,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1253,9 +1219,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1286,9 +1250,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1313,9 +1275,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1343,9 +1303,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1376,9 +1334,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1406,9 +1362,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1439,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1466,9 +1418,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1496,9 +1446,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1625,9 +1567,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1652,9 +1592,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1682,9 +1620,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1715,9 +1651,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif
index ac694af16..b8fbf1d45 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.dll.sarif
@@ -640,9 +640,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -670,9 +668,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -700,9 +696,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -736,9 +730,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -769,9 +761,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -796,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -829,9 +817,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -859,9 +845,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -886,9 +870,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -910,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -934,9 +914,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -958,9 +936,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -982,9 +958,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1006,9 +980,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1030,9 +1002,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1060,9 +1030,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1084,9 +1052,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1108,9 +1074,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1135,9 +1099,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1168,9 +1130,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1195,9 +1155,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1222,9 +1180,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1252,9 +1208,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1279,9 +1233,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1309,9 +1261,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1342,9 +1292,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif
index 10468401e..48497a80d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2015_DefaultBlankApp.exe.sarif
@@ -566,9 +566,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -596,9 +594,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -629,9 +625,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -659,9 +653,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -686,9 +678,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -710,9 +700,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -734,9 +722,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -758,9 +744,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -782,9 +766,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -806,9 +788,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -830,9 +810,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -860,9 +838,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -884,9 +860,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -908,9 +882,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -935,9 +907,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -968,9 +938,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -995,9 +963,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1031,9 +997,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1058,9 +1022,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1088,9 +1050,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1115,9 +1075,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1145,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1178,9 +1134,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif
index 8201480c5..fa8670fd6 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Uwp_x86_VS2017_Cpp_DirectX11.exe.sarif
@@ -812,9 +812,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -845,9 +843,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -881,9 +877,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -905,9 +899,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -929,9 +921,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -956,9 +946,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -983,9 +971,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1007,9 +993,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1031,9 +1015,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1055,9 +1037,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1079,9 +1059,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1103,9 +1081,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1127,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1157,9 +1131,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1181,9 +1153,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1205,9 +1175,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2002",
@@ -1229,9 +1197,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1262,9 +1228,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1289,9 +1253,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1319,9 +1281,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1352,9 +1312,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1382,9 +1340,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1415,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1442,9 +1396,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1472,9 +1424,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1508,9 +1458,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1541,9 +1489,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1568,9 +1514,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1595,9 +1539,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1625,9 +1567,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1652,9 +1592,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1682,9 +1620,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1715,9 +1651,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif
index 03b323971..38aaad5c5 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/Wix_3.11.1_VS2017_Bootstrapper.exe.sarif
@@ -806,9 +806,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -833,9 +831,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -866,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2006",
@@ -893,9 +887,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -926,9 +918,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -956,9 +946,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -986,9 +974,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1019,9 +1005,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1046,9 +1030,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1079,9 +1061,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1139,9 +1117,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1163,9 +1139,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1190,9 +1164,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1217,9 +1189,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1241,9 +1211,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1265,9 +1233,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1289,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1313,9 +1277,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1337,9 +1299,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1361,9 +1321,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1391,9 +1349,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1415,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1439,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -1466,9 +1418,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1499,9 +1449,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1526,9 +1474,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1562,9 +1508,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1589,9 +1533,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1619,9 +1561,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1646,9 +1586,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1676,9 +1614,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1709,9 +1645,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif
index 572a4f33e..bbdc49129 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.default_compilation.sarif
@@ -786,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -813,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -846,9 +842,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -873,9 +867,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -903,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -936,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -966,9 +954,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1026,9 +1010,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1056,9 +1038,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1092,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1125,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1185,9 +1159,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1212,9 +1184,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1242,9 +1212,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1269,9 +1237,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1299,9 +1265,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1332,9 +1296,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1365,9 +1327,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1389,9 +1349,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1413,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1437,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1461,9 +1415,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1491,9 +1443,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1515,9 +1465,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1539,9 +1487,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1617,9 +1559,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1641,9 +1581,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1665,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif
index cdbd59af4..7b2f7e84b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.elf.objectivec.dwarf.sarif
@@ -808,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -835,9 +833,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -868,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -895,9 +889,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -925,9 +917,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -958,9 +948,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -988,9 +976,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1021,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1048,9 +1032,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1078,9 +1060,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1114,9 +1094,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1147,9 +1125,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1174,9 +1150,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1207,9 +1181,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1234,9 +1206,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1264,9 +1234,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1291,9 +1259,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1321,9 +1287,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1354,9 +1318,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1387,9 +1349,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1411,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1435,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1459,9 +1415,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1483,9 +1437,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1513,9 +1465,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1537,9 +1487,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1561,9 +1509,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1588,9 +1534,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1615,9 +1559,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3004",
@@ -1639,9 +1581,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3006",
@@ -1663,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1687,9 +1625,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1711,9 +1647,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif
index c6c2dd4c7..0e544ef02 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.sarif
@@ -784,9 +784,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -811,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -844,9 +840,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -871,9 +865,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -901,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -934,9 +924,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -964,9 +952,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -997,9 +983,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1024,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1054,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1090,9 +1070,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1123,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1150,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1183,9 +1157,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1210,9 +1182,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1240,9 +1210,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1267,9 +1235,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1297,9 +1263,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1330,9 +1294,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1363,9 +1325,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1387,9 +1347,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1411,9 +1369,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1435,9 +1391,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1459,9 +1413,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1489,9 +1441,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1513,9 +1463,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1537,9 +1485,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1564,9 +1510,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1591,9 +1535,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1615,9 +1557,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1639,9 +1579,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1663,9 +1601,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif
index ced8d21a8..006f5ebd4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.execstack.so.sarif
@@ -785,9 +785,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -812,9 +810,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -845,9 +841,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -872,9 +866,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -902,9 +894,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -935,9 +925,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -965,9 +953,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -998,9 +984,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1025,9 +1009,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1055,9 +1037,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1091,9 +1071,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1124,9 +1102,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1151,9 +1127,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1184,9 +1158,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1211,9 +1183,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1241,9 +1211,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1268,9 +1236,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1298,9 +1264,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1331,9 +1295,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1364,9 +1326,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1388,9 +1348,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1412,9 +1370,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1436,9 +1392,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1460,9 +1414,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1490,9 +1442,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1514,9 +1464,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1538,9 +1486,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1616,9 +1558,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1640,9 +1580,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1664,9 +1602,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif
index 71ea0b041..2f71a5cf8 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.immediate_binding.sarif
@@ -787,9 +787,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -814,9 +812,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -847,9 +843,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -874,9 +868,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -904,9 +896,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -937,9 +927,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -967,9 +955,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1000,9 +986,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1027,9 +1011,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1057,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1093,9 +1073,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1126,9 +1104,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1153,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1186,9 +1160,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1213,9 +1185,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1243,9 +1213,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1270,9 +1238,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1300,9 +1266,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1333,9 +1297,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1366,9 +1328,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1390,9 +1350,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1414,9 +1372,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1438,9 +1394,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1462,9 +1416,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1492,9 +1444,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1516,9 +1466,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1540,9 +1488,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1567,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1594,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1618,9 +1560,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1642,9 +1582,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1666,9 +1604,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif
index 37f9d23aa..43b92a5a0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_immediate_binding.sarif
@@ -786,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -813,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -846,9 +842,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -873,9 +867,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -903,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -936,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -966,9 +954,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1026,9 +1010,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1056,9 +1038,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1092,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1125,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1185,9 +1159,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1212,9 +1184,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1242,9 +1212,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1269,9 +1237,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1299,9 +1265,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1332,9 +1296,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1365,9 +1327,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1389,9 +1349,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1413,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1437,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1461,9 +1415,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1491,9 +1443,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1515,9 +1465,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1539,9 +1487,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1617,9 +1559,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1641,9 +1581,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1665,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif
index 55fb931a0..ed0c44d0c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.no_stack_protector.sarif
@@ -786,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -813,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -846,9 +842,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -873,9 +867,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -903,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -936,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -966,9 +954,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1026,9 +1010,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1056,9 +1038,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1092,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1125,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1185,9 +1159,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1212,9 +1184,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1242,9 +1212,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1269,9 +1237,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1299,9 +1265,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1332,9 +1296,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1365,9 +1327,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1389,9 +1349,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1413,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1437,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1461,9 +1415,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1491,9 +1443,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1515,9 +1465,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1539,9 +1487,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1617,9 +1559,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1641,9 +1581,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1665,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif
index 5c58272b9..e43b55a5d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.sarif
@@ -786,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -813,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -846,9 +842,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -873,9 +867,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -903,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -936,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -966,9 +954,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1026,9 +1010,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1056,9 +1038,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1092,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1125,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1185,9 +1159,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1212,9 +1184,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1242,9 +1212,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1269,9 +1237,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1299,9 +1265,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1332,9 +1296,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1365,9 +1327,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1389,9 +1349,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1413,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1437,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1461,9 +1415,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1491,9 +1443,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1515,9 +1465,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1539,9 +1487,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1617,9 +1559,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1641,9 +1581,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1665,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif
index e2c05f952..46fb26cc1 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.noexecstack.so.sarif
@@ -787,9 +787,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -814,9 +812,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -847,9 +843,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -874,9 +868,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -904,9 +896,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -937,9 +927,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -967,9 +955,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1000,9 +986,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1027,9 +1011,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1057,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1093,9 +1073,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1126,9 +1104,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1153,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1186,9 +1160,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1213,9 +1185,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1243,9 +1213,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1270,9 +1238,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1300,9 +1266,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1333,9 +1297,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1366,9 +1328,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1390,9 +1350,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1414,9 +1372,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1438,9 +1394,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1462,9 +1416,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1492,9 +1444,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1516,9 +1466,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1540,9 +1488,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1567,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1594,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1618,9 +1560,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1642,9 +1582,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1666,9 +1604,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif
index 6a78d0a88..02ef550bd 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.non_pie_executable.sarif
@@ -786,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -813,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -846,9 +842,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -873,9 +867,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -903,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -936,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -966,9 +954,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1026,9 +1010,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1056,9 +1038,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1092,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1125,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1185,9 +1159,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1212,9 +1184,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1242,9 +1212,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1269,9 +1237,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1299,9 +1265,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1332,9 +1296,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1365,9 +1327,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1389,9 +1349,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1413,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1437,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1461,9 +1415,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1491,9 +1443,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1515,9 +1465,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1539,9 +1487,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1617,9 +1559,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1641,9 +1581,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1665,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif
index d5ff61efa..0a41131de 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.object_file.o.sarif
@@ -798,9 +798,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -825,9 +823,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -858,9 +854,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -885,9 +879,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -915,9 +907,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -948,9 +938,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -978,9 +966,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1011,9 +997,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1038,9 +1022,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1068,9 +1050,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1104,9 +1084,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1137,9 +1115,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1164,9 +1140,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1197,9 +1171,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1224,9 +1196,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1254,9 +1224,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1281,9 +1249,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1311,9 +1277,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1344,9 +1308,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1377,9 +1339,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1401,9 +1361,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1425,9 +1383,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1452,9 +1408,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1479,9 +1433,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1503,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1527,9 +1477,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1551,9 +1499,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1575,9 +1521,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1599,9 +1543,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1629,9 +1571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1653,9 +1593,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1677,9 +1615,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif
index cd0f0024b..0b2801743 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.pie_executable.sarif
@@ -787,9 +787,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -814,9 +812,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -847,9 +843,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -874,9 +868,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -904,9 +896,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -937,9 +927,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -967,9 +955,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1000,9 +986,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1027,9 +1011,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1057,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1093,9 +1073,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1126,9 +1104,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1153,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1186,9 +1160,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1213,9 +1185,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1243,9 +1213,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1270,9 +1238,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1300,9 +1266,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1333,9 +1297,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1366,9 +1328,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1390,9 +1350,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1414,9 +1372,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1438,9 +1394,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1462,9 +1416,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1492,9 +1444,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1516,9 +1466,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1540,9 +1488,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1567,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1594,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1618,9 +1560,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1642,9 +1582,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1666,9 +1604,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif
index 615a3ae24..68c182933 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsro.sarif
@@ -786,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -813,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -846,9 +842,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -873,9 +867,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -903,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -936,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -966,9 +954,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1026,9 +1010,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1056,9 +1038,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1092,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1125,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1185,9 +1159,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1212,9 +1184,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1242,9 +1212,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1269,9 +1237,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1299,9 +1265,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1332,9 +1296,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1365,9 +1327,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1389,9 +1349,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1413,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1437,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1461,9 +1415,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1491,9 +1443,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1515,9 +1465,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1539,9 +1487,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1617,9 +1559,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1641,9 +1581,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1665,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif
index eb99839b5..7147c90cf 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.relocationsrw.sarif
@@ -785,9 +785,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -812,9 +810,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -845,9 +841,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -872,9 +866,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -902,9 +894,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -935,9 +925,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -965,9 +953,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -998,9 +984,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1025,9 +1009,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1055,9 +1037,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1091,9 +1071,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1124,9 +1102,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1151,9 +1127,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1184,9 +1158,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1211,9 +1183,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1241,9 +1211,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1268,9 +1236,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1298,9 +1264,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1331,9 +1295,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1364,9 +1326,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1388,9 +1348,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1412,9 +1370,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1436,9 +1392,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1460,9 +1414,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1490,9 +1442,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1514,9 +1464,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1538,9 +1486,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1565,9 +1511,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1592,9 +1536,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1616,9 +1558,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1640,9 +1580,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1664,9 +1602,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif
index c80e665bb..c48dcf63a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.shared_library.so.sarif
@@ -787,9 +787,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -814,9 +812,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -847,9 +843,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -874,9 +868,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -904,9 +896,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -937,9 +927,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -967,9 +955,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1000,9 +986,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1027,9 +1011,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1057,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1093,9 +1073,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1126,9 +1104,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1153,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1186,9 +1160,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1213,9 +1185,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1243,9 +1213,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1270,9 +1238,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1300,9 +1266,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1333,9 +1297,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1366,9 +1328,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1390,9 +1350,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1414,9 +1372,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1438,9 +1394,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1462,9 +1416,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1492,9 +1444,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1516,9 +1466,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1540,9 +1488,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1567,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1594,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1618,9 +1560,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1642,9 +1582,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1666,9 +1604,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif
index 5f491d2c5..4a5305958 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.sarif
@@ -786,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -813,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -846,9 +842,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -873,9 +867,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -903,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -936,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -966,9 +954,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1026,9 +1010,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1056,9 +1038,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1092,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1125,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1185,9 +1159,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1212,9 +1184,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1242,9 +1212,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1269,9 +1237,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1299,9 +1265,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1332,9 +1296,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1365,9 +1327,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1389,9 +1349,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1413,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1437,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1461,9 +1415,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1491,9 +1443,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1515,9 +1465,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1539,9 +1487,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1566,9 +1512,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1593,9 +1537,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1617,9 +1559,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1641,9 +1581,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1665,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif
index 16c236d2c..2dc9dc91b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clang.stack_protector.so.sarif
@@ -787,9 +787,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -814,9 +812,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -847,9 +843,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -874,9 +868,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -904,9 +896,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -937,9 +927,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -967,9 +955,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1000,9 +986,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1027,9 +1011,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1057,9 +1039,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1093,9 +1073,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1126,9 +1104,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1153,9 +1129,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1186,9 +1160,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1213,9 +1185,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1243,9 +1213,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1270,9 +1238,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1300,9 +1266,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1333,9 +1297,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1366,9 +1328,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1390,9 +1350,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1414,9 +1372,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1438,9 +1394,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1462,9 +1416,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3030",
@@ -1492,9 +1444,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1516,9 +1466,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1540,9 +1488,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1567,9 +1513,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1594,9 +1538,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1618,9 +1560,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1642,9 +1582,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1666,9 +1604,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif
index bf1a95853..de42adec0 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/clangcl.pe.cpp.codeview.exe.sarif
@@ -801,9 +801,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -831,9 +829,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -861,9 +857,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -888,9 +882,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -912,9 +904,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -936,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -960,9 +948,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -984,9 +970,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1008,9 +992,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1032,9 +1014,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1062,9 +1042,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1086,9 +1064,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1110,9 +1086,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2001",
@@ -1134,9 +1108,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -1161,9 +1133,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -1194,9 +1164,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -1221,9 +1189,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -1251,9 +1217,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -1284,9 +1248,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1314,9 +1276,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1347,9 +1307,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1374,9 +1332,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1404,9 +1360,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1440,9 +1394,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1473,9 +1425,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1500,9 +1450,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1533,9 +1481,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1560,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1590,9 +1534,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1623,9 +1565,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1656,9 +1596,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1680,9 +1618,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1704,9 +1640,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif
index 0c4a9e366..ce00f81c7 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.default_compilation.sarif
@@ -783,9 +783,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -810,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -843,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -870,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -900,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -933,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -963,9 +951,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -996,9 +982,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1023,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1053,9 +1035,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1089,9 +1069,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1122,9 +1100,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1149,9 +1125,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1182,9 +1156,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1209,9 +1181,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1239,9 +1209,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1266,9 +1234,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1296,9 +1262,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1329,9 +1293,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1362,9 +1324,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1386,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1410,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1434,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1458,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1482,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1506,9 +1456,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1533,9 +1481,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1560,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1584,9 +1528,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1608,9 +1550,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1632,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1662,9 +1600,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif
index 1e92efe4e..21efb5993 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.example2.fstackprotectorstrongsspbuffersize8+fnostackprotector.sarif
@@ -804,9 +804,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -831,9 +829,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -864,9 +860,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -891,9 +885,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -921,9 +913,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -954,9 +944,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -984,9 +972,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1017,9 +1003,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1044,9 +1028,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1074,9 +1056,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1110,9 +1090,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1143,9 +1121,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1170,9 +1146,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1203,9 +1177,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1230,9 +1202,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1260,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1287,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1317,9 +1283,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1350,9 +1314,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1383,9 +1345,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1407,9 +1367,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1431,9 +1389,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA5001",
@@ -1455,9 +1411,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1479,9 +1433,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1506,9 +1458,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1533,9 +1483,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1557,9 +1505,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1581,9 +1527,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1605,9 +1549,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1629,9 +1571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1653,9 +1593,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1677,9 +1615,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1707,9 +1643,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif
index 98d22b0ab..4505ff73a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.sarif
@@ -781,9 +781,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -808,9 +806,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -841,9 +837,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -868,9 +862,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -898,9 +890,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -931,9 +921,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -961,9 +949,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -994,9 +980,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1021,9 +1005,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1051,9 +1033,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1087,9 +1067,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1120,9 +1098,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1147,9 +1123,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1180,9 +1154,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1207,9 +1179,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1237,9 +1207,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1264,9 +1232,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1294,9 +1260,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1327,9 +1291,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1360,9 +1322,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1384,9 +1344,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1408,9 +1366,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1432,9 +1388,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1456,9 +1410,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1480,9 +1432,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1504,9 +1454,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1531,9 +1479,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1558,9 +1504,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1582,9 +1526,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1606,9 +1548,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1630,9 +1570,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1660,9 +1598,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif
index bff84f6ea..dc34fe47e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.execstack.so.sarif
@@ -782,9 +782,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -809,9 +807,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -842,9 +838,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -869,9 +863,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -899,9 +891,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -932,9 +922,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -962,9 +950,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -995,9 +981,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1022,9 +1006,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1052,9 +1034,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1088,9 +1068,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1121,9 +1099,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1148,9 +1124,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1181,9 +1155,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1208,9 +1180,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1238,9 +1208,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1265,9 +1233,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1295,9 +1261,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1328,9 +1292,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1361,9 +1323,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1385,9 +1345,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1409,9 +1367,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1433,9 +1389,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1457,9 +1411,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1481,9 +1433,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1559,9 +1505,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1583,9 +1527,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1607,9 +1549,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1631,9 +1571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1661,9 +1599,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif
index e5b18e2dc..f960deb6c 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.fortified.sarif
@@ -784,9 +784,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -811,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -844,9 +840,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -871,9 +865,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -901,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -934,9 +924,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -964,9 +952,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -997,9 +983,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1024,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1054,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1090,9 +1070,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1123,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1150,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1183,9 +1157,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1210,9 +1182,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1240,9 +1210,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1267,9 +1235,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1297,9 +1263,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1330,9 +1294,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1363,9 +1325,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1387,9 +1347,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1411,9 +1369,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1435,9 +1391,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1459,9 +1413,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1483,9 +1435,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1507,9 +1457,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1534,9 +1482,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1561,9 +1507,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1585,9 +1529,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1609,9 +1551,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1633,9 +1573,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1663,9 +1601,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif
index b9025e7e8..2cde19251 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.dwo.sarif
@@ -822,9 +822,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -849,9 +847,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -882,9 +878,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -909,9 +903,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -939,9 +931,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -972,9 +962,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1002,9 +990,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1035,9 +1021,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1062,9 +1046,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1092,9 +1074,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1128,9 +1108,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1161,9 +1139,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1188,9 +1164,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1221,9 +1195,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1248,9 +1220,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1278,9 +1248,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1305,9 +1273,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1335,9 +1301,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1368,9 +1332,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1401,9 +1363,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1425,9 +1385,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1449,9 +1407,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1476,9 +1432,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1503,9 +1457,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1527,9 +1479,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1551,9 +1501,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1575,9 +1523,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1599,9 +1545,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1623,9 +1567,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1647,9 +1589,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1677,9 +1617,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1701,9 +1639,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1725,9 +1661,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif
index dc0daf762..8d9950746 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.gsplitdwarf.5.sarif
@@ -809,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -836,9 +834,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -869,9 +865,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -896,9 +890,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -926,9 +918,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -959,9 +949,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -989,9 +977,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1022,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1049,9 +1033,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1079,9 +1061,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1115,9 +1095,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1148,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1175,9 +1151,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1208,9 +1182,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1235,9 +1207,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1265,9 +1235,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1292,9 +1260,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1322,9 +1288,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1355,9 +1319,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1388,9 +1350,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1412,9 +1372,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1436,9 +1394,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1460,9 +1416,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1484,9 +1438,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1508,9 +1460,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1532,9 +1482,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1559,9 +1507,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1586,9 +1532,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3004",
@@ -1610,9 +1554,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3006",
@@ -1634,9 +1576,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1658,9 +1598,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1682,9 +1620,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1712,9 +1648,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif
index 21d092754..9ae289069 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.4.o.no-stack-clash-protection.sarif
@@ -804,9 +804,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -831,9 +829,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -864,9 +860,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -891,9 +885,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -921,9 +913,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -954,9 +944,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -984,9 +972,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1017,9 +1003,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1044,9 +1028,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1074,9 +1056,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1110,9 +1090,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1143,9 +1121,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1170,9 +1146,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1203,9 +1177,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1230,9 +1202,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1260,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1287,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1317,9 +1283,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1350,9 +1314,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1383,9 +1345,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1407,9 +1367,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1431,9 +1389,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA5001",
@@ -1455,9 +1411,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1479,9 +1433,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1506,9 +1458,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1533,9 +1483,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1557,9 +1505,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1581,9 +1527,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1605,9 +1549,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1629,9 +1571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1653,9 +1593,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1677,9 +1615,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1707,9 +1643,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif
index 459c7a484..9d57a1972 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.5.o.no-stack-clash-protection.sarif
@@ -805,9 +805,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -832,9 +830,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -865,9 +861,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -892,9 +886,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -922,9 +914,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -955,9 +945,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -985,9 +973,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1018,9 +1004,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1045,9 +1029,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1075,9 +1057,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1111,9 +1091,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1144,9 +1122,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1171,9 +1147,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1204,9 +1178,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1231,9 +1203,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1261,9 +1231,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1288,9 +1256,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1318,9 +1284,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1351,9 +1315,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1384,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1408,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1432,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA5001",
@@ -1456,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1480,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1507,9 +1459,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1534,9 +1484,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1558,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1582,9 +1528,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1606,9 +1550,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1630,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1654,9 +1594,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1678,9 +1616,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1708,9 +1644,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif
index 71d6188ac..9fdc9593e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.execstack.5.o.sarif
@@ -803,9 +803,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -830,9 +828,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -863,9 +859,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -890,9 +884,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -920,9 +912,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -953,9 +943,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -983,9 +971,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1016,9 +1002,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1043,9 +1027,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1073,9 +1055,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1109,9 +1089,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1142,9 +1120,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1169,9 +1145,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1202,9 +1176,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1229,9 +1201,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1259,9 +1229,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1286,9 +1254,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1316,9 +1282,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1349,9 +1313,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1382,9 +1344,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1406,9 +1366,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1430,9 +1388,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA5001",
@@ -1454,9 +1410,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1478,9 +1432,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1505,9 +1457,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1532,9 +1482,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1556,9 +1504,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1580,9 +1526,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1604,9 +1548,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1628,9 +1570,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1652,9 +1592,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1676,9 +1614,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1706,9 +1642,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif
index a1af4303f..cf64d599b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.nodwarf.sarif
@@ -786,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -813,9 +811,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -846,9 +842,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -873,9 +867,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -903,9 +895,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -936,9 +926,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -966,9 +954,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -999,9 +985,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1026,9 +1010,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1056,9 +1038,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1092,9 +1072,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1125,9 +1103,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1152,9 +1128,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1185,9 +1159,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1212,9 +1184,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1242,9 +1212,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1269,9 +1237,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1299,9 +1265,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1332,9 +1296,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1365,9 +1327,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1389,9 +1349,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1413,9 +1371,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1437,9 +1393,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1461,9 +1415,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1485,9 +1437,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1509,9 +1459,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1536,9 +1484,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1563,9 +1509,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1587,9 +1531,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1611,9 +1553,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1635,9 +1575,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1665,9 +1603,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif
index 3c828b129..f5b8ac7a4 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.helloworld.noexecstack.5.o.sarif
@@ -805,9 +805,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -832,9 +830,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -865,9 +861,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -892,9 +886,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -922,9 +914,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -955,9 +945,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -985,9 +973,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1018,9 +1004,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1045,9 +1029,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1075,9 +1057,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1111,9 +1091,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1144,9 +1122,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1171,9 +1147,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1204,9 +1178,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1231,9 +1203,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1261,9 +1231,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1288,9 +1256,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1318,9 +1284,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1351,9 +1315,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1384,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1408,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1432,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA5001",
@@ -1456,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1480,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1507,9 +1459,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1534,9 +1484,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1558,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1582,9 +1528,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1606,9 +1550,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1630,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1654,9 +1594,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1678,9 +1616,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1708,9 +1644,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif
index aa06601e2..a0c7aa7f8 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.immediate_binding.sarif
@@ -784,9 +784,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -811,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -844,9 +840,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -871,9 +865,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -901,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -934,9 +924,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -964,9 +952,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -997,9 +983,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1024,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1054,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1090,9 +1070,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1123,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1150,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1183,9 +1157,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1210,9 +1182,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1240,9 +1210,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1267,9 +1235,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1297,9 +1263,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1330,9 +1294,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1363,9 +1325,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1387,9 +1347,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1411,9 +1369,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1435,9 +1391,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1459,9 +1413,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1483,9 +1435,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1507,9 +1457,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1534,9 +1482,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1561,9 +1507,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1585,9 +1529,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1609,9 +1551,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1633,9 +1573,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1663,9 +1601,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif
index ec7218504..35217331f 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_fortification_required.sarif
@@ -784,9 +784,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -811,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -844,9 +840,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -871,9 +865,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -901,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -934,9 +924,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -964,9 +952,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -997,9 +983,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1024,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1054,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1090,9 +1070,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1123,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1150,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1183,9 +1157,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1210,9 +1182,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1240,9 +1210,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1267,9 +1235,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1297,9 +1263,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1330,9 +1294,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1363,9 +1325,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1387,9 +1347,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1411,9 +1369,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1435,9 +1391,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1459,9 +1413,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1483,9 +1435,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1507,9 +1457,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1534,9 +1482,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1561,9 +1507,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1585,9 +1529,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1609,9 +1551,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1633,9 +1573,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1663,9 +1601,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif
index 00169bfdc..4ab87a2ac 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_immediate_binding.sarif
@@ -783,9 +783,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -810,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -843,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -870,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -900,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -933,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -963,9 +951,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -996,9 +982,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1023,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1053,9 +1035,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1089,9 +1069,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1122,9 +1100,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1149,9 +1125,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1182,9 +1156,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1209,9 +1181,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1239,9 +1209,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1266,9 +1234,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1296,9 +1262,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1329,9 +1293,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1362,9 +1324,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1386,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1410,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1434,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1458,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1482,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1506,9 +1456,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1533,9 +1481,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1560,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1584,9 +1528,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1608,9 +1550,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1632,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1662,9 +1600,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif
index 76e30e0e0..4dcda324a 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.no_stack_protector.sarif
@@ -783,9 +783,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -810,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -843,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -870,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -900,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -933,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -963,9 +951,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -996,9 +982,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1023,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1053,9 +1035,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1089,9 +1069,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1122,9 +1100,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1149,9 +1125,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1182,9 +1156,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1209,9 +1181,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1239,9 +1209,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1266,9 +1234,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1296,9 +1262,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1329,9 +1293,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1362,9 +1324,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1386,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1410,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1434,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1458,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1482,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1506,9 +1456,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1533,9 +1481,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1560,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1584,9 +1528,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1608,9 +1550,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1632,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1662,9 +1600,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif
index 26a2ec96b..e6498d366 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.sarif
@@ -783,9 +783,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -810,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -843,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -870,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -900,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -933,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -963,9 +951,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -996,9 +982,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1023,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1053,9 +1035,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1089,9 +1069,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1122,9 +1100,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1149,9 +1125,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1182,9 +1156,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1209,9 +1181,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1239,9 +1209,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1266,9 +1234,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1296,9 +1262,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1329,9 +1293,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1362,9 +1324,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1386,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1410,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1434,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1458,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1482,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1506,9 +1456,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1533,9 +1481,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1560,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1584,9 +1528,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1608,9 +1550,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1632,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1662,9 +1600,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif
index db5a7a2ee..47a394dca 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.noexecstack.so.sarif
@@ -784,9 +784,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -811,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -844,9 +840,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -871,9 +865,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -901,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -934,9 +924,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -964,9 +952,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -997,9 +983,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1024,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1054,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1090,9 +1070,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1123,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1150,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1183,9 +1157,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1210,9 +1182,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1240,9 +1210,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1267,9 +1235,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1297,9 +1263,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1330,9 +1294,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1363,9 +1325,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1387,9 +1347,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1411,9 +1369,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1435,9 +1391,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1459,9 +1413,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1483,9 +1435,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1507,9 +1457,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1534,9 +1482,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1561,9 +1507,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1585,9 +1529,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1609,9 +1551,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1633,9 +1573,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1663,9 +1601,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif
index 70aa2d308..38e30ada3 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.non_pie_executable.sarif
@@ -783,9 +783,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -810,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -843,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -870,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -900,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -933,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -963,9 +951,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -996,9 +982,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1023,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1053,9 +1035,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1089,9 +1069,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1122,9 +1100,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1149,9 +1125,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1182,9 +1156,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1209,9 +1181,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1239,9 +1209,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1266,9 +1234,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1296,9 +1262,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1329,9 +1293,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1362,9 +1324,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1386,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1410,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1434,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1458,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1482,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1506,9 +1456,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1533,9 +1481,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1560,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1584,9 +1528,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1608,9 +1550,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1632,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1662,9 +1600,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif
index a352562a4..dc36e1ebe 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.dbg.sarif
@@ -822,9 +822,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -849,9 +847,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -882,9 +878,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -909,9 +903,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -939,9 +931,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -972,9 +962,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -1002,9 +990,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1035,9 +1021,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1062,9 +1046,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1092,9 +1074,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1128,9 +1108,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1161,9 +1139,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1188,9 +1164,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1221,9 +1195,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1248,9 +1220,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1278,9 +1248,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1305,9 +1273,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1335,9 +1301,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1368,9 +1332,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1401,9 +1363,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1425,9 +1385,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1449,9 +1407,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1476,9 +1432,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1503,9 +1457,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1527,9 +1479,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1551,9 +1501,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1575,9 +1523,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1599,9 +1545,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1623,9 +1567,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1647,9 +1589,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1677,9 +1617,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1701,9 +1639,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1725,9 +1661,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif
index cafef0877..f5692be5b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.objcopy.stripall.addgnudebuglink.sarif
@@ -782,9 +782,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -809,9 +807,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -842,9 +838,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -869,9 +863,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -899,9 +891,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -932,9 +922,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -962,9 +950,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -995,9 +981,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1022,9 +1006,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1052,9 +1034,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1088,9 +1068,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1121,9 +1099,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1148,9 +1124,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1181,9 +1155,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1208,9 +1180,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1238,9 +1208,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1265,9 +1233,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1295,9 +1261,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1328,9 +1292,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1361,9 +1323,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1385,9 +1345,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1409,9 +1367,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA5001",
@@ -1433,9 +1389,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1457,9 +1411,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1484,9 +1436,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1511,9 +1461,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1535,9 +1483,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1559,9 +1505,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1583,9 +1527,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1607,9 +1549,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1631,9 +1571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1661,9 +1599,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif
index 1b735753c..2b889b4af 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.object_file.o.sarif
@@ -798,9 +798,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -825,9 +823,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -858,9 +854,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -885,9 +879,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -915,9 +907,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -948,9 +938,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -978,9 +966,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1011,9 +997,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1038,9 +1022,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1068,9 +1050,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1104,9 +1084,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1137,9 +1115,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1164,9 +1140,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1197,9 +1171,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1224,9 +1196,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1254,9 +1224,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1281,9 +1249,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1311,9 +1277,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1344,9 +1308,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1377,9 +1339,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1401,9 +1361,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1425,9 +1383,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3001",
@@ -1452,9 +1408,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1479,9 +1433,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1503,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1527,9 +1477,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1551,9 +1499,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1575,9 +1521,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1599,9 +1543,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1629,9 +1571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -1653,9 +1593,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1677,9 +1615,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif
index 73b08fdae..de066311b 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pe.objectivec.dwarf.exe.sarif
@@ -564,9 +564,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -594,9 +592,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -627,9 +623,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -657,9 +651,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -684,9 +676,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -708,9 +698,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -732,9 +720,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -756,9 +742,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -780,9 +764,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -804,9 +786,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -828,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -858,9 +836,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             },
             {
               "id": "BA5001",
@@ -882,9 +858,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -906,9 +880,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA2005",
@@ -933,9 +905,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -966,9 +936,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -993,9 +961,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1029,9 +995,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1056,9 +1020,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1086,9 +1048,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1113,9 +1073,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1143,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1176,9 +1132,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif
index 9d2d81f2c..7a31b65dd 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.pie_executable.sarif
@@ -784,9 +784,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -811,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -844,9 +840,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -871,9 +865,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -901,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -934,9 +924,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -964,9 +952,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -997,9 +983,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1024,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1054,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1090,9 +1070,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1123,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1150,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1183,9 +1157,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1210,9 +1182,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1240,9 +1210,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1267,9 +1235,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1297,9 +1263,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1330,9 +1294,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1363,9 +1325,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1387,9 +1347,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1411,9 +1369,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1435,9 +1391,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1459,9 +1413,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1483,9 +1435,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1507,9 +1457,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1534,9 +1482,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1561,9 +1507,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1585,9 +1529,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1609,9 +1551,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1633,9 +1573,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1663,9 +1601,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif
index 198bdb5ab..129304a9e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsro.sarif
@@ -783,9 +783,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -810,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -843,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -870,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -900,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -933,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -963,9 +951,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -996,9 +982,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1023,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1053,9 +1035,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1089,9 +1069,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1122,9 +1100,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1149,9 +1125,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1182,9 +1156,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1209,9 +1181,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1239,9 +1209,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1266,9 +1234,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1296,9 +1262,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1329,9 +1293,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1362,9 +1324,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1386,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1410,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1434,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1458,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1482,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1506,9 +1456,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1533,9 +1481,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1560,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1584,9 +1528,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1608,9 +1550,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1632,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1662,9 +1600,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif
index b3496781a..71ffc0b1e 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.relocationsrw.sarif
@@ -782,9 +782,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -809,9 +807,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -842,9 +838,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -869,9 +863,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -899,9 +891,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -932,9 +922,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -962,9 +950,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -995,9 +981,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1022,9 +1006,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1052,9 +1034,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1088,9 +1068,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1121,9 +1099,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1148,9 +1124,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1181,9 +1155,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1208,9 +1180,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1238,9 +1208,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1265,9 +1233,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1295,9 +1261,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1328,9 +1292,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1361,9 +1323,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1385,9 +1345,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1409,9 +1367,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1433,9 +1389,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1457,9 +1411,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1481,9 +1433,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1505,9 +1455,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1532,9 +1480,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1559,9 +1505,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1583,9 +1527,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1607,9 +1549,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1631,9 +1571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1661,9 +1599,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif
index 931a64434..50d43532d 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.4.o.sarif
@@ -804,9 +804,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -831,9 +829,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -864,9 +860,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -891,9 +885,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -921,9 +913,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -954,9 +944,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -984,9 +972,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1017,9 +1003,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1044,9 +1028,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1074,9 +1056,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1110,9 +1090,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1143,9 +1121,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1170,9 +1146,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1203,9 +1177,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1230,9 +1202,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1260,9 +1230,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1287,9 +1255,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1317,9 +1283,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1350,9 +1314,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1383,9 +1345,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1407,9 +1367,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1431,9 +1389,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA5001",
@@ -1455,9 +1411,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1479,9 +1433,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1506,9 +1458,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1533,9 +1483,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1557,9 +1505,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1581,9 +1527,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1605,9 +1549,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1629,9 +1571,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1653,9 +1593,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1677,9 +1615,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1707,9 +1643,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif
index 075b1de8a..16028c0e8 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.requiredsymbol.5.o.sarif
@@ -805,9 +805,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -832,9 +830,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -865,9 +861,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -892,9 +886,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -922,9 +914,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -955,9 +945,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -985,9 +973,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -1018,9 +1004,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1045,9 +1029,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1075,9 +1057,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1111,9 +1091,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1144,9 +1122,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1171,9 +1147,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1204,9 +1178,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1231,9 +1203,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1261,9 +1231,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1288,9 +1256,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1318,9 +1284,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1351,9 +1315,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1384,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1408,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1432,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA5001",
@@ -1456,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1480,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1507,9 +1459,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1534,9 +1484,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3003",
@@ -1558,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3004",
@@ -1582,9 +1528,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "GenerateRequiredSymbolFormat",
-              "guid": null
+              "name": "GenerateRequiredSymbolFormat"
             },
             {
               "id": "BA3005",
@@ -1606,9 +1550,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA3006",
@@ -1630,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1654,9 +1594,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1678,9 +1616,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1708,9 +1644,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif
index f88dafd66..988b54661 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.shared_library.so.sarif
@@ -784,9 +784,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -811,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -844,9 +840,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -871,9 +865,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -901,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -934,9 +924,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -964,9 +952,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -997,9 +983,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1024,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1054,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1090,9 +1070,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1123,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1150,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1183,9 +1157,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1210,9 +1182,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1240,9 +1210,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1267,9 +1235,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1297,9 +1263,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1330,9 +1294,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1363,9 +1325,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1387,9 +1347,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1411,9 +1369,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1435,9 +1391,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1459,9 +1413,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1483,9 +1435,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1507,9 +1457,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1534,9 +1482,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1561,9 +1507,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1585,9 +1529,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1609,9 +1551,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1633,9 +1573,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1663,9 +1601,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif
index 18e78bdcc..03618d784 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.sarif
@@ -783,9 +783,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -810,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -843,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -870,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -900,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -933,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -963,9 +951,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -996,9 +982,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1023,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1053,9 +1035,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1089,9 +1069,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1122,9 +1100,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1149,9 +1125,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1182,9 +1156,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1209,9 +1181,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1239,9 +1209,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1266,9 +1234,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1296,9 +1262,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1329,9 +1293,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1362,9 +1324,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1386,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1410,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1434,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1458,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1482,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1506,9 +1456,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1533,9 +1481,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1560,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1584,9 +1528,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1608,9 +1550,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1632,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1662,9 +1600,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif
index c931c9ad0..60341f525 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.stack_protector.so.sarif
@@ -784,9 +784,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -811,9 +809,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -844,9 +840,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -871,9 +865,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -901,9 +893,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -934,9 +924,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -964,9 +952,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -997,9 +983,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1024,9 +1008,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1054,9 +1036,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1090,9 +1070,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1123,9 +1101,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1150,9 +1126,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1183,9 +1157,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1210,9 +1182,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1240,9 +1210,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1267,9 +1235,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1297,9 +1263,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1330,9 +1294,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1363,9 +1325,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1387,9 +1347,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1411,9 +1369,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1435,9 +1391,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1459,9 +1413,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1483,9 +1435,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1507,9 +1457,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1534,9 +1482,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1561,9 +1507,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1585,9 +1529,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1609,9 +1551,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1633,9 +1573,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1663,9 +1601,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {
diff --git a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif
index 85b8b4821..abecdfb73 100644
--- a/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif
+++ b/src/Test.FunctionalTests.BinSkim.Driver/BaselineTestsData/Expected/gcc.unfortified.sarif
@@ -783,9 +783,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "LoadImageAboveFourGigabyteAddress",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "FourGbCheck"
               }
@@ -810,9 +808,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotIncorporateVulnerableDependencies",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ATLVersionCheck"
               }
@@ -843,9 +839,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSecureSourceCodeHashing",
-              "guid": null
+              "name": "EnableSecureSourceCodeHashing"
             },
             {
               "id": "BA2005",
@@ -870,9 +864,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotShipVulnerableBinaries",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "BinaryVersionsCheck"
               }
@@ -900,9 +892,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "BuildWithSecureTools",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerVersionCheck"
               }
@@ -933,9 +923,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableCriticalCompilerWarnings",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "CompilerWarningsCheck"
               }
@@ -963,9 +951,7 @@
                   "text": "'{0}' is a kernel mode portable executable compiled for a version of Windows that does not support the control flow guard feature for kernel mode binaries."
                 }
               },
-              "shortDescription": null,
               "name": "EnableControlFlowGuard",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ControlFlowGuardCheck"
               }
@@ -996,9 +982,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableAddressSpaceLayoutRandomization",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DBCheck"
               }
@@ -1023,9 +1007,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkImportsSectionAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "ExecutableImportsCheck"
               }
@@ -1053,9 +1035,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSCheck"
               }
@@ -1089,9 +1069,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotModifyStackProtectionCookie",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "DefaultGSCookieCheck"
               }
@@ -1122,9 +1100,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "InitializeStackProtection",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFriendlyInitCheck"
               }
@@ -1149,9 +1125,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotDisableStackProtectionForFunctions",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "GSFunctionSafeBuffersCheck"
               }
@@ -1182,9 +1156,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableHighEntropyVirtualAddresses",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "HighEntropyVACheck"
               }
@@ -1209,9 +1181,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "MarkImageAsNXCompatible",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "NXCheck"
               }
@@ -1239,9 +1209,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "EnableSafeSEH",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SafeSEHCheck"
               }
@@ -1266,9 +1234,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsShared",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "SharedSectionCheck"
               }
@@ -1296,9 +1262,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
               "name": "DoNotMarkWritableSectionsAsExecutable",
-              "guid": null,
               "properties": {
                 "equivalentBinScopeRuleReadableName": "WXCheck"
               }
@@ -1329,9 +1293,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "SignSecurely",
-              "guid": null
+              "name": "SignSecurely"
             },
             {
               "id": "BA2024",
@@ -1362,9 +1324,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableSpectreMitigations",
-              "guid": null
+              "name": "EnableSpectreMitigations"
             },
             {
               "id": "BA2025",
@@ -1386,9 +1346,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableShadowStack",
-              "guid": null
+              "name": "EnableShadowStack"
             },
             {
               "id": "BA2026",
@@ -1410,9 +1368,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableAdditionalSdlSecurityChecks",
-              "guid": null
+              "name": "EnableAdditionalSdlSecurityChecks"
             },
             {
               "id": "BA3003",
@@ -1434,9 +1390,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackProtector",
-              "guid": null
+              "name": "EnableStackProtector"
             },
             {
               "id": "BA3005",
@@ -1458,9 +1412,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableStackClashProtection",
-              "guid": null
+              "name": "EnableStackClashProtection"
             },
             {
               "id": "BA5001",
@@ -1482,9 +1434,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutableMachO",
-              "guid": null
+              "name": "EnablePositionIndependentExecutableMachO"
             },
             {
               "id": "BA5002",
@@ -1506,9 +1456,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotAllowExecutableStack",
-              "guid": null
+              "name": "DoNotAllowExecutableStack"
             },
             {
               "id": "BA3001",
@@ -1533,9 +1481,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnablePositionIndependentExecutable",
-              "guid": null
+              "name": "EnablePositionIndependentExecutable"
             },
             {
               "id": "BA3002",
@@ -1560,9 +1506,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "DoNotMarkStackAsExecutable",
-              "guid": null
+              "name": "DoNotMarkStackAsExecutable"
             },
             {
               "id": "BA3006",
@@ -1584,9 +1528,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableNonExecutableStack",
-              "guid": null
+              "name": "EnableNonExecutableStack"
             },
             {
               "id": "BA3010",
@@ -1608,9 +1550,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableReadOnlyRelocations",
-              "guid": null
+              "name": "EnableReadOnlyRelocations"
             },
             {
               "id": "BA3011",
@@ -1632,9 +1572,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "EnableBindNow",
-              "guid": null
+              "name": "EnableBindNow"
             },
             {
               "id": "BA3030",
@@ -1662,9 +1600,7 @@
                   "text": "'{0}' was not evaluated for check '{1}' as the analysis is not relevant based on observed metadata: {2}."
                 }
               },
-              "shortDescription": null,
-              "name": "UseCheckedFunctionsWithGcc",
-              "guid": null
+              "name": "UseCheckedFunctionsWithGcc"
             }
           ],
           "properties": {

From b542a26da085601eafba715791ad2bce483d9c5a Mon Sep 17 00:00:00 2001
From: Shaopeng <81775155+shaopeng-gh@users.noreply.github.com>
Date: Sat, 8 Jan 2022 19:06:54 -0800
Subject: [PATCH 07/10] move && to end of line

---
 src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs b/src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs
index c8dc7fd81..098e149a1 100644
--- a/src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs
+++ b/src/BinSkim.Rules/PERules/BA2006.BuildWithSecureTools.cs
@@ -116,8 +116,8 @@ public override void AnalyzePortableExecutableAndPdb(BinaryAnalyzerContext conte
                 Symbol om = omView.Value;
                 ObjectModuleDetails omDetails = om.GetObjectModuleDetails();
 
-                if (omDetails.WellKnownCompiler != WellKnownCompilers.MicrosoftC
-                    && omDetails.WellKnownCompiler != WellKnownCompilers.MicrosoftCxx)
+                if (omDetails.WellKnownCompiler != WellKnownCompilers.MicrosoftC &&
+                    omDetails.WellKnownCompiler != WellKnownCompilers.MicrosoftCxx)
                 {
                     // TODO: MikeFan (1/6/2022)
                     // We need to take a step back and comprehensively review our compiler/language support.

From 9d58f42be5d18c77cb4976a7403265ba4a5ad0e1 Mon Sep 17 00:00:00 2001
From: Shaopeng <81775155+shaopeng-gh@users.noreply.github.com>
Date: Mon, 10 Jan 2022 11:56:14 -0800
Subject: [PATCH 08/10] upgrade submodule

---
 src/sarif-sdk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sarif-sdk b/src/sarif-sdk
index 744f7206b..4959f73eb 160000
--- a/src/sarif-sdk
+++ b/src/sarif-sdk
@@ -1 +1 @@
-Subproject commit 744f7206b6d51bf3a285ce2cb80d90e7d1b942f2
+Subproject commit 4959f73ebe231caa914931a9f26699a9b3dd4315

From b32a98290a0acbd529f3019647c2d42dcff3be37 Mon Sep 17 00:00:00 2001
From: Shaopeng <81775155+shaopeng-gh@users.noreply.github.com>
Date: Mon, 10 Jan 2022 12:08:56 -0800
Subject: [PATCH 09/10] update history.md

---
 src/ReleaseHistory.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/ReleaseHistory.md b/src/ReleaseHistory.md
index 96056700d..fc8c8a09a 100644
--- a/src/ReleaseHistory.md
+++ b/src/ReleaseHistory.md
@@ -2,7 +2,7 @@
 
 ## Unreleased
 
-* BUGFIX: Fix Error BA2006: '...' was compiled with one or more modules which were not built using minimum required tool versions [533](https://github.com/microsoft/binskim/pull/533)
+* BUGFIX: Fix Error BA2006: '...' was compiled with one or more modules which were not built using minimum required tool versions [545](https://github.com/microsoft/binskim/pull/545)
 * BUGFIX: Fix `JsonSerializationException` that occurs when saving SARIF v1 with telemetry enabled. [#535](https://github.com/microsoft/binskim/pull/535)
 * BUGFIX: Fix `NullReferenceException` when `--Hashes` and telemetry rules are enabled. [#531](https://github.com/microsoft/binskim/pull/531)
 

From 3441b727f0d616f9e828e785e9e5f314a9db363f Mon Sep 17 00:00:00 2001
From: Shaopeng <81775155+shaopeng-gh@users.noreply.github.com>
Date: Mon, 10 Jan 2022 12:44:11 -0800
Subject: [PATCH 10/10] update history md file

---
 src/ReleaseHistory.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/ReleaseHistory.md b/src/ReleaseHistory.md
index fc8c8a09a..fde4e9095 100644
--- a/src/ReleaseHistory.md
+++ b/src/ReleaseHistory.md
@@ -2,7 +2,7 @@
 
 ## Unreleased
 
-* BUGFIX: Fix Error BA2006: '...' was compiled with one or more modules which were not built using minimum required tool versions [545](https://github.com/microsoft/binskim/pull/545)
+* BUGFIX: Fix incorrect analysis for non-Microsoft compiler on BA2006.BuildWithSecureTools [545](https://github.com/microsoft/binskim/pull/545)
 * BUGFIX: Fix `JsonSerializationException` that occurs when saving SARIF v1 with telemetry enabled. [#535](https://github.com/microsoft/binskim/pull/535)
 * BUGFIX: Fix `NullReferenceException` when `--Hashes` and telemetry rules are enabled. [#531](https://github.com/microsoft/binskim/pull/531)